Componentes de una plataforma SOA - II Parte

Los componentes adicionales que deben ser considerados para SOA son:

Adaptadores de ESB, los adaptadores de un ESB son necesarios para ofrecer capacidades de intercambio de información entre las aplicaciones legadas, aplicaciones empaquetadas, almacenes de datos empresariales y el ESB para incorporar servicios que son entregados a través de aplicaciones existentes en un ambiente SOA.
Registro de Servicios,un registro actúa como un catalogo centralizado de servicios de negocios. Un registro típicamente cumple con las funcionalidades siguientes:
Descripción del almacenamiento de servicios, que contiene información acerca de los “endpoints” (los recursos de red donde la funcionalidad del servicio es implementada) y los detalles técnicos que un consumidor requiere para invocar el servicio, como el protocolo de enlace y los formatos de los mensajes.
Catalogo de Servicios, que categoriza y organiza los servicios para un acceso y ubicación fácil de parte de los consumidores.
Publicación de nuevos servicios, permite publica los servicios nuevos implementados sobre el registro, explorar y buscar por servicios existentes.
Historia de Servicios, mantiene un registro histórico del servicio, permitiendo a los usuarios ver cuando un servicio fue publicado o cambiado.

Gobierno de Servicios

Gobierno es el arte y la disciplina de gestionar los resultados a través de relaciones estructuradas, procedimientos y políticas. El gobierno consiste de un conjunto de políticas que el proveedor de servicio y los consumidores deben cumplir, un conjunto de prácticas para implementar estas políticas y un conjunto de procesos que permiten que las políticas se implementen de manera correcta. El gobierno debe incluir:

• Políticas de regulación para la definición y mejoras de servicios, incluyendo la propiedad, roles, criterios, guías de revisión y demás.
  Identificación de roles, responsabilidades y propietarios.
• Políticas de cumplimiento que están integradas directamente sobre el repositorio de servicios.
• Guías, plantillas, listas de verificación y ejemplos que hacen fácil conformar los requerimientos de gobierno.
• Revisión de las interfaces de servicios para nuevos servicios y las mejoras sobre servicios existentes. Las revisiones permiten que los servicios se definan conforme a los estándares y se alineen con las necesidades del negocio y de los modelos de información.
• Revisión de las arquitecturas de las soluciones de negocio y servicios para permitir que estén conforme a SOA y a la arquitectura empresarial.

Como Diseñar Servicios

La aplicación de principios de orientación-a-servicios para el procesamiento de lógica resulta en lógica de procesamiento estandarizada orientada-a-servicios. Cuando una solución está compuesta de unidades de lógica de procesamiento orientado-a-servicios, esta se refiere a una solución orientada-a-servicios. Los principios de de diseño orientado-a-servicios son:

Bajo Acoplamiento, donde los servicios mantienen una relación que minimiza las dependencias y solamente requieren que retengan un conocimiento básico de los servicios con los cuales interactúa.
Contrato de Servicio, que especifica como los servicios de adhieren a las reglas de comunicación, son definidos en forma colectiva por una o más descripciones de servicios y documentos relacionados.
Servicios autónomos, que tienen el control sobre la lógica que estos encapsulan.
Abstracción, más allá de lo que se describe en el contrato de servicio, lo servicios ocultan la lógica al mundo real.
Reutilización, de manera que la lógica se divida de manera organizada con la intención de promover la reutilización.
Composición de colección de servicios, para que pueden ser coordinados y ensamblados para formar servicios o aplicaciones compuestas.
Servicios que no contengan el estado de la comunicación ni de los datos en los diferentes intercambios de información, de esta manera se minimiza la retención de información específicos a una actividad.
Descubrimiento de servicios, que son diseñados para ser descriptivos hacia el exterior, para que puedan ser fácilmente ubicados y evaluados a través de los mecanismos disponibles de descubrimiento.

Con el conocimiento de componente que comprender la arquitectura básica y el conjunto de principios de diseño se puede utilizar para configurar y normalizar estos componentes. Lo que hace falta es una plataforma de aplicación que nos permitirá extraer estas piezas juntas para construir la prestación de servicios orientados a soluciones de automatización.

Blueprint de Servicios

Un objetivo principal hacia la transición a SOA es el de poder producir una colección de servicios estandarizados que comprendan un inventario de servicios. El inventario debe ser estructurados sobre capas de acuerdo a los modelos de servicios utilizados, pero a través de la aplicación del paradigma de orientación-a-servicios todos los servicios que se identifiquen deben tener un valor para el negocio y estar alienados con los objetivos de negocio asociados al proyecto SOA.

