Estratégia de versão do wsdl

Versão de serviços da Web.
por Gabriel Bechara.
Introdução.
Os serviços da Web são obrigados a mudar e evoluir ao longo do tempo. Os princípios de acoplamento solto da arquitetura orientada a serviços (SOA) implicam que os provedores de serviços podem lançar uma nova versão de um serviço compartilhado sem esperar que os consumidores se adaptem e que os consumidores do serviço devem testar e certificar em uma nova versão do serviço compartilhado antes de mudar. Consequentemente, talvez seja necessário que várias versões de um serviço compartilhado sejam executadas ao mesmo tempo e simultaneamente acessíveis por diferentes consumidores de serviços. Alguns consumidores de serviços podem precisar continuar usando uma versão antiga de um serviço até a migração do código do consumidor ocorrer. Portanto, o controle de serviços da Web é um assunto importante que deve ser considerado cuidadosamente em todas as abordagens SOA da empresa.
Os padrões atuais para serviços da Web não possuem suporte explícito para versões, exigindo arquitetos e desenvolvedores para resolver o problema através da aplicação de padrões. Este artigo:
Identifique os tipos de mudanças que podem ocorrer nos serviços.
No final deste artigo, você deve ter uma boa compreensão dos principais aspectos que devem ser tratados ao construir sua própria estratégia de controle de serviços da empresa.
Tipos de mudanças.
Uma mudança na implementação de um serviço da Web pode afetar seus consumidores, dependendo de vários fatores:
Uma alteração nos parâmetros de operação de um serviço da Web. Isso pode envolver a adição de novos parâmetros (isso afetará os consumidores atuais) ou uma alteração nos parâmetros existentes, como uma alteração em um documento XML que pode ser usado como um parâmetro de mensagem em um serviço da Web. As alterações em um documento XML podem envolver a adição de elementos ou atributos opcionais (isso pode afetar os consumidores atuais) ou de elementos obrigatórios (isso afetará os consumidores atuais).
Portanto, uma tipologia de mudanças nos serviços da Web pode ser criada em relação ao impacto nos consumidores atuais desses serviços. Uma abordagem é qualificar uma mudança que não afetará os consumidores atuais como uma versão menor e uma mudança que afetará os consumidores atuais como uma versão importante.
Menor lançamento.
Uma versão menor pode ser um dos dois tipos. A primeira é uma correção de um bug ou um aprimoramento de desempenho. Esse tipo não afetará o WSDL (Web Services Description Language) do serviço da Web. O segundo tipo consiste em adicionar novos métodos a um serviço da Web, onde o WSDL é alterado sem impacto nos consumidores de serviços. Uma distinção pode ser feita entre esses dois tipos ao rotular essas versões. Por exemplo, para o primeiro tipo, você pode alterar a segunda casa decimal do número da versão (1.0X), enquanto que para o segundo tipo você altera a primeira casa decimal do número da versão (1.Y0).
Major Release.
Um lançamento importante envolve uma mudança que quebrará a compatibilidade com versões anteriores. Neste caso, os consumidores devem ser modificados. Um lançamento que afeta somente as funcionalidades de um serviço da Web, sem afetar o WSDL, também é considerado uma versão importante. Isso ocorre porque os consumidores atuais não podem invocar a nova versão sem considerar as funcionalidades modificadas do serviço da Web. Agora que identificamos os vários tipos de mudanças e seu impacto nos consumidores atuais, vamos dar uma olhada em padrões diferentes para o controle de versão de serviços da Web.
Os padrões.
Padrão de consolidação do consumidor.
Quando uma nova versão de um serviço da Web é lançada - seja uma versão maior ou menor - os consumidores são notificados sobre a mudança e são responsáveis ​​por mudar o código para acessar a nova versão. O novo WSDL é publicado - em um registro UDDI, por exemplo - e uma notificação é enviada aos consumidores para que eles possam encontrar o novo serviço e estabelecer vinculação com o novo provedor de serviços. Uma prática para usar um registro UDDI envolve a associação de uma determinada versão de um tipo de porta a um tModel exclusivo. Um WSDL está associado a um tModel. Este tModel deve conter uma referência ao número da versão para uma versão principal porque duas versões principais implicarão dois WSDLs diferentes. O tModel pode conter uma referência à versão secundária se duas versões menores precisam ser acessadas ao mesmo tempo. Um consumidor desse portType / version poderia fazer uma pesquisa UDDI de páginas verdes para serviços que anunciam conformidade associando-se ao tModel da versão correspondente.
Este método pode impor mudanças no código do consumidor, pelo menos na pesquisa realizada no registro para acessar uma versão (maior ou menor) de um serviço, mesmo para lançamentos menores. E se você precisar ter duas versões menores executando ao mesmo tempo? Por exemplo, você pode querer implantar uma nova versão menor em um site de teste para ser usada por um número limitado de consumidores, mantendo a versão antiga para o resto. Os consumidores do serviço implantado no site de teste precisarão mudar o ponto final do serviço, mesmo que o WSDL não seja modificado (porque é uma versão menor). Neste caso específico, pode ser útil ter uma camada de indireção entre os consumidores e os provedores, para impulsionar a migração de diferentes consumidores de forma graciosa.
Figura 1. Padrão de ligação ao consumidor.
Nota: O padrão de vinculação do consumidor não implica o uso de UDDI; refere-se ao fato de que a decisão vinculativa é feita pelo lado do consumidor. Vamos discutir os usos interessantes deste padrão em um momento.
Padrão de camada de indutor.
Quando uma nova versão menor de um serviço da Web é lançada, o consumidor pode migrar de forma transparente para a nova versão. Essa capacidade é fornecida pela camada de indireção através de um mecanismo de roteamento que garante roteamento baseado em conteúdo ou roteamento baseado em usuário (com base no IP do solicitante, por exemplo, ou no principal do solicitante na propagação de funções de segurança) para chamar as diferentes versões de um serviço da Web.
O uso de uma camada de indireção permite que duas liberações menores coexistam sem alterar o código dos consumidores e ajuda a garantir uma migração graciosa para uma nova versão.
Figura 2. Camada do Padrão de Indireccional.
Mas no caso de uma versão importante, os consumidores precisarão mudar seu código. E se, por algum motivo organizacional, precisamos migrar para uma nova versão importante sem alterar o código atual dos consumidores, chamando o novo serviço com o cliente antigo? Isso pode acontecer se, por exemplo, algum motivo regulatório implique uma mudança acessível apenas através do uso da nova versão principal de um serviço, fornecida por um parceiro comercial externo à sua organização. Isso leva a usar um adaptador para permitir o uso de uma nova versão principal para consumidores atuais até que todo o código dos consumidores seja modificado.
Padrão do Adaptador.
O padrão do adaptador consiste em adaptar a solicitação e a resposta do cliente para poder consumir uma nova versão importante de um serviço. O uso deste padrão oferece uma migração mais suave, no caso de o uso de uma nova versão principal de um serviço ser obrigatório por algum motivo comercial, regulamentar ou organizacional.
Figura 3. Padrão do Adaptador.
Soluções para a aplicação dos padrões.
Os diferentes padrões podem ser aplicados de diferentes maneiras. Isso pode ser feito no código dos consumidores, mas isso raramente é o caso porque pode causar atrasos de codificação e aumentar a complexidade do código que gerencia o controle de versão. Uma alternativa é usar uma camada de mediação para desacoplar o consumidor do provedor e aplicar esses padrões na camada de mediação. O uso do Oracle Service Bus como camada de mediação fornecerá as funcionalidades do padrão Layer of Indirection associado ao Pattern Adapter, aliviando o código dos consumidores dessas preocupações. Veja a Figura 4.
Figura 4. Aplicando os padrões usando o Oracle Service Bus.
A utilização desta abordagem baseada no Oracle Service Bus oferece estas vantagens:
Uma mudança de lançamento menor pode ser abordada sem modificar os consumidores, e os sites de teste podem ser abordados através de roteamento baseado em conteúdo ou baseado em usuário.
A mediação no Oracle Service Bus é configurada principalmente usando proxies para acessar serviços empresariais. No meio há pipelines, consistindo em estágios, ações, ramos e nós de roteamento. A mensagem é adaptada dentro dessas encanamentos, roteando as solicitações nos nós de roteamento. A configuração dos proxies e dos serviços empresariais pode ser organizada com referência aos números de versão. Os proxies no Oracle Service Bus podem incluir no seu caminho uma referência ao lançamento principal e o serviço comercial pode incluir a versão maior e menor. Por exemplo, para um importante v1.XX, teremos um proxy, um ou mais serviços empresariais (um por lançamento menor) e um WSDL:
. e para o V2.XX principal:
Nota: Como os proxies eo WSDL são os mesmos para versões menores, o caminho que contém esses não precisa incluir uma referência à versão menor.
Nós abordamos o acesso a diferentes serviços através do Oracle Service Bus. Mas há outras questões a serem tratadas, como a implantação de duas versões diferentes de um provedor de serviços provenientes do mesmo ambiente de desenvolvimento. Esses serviços podem ter o mesmo caminho de contexto do módulo da Web Java Platform, Enterprise Edition (Java EE), porque eles podem ter sido desenvolvidos usando as mesmas ferramentas de desenvolvimento. Portanto, a menos que você forneça um script de compilação que adicione referência de versão no contexto do módulo Java EE Web, você pode querer considerar a implantação de diferentes versões do mesmo serviço em diferentes destinos. (Um alvo é um cluster ou um servidor gerenciado). Veja a Figura 5.
Figura 5. Implantando fornecedores de serviços em diferentes destinos.
Nota: algumas estruturas e ferramentas de desenvolvimento, incluindo o Oracle JDeveloper, automatizam a versão de alguns provedores de serviços. Essa capacidade foi estendida no Oracle JDeveloper 11 Technical Preview 4 para lidar com a versão de componentes de arquitetura de componentes de serviço (SCA) (vários serviços em um composto).
Serviços de apresentação e serviços de orquestração (serviços de processos de negócios) beneficiarão da transparência desta abordagem ao consumir outros serviços pertencentes à camada de serviços empresariais ou à camada de serviços de acesso a dados. Mas e os consumidores de serviços de apresentação? Um portal composto pode consumir serviços de apresentação usando Web Services para Portlets Remotos (WSRP) para consumir portlets remotos. O padrão Layer of Indirection, juntamente com o Adapter Pattern usando o Oracle Service Bus, também pode ser aplicado neste caso, mas podemos usar uma abordagem mais adaptada com base nas capacidades do portal. Os portais geralmente vêm com ferramentas de administração para configurar o acesso a portlets (serviços de apresentação reutilizáveis). O uso das regras e direitos baseados em funções dos usuários para exibir alguma parte do portal composto, dependendo das propriedades do usuário, pode ser mais apropriado para os serviços de apresentação. Isso é mais uma preocupação com um mecanismo de portal composto do que com o Oracle Service Bus.
Portanto, o controle de camada de serviços de apresentação é melhor acomodado usando o padrão de consolidação do consumidor. Nesse contexto, o padrão não é aplicado usando um registro UDDI para escolher o serviço. Neste caso, a aplicação deste padrão depende dos direitos ou do mecanismo de personalização fornecido pelo portal composto. Um aspecto importante deste uso específico deste padrão é que a escolha da versão é feita através da configuração, na ferramenta de administração do portal. Assim, não implicará qualquer modificação ou manutenção de código.
A figura abaixo mostra como um portal composto pode consumir portlets através do WSRP em diferentes versões do mesmo aplicativo. A seleção da versão do portlet a ser exposta é feita no mecanismo do portal composto.
Figura 6. O Padrão de Encadernação do Consumidor aplicado aos serviços de apresentação.
Isso permite que duas versões do mesmo aplicativo sejam executadas simultaneamente, expondo novas funcionalidades somente para usuários finais selecionados com base em atributos de perfil de usuário.
Conclusão.
O controle de versão dos serviços da Web pode ser gerenciado de várias maneiras, dependendo das restrições comerciais e da camada a que o serviço pertence. Neste artigo, abordamos práticas que podem ser aplicadas a uma variedade de tarefas de controle de versão:
Acessando e implantando várias versões de um provedor de serviços ao mesmo tempo.
Alguns fatores adicionais devem ser levados em consideração, incluindo o controle de XML Schemas e o gerenciamento de dependências entre serviços e os esquemas XML usados ​​por esses serviços. No nível organizacional, isso se tornará muito difícil de lidar sem as ferramentas adequadas para gerenciar dependências e para dirigir as mudanças de forma adequada e holística.
Gabriel Bechara trabalhou com pré-vendas e serviços de consultoria Oracle-BEA desde 2003. Um veterano de 15 anos da indústria de software, Gabriel atuou como arquiteto e assessor em grandes projetos, proporcionando experiência prática e feedback sobre conceitos que podem constituir uma base para construindo novos sistemas de informação. Seus interesses incluem metodologias para a definição de software e arquiteturas empresariais, com foco em integração empresarial e SOA.

