service oriented architeture (soa) - … · gartner: “soa es una arquitectura de software que...

Service Oriented Architecture

(SOA)

Pautas y Recomendaciones Versión 0.91 – primera iteración

Versión 0.9 - 12/7/2006 Página 2 de 30

ARQ-RFC-01-Pautas y Recomendaciones para SOA

1 Información del Documento

1.1 Identificación y versión

ARQ-RFC-01-Pautas y recomendaciones para SOA (Service Oriented Architectures) Versión 0.91 (pre-release, primera iteración)

1.2 Resumen

Se presenta un conjunto de PAUTAS (de aplicación obligatoria) y RECOMENDACIONES (de utilización sugerida) relativas a la aplicación 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 – Creación 07 al 11/07/2006 – Ajustes finales pre-RFC 12/7/2006 – Liberación RFC

1.5 Autores

Edición Revisión Coordinación

Mónica Borso

Virginia Casciato

Heber Rodríguez

Mauricio Papaleo

Carlos Suárez

Jorge Suárez



2 Tabla de Contenidos

1 INFORMACIÓN DEL DOCUMENTO 2

1.1 IDENTIFICACIÓN Y VERSIÓN 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 PRESENTACIÓN 5

4 DEFINICIONES Y CONCEPTOS GENERALES 6

4.1 ALGUNAS DEFINICIONES DE ARQUITECTURA 6 4.2 DEFINICIÓN DE COMPONENTE 6 4.3 ALGUNAS DEFINICIONES DE SOA 6 4.4 DOS TAXONOMÍAS DE LA SOA 7 4.5 SERVICIOS 8

4.5.1 Arquitectura de Servicios 9 4.5.2 Estructura y características de los Servicios 10 4.5.3 Los Principios Comunes de la Orientación 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 categorización de los Componentes de Servicio 12

6 MECANISMOS DE INTEGRACIÓN MULTIPLATAFORMA 13

6.1 PAUTA DE UTILIZACIÓN DE PROXIES RMI - .NET REMOTING: 13 6.2 PAUTA DE APLICACIÓN COLAS DE MENSAJES 13 6.3 PAUTA DE APLICACIÓN INTERMEDIARIOS DE INTEGRACIÓN (BROKERS) 14 6.4 PAUTA DE APLICACIÓN SOBRE ESTÁNDARES WS-* 14

7 CONSIDERACIONES DE DISEÑO 15

7.1 DISEÑO DE SERVICIOS 15 7.2 BUENAS PRÁCTICAS 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 Diseñarlos para que sean cohesivos y completos. 16

7.3 RECOMENDACIONES 16 7.3.1 Manejar múltiples patterns de invocación 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 “Agregación”/Composición/Orquestación/Coreografía. 17 7.4.3 No concebirlos como aplicaciones enteras. 17

7.5 PRINCIPIOS PARA EL DISEÑO DE LAS OPERACIONES DE LOS SERVICIOS 18 7.5.1 Diseñar para que representen acciones del negocio 18 7.5.2 Definir con parámetros de gran granularidad 18 7.5.3 Diseñar para la concurrencia 18

7.6 PASOS PARA LA DEFINICIÓN DE UN SERVICIO 18



8 ENFOQUES Y TÉCNICAS PARA LA IDENTIFICACIÓN DE SERVICIOS 19

8.1 SEIS ENFOQUES PARA CREAR UNA SOA 19 8.2 RECOMENDACIONES SOBRE ENFOQUES PARA CREAR UNA SOA 19 8.3 TÉCNICAS DE IDENTIFICACIÓN DE SERVICIOS 20

8.3.1 Análisis de documentos 20 8.3.2 Descomposición de dominio 20 8.3.3 Síntesis de sistemas existentes 21 8.3.4 Meet-in-the-middle 21

8.4 RECOMENDACIONES TÉCNICAS DE IDENTIFICACIÓN DE SERVICIOS 21

9 PRÓXIMA ITERACIÓN 22

10 ANEXO: DEFINICIONES Y GLOSARIO 23

10.1 COMPONENTES 23 10.1.1 Definición clásica de COMPONENTE: 23 10.1.2 COM 23 10.1.3 Enterprise Beans 23 10.1.4 CORBA 24

10.2 CARACTERÍSTICAS DE LOS COMPONENTES 24 10.3 DEFINICIONES BÁSICAS AUXILIARES 25

10.3.1 En el entorno Java 26 10.3.2 En el entorno .NET 27

10.4 MECANISMOS DE INTEGRACIÓN 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 Integración (Brokers) 28 10.4.4 Servicios Web (WS) 29

11 REFERENCIAS 30



3 Presentación

El presente documento establece pautas y recomendaciones para la creación y evolución de sistemas según un estilo de arquitectura orientado a servicios en el BPS. Está estructurado en un cuerpo principal con algunas definiciones básicas (incluidas con el objetivo de uniformizar terminología) y las pautas y recomendaciones correspondientes, y un anexo con definiciones más amplias. Se incluyen únicamente los aspectos seleccionados para la primera iteración. A ésta seguirá al menos una segunda iteración con los contenidos tentativamente descriptos en el capítulo final.



4 Definiciones y conceptos generales

4.1 Algunas Definiciones de ARQUITECTURA

ANSI/IEEE Std 1471-2000: “La organización fundamental de un sistema, embebida en sus componentes, las relaciones entre ellos y su entorno y los principios que gobiernan su diseño y evolución” TOGAF: “En TOGAF, “arquitectura” tiene dos significados dependiendo del contexto en que se use: La descripción formal de un sistema, o un plan detallado de un sistema a nivel de sus

componentes que guía su implementación. La estructura de sus componentes, sus inter-relaciones, y los principios y guías que

gobiernan su diseño y evolución a lo largo del tiempo.” En forma tentativa, este Comité utilizará las definiciones propuestas en el TOGAF.

4.2 Definición de COMPONENTE

SZYPERSKY: “Un componente es una unidad de composición 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 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…”. IBM: “SOA representa una forma de construir sistemas distribuidos que permite ofrecer las funcionalidades de una aplicación como servicios tanto para aplicaciones de usuario final ó a otros servicios”. Martín Cabrera: “SOA es un estilo de arquitectura que promueve descomponer la lógica funcional de una aplicación en unidades autónomas 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 fácil y rápidamente 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 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 llamada “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”. 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 (típicamente

de negocios) en una manera flexible y extendida.”

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

4.4 Dos taxonomías de la SOA

Se incluyen en este párrafo dos diagramas representando los distintos componentes de una Arquitectura Orientada a Servicios.

El diagrama anterior muestra una vista tecnológica de los distintos aspectos de SOA, es decir con una fuerte orientación a su implementación.



Funciones:

1 Transporte: Mecanismo utilizado para trasladar las peticiones desde el cliente, hasta el proveedor del servicio, y viceversa.

2 Protocolo de comunicación: Es el sistema de comunicación entre el cliente y el proveedor de servicios.

3 Descripción del servicio: Es un esquema utilizado para describir qué servicio es, cómo se le puede invocar, y cuáles son los datos necesarios para realizar su invocación.

4 Servicio: Es la implementación del servicio. 5 Proceso de negocio: Es una colección 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 Políticas: 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 podrían ser aplicadas en la identificación, autorización y control de acceso a los servicios, por parte del cliente.

3 Transacción: Conjunto de atributos que podrían ser aplicados sobre un grupo de servicios para devolver un conjunto de datos consistentes.

4 Gestión: Conjunto de atributos que podrían 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 aplicación correctamente basada en componentes, no necesariamente es una aplicación correctamente orientada a servicios.



La clave para comprender esta diferencia radica en ver como una arquitectura orientada a servicios (SOA) implica una capa adicional de arquitectura (una nueva abstracción) implementada con una granularidad más “gruesa” y ubicada más cerca del consumidor de la aplicación.

Figura: Capas de Aplicación: Servicios, Componentes y Objetos.

Un servicio es una forma de exponer una visión externa de un sistema, con reuso interno y una composición tradicional basada en el diseño de componentes. En una SOA, un servicio mapea una función identificada durante un proceso de análisis del negocio; dependiendo de la función del negocio de que se trate, la granularidad del mismo puede ser mas o menos fina o gruesa. Los servicios no se diseñan en base a las entidades de negocio; cada servicio es una unidad que maneja operaciones a través 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 colección de componentes que trabajan en colaboración para entregar la funcionalidad del negocio que el mismo representa; los componentes son de una granularidad más fina que la de los servicios. Mientras un servicio mapea una funcionalidad del negocio, un componente típicamente mapea las entidades del negocio y las reglas que las operan.

4.5.1 Arquitectura de Servicios

El siguiente diagrama muestra la interrelación entre las arquitecturas de Aplicación, Servicios y Componentes, y la implementación de procesos de negocio mediante orquestación de servicios.



4.5.2 Estructura y características 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 interactúa 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 propósito, la funcionalidad, las restricciones y el modo de uso del servicio. Es definido POR EL NEGOCIO, en TÉRMINOS del NEGOCIO.

