Anexo7 - arq-Rfc-01-Pautas y Recomendaciones para Soa v0.91

Service Oriented Architecture
(SOA)
Pautas y Recomendaciones
Versin 0.91 primera iteracin

Versin 0.9 - 12/7/2006 Pgina 2 de 30

ARQ-RFC-01-Pautas y Recomendaciones para SOA

1 Informacin del Documento
1.1 Identificacin y versin
ARQ-RFC-01-Pautas y recomendaciones para SOA (Service Oriented Architectures)
Versin 0.91 (pre-release, primera iteracin)

1.2 Resumen
Se presenta un conjunto de PAUTAS (de aplicacin obligatoria) y RECOMENDACIONES (de
utilizacin sugerida) relativas a la aplicacin de estilos de Arquitecturas Orientadas a Servicios
en el BPS.

1.3 Estado
RFC Request For Comments

Liberado para ser comentado por parte de los Arquitectos de los Centros de Desarrollo,
Proveedores de servicios tercerizados, ASIT y CSEI.

1.4 Historia de Revisiones
26/06/2006 Creacin
07 al 11/07/2006 Ajustes finales pre-RFC
12/7/2006 Liberacin RFC

1.5 Autores
Edicin Revisin Coordinacin
Mnica Borso
Virginia Casciato
Heber Rodrguez
Mauricio Papaleo
Carlos Surez
Jorge Surez

Versin 0.9 - 12/7/2006 Pgina 3 de 30


2 Tabla de Contenidos
1 INFORMACIN DEL DOCUMENTO 2
1.1 IDENTIFICACIN Y VERSIN 2
1.2 RESUMEN 2
1.3 ESTADO 2
1.4 HISTORIA DE REVISIONES 2
1.5 AUTORES 2
2 TABLA DE CONTENIDOS 3
3 PRESENTACIN 5
4 DEFINICIONES Y CONCEPTOS GENERALES 6
4.1 ALGUNAS DEFINICIONES DE ARQUITECTURA 6
4.2 DEFINICIN DE COMPONENTE 6
4.3 ALGUNAS DEFINICIONES DE SOA 6
4.4 DOS TAXONOMAS DE LA SOA 7
4.5 SERVICIOS 8
4.5.1 Arquitectura de Servicios 9
4.5.2 Estructura y caractersticas de los Servicios 10
4.5.3 Los Principios Comunes de la Orientacin a Servicios: 11
4.6 OTRAS DEFINICIONES DEL ENTORNO SOA 11
5 DEFINICIONES SOA EN BPS 12
5.1 ALGUNAS DEFINICIONES 12
5.1.1 Principales requerimientos no funcionales 12
5.1.2 Componentes de Servicio 12
5.1.3 Servicios 12
5.1.4 Primera categorizacin de los Componentes de Servicio 12
6 MECANISMOS DE INTEGRACIN MULTIPLATAFORMA 13
6.1 PAUTA DE UTILIZACIN DE PROXIES RMI - .NET REMOTING: 13
6.2 PAUTA DE APLICACIN COLAS DE MENSAJES 13
6.3 PAUTA DE APLICACIN INTERMEDIARIOS DE INTEGRACIN (BROKERS) 14
6.4 PAUTA DE APLICACIN SOBRE ESTNDARES WS-* 14
7 CONSIDERACIONES DE DISEO 15
7.1 DISEO DE SERVICIOS 15
7.2 BUENAS PRCTICAS 15
7.2.1 Adoptar los nombres de los Servicios que maximicen la consumibilidad 15
7.2.2 Escoger bien la Granularidad 15
7.2.3 Disearlos para que sean cohesivos y completos. 16
7.3 RECOMENDACIONES 16
7.3.1 Manejar mltiples patterns de invocacin 16
7.3.2 Modelar los servicios usando transiciones de estado 17
7.4 PAUTAS 17
7.4.1 Ofrecer interfaces sin estado (stateless) 17
7.4.2 Modelar para las Agregacin/Composicin/Orquestacin/Coreografa. 17
7.4.3 No concebirlos como aplicaciones enteras. 17
7.5 PRINCIPIOS PARA EL DISEO DE LAS OPERACIONES DE LOS SERVICIOS 18
7.5.1 Disear para que representen acciones del negocio 18
7.5.2 Definir con parmetros de gran granularidad 18
7.5.3 Disear para la concurrencia 18
7.6 PASOS PARA LA DEFINICIN DE UN SERVICIO 18

Versin 0.9 - 12/7/2006 Pgina 4 de 30

8 ENFOQUES Y TCNICAS PARA LA IDENTIFICACIN DE SERVICIOS 19
8.1 SEIS ENFOQUES PARA CREAR UNA SOA 19
8.2 RECOMENDACIONES SOBRE ENFOQUES PARA CREAR UNA SOA 19
8.3 TCNICAS DE IDENTIFICACIN DE SERVICIOS 20
8.3.1 Anlisis de documentos 20
8.3.2 Descomposicin de dominio 20
8.3.3 Sntesis de sistemas existentes 21
8.3.4 Meet-in-the-middle 21
8.4 RECOMENDACIONES TCNICAS DE IDENTIFICACIN DE SERVICIOS 21
9 PRXIMA ITERACIN 22
10 ANEXO: DEFINICIONES Y GLOSARIO 23
10.1 COMPONENTES 23
10.1.1 Definicin clsica de COMPONENTE: 23
10.1.2 COM 23
10.1.3 Enterprise Beans 23
10.1.4 CORBA 24
10.2 CARACTERSTICAS DE LOS COMPONENTES 24
10.3 DEFINICIONES BSICAS AUXILIARES 25
10.3.1 En el entorno Java 26
10.3.2 En el entorno .NET 27
10.4 MECANISMOS DE INTEGRACIN MULTIPLATAFORMA 28
10.4.1 Apoderados RMI - .NET Remoting (Proxies) 28
10.4.2 Colas de Mensajes (Message Queues) 28
10.4.3 Intermediarios de Integracin (Brokers) 28
10.4.4 Servicios Web (WS) 29
11 REFERENCIAS 30

Versin 0.9 - 12/7/2006 Pgina 5 de 30


3 Presentacin

El presente documento establece pautas y recomendaciones para la creacin y evolucin de
sistemas segn un estilo de arquitectura orientado a servicios en el BPS.

Est estructurado en un cuerpo principal con algunas definiciones bsicas (incluidas con el
objetivo de uniformizar terminologa) y las pautas y recomendaciones correspondientes, y un
anexo con definiciones ms amplias.

Se incluyen nicamente los aspectos seleccionados para la primera iteracin. A sta
seguir al menos una segunda iteracin con los contenidos tentativamente descriptos en
el captulo final.

Versin 0.9 - 12/7/2006 Pgina 6 de 30


4 Definiciones y conceptos generales
4.1 Algunas Definiciones de ARQUITECTURA
ANSI/IEEE Std 1471-2000: La organizacin fundamental de un sistema, embebida en sus
componentes, las relaciones entre ellos y su entorno y los principios que gobiernan su diseo y
evolucin

TOGAF: En TOGAF, arquitectura tiene dos significados dependiendo del contexto en que se
use:
La descripcin formal de un sistema, o un plan detallado de un sistema a nivel de sus
componentes que gua su implementacin.
La estructura de sus componentes, sus inter-relaciones, y los principios y guas que
gobiernan su diseo y evolucin a lo largo del tiempo.

En forma tentativa, este Comit utilizar las definiciones propuestas en el TOGAF.

