Serviços Web Seguros, Confiáveis e Transacionados: Arquitetura e Composição

 

Setembro de 2003

IBM Corporation Donald F. Ferguson   IBM Fellow and Chairman  IBM Software Group Architecture Board Tony Storey  IBM Fellow

da Microsoft Corporation   Brad Lovering  Engenheiro diferenciado    John Shewchuk  Arquiteto de Serviços Web

Conteúdo

Introdução à 1.0
   1.1 Serviços Composable
   1.2 Um exemplo de composição na prática
2.0 Serviços Web: Uma arquitetura de Service-Oriented
   2.1 Os serviços são descritos por esquema e contrato não tipo
   2.2 Compatibilidade de serviço é mais do que compatibilidade de tipo
   2.3 Orientação de serviço pressupõe que coisas ruins podem e acontecerão
   2.4 Orientação de serviço permite associação flexível de serviços
3.0 Funções e Especificações do Serviço Web
   3.1 Uma abordagem composable para serviços Web
   3.2 O Básico – Transportes e Mensagens
      3.2.1 Transportes – HTTP, HTTP/S, SMTP
      3.2.2 Formatos de mensagem – XSD
      3.2.3 WS-Addressing
   Descrição 3.3
      3.3.1 WSDL
      3.3.2 WS-Policy
      3.3.3 Obtendo descrições
      3.3.4 WS-MetadataExchange
      3.3.5 UDDI
   3.4 Garantias de Serviço
   3.5 Segurança
      3.5.1 WS-Security
      3.5.2 WS-Trust
      3.5.3 WS-SecureConversation
      3.5.4 WS-Federation
   3.6 Reliable Messaging
      3.6.1 WS-ReliableMessaging
   3.7 Transações
      3.7.1 WS-Coordination
      3.7.2 WS-AtomicTransaction
      3.7.3 WS-BusinessActivity
   3.8 Composição de Serviço
      3.8.1 BPEL4WS
4.0 Serviços Web na Prática – Um exemplo
   4.1 Parte 1: a experiência do cliente
   4.2 Parte 2: a experiência do fornecedor
5.0 Conclusões
6.0 Confirmações

Introdução à 1.0

Hoje, os serviços Web , especificamente serviços distribuídos que processam mensagens SOAP codificadas em XML, enviados por HTTP e descritos usando a Linguagem de Descrição dos Serviços Web (WSDL) estão sendo implantados amplamente. (Os termos XML, SOAP e HTTP estão em uso comum hoje e, em muitos aspectos, seu uso foi além de seus acrônimos originais. Para fins de integridade, esses acrônimos estão listados aqui: XML — linguagem de marcação eXtensible, SOAP — Protocolo de Acesso a Objetos Simples e HTTP — Protocolo de Transferência de HiperTexto.) Os serviços Web são usados em uma variedade de cenários de integração de aplicativos: desde simples, ad hoc, por trás do firewall, compartilhamento de dados até varejo de Internet em grande escala e negociação de moeda. E cada vez mais os serviços Web estão sendo aplicados em cenários móveis, de dispositivos e de grade.

Os serviços Web fornecem interoperabilidade entre componentes de software que podem se comunicar entre diferentes empresas e podem residir em diferentes infraestruturas. Isso resolve um dos problemas mais críticos que clientes, desenvolvedores de software e parceiros enfrentam. HTTP e SOAP fornecem interoperabilidade de comunicação e mensagem. O WSDL fornece a descrição do serviço para dar suporte à interoperabilidade entre ferramentas de desenvolvimento; ele complementa a interoperabilidade de comunicação com a capacidade de trocar definições de interface.

O conjunto básico de especificações de serviço Web permite que clientes e fornecedores de software resolvam problemas importantes. Com base em seu sucesso, muitos desenvolvedores e empresas estão prontos para enfrentar problemas mais difíceis com a tecnologia de serviço Web. O sucesso dos serviços Web levou os desenvolvedores a desejar ainda mais recursos dos serviços Web. Como a interoperabilidade significativa de ferramentas e comunicações foi bem-sucedida, os desenvolvedores agora esperam que as funções aprimoradas interoperem.

Além da interoperabilidade básica de mensagens e da troca de interfaces, os desenvolvedores exigem cada vez mais que os serviços de aplicativos de nível superior interoperem. Muitos aplicativos comerciais são executados em um ambiente ("middleware" ou "sistemas operacionais") que fornecem suporte para funções como segurança e transações.

A IBM, a Microsoft e outras pessoas do setor geralmente são solicitadas a tornar os serviços Web mais seguros, mais confiáveis e mais capazes de dar suporte a transações. Além disso, é solicitado que forneçamos esses recursos, mantendo a simplicidade e a interoperabilidade essenciais encontradas nos serviços Web atualmente.

Este artigo fornece uma visão geral sucinta para o conjunto de especificações de serviço Web que atende a essas necessidades. Para obter os detalhes das especificações, fornecemos referências aos documentos reais. A principal finalidade deste artigo é definir brevemente o valor que essas especificações fornecem aos nossos clientes. Também descrevemos como essas especificações se complementam para compor ambientes robustos para aplicativos distribuídos.

Enfrentamos um grande desafio de engenharia: como damos aos serviços Web novos recursos de segurança, confiabilidade e transação sem adicionar mais complexidade do que o necessário?

1.1 Serviços Composable

Como fizemos com soap e WSDL, IBM, Microsoft e nossos parceiros seguiram o princípio de design de de capacidade de composição na definição de especificações de serviço Web. A abordagem que seguimos baseia-se no princípio de design de de composição na definição de especificações de serviço Web. Cada especificação que desenvolvemos resolve uma necessidade imediata e é valiosa por si só. Por exemplo, os desenvolvedores podem adotar mensagens confiáveis para simplificar o desenvolvimento de soluções ou adotar BPEL4WS para definir suas composições de serviço. E enquanto cada especificação está por conta própria, elas são projetadas para serem combinadas e trabalharem entre si.

Usamos o termo de capacidade de composição para descrever especificações independentes que podem ser combinadas para fornecer recursos mais avançados. Provedores de sistema operacional e middleware podem dar suporte a recursos compostos, por exemplo, os provedores podem integrar o suporte de mensagens confiáveis para comunicação BPEL4WS processos. Este exemplo combina duas especificações independentes para simplificar o desenvolvimento de processos de comunicação eliminando a necessidade de lidar com erros de comunicação de mensagem durante o design do processo.

A capacidade de composição permite consumo incremental ou de descoberta progressiva de novos conceitos, ferramentas e serviços. Os desenvolvedores só precisam aprender e implementar o que é necessário e não mais. A complexidade da solução só aumenta porque os requisitos do problema aumentam e não se deve ao "bloat" da tecnologia.

A composição tem e continua sendo uma das principais metas de design para serviços Web. Nos últimos anos, definimos as especificações de serviço Web mais básicas (SOAP e WSDL) para dar suporte inerente à composição. Uma das características fundamentais de um serviço Web é uma estrutura de mensagens regular de várias partes. Essa estrutura habilita o de composição de novas funcionalidades. Novos elementos de mensagem que dão suporte a novos serviços podem ser adicionados a mensagens de uma maneira que não altere o processamento da funcionalidade existente. Por exemplo, é possível adicionar independentemente identificadores de transação e números de sequência de mensagens confiáveis. As duas extensões não entram em conflito entre si e são compatíveis com estruturas de mensagens pré-existentes.

