WSARCH: Uma arquitetura para a provisão de web services ... fileWSARCH: Uma arquitetura para a...

WSARCH: Uma arquitetura para a provisode web services com qualidade de servio

Jlio Cezar Estrella

SERVIO DE PS-GRADUAO DO ICMC-USP

Data de Depsito: 05 de abril de 2010

Assinatura:

WSARCH: Uma arquitetura para a proviso de web services comqualidade de servio

Jlio Cezar Estrella

Orientadora: Profa. Dra. Regina Helena Carlucci Santana

Tese apresentada ao Instituto de Cincias Matemticas e deComputao - ICMC-USP, como parte dos requisitos paraobteno do ttulo de Doutor em Cincias - Cincias deComputao e Matemtica Computacional.

USP - So CarlosAbril/2010

Agradecimentos

AGradeo primeiramente ao senhor Deus Pai por eu existir. Ao sen-hor Osvaldo e senhora Maria Odete, meus queridos pais que sem-pre me motivaram e incentivou a ser um homem crtico, lutador ea no desistir em hiptese alguma diante das dificuldades. s minhas ir-ms Ana e Heloisa, que tambm sempre me apoiaram e torceram por mimmesmo estando distantes. minha namorada Fernanda (Fer) que me apoiouimensamente desde o incio do doutorado. No poderia deixar de destacar oquanto a presena da Fer foi importante durante os quatro anos de trabalho. professora Regina, minha orientadora, por ter me orientado durante esteperodo e pelas discusses que tivemos para melhorar o desenvolvimentodo trabalho. Sua pacincia e a capacidade de direcionamento do projetoem momentos oportunos foram de fundamental importncia para que estetrabalho chegasse a este estgio. Ao professor Marcos que me concedeuoportunidades de participar de outras atividades extracurriculares, as quaisme proporcionaram diversos outros aprendizados. Tambm agradeo pro-fessora Sarita que me ajudou na escrita e correes de artigos e tambm professora Kalinka pelas sugestes para melhorar o trabalho. No poderiadeixar de mencionar o apoio do professor Mnaco, em que tivemos a opor-tunidade de desenvolver alguns trabalhos em conjunto. Agradeo tambmaos meus amigos e colegas de laboratrio Jonathan, Thiago, Maycon, PedroNobile, Paulo Eustquio, Bruno Guazzelli, Douglas pelo convvio do dia-a-dia, pelo apoio moral e pela ajuda durante o perodo de desenvolvimentodo doutorado. Em especial ao Bruno, Thiago e Kenji que no mediramesforos em me ajudar com a implementao do prottipo da arquiteturadesde que esta foi concebida, permitindo que as inmeras discusses tcni-cas e filosficas enriquecessem a proposta deste trabalho. Devo mencionar aajuda do Kenji em algumas fases da implementao e na melhoria do cdigoda arquitetura, bem como sua participao no planejamento e execuo dosexperimentos de validao do prottipo da WSARCH. Tambm no poderiadeixar de agradecer ao Lus Nakamura, Ricardo e ao Maycon pelas correesque fizeram no texto desta tese. Agradeo tambm FAPESP (Fundao deAmparo Pesquisa do Estado de So Paulo) pelo apoio financeiro conce-dido, o qual possibilitou minha dedicao integral a esse projeto com umabolsa de estudo durante o perodo do doutorado, alm de reserva tcnicapara a compra de recursos computacionais e o custeio para a participao

i

em eventos nacionais e internacionais relacionados ao tema de pesquisa dodoutorado.

ii

Resumo

ESta tese tem como objetivo o projeto e implementao de uma arquite-tura orientada a servios, denominada WSARCH - Web ServicesArchitecture, que possibilita acesso a Web Services com Qualidadede Servio (QoS). Os atributos de QoS que devem ser considerados, visando avaliao de desempenho de Web services e a obteno de QoS em uma ar-quitetura orientada a servios, so identificados e discutidos. Esses atributosde QoS so mapeados para os componentes participantes de uma arquite-tura orientada a servios que incorpora qualidade de servio. A arquiteturaproposta prev a monitorao dos provedores de servios e um mdulo queutiliza os dados obtidos para a localizao do servio apropriado. Visandoa validao da arquitetura proposta e dos atributos definidos desenvolveu-seum prottipo da WSARCH. O prottipo desenvolvido permite que estudosde avaliao de desempenho sejam realizados considerando os diferentescomponentes da arquitetura, algoritmos, protocolos e padres. A propostada WSARCH se insere em um contexto em que importante definir comodeve ser projetada uma arquitetura SOA com foco em desempenho, uma vezque a correta caracterizao do que avaliar, e como avaliar, se faz necessrio.Nesta tese, a avaliao de desempenho est focada nas diferentes entidadesque participam de uma arquitetura orientada a servio: cliente, provedor eos demais participantes.

iii

Abstract

THis thesis aims at the design and implementation of a service-orientedarchitecture, named WSARCH - Web Services Architecture, whichallows accessing Web Services with Quality of Service (QoS). Theattributes of QoS that shall be considered, aiming at evaluating the perfor-mance of Web Services in order to achieve QoS in a service-oriented archi-tecture are identified and discussed. These QoS attributes were mapped tothe components participating in a service-oriented architecture that incorpo-rates quality of service. The proposed architecture provides the monitoringof service providers and a module that uses the data to locate the appropriateservice. Aiming at the validation of the proposed architecture and the set ofattributes proposed, a prototype of WSARCH was developed. The prototypeallows performance evaluation studies being conducted considering the dif-ferent components of the architecture, algorithms, protocols and standards.The proposal of WSARCH is inserted in a context where is important todefine how a SOA architecture focusing on performance shall be designed,since the correct characterization of what to evaluate, and how to evaluateis necessary. In this thesis, the evaluation of performance is focused onthe different entities participating in a service-oriented architecture: client,provider and other participants.

v

Sumrio

Agradecimentos i

Resumo iii

Abstract v

Lista de Figuras xii

Lista de Tabelas xiii

Lista de Siglas xv

1 Introduo 11.1 Consideraes Iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Contextualizao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Motivao e Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.4 Estrutura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 SOA e Qualidade de Servios 52.1 Consideraes Iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Computao Distribuda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.3 SOA e Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3.1 Camada Fsica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.3.2 Camada de Descrio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.3.3 Camada de Descoberta . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.4 Qualidade de Servio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.4.1 Servios Diferenciados em nvel de aplicao . . . . . . . . . . . . . . . . 142.4.2 Service Level Agreements (SLA) . . . . . . . . . . . . . . . . . . . . . . 15

2.5 Consideraes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3 Desempenho em SOA e QoS em Web Services 193.1 Consideraes Iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.2 Trabalhos Relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.2.1 Composio de Web Services . . . . . . . . . . . . . . . . . . . . . . . . 203.2.2 Qualidade de Servio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.3 Limitaes do Paradigma de Arquiteturas Orientadas a Servio . . . . . . . . . . . 29

vii

3.3.1 Protocolos e Limitaes de Hardware - Dispositivos Mveis . . . . . . . . 303.3.2 XML como Formato de Mensagem, XML Parser e Mensagens SOAP . . . 313.3.3 Evoluo de Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . 343.3.4 Composio de Web Services . . . . . . . . . . . . . . . . . . . . . . . . 353.3.5 Segurana em Web Services . . . . . . . . . . . . . . . . . . . . . . . . . 363.3.6 Web Services Attachments . . . . . . . . . . . . . . . . . . . . . . . . . . 383.3.7 Registro UDDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.4 ndices de Carga e de Desempenho . . . . . . . . . . . . . . . . . . . . . . . . . . 423.4.1 ndices de Carga . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433.4.2 ndices de Desempenho . . . . . . . . . . . . . . . . . . . . . . . . . . . 44


4 A Arquitetura WSARCH 494.1 Consideraes Iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.2 A Arquitetura WSARCH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.3 Funcionamento e Sub-Mdulos da WSARCH . . . . . . . . . . . . . . . . . . . . 514.4 Relao de Atributos de QoS com a WSARCH . . . . . . . . . . . . . . . . . . . 56

4.4.1 QoS e Mdulos da WSARCH . . . . . . . . . . . . . . . . . . . . . . . . 564.4.2 Fatores relacionados interao entre os mdulos da WSARCH . . . . . . 60

4.5 Implementao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 624.5.1 Monitorao dos Provedores de Servios . . . . . . . . . . . . . . . . . . 634.5.2 Comunicao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 654.5.3 Broker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 654.5.4 Registro UDDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 684.5.5 Implementao dos Provedores de Servios . . . . . . . . . . . . . . . . . 694.5.6 Categorias das Aplicaes . . . . . . . . . . . . . . . . . . . . . . . . . . 694.5.7 LogServer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724.5.8 Controle de Erros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

4.6 Composio de Servios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 734.7 Consideraes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

5 Validao da Arquitetura WSARCH 775.1 Consideraes Iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 775.2 Avaliao de Desempenho da WSARCH . . . . . . . . . . . . . . . . . . . . . . . 78

5.2.1 Configurao do Ambiente . . . . . . . . . . . . . . . . . . . . . . . . . . 785.2.2 Planejamento dos Experimentos . . . . . . . . . . . . . . . . . . . . . . . 79

5.3 Anlise dos Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 825.3.1 Anlise Comportamental . . . . . . . . . . . . . . . . . . . . . . . . . . . 825.3.2 Sobrecarga no Broker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 845.3.3 Sobrecarga devido ao LogServer . . . . . . . . . . . . . . . . . . . . . . . 855.3.4 Influncia da Carga de Trabalho . . . . . . . . . . . . . . . . . . . . . . . 875.3.5 Tempo de Processamento nos Provedores . . . . . . . . . . . . . . . . . . 895.3.6 Algoritmo de Escalonamento de Mensagens . . . . . . . . . . . . . . . . . 90


viii

6 Concluses 1016.1 Consideraes iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1016.2 Concluses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1026.3 Dificuldades relacionadas ao Projeto . . . . . . . . . . . . . . . . . . . . . . . . . 1026.4 Contribuies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1036.5 Produo Cientfica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

6.5.1 Relatrios Tcnicos e Notas Didticas . . . . . . . . . . . . . . . . . . . . 1056.5.2 Artigos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1056.5.3 Livros e Captulos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1066.5.4 Colaborao em projetos de pesquisa . . . . . . . . . . . . . . . . . . . . 1066.5.5 Participao em projetos de pesquisa relacionados ao doutorado . . . . . . 107

6.6 Participao em Conferncias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1076.7 Trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

ix

Lista de Figuras

2.1 Arquitetura Orientada a Servio . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2 Pilha conceitual dos Web Services (Brooks, 2002) . . . . . . . . . . . . . . . . . . 8

3.1 Lacuna existente na literatura quando levado em considerao os nveis arquitetu-rais e organizacionais (Branco, 2004) . . . . . . . . . . . . . . . . . . . . . . . . . 45

