Arquitectura de referencia SOA

Uno de los aspectos relevantes en SOA es definir la Arquitectura de Referencia para la Empresa, esta definición permite tener un marco de referencia en donde ubicar los nuevos desarrollos.

La Arquitectura de Referencia SOA plasma los distintos componentes de una solución SOA, principalmente Procesos de Negocio y Servicios, además muestra como interactúan estos componentes con los usuarios de negocio, y con los sistemas existentes en la Empresa (sistemas legados).

Esta Arquitectura debe ser complementada con los componentes específicos de cada Empresa. Además cada proveedor de soluciones (IBM, Oracle, BEA, etc.) tiene su propia Arquitectura SOA de Referencia, que incorpora sus herramientas especificas, pero toda Arquitectura de Referencia por lo menos contempla lo siguiente:

• Usuarios de Negocio: son lo usuarios de las aplicaciones, pero en SOA son también los participantes de los procesos de negocio, estos pueden utilizar distintas tecnologías para acceder a la aplicación (o proceso de negocio): Desktop, Notebooks, PDAs, Celulares.

• Aplicación SOA y Portal: Las aplicaciones (aplicaciones SOA, o aplicaciones compuestas), están implementadas usando componentes reutilizables (Portlets, y Servicios), para lo cual se utiliza la tecnología de Portales. Una aplicación de este tipo incorpora todas las funcionalidades de un proceso bajo un ambiente común. La ventaja principal de las soluciones Portal; es que una aplicación desarrollada para un dispositivo se puede ajustar a otro con muy poco esfuerzo, es decir, una aplicación que funciona en un Desktop se puede adaptar para que se vea en una PDA, ajustando los portlets, y su distribución para cada dispositivo. Un portal de ejemplo puede ser este sitio web: “SOAagenda.com”,

• Servicios de Presentación (Portlets): son los componentes de presentación reutilizables, que en la practica corresponden a secciones reutilizables de las paginas Web. Ejemplos: un portlet de “Calendario”, un portlet para mostrar las “Publicaciones Recientes” de un blog. En el caso de los “Procesos de Negocio” (BPMS) generalmente ellos ofrecen un portlet para ejecutar los procesos, al que llamaremos portlet “Lista de Pendientes”.

• Procesos de Negocio: son la implementación BPM de los procesos, son procesos que incorporan tareas interactivas (interacción participante), con actividades automatizadas (servicios). Ejemplo: el proceso de “publicar un comentario en un Blog”, que dentro de sus tareas interactivas esta el “ingresar el comentario”, y “aprobar el comentario para su publicación”, y una actividad automatizada es el servicio de “ingresar el comentario en el sistema de Blog”.

• Servicios de Negocio: son componentes funcionales del negocio que se pueden reutilizar en los distintos procesos, y distintas aplicaciones, generalmente son servicios compuestos (por otros servicios). Ejemplo “ingresarComentarioBlog”.

• Servicios de Información: son lo servicios atómicos que pueden ser parte de servicios de mas alto nivel. Su principal características es que acceden directamente a los recursos, o sistemas legados, encapsulan las funcionalidades especificas de los sistemas existentes, dándole así una interfaz que permita integrarlos al estándar SOA.

• Sistemas Legados: son los sistemas existentes en la Empresa, que no están integrados (sistemas silo o isla). Son que soportan actualmente la operación del negocio, y que no están bajo el nuevo esquema de “orientación a servicios”.

 

Modelado de SOA: Parte 1. Identificación del servicio

Resumen:  Este artículo es el primero de una serie de cinco sobre el desarrollo de software basado en la arquitectura orientada a servicios (SOA). El mismo muestra cómo usar los modelos UML ampliados con IBM® Software Service Profile para el diseño de una solución SOA que se conecte con los requerimientos de negocios y sea al mismo tiempo independiente de la implementación de la solución. El autor describe las metas y los objetivos de negocios así como los procesos implementados para cumplir con dichos objetivos, y luego explica la manera en que se deben usar los procesos para identificar los servicios de relevancia para el negocio que resulten necesarios para cumplir con los requerimientos que representan.

Ver más contenido de esta serie

Primeros pasos en SOA

La Arquitectura Orientada a Servicios (en inglés Service Oriented Architecture), es un concepto de arquitectura de software que define la utilización de servicios para dar soporte a los requisitos del negocio.
Permite la creación de sistemas altamente escalables que reflejan el negocio de la organización, a su vez brinda una forma bien definida de exposición e invocación de servicios (comúnmente pero no exclusivamente servicios web), lo cual facilita la interacción entre diferentes sistemas propios o de terceros.
SOA define las siguientes capas de software:

