O modelo canônico é um facilitador para troca de dados entre serviços.
Assim como o ESB (Enterprise Service Bus) atua como um mediador, permitindo que web services conversem uns com os outros sem a necessidade de criar um relacionamento ponto-a-ponto específico para cada um deles, um modelo canônico permite que sejam definidos esquemas para as entidades de uma organização (ex. Cliente, Produto, Fatura, etc..), desta forma, todos serviços fazem uso desse mesmo modelo de dados canônico, reduzindo o número de transações, o custo de infraestrutura e o custo de implementação e garantindo uma maior padronização como consequência do aumento do reúso.
Definir as entidades separadamente para cada serviço implica em um contrato de serviço (WSDL) totalmente customizado para cada serviço. Isto pode significar muita redundância, também conhecido como desnormalização de esquema.
Qualquer serviço que necessite fazer troca de dados pode traduzir sua versão de dados local para versão canônica.
Considere que uma empresa adquiriu outra empresa. Ambas as empresas possuem a entidade Funcionário. No entanto, o esquema de ambas as entidades são diferentes. Utilizando o modelo de dados canônico, basta que os dois serviços mapeiem seus dados para o modelo canônico, eles não precisam mapear de um para o outro ou serem individualmente reescritos.
A transformação de dados local para o modelo canônico ocorre mais frequentemente de três formas:
- O Consumidor 1 chama o Serviço A. Ambos utilizam o modelo canônico, nenhuma transformação é necessária, sendo esta implementação a ideal;
- O Consumidor 2 chama o Serviço B. A transformação para o modelo canônico ocorre dentro do barramento;
- O Consumidor 3 chama o Serviço C. Um adaptador transforma a mensagem do modelo local do serviço para o modelo canônico.
O modelo canônico existe para definir conceitos e agem como mediadores ideais.
O modelo canônico deve ser mantido de forma flexível e geral, dado que eles irão potencialmente absorver uma variedade de definições de entidades.
A evolução do modelo canônico implica na evolução do contrato do serviço (WSDL), já que o esquema faz parte do contrato do serviço (WSDL), sendo assim, será necessário re-gerar código do serviço.
A evolução do modelo canônico deve ocorrer através da governança SOA. Os esquemas podem ser versionados. Indicando explicitamente a versão do esquema no namespace, têm-se a liberdade para mudar apenas os serviços necessários no momento, sem a necessidade de alterar todos os serviços de uma só vez. Os demais serviços podem ser alterados ao longo do tempo, mas o ideal é que essa atualização não demore a ser feita. Ter muitas versões de esquema canônico em uso, pode levar a não se ter mais o esquema canônico. As atividades de governança para este processo devem estar bem definidas.
Abraço,
Daniel Varanda
Representação do Modelo Canônico em uma abordagem SOA