3.2 Viso macroscpica do projeto de um ndice de desempenho (Branco, 2004) . . . . 453.3 Estratgia para obteno do ndice de desempenho (Branco, 2004) . . . . . . . . . 463.4 Exemplo de utilizao do ndice de desempenho (Branco, 2004) . . . . . . . . . . 47

4.1 WSARCH - Modelo Abstrato . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514.2 WSARCH - Modelo Simplificado . . . . . . . . . . . . . . . . . . . . . . . . . . 524.3 WSARCH - Modelo Atual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534.4 Funcionamento do Ganglia na WSARCH . . . . . . . . . . . . . . . . . . . . . . 644.5 Broker e Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 664.6 WSARCH - Informaes de QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . 674.7 Classificao das Aplicaes (Branco, 2004) . . . . . . . . . . . . . . . . . . . . . 704.8 Fluxo de composio de uma reserva de viagens . . . . . . . . . . . . . . . . . . . 74

5.1 Distribuio das requisies - Cliente (Bronze) X Provedor . . . . . . . . . . . . . 835.2 Distribuio das requisies - Cliente (Gold) X Provedor . . . . . . . . . . . . . . 835.3 Comportamento tpico do Broker da WSARCH . . . . . . . . . . . . . . . . . . . 845.4 Arquitetura WSARCH com LogServer ativado/desativada . . . . . . . . . . . . . . 865.5 Comportamento da WSARCH quanto ao tempo de processamento nos provedores . 875.6 Sobrecarga da arquitetura mediante variao do tempo entre requisies . . . . . . 875.7 Tempo mdio de resposta para os experimentos Exp004 e Exp005 . . . . . . . . . 885.8 Sobrecarga da arquitetura com variao do tempo de processamento nos prove-

dores de servios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 895.9 Tempo mdio de resposta da arquitetura para diferentes clientes . . . . . . . . . . 905.10 Algoritmo de Classificao - 50% Bronze . . . . . . . . . . . . . . . . . . . . . . 915.11 Algoritmo de Classificao - 50% Gold . . . . . . . . . . . . . . . . . . . . . . . 925.12 Tempo mdio de resposta para clientes Gold e Bronze . . . . . . . . . . . . . . . . 925.13 Clientes da classe Gold e Bronze x Tempo mdio de SOA . . . . . . . . . . . . . . 935.14 Sobrecarga da arquitetura para Clientes Gold e Bronze . . . . . . . . . . . . . . . 935.15 Tempo de processamento mdio: Clientes Gold x Clientes Bronze . . . . . . . . . 945.16 Algoritmo de Reserva de Recursos com 3 provedores para a classe Bronze . . . . . 955.17 Algoritmo de Reserva de Recursos com 4 provedores para a classe Gold . . . . . . 95

xi

5.18 No ocorrncia da diferenciao de servios em relao ao tempo mdio de resposta 965.19 No ocorrncia da diferenciao em relao ao elementos de SOA . . . . . . . . . 965.20 Diferenciao de servios considerando a sobrecarga da WSARCH . . . . . . . . . 975.21 No ocorrncia da diferenciao de servios para o tempo mdio de processamento 975.22 Algoritmo de Reserva de Recursos com 2 provedores para a classe Bronze . . . . . 985.23 Algoritmo de Reserva de Recursos com 5 provedores para a classe Gold . . . . . . 985.24 Diferenciao de servios para diferentes clientes . . . . . . . . . . . . . . . . . . 995.25 Diferenciao de servios considerando os elementos de SOA . . . . . . . . . . . 995.26 Diferenciao de servios considerando a sobrecarga da WSARCH . . . . . . . . . 995.27 Diferenciao de servios para o tempo mdio de processamento . . . . . . . . . . 100

xii

Lista de Tabelas

3.1 Ataques e impactos da segurana no desempenho de Web Services Adaptado de(Jensen et al., 2007) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.1 Relao dos atributos de QoS com os mdulos da WSARCH . . . . . . . . . . . . 584.2 Informaes de QoS armazenadas no registro UDDI . . . . . . . . . . . . . . . . . 68

5.1 Elementos de Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 785.2 Elementos de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 795.3 Fatores e nveis realativos aos experimentos . . . . . . . . . . . . . . . . . . . . . 815.4 Experimentos realizados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 815.5 Mdia e Desvio Padro do comportamento do Broker . . . . . . . . . . . . . . . . 855.6 Mdia e Desvio Padro do comportamento da WSARCH em relao ao LogServer 865.7 Mdia e Desvio Padro do comportamento da WSARCH para variao do tempo

entre requisies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 885.8 Mdia e Desvio Padro do comportamento da WSARCH para variao do tempo

entre requisies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

xiii

Lista de Siglas

ASCII - American Standard Code for Information Interchange

ATM - Asynchronous Transfer Mode

B2B - Business-to-Business

B2C - Business-to-Consumer

BPEL, BPEL4WS - Business Process Execution Language for Web Services

BPM - Business Process Management

CERN - Centro Europeu para Pesquisa Nuclear

CISC - Complex Instruction-Set Computer

CORBA - Common Objetct Request Broker Architecture

CPU - Central Processing Unit

DCOM - Distributed Component Object Model

DNS - Domain Name System

DOM - Document Object Model

DoS - Denial of Service

DTD - Data Type Definition

DIME - Direct Internet Message Encapsulation

EAI - Enterprise Application Integration

ESB - Enterprise Service Bus

FLOPS - Floating Point Operations per Second

FTP - File Transfer Protocol

xv

HP - Hewlett-Packard

HTTP - HyperText Transfer Protocol

HTML - HyperText Markup Language

IBM - International Business Machine

IDL - Interface Description Language

IP - Internet Protocol

IEEE - Institute of Electrical and Electronics Engineers

JSIM - A Java-Based Simulation and Animation Environment

MEDIDAh - Modelo De ndice de Desempenho em Ambientes heterogneos

MEP - Message Exchange Patterns

MIME - Multipurpose Internet Mail Extensions

MIPS - Millions of Instructions per Second

MIT - Massachusetts Institute of Technology

MTOM - Message Transmission Optimization Mechanism

OASIS - Organization for the Advancement of Structured Information Standards

OGSA - Open Grid Services Architecture (OGSA)

OMG - Object Management Group

OWL - Web Ontology Language

POP3 - Post Office Protocol

QoS - Quality of Service

RFC - Request for Comments

RDF - Resource Description Framework

RISC - Reduced Instruction-Set Computer

RMI - Remote Method Invocation

RPC - Remote Procedure Call

SAML - Security Assertion Markup Language

SLA - Service Level Agreement

SONET - Synchronous Optical Networking

SMTP - Simple Mail Transfer Protocol

SOA - Service Oriented Architecture

SOAP - Simple Object Access Protocol

xvi

SSL - Secure Sockets Layer

Stax - Streaming API for XML

SwA - SOAP with Attachments

TI - Tecnologia da Informao

TCP - Transmission Control Protocol

TLS - Transport Layer Security

UDDI - Universal, Discovery, Description and Integration

UDP - User Datagram Protocol

URI - Uniform Resource Identifier

VIP - Vector of Index Performance

W3C - World Wide Web Consortium

WS - Web Service

WS-Addressing - Web Service Addressing

WS-Attachment - Web Service Attachment

WS-Management - Web Service Management

WS-Reliable - Web Service Reliable

WS-Reliable Messaging - Web Service Reliable Messaging

WS-Security - Web Service Security

WS-Transaction - Web Service Transaction

WSARCH - Web Services Architecture

WSDL - Web Services Description Language

WSLA - Web Service Level Agreement

WSML - Web Service Management Language

WSOL - Web Service Offer Language

WWW - World Wide Web

XOP - XML-binary Optimized Packing

XHTML - eXtensible HyperText Markup Language

XML - eXtensible Markup Language

XML-RPC - XML Remote Procedure Call

YAWL - YAWL: Yet Another Workflow Language

xvii

xviii

CAPTULO

1Introduo

1.1 Consideraes Iniciais

A Web, tambm conhecida como World Wide Web (WWW), teve incio em 1989 no CERN,o centro europeu para pesquisa nuclear, sendo concebida por Tim Berners-Lee (Berners-Lee eFischetti, 1999). Nasceu da necessidade de fazer com que grupos de cientistas de diferentes nacio-nalidades pudessem colaborar uns com os outros por meio da troca de imagens, relatrios e outrosdocumentos em formato digital. O primeiro prottipo da Web (no modo texto) j estava operacionalno ano de 1991, durante uma demonstrao pblica na conferncia Hypertext-91 em San Antonio,no Texas. Em 1994, o CERN e o MIT assinaram um acordo criando o World Wide Web Consor-tium (W3C), uma organizao voltada para o desenvolvimento da Web, cujo objetivo era padronizarprotocolos e incentivar a interoperabilidade. Desde ento, centenas de universidades e empresasjuntaram-se ao consrcio (Tanenbaum, 2002). Atualmente, a Web amplamente utilizada para aveiculao de aplicaes que envolvem comrcio eletrnico, jogos online, aplicaes multimdia,etc. Com o surgimento dos chamados Web Services tem sido possvel que aplicaes executandoem diferentes plataformas e em diferentes linguagens de programao possam se comunicar pelaWeb por meio de uma interface denominada Web Services Description Language (WSDL), baseadaem uma linguagem interopervel e independente de plataforma e sistema operacional denominadaeXtensible Markup Language (XML). Os Web Services, oferecem caractersticas valiosas por meiodo suporte ao desenvolvimento de sistemas distribudos abertos, desenvolvido fora da composiode sistemas autnomos. No entanto, no basta que ocorra comunicao entre as diferentes apli-caes distribudas geograficamente. Essa comunicao deve ser acompanhada de caractersticasque envolvem critrios de qualidade de servio. Com a crescente popularidade dos Web Services,

1

2 1.2. CONTEXTUALIZAO

um suporte geral Quality of Service (QoS) (Erradi e Maheshwari, 2005) para esses uma questofundamental para o sucesso desta tecnologia emergente. Os ambientes de Web Services atuais nooferecem um suporte adequado qualidade de servio e apresentam diversas limitaes (Atkinsonet al., 2007), (Hicks et al., 2007). Como os Web Services podem ser aplicados em ambientes queenvolvem aplicaes de misso crtica e em cenrios Business to Busissnes (B2B), uma melhorqualidade de servio e entrega contnua de servios tornam-se questes crticas para propiciar altadisponibilidade e confiabilidade apesar da falha e indisponibilidade de servios participantes outambm da rede de comunicao (Erradi e Maheshwari, 2005). Poucos trabalhos relacionados(Marquezan et al., 2007), (Saez et al., 2004), (Suzumura et al., 2005), (Zhang et al., 2007) fazemmeno a uma anlise criteriosa em relao avaliao de desempenho, visto que na maioria dasvezes s h a proposio de arquiteturas e tcnicas conceituais (Lo e Wang, 2007), (Serhani etal., 2008), (Tabein et al., 2008), (Tabein e Nourollah, 2008), (Pegoraro et al., 2008), (Yeom etal., 2009), (Yan et al., 2009), sem nenhum resultado satisfatrio que permita afirmar que a pro-viso de QoS naquela arquitetura especfica ou no adequada. A prxima seo apresenta umacontextualizao sobre os diversos aspectos que envolvem a tecnologia dos Web Services.

