Web Services

Neste artigo veremos uma introdução às tecnologias Web Services: SOA, SOAP, REStful, WSDL e UDDI.

Tutorial sobre WebServices

Antes de nos aprofundarmos nos conceitos e tecnologia de web services, vejamos um pouco sua evolução. No ano de 2000, a W3C (World Wide Web Consortium) aceitou a submissão do Simple Object Access Protocol (SOAP). Este formato de mensagem baseado em XML estabeleceu uma estrutura de transmissão para comunicação entre aplicações (ou entre serviços) via HTTP. Sendo uma tecnologia não amarrada a fornecedor, o SOAP disponibilizou uma alternativa atrativa em relação aos protocolos proprietários tradicionais, tais como CORBA e DCOM.

Guia do artigo:

No decorrer do ano seguinte, o W3C publicou a especificação WSDL. Uma nova implementação do XML, este padrão forneceu uma linguagem para descrever a interface dos web services. Posteriormente suplementada pela especificação UDDI (Universal Description, Discovery and Integration), que proporcionou um mecanismo padrão para a descoberta dinâmica (dynamic discovering) de descrições de serviço, a primeira geração da plataforma de Web services foi estabelecida. A Figura 1 ilustra em alto nível o relacionamento entre estes padrões.

Figura 1. O relacionamento entre especificações de primeira geração

Desde então, os web services foram adotados por vendedores e fabricantes num ritmo considerável. Suporte amplo da indústria seguiu-se à popularidade e importância desta plataforma e de princípios de projeto orientados a serviço. Isto levou à criação de uma segunda geração de especificação de Web services.

Web services e a arquitetura orientada a serviços (SOA)

Entendendo serviços

O conceito de serviços em uma aplicação existe faz algum tempo. Serviços, assim como componentes, são considerados blocos de construção independentes, os quais coletivamente representam um ambiente de aplicação. No entanto, diferente de componentes tradicionais, serviços têm algumas características únicas que lhes permitem participar como parte de uma arquitetura orientada a serviços.

Saiba mais: Curso de Web Service em Java

Uma destas características é a completa autonomia em relação a outros serviços. Isto significa que cada serviço é responsável por seu próprio domínio, o que tipicamente significa limitar seu alcance para uma função de negócio específica (ou um grupo de funções relacionadas).

Este enfoque de projeto resulta na criação de unidades isoladas de funcionalidades de negócio ligadas fracamente entre si. Isto é possível por causa da definição de uma estrutura padrão de comunicação. Devido à independência que esses serviços desfrutam dentro desta estrutura, a lógica de programação que encapsulam não tem necessidade de obedecer a nenhuma outra plataforma ou conjunto de tecnologias.

XML Web services

O tipo de serviço mais largamente aceito e bem sucedido é o XML Web service, que será daqui em diante chamado apenas de web service, ou simplesmente service. Este tipo de serviço possui dois requisitos fundamentais:

A ampla aceitação do web service resultou no surgimento de um conjunto de tecnologias suplementares que se tornaram um padrão de fato. Assim ao desenvolver nossos web services devemos considerar o uso de tecnologias que:

Estas tecnologias não modificam a funcionalidade do núcleo de um serviço web, tanto como o faz sua habilidade para se representar e comunicar num modo padrão. Muitas das convenções de arquitetura expressadas neste artigo assumem que SOAP e WSDL fazem parte da estrutura de web services descrita. Além disto, é normal que um Web service seja:

Numa conversação típica com um web service, o cliente iniciador do pedido é um web service também. Como mostrado na Figura 2, qualquer interface exposta por este client service também o qualifica como um serviço a partir do qual outros serviços podem solicitar informação. Posto isto, web services não se encaixam no modelo clássico de cliente-servidor. Na verdade, eles tendem a estabelecer um sistema ponto-a-ponto, onde cada serviço pode atuar como cliente ou servidor.

Figura 2. Troca de papéis do Web services durante uma conversação

Service-oriented architecture (SOA)

Como mencionado anteriormente, adicionar uma aplicação com uns poucos web services não é nenhum problema. Esta integração limitada pode ser apropriada para uma experiência de aprendizado, ou para complementar a arquitetura de uma aplicação existente com uma peça de funcionalidade baseada em serviços que atende a um requisito específico do projeto. No entanto, isto não estabelece uma arquitetura orientada a serviço. Existe uma clara diferença entre:

Uma SOA é um modelo de projeto com um conceito profundamente amarrado à questão do encapsulamento de aplicação. A arquitetura resultante estabelece essencialmente um paradigma de projeto, no qual web services são os blocos de construção chave. Isto quer dizer que ao migrar a arquitetura da sua aplicação para uma SOA, estabelece-se um compromisso com os princípios de projeto de web services e a tecnologia correspondente, como partes fundamentais do seu ambiente técnico.

Uma SOA baseada em XML web service é construída sobre camadas de tecnologia XML estabelecidas, focada em expor a lógica de aplicação existente como um serviço fracamente acoplado. Para apoiar este modelo, uma SOA promove o uso de um mecanismo de discovery por serviços via um service broker ou discovery agent.

A Figura 3 mostra como uma SOA altera a arquitetura multicamada existente, ao introduzir uma camada lógica que, através do uso de interfaces programáticas padrão (providas pelo web services), estabelece um ponto comum de integração. Esta camada de integração de serviços constitui a base para um novo modelo que pode se estender além do escopo de uma única aplicação, unificando plataformas legadas díspares em um ambiente aberto. Quando web services são utilizados para integração cruzada de aplicações (ver Figura 4), elas se estabelecem como parte da infra-estrutura do sistema.

Figura 3. Uma representação lógica de uma arquitetura orientada a serviços
Figura 4. Uma representação lógica de uma arquitetura de integração orientada a serviço

É importante se conscientizar quanto ao acréscimo de complexidade de projeto introduzido pelo SOA. Mais ainda do que em um ambiente n-camada, projetistas de aplicação devem considerar de uma forma completa como a introdução de serviços vai afetar dados existentes e modelos de negócio.

Na medida em que a utilização de serviços se diversifica, o significado dos requisitos de segurança e escalabilidade são amplificados. Ambientes orientados a serviço bem projetados tentarão vencer estes desafios com infra-estrutura adequada, ao invés de utilizar soluções sob medida, específicas de aplicação

Saiba mais: O que é RESTful? Diferença entre REST e RESTful

Os papéis e cenários ilustrados nas próximas duas seções estão limitados somente ao assunto web service. A estrutura de mensagens SOAP subjacente será explicada em separado, no próximo artigo desta série.

Funções de um web service

Serviços podem assumir diferentes funções quando envolvidos em diversos cenários de interação. Dependendo do contexto pelo qual é visualizado, assim como o estado da tarefa rodando no momento, o mesmo web service pode trocar de papéis ou ser designado para múltiplos papéis simultâneos:

Provedor de serviços

Agindo como um provedor de serviços, um web service expõe uma interface pública através da qual pode ser chamado por solicitantes do serviço. Um provedor de serviços disponibiliza esta interface publicando uma descrição do serviço. Num modelo cliente-servidor, o provedor de serviço pode ser comparado ao servidor.

O termo “provedor de serviço” pode também ser usado para descrever a organização ou ambiente que hospeda (provê) o web service.

Um provedor de serviço pode também agir como um solicitante de serviço. Por exemplo, um web service pode atuar como um provedor de serviço quando um solicitante de serviço lhe pede para executar uma função. Pode então atuar como um solicitante de serviço quando mais tarde contata o solicitante de serviço original (agora agindo como um provedor de serviço) para solicitar informação de status.

Solicitante de serviço

Um solicitante de serviço é o remetente de uma mensagem web service ou o programa de software solicitando um web service específico. O solicitante de serviço é comparável ao cliente dentro de um modelo cliente-servidor padrão. Solicitantes de serviços são às vezes chamados de consumidores de serviços.

Um solicitante de serviço pode também ser um provedor de serviço. Por exemplo, num modelo de solicitação e resposta, o web service iniciador primeiro age como um solicitante de serviço ao requerer informações do provedor de serviço. O mesmo web service então, faz o papel de um provedor de serviço ao responder à solicitação original.

Intermediário

O papel de intermediário é assumido pelo web service quando ele recebe a mensagem de um solicitante de serviço e a passa adiante para o provedor de serviço. Neste caso, ele  pode também agir como um provedor de serviço (recebendo a mensagem) e como um solicitante de serviço (passando adiante a mensagem).

Intermediários podem existir em muitas formas diferentes. Alguns são passivos e simplesmente re-transmitem ou roteam as mensagens, enquanto outros processam ativamente uma mensagem antes de repassá-la. Tipicamente, aos intermediários só é permitido o processamento e modificação do cabeçalho da mensagem. Para preservar a integridade da mensagem, seus dados não devem ser alterados.

