La descarga está en progreso. Por favor, espere

La descarga está en progreso. Por favor, espere

Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 1 Tecnologías Web Jose Emilio Labra Gayo Departamento de Informática Universidad de.

Presentaciones similares


Presentación del tema: "Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 1 Tecnologías Web Jose Emilio Labra Gayo Departamento de Informática Universidad de."— Transcripción de la presentación:

1 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 1 Tecnologías Web Jose Emilio Labra Gayo Departamento de Informática Universidad de Oviedo

2 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 2 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

3 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 3 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

4 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 4 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,...

5 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 5 Arquitectura Cliente/Servidor Protocolo HTTP se basa en la arquitectura cliente/servidor (sin estado) Servidor Protocolo http Visualizador http:/1.0 200 OK Enlace a Otro http:/1.0 200 OK Enlace a Otro GET http://servidor.com/hola.html Cliente

6 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 6 Arquitectura Cliente/Servidor Computación dinámica 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 Cliente Servidor Base Datos Arquitectura de 3 capas

7 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 7 Arquitectura Cliente/Servidor Computación en cliente Etiqueta 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) Applets = código Java compilado (Java utiliza la máquina virtual JVM) Muchos visualizadores incluyen la JVM La etiqueta no se recomienda en HTML 4.0 (deprecated) Es preferible la utilización de Menor carga computacional en el servidor Menor carga en la red Dependencia capacidades del cliente Problema de seguridad para el cliente Valoración

8 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 8 Arquitectura cliente/servidor Computación en cliente La etiqueta 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. function onImg(name) {... } function offImg(name) {... } Se pueden combinar con los eventos de navegación y con los formularios Aplicaciones habituales: Modificar la presentación, validar entradas, etc.

9 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 9 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

10 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 10 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... 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 {... }

11 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 11 Componentes Distribuidos

12 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 12 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

13 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 13 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)

14 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 14 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

15 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 15 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

16 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 16 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...

17 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 17 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.

18 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 18 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 stub Red Objeto Distribuido skeleton interfaz remota interfaz remota

19 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 19 Arquitectura de Componentes Distribuidos Middleware explícito Cliente stub Red Objeto Distribuido skeleton Transacciones Persistencia Seguridad... Contenedor El Objeto distribuido se encarga de gestionar directamente los servicios del contenedor: transacciones, persistencia, seguridad, etc. Problema: Mayor complejidad en desarrollo de objeto distribuido interfaz remota interfaz remota

20 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 20 Arquitectura de Componentes Distribuidos Middleware implícito Cliente stub Red Objeto Distribuido skeleton interfaz remota Interceptor Transacciones Bases Datos Seguridad... Contenedor 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. interfaz remota

21 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 21 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) Cliente stub Red skeleton Interceptor Transacciones Bases Datos Seguridad... Contenedor Factoría crea Objeto Distribuido solicitud creación interfaz remota interfaz remota interfaz factoría

22 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 22 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.

23 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 23 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

24 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 24 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.

25 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 25 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...)

26 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 26 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: Publicador Suscriptor Tópico Suscriptor Publica y subscribe Emisor Cola Receptor Potencial Receptor Potencial Punto a Punto

27 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 27 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)

28 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 28 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

29 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 29 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.

30 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 30 Componentes Distribuidos: Caso particular: Enterprise Java Beans

31 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 31 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

32 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 32 Tipos de Beans EnterpriseBean EntityBean SessionBean MessageDrivenBean Stateless Stateful CMP BMP

33 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 33 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

34 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 34 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

35 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 35 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()

36 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 36 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 Servdor Aplicaciones (Contenedor) EJB MDB EJB Sesión EJB Sesión EJB Sesión EJB Entidad EJB Entidad JSP Servlet Aplicación Applet Cliente CORBA Cliente Mensaje Cliente HTML Socio Negocio Firewall SOAP WSDL UDDI Mensaje IIOP RMI-IIOP Servidor Web

37 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 37 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 Cliente stub Red skeleton Interceptor Transacciones Bases Datos Seguridad... Contenedor Factoría crea Objeto Distribuido solicitud creación interfaz remota interfaz remota interfaz factoría

38 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 38 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 Cliente stub Red skeleton EJBObject Transacciones Bases Datos Seguridad... Contenedor HomeObject crea Enterprise Bean solicitud creación interfaz remota interfaz remota interfaz Home

39 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 39 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)

