Utilização de Aspectos no Desenvolvimento de Aplicações baseadas em

Serviços Web

Mateus Barcellos Costa1 3 Rodolfo Ferreira Resende1

Pedro dos Santos Neto1 Mı́rian Halfeld Ferrari Alves2
1
Universidade Federal de Minas Gerais
2
Université François Rabelais Blois-Tours-Chinon/LI - Antenne de Blois
3
Faculdade de Ciências Humanas de Aracruz
email: mcosta@dcc.ufmg.br, rodolfo@dcc.ufmg.br,
pasn@dcc.ufmg.br, mirian.halfeld@univ-tours.fr

Resumo

Nesse trabalho apresentamos diretivas para o desenvolvimento de aplicações baseadas em serviços Web. O
objetivo dessas diretivas é reduzir a complexidade da incorporação de serviços no desenvolvimento de aplicações.
Em nossa abordagem, a utilização desses serviços é feita concentrando-se as invocações de suas operações em um
conjunto definido de elementos e tornando implı́citas essas invocações quando as mesmas são necessárias. Como
solução de implementação utilizamos Aspectos. A abordagem proposta está sendo utilizada no desenvolvimento de
uma aplicação para instituições de ensino superior. Utilizamos alguns elementos dessa aplicação como exemplo
ilustrativo.
Abstract

In this paper, we present directives for the development of Web service based applications. The goal of these
directives is to reduce the complexity of incorporating services in the development process. In our approach the
service invocations are done within specific modules. These invocations become implicit for other modules which
need them. We use Aspects as the implementation solution. This approach has been used in the development of an
application for academic institutions which can be used for the enrollment of students. We use some elements of
this application to illustrate our directives.

1. Introdução

Aplicações comerciais atuais freqüentemente têm que atender a requisitos relacionados ao

Comércio Eletrônico entre Empresas - Business-to-Business E-Commerce. Para tanto, desen-
volvedores dessas aplicações necessitam lidar com requisitos funcionais inovadores e com prob-
lemas relacionados à interação e integração de aplicações tais como escalabilidade, dinamismo,
autonomia, heterogeneidade e adaptação de sistemas legados [14].
Essas novas necessidades têm motivado o desenvolvimento de tecnologias e paradigmas
voltados para a área de Comércio Eletrônico entre Empresas. Dentre esses paradigmas, destaca-
se a Computação Orientada a Serviços. Um dos objetivos do uso da Computação Orientada a
Serviços é promover o desenvolvimento de aplicações distribuı́das através da composição rápida
e de baixo custo de componentes de software autônomos e independentes de plataforma [15].
Esses componentes são denominados serviços.
 Segundo a Arquitetura Orientada a Serviços [19], provedores disponibilizam serviços
