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 e 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.
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.
Serviço de web de estratégia de versão
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.
Serviço de web de estratégia de versão
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. For example, version 5.2 of a program should be fully backwards compatible with versions 5.0 and 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.
Versioning Strategies For RESTful Services Like.
Estimated reading time: 3 minutes Added to.
reading list Add to.
reading list View my.
If the behaviour persists please contact us.
NOTE: QCon London - the 12th international software development conference - Mar 5-9, 2018. 100+ expert practitioner speakers, 1300+ attendees, 18 tracks to cover topics driving the evolution of software development today. Get more details or register now!
In his article, Stu Charlton summarizes the various options available for versioning RESTful services which he prefaces by saying “ These can be tricky concepts to describe, and I don't really want to write a small book on this topic ”. He categorizes the versioning problem into two types; Data Versioning, which aims to version the resource itself so tracking changes to state of any given resource becomes possible; and Language Versioning which refers to the protocol itself; in other words the representation.
URI versioning […] is a design choice when resources are immutable across time and we create new resources for state changes (similar to how we manage time-series data in a database).
Language extension or versioning , on the other hand, the state is unchanged, but the way that data is represented has changed.
Stu defers to W3C TAG's draft document by David Orchard on versioning compatibility strategies which elucidates the intricacies of backwards, forwards and incompatible changes. & ldquo; Language extension requires thought” he says, and emphasizes that.
Rule #1: Prefer to extend a language in a forwards and/or backwards compatible manner. Version indicators are a last resort, to denote incompatible changes.
He summarizes the document in tabular form as follows.
Lookup version notifications.
Replacement or Side-by-side Version notification via out-of-band channel or links.
Must accept unknowns Must preserve unknowns if persisting state Version identifier substitution model.
Media type specification clearly defines consumer forward compatibility expectations (and/or uses a machine-readable schema to denote forward-compatibility extension areas)
Check for version identifier.
Side-by-side or Breaking Replacement.
He goes on to define some of the terms used in the table such as version notifications , replacement , side-by-side , version identifiers and how producers and consumers deal with unknown elements in the “ language ” in different compatibility scenarios. He examines various strategies for providing version identifiers and discusses his preference on the priority with which that these strategies be applied.
Version identifier inside the media type content.
This has many examples in the wild, such as HTML DOCTYPE, some uses of XMLNS, a version identifier inside your PDF document. […] It's the way that most web media types have long worked, with varying degrees of success, but note that those formats were long designed with forward compatibility in mind.
Version identifier in the MIME type.
[…] The benefit here is that this enables side-by-side versioning without impacting the URI-space. [….but…] this reeks of avoiding hypermedia and trying to push things to the other layers of the Web Architecture (HTTP and/or URIs). por exemplo. application/vnd. mytype;version=2.
Version identifier in the URI.
It's clear we mint URIs when the semantics of the resource itself changes. So, if they change with the language, then mint new URIs […] e. g. example/data/v1/po/123.
The other problem is bookmarks, which in a data system are actually known as "foreign keys". Anyone with a relational data background knows that their primary keys really shouldn't change, as it's expensive to propagate that change to foreign keys.
He recommends reading Chapter 13 of the book RESTful Web Services Cookbook by Subbu Allamaraju to learn more on the subject and concludes his article with the following summary.
Prefer extensible, forwards & backwards compatible languages and the replacement approach to compatibility. Note the W3C TAG's position on version identifiers Be judicious when you use version identifiers in URIs, as cool URIs don't change For side-by-side deployments, always include a section in your media, or link relation(s), to point to new/old versions, and update references lazily as the consumer refreshes its cached value. Use permanent redirects to retire URIs bound to old language versions. Version URIs if the semantics of the resource changed, but be courteous to consumers by ensuring links are available to denote the old vs. new.
Stu's article tries to brings together the elements that make up the solution space for the versioning RESTful services, however these strategies continue to be fraught with debate on what the right options are.
Related Vendor Content.
Related Sponsor.
Modern Java EE Design Patterns - an O'Reilly book. Baixe Agora.
This content is in the topic.
Related Topics:
Related Editorial.
Nos diga o que você acha.
3 Community comments.
Hello stranger!
You need to Register an InfoQ account or login to post comments. But there's so much more behind being registered.
Get the most out of the InfoQ experience.
Clarification request by Andrew Marshall - Mar 11, 2018 11:45.
InfoQ Weekly Newsletter.
Join a community of over 250 K senior developers by signing up for our newsletter.
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. For example, version 5.2 of a program should be fully backwards compatible with versions 5.0 and 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.
Versioning Strategies For RESTful Services Like.
Estimated reading time: 3 minutes Added to.
reading list Add to.
reading list View my.
If the behaviour persists please contact us.
NOTE: QCon London - the 12th international software development conference - Mar 5-9, 2018. 100+ expert practitioner speakers, 1300+ attendees, 18 tracks to cover topics driving the evolution of software development today. Get more details or register now!
In his article, Stu Charlton summarizes the various options available for versioning RESTful services which he prefaces by saying “ These can be tricky concepts to describe, and I don't really want to write a small book on this topic ”. He categorizes the versioning problem into two types; Data Versioning, which aims to version the resource itself so tracking changes to state of any given resource becomes possible; and Language Versioning which refers to the protocol itself; in other words the representation.
URI versioning […] is a design choice when resources are immutable across time and we create new resources for state changes (similar to how we manage time-series data in a database).
Language extension or versioning , on the other hand, the state is unchanged, but the way that data is represented has changed.
Stu defers to W3C TAG's draft document by David Orchard on versioning compatibility strategies which elucidates the intricacies of backwards, forwards and incompatible changes. & ldquo; Language extension requires thought” he says, and emphasizes that.
Rule #1: Prefer to extend a language in a forwards and/or backwards compatible manner. Version indicators are a last resort, to denote incompatible changes.
He summarizes the document in tabular form as follows.
Lookup version notifications.
Replacement or Side-by-side Version notification via out-of-band channel or links.
Must accept unknowns Must preserve unknowns if persisting state Version identifier substitution model.
Media type specification clearly defines consumer forward compatibility expectations (and/or uses a machine-readable schema to denote forward-compatibility extension areas)
Check for version identifier.
Side-by-side or Breaking Replacement.
He goes on to define some of the terms used in the table such as version notifications , replacement , side-by-side , version identifiers and how producers and consumers deal with unknown elements in the “ language ” in different compatibility scenarios. He examines various strategies for providing version identifiers and discusses his preference on the priority with which that these strategies be applied.
Version identifier inside the media type content.
This has many examples in the wild, such as HTML DOCTYPE, some uses of XMLNS, a version identifier inside your PDF document. […] It's the way that most web media types have long worked, with varying degrees of success, but note that those formats were long designed with forward compatibility in mind.
Version identifier in the MIME type.
[…] The benefit here is that this enables side-by-side versioning without impacting the URI-space. [….but…] this reeks of avoiding hypermedia and trying to push things to the other layers of the Web Architecture (HTTP and/or URIs). por exemplo. application/vnd. mytype;version=2.
Version identifier in the URI.
It's clear we mint URIs when the semantics of the resource itself changes. So, if they change with the language, then mint new URIs […] e. g. example/data/v1/po/123.
The other problem is bookmarks, which in a data system are actually known as "foreign keys". Anyone with a relational data background knows that their primary keys really shouldn't change, as it's expensive to propagate that change to foreign keys.
He recommends reading Chapter 13 of the book RESTful Web Services Cookbook by Subbu Allamaraju to learn more on the subject and concludes his article with the following summary.
Prefer extensible, forwards & backwards compatible languages and the replacement approach to compatibility. Note the W3C TAG's position on version identifiers Be judicious when you use version identifiers in URIs, as cool URIs don't change For side-by-side deployments, always include a section in your media, or link relation(s), to point to new/old versions, and update references lazily as the consumer refreshes its cached value. Use permanent redirects to retire URIs bound to old language versions. Version URIs if the semantics of the resource changed, but be courteous to consumers by ensuring links are available to denote the old vs. new.
Stu's article tries to brings together the elements that make up the solution space for the versioning RESTful services, however these strategies continue to be fraught with debate on what the right options are.
Related Vendor Content.
Related Sponsor.
Modern Java EE Design Patterns - an O'Reilly book. Baixe Agora.
This content is in the topic.
Related Topics:
Related Editorial.
Nos diga o que você acha.
3 Community comments.
Hello stranger!
You need to Register an InfoQ account or login to post comments. But there's so much more behind being registered.
Get the most out of the InfoQ experience.
Clarification request by Andrew Marshall - Mar 11, 2018 11:45.
InfoQ Weekly Newsletter.
Join a community of over 250 K senior developers by signing up for our newsletter.
No comments:
Post a Comment