Introdução a Web Services

Olá, pessoal! Continuando nossos estudos sobre Arquitetura Orientada a Serviços (SOA), vamos passar agora pela implementação mais famosa dessa arquitetura: Web services. De cara, é importante lembrar que SOA é um modelo de arquitetura independente de qualquer plataforma de tecnologia e os web services são a implementação de SOA mais popular. Como o nome indica, os web services oferecem serviços pela internet.

Um web service é uma aplicação que está disponível pela internet e se utiliza de padrões baseados em XML para descrever as mensagens enviadas e recebidas, bem como seus dados. É uma tecnologia independente de hardware, sistema operacional e linguagem de programação.

Entre as estratégias utilizadas para implementar web services, destaca-se AJAX (Asynchronous JavaScript and XML).

Temos uma pilha de protocolos utilizados em web services, sintetizada na figura a seguir, extraída de Sommerville:

Entre esses protocolos, destaca-se:

XML: Foi escolhida como a linguagem de comunicação a ser utilizada entre os sistemas que implementam web services por ser independente de plataforma e entendida por diferentes sistemas.
HTTP (Hypertext Transfer Protocol): Ao criar web services em HTTP, todos os computadores capazes de se conectar à internet podem se tornar potenciais consumidores de serviços. Além disso, usando o protocolo HTTPS (Hyper Text Transfer Protocol Secure), a comunicação do web service pode ser protegida.
SOAP (Simple Object Access Protocol): Padrão de trocas de mensagens que oferece suporte à comunicação entre os atores de uma arquitetura SOA.
WSDL (Web Service Definition Language): É um padrão para a definição da interface de um serviço. Define como as operações de serviço (nomes de operação, parâmetros e seus tipos) e associações de serviço devem ser definidas.
UDDI (Universal Description, Discovery and Integration): Define os componentes de uma especificação de serviço, que pode ser usada para descobrir a existência do serviço. Esses componentes incluem informações sobre o provedor de serviço, os serviços fornecidos, o local da descrição WSDL da interface de serviço e informações sobre os relacionamentos de negócios.

Na prática, temos a seguinte arquitetura:

Veja nessa figura que a implantação de web services é 100% SOA. Um solicitante de serviços busca informações do serviço no broker querendo descobrir o WSDL do serviço desejado. O broker possui arquivos UDDI com as informações que o solicitante precisa. Daí, o solicitante solicita o serviço ao provedor de serviços por meio de uma mensagem SOAP e recebe a saída do serviço também por SOAP. Por fim, o provedor atualiza o broker periodicamente sobre seus serviços por meio de arquivos WSDL.

Em outras palavras, temos:

Existe, ainda, um grande número de padrões de suporte que se destinam a apoiar a SOA em diferentes aplicações empresariais. Entre esses padrões, destaca-se:

WS-Reliable Messaging: Um padrão para troca de mensagens que garante que elas serão entregues uma vez e apenas uma vez.
WS-Security: Um conjunto de padrões que apoiam a proteção de web services, incluindo padrões que especificam a definição de políticas de proteção e padrões que cobrem o uso de assinaturas digitais.
WS-Addressing: Define como as informações de endereço devem ser representadas em uma mensagem SOAP.
WS-Transactions: Define como as transações através de serviços distribuídos devem ser coordenadas.
WS-BPEL: Padrão para uma linguagem de workflow, que é usada para definir programas de processo que envolvem vários serviços diferentes.

Os atuais padrões de web services têm sido criticados como padrões ‘pesados’, muito gerais e ineficientes. Implementar esses padrões requer uma quantidade considerável de processamento para criar, transmitir e interpretar as mensagens XML associadas. Por essa razão, algumas organizações, como a Amazon, usam uma abordagem mais simples e mais eficiente para comunicação de serviços, usando os chamados serviços RESTful[1]. A abordagem RESTful oferece suporte à interação eficiente de serviço, mas não oferece suporte a recursos de nível empresarial, como a WS-Reliability e WS-Transactions.

Para terminar, vamos trazer as propriedades de web services, segundo a IBM:

Os web services são independentes. No cliente, nenhum software adicional é necessário. Uma linguagem de programação com suporte a clientes XML e HTTP é suficiente para começar. No lado do servidor, um servidor da Web e um servidor SOAP são necessários. É possível ativar um aplicativo existente para web services sem gravar uma única linha de código.
Os web services são auto-explicativos. Nem o cliente nem o servidor sabem ou se preocupam sobre nada, além do formato, do conteúdo do pedido e das mensagens de resposta. A definição do formato da mensagem viaja com a mensagem, não são necessários repositórios de metadados externos ou uma ferramenta de geração de código.
Os web services podem ser publicados, localizados e chamados por meio da Internet. SOA utiliza padrões de Internet estabelecidos, como HTTP, e alavanca a infraestrutura existente. Outros padrões requeridos incluem SOAP, WSDL e UDDI.
Os web services são independentes de linguagem e interoperáveis. O cliente e o servidor podem ser implementados em ambientes diferentes. O código existente não precisa ser alterado para ser ativado por web services.
Os web services são inerentemente abertos e baseados em padrões. XML e HTTP são a base técnica principal para web services. Uma grande parte da tecnologia de web services foi construída utilizando open source.
Os web services são dinâmicos. O e-business pode se tornar realidade usando web services, porque com UDDI e WSDL é possível automatizar a descrição e a descoberta do web service.
Os web services podem ser compostos. Web services simples podem ser agregados aos mais complexos, usando técnicas de workflow ou chamando web services de camadas inferiores.
Os web services são fracamente acoplados. Tradicionalmente, o design de aplicativos depende de interconexões fortes em ambas as extremidades. Os web services requerem um nível mais simples de coordenação, que suporta uma reconfiguração mais flexível para uma integração dos serviços.
Os web services fornecem acesso programático. SOA não fornece uma interface gráfica com o usuário; ela opera no nível do código. Os consumidores de serviços precisam conhecer as interfaces com os web services, mas não precisam conhecer os detalhes da implementação dos serviços.
Os web services fornecem a capacidade de agrupar aplicativos existentes. Os aplicativos independentes já existentes podem facilmente se integrar à SOA implementando um web service como uma interface.