Estratégia de controle de serviço do soa

Versão de 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 tem como objetivo destacar os prós e contras de cada abordagem e propõe as melhores práticas adequadas aos 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.
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. Várias versões ativas existem para esses dois 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 a uma baixa capacidade de manutenção do código de serviço.
Sempre há um plano de reversão fácil quando um aplicativo enfrenta um problema com a nova versão. Ele pode continuar interagindo 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. Somente uma versão finalizada do Serviço é mantida ativa a qualquer momento, e todos os aplicativos do consumidor apontam para uma e apenas a versão do serviço, que é a versão da linha de base.
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 os principais aprimoramentos de 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 as duas abordagens e seus prós / contras listados, torna-se muito difícil para as empresas escolher uma abordagem em particular. Os prós da abordagem de serviços versionados parece ser ideal 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-e-match dos dois mundos seguindo a abordagem de serviços com versão, mas tendo controle sobre os pesadelos de versionamento limitando as versões ativas máximas a 3 Ao lançar uma nova versão do serviço, apenas os dois últimos continuam 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. Políticas precisam ser estabelecidas e comunicadas às equipes de aplicativos do consumidor para garantir que a migração seja feita no prazo A equipe de serviços não será responsável por impactos no aplicativo do consumidor se o aplicativo continuar a usar uma versão reprovada 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 Soluções de Negócios Torry Harris | Termos e Condições | Mapa do site.

Estratégia de controle de serviço do Soa
Obter através da App Store Leia esta publicação em nosso aplicativo!
Estratégia de Versão para Interfaces de Serviço JAR.
Estou construindo uma arquitetura orientada a serviços composta (principalmente) de serviços baseados em Java, cada um dos quais é um projeto Maven (em um repositório individual) com dois submódulos: comum e servidor. O módulo comum contém as interfaces do serviço que os clientes podem incluir no seu projeto para fazer chamadas de serviço. O submódulo do servidor contém o código que realmente alimenta o serviço.
Agora estou tentando descobrir uma estratégia de versionamento apropriada para as interfaces, de forma que cada mudança de interface resulte em um novo jar comum, mas as mudanças no servidor (desde que não impactem o contrato das interfaces) recebam mesmo jar comum.
Eu sei que isso é muito simples de fazer manualmente (basta incrementar a versão do servidor e não tocar no comum), mas este projeto será construído e implantado por um servidor de CI, e eu gostaria de elaborar uma estratégia para versão automática destes. A única coisa que eu consegui chegar até agora é ter o servidor CI md5 as interfaces de serviço.
Eu consideraria usar os campos versão-versão e implementação-versão no Manifesto. A versão de especificação incrementaria as alterações na especificação da interface, enquanto a versão de implementação aumentaria em cada construção.
Normalmente, a versão de especificação seria algo como 1.0 e a versão de implementação acrescentaria algo relacionado à construção de algo como 1.0.3432.
Veja como o JST é versionado para um exemplo.
Ao declarar suas dependências, você provavelmente deseja evitar a correspondência exata.

Versão em SOA.
por Boris Lublinsky.
Resumo: A arquitetura orientada a serviços (SOA) está tomando um ponto central na arquitetura corporativa. O SOA permite o desenvolvimento paralelo por várias equipes diferentes, cada uma com sua própria programação de entrega e manutenção. Neste artigo, examinarei as abordagens de controle de serviço, permitindo que as implementações de serviços evoluam sem quebrar os consumidores existentes, levando a implementações de SOA mais acopladas.
A idéia básica do controle de versão do serviço é bastante simples, mas sua implementação requer uma governança rígida. Vou discutir unidades de versionamento; mudanças de serviço, constituindo uma nova versão; Considerações sobre o ciclo de vida da versão do serviço; e as abordagens de implantação / acesso à versão. O controle de serviço baseado no método proposto aqui permite minimizar o impacto do controle de versão e reduzir a quantidade de código implantado. A mensagem semântica para definições de interface de serviço torna a implementação do serviço mais resiliente para mudar. (12 páginas impressas)
Se houver uma constante na implementação de TI, isso é uma mudança. As condições de negócios mudam, consequentemente, exigindo mudanças nas implementações de TI. Novas técnicas e padrões permitem uma melhor implementação de qualidades de serviço, como balanceamento de carga e failover, segurança e assim por diante. A tecnologia da informação em si muda continuamente com a introdução de novos sistemas operacionais, linguagens de programação e servidores de aplicativos, por exemplo, que simplificam a criação e manutenção de novas soluções. Na verdade, uma força motriz na implementação de uma solução de TI é sua capacidade de lidar com essas mudanças inevitáveis.
Na era das aplicações monolíticas, as mudanças eram tratadas numa base aplicativo por aplicativo. A implementação da mudança, seja para um novo negócio ou infraestrutura - por exemplo, a introdução de uma política ou requisito de segurança ou a migração de um aplicativo para uma nova plataforma de software - foi feita para um aplicativo como um todo, consumindo muito tempo e dinheiro completar. Por outro lado, como cada aplicativo foi desenvolvido por uma única equipe e independente, essa abordagem permitiu que as alterações fossem contidas. À medida que uma nova versão de um aplicativo foi introduzida, a versão anterior saiu de uso e poderia ser descartada.
Uma das principais vantagens de um estilo arquitetônico orientado a serviços é sua capacidade de lidar eficientemente com as mudanças. A SOA baseia-se na decomposição de ativos de TI da empresa e na separação de artefatos (serviços) de TI "estáveis" de artefatos "variáveis" (processos de negócios), orquestrando serviços em soluções de TI (processos). Como resultado, as mudanças nos requisitos de negócios podem ser satisfeitas por mudanças nos processos existentes ou na criação de novos processos empresariais baseados nos serviços existentes. Esta abordagem permite suporte muito melhor (mais rápido e mais barato) para mudanças necessárias através da (re) montagem de uma solução baseada nos serviços empresariais reutilizáveis. Os serviços empresariais tornam-se recursos, compartilháveis ​​por múltiplas soluções empresariais, possibilitando o desenvolvimento autônomo e massivamente paralelo de serviços por múltiplas equipes diferentes, cada uma com seu próprio cronograma de entrega e manutenção.
Como cada serviço, neste caso, é usado simultaneamente em várias soluções corporativas, uma mudança em um serviço de negócios pode ter um impacto significativo em muitas implementações existentes e, conseqüentemente, requer mudanças em cada uma delas. Isso não é apenas extremamente caro (requer uma enorme coordenação entre as equipes de desenvolvimento e os testes, garantindo que nenhum dos múltiplos consumidores de serviços seja afetado), mas também contraria um dos princípios fundamentais da SOA: os serviços são autônomos. A autonomia é o conceito fundamental por trás da orientação do serviço. Os serviços devem ser implantados e modificados / mantidos independentemente uns dos outros e dos sistemas que os utilizam.
O problema de lidar com componentes compartilhados e potencialmente em mudança não é novo. Por exemplo, o sistema operacional Windows e os aplicativos baseados no Windows dependem dos componentes COM / ActiveX compartilháveis. No caso COM, os componentes são considerados imutáveis ​​e qualquer alteração funcional requer a introdução de um novo componente com um novo identificador globalmente exclusivo (GUID). Essa abordagem permite a coexistência simultânea de múltiplos componentes / versões.
Neste artigo, discutirei as abordagens de versão de serviço, permitindo que as implementações de serviço evoluíssem sem prejudicar os consumidores existentes.
Apresentando a versão do serviço.
Uma das abordagens mais populares para lidar com mudanças é o controle de versão. O controle de versão assume a existência simultânea de implementações múltiplas (diferentes) da mesma coisa, com cada implementação distinguível e endereçável individualmente. No caso do SOA, o controle de versão de serviço equivale à coexistência de várias versões do mesmo serviço, o que permite que cada consumidor use a versão para a qual foi projetado e testado (consulte a Figura 1). Neste caso, uma nova versão de um serviço é criada com base nos requisitos de um ou mais consumidores, que podem começar a usar esta nova versão imediatamente. Os outros consumidores deste serviço não precisam mudar para usar a versão mais recente imediatamente, mas podem continuar a usar as versões do serviço para o qual elas foram projetadas e testadas. Eles podem mudar para a versão mais recente do serviço, com base em seu próprio calendário de desenvolvimento e testes. Várias versões coexistentes do mesmo serviço no sistema permitem ciclos de vida independentes de serviços e seus consumidores e minimizam o impacto geral da introdução de mudanças. Embora a necessidade de tal mecanismo de versionamento possa ser óbvia para qualquer um que tenha lidado com serviços, este tópico ainda não penetrou no mainstream das publicações e implementações de SOA. A ideia básica de versionamento de serviços é bastante simples e direta, mas sua implementação requer a definição do seguinte:
Unidades de versão Mudanças de serviço, constituindo uma nova versão Considerações sobre o ciclo de vida da versão do serviço Abordagens de implantação / acesso à versão.
Figura 1. Coexistência de várias versões de serviço.
Unidades de versão.
Existem duas opções principais para definir unidades de versão, cada uma com seus próprios benefícios e passivos.
Com base nas atuais práticas de Serviços da Web (a tecnologia de implementação de SOA mais popular hoje), muitos praticantes propõem o controle de versão do serviço (incluindo todas as operações) como um todo. Embora essa abordagem esteja bem alinhada com as práticas atuais de desenvolvimento orientado a objeto (OO) e baseado em componente (CBD), ela nem sempre parece ser apropriada no caso de serviços de granulação grossa. (Para uma comparação mais aprofundada de SOA e OO, consulte "Definindo SOA como estilo arquitetônico", em Recursos.)
Quando as pessoas falam sobre o controle de versão em suas conversas diárias, elas geralmente falam sobre mudanças e versões dos métodos, e não um serviço em si. Por exemplo, considere um serviço de conta que implementa três operações: retirada, depósito e transferência. Normalmente, a conversação gira em torno de mudanças das operações individuais (em outras palavras, retirada), não o próprio serviço de conta.
Portanto, outra opção é definir operações de serviço individuais (métodos) como uma unidade de controle de versão. A operação do serviço de versão independentemente tem as seguintes vantagens:
Permite serviços imutáveis. O serviço pode fornecer métodos adicionais (versões de métodos), alguns dos quais podem ser obsoletos ao longo do tempo, mas o próprio serviço, seu nome e classificação, nunca muda. Esse esquema se assemelha a abordagens de versão em linguagens de programação populares, como Java ou C #, em que os métodos nas classes são adicionados e obsoletos com bastante frequência, enquanto as classes existentes amplamente usadas raramente são alteradas. Isso minimiza o impacto das mudanças de serviço para os consumidores. Somente os consumidores que usam um método específico são afetados por uma mudança, em vez de todos os consumidores de serviços. Ele minimiza a quantidade total de código implantado. Somente os métodos com uma nova versão serão redistribuídos no processo de introdução da nova versão. O código implementando métodos que não foram alterados permanece inalterado.
Também possui os seguintes passivos:
Ele exige a implantação de cada método de forma independente com seu próprio endereço de endpoint (es). (Embora essa abordagem de implantação não seja comum hoje em dia, ela apresenta algumas vantagens, como o fornecimento de diferentes contratos de nível de serviço (SLA) para diferentes métodos dentro do mesmo serviço.) Requer um esquema de endereçamento de chamada de serviço diferente, um pouco mais complexo. Em vez de especificar um serviço que precisa invocar, o consumidor do serviço, neste caso, precisa especificar explicitamente o serviço, a operação e a versão da operação que ele requer.
Apesar do requisito de invocação / roteamento de serviço não padrão, a versão de serviço baseada em método fornece maior flexibilidade e alinha melhor a versão do serviço com as práticas de controle de versão predominantes nas linguagens de programação. Ele também minimiza a quantidade de código que precisa ser reimplementado para suportar uma nova versão. Essas características tornam o controle de versão baseado em métodos uma poderosa abordagem de controle de serviço.
Definições de versão.
Definir o que constitui uma nova versão do serviço (método) requer analisar as possíveis mudanças, seu impacto potencial na execução do consumidor e identificar as que irão "quebrá-lo". Qualquer alteração no serviço, seja uma mudança na interface ou implementação que possa impactar a execução do consumidor, deve levar à criação da nova versão do serviço (método). Embora a definição acima não seja muito precisa e aberta para interpretação, ela fornece um bom ponto de partida para a decisão sobre a criação da nova versão.
Examinarei ainda mais os principais componentes da definição de serviço (definições de interface e mensagem) e implementações para determinar situações específicas que podem levar à criação de novas versões.
Mudanças de Serviço-Interface.
Após a adoção do modelo de mensagens semânticas, as assinaturas do método de serviço nunca mudam (todas as alterações são refletidas nas mudanças no modelo semântico). A interface do método de serviço no caso de mensagens semânticas é:
servicemethod (XML in, XML out)
Conseqüentemente, a interface do método de serviço nunca muda e não deve ser considerada na definição de versão. Como cada método é individualmente implantado e abordado em um esquema de controle de versão baseado em métodos, métodos adicionais podem ser introduzidos para o serviço sem afetar os consumidores de serviços existentes. Finalmente, porque todas as alterações da interface estão contidas no modelo de mensagens, a remoção do método (depreciações), neste caso, equivale a eliminar algumas das funcionalidades da empresa e deve acontecer muito raramente. Do ponto de vista do consumidor, esta situação requer modificações (potencialmente significativas), que implicam a implementação interna da funcionalidade requerida ou o uso de um serviço completamente diferente. Nesse caso, o método de serviço é definido como reprovado e mantido, enquanto cada um de seus consumidores poderá parar de usá-lo (consulte Considerações sobre o ciclo de vida da versão de serviço, mais adiante no artigo).
Alterações de mensagens.
Conforme definido anteriormente, no caso de mensagens semânticas, as mudanças na interface de serviço estão contidas nas mudanças de mensagens semânticas. Essas mensagens são definidas usando esquemas que descrevem seu conteúdo. O uso dos esquemas de mensagens para definir possíveis mudanças de interface alinha essa abordagem às técnicas de controle de versão do esquema XML (consulte "Suporte a controle de versão em esquemas XML", na barra lateral), permitindo a representação direta de controle de versão nas mensagens de serviço. Mudanças nos esquemas podem ser amplamente definidas em três categorias principais:
As revisões representam as mudanças de esquema do documento sem significado semântico. Por exemplo, uma alteração no espaço em branco, formatação, documentação não-normativa, comentários e assim por diante. A revisão de uma versão já publicada não deve afetar a funcionalidade das implementações de serviços ou consumidores.
Além disso, o desenvolvimento incremental inicial de um esquema semântico, antes de ser publicado para uso em produção, também pode ser tratado como revisões da mesma versão.
As mudanças menores representam mudanças compatíveis com versões anteriores para o esquema do documento. Exemplos de pequenas alterações no esquema incluem:
Alterando a Opcionalidade de um Elemento Local ou Referência de Elemento de Obrigatório para Opcional Incluindo um Elemento ou Tipo Global Incluindo Elementos Opcionais no Tipo Existente Alterando o tipo de um elemento global ou local para o novo tipo, derivado do original incluindo / restringindo elementos opcionais .
As principais mudanças representam alterações não compatíveis com versões anteriores ao esquema do documento.
Exemplos de mudanças importantes no esquema incluem:
Alterando o tipo de elemento local ou global para o novo tipo, derivado do original, adicionando / restringindo elementos opcionais. Alterando a opcionalidade de um elemento local ou referência de elemento de opcional para necessário Adicionando ou removendo um valor de enumeração Removendo ou renomeando um tipo ou elemento global.
Com base nas definições acima, tanto as revisões quanto as pequenas mudanças no esquema de mensagens fornecem compatibilidade com versões anteriores e não "quebram" o contrato de serviço. Como resultado, eles não afetarão o serviço nem a implementação do consumidor e não exigirão o controle de versão do serviço. Em contraste, as principais mudanças exigem o controle de versão do esquema de mensagens e, conseqüentemente, dos serviços.
Alterações de implementação.
Um equívoco comum é que, porque os serviços são definidos através da interface, e não a implementação, as mudanças na implementação do serviço não afetarão os consumidores de serviços e não exigem o controle de versão.
Na realidade, a adesão à interface não constitui substituibilidade das implementações. A capacidade de replicação não é definida apenas pela interface, mas pelo contrato - que inclui interface, pré e pós-condições e determinados SLAs - dos quais o consumidor de serviço se baseia. Consequentemente, o controle de versão é necessário quando as alterações na implementação do serviço afetam o contrato no qual um determinado consumidor de serviços se baseia. Como diferentes consumidores de serviço podem confiar em diferentes partes do contrato de serviço, todas as mudanças na implementação do serviço devem ser validadas em relação a todos os consumidores de serviço existentes, para garantir que nenhum contrato seja "quebrado".
Aqui estão alguns dos exemplos de como as mudanças na implementação do serviço (método) podem levar a alterações no contrato:
A nova implementação de serviço suporta exatamente a mesma interface (funcionalidade), mas altera o tempo de execução (SLA). Se um consumidor de serviço estiver chamando esse serviço (método) de forma síncrona, essa alteração poderá impactar significativamente a execução do consumidor de serviço. Como resultado, a versão de serviço pode ser necessária. (Curiosamente, mesmo a reimplementação do serviço existente, com alterações em sua implementação, pode levar aos mesmos resultados.) A nova implementação de serviço suporta a mesma interface, mas altera as validações de parâmetros de entrada (pré-condições). Nesse caso, algumas solicitações que foram processadas com êxito agora serão rejeitadas, exigindo a introdução de um novo serviço. A nova implementação do serviço introduz uma nova implementação de segurança (pré-condição), que muitas vezes não é refletida na interface de serviço, mas feita através das configurações. (Consulte o Manual de Serviços da Web para o WebSphere Application Server Versão 6.1, em Recursos.) Neste caso, os consumidores de serviços existentes precisarão enviar credenciais de segurança; A mudança de implementação ea criação da nova versão são necessárias.
Cada um desses cenários requer análise de consumidores de serviços existentes e testes potencialmente extensivos. Como resultado, uma maneira mais simples de decidir se uma nova versão de serviço (método) precisa ser criada quando a implementação do serviço muda é manter uma definição de contrato de serviço (método) e criar uma nova versão quando o contrato muda, independentemente de que os consumidores confiam nas partes do contrato. Em caso de dúvida, geralmente é mais simples criar uma nova versão.
Considerações sobre o Ciclo de Vida da Versão do Serviço.
Uma das principais considerações de versão é definir o período de tempo para o qual uma versão do serviço (método) será preservada. A extensão deste período leva à necessidade de manter uma quantidade excessiva de versões de serviço. Encurtar o período, por outro lado, limita o tempo para os consumidores de serviços implementarem as atualizações necessárias. O ciclo de vida apropriado para as versões de serviço (método) varia significativamente e é definido pela capacidade da organização de lidar com as mudanças.
Implementação de Versão / Abordagens de Acesso.
Existem duas abordagens comuns para a implantação de versões de serviço:
Parâmetro da aliança ou da versão. Uma aliança é um acordo "if-then-else" ("se você fizer isso, então farei isso"). Neste caso, existe um único endereço de ponto final para todas as versões do serviço (método), conforme mostrado na Figura 2.
Figura 2. Implementação do controle de versão usando pacto.
A aliança efetivamente implementa roteamento baseado em contexto, recebendo uma mensagem recebida e encaminhando-a (com base em um parâmetro de versão, incorporado na mensagem de invocação) para a versão de serviço apropriada. O benefício dessa abordagem é que simplifica o atendimento de serviços do ponto de vista do consumidor. O consumidor, nesse caso, usa um único endpoint address para acessar todas as versões de um determinado serviço (método) e codifica o método requerido na mensagem de invocação. Um endereço de ponto final implementa um suporte de roteamento, invocando uma versão necessária.
Embora a abordagem da aliança minimize o impacto da introdução de novas versões nos consumidores de serviços, ela introduz a complexidade da embalagem em conjunto com múltiplas versões de um método de serviço. Isso pode levar a colisões de nome de classe, colisões de nomes de banco de dados e assim por diante. Além disso, esta abordagem exige efetivamente uma estratégia de controle de versão não só para os próprios serviços, mas também para os componentes utilizados para implementações de serviços. Considerando o acoplamento mais estreito entre os componentes, esse problema pode ser ainda mais complexo do que o controle de versão dos serviços.
Maiores melhorias podem ser alcançadas através da substituição do roteador local que despacha entre a implementação das versões do serviço com um corretor externo (mediador). Nesse caso, todas as versões podem ser implantadas de forma independente e é responsabilidade do mediador resolver dinamicamente o endereço do terminal da versão de serviço desejada e enviar todas as mensagens de acordo. No entanto, embora os intermediários (mediações) sejam freqüentemente promovidos pelas publicações ESB como uma cura para a maioria dos problemas de roteamento / transformação, encontrados na arquitetura orientada a serviços, há custos associados a eles. Normalmente, reduz o desempenho. Também deve suportar o SLA mais rigoroso de todos os serviços acessados ​​através dele, o que pode ser um requisito muito forte.
Vários endereços de endpoint. Nesse caso, semelhante à implementação do mediador, cada versão de uma determinada operação é implantada em seu próprio endereço de ponto final. A diferença aqui é que cada endereço de terminal é exposto diretamente a um consumidor de serviço (veja a Figura 3).
Figura 3. Implementação de versões usando endereços de terminal diretamente expostos.
Múltiplos endpoint endereços assumem que um consumidor do serviço pode resolver endpoint endereço (normalmente usando o serviço de registro) para uma versão necessária com base no serviço / método / versão informações. A vantagem deste esquema é uma separação completa da implantação de versões de métodos múltiplos. A desvantagem é um paradigma de endereçamento mais complexo, exigindo suporte de registro de serviço para resolver o endereço do terminal.
A abordagem de endereço de ponto de extremidade múltiplo geralmente fornece melhor escalabilidade (um salto de rede menor) e reduz o acoplamento entre várias versões da mesma operação.
Versão da infra-estrutura de serviços.
Uma variante de versão de serviço é o versionamento da infraestrutura de serviço, que pode envolver o seguinte:
Mudanças de transporte - por exemplo, comutação de transporte de HTTP para Java Message Service (JMS) - por exemplo, atualizando envelopamento proprietário com SOAP (Simple Object Access Protocol) no esquema de endereçamento - por exemplo, introdução do Web Services Addressing para especificação de endereço de resposta.
Nesse caso, é sempre desejável implementar a "compatibilidade reversa", garantindo que a nova infraestrutura possa "entender" e suportar mensagens produzidas pela antiga infraestrutura e produzir mensagens compatíveis com ela. Na realidade, pode ser muito caro, ou mesmo tecnicamente impossível.
A migração de todas as implementações de serviços e consumidores existentes para a nova infraestrutura é normalmente bastante cara e demorada, exigindo suporte a versões que forneçam interoperabilidade entre duas infra-estruturas de serviço diferentes. A solução mais popular para este problema é um adaptador de serviço (veja a Figura 4).
Figura 4. Interoperabilidade entre infra-estruturas de serviços (Clique na imagem para uma imagem maior)
Nesse caso, quando o consumidor de serviço suportado pela infraestrutura de serviço 1 invoca o provedor de serviços suportado pela infraestrutura de serviço 2, a chamada passa pela mediação do adaptador entre as infraestruturas de serviço. Do ponto de vista do consumidor do serviço, o adaptador atua como um provedor de serviços. O adaptador então invoca o provedor de serviços atuando como consumidor de serviço.
Esta implementação pode ser combinada com a topologia de implantação do service-versioning (veja a Figura 4) para fornecer suporte de versão para serviços e consumidores de serviços entre diferentes infra-estruturas.
Suporte de versão em XML Schemas.
A maneira mais simples de denotar versões no XML Schema é o uso de um atributo (opcional) no elemento xs: schema - version. O modelo de conteúdo permite a notação Dewey dos números de versão major. minor.
Como os analisadores XML não são necessários para validar instâncias usando a versão, é possível implementar a representação personalizada da versão, permitindo que o analisador a inclua no processo de validação. O uso dessa técnica geralmente requer a introdução de um atributo de versão como um valor fixo e obrigatório para a identificação de uma versão específica do esquema. No entanto, essa abordagem para o controle de versão do esquema não é muito prática. Existem várias desvantagens:
Uma instância XML será incapaz de usar várias versões de uma representação de esquema porque o controle de versão ocorre na raiz do esquema. As ferramentas de validação de esquema XML não são necessárias para validar instâncias usando o atributo de versão; o atributo é fornecido apenas para fins de documentação e não é aplicável por analisadores XML. Como os analisadores XML não precisam validar o uso do atributo version, é necessário um processamento customizado adicional (além da análise e validação) para assegurar que as versões do esquema esperado estejam sendo referenciadas pela instância. Marshaling / unmarshaling de documentos XML é muito raramente feito usando manipulação direta da árvore DOM. A abordagem predominante para empacotamento é geração das classes, suporte empacotamento "automático", usando ferramentas como WSDL2Java, Castor, EMF, SDO, XSD, XSDObjectGenerator e assim por diante. Nesse caso, as classes são geradas nos pacotes em Java ou namespaces em C #, com base nos espaços de nomes de esquema, e não na versão do esquema.
Outra opção para denotar a versão do esquema é o uso de namespaces XML. Nesta abordagem, um novo XML Namespace é usado para todas as versões principais. This approach is well aligned with generation of marshaling/unmarshaling code by allowing generating code in different packages (namespaces), thus enabling a single service consumer to work with several major releases of schema simultaneously.
Yet another option is to keep XML Namespace values constant and add a special element for grouping custom extensions. This approach wraps extensions to the underlying vocabulary within a special extension element. This technique is favored by several industry-standard schemas. For example, the Open Application Group's Business Object Documents (OAG BODs) include a <userarea> element defining custom information that may not be part of the base vocabulary. This approach maximizes the extensibility of the schema constructs (schemas can be both forward - and backward-compatible) without introduction of new namespaces. There are two disadvantages to this approach:
It introduces significantly higher levels of complexity into the schema. It does not allow implementation of multiple extensions across different portions of the XML instance, because all extensions must be grouped within the extension "wrapper."
The most scalable approach to versioning of schemas is as follows:
Componentization of the overall schema in logical partitions using multiple namespaces, thus containing changes. Defining a new namespace (reflecting the major version information) for every major version of each schema. Denoting every minor version as a schema version in a major version namespace. Because minor versions are backward-compatible, generated marshaling/unmarshaling code also will be backward-compatible.
Conclusão.
Dealing with changes is never simple and the complexity usually grows with the size of implementation. Larger implementations typically have more interdependent moving parts, and consequently, the effects of changes are more pervasive. SOA implementations, especially enterprise-wide implementations, are no exception.
Service-versioning approaches, described in this article, leads to the creation of much more loosely coupled SOA implementations. Introduction of simultaneously deployed multiple service versions allow both service consumers and providers to evolve independently, on their own development and deployment schedules. Independent versioning of service methods minimizes the impact of versioning and reduces amount of deployed code. Finally, usage of semantic messaging for service-interface definitions makes service implementation more resilient to changes.
Agradecimentos.
The Author thanks Jim McKune, Dmitry Tyomkin, Kiran Achen, and Luc Clement for their contributions.
Lublinsky, Boris. "Defining SOA as an Architectural Style." IBM developerWorks, January 2007. Evdemon, John. "Principles of Service Design: Service Patterns and Anti-Patterns." Microsoft Developer Network, August 2005. Brown, Kyle, and Michael Ellis. "Best Practices for Web Services Versioning." IBM developerWorks, January 2004. Lhotka, Rocky. "A SOA Version Covenant." Enterprise Community, April 2005. XFire User Guide, Versioning Best Practices. Lee, Josh. "Architecting Industry Standards for Service Orientation." Microsoft Developer Network, May 2005. Evdemon, John. "Principles of Service Design: Service Versioning." Microsoft Developer Network, August 2005. Wahli, Ueli, Owen Burroughs, Owen Cline, Alec Go, and Larry Tung. Web Services Handbook for WebSphere Application Server Version 6.1. Boca Raton, FL: IBM Corp., International Technical Support Organization, 2006. Hogg, Jason, Don Smith, Fred Chong, Dwayne Taylor, LonnieWall, and Paul Slater. Web Service Security: Scenarios, Patterns, and Implementation Guidance for Web Services Enhancements (WSE) 3.0. Redmond, WA: Microsoft Press, 2005. Keen, Martin, Oscar Adinolfi, Sarah Hemmings, Andrew Humphreys, Hanumanth Kanthi, and Alasdair Nottingham. Patterns: SOA with an Enterprise Service Bus in WebSphere Application Server V6. Research Triangle Park, NC: IBM Corp., International Technical Support Organization, 2005. Lublinsky, Boris. "Supporting Policies in Service-Oriented Architecture." IBM developerWorks, November 2004. Arsanjani, Ali. "Toward a Pattern Language for Service-Oriented Architecture and Integration, Part 1: Build a Service Eco-System." IBM developerWorks, July 2005.
Sobre o autor.
Boris Lublinsky has over 25 years of experience in software engineering and technical architecture. For the past several years, he focused on Enterprise Architecture, SOA, and Process Management. Throughout his career, Dr. Lublinsky has been a frequent technical speaker and author. He has over 40 technical publications in different magazines, including Avtomatika i telemechanica , IEEE Transactions on Automatic Control, Distributed Computing, Nuclear Instruments and Methods, Java Developer's Journal, XML Journal, Web Services Journal, JavaPro Journal, Enterprise Architect Journal , and EAI Journal . Currently, Dr. Lublinsky works for the large Insurance Company, where his responsibilities include developing and maintaining SOA strategy and frameworks. He can be reached at blublinskyhotmail.
This article was published in the Architecture Journal, a print and online publication produced by Microsoft. For more articles from this publication, please visit the Architecture Journal Web site.

Web Service Contract Versioning Fundamentals Part II: Version Identifiers and Versioning Strategies.
Junte-se à comunidade DZone e obtenha a experiência dos membros completos.
There are different ways of versioning service contracts based on policies, priorities, and requirements. This, the second article in a two-part series from the book "Web Service Contract Design & Versioning for SOA", introduces three common versioning strategies: strict, flexible, and loose. The pros and cons of each approach are discussed and further ranked in relation to strictness, governance impact, and complexity. The role of version identifiers is also explored through a series of examples. Read Part I Here.
Sometimes, you will see additional period + decimal pairs that lead to more detailed version numbers like this:
The typical meaning associated with these numbers is the measure or significance of the change. Incrementing the first decimal generally indicates a major version change (or upgrade) in the software, whereas decimals after the first period usually represent various levels of minor version changes.
A minor version is expected to be backwards compatible with other minor versions associated with a major version. 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.
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.
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.
Note : All three strategies will be referenced in upcoming chapters as we explore how versioning can be accomplished with the WSDL, XML Schema, and WS-Policy languages.
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.
This article was originally published in The SOA Magazine (soamag), a publication officially associated with "The Prentice Hall Service-Oriented Computing Series from Thomas Erl" (soabooks). Copyright ©SOA Systems Inc. (soasystems)
The Integration Zone is proudly sponsored by CA Technologies. Learn from expert microservices and API presentations at the Modernizing Application Architectures Virtual Summit Series.
Como esse artigo? Leia mais do DZone.
Free DZone Refcard.
RESTful API Lifecycle Management.
Published at DZone with permission of Nitin Bharti. See the original article here.
As opiniões expressas pelos contribuidores da DZone são próprias.

Web Services Versioning.
by Gabriel Bechara.
Introdução.
Web services are bound to change and evolve over time. The loose coupling principles of service-oriented architecture (SOA) imply that service providers can release a new version of a shared service without waiting for consumers to adapt, and that service consumers should test and certify on a new shared service version before switching. Consequently, you might need to have multiple versions of a shared service running concurrently and simultaneously accessible by different service consumers. Some service consumers might need to continue using an old version of a service until migration of the consumer code occurs. Therefore, Web services versioning is an important subject that should be considered carefully in all enterprise SOA approaches.
Current standards for Web services have no explicit support for versioning, requiring architects and developers to solve the problem through the application of patterns. This article will:
Identify the types of changes that can occur in services.
By the end of this article, you should have a good understanding of the main aspects that should be dealt with when building your own enterprise Web services versioning strategy.
Types of Changes.
A change in a Web services implementation may affect its consumers depending on a number of factors:
A change in the operation parameters of a Web service. This might involve the addition of new parameters (this will affect the current consumers), or a change in existing parameters, such as a change in an XML document that might be used as a message parameter in a Web service. The changes in an XML document may involve the addition of optional elements or attributes (this might affect the current consumers) or of mandatory elements (this will affect the current consumers).
Therefore, a typology of change in Web services can be created in relation to the impact on the current consumers of those services. One approach is to qualify a change that will not affect the current consumers as a minor release and a change that will affect the current consumers as a major release.
Minor Release.
A minor release can be one of two types. The first is a correction of a bug or a performance enhancement. This type will not affect the Web Services Description Language (WSDL) of the Web service. The second type consists of adding new methods to a Web service, wherein the WSDL is changed with no impact on service consumers. A distinction can be made between these two types when labeling those versions. For example, for the first type you can change the second decimal place of the version number (1.0X), while for the second type you change the first decimal place of the version number (1.Y0).
Major Release.
A major release involves a change that will break backwards compatibility. In this case the consumers must be modified. A release that only affects the functionalities of a Web service, without affecting the WSDL, is also considered a major release. This is because the current consumers cannot invoke the new version without considering the Web service's modified functionalities. Now that we have identified the various types of changes and their impact on current consumers, let's take a look at different patterns for Web services versioning.
The Patterns.
Consumer Binding Pattern.
When a new version of a Web service is released -- whether a major or minor release -- the consumers are notified about the change, and are responsible for changing the code to access the new version. The new WSDL is published -- in a UDDI registry, for example -- and a notification is sent to the consumers so that they can find the new service and establish binding with the new service provider. One practice for using a UDDI registry involves associating a given version of a portType to a unique tModel. One WSDL is associated with one tModel. This tModel should contain a reference to the version number for a major release because two major versions will imply two different WSDLs. The tModel may contain a reference to the minor version if two minor versions need to be accessed at one time. A consumer of that portType/version could do a green-pages UDDI search for services that advertise compliance by associating themselves with the tModel of the corresponding version.
This method may impose changes in the consumers' code, at least in the search performed on the registry for accessing a version (major or minor) of a service, even for minor releases. And what if you need to have two minor versions running at the same time? For instance, you might want to deploy a new minor release on a test site to be used by a limited number of consumers, while maintaining the old version for the rest. The consumers of the service deployed on the test site will need to change the end point of the service even if the WSDL is not modified (because it's a minor version). In this specific case, it may be useful to have a layer of indirection between the consumers and the providers, to drive the migration of different consumers in a graceful way.
Figure 1. Consumer Binding Pattern.
Note: The consumer binding pattern does not imply the use of UDDI; it refers to the fact that the binding decision is made on the consumer side. We'll discuss interesting uses of this pattern in a moment.
Layer of Indirection Pattern.
When a new minor version of a Web service is released, the consumer can transparently migrate to the new release. This ability is provided by the layer of indirection through a routing mechanism that ensures content-based routing or user-based routing (based on the IP of the requester, for instance, or on the principal of the requester when propagating security roles) to call the different versions of a Web service.
The use of a layer of indirection allows two minor releases to coexist without changing the consumers' code, and helps to ensure a graceful migration to a new release.
Figure 2. Layer of Indirection Pattern.
But in the case of a major release, the consumers will need to change their code. And what if, for some organizational reason, we need to migrate to a new major release without changing the current consumers' code, calling the new service with the old client? This might happen if, for example, some regulatory reason implies a change accessible only through the use of the new major release of a service, provided by a business partner external to your organization. This leads to using an adapter to enable the use of a new major release for current consumers until all the consumers' code is modified.
Adapter Pattern.
The adapter pattern consists of adapting the client request and response to be able to consume a new major release of a service. Using this pattern offers a smoother migration, in case the use of a new major version of a service is mandatory for some business, regulatory, or organizational reason.
Figure 3. Adapter Pattern.
Solutions for Applying the Patterns.
The different patterns can be applied in different ways. This can be done in the consumers' code, but that is rarely the case because it can cause coding delays and increase the complexity of the code handling versioning. An alternative is to use a mediation layer for decoupling the consumer from the provider and to apply those patterns in the mediation layer. Using Oracle Service Bus as a mediation layer will provide the functionalities of the Layer of Indirection pattern associated with the Adapter Pattern, relieving the consumers' code from those concerns. Veja a Figura 4.
Figure 4. Applying the patterns using Oracle Service Bus.
Using this approach based on Oracle Service Bus offers these advantages:
A minor release change can be addressed without modifying the consumers, and test sites can be addressed through content-based or user-based routing.
Mediation in Oracle Service Bus is mainly configured using proxies to access business services. In between there are pipelines, consisting of stages, actions, branches, and routing nodes. The message is adapted within those pipelines, routing the requests in the routing nodes. The configuration of the proxies and the business services can be organized with a reference to the version numbers. The proxies in Oracle Service Bus may include in their path a reference to the major release, and the business service may include the major and minor release. For example, for a major v1.XX, we will have one proxy, one or more business services (one per minor release), and one WSDL:
. and for major V2.XX:
Note: Because the proxies and the WSDL are the same for minor releases, the path containing those does not need to include a reference to the minor version.
We have addressed the access to different services through Oracle Service Bus. But there are other issues to deal with, such as the deployment of two different versions of a service provider coming from the same development environment. Those services might have the same Java Platform, Enterprise Edition (Java EE) Web module context path, because they may have been developed using the same development tools. Therefore, unless you provide a build script that adds version reference in the context of the Java EE Web module, you might want to consider deploying different versions of the same service on different targets. (A target is a cluster or a managed server.) See Figure 5.
Figure 5. Deploying service providers on different Targets.
Note: Some frameworks and development tools, including Oracle JDeveloper, automate the versioning of some service providers. That capability has been extended in Oracle JDeveloper 11 Technical Preview 4 to deal with the versioning of Service Component Architecture (SCA) composites (multiple services in one composite).
Presentation services and orchestration services (business process services) will benefit from the transparency of this approach when consuming other services belonging to the business services layer or the data access services layer. But what about consumers of presentation services? A composite portal can consume presentation services using Web Services for Remote Portlets (WSRP) to consume remote portlets. The Layer of Indirection pattern, coupled with the Adapter Pattern using Oracle Service Bus, can also be applied in this case, but we may use a more adapted approach based on the portal capabilities. Portals usually come with administration tools for configuring access to portlets (reusable presentation services). Using users' role-based rules and entitlements to display some part of the composite portal, depending on the user properties, may be more appropriate for the presentation services. This is more of a concern with a composite portal engine than with Oracle Service Bus.
Therefore, presentation services layer versioning is better accommodated using the Consumer Binding pattern. In this context, the pattern is not applied by using a UDDI registry to choose the service. In this case, applying this pattern relies on the entitlements or personalization engine provided by the composite portal. An important aspect of this particular use of this pattern is that the choice of the version is made through configuration, in the portal administration tool. Thus, it will not imply any code modification or maintenance.
The figure below shows how a composite portal can consume portlets through WSRP in different versions of the same application. The selection of the portlet version to be exposed is made in the composite portal engine.
Figure 6. The Consumer Binding Pattern applied to presentation services.
Doing this allows two versions of the same application to run simultaneously, exposing new functionalities only to selected end users based on user profile attributes.
Conclusão.
Web services versioning can be handled in a variety of ways, depending on business constraints and the layer to which the service belongs. In this article we've covered practices that can be applied to a variety of versioning tasks:
Accessing and deploying multiple versions of a service provider at the same time.
Some additional factors should be taken into consideration, including XML Schemas versioning and managing dependencies between services and the XML Schemas used by those services. At the organizational level, this will become very difficult to handle without the proper tools for managing dependencies and for driving the changes properly and holistically.
Gabriel Bechara has worked with Oracle-BEA presales and consulting services since 2003. A 15-year veteran of the software industry, Gabriel has served as an architect and advisor on large projects, providing practical experience and feedback on concepts that can provide a foundation for building new information systems. His interests include methodologies for defining software and enterprise architectures, with a strong focus on business integration and SOA.

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. ai - Applied AI conference for Developers Apr 9 - 11, 2018. Connect with AI and Machine Learning practitioners who are driving the change in software. 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.
This content is in the topic.
Tópicos relacionados:
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, 2010 11:45.
InfoQ Weekly Newsletter.
Join a community of over 250 K senior developers by signing up for our newsletter.