Fijación de los enfoques de la identificación de SOA/SOMA Service a los entornos del proyecto

La motivación hacia Service Oriented Architecture (SOA) es la reutilización. Una entidad desarrollada para cumplir con una funcionalidad empresarial específica debería poseer la capacidad de ser utilizada nuevamente para así poder atender las necesidades empresariales tan cambiantes. El paradigma de SOA desarrollado por IBM denominado Soma (Service Oriented Modeling and Architecture) brinda las técnicas en varias dimensiones para adoptar SOA. En los proyectos que apalancan SOA/SOMA, los servicios son identificados, diseñados e implementados. Existen varios enfoques para el proceso de identificación del servicio y cada uno es el más adecuado para el entorno de un proyecto determinado. Este artículo tiene como objetivo analizar los enfoques existentes, los entornos del proyecto y recomendar la mejor opción para cada entorno.

Gandhi Sivakumar , Senior IT Architect, IBM Australia

Gandhi Sivakumar Gandhi Sivakumar es una Arquitecta de IT Senior Certificada de IBM / una diseñadora de soluciones SOA certificada por IBM y trabaja en el equipo de práctica de Arquitectura de IBM Australia. Ella ha sido una pieza clave hacia el éxito del complejo Primer proyecto de su clase en la empresa. Ella ha publicado numerosos documentos y ha registrado muchas patentes en el dominio de SOA. Además es miembro de la IBM Academy of Technology.



11-05-2010

Identificación de los servicios de SOA/SOMA

En los proyectos basados en SOA, los servicios son identificados utilizando los siguientes enfoques:

  • Enfoque top down
  • Enfoque bottom up
  • Enfoque Meet in the middle

(Nota: Existe una extensión de todos los enfoques mencionados anteriormente que se denomina "Goal Service Model" que se detalla más adelante).

SOMA Method de IBM tiene la capacidad para manejar los enfoques anteriores. Proporciona las mejores prácticas y una orientación normativa para dar soporte a esas actividades.


Enfoque top down

Existen varios métodos para desarrollar la descomposición top-down en el que el requisito empresarial se descompone en los elementos del nivel más bajo de la granularidad. A continuación se detallan los tipos de métodos:

  • Método basado en la información
  • Método basado en Process Modeling
  • Método basado en los requisitos

Eventualmente, en base a las previsiones empresariales esperadas, los elementos resultantes se refactorizan/o se seleccionan como un sevicio. Por ejemplo se toma en consideración un requisito empresarial para gestionar un pedido desde el sistema front end Customer Relation Management. Si se utiliza un efoque top down basado en la información, el Pedido puede ser dividido en los siguientes elementos:

  • CustomerDetails
  • AddressDetails
  • CustomerContactDetails
  • ProductOrderDetails
  • ProductOrderItemDetails

Dependiendo de las necesidades empresariales futuras, los elementos como ProductOrder y ProductOrderItem pueden ser refactorizados como "ManageProductOrder" que es un servicio y otros tres podrán existir como servicios por separado. Dichos servicios identificados pueden ser consumidos por servicios externos o internos y estarán conectados a múltiples aplicaciones de back end para satisfacer las necesidades empresariales.


Enfoque bottom up

El enfoque bottom up tiene como objetivo exponer las aplicaciones existentes como servicios. Los servicios atendidos por las aplicaciones legacy pueden ser refactorizados para crear servicios compuestos basados en las necesidades empresariales. (Nota: La exposición de las aplicaciones legacy como servicios se puede realizar utilizando los adaptadores disponibles listos para usar.). Este tipo de servicio completo finalmente puede utilizar las aplicaciones legacy múltiples para satisfacer las necesidades previstas por la empresa. El método SOMA define este enfoque como un "Existing Asset Analysis" en donde el término Asset se refiere no sólo a los sistemas legacy, sino también a las estructuras y a los estándares industriales, así como también a las aplicaciones en paquete que pueden ser usadas en este contexto.


Enfoque Meet in the Middle

El enfoque Meet in the middle se centra en contabilizar la descomposición del proceso empresarial en elementos granulares y a correlacionarlos con las aplicaciones existentes. Siempre que se observe una brecha, es decir un elemento que no encaje en la funcionalidad de las aplicaciones existentes, se vuelve elegible como candidato potencial para un nuevo servicio que requiera la mejora de la aplicación legacy existente para ejecutar las necesidades de la empresa. La tabla 1 reitera el ejemplo discutido en el enfoque Top down para este caso:

Tabla 1. Enfoque top-down
S1 NoElementosCorrelación de las aplicaciones legacyObservaciones
1CustomerDetailsMapped- Legacy1CICS Transaction
2AddressDetailsNo correlacionadaBrecha identificada
3CustomerContactDetailsCorrelacionada - Legacy1Interfaz de programación de las aplicaciones
4ProductOrderDetailsCorrelacionada - Legacy2Acceso a la interfaz de las aplicaciones en paquete
5ProductOrderItemDetailsCorrelacionada - Legacy2Acceso a la interfaz de las aplicaciones en paquete