Remetente inicial

Como o web service responsável por iniciar a transmissão da mensagem, remetentes iniciais também podem ser considerados solicitantes de serviço. Este termo existe para ajudar a diferenciar o primeiro web service que envia uma mensagem, dos intermediários também qualificados como solicitantes de serviço.

Receptor final

O último Web service a receber uma mensagem é o receptor final. Estes serviços representam o destino final de uma mensagem e também podem ser considerados provedores de serviço.

Interação de web service

Quando mensagens são passadas entre dois ou mais web services, uma variedade de cenários de interação pode acontecer. A seguir, termos comuns utilizados para identificar e etiquetar estes cenários serão apresentados.

Caminho da mensagem

A rota pela qual a mensagem viaja é o caminho da mensagem. Deve consistir de um remetente inicial e um receptor final e pode conter nenhum, um, ou mais de um intermediários. A Figura 5 ilustra um caminho de mensagem simples.

O caminho de transmissão atual percorrido por uma mensagem pode ser dinamicamente determinado por roteadores intermediários. A lógica de roteamento pode ser ativada em resposta à carga de requisitos de balanceamento, ou pode ser baseada nas características da mensagem e outras variáveis lidas e processadas pelo intermediário em tempo de execução. A Figura 6 descreve como uma mensagem é enviada via um ou dois caminhos de mensagem possíveis, tal como é determinado pelo roteador intermediário.

Figura 5. Um caminho de mensagem formado por três Web services
Figura 6. Uma mensagem dinamicamente determinada por um roteador intermediário

Padrão de troca de mensagens

Serviços que interagem em um ambiente orientado a serviços tipicamente se enquadram em determinados padrões de troca de mensagens. Padrões típicos incluem:

O padrão pedido e resposta é o mais comum quando se está simulando intercâmbio de dados síncronizados. Os demais padrões são usados principalmente para facilitar transferência de dados assíncrona.

Correlação

Correlação (Correlation) é a técnica utilizada para casar mensagens enviadas através de caminhos de mensagem diferentes. É comumente empregada num padrão de intercâmbio de pedido e resposta de mensagem, onde a mensagem de resposta deve estar associada à mensagem original que iniciou a solicitação. Embutir valores de ID sincronizados dentro de mensagens relacionadas é uma técnica frequentemente utilizada para conseguir correlação.

Coreografia

Regras que governam características de comportamento relacionadas à forma como um grupo de web services interagem podem ser aplicadas como uma coreografia (choreography). Estas regras incluem a seqüência na qual web services podem ser chamados, condições que se aplicam à seqüência que está sendo transportada e o padrão de uso que irá definir os cenários de interação permitidos. O escopo de uma coreografia está tipicamente amarrado ao de uma atividade ou tarefa (ver exemplo na Figura 7).

Figura 7. A sequência de interação de um grupo de serviços sendo comandados por uma coreografia

Atividade

Padrões de intercâmbio de mensagens formam a base para atividades de serviços (também conhecidos como tarefas). Uma atividade consiste de um grupo de web services que interagem e colaboram para realizar uma função ou um grupo lógico de funções. A Figura 8 mostra uma atividade de serviço simples. A diferença entre uma coreografia e uma atividade está no fato de que a atividade é geralmente associada com uma função de aplicação específica, tal como a execução de uma tarefa de negócio.

Figura 8. Uma atividade de serviço envolvendo três serviços

Descrição da estrutura de web services

Um web service é descrito através de uma coleção de documentos de definição. Estes atuam como blocos de construção para uma descrição de serviço:

A Figura 9 ilustra a relação entre esses documentos.

Figura 9. Conteúdo de uma descrição de serviço

Abstrato

A descrição de uma interface web service, independente dos detalhes de implementação, é chamada de abstrato (abstract). Descrições deste elemento são fornecidas adiante neste artigo, como parte do tutorial do WSDL.

Concreto

Localização e informação de implementação específicas sobre um web service constituem as partes concretas (concrete) de um documento WSDL. Elas são representadas pelos elementos de ligação (binding), serviço (service) e ponto-de-término (endpoint ou port).

Definição de serviço

Geralmente, o conteúdo de um documento WSDL constitui uma definição de serviço (service definition) que inclui as definições da interface (abstrato) e da implementação (concreto).

Descrição de serviço

Frequentemente, uma descrição de serviço é um único documento WSDL que fornece uma definição de serviço. No entanto, pode também incluir vários documentos de definição adicionais que irão fornecer informações complementares.

