Antes de mais nada, Modelo Canônico é uma questão de semântica. Em se falando de SOA, o Modelo Canônico tem se tornado uma grande fonte de dúvidas e confusões. Na realidade, a solução SOA precisa incluir um amplo interesse do conjunto de design, refletindo informação das melhores práticas de arquitetura a fim de escalonar o suporte totalmente, consistente e acesso reutilizável da informação.
Mas antes de falar sobre canônico, vamos voltar em um tópico mais “básico” que acredito ser a origem de parte do problema: a Modelagem. É muito comum encontrar problemas de modelagem mas, tratando-se de serviço, a correção destes problemas torna-se um pouco mais complexa. Tal correção não pode ser encarada como um “simples” refactoring. Ao alterar o contrato de um serviço, todos os seus consumidores podem ser afetados, vai ser um “Deus nos acuda”. Uma vez que a alteração na interface dos serviços é complexa, sua modelagem merece atenção redobrada! Para isso é necessário trabalhar juntamente com a área de negócio, buscando sempre utilizar os mesmos termos para que a nomenclatura dos serviços tenha significado para a área de negócio.
Uma vez que os serviços e operações (ou capacidades) foram modelados, os parâmetros das operações precisam ser modelados. Esta modelagem NÃO deve levar em conta a nomenclatura dos sistemas já existentes e sim manter o mesmo critério adotado na modelagem dos serviços. Neste ponto o Modelo Canônico entra na equação, atuando como uma linguagem universal entre os sistemas envolvidos, facilitando o entendimento dos parâmetros dos serviços.
Então, respondendo a pergunta do título, uma definição simples de Modelo Canônico seria modelo de dados universal utilizado pela camada SOA.
Uma terminologia consistente é um bom ponto de partida na concepção de serviços mas isso por si mesmo não é suficiente. Você deve também ter um entendimento claro da forma como a informação do negócio é estruturada. Os parâmetros de entrada e saída, isto é as mensagens, são geralmente muito mais complexas do que dos únicos tipos de dados. Eles representam as definições complexas das entidades e os relacionamentos entre eles. O tempo de desenvolvimento e qualidade dos projetos SOA podem ser muito melhorados se arquitetos SOA alcançam o modelo canônico no designing dos formatos de dados expostos e modelos de serviços. O alinhamento resultante do processo, serviço/mensagem e modelos de dados aceleram o design, alcançam orientação normativa para a modelagem de dados e evita transformações desnecessárias.
Modelagem sempre é um assunto indigesto, 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 dificil e complexa na modelagem do Modelo Canônico é a ‘normalização semântica’, então vamos deixa-la para o próximo post, começando 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 (complexType) e lowerCamelCase para campos (element);
-
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 bi-direcional. Por exemplo: se a entidade Cliente possui um relacionamento com a entidade ContaCorrente não deve ser criado um relacionamento da entidadeContaCorrente para Cliente. Isso pode gerar problemas de performance e incompatibilidade em alguns clients / ferramentas;
Depois da parte técnica, existem alguns tópicos 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 do entedereço 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;
Modelagem é um assunto complexo e subjetivo. E ainda existem outras considerações a respeito da modelagem de Modelo Canônico.