O fator que mais provocou mudanças nas metodologias e tecnologias de desenvolvimento da aplicações, nos últimos tempos, foi  Internet. A criação de aplicações distribuídas e o compartilhamento de informações passou a ser mais uma necessidade, do que uma realidade. Como fazer o sistema de uma empresa, baseado no Mainframe, trocar informações com o sistema de outra empresa, baseado no modelo Cliente/Servidor?

Muitas vezes, dentro da mesma empresa temos diferentes ambientes e a questão do compartilhamento de informações e integração de aplicações é uma das mais difíceis de serem resolvidas. Com a Internet começou-se um processo de padronização em diversas frentes:

• TCP/IP como protocolo da Internet e também das redes internas, das empresas.
• HTML como um formato padrão para a publicação de informações.
• HTTP como protocolo de transporte.

Porém alguns problemas ainda persistiam. Como viabilizar a troca de informações entre empresas que, na maioria das vezes, utilizam formatos de dados proprietários e completamente incompatíveis? Como resposta a este questão, o padrão XML (Extensible Markup Language) tem sido uma resposta eficaz e amplamente aceita pelo mercado. Porém ainda persiste a questão de como fazer que uma aplicação possa utilizar funcionalidades de outras aplicações, sem ter que reescrever toda a lógica que já está implementada?

Acredito que a utilização dos Web Services seja a resposta para esta última questão. Com Web Services podemos construir aplicações e componentes de software capazes de interagirem. Os Web Services podem ser criados em diferentes linguagens ou plataformas. O que garante a interoperabilidade é a utilização de um formato padrão para troca de mensagens (XML) e um protocolo padrão para o envio e recebimento destas mensagens (SOAP – Simple Object Access Protocol); sendo que as mensagens no formato SOAP são empacotadas e transportadas utilizando-se HTTP ou SMTP, protocolos amplamente utilizados na Internet.

O fato de utilizar padrões amplamente aceitos é que torna os Web Services uma alternativa atraente. Cabe ressaltar que o conceito de Web Services não é uma novidade do Framework .NET. Outras empresas como IBM e Sun já trabalham com o conceito de Web Services, sendo que a IBM também utiliza os padrões XML e SOAP.

Um Web Service é um componente ou unidade de software(eu prefiro o termo “Pedaço de Código”, mas reconheço que não é um termo muito, digamos, elegante) que fornece uma funcionalidade específica, como por exemplo uma rotina para validação do número de Cartão de Crédito ou do Dígito Verificador de um número de CPF; unidade esta que pode ser acessada por diferentes sistemas, através da utilização de padrões da Internet, como por exemplo XML, HTTP e SOAP. A utilização destes padrões é de vital importância para que possamos criar aplicações distribuídas utilizando Web Services.

Um Web Service pode ser utilizado internamente, por uma única aplicação ou por várias aplicações da mesma empresa; ou pode ser “exposto” através da Internet, para utilização por qualquer aplicação. Por exemplo, imagine que o Governo do Estado disponibiliza um Web Service para cálculo do ICMS. Todas as máquinas registradores de Supermercados, Padarias e demais estabelecimentos possuem um programa que utiliza este Web Service. Se a legislação do ICMS mudar, tudo o que o governo precisaria fazer seria alterar o Web Service e as máquinas registradoras já passariam a fazer o cálculo do ICMS, baseado na nova versão. Pelo exemplo podemos ver que a utilização de Web Services é baseada em um “mundo” amplamente conectado, através de padrões utilizados na Internet. Como a forma de acesso a um Web Service é padronizada, isto permite que diferentes sistemas possam acessar e trocar dados com um mesmo Web Service. Para que uma aplicação possa fazer uso de um Web Service, basta que ela seja capaz de entender SOAP e XML.

A Microsoft vem trabalhando com diversas companhias e junto ao W3C (www.w3.org), que é uma entidade responsável pela padronização de diversas linguagens e protocolas de Internet, em uma proposta para a padronização do SOAP e de outros padrões que dão suporte a utilização de Web Services.

Para que um Web Service possa ser utilizado, algumas funções precisam estar disponíveis:

• Descoberta: Precisa existir uma maneira de “descobrirmos” a existência do Web Service. Por exemplo, quando você está criando uma aplicação de Comércio Eletrônico, você precisa de mecanismos para localizar Web Services com funcionalidades específicas e que possam ser utilizados pela aplicação que está sendo criada. Para resolver esta questão existem duas especificações sendo atualmente analisadas: 1) UDDI (Universal Description, Discovery and Integration – www.UDDI.org); 2) DISCO (Discovery).
• Descrição das funcionalidades e métodos disponibilizados pelo Web Service: Para documentar e expor as funcionalidades de um Web Service, a Microsoft propôs ao W3C a especificação WSDL ( Web Service Description Language). O WDSL define regras para a descrição das funcionalidades de um Web Service, utilizando XML. São descritos os métodos e propriedades suportados pelo Web Service, os tipos de dados e os protocolos que podem ser utilizados para o envio e recebimento de mensagens. Maiores detalhes em www.w3.org/TR/wsdl.
• Protocolo padrão para troca de mensagens: Conforme descrito anteriormente, é utilizado o protocolo SOAP. Maiores informações em www.w3.org/TR/SOAP.

Possíveis utilizações para um Web Service.

Vamos ver alguns exemplos onde poderíamos utilizar Web Services como uma forma de criar aplicações mais flexíveis e de fácil manutenção.

Criação de uma funcionalidade específica para ser utilizada por um programa cliente

Este é uma das situações mais simples possíveis. Criamos um Web Service, cuja funcionalidade será utilizada por um outro programa. Por exemplo, podemos criar um Web Service que contém informações sobre as taxas de imposto de todos os estados Brasileiras e a forma de cálculo dos impostos. Este Web Service pode ser utilizado por sites de comércio eletrônico para calcular o preço final do produto, de acordo com o local de entrega.

Neste cenário, o sistema do site de comércio eletrônico formata uma mensagem com as informações do produto e do local de destino, na forma de uma mensagem XML, a qual é encapsulada no formato SOAP para ser transportada pelo protocolo HTTP. No destino o Web Service “desempacota a mensagem”, lê as informações no formato XML, faz os cálculos com base nos valores recebidos, empacota o resultado no formato XML, o qual é encapsulado no formato SOAP para ser transportado pelo protocolo HTTP, de volta para programa que fez a solicitação de cálculo.

Integração entre diferentes aplicações

Este é um dos grandes problemas a ser resolvido pela área de TI das empresas. Podemos utilizar Web Services para fazer a integração entre diferentes aplicações, criadas em diferentes plataformas e que trabalham com diferentes formatos de dados. Com Web Services, podemos expor a funcionalidade e os dados de cada aplicação como um Web Service. Em seguida criamos uma aplicação que utiliza o conjunto de Web Services, criados a partir das aplicações individuais, aplicação esta que habilita a interoperabilidade entre as diversas aplicações. Esta situação é ilustrada na Figura 13.1:

Figura 13.1 Interoperabilidade entre aplicações com Web Services.

A utilização de Web Services também é de grande utilidade em aplicações de Workflow, onde um determinado processo ou tarefa é realizado em diferentes seções da empresa.

O exemplo clássico é o caso de aprovação das despesas de viagens para um funcionário. O funcionário envia uma solicitação com a justificativa para o chefe imediato, o qual aprova a solicitação e envia para o setor de Recursos Humanos para as providências necessárias. Uma vez alocados os recursos necessários, o setor de Recursos Humanos informa o funcionário sobre horários, datas, etc. Para automatizarmos um Workflow como este do exemplo, precisamos interagir com dados e sistemas de diferentes departamentos da empresa, os quais normalmente não estão integrados, com formatos de dados diferentes. Neste ponto é que podemos utilizar Web Services para criar um sistema de Workflow que, do ponto de vista do usuário, funciona como um sistema integrado, que utiliza um único modelo de dados e conjunto de funcionalidades.

A Microsoft fornece um produto que facilita a criação de um sistema como o descrito no parágrafo anterior: BizTalk Server. Com este produto podemos criar processos de negócios e automatizar a geração de mensagens no formato XML, para interoperabilidade entre os sistemas.

O que diferencia Web Services das tecnologias de componentes como COM ou CORBA?

Caso você conheça a tecnologia COM /COM+ da Microsoft ou CORBA, coordenada por um grupo de grandes empresas como Sun, Netscape, IBM, etc, pode estar se perguntando se Web Services não é exatamente a mesma coisa.

Em termos de funcionalidade devo concordar que a idéia é bastante semelhante, mas o que diferencia um Web Service é o fato deste poder ser acessado a partir de qualquer servidor da Internet, utilizando um protocolo padrão como o HTTP. Já a tecnologia COM, utiliza interfaces e formatos de mensagens, proprietários. Surgiram algumas soluções para acesso a componentes COM através da Internet, porém soluções proprietárias. Os mesmos comentários são válidos para a tecnologia CORBA.

O modelo de programação para a criação de Web Services é semelhante, em muitos aspectos, ao modelo de criação e utilização de componentes COM. O principal objetivo da tecnologia COM é possibilitar aos programadores, a criação de uma aplicação a partir de componentes prontos, componentes estes que fornecem funcionalidades específicas. Para atingir este objetivo, COM utiliza uma padrão binário (e proprietário), para a definição das interfaces expostas por um componente COM. Embora o modelo COM facilite a localização e utilização de componentes, o modelo está restrito aquelas plataformas capazes de entender o método proprietário de comunicação, definido na especificação COM.

O principal objetivo dos Web Services é possibilitar aos desenvolvedores uma maneira fácil para integrar aplicações e dados de diferentes plataformas. Com Web Services somos capazes de integrar aplicações criadas em diferentes plataformas e em diferentes linguagens. Para tal, diferentemente do COM, os Web Services são baseados em padrões abertos (XML, SOAP, HTTP, etc), padrões estes amplamente utilizados atualmente. Ao invés de um método binário para comunicação entre aplicações, os Web Services utilizam um mecanismo de comunicação baseado em XML. O XML passa a ser uma espécie de “Linguagem Universal para troca de dados e mensagens entre aplicações”.

Bem, chega de teoria. Agora vamos aprender a criar e a utilizar Web Services. Primeiro aprenderemos a criar um Web Service para, em seguida aprender a utilizar Web Services em uma página ASP.NET.