Avaliação de desempenho de web services orquestrados com BPEL4People

Departamento de Engenharia de Teleinformátia

Programa de Pós-Graduação em Engenharia de Teleinformátia

Avaliação de Desempenho de Web Servies

Orquestrados om BPEL4People

Henrique Jorge Amorim Holanda

Fortaleza Ceará

Departamento de Engenharia de Teleinformátia

Programa de Pós-Graduação em Engenharia de Teleinformátia

Avaliação de Desempenho de Web Servies

Orquestrados om BPEL4People

Autor

Henrique Jorge Amorim Holanda

Orientador

Giovanni Cordeiro Barroso

Co-orientador

Antnio de BarrosSerra

Tese de Doutorado apresentada

à Coordenação do Curso de

Pós-Graduação em Engenharia de

Teleinformátia da Universidade

Federal do Ceará omo parte dos

requisitos para obtenção do grau

de Doutor em Engenharia de

Teleinformátia.

Fortaleza Ceará

Avaliação de Desempenho de Web Servies Orquestrados om

BPEL4People

EstaTesefoi julgadaadequadaparaa obtençãodotítulode Doutor emEngenharia

deTeleinformátiaeaprovadaemsua formanal peloProgramade Pós-Graduação

em Engenharia de Teleinformátia daUniversidade Federal doCeará.

Nome do Aluno

BanaExaminadora:

Prof. Dr. Giovanni Cordeiro Barroso

(Orientador)

Universidade Federal doCeará - UFC

Prof. Dr. Antniode BarrosSerra

(Co-orientador)

lnstitutoFederal de Eduação, Ciêniae

TenologiadoCeará -IFCE

Prof. Dr. Franiso Milton Mendes Neto

Universidade Federal Rural doSemi-Árido

Prof. Dr. Pedro Fernandes RibeiroNeto

Universidade do Estado doRioGrande do

Norte -UERN

Prof. Dr. RossanaMaria de Castro

Andrade

Universidade Federal doCeará - UFC

Prof. Dr. Prof. Dr. José Marques Soares

Universidade Federal doCeará - UFC

W

eb Servies (WS) são pilares para a onstrução de apliações orientadas a serviços. Uma série de linguagens para a omposição de serviços

web têm sido propostas, sendo formado um onsenso em torno da linguagem de

exeução deproessos de negóio(BPEL).BPELentra-se emproessosde negóio

que orquestram interações de WS. No entanto, em geral, proessos de negóio

são ompostos por um amplo espetro de atividades que exigem muitas vezes a

partiipação humana para exeutar tarefas, rever ou aprovar medidas e inserir

dados. Essas interações humanas são abordadas em uma nova espeiação do

BPEL denominada de BPEL4People. BPEL4People introduz a atividade humana

paraBPEL.Com ouso doBPEL4People,modelosformais(omoasredes de Petri)

de BPEL4People têm sido propostos. Com base em modelos formais é possível

a realização de análises formais, tais omo análise de desempenho de modelos

para desobrir possíveis problemas em WS orquestrados om o BPEL4People.

Há duas dimensões importantes para o desempenho de WS: tempo de resposta

e esalabilidade. O tempo de resposta é a apaidade de um sistema de prover

tempos aeitáveis para suas atividades e a esalabilidade é a apaidade de um

sistema de ontinuar a umprir seus objetivos de tempo de resposta quando a

demanda pelo mesmo aumenta. Alguns trabalhos têm sido propostos aera da

análise do desempenho de WS orquestrados om o BPEL. Nesta tese, é proposta

uma arquitetura denominada SOASPE (SOA + SPE) para a transformação de

ódigos BPEL4People em redes de Petri estoástias generalizadas - Generalized

Stohasti Petri Nets (GSPN) e redes de Petri oloridas - Coloured Petri Net

(CPN). Através dos modelos GSPN e CPN de BPEL4People é possível avaliar o

desempenho dos WS orquestrados om oBPEL4People através daomparação dos

SOASPE quando realizadas simulações om a mesma quantidade de requisições.

Durante a transformação de ódigos BPEL4People, as redes de Petri são usadas

paramodelaratividadesBPEL easatividadeshumanas. Então, pelasimulaçãodos

modelosgerados,problemas poteniaisom odesempenhode WSorquestradosom

oBPEL4People podem ser detetados.

Palavras-have: Desempenho, SOA, Web Servie, BPel4People e Redes de

W

eb Servies (WS) are pillars for the onstrution of servie-oriented appliations. Anumberof languagesforweb servieompositionhavebeen

proposed,formedaonsensusonthelanguageofbusinessproessexeution(BPEL).

BPEL fouses onbusiness proesses that orhestrate WSinterations. However, in

general, business proesses are omposed of a broad spetrum of ativities that

often require human involvement to perform tasks, review or approve steps and

enter data. Thesehuman interations are disussed inanew speiation of BPEL

alledBPEL4People. BPEL4People introdues human ativity to BPEL. Withthe

use of BPEL4People, formal models (suh as Petri nets) of BPEL4People have

been proposed. Based on formal models is possible to perform formal analysis,

suh as performane analysis of models to disover potential problems with the

WS orhestrated with BPEL4People. There are two dimensions important to the

performane of WS: response time and salability. The response time isthe ability

of a system to provide an aeptable time for their ativities and salability is the

ability of a system to ontinue to fulll its goals of response time when demand

forit inreases. Some workshave been proposed about the performane analysis of

WS orhestrated with BPEL. In this thesi, it is proposed an arhiteture alled

SOASPE (SOA + SPE) for the transformation of the BPEL4People ode in

generalized stohasti Petri nets (GSPN) and olored Petri nets (CPN). Through

theGSPNandCPNmodelsofBPEL4Peopleispossibletoevaluatetheperformane

ofWSorhestratedwithBPEL4Peoplebyomparingtheirrealresponsetimeswhen

subjeted to a number of requests and response times of the GSPN and CPN

models generated by the arhiteture SOASPE when simulations with the same

amount of requests. During the transformation of BPEL4People ode, Petri nets

BPEL4People an be deteted.

FranisaAmorim, aminhaesposa CarlaMonteiro,aos meus lhosPedroHenrique

eJulianaeatodosmeus familiareseamigosquede formaimpresindíveleamorosa

ontribuirampara a realização desta.

"Nãobasta que seja pura ejusta anossa ausa. É neessário que apureza e a

Gostaríamos de agradeer aos olegas do Centro Politénio Superior (CPS) da

UniversidadedeZaragoza(UNIZAR)-EspanhaedoLaboratóriodeComputaçãodo

Departamento de Físia daUniversidade Federal doCeará, naajudae olaboração

no desenvolvimento do arquitetura SOASPE. Gostaríamos também de agradeer

ao Professor Giovanni Cordeiro Barroso por nossas interessantes disussões sobre

vários aspetos deste trabalho. Um obrigado espeial ao Professor José Merseguer

Hernáizporareditarnaminhaapaidadeeporestarpresentenodesenvolvimento

deste trabalho e por suas freqüentes revisões nas várias etapas da onepção,

implementação e publiações aera desta tese. Finalmente, agradeço a todos

aquelesquediretaeindiretamenteestiveramenvolvidos naexeuçãodestetrabalho.

Tambémagradeçooapoioeoestímuloofereidosporminhaesposa CarlaMonteiro

0.1 Publiações Naionais

◮

Henrique J. Holanda, G. Barroso, Antonio de B. Serra and José Merseguer

Hernáiz, Performane Evaluation of BPEL4People Speiations Integrate

HumanInterations Into Business Proess, SBSI, Marabá-Pa,Junho, 2010.

◮

Henrique J. Holanda, G. Barroso and Antonio de B. Serra, SOASPE: a

Frameworkforthe Performane AnalysisofServie OrientedSoftware,SBSI,

pp.204-215,May 2009,Brasilia.

◮

Holanda, Henrique Jorge A., Barroso, Giovanni Cordeiro, Serra, Antonio de

Barros (2009) Performane Analysis of Servie Oriented Software, In: iSys

- Revista Brasileira de Sistemas de Informação, Volume II, ISSN eletrnio

1984-2902,2009.

0.2 Publiações Internaionais

◮

HenriqueJ. AmorimHolanda, Giovanni Cordeiro Barroso,Carla K.Monteiro

Marques, Antonio de Barros Serra, Vando A. S. Alves, Human Interations

Formalization in Web Servies Orhestrated with BPEL4People in the

Perspetive of Performane Evaluation, Journal of Information Sienes

-Elsevier,2012. (Obs.: artigo aeitoa ser publiadoom alteraçõesa menor).

◮

Henrique J. Holanda, G. Barroso, Antonio de B. Serra and José

Merseguer Hernáiz, Performane Analysis of Web Servies Orhestrated

with WS-BPEL4People, International journal of Computer Networks &

Communiations - IJCNC, volume 2, number 5, ISSN 0974 - 9322 (Online),

2010.

on Computing in the Global Information Tehnology, Valenia, Spain,

September 20-September 25, ISBN: 978-0-7695-4181-5, 2010. doi =

http://doi.ieeeomputersoiety.org/10.1109/ICCGI.2010.41,2010.