Figura 1. A composição permite o uso de elementos conforme necessário.

A Figura 1 mostra uma mensagem de serviços Web simples que contém elementos para de endereçamento WS, WS-Security e WS-ReliableMessaging. Observe que os elementos WS-Addressing, WS-Security e WS-ReliableMessaging são independentes e esses elementos podem ser usados independentemente sem alterar o processamento de outros elementos.

Essa característica permite que a segurança, a confiabilidade e as transações sejam definidas em termos de elementos de mensagem composáveis.

A noção de composição também permite a criação de um conjunto específico de serviços Web bem definidos que dão suporte à segurança, confiabilidade etc. Esses serviços bem definidos especificam o comportamento dos serviços necessários para dar suporte à funcionalidade de serviço Web de nível superior. Um exemplo é o Serviço de Token Seguro definido em WS-Trust que emite e valida elementos de segurança em mensagens.

Além disso, é importante que os consumidores de um serviço possam determinar as garantias de serviço compatíveis e necessárias. Os serviços devem documentar seus requisitos e suporte para transações, segurança, mensagens confiáveis etc. WS-Policy permite que os serviços Web aumentem incrementalmente seu WSDL para documentar quais funções de transação, segurança e confiabilidade dão suporte ou exigem. O WSDL e o WS-Policy habilitar a composição para a descrição dos serviços. Isso, por sua vez, permite que as outras partes entendam quais elementos de mensagem e serviços de nível superior empregam ao interagir com o serviço.

1.2 Um exemplo de composição na prática

A Figura 2 fornece uma visão geral que mostra a composição na prática. Um cliente e um fornecedor usam serviços Web para processar pedidos.

Figura 2. Composição em um sistema de processamento de pedidos

Ao criar esses serviços Web, os desenvolvedores usam WSDL e documentos relacionados para descrever sua interface de negócios. Esses documentos do WSDL descrevem o conjunto de mensagens que os serviços Web do cliente e do fornecedor processarão, por exemplo, a mensagem SubmitPurchaseOrder (SubmitPO) que flui do cliente para o fornecedor. Isso é mostrado na parte superior da Figura 2. Depois que as partes principais do aplicativo estiverem em vigor, os desenvolvedores poderão decidir dar suporte a uma funcionalidade adicional, por exemplo, aqui eles decidem fazer com que o processamento do pedido seja transacionado. Para fazer isso, eles redigir os seguintes elementos na estrutura existente:

• Os serviços associam WS-Policy documentos que descrevem seu suporte para transações à descrição do WSDL de seus serviços. Observe que essas instruções de política aumentam, mas não alteram fundamentalmente a funcionalidade de negócios existente.
• Para dar suporte ao processamento transacionado, os serviços adicionais que descrevem as transações que compõem, mas não alteram fundamentalmente, as mensagens de aplicativo existentes.
• Quando o serviço fornecedor recebe mensagens que contêm o elemento de transação, ele usa essas informações para se comunicar com um serviço Web designado chamado coordenador que dá suporte à função de transação. Novamente, esse serviço Web adicional simplesmente adiciona à solução e não requer modificação na descrição da funcionalidade de negócios existente.
• Por fim, os serviços podem implementar operações adicionais para dar suporte à integração com o serviço de coordenador de transações.

Na figura anterior, esses elementos adicionais são realçados.

O modelo é incremental e composável porque:

• A adição das novas funções pode ser feita independentemente da adição de outras funções.
• Adicionar a função não interrompe as mensagens existentes, a lógica de processamento de mensagens ou o WSDL.

A composição é um princípio de design cada vez mais importante, mas a abordagem nem sempre é bem compreendida. Embora as especificações individuais do serviço Web definam como elementos e serviços individuais interoperam, este white paper destina-se a fornecer uma visão geral de como a coleção de especificações pode ser composta para fornecer serviços Web interoperáveis mais sofisticados.

2.0 Serviços Web: Uma arquitetura de Service-Oriented

Nos últimos anos, testemunhamos uma enxurrada de atividades centradas no desenvolvimento de serviços Web. Com toda essa atividade, é importante recuar e fazer a pergunta: "Por quê?" Certamente, os serviços Web não habilitam novos tipos de funcionalidade computacional, depois que todos os serviços Web ainda são executados em computadores existentes, executando o mesmo conjunto de instruções e acessando os mesmos dados. Além disso, os protocolos de serviço Web em muitos casos podem, na verdade, aumentar a sobrecarga de protocolo para uma determinada tarefa.

Um dos principais motivos pelos quais vemos tanto interesse em serviços Web é que os serviços Web são adequados para habilitar uma SOA (arquitetura de Service-Oriented). Ao usar serviços Web para criar um SOA, as soluções consistem em coleções de serviços autônomos, identificados por URLs, com interfaces documentadas usando WSDL e processamento de mensagens XML bem definidas. SOA é um complemento natural para o OO (orientado a objeto), abordagens centradas em procedimentos e dados para a implementação da solução. De fato, ao criar um sistema SOA, os serviços individuais normalmente são construídos usando uma ou mais dessas tecnologias.

Uma arquitetura de Service-Oriented difere da OO e dos sistemas processuais em um aspecto fundamental: associação. os Serviços interagem com base em quais funções elas fornecem e como elas as entregam. Os sistemas de OO e de procedimento vinculam elementos com base no tipo ou nome. As seções a seguir fornecem mais detalhes.

2.1 Os serviços são descritos por esquema e contrato não tipo

Ao contrário dos sistemas anteriores, o modelo de serviço Web não opera na noção de tipos compartilhados que exigem implementação comum. Em vez disso, os serviços interagem com base apenas em contratos (WSDL/BPEL4WS para comportamento de processamento de mensagens) e esquemas (WSDL/XSD para estrutura de mensagens). Isso permite que o serviço descreva a estrutura de mensagens que pode enviar e/ou receber e sequenciar restrições nessas mensagens. A separação entre estrutura e comportamento e a descrição explícita e verificável do computador dessas características simplifica a integração em ambientes heterogêneos.

Além disso, essas informações caracterizam suficientemente a interface de serviço para que a integração de aplicativos não exija um ambiente de execução compartilhada para criar a estrutura ou o comportamento das mensagens.

O modelo orientado a serviço pressupõe um ambiente totalmente distribuído em que é difícil, se não impossível, propagar alterações no esquema e/ou contrato para todas as partes que encontraram um serviço. A orientação de serviço implica que os contratos e o esquema devem permanecer compatíveis com versões anteriores e podem conter informações que são compreendidas incompletamente por sistemas de processamento específicos.

Por esse motivo, as tecnologias de contrato e esquema projetadas para uso em designs orientados a serviços permitem mais flexibilidade do que as interfaces tradicionais orientadas a objetos. Em particular, os serviços usam recursos como curingas de elemento XML (por exemplo, xsd:any), extensões de esquema e blocos de cabeçalho SOAP opcionais para desenvolver serviços de maneiras que não interrompem aplicativos implantados. Essas características são a chave para a composição dos serviços Web.

2.2 Compatibilidade de serviço é mais do que compatibilidade de tipo

Os designs orientados a procedimentos e objetos normalmente equivalem à compatibilidade de tipo com compatibilidade semântica. A orientação de serviço fornece um modelo mais avançado para determinar a compatibilidade. A compatibilidade estrutural baseia-se no contrato (WSDL e, opcionalmente, BPEL4WS) e no esquema (XSD) e pode ser validada. Além disso, o advento do WS-Policy fornece uma análise automatizada adicional da compatibilidade da garantia de serviço entre os serviços. Isso é feito com base em declarações explícitas de recursos e requisitos na forma de instruções WS-Policy.

