Patrón de esquema canónico

En ingeniería de software , el Esquema Canónico es un patrón de diseño , aplicado dentro del paradigma de diseño orientado a servicios , que tiene como objetivo reducir la necesidad de realizar transformaciones del modelo de datos ^{[ 1 ]} cuando los servicios ^{[ 2 ]} intercambian mensajes que hacen referencia al mismo modelo de datos. ^{[ 3 ]}

La interacción entre servicios a menudo requiere el intercambio de documentos comerciales. Para que un consumidor de servicios envíe datos (relacionados con una entidad comercial específica, por ejemplo, una orden de compra ), necesita conocer la estructura de los datos, es decir, el modelo de datos. Para ello, el proveedor de servicios publica la estructura de los datos que espera en el mensaje entrante del consumidor. En el caso de servicios implementados como servicios web, ^{[ 4 ]} este sería el documento de esquema XML. Una vez que el consumidor de servicios conoce el modelo de datos requerido, puede estructurar los datos en consecuencia. Sin embargo, en algunas circunstancias, es posible que el consumidor de servicios ya posea los datos necesarios, relacionados con un documento comercial específico, pero que estos no se ajusten al modelo de datos especificado por el proveedor de servicios. Esta discrepancia entre los modelos de datos genera la necesidad de transformar el modelo de datos para que el mensaje se adapte a la estructura requerida por el proveedor de servicios. Basándonos en el ejemplo anterior, es totalmente posible que, tras procesar el documento comercial recibido, el proveedor de servicios devuelva el documento procesado al consumidor, quien nuevamente realiza la transformación del modelo de datos para convertirlo de nuevo al modelo de datos que utiliza en su lógica para representarlo. Esta transformación del modelo de datos en tiempo de ejecución añade sobrecarga de procesamiento y complica el diseño de las composiciones de servicios. ^{[ 5 ]} Para evitar la necesidad de transformar el modelo de datos, el patrón Esquema Canónico exige el uso de modelos de datos estandarizados para aquellos documentos comerciales que suelen procesar los servicios de un inventario de servicios. ^{[ 6 ] [ 7 ]}

This design pattern is fully supported by the application of the Standardized Service Contract design principle. The Standardized Service Contract design principle advocates that the service contracts be based on standardized data models. This is achieved by performing an analysis of the service inventory blueprint^[8] in order to find out the commonly occurring business documents that are exchanged between services. These business documents are then modeled in a standardized manner. For example, in case of web services, the business documents are modeled as XML schemas. Once a standardized data representation layer exists in a service inventory, different service contracts can make use of the same data models if they need to exchange the same business documents. This eliminates the need for any data model transformation and reduces the processing overhead associated with the data model transformation. It also increases the reusability potential of a service as now the service can be consumed without requiring any custom data model transformation logic. In a way, the application of the Canonical Schema pattern reduces the need for the application of the Data Model Transformation^[9] design pattern.

The application of this design pattern requires design standards^[10] in place that make the use of standardized data models mandatory, as the mere creation of data models does not guarantee their use.^[11] Although simple in principle but difficult to enforce as it needs commitment from different project teams which may entail extra efforts, on part of each team, in terms of designing solutions that accommodate standardized data models. On some occasions, either because of the sheer size of the organization or because of the resistance from different segments of the enterprise, the Canonical Schema design pattern may need to be applied within a particular domain inventory, created by the application of the Domain Inventory design pattern.^[7] The schemas need to be designed separately than the service contract design so that there is no dependency between them.^[11]

• Canonical model

• Erl et al., (2009).SOA Design Patterns. Prentice Hall. ISBN 0-13-613516-1.
• Thomas Erl (2008).SOA Principles of Service Design. Prentice Hall. ISBN 0-13-234482-3.

• SOA Concepts
• SOA Terms Glossary
• SOA Design Patterns