4.2 Definicin de COMPONENTE
SZYPERSKY: Un componente es una unidad de composicin de aplicaciones de software, que
posee un conjunto de interfaces y un conjunto de requisitos, y que ha de poder ser desarrollado,
adquirido, incorporado al sistema y compuesto con otros componentes de forma independiente
en tiempo y espacio [1998]

4.3 Algunas Definiciones de SOA
W3C: Conjunto de componentes que pueden ser invocados, cuyas descripciones de interfaces
se pueden publicar y describir.

CBDI: Estilo resultante de polticas, prcticas y frameworks que permiten que la funcionalidad
de una aplicacin se pueda proveer y consumir como conjuntos de servicios, con una
granularidad relevante para el consumidor.

IBM: SOA representa una forma de construir sistemas distribuidos que permite ofrecer las
funcionalidades de una aplicacin como servicios tanto para aplicaciones de usuario final a
otros servicios.

Martn Cabrera: SOA es un estilo de arquitectura que promueve descomponer la lgica
funcional de una aplicacin en unidades autnomas denominadas servicios

BEA: Es una estrategia de IT que organiza las funciones discretas contenidas en las
aplicaciones empresariales en servicios estandarizados, interoperables, de forma que puedan
ser combinados y reusados fcil y rpidamente para adaptarse a los requerimientos del
negocio.

OASIS: SOA es un paradigma para organizar y utilizar capacidades distribuidas que pueden
estar bajo el control de diferentes dominios. Provee una manera uniforme de ofrecer, descubrir,
interactuar con ellos y sus capacidades de uso para producir el efecto deseado consistente con
precondiciones y expectativas medibles.

Gartner: SOA es una arquitectura de software que comienza con una definicin de interface y
construye toda la topologa de la aplicacin como una topologa de interfaces, implementaciones
y llamados a interfaces. Sera mejor llamada arquitectura orientada a interfaces. SOA es una
relacin de servicios y consumidores de servicios, ambos suficientemente amplios para

Versin 0.9 - 12/7/2006 Pgina 7 de 30

representar una funcin de negocios completa.

SUN: Una arquitectura orientada a servicios es una estrategia donde las aplicaciones hace uso (o se
basan) en servicios disponibles en una red. Siendo una manera de compartir funciones (tpicamente
de negocios) en una manera flexible y extendida.

En forma tentativa, este Comit utilizar las definiciones propuestas por BEA y Gartner.

4.4 Dos taxonomas de la SOA
Se incluyen en este prrafo dos diagramas representando los distintos componentes de una
Arquitectura Orientada a Servicios.

El diagrama anterior muestra una vista tecnolgica de los distintos aspectos de SOA, es decir
con una fuerte orientacin a su implementacin.

Versin 0.9 - 12/7/2006 Pgina 8 de 30


Funciones:
1 Transporte: Mecanismo utilizado para trasladar las peticiones desde el cliente, hasta el
proveedor del servicio, y viceversa.
2 Protocolo de comunicacin: Es el sistema de comunicacin entre el cliente y el
proveedor de servicios.
3 Descripcin del servicio: Es un esquema utilizado para describir qu servicio es, cmo
se le puede invocar, y cules son los datos necesarios para realizar su invocacin.
4 Servicio: Es la implementacin del servicio.
5 Proceso de negocio: Es una coleccin de servicios, invocados en una determinada
secuencia, con un conjunto particular de reglas para satisfaces un requisito de negocio.
6 Registro de servicios: Es un repositorio de servicios y datos, usado por los proveedores
de servicio y publicar los servicios, y para los clientes, donde buscarlos.
Calidad del servicio:
1 Polticas: Son un conjunto de reglas bajo las cuales, un proveedor de servicio hace que el
servicio est disponible para los clientes.
2 Seguridad: Son un conjunto de reglas que podran ser aplicadas en la identificacin,
autorizacin y control de acceso a los servicios, por parte del cliente.
3 Transaccin: Conjunto de atributos que podran ser aplicados sobre un grupo de servicios
para devolver un conjunto de datos consistentes.
4 Gestin: Conjunto de atributos que podran ser aplicados para gestionar los servicios
proporcionados.

4.5 Servicios
Mientras los componentes son la mejor forma de implementar servicios, se debe entender que
una aplicacin correctamente basada en componentes, no necesariamente es una aplicacin
correctamente orientada a servicios.

Versin 0.9 - 12/7/2006 Pgina 9 de 30

La clave para comprender esta diferencia radica en ver como una arquitectura orientada a
servicios (SOA) implica una capa adicional de arquitectura (una nueva abstraccin)
implementada con una granularidad ms gruesa y ubicada ms cerca del consumidor de la
aplicacin.

Figura: Capas de Aplicacin: Servicios, Componentes y Objetos.

Un servicio es una forma de exponer una visin externa de un sistema, con reuso interno y una
composicin tradicional basada en el diseo de componentes.

En una SOA, un servicio mapea una funcin identificada durante un proceso de anlisis del
negocio; dependiendo de la funcin del negocio de que se trate, la granularidad del mismo
puede ser mas o menos fina o gruesa. Los servicios no se disean en base a las entidades de
negocio; cada servicio es una unidad que maneja operaciones a travs de un conjunto de
entidades de negocio.

Un servicio es una unidad de procesamiento de granularidad gruesa, que consume y produce un
conjunto de objetos pasados por valor, implementada sobre una coleccin de componentes que
trabajan en colaboracin para entregar la funcionalidad del negocio que el mismo representa; los
componentes son de una granularidad ms fina que la de los servicios. Mientras un servicio
mapea una funcionalidad del negocio, un componente tpicamente mapea las entidades del
negocio y las reglas que las operan.

4.5.1 Arquitectura de Servicios
El siguiente diagrama muestra la interrelacin entre las arquitecturas de Aplicacin, Servicios y
Componentes, y la implementacin de procesos de negocio mediante orquestacin de servicios.

Versin 0.9 - 12/7/2006 Pgina 10 de 30


4.5.2 Estructura y caractersticas de los Servicios
Los servicios son una forma de encapsular componentes/programas reusables (building blocks)
para proveer funcionalidad a otros usuarios y a otros servicios.

Cuando un servicio provee servicios a otro, al servicio que invoca lo llamaremos consumidor,
para distinguirlo del usuario. Con los servicios se interacta mediante el intercambio de
mensajes.

Un servicio consiste de 3 elementos:

1 Contrato: El uso de la funcionalidad que provee un servicio es gobernada por un contrato.
Especifica el propsito, la funcionalidad, las restricciones y el modo de uso del servicio. Es
definido POR EL NEGOCIO, en TRMINOS del NEGOCIO.
2 Implementacin: La funcionalidad en s misma que provee el servicio: puede ser realizada
utilizando cualquier tecnologa.
3 Interfaces: Para acceder a la funcionalidad el consumidor necesita interfacear con el
servicio. Proveen la forma de acceder a la funcionalidad de acuerdo al contrato. Un servicio
puede ofrecer mltiples interfaces para permitir su consumo de diferentes maneras.

1. Caractersticas Funcionales:

1 Invocacin: sincrnica o asincrnica
2 Intercambio: uni-direccional, bi-direccional
3 Complejidad: referido a la granularidad

Versin 0.9 - 12/7/2006 Pgina 11 de 30

2. Caractersticas No-Funcionales:

1. Requerimientos de Volmenes
2. Calidad del Servicio
3. Tiempo de ejecucin del Servicio

