Tecnologías Web Jose Emilio Labra Gayo Departamento de Informática

Tecnologías Web Jose Emilio Labra Gayo Departamento de Informática
Universidad de Oviedo

Esquema de la exposición
1.-Lenguaje XML Definición y Vocabularios 2.-Arquitecturas Web Cliente-servidor Componentes distribuidos Servicios Web Otras arquitecturas: Agentes, P2P, etc. 3.-Web Semántica Descripción de recursos Ontologías

Internet (60-80) Origen militar Protocolos de comunicación (TCP/IP)
Seguridad ante ataques (múltiples servidores) (80 – 95) Implantación académica Protocolos de intercambio de información (FTP, SMTP, HTTP, ...) Enorme biblioteca con material hipermedia (95 – 00) Acceso comercial Posibilidad de negocio  Dinero!! Boom comercial La red es un ordenador gigante para hacer negocios (00-) Crisis de las punto com Historias de fracasos  Lecciones aprendidas Revisión de las arquitecturas tradicionales

Topologías Transaccional Grandes mainframes con terminales tontas
Bases de datos multiusuario transaccionales El sistema garantizaba que una unidad de trabajo era completamente procesada (o no) sin interferencias Relacional Aparición de ordenadores personales Necesidad de comunicación  Creación de LANs Arquitecturas cliente-servidor (Múltiples clientes – un servidor) Bases de datos relacionales (múltiples vistas de los datos) Navegacional Web = Múltiples clientes y múltiples servidores Computación obicua (PDAs, moviles, coches,...) Se requieren nuevos servicios de todo tipo Actividades del cliente: navegar y descubrir servicios Arquitecturas: anillos, comunidades, peer-to-peer, ...

Arquitectura Cliente/Servidor
Protocolo HTTP se basa en la arquitectura cliente/servidor (sin estado) Servidor Cliente Protocolo http Visualizador GET 200 OK <html> <body> Enlace a <a href =“otro.html”>Otro</a> </body> </html>

Arquitectura Cliente/Servidor Computación dinámica
Arquitectura de 3 capas Servidor Cliente Base Datos Computación dinámica: La información se computa en el momento en que se solicita (normalmente a partir de una base de datos) Ejemplos: Información meteorológica, bursátil, estado de carreteras, etc. Ventajas: Flexibilidad: La información se adapta a las características del cliente Eficiencia: No es necesario tener almacenada toda la información Posibilidades Computación en cliente Computación en servidor

Arquitectura Cliente/Servidor Computación en cliente
Etiqueta <object> permite incluir elementos computacionales El visualizador reconoce el tipo de elemento y lo ejecuta Sólo funciona con ciertos tipos de visualizadores (necesidad de plug-ins) <p><OBJECT CLASSID=”juego.py" CODETYPE="application/x-python" TITLE=”Juego lógico"> </OBJECT></p> Applets = código Java compilado (Java utiliza la máquina virtual JVM) Muchos visualizadores incluyen la JVM La etiqueta <applet> no se recomienda en HTML 4.0 (deprecated) Es preferible la utilización de <object> <p><OBJECT CLASSID="java:juego.class" CODETYPE="application/java" WIDTH=400 HEIGHT=250> </OBJECT></p>  Menor carga computacional en el servidor  Menor carga en la red  Dependencia capacidades del cliente  Problema de seguridad para el cliente Valoración

Arquitectura cliente/servidor Computación en cliente
La etiqueta <script> permite incluir guiones (programas interpretados por el visualizador) DHTML (Dynamic HTML): los programas pueden tener acceso a características del visualizador Lenguajes interpretados: JavaScript, VBScript, etc. <p><SCRIPT type=“text/javascript”> function onImg(name) { } function offImg(name) { } </SCRIPT> </p> Se pueden combinar con los eventos de navegación y con los formularios Aplicaciones habituales: Modificar la presentación, validar entradas, etc. <li><a href="About.html" onMouseOver='onImg("About")' onMouseOut ='offImg("About")'> <img width="200" height="23” src="Images/About.gif"></a></li>

Arquitectura cliente/servidor Computación en servidor
CGI (Common Gateway Interface) Cuando el servidor reconoce que el fichero es un CGI, en lugar de transferir su contenido, lo ejecuta como si fuese un programa y transmite al cliente los resultados de la ejecución (salida estándar) Al programa se le pasan parámetros con un formato determinado CGI = Especificación formato E/S de dichos programas Ejecución en servidor  Transparencia para el cliente El cliente sólo ve los resultados Independencia del lenguaje de programación (C, Perl, Java, ...) Lenguajes interpretados: Mediante llamada al intérprete. #! perl ... #!/usr/bin/perl código Perl que devuelve HTML El programa CGI se arranca, se ejecuta, devuelve el resultado y acaba Poco eficiente para ejecuciones repetidas No mantiene el estado (se recurre a la utilización de cookies) FastCGI utiliza un hilo por cada proceso