◮

Henrique Jorge A. Holanda, Giovanni Cordeiro Barroso, Antonio

de Barros Serra, SPEWS: A Framework for the Performane

Analysis of Web Servies Orhestrated with BPEL4WS, ICIW,

pp.363-369, Fourth International Conferene on Internet and

Web Appliations and Servies, ISBN: 978-0-7695-3613-2, doi =

http://doi.ieeeomputersoiety.org/10.1109/ICIW.2009.60. Venie/Mestre,

Publiações do Autor viii

0.1 Publiações Naionais . . . viii

0.2 Publiações Internaionais . . . viii

Lista de Figuras xv Lista de Tabelas xvi Lista de Siglas xvii 1 Introdução 1 1.1 Justiativas eMotivações . . . 3

1.2 Hipótese eObjetivos doTrabalho . . . 4

1.2.1 Objetivos . . . 4

1.3 Trabalhos Relaionados. . . 5

1.4 Organização doTrabalho . . . 8

2 Conheimentos Preliminares 9 2.1 Engenharia de Performane de Software -SPE . . . 9

2.1.1 Denição de SPE . . . 10

2.1.2 Visão Geral daSPE . . . 11

2.1.3 O Proesso de ModelagemdaSPE . . . 13

2.2 Arquitetura Orientada a Serviços (SOA) . . . 14

2.2.1 Denição de SOA . . . 16

2.2.2 Benefíios eDesaos de uma ArquiteturaSOA . . . 17

2.2.3 Prinipais Termos eDenições de SOA . . . 18

2.2.4 Prinípios de SOA . . . 19

2.2.5 As Camadas de uma Arquitetura SOA . . . 22

2.2.6 SOA e a TenologiaWeb Servies . . . 23

2.2.7 Estratégias de Desenvolvimento e ImplementaçãoSOA . . . . 24

2.3 Web Servies (WS) . . . 25

2.4 Modelos Formais . . . 27

2.4.1.2 Redes de Petri Temporizadas Determinístias . . . . 33

2.4.1.3 Redes de Petri Estoástias Generalizadas . . . 34

2.4.2 Álgebras de Proessos . . . 36

2.4.3 Linguagem Z . . . 37

2.5 Conlusões doCapítulo. . . 38

3 BPEL e BPEL4People 40 3.1 Coneitos Fundamentaisde BPEL . . . 40

3.1.1 Síntese doFunionamentodo BPEL . . . 44

3.2 Coneitos Fundamentaisde BPEL4People . . . 44

4 A arquitetura SOASPE 47 4.1 A Camada SOA . . . 49

4.2 A Camada BPEL . . . 50

4.3 A Camada de Transformação . . . 50

4.3.1 Regras de Transformação de BPEL em GSPN . . . 52

4.3.1.1 Transformação de AtividadesBásias . . . 53

4.3.1.2 Transformação de AtividadesEstruturadas . . . 53

4.3.1.3 Atribuições Temporaisà GSPN . . . 55

4.3.2 Regras de Transformação de BPEL em CPN . . . 58

4.3.2.1 Transformação de AtividadesBásias . . . 59

4.3.2.2 Transformação de AtividadesEstruturadas . . . 61

4.3.2.3 Atribuições Temporaisà CPN . . . 62

4.4 A Camada Rede de Petri . . . 64

4.5 A Camada de Desempenho . . . 65

4.5.1 Análise de Desempenho de Códigos BPEL Modelados em GSPN e emCPN . . . 65

4.5.1.1 Desempenho doWS SodaSys . . . 67

4.5.1.2 Desempenho do Modelo GSPN Gerado pela Arquitetura SOASPE . . . 68

4.5.1.3 Desempenho do Modelo CPN Gerado pela Arquitetura SOASPE . . . 73

4.6 Conlusões doCapítulo. . . 75

5 SOASPE: Modelagem das Interações Humanas em GSPN e em CPN 78 5.1 Restriçõesde Autorização . . . 79

5.1.1 Separação de Direito- Separation of Duty . . . 79

5.1.2 Vinulação de Direito- Binding of Duty . . . 80

5.2 Modelagemde BPEL4People emGSPN. . . 80

5.2.1 Transformação da Extensão Humana WS-HumanTask do BPEL4People emGSPN . . . 81

em GSPN . . . 84

5.2.2.2 Modelo GSPNpara o Web ServieWS PurhSys . 85 5.2.2.3 Análise de Desempenho do Modelo GSPN para o WS PurhSys . . . 86

5.3 Modelagemde BPEL4People emCPN . . . 87

5.3.1 Transformação da Extensão Humana WS-HumanTask de Códigos BPEL4People emCPN . . . 88

5.3.2 Atribuições Temporais ao modelo CPN da extensão humana WS-HumanTask de Códigos BPEL4People . . . 89

5.3.3 Estudo de aso de Transformação de BPEL4People para CPN 90 5.3.3.1 Modelo CPNpara o WS-PurhSys . . . 90

5.3.3.2 Análisede DesempenhodoModeloCPNparaoWS PurhSys . . . 91

5.4 Conlusões doCapítulo. . . 92

6 SOASPE: Projeto e Implementação de uma Ferramenta TPeople4PN 94 6.1 O Projeto e aImplementaçãodaFerramenta TPeople4PN . . . 94

6.1.1 A Interfae daFerramenta TPeople4PN . . . 95

6.1.2 A Classe DomParse . . . 96

6.1.3 As Classes CreatePetriNet e GreatSPNFileWriter . . . 99

6.1.3.1 A Classe CreatePetriNet . . . 99

6.1.3.2 A Classe GreatSPNFileWriter . . . 104

7 Conlusões e Trabalhos Futuros 106 7.1 Contribuiçõesdo Estudo . . . 106

7.2 Limitaçõeseproposições . . . 107

7.3 Considerações nais . . . 107

7.4 Trabalhos Futuros. . . 107

2.1 O proesso de modelagemSPE (SMITH, 1989). . . 14

2.2 Operações pertenentes a diferentes serviços representam várias partes de um proesso de negóios lógio. . . 19

2.3 Camada de serviços posiionada entre as amadas de proessos de negóioe de apliação (SCHULTE;NATIS, 2006). . . 22

2.4 Paradigmaproura-onsolida-exeuta,adaptadode (ARSANJANI,2004). 24 2.5 Arquitetura adotadapelos WS (LUDWIG, 2003) . . . 26

2.6 Hierarquia emRPC de um sistema de manufatura. . . 30

2.7 Desrição em RPC dapágina Prinipalde um sistemade manufatura. 31 2.8 Desrição emRPC dapágina t2de um sistemade manufatura.. . . . 33

2.9 Exemplo de Rede de Petri Temporizada. . . 34

2.10 Exemplo de Rede de Petri EstoástiaGeneralizada. . . 35

3.1 FunionamentodoBPEL (VERBEEK, 2005). . . 44

4.1 Arquitetura SOASPE (HOLANDAG.C.BARROSO,2009b). . . 48

4.2 Composição dos proessos de negóios (HOLANDA G.C. BARROSO, 2009b). . . 49

4.3 A funionalidade da amada de transformação (HOLANDA G.C.BARROSO, 2009b). . . 51

4.4 Representação dos serviços básiose atividadesbásias emGSPN. . . 52

4.5 Representação da estrutura de sequênia emGSPN. . . 53

4.6 Representação da estrutura de ondição em GSPN. . . 54

4.7 Representação da estrutura de repetição emGSPN. . . 55

4.8 Representação da estrutura

<

Pik

>

em GSPN. . . 55

4.9 Representação da estrutura

<

Flow

>

em GSPN. . . 56

4.10 Cálulo do

σ

, CV e

λ

(SILVA; LINS, 2006). . . 57

4.11 Código BPEL. . . 58

4.12 Rede GSPN doCódigo BPEL da Figura 4.11. . . 59

4.13 Sequênia de transformação eanálise de BPEL emCPN. . . 59

4.14 Atividade

<

Reeive

>

modeladaemCPN. . . 60

4.15 Atividade

<

Reply

>

modeladaem CPN. . . 60

4.17 Atividade

<

Empty

>

modeladaemCPN. . . 61

4.18 Tipos oloridosdas redes CPN dos ódigos BPEL4People. . . 61

4.19 Estrutura

<

Sequene

>

modeladaemCPN. . . 62

4.20 Estrutura

<

Swith

>

modeladaemCPN. . . 63

4.21 Estrutura

<

While

>

modelada emCPN. . . 64

4.22 Estrutura

<

Pik

>

modelada emCPN. . . 65

4.23 Estrutura

<

Flow

>

modelada emCPN. . . 66

4.24 Rede CPN doCódigo BPEL daFigura 4.11.. . . 67

4.25 Código BPEL de orquetração doweb servie -WS SodaSys. . . 68

4.26 Tempos de resposta do WS SodaSys e do modelo GSPN gerado a partir daarquitetura SOASPE para o WSSodaSys. . . 74

4.27 EiêniadaarquiteturaSOASPE naanálisededesempenhodeWS orquestrados peloBPEL4 emGSPN. . . 75