4.5.3 Los Principios Comunes de la Orientacin a Servicios:

1. Comparten un contrato formal
2. Bajamente acoplados
3. Abstraen la lgica que existen debajo (autocontenidos y modulares)
4. Interoperables
5. Componibles
6. Reusables
7. Autnomos
8. Sin estado
9. Descubribles (transparentes a la ubicacin)

4.6 Otras Definiciones del entorno SOA

Servicios: Entidades lgicas - Contratos definidos por una o ms interfaces pblicas.

Service Provider: Entidad de software que implementa una especificacin de servicio.

Consumidor: Entidad de software que llama a un service provider. Tradicionalmente se lo llama
cliente. Puede ser una aplicacin final u otro servicio.

Service Locator: Tipo especfico de service provider que acta como registry y permite buscar
interfaces de service providers y sus ubicaciones.

Service Broker: Tipo especfico de service provider que puede pasar requerimientos
de servicios a otros service providers.

Versin 0.9 - 12/7/2006 Pgina 12 de 30


5 Definiciones SOA en BPS
En este captulo se incluirn las definiciones correspondientes a la visin BPS de la Arquitectura
Orientada a Servicios. Las mismas estn en elaboracin, identificndose al momento de
liberacin de este RFC dos fuentes principales:

1. las pautas de ASIT
2. la especificacin de la Service Component Architecture, trabajo realizado en forma
conjunta por varias empresas [12]

El Comit est trabajando en la generacin de una pauta conceptualmente abierta,
implementable en cualquier tecnologa, construida sobre elementos claramente definidos y una
nomenclatura no ambigua. En futuras versiones de este documento se irn presentando
avances y refinamientos sucesivos.

5.1 Algunas definiciones
Las definiciones que siguen fueron incluidas en la presentacin realizada para el lanzamiento del
Comit.

5.1.1 Principales requerimientos no funcionales
Encapsulamiento
Conectividad
Flexibilidad
Reuso
Independencia de plataforma

5.1.2 Componentes de Servicio
Implementan la lgica y la encapsulan
Granularidad a establecer
Implementados internamente en una nica tecnologa (homogneos)

5.1.3 Servicios
Constituyen la nica interfaz de acceso a la lgica implementada en los componentes de
servicio
Son invocables como servicio externo, no como un mdulo en una biblioteca

5.1.4 Primera categorizacin de los Componentes de Servicio
Segn la funcin que cumplen (principalmente), pueden identificarse en primera instancia las
siguientes categoras.

1. Administracin de datos
2. Lgica de negocios bsica
3. Lgica de negocios compuesta
4. Interaccin con el usuario
5. Componentes utilitarios comunes

Versin 0.9 - 12/7/2006 Pgina 13 de 30


6 Mecanismos de integracin multiplataforma
En este captulo se describen algunos mecanismos de integracin multiplataforma que permiten
la invocacin de mtodos o servicios distribuidos y que pueden servir para la implementacin de
una capa de servicios que oculte la tecnologa de implementacin subyacente.

Los siguientes mecanismos aportan a la construccin:

1. Apoderados (Proxies) RMI - .NET Remoting
2. Colas de Mensajes (Message Queues)
3. Intermediarios de Integracin (Brokers)
4. Servicios Web (WS)

En el Anexo se describen las principales caractersticas de cada mecanismo

6.1 Pauta de utilizacin de Proxies RMI - .NET Remoting:
Se establece como PAUTA que esta estrategia de integracin no deber aplicarse en la
construccin de servicios de consumo externo (orientado al Usuario externo va Web) y deber
evitarse en la integracin de aplicaciones dentro de la Institucin (Pattern Enterprise Application
Integration o EAI) en atencin a que:

tanto la JVM como el CLR tienen formatos propios de serializacin de invocaciones.
es necesario piezas de terceros para filtrar este tipo de invocaciones salientes,
mapendolas adecuadamente a mensajes RMI serializados (Por ej.: JNBridge y J-
Integra.).
lo mismo, para las invocaciones desde JVM en formato RMI, que las transforman en
pedidos .NET Remoting.
tiende a crear acoplamiento entre aplicaciones al permitir compartir objetos, sea por las
interfases remotas invocadas como por los argumentos enviados
las implementaciones de estas soluciones pueden no contemplar el manejo de la
seguridad o la coordinacin de transacciones distribuidas.

En general, para servicios consumidores internos puede aplicarse escenarios del tipo

RMI-RMI
.NET Remoting -.NET Remoting

y restrictivamente

RMI-.NET Remoting

si se tienen restricciones de performance, costo, oportunidad, que impongan sacar ventaja de su
alto rendimiento, en razones de que:

el protocolo de transporte es el TCP, menos cargado que HTTP.
la serializacin es binaria (empaquetada), con menor consumo de recursos.

6.2 Pauta de aplicacin Colas de Mensajes
En aplicaciones complejas, este mecanismo basado en eventos (Event-Driver Architecture -
EDA) rpidamente puede quedar fuera de control al generar mltiples dependencias.

Versin 0.9 - 12/7/2006 Pgina 14 de 30


Se PAUTA EDA como enfoque complementario a soluciones basadas en extraer
aspectos de procedimiento de varios servicios dentro de uno dedicado, donde se
centralizar la definicin del proceso y el control de las acciones del servicio de negocio
paso a paso, moviendo el sistema de un estado a otro. En este enfoque cada paso
deber llamar una operacin de negocio provista por otro servicio o por un componente.

6.3 Pauta de aplicacin Intermediarios de Integracin (Brokers)
Se PAUTA Intermediarios de Integracin (Brokers) como pieza clave en la integracin
de aplicaciones y la construccin de una arquitectura de servicios, soporte de funciones
en procesos de negocio.
El BPS ha definido Biztalk Server como Integration Broker estndar.

6.4 Pauta de aplicacin sobre estndares WS-*
Se establece como PAUTA la utilizacin de Servicios Web como pieza clave en la integracin de
aplicaciones y la construccin de una arquitectura de servicios, soporte de funciones en
procesos de negocio.

El BPS ha definido como estndares los registrados por los documentos llamados Basic Profile
y Security Basic Profilede WS-I

Basic Profile 1.2 y 2.0, fecha de revision Mayo /2006 o posterior
Security Basic Profile 1.0, fecha de revision Mayo /2006 o posterior

Es necesario tener en cuenta las directrices y evolucin de las tres organizaciones involucradas
en la definicin, desarrollo y publicacin de estndares WS-*:

World Wide Web Consortium (W3C)
OASIS
Web Services Interoperability (WS-I)

a la hora de disear SOA mediante Servicios Web.

Versin 0.9 - 12/7/2006 Pgina 15 de 30


7 Consideraciones de Diseo
7.1 Diseo de Servicios
Siempre se deben pensar los Servicios desde el punto de vista de los Consumidores. Adoptar
esa postura facilita muchas de las decisiones de diseo de los mismos, desde varios puntos de
vista. Este criterio deber tenerse muy presente a la hora de disear un Servicio.

Recordando que un servicio es una agrupacin lgica de operaciones cuyas interfaces son
publicadas en algn formato pre-establecido, veremos algunas recomendaciones que aplican al
servicio como un todo.

7.2 Buenas prcticas
7.2.1 Adoptar los nombres de los Servicios que maximicen la consumibilidad
Esto permite que el desarrollador pueda identificar los servicios y las operaciones de manera
sencilla. Los nombres deben de ser significativos del dominio del negocio que se est
desarrollando, favoreciendo en la nomenclatura la utilizacin de aspectos del negocio frente a los
aspectos tcnicos.