Introdução aos Web services de primeira geração

A estrutura W3C para web services está fundamentada em três especificações XML fundamentais:

Estes padrões de tecnologia, acoplados aos princípios de projeto orientado a serviço, formam um SOA fundamentado na tecnologia XML. Esta arquitetura de web services de primeira geração permite a criação de web services independentes capazes de encapsular unidades isoladas de funcionalidades de negócio. Esta tecnologia tem também algumas limitações, que tem sido contempladas numa segunda geração de especificações. A seção a seguir, fornece um tutorial introdutório para a tecnologia WSDL. SOAP e UDDI serão vistos no próximo artigo da série.

Linguagem para definição de Web Services (WSDL)

Web services devem ser definidos numa forma consistente para que possam ser descobertos e “interfaceados” com outros serviços e aplicações. A WSDL é uma especificação W3C que fornece a linguagem mais avançada para a descrição de definições de web services.

A camada de integração introduzida pela estrutura de web services estabelece um padrão, universalmente reconhecido e com interface programática suportada. Tal como mostrado na Figura 10, WSDL permite a comunicação entre essas camadas ao fornecer descrições padronizadas.

Figura 10. Documentos WSDL representando aplicações web services

A melhor forma de entender como é definido um web service e como ele é expresso por um documento WSDL, é caminhar através de cada construtor que coletivamente representa essa definição. Comecemos com o elemento definitions raiz, o qual age como o conteiner para a definição do serviço (ver Listagem 1).

<definitions> <interface name='Catalog'> ... </interface> <message name='BookInfo'> ... </message> <service> ... </service> <binding name='Binding1'> ... </binding> </definitions>
Listagem 1. Uma definição de serviço, tal como é expressa pelo construtor definitions

Uma definição WSDL pode conter coleções dos seguintes construtores primários:

A Figura 11 ilustra como os primeiros dois construtores representam a definição da interface de serviço e os últimos dois fornecem os detalhes de implementação do serviço.

Figura 11. O conteúdo de um documento WSDL, tal como se relaciona com uma definição de serviço

Definição de interface abstrata

Interfaces de web services individuais são representadas por elementos interface WSDL. Estes construtores contêm um grupo de operações lógicas correlatas. Numa arquitetura baseada em componentes, um elemento interface WSDL é análogo à interface do componente. Uma operação, portanto, é equivalente a um método de componente, por representar uma única ação ou função. A Listagem 2 apresenta um exemplo de interface.

Saiba mais sobre Web Services ;)

  • Primeiros passos para a segurança de web services RESTful em Java: Aprenda a programar um mecanismo de autenticação utilizando a API JAX-RS e sua implementação de referência, o framework Jersey, para criar web services RESTful seguros.
  • JWT: Web services seguros em Java: Aprenda a programar web services RESTful seguros utilizando JWT (JSON Web Tokens). Para isso tomaremos como base uma Web API que já fornece um CRUD de marcas e produtos, mas que ainda não provê nenhum mecanismo de segurança, nenhum controle de autenticação e autorização.
  • Web services RESTful com Spring framework e JPA: Neste curso você vai aprender a criar sua primeira API REST baseada nos recursos do Spring Framework. Veremos como declarar corretamente os verbos HTTP em cada recurso consumido e também como definir, de forma apropriada, o status de cada resposta fornecida pela API.
<definitions> <interface name='Catalog'> <operation name='GetBook'> ... </operation> </interface> </definitions>
Listagem 2. Uma interface representada pelo elemento interface

Um elemento operation típico consiste de um grupo de mensagens de entrada e saída correlatas. A execução de uma operation requer a transmissão ou intercâmbio destas mensagens entre o serviço solicitante e o provedor de serviço.

Mensagens operation são representadas por construtores message que são declarados sob os elementos definitions. Os nomes das mensagens são então referenciados nos elementos filho das operation input ou output (ver Listagem 3).

<definitions> <message name='BookInfo'> ... </message> <interface name='Catalog'> <operation name='GetBook'> <input name='Msg1' message='BookInfo'/> </operation> </interface> </definitions>
Listagem 3. O elemento input dentro do construtor operation referenciando um bloco de mensagem

Um elemento message pode conter um ou mais parâmetros input ou output que pertencem a uma operation. Cada elemento part define um destes parâmetros. Ele fornece um conjunto nome/valor (name/value), junto com o tipo de dado associado. Em uma arquitetura baseada em componentes, um part WSDL equivale a um parâmetro de input ou output (ou um valor de retorno) de um método de componente (ver Listagem 4).