4.28 Tempos de resposta do WS SodaSys e do modelo CPN gerado a partir daarquitetura SOASPE para o WSSodaSys. . . 77

4.29 EiêniadaarquiteturaSOASPE naanálisededesempenhodeWS orquestrados peloBPEL4 emCPN. . . 77

5.1 Exemplo de tarefa humana -WS-HumanTask. . . 79

5.2 Representaçãodas atividadesbásiasedosusuáriospoteniaisdeum serviço em GSPN. . . 81

5.3 Fluxo de transformação da extensão humana WS-HumanTask em GSPN. . . 81

5.4 Algoritmo de transformação da extensão humana WS-HumanTask emGSPN. . . 82

5.5 Algoritmo de riação daárvore de interaçõeshumanas. . . 83

5.6 Árvore representativa daextensão humanaWS-HumanTask. . . 83

5.7 Código BPEL4Peole. . . 84

5.8 BPEL4People para aorquestração do WSPurhSys. . . 85

5.9 Modelo GSPNpara Código BPEL4People do WSPurhSys. . . 86

5.10 Tempos de resposta do WS PurhSys e domodeloGSPN gerado a partir daarquitetura SOASPE para o WSPurhSys.. . . 87

5.11 Eiênia do framework SOASPE para análise de desempenho de WS orquestrados peloBPEL4People emGSPN. . . 88

5.12 Tipos oloridosdas redes CPN dos ódigos BPEL4People. . . 88

5.13 Representaçãodas atividadesbásiasedosusuáriospoteniaisdeum serviço em CPN. . . 89

5.14 Modelo CPNpara Código BPEL4People doWS-PurhSys. . . 91

5.15 Tempos de resposta do WS PurhSys e do modelo CPN gerado a partir daarquitetura SOASPE para o WSPurhSys.. . . 92

5.16 Eiênia do framework SOASPE para análise de desempenho de WS orquestrados peloBPEL4People emCPN. . . 93

6.1 Interfae da ferramenta TPeople4PN om arquivo XML do BPEL4People. . . 95

6.4 O proesso de parsear um XML om a API DOM. . . 98

6.5 O mapa DOM. . . 98

6.6 Interfaes daAPI DOM. . . 99

6.7 Função de leitura daárvore gerada pelalasse DomParser. . . 100

6.8 Função OperaçãoBasia. . . 101

6.9 Função de riação de transições. . . 101

6.10 Função de riação de lugares. . . 102

6.11 Função de riação de aros. . . 102

6.12 Função de leitura de arquivosde tempos: dos provedores de serviços e dos usuários (poteniaisexeutores dos serviços). . . 103

6.13 Função de aproximação dos temposde resposta dos SP. . . 104

2.1 Prinipaisdeniçõesde SOA (SCHULTE;NATIS, 2006). . . 20

3.1 Primitivasbásias usadasem uma omposição de serviço BPEL. . . . 43

4.1 Tempos de resposta dos provedores de serviços do WSSodaSys. . . 69

4.2 Tempos de resposta doódigo BPEL doPNI do WSSodaSys. . . . 69

4.3 Média e desvio padrãodos provedores de serviços: Serv-1, Serv-2, ...

, Serv-9. . . 71

4.4 CV e tipoda aproximação. . . 71

4.5 Tempo de atraso dos SPs: Serv-1, Serv-2, ... ,Serv-9. . . 72

4.6 Tempos de resposta dasimulação nomodelo GSPN doWS SodaSys. 73

BPEL Business Proess Exeution Language-Linguagem de Exeução

de Proessos de Negóio

BPEL4People Linguagem de Exeução de Proessosde Negóiopara pessoas

BP Business Proess -Proessos de Negóios

BPM Business Proess Management- Gereniamentode Proessos de

Negóios

CPN Colored Petri Net- Redes de Petri oloridas

GSPN Generalized Stohasti Petri Nets - Rede de Petri Estoástia

Generalizada

LQN Teoria das listas

OASIS Organization for the Advanement of Strutured Information

Standard

PASA Performane Assessment of Software Arhitetures -Método de

avaliação de desempenho de arquiteturas de software

QN Queuing netwoks

RP Redes de Petri

SOA ServieOrientedArhitetures-ArquiteturaOrientadaaServiço

SPE Software Performane Egineering - Engenharia de Performane

de Software

SOASPE Junção das siglas SOA e SPE (SOA +SPE)

SOA Servie-OrientedArhiteture- ArquiteturaOrientada aServiço

SOAP Simple Objet Aess Protool

SPE Software Performane Engineering-Engenhariade performane

de software

SPN StohastiPetri Nets - Redes de Petri Estoástias

RP Redes de Petri

UDDI Universal Desription, Disovery, and Integration

UML Unield Moleling Language

XML Extensible Markup Language - Linguagem Extensível de

Formatação

WSDL WebServies DesriptionLanguage-LinguagemdeDesriçãode

Serviços Web

WS Web Servie

Capítulo

1

Introdução

Em um mundo ompetitivo, as empresas estão naturalmente interessadas

em tenologia da informação para ganhar vantagem ompetitiva. Dado que a

ooperação se torna ada vez mais importante para as empresas, surgem novos

desaos para o apoio às empresas em enários de negóios om tenologia da

informação. Emboraasempresasjáutilizemsistemastradiionaisde gereniamento

de workow, alinguagem padrão de exeução de proesso BPEL (BusinessProess

ExeutionLanguage) permiteaespeiaçãodeproessosepermitequeasempresas

olaboremumasomasoutrasatravésdainteraçãode proessosdenegóios. BPEL

pode ser usada em proessos automatizados entre empresas que utilizam serviços

respetivos (SELVAGE D. WOLFSON, 2005). No entanto, o enário óbvio de um

proesso de negóio que depende de uma pessoa para umprir uma determinada

tarefahumanaomoum tipode atividadedoproessonão éabrangido peloBPEL.

O BPEL vem se tornando o padrão para a espeiação e a exeução de

omposição de Web Servies (WS). A maior desvantagem do BPEL é a falta do

hamado uxo de trabalho humano. A espeiação BPEL4People (Business

Proess Exeution Language for people) tenta minimizar a presente desvantagem,

adiionandosuporte à tarefa humana para BPEL (ADOBEetal.,2007).

Como já menionado, o BPEL não trata do uxo de trabalho humano. Nos

proessos de negóio de longa duração, as tarefas que requerem o envolvimento

humano são muito frequentes. Um proesso pode esperar para a entrada de

partiipantes humanos ou WS, e a entrada deve ser oletada dentro de um

deve ser notiado para deidir omo o proesso deve proeder. Como itado

em (HOLANDA G.C. BARROSO, 2010a): a interação do usuário humano não está

atualmenteabrangidapeloBPEL,queéprinipalmentedestinadoaapoiarproessos

denegóios automatizadosbaseadosemWS.Naprátia,porém,enáriosde vários

proessos de negóio requerem interação do usuário. A introdução da interação

humana tambémleva aoutros oneitos, tais omo papéise permissões, que fazem

oprojetoeaveriaçãodeuxosdetrabalhohumanoaindamaisdifíeis (HOLANDA

G.C.BARROSO,2010b).

Para apoiar e padronizar as atividades humanas em BPEL, BPEL4People é

propostopelaIBM-SAP,quedesreveosreursosparaapoiarasatividadeshumanas

dentro de padrões existentes no BPEL, e introduz o prinípio de tarefas manuais

exeutadas por partiipantes humanos. Alguns problemas omo autorizações de

tarefas, tambémsão desritos naespeiação BPEL4People.

OBPEL4People inlui duas espeiações: WS-BPELextensão para aspessoas

eWS-HumanTask (ADOBEetal.,2007). Aprimeiraestende alinguagemBPELom

atividade humana e a torna uma invoação de serviço da Web normal. A última

deneoneitos, taisomo papéis humanos,tarefas e permissões usadas noâmbito

das atividades de pessoas. Uma vez que ambas devem ser usadas em onjunto

para omporum uxo de trabalho humano, elas são referidas omo um todoneste

trabalho.

Com o uso do BPEL4People, modelos formais (omo redes de Petri) de

ódigos-fonte BPEL4People têm sido propostos. Estes modelos não só ajudam a

ompreender melhor a espeiação, mas também ofereemsubsídios para análises

mais importantes no BPEL4People. Além disso, om base no modelo formal

pode-se simular o desempenho de modelos e assim desobrir possíveis problemas

de gargalos em ódigos-fonte BPEL4People (HOLANDA G.C. BARROSO, 2010a;

HOLANDA;BARROSO;SERRA, 2010; HOLANDAG.C.BARROSO,2009a).

Redes de Petri estoástias generalizadas - Generalized Stohasti Petri Nets

(GSPN) e redes de Petri oloridas - Coloured Petri Net (CPN) são extensões de

redes de Petri lássias. Existem várias razões para a esolha das GSPN e das

CPN omo linguagens de modelagem de distribuição de trabalho no ontexto da

BPEL4People. Primeiro, elas têm semântia formale permitem diferentes tipos de

lugar, elas são gráas e suas notações são semelhante às linguagens de uxo de

trabalho existentes. Finalmente, a linguagem GSPN é apoiada pela ferramenta

