Esse artigo faz parte da revista WebMobile edição 1. Clique aqui para ler todos os artigos desta edição

Introdução às tecnologias Web Services: SOA, SOAP, WSDL e UDDI - Parte1

   Antes de nos aprofundarmos nos conceitos e tecnologia de web services, vejamos um pouco sua evolução. No ano de 2000, a W3C (World Wide Web Consortium) aceitou a submissão do Simple Object Access Protocol (SOAP). Este formato de mensagem baseado em XML estabeleceu uma estrutura de transmissão para comunicação entre aplicações (ou entre serviços) via HTTP. Sendo uma tecnologia não amarrada a fornecedor, o SOAP disponibilizou uma alternativa atrativa em relação aos protocolos proprietários tradicionais, tais como CORBA e DCOM.

   No decorrer do ano seguinte, o W3C publicou a especificação WSDL. Uma nova implementação do XML, este padrão forneceu uma linguagem para descrever a interface dos web services. Posteriormente suplementada pela especificação UDDI (Universal Description, Discovery and Integration), que proporcionou um mecanismo padrão para a descoberta dinâmica (dynamic discovering) de descrições de serviço, a primeira geração da plataforma de Web services foi estabelecida. A Figura 1 ilustra em alto nível o relacionamento entre estes padrões.

Figura 1. O relacionamento entre especificações de primeira geração.

Is accessed using à é acessado utilizando

Enables discovery of à permite a descoberta de

Describes à descreve

Enables communication between à permite a comunicação entre

Binds to à ligação para

Desde então, os web services foram adotados por vendedores e fabricantes num ritmo considerável. Suporte amplo da indústria seguiu-se à popularidade e importância desta plataforma e de princípios de projeto orientados a serviço. Isto levou à criação de uma segunda geração de especificação de Web services.

Web services e a arquitetura orientada a serviços (SOA)

Entendendo serviços

O conceito de serviços em uma aplicação existe faz algum tempo. Serviços, assim como componentes, são considerados blocos de construção independentes, os quais coletivamente representam um ambiente de aplicação. No entanto, diferente de componentes tradicionais, serviços têm algumas características únicas que lhes permitem participar como parte de uma arquitetura orientada a serviços.

Uma destas características é a completa autonomia em relação a outros serviços. Isto significa que cada serviço é responsável por seu próprio domínio, o que tipicamente significa limitar seu alcance para uma função de negócio específica (ou um grupo de funções relacionadas).

Este enfoque de projeto resulta na criação de unidades isoladas de funcionalidades de negócio ligadas fracamente entre si. Isto é possível por causa da definição de uma estrutura padrão de comunicação. Devido à independência que esses serviços desfrutam dentro desta estrutura, a lógica de programação que encapsulam não tem necessidade de obedecer a nenhuma outra plataforma ou conjunto de tecnologias.

XML Web services

O tipo de serviço mais largamente aceito e bem sucedido é o XML Web service, que será daqui em diante chamado apenas de web service, ou simplesmente service. Este tipo de serviço possui dois requisitos fundamentais:

·         comunica-se via protocolos internet (normalmente HTTP);

·         envia e recebe dados formatados como documentos XML.

A ampla aceitação do web service resultou no surgimento de um conjunto de tecnologias suplementares que se tornaram um padrão de fato. Assim ao desenvolver nossos web services devemos considerar o uso de tecnologias que:

·         forneça uma descrição de serviço que, no mínimo, consista de um documento WSDL;

·         seja capaz de transportar documentos XML utilizando SOAP sobre HTTP.

Estas tecnologias não modificam a funcionalidade do núcleo de um serviço web, tanto como o faz sua habilidade para se representar e comunicar num modo padrão. Muitas das convenções de arquitetura expressadas neste artigo assumem que SOAP e WSDL fazem parte da estrutura de web services descrita.

Além disto, é normal que um Web service seja:

·         capaz de agir como o solicitante e o provedor de um serviço;

·         registrado com um discovery agent através do qual possam ser localizados.

Numa conversação típica com um web service, o cliente iniciador do pedido é um web service também. Como mostrado na Figura 2, qualquer interface exposta por este client service também o qualifica como um serviço a partir do qual outros serviços podem solicitar informação. Posto isto, web services não se encaixam no modelo clássico de cliente-servidor. Na verdade, eles tendem a estabelecer um sistema ponto-a-ponto, onde cada serviço pode atuar como cliente ou servidor.

Figura 2. Troca de papéis do Web services durante uma conversação.

Now I´m like a client à agora sou um cliente

Now I´m like a server à agora sou um servidor

Service à serviços

Could you do this for me à poderia fazer isso por mim?

Ok, i´ll get right on it à Ok

Now I´ve got to ask you to do something à agora eu gostaria de lhe pedir algo

Yeah, alright. I´ll take care of if à Tudo bem, é só falar.

Service-oriented architecture (SOA)

Como mencionado anteriormente, adicionar uma aplicação com uns poucos web services não é nenhum problema. Esta integração limitada pode ser apropriada para uma experiência de aprendizado, ou para complementar a arquitetura de uma aplicação existente com uma peça de funcionalidade baseada em serviços que atende a um requisito específico do projeto. No entanto, isto não estabelece uma arquitetura orientada a serviço. Existe uma clara diferença entre:

·         uma aplicação que usa web service;

·         uma aplicação baseada numa arquitetura orientada a serviços.

Uma SOA é um modelo de projeto com um conceito profundamente amarrado à questão do encapsulamento de aplicação. A arquitetura resultante estabelece essencialmente um paradigma de projeto, no qual web services são os blocos de construção chave. Isto quer dizer que ao migrar a arquitetura da sua aplicação para uma SOA, estabelece-se um compromisso com os princípios de projeto de web services e a tecnologia correspondente, como partes fundamentais do seu ambiente técnico.

Uma SOA baseada em XML web service é construída sobre camadas de tecnologia XML estabelecidas, focada em expor a lógica de aplicação existente como um serviço fracamente acoplado. Para apoiar este modelo, uma SOA promove o uso de um mecanismo de discovery por serviços via um service broker ou discovery agent.

A Figura 3 mostra como uma SOA altera a arquitetura multicamada existente, ao introduzir uma camada lógica que, através do uso de interfaces programáticas padrão (providas pelo web services), estabelece um ponto comum de integração. Esta camada de integração de serviços constitui a base para um novo modelo que pode se estender além do escopo de uma única aplicação, unificando plataformas legadas díspares em um ambiente aberto. Quando web services são utilizados para integração cruzada de aplicações (ver Figura 4), elas se estabelecem como parte da infra-estrutura do sistema.

Figura 3. Uma representação lógica de uma arquitetura orientada a serviços.

Presentation à apresentação

Integration à integração

Business à negócio

Data à dado

Service interface à interface de serviço

Figura 4. Uma representação lógica de uma arquitetura de integração orientada a serviço.

É importante se conscientizar quanto ao acréscimo de complexidade de projeto introduzido pelo SOA. Mais ainda do que em um ambiente n-camada, projetistas de aplicação devem considerar de uma forma completa como a introdução de serviços vai afetar dados existentes e modelos de negócio.

Na medida em que a utilização de serviços se diversifica, o significado dos requisitos de segurança e escalabilidade são amplificados. Ambientes orientados a serviço bem projetados tentarão vencer estes desafios com infra-estrutura adequada, ao invés de utilizar soluções sob medida, específicas de aplicação

Os papéis e cenários ilustrados nas próximas duas seções estão limitados somente ao assunto web service. A estrutura de mensagens SOAP subjacente será explicada em separado, no próximo artigo desta série.

Papéis web service

Serviços podem assumir diferentes papéis quando envolvidos em diversos cenários de interação. Dependendo do contexto pelo qual é visualizado, assim como o estado da tarefa rodando no momento, o mesmo web service pode trocar de papéis ou ser designado para múltiplos papéis simultâneos:

Provedor de serviços

Agindo como um provedor de serviços, um web service expõe uma interface pública através da qual pode ser chamado por solicitantes do serviço. Um provedor de serviços disponibiliza esta interface publicando uma descrição do serviço. Num modelo cliente-servidor, o provedor de serviço pode ser comparado ao servidor.

O termo “provedor de serviço” pode também ser usado para descrever a organização ou ambiente que hospeda (provê) o web service.

Um provedor de serviço pode também agir como um solicitante de serviço. Por exemplo, um web service pode atuar como um provedor de serviço quando um solicitante de serviço lhe pede para executar uma função. Pode então atuar como um solicitante de serviço quando mais tarde contata o solicitante de serviço original (agora agindo como um provedor de serviço) para solicitar informação de status.

Solicitante de serviço

Um solicitante de serviço é o remetente de uma mensagem web service ou o programa de software solicitando um web service específico. O solicitante de serviço é comparável ao cliente dentro de um modelo cliente-servidor padrão. Solicitantes de serviços são às vezes chamados de consumidores de serviços.

Um solicitante de serviço pode também ser um provedor de