Computação Orientada a Serviço

Um outro paradigma que pode ser utilizado para montar aplicações a partir de unidades elementares de reuso é a orientação a serviços (PAPAZOGLOU et al., 2007). A introdução desse paradigma teve um forte impacto na perspectiva sob a qual o reuso dos elementos de software era tradicionalmente considerado. No centro dessa nova perspectiva está a noção de “mundo aberto” (BARESI; Di Nitto; GHEZI, 2006; Di Nitto et al., 2008).

Segundo Baresi, Di Nitto e Ghezi (2006), todo o desenvolvimento de software tradicio- nal estava fundamentado na presunção de que as fronteiras entre os sistemas e os ambientes correspondentes eram conhecidas e estáveis. Assim, um levantamento cuidadoso dos requi- sitos seria capaz de capturar todas as características necessárias e identificar os elementos que compõem os ambientes de execução. Os sistema desenvolvidos com base nessa pers- pectiva de “mundo fechado” não eram capazes de se adaptar às mudanças que não haviam sido previstas quando do seu projeto original. Como veremos, a proposição de SOC teve um impacto direto nesse cenário, viabilizando a construção de aplicações mais dinâmicas e flexíveis baseadas na composição de elementos auto-contidos e reusáveis, referenciados como serviços.

2.2.3.1 Serviço

Um serviço (CERVANTES; HALL, 2004; PAPAZOGLOU et al., 2007) é uma funcionalidade autônoma, coesa, e reusável, descrita de forma contratual através de um descritor de

serviço. Esse descritor especifica um serviço através de sua interface funcional, e pode

conter, também, informações referentes à semântica, ao comportamento, e ao nível de qualidade.

Em SOC, os serviços podem ser dinamicamente descobertos e invocados em função do estilo arquitetural SOA, o qual especifica as interações entre três papeis distintos: prove- dor, consumidor e registro de serviços. Os provedores publicam descritores de serviços em um registro, que é utilizado pelos consumidores para buscar serviços com as caracterís- ticas necessárias. Ao receber a lista de serviços candidatos, o consumidor deve selecionar aquele que considera mais adequado e ligar-se a ele para que possa realizar requisições.

O conceito de serviço e o estilo arquitetural SOA posicionam a orientação a serviços como um paradigma natural para a construção de plataformas com suporte aos sistemas auto-adaptativos. De fato, por serem fortemente coesos, os serviços podem ser facilmente isolados, servindo para estabelecer fronteiras entre funcionalidades distintas. Além disso, o baixo acoplamento, decorrente da capacidade de descoberta, seleção, e ligação dinâmica, facilita a substituição dos serviços utilizados por uma aplicação, viabilizando a realização da adaptação composicional.

A possibilidade de utilização de serviços disponibilizados por terceiros introduziu um aspecto completamente novo no contexto do reuso. De fato, ao reusar um serviço de software fornecido por um terceiro, uma aplicação não está somente fazendo uso de um componente de negócio desenvolvido e mantido por esse terceiro, mas sim delegando para ele a responsabilidade pela execução e gerenciamento de parte da aplicação, uma vez que ela não tem nenhum controle sobre o ambiente no qual o serviço está em execução (Di Nitto et al., 2008).

Por fim, é importante ressaltar que a essência de SOC, materializada nas definições de serviço e de SOA, não envolve nenhum aspecto tecnológico, de forma que a orientação a serviços pode ser implementada utilizando-se diferentes tecnologias.

2.2.3.2 Composição de Serviços

Uma composição de serviços é, em essência, um programa que realiza a sua funcionalidade através do consumo de um conjunto de serviços. Dada a sua natureza programática, uma composição deve possuir um fluxo de controle que é responsável por realizar a coordena- ção da invocação dos serviços e a transferência de dados entre eles (CERVANTES; HALL, 2004). A natureza agnóstica inerente ao estilo arquitetural SOA viabiliza a utilização de diferentes linguagens para descrever o fluxo de controle de uma composição, desde lin- guagens de uso geral, até linguagens próprias para descrição de fluxos de trabalho (i.e.,

Figura 4 – Níveis de composição de serviços

Fonte: baseada em Davis (2009)

workflows).

Em SOC, serviços e composições são tipicamente organizados em níveis (vide Fi- gura 4). O nível mais baixo apresentado na figura é composto pelos sistemas de infor- mação, os quais realizam as funcionalidades de negócio disponíveis. Essas funcionalidades são tipicamente expostas por serviços primitivos de baixa granularidade, os quais são referenciados na figura como “serviços de baixo nível”. Esses serviços são utilizados em composições que oferecem serviços de maior granularidade. Por fim, os serviços primitivos e as composições podem ser utilizados na montagem de processos de negócio, os quais são composições de mais alto nível, normalmente caracterizadas por execuções longas e estados de espera (DAVIS, 2009).

Independentemente do nível e da linguagem utilizada, uma composição de serviços deve ser descrita em termos de referências para interfaces dos serviços requeridos, as quais somente devem ser resolvidas em tempo de execução, quando os provedores de serviços são dinamicamente descobertos e ligados às respectivas referências. Neste contexto, a composição deve tratar de diversas particularidades próprias da abordagem orientada a serviços, tais como a disponibilidade dinâmica (CERVANTES; HALL, 2004), e a filtragem e seleção dos serviços candidatos utilizados pela composição.

2.2.3.3 Ambiente de Execução

Para que serviços e composições possam ser utilizados, eles devem ser instalados em uma infraestrutura de suporte, referenciada como ambiente de execução. Segundo (PA-

PAZOGLOU et al., 2007), os ambientes de execução devem possuir mecanismos capazes de

suportar: (1) a interação entre provedores e consumidores de serviços, (2) a composição dinâmica de serviços em unidades de maior granularidade, e (3) o gerenciamento dos serviços e composições.

arquitetural SOA. Um elemento central neste contexto é o registro de serviços. Como vimos, um registro funciona como um elemento de indireção que armazena descrições dos serviços disponíveis, podendo ser consultado dinamicamente para descoberta de serviços candidatos. Diferentes modelos de registros compreendem diferentes descrições de serviços e implementam diferentes operações. Visando manter a descrição de um registro sob uma perspectiva conceitual, pode-se dizer que um registro suporta idealmente as seguintes operações: publicação, retirada, atualização, consulta, e notificação.

As operações de publicação, retirada, e atualização compõem a perspectiva do pro- vedor de serviços. A operação de publicação é utilizada para cadastrar uma descrição de um serviço fornecido, associando a essa descrição uma referência para o serviço corres- pondente. A operação de retirada é utilizada com o intuito de remover uma descrição de serviço, inviabilizando a descoberta dinâmica do mesmo. Por fim, a operação de atualiza- ção visa permitir que a descrição do serviço oferecido seja modificada dinamicamente.

Do ponto de vista dos consumidores, as operações relevantes são consulta e notificação. A operação de consulta é utilizada por consumidores para descobrir, sob demanda, serviços com as características necessárias a partir de uma descrição do serviço requerido, a qual normalmente está associada à sua interface. Essa descrição também pode envolver outras propriedades, tais como informações referentes aos provedores de serviços ou ao nível de qualidade requerido. A partir da descrição informada por um consumidor, o registro realiza uma filtragem, retornando para o cliente uma lista contendo os serviços candidatos, cabendo ao consumidor a responsabilidade pela seleção do serviço e pela ligação dinâmica. A operação de notificação visa oferecer maior suporte ao dinamismo, permitindo que um consumidor se registre para receber notificações referentes à publicação, retirada, e atualização de descrições de serviço.

O suporte à composição dinâmica de serviço é normalmente realizado por motores de execução e contêineres embutidos nos ambientes. Os motores de execução são responsá- veis por realizar composições comportamentais descritas por fluxos de trabalho, realizando processos de negócio. Uma vez que a presente tese não trata desses processos, as com- posições comportamentais não serão mais exploradas. Por outro lado, as composições estruturais são suportadas por contêineres que buscam e selecionam serviços requeridos e os integram às composições através de mecanismos de injeção de dependências. Com o intuito de guiar a atuação dos contêineres, as características dos serviços requeridos são tipicamente descritas através de uma ADL. A utilização de contêineres em plataformas orientadas a serviços é discutida na Seção 2.2.4.

Sob a perspectiva do gerenciamento, os ambientes de execução devem compreender mecanismos para permitir desde a instalação e configuração de serviços primitivos e com- postos, até a monitoração e eventuais ajustes nesses serviços. Mais ainda, esses ambi- entes devem idealmente fornecer mecanismos que permitam o gerenciamento do próprio ambiente e dos serviços que ele oferece. Por fim, de forma similar aos ambientes de exe-

cução no mundo de componentes, diversos serviços técnicos responsáveis por aspectos não-funcionais também são comumente integrados aos ambientes de execução.