Arquitectura SOA

Otras Arquitecturas y
metodologías SOA
Pablo García Sánchez

pgarcia@atc.ugr.es
Departamento de Arquitectura y Tecnología de Computadores
Curso Web 2.0 Arquitectura Orientada a Servicios en Java
Escuela de Posgrado
Febrero/Marzo de 2010

¿Qué vamos a aprender?


Otras SOA en Java:





OSGI
ebXML

Metodologías



BCM





RosettaNet
UMM

Proyectos de lavida real

Introducción





SOA no es sólo Web Services, SOAP y BPEL!
Es cualquier sistema software que permita
descubrir e invocar servicios (remotos o
locales)
Pueden basarse en una especificación pública
o no

Web 2-0: Arquitectura Orientada a Servicios en Java

3

OSGi


OSGi (Open Service Gateway Initiative) define
una arquitectura SOA dentro de una máquinavirtual de Java para integración de sistemas
heterogéneos. Además, proporciona
características muy deseables:


Abstracción de paquetes



Gestión del ciclo de vida



Empaquetamiento



Versionado
Web 2-0: Arquitectura Orientada a Servicios en Java

4

OSGi (II)





Bundle: Jar con el fichero MANIFEST
adaptado
Servicio: conecta bundles de manera dinámicaComponente: Clase dentro de un bundle junto
con una descripción en XML interpretada en
tiempo de ejecución->Servicios Declarativos

Web 2-0: Arquitectura Orientada a Servicios en Java

5

OSGi (III)

Web 2-0: Arquitectura Orientada a Servicios en Java

6

OSGi (III)

Ejemplo de MANIFEST.MF
Web 2-0: Arquitectura Orientada a Servicios en Java

7

OSGi (IV)

Ejemplo deDescriptor
de Servicio

Web 2-0: Arquitectura Orientada a Servicios en Java

8

R-OSGi

Problema de OSGi: imposibilidad de invocar servicios
remotos
–Uso de conectores basados en UPnP y Jini: INVASIVOS
R-OSGi es un midleware para distribuir de forma
transparente servicios en red
Crea proxies que actúan como bundles normales que se
encargan de comunicar con otros bundles distribuidos

Web2-0: Arquitectura Orientada a Servicios en Java

9

ebXML


Es una arquitectura completa para crear un
mercado electrónico global donde las empresas
puedan:



Encontrarse unas a otras
Realizar negocios mediante el intercambio de
mensajes de negocio basados en XML

Web 2-0: Arquitectura Orientada a Servicios en Java

10

ebXML (II)


SOAP, WSDL, UDDI por sí solos noson
adecuados






WSDL no puede hacer frente a colaboración de
negocio
SOAP (en su forma básica) no proporciona
mensajería segura y confiable
UDDI no proporciona capacidad de repositorio para
objetos de negocio

Web 2-0: Arquitectura Orientada a Servicios en Java

11

WS Vs. B2B
Web Services

B2B



Interacción simple



Interacción compleja



Orientadosal consumidor



Orientados al negocio



Procesos “ligeros”



Procesos “pesados”



Sin colaboración de
negocio



Con colaboración de
negocio



Sin perfil de socio



Soporta perfil de socio



No seguro, no confiable



Seguro, confiable



No soporta no-repudiación



Soporta no-repudiación



No soporta repositorio

Registro y Repositorio

Web 2-0: Arquitectura Orientada a Servicios en Java

12

Modulos de la Arquitectura de
ebXML





Business Process Specification
Partner Profile and Agreements (ISO 150001:2004)
Registro y Repositorio (ISO 15000-3:2004 e
ISO 15000-2:2004)



Messaging Service (ISO 15000-4:2004)



Core Components (ISO 15000-5:2005)



¡Pueden ser usados porseparado!
Web 2-0: Arquitectura Orientada a Servicios en Java

13

Descripción general de un
sistema ebXML

Web 2-0: Arquitectura Orientada a Servicios en Java

14

Aproximación basada en
Servicios Vs basada en contrato

Web 2-0: Arquitectura Orientada a Servicios en Java

15

Modelado Top-down vs. Bottomup


ebXML






Utilizar metodologías para ebXML (como UMM)...