Versão do Serviço SOA - Melhores Práticas.
Sumário executivo.
Este documento tem como objetivo destacar algumas das melhores práticas relacionadas ao Service Versioning em SOA. Essas melhores práticas são baseadas em problemas práticos que Torry Harris enfrentou ao implementar projetos SOA.
O controle de versão é um dos aspectos importantes da Governança SOA. Poucas estratégias de governança recomendam uma versão basilizada do serviço para evitar a complexidade do controle de versão. Por outro lado, poucas outras estratégias de governança preferem usar múltiplas versões do mesmo serviço para que mudanças e melhorias na interface de serviço não afetem os consumidores existentes. Este documento visa destacar os prós e os contras de cada abordagem e propõe melhores práticas que atendam os dois casos.
A solução técnica real para a implementação do controle de versão do serviço é considerada fora do escopo deste documento, pois existem várias abordagens simples e específicas para o fornecedor. O foco deste documento é descrever o princípio do controle de serviço e destacar as melhores práticas.
Por que o Versioning?
Visão geral do controle de versão do serviço.
Service Versioning é a abordagem seguida pelos desenvolvedores de serviços para permitir que várias versões do mesmo serviço estejam operacionais ao mesmo tempo. Para dar uma analogia, qualquer biblioteca de API de software reutilizável possui várias versões usadas por diferentes aplicativos. A mesma analogia se aplica aos serviços.
Exemplo de versão de versão do serviço.
Os serviços da Web são a maneira ideal de implementar serviços SOA. O diagrama a seguir ilustra o conceito de múltiplas versões ativas com visão dos serviços e a dependência com suas aplicações de consumo. No exemplo, existem dois serviços: Serviço de Processador de Pedidos e Serviço de Consulta de Estoque. Existem várias versões ativas para ambos os serviços. O diagrama mostra o caminho de dependência de 7 diferentes aplicativos usando várias versões desses dois serviços.
Prós e contras.
Alterações e aprimoramentos podem ser feitos em serviços individuais e lançados como novas versões sem causar impacto nas aplicações de consumo existentes.
Como mostrado no diagrama acima, várias versões podem levar rapidamente a muitos problemas de gerenciamento de dependência, aumentando assim com.
Em uma empresa, as aplicações do consumidor normalmente seriam desenvolvidas e mantidas por equipes diferentes. O múltiplo controle de versão oferece flexibilidade para a equipe priorizar e migrar para a versão mais recente de acordo com sua agenda e orçamento convenientes.
Qualquer bug-correção / erro descoberto em um ponto posterior dos serviços precisaria de uma correção adequada em todas as versões aplicáveis do serviço. Isso, eventualmente, leva à má manutenção do código de serviço.
Há sempre um plano de reversão fácil no lugar quando um aplicativo enfrenta um problema com a nova versão. Pode continuar a interagir com uma versão estável anterior.
A solução personalizada precisaria ser seguida na maioria dos casos, exigindo a manutenção de várias cópias versionadas do WSDL e do esquema.
É necessária uma ferramenta adicional / registro de tempo de execução para buscar o URL do ponto final adequado com base no número da versão.
O código fonte dos serviços precisaria ser cuidadosamente controlado usando ramificação para que múltiplas versões de binários sejam geradas e mantidas adequadamente.
Baselined Services - No Versioning.
Visão geral dos serviços de Baselined.
O conceito de Baselined Services desencoraja o uso do controle de versão. Apenas uma versão finalizada do Serviço é mantida ativa em qualquer ponto do tempo, e todos os aplicativos de consumo apontam para uma e única versão do serviço, que é a versão em baseline.
Exemplo de serviços de Baselined.
O exemplo a seguir (adaptado do anterior) ilustra o conceito de serviços basilíngüe.
Prós e contras.
A Plataforma de Serviços representa uma visão única do portfólio de serviços corporativos, garantindo assim a "reutilização" em seu verdadeiro sentido.
Esta política é "muito rígida" em várias equipes de consumidores de aplicativos, onde, em todas as mudanças / aprimoramentos no serviço, seria necessário um pouco de trabalho de migração dentro do aplicativo.
A manutenção é bastante simplificada.
O design do serviço precisaria ser considerado com muito cuidado, garantindo compatibilidade com a frente e para trás. Isso pode ser um fator limitante, em alguns casos, para que as equipes de negócios planejem aprimoramentos importantes do serviço.
Não é necessário um registro de tempo de execução, pois os aplicativos de consumo mantêm um URL de ponto final fixo.
O procedimento de análise de impacto deve ser fortalecido para que as mudanças sejam implementadas com grande precisão.
O gerenciamento de código-fonte dos serviços é bastante simplificado, pois existe apenas uma versão para manter.
Desdobramentos de implantação ao vivo devem ser planejados cuidadosamente para que haja um impacto mínimo na aplicação do consumidor.
Melhores práticas.
Tendo descrito ambas as abordagens, e os seus prós / contras listados, torna-se muito difícil para as empresas escolherem uma abordagem específica. Os profissionais da abordagem de serviços versionados parecem ser ideais em comparação com os contras da abordagem de serviços de base. Assim, as recomendações de melhores práticas para a estratégia de governança de versão são.
Use um mix-and-match de ambos os mundos seguindo a abordagem de serviços versionados, ainda tendo controle sobre os pesadelos de versão limitando as versões ativas máximas para 3 Ao iniciar uma nova versão do serviço, somente os dois últimos continuam a permanecer ativos. Todas as versões mais baixas devem ser obsoletas e desarmadas. Isso significa que não existem mais de três versões ativas de um serviço em qualquer ponto do tempo. As políticas precisam ser estabelecidas e comunicadas às equipes de aplicativos do consumidor para garantir que a migração seja feita a tempo. A equipe de serviços não será responsável por impactos no aplicativo do consumidor se o aplicativo continuar usando uma versão obsoleta do serviço.
Versão de serviços da Web.
por Gabriel Bechara.
Introdução.
Os serviços da Web são obrigados a mudar e evoluir ao longo do tempo. Os princípios de acoplamento solto da arquitetura orientada a serviços (SOA) implicam que os provedores de serviços podem lançar uma nova versão de um serviço compartilhado sem esperar que os consumidores se adaptem e que os consumidores do serviço devem testar e certificar em uma nova versão do serviço compartilhado antes de mudar. Consequentemente, talvez seja necessário que várias versões de um serviço compartilhado sejam executadas ao mesmo tempo e simultaneamente acessíveis por diferentes consumidores de serviços. Alguns consumidores de serviços podem precisar continuar usando uma versão antiga de um serviço até a migração do código do consumidor ocorrer. Portanto, o controle de serviços da Web é um assunto importante que deve ser considerado cuidadosamente em todas as abordagens SOA da empresa.
Os padrões atuais para serviços da Web não possuem suporte explícito para versões, exigindo arquitetos e desenvolvedores para resolver o problema através da aplicação de padrões. Este artigo:
Identifique os tipos de mudanças que podem ocorrer nos serviços.
No final deste artigo, você deve ter uma boa compreensão dos principais aspectos que devem ser tratados ao construir sua própria estratégia de controle de serviços da empresa.
Tipos de mudanças.
Uma mudança na implementação de um serviço da Web pode afetar seus consumidores, dependendo de vários fatores:
Uma alteração nos parâmetros de operação de um serviço da Web. Isso pode envolver a adição de novos parâmetros (isso afetará os consumidores atuais) ou uma alteração nos parâmetros existentes, como uma alteração em um documento XML que pode ser usado como um parâmetro de mensagem em um serviço da Web. As alterações em um documento XML podem envolver a adição de elementos ou atributos opcionais (isso pode afetar os consumidores atuais) ou de elementos obrigatórios (isso afetará os consumidores atuais).
Portanto, uma tipologia de mudanças nos serviços da Web pode ser criada em relação ao impacto nos consumidores atuais desses serviços. Uma abordagem é qualificar uma mudança que não afetará os consumidores atuais como uma versão menor e uma mudança que afetará os consumidores atuais como uma versão importante.
Menor lançamento.
Uma versão menor pode ser um dos dois tipos. A primeira é uma correção de um bug ou um aprimoramento de desempenho. Esse tipo não afetará o WSDL (Web Services Description Language) do serviço da Web. O segundo tipo consiste em adicionar novos métodos a um serviço da Web, onde o WSDL é alterado sem impacto nos consumidores de serviços. Uma distinção pode ser feita entre esses dois tipos ao rotular essas versões. Por exemplo, para o primeiro tipo, você pode alterar a segunda casa decimal do número da versão (1.0X), enquanto que para o segundo tipo você altera a primeira casa decimal do número da versão (1.Y0).
Major Release.
Um lançamento importante envolve uma mudança que quebrará a compatibilidade com versões anteriores. Neste caso, os consumidores devem ser modificados. Um lançamento que afeta somente as funcionalidades de um serviço da Web, sem afetar o WSDL, também é considerado uma versão importante. Isso ocorre porque os consumidores atuais não podem invocar a nova versão sem considerar as funcionalidades modificadas do serviço da Web. Agora que identificamos os vários tipos de mudanças e seu impacto nos consumidores atuais, vamos dar uma olhada em padrões diferentes para o controle de versão de serviços da Web.
Os padrões.
Padrão de consolidação do consumidor.
Quando uma nova versão de um serviço da Web é lançada - seja uma versão maior ou menor - os consumidores são notificados sobre a mudança e são responsáveis por mudar o código para acessar a nova versão. O novo WSDL é publicado - em um registro UDDI, por exemplo - e uma notificação é enviada aos consumidores para que eles possam encontrar o novo serviço e estabelecer vinculação com o novo provedor de serviços. Uma prática para usar um registro UDDI envolve a associação de uma determinada versão de um tipo de porta a um tModel exclusivo. Um WSDL está associado a um tModel. Este tModel deve conter uma referência ao número da versão para uma versão principal porque duas versões principais implicarão dois WSDLs diferentes. O tModel pode conter uma referência à versão secundária se duas versões menores precisam ser acessadas ao mesmo tempo. Um consumidor desse portType / version poderia fazer uma pesquisa UDDI de páginas verdes para serviços que anunciam conformidade associando-se ao tModel da versão correspondente.
Este método pode impor mudanças no código do consumidor, pelo menos na pesquisa realizada no registro para acessar uma versão (maior ou menor) de um serviço, mesmo para lançamentos menores. E se você precisar ter duas versões menores executando ao mesmo tempo? Por exemplo, você pode querer implantar uma nova versão menor em um site de teste para ser usada por um número limitado de consumidores, mantendo a versão antiga para o resto. Os consumidores do serviço implantado no site de teste precisarão mudar o ponto final do serviço, mesmo que o WSDL não seja modificado (porque é uma versão menor). Neste caso específico, pode ser útil ter uma camada de indireção entre os consumidores e os provedores, para impulsionar a migração de diferentes consumidores de forma graciosa.
Figura 1. Padrão de ligação ao consumidor.
Nota: O padrão de vinculação do consumidor não implica o uso de UDDI; refere-se ao fato de que a decisão vinculativa é feita pelo lado do consumidor. Vamos discutir os usos interessantes deste padrão em um momento.
Padrão de camada de indutor.
Quando uma nova versão menor de um serviço da Web é lançada, o consumidor pode migrar de forma transparente para a nova versão. Essa capacidade é fornecida pela camada de indireção através de um mecanismo de roteamento que garante roteamento baseado em conteúdo ou roteamento baseado em usuário (com base no IP do solicitante, por exemplo, ou no principal do solicitante na propagação de funções de segurança) para chamar as diferentes versões de um serviço da Web.
O uso de uma camada de indireção permite que duas liberações menores coexistam sem alterar o código dos consumidores e ajuda a garantir uma migração graciosa para uma nova versão.
Figura 2. Camada do Padrão de Indireccional.
Mas no caso de uma versão importante, os consumidores precisarão mudar seu código. E se, por algum motivo organizacional, precisamos migrar para uma nova versão importante sem alterar o código atual dos consumidores, chamando o novo serviço com o cliente antigo? Isso pode acontecer se, por exemplo, algum motivo regulatório implique uma mudança acessível apenas através do uso da nova versão principal de um serviço, fornecida por um parceiro comercial externo à sua organização. Isso leva a usar um adaptador para permitir o uso de uma nova versão principal para consumidores atuais até que todo o código dos consumidores seja modificado.
Padrão do Adaptador.
O padrão do adaptador consiste em adaptar a solicitação e a resposta do cliente para poder consumir uma nova versão importante de um serviço. O uso deste padrão oferece uma migração mais suave, no caso de o uso de uma nova versão principal de um serviço ser obrigatório por algum motivo comercial, regulamentar ou organizacional.
Figura 3. Padrão do Adaptador.
Soluções para a aplicação dos padrões.
Os diferentes padrões podem ser aplicados de diferentes maneiras. Isso pode ser feito no código dos consumidores, mas isso raramente é o caso porque pode causar atrasos de codificação e aumentar a complexidade do código que gerencia o controle de versão. Uma alternativa é usar uma camada de mediação para desacoplar o consumidor do provedor e aplicar esses padrões na camada de mediação. O uso do Oracle Service Bus como camada de mediação fornecerá as funcionalidades do padrão Layer of Indirection associado ao Pattern Adapter, aliviando o código dos consumidores dessas preocupações. Veja a Figura 4.
Figura 4. Aplicando os padrões usando o Oracle Service Bus.
A utilização desta abordagem baseada no Oracle Service Bus oferece estas vantagens:
Uma mudança de lançamento menor pode ser abordada sem modificar os consumidores, e os sites de teste podem ser abordados através de roteamento baseado em conteúdo ou baseado em usuário.
A mediação no Oracle Service Bus é configurada principalmente usando proxies para acessar serviços empresariais. No meio há pipelines, consistindo em estágios, ações, ramos e nós de roteamento. A mensagem é adaptada dentro dessas encanamentos, roteando as solicitações nos nós de roteamento. A configuração dos proxies e dos serviços empresariais pode ser organizada com referência aos números de versão. Os proxies no Oracle Service Bus podem incluir no seu caminho uma referência ao lançamento principal e o serviço comercial pode incluir a versão maior e menor. Por exemplo, para um importante v1.XX, teremos um proxy, um ou mais serviços empresariais (um por lançamento menor) e um WSDL:
. e para o V2.XX principal:
Nota: Como os proxies eo WSDL são os mesmos para versões menores, o caminho que contém esses não precisa incluir uma referência à versão menor.
Nós abordamos o acesso a diferentes serviços através do Oracle Service Bus. Mas há outras questões a serem tratadas, como a implantação de duas versões diferentes de um provedor de serviços provenientes do mesmo ambiente de desenvolvimento. Esses serviços podem ter o mesmo caminho de contexto do módulo da Web Java Platform, Enterprise Edition (Java EE), porque eles podem ter sido desenvolvidos usando as mesmas ferramentas de desenvolvimento. Portanto, a menos que você forneça um script de compilação que adicione referência de versão no contexto do módulo Java EE Web, você pode querer considerar a implantação de diferentes versões do mesmo serviço em diferentes destinos. (Um alvo é um cluster ou um servidor gerenciado). Veja a Figura 5.
Figura 5. Implantando fornecedores de serviços em diferentes destinos.
Nota: algumas estruturas e ferramentas de desenvolvimento, incluindo o Oracle JDeveloper, automatizam a versão de alguns provedores de serviços. Essa capacidade foi estendida no Oracle JDeveloper 11 Technical Preview 4 para lidar com a versão de componentes de arquitetura de componentes de serviço (SCA) (vários serviços em um composto).
Serviços de apresentação e serviços de orquestração (serviços de processos de negócios) beneficiarão da transparência desta abordagem ao consumir outros serviços pertencentes à camada de serviços empresariais ou à camada de serviços de acesso a dados. Mas e os consumidores de serviços de apresentação? Um portal composto pode consumir serviços de apresentação usando Web Services para Portlets Remotos (WSRP) para consumir portlets remotos. O padrão Layer of Indirection, juntamente com o Adapter Pattern usando o Oracle Service Bus, também pode ser aplicado neste caso, mas podemos usar uma abordagem mais adaptada com base nas capacidades do portal. Os portais geralmente vêm com ferramentas de administração para configurar o acesso a portlets (serviços de apresentação reutilizáveis). O uso das regras e direitos baseados em funções dos usuários para exibir alguma parte do portal composto, dependendo das propriedades do usuário, pode ser mais apropriado para os serviços de apresentação. Isso é mais uma preocupação com um mecanismo de portal composto do que com o Oracle Service Bus.
Portanto, o controle de camada de serviços de apresentação é melhor acomodado usando o padrão de consolidação do consumidor. Nesse contexto, o padrão não é aplicado usando um registro UDDI para escolher o serviço. Neste caso, a aplicação deste padrão depende dos direitos ou do mecanismo de personalização fornecido pelo portal composto. Um aspecto importante deste uso específico deste padrão é que a escolha da versão é feita através da configuração, na ferramenta de administração do portal. Assim, não implicará qualquer modificação ou manutenção de código.
A figura abaixo mostra como um portal composto pode consumir portlets através do WSRP em diferentes versões do mesmo aplicativo. A seleção da versão do portlet a ser exposta é feita no mecanismo do portal composto.
Figura 6. O Padrão de Encadernação do Consumidor aplicado aos serviços de apresentação.
Isso permite que duas versões do mesmo aplicativo sejam executadas simultaneamente, expondo novas funcionalidades somente para usuários finais selecionados com base em atributos de perfil de usuário.
Conclusão.
O controle de versão dos serviços da Web pode ser gerenciado de várias maneiras, dependendo das restrições comerciais e da camada a que o serviço pertence. Neste artigo, abordamos práticas que podem ser aplicadas a uma variedade de tarefas de controle de versão:
Acessando e implantando várias versões de um provedor de serviços ao mesmo tempo.
Alguns fatores adicionais devem ser levados em consideração, incluindo o controle de XML Schemas e o gerenciamento de dependências entre serviços e os esquemas XML usados por esses serviços. No nível organizacional, isso se tornará muito difícil de lidar sem as ferramentas adequadas para gerenciar dependências e para dirigir as mudanças de forma adequada e holística.
Gabriel Bechara trabalhou com pré-vendas e serviços de consultoria Oracle-BEA desde 2003. Um veterano de 15 anos da indústria de software, Gabriel atuou como arquiteto e assessor em grandes projetos, proporcionando experiência prática e feedback sobre conceitos que podem constituir uma base para construindo novos sistemas de informação. Seus interesses incluem metodologias para a definição de software e arquiteturas empresariais, com foco em integração empresarial e SOA.
Fundamentos de versão do contrato de serviço da Web Parte II: Identificadores de versão e estratégias de versão.
Junte-se à comunidade DZone e obtenha a experiência dos membros completos.
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 & amp; 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. Leia a parte I 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.
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", "quot; usa números de versão para comunicar o esforço que entrou 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.
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-o a qualquer elemento que você definir (caso em que não é necessário nomear o atributo & quot; versão & quot;).
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.
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.
Nota: Todas as três estratégias serão referenciadas nos próximos capítulos à medida que exploramos a forma como o controle de versão pode ser realizado com os idiomas WSDL, XML Schema e WS-Policy.
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.
Este artigo foi originalmente publicado na Revista SOA (soamag), uma publicação oficialmente associada à "The Prentice Hall Service-Oriented Computing Series" de Thomas Erl & quot; (soabooks). Copyright e cópia; SOA Systems Inc. (soasystems)
A Zona de Integração é orgulhosamente patrocinada pela CA Technologies. Aprenda com microservices especializados e apresentações de API na série Modern Summit Application Architectures Virtual Summit.
Como esse artigo? Leia mais do DZone.
Free DZone Refcard.
RESTful API Lifecycle Management.
Publicado em DZone com permissão de Nitin Bharti. Veja o artigo original aqui.
As opiniões expressas pelos contribuidores da DZone são próprias.
SOAPatterns.
Formulário de contribuição Formulário de candidatura.
Versão Canonical (Erl)
Como os contratos de serviços dentro do mesmo inventário de serviços podem ser versionados com impacto mínimo?
Os contratos de serviços dentro do mesmo inventário de serviços que são versionados de forma diferente causarão inúmeros problemas de interoperabilidade e governança.
As regras de versão de contrato de serviço e a expressão de informações de versão são padronizadas dentro de um limite de estoque de serviços.
Aplicação.
São necessários padrões de governança e design para assegurar o controle de versão consistente dos contratos de serviços dentro do limite do inventário.
A criação e aplicação dos padrões de versão necessários introduzem novas demandas de governança.
Princípios.
Arquitetura.
Quando os serviços são versionados de acordo com a mesma estratégia abrangente, eles podem manter sua padronização e interoperabilidade originais e são mais facilmente compreendidos pelos designers de consumo.
Padrões relacionados neste Catálogo.
Objetivos de computação orientados para serviços relacionados.
Esta página contém excertos de:
Prefácio de Grady Booch.
Com contribuições de David Chappell, Jason Hogg, Anish Karmarkar, Mark Little, David Orchard, Satadru Roy, Thomas Rischbeck, Arnaud Simon, Clemens Utschig, Dennis Wisnosky e outros.
(ISBN: 0136135161, Hardcover, Full-Color, 400+ Ilustrações, 865 páginas)
Para mais informações sobre este livro, visite o servicetechbooks.
Esta página contém excertos de:
por Thomas Erl, Anish Karmarkar, Priscilla Walmsley, Hugo Haas, Umit Yalcinalp, Canyang Kevin Liu, David Orchard, Andre Tost, James Pasley.
Prefácio de David Chappell.
Com contribuições de David Chappell, Jason Hogg, Anish Karmarkar, Mark Little, David Orchard, Satadru Roy, Thomas Rischbeck, Arnaud Simon, Clemens Utschig, Dennis Wisnosky e outros.
Para mais informações sobre este livro, visite o servicetechbooks.
Arcitura e comércio; A Education Inc. é uma provedora global líder de programas de treinamento e certificação progressivos, neutros para o fornecedor. Com uma rede mundial de treinadores certificados, parceiros de treinamento e centros de testes, Arcitura e comércio; escolas e programas de credenciamento tornaram-se internacionalmente estabelecidos e comprovados através de uma série de livros publicados, documentos e indústria em andamento.