Para poder tener un blueprint (un plan especificado en un diagrama) de inventario de servicios debe identificar todos los servicios de negocio que ofrecen de alguna u otra manera funcionalidades o capacidades a las actividades de los procesos de negocios que forman parte del alcance funcional que se requiere resolver con la solución basada en SOA. Esta perspectiva debe ser documentada en un blueprint de inventario de servicios. Los modelos de datos y negocios que pueden permitir la identificación de estos servicios de negocios candidatos son: los modelos de entidades de negocio, entidades de información, modelos de datos conceptuales, modelos de datos lógicos, modelos de mensajes y datos propietarios, ontologías o modelos de arquitectura de información.

Arquitectura de Referencia - AR

La AR representa una definición formal de arquitectura, una que puede ser utilizada para validar los objetivos de los servicios y aplicaciones. La AR para SOA debe contemplar:

1. Soporte de conceptos empresariales, particularmente de sub-arquitecturas de negocios, información, aplicación y tecnología.
2. Especificar una jerarquía y taxonomía de servicios y tipos de servicios.
3. Definir como los servicios encajan dentro de una aplicación empresarial, como un portal, un sistema de gestión de cliente o un ERP.
4. Proveer una separación entre conceptos de negocios, aplicación y tecnología.
5. Integrarse en los procesos de desarrollo.

Eficiencia de Desarrollo en SOA

Un desarrollo de soluciones eficiente significa construir más funcionalidad en menos tiempo a menor costo. Los servicios son desarrollados conforme a unos principios de arquitectura y de acuerdos a requerimientos de negocios y modelos de información empresariales. Algunos requerimientos de arquitectura son necesarios para una efectiva productividad en el desarrollo:

1. Tener arquitecturas de referencia que guíen los desarrollos de servicios.
2. Utilizar BPM para definir procesos de negocios, basados en la composición de servicios y el conjunto de capas de servicios. Utilizar BPM para manejar el descubrimiento y diseño de los servicios requeridos.
3. Tener un proceso eficiente que gestione la integridad total del conjunto de servicios de proveedores y consumidores de acuerdos con la visión y los modelos de información del negocio.
4. Contar con el conjunto de herramientas que permitan implementar servicios de acuerdo a los principios de arquitectura orientada-a-servicios.

Componentes de una plataforma SOA - I Parte

ESB - Capacidades BASICAS

El componente principal de las implementaciones Orientadas-a-Servicios está construido como un middleware en la forma de un Enterprise Service BUS (ESB). La funcionalidad de un ESB es la de entregar todo las capacidades de interconexión requeridas para aprovechar los servicios implementados a través de la arquitectura completa, incluyendo los servicios de transporte, servicios de eventos y servicios de mediación. La mejor forma de definir las funcionalidades de un ESB es especificando sus capacidades. Las capacidades de un ESB son las siguientes:

Enrutamiento, es la habilidad para canalizar una petición a un determinado proveedor de servicios sobre un criterio o variable de enrutamiento. Los tipos de enrutamiento pueden ser estáticos o deterministas, enrutamiento basados en contenido, enrutamiento basados en políticas o enrutamiento basados en reglas complejas gestionados sobre componentes de reglas de negocio.
Transformación de Mensajes, es la habilidad para convertir la estructura y el formato de un requerimiento del servicio de negocio a la estructura y formato esperado por el proveedor del servicio.
Enriquecimiento de Mensajes, es la facilidad para adicionar o modificar la información contendía en el mensaje requerido por el proveedor del servicio.
Transformación de Protocolos, es la habilidad para aceptar un tipo de protocolo de un consumidor como entrada (ejemplo: SOAP, TCPIP, JMS, RMI) y comunicar al proveedor del servicios a través de un protocolo diferentes (ejemplo IIOP, HTTP).
Mapeo de Servicios, es la facilidad para traducir un servicio de negocio a una correspondiente implementación de servicio, brindando un enlace y proporcionando la localización de información.
Procesamiento de Mensajes, es la habilidad para gestionar el estado y llevar a cabo la gestión del requerimiento aceptando un requerimiento de entrada y garantizando la entrega al cliente vía la sincronización de mensajes.
Coreografía de Procesos, es la facilidad de gestionar procesos de negocios complejos que requieren la coordinación de múltiples servicios de negocios para cumplir un solo requerimiento de servicio de negocio.
Orquestación de Servicios, es la habilidad para gestionar la coordinación de múltiples implementaciones de servicios.
Gestión de Transacción, es la facilidad para brindar una única unidad de trabajo para un requerimiento de servicio de negocio brindado un marco de trabajo para la coordinación de múltiples recursos a través de múltiples servicios.
Seguridad, es la facilidad de proteger los servicios empresariales desplegados a través del ESB del uso no autorizado.