1.2 Contextualizao

Web Services so uma realidade para a integrao de aplicaes Web, sendo um tpico ampla-mente pesquisado pela comunidade acadmica e por empresas como IBM, HP - Hewlett-Packard,Microsoft (Siblini e Mansour, 2005). O surgimento dos Web Services tm provocado uma mudanade paradigma na integrao de aplicaes, onde servios podem ser compartilhados para permitira otimizao de processos de negcios numa ampla estrutura de tecnologia de informao (TI).A adoo dos Web Services no mundo acadmico e empresarial j uma realidade, uma vez queas indstrias consideram duas frentes: padres e produtos (Kreger, 2003). A IBM tem investidotempo, talento e dinheiro em ambas as frentes. O conceito de Web Services foi desenvolvidocomo um fundamento de uma nova gerao de aplicaes B2B e Enterprise Application Integra-tion (EAI), bem como parte dos chamados componentes sob demanda, como Grids, Wireless ecomputao autnoma. Para isso, um conjunto de padres e tecnologias tem sido desenvolvido epassado por constantes evolues para permitir a interoperabilidade entre os componentes de umaarquitetura orientada a servios. Os Web Services so capazes de integrar aplicaes executandoem diferentes plataformas, habilitar informaes de uma base de dados de aplicaes para seremdisponibilizadas para outras, alm de permitir que aplicaes internas se tornem disponveis narede mundial de computadores, isto , na Internet. Os benefcios trazidos pela utilizao dos WebServices s tm se tornado possvel em virtude da adoo de uma linguagem padro da Web, comoa XML e suas derivaes como a WSDL, dentre outras. H diversos problemas relacionados coma integrao entre os Web Services que compem um processo de negcios que requerem muitainvestigao. Como se trata de uma tecnologia que envolve diversos conceitos e aplicaes de sis-temas distribudos, se faz necessria uma anlise de problemas como disponibilidade, dependncia

CAPTULO 1. INTRODUO 3

e confiabilidade de Web Services, alm da qualidade de servio envolvida na comunicao das apli-caes orientadas a servios (no muito explorada pelos rgos responsveis pela padronizao datecnologia de Web Services). Alguns trabalhos (Chen et al., 2003), (Ludwig, 2003), (Wu et al.,2003), (Erradi e Maheshwari, 2005), (Tsai et al., 2006), (Badidi et al., 2006), (Tavares e Westphall,2006), (DMello et al., 2008), (Zhao e Tan, 2009), tratam desses problemas com a proposio dearquiteturas isoladas. Assim, no se preocupam em considerar a possibilidade de utilizao derecursos computacionais ociosos, que poderiam ser aproveitados para a execuo de Web Servicesnum ambiente globalmente distribudo. H tambm esforos no sentido de aproveitar a ociosidadecomputacional em um contexto geral, com adoo de padres como o Open Grid Service Archi-tecture (OGSA) (Foster et al., 2002), culminando com o termo Grid Services, em que qualquerservio possa ser oferecido aos clientes num ambiente de Grid.

1.3 Motivao e Objetivos

O objetivo desta tese de doutorado o projeto e implementao de uma arquitetura orientadaa servios, denominada WSARCH - Web Services Architecture, que possibilita acesso a Web Ser-vices com Qualidade de Servio (QoS). A arquitetura proposta neste projeto estende, com adap-taes e sugestes de melhorias, outros modelos arquiteturais evidenciados na literatura de WebServices (Erradi e Maheshwari, 2005), (Benkner e Engelbrecht, 2006), (Sheth et al., 2002). O focoprincipal da WSARCH, que a torna diferente de outras arquiteturas, o fato de ser uma arquiteturavoltada avaliao e oferecimento de desempenho e voltada proviso de Web Services con-siderando atributos de qualidade de servio. Para possibilitar o desenvolvimento dessa arquiteturatorna-se necessrio definir quais atributos devem ser considerados para esse fim. Desta forma, parao desenvolvimento da WSARCH preciso identificar e mapear os atributos de QoS nos diversoscomponentes de uma arquitetura orientada a servios e em particular arquitetura proposta nestetrabalho.

Um ponto importante para atingir os objetivos da WSARCH sua arquitetura que consideraa interao entre os componentes de uma arquitetura SOA (Service Oriented Architecture) tradi-cional e tambm um Broker de servios responsvel pelo escalonamento de mensagens SOAP entrecliente, provedor e registro de servios.

Para alcanar os resultados desejados, deve-se avaliar cuidadosamente os aspectos relativos QoS em Web Services, tais como o entendimento dos protocolos que compem a arquitetura orien-tada servio, as arquiteturas propostas em trabalhos da rea e a proposio de novas metodologiasde QoS.

A metodologia utilizada para o desenvolvimento do projeto a implementao, atravs da con-struo de um prottipo da WSARCH. O prottipo deve ser desenvolvido de forma modular como intuito de possibilitar que diferentes estudos de avaliao de desempenho possam ser realizados.

4 1.4. ESTRUTURA

1.4 Estrutura

No Captulo 2 desta tese apresentada uma reviso geral sobre Web Services, bem como dosprotocolos da arquitetura SOA. Alm disso, so discutidos os conceitos relacionados QoS nonvel de aplicao.

No Captulo 3 realizado uma anlise crtica sobre os trabalhos relacionados a este projetode doutorado, envolvendo as reas de QoS, arquiteturas orientadas a servios e Web Services. Naanlise sero abordadas caractersticas peculiares de solues propostas para problemas dessasreas, alm de relacionar a proviso de QoS especificamente para Web Services. Ainda nestecaptulo so abordadas as principais limitaes de arquiteturas orientadas a servios no contextode desempenho, tais como: parsers XML, evoluo e composio de servios, segurana, WebServices attachments, compresso de mensagens, dentre outros, alm dos desafios que precisamser considerados para garantir que o desempenho geral de uma arquitetura SOA seja adequado.

No Captulo 4 caracterizada a estrutura geral da arquitetura WSARCH, no qual sero discu-tidos seus mdulos, sub-mdulos, a interao entre seus componentes, e a relao dos atributosde QoS associados arquitetura. Tambm sero discutidas todas as etapas da implementao ecomo as informaes de QoS e mensagens SOAP so propagadas entre cliente, Broker, Univer-sal Description Discovery and Integration (UDDI), monitores de Web Services e provedores deservios.

No Captulo 5 discutida a validao da arquitetura WSARCH por meio de uma avaliao dedesempenho, o que envolve a configurao do ambiente para a avaliao, o planejamento de ex-perimentos (escolha dos fatores para anlise, nveis, etc.), variveis de resposta, tais como: tempode resposta mdio, tempo de sobrecarga da arquitetura, tempo de processamento nos provedoresde servios, etc.

No Captulo 6 so apresentadas as principais concluses obtidas com o desenvolvimento desteprojeto e tambm as contribuies geradas para a rea com a apresentao do prottipo da WSARCH.Ainda nesse captulo, ser objeto de anlise uma lista detalhada de projetos futuros que podem serconsiderados a partir do desenvolvimento da arquitetura WSARCH. Finalmente no Captulo 7 soapresentadas as referncias.

CAPTULO

2SOA e Qualidade de Servios


A World Wide Web (WWW) tem sido adotada por milhes de pessoas e milhares de empresasem todo o mundo. De natureza fracamente acoplada, esse sistema distribudo ainda necessita demelhor integrao entre as aplicaes (Brooks, 2002). Como resposta melhoria na integrao dasaplicaes surgiram em meados de 2002 os chamados Web Services. A proposta visa a realizara convergncia de inmeras aplicaes que hoje esto disponveis na Web, mas que no inter-agem entre si devido algumas limitaes como: falta de uma interface comum, independncia deplataforma de hardware e de sistema operacional. O surgimento dos Web Services permite maiorcomunicao entre os sistemas, independente da linguagem em que eles foram escritos desde a suacriao. Neste captulo, so apresentados conceitos de Web Services, seus protocolos e padres,alm de uma anlise do tpico relacionado qualidade de servio (tanto em relao rede de comu-nicao quanto em relao s aplicaes), que de essencial importncia para o desenvolvimentodo presente trabalho. Nesse contexto, na Seo 2.1 realizado uma reviso sobre computaodistribuda. Na Seo 2.3 so discutidos os conceitos primordiais relacionados a SOA e Web Ser-vices, incluindo a pilha conceitual dos Web Services e a descrio de cada uma das camadas dessapilha. Na Seo 2.4 abordado o tpico relacionado qualidade de servios do ponto de vista deaplicaes incluindo os conceitos relacionados aos acordos de nveis de servios.

5

6 2.2. COMPUTAO DISTRIBUDA

2.2 Computao Distribuda

A computao distribuda uma referncia para a computao paralela descentralizada, real-izada por dois ou mais computadores conectados por meio de uma rede, cujo objetivo concluiruma tarefa em comum (Tanenbaum, 2002). Dentre os modelos de computao distribuda maisdifundidos destacam-se: o modelo cliente-servidor, o modelo peer-to-peer e o modelo de objetosdistribudos. Este ltimo semelhante ao modelo peer-to-peer, com a diferena de que h ummiddleware intermediando o processo de comunicao. Os protocolos representantes do modelode objetos distribudos mais amplamente utilizados so o Common Objetct Request Broker Ar-chitecture (CORBA) (OMG, 2001), Distributed Component Object Model (DCOM) (Hortsmanne Kirtland, 1997) e o Remote Method Invocation (RMI) (Sun, 2010). Embora esses protocolospermitam que aplicaes distribudas possam se comunicar tanto em uma rede local, quanto naInternet, eles apresentam os seguintes problemas (Brooks, 2002):

No so interoperveis com outros protocolos;

So dependentes de linguagem ou sistema operacional;

Apresentam um modelo de objeto distribudo especfico;

Possuem um formato especfico de serializao de mensagens utilizadas na troca de infor-maes entre as partes comunicantes.

