sábado, 16 de abril de 2016

MODELO: 'ONTOLÓGICO/CANÓNICO'


Este modelo consiste en definir atributos estándares y sus respectivas características, diseñados a nivel de entidades. Esto con la finalidad de la reutilización de esta información a nivel de los contratos de servicio, evitando de esta manera cualquier tipo de duplicidad en los datos.

El objetivo es que el modelo canónico proporcione los formatos de intercambio de datos del negocio, de manera que todos los componentes (servicios, aplicaciones, etc), sólo necesiten saber (como máximo) su propio formato de datos y el formato de datos predeterminado (el que comparte dentro del bus de servicio), ya que el modelo canónico de mensajes tambien representa el formato estándar utilizado para intercambiar información de negocios en un bus de servicio.

Dicho modelo está enfocado en la aplicación dos patrones:

- SCHEMA CENTRALIZATION.
- CANONICAL SCHEMA.


Dando solución a los PROBLEMAS siguientes:

¿Cómo pueden los contratos de servicio ser diseñados para evitar la definición de datos redundantes?.
Esto se refiere específicamente al contenido de los esquemas redundantes (muy comúnmente) y/o mal diseñados que en si son difíciles de gobernar.

¿Cómo pueden los servicios diseñarse para evitar la transformación del modelo de datos?.
Esto se refiere e impacta directamente a servicios con esquemas diferentes, con datos similares (Redundantes) y que requieren de transformación, con esto aumenta el esfuerzo de desarrollo, la complejidad del diseño y la sobrecarga de rendimiento en tiempo de ejecución, ya que el objetivo es llegar a la Interoperabilidad  intrínseca (de manera natural). 


La SOLUCIÓN sería:

Crear y seleccionar esquemas existentes físicamente separados del contrato de servicio (.WSDL), ya que justamente la representación más común que se utiliza para el modelo canónico mensaje es un conjunto de esquemas XML. Esto tiene la ventaja de hacer el tipo y definiciones de mensajes (esquemas) con el fin de reutilizarlos y compartirlos entre varios contratos.

Un modelo de datos canónico es conjunto definido de tipos, elementos, atributos y relaciones que representan las entidades de negocios, estas están justamente basadas en los requerimientos del negocio para el proyecto SOA. Los modelos de datos (esquemas) deben estar estandarizados (Modelo Canónico) a nivel de entidades, almacenado y versionado por medio de alguna herramienta que permita centralizar todo el Modelo Canónico (MDL) de entidades, para que ante algún requerimiento de información por parte de un servicio dentro del contrato se importe la referencia a la entidad y se reutilice el dato requerido. Esto evitará cualquier tipo de redundancia de información, problema de transformación a nivel de Xsd, etc.


¿Cómo diseñar un MDL?
Dependiendo de cuan grande sea la empresa puede que ya tenga algunos modelos de referencia (para las Telecomunicaciones existe SID-TM Forum, etc.).  La idea es tener un modelo base inicial para poder trabajar y que se ajusta a las necesidades, al cual se puede complementando con más entidades en base al levantamiento de información que se realice. Aquí están algunas ideas sobre cómo lograr un buen modelo conceptual MDL (muy similar a cualquier otro modelo de datos):

- Validar si se seguirá algun modelo base del modelo canónico (como SID).
- Enumerar todas las entidades principales que requiere su empresa (cliente, pedido, etc.).
- Relacionar las entidades.
- Especificar los atributos de las entidades.


TeleManagement Forum (TMF) han definido un conjunto de cuatro marcos conocidos colectivamente como Frameworx. Los marcos clave proporcionan un valor empresarial que son el 'Marco de la Información' (SID) y el 'Marco de Procesos' (eTOM). Ambos pueden ofrecer una mayor agilidad en los negocios. Dichos modelos SID representan el ejemplo más importante de los esfuerzos puestos en desarrollar formas eficientes de compartir información entre sistemas de telecomunicaciones. Incluso, el SID debe convertirse en el lenguaje que SOA proporcione como vocabulario, gramática y sintaxis base que utilicen los servicios para proporcionar o recibir información. Así mismo, se debe de asegurarse de que todo el tráfico de mensajes a través de la ESB esté alineado SID, así el esfuerzo necesario para integrar los servicios se reducirá drásticamente así como también se reducirá los costos de mantenimiento respetivamente.


Por otro lado, una contra que se debería tener en consideración es que ante algún cambio en el 'tipo/tamaño' del dato perteneciente a la entidad, se debe de considerar que esto impactará en las ‘N’ aplicaciones que reutilizan dicha entidad (por medio de sus Xsd), y en las otras ‘N’ aplicaciones consumidoras que también reutilizan en sus comunicaciones.

¿Cómo implementar un MDL?
Para implementar un MDL como ya se ha mencionado se debe de diseñar, modelar y relacionar las entidades de negocio, para esto uno se puede apoyar en herramientas empresariales como Enterprise Architect (Sparx), que permitira diseñar desde un Diagrama de Clases 'UML', poder modelar las entidades y a si mismo y generar en base al diagrama de clases, esquemas .XSD y clases .JAVA.


El Modelo Canónico de las entidades completo puede ser diseñado exportado y reutilizado en los para cada servicio dentro de sus contratos respectivamente:


Tal como se mencionó durante el desarrollo de un Servicio Web la idea es reutilizar el Modelo Canónico estandar dentro del Contrato tal como se puede apreciar en la imagen:


Finalmente, una de las cosas más importantes que se debe también hacer, es educar a la empresa en el uso del MDL, y las ventajas a largo plazo de la misma. La gente a menudo no se enfocan a largo plazo y prefieren optar un enfoque más pragmático para resolver los problemas que se enfrentan sin tener en cuenta el impacto de la misma en el futuro.

Para los intersados se pueden descargar los archivos utilizados desde aquí:

Modelado:
http://www.mediafire.com/download/zkfz3x3xazkrci6/XSD_Model_Generator.zip

Wsdl/Xsd:
http://www.mediafire.com/download/n2lbxbnxnk40i24/ModeloCanonico_Dummy.zip