Usando o WS-Policy, os serviços descrevem seus recursos e requisitos de garantia de serviço na forma de uma expressão de política legível pelo computador que contém combinações de declarações. Isso permite que o serviço selecione uns aos outros com base em "como" ou "com que qualidade" eles entregam seus contratos,

As declarações de política são identificadas por nomes estáveis e globalmente exclusivos cujo significado é consistente no tempo e no espaço, independentemente do serviço ao qual a declaração é aplicada. As declarações de política também podem ter parâmetros que qualificam a interpretação exata da declaração.

2.3 Orientação de serviço pressupõe que coisas ruins podem e acontecerão

Algumas abordagens anteriores para aplicativos distribuídos assumiram explicitamente um espaço de tipo comum, um modelo de execução e um modelo de referência de procedimento/objeto. Em essência, o modelo de programação "na memória" definiu o modelo de sistema distribuído.

A orientação de serviço simplesmente pressupõe que os serviços sejam executados de forma autônoma e não haja noção de execução local ou ambiente operacional comum. Por esse motivo, um SOA pressupõe explicitamente que erros de comunicação, disponibilidade e tipo são comuns.

Para manter a integridade do sistema, os designs orientados ao serviço dependem explicitamente de uma variedade de tecnologias para lidar com modos de falha assíncrona e parcial. Técnicas como mensagens assíncronas, transações, mensagens confiáveis e implantação redundante são a norma em sistemas orientados a serviços.

Além disso, ao contrário do modelo na memória, a orientação de serviço pressupõe que não apenas uma mensagem de entrada pode estar malformada, mas também que pode ter sido transmitida para fins mal-intencionados ou completamente inesperados. Consequentemente, os sistemas orientados a serviços se protegem colocando o ônus da prova em todos os remetentes de mensagens, exigindo que os aplicativos provem que os direitos necessários foram concedidos ao remetente. Consistente com a noção de autonomia de serviço, as arquiteturas orientadas a serviço normalmente dependem de relações de confiança gerenciadas administrativamente para evitar mecanismos de autenticação por serviço comuns em aplicativos Web clássicos.

2.4 Orientação de serviço permite associação flexível de serviços

Um dos principais conceitos de SOA (arquitetura orientada a serviço) é a associação flexível de serviços. Modelos de procedimento, componente e objeto mais tradicionais associam componentes por meio de referências (ponteiros) ou nomes. Um SOA dá suporte à descoberta mais dinâmica de instâncias de serviço que fornecem a interface, semântica e garantias de serviço que o solicitante espera.

Em sistemas orientados a procedimentos ou objetos, um chamador normalmente encontra um servidor com base nos tipos exportados ou em um espaço de nome compartilhado. Em um sistema SOA, os chamadores podem pesquisar registros como UDDI para um serviço.

1. Essa é uma mensagem compatível com os requisitos do chamador. A compatibilidade pode ocorrer por meio do WSDL ou de mensagens correspondentes de esquemas XML conhecidos.
2. Esses documentos dão suporte a garantias de serviço que o chamador requer. Por exemplo, o chamador pode desejar determinadas abordagens de segurança ou transações.

A associação flexível em relação à implementação do serviço que permite implementações alternativas de comportamento pode ser usada para atender a uma variedade de requisitos de negócios. Por exemplo, as implementações alternativas podem corresponder a fornecedores alternativos em uma cadeia de fornecedores, permitindo uma resposta mais rápida às mudanças nas condições do mercado. Da mesma forma, a implementação alternativa pode ser data centers distribuídos geograficamente habilitando a tolerância a desastres.

3.0 Funções e Especificações do Serviço Web

Esta seção fornece uma visão geral das especificações do serviço Web.

3.1 Uma abordagem composable para serviços Web

Esta seção descreve brevemente as especificações do serviço Web que estão disponíveis. Explicamos seu valor para os provedores de soluções, seu papel em uma arquitetura mais ampla e como eles complementam uns aos outros.

A figura a seguir fornece um agrupamento de alto nível das especificações do serviço Web publicadas pela IBM, Microsoft e outros. Observe que essa figura não se destina a implicar uma camada estrita entre os grupos; em vez disso, destina-se a fornecer uma intuição sobre as relações entre áreas funcionais. Por exemplo, a segurança da mensagem não requer Descrição e, da mesma forma, a Descrição é um conceito de tempo de desenvolvimento útil para Mensagens.

Figura 3. A arquitetura de protocolo de serviços Web interoperáveis

3.2 O Básico – Transportes e Mensagens

Se eu te enviar uma carta escrita em francês mas você estava esperando um telefonema em inglês, nós não nos comunicaremos. A interoperabilidade dos serviços Web enfrenta o mesmo problema; resolvemos isso fornecendo um conjunto comum de transportes e tecnologia de mensagens.

Além disso, para garantir que essas tecnologias sejam eficazes na prática, a IBM, a Microsoft e outras criaram a Organização de Interoperabilidade dos Serviços Web (WS-I). Recentemente, o WS-I lançou um perfil básico que documenta formalmente mecanismos interoperáveis de transporte e mensagens do serviço Web.

3.2.1 Transportes — HTTP, HTTP/S, SMTP

Esse conjunto de especificações define os principais mecanismos de comunicação para mover dados brutos entre serviços Web.

HTTP, HTTP/S e SMTP (Simple Mail Transport Protocol) são exemplos nesse grupo. Implementações de serviço Web podem dar suporte adicional a outros transportes, mas é essencial fornecer suporte para protocolos padrão e interoperáveis.

3.2.2 Formatos de mensagem – XSD

O próximo grupo de especificações define mecanismos interoperáveis para codificar mensagens de serviço Web para transporte. Os transportes movem blocos de "bytes" entre os serviços. Isso só será útil se os participantes puderem converter os bytes em estruturas de dados úteis que seu aplicativo processa.

O grupo de especificação de mensagens define como formatar mensagens corretamente. As definições de esquema XML e XML fornecem o mecanismo para concordar abstratamente sobre estruturas de mensagem (dados). SOAP define a codificação padrão para representar mensagens XML nas informações de byte que os serviços trocam por transportes.

3.2.3 WS-Addressing

Mensagens e respostas vão para algum lugar e vêm de algum lugar. de Endereçamento WS fornece uma abordagem interoperável e independente de transporte para identificar remetentes e receptores de mensagens. WS-Addressing também fornece uma abordagem mais refinada para identificar elementos específicos em um serviço que enviam ou devem receber uma mensagem.

Atualmente, a maioria dos sistemas que usam serviços Web codificam o destino de uma mensagem de serviço Web com uma URL que é colocada no transporte HTTP. O destino da resposta é determinado pelo endereço de transporte de retorno. Essa abordagem se baseia no modelo de servidor de navegador básico de HTTP.

Usando a abordagem de hoje, as informações de origem e de destino não fazem parte da própria mensagem. Isso pode causar vários problemas. As informações poderão ser perdidas se uma conexão de transporte for encerrada (por exemplo, se a resposta demorar muito tempo e a conexão atingir o tempo limite) ou se a mensagem for encaminhada por um intermediário, como um firewall.