2 Implementación: La funcionalidad en sí misma que provee el servicio: puede ser realizada utilizando cualquier tecnología.

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 múltiples interfaces para permitir su consumo de diferentes maneras.

1. Características Funcionales:

1 Invocación: sincrónica o asincrónica 2 Intercambio: uni-direccional, bi-direccional 3 Complejidad: referido a la granularidad



2. Características No-Funcionales:

1. Requerimientos de Volúmenes 2. Calidad del Servicio 3. Tiempo de ejecución del Servicio

4.5.3 Los Principios Comunes de la Orientación a Servicios:

1. Comparten un contrato formal 2. Bajamente acoplados 3. Abstraen la lógica que existen debajo (autocontenidos y modulares) 4. Interoperables 5. Componibles 6. Reusables 7. Autónomos 8. Sin estado 9. Descubribles (transparentes a la ubicación)

4.6 Otras Definiciones del entorno SOA

Servicios: Entidades lógicas - Contratos definidos por una o más interfaces públicas. Service Provider: Entidad de software que implementa una especificación de servicio. Consumidor: Entidad de software que llama a un service provider. Tradicionalmente se lo llama “cliente”. Puede ser una aplicación final u otro servicio. Service Locator: Tipo específico de service provider que actúa como registry y permite buscar interfaces de service providers y sus ubicaciones. Service Broker: Tipo específico de service provider que puede pasar requerimientos de servicios a otros service providers.



5 Definiciones SOA en BPS

En este capítulo se incluirán las definiciones correspondientes a la visión BPS de la Arquitectura Orientada a Servicios. Las mismas están en elaboración, identificándose al momento de liberación de este RFC dos fuentes principales:

1. las pautas de ASIT 2. la especificación de la Service Component Architecture, trabajo realizado en forma

conjunta por varias empresas [12] El Comité está trabajando en la generación de una pauta conceptualmente “abierta”, implementable en cualquier tecnología, construida sobre elementos claramente definidos y una nomenclatura no ambigua. En futuras versiones de este documento se irán presentando avances y refinamientos sucesivos.

5.1 Algunas definiciones

Las definiciones que siguen fueron incluidas en la presentación 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 lógica y la encapsulan Granularidad a establecer Implementados internamente en una única tecnología (homogéneos)

5.1.3 Servicios

Constituyen la única interfaz de acceso a la lógica implementada en los componentes de servicio

Son invocables como servicio externo, no como un módulo en una biblioteca

5.1.4 Primera categorización de los Componentes de Servicio

Según la función que cumplen (principalmente), pueden identificarse en primera instancia las siguientes categorías.

1. Administración de datos 2. Lógica de negocios básica 3. Lógica de negocios compuesta 4. Interacción con el usuario 5. Componentes utilitarios comunes



6 Mecanismos de integración multiplataforma

En este capítulo se describen algunos mecanismos de integración multiplataforma que permiten la invocación de métodos o servicios distribuidos y que pueden servir para la implementación de una “capa de servicios” que oculte la tecnología de implementación subyacente.

Los siguientes mecanismos aportan a la construcción: 1. Apoderados (Proxies) RMI - .NET Remoting 2. Colas de Mensajes (Message Queues) 3. Intermediarios de Integración (Brokers) 4. Servicios Web (WS)

En el Anexo se describen las principales características de cada mecanismo

6.1 Pauta de utilización de Proxies RMI - .NET Remoting:

Se establece como PAUTA que esta estrategia de integración no deberá aplicarse en la construcción de servicios de consumo externo (orientado al Usuario externo vía Web) y deberá evitarse en la integración de aplicaciones dentro de la Institución (Pattern Enterprise Application Integration o EAI) en atención a que:

tanto la JVM como el CLR tienen formatos propios de serialización de invocaciones. es necesario piezas de terceros para filtrar este tipo de invocaciones salientes,

mapeándolas 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 coordinación 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 serialización es binaria (empaquetada), con menor consumo de recursos.

6.2 Pauta de aplicación Colas de Mensajes

En aplicaciones complejas, este mecanismo basado en eventos (Event-Driver Architecture -EDA) rápidamente puede quedar fuera de control al generar múltiples dependencias.



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 definición 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 operación de negocio provista por otro servicio o por un componente.

6.3 Pauta de aplicación Intermediarios de Integración (Brokers)

Se PAUTA Intermediarios de Integración (Brokers) como pieza clave en la integración de aplicaciones y la construcción de una arquitectura de servicios, soporte de funciones en procesos de negocio.

