En muchas ocasiones cuando estoy en consultorias relacionadas con arquitecturas orientadas a servicios – SOA – tengo que hacer mucho enfasis en el hecho de que tener web services en la organización no significa que tengo una arquitectura orientada a servicios. Al mismo tiempo, se me consulta que papel juega el MSE en la transición hacia una arquitectura orientada a servicios. En este post voy a tratar de aclarar estas dos dudas.
Tener Servicios Web no es tener SOA
Existe la creencia errada respecto a que tener servicios web para ser consumidos tanto internamente como externamente, me da automáticamente una arquitectura orientada a servicios. En realidad cuando implementamos servicios web dentro de nuestra organización estamos creando una arquitectura que se conoce como punto a punto. Esto se puede notar si tenemos muchos servidores Web hospedando los servicios, y/o si tenemos que consumir servicios web de muchas otras organizaciones ya sean externas o internas. En la siguiente figura podemos ver esta arquitectura.
En la figura anterior, podemos ver que las aplicaciones hacen referencias directas a servicios que retornan funcionalidad de negocios de las aplicaciones que desean acceder, teniendo en sus referencias el servidor donde estan hospedados estos servicios, el uri del servicio y el contrato de la implementación del servicio. Esto nos pone en desventaja ya que si tenemos que mover algún servicio de servidor, tenemos que actualizar todos los consumidores del mismo, ya que hay una referencia directa al servicio a través del servidor. Peor aún, si estamos consumiendo servicios externos y nos cambian la dirección del servicio, nuestra aplicación no funcionará correctamente si no se nos notifica a tiempo.
Otro problema que tendríamos además del ruteo de los mensajes es el manejo de los errores. Al tener diversas fuentes de donde consumir los servicios, los errores se van a almacenar y administrar en cada uno de los servidores internos o externos, de forma tal que no podemos crear logs centralizados para identificar que sucede en caso de presentarse algún error.
Además, dentro de los patrones de una arquitectura orientada a servicios, el concepto de servicio web no es exclusivo para su implementación. Esto por que en realidad en una arquitectura orientada a servicios yo puedo integrarme con servicios que implementen protocolos diversos tales como HTTP(s), TCP, etc.
Como me ayuda el MSE a tener una Arquitectura Orientada a Servicios
Una de las razones principales por la cual las organizaciones adoptan una arquitectura orientada a servicios es por la promesa de una alta flexibilidad en las aplicaciones. Esta promesa viene del hecho de que una arquitectura SOA diseñada correctamente reduce el tiempo de construcción de las aplicaciones y de los nuevos requerimientos en las aplicaciones ya existentes.
El primer requerimiento de una aplicación SOA bien diseñada es que cualquier aplicación puede ser accesada vía servicios ya sea interna o externamente lo cual permitirá la reutilización. Esto nos va a permitir desarrollar nuevas aplicaciones que requieran funcionalidad de las aplicaciones ya implementadas de forma más rápida y sencilla porque vamos a requerir menos código para tener acceso a la funcionalidad deseada. Sin embargo, si debo escribir cada servicio desde cero este requerimiento no se puede cumplir o cumplirlo sería muy costos en tiempo e inversión. Si se construyen estos servicios como aplicaciones aisladas, se van a crear servicios con funcionalidades duplicadas, será dificil tener un inventario de servicios disponibles y sus funcionaldiades, los logs de errores de los servicios estarían en cada uno de los servidores que almacenan el servicio, por citar alguno de los inconvenientes que tendríamos si no utilizamos una arquitectura orientada a servicios.
El segundo punto a tratar es que una arquitectura SOA bien diseñada tiene que tomar en cuenta es el cambio constante. En un ambiente empresarial SOA, los servicios tienden a cambiar mientras evolucionan. Estos cambios son de dos tipos: cambios en la interface y cambios en la implementación. El reto esta en encontrar una manera de convivir con la evolución de los servicios y el minimizar el efecto del cambio en los servicios en el consumidor de los mismos.
La pregunta que nos surge ahora es: ¿Qué rol juega el MSE en este escenario? Pues bien, el MSE nos permite llevar a cabo virtualización de servicios. La virtualización de servicios es un esquema de instalación y administración de servicios que nos brinda toda la “plomería” requerida por todos los servicios dentro de la organización. Esto le permite al desarrollador enfocarse en construir nueva funcionalidad y nos brinda una base de funcionalidad donde se requiere conectar con nueva funcionalidad.
Respecto al manejo de los cambios en los servicios, el MSE nos permite manejar este problema a nivel de operación. Este nos da la posibilidad de crear nuevas versiones de las operaciones existentes de los servicios. El MSE nos brinda esta funcionalidad por que el mantiene la interface de la operaciones del servicio conectada pero separada de su implementación, siendo este el principio básico para la virtualización de servicios. A través de la virtualización de servicios se pueden tener tantas versiones de la operación del servicio activas como sea necesarias, pero solamente una puede ser publicada a través del WSDL. Esta característica nos permite soportar la compatiblidad hacia versoines anteriores ya que los usuarios con versiones anteriores pueden serguir consumiendo el servicio y los nuevos usuarios usan el WSDL publicado del nuevo servicio, ambos casos sin complicación alguna. En el momento en que todos los clientes se muevan a la última versión del servicio, las versiones anteriores pueden ser desactivadas. La siguiente figura nos muestra la arquitectura del funcionamiento del MSE y sus funcionalidades en cada uno de los componentes que lo conforman.
Technorati Tags:
MSE,
C#,
Architecture,
SOA
