Arquitetura Orientada a Serviços

A arquitetura orientada a serviços é uma estratégia utilizada para construir aplicações a partir da composição de serviços. Ela surgiu com base no desenvolvimento baseado em componentes e na computação distribuída (Tsai et al., 2005; Krafzig et al., 2004). Seu objetivo é desenvol- ver principalmente sistemas de informação empresariais que se adequem a um fluxo de negócio específico e que tenham fraco acoplamento entre seus módulos, independência de tecnologia de implementação e padrões bem definidos (Papazoglou e Heuvel, 2007).

A unidade básica de composição em uma arquitetura orientada a serviços é chamada de serviço. Serviços são módulos independentes e autocontidos, que oferecem funcionalidades de negócio específicas e são descritos de forma padronizada. A comunicação com os serviços ocorre por meio de invocações remotas de suas interfaces públicas. A arquitetura orientada a serviços é independente de tecnologia específica porque é exigido que os serviços sejam definidos por uma linguagem de descrição padronizada (WSDL) e tenham interfaces com operações de negócio bem definidas. Com essas arquiteturas, as empresas podem criar, implantar e integrar serviços e compor novas funções e processos de negócio pela combinação de novos e antigos recursos de software.

Os serviços são semelhantes aos componentes, pois são unidades independentes e autocontidas que podem ser invocadas somente por meio de suas interfaces (Gross, 2005). A diferença entre eles é que nos sistemas baseados em componentes o desenvolvedor pode integrar fisicamente os componentes em sua aplicação e controlar suas mudanças, enquanto que os serviços não são in- tegrados fisicamente e são vistos apenas como uma interface que pode ser invocada remotamente. Neste caso, as mudanças (correções, atualizações) dos serviços não podem ser previstas pelo de- senvolvedor porque são de responsabilidade de seus fornecedores (Canfora e Penta, 2006, 2009).

Uma implementaçâo popular de serviços adotada atualmente são os serviços Web (web servi- ces). Os serviços Web podem ser escritos em qualquer linguagem, desde que sigam os padrões de

CAPÍTULO 3. TESTE DE SERVIÇOS 21 publicação e comunicação definidos pela arquitetura. Cada serviço deve ser identificado por um URI (Uniform Resource Identifier) e descrito por um arquivo WSDL (Web Services Description Language), que tem a função de descrever o endereço em que o serviço está disponível, as assina- turas de suas operações, incluindo os parâmetros de entrada e de retorno, as exceções previstas e o protocolo de rede utilizado (Papazoglou, 2003; Pulier e Taylor, 2005). Com estas informações os consumidores são capazes de saber como invocar o serviço. Em geral as ferramentas de de- senvolvimento utilizam essas informações para criar stubs locais que representam o serviço Web localmente.

A comunicação com os serviços é feita por meio de mensagens SOAP (Simple Object Access Protocol). Uma mensagem SOAP é formada basicamente pelas seguintes partes: envelope, cabe- çalho (header) e corpo (body). O envelope determina o início e o fim da mensagem e indica para o ponto de rede que o pacote recebido contém uma mensagem SOAP. O cabeçalho é opcional e pode ser usado para adicionar metadados sobre o conteúdo da mensagem e/ou instruções especí- ficas sobre como processar a mensagem recebida. Os cabeçalhos são mecanismos-chave para a extensão do protocolo SOAP por meio de adição de entradas que instruem nós de processamento a se comportarem de modo específico em determinados contextos, como autenticação, autorização, transações, etc. O corpo da mensagem SOAP é que contém a mensagem transmitida do provedor para o consumidor e vice-versa.

Os serviços podem assumir dois papéis na comunicação entre os elementos da arquitetura: provedor e consumidor. O provedor é o que oferece a operação de negócio e consumidor é o que utiliza a operação de negócio do provedor. A comunicação entre serviços pode ser feita de forma direta quando o consumidor conhece o endereço do fornecedor. Quando o endereço não é conhecido, o consumidor precisa de um serviço intermediário (broker) para localizar o serviço do provedor desejado. O serviço intermediário funciona de forma semelhante a uma lista telefô- nica, em que os serviços podem ser registrados e localizados por palavras-chave, tais como nome, funções oferecidas, empresas fornecedoras, etc.

Na Figura 3.1 é apresentado um padrão de arquitetura orientada a serviços. Os componentes da arquitetura são o provedor, o consumidor e o intermediário. Um provedor oferece um serviço e o publica em um ambiente de publicação/descoberta de serviços (intermediário ou broker). O consumidor usa o serviço de publicação/descoberta para achar um serviço adequado para interagir e executar alguma tarefa. O serviço de publicação/descoberta oferece funções para armazenar, classificar e localizar serviços registrados (Heckel e Mariani, 2005). O consumidor também pode conectar-se ao serviço desejado de forma direta, no caso de já conhecer o endereço de rede do serviço, ao invés de procurar o serviço em um intermediário (Tsai et al., 2005).

Uma especificação comumente implementada para os componentes intermediárias são os regis- tros UDDI (Universal Description Discovery and Integration) (Papazoglou, 2003; Pulier e Taylor, 2005). Os registros UDDI em geral possuem uma API (Application Programming Interface) com operações para a criação, leitura, atualização, remoção e busca de serviços e de suas informações. Eles armazenam metadados sobre os serviços publicados para o consumidor conhecer detalhes so-

CAPÍTULO 3. TESTE DE SERVIÇOS 22

Intermediário

(broker)

Provedor de

serviços

Consumidor

de serviços

Figura 3.1: Arquitetura Orientada a Serviços.

bre o serviço. Tipicamente os serviços são descritos por meio de um arquivo WSDL (WebService Description Language).

As aplicações formadas por serviços podem ser tão dinâmicas e flexíveis quanto for necessário. Em uma situação mais conservadora, o sistema pode ser formado por serviços com localizações, interfaces e operações previamente conhecidas. Nesse caso, a aplicação é semelhante a um sistema baseado em componentes, com a diferença de que os serviços não estão sob o controle do integra- dor da aplicação e podem ser independentemente atualizados, tornarem-se indisponíveis ou deixar de atender a requisitos de qualidade esperados, o que pode afetar a qualidade global da aplicação (Baresi et al., 2006).

Em uma situação totalmente dinâmica, o sistema será formado por serviços cujas interfaces são abstratas e serão concretizadas somente em tempo de publicação. Nestes casos, o sistema deve ser capaz de descobrir novos serviços em ambientes de publicação/descoberta quando precisarem ou quando os serviços utilizados estiverem indisponíveis ou deixarem de atender a algum requisito específico. Baresi et al. (2006) chamam esse ambiente dinâmico de mundo aberto (open-world), no qual a previsão das mudanças é difícil ou impraticável, em oposição ao mundo fechado (closed- world), no qual as mudanças são planejadas e controladas.

Os serviços podem ser oferecidos de duas formas: simples ou compostos. Os serviços simples em geral oferecem apenas uma funcionalidade específica e os compostos consistem em um pro- cesso que integra informações e funções de múltiplos serviços (Papazoglou, 2003). A composição de serviços simples para formar serviços mais complexos pode ser feita por meio de qualquer lin- guagem e ambiente capazes de usar serviços e interligá-los para atender a um propósito específico, como a linguagem Java, por exemplo. Uma linguagem comumente utilizada para a especificação de composições de serviços é a BPEL (Business Process Execution Language), que é usada para compor um conjunto de serviços em um fluxo de negócios e funciona basicamente como um código de ligação (glue code) para a integração de serviços. A linguagem possui meios para especificar parceiros, variáveis, atividades, tratamento de dados, eventos e exceções.

CAPÍTULO 3. TESTE DE SERVIÇOS 23