<definitions> <message name='BookInfo'> <part name='title' type='xs:string'> Field Guide </part> <part name='author' type='xs:string'> Mr. T </part> </message> </definitions>
Listagem 4. Um bloco de mensagem com um construtor part representando parâmetros operation

A seguir, um breve resumo dos construtores fundamentais que podem ser montados para estabelecer uma definição de interface abstrata:

Definição concrete (implementação)

Sobre os detalhes de implementação, usando os elementos descritos nesta seção, um documento WSDL pode estabelecer detalhes “concrete” de ligação para protocolos, tais como SOAP e HTTP.

Dentro de um documento WSDL, o elemento service representa um ou mais pontos-de-término nos quais o web service pode ser acessado. Estes pontos-de-têrmino consistem de informações de localização e protocolo e são armazenados numa coleção de elementos endpoint (ver Listagem 5).

<definitions> <service name='Service1'> <endpoint name='EndPoint1' binding='Binding1'> ...concrete implementation details... </endpoint> </service> </definitions>
Listagem 5. O elemento ponto-de-término

Agora que descrevemos como um web service pode ser acessado, precisamos definir os requisitos de chamada para cada uma das suas operations. Os elementos binding associam às operations informações de formato de protocolo e mensagem. O construtor operation que reside dentro do bloco binding é semelhante a sua contrapartida na seção interface (ver Listagem 6).

<definitions> <service name='Service1'> <binding name='Binding1'> <operation> <input name='Msg1' message='book'/> </operation> </binding> </service> </definitions>
Listagem 6. O elemento binding representando uma operation existente

A descrição de informação concrete dentro de um documento WSDL pode ser resumida assim:

Simple Object Access Protocol - SOAP

pesar de ter sido inicialmente concebido como a tecnologia para transpor a brecha entre plataformas baseadas em comunicação RPC, SOAP se tornou em um dos mais conhecidos formatos de mensagens e protocolo utilizado por web services baseados em XML. Por este motivo, o acrônimo SOAP é referido freqüentemente como Service-Oriented Architecture (or Application) Protocol (protocolo de arquitetura orientada a serviços) ao invés de Simple Object Access Protocol.

A especificação SOAP estabelece um formato padrão de mensagem que consiste em um documento XML capaz de hospedar dados RPC e centrados em documentos (document-centric) (ver Figura 1). Isto facilita o intercâmbio de dados de modelos síncronos (pedido e resposta) e assíncronos (orientado a processo). Com o WSDL estabelecendo um formato de descrição padrão para aplicações, o uso do formato de mensagem document-centric é muito mais comum.

Figura 1. SOAP estabelece dois formatos de mensagem padrão primários

A arquitetura que exploraremos ao longo deste artigo faz referência a ambos os tipos de formatos de mensagem, utilizando os símbolos padrão de diagramação fornecidos na Figura 2.

Figura 2. Símbolos utilizados para representar mensagens SOAP: (a) document-centric e (b) RPC

Adicionalmente, discutiremos o uso de anexos em mensagens SOAP. Estes são descritos em diferentes especificações de web services de segunda geração: os padrões WS-Attachmentes e SOAP Messages with Attachments – SwA. Mensagens SOAP contendo anexos são representados com o símbolo mostrado na Figura 3.

Figura 3. O símbolo usado para representar mensagens SOAP entregando seus dados como um anexo

Arquitetura de mensagens SOAP

SOAP estabelece um método de comunicação baseado em um modelo de processamento que está relativamente alinhado com a arquitetura de web services descrita na primeira parte deste artigo. Esse protocolo introduz termos e conceitos relacionados ao modo pelo qual mensagens devem ser manipuladas.

Nós SOAP

Um nó SOAP representa o processamento lógico responsável pela transmissão, recebimento e realização de uma série de tarefas sobre mensagens SOAP. Uma implementação de um nó SOAP é tipicamente específica à plataforma e é normalmente rotulado como um SOAP server (servidor) ou SOAP listener (ouvinte). Existem também variações especializadas, tais como SOAP routers (roteadores). A Figura 4 estabelece o nó SOAP como o mecanismo de transporte subjacente a um web service.

Figura 4. Um nó SOAP

Tipos de nós SOAP

Nós SOAP podem existir como emissores iniciais, intermediários e receptores finais. Nós SOAP realizando tarefas de envio e recebimento são chamados de SOAP senders e SOAP receivers (ver Figura 5). A especificação SOAP, no entanto, não classifica isto como papeis. Para os propósitos deste artigo, nos referiremos a eles como “tipos” de nós SOAP.