En el ejemplo mencionado anteriormente AddressDetails no está correlacionado con ninguna de las aplicaiones legacy existentes. Con el fin de satisfacer las necesidades empresariales, es decir ManageCustomerOrder, esta función tiene que ser aumentada en las aplicaciones legacy. En los casos en que el cliente no esté dispuesto a invertir en el gasto de las aplicaciones (una de las razones podría ser que las aplicaciones pueden necesitar ser gastadas en la transformación), esta funcionalidad se puede crear en el middleware. En este caso el servicio podría flexibilizarse para recibir los detalles de las direcciones completas del consumidor o simplemente las del AddressIdentifier. Digamos que el consumidor 1 no tiene la capacidad de enviar la estructura de las direcciones (como hemos comentado anteriormente la razón podría ser que se espere que este consumidor sea eliminado en las sucesivas versiones o que el cliente no posea el privilegio de realizar cambios en la aplicación del consumidor) entonces éste sólo puede pasar el AddressIdentifier. El componente del servico ejecutará la funcionalidad de convertir el identificador de Address a la estructura de Address.


Goal Service Modeling

SOMA presenta una extensión para el enfoque Meet in the middle denominado "Goal Service modeling (GSM)" donde los Servicios identificados que utilicen cualquiera de los enfoques mencionados anteriormente en un entorno táctico se aseguren de estar alineados con la visión estratégica de la empresa. (Nota: Lógicamente GSM puede ser aplicado para otros enfoques también). Además, GSM propone etiquetar cada servicio con KPIs (Key Performance Indicators) para medir la performance de cada servicio. Los KPIs son inicialmente utilizados para realizar el seguimiento de la magnitud del éxito para conseguir el objetivo empresarial señalado. Tenga en cuenta que los servicios ofrecen una mecanísmo para alcanzar los objetivos.

En la próxima sección hablaremos de los entornos del proyecto y correlacionaremos los enfoques con cada entorno.


Entornos del proyecto

En realidad, existen tres entornos de proyectos diferentes:

  1. Entornos basados en el campo verde
  2. Entorno más débil de campo marrón (normalmente denominados entornos de campo marrón)
  3. Entorno más fuerte de campo marrón (normalmente denominados campo marrón)

La figura 1 muestra los variados enfoques para la identificación del servicio SOA y su mejor ajuste a los entornos del proyecto.

Figura 1. Enfoques para la identificación del servicio SOA
Enfoques para la identificación del servicio de SOA

Entornos basados en el campo verde

En este entorno el producto o la solución se han desarrollado desde cero. La mayoría de las veces este entorno es aplicable al desarrollo del producto en relación con las soluciones centradas en la Integración. En dicho entorno, el diseñador no tiene una pista sobre los consumidores o las aplicaciones destino que deben utilizarse.

El diseñador podría tener que depender de los modelos de los procesos industriales como el e-TOM(enhanced Telecommunications Operations Map) para los productos específicos industriales de Telecomunicaicones de IFW-APM (IBM Financial Services Industry Model- Analysis Process Model) o para los productos específicos industriales bancarios. El mejor enfoque para identificar los servicios en dichos escenarios es el "enfoque Top-Down". Una vez identificados los servicios, el diseñador puede aplicar los conceptos de GSM, mediante el análisis de los objetivos empresariales a largo plazo y aumentar los nuevos servicios cuando fuese necesario, etiquetar con los KPIs claves para llevar los servicios a las etapas siguientes del ciclo de vida.

Campo marrón basado en el entorno

Para simplificar, dividimos el campo marrón basado en los entornos en dos categorías:

El campo marrón más débil basado en los entornos: En esta categoría el objetivo es sólo exponer la aplicación legacy existente como un servicio. En estos casos el diseñador no necesita poner atención en el proceso de la empresa/del consumidor que eventualmente utilizará el servicio. Cuando se exponga una aplicación legacy como servicio, el diseñador puede unir las interfaces utilizando un adaptador. Cumplir con los requisitos de dichos servicios es responsabilidad de las aplicaciones consumidoras o del intermediario. En esta fase la técnica de GSM puede ser aplicada. El o los servicios identificados pueden ser analizados para las necesidades futuras y etiquetados con los KPIs.

Por lo tanto el "enfoque bottom up" sería el mejor para llevar a cabo el proceso de identificación del servicio basado en los entornos de los campos marrones más débiles.

Entornos basados en los campos marrones más fuertes: Los escenarios de las soluciones requieren la integración de las aplicaciones/mejoras existentes a las aplicaciones ya existentes dentro de esta categoría. En el entorno de la integración es necesario identificar los procesos correlacionando dichos procesos con la funcionalidad de las aplicaciones/los servicios ya existentes, identificando las brechas y decidiendo el posisionamiento de la funcionalidad mejorada en los niveles apropiados. En tales escenarios se sugiere utilizar el enfoque Meet in the middle. Esto se debe a que la identificación de los servicios requiere entrelazar los procesos empresariales, así como también analizar y contabilizar las aplicaciones legacy existentes. Al igual que los otros enfoques, éste puede ser aumentado con GSM.


Conclusión

Existen varios enfoques generales para el servicio de la identificación y se deberían adoptar enfoques relevantes para los entornos de los proyectos adecuados. En este artículo se proporciona el análisis de dichos procesos de identificación de los servicios y los adapta al entorno del proyecto adecuado.


Agradecimientos

El autor agradece a Ahamed Jalaldeen, Arquitecto líder en automatización de SOMA y a Ali Arsanjani, Ingeniero Distinguido & CTO, tecnologías Emerging, y a SOMA por su orientación y soporte en este artículo.

Recursos

Aprender

Obtener los productos y tecnologías

Comentar

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=SOA y servicios web
ArticleID=489087
ArticleTitle=Fijación de los enfoques de la identificación de SOA/SOMA Service a los entornos del proyecto
publish-date=05112010