Los servicios deben de ser nombrados utilizando nombres sustantivos, y las operaciones
utilizando verbos.

Ejemplo 1: Nombrando Servicios utilizando frases verbales y lenguaje tcnico

Servicio: ManejarDatosClientes
Operaciones: InsertarRegistroCliente,
ModificarRegistroCliente,
. . . . .
. . . . .

Ejemplo 2: Nombrando los servicios usando nombres y frases verbales que son conceptos del
Negocio

Servicio: ServicioClientes
Operaciones: CrearNuevoCliente,
CambiarDireccionCliente,
CorregirDireccionCliente,
. . . .
. . . .

Puede ser necesario contar con un glosario de trminos de negocios, en ese caso el glosario
debe tener un administrador responsable.

7.2.2 Escoger bien la Granularidad
No existe una forma sencilla de determinar la granularidad de un servicio, entendida como la
cantidad de operaciones que el servicio debe ofrecer. Algunas orientaciones que influyen a la
hora de determinar la granularidad:

Usualmente los Servicios son la unidad de testeo y de release. Si existen muchas
operaciones, muchos consumidores van a utilizar el servicio; si se requiere cambiar una

Versin 0.9 - 12/7/2006 Pgina 16 de 30

operacin que es utilizada por un conjunto de consumidores, el servicio entero deber
ser re-deployed, lo que impactar a todos sus consumidores.
No ir a los extremos: pocos servicios con muchas operaciones vs muchos servicios con
pocas operaciones.
Mantener un equilibrio entre mantenibilidad, operabilidad y consumibilidad.

7.2.3 Disearlos para que sean cohesivos y completos.
Las operaciones que brindan deben de ser funcionalmente cohesivas, o sea que las operaciones
deben estar agrupadas por su funcin.

No deben agruparse en base a detalles de implementacin o al patrn de secuencia lgica de
uso (algunas veces puede parecer que algunas operaciones deberan ir juntas, pero analizadas
desde el punto de vista funcional, tal vez se encuentren en diferentes servicios).

El buen uso de la nomenclatura nombre-verbo (servicio y operaciones) puede ayudar, uno puede
hacerse la pregunta: Este verbo es alguna accin que el nombre realiza?

Por completitud, se entiende que debe ofrecer todas las operaciones necesarias para realizar el
servicio (siempre desde el punto de vista funcional), entendiendo bien que es lo que necesitan
los consumidores conocidos e infiriendo operaciones que tambin puedan ser necesarias para
otros consumidores an no conocidos.

Ejemplo 3: Ejemplo de Completitud

Servicio: ServicioCelulares
Operaciones: CrearCelular,
CambiarCelular,
ConsultarCelular,
EliminarCelular,
DesactivarCelular

Suena razonable que -a pesar de no haber sido pedido explcitamente por los consumidores
identificados- se va a necesitar tambin la operacin ActivarCelular, por lo que el servicio debera
ofrecerla desde un principio.

7.3 Recomendaciones
7.3.1 Manejar mltiples patterns de invocacin
Un consumidor debera usar cdigo similar para invocar servicios usando una variedad de
patterns de invocaciones diferentes, como por ejemplo:

Tradicional (SOAP/HTPP)
Asncrona (SOAP/Message Queues)

Como RECOMENDACION se preferirn las invocaciones remotas y asncronas por sobre las
invocaciones locales y sincrnicas.

Esto incide directamente en el diseo. No es lo mismo pensar en invocaciones locales y
sincrnicas que en invocaciones remotas (hay que tener en cuenta la red) y asncronas (se
deben pensar mecanismos compensatorios, por ejemplo).

Ejemplo 4: Ejemplo de un mal diseo para las invocaciones remotas

Servicio: ServicioCelulares
Operaciones: . . . .

Versin 0.9 - 12/7/2006 Pgina 17 de 30

ObtenerPropietarioCelular,
ObtenerFacturacinCelular,
ObtenerFechaDesactivacionCelular

Estas operaciones (continuando con el ejemplo de los celulares) parecen ser razonables en un
ambiente local. Pensando en invocaciones remotas, esto es altamente ineficiente; imaginemos
un listado por celular, para cada celular se debern realizar 3 invocaciones por la red para
obtener los datos de un solo celular. En este caso pensndolo desde el punto de vista del
consumidor (remoto) se debera manejar la granularidad de las operaciones de forma tal que en
una sola operacin se pudiera obtener los datos completos.

7.3.2 Modelar los servicios usando transiciones de estado
Estas transiciones de estado deben reflejar el ciclo de vida de los objetos del negocio.

Es necesario acompaar la documentacin de los servicios y las intefaces con un buen diagrama
de estados indicando en que transicin y con que finalidad se usa cada interface.
Probablemente pueda resultar conveniente agrupar los servicios de acuerdo al estado en que se
encuentran los objetos de negocio, resultando de ello una mayor consumibilidad (pensando
siempre en la forma en que el consumidor los va a necesitar).

7.4 Pautas
7.4.1 Ofrecer interfaces sin estado (stateless)
Los servicios son diseados para el reuso, deben ser escalables y estar preparados para ser
deployados en infraestructuras de alta-disponibilidad, por lo tanto se establece la PAUTA de que
sean stateless.

Esto se debe hacer pensando en que no deben ser diseados para soportar una relacin de
largo tiempo entre el consumidor y el proveedor, ni tampoco una operacin deber depender del
estado de una invocacin previa.

En este caso siempre existe un compromiso entre la escalabilidad y las necesidades de negocio.
Tcnicamente se pueden proveer interfaces con estado, para ello existen tcnicas tales como las
cookies EJBs Stateful (en el mundo J2EE); pero estas tcnicas limitan la escalabilidad y la
libertad de la infraestructura para poder elegir diferentes formas de crecimiento (usando cookies
por ejemplo, es necesario establecer afinidad entre los clientes y los servidores web).

Estos recursos debern ser utilizados solamente con autorizacin expresa (como excepciones)
y deber estar correctamente fundamentado su uso.

7.4.2 Modelar para las Agregacin/Composicin/Orquestacin/Coreografa.
Esto debe ser tenido en cuenta desde el diseo, ya que sino pueden aparecer problemas para
componerlos si no fueron considerados en su momento.

Es muy comn no pensar en estas cosas en el momento del diseo, pero deben de ser tomadas
en cuenta, maxime que no sabemos con precisin quien puede llegar a invocar los servicios que
estn siendo creados, ni de que forma participarn en un proceso de negocio y que operaciones
se harn antes y despus de haberlos invocado.

7.4.3 No concebirlos como aplicaciones enteras.
Los servicios deben tener un alcance limitado; si se necesita mayor complejidad, se deben hacer
ms servicios, evitando la sobrecarga de un servicio con mucha funcionalidad.

Versin 0.9 - 12/7/2006 Pgina 18 de 30


7.5 Principios para el Diseo de las Operaciones de los Servicios
7.5.1 Disear para que representen acciones del negocio
Para ello se usarn nombres de verbos y sern bien especficas del negocio en vez de ser
operaciones genricas y/o puramente tcnicas. Deben corresponderse con escenarios
especficos del negocio.
Las interfaces individuales deben ser simples y sencillas de entender, incrementado la
consumibilidad.

7.5.2 Definir con parmetros de gran granularidad
Se recomienda que sean de gran granularidad por tres motivos:
Permiten crear operaciones ms flexibles, permitiendo nuevas versiones sin afectar a
los consumidores.
Una operacin con gran cantidad de parmetros es vulnerable a errores de
transposicin de parmetros en las invocaciones.
Aumentan la eficacia de la red.