hospedando suas implementações e descrições em sistemas de computação conectados a po-
tenciais clientes através de uma rede de computadores. Em uma visão externa, um serviço en-
capsula uma função de negócio [6] disponibilizada por uma organização. Clientes de serviços
podem utilizá-lo dessa forma, sem conhecer detalhes de sua implementação.
Serviços Web [20] constituem um conjunto de tecnologias para suporte à Computação Ori-
entada a Serviços. Um serviço Web fica disponı́vel em um ponto de acesso na Web endereçável
através de um URI - Uniform Resource Identifier , que especifica unicamente o serviço. Nesse
endereço, potenciais clientes podem obter a descrição do serviço em WSDL - Web Service De-
scription Language [18]. WSDL permite especificar a interface de serviços Web, seus métodos,
detalhes de transporte e do ponto de acesso ao serviço. A partir dessa descrição, pode-se con-
struir uma interface para o cliente em sua linguagem nativa, que atenda às especificações do
serviço descrito.
A maioria das ferramentas de desenvolvimento de software com suporte para serviços Web
oferecem mecanismos para automatização de tarefas como publicação de serviços, construção
da sua descrição em WSDL, geração de interfaces na linguagem nativa do cliente além de
suporte a aspectos de comunicação. Tais mecanismos facilitam a construção, manutenção e
invocação de serviços Web. Entretanto, considerando o ponto de vista de que serviços Web
são utilizados como solução para o atendimento dos requisitos de aplicações, processos de
desenvolvimento de software devem fornecer mecanismos apropriados para a representação
dessa solução e para a introdução desses serviços na elaboração da aplicação.
Requisitos de aplicações estão relacionados a conceitos do domı́nio do problema. Derivar o
desenho de aplicações a partir dos requisitos significa representar soluções para o atendimento
desses requisitos através de elementos tecnológicos. Tal processo implica em transpor o “gap”
semântico entre requisitos e tecnologias [3]. Com o conjunto de diretivas que apresentamos
pretendemos facilitar esse processo, primeiro, sugerindo o estabelecimento de um conjunto de
elementos, que representem soluções para o atendimento dos requisitos. Segundo, separando
os aspectos relacionados ao uso de interfaces de serviços em um outro conjunto de elementos.
Dessa forma, o desenho e implementação dos módulos diretamente ligados às interfaces de
serviços pode ser feita isoladamente. A implementação dos elementos relacionados às interfaces
de serviços pode ser feita através do uso de Aspectos [22].
Estamos experimentando a abordagem proposta na construção de um sistema de matrı́culas
multi-institucional para instituições de ensino superior. Nesse sistema, várias instituições de
ensino formam um consórcio para permitir que seus alunos tenham a opção de se matricularem
em disciplinas oferecidas em qualquer das instituições participantes. Utilizaremos UML como
linguagem de modelagem e notação de AspectJ [10] para ilustrar aspectos de implementação.
O restante do artigo está organizado da seguinte maneira: na Seção 2 discutimos o desen-
volvimento de aplicações utilizando o Processo Unificado e serviços Web. Na Seção 3 apresen-
tamos uma abordagem de desenvolvimento de aplicações baseado em serviços Web utilizando
Aspectos. Na Seção 4 discutimos trabalhos relacionados e na Seção 5 concluı́mos.

2. Desenvolvimento de Aplicações utilizando Serviços Web

O uso do Processo Unificado [8] implica na realização de uma série de interações incre-
mentais. Em cada uma dessas interações são realizadas atividades pertinentes ao ciclo de vida
do sistema. Cada interação consiste em um passo das atividades de especificação de requisitos,
análise, desenho, implementação e de teste.
O Processo Unificado é dirigido por casos de uso. Casos de uso são usados na especificação
de requisitos para capturar as necessidades do usuário e os passos seguintes são destinados
ao atendimento dessas necessidades através da realização dos casos de uso. Por exemplo, na
especificação de requisitos do sistema de matrı́culas multi-institucional, definimos Matrı́cula
Externa como um caso de uso. Esse caso de uso fornece a especificação das funcionalidades
necessárias para que alunos de uma instituição possam ser matriculados em todas as instituições
consorciadas. A Figura 1 apresenta uma possı́vel especificação para esse caso de uso1 . Após a
identificação e especificação de casos de uso, na atividade de análise define-se um conjunto de
classes e outros elementos, relacionamentos e colaborações, necessários para a sua realização.
Os casos de uso, aspectos tecnológicos, requisitos não funcionais, sistemas legados e
interações com outros sistemas influenciam na definição da arquitetura da aplicação [7]. No
Processo Unificado, a arquitetura da aplicação tem a função de apresentar uma visão do sistema
como um todo. As diretivas de desenvolvimento que propomos especificam parcialmente uma
arquitetura para aplicações baseadas em serviços Web. Entretanto, embora estejamos discutindo
nossa abordagem no contexto do Processo Unificado, esta pode se aplicada considerando difer-
entes estilos de especificação arquitetural [11, 16, 21].
No desenho da aplicação, são levados em conta aspectos da plataforma de desenvolvimento
como por exemplo bibliotecas de interface de usuário e sistemas de gerenciamento de banco de
dados. A reutilização de módulos de sistemas legados e de frameworks também é considerada
no modelo de desenho. Para a construção do modelo de desenho são também especificados um
conjunto de classes e outros elementos, relacionamentos e colaborações. Enquanto no mod-
elo de análise os elementos definidos são conceituais, representando elementos do domı́nio da
aplicação, o modelo de desenho oferece um esboço do modelo de implementação, através de
elementos lógicos. Na Implementação são definidos todos os elementos necessários para a
obtenção do código executável da aplicação.
O uso de um serviço Web como solução para atendimento de requisitos de aplicações im-
plica na definição e descrição de sua interface na atividade de desenho. Para ilustrar a definição
dessas interfaces, utilizamos a realização do caso de uso Matrı́cula Externa do sistema de
matrı́culas. A Figura 2.a apresenta instâncias de classes de análise e suas colaborações para
a realização do caso de uso Matrı́cula Externa.

