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.
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
Em 24 de outubro de 2012 12:37, Rodrigo Nascimento
<rodrigo...@gmail.com>escreveu:
> 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
> --
> Você recebeu esta mensagem porque faz parte do grupo .Net Architects
> hospedado no Google Groups.
> Para postar envie uma mensagem para dotnetarchitects@googlegroups.com
> Para sair do grupo envie uma mensagem para
> dotnetarchitects+unsubscribe@googlegroups.com
> Para mais opções visite o grupo em
> http://groups.google.com/group/dotnetarchitects?hl=pt-br
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
Em segunda-feira, 29 de outubro de 2012 23h28min15s UTC-2, Luiz Carlos Faria escreveu:
> 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
> Em 24 de outubro de 2012 12:37, Rodrigo Nascimento <rodri...@gmail.com<javascript:>
> > escreveu:
>> 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
>> -- >> Você recebeu esta mensagem porque faz parte do grupo .Net Architects >> hospedado no Google Groups.
>> Para postar envie uma mensagem para dotnetar...@googlegroups.com<javascript:> >> Para sair do grupo envie uma mensagem para >> dotnetarchitec...@googlegroups.com <javascript:>
>> Para mais opções visite o grupo em >> http://groups.google.com/group/dotnetarchitects?hl=pt-br
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 <marcelo20...@gmail.com>escreveu:
> 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:
>> 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
>> Em 24 de outubro de 2012 12:37, Rodrigo Nascimento <rodri...@gmail.com>escreveu:
>>> 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
>>> --
>>> 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
>> --
> Você recebeu esta mensagem porque faz parte do grupo .Net Architects
> hospedado no Google Groups.
> Para postar envie uma mensagem para dotnetarchitects@googlegroups.com
> Para sair do grupo envie uma mensagem para
> dotnetarchitects+unsubscribe@googlegroups.com
> Para mais opções visite o grupo em
> http://groups.google.com/group/dotnetarchitects?hl=pt-br