GREATSPN 1

e a linguagem CPN é apoiada pela ferramenta CPN tools 2

, que são

ambientes gráospara modelar e analisarGSPNe CPN, respetivamente.

Estatesemotiva-seporquestõesrelaionadasomadeniçãodeumaarquitetura

denominada SOASPE (SOA + SPE) para a transformação da BPEL4People em

GSPNe emCPN edesta formaavaliaro seu desempenho.

1.1 Justiativas e Motivações

O desenho e implementação de sistemas de omputadores é uma tarefa difíil.

Por esta razão, nos últimos anos as tarefas de modelagem,validação, avaliação de

desempenho e implementação destes sistemas têm sido abordadas juntamente om

propostas de modelosformais.

Rede de Petri (RP) é um modelo formal que pode auxiliarno desenvolvimento

de todo o ilo de vida dos sistemas (DYER; ZULAUF, 2005). As RP têm sido

usadas para modelar e avaliar sistemas de manufatura (LAW; KELTON, 2000),

arquiteturas multi-proessadas (KELTON; SADOWSKI; SADOWSKI, 2002), sistemas

de omuniação (BILLINGTON;DIAZ; ROZENBERG, 1999) e também para avaliar a

eiênia de sistemas de omputador (AALST, 1998).

Desdequeaanálisede desempenhodesoftwarenãoéumaprátiaquevemsendo

apliadausualmentenodesenvolvimentodesoftware,torna-seneessáriaaexistênia

de uma integração de modelos de análise de desempenho om metodologias de

desenvolvimento de sistemas e ferramentas que as implementam. Cadeias de

Markov, álgebra estoástia e Redes de Petri Estoástia - Stohasti Petri Nets

(SPN) são bons paradigmas de modelos de desempenho. As redes de Petri

estoástiassedestaampelasuaadequaçãoomamodelagemde sistemasparalelos

edistribuídos,simpliidadematemátia,seu poderde generalização,sua adequação

de expressar todas as semântias básias de onorrênia, sua fáil representação

gráa, sua fáil deteção de estados e ações, sua boa quantidade de ténias de

análise quantitativa e qualitativa e mais a existênia de ferramentas de análise ao

seu dispor (MARSANet al.,1998).

1

http://www.di.unito.it/~greatspn

2

Esta tesesejustia nodesenvolvimentode sistemasde softwarequepreenham

osobjetivos de desempenho.

Desempenho é o grau em que um sistema de software ou omponente deste

satisfaz a seus objetivos temporais de forma aeitável. Para atingir estes objetivos

muitos autores defendem o prinípio de que a análise de desempenho deve ser

inluída no prinípiodo projeto de desenvolvimento do software. Como o desenho

e implementação de sistemas de omputadores é uma tarefa difíil, nos últimos

anos as tarefas de modelagem, validação, avaliação de desempenho (performane)

eimplementação destes sistemastêm sido abordadasjuntamenteom propostas de

modelos formais. Neste ontexto, redes de Petri (RP) é um modelo formal que

pode auxiliarnodesenvolvimentode todooilo de vidados sistemas (BRINKSMA;

HERMANNS;KATOEN, 2002).

Há duas dimensões importantes para o desempenho de softwares: tempo de

resposta eesalabilidade.

Otempo de resposta é aapaidade de um sistema de prover tempos aeitáveis

parasuasatividades. Emsistemasdetemporeal,otempoderespostaéumamedida

dequãorápidoosistemarespondeaumevento,ouonúmero deeventosquepodem

ser proessados em um determinadoinstante.

A esalabilidade é a apaidade de um sistema de ontinuar a umprir

seus objetivos de tempo de resposta quando a demanda pelo mesmo aumenta.

Esalabilidade é uma propriedade muito importante para os sistemas de

softwares (BRINKSMA;HERMANNS;KATOEN,2002).

Ébaseada na satisfaçãodestasduas dimensõesque este trabalhode tese propõe

aarquitetura SOASPE.

1.2 Hipótese e Objetivos do Trabalho

Para a onretização desta tese parte-se da seguinte hipótese: possibilidade

de formalização das interações humanas (WS-HumanTask) nos Web Servies

orquestrados om oBpel4Peple naperspetiva de avaliaçãode desempenho.

1.2.1 Objetivos

◮

desenvolvimentoeespeiaçãode umaarquiteturaSOASPE paraavaliação

de desempenho de web servies orquestrados através de ódigos BPEL

(extensãopara pessoas - BPEL4People);

◮

espeiar regras eestruturas para onversão de ódigos:

•

BPEL4People (Bpele WS-HumanTask) emGSPN; e

•

BPEL4People (Bpele WS-HumanTask) emCPN.

◮

desenvolver algoritmos para atribuição de tempo de atraso das transições

atravésde ténias de análisede funçõesde distribuiçãode probabilidade;

◮

desenvolver um módulo de aptura de tempo de resposta de serviços

automatizadoseserviços om a partiipaçãohumana;

◮

avaliação de desempenho de WS orquestrados om o BPEL4People através

da simulação em modelos (GSPN e CPN) obtidos a partir da arquitetura

SOASPE;

◮

análise omparativa dos resultados de avaliação de desempenho dos modelos

emGSPN e dos modelos em CPN de WS orquestrados om o BPEL4People;

e

◮

desenvolver umaferramentae umainterfaepara onversão de BPEL4People

emGSPN.

◮

estudosde asos.

1.3 Trabalhos Relaionados

Engenharia de performane de software - Software Performane Engineering

(SPE)equalidade deservivos(QoS)noontexto de web servieéo temade muitos

estudos.

Em (MENASCé;ALMEIDA, 2001)foi desenvolvida umametodologiade avaliação

de desempenho de web servies. Sua metodologia é foada no planejamento de

apaidade usando teoria das listas - Queuing netwoks (QN). A metodologia de

(MENASCé;ALMEIDA, 2001)difere da metodologiadesta tese quese utilizade redes

OWeb Servie Trust Center(WSTC)éuma plataformapara desenvolvimento e

avaliação de ferramentas de medição e ténias na área de arquitetura orientada

a serviço - Servie Oriented Arhitetures (SOA) e serviços web. Uma de

suas publiações, intitulada Performane modeling of WS-BPEL based web

servie ompositions (RUD; SCHMIETENDORF; DUMKE, 2006), aborda aspetos

da qualidade de serviço de orquestrações de serviços da Web riados usando o

WS-BPEL do ponto de vista de um integrador de serviços web. Um modelo

matemátio baseado em ténias de pesquisa operaional e semântia formal de

WS-BPEL é proposto para estimar e prever a inuênia da exeução de proessos

orquestrados sobre a utilização e rendimento de ada um dos nós envolvidos e do

sistemaomo um todo. Este modelo é apliadopara a otimização de proessos, de

aordoom os níveis de serviço entre as partes envolvidas.

O trabalho aqui proposto se diferenia daquele apresentado em (RUD;

SCHMIETENDORF;DUMKE,2006),pelofatodeusarRPparaavaliarodesempenhoda

orquestraçãode WS orquestrados omBPEL4People enão um modelo matemátio

puroomoosautoresdessaproposta. AdiferençadeusarRPéqueelastambémsão

modelos matemátios, om a vantagem de proporionar uma boa visão do modelo

dosistema.

Em (SILVA; LINS, 2006), serviços web têm desempenhado um papel importante

no desenvolvimento de sistemas distribuídos. Em partiular, a possibilidade

de omposição de web servies já implementados, a m de proporionar uma

nova funionalidade é uma abordagem interessante para a onstrução de sistemas

distribuídos. No entanto, a esolha da melhor omposição ainda é um desao,

omoqualidadesdiferentesaseremobservadas naomposição,taisomosegurança,

desempenho e tolerânia a falhas. Neste ontexto, o referido artigo propõe uma

metodologia baseada emredes de Petri estoástias para modelar, avaliare ajudar

aesolher omposiçõesweb servies,onsiderando os aspetos de desempenho.

O trabalho aqui proposto se diferenia daquele apresentado em (SILVA; LINS,

2006), por estar interessado em avaliar o desempenho dos WS orquestrado pelo

BPEL4People e não apenas na omposição dos serviços web orquestrados pelo

BPEL. O maior interesse do trabalho aqui proposto é denir uma arquitetura

que possa ser usada para análise de desempenho de WS orquestrados om o

Em (CHANDRASEKARAN et al., 2003), os autores propõem uma ténia de

simulação para analisar o desempenho de serviços web ompostos, a m de obter

proessos web eientes. O referido artigo desreve a omposição e exeução da

ferramenta(SCET)ediferentesmetodologiasquepoderiamseradotadasparaavaliar

o desempenho de um proesso de web. A ferramenta (SCET) permite ompor

serviçosestatiamenteusandoseus modelos(desenhos)earmazenando-osomoWeb

ServieFlowLanguage(WSFL).A exeuçãodeum proesso permitepereberasua

funionalidadee tambémanalisaro seu desempenho.

Em (NARAYANAN; MCILRAITH, 2003), Narayanan e seu grupo utilizam-se da

ontologia (DAML-S) para desrever os reursos de WS e denir a semântia de

