[CatDotNet] Dices tu de nServiceBus…

Buenas!! Pues el próximo viernes 26 de febrero tendremos el placer de contar en Igualada con Sergio Bermudez quién nos presentará lo bueno y lo malo –si es que lo hay- de nServiceBus del amigo Udi Dahan, y cuyo pretexto utilizaremos para tomar, a posteriori, unos cacharros entre amigos y saber más sobre los ESB (ver foto).

Así que si estás por las cercanías, ¡¡te esperamos!!

CatDotNet_peque%c3%b1a

Virtualización de Servicios con Managed Services Engines

Desde mis primeras incursiones en el desarrollo de Servicios empresariales, básicamente desde la aparición de las primeras betas de WCF, ha habido un miedo escénico que me ha atormentado y es la programación déspota e incontrolada de servicios, servicios y más servicios, lo que deriva en la producción de 300 servicios, con 300 enlaces distintos (no más de 10 comunes), en 50 endpoints y cuyo valor operativo era equivalente a 50 servicios bien diseñados y gobernados.  No concebía una arquitectura sólida de servicios sin una “torre de control” o una “cabina de mando” desde dónde poder ver, gestionar y modificar nuestros servicios.

Más adelante tuve la oportunidad de trabajar en una arquitectura SOA desarrollada en J2EE, dirigida por un ESB de Oracle y gestionada con herramientas de gobernabilidad SOA, que manejaban más de un centenar de servicios (proxy y legacy) y dónde la publicación y consumo de dichos servicios se realizaban a través de estrictas normas protocolarias (seguridad, documentación,…).

Ahora vuelvo, de nuevo, a tener la misma necesidad, diseñar una infraestructura de servicios y cuando hablo de infraestructura hablo de ese tipo de herramientas fundamentales para el control de todos y cada uno de los servicios. Pero ahora (en realidad hace ya un tiempo que existe) me encontré con un software, bajo licencia  Microsoft Public License (Ms-PL) y código abierto, que adopta de forma práctica la idea de Virtualización de Servicios, llamado Managed Services Engine.

Virtualización de Servicios

La idea básica del patrón de Virtualización de Servicios es el de aislar la complejidad de los servicios expuestos del cliente que los consume ya que  tras cada servicio se alberga una gran cantidad de aspectos tales como las localizaciones de los endpoints, las configuraciones de los enlaces, la aplicación de políticas, etc. Además muchas de las adopciones SOA a la practica no ofrecen soluciones sobre versionado de servicios, aplicación de políticas de seguridad o cambios operativos sin necesidad volver a codificar el servicio así como el cumplimiento del SLA entre el proveedor –nosotros- y el cliente.

Aparece la idea de Servicio Intermediario que desacopla el cliente de la implementación del servicio. Como tal, podemos ofrece varios servicios virtuales de una misma implementación para, por ejemplo, utilizarlo en distintos escenarios. Es aquí dónde encontramos la clave de la virtualización, en el servicio intermediario, pues todas las llamadas se realizaran a través de este y podremos modificar su comportamiento sin comprometer los modelos del servicio.

 

Managed Services Engine

Microsoft Services SOA Infraestructure ofrece una solución de virtualización de servicios a través de Managed Services Engine (MSE). Como cabe esperar, MSE está basado en la plataforma Windows, esto es, Windows Server 2003/2008, SQL Server 2005/2008 y .NET Framework 3.5, especialmente con Windows Communication Foundation para la interceptación de comunicaciones entre servicios virtuales y reales.

MSE puede integrarse tanto con MS Biztalk Server 2006 R2 / 2009 para proporcionar capacidades adicionales tales como la monitorización de las actividades de negocio (BAM), el Business Rules Engine o el ESB Toolkit, entre otros. Además también podemos utilizar los servicios Azure a través de Azure AppFabric, especialmente con .NET Service Bus.

MSE consiste, básicamente, en tres componentes:

  • Messenger: proporciona la normalización del mensaje de entrada a través de los servicios virtuales. Este componente soporta además la aplicación de políticas (de transformación por ejemplo, tanto de peticiones como de respuestas) así como el mapeo de protocolos.
  • Broker: este componente obtiene el mensaje normalizado y lo reconvierte a la operación (es decir la implementación de un método del servicio) y su respectiva versión (pues podemos tener más de una operación con distintas versiones).
  • Dispatcher: una vez se tiene el mensaje y la operación pertinente, dispatcher invoca el método del servicio y se transmite dicho mensaje.

Recalcar que estos tres componentes están totalmente desacoplados unos de otros con lo que podríamos distribuirlos de forma que obtendríamos una gran cantidad de tipologías del sistema. Todo esto es gracias a la catalogo del servicio (Service Catalog), también conocido como repositorio de metadata o simplemente repository o repositorio, ya que contiene todos los modelos de los servicios que hospeda el runtime del MSE –incorpora asistentes para la importación de servicios a través del WSDL y otros mecanismos para servicios POX o REST-. Como dije anteriormente, MSE contiene una implementación de WCF así que es fácil intuir que la comunicación entre ellos se realizan a través de canales de mensajería. El repositorio, por último, utiliza una base de datos SQL Server y la información puede ser publicada en un registry externo UDDI 2.0/3.0.

Por último, MSE contiene una interfaz para la administración de los servicios –MSE Model Viewer– así como una herramienta de test –MSE Universal Service Tester-.

image

image

En próximos posts hablaré de las diferentes posibilidades que ofrece MSE desde el punto del vista del rol (developer, IT, architect,…) y como familiarizarse MSE.