El BPS ha definido Biztalk Server como Integration Broker estándar.

6.4 Pauta de aplicación sobre estándares WS-*

Se establece como PAUTA la utilización de Servicios Web como pieza clave en la integración de aplicaciones y la construcción de una arquitectura de servicios, soporte de funciones en procesos de negocio. El BPS ha definido como estándares los registrados por los documentos llamados “Basic Profile” y “Security Basic Profile”de 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 evolución de las tres organizaciones involucradas en la definición, desarrollo y publicación de estándares WS-*:

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

a la hora de diseñar SOA mediante Servicios Web.



7 Consideraciones de Diseño

7.1 Diseño 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 diseño de los mismos, desde varios puntos de vista. Este criterio deberá tenerse muy presente a la hora de diseñar un Servicio. Recordando que un servicio es una agrupación lógica de operaciones cuyas interfaces son publicadas en algún formato pre-establecido, veremos algunas recomendaciones que aplican al servicio como un todo.

7.2 Buenas prácticas

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 utilización de aspectos del negocio frente a los aspectos técnicos. Los servicios deben de ser nombrados utilizando nombres ó sustantivos, y las operaciones utilizando verbos.

Ejemplo 1: Nombrando Servicios utilizando frases verbales y lenguaje técnico

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 términos 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



