Para a realização dos experimentos, foram definidas duas composições. A primeira envolve um teste booleano (sobre o dispositivo do usuário) que determina a maneira como os dados produzidos serão exibidos. A segunda mostra uma série de requisitos de uma aplicação de locação de hotel. Estas composições cobrem as estruturas propostas neste trabalho: (i) a primeira composição envolve uma estrutura if, then e else onde cada bloco de atividade consiste em serviços que serão executados em paralelo; (ii) a segunda envolve uma instrução while associada a um bloco de atividades que define uma execução sequencial de serviços. Para cada uma dessas composições foram criados serviços concretos e respectivas anotações de funcionalidades.
Utilizaremos a primeira composição como referência para a explicação do método proposto, pois sua especificação envolve uma estrutura if, a qual engloba um bloco de teste e dois blocos de funcionalidades alternativas.
Mobile
Esse problema mostra um sistema simples onde é testado o tipo de dispositivo para decidir como informações recuperadas a partir de uma chave serão exibidas ao usuário. O sistema possui duas possibilidade de execução: se o dispositivo for um tablet, o sistema recuperas as informações e as mostra em forma de texto; caso contrário, invoca o serviço que mostra as informações em flash. A Figura9 mostra um fluxograma de execução para esse sistema.
Esse problema demostra uma composição abstrata utilizando a instrução de con- trole if. Neste problema, foram escolhidos serviços e parâmetros de modo que se possa demonstrar a atividade de WS-BPEL flow tanto no bloco then quando no bloco else. Abaixo, a representação textual da consulta.
Figura 9 – Estudo de caso 1
CA(KEY?,DEVICE?) ≡def if is_Tablet(DEVICE?,R!) then retrieveInfo(DEVICE?,I?) showText(DEVICE?,I?,OUT!) else retrieveInfo(KEY?,I!) showFlash(DEVICE?,I?,OUT!) endif
Na condição da instrução if é invocado o serviço is_Tablet(DEVICE?,R!). Nesse serviço, DEVICE é um parâmetro de entrada, enquanto R é um parâmetro booleano de saída que será verdadeiro se o dispositivo de entrada for um tablet. O bloco then invoca dois serviços: retrieveInfo(KEY?,I!), que recupera a informação a ser exibida a partir de uma chave; e showText(DEVICE?,I?,OUT!), que mostra as informações no dispositivo indicado de forma textual por meio do parâmetro OUT!. De maneira análoga, o bloco else também chama o serviço retrieveInfo(KEY?,I!), porém o segundo serviço chamado será showFlash(DEVICE?,I?,OUT!). Neste caso, as informações serão exibidas em uma animação flash.
Cada bloco de serviços corresponderá a uma sub-composição que será refinada em separado:
CA1(KEY?,DEVICE?) ≡def is_Tablet(DEVICE?,R!)
CA2(KEY?,DEVICE?) ≡def retrieveInfo(KEY?,I!),showText(DEVICE?,I?,OUT!) CA3(KEY?,DEVICE?) ≡def retrieveInfo(KEY?,I!),showFlash(DEVICE?,I?,OUT!)
todas as funcionalidades requeridas na especificação da composição abstrata CA. A espe- cificação desse serviço deve vir acompanhada de informações referentes às funcionalidades de cada umas de suas operações. O trecho do documento que contem as anotações com as funcionalidades das operações mostrarFlash, eh_tablet, mostrarTexto e obterInformacao é mostrado na Listagem 4.1. 6 <operations> <operation>mostrarFlash(device?,i?,return!) :− showFlash(device?,i?,return!)</operation> 8 <operation>eh_tablet(device?,return!) :− is_Tablet(device?,return!)</operation> <operation>mostrarTexto(device?,i?,return!) :− showText(device?,i?,return!)</operation> 10 <operation>obterInformacao(chave?,return!) :− retrieveInfo(chave?,return!)</operation> </operations>
Listagem 4.1 – Trecho de anotações
A partir dessas operações, o módulo do front-end gera a entrada do algoritmo refinamento. Cada operação do serviço será convertida para uma visão, de acordo com o seguinte padrão: o nome do predicado que define a interface de uma visão é composto pela concatenação do nome do serviço e do nome da operação à qual ela se refere; a definição da cada visão corresponde exatamente à definição da respectiva operação. Para esse estudo de caso, o documento que representa os serviços concretos é mostrado no ApêndiceG. Na Listagem 4.2, apresentamos um trecho desse documento.
12 <testcase> <id>1</id> 14 <query>CA2(KEY?,DEVICE?) :− retrieveInfo(KEY?,I!),showText(DEVICE?,I?,OUT!)</query> <view>MOBILE:eh_tablet(device?,return!) :− is_Tablet(device?,return!)</view> 16 <view>MOBILE:mostrarFlash(device?,i?,return!) :− showFlash(device?,i?,return!)</view> <view>MOBILE:obterInformacao(key?,return!) :− retrieveInfo(key?,return!)</view> 18 <view>MOBILE:mostrarTexto(device?,i?,return!) :− showText(device?,i?,return!)</view> </testcase>
Listagem 4.2 – Exemplo de uma entrada para o algoritmo
A interface de cada visão é definida a partir de informações obtidas do WSDL do serviço Mobile, enquanto sua definição é obtida das anotações de funcionalidades.
Para o conjunto de serviços concretos disponíveis e cada sub-composição, nosso algoritmo retorna as melhores1 sub-composições refinadas:
CA1’(KEY?,DEVICE?) ≡def MOBILE:eh_tablet(DEVICE?,R!) CA2’(KEY?,DEVICE?) ≡def MOBILE:obterInformacao(KEY?,I!),
MOBILE:mostrarTexto(DEVICE?,I?,OUT!) CA3’(KEY?,DEVICE?) ≡def MOBILE:obterInformacao(KEY?,I!),
1 Lembramos que na implementação atual adotamos a primeira composição produzida pelo refinamento
MOBILE:mostrarFlash(DEVICE?,I?,OUT!)
Para cada sub-composição concreta, o módulo de identificação de dependência produz informações de controle mais finas, identificando invocações de serviços, sequências e fluxos paralelos de serviços.
A Listagem 4.3 mostra o resultado obtido pelo módulo de identificação de depen- dência quando aplicado à sub-composição CA2’(KEY?,DEVICE?).
<sequence>
2 <invoke>MOBILE:obterInformacao(KEY?,I!)</invoke> <invoke>MOBILE:mostrarTexto(DEVICE?,I?,OUT!)</invoke>
4 </sequence>
Listagem 4.3 – Trecho do código após a geração de dependências
Como o serviço MOBILE:mostrarTexto(DEVICE?,I?,OUT!) depende da infor- mação I produzida por MOBILE:obterInformacao(KEY?,I!), a invocação de MO- BILE:mostrarTexto (linha 2) deve preceder a de MOBILE:obterInformacao (linha 3). A sequência de chamadas é definida por um elemento <sequence>.
Após a identificação das dependências de cada uma das sub-composições concretas, nosso método as integra de forma a gerar uma composição concreta com a mesma estrutura da composição abstrata inicial. Para o estudo de caso MOBILE, a composição concreta obtida é aquela mostrada na Listagem4.4.
1 <if> <condition>MOBILE:eh_Tablet(DEVICE?,R!)</condition> 3 <then> <sequence> 5 <invoke>MOBILE:obterInformacao(KEY?,I!)</invoke> <invoke>MOBILE:mostrarTexto(DEVICE?,I?,OUT!)</invoke> 7 </sequence> </then> 9 <else> <sequence> 11 <invoke>MOBILE:obterInformacao(KEY?,I!)</invoke> <invoke>MOBILE:mostrarFlash(DEVICE?,I?,OUT!)</invoke> 13 </sequence> </else> 15 </if>
Listagem 4.4 – Trecho do código após reagrupar as sub-composições
O próximo passo é converter a representação da Listagem 4.4 em um processo WS-BPEL. O trecho do documento que contêm os namespace do processo é mostrado na Listagem4.5. Neste trecho são mostrados os namespaces dos serviços participantes. Note que há apenas um namespace (linha 3), referente à URL do serviço concreto usado na composição.
xmlns:ns="http://ws.apache.org/axis2"name="teste"
4 targetNamespace="http://eclipse.org/bpel/sample">
Listagem 4.5 – Trecho com os namespace do processo
Os elementos partnerLink representam cada serviço que participa da composição. Na linha 9, encontra-se a declaração do serviço concreto “mobile”. O atributo partner- LinkType refere-se ao tipo de porta usada na comunicação desse serviço. Essa informa- ção é obtida do documento WSDL do serviço. O trecho do documento que contém os partnerLinks do processo é mostrado na Listagem 4.6:
<bpel:partnerLinks
6 xmlns:bpel="http://docs.oasis−open.org/wsbpel/2.0/process/executable"> <bpel:partnerLink name="client"partnerLinkType="tns:test"
8 myRole="Provider"/>
<bpel:partnerLink name="mobile"partnerLinkType="ns:MobilePortType"
10 role="MobileRole"/> </bpel:partnerLinks>
Listagem 4.6 – PartnerLinks do processo
O elemento variables é criado obtendo os nomes das operações dos serviços participantes. Esses nomes são identificados a partir dos documentos WSDL de cada serviço parceiro. Para cada operação em Mobile, são criadas duas variáveis locais no processo WS-BPEL, uma de saída e outra de entrada. O trecho do documento que contém dois elementos variable para a operação obterInformacao é mostrado na Listagem 4.7, uma para a saída e outro para entrada da operação:
16 <bpel:variable name="MOBILERequest"messageType="obterInformacaoRequest"/> <bpel:variable name="MOBILEResponse"messageType="obterInformacaoResponse"/>
Listagem 4.7 – PartnerLinks do processo
O principal elemento sequence de um processo WS-BPEL é um agregador de ati- vidades que aninha todas as outras atividades do processo. O elemento sequence principal começa com uma atividade receive para receber a entrada do processo (Listagem 4.8) . 28 <receive name="receiveInput"partnerLink="client"portType="test"
operation="process"variable="input"createInstance="yes"/>
Listagem 4.8 – Atividade receive
Em seguida, começa-se a tradução da representação vista na Listagem 4.4 em um processo WS-BPEL. Por fim, é criada a atividade reply para fornecer a saída da composição. Essa atividade é mostrada na Listagem 4.9.
88 <reply name="receiveInput"partnerLink="client"portType="test"
operation="process"variable="output"/>
O processo WS-BPEL obtido para este estudo de caso é mostrado em detalhes no ApêndiceIe o documento WSDL do serviço concreto “MOBILE” encontra-se no Apêndice D.
Reserva de hotel
Neste estudo de caso apresentamos um problema que consiste na criação de uma composição de serviços para a administração de uma rede de hotéis (adaptação do pro- blema abordado em [NETO et al.,2010]). O objetivo da composição é oferecer um sistema web onde clientes possam efetivar reservas de hotéis de uma rede distribuída em diversas cidades. O sistema é visto como composto de quatro tarefas principais, que devem ser repetidas até que o cliente efetue sua reserva (Figura10).
Figura 10 – Estudo de caso 2
O cliente precisa informar o nome de uma cidade para obter a lista de hotéis da- quela localidade. Dada uma cidade, a atividade searchHotel(CITY?,HOTELS!) faz uma busca de hotéis. A atividade selectHotel(HOTELS?,HOTEL!) recebe como entrada uma lista do hotéis e retorna apenas um hotel, aquele selecionado pelo usuário. A atividade viewDetails(HOTEL?,DETAILS!) recebe como entrada um hotel e retorna os detalhes do mesmo. Por fim, a atividade chooseHotel(USER?,HOTEL?,VOUCHER!) efetua a reserva e devolve um voucher ao cliente. Esta atividade tem duas entradas, o identificador do cli- ente e o hotel selecionado. Usando estas informações a atividade retorna um comprovante referente a reserva do usuário.
Dada a natureza iterativa deste problema, o mesmo pode ser representado por uma composição utilizando a estrutura de controle while. Nesta estrutura, o serviço done(USER?,RESPONSE!) representa o teste de parada de repetição: enquanto o parâ- metro RESPONSE for verdadeiro, o cliente continua a buscar hoteis e suas informações. Na Figura 10, apresentamos a composição abstrata definida para este problema:
CB(USER?,CITY?,VOUCHER!) ≡def while done(USER?,RESPONSE!) do searchHotel(CITY?,HOTELS!) selectHotel(HOTELS?,HOTEL!) viewDetails(HOTEL?,DETAILS!) chooseHotel(USER?,HOTEL?,VOUCHER!) endwhile
A partir desta especificação, o módulo responsável pela identificação das sub- composições concretas, produzirá uma sub-composição referente ao teste de parada e outra referente aos serviços que serão executados repetidamente pelo cliente:
CB1(USER?,CITY?,VOUCHER!) ≡def done(USER?,RESPONSE!) CB2(USER?,CITY?,VOUCHER!) ≡def searchHotel(CITY?,HOTELS!),
selectHotel(HOTELS?,HOTEL!), viewDetails(HOTEL?,DETAILS!),
chooseHotel(USER?,HOTEL?,VOUCHER!) Para este problema, foi criado o serviço concreto HotelService que atende as re- quisições de funcionalidades da especificação. As operações deste serviço são mostradas na Listagem 4.10, incluindo suas anotações de funcionalidade.
<operations> 2 <operation>naoEscolhido(user?,return!) :− done(user?,return!)</operation> <operation>procuraHotel(city?,return!) :− searchHotel(city?,return!)</operation> 4 <operation>verDetalhes(hotel?,return!) :− viewDetails(hotel?,return!)</operation> <operation>escolheHotel(hotels?,return!) :− selectHotel(hotels?,return!)</operation> 6 <operation>confirmaReserva(user?,hotel?,return!) :− chooseHotel(user?,hotel?,return!)</operation> </operations>
Listagem 4.10 – Trecho de anotações
Um trecho do documento de entrada para o algoritmo de refinamento referente à sub-composição CB2 é mostrado na Listagem4.11.
16 <testcase> <id>1</id> 18 <query>CB2(USER?,CITY?,VOUCHER!) :− searchHotel(CITY?,HOTELS!),selectHotel(HOTELS?,HOTEL!), viewDetails(HOTEL?,DETAILS!),chooseHotel(USER?,HOTEL?,VOUCHER!)</query> <view>HOTELSERVICE:procuraHotel(city?,return!) :− searchHotel(city?,return!)</view> 20 <view>HOTELSERVICE:verDetalhes(hotel?,return!) :− viewDetails(hotel?,return!)</view> <view>HOTELSERVICE:escolheHotel(hotels?,return!) :− selectHotel(hotels?,return!)</view> 22 <view>HOTELSERVICE:confirmaReserva(user?,hotel?,return!) :− chooseHotel(user?,hotel?,return!)</view> </testcase> 24 </testcases>
Considerando as sub-composições CB1 e CB2, os módulo de refinamento e classi-
ficação produzirão as seguintes sub-composições:
CB1’(USER?,CITY?,VOUCHER!) ≡def HOTELSERVICE:naoEscolhido(USER?,RESPONSE!)
CB2’(USER?,CITY?,VOUCHER!) ≡def HOTELSERVICE:procuraHotel(CITY?,HOTELS!),
HOTELSERVICE:escolheHotel(HOTELS?,HOTEL!), HOTELSERVICE:verDetalhes(HOTEL?,DETAILS!),
HOTELSERVICE:confirmaReserva(USER?,HOTEL?,VOUCHER!) A Listagem 4.12, mostra o resultado da aplicação do módulo de identificação de dependências à CB2’ . <sequence> 2 <invoke>HOTELSERVICE:procuraHotel(CITY?,HOTELS!)</invoke> <invoke>HOTELSERVICE:escolheHotel(HOTELS?,HOTEL!)</invoke> 4 <flow> <invoke>HOTELSERVICE:verDetalhes(HOTEL?,DETAILS!)</invoke> 6 <invoke>HOTELSERVICE:confirmaReserva(USER?,HOTEL?,VOUCHER!)</invoke> </flow> 8 </sequence>
Listagem 4.12 – Dependências geradas em CB2’
Note que a seleção de um hotel depende do resultado da busca dos hotéis da rede para a localidade considerada. Selecionado um hotel, o cliente poderá visualizar seus detalhes enquanto finaliza sua escolha.
A composição concreta correspondente à integração das sub-composições concretas obtidas é mostrada na Listagem 4.13.
1 <while> <condition>HOTELSERVICE:naoEscolhido(USER?,RESPONSE!)</condition> 3 <sequence> <invoke>HOTELSERVICE:procuraHotel(CITY?,HOTELS!)</invoke> 5 <invoke>HOTELSERVICE:escolheHotel(HOTELS?,HOTEL!)</invoke> <flow> 7 <invoke>HOTELSERVICE:verDetalhes(HOTEL?,DETAILS!)</invoke> <invoke>HOTELSERVICE:confirmaReserva(USER?,HOTEL?,VOUCHER!)</invoke> 9 </flow> </sequence> 11 </while>
Listagem 4.13 – Dependências geradas em CB2’
O processo WS-BPEL obtido pela tradução desta composição encontra-se no Apêndice H e o WSDL do serviço concreto “HotelService” encontra-se no ApêndiceC.
5 Conclusões e Trabalhos Futuros
Neste trabalho foi proposto um método de composição automática de processos WS-BPEL a partir de especificações de serviços em alto nível. Esta abordagem tem por objetivo facilitar o desenvolvimento de sistemas baseados em serviços web, uma vez que o projetista poderá se concentrar na concepção da composição independente da disponibi- lidade dos serviços específicos. Serviços concretos poderão ser vinculados posteriormente, fazendo uso de algoritmo de refinamento de especificações de serviços abstratos para ser- viços concretos. Hoje, ainda é bastante baixo o número de ferramentas que se propõem a criar projetos WS-BPEL a partir de especificações de alto nível. O plugin do Eclipse BPEL Design permite escrever projetos WS-BPEL utilizando um sistema gráfico, mas não oferece um mecanismo para criação de composição a partir de descrições abstratas.
Nesta dissertação foi apresentada uma fundamentação teórica acerca dos tópicos necessários para esta proposta, envolvendo: conceitos de SOC (Service-Oriented Compu- ting), serviços web, algoritmo de refinamento de composições de serviços e WS-BPEL, a linguagem de composição alvo deste trabalho. Em [COSTA et al., 2013] os autores pro- põem um algoritmo que refina composições de serviços especificadas sobre serviços abs- tratos em composições de serviços definidas sobre serviços concretos. Propusemos uma extensão da linguagem de especificação utilizada nesse trabalho. As extensões propostas nos permitem adicionar instruções de controle de alto nível na especificação da composi- ção abstrata. Com base nessas instruções de controle, dividimos a especificação original em sub-composições que são refinadas separadamente, analisadas quanto a dependências de dados e, por fim, traduzidas e reintegradas em processos WS-BPEL.
Nossa abordagem foi validada por meio da implementação de um protótipo. Esse protótipo suporta composições utilizando nossas extensões (instruções de controle de alto nível) e gera processos WS-BPEL contendo atividades invoke, assign, seguence e flow. Realizamos experimentos considerando dois estudos de caso, um ilustrando a estrutura condicional if e else, outro ilustrando a estrutura de repetição while. O código produzido por nosso método foi avaliado comparando-se sua estrutura ao esquema XML do BPEL. Essa avaliação foi realizada automaticamente utilizando-se o site FreeFormatter.com1
No momento, nosso método não suporta especificações com estruturas if ou while aninhadas, bem como, não há suporte ao tratamento de falhas, atividades de tomadas de decisão mais complexas (como a atividade pick). Entre as sugestões de melhoria de nossa abordagem, destacamos: (i) ampliação do número de atividades suportadas pela linguagem de especificação inicial, fazendo com que seja mais explorada a linguagem WS- 1 <http://www.freeformatter.com/xml-validator-xsd.html>
BPEL; (ii) suporte a instruções de controle aninhadas, como exemplo, sequence, flow, if e while; (iii) criação de uma ferramenta que valide de forma precisa esse método, já foi dito que ha poucas ferramentas que oferecem a possibilidade de projetar de sistemas em WS-BPEL, porém, nenhuma delas trabalha diretamente com o código, sendo esse gerado de automaticamente; e (iv) ampliação do número de linguagens de composição final suportadas. Neste trabalho o único alvo é a conversão para WS-BPEL, porém, é possível usar o mesmo método e converter para outra linguagem.
Referências
ALVES, A. et al. Web Services Business Process Execution Language Version 2.0. maio 2006. OASIS Committee Draft. Citado 8 vezes nas páginas 19, 27, 28, 29, 32, 35, 39
e 65.
BA, C. et al. Pews: A new language for building web service interfaces. 2005. v. 11, n. 7, p. 1215–1233, jul 2005. Citado na página24.
BLOW, M. et al. Bpelj: Bpel for java. In: . BEA and IBM, 2004. Disponível em: <http://ftpna2.bea.com/pub/downloads/ws-bpelj.pdf>. Citado na página24. BOX, D. et al. W3C. Simple object access protocol (soap) 1.1. 2011. Disponível em
<http://www.w3.org/TR/2000/NOTE-SOAP-20000508>. Citado na página 21. BUCCHIARONE, A.; GNESI, S. A survey on services composition languages and models. In: Proceedings of International Workshop on Web Services Modeling and Testing 2006 (WS-MaTe 2006). [S.l.: s.n.], 2006. Citado 2 vezes nas páginas 17e 21.
CHAMPION, M. et al. Web services architecture. 2002. Disponível em <http:
//www.w3.org/TR/2002/WD-ws-arch-20021114/>. W3C Working Draft 14 November 2002]. Citado na página 21.
CHAPPELL, D. Introducing Windows Workflow Foundation. 2012. Acessado em 12/08/2019 às 14:30 horas. Disponível em: <http://msdn.microsoft.com/pt-br/library-
/ee210343.aspx>. Citado na página 24.
CHRISTENSEN, E. et al. Web services description language (wsdl) 1.1. 2001. Disponível em <http://www.w3.org/TR/wsdl>. Citado na página 21.
COSTA, U. et al. Automatic refinement of service compositions. 2013. Springer Berlin Heidelberg, v. 7977, p. 400–407, 2013. Disponível em: <http://dx.doi.org-
/10.1007/978-3-642-39200-9 33>. Citado 7 vezes nas páginas 18, 19, 20, 24, 43, 44
e 73.
ERL, T. Service-Oriented Architecture (SOA): Concepts, Technology, and Design. Prentice Hall, 2005. ISBN 0131858580. Disponível em: <http://www-
.amazon.com/Service-Oriented-Architecture-SOA-Concepts-Technology/dp-
/0131858580%3FSubscriptionId%3D0JYN1NVW651KCA56C102%26tag%3Dtechkie-
20%26linkCode%3Dxm2%26camp%3D2025%26creative%3D165953%26creativeASIN%3D0131858580
Citado 6 vezes nas páginas 18,28, 29, 31,34 e37.
HAROLD, E. R. XOM. 2013. Acessado em 12/08/2019 às 14:30 horas. Disponível em: <http://http://www.xom.nu/>. Citado na página 55.
KHALAF, R.; MUKHI, N.; WEERAWARANA, S. Service-oriented composition in bpel4ws. In: WWW (Alternate Paper Tracks). [S.l.: s.n.], 2003. Citado 3 vezes nas páginas 27, 28e 38.
KITCHIN, D. et al. The orc programming language. In: LEE, D.; LOPES, A.;
POETZSCH-HEFFTER, A. (Ed.). Formal Techniques for Distributed Systems. Springer Berlin Heidelberg, 2009, (Lecture Notes in Computer Science, v. 5522). p. 1–25. ISBN 978-3-642-02137-4. Disponível em: <http://dx.doi.org/10.1007/978-3-642-02138-1 1>. Citado na página24.
KREGER, H. Web Services Conceptual Architecture. [S.l.]: IBM, maio 2001. WWW. Citado 2 vezes nas páginas22 e23.
MENDLING, J.; LASSEN, K. B.; ZDUN, U. On the transformation of control flow between block-oriented and graph-oriented process modeling languages. IJBPIM, 2008. 2008. Citado na página 28.
MONTESI, F. et al. Jolie: a java orchestration language interpreter engine. Electr. Notes Theor. Comput. Sci., 2007. v. 181, p. 19–33, 2007. Citado na página24.
NETO, P. A. S. et al. Adding contracts to a web service composition language. in: Workshop on languages and tools for multithreaded, parallel and distributed programming. 4th Workshop on Languages and Tools for Multithreaded, Parallel and Distributed Programming, 2010. 2010. Citado na página70.
PAPAZOGLOU, M. et al. Service-oriented computing: State of the art and research challenges. 2007. v. 40, p. 38–45, 2007. ISSN 0018-9162. Disponível em: <http:-
//ieeexplore.ieee.org/xpl/freeabs all.jsp?arnumber=4385255>. Citado na página
21.
PAPAZOGLOU, M. P. Service -oriented computing: Concepts, characteristics and directions. In: Proceedings of the Fourth International Conference on Web Information Systems Engineering. Washington, DC, USA: IEEE Computer Society, 2003. (WISE ’03), p. 3–. ISBN 0-7695-1999-7. Disponível em: <http://dl.acm.org/citation.cfm?id=960322-
.960404>. Citado 2 vezes nas páginas17e 21.
PELTZ, C. Web services orchestration and choreography. Computer, 2003. v. 36, n. 10, p. 46 – 52, oct. 2003. ISSN 0018-9162. Citado na página17.
PETRITSCH, H. Service-oriented architecture (soa) vs. component based architecture. Tech Republic, 2006. February 2006. Vienna University of Technology. Citado na página
17.
POTTINGER, R.; LEVY, A. A scalable algorithm for answering queries using views. In: In Proc. of VLDB. [S.l.: s.n.], 2000. p. 484–495. Citado 2 vezes nas páginas18e 24. W3C, W. W. W. C. Web services architecture requirements. Technical report. 2002. Acessado em 18/06/2010 às 23:00 horas. Disponível em:<http://www.w3.org/TR/2002-
/WD-wsa-reqs-20020429>. Citado na página 17.
WEERAWARANA, S. et al. Web Services Platform Architecture: SOAP, WSDL, WS-Policy, WS-Addressing, WS-BPEL, WS-Reliable Messaging, and More. Prentice Hall, 2005. ISBN 0131488740. Disponível em: <http:/-
/www.amazon.com/Web-Services-Platform-Architecture-WS-Addressing/dp-
/0131488740%3FSubscriptionId%3D0JYN1NVW651KCA56C102%26tag%3Dtechkie-
20%26linkCode%3Dxm2%26camp%3D2025%26creative%3D165953%26creativeASIN%3D0131488740>. Citado 2 vezes nas páginas21 e22.
WHITE, S. A. Using BPMN to Model a BPEL Process. 2005. Disponível em