WS-Addressing fornece um mecanismo para colocar o destino, a origem e outras informações de endereço importantes diretamente na mensagem do serviço Web. Em suma, WS-Addressing separa informações de endereço de qualquer modelo de transporte específico.

Em muitos cenários, as mensagens são direcionadas diretamente a um serviço e as informações de endereçamento na mensagem podem ser descritas simplesmente usando uma URL. Mas, na prática, geralmente descobrimos que as mensagens são direcionadas a elementos ou recursos específicos dentro de um serviço. Por exemplo, um serviço de coordenação pode estar coordenando muitas tarefas diferentes. O coordenador precisa associar a maioria das mensagens de entrada a uma instância de tarefa específica que gerencia e não ao próprio serviço de coordenação. 

WS-Addressing fornece um mecanismo simples, mas poderoso, chamado de de referência de ponto de extremidade para endereçar entidades gerenciadas por um serviço. Embora essas informações possam ser codificadas de maneira ad hoc dentro da URL do serviço, as referências de ponto de extremidade fornecem um elemento XML padrão que permite uma abordagem estruturada para codificar esse endereçamento refinado.

A combinação de controle refinado sobre o endereçamento, juntamente com a codificação neutra em transporte da origem e do destino da mensagem, permite que as mensagens de serviço Web sejam enviadas por uma variedade de transportes, por meio de intermediários, e permite padrões de comunicação de duração assíncrona e estendida.

WS-Addressing também permite que um remetente indique para onde uma resposta deve ir de maneira independente de transporte. A resposta a uma mensagem pode não necessariamente ir para o remetente. Em HTTP, por exemplo, sem WS-Addressing é impossível especificar que a resposta deve ser enviada para outro lugar.

Esses aprimoramentos no modelo de mensagens permitem que os serviços Web sejam usados para dar suporte a muitos cenários de negócios. Por exemplo, determinadas tarefas bancárias exigem revisão humana para aprovação em determinadas etapas. Geralmente, há muitas instâncias ativas da tarefa em qualquer momento. WS-Addressing fornece um mecanismo geral para associar mensagens de entrada ou saída a tarefas específicas. O mecanismo usado pelo serviço é transparente para aqueles que usam o serviço por meio de uma referência de ponto de extremidade.

Descrição 3.3

As especificações de transporte e mensagem permitem que os serviços Web se comuniquem usando mensagens. Mas como os participantes sabem quais são as mensagens? Como um serviço Web documenta ou descreve as mensagens que ele envia e recebe? O uso de um serviço Web requer uma compreensão das mensagens que o serviço Web consumirá e produzirá: a interface para o serviço Web. O grupo de especificações de descrição permite que um serviço Web expresse sua interface e funcionalidades.

Além da interoperabilidade de mensagens; essas especificações também permitem interoperabilidade da ferramenta de desenvolvimento. As especificações de descrição fornecem um modelo padrão que permite ferramentas diferentes de diferentes fornecedores para dar suporte colaborativo aos desenvolvedores. Da mesma forma que os serviços Web isolam os parceiros das opções de implementação e infraestrutura, as especificações de descrição isolam os parceiros das opções de ferramentas de desenvolvimento.

3.3.1 WSDL

O WSDL (Web Services Description Language) e o XSD (esquema XML) são as especificações base desse grupo. O esquema XML permite que desenvolvedores e provedores de serviços definam tipos XML para estruturas de dados, por exemplo, uma ordem de compra e mensagens, por exemplo, a mensagem CreatePO. O WSDL permite que um serviço Web documente as mensagens que recebe e envia. Em outras palavras, quais "ações" ou "funções" o serviço executa em termos das mensagens que recebe e envia.

O WSDL fornece suporte para uma variedade de padrões de interação de mensagens. Ele dá suporte a mensagens de entrada unidirecionais que não têm resposta, solicitação/resposta e envios unidirecionais com ou sem resposta. Os dois últimos padrões permitem que um serviço especifique outros serviços necessários.

As melhorias propostas do WSDL oferecem suporte para documentar protocolos e formatos de mensagem que um serviço dá suporte e o endereço do serviço.

3.3.2 WS-Policy

As definições WSDL e XSD geralmente não fornecem informações suficientes para chamar um serviço Web. WSDL e XSD definem a sintaxe da interface do serviço, mas não expressam informações sobre como o serviço fornece sua interface ou o que o serviço espera do chamador. Por exemplo, o serviço requer segurança ou implementa transações?

WS-Policy permite que um serviço especifique o que espera dos chamadores e como ele implementa sua interface. WS-Policy é essencial para alcançar a interoperabilidade na operação funcional de nível superior do serviço. Segurança, transações, mensagens confiáveis e outras especificações exigem esquema WS-Policy concreto. Isso permite que os serviços descrevam a garantia funcional que eles esperam e forneçam aos chamadores.

A estrutura WS-Policy fornece um modelo base para definir expressões de política.

WS-Policy dá suporte a uma gramática para agregar instruções políticas e permite a construção de conjuntos de políticas mais flexíveis e completos.

WS-PolicyAttachment especifica como associar um conjunto de políticas a mensagens XML e elementos WSDL (operações e portTypes).

Juntos, WS-Policy e WS-PolicyAttachment fornecem a estrutura. Especificações individuais definem suas instruções de política e esquema específicos de domínio.

Por fim, @Page WS-PolicyAssertions fornece um conjunto fundamental de instruções de política comuns que podem ser usadas para alcançar a interoperabilidade.

3.3.3 Obtendo descrições

Suporte a XML, XSD, WSDL e WS-Policy descrevendo a interface e as garantias de serviço para um serviço. Mas, como os usuários potenciais do serviço encontram essas informações?

Atualmente, a abordagem mais comum é por meio de trocas de email ou boca a boca. Um modelo mais geral e escalonável é necessário. Há duas opções, o serviço pode ir diretamente para o serviço para obter informações usando WS-MetadataExchange ou pode optar por usar um serviço UDDI que agrega essas informações para vários serviços de destino.

Os desenvolvedores usam WS-MetadataExchange quando têm uma referência a um serviço e precisam entender o que ele faz. Os desenvolvedores usam UDDI quando desejam encontrar uma referência a um serviço que dê suporte a um conjunto específico de funções.

3.3.4 WS-MetadataExchange

Conforme descrito acima, os serviços normalmente fornecem informações como WSDL, WS-Policy e XSD, que descrevem o próprio serviço. Coletividade nos referimos a informações sobre o serviço como metadados. A especificação WS-MetadataExchange permite que um serviço forneça metadados para outras pessoas por meio de uma interface de serviços Web. Dada apenas uma referência a um serviço Web, um usuário em potencial pode acessar um conjunto de operações WSDL/SOAP para recuperar os metadados que descrevem o serviço. Os clientes podem usar WS-MetadataExchange em tempo de design, ao criar seus clientes ou em runtime.

3.3.5 UDDI

Muitas vezes, é útil coletar metadados sobre uma coleção de serviços e disponibilizar as informações em um formulário pesquisável. Esses serviços de agregação de metadados são um repositório útil no qual as organizações podem publicar os serviços que fornecem, descrever as interfaces para seus serviços e habilitar taxonomias de serviços específicas do domínio. A especificação UDDI (Universal Description and Discovery Interface) define um serviço de agregação de metadados.

As soluções podem consultar a UDDI em tempo de design para localizar serviços compatíveis com seus requisitos. Os desenvolvedores podem usar esses serviços na definição de seus fluxos de trabalho BPEL4WS, por exemplo. As soluções também podem consultar a UDDI em runtime. Nesse cenário, o chamador "conhece" a interface necessária e procura um serviço que atenda aos seus requisitos funcionais ou seja fornecido por um parceiro conhecido.

