Hacia una Arquitectura Empresarial basada

en Servicios
Por José David Parra

"Entienda cómo una Arquitectura Orientada a Servicios (SOA) posibilitará la rápida creación de
aplicaciones basadas en comunidades de servicios interoperables."

En las últimas décadas, los departamentos de IT de las empresas han venido constru-yendo una
infraestructura que actualmente soporta en gran medida la operación de sus empresas y sus clientes.
El camino para llegar hasta este punto no ha sido fácil. Se ha aprendido de los errores y aciertos de
la industria. El resultado de este proceso, ha sido la creación y mantenimiento de un número
considerable de aplicaciones al interior de las empresas, cada una responsable de sus propias tareas.

El negocio cada vez exige crear aplicaciones más complejas, con menos tiempo y presu-puesto que
antes. Crear estas aplicaciones, requiere en muchos casos de funcionalida-des ya antes
implementadas como parte de otros sistema. En este punto los arquitectos de soluciones tienen dos
opciones:

1. Tratar de reutilizar la funcionalidad ya implementada en otros sistemas. Una labor difícil de

realizar, debido a que estos no fueron diseñados para integrarse o sobre plataformas y/o tecnologías
incompatibles entre ellas. Incluso en el caso de encon-trarse la manera técnica de realizar la
conexión, se debe asumir el riesgo de alterar un sistema en producción que esta funcionando sin
problemas.

2. Re implementar la funcionalidad requerida ("reinventar la rueda"). Aunque implica mas tiempo

de desarrollo, es la mas fácil y segura.

Por su facilidad y aunque no es la mas acertada a largo plazo, la segunda opción es la mas escogida.
Esto trae como resultado:

• Funcionalidad replicada por todos los aplicativos

• Dificultad de migración de los sistemas internos. Al haber múltiples conexiones des-de
sistemas que dependen de estos para su funcionamiento.
• Al no haber una estrategia de integración de aplicaciones, se generan múltiples pun-tos de
falla, que pueden detener la operación de todos los sistemas muy fácilmente.
• Un modelo así, por lo general no escala muy bien.
• El inconveniente final es una pobre respuesta al cambio. Las aplicaciones siguen siendo
concebidas desde un principio como islas independientes.

Como SOA nos puede ayudar

Una estrategia de aplicaciones empresariales debe facilitar su integración. Además que debe
motivar la construcción de servicios, mas que de aplicaciones. Estos servicios se encargarían de
exponer una funcionalidad bien definida a la aplicación que la requiera. De esta manera, una
aplicación final simplemente orquesta la ejecución de un conjunto de estos servicios, añade su
lógica particular y le presenta una interfaz al usuario final.

Figura 1. Un sistema sencillo basado en servicios. Una aplicación además de implemen-tar sus
propios componentes de negocio y datos, también puede reutilizar la funcionalidad de servicios
existentes en la red empresarial.

Exponer procesos de negocio como servicios es la clave a la flexibilidad de la arquitectu-ra. Esto

permite que otras piezas de funcionalidad (incluso también implementadas co-mo servicios) hagan
uso de otros servicios de manera natural, sin importar su ubicación física. Así un sistema evoluciona
con la adición de nuevos servicios y su mejoramiento. Donde cada servicio evoluciona de una
manera independiente. La Arquitectura Orienta-da a Servicios (SOA) resultante, define los servicios
de los cuales estará compuesto el sistema, sus interacciones, y con que tecnologías serán
implementados. Las interfaces que utiliza cada servicio para exponer su funcionalidad son
gobernadas por contratos, que definen claramente el conjunto de mensajes soportados, su contenido
y las políticas aplicables.

Visión interna de los servicios

Un servicio debe ser una aplicación completamente autónoma e independiente. A pesar de esto, no
es una isla, porque expone una interfaz de llamado basada en mensajes, capaz de ser accedida a
través de la red. Generalmente, los servicios incluyen tanto ló-gica de negocios como manejo de
estado (datos), relevantes a la solución del problema para el cual fueron diseñados. La manipulación
del estado es gobernada por las reglas de negocio.
Figura 2: Visión interna de los servicios. Un servicio funciona como una aplicación independien-
te. Teniendo sus propias reglas de negocio, datos, procedimientos de administración y operación.
Ex-pone toda su funcionalidad utilizando una interfaz basada en mensajes. Y por lo tanto carece de
una interfaz de usuario.

La comunicación hacia y desde el servicio, es realizada utilizando mensajes y no llama-das a

métodos. Estos mensajes deben contener o referenciar toda la información nece-saria para
entenderlo. La idea es que haya el mínimo posible de llamadas entre el cliente y el servicio.

Un servicio es la evolución en complejidad de un componente distribuido, y se diferencian en:

