Fijacin de los enfoques de la identificacin de SOA/

SOMA Service a los entornos del proyecto

Gandhi Sivakumar (gandhis@au1.ibm.com)
Senior IT Architect
IBM Australia

11-05-2010

La motivacin hacia Service Oriented Architecture (SOA) es la reutilizacin. Una entidad

desarrollada para cumplir con una funcionalidad empresarial especfica debera 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 tcnicas en varias dimensiones para adoptar
SOA. En los proyectos que apalancan SOA/SOMA, los servicios son identificados, diseados
e implementados. Existen varios enfoques para el proceso de identificacin del servicio y cada
uno es el ms adecuado para el entorno de un proyecto determinado. Este artculo tiene como
objetivo analizar los enfoques existentes, los entornos del proyecto y recomendar la mejor
opcin para cada entorno.

Identificacin 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 extensin de todos los enfoques mencionados anteriormente que se denomina
"Goal Service Model" que se detalla ms adelante).
SOMA Method de IBM tiene la capacidad para manejar los enfoques anteriores. Proporciona las
mejores prcticas y una orientacin normativa para dar soporte a esas actividades.

Enfoque top down

Existen varios mtodos para desarrollar la descomposicin top-down en el que el requisito
empresarial se descompone en los elementos del nivel ms bajo de la granularidad. A
continuacin se detallan los tipos de mtodos:
Mtodo basado en la informacin
Copyright IBM Corporation 2010
Fijacin de los enfoques de la identificacin de SOA/SOMA
Service a los entornos del proyecto

Marcas
Pagina 1 de 7

developerWorks

ibm.com/developerWorks/ssa/

Mtodo basado en Process Modeling

Mtodo 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 consideracin 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 informacin, 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 podrn existir como servicios por separado. Dichos servicios identificados pueden ser
consumidos por servicios externos o internos y estarn conectados a mltiples 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 exposicin 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 mltiples para
satisfacer las necesidades previstas por la empresa. El mtodo SOMA define este enfoque como
un "Existing Asset Analysis" en donde el trmino Asset se refiere no slo a los sistemas legacy,
sino tambin a las estructuras y a los estndares industriales, as como tambin 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 descomposicin 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 aplicacin 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 No

Elementos

Correlacin de las
aplicaciones legacy

Fijacin de los enfoques de la identificacin de SOA/SOMA

Service a los entornos del proyecto

Observaciones

Pagina 2 de 7

ibm.com/developerWorks/ssa/

developerWorks

CustomerDetails

Mapped- Legacy1

CICS Transaction

AddressDetails

No correlacionada

Brecha identificada

CustomerContactDetails Correlacionada Legacy1

Interfaz de
programacin de las
aplicaciones

ProductOrderDetails

Correlacionada Legacy2

Acceso a la interfaz
de las aplicaciones en
paquete

ProductOrderItemDetails Correlacionada Legacy2

Acceso 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 funcin 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 podra ser que las aplicaciones pueden necesitar ser gastadas en la transformacin),
esta funcionalidad se puede crear en el middleware. En este caso el servicio podra 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 razn podra 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 aplicacin del consumidor) entonces ste slo 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 extensin 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 tctico se aseguren de estar alineados con la visin
estratgica de la empresa. (Nota: Lgicamente GSM puede ser aplicado para otros enfoques
tambin). Adems, 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 sealado. Tenga en
cuenta que los servicios ofrecen una mecansmo para alcanzar los objetivos.
En la prxima seccin 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 ms dbil de campo marrn (normalmente denominados entornos de campo marrn)
3. Entorno ms fuerte de campo marrn (normalmente denominados campo marrn)
Fijacin de los enfoques de la identificacin de SOA/SOMA
Service a los entornos del proyecto

Pagina 3 de 7

developerWorks

ibm.com/developerWorks/ssa/

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

Figura 1. Enfoques para la identificacin del servicio SOA

Entornos basados en el campo verde

