Versionamento de contratos WCF

147 views
Skip to first unread message

Rodrigo Nascimento

unread,
Oct 24, 2012, 10:37:25 AM10/24/12
to Grupo DotNetArchitects
Bom dia pessoal,
Estou trabalhando em um sistema que contem um serviço WCF que é consumido por vários clientes que, por sua vez, trabalham com várias linguagens diferentes. Hoje o serviço é consumido por clientes que usam Java, Ruby, .NET e Python. Temos agora a necessidade de alterar uma das classes do DataContract do serviço e, para isso, precisamos versionar o serviço.

Já li vários artigos mas não achei nada conclusivo. Gostaria de saber se alguém já teve esta necessidade com WCF e como conseguiu fazer o versionamento.

Muito obrigado.

--
Rodrigo

Luiz Carlos Faria

unread,
Oct 29, 2012, 9:27:32 PM10/29/12
to dotnetar...@googlegroups.com
Rodrigo,

Aconselho dar uma lida em materiais sobre SOA. Colocar um ESB na frente de sua camada WCF poderia ajudar. 

Com um ESB e configurações de transformação você consegue gerir diferentes contratos consumindo um mesmo serviço. Se os contratos sofrera mudanças significativas e são totalmente incompativeis, as transformações (de input e output) não resolverão teu problema, você terá de segmentar seus serviços, seus fontes, sua gestão. 

Se não me engano o BizTalk ESB Toolkit vc consegue fazer essas abstrações.

Sobre a abordagem, eu simplesmente nunca exponho um serviço WCF para terceiros. Se preciso fazê-lo, todos os proxies estão sob minha responsabilidade. Isso facilita nas negociações de mudança.

Uma dica: Diversos grandes fornecedores simplesmente não fazem este tipo de gestão. As CIAS aéreas por exemplo não fazem.

Não estou sugerindo que você não faça. Só estou alertando para que seja medido o custo desta implantação. Não é muito complexo provar que o custo de adequação dos clientes é menor do que o custo do versionamento de serviços.

[SendoFranco Off]
_______________________________________________________________
Luiz Carlos Faria




--
Rodrigo

--
Você recebeu esta mensagem porque faz parte do grupo .Net Architects hospedado no Google Groups.
Para postar envie uma mensagem para dotnetar...@googlegroups.com
Para sair do grupo envie uma mensagem para dotnetarchitec...@googlegroups.com
Para mais opções visite o grupo em http://groups.google.com/group/dotnetarchitects?hl=pt-br

Message has been deleted

Marcelo Vieira

unread,
Oct 31, 2012, 5:26:09 AM10/31/12
to dotnetar...@googlegroups.com
Boa Luis,

Só me permite uma ressalva: acho que precisaria tomar essa decisão mediante qualquer mudança do contrato (da "assinatura" do contrato). Se mudou uma "virgula" e isso vai afetar a implementação de chamada do client, então é preciso ser tratado quase como se fosse outro serviço.

Agora um adendo: se a "negociação" da exposição do serviço permitir, pode ser feito como em um cenário que vi, é criado um "segundo" serviço e o primeiro dispara vez em quando uma exceção com informações que o mesmo está com data de validade (...), para no caso os implementadores/
administradores dos client serem acionados e perceberem (seja olhando log, etc...) a mudança.

**nota, claro que nesse caso há mais coisas a serem discutidas e avaliadas conforme o negócio e contexto que envolvem o serviço.

Att.

Marcelo Vieira

Luiz Carlos Faria

unread,
Nov 2, 2012, 9:27:32 AM11/2/12
to dotnetar...@googlegroups.com
Marcelo,

A respeito das exceptions, jã vi uma abordagem interessante:. Envelopamento.

Imagine que toda mensagem de retorno fosse envelopada em uma mensagem genérica que contivesse as informações de gestão. Como, versão, avisos, depreciação, paralisação agendada.. etc.
Quando vi achei mt interessante.

Me veio a cabeça agora  a possibilidade de se ter um serviço exclusivo para informações de estado de outros serviços. Algo que pudesse começar a alarmar uma mudança, informando um endereço para maiores informações e que pudesse ser requisitado pelos clientes periodicamente.

A respeito das características do contrato, concordo que a menor mudança em um contrato faz com que o serviço seja novo, no entanto, não é absurdo pensarmos em mudanças que não ferem o comportamento da versão anterior, só enriquecem o contrato, de entrada e/ou saída. Para estes casos, uma camada de abstração poderia eliminar o versionamento do serviço, tendo apenas o versionamento do contrato (e implicitamente versionamento do endpoint). A conversão de contratos seria papel do ESB e clientes da v1 do serviço, nada muda, embora por baixo possa estar rodando a versão 2 ou 3 do serviço.

[ ]`s
_______________________________________________________________
Luiz Carlos Faria



Em 31 de outubro de 2012 07:24, Marcelo Vieira <marcel...@gmail.com> escreveu:
Boa Luis,

Só me permite uma ressalva: acho que precisaria tomar essa decisão mediante qualquer mudança do contrato (da "assinatura" do contrato). Se mudou uma "virgula" e isso vai afetar a implementação de chamada do client, então é preciso ser tratado quase como se fosse outro serviço.

Agora um adendo: se a "negociação" da exposição do serviço permitir, pode ser feito como em um cenário que vi, é criado um "segundo" serviço e o primeiro dispara vez em quando uma exceção com informações que o mesmo está com data de validade (...), para no caso os implementadores/administradores dos client serem acionados e perceberem (seja olhando log, etc...) a mudança.

**nota, claro que nesse caso há mais coisas a serem discutida e avaliada conforme o negócio e contexto que envolvem o serviço.


Att.

Marcelo Vieira

Em segunda-feira, 29 de outubro de 2012 23h28min15s UTC-2, Luiz Carlos Faria escreveu:
Reply all
Reply to author
Forward
0 new messages