As limitaes dos protocolos citados anteriormente e o crescimento da WWW, levou a necessi-dade de se estudar a criao de um novo modelo de computao distribuda dirigido ao consumidorfinal. Nesse novo modelo, chamadas distribudas so feitas por meio de hiperlinks e codificadasem mensagens (HTTP) Hypertext Tranfer Protocol como requisies GET ou POST. Respostasgeradas pelo servidor so enviadas em formato (HTML) HyperText Markup Language pelo pro-tocolo HTTP e so exibidas imediatamente pelo browser. Ainda que chamadas distribudas pos-sam ser feitas por meio de hiperlinks, alguns pontos precisam ser considerados. O primeiro que no h nenhum mecanismo padronizado para interrogar a Web diante de uma grande lista deservios disponveis, e muito menos um conjunto de interfaces padro que mostre como os serviosdisponveis poderiam ser utilizados. Em (Ehnebuske et al., 2001) os autores apresentam um breveresumo das tcnicas e tecnologias que tm sido utilizadas para tentar fazer Web Services basea-dos em HTML suportar um alto grau de interoperabilidade. Em geral, Web Services baseados emHTML e HTTP requerem um complexo processamento do lado do cliente, para entender e interpre-tar as mensagens dos servidores, alm de serem inflexveis. Nesse caso, a linguagem XML aparecepara resolver alguns desses problemas. Ao permitir uma sintaxe de comunicao extensvel e umconjunto de primitivas modulares denominada eXtensible HyperText Markup Language (XHTML),a interoperabilidade pode ser atingida. Uma questo fundamental saber como os componentesde software podem descobrir e utilizar os Web Services, e como os dados de entrada e sada sero

CAPTULO 2. SOA E QUALIDADE DE SERVIOS 7

validados, alm de questes envolvendo qualidade de servios, confiabilidade e redundncia. Osegundo ponto, to importante quanto o primeiro, saber como se dar a comunicao entre osdistintos Web Services, de forma que estes possam integrar os processos de negcios distribu-dos, ao redor do mundo. Questes como essas tm sido investigadas pelos grupos de trabalho daW3C. Esses grupos so denominados Web Services Activity. Cada grupo de trabalho constitudode membros da academia e da indstria da tecnologia da informao contribuindo por meio dapublicao de especificaes.

2.3 SOA e Web Services

Uma arquitetura orientada a servio uma maneira lgica de concepo de sistema de softwarepara prover servios para aplicativos ou usurios finais ou para outros servios distribudos em umarede atravs de interfaces que possam ser publicadas e descobertas posteriormente. O principalproblema com uma arquitetura SOA que no houve preocupao em tratar questes tais como ogerenciamento de servios, gerenciamento de transaes, a orquestrao de servios, segurana eoutros aspectos que se aplicam a todos os componentes de uma arquitetura orientada a servios,como por exemplo: qualidade de servio e desempenho. A abordagem arquitetural aplicvelquando h vrios aplicativos em execuo de diversas tecnologias e plataformas que precisam secomunicar uns com os outros. Um arquitetura SOA em sua concepo original apresentada naFigura 2.1.

Registro do

Servio

Consumidor do

Servio

Provedor de

Servios

Procura Servio

Interao

Publica Servio

Cliente

Descrio do

Servio

Descrio do

ServioServio

Figura 2.1: Arquitetura Orientada a Servio

A implementao mais abordada para o conceito de arquiteturas orientadas a servios so oschamados Web Services. O termo Web Service tem sido muito abordado nos ltimos anos, comvrias definies apresentadas pela literatura. Uma definio amplamente aceita apresenta Web

8 2.3. SOA E WEB SERVICES

Services como um componente, ou unidade lgica de aplicao, acessvel por meio de protocolospadres da Internet, possuindo uma funcionalidade que pode ser reutilizada sem a preocupaode como implementada. Web Services so referenciados como uma implementao de umaarquitetura orientada a servios - SOA (Erradi e Maheshwari, 2005). A W3C define o termo comouma aplicao identificada por um URI - (Uniform Resource Identifier), cujas interfaces e ligaesso definidas, descritas e descobertas utilizando-se uma linguagem padro como XML (Ferris eFarrell, 2003). As interaes entre Web Services ocorrem tipicamente como chamadas SOAP, que um protocolo de comunicao baseado em XML para a interao de aplicaes (Papazoglouet al., 2007). SOAP apresentado como um backbone para uma nova gerao de aplicaes decomputao distribuda, independente de plataforma e de linguagens. Alm disso, as descries deinterfaces dos Web Services so expressas usando uma linguagem denominada WSDL (Thomas etal., 2003). A pilha conceitual dos Web Services relaciona trs camadas principais: camada fsica,camada de descrio, e camada de descoberta, mostradas na Figura 2.2.

Ro

uti

ng

Qu

ality

of

se

rvic

e

Bin

ary

att

ac

hm

en

t

XM

L-R

PC

en

cry

pti

on

Tra

ns

ac

tio

n

ma

na

ge

me

nt

SOAP

XML

HTTP, SMTP, MIME

.

.

.

XML Schema

WSDL

RDF

RDF Schema

WSFL

UDDI Camada de Descoberta

Camada de Descrio

Camada Fsica

Outros Protocolos

de Internet

Figura 2.2: Pilha conceitual dos Web Services (Brooks, 2002)

Para a construo e utilizao de Web Services necessrio considerar as seguintes especifi-caes e tecnologias:

Uma maneira de representar dados;

Um formato de mensagens comum e extensvel;


Um mecanismo para localizar os servios presentes em Web sites especficos;

Um mecanismo para descobrir os provedores de servio.

Em resumo, um Web Service pode ser definido como um servio de software publicado naWeb por meio do protocolo SOAP (Gudgin et al., 2001b), (Gudgin et al., 2001a), descrito em umainterface WSDL e registrado num repositrio denominado UDDI (Ehnebuske et al., 2001). Osprotocolos relacionados a cada uma das camadas citadas sero objetos de estudo nas prximassees.

2.3.1 Camada Fsica

Trata-se da camada mais baixa e a base de todo o desenvolvimento dos Web Services. feita decomponentes para suportar a troca de servios em mais alto nvel. Sendo assim, os componentesdessa camada podem ser chamados de descritores de sintaxe de baixo nvel, que so necessriospara passagem de mensagens. Assim, essa camada responsvel pela sintaxe do roteamento dasmensagens, suporte transaes, qualidade de servio no nvel de mensagens, alm de chamadasde procedimento. Com relao aos protocolos dessa camada, dois deles tem sido amplamenteadotados. O primeiro o eXtensible Markup Language - Remote Procedure Call (XML-RPC),que geralmente adotado para servios leves, que no necessitam de um roteamento complexo ede mecanismos de tipagem de dados. O segundo o SOAP, que tem sido adotado para serviosmais pesados. Cada protocolo define um formato de mensagem baseada em XML e no necessitautilizar qualquer modelo de objeto especfico, tal como coleta automtica de lixo de forma dis-tribuda. Ambos apresentam um nmero de implementaes significativas e toolkits disponveis, eso suportados por grandes empresas como IBM, Microsoft e Sun Microsystems.

XML-RPC

A especificao XML-RPC foi desenvolvida em 1999 como um protocolo de troca de infor-maes para a Web. Foi construdo sob o topo dos protocolos HTTP 1.1 (Fielding, 1999) e XML1.0 (Apparao, 2001), tornando-o facilmente extensvel para a maioria dos Servidores Web. A idia que cada requisio XML-RPC (Ibbotson, 2001) seja enviada como uma mensagem HTTP-POST,enquanto as respostas retornam como uma mensagem de resposta HTTP 200. Quando as falhas deprocessamento de baixo nvel ocorrem, o Servidor Web consegue interpretar XML-RPC e rejeitaa requisio. Toda mensagem XML-RPC deve possuir cabealhos HTTP que incluem os camposUser-Agent, Content-Type e Content-Length, como descrito no RFC 2616 (Fielding,1999). O campo Content-Type deve ser text-xml, e o campo Content-Length deveespecificar o tamanho da mensagem. De acordo com a especificao da W3C cada requisioXML-RPC constituda de determinados elementos, onde cada elemento pode tambm conteroutros elementos. Por exemplo, cada requisio pode comear com um elemento methodCall


e este conter os elementos methodName. O elemento methodName por sua vez, identifica oservio que est sendo invocado. Os parmetros de cada mtodo so codificados com um elementoparam como um dos tipos bsicos da especificao XML-RPC. Alm de tipos bsicos no nomea-dos, XML-RPC tambm suporta um tipo bsico nomeado por meio do elemento struct. Umstruct composto de um ou mais membros, cada um deles contendo um elemento nome, quedistingue o nome do recurso, e um valor de elemento que distingue ambos os tipos e o valor dorecurso. Outra caracterstica da especificao XML-RPC tambm inclui um modo de representarum conjunto de recursos no-nomeado usando o elemento array. Um array contm um nicoelemento de dado com um conjunto de elementos de valor (os valores de elementos), cada qualcontendo um tipo de recurso. Vetores podem ser recursivos e tambm incluir no somente o tipobsico, mas tambm structs.

Simple Object Access Protocol (SOAP)

O protocolo SOAP uma especificao para requisitar mtodos de negcio, como documen-tos XML e suporta outros protocolos como HTTP e Simple Mail Transfer Protocol (SMTP). Oprotocolo SOAP o protocolo de comunicao para os Web Services. Dentre suas principais car-actersticas destaca-se a definio do formato das mensagens XML. Uma mensagem SOAP nadamais que um fragmento XML bem formado, encapsulado por um par de elementos SOAP. Houtras partes da especificao SOAP que descrevem como representar os dados do programa emXML e como us-lo para fazer as chamadas de procedimento remoto. Tais partes opcionais daespecificao so usadas para implementar as aplicaes no estilo Remote Procedure Call (RPC).Neste caso, o cliente envia a mensagem SOAP contendo a chamada e os parmetros da funo, e oservidor retorna uma mensagem com os resultados da funo executada. Ressalta-se que as imple-mentaes atuais do SOAP suportam aplicaes RPC porque os programadores acostumados comas aplicaes DCOM (Hortsmann e Kirtland, 1997) ou CORBA (OMG, 2001) aplicam esse estilode forma adequada. Em contrapartida, o SOAP tambm suporta aplicaes no estilo documento,onde a mensagem apenas um envlucro de um documento XML, sendo um estilo flexvel, jque alguns Web Services o utilizam para implementar servios que seriam difceis de desenvolverusando chamada remota de procedimentos (Brooks, 2002). Outra parte opcional da especificaoSOAP define como uma requisio HTTP que contm uma mensagem SOAP. Por ser o protocolocentral da WWW e por possuir caractersticas de segurana, monitoramento e balanceamento decarga, o HTTP tornou-se o protocolo padro para o transporte de mensagens XML, muito emboramuitos outros protocolos tais como SMTP e File Transfer Protocol (FTP) possam ser utilizados.

2.3.2 Camada de Descrio

