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 http://servidor.com/hola.html http:/1.0 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" "http://java.sun.com/dtd/ejb-jar_2_0.dtd"> <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 www.theserverside.com: Documentos y Forums www.jguru.com 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=‘http://www.w3.org/2001/12/soap-envelope’ xmlns:p =‘http://www.mafia.it/pizzas’> </soap:Envelope> <soap:Header> <p:prioridad> urgente </p:prioridad> <p:origen>pepe@oviedo.es</p:origen> </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=‘http://www.w3.org/2001/12/soap-envelope’> </soap:Envelope> <soap:Body> <soap:Fault> <faultcode>soap:Receiver’</faultcode> <faultstring>Error al procesar</faultstring> <detail> <p:detalles xmlns:p=‘http://www.mafia.it/pizzas’> <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=‘http://www.w3.org/2001/12/soap-envelope’ xmlns:xsi=“http://www.w3.org/2001/XMLSchema” encodingStyle=‘http://www.w3.org/2001/12/soap-encoding’> <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: "http://tempuri.org/suma" <?xml version="1.0" encoding="utf-8"?> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <suma xmlns="http://tempuri.org/"> <a>3</a> <b>2</b> </suma> </soap:Body> </soap:Envelope>
SOAP Ejemplo de respuesta HTTP/1.1 200 OK Content-Type: text/xml; charset=utf-8 Content-Length: longitud del mensaje <?xml version="1.0" encoding="utf-8"?> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <sumaResponse xmlns="http://tempuri.org/"> <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="http://schemas.xmlsoap.org/soap/http" style="document" /> <soap:operation soapAction="http://tempuri.org/suma" 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="http://localhost/Suma/Service1.asmx" /> </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 www.xmethods.net www.bindingpoint.com 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: http://localhost:8080/axis
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 http://petra.euitio.uniovi.es/~labra/ws/suma.php?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... http://live.capescience.com/wsdl/GlobalWeather.wsdl 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 http://localhost:8080/axis/Suma.jws
Implementación de Servicios Web Creación de un Servicio Web 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
Implementación de Servicios Web Creación de un Servicio Web 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
Implementación de Servicios Web Creación de un Servicio Web deploy.wsdd <deployment xmlns="http://xml.apache.org/axis/wsdd/" xmlns:java="http://xml.apache.org/axis/wsdd/providers/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 http://localhost:8080/axis/services/ServSuma
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 http://localhost:8080/axis/services/ServSuma?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 .NET
Interoperabilidad Servicios Web en .NET
Interoperabilidad Servicios Web en PHP suma.php <?php include "nusoap.php"; $namespace = "http://petra.euitio.uniovi.es/~labra/ws/suma.php?wsdl"; $servidor = new soap_server; $servidor -> configureWSDL ("ServicioSuma", $namespace, "http://petra.euitio.uniovi.es/~labra/ws/suma.php"); $servidor -> wsdl -> schemaTargetNamespace = $namespace; $servidor -> register ('suma', array ('a' => 'xsd:float', 'b' => 'xsd:float'), array ('return' => 'xsd:float'), 'http://petra.euitio.uniovi.es/~labra/ws/suma.php', '', '', '', '' ); $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 www.searchwebservices.com Portal de servicios Web orientado a empresas www.webservices.org Sobre servicios Web www.xmethods.net Lista de servicios Web www.soapware.org Portal sobre SOAP www.w3c.org/2002/ws 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 SETI@home: 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
Sistemas peer-to-peer Topologías 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 Topologías 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 SETI@Home - 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: http://allconsuming.net/
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 www.xmethods.com Sobre servicios Web www.webservices.org Especificaciones relacionadas con servicios Web www.w3c.org/2002/ws Varios artículos comparando ventajas e inconvenientes de XML y servicios Web www.zapthink.com Páginas con información sobre agentes: Agents 101: agents.umbc.edu/introduction/ AgentLand: www.agentland.com
Más Información Peer-to-Peer y Grid Computing Workshop on Peer-to-peer http://www.lri.fr/~fci/GP2PC-04.htm Peer-to-Peer Working Group www.p2pwg.org SETI@home http://setiathome.ssl.berkeley.edu Distributed.net, Project RC5 www.distributed.net/rc5 Global Grid Forum www.gridforum.org Grid Computing Info Centre www.gridcomputing.com