O que é modelo Canônico Afinal?

Uma das perguntas mais frequentes para quem está implantando SOA em sua empresa é sempre referente ao modelo canônico, e porque isso?Porque esse tipo de modelagem é um facilitador, que:

• reduz o número de transações dentro de seus serviços;
• diminui o custo de infraestrutura e implementação;
• além de garantir uma maior padronização por aumento do reúso.

Neste post, eu vou passar por alguns pontos muito importantes dentro deste modelo, desde como ele se encaixa dentro de SOA, até mesmo como ele é modelado. E é claro, que stakeholders devem estar cientes desta modelagem, para que não aconteça retrabalho no projeto.De forma muito simplista, nós podemos dizer que Modelo Canônico é um modelo de dados universal utilizado pela camada SOA. Para entender isso, vamos analisar a sua aplicação em SOA e como fazer a modelagem.

Como Modelo Canônico se Aplica em SOA

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.Definir as entidades 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 WSDL pode ser recolocado na versão canônica.

Vamos então ver um exemplo: considere que uma empresa adquiriu outra. Ambas as empresas possuem a entidade Funcionário. No entanto, os esquemas 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, isto é, 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:

• Os Consumidores chamam o Serviço A. Ambos utilizam o modelo canônico para esse serviço, e nenhuma transformação é necessária, sendo esta a implementação ideal;
• O Consumidor chama o Serviço B, que está mapeado para o modelo canônico. A transformação para o modelo canônico ocorre dentro do barramento;
• O Consumidor chama o Serviço C. Um adaptador no próprio serviço transforma a mensagem do modelo local do serviço para o modelo canônico.

O modelo canônico existe para definir conceitos e agir como um mediador ideal.

Ele deve ser mantido de forma flexível e geral, dado que eles irão potencialmente absorver uma variedade de definições de entidades.Algo muito interessante de lembrar é que a evolução do seu serviço para o modelo canônico implica na evolução do contrato de seu WSDL, ou seja, é necessário que todos os consumidores se atualizem com o novo contrato.A evolução do modelo canônico deve ocorrer através da governança SOA (já fizemos um Webinar completo sobre o assunto). Os esquemas podem ser versionados, mantendo as versões antigas documentadas e indicando explicitamente a versão do esquema no namespace.Assim, tem-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.Bom, agora que você já sabe onde o Modelo se encaixa, vamos traçar o plano de modelagem.

Como fazer a Modelagem ideal

Em primeiro lugar, normalmente aprendemos a modelar banco de dados relacional, que tem como principal preocupação a normalização dos dados. Em seguida, aprendemos a modelar orientado a objetos, onde a normalização não é tão importante. A distribuição de responsabilidades, alta coesão e baixo acoplamento são mais importantes. Em SOA, a modelagem muda novamente: agora os dados e comportamento estão separados novamente. Distribuição de responsabilidades, alta coesão e baixo acoplamento continuam importantes, porém a ‘normalização semântica’ dos dados ganha maior força pois o escopo agora é muito maior. Quando falamos de recursos RESTful, a modelagem muda completamente, o que não tratarei em detalhes aqui. Fica para um post futuro!Costumo dizer que modelagem é um assunto indigesto, complexo, pesado. Digo isso porque leva um tempo para ser digerido, assimilado, e isso só é alcançado através de exercícios, ou seja, só se aprende fazer fazendo! Mas existem algumas ‘dicas’ que podem ajudar a encurtar este caminho.A parte mais difícil e complexa na modelagem do Modelo Canônico é a ‘normalização semântica’, mas vamos começar pela parte técnica:

• Como estamos falando em SOA e a maioria das implementações utiliza SOAP, a implementação do Modelo Canônico é em XML Schema;
• Deve ser definida um padrão de nomenclatura. Normalmente é utilizado como em java, UpperCamelCase para os tipos, ou seja, para os complexType e lowerCamelCase para campos, os element. Um exemplo é a imagem abaixo:

• Como as entidades do Modelo Canônico são reutilizadas por várias operações, não é possível definir a obrigatoriedade dos campos (elementos). Por este motivo todos os campos devem ser opcionais utilizando o atributo minOccurs="0" e não devem possuir nenhum tipo de restrição, como limite de tamanho;
• Utilize element para representar os campos, não attributes;
• Não utilize referência cíclica, mais conhecida como relacionamento bidirecional. Por exemplo: se a entidade Cliente possui um relacionamento com a entidade ContaCorrente não deve ser criado um relacionamento da entidade ContaCorrente para Cliente. Isso pode gerar problemas de performance e incompatibilidade em alguns clients ou ferramentas;

Depois da parte técnica, existem alguns tópicos conceituais relacionados a modelagem:

• Evite criar relacionamentos entre entidades muito independentes. Este tipo de composição pode ser feito na interface do serviço;
• Eventualmente uma associação é identificada, porém não é necessário que tais informações sejam estruturadas. Neste caso a desnormalização pode ser usada. Por exemplo: a entidade Endereço possui todos os campos estruturados, porém para a entidade Nota Fiscal esta normalização não é necessária, podendo ser um único campo texto;
• Em alguns casos similares ao exemplo acima o tipo de informação de uma determinada entidade muda de acordo com o contexto. Por exemplo para o contexto de faturamento o Cliente possui algumas informações e para o contexto de CRM possui outros. Neste caso a entidade Cliente pode ser ‘quebrada’ de acordo com o domínio;

Como assegurar que não aconteça Retrabalho

Para conseguir normalizar a nomenclatura e até mesmo definir como será a construção de das entidades canônicas é sempre necessário envolver todos os stakeholders do projeto.

Dessa forma, é possível juntar todas as informações de maneira central, evitando retrabalho. Essa é uma dor comum em SOA.

Também é muito interessante ter um repositório de todos os ativos da empresa garantindo que o serviço, antes de ser criado, passe por uma avaliação de reúso pelo que já existe dentro da sua empresa. Isso faz parte do processo de Governança.Com um processo bem estabelecido dentro do modelo canônico, você irá conseguir ter uma arquitetura madura e de muito reúso, sempre alinhado com a arquitetura corporativa. Você também pode conhecer nossa plataforma de API Management e entender como ajudamos grandes empresas com uma arquitetura ágil e robusta.

Confira também o vídeo abaixo, sobre SOA no mundo das APIs: