Estratégia de controle de serviço do Soa
Thomas Erl é um autor de TI e fundador da Arcitura e comércio; Education Inc. Thomas é o autor de tecnologia do serviço mais vendido no mundo por mais de sete anos e é o editor de séries da Prentice Hall Service Technology Series de Thomas Erl (servicetechbooks). Com mais de 300.000 cópias impressas em todo o mundo, seus livros se tornaram best-sellers internacionais e foram formalmente aprovados por membros seniores das principais organizações de TI, como IBM, Microsoft, Oracle, Intel, Accenture, IEEE, HL7, MITRE, SAP, CISCO, HP, e muitos outros.
Vários de seus livros, incluindo Cloud Computing Design Patterns, Cloud Computing: Concepts, Technology & amp; Arquitetura, SOA Design Patterns, SOA Principles of Service Design e SOA Governance, foram criados em colaboração com a comunidade de TI e contribuíram para a definição de mecanismos de tecnologia da computação em nuvem, o modelo arquitetônico orientado para o serviço e a orientação do serviço como um paradigma distinto . Seu título mais recente, Arquitetura Orientada a Serviços: Análise & amp; Design para Serviços e Microservices, posiciona formalmente e introduz novos padrões para o modelo arquitetônico da Microservice como parte da SOA.
Como CEO da Arcitura & Trade; Education Inc. e em cooperação com SOA School, Cloud School e Big Data Science School, Thomas liderou o desenvolvimento de currículos para o SOA Certified Professional reconhecido internacionalmente (SOACP), Cloud Certified Professional (CCP) e Big Data Science Certified Professional (BDSCP ) programas de acreditação, que estabeleceram uma série de certificações de indústria formal, neutras do fornecedor, obtidas por milhares de profissionais de TI em todo o mundo.
Thomas é o membro fundador do SOA Manifesto Working Group e autor do Annotated SOA Manifesto (soa-manifesto). Durante 10 anos, ele foi o editor da The Service Technology Magazine, e ele supervisiona as iniciativas SOAPatterns, CloudPatterns e BigDataPatterns, dedicadas ao desenvolvimento contínuo de catálogos de padrões principais para arquitetura orientada a serviços, computação em nuvem e Big Data .
Thomas visitou mais de 20 países como palestrante e instrutor e participa regularmente de conferências internacionais. Mais de 100 artigos e entrevistas de Thomas foram publicados em numerosas publicações, incluindo The Wall Street Journal e CIO Magazine.
David Orchard é o ex-diretor técnico do BEA Systems CTO Office, com foco em padrões de serviços da Web. Ele é um membro eleito do Grupo de Arquitetura Técnica do W3C e é um editor nomeado da extensibilidade e versão de versão do W3C TAG; Arquitetura de serviços da Web, XML e comitês consultivos.
Ele é atualmente ou foi um co-editor da arquitetura de serviços da Web, cenários de uso de serviços da Web, WS-Coordination, WS-ReliableMessaging, WS-Addressing, WS-Eventing, WS-MetadataExchange, WS-Transfer, SOAP-Conversation, XML Link e XInclude especificações.
Ele escreveu vários artigos técnicos, é o co-autor do Web Service Contract Design & amp; Versão para SOA, e é um falante freqüente em várias tecnologias relacionadas à Internet.
James Pasley é um arquiteto com Workday e um membro de sua equipe de Integração sob demanda. James é especialista no cliente que enfrenta aspectos da arquitetura de integração do Workday, como os serviços públicos da Web do Workday. James é editor do site de desenvolvimento do Workday e também cria muito material para os cursos de treinamento relacionados à integração da Workday. James juntou-se à Workday através da aquisição do software Cape Clear.
James ingressou no Cape Clear Software em 2001 como desenvolvedor principal do Cape Studio. Em 2003, James foi nomeado Arquiteto Chefe da Cape Clear, onde supervisionou o desenvolvimento do Enterprise Service Bus (ESB) do Cape Clear. Em 2005, James tornou-se Diretor de Tecnologia do Cabo Clear Software. A Cape Clear foi reconhecida pela Gartner e pela Forrester como o Enterprise Service Bus líder, oferecendo confiabilidade, escalabilidade e desempenho comprovados de integração sob demanda para conectar qualquer conteúdo, serviços ou software através da internet usando tecnologias de serviços da Web.
Antes de ingressar no Cape Clear Software, James trabalhou para a Siemens Nixdorf, desenvolvendo soluções seguras de mensagens X.400 e infra-estrutura de chave pública (PKI) para uma variedade de produtos.
James possui um B. A. (Moderator) em Computer Science do Trinity College, Dublin e é co-autor do Web Service Contract Design & amp; Versão para SOA.
Fundamentos de versão do contrato de serviços da Web Parte II:
Identificadores de versão e estratégias de versão.
Resumo: Existem diferentes formas de contratos de serviços de versão com base em políticas, prioridades e requisitos. Este, o segundo artigo em uma série de duas partes do livro "Web Service Contract Design & Versioning for SOA", apresenta três estratégias de controle de versão comuns: rigorosas, flexíveis e soltas. Os prós e contras de cada abordagem são discutidos e classificados em relação ao rigor, impacto de governança e complexidade. O papel dos identificadores de versão também é explorado através de uma série de exemplos.
O seguinte artigo é um trecho do novo livro "Web Service Contract Design and Versioning for SOA" [REF-1] Copyright 2008 Prentice Hall / Pearson PTR e SOA Systems Inc. Observe que as referências dos capítulos foram intencionalmente deixadas no artigo, conforme requisitos de Prentice Hall.
Um dos padrões de design mais fundamentais relacionados ao design do contrato de serviços da Web é o padrão de identificação da versão. Ele essencialmente defende que os números de versão devem ser claramente expressos, não apenas no nível do contrato, mas até as versões dos esquemas que estão subjacentes às definições das mensagens.
O primeiro passo para estabelecer uma estratégia de controle de versão efetiva é decidir sobre um meio comum pelo qual as próprias versões são identificadas e representadas nos contratos de serviços da Web.
As versões quase sempre são comunicadas com os números de versão. O formato mais comum é um decimal, seguido por um período e depois outro decimal, como mostrado aqui:
Às vezes, você verá um período adicional + pares decimais que levam a números de versão mais detalhados como este:
O significado típico associado a esses números é a medida ou o significado da mudança. Incrementar o primeiro decimal geralmente indica uma grande mudança de versão (ou atualização) no software, enquanto que os decimais após o primeiro período geralmente representam vários níveis de mudanças de versão menores.
Do ponto de vista da compatibilidade, podemos associar significado adicional a esses números. Especificamente, a seguinte convenção surgiu no setor:
Espera-se que uma versão menor seja compatível com outras versões menores associadas a uma versão principal. Por exemplo, a versão 5.2 de um programa deve ser totalmente compatível com as versões 5.0 e 5.1. Uma versão principal geralmente é esperada para quebrar a compatibilidade com programas que pertencem a outras versões importantes. Isso significa que a versão 5.0 do programa não deverá ser compatível com a versão 4.0.
Esta convenção de indicação de compatibilidade através de números de versão maiores e menores é referida como a garantia de compatibilidade. Outra abordagem, conhecida como "quantidade de trabalho", usa números de versão para comunicar o esforço que ocorreu na mudança. Um aumento da versão menor indica um esforço modesto, e um aumento importante da versão representa previsivelmente muito trabalho.
Essas duas convenções podem ser combinadas e muitas vezes são. O resultado é freqüentemente que os números de versão continuam a comunicar a compatibilidade como explicado anteriormente, mas às vezes aumentam em vários dígitos, dependendo da quantidade de esforço que entrou em cada versão.
Existem várias opções de sintaxe disponíveis para expressar números de versão. Por exemplo, você pode ter notado que a declaração declaração que começa um documento XML pode conter um número que expressa a versão da especificação XML que está sendo usada:
Esse mesmo atributo de versão pode ser usado com o elemento xsd: schema da raiz, da seguinte maneira:
Você pode criar uma variação personalizada desse atributo atribuindo-a a qualquer elemento que você definir (caso em que não é necessário nomear o atributo "versão").
Uma abordagem personalizada alternativa é incorporar o número da versão em um espaço para nome, como mostrado aqui:
Observe que se tornou uma convenção comum para usar valores de data em namespaces ao controlar os esquemas XML, da seguinte maneira:
Neste caso, é a data da alteração que atua como o identificador da versão. Para manter a expressão das versões de definição XML Schema alinhadas com as versões de definição WSDL, usamos números de versão em vez de valores de data nos exemplos ao longo dos próximos capítulos. No entanto, quando se trabalha em um ambiente em que as definições do Esquema XML são de propriedade separada como parte de uma arquitetura de dados independente, não é incomum que os identificadores de versão de esquema sejam diferentes dos usados pelas definições WSDL.
Independentemente da opção que você escolher, é importante considerar o padrão de Versão Canonical que dita que a expressão das informações de versão deve ser padronizada em todos os contratos de serviços dentro do limite de um inventário de serviços. Em ambientes maiores, isso exigirá frequentemente uma autoridade central que possa garantir a linearidade, a consistência e a qualidade da descrição das informações da versão. Esses tipos de convenções transportam a forma como a informação de término do serviço é expressa (conforme explorado no Capítulo 23).
Não existe uma abordagem de versão exclusiva para todos. Como o controle de versão representa uma fase relacionada à governança no ciclo de vida geral de um serviço, é uma prática sujeita às convenções, preferências e requisitos que são distintos para qualquer empresa.
Mesmo que não haja uma técnica de versão de fato para o WSDL, XML Schema e WS-Policy, que inclui contratos de serviços da Web, surgiu uma série de abordagens de controle de controle comuns e recomendadas, cada uma com seus próprios benefícios e compensações.
Neste capítulo, vamos selecionar as três estratégias conhecidas:
Estrita - Qualquer alteração compatível ou incompatível resulta em uma nova versão do contrato de serviço. Esta abordagem não suporta compatibilidade para trás ou para frente.
Flexível - Qualquer alteração incompatível resulta em uma nova versão do contrato de serviço e o contrato foi projetado para suportar a compatibilidade com versões anteriores, mas não é compatível.
Solto - Qualquer alteração incompatível resulta em uma nova versão do contrato de serviço e o contrato foi projetado para suportar a compatibilidade com versões anteriores e antecipa a compatibilidade.
Essas estratégias são explicadas individualmente nas próximas seções e referenciadas em todos os capítulos restantes.
Estratégia # 1: Estratégia Estrita (Nova Mudança, Novo Contrato)
A abordagem mais simples para a versão do contrato de serviço da Web é exigir que uma nova versão de um contrato seja emitida sempre que qualquer tipo de alteração for feita em qualquer parte do contrato.
Isso é comumente implementado alterando o valor de espaço de nome de destino de uma definição WSDL (e, possivelmente, a definição XML Schema) sempre que uma alteração compatível ou incompatível é feita com o WSDL, XML Schema ou WS-Policy relacionado ao contrato. Namespaces são usados para a identificação de versão em vez de um atributo de versão, porque alterar o valor do namespace força automaticamente uma mudança em todos os programas de consumidor que precisam acessar a nova versão do esquema que define os tipos de mensagem.
Esta abordagem "super estrita" não é realmente prática, mas é mais segura e às vezes justificada quando há implicações legais para as modificações do contrato de serviços da Web, como quando os contratos são publicados para determinadas trocas de dados entre organizações. Uma vez que as alterações compatíveis e incompatíveis resultarão em uma nova versão do contrato, esta abordagem não suporta compatibilidade para trás ou para frente.
O benefício desta estratégia é que você tem controle total sobre a evolução do contrato de serviço, e porque a compatibilidade para trás e para frente é intencionalmente desconsiderada, você não precisa se preocupar com o impacto de qualquer mudança em particular (porque todas as mudanças efetivamente quebram o contrato).
Em contrapartida, ao forçar um novo espaço de nome no contrato com cada mudança, você está garantindo que todos os consumidores de serviços já existentes não serão mais compatíveis com qualquer nova versão do contrato. Os consumidores só poderão continuar a se comunicar com o serviço da Web enquanto o contrato antigo permanecerá disponível ao lado da nova versão ou até que os próprios consumidores sejam atualizados para se adequarem ao novo contrato.
Portanto, essa abordagem aumentará a carga de governança dos serviços individuais e exigirá estratégias cuidadosas de transição. Ter duas ou mais versões do mesmo serviço coexistir ao mesmo tempo pode se tornar um requisito comum para o qual a infraestrutura de inventário do serviço de suporte precisa ser preparada.
Estratégia # 2: A Estratégia Flexível (Compatibilidade para trás)
Uma abordagem comum usada para equilibrar considerações práticas com uma tentativa de minimizar o impacto das alterações nos contratos de serviços da Web é permitir mudanças compatíveis, sem forçar uma nova versão do contrato, sem tentar suportar compatibilidade.
Isso significa que qualquer alteração compatível com versões anteriores é considerada segura na medida em que acaba por estender ou aumentar um contrato estabelecido sem afetar nenhum dos consumidores existentes do serviço. Um exemplo comum disso é adicionar uma nova operação a uma definição WSDL ou adicionar uma declaração de elemento opcional à definição de esquema de uma mensagem.
Tal como acontece com a estratégia Strict, qualquer alteração que quebra o contrato existente resulta em uma nova versão do contrato, geralmente implementada ao alterar o valor do espaço para nome do destino da definição do WSDL e potencialmente também a definição do Esquema XML.
A principal vantagem para esta abordagem é que ele pode ser usado para acomodar uma variedade de mudanças, mantendo consistentemente a compatibilidade para trás do contrato. No entanto, quando as alterações compatíveis são feitas, essas alterações se tornam permanentes e não podem ser revertidas sem introduzir uma alteração incompatível. Portanto, é necessário um processo de governança durante o qual cada alteração proposta é avaliada para que os contratos não se tornem excessivamente inchados ou complicados. Esta é uma consideração especialmente importante para os serviços agnósticos que são fortemente reutilizados.
Estratégia # 3: A Estratégia Fraca (Compatibilidade para trás e para a frente)
Tal como acontece com as duas abordagens anteriores, esta estratégia exige que as alterações incompatíveis resultem em uma nova versão do contrato de serviço. A diferença aqui é a forma como os contratos de serviços foram projetados inicialmente.
Em vez de acomodar requisitos de troca de dados conhecidos, recursos especiais dos idiomas WSDL, XML Schema e WS-Policy são usados para tornar partes do contrato intrinsecamente extensíveis para que permaneçam capazes de suportar uma ampla gama de requisitos de troca de dados futuros e desconhecidos.
O valor do atributo anyType fornecido pelo idioma WSDL 2.0 permite que uma mensagem consista em qualquer documento XML válido. Os curingas XML Schema podem ser usados para permitir que um intervalo de dados desconhecidos seja passado nas definições de mensagens. Asserções de política ignoráveis podem ser definidas para comunicar características de serviço que podem ser reconhecidas pelos consumidores futuros.
Esses e outros recursos relacionados à compatibilidade com versões anteriores são discutidos nos próximos capítulos.
O fato de que os curingas permitem que o conteúdo indefinido seja passado através de contratos de serviços da Web oferece uma oportunidade constante para expandir ainda mais o intervalo de conteúdo de elementos e dados de mensagens aceitáveis. Por outro lado, o uso de curingas resultará naturalmente em contratos de serviços vagos e excessivamente grosseiros que colocam a carga de validação na lógica do serviço subjacente.
Fornecido aqui é uma tabela que resume amplamente como as três estratégias se comparam com base em três características fundamentais.
Tabela 1 - Uma comparação geral das três estratégias de controle de versão.
As três características utilizadas nesta tabela para formar a base dessa comparação são as seguintes:
Strictness - A rigidez das opções de versão do contrato. A abordagem restrita é claramente a mais rígida em suas regras de versão, enquanto a estratégia Loose oferece a maior variedade de opções de controle de versão devido à dependência de curingas. Impacto de governança - A quantidade de carga de governança imposta por uma estratégia. As abordagens estritas e soltas aumentam o impacto da governança, mas por diferentes motivos. A Estratégia Estrita requer a emissão de novas versões de contratos, que afetam os consumidores e as infra-estruturas circundantes, enquanto a abordagem Loose introduz o conceito de conjuntos de mensagens desconhecidas que precisam ser acomodados separadamente através de programação personalizada. Complexidade - A complexidade geral do processo de versão. Devido ao uso de curingas e dados de mensagens desconhecidas, a estratégia Loose tem o maior potencial de complexidade, enquanto as regras diretas que formam a base da abordagem Strict tornam a opção mais simples.
Ao longo desta comparação, a estratégia Flexível oferece uma abordagem que representa um nível consistentemente médio de rigor, esforço de governança e complexidade geral.
Cada estratégia também determina como mudanças compatíveis, mudanças incompatíveis e identificadores de versão são usados e aplicados em suporte às regras e convenções da estratégia. Os Capítulos 21, 22 e 23 exploram a aplicação dessas estratégias individualmente para definições de WSDL, definições de Esquema XML e definições de WS-Policy.

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. 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.

Soa service versioning strategy

Microservices Expo: Article.
Design Strategies for Web Services Versioning.
Adapting to the needs of the business.
Application versioning has always been a challenge for the developer community. With the introduction of Web services, this issue becomes even more difficult as developers are dealing with a more distributed set of components that aren't necessarily under their control.
A robust versioning strategy is needed to support multiple versions of Web services in development. This can allow for upgrades and improvements to be made to a Web service, while continuously supporting previously released versions. The right versioning strategy can maximize code reuse and provide a more manageable approach to the naming, deployment, and maintenance of your Web services.
The issue of versioning is a complicated one, and this article does not attempt to answer every question surrounding the versioning of XML and Web services. However, there are some key approaches and design practices that have been helpful in our development that we will share with you here. The approach we will take is to start at the component level (XML Schemas) and work up to higher service-level abstractions, including facades and service-oriented (SOA)–based architectures. Along the way, we hope to impart some important best practices that can be applied to incorporate versioning techniques at various levels of the design.
Let's begin by looking at the importance of XML Schemas.
The Importance of XML Schemas in Versioning.
Versioning for Web services should first consider how the XML Schemas being used are versioned. A number of approaches can be taken to version XML Schemas, including using a schema version attribute, changing the physical location of the schema, and leveraging XML Namespaces.
XML Namespaces provide a scoping mechanism for XML, where elements defined in that namespace can be uniquely identified. Namespaces are typically used to reduce name collisions between schemas, but they can also be used as a version control mechanism. Here's a simple example showing how Namespaces can be used for versioning:
A Web service referencing a versioned schema would be required to have knowledge of the version because it is built intothe targetNamespace. The benefit of this approach is that once the targetNamespace is updated, any clients that reference it are required to do something. This automatically enforces a level of version control, requiring some action on the client's part.
The downside of this approach is that any incremental change would require the client to also change. Clearly, a noncompatible change such as removing a WSDL operation being used by the client requires client modification. But, a change such as adding an optional attribute to the schema would still be compatible with the existing code. One key question that must be addressed in your design is: What changes should constitute a new Web services version? If you take the approach that any change results in a new Namespace, this will place a great burden on the developers using the schemas.
One proposed hybrid solution is to use a combination of Namespace and version ids. The targetNamespace would only be updated for non-compatible changes. For any incremental, compatible change, the version ID attribute could be used to identify the new revision. The following approach can significantly reduce the amount of maintenance required by the developer when new versions of a Web service are released.
Version compatibility can be a very difficult thing to determine. Without any robust development tools available for this, it is the responsibility of the development team to determine whether a new release maintains compatibility. In this section, we've presented a number of approaches to versioning XML Schemas. If you're considering versioning at this level of your architecture, we would recommend use of XML Namespaces in a limited capacity to indicate major version upgrades to the XML But, it is a good practice to fully test your services to verify version compatibility.
Naming Conventions for Versioning.
Having a name for each release of a Web service is essential for simplifying the management of the releases. The naming strategy should facilitate recognition of multiple versions of a Web service, including both existing and new interfaces. Different strategies can be implemented here, including using a sequential naming strategy or date stamps.
When you are sequentially naming your version you can use a convention of "vMajor#.Minor#/SERVICE_NAME, where Major# is the major version release and Minor# is the minor number release. A major release would most likely require a change in the client code to use the new version, while a minor release would attempt to maintain backward compatability with the client. A minor version could constitute a modification to a Web service that would impact the internal system only.
The standard method name for a Web service has "_v#_#" appended to the end of its name. Thus, for the getProductCatalog service we might define the operation as "getProductCatalog_v1_1". Or, if you are applying this to XML namespaces, it might look like:
Another way of naming versions is to use date stamps as part of the namespace. The date helps to determine the sequencing of the version. This naming convention does not show a major or minor release. Here's how this might look in our definition of the schema:
The important thing to remember is that there isn't one best solution in how you name the versions. Your approach will depend on the deployment strategy you use and the specific requirements your clients might have to distinguish versions and maintain compatibility.
It should also be apparent that these techniques can become very unmanageable if you have to apply them to every component in your design.
To address this, let's turn to a few important design practices for building more coarse-grained services with design patterns and service-oriented architectures.
Using Web Services Facades.
As organizations build, deploy, and orchestrate Web services, it becomes apparent that a higher level of versioning and management is required. You must begin thinking about services from a business level, rather than from the technical interfaces being exposed. However, many organizations investigating Web services are still looking at them as extensions to object-oriented paradigms. They make the mistake of taking their existing objects and exposing them directly with a Web services interface. This will most likely deliver Web services that are fine grained and difficult to use. It can also make it difficult to incorporate a consistent approach to Web services versioning.
Instead, think from the perspective of the WSDL first, and map to a back-end implementation later. This approach provides a more loosely coupled architecture, minimizing dependencies on specific implementations. You should also look to design patterns, such as the Web Services Facade, to assist in the creation of coarse-grained components. This pattern takes the complexity out of the interfaces being exposed. Rather than having multiple interface points to a collection of services, composite Web services can be designed with simpler, well-understood business interfaces.
As Figure 1 illustrates, the facade can be used to simplify the steps required to place a Change Order request. While this picture shows the facade being used from the perspective of the provider, a consumer of could also design facades to simplify access to services.
The use of this pattern can offer a number of benefits, including minimizing the level of coupling between consumer and service, creating a control point for manageability, and improving overall performance by reducing the number of network calls. The facade pattern can also provide a framework for managing the inherent complexity of supporting multiple Web services versions simultaneously.
One implementation of this pattern, shown in Figure 2, creates levels of abstraction by separating the code into three distinct tiers of classes: request handler classes, facade business flow classes, and business object classes.
The managing class, the session facade class, is responsible for chaining the smaller business object classes together. Each business object class contains a subunit of processing logic, and chaining of all these business object classes provides the core business logic. Each session facade class by itself contains no processing logic, but by concatenating business objects together it implements the desired business logic.
This architecture decouples processes from each other, allowing reuse of components. It also helps in managing the complexity of Web services as business requirements change in different versions of the service. Processes leveraged to execute business requirements are abstracted into individual pieces of software code that one managing class chains together to execute in sequence. By chaining these pieces of code together, required business processes are implemented to adhere to a specific business process flow. Thus, by building multiple managing classes, different business flows can be implemented and maintained simultaneously.
Importance of Service-Oriented Architectures.
The design of coarse-grained services is an important aspect of a versioning strategy, simplifying the client interfaces and maximizing reuse. Designing facades at the implementation level can help, but it still requires a significant change to the underlying infrastructure at various levels that someone has to deal with. What's truly needed is an SOA-based platform that can assist in the management of the entire life cycle of Web services.
An SOA-based approach offers software components as a collection of distributed business services. A business service plays the role of a single entity that represents a business application, and may include multiple IT resources, platforms, and components. The model, simplified in Figure 3, separates the roles of consumer, provider, and registry. A provider registers available services in a registry that the consumer can later discover and invoke. Consumers aren't directly aware of a specific service endpoint or the implementation details. The SOA provides a greater degree of separation between the provider and consumer, and as changes are made to a service, the SOA can help minimize the impact on the consumer.
An SOA typically requires some type of framework or platform that can act as an intermediary between providers and consumers. Without this intermediary in place, consumers would have to build a more tightly coupled integration with a service endpoint. This intermediary could be implemented as a proxy, a gateway, or a broker, handling issues such as security, routing, SLA management, and life-cycle management.
The life-cycle management features offered by the platform are key to our discussion of versioning. Some Web services and SOA management platforms on the market today offer support for life-cycle management. This might include: The ability to handle multiple versions of a service at the same time Deprecating or retiring services in a graceful manner Routing requests to the appropriate service endpoint based on a request Transforming requests and responses to maintain backward compatibility (e. g., using XSLT) Automated deployment of new versions without requiring system shutdown Managing dependencies that exist between different Web services Life-cycle management is also much more than just managing the deployment of Web services. From the perspective of a business service, life-cycle management might include many platforms, application servers, and database instances. To truly manage this level of a service, you must consider how all dependent application components and infrastructure elements are deployed and managed.
Let's look at an example showing a common versioning problem. In Figure 4, a provider has offered an initial version of a Web service, V1.0. The platform would automatically route requests for this service to an appropriate service endpoint. Routing could be determined based on information placed in a UDDI registry, or the underlying management model could manage this (e. g., through WSDM interfaces).
At some point, a second version of the service is deployed that maintains backward compatibility. Within the SOA, the new service is identified as supporting both the original business service and the new business service. Requests made for the original business service could be brokered to either service endpoint. Consumers wishing to access the new functionality would have to make the appropriate programmatic changes.
This approach to versioning allows an IT organization to better adapt to changes required by the business. Multiple versions of a service can be maintained simultaneously without impact to the consumer. Old versions can be retired gracefully, and consumers can upgrade on their own time, rather than being forced to when new versions are released.
Even with a solid design and robust architecture for versioning, there is still a human factor that must be considered in this process. Understanding the versioning life cycle will help you to implement new versions and deprecate the older versions effectively. The first step in this process is to put a solid plan together describing the life cycle of Web services being supported. This plan might include the following steps:
1. Determine how often versions are to be released . When considering frequency, you should consider how many versions of the Web service you want to support in parallel.
2. Understand the timeframe within which you expect consumers to move to a new version of a service . The Web services management platform may be able to provide guidance on service usage to determine the appropriate time to phase out older versions.
3. Consider releasing a pilot or an early release of a new version . Give consumers an opportunity to test compatibility and determine potential code impacts.
4. Approach Web services versioning the same way software packages might be released . Changes to your service, either as a result of bug fixes, partner requests, or specification upgrades, should follow a specific release cycle.
5. Clearly communicate your Web services versioning strategy to users of your Web service .
Once the versioning strategy is laid out for each release you should then consider the following steps:
1. After making the appropriate changes to your services, do unit and functional testing of the service.
2. Deploy the new service through appropriate schema, WSDL, and service changes. This step might include registration to a UDDI registry or the Web services platform.
3. Notify the consumers of your new service and pilot the new versions with one of your consumers.
4. Run the new and old versions in parallel for the timeframe you have allocated in your versioning plan.
5. Notify the consumers of your service of the date you expect to deprecate old versions.
6. Remove old versions from WSDL descriptions and UDDI registries to prevent new consumers from discovering and using the older versions.
7. Remove functionality of the old service, and add in appropriate functionality so existing consumers are properly notified (e. g., through a SOAP fault) that the old version is no longer supported.
One approach to deployment is shown in Figure 5. The calendar is shown in quarters of a company's financial calendar. The new version can be introduced at the beginning of a quarter (e. g., Q1 of 2003). It is valid for four quarters and then is sunset at the beginning of Q1 of 2004. In this case, the consumer of the service could be given six months to convert to the new version. You can also have minor versions released in between the major versions. These minor releases can then be folded into the Web service version 2.0 when it is released.
This article has presented a number of considerations when versioning Web services. Whether it's developing a versioning approach for schemas or building a full-scale versioning system using an SOA approach, there are a couple of key points that we would like to leave you with.
First, we hope it's obvious that versioning can become a nightmare as you deploy more and more versions of your service, especially if the service is being offered to different consumers. The goal of your design should be to build reusable components that can be leveraged and reused across the versions being managed. In the long run, this will reduce maintenance and deployment costs.
Second, don't underestimate the impact these changes might have on the consumer. While the design you introduce might reduce your development costs, you must also consider how these changes impact the end consumer. Service compatibility is key to this, and if new services maintain backward compatibility, consumers wishing to use the existing functionality shouldn't be required to change. The architecture should provide an easy migration and upgrade path for them.
Third, you want to strive to isolate the technical implementation and provide a clear separation between the consumer and provider. This might be implemented using design patterns such as the Facade, or it could require an SOA-based approach. Either way, the notion of coarse-grained business services offers a more loosely coupled architecture where consumers and providers can change without impacting the other party.
The last piece of advice we could offer is to not attempt to build the entire versioning infrastructure yourself. If you look at the requirements for manageability, they include a wide range of features such as routing, transformation, versioning, and security. Leveraging a vendor offering, especially one that provides a service-oriented approach IT management, can go a long way toward offering an architecture that can truly adapt to the changing needs of the business.
Published April 5, 2004 – Reads 53,749.
Direitos autorais e cópia; 2004 SYS-CON Media, Inc. — Todos os direitos reservados.
Syndicated stories and blog feeds, all rights reserved by the author.
More Stories By Chris Peltz.
Chris Peltz is a senior architect within HP's.
Developer Resources Organization (devresource. hp), providing technical and architectural consulting to enterprise customers in the areas of J2EE, Web services, and.
More Stories By Anjali Anagol-Subbarao.
Anjali Anagol-Subbarao works in HP's IT organization as an IT architect. She has 12 years of IT experience, the last five in Web services. Her book on J2EE Web services on BEA WebLogic was published in October 2004.
Click this link to view as XML.
ADD THIS FEED TO YOUR ONLINE NEWS READER.
Cloud Expo.
All of Cloud Is at Cloud Expo!
Containers - Microservices - WebRTC - DevOps.
Join Us at the Javits Center in New York, NY, June 6-8.
• Big Data | Analítica.
• Internet of Things.
Register Now!
Save on your "Golden Pass"! Call 201.802.3020.
or click here to Register.
Submit your speaking proposal for the upcoming Cloud Expo in New York.
Please Call 201.802.3021.
events (at) sys-con.
carmen (at) sys-con.
Todos os direitos reservados. All marks are trademarks of Ulitzer, Inc.
Reproduction in whole or in part in any form or medium without express written permission of Ulitzer, Inc. is prohibited.

Versioning in SOA.
by Boris Lublinsky.
Summary: Service-oriented architecture (SOA) is taking a center stage in enterprise architecture. SOA enables parallel development by multiple disparate teams, each with its own delivery and maintenance schedule. In this article, I will examine service-versioning approaches, allowing service implementations to evolve without breaking existing consumers, leading to more loosely coupled SOA implementations.
The basic idea of service versioning is fairly simple, but its implementation requires strict governance. I will discuss units of versioning; service changes, constituting a new version; service version life-cycle considerations; and version deployment/access approaches. The method-based service versioning proposed here allows one to minimize the impact of versioning and to reduce amount of deployed code. Semantic messaging for service-interface definitions makes service implementation more resilient to change. (12 printed pages)
If there is a constant in IT implementation, it is change. Business conditions change, consequently requiring IT implementations to change. New techniques and patterns allow for better implementation of qualities of service, such as load balancing and failover, security, and so forth. Information technology itself changes continually with the introduction of new operating systems, programming languages, and application servers, for example, that simplify creation and maintenance of new solutions. In fact, a driving force in the implementation of an IT solution is its ability to cope with these inevitable changes.
In the era of monolithic applications, changes were dealt with on an application-by-application basis. Implementation of change, whether for a new business or infrastructure—for example, the introduction of a security policy or requirement, or moving an application to a new software platform—was done for an application as a whole, consuming significant amounts of time and money to complete. On the other hand, because each application was developed by a single team and independent, this approach allowed changes to be contained. As a new version of an application was introduced, the previous version came out of use and could be disposed.
One of the main advantages of a service-oriented architectural style is its ability to efficiently deal with changes. SOA is based on a decomposition of enterprise IT assets and separation of "stable" IT artifacts (services) from "changeable" artifacts (business processes), orchestrating services into IT solutions (processes). As a result, business requirements changes can often be satisfied by either changes to existing processes or creation of new enterprise business processes based on the existing services. This approach allows for much better (faster, cheaper) support for required changes through (re)assembling of a solution based on the reusable enterprise services. Business services become resources, shareable by multiple business solutions, enabling massively parallel autonomous development of services by multiple disparate teams, each with its own delivery and maintenance schedule.
Because every service, in this case, is used simultaneously in multiple enterprise solutions, a change in a business service can have a significant impact on many existing implementations and may, consequently, require changes in each of them. This is not only extremely expensive (requiring a tremendous amount of coordination between development teams and testing, ensuring that none of the multiple service consumers are affected), but also goes against one of the fundamental SOA tenets: Services are autonomous. Autonomy is the fundamental concept behind service orientation. Services should be deployed and modified/maintained independently from each other and the systems that use them.
The problem of dealing with shared, potentially changing components is not a new one. For example, Windows operating system and Windows-based applications rely on the shareable COM/ActiveX components. In the COM case, components are considered immutable and any functional change requires introduction of new component with a new globally unique identifier (GUID). Such approach allows for simultaneous coexistence of multiple components/versions.
In this article, I will discuss service-versioning approaches, allowing service implementations to evolve without breaking existing consumers.
Introducing Service Versioning.
One the most popular approaches for dealing with changes is versioning. Versioning assumes simultaneous existence of multiple (different) implementations of the same thing, with every implementation distinguishable and individually addressable. In the case of SOA, service versioning equates to coexistence of multiple versions of the same service, which allows each consumer to use the version that it is designed and tested for (see Figure 1). In this case, a new version of a service is created based on the requirements of one or more consumers, which can start using this new version immediately. The other consumers of this service do not need to switch to using the latest version immediately, but can continue to use the versions of the service they were designed for and tested with. They can switch to the latest version of service, based on their own development and testing schedule. Multiple coexisting versions of the same service in the system allows for the independent life cycles of services and their consumers and minimizes the overall impact of the introduction of changes. Although the necessity of such versioning mechanism may be obvious to anyone who has ever dealt with services, this topic still has not penetrated the mainstream of SOA publications and implementations. The basic idea of service versioning is fairly simple and straightforward, but its implementation requires definition of the following:
Units of versioning Service changes, constituting a new version Service version life-cycle considerations Version deployment/access approaches.
Figure 1. Coexistence of multiple service versions.
Units of Versioning.
There are two major options for defining units of versioning, each with its own benefits and liabilities.
Based on the current Web Services practices (the most popular SOA implementation technology today), many practitioners propose versioning of the service (including all its operations) as a whole . Although this approach is well aligned with the current object-oriented (OO) and component-based development (CBD) practices, it does not always seem to be appropriate in the case of coarse-grained services. (For further comparison of SOA and OO, see "Defining SOA as an Architectural Style," under Resources.)
When people talk about versioning in their everyday conversations, they usually talk about changes and versioning of the methods, not a service itself. For example, consider an account service that implements three operations: withdrawal, deposit, and transfer. Typically the conversation revolves around changes of the individual operations (in other words, withdrawal), not the account service itself.
Therefore, another option is to define individual service operations (methods) as a unit of versioning . Versioning service operation independently has the following advantages:
It allows for immutable services. The service can provide additional methods (versions of methods), some of which can be deprecated over time, but the service itself, its name and classification, never changes. This scheme resembles versioning approaches in popular programming languages, such as Java or C#, where methods on classes are added and deprecated quite often while existing classes that are widely used rarely change. It minimizes the impact of the service changes to consumers. Only consumers using a particular method are affected by a change, instead of all service consumers. It minimizes the overall amount of deployed code. Only methods with a new version get redeployed in the process of introduction of the new version. The code implementing methods that have not changed remains unchanged.
It also has the following liabilities:
It calls for deploying each method independently with its own endpoint address(es). (Although such a deployment approach is not mainstream today, it has some advantages, such as providing different service-level agreements (SLA) for different methods within the same service.) It requires a different, slightly more complex, service invocation addressing schema. Instead of specifying a service that it needs to invoke, the service consumer, in this case, needs to explicitly specify the service, the operation, and the version of the operation that it requires.
Despite the requirement for nonstandard service invocation/routing, method-based service versioning provides enhanced flexibility and better aligns service versioning with the versioning practices prevalent for programming languages. It also minimizes the amount of code that has to be redeployed to support a new version. These characteristics make method-based versioning a powerful service-versioning approach.
Version Definitions.
Defining what constitutes a new version of the service (method) requires analyzing the possible changes, their potential impact on the consumer's execution, and identifying the ones that will "break" it. Any change in the service, whether it is a change in the interface or implementation that might impact consumer execution, should lead to creation of the new version of service (method) . Although the above definition is not very precise and open for interpretation, it provides a good starting point for decision on creation of the new version.
I will further examine the major components of service definition (interface and message definitions) and implementations to determine particular situations that can lead to new version creation.
Service-Interface Changes.
Following the adoption of the semantic messaging model, the service method signatures never change (all changes are reflected in the semantic model changes). The service method's interface in the case of semantic messaging is:
servicemethod (XML in, XML out)
Consequently, the service method's interface never changes and should not be considered in versioning definition. Because every method is individually deployed and addressed in a method-based versioning scheme, additional methods can be introduced for the service without impacting existing service consumers. Finally, because all the interface changes are contained in the messaging model, method removal (deprecations), in this case, is equivalent to elimination of some of the enterprise functionality and should happen very rarely. From the consumer point of view, this situation requires (potentially significant) modifications, which entail either internal implementation of the required functionality or usage of a completely different service. In this case, the service method is defined as deprecated and is kept around, while each of its consumers will be able to stop using it (see Service Version Life-Cycle Considerations, later in the article).
Message Changes.
As defined earlier, in the case of semantic messaging, the changes in the service interface are contained in the semantic messages changes. These messages are defined using schemas describing their content. Usage of the messaging schemas for defining potential interface changes aligns this approach with XML schema versioning techniques (see "Versioning Support in XML Schemas," under Sidebar), and thus allows for direct representation of versioning in the service messages. Changes in schemas can be broadly defined in three major categories:
Revisions represent document's schema changes with no semantic meaning. For example, a change in white space, formatting, non-normative documentation, comments, and so on. A revision of an already published version must not impact the functionality of either service implementations or consumers.
Additionally, the initial incremental development of a semantic schema, before it is published for production use, can also be treated as revisions of the same version.
Minor changes represent backward-compatible changes to the document schema. Examples of minor changes to the schema include:
Changing the optionality of a local element or element reference from required to optional Adding a global element or type Adding optional elements to the existing type Changing type of a global or local element to the new type, derived from the original by adding/restricting optional elements.
Major changes represent non-backward-compatible changes to the document schema.
Examples of major changes to the schema include:
Changing the type of a local or global element to the new type, derived from the original by adding/restricting optional elements. Changing the optionality of a local element or element reference from optional to required Adding or removing an enumeration value Removing or renaming a global type or element.
Based on the above definitions, both revisions and minor changes in the messaging schema provide backward compatibility and will not "break" the service contract. As a result they will not impact either service or consumer implementation and do not require service versioning. In contrast, major changes require versioning of messaging schema and, consequently, services.
Implementation Changes.
A common misconception is that, because services are defined through the interface—not implementation—changes in the service implementation will not affect service consumers and do not require versioning.
In reality, adherence to the interface does not constitute replaceability of implementations. Replaceability is not defined by interface alone, but instead by the contract—which includes interface, pre - and post-conditions, and certain SLAs—on which the service consumer relies. Consequently, versioning is required when service implementation changes affect the contract on which a particular service consumer relies. Because different service consumers can rely on different parts of the service contract, every service implementation changes should be validated against all existing service consumers to ensure that no contracts will be "broken."
Here are some of the examples of how changes in service (method) implementation can lead to the contract changes:
New service implementation supports exactly the same interface (functionality), but changes execution timing (SLA). If a service consumer is invoking this service (method) synchronously, such change can significantly impact service consumer execution. As a result, service versioning might be required. (Interestingly enough, even redeployment of existing service, with changes to its implementation, can lead to the same results.) New service implementation supports the same interface, but changes incoming parameters validations (preconditions). In this case, some requests that had been processed successfully will now be rejected, requiring introduction of a new service. New service implementation introduces a new security implementation (precondition), which often is not reflected in service interface, but done through the configuration settings. (See Web Services Handbook for WebSphere Application Server Version 6.1 , under Resources.) In this case, existing service consumers will require sending security credentials; implementation change and creation of the new version is required.
Every one of these scenarios requires analysis of existing service consumers and potentially extensive testing. As a result, a simpler way to decide whether a new version of service (method) needs to be created when the service implementation changes is to maintain a definition of service (method) contract and creating a new version when the contract changes, regardless of which consumers rely on which parts of the contract. When in doubt, it is usually simpler to create a new version.
Service Version Life-Cycle Considerations.
One of the important versioning considerations is defining the length of time for which a version of service (method) will be preserved. Extending this period leads to the necessity of maintaining excessive amount of service versions. Shortening the period, on another hand, constrains the time for service consumers to implement required upgrades. The appropriate life cycle for service (method) versions varies significantly and is defined by organization's ability to cope with changes.
Version Deployment/Access Approaches.
There are two common approaches to the deployment of service versions:
Covenant or Version Parameter . A covenant is an "if-then-else" agreement ("if you do this then I will do that"). In this case, there is a single endpoint address for all versions of the service (method), as shown in Figure 2.
Figure 2. Implementation of versioning using covenant.
The covenant effectively implements context-based routing, taking an incoming message and routing it (based on a version parameter, embedded in the invocation message) to the appropriate service version. The benefit of this approach is that it simplifies service addressing from the consumer point of view. The consumer, in this case, uses a single endpoint address to access all versions of a given service (method) and encodes the required method in the invocation message. An endpoint address implements a routing support, invoking a required version.
Although the covenant approach minimizes the impact of introduction of new versions on the service consumers, it introduces the complexity of packaging together multiple versions of a service method. This can lead to class name collisions, database names collisions, and so on. Furthermore, this approach effectively requires a versioning strategy not only for services themselves, but also for the components used for service implementations. Considering the tighter coupling between components, this problem can be even more complex than services versioning.
Further improvement can be achieved by replacing the local router dispatching between the service versions implementation with an external broker ( mediator ). In this case, all versions can be deployed independently and it is a responsibility of mediator to dynamically resolve endpoint address of the desired service version and dispatch all messages accordingly. However, although intermediaries (mediations) are often touted by ESB publications as a cure for most routing/transformation problems, encountered in service-oriented architecture, there are costs associated with them. Typically, it lowers performance. It also must support the most stringent SLA of all the services accessed through it, which could be a very strong requirement.
Multiple endpoint addresses . In this case, similar to the mediator implementation, every version of a given operation is deployed at its own endpoint address. The difference here is that every endpoint address is directly exposed to a service consumer (see Figure 3).
Figure 3. Implementation of versions using directly exposed endpoint addresses.
Multiple endpoint addresses assume that a service consumer can resolve endpoint address (typically using service registry) for a required version based on the service/method/version information. The advantage of this scheme is a complete separation of multiple method versions deployment. The drawback is a more complex addressing paradigm, requiring service registry support for resolving endpoint address.
The multiple endpoint address approach typically provides better scalability (one less network hop) and lowers the coupling between multiple versions of the same operation.
Versioning of Service Infrastructure.
A variant of service versioning is versioning of the service infrastructure, which can involve the following:
Transport changes—for example, switching transport from HTTP to Java Message Service (JMS) Message encoding changes—for example, upgrading proprietary enveloping with Simple Object Access Protocol (SOAP) Changes in addressing schema—for example, introduction of the Web Services Addressing for reply-address specification.
In this case, it is always desirable to implement "backward compatibility," ensuring that new infrastructure can "understand" and support messages produced by the old infrastructure and produce messages compatible with it. In reality, it might be too expensive, or even technically impossible.
Moving all of the existing service implementations and consumers to the new infrastructure is typically fairly expensive and time-consuming, requiring versioning support that provides interoperability between two different service infrastructures. The most popular solution to this problem is a service adapter (see Figure 4).
Figure 4. Interoperability between service infrastructures (Click on the picture for a larger image)
In this case, when the service consumer supported by service infrastructure 1 invokes the service provider supported by the service infrastructure 2, the invocation goes through the adapter mediating between the service infrastructures. From the point of view of the service consumer, the adapter acts as a service provider. The adapter then invokes the service provider acting as a service consumer.
This implementation can be combined with service-versioning deployment topology (see Figure 4) to provide versioning support for both services and service consumers between different infrastructures.
Versioning Support in XML Schemas.
The simplest way of denoting versions in XML Schema is usage of an (optional) attribute at the xs:schema element - version. The content model permits Dewey notation of major. minor version numbers.
Because XML parsers are not required to validate instances using version, it is possible to implement custom representation of version, enabling the parser to include it in the validation process. Using this technique typically requires introduction of a versioning attribute as a fixed, required value for identifying a specific schema version. However, this approach for schema versioning is not very practical. There are several disadvantages:
An XML instance will be unable to use multiple versions of a schema representation because versioning occurs at the schema's root. XML schema validation tools are not required to validate instances using the version attribute; the attribute is provided purely for documentation purposes and is not enforceable by XML parsers. Because XML parsers are not required to validate using the version attribute, additional custom processing (over and above parsing and validation) is required to ensure that the expected schema version(s) are being referenced by the instance. Marshaling/unmarshaling of XML documents is very rarely done using direct manipulation of the DOM tree. The prevalent approach to marshaling is generation of the classes, supporting "automatic" marshaling, using tools like WSDL2Java, Castor, EMF, SDO, XSD, XSDObjectGenerator, and so on. In this case, classes are generated in the packages in Java or namespaces in C#, based on the schema namespaces, not the schema version.
Another option for denoting schema version is usage of XML Namespaces. In this approach, a new XML Namespace is used for all major version releases. 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 blublinsky@hotmail.
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.

Troca de divisas on-line Macaé

Search This Blog

Estratégia de controle de serviço do soa

Soa service versioning strategy

Comments

Post a Comment