• Mucho menos acoplados con sus aplicaciones cliente que los componentes.
• Menor granularidad que los componentes.
• No son diseñados e implementados necesariamente como parte de una aplicación end-to-
end.
• Son controlados y administrados de manera independiente.
• Expone su funcionalidad a través de protocolos abiertos e independientes de plata-forma.
Incluso arriesgando el rendimiento y consumo de recursos.
• Son transparentes de su localización en la red, de esta manera garantizan escalabili-dad y
tolerancia a fallos.
• Tienen sus propias políticas de escalabilidad, seguridad, tolerancia a fallos, manejo de
excepciones, configuración, etc.

Diseñando con SOA en mente

La implementación ideal de un servicio exige resolver algunos inconvenientes técnicos inherentes a
su modelo:

• Los tiempos de llamado no son despreciables, gracias a la comunicación de la red, tamaño

de los mensajes, etc. Esto necesariamente implica la utilización de mensaje-ría confiable.
• La respuesta del servicio es afectada directamente por aspectos externos como pro-blemas
en la red, configuración, etc. Estos deben ser tenidos en cuenta en el diseño, desarrollándose
los mecanismos de contingencia que eviten la parálisis de las aplica-ciones y servicios que
dependen de él.
• Debe manejar comunicaciones no confiables, mensajes impredecibles, reintentos, mensajes
fuera de secuencia, etc.
Según lo anterior, se puede ver que la construcción de un servicio es una tarea mucho mas
complicada que la de un simple componente distribuido.

El servicio debe publicar una interfaz (por ejemplo, utilizando WSDL o proxies) fácilmen-te
localizable en la red. Esta interfaz debe servir como un contrato de servicio. Donde se describen
cada una de las funciones que provee, e incluso los niveles de prestación de servicio (SLA). Esta
interfaz debe estar claramente documentada de manera que sea muy fácil implementar una
conexión.

Un diseño exitoso de una arquitectura basada en servicios debe estar basado en una plataforma de
mensajería confiable, que aísle de la implementación funcional muchos de los problemas
anteriormente mencionados. Algunas de las responsabilidades de un me-canismo así, incluyen:

• Entrega garantizada de mensajes,

• Enrutamiento de peticiones a un servicio disponible,
• Seguridad del contenido de los mensajes,
• QoS (quality of service) Calidad del Servicio
• Escenarios fuera-de-línea

Entre mas de estas características tenga la tecnología elegida, menos problemas tendrá la solución
final en operación.

Una comunicación basada en mensajes por lo general implica que no existen sesiones. Por lo tanto,
los clientes no guardan estado en el servicio (mayor escalabilidad), y la au-tenticación se debe dar a
nivel de cada mensaje.
Por ultimo, los servicios deben ser diseñados para controlar internamente la transaccio-nalidad de
sus propias operaciones. No es recomendable que una transacción traspase los límites de un
servicio.

El problema de múltiples servicios

Cuando se usan múltiples servicios para implementar un sistema, es muy fácil que la comunicación
entre estos se salga de control. Por ejemplo, usted puede tener un servi-cio que llama a otros seis
servicios, algunos de los cuales llama a otros servicios, y de esta manera, muy fácilmente el sistema
se vuelve inmanejable. De esta manera, un sis-tema grande puede terminar con múltiples
dependencias. Detectar un problema de ren-dimiento o funcionalidad se puede volver muy
complicado.
Figura 3: Si no se cuenta con una estrategia adecuada de SOA, se puede llegar a una imple-
mentación de SOA como la anterior. Donde existe una explosión de dependencias entre los di-
ferentes servicios.

Una solución lógica a este problema es extraer los aspectos de procedimiento de varios servicios
dentro de uno dedicado, llamado servicio de negocio. Un servicio de negocio controla las acciones
paso a paso en la ejecución de algún trabajo, moviendo el sistema de un estado a otro. En cada paso,
este llamara una operación de negocio provista por un servicio.

Así, un servicio de negocio centraliza la definición del proceso, en vez de tener piezas del proceso
entre todos los servicios. Esto disminuye las dependencias entre servicios y las aplicaciones
clientes. Ayudando a facilitar la administración del sistema.
Figura 4: Un modelo mas simplificado. Introducir el concepto de servicios de negocio nos simplifi-
co considerablemente la arquitectura que se mostró en la figura 3. Aquí simplemente consolidamos
funcionalidades creando algunos servicios de negocio que hacen llamadas al resto de servicios.

Escogiendo un protocolo de mensajería

Independiente de la tecnología que se escoja para implementar la comunicación entre los servicios,
esta debe manejar los problemas ya enunciados anteriormente. A conti-nuación comparamos
algunas de las opciones de protocolos a utilizar:

Protocolo Pros: Contras:

A menos que se utilice HTTP y un serializador
SOAP, utiliza un protocolo propietario. Aunque
existen productos como Ja.NET
(http://j-integra.intrinsyc.com/) que permiten
Tiene el mejor rendimiento si se
interoperabilidad con Java 1.2+.
Remoting utiliza un serializador binario
No tiene las capacidades de mensajería
sobre TCP.
confiable, seguri-dad y enrutamiento de men-
sajes requeridas por SOA. Deben ser
implementados manualmente.
Promueven una arquitectura mas acoplada.
Web Services Protocolo abierto (independiente Su rendimiento sobre la red no es el mejor (en
XML de plataforma) comparación con un protocolo binario). Debido
Independiente de ubicación a que todo el flujo es texto. La
Fácil de implementar serialización/deserialización en los extremos
Promueven una arquitectura también contribuye a su pobre desempeño.
desacoplada. Aunque cuenta con una manera de hacer
 llamados asincrónicos, no tiene todas las
capacidades de mensajería requeridas por SOA.

Permite configurar un canal

binario sobre el cual se va toda la
mensajería SOAP.
Web Services Provee muchas de las Aunque basado en estándares, aun no existen
XML + Web características requeridas por SOA muchas implementaciones diferentes a la de
Services implementando las Microsoft. Esto complica la interoperabilidad.
Enhancements especificaciones WS-Security, Aun falta madurez en las implementaciones
(WSE) 2.0 WS-Routing, WS- actuales.
ReliableMessaging, entre otras.

Por ser un protocolo de mensajería

asincrónica basado en colas de
Aunque existen puentes con otros sistemas de
mensajes, ya incluye las
MSMQ mensajería basada en colas (como MQSeries de
características que brindan
IBM), es un pro-tocolo cerrado.
confiabilidad y desacoplamiento a
la transmisión de los mensajes.

Una comparación más completa entre Remoting y Web Services puede encontrarla en:

http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/cpguide/html/cpconchoosingcommunicationoptionsinnet.asp

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/bdadotnetarch14.asp

¿Qué es WSE?

Los Web Services Extensions constituyen los primeros entregables de una estrategia a largo plazo
denominada "Indigo" (por su nombre código al interior de Microsoft). La estrategia involucra la
implementación de la versión 1.2 de SOAP y de las especificaciones conocidas como WS-*. Las
cuales se encargaran de darle la seguridad, confiabilidad y demás requisitos de los sistemas basados
en Web Services. Algunas de las especificaciones son:

WS-Routing WS-Coordination
WS-Attachments WS-Transaction
WS-Security WS-Trust
WS-Inspection WS-SecureConversation
WS-Referral WS-Policy
WS-SecurityPolicy WS-PolicyAssertions
WS-PolicyAttachment WS-ReliableMessaging

Estas especificaciones son manejadas por la organización WS-I. De esta hace parte Mi-crosoft y una
multitud de fabricantes lideres en la industria. Esto demuestra el compro-miso por la construcción
de tecnologías completamente interoperables, basadas en es-tándares.

Estas especificaciones son manejadas por la organización WS-I. De esta hace parte Microsoft y una
multitud de fabricantes lideres en la industria. Esto demuestra el compromiso por la construcción de
tecnologías completamente interoperables, basadas en estándares.

• seguridad (encripción y firmas digitales) ,

• mensajería confiable,
• direccionamiento y enrutamiento, y
• coordinación y transaccionalidad.

Mayor información en:

http://www.ws-i.org
http://msdn.microsoft.com/webservices/

En conclusión, si medimos el rendimiento, una solución de mensajería basada en Remoting es la

mejor opción en un ambiente 100% .NET (a menos que se desee utilizar alguna de las soluciones de
interoperabilidad con Java). Pero como ya hemos dicho, la independencia de plataforma es muy
importante en una arquitectura basada en SOA, por lo tanto nuestra recomendación es utili-zar Web
Services XML más WSE 2.0.

Conclusiones
Considere desde ya una arquitectura basada en servicios, para manejar la complejidad y la constante
mejora de los sistemas actuales y futuros al interior de su empresa.
Tal como vimos, los servicios construidos como Web Services sin estado, son la mejor alternativa
disponible para construir una arquitectura altamente escalable. Aprovechan-do todas las ventajas
que trae SOA. Además son basados completamente en XML, ase-gurando su interoperabilidad.

Involucre desde ya tecnologías como Web Services y WSE 2.0, con la seguridad de no perder su
inversión de tiempo y esfuerzo. Así, una vez contemos con Indigo y Whidbey (la siguiente versión
de la suite de desarrollo de Microsoft), habrá todo el soporte res-tante durante el diseño y desarrollo,
para construir soluciones empresariales orientadas a servicios.

Mas Información y Recursos en-línea

Web Services seguros, confiables y transaccionales: Arquitectura y Composición

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwebsrv/html/wsoverview.asp
Web Services Developer Center

http://msdn.microsoft.com/webservices/

.NET Architecture Center

http://msdn.microsoft.com/architecture/

Microsoft Patterns and Practices

http://www.microsoft.com/resources/practices/

Charla de Pat Helland, de Microsoft. Donde introduce el concepto de SOA.

http://www.microsoft.com/usa/webcasts/ondemand/892.asp