um subonjunto relevante de (DAML-S) em termos de uma linguagem de lógia

de primeira ordem. Com o uso da referida semântia, eles odiam desrições de

serviços em redes de Petri e ofereem proedimentos de deisão para simulação,

veriação e omposiçãode WS.

Em (GÓMEZ-MARTÍNEZ; MERSEGUER, 2006), os autores fazem, a partir da

literatura, um estudo do desempenho de WS. Este estudo, baseado na teoria das

listas - Queuing Networks (QN), é abordado na sequênia da abordagem (PUMA)

paraobterumnovomodelodedesempenho,nesteasoemtermosde redesde Petri.

Menase, em seu trabalho (MENASCE, 2004), pressupõe que a arquitetuta

orientada a serviços (SOA) permite uma innidade de prestadores de serviços na

prestação de serviços de baixo aoplamento. Seu trabalho onsidera proessos de

negóioompostos poratividadesquesão suportadosporprovedores de serviços. A

estrutura de um proesso de negóiopode ser expressa porlinguagens omo BPEL

e permite onstruções omo: sequênia, enquanto, uxo, e esolha. Assim, seu

artigo aborda o problema de enontrar o onjunto de prestadores de serviço que

minimizamotempo total de exeução do proesso de negóios sujeitos a restrições

de tempoe usto de exeução. Este problema élaramente NP-difíil. No entanto,

o trabalhoapresenta um algoritmootimizado que enontra a solução ideal sem ter

de explorar o espaçoamostral de toda a solução. Este algoritmopode ser utilizado

paraenontrar asoluçãoótima emproblemas de tamanhomoderado. Uma solução

heurístiatambéméapresentadaeosestudosexperimentaisqueomparamamelhor

solução e a heurístia mostram que o tempo de exeução médio obtido om uma

dotaçãoheurístia dos prestadoresde serviços não ultrapa6% do tempoda solução

Em (DUN; XU; WANG, 2008), a omposição de WS envolve a ombinação

de um onjunto de serviços existentes para riar um serviço de valor agregado.

BPEL é uma linguagem promissora que desreve a omposição de web servie em

forma de proessos de negóios. O BPEL é uma linguagem baseada em XML e

faz-se neessário analisar os proessos de negóios espeiados em BPEL em uma

ferramenta formal. Emseu artigo (DUN;XU; WANG, 2008), os autores apresentam

uma abordagem para o modelo e o verição om base em BPEL ServieNet, uma

lasseespeial de redes de Petri. Elesapresentam algumas regrasde transformação

dos proessos de negóio em BPEL ServieNet. Em seguida, a análise de um

proesso de negóio BPEL pode ser veriada através da redução da ServieNet

orrespondente om base em algumasregras de redução.

1.4 Organização do Trabalho

Esta tese enontra-se organizada, além deste apítulo introdutório, da seguinte

forma. No Capítulo 2são introduzidosonheimentospreliminaresemEngenharia

de Performane de Software (SPE), Arquitetura Orientada a Serviços (SOA), Web

Servies e Modelos Formais, que são neessários para a ompreensãoda tenologia

da arquitetura SOASPE. No Capítulo 3 são abordos BPEL e BPEL4People que

são as linguagens de orquestração de WS utilizadas pela arquitetura SOASPE.

No Capítulo 4 é apresentada a arquitetura SOASPE. O Capítulo 5 apresenta

a modelagem das interações humanas em GSPN e em CPN. Uma ferramenta

automátiadeonversãodeBPEL4PeopleemGSPN,denominadadeTPeople4PN,

é apresentada no Capítulo 6. São apresentadas no Capítulo 7 as onlusões e as

sugestõesde trabalhos futuros para aontinuação dos estudosna linha de trabalho

Capítulo

2

Conheimentos Preliminares

Neste apítulo são apresentados os assuntos que formam a base do

desenvolvimento deste trabalho. Iniialmente, na Seção 2.1 é introduzida a

Engenhariade Performane de Software - SoftwarePerformane Egineering(SPE).

Na Seção 2.2 é oneituada Arquitetura Orientada a Serviços - Servie Oriented

Arhiteture (SOA) referente a negóios e requisitos tenológios. A tenologia de

Web Wervies (WS) édesritanaSeção 2.3omouma implementaçãode SOA.Na

Seção 2.4 é apresentada uma visão geral sobre modelos formais om enfoque em

redesde Petri -Petri Nets (PN) esuas extensões GSPNe CPN.

2.1 Engenharia de Performane de Software - SPE

Desempenho (performane) é fundamental para o suesso de um projeto de

software. No entanto, muitos softwares não satisfazem osobjetivosde desempenho

quando da sua onepção iniial. A solução destas insatisfações é ara e ausa

atrasos de ronograma, perda de produtividade, e uma série de outras diuldades

(WESTERGAARD; LASSEN, 2006). Nesta seção é apresentada a Engenharia de

Performane de Software (SPE), uma abordagem sistemátia quantitativa para

onstruir sistemas de software que preenham os objetivos de desempenho. A SPE

deve omeçar a ser utilizada no iníio do proesso de desenvolvimento de software

paraumapropostade arquiteturadedesenho de altonível. Nestatarefa osmodelos

ajudam a identiar poteniais problemas de desempenho quando eles podem ser

2.1.1 Denição de SPE

Embora a funionalidade de uma apliação de software seja obviamente

importante, esta não deve ser a únia preoupação. Durante a vida útil de

um software, seu usto deve ser determinado mais pela maneira omo ele deve

atingirosseusobjetivosemmatériadequalidadeomodesempenho,onabilidade,

disponibilidade e manutenibilidade, do que por sua funionalidade (CHEN; CHEN;

SHAO,2003).

Estaseçãoentra-senaoneituaçãodedesenvolvimentode sistemasde software

que preenham os objetivos de desempenho. Desempenho é o grau em que um

sistema de software ou omponente deste satisfaz a seus objetivos temporais de

formaaeitável. Assim, o desempenho é qualquer araterístia de um produto de

softwarequevoêpoderia,emprinípio,mediromumronmetronamão (SMITH,

1989).

Há duas dimensões importantes para o desempenho de software: tempo de

resposta e esalabilidade. Tempo de resposta é a apaidade de um sistema de

provertemposaeitáveisparasuas atividades. Emsistemasde temporeal, otempo

de resposta é uma medida de quão rápido o sistema responde a um evento, ou o

número de eventos que podem ser proessados em um determinado instante. A

esalabilidadeé a apaidade de um sistema de ontinuar a umprir seus objetivos

de tempo de resposta quando a demanda pelo mesmo aumenta. Esalabilidade é

umapropriedade muito importantepara os sistemasde software (SMITH, 1989).

Desempenhoéfundamentalparaosuessodos sistemasdesoftware. Noentanto,

amaioriados projetos de softwarenão tem a preoupação de avaliarodesempenho

doseu produto na fase iniial. A avaliação de desempenho somenteé feita quando

o software já está implementado e em produção. Neste aso a orreção destes

problemas é onerosa e provoa atrasos de ronograma, perda de produtividade, e

umasérie de outras diuldades. Emasos extremos,pode não ser possível orrigir

problemasde desempenhosemumaextensareformadoprojetológioeonsequente

re-implementação. Nesses asos, o projeto ou se torna um onsumidor innito de

tempo edinheiro, oué inondiionalmenteanelado (SMITH, 1989).

Odesempenhodeveserobjetodeanálisedesdeoiníiodoprojetodosoftware. O

fazer exeutar, fazê-lofunionar direito e após torná-lo rápido é uma abordagem

SPE.

A SPE é uma abordagem sistemátia quantitativa para onstruir sistemas de

software que preenham objetivos de desempenho. Ela dene prinípios para a

riação de software om bom desempenho, dene também parâmetros neessários

paraaavaliaçãode desempenho desoftwareeorientaçõespara ostiposde avaliação

dedesempenhoquedevemserrealizadasemadafasedodesenvolvimentodosistema

de software. A SPE inorpora a modelos de representação, seus prinípios de

avaliação de desempenho, bem omo um onjunto de métodos de análise (SMITH,

1989).

Devido à importânia da arquitetura do software na determinação de seu

desempenho, a SPE toma uma perspetiva arquitetnia. Os prinípios e ténias

de SPE formam abase para ométodode avaliação de desempenho de arquiteturas

de software - Performane Assessment of Software Arhitetures (PASA) (SMITH,

1989).

A PASA foi desenvolvida segundo a experiênia na ondução de avaliação de

desempenho em múltiplas arquiteturas de software em vários domínios, inluindo

apliativobaseadoemsistemasWebesistemasemtemporeal. Elausaosprinípios

easténias itadasadiantenestaseçãoparadeterminarseumaarquiteturaéapaz

de suportar seus objetivos de desempenho. Quando um problema é enontrado,

PASA tambémidentia estratégias para reduzirou eliminaresses risos.

OmétodoPASA pode serapliadonodesenvolvimentode umprojetonovopara

desobrir possíveis problemas quando são mais fáeis e menos dispendiosos para

orrigir. Também pode ser utilizado quando da atualização de sistemas legados,