40 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 40 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 Cliente stub Red skeleton EJBObject Transacciones Bases Datos Seguridad... Contenedor HomeObject crea Enterprise Bean solicitud creación interfaz remota interfaz remota interfaz Home

41 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 41 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

42 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 42 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 Cliente stub Red skeleton EJBObject Transacciones Bases Datos Seguridad... Contenedor HomeObject crea Enterprise Bean solicitud creación interfaz remota interfaz remota interfaz Home

43 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 43 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 Cliente stub Red skeleton EJBObject Transacciones Bases Datos Seguridad... Contenedor HomeObject crea Enterprise Bean solicitud creación interfaz remota interfaz remota interfaz Home

44 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 44 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

45 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 45 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

46 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 46 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) Cliente stub Red skeleton EJBObject Transacciones Bases Datos Seguridad... Contenedor HomeObject crea Enterprise Bean solicitud creación interfaz remota interfaz remota interfaz Home

47 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 47 Ejemplo de EJB de Sesión Interfaz del Componente 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 Necesario para que el contenedor implemente el EJBObject

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

49 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 49 Ejemplo de EJB de Sesión Objeto de Negocio 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); } } Implementación del método Bean de sesión Métodos que controlan el ciclo de vida (en este caso, no hacen nada)

50 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 50 Ejemplo de EJB de Sesión Descriptor de Despliegue (1) ejbSuma com.suma.ejbSuma.SumaHome com.suma.ejbSuma.Suma com.suma.ejbSuma.SumaBean Stateless Container... Declara las clases e interfaces del EJB Delega la gestión transaccional al contenedor Indica que es sin estado

51 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 51 Ejemplo de EJB de Sesión Descriptor de Despliegue (y 2) everyone everyone ejbSuma * ejbSuma * Required 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)

52 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 52 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

53 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 53 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

54 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 54 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...

55 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 55 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

56 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 56 Servicios Web

57 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 57 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 Antecedentes Intercambio de XML

58 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 58 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 RespuestaInternet URL

59 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 59 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

60 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 60 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

61 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 61 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

62 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 62 HTTP Servicios Web Principales VocabulariosUDDIregistra publica WSDL petición SOAP (XML) respuesta SOAP (XML) Implementación servicio Web encuentra obtiene WSDL Consumidor servicio Web

63 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 63 XSLT HTML Dispositivo del Cliente Servicio Web Base Datos SOAPXML XSLT WML XSLTVoiceXML Servicios Web Arquitectura de Aplicaciones

64 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 64 SOAP SOAP SOAP SOAP Internet Conversión de MonedasFacturación Gestión de Usuarios SOAP XML Aplicación del usuario Servicios Web Arquitectura de Aplicaciones

65 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 65 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 Evolución

66 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 66 Envelope Body Header Header Key SOAP Formato

67 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 67 urgente pepe@oviedo.es Cabecera familiar con mucho queso Contenido SOAP Ejemplo

68 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 68 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 Formato general

69 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 69 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 Header

70 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 70 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

71 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 71 soap:Receiver Error al procesar La pizza Barbacoa no puede llevar tanto queso SOAP Fault

72 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 72 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

73 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 73 234 familiar Tipos básicos SOAP Codificación

74 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 74 234 Barbacoa struct Pizza { int código; string nombre; }; Estructuras 234 Barbacoa 237 Barbacoa Arrays SOAP Codificación

75 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 75 Arrays parciales 234 Barbacoa 237 Barbacoa 234 Barbacoa 237 Barbacoa 5º y 6º elemento 2º y 5º elemento SOAP Codificación

76 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 76 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" 3 2 SOAP Ejemplo con HTTP

77 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 77 HTTP/1.1 200 OK Content-Type: text/xml; charset=utf-8 Content-Length: longitud del mensaje 5 SOAP Ejemplo de respuesta

78 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 78 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 Evolución

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