operación 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 Diseñarlos 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 función. No deben agruparse en base a detalles de implementación o al patrón de secuencia lógica de uso (algunas veces puede parecer que algunas operaciones deberían 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 acción 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 también puedan ser necesarias para otros consumidores aún 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 explícitamente por los consumidores identificados- se va a necesitar también la operación ActivarCelular, por lo que el servicio debería ofrecerla desde un principio.

7.3 Recomendaciones

7.3.1 Manejar múltiples patterns de invocación

Un consumidor debería usar código similar para invocar servicios usando una variedad de patterns de invocaciones diferentes, como por ejemplo: Tradicional (SOAP/HTPP) Asíncrona (SOAP/Message Queues)

Como RECOMENDACION se preferirán las invocaciones remotas y asíncronas por sobre las invocaciones locales y sincrónicas. Esto incide directamente en el diseño. No es lo mismo pensar en invocaciones locales y sincrónicas que en invocaciones remotas (hay que tener en cuenta la red) y asíncronas (se deben pensar mecanismos compensatorios, por ejemplo).

Ejemplo 4: Ejemplo de un mal diseño para las invocaciones remotas

Servicio: ServicioCelulares Operaciones: . . . .



ObtenerPropietarioCelular, ObtenerFacturaciónCelular, 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 deberán realizar 3 invocaciones por la red para obtener los datos de un solo celular. En este caso pensándolo desde el punto de vista del consumidor (remoto) se debería manejar la granularidad de las operaciones de forma tal que en una sola operación 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 acompañar la documentación de los servicios y las intefaces con un buen diagrama de estados indicando en que transición 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 diseñados 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 diseñados para soportar una relación de largo tiempo entre el consumidor y el proveedor, ni tampoco una operación deberá depender del estado de una invocación previa. En este caso siempre existe un compromiso entre la escalabilidad y las necesidades de negocio. Técnicamente se pueden proveer interfaces con estado, para ello existen técnicas tales como las cookies ó EJB‟s Stateful (en el mundo J2EE); pero estas técnicas 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 deberán ser utilizados solamente con autorización expresa (como excepciones) y deberá estar correctamente fundamentado su uso.

7.4.2 Modelar para las “Agregación”/Composición/Orquestación/Coreografía.

Esto debe ser tenido en cuenta desde el diseño, ya que sino pueden aparecer problemas para componerlos si no fueron considerados en su momento. Es muy común no pensar en estas cosas en el momento del diseño, pero deben de ser tomadas en cuenta, maxime que no sabemos con precisión quien puede llegar a invocar los servicios que están siendo creados, ni de que forma participarán en un proceso de negocio y que operaciones se harán antes y después 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 más servicios, evitando la sobrecarga de un servicio con mucha funcionalidad.



7.5 Principios para el Diseño de las Operaciones de los Servicios

7.5.1 Diseñar para que representen acciones del negocio

Para ello se usarán nombres de verbos y serán bien específicas del negocio en vez de ser operaciones genéricas y/o puramente técnicas. Deben corresponderse con escenarios específicos del negocio. Las interfaces individuales deben ser simples y sencillas de entender, incrementado la consumibilidad.

7.5.2 Definir con parámetros de gran granularidad

Se recomienda que sean de gran granularidad por tres motivos: Permiten crear operaciones más flexibles, permitiendo nuevas versiones sin afectar a

los consumidores. Una operación con gran cantidad de parámetros es vulnerable a errores de

“transposición” de parámetros en las invocaciones. Aumentan la eficacia de la red.

Estas pautas deberán ser sopesadas en el ámbito de creación de las operaciones del servicio, pero se deberá ganar en generalidad de la operación y sus parámetros frente a implementaciones para consumidores específicos; para ello se debe tener muy en cuenta el negocio y los posibles consumidores.

7.5.3 Diseñar para la concurrencia

Se deberá tener en cuenta que la invocación de las operaciones puede ser realizada múltiples 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 múltiple invocación de la operación. Se debe tender a favorecer el asincronismo y la ejecución remota por sobre la sincronía y la ejecución local. De todas formas en la documentación del servicio deberá quedar expresamente establecido de que forma se comporta la operación y cuales son las pautas de su invocación, incluyendo ejemplos.

7.6 Pasos para la Definición de un Servicio

Pretende ser una guía tentativa sobre los pasos a seguir para definir un servicio.

1. Definir el propósito del servicio (orientado al negocio) 2. Determinar la información 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 (métodos) encapsuladas dentro del servicio, es decir el

comportamiento interno. 6. Definir las interfaces, los parámetros y el mapeo con las funciones o métodos internos. 7. Definir como deberá ser testeado el servicio (test information, service invocation,

validez de los resultados, etc) 8. Definir la documentación a incorporar.



8 Enfoques y Técnicas para la Identificación de Servicios

Se describen en este capítulo algunos enfoques con los que pueden encararse proyectos de definición de Arquitecturas Orientadas a Servicios. Luego, algunas técnicas de identificación de servicios.

8.1 Seis Enfoques para crear una SOA

Enfoque Caracterización del Proyecto Clasificación 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 inversión importante en los sistemas existentes, pero éstos no son flexibles: no se les puede agregar funcionalidades en forma rápida, son sistemas estancos, con funciones “cautivas”.

BOTTOM-UP

Composición de Sistemas Legados

Descomponer los sistemas legados monolíticos en módulos (manual o automático)

BOTTOM-UP

Orientado a Datos Proveer acceso a los datos usando servicios, sin exponer esquemas o consideraciones de implementación

DATA-FOCUSED

Message-Driven Se necesita integrar sistemas, comunicándolos mediante protocolos estándar 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 construcción y descripción de una SOA, pero sería poco realista ignorar la extensión y criticidad de la plataforma tecnológica que hoy da soporte a dichos procesos. Según el escenario a atender, se recomienda aplicar los siguientes enfoques:

1. Partiendo de los sistemas actuales:

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

2. Partiendo del análisis de procesos de negocio:



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

8.3 Técnicas de identificación de servicios

La identificación de servicios puede ser hecha mediante las siguientes técnicas:

1. Análisis de Documentos 2. Descomposición de Dominio (top-down) 3. Síntesis de Sistemas Existentes (bottom-up) 4. Convergencia (meet-in-the middle)

8.3.1 Análisis de documentos

Esta técnica involucra la revisión de los modelos de negocio y la documentación de los sistemas existentes para el proceso de negocio en cuestión. 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 términos de los indicadores clave del desempeño 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 críticos pendientes de resolución en la documentación de

requerimientos no funcionales?

Si los modelos de negocio y los documentos de sistemas existentes no son suficientes, deben planificarse actividades de análisis adicionales, ya que no tiene sentido avanzar con el modelado sin una base documental sólida.

8.3.2 Descomposición de dominio

Esta técnica parte de los procesos de negocio a alto nivel, y progresivamente mejora el nivel de detalle hasta llegar a la identificación de los servicios necesarios para la implementación de los procesos en cuestión. Los pasos a seguir son:

1. Identificación de los procesos de negocio a implementar 2. Modelado de los mismos para capturar requerimientos 3. Aplicación de técnicas de análisis orientado a objetos para identificar y definir los

servicios requeridos

Debe mantenerse una perspectiva de alto nivel en este proceso, ya que el análisis orientado a objetos de un proceso completo puede resultar en un modelo de objetos demasiado grande e inmanejable. Pueden aplicarse técnicas tradicionales de modelado de procesos y de análisis de requerimientos y también utilizarse documentos existentes (por ej.: de casos de uso) relacionados al proceso en cuestión. Durante el proceso debe construirse un glosario de uso común entre analistas de negocio y de IT y deben identificarse relaciones entre sus términos.



8.3.3 Síntesis de sistemas existentes

En el escenario más usual, la identificación de servicios se inicia motivada por necesidades de integración de sistemas. Esta integración puede ser realizada mediante la descomposición de los sistemas existentes (y relevantes) en:

Flujos de procesos de negocio Reglas de negocio Componentes potencialmente reutilizables

Mediante esta descomposición es posible sintetizar un conjunto de servicios candidatos a partir de los componentes identificados, y sintetizar otros a partir de la adaptación de los flujos de proceso descubiertos.

8.3.4 Meet-in-the-middle

Esta técnica combina las descriptas en párrafos anteriores. En paralelo se procesan los análisis top-down (orientado a procesos de negocio) y bottom-up (descomponiendo sistemas existentes), buscando la convergencia o “encuentro en el medio” de ambos análisis, mediante el mapeo de requerimientos de negocio y funcionalidades de los sistemas.

8.4 Recomendaciones Técnicas de identificación de servicios

Considerando el alto grado de informatización de procesos existente en BPS, y la necesidad de aprovechar la inversión ya realizada mediante la mayor reutilización posible de los sistemas existentes, parece poco viable aplicar técnicas como las descriptas en primer y segundo término (análisis de documentos y descomposición de dominio), a menos que se trate de procesos aún no informatizados. En consecuencia, y en función de los plazos disponibles y del avance existente en la documentación de los procesos de negocio involucrados, se recomienda aplicar las siguientes técnicas de identificación de servicios:

1. Partiendo de los sistemas actuales: Síntesis de Sistemas Existentes Convergencia (meet-in-the middle)

2. Partiendo del análisis de procesos de negocio: Análisis de documentos Descomposición de dominio



9 Próxima iteración

Se espera incluir en la próxima iteración los siguientes aspectos de SOA:

Patterns Protocolos Catálogo de servicios Manejo de consistencia Seguridad Administración Productos

Adicionalmente se incluirán las modificaciones que surjan de los comentarios recibidos al presente RFC.



10 ANEXO: Definiciones y Glosario

10.1 Componentes

La noción de componente extiende la Programación Orientada a Objetos (OOP) en el contexto de sistemas abiertos y eventualmente distribuidos.

Def.: Se entiende por “abierto” aquel sistema concurrente, reactivo, independientemente extensible, heterogéneo, evolutivo y permisivo al ingreso o abandono en forma dinámica de componentes software heterogéneos.

Def.: Se entiende por plataforma de componentes al entorno de desarrollo y de ejecución que permita aislar la mayor parte de las dificultades conceptuales y técnicas que conlleva la construcción de aplicaciones basadas en los componentes del modelo [Krieger y Adler, 1998]. Es una implementación 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 Definición clásica de COMPONENTE:

Def.: “Un componente es una unidad de composición 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 especificación del modelo de objeto común (COM), definida por Microsoft, según el cual se separa el conjunto de interfaces públicas del componente (básicamente, una tabla de punteros a métodos) de su implementación.

10.1.3 Enterprise Beans

Nota:

La especificación 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 comunicación entre una aplicación 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 sólo se utilizan en la capa de negocio como parte de una capa de servidor. Los JavaBeans tienen variables de ejemplar y métodos 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 diseño y la implementación de los componentes JavaBeans.



Java 2 Enterprise Edition (J2EE) es una arquitectura multicapa para implementar aplicaciones de tipo empresarial y aplicaciones basadas en la Web. Esta tecnología soporta una gran variedad de tipos de aplicaciones, desde aplicaciones Web de gran escala a pequeñas aplicaciones cliente-servidor. El objetivo principal de la tecnología J2EE es crear un simple modelo de desarrollo para aplicaciones empresariales utilizando componentes basados en el modelo de aplicación. En este modelo dichos componentes utilizan servicios proporcionados por el contenedor, que de otro modo tendrían que estar incorporados en el código de la aplicación.

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

La especificación 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 tecnología 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 aplicación. 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

recepción de un mensaje. Además de estos componentes principales, J2EE incluye servicios estándar y tecnologías de soporte como: Java Database Connectivity (JDBC) tecnología 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 comunicación asíncrona 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 -Estándar OMG/2002). Es una arquitectura orientada al desarrollo e interoperabilidad de objetos distribuidos heterogéneos centrada en un ORB.

