Tecnologias de Apoio aos Web Services

Para entender melhor como as tecnologias trabalham no ambiente Web Services, deve-se observar onde estas tecnologias se encaixam no WSA. O objetivo destas tecnologias

é definir uma perspectiva de ferramentas que podem ser usadas para projeto, construção e implantação de Web Services.

As principais tecnologias dos Web Services são o XML [74], SOAP [24], WSDL [11] e UDDI [42].

No entanto, há ainda, uma gama de tecnologias que estendem a capacidade destas ou servem de apoio a elas. Estas outras tecnologias podem ser encontradas no documento “List of Web Services Specifications Compiled by Roger Cutler and Paul Denning” [14].

XML

XML (eXtensible Markup Language) é uma linguagem muito parecida com HTML (Hyper Text Markup Language), mas com a possibilidade de definir tags, que são marcações de dados (meta–markup language) [74]. Essas tags fornecem um formato para descrever dados estruturados. O XML provê um sistema para criar dados diferentes do HTML que define apenas formatação de textos e caracteres. A Figura 2.6 apresenta um trecho de um arquivo XML.

Figura 2.6: Trecho de um arquivo XML

XML é a tecnologia chave para atender à comunicação independente nos Web Services. As empresas descobriram os benefícios de usar XML para a integração dos dados internamente, compartilhando seus dados entre departamentos, e externamente, compartilhando-os com outras empresas. Graças a isto, XML tornou-se rapidamente o padrão como tecnologia para representação de dados para negócios de Computação na Web [74].

SOAP

SOAP (Simple Object Access Protocol) é um protocolo que define uma estrutura padrão de interoperabilidade, um mecanismo de RPC (Remote Procedure Call), um framework para empacotar e desempacotar mensagens XML entre o Servidor e o Cliente [24].

Normalmente, os envelopes, nome dado às mensagens SOAP, são transmitidos via HTTP [27] ou SMTP [52] devido ao seu fácil acesso, mas é possível transmitir SOAP sob praticamente qualquer protocolo.

Uma mensagem SOAP está representada na Figura 2.7. O envelope SOAP (SOAPEnvelope) é a parte obrigatória de uma mensagem SOAP. Ele funciona como um recipiente de todos os outros elementos da mensagem, possivelmente o cabeçalho e o corpo, assim como os namespaces de cada um. Um envelope SOAP consiste basicamente em:

Um cabeçalho composto por zero ou mais entradas; Um corpo composto por zero ou mais entradas;

SOAP Message (an XML document) SOAPPart SOAPEnvelope SOAPHeader(optional) header header SOAPBody XML content SOAPFault (optional)

Atualmente, o termo SOAP não mais define um único significado. Existem duas definições para este termo que refletem diferentes caminhos em que a tecnologia pode ser interpretada como:

• Service Oriented Architecture Protocol: no caso geral, uma mensagem SOAP representa a informação que você precisa para invocar um serviço ou analisar o resultado desta chamada, junto com a informação específica da definição da interface do serviço;

• Simple Object Access Protocol: quando você usa uma representação opcional do SOAP RPC, a mensagem SOAP representa um método de invocação do objeto remoto, e a serialização dos argumentos do método que precisam ser movidos do ambiente local para um ambiente remoto.

WSDL

WSDL (Web Service Description Language) descreve a interface do serviço de forma estruturada e padronizada em XML [11].

O WSDL [11] é a linguagem para descrição de Web Services. Com WSDL especifica-se:

o que o serviço faz;

como chamar suas operações; onde encontrar o serviço.

WSDL descreve os Web Services começando com as mensagens que são trocadas entre os agentes requisitores e provedores. As mensagens são descritas de forma abstrata e limitadas a um formato concreto do protocolo e da mensagem de rede. A Figura 2.8 apresenta a estrutura de um arquivo WSDL.

Os componentes são:

• wsdl:types: Tipos de dados;

• wsdl:message: Parâmetros de entrada e saída de um serviço;

• wsdl:operation: Representa a assinatura do método (operações) e o relacionamento entre parâmetros de entrada e saída;

• wsdl:portType: Agrupamento lógico de operações, denominado de tipo de porta;

• wsdl:binding: Define o protocolo a ser usado para acessar os métodos de um objeto (SOAP, HTTP ou MIME);

• wsdl:service: Endereço do serviço. Além dos componentes acima, esta tag define um serviço.

wsdl:definitions wsdl:types wsdl:message wsdl:binding wsdl:port Type wsdl:operation wsdl:service wsdl:port

Figura 2.8: Estrutura do Arquivo WSDL

Uma visão mais detalhada do WSDL em uso pode ser definida nas seguintes etapas: 1. O provedor do serviço cria um Web Service e registra-o em um Universal

Description, Discovery and Integration (UDDI). É através do UDDI [42] que um sócio de negócio ou outro sistema ou clientes podem encontrar o serviço; 2. Um requisitor de serviço encontra o diretório de Web Services e procura o

serviço que lhe interessa. A informação do registro de UDDI é usada para

encontrar o documento original WSDL, detalhando a estrutura das chamadas para o(s) serviço(s) desejado(s), que inclui informações tais como parâmetros do serviço e protocolo;

3. Usando a informação fornecida no documento correspondente do WSDL, o programador pode escrever um acesso para o cliente deste serviço, ou simplesmente usar a informação para criar uma mensagem SOAP em baixo- nível usando o protocolo SOAP [24].

UDDI

UDDI (Universal Description, Discovery and Integration) corresponde a um Web Service registry, que provê um mecanismo para busca e publicação de Web Services [42].

Um UDDI registry contém informações categorizadas sobre os serviços e as funcionalidades que eles oferecem, e permite a associação desses serviços com suas informações técnicas, geralmente definidas usando WSDL. Como dito anteriormente, o arquivo de descrição em WSDL descreve as funcionalidades do Web Service, a forma de comunicação e sua localização. Devido ao modo de acesso, um UDDI registry também pode ser entendido como um Web Service. A Figura 2.9 apresenta as interações com o UDDI registry.

Figura 2.9: Interações com UDDI registry [42]

A Figura 2.9 pode ser descrita da seguinte maneira:

1. Os Arquitetos de Negócios populam o registry com especificações abstratas dos serviços disponibilizados pela organização. Estas informações são denominadas de modelos técnicos de negócios, ou mais comumente chamados de tModels. Em muitos casos, o tModel contém a localização do arquivo WSDL que descreve a interface SOAP do Web Service;

2. Usuários especializados da organização populam o registry com informações sobre a organização e suas unidades;

3. Desenvolvedores, populam o registry com informações técnicas dos serviços e os classificam de acordo com o tModel definido pelos Arquitetos de Negócios;

4. Consumidores de serviços consultam o registry procurando por serviços que atendam as suas necessidades;

5. Os serviços descobertos são ligados para a criação de novas aplicações, podendo gerar novos web services ou não;

6. Aplicações podem dinamicamente consultar o registry para localizar end points de serviços ou outros metadados.

A especificação UDDI define uma API baseada em mensagens SOAP, com uma descrição em WSDL do próprio Web Service do servidor de registro. A maioria dos servidores de registro UDDI também provê uma interface de navegação por browser.