parasedeidirsequerontinuaraempenharreursosnaatualarquiteturaoumigrar

paraumanova,ouemsistemasexistentes quepossuamum fraodesempenhoe que

exigemrápida orreção.

2.1.2 Visão Geral da SPE

A SPE é uma metodologia uja abordagem é a utilização de métodos de

transformação de software em modelos formais, om o objetivo de se utilizar estes

modelos para que se possa identiar problemas om a arquitetura do sistema,

desenho ou implementação deste. Esses modelos são onstruídos e analisados para

avança,osmodelossãorenadosparamelhorrepresentarodesempenhodestesnovos

estágiosdosoftware.

Apreisãodosresultadosdaanálisedomodelodependedaqualidadedosvalores

dos parâmetros de estimativas estabeleidos. Estes valores são difíeis de estimar

para as arquiteturas de software. A SPE utiliza estratégias adaptativas, taisomo

a denição de fronteiras superior e inferior, que representam o melhor e pior aso.

Usandoestas estimativas,osanalistasproduzemprevisõesdomelhoredopior aso

de desempenho. Se os resultados forem insatisfatórios então tenta-se identiar

omponentes rítios ujas estimativas têm o maior efeito sobre o desempenho e

entra-se naobtenção de valoresmaispreisospara eles. Umavariedadede ténias

pode forneer mais preisão, inluindo: renar ainda mais aarquitetura do sistema

e onstrução mais detalhada de modelos formais destes ou ainda a onstrução de

protótipospara mediçãode desempenho dos omponentes rítios (SMITH, 1989).

Doistiposde modelos forneeminformaçõesaeradaavaliaçãode desempenho

daarquiteturadesoftware: omodelodeexeuçãodosoftwareeomodelodeexeução

dosistema. O modelo de exeução do software é obtido a partir de modelos UML

do software e representa aspetos de omportamento da exeução deste software.

Ele é onstruído utilizando grafos exeutáveis para representar a atividade dos

diversos enários. Nestes grafos, nós representam omponentes funionais do

software e aros representam ontrole de uxo. Os gráos são hierárquios e

devem onter informações ompletas aera da estimativa temporal dos reursos

neessários (SMITH, 1989).

A onstrução do modelo de exeução do software proporiona uma análise

estátia da arquitetura do software. Esse modelo analisa o desempenho dos

reursos da proposta de software isoladamente, na ausênia de outros. Se esta

análise é satisfatória, então não há neessidade de onstruir modelos de análise

mais sostiados. O modelo de exeução do software é geralmente suiente para

identiar problemas devido aomau desempenho daarquitetura dosoftware.

Se o modelo de exeução do software india que não há problemas, então os

analistas podem ontinuar a análise de desempenho om a denição do modelo de

exeução dosistema. Este modelo dinâmioarateriza o desempenho do software

na presença de fatores, tais omo: existênia de vários enários e usuários, o que

parâmetrosdeentradaparaomodelodeexeuçãodosistema. Omodelodeexeução

do sistema prevê a análise de desempenho levando em onsideração as seguintes

informaçõesadiionais (SMITH, 1989):

◮

renamentodos requisitosde desempenho;

◮

métriasmais preisasdos reursos que representam ontensão;

◮

métriasde desempenho mais sensíveis àsvariações de omposiçãode arga;

◮

identiaçãodos reursos gargalo;

◮

dados omparativos para melhorar o desempenho através de mudanças

de workload, alterações de software, atualizações de hardware e várias

ombinaçõesde ada um destes;

◮

esalabilidadedaarquitetura: o efeitodoresimento futuro nodesempenho;

◮

identiaçãodos elementosruiais daonepção; e

◮

onepção de testes de desempenho.

2.1.3 O Proesso de Modelagem da SPE

O proesso de modelagem da SPE, entrado em diagramas de aso de uso do

modelo UML do sistema e em seus enários, é desrito por Smith (SMITH, 1989).

ODesenvolvimento apartir de uma perspetivade utilizaçãode diagramas de aso

de uso e seus enários fornee um meio de ompreensãodos requisitosdo sistema e

desua arquitetura, possibilitando assimaonstrução de modelosformaisparaada

enárioe sua efetiva avaliação de desempenho.

OproessoSPEinluiosseguintes passosqueestãoesquematizadosnodiagrama

de atividadesmostrado naFigura2.1 (SMITH, 1989).

i. identiar osasos rítios;

ii. veriar evalidaros modelos;

Figura 2.1: Oproesso demodelagemSPE (SMITH, 1989).

v. onstruir modelos de desempenho;

vi. aresentar reursos de softwares neessários;

vii. aresentar reursos de hardware neessários;

viii. avaliaros modelos;

ix. revisar objetivosde desempenho; e

x. modiara onepção dos enários.

2.2 Arquitetura Orientada a Serviços (SOA)

Servie-Oriented Arhiteture (SOA) - em português, Arquitetura Orientada a

Serviços-é um termoque desreve duasoisas muito diferentes. Asduas primeiras

umaplantaarquitetniaéumarepresentaçãodetodasaspeçasque,juntas,formam

uma onstrução. Portanto, servie-oriented arhiteture é uma estratégia que

prolamaa riaçãode todos osativosde software de uma empresa via metodologia

de programaçãoorientada aserviços (ERL, 2005)

Aarquitetura SOA tornapossíveltransformarapliaçõesmonolítias rígidasem

omponentes de software exíveis, permitindoa interoperabilidade entre diferentes

tenologias. Oalavanardas apliaçõeslegadaseenfoquenareutilização,aredução

dos ustos de desenvolvimento e manutenção tornam as soluções de negóio mais

ágeise fáeisde implementar, viabilizandoasoportunidades de negóioemtempos

antes onsiderados impossíveisde realizar (ARSANJANI, 2004).

O motivo para se migrar para o SOA é a reutilização de serviços de negóio

(ARSANJANI, 2004). Os programadores dentro e fora da organização podem

alavanar o ódigo desenvolvido pelas apliações existentes, expondo-o omo um

web servie, e podem reutilizá-lo para satisfazer novos requisitos de negóio. A

reutilizaçãode funionalidadesquejáexistemnaprópriaorganizaçãoounoexterior

pode resultar na redução signiativa do esforço de desenvolvimento do apliativo

e, portanto, dos ustos. Os benefíios de reutilização resem dramatiamente à

medida que mais serviços de negóiosão onstruídos e inorporados nas diferentes

apliações.

A abordagem SOA das interações entre os pedidos de lientes e os serviços

fraamente aoplados (loosely-oupled) traduz-se tão somente num oneito:

interoperabilidade vasta e abrangente. Por outras palavras, pretende-se que

os lientes e os serviços possam omuniar-se e ompreender-se mutuamente,

independentemente da plataforma que os suporta. Este objetivo somente será

tangívelsetantooslientesomoosserviçoszeremusodeumaformapadrãoebem

denida de omuniação entre si - uma forma onsistente, denida e transparente

quesejareonheida atravésdas plataformas,sistemaselinguagensatuais. De fato,

os web servies são os suportes que permitem exatamente isto. Os web servies

provideniam um onjunto robustoe onsistente de protoolos,regras etenologias

que são ompletamente independentes das plataformas, sistemas ou linguagens de

programação (FARREL, 2003).

Osserviçosloosely-oupledsãotipiamentemuitomaisexíveisqueasapliações

omuns epartilhando até estadosde exeução. Este fatotorna difíilepesado todo

o trabalho de evolução e adaptação destas apliações às onstantes mutações do

negóio,dassuasregrasedassuasneessidadeserequisitos. Emontraponto,tem-se

aarquitetura SOA, que utilizandoserviços de natureza loosely-oupled possibilita

às apliações grande exibilidade e failidade de evolução e rápida adaptação às

onstantes mutaçõesdo negóio, das suas regras erequisitos (ERL, 2005).

2.2.1 Denição de SOA

Otermo Servie-Oriented Arhiteture foi iniialmenteproposto por SCHULTE

& NATIS, então analistas do Gartner Group. Eles deniram SOA omo uma

onguraçãode omputação multiamadas queajudaas organizaçõesompartilhar

lógiaedados através de múltiplasapliaçõesemodelos de uso (SCHULTE;NATIS,

2006).

Estar preparado para atender às demandas das áreas de negóios om mais

agilidadeeexibilidade. Teromoenárioumambientebaseadoemumaarquitetura

desoftwaremodular,ondetodososapliativossãoaessadosporumaúniainterfae

webeossistemasutilizamdadosunsdosoutroseonversam indisriminadamente.

Istoé o panode fundo de umaarquitetura orientada a serviços (SOA).

Nestenovomodeloarquitetural,nãohámaisumainterfae,umbanodedadose

umsistemadeintegraçãoparaadasoftware. Naweb,emumaúniatela,osusuários

aessam todos os programas de forma transparente. Além de mais exível e mais

amigável,a interfae únia dá muito mais agilidadee transparêniaao usuário. Os

apliativos,por sua vez, utilizamqualquer informação,independentemente de onde

ela tenha sido gerada, graças ao mapeamento lógio dos dados. É omo se todos

