Service Oriented Architecture - (SOA) Pautas y Recomendaciones Versión 0.91 - primera iteración
←
→
Transcripción del contenido de la página
Si su navegador no muestra la página correctamente, lea el contenido de la página a continuación
Service Oriented Architecture (SOA) Pautas y Recomendaciones Versión 0.91 – primera iteración
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
Versión 0.9 - 12/7/2006 Página 2 de 30ARQ-RFC-01-Pautas y Recomendaciones para SOA
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
Versión 0.9 - 12/7/2006 Página 3 de 30ARQ-RFC-01-Pautas y Recomendaciones para SOA
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
Versión 0.9 - 12/7/2006 Página 4 de 30ARQ-RFC-01-Pautas y Recomendaciones para SOA
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.
Versión 0.9 - 12/7/2006 Página 5 de 30ARQ-RFC-01-Pautas y Recomendaciones para SOA
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
Versión 0.9 - 12/7/2006 Página 6 de 30ARQ-RFC-01-Pautas y Recomendaciones para SOA
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.
Versión 0.9 - 12/7/2006 Página 7 de 30ARQ-RFC-01-Pautas y Recomendaciones para SOA
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.
Versión 0.9 - 12/7/2006 Página 8 de 30ARQ-RFC-01-Pautas y Recomendaciones para SOA
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.
Versión 0.9 - 12/7/2006 Página 9 de 30ARQ-RFC-01-Pautas y Recomendaciones para SOA
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
Versión 0.9 - 12/7/2006 Página 10 de 30ARQ-RFC-01-Pautas y Recomendaciones para SOA
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.
Versión 0.9 - 12/7/2006 Página 11 de 30ARQ-RFC-01-Pautas y Recomendaciones para SOA
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
Versión 0.9 - 12/7/2006 Página 12 de 30ARQ-RFC-01-Pautas y Recomendaciones para SOA
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.
Versión 0.9 - 12/7/2006 Página 13 de 30ARQ-RFC-01-Pautas y Recomendaciones para SOA
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.
Versión 0.9 - 12/7/2006 Página 14 de 30ARQ-RFC-01-Pautas y Recomendaciones para SOA
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
Versión 0.9 - 12/7/2006 Página 15 de 30ARQ-RFC-01-Pautas y Recomendaciones para SOA
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: ....
Versión 0.9 - 12/7/2006 Página 16 de 30ARQ-RFC-01-Pautas y Recomendaciones para SOA
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.
Versión 0.9 - 12/7/2006 Página 17 de 30ARQ-RFC-01-Pautas y Recomendaciones para SOA
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.
Versión 0.9 - 12/7/2006 Página 18 de 30ARQ-RFC-01-Pautas y Recomendaciones para SOA
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 Los procesos de negocio necesitan TOP-DOWN
Negocio explotar los recursos disponibles, y
cada actividad requiere invocar una
funcionalidad de IT. Para ello, cada
funcionalidad debe estar disponible en
una manera flexible.
MDA (Model-Driven Se modela el negocio y luego las TOP-DOWN
Architecture, basada en herramientas generan el detalle
herramientas)
Empaquetado de Sistemas Se ha realizado una inversión BOTTOM-UP
Legados 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”.
Composición de Sistemas Descomponer los sistemas legados BOTTOM-UP
Legados monolíticos en módulos (manual o
automático)
Orientado a Datos Proveer acceso a los datos usando DATA-FOCUSED
servicios, sin exponer esquemas o
consideraciones de implementación
Message-Driven Se necesita integrar sistemas, SERVICE-ORIENTED
comunicándolos mediante protocolos INTEGRATION of
estándar no propietarios. 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:
Versión 0.9 - 12/7/2006 Página 19 de 30ARQ-RFC-01-Pautas y Recomendaciones para SOA
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.
Versión 0.9 - 12/7/2006 Página 20 de 30ARQ-RFC-01-Pautas y Recomendaciones para SOA
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
Versión 0.9 - 12/7/2006 Página 21 de 30ARQ-RFC-01-Pautas y Recomendaciones para SOA
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.
Versión 0.9 - 12/7/2006 Página 22 de 30ARQ-RFC-01-Pautas y Recomendaciones para SOA
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.
Versión 0.9 - 12/7/2006 Página 23 de 30ARQ-RFC-01-Pautas y Recomendaciones para SOA
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
Versión 0.9 - 12/7/2006 Página 24 de 30ARQ-RFC-01-Pautas y Recomendaciones para SOA
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
Versión 0.9 - 12/7/2006 Página 25 de 30ARQ-RFC-01-Pautas y Recomendaciones para SOA
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.
Versión 0.9 - 12/7/2006 Página 26 de 30ARQ-RFC-01-Pautas y Recomendaciones para SOA
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.
Versión 0.9 - 12/7/2006 Página 27 de 30También puede leer
