Composição de Serviços

Os mecanismos de composição de serviços associados à arquitetura WSARCH podem ser uti- lizados por meio de um módulo complementar denominado DWSC-M (Dynamic Web Services

Composition Middleware) (Kuehne, 2009) o qual foi implementado testado e validado em outro

projeto de mestrado associado à WSARCH. Apesar deste módulo ainda não estar integrado à ar- quitetura é importante destacar como aplicações compostas podem ser integradas e testadas na WSARCH. Um serviço composto envolve a interação entre diversos Web Services, de modo que o resultado de um funcione como parâmetro de entrada para o próximo Web Service do fluxo, até que uma resposta seja retornada ao cliente que fez a requisição. Por exemplo: Para efetuar a compra de uma passagem aérea para determinado destino, é natural que haja disponibilidade de vôo para o destino desejado, a disponibilidade de reserva em um Hotel e também a disponibilidade de locação em uma locadora de veículos. Nesse sentido, algumas regras de negócios precisam ser discutidas, considerando o fluxo exemplo, descrito na Figura 4.8.

De acordo com o fluxo da Figura 4.7 na arquitetura WSARCH, o cliente deve inicialmente con- sultar o Broker de serviços sobre a disponibilidade de vôos em uma data especificada, um Hotel no destino escolhido e também a possibilidade de haver uma opção de aluguel de veículo na data estipulada. Sendo assim, o Broker da WSARCH deve receber quatro parâmetros na requisição

SOAP enviada pelo cliente: a identificação do cliente (CPF), a data do vôo, o nome ou código

do Hotel e o nome ou código da locadora de veículos. Ao receber a requisição SOAP do cliente, o Broker extrai esses parâmetros e inicia uma busca ao repositório UDDI para pesquisar sobre a

74 4.6. COMPOSIÇÃO DE SERVIÇOS Aluguel Carro Hotel Início Vôo Fim Serviço de Pagamento

Figura 4.8: Fluxo de composição de uma reserva de viagens

existência de serviços candidatos ao atendimento da solicitação do cliente. Como na prática pode haver vários provedores que funcionalmente realizam as mesmas tarefas, a escolha do melhor Web

Servicepara o atendimento da requisição do cliente deve levar em consideração também a carga

de trabalho imposta a um provedor em particular. As informações da carga de trabalho (CPU, memória, disco, paginação, etc), ou a combinação delas por meio de um índice de desempenho serão utilizadas pelo Broker (por meio de um algoritmo de seleção) para uma tomada de decisão. A resposta retornada ao cliente deve obedecer a um acordo de nível de serviço previamente estip- ulado, isto é, os provedores precisam oferecer exatamente aquilo que o cliente deseja ou algo bem próximo ao desejado, desde que isso esteja previsto no acordo. O cumprimento do acordo não é trivial e para que ele seja cumprido, é preciso considerar algumas situações em relação a este fluxo: • Mensagens de sucesso ou falha devem ser enviadas ao cliente do Web Service quando do

término do fluxo.

• O Broker da WSARCH deve registrar a ocorrência das requisições efetuadas pelos clientes e armazenar em uma base de dados auxiliar se a busca por determinado serviço no fluxo foi positiva ou negativa.

CAPÍTULO 4. A ARQUITETURA WSARCH 75 • Cada serviço participante do fluxo deve gerar um ID. Cada ID de um serviço será parte de

um ID_FINAL que corresponde ao fluxo composto.

• O Broker deve realizar o tratamento de erros caso algum serviço no fluxo apresente prob- lemas e o contrato de serviço não possa ser cumprido. Ou seja, se por alguma exceção, o pagamento no Web Service de pagamento não puder ser efetivado, uma operação de roll-

back (desfazer uma transação corrente fazendo com que todas as modificações realizadas

pela transação sejam rejeitadas) deve ser realizada para cancelar a reserva de vôo, reserva de hotel e locação de veículo. Como as informações de cada serviço são identificadas por um ID, o processo de rollback na base de dados será realizado com base neste ID.

• As informações da carga de trabalho de cada provedor serão propagadas periodicamente para o Broker da WSARCH, que as utilizará em conjunto com os algoritmos de roteamen- to/escalonamento de mensagens

O exemplo de composição de serviços apresentado nesta seção é apenas uma das possibilidades de implementação de fluxos de composição na arquitetura WSARCH. A integração do DWSC-M à WSARCH permitirá que novas aplicações possam ser desenvolvidas e seus comportamentos analisados.

4.7 Considerações Finais

Este capítulo descreveu a proposição de uma arquitetura para a provisão de Web Services com qualidade de serviço. Foram apresentados a estrutura inicial da arquitetura, seus módulos, sub- módulos e um levantamento de alguns parâmetros de qualidade de serviços que foram explorados durante o desenvolvimento do projeto de doutorado. Também foram descritas as possíveis inter- ações que podem ocorrer entre os módulos da arquitetura (cliente, Broker e provedores de serviço). Neste capítulo também foi discutido todo o processo de implementação dos componentes da ar- quitetura e as dificuldades encontradas durante essa fase do desenvolvimento. Muitos foram os de- safios técnicos desde o planejamento da arquitetura, o que vai desde a escolha da linguagem de pro- gramação, motor de processamento de mensagens, configuração e implantação da infra-estrutura física, configuração de um firewall para integrar duas redes distintas (clientes e provedores per- tencem a redes separadas), ferramentas de monitoração, até a coleta e análise de dados. No âmbito técnico um dos desafios mais complicados foi determinar qual parte do motor de processamento de mensagens Axis2 deveria ser alterada para a correta obtenção do tempo de processamento de uma mensagem SOAP no provedor de serviços. Essa tarefa não foi trivial pois o Axis2 possui milhares de linhas de código.

Como objetivo principal, este trabalho explora mais detalhadamente uma forma de provisão de

QoSpara os Web Services, utilizando técnicas já existentes, além da proposição de novas metodolo-

76 4.7. CONSIDERAÇÕES FINAIS projeto de doutorado. Uma forma de análise de desempenho dessa arquitetura é necessária, uma vez que há uma carência deste tópico na literatura da área. Nesse sentido, o próximo capítulo descreve todos os procedimentos utilizados para avaliar o desempenho da arquitetura WSARCH. Espera-se que essa avaliação de desempenho sirva como estudo de caso para empresas, prove- dores de serviços e de conteúdo, indústria e órgãos governamentais que queiram se beneficiar da computação orientada a serviço como forma de integrar aplicações, equipamentos e processos de negócios.

C

5

Validação da Arquitetura WSARCH

5.1 Considerações Iniciais

Neste capítulo são descritos os projetos experimentais utilizados para validar a arquitetura WSARCH. Na Seção 5.2 é apresentado como a WSARCH foi configurada para a realização dos ex- perimentos, incluindo as etapas de configuração do ambiente computacional (software e hardware) e o planejamento dos experimentos, ambos necessários para a fase de validação da arquitetura. A validação apresenta dois enfoques. O primeiro visa demonstrar que a arquitetura está funcionando da forma projetada. Nessa fase é realizada uma análise comportamental da WSARCH (Seção 5.3.1), e é verificado como dois componentes da arquitetura (Broker e LogServer) influenciam nos resultados da execução dos serviços (Seções 5.3.2 e 5.3.3). O segundo enfoque visa demonstrar como a arquitetura proposta atinge seu objetivo de ser uma ferramenta que possibilita avaliar o de- sempenho de Web Services com qualidade de serviço (Seções 5.3.4, 5.3.5 e 5.3.6). Para a realização dos testes da arquitetura foi necessário a configuração de um ambiente computacional envolvendo elementos de software e hardware. Para os elementos de software foram utilizados máquinas virtu- ais Java, motores de processamento de mensagens SOAP, aplicações clientes e servidoras, Broker para o roteamento de mensagens SOAP, além de aplicações auxiliares utilizadas para a coleta e análise dos dados proveniente dos estudos dos fatores envolvidos no planejamento de experimen- tos. Para os elementos de hardware foram consideradas unidades de processamento multi-core (todas homogêneas), utilizadas para o processamento de mensagens tanto no cliente quanto nos provedores de serviços. Um número considerável de experimentos podem ser analisados, no en- tanto, em função da natureza dinâmica da arquitetura WSARCH, alguns deles foram escolhidos para serem avaliados.