En este entorno el producto o la solucin se han desarrollado desde cero. La mayora de
las veces este entorno es aplicable al desarrollo del producto en relacin con las soluciones
centradas en la Integracin. En dicho entorno, el diseador no tiene una pista sobre los
consumidores o las aplicaciones destino que deben utilizarse.
El diseador podra tener que depender de los modelos de los procesos industriales como
el e-TOM(enhanced Telecommunications Operations Map) para los productos especficos
industriales de Telecomunicaicones de IFW-APM (IBM Financial Services Industry Model- Analysis
Process Model) o para los productos especficos industriales bancarios. El mejor enfoque para
identificar los servicios en dichos escenarios es el "enfoque Top-Down". Una vez identificados los
servicios, el diseador puede aplicar los conceptos de GSM, mediante el anlisis 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 marrn basado en el entorno

Para simplificar, dividimos el campo marrn basado en los entornos en dos categoras:
El campo marrn ms dbil basado en los entornos: En esta categora el objetivo es
slo exponer la aplicacin legacy existente como un servicio. En estos casos el diseador
no necesita poner atencin en el proceso de la empresa/del consumidor que eventualmente
utilizar el servicio. Cuando se exponga una aplicacin legacy como servicio, el diseador 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 tcnica
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" sera el mejor para llevar a cabo el proceso de identificacin
del servicio basado en los entornos de los campos marrones ms dbiles.
Entornos basados en los campos marrones ms fuertes: Los escenarios de las soluciones
requieren la integracin de las aplicaciones/mejoras existentes a las aplicaciones ya existentes
Fijacin de los enfoques de la identificacin de SOA/SOMA
Service a los entornos del proyecto

Pagina 4 de 7

ibm.com/developerWorks/ssa/

developerWorks

dentro de esta categora. En el entorno de la integracin 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 identificacin de los servicios requiere entrelazar los procesos
empresariales, as como tambin analizar y contabilizar las aplicaciones legacy existentes. Al
igual que los otros enfoques, ste puede ser aumentado con GSM.

Conclusin
Existen varios enfoques generales para el servicio de la identificacin y se deberan adoptar
enfoques relevantes para los entornos de los proyectos adecuados. En este artculo se
proporciona el anlisis de dichos procesos de identificacin de los servicios y los adapta al
entorno del proyecto adecuado.

Agradecimientos
El autor agradece a Ahamed Jalaldeen, Arquitecto lder en automatizacin de SOMA y a Ali
Arsanjani, Ingeniero Distinguido & CTO, tecnologas Emerging, y a SOMA por su orientacin y
soporte en este artculo.

Fijacin de los enfoques de la identificacin de SOA/SOMA

Service a los entornos del proyecto

Pagina 5 de 7

developerWorks

ibm.com/developerWorks/ssa/

Recursos
Aprender
"Service-oriented modeling and architecture" (developerWorks, Nov 2004) analiza los
aspectos ms destacados del modelado y de la arquitectura orientados al servicio.
Acceda a IBM Journal of Research and Development para obtener una lista completa de las
diferentes tcnicas en SOMA.
En SOA and Web services area on developerWorks, para obtener los recursos que usted
necesita para mejorar sus aptitudes.
Navegue por technology bookstore para encontrar libros sobre estos y otros temas tcnicos.
Obtener los productos y tecnologas
Descargue IBM product evaluation versions o explore the online trials in the IBM SOA
Sandbox y practique con las herramientas para el desarrollo de las aplicaciones y de los
productos middleware de DB2, Lotus, Rational, Tivoli, y WebSphere.
Comentar
Vea los blogs sobre developerWorks e involcrece con developerWorks community.

Fijacin de los enfoques de la identificacin de SOA/SOMA

Service a los entornos del proyecto

Pagina 6 de 7

ibm.com/developerWorks/ssa/

developerWorks

Sobre el autor
Gandhi Sivakumar
Gandhi Sivakumar es una Arquitecta de IT Senior Certificada de IBM / una
diseadora de soluciones SOA certificada por IBM y trabaja en el equipo de prctica
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. Adems es
miembro de la IBM Academy of Technology.
Copyright IBM Corporation 2010
(www.ibm.com/legal/copytrade.shtml)
Marcas
(www.ibm.com/developerworks/ssa/ibm/trademarks/)

Fijacin de los enfoques de la identificacin de SOA/SOMA

Service a los entornos del proyecto

Pagina 7 de 7