Figura 5. Tipos fundamentais de nós SOAP ao longo de uma rota de mensagem

A Figura 6 mostra um nó SOAP agindo como um intermediário. Ele transaciona através de ambos os tipos SOAP, receptor e emissor, durante o processamento de uma mensagem SOAP.

Figura 6. Nó SOAP intermediário

Assim como nos papeis atribuídos aos web services, o mesmo nó SOAP pode assumir comportamentos diferentes dependendo da sua posição dentro da rota da mensagem e do estado da atividade de negócio atual. Por exemplo, um nó SOAP como um emissor inicial ao transmitir uma mensagem pode, em outro momento, assumir o papel de receptor final e também receber uma resposta enviada por um outro nó.

Estrutura das mensagens SOAP

O recipiente da informação de uma mensagem SOAP é chamado de envelope SOAP. Descreveremos na Listagem 1 a estrutura de uma típica mensagem SOAP. O elemento raiz Envelope, que delimita o documento da mensagem, é composto por uma seção Body e uma área Header que é opcional.

<env:Envelope xmlns:env='https://www.w3.or/2003/05/soap-envelope'> <env:Header> ... </env:Header> <env:Body> ... </env:Body> </env:Envelope>
Listagem 1. Esqueleto do envelope de um SOAP

O cabeçalho SOAP é representado através do uso de um construtor Header, o qual pode conter um ou mais blocos ou seções. O uso mais comum de blocos Header ocorre em:

Enquanto uma mensagem SOAP trafega até o seu destino, intermediários podem acrescentar, remover ou processar as informações contidas no Header. Mesmo sendo parte opcional de uma mensagem SOAP, o uso da seção Header para carregar informações é muito comum quando se trabalha com especificações web services de segunda geração.

A única parte de uma mensagem SOAP que é obrigatória é o corpo (Body). Esta seção age como um recipiente para os dados que são entregues pela mensagem. Esses dados são frequentemente chamados de carga útil ou dados de carga útil (ver Listagem 2).

<env:Envelope xmlns:env='https://www.w3.or/2003/05/soap-envelope'> <env:Body> <env:Fault> <env:Code> <env:Value> env:VersionMismatch </env:Value> </env:Code> <env:Reason> <env:Text xml:lang='en'> versions do not match </env:Text> </env:Reason> </env:Fault> </env:Body> </env:Envelope>
Listagem 3. Um exemplo de construtor Fault que fornece informação de erro

Papeis de nós SOAP

Agora que demos uma olhada na estrutura interna e na sintaxe de uma mensagem SOAP, encerraremos este assunto com uma breve introdução aos possíveis papeis que um nó SOAP pode assumir.

Nós SOAP só podem assumir um determinado papel se eles executarem uma função de recepção, ou seja, se forem receptores intermediários ou finais (ver Figura 7).

Para indicar que um nó SOAP possui em papel, o atributo env:role deve ser usado. Esse atributo permite que uma mensagem SOAP identifique blocos de cabeçalho destinados a tipos específicos de receptores SOAP.

Figura 7. Papeis que podem ser assumidos recepcionando nós SOAP

Os dois valores de atributos env:role mais comuns são next (próximo) e ultimateReceiver (receptor final). Um nó intermediário processará somente blocos com cabeçalhos identificados com o papel next, enquanto que um nó agindo como o receptor final, processará os dois.

Universal Description, Discovery, and Integration - UDDI

Um componente fundamental da arquitetura orientada a serviço é o mecanismo pelo qual descrições web services podem ser descobertas por requisitantes potenciais. Para estabelecer esta parte de um framework baseado em web service, é necessário um diretório centralizado para hospedar as descrições dos serviços utilizados. Tal diretório pode se tornar uma parte integrada de uma organização ou de uma comunidade disponibilizada na internet.

Esta é a razão pela qual a UDDI tem crescido em importância. Um aspecto chave da UDDI é a padronização da descrição que é armazenada em tais diretórios, também conhecidas como registro. Um registro público de negócio é um diretório global de descrições de serviços internacionais de negócios. Instâncias deste registro são hospedadas em um grupo de servidores UDDI dedicados.

Esses registros UDDI são replicados automaticamente entre instâncias de repositórios. Algumas empresas também agem como registradoras de UDDI, permitindo que outros adicionem e editem seus perfis de descrições web service.