estivessem emuma únia base, ajudandoa reduzira inonsistênia.

AOrganizationforthe Advanement of Strutured InformationStandards dene

SOA da seguinte forma: Arquitetura Orientada a Serviços (SOA) é um paradigma

para organização e utilização de ompetênias distribuídas, as quais estão sob o

ontrole de diferentes domínios proprietários. Ela fornee um meio uniforme de

ofereer, desobrir, interagir e usar apaidades para produzir efeitos desejáveis

2.2.2 Benefíios e Desaos de uma Arquitetura SOA

OsbenefíiosparaosinteressadosemimplementarumaSOAparagereniamento

dainformaçãosão signiantes. Osseguintes benefíios são alançados (SCHULTE;

NATIS, 2006):

◮

permite a reutilização dos ativos de TI: este é o primeiro e o mais

importante benefíio de implementar SOA. Pode-se onstruir um serviço de

negóio omo uma agregação de omponentes existentes. Para utilizar este

novo serviço é exigido somente saberseu nome e interfae. A implementação

deumserviçoespeío,bemomosuaarquiteturaeasomplexidadesdouxo

de dados que ompõem este serviço, são transparentes para quem o hama.

Istopermiteàsorganizaçõesaproveitarinvestimentosatuais,onstruirserviços

de um onglomeradode omponentes onstruídos em diferentes plataformas,

que rodam em diferentes sistemas operaionais e desenvolvidos em diferentes

linguagens de programação. Sistemas legados podem ser enapsulados e

aessados utilizandoasinterfaes web servies;

◮

diminui o tempo de desenvolvimento e reduz os ustos de

desenvolvimento e manutenção: omoas demandasdo negóioresem e

novos requisitos são introduzidos a todo o momento, o usto de desenvolver

e riar novos serviços através da arquitetura SOA e bibliotea de serviços

é bastante reduzido. A urva de aprendizagem de uma equipe de

desenvolvimento é também reduzida, pois a mesma pode estar familiarizada

omos omponentes existentes;

◮

diminuioriso: reusaromponentes existentes reduzorisode seintroduzir

novasfunionalidades dentrode proessos de melhoriaouriar novosserviços

do negóio. O riso de manutenção e gereniamento da infra-estrutura dos

serviços de suporte tambémserá reduzido; e

◮

protege investimento: protege oinvestimento do liente no gereniamento

dainformaçãoqueéaltamentevolátilnummeradoondeasfusõeseaquisições

são frequentes.

áreasque suportamtenologiamenteos negóios e osnegóios propriamenteditos.

Seusgestores estãose dandoontadaneessidade edaonveniêniadoenfoquenos

serviços,omoumm,sendovitaisparaosnegóiosemumfuturoquejásetornava

atualidade. A SOA trouxe à tona a neessidade de fortaleer o enfoque no liente

e tornar a gestão de serviços omo uma atividade produtiva, que agregue valor à

empresa (BOTTO, 2004).

2.2.3 Prinipais Termos e Denições de SOA

A visibilidade, interação e efeitos são os oneitos haves para desrever o

paradigma SOA (SCHULTE; NATIS, 2006). A visibilidade refere-se à apaidade

para aqueles om neessidades e aqueles om ompetênias estarem aptos a se

verem mutuamente. Isto é possível pelo ofereimento de desrições aera destes

aspetos omo asfunções erequisitos ténios, restriçõese polítias relaionadas, e

meanismosparaaessoeresposta. Enquantoavisibilidadeintroduzapossibilidade

de ompatibilizarasneessidades om as ompetênias (evie-versa), a interação é

aatividadequeusaaompetêniamediadaportroade mensagens. Umainteração

prossegue através de uma série de ações de troa de informações e invoações. O

propósitodeusarasompetêniasérealizarumoumaisefeitosnomundoreal. Uma

interação é um ato em oposição a um objeto e o resultado de uma interação é

um efeito(ou um onjunto/sériede efeitos). Este efeito pode ser o retorno de uma

informaçãoouamudançanoestadode entidades(onheidasoudesonheidas) que

estãoenvolvidas na interação (SCHULTE;NATIS, 2006).

A desrição de SOA tem ainda que menionar o que é usualmente onsiderado

o oneito entral de SOA: o serviço. O termo serviço pode ser denido omo

arealização de trabalho (uma função) por alguém para outro. Contudo, serviço,

omootermoégeralmenteentendido, tambémombina asidéiasrelaionadasom:

◮

aompetêniade exeutaro trabalhopara outro;

◮

aespeiação dotrabalho ofereidopara outro; e

◮

aoferta para exeutar trabalhopara outro.

Serviço é uma função independente, sem estado, que aeita uma ou mais

omo editar ou proessar uma transação. Serviços não devem depender do estado

de outras funções ou proessos. A tenologia utilizada para prover o serviço, tal

omouma linguagem de programação,não pode fazerparte dadenição doserviço

(SCHULTE;NATIS, 2006).

A ERL-2005 estabelee uma relação entre serviço e operações, omo ilustrado

na Figura 2.2, onde pode-se observar que um serviço representa um onjunto

logiamente agrupado de operações apaz de exeutar unidades de trabalho

relaionades (ERL, 2005).

Figura 2.2: Operaçõespertenentesadiferentesserviçosrepresentamváriaspartesdeum

proessode negóios lógio.

Na Tabela2.1são mostrados algunsdos prinipaistermos utilizadospor SOA e

suas respetivas denições.

2.2.4 Prinípios de SOA

A ERL-2005 dene os seguintes prinípios de uma arquitetura orientada a

serviços (ERL, 2005):

◮

reusabilidade do serviço: é a divisão em serviços om a intenção de

promovero seu reuso;

◮

frao aoplamento: serviços mantêm um relaionamento que minimiza

dependênias e somente requer que eles mantenham o onheimento da

existêniaum do outro;

Tabela 2.1: Prinipais deniçõesde SOA (SCHULTE;NATIS, 2006).

Termo Denição / Comentário

Serviço É uma função independente, sem estado (stateless)

que aeita uma ou mais requisições e retorna uma ou

mais respostas através de uma interfae padronizada e

bem denida. Serviços podem também realizar partes

disretas de um proesso tal omo editar ou proessar

umatransação. Serviçosnãodevemdependerdoestado

de outras funções ou proessos. A tenologia utilizada

para prover o serviço, tal omo uma linguagem de

programação, não pode fazer parte da denição do

serviço.

Orquestração Proesso de sequeniar serviços e prover uma lógia

adiional para proessar dados. Não inlui uma

representação de dados.

Stateless Não depende de nenhuma ondição pré-existente. Os

serviços não devem depender de ondições de outros

serviços. Elesreebemtodas asinformaçõesneessárias

para prover uma resposta onsistente. O objetivo

de busar a araterístia de stateless dos serviços

é possibilitar que o onsumidor do serviço possa

sequeniá-los, ou seja, orquestrá-los em vários uxos

(algumasvezes hamados de pipelines) para exeutar a

lógiade uma apliação.

Provedor O reurso que exeuta o serviço em resposta a uma

requisiçãode um onsumidor

Consumidor É quem onsome ou pede o resultado de um serviço

forneidopor um provedor.

Desoberta SOA se baseia na apaidade de identiar serviços

e suas araterístias. Consequentemente, esta

arquiteturadepende de um diretórioque desrevaquais

◮

abstração: além do que está desrito no ontrato de serviços, serviços

esondem alógia para quem está olhando de fora;

◮

omposabilidade: oleções de serviços podem ser oordenadas e montadas

paraformar omenude serviços;

◮

autonomia: serviços têm oontrole sobre a lógiaque eles enapsulam;

◮

sem estado: serviços minimizam a retenção da informação espeía para

umaatividade; e

◮

desobertabilidade: os serviços são projetados para serem desritivos,

de modo que possam ser ahados e possam ser avaliados via meanismos

disponíveisde desoberta.

Todos os prinípios são bastante importantes, mas o da reusabilidade passa a

ser o prinipal. Quando um serviço enapsula a lógia que é utilizada por mais de

umarequisiçãodeserviço, estepodeser onsideradoreusável. Ooneito dereuso é

baseadoemumnúmerode prinípiosomplementares,taisomo (MARTENS, 2003):

◮

autonomiadoserviçoestabeleeum ambientede exeução quefailitaoreuso

porque o serviço tem independênia eauto-governança;

◮

sem-estado doserviço suporta o reuso porque ele maximiza a disponibilidade

de um serviço e em geral promove uma espeiação genéria do serviço que

diferedoproessamentode atividadesespeíasforadas fronteiraslógiasdo

serviço;

◮

abstração do serviço permite o reuso porque estabelee o oneito de aixa

preta, onde os detalhes do proessamento são ompletamente esondidos do

requisitante. Istopermitequeum serviço expressede umaformasimplesuma

interfaepúblia genéria;

◮

desobertabilidade do serviço promove o reuso, e istopermite a requisitantes

prourar e desobrir serviços reusáveis; e

◮

baixoaoplamento dos serviços estabelee uma independênia intrínsea que

2.2.5 As Camadas de uma Arquitetura SOA

ERL-2005 apresenta um alto nível de abstração da amada de serviços