Observe que um dos mecanismos que podem ser usados para popular um serviço UDDI com metadados é adquirir os metadados de serviços usando WS-MetadataExchange.

3.4 Garantias de Serviço

Os serviços Web geraram tanto entusiasmo em parte devido à sua capacidade de fazer pontes com sistemas diferentes. Os desenvolvedores produziram muitas soluções totalmente funcionais usando os recursos base de transporte, mensagens e descrição. No entanto, para serem aceitos pelos desenvolvedores que criam soluções de integração mais avançadas, os serviços Web devem fornecer funcionalidade para garantir o mesmo nível de garantias de serviço fornecidas por soluções de middleware mais tradicionais. Não basta simplesmente trocar mensagens. Aplicativos e serviços residem em middleware e sistemas que fornecem funções valiosas de nível superior, como segurança, confiabilidade e operações transacionadas. Os serviços Web devem fornecer um mecanismo para interoperabilidade entre essas funções.

3.5 Segurança

Essa @Pagefamília de especificações é essencial para serviços Web entre organizações. Essas especificações dão suporte à autenticação e à integridade da mensagem, à confidencialidade, à confiança e à privacidade. Eles também dão suporte à federação de segurança entre diferentes organizações.

3.5.1 WS-Security

WS-Security é o bloco de construção básico para serviços Web seguros. Hoje, a maioria dos serviços Web distribuídos depende do suporte de nível de transporte para funções de segurança. Exemplos são HTTP/S e autenticação BASIC-Auth. Essas abordagens de segurança fornecem o mínimo necessário para uma comunicação segura. O nível de função que eles fornecem, no entanto, é significativamente menor do que o fornecido pelos ambientes de middleware e distribuídos existentes.

Dois exemplos destacam as deficiências de BASIC-Auth e HTTP/S.

• Um envia uma mensagem para o serviço B. B processa parcialmente as mensagens e a encaminha para o serviço C. HTTP/S permitem autenticação, confidencialidade e integridade entre A-B e B-C. No entanto, C e A não podem se autenticar ou ocultar informações de B.
• Para A, B e C usarem BASIC-Auth para autenticação. Eles devem compartilhar as mesmas informações de usuário e senha replicadas. Isso é inaceitável em muitos cenários.

WS-Security resolve esses problemas. Ele dá suporte a:

• Tokens de segurança criptografados e assinados. É possível gerar um token que c pode verificar como tendo vindo de A. B não pode forjar o token.
• É possível assinar elementos selecionados ou a mensagem inteira. Isso permite que B e C confirmem que a mensagem não foi alterada desde que A a enviou.
• É possível selar a mensagem ou os elementos selecionados. Isso garante que somente o serviço pretendido para esses elementos possa usar as informações. Isso impede que b veja informações destinadas a C e vice-versa.