Versão do Serviço SOA - Melhores Práticas.
Sumário executivo.
Este documento tem como objetivo destacar algumas das melhores práticas relacionadas ao Service Versioning em SOA. Essas melhores práticas são baseadas em problemas práticos que Torry Harris enfrentou ao implementar projetos SOA.
O controle de versão é um dos aspectos importantes da Governança SOA. Poucas estratégias de governança recomendam uma versão basilizada do serviço para evitar a complexidade do controle de versão. Por outro lado, poucas outras estratégias de governança preferem usar múltiplas versões do mesmo serviço para que mudanças e melhorias na interface de serviço não afetem os consumidores existentes. Este documento visa destacar os prós e os contras de cada abordagem e propõe melhores práticas que atendam os dois casos.
A solução técnica real para a implementação do controle de versão do serviço é considerada fora do escopo deste documento, pois existem várias abordagens simples e específicas para o fornecedor. O foco deste documento é descrever o princípio do controle de serviço e destacar as melhores práticas.
Por que o Versioning?
Visão geral do controle de versão do serviço.
Service Versioning é a abordagem seguida pelos desenvolvedores de serviços para permitir que várias versões do mesmo serviço estejam operacionais ao mesmo tempo. Para dar uma analogia, qualquer biblioteca de API de software reutilizável possui várias versões usadas por diferentes aplicativos. A mesma analogia se aplica aos serviços.
Exemplo de versão de versão do serviço.
Os serviços da Web são a maneira ideal de implementar serviços SOA. O diagrama a seguir ilustra o conceito de múltiplas versões ativas com visão dos serviços e a dependência com suas aplicações de consumo. No exemplo, existem dois serviços: Serviço de Processador de Pedidos e Serviço de Consulta de Estoque. Existem várias versões ativas para ambos os serviços. O diagrama mostra o caminho de dependência de 7 diferentes aplicativos usando várias versões desses dois serviços.
Prós e contras.
Alterações e aprimoramentos podem ser feitos em serviços individuais e lançados como novas versões sem causar impacto nas aplicações de consumo existentes.
Como mostrado no diagrama acima, várias versões podem levar rapidamente a muitos problemas de gerenciamento de dependência, aumentando assim com.
Em uma empresa, as aplicações do consumidor normalmente seriam desenvolvidas e mantidas por equipes diferentes. O múltiplo controle de versão oferece flexibilidade para a equipe priorizar e migrar para a versão mais recente de acordo com sua agenda e orçamento convenientes.
Qualquer bug-correção / erro descoberto em um ponto posterior dos serviços precisaria de uma correção adequada em todas as versões aplicáveis ​​do serviço. Isso, eventualmente, leva à má manutenção do código de serviço.
Há sempre um plano de reversão fácil no lugar quando um aplicativo enfrenta um problema com a nova versão. Pode continuar a interagir com uma versão estável anterior.
A solução personalizada precisaria ser seguida na maioria dos casos, exigindo a manutenção de várias cópias versionadas do WSDL e do esquema.
É necessária uma ferramenta adicional / registro de tempo de execução para buscar o URL do ponto final adequado com base no número da versão.
O código fonte dos serviços precisaria ser cuidadosamente controlado usando ramificação para que múltiplas versões de binários sejam geradas e mantidas adequadamente.
Baselined Services - No Versioning.
Visão geral dos serviços de Baselined.
O conceito de Baselined Services desencoraja o uso do controle de versão. Apenas uma versão finalizada do Serviço é mantida ativa em qualquer ponto do tempo, e todos os aplicativos de consumo apontam para uma e única versão do serviço, que é a versão em baseline.
Exemplo de serviços de Baselined.
O exemplo a seguir (adaptado do anterior) ilustra o conceito de serviços basilíngüe.
Prós e contras.
A Plataforma de Serviços representa uma visão única do portfólio de serviços corporativos, garantindo assim a "reutilização" em seu verdadeiro sentido.
Esta política é "muito rígida" em várias equipes de consumidores de aplicativos, onde, em todas as mudanças / aprimoramentos no serviço, seria necessário um pouco de trabalho de migração dentro do aplicativo.
A manutenção é bastante simplificada.
O design do serviço precisaria ser considerado com muito cuidado, garantindo compatibilidade com a frente e para trás. Isso pode ser um fator limitante, em alguns casos, para que as equipes de negócios planejem aprimoramentos importantes do serviço.
Não é necessário um registro de tempo de execução, pois os aplicativos de consumo mantêm um URL de ponto final fixo.
O procedimento de análise de impacto deve ser fortalecido para que as mudanças sejam implementadas com grande precisão.
O gerenciamento de código-fonte dos serviços é bastante simplificado, pois existe apenas uma versão para manter.
Desdobramentos de implantação ao vivo devem ser planejados cuidadosamente para que haja um impacto mínimo na aplicação do consumidor.
Melhores práticas.
Tendo descrito ambas as abordagens, e os seus prós / contras listados, torna-se muito difícil para as empresas escolherem uma abordagem específica. Os profissionais da abordagem de serviços versionados parecem ser ideais em comparação com os contras da abordagem de serviços de base. Assim, as recomendações de melhores práticas para a estratégia de governança de versão são.
Use um mix-and-match de ambos os mundos seguindo a abordagem de serviços versionados, ainda tendo controle sobre os pesadelos de versão limitando as versões ativas máximas para 3 Ao iniciar uma nova versão do serviço, somente os dois últimos continuam a permanecer ativos. Todas as versões mais baixas devem ser obsoletas e desarmadas. Isso significa que não existem mais de três versões ativas de um serviço em qualquer ponto do tempo. As políticas precisam ser estabelecidas e comunicadas às equipes de aplicativos do consumidor para garantir que a migração seja feita a tempo. A equipe de serviços não será responsável por impactos no aplicativo do consumidor se o aplicativo continuar usando uma versão obsoleta do serviço.
Torry Harris SOA engajamento.
Você está aqui: & # 160; Home THBS Insights Whitepaper - Melhores Práticas de Versão de Serviço SOA.
Baixe o Whitepaper.
Copyright © 2018 Torry Harris Business Solutions | Termos e Condições | Mapa do site.