Estas pautas debern ser sopesadas en el mbito de creacin de las operaciones del servicio,
pero se deber ganar en generalidad de la operacin y sus parmetros frente a
implementaciones para consumidores especficos; para ello se debe tener muy en cuenta el
negocio y los posibles consumidores.

7.5.3 Disear para la concurrencia
Se deber tener en cuenta que la invocacin de las operaciones puede ser realizada mltiples
veces por el mismo consumidor e inclusive por varios consumidores. Se debe adoptar la mejor
postura con respecto a la concurrencia de las operaciones, dependiendo del objeto de negocio
que se est modelando, intentando siempre impedir las posibles contenciones y/o problemas de
inconsistencia que pudieran aparecer debido a la mltiple invocacin de la operacin.

Se debe tender a favorecer el asincronismo y la ejecucin remota por sobre la sincrona y la
ejecucin local. De todas formas en la documentacin del servicio deber quedar expresamente
establecido de que forma se comporta la operacin y cuales son las pautas de su invocacin,
incluyendo ejemplos.

7.6 Pasos para la Definicin de un Servicio
Pretende ser una gua tentativa sobre los pasos a seguir para definir un servicio.

1. Definir el propsito del servicio (orientado al negocio)
2. Determinar la informacin que debe de manejar el servicio (metadata y schemas)
3. Identificar los potenciales consumidores.
4. Definir los aspectos de niveles de servicio, seguridad y performance que brindar el
servicio.
5. Determinar las funciones (mtodos) encapsuladas dentro del servicio, es decir el
comportamiento interno.
6. Definir las interfaces, los parmetros y el mapeo con las funciones o mtodos internos.
7. Definir como deber ser testeado el servicio (test information, service invocation,
validez de los resultados, etc)
8. Definir la documentacin a incorporar.

Versin 0.9 - 12/7/2006 Pgina 19 de 30


8 Enfoques y Tcnicas para la Identificacin de Servicios
Se describen en este captulo algunos enfoques con los que pueden encararse proyectos de
definicin de Arquitecturas Orientadas a Servicios. Luego, algunas tcnicas de identificacin de
servicios.

8.1 Seis Enfoques para crear una SOA
Enfoque Caracterizacin del Proyecto Clasificacin
Orientado a Procesos de
Negocio
Los procesos de negocio necesitan
explotar los recursos disponibles, y
cada actividad requiere invocar una
funcionalidad de IT. Para ello, cada
funcionalidad debe estar disponible en
una manera flexible.
TOP-DOWN
MDA (Model-Driven
Architecture, basada en
herramientas)
Se modela el negocio y luego las
herramientas generan el detalle
TOP-DOWN
Empaquetado de Sistemas
Legados
Se ha realizado una inversin
importante en los sistemas existentes,
pero stos no son flexibles: no se les
puede agregar funcionalidades en
forma rpida, son sistemas estancos,
con funciones cautivas.
BOTTOM-UP
Composicin de Sistemas
Legados
Descomponer los sistemas legados
monolticos en mdulos (manual o
automtico)
BOTTOM-UP
Orientado a Datos Proveer acceso a los datos usando
servicios, sin exponer esquemas o
consideraciones de implementacin
DATA-FOCUSED
Message-Driven Se necesita integrar sistemas,
comunicndolos mediante protocolos
estndar no propietarios.
SERVICE-ORIENTED
INTEGRATION of
APPLICATIONS AND
SYSTEMS.

8.2 Recomendaciones sobre Enfoques para crear una SOA
Abordar un enfoque del tipo Orientado a Procesos de Negocio lleva, sin duda a la construccin y
descripcin de una SOA, pero sera poco realista ignorar la extensin y criticidad de la plataforma
tecnolgica que hoy da soporte a dichos procesos.

Segn el escenario a atender, se recomienda aplicar los siguientes enfoques:

1. Partiendo de los sistemas actuales:

Message-Driven
Empaquetado de Sistemas Legados
Composicin de Sistemas Legados
MDA (Model-Driven Architecture, basada en herramientas)

2. Partiendo del anlisis de procesos de negocio:

Versin 0.9 - 12/7/2006 Pgina 20 de 30


MDA (Model-Driven Architecture, basada en herramientas)
Orientado a Procesos de Negocio

8.3 Tcnicas de identificacin de servicios
La identificacin de servicios puede ser hecha mediante las siguientes tcnicas:

1. Anlisis de Documentos
2. Descomposicin de Dominio (top-down)
3. Sntesis de Sistemas Existentes (bottom-up)
4. Convergencia (meet-in-the middle)

8.3.1 Anlisis de documentos
Esta tcnica involucra la revisin de los modelos de negocio y la documentacin de los sistemas
existentes para el proceso de negocio en cuestin. Las siguientes preguntas suelen surgir en
esta fase:

Los factores que motivan el proyecto SOA y sus objetivos, han sido expresados y son
medibles en trminos de los indicadores clave del desempeo del negocio?
Los procesos de negocio que van a ser materializados, han sido definidos y descriptos
a un nivel de detalle suficiente para la toma de decisiones de arquitectura de IT?
Existen puntos crticos pendientes de resolucin en la documentacin de
requerimientos no funcionales?

Si los modelos de negocio y los documentos de sistemas existentes no son suficientes, deben
planificarse actividades de anlisis adicionales, ya que no tiene sentido avanzar con el modelado
sin una base documental slida.

8.3.2 Descomposicin de dominio
Esta tcnica parte de los procesos de negocio a alto nivel, y progresivamente mejora el nivel de
detalle hasta llegar a la identificacin de los servicios necesarios para la implementacin de los
procesos en cuestin. Los pasos a seguir son:

1. Identificacin de los procesos de negocio a implementar
2. Modelado de los mismos para capturar requerimientos
3. Aplicacin de tcnicas de anlisis orientado a objetos para identificar y definir los
servicios requeridos

Debe mantenerse una perspectiva de alto nivel en este proceso, ya que el anlisis orientado a
objetos de un proceso completo puede resultar en un modelo de objetos demasiado grande e
inmanejable.

Pueden aplicarse tcnicas tradicionales de modelado de procesos y de anlisis de
requerimientos y tambin utilizarse documentos existentes (por ej.: de casos de uso)
relacionados al proceso en cuestin.

Durante el proceso debe construirse un glosario de uso comn entre analistas de negocio y de IT
y deben identificarse relaciones entre sus trminos.

Versin 0.9 - 12/7/2006 Pgina 21 de 30

8.3.3 Sntesis de sistemas existentes
En el escenario ms usual, la identificacin de servicios se inicia motivada por necesidades de
integracin de sistemas.

Esta integracin puede ser realizada mediante la descomposicin de los sistemas existentes (y
relevantes) en:

Flujos de procesos de negocio
Reglas de negocio
Componentes potencialmente reutilizables

Mediante esta descomposicin es posible sintetizar un conjunto de servicios candidatos a partir
de los componentes identificados, y sintetizar otros a partir de la adaptacin de los flujos de
proceso descubiertos.

8.3.4 Meet-in-the-middle
Esta tcnica combina las descriptas en prrafos anteriores. En paralelo se procesan los anlisis
top-down (orientado a procesos de negocio) y bottom-up (descomponiendo sistemas existentes),
buscando la convergencia o encuentro en el medio de ambos anlisis, mediante el mapeo de
requerimientos de negocio y funcionalidades de los sistemas.