1. O Usuário identifica um aluno;

2. O Sistema apresenta um conjunto de disciplinas externas para o aluno selecionado;
3. O Usuário seleciona as disciplinas desejadas;
4. O Sistema realiza a matrı́cula do aluno nas disciplinas selecionadas;
Figura 1: Especificação do caso de uso de Matrı́cula Externa

O modelo de análise no Processo Unificado estabelece uma categorização para classes se-
gundo os estereótipos entidade, controle e fronteira [8]. O estereótipo entidade categoriza
classes do domı́nio da aplicação que são persistentes na maioria dos casos. O estereótipo cont-
role é usado para categorizar classes que modelam o comportamento do sistema. O estereótipo
fronteira categoriza classes utilizadas para modelar as interações entre o sistema, seus usuários
e outros sistemas. Na Figura 2.a os objetos são representados conforme esses estereótipos.
1
Essa forma de especificação de casos de uso é apenas uma das possı́veis que encontra-se na literatura [5].
Utilizamos um exemplo de cada estereótipo para discutir aspectos de desenho relativos ao uso
interfaces de serviços. A Figura 2.b apresenta as classes de análise InterfaceMatrı́culaExterna
(fronteira), DisciplinaExterna (entidade) e FazMatrı́cula (controle), e as interfaces de serviço
necessárias para o seu desenho.

: FazMatrícula

12: Solicita Matrícula Externa

11: Seleciona Disciplinas 13: Matrícula Realizada

1: Identifica Aluno 6: Solicita Disciplinas Externas para o Aluno

10: Informa Disciplinas Externas 9: Retorna Disciplinas Externas

: Usuário : InterfaceMatrículaExterna : BuscaDisciplinas
InterfaceMatrículaExterna DisciplinaExterna FazMatrícula
14: Confirma Matrícula 7: Recupera Disciplinas Externas
(from Analysis Model) (from Analysis Model) (from Analysis Model)
2: Solicita dados aluno

5: Retorna dados Aluno 8: Retorna Disciplinas Externas

<<trace>> <<trace>> <<trace>>
4: Retorna dados Aluno

: DisciplinaExterna
3: Recupera Dados Aluno IS Verifica IS Obtém IS Faz
: Aluno : BuscaAluno Disponibilidade Disciplinas Matrícula

(a) Diagrama de Colaboração (b) Interfaces de Serviço para desenho das

classes de Análise

Figura 2: Colaborações e Interfaces de Serviço para o Caso de Uso Matrı́cula Externa

A função da interface Verifica Disponibilidade é informar se um serviço está on-line. A

classe de fronteira InterfaceMatrı́culaExterna utiliza esse serviço para fornecer ao usuário essa
informação e definir o conjunto de instituições nas quais poderão ser realizadas matrı́culas numa
dada operação. A classe de entidade DisciplinaExterna é uma abstração. A informação dessa
classe é obtida quando um aluno é identificado. São obtidas de cada instituição participante
as disciplinas externas que o mesmo pode cursar. Para tanto, a interface de serviço Obtém
Disciplinas de cada instituição é utilizada. A realização da matrı́cula nas disciplinas externas é
feita no sistema de informações da instituição do aluno e na instituição que oferece a disciplina.
A matrı́cula na instituição que oferece a disciplina externa é feita através da interface de serviço
Faz Matrı́cula.
Cada instituição participante, fornece uma tripla de interfaces Verifica Disponibilidade,
Obtém Disciplinas e Faz Matrı́cula. A realização do caso de uso Matrı́cula Externa neces-
sita invocar serviços de todas as instituições consorciadas. Por exemplo, para a classe Inter-
faceMatrı́culaExterna apresentar a informação sobre quais instituições estão on-line, a mesma
deve invocar métodos da interface Verifica Disponibilidade de cada uma das instituições do
consórcio. Para obter as disciplinas externas, a classe Disciplina Externa deve invocar métodos
de todas as interfaces Obtém disciplinas. A implementação da classe Faz Matrı́cula deve uti-
lizar a interface com as instituições que fornecem as disciplinas externas selecionadas para a
realização de matrı́culas externas.
Utilizando esse desenho, a invocação das operações dos serviço Web se dá em diversos
módulos da aplicação. Na Seção 3 discutimos uma alternativa para o uso das interfaces de
serviços concentrando esse uso em módulos especı́ficos da aplicação.
3. Modelo de Desenho para o uso das Interfaces de Serviços