A camada de descrio contm uma semntica formal para descrever as mensagens que umWeb Service pode entender, as restries aplicadas aos dados dentro daquelas mensagens, as cat-egorias ou ontologias as quais as mensagens pertencem, e o modo em que Web Services podem


ser combinados com um outro para suportar fluxo de trabalho de negcios. Tipos de dados somanipulados pelo XML-Schema, enquanto semnticas para interfaces de Web Services so manip-uladas pela WSDL. O Resource Description Framework (RDF) utilizado para criar ontologiaspara categorizar mensagens e servios.

XML-Schema

XML-Schema (Lassila, 1999), (Leymann, 2001) um mecanismo para a definio de tiposde dados complexos para documentos XML. Ele permite a definio de novos tipos de dados eno fora o usurio a adotar uma metodologia de programao especfica. XML-Schema exclui aambiguidade que pode ser trazida enquanto se usa o Document Type Definition (DTD), o mecan-ismo padro de dados para documentos XML. Outra caracterstica do XML-Schema que ele temsido amplamente adotado como um novo mecanismo de tipagem de dados para documentos XML.Outro ponto o suporte a extenses por meio do uso de namespaces XML, alm da proviso deum mecanismo para identificar instncias de esquema individuais (Team et al., 2001). Podem serdefinidos tipos de dados baseados em string simples ou tipos de dados de fragmentos de docu-mentos XML mais complexos. Tipos de dados podem ser estendidos ou restringidos em razo douso de 12 tipos de facetas de tipos de dados e 25 tipos de padres de dados simples.

Web Services Description Language (WSDL)

O acrnimo WSDL trata-se de um documento XML que descreve um conjunto de mensagensSOAP, a especificao de um servio, e tambm a forma como as mensagens so trocadas entreclientes e provedores de servios. As mensagens entre Web Services so quebradas em partesde elementos, representados por fragmentos de nomes de documentos. Operaes so conhecidascomo pontos de entrada em um Web Service e so descritos como elementos portType. Fazendo-se uma analogia, o WSDL para o SOAP o que a Interface Definition Language (IDL) para oCORBA. Para os Web Services, o WSDL define quatro tipos diferentes de primitivas de transmissodescritas a seguir:

One-Way: cliente envia com nenhuma resposta;

Requisio/Resposta: cliente envia e recebe uma resposta do servidor

Solicitao/Resposta: servidor (Provedor de servios) envia e recebe a resposta do cliente.

Notificao: servidor envia e nenhuma resposta retornada.

Resource Description Framework (RDF)

O RDF uma especificao produzida e recomendada pela W3C Semantic Web Activity. Seuobjetivo principal definir uma gramtica que pode ser utilizada para marcar semanticamente


recursos Web, isto , criar um modelo simples de dados, com uma semntica formal, usar o vocab-ulrio baseado em um URI, uma sintaxe baseada em XML e suportar o uso de XML. Os arquivosRDF possuem trs componentes bsicos: recurso, propriedade e indicao, tornando a linguagemaltamente escalvel:

Recurso: Qualquer objeto que pode conter um URI, incluindo as pginas da Web, assimcomo elementos de um documento XML;

Propriedade: Um recurso que tenha um determinado nome e que possa ser utilizado comouma propriedade;

Indicao: Consiste na combinao de um recurso, de uma propriedade, e de um valor.

2.3.3 Camada de Descoberta

A camada de descoberta consiste de processos e protocolos pelos quais os Web Services podemser descobertos por pesquisas por meio de seus metadados, cujo objetivo primariamente so astransaes de negcios. Para que uma chamada a um Web Service seja realizada com sucesso, necessrio localiz-lo, descobrir a interface com a semntica da sua chamada, alm de escrevere configurar o software local para colaborar com o servio. O Universal Discovery Descriptionand Integration (UDDI) (Ehnebuske et al., 2001) caracteriza-se por ser as pginas amarelas dosWeb Services. Como as pginas amarelas de uma lista telefnica, possvel procurar por umacompanhia que oferea os servios que voc precisa, ler sobre o servio oferecido dentre outrasinformaes. Alm disso, possvel oferecer o Web Service construdo e registr-lo no UDDI.

Universal Description Discovery and Integration (UDDI)

Enquanto no h nenhuma especificao padronizada pela W3C, o UDDI apropriado para su-portar o mecanismo de descoberta. Essencialmente, o servio UDDI um repositrio centralizadodas especificaes da camada de descrio, cuja construo bastante parecida com o DomainName System (DNS). Registros UDDI podem estar em escala global ou disponvel em intranetslocais. Entradas UDDI incluem pontos de entradas dos Web Services e metadados associados,publicados em uma ou mais taxonomias. Um diretrio UDDI um arquivo XML que descreve onegcio e os servios. O registro apresenta trs partes:

Pginas Brancas: descrevem a companhia (nome, endereo, contatos, etc.);

Pginas Amarelas: incluem as categorias baseadas em taxonomias padres;

Pginas Verdes: descrevem a interface para o servio, com detalhes suficientes para seescrever uma aplicao que utilize o Web Service.


2.4 Qualidade de Servio

O termo Qualidade de Servio pode ser visto de diversas formas de acordo com a rea deaplicao. Por exemplo, do ponto de vista de uma rede de comutao de circuitos, refere-se probabilidade de sucesso em estabelecer uma ligao a um determinado destino. Do ponto devista de uma rede de comutao de pacotes a Qualidade de Servio (QoS) refere-se capacidadede uma rede prover melhores servios para um dado trfego selecionado, podendo utilizar vriastecnologias incluindo Frame Relay, ATM, Ethernet, redes 802.11, SONET e redes IP (Vesegna,2001). Dentre os parmetros para descrever QoS destacam-se, largura de banda, utilizao debuffers, atraso, jitter, prioridades, utilizao de CPU, etc. No contexto deste trabalho de doutorado importante destacar o termo QoS do ponto de vista de rede, uma vez que muitos dos conceitosaplicados na camada de rede de comutao de pacotes podem ser utilizados em aplicaes Webatuais. Atualmente, o trfego na rede muito diversificado e cada tipo possui um requisito nicoem termos de largura de banda, atraso, perda e disponibilidade. Com o crescimento da Internet, amaioria das redes do momento baseada no protocolo IP. O fato da pilha de protocolos padro daInternet possuir um nico protocolo de rede benfico, uma vez que a manuteno dos equipamen-tos de rede se torna menos complexa, resultando em custos operacionais mais baixos. No entanto,isso contrastado pelo fato de que o IP um protocolo sem conexes, isto , os pacotes IP nopossuem um caminho especfico medida que trafegam pela rede. Essa caracterstica do protocoloIP sinaliza para uma qualidade de servio inadequada em uma rede best effort (Networks, 2003).A pilha do protocolo IP bsica fornece somente um servio de melhor esforo. Nesse modelo,as requisies so processadas conforme a estratgia da primeira a chegar ser a primeira a seratendida. Isso significa que todas as requisies tm a mesma prioridade e so processadas umaaps a outra sem nenhuma distino. Em um cenrio em que cada vez mais as pessoas e as em-presas esto utilizando a Internet para entretenimento, para fins comerciais e para fins acadmicos,a capacidade do canal de comunicao torna-se um assunto importante. Aplicaes bem conheci-das do pblico da rede mundial de computadores como RealAudio, RealVideo, Internet Phone,Skype e sistemas de videoconferncia fazem muito mais uso da largura de banda disponvel queos aplicativos usados nos primeiros anos da Internet, tais como aplicativos de transferncias dearquivos e de login remoto. O mesmo ocorre para aplicaes da nova gerao da Web, isto aWeb 2.0, tais como o YouTube, Revver, etc. Enquanto aplicativos tradicionais, tais como WWWe FTP no toleram perda de pacotes, mas so menos sensveis aos atrasos variveis, a maioriados aplicativos em tempo real apresenta o comportamento oposto. Isso ocorre, pois, estes podemcompensar uma quantidade razovel de perda de pacotes, mas so bastante crticos em relaoaos atrasos variveis. Diante dessa situao, na ausncia de algum tipo de controle de largurade banda, a qualidade desses fluxos de dados em tempo real torna-se dependente de tal ausncia(Ferguson e Huston, 1998). Apesar do aumento da largura de banda melhorar a interatividade dasaplicaes, ela no suficiente para que a qualidade de servio de uma determinada aplicao sejagarantida. Essa insuficincia deve-se aos longos congestionamentos, aos atrasos inadmissveis em

14 2.4. QUALIDADE DE SERVIO

redes compartilhadas por milhares de usurios e, na maioria das vezes, a longas distncias. Halgumas formas de prover qualidade de servio s aplicaes crticas (voz e videoconferncia, porexemplo), com destaque para os servios integrados, servios diferenciados e prioridade relativa.Pesquisas recentes, tais como as discutidas em (Benkner e Engelbrecht, 2006), (Liang et al., 2008),(Liang et al., 2009) tm mostrado que a QoS tambm pode ser obtida em nvel de aplicao.

2.4.1 Servios Diferenciados em nvel de aplicao

A disponibilidade universal e a facilidade para utilizar a interface provida pelos Web browsers,juntamente com o crescimento do nmero de usurios da Internet, tm motivado empresas degrande porte a migrar servios de misso crtica para a Web. Bancos online, livrarias, reservas depassagens so exemplos de servios que esto sendo oferecidos via Web front-ends. Tais carac-tersticas so uma tendncia na Web, de modo que as consideraes de qualidade de servio tmganho importncia. Por exemplo, o tempo de resposta elevado, por parte de um site da Web, umdos problemas enfrentados pelos usurios finais (Srinivas et al., 2000). Enquanto prever a demandae aumentar a capacidade dos servidores em geral pode permitir a um site da Web descobrir as ex-pectativas de QoS dos usurios, saber com certeza a demanda de novos usurios mais custoso eapresenta mais dificuldades. A alternativa para o tratamento desse problema tem sido a proviso dequalidade de servio em servidores Web, de modo que quando um servidor esteja sobrecarregado,este tenha a habilidade para estabelecer prioridades dentre as requisies que a ele chegam e, sele-tivamente, processar aquelas que so consideradas mais importantes segundo determinado critrio.Para o usurio final, deve haver um limite no tempo de resposta s resquisies enviadas a um clus-ter de servidores Web. Se o tempo de resposta exceder um determinado limiar, o usurio tende aficar insatisfeito com o servio oferecido. Por isso so necessrios algoritmos de balanceamentode carga, como sugerem os trabalhos de (Ho et al., 2004) e (Chen e Chen, 2004) , para permitiralta disponibilidade dos servidores, evitar a sobrecarga, alm de possibilitar uma resposta rpidaaos clientes. Outros trabalhos que merecem destaque nesta rea, incluem (Pai et al., 1999), (Crov-ella et al., 1999), (Cherkasova e Phaal, 2002), (Eggert e Heidemann, 1999), (Chen e Mohapatra,1999), (Blanquer et al., 2004), (Bhinder et al., 2004), (Andreolini et al., 2004). Todos, de umaforma geral abordam a problemtica de se tratar a diferenciao de servio no nvel da aplicao,utilizando tcnicas de balanceamento de carga, escalonamento, controle de admisso, middleware,etc. Como complemento diferenciao de servios em servidores Web, muitas so as discussesem torno da qualidade de servios relacionadas aos Web Services tais como as evidenciadas em(Liang et al., 2008), (Liang et al., 2009), (Qiqing et al., 2009), (Sha et al., 2009), (Huang e Nie,2010). As questes relacionadas s garantias fundamentais de QoS tais como: disponibilidade,acessibilidade, integridade, desempenho, confiabilidade e segurana (Jensen et al., 2007) aindaso incipientes. Esforos de pesquisadores e empresas tm originado resultados importantes. Ummodo para a proviso de qualidade de servio em Web Services a utilizao de protocolos querealizam o transporte confivel das mensagens trocadas entre as aplicaes envolvidas num pro-