80 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 80 { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.es/1057007/3/slides/slide_79.jpg", "name": "Curso Doctorado:Universidad Pontificia de Salamanca (Jose E.", "description": "Labra) 80

81 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 81...... WSDL Ejemplo

82 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 82 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

83 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 83 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 tModel: Descripciones de especificaciones de servicios Binding contiene referencias a tModels. Estas referencias declaran las especificaciones del interfaz Binding contiene referencias a tModels. Estas referencias declaran las especificaciones del interfaz 0…n UDDI Definición

84 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 84 Servicios UDDI 2.El desarrollador registra y clasifica el servicio Web 3.El usuario pregunta a UDDI por servicios de conversión 4.El usuario determina el servicio de conversión más apropiado 5.El usuario construye una aplicación que consuma el servicio Web directamente SOAP 1.El desarrollador construye un servicio para convertir monedas servicio Web conversión UDDI Funcionamiento

85 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 85 Utilización de un Servicio Web Ejemplos Consltar listados de servicios Web www.xmethods.net www.bindingpoint.com Pueden ejecutarse

86 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 86 Utilización de servicios Web Ejemplos: Google

87 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 87 Utilización de servicios Web Ejemplos: Amazon

88 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 88 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 Posibilidades

89 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 89 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)

90 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 90 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

91 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 91 Implementación de Servicios Web Creación de un Cliente WSDL Descripción del servicio adaptador stubs clases Java generadas WSDL2Java código cliente javac cliente

92 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 92 Implementación de servicios Web Creación de un cliente http://petra.euitio.uniovi.es/~labra/ws/suma.php?wsdl 1.- Acceder a WSDL > java org.apache.axis.wsdl.WSDL2Java -p suma suma.wsdl 2.-Generar stubs Almacenar como suma.wsdl 3.- Comprobar clases generadas > ls suma/*.java ServicioSuma.java ServicioSumaLocator.java ServicioSumaBindingStub.java ServicioSumaPortType.java 4.- Compilar clases generadas > javac suma/*.java

93 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 93 Implementación de servicios Web Creación de un cliente 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 ClienteSuma.java

94 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 94 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 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); } ClienteTemp.java

95 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 95 Implementación de Servicios Web Creación de un Servicio Web Método simple: JWS public class Suma { public int suma(int a, int b) { return a + b; } Suma.jws Almacenar en: \webapps\axis\Suma.jws http://localhost:8080/axis/Suma.jws

96 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 96 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

97 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 97 Implementación de Servicios Web Creación de un Servicio Web 1.- Compilar servicio > javac ServSuma.java package ServSuma; public class ServSuma { public int suma(int a, int b){ return (a + b); } ServSuma.java 2.-Copiar ServSuma.class a /webapps/WEB-INF/classes/ServSuma/ServSuma.class También puede dejarse un.jar en WEB-INF/lib

98 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 98 Implementación de Servicios Web Creación de un Servicio Web deploy.wsdd 3.- Desplegar servicio > java org.apache.axis.client.AdminClient deploy.wsdd Processing file deploy.wsdd Done processing Puede ser necesario reiniciar servidor 4.- Acceder a http://localhost:8080/axis/services/ServSuma

99 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 99 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

100 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 100 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

101 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 101 Interoperabilidad Servicios Web en.NET

102 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 102 Interoperabilidad Servicios Web en.NET

103 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 103 Interoperabilidad Servicios Web en.NET

104 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 104 Interoperabilidad Servicios Web en PHP 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; } ?> suma.php

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

106 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 106 Arquitecturas Orientadas a Servicios Modelo tradicional Algoritmos IVA Algoritmos Envío Aplicación Compilación Datos IVA Aplicación Integrada Fuente datos envío Tiempo de construcción Tiempo de configuración Tiempo de ejecución

107 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 107 Arquitecturas Orientadas a Servicios Modelo Orientado a Servicios Aplicación Compilación servicio cálculo IVA Aplicación Integrada Tiempo de construcción Tiempo de ejecución servicio gastos envío

108 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 108 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

109 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 109 Servicios Web Retos 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.

110 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 110 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...

111 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 111 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

112 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 112 Otras Arquitecturas: Agentes Sistemas Colaborativos Peer-to-peer Grid computing

113 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 113 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

114 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 114 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

115 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 115 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

116 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 116 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?

117 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 117 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

118 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 118 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.

119 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 119 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. 1.informar/actualizar 3. transferencia 2. preguntar peers Servidor directorios

120 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 120 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

121 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 121 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 unirse pregunta

122 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 122 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.orgInfraestructura para grid computing

123 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 123 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...

124 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 124 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

125 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 125 Otros Sistemas Colaborativos Weblogs Sistemas de registro: Weblogs, Blogs, etc. Ejemplo de aplicación: http://allconsuming.net/

126 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 126 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

127 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 127 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

128 Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 128 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


Descargar ppt "Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 1 Tecnologías Web Jose Emilio Labra Gayo Departamento de Informática Universidad de."

Presentaciones similares


Anuncios Google