Para a realização do caso de uso Matrı́cula Externa, cada instituição participante provê
um conjunto de serviços para os demais participantes. Considerando a sugestão de desenho
apresentada na Seção 2, para a realização do caso de uso Matrı́cula Externa, todas as inter-
faces de serviços providos pelas instituições consorciadas participam, na aplicação cliente, da
especificação das classes InterfaceMatrı́culaExterna, DisciplinaExterna e FazMatrı́cula. Nesta
seção apresentamos uma segunda abordagem para a utilização das interfaces de serviços. Uti-
lizaremos as mesmas classes de análise da seção anterior.

3.1. Solução de Desenho para Invocações de Serviços utilizando Aspectos

Disponibilidade

InterfaceMatrículaExterna DisciplinaExterna FazMatrícula

(from Analysis Model) (from Analysis Model)
Disciplinas
(from Analysis Model)

<<trace>> <<trace>> <<trace>>

Matrícula

Monitor DisciplinaExterna MatriculaExterna

ParticipantesDisponíveis() ObtemDisciplinas() FazMatrículaExterna()

(a) Alternativa de Desenho para O caso de Uso Matrı́cula Externa (b) Elementos
para a invocação
dos serviços

Figura 3: Modelo de Desenho para o uso de Interfaces de Serviços

A Figura 3.a apresenta uma alternativa de desenho para o caso de uso Matrı́cula Externa.
Nessa solução, o desenho das classes de análise requer a implementação das classes Monitor,
DisciplinaExterna e Matrı́culaExterna. Em nosso exemplo, para apresentar informação sobre
as instituições on-line, a interface de usuário deve invocar apenas a operação VerificaDisponi-
bilidade() da classe Monitor. Para obter as disciplinas externas disponı́veis para o aluno sele-
cionado, a classe de desenho DisciplinaExterna deve invocar a operação ObtémDisciplinas().
Por fim, para realizar a Matrı́cula Externa, a classe de controle FazMatrı́cula utiliza a operação
FazMatrı́culaExterna() da classe Matrı́culaExterna.
A solução de desenho proposta requer que a invocação dos serviços utilizados seja feita im-
plicitamente quando necessárias. Na especificação arquitetural dessa solução, essas invocações
são concentradas em um conjunto especı́fico de elementos. A Figura 3.b apresenta os elementos
responsáveis pela invocação dos serviços.
A especificação arquitetural proposta é aderente a idéia de separação de interesses do De-
senvolvimento Orientado a Aspectos. Programação Orientada a Aspectos - POA [9, 10, 22],
baseia-se na idéia de que sistemas são melhor programados especificando-se separadamente
os vários interesses e descrições de seus relacionamentos e, posteriormente, deixando-se para
 aspect Disponibilidade {
pointcut EstaDisponı́vel(): aspect Disciplinas {
call(Monitor.ParticipantesDisponı́veis()) pointcut Externas():
before(): EstaDisponı́vel() { call(DisciplinaExterna.ObtémDisciplinas())
Monitor.Disp(ISVerificaDisponibilidade_1()); before(): Externas() {
Monitor.Disp(ISVerificaDisponibilidade_2()); DisciplinaExterna.Atualiza(ISObtémDisciplinas_1());
DisciplinaExterna.Atualiza(ISObtémDisciplinas_2());
.. ..
Monitor.Disp(ISVerificaDisponibilidade_n()); DisciplinaExterna.Atualiza(ISObtémDisciplinas_n());
} }
} }

(a) Disponibilidade (b) Disciplinas Externas

aspect Matrı́cula {
pointcut FazMatrı́cula():
call(Matrı́culaExterna.FazMatrı́culaExterna())
After(): FazMatrı́cula() {
ISFazMatrı́cula_1();
ISFazMatrı́cula_2();
..
ISFazMatrı́cula_n();
}
}

(c) Matrı́cula

Figura 4: Aspectos para suporte ao caso de Uso Matrı́cula Externa

mecanismos existentes em ambientes POA a composição dos mesmos para a obtenção de um

programa coerente. Interesses podem ser relativos a noções em qualquer nı́vel de abstração e
podem ser funcionais ou não. Em nossa abordagem consideramos a invocação de interfaces de
serviços como um interesse.
Na Figura 4 apresentamos um conjunto de aspectos como solução de implementação dos
elementos que utilizam diretamente as interfaces de serviço. Os Aspectos estão descritos uti-
lizando a notação da linguagem AspectJ. Um aspecto em AspectJ possui um conjunto de point-
cuts que define um ponto de execução do código. Os aspectos podem introduzir ações rel-
ativas a execução de um pointcut. No nosso exemplo o pointcut EstaDisponı́vel() refere-se
a execução do método Monitor.ParticipantesDisponı́veis(). A declaração before() seguida do
pointcut EstáDisponı́vel() implica que o conjunto de comandos entre as chaves será executado
antes da execução do pointcut.
Conforme discutido na Seção 2, nossa contribuição especifica parcialmente uma arquitetura
para aplicações baseadas em serviços Web. Essa especificação consiste na definição do conjunto
de elementos responsáveis pela invocações de operações dos serviços que a aplicação utiliza.
A solução adotada não implica na adoção de nenhum middleware, componente ou framework,
embora a construção de frameworks ou mecanismos especı́ficos para um domı́nio de aplicação
possa aumentar a reusabilidade no desenvolvimento. A maioria das ferramentas de suporte
a serviços Web fornecem mecanismos para que, no desenvolvimento de aplicações cliente, a
interface com serviços Web seja gerada automaticamente de acordo com a linguagem nativa do
cliente. Nossa solução visa organizar o uso dessas interfaces e facilitar o desenvolvimento e a
manutenção das aplicações que as utilizam dentro de um processo de software.
4. Trabalhos Relacionados

A maior parte dos esforços relacionados à Computação Orientada a Serviços se concen-

tra nos aspectos de criação e composição[4, 24], localização, orquestração (definição de fluxos
de execução) e serviços Web semânticos [13, 17] para os mesmos. Soluções para o desen-
volvimento de aplicações utilizando serviços têm considerado a sua representação como um
componente [23] e a organização dos mesmos em uma biblioteca de componentes. Esta abor-
dagem pode facilitar o desenvolvimento de aplicações, entretanto, seu maior enfoque está em
facilitar a composição de serviços. O uso de Aspectos aplicados a serviços Web é uma idéia
recente, embora a sua aplicação em estratégias de comunicação de bibliotecas digitais tenha
sido referida anteriormente[9]. A sua aplicação associada a serviços Web é referenciada por
Arjansani [1]. Cibrán e outros [2, 12] propõem uma camada de gerenciamento de serviços Web
(WSML) para realizar a integração e seleção dinâmica de serviços Web e utilizam Aspectos
como opção de implementação.

5. Conclusão

Neste trabalho, discutimos como o desenvolvimento de aplicações baseadas em serviços

Web pode ser facilitado por um conjunto de diretivas de desenho e implementação que facilite
a introdução desses serviços na elaboração da aplicação.
Grandes quantidades de interfaces, diferenças entre as mesmas e a dinâmica de suas
atualizações podem tornar complexo o desenvolvimento e manutenção de aplicações que uti-
lizem serviços Web. Na abordagem proposta, interfaces de serviços são utilizadas em módulos
especı́ficos da aplicação, tornando mais fácil a sua construção e manutenção. Tal solução es-
pecifica parcialmente uma arquitetura para essas aplicações que é aderente ao uso de Aspectos.
Através do uso de Aspectos, foi possı́vel estabelecer transparência no uso das interfaces de
serviços Web, para os módulos da aplicação que necessitam interagir com os mesmos.
Por fim, gostarı́amos de agradecer ao LECOM-DCC/UFMG e ao Synergia-DCC/UFMG
pelo apoio às atividades desse projeto.

Referências

