TIAGO LOPES GONC ¸ ALVES
UMA ABORDAGEM PARA APOIO ` A APLICAC ¸ ˜ AO DE ESTUDOS EXPERIMENTAIS EM PROCESSO DE NEG ´ OCIO
MARING ´ A
2009
TIAGO LOPES GONC ¸ ALVES
UMA ABORDAGEM PARA APOIO ` A APLICAC ¸ ˜ AO DE ESTUDOS EXPERIMENTAIS EM PROCESSO DE NEG ´ OCIO
Disserta¸c˜ ao apresentada ao Programa de P´ os-Gradua¸c˜ ao em Ciˆ encia da Computa¸c˜ ao da Universidade Estadual de Maring´ a, como requisito para obten¸c˜ ao do grau de Mestre em Ciˆ encia da Computa¸c˜ ao.
Orientadora: Profa. Dra. Itana Maria de Souza Gimenes
MARING ´ A
2009
G635u Gonçalves, Tiago Lopes
Uma abordagem para apoio à aplicação de estudos experimentais em processo de negócio / Tiago Lopes Gonçalves. -
Maringá: UEM, 2009.
xiii, 82 f. : il. ; 30 cm.
Orientadora: Prof. Dra. Itana Maria de Souza Gimenes Dissertação (Mestrado) – Universidade Estadual de Maringá.
Programa de Pós-Graduação em Ciência da Computação.
Maringá, 2009.
1. Processo de Negócio. 2. Engenharia de Software Experimental. 3.
Serviços Web. 4. Contratos Eletrônicos. I. Gimenes, Itana Maria de Souza, orient. II. Universidade Estadual de Maringá. Programa de Pós- Graduação em Ciência da Computação. III. Titulo.
CDD: 005.1 CDU: 004.41
Agradecimentos
A Jesus Cristo, meu amigo e mestre de toda sabedoria existente.
A minha orientadora pela oportunidade, pela dedica¸c˜ ao e paciˆ encia.
A minha linda, maravilhosa, fant´ astica, carinhosa, dedicada, lutadora e incr´ıvel Fam´ılia (Dozinete, Marta, Tatiane e Tom´ as). Vocˆ es s˜ ao minha for¸ca, minha garra e incentivo para todos os desafios.
A meus tios e tias e tamb´ em meus avˆ os e av´ os pela alegria e ora¸c˜ ao oferecida.
A meus incompar´ aveis amigos: Carla, Franciele, Sandro, Vˆ ania, Graziele, Edilene, Ro- drigo, Danilo, Karina, Viviane, Rafael, Claudia e Cristina.
As m˜ aes Izabel Tessaro, Sˆ onia Tessaro e Sandra Delci pela aten¸c˜ ao e carinho sempre demonstrados.
A minha querida amiga Ana Paula Chaves pelos incr´ıveis e inesquec´ıveis momentos, al´ em da ajuda, for¸ca e incentivo nesse per´ıodo de mestrado.
A meus grandes amigos irm˜ aos Andr´ e Dias Martins e Juliano Pazini, pelo apoio, motiva¸c˜ ao e alegrias.
A meu grande amigo Roberto Pereira, pela amizade, confian¸ca e acolhimento.
A meu amigo Rodrigo Pagno, pelos momentos de distra¸c˜ ao proporcionados por suas hist´ orias e piadas.
A pessoa mais incr´ıvel de todas as secret´ arias dessa universidade, Inˆ es pela paciˆ encia e compreens˜ ao.
A meus amigos participantes do estudo experimental: Jesus, Roberto, Marcelo, Sara, Ana, Vanderson, Mauro, Nelson, Renata, Andr´ e Verona, Andr´ e Dias, Bruno, Francisco e Rog´ erio.
A todos aqueles que aqui n˜ ao foram citados, mas que contribuiram direto ou indiretamente para minha forma¸c˜ ao pessoal e profissional.
A todos aqueles que acreditam no poder do Sonho, que acreditam que podemos mais, que lutam, suam, sofrem, descepcionam-se e choram. Contudo a aqueles que acreditam no imposs´ıvel, almejam, vencem, se alegram, sorriam e comemoram a conquista de um grande e t˜ ao esperado SONHO.
Muito Obrigado!
i
Resumo
Com os avan¸cos e a capacidade da Internet de oferecer recursos mais poderosos e eficientes, ´ e poss´ıvel que organiza¸c˜ oes, mesmo estando fisicamente distribu´ıdas, coo- perem para que disponibilizem seus servi¸cos, bem como consumirem servi¸cos de ou- tras organiza¸c˜ oes de maneira dinˆ amica. Para garantir a qualidade dos servi¸cos en- volvidos nos processos inter-organizacionais s˜ ao estabelecidos contratos eletrˆ onicos.
Um contrato eletrˆ onico ´ e um documento composto de informa¸c˜ oes que regem um processo de neg´ ocio entre organiza¸c˜ oes. Assim como mecanismos e teorias, processos de neg´ ocio precisam ser evidenciados e melhorados. Experimentos em engenharia de software buscam caracterizar, evidenciar, avaliar, prever, controlar e melhorar teorias, processos, produtos e ferramentas de desenvolvimento de soft- ware. Esta disserta¸c˜ ao apresenta uma abordagem para o apoio ` a aplica¸c˜ ao de es- tudos experimentais em processos de neg´ ocio. Esta abordagem ´ e composta por um conjunto de procedimentos e diretrizes para a aplica¸c˜ ao dos experimentos e tamb´ em de um meta-modelo de artefatos de apoio ` a execu¸c˜ ao de experimento que permite armazenar projetos de estudos experimentais, dados e documentos relacionados.
Para a concep¸c˜ ao da proposta, utilizou-se como objeto de estudo a abordagem baseada em caracter´ısticas para o estabelecimento de contratos eletrˆ onicos para servi¸cos Web. Os experimentos serviram como meio de explicitar os elementos da abordagem proposta. Um experimento com participantes do meio acadˆ emico sobre a abrangˆ encia de estudos in-vitro e outro estudo por meio de uma pesquisa de opini˜ ao com participantes que trabalham em empresas de desenvolvimento de software e implementa¸c˜ ao de servi¸cos da cidade de Maring´ a e Dois Vizinhos. Ap´ os a coleta dos dados, a an´ alise foi realizada a fim de identificar a influˆ encia da experiˆ encia ou inexperiˆ encia dos participantes no uso da abordagem como objeto de estudo. As contribui¸c˜ oes apresentadas por este trabalho s˜ ao: (i) a avalia¸c˜ ao da abordagem baseada em caracter´ısticas para o estabelecimento de contratos eletrˆ onicos para servi¸cos Web; (ii) a concep¸c˜ ao de uma abordagem para o apoio
`
a aplica¸c˜ ao de estudos experimentais em processo de neg´ ocio com procedimentos e diretrizes para aplica¸c˜ ao de experimentos;(iii) um meta-modelo de artefatos de apoio ` a execu¸c˜ ao de experimentos, que contribuir´ a com uma s´ erie de artefatos devidamente armazenados e descritos para facilitar as experimenta¸c˜ oes futuras e;
(iv) o estabelecimento de uma vis˜ ao do planejamento e execu¸c˜ ao de experimentos em processo de neg´ ocio.
iii
Abstract
With the advances of the Internet and the ability to offer the most powerful and efficient, it is possible that organizations, even though they are physically distributed, cooperate to provide and consume services of other organizations dynamically. To ensure the quality of the services involved in inter-organizational process, electronic contracts are established. An electronic contract is a document composed of information that govern a business process between organizations. As mechanisms and theories, business processes need to be highlighted and impro- ved. Experiments in software engineering seek characterize, demonstrate, assess, predict, monitor and improve theories, processes, products and development tools software. This dissertation presents an approach to give support to the application of experimental studies in business processes. This approach is composed of procedures and guidelines for application of experiments and also a meta-model of artifacts to support the implementation of experiments that can store experimental studies, data and documents related. For the development of the proposal design, was used as objects of study the approach based on feature for the establishment of electronic contracts for Web services. Two experiments were performed and served as a means to ilustrate the elements of the proposed approach. An experiment with participants from academic on the scope of studies in vitro, and another experi- ment by an opinion search with participants who work in companies of software development and implementation services in Maring´ a and Dois Vizinhos. After data collection, the analysis was performed to identify the influence of experience or inexperience of the participants in the use of the approach used as the object of study. The contributions of this work are: (i) the evaluation of the feature-based approach to the establishment of electronic contracts for Web services, (ii) to design an approach to support the application of experimental studies in business process with procedures and guidelines for implementation of experiments, (iii) a meta-model of artifacts to support the implementation of experiments that will contribute to a number of artifacts stored properly and described to facilitate future experiments and (iii) the establishment of a view for the planning and execution of experiments in business process.
v
Sum´ ario
Lista de Figuras ix
Lista de Tabelas xi
1 Introdu¸ c˜ ao 1
2 Processo de Neg´ ocio e Servi¸ cos Web 5
2.1 Considera¸c˜ oes Iniciais . . . . 5
2.2 Tecnologias de Servi¸cos Web . . . . 5
2.2.1 SOAP . . . . 8
2.2.2 WSDL . . . . 8
2.2.3 UDDI . . . . 10
2.3 Processo de Neg´ ocio . . . . 11
2.4 Contratos Eletrˆ onicos . . . . 13
2.4.1 Uma abordagem baseada em caracter´ısticas para o estabelecimento de contratos eletrˆ onicos para servi¸cos web . . . . 15
2.4.2 Exemplos: configura¸c˜ ao de caracter´ısticas e contrato eletrˆ onico . . . 20
2.5 Projeto InfraPro . . . . 20
2.6 Considera¸c˜ oes Finais . . . . 23
3 Engenharia de Software Experimental 25 3.1 Considera¸c˜ oes Iniciais . . . . 25
3.2 Experimenta¸c˜ ao em Engenharia de Software . . . . 26
3.3 Conceitos Relacionados ` a Experimenta¸c˜ ao . . . . 28
3.4 M´ etodos de Pesquisa em Engenharia de Software . . . . 30
3.4.1 Abordagens para Execu¸c˜ ao de Estudos Emp´ıricos . . . . 31
3.4.2 Estrat´ egias para investiga¸c˜ ao de estudos emp´ıricos . . . . 32
3.5 Plano Experimental . . . . 33
3.6 Considera¸c˜ oes Finais . . . . 34
4 Experimentos Realizados 37 4.1 Considera¸c˜ oes Iniciais . . . . 37
4.2 Vis˜ ao Geral dos Experimentos . . . . 38
4.3 Defini¸c˜ ao do Experimento I . . . . 39
4.4 Defini¸c˜ ao do Experimento II . . . . 44
4.5 An´ alise dos Resultados - Experimento I . . . . 45
vii
4.7 Considera¸c˜ oes Finais . . . . 55
5 Procedimentos e diretrizes da abordagem proposta 59 5.1 Considera¸c˜ oes Iniciais . . . . 59
5.2 Vis˜ ao Geral da Abordagem . . . . 60
5.2.1 Descri¸c˜ ao do Conjunto de Procedimentos e diretrizes para Experi- menta¸c˜ ao . . . . 61
5.2.2 Artefatos Gerados pela abordagem . . . . 63
5.3 Infraestrutura de apoio a processo de neg´ ocio . . . . 64
5.4 Considera¸c˜ oes Finais . . . . 66
6 Conclus˜ oes 69
Referˆ encias Bibliogr´ aficas 73
A Q1 - Question´ ario de Experiˆ encia 77
B Q2 - Question´ ario de Dificuldades - Acadˆ emicos 79 C Q3 - Question´ ario de Dificuldades - Empres´ arios 81
viii
Lista de Figuras
2.1 Pap´ eis dos componentes de SOA . . . . 7
2.2 Representa¸c˜ ao do documento WSDL . . . . 9
2.3 Estrutura de uma aplica¸c˜ ao baseada em processo de neg´ ocio . . . . 11
2.4 Ciclo de vida de gerˆ encia de processo de neg´ ocio . . . . 12
2.5 Processo de estabelecimento de contratos eletrˆ onicos com base em carac- ter´ısticas . . . . 16
2.6 Exemplo de modelo de caracter´ıstica e suas associa¸c˜ oes . . . . 17
2.7 Relacionamento entre os artefatos produzidos pelo processo . . . . 18
2.8 Meta-modelo para o estabelecimento de contratos eletrˆ onicos . . . . 19
2.9 Parte de uma configura¸c˜ ao de modelo de caracter´ıstica para servi¸cos eletrˆ onicos 21 2.10 Parte de exemplo de contrato eletrˆ onico . . . . 22
3.1 Processo de Experimenta¸c˜ ao . . . . 30
4.1 Grupo de servi¸cos Web modelados e utilizados para o experimento . . . . 39
4.2 Experiˆ encia dos participantes . . . . 46
4.3 A quem a abordagem ´ e vantajosa . . . . 50
4.4 Experiˆ encia - Empres´ arios . . . . 51
4.5 Experimento - Empresas . . . . 54
4.6 A quem a abordagem ´ e vantajosa . . . . 55
5.1 Processo de apoio a execu¸c˜ ao de experimentos em processo de neg´ ocio . . . 61
5.2 Relacionamento entre os artefatos gerados pelo processo . . . . 63
5.3 Arquitetura do conjunto de ferramentas FeatureContract . . . . 65
5.4 Meta-modelo de artefatos para apoio a execu¸c˜ ao de experimentos . . . . . 66
ix
Lista de Tabelas
4.1 Dados da Experiˆ encia dos Participantes . . . . 45
4.2 Dados dos participantes do Estudo Experimental - I . . . . 47
4.3 Frequˆ encias observadas - Suficiˆ encia do Treinamento . . . . 48
4.4 Frequˆ encias observadas - Apresentaram dificuldades quanto a nova abor- dagem . . . . 48
4.5 Frequˆ encias observadas - Julgaram a abordagem ser vantajosa . . . . 49
4.6 Dados da Experiˆ encia dos Participantes - Empres´ arios . . . . 51
4.7 Dados dos participantes do experimento - Empres´ arios . . . . 52
4.8 Frequˆ encias observadas - Encorajaria a utiliza¸c˜ ao . . . . 54
A.1 Grau de Experiˆ encia do Participante . . . . 78
xi
Lista de Siglas
BPEL: Business Process Execution Language - (Linguagem de Execu¸c˜ ao de Processo de Neg´ ocio)
BPM: Business Process Management - (Gerenciamento de Processo de Neg´ ocio)
BPMS: Business Process Management System - (Sistema de Gerenciamento de Processo de Neg´ ocio)
COS: Computer Oriented Service - (Computa¸c˜ ao Orientada a Servi¸co)
FORM: Feature Oriented Reuse Method - (M´ etodo de Reusabilidade Orientado a Carac- ter´ısticas)
HTTP: HyperText Transfer Prtocol - (Protocolo de Transferˆ encia de Hipertexto) QoS: Quality of Service - (Qualidade de Servi¸co)
GQM: Goal Question Metric - (Objetivo, Pergunta, M´ etrica)
SOA: Service Oriented Arquitecture - (Arquitetura Orientada a Servi¸co)
SOAP: Simple Object Access Protocol - (Protocolo de Acesso Simples ao Objeto)
UDDI: Universal Description, Discovery and Integration (Descri¸c˜ ao, Descobrimento e Integra¸c˜ ao Universal)
WS-Agreement: Web Services Agreement Specification - (Especifica¸c˜ ao de Acordos de Servi¸cos Web)
WSDL: Web Services Description Language - (Linguagem de Descri¸c˜ ao de Servi¸cos Web) WS-BPEL: Web Service - Business Process Execution Language - (Linguagem de Execu¸c˜ ao de Processo de Neg´ ocio para Servi¸cos Web)
WSFL: Web Service Flow Language - (Linguagem de Fluxo de Servi¸cos Web) XML: eXtendible Markup Language - (Linguagem de Marca¸c˜ ao Extensiva) XLANG: X Language - (Linguagem X)
WSAG: Web Service Agreement - (Acordo de Servi¸cos Web) XSD: XML Schema Definitions - (Defini¸c˜ oes de Esquemas XML)
xiii
Cap´ıtulo
1
Introdu¸ c˜ ao
Com os avan¸cos e a capacidade da Internet de oferecer recursos mais poderosos e eficientes,
´
e poss´ıvel que organiza¸c˜ oes, mesmo estando fisicamente distribu´ıdas, cooperem para que disponibilizem seus servi¸cos, bem como consumirem servi¸cos de outras organiza¸c˜ oes de maneira dinˆ amica. Linguagens de representa¸c˜ ao de processos de neg´ ocios permitem que a composi¸c˜ ao de servi¸cos inter-organizacionais seja formalizada. Para garantir a qualidade dos servi¸cos envolvidos nos processos inter-organizacionais s˜ ao estabelecidos contratos eletrˆ onicos. Um contrato eletrˆ onico ´ e um documento composto de informa¸c˜ oes que regem um processo de neg´ ocio entre organiza¸c˜ oes.
Assim como mecanismos e teorias, processos de neg´ ocio precisam ser evidenciados e melhorados. No entanto, existe uma carˆ encia por pesquisas que apliquem t´ ecnicas de engenharia de software experimental em processos de neg´ ocio. ´ E necess´ ario que se tenha procedimentos, diretrizes, artefatos, documentos, estudos relacionados armazenados, e ferramentas que auxiliem a aplica¸c˜ ao de estudos experimentais em processos de neg´ ocio.
Experimentos em engenharia de software buscam caracterizar, evidenciar, avaliar, prever, controlar e melhorar teorias, processos, produtos e ferramentas de desenvolvimento de software (Basili et al., 1986). Por meio de um plano experimental, os experimentos s˜ ao aplicados para evidenciar quantitativamente ou qualitativamente a credibilidade e a confiabilidade dos resultados do estudo.
A importˆ ancia de experimentos e medi¸c˜ ao para a evolu¸c˜ ao da ciˆ encia tem sido discutida na comunidade cient´ıfica de computa¸c˜ ao (Fabbri, 2006), (Basili, 2006) e (Tichy, 1998).
Evidenciar a veracidade e a precis˜ ao das id´ eias ´ e um requisito para o progresso de qualquer
1
disciplina. Por esse motivo, existe uma crescente conscientiza¸c˜ ao na comunidade de engenharia de software de que estudos experimentais s˜ ao indispens´ aveis para desenvolver e melhorar processos, m´ etodos e ferramentas.
Fantinato (2007) propos uma abordagem baseada em caracter´ısticas para o estabe- lecimento de contratos eletrˆ onicos para servi¸cos Web. Esta abordagem ´ e utilizada no InfraPro
1(Gimenes, 2006). Neste projeto s˜ ao propostas t´ ecnicas e ferramentas de apoio ao gerenciamento de processos de neg´ ocio baseadas nos conceitos de linha de produto e aspectos. Assim, faz-se necess´ ario uma abordagem para avaliar as t´ ecnicas e ferramentas propostas de modo que os artefatos e diretrizes para realiza¸c˜ ao de experimentos fiquem ar- mazenados e possam ser explorados pelos participantes do projeto ou pessoas interessadas em repetir os experimentos. Este trabalho de mestrado prop˜ oe o desenvolvimento de uma abordagem para apoiar a aplica¸c˜ ao de estudos experimentais em processo de neg´ ocio, e em particular estuda-se o processo de estabelecimento de contratos eletrˆ onicos. Para apoiar a concep¸c˜ ao da abordagem experimental foram realizados experimentos que utilizam como objeto de estudo a abordagem baseada em caracter´ıstica para o estabelecimento de contratos eletrˆ onicos para servi¸cos Web.
O projeto InfraPro tem como objetivo desenvolver modelos e mecanismos para a forma¸c˜ ao de uma infraestrutura de apoio ` a modelagem e execu¸c˜ ao de processos de neg´ ocio baseada nos conceitos de reutiliza¸c˜ ao, no paradigma de orienta¸c˜ ao a aspectos e na tecno- logia de servi¸cos Web. Este trabalho de mestrado est´ a no contexto do projeto InfraPro para estabelecer mecanismos para a realiza¸c˜ ao de estudos experimentais.
A abordagem proposta ´ e composta de um conjunto de procedimentos e diretrizes para aplica¸c˜ ao de experimentos em processo de neg´ ocio e um meta-modelo de artefatos de apoio
`
a execu¸c˜ ao de experimentos que permitam armazenar projetos de estudos experimentais, dados e documentos relacionados aos estudos realizados. Para conceber os elementos da abordagem foram realizados dois experimentos, um em ambiente acadˆ emico e o outro em ambiente empresarial. O experimento em ambiente acadˆ emico teve a participa¸c˜ ao de 15 (quinze) pessoas e o empresarial 8 (oito) pessoas. No ambiente acadˆ emico, os participantes respondiam o question´ ario que revelava sua experiˆ encia e depois representavam o papel de estabelecedores de contratos eletrˆ onicos selecionando as caracter´ısticas que desejavam para o contrato eletrˆ onico que estavam formalizando. Ap´ os isso, respondiam o question´ ario para expressar suas dificuldades sobre a abordagem. Para o segundo experimento, os participantes empres´ arios respondiam o question´ ario que revelava a experiˆ encia sobre os assuntos abordados e recebiam uma explana¸c˜ ao da abordagem auxiliada por um docu- mento que apresentava a abordagem com exemplos de aplica¸c˜ ao, vantagens e limita¸c˜ oes.
1Infraestrutura de apoio a Processos de Neg´ocio baseado em Reutiliza¸c˜ao e Aspectos
3 Ap´ os isso, os participantes respondiam um terceiro question´ ario que buscava identificar o
“feedback” dos participantes em uma futura utiliza¸c˜ ao da abordagem.
As contribui¸c˜ oes apresentadas por este trabalho s˜ ao: (i) a avalia¸c˜ ao da abordagem baseada em caracter´ısticas para o estabelecimento de contratos eletrˆ onicos para servi¸cos Web; (ii) a concep¸c˜ ao de uma abordagem para o apoio ` a aplica¸c˜ ao de estudos experi- mentais em processo de neg´ ocio com procedimentos e diretrizes para aplica¸c˜ ao de expe- rimentos; (iii) um meta-modelo de artefatos de apoio ` a execu¸c˜ ao de experimentos, que contribuir´ a com uma s´ erie de artefatos devidamente armazenados e descritos para facilitar as experimenta¸c˜ oes futuras e; (iv) o estabelecimento de uma vis˜ ao do planejamento e execu¸c˜ ao de experimentos em processo de neg´ ocio.
Esta disserta¸c˜ ao est´ a organizada em 5 (cinco) cap´ıtulos. O Cap´ıtulo 2 apresenta uma
contextualiza¸c˜ ao do assunto deste trabalho, os quais incluem: tecnologias de servi¸cos
Web, detalhando aspectos relacionados a protocolos e linguagens de especifica¸c˜ ao de
servi¸cos Web, processos de neg´ ocio, contratos eletrˆ onicos, e a abordagem desenvolvida por
Fantinato (2007). No Cap´ıtulo 3 descrevem-se os principais conceitos de engenharia de
software experimental, processo de experimenta¸c˜ ao, m´ etodos e classifica¸c˜ oes de pesquisa
experimental. O Capitulo 4 apresenta os experimentos realizados, a an´ alise dos dados e as
li¸c˜ oes aprendidas. A partir dos experimentos realizados, os procedimentos e diretrizes da
abordagem s˜ ao descritos pelo Cap´ıtulo 5. No Cap´ıtulo 6 s˜ ao apresentadas as conclus˜ oes
finais deste trabalho,as contribui¸c˜ oes da abordagem e os trabalhos futuros.
Cap´ıtulo
2
Processo de Neg´ ocio e Servi¸ cos Web
2.1 Considera¸ c˜ oes Iniciais
Visto que o objetivo deste trabalho ´ e conceber uma abordagem para o apoio ` a aplica¸c˜ ao de estudos experimentais em processo de neg´ ocio, e ainda, que um processo de neg´ ocio ´ e composto por servi¸cos Web, introduz-se neste cap´ıtulo os conceitos b´ asicos relacionados a esses assuntos. Inicialmente, na Se¸c˜ ao 2.2 uma revis˜ ao sobre tecnologias de servi¸cos Web
´
e apresentada. Em seguida, na Se¸c˜ ao 2.3 s˜ ao abordados conceitos que envolvem processo de neg´ ocio e seu relacionamento com servi¸cos Web. Uma descri¸c˜ ao sobre contratos eletrˆ onicos ´ e realizada na Se¸c˜ ao 2.4. Nesta se¸c˜ ao tamb´ em ´ e apresentada a abordagem baseada em caracter´ısticas para o estabelecimento de contratos eletrˆ onicos para servi¸cos Web, discutindo seu funcionamento vantagens e limita¸c˜ oes, que ´ e o foco principal dos experimentos realizados. Na Se¸c˜ ao 2.5 ´ e apresentado o contexto desse trabalho com o projeto InfraPro. A Se¸c˜ ao 2.6 faz as considera¸c˜ oes finais deste cap´ıtulo.
2.2 Tecnologias de Servi¸ cos Web
Com o crescimento da Internet, as intera¸c˜ oes humanas passaram a ser apoiadas com dados textuais e gr´ aficos. As pessoas utilizam a Internet diariamente para comprar bens de consumo, ler not´ıcias e outros. Este n´ıvel de intera¸c˜ ao ´ e adequado para mui- tos prop´ ositos, entretanto, p´ aginas textuais est´ aticas n˜ ao oferecem apoio suficiente ` a aplica¸c˜ oes na Internet. A transmiss˜ ao de grandes quantidades de dados de forma eficiente
5
tornou poss´ıvel a comunica¸c˜ ao entre organiza¸c˜ oes de maneira mais r´ apida, mais produtiva e barata (Newcomer, 2002). As aplica¸c˜ oes passaram a ser disponibilizadas por meio de servi¸cos, e suas intera¸c˜ oes realizadas por meio de mensagens XML sobre protocolos baseados na Internet, construindo o conceito de COS (Computa¸c˜ ao orientada a servi¸cos)
1. Leymann et al. (2002) definem servi¸cos como sendo componentes de software auto - descritivos que apoiam a composi¸c˜ ao ´ agil de aplica¸c˜ oes. Cada servi¸co pode realizar uma ou mais fun¸c˜ oes relacionadas ao neg´ ocio. Dessa forma, mesmo em locais fisicamente distribu´ıdos com plataformas diferentes, ´ e poss´ıvel que organiza¸c˜ oes disponibilizem suas aplica¸c˜ oes como servi¸cos e, tamb´ em, consumam servi¸cos de outras. Um tipo de Servi¸co que possibilita a intera¸c˜ ao entre aplica¸c˜ oes semelhantes a outros mecanismos de apoio aos sistemas distribu´ıdos como CORBA
2e RMI
3´ e o servi¸co Web. Um servi¸co Web
´
e um m´ odulo de software auto-descritivo dispon´ıvel por meio de uma rede, como a Internet, que completa suas atribui¸c˜ oes ou realiza opera¸c˜ oes em nome de um usu´ ario ou de uma aplica¸c˜ ao (Papazoglou, 2008). Servi¸cos Web fazem parte de uma infraestrutura de computadores distribu´ıdos com m´ odulos de software tentando se comunicar sobre uma determinada rede a fim de formar um ´ unico sistema l´ ogico. Os m´ odulos de software s˜ ao identificados por uma URL na Internet e suas interfaces definidas e descritas em artefatos XML (Alonso et al., 2004). Servi¸cos Web est˜ ao alterando radicalmente as regras do Web Commerce, tornando-se poss´ıvel a conex˜ ao de sistemas de diferentes organiza¸c˜ oes. Para tanto, algumas modifica¸c˜ oes no uso de tecnologias correntes foram necess´ arias, a saber:
(i) a substitui¸c˜ ao do uso do protocolo HTML
4pelo protocolo XML; (ii) servidor Web por uma m´ aquina SOAP e; (iii) usu´ ario por um programa que realize e gerencie as trocas de mensagens.
Servi¸cos s˜ ao estruturados de acordo com a arquitetura SOA
5que ´ e uma abordagem baseada em padr˜ oes compostos e disponibilizados por diferentes pacotes de software para a gest˜ ao de reutiliza¸c˜ ao e reconfigura¸c˜ ao(Benatallah e Nezhad, 2005). A SOA tem a fun¸c˜ ao de permitir a interoperabilidade entre as tecnologias existentes e aos futuros efeitos de extensibilidade sobre arquiteturas (Papazoglou, 2008). SOA permite que sitemas de componentes monol´ıticos e est´ aticos tornem-se sistemas modulares e componentes flex´ıveis representados como servi¸cos que podem ser solicitados por protocolos padr˜ ao de Internet.
De acordo com Chaudhary et al. (2003) e Medeiros et al. (2007), os componentes de SOA podem desempenhar um ou mais dos seguintes pap´ eis representados pela Figura 2.1.
1Do InglˆesComputer Oriented Service
2Do InglˆesCommon Object Request Broker Architecture
3Do InglˆesRemote Method Invocation
4Do inglˆes Hyper Text Markup Languague
5Do InglˆesService Oriented Architecture
2.2 Tecnologias de Servi¸cos Web 7
Figura 2.1: Pap´ eis dos componentes de SOA (Medeiros et al., 2007)
Para melhor compreens˜ ao desses pap´ eis, procede-se ` a descri¸c˜ ao de cada item:
• provedor do servi¸ co: publica o servi¸co disponibilizando um ponto de acesso em sua localiza¸c˜ ao;
• reposit´ orio do servi¸ co: entidade que anuncia e descreve os servi¸cos dispon´ıveis nos provedores;
• consumidor do servi¸ co: entidade que procura um servi¸co no diret´ orio. Ap´ os encontrar, usa-o em seu respectivo provedor;
• agregador do servi¸ co: faz a composi¸c˜ ao de v´ arios servi¸cos em um ´ unico novo servi¸co;
Em rela¸c˜ ao a servi¸cos web, XML oferece o formato da descri¸c˜ ao, do armazenamento e tamb´ em da transmiss˜ ao de dados trocados entre os servi¸cos. A sintaxe do XML especifica como o dado ´ e representado, como ´ e definido e com que qualidade de servi¸co
´
e transmitido, al´ em de detalhar como os servi¸cos s˜ ao publicados e descobertos. Em seu
livro Undertanding Web Services, Newcomer (2002) afirma que existem duas grandes
categorias de uso de XML em Web Service, s˜ ao elas: a primeira focada no formato e na
representa¸c˜ ao de armazenamento de dados, e a segunda na especifica¸c˜ ao do software que
manipula os dados. Apesar de ter originado como uma linguagem de marca¸c˜ ao de texto,
a XML tornou-se amplamente utilizada para manipula¸c˜ ao e formata¸c˜ ao dos dados. As
subse¸c˜ oes seguintes apresentam uma descri¸c˜ ao dos padr˜ oes de servi¸co Web que realizados
com o uso de XML.
2.2.1 SOAP
SOAP
6´ e o protocolo baseado em XML respons´ avel pela comunica¸c˜ ao entre servi¸cos de ambientes distribu´ıdos que utilizam servi¸cos Web. O SOAP oferece um formato de mensagem comum para troca de dados entre clientes e servi¸cos, defini caracter´ısticas b´ asicas como: (i) o formato da mensagem para a comunica¸c˜ ao, descrevendo como a informa¸c˜ ao pode ser empacotada em um documento XML; (ii) um conjunto de regras para o uso de mensagens SOAP, bem como definir como os clientes podem invocar procedimentos remotos enviando uma mensagem SOAP; (iii) a forma como os servi¸cos podem responder enviando outra mensagem SOAP ao chamador; (iv) defini¸c˜ ao de um conjunto de regras que qualquer entidade que processa uma mensagem SOAP deve seguir, definindo em particular os elementos XML que uma entidade deve ler e entender, al´ em das a¸c˜ oes que essas entidades devem realizar se n˜ ao entenderem o conte´ udo.
2.2.2 WSDL
WSDL
7´ e a linguagem de descri¸c˜ ao de servi¸cos Web que utiliza XML como base. Esta linguagem tem a fun¸c˜ ao de divulgar informa¸c˜ oes detalhadas que descrevem como o cliente pode utilizar o servi¸co Web. As descri¸c˜ oes em WSDL representam as funcionalidades do servi¸co (Alonso et al., 2004), incluindo detalhes da interface, indicando os m´ etodos dispon´ıveis, e os valores retornados. A finalidade de uma descri¸c˜ ao em WSDL ´ e permi- tir ao consumidor conhecer, primeiramente, os servi¸cos para depois utiliz´ a-lo de forma autom´ atica, sem a necessidade de interven¸c˜ ao ou contato com o autor do servi¸co. Para utilizar os servi¸cos, no m´ınimo deve ser conhecida as informa¸c˜ oes como a localiza¸c˜ ao e o protocolo a ser usado para enviar a invoca¸c˜ ao. Essas informa¸c˜ oes comp˜ oe um documento WSDL e est˜ ao divididos nos trˆ es principais elementos, relacionados a seguir Newcomer (2002):
• defini¸ c˜ oes do tipo de dados: determina a estrutura e o conte´ udo de uma men- sagem;
• opera¸ c˜ oes abstratas: determina as opera¸c˜ oes executadas sobre o conte´ udo da mensagem e;
• elementos bindings : determina como a rede de transmiss˜ ao ir´ a levar a mensagem ao seu destino.
6Do InglˆesSimple Object Access Protocol
7Do InglˆesWeb Service Description Language
2.2 Tecnologias de Servi¸cos Web 9 Um documento WSDL ´ e representado pela Figura 2.2
Figura 2.2: Representa¸c˜ ao do documento WSDL (Abinader e Lins, 2006)
A descri¸c˜ ao de um servi¸co precisa ser disponibilizada para ser usada por diferentes plataformas e linguagens. Sendo assim, para melhor entender a representa¸c˜ ao da Figura 2.2, considere que a organiza¸c˜ ao das informa¸c˜ oes est´ a em duas se¸c˜ oes: descri¸c˜ ao abstrata e descri¸c˜ ao concreta. A parte de descri¸c˜ ao abstrata ´ e composta por quatro elementos:
os elementos types que cont´ em tipos e defini¸c˜ oes independentes de linguagem e plata- forma; elementos messages compostos pelos parˆ ametros de entrada e sa´ıda para o servi¸co, descrevendo tamb´ em as diferentes mensagens trocadas pelo servi¸co; elemento operations, respons´ avel pela intera¸c˜ ao particular com o servi¸co, descrevendo tamb´ em as mensagens de entrada, sa´ıda e exce¸c˜ oes poss´ıveis que s˜ ao permitidas durante a intera¸c˜ ao e; o elemento portTypes respons´ avel por usar a se¸c˜ ao de mensagem para descrever as fun¸c˜ oes oferecidas e os, m´ etodos disponibilizados pelos sevi¸cos.
Em rela¸c˜ ao ` a descri¸c˜ ao concreta, seu papel ´ e definir a especifica¸c˜ ao de implementa¸c˜ ao
para os servi¸cos Web. Conforme apresentado na Figura 2.2, a descri¸c˜ ao concreta conta
com dois elementos XML significantes: elementos bindings que definem como o servi¸co
ser´ a acessado na rede e por meio de qual protocolo e; elemento services indicando por exemplo, onde o servi¸co est´ a localizado para acesso, isto ´ e, o endere¸co do servi¸co na rede.
2.2.3 UDDI
Depois que os dados dos servi¸cos foram definidos e descritos em XML e WSDL respecti- vamente, ser´ a identificado o meio de envio e recebimento dessas mensagens por meio do protocolo SOAP. Assim se faz necess´ ario publicar o servi¸co que a organiza¸c˜ ao oferecer´ a e encontrar os servi¸cos que outras oferecer˜ ao. O UDDI
8´ e um framework que define um modelo de dados em XML e SOAP para que APIs
9registrem e descubram informa¸c˜ oes de servi¸cos Web (Newcomer, 2002). O UDDI ´ e considerado um diret´ orio que registra e publica as defini¸c˜ oes dos servi¸cos na Internet. Baseado em XML, esse diret´ orio oferece uma infra-estrutura para integrar e compartilhar informa¸c˜ oes sobre a localiza¸c˜ ao e uso dos servi¸cos Web por meio de registros. Este registro ´ e respons´ avel por fornecer informa¸c˜ oes sobre neg´ ocios, dados da organiza¸c˜ ao e dos servi¸cos que ela oferece, al´ em de informa¸c˜ oes como nome do servi¸co, descri¸c˜ ao das funcionalidades, localiza¸c˜ ao e descri¸c˜ ao da interface para seu uso.
Todos os trˆ es recursos b´ asicos da tecnologia de servi¸cos Web aqui explicados, s˜ ao de- senvolvidos baseados em XML. Por ser uma meta-linguagem, permite a defini¸c˜ ao de outras linguagens aplic´ aves a dom´ınios de neg´ ocio espec´ıficos. As propriedades dos marcadores XML permitem que a representa¸c˜ ao seja realizada de forma neutra, o que possibilita seu uso por diferentes plataformas e fabricantes. Dentre os recursos que XML fornece, Moultis e Kirk (2000) citam:
• uma linguagem extens´ıvel que fornece a capacidade de definir suas pr´ oprias marcas e atributos. Esses elementos com suas marcas de in´ıcio e fim, junto a seus atributos, estabelecem a estrutura do documento;
• a capacidade de aninhar estruturas de documentos dentro de estruturas de outros, a fim de criar outros documentos mais complexos e;
• a capacidade de validar a estrutura de documentos durante o processamento.
Na pr´ oxima Se¸c˜ ao (2.3), s˜ ao abordados conceitos fundamentais sobre processo de neg´ ocio e como servi¸cos web est˜ ao engajados nestes conceitos.
8Do inglˆesUniversal Distribution, Discovery, and Interoperability
9Do InglˆesApplication Programming Interfaces
2.3 Processo de Neg´ ocio 11
2.3 Processo de Neg´ ocio
Um Processo de neg´ ocio consiste em um conjunto de atividades que s˜ ao executadas de forma coordenada em um ambiente t´ ecnico e organizacional para atingir um objetivo de neg´ ocio (Weske, 2007). Cada processo de neg´ ocio ´ e publicado em uma ´ unica organiza¸c˜ ao que visa interagir com processos de neg´ ocio realizado por outras.
A Figura 2.3 mostra o funcionamento de um processo de neg´ ocio, representado por um conjunto de 5 (cinco) atividades. A atividade 1 (um) representada por uma aplica¸c˜ ao Java est´ a conectada ` a atividade 2 (dois) representada por um sistema legado. A atividade trˆ es (3) representa um outro processo. Ao t´ ermino da execu¸c˜ ao da atividade 1 (um), as atividades 2 (dois) e 3 (trˆ es) podem ser executadas em paralelo ou apenas uma de cada vez, considerando a condi¸c˜ ao estabelecida nos conectores. O fluxo do processo esperar´ a na atividade 4 (quatro) por uma decis˜ ao humana para executar a atividade 5 (cinco) (Sadtler e Kovari, 2004). Desta forma, nota-se que uma aplica¸c˜ ao baseada em processo de neg´ ocio
´
e composta por processos de neg´ ocio e aplica¸c˜ oes que ele invoca.
Figura 2.3: Estrutura de uma aplica¸c˜ ao baseada em processo de neg´ ocio (Sadtler e Kovari, 2004)
Tendˆ encias de mercado como a intera¸c˜ ao entre aplica¸c˜ oes de diferentes organiza¸c˜ oes,
permitem a reciprocidade entre processos de neg´ ocio tanto dentro de uma organiza¸c˜ ao
quanto entre outras organiza¸c˜ oes. Desse modo, o conceito de processos de neg´ ocio inte-
rorganizacionais ´ e formalizado e realizado por duas ou mais partes, cruzando as fronteiras
organizacionais e caracterizados pela heterogeneidade dos ambientes.
O gerenciamento de processo de neg´ ocio (BPM
10) inclui conceitos, m´ etodos e t´ ecnicas para apoiar o projeto, administra¸c˜ ao, configura¸c˜ ao, publica¸c˜ ao e an´ alise dos processos de neg´ ocio (Weske, 2007).
Karagiannis (1995) explica que para a gerˆ encia de processos de neg´ ocio, ´ e necess´ ario um sistema de gerenciamento de processo de neg´ ocio (BPMS)
11. Os BPMS oferecem automatiza¸c˜ ao de processos caracterizados pelo alto grau de estrutura¸c˜ ao e atividades com um alto grau de automatiza¸c˜ ao.
A Figura 2.4 apresenta o ciclo de vida para a automatiza¸c˜ ao de processo de neg´ ocio.
Realiza-se primeiro a defini¸c˜ ao do processo de automatiza¸c˜ ao (projeto). Em seguida, esta defini¸c˜ ao ´ e registrada em um sistema de gerenciamento de processos de neg´ ocio (configura¸c˜ ao da automatiza¸c˜ ao). Para a execu¸c˜ ao do processo, ´ e necess´ ario criar uma instˆ ancia, coordenando e registrando (realizando a execu¸c˜ ao). Ap´ os a execu¸c˜ ao desse processo, o diagn´ ostico ´ e apresentado baseado na an´ alise dos resultados a fim de gerar um processo de neg´ ocio mais aprimorado (Garcia, 2007).
Figura 2.4: Ciclo de vida de gerˆ encia de processo de neg´ ocio (Garcia, 2007)
Conforme discutido na Se¸c˜ ao 2.2, a concep¸c˜ ao de servi¸cos est´ a baseada na SOA.
Desta forma, ´ e oferecida uma estrutura para acessar servi¸cos e integrar processos de neg´ ocio compostos pela execu¸c˜ ao dos servi¸cos. Nessa abordagem de processos de neg´ ocio baseados em servi¸cos Web, cada processo de neg´ ocio inclue atividades que representam servi¸cos providos por parceiros de neg´ ocio. Durante a execu¸c˜ ao do BPM, as atividades s˜ ao realizadas por servi¸cos web e s˜ ao selecionadas de reposit´ orios de servi¸cos.
Algumas propostas de linguagens de especifica¸c˜ ao de processos de neg´ ocio que permi- tem a composi¸c˜ ao de servi¸cos web s˜ ao conhecidas. A WSFL da IBM (Leymann, 2001)
10Do inglˆesBusiness Process Management
11Do inglˆesBusiness Process Management System
2.4 Contratos Eletrˆ onicos 13 e a XLANG da Microsoft (Thatte, 2001). Ambas linguagens originaram a BPEL4WS, comumente conhecida como WS-BPEL (Jordan e Evdemon, 2007). WS-BPEL permite a especifica¸c˜ ao de aplica¸c˜ oes que utilizam servi¸cos web, e tamb´ em que uma aplica¸c˜ ao seja especificada como um servi¸co web devido ao fato de que, em WS-BPEL um processo de neg´ ocio ´ e publicado em forma de servi¸co web, inclusive com seu pr´ oprio descritor WSDL.
WS-BPEL ´ e a linguagem mais usada atualmente e possui os seguintes componentes b´ asicos, a saber (Jordan e Evdemon, 2007):
• tipos de dados: XSD
12define os tipos de dados que podem ser usados no processo;
• entrada e sa´ıdas: WSDL descritor dos servi¸cos web utilizados na composi¸c˜ ao e;
• l´ ogica de programa¸ c˜ ao: os elementos da linguagem WS-BPEL que unem as vari´ aveis ` as chamadas de servi¸cos.
Medeiros et al. (2007) apresentam o escopo da linguagem WS-BPEL:
• pap´ eis que participam da troca de mensagem;
• portas
13dos pap´ eis;
• vari´ aveis usadas para manter o estado de dados e a hist´ oria do processo baseada na troca de mensagens;
• orquestra¸c˜ ao entre servi¸cos definidos em WSDL e outros aspectos como transa¸c˜ oes e exce¸c˜ oes e;
• informa¸c˜ ao de correla¸c˜ ao definindo como mensagens s˜ ao direcionadas para instˆ ancia de composi¸c˜ ao correta.
2.4 Contratos Eletrˆ onicos
De acordo com o descrito na Se¸c˜ ao 2.2, a evolu¸c˜ ao da Internet permitiu que aplica¸c˜ oes pudessem ser disponibilizadas em formato de servi¸cos para serem utilizadas por outras organiza¸c˜ oes. Entretanto, o fato de realizar transa¸c˜ oes operacionais ou comerciais entre aplica¸c˜ oes que ultrapassam os limites f´ısicos e l´ ogicos organizacionais, implica na ne- cessidade de acompanhamento ou apenas de uma descri¸c˜ ao formal em detalhes sobre o fornecimento e o consumo dos servi¸cos.
12Do InglˆesSchema Definitions
13Do InglˆesPort
Segundo Fantinato (2007), contratos eletrˆ onicos s˜ ao usados para descrever detalhes sobre o fornecimento e o consumo de servi¸cos eletrˆ onicos em um processo de neg´ ocio, podendo incluir tamb´ em atributos de QoS estabelecidos pelas partes envolvidas. Alguns exemplos de atributos de qualidade de servico s˜ ao: integridade, disponibilidade, confia- bilidade, seguran¸ca e tempo de resposta (Sahai et al., 2002). Neste trabalho, o tipo de contrato eletrˆ onico considerado ´ e o contrato eletrˆ onico para servi¸cos web.
Um contrato eletrˆ onico ´ e um documento modelado, especificado, executado, controlado e monitorado por um sistema de software (Krishna et al., 2005). Um Contrato Eletrˆ onico estabelece um acordo entre duas ou mais partes (organiza¸c˜ oes) para criar um relacio- namento entre elas. Essas rela¸c˜ oes representam os direitos e obriga¸c˜ oes como tamb´ em as condi¸c˜ oes sobre as quais as partes organizacionais estar˜ ao regidas (Krishna et al., 2005),(Fantinato, 2007). Angelov e Grefen (2002) afirmam que os acordos acontecem com custos mais baixos, com per´ıodos de tempo menores e sem limites geogr´ aficos. Sendo assim, alguns benef´ıcios podem ser ressaltados quando se faz o uso de contratos eletrˆ onicos, s˜ ao de trˆ es tipos e valores: financeiro, estrat´ egicos e de processos. Os valores estrat´ egicos compreendem vantagem competitiva, informa¸c˜ ao de gerˆ encia e arquitetura de tecnologia de informa¸c˜ ao estrat´ egica. Sobre valores de processos podem-se citar: tempo do ciclo de vida, agilidade e adaptalidade Angelov e Grefen (2004) apud Fantinato (2007). Um contrato eletrˆ onico pode ser usado como instrumento de apoio para eventuais julgamentos em caso de discordˆ ancias entre as partes envolvidas no processo de neg´ ocio.
Alguns riscos podem ser associados a contratos eletrˆ onicos como: riscos pol´ıticos, de neg´ ocio, de legalidade, de padroniza¸c˜ ao de seguran¸ca (interna e externa).
Alguns autores como Griffel et al. (1998) e Fantinato (2007) afirmam que os elementos mais comuns de contratos eletrˆ onicos s˜ ao:
• partes: representam as diferentes organiza¸c˜ oes envolvidas em um processo de neg´ ocio.
Essas organiza¸c˜ oes representam parceiros exercendo diferentes pap´ eis.
• atividades: descrevem os servi¸cos que ser˜ ao executados por meio da realiza¸c˜ ao do contrato eletrˆ onico. Essas descri¸c˜ oes incluem tamb´ em informa¸c˜ oes que s˜ ao ´ uteis para o correto fornecimento e consumo dos servi¸cos.
• cl´ ausulas contratuais: descrevem restri¸c˜ oes a serem cumpridas durante a execu¸c˜ ao das atividades que est˜ ao previstas no contrato.
O ciclo de vida de contratos eletrˆ onicos pode se resumir em quatro fases (Fantinato,
2007):
2.4 Contratos Eletrˆ onicos 15 1. implementa¸ c˜ ao dos servi¸ cos eletrˆ onicos: refere-se ` a implementa¸c˜ ao dos servi¸cos realizados pelas organiza¸c˜ oes fornecedoras. Esta implementa¸c˜ ao pode ser realizada pela iniciativa das organiza¸c˜ oes e n˜ ao necessariamente s´ o a partir dos pedidos de organiza¸c˜ oes que poder˜ ao ser potenciais consumidoras;
2. disponibiliza¸ c˜ ao, busca e descoberta dos servi¸ cos eletrˆ onicos: a dispo- nibiliza¸c˜ ao de servi¸cos como tamb´ em de informa¸c˜ oes de QoS ´ e realizada pelos fornecedores. Para os consumidores faz-se necess´ aria a busca e descoberta dos servi¸cos;
3. negocia¸ c˜ ao e estabelecimento dos contratos eletrˆ onicos: envolve decis˜ oes que definem como o processo de neg´ ocio acontecer´ a entre as partes envolvidas. Decis˜ oes como quais servi¸cos ser˜ ao utilizados bem como quais as cl´ ausulas contratuais;
4. realiza¸ c˜ ao do processo de neg´ ocio: refere-se ` a execu¸c˜ ao e cumprimento dos termos estabelecidos no contrato eletrˆ onico.
2.4.1 Uma abordagem baseada em caracter´ısticas para o estabeleci- mento de contratos eletrˆ onicos para servi¸ cos web
Esta se¸c˜ ao apresenta a Abordagem baseada em Caracter´ısticas para o Estabelecimento de Contratos Eletrˆ onicos para Servi¸cos Web que ´ e foco dos experimentos realizados neste trabalho de mestrado. Esta abordagem visa reduzir a complexidade do estabelecimento de contratos eletrˆ onicos para servi¸cos Web, melhorar a estrutura e aumentar a reutiliza¸c˜ ao de informa¸c˜ oes presentes em contratos eletrˆ onicos. Al´ em disto, s˜ ao propostas melhorias na estrutura¸c˜ ao como tamb´ em nas facilidades de gerˆ encia e reutiliza¸c˜ ao das informa¸c˜ oes envolvidas nos contratos eletrˆ onicos (Fantinato, 2007).
Na abordagem baseada em caracter´ısticas para o estabelecimento de contratos eletrˆ oni-
cos para servi¸cos Web s˜ ao usados modelos de caracter´ısticas para representar, de forma
gen´ erica, os servi¸cos eletrˆ onicos e seus n´ıveis de QoS. As atividades do processo de
estabelecimento de contratos eletrˆ onicos entre as partes envolvidas s˜ ao orientadas pelos
modelos de caracter´ısticas e por suas poss´ıveis configura¸c˜ oes. Cada configura¸c˜ ao de um
modelo de caracter´ısticas apresenta um conjunto de servi¸cos eletrˆ onicos, informa¸c˜ oes
associadas aos servi¸cos e, tamb´ em, ao conjunto de n´ıveis dos atributos de QoS, conhecidas
pelas duas partes envolvidas do neg´ ocio. Todos os servi¸cos gen´ ericos, ap´ os selecionados
para a contrata¸c˜ ao, s˜ ao mapeados para servi¸cos web espec´ıficos a fim de possu´ırem
opera¸c˜ oes e relacionamento de um-para-um. Esta abordagem ´ e baseada em conceitos de
linha de produto de software, como tamb´ em em modelo de caracter´ısticas. Seus 5 (cinco) est´ agios s˜ ao derivados do m´ etodo FORM
14, conforme mostra a Figura 2.5, (Fantinato, 2007):
Figura 2.5: Processo de estabelecimento de contratos eletrˆ onicos com base em carac- ter´ısticas
(Fantinato, 2007)
1. elabora¸ c˜ ao dos modelos de caracter´ısticas para servi¸ cos eletrˆ onicos: os modelos de caracter´ısticas e os atributos de QoS, sendo um para cada parte das organiza¸c˜ oes que desejam estabelecer o contrato eletrˆ onico;
2. cria¸ c˜ ao do molde de contrato eletrˆ onico para servi¸ co web: este molde de contrato conter´ a informa¸c˜ oes que poder˜ ao ser utilizadas em qualquer contrato eletrˆ onico estabelecido a partir desses dois modelos;
3. desenvolvimento e publica¸ c˜ ao dos servi¸ cos Web: os servi¸cos Web que im- plementam os servi¸cos eletrˆ onicos devem ser desenvolvidos e publicados a fim de estarem dispon´ıveis para a realiza¸c˜ ao do processo de neg´ ocio contido no contrato;
14Do InglˆesFeature-Oriented Reuse Method
2.4 Contratos Eletrˆ onicos 17 4. configura¸ c˜ ao dos modelos de caracter´ısticas para servi¸ cos eletrˆ onicos: os modelos de caracter´ısticas s˜ ao configurados, isto ´ e, as caracter´ıstas que representam os servi¸cos e os n´ıveis de QoS exigidos s˜ ao selecionados para o processo de neg´ ocio entre as organiza¸c˜ oes;
5. cria¸ c˜ ao da instˆ ancia de contrato eletrˆ onico para servi¸ co Web: tendo como base o par de modelos de caracter´ısticas configurados no est´ agio 4, o contrato eletrˆ onico ´ e refinado sobre o molde de contrato eletrˆ onico estabelecido no est´ agio 2.
A Figura 2.6 apresenta um exemplo de modelo de caracter´ıstica no dom´ınio de uma loja virtual. A associa¸c˜ ao das caracter´ısticas basicamente determina como o servi¸co ser´ a realizado. Dois servi¸cos b´ asicos s˜ ao oferecidos: pagamento e entrega. O servi¸co pagamento possui funcionalidades opcionais de pagamento por cart˜ ao de cr´ edito, cart˜ ao de d´ ebito ou por boleto banc´ ario. O servi¸co de entrega disp˜ oe de entrega por terra, ar ou mar exclusivamente.
Figura 2.6: Exemplo de modelo de caracter´ıstica e suas associa¸c˜ oes (Fantinato, 2007)
Para o in´ıcio do processo de estabelecimento do contrato, ´ e necess´ ario que as orga- niza¸c˜ oes envolvidas no processo de neg´ ocio sejam conhecidas. Com exce¸c˜ ao do est´ agio 1 (um), os est´ agios que seguem devem ser realizados com parceria entre as organiza¸c˜ oes.
Devido as caracter´ısticas particulares, os est´ agios 1 (um), 2 (dois) e 3(trˆ es) s˜ ao realizados uma ´ unica vez para um dom´ınio de contrato envolvendo aquele mesmo par de organiza¸c˜ ao.
Os est´ agios 4 (quatro) e 5 (cinco) s˜ ao realizados a cada nova estˆ ancia do contrato para um mesmo dom´ınio.
Para cada est´ agio, descrito anteriormente, um artefato ´ e gerado. Na Figura 2.7, os
artefatos s˜ ao representados em um diagrama de classe, e os relacionamentos estabelecidos.
O modelo de caracter´ısticas ´ e o artefato base para a cria¸c˜ ao de um ´ unico molde de contrato eletrˆ onico. A partir dele ser´ a derivado um ou mais modelos de caracter´ısticas configurados.
Para cada modelo de caracter´ıstica configurado, existe um contrato eletrˆ onico para um particular servi¸co Web estabelecido. Cada contrato eletrˆ onico ´ e estabelecido com base no molde de contrato eletrˆ onico para servi¸cos Web. Cada servi¸co Web que implementa um determinado servi¸co eletrˆ onico do modelo de caracter´ısticas ´ e referenciado por um molde de contrato eletrˆ onico. Somente os servi¸cos Web que implementam os servi¸cos eletrˆ onicos do modelo de caracter´ısticas configurados s˜ ao referenciados pelo contrato eletrˆ onico correspondente (Fantinato, 2007).
Figura 2.7: Relacionamento entre os artefatos produzidos pelo processo (Fantinato, 2007)
O meta-modelo de contrato eletrˆ onico desenvolvido por Fantinato (2007), apresentado na Figura 2.8, representa as regras a serem seguidas durante a cria¸c˜ ao dos contratos eletrˆ onicos e tamb´ em para moldes de contratos eletrˆ onicos. Para a cria¸c˜ ao do modelo, a unifica¸c˜ ao dos seguintes e principais conceitos foi realizada:
• servi¸ cos Web: descritos por meio da linguagem WSDL;
• atributos de QoS para servi¸ cos Web: descritos por meio da linguagem WS - Agreement
15;
• processos de neg´ ocio envolvendo servi¸ cos Web: descritos por meio da lingua- gem WS-BPEL.
As contribui¸c˜ oes da abordagem baseada em caracter´ısticas para o estabelecimento de contratos eletrˆ onicos para servi¸cos Web apresentadas, incluem: (i) uma forma sistem´ atica e eficiente para a estrutura¸c˜ ao e o reuso de informa¸c˜ ao em contratos eletrˆ onicos; (ii) um meio para representar informa¸c˜ oes de contratos eletrˆ onios por meio de modelos de caracter´ısticas que podem ser transformados em moldes de contratos eletrˆ onicos; (iii)
15Do InglˆesWeb Services Agreement Specification
2.4 Contratos Eletrˆ onicos 19
Figura 2.8: Meta-modelo para o estabelecimento de contratos eletrˆ onicos (Fantinato, 2007)
gerˆ encia eficiente de partes obrigat´ orias, opcionais e alternativas de contratos eletrˆ onicos, em processo de neg´ ocio e tamb´ em em atributos de QoS associados aos servi¸cos Web contratados.
Fantinato (2007) ao ressaltar os resultados obtidos na realiza¸c˜ ao de seu trabalho e
tamb´ em no estudo de caso, apresenta as vantagens, dentre as quais descatam-se: repre-
senta¸c˜ ao adequada de servi¸cos eletrˆ onicos por modelos de caracter´ısticas; proposi¸c˜ ao de
um meta-modelo completo de contrato eletrˆ onico para servi¸co Web; melhor estrutura¸c˜ ao
e reuso de informa¸c˜ oes envolvidas como tamb´ em a aplicabilidade dessa abordagem para
contratos eletrˆ onicos complexos. Como desvantagens e limita¸c˜ oes tˆ em-se: necessidade
de conhecimento de modelagem de caracter´ısticas; cobertura n˜ ao extensiva de tipos de
contratos eletrˆ onicos; o acordo est´ a limitado a duas partes apenas; o modelo de est´ agio
de negocia¸c˜ ao deve ser est´ atico; a necessidade da heterogeneidade das ferramentas que
englobam o conjunto de ferramentas FeatureContract
16e; a falta de realiza¸c˜ ao de estudos experimentais para avaliar a abordagem desenvolvida.
2.4.2 Exemplos: configura¸ c˜ ao de caracter´ısticas e contrato eletrˆ onico
Para apresentar um exemplo de contrato eletrˆ onico, a Figura 2.9 mostra parte de uma configura¸c˜ ao de modelo de caracter´ısticas para servi¸cos eletrˆ onicos por meio da ferra- menta FeaturePlugin. Esse modelo descreve as informa¸c˜ oes sobre os servi¸cos eletrˆ onicos e atributos de QoS apresentadas por um sistema de cobran¸ca.
Como pode-se visualizar, o servi¸co eletrˆ onico configurado ´ e “aplicacao - de - acao - de - cobranca”. Este servi¸co inclui as caracter´ısticas “notificacao - de - debito”,
“suspensao - de - fornecimento - de - servico” e “acoes legais”. Tendo selecionado a caracter´ıstica “suspensao - de - fornecimento - de - servico” e a sub caracter´ıstica
“suspensao - total”, ´ e necess´ ario configurar tamb´ em seus atributos de QoS. O atru- buto de QoS configurado ´ e o “tempo-de-resposta”, determinando que com 15 dias de atraso, a suspens˜ ao do fornecimento do servi¸co ser´ a total. Ap´ os a configura¸c˜ ao das caracter´ısticas selecionadas para gerir as a¸c˜ oes entre as organiza¸c˜ oes parceiras, ´ e gerado o contrato eletrˆ onico. A Figura 2.10 apresenta a parte do contrato eletrˆ onico que refere-se
`
a configura¸c˜ ao realizada na Figura 2.9.
Como mostra a figura 2.10, por meio da configura¸c˜ ao do atributo de QoS do servi¸co
“aplicacao-de-acao-de-cobranca”, o tempo de resposta da empresa parceira ser´ a de 15 dias. Desta forma, todas as regras configuradas por meio das caracter´ısticas e seus atributos de qualidade ser˜ ao monitorados por um sistema de software.
2.5 Projeto InfraPro
O projeto InfraPro tem como objetivo desenvolver modelos e mecanismos para a forma¸c˜ ao de uma infra-estrutura de apoio ` a modelagem e execu¸c˜ ao de processos de neg´ ocio baseada nos conceitos de reutiliza¸c˜ ao, no paradigma de orienta¸c˜ ao a aspectos e na tecnologia de servi¸cos Web. Al´ em disso, o projeto InfraPro visa contornar o problema da falta de planejamento de estudos experimentais e no rigor de execu¸c˜ ao deste. Este projeto segue os conceitos de engenharia de software experimental para avaliar os seus resultados das t´ ecnicas e ferramentas propostas por meio de estudos de caso quantitativos. Os objetivos espec´ıficos do projeto s˜ ao:
16Do InglˆesFeature Modeling based Web Services E-Contracts establishment toolkit