No aplica en la actual plataforma IT del Banco; y pese a ser una plataforma de integración estándar aceptada por el Banco, aplicará sólo como último recurso tecnológico de integración.

10.2 Características de los Componentes

Introspección Evento y comunicaciones asíncronas Enlazado dinámico y composición tardía Binario (“caja negra”) Interfaces y contratos



Servicios ofrecidos y requeridos Desarrollo independiente de contexto Reutilización por composición

10.3 Definiciones básicas auxiliares

Conjunto no exhaustivo de conceptos básicos que intervienen en el cuerpo conceptual tratado:

Composición tardía Dícese de aquella composición que se realiza en un tiempo posterior al de la compilación del componente, como puede ser durante su enlazado, carga o ejecución, y por alguien ajeno a su desarrollo, es decir, que sólo conoce al componente por su interfaz o contrato, pero no tiene porqué conocer ni sus detalles de implementación, 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 ejecución y el de diseño. En primero de ellos es el ambiente para el que se ha construido el componente, y en donde se ejecuta normalmente. El entorno de diseño es un ambiente restringido, que se utiliza para localizar, configurar, especializar y probar los componentes que van a formar parte de una aplicación, y en donde los componentes han de poder mostrar un comportamiento distinto a su comportamiento normal durante su ejecución.