[1] Ali Arsanjani, Joanne Martin, Peri Tarr, and Brent Hailpern. Web services: Promises and
Compromises. Queue, 1(1):48–58, 2003.
[2] M. A. Cibrán B. Verheecke and V. Jonckers. AOP for Dynamic Configuration and Man-
agement of Web Services. In Proceedings of the 3rd International Conference on Web
Services, (ICWS-Europe’03), September 2003.
[3] Lucia R. D. Bastos and Jaelson Castro. Integration between Organizational Requirements
and architecture. In Proceedings of WER’03, 2003.
[4] Boualem Benatallah, Marlon Dumas, Liangzhao Zeng, and A. Ngu. Declarative Com-
position and Peer-to-Peer Provisioning of Dynamic Web Services. In Proceedings of the
18th International Conference on Data Engineering (ICDE’02), pages 297–308. IEEE
Computer Society, 2002.
[5] Alistair Cockburn. Writing Effective Use Cases. Addison Wesley, 2001.
 [6] Francisco Curbera, Rania Khalaf, Nirmal Mukhi, Stefan Tai, and Sanjiva Weerawarana.
Service-Oriented Computing: The Next Step in Web Services. Communications of the
ACM, 46(10):29–34, October 2003.
[7] Ivar Jacobson, Grady Booch, and James Rumbaugh. The Unified Software Development
Process. Addison Wesley, 1998.
[8] Ivar Jacobson, M. Christerson, P. Jonsson, and G. Övergaard. Object-Oriented Software
Engineering: A Use Case Driven Approach. Addison-Wesley, 1992.
[9] G. Kiczales, J. Lamping, A. Menhdhekar, C. Maeda, C. Lopes, J-M. Loingtier, and J. Ir-
win. Aspect-Oriented Programming. In Proceedings of the European Conference on
Object-Oriented Programming, volume 1241, pages 220–242. Springer-Verlag, Berlin,
Heidelberg and New York, 1997.
[10] Gregor Kiczales, Erik Hilsdale, Jim Hugunin, Mik Kersten, Jeffrey Palm, and William
Griswold. Getting Started with ASPECTJ. Communications of the ACM, 44(10):59–65,
2001.
[11] Philippe B. Kruchten. The 4+1 View Model of Architecture. IEEE Software, November,
1995.
[12] B. Verheecke M. A. Cibrán and V. Jonckers. Modularizing Client-Side Web Service
Management Aspects. In Proceedings of the 2nd Nordic Conference on Web Services
(NCWS’03), 2003.
[13] S. McIlraith, T. C. Son T. C., and H. Zeng. Semantic Web Services. IEEE Inteligent
Systems, 16(2):46–53, March./Apr. 2001. Special Issue on the Semantic Web.
[14] B. Medjahed et al. Business-to-Business Interactions: Issues and Enabling Technologies.
The VLDB Journal, 12(1):59–85, 2003.
[15] M. P. Papazoglou and D. Georgakopoulos. Service-Oriented Computing: Introduction.
Communications of the ACM, 46(10):24–28, October 2003.
[16] Mary Shaw and David Garlan. Software Architecture: Perspectives on an Emerging Dis-
cipline. Prentice Hall Publishing, 1996.
[17] D. Trastour, C. Bartolini, and C. Preist. Semantic Web Support for the E-Commerce
B2B Life Cycle. In Proceedings of the 11th International World Wide Web Conference
(WWW’02). ACM, May 2002.
[18] W3C. Web Services Description Language - W3C Note, Mar. 2001. [Online] Available:
http://www.w3.org/TR/2001/NOTE-wsdl-20010315.
[19] W3C. Web Services Architecture: W3C working draft, Nov. 2002. [Online] Available:
http://www.w3.org/TR/2002/WD-ws-arch-20021114/.
[20] W3C. Web services glossary: W3C Working Draft 14, May 2003. [Online] Available:
http://www.w3.org/TR/2003/WD-ws-gloss-20030514/.
[21] Kim Waldén and Jean-Marc Nerson. Seamless object-oriented software architecture.
Prentice Hall Publishing, 1995.
[22] Robert J. Walker, Elisa L. A. Baniassad, and Gail C. Murphy. An Initial Assessment of
Aspect-Oriented Programming. In Proceedings of the 21st International Conference on
Software Engineering (ICSE’99), pages 120–130. IEEE Computer Society Press, 1999.
[23] J. Yang and Mike P. Papazoglou. Web Component: A Substrate for Web Service Reuse
and Composition. In Proceedings of the 14th International Conference on Advanced In-
formation Systems Engineering (CAISE’02).
[24] Liangzhao Zeng, Boualem Benatallah, and Marlon Dumas. Quality Driven Web Ser-
vices Composition. In Proceedings of the 12th International World Wide Web Conference
(WWW’03). ACM, May 2003.