Registros privados são repositórios de descrições de serviços hospedados dentro de uma organização (ver Figura 8). Aqueles autorizados a acessar este diretório geralmente são parceiros de negócios externos. Um registro restrito a usuários internos só pode ser referenciado como registro interno.

Figura 8. Descrições de serviço centralizados em um registro UDDI privado

O processo de descobrimento pode ocorrer em várias situações dependendo da necessidade da informação de serviço. Por exemplo:

Registros UDDI organizam as entradas de registro utilizando seis tipos de dados primários:

As entidades de negócios, tal como representados pelo elemento businessEntity, fornecem informação de perfil acerca do negócio registrado, incluindo seu nome, descrição e identificador unívoco. A Listagem 4 apresenta um documento XML exemplo contendo o construtor businessEntity.

<businessEntity xmlns:xsd="https://www.w3.org/2001/XMLSchema" xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance" businessKey="e9355d51-32ca-49cf-8eb4-1ce59aafbf4a7" operator="Microsoft Corporation" authorizedName="Thomas Erl" xmlns="um.uddi-org:api_v2"> <discoveryURLs> <discoveryURL useType="businessEntity"> https://test.uddi.microsoft.com/discovery?businessKey= e9355d51-32ca-49cf-8eb4-1ce59aafbf4a7 </discoveryURL> </discoveryURLs> <name xml:lang="en"> XMLTC Consulting Inc </name> <description xml:lang="en"> XMLTC has been building end-to-end enterprise eBusiness solutions for corporations and government agencies since 1996. We offer a wide range of design, development and integration services </description> <businessServices> <businessService serviceKey="leeecfal-6f99-460e-a392-8328d38b763a" businessKey="e9355d51-32ca-49cf-8eb4-1ce59aafbf4a7"> <name xml:lang="en-us"> Coporate Home Page </name> <bindingTemplates> <bindingTemplate bindingKey="48b02d40-0312-4293-a7f5-4449ca190984" serviceKey="leeecfal-6f99-460e-a392-8328d38b763a"> <description xml:lang="en"> Entry point into the XMLTC Web site through which a number of resource sites can be accessed </description> <accessPoint URLType="http"> https://www.xmltc.com/ </accessPoint> <tModelInstanceDetails /> </bindingTemplate> </bindingTemplates> <categoryBag> <keyedReference tModelKey="um.uddi:cl acf26d-9672-4404-9d7039b756e62ab4" KeyName="Namespace" KeyValue="namespace" /> </categoryBag> </businessService> </businessServices> </businessEntity>
Listagem 4. Um documento businessEntity real, recuperado de um serviço público de registro

Examinaremos a partir de agora este documento para analisar os construtores individuais. Começaremos pela Listagem 5.

<businessEntity xmlns:xsd="https://www.w3.org/2001/XMLSchema" xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance" businessKey="e9355d51-32ca-49cf-8eb4-1ce59aafbf4a7" operator="Microsoft Corporation" authorizedName="Thomas Erl" xmlns="um:uddi-org:api_v2">
Listagem 6. O construtor discoveryURL contendo a URL original

O elemento name simplesmente contém o nome oficial de negócio (ver Listagem 7).

<name xml:lang="en"> XMLTC Consulting Inc </name>
Listagem 7. O elemento name fornecendo o nome de negócio

Registros businessService representando o serviço atual oferecido pelo negócio registrado são aninhados dentro do construtor businessEntity como pode ser observado na Listagem 8.

<businessServices> <businessService serviceKey="leeecfal-6f99-460e-a392-8328d38b763a" businessKey="e9355d51-32ca-49cf-8eb4-1ce59aafbf4a7"> <name xml:lang="en-us"> Corporate Home Page </name> <bindingTemplates> <bindingTemplate bindingKey="48b02d40-0312-4293-a7f5-4449ca190984" serviceKey="leeecfal-6f99-460e-a392-8328d38b763a"> <description xml:lang="en"> Entry point into the XMLTC Web site through wich a number of resource sites can be accessed </description> <accessPoint URLType="http"> https://www.xmltc.com/ </accessPoint> <tModelInstanceDetails /> </bindingTemplate> </bindingTemplates> <categoryBag> <keyedReference tModelKey="um.uddi:cl acf26d-9672-4404-9d7039b756e62ab4" KeyName="Namespace" KeyValue="namespace" /> </categoryBag> </businessService> </businessServices>
Listagem 8. O construtor businessService