cesso de comunicao. No entanto, alguns estudos tm sido conduzidos para o desenvolvimentode outras especificaes que garantam melhor QoS para os Web Services. Um comit tcnico daW3C trata desse assunto, e desenvolveu uma especificao de Web Services confivel denominadaWS-Reliability (Leavitt, 2004). Destaca-se tambm suporte para a descrio de camadas de acor-dos de nveis de servios, denominadas Web Service Level Agreements (WSLA). Atualmente, aindano foi adotada nenhuma especificao padro para a utilizao de Web Services com qualidadede servio. Por isso, enquanto no h uma slida especificao padro de QoS para Web Services,os trabalhos relacionados na literatura da rea refletem diversos cenrios, principalmente porquegarantir qualidade de servio um grande desafio devido a heterogeneidade e a natureza impre-visvel dos servios (Farkas e Charaf, 2003), (Skorin-Kapov et al., 2007), (Nemati e Takizawa,2008), (Gardasevic e Bojkovic, 2009), (Liang et al., 2009).

2.4.2 Service Level Agreements (SLA)

O termo Service Level Agreements (SLA) baseado no conceito de servios fixos e acordosde desempenho entre clientes e provedores de servio, criando uma transparncia para ambas aspartes em termos de desempenho e custos. Acordos de nveis de servios especficos so usa-dos para definir o tipo, o escopo, a qualidade de servios, e para verificar que especificaes soconhecidas. Como tais acordos tambm incluem sanes potenciais para o evento que aceitou osparmetros de servios que no so conhecidos, as especificaes fazem com que elas tenham umefeito significativo no sucesso comercial de uma companhia, provendo servios para seus clientes(Schmietendorf et al., 2004). No contexto de arquiteturas orientadas a servio, os benefcios degerenciamento de nveis de servio so descritos abaixo: O nmero de situaes de conflito entreprovedor e cliente podem ser reduzidos, resultando na melhoria da satisfao do cliente; Os recur-sos utilizados para melhorar o servio (hardware) podem ser distribudos num nvel detalhado peloprovedor de servios e, por isso, usados para otimizar os custos; Problemas podem ser identifica-dos rapidamente pelo monitoramento de nvel de servio e a causa associada pode ser determinada;Custos podem ser mais transparentes - por um lado, o consumidor (cliente) quer somente pagarpelo servio que ele utiliza, por outro lado, um preo adequado pode ser garantido;

Como parte do gerenciamento de acordo de nvel de servio para Web Services baseados emaplicaes, um acordo deve ser concludo para prover o Web Service. As especificaces discutidasem (Keller e Ludwig, 2003) so apresentadas a seguir:

Partes envolvidas e a validade de um acordo, isto , o perodo sobre o qual o servio serprovido;

Especificao de componentes de contrato e procedimentos para qualquer modificao necessria;

Especificao de um escopo funcional e qualidade de servio a ser provida;

Definio de parmetros de SLA com a qual a proviso do servio ser efetuada;

16 2.4. QUALIDADE DE SERVIO

Especificao do procedimento para determinar/calcular os parmetros de SLA.

De acordo com (Schmietendorf et al., 2004) os contedos descritos para um acordo de nvel deservio podem variar significativamente em termos de preciso de detalhes. No caso de aplicaesbaseadas em Web Services, essencialmente necessrio manter o relacionamento entre os WebServices envolvidos em prover o servio e promover uma padronizao de possveis SLAs. Tantoo aspecto semntico quanto o sinttico podem ser negociados usando XML. A padronizao de as-pectos semnticos ainda est em fase inicial. Um exemplo disso, a tarefa de interpretar a disponi-bilidade de um Web Service que especificado como 98 por cento. Usurios podem questionar seo tempo de manuteno levado em considerao, e como seria tratado um possvel downtime dosistema. Esta flexibilidade deve ser explicitamente levada em conta durante o desenvolvimento, e ainterface do Web Service deve ser tratada com esta informao. Alm disso, o monitoramento deveser suportado por pontos de medidas adequadas, de modo que potenciais gargalos do SLA possamser identificados. Em geral, qualidade de servio se refere s propriedades no funcionais de WebServices, tais como: desempenho, confiabilidade, disponibilidade, throughput, tempo de resposta,latncia, acessibilidade, robustez, flexibilidade, integridade, reputao e segurana, (Kalepu et al.,2003). Em (Bouch et al., 2000) so discutidas que as mtricas tradicionais de QoS tais comotempo de resposta e retardo no so suficientes para descrever totalmente a qualidade de serviopercebida pelos usurios. Outro fator, que ao se levar em considerao determinados quesitosde QoS, alguns trabalhos abordam o melhor modo possvel de descobrir a WSDL mais apropriadaque defina um servio (Erradi e Maheshwari, 2005), (Ludwig, 2003). Na busca pela WSDL maisadequada, um suporte QoS deve responder a questes principais: Qual a latncia envolvida e qualo round-trip-time (retardo de ida e volta) aceitvel (Kalepu et al., 2003). Essa uma das vertentesde pesquisas de QoS em Web Services. Outras buscam melhorar a interao entre aplicaes mod-ificando protocolos, tal como o HTTP, e os adequando s caractersticas dos Web Services (Bankset al., 2002). Soma-se a isso, proposies de arquiteturas para prover QoS entre os Web Services,com a incluso de Brokers (responsveis por procurar pelo melhor repositrio que contm a WSDLpara um determinado Web Service requisitado pelo cliente) (Farkas e Charaf, 2003). Alguns tra-balhos tambm tm se concentrado na proposio de novas mtricas para melhorar a QoS numaarquitetura orientada servio (Kalepu et al., 2003), (Kalepu et al., 2004), (Taher et al., 2005),(Thio e Karunasekera, 2005), (Sha et al., 2009), (Liang et al., 2009). Em resumo, de acordo comuma anlise da literatura da rea, verifica-se que a rea de qualidade de servio em Web Servicesapresenta uma quantidade considervel de trabalhos, mas parte deles apenas enfatizam linguagens,arquiteturas e mtricas de QoS para Web Services, e poucos trabalhos evidenciam de forma sucintaos benefcios da proviso de QoS, por meio de resultados e da anlise de desempenho, tpico quedeve ser enfatizado no desenvolvimento deste projeto de doutorado.


2.5 Consideraes Finais

Este captulo abordou a caracterizao dos Web Services, incluindo protocolos, padres e astcnicas utilizadas atualmente para a construo de aplicaes envolvendo servios Web. Umdestaque maior foi dado ao tpico relacionado qualidade de servio em especial no nvel deaplicao, com os esforos de diversos grupos de trabalho para a proviso de QoS em Web Ser-vices. A Web tem se tornado nos ltimos anos um canal para troca de informaes, negcios ecomrcio eletrnico, sendo necessrio, portanto, um tratamento diferenciado para as aplicaesque recebem solicitaes de clientes ou sistemas distintos. Soma-se a isso, a adoo da idia deque tudo na Web se torne um servio e que a utilizao de determinada funcionalidade de um sis-tema, principalmente das grandes empresas, esteja disponvel para a interao com outros sistemasde outras empresas e at mesmo centros de pesquisas. Nesse sentido, para que os problemas deinterao sejam diminudos, faz-se necessria a adoo de mtricas de qualidade de servio. Noprximo captulo sero abordados os principais trabalhos relacionados envolvendo composio deservios, desempenho e qualidade de servios em Web Services. O Captulo 3 tambm destaca asprincipais limitaes de uma arquitetura orientada a servios no contexto atual, e de que formaessas limitaes podem degradar o desempenho do ponto de vista dos componentes participantesde uma arquitetura SOA.

CAPTULO

3Desempenho em SOA e QoS em Web

Services


O objetivo deste captulo apresentar uma discusso em torno dos trabalhos relacionados aodesempenho em arquiteturas orientadas a servios e qualidade de servio em Web Services. Essadiscusso e uma anlise cuidadosa desses trabalhos so de fundamental importncia para se situarnas reas de pesquisa em questo e tambm para sugerir possveis melhorias para a comunidadecientfica, sendo, portanto, referncias para o desenvolvimento deste projeto de doutorado. Nessecontexto, na Seo 3.2.1 so discutidos diversos trabalhos relacionados ao tpico de composiode Web Services, o qual tem sido amplamente pesquisado pela comunidade acadmica nos ltimosanos. Na Seo 3.2.2 so abordados trabalhos relacionados qualidade de servio em especialvoltado para arquitetura SOA e Web Services. As principais limitaes do paradgmina de arquite-turas orientadas a servios, incluindo protocolos, dispositivos mveis, XML parser, dentre outros,so apresentadas na Seo 3.3. Na Seo 3.4 so apresentados trabalhos relacionados a criaode ndices de desempenho, de modo que esses pudessem ser utilizados no prottipo da arquiteturaWSARCH.

19

20 3.2. TRABALHOS RELACIONADOS

3.2 Trabalhos Relacionados

3.2.1 Composio de Web Services

Pesquisas efetuadas de acordo com a literatura sobre Web Services tm demonstrado um grandeinteresse dos pesquisadores em investigar como prover qualidade de servio durante a troca demensagens entre duas partes comunicantes. Uma referncia importante relatando os problemas,os desafios e as iniciativas da rea de computao orientada a servio so apresentadas em (Papa-zoglou et al., 2007), (Papazoglou et al., 2006) e tambm em (Papazoglou, 2003). Em (Papazoglouet al., 2007) a temtica o paradigma de computao que utiliza servios como elementos funda-mentais para o desenvolvimento de aplicaes/solues. O autor argumenta que os Web Servicesrequerem consideraes especiais para interaes entre os servios. A arquitetura original SOA nose preocupa com detalhes como: gerenciamento, coordenao e segurana. O artigo tambm rela-ciona a interao entre Web Services (cujo foco a neutralidade de plataformas computacionais,descoberta e invocao de servios) e grades (com foco na dinmica de servios e uso eficiente derecursos computacionais distribudos). Em (Papazoglou e van den Heuvel, 2005) os autores dis-cutem o relacionamento de gerenciamento de sistemas distribudos com o gerenciamento de WebServices explorando diversas abordagens e conceitos arquiteturais. Em (Menasce, 2004) o autortrata dos problemas de composio de Web Services. Analisa essa problemtica por meio de umexemplo e destaca ateno para o tpico: Como os diferentes atributos de QoS devem ser com-binados para realizar uma composio de servios mais elaborada? Destaca, de maneira formal,alguns tipos de composio de servio, tais como:

Invocao probabilstica: deve ocorrer quando h dois servios disputando para fazer parteda composio e somente um deles selecionado probabilisticamente;

Invocao Paralela: numa situao em que S um servio composto e A e B so seussucessores, para que a composio seja efetivada com sucesso, todos os sucessores de Sprecisam ser invocados em paralelo;

Ativao Seqencial: os caminhos que conduzem ao servio S so mutuamente exclusivos.Isso significa que se um deles completar, o servio S se inicia;

Ativao do mais rpido predecessor: a execuo de S se inicia to logo a execuo doprimeiro predecessor esteja completa;

Ativao Sincronizada: a execuo de todos os servios predecessores precisam ser com-pletadas antes de S ser iniciado.

Outro desafio mencionado pelo autor, mas no caracterizado com um exemplo, a composiodinmica de servios. O ponto positivo desse trabalho a discusso em torno da composio de

CAPTULO 3. DESEMPENHO EM SOA E QOS EM WEB SERVICES 21

servios. Mostra um exemplo terico de composio esttica e alguns tipos de composio deservios. Sobre a composio dinmica, que um tpico relativamente complexo (Yang et al.,2005), no abordada com maior profundidade e no so apresentados exemplos. O trabalho de(Wang et al., 2004) apresenta uma engine denominado D3D-Serv para implementar a funcionali-dade de composio de servios que utilizada para compor servios de diferentes requerimentose lgicas de negcio. A idia discutir uma estratgia de seleo e execuo de servios (de modoeficiente) baseada em teoria de filas e que pode prover garantias de QoS sobre recursos limitadosdos provedores. A composio de servios um tpico de pesquisa bastante discutido e cuja car-acterstica a modelagem de processos de negcios complexos. Por exemplo, em um sistema delogstica a integrao complexa de vrias aplicaes deve envolver muitas companhias, consum-idores, fornecedores, provedores e clientes. O artigo descreve um framework para composiodinmica de servios. Neste framework a idia que os servios sejam definidos sob demanda,selecionados de acordo com critrios de QoS e executados de forma dinmica. Dado o problema decomposio, estudam uma estratgia de seleo de provedores de servios garantindo uma deter-minada QoS. A estratgia de seleo uma abordagem dinmica e adaptvel ao ambiente dinmicoda Web. Os autores modelaram o problema do ambiente dinmico da Internet e utilizaram a van-tagem oferecida da teoria de redes de filas para o processo de seleo e escalonamento de servios.Sugerem que a abordagem por eles oferecida permitem ganhos de desempenho em ambientes so-brecarregados e com limitao de recursos. A abordagem interessante, inclusive no que dizrespeito ao mecanismo de funcionamento do engine. Os algoritmos tambm so devidamente ex-plicados. Os grficos com os resultados sinalizam o entendimento dos mecanismos sugeridos peloartigo. No entanto, como boa parte dos artigos, falha em no mostrar de forma clara como foi feitaa simulao, quais ferramentas foram utilizadas e como foi feita a composio. A composiodinmica abordada na escrita do artigo, mas nenhum resultado relacionado apresentado.

Em (Jaeger et al., 2005), os autores abordam a seleo de Web Services para o processo decomposio e como considerar diferentes categorias de QoS para determinar os candidatos maisadequados para tal processo. Como ponto positivo, o artigo demonstra o modo de calcular a qual-idade de servio de uma composio de Web Services, agregando a QoS a cada servio individuale tambm sinaliza para alguns algoritmos que permitem a seleo de candidatos para otimizar acomposio. Em (Ardgna e Pernici, 2005), por sua vez, discutido o processo de composiode servio como um problema de otimizao linear, isto , uma abordagem matemtica da com-posio de servio. Ainda com relao ao processo de composio de servios, em (Kalepu et al.,2003) apresentada uma mtrica para quantificar a composio e seleo de um Web Service. Autilizao da mtrica deve ser voltada aos provedores de servios de modo a verificar se estes estocumprindo os acordos de nveis de servios com os usurios (clientes). Esse esforo vlido, vistoque, h problemas em selecionar o Web Service mais adequado em razo da grande quantidadede provedores de servios. Por isso, existe a necessidade de delimitao de qualidade de serviopara diferenciar os provedores e responder a seguinte pergunta: H o cumprimento dos acordosde nveis de servios com os usurios? Uma questo a necessidade do usurio, outra est rela-


cionada ao que o provedor de servios pode oferecer. Para os autores, a proposio de uma mtricapara quantificar qual o melhor provedor de servio a ser escolhido deve levar em consideraoaspectos como a replicao de servios, distribuio de carga, redirecionamento de servidores emedida dos atributos de QoS. Alm disso, alguns autores fazem aluso ao termo de Reputao emWeb Services, que permeiam questes como (Kalepu et al., 2004): como escolher o servio corretoe em que parmetros se basear. Um ponto negativo destacado em (Kalepu et al., 2003) o deapresentar a mtrica mas no correlacion-la com uma abordagem prtica ou simulada. Apresentaa arquitetura proposta, mas no uma avaliao quantitativa.

3.2.2 Qualidade de Servio

Muitos trabalhos relacionados no consideram avaliao de desempenho em Web Services.Com a integrao de Web Services como uma soluo de negcios em muitas aplicaes empre-sariais, a qualidade de servio apresentada pelos Web Services est se tornando a preocupao tantodos provedores de servios quanto dos clientes. Provedores precisam especificar e garantir a QoSde seus Web Services para se manterem competitivos e realizarem o melhor atendimento de seusprocessos de negcios. Por outro lado, os clientes objetivam que os servios solicitados tenhambom desempenho (alta disponibilidade, baixo tempo de resposta, baixa latncia). Em (Comuzzi ePernici, 2005), os autores trabalham na criao de uma abordagem automtica para a negociaode Web Services. A negociao realizada por um Broker no qual ambos o provedor e o con-sumidor do servio podem notificar suas preferncias de QoS e negociar estratgias especificandoo valor de um conjunto de parmetros. A idia que o Broker tenha um modelo de deciso decada provedor, de modo que o cliente faa a interao diretamente com o Broker. O Broker podesimular o comportamento do provedor no processo de negociao sem ter contato com o provedortoda a vez que o usurio faz um novo oferecimento de QoS.

Em (Orta et al., 2009) apresentado um modelo de simulao relacionado ao gerenciamentode capacidade de Web Services. A principal finalidade do modelo ajudar a gerir a capacidade deWeb Services atribudas pelos provedores de servios aos seus clientes com o objetivo de asseguraro cumprimento de um acordo de nvel de servio (SLA - Service Level Agreements). Questesde QoS tm recebido ateno durante os ltimos anos, a maioria em rede de comunicao e tam-bm em comunidade de middleware (Tian et al., 2004) em que mtricas locais foram definidassem a preocupao com mtricas para servios fim-a-fim. Tem sido difcil encontrar propostaspara negociao direta de QoS em ambientes de Web Services, especialmente quando consideramestratgias com aspecto fundamental em definir um framework de negociao automatizada.

Em (Thio e Karunasekera, 2005), discutido como fazer medidas de QoS tanto do lado docliente quanto do servidor. Qualidade de servio de um Web Service um fator importante quediferencia servios similares oferecidos pelos vrios provedores. Tal medida permitiria a umcliente de um Web Service escolher e ligar um Web Service adequado em tempo de execuo(baseado em atributos de QoS). Alguns pesquisadores tm proposto a integrao de medidas de


QoS no diretrio do servidor do Web Service. Este artigo prope um mecanismo dessa natureza,isto , um mecanismo para manter mtricas de QoS. Esse mecanismo deve envolver medidas au-tomticas de atributos de QoS, tanto do lado do cliente quando do lado do servidor, quando oservio est sendo usado e atualizando o diretrio baseado em QoS, com esta informao. Aspropriedades de QoS podem ser representadas como atributos dos servios e conseqentementea consulta do cliente pode ser baseada nessas propriedades. O modo como o autor apresenta astcnicas para avaliar o desempenho em Web Services, poder ser considerado para definir o quefoi avaliado na implementao deste projeto de doutorado. Em (Sheth et al., 2002) proposto ummiddleware de alto nvel para a arquitetura orientada a servio e a composio de um modelo deQoS levando em conta as seguintes dimenses: tempo, custo, confiabilidade;

As definies das dimenses segundo o trabalho citado so:

Tempo de resposta: o tempo estimado entre a chegada de uma requisio de servio e oprocessamento daquela requisio;

Custo: custo associado com a execuo de Web Services;

Confiabilidade: probabilidade que um servio atenda s necessidades de quem deseja utiliz-lo. Ou seja, a taxa de execues escalonadas/executadas com sucesso.

Fidelidade: usada para indicar quo bem um servio atende as expectativas dos usurios.Tratada como um vetor composto de atributos de fidelidade. Cada atributo se refere a umapropriedade/caracterstica do produto/servio criado, transformado ou analisado.

Outras questes importantes abordadas em (Sheth et al., 2002) so como determinar as estima-tivas para as propriedades de QoS de um Web Service. Neste caso pode-se ter:

Uma combinao de estimativas de projetistas (da aplicao);

Estimativas de QoS so paramtricas. Como por exemplo, o tempo de resposta de um servioque obtm um documento XML como entrada, depender do tamanho do documento;

A especificao do comportamento de execuo de um Web Service pode ser feita utilizando-se 2 classes:

Bsica: associa a cada dimenso de QoS do Web Service um valor mnimo, mdio emximo. Os valores especificados nesta classe so empregados por mtodos matemti-cos para computar mtricas de QoS. Por exemplo: a dimenso do custo corresponde aum valor mnimo, mdio e mximo associada com a execuo de uma tarefa.

Distribucional: corresponde especificao de uma constante ou de uma funo dedistribuio (exponencial, lognormal, normal, etc.) que estatisticamente descreve ocomportamento da tarefa em tempo de execuo. Os valores so apresentados pormeio de simulao para computar o fluxo de trabalho de QoS.


