Serviços Web – Uma breve introdução (Parte I) - Continuação

1.3 Descrição de serviços
A especificação WSDL (Web Services Description Language), atualmente na versão 1.2, é uma linguagem baseada em XML que descreve de forma padronizada e independente de plataforma como e onde os serviços podem ser conectados e utilizados através da rede.
Um documento WSDL possui o mesmo papel que a IDL da OMG nos ambientes distribuídos (WSDL, 2001), representando um contrato entre o provedor de serviços e seus clientes e definindo os serviços como uma coleção de portas na rede. Os documentos WSDL apresentam uma dicotomia entre a definição da mensagem (parte abstrata) e sua implementação (parte concreta), o que permite o reuso das definições das mensagens e port types.
Um documento WSDL é composto por sete elementos XML que representam as partes abstrata e concreta.
Na parte abstrata temos quatro elementos:
1-types - fornece a definição dos tipos de dados para descrever as mensagens trocadas entre aplicações, normalmente representadas por um documento XSD (XML Schema Definition);
2-message - representa a informação que será trocada através das definições dos tipos de dados;
3-porttype - é um conjunto de operações suportadas por um ou mais end points, onde cada operação se refere a uma mensagem de entrada, saída ou erro;
4-operation - descreve a ação suportada pelo serviço.
Na parte concreta temos os outros três elementos:
1-binding - define uma especificação de protocolo e formato de dados para as mensagens definidas em um port type;
2-port - é um end point, representa a combinação de um binding e um endereço de rede;
3-service - é uma coleção de portas. Cada elemento port se relaciona com um elemento binding particular, indicando qual interface e qual protocolo de comunicação estão sendo utilizados nessa implementação.

1.4 Publicação e descoberta de serviços Web
A especificação UDDI, atualmente na versão 3.0, especifica mecanismos para a publicação, descoberta e integração de serviços. Tais mecanismos definem as estruturas de dados necessárias para sua descrição e classificação, bem como uma interface baseada no protocolo SOAP que permite o acesso a essas informações.
Resumidamente, o registro de serviços UDDI possui dois tipos de cliente. O primeiro envolve as aplicações que desejam publicar serviços e suas interfaces, o segundo tipo envolve os clientes que desejam obter e se ligar a serviços Web.
Conceitualmente, o protocolo UDDI apresenta três papéis, representados sob a forma de XML Schemas (NEWCOMER, 2002). Os papéis são:
1-Páginas Brancas - contém identificadores sobre o contato técnico do serviço oferecido;
2-Páginas Amarelas - contém informações genéricas sobre os tipos e localização dos serviços disponíveis;
3-Páginas Verdes - contém informações técnicas sobre um determinado serviço Web.
A especificação UDDI define quatro estruturas de dados, também descritas como documentos XML, onde cada elemento descreve o tratamento dado ao serviço Web, (KREGER, 2001; 2002; NEWCOMER, 2002).
1-businessEntity - estrutura de alto nível (páginas brancas) que contém, para cada serviço, as informações (nome, categoria, identificadores, entre outros) sobre a organização que publicou o serviço Web;
2-businessService - contém informações descritivas sobre serviços Web (páginas amarelas), tais como nome e descrição do serviço publicado;
3-bindingTemplate - contém informações técnicas sobre o serviço Web tais como forma de acesso e endereços dos pontos acesso ao serviço (páginas verdes);
4-tModel - mecanismo usado para a troca de definições abstratas (metadados) sobre um serviço Web, contém as descrições do serviço Web, opcionalmente aponta para documentos WSDL.

1.5 Descrição de composições de serviços Web
A composição de serviços Web se relaciona com a automação de processos de negócio e requer uma especificação que controle a troca de mensagens entre os serviços Web. As especificações que descrevem a composição de serviços Web devem seguir uma série de princípios:
1-Estar em consonância com as demais especificações da W3C;
2-Permitir a composição de serviços mais complexos a partir de serviços Web mais simples;
3-Ser capaz de manter alta independência entre serviços com baixo acoplamento;
4-Facilitar a implementação de processos de negócio e a comunicação entre seus serviços; definir serviços obrigatórios e opcionais;
5-Indicar a ordem de execução e as rotas que serão seguidas no caso de sucesso ou falha na execução de um dado serviço Web.
Inicialmente, existiam duas especificações de descrição de composição de serviços: a WSFL (Web Services Flow Language) e a XLANG. Entretanto, elas foram substituídas pela especificação BPEL4WS (Business Process Execution Language for Web Services). BPEL4WS une características das linguagens XLANG e WSFL tornando-se mais completa que suas antecessoras (ANDREWS et al., 2003).
A especificação BPEL4WS, atualmente na versão 1.1, possui elementos que possibilitam a descrição de workflows baseados na interação de serviços Web. A linguagem também define um modelo e uma gramática para a descrição do comportamento de um processo de negócio e ainda define mecanismos para o tratamento de exceção (ANDREWS et al., 2003).

1.6 Protocolos de comunicação
A especificação SOAP (Simple Object Access Protocol) é um protocolo de transporte que rege a troca de mensagens entre aplicações em ambientes distribuídos e descentralizados. Seu conteúdo é composto por informações e estruturas de dados (KREGER, 2001; COYLE, 2002).
A especificação SOAP 1.2 contém três partes principais:
1-Modelo de empacotamento - envelope SOAP - define o conteúdo da mensagem SOAP;
2-Mecanismo de serialização - conjunto de regras de codificação - define os tipos de dados utilizados na aplicação;
3-Mecanismo de comunicação – convenção - define as chamadas e respostas através de procedimentos remotos.
Toda mensagem SOAP é um documento XML. Ela obrigatoriamente contém os elementos <Envelope> e <Body> e opcionalmente os elementos <Header> e <Fault>.
1-O elemento <Envelope> é a raiz do documento XML e representa a mensagem propriamente dita;
2-O elemento <Body> contém a carga de informações (operações e parâmetros) que são entregues ao destinatário da mensagem Este elemento, de acordo com a especificação SOAP, pode conter um elemento <Fault>, que, quando presente, pode ser utilizado no processamento de falhas do serviço Web. O elemento <Fault> descreve erros de chamada de métodos remotos ou mantém informações acerca do tipo de erro. Portanto, ele conta com os elementos <FaultCode>, <FaultActor>, <FaultString> e <Detail>;
3-O elemento <Header> expande uma mensagem SOAP. Ele define algumas características opcionais e acordos negociáveis entre as partes; seu conteúdo deve ser aceito pelas aplicações que estiverem se comunicando.
A especificação SOAP, a rigor, não depende do protocolo HTTP. Apesar de ser a combinação mais amplamente utilizada nos dias de hoje, a SOAP pode ser utilizada por outros protocolos da camada de transporte como, por exemplo, FTP, SMTP (COYLE, 2002).
Newcomer (2002) considera a especificação SOAP um tipo de extensão do protocolo HTTP, pois ela envia e recebe mensagens XML através das operações requisição e resposta do protocolo HTTP. Para que este processo ocorra, é necessário utilizar um servidor de páginas que seja capaz de atuar como um processador SOAP.

O exemplo abaixo ilustra uma mensagem SOAP sendo enviada através do método POST do protocolo HTTP v 1.1.