8.4 Recomendaciones Tcnicas de identificacin de servicios
Considerando el alto grado de informatizacin de procesos existente en BPS, y la necesidad de
aprovechar la inversin ya realizada mediante la mayor reutilizacin posible de los sistemas
existentes, parece poco viable aplicar tcnicas como las descriptas en primer y segundo trmino
(anlisis de documentos y descomposicin de dominio), a menos que se trate de procesos an
no informatizados.

En consecuencia, y en funcin de los plazos disponibles y del avance existente en la
documentacin de los procesos de negocio involucrados, se recomienda aplicar las siguientes
tcnicas de identificacin de servicios:

1. Partiendo de los sistemas actuales:

Sntesis de Sistemas Existentes
Convergencia (meet-in-the middle)

2. Partiendo del anlisis de procesos de negocio:

Anlisis de documentos
Descomposicin de dominio

Versin 0.9 - 12/7/2006 Pgina 22 de 30


9 Prxima iteracin
Se espera incluir en la prxima iteracin los siguientes aspectos de SOA:

Patterns
Protocolos
Catlogo de servicios
Manejo de consistencia
Seguridad
Administracin
Productos

Adicionalmente se incluirn las modificaciones que surjan de los comentarios recibidos al
presente RFC.

Versin 0.9 - 12/7/2006 Pgina 23 de 30


10 ANEXO: Definiciones y Glosario

10.1 Componentes
La nocin de componente extiende la Programacin Orientada a Objetos (OOP) en el contexto
de sistemas abiertos y eventualmente distribuidos.

Def.: Se entiende por abierto aquel sistema concurrente, reactivo, independientemente
extensible, heterogneo, evolutivo y permisivo al ingreso o abandono en forma dinmica de
componentes software heterogneos.

Def.: Se entiende por plataforma de componentes al entorno de desarrollo y de ejecucin que
permita aislar la mayor parte de las dificultades conceptuales y tcnicas que conlleva la
construccin de aplicaciones basadas en los componentes del modelo [Krieger y Adler, 1998].
Es una implementacin de los mecanismos del modelo de componentes concreto, junto con una
serie de herramientas asociadas.

Ejemplos:

Componentes Modelo
ActiveX/OLE, COM
Enterprise Beans EJB/J2EE
Orbix CORBA

10.1.1 Definicin clsica de COMPONENTE:
Def.: Un componente es una unidad de composicin de aplicaciones software, que posee un
conjunto de interfaces y un conjunto de requisitos , y que ha de poder ser desarrollado ,
adquirido, incorporado al sistema y compuesto con otros componentes de forma independiente,
en tiempo y espacio [Szypersky, 1998]

Tres modelos de Componentes:

10.1.2 COM
Es una imagen binaria que sigue la especificacin del modelo de objeto comn (COM), definida
por Microsoft, segn el cual se separa el conjunto de interfaces pblicas del componente
(bsicamente, una tabla de punteros a mtodos) de su implementacin.

10.1.3 Enterprise Beans
Nota:

La especificacin J2EE no considera como componentes J2EE a los Java Beans ya que son diferentes de los
Beans Enterprise. La arquitectura de componentes JavaBeans se pueden utilizar tanto en la capa de cliente
como de servidor para manejar la comunicacin entre una aplicacin cliente o un applet y los componentes
que se ejecutan en el servidor J2EE o entre los componentes del servidor y una base de datos, mientras que
los componentes Enterprise JavaBeans slo se utilizan en la capa de negocio como parte de una capa de
servidor. Los JavaBeans tienen variables de ejemplar y mtodos accesores y mutadores para acceder a las
propiedades del bean o digamos, acceso a los datos en las variables de ejemplar lo que simplifica el diseo y
la implementacin de los componentes JavaBeans.

Versin 0.9 - 12/7/2006 Pgina 24 de 30


Java 2 Enterprise Edition (J2EE) es una arquitectura multicapa para implementar aplicaciones de
tipo empresarial y aplicaciones basadas en la Web. Esta tecnologa soporta una gran variedad
de tipos de aplicaciones, desde aplicaciones Web de gran escala a pequeas aplicaciones
cliente-servidor. El objetivo principal de la tecnologa J2EE es crear un simple modelo de
desarrollo para aplicaciones empresariales utilizando componentes basados en el modelo de
aplicacin. En este modelo dichos componentes utilizan servicios proporcionados por el
contenedor, que de otro modo tendran que estar incorporados en el cdigo de la aplicacin.

Def.: Un componente J2EE es una unidad de software funcional auto-contenido que se
ensambla dentro de una aplicacin J2EE con sus clases de ayuda y ficheros y que se comunica
con otros componentes de la aplicacin.

La especificacin J2EE define los siguientes componentes J2EE:

Las Aplicaciones Clientes y los Applets son componentes que se ejecutan en el lado del
cliente.
Los componentes Java Servlet la tecnologa JavaServer Pages son componentes Web
que se ejecutan en el lado del servidor.
Los Enterprise JavaBeans (EJB) son componentes de negocio que se ejecutan en el
servidor de aplicacin.
o Entity Beans: Modelan conceptos de negocio como objetos persistentes
asociados a los datos.
o Session Beans: Representan procesos ejecutados en respuesta a la solicitud
de un cliente.
o Message-Driven Beans: Representan procesos ejecutados en respuesta a la
recepcin de un mensaje.

Adems de estos componentes principales, J2EE incluye servicios estndar y tecnologas de
soporte como:

Java Database Connectivity (JDBC) tecnologa que proporciona acceso a sistemas de
bases de datos relacionales.
Java Transaction API (JTA) o Java Transaction Service (JTS) proporciona soporte para
transacciones a los componentes J2EE.
Java Messaging Service (JMS) para comunicacin asncrona entre componentes J2EE.
Java Naming y Directory Interface (JNDI) proporcionan accesos a nombres y directorios.

10.1.4 CORBA
CORBA es modelo de componente que extiende los anteriores COM/EJB (CORBA Component
Model CCM 3.0 -Estndar OMG/2002). Es una arquitectura orientada al desarrollo e
interoperabilidad de objetos distribuidos heterogneos centrada en un ORB.

No aplica en la actual plataforma IT del Banco; y pese a ser una plataforma de integracin
estndar aceptada por el Banco, aplicar slo como ltimo recurso tecnolgico de integracin.

10.2 Caractersticas de los Componentes
Introspeccin
Evento y comunicaciones asncronas
Enlazado dinmico y composicin tarda
Binario (caja negra)
Interfaces y contratos

Versin 0.9 - 12/7/2006 Pgina 25 de 30

Servicios ofrecidos y requeridos
Desarrollo independiente de contexto
Reutilizacin por composicin

10.3 Definiciones bsicas auxiliares
Conjunto no exhaustivo de conceptos bsicos que intervienen en el cuerpo conceptual tratado:

Composicin tarda Dcese de aquella composicin que se realiza en un tiempo posterior al de
la compilacin del componente, como puede ser durante su enlazado, carga o ejecucin, y por
alguien ajeno a su desarrollo, es decir, que slo conoce al componente por su interfaz o contrato,
pero no tiene porqu conocer ni sus detalles de implementacin, ni la forma en la que fue
concebido para ser usado.