Arquitectura cliente/servidor Computación en servidor
Código Incrustado en HTML El servidor reconoce ciertas etiquetas y ejecuta el código que contienen El servidor debe incluir un intérprete del lenguaje de programación utilizado El programa tiene acceso a componentes del servidor Lenguajes habituales: PHP: Lenguaje específico (sintaxis similar a C, sin chequeo de tipos) ASP (Microsoft): Utiliza Visual Basic JSP (Sun): Utiliza lenguaje Java <html><body> <h1><?php ?></h1> . . . </body></html> Servlets: Programas Java compilados que se ejecutan en la JVM del servidor Dependen del lenguaje Java Disponibles en plataformas Java (compatibilidad?) public class MiServlet extends GenericServlet { public void service (ServletRequest rqt, ServletResponse rs) throws ServletException, IOException { . . . }

Componentes Distribuidos

Componentes Distribuidos Definiciones
Un componente software en una unidad de software independiente con una interfaz explícita que puede utilizarse para componer aplicaciones Un componente puede considerarse como una colección de objetos. Un sistema de componentes distribuidos es un sistema de componentes que pueden estar ejecutándose en diferentes máquinas. Red

Componentes Distribuidos Antecedentes
RPC (Remote Procedure Call): Permite la invocación a procedimientos remotos Concepto de Marshalling/Unmarshalling: Conversión de parámetros en las llamadas RMI (Remote Method Invocation): Permite la invocación a métodos de objetos que residen en diferentes máquinas virtuales Concepto de serialización/deserialización de objetos Recolección de basura remota Sistemas de Transacciones Distribuidos: CICS (1977, IBM), TUXEDO (BEA)

Plataformas existentes Microsoft COM y .NET
COM (1993) fue uno de los primeros modelos de componentes populares DCOM (1995) = Componentes distribuidos mediante RPC COM+ (2000) nueva generación con soporte transaccional .NET Framework (2002) proporciona: - Lenguaje intermedio común (CLR) - Programación en Cliente (ASP.NET) - Componentes de negocios (.NET Enterprise services) - Bases de datos (ADO.NET) - Servicios Web - etc. Similar a plataforma Java, aunque promueve la independencia del Lenguaje (VB, C++, C#, etc.) e incluso de plataforma (Mono en Linux) Prog. Declarativa mediante atributos vs Descriptor de despliegue

Plataformas existentes CORBA
CORBA (Common Object Request Broker Architecture) fue desarrollado por el OMG (Object Management Group) en 1989 Independencia de Lenguaje y de Plataforma ORB (Object Request Broker): Intermediario de petición de objetos Proporciona transparencia entre clientes e implementaciones IDL (Interface Definition Language) Lenguaje propio para definir interfaces Conversiones desde/hacia otros lenguajes (C++, Java, etc.) Numerosos servicios soportados: Nombres, comunicaciones asíncronas, transacciones, concurrencia y seguridad Reciente extensión para soportar componentes no muy utilizada

Plataformas existentes EJBs
Sun Microsystems desarrolló un modelo de componentes distribuidos en 1997 denominado Enterprise Java Beans (EJBs) Inspirados en CORBA, pero específico para Java Arquitectura basada en un contenedor (servidor de aplicaciones) que ofrece servicios de infraestructura: Persistencia, Concurrencia, Transacciones, Seguridad, etc. Posteriormente, se describirá en más detalle...

Arquitectura de Componentes Distribuidos Contenedor
El contenedor o servidor de aplicaciones se encarga de proporcionar servicios de infraestructura La especificación de servicios puede ser: Programática: Se ofrece acceso a APIs de servicios Ejemplo: JDBC, JTA, JNDI, JMS, etc. Declarativa: Mediante los descriptores de despliegue se definen diversas políticas como la seguridad, las transacciones El contenedor puede gestionar otros servicios: Ciclo de vida de componentes, pool de recursos, servicios de nombres, clustering, etc.

Arquitectura de Componentes Distribuidos stub y skeleton
stub: Objeto que se forma en el cliente y se encarga de la comunicación con el objeto remoto (patrón proxy) skeleton: Objeto del lado del servidor que se comunica con el stub y el objeto distribuido (patrón adapter) Ventaja: Liberar al cliente y al objeto distribuido de tareas de comunicación. Incluso pueden generarse automáticamente Cliente interfaz remota Red Objeto Distribuido stub skeleton interfaz remota

Arquitectura de Componentes Distribuidos Middleware explícito
El Objeto distribuido se encarga de gestionar directamente los servicios del contenedor: transacciones, persistencia, seguridad, etc. Problema: Mayor complejidad en desarrollo de objeto distribuido Contenedor Cliente Transacciones interfaz remota Persistencia Red Objeto Distribuido stub skeleton interfaz remota Seguridad ...

Arquitectura de Componentes Distribuidos Middleware implícito
Se utiliza un objeto interceptor que se encarga de gestionar servicios del contenedor y llamar al objeto distribuido cuando sea necesario. Ventaja: Libera al objeto distribuido de dichas tareas. Posibilidad de creación automática del interceptor. Contenedor Cliente Transacciones interfaz remota Bases Datos Red stub skeleton Interceptor interfaz remota Seguridad Objeto Distribuido ...

Arquitectura de Componentes Distribuidos Creación de Objetos
La creación, eliminación y búsqueda de objetos distribuidos se realiza mediante un objeto dedicado exclusivamente a dicha tarea (patrón Factoría) Contenedor solicitud creación Cliente Factoría Transacciones interfaz factoría interfaz remota crea Bases Datos Red stub skeleton Interceptor interfaz remota Seguridad Objeto Distribuido ...

Servicios de Infraestructura
El contenedor se encarga de los servicios de infraestructura: - Gestión de recursos - Concurrencia - Transacciones - Mensajería Asíncrona - Nombres - Seguridad etc.

Servicios de Infraestructura Gestión de Recursos
Problema de Escalabilidad: Mantener eficiencia cuando el número de clientes aumenta Acciones: Pooling de recursos: permite reutilizar varios recursos para diferentes propósitos Pooling de instancias: Los mismos Objetos son utilizados por diferentes peticiones (evita la creación de nuevos objetos para cada petición) Gestión de Pasivación/Activación: Almacenar valores de un objeto en memoria secundaria o recuperarlos. Balance de carga: Distribuir peticiones a elementos con menor carga Clustering: Utilizar varios servidores de aplicaciones

Servicios de Infraestructura Concurrencia
La programación concurrente requiere técnicas de programación avanzadas: bloqueos, recursos compartidos, sincronización, etc. El contenedor puede realizar la gestión de la concurrencia, liberando al desarrollador (limita creación explícita de hilos) Aspectos: Código Reentrante: Código que puede ser compartido por varios procesos. El mantenimiento de estado de objetos limita posibilidades.

Servicios de Infraestructura Transacciones
Una transacción es un conjunto de tareas que se ejecutan como una unidad Propiedades ACID (A)tomicidad: El trabajo se realiza en su totalidad o no se realiza (C)onsistencia: Se mantiene la coherencia de los datos (aunque se produzcan fallos) (I)solation (Aislamiento): Cada transacción es autónoma y no depende de otras (D)urabilidad: Los resultados permanecen aunque haya fallos Ejemplo: Comprar billete = Reservar plaza + Pagar Interrupción comunicación tras la reserva... Protocolo de consumación en 2 fases Ejemplo: Viaje combinado (varios proveedores y fallo del último...)

Servicios de Infraestructura Mensajería
MOM (Message Oriented Middleware) = Capa que se encarga de la comunicación mediante mensajes Acoplamiento fuerte: El emisor realiza una petición y queda a la espera de la respuesta. Problema: Fallo en comunicación o en receptor? Acomplamiento débil: El emisor envía un mensaje y continúa trabajando 2 modelos: Publica y subscribe Punto a Punto Suscriptor Receptor Potencial Publicador Tópico Suscriptor Emisor Cola Receptor Potencial Suscriptor

Servicios de Infraestructura Persistencia
Persistencia consiste en el almacenamiento en memoria secundaria del estado de los objetos El contenedor puede encargarse de gestionar dicho almacenamiento Aspectos: Conversión modelo OO a modelo relacional Consultas de datos Rendimiento En EJBs los beans de entidad son objetos con persistencia. 2 posibilidades: Bean Managed Persistence (BMP) Container Managed Persistence (CMP)

Servicios de Infraestructura Trasparencia de Localización
El contenedor se encarga de la localización física del objeto distribuido El cliente accede a través de un nombre lógico que el contenedor resuelve. La dirección exacta sólo es conocida por el contenedor Facilita escalabilidad (ejemplo: clustering) En EJBs, se utiliza JNDI para localizar/asociar nombres a recursos. JNDI es un API común que permite la coexistencia de varios servicios de directorios

Servicios de Infraestructura Seguridad
Retos de seguridad: 1. Integridad: Garantizar que los documentos o mensajes, y sus componentes no han sido alterados 2. Autentificación: Garantizar que una entidad (persona o sistema) es quien dice que es. 3. Autorización: Determinar los privilegios asociados a una entidad 4. Confidencialidad: Garantizar que elementos no autorizados no pueden acceder a documentos, mensajes o sus componentes 5. No repudiación: Prohibir que una entidad niegue haber recibido o enviado un mensaje En EJBs, el contenedor facilita gestión de autorización de forma declarativa mediante roles.

Componentes Distribuidos: Caso particular: Enterprise Java Beans

Plataformas existentes EJBs
Desarrollados por Sun Microsystems como modelo de componentes de negocio en servidor para Java Se definen como: Una especificación + Un conjunto de interfaces Evolución: EJB 1.0 (1997) Beans de sesión EJB 1.1 (1999) Beans de entidad EJB 2.0 (2001) Beans manejados por mensajes EJB 2.1 (2003) Soporte para Servicios Web EJB 3.0 (borrador) Meta-datos para facilitar desarrollo declarativo

Tipos de Beans EnterpriseBean SessionBean MessageDrivenBean EntityBean
BMP Stateless Stateful CMP

Beans de Sesión SessionBean
Los Beans de Sesión describen procesos de negocio Ejemplos: ConsultarTarifa, ReservaViaje, etc. 2 tipos: Sin estado: no almacenan información entre peticiones Los beans sin estado facilitan la gestión de recursos del contenedor (mayor rendimiento) Con estado: permiten conversaciones de un cliente Requieren serialización/deserialización de valores Estado conversacional: el estado sólo se almacena durante una sesión del cliente

Beans de Entidad EntityBean
Los Beans de entidad describen elementos del dominio Característica: Persistencia (son almacenables) Ejemplos: Cliente, Avión, Aeropuerto, etc. Aspectos: Necesario declarar una clave primaria (puede ser objeto compuesto) Conversión automática modelo OO a modelo Relacional Manejo de Persistencia: Contenedor vs Componente Incluye lenguaje de consultas EJB-QL similar a SQL

Beans Manejados por Mensajes MessageDrivenBean
Describen procesos de negocio que son accedidos asíncronamente Se subscriben y reaccionan a determinados eventos Facilitan la integración de sistemas ya existentes Ejemplos: ReservaViaje No se declaran interfaces ya que sólo reaccionan a un método: onMessage()

Interacción entre tipos de EJBs
Es posible invocar a Beans de sesión o a Beans manejados por mensajes (MDBs) pero no a Beans de entidad Firewall Servidor Web Cliente HTML JSP Servdor Aplicaciones (Contenedor) EJB Sesión EJB Entidad RMI-IIOP Servlet Socio Negocio SOAP WSDL UDDI Aplicación Applet RMI-IIOP EJB Sesión EJB Entidad Cliente CORBA IIOP EJB MDB EJB Sesión Cliente Mensaje Mensaje

Partes de un EJB Enterprise Bean: Objeto distribuido propiamente dicho EJBObject: Interceptor Objeto Home: Objeto Factoría Interfaz Remote: Interfaz del Enterprise Bean (también puede ser local) Interfaz Home: Interfaz del Objeto Home Descriptor de Despliegue: Especificación declarativa del componente Contenedor solicitud creación Cliente Factoría Transacciones interfaz factoría interfaz remota crea Bases Datos Red stub skeleton Interceptor interfaz remota Seguridad Objeto Distribuido ...

Partes de un EJB Enterprise Bean: Objeto distribuido propiamente dicho EJBObject: Interceptor Objeto Home: Objeto Factoría Interfaz Remote: Interfaz del Enterprise Bean (también puede ser local) Interfaz Home: Interfaz del Objeto Home Descriptor de Despliegue: Especificación declarativa del componente Contenedor solicitud creación Cliente HomeObject Transacciones interfaz Home interfaz remota crea Bases Datos Red stub skeleton EJBObject interfaz remota Seguridad Enterprise Bean ...

Partes de un EJB Enterprise Bean
El Bean de negocio (EnterpriseBean) es el objeto distribuido propiamente dicho Debe implementar la interfaz serializable así como la interfaz que corresponda a su tipo: SessionBean, MessageDrivenBean ó EntityBean Implementa los métodos que se definan en la interfaz remota (métodos públicos para los clientes) y en la interfaz Home (métodos de creación, destrucción y búsqueda)

Partes de un EJB EJB Object
El Objeto EJB (EJBObject) intercepta las invocaciones al EJB y gestiona los servicios implícitos del contenedor Forma parte del contenedor de EJBs y es generado automáticamente Contenedor solicitud creación Cliente HomeObject Transacciones interfaz Home interfaz remota crea Bases Datos Red stub skeleton EJBObject interfaz remota Seguridad Enterprise Bean ...

Partes de un EJB Interfaz del Componente
Interfaz remota del componente = contrato entre cliente y Bean de negocio Debe extender la interfaz javax.ejb.EJBObject Se publican los métodos que se quieran invocar desde el cliente La interfaz será implementada por - Bean de negocio (implementado por el desarrollador) - EJBObject (generado automáticamente por contenedor) La interfaz remota es obligatoria en beans de sesión y de entidad También puede definirse una interfaz local que se utiliza cuando el bean se invoca de forma no remota

Partes de un EJB Objeto Home
El objeto Home es la factoría para la obtención de referencias a EJBs (Patrón Factory) La factoría es la responsable de instanciar, buscar y destruir los objetos Los objetos Home son autogenerados y forman parte del contenedor. El desarrollador especifica solamente la interfaz Home Contenedor solicitud creación Cliente HomeObject Transacciones interfaz Home interfaz remota crea Bases Datos Red stub skeleton EJBObject interfaz remota Seguridad Enterprise Bean ...

Partes de un EJB Interfaz Home
Para generar los objetos Home, el desarrollador debe aportar una interfaz java que extienda la interfaz javax.ejb.EJBHome En esta interfaz se definen los métodos para crear,destruir y localizar EJBs Contenedor solicitud creación Cliente HomeObject Transacciones interfaz Home interfaz remota crea Bases Datos Red stub skeleton EJBObject interfaz remota Seguridad Enterprise Bean ...

Partes de un EJB Interfaces Locales
Permiten invocar al EJB como si se tratara de un objeto local. Solventan el problema de la sobrecarga cuando el EJB se ejecuta en la propia máquina del cliente. El Objeto Local realiza las tareas de middleware que le corresponderían al EJB Object, y luego le cede el control al bean de negocio. De esta forman, se evitan las tareas propias a la invocación remota (stubs, serialización, etc.). Son opcionales Extienden la interfaz javax.ejb.EJBLocalObject y su factoría javax.ejb.EJBLocalHome

Partes de un EJB Descriptores de Despliegue
Especifica las propiedades y servicios del EJB de forma declarativa (sintaxis XML) Describe cómo ha de ser desplegado el EJB en el contenedor, y cómo ha de ser manejado: Ciclo de vida Sistema de persistencia Control de transacciones Servicios de seguridad. Es un fichero XML: ejb-jar.xml Habrá uno por paquete de despliegue (fichero jar) y puede declarar varios EJBs de distintos tipos

En resumen... Pasos para crear un EJB
El desarrollador debe definir: - interfaz del componente (remota y/o local) - interfaz Home (remota y/o local) - Clase de negocio y clave primaria (para beans de entidad) - Descriptor de Despliegue (parte declarativa,en XML) Contenedor solicitud creación Cliente HomeObject Transacciones interfaz Home interfaz remota crea Bases Datos Red stub skeleton EJBObject interfaz remota Seguridad Enterprise Bean ...

Ejemplo de EJB de Sesión Interfaz del Componente
Necesario para que el contenedor implemente el EJBObject public interface Suma extends EJBObject { public int suma(int a, int b) throws java.rmi.RemoteException; } Método que va a ser invocado Necesario para todos los métodos de objetos distribuidos

Ejemplo de EJB de Sesión Interfaz Home
Necesario para que el contenedor implemente el EJBHome public interface SumaHome extends EJBHome { Suma create() throws javax.ejb.CreateException,java.rmi.RemoteException; } Método que se invocará al crear el EJB

Ejemplo de EJB de Sesión Objeto de Negocio
Implementación del método Bean de sesión Métodos que controlan el ciclo de vida (en este caso, no hacen nada) public class SumaBean implements SessionBean { public void ejbActivate() throws EJBException, RemoteException { } public void ejbPassivate() throws EJBException, RemoteException { } public void ejbRemove() throws EJBException, RemoteException { } public void setSessionContext(SessionContext arg0) throws EJBException, RemoteException { } public void ejbCreate() throws javax.ejb.CreateException { } public int suma(int a, int b) { return (a+b); } }

Ejemplo de EJB de Sesión Descriptor de Despliegue (1)
<?xml version="1.0"?> <!DOCTYPE ejb-jar PUBLIC "-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 2.0//EN" " <ejb-jar> <enterprise-beans> <session> <ejb-name>ejbSuma</ejb-name> <home>com.suma.ejbSuma.SumaHome</home> <remote>com.suma.ejbSuma.Suma</remote> <ejb-class>com.suma.ejbSuma.SumaBean</ejb-class> <session-type>Stateless</session-type> <transaction-type>Container</transaction-type> </session> </enterprise-beans> . . . Declara las clases e interfaces del EJB Delega la gestión transaccional al contenedor Indica que es sin estado

Ejemplo de EJB de Sesión Descriptor de Despliegue (y 2)
<assembly-descriptor> <security-role><role-name>everyone</role-name></security-role> <method-permission> <role-name>everyone</role-name> <method> <ejb-name>ejbSuma</ejb-name><method-name>*</method-name> </method> </method-permission> <container-transaction> <trans-attribute>Required</trans-attribute> </container-transaction> </assembly-descriptor> </ejb-jar> Especifica política de seguridad (todo el mundo puede invocar todos los métodos) Especifica política de transacciones (el contenedor de crear una transacción si no existe)

Ejemplo de EJB de Sesión Código Cliente
import com.suma.ejbSuma.SumaHome; public class hazSuma { public static void main(String[] args) { try { Context jndiContext = new InitialContext(); Object ref = jndiContext.lookup("Suma"); SumaHome home = (SumaHome) PortableRemoteObject.narrow(ref,SumaHome.class); Suma s = home.create(); System.out.println("2 + 3 = " + s.suma(2,3)); } catch (Exception e) { System.out.println("Exception: " + e); } Buscar objeto Home en JNDI Convertir referencia a objeto Home Crear objeto EJB a partir del Home Invocar método

EJBs Valoración Facilita el desarrollo de aplicaciones Web liberando al programador de la gestión de tareas complicadas: gestión de recursos, transacciones, seguridad, etc. Favorece una mayor separación entre lógica de negocio y presentación Gran penetración en el mercado: numerosas implementaciones comerciales y libres Permite la integración entre tecnologías de última generación y tecnologías ya existentes (legacy systems) Soporte a la escalabilidad del sistema desde el principio

EJBs Valoración Múltiples capas intermedias
Puede perjudicar depuración y rendimiento Tecnología en movimiento, necesidad de consolidación de algunas especificaciones No todas las aplicaciones requieren EJBs. Ejemplos: - Aplicaciones basadas únicamente en interfaz de usuario accediendo a base de datos (sin lógica de negocio) - Aplicaciones muy simples (prototipos), en algunos casos puede ser como matar pulgas a cañonazos... - Limitaciones de EJBs, se requiere utilización de código nativo o programación multi-hilo - Se utilizan otras tecnologías alternativas: .NET o CORBA... Programación declarativa mediante lenguajes no convencionales: vocabularios XML, lenguaje EJB-QL, etc...

Bibliografía Libros: Mastering EJBs de Ed Roman
EJB Design Patterns de Floyd Marinescu Enterprise Java Beans de Richard Monson-Haefel URLS: java.sun.com/products/ejb/ Especificaciones y otros documentos Documentos y Forums EJB FAQ

Servicios Web

Antecedentes Intercambio de XML
XML-RPC Adapta RPC para envío de mensajes en formato XML Semilla de SOAP XMOP (XML Metadata Object Persistence) Protocolo de interacción de objetos ebXML (electronic business XML) Proyecto más ambicioso Intercambio de mensajes, gestión y recuperación de errores, calidad de servicio, seguridad, etc. Reciente acuerdo para adoptar SOAP como parte de su infraestructura

Servicios Web Posible definición
Aplicaciones auto-contenidas, auto-descritas que pueden ser publicadas, localizadas e invocadas a través de la Web Una vez desarrolladas, otras aplicaciones (y otros servicios Web) pueden descubrirlas e invocar el servicio dado Servicio Web Petición Respuesta Internet URL

Servicios Web Factores que influyeron en su aparición
Computación Distribuida: RPC, CORBA, RMI, DCOM Sistemas fuertemente acoplados Integración de aplicaciones: EAI (Enterprise Application Integration) Reacción frente a sistemas ERP monolíticos Aparición de XML Adopción por principales industrias XML-RPC Necesidad de intercambios B2B Sistemas de integración EDI, RosettaNet, ebXML Comercio electrónico y burbuja de Internet Necesidad de nuevas fórmulas Microsoft vs. Java Compatibilidad

Servicios Web Objetivos
Independencia del lenguaje y de la plataforma Separación de especificación de la implementación Interoperabilidad Utilización de estándares: XML, SOAP, WSDL, UDDI... Acoplamiento débil: Sistemas basados en mensajes Interacciones síncronas y asíncronas A través de Internet Sin control centralizado Utilización de Protocolos establecidos Consideraciones de seguridad Modularidad y Reusabilidad de servicios Escalabilidad: Aplicaciones uno-a-uno frente a uno-a-muchos

Servicios Web Principales Vocabularios
Protocolo de transporte HTTP/HTTPs (principalmente) Codificación de datos y mensajes SOAP (Simple Object Access Protocol) Descripción del servicio WSDL (Web Service Description Language) Búsqueda y localización de servicios UDDI (Universal Discovery, Description and Integration) Programas accesibles en Internet que esponen su funcionalidad recibiendo/enviando mensajes SOAP a través de HTTP(s) y describen su interfaz en WSDL Otra definición

Servicios Web Principales Vocabularios
UDDI registra publica WSDL encuentra obtiene WSDL Consumidor servicio Web HTTP petición SOAP (XML) respuesta SOAP (XML) Implementación servicio Web

Servicios Web Arquitectura de Aplicaciones
XSLT HTML Dispositivo del Cliente Base Datos SOAP XML XSLT WML Servicio Web XSLT VoiceXML

Servicios Web Arquitectura de Aplicaciones
Conversión de Monedas Facturación Gestión de Usuarios SOAP SOAP SOAP XML Aplicación del usuario Internet SOAP SOAP

SOAP Evolución SOAP: Define el formato de los mensajes
SOAP = Simple Object Access Protocol Aunque tiene poco de objetos... Evolución Desarrollado a partir de XML-RPC SOAP 1.0 (1999), 1.1 (2000), 1.2 (2002) Participación inicial de Microsoft Adopción posterior de IBM, Sun, etc. Aceptación industrial

SOAP Formato Envelope Header Header Key Body

SOAP Ejemplo Cabecera Contenido <?xml version=‘1.0’ ?>
<soap:Envelope xmlns:soap=‘ xmlns:p =‘ </soap:Envelope> <soap:Header> <p:prioridad> urgente </p:prioridad> </soap:Header> Cabecera <soap:Body> <p:encargo> <p:pizza nombre=‘Margarita’> <p:tamaño>familiar</p:tamaño> <p:comentario>con mucho queso</p:comentario> </p:pizza> </p:encargo> </soap:Body> Contenido

SOAP Formato general SOAP especifica el formato de mensajes
Es independiente del protocolo de transporte Aunque se define un enlace (binding) con HTTP envelope: Pueden especificarse datos globales (codificación, espacios de nombres, etc.) Contiene: header (opcional) + body (obligatorio) body contiene datos en formato XML header contiene meta-información Extensiones obligatorias/opcionales

SOAP Header header incluye información sobre el mensaje
Facilita futuras extensiones Seguridad, transacciones, etc. Información procesable por intermediarios Atributos pre-definidos mustUnderstand (true/false) Si el elemento no puede procesar dicha información devuelve un error actor Indica qué nodo debe procesar la información Si no aparece, debe procesarla el nodo receptor final

SOAP Fault fault: Formato predefinido de mensajes de error Se incluye el elemento fault en el cuerpo Subelementos predefinidos faultcode: Código del error Predefinidos: VersionMismatch, MustUnderstand, DTDNotSupported, DataEncodingUnknown, Sender, Receiver faultstring: Explicación legible por personas detail: Información específica de la aplicación Puede contener elementos XML faultactor: URI del nodo que causó el error

SOAP Fault <?xml version=‘1.0’ ?>
<soap:Envelope xmlns:soap=‘ </soap:Envelope> <soap:Body> <soap:Fault> <faultcode>soap:Receiver’</faultcode> <faultstring>Error al procesar</faultstring> <detail> <p:detalles xmlns:p=‘ <mensaje>La pizza Barbacoa no puede llevar tanto queso</mensaje> </p:detalles> </detail> </p:pizza> </soap:Fault> </soap:Body>

SOAP Codificación Atributo encodingStyle define reglas de codificación
Algunos tipos básicos predefinidos Enteros, cadenas, flotantes Contiene reglas específicas para: Estructuras Arrays Referencias Se complementa con XML Schemas Pueden definirse otros sistemas de codificación

SOAP Codificación Tipos básicos <?xml version=‘1.0’ ?>
<soap:Envelope xmlns:soap=‘ xmlns:xsi=“ encodingStyle=‘ <soap:Body> <p:pizza> <p:código xsi:type=‘soap:int’>234</p:comida> <p:tamaño xsi:type =‘soap:string’>familiar</p:tamaño> </p:pizza> </soap:Body> </soap:Envelope>

SOAP Codificación Estructuras Arrays struct Pizza { int código;
string nombre; }; <Pizza xmlns=‘cualquier_URI’> <código>234</código> <nombre>Barbacoa</nombre> </Pizza> <pizzas xsi:type=‘soap:Array’ soap:arrayType=‘p:Pizzas[2]’> <pizza> <código>234</código> <nombre>Barbacoa</nombre> </pizza> <pizza><código>237</código> </pizzas> Arrays

SOAP Codificación Arrays parciales 5º y 6º elemento 2º y 5º elemento
<pizzas xsi:type=‘soap:Array’ soap:arrayType=‘p:Pizzas[10]’ soap:offset=‘[4]’> <pizza> <código>234</código> <nombre>Barbacoa</nombre> </pizza> <pizza><código>237</código> </pizzas> 5º y 6º elemento <pizzas xsi:type=‘soap:Array’ soap:arrayType=‘p:Pizzas[10]’> <pizza soap:position=‘2’> <código>234</código> <nombre>Barbacoa</nombre> </pizza> <pizza soap:position=‘5’ ><código>237</código> </pizzas> 2º y 5º elemento

SOAP Ejemplo con HTTP POST /Suma/Service1.asmx HTTP/1.1
Host: localhost Content-Type: text/xml; charset=utf-8 Content-Length: longitod del mensaje SOAPAction: " <?xml version="1.0" encoding="utf-8"?> <soap:Envelope xmlns:soap=" <soap:Body> <suma xmlns=" <a>3</a> <b>2</b> </suma> </soap:Body> </soap:Envelope>

SOAP Ejemplo de respuesta
HTTP/ OK Content-Type: text/xml; charset=utf-8 Content-Length: longitud del mensaje <?xml version="1.0" encoding="utf-8"?> <soap:Envelope xmlns:soap=" <soap:Body> <sumaResponse xmlns=" <sumaResult>5</sumaResult> </sumaResponse> </soap:Body> </soap:Envelope>

WSDL Evolución WSDL (Web Services Description Language) Describe:
Qué puede hacer el servicio Dónde reside Cómo invocarlo Vocabulario basado en capas Es posible concentrarse en una capa cada vez Evolución: Iniciativa conjunta de Ariba, IBM y Microsoft (2001) Propuesto a W3C como recomendación (WSDL 1.1) (2003) En desarrollo WSDL 2.0

WSDL Estructura del documento
definitions types Tipos de datos usados en los mensajes (XML Schema) message Definición abstracta de los datos transmitidos. portType Conjunto de operaciones abstractas binding Protocolo concreto y especificaciones de los formatos de las operaciones del mensaje port Especifica una dirección para el enlace definiendo un único punto de destino service Colección de puntos de destino

WSDL Ejemplo <?xml version="1.0" encoding="utf-8" ?>
<definitions xmlns:s=. . . <types> <s:schema <s:element name="suma"> <s:complexType> <s:sequence> <s:element minOccurs="1" maxOccurs="1" name="a" type="s:int" /> <s:element minOccurs="1" maxOccurs="1" name="b" type="s:int" /> </s:sequence> </s:complexType> </s:element> . . . <message name="sumaSoapIn"> <part name="parameters" element="s0:suma" /> </message>

WSDL Ejemplo . . . <portType name="ServicioSumaSoap">
<operation name="suma"> <input message="s0:sumaSoapIn" /> <output message="s0:sumaSoapOut" /> </operation> </portType> <binding name="ServicioSumaSoap" type="s0:ServicioSumaSoap"> <soap:binding transport=" style="document" /> <soap:operation soapAction=" style="document" /> <input> <soap:body use="literal" /> </input> <output> <soap:body use="literal" /> </output> </binding> <service name="ServicioSuma"> <port name="ServicioSumaSoap" binding="s0:ServicioSumaSoap"> <soap:address location=" /> </port> </service> </definitions>

UDDI Definición UDDI (Universal Discovery, Description and Integration) Consorcio formado por IBM, Hp, Sun, Microsoft, Oracle, etc. UDDI 1.0 (2000) Fundación del registro UDDI 2.0 (2001) Alineación con estándares y taxonomía de servicios más flexible UDDI 3.0 (2002) Interacción de implementaciones públicas y privadas 2 partes Descripción de negocios Páginas blancas (información de contacto) “ amarillas (información de la industria) “ verdes (información técnica y especificaciones) Registro de servicios

UDDI Definición tModel: Descripciones de especificaciones de servicios Binding contiene referencias a tModels. Estas referencias declaran las especificaciones del interfaz 0…n Provider: Información sobre la entidad que ofrece el servicio 0…n Service: Información descriptiva sobre una familia particular de ofertas 0…n Binding: Información técnica sobre un punto de entrada a un servicio

servicio Web conversión
UDDI Funcionamiento El desarrollador construye un servicio para convertir monedas servicio Web conversión El usuario construye una aplicación que consuma el servicio Web directamente SOAP El usuario pregunta a UDDI por servicios de conversión Servicios UDDI El desarrollador registra y clasifica el servicio Web El usuario determina el servicio de conversión más apropiado

Utilización de un Servicio Web Ejemplos
Consltar listados de servicios Web Pueden ejecutarse

Utilización de servicios Web Ejemplos: Google

Utilización de servicios Web Ejemplos: Amazon

Implementación de Servicios Web Posibilidades
Java APIs de Sun: JAXRPC, JAXM, SAAJ, Librerías de Apache: Axis Microsoft .NET ASP.NET para C#, VBasic, etc. MS SOAP Toolkit Otros: SOAP::Lite (Perl), NuSOAP (PHP), Axis (C++)

Implementación de Servicios Web APIs de Java
SAAJ (SOAP with Attachments API for Java) Tratar mensajes SOAP como objetos Java JAX-RPC (Java API for XML based RPC) Modelo de programación Conversión WSDL/XML  Java Manejo de SOAP y SOAP con Attachments API para cliente: WSDL, Invocación y proxy dinámico JWSDL Acceso a descripciones WSDL JAXR (Java API for XML Registries) Acceso a registros de servicios Web (UDDI)

Implementación de Servicios Web Apache Axis
Sucesor de Apache SOAP (software abierto) Soporta JAX-RPC y SAAJ Arquitectura flexible y extensible Necesita servidor de aplicaciones (por ejemplo Tomcat) Validar la instalación:

Implementación de Servicios Web Creación de un Cliente
WSDL adaptador stubs clases Java generadas WSDL2Java código cliente javac Descripción del servicio

Implementación de servicios Web Creación de un cliente
1.- Acceder a WSDL Almacenar como suma.wsdl > java org.apache.axis.wsdl.WSDL2Java -p suma suma.wsdl 2.-Generar stubs 3.- Comprobar clases generadas > ls suma/*.java ServicioSuma.java ServicioSumaLocator.java ServicioSumaBindingStub.java ServicioSumaPortType.java 4.- Compilar clases generadas > javac suma/*.java

Implementación de servicios Web Creación de un cliente
ClienteSuma.java import suma.*; public class ClienteSuma { public static void main(String[ ] args) throws Exception { try { ServicioSumaLocator loc = new ServicioSumaLocator(); ServicioSumaPortType p = loc.getServicioSumaPort(); System.out.println("2 + 3 = " + p.suma(2,3)); } catch (Exception e) { System.err.println("Excepción: " + e); } 4.- Compilar cliente > javac CienteSuma.java 5.-Ejecutar cliente > java ClienteSuma 2 + 3 = 5

Implementación de un servicio Web Creación de un cliente
Ejercicio: Consultar temperatura del aeropuerto de Avilés... ClienteTemp.java public class ClienteTemp { public static void main(String args[]) throws Exception { try { GlobalWeather_ServiceLocator loc = new GlobalWeather_ServiceLocator(); GlobalWeather_Port s = loc.getGlobalWeather(); System.out.println("Temperatura en Aeropuerto de Asturias: " + s.getWeatherReport("LEAS").getTemperature().getString()); } catch (Exception e) { System.err.println("Excepción: " + e); }

Implementación de Servicios Web Creación de un Servicio Web
Método simple: JWS Suma.jws public class Suma { public int suma(int a, int b) { return a + b; } Almacenar en: <TOMCAT>\webapps\axis\Suma.jws

Utilizar JWS tiene sus limitaciones Debe disponerse del código fuente Los errores aparecen en tiempo de ejecución La clase no puede tener package Sólo se pueden transferir datos simples No se puede configurar el servicio Método riguroso: WSDD (Web Service Deployment Descriptor) Permite desplegar (deploy) y quitar (undeploy) servicios Pueden utilizarse servicios compilados Control de las Conversiones de tipos

ServSuma.java package ServSuma; public class ServSuma { public int suma(int a, int b){ return (a + b); } 1.- Compilar servicio > javac ServSuma.java 2.-Copiar ServSuma.class a <TOMCAT>/webapps/WEB-INF/classes/ServSuma/ServSuma.class También puede dejarse un .jar en WEB-INF/lib

deploy.wsdd <deployment xmlns=" xmlns:java=" <service name="ServSuma" provider="java:RPC"> <parameter name="className" value="ServSuma.ServSuma"/> <parameter name="allowedMethods" value="*"/> </service> </deployment> 3.- Desplegar servicio > java org.apache.axis.client.AdminClient deploy.wsdd Processing file deploy.wsdd <Admin>Done processing</Admin> Puede ser necesario reiniciar servidor 4.- Acceder a

Implementación de Servicios Web Otras características de Axis
Invocación dinámica Dynamic Invocation Interface Invocación mediante Proxy Conversión Java2WSDL Permite generar WSDL a partir de clases/interfaces Java Generación de ficheros WSDD para deploy/undeploy Seguridad Otros protocolos de transporte

Interoperabilidad Acceso desde .NET a servicio en Java
1.- Acceso a WSDL y creación de Stubs (o proxys) > wsdl ... Writing file 'C:\usr\labra\cursos\XMLInnova\WebServ\ClienteNet\ServSumaService.cs'. En algunas versiones es necesario editar ServSumaService.cs y modificar this.URL para que incluya el puerto 8080 2.- Compilación de proxys > csc /t: library ServSumaService.cs 3.- Creación de cliente using System; public class ClienteSumaNet { public static void Main() { ServSumaService srv = new ServSumaService(); Console.WriteLine("2 + 3 = {0}", srv.suma(2,3)); }} cliente.cs > csc cliente.cs /reference:ServSumaService.cs 4.- Compilación de cliente > cliente 2 + 3 = 5 5.- Ejecución

Interoperabilidad Servicios Web en .NET

Interoperabilidad Servicios Web en PHP
suma.php <?php include "nusoap.php"; $namespace = " $servidor = new soap_server; $servidor -> configureWSDL ("ServicioSuma", $namespace, " $servidor -> wsdl -> schemaTargetNamespace = $namespace; $servidor -> register ('suma', array ('a' => 'xsd:float', 'b' => 'xsd:float'), array ('return' => 'xsd:float'), ' '', '', '', '' ); $servidor -> service ($HTTP_RAW_POST_DATA); function suma ($a, $b) { if (!$a || !$b) { return new soap_fault ("Client", "", "Se necesitan dos argumentos"); } if ((gettype ($a) != "integer" && gettype ($a) != "double") || (gettype ($b) != "integer" && gettype ($b) != "double")) { return new soap_fault ("Client", "", "El tipo debe ser entero o real"); return $a + $b; ?>

Arquitecturas Orientadas a Servicios Definición
SOA = Service Oriented Architectures Construcción de aplicaciones partiendo de interfaces, con el objetivo de desarrollar agentes débilmente acoplados que se comunican entre sí. Un tocadiscos es un servicio... ...le pasamos un disco y suena música Ejemplo En POO se encapsulan datos y procesos ...el disco incluiría su tocadiscos...

Arquitecturas Orientadas a Servicios Modelo tradicional
Datos IVA Algoritmos IVA Algoritmos Envío Compilación Aplicación Integrada Aplicación Fuente datos datos envío Tiempo de construcción Tiempo de configuración Tiempo de ejecución

Arquitecturas Orientadas a Servicios Modelo Orientado a Servicios
cálculo IVA Aplicación Integrada Compilación Aplicación servicio gastos envío Tiempo de construcción Tiempo de ejecución

Arquitecturas Orientadas a Servicios Principales características
Importancia de las interfaces Descripción rigurosa de interfaces (legibles por máquinas) Recomendación: Partir de WSDL + XML Schema Modelos débilmente acoplados Sistemas de comunicación asíncrona Estilo documento vs. estilo RPC Colas de mensajes Ej. Solicitar un libro Interoperabilidad Independencia de lenguajes y plataformas Adaptación de arquitecturas ya existentes Utilización de estándares Modelo REST vs SOAP

Servicios Web Retos Ejemplo. Reserva de avión + hotel
Gestión de servicios Web WSDM - Web Services Distribution Management Agregación de servicios Ejemplo. Reserva de avión + hotel Evolución de los servicios Cambio de la Interfaz Modelización de procesos de negocios BPEL - Business Process Execution Language Contratos, facturación ¿Quién gana dinero? ¿Qué pasa cuando algo falla? Seguridad y fiabilidad XML Security Calidad de servicios Tiempos de respuesta, soporte, monitorización, etc.

Servicios Web Mitos... Web para ordenadores?
... no confundir con Web semántica Nueva arquitectura? ...en realidad, usan arquitecturas ya existentes Obligarán a cambiar de plataformas? ... es posible incorporar sistemas heredados Lengua universal para las aplicaciones? ...no proporcionan semántica, sólo una sintaxis común Nuevo modelo de negocios? ...el negocio es el servicio, no la forma en que se suministra Ventaja competitiva? ...peligro de adoptar tecnología inmadura. Enlace automático a socios desconocidos? ...modelo de negocio no desarrollado Estándares bien definidos? ...algunos se están desarrollando y otros ni siquiera se han desarrollado Es lo mismo que .NET? ...Independiente de plataforma...

Más información www.wsindex.org
Información de servicios Web y Web semántica Portal de servicios Web orientado a empresas Sobre servicios Web Lista de servicios Web Portal sobre SOAP Especificaciones relacionadas con servicios Web

Otras Arquitecturas: Agentes Sistemas Colaborativos Peer-to-peer Grid computing

Sistemas de Agentes Código móvil: Aplicaciones globales que pueden intercambiar unidades activas de comportamiento (computaciones), no simplemente datos. Modelos: Evaluación remota: Código que se envía a un ordenador remoto para que lo ejecute Código bajo demanda: Código que se va obteniendo y ejecutando a medida que se necesita (JIT) Agentes móviles: Procesos que pueden suspender su ejecución y migrar a otro ordenador en el que continúan la ejecución Movilidad débil: El código se mueve a otro entorno, se enlaza y se ejecuta (no se transmite el estado). Movilidad fuerte: Un hilo puede mover su código y estado de la ejecución a un sitio diferente y continuar la ejecución al llegar Movilidad total: Se mueve el estado completo, incluidas las pilas de ejecución de todos los hilos  migración transparente

Sistemas de Agentes: Características
El agente es un programa y necesita un entorno de ejecución (servidor que suministra recursos) Autonomía: El código se ejecuta independientemente del usuario que lo crea Orientación a un objetivo (goal oriented): El código persigue un objetivo y para ello puede actuar sobre el entorno en el que se ejecuta Reactividad: El agente siente los cambios en el entorno y actúa de acuerdo a ellos Adaptatividad/aprendizaje: El agente actúa de acuerdo a su experiencia Autocontenido: El agente posee todos los datos que necesita para ejecutarse y migrar Coordinación: Los agentes pueden coordinarse entre sí para realizar una actividad compleja Desconexión: El agente puede seguir ejecutándose aunque el usuario (o dueño) esté desconectado Puede decidir dormir, y reestablecer conexión periódicamente El usuario puede traer de vuelta al agente cuando lo desea

Sistemas de Agentes: Tecnologías
Tecnologías Java Mole, Concordia, Mobile Objects and Agents Voyager IBM Aglets Agent Communication Language (ACL) Vocabulario KIF (Knowledge Interchange Language) KQML (Knowledge Query Manipulation Language) Diversas arquitecturas: InteRRAP, GRATE, ADEPT

Sistemas de Agentes: Valoración
Ventajas Los agentes pueden reducir el tráfico en la red No se requiere que el usuario esté conectado para que la computación se ejecute Pueden utilizarse como intermediarios (proxy) Los computadores de los usuarios no requieren gran capacidad (posible aplicación: PDAs) Desventajas Dependencia de la red, no siempre se reduce el tráfico Se requiere independencia de plataforma  Código no optimizado Seguridad  Requiere chequeo de código antes de ejecución Tolerancia a Fallos, ¿y si el servidor que ejecuta el código se cae?

Sistemas Colaborativos
La Web nació como una tecnología colaborativa Visualización / Creación de contenidos Ejemplo: Amaya Protocolo HTTP Sistemas de Edición compartida: Sistemas Wiki, Weblogs, Blogs Mensajería Instantánea: Jabber

Sistemas peer-to-peer
Sistemas de intercambio de información y/o servicios entre nodos de una red con la misma capacidad o papel. Los ordenadores se intercambian el papel de cliente/servidor Aplicaciones: música (Napster, Soul seek), Vídeos y otros archivos (Kazaa) Mensajes personales (ICQ) Ciclos computacionales Search for extraterrestiral Intelligence BOINC: Berkeley Open Infraestructure for Network Computing Colecciones de documentos (LOCKSS), etc.

Sistemas peer-to-peer Topologías
Servidor de Directorios Centralizado (sistemas híbridos) Algunos nodos tienen carácter especial (servidores de directorio) Ejemplos: Napster, Pointerra, OpenNap Problemas: Punto simple de fallo (si el servidor de directorio falla, la aplicación p2p falla). Soluciones mediante granjas de servidores. Cuello de botella (gran base de datos si hay muchos usuarios) Problemas de copyright: Si los servidores pertenecen a una compañía, ésta puede tener problemas legales. peers 1.informar/actualizar 3. transferencia 2. preguntar Servidor directorios

Directorio Descentralizado (super-peer) Se utilizan líderes de grupo (super-peers) Los super-peers están a su vez conectados entre sí como peers Se requiere uno (o más) nodos de arranque Asignan los líderes de grupo Los peers están enlazados virtualmente Ejemplos: KaZaA/FastTrack Problemas: Protocolos complejos Falta de simetría Problemas si fallan los super-peers Posibles cuellos de botella

Sistemas peer-to-peer puros: Todos los nodos tienen la misma capacidad Sistema de Inundación de preguntas (query flooding): Las peticiones se transmiten a los nodos vecinos y éstos a su vez a otros nodos. Problemas de escalabilidad Ejemplos: GNUTella Freenet: Sistemas Intercambio seguro y anónimo Se intenta proteger la identidad de la información pregunta unirse

Computación Colaborativa Grid Computing, Cluster Computing
Orígenes = Enlazar supercomputadores dispersos geográficamente Infraestructura que facilita intercambio de computaciones Comparación con red eléctrica = Disponibilidad global de ciclos de computación Varias posibilidades: Cluster Computing: Sistemas homogéneos Grid Computing: Sistemas heterogéneos y dinámicos Fuerte soporte industrial: Oracle, Sun, IBM, etc. Ejemplos: Distributed.net - Retos computacionales, ej. descifrado de códigos - Search for extraterrestrial Intelligence grid.org Lucha contra el cáncer globus.org Infraestructura para grid computing

Sistemas de Edición colaborativa Wikis
Wikis = Portales que facilitan la edición colaborativa de contenido wiki wiki = significa rápido en hawaiano Facilitan la edición rápida de contenido por parte de los usuarios Varios ejemplos: wikipedia, nupedia, etc...

Otros Sistemas Colaborativos Trabajo en Grupo
Software de trabajo en Grupo: Groupware Desarrollo de proyectos: eGroupWare, phpGroupware, Desarrollo de software: Sourceforge, bugzilla, CVS, Subversion, etc. Protocolos de Edición distribuida: WebDAV

Otros Sistemas Colaborativos Weblogs
Sistemas de registro: Weblogs, Blogs, etc. Ejemplo de aplicación:

Otros Sistemas Colaborativos Mensajería Instantánea, chatbots
Sistemas de mensajería instantánea Jabber = Protocolo de Mensajería instantánea sin servidores centralizados ChatBots = Robots que conversan automáticamente. Ejemplo: ALICE

Más información Servicios Web Portal sobre SOAP www.soapware.org
Lista de servicios Web Sobre servicios Web Especificaciones relacionadas con servicios Web Varios artículos comparando ventajas e inconvenientes de XML y servicios Web Páginas con información sobre agentes: Agents 101: agents.umbc.edu/introduction/ AgentLand:

Más Información Peer-to-Peer y Grid Computing Workshop on Peer-to-peer
Peer-to-Peer Working Group Distributed.net, Project RC5 Global Grid Forum Grid Computing Info Centre

Tecnologías Web Jose Emilio Labra Gayo Departamento de Informática

Presentaciones similares

Presentación del tema: "Tecnologías Web Jose Emilio Labra Gayo Departamento de Informática"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback

Iniciar la sesión

Autorizarse a través de una red social:

Tecnologías Web Jose Emilio Labra Gayo Departamento de Informática

Presentaciones similares

Presentación del tema: "Tecnologías Web Jose Emilio Labra Gayo Departamento de Informática"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback