Um Plugin para Monitoramento e Gerenciamento de Web Services baseados em SOAP

Adair Jose Rohling1, Vinicius Cardoso Garcia2

1Centro de Estudos e Sistemas Avançados do Recife – C.E.S.A.R. EDU

2Centro de Informática – Universidade Federal de Pernambuco

adairrohling@gmail.com, vcg@cin.ufpe.br

Abstract. Web Service has been playing a significant role in application development and integration. However there are still challenges to attend its enormous potential, one of these challenges is to check the behavior and Quality of Service (QoS) available. This paper presents a solution in form of a plugin that allows performing monitoring and management of Web Services based on SOAP W3C standard, non-intrusive to the codification and decoupled from the execution environment. To achieve the objectives the solution performs an extension of the JAXWS API and makes use of dynamic instrumentation process through JMX API. Resumo. Web Services tem desempenhado um papel significativo no desenvolvimento e integração de aplicações. Entretanto há ainda desafios para atender seu amplo potencial, um destes desafios é verificar o comportamento e a qualidade dos serviços disponibilizados. Esse trabalho apresenta uma solução em forma de um plugin que permite realizar o monitoramento e gerenciamento de Web Services baseados no protocolo SOAP padrão da W3C, de forma não intrusiva à codificação e desacoplada do ambiente de execução. Para atingir os objetivos a solução realiza uma extensão da API JAXWS e faz uso do processo de instrumentação dinâmica através da API JMX.

1. Introdução O crescimento e a popularização da transferência de documentos entre computadores em redes permitiram a integração entre sistemas e algumas tendências aumentaram a necessidade da integração entre processos em diferentes organizações. Para Will et al.(1999), Casati (2001) e Dayal (2001), o aumento do outsourcing e do comércio eletrônico, produz a necessidade da integração e automação destes processos nas organizações. Boniati (2003), define que Web Services é uma solução para as necessidades de integração, pois em seu princípio utiliza padrões abertos de protocolos de comunicação e de linguagens. Segundo o W3C (2008), a ideia por trás do conceito de Web Services é oferecer um padrão para interoperabilidade entre diferentes aplicações de software, que possibilite a execução dessas aplicações de maneira independente de plataforma ou arquitetura.

De acordo com Cerami (2002), Web Services estão se tornando a forma mais bem aceita para disponibilizar e-business na web, bem como permitir que os usuários, sejam estes humanos ou outros serviços da web, possam usá-los. De acordo com pesquisas do Gartner (2004), organizações que querem manter-se competitivas terão que frequentemente fornecer dados aos seus parceiros através de Web Services, e isso irá transformar a indústria de TI e de serviços de software. Atualmente várias organizações possuem seus serviços implantados através de Web Services, consequentemente vários dados são recebidos e transmitidos. Entretanto, não basta somente receber e transmitir esses dados, também é necessário oferecer qualidade nestes serviços. Andrieux et al. (2004), descrevem que “as organizações que contratam ou disponibilizam um Web Services também tem interesse em especificar quais as capacidades, requisitos e garantias que determinado serviço oferece, bem como em monitorar se essas capacidades estão sendo respeitadas”. Para tratar destes interesses surge a necessidade da criação de mecanismos que auxiliem na automatização destas tarefas.

Este artigo apresenta o plugin1 WSMM (Web Services Management and Monitoring) como uma proposta para realizar gerenciamento e monitoramento de Web Services baseados em SOAP, que é o protocolo padrão da W3C para Web Services. O plugin realiza a descoberta dos serviços implantados e inicia o processo de monitoramento, verificando as características não-funcionais dos Web Services.

No restante desse artigo, as seções estão definidas da seguinte forma: Seção 2, descreve o estado da arte de alguns conceitos como Web Services, mecanismo de monitoração e gerenciamento, na Seção 3, é apresentado alguns trabalhos relacionados, na Seção 4 é apresentado o plugin WSMM, seu desenvolvimento, sua arquitetura e suas funcionalidades, na Seção 5 é realizado um validação da proposta, na Seção 6, são descritas as considerações finais e propostas de trabalhos futuros. 1.1. Caracterização do problema Quando adquirirmos algum hardware, como componentes de redes ou impressoras, os fabricantes disponibilizam ferramentas para o seu monitoramento e gerenciamento. Porém quando falamos de aplicações de software muitas vezes não é disponibilizado recurso algum para estas tarefas. Quando Web Services estão em produção estes serviços podem estar apresentando algum tipo de problema como sobrecarga, tempo de resposta muito elevado, erro ou falhas na lógica do desenvolvimento. A não existência de um processo de monitoramento e gerenciamento pode refletir em sérios prejuízos para as organizações.

A tecnologia de Web Services possui várias características importantes, porém para tratar de interesses não-funcionais ainda não disponibiliza um modelo padrão para tratar estas características. Shuping (2003), indica que a falta de informações sobre atributos de qualidade dos Web Services é uma das causas da lenta taxa de adoção desta tecnologia.

                                                                                                                         1  Extensões  para  aplicação  são  chamadas  de  Plugin  (Szyperski,  2002  ),  usado  normalmente  para  prover    funcionalidades  específicas.  

Algumas soluções para monitorar e gerenciar Web Services estão disponíveis através do próprio ambiente de execução (servidores de aplicação) destes serviços. Outras soluções, em menor ou maior grau, estão acoplados até mesmo, misturando-se à implementação de seus interesses funcionais. Podendo assim afetar negativamente o desenvolvimento de aplicações, dificultando não apenas a sua implementação, mas também a sua subsequente manutenção e evolução.

1.2. Objetivos Como principal objetivo do trabalho, foi implementar um plugin para realizar em tempo de execução a interceptação, monitoração e gerenciamento de Web Services, desacoplada de ambiente de execução, de forma não intrusiva à codificação. Além disso, como objetivos específicos podem-se destacar:

• Apresentar uma alternativa para realizar a interceptação de Web Services em nível do protocolo SOAP.

• Apresentar uma validação do plugin com o intuito de avaliar o impacto no desempenho e também verificar a independência do ambiente de execução.

1.3. Metodologia Este estudo caracterizou-se através da multiplicidade de meios, como pesquisa em artigos e livros, tecnologias, componentes, ambiente de execução, ferramentas e técnicas para a construção de um produto de software.

Será realizada uma pesquisa quantitativa através de um experimento verificando o impacto no desempenho, quando da adoção do uso do plugin no processo de monitoramento e gerenciamento. Outra análise será realizada para verificar se o plugin é funcional independente do ambiente de execução. 2. Estado da Arte 2.1. Web Services Web Services surgiram como uma evolução dos modelos da computação distribuída, como IIOP, RMI, DCOM e o Corba, tendo como principal diferencial a possibilidade de comunicação entre ambientes heterogêneos. Segundo Kalin (2009), Web Services podem ser divididos em dois grupos, baseados em SOAP e de estilo REST. REST e SOAP são muito diferentes. SOAP é um protocolo de mensagem, enquanto que REST é um estilo de arquitetura de software para sistemas hipermídia distribuídos. A literatura atual apresenta diversos modelos de Web Services, neste trabalho será baseado no modelo do W3C, onde Booth et al.(2004) na documentação do modelo W3C realizam a definição de Web Services como:

• Sistema de software projetado para apoiar interações entre computadores em uma rede;

• Interface descrita em um formato processável por máquina (especificamente WSDL – Web Service Description Language);

• Outros sistemas que interagem com um serviço conforme sua descrição utilizando mensagens SOAP. Essas mensagens são dirigidas utilizando geralmente o protocolo HyperText Transfer Protocol (HTTP) com uma serialização XML.

Foram encontradas na literatura várias outras definições para Web Services, entre elas Austin et al. (2002), definem Web Services como uma aplicação identificada por uma URI (Universal Resource Identifier), cujas interfaces e implementações são capazes de serem definidas, descritas e localizadas, utilizando-se a linguagem XML e suas ferramentas. Um serviço web deve ser capaz de interagir com outras aplicações, através da troca de mensagens baseadas em XML, utilizando os protocolos de comunicação existentes na Internet.

Outro conceito é dado por Papazoglou e Georgakopoulus (2003), onde Web Services são considerados um tipo especial de serviço que fica disponível em um endereço de acesso na Web, através de um identificador universal (URI), onde o mecanismo de transporte utiliza padrões abertos, baseados em XML. 2.1.1 Tecnologias de Web Services As tecnologias de Web Services são apresentadas através de três áreas básicas, o protocolo de mensagens, descrição de serviços e a descoberta de serviços. O protocolo SOAP (Simple Object Access Protocol) é o protocolo padrão de mensagens proposto pela W3C para transmissão de dados dentro da arquitetura de Web Services.

Castillo et al. (2011) definen que SOAP pode ser considerado como uma evolução do protocolo XML-RPC, muito mais completo e maduro, que permite realizar chamadas de procedimento remoto para rotinas distribuídas (serviços) com base em uma interface XML.

WSDL (Web Service Description Language) é um documento em formato XML utilizado para descrever um Web Services, permitindo que Web Services publique a interface de suas funções em um formato das mensagens de requisições e de respostas.

UDDI (Universal Description, Discovery and Integration) é uma especificação que descreve um padrão para publicar e descobrir Web Services em um repositório com uma rígida estrutura de dados que descreve empresas e seus Web Services. Abaixo é apresentada na Figura 1 a arquitetura de comunicação em Web Services envolvendo as principais tecnologias.

Figura 1. Arquitetura Comunicação Web Services [Sommerville 2007]

A Figura 1 ilustra como os Web Services são usados no processo de

comunicação. Os provedores de Web Services projetam e implementam os Web Services realizando a especificação em linguagem WSDL. Também é publicado informações sobre esses Web Services em um registro de acesso geral usando o padrão de publicação UDDI. Os solicitantes de Web Services buscam o registro UDDI para descobrir a

especificação desses Web Services e a localização do provedor Web Services, então o solicitante e provedor realizam a comunicação através do protocolo SOAP. 2.2. Mecanismos de Monitoração e Gerenciamento Para as organizações possuírem uma gestão de seus recursos é necessário ter ferramentas que informam o comportamento de seus aplicativos e hardware. Tosic (2005), descreve que com base no comportamento dos recursos, pode reagir a eventuais falhas no sistema e eventos críticos. Ocasionando uma maneira mais efetiva no papel da resolução dos problemas e acomodar mudanças.

Wang et al. (2009) conceituam monitoramento de software como a obtenção das informações relativas ao estado e comportamento de sistema de software em tempo de execução, a fim de lidar com potenciais desvios de comportamento dos requisitos mais cedo possível. A realização de monitoramento utilizando intermediários SOAP como forma de implementar interesses não-funcionais de serviços não é uma ideia nova, fazendo parte da especificação SOAP desde suas primeiras versões conforme Gudin e Hadley (2003) e também é suportada pela maioria dos frameworks que suportam Web Services atuais, como o framework Axis.

Clark et al. (2003) definem que monitores em Web Services são implementados como um intermediário do serviço web podendo interceptar as mensagens para algum serviço e depois encaminhar para seu destino. Booth et al. (2004) mostram que um intermediário de Web Services está localizado entre um cliente de serviço e um provedor de serviço. Mitra et al. (2006) apresentam que os intermediários Web Services também podem manipular o conteúdo das mensagens SOAP, incluindo o cabeçalho para definir algum tipo de extensão SOAP.

Diferentes mecanismos estão disponíveis para realizar monitoração em Web Services. Geralmente esses mecanismos podem ser classificados em duas categorias, aqueles baseados em instrumentação ou com base em um interceptador conforme Li (2006) e Chen (2003).

Conforme Wang et al. (2009 a instrumentação é o mecanismo mais utilizado na monitoração, também é amplamente usado nos processos de testes. Nesta abordagem, o código de monitoramento é incorporado dentro do alvo de código. Tradicionalmente, o código de instrumentação é inserido manualmente pelos programadores. A característica mais importante desta abordagem é que o código pode ser inserido livremente em qualquer local no monitorado do código. Outra razão para usar a instrumentação é que não precisa de apoio da plataforma. Atualmente alguns dos novos mecanismos de instrumentação, tais como Javaassit2, JMX e AspectJ, são desenvolvidos, com a finalidade de instrumentação de código dinâmico de acordo com informações de configuração.

Os interceptores são amplamente utilizados nas implementações de Web Services. Com interceptadores é possível obter detalhes das mensagens dos serviços e, portanto, pode ser usado naturalmente no processo de monitoramento. Interceptadores em CORBA, filtro do Framework Axis, Handler Framework para API JAX-WS,

                                                                                                                         2    Biblioteca  para  realizar  manipulação  de    bytecode  em  Java  

Interceptadores no EJB versão 3.1 e JVMTI3, são todos interceptores conhecidos que podem fazer algum processamento de mensagens. A característica mais importante de interceptadores é que são independentes do sistema de destino tanto no tempo de codificação e tempo de execução.

2.2.1. JMX O JMX (Java Management Extensions) é uma extensão aberta e universal da linguagem Java que possibilita a instrumentação de aplicações para provedores de serviços gerenciem ambientes heterogêneos de uma maneira padrão. Foi introduzida na JavaSE (Java 2 Standard Edition) versão 5.0, com esta API JMX é possível criar a aplicação totalmente gerenciável , monitorável e configurável. Podendo expor os componentes da sua aplicação, atributos e configurações para os utilitários de gerenciamento, esse processo é chamado de instrumentação. Conforme Mahmoud (2004), a arquitetura JMX é dividida em três níveis: nível de instrumentação, nível de agente e nível de gerenciamento através de serviços distribuídos, a arquitetura é apresentada na Figura 2.

Figura 2. Arquitetura JMX [Mahmoud 2004].

Conforme Sullins (2003) e Perry (2002), o nível de instrumentação está mais

próximo dos recursos que serão monitorados, é onde ocorre a coleta das informações destes recursos e exposto suas funcionalidades. Esse processo é realizado através dos MBeans que conforme Perry (2002), são objetos Java que implementam uma interface e segue o padrão de projeto Listener e Emitter para informar o MBeanServer as mudanças de registro e as mudanças internas respectivamente. No nível de agente é fornecido os agentes de gerência, que são recipientes que contêm a base dos serviços de gerência, é formada por duas partes; os agentes de serviços JMX e o MBean Server, que conforme

                                                                                                                         3   Interface   padrão   que   permite   que   bibliotecas   nativas   (conhecidas   como   agentes)   controlem   uma  máquina   virtual   em   execução   obtendo   informações   sobre   o   aplicativo   Java   em   execução.   Em  http://docs.oracle.com/javase/1.5.0/docs/guide/jvmti/jvmti.html    

Perry (2002), funciona como um registro de MBeans e um broker para realizar a comunicação entre as aplicações e os próprios agentes JMX. No último nível da arquitetura o gerenciamento através de serviços distribuídos é disponibilizado os agentes JMX para ser acessado, podendo fazer essa distribuição de duas formas, através de adaptadores com visibilidade dos MBeans em diferentes protocolo como HTTP e SNMP, outra forma de acesso é utilizando conectores para outras tecnologias, tais como Java RMI, Java JNI (Java Native Interface) ou através Web Services com a especificação JSR-262(Web Services Conector for Java Management Extensions Agents). 2.2.2 Framework Axis O Framework Axis (eXtensible Interaction System) da Apache Software Foundation, é uma implementação baseada em Java do protocolo padrão W3C SOAP, é usado para descrever aplicação servidor e cliente de Web Services. Possui uma arquitetura flexível e extensível, facilitando a adição de novas funcionalidades e suporte para novas especificações. Atualmente o framework se encontra na versão 2.0, a seguir é apresentada a arquitetura do framework.

Figura 3. Arquitetura Framework AXIS [Gopalakrishnan 2005].

Como pode ser observado na Figura 3, a arquitetura do framework Axis

disponibiliza várias fases e manipuladores durante o processo de comunicação entre as requisição e resposta dos Web Services. Em Tosic et al. (2005), descrevem que o Framework Axis não contém módulos para medição ou cálculos de métricas para QoS, não possuindo suporte embutido para monitoramento destas atividades. Porém em virtude da extensibilidade do framework é possível acrescentar estas funcionalidades. 2.2.3. JWS Handler Framework JAX-WS (Java API for XML-Web Services) oferece um Handler Framework que permite realizar o monitoramento e a manipulação de mensagens SOAP de entrada e saída. É disponibilizado dois tipos de manipuladores o LogicalHandler e SOAPHandler. O LogicalHandler tem apenas acesso ao corpo da mensagem SOAP, enquanto que SOAPHandler tem acesso a mensagem inteira incluindo cabeçalho, corpo e anexos.

Quando existe uma cadeia de manipuladores para execução de tipos diferentes a ordem de execução segue uma sequência de um arquivo de configuração e diferencia conforme o tipo do manipulador, essa ordem é apresentada na Figura 4.

Figura 4. Ordem execução Manipulador- JWS Handler Framework [Kalin 2009] A monitoração e manipulação dos serviços pode ser realizada

programaticamente com a necessidade de inserção de códigos no próprio serviço ou através de uma arquivo de metadados como handler-chain.xml e com a inclusão da anotação @HandlerChain nos serviços a serem monitorados conforme Kalin (2009).

Realizar monitoramento usando JAX-WS programaticamente ou fazendo uso de arquivo de metadados com anotações, juntamente ao código dos serviços não torna independente o processo de monitoramento com a lógica do serviço, pois apresenta a necessidade da inclusão da anotação @HandlerChain e também consequentemente a recompilação e reimplantação destes serviços a cada modificação. 2.2.4 Ferramentas de Monitoração Conforme Kalin (2009), o monitoramento de Web Services pode ser realizado também através de algumas ferramentas, que capturam o tráfego de baixo nível de rede para mensagens SOAP no protocolo HTTP. Exemplos destes produtos comerciais e open source, são o tcpmon, SOAPscope, NetSniffer, Wireshark e WinDump. Abaixo é ilustrado como é realizado este processo.

Figura 5. Pacotes de Redes Capturados na Pilha de Protocolos [Sahai e Graupner 2005]

Na Figura 5 é apresentado como as ferramentas podem capturar o tráfego da rede em diferentes camadas e protocolos, a vantagem da utilização desta abordagem é a

não existência do processo de instrumentação, porém conforme apresentado por Sahai e Graupner (2005), a abordagem pode se tornar inadequada devido ao alto grau de tráfego destes protocolos juntamente com a necessidade de mecanismo eficientes de filtragem, além disso, durante uma comunicação criptografada os dados capturados estarão em formato inadequado. 3. Trabalhos Relacionados Alguns trabalhos como Menasce (2002) e Leymann (2002) apresentam a necessidade dos padrões de Web Services no tratamento de atributos de qualidade, Leymann (2002) também apresenta a importância do tratamento destes atributos no processo de gerência, já em Wei et al. (2005), apresentam que o monitoramento é a base para outras atividades de gestão. Nestes contextos várias atividades de pesquisas estão sendo realizadas para tratar destes interesses, em Garcia (2007), apresenta as seguintes necessidades para realizar o tratamento dos atributos de qualidade para Web Services:

• Especificação de características não-funcionais de Web Services; • Publicação de atributos de qualidade de serviço e descoberta de serviços

considerando parâmetros de qualidade; • Verificação de características não-funcionais com o objetivo de garantir

níveis de qualidade. Com o objetivo de realizar a especificação de características não-funcionais dos

Web Services, são apresentadas as abordagens, Web Service Offerings Language (WSOL) de Tosic (2002), SLAs (Service Level Agreements) do trabalho de Keller e Ludwig (2003), a abordagem GlueQoS de Wohlstadter et al. (2004), (WSEL) Web Services Endpoint Language de Sivashanmugam (2005).

Para realizar a publicação de atributos de qualidade de Web Services e descoberta de serviços são apresentados o sistema UX (UDDI eXtension) de Chen (2003), UDDIe, uma extensão para o padrão UDDI é apresentada em ShaikhAli (2002), Maximilien e Singh (2004) apresentam WSAF (Web Services Agent Framework) e um modelo proposto por Kokash (2005).

A necessidade do processo da verificação das características não-funcionais, que é a principal característica contemplada através do processo de monitoramento deste trabalho, é apresentada de forma mais detalhada através de alguns trabalhos relacionados a seguir. 3.1. WSOI (Web Service Offerings Infrastructure) Em Wei et al. (2005), apresentam os detalhes técnicos da WSOI (Web Service Offerings Infrastructure), que disponibiliza o monitoramento de Web Services das classes de Web Services descritas pela linguagem WSOL de Tosic (2002). Nesta proposta é realizado uma extensão do Framework Axis através da criação das classes WSOIHandler e WSOIChain que são estendidas das classes Handler e Chain do framework. Com adoção desta extensão foi reduzido o tempo de desenvolvimento da solução através do suporte a flexibilidade e extensibilidade deste framework.

Em Silva (2008) apresenta uma abordagem baseada em instrumentação com uso do paradigma orientado a aspectos para monitoramento de contratos eletrônicos, chamada de AspectMonitor. É definida uma arquitetura para implementação da

abordagem com as atividades e responsabilidades das organizações envolvidas e um conjunto de regras de mapeamento de contratos eletrônicos, para aspectos de monitoramento. O tratamento do monitoramento é realizado por aspectos monitores que atuam no processo de negócio e envia dados de monitoramento para Web Serivces monitores. Esta abordagem tem como foco principal o atendimento ao monitoramento de contratos eletrônicos com necessidade de um sistema que apoie a execução de processos de negócios em AO4BPEL (Aspect Oriented extension to BPEL4WS) de Charfi, (2004), a qual não existe ainda apoio computacional para publicar o processo de negócio e os aspectos de monitoramento.

Em outras propostas de linguagens de especificação de contratos eletrônicos como WSLA de Dan et al. (2004) e WS-Agreement de Andrieux et al. (2004), conforme Silva, (2008) define como mecanismos de monitoramento que apresentam algumas desvantagens como o excesso de instrumentação necessária no processo de negócio, excesso de novas funções que devem ser implementadas no cliente e servidor e à falta de ferramentas disponíveis para implementação efetiva do estabelecimento e monitoramento propostos. Com estas características a adoção da abordagem poderá apresentar algumas dificuldades em relação a desempenho, manutenção e a necessidade de implementação de novo ambiente de monitoração.

Wang et al.(2009) apresentam uma proposta de monitoração de requisitos de Web Services em tempo de execução, seu trabalho é direcionado para requisitos funcionais, realizando controle de algumas restrições de valores, como tamanho máximo e mínimo de campos, tipo de dados e intervalos de valores. Este controle é realizado baseado na linguagem de descrição, chamada WSCDL (Web Service Constraint Description Language) e o protótipo usado para realizar a interceptação de Web Services é baseado no framework Axis 2.0.

Han et al. (2006) apresentam um framework e técnicas associadas para oferecer suporte a validação automática do comportamento dos Web Services em tempo de execução. Neste framework o MM (Monitor de Mensagens) é o componente que foi desenvolvido para conectar-se ao SMS (Monitor de Serviço SOAP) do Axis, para recuperar as mensagens e realizar a validação. Esta abordagem tem como principal objetivo dar suporte a validação dos Web Services através do processo de monitoração, onde este monitoramento é realizado com auxílio do SMS do Axis 1.2, ficando assim vinculado ao uso restrito deste framework.

WSAL (Web Service Aspect Language), é uma proposta apresentada por Silva (2006), onde utiliza conceitos fundamentais da programação orientada a aspectos, onde interesses não-funcionais são modularizados em aspectos e implementados na forma de serviços, nesta proposta o combinador intercepta o tráfego SOAP em nível de rede e não especificamente no ambiente de execução dos Web Services, para realizar o processo de interceptação do tráfego em nível de rede faz uso da tecnologia de intermediários web, adotando a proposta WBI4 de Barrett e Maglio (1998), que consiste em um servidor proxy programável construído na plataforma Java.

Em Verheecke e Cibran (2003), apresentam uma camada de gerenciamento de Web Serivices chamada Web Services Management Layer (WSML), a qual é colocada entre a provedor e consumidor de Web Services. Exigindo consumidores de Web Services requisitem os serviços através de uma interface abstrata, após a camada WSML

                                                                                                                         4  http://www.almaden.ibm.com/cs/wbi  

realiza a seleção dinâmica para os serviços reais a serem utilizados na integração dos serviços em uma aplicação. A proposta utiliza a linguagem JAsCo apresentada em Suvée et al. (2003), para realizar a modularização dos aspectos para seleção dos serviços.

Alguns Servidores de Aplicações possuem recursos para monitorar Web Services, como JbossAS que pertencente a Red Hat e o WebLogic da Oracle. No Servidor de Aplicação JbossAS foi desenvolvido como parte de sua solução o JBossWS, um framework para Web Services que foi recentemente descontinuado a partir da versão 4.0.2 (Jboss, 2012), sendo a monitoração de Web Services através do JbosAS está disponível com através do JBoss ON (JBoss Operations Network) que provê uma solução centralizada para monitoração e gerenciamento da plataforma. A Oracle disponibiliza através de servidor de aplicação WebLogic, o acesso ao monitoramento dos Web Services baseados na API JAX-WS. O acesso é realizado via browser no console de administração, onde são disponibilizados alguns exemplos de monitoramento, como contagens de invocação dos serviços, total de erros encontrados no acesso, tempo médio de execução dos serviços e listagem de portas monitoradas. 4. Plugin WSMM A partir dessa seção, este artigo apresenta a especificação do plugin WSMM, que foi desenvolvido para realizar o monitoramento e gerenciamento de Web Services baseados na arquitetura SOAP. As seções seguintes apresentam o Padrão Arquitetural adotado, o Processo de Interceptação dos Envelopes SOAP, Processo de Implantação e suas Funcionalidades. O plugin WSMM é disponibilizado através do site http://code.google.com/p/wsmm, é uma ferramenta de uso livre (gratuito), a sua forma de licenciamento é a BSD 2 License, onde a redistribuição e o uso nas formas binárias e código fonte, com ou sem modificações são permitidos com algumas restrições.

Para atingir o objetivo de realizar a interceptação e monitoramento de Web Services de forma independente, como decisão tecnológica partiu do princípio de selecionar somente as próprias APIs presentes na plataforma Java. Essa decisão vem de encontro com a própria concepção heterogênea e fracamente acoplada que caracteriza os Web Services baseados em SOAP.

Como o envelope SOAP é o meio em comum de comunicação de qualquer tecnologia envolvida no processo, representa ser a opção mais viável para realização do processo de monitoramento com base neste protocolo. Nas seções seguintes serão apresentas como foi desenvolvida a solução para realizar o processo de interceptação no nível de envelopes SOAP. Em seguida, será apresentado como foram disponibilizados alguns atributos de qualidade dos Web Services, os quais são fornecidos sem a necessidade de descrever ou configurar estas operações, pois o plugin realiza o processo de descobrimento destas operações durante o processo de implantação. Abaixo é apresentada uma visão geral da arquitetura do ambiente de execução do plugin WSMM.

Figura 6. Visão Geral Arquitetura Ambiente de Execução

Na Figura 6 é apresentada a arquitetura em um ambiente em execução, com o

plugin WSMM em funcionamento. O processo de solicitação e resposta dos Web Services é realizado normalmente. No contêiner de Web Services esta implantado duas aplicações, uma sem fazer uso do plugin, e outra aplicação com o plugin implantado, neste caso o plugin realiza a interceptação das requisições e respostas do envelopes SOAP através da extensão da biblioteca JAX-WS, e juntamente com o uso da arquitetura JMX é disponibilizados uma interface através do browser para realizar o monitoramento e gerenciamento em tempo real.

4.1. Padrão Arquitetural Baseado na necessidade do desenvolvimento de uma aplicação capaz de se conectar aos Web Services de uma forma dinâmica, então o plugin WSMM foi projetado com um padrão arquitetural que faz a divisão de níveis de responsabilidade em forma de camada, conforme é apresentado na Figura 7 a seguir.

Figura 7. Arquitetura WSMM

Abaixo é apresentado um detalhamento da arquitetura com as principais funções de cada camada: WSMM Camada de Gerenciamento: Esta camada é responsável para prover a interface aos usuários que realizam a configuração, monitoramento e gerenciamento dos Web Services. Coleta as informações da camada inferior e apresentam de forma compreensiva. WSMM Camada de Agentes: É a camada responsável por controlar os recursos diretamente e torná-los acessíveis pelos agentes com o servidor MBean, também é responsável para realizar a mensuração dos dados coletas e expor para a camada superior. WSMM Camada de Interceptação: Nesta camada é realizado e interceptação dos envelopes SOAP de requisição e respostas através do processo de extensão da arquitetura JAX-WS. E também onde é realizado o processo de instrumentação através da arquitetura JMX. 4.1.1 Padrões de Projeto No desenvolvimento do plugin WSMM, foi necessário fazer uso de alguns padrões de projetos, entre eles o padrão Factory Method e o padrão Proxy. O padrão Proxy que conforme Gamma et al. (2000) “tem a intenção de fornecer um objeto de referência representante ou procurador de outro objeto, para poder controlar o acesso ao mesmo”. No plugin WSMM este padrão garante que o acesso as requisições e respostas aos Tubes sejam realizados através de outro objeto estendido, o CustomTube, na Figura 8 a seguir é apresentado a extensão utilizada neste processo.

Figura 8. Representação do Objeto de Referência

Outro padrão de projeto o Factory Method que conforme Freeman (2007) “define uma interface para criar um objeto, mas permite às classes decidir qual classe instanciar”. O Factory Method permite a uma classe deferir a instanciação para subclasses, no desenvolvimento do plugin com a classe TubelineAssemblerFactory e o Factory Method doCreate, foi realizado o processo de carregamento da classe personalizada CustomTubeAssembler, isso foi possível através do padrão Service Locator5 da plataforma Java, fazendo uso da classe ServiceLoader presente na API JDK versão 1.6. 4.2. Processo de Interceptação de Envelopes SOAP O framework JAX-WS (Java API for XML-Web Services) versão 2.0 faz parte do Metro Web Services Stack, projeto que visa promover interoperabilidade entre plataforma Java e WCF (Windows Communication Foundation). Foi incluído no Java SE a partir da versão 6 com Update 4 a versão atualizado para a versão JAX-WS 2.1, preservando e estendendo significativamente as capacitadas das versões anteriores, como o fornecimento ao suporte para Tube.

Conforme documentação Java, Tube6 é uma unidade base de processamento que representa em nível de protocolo SOAP o código para manipulação do envelope. Para realizar processamento das mensagens representadas como pacotes, esses pacotes são considerados apenas containers para as mensagens, que mantém as propriedades adicionais dos metadados relacionados. Os Tubes podem ser considerados como filtros que trabalham em nível de pacote e pode ser executado de forma assíncrona, o que significa que os pacotes de solicitação e resposta podem ser processados por diferentes threads.

Apesar da implementação de Tubes estar apenas disponível a partir da versão 2.1 do JAX-WS e possuir poucos trabalhos e referências sobre o assunto, porém com um estudo detalhado sobre esta API e através da proposta de Kotamraju (2007), a implementação da extensão com Tubes apresentou-se como ótima opção, pois se apresenta como suas principais vantagens a possibilidade de realizar a interceptação das requisições e respostas de forma totalmente transparente e o processamento de requisições e respostas é dissociado, isso significa que eles poderiam ser executados por diferentes threads.

Nas versões da API JAX-WS 2.1 e na versão atual 2.2, é disponibilizo a classe TubelineAssemblerFactory que é responsável por realizar a verificação de suporte para                                                                                                                          5  http://java.sun.com/blueprints/corej2eepatterns/Patterns/ServiceLocator.html  6  http://www.docjar.com/docs/api/com/sun/xml/ws/api/pipe/Tube.html  

montadores de Tubeline. Os montadores de Tubeline são representados através da classe TubelineAssembler, a Figura 9 apresenta parte da implementação desta classe.

Figura 9. Classe TubelineAssemblerFactory da API JAX-WS

Durante a execução desta classe, o primeiro objeto montador válido que for

verificado será retornada para uso na criação do Tubeline. Depois de verificar como é realizado este processo de carregamento nesta API,

este trabalho optou por criar uma extensão da classe TubelineAssemblerFactory, onde nesta classe sobrescrevemos o método abstrato doCreate, retornando um montador de Tubeline personalizado, conforme é apresentado na Figura 10.

Figura 10. Classe Estendida com método sobrescrito

Realizando o carregamento desta classe com auxílio do uso do padrão Service Locator da plataforma Java, consecutivamente podemos retornar através do método sobrescrito um montador de Tubes personalizado. A classe CustomTubeAssembler será responsável para retornar a classe CustomTube. A partir do momento do processo do carregamento da classe CustomTube que contém um objeto tube personalizado, podemos realizar a interceptação dos pacotes de requisição com o método sobrescrito processRequest, e através do método também sobrescrito processResponse realizar a interceptação dos pacotes de respostas 4.3. Implantação O plugin WSMM foi projetado para fazer parte da biblioteca da aplicação provedora de Web Services, para realizar a implantação do plugin, apenas é necessário adicionar o plugin junto à pasta das bibliotecas da aplicação, identificada geralmente por uma pasta denominada lib. Como precisamos também estender a funcionalidades dos Tubes com auxílio do padrão Service Locator da plataforma Java, será necessário a inclusão da pasta META-INF/services no classpath da aplicação. Nesta pasta contém o arquivo com o caminho da classe estendida do Tube personalizado, o qual será carregada durante o processo de inicialização da aplicação juntamente com os seus serviços.

A partir do momento da implantação do plugin, por padrão de inicialização, todos os serviços já estarão disponíveis para o monitoramento e gerenciamento. Sendo necessário apenas acessar através do browser o endereço de domínio ou do IP da aplicação provedora, e na porta pré-configurada número 1111, assim, http://domíniox:1111 ou http://NúmeroIPServidorAplicação:1111.

4.4. Funcionalidades O plugin WSMM quando implantado em projetos de Web Services baseados na API JAX-WS do protocolo SOAP, realiza através do processo de extensão a auto descoberta dos serviços e as operações disponibilizadas nestes serviços. Durante o processo de implantação é realizado o registro dos MBeans e inicializado o adaptador HTML para acesso aos serviços monitorados, através do Browser, podendo ser acessado de qualquer local. Estando disponíveis para o gerenciamento e a monitoração alguns requisitos não-funcionais dos serviços como:

• Número de requisição de cada operação: o plugin realiza a contagem de todas as solicitações de serviços agrupados pelo tipo das operações disponíveis.

• Número de falhas de cada operação: o plugin captura e apresenta a contagem das requisições que retornaram com algum tipo de falha.

• Tempo máximo e tempo mínimo de cada operação de serviço: o plugin apresenta o tempo máximo e mínimo para cada serviço acessado.

• Porcentagem de falhas de cada operação de serviços: para visualizar se os serviços disponibilizados estão sendo consumidos com um índice mínimo de falhas.

• Possibilidade de Habilita/Desabilitar o gerenciamento destes serviços em tempo de execução: esta opção disponibiliza que o processo de monitoramento e gerenciamento possa ser habilitado ou desabilitado a qualquer momento, mesmo em tempo de execução.

A seguir, na Figura 11, é apresentada a interface gerada pelo adaptador JMX, onde é realizado o acompanhamento das principais funcionalidades disponibilizadas.

Figura 11. Interface HTML-JMX para Monitorar Web Services

A Figura 11 apresenta a interface contendo uma lista atributos de Mbeans que representa alguns requisitos não-funcionais do serviço monitorado, nesta interface poderá ser observado em tempo de execução o comportamento para cada serviço provido. 5. Validação Para realizarmos uma avaliação preliminar do plugin WSMM, elaboramos dois cenários da aplicação da abordagem. No Primeiro Cenário foi feita uma análise do impacto de desempenho em relação ao fluxo normal de execução dos Web Services, no segundo cenário foi realizado um teste de compatibilidade entre alguns dos principais servidores de aplicação para Web Services. 5.1. Cenário 1 – Impacto no desempenho  Para avaliarmos o custo de processamento imposto pela interceptação e registros dos pacotes SOAP durante o processo de monitoramento, foi utilizado o paradigma GQM (Goal/Question/Metric) proposto por Basili (1992). A Tabela 1 apresenta um sumário com o plano GQM.

Tabela 1. Sumário Plano GQM Objeto de Estudo Plugin WSMM Propósito Verificar Impacto Com Relação Tempo Ponto de Vista: Consumidores de Web Services Questão Q1 Qual o tempo de processamento de Web Services em um ambiente

sem monitoração? Métrica M1 Tempo total de processamento de 5000 requisições. M2 Tempo médio de processamento de 5 amostras de 5000 requisições Questão Q2 Qual o tempo de processamento de Web Services em um ambiente

com monitoramento? Métrica

M3 Tempo total de processamento de 5000 requisições com monitoramento.

M4 Tempo médio de processamento de 5 amostras de 5000 requisições com monitoramento.

Após a definição do plano GQM, foi realizado a seleção dos procedimentos e ferramentas apropriadas para a coleta de dados, entre as ferramentas foi usado Jmeter versão 2.5.1, para aferir o tempo de resposta, rodando em um microcomputador de 3.0 GHz de 2 núcleos, 2GB de memória RAM, sistema operacional Windows versão 7, Máquina virtual Java Sun Java Runtime Environment 1.5.0_06 e o Servidor de aplicação Apache Tomcat 6.1.8.

Para execução desta análise foram realizados uma quantidade considerável de testes, seguindo os objetivos apresentados no plano GQM, tanto para o ambiente sem monitoração, quanto para o caso com monitoração com o plugin WSMM. Após foram capturados o tempo transcorrido de cada teste realizado no grupo, obtido uma média para cada grupo, após realizado a média entre os grupos para obter o resultado final em cada ambiente. Para efeito de calibragem dos dados, desconsideramos a primeira

invocação por apresentaram um tempo de resposta considerado elevado em relação às outras invocações, em ambos os casos. O processo de realização do monitoramento com a interceptação dos envelopes SOAP, como já era previsto, provocou um perda de desempenho conforme apresentado na Figura 12. A análise dos resultados demonstra que a perda de desempenho obtida com a monitoração dos Web Services apresentou um valor médio de 3,26% em relação ao cenário sem monitoração.

Figura 12 – Impacto do Desempenho

Apesar da perda não ser considerada insignificantes, os benefícios que esta abordagem traz para o gerenciamento dos Web Services, em nossa análise, podem compensar o impacto apresentado.

Outra análise sobre os resultados mostra a utilidade do plugin WSMM para aferir o tempo de processamento das solicitações de serviço somente do lado provedor. O uso de algumas ferramentas disponíveis como JMeter7 e soapUI8 realiza esta análise considerando o tempo de latência, que acontece a partir do início da requisição do serviço até o seu retorno. 5.2 Cenário 2 – Teste de Independência de ambiente Neste cenário foi verificado qual o comportamento do plugin WSMM em relação ao seu funcionamento e compatibilidade em alguns Servidores de Aplicação entre eles, Tomcat, Jboss, WebLogic e Glassfish. Para realização desta análise foi implantado provedores de Web Services em cada servidor de aplicação após foi instalado o plugin WSMM. Durante da execução foram realizadas 50.000 requisições de serviços para cada servidor de aplicação. Os resultados obtidos são apresentados na tabela abaixo.

Tabela 2. Resultados

Servidor de Aplicação % Monitoramento Observações

Apache Tomcat 6.1.8 100% -

                                                                                                                         7  http://jmeter.apache.org/  8  http://www.soapui.org/  

Servidor de Aplicação % Monitoramento Observações

Jboss Web Server 1.0.2 100% -

Weblogic 12c 0% Por motivos de segurança o contêiner não permitiu disponibilizar portas de acesso do adaptador HTML do JMX.

Glassfish 3.1.1 100% Necessário incluir linha ao arquivo metro.xml9, pois o próprio contêiner já possui a implementação JAXWS.

Como pôde ser observado na tabela acima o plugin WSMM, apresentou-se compatível com a maioria dos servidores de aplicação, podendo ser implantado independente do ambiente de execução dos Web Services, pois seu único requisito para funcionamento a própria plataforma Java. 6. Considerações Finais Este trabalho apresentou o plugin WSMM que realiza a monitoração e gerenciamento de Web Services que são implementados utilizando o protocolo SOAP padrão da W3C. Para atingir nosso objetivo de realizar este processo de forma desacoplada de ambiente de execução e de forma não intrusiva à codificação, optou-se em fazer uso da instrumentação dinâmica usando API JMX juntamente com uma proposta de extensão da API JAXWS.

Outras vantagens observadas durante o desenvolvimento do trabalho é a possibilidade de uso em Web Services já implantados uma vez que o plugin realiza a descoberta dos serviços, além do fácil processo de implantação, visto que depende somente da plataforma Java. O impacto no desempenho apresentado justifica-se em virtude dos benefícios que esta abordagem apresenta para o gerenciamento de Web Services.

6.1. Trabalhos Futuros Com o processo de Interceptação de envelopes SOAP realizado pelo plugin WSMM, o uso de um mecanismo de caching, o qual é muito utilizado para melhorar o desempenho de aplicações, parece apresentar-se como válido, para operações cuja resposta se repita quando invocada com um contexto similar ou equivalente conforme Terry et al.(2003).

Também como proposta faz-se necessário uma pesquisa no comportamento do plugin realizando o monitoramento e gerenciamento de forma totalmente paralela à execução dos serviços.

Neste trabalho foi apresentado o plugin realizando monitoramento e gerenciamento em funcionamento no provedor de serviço, também sendo necessária a realização de testes para verificar seu comportamento quando implantado em aplicações consumidoras dos Web Services, bem como um estudo de implementação do plugin para WebServices baseados em Rest.

A tecnologia JMX proporciona fazer uso de notificações, apresentando-se também como uma opção para acrescentar em futuras atualizações do plugin.

                                                                                                                         9  http://marek.potociar.net/2009/10/19/custom-­‐metro-­‐tube-­‐interceptor/  

Propor funcionalidades para localizar especificações não-funcionais dos Web Services das propostas de modelos de descrição de serviços, como Extensões UDDI, Linguagens WSOL ou GlueQoS.

Agradecimentos A Deus pela capacidade de aprender, a toda minha família onde sempre busquei força e coragem, ao meu orientador Vinicius Cardoso Garcia que não mediu esforços no apoio a este trabalho, a todos os professores, aos coordenadores Simone Santos e Felipe Furtado, a equipe do Cesar.edu e aos integrantes das fábricas de software FarmFactory e Yes.

Referências Andrieux, A.; Czajkowski, K.; Dan, A.; Keahey, K.; Ludwig, H.; Pruyne, J.; Rofrano,

J.; Tuecke, S. e Xu, M. Web Service Agreement Specification (WS-Agreement). Global Grid Forum, Maio, 2004.

Basili, V. R. Software modeling and measurement: the Goal/Question/Metric paradigm. University of Maryland CSTR2956, 1992. University of Maryland at College Park. Disponível em: http://129.2.17.93/drum/handle/1903/7538.

Barrett, R. Maglio, P., 1998, Intermediaries: New Places for Producing and Manipulating Web Content. Computer Networks and ISDN Systems, Abril 1998.

Boniati, Bruno B.; Padoin, Edson Luiz. Web services como middlewares para interoperabilidade em sistemas. Revista do CCEI ,2003.

Booth, David. Hugo Haas e Francis McCabe, Eric Newcomer, Michael Champion, Chris Ferris, e David Orchard. Web Services Architecture. W3C. Disponível em: http://www.w3.org/TR/2004/NOTE-ws-arch20040211/, Acessado em 11/2011.

Castillo, Pedro A.; Bernier, José Luis; Arenas, Maribel García; Merelo, Juan Julián; García-Sánchez, Pablo. SOAP vs REST: Comparing a master-slave GA implementation. 2011. First International Workshop of Distributed Evolutionary computation in Informal Environments.

Cerami, Ethan. Web Services Essentials. O'Reilly. 2002. Charfi, A. e Mezini, M. Aspect-oriented Web service composition with AO4BPEL. In

Proceedings of the European Conference on Web Services (ECOWS), 2004. Chen F. and Rosu G., “Towards Monitoring-Oriented Programming: A Paradigm

Combining Specification and Implementation,” Electronic Notes in Theoretical Computer Science, 2003.

Chinnici R., J. Moreau, A. Ryman, and S. Weerawarana, “Web services description language (wsdl) version 2.0 part 1: Core language – w3c recommendation 26 june 2007,” World Wide Web Consortium (W3C), Tech. Rep., 2007. Disponível em: http://www.w3.org/TR/wsdl20/

Clark, Mike, Peter Fletcher, Jeffrey J. Hanson, Romin Irani, Mark Waterhouse, e Jorgen Thelin. Web Services Business Strategies and Architectures. A-Press, 2003.

Casati, Fabio ; Discenza, Angela. Modeling and managing interactions among business processes. J. of Systems Integration, 2001.

Dayal, Umeshwar, Meichun, Hsu and Rivka, Ladin. Business process coordination: State of the art, trends, and open issues. VLDB ’01: Proceedings of the 27th Intl. Conference on Very Large Data Bases , São Francisco, 2001.

Eric, Wohlstadter, Stefan Tai, Thomas Mikalsen, Isabelle Rouvellou, e Premkumar Devanbu. GlueQoS: Middleware to sweeten quality-of-service policy interactions. IEEE Computer Society.Washington, EUA, 2004

Freeman, Eric; Freeman Elisabeth. Use a Cabeça (Head First) Padrões de Projeto. Rio de Janeiro: Alta Books, 2007.

Gamma, Erich et al. Padrões de Projeto: soluções reutilizáveis de software orientado a objetos. Porto Alegre: Bookman, 2000.

Garcia, Diego Z.G. Incorporação de Qualidade de Serviço no Modelo de Serviços Web. 2007. 207 f. Dissertação(Ciências da Computação) - Universidade Estadual de Campinas. Unicamp, São Paulo.

Gartner 2004, Whit Andres, Abrams C. Web Services Drive Market Convergence Gopalakrishnan U, Shreevidya Rao.(2005) Develop Web services with Axis2, Part 1:

Deploy and consume simple Web services using the Axis2 runtime. Disponível em: https://www.ibm.com/developerworks/webservices/library/ws-webaxis1. Acessado em: Fevereiro, 2012.

Han , Jun ;Zheng Li, Yan Jin. A Runtime Monitoring and Validation Framework for Web Service Interactions. Proceedings of the 2006 Australian Software Engineering Conference,2006.

Kaarthik Sivashanmugam, John A. Miller, Amit Sheth, e Kunal Verma. Framework for semantic Web process composition. International Journal of Electronic Commerce, 2005.

Kalin, Martin. Java web services:up and running. 1sd ed. Sebastopol, California O'Reilly Media, 2009

Keller, Alexander e Ludwig, Heiko. The WSLA framework: Specifying and monitoring service level agreements for Web services. Journal of Network and Systems Management, 2003.

Kokash, Natallia. Web service discovery with implicit QoS filtering. Em Andreas Hanemann, editor, Proceedings of the IBM PhD Student Symposium at the 3rd International Conference on Service Oriented Computing (ICSOC 2005), v.169 de IBM Technical Reports, 2005.

Kotamraju, Jitendra. (2007). Tubes in JAX-WS 2.1. Disponível em http://javakenai-dev.cognisync.net/blog/2007/02/02/tubes-jax-ws-21. Acessado em: setembro, 2011.

Mahmoud, Qusay H.(2004). Getting Started with Java Management Extensions (JMX): Developing Management and Monitoring Solutions. Disponível em http://java.sun.com/developer/technicalArticles/J2SE/jmx.html. Acessado em: janeiro, 2012.

Maximilien E. Michael e Singh M. P. A framework and ontology for dynamic Web services selection. IEEE Internet Comp., 8(5):84–93, 2004.

Menasce, Daniel A. QoS issues in Web services. IEEE Internet Computing, V6,6, 2002. Michael, E. Maximilien e M. P. Singh. A framework and ontology for dynamic Web

services selection. IEEE Internet Comp. 2004. Mitra, Nilo. SOAP Part Primer Version 1.2 Specification. W3C, 24 Junho 2003.

http://www.w3.org/TR/2003/REC-soap12-part0-20030624, acessado em 03/2012. Leymann, Frank, Dieter Roller, e Marc-Thomas Schmidt. Web services and business

process management. IBM Systems Journal, New Developments in Web Services and Electronic Commerce , 2002.

Li Z. and Jin Y., J. Han, A Runtime Monitoring and Validation Framework for Web Service Interactions, Proc. 17th Australian Software Eng. Conf., 2006.

Perry, J. Steven. Java Management Extensions. Sebastopol: O'Reilly Media, 1a. Ed. 2002

Sahai Akhil. and Graupner Sven. Web Services in the Enterprise Concepts, Standards, Solutions, and Management. Springer, 2005

Shaikh, Ali, Omer F. Rana, Rashid Al-Ali, e David W. Walker. UDDIe: An extended registry for Web services. Em Saint-W IEEE Computer Society., Washington, EUA, 2003.

Shuping, Ran. A framework for discovering Web services with desired quality of services attributes. Em ICWS ’03: Proceedings of the International Conference on Web Services, 2003.

Silva, Mario F. Uma abordagem para monitoramento de contratos eletrônicos baseada em aspectos. 2008. 105 f. Dissertação(Ciências da Computação) – Universidade Estadual de Maringá. UEM, Maringá.

Silva, Clayton Ferreira.   Uma Linguagem de Especificação de Aspectos para o Desenvolvimento Orientado a Serviços. 2006. 124 f. Dissertação(Ciências da Computação) – Universidade de Fortaleza.

Sommerville, I. Engenharia de Software. 8ª ed. São Paulo: Pearson Addison Wesley, 2007.

Sullins, Ben G.; Whipple, Mark B. JMX in Action. Greenwich: Manning, 2003. Suvée, D., Vanderperren, W., Jonckers, V., 2003, JAsCo: An Aspect-Oriented

Approach Tailored for Component Based Software Development. In Proc. of the 2nd International Conference on Aspect Oriented Software Development (AOSD’03), ACM Press, Boston, EUA.

Szyperski, C. Component Software: Beyond Object-Oriented Programming. Boston, MA, USA: Addison-Wesley Longman, 2002.

Terry, D. B., Ramasubramanian, Caching XML Web Services for Mobility. ACM Queue, 2003.

Tosic, Vladimir, Aad van Moorsel and Raymond, Wong. Quality of Service (QoS) middleware for Web services: Achieved results and challenges for the future (panel discussion). IEEE Computer Society, Washington, EUA, 2005.

Tosic, Vladimir, Kruti Patel and Bernard, Pagurek. WSOL: Web Service Offerings Language. Em Christoph Bussler, Richard Hull, Sheila A. McIlraith, Maria E. Orlowska, Barbara Pernici, e Jian Yang, editores, WES ’02: Proceedings of the CAiSE 2002 International Workshop on Web Services, Berlin, 2002.

Verheecke, B., Cibrán, M. A., 2003, AOP for Dynamic Configuration and Management of Web Services. In Proc. of the International Conference on Web Services – Europe 2003 (ICWS – Europe’03), Erfurt, Alemanha

Wang, Qianxiang; Jin Shao; Fang Deng; Yonggang Liu; Min Li; Jun Han; Hong Mei, "An Online Monitoring Approach for Web Service Requirements," IEEE Transactions on Services Computing, vol. 2, no. 4, pp. 338-351, Oct.-Dec. 2009.

Wei, Ma, Tosic, Vladimir, Esfandiari, Babak and Pagurek, Bernard. Extending Apache Axis for monitoring of Web Service Offerings. In Proceedings of the IEEE EEE05 international workshop on Business services networks, IEEE Press, 2005.

Wil M. P. van der Aalst. Process-oriented architectures for electronic commerce and interorganizational workflow. Information Systems, 1999.

Zhou Chen, Chia Liang-Tien, Bilhanan Silverajan, e Lee Bu-Sung. UX: An architecture providing QoS-aware and federated support for UDDI. Em ICWS ’03: Proceedings of the International Conference on Web Services, Press, 2003.