Um serviço de negócio é identificado por um valor único conferido ao atributo serviceKey. Seu pai, o elemento businessEntity, é referenciado pelo atributo businessKey (ver Listagem 9).

<businessService serviceKey="leeecfal-6f99-460e-a392-8328d38b763a" businessKey="e9355d51-32ca-49cf-8eb4-1ce59aafbf4a7"> ..... </businessService>
Listagem 9. Os atributos dos elementos serviceKey e businessKey do businessService

O único businessService associado com esta entidade de negócio é a home page do negócio, como identificada pelo elemento name (ver Listagem 10).

<name xml:lang='en-us'> Corporate Home Page </name>
Listagem 10. O elemento name com o serviceName

Cada businessService fornece ponteiros de especificação. Também conhecidos como binding templates, estes registros consistem de endereços ligando o business service à informação de implementação. Utilizando service pointers (ponteiros de serviço), um desenvolvedor pode saber como e onde se ligar fisicamente a um web service (ver Listagem 11).

<bindingTemplates> <bindingTemplate bindingKey="48b02d40-0312-4293-a7f5-4449ca190984" serviceKey="leeecfal-6f99-460e-a392-8328d38b763a"> <description xml:lang="en"> Entry point into the XMLTC Web site through wich a number of resource sites can be accessed </description> <accessPoint URLType="http"> https://www.xmltc.com/ </accessPoint> <tModelInstanceDetails /> </bindingTemplate> </bindingTemplates>
Listagem 11. O construtor bindingTemplate alojando informação de localização concreta

O construtor bindingTemplate exibido no exemplo anterior estabelece a localização e descrição do serviço, utilizando os elementos accessPoint e description.

Várias categorias podem ser atribuídas a serviços de negócio. No nosso exemplo, a URL que identificamos foi classificada como um namespace utilizando o elemento filho keyedReference do construtor categoryBag (ver Listagem 12).

<categoryBag> <keyedReference tModelKey="um.uddi:cl acf26d-9672-4404-9d7039b756e62ab4" KeyName="Namespace" KeyValue="namespace" /> </categoryBag>
Listagem 12. O elemento categoryBag fornecendo a categorização mediante a utilização do elemento aninhado keyedReference

Finalmente, dados de relações de negócio e de subscrição são representados por elementos publisherAssertions e subscription, respectivamente. Construtores publisherAssertions fornecem meios de estabelecer a relação da businessEntity atual com uma outra. Subscription permite que os assinantes sejam notificados quando a informação do perfil da entidade de negócio foi atualizada.

Vale ressaltar que não existe uma relação de formato entre UDDI e WSDL. Um registro UDDI fornece meios para apontar para as definições da interface de serviços.

Conclusão

Essa série de artigos teve com principal objetivo apresentar uma tecnologia que está se popularizando cada vez mais: os web services. O principal motivo relacionado a essa popularização é o grande desacoplamento entre os diferentes serviços, que possibilita uma fácil e rápida construção das aplicações.

Nota: Thomas Erl é consultor independente e arquiteto chefe da XMLTC Consulting em Vancouver, no Canadá. Ele é conhecido por seus trabalhos no modelo de escopo em camadas para XML e Web Services e, no framework de integração de Web Services (XWIF).

Saiu na DevMedia!

  • Primeiros passos na JSF com Ajax: Aprenda a enviar um formulário com Ajax utilizando componentes da JSF. Neste curso você dará os seus primeiros passos na programação com Ajax na JSF e aprenderá a utilizar esse mecanismo com validações de campos do formulário, geradas no back-end da aplicação pela Bean Validation.
  • CDI 2.0: avanços no Java EE e além: Injeção de dependências é um pilar do desenvolvimento moderno; com CDI 2.0, esta ferramenta será disponível para desenvolvedores Java SE. A nova versão de CDI também traz avanços para programação assíncrona, que é um tópico muito relevante para a performance de uma aplicação.
  • O que é JWT?: Você sabe o que é JWT? Talvez este seja um dos termos que você mais tenha escutado nos últimos meses, não é verdade? Mas, por que JWT? Qual a importância dele no desenvolvimento de software hoje em dia? Onde o JWT é utilizado?
  • Vale a pena ver CSS de novo: O programador está sempre preocupado em utilizar bem o seu tempo. Com isso em mente, saiba que os recursos mais modernos do CSS3 podem nos ajudar a nos dedicarmos mais ao back-end da aplicação, como veremos neste DevCast.

Artigos relacionados