Entornos Un entorno es el conjunto de recursos y componentes que rodean a un objeto o
componente dado, y que definen las acciones que sobre l se solicitan, as como su
comportamiento.
Se pueden definir al menos dos clases de entornos para los componentes: el entorno de
ejecucin y el de diseo. En primero de ellos es el ambiente para el que se ha construido el
componente, y en donde se ejecuta normalmente. El entorno de diseo es un ambiente
restringido, que se utiliza para localizar, configurar, especializar y probar los componentes que
van a formar parte de una aplicacin, y en donde los componentes han de poder mostrar un
comportamiento distinto a su comportamiento normal durante su ejecucin.

Eventos Mecanismo de comunicacin por el que se pueden propagar las situaciones que
ocurren en un sistema de forma asncrona. La comunicacin entre emisores y receptores de los
eventos se puede realizar tanto de forma directa como indirecta, siguiendo el mecanismo
publish-and-subscribe que describiremos ms adelante. Los eventos suelen ser emitidos por
los componentes para avisar a los componentes de su entorno de cambios en su estado o de
circunstancias especiales, como pueden ser las excepciones.

Reutilizacin Habilidad de un componente software de ser utilizado en contextos distintos a
aquellos para los que fue diseado (reutilizar no significa usar ms de una vez).
Existen 4 modalidades de reutilizacin, dependiendo de la cantidad de informacin y
posibilidades de cambio que permita el componente a ser reutilizado:
caja blanca,
caja de cristal,
caja gris
caja negra.

Contratos Especificacin que se aade a la interfaz de un componente y que establece las
condiciones de uso e implementacin que ligan a los clientes y proveedores del componente.
Los contratos cubren aspectos tanto funcionales (semntica de las operaciones de la interfaz)
como no funcionales (calidad de servicio, prestaciones, fiabilidad o seguridad).

Polimorfismo Habilidad de un mismo componente de mostrarse de diferentes formas,
dependiendo del contexto; o bien la capacidad de distintos componentes de mostrar un mismo
comportamiento en un contexto dado. Ambas acepciones representan los dos lados de una
misma moneda. En POO el polimorfismo se relaciona con la sobre-escritura de mtodos y la
sobrecarga de operadores (polimorfismo ad-hoc). Sin embargo, en POC muestra tres nuevas

Versin 0.9 - 12/7/2006 Pgina 26 de 30

posibilidades:

La reemplazabilidad, o capacidad de un componente de reemplazar a otro en una
aplicacin, sin romper los contratos con sus clientes (tambin conocido por polimorfismo
de subtipos o de inclusin).
El polimorfismo paramtrico, o implementacin genrica de un componente. Similar en
concepto a los generics de Ada o a los templates de C++, el polimorfismo paramtrico
no se resuelve como ellos en tiempo de compilacin (generando la tpica explosin de
cdigo) sino en tiempo de ejecucin.
Por ultimo, el polimorfismo acotado combina los polimorfismos de inclusin y
paramtrico para poder realizar restricciones sobre los tipos sobre los que se puede
parametrizar un componente [Szyperski, 1998].

Seguridad Por seguridad en este contexto se entiende la garanta que debe ofrecer un
componente de respetar sus interfaces y contratos, y forma el concepto bsico sobre el que se
puede garantizar la seguridad (en su acepcin ms amplia) de un sistema.
Se puede hacer una distincin entre seguridad a nivel de tipos y a nivel de mdulos.
A nivel de tipos, refiere a que la invocacin de los servicios de un componente se
realice usando parmetros de entrada de los tipos adecuados (o supertipos suyos:
contravarianza) y que los servicios devuelvan tambin valores del tipo adecuado (o
subtipos suyos: covarianza).
A nivel de mdulos, [Szyperski y Gough, 1995] refiere a que slo se utilicen los servicios
ajenos al componente que hayan sido declarados por l, y no otros.

Reflexin La reflexin es la habilidad de una entidad software de conocer o modificar su
estado. A la primera forma se le denomina reflexin estructural, y a la segunda reflexin de
comportamiento.

10.3.1 En el entorno Java
J2EE tiene la misin de proveer una plataforma portable, segura y estandarizada para
aplicaciones distribuidas realizadas en Java. Es importante notar que J2EE es slo una
especificacin. Esto permite que diversos productos sean diseados alrededor de estas
especificaciones, entre ellos Tomcat y JBoss.

Entre los conceptos ms importantes se encuentran las definiciones siguientes:

RMI: Remote Method Invocation. Es la forma nativa que tiene Java de comunicacin
entre objetos distribuidos. Fue extendida a RMI-IIOP para lograr la comunicacin con
objetos CORBA.

JNDI: Java Naming Directory Interface. Es usada para acceder a los sistemas de
nombres y directorios, por ejemplo, un componente EJB.

JDBC: Java Database Connectivity. Es una API que permite el acceso a bases de datos
relacionales.

JMS: Java Messaging Services. Permite la comunicacin entre componentes mediante
un servicio de mensajera.

Versin 0.9 - 12/7/2006 Pgina 27 de 30

Java Servlets. Son componentes orientados al request / response. Toman los pedidos
de un cliente (web browser) y generan luego la respuesta a ese cliente.

JSP: Java Server Pages Son componentes Web, encargados de la capa de
presentacin. Es la tecnologa para generar pginas web de forma dinmica en el
servidor, desarrollado por Sun Microsystems.

EJBs: Enterprise Java Beans. Define como deben ser escritos los componentes en el
lado del servidor. Establece un contrato entre estos componentes y los servidores de
aplicaciones que los manejan. Existen tres tipos de componentes en la especificacin
2.0 de los EJBs : Session Beans, Entity Beans y Message-driven Beans.

i. Los Session Beans modelan el proceso del negocio. Esto es, acciones, tales como
sumar dos nmeros, invocar un sistema legado, autorizar una tarjeta de crdito, etc. Un
Session Bean puede realizar operaciones sobre una base de datos, pero no es un objeto
persistente.
Un componente de este tipo tiene conversaciones con el cliente. Implican la interaccin
entre el Bean y el cliente, estn compuestas por un nmero de llamadas a mtodos, y
corresponden a un proceso de negocio.

Los Session Beans se clasifican segn el tipo de conversacin con un cliente, como:
Stateful Session Beans. Es diseado para servir procesos de negocio que abarcan
mltiples llamadas a mtodos y que necesitan mantener un estado de la conversacin.
Stateless Session Beans. Mantiene interacciones con el cliente que abarcan una nica
llamada a mtodo. Esto quiere decir que luego de una invocacin a un mtodo de un
Session Bean de este tipo, el contenedor puede decidir destruirlo.

ii. Los Entity Beans modelan los datos de la empresa. Son objetos Java que sirven
como cache de la informacin. Puede describirse a una instancia de un Entity Bean
como una representacin en memoria de datos capturados desde una fuente de
almacenamiento, que puede ser nuevamente persistida actualizando estos datos. Esta
representacin en memoria debe ser interpretada como una vista de la base de datos.
Esto es, si algn campo del Entity Bean es actualizado los cambios deben verse
reflejados automticamente en la base de datos.
Existen dos tipos de Entity Beans segn la forma en la que los datos son persistidos en
alguna fuente de almacenamiento perdurable:
Bean-Managed Persstanse (BMP). La lgica de acceso a los datos debe ser codificada
por el programador.
Container-Managed Persistence (CMP). El EJB Container maneja en forma
transparente la lgica involucrada en la persistencia de los datos, almacenndolos y
recuperndolos mediante el mapeado a la fuente de datos.