posiionada entre as amadas dos proessos de negóio e de apliação, que

demonstra a onetividade aberta entre as amadas de serviço. No nível físio,

serviçossãodesenvolvidosemambientesproprietários,ondeelessãoindividualmente

responsáveis pelo enapsulamento de uma apliação lógia espeía (ERL, 2005).

Na Figura 2.3 é mostrado omo serviços individuais, dentro da amada lógia de

serviços,representamapliaçõeslógiasoriginadasemdiferentesplataformas (ERL,

2005).

Figura 2.3: Camadadeserviços posiionada entreasamadas de proessosde negóioe

2.2.6 SOA e a Tenologia Web Servies

SOA expressa um oneito em que apliativos ou rotinas são disponibilizados

omo serviços em uma rede de omputadores (Internet ou Intranets) de forma

independente e se omuniando através de padrões abertos. A maior parte

das implementações de SOA se utilizam de web servies. Entretanto, uma

implementaçãodeSOApodeseutilizardequalquer tenologiapadronizadabaseada

em web (CURBERAetal., 2002).

A base dopadrão web servies relevantes ao SOA inluem:

◮

XML(eXtensibleMarkup Language): éumalinguagemdemaraçãopara

desrever dados emargasde mensagens emum formato de doumento;

◮

SOAP(SimpleObjet Aess Protool): éumprotoolobaseadoemXML

utilizadopara troas de informações num ambiente distribuído. A utilização

deXMLéumaformaeienteparatroasdeinformações,masnãoésuiente

paratroas de dados via Web. Ainda preisamos de um protooloemomum

paraenviodedoumentos XMLpelaWeb de talformaqueoreeptorentenda

oque está reebendo e o que deve ser respondido. É neste ponto que entra o

SOAP;

◮

WSDL (Web Servies Desription Language): é um doumento XML

que desreve um onjunto de mensagens SOAP e a forma omo essas

mensagens são troadas. Como oWSDL é XML, eleé legívele editável, mas

namaioriados asos, eleé geradoe onsumido pelosoftware;e

◮

UDDI (Universal Desription, Disovery, and Integration): é uma

das formas de loalizar um Web Servie num registro, omo se fosse um

atálogo de páginas amarelas, de tal forma que um programa em busa de

um determinadoserviço possa failmente loalizare entender oque elefaz.

Segundo ARSANJANI (ARSANJANI, 2004), a arquitetura orientada a serviços

(SOA) pode ser bem representada a partir do seguinte modelo envolvendo três

partes prinipais: o forneedor do serviço, o usuário e o registro do serviço,

também hamado de nd-bind-exeute paradigm o que signia paradigma de

Figura 2.4: Paradigmaproura-onsolida-exeuta, adaptado de (ARSANJANI,2004).

Teniamente falando, o proesso preoniza que os provedores de serviços

registreminformaçõesemum registroentral, omsuas araterístias, indiadores,

e aspetos relevantes às tomadas de deisões. O registro é utilizado pelo liente

para determinar as araterístias dos serviços neessários, e se o mesmo estiver

disponível no registro entral, omo por exemplo, por um atálogo de serviços, o

liente poderá utilizá-lo, sendo este oializado através de um ontrato de serviço

queenderee este serviço.

2.2.7 Estratégias de Desenvolvimento e Implementação SOA

ERL-2005deneasseguintes estratégiasparadesenvolvimentoeimplementação

SOA (ERL, 2005):

◮

a estratégia em top-down: esta estratégia de ima para baixo requer

não somente que osproessos de negóiose tornemorientados a serviço, mas

também promove ariação (ou realinhamento)de todoo modelo de negóios

daorganização. Os seguintes passos estão previstos nesta abordagem:

•

denição de proessosde negóio;

•

omposiçãoSOA;

•

denição do modelo de serviço;

•

análise orientada a serviço;

•

desenvolvimentodos serviços;

•

testes; e

•

implementação.

◮

a estratégia bottom-up: esta abordagem de baixo para ima enoraja

primeiramenteariaçãodas apliaçõesdeserviçosservindoomobasepara as

demaisfases,eaintegração passaaseromotivadorprinipaldestaestratégia.

Osseguintes passos estão previstosnesta abordagem:

•

modelar asapliaçõesde serviços;

•

espeiaras apliações;

•

desenvolver as apliações;

•

testar; e

•

implementar.

A esolha de uma ou outra estratégia vai depender de ada organização

onsiderandoas variáveis tempo e reursos naneiros que dispõem. A abordagem

de ima para baixo laramente exige mais tempo e tem um usto bem mais alto

que a abordagem de baixopara ima, pois esta última se utiliza das ongurações

e proessos que se enontram na organização, não sendo neessário rever todos

os proessos e pode-se também esolher determinadas apliações para torná-las

orientadas-a-serviço.

◮

a estratégia mista: pode-se também apliar uma estratégia mista, ou seja,

uma ombinação entre as abordagens top-down e bottom-up, onde as fases

de modelagem dos proessos e do negóio se dão onomitantemente om as

fasesde espeiação e implementação, neessitando um re-alinhamentoom

osproessos emada uma das fases.

2.3 Web Servies (WS)

Web servies podem ser denidos omo omponentes, ou unidades lógias de

apliação, aessível através de protoolos padrões da Internet, possuindo uma

ResoureIdentier),ujasinterfaeseligaçõessãodenidas, desritasedesobertas

utilizando-seomo padrãoa linguagem XML (GARCIA;TOLEDO,2006).

Segundo (LUDWIG, 2003), a tenologia web servies poderá ser tão importante

para as interações entre apliação-apliação (B2B), quanto a web foi para as

interações entre apliação-usuário (B2C). Web servies possibilitam empresas

reduzirem ustos de e-bussiness, forneem soluções mais rápidas e riam novas

oportunidadesde negóios.

Além disso, web servies permitem que empresas desenvolvam funções que

podem ser utilizadas sob demanda ou utilizadas em onjunto para prover um

serviço de negóio (LUDWIG, 2003). Web servies estão emergindo para forneer

uma infraestrutura sistemátia e extensível para interações apliação-apliação,

onstruída sobre protoolos web já existentes e baseada em padrões XML abertos

(LUDWIG, 2003). A arquitetura adotada pelos web servies é mostrada na Figura

2.5.

Figura 2.5: Arquiteturaadotada pelos WS (LUDWIG,2003)

A arquitetura, mostrada na Figura 2.5, é formada por três entidades

partiipantes: provedor de serviço, onsumidor de serviço e registro de serviços.

Oprovedor de serviço é o repositório do serviços. É função doprovedor de serviço

desrever de forma padronizada ada serviço riado e publiá-lo em registros de

serviços. Oonsumidordeserviço oulienteéaentidadequevaiutilizarumserviço

peloserviço adequado é feitaatravésde uma onsulta aum registrode serviços. O

registrodeserviçoséaentidadeomaqualambos,oprovedoreoliente,interagem.

Os provedores publiam seus serviços no registro para que os lientes onsigam

enontrá-los e utilizá-los. Oregistro de serviços é essenialmente um repositório de

dadosbaseado emXML.

Vale ressaltar que os web servies são baseados em três padrões web

fundamentais: SOAP, WSDL e UDDI. O Simple Objet Aess Protool (SOAP)

(SCHULTE; NATIS, 2006) é um protoolo de omuniação baseado em XML para

a interação de apliações. Nos web servies, o SOAP é utilizado para denir a

estruturadasmensagenstroadasentreasentidadespartiipantes. AlinguagemWeb

Servies Desription Language (WSDL) (SCHULTE; NATIS, 2006) é um padrão da

W3Cutilizadoparadesrever asinterfaesdos webservies. O(UDDI)- Universal,

Disovery, Desription and Integration (SCHULTE; NATIS, 2006) é um padrão da

OASIS 1

que fornee aos usuários uma formauniada e sistemátia para desobrir

serviços por meio de um registro entralizado. Em resumo, um web servie pode

ser denido omo um serviço de software publiado na web, que troa mensagens

utilizandooprotoolo SOAP, é desrito por um arquivo na WSDL e registrado em

um repositórioonheido omo UDDI.

Ainda que a interfae WSDL permita a desrição de atributos funionais dos

web servies (LUDWIG, 2003), há uma arênia em permitir que outros atributos

não-funionaisetransaionais tambémsejam anexados. Permitir queatributos não

funionais(tempode resposta, vazão,segurança,et)sejamanexadosàWSDLseria

uma possibilidade para melhorar a provisão de QoS em web servies. Como um

quesito essenial para a omputação orientada a serviço, QoS tem-se demonstrado

um fator difíil de se gereniar devido às diferenças entre as organizações e

loalização dos web servies (LUDWIG, 2003). Nesse sentido, QoS e avaliação de

desempenho para web servies são assuntos pesquisados na atualidade, atraindo

tanto pesquisadores da aademia quantoda indústria.

2.4 Modelos Formais

Várias ténias formaisde modelagem de omportamentode software têm sido

objeto de pesquisa e desenvolvimento. Esta seção apresenta uma introdução sobre

1

Organization for the Advanement of Strutured Information Standards - http://www.