• Aplicaciones básicas - Sistemas desarrollados bajo cualquier arquitectura o tecnología, geográficamente dispersos y bajo cualquier figura de propiedad;
• De exposición de funcionalidades - Donde las funcionalidades de la capa aplicativa son expuestas en forma de servicios (servicios web);
• De integración de servicios - Facilitan el intercambio de datos entre elementos de la capa aplicativa orientada a procesos empresariales internos o en colaboración;
• De composición de procesos - Que define el proceso en términos del negocio y sus necesidades, y que varía en función del negocio;
• De entrega - donde los servicios son desplegados a los usuarios finales.

SOA proporciona una metodología y un marco de trabajo para documentar las capacidades de negocio y puede dar soporte a las actividades de integración y consolidación.

Terminología

Término	Definición / Comentario
Servicio	Una función sin estado, auto-contenida, que acepta una(s) llamada(s) y devuelve una(s) respuesta(s) mediante una interfaz bien definida. Los servicios pueden también ejecutar unidades discretas de trabajo como serían editar y procesar una transacción. Los servicios no dependen del estado de otras funciones o procesos. La tecnología concreta utilizada para prestar el servicio no es parte de esta definición. Existen servicios asíncronos en los que una solicitud a un servicio crea, por ejemplo, un archivo, y en una segunda solicitud se obtiene ese archivo
Orquestación	Secuenciar los servicios y proveer la lógica adicional para procesar datos. No incluye la presentación de los datos. Coordinación.
Sin estado	No mantiene ni depende de condición pre-existente alguna. En una SOA los servicios no son dependientes de la condición de ningún otro servicio. Reciben en la llamada toda la información que necesitan para dar una respuesta. Debido a que los servicios son "sin estado", pueden ser secuenciados (orquestados) en numerosas secuencias (algunas veces llamadas tuberías o pipelines) para realizar la lógica del negocio.
Proveedor	La función que brinda un servicio en respuesta a una llamada o petición desde un consumidor.
Consumidor	La función que consume el resultado del servicio provisto por un proveedor.

Diseño y desarrollo de SOA

La metodología de modelado y diseño para aplicaciones SOA se conoce como análisis y diseño orientado a servicios. La arquitectura orientada a servicios es tanto un marco de trabajo para el desarrollo de software como un marco de trabajo de implementación. Para que un proyecto SOA tenga éxito los desarrolladores de software deben orientarse ellos mismos a esta mentalidad de crear servicios comunes que son orquestados por clientes o middleware para implementar los procesos de negocio. El desarrollo de sistemas usando SOA requiere un compromiso con este modelo en términos de planificación, herramientas e infraestructura.
Cuando la mayoría de la gente habla de una arquitectura orientada a servicios están hablando de un juego de servicios residentes en Internet o en una intranet, usando servicios web. Existen diversos estándares relacionados a los servicios web. Incluyen los siguientes:

• XML
• HTTP
• SOAP
• WSDL
• UDDI

Hay que considerar, sin embargo, que un sistema SOA no necesariamente necesita utilizar estos estándares para ser "orientado a servicios" pero es altamente recomendable su uso.
En un ambiente SOA, los nodos de la red hacen disponibles sus recursos a otros participantes en la red como servicios independientes a los que tienen acceso de un modo estandarizado. La mayoría de las definiciones de SOA identifican la utilización de Servicios Web (empleando SOAP y WSDL) en su implementación, no obstante se puede implementar SOA utilizando cualquier tecnología basada en servicios.

Diferencias con otras arquitecturas

Al contrario de las arquitecturas orientado a objetos, las SOAs están formadas por servicios de aplicación débilmente acoplados y altamente interoperables. Para comunicarse entre sí, estos servicios se basan en una definición formal independiente de la plataforma subyacente y del lenguaje de programación (p.ej., WSDL). La definición de la interfaz encapsula (oculta) las particularidades de una implementación, lo que la hace independiente del fabricante, del lenguaje de programación o de la tecnología de desarrollo (como Plataforma Java o Microsoft.NET). Con esta arquitectura, se pretende que los componentes de software desarrollados sean muy reutilizables, ya que la interfaz se define siguiendo un estándar; así, un servicio C# podría ser usado por una aplicación Java. En este sentido, ciertos autores definen SOA como una Súper-Abstracción.

Beneficios

Los beneficios que puede obtener una organización que adopte SOA son:

• Mejora en los tiempos de realización de cambios en procesos.
• Facilidad para evolucionar a modelos de negocios basados en tercerización.
• Facilidad para abordar modelos de negocios basados en colaboración con otros entes (socios, proveedores).
• Poder para reemplazar elementos de la capa aplicativa SOA sin disrupción en el proceso de negocio
• Facilidad para la integración de tecnologías disímiles