3/9 soa y web services

3,869 views
3,766 views

Published on

Curso JEE5, Soa, Web Services, ESB y XML

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,869
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
221
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

3/9 soa y web services

  1. 1. SERVICIOS WEB:ARQUITECTURASORIENTADAS A SERVICIOS
  2. 2. • ÍNDICE DE CONTENIDOS: − COMPONENTES − SERVICIOS WEB − ARQUITECTURAS ORIENTADAS A SERVICIO –SOA − XML Y JAVA − SOAP − SEGURIDAD XML Y SERVICIOS WEB
  3. 3. WEB SERVICES» PARTE II: FUNDAMENTOS TEÓRICOS DE LOS WEB SERVICES
  4. 4. WEB SERVICES• “Modular, selfdescribing applications that can be published, located and invoked from anywhere on the Web or a local network. The provider and the consumer of the Web service do not have to worry about the operating system, language environment, or component model used to create or access the service, as they are based on ubiquitous and open Internet standards, such as XML, HTTP, and SMTP” [Claudwell et al, 2001]• “Aplicaciones modulares, autodescritas que pueden ser publicadas, localizadas e invocadas desde cualquier ubicación en la web o en una red local. El suministrador y el consumidor del Web Service no tienen que preocuparse por el Sistema Operativo, idioma o modelo de componentes usado para crear o acceder a los servicios, ya que están basados en estándares omnipresentes de internet, como XML, HTTP y SMTP” [Claudwell et al, 2001]
  5. 5. WEB SERVICES• “Internetbased modular applications that perform a specific business task and conform to a specific technical format” [Mark Colan, IBM]• “Aplicaciones modulares basadas en Internet que llevan a cabo tareas de negocio específicas ajustándose a un formato técnico específico” [Mark Colan, IBM]• “An abstraction of a service provided by some organization as visible from a Webenabled client, utilizing the www as transport medium, and www transport protocols and formats” [M. Koethe, MediaOne]• “Una abstracción de un servicio proporcionado por alguna organización, y que es visible mediante un cliente web usando la WWW como medio de transporte y sus protocolos y formatos de transporte” [M. Koethe, MediaOne]
  6. 6. WEB SERVICES• ¿Qué nos aportan los Web Services? − Pervasiveness: Alta penetración. acceso a servicios desde cualquier ubicación en la red. − Mejor interoperabilidad − Simplicidad − Permiten pasar de las típicas aplicaciones Web (2tier), a aplicaciones más complejas (n tier) − Menor acoplamiento y mayor granularidad − Alta reutilización
  7. 7. Web Services• ¿Qué ofrecen de nuevo los Web Services? − Alquiler de servicios externos frente a desarrollo • ¿Reducción de costes? − Alquiler de servicios externos frente a compra de software • ¿mejor negocio? • (Ejemplo: Adobe’s Distiller) − Alquiler de servicios propios frente a venta de software • ¿Mejor negocio? • (Ejemplo: Adobe’s Distiller)
  8. 8. WEB SERVICES• EJEMPLOS DE WEB SERVICES − Conversores (moneda, unidades, ....) − Servicios de cotización en bolsa − Calculadoras − Asignación de IDs y GUIDs − Comprobación del tiempo, el estado del tráfico, precios de subastas, ...• SITIOS QUE MUESTRAN LISTAS DE WS GRATUITOS − www.xmethods.net − www.salcentral.com La herramienta “estrella” o más “popular” de generación de Web Services es sin duda .NET.
  9. 9. WEB SERVICES• UTILIZACIÓN DE WEB SERVICES − Descubrirlos (Discovery) • UDDI – Universal Description, Discovery & Integration − Conocer qué hacen exactamente, y cómo se usan (Description) • WSDL – Web Services Description Languaje − Invocarlos (Invocation) • SOAP – Simple Object Access Protocol − Intercambio de datos (Data Interchange) • XML − Conexión (Conection). • HTTP
  10. 10. WEB SERVICES
  11. 11. WEB SERVICES• ESTÁNDARES (I): SOAP − SOAP: Simple Object Access Protocol • Creado por Microsoft e IBM. A diferencia de DCOM y CORBA, SOAP usa el código fuente en XML, que facilita la eliminación de errores. • Permite el intercambio de información estructurada y con tipos entre entidades (peers) descentralizadas • Permite codificación y empaquetamiento basado en XML para intercambiar datos como mensajes o RPCs
  12. 12. WEB SERVICES• ESTÁNDARES (II): WSDL • SOAP permite expresar invocaciones y respuestas sueltas, pero también es necesario describir los servicios, como colecciones de operaciones y respuestas. • Web Service Description Language fue desarrollado por Microsoft e IBM para describir servicios Web. • Independiente del método de transporte o método de codificación final. • Las descripciones WSDL son complejas y difíciles de construir manualmente • Los fabricantes ofrecen generadores automáticos de documentos WSDL: − Microsoft SOAP Toolkit for COM − IBM WebServices Toolkit: Java, EJBs, COM − .NET(fue diseñado para trabajar con Web Services)
  13. 13. WEB SERVICES• ESTÁNDARES (III): UDDI Universal Description, Discovery and Integration − Desarrollado por IBM, Microsoft y Ariba − Permite mantener un registro global de Web Services − Con operaciones para: publicar (publish), ojear (browse) y retirar (un-publish) Web Services − Cualquier aplicación (incluidos Search engines) pueden consultarlo para descubrir servicios.
  14. 14. WEB SERVICES• Componentes y Web Services; ¿NO SON LO MISMO? WEB SERVICES CORBA SOAP, HTTP IIOP URL’S IOR’S WSDL IDL UDDI Naming Service, Interface Repository
  15. 15. WEB SERVICES• Componentes Versus Web Services Componentes Web Services Perspectiva Elementos internos de Elementos que se Arquitectónica un sistema ven desde fuera del sistema Modelo de Despliegue físico (install El SW existe en despliegue and use) alguna parte. Niveles de Mayoritariamente dentro Mayoritariamente intercambio de de la empresa entre varias información empresas. Niveles de Débil Muy débil acoplamiento Comunicación Middleware (Ej: IIOP) Web Based; (SOAP/XML sobre http)
  16. 16. WEB SERVICES• Entonces; ¿Cómo funciona una invocación a un web service?
  17. 17. Soporte a Web Services en EE5• En la plataforma Java EE 5, el soporte a Web Services se ha mejorado y simplificado gracias al uso de annotations. Las sigiuentes especificaciones han contribuído en ello: − JSR 224, Java API for XML-Based Web Services (JAX-WS) 2.0 − JSR 222, Java Architecture for XML Binding (JAXB) 2.0 − JSR 181, Web Services Metadata for the Java Platform 2.0 − SOAP with Attachments API for Java (SAAJ) 1.3
  18. 18. Soporte a Web Services• JAX-WS 2.0: Es la nueva API para Web Services en la plataforma JEE5.• Como sucesora de la API JAX-RPC 1.1, JAX-WS 2.0 mantiene el modelo de programación RPC mejorando lo siguientes frentes: − Data binding (enlace de datos) − Independencia de protocolo de transporte − Soporte al estilo REST (Representational State Transfer) de Web Services − Facilidad de desarrollo
  19. 19. Soporte a Web Services• Características clave de JAX-WS 2.0: − Modelo de programación más simplificado: Antes de JEE5 y JAX-WS 2.0, se necesitaban descriptores farragosos. Ahora todo es tan fácil como colocar la annotation @WebService a la clase Java. Sólo con esto, TODOS los métodos públicos de la clase, será publicados como operaciones Web Service, y sus argumentos serán mapeados a tipos de datos de XML Schema usando JAXB 2.0 − Integración con JAXB 2.0: En JAX-WS 2.0, todo el data binding ha sido delegado a JAXB 2.0. JAXB2.0 puede generar documentos XML Schema que son incluídos dentro de un archivo WSDL, liberando al desarrollador de esta tarea. − Extensibilidad de Protocolo Transporte: Como por ejemplo el nuevo Fast Infoset (XML binario).
  20. 20. Soporte a Web Services− Extenso soporte a los estándares de Web Services: Soporta SOAP 1.1, SOAP 1.2 y protocolos XML/HTTP. Incluso podemos usar MTOM/XOP (W3Cs SOAP Message Transmission Optimization Mechanism/XML-Binary Optimized Packaging). Se beneficiaría de ello los Web Services que usen ficheros adjuntos para envío y recepción de datos binarios.− Soporte a clientes asíncronos: JAX-WS 2.0 soporta invocaciones de web services sin bloqueos, evitando que la aplicación cree y administre su propio pool de threads.− Capa de Mensajería: Las aplicaciones avanzadas que pueden usar a bajo nivel la API de mensajería JAX-WS 2.0 para procesar mensajes de forma directa, sin tener que duplicar ninguno de los niveles de transporte y protocolo− Soporte a aplicaciones REST-Style: Usando la API de mensajería de JAX-WS 2.0
  21. 21. Soporte a Web Services• Ejemplos de Web Services: − El ejemplo 3, muestra el código fuente de una aplicación implementada haciendo uso de un componente EJB 2.1 − El ejemplo 4, muestra el código equivalente pero haciendo uso de las nuevas annotations para Web Services
  22. 22. Soporte a Web Services• Ejemplo 3• Ejemplo 4 − Gracias a las annotations, no es necesario usar descriptores en este ejemplo
  23. 23. Soporte a Web Services• Web Services asíncronos. − Al tener lugar las invocaciones de Web Services a través de la red, algunas de esas llamadas obtienen respuestas en lapsos impredecibles de tiempo. Muchos clientes, especialmente las aplicaciones de escritorio (JFC/Swing) experimentan un comportamiento indeseable debido a esas esperas del proveedor del servicio. − JAX-WS 2.0 proporciona una nueva API cliente asíncrona. Con esta API, los programadores ya no tienen que crear threads; en lugar de ello, pueden confiar en el runtime JAX- WS 2.0 para que administre las invocaciones remotas.
  24. 24. Soporte a Web Services• API de Mensajería − El modelo de programación basado en el interfaz de la API JAX-WS 2.0, es muy potente, pero en ocasiones, algunas aplicaciones necesitan más control sobre los mensajes que son enviados a través de la red, − Las APIs Dispatch y Provider pueden usarse para enviar y recibir mensajes de forma directa. • Dispatch: Se usa en aplicaciones cliente • Provider: Se usa en aplicaciones servidor − Un uso particularmente interesante de estas aplicaciones consiste en escribir Web Services acordes con el estilo REST. En este estilo, los servicios exponen un conjunto de recursos que los clientes pueden manipular usando HTTP.
  25. 25. Prácticas• AXIS − ¿Qué es Axis?. Axis Services Vs JEE5 Services • Creación de un web service calculadora con Axis (modo JWS) • Creación de un web service calculadora mediante herramientas JEE5 − Más sobre axis: Implementación de un servicio mediante un WSDD
  26. 26. Prácticas• AXIS − Apache Axis es una implementación de SOAP − Con axis, es muy sencillo crear y usar un Web Service. Hasta que apareció JEE5, era una opción bastante buena para muchas organizaciones para construir sus Web Services. − La versión que usaremos es la más reciente, la 1.4 * • NO ES CIERTO: * la más reciente, es AXIS2; pero el desarrollo no es aún lo suficientemente maduro, y además se trata de una implementación de WS distinta.• AXIS Web Services VS JEE5 Web Services − Axis es un “añadido” innecesario para construir Web Services si nuestra plataforma es JEE5 − Sin embargo es muy útil conocerlo, ya que podemos implantarlo fácilmente en nuestros entornos J2EE (por ejemplo, con Tomcat). − Los Web Services en JEE5 se construyen con JAX-WS. En AXIS se construyen con JAX-RPC.
  27. 27. PrácticasPreparando el entorno− Copiamos el archivo siguiente en nuestra máquina guadalinex: • axis-bin-1_4.zip− Una vez en /home/guadalinex, lo copiamos a /tmp y descomprimimos con unzip.− Entramos a la carpeta cd axis-1_4webappsaxisWEB-INF− Editamos con gvim –y el archivo web.xml− Eliminamos el comentario para habilitar el Admin Servlet. Salvamos− Vamos a axis-1_4webappsaxis− Ejecutamos: cp WEB-INF/classes/SOAP*.class .− Ejecutamos jar –cvf axis.war * OJO con el PUNTO
  28. 28. Prácticas• Preparando el entorno (II) − Ejecutamos asadmin deploy axis.war − Si no tenenos arrancado el servidor, fallará. − Comprobaremos los domains instalados y en ejecución con el comando: • asadmin list-domains − Arrancar/Detener el servicio • asadmin start-domain domain1 (como sólo un dominio, es opcional) • asadmin stop-domain domain1 − Arrancamos el servicio con el comando start-domain. − Volvemos a intentar asadmin deploy axis.war . • Usuario admin: admin • Password: curso.curso
  29. 29. Prácticas• Preparando el entorno (III) − Comprobamos que se ha desplegado la aplicación con un navegador http://localhost:8080/axis − Ahora iniciamos la consola de administración (abrimos un navegador y tecleamos la URL: http://localhost:4848) − Nos logamos con admin/curso.curso − En el panel de la izquierda, en Applications, pinchamos en web applications, y en el panel de la derecha, comprobamos que se encuentra la aplicación axis. − Logout − Si con el servidor iniciado, hubiésemos tomado el archivo axis.war y lo hubiésemos copiamos al directorio: • App-server-install-dir/domains/domain1/autodeploy • También se habría desplegado y aparecería en la consola de administración.
  30. 30. Prácticas• Preparando el entorno (IV) − El autodeploy es por tanto también una forma rápida y cómo de desplegar aplicaciones en nuestro Application Server. − Copiamos el archivo lib-ext-netb-ide7-modules-ext.zip a nuestra máquina guadalinex, y lo copiamos desde /home/guadalinex a /tmp. Ahí, extraemos su contenido con unzip. − Copiamos todas las librerías CON sudo que aparezcan a: • /opt/netbean-5.5/ide7/modules/ext
  31. 31. ARQUITECTURAS ORIENTADAS ASERVICIO: SOA
  32. 32. SOA• “La recompensa potencial [de SOA] es enorme para las empresas que entiendan esta evolución y se muevan hacia estas arquitecturas. ... La tecnología de computación distribuida promete ser lo suficientemente flexible y elegante para responder a las necesidades de negocios y proporcionar la agilidad de negocios que las compañías han anhelado tanto tiempo, pero siempre ha estado fuera de alcance”. [The Rational Edge, 2004]• “La mejor solución a la integración de negocios...” [Annraí O’Toole, Cape Clear]• “SOA ha surgido como la mejor manera de afrontar el desafío de hacer más con menos recursos. Promete hacer la re-utilización y la integración mucho más fáciles, ayudando a reducir el tiempo de desarrollo y aumentando la agilidad organizacional. No sorprendentemente, el 80% de las organizaciones de IT están implementando aplicaciones usando SOA con web services subyacentes. SOA proporciona mayor flexibilidad para afrontar los cambios tanto en el ambiente de negocios como en la infraestructura tecnológica”. [M7 Corporation]
  33. 33. SOA• “SOA es la próxima ola de desarrollo de aplicaciones. Es más rápida, mejor y más barata” [Michael Pallos, 2001]• “Comprender el rol y el significado de SOA, más allá del hype simplista, es imperativo para cualquier arquitecto de software empresarial. ... Hacia 2008, SOA y Web Services serán implementados juntos en más del 75% de los proyectos futuros (probabilidad 0.7)” [Gartner, 2003]• “Hacia 2008, más del 75% de los paquetes de aplicación de ese entonces serán nativamente SOA o expondrán interfaces SOA a través de una capa de envoltura de interfaces (probabilidad 0.8)” [Gartner, 2003]• “Hacia 2008, SOA será la práctica prevalente de ingeniería de software, acabando con los 40 años de dominación de las arquitecturas monolíticas (probabilidad 0.7)” [Gartner, 2003]• “Giga recomienda a los arquitectos considerar SOA como la prioridad número uno en sus esfuerzos de planeamiento arquitectónico” [Giga IT Trends 2003: Application architecture and design]
  34. 34. SOA• Service-oriented architecture (SOA) fue descrita por primera vez por Gartner en 1996 − SSA Research Note SPA-401-068, 12 de abril, “‘Service Oriented’ Architectures, Part 1” y SSA Research Note SPA-401-069, 12 de abril, “‘Service Oriented’ Architectures, Part 2”• Los Web Services surgen con mayor fuerza hacia el 2000.• XML Web Services®• SOA (en la práctica) = XML+SOAP+WSDL+UDDI+Bus• SOAP 1.0 - Específico de Microsoft+Developmentor − XML + HTTP• SOAP 1.1 - MS+IBM+Lotus − Bindings de transporte para no-HTTP• SOAP 1.2 - W3C.org (ya no es más acrónimo)
  35. 35. SOA• W3C: Definición: “Conjunto de componentes que pueden ser invocados, cuyas descripciones de interfaces se pueden publicar y descubrir”• CBDI rechaza esa definición: − Los componentes pueden no ser conjuntos (ún único componente) − La definición sólo considera los componentes y no la práctica o el arte de construir la arquitectura• CBDI: “Estilo resultante de políticas, prácticas y frameworks que permiten que la funcionalidad de una aplicación se pueda proveer y consumir como conjuntos de servicios, con una granularidad relevante para el consumidor. Los servicios pueden invocarse, publicarse y descubrirse y están abstraídos de su implementación utilizando una sola forma estándar de interface”
  36. 36. SOA• “Infraestructura de alto nivel basada en best practices y patrones para crear soluciones basadas en servicios, de alta cohesión y bajo acoplamiento” (Geniant®).• “Estilo arquitectónico apto para implementar bajo acoplamiento entre agentes. Los agentes son proveedores y consumidores de servicios, que son la unidad de trabajo”. (Hao He).• “Una arquitectura de aplicación en la cual todas las funciones se definen como servicios independientes con interfaces invocables bien definidas, que pueden ser llamadas en secuencias definidas para formar procesos de negocios” (IBM).
  37. 37. SOA• MITRE: − Una aplicación SOA es una colección de servicios − Un servicio es la unidad atómica de una SOA − Los servicios encapsulan procesos de negocios − Los proveedores de servicios se registran solos − Un servicio involucra: Find, Bind, Execute − Las instancias más conocidas son los web services• Gartner: − “SOA es una arquitectura de software que comienza con una definición de interface y construye toda la topología de la aplicación como una topología de interfaces, implementaciones y llamados a interfaces. Sería mejor llamarla “arquitectura orientada a interfaces”. SOA es una relación de servicios y consumidores de servicios, ambos suficientemente amplios para representar una función de negocios completa”.
  38. 38. SOA¿Qué es SOA –Service Oriented Architecture-? − “Un conjunto de software de infraestructura y diseño integrados, que rentabiliza los estándares de computación web para desarrollar tareas de negocio en forma de servicios compartidos” <<SUN Microsystems>> − Panorama actual de las aplicaciones: •Caro •Confuso •Duplicidades •Difícil de mantener •Inflexible •Lento
  39. 39. SOAEscenario SOA•Fácil de compartir•Reusabilidad•Interoperabilidad•Escalabilidad•Flexibilidad•Desacoplado•Sencillo•Desarrollo Rápido•Ágil•Rentable en costes
  40. 40. SOA• Posibilita un flujo sencillo para el desarrollo Usamos servicios que a su vez usan a otros servicios
  41. 41. SOAEvolución perseguida al emplear SOA:
  42. 42. SOA• EN RESUMEN: ¿POR QUÉ SOA? − Permite reaccionar de forma rápida y precisa a las necesidades empresariales de evolución contínua. − Permite controlar los costes − Permite desarrollar servicios en menos tiempo − Despliegue de servicios innovadores y relevantes. − El incremento de eficiencia reduce el TCO − Incrementa la colaboración, tanto interna como externa − Toma de decisiones mejorada
  43. 43. SOA
  44. 44. SOA• Implementaciones RPC DCOM CORBA JAVA RMI WS Protocolo RPC RPC IIOP IIOP o JRMP SOAP Formato NDR CDR Java XML 1.0 mensaje Serialization Namespaces Format Descripción IDL OMG IDL Java WSDL Descubrimiento Registry Naming Service RMI Registry o UDDI JNDI Marshalling Type Library Serialization Marshaller• WS no requiere despliegue• WS no requiere clientes específicos, ni drivers• SOA se redefine como paso de mensajes, no RPC
  45. 45. SOA• Reusabilidad: Los servicios se ejecutan en distintos sistemas operativos, pueden estar escritos en diferentes lenguajes; lo único necesario para usar un servicio es su interfaz público.• Interoperabilidad: los perfiles WS-I (Web Services Interoperability) ayudan a que los servicios en diferentes lenguajes y plataformas puedan comunicarse.• Escalabilidad: Un bajo acoplamiento implica pocas dependencias entre los clientes y los servicios que usan. Esto conlleva que el esfuerzo en desarrollo no aumenta en complejidad en la misma proporción que en sistemas acoplados.• Flexibilidad: Pobre acoplamiento, naturaleza asíncrona de los servicios y sistema basado en documentos, son características de SOA que permiten flexibilidad al evolucionar en cambio de requisitos.• Eficiencia en costes: Las soluciones personalizadas son costosas porque requieren análisis intensivo, mucho tiempo de desarrollo y alto esfuerzo. Una solución SOA basada en servicios web reduce costes porque la integración de los clientes y servicios no implica análisis intensivos y la unicidad de los desarrollos a medida frente a las diferentes aproximaciones de los web services..
  46. 46. WEB SERVICES: PROTOLOS YTECNOLOGÍAS
  47. 47. SOA• Web Services: Protocolos y tecnologías (I) − XML: eXtensible Markup Language. Lenguage de marcas; implica el uso de etiquetas que marcan los contenidos de un documento. Por ejemplo: <biblioteca> <libro> <titulo>Quiero ser alcaldesa de Marbella y otros pensamientos</titulo> <sinopsis>¿El qué?</sinopsis> <autor>Yola Berrocal</autor> <precio>39.95</precio> <paginas>1</paginas> </libro> </biblioteca>
  48. 48. SOA• Web Services: Protocolos y tecnologías (II) − SOAP: Simple Object Access Protocol. Es un protocolo de intercambio de información basado en XML en un entorno distribuido. SOAP proporciona un formato de mensaje común para intercambio de información entre clientes y servicios. El elemento básico de transmisión en SOAP es el Mensaje SOAP, que consiste en un “sobre” o envoltura obligatoria, una cabecera SOAP opcional, y un cuerpo SOAP obligatorio.
  49. 49. SOA• Ejemplo de petición de compra SOAP completo: <env:Envelope xmlns:s="http://www.w3.org/2001/06/soap-envelope"> <env:Header> <m:transaction xmlns:m="soap-transaction" s:mustUnderstand="true"> <transactionID>1234</transactionID> </m:transaction> </env:Header> <env:Body> <n:purchaseOrder xmlns:n="urn:OrderService"> <from> <person>Christopher Robin</person> <dept>Accounting</dept> </from> <to> <person>Pooh Bear</person> <dept>Honey</dept> </to> <order> <quantity>1</quantity> <item>Pooh Stick</item> </order> </n:purchaseOrder> </env:Body> </env:Envelope>
  50. 50. SOA• Ejemplo SOAP de petición y respuesta: − Ejemplo de petición SOA <SOAP-ENV:Envelope . . . <SOAP-ENV:Body> <m:GetOrderStatus xmlns:m="www.xmlbus.com/OrderEntry"> <orderno>12345</orderno> </m:GetOrderStatus> </SOAP-ENV:Body> </SOAP-ENV:Envelope> − Ejemplo de respuesta: <SOAP-ENV:Envelope . . . <SOAP-ENV:Body> <m:GetOrderStatusResponse xmlns:m="www.xmlbus.com/OrderEntry"> <status>shipped June 18</status> <m:GetOrderStatusResponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope>
  51. 51. WEB SERVICES• ESTÁNDARES (I): SOAP − SOAP: Simple Object Access Protocol • Creado por Microsoft e IBM. A diferencia de DCOM y CORBA, SOAP usa el código fuente en XML, que facilita la eliminación de errores. • Permite el intercambio de información estructurada y con tipos entre entidades (peers) descentralizadas • Permite codificación y empaquetamiento basado en XML para intercambiar datos como mensajes o RPCs
  52. 52. WEB SERVICES• ESTÁNDARES (II): WSDL • SOAP permite expresar invocaciones y respuestas sueltas, pero también es necesario describir los servicios, como colecciones de operaciones y respuestas. • Web Service Description Language fue desarrollado por Microsoft e IBM para describir servicios Web. • Independiente del método de transporte o método de codificación final. • Las descripciones WSDL son complejas y difíciles de construir manualmente • Los fabricantes ofrecen generadores automáticos de documentos WSDL: − Microsoft SOAP Toolkit for COM − IBM WebServices Toolkit: Java, EJBs, COM − .NET(fue diseñado para trabajar con Web Services)
  53. 53. WEB SERVICES• ESTÁNDARES (III): UDDI Universal Description, Discovery and Integration − Desarrollado por IBM, Microsoft y Ariba − Permite mantener un registro global de Web Services − Con operaciones para: publicar (publish), ojear (browse) y retirar (un-publish) Web Services − Cualquier aplicación (incluidos Search engines) pueden consultarlo para descubrir servicios.
  54. 54. WEB SERVICES• SOA vs WEB SERVICES − SERVICE ORIENTED ARCHITECTURE • Integra las arquitecturas de “web services”con los sistemas antiguos de una manera débilmente acoplada. • Habilita funcionalidades de alto nivel, como Identidad, Seguridad,Gestión, Modelaje u orquestación de Procesos de Negocio. − Web Services • Expone la lógica de negocio como servicios autodescritos, débilmente acoplados • Usa protocolos de bajo nivel e infraestructura
  55. 55. RECOMENDACIONES• RECOMENDACIONES PRÁCTICAS DE SUN PARA EL TRABAJO CON SOA − Exponer las aplicaciones antiguas como Web Services (crear interfaces hacia ellos) − Presentar o construir las nuevas aplicaciones en base a Web Services − Coreografiar u orquestar Web Services en forma de aplicaciones compuestas − Proporcionar acceso seguro con Directory Server y Access Manager.
  56. 56. SOI• SOI: SERVICE ORIENTED INTEGRATION − Consiste en la integración basada en Web Services en un contexto SOA. − Es la aplicación sistemática de la tecnología de Web Services para crear aplicaciones compuestas, mediante la integración e interoperabilidad de sistemas, a nivel de lógica de negocio y usando Interfaces de Programación (API’s). − Este objetivo comienza aplicando la tecnología JBI (Java Business Integration) y posteriormente, aplicar ESB (Enterprise Service Bus).
  57. 57. JBI• JAVA BUSINESS INTEGRATION (JBI) − Especificación del Java Community Process (JSR208) marzo 2003 − Estándar de Java aprobado el 20 de Julio 20 de 2005 − JBI es la base de Integración basada en SOA• JBI ofrece: − Arquitectura de Interoperabilidad • Una arquitectura abierta basada en SOA para que las tecnologías y servicios de Integración puedan colaborar entre sí − Ensamblaje de Servicios • CSD Composite Service Descriptor: Un documento único que describe una “aplicación” SOA - un “super .jar”
  58. 58. JBI• JBI − Es una arquitectura de integración especificando componentes plug-in que interoperan intercambiando mensajes. − Los componentes JBI proporcionan servicios, consumen servicios y a veces ambas cosas. − Tenemos dos tipos de componentes: • Service Engines (SE): proporcionan la lógica de negocio y los servicios de transformación. • Binding Components: Proporcionan conectividad para aplicaciones que son externas a JBI. − El intercambio de mensajes entre componentes se realiza mediante el Normalized Message Router (NMR). • El NMR enruta mensajes entre consumidores y proveedores.
  59. 59. JBI• CARACTERÍSTICAS DE JBI − “Meta-Contenedor” de servicios básicos • Mensajería • Enrutamiento • Binding de protocolos − Infraestructura SOA • Acoplamiento débil • Intercambio de Mensajes WSDL − Dos tipos de componentes (como ya hemos visto): • Motores (Service Engines): − proveen lógica y funciones de negocios • Bindings: − Proveen protocolos de comunicaciones para el acceso a servicios remotos
  60. 60. JBI• META-CONTENEDOR JBI
  61. 61. JBI• ENSAMBLAJE DE SERVICIO JBI (Service Assembly) – Es un único documento XML que contiene los artifacts (un ZIP con los instaladores de componentes BC/SE) y la información de routing de una aplicación SOA.
  62. 62. JBI• Beneficios aportados por JBI − JBI es a SOA lo que J2EE es al desarrollo de aplicaciones − JBI es una infraestructura abierta, basada en plug-ins, para desplegar aplicaciones compuestas (composite aplications) − Efectúa el papel de una capa de mensajería SOA para la plataforma JAVA − Es la pieza estándar para la construcción de ESB’s (enterprise Service Bus) para la plataforma JAVA − Permite a los desarrolladores sacar jugo a las tecnologías BPEL y XSLT.
  63. 63. ESB• ENTERPRISE SERVICE BUS − Tecnologías previas que pretendían solucionar el problema de la integración de plataformas y aplicaciones heterogéneas: • Enterprise Applicaton Integration (EAI). • Business-to-Business (B2B). • Service Oriented Architecture (SOA) • Web Services − Desventajas: • Tecnologías propietarias • Caras • Costosas en tiempo de implantación
  64. 64. ESB• Aproximación ESB al problema de la integración − Solución basada en estándares (elimina algunas desventajas de soluciones anteriores) − Facilita la tarea de la integración proporcionando servicios de infraestructura (routing, seguridad, orquestación, etc.), de modo que cada aplicación no tenga que implementarlos de manera propietaria, sino USARLOS.• Atributos de una infraestructura ESB − Distribuida. − Basada en mensajes − Basada en estándares abiertos − Confiable

×