Sistemas de Informação Distribuídos/Interoperação/Web Services/Arquitetura e componentes
Arquitetura e componentes
editarA 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.[1]
- 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 prlo 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.
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
editarAs 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
editar[2] 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
editarAlé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)
Ligações externas
editar- 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
Bibliografia
editar- ↑ Stal, Michael. "Web Services: Beyond Component-Based Computing", Communications of the ACM, Volume 45, Issue 10, 71-76, October, 2002.
- ↑ Curbera, F.; Khalaf, R.; Mukhi, N.; Tai, S. and Weerawarana, S. "The next step in Web services" Communications of the ACM, Volume 46, Issue 10, Special Section: Service-oriented computing, 29-34, October, 2003