O aspecto positivo do trabalho de (Sheth et al., 2002) a abordagem sobre gerenciamento deQoS de modo efetivo e eficiente, alm da integrao de Web Services, grades e redes peer2peer.Produtos e servios devem ser disponveis aos consumidores com especificaes bem definidaspara preencher expectativas dos clientes. Cita uma ferramenta para simulao (JSIM) (Miller et al.,1997) e outra para criao de fluxo de trabalho de QoS. Aborda que resultados estatsticos podemser coletados e mostrados indicando o fluxo de trabalho de QoS. Em (Woodside e Menasce, 2006),os autores defendem que muitos projetos de aplicaes para sistemas distribudos falham porqueno abordam aspectos de qualidade de servio. Solues baseadas na atualizao de hardware noresolvem o problema causado por componentes de software inadequados e por construes erradasde arquiteturas de software. Abordam algumas tcnicas para o desenho de QoS:

Evolution: baseada nas caractersticas de desempenho anteriores para a tomada de deciso.

Precision Design: explora modelos de carga, comportamento e recursos para obter QoSadequada.

Flexible Design: trabalha com caractersticas para lidar com as incertezas da carga de tra-balho e criar softwares escalveis que (dado um conjunto suficiente de recursos) podemoperar eficientemente para uma vasta gama de cargas de trabalho.

Em (Woodside e Menasce, 2006) reiterado que a qualidade de servio resulta da interaoentre a demanda do usurio, o comportamento do sistema sobre essa demanda e os recursos queesse comportamento requer. Se tais fatores no forem considerados, a tendncia o mal uso derecursos e uma QoS no controlada. O ponto principal deve ser o conhecimento do comportamentodas aplicaes e suas demandas por recursos. Um problema freqentemente enfrentado a difi-culdade de descobrir esse comportamento. O trabalho de (Taher et al., 2005) tem como objetivoprover suporte seleo de Web Services baseado em critrios de QoS em um framework denomi-nado QoS Information and Computation (QoS-IC). O destaque para o mapeamento de QoS paraconsumidores (clientes) com a informao de QoS publicada pelos provedores de servio. Os au-tores criticam o mecanismo atual de seleo de Web Services em registros de servios pelo fatodaquele ser baseado somente nas informaes publicadas no documento WSDL, ou seja, somentenas informaes funcionais. Os clientes precisam de um mecanismo baseado numa informaofuncional e tambm no funcional (tempo de resposta, disponibilidade, confiabilidade, etc.). Acontribuio dada pelo artigo so as discusses sobre como selecionar Web Services de um prove-dor de servios. Os autores utilizam uma tcnica de otimizao para tal finalidade. Apresentade forma clara e transparente a metodologia e descreve matematicamente todo o procedimento.O ponto negativo que os autores no exploram questes de avaliao de desempenho e simu-lao/implementao.

Outra tcnica para a melhoria da proviso de QoS a utilizao de um mecanismo que re-duza o tempo de transmisso e de resposta das mensagens trocadas entre Web Services (Wu et al.,


2003), por meio da compresso de mensagens a serem enviadas do consumidor para o provedorde servios. Durante o desenvolvimento desse projeto de doutorado foi proposta uma heursticaque pode ser usada para decidir se uma mensagem SOAP deve ou no deve ser compactada. Umasimulao foi realizada para determinar a eficincia da heurstica, e os resultados mostraram queela pode ajudar na reduo do tempo de resposta do servio em uma variedade de cenrios. Osresultados obtidos so apresentados em (Estrella et al., 2008a).

Em (Ludwig, 2003) so evidenciados tpicos relacionados as semnticas dos parmetros deQoS (entendimento dos parmetros de QoS pelos usurios e Web Services). Onde as medidasdevem ser realizadas? Rede, Cliente, Servidor de Aplicao? importante considerar os aspectosrelacionados ao desempenho dos sistemas envolvendo Web Services, tais como: gerenciamento dedesempenho, gerenciamento de carga, escalonadores, controle de resposta de sistemas individuais,etc. Tcnicas de avaliao de desempenho no so mostradas, apesar das discusses sobre o temaserem mapeadas adequadamente. Para (Farkas e Charaf, 2003), em geral, o modelo bsico deWeb Services no contm informaes sobre medidas de qualidade. Dentre as desvantagens dessemodelo, os autores citam:

Baixa qualidade;

Pouca confiabilidade;

Tamanho das mensagens XML: necessrio melhorar o desempenho com tcnicas de com-presso de mensagens;

Citam ainda que os fatores de qualidade para a escolha do melhor Web Service devem envolvero tempo de resposta, carga da rede, custo para acessar o melhor servio.

O trabalho proposto em (Chen et al., 2003) destaca uma arquitetura de QoS utilizando umBroker entre clientes, Web Services e provedores de servio. Anlise de desempenho tambm um tema abordado. Alm disso, mostra quais as garantias que as aplicaes precisam possuirquando esto trocando informaes (mensagens). Dentre os componentes de controle de QoSforam citados: poder de processamento do servidor e entrega do servio. De acordo com estudodos autores os parmetros de QoS que podem ser coletados do sistema avaliado, com a vantagemde no apresentar nenhuma interveno do usurio so:

Tempo de resposta;

Custo do servio;

Largura de banda;

Disponibilidade do servio;


Alm das abordagens anteriormente descritas o artigo tambm mostra como classificar os WebServices de acordo com suas funcionalidades, separando-os em grupos de servios. Neste casoos clientes teriam os mesmos critrios de QoS. Apresentam tambm, dois algoritmos de reservasde alocao de recursos para se ter uma qualidade de servio adequada. Apesar das boas dis-cusses em torno do tema de QoS, os autores no sinalizam no artigo como foram realizados ostestes desses algoritmos, isto , em que condies, quais as ferramentas para implementao ousimulao, etc.

Em (Jaeger et al., 2005) tambm so apresentadas tcnicas para composio de Web Servicespor meio de modelos. Por meio de uma ferramenta de simulao so gerados exemplos de com-posies e candidatos de Web Services para avaliar possveis substituies. As caractersticas deQoS tais como custo, disponibilidade, tempo de execuo e reputao tambm so analisadas. Em(Aiello et al., 2009) proposto um algoritmo que, dada a funcionalidade desejada, retorna umacomposio de servios a partir de um repositrio com o timo tempo de resposta ou throughput.Os servios so compostos, levando em considerao uma ontologia de nomes de operaes ex-pressas em Web Ontology Language (OWL). Outra questo abordada em relao aos servios queprecisam ser substitudos em um fluxo composto. Essa preocupao importante, pois, serviosdo fluxo podem falhar e causar degradao na qualidade de servio final. Nesse sentido, em (Yin etal., 2009) proposto uma nova abordagem para os servios substitutos de um fluxo composto. Oservio de destino pode ser substitudo individualmente, ou pode ser substitudo por seus serviosrelacionados na composio como um todo por um servio mais complexo. Desta forma, muitomais opes estaro disponveis para reparar a composio. tambm apresentado um mecanismopara selecionar o servio ideal para a substituio baseada em QoS em duas fases: a pr-seleo eclassificao.

Em (Yu e Lin, 2004), os autores discutem os principais parmetros que devem ser consideradosna proposio de um algoritmo de seleo de servios, isto , aqueles que podem ser coletados sema interveno do usurio. Entre tais parmetros, so citados: custo do servio, tempo de resposta,carga do servidor/provedor, atraso da rede, etc. O artigo tambm destaca especial ateno ao tpicode composio de servios. Para os autores, os Web Services requisitados por um cliente podem serdivididos em duas categorias. Uma delas a dos servios simples, ou seja, quando uma requisiopode ser cumprida por um servio individual. A outra a categoria de servios compostos, para oqual uma requisio deve ser completada por um conjunto de servios individuais (por exemplo,quando um usurio quer fazer um plano de viagem que inclui a seleo do vo, a reserva do hotel, oaluguel do carro, etc). H dois tipos de servios compostos dependendo da quantidade de caminhosde execuo que um servio composto possa ter:

Pipeline Simples: Uma estrutura de servio composto com um nico caminho de execuo;

Estrutura de Grafo: Possui mltiplos caminhos de execuo. O Broker ou o responsvelpela seleo, deve escolher o caminho timo dentre os apresentados.


Em contrapartida, o trabalho de (Liu et al., 2005b) tem como objetivo a apresentao de umplano de composio automtico e dinmico de Web Services. A abordagem de composio deWeb Services, e particularmente como tal composio feita, mostrada segundo o algoritmo aseguir:

Computar uma rede reduzida (de servios);

Encontrar todos os planos de composio para uma sada dada pelo usurio final;

Obter todos os planos de composio para todas as sadas dada pelo usurio final;

Encontrar o plano de composio com qualidade de servio tima.

Os autores ainda consideram como relevantes os atributos de QoS, preo, disponibilidade, con-fiabilidade, durao e reputao. Eles no mencionam se a abordagem foi implementada ou simu-lada. No so apresentados resultados. Em (Estrella et al., 2008b) diversos atributos de qualidadede servico so mapeados para entidades participantes de uma SOA, visando definir como pode seravaliado o desempenho de um Web Service. Pontos como o que deve ser avaliado e a maneiracomo deve ser avaliado em um Web Service, so abordados neste artigo, alm de uma arquiteturautilizada para exemplificar como os atributos de QoS definidos podem ser utilizados no ofereci-mento de Web Services.

O trabalho de (Huang, 2005) mostra um modelo de como formatar e resolver o problema dealocao de capacidade de recursos computacionais para as aplicaes, como um problema deotimizao linear, juntamente com contratos de QoS. O trabalho proposto pelos autores retrataum modelo de redes de fila para a resoluo do problema de capacidade de alocao de recursos.Neste modelo, mquinas so estaes de servios compartilhadas e aplicaes de negcios sofilas associadas com essas estaes. Os jobs so instncias dos processos de negcio. O mtodode alocao de capacidade leva em considerao os seguintes fatores:

Chegadas aleatrias de instncias de processos de negcios;

Flutuaes no tempo de servio das aplicaes de negcios;

Requerimentos de QoS das aplicaes;

Estrutura de composio do processo.

Alm disso, relatam que utilizam distribuies para simular o tempo de servio e tambm entreas chegadas de requisies. O mesmo ocorrendo para aproximaes de trfego pesado. Segundoos autores, cada atividade em um processo de negcios representa um determinado tipo de tarefa aser completada. Para completar um processo de negcios, aplicaes que controlam aplicaes in-dividuais precisam ser requisitadas de forma correta de acordo com a estrutura seqencial (padro


de composio do processo). Para analisar o desempenho de um processo de negcios, saber aestrutura do processo no suficiente; preciso conhecer o desempenho de cada atividade de

WSARCH: Uma arquitetura para a provisão de web services ... fileWSARCH: Uma arquitetura para a...

Documents

Transcript of WSARCH: Uma arquitetura para a provisão de web services ... fileWSARCH: Uma arquitetura para a...