Estratégia de versão xml

Impacto do XML Schema Versioning no System Design.
(Estratégias para facilitar a evolução do sistema)
Introdução.
Criar uma nova versão de um Esquema XML pode ter efeitos que ondulam através de muitas partes de um sistema. Gerenciar esses efeitos pode ser caro. Portanto, vale a pena examinar maneiras de mitigar os efeitos de ondulação dispendiosos das novas versões de um Esquema.
Freqüentemente, o controle de esquema é considerado isoladamente do resto do sistema. No entanto, conforme observado, as alterações do esquema podem afetar outras partes de um sistema, por isso recomendamos que o controle de esquema seja parte de um plano de evolução do sistema integrado. O controle de esquema é um dos drivers para a evolução do sistema.
Como uma estratégia para facilitar a evolução do sistema, nos concentramos nestas três partes de um sistema - Esquemas, documentos de instância e aplicativos. Para tratar essas três partes de forma holística, fazemos as seguintes recomendações:
Recomendações de Design de Esquema:
Recomendações de Design de Documentos de Instância:
Recomendações de design de aplicativos:
A justificativa de cada uma dessas recomendações é explicada ao longo deste trabalho. Mas primeiro começamos definindo a natureza dos sistemas que estão sendo direcionados.
O sistema.
Declaração do problema.
Categorias de mudanças de esquema que impactam documentos e aplicativos de instância.
Nota: Existem muitos outros tipos de alterações que podem ocorrer em um esquema XML do que os listados acima. No entanto, são mudanças internas no esquema e não têm manifestação em documentos de instância.
Abaixo, discutimos como mitigar o impacto de cada uma dessas mudanças.
1. Namespace-Aware Applications.
A maioria dos aplicativos XML é "conhecimento do espaço para nome". Ou seja, o aplicativo foi projetado para processar elementos pertencentes a um espaço de nome específico.
Por exemplo, um processador de transformações de linguagem de folha de estilo XML (XSLT) é um aplicativo que entende o espaço para nome XSLT: Concretamente, isso significa que um processador XSLT (aplicativo) sabe como processar elementos como & lt; template>, & lt; for-each> & lt; if>, etc., desde que os elementos estejam associados ao namespace XSLT.
Alterar espaços de nomes resulta na quebra de aplicativos com reconhecimento de namespace. Isso nos leva à nossa primeira recomendação:
Recomendação 1: Para evitar quebrar aplicativos compatíveis com o namespace com cada nova versão de um Esquema XML use o mesmo espaço de nome para todas as versões.
2. Coloque a nova versão de um esquema em um novo local para evitar a quebra de documentos de instâncias antigas.
Suponha que uma nova versão de um XML Schema seja criada (usando o mesmo namespace, conforme descrito acima). E a nova versão simplesmente substitui a versão antiga. Ou seja, a nova versão tem o mesmo nome de arquivo e a mesma localização de URL que o esquema antigo. Dependendo dos tipos de alterações feitas, isso pode resultar em quebrar todos os documentos da instância que foram escritos de acordo com o Esquema antigo.
Recomendação 2: Para evitar a quebra de documentos de instância antiga, dê à nova versão do Esquema um nome de arquivo diferente ou um local de URL diferente ou ambos.
3. Lidar com a alteração ao modelo de conteúdo de um elemento.
Uma ocorrência comum ao criar uma nova versão de um Esquema XML é mudar o conteúdo de um elemento. (A expressão técnica é: "alterar o modelo de conteúdo de um elemento")
Por exemplo, em um esquema de versão 1, o elemento & lt; location> pode ter sido declarado como composto de & lt; lat> e & lt; lon> enquanto na versão 2 seu conteúdo pode ser & lt; x> e & lt; y>.
Suponha que um aplicativo receba um documento de instância que esteja em conformidade com a versão mais recente do Esquema. E suponhamos que o aplicativo ainda esteja codificado para a versão anterior do Esquema. O aplicativo analisa o documento da instância e chega, digamos, no elemento & lt; location>. Como o aplicativo reconhecerá que o modelo de conteúdo da localização mudou?
Seria útil se o aplicativo pudesse consultar o analisador: "Qual é o tipo (modelo de conteúdo) do & lt; location>?" Se o tipo não é um que ele espera, então o aplicativo deve decidir como proceder.
Como podemos facilitar um aplicativo ao reconhecer o tipo de um elemento? Ou seja, como habilitamos as aplicações para determinar o tipo de cada elemento que encontra? Resposta: o Esquema XML deve ser projetado para fornecer informações de tipo explícito.
Recomendação 3: Para facilitar um aplicativo ao reconhecer que o conteúdo de um elemento mudou, não use tipos anônimos. Em vez disso, use tipos nomeados.
Exemplo. Não projete seu Esquema como este:
Qual é o tipo de localização? Resposta: é anônimo. Este Esquema não foi projetado para facilitar um aplicativo na obtenção de informações de tipo.
Em vez disso, crie seu Esquema como este: qual é o tipo de localização? Resposta: o tipo nomeado, locationType-x_y_version. Assim, este Esquema é projetado para facilitar um aplicativo na obtenção de informações de tipo.
Suponha que um designer Schema siga a Recomendação 3 e use sempre tipos nomeados. Isso permitirá que os aplicativos consultem um analisador para informações de tipo, por exemplo, "Qual é o tipo de & lt; location>?" O analisador responderá com: "o tipo é locationType-x_y_version". Se este for um tipo que o aplicativo não esperava (ou seja, não foi codificado para entender), ele tomará as etapas apropriadas (conforme descrito acima).
Vamos continuar com o exemplo & lt; location>. Acima, vimos a motivação para usar tipos nomeados - permite que um aplicativo descubra facilmente o modelo de conteúdo de um elemento. Claro, se uma nova versão de um Esquema for criada e o tipo de & lt; location> for alterado, mas o novo tipo recebe o mesmo nome do tipo antigo, então ele derrota toda a finalidade do tipo de informação. Isso nos leva à próxima recomendação:
Recomendação 4: se você alterar um tipo quando você cria uma nova versão de um Esquema, então dê ao tipo um nome diferente.
Exemplo. Suponha que, na versão 1 Schema & lt; location> tenha como conteúdo: & lt; lat> e & lt; lon>. O Esquema declara este tipo nomeado:
Agora suponha que no esquema da versão 2 o conteúdo de & lt; location> seja alterado para & lt; x> e & lt; y>. É importante dar um novo nome para o tipo de localização:
Assim, se um aplicativo da versão 1 receber um documento de instância da versão 2, então, quando ele analisar o elemento & lt; location>, ele poderá reconhecer facilmente que o modelo de conteúdo do & lt; location> mudou (ele mudou de locationType para locationType-x_y_version).
3.b Localize as alterações de tipo.
Suponha que o elemento & lt; location> esteja aninhado dentro de um elemento & lt; aircraft>, por exemplo,
Tecnicamente, o conteúdo de & lt; aircraft> mudou desde que o conteúdo de & lt; location> mudou. O nome do tipo para & lt; aircraft> deve ser alterado? Resposta: não. A razão é que queremos minimizar as mudanças. Ou seja, queremos que um aplicativo veja tantos elementos e tipos familiares quanto possível. O tipo de avião é um tipo familiar. Ainda tem como conteúdo um elemento & lt; location>. Queremos preservar essa familiaridade.
Recomendação 5: mude o nome do tipo de elemento somente se o conteúdo imediato tiver mudado.
3.c Use um atributo de versão.
As aplicações acharão útil ter uma indicação de se pode esperar mudanças à medida que processa um documento de instância. Isso pode ser feito usando um atributo de versão no elemento raiz.
Note que isso é o que o XSLT faz. À medida que a tecnologia XSLT migrou para uma nova versão, documentos de instância (ou seja, documentos XSLT) indicam qual versão está sendo usada com um atributo de versão no elemento raiz.
Recomendação 6: use um atributo de versão no elemento raiz. Se um documento de instância for um documento composto - isto é, uma montagem de fragmentos XML -, então coloque um atributo de versão na raiz de cada fragmento.
4. Efeito dos elementos de baralhar.
Uma nova versão de um Esquema pode fazer uma mudança tão simples como reordenar o conteúdo de um elemento. Por exemplo, num esquema da versão 1, a ordem pode ser A, B, C, por exemplo,
No esquema da versão 2, a ordem pode ser alterada para B, C, A, por exemplo,
Se um aplicativo é codificado para esperar um certo pedido dos dados, a nova versão do Esquema irá quebrar o aplicativo. Para evitar isso, um aplicativo nunca deve depender de pedidos específicos de dados. Ele deve localizar os dados usando as tags.
Recomendação 7: os aplicativos devem usar os nomes das tags para localizar dados nos documentos da instância. As aplicações devem ser projetadas para antecipar que a ordem das tags pode mudar.
5. Efeito da remoção de um elemento ou atributo.
Criar uma nova versão de um esquema XML pode resultar na remoção de um elemento ou atributo. Considere um aplicativo que não foi atualizado para a nova versão e recebe um documento de instância que esteja em conformidade com a nova versão. O aplicativo deve decidir se a falta do elemento ou atributo é catastrófica ou se ele pode viver sem a informação. A ação adotada é específica da aplicação (e está fora do escopo deste documento).
6. Efeito de adicionar um elemento ou atributo.
Criar uma nova versão de um esquema XML pode resultar na adição de um elemento ou atributo. Considere um aplicativo que não foi atualizado para a nova versão e recebe um documento de instância que esteja em conformidade com a nova versão. O aplicativo deve decidir o que fazer com as informações adicionais. Novamente, o que é feito é específico da aplicação.
O que fazer quando um aplicativo é interrompido.
As recomendações acima ajudarão a mitigar a quebra devido a alterações do Esquema. No entanto, eles não garantem que os aplicativos não quebram. Um aplicativo antigo pode receber uma nova instância que está faltando informações cruciais, ou o modelo de conteúdo de um elemento crucial pode ter mudado para um tipo que não pode ser entendido dinamicamente.
Para antecipar tais ocorrências, será benéfico instituir um protocolo de sistema que especifique quais ações devem ser tomadas pelos aplicativos quando ocorre uma quebra. Um protocolo possível é para um aplicativo responder ao remetente com uma mensagem de falha.
Recomendação 8: Definir um protocolo de todo o sistema (por exemplo, mecanismo de relatório de falhas) para ser usado quando um aplicativo não conseguir processar um documento de instância que recebe de outro aplicativo.
Para minimizar o impacto nos documentos e aplicativos de instâncias existentes à medida que novas versões do XML Schemas são criadas, fazemos as seguintes recomendações:
Recomendação 1: Para evitar quebrar aplicativos compatíveis com o namespace com cada nova versão de um Esquema XML use o mesmo espaço de nome para todas as versões.
Recomendação 2: Para evitar a quebra de documentos de instância antiga, dê à nova versão do Esquema um nome de arquivo diferente ou um local de URL diferente ou ambos.
Recomendação 3: Para facilitar um aplicativo ao reconhecer que o conteúdo de um elemento mudou, não use tipos anônimos. Em vez disso, use tipos nomeados.
Recomendação 4: se você alterar um tipo quando você cria uma nova versão de um Esquema, então dê ao tipo um nome diferente.
Recomendação 5: mude o nome do tipo de elemento somente se o conteúdo imediato tiver mudado.
Recomendação 6: use um atributo de versão no elemento raiz. Se um documento de instância for um documento composto - isto é, uma montagem de fragmentos XML -, então coloque um atributo de versão na raiz de cada fragmento.
Recomendação 7: os aplicativos devem usar os nomes das tags para localizar dados nos documentos da instância. As aplicações devem ser projetadas para antecipar que a ordem das tags pode mudar.

Kyle Lieber.
algumas coisas pelas quais eu senti escrever.
Estratégia de versão do Maven.
Eu tenho tido muitas discussões com analistas da minha organização sobre como o software de versão usando Maven e I & rsquo; achar que há um equívoco comum sobre o que realmente significa SNAPSHOT. Eu estava procurando um bom blog para enviá-los que ajude a explicar o controle de versão em Maven, mas infelizmente tudo que eu encontrei apenas discute formatos de versão e não como usá-los como você está desenvolvendo um aplicativo. Então, eu decidi que eu tomaria uma facada nisso. Congratulo-me com quaisquer comentários e críticas construtivas que me ajudem a melhorar este documento, então fique à vontade.
Primeiro, um SNAPSHOT não é o mesmo que uma versão alpha / beta / etc. É uma palavra-chave especial que significa que é a versão mais recente do seu código. Isso significa que ele muda. Se você derrubou o someapp-1.0-SNAPSHOT ontem e então você tenta retirá-lo hoje, provavelmente não será o mesmo. Isso também significa que se você tiver um projeto dependente de uma versão do SNAPSHOT, o maven precisará verificar o repositório remoto para as mudanças sempre que você executar uma compilação.
A próxima coisa a entender é qual é a versão em Maven. Uma versão não significa que a versão esteja pronta para a produção. Isso significa que o desenvolvedor decidiu que ele está em um ponto em seu desenvolvimento que ele quer que o código seja bloqueado para que não seja perdido. Ele também pode querer distribuir esse código para alguém, talvez seja uma biblioteca, um desenvolvedor em outra equipe precisa começar seu próprio desenvolvimento de aplicativos ou talvez seja um aplicativo que será instalado em um ambiente de teste para testes. Então, isso significa que uma versão do maven pode ser um alfa, beta, candidato a liberação, patch, produção ou qualquer outra coisa que você deseja categorizar.
Faz sentido? Bem, talvez passar por um cenário de como eu lido com isso o ajudaria. Primeiro, olhe para a estratégia de versão que uso:
Estratégia de versão.
A sintaxe para esta estratégia é baseada no formato em Maven: The Complete Reference. As diferenças são I & rsquo; m rename & ldquo; incremental version & rdquo; para & ldquo; patch & rdquo; e quebra o opcional & ldquo; qualifier & rdquo; em & ldquo; type & rdquo; e uma & ldquo; tentativa & rdquo; simplesmente por clareza.
& lt; major & gt; - Este é um número que indica uma mudança significativa no aplicativo. Uma versão importante talvez seja uma reescrita completa da versão principal anterior e / ou quebra a compatibilidade com versões anteriores. & lt; minor & gt; - Este é um número que indica um pequeno conjunto de alterações da versão secundária anterior. Uma versão menor geralmente consiste em um conjunto uniforme de correções de bugs e novos recursos e deve sempre ser compatível com versões anteriores. & lt; patch & gt; - Este é um número que indica que foram corrigidos alguns erros que não podiam esperar até a próxima versão menor. Uma versão de patch só deve incluir correções de bugs e nunca incluir novos recursos. Também deve ser sempre compatível com versões anteriores. As correções de segurança são um exemplo de um patch típico. [& lt; type & gt; - & lt; tentativa & gt;] - Esta última parte é opcional e usada apenas para identificar que esta versão não é necessariamente estável. O tipo é uma palavra-chave e pode ser qualquer coisa, mas geralmente aderem a alpha, beta e RC. A tentativa é apenas um número para indicar qual tentativa desse tipo é essa. Então, por exemplo, beta-01, RC-02, RC-05, ect. Para uma versão estável, deixo essa parte, no entanto, eu vi outros projetos que gostam de usar a palavra-chave de RELEASE para indicar a versão estável (você deixa a tentativa, porque isso não faria sentido, use RC (lançamento candidato) para isso).
Exemplo Scenerio.
Então, agora, para o cenário. Deixe-nos dizer que eu estou trabalhando no aplicativo Foobar. Minha organização está esperando que eu entregue a versão 1.0 do foobar no final do trimestre. (Observe que eu digo 1,0, o que significa que eu só uso os dois primeiros números para se referir à versão. Isso ocorre porque a versão maior e menor são realmente as únicas versões em que qualquer pessoa se importará além do seu time de desenvolvimento. Além disso, não há caminho para eu saber qual será a versão final, mas eu sei que o maior e o menor permanecerão o mesmo.) Eu estou trabalhando em uma equipe ágil, então eu vou implantar tudo o que eu fiz no final de cada sprint para o meu ambiente de teste para que meus testadores possam validar tudo. Então, aqui é o que eu posso fazer:
Vou começar com a versão 1.0.0-SNAPSHOT no meu pom. xml no início do Sprint # 1. No final do Sprint # 1, vou usar o plugin maven-release para criar a versão foobar-1.0.0-RC-01 da aplicação Foobar. O plugin irá mudar a versão de 1.0.0-SNAPSHOT para 1.0.0-RC-01, marcar o código em scm com foobar-1.0.0-RC-01 e, finalmente, criar essa versão. Em seguida, o plugin irá atualizar o tronco para ser a próxima versão de desenvolvimento do aplicativo que iremos em 1.0.0-SNAPSHOT. Então eu vou implantar o foobar-1.0.0-RC-01 para o ambiente de teste. Este processo continuará para os próximos sprints até chegarmos a uma fase em que estamos a um ponto em que pensamos estar completo.
Então, deixe-nos dizer que estamos agora na Sprint # 5. Nós lançamos quatro versões de candidatura de lançamento do aplicativo, corrigindo erros e adicionando recursos ao longo do caminho. Agora nos sentimos foobar-1.0.0-RC-04 está pronto para uso em produção. Agora eu lanço o maven-release-plugin novamente para criar a versão foobar-1.0.0 do meu aplicativo. Mais uma vez, o plugin irá marcar a versão atual do código no scm com foobar-1.0.0 e, em seguida, construir essa versão. O plugin então atualizará o tronco para ser a próxima versão de desenvolvimento do aplicativo que desta vez eu escolho ser 1.1.0-INSTANTÂNEO.
Aviso, incremento a versão menor e não a versão do patch. Em um mundo perfeito, eu seria feito com a versão 1.0, mas é claro que isso não é um mundo perfeito e, provavelmente, I & rsquo; eu tenho que corrigir minha versão 1.0.0 em algum momento. Como eu não sei quando isso será, eu vou seguir com a vida e começar a trabalhar na próxima versão do aplicativo, 1.1.
Algumas semanas depois, minha equipe de QA me informa que um erro foi encontrado nos testes de lançamento que precisam ser corrigidos. O que vou fazer agora? I & rsquo; ve movido e tem novo 1.1 código no tronco que pode & rsquo; t entrar na versão 1.0. Sem preocupações, lembro que o plugin de lançamento marca cada um dos meus lançamentos para mim. Então, eu crio um ramo da tag foobar-1.0.0 e chama foobar-1.0.X. Em seguida, marquei o novo ramo e incremente a versão do patch para 1.0.1-SNAPSHOT. Este novo ramo é agora meu ramo de remendo. Eu corrigirei o bug relatado pela equipe de QA e use o plugin de lançamento para produzir a versão de patch foobar-1.0.1. Então, imediatamente depois de produzir foobar-1.0.1, mesclaremos as alterações 1.0.1 no tronco para que a correção esteja presente na versão 1.1 (que ainda não foi lançada).
Então respiro fundo e volto a trabalhar no 1.1. Se surgir outro erro, talvez, mesmo depois de sairmos à produção, vou continuar a voltar ao meu ramo de remendo foobar-1.0.X para fazer a correção e mesclar as mudanças de volta ao tronco.
Estratégia simplificada.
Eu não uso sempre a estratégia acima. Na verdade, muitas vezes eu uso o que eu chamaria de versão simplificada desta estratégia. Essencialmente, é a mesma coisa, exceto que eu removo o - & lt; type & gt; - & lt; tentativa & gt; completamente e em vez de um & lt; patch & gt; , Eu tenho um mais genérico & lt; incrementalVersion & gt; (assim como no livro maven). Então, parece assim:
Deixe o & rsquo; s voltar para o cenário de exemplo acima e compare a estratégia completa com esta estratégia simplificada:
Como você pode ver, a estratégia simplificada perde uma parte da verbosidade da estratégia completa que pode ser uma coisa boa e ruim. Não será óbvio se uma versão está pronta para a produção ou apenas um candidato a liberação. No entanto, isso significa que você não precisa testar o candidato de lançamento aceito duas vezes. Se você notou, a versão fornecida pela Sprint # 4 também é a versão de produção. Não há necessidade de reconstruí-lo apenas para remover o - RC-04.
Para uma equipe menor ou uma equipe que não tem realmente seus artefatos consumidos por muitas outras áreas, esta pode ser uma solução melhor porque há muito menos versões para gerenciar. Você só precisa se certificar de que está se comunicando claramente com sua equipe para que todos saibam o que está acontecendo.
Postagens recentes.
GitHub Repos.
Atualização do status. @klieber no GitHub.
Direitos autorais e cópia; 2018 Kyle Lieber - Licença - Desenvolvido pelo tema Hugo e Hugo-Octopress.

estratégia de versão Xml
Obter através da App Store Leia esta publicação em nosso aplicativo!
Quais são as melhores práticas para versões de esquemas XML?
Muitas vezes eu tenho que criar esquemas XML para diferentes rotinas de importação de bases XML. É claro que os esquemas XML irão evoluir ao longo do tempo ou podem conter bugs para serem corrigidos, por isso é importante capturar a versão do esquema e ter algum mecanismo para se ligar contra uma versão específica.
Atualmente eu tenho dois cenários:
O erro é encontrado dentro do esquema e todas as instâncias de esquema devem estar em conformidade com a versão fixa.
O esquema foi atualizado e deve ser considerado como preferível, mas um antigo também deve ser suportado.
Finalmente, criei informações de armazenamento de versão dentro do namespace do esquema:
Ao corrigir um bug, consertá-lo no mesmo espaço para nome, mas se estou prestes a atualizar um esquema, preciso criar um novo espaço para nome, mas com mês de atualização adicionado:
E se eu tiver mais de uma atualização em um mês, basta acrescentar um dia também:
Você conhece alguma abordagem melhor?
Este é um assunto tão difícil que nem sequer é engraçado, e um que eu passei anos oferecendo suporte de consultoria.
Existem muitas práticas recomendadas, mas a maioria delas não funciona em todas as situações. Por exemplo, muitos defendem o uso de "xsd: any" para permitir extensões, e essa é apenas uma receita para o desastre, se os desenvolvedores estiverem encarregados de manter o esquema, transformando-o em um despejo.
Aqui estão algumas dicas para você se você começar:
Não coloque um número de versão menor, número de versão micro, data ou qualquer outra coisa do tipo, em seu namespace. Toda vez que você mudar o espaço para nome, você quebrará todos os aplicativos de processamento. Coloque um atributo "versão" no documento de instância XML. Isso permitirá que um aplicativo de processamento ou um serviço de adaptador de versão descubra o que está processando. Especificar uma política do que constitui uma mudança compatível com versões anteriores, por exemplo: adicionar elementos opcionais não quebra os remetentes e não quebrará os receptores, se eles usam uma política de ignorar elementos que eles não conhecem (JAXB e XMLBeans podem ser configurados desta forma )

eBay Schema Versioning Strategy.
A partir de agosto de 2018, a versão mais baixa suportada é 863.
Este tópico descreve a estratégia de versão do eBay para a Trading API (e a API comercial), o que nos permite evoluir o esquema, mantendo a compatibilidade com versões anteriores por pelo menos 18 meses. Esta estratégia destina-se a resolver estas preocupações:
O eBay adiciona novos recursos a cada duas semanas. Se você atualizar seu software cliente menos freqüentemente, seu software precisa de uma maneira de lidar com dados não reconhecidos do eBay. Ao longo do tempo, torna-se mais difícil para o eBay suportar software de terceiros que esteja usando lógica ou recursos comerciais desatualizados. O eBay precisa de uma maneira de descartar o suporte para recursos desatualizados. Entendemos que pode ser difícil para você atualizar seu software em breve aviso. Para ajudá-lo, o eBay precisa manter o suporte para recursos desatualizados por algum período de tempo, e precisamos dar-lhe o maior conhecimento possível antes de parar completamente o suporte a um recurso.
Em cada versão, fazemos o nosso melhor para atualizar o esquema de uma maneira compatível com versões anteriores. No entanto, às vezes precisamos fazer alterações que não são compatíveis com versões anteriores:
À medida que as construções de esquema XML são digitadas, qualquer modificação que resultaria em uma mudança de tipo é uma incompatibilidade potencial. Como um exemplo muito simples, podemos atualmente expressar uma medida ou uma contagem em valores inteiros (xs: int), mas em um aprimoramento futuro, talvez precisemos de uma maneira de permitir frações decimais para o mesmo valor (xs: double). Se o seu aplicativo está esperando um campo para retornar um número inteiro no tempo de execução e começamos a retornar um duplo, sua aplicação pode falhar. Então, precisamos de uma maneira de evitar a mudança do tipo diretamente. Alterar a multiplicidade de um elemento também é uma incompatibilidade potencial. Por exemplo, podemos atualmente permitir um único campo de URL, mas em um aprimoramento futuro, podemos permitir campos de URL de repetição (maxOccurs = "ilimitado"). Como alguns kits de ferramentas interpretam campos repetitivos como arrays, isso seria equivalente a uma mudança de tipo.
Quando tais mudanças são necessárias, precisamos de uma forma de fase graciosa na nova abordagem e gradualmente eliminar o antigo. (Ou seja, precisamos fazer alterações sem que os aplicativos de terceiros falhem de forma inesperada e os aplicativos precisam ser projetados para acomodar as mudanças de rotina.) Esta abordagem é descrita abaixo.
Conceitos Básicos de Esquema.
Antes de ler este documento, você deve estar familiarizado com esses conceitos básicos.
Pontos chave da estratégia de versão.
Esta seção resume os pontos principais que você deve entender sobre nossa estratégia de controle de versão. Estes pontos são explicados em mais detalhes em seções posteriores.
Um objeto obsoleto é um objeto que não mais recomendamos. A versão do esquema quando ocorre esta desvalorização é a versão de desaprovação do objeto. Por exemplo, se depreciarmos um objeto chamado "Flavor" na versão 803 do esquema, a versão de desaprovação desse objeto era 803.
Sempre que depreciamos um objeto, também excluímos o objeto do esquema mais recente ao mesmo tempo (salvo indicação em contrário). Seu aplicativo não deve ser afetado por essas exclusões até você atualizar para uma versão mais recente do esquema. (Consulte o cronograma de desaprovação do objeto para uma lista de objetos anteriormente depreciados que foram excluídos do esquema.)
Controlamos o uso de um objeto depreciado com base na versão do pedido:
Se for um objeto de entrada, você só pode receber um aviso (independentemente da versão do pedido). Se for um objeto de saída, nós apenas o devolvemos com versões de solicitação que são mais baixas do que a versão de desaprovação (a menos que seja indicado). Veja o Exemplo de Depreção de Objeto abaixo para obter um exemplo de como isso funciona. Se foi obsoleto antes da versão suportada mais baixa (veja abaixo), não funcionará mais.
Nós incrementamos a menor versão suportada a cada 6 meses. A versão suportada mais baixa terá 18 meses de idade. Veja o Programa de Suporte de Versão do eBay.
Calendário de suporte de versão do eBay.
Em fevereiro e agosto de cada ano, o eBay incrementa a versão de esquema suportada mais baixa.
A tabela abaixo mostra o esquema de suporte da versão do esquema do eBay. A linha com texto em negrito indica a versão suportada mais baixa atual. As linhas com texto cinza indicam versões futuras que ainda não foram publicadas ou versões anteriores que não são mais suportadas.
Programação de suporte de versão (projetado)
Aqui está um exemplo de como interpretar a tabela:
A partir de fevereiro de 2018, a versão mais baixa suportada é 837. Em agosto de 2018, incrementamos a versão suportada mais baixa para 863. Se você atualizar para a versão 861, antes de agosto de 2018, você poderá usar 861 até agosto de 2018 (quando menor A versão suportada move para 863).
Veja como esta agenda irá afetar você:
Se o seu aplicativo estiver usando uma versão menor que a versão suportada mais baixa, você deve atualizar seu software para usar uma versão suportada. Você é encorajado a usar uma das versões mais recentes disponíveis. Se você estiver criando um novo aplicativo, é necessário usar a versão mais recente disponível.
Importante: uma vez que uma versão de esquema não é mais suportada, os objetos que foram obsoletos a partir dessa versão (ou anteriores) não são suportados, independentemente da versão do pedido.
Mudanças de esquema que afetam a compatibilidade.
eBay faz três tipos básicos de alterações no esquema:
Nós adicionamos novos objetos. Desobedecemos objetos existentes. Substituimos objetos existentes ou alteramos seu tipo.
Em muitos casos, essas alterações não afetarão seu aplicativo até você atualizar para um esquema mais recente. Os efeitos podem depender se o seu aplicativo passa a usar a funcionalidade que mudou e a versão do esquema que você está usando.
Fazemos o nosso melhor para mantê-lo informado das mudanças de esquema através da documentação do esquema, notas de versão, o Blog do Programa de Desenvolvedores eBay, o status do site e outros mecanismos.
Adição de novos objetos.
Podemos apresentar novos objetos a qualquer momento e em qualquer nível do esquema.
Geralmente, a versão do pedido não controla sua capacidade de usar novos elementos ou chamadas (a menos que seja indicado). Por exemplo, novos elementos de saída geralmente são retornados para todas as versões de solicitação. Nós adicionamos um xs: qualquer elemento ao final de cada tipo para expressar essa abertura. Por política, também tentamos adicionar elementos ao final de um tipo antes do xs: qualquer elemento. (Esta é apenas uma política, não é uma garantia.)
No entanto, a versão do pedido controla se retornamos novos valores de tipo de código (enumerações) nas respostas. Se o seu software já estiver usando um elemento que seja um tipo de código, você precisa de uma maneira segura de lidar com novos valores que o seu software ainda não reconhece. Portanto, verificamos a sua versão de solicitação e, em nossa resposta, mapeamos quaisquer valores de tipo de código mais novos para um valor padrão que você pode reconhecer (CustomCode). (Consulte Visão geral do Esquema da API para obter mais informações sobre tipos de código.)
Para compatibilidade com versões anteriores:
Você deve projetar seu software para poder manipular ou ignorar graciosamente elementos extras que adicionamos ao esquema. Por exemplo, a qualquer momento, as chamadas de API podem retornar novos elementos além disso, os declarados na versão do esquema que você está usando. Seu software também deve estar preparado para ver e manipular "CustomCode" (sem aspas) para os valores que adicionamos aos tipos de código nas versões mais recentes do que a sua versão de solicitação atual.
Desvalorização de Objetos Existentes.
Conforme mencionado anteriormente, um objeto obsoleto é um objeto que não mais recomendamos (embora ainda o possamos). Fazemos o nosso melhor para não depreciar objetos, mas às vezes torna-se necessário depreciar um objeto devido a problemas comerciais, legais ou funcionais. A versão do esquema quando ocorre esta desvalorização é a versão de desaprovação do objeto.
Aqui está o que acontece na API:
Quando depreciamos um objeto, o excluímos do esquema ao mesmo tempo. (Se o seu aplicativo já usa o objeto, você não deve ser afetado até você atualizar para a versão de desaprovação ou superior.) Quando incrementamos a versão de esquema suportada mais baixa, deixaremos o suporte para todos os objetos que foram obsoletos nas versões mais baixas. Veja o Programa de Suporte de Versão do eBay.
Aqui está o comportamento que você pode esperar:
Seu aplicativo não deve ser afetado por objetos recentemente excluídos, desde que você esteja usando boas práticas de codificação. Por exemplo, você não deve codificar um cheque para, digamos, "o elemento 20" na resposta. Para compatibilidade com versões anteriores, como você usa um objeto obsoleta depende se o objeto está na solicitação (entrada) ou na resposta (saída). A política na tabela abaixo pressupõe que a versão de desaprovação e sua versão de solicitação são ambas suportadas (ou seja, maior que a versão suportada mais baixa).
Veja Exemplo de desaprovação de objetos para um exemplo concreto, incluindo um diagrama.
Ao testar uma chamada, você pode configurar WarningLevel como Alto para identificar se você está usando objetos obsoletos em sua solicitação.
Substituições e alterações de tipo.
Às vezes, precisamos efetivamente mudar um objeto existente para um tipo diferente, ou substituir ou renomear um objeto. Em vez de substituir um objeto diretamente, costumamos usar as abordagens de adição e depreciação descritas acima. Ou seja, adicionamos um novo objeto com um nome diferente e depreciamos o objeto antigo.
Para compatibilidade com versões anteriores:
Trate o novo objeto como qualquer outro objeto novo. Ele estará disponível independentemente da versão do pedido (a menos que seja indicado). Veja a adição de novos objetos acima. Trate o objeto antigo como qualquer outro objeto obsoleto. Veja a Depreciação de Objetos Existentes acima.
O software cliente que depende do objeto antigo deve começar a usar (ou esperar) o novo o mais rápido possível. This is particularly important if the old object reflects functionality that is inconsistent with current eBay site logic. Otherwise, your application's users may see unexpected (and undesirable) behavior.
In some cases, we may change an existing object's behavior without replacing it. See Logical Changes That Affect Compatibility for an example. Again, we do our best to minimize these kinds of changes.
Object Deprecation Example.
Let's suppose eBay offers a new "flavor" feature, and then later enhances the feature in a way that isn't backward compatible.
This is how the schema and the object's usage might change in this case:
Logical Changes That Affect Compatibility.
Incompatible changes can be logical or functional; not necessarily changes to the schema itself. As with deprecated objects, we implement these kinds of changes based on the version whenever possible.
For example, suppose a call returns a node called ManyDetails :
In version 483, we always return ManyDetails . In version 503, we add a new IncludeManyDetails field to the request, and we set the default to false (so that ManyDetails is only returned when you specifically ask for it).
In this example, we are not deprecating ManyDetails or changing the schema in any way, but this change would break any application that specifically looks for ManyDetails and expects it to be returned by default. Therefore, we would implement this change so that only clients specifying request version 503 or higher would see the new behavior.
See the Version-Dependent Logical Changes table for a summary of objects that behave differently based on the request version.
Schema Versions and Requirements for Compatible Application Check.
To comply with eBay's requirements for Compatible Application Check, new applications must use the latest version that is available in the Production environment at the time of Compatible Application Check.
For example, suppose your application had a Compatible Application Check at version 525. If version 555 is the latest version available in production, then you can still use version 525 or higher .
On the other hand, suppose you submit a new request for a Compatible Application Check. If version 555 is the latest version available in production, you would need to use the latest version (555 in this example).
We increment the lowest supported version periodically. Make sure you understand how your application will be affected by these changes (see eBay's Version Support Schedule). Plan to start adjusting your application to use the latest version before we drop support for the version you are using. (You do not necessarily need to redo a Compatible Application Check for your application if you are only upgrading it to a newer version.)
Upgrading Applications to Support New Versions.
At a high level, we suggest you follow this process when you upgrade an application to a newer version of the schema:
Make sure the application uses no invalid objects or functionality. For example: For each call, remove dependencies on objects that have been deprecated for the version you are upgrading to. For each call, make sure the request only includes applicable and valid fields. For example, certain fields that are valid in AddItem calls may be invalid in ReviseItem calls. Use the Sandbox to test your application's compatibility with the new version. Make sure that all requests trigger no warnings or errors. Set WarningLevel to High to make sure no schema warnings are returned.
What is a Compatibility Level?
You may see some people use the older term "compatibility level" instead of "request version" in the Forums, KB articles, obsolete documentation, and other resources. The term is also used in the X-EBAY-API-COMPATIBILITY-LEVEL header, for XML requests. This is simply an older name for the request version.
Direitos autorais e cópia; 2005–2018 eBay, Inc. All rights reserved. This documentation and the API may only be used in accordance with the eBay Developers Program and API License Agreement.

Xml 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,770.
Direitos autorais e cópia; 2004 SYS-CON Media, Inc. — Todos os direitos reservados.
Histórias sindicadas e feeds de blog, todos os direitos reservados pelo autor.
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.
Clique neste link para ver como XML.
ADICIONE ESTA ALIMENTAÇÃO PARA O SEU LETRO DE NOTÍCIAS ONLINE.
Cloud Expo.
Toda a Cloud está na Cloud Expo!
Containers - Microservices - WebRTC - DevOps.
Junte-se ao Centro Javits em Nova York, NY, 6-8 de junho.
• Dados importantes | Analítica.
• Internet das Coisas.
Registrar agora!
Salve em seu "Passe de Ouro"! Ligue para 201.802.3020.
Ou clique aqui para registrar.
Envie sua proposta de fala para a próxima Cloud Expo em Nova York.
Ligue para 201.802.3021.
eventos (em) sys-con.
carmen (at) sys-con.
Todos os direitos reservados. Todas as marcas são marcas registradas da Ulitzer, Inc.
É proibida a reprodução total ou parcial de qualquer forma ou meio sem autorização expressa por escrito da Ulitzer, Inc.