O que são Web Services ?

Os Web Services são baseados em 4 protocolos-padrão, usados pelos principais fabricantes de tecnologias: XML, SOAP, UDDI e WSDL. O XML, um primo avançado do HTML é um método para descrever dados. O SOAP é simplesmente um protocolo que define como determinada aplicação fala com os SW, para realizar uma tarefa. O UDDI funciona como páginas amarelas dos SW, dizendo o que e onde está disponível. Finalmente, WSDL é a linguagem que permite descrever esses serviços.

Quando a Internet começou a se popularizar, por volta do meio dos anos 90, as tecnologias presentes permitiam você se conectar a um site e baixar o conteúdo deste. O HTML (Hiper Text Markup Language) era a linguagem "de fato" que permitia a apresentação da informação presente na rede. Nos últimos anos, porém, novas tecnologias e frameworks de desenvolvimento estão surgindo, permitindo uma maior integração entre os diversos aplicativos e serviços disponíveis na internet. Este novo modelo em crescimento deve tratar tarefas complexas, como o gerenciamento de transações, através da disponibilização de serviços distribuídos que utilizem interfaces de acesso simples e bem definidas. Esses serviços ou aplicativos distribuídos são conhecidos como Web Services.

Para ilustrar a utilização de Web Services em uma situação real, imaginemos um site de vendas pela Internet, que necessita validar o crédito do comprador antes de proceder com a venda. O sistema então acessa um serviço (Web Service) que cuida de todos os passos necessários à verificação de crédito: Checa o histórico das compras efetuadas pelo consumidor na empresa, checa a situação de crédito do consumidor no sistema público, etc. O Web Service obtém estes dados e retorna a situação de crédito deste consumidor para o site. Este é apenas um exemplo, entre tantos, de utilização de Web Services.

Web Services são identificados por uma URI (Unique Resource Identifier), e são descritos e definidos usando XML. Um dos motivos que tornam Web Services atrativos é o fato deste modelo ser baseado em tecnologias standards, em particular XML e HTTP. Web Services são usados para disponibilizar serviços interativos na WEB, podendo ser acessados por outras aplicações. SOAP (Simple Object Access Protocol) está se tornando padrão para a troca de mensagens entre aplicações e Web Services, já que é uma tecnologia construída com base em XML e HTTP.

SOAP é um procolo projetado para invocar aplicações remotas através de RPC (Remote Procedure Calls - Chamadas Remotas de Procedimento) ou trocas de mensagens, em um ambiente independente de plataforma e linguagem de programação. SOAP é, portanto, um padrão normalmente aceito para se utilizar com Web Services. Desta forma, pretende-se garantir a interoperabilidade e intercomunicação entre diferentes sistemas, através da utilização de uma linguagem (XML) e mecanismo de transporte (HTTP) padrões.

Características do SOAP

1. Definido pelo consórcio W3C. Veja maiores detalhes da versão atual SOAP 1.1.
2. Protocolo baseado em XML para a troca de informações em um ambiente distribuído;
3. Padrão de utilização com Web Services;
4. Normalmente utiliza HTTP como protocolo de transporte;
5. Uma mensagem SOAP (veja fig.1) consiste basicamente dos seguintes elementos:

• O Envelope: Toda mensagem SOAP deve contê-lo. É o elemento raiz do documento XML. O Envelope pode conter declarações de namespaces e também atributos adicionais como o que define o estilo de codificação (encoding style).Um "encoding style" define como os dados são representados no documento XML.
• O Header: É um cabeçalho opcional. Ele carrega informações adicionais, como por exemplo, se a mensagem deve ser processada por um determinado nó intermediário (É importante lembrar que, ao trafegar pela rede, a mensagem normalmente passa por diversos pontos intermediários, até alcançar o destino final). Quando utilizado, o Header deve ser o primeiro elemento do Envelope.
• O Body: Este elemento é obrigatório e contém o payload, ou a informação a ser transportada para o seu destino final. O elemento Body pode conter um elemento opcional Fault, usado para carregar mensagens de status e erros retornadas pelos "nós" ao processarem a mensagem.

Entre outras utilizações, SOAP foi desenhado para encapsular e transportar chamadas de RPC, e para isto utiliza-se dos recursos e flexibilidade do XML, sob HTTP.

RPCs ou chamadas remotas de procedimento, são chamadas locais a métodos de objetos (ou serviços) remotos. Portanto, podemos acessar os serviços de um objeto localizado em um outro ponto da rede, através de uma chamada local a este objeto. Cada chamada ou requisição exige uma resposta.

Processo de uma chamada RPC: Antes de serem enviadas pela rede, as chamadas de RPC (emitidas pela aplicação cliente) são encapsuladas (ou serializadas) segundo o padrão SOAP. O serviço remoto, ao receber a mensagem faz o processo contrário, desencapsulando-a e extraindo as chamadas de método. A aplicação servidora então processa esta chamada, e envia uma resposta ao cliente. O processo então se repete: a resposta é também serializada e enviada pela rede. Na máquina cliente, esta resposta é desencapsulada e é repassada para a aplicação cliente.

A especificação SOAP (definida pela W3C) define as seguintes informações, como necessárias em toda chamada de RPC:

• A URI do objeto alvo;
• O nome do método;
• Os parâmetros do método (requisição ou resposta);
• Uma assinatura do método opcional;
• Um cabeçalho (header) opcional.

Documento WSDL

A linguagem XML (uma ferramenta para descrever dados) é ideal para a Web ; mas para descrever os Web Services usamos a linguagem WSDL (web Service Description Language ) . Todo web service tem o seu WSDL . O WSDL é um documento em XML que descreve os protocolos que podem ser utilizados para acessar o web service. No WSDL estão definidos : a URL de acesso , o nome do web service , a descrição de cada método e como fazer a solicitação via SOAP , GET ou POST . Podemos fazer a requisição WSDL via Web.

De que forma um cliente de um Web Service sabe qual formato dos métodos a serem chamados, qual parâmetros a serem passados? Como cliente e serviço sabem como processar uma requisição?

Para solucionar estes tipos de perguntas é que foi criado um documento, que utiliza uma linguagem chamada WSDL. WSDL ou Web Service Description Language é uma linguagem baseada em XML, utilizada para descrever um Web Service. Um Web Service deve, portanto, definir todas as suas interfaces, operações, esquemas de codificação, entre outros neste documento.


Tão logo o cliente tenha acesso à descrição do serviço a ser utilizado, a implementação do Web Service pode ser feita em qualquer linguagem de programação. Normalmente são utilizadas linguagem construídas para interação com a WEB, como por exemplo Java Servlets ou ASP, que, em seguida, chamam um outro programa ou objeto.

Basicamente, quando o cliente deseja enviar uma mensagem para um determinado Web Service, ele obtém a descrição do serviço (através da localização do respectivo documento WSDL), e em seguida constrói a mensagem, passando os tipos de dados corretos (parâmetros, etc) de acordo com a definição encontrada no documento. Em seguida, a mensagem é enviada para o endereço onde o serviço está localizado, a fim de que possa ser processada. O Web Service, quando recebe esta mensagem valida-a conforme as informações contidas no documento WSDL. À partir de então, o serviço remoto sabe como tratar a mensagem, sabe como processá-la (possivelmente enviando-a para outro programa) e como montar a resposta ao cliente.

Crie um Índice de Web Services com o UDDI

Com tantos Web services disponíveis na rede, você deve estar se perguntando como fazer para encontrá-los. Da mesma forma que os mecanismos de busca como Yahoo! e Google o ajudam a localizar os dados certos nas páginas Web, o UDDI (Universal Description, Discovery, and Integration) define uma maneira padrão de os Web services publicarem informações e anunciarem seus serviços. O UDDI é basicamente um diretório de Web services que oferece às empresas uma maneira fácil de registrar e localizar serviços.

O diretório permite que os consumidores de Web services executem buscas programáticas por Web services relevantes. Assim que um consumidor souber onde reside um dado Web service, ele precisará localizar o WSDL do Web service. Os Web services fornecem um arquivo de busca em formato XML. Você pode juntar os vários componentes descritos até aqui para criar um Web service amplamente funcional. Veja como funciona: o consumidor de Web services consulta o UDDI em relação a um Web service e o UDDI retorna a lista de Web services disponíveis. Em seguida, o consumidor envia uma solicitação do documento buscado ao Web service e este o retorna. O consumidor então envia um pedido de um documento WSDL ao Web service, e este também o retorna. Por fim, o consumidor envia uma solicitação de serviço e o Web service retorna uma resposta de serviço.

A boa notícia sobre Web services é que você pode começar a desenvolvê-los imediatamente. Nessa fase mais rudimentar, tudo que você precisa é de um servidor Web e de uma tecnologia no lado servidor, como o ASP (Microsoft Active Server Pages), com capacidade para ler e escrever em XML. E, como os Web services são baseados em XML, se o seu aplicativo puder criar e ler documentos em XML, você pode consumir Web services.

Você também já pode tirar proveito de diversas ferramentas existentes para desenvolver e distribuir Web Services. Se utiliza a plataforma Microsoft Windows, pode usar o SOAP Toolkit for Visual Studio 6. Além disso, o Microsoft .NET Framework oferece uma excelente plataforma para desenvolvimento e distribuição de Web services. Sendo assim, comece a pensar em como deseja implementar Web services em sua empresa e equipe sua equipe de desenvolvimento com as ferramentas corretas para dar o passo inicial.

Fonte: http://devedge-temp.mozilla.org/
http://www.linhadecodigo.com.br/