Muchos de los proyectos en lo que tengo la suerte de trabajar estan relacionado con Arquitectura Orientada a Servicios. En estos proyectos es normal escuchar opiniones de las personas involucradas en estos proyectos respecto a lo que es SOA, lo que no es SOA, el mejor SOA, el peor SOA, etc. Además, acompañando estas opiniones vienen muchos mitos que por alguna razón surgen y luego persisten en la organización respecto a este tema. Por esta razón he decidido iniciar una serie de post acerca de estos mitos acerca de SOA. En la misma voy a tratar de ir mencionando todos los mitos que he escuchado e ir aclarándolos. Si alguno por ahi tiene algún tema que considera erróneo respecto a SOA, lo puede postear y con gusto lo voy a tratar.
SOA Myth 1: Estandarizar el Formato del Mensaje
Este quizás uno de los aspecto que más se menciona a la hora de construir un proyecto en este tipo de arquitecturas. Inicialmente, las empresas que quieren construir un core de mensajes – un ESB – primero miden el nivel de persuación que pueden tener en contra de sus “partners” y dicen cosas como:
- Nosotro definimos el mensaje y el que quiere integrarse tiene que cumplir con el esquema del mismo.
- Use lo que quieran en el core – cualquier tecnología – es problema de los partners si pueden integrarse bien o no.
Este pensamiento se da porque estamos acosumbrados a desarrollar aplicaciones locales que o comparten datos a través de su base de datos, o en el mejor de los casos se integran a través de servicios Web – arquitectura punto a punto. {he aquí otro mito: SOA y Servicios Web que atacaremos en otro post}
En realidad la idea del ESB es poder interconectar sistemas permitiendo no solamente a las empresas tener la posiblidad de conectarse sin conocer exactamente donde esta la aplicación ni que tipo de aplicación es, si no también brindándo la posibilidad de integrarse con el bus con los datos que actualmente tiene – o maneja - la empresa, caso contrario como haría la empresa para meter datos a un BUS que no tiene? Es por esta razón que los ESB tienen módulos para hacer mapping y functoids dentro de los mapas para mejorar la calidad del mensaje – al final los mapas son documentos XSLT que hacen transformaciones de los datos.
Otro punto a destacar es que no siempre el ESB solo sirve para exponer servicios, si no también para consumir. En este caso debemos acoplar el mensaje que viene con lo que estamos necesitando dentro del ESB y esto depende explícitamente de lo que vayamos a hacer dentro de nuestro workflow de negocios. En la siguiente figura se ven los dos esquemas de exposición de los EndPoints.
En el esquema con el Partner 1 el partner me expone el servicio que ya tiene desarrollado y yo procedo a consumirlo, en este caso tengo que mapear el mensaje que ingresa con el mensaje que se espera dentro del bus y transformarlo para que tenga la estructura que yo deseo. En el esquema con el partner 2 yo expongo el servicio con el formato de mensaje que yo establezco; en este caso, yo defino como me deben de llegar los mensajes. Al final lo que debe privar es la posiblidad de enviar y recibir mensajes sin importar quién define la estructura del mensaje y ninguna entidad debe forzar a otra entidad a cambiar sus esquemas de datos para satisfacer su flujo de trabajo.
No hay comentarios:
Publicar un comentario