• Save
SOA y Web Services
Upcoming SlideShare
Loading in...5
×
 

SOA y Web Services

on

  • 4,991 views

 

Statistics

Views

Total Views
4,991
Views on SlideShare
4,991
Embed Views
0

Actions

Likes
6
Downloads
17
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution-NonCommercial-NoDerivs LicenseCC Attribution-NonCommercial-NoDerivs LicenseCC Attribution-NonCommercial-NoDerivs License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • 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 SOA y Web Services Presentation Transcript

  • SOA y Web Services Óliver Centeno Álvarez Junio 2011Junio 2011 SOA y Web Services 1
  • 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
  • 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 View slide
  • 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 View slide
  • 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
  • I. Fundamentos1. Motivación2. Arquitecturas de Software3. Necesidad del Contrato4. Modelado de Componentes5. RetosJunio 2011 SOA y Web Services 6
  • 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
  • 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
  • I. Fundamentos1. Motivación2. Arquitecturas de Software3. Necesidad del Contrato4. Modelado de Componentes5. RetosJunio 2011 SOA y Web Services 9
  • 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
  • 2. Arquitecturas de Software Evolución históricaJunio 2011 SOA y Web Services 11
  • 2. Arquitecturas de Software MVC  Modelo  Vista  Controlador  Utilizado en aplicaciones gráficas y WebJunio 2011 SOA y Web Services 12
  • 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
  • I. Fundamentos1. Motivación2. Arquitecturas de Software3. Necesidad del Contrato4. Modelado de Componentes5. RetosJunio 2011 SOA y Web Services 14
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • I. Fundamentos1. Motivación2. Arquitecturas de Software3. Necesidad del Contrato4. Modelado de Componentes5. RetosJunio 2011 SOA y Web Services 22
  • 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
  • 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
  • 4. Modelado de Componentes Representación UML Componentes Componente componente Interfaz requerida Interfaz proporcionadaJunio 2011 SOA y Web Services 25
  • 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
  • 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
  • 4.Modelado de Componentes Veamos un EjemploJunio 2011 SOA y Web Services 28
  • I. Fundamentos1. Motivación2. Arquitecturas de Software3. Necesidad del Contrato4. Modelado de Componentes5. RetosJunio 2011 SOA y Web Services 29
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • III.XML Web Services1. Definiciones2. El protocolo SOAP3. Documentos WSDL4. Registros UDDIJunio 2011 SOA y Web Services 57
  • 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
  • 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
  • 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
  • 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
  • 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
  • 1. Definiciones InfraestructuraJunio 2011 SOA y Web Services 63
  • 1. Definiciones Estándares:  XML  XSD  HTTP  SOAP  WSDL  UDDIJunio 2011 SOA y Web Services 64
  • III.XML Web Services1. Definiciones2. El protocolo SOAP3. Documentos WSDL4. Registros UDDIJunio 2011 SOA y Web Services 65
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 2. El protocolo SOAP Motores SOAPJunio 2011 SOA y Web Services 72
  • 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
  • III.XML Web Services1. Definiciones2. El protocolo SOAP3. Documentos WSDL4. Registros UDDIJunio 2011 SOA y Web Services 74
  • 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
  • 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
  • 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
  • 3. Documentos WSDL Veamos unos documentos WSDLJunio 2011 SOA y Web Services 78
  • III.XML Web Services1. Definiciones2. El protocolo SOAP3. Documentos WSDL4. Registros UDDIJunio 2011 SOA y Web Services 79
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 1. Tecnologías J2EE para WS El API SAAJ sin archivos vinculadosJunio 2011 SOA y Web Services 86
  • 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
  • 1. Tecnologías J2EE para WS El API SAAJ con archivos vinculadosJunio 2011 SOA y Web Services 88
  • 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
  • 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
  • 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
  • 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
  • 1. Tecnologías J2EE para WS El API JAX-RPCJunio 2011 SOA y Web Services 93
  • 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
  • 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
  • 1. Tecnologías J2EE para WS El API JAX-WSJunio 2011 SOA y Web Services 96
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 3. Creación de WS en Java En Eclipse desde un JavaBeanJunio 2011 SOA y Web Services 110
  • 3. Creación de WS en JavaJunio 2011 SOA y Web Services 111
  • 3. Creación de WS en JavaJunio 2011 SOA y Web Services 112
  • 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
  • 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
  • 3. Creación de WS en JavaJunio 2011 SOA y Web Services 115
  • 3. Creación de WS en Java En JDeveloper desde un JavaBeanJunio 2011 SOA y Web Services 116
  • 3. Creación de WS en JavaJunio 2011 SOA y Web Services 117
  • 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
  • 4. Creación de WS en .NetJunio 2011 SOA y Web Services 119
  • 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
  • 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
  • 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
  • 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
  • 5. Publicación de Web Services En JDeveloperJunio 2011 SOA y Web Services 124
  • 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
  • 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
  • 5. Publicación de Web ServicesJunio 2011 SOA y Web Services 127
  • 5. Publicación de Web ServicesJunio 2011 SOA y Web Services 128
  • 5. Publicación de Web ServicesJunio 2011 SOA y Web Services 129
  • 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
  • 6. Consumo de Web Services En JDeveloperJunio 2011 SOA y Web Services 131
  • 6. Consumo de Web ServicesJunio 2011 SOA y Web Services 132
  • 6. Consumo de Web ServicesJunio 2011 SOA y Web Services 133
  • 6. Consumo de Web ServicesJunio 2011 SOA y Web Services 134
  • 6. Consumo de Web ServicesJunio 2011 SOA y Web Services 135
  • 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
  • 6. Consumo de Web ServicesJunio 2011 SOA y Web Services 137
  • 6. Consumo de Web ServicesJunio 2011 SOA y Web Services 138
  • 6. Consumo de Web Serviceslocalhost.Externos objeto;Junio 2011 SOA y Web Services 139
  • 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
  • V. RESTful Web Services1. Introducción a los Servicios REST2. Comparativa con SOAP3. Implementación de Servicios RESTJunio 2011 SOA y Web Services 141
  • V. RESTful Web Services1. Introducción a los Servicios REST2. Comparativa con SOAP3. Implementación de Servicios RESTJunio 2011 SOA y Web Services 142
  • 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
  • 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
  • 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
  • 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
  • V. RESTful Web Services1. Introducción a los Servicios REST2. Comparativa con SOAP3. Implementación de Servicios RESTJunio 2011 SOA y Web Services 147
  • 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
  • 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
  • 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
  • V. RESTful Web Services1. Introducción a los Servicios REST2. Comparativa con SOAP3. Implementación de Servicios RESTJunio 2011 SOA y Web Services 151
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • VI. Interoperabilidad1. Concepto de Interoperabilidad2. XML Schemas3. Implementación de la InteroperabilidadJunio 2011 SOA y Web Services 161
  • 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
  • 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
  • 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
  • 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
  • VI. Interoperabilidad1. Concepto de Interoperabilidad2. XML Schemas3. Implementación de la InteroperabilidadJunio 2011 SOA y Web Services 166
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 2. XML Schemas Veamos un ejemploJunio 2011 SOA y Web Services 173
  • VI. Interoperabilidad1. Concepto de Interoperabilidad2. XML Schemas3. Implementación de la InteroperabilidadJunio 2011 SOA y Web Services 174
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • VII. Arquitectura ESB1. Origen y Motivación2. Integración de Aplicaciones3. Modelo ESBJunio 2011 SOA y Web Services 184
  • 1. Origen y MotivaciónUsuarios Imagenes unificadas de datosSistemasexistentes Network Colaboración Contenido Utilitarios Heredados Paquetes Junio 2011 SOA y Web Services 185
  • 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
  • 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
  • 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
  • 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
  • VII. Arquitectura ESB1. Origen y Motivación2. Integración de Aplicaciones3. Modelo ESBJunio 2011 SOA y Web Services 190
  • 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
  • 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
  • VII. Arquitectura ESB1. Origen y Motivación2. Integración de Aplicaciones3. Modelo ESBJunio 2011 SOA y Web Services 193
  • 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
  • 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
  • 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
  • 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
  • Muchas Gracias Óliver Centeno ÁlvarezJunio 2011 SOA y Web Services 198