Padrão de protocolo canônico

Protocolo Canônico é um padrão de design , aplicado dentro do paradigma de design de orientação a serviços , que tenta tornar os serviços , dentro de um inventário de serviços, ^[1] interoperáveis ​​entre si, padronizando os protocolos de comunicação usados ​​pelos serviços. Isto elimina a necessidade de protocolos de comunicação em ponte quando os serviços utilizam protocolos de comunicação diferentes. ^[2]

Justificativa

Os serviços desenvolvidos por diferentes equipas de projeto podem basear-se em diferentes mecanismos de comunicação. Como resultado, um inventário de serviços pode acabar tendo diferentes conjuntos de serviços, cada um em conformidade com um conjunto diferente de protocolos. Quando se trata de reutilizar serviços com diferentes protocolos de comunicação, é necessário algum tipo de mecanismo de ponte de comunicação. Por exemplo, os serviços desenvolvidos usando o protocolo de mensagens JMS são incompatíveis com os serviços que usam o .NET Remoting , portanto, para fazer uso desses dois tipos de serviços, é necessária alguma tecnologia de middleware que resolva a disparidade do protocolo de comunicação. Além de incorrer em custos extras, o uso de tal tecnologia de ponte adiciona latênciae sobrecarga de comunicação. Isso torna o serviço menos reutilizável e recombinável ^[3] e vai contra as diretrizes do princípio de design de Composabilidade de Serviço .

Para projetar um inventário de serviços onde todos os serviços sejam interoperáveis ​​entre si para que possam ser compostos em diferentes soluções, a aplicação do padrão Canonical Protocol dita a padronização dos protocolos de comunicação utilizados pelos serviços. Quando todos os serviços utilizam o mesmo protocolo de comunicação, a necessidade de uma tecnologia de ponte é eliminada e a comunicação entre os serviços é mais simplificada. ^[4]

Uso

A aplicação deste padrão de design requer a escolha de uma arquitetura tecnológica que forneça uma estrutura de comunicação comum para que todos os serviços em um inventário possam se comunicar entre si usando o mesmo protocolo de comunicação. Isso depende de como os serviços dentro de um inventário de serviços serão usados. Se os serviços fizerem apenas parte de composições de serviços que sempre usam um protocolo de comunicação específico (por razões de eficiência e segurança), então todos os serviços dentro desse inventário de serviços poderão ser construídos sobre tal protocolo de comunicação, mesmo que não seja o protocolo mais utilizado.

O padrão Canonical Protocol de Thomas Erl responde à pergunta: "Como os serviços podem ser projetados para evitar a ponte de protocolo?" ^[5] O problema é que os serviços que suportam diferentes tecnologias de comunicação comprometem a interoperabilidade, limitam a quantidade de consumidores potenciais e introduzem a necessidade de medidas de ponte de protocolo indesejáveis. A solução é que a arquitetura estabeleça uma única tecnologia de comunicação como o único ou principal meio pelo qual os serviços possam interagir. Portanto, os protocolos de comunicação (incluindo versões de protocolo) usados ​​dentro de um limite de inventário de serviços são padronizados para todos os serviços (ver diagrama).

Um dos mecanismos de comunicação mais maduros e amplamente utilizados é fornecido pela estrutura de serviços da Web. Além de escolher uma estrutura de comunicação, os protocolos de mensagens reais também precisam ser padronizados. Por exemplo, se os serviços da web são criados usando SOAP sobre HTTP ou simplesmente usando serviços RESTful . Da mesma forma, ao padronizar serviços da Web baseados em SOAP, a versão específica do protocolo SOAP também precisa ser acordada, ou seja, SOAP v 1.1 ou SOAP v 1.2.

Considerações

Para padronizar um protocolo de comunicação, as características do protocolo precisam ser comparadas com os requisitos de interação de serviço, incluindo segurança, eficiência e suporte a transações. No caso de serviços web, por exemplo, se uma composição de serviço requer suporte explícito a transações, então SOAP sobre HTTP seria uma escolha melhor do que usar serviços RESTful.

Em alguns casos, dependendo da tecnologia utilizada para construir o serviço, pode ser possível suportar dois conjuntos diferentes de protocolos, a fim de tornar o serviço acessível a diferentes tipos de consumidores de serviço (padrão de design Dual Protocols [6] ⁾ . Por exemplo, usando WCF , o mesmo serviço pode ser configurado para usar os protocolos HTTP e TCP/IP ao mesmo tempo.

Ao escolher uma estrutura de comunicação, a maturidade, a escalabilidade e quaisquer custos de licenciamento devem ser tidos em conta, uma vez que a construção de serviços que utilizem um protocolo que se tornará obsoleto num futuro próximo terá impacto na reutilização de tais serviços e exigirá tempo e esforços consideráveis. para redesenhar o serviço.

Referências

Notas

Fontes

• Thomas Erl et al., (2009).Padrões de Design SOA. Salão Prentice. ISBN  978-0-13-613516-6 .

links externos

• Conceitos SOA
• Glossário de termos SOA
• Padrões de projeto SOA