SOA y Web Services

14,136 views
13,858 views

Published on

Published in: Technology
0 Comments
23 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
14,136
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
17
Comments
0
Likes
23
Embeds 0
No embeds

No notes for slide
  • SOA define las siguientes capas de software: Aplicaciones básicas - Sistemas desarrollados bajo cualquier arquitectura o tecnología, geográficamente dispersos y bajo cualquier figura de propiedad; De exposición de funcionalidades - Donde las funcionalidades de la capa aplicativas son expuestas en forma de servicios (servicios web); De integración de servicios - Facilitan el intercambio de datos entre elementos de la capa aplicativa orientada a procesos empresariales internos o en colaboración; De composición de procesos - Que define el proceso en términos del negocio y sus necesidades, y que varía en función del negocio; De entrega - donde los servicios son desplegados a los usuarios finales.
  • The goal of the JAX-RPC project is to develop and evolve the code base for the Reference Implementation of JAX-RPC, the Java APIs for XML based RPC. The JAX-RPC specification is developed through the Java Community Process following the process described at jcp.org . This process involves an Expert Group with a lead that is responsible for delivering the specifications, reference implementations (RI) and Technology Compatibility kits (TCK). The primary goal of an RI is to support the development of the specification and to validate it. Specific RIs can have additional goals; the JAX-RPC RI is a production-quality implementation that is used directly in a number of products by Sun and other vendors. The JAX-RPC expert group has wide industry participation with Sun Microsystems as the EG lead. The initial specification (JAX-RPC 1.0) was JSR-101 and was released in June 2002. A maintenance release followed in October 2003 providing better integration with JAXB 1.0 as well as better support for doc/literal. The next version of the spec was renamed from JAX-RPC 2.0 to JAX-WS 2.0 and is being developed as JSR-224 ; this release will address a number of additional requirements in the area, and will increase the synergy between the JAXB and JAX-WS specifications. You can access the JAX-WS project page here . An implementation of the JAX-RPC 1.1 specification is included in the latest Java Web Services Developer Pack release, JWSDP 2.0 . However, with the release of Java Web Services Developer Pack 2.0 , you should start planning to move to the new, more modern, and easier-to-implement model of Web services provided in the integrated stack, the combination of JAX-WS 2.0 (which supplants JAX-RPC), JAXB 2.0 , and SAAJ 1.3. Even so, JAX-RPC implementations will continue to be available for a suitable length of time to support backward compatibility and orderly transitions from the Web services architecture in previous versions of Java WSDP and Java WSDP 2.0. If you are new to Web Services, it is strongly recommended that you use JAX-WS 2.0 instead of JAX-RPC. JAX-WS 2.0 comes with many new features not supported by JAX-RPC such as a new Dispatch interface which is much more powerful than the DII approach used by JAX-RPC. A big plus for JAX-WS is that it is included in the Mustang (Java SE 6) version of Java. This means that the size of client applications will be dramatically smaller. JAX-WS 2.0 is also part of the Glassfish project.
  • JSR101, Java APIs for XML-based RPC (JAX-RPC), provides APIs for invoking RPC-based Web Services over SOAP. It defines how interactions should take place and provides the basis for automated tools to produce stubs and skeletons. It also specifies type mapping and marshalling requirements between Java and SOAP/WSDL. JSR067, Java APIs for XML Messaging (JAXM), defines APIs for creating document-centric SOAP messages that can be exchanged either synchronously or asynchronously. Vendors can provide messaging profiles on top of this that offer value-added services, such as ebXML. JSR093, the Java API for XML Registries (JAXR), defines a two-tier API for accessing registry information stored in XML format. This is targeted at Web Service-related registries, such as UDDI registries and ebXML registry/repositories, as well as other generic XML registries.
  • Tipos de acceso Invocación mediante stub estático Invocación mediante Proxy dinámico Interfaz de invocación dinámica (DII)
  • Tipos de acceso Invocación mediante stub estático Invocación mediante Proxy dinámico Interfaz de invocación dinámica (DII)
  • Tipos de acceso Invocación mediante stub estático Invocación mediante Proxy dinámico Interfaz de invocación dinámica (DII)
  • Tipos de acceso Invocación mediante stub estático Invocación mediante Proxy dinámico Interfaz de invocación dinámica (DII)
  • Tipos de acceso Invocación mediante stub estático Invocación mediante Proxy dinámico Interfaz de invocación dinámica (DII)
  • SOA y Web Services

    1. 1. SOA y Web Services Óliver Centeno Álvarez Junio 2011Junio 2011 SOA y Web Services 1
    2. 2. Objetivos Conocer la arquitectura SOA, su función, ventajas y diseño Mostrar los lenguajes y protocolos implicados en la arquitectura SOA Mostrar una panorámica de las distintas aproximaciones tecnológicas a SOA Demostrar la creación y consumo de Web Services existentes mediante las tecnologías más extendidasJunio 2011 SOA y Web Services 2
    3. 3. Requisitos Conocimientos previos:  Experiencia en desarrollo con Java  Conocimientos de Arquitecturas o Ingeniería de Software Requisitos técnicos:  VirtualPC2007  Al menos 1GB de memoria RAM (recomendado 2GB)Junio 2011 SOA y Web Services 3
    4. 4. Contenidos I. Fundamentos II. Arquitectura SOA III. XML Web Services IV. Implementando XML Web Services V. RESTful Web Services VI. Interoperabilidad VII. Arquitectura ESBJunio 2011 SOA y Web Services 4
    5. 5. Contenidos I. Fundamentos II. Arquitectura SOA III. XML Web Services IV. Implementando XML Web Services V. RESTful Web Services VI. Interoperabilidad VII. Arquitectura ESBJunio 2011 SOA y Web Services 5
    6. 6. I. Fundamentos1. Motivación2. Arquitecturas de Software3. Necesidad del Contrato4. Modelado de Componentes5. RetosJunio 2011 SOA y Web Services 6
    7. 7. 1. Motivación Intercambio de información Procesamiento  Sinintervención del usuario  Acelerando tiempos de respuesta Normalización  Entre plataformas  Entre lenguajes  Entre sistemas operativosJunio 2011 SOA y Web Services 7
    8. 8. 1. Motivación Buenas prácticas  Reutilización  Modularidad y encapsulamiento Nuevos retos  Portabilidad  Interoperabilidad  Computación distribuida  InternetJunio 2011 SOA y Web Services 8
    9. 9. I. Fundamentos1. Motivación2. Arquitecturas de Software3. Necesidad del Contrato4. Modelado de Componentes5. RetosJunio 2011 SOA y Web Services 9
    10. 10. 2. Arquitecturas de Software Formas de organizar las partes que componen un sistema software  A nivel físico (cliente, servidor, consumidor,…)  A nivel lógico (capas, módulos, subsistemas,…) Permiten separar las partes que componen un sistema complejo de manera adecuada Aumenta la modularidad y la reutilización Aumenta el entendimiento del sistema Mejora el mantenimiento Mejora la validación y verificaciónJunio 2011 SOA y Web Services 10
    11. 11. 2. Arquitecturas de Software Evolución históricaJunio 2011 SOA y Web Services 11
    12. 12. 2. Arquitecturas de Software MVC  Modelo  Vista  Controlador  Utilizado en aplicaciones gráficas y WebJunio 2011 SOA y Web Services 12
    13. 13. 2. Arquitecturas de Software DAO y 3+1 capas  Separa el acceso a datos Presentación (DAO) de los datos (Modelo) M Negocio o  Permite utilizar el modelo en d todas las capas e  Permite reemplazar DAO sin Persistencia l o afectar al resto DAO BDJunio 2011 SOA y Web Services 13
    14. 14. I. Fundamentos1. Motivación2. Arquitecturas de Software3. Necesidad del Contrato4. Modelado de Componentes5. RetosJunio 2011 SOA y Web Services 14
    15. 15. 3. Necesidad del Contrato Las arquitecturas de software permiten estructurar un sistema Pero, ¿cómo se ensamblan las partes? Principio de desarrollo  Maximizar la cohesión  Minimizar el acoplamiento En otras palabras  Que cada parte sea autosuficiente  Y que dependa lo mínimo de las demás partesJunio 2011 SOA y Web Services 15
    16. 16. 3. Necesidad del Contrato Las arquitecturas no garantizan esto Necesitamos conceptualizar más cada parte Cuestiones:  El puerto USB sirve para muchas cosas pero…  ¿Cómo funciona un puerto USB?  ¿Cómo funciona un dispositivo USB?  ¿Por qué funciona un dispositivo USB?Junio 2011 SOA y Web Services 16
    17. 17. 3. Necesidad del Contrato Contrato (Especificación):  Acuerdo entre las partes para cumplir una serie de especificaciones enumeradas  Requisitos…  ¿Programación? Interfaz:  Conjunto de métodos especificados que debe proporcionar una clase de implementación  Importa el QUÉ y no el CÓMO  NO ES HERENCIA MÚLTIPLEJunio 2011 SOA y Web Services 17
    18. 18. 3. Necesidad del Contrato Programación Bajo Contrato  Definir siempre las interfaces de especificación de cada subsistema (interfaz proporcionada)  Implementar cada módulo utilizando las interfaces proporcionadas de los subsistemas asociados (interfaz requerida)  Se apoya en el polimorfismo: utilizar objetos que son a la vez de distintos tipos  Permite construir partes dependientes de otras sin que estas estén terminadasJunio 2011 SOA y Web Services 18
    19. 19. 3. Necesidad del Contrato Ejemplo: Interfaz public interface Tabla{ public void conectar(); public void desconectar(); public boolean insertar(); }  Importa poder conectar y desconectar  Importa poder insertar  No importa qué base de datos  No importa qué tabla ni qué columnasJunio 2011 SOA y Web Services 19
    20. 20. 3. Necesidad del Contrato Ejemplo: Lógica public class GestorBD{ private Tabla tabla; public GestorDB(Tabla t){ tabla = t; } public boolean añadir(){ tabla.conectar(); boolean resultado = tabla.insertar(); tabla.desconectar(); return resultado; } }Junio 2011 SOA y Web Services 20
    21. 21. 3. Necesidad del Contrato Ejemplo: Implementación public class TablaOracle implements Tabla{ public void conectar(){ … } public void desconectar() { … } public boolean insertar() { … } } public class Programa{ public static void main(String[] args){ Tabla t = new TablaOracle(); GestorDB g = new GestorDB(t); g.añadir(); } }Junio 2011 SOA y Web Services 21
    22. 22. I. Fundamentos1. Motivación2. Arquitecturas de Software3. Necesidad del Contrato4. Modelado de Componentes5. RetosJunio 2011 SOA y Web Services 22
    23. 23. 4. Modelado de Componentes Interfaz:  Colección de operaciones que especifican un servicio proporcionado (implementado) o solicitado (utilizado) por una clase o componente. Componente:  Parte lógica y reemplazable del sistema.  Conforma y proporciona la realización de un conjunto de interfaces.  Cumple los principios de modularidad y encapsulamiento.  Son bloques de construcción, “ladrillos”.Junio 2011 SOA y Web Services 23
    24. 24. 4. Modelado de Componentes Diagrama de Componentes  Ilustran las piezas del software, controladores embebidos, etc. que conformarán un sistema.  Con un nivel de abstracción más alto que un diagrama de clase.  Eventualmente un componente puede comprender una gran porción de un sistema.  Se descompone el sistema en base a interfaces que representan las líneas de separación entre subsistemas.Junio 2011 SOA y Web Services 24
    25. 25. 4. Modelado de Componentes Representación UML Componentes Componente componente Interfaz requerida Interfaz proporcionadaJunio 2011 SOA y Web Services 25
    26. 26. 4. Modelado de Componentes Ejemplo  Buscador de citas por Internet  Un Controlador requiere una interfaz Servicio para invocar a buscaAfines() y buscaIdeal()  Esta interfaz la implementa ServicioParejas que, a su vez requiere poder trabajar contra una Base de Datos PersonaDaoOracle Controlador ServicioParejas s : Servicio dao : DAO insertar() buscar() buscarAfines() actualizar() buscarIdeal() eliminar() buscar() DAO listar() Servicio insertar() actualizar() buscarAfines() eliminar() buscarIdeal() buscar() listar()Junio 2011 SOA y Web Services 26
    27. 27. 4. Modelado de Componentes Principios del desarrollo basado en componentes  Encapsulación e Interfaces:  Si un módulo cambia internamente sin modificar su interfaz, dicho cambio no provocará cambios en otras partes del sistema  Abstracción:  Un usuario del componente no necesita saber como esta implementado el modulo para comprender la funcionalidad ofertada  Arquitectura del sistema  Cómo se organizan los componentes  Conectividad entre componentes  Centra y prioriza las decisiones del desarrolloJunio 2011 SOA y Web Services 27
    28. 28. 4.Modelado de Componentes Veamos un EjemploJunio 2011 SOA y Web Services 28
    29. 29. I. Fundamentos1. Motivación2. Arquitecturas de Software3. Necesidad del Contrato4. Modelado de Componentes5. RetosJunio 2011 SOA y Web Services 29
    30. 30. 5. Retos Computación Distribuida  Poder realizar un conjunto de operaciones de cálculo de manera cooperativa entre varias máquinas  Las máquinas se conectan mediante una red  El resultado se compone a partir de los resultados parcialesJunio 2011 SOA y Web Services 30
    31. 31. 5. Retos Interoperabilidad  Poder comunicar máquinas distintas y software distinto para realizar computación distribuida  Poder invocar aplicaciones creadas para una plataforma desde otra totalmente distintaJunio 2011 SOA y Web Services 31
    32. 32. 5. Retos Integración  De datos, de aplicaciones, de componentes, de negocio (EAI)  Síncrona o asíncrona  Mediante sockets, RPC, RMI, colas, DCOM, ETL, …  ¿Sistemas heredados?Junio 2011 SOA y Web Services 32
    33. 33. 5. Retos Computación en Internet  Poder llevar los conceptos de computación distribuida a Internet  Aplicando medidas de seguridad pertinentes  Atravesando cortafuegos  Utilizando estándares de factoJunio 2011 SOA y Web Services 33
    34. 34. Contenidos I. Fundamentos II. Arquitectura SOA III. XML Web Services IV. Implementando XML Web Services V. RESTful Web Services VI. Interoperabilidad VII. Arquitectura ESBJunio 2011 SOA y Web Services 34
    35. 35. II. Arquitectura SOA1. Tecnologías de Integración2. Problemas3. ¿Qué es SOA?4. Servicios, Web Services y SOA5. Ejemplos de AplicaciónJunio 2011 SOA y Web Services 35
    36. 36. 1. Tecnologías de Integración Existen muchas propuestas para integrar aplicaciones distribuidas Objetivo:  Comunicar máquinas remotas  Ejecutar tareas de manera cooperativa  Integrar sistemas heterogéneos  Integrar aplicaciones “legadas” Distinciones:  Caso de Aplicaciones compatibles (homogéneas)  Caso de Aplicaciones incompatibles (heterogéneas)Junio 2011 SOA y Web Services 36
    37. 37. 1. Tecnologías de Integración DCOM  Distributed Component Object Model  Tecnología de Microsoft para programación con objetos distribuidos  Problema: Sólo disponible para Windows lo que limita la interoperabilidad Java RMI  Remote Method Invocation  Distribución de objetos “Java-to-Java”  Problema: No es independiente del lenguaje ya que exige utilizar JavaJunio 2011 SOA y Web Services 37
    38. 38. 1. Tecnologías de Integración CORBA  Common Object Request Broker Architecture by OMG  Estándar para comunicar objetos distribuidos independiente del lenguaje utilizado  Problema: hay problemas de interoperabilidad porque no garantiza que los participantes implementen la especificación completa RMI sobre IIOP  Java RMI que utilizar IIOP de CORBA para la comunicación  Utilizado para acceder a EJBs (Enterprise JavaBeans)  Problema: Depende de CORBA para la comunicación y de Java para la implementaciónJunio 2011 SOA y Web Services 38
    39. 39. II. Arquitectura SOA1. Tecnologías de Integración2. Problemas3. ¿Qué es SOA?4. Servicios, Web Services y SOA5. Ejemplos de AplicaciónJunio 2011 SOA y Web Services 39
    40. 40. 2. Problemas Rendimiento y escalabilidad Gestión Cumplir la falta de acoplamiento Transaccionalidad, seguridad, estado Conversión de protocolos Versionado Firewalls y otros elementos de seguridad Ancho de banda Evaluación de la causa raíz de los problemas Coste de desarrollo, integración y pruebasJunio 2011 SOA y Web Services 40
    41. 41. II. Arquitectura SOA1. Tecnologías de Integración2. Problemas3. ¿Qué es SOA?4. Servicios, Web Services y SOA5. Ejemplos de AplicaciónJunio 2011 SOA y Web Services 41
    42. 42. 3. ¿Qué es SOA? Arquitectura Orientada a Servicios N-capas Importa el servicio ofrecido Cliente Seguridad Gestión Cliente Servidor Cliente ValidaciónJunio 2011 SOA y Web Services 42
    43. 43. 3. ¿Qué es SOA? Arquitectura que utiliza servicios como bloques de construcción para facilitar la integración y reutilización de componentes empresariales a través de un bajo acoplamiento ¿Cómo?  Utilizar servicios para implementar las capas  Los servicios NO SON LIBRERÍAS pero se parecen  Tienen funcionalidad pero esperan a ser invocados  No importa el lenguaje de programación ni el entorno, sólo que cumplan con su cometidoJunio 2011 SOA y Web Services 43
    44. 44. 3. ¿Qué es SOA? Ventajas  Aprovecha los estándares abiertos para representar los servicios  Permite ver los servicios como bloques de construcción que pueden ser reutilizados en el desarrollo de otros aplicaciones  Permite centrarse en ensamblar bloques en vez de en los detalles de implementación  Se puede utilizar internamente para crear nuevas aplicaciones a partir de componentes existentes  Puede utilizarse externamente al integrarse con las aplicaciones fuera de la empresaJunio 2011 SOA y Web Services 44
    45. 45. 3. ¿Qué es SOA? Terminología utilizada en SOA  Servicio  Funcionalidad publicada  Orquestación y coreografía  Coordinación de servicios para implementar una lógica determinada  En la orquestación hay un director, en la coreografía no  Sin estado  Los servicios no dependen unos de otros y se pueden orquestar de distintas maneras  Proveedor  ConsumidorJunio 2011 SOA y Web Services 45
    46. 46. 3. ¿Qué es SOA? Exige un cambio de mentalidad  Los servicios NO SON LIBRERÍAS  NO SIRVEN PARA TODO  NO SON RÁPIDOS  ESTÁN PENSADOS PARA SISTEMAS HOMOGÉNEOS Servicios poco acoplados pero altamente interoperables Basados en una definición independiente de plataforma Alta reusabilidad Poco sensible a cambios Permite modelos de  Consumo de terceros  Colaboración  Integración de tecnologíasJunio 2011 SOA y Web Services 46
    47. 47. 3. ¿Qué es SOA? Ciclo de Vida de SOA  Modelado  Capturar, analizar, simular y optimizar modelos  Reducir el riesgo y aumentar la flexibilidad  Ensamblado  De componentes nuevos y antiguos  Para ejecutar y gestionar procesos de negocio  Despliegue  Gestión  Análisis de la información de negocio derivada  Para tomar acciones coordinadas y “a tiempo”Junio 2011 SOA y Web Services 47
    48. 48. 3. ¿Qué es SOA? Capas SOA  Aplicaciones básicas (SD)  Sistemas geográficamente dispersos  Exposición de funcionalidad (WS)  Como Web Service para su consumo  Integración de servicios (ESB)  Facilitando el intercambio de datos empresariales  Composición de procesos (BPM)  Modelando un proceso en términos del negocio y sus necesidades  Entrega  Desplegando los servicios para el usuario finalJunio 2011 SOA y Web Services 48
    49. 49. II. Arquitectura SOA1. Tecnologías de Integración2. Problemas3. ¿Qué es SOA?4. Servicios, Web Services y SOA5. Ejemplos de AplicaciónJunio 2011 SOA y Web Services 49
    50. 50. 4. Servicios, Web Services y SOA Servicio  Funcionalidad empaquetada como un componente reutilizable en procesos de negocio  Expuesto mediante una interfaz bien definida  Que aparece como una función autocontenida  Que utiliza mensajes para ocultar la implementación  Por tanto no importa cómo se ha desarrollado  Que no depende del estado de otros servicios  Que proporciona información o realiza modificaciones en los datos de negocioJunio 2011 SOA y Web Services 50
    51. 51. 4. Servicios, Web Services y SOA XML Web Service  Servicio identificado por una URI  Definido, descrito y descubierto mediante XML  Que utiliza XML como soporte de sus mensajes  Cuyos protocolos de mensajes están basados en Internet  Que no almacena estado RESTful WebService  Servicio identificado por una URI  Cuyos protocolos de mensajes están basados en Internet  Que no almacena estadoJunio 2011 SOA y Web Services 51
    52. 52. 4. Servicios, Web Services y SOA SOA es una arquitectura basada en servicios Se centra en la disposición de los servicios al crear aplicaciones Los Web Services son un caso particular de servicio  Pueden utilizarse para crear una SOA  Pero no tiene estado  Cada petición debe ser autocontenida  No podemos valernos de la información del servidor  No podemos utilizar variables de sesión  No debemos utilizar cookiesJunio 2011 SOA y Web Services 52
    53. 53. II. Arquitectura SOA1. Tecnologías de Integración2. Problemas3. ¿Qué es SOA?4. Servicios, Web Services y SOA5. Ejemplos de AplicaciónJunio 2011 SOA y Web Services 53
    54. 54. 5. Ejemplos de Aplicación Transporte  Ofertar precios realistas se hace difícil cuando los envíos viajan a través de múltiples operadores Banca  Necesidad de proporcionar servicios bancarios a múltiples clientes  Necesidad de integrar un gran número de aplicaciones internas Gobierno  Necesita compartir y acceder a datos a través de distintas agencias Internet  Necesidad de realizar búsquedas rápidas de distintos contenidosJunio 2011 SOA y Web Services 54
    55. 55. 5. Ejemplos de Aplicación Interoperabilidad entre sistemas heterogéneos Interacciones B2B La encapsulación de los sistemas heredados Aislamiento de la evolución de los sistemas Empresa normalización de los servicios Integración de paquetes de terceros Coordinación de procesos Desarrollo de portalesJunio 2011 SOA y Web Services 55
    56. 56. Contenidos I. Fundamentos II. Arquitectura SOA III. XML Web Services IV. Implementando XML Web Services V. RESTful Web Services VI. Interoperabilidad VII. Arquitectura ESBJunio 2011 SOA y Web Services 56
    57. 57. III.XML Web Services1. Definiciones2. El protocolo SOAP3. Documentos WSDL4. Registros UDDIJunio 2011 SOA y Web Services 57
    58. 58. 1. Definiciones ¿Qué es un Servicio Web?  Según Wikipedia: “… es un conjunto de protocolos y estándares que sirven para intercambiar datos entre aplicaciones.”  De otra forma: “A través de una interfaz estándar … permite el funcionamiento de una serie de sistemas heterogéneos como un conjunto integrado.”  Simplificando: “Cada uno de los componentes de un sistema diseñado para soportar interoperabilidad entre máquinas sobre Internet.”Junio 2011 SOA y Web Services 58
    59. 59. 1. Definiciones ¿Qué es un Servicio Web XML?  Según Microsoft: “… es una entidad programable que proporciona un elemento de funcionalidad determinado, como lógica de aplicación … (accesible) mediante estándares de Internet … como XML y HTTP.”  Según Sun: “… es un componente software con las siguientes características: 1) Es accesible a través del interfaz SOAP, 2) Su interfaz se describe en un documento WSDL.”Junio 2011 SOA y Web Services 59
    60. 60. 1. Definiciones Simplificando más:  Interfazaccesible a través de Internet  Alojada en un Servidor Web  Que permite invocación remota de procesos  Autocontenido, Autodescrito, Modular e Independiente de Plataforma  Estándares (XML, SOAP, HTTP)  Modelo de ProxyJunio 2011 SOA y Web Services 60
    61. 61. 1. Definiciones Fundamentos:  Intercambio de información  Normalización  Entre plataformas  Entre lenguajes  Entre sistemas operativos Escenarios:  Simple  Publicación de información  Integración de Aplicaciones  Permite realizar tareas remotas  Soluciones de Flujo de Trabajo (Workflow)  Integrados con BizTalk, Sun ONE, ServiceMix,…Junio 2011 SOA y Web Services 61
    62. 62. 1. Definiciones Modelo de Proxy:  Componentes ubicados en servidores diferentes que deben comunicarse de manera transparente.  Un Proxy “se hace pasar por el objeto remoto”  El objeto cliente usa el Proxy como si no hubiera una red Objeto Objeto Cliente referencia remota Remoto Proxy Referencia Remota RED TCPJunio 2011 SOA y Web Services 62
    63. 63. 1. Definiciones InfraestructuraJunio 2011 SOA y Web Services 63
    64. 64. 1. Definiciones Estándares:  XML  XSD  HTTP  SOAP  WSDL  UDDIJunio 2011 SOA y Web Services 64
    65. 65. III.XML Web Services1. Definiciones2. El protocolo SOAP3. Documentos WSDL4. Registros UDDIJunio 2011 SOA y Web Services 65
    66. 66. 2. El protocolo SOAP Simple Object Access Protocol  Invocación remota basada en XML  Mensaje estructurado en XML con posibilidad de implementar múltiples formatos, seguridad etc.  Microsoft (1.0), IBM (1.1), Sun  Contiene llamadas y respuestas de procedimientos  Trata de sustituir a formatos propietarioJunio 2011 SOA y Web Services 66
    67. 67. 2. El protocolo SOAP SOAP Message  Un mensaje SOAP es un elemento Envelope con una cabecera opcional y un cuerpo obligatorio <soap:Envelope> <soap:Header> ... </soap:Header> <soap:Body> <metodo> <x xsi:type="xsd:int">5</x> <y xsi:type="xsd:float">5.0</y> </metodo> </soap:Body> </soap:Envelope>Junio 2011 SOA y Web Services 67
    68. 68. 2. El protocolo SOAP SOAP Message  Mensaje de Respuesta <soap:Envelope> <soap:Header> ... </soap:Header> <soap:Body> <metodoResponse> <metodoReturn> El producto es 25.0 </metodoReturn> </ metodoResponse> </soap:Body> </soap:Envelope>Junio 2011 SOA y Web Services 68
    69. 69. 2. El protocolo SOAP Permite separar meta-información del mensaje  Información de enrutado  Información de expiración  … Define  Un modelo de proceso  Un mecanismo para manejar errores  Un mecanismo para representar datos  Un convenio para RPC  Un marco para vincular protocolosJunio 2011 SOA y Web Services 69
    70. 70. 2. El protocolo SOAP Ventajas:  XML plano --> ubicuidad de componentes  Comunicación HTTP --> no cortafuegos  IPSec o SSL proporcionan seguridad  Escalable a conjuntos de servidoresJunio 2011 SOA y Web Services 70
    71. 71. 2. El protocolo SOAP Motores SOAP  Framework que se utiliza en servidores y clientes para facilitar  La serialización de objetos a SOAP  La deserialización de mensajes SOAP a objetos  La validación de la estructura de los mensajes  SOAPpy  Implementado en Python y AxisJunio 2011 SOA y Web Services 71
    72. 72. 2. El protocolo SOAP Motores SOAPJunio 2011 SOA y Web Services 72
    73. 73. 2. El protocolo SOAP Mensajes de error  SOAP Fault XML <Fault>  <faultcode> ID del error  <faultstring> Descripción breve  <detail> Detalles del errorJunio 2011 SOA y Web Services 73
    74. 74. III.XML Web Services1. Definiciones2. El protocolo SOAP3. Documentos WSDL4. Registros UDDIJunio 2011 SOA y Web Services 74
    75. 75. 3. Documentos WSDL Web Services Description Language  Lenguaje de descripción del Servicio Web  Describir interfaces de Servicios Web  Independiente de la implementación  Métodos disponibles, parámetros y retorno  Mapeado a SOAP de manera unívocaJunio 2011 SOA y Web Services 75
    76. 76. 3. Documentos WSDL Web Services Description Language  Define una o varias operaciones  Incluyendo los mensajes que reciben  Y los mensajes que devuelven  Descritasde forma abstracta  Concretadas en el endpoint  Protocolo  Formato de mensaje  Dirección de RedJunio 2011 SOA y Web Services 76
    77. 77. 3. Documentos WSDL<definitions>  Web Services Description Language <types/>  types: Declaraciones de tipos de dato <message/> habitualmente en XSD <part/>  message: Definición abstracta de mensajes y sus </message> tipos de dato (part) <portType>  portType: Operaciones soportadas por el servicio <operation/> y los mensajes que se les envía y/o recibe </portType> (operation) <binding/>  binding: Formato de mensaje y protocolo que se <service> debe utilizar para invocar las operaciones <port/>  service: Colección de endpoints cada uno </service> representado por un puerto en una dirección de red y con un nombre de binding </definitions>Junio 2011 SOA y Web Services 77
    78. 78. 3. Documentos WSDL Veamos unos documentos WSDLJunio 2011 SOA y Web Services 78
    79. 79. III.XML Web Services1. Definiciones2. El protocolo SOAP3. Documentos WSDL4. Registros UDDIJunio 2011 SOA y Web Services 79
    80. 80. 4. Registros UDDI Universal Description, Discovery & Integration Catálogo de negocios de Internet  Páginas amarillas  Páginas blancas  Páginas verdes Accedido por mensajes SOAP para obtener documentos WSDLJunio 2011 SOA y Web Services 80
    81. 81. 4. Registros UDDI Universal Description, Discovery & Integration  Mecanismo de descubrimiento de Servicios Web disponibles  Publicación de Servicios Web  Descubrimiento de ServiciosJunio 2011 SOA y Web Services 81
    82. 82. Contenidos I. Fundamentos II. Arquitectura SOA III. XML Web Services IV. Implementando XML Web Services V. RESTful Web Services VI. Interoperabilidad VII. Arquitectura ESBJunio 2011 SOA y Web Services 82
    83. 83. IV. Implementando XML Web Services1. Tecnologías J2EE para WS2. Apache AXIS3. Creación de WS en Java4. Creación de WS en .Net5. Publicación de Web Services6. Consumo de Web ServicesJunio 2011 SOA y Web Services 83
    84. 84. 1. Tecnologías J2EE para WS El API SAAJ  SOAP with Attachments API for Java  Se emplea para escribir mesajes SOAP directamente en lugar de utilizar un generador  Permite escribir y leer mensajes SOAP  Algunas implementaciones permiten enviar y recibir mensajes SOAP  Paquete: javax.xml.soapJunio 2011 SOA y Web Services 84
    85. 85. 1. Tecnologías J2EE para WS El API SAAJ sin archivos vinculados  SOAPMessage <Message>  SOAPPart <Part>  SOAPEnvelope <Envelope>  SOAPHeader <Header>  SOAPBody <Body>  Se generan con el SOAPMessageJunio 2011 SOA y Web Services 85
    86. 86. 1. Tecnologías J2EE para WS El API SAAJ sin archivos vinculadosJunio 2011 SOA y Web Services 86
    87. 87. 1. Tecnologías J2EE para WS El API SAAJ con archivos vinculados  AttachmentPart  Hay que crearlos a mano  Debe contener una cabecera MIME  Tipo de contenido  Opcionalmente tendrá contenidoJunio 2011 SOA y Web Services 87
    88. 88. 1. Tecnologías J2EE para WS El API SAAJ con archivos vinculadosJunio 2011 SOA y Web Services 88
    89. 89. 1. Tecnologías J2EE para WS El API SAAJ. Conexión SOAPConnectionFactory factory = SOAPConnectionFactory.newInstance(); SOAPConnection conexion = factory.createConnection(); //Crear un mensaje SOAP de request java.net.URL endpoint = new URL("http: //..."); SOAPMessage respuesta = conexion.call (request, endpoint);Junio 2011 SOA y Web Services 89
    90. 90. 1. Tecnologías J2EE para WS El API SAAJ. Acceder al contenido SOAPBody cuerpo = respuesta.getSOAPBody(); //Lectura del cuerpo for(SOAPBodyElement elemento : cuerpo. getChildElements(Name)){ String valor = elemento.getValue(); } //Modificación del cuerpo SOAPBodyElement docElement = cuerpo. addDocument(documento);Junio 2011 SOA y Web Services 90
    91. 91. 1. Tecnologías J2EE para WS El API SAAJ. Attachments //Crear y añadir AttachmentPart adjuntos = message. createAttachmentPart(); adjuntos.setContent("texto", "text/plain"); adjuntos.setContentId("id"); message.addAttachmentPart(adjuntos); //acceder a contenidos for(AttachmentPart att : message.getAttachments()){ String id = att.getContentId(); String type = att.getContentType(); Object content = att.getContent(); }Junio 2011 SOA y Web Services 91
    92. 92. 1. Tecnologías J2EE para WS El API JAX-RPC  Java API for XML-Based RPC  Permite construir aplicaciones y Servicios Web con funcionalidades RPC basadas en XML  Cumple la especificación SOAP 1.1  JAX-RPC 2.0 ha sido renombrado a JAX-WS 2.0 https://jax-rpc.dev.java.net/Junio 2011 SOA y Web Services 92
    93. 93. 1. Tecnologías J2EE para WS El API JAX-RPCJunio 2011 SOA y Web Services 93
    94. 94. 1. Tecnologías J2EE para WS El API JAX-WS  Tecnología Java para construir clientes y Servicios Web basados en XML  Orientados a mensajes  Orientados a RPC  Oculta la complejidad de SOAP  Se crea un objeto Proxy que invoca a los métodos del Servicio  Se requiere la anotación javax.jws.WebService para que la clase se comporte como WS  Se habla de endpoint del WSJunio 2011 SOA y Web Services 94
    95. 95. 1. Tecnologías J2EE para WS JAX-WS Endpoint  Un endpoint requiere:  javax.jws.WebService/WebServiceProvider  @WebService  No admite métodos finales ni estáticos  javax.jws.WebMethod  Parámetros compatibles con JAXB  Clase no abstracta ni final  Con un constructor público por defecto  Sin destructor (finalize)Junio 2011 SOA y Web Services 95
    96. 96. 1. Tecnologías J2EE para WS El API JAX-WSJunio 2011 SOA y Web Services 96
    97. 97. 1. Tecnologías J2EE para WS JAX-WS Endpoint import javax.jws.WebService; @WebService() public class Hello { private String message = new String(“Hola, "); public Hello() {} @WebMethod() public String sayHello(String name) { return message + name + "."; } }Junio 2011 SOA y Web Services 97
    98. 98. 1. Tecnologías J2EE para WS JAX-WS Client  Un cliente requiere:  javax.xml.ws.WebServiceRef  @WebServiceRef(wsdlLocation="http://...")  Un campo estático que referencie el servicio static HelloService service;  Un proxy al servicio con el que trabajar Hello port = service.getHelloPort();  Utilizar el proxy para invocar métodos String response = port.sayHello(name);Junio 2011 SOA y Web Services 98
    99. 99. 1. Tecnologías J2EE para WS JAX-WS Client import javax.jws.WebServiceRef; public class HelloClient { @WebServiceRef(wsdlLocation = "http://localhost: 8080/helloservice/hello?wsdl") static HelloService servicio; public static void main(String[] args) { Hello puerto = servicio.getHelloPort(); String respuesta = puerto.sayHello(args[0]); System.out.println(respuesta); } }Junio 2011 SOA y Web Services 99
    100. 100. 1. Tecnologías J2EE para WS JAXR (Java API for XML Registries)  Permite acceder a registros de negocio basados en UDDI y otros (ebXML)  https://jaxr.dev.java.net/  Proyecto privado  Requiere hacerse miembro para consultarlo  Se incluye en el proyecto GlassFish com.sun.connector.jaxr javax.xml.registryJunio 2011 SOA y Web Services 100
    101. 101. IV. Implementando XML Web Services1. Tecnologías J2EE para WS2. Apache AXIS3. Creación de WS en Java4. Creación de WS en .Net5. Publicación de Web Services6. Consumo de Web ServicesJunio 2011 SOA y Web Services 101
    102. 102. 2. Apache AXIS Librerías que permiten ejecutar Servicios Web Servlet para desplegar y replegar servicios Libreria WSDL.jar general el WSDL de Servicios  Parámetros de entrada/salida y métodos a invocar http://ws.apache.org/axis/ org.apache.axis.clientJunio 2011 SOA y Web Services 102
    103. 103. 2. Apache AXIS Cliente y Servidor SOAP open source Implementa el API JAX-RPC 2006 v1.4 Final Axis2 implementa JAX-WS Se utiliza con el servidor Tomcat Posible desplegarlo en otros  WebLogic  GlassFishJunio 2011 SOA y Web Services 103
    104. 104. 2. Apache AXIS Desplegar un Servicio manualmente  Copiar el .class del Servicio en la carpeta classes dentro de Axis  Copiar el .java del Servicio con extensión .jws en la raíz del Axis desplegado  Para que se genere el WSDLJunio 2011 SOA y Web Services 104
    105. 105. 2. Apache AXIS Desplegar un Servicio por línea de comandos  Fichero .wsdd describe el Servicio  XML específico de AXIS  Desde el directorio ejecutarjava -cp %AXISCLASSPATH% org.apache.axis.client. AdminClient -lhttp://localhost:8080/axis/services/AdminService deploy.wsddJunio 2011 SOA y Web Services 105
    106. 106. 2. Apache AXIS WSDL2Java  Aplicación Java que genera clases a partir de un documento WSDL  Para cada <port> genera una clase Proxy  Para cada <portType> una interfaz (SEI)  Para cada <binding> un stub que implementa el SEI  Para cada <service> una interfaz de servicio y su implementación para localizar el proxyjava org.apache.axis.wsdl.WSDL2Java “fichero-WSDL”Junio 2011 SOA y Web Services 106
    107. 107. 2. Apache AXIS Java2WSDL  Aplicación Java que genera clases a partir de un documento WSDL  java org.apache.axis.wsdl.Java2WSDL -o “fichero-WSDL” -l“url del servicio” -n <espacio de nombres> -p “package” “namespace” “fichero-CLASS”Junio 2011 SOA y Web Services 107
    108. 108. 2. Apache AXIS Consumir un Servicio con AXISimport org.apache.axis.client.Call;import org.apache.axis.client.Service;import javax.xml.namespace.QName;public class TestClient{ public static void main(String [] args) { String endpoint = "http://nagoya.apache.org:5049/axis/services/echo"; Service service = new Service(); Call call = (Call) service.createCall(); call.setTargetEndpointAddress(new java.net.URL(endpoint)); call.setOperationName(new QName("http://soapinterop.org/", "echoString") ); String ret = (String) call.invoke( new Object[] { "Hello!" } ); System.out.println("Sent Hello!, got " + ret + ""); }}Junio 2011 SOA y Web Services 108
    109. 109. IV. Implementando XML Web Services1. Tecnologías J2EE para WS2. Apache AXIS3. Creación de WS en Java4. Creación de WS en .Net5. Publicación de Web Services6. Consumo de Web ServicesJunio 2011 SOA y Web Services 109
    110. 110. 3. Creación de WS en Java En Eclipse desde un JavaBeanJunio 2011 SOA y Web Services 110
    111. 111. 3. Creación de WS en JavaJunio 2011 SOA y Web Services 111
    112. 112. 3. Creación de WS en JavaJunio 2011 SOA y Web Services 112
    113. 113. 3. Creación de WS en Java Contenido generado:  Librerías jar  Servlet en web.xml  Fichero wsdl  Ficheros wsdd de AXISJunio 2011 SOA y Web Services 113
    114. 114. 3. Creación de WS en Java Probando el Web Service  Botón derecho en el WSDL  Web Services > Test with Web Services Explorer  Permite configurar múltiples endpoints  Incluye una ventana de estado que muestra los mensajes SOAP  Permite probar el WSDL sin necesidad de nada másJunio 2011 SOA y Web Services 114
    115. 115. 3. Creación de WS en JavaJunio 2011 SOA y Web Services 115
    116. 116. 3. Creación de WS en Java En JDeveloper desde un JavaBeanJunio 2011 SOA y Web Services 116
    117. 117. 3. Creación de WS en JavaJunio 2011 SOA y Web Services 117
    118. 118. IV. Implementando XML Web Services1. Tecnologías J2EE para WS2. Apache AXIS3. Creación de WS en Java4. Creación de WS en .Net5. Publicación de Web Services6. Consumo de Web ServicesJunio 2011 SOA y Web Services 118
    119. 119. 4. Creación de WS en .NetJunio 2011 SOA y Web Services 119
    120. 120. 4. Creación de WS en .Net Tipo especial de clase  Extensión ASMX (Visual Studio 2005)  WCF Web Service (Visual Studio 2010) Los métodos a publicar se marcan con el atributo WebMethod VB <WebMethod()> _ Public Function TraerDatos() As String[] End Function C# [WebMethod] public String[] TraerDatos(){ }Junio 2011 SOA y Web Services 120
    121. 121. 4. Creación de WS en .Net Fichero .asmx indica que es un servicio Web <%@ WebService Language = "C#" CodeBehind = "~/App_Code/Service.cs" Class = "Service" %> Código en /App_Code/Service.cs public class Service : System.Web.Services. WebService{ public Service () { } [WebMethod] public string HelloWorld() { return "Hola a todos"; } }Junio 2011 SOA y Web Services 121
    122. 122. 4. Creación de WS en .Net [WebService(Namespace = "http://...")]  Indica el espacio de nombres del servicio  Distinto del namespace de C#  Describe el servicio para el descubridor UDDI WebService(Namespace=“...”, Description=“…”)] [WebMethod(Description = "…")]  Delantede la declaración de los métodos  Parámetros como siempreJunio 2011 SOA y Web Services 122
    123. 123. IV. Implementando XML Web Services1. Tecnologías J2EE para WS2. Apache AXIS3. Creación de WS en Java4. Creación de WS en .Net5. Publicación de Web Services6. Consumo de Web ServicesJunio 2011 SOA y Web Services 123
    124. 124. 5. Publicación de Web Services En JDeveloperJunio 2011 SOA y Web Services 124
    125. 125. 5. Publicación de Web Services Creado desde Visual Studio, sólo es necesario publicarlo como un sitio Web Usando las herramientas de publicación de VS2005  http  ftp  Front Page Server Extensions ¡Copiar y pegar!Junio 2011 SOA y Web Services 125
    126. 126. 5. Publicación de Web Services Manualmente: 1. Alojar el servicio en un servidor local (IIS)  Publicando el servicio en una carpeta 2. Activar el servidor Web  Indicando el directorio local con el servicio  Añadirlo a IIS (*) 3. Añadir una referencia Web al proyecto 4. ConsumirJunio 2011 SOA y Web Services 126
    127. 127. 5. Publicación de Web ServicesJunio 2011 SOA y Web Services 127
    128. 128. 5. Publicación de Web ServicesJunio 2011 SOA y Web Services 128
    129. 129. 5. Publicación de Web ServicesJunio 2011 SOA y Web Services 129
    130. 130. IV. Implementando XML Web Services1. Tecnologías J2EE para WS2. Apache AXIS3. Creación de WS en Java4. Creación de WS en .Net5. Publicación de Web Services6. Consumo de Web ServicesJunio 2011 SOA y Web Services 130
    131. 131. 6. Consumo de Web Services En JDeveloperJunio 2011 SOA y Web Services 131
    132. 132. 6. Consumo de Web ServicesJunio 2011 SOA y Web Services 132
    133. 133. 6. Consumo de Web ServicesJunio 2011 SOA y Web Services 133
    134. 134. 6. Consumo de Web ServicesJunio 2011 SOA y Web Services 134
    135. 135. 6. Consumo de Web ServicesJunio 2011 SOA y Web Services 135
    136. 136. 6. Consumo de Web Services En .Net  Crearun proyecto  Botón derecho > “Agregar Referencia Web”…  Buscándolo por UDDI  Utilizando el vínculo al WSDL  Llamando al Servicio Web con ?wsdl  Explorando los Servicios de la Solución  Explorando los Servicios de la máquina localJunio 2011 SOA y Web Services 136
    137. 137. 6. Consumo de Web ServicesJunio 2011 SOA y Web Services 137
    138. 138. 6. Consumo de Web ServicesJunio 2011 SOA y Web Services 138
    139. 139. 6. Consumo de Web Serviceslocalhost.Externos objeto;Junio 2011 SOA y Web Services 139
    140. 140. Contenidos I. Fundamentos II. Arquitectura SOA III. XML Web Services IV. Implementando XML Web Services V. RESTful Web Services VI. Interoperabilidad VII. Arquitectura ESBJunio 2011 SOA y Web Services 140
    141. 141. V. RESTful Web Services1. Introducción a los Servicios REST2. Comparativa con SOAP3. Implementación de Servicios RESTJunio 2011 SOA y Web Services 141
    142. 142. V. RESTful Web Services1. Introducción a los Servicios REST2. Comparativa con SOAP3. Implementación de Servicios RESTJunio 2011 SOA y Web Services 142
    143. 143. 1. Introducción a los Servicios REST REpresentational State Transfer Tesis de Roy T. Fielding (2000)  Coautorde los estándares HTTP y URI  Cofundador de Apache Se han empezado a utilizar porque  Los Servicios XML son complicados  Requieren mucha infraestructura lógica  Al final vamos a utilizar HTTP  Simplificar el modeloJunio 2011 SOA y Web Services 143
    144. 144. 1. Introducción a los Servicios REST Principios de REST  No tienen estado  Tienen una interfaz uniforme  No hay WSDL pero se usan los verbos HTTP  POST, GET, PUT, DELETE,…  Se basa en la representación de recursos  URI + Secuencia de bytes + tipo MIME (txt, xml, json, jpeg,…)  http://localhost/clientes  http://localhost/clientes/1234  http://localhost/pedidos/567/cliente  Los mensajes están autodescritos  HATEOS (Hypermedia As The Engine Of application State)Junio 2011 SOA y Web Services 144
    145. 145. 1. Introducción a los Servicios REST HATEOS  Cada respuesta del servidor debe contener todas las URI que permitan llevar a un siguiente paso  Todas las posibles transiciones de estado que pueda realizar el usuario desde el estado actual se representan mediante URI  Si no lo cumple no es un servicio RESTful  No es necesario almacenar el estado en variables de sesión ni en cookies  Se identifican los recursos mediante la URIJunio 2011 SOA y Web Services 145
    146. 146. 1. Introducción a los Servicios REST Otros principios de REST  No depender de un único protocolo de comunicación  Describir dentro del servicio los tipos MIME que representan los recursos  No utilizar nombre fijos para los recursos  Definir las normas para crear URIs válidas en base a los tipos MIME y el estado actual  Utilizar un punto de entrada fijo pero que todas las transiciones las guíe el clienteJunio 2011 SOA y Web Services 146
    147. 147. V. RESTful Web Services1. Introducción a los Servicios REST2. Comparativa con SOAP3. Implementación de Servicios RESTJunio 2011 SOA y Web Services 147
    148. 148. 2. Comparativa con SOAP SOAP está más extendido Tiene múltiples extensiones  WS-Extensions, WS-I,…  Pensadas para la integración de aplicaciones empresariales Existen multitud de plataformas de generación de código  JAX-RPC, JAX-WS, AXIS, … Existen entornos ESB que utilizan interfaces WSDL para la integración de aplicaciones  Apache ODE, Mule, MQ,… El formato document/literal es similar a REST  Envío de un documento XML encapsulado en SOAPJunio 2011 SOA y Web Services 148
    149. 149. 2. Comparativa con SOAP La red es una de las aplicaciones más exitosas del planeta  HTTP es suficientemente general y claro para crear aplicaciones robustas y escalables Los desarrolladores tienden a la complejidad  Un problema complejo no implica que la solución también lo sea SOAP es muy complejo y REST muy simple  “WS-Estrella de la muerte” Vs “RESTafaris”  Razonamiento de Occam Alternativas SOA  Comprar un ESB estándar y adaptarte a él  Comprar el mejor ESB y aprender a manejarlo  Hacértelo tú mismo  ¿cómo?, SOAP, REST, formato propioJunio 2011 SOA y Web Services 149
    150. 150. 2. Comparativa con SOAP Tabla comparativa Principio SOA Servicios XML Servicios REST Interpoerabilidad Excelente Buena Bajo acoplamiento Excelente Excelente Reutilización Excelente Buena Fácil descubrimiento Excelente Pobre Simplicidad Pobre Excelente Mantenibilidad Buena Buena Extensibilidad Excelente Pobre Rendimiento Bueno Excelente Escalibilidad Buena PobreJunio 2011 SOA y Web Services 150
    151. 151. V. RESTful Web Services1. Introducción a los Servicios REST2. Comparativa con SOAP3. Implementación de Servicios RESTJunio 2011 SOA y Web Services 151
    152. 152. 3. Implementación de Servicios REST Los Servicios REST se basan en los verbos de HTTP  POST, GET, PUT, DELETE Y en los tipos MIME de datos enviados  text/plain, text/xml, image/jpeg,… En general se puede decir que REST utiliza actividades CRUD  Create, Read, Update, Delete Cada operación del servicio va a estar disponible dado un verbo HTTP y uno o varios tipos de contenido MIMEJunio 2011 SOA y Web Services 152
    153. 153. 3. Implementación de Servicios REST Mediante JAX-RS  Basado en el JSR 311  Define anotaciones para mapear servicios RESTful  @GET, @POST, @PUT,…  Implementaciones  RESTeasy de JBoss  RESTpack de Mule  Jersey de Sun  NetBeans 6 incluye una implementación de Jersey IDE con ejemplos preconfiguradosJunio 2011 SOA y Web Services 153
    154. 154. 3. Implementación de Servicios REST Mediante Jersey  Requiere las librerías  Jersey-server  Jersey-core  Asm  1º Crear un Servlet mapeado a "/*" <servlet> <servlet-name>RecursoREST</servlet-name> <servlet-class> com.sun.jersey.spi.container.servlet.ServletContainer </servlet-class> </servlet> <servlet-mapping> <servlet-name>RecursoREST</servlet-name> <url-pattern>/*</url-pattern> </servlet-mapping>Junio 2011 SOA y Web Services 154
    155. 155. 3. Implementación de Servicios REST Mediante Jersey  2º Crear una clase de implementación anotada a un path @Path("/raiz") public class Servicio{ }  3º Anotar los métodos de recursos  Con un verbo HTTP y un tipo de contenido MIME a consumir y/o producir  Se puede ampliar el path siempre bajo el raíz  Se localiza en /raiz/saludo @GET @ProduceMime("text/xml") @Path("/saludo") public String hola(){ }Junio 2011 SOA y Web Services 155
    156. 156. 3. Implementación de Servicios REST Parámetros de entrada  Parámetros del Path  Indicar la parte del path que hace de parámetro entre llaves  @Path("/raiz/{var}")  Admite expresiones regulares (Ej. Número de 3 dígitos)  @Path("/raiz/{var: d{3}}")  Anotar el parámetro con  @PathParam("var") int x  Parámetros de la QueryString (?var1=valor&var2=valor&…)  Anotar el parámetro con  @QueryParam("var") @DefaultValue("7") int y  Parámetros de formulario  Anotar el método con  @Consumes("application/x-www-form-urlencoded")  Anotar el parámetro con  @FormParam("parametro") String zJunio 2011 SOA y Web Services 156
    157. 157. 3. Implementación de Servicios REST Parámetros de retorno  Tipos sencillos (nativos + fechas + String)  @Produces(“text/plain”)  Tipos XML y JSON  Devolver el contenido como String pero con el tipo MIME adecuado  Tipos Response  return Response.ok(contenido, tipoMIME).build();  Tipos Object  1º Anotar el objeto con anotaciones JAXB @XmlRootElement(name=“persona”) public class Persona{ @XmlElement(name=“id”) int id; @XmlElement(name=“nombre”) String nombre; }  2º Devolver el objeto con tipo MIME “application/xml”Junio 2011 SOA y Web Services 157
    158. 158. 3. Implementación de Servicios REST Clientes REST con Jersey  Requiere las librerías  Jersey-client  Jersey-core  1º Crear un objeto cliente ClientConfig cfg = new DefaultClientConfig(); Client cliente = Client.create(cfg);  2º Obtener el recurso Web apuntando a la URL base URI url = URI.create(“http://localhost:8080/raiz”); WebResource recurso = cliente.resource(url);Junio 2011 SOA y Web Services 158
    159. 159. 3. Implementación de Servicios REST Clientes REST con Jersey  3º Consumir el recurso  Añadir paths opcionales a la URL recurso.path("subrecurso");  Indicar el tipo MIME a recoger/enviar recurso.accept(MediaType.TEXT_XML); recurso.accept(MediaType.TEXT_XML);  Invocar al verbo HTTP con el tipo de retorno esperado String respuesta = recurso.get(String.class);  Los verbos POST y PUT requiere datos a enviar ClientResponse r = recurso.put(ClientResponse. class, datos);Junio 2011 SOA y Web Services 159
    160. 160. Contenidos I. Fundamentos II. Arquitectura SOA III. XML Web Services IV. Implementando XML Web Services V. RESTful Web Services VI. Interoperabilidad VII. Arquitectura ESBJunio 2011 SOA y Web Services 160
    161. 161. VI. Interoperabilidad1. Concepto de Interoperabilidad2. XML Schemas3. Implementación de la InteroperabilidadJunio 2011 SOA y Web Services 161
    162. 162. 1. Concepto de Interoperabilidad La característica fundamental de los Web Services es la interoperabilidad Pero, ¿Qué es interoperabilidad? Condición mediante la cual sistemas heterogéneos pueden intercambiar procesos o datos Una definición más genérica  “Propiedad de los sistemas de producción, cuyas interfaces son perfectamente conocidas, para trabajar con otros sistemas de producción presentes o futuros sin restricciones de acceso o implementación”.Junio 2011 SOA y Web Services 162
    163. 163. 1. Concepto de Interoperabilidad Más sencillo  Integración a distintos niveles tecnológicos  Datos, mensajes, componentes, aplicaciones, servicios, procesos,…  Para  Integrar procesos de negocio incompatibles  Unificar datos usados en distintos sistemas  Unificar tecnologías  Unificar tiempos de ejecución (batch + OLTP)  …Junio 2011 SOA y Web Services 163
    164. 164. 1. Concepto de Interoperabilidad Interoperabilidad sintáctica  Posibilidad de intercambiar datos entre dos sistemas heterogéneos  Transformación de datos: XSLT Interoperabilidad semántica  Posibilidad de entender y ser capaz de utilizar los datos intercambiados  Definición de datos: XSDJunio 2011 SOA y Web Services 164
    165. 165. 1. Concepto de Interoperabilidad La interoperabilidad exige que los tipos de datos utilizados como parámetros en los Web Services tengan una correspondencia con los tipo XSD  Porque ya existan (tipos nativos)  Porque sean composición de éstos (clases sencillas mapeadas a complexType) No se admiten tipos complejos  List, Array, Map, DataSet, …  En el mejor de los casos se mapean a array [ ]Junio 2011 SOA y Web Services 165
    166. 166. VI. Interoperabilidad1. Concepto de Interoperabilidad2. XML Schemas3. Implementación de la InteroperabilidadJunio 2011 SOA y Web Services 166
    167. 167. 2. XML Schemas En documentos XML a veces es necesario  Especificar una relación entre los elementos del documento  Verificar la corrección de los datos  Verificar la integridad de los datos  Tener un entendimiento compartido Se comprueba:  Elementos o atributos declarados en el esquema.  Estructura jerárquica de elementos y atributos.  Orden de los elementos.  Valores de atributos y elementos.  Unicidad de valores.Junio 2011 SOA y Web Services 167
    168. 168. 2. XML Schemas XML Schema (XSD)  Fichero de validación XML  Sintaxis XML  Nodos y tipos (primitivos y derivados)  Soporta la extensión del documento  Se puede utilizar para transformar el documento en una jerarquía de objetos  NO mapea los métodos  Utiliza espacios de nombres (namespaces)Junio 2011 SOA y Web Services 168
    169. 169. 2. XML Schemas <xsd:element name=“nombre_nodo” type=“tipo_dato” default=“valor por defecto” fixed=“valor fijo” minOccurs=“cardinalidad mínima” maxOccurs=“cardinalidad máxima”> <xsd:attribute name=“nombre_atributo” type=“tipo_dato” use=“optional o mandatory” fixed=“valor fijo” > <xsd:complexType mixed=“true o false”>Junio 2011 SOA y Web Services 169
    170. 170. 2. XML Schemas Tipos Primitivos:  Tipos Derivados:  string  integer (decimal)  boolean  long (integer)  decimal  normalizedString (string)  float  token (normalizedString)  double  Name (token)  dateTime  ID (Name)  date  IDREF (Name)  time  ENTITY (Name)  …  …Junio 2011 SOA y Web Services 170
    171. 171. 2. XML Schemas Mapeo de Objetos Cliente <xsd:element name="Cliente"> +fechaNac:Date +direccion:String <xsd:complexType> <xsd:all> <xsd:element name="fechaNac" type="xsd:date" /> <xsd:element name=“direccion" type="xsd:string" /> </xsd:all> </xsd:complexType> </xsd:element>Junio 2011 SOA y Web Services 171
    172. 172. 2. XML Schemas Base +a:int Mapeo de Herencia -b:int <xsd:complexType name=“Base”> -c:int <xsd:all> +getB():int <xsd:element name="a" type="xsd:int" /> +setB(int) <xsd:element name="b" type="xsd:int" /> </xsd:all> </xsd:complexType> <xsd:complexType name=“Derivada”> <complexContent> <extension base=“Base”> Derivada <xsd:all> +x:int <xsd:element name=“x" type="xsd:int" /> </xsd:all> -y:int </extension> </complexcontent> </xsd:complexType>Junio 2011 SOA y Web Services 172
    173. 173. 2. XML Schemas Veamos un ejemploJunio 2011 SOA y Web Services 173
    174. 174. VI. Interoperabilidad1. Concepto de Interoperabilidad2. XML Schemas3. Implementación de la InteroperabilidadJunio 2011 SOA y Web Services 174
    175. 175. 3. Implementación de la Interoperabilidad Estrategias  Rápida y de bajo coste de integración  WSI (WebServices Integration)  Crear un WS para el sistema a integrar  Se crean los tipos necesarios para ese sistema  Poco reutilizable  Sistemática y de inversión a futuro  SOI (Service Oriented Integration)  Diseñar la arquitectura SOA antes de nada  Interfaces y modelo de datos comunes y centralizadosJunio 2011 SOA y Web Services 175
    176. 176. 3. Implementación de la Interoperabilidad Bottom-up  Generar un SEI y el documento WSDL a partir de una clase de implementación  Ventajas: Fácil de implementar y generar  Desventajas: Podrían utilizarse objetos complejos no serializables ●Top-down  Generar un SEI a partir de un WSDL existente  Implementar el servicio a partir de esta interfaz  Ventajas: Se asegura desde la definición que el servicio va a ser totalmente interoperable  Inconvenientes: Más costoso de implementarJunio 2011 SOA y Web Services 176
    177. 177. 3. Implementación de la Interoperabilidad ¿Qué pasa con los estándares?  HTTP  W3C  XML  ISO  SOAP  ECMA  WSDL  OASIS  …  … Estandarizar los estándares  WS-I.org (no confundir con WSI)  Web Services Interoperability Organization  Promoción de interoperabilidad desde el SW libreJunio 2011 SOA y Web Services 177
    178. 178. 3. Implementación de la Interoperabilidad WS-I  Integrador de estándares  Guía, recomienda buenas prácticas y proporciona recursos para el desarrollo  Pero no desarrolla estándares  Para  Lograr la interoperabilidad de WS  Lograr que se adopte el modelo de WS  Acelerar el despliegue de WSJunio 2011 SOA y Web Services 178
    179. 179. 3. Implementación de la Interoperabilidad Perfiles WS-I (Profiles)  Basic 1.0  SOAP + WSDL + XSD + UDDI  Basic 1.1  Basic 1.0 + Attachments  SwA (SOAP with Attachments)  Basado en MIME  No Microsoft  MTOM (Message Transmission Optimization Mechanism)  MIME + codificación Base64Junio 2011 SOA y Web Services 179
    180. 180. 3. Implementación de la Interoperabilidad Se debe:  Usar HTTP para SOAP  Usar HTTP 500 para faltas SOAP  Usar método POST  Usar WSDL 1.1  Usar RPC/literal o document/literal No se debe:  Extender/restringir <soapenc:ArrayType>  Usar RPC/encoding  Usar operaciones de tipo notificación  Usar <wsdl:import> para otra cosa que no sea WSDLJunio 2011 SOA y Web Services 180
    181. 181. 3. Implementación de la Interoperabilidad Arrays  Existe el tipo <soapenc:ArrayType>  No existen tipos Collection, NO LOS USES  List, Map, Set, Dictionary, DataSet,…  Ejemplo: <xsd:element name="MiArray" type="tns:TipoArray"/> <xsd:complexType name="TipoArray"> <xsd:sequence> <xsd:element name="item" type="xsd:string" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType> </xsd:element>Junio 2011 SOA y Web Services 181
    182. 182. 3. Implementación de la Interoperabilidad Tips  Se puede validar un WSDL contra WS-I  Se puede generar cumpliendo con un perfil WS-I  Se recomienda el enfoque Top-Down (primero el WSDL)  Se recomienda usar siempre document/literal  Se recomienda usar clases tipo JavaBean  Se recomienda realizar pruebas sistemáticas  Los mensajes SOAP grandes ralentizan la comunicación  Los ficheros SOAP complejos también  Máximo 100KB y 10 niveles de anidación en el SOAPJunio 2011 SOA y Web Services 182
    183. 183. Contenidos I. Fundamentos II. Arquitectura SOA III. XML Web Services IV. Implementando XML Web Services V. RESTful Web Services VI. Interoperabilidad VII. Arquitectura ESBJunio 2011 SOA y Web Services 183
    184. 184. VII. Arquitectura ESB1. Origen y Motivación2. Integración de Aplicaciones3. Modelo ESBJunio 2011 SOA y Web Services 184
    185. 185. 1. Origen y MotivaciónUsuarios Imagenes unificadas de datosSistemasexistentes Network Colaboración Contenido Utilitarios Heredados Paquetes Junio 2011 SOA y Web Services 185
    186. 186. 1. Origen y MotivaciónUsuarios Procesos de negocio traducidos en tecnologíaSistemasexistentes Network Colaboración Contenido Utilitarios Heredados Paquetes *Extraído de “ESB: Enterprise Services Bus ” de Jorge Humberto Arias Junio 2011 SOA y Web Services 186
    187. 187. 1. Origen y Motivación En una empresa se deben integrar datos, procesos de negocio, soluciones,… Sin caer en un caos que nos lleve al fracaso  Tener distintas clases Cliente según sistema o Base de Datos… Interesa  Poder dirigir la integración por procesos de negocio  Localizando las funcionalidades base del proceso  Pudiendo acceder de modo síncrono y asíncrono  Que soporte y conviva con la “historia”  SOA + EDAJunio 2011 SOA y Web Services 187
    188. 188. 1. Origen y Motivación EDA  ArquitecturaDirigida por Eventos  Propuesta para la integración de sistemas heredados  Automatizar la generación de mensajes y el envío de los mismos por medio de eventosJunio 2011 SOA y Web Services 188
    189. 189. 1. Origen y Motivación Hay muchas formas de integrar aplicaciones nuevas ¿Y las antiguas? Sistemas heredados/legados (legacy)  Sistemas grandes difíciles de tratar pero vitales para el negocio  Sistemas menos competitivos que otros más modernos pero con prohibitivo coste de reemplazo  Antiguos, monolíticos y difíciles de modificarJunio 2011 SOA y Web Services 189
    190. 190. VII. Arquitectura ESB1. Origen y Motivación2. Integración de Aplicaciones3. Modelo ESBJunio 2011 SOA y Web Services 190
    191. 191. 2. Integración de Aplicaciones Intrusiva  Modificar el código Interfaz de Usuario No intrusiva  Añadir una capa de abstracción que utilice la aplicación de Servicio manera transparente Lógica de aplicación DatosJunio 2011 SOA y Web Services 191
    192. 192. 2. Integración de Aplicaciones Estrategias  MBS (Message Bus Architecture)  Se tiene un bus por el que fluyen mensajes entre las aplicaciones  Cada aplicación está conectada al bus mediante un adaptador específico  Switch de Protocolos  Un motor genérico se encarga de utilizar los distintos tipos de protocolo en cada caso  SOAP, CORBA, MOM, Remoting,…  Gateway  Un programa “pasarela” comunica las aplicaciones  Se encarga de las transformaciones necesariasJunio 2011 SOA y Web Services 192
    193. 193. VII. Arquitectura ESB1. Origen y Motivación2. Integración de Aplicaciones3. Modelo ESBJunio 2011 SOA y Web Services 193
    194. 194. 3. Modelo ESB Sistem Atención al Sistema de cliente CORBA facturación JMS RMI SOAP Servicios de negocio Enterprise Service Bus (ESB) Conectores técnicosJunio 2011 SOA y Web Services 194
    195. 195. 3. Modelo ESB Estándares WSP Infraestructura de servicios no-funcionales Prácticas ( Transacciones, seguridad, BPM, etc.) para el diseño de servicios o adaptación Bus de Servicios Infraestructura/Framework de webservices Servicio/Adaptador Servicio/Adaptador Servicio/Adaptador Clientes Fuente: Burton Group Plataforma de Plataforma de Plataforma de negocio A negocio B Negocio CJunio 2011 SOA y Web Services 195
    196. 196. 3. Modelo ESB Un buen ESB debe  Soportar multiprotocolo (SOAP, CORBA, MOM, B2B,…)  Soportar WSP (Web Services Platform)  Motor SOAP  Framework para crear WebServices  Frameworks adicionales (WS-Eventing, WS-Transaction, WS-Security, WS-BPEL,…)  Implementar adaptadores de integración  Para sistemas legados, CRMs, ERPs,…  Permitir orquestar procesos de negocio  Permitir transacciones y transformacionesJunio 2011 SOA y Web Services 196
    197. 197. 3. Modelo ESB Algunos ESB  Libres  Mule (http://mule.codehaus.org/)  WSO2 (http://wso2.com/products/enterprise-service-bus/)  Apache ServiceMix (http://servicemix.apache.org/home.html)  Comerciales  Fiorano (http://www.fiorano.com)  BizTalk (http://www.microsoft.com/biztalk/)  JBoss (http://www.jboss.org/jbossesb)  IBM WebSphere (http://www-01.ibm.com/software/integration/wsesb/)  Oracle (http://www.oracle.com/technologies/soa/service-bus.html)Junio 2011 SOA y Web Services 197
    198. 198. Muchas Gracias Óliver Centeno ÁlvarezJunio 2011 SOA y Web Services 198

    ×