lunes, 10 de marzo de 2014

Interoperabilidad a través de un Modelo de Datos Canónicos


En temas de interoperabilidad técnica, relacionada con SOA, el patrón Modelo de Datos Canónicos reviste un especial interés, ya que cuando fue elaborado se pensó como una "bala de plata" para los temas de integración e interoperabilidad, pero hasta el día de  hoy tiene sus pro y sus contras, como todo.

Según la wikipedia este patrón permite la comunicación entre sistemas que tienen diferentes modelos de datos, reduciendo costos y estandarizando la forma de comunicarse. Su adopción pasa por el uso de algún middleware, ESB, que permita implementar el patrón con lo cual las aplicaciones se desentienden de como transformar sus datos a las estructuras de datos de otras aplicaciones.

Veamos con un ejemplo de la vida real como funciona.

Digamos que tenemos una persona X que habla español y una persona Y que habla chino.
La unica forma que tienen estas dos personas de entenderse entre si es que la información intercambiada sea transformada de un idioma a otro, bien sea del español al chino o de chino al español.

Si agregamos 20 personas más, cada una con su idioma propio y sin repetir, pues cada persona tendrá que saber como transformar la información que envía al idioma de la persona que debe recibirlo, para que se puedan comunicar.

Algo similar es lo que se presenta cuando múltiples aplicaciones tienen que intercambiar información entre si,  ya que deben implementar transformaciones para los mensajes que se mandan o se reciben.
En nuestro ejemplo de las personas la solución es usar un idioma común para todas, algo como el Esperanto. De esta manera cada persona solo tiene que saber su idioma y el Esperanto, y eso es todo. Si tiene que hablar con otra persona que no domine su idioma usa el Esperanto y así se podrán entender.

Llevando esto al ámbito técnico la solución es usar el patrón Modelo de Datos Canónicos (MDC), el cual nos indica que debemos crear un modelo que sea común a todos los sistemas, de forma tal que se mapeen en él las principales entidades y sus atributos. De esta manera si  una aplicación X quiere enviar un objeto Persona a una aplicación Y, debe convertir su objeto Persona al objeto Persona del MDC para poder enviarlo a la aplicación destino. La aplicación destino entonces convertirá el objeto persona del MDC a su modelo propio y lo podrá usar. Algunas ideas al respecto las podrán encontrar en este enlace y en este otro.

 Por lo general este patrón es bueno usarlo en organizaciones que poseen múltiples sistemas legados que además tienen diferentes BD con diferentes esquemas y modelado de las entidades de negocio, pues es el escenario ideal para su implementación cuando se requiera alguna solución de integración. Este patrón y su implementación vienen también con formas negativas de implementarlo, por lo que es importante primero entenderlo adecuadamente, ver las buenas prácticas a seguir y contar con el apoyo de la organización para poder ejecutarlo, de lo contrario puede ser todo lo contrario de lo propuesto  inicialmente. Información al respecto la pueden encontrar en este enlace.

Por último mi recomendación es que se estudien el libro "Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions" de Gregor Hohpe y Bobby Woolf donde se explica correctamente este patrón.

En la siguiente entrada sobre este tema estaremos viendo como WSO2 plantea el tema del MDC usando su ESB

0 comentarios:

Publicar un comentario