2. • ÍNDICE DE CONTENIDOS:
− COMPONENTES
− SERVICIOS WEB
− ARQUITECTURAS ORIENTADAS A SERVICIO –SOA
− XML Y JAVA
− SOAP
− SEGURIDAD XML Y SERVICIOS WEB
3. WEB SERVICES
» PARTE II: FUNDAMENTOS TEÓRICOS
DE LOS WEB SERVICES
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. 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. 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. 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. 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. 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
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. 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. 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. 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. 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)
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. 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. 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. 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 (W3C's 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. 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. Soporte a Web Services
• Ejemplo 3
• Ejemplo 4
− Gracias a las annotations, no es necesario usar descriptores en este
ejemplo
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. 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. 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. 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. Prácticas
Preparando 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. 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. 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. 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
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. 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. 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. 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. 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. 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. 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. SOA
Escenario SOA
•Fácil de compartir
•Reusabilidad
•Interoperabilidad
•Escalabilidad
•Flexibilidad
•Desacoplado
•Sencillo
•Desarrollo Rápido
•Ágil
•Rentable en costes
40. SOA
• Posibilita un flujo sencillo para el desarrollo
Usamos servicios que a su vez usan a otros servicios
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
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. 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..
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. 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.
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. 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. 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. 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. 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. 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. 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. 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. 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. 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
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. 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. 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. 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