iii. Los Message-driven Bean, un componente sin estado, que acta como un simple
listener de mensajes. Es parecido a un Session Bean, en cuanto a que tambin
representa acciones del negocio. La diferencia radica en que es invocado slo por el
EJB container cuando un mensaje es recibido desde un Topic o una Queue JMS.

10.3.2 En el entorno .NET
Pendiente de elaboracin.

Versin 0.9 - 12/7/2006 Pgina 28 de 30

10.4 Mecanismos de integracin multiplataforma
10.4.1 Apoderados RMI - .NET Remoting (Proxies)
Son soluciones propietarias que traducen, en ambos sentidos, las serializaciones de J2EE y
.NET.

Dadas lado a lado dos aplicaciones (dos procesos), una corriendo sobre la JVM y la otra sobre el
CLR, ambos procesos interoperan mediante llamadas a procedimientos remotos (RPCs).

RMI y .NET Remoting operan de manera similar: el objeto que quiere invocar un mtodo de un
objeto remoto, lo hace a travs de un apoderado (proxy) que expone la misma firma que el
mtodo remoto, en tanto que internamente serializa la invocacin (incluyendo los argumentos
recibidos) y los enva hacia el otro proceso mediante transporte TCP/IP. Este proceso que
culmina en la serializacin de la invocacin se conoce como marshalling (formacin).

Del otro lado (donde necesariamente el proceso receptor tiene un puerto habilitado para recibir
estos mensajes de invocaciones serializadas), se procede a la deserializacin del flujo (stream)
recibido, para reconstituir la invocacin requerida, ya en el proceso remoto. A este proceso,
anlogamente, se lo llama unmarshalling (desmontado).

10.4.2 Colas de Mensajes (Message Queues)
Mecanismo de alto rendimiento que permite conectar aplicaciones en forma asncrona.

Las colas de mensaje trabajan en una modalidad orientada a eventos. Se dice que un proceso
"publica un evento". Toda vez que pone un mensaje en una cola. Otros procesos previamente
suscriptos a ese tipo de eventos reciben notificacin de la cola cada vez que un evento es
publicado.

Esta notificacin puede provocar acciones en el proceso suscriptor que cambien el estado de los
recursos propios y/o compartidos. Quien public el mensaje en la cola no se entera de los
resultados de esas reacciones excepto que consulte explcitamente. De ah que sea asncrono el
proceso global: quien publica el mensaje no queda bloqueado a la espera de los resultados.

Los motores de gestin de colas (P/Ej: IBM WebSphere MQ o MSMQ), contienen mecanismos
que contemplan la participacin en transacciones. Esto garantizan que un mensaje quede en la
cola hasta tanto no haya sido consumido en forma exitosa (mensajera confiable); el mensaje no
se va a perder sin ser consumido.

10.4.3 Intermediarios de Integracin (Brokers)

Los Integration Broker se encargan de conectar consumidores de servicios con los proveedores
de los mismos. Dado que ambas partes podran tener implementados distintos protocolos de
comunicacin, el Intermediario se encarga de ser el intrprete entre ambas partes, l "entiende"
mltiples dialectos.

Las soluciones basada en broker han generado productos conocidos como ESB (Bus de
Servicios Empresariales), fuertemente inspirados en patrones de integracin conocidos como
Hub o Spoke.

Los productos ESB surgidos proveen adems:

otros servicios como ruteo y direccionamiento, transformaciones de protocolos de
comunicacin, etc.
Numerosas capacidades adicionales, especialmente para definir procesos de negocio
en base a varios servicios. Cada uno de estos servicios desconoce de la presencia o

Versin 0.9 - 12/7/2006 Pgina 29 de 30

existencia de los otros. De este modo el Intermediario juega un rol de " orquestadores de
procesos de negocio", rol central en los ESB. La lgica de orquestacin y las capas de
las aplicaciones (servicios) estn separadas, facilitando desarrollos ms simples,
mantenibles.
Un motor de reglas de negocio y mecanismos sofisticados de monitoreo, tanto a nivel de
infraestructura (procesos, servidores) como a nivel de negocio (transacciones de
negocio en el bus).
Gestin transacciones largas, compensaciones, correlacin de mensajes y flujos de
control.
Facilidades en el contexto SOA que permiten acelerar el montado de toda o parte de
la infraestructura.

Algunos productos:

MS BizTalk Server
IBM WebSphere Message Broker
BEA Aqualogic

10.4.4 Servicios Web (WS)
Estndar apoyado por la industria (Microsoft, IBM, BEA, Oracle, Sun y otros), por empresas de
distintos rubros, no tecnolgicas (Ford, United Airlines, KPMG, Daimler-Chrysler), agrupadas en
un comit conocido como Web Services Interoperability, o WS-I.
Este organismo tiene por principal objetivo asegurar que los grupos de trabajo que definen las
especificaciones sobre WS utilizan estndares adecuados., a la vez que monitorea el avance de
sus trabajos; no define ni desarrolla estndares.

WS es un estndar construido sobre a su vez en estndares como

WSDL (para describir contratos entre el consumidor y el proveedor de un servicio),
UDDI (para descubrir servicios)
SOAP (para invocar servicios)
XML / HTTP (para la capa de transporte)

Y madurando bajo un esquema conocido como WS-*, que persigue

proveer seguridad a las conversaciones dentro de esta tecnologa (en estado avanzado
tanto en definicin como implementacin) Se sostiene con tres estndares:

o WS-Security otorga elementos para firmar mensajes o encriptar (parte o todo).
o WS-SecureConversation contempla la posibilidad de acordar claves especficas
entre las partes para conversaciones ms largas.
o WS-Trust para delegar relaciones de confianza a servicios distribuidos
(mediante la creacin, intercambio y validacin de tokens de seguridad)

mensajera confiable (un estado menor de avance)
coordinacin transaccional (un estado menor an de avance)

Versin 0.9 - 12/7/2006 Pgina 30 de 30


11 Referencias
1. BEA - Domain Model For SOA BEA White Paper
2. ORACLE - Best Practices For Adopting SOA Oracle Architect Forum, Feb 2005
3. IBM - SOA Realization: Service Design Principles. David J.N. Artus
4. IBM Toward a Pattern Languague for Service-Oriented Architecture and
Integration, Part 1: Build a Service Eco-System. Ali Arsanjani.
5. MS Arquitecture Resource Center Understanding SOA. David Sprott and
Lawrence Wilkes CBDI Forum
6. MS - Arquitectura para distribucin y agregacin: Services Oriented Architecture
(SOA) Billy Reinoso
7. Enterprise Architect 11 Tips for Smarter Service Design. David Linthicum (Junio 8
de 2005)
8. Object Watch - A Better Path To Enterprise Architectures. Roger Sessions
9. Grupo Castor - SOA Una Visin Prctica. Martn Cabrera
10. IBM - Service-Oriented Architecture Compass: Business Value, Planning, and
Enterprise Roadmap. Norbert Bieberstein, Sanjay Bose, Marc Fiammante,
Keith Jones, Rawn Shah
11. SUN - SOA and Web Services: Concepts, Technologies, and Tools. Ed Ort.
12. BEA, IBM, Interface21, IONA, Oracle, SAP, Siebel, Sybase Service Component
Architecture Building Systems using a Service Oriented Architecture

Anexo7 - arq-Rfc-01-Pautas y Recomendaciones para Soa v0.91

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Anexo7 - arq-Rfc-01-Pautas y Recomendaciones para Soa v0.91

Transféré par

Droits d'auteur :

Formats disponibles

Service Oriented Architecture

Vous aimerez peut-être aussi