Eventos Mecanismo de comunicación por el que se pueden propagar las situaciones que ocurren en un sistema de forma asíncrona. La comunicación entre emisores y receptores de los eventos se puede realizar tanto de forma directa como indirecta, siguiendo el mecanismo publish-and-subscribe que describiremos más 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.

Reutilización Habilidad de un componente software de ser utilizado en contextos distintos a aquellos para los que fue diseñado (reutilizar no significa usar más de una vez).

Existen 4 modalidades de reutilización, dependiendo de la cantidad de información y posibilidades de cambio que permita el componente a ser reutilizado: caja blanca, caja de cristal, caja gris caja negra.

Contratos Especificación que se añade a la interfaz de un componente y que establece las condiciones de uso e implementación que ligan a los clientes y proveedores del componente. Los contratos cubren aspectos tanto funcionales (semántica 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 métodos y la sobrecarga de operadores (polimorfismo ad-hoc). Sin embargo, en POC muestra tres nuevas



posibilidades:

La reemplazabilidad, o capacidad de un componente de reemplazar a otro en una aplicación, sin romper los contratos con sus clientes (también conocido por polimorfismo de subtipos o de inclusión).

El polimorfismo paramétrico, o implementación genérica de un componente. Similar en concepto a los generics de Ada o a los templates de C++, el polimorfismo paramétrico no se resuelve como ellos en tiempo de compilación (generando la típica explosión de código) sino en tiempo de ejecución.

Por ultimo, el polimorfismo acotado combina los polimorfismos de inclusión y paramétrico 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 garantía que debe ofrecer un componente de respetar sus interfaces y contratos, y forma el concepto básico sobre el que se puede garantizar la seguridad (en su acepción más amplia) de un sistema.

Se puede hacer una distinción entre seguridad a nivel de tipos y a nivel de módulos.

A nivel de tipos, refiere a que la invocación de los servicios de un componente se realice usando parámetros de entrada de los tipos adecuados (o supertipos suyos: contravarianza) y que los servicios devuelvan también valores del tipo adecuado (o subtipos suyos: covarianza).

A nivel de módulos, [Szyperski y Gough, 1995] refiere a que sólo se utilicen los servicios ajenos al componente que hayan sido declarados por él, y no otros.

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

10.3.1 En el entorno Java

J2EE tiene la misión de proveer una plataforma portable, segura y estandarizada para aplicaciones distribuidas realizadas en Java. Es importante notar que J2EE es sólo una especificación. Esto permite que diversos productos sean diseñados alrededor de estas especificaciones, entre ellos Tomcat y JBoss. Entre los conceptos más importantes se encuentran las definiciones siguientes:

RMI: Remote Method Invocation. Es la forma nativa que tiene Java de comunicación entre objetos distribuidos. Fue extendida a RMI-IIOP para lograr la comunicación 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 comunicación entre componentes mediante un servicio de mensajería.



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

presentación. Es la tecnología para generar páginas web de forma dinámica 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 especificación 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 números, invocar un sistema legado, autorizar una tarjeta de crédito, 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 interacción entre el Bean y el cliente, están compuestas por un número de llamadas a métodos, y corresponden a un proceso de negocio.

Los Session Beans se clasifican según el tipo de conversación con un cliente, como:

Stateful Session Beans. Es diseñado para servir procesos de negocio que abarcan múltiples llamadas a métodos y que necesitan mantener un estado de la conversación.

Stateless Session Beans. Mantiene interacciones con el cliente que abarcan una única llamada a método. Esto quiere decir que luego de una invocación a un método 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 información. Puede describirse a una instancia de un Entity Bean como una representación en memoria de datos capturados desde una fuente de almacenamiento, que puede ser nuevamente persistida actualizando estos datos. Esta representación en memoria debe ser interpretada como una vista de la base de datos. Esto es, si algún campo del Entity Bean es actualizado los cambios deben verse reflejados automáticamente en la base de datos.

Existen dos tipos de Entity Beans según la forma en la que los datos son persistidos en alguna fuente de almacenamiento perdurable:

Bean-Managed Persístanse (BMP). La lógica de acceso a los datos debe ser codificada por el programador.

Container-Managed Persistence (CMP). El EJB Container maneja en forma transparente la lógica involucrada en la persistencia de los datos, almacenándolos y recuperándolos mediante el mapeado a la fuente de datos.

iii. Los Message-driven Bean, un componente sin estado, que actúa como un simple „listener‟ de mensajes. Es parecido a un Session Bean, en cuanto a que también representa „acciones‟ del negocio. La diferencia radica en que es invocado sólo 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 elaboración.



10.4 Mecanismos de integración 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 método de un objeto remoto, lo hace a través de un apoderado (proxy) que expone la misma firma que el método remoto, en tanto que internamente serializa la invocación (incluyendo los argumentos recibidos) y los envía hacia el otro proceso mediante transporte TCP/IP. Este proceso que culmina en la serialización de la invocación se conoce como marshalling (formación). Del otro lado (donde necesariamente el proceso receptor tiene un puerto habilitado para recibir estos mensajes de invocaciones serializadas), se procede a la deserialización del flujo (stream) recibido, para reconstituir la invocación requerida, ya en el proceso remoto. A este proceso, análogamente, se lo llama unmarshalling (desmontado).

10.4.2 Colas de Mensajes (Message Queues)

Mecanismo de alto rendimiento que permite conectar aplicaciones en forma asíncrona.

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 notificación de la cola cada vez que un evento es publicado. Esta notificación 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 explícitamente. De ahí que sea asíncrono el proceso global: quien publica el mensaje no queda bloqueado a la espera de los resultados. Los motores de gestión de colas (P/Ej: IBM WebSphere MQ o MSMQ), contienen mecanismos que contemplan la participación en transacciones. Esto garantizan que un mensaje quede en la cola hasta tanto no haya sido consumido en forma exitosa (mensajería confiable); el mensaje no se va a perder sin ser consumido.

10.4.3 Intermediarios de Integración (Brokers)

Los Integration Broker se encargan de conectar consumidores de servicios con los proveedores de los mismos. Dado que ambas partes podrían tener implementados distintos protocolos de comunicación, el Intermediario se encarga de ser el intérprete entre ambas partes, él "entiende" múltiples dialectos. Las soluciones basada en broker han generado productos conocidos como ESB (Bus de Servicios Empresariales), fuertemente inspirados en patrones de integración conocidos como Hub o Spoke.

Los productos ESB surgidos proveen además:

otros servicios como ruteo y direccionamiento, transformaciones de protocolos de

comunicación, 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



existencia de los otros. De este modo el Intermediario juega un rol de " orquestadores de procesos de negocio", rol central en los ESB. La lógica de orquestación y las capas de las aplicaciones (servicios) están separadas, facilitando desarrollos más 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).

Gestión transacciones largas, compensaciones, correlación 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)

Estándar apoyado por la industria (Microsoft, IBM, BEA, Oracle, Sun y otros), por empresas de distintos rubros, no tecnológicas (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 estándares adecuados., a la vez que monitorea el avance de sus trabajos; no define ni desarrolla estándares.

WS es un estándar construido sobre a su vez en estándares 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 tecnología (en estado avanzado

tanto en definición como implementación) Se sostiene con tres estándares:

o WS-Security otorga elementos para firmar mensajes o encriptar (parte o todo). o WS-SecureConversation contempla la posibilidad de acordar claves específicas

entre las partes para conversaciones más largas. o WS-Trust para delegar relaciones de confianza a servicios distribuidos

(mediante la creación, intercambio y validación de tokens de seguridad) mensajería confiable (un estado menor de avance) coordinación transaccional (un estado menor aún de avance)



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 distribución y agregación: 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 Visión Práctica. Martín 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

service oriented architeture (soa) - … · gartner: “soa es una arquitectura de software que...

Documents