Sistemas de Informação Distribuídos/Interoperação/Web Services/Arquitetura e componentes

Arquitetura e componentes

A idéia inicial da arquitetura dos Web services pode ser apresentada como uma descrição dos componentes básicos de arquiteturas de middlewares existentes anteriormente, tais como CORBA, COM+, Java RMI, entre outros, e mostrando qual seriam as vantagens, as inovações, criadas pelos Web services.

• Uso de proxies no cliente e no servidor:

A idéia é introduzir um componente intermediário na comunicação do cliente com o servidor (chamado de servant). Este proxy é acessível pelo cliente e implementa a mesma interface do servant. Assim, toda comunicação feita entre cliente e servant, ou no sentido oposto, é feita através do proxy.

O uso de um proxy permite abstrair do programador os detalhes mais básicos da comunicação e implementa o conceito de transparência de localidade no sistema. Embora este conceito exista, a informação da localização deve estar codificada internamente nos proxies, o que limita o conceito de transparência de localidade somente para os componentes mais externos do sistema, o cliente e o servidor.

• Broker Architecture:

A arquitetura com o uso de um broker (que pode ser entendido como um intermediário) consiste em adicionar um novo componente intermediário na comunicação. Este componente deve estar sempre disponível e é responsável pelo mapeamento de endereços lógicos dos servants para endereços físicos. Com isso, o conceito de transparência de localização passa a ser válido também para os proxies.

• Geração automatizada dos proxies:

A criação dos proxies do cliente e servant é uma tarefa complicada e sujeita a erros, portanto é interessante que seja automatizada. Para isso é utilizada uma linguagem de definição de interfaces que pode ser utilizada por um aplicativo para gerar automaticamente estes proxies.

• Middleware para uso na Web:

É neste tópico que encontram-se as novidades criadas pelos Web services.

Os conceitos anteriores são utilizados na maioria das middlewares existentes, porém nenhum deles foi criado com o propósito fazer a transmissão de dados através da Web. Por este motivo surgem problemas como a dificuldade de utilizar um destes sistemas sobre os protocolos básicos da Web e de integrar dois sistemas implementados com middlewares diferentes.

Já os Web services foram criados com base em padrões amplamente utilizados na Web, o HTTP e XML. Com isso, torna-se natural o seu uso neste ambiente, integrando os conceitos citados anteriormente que são utilizados nos middlewares com o propósito de transmissão de dados através da Web.

Os Web services compõe sistemas orientados a serviços. Para operarem nestes ambientes, as aplicações (serviços) precisam definir seus requerimentos e capacidades funcionais e não funcionais de forma aceita por ambas as partes e que possam ser interpretadas por um computador.

É utilizado, então, o modelo baseado em componentes, onde os serviços passam a representar componentes que, através de uma composição dos mesmos, formam-se as aplicações. Uma composição de serviços também pode ser vista como um serviço, podendo ser utilizada para criação de outras composições.

Interação entre componentes dos Web services

Para suportar uma arquitetura orientada a serviços, os Web services precisavam prover definições padronizadas para garantir funcionalidades básicas como: permitir a comunicação entre eles, definir um serviço, descobrir (ou localizar) um serviço, criar composições de diversos serviços, garantir QoS, entre outros.

Uma característica importante dos Web services é justamente a modularidade de suas especificações, seus componentes. A figura ao lado mostra um exemplo da interação de alguns componentes (coluna esquerda) de acordo com sua funcionalidade (coluna direita) na pilha, onde peças podem ser removidas e substituídas por outras conforme necessário.

Imagens semelhantes podem ser encontradas em sites como o site da IBM que apresenta a lista de padronizações dos Web services [1] e o site da Microsoft que tem o mesmo objetivo [2].

O núcleo dos Web services

As primeiras funcionalidades disponibilizadas foram: a comunicação para possibilitar a interoperação e mecanismos para descrição e descoberta de serviços. Os padrões criados para prover estas funcionalidades formam o trio inicial e básico de padrões dos Web services: SOAP, WSDL e UDDI.

SOAP (Simple Object Access Protocol):

O SOAP provê uma forma de representar e estruturar os dados que representam as mensagens trocadas entre as aplicações em um ambiente distribuído, neste caso os Web services. Ele é expressado através da linguagem XML e, para comunicação de dados, utiliza normalmente o HTTP, mas não obrigatoriamente, permitindo também protocolos como SMTP, FTP, etc.

A descrição das mensagens utilizando SOAP e o protocolo de comunicação utilizado formam a camada fundamental de comunicação dos Web services.

• SOAP no W3C: http://www.w3.org/TR/2000/NOTE-SOAP-20000508/ (em inglês)

WSDL (Web Services Description Language):

WSDL é uma linguagem construída sobre o XML utilizada para descrever os Web services. A linguagem descreve a interface pública de um serviço, disponibilizando informações para que seus métodos possam ser acessados.

Um documento WSDL possui uma parte abstrata e uma parte concreta (ligada à instância do serviço), o que possibilita a reusabilidade desses itens. A parte abstrata descreve a interface de um serviço, as mensagens que serão trocadas e as operações suportadas, e a parte concreta especifica os formatos de dados e protocolos específicos que serão utilizados.

A descrição WSDL normalmente é gerada automaticamente por ferramentas especializadas e também pode ser utilizada para facilitar a criação de um Web service. Algumas ferramentas permitem a criação de uma descrição de alto nível dos serviços e esta descrição é utilizada para criação do serviço e seu WSDL.

• WSDL no W3C: http://www.w3.org/TR/2001/NOTE-wsdl-20010315 (em inglês)

UDDI (Universal Description Discovery and Integration):

UDDI é um sistema utilizado para registro e descoberta de Web services.

O sistema é baseado em XML, assim como os protocolos anteriores, e possibilita que serviços em toda a Internet sejam registrados e possam ser encontrados por outros serviços. A primeira versão foi escrita em 2000, com a intenção de que o UDDI se tornasse um ponto único de consulta a serviços, onde uma aplicação cliente faria uma consulta ao registro, o registro localizaria o serviço mais adequado para responder às necessidades do cliente e retornaria dados suficientes para que o cliente pudesse acessar o serviço.

Um sistema UDDI é modelado para suportar a troca de mensagens utilizando SOAP e a descrição dos serviços registrados que ele utiliza para consultas e para retornar dados aos clientes é feita usando WSDL.

• Especificações UDDI: http://www.oasis-open.org/committees/uddi-spec/doc/tcspecs.htm (em inglês)

Evolução dos componentes

alega que, para ir além destas funcionalidades básicas iniciais, são necessários mecanismos para composição de serviços e protocolos para garantir a qualidade de serviço. Diversos padrões foram criados nestas áreas (e não somente nestas), podendo-se citar alguns importantes como:

BPEL4WS (Business Process Execution Language for Web Services):

BPEL4WS (ou simplesmente BPEL) é uma das linguagens utilizadas para composição de Web services na forma de processos de negócios. No BPEL, cada composição é um processo de negócio que interage com um conjunto de Web services (chamados de parceiros) para atingir determinado objetivo. A comunicação dos processos com seus parceiros é feita na forma P2P, onde os parceiros oferecem funções a serem usadas pelos processos e os processos somente utilizam estas funções, sem disponibilizar outras. A definição das interfaces do processo e dos parceiros são feitas através de componentes abstratos das descrições WSDL de ambos, o que torna os processos BPEL independentes de protocolo e plataforma.

Os processos BPEL são baseados em atividades: uma mensagem é enviada através de uma invoke activity, ele pode esperar que uma de suas funções seja invocada usando a receive activity, obtém os valores de retorno de uma operação através da reply activity, entre outras. Estas atividades podem formar algoritmos complexos quando combinadas utilizando estruturas disponibilizadas pela linguagem.

BPEL também suporta manipulação e compensação de falhas. A manipulação de falhas consiste em detectar erros durante a execução e realizar uma ação necessária (o que é feito através de estruturas semelhantes aos blocos “try” existentes em linguagens como C++ e Java), enquanto a compensação corresponde a remover os efeitos causados por certas ações que já foram concluídas.

• Especificação: http://www.ibm.com/developerworks/library/specification/ws-bpel/ (em inglês)

WS-Coordination:

É um framework para implementação de modelos de coordenação que necessitam de um contexto compartilhado. Ele provê mecanismos gerais necessários para coordenação das ações de aplicações distribuídas e permite ser estendido para geração de suporte a tipos específicos de coordenação.

• Especificação: http://dev2dev.bea.com/pub/a/2004/03/ws-coordination.html (em inglês)

WS-Transactions:

Define dois modelos particulares de coordenação usadas com o WS-Coordination: uma para transações atômicas (curtas e instantâneas) e uma para transações de negócios (longas e lentas). Elas podem ser usadas tanto individualmente quanto em conjunto, dependendo das necessidades das aplicações.

• Especificação: http://dev2dev.bea.com/pub/a/2004/01/ws-transaction.html (em inglês)

WS-Security:

Como o nome diz, visa garantir segurança nas transmissões que envolvem Web services. Ele especifica como pode-se alcançar integridade e confidencialidade na troca de mensagens com os Web services através da inclusão de cabeçalhos adicionais nas mensagens SOAP.

• Especificação: http://www-128.ibm.com/developerworks/library/specification/ws-secure/ (em inglês)

WS-ReliableMessaging:

Permite que a troca de mensagens entre aplicações distribuídas seja feita de forma confiável, mesmo na presença de falhas.

• Especificação: http://docs.oasis-open.org/ws-rx/wsrm/200702/wsrm-1.1-spec-cs-01.pdf (em inglês)

WS-Policy:

Estende o WSDL para permitir codificar e anexar informações de qualidade de serviços, segurança, etc. nos Web services através de políticas de serviços. Permite que os fornecedores de serviço especifiquem suas políticas de uso e que os consumidores especifiquem que políticas necessitam dos fornecedores.

• Especificação: http://schemas.xmlsoap.org/ws/2004/09/policy/ (em inglês)

Os componentes atualmente

Além dos componentes citados, diversos outros foram criados ao longo dos últimos anos. A lista atual de especificações é muito extensa. Estas especificações possuem suporte de diferentes organizações e estão em diferentes estágios de desenvolvimento. Algumas listas podem ser encontradas nos locais abaixo:

• Especificações no site da IBM: http://www-128.ibm.com/developerworks/webservices/standards/ (em inglês)
• Especificações no site da Microsoft: http://msdn2.microsoft.com/webservices/Aa740689 (em inglês)
• Lista de especificações na Wikipedia: http://en.wikipedia.org/wiki/List_of_Web_service_specifications (em inglês)

Links Externos

• Especificação da arquitetura no W3C: http://www.w3.org/TR/ws-arch/ (em inglês)
• Uma apresentação sobre a arquitetura dos Web services por Marco A. Casanova, PUC-Rio: http://www.inf.puc-rio.br/~casanova/INF2328-Topicos-WebBD/modulo3-Webservices/modulo3a-webservices-arquitetura.PDF