WS-Security usa modelos de segurança existentes (Kerberos, X509 etc. As especificações definem concretamente como usar os modelos existentes de maneira interoperável. Cálculos de serviço Web de vários saltos e multiparte não podem ser seguros sem o WS-Security.

3.5.2 WS-Trust

A segurança depende de relações de confiança predefinidas. O Kerberos funciona porque os participantes "confiam" no Centro de Distribuição de Chaves Kerberos. A PKI funciona porque os participantes confiam nas autoridades de certificação raiz. WS-Trust define um modelo extensível para configurar e verificar relações de confiança.

O conceito chave no WS-Trust é um STS (Serviço de Token de Segurança) . Um STS é um serviço Web diferenciado que emite, troca e valida tokens de segurança. WS-Trust permite que os serviços Web configurem e concordem em quais servidores de segurança eles "confiam" e confiem nesses servidores.

O STS tem ampla aplicabilidade, pois pode ser usado para emitir tokens de segurança que fazem uma ampla gama de declarações. Em muitos casos, ele será usado para emitir as mesmas declarações, mas em formatos diferentes. Por exemplo, um STS pode emitir um token Kerberos afirmando que o titular da chave é Susan e pode fazer isso com base em um certificado X.509 emitido por uma autoridade de certificação confiável. Isso permite que as organizações usem diferentes tecnologias de segurança para federar. Um STS também pode emitir um token de segurança afirmando que o titular da chave é um membro do grupo BankTellers com base em um token de segurança de entrada que declara uma declaração de identidade.

3.5.3 WS-SecureConversation

Alguns cenários de serviço Web envolvem apenas a breve troca esporádica de algumas mensagens. WS-Security prontamente dá suporte a esse modelo. Outros cenários envolvem conversas de longa duração e várias mensagens entre os serviços Web. WS-Security também dá suporte a esse modelo, mas a solução não é ideal.

Há dois usos sub-ideais de WS-Security nestes cenários:

• Uso repetido de operações criptográficas computacionalmente caras, como validação de chave pública.
• Enviar e receber muitas mensagens usando as mesmas chaves criptográficas, fornecendo mais informações que permitem que ataques de força bruta "quebrem o código".

Por esses motivos, protocolos como HTTP/S usam chaves públicas para executar uma negociação simples que define chaves específicas da conversa. Essa troca de chaves permite implementações de segurança mais eficientes e também diminui a quantidade de informações criptografadas com um conjunto específico de chaves.

WS-SecureConversation fornece suporte semelhante para o WS-Security. Os participantes geralmente usam WS-Security com chaves públicas para iniciar uma "conversa" ou "sessão" e usam WS-SecureConversation para concordar com chaves específicas da sessão para assinar e criptografar informações.

3.5.4 WS-Federation

WS-Federation permite que um conjunto de organizações estabeleça um único domínio de segurança virtual. Por exemplo, um agente de viagens, uma companhia aérea e uma rede hoteleira podem configurar tal federação. Um usuário final que "faz logon" em qualquer membro da federação entrou efetivamente em todos os membros. WS-Federation define vários modelos para fornecer segurança federada por meio de protocolos entre topologias WS-Trust e WS-SecureConversation.

Além disso, os clientes geralmente têm "propriedades" quando lidam com uma empresa. Um exemplo é uma preferência por assentos de janela ou corredor ou um carro de médio porte. WS-Federation permite que os membros configurem um espaço de propriedade federado. Isso permite que cada participante tenha acesso controlado seguro às informações de propriedade de cada membro sobre os usuários finais.

Propriedades e informações sobre indivíduos podem ser mantidas de perto para proteção de privacidade ou porque as informações fornecem uma vantagem competitiva para um membro específico. Para dar suporte a esses requisitos, WS-Federation dá suporte a um modelo de pseudônimo . Os usuários que se autenticaram na agência de viagens geraram "aliases" em suas interações com a companhia aérea ou hotel. Isso protege a privacidade do usuário final e a vantagem competitiva que a agência de viagens pode ganhar conhecendo as propriedades do usuário.

3.6 Reliable Messaging

Em um mundo da Internet, quase todos os canais de comunicação não são confiáveis. Mensagens desaparecem. Quebra de conexões.

Sem um padrão de mensagens confiável, os desenvolvedores de aplicativos de serviço Web devem criar essas funções em seus aplicativos. As abordagens e técnicas básicas são bem compreendidas, por exemplo, muitos sistemas operacionais e de middleware garantem que as mensagens tenham identificadores exclusivos, forneçam números de sequência e usem retransmissão quando as mensagens são perdidas. Se os desenvolvedores do serviço Web de aplicativo implementarem esses modelos em seus aplicativos. Eles podem fazer suposições ou escolhas de design diferentes, resultando em poucas mensagens confiáveis.

3.6.1 WS-ReliableMessaging

WS-ReliableMessaging define mecanismos que permitem que os serviços Web garantam a entrega de mensagens em redes de comunicação não confiáveis.

WS-ReliableMessaging garante que os serviços implementem abordagens interoperáveis e também permite que os fornecedores de runtime facilitem o desenvolvimento de aplicativos fornecendo serviços que implementam os protocolos. Isso simplifica significativamente a tarefa de desenvolvimento de aplicativos. Em seguida, a lógica de negócios tem muito menos condições de erro que deve lidar.

Por fim, o setor tem um rico conjunto de middleware orientado a mensagens para roteamento e distribuição confiável de mensagens. Cada implementação usa protocolos proprietários. WS-Reliable protocolos de mensagens permitem que diferentes sistemas operacionais e de middleware troquem mensagens de forma confiável. Assim, ele dá suporte à ponte de duas infraestruturas diferentes em um único modelo de ponta a ponta logicamente completo.

3.7 Transações

Um cenário de negócios complexo pode exigir que várias partes troquem vários conjuntos de mensagens. Um exemplo é um conjunto de instituições financeiras que configuram uma oferta financeira que envolve apólices de seguro, anuidades, contas corrente e contas de corretagem. As várias mensagens trocadas entre os participantes constituem uma "tarefa" lógica ou "objetivo".

Para o sucesso, as partes devem ser capazes de:

1. Inicie novas tarefas coordenadas.
2. Associe as operações à tarefa lógica. As partes podem estar configurando várias contas para clientes diferentes ao mesmo tempo.
3. Concorde com o resultado da computação. Por exemplo, todos concordam que os pacotes financeiros foram configurados?

WS-Coordination, WS-AtomicTransaction e WS-BusinessActivity dão suporte a esses requisitos.

3.7.1 WS-Coordination

@PageWS-Coordination é um mecanismo geral para iniciar e concordar com o resultado de tarefas de serviço Web de várias partes e várias mensagens. WS-Coordination tem três elementos principais:

1. Um elemento de mensagem chamado contexto de coordenação que flui em todas as mensagens que os serviços Web trocam durante a computação. O contexto de coordenação contém a referência de ponto de extremidade WS-Addressing ao serviço de coordenação e, por sua vez, contém informações para identificar a tarefa específica que está sendo coordenada.
2. O serviço coordenador de . O serviço coordenador fornece um serviço, descrito usando o WSDL, que fornece a capacidade de iniciar uma tarefa coordenada, encerrar uma tarefa coordenada, permitir que um participante se registre em uma tarefa e produzir um contexto de coordenação que faça parte de todas as mensagens em um grupo.
3. O serviço de coordenação também inclui uma interface, definida em WSDL, que os serviços participantes usam para serem informados do resultado da tarefa coordenada.

Um serviço Web que recebe uma mensagem com um novo contexto de coordenação registra-se com o serviço coordenador no contexto para receber informações de resultado. Outras especificações podem aumentar essa estrutura para requisitos específicos de domínio e garantia.

WS-Coordination é uma estrutura geral e uma funcionalidade. WS-AtomicTransaction e WS-BusinessActivity estender essa estrutura para permitir que os participantes na computação distribuída determinem de forma robusta os resultados.

3.7.2 WS-AtomicTransaction

WS-AtomicTransaction define um conjunto específico de protocolos que se conectam ao modelo WS-Coordination para implementar protocolos tradicionais de transação atômica de duas fases. É importante observar que o modelo atômico de duas fases é apenas em relação aos serviços envolvidos. Sites ou serviços de oferta de infraestrutura podem anunciar confirmação em duas fases, mas usar algum outro modelo intra-empresarial, como compensação ou controle de versão. Essa liberdade torna um modelo de confirmação de duas fases simples mais útil para cálculos de Internet de longa execução.

3.7.3 WS-BusinessActivity

WS-BusinessActivity define um conjunto específico de protocolos que se conectam ao modelo de WS-Coordination para implementar protocolos de transação baseados em compensação de longa execução. Embora BPEL4WS defina um modelo de transação para processos de negócios, é WS-BusinessActivity que especifica a renderização de protocolo correspondente. Isso, novamente, é um exemplo para a composição das especificações dos serviços Web.

3.8 Composição de Serviço

O elemento superior nas camadas do serviço Web é composição de serviço. A composição de serviço permite que os desenvolvedores "redigirem" serviços que trocam mensagens SOAP e definam sua interface no WSDL e WS-Policy em uma solução de agregação. A agregação é um serviço Web composto.

3.8.1 BPEL4WS

A especificação Business Process Execution Language for Web Services (BPEL4WS) dá suporte à composição do serviço. Ele permite que os desenvolvedores definam a estrutura e o comportamento de um conjunto de serviços Web que implementam em conjunto uma solução de negócios compartilhada. Cada elemento do conjunto de serviços define sua interface usando WSDL e WS-Policy. A solução composta é em si um serviço Web, que dá suporte a mensagens HTTP/SOAP e define sua interface usando WSDL e WS-Policy.

A composição tem três aspectos: estrutura , de informações e comportamento . BPEL4WS apresenta três constructos que dão suporte a cada aspecto de composição.

Um partnerLink define uma associação nomeada entre o serviço composto e um serviço Web que participa da solução geral. O serviço composto e o serviço participante definem suas interfaces entre si usando WSDL e WS-Policy. Um exemplo pode ser uma associação entre uma empresa de fabricação e um fornecedor.

O conceito partnerLink e as interfaces WSDL/WS-Policy entre a composição e os parceiros definem a estrutura da composição do serviço. Eles definem os tipos de serviços que colaboram para formar a composição e quais mensagens trocam com quais níveis de garantia (segurança, transações etc.)

BPEL4WS também oferece suporte para definir as informações da composição do serviço. BPEL4WS define o conceito de uma variável. O serviço composto define um conjunto de variáveis, cada uma com uma definição XSD. O estado atual de um serviço específico é o estado de suas variáveis. Isso define quais mensagens ele recebeu ou enviou.

Por fim, BPEL4WS dá suporte à definição do comportamento do serviço composto pelo conceito de uma atividade . Um serviço BPEL4WS definido é um conjunto de atividades ou "etapas", que definem o comportamento do serviço. As atividades mais básicas são enviar uma mensagem para um parceiro ou receber uma mensagem de um parceiro. Cada mensagem corresponde a uma variável. BPEL4WS fornece suporte para mover dados entre variáveis.

Um aspecto fundamental das atividades de BPEL4WS é que BPEL4WS fornece suporte especial para definir o comportamento de serviços externamente visível (público) permitindo o uso controlado de comportamento não determinístico. Por exemplo, o fato de uma verificação de crédito ser executada de forma específica no processo de decisão para aceitar uma PO pode ser um assunto privado para um fornecedor. BPEL4WS permite que o processo de decisão fique oculto descartando o comportamento de verificação de crédito da descrição do processo, mas mostrando que a resposta à PO pode ser aceitação ou rejeição. Esse tipo de processo de abstrato pode ser usado em conjunto com o WSDL para definir protocolos de negócios interoperáveis entre parceiros de negócios e para domínios verticais do setor, como a cadeia de suprimentos.

BPEL4WS também dá suporte a várias abordagens para controlar o fluxo de execução de atividades. Isso inclui sequenciamento e fluxos baseados em grafo. BPEL4WS dar suporte a predicados em variáveis para determinar quais caminhos de controle o serviço composto segue.

Para resumir, BPEL4WS faz duas adições às especificações de serviço Web definidas anteriormente.

1. BPEL4WS estende o suporte ao WSDL e WS-Policy para descrever os serviços. BPEL4WS suporte à combinação de serviços Web em serviços de agregação e à documentação das associações entre serviços, como o fluxo de informações e o comportamento. Isso fornece suporte para interoperabilidade entre ferramentas de camada superior que dão suporte ao design colaborativo de serviços Web.
2. BPEL4WS é uma linguagem de execução . BPEL4WS permite que os desenvolvedores especifiquem completamente o comportamento de um serviço Web composto. IBM, Microsoft e outros parceiros fornecerão ambientes que executam BPEL4WS documentos e dão suporte à associação de tempo de execução e design a parceiros.

4.0 Serviços Web na prática — um exemplo

O cenário a seguir mostra como as especificações do WS podem ser usadas em conjunto para criar serviços Web que resolvem necessidades reais. O cenário fornece um exemplo da funcionalidade avançada disponível para desenvolvedores devido à composição das diferentes especificações do WS.

Os serviços Web descritos nesse cenário foram criados para uma demonstração conjunta IBM-Microsoft da tecnologia realizada em 17 de setembro de 2003. Eles foram usados para criar um aplicativo interoperável, seguro, confiável e transacionado; e isso abrange os limites organizacionais.

A demonstração mostra um exemplo em execução de um sistema de VMI (processamento de pedidos federados e inventário gerenciado por fornecedor) para um revendedor de carros ordenando uma parte de um fabricante de automóveis; o fabricante, por sua vez, obtém peças de um fornecedor que opera vários armazéns. Todas as comunicações de aplicativo para aplicativo no sistema foram criadas exclusivamente usando os protocolos de serviço Web descritos anteriormente e em execução em uma coleção de computadores com software IBM e Microsoft.

O cenário lida com alguns dos aspectos mais comuns da condução de negócios— a interação entre um negócio de varejo, seu atacadista e o fornecedor do atacadista. O cenário mostra como diferentes especificações do WS podem ser compostas para automatizar os itens essenciais do processo de negócios, como:

1. Autenticação para impor a segurança (WS-Security)
2. Federação de confiança entre diferentes organizações ( WS-Trust e WS-Federation )
3. Troca de dados para concluir uma transação (WS-AtomicTransaction )
4. Garantia de que os pedidos foram enviados por meio de mensagens confiáveis (WS-ReliableMessaging)

4.1 Parte 1: a experiência do cliente

O exemplo começa com Heather, uma funcionária de uma empresa chamada Revendedora de Automóveis, fazendo logon no site seguro da Intranet de sua concessionária. Este site é criado usando tecnologias web padrão e off-the-shelf. Heather entra no site usando seu navegador. O acesso ao site é protegido por senha.

Figura 4. Heather faz logon no site seguro da intranet de sua empresa e navega até sua Minha Página personalizada.

Heather clica em Minha Página. Em segundo plano, o aplicativo coleta informações do banco de dados de inventário do Revendedor Automático. Se os níveis de inventário de um item estiverem abaixo de um limite definido, um relatório será gerado e listado na exibição "Seus Alertas" da página de Heather.

Heather vê que sua empresa tem um estoque baixo em folhas de apagamento WindshieldPro.

Heather clica no link e é redirecionada diretamente para uma página da Web segura na extranet fabricante de automóveis, onde Heather pode fazer um pedido. A experiência é perfeita porque o software do Revendedor de Automóveis é baseado em serviços Web. O serviço Web que vinculava a intranet do Revendedor Automático à extranet do Fabricante de Automóveis foi composto usando o WS-Federation. WS-Federation garante que as credenciais de segurança concedidas por um site sejam respeitadas por um segundo site.

Veja como isso funciona. O Revendedor de Automóveis e o Fabricante de Automóveis concordaram em federar seus sites. WS-Federation coordena uma série de comunicações servidor a servidor. Assim que Heather clicou no link do WindshieldPro para levá-la à página da Web do Fabricante Automático, o servidor de página da Web do Fabricante Automático consultou seu serviço de autorização, que, por sua vez, consultou o serviço de autorização do Revendedor Automático. O serviço de autorização do Revendedor de Automóveis confirma que Heather é uma usuária autorizada, transmitindo credenciais, juntamente com o nome da concessionária de Heather, de volta ao serviço de autorização do Fabricante de Automóveis, que concede acesso a Heather. Isso acontece tão perfeitamente, que tudo o que Heather nota é que ela passou de uma página da Web para outra.

O serviço Web também consulta o banco de dados do cliente do Fabricante automático para solicitar informações vinculadas à conta de Heather. As informações são apresentadas em uma página personalizada da Web do Fabricante de Automóveis "Minha Página".

Figura 5: Compor um serviço Web usando WS-Federated permite que Heather mude perfeitamente de sua página personalizada no Revendedor de Automóveis para sua página personalizada no Fabricante de Automóveis.

A página da Web personalizada de Heather na extranet fabricante de automóveis permite que ela veja que ela atualmente não tem pedidos pendentes; ela tem uma ordem (para 50 SuperTires) em trânsito; e que sua lista de pedidos concluídos inclui 20 unidades da CDPlus e 50 unidades de Limpador de Couro.

Heather clica em "Criar Nova Ordem" e uma nova página é aberta, pré-preenchida com a parte desejada— folhas do apagador WindshieldPro e a data da ordenação. Tudo o que ela precisa para entrar é a quantidade. Todas as outras informações necessárias para concluir o pedido são preenchidas do banco de dados do Fabricante automático.

Figura 6. Um pedido é facilmente feito porque grande parte dos dados de pedidos já foi importado do arquivo de Heather no banco de dados do cliente fabricante de automóveis.

Heather envia o pedido e procura itens adicionais para comprar, ou clica em Logout, para encerrar sua sessão e impedir que qualquer outra pessoa faça um pedido de seu computador autônomo.

Observe que a composição do serviço Web com WS-Federation forneceu ao Revendedor Automático e ao Fabricante de Automóveis custos administrativos mais baixos e segurança de ponta a ponta. Sem essa tecnologia, a Fabricante de Automóveis teria que manter uma lista de todos os funcionários autorizados da concessionária e suas senhas. Isso seria caro, propenso a erros e reduziria a segurança do aplicativo.

Por exemplo, se Heather deixasse o emprego, sua conta de usuário seria removida no Revendedor de Automóveis. Mas, se o administrador da concessionária esqueceu de entrar em contato com a Fabricante de Automóveis sobre sua saída, ela continuaria a ter acesso ao site de compra. Com o WS-Federation, isso não é um problema, pois o único sistema que precisa ser alterado é o serviço provedor de identidade do Revendedor automático. Os sistemas do Fabricante de Automóveis, tanto o aplicativo quanto o Serviço de Autorização, não têm conhecimento inato de Heather, seu nome de usuário ou sua senha.

4.2 Parte 2: a experiência do fornecedor

Embora Heather ordene lâminas de apagamento WindshieldPro da Fabricante de Automóveis, já faz meio século desde que a empresa realmente fez suas próprias lâminas. As folhas do apagador WindshieldPro vêm de um fornecedor, Supplier.

Tony é o representante de vendas da Supplier, e ele começa seu dia registrando-se na intranet do Fornecedor, assim como Heather entrou na intranet do Revendedor de Automóveis. Mas, em vez de usar um navegador da Web padrão, o Tony trabalha com um aplicativo do Windows que tem suporte interno para serviços Web.

Figura 7. A página pessoal de Tony na intranet do Fornecedor o lembra de verificar pedidos e inventário em um de seus principais clientes, o Fabricante de Automóveis.

Quando Tony clica para verificar pedidos e inventário, seu aplicativo usa um serviço Web para pedir dados de inventário que Tony tem permissão para acessar.

Um aspecto fundamental dessa solicitação de dados de serviços Web no nível do aplicativo é que ele é composto por WS-Federation que autentica seu acesso à extranet do Fabricante Automático.

O serviço Web retorna os resultados de volta para a página do Fornecedor, onde é exibido pelo tipo de produto e pela contagem de inventário atual.

Figura 8. Um serviço Web preenche a página Fornecedor do Tony com dados de inventário dos bancos de dados de inventário do Fabricante Automático. A solicitação foi protegida compondo-a com WS-Security e WS-Federation.

O fornecedor entrou em um contrato de compra just-in-time com o Fabricante de Automóveis. Tony está autorizado a fornecer uma ordem de reabastecer automaticamente como parte do Inventário Gerenciado do Fornecedor (VMI) em nome do Fabricante De Automóveis, uma vez que o inventário fica abaixo de 20. Tony clica em WindshieldPro para fazer um pedido. Todas as mensagens entre o Tony e o Fabricante automático são protegidas porque o aplicativo tem suporte dos serviços Web compostos com as proteções do WS-Security.

Figura 9. Um acordo just-in-time com a Fabricante de Automóveis permite que Tony insira um pedido em nome da empresa.

O aplicativo de Tony fornece a ele uma tela para criar solicitações ao Fornecedor com uma ordem de compra do Fabricante automático. Tony ordena que 50 limpadores WindishieldPros sejam enviados diretamente para o Fabricante de Automóveis.

Quando Tony clica em OK, o Serviço de Warehouse, um serviço Web composto com WS-AtomicTransactions, WS-Security e WS-ReliableMessaging, tenta fazer o pedido com outro serviço Web, os Serviços de Warehouse subordinados. Quando uma resposta não é retornada imediatamente do Serviço de Warehouse (devido a uma interrupção temporária de rede) WS-ReliableMessaging continua a reenviar a consulta até receber uma resposta.

Quando o serviço de armazém recebe a ordem, ele os retransmite internamente para os dois armazéns físicos da empresa. Como isso envolve bancos de dados entre ambos os armazéns, WS-AtomicTransaction é usado para garantir o comportamento transacional entre os bancos de dados.

O aplicativo Warehouse divide os pedidos entre os serviços subordinados do Warehouse para garantir a cobertura de inventário, 70% de pedidos vão para o Warehouse 1 e os 30% restantes vão para o Warehouse 2. O Coordenador Raiz no Main Warehouse envia uma mensagem ao Coordenador Raiz do Warehouse 2 solicitando 30% do pedido. O Coordenador Raiz do Warehouse 2 verifica seu inventário e envia uma mensagem ao Coordenador Raiz do Main Warehouse informando que não há inventário suficiente em estoque.

O coordenador raiz principal sabendo que não há inventário suficiente cancela toda a transação e envia uma mensagem para o aplicativo de serviço Web do Tony indicando o status, os níveis de inventário e que a transação foi cancelada. O coordenador raiz começa a fazer backup da transação e, quando concluída, volta para o Warehouse para dizer que a transação foi cancelada.

Tony, com o conhecimento atual do inventário, envia outra solicitação ao Warehouse. O coordenador raiz coordena entre outras entidades transacionais (controlador de outras transações) e envia essa solicitação para os 2 Warehouses que passam pelo mesmo processo de antes. Estamos usando WS-Security para assinar todo o corpo da mensagem, portanto, não importa em qual domínio você esteja, você sabe que está seguro.

Agora, o coordenador raiz confirma as transações, bloqueia os recursos e conclui a transação. Uma mensagem é enviada ao Tony indicando que a transação foi concluída com êxito.

WS-AtomicTransaction redigir com WS-ReliableMessaging e WS-Security nessas mensagens para oferecer um sistema distribuído completo pronto para a empresa.

5.0 Conclusões

IBM, Microsoft e nossos parceiros estão desenvolvendo especificações de serviço Web que podem ser usadas como blocos de construção para uma nova geração de serviços Web avançados, seguros, confiáveis e transacionados.

Essas especificações são projetadas de forma modular e redigir, de modo que os desenvolvedores possam utilizar apenas os recursos necessários. Essa composição "semelhante a componentes" permitirá que os desenvolvedores criem serviços Web avançados de maneira simples e flexível, ao mesmo tempo em que introduzem apenas o nível de complexidade determinado pelo aplicativo específico.

Essa tecnologia permitirá que as organizações criem aplicativos facilmente usando uma SOA (arquitetura de Service-Oriented). Além disso, a IBM e a Microsoft demonstraram aplicativos SOA seguros, confiáveis e transacionados que ilustram a riqueza dos processos de negócios que podem ser criados usando essa abordagem. Além disso, essas demonstrações têm operado em um ambiente de segurança federado em um ambiente heterogêneo que consiste em software IBM WebSphere e Microsoft .NET.

Prevemos que essas tecnologias de Serviço Web estarão disponíveis em sistemas operacionais, middleware, com ferramentas que facilitarão ainda mais o uso dessas tecnologias pelos desenvolvedores. Será interessante ver os aplicativos que surgem à medida que desenvolvedores e organizações usam esses sistemas para criar a próxima geração de soluções baseadas em serviços Web.

6.0 Confirmações

Queremos reconhecer os seguintes indivíduos que contribuíram para essas ideias: (alfabético) Tony Andrews, Bob Atkinson, Keith Ballinger, Don Box, John Brezak, Allen Brown, Felipe Cabrera, Erik Christensen, George Copeland, Michael Coulson, Giovanni Della-Libera, Brendan Dixon, Mike Dusche, Colleen Evans, Max Feingold, Jeff Frey, Henrik Frystyk Nielsen, Praerit Garg, Omri Gazitt, Scot Gellock, Josh Gray, Martin Gudgin, MaryAnn Hondo, Destry Hood, Efim Hudis, Tomasz Janczuk, Jim Johnson, Ryan Johnson, Gopal Kakivaya, Chris Kaler, Johannes Klein, Scott Konersmann, Brian LaMacchia, Dave Langworthy, Andrew Layman, Paul Leach, Al Lee, Frank Leymann, Rodney Limprecht, Joe Long, Steve Lucco, John Manferdelli, Ashok Malhotra, Jonathan Marsh, Steve Millet, Angela Mills, Tony Nadalin, Martin Nally, Karla Norsworthy, Stefan Pharies, Scott Robinson, Yordan Rouskov, Sujay Sahni, Jeff Schlimmer, Oliver Sharp, Yasser Shohoud, Dan Simon, Jeff Spelman, Keith Stobie, Satish Thatte, Robert Wahbe, Elliot Waingold, Richard Ward, Sanjiva Weerawarana, Hervey Wilson, Eric Zinda.