Departamento de Engenharia
Informática
Conversão da Notação CEO
para a linguagem BPEL4WS
RELATÓRIO
TRABALHO FINAL DE CURSO
Ano Lectivo: 2004/2005
N.º da Proposta: 39
Título: Conversão da Notação CEO para a linguagem BPEL4WS
Curso: Licenciatura em Engenharia Informática e de Computadores (LEIC)
Professor Orientador:
Prof.ª Dr.ª Carla Ferreira __________(assinatura)__________
Co-Orientador:
__________(assinatura)__________
Alunos:
50077, Francisco Santos __________(assinatura)__________
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
Francisco Santos i
Agradecimentos
À minha orientadora, a Sr.ª Prof.ª Dr.ª Carla Ferreira, agradeço todo o apoio prestado durante
a realização do trabalho e os conselhos sobre a melhor forma de concretizar os objectivos
propostos.
Ao grupo CEO agradeço a oportunidade que me deram para expor o meu trabalho e as
sugestões que fizeram sobre como melhorar e expandir as ideias iniciais.
Ao Sr. Eng. João Saraiva agradeço a disponibilidade que demonstrou no esclarecimento de
dúvidas sobre o projecto Eclipse UML2. Ao Sr. Dr. Alexandre Francisco agradeço os
esclarecimentos que prestou relativamente aos algoritmos de travessia em grafos.
Um agradecimento especial à minha família e amigos que me apoiaram durante a realização
do trabalho.
Lisboa, Fevereiro de 2006
Francisco Santos
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
Francisco Santos ii
Resumo
A Framework CEO (FCEO) suporta a modelação dos processos de negócio de organizações.
Para a representação dos seus modelos a FCEO estende a notação UML com conceitos
específicos ao domínio dos processos de negócio. A Business Process Execution Language
for Web Services (BPEL4WS) é uma linguagem executável para a modelação de negócios, no
entanto, o seu nível conceptual é mais próximo da implementação do que os modelos FCEO.
O objectivo deste trabalho é o de tornar os modelos FCEO executáveis, estendendo o perfil de
modelação do negócio da FCEO e implementando um método automático de conversão para
a linguagem de execução de processos de negócio: BPEL4WS.
Palavras chave: modelo, processo, negócio, modelação, FCEO, UML, BPEL4WS, BPEL,
conversão, algoritmo, executável
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
Francisco Santos iii
Índice
1 Introdução............................................................................................................................ 8
2 Framework CEO................................................................................................................ 10
2.1 Definição de um Processo de Negócio..................................................................... 10
2.1.1 Especificação da Estrutura do Processo ............................................................... 10
2.1.2 Especificação Funcional do Processo .................................................................. 11
3 BPEL4WS ......................................................................................................................... 22
3.1 Relação com o WSDL.............................................................................................. 22
3.2 Definição de um Processo de Negócio..................................................................... 23
3.2.1 Especificação do Serviço Associado ao Processo................................................ 24
3.2.2 Especificação Funcional do Processo .................................................................. 25
4 Conversão entre FCEO e BPEL4WS ................................................................................ 30
4.1 Extensão ao Perfil UML da FCEO........................................................................... 30
4.2 Delineação do Processo de Conversão UML BPEL ................................................ 37
4.3 Organização do Espaço Nomes................................................................................ 39
4.3.1 Notação................................................................................................................. 39
4.3.2 Geração dos Ficheiros XSD, WSDL e BPEL ...................................................... 40
4.4 Conversão dos Tipos de Dados e Mensagens .......................................................... 41
4.4.1 Geração dos Ficheiros XSD e WSDL.................................................................. 42
4.5 Conversão das Propriedades e Conjuntos de Correlação ......................................... 46
4.5.1 Notação................................................................................................................. 47
4.5.2 Geração dos Ficheiros WSDL e BPEL ................................................................ 50
4.6 Conversão dos Protocolos de Negócio..................................................................... 52
4.6.1 Notação................................................................................................................. 52
4.6.2 Geração do Ficheiro WSDL................................................................................. 53
4.7 Conversão de Processos ........................................................................................... 54
4.7.1 Notação................................................................................................................. 54
4.7.2 Geração do Ficheiro BPEL .................................................................................. 55
4.8 Manipulação do Estado do Processo........................................................................ 56
4.8.1 Linguagem XPath................................................................................................. 56
4.8.2 Expressões de Acesso aos Dados ......................................................................... 58
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
Francisco Santos iv
4.8.3 Expressões de Atribuição ..................................................................................... 59
4.8.4 Geração das Actividades BPEL ........................................................................... 60
4.8.5 Conversão do Diagrama de Actividades .............................................................. 67
5 Implementação................................................................................................................... 77
6 Conclusão .......................................................................................................................... 81
Apêndice A – Ficheiro WSDL Protocolo Encomendar ........................................................... 82
Apêndice B – Ficheiro BPEL ProcessoReceberEcomenda...................................................... 83
Apêndice C – Conversão de Tipos Básicos da UML para o Formato XSD ............................ 86
Apêndice D – Conversão para o Perfil versão UML 2.0 ......................................................... 87
Referências ............................................................................................................................... 89
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
Francisco Santos v
Lista Figuras
Figura 2.1 – Diagrama de Classes para a Estrutura dos Recursos ........................................... 11
Figura 2.2 – Diagrama de Actividades para o ProcessoReceberEncomenda........................... 13
Figura 2.3 – Diagrama de Actividades para o Processo de Desenvolvimento Software ......... 14
Figura 2.4 – Diagrama de Actividades com actividades aninhadas......................................... 15
Figura 2.5 – Nós de decisão e de fusão .................................................................................... 17
Figura 2.6 – Utilização explícita de nós de difusão e de junção .............................................. 19
Figura 2.7 – Diagrama de Actividades com fluxo de objectos ................................................ 20
Figura 2.8 – Diagrama de Actividades com fluxo de objectos e pistas ................................... 21
Figura 3.1 – Processo de Recepção de Encomendas................................................................ 23
Figura 4.1 – Diagrama de Actividades para o Processo Receber Encomenda......................... 31
Figura 4.2 – Tipos de Dados e Mensagens............................................................................... 32
Figura 4.3 – Protocolos de Negócio, Papéis e Interfaces ......................................................... 33
Figura 4.4 – Processo Recepção de Encomendas .................................................................... 34
Figura 4.5 – Diagrama de Actividades detalhado para o Processo Receber Encomenda ........ 35
Figura 4.6 – Esquema dos Documentos XML gerados pelo Processo de Conversão.............. 38
Figura 4.7 – Exemplo de Dependência entre Pacotes .............................................................. 39
Figura 4.8 – Notação para o pacote e para a dependência entre pacotes ................................. 40
Figura 4.9 – Cenário Conversão para uma Encomenda ........................................................... 45
Figura 4.10 – Ficheiro XSD correspondente aos Tipos de Dados Base da Encomenda.......... 45
Figura 4.11 – Ficheiro WSDL correspondente à Encomenda.................................................. 46
Figura 4.12 – Notação para as Propriedades ............................................................................ 48
Figura 4.13 – Exemplo da inclusão de um Conjunto de Correlação num Processo ................ 49
Figura 4.14 – Exemplo de uma Actividade que usa Correlação .............................................. 49
Figura 4.15 – Definição Propriedades em WSDL.................................................................... 51
Figura 4.16 – Definição de Conjuntos de Correlação em BPEL ............................................. 51
Figura 4.17 – Definição de Actividades Correlacionadas em BPEL ....................................... 52
Figura 4.18 – Exemplo da Notação dos Protocolos de Negócio e Papéis................................ 53
Figura 4.19 – Exemplo da Notação das Interfaces................................................................... 53
Figura 4.20 – Ficheiro WSDL com a definição das Ligações a Parceiros e Papéis................. 54
Figura 4.21 – Exemplo de uma Actividade de Atribuição....................................................... 60
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
Francisco Santos vi
Figura 4.22 – Exemplo da conversão de uma Actividade de Atribuição para BPEL .............. 61
Figura 4.23 – Exemplo de uma Actividade de Espera ............................................................. 62
Figura 4.24 – Exemplo da conversão de uma Actividade de Atribuição para BPEL .............. 62
Figura 4.25 – Exemplo da Invocação de Operações Síncronas e Assíncronas ........................ 63
Figura 4.26 – Exemplo da Conversão de Actividades de Invocação Síncronas e Assíncronas63
Figura 4.27 – Exemplo da utilização de Actividades de Recepção e Reposta......................... 64
Figura 4.28 – Exemplo da Conversão de Actividades de Recepção e Resposta...................... 65
Figura 4.29 – Exemplo da utilização de Actividades de Decisão ............................................ 66
Figura 4.30 – Exemplo da Conversão de uma Actividade de Decisão para BPEL.................. 66
Figura 4.31 – Exemplo Diagrama Actividades UML .............................................................. 68
Figura 4.32 – Grafo de Actividades BPEL .............................................................................. 68
Figura 4.33 – Ordenação Topológica....................................................................................... 70
Figura 4.34 – Árvore BPEL ..................................................................................................... 73
Figura 4.35 – Árvore BPEL Optimizada.................................................................................. 76
Figura 5.1 – Interface Gráfica do Conversor............................................................................ 80
Figura 5.2 – Visualizador de Eventos da Plataforma Eclipse .................................................. 80
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
Lista Tabelas
Tabela 2.1 – Um plano de execução para o diagrama de actividades da Figura 2.4................ 16
Tabela 3.1 – Principais actividades de um processo BPEL4WS ............................................. 27
Tabela 4.1 – Conversão das Expressões de Multiplicidade ..................................................... 43
Tabela 4.2 – Conversão Modelo UML para Formato XSD ..................................................... 44
Tabela 4.3 – Atributos para a Definição de um Processo BPEL.............................................. 55
Tabela 4.4 – Exemplos de Expressões de Acesso aos Dados .................................................. 59
Tabela 4.5 – Regras para a Geração da Árvore BPEL ............................................................. 72
Tabela 4.6 – Heurísticas de Optimização do Código BPEL .................................................... 75
Francisco Santos vii
1 Introdução A Unified Modeling Language (UML) é uma linguagem para a especificação,
visualização, construção e documentação de artefactos de software. A UML representa
um conjunto das melhores práticas da engenharia, que provaram adequadas na
modelação de sistemas software complexos e de grande escala. Através dos seus
mecanismos de extensão foi possível utilizar a UML noutros domínios de aplicação,
como sendo a modelação do negócio.
Desenvolver um modelo para um sistema de software antes da sua construção ou
renovação é uma tarefa importante para garantir o sucesso de um projecto de
engenharia. Os bons modelos são essenciais para a comunicação entre equipas de
projecto e assegura uma coesão arquitectural do sistema. À medida que a complexidade
dos sistemas aumenta, torna-se particularmente útil recorrer às técnicas de modelação,
tratando-se de uma boa forma de reduzir a complexidade do projecto. A modelação
permite ao engenheiro abstrair-se dos aspectos irrelevantes e focar nos aspectos mais
importantes para uma dada fase do projecto.
A Framework CEO (FCEO) é um perfil UML (extensão do UML base) que
permite definir o modelo de negócio de uma organização. Este modelo,
conceptualmente semelhante ao modelo de software, é uma abstracção de como o
negócio funciona. Cria uma vista simplificada da estrutura do negócio, servindo de base
à comunicação, introdução de melhoramentos ao funcionamento da organização ou na
inovação do negócio. Os modelos FCEO não são à partida executáveis, uma vez que
possuem apenas uma descrição estática da estrutura e dinâmica do processo. Usando
uma descrição normalizada da dinâmica do processo torna-se possível a conversão
automática dos modelos estáticos em modelos executáveis, permitindo simular o
funcionamento real dos processos. Através da simulação torna-se possível enriquecer
ainda mais o modelo de negócio existente e possibilita a sua validação, recorrendo a
cenários de negócio reais.
Foi escolhida a linguagem Business Process Execution Language for Web
Services (BPEL4WS) para definir a versão executável dos processos de negócio. A
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
BPEL4WS define um modelo e uma gramática para descrever o comportamento de um
processo de negócio baseado nas interacções entre o processo e os parceiros de negócio
envolvidos. Um parceiro pode providenciar serviços, requisitar serviços ou participar
numa conversação bidireccional com o processo. O objectivo deste trabalho é o de
tornar os modelos FCEO executáveis, estendendo o perfil de modelação do negócio da
FCEO e implementando um método automático de conversão para a linguagem de
execução de processos de negócio: BPEL4WS.
O relatório está organizado da seguinte forma: na Secção 2 é feita uma descrição
do perfil UML da FCEO para a definição de processos de negócio, na Secção 3 é
apresentada a linguagem de modelação de processos de negócio executáveis:
BPEL4WS, na Secção 4 é descrito todo o processo de conversão entre as duas
linguagens de modelação, os detalhes da implementação do algoritmo encontram-se
descritos na Secção 5 e as principais conclusões do trabalho encontram-se descritas na
Secção 6.
Francisco Santos 9
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
2 Framework CEO A Framework CEO (FCEO) [VCSMT04], proposta pelo Centro de Engenharia
Organizacional (CEO), permite modelar os conceitos do negócio. Nesta framework foi
adoptada uma estratégia conjunta de desenho de SI e do negócio, garantindo assim um
melhor alinhamento entre estes dois aspectos da modelação organizacional. Esta
framework contempla, actualmente, os seguintes conceitos do negócio: os objectivos
(<<goal>>), para a modelação da estratégia; os processos (<<process>>), para a
modelação dos processos de negócio; os recursos (<<resource>>), para a modelação
dos recursos do negócio; e os blocos (<<block>>), para a modelação dos sistemas de
informação.
Outra vantagem da FCEO reside no facto de ser suportada por uma linguagem
de modelação estandarte que representa as melhores práticas na indústria da modelação
orientada a objectos: a Unified Modelling Language (UML) [OMG03]. Mais
concretamente, esta framework recorre a um perfil UML para permitir a modelação no
domínio do negócio.
2.1 Definição de um Processo de Negócio
De forma a melhor compreender a metodologia de modelação sugerida pela FCEO e,
numa fase posterior, compreender quais são as transformações necessárias a fazer ao
modelo de forma a torná-lo executável, é apresentado um curto exemplo de um processo
de recepção de encomendas.
2.1.1 Especificação da Estrutura do Processo
No Diagrama de Classes para a Estrutura dos Recursos são descritas as relações que
existem entre os recursos físicos e de informação, lidados pelo processo. Neste caso, o
Cliente (recurso físico) efectua uma Encomenda (recurso de informação) onde constam
vários Produtos (recurso físico) oferecidos pela empresa. Para cada encomenda é
emitida uma Factura (recurso de informação) à qual irá corresponder um Pagamento
(recurso físico).
Francisco Santos 10
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
Cliente<<resource>>
Produto<<resource>>
Encomenda<<resource>>
1 n
0..1
1..n
Pagamento<<resource>>
Factura<<resource>>
1
1
1 1
1 n
0..1
1..n
1
1
1 1
Figura 2.1 – Diagrama de Classes para a Estrutura dos Recursos
Existem as seguintes relações entre os recursos enunciados: para cada Cliente
existem zero ou mais Encomendas, para cada Encomenda existem um ou mais Produtos
encomendados, para cada Encomenda existe uma Factura e para cada Factura existe um
Pagamento. Seguidamente deve ser criado o Diagrama de Classes para a Estrutura dos
Processos, onde são descritas as relações entre os vários processos e sub-processos da
organização. Neste caso, vai ser modelado apenas um processo: o
‘ProcessoReceberEncomenda’.
2.1.2 Especificação Funcional do Processo
Os diagramas de actividades são usados para explorar e descrever fluxos de execução,
as acções desempenhadas por uma operação de uma classe, semelhante aos tradicionais
diagramas de fluxos de dados. Adicionalmente, os diagramas de actividades são usados
para descrever processos de negócio, i.e. fluxos de execução, ou workflows, no contexto
organizacional. Um fluxo de execução pode envolver uma simples operação, tal como a
introdução de uma encomenda num sistema de processamento de encomendas, ou pode
ser mais complexo, tal como o processo de controlo de produção e desenvolvimento de
produtos. No âmbito deste trabalho não serão considerados diagramas de actividades
que contenham actividades aninhadas (tal como apresentado na Figura 2.4) [OMG03].
Na Figura 2.2, é apresentado o diagrama de actividades para o processo de
recepção de encomendas. Os classificadores: ‘encomendar’, ‘enviar’, ‘facturar’ e
Francisco Santos 11
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
‘fabricar’ separam o conjunto de actividades desempenhadas pelos vários intervenientes
no processo. Os nomes das actividades foram escolhidos com base na actividade
realizada pelo processo em relação aos outros intervenientes.
No acto da recepção da encomenda do cliente, actividade ‘receberEncomenda’,
são iniciadas três tarefas concorrentes: escolha do distribuidor, actividade
‘inicializarPedidoEntrega’, cálculo do preço dos artigos encomendados, actividade
‘calcularPreco’, e escalonamento da produção, actividade
‘pedirEscalonamentoProducao’. Num diagrama de actividades existe uma transição
automática entre uma actividade e as actividades sucessoras. Não havendo condições de
guarda especificadas para as transições de saída, as próximas actividades podem
executar-se logo que as actividades antecessoras tenham terminado. No caso do
exemplo, existem restrições quanto à forma de execução concorrencial das tarefas: só é
possível finalizar o cálculo do preço da encomenda depois de determinado o preço de
envio, ligação entre ‘pedirEntrega’ e ‘enviarPrecoEntrega’, e só é possível finalizar o
escalonamento da produção depois de se saber a data de envio do distribuidor, ligação
entre ‘receberPrazoEntrega’ e ‘enviarPrazoEntrega’. Assim que as três sequências
concorrentes terminem, o processamento da encomenda pode continuar, sendo enviada
a factura ao cliente: ‘enviarFactura’.
Francisco Santos 12
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
receberEncomenda
env iarFactura
inicializarPedidoEntrega
pedirEntrega
receberPrazoEntrega
env iarPrecoEntrega
receberFactura
calcularPreco pedirEscalonamentoProducao
env iarPrazoEntrega
FabricarFacturarEnviarEncomendar encomendar enviar facturar fabricar
Figura 2.2 – Diagrama de Actividades para o ProcessoReceberEncomenda
2.1.2.1 Estados Actividade
O diagrama de actividades é um caso particular de um diagrama de estados, no qual
todos ou a maioria dos estados representam actividades a ser executadas, e todas ou a
maioria das transições são despoletadas pelo término das actividades antecedentes, i.e.
quando uma actividade especificada num estado foi executada, a transição para a
próxima actividade ocorre automaticamente. Os estados num diagrama de actividades
são designados estados actividade ou, simplesmente, actividades. Os estados
actividade são estados nos quais alguma actividade é desempenhada.
As actividades podem ser divididas em subactividades. No caso apresentado na
Figura 2.3 a actividade ‘Processo Desenvolvimento Software’ foi subdividida em seis
actividades distintas: ‘Análise Requisitos’, ‘Desenho Sistema’, ‘Implementação’,
‘Teste’, ‘Distribuição’ e ‘Manutenção’. As subactividades que não possam mais ser
subdivididas são designadas acções (actividades atómicas); as actividades atómicas
encontram-se representadas pelo mesmo símbolo das outras actividades: rectângulo de
cantos arredondados. As actividades e acções encontram-se ligadas através de
Francisco Santos 13
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
transições, sendo que estas compõem o fluxo de execução de um diagrama de
actividades.
Processo Desenvolvimento Software
Análise Requisitos
Desenho Sistema
Implementação
Teste Distribuição Manutenção
Análise Requisitos
Desenho Sistema
Implementação
Teste Distribuição Manutenção
Figura 2.3 – Diagrama de Actividades para o Processo de Desenvolvimento Software
2.1.2.2 Fluxo de Execução Básico
A ordem de execução das actividades é modelada usando ligações de controlo, que são
representadas por uma seta de transição entre duas actividades. Os processos suportam
fluxos de execução concorrentes. Uma actividade é executada quando todas as ligações
de controlo de entrada estão activas. Quando uma actividade finaliza a sua execução,
todas as ligações de controlo de saída ficam activas. Opcionalmente, uma ligação de
controlo pode conter uma guarda. Uma ligação de controlo com guarda só é activada se
a avaliação da guarda (expressão booleana) resultar no valor verdadeiro após a
actividade origem terminar a sua execução.
Uma actividade pode ter uma ou mais ligações de controlo de entrada e de saída.
Uma actividade pode estar aninhada dentro de outra actividade. As ligações de controlo
podem atravessar as fronteiras duma actividade; isto permite que uma actividade
aninhada possa ter uma ligação de controlo de entrada e de saída para uma actividade
exterior à actividade que a contém.
O exemplo da Figura 2.4 ilustra o fluxo de execução para actividades aninhadas.
De forma a facilitar a compreensão do exemplo, designaremos por ‘1’ a actividade
‘Actividade 1’ e por ‘3::1’ a actividade ‘Actividade 3::Actividade 1’.
Francisco Santos 14
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
Actividade 1
Actividade 2Activitdade 3
Actividade 1
Actividade 2
Actividade 3Actividade 1
Actividade 2
Actividade 3 Actividade 4
Actividade 5Actividade 6
Actividade 7
[ guarda1 ]
Figura 2.4 – Diagrama de Actividades com actividades aninhadas
Na tabela que se segue é demonstrado um plano de execução possível e quais as
actividades que podem ser executadas a um dado momento. Assume-se, neste exemplo,
que as actividades: 1, 2, 3::1, 3::2, 3::3, 4, 5, 6 e 7, são atómicas.
Actividades Executáveis Operação Escolhida Comentário
{1} Executar 1 Inicio da execução.
{2, 3} Executar 3 É possível subdividir a
actividade 3. A actividade 4
depende da actividade 3::3.
{2, 3::1, 3::3} Executar 3::1
{2, 3::3} Executar 2
{3::2, 3::3} Executar 3:2 3::2 só pode ser executada
após 2 e 3::1 terem
terminado.
{3::3} Executar 3::3
Francisco Santos 15
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
Actividades Executáveis Operação Escolhida Comentário
{4, 5} Executar 5 Tendo sido executada a
última actividade atómica
aninhada na actividade 3,
considera-se que esta
terminou a sua execução.
{4} Executar 4
{6} Executar 6
{} Avaliar guarda1 = true Após término da actividade
6, a condição de guarda é
avaliada; caso seja
verdadeira, torna-se
possível executar a
actividade 7.
{7} 7 Tabela 2.1 – Um plano de execução para o diagrama de actividades da Figura 2.4
2.1.2.3 Nós de Decisão e de Fusão
Os nós de decisão (decision) e de fusão (merge) permitem afinar o comportamento do
fluxo de execução concorrente. As decisões permitem relacionar o fluxo de execução
das actividades ao estado interno do processo. Quando o controlo de execução chega ao
nó de decisão, todas as condições de guarda, pertencentes às ligações de controlo que
partem do nó, são avaliadas. Quando o resultado de avaliar uma condição de guarda for
verdadeiro, a ligação de controlo associada passa a estar activa e mais nenhuma
condição de guarda é avaliada. No máximo uma ligação de controlo pode ter a condição
de guarda ‘otherwise’, indicando que a ligação de controlo é activada caso o resultado
de avaliar todas as outras ligações de controlo tenha sido falso.
Um nó de fusão permite que várias ligações de controlo de entrada causem a
activação de uma ligação de controlo de saída. Este tipo de nó é usado para juntar vários
fluxos de execução alternativos, criados por um nó decisão, indicando que o
Francisco Santos 16
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
comportamento após a fusão é comum a todos os casos. O exemplo da Figura 2.5 ilustra
um caso de utilização dos nós de decisão e de fusão para diferenciar o tratamento de
encomendas urgentes, sendo que a actividade ‘Fechar Encomenda’ é executada em
qualquer um dos casos.
Preparar
Encomenda
Enviar Modo Expresso
Enviar Modo Normal
Fechar Encomenda
[ tipo de envio = 'urgente' ] [ otherwise ]
Figura 2.5 – Nós de decisão e de fusão
Em termos de notação, tanto o nó de decisão como o de fusão são representados
por um losango (existe um nó de cada tipo no diagrama anterior). Os nós de decisão
representam escolhas, onde a execução de uma dada ligação de controlo de saída é
determinada pela avaliação da sua condição de guarda. A condição de guarda deve ser
colocada entre parênteses rectos numa etiqueta associada à ligação de controlo.
Opcionalmente uma (e só uma) das ligações de controlo pode ser condicionada pela
guarda ‘otherwise’. Os nós de fusão recebem várias ligações de controlo de entrada e
têm apenas uma ligação de controlo de saída.
Em UML, um nó de decisão apenas pode ter uma ligação de controlo de entrada
e um nó de fusão apenas pode ter uma ligação de controlo de saída. Se um losango for
desenhado tendo várias ligações de controlo de entrada e de saída, então é interpretado
como sendo um nó de fusão seguido de um de decisão. Isto significa que, para
representar a sincronização de actividades concorrentes antes de um nó decisão é
Francisco Santos 17
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
necessário usar um nó de junção, e para representar actividades concorrentes após um
nó de fusão torna-se necessário usar um nó de difusão.
O nó de difusão (fork) permite modelar um fluxo de execução singular que se
separa em dois ou mais fluxos de execução concorrentes. Todavia, o número de nós de
difusão presentes no diagrama deve ser compensado por igual número de nós de junção.
Uma junção (join) consiste em dois ou mais fluxos de execução concorrentes que se
juntam num único fluxo de execução. Todas as actividades que se encontrem entre uma
difusão e uma junção devem completar a sua execução antes dos fluxos de execução se
unirem num só fluxo. O processo de ‘Marketplace’, ilustrado na Figura 2.6, demonstra a
utilização de uma junção antes de uma decisão (barra sólida) e uma difusão (também
representada por uma barra sólida) depois da fusão.
O comportamento de um nó de decisão pode ser alcançado colocando guardas
nas várias transições de saída de uma actividade. Por questões de clareza, é
recomendável introduzir um nó de decisão sempre que seja feita uma escolha
mutuamente exclusiva, Figura 2.6. Quando é usado um nó de decisão, sabe-se que
apenas uma das suas transições de saída pode ser executada. Por este motivo, é
necessário que a escolha a partir do nó decisão seja mutuamente exclusiva. Quando são
usadas transições de saída com guarda, é possível que mais do que uma condição seja
verdadeira, tornando activas todas as transições onde isto se verifique.
Francisco Santos 18
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
Receber Proposta Comprador
Receber Preço Vendedor
Enviar Artigo ao Comprador
[ preço venda <= oferta compra ]
Devolver Artigo ao Vendedor
[ otherwise ]
Enviar Resultado Negociação ao Comprador
Enviar Resultado Negociação ao Vendedor
Figura 2.6 – Utilização explícita de nós de difusão e de junção
2.1.2.4 Fluxo de Objectos
O fluxo de objectos é uma técnica usada para modelar a forma como os objectos
participam em actividades e a forma como são afectados por elas. Na Figura 2.7 é
ilustrado um exemplo de um diagrama de actividades que contém um fluxo de objectos.
Neste caso um objecto do tipo ‘Encomenda’ é recebido pela actividade ‘Receber
Encomenda’, que é responsável por alterar o seu estado para ‘processada’. A actividade
‘Produzir Produto’ recebe a encomenda processada e produz um objecto do tipo
‘Produto’. O fluxo de execução termina com a emissão do objecto do tipo ‘Factura’.
Os fluxos de objectos são representados por uma seta a tracejado e ligam,
obrigatoriamente, objectos a actividades ou actividades a objectos. Quando a seta parte
do objecto em direcção à actividade, trata-se de um objecto de entrada. Quando a seta
parte da actividade em direcção ao objecto, trata-se de um objecto de saída. No caso de
haver um fluxo de objectos entre duas actividades está implicitamente definida uma
transição (representada por uma seta a cheio) entre essas duas actividades.
Francisco Santos 19
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
Receber Encomenda
Produzir Produto
Verificar Produto
Emitir Factura
: Encomenda : Encomenda[processada]
: Produto : Produto[verificado]
: Factura
Figura 2.7 – Diagrama de Actividades com fluxo de objectos
2.1.2.5 Pistas
As pistas (swimlanes) agrupam actividades de acordo com a sua responsabilidade.
Podem ser usadas para diferentes propósitos, como sendo mostrar em que objecto são
executadas as actividades, ou que parte da organização é responsável pela sua execução.
As pistas são representadas por rectângulos verticais no diagrama de actividades e as
actividades que fazem parte dessa pista são colocadas dentro do rectângulo. É atribuído
um nome à pista, que é colocado no topo do rectângulo. No âmbito organizacional
interpretam-se fluxos de objectos que partem de uma pista em direcção a outra como
troca de recursos (objectos) entre unidades organizacionais.
No exemplo da Figura 2.8 é ilustrado um processo de recepção de encomendas
com passagem de recursos entre as unidades da empresa e o cliente. O cliente efectua
uma encomenda, logo a origem do objecto do tipo ‘Encomenda’ é o ‘Cliente’. Após o
processamento da encomenda, o envio da factura e o início da produção do produto são
actividades concorrentes. O objecto do tipo ‘Factura’ é produzido pelo ‘Dep.
Comercial’ e é enviado ao ‘Cliente’ através da actividade ‘Enviar Factura’. Após a
recepção do pagamento e da finalização do produto, este é enviado ao cliente através da
actividade ‘Enviar Produto’.
Francisco Santos 20
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
Efectuar Encomenda
Efectuar Pagamento
Receber Produto
Processar Encomenda
Enviar Produto
Enviar Factura
Receber Pagamento
Produzir Produto
: Factura
: Produto[enviado]
: Encomenda
: Pagamento
: Encomenda[processada]
: Produto
Dep. ProduçãoDe lp. ComerciaCl eient Cliente Dep. Comercial Dep. Produção
Figura 2.8 – Diagrama de Actividades com fluxo de objectos e pistas
Francisco Santos 21
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
3 BPEL4WS Esta linguagem define um modelo e uma gramática para a descrição do comportamento
de um processo de negócio, baseado nas suas interacções com os parceiros de negócio.
A interacção com cada parceiro de negócio é feita através da interface de Web Services.
A estrutura de cada interacção encontra-se encapsulada por uma ligação a um parceiro
de negócio (partner link).
O processo BPEL4WS define como é que as múltiplas interacções com os
parceiros de negócio são coordenadas de forma a satisfazer um dado objectivo de
negócio, para além de descrever o estado e a lógica necessários a uma dada interacção.
3.1 Relação com o WSDL
O modelo de processos é suportado pelo modelo de serviços definido na especificação
WSDL 1.1. No núcleo do modelo de processos BPEL4WS existe a noção de interacção
ponto-a-ponto entre serviços, descrita em WSDL; tanto o processo como os seus
parceiros encontram-se modelados em WSDL. Um processo de negócio define como
deve ser feita a coordenação entre a instância do processo e os seus parceiros. Neste
sentido, uma definição particular de um processo BPEL4WS fornece e/ou utiliza um ou
mais serviços WSDL. Adicionalmente, descreve o comportamento e as interacções entre
a instância do processo e os parceiros de negócio, através da interface de Web Services.
Por outras palavras, a linguagem BPEL4WS define os protocolos de troca de mensagens
e, seguidamente, define o processo de negócio para um papel específico na interacção
entre parceiros.
Na definição de um processo BPEL4WS as mensagens e os tipos de portos
encontram-se separados da ligação (binding) aos serviços e informação de
endereçamento na rede, tal como é descrito no modelo WSDL. Em particular, o
processo BPEL4WS descreve os parceiros e respectivas interacções através de
interfaces WSDL abstractas (i.e. recorrendo apenas a operações e tipos de portos), não
sendo especificadas as ligações concretas aos serviços usados pela instância do
processo.
Francisco Santos 22
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
3.2 Definição de um Processo de Negócio
Antes de abordar a estrutura detalhada de um processo, definido na linguagem
BPEL4WS, é usado o exemplo já introduzido na Secção 2.1, que ilustra um processo de
recepção de encomendas de uma empresa. Neste caso, o exemplo será usado para
apresentar as principais estruturas e conceitos da linguagem BPEL4WS. De seguida, é
apresentada uma descrição mais detalhada dos elementos constituintes da linguagem.
Na Figura 3.1 é modelado o processo de recepção de encomendas. Neste
diagrama, recorre-se a conceitos mais próximos da linguagem BPEL4WS: os
rectângulos a tracejado representam sequências; os losangos seguidos de uma barra
horizontal representam conjuntos de actividades de execução concorrente; as setas a
tracejado representam ligações de controlo, usadas para sincronizar actividades
concorrentes. É importante notar que este diagrama não faz parte da especificação da
BPEL4WS, sendo apenas usado, informalmente, para melhor compreender o processo
descrito no exemplo.
Receber Encomenda
Calcular Preço Encomenda
Processar Preço Entrega
Gerar Factura
Gerar Pedido Entrega
Requisitar Entrega
Receber Prazo Entrega
Pedir Escalonamento Producao
Finalizar Escalonamento Producao
Fluxo1
Enviar Factura
Seq
uenc
ia1
Seq
uenc
ia2
Seq
uenc
ia3
Ligação de controlo
Receber Encomenda
Calcular Preço Encomenda
Processar Preço Entrega
Gerar Factura
Gerar Pedido Entrega
Requisitar Entrega
Receber Prazo Entrega
Pedir Escalonamento Producao
Finalizar Escalonamento Producao
Fluxo1
Enviar Factura
Seq
uenc
ia1
Seq
uenc
ia2
Seq
uenc
ia3
Ligação de controlo
Figura 3.1 – Processo de Recepção de Encomendas
Francisco Santos 23
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
3.2.1 Especificação do Serviço Associado ao Processo
No documento WSDL é feita a descrição do serviço associado ao processo de negócio.
Este documento descreve o formato das mensagens trocadas, os tipos de portos e os
tipos de ligações aos parceiros de negócio.
A definição abstracta do processo é feita apenas com base nos tipos de portos
para os serviços envolvidos no processo, independentemente da sua localização na rede.
Isto permite a utilização das definições do processo para múltiplas disposições dos
serviços na rede, sendo apenas exigida a sua compatibilidade com os tipos de portos
definidos.
O documento WSDL para a especificação do serviço contém as seguintes
definições:
• As mensagens (<message>): que são uma definição abstracta,
tipificada, para os dados usados nas operações do serviço.
• As operações (<operation>): que são uma descrição abstracta das
acções suportadas pelo serviço.
• Os tipos de portos (<portType>): representam colecções abstractas
das operações suportadas por um ou mais pontos terminais.
• Os tipos de ligações aos parceiros de negócio
(<partnerLinkType>): que descrevem as interacções com os
parceiros de negócio.
Os tipos de ligação aos parceiros de negócio (partner link types) podem ser
usados para representar as dependências entre serviços, independentemente de existirem
processos BPEL4WS associados a esses serviços. Cada tipo de ligação define até dois
nomes de papéis, explicitando para cada papel quais os tipos de portos que necessitam
ser suportados pelo serviço para que a interacção se realize com êxito.
Neste exemplo são definidos dois tipos de ligações a parceiros de negócio com
apenas um papel: ‘encomendar’ e ‘fabricar’. A existência de apenas um papel deve-se
ao facto de, nos dois casos, apenas uma das entidades envolvidas na interacção fornecer
as operações a invocar. A ligação ‘encomendar’ representa a interacção entre o serviço
de encomendas e o cliente, onde apenas são executadas operações do primeiro serviço
Francisco Santos 24
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
(ver Apêndice A – Ficheiro WSDL Protocolo Encomendar). A ligação ‘fabricar’
representa a interacção entre o serviço de encomendas e o serviço de escalonamento da
produção, onde apenas são invocadas operações do último. Os outros dois tipos de
ligações: ‘facturar’ e ‘enviar’, definem dois papéis cada. Tanto o serviço de cálculo do
valor da encomenda como o serviço de envio necessitam disponibilizar operações
callback de forma a permitir o envio de notificações assíncronas (tipos de portos:
‘ICallbackFacturacao’ e ‘ICallbackDistribuicao’ respectivamente).
3.2.2 Especificação Funcional do Processo
A estrutura das actividades do processo é descrita no documento BPEL, que está
separado da definição do serviço. Neste documento, escrito em XML, é descrita a forma
do processo armazenar os dados, a ordem de execução das actividades, a sequência e a
forma como devem ser contactados os parceiros de negócio e o procedimento a seguir
caso ocorra uma falha durante a execução.
Este documento encontra-se estruturado em quatro secções:
• A secção <variables> define as variáveis, que irão conter os dados
usados pelo processo, em termos de: tipos de mensagens WSDL, tipos
simples XML Schema e tipos compostos XML Schema.
• A secção <partnerLinks> define como é que os parceiros de
negócio interagem com o processo. No exemplo os parceiros associados
ao processo são: a entidade que efectua a encomenda, a entidade que
calcula o preço, a entidade responsável pelo envio e a entidade
responsável pelo escalonamento da produção.
• A secção <faultHandlers> descreve o procedimento para o
tratamento das faltas resultantes da execução do processo através de uma
sequência de actividades.
• A restante parte do documento contém a descrição do funcionamento
normal do processo. As actividades que fazem parte da descrição
funcional do processo encontram-se apresentadas a seguir.
Francisco Santos 25
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
Cada actividade de um processo BPEL4WS contém opcionalmente um nome e
os elementos aninhados: <source> e <target>. Estes dois elementos aninhados são
usados para criar ligações de controlo, que determinam a ordem de execução das
actividades de um processo. Cada ligação de controlo possui um nome e é definida
independentemente das outras. Define-se que uma actividade é origem de uma ou mais
ligações de controlo através da inclusão de um ou mais elementos <source>.
Analogamente, define-se que uma actividade é alvo de uma ou mais ligações de
controlo, através da inclusão de um ou mais elementos <target>. Todos os elementos
<source> associados a uma actividade têm de possuir um nome distinto.
Semelhantemente, todos os elementos <target> associados a uma actividade
precisam de nomes distintos. As principais actividades de um processo encontram-se
descritas na Tabela 3.1.
Actividade Elemento XML Descrição
BPELReceive <receive> Permite ao processo bloquear-se à espera da
recepção de um dado tipo de mensagem.
BPELReply <reply> Permite ao processo responder a uma mensagem
recebida através da actividade <receive>. A
combinação <receive> <reply> forma uma
operação bidireccional (síncrona) para um dado
tipo de porto do processo.
BPELInvoke <invoke> Permite ao processo invocar operações
unidireccionais (assíncronas) e bidireccionais
(síncronas) através de um tipo de porto
disponibilizado por um parceiro de negócio.
BPELAssign <assign> É usada para actualizar os valores das variáveis
com dados novos, podendo conter um número
arbitrário de atribuições elementares.
BPELThrow <throw> Permite gerar uma falta a partir do interior do
processo.
Francisco Santos 26
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
Actividade Elemento XML Descrição
BPELWait <wait> Permite esperar um determinado período de tempo,
sendo tipicamente usada para executar uma
operação a um dado instante no tempo.
BPELEmpty <empty> Permite inserir uma instrução nula no processo,
sendo útil para sincronizar actividades
concorrentes.
BPELSequence <sequence> Permite definir um conjunto de actividades a ser
executadas sequencialmente.
BPELSwitch <switch> Permite seleccionar exactamente um ramo de
execução a partir de um conjunto de opções.
BPELWhile <while> Permite repetir a execução de uma outra actividade
até que uma dada condição seja verdadeira.
BPELFlow <flow> Permite especificar uma ou mais actividades a ser
executadas concorrentemente. Podem ser usadas
ligações de controlo para determinar a ordem de
execução de um subconjunto das actividades
contidas no fluxo. Tabela 3.1 – Principais actividades de um processo BPEL4WS
No exemplo, a estrutura principal do processo encontra-se caracterizada pelo
elemento <sequence>, que define a ordem de execução das actividades constituintes
como sendo sequencial (ver Apêndice B – Ficheiro BPEL Processo). A encomenda do
cliente é recebida (elemento <receive>), depois é processada (elemento <flow>,
que permite a execução concorrencial das actividades constituintes) e, finalmente, é
enviada a resposta ao cliente (elemento <reply>).
Neste caso, foi utilizado um modelo de comunicação síncrono. Assume-se,
portanto, que o tempo de processamento é suficientemente curto para permitir que o
invocador do serviço espere por uma resposta síncrona ao seu pedido. Alternativamente,
podia ser usado um modelo de comunicação assíncrono. Para implementar este modelo
de comunicação, é necessário modificar a operação ‘enviarPedidoEncomenda’ para que
Francisco Santos 27
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
seja unidireccional e a resposta ao pedido de encomenda passa a ser enviada através de
uma segunda operação na interface callback do cliente. Para representar a interface
callback do cliente são necessárias duas modificações adicionais. Em primeiro lugar, a
ligação entre o processo e o cliente, ‘encomendar’, necessita de um papel adicional,
‘ClienteEncomenda’, contendo o tipo de porto para a interface callback do cliente.
Finalmente, a actividade <reply> no processo deve ser substituída pela actividade
<invoke>, com o objectivo de invocar a operação de envio de resposta, definida na
interface callback do cliente.
Dentro do elemento <flow> existem três blocos do tipo <sequence>, que se
executam concorrentemente. A sincronização entre as actividades contidas nos três
blocos <sequence> é feita através de ligações de controlo, descritas no início do
bloco <flow>. Na ausência de ligações de controlo as actividades dentro do fluxo são
executadas concorrentemente. No exemplo, a existência de duas ligações de controlo
determina a ordem de execução das actividades contidas em cada sequência. O cálculo
do preço da encomenda pode começar logo após a recepção do pedido por parte do
cliente. No entanto, o preço de envio só pode ser adicionado à encomenda depois do
distribuidor ter sido seleccionado; esta dependência é representada pela ligação
‘pedirEntrega-to-enviarPrecoEntrega’, que liga a invocação da operação ‘pedirEntrega’,
para a escolha do distribuidor, à invocação da operação ‘enviarPrecoEntrega’, que
remete o preço de envio para o serviço de facturação. Analogamente, a informação
sobre o prazo de envio da encomenda só pode ser enviada ao serviço de escalonamento
da produção depois de ter sido recebida do serviço do distribuidor; esta dependência é
representada pela ligação ‘receberPrazoEntrega-to-enviarPrazoEntrega’.
Os dados são passados entre as actividades, de uma forma implícita, através da
partilha de variáveis globais. Neste exemplo, as ligações de controlo de execução das
actividades estão relacionadas com as dependências de dados correspondentes. Existe
uma dependência associada à informação sobre o preço de envio e outra associada à
informação sobre o prazo de entrega da encomenda. A informação é transferida entre a
actividade que a cria para a actividade que consome através de duas varáveis globais:
‘informacaoEntrega’ e ‘prazoEntrega’.
Francisco Santos 28
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
Certas operações podem retornar faltas, tal como especificado no documento
WSDL. Para simplificar, no exemplo é assumido que as duas operações retornam a
mesma falta: ‘impossivelFinalizarEncomenda’. Quando ocorre uma falta, termina o
processamento normal e o controlo de execução é transferido para o tratador de faltas
correspondente, tal como definido na secção <faultHandlers> do documento
BPEL. Neste exemplo, o tratador de faltas usa um elemento do tipo <reply> para
enviar a falta ao cliente (observe a presença do atributo para o nome da falta,
‘faultName’, neste elemento <reply>).
Finalmente, é importante notar a forma como a actividade de atribuição,
<assign>, é usada para transferir dados entre variáveis distintas. As atribuições
ilustradas neste exemplo servem para transferir a secção de uma mensagem, guardada
numa variável origem, para a secção de uma outra mensagem, guardada numa variável
destino. Para além das atribuições simples do exemplo é possível definir atribuições
mais complexas nesta linguagem.
Francisco Santos 29
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
4 Conversão entre FCEO e BPEL4WS De forma a tornar possível a conversão dos modelos FCEO em modelos BPEL4WS
executáveis é necessário estender o perfil UML, definido na FCEO. Nesta Secção são
descritas as extensões introduzidas à framework, adequadamente justificadas, bem como
a conversão entre os artefactos dos modelos FCEO e BPEL4WS.
4.1 Extensão ao Perfil UML da FCEO
O perfil UML, definido actualmente na FCEO, não permite uma conversão automática
para a BPEL4WS. Não é possível identificar, de forma clara, quais são os parceiros de
negócio, quais as operações suportadas pelos parceiros e qual o papel que cada parceiro
desempenha na interacção com o processo. Adicionalmente, não é possível distinguir
entre as actividades de espera, atribuição, recepção, resposta e invocação (i.e. wait,
assign, receive, reply e invoke) da BPEL, não é possível especificar qual o formato das
mensagens trocadas entre os parceiros e o processo e não é possível definir a forma de
encaminhar as mensagens entre diferentes instâncias dos processos comunicantes. Para
colmatar os problemas identificados são descritas as alterações necessárias ao actual
perfil UML da FCEO, recorrendo ao perfil proposto em [AGGI03].
O diagrama de actividades apresentado na Figura 4.1 fornece uma vista global
do processo para a recepção de encomendas. Ao contrário do diagrama da Figura 2.2,
este foi concebido para permitir a conversão para a linguagem BPEL4WS. Em resumo,
este diagrama mostra que o processo possui quatro ligações a parceiros de negócio:
‘encomendar’, ‘enviar’, ‘facturar’ e ‘fabricar’, que estão representados pelas pistas. As
actividades que envolvem uma operação de recepção ou envio de mensagens, através de
uma ligação a um determinado parceiro de negócio, aparecem na pista correspondente.
Francisco Santos 30
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
receberEncomenda<<receiv e>>
env iarFactura<<reply >>
inicializarPedidoEntrega<<assign>>
pedirEntrega<<inv oke>>
receberPrazoEntrega<<receiv e>>
env iarPrecoEntrega<<inv oke>>
receberFactura<<receiv e>>
calcularPreco<<inv oke>>
pedirEscalonamentoProducao<<inv oke>>
env iarPrazoEntrega<<inv oke>>
Fa rbricaFacturarEnviarEncomendar encomendar enviar facturar fabricar
Figura 4.1 – Diagrama de Actividades para o Processo Receber Encomenda
Os tipos de dados devem ser representados através de classes UML com o
estereótipo <<data>>, conforme ilustrado na Figura 4.2. Estes tipos de dados podem
ser usados directamente pelas operações das interfaces dos protocolos de negócio ou,
alternativamente, como parte de mensagens mais complexas (ex.: ‘PedidoEntrega’ e
‘Encomenda’). Todos os tipos de dados base foram colocados no pacote
‘DefinicoesEncomenda’. As mensagens, que são definidas à custa dos tipos de dados
base, também se encontram definidas no mesmo pacote. Por exemplo, a mensagem
‘Encomenda’ é composta por dois tipos de dados base: ‘Cliente’, que contém
informação sobre o cliente, e ‘LinhaEncomenda’, que contém informação sobre os
vários produtos que foram encomendados.
Francisco Santos 31
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
Clientenome : Stringmorada : String
<<data>>
PedidoEntrega<<messageContent>>
+cliente
EncomendaFaultdescricaoProblema : String
<<messageContent>>Factura
eid : Stringinput : String
<<messageContent>>InformacaoEntregaeid : Stringinput : String
<<messageContent>>PrazoEntrega
eid : Stringinput : String
<<messageContent>>
Encomendaeid : String
<<messageContent>>
+cliente LinhanomeProduto : Stringquantidade : IntegerprecoUnitario : Float
<<data>>
LinhaEncomenda<<data>>
+linhaEncomenda
1..n1..n
Figura 4.2 – Tipos de Dados e Mensagens
O processo participa num protocolo através das ligações aos parceiros de
negócio. Um protocolo liga um par de papéis complementares, associados a cada um
dos parceiros, e especifica como é que esses papéis interagem. Cada papel disponibiliza,
opcionalmente, um conjunto de interfaces através das quais o papel complementar pode
interagir. As interfaces juntamente com os papéis complementares encontram-se
definidas em pacotes próprios com o estereótipo <<protocol>>. Na Figura 4.3 são
apresentados os protocolos de negócio, os papéis e as interfaces.
Francisco Santos 32
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
Encomendar<<protocol>>
ClienteEncomenda<<role>>
ServicoEncomenda<<role>>
IServicoEncomenda
enviarPedidoEncomenda()
Enviar<<protocol>>
ClienteDistribuicao<<role>>
ServicoDistribuicao<<role>>
ICallbackDistribuicao
enviarPrazoEntrega()
IServicoDistribuicao
pedirEntrega()
Fabricar<<protocol>>
ClienteProducao<<role>>
ServicoProducao<<role>>
IServicoProducao
pedirEscalonamentoProducao()enviarPrazoEntrega()
Facturar<<protocol>>
IServicoFacturacao
iniciarCalculoPreco()enviarPrecoEntrega()
ICallbackFacturacao
enviarFactura()
ClienteFacturacao<<role>>
ServicoFacturacao<<role>>
Figura 4.3 – Protocolos de Negócio, Papéis e Interfaces
Nesta fase, todas as definições necessárias ao processo foram fornecidas.
Embora estas definições tenham sido introduzidas no contexto do processo recepção de
encomendas, podem ser usadas independentemente do processo. Se os parceiros
também forem modelados como processos de negócio automatizados, então também
podem fazer uso destas definições. Mais genericamente, outros processos que
disponibilizem todos ou apenas uma parte dos papéis do processo recepção de
encomendas podem fazer uso destas definições.
Na Figura 4.4 é apresentada a classe ‘ProcessoReceberEncomenda’, com o
estereótipo <<process>>, que representa o processo recepção de encomendas. O
estado do processo é descrito pelos atributos da classe ‘ProcessoReceberEncomenda’,
cujos tipos de dados foram introduzidos no pacote ‘Encomenda’ ou importados do
pacote ‘DefinicoesEncomenda’. Adicionalmente possui quatro associações a papéis de
negócio, correspondentes aos quatros parceiros com os quais interage, definidos nos
pacotes <<protocol>> da Figura 4.3.
Francisco Santos 33
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
ServicoEncomenda(from Encomendar)
<<role>>
ClienteFacturacao(from Facturar)
<<role>>
ClienteProducao(from Fabricar)
<<role>> ClienteDistribuicao(from Enviar)
<<role>>
ProcessoReceberEncomendaencomenda : Encomendafactura : FacturaencomendaFault : EncomendaFaultprazoEntrega : PrazoEntregainformacaoEntrega : InformacaoEntregapedidoEntrega : PedidoEntrega
<<process>>
1+encomendar 1<<partnerLink>>
1+facturar
1
<<partnerLink>>
1+fabricar
1
<<partnerLink>>
1+enviar
1
<<partnerLink>>
Figura 4.4 – Processo Recepção de Encomendas
Cada ligação a um parceiro de negócio constitui um ponto de ligação para um
parceiro do processo. As interfaces, que são disponibilizadas ou solicitadas através de
uma ligação, estão definidas pelo papel que o processo desempenha no protocolo. Uma
ligação a um parceiro de negócio é representada por uma associação, com o estereótipo
<<partnerLink>>, entre o processo e o papel que este desempenha.
O ‘ProcessoReceberEncomenda’ disponibiliza a sua interface
‘IServicoEncomenda’ através da ligação ‘encomendar’, correspondente ao protocolo
‘Encomendar’, e solicita serviços através das restantes ligações: ‘facturar’, ‘fabricar’ e
‘enviar’. A ligação ‘facturar’ suporta comunicação bidireccional: o processo solicita a
interface ‘IServicoFacturacao’ e disponibiliza a interface ‘ICallbackFacturacao’, tal
como especificado pelo papel ‘ClienteFacturacao’ do protocolo ‘Facturar’. A ligação
‘enviar’ também é bidireccional, neste caso o processo solicita a interface
‘IServicoDistribuicao’ e disponibiliza a interface ‘ICallbackDistribuicao’.
O diagrama de actividades na Figura 4.5 mostra o comportamento do processo
recepção de encomendas, fazendo parte da classe ‘ProcessoReceberEcomenda’. É
idêntico ao diagrama da Figura 4.1 excepto que exibe um maior nível de detalhe. Cada
pista do diagrama corresponde a uma ligação a um parceiro de negócio. Actividades que
Francisco Santos 34
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
representem uma interacção através de um porto, seja de entrada ou de saída, associado
a um determinado parceiro de negócio, são colocadas na pista respectiva, com setas de
controlo de fluxo a indicar a sua sequência de execução. Cada actividade é identificada
por um nome descritivo. As acções de entrada, representadas por um evento do tipo
entry, descrevem o trabalho realizado numa dada actividade.
receberEncomenda<<receiv e>>
entry / env iarPedidoEncomenda(encomenda)
env iarFactura<<reply >>
entry / env iarPedidoEncomenda() := f actura
inicializarPedidoEntrega<<assign>>
entry / pedidoEntrega/inf Cliente := encomenda/inf Cliente
pedirEntrega<<inv oke>>
entry / inf ormacaoEntrega := pedirEntrega(pedidoEntrega)
receberPrazoEntrega<<receiv e>>
entry / env iarPrazoEntrega(prazoEnt...
env iarPrecoEntrega<<inv oke>>
entry / env iarPrecoEntrega(inf ormacaoEn...
receberFactura<<receiv e>>
entry / env iarFactura(f actura)
calcularPreco<<inv oke>>
entry / iniciarCalculoPreco(encomenda)
pedirEscalonamentoProducao<<inv oke>>
entry / pedirEscalonamentoProducao(encomenda)
env iarPrazoEntrega<<inv oke>>
entry / env iarPrazoEntrega(prazoEnt...
FabricarFacturarEnviarEncomendar encomendar enviar facturar fabricar
Figura 4.5 – Diagrama de Actividades detalhado para o Processo Receber Encomenda
A actividade ‘receberEncomenda’ contém o estereótipo <<receive>>,
tratando-se, por isso, da recepção de uma mensagem através de uma ligação, neste caso
da ligação ‘encomendar’. A expressão:
enviarPedidoEncomenda(encomenda)
indica o nome da operação a invocar, através da ligação ‘encomendar’, e o nome do
atributo onde a mensagem recebida é guardada. A actividade ‘enviarFactura’ possui o
estereótipo <<reply>> indicando que o resultado deve ser enviado ao invocador da
anterior actividade <<receive>>. Ambas as actividades fazem referência à mesma
operação: ‘enviarPedidoEncomenda’, sendo que a actividade de recepção especifica o
Francisco Santos 35
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
atributo no qual a mensagem recebida deve ser guardada e a actividade de resposta
especifica o atributo a partir do qual a mensagem de resposta deve ser criada. A
expressão:
enviarPedidoEncomenda() := factura
indica que o valor do atributo ‘factura’ deve constituir a resposta à operação
‘enviarPedidoEncomenda’. As actividades ‘pedirEntrega’ e
‘pedirEscalonamentoProducao’ possuem o estereótipo <<invoke>>, indicando que
invocam uma operação através de um porto. A actividade
‘pedirEscalonamentoProducao’ não especifica o atributo de resposta, pelo que se trata
de uma actividade assíncrona (unidireccional). A expressão:
pedirEscalonamentoProducao(encomenda)
indica que a operação ‘pedirEscalonamentoProducao’ é invocada com o valor do
atributo ‘encomenda’. A actividade ‘pedirEntrega’, por sua vez, é síncrona
(bidireccional). A expressão:
informacaoEntrega := pedirEntrega(pedidoEntrega)
indica que a operação ‘pedirEntrega’ deve ser invocada, tendo como parâmetro o valor
do atributo ‘pedidoEntrega’. Na actividade ‘inicializarPedidoEntrega’ não é feita
qualquer interacção com parceiros de negócio, sendo apenas copiado o valor de uma
variável para outra. O operador ‘:=’ é usado na atribuição de valores.
Tal como na linguagem BPEL4WS, a passagem dos dados neste exemplo é feita
recorrendo a variáveis no ambiente do processo, que no modelo UML são representadas
através dos atributos da classe do processo. Por exemplo, a actividade
‘receberEncomenda’ recebe um valor, através da ligação ‘encomendar’, que é guardado
na variável ‘encomenda’, sendo depois lida pela actividade
‘pedirEscalonamentoProducao’ e depois usada como parâmetro de entrada na operação
invocada por essa actividade.
Francisco Santos 36
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
4.2 Delineação do Processo de Conversão UML BPEL
Pretende-se nesta Secção delinear o processo de conversão UML para BPEL. As classes
com o estereótipo <<data>> contém a definição dos tipos de dados usados no âmbito
do negócio. Por exemplo: a entidade de informação ‘cliente’ tem os seguintes atributos:
‘nome’, representado por uma cadeia de caracteres, e ‘morada’, igualmente
representado por uma cadeia de caracteres. Os tipos de dados são convertidos em
representações equivalentes no formato XML Schema Definition (XSD). As mensagens,
representadas através de classes com o estereótipo <<messageContent>>, fazem
uso dos anteriores tipos de dados, juntamente com os tipos de dados elementares XSD,
para definir o seu conteúdo. Estas mensagens são usadas para trocar informação entre o
processo e os parceiros de negócio. O resultado da conversão destas classes é colocado
num documento WSDL, que é importado por todos os protocolos de negócio. Para cada
protocolo, contido num pacote <<protocol>>, é definida uma ligação a um parceiro
de negócio. A ligação contém dois papéis complementares, sendo que um é
desempenhado pelo processo e o outro pelo parceiro. Os papéis definem a interface das
operações que podem ser executadas por cada entidade comunicante. Cada protocolo é
colocado num ficheiro WSDL separado. Para cada processo de negócio, descritos
através das classes com o estereótipo <<process>>, é gerado um ficheiro BPEL.
Todos os ficheiros WSDL, correspondentes aos protocolos onde o processo participa,
são importados por este ficheiro. Na Figura 4.6 é ilustrado o esquema dos documentos
XML gerados pelo processo de conversão.
Francisco Santos 37
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
WSDL
Mensagens
XSD
Tipos de dados
WSDL
Protocolo de negócio
WSDL
Protocolo de negócio
BPEL
Processo de negócio
…
importação
WSDL
Mensagens
XSD
Tipos de dados
WSDL
Protocolo de negócio
WSDL
Protocolo de negócio
BPEL
Processo de negócio
…
importação Figura 4.6 – Esquema dos Documentos XML gerados pelo Processo de Conversão
Francisco Santos 38
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
4.3 Organização do Espaço Nomes
A organização do espaço nomes e a definição de unidades reutilizáveis do modelo é
feita recorrendo ao diagrama de pacotes do UML. As dependências no espaço de nomes
são representadas através das dependências de importação do UML.
DefinicoesEncomenda
Facturar<<protocol>>
Enviar<<protocol>>
Fabricar<<protocol>>
Encomendar<<protocol>>
ReceberEncomenda
<<import>><<import>> <<import>>
<<import>> <<import>> <<import>> <<import>>
<<import>>
Figura 4.7 – Exemplo de Dependência entre Pacotes
4.3.1 Notação
Os pacotes são usados para agrupar elementos e para criar um espaço de nomes. Em
UML, as dependências entre pacotes são designadas permissões. As dependências entre
pacotes são representadas recorrendo à seta de permissão do tipo <<import>>, tal
como ilustrado na Figura 4.8. A utilização da importação permite ao pacote que faz
importação referenciar os elementos, contidos no pacote importado, sem que seja
necessário usar nomes qualificados. Por exemplo, se a ‘classe X’ estiver definida no
‘Pacote1’, então o ‘Pacote2’ pode referenciar a ‘classe X’ directamente, sem ter de usar
o nome qualificado ‘Pacote1::X’.
Francisco Santos 39
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
Pacote1
Pacote2
<<import>>
Figura 4.8 – Notação para o pacote e para a dependência entre pacotes
4.3.2 Geração dos Ficheiros XSD, WSDL e BPEL
A hierarquia de pacotes de um modelo corresponde a uma hierarquia de espaços de
nome em XML. O nome do modelo em si (pacote de topo) também contribui para o
espaço de nomes. O prefixo para o espaço de nomes, usado nos ficheiros XML gerados,
é especificado durante o processo de conversão. A estrutura dos directórios onde os
ficheiros gerados serão colocados corresponde à hierarquia de espaços de nomes
definida anteriormente. Finalmente, a dependência <<import>> entre pacotes
corresponde à importação de um espaço de nomes em XML.
Os protocolos de negócio encontram-se definidos nos pacotes do tipo
<<protocol>>, dando origem à geração dos ficheiros WSDL correspondentes.
Nestes ficheiros encontram-se definidas as ligações aos parceiros de negócio, os papéis
complementares da interacção e os portos que o processo e o parceiro deverão
implementar para que o protocolo se realize. A cada processo do modelo corresponderá
um ficheiro BPEL, contendo a descrição do processo na linguagem executável. A
participação do processo nos protocolos de negócio pode ser feita com o papel de
cliente ou com o papel de serviço. Todas as operações suportadas pelo papel de serviço
devem ser implementadas pelo processo BPEL. A inclusão de mais de um processo por
pacote não é suportada pelo perfil.
No exemplo apresentado na Figura 4.7 é gerado um ficheiro XML Schema
Definition (XSD) [FW04] contendo os tipos de dados base que resultam da conversão
Francisco Santos 40
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
das classes <<data>> compreendidas no pacote ‘DefinicoesEncomenda’. As
mensagens que dependem destes tipos de dados e os conjuntos de correlação, usados no
diálogo entre processos assíncronos, são descritos num ficheiro WSDL.
Para cada protocolo é gerado um ficheiro WSDL com os papéis suportados. Para
cada papel é disponibilizado um conjunto de interfaces através das quais o papel
complementar pode interagir. As interfaces, por sua vez, definem um conjunto de
operações suportadas bem como os tipos de mensagens, de entrada e saída, associadas a
cada operação. O pacote ‘ReceberEncomenda’ contém um processo, representado por
uma classe do tipo <<process>>, de nome ‘ProcessoReceberEncomenda’, ver Figura
4.4. Durante a conversão é gerado um ficheiro BPEL com ligações aos protocolos de
negócio onde o processo participa: ‘Facturar’, ‘Encomendar’, ‘Fabricar’ e ‘Enviar’. O
processo implementa o papel de serviço no protocolo ‘Encomendar’, pelo que
implementa a funcionalidade das operações definidas nas interfaces deste papel.
O espaço de nomes é construído com base num prefixo, nome do modelo,
seguido da hierarquia de pacotes usada. Por exemplo, para o caso do
‘ProcessoReceberEncomenda’, contido no pacote ‘ReceberEncomenda’ e para um
prefixo: ‘http://www.example.org’, o nome qualificado corresponde a: http://www.example.org/ProcessamentoEncomendas/ReceberEncomenda/ProcessoReceberEncomenda
Analogamente, o nome qualificado correspondente ao documento ‘TiposDados’,
contido no pacote ‘DefinicoesEncomenda’ é dado por: http://www.example.org/ProcessamentoEncomendas/DefinicoesEncomenda/TiposDados
A estrutura de directórios espelha a hierarquia do espaço de nomes, definida
anteriormente, tendo como raiz um directório com o nome do modelo:
‘ProcessamentoEncomendas’, e como sub-directórios os vários pacotes definidos.
4.4 Conversão dos Tipos de Dados e Mensagens
É possível converter, automaticamente, os tipos de dados e as mensagens em UML para
o formato XSD/WSDL, recorrendo a um conjunto de regras. No perfil, os tipos de
dados são definidos através de classes com o estereótipo <<data>>. Por sua vez, as
Francisco Santos 41
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
mensagens são definidas através das classes com o estereótipo
<<messageContent>>. Como resultado da conversão devem ser criados dois
ficheiros. No ficheiro XSD deverão ser colocados os tipos de dados e no ficheiro WSDL
deverão ser colocadas as mensagens. A separação entre os dois documentos permite
aumentar a modularidade da solução, reutilizar os mesmos tipos de dados base em
outros projectos, usar esquemas já existentes e facilitar a manutenção do projecto.
4.4.1 Geração dos Ficheiros XSD e WSDL
Todas as classes com o estereótipo <<data>> são convertidas num tipo composto:
complexType [FW04]. O nome a atribuir é constituído pelo nome da classe seguido de
“Type”. Este sufixo serve para distinguir entre tipos e elementos em XSD. Para cada
tipo XSD deve ser criado o elemento respectivo. Recorre-se à etiqueta element para
definir os elementos em XSD. O nome a atribuir ao elemento é igual ao do tipo que lhe
deu origem, excepto que a primeira letra é minúscula e que o sufixo “Type” é excluído
do nome.
Os atributos de cada classe UML dão origem a uma sequência de elementos
dentro do tipo XSD composto. Estes elementos, por sua vez, podem referenciar um tipo
XSD simples ou complexo. Um elemento referencia um tipo simples sempre que o
atributo do modelo UML seja elementar, por exemplo: ‘String’, ‘Integer’, ‘Double’, etc
(ver Apêndice C – Conversão de Tipos Básicos da UML para o Formato XSD). Neste
caso, o seu nome é igual ao atributo do modelo UML que lhe deu origem. Quando a
classe está associada a outras classes do tipo <<data>>, o elemento passa a referenciar
o tipo XSD correspondente à classe associada [BM04]. Neste caso, o nome do elemento
é constituído pelo nome da classe associada, devendo iniciar-se por uma letra
minúscula. Deve ainda ser considerada a multiplicidade dos elementos que participam
na associação, alterando em conformidade os campos: ‘minOccurs’ e ‘maxOccurs’, do
elemento XSD. Na Tabela em baixo encontra-se exemplificada a conversão das
diferentes expressões de multiplicidade possíveis em UML para XSD.
Francisco Santos 42
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
Expressão UML minOccurs maxOccurs
0..1 0 1
1 1 1
m..n m n
1..* 1 unbounded Tabela 4.1 – Conversão das Expressões de Multiplicidade
Sempre que exista herança entre duas classes <<data>> deve usar-se o
elemento extension. A extensão é declarada no tipo XSD que solicita a herança,
definindo, como base da extensão, o tipo XSD associado à classe da qual pretende
herdar. Podem ser usados nomes de atributos iguais na super- e na sub-classe. Na
Tabela 4.2 encontra-se exemplificada a conversão de vários exemplos de classes
<<data>> para o formato XSD.
Modelo UML Conversão para XSD
<xsd:complexType name=”ClasseAType”>
<xsd:sequence>
<xsd:element name=”attribA” type=”string”/>
<xsd:element name=”attribB” type=”boolean”/>
<xsd:element name=”attribC” type=”int”/>
</xsd:sequence>
</xsd:complexType>
ClasseAattribA : StringattribB : BooleanattribC : Integer
<<data>>
ClasseA<<data>>
ClasseB<<data>>
1..n0..10..1 1..n
<!-- geracao tipo ‘ClasseAType’ -->
<xsd:complexType name=”ClasseAType”>
<xsd:sequence>
<xsd:element name=”classeB” type=”tns:ClasseBType” minOccurs=”1” maxOccurs=”unbounded” />
</xsd:sequence>
</xsd:complexType>
<!-- geracao tipo ‘ClasseBType’ -->
<xsd:complexType name=”ClasseBType”>
<xsd:sequence>
<xsd:element name=”classeA” type=”tns:ClasseAType” minOccurs=”0” maxOccurs=”1” />
</xsd:sequence>
</xsd:complexType>
Francisco Santos 43
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
Modelo UML Conversão para XSD
ClasseA<<data>>
ClasseB<<data>>
1..n0..10..1 1..n
<!-- geracao tipo ‘ClasseAType’ -->
<xsd:complexType name=”ClasseAType”>
<xsd:sequence>
<xsd:element name=”classeB” type=”tns:ClasseBType” minOccurs=”1” maxOccurs=”unbounded” />
</xsd:sequence>
</xsd:complexType>
<!-- geracao tipo ‘ClasseBType’ -->
<xsd:complexType name=”ClasseBType” />
ClasseAattribA : String
<<data>>
ClasseBattribB : String
<<data>>
<!-- geracao tipo ‘ClasseAType’ -->
<xsd:complexType name="ClasseAType">
<xsd:sequence>
<xsd:element name="attribA" type="string"/>
</xsd:sequence>
</xsd:complexType>
<!-- geracao tipo ‘ClasseBType’ -->
<xsd:complexType name="ClasseBType">
<xsd:complexContent>
<xsd:extension base="tns:ClasseAType">
<xsd:sequence>
<xsd:element name="attribB" type="string"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
Tabela 4.2 – Conversão Modelo UML para Formato XSD
As mensagens e as secções constituintes devem ser colocadas num ficheiro
WSDL, separado do ficheiro XSD que contém o esquema dos tipos de dados base. Cada
classe do tipo <<messageContent>> dá origem a um elemento message no ficheiro
WSDL. Para cada atributo da classe é acrescentada uma etiqueta part ao elemento da
mensagem. Sempre que um atributo seja elementar recorre-se ao método de conversão
usado para os tipos de dados base (ver Apêndice C – Conversão de Tipos Básicos da
UML para o Formato XSD). Os restantes atributos da classe devem referenciar um tipo
XSD composto previamente definido. Nas Figuras em baixo é ilustrado um exemplo de
conversão de uma mensagem para o formato WSDL juntamente com os tipos de dados
Francisco Santos 44
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
utilizados. Note-se que o esquema importado através do ficheiro WSDL corresponde ao
ficheiro XSD que contém a definição dos tipos de dados base.
Clientenome : Stringmorada : String
<<data>>
Encomendaeid : String
<<messageContent>>
+cliente
LinhanomeProduto : Stringquantidade : IntegerprecoUnitario : Float
<<data>>
LinhaEncomenda<<data>>
+linhaEncomenda
1..n1..n
Figura 4.9 – Cenário Conversão para uma Encomenda
… <xsd:complexType name="ClienteType"> <xsd:sequence> <xsd:element name="nome" type="xsd:string"/> <xsd:element name="morada" type="xsd:string"/> </xsd:sequence> </xsd:complexType> <xsd:complexType name="LinhaEncomendaType"> <xsd:sequence> <xsd:element name="linhas" type="LinhaType"/> </xsd:sequence> </xsd:complexType> <xsd:complexType name="LinhaType"> <xsd:sequence maxOccurs="unbounded"> <xsd:element name="nomeProduto" type="xsd:string"/> <xsd:element name="quantidade" type="xsd:int"/> <xsd:element name="precoUnitario" type="xsd:float"/> </xsd:sequence> </xsd:complexType> …
Figura 4.10 – Ficheiro XSD correspondente aos Tipos de Dados Base da Encomenda
Francisco Santos 45
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
…
<types>
<schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="http://www.w3.org/2001/XMLSchema"
…
elementFormDefault="qualified" >
<import namespace="…" schemaLocation="Ficheiro.xsd"/>
<element name="cliente" type="tns:ClienteType"/>
<element name="linhaEncomenda" type="tns:LinhaEncomendaType"/>
</schema>
</types>
…
<message name="Encomenda">
<part name="eid" type="xsd:string"/>
<part name="cliente" element="tns:cliente"/>
<part name="linhaEncomenda" element="tns:linhaEncomenda"/>
</message>
…
Figura 4.11 – Ficheiro WSDL correspondente à Encomenda
4.5 Conversão das Propriedades e Conjuntos de Correlação
Numa primeira abordagem ao problema da comunicação entre processos pode parecer
viável que para enviar uma mensagem a um processo seja apenas necessário conhecer o
seu porto WSDL. Isto é uma ilusão, pois os processos têm estado e necessitam ser
instanciados no início de cada interacção. Por este motivo, qualquer solução para o
encaminhamento das mensagens entre processos deve ter em conta, não só o porto
WSDL do destinatário, como também a correcta identificação da instância do processo.
A infra-estrutura tecnológica de suporte à comunicação entre processos deve permitir
ainda que o encaminhamento das mensagens seja feito de uma forma genérica, sem
obrigar a que cada implementação de um processo possua o seu próprio mecanismo de
encaminhamento [AGGI03].
No mundo orientado por objectos cada objecto possui uma referência, usada
para a comunicação entre objectos. Este mecanismo funciona razoavelmente bem em
ambientes onde exista um acoplamento forte (tight coupling) das entidades
comunicantes, onde a dependência na implementação do mecanismo de referências é
considerada normal. No mundo dos Web Services, que operam num ambiente onde
Francisco Santos 46
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
existe um acoplamento fraco das entidades comunicantes, torna-se necessário usar um
mecanismo de encaminhamento que seja independente, tanto quanto possível, da
implementação dos processos. A solução passa por usar os identificadores dos dados
que compõem as mensagens trocadas entre processos. Esta é a única solução que
promete sobreviver à evolução independente das implementações dos processos, uma
vez que depende apenas da estrutura das mensagens descritas no protocolo de negócio.
A esta solução de encaminhamento de mensagens dá-se o nome de: correlação.
O conjunto de valores usados para identificar a instância numa comunicação
com correlação é designado por: conjunto de correlação. Todas as mensagens trocadas
através do mecanismo de correlação devem conter os dados do conjunto de correlação
correspondente. É permitido, no entanto, que estes valores se situem em lugares
diferentes na mensagem. Por exemplo: a mensagem ‘Encomenda’ pode conter o
identificador no atributo ‘encomendaID’, mas a mensagem ‘Factura’ pode conter o
identificador no atributo ‘cabecalho/encID’. Por este motivo os conjuntos de correlação
são definidos através de propriedades. As propriedades permitem abstrair do local na
mensagem onde se situam os identificadores dos dados. Cada propriedade possui um
nome e um tipo XSD. Para cada mensagem que contenha uma dada propriedade deve
ser referido o caminho para aceder aos dados correspondentes na mensagem.
4.5.1 Notação
As definições das propriedades são introduzidas no modelo através de uma classe com o
estereótipo <<properties>>. Cada propriedade é expressa como um atributo da
classe, contendo um nome e o tipo correspondente. Para cada mensagem que
implemente uma dada propriedade é definida uma operação na classe
<<properties>>, com o mesmo nome dessa propriedade. Estas operações têm
como único atributo o tipo da mensagem a partir da qual é extraída a propriedade e têm
um tipo de retorno igual ao da propriedade associada. Associa-se uma expressão XPath
a cada operação de modo a definir a forma como deve ser extraída a propriedade a partir
da mensagem. Genericamente, a XML Path Language (XPath) permite aceder aos nós
dos documentos XML, usando uma sintaxe compacta e independente da linguagem
Francisco Santos 47
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
XML [CR99]. Neste contexto específico a linguagem é usada para aceder às secções
constituintes da mensagem.
Na Figura 4.12 é ilustrado um exemplo de definição de propriedades no modelo
UML. A classe ‘ConjuntoPropriedades’, do tipo <<properties>>, define duas
propriedades: ‘propriedade1’ e ‘propriedade2’. São definidos dois métodos de extracção
para cada propriedade. As primeiras duas operações definem a forma de extrair a
‘propriedade1’ das mensagens do tipo: ‘TipoMensagem1’ e ‘TipoMensagem2’. As
restantes duas operações definem como se extrai a ‘propriedade2’ das mensagens do
tipo: ‘TipoMensagem2’ e ‘TipoMensagem3’.
ConjuntoPropriedadespropriedade1 : Stringpropriedade2 : Integer
propriedade1(msg1 : TipoMensagem1) : Stringpropriedade1(msg2 : TipoMensagem2) : Stringpropriedade2(msg2 : TipoMensagem2) : Integerpropriedade2(msg3 : TipoMensagem3) : Integer
<<properties>>
Figura 4.12 – Notação para as Propriedades
Um conjunto de correlação é definido por uma classe com o estereótipo
<<correlation>>. Os atributos correspondem às propriedades definidas no mesmo
espaço de nomes da classe, sendo que os nomes e tipos são concordantes. A utilização
de um conjunto de correlação por parte de um processo é descrita através da inclusão de
um atributo com o tipo do conjunto de correlação. O estereótipo <<correlation>>
é também aplicado ao atributo para que seja mais fácil distingui-lo dos restantes
atributos do processo. Na Figura 4.13 é ilustrado um exemplo onde a classe
‘ConjuntoCorrelacao1’ é utilizada pela classe ‘Processo1’. O conjunto de correlação,
definido pela classe ‘ConjuntoCorrelacao1’, faz referência às propriedades definidas
anteriormente no exemplo da Figura 4.12.
Francisco Santos 48
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
ConjuntoCorrelacao1propriedade1 : Stringpropriedade2 : Integer
<<correlation>>
Processo1<<correlation>> correlacao1 : ConjuntoCorrelacao1
<<process>>
Figura 4.13 – Exemplo da inclusão de um Conjunto de Correlação num Processo
No caso mais simples, todas as mensagens recebidas e enviadas pelo processo
usam o mesmo conjunto de correlação, sendo este inicializado no arranque do processo.
Neste caso é apenas necessário associar o conjunto ao processo, conforme ilustrado na
Figura 4.13. Nos outros casos torna-se necessário associar, individualmente, um
conjunto de correlação às actividades de interacção: invoke, receive e reply. Note-se que
apenas as actividades de interacção podem estar associadas a um conjunto de
correlação. Na Figura 4.14 encontra-se ilustrado um exemplo de uma actividade de
interacção, neste caso do tipo receive, onde se define quais os conjuntos de correlação a
usar no acto da recepção da mensagem: ‘msg1’, através da operação: ‘operacao1’.
Actividade1
entry/ operacao1(msg1)entry/ <expressão de correlação>
<<receive>>
Figura 4.14 – Exemplo de uma Actividade que usa Correlação
É usado o prefixo: correlation:, para indicar o começo de uma expressão
de correlação. As expressões de correlação indicam quais são os conjuntos de
correlação usados pela actividade. Sempre que uma actividade use mais do que um
conjunto, os nomes dos restantes conjuntos de correlação deverão estar separados por
vírgulas.
Francisco Santos 49
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
Exemplos de expressões de correlação:
• correlation: correlacao1
• correlation: correlacao1, correlacao2
Em BPEL, quando um conjunto de correlação é usado pela primeira vez é
necessário inicializá-lo. Por este motivo, as actividades que usam em primeira-mão um
dado conjunto de correlação devem proceder à sua inicialização. Na linguagem BPEL é
possível que múltiplas actividades concorrentes suportem a inicialização do mesmo
conjunto de correlação. A primeira actividade a usar um determinado conjunto ficará
encarregue de proceder à sua inicialização. Obtém-se este comportamento sempre que
seja colocada a palavra initialize antes do nome do conjunto, na expressão de
correlação da actividade.
Exemplos de expressões de correlação com a palavra initialize:
• correlation: initialize correlacao1
• correlation: correlacao1, initialize correlacao2
Sempre que, através da actividade invoke, se execute uma operação síncrona, é
possível usar conjuntos de correlação diferentes para as mensagens recebidas e
enviadas. Neste caso, são necessárias duas acções de entrada para definir os conjuntos
de correlação a usar em cada sentido. De forma a distinguir entre os dois conjuntos, as
expressões de correlação são precedidas pelas palavras: in, no caso da recepção de
mensagens, e out, no caso do envio.
Exemplos de expressões de correlação para a invocação de operações síncronas:
• in correlation: correlacao1
• out correlation: correlacao2
4.5.2 Geração dos Ficheiros WSDL e BPEL
Cada atributo de uma classe <<properties>> corresponde à definição de uma
propriedade no ficheiro WSDL. As operações da classe correspondem aos métodos de
extracção das propriedades para cada tipo de mensagem em WSDL (propertyAlias). Se
Francisco Santos 50
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
convertermos o exemplo da Figura 4.12 obtemos o código WSDL apresentado na
Figura 4.15. Note-se que, embora não conste no diagrama UML da classe
‘ConjuntoPropriedades’, cada operação define uma interrogação XPath para aceder às
propriedades nos diferentes tipos de mensagens. Neste exemplo assume-se que na
mensagem do tipo ‘TipoMensagem2’ a informação referente à ‘propriedade1’ está
contida no elemento ‘parte1’ e a informação referente à ‘propriedade2’ está contida no
elemento ‘parte2’.
<!-- propriedades --> <bpws:property name=”propriedade1” type=”xsd:string” /> <bpws:property name=”propriedade2” type=”xsd:int” /> <!-- metodos de acesso --> <bpws:propertyAlias propertyName=”tns:propriedade1” messageType=”tns:TipoMensagem1” part=”parte1” query=”/parte1/”/> <bpws:propertyAlias propertyName=”tns:propriedade1” messageType=”tns:TipoMensagem2” part=”parte1” query=”/parte1/”/> <bpws:propertyAlias propertyName=”tns:propriedade2” messageType=”tns:TipoMensagem2” part=”parte2” query=”/parte2/”/> <bpws:propertyAlias propertyName=”tns:propriedade2” messageType=”tns:TipoMensagem3” part=”parte1” query=”/parte1/”/>
Figura 4.15 – Definição Propriedades em WSDL
Cada atributo do tipo <<correlation>>, contido num processo, corresponde
à definição de um conjunto de correlação no ficheiro BPEL para esse processo. A
definição das propriedades desse conjunto provém da classe <<correlation>> que
está associada ao atributo. A conversão para BPEL do exemplo descrito na Figura 4.13
resulta no código BPEL apresentado na Figura 4.16.
<correlationSets> <correlationSet name=”correlacao1” properties=”tns:propriedade1 tns:propriedade2”/> </correlationSets>
Figura 4.16 – Definição de Conjuntos de Correlação em BPEL
As expressões de correlação contidas nas actividades UML são convertidas em
expressões de correlação para as actividades do processo BPEL. A actividade com
correlação, descrita na Figura 4.14, resulta no código BPEL apresentado na Figura em
baixo.
Francisco Santos 51
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
<receive name="actividade1" partnerLink="…" portType="…" operation="initiate" variable="…" createInstance="…"> <correlations> <correlation set="conjuntoCorrelacao1" initiate="yes"/> </correlations> </receive>
Figura 4.17 – Definição de Actividades Correlacionadas em BPEL
4.6 Conversão dos Protocolos de Negócio
Na relação entre um processo e um parceiro de negócio pode existir comunicação uni-
ou bi-direccional. Um protocolo une dois papéis complementares, por exemplo: o
Comprador e o Vendedor, e define quais são as interfaces oferecidas e requeridas por
cada um. Um processo possui um conjunto de portos, onde cada porto está associado a
um papel no protocolo de negócio. O papel define quais são as interfaces oferecidas e
requeridas por esse porto.
Na Figura 4.3 são ilustrados quatro protocolos de negócio: ‘Encomendar’,
‘Enviar’, ‘Fabricar’, ‘Facturar’. Os protocolos: ‘Encomendar’ e ‘Fabricar’ são
unidireccionais, e os restantes são bidireccionais.
4.6.1 Notação
Um protocolo é modelado como um pacote com o estereótipo <<protocol>>. Cada
protocolo contém um par de classes do tipo <<role>>. O nome do protocolo é igual
ao nome do pacote onde está contido. Cada pacote <<protocol>> deve conter
apenas um protocolo.
Na Figura 4.18 é apresentada a definição do protocolo de negócio: ‘Protocolo1’.
O ‘Papel1’ oferece a ‘Interface1’ e requer a ‘Interface2’, e o ‘Papel2’ oferece a
‘Interface2’ e requer a ‘Interface1’. Se este protocolo fosse unidireccional, seria
definida apenas uma interface, oferecida por um dos papéis e requerida pelo
complementar. Na Figura 4.19 é apresentada a definição detalhada da ‘Interface1’ e da
‘Interface2’. O argumento de entrada da operação tem sempre o nome ‘input’ e pode
estar associado a uma mensagem (classe <<messageContent>>) ou tipo de dados
base (classe <<data>>). Tratando-se de uma operação síncrona, é também necessário
Francisco Santos 52
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
definir o tipo de retorno. Tal como no caso do argumento de entrada, o tipo de retorno
pode estar associado a uma mensagem ou tipo de dados base.
Protocolo1<<protocol>>
Papel2<<role>>
Interface2
operacao2()
Papel1<<role>> Interface1
operacao1()
Figura 4.18 – Exemplo da Notação dos Protocolos de Negócio e Papéis
Interface1
operacao1(input : TipoEntrada1) : TipoRetorno1
Interface2
operacao2(input : TipoEntrada2) Figura 4.19 – Exemplo da Notação das Interfaces
4.6.2 Geração do Ficheiro WSDL
Para cada pacote do tipo <<protocol>> é criada uma ligação a um parceiro de
negócio. Os papéis do protocolo são convertidos em papéis desta ligação. As interfaces
realizadas pelos papéis correspondem aos tipos de portos, sendo que o nome do tipo de
porto é igual ao nome da interface. Protocolos que apenas suportem a comunicação
unidireccional são convertidos em ligações com apenas um papel. O código WSDL,
Francisco Santos 53
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
apresentado na Figura 4.20, resulta da conversão do protocolo de negócio, descrito
anteriormente.
<portType name="Interface1"> <operation name="operacao1"> <input message="ns1:TipoEntrada1"/> <output message="ns1:TipoRetorno1"/> </operation> </portType> <portType name="Interface2"> <operation name="operacao2"> <input message="ns1:TipoEntrada2"/> </operation> </portType> <plnk:partnerLinkType name="Protocolo1"> <plnk:role name="Papel1"> <plnk:portType name="tns:Interface1"/> </plnk:role> <plnk:role name="Papel2"> <plnk:portType name="tns:Interface2"/> </plnk:role> </plnk:partnerLinkType>
Figura 4.20 – Ficheiro WSDL com a definição das Ligações a Parceiros e Papéis
4.7 Conversão de Processos
Um processo automatizado descreve os passos de execução de uma tarefa do negócio,
possivelmente envolvendo várias entidades internas ou externas à organização. O
processo possui estado e interage com os parceiros de negócio através de protocolos
bem definidos. Cada ligação a um parceiro de negócio constitui um ponto de ligação
para um parceiro do processo. As interfaces, que são disponibilizadas ou solicitadas
através de uma ligação, estão definidas pelo papel que o processo desempenha no
protocolo.
4.7.1 Notação
Um processo é modelado através de uma classe com o estereótipo <<process>>.
Uma ligação a um parceiro de negócio é representada por uma associação, com o
estereótipo <<partnerLink>>, entre o processo e o papel que este desempenha. O
‘ProcessoReceberEncomenda’, ilustrado na Figura 4.4, possui quatro ligações a
parceiros de negócio: ‘encomendar’, ‘facturar’, ‘enviar’ e ‘fabricar’, e o seu estado é
Francisco Santos 54
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
representado através de seis atributos: ‘encomenda’, ‘factura’, ‘encomendaFault’,
‘prazoEntrega’, ‘informacaoEntrega’ e ‘pedidoEntrega’.
4.7.2 Geração do Ficheiro BPEL
Cada classe que contenha o estereótipo <<process>> é convertida numa definição de
um processo BPEL, com os seguintes atributos:
Atributo Valor Descrição
abstractProcess no Este perfil suporta apenas a modelação de processos executáveis [ACDG+03].
variableAccessSerializable no Os contextos BPEL serializáveis [ACDG+03] não são suportados por este perfil.
enableInstanceCompensation no Os contextos BPEL de compensação [ACDG+03] não são suportados por este perfil.
suppressJoinFailure yes As falhas de junção [ACDG+03] ocorrem sempre que todas as ligações de entrada de uma actividade BPEL estejam inactivas. Este evento não é considerado um erro neste perfil.
Tabela 4.3 – Atributos para a Definição de um Processo BPEL
O prefixo do espaço de nomes do processo é fornecido no início do processo de
conversão. A restante parte do espaço de nomes é constituída pelo nome do modelo,
estrutura de pacotes e o nome do processo.
Os atributos do processo são convertidos em variáveis BPEL e as associações
com o estereótipo <<partenerLink>>, que ligam o processo aos papéis do
protocolo, são convertidas em ligações a parceiros de negócio. Não é necessário
especificar o papel desempenhado pelo parceiro uma vez que este, automaticamente,
assume o papel complementar, definido no protocolo de negócio. No Apêndice B –
Ficheiro BPEL ProcessoReceberEcomenda – encontra-se descrita a conversão do
‘ProcessoReceberEncomenda’.
Francisco Santos 55
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
4.8 Manipulação do Estado do Processo
Ao longo da vida útil de um processo de negócio, torna-se necessário actualizar e
manipular o seu estado interno. O perfil recorre à linguagem XPath para manipular os
atributos do processo através de expressões, permitindo uma conversão directa para
BPEL. Isto deve-se ao facto da XPath ser a linguagem usada por omissão na definição
de expressões em BPEL.
4.8.1 Linguagem XPath
O principal objectivo da linguagem XPath é o de aceder ao conteúdo de um documento
XML [CR99]. Para poder processar os dados contidos nos documentos XML, a
linguagem disponibiliza um conjunto de funções adequadas à manipulação de cadeias
de caracteres, números e valores booleanos. Esta linguagem usa uma notação compacta,
diferente da notação XML, para facilitar a sua utilização em Universal Resource
Identifiers (URIs) e nos valores dos atributos XML. A XPath opera na estrutura lógica
abstracta de um documento XML em vez de na sua sintaxe superficial. Um documento
XML é visto como uma árvore de nós. Os nós podem ser de vários tipos diferentes,
incluindo: nós elemento (element), nós atributo (attribute) e nós texto (text), sendo que
para cada um existe uma representação textual definida pela linguagem.
O principal constructo sintáctico na XPath é a expressão. Uma expressão
corresponde à produção ‘Expr’ da gramática XPath. O resultado da avaliação de uma
expressão pode ser de quatro tipos: conjunto de nós (conjunto desordenado de nós sem
duplicados), valor booleano, número (de vírgula flutuante) ou cadeia de caracteres. A
avaliação de expressões é sempre feita com base num contexto. O contexto consiste em:
um nó (designado nó contexto), um par de inteiros positivos, constituído pela posição e
tamanho do contexto, um conjunto de ligações de variáveis, uma biblioteca de funções,
um conjunto de espaços nomes válidos neste contexto. O tamanho do contexto
representa o número de nós filho do nó contexto. A posição representa o identificador
numérico, começado em um, do nó filho que está a ser analisado. Facilmente se
depreende que o valor da posição é sempre inferior ao tamanho do contexto. As ligações
de variáveis representam a correspondência entre o nome de uma variável e o seu valor.
Francisco Santos 56
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
A biblioteca de funções faz a correspondência entres os nomes das funções e as próprias
funções. Na Secção 4 de [CR99] é descrito o conjunto de funções base que faz parte de
qualquer implementação XPath. No contexto da linguagem BPEL são acrescentadas
algumas funções a esta biblioteca para seleccionar atributos de um processo de negócio
e para obter o seu valor. Por fim, o conjunto de espaços de nomes faz a correspondência
entre os prefixos e os URIs dos espaços de nomes.
Uma expressão com particular interesse é o caminho. O caminho selecciona um
conjunto de nós relativos ao nó contexto. Os caminhos, que correspondem à produção
‘LocationPath’ da gramática XPath, podem conter, recursivamente, outras expressões
que sejam usadas para filtrar o conjunto de nós resultante. Existem dois tipos de
caminhos: relativos e absolutos.
Os caminhos relativos consistem numa sequência de um ou mais passos,
separados por uma barra (‘/’). Os passos são construídos da esquerda para a direita.
Cada passo selecciona um conjunto de nós relativamente a um nó contexto. Após a
avaliação de uma sequência de ‘k’ passos obtemos um determinado conjunto de nós do
documento XML. O passo ‘k+1’ utiliza, como nós contexto, todos os nós pertencentes
ao conjunto anterior. No final da execução do passo ‘k+1’ é feita a união dos nós
encontrados com o conjunto anterior.
Os caminhos absolutos consistem numa barra seguida de um caminho relativo.
A barra, por si só, selecciona a raiz do documento XML. Se esta for sucedida por um
caminho relativo, o resultado é igual à avaliação da expressão do caminho relativo,
tendo como nó contexto a raiz do documento.
Um passo do caminho é composto por três partes: um eixo, um selector de nós e
zero ou mais predicados. O eixo identifica qual a relação que existe entre os nós
seleccionados pelo passo e o nó contexto. Por exemplo: child identifica uma relação
de “pai para filho”, descendant identifica uma relação de descendência, que inclui
todos os filhos e, recursivamente, os filhos dos filhos, e parent identifica uma relação
de “filho para pai”. O selector do nó identifica o tipo de nó a encontrar ou o nome
expandido do nó (composto pelo URI do espaço de nomes e o nome local). Os
predicados são expressões arbitrárias que servem para refinar ainda mais o conjunto de
nós encontrado neste passo. A sintaxe para a definição de um passo é a seguinte: nome
Francisco Santos 57
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
do eixo, separado por ‘::’, selector do nó, seguido de zero ou mais predicados entre
parênteses rectos (‘[‘ e ‘]’). Por exemplo:
child::paragrafo[position()=1]
child é o nome do eixo, paragrafo é o selector do nó e position()=1 é o
predicado. Este passo do caminho selecciona o primeiro filho, de nome paragrafo, a
partir do contexto.
4.8.2 Expressões de Acesso aos Dados
Cada expressão de acesso aos dados é começada pelo nome de um atributo (ou
variável) do processo. Para aceder a uma secção da mensagem correspondente ao
atributo concatena-se uma barra ao nome do atributo e acrescenta-se o nome da secção.
Por exemplo, a expressão:
encomenda/cliente
permite aceder à secção ‘cliente’ da mensagem ‘encomenda’, que representa um
atributo do processo.
A especificação BPEL acrescenta duas novas funções à especificação XPath. A
função ‘getVariableData’ recebe como argumentos: o nome da variável do processo
(ex.: ‘encomenda’), a secção da mensagem que deve ser acedida (‘cliente’) e,
opcionalmente, uma expressão que representa o caminho para aceder aos dados contidos
na secção anterior (ex.: ‘morada/codigoPostal’). Como resultado da aplicação desta
função obtém-se o nó correspondente à secção da mensagem ou à selecção descrita pelo
terceiro argumento. Se o resultado da aplicação da selecção devolver um conjunto de
nós com cardinalidade diferente de um, a função devolve um erro. A função
‘getVariableProperty’ recebe como argumentos: o nome da variável do processo (ex.:
‘factura’) e o nome de uma propriedade que esteja associada à mensagem anterior (ex.:
‘encomendaID’). Após a aplicação desta função obtém-se o valor associado à
propriedade da mensagem, que resulta da avaliação da expressão XPath associada à
propriedade (ver Secção 4.5). Se o resultado da avaliação da expressão XPath
Francisco Santos 58
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
correspondente à propriedade devolver um conjunto de nós com cardinalidade diferente
de um, é devolvido um erro.
As expressões de acesso aos dados são convertidas em aplicações de uma das
funções anteriores: ‘getVariableData’ ou ‘getVariableProprety’. O primeiro argumento
de ambas as funções corresponde ao atributo do processo. O segundo argumento pode
representar o nome de uma secção ou o nome de uma propriedade da mensagem
anterior. Se representar o nome de uma secção é aplicada a função ‘getVariableData’,
caso represente uma propriedade é aplicada a função ‘getVariableProperty’. Na tabela
em baixo são apresentados alguns exemplos de conversão de expressões de acesso aos
dados.
Expressão acesso aos dados Conversão BPEL encomenda/cliente
onde ‘encomenda’ é uma variável do tipo ‘Encomenda’ e ‘cliente’ é o nome de uma secção dessa mensagem
getVariableData(‘encomenda’,’cliente’)
encomenda/cliente/morada/codigoPostal
onde ‘encomenda’ é uma variável do tipo ‘Encomenda’ e a restante parte da expressão representa um caminho para aceder aos dados da mensagem
getVariableData(‘encomenda’,’cliente’,’/morada/codigoPostal’)
factura/encomendaID
onde ‘factura’ é uma variável do tipo ‘Factura’ e ‘encomendaID’ representa uma propriedade da mensagem
getPropertyData(‘factura’,’encomendaID’)
Tabela 4.4 – Exemplos de Expressões de Acesso aos Dados
4.8.3 Expressões de Atribuição
As expressões de atribuição, usadas nas actividades <<assign>>, são necessárias
para modificar o valor dos atributos de um processo. Uma vez que não fazem parte da
Francisco Santos 59
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
linguagem XPath base, torna-se necessário introduzir a sua definição. Estas expressões
são constituídas por um operador atribuição ‘:=’ entre duas expressões XPath normais.
Como resultado da avaliação destas expressões, o valor da expressão direita é copiado
para o elemento seleccionado pela expressão esquerda. Por exemplo:
factura/cliente := encomenda/cliente
copia o valor do atributo ‘cliente’ da mensagem ‘encomenda’ para o atributo ‘cliente’
da mensagem ‘factura’.
4.8.4 Geração das Actividades BPEL
Nesta Secção é descrita a conversão das actividades individuais, que compõem o
diagrama de actividades do processo, em BPEL. O processo de conversão ao nível da
actividade é invocado durante a construção do grafo de actividades BPEL, usado pelo
algoritmo descrito na Secção 4.8.5.1.
4.8.4.1 Actividade de Atribuição
As actividades de atribuição (BPELAssign) são usadas para actualizar os valores dos
atributos de um processo, podendo conter um número arbitrário de atribuições
elementares. Em UML, as atribuições são descritas através das actividades com o
estereótipo <<assign>>, recorrendo às expressões de atribuição (ver Secção 4.8.3). O
processo de conversão das actividades <<assign>> é ilustrado através de um
exemplo:
Atribuicao1<<assign>>
entry/ encomenda/aprovada := 'true'entry/ factura/cliente := encomenda/clienteentry/ factura/data := getDataHora()
Figura 4.21 – Exemplo de uma Actividade de Atribuição
A conversão da actividade anterior resulta no seguinte código BPEL:
Francisco Santos 60
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
<assign name="Atribuicao1"> <copy> <from expression="‘true’)"/> <to variable="encomenda" part="aprovada"/> </copy> <copy> <from expression="getVariableData(‘encomenda’,’cliente’)"/> <to variable="factura" part="cliente"/> </copy> <copy> <from expression="getDataHora()"/> <to variable="factura" part="data"/> </copy> </assign>
Figura 4.22 – Exemplo da conversão de uma Actividade de Atribuição para BPEL
Note-se que tanto a biblioteca de funções base da linguagem XPath 1.0 [CR99]
como a da linguagem BPEL [ACDG+03] não incluem funções para manipular datas,
pelo que a existência da função ‘getDataHora()’, descrita no exemplo anterior e que
devolve a data e hora actuais, depende da plataforma escolhida para a execução do
processo.
4.8.4.2 Actividade de Espera
A actividade de espera (BPELWait) permite modelar eventos temporais, i.e. períodos
de espera ou prazos, na sequência de actividades de um processo. Em UML,
representam-se as actividades de espera com o estereótipo <<wait>> e recorre-se a
expressões XPath para modelar eventos temporais. Na modelação de períodos de espera
o resultado da avaliação da expressão XPath deve ser do tipo: XSD duration [BM04].
Para a modelação de prazos o tipo de dados resultante da expressão XPath dever ser:
XSD date ou dateTime [BM04]. De forma a distinguir entre os dois tipos de eventos
temporais, coloca-se o prefixo ‘for’, no caso dos períodos de espera, e ‘until’, no
caso dos prazos, antes da expressão XPath temporal. O processo de conversão das
actividades <<wait>> é ilustrado através de um exemplo:
Francisco Santos 61
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
esperarPelaProducao<<wait>>
entry/ until escalonamentoProducao/finalizacaoEncomenda
enviarEncomenda
Figura 4.23 – Exemplo de uma Actividade de Espera
A conversão da actividade de espera anterior resulta no seguinte código BPEL:
<wait name=”esperarPelaProducao” until=”getVariableData(‘escalonamentoProducao’,’finalizacaoEncomenda’)”/>
Figura 4.24 – Exemplo da conversão de uma Actividade de Atribuição para BPEL
4.8.4.3 Actividade de Invocação
É normal que um processo invoque operações dos parceiros de negócio várias vezes
durante a sua execução. Uma actividade de invocação (BPELInvoke) pode ser do tipo:
síncrono ou assíncrono. Na invocação síncrona é retornado um valor e, em caso de erro,
é devolvida uma excepção. Na invocação assíncrona, a actividade de invocação termina
assim que seja enviado o pedido, não sendo retornado qualquer valor ou excepção. A
resposta assíncrona do parceiro para o processo é modelada através de uma actividade
de invocação adicional. Em UML, as actividade de invocação são representadas pelo
estereótipo <<invoke>>. O processo de conversão das actividades de invocação é
ilustrado através de um exemplo:
Francisco Santos 62
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
invocar1<<invoke>>
entry/ operacao1( atrib1 )
invocar2<<invoke>>
entry/ atrib3 := operacao2( atrib2 )
ligacaoParceiro2ligacaoParceiro1
Figura 4.25 – Exemplo da Invocação de Operações Síncronas e Assíncronas
A conversão das actividades de invocação anteriores resulta no seguinte código
BPEL:
<!-- actividade de invocação assíncrona, operação: operação1 -->
<invoke name="invocar1" partnerLink="ligacaoParceiro1" portType="ligacaoParceiro1:IServicoXXX" operation="operacao1" inputVariable="atrib1" />
<!-- actividade de invocação síncrona, operação: operação2 -->
<invoke name="invocar2" partnerLink="ligacaoParceiro2" portType="ligacaoParceiro2:IServicoYYY" operation="operacao2" inputVariable="atrib2" outputVariable="atrib3"/>
Figura 4.26 – Exemplo da Conversão de Actividades de Invocação Síncronas e Assíncronas
4.8.4.4 Actividade de Recepção e de Resposta
Um processo disponibiliza o conjunto de operações a executar pelos seus parceiros
através das actividades de recepção (BPELReceive). As respostas síncronas são
modeladas através de uma actividade de resposta (BPELReply) correspondente,
significando que o parceiro fica bloqueado à espera da resposta ao seu pedido. Em
UML, as actividades de recepção são representadas através do estereótipo
<<receive>>, tendo, como acção de entrada, a operação invocada pelo parceiro, cujo
único atributo é a variável onde é colocada a mensagem recebida. As actividades de
resposta são modeladas através do estereótipo <<reply>>, tendo, como acção de
entrada, uma expressão de atribuição, cujo lado esquerdo contém a operação invocada
Francisco Santos 63
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
inicialmente pelo parceiro e no lado direito contém a variável a partir da qual deve ser
gerada a resposta. A actividade de resposta é colocada na mesma pista da actividade de
recepção correspondente. O processo de conversão das actividades de recepção e
resposta é ilustrado através de um exemplo:
receber1<<receive>>
entry/ operacao1( atrib1 )
responder1<<reply>>
entry/ operacao1() := atrib2
invocar2<<invoke>>
entry/ operacao2( atrib1 )
receber3<<receive>>
entry/ operacao3( atrib2 )
ligacaoParceiro2ligacaoParceiro1
Figura 4.27 – Exemplo da utilização de Actividades de Recepção e Reposta
Na Figura 4.27 é ilustrado um exemplo de um pedido síncrono, representado
pelas actividades ‘receber1’ e ‘responder1’, que formam um par recepção/resposta
através da ligação ‘ligacaoParceiro1’. A mensagem correspondente à invocação da
‘operacao1’ é guardada na variável do processo ‘atrib1’. O processo invoca a
‘operacao2’ através da ligação ‘ligacaoParceiro2’, enviando a mensagem contida no seu
atributo ‘atrib1’. Na actividade ‘receber3’ é ilustrado um exemplo de um pedido
assíncrono, note-se que não existe uma actividade de resposta correspondente.
Finalmente, é enviada a resposta ao pedido inicial através da actividade ‘resposta1’.
Neste caso, é enviada a mensagem contida no atributo ‘atrib2’. A conversão das
actividades de recepção e resposta do exemplo resultam no seguinte código BPEL:
Francisco Santos 64
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
<receive name="receber1" variable="atrib1" createInstance="yes" operation="operacao1" partner="ligacaoParceiro1" portType="ligacaoParceiro1:IServicoXXX" suppressJoinFailure="no"/>
…
<receive name="receber3" variable="atrib2" createInstance="no" operation="operacao3" partner="ligacaoParceiro2" portType="ligacaoParceiro2:ICallbackYYY" suppressJoinFailure="no"/>
<reply name="responder1" partnerLink="ligacaoParceiro1" portType=" ligacaoParceiro1:IServicoXXX " operation="operacao1" variable="atrib2"/>
Figura 4.28 – Exemplo da Conversão de Actividades de Recepção e Resposta
As actividades de recepção são também usadas para criar a instância do
processo, pelo que são sempre executadas antes de qualquer outro tipo de actividade1.
Na conversão de uma actividade de recepção inicial para BPEL é colocado o valor ‘yes’
no atributo ‘createInstance’, significando que ao executar-se é criada uma nova
instância do processo. Caso a ordem de chegada dos pedidos iniciais não seja previsível,
é possível haver mais do que uma actividade de recepção responsável pela criação da
instância do processo [ACDG+03]. Todas as actividades de recepção iniciais devem
partilhar os mesmos conjuntos de correlação.
4.8.4.5 Actividade de Decisão
As actividades de decisão (BPELSwitch) dão suporte ao comportamento condicional
dos processos. Esta actividade consiste num conjunto de uma ou mais condições
mutuamente exclusivas, definas por elementos case. Opcionalmente, pode incluir-se
uma condição de excepção através do elemento otherwise, sendo escolhida sempre que
todas as outras condições sejam falsas. A execução desta actividade termina assim que a
actividade correspondente à condição escolhida tenha terminado a sua execução. Em
UML, as actividades de decisão são representadas através dos nós de decisão do
diagrama de actividades, sendo as condições especificadas através de expressões XPath
cuja avaliação resulte num valor booleano. O processo de conversão das actividades de
decisão é ilustrado através do seguinte exemplo:
Francisco Santos 65
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
Actividade 1
Actividade 2
Actividade 3
Actividade 4
Actividade 5
[ cond1 ][ cond2 ]
[ otherwise ]
Figura 4.29 – Exemplo da utilização de Actividades de Decisão
Na Figura 4.29 é apresentado um diagrama de actividades com um nó de decisão
e de fusão. Do nó de decisão partem três ligações de controlo, cada um com uma
condição de transição mutuamente exclusiva: ‘cond1’, ‘cond2’ e ‘otherwise’, que é
verdadeira sempre que ‘cond1’ e ‘cond2’ sejam falsas. A conversão do diagrama de
actividades do exemplo resulta no seguinte código BPEL:
<!-- actividade1 --> <switch> <!-- ‘cond1’ --> <case condition=”…”> <!-- actividade2 --> <!-- actividade3 --> </case> <!-- 'cond2’ --> <case condition=”…”> <!-- actividade4 --> </case> <otherwise> <empty/> </otherwise> </switch> <!-- actividade5 -->
Figura 4.30 – Exemplo da Conversão de uma Actividade de Decisão para BPEL
1 Nota: a actividade BPEL pick [ACDG+03] também pode ser usada no início para criar a instância do processo. Esta actividade não é suportada pelo perfil.
Francisco Santos 66
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
4.8.5 Conversão do Diagrama de Actividades
Um grafo é definido por um conjunto de vértices ‘V’ e um conjunto de arcos ‘E’, onde
os arcos representam ligações entre os vértices. Os grafos podem ser dirigidos ou não
dirigidos, consoante exista (ou não) a noção de direcção nos arcos. O diagrama de
actividades da UML é um grafo dirigido, onde os vértices representam as actividades e
os arcos representam as ligações de controlo. Uma actividade só se executa quando
todas as ligações de controlo de entrada estiverem activas. Quando uma actividade
finaliza a sua execução, todas as ligações de controlo de saída ficam activas. Desta
forma é possível que várias actividades se executem concorrentemente. Na linguagem
BPEL, as actividades encontram-se estruturadas em árvores. São usadas duas
actividades estruturantes para construir uma árvore BPEL: BPELSequence, que
representa uma sequência de actividades BPEL, e BPELFlow, que representa um
conjunto de actividades BPEL concorrentes. É possível sincronizar actividades
concorrentes recorrendo às ligações de controlo em BPEL.
Uma vez que as duas metodologias de modelação: UML e BPEL, usam
representações diferentes para a concorrência entre actividades, torna-se necessário usar
um algoritmo para separar as actividades UML concorrentes em sequências e fluxos
paralelos de execução, preservando a noção de concorrência descrita inicialmente no
diagrama de actividades UML. Os restantes artefactos do diagrama de actividades da
UML são facilmente convertíveis, usando as regras de conversão apresentadas
anteriormente.
4.8.5.1 Geração da Árvore do Processo BPEL
O algoritmo desenvolvido está dividido em três fases: conversão das actividades UML
em BPEL, geração da árvore BPEL e optimização da árvore gerada. Na primeira fase,
as actividades UML são convertidas em actividades BPEL equivalentes, através das
regras de conversão apresentadas nas Secções anteriores. É usada uma representação em
grafo para armazenar o resultado da conversão inicial, onde os vértices do grafo são as
actividades BPEL. Todos os arcos constantes no diagrama de actividades UML original
Francisco Santos 67
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
são adicionados ao grafo de actividades BPEL. Considere-se, como exemplo, o seguinte
diagrama de actividades UML:
Actividade1<<receive>>
Actividade2<<assign>>
[ cond1 ]
Actividade4<<invoke>>
Actividade3<<invoke>>
[ cond2 ]
Actividade6<<reply>>
Actividade5<<wait>>
Figura 4.31 – Exemplo Diagrama Actividades UML
Após todas as actividades da Figura 4.31 terem sido convertidas obtém-se o seguinte
grafo BPEL: BPELReceivenome: Actividade1
BPELSwitchnome: Decisao1
BPELAssignnome: Actividade2
BPELInvokenome: Actividade3
BPELMergenome: Fusao1
BPELInvokenome: Actividade4
BPELWaitnome: Actividade5
BPELReplynome: Actividade6
cond: ‘cond2’cond: ‘cond1’
BPELReceivenome: Actividade1
BPELSwitchnome: Decisao1
BPELAssignnome: Actividade2
BPELInvokenome: Actividade3
BPELMergenome: Fusao1
BPELInvokenome: Actividade4
BPELWaitnome: Actividade5
BPELReplynome: Actividade6
cond: ‘cond2’cond: ‘cond1’
Figura 4.32 – Grafo de Actividades BPEL
Na segunda fase, é gerada uma árvore com base no grafo BPEL recorrendo às
duas actividades estruturantes: BPELSequence e BPELFlow. Torna-se necessário
Francisco Santos 68
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
separar as actividades BPEL do grafo em sequências e fluxos concorrentes. Existem
pelo menos duas técnicas básicas para a travessia de grafos: pesquisa em largura e
pesquisa em profundidade. Dado um grafo ‘G=(V,E)’ e um vértice raiz ‘s’, a pesquisa
em largura explora, sistematicamente, todos os arcos de ‘G’ para descobrir cada vértice
atingível a partir de ‘s’. Para qualquer vértice ‘v’ atingível a partir de ‘s’, o caminho na
árvore de pesquisa em profundidade corresponde ao caminho mais curto de ‘s’ a ‘v’, na
medida em que contém o menor número de arcos. A razão do nome “pesquisa em
profundidade” deve-se ao facto do algoritmo descobrir todos os vértices ‘v’ que se
encontram à distância ‘k’ de ‘s’ antes de descobrir os que estão à distância ‘k+1’.
Na pesquisa em profundidade, os arcos são explorados a partir do último vértice
descoberto ‘v’ que ainda tenha arcos de saída por explorar. O algoritmo continua até
que todos os vértices atingíveis a partir do vértice inicial tenham sido descobertos. Se
restarem vértices por descobrir então um deles é seleccionado e a pesquisa continua a
partir dele. É possível usar a pesquisa em profundidade para classificar os arcos do
grafo em quatro tipos distintos: arcos de árvore, arcos para trás, arcos para a frente,
arcos de cruzamento. Um arco ‘(u, v)’ é um arco de árvore se ‘v’ foi descoberto pela
primeira vez devido à exploração de ‘(u, v)’. Os arcos para trás ligam um vértice ‘u’ a
um vértice ‘v’, antecessor na mesma árvore de pesquisa. Os arcos para a frente ligam
um vértice ‘u’ a um vértice ‘v’, descendente na mesma árvore de pesquisa. Os arcos de
cruzamento podem ligar vértices dentro da mesma árvore de pesquisa, desde que um
vértice não seja antecessor do outro, ou podem ligar vértices entre árvores de pesquisa
diferentes. Prova-se que um grafo dirigido é acíclico somente se a pesquisa em
profundidade não encontrar arcos para trás [CLRS01].
Através da pesquisa em profundidade é possível obter a ordenação topológica
dos vértices de um grafo. A ordenação topológica dos vértices de um grafo dirigido
acíclico ‘G=(V,E)’ é uma ordenação linear de todos os seus vértices tal que se ‘G’
contém o arco ‘(u, v)’ então ‘u’ aparece antes de ‘v’ na ordenação. Se o grafo que
representa o diagrama de actividades não tiver ciclos, i.e. não tiver arcos para trás, e se
interpretarmos a existência de um arco ‘(u, v)’ no grafo como uma ligação de controlo
entre as actividades ‘u’ e ‘v’, então, através da ordenação topológica obtém-se
sequência de actividades BPEL. Na Figura 4.33 podemos observar o resultado da
Francisco Santos 69
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
ordenação topológica dos vértices de um grafo dirigido acíclico. Após a execução do
conjunto de acções descritas no vértice ‘A’ seguido das do vértice ‘B’, passa a ser
possível executar as acções dos vértices: ‘C’, ‘D’ e ‘E’, em paralelo. No entanto, após a
ordenação topológica todas as actividades são executadas em série, pelo que a noção de
concorrência é perdida, podendo reduzir significativamente a eficiência de execução do
processo BPEL resultante da conversão.
Ordenação topológica possível: A,B,C,D,F,E,G
A
B
C D E
F G
Ordenação topológica possível: A,B,C,D,F,E,G
A
B
C D E
F G
A
B
C D E
F G
Figura 4.33 – Ordenação Topológica
Dado que as actividades em BPEL estão estruturadas em árvores, as próprias
árvores de pesquisa, resultantes da travessia em largura e em profundidade, são uma
conversão possível para o grafo de actividades BPEL. Assim, os nós da árvore que
tenham um número de descendentes superior a um representam um BPELFlow, com um
número de actividades concorrentes igual ao número de descendentes do nó. Os nós
com um número de descendentes igual a um são adicionados a uma BPELSequence.
Todos os arcos para a frente e de cruzamento correspondem a ligações de controlo em
BPEL. Se for encontrado um arco para trás, sabe-se de imediato que existem ciclos no
grafo e que o processo UML não pode ser convertido num processo BPEL. Devido ao
facto do algoritmo de pesquisa em profundidade classificar os arcos do grafo e
identificar a presença de ciclos durante a própria travessia, é possível gerar a árvore a
partir do grafo BPEL numa só iteração. Por este motivo prefere-se a utilização da
travessia em profundidade à travessia em largura para construir a árvore de actividades
BPEL. A implementação do algoritmo com base na travessia em profundidade permite
Francisco Santos 70
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
que o tempo de execução seja linear, proporcional à soma do número de arcos e vértices
do grafo BPEL: ‘O(V+E)’. Em [CLRS01] é feita uma demonstração formal do tempo
de execução do algoritmo de travessia em profundidade.
As regras a aplicar durante a travessia em profundidade para gerar a árvore
BPEL encontram-se descritas na Tabela em baixo. As regras estão seriadas segundo a
sua ordem de aplicação.
Arco ‘(u, v)’
Actividade ‘u’
‘(u, v)’ é arco de árvore ‘(u, v)’ é arco para a frente
ou de cruzamento, onde ‘v’
não é um BPELMerge
BPELSwitch Criar um novo ramo do nó
decisão, com a condição de
transição do arco.
Pesquisar a partir de ‘v’ e
adicionar todas as
actividades encontradas ao
ramo do BPELSwitch.
Criar um novo ramo do nó
decisão, com a condição de
transição do arco.
Adicionar uma actividade
BPELEmpty ao ramo.
Criar uma ligação de
controlo entre a actividade
BPELEmpty e ‘v’.
BPELMerge2 Pesquisar a partir de ‘v’ e
adicionar todas as
actividades encontradas a
seguir ao BPELSwitch
correspondente.
Criar uma ligação de
controlo entre o
BPELSwitch
correspondente e ‘v’.
2 Pressupõe a existência de um BPELSwitch prévio
Francisco Santos 71
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
Arco ‘(u, v)’
Actividade ‘u’
‘(u, v)’ é arco de árvore ‘(u, v)’ é arco para a frente
ou de cruzamento, onde ‘v’
não é um BPELMerge
Grau saída de ‘u’ superior a
um
Criar um BPELFlow.
Criar uma BPELSequence
para cada arco ‘(u, v)’ deste
tipo. Todas as actividades
encontradas a partir de ‘v’
são adicionadas a esta
sequência.
Criar uma ligação de
controlo entre ‘u’ e ‘v’ para
cada arco ‘(u, v)’ deste
tipo.
Grau de saída de ‘u’ igual a
um
Todas as actividades
encontradas a partir de ‘v’
são adicionadas à
BPELSequence actual.
Criar uma ligação de
controlo entre ‘u’ e ‘v’.
Tabela 4.5 – Regras para a Geração da Árvore BPEL
Aplicando as regras da Tabela 4.5 ao grafo da Figura 4.32 obtém-se a árvore BPEL
ilustrada em baixo.
Francisco Santos 72
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
Actividade1
Actividade3
Actividade6
Actividade2
Actividade4
Actividade5
Fluxo2
Fluxo1
cond1 cond2
Ligação de controlo
Decisao1
Seq
uenc
ia1
Seq
uenc
ia2
Seq
uenc
ia3
Seq
4
Seq
5
Actividade1
Actividade3
Actividade6
Actividade2
Actividade4
Actividade5
Fluxo2
Fluxo1
cond1 cond2
Ligação de controlo
Decisao1
Seq
uenc
ia1
Seq
uenc
ia2
Seq
uenc
ia3
Seq
4
Seq
5
Figura 4.34 – Árvore BPEL
A árvore gerada com base no algoritmo de pesquisa em profundidade tende a
produzir actividades de características: redundantes, i.e. que não têm significado para a
execução do processo ou não alteram o seu estado interno, e lentas, i.e. que podem ser
substituídas por outras que demoram menos tempo a produzir o mesmo resultado. A
fase de optimização tem como objectivo substituir o código BPEL por outro que seja de
execução mais rápida, ocupe menos espaço em memória e produza o mesmo resultado.
O optimizador recorre a um conjunto de heurísticas simples, de modo a não prejudicar o
desempenho global do algoritmo de conversão.
O método genérico de optimização consiste em percorrer a árvore BPEL da raiz
em direcção às folhas, substituindo actividades BPEL por outras mais eficientes. No
caso das actividades compostas, i.e. actividades que contenham outras actividades
BPEL, tais como: o BPELFlow, a BPELSequence e o BPELSwitch, as actividades
constituintes são optimizadas primeiro, seguindo-se a optimização da própria actividade
composta. As heurísticas encontram-se descritas na Tabela em baixo.
Francisco Santos 73
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
Actividades BPEL Heurísticas de Optimização
BPELEmpty H1 Caso não possua ligações de controlo (entrada ou saída): remover a actividade.
BPELWait H2 Se a expressão temporal for vazia: aplicar H1.
BPELAssign H3 Se a lista de atribuições for nula: aplicar H1.
BPELSequence H4 Para cada actividade da BPELSequence aplicar H1 até H3.
H5 Se após a aplicação de H4 a BPELSequence ficar vazia: aplicar H1; se existirem ligações de controlo: criar uma actividade BPELEmpty, adicionar as ligações de controlo da BPELSequence à actividade BPELEmpty e substituir a BPELSequence pela actividade BPELEmpty.
H6 Se após a aplicação de H4 a BPELSequence contiver uma só actividade: adicionar as ligações de controlo da BPELSequence à actividade e substituir a BPELSequence pela actividade constituinte.
BPELFlow H7 Para cada actividade concorrente aplicar H1 até H3.
H8 Se após a aplicação de H7 não restarem fluxos concorrentes: aplicar H1; se existirem ligações de controlo: criar uma actividade BPELEmpty, adicionar as ligações de controlo do BPELFlow à actividade BPELEmpty e substituir o BPELFlow pela actividade BPELEmpty.
H9 Se após a aplicação de H7 existir apenas um fluxo de execução e o BPELFlow não armazenar informação sobre as ligações de controlo entre actividades3: adicionar as ligações de controlo do BPELFlow à actividade e substituir o BPELFlow pela actividade constituinte.
3 Todas as ligações de controlo entre actividades são armazenadas num BPELFlow hierarquicamente superior; o próprio BPELFlow pode estar ligado a outra actividade BPEL, sendo esta ligação de controlo armazenada num BPELFlow hierarquicamente superior a este.
Francisco Santos 74
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
Actividades BPEL Heurísticas de Optimização
BPELSwitch H10 Para cada ramo aplicar H1 até H3.
H11 Se após a aplicação de H10 não restarem ramos: aplicar H1; se existirem ligações de controlo: criar uma actividade BPELEmpty, adicionar as ligações de controlo do BPELSwitch à actividade BPELEmpty e substituir o BPELSwitch pela actividade BPELEmpty.
H12 Se após a aplicação de H10 existir apenas um ramo com a condição ‘otherwise’: adicionar as ligações de controlo do BPELSwitch à actividade associada ao ramo e substituir o BPELSwitch pela actividade do ramo.
Tabela 4.6 – Heurísticas de Optimização do Código BPEL
O resultado da optimização da árvore BPEL da Figura 4.34 encontra-se na
Figura em baixo. As actividades: ‘Sequencia4’ e ‘Sequencia5’, contidas nos ramos do
BPELSwitch, foram substituídas pelas actividades constituintes, resultado da aplicação
de H6. O ‘Fluxo1’ apenas contém uma actividade do tipo BPELSequence. Se a ligação
de controlo entre ‘Decisao1’ e ‘Actividade6’ estiver armazenada no ‘Fluxo2’, é possível
aplicar H9, substituindo ‘Fluxo1’ por ‘Sequencia1’.
Francisco Santos 75
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
Actividade1
Actividade3
Actividade6
Actividade2
Actividade4
Actividade5
Fluxo2
cond1 cond2
Ligação de controlo
Decisao1
Seq
uenc
ia1
Seq
uenc
ia3
Actividade1
Actividade3
Actividade6
Actividade2
Actividade4
Actividade5
Fluxo2
cond1 cond2
Ligação de controlo
Decisao1
Seq
uenc
ia1
Seq
uenc
ia3
Figura 4.35 – Árvore BPEL Optimizada
Francisco Santos 76
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
5 Implementação Na primeira fase do trabalho foi desenvolvida uma biblioteca dedicada à manipulação
de grafos, para servir de base à implementação do algoritmo de conversão, descrito na
Secção 4.8.5. Os algoritmos para a travessia em largura e em profundidade foram
implementados na sua versão iterativa por questões de eficiência: espaço ocupado em
memória e tempo de execução. O algoritmo de conversão estende a classe para a
travessia em profundidade, definida na biblioteca, e reutiliza o método de classificação
de arcos do grafo.
Para o primeiro protótipo da solução foi usado um processador de expressões
XPath: designado Java XPath Engine (Jaxen), para ler o modelo UML a partir de um
ficheiro XMI 1.1. Nesta implementação adoptou-se a estratégia de seguir a sequência de
nós da árvore do documento XML para a conversão do modelo UML. Esta solução
revelou-se impraticável visto que é necessário consultar mais do que uma parte do
modelo em simultâneo durante a conversão. O primeiro protótipo serviu apenas para
testar e desenvolver as principais ideias do algoritmo de conversão baseado em grafos,
centrando-se no diagrama de actividades associado ao processo. Para converter a
totalidade do modelo tornava-se necessário usar uma representação em memória do
modelo UML do utilizador, que permitisse um acesso eficiente a todos os seus
elementos constituintes. O projecto UML2 sobre a plataforma Eclipse [Hussey05] veio
responder a esta necessidade.
Embora adequado à solução do problema, o projecto UML2 disponibiliza
documentação insuficiente sobre a sua utilização, existindo, à data da escrita deste
relatório, poucos artigos publicados sobre o assunto: [Hussey05], [Hussey05b] e
[Misic05]. O projecto Eclipse UML2 representa uma implementação do meta-modelo
UML2 e é baseado no projecto Eclipse Modelling Framework (EMF), através do qual
tem capacidade para fazer importação e exportação dos modelos para XMI 2.0. A
utilização do meta-modelo UML versão 2 obrigou à conversão do perfil de modelação
de negócio, descrito neste documento, que estava inicialmente adaptado à versão 1.5 do
meta-modelo. Os diagramas de actividades sofreram várias modificações ao longo das
versões da UML. Por este motivo, não é surpreendente que na versão 2 da UML o
Francisco Santos 77
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
diagrama de actividades tenha sido significativamente estendido e alterado [Fowler04].
Na UML2 os diagramas de actividades deixaram de ser uma especialização dos
diagramas de estados. Na UML1 existiam regras para o balanceamento dos nós de
difusão e de junção, que deixaram de existir na nova versão. Os nós do diagrama de
actividades são agora designados por: “acções”, sendo que uma “actividade” se refere a
uma sequência de acções e o diagrama de actividades mostra uma actividade, composta
por várias acções. Os nós de decisão, designados por “ramos” na UML1, possuem um
único fluxo de entrada e vários fluxos de saída. Cada fluxo de saída possui uma
“condição de transição”, representada por uma expressão booleana, colocada entre
parênteses rectos. A partir de um nó de decisão apenas um fluxo de saída pode ser
escolhido, sendo por isso necessário que as condições de transição sejam mutuamente
exclusivas. O nó de fusão, ao contrário do nó de decisão, possui múltiplos fluxos de
entrada e apenas um de saída. Este nó é usado para assinalar o final de um nó de
decisão. Finalmente, na UML1 múltiplos fluxos de entrada significavam uma fusão
implícita dos fluxos, sendo apenas necessário que um fluxo estivesse activo para que a
acção se executasse. Na nova versão, este comportamento foi modificado de forma a
existir uma junção (sincronização) implícita dos fluxos de entrada de uma acção. Este
aspecto em particular já tinha sido contemplado no perfil descrito em [AGGI03], pelo
que não foi necessário modificar o comportamento descrito na Secção 2.1.2. No
Apêndice D – Conversão para o Perfil versão UML 2.0 – encontra-se uma descrição das
modificações necessárias ao perfil para poder ser usado na versão 2 da linguagem UML.
O algoritmo de conversão encontra-se implementado sobre a forma de um
componente para a plataforma Eclipse. A principal vantagem desta plataforma é a
possibilidade de desenvolver aplicações num curto espaço de tempo, estendendo e
reutilizando outros componentes existentes na plataforma, nomeadamente os
componentes: UML2 e EMF. Adicionalmente, devido ao crescente interesse das
empresas da área informática nesta plataforma de desenvolvimento, e no componente
UML2 em particular, favorece a longevidade da solução proposta. A conversão e
optimização das expressões XPath, contidas no próprio modelo UML, ficam a cargo do
processador Jaxen, usando as regras de conversão descritas na Secções: 4.8.1, 4.8.2 e
4.8.3.
Francisco Santos 78
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
O perfil descrito neste relatório foi definido sob a forma de um ficheiro UML2,
tal como descrito em [Hussey05b] e [Misic05], e estende os elementos do meta-modelo
UML2 da plataforma através de um conjunto de estereótipos. Sempre que se pretenda
construir um modelo de negócio que seja convertível para a linguagem BPEL, torna-se
necessário importar o perfil a partir do modelo UML. Uma vez que o ficheiro do perfil
está contido no componente Eclipse desenvolvido, a importação deve ser feita através
de um Universal Resource Identifier (URI), o que permite abstrair da sua localização
física. Assim, sempre que se queira usar este perfil deve ser usado o seguinte URI a
partir da plataforma Eclipse:
pathmap://UML2BPEL_PROFILES/UML2BPEL.profile.uml2
O componente de conversão é invocado através da interface gráfica da
plataforma, sempre que se carregue com o botão direito do rato sobre um ficheiro
UML2 na área de trabalho do utilizador, conforme ilustrado na Figura 5.1. Os eventuais
erros de conversão são apresentados através do visualizador de eventos da própria
plataforma, conforme ilustrado na Figura 5.2. Os ficheiros resultantes da conversão são
colocados na área de trabalho do utilizador, usando a estrutura de directórios definida na
Secção 4.3. Actualmente, o algoritmo de conversão gera os ficheiros BPEL a partir da
especificação do processo, não sendo ainda gerados os ficheiros WSDL correspondentes
aos protocolos, nem os ficheiros XSD e WSDL correspondentes aos tipos de dados e
mensagens.
Francisco Santos 79
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
Figura 5.1 – Interface Gráfica do Conversor
Figura 5.2 – Visualizador de Eventos da Plataforma Eclipse
Francisco Santos 80
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
6 Conclusão A Framework CEO (FCEO) é um perfil UML (extensão do UML base) que permite
definir o modelo de negócio de uma organização. Os modelos FCEO não são à partida
executáveis, uma vez que possuem apenas uma descrição estática da estrutura e
dinâmica do processo. Usando uma descrição normalizada da dinâmica do processo
torna possível a conversão automática dos modelos estáticos em modelos executáveis,
permitindo simular o funcionamento real dos processos. Foi escolhida a linguagem
Business Process Execution Language for Web Services (BPEL4WS) para definir a
versão executável dos processos de negócio. A BPEL4WS define um modelo e uma
gramática para descrever o comportamento de um processo de negócio baseado nas
interacções entre o processo e os parceiros de negócio envolvidos.
Recorre-se a um exemplo simples de um processo de recepção de encomendas
para melhor compreender a metodologia de modelação sugerida pela FCEO, sendo
introduzidos os principais diagramas usados para descrever a estrutura e funcionamento
do processo. Este exemplo é também usado para apresentar as principais estruturas e
conceitos da linguagem BPEL4WS. De forma a tornar possível a conversão dos
modelos FCEO em modelos BPEL4WS executáveis é necessário estender o perfil
UML, definido na FCEO. Neste relatório são descritas as extensões necessárias à
framework de forma a tornar possível a conversão automática dos processos de negócio
descritos em UML. A partir da definição do perfil de modelação do negócio é detalhado
todo o processo de conversão dos modelos UML para a linguagem BPEL4WS, sendo
especificado o algoritmo usado durante a conversão. Actualmente, o algoritmo
implementado permite gerar os ficheiros BPEL a partir da especificação do processo,
não sendo ainda gerados os ficheiros WSDL correspondentes aos protocolos, nem os
ficheiros XSD e WSDL correspondentes aos tipos de dados e mensagens.
Francisco Santos 81
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
Apêndice A – Ficheiro WSDL Protocolo Encomendar <?xml version="1.0"?>
<definitions name="Encomendar”
targetNamespace="http://www.example.org/ProcessamentoEncomendas/Encomendar"
xmlns:tns="http://www.example.org/ProcessamentoEncomendas/Encomendar"
xmlns:plnk="http://schemas.xmlsoap.org/ws/2003/05/partner-link/"
xmlns:def="http://www.example.org/ProcessamentoEncomendas/DefinicoesEncomenda/Definicoes
Encomenda"
xmlns:bpws="http://schemas.xmlsoap.org/ws/2003/03/business-process/"
xmlns="http://schemas.xmlsoap.org/wsdl/"
>
<import
namespace="http://www.example.org/ProcessamentoEncomendas/DefinicoesEncomenda/Definicoes
Encomenda" location="DefinicoesEncomenda.wsdl"/>
<!-- ================================================================= -->
<!-- Definição dos tipos de portos: agrupam um conjunto de operações -->
<!-- numa unidade lógica. -->
<!-- ================================================================= -->
<portType name="IServicoEncomenda">
<operation name="enviarPedidoEncomenda">
<input message="def:Encomenda" />
<output message="def:Factura"/>
<fault name="impossivelFinalizarEncomenda" message="def:EncomendaFault"/>
</operation>
</portType>
<!-- ================================================================= -->
<!-- Definição das ligações aos parceiros de negócio e dos papéis -->
<!-- ================================================================= -->
<plnk:partnerLinkType name="Encomendar">
<plnk:role name="ServicoEncomenda">
<plnk:portType name="tns:IServicoEncomenda"/>
</plnk:role>
</plnk:partnerLinkType>
</definitions>
Francisco Santos 82
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
Apêndice B – Ficheiro BPEL ProcessoReceberEcomenda <process name="ProcessoReceberEncomenda" suppressJoinFailure="yes"
targetNamespace="http://www.example.org/ProcessamentoEncomendas/ReceberEncomenda/
ProcessoReceberEncomenda"
xmlns="http://schemas.xmlsoap.org/ws/2003/03/business-process/"
xmlns:tns="http://www.example.org/ProcessamentoEncomendas/ReceberEncomenda/Proces
soReceberEncomenda"
xmlns:fabricar="http://www.example.org/ProcessamentoEncomendas/Fabricar"
xmlns:bpws="http://schemas.xmlsoap.org/ws/2003/03/business-process/"
xmlns:enviar="http://www.example.org/ProcessamentoEncomendas/Enviar"
xmlns:encomendar="http://www.example.org/ProcessamentoEncomendas/Encomendar"
xmlns:def="http://www.example.org/ProcessamentoEncomendas/DefinicoesEncomenda"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:bpelx="http://schemas.oracle.com/bpel/extension"
xmlns:ora="http://schemas.oracle.com/xpath/extension"
xmlns:facturar="http://www.example.org/ProcessamentoEncomendas/Facturar">
<!-- ================================================================= -->
<!-- PARTNERLINKS -->
<!-- Lista de parceiros de negócio associados ao processo -->
<!-- ================================================================= -->
<partnerLinks>
<!-- The 'client' role represents the requester of this service. -->
<partnerLink name="encomendar" partnerLinkType="encomendar:Encomendar"
myRole="ServicoEncomenda"/>
<partnerLink name="enviar" partnerLinkType="enviar:Enviar"
myRole="ClienteDistribuicao" partnerRole="ServicoDistribuicao"/>
<partnerLink name="facturar" partnerLinkType="facturar:Facturar"
partnerRole="ServicoFacturacao" myRole="ClienteFacturacao"/>
<partnerLink name="fabricar" partnerLinkType="fabricar:Fabricar"
partnerRole="ServicoProducao"/>
</partnerLinks>
<!-- ================================================================= -->
<!-- VARIABLES -->
<!-- Lista das mensagens e documentos XML usados pelo processo -->
<!-- ================================================================= -->
<variables>
<variable name="encomenda" messageType="def:Encomenda"/>
<variable name="pedidoEntrega" messageType="def:PedidoEntrega"/>
<variable name="informacaoEntrega" messageType="def:InformacaoEntrega"/>
<variable name="prazoEntrega" messageType="def:PrazoEntrega"/>
<variable name="factura" messageType="def:Factura"/>
</variables>
<!-- ================================================================= -->
Francisco Santos 83
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
<!-- CORRELATION SETS -->
<!-- Lista dos conjuntos de correlação -->
<!-- ================================================================= -->
<correlationSets>
<correlationSet name="Encomenda" properties="def:encomendaID"/>
<correlationSet name="PrazoEntrega" properties="def:encomendaID"/>
</correlationSets>
<!-- ================================================================= -->
<!-- ORCHESTRATION LOGIC -->
<!-- Conjunto de actividades que coordenam o fluxo das mensagens entre -->
<!-- o processo e os parceiros de negócio -->
<!-- ================================================================= -->
<sequence name="main">
<receive createInstance="yes" name="receberEncomenda"
partnerLink="encomendar" portType="encomendar:IServicoEncomenda"
operation="enviarPedidoEncomenda" variable="encomenda"/>
<flow name="flow-1">
<links>
<link name="pedirEntrega-to-enviarPrecoEntrega"/>
<link name="receberPrazoEntrega-to-enviarPrazoEntrega"/>
</links>
<sequence name="flow-sequence-distribuicao">
<assign name="inicializarPedidoEntrega">
<copy>
<from variable="encomenda" part="eid"/>
<to variable="pedidoEntrega" part="eid"/>
</copy>
<copy>
<from variable="encomenda" part="cliente"/>
<to variable="pedidoEntrega" part="cliente"/>
</copy>
</assign>
<invoke name="pedirEntrega" partnerLink="enviar"
portType="enviar:IServicoDistribuicao" operation="pedirEntrega"
inputVariable="pedidoEntrega" outputVariable="informacaoEntrega">
<source linkName="pedirEntrega-to-enviarPrecoEntrega"/>
</invoke>
<receive createInstance="no" name="receberPrazoEntrega"
partnerLink="enviar" portType="enviar:ICallbackDistribuicao"
operation="enviarPrazoEntrega" variable="prazoEntrega">
<source linkName="receberPrazoEntrega-to-enviarPrazoEntrega"/>
</receive>
</sequence>
<sequence name="flow-sequence-facturacao">
<invoke name="calcularPreco" partnerLink="facturar"
portType="facturar:IServicoFacturacao"
operation="iniciarCalculoPreco" inputVariable="encomenda"/>
Francisco Santos 84
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
<invoke name="enviarPrecoEntrega" partnerLink="facturar"
portType="facturar:IServicoFacturacao"
operation="enviarPrecoEntrega" inputVariable="informacaoEntrega">
<target linkName="pedirEntrega-to-enviarPrecoEntrega"/>
</invoke>
<receive createInstance="no" name="receberFactura"
partnerLink="facturar" portType="facturar:ICallbackFacturacao"
operation="enviarFactura" variable="factura"/>
</sequence>
<sequence name="flow-sequence-producao">
<invoke name="pedirEscalonamentoProducao" partnerLink="fabricar"
portType="fabricar:IServicoProducao"
operation="pedirEscalonamentoProducao" inputVariable="encomenda">
<correlations>
<correlation set="Encomenda" initiate="yes" pattern="out"/>
</correlations>
</invoke>
<invoke name="enviarPrazoEntrega" partnerLink="fabricar"
portType="fabricar:IServicoProducao"
operation="enviarPrazoEntrega" inputVariable="prazoEntrega">
<target linkName="receberPrazoEntrega-to-enviarPrazoEntrega"/>
<correlations>
<correlation set="PrazoEntrega" initiate="yes" pattern="out"/>
</correlations>
</invoke>
</sequence>
</flow>
<reply name="enviarFactura" partnerLink="encomendar"
portType="encomendar:IServicoEncomenda"
operation="enviarPedidoEncomenda" variable="factura"/>
</sequence>
</process>
Francisco Santos 85
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
Apêndice C – Conversão de Tipos Básicos da UML para o Formato XSD Tipo Elementar UML Tipo Simples XSD
Boolean boolean
Byte byte
Currency decimal
Date dateTime
Double double
Float float
Integer int
Long long
Single float
String string
Francisco Santos 86
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
Apêndice D – Conversão para o Perfil versão UML 2.0
Perfil versão UML 1.5 Perfil versão UML 2.0 Descrição
receber<<receive>>
entry/ correlation: initialize correlacao1entry/ operacao1( atrib1 )
Na UML 2, a acção <<receive>> é modelada como uma CallOperation action e referencia directamente a operação da interface do protocolo; o nome da acção é sempre igual ao nome da operação; é usado um output pin para modelar a mensagem recebida: ‘atrib1’; os conjuntos de correlação a usar são descritos através de uma restrição associada à acção.
invocar
entry/ correlation: initialize correlacao2entry/ atrib2 := operacao2( atrib1 )
<<invoke>>
Na UML 2, a acção <<invoke>> é modelada como uma CallOperation action e referencia directamente a operação da interface do protocolo; o nome da acção é sempre igual ao nome da operação invocada; todas as invocações incluem um input pin, correspondente ao parâmetro de entrada da operação, e no caso da invocação síncrona é também incluído um output pin, correspondente ao parâmetro de retorno da operação.
responder<<reply>>
entry/ correlation: correlacao1entry/ operacao1() := atrib2
Na UML 2, a acção <<reply>> é modelada como uma CallOperation action e referencia directamente a operação da interface do protocolo; o nome da acção é sempre igual ao nome da operação; todas as actividades de resposta incluem um input pin correspondente ao parâmetro de retorno da operação.
atribuicao<<assign>>
entry/ msg2/secB := msg1/secA
Na UML 2, as expressões de atribuição da acção <<assign>> são modeladas através de restrições.
Francisco Santos 87
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
Perfil versão UML 1.5 Perfil versão UML 2.0 Descrição
esperar24H
entry/ for 'P1DT'
<<wait>>
Na UML 2, as expressões temporais da acção <<wait>> são modeladas através de restrições.
Actividade1<<receive>>
Actividade2<<assign>>
[ cond1 ]
Actividade4<<invoke>>
Actividade3<<invoke>>
[ cond2 ]
Actividade6<<reply>>
Actividade5<<wait>>
Na UML 2, o fluxo entre actividades deve ser modelado através do fluxo de controlo e não do fluxo de objectos.
Francisco Santos 88
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
Referências
[ACDG+03] – T. Andrews, F. Curbera, H. Dholakia, Y. Goland et. al, “Business Process Execution Language for Web Services”, 2003
[AGGI03] – J. Amsden, T. Gardner, C. Griffin, S. Iyengar, “Draft UML 1.4 Profile for Automated Business Processes with a mapping to BPEL 1.0”, 2003
[BEKM05] – F. Beshears, J. Evdemon, R. Kleinman, S. Mohler, “IMS General Web Services UML to WSDL Binding Auto-generation Guidelines”, IMS Global Learning Consortium, Inc., 2005
[CCMW01] – E. Christensen, F. Curbera, G. Meredith, S. Weerawarana, “Web Services Description Language (WSDL) 1.1”, www.w3.org/TR/wsdl, W3C, 2001
[CLRS01] – T. Cormen, C. Leiserson, R. Rivest, C. Stein, “Introduction to Algorithms”, McGraw-Hill, 2001
[CR99] – J. Clark, S. DeRose, “XML Path Language (XPath)”, www.w3.org/TR/xpath, W3C, 1999
[FW04] – D. Fallside, P. Walmsley, “XML Schema Part 0: Primer Second Edition”, www.w3.org/TR/xmlschema-0/, W3C, 2004
[BM04] – P. Biron, A. Malhotra, “XML Schema Part 2: Datatypes Second Edition”, www.w3.org/TR/xmlschema-2/, W3C, 2004
[EP00] – H. Eriksson, M. Penker, “Business Modeling with UML”, John Wiley & Sons, Inc., 2000
[Fowler04] – Martin Fowler, “UML Distilled Third Edition: A Brief Guide to the Standard Object Modeling Language”, Addison-Wesley, 2004
Francisco Santos 89
Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS
[Hussey05] – Kenn Hussey, “Getting Started with UML2”, dev.eclipse.org/viewcvs/indextools.cgi/~checkout~/uml2-home/docs/articles/Getting_Started_with_UML2/article.html, IBM, 2005
[Hussey05b] – Kenn Hussey, “Introduction to UML2 Profiles”, dev.eclipse.org/viewcvs/indextools.cgi/~checkout~/uml2-home/docs/articles/Introduction_to_UML2_Profiles/article.html, IBM, 2005
[Misic05] – Dusko Misic, “Authoring UML profiles using Rational Software Architect and Rational Software Modeler”, www-128.ibm.com/developerworks/rational/library/05/0906_dusko/ , IBM, 2005
[OMG03] – “Unified Modeling Language Specification”, OMG, version 1.5, 2003
[Sinogas02] – Pedro Sinogas, “Modelação de processos de negócio”, 2002
[VCSMT04] – A. Vasconcelos, A. Caetano, P. Sinogas, R. Mendes, J. Tribolet, Arquitectura de Sistemas de Informação: A Ferramenta de Alinhamento Negócio / Sistemas de Informação?, 2004
Francisco Santos 90