estratégia de versão do Wsdl
Obter através da App Store Leia esta publicação em nosso aplicativo!
Controle de API da Web Services.
Ofereço uma pequena API de Serviços Web para meus clientes, que planejo evoluir ao longo do tempo. Então eu preciso de algum tipo de versão, mas não consigo encontrar nenhuma informação sobre como você faz algo assim.
Existe uma melhor prática?
Como posso continuar adicionando novas funcionalidades sem quebrar a compatibilidade com os consumidores de serviços da Web?
O controle de versão é um tópico complexo, então primeiro você precisa definir seus objetivos de forma mais descritiva. Seria ótimo dizer que você possui uma interface que assegura que você nunca quebrará a compatibilidade, mas dependendo do que é a nova funcionalidade, talvez nem seja possível. Portanto, existem diferentes situações e trade-offs diferentes.
Se a sua intenção é apenas fornecer novas funcionalidades a novos consumidores, e todos os seus consumidores são consumidores diretos (sem intermediários, frameworks, etc.), então uma abordagem de ponto final discreto é a melhor escolha. Cada vez que você adiciona uma característica que arrisca uma ruptura, crie um novo ponto final, dê-lhe um novo número de versão e, em seguida, deixe os consumidores saberem para validar contra e mudar suas configurações. Esta estratégia é bastante tentada e verdadeira, mas tem as desvantagens de colocar o fardo sobre os consumidores para manterem-se atualizados. Além disso, se houver dependências entre serviços, ele pode se tornar uma tarefa rudimentar. O lado positivo é se o código quebrar não é (diretamente) sua culpa.
A outra estratégia principal é a interface extensível. Existem três variedades diferentes aqui que tenho conhecimento. Primeiro, é o tipo de interface que tenta tão bem descrever o domínio do serviço que todas as funções possíveis que você pode adicionar são de alguma forma possíveis, dada a interface existente. Se isso parecer difícil, é. Você pode chamar isso de interface perfeita. Tudo é completamente descrito, mas o domínio inteiro também é completamente descrito. O "perfeito" é realmente apenas em papel.
A segunda variedade é o tipo que parece uma interface normal, mas adiciona pontos de extensão genéricos. Em WSDLs, isso significa xs: qualquer, pares de nome-valor ou algo semelhante. Você pode chamar isso de interface básica extensível. Não é muito difícil de fazer, mas não é sem suas complicações. Os pontos de extensão podem tornar a interface mais difícil de trabalhar em certas ferramentas (xs: qualquer), ou perder explicitamente a sua capacidade de validar entradas e saídas (pares nome-valor). Também é muito fácil abusar desses pontos de extensão de uma forma que torna a versão 3 ou 4 muito difícil de usar.
A terceira variedade é o tipo que converte sua interface em um byte-stream. Você pode chamar estas interfaces Deus. Eles não estão sem suas justificativas, mas se você estiver usando um, você pode querer perguntar por que você está usando os serviços da Web. Talvez você devesse estar pensando em TCP / IP bruto, ou HTTP GET / POST básico. Mas talvez você esteja cansado da complexidade de WSDLs e XSDs e você quer começar do zero, mas você está vinculado a serviços da web por algum motivo de infraestrutura. Perceba, no entanto, que, uma vez que você inicia esse caminho, você precisará de uma maneira totalmente nova de descrever aos seus consumidores como usar / não usar seu serviço, e se você usar o XSD para isso ... bem, você está basicamente de volta onde você começou.
Sua melhor aposta é conhecer todas essas opções e abordar o design do seu serviço tentando pela primeira vez a "interface perfeita", desistindo e adicionando pontos genéricos de extensibilidade. Tentando projetar a interface perfeita, irá forçá-lo a aprender coisas que melhorarão o seu serviço, não apenas a sua interface, mas isso levará tempo e, se você não limitar esse tempo de alguma forma, isso levará uma eternidade.
Um pouquinho de uma verdadeira interface de deus, existe a interface do wrapper. Se você possui camadas de sistema, você deseja que sua interface esteja em camadas também. Quando você muda a camada B, você só quer mudar a camada B, nem todas as instâncias na camada C.
A estratégia mais comum que eu vi é a versão do WSDL, adicionando a identificação do controle de versão (normalmente aaaa / MM [/ dd]) ao namespace de objetos no wsdl, a saber:
Isso pode ser feito em um nível per-type (types / schema) ou em todo o nível WSDL - & lt; definitions & gt; em 1.1 ou & lt; descrição & gt; em 2.0.
Um pouco datado, mas esse link do IBM Developer Works fornece o raciocínio para essa abordagem e, especificamente, quando as versões precisam ser incrementadas:
Versões compatíveis com versões anteriores / não-rompentes:
Removendo ou renomeando operações Alterando parâmetros para um método Mudando um tipo complexo.
Eu geralmente adiciono a seqüência de versão ao URL do serviço da web, me dando "pontos de extremidade versionados". O código que implementa esses pontos finais pode ser compartilhado, se as diferenças são triviais e podem ser tratadas pelo mesmo código, ou o código pode ser clonado ou em algum lugar intermediário.
Os diferentes pontos de extremidade controlados também podem usar os esquemas XML versionados, se for isso que você precisa.
Uma das possibilidades é projetar todas as operações do serviço web para ter apenas um parâmetro de um tipo que herda de algum tipo abstrato que contenha o número da versão. Esta abordagem é implementada pela plataforma de serviços da Web eBay. Algo como o seguinte:
Além disso, se você trabalha em http, talvez seja necessário adicionar a versão como um parâmetro http GET para o URL do ponto final do serviço web, para que você possa detectar a versão solicitada facilmente servidor / serviço? Versão = 1.
Adicione o "número da versão da API" como parâmetro em todas as APIs, em seguida, implemente o padrão de estratégia no seu código de serviço da web, onde o número da versão determina a estratégia a ser usada.

estratégia de versão do Wsdl
Thomas Erl é um autor de TI e fundador da Arcitura e comércio; Education Inc. Thomas é o autor de tecnologia do serviço mais vendido no mundo por mais de sete anos e é o editor de séries da Prentice Hall Service Technology Series de Thomas Erl (servicetechbooks). Com mais de 300.000 cópias impressas em todo o mundo, seus livros se tornaram best-sellers internacionais e foram formalmente aprovados por membros seniores das principais organizações de TI, como IBM, Microsoft, Oracle, Intel, Accenture, IEEE, HL7, MITRE, SAP, CISCO, HP, e muitos outros.
Vários de seus livros, incluindo Cloud Computing Design Patterns, Cloud Computing: Concepts, Technology & amp; Arquitetura, SOA Design Patterns, SOA Principles of Service Design e SOA Governance, foram criados em colaboração com a comunidade de TI e contribuíram para a definição de mecanismos de tecnologia da computação em nuvem, o modelo arquitetônico orientado para o serviço e a orientação do serviço como um paradigma distinto . Seu título mais recente, Arquitetura Orientada a Serviços: Análise & amp; Design para Serviços e Microservices, posiciona formalmente e introduz novos padrões para o modelo arquitetônico da Microservice como parte da SOA.
Como CEO da Arcitura & Trade; Education Inc. e em cooperação com SOA School, Cloud School e Big Data Science School, Thomas liderou o desenvolvimento de currículos para o SOA Certified Professional reconhecido internacionalmente (SOACP), Cloud Certified Professional (CCP) e Big Data Science Certified Professional (BDSCP ) programas de acreditação, que estabeleceram uma série de certificações de indústria formal, neutras do fornecedor, obtidas por milhares de profissionais de TI em todo o mundo.
Thomas é o membro fundador do SOA Manifesto Working Group e autor do Annotated SOA Manifesto (soa-manifesto). Durante 10 anos, ele foi o editor da The Service Technology Magazine, e ele supervisiona as iniciativas SOAPatterns, CloudPatterns e BigDataPatterns, dedicadas ao desenvolvimento contínuo de catálogos de padrões principais para arquitetura orientada a serviços, computação em nuvem e Big Data .
Thomas visitou mais de 20 países como palestrante e instrutor e participa regularmente de conferências internacionais. Mais de 100 artigos e entrevistas de Thomas foram publicados em numerosas publicações, incluindo The Wall Street Journal e CIO Magazine.
David Orchard é o ex-diretor técnico do BEA Systems CTO Office, com foco em padrões de serviços da Web. Ele é um membro eleito do Grupo de Arquitetura Técnica do W3C e é um editor nomeado da extensibilidade e versão de versão do W3C TAG; Arquitetura de serviços da Web, XML e comitês consultivos.
Ele é atualmente ou foi um co-editor da arquitetura de serviços da Web, cenários de uso de serviços da Web, WS-Coordination, WS-ReliableMessaging, WS-Addressing, WS-Eventing, WS-MetadataExchange, WS-Transfer, SOAP-Conversation, XML Link e XInclude especificações.
Ele escreveu vários artigos técnicos, é o co-autor do Web Service Contract Design & amp; Versão para SOA, e é um falante freqüente em várias tecnologias relacionadas à Internet.
James Pasley é um arquiteto com Workday e um membro de sua equipe de Integração sob demanda. James é especialista no cliente que enfrenta aspectos da arquitetura de integração do Workday, como os serviços públicos da Web do Workday. James é editor do site de desenvolvimento do Workday e também cria muito material para os cursos de treinamento relacionados à integração da Workday. James juntou-se à Workday através da aquisição do software Cape Clear.
James ingressou no Cape Clear Software em 2001 como desenvolvedor principal do Cape Studio. Em 2003, James foi nomeado Arquiteto Chefe da Cape Clear, onde supervisionou o desenvolvimento do Enterprise Service Bus (ESB) do Cape Clear. Em 2005, James tornou-se Diretor de Tecnologia do Cabo Clear Software. A Cape Clear foi reconhecida pela Gartner e pela Forrester como o Enterprise Service Bus líder, oferecendo confiabilidade, escalabilidade e desempenho comprovados de integração sob demanda para conectar qualquer conteúdo, serviços ou software através da internet usando tecnologias de serviços da Web.
Antes de ingressar no Cape Clear Software, James trabalhou para a Siemens Nixdorf, desenvolvendo soluções seguras de mensagens X.400 e infra-estrutura de chave pública (PKI) para uma variedade de produtos.
James possui um B. A. (Moderator) em Computer Science do Trinity College, Dublin e é co-autor do Web Service Contract Design & amp; Versão para SOA.
Fundamentos de versão do contrato de serviços da Web Parte II:
Identificadores de versão e estratégias de versão.
Resumo: Existem diferentes formas de contratos de serviços de versão com base em políticas, prioridades e requisitos. Este, o segundo artigo em uma série de duas partes do livro "Web Service Contract Design & Versioning for SOA", apresenta três estratégias de controle de versão comuns: rigorosas, flexíveis e soltas. Os prós e contras de cada abordagem são discutidos e classificados em relação ao rigor, impacto de governança e complexidade. O papel dos identificadores de versão também é explorado através de uma série de exemplos.
O seguinte artigo é um trecho do novo livro "Web Service Contract Design and Versioning for SOA" [REF-1] Copyright 2008 Prentice Hall / Pearson PTR e SOA Systems Inc. Observe que as referências dos capítulos foram intencionalmente deixadas no artigo, conforme requisitos de Prentice Hall.
Um dos padrões de design mais fundamentais relacionados ao design do contrato de serviços da Web é o padrão de identificação da versão. Ele essencialmente defende que os números de versão devem ser claramente expressos, não apenas no nível do contrato, mas até as versões dos esquemas que estão subjacentes às definições das mensagens.
O primeiro passo para estabelecer uma estratégia de controle de versão efetiva é decidir sobre um meio comum pelo qual as próprias versões são identificadas e representadas nos contratos de serviços da Web.
As versões quase sempre são comunicadas com os números de versão. O formato mais comum é um decimal, seguido por um período e depois outro decimal, como mostrado aqui:
Às vezes, você verá um período adicional + pares decimais que levam a números de versão mais detalhados como este:
O significado típico associado a esses números é a medida ou o significado da mudança. Incrementar o primeiro decimal geralmente indica uma grande mudança de versão (ou atualização) no software, enquanto que os decimais após o primeiro período geralmente representam vários níveis de mudanças de versão menores.
Do ponto de vista da compatibilidade, podemos associar significado adicional a esses números. Especificamente, a seguinte convenção surgiu no setor:
Espera-se que uma versão menor seja compatível com outras versões menores associadas a uma versão principal. Por exemplo, a versão 5.2 de um programa deve ser totalmente compatível com as versões 5.0 e 5.1. A major version is generally expected to break backwards compatibility with programs that belong to other major versions. This means that program version 5.0 is not expected to be backwards compatible with version 4.0.
This convention of indicating compatibility through major and minor version numbers is referred to as the compatibility guarantee. Another approach, known as "amount of work," uses version numbers to communicate the effort that has gone into the change. A minor version increase indicates a modest effort, and a major version increase predictably represents a lot of work.
These two conventions can be combined and often are. The result is often that version numbers continue to communicate compatibility as explained earlier, but they sometimes increment by several digits, depending on the amount of effort that went into each version.
There are various syntax options available to express version numbers. For example, you may have noticed that the declaration statement that begins an XML document can contain a number that expresses the version of the XML specification being used:
That same version attribute can be used with the root xsd:schema element, as follows:
You can further create a custom variation of this attribute by assigning it to any element you define (in which case you are not required to name the attribute "version").
An alternative custom approach is to embed the version number into a namespace, as shown here:
Note that it has become a common convention to use date values in namespaces when versioning XML schemas, as follows:
In this case, it is the date of the change that acts as the version identifier. In order to keep the expression of XML Schema definition versions in alignment with WSDL definition versions, we use version numbers instead of date values in the examples throughout the upcoming chapters. However, when working in an environment where XML Schema definitions are separately owned as part of an independent data architecture, it is not uncommon for schema versioning identifiers to be different from those used by WSDL definitions.
Regardless of which option you choose, it is important to consider the Canonical Versioning pattern that dictates that the expression of version information must be standardized across all service contracts within the boundary of a service inventory. In larger environments, this will often require a central authority that can guarantee the linearity, consistency, and description quality of version information. These types of conventions carry over into how service termination information is expressed (as further explored in Chapter 23).
There is no one versioning approach that is right for everyone. Because versioning represents a governance-related phase in the overall lifecycle of a service, it is a practice that is subject to the conventions, preferences, and requirements that are distinct to any enterprise.
Even though there is no de facto versioning technique for the WSDL, XML Schema, and WS-Policy content that comprises Web service contracts, a number of common and advocated versioning approaches have emerged, each with its own benefits and tradeoffs.
In this chapter we're going to single out the following three known strategies:
Strict - Any compatible or incompatible changes result in a new version of the service contract. This approach does not support backwards or forwards compatibility.
Flexible - Any incompatible change results in a new version of the service contract and the contract is designed to support backwards compatibility but not forwards compatibility.
Loose - Any incompatible change results in a new version of the service contract and the contract is designed to support backwards compatibility and forwards compatibility.
These strategies are explained individually in the upcoming sections and referenced throughout the remaining chapters.
Strategy #1: The Strict Strategy (New Change, New Contract)
The simplest approach to Web service contract versioning is to require that a new version of a contract be issued whenever any kind of change is made to any part of the contract.
This is commonly implemented by changing the target namespace value of a WSDL definition (and possibly the XML Schema definition) every time a compatible or incompatible change is made to the WSDL, XML Schema, or WS-Policy content related to the contract. Namespaces are used for version identification instead of a version attribute because changing the namespace value automatically forces a change in all consumer programs that need to access the new version of the schema that defines the message types.
This "super-strict" approach is not really that practical, but it is the safest and sometimes warranted when there are legal implications to Web service contract modifications, such as when contracts are published for certain inter-organization data exchanges. Because both compatible and incompatible changes will result in a new contract version, this approach supports neither backwards or forwards compatibility.
The benefit of this strategy is that you have full control over the evolution of the service contract, and because backwards and forwards compatibility are intentionally disregarded, you do not need to concern yourself with the impact of any change in particular (because all changes effectively break the contract).
On the downside, by forcing a new namespace upon the contract with each change, you are guaranteeing that all existing service consumers will no longer be compatible with any new version of the contract. Consumers will only be able to continue communicating with the Web service while the old contract remains available alongside the new version or until the consumers themselves are updated to conform to the new contract.
Therefore, this approach will increase the governance burden of individual services and will require careful transitioning strategies. Having two or more versions of the same service co-exist at the same time can become a common requirement for which the supporting service inventory infrastructure needs to be prepared.
Strategy #2: The Flexible Strategy (Backwards Compatibility)
A common approach used to balance practical considerations with an attempt at minimizing the impact of changes to Web service contracts is to allow compatible changes to occur without forcing a new contract version, while not attempting to support forwards compatibility at all.
This means that any backwards-compatible change is considered safe in that it ends up extending or augmenting an established contract without affecting any of the service's existing consumers. A common example of this is adding a new operation to a WSDL definition or adding an optional element declaration to a message's schema definition.
As with the Strict strategy, any change that breaks the existing contract does result in a new contract version, usually implemented by changing the target namespace value of the WSDL definition and potentially also the XML Schema definition.
The primary advantage to this approach is that it can be used to accommodate a variety of changes while consistently retaining the contract's backwards compatibility. However, when compatible changes are made, these changes become permanent and cannot be reversed without introducing an incompatible change. Therefore, a governance process is required during which each proposed change is evaluated so that contracts do not become overly bloated or convoluted. This is an especially important consideration for agnostic services that are heavily reused.
Strategy #3: The Loose Strategy (Backwards and Forwards Compatibility)
As with the previous two approaches, this strategy requires that incompatible changes result in a new service contract version. The difference here is in how service contracts are initially designed.
Instead of accommodating known data exchange requirements, special features from the WSDL, XML Schema, and WS-Policy languages are used to make parts of the contract intrinsically extensible so that they remain able to support a broad range of future, unknown data exchange requirements.
The anyType attribute value provided by the WSDL 2.0 language allows a message to consist of any valid XML document. XML Schema wildcards can be used to allow a range of unknown data to be passed in message definitions. Ignorable policy assertions can be defined to communicate service characteristics that can optionally be acknowledged by future consumers.
These and other features related to forwards compatibility are discussed in upcoming chapters.
The fact that wildcards allow undefined content to be passed through Web service contracts provides a constant opportunity to further expand the range of acceptable message element and data content. On the other hand, the use of wildcards will naturally result in vague and overly coarse service contracts that place the burden of validation on the underlying service logic.
Provided here is a table that broadly summaries how the three strategies compare based on three fundamental characteristics.
Table 1 - A general comparison of the three versioning strategies.
The three characteristics used in this table to form the basis of this comparison are as follows:
Strictness - The rigidity of the contract versioning options. The Strict approach clearly is the most rigid in its versioning rules, while the Loose strategy provides the broadest range of versioning options due to its reliance on wildcards. Governance Impact - The amount of governance burden imposed by a strategy. Both Strict and Loose approaches increase governance impact but for different reasons. The Strict strategy requires the issuance of more new contract versions, which impacts surrounding consumers and infrastructure, while the Loose approach introduces the concept of unknown message sets that need to be separately accommodated through custom programming. Complexity - The overall complexity of the versioning process. Due to the use of wildcards and unknown message data, the Loose strategy has the highest complexity potential, while the straight-forward rules that form the basis of the Strict approach make it the simplest option.
Throughout this comparison, the Flexible strategy provides an approach that represents a consistently average level of strictness, governance effort, and overall complexity.
Each strategy also determines how compatible changes, incompatible changes, and version identifiers are used and applied in support of the rules and conventions of the strategy. Chapters 21, 22, and 23 explore the application of these strategies individually to WSDL definitions, XML Schema definitions, and WS-Policy definitions.

Estratégias de versão.
Artigos nesta série.
Uma vez que os serviços são empurrados para a produção, seus documentos WSDL associados - que representam pontos de extremidade de serviço, protocolos e contratos relacionados que descrevem operações e mensagens - não devem ser alterados. Ou, pelo menos, qualquer alteração deve ser compatível com versões anteriores para que os clientes existentes não sejam afetados quando as alterações são publicadas. Nesta seção, discutirei como os contratos do WCF suportam compatibilidade com versões anteriores e explicam algumas estratégias de controle de versões que você pode considerar para seus aplicativos do WCF.
Contratos WCF e compatibilidade com versões anteriores.
Os contratos WCF são tolerantes à versão por padrão. A Figura 1 e a Figura 2 resumem as mudanças típicas nos contratos de serviços e de dados e descrevem o impacto para os clientes existentes. Em suma, o DataContractSerializer permite dados faltantes e não necessários e ignora dados supérfluos para contratos de serviços, contratos de dados e, de forma semelhante, contratos de mensagens. Somente a remoção de operações ou a adição ou remoção de dados exigidos causa problemas com clientes existentes.
Figura 1: Contratos de serviço e compatibilidade com versões anteriores.
Adicionando novos parâmetros a uma assinatura de operação.
Cliente não afetado. Novos parâmetros inicializados em valores padrão no serviço.
Removendo parâmetros de uma assinatura de operação.
Cliente não afetado. Os parâmetros superfluos passados ​​pelos clientes são ignorados, dados perdidos no serviço.
Modificando os tipos de parâmetros.
Uma exceção ocorrerá se o tipo de entrada do cliente não puder ser convertido no tipo de dados do parâmetro.
Modificando tipos de valor de retorno.
Uma exceção ocorrerá se o valor de retorno do serviço não puder ser convertido no tipo de dados esperado na versão do cliente da assinatura da operação.
Adicionando novas operações.
Cliente não afetado. Não invocará operações sobre as quais nada sabe.
Uma exceção ocorrerá. As mensagens enviadas pelo cliente para o serviço são consideradas como usando um cabeçalho de ação desconhecido.
Figura 2: Contratos de dados e compatibilidade com versões anteriores.
Adicione novos membros não obrigatórios.
Cliente não afetado. Os valores perdidos são inicializados para padrões.
Adicione novos membros necessários.
Uma exceção é lançada para valores faltantes.
Remova membros não requeridos.
Dados perdidos no serviço. Não é possível retornar o conjunto de dados completo de volta ao cliente, por exemplo. Sem exceções.
Remova os membros necessários.
Uma exceção é lançada quando o cliente recebe respostas do serviço com valores em falta.
Modifique os tipos de dados de membros existentes.
Se os tipos são compatíveis, não há exceção, mas podem receber resultados inesperados.
Escolhendo uma estratégia de versão.
A tolerância à versão é uma coisa boa, uma vez que oferece aos desenvolvedores uma maneira flexível de lidar com a mudança. Uma vez que o DataContractSerializer é tolerante a versões, em teoria, você pode abster-se de usar versões oficiais de versões e pontos finais que expõem esses contratos até que seja introduzida uma mudança de interrupção, como remover operações de um contrato de serviço ou adicionar ou remover membros necessários de um contrato de dados.
Existem também possíveis efeitos colaterais da tolerância à versão:
If you add new operations to a service contract only clients that reference the latest WSDL will know about those operations and you will not be able to track which of your existing clients have updated their WSDL unless you expose a new endpoint when changes are made. Se você adicionar membros de dados não obrigatórios a um contrato de dados, talvez seja necessário que escreva um código extra para inicializar valores faltantes para algo significativo - ao invés de usar o valor padrão. Se você remover membros de dados não exigidos de um contrato de dados, você pode ter problemas de ida e volta onde os dados passados ​​para os serviços ou retornados aos clientes são perdidos. Pode ser difícil rastrear problemas se você não acompanhar diferentes versões de contratos, como mudanças na produção.
É importante escolher uma estratégia de controle de versão apropriada que satisfaça as necessidades, às vezes, de agilidade e produtividade versus controle de mudanças. Aqui estão algumas estratégias de controle de versão a serem consideradas:
Version ágil: confie na compatibilidade com versões anteriores o maior tempo possível e evite o controle formal e o controle de versão final, até que a compatibilidade seja quebrada. Esta abordagem é útil em ambientes ágeis que requerem atualizações freqüentes do código de produção. Versões restritas: Execute o controle formal e o controle de versão final para qualquer alteração de um contrato de serviço, contrato de dados, contrato de mensagem ou outras alterações relacionadas ao contrato ou ao ponto final. Esta abordagem é melhor em ambientes que têm atualizações de produção menos freqüentes ou que exigem rastreamento detalhado de todas e quaisquer alterações. Versões semi-estritas: Execute o controle formal e a versão final quando os contratos ou os pontos finais são modificados de forma que sua política exija monitorar a alteração. Por exemplo, sua política pode ser permitir que novas operações sejam adicionadas a um contrato de serviço, mas se forem feitas alterações nas operações existentes ou se qualquer contrato de dados mudar de forma semântica, ele requer o controle de versão. Essa abordagem está em algum lugar entre versões ágeis e estritas.
A abordagem ágil do controle de versão - mostrada na Figura 3 - significa fazer alterações nos contratos de dados e contratos de serviços existentes, sem modificá-los ou fornecer novos pontos finais. O controle de versão estrito significa fornecer novos contratos de dados, contratos de serviço e pontos finais como mostrado na Figura 4.
Figura 3: versão ágil através do mesmo contrato de serviço e ponto final.
Figura 4: Versões restritas através de um novo contrato de serviço e um ponto final exclusivo.
É melhor decidir sobre uma política de versão antes de liberar a primeira versão para a produção.
Contratos de serviço de versão.
Para formatar formalmente um contrato de serviço, você deve fazer o seguinte:
Faça uma cópia do contrato original com um novo nome do tipo de interface, o mesmo nome do contrato e um novo espaço para nome. Faça as modificações necessárias à definição do contrato. Implementar o novo contrato de serviço no mesmo tipo de serviço, se possível. Você pode usar a implementação de contrato explícita para canalizar solicitações para as implementações do método diferente, se necessário. Adicione um novo ponto final para o novo contrato de serviço ao serviço & lt; service & gt; configuração. Como alternativa, você pode usar uma classe base comum que implementa as operações principais do serviço e fornece substituições no tipo derivado de cada versão. Esta pode ser uma abordagem melhor se houver mudanças significativas na implementação do serviço, ou se os comportamentos de segurança do serviço serão diferentes do serviço original. Isso exigirá um serviço separado & lt; & gt; entrada no arquivo de configuração.
A Figura 5 mostra um exemplo de versão restrita do contrato de serviço com uma implementação de serviço compartilhado. Observe que a propriedade Nome do ServiceContractAttribute é a mesma para ambas as versões do contrato, enquanto o nome do tipo de interface muda de IServiceA para IServiceA2. Observe também que dois pontos de extremidade de serviço estão configurados - um para cada contrato.
Figura 5: Versão 1 e 2 do ServiceAContract com configuração de ponto final relacionado.
interface pública IServiceA.
interface pública IServiceA2.
& lt; endpoint address = "ServiceA" binding = "wsHttpBinding"
& lt; endpoint address = "ServiceA2" binding = "wsHttpBinding"
No download do código que acompanha para este documento, os seguintes diretórios contêm exemplos que ilustram o controle de versão do contrato de serviço: WCFEssentials \ ContractVersioning \ ServiceContractVersioningAgile, WCFEssentials \ ContractVersioning \ ServiceContractVersioningStrict.
Contratos de dados de versão.
Para a versão formal, os contratos de dados são um pouco mais complicados, uma vez que cada contrato de dados provavelmente está vinculado a entidades comerciais que são usadas pelo nível de serviço, a camada de negócios e a camada de acesso a dados no aplicativo. Eu recomendo a seguinte abordagem:
Faça uma cópia do contrato e tipo de dados original, mas renomeie o tipo para V1, pois isso não será mais usado ativamente em cada camada de aplicativo. Modifique a implementação da entidade comercial conforme necessário para trabalhar com o aplicativo e atualize seu contrato de dados fornecendo um novo namespace. Faça uma cópia do contrato de serviço original e implementação e atualize-o para usar o nome do tipo V1. Observe que isso não alterará a implementação do serviço, pois o nome do tipo V1 deve ter o contrato de dados original com um nome e espaço de nome explícitos. Versão de todos os contratos de serviços que dependem deste novo contrato de dados seguindo as instruções na seção anterior. Isso inclui a exposição de novos pontos finais. Modifique a implementação do serviço original para encaminhar chamadas para uma instância do serviço V2 depois de mapear a entidade comercial V1 para a entidade comercial V2.
A Figura 6 ilustra essa abordagem.
Figura 6: Contratos de dados de versão.
Os contratos de dados do lado do cliente também devem implementar IExtensibleDataObject para que os clientes V1 preservem dados desconhecidos de um serviço V2 - assumindo que o controle de versão não-estrito é usado. Embora você possa implementar IExtensibleDataObject no serviço também, é menos provável que um serviço precise preservar dados desconhecidos, pois é o sistema de registro para o aplicativo. Suprimir o comportamento do IExtensibleDataObject pode proteger o serviço de potenciais ataques DoS ao lado do tamanho da mensagem e das cotas do leitor definidas na ligação. Se você estiver compartilhando metadados como definições de contrato de dados entre clientes e serviços - você pode implementar IExtensibleDataObject nos tipos de contrato de dados e desativar o suporte para essa extensibilidade apenas no serviço. Isso é melhor feito no código para que ele não possa ser alterado inadvertidamente na produção - definindo a propriedade IgnoreExtensionDataObject do ServiceBehaviorAttribute como true, como mostrado aqui:
Classe pública ArticlesManagerService: IArticlesManager.
Isso também pode ser configurado de forma declarativa nos comportamentos & lt; & gt; seção como segue:
No download do código que acompanha para este documento, os seguintes diretórios contêm exemplos que ilustram versões de contrato de dados e IExtensibleDataObject: WCFEssentials \ ContractVersioning \ DataContractVersioning, WCFEssentials \ ContractVersioning \ IExtensibleDataObject.