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:
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
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
Í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.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
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.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
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
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
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.
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).
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].
‘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’.
receberEncomenda env iarFactura inicializarPedidoEntrega pedirEntrega receberPrazoEntrega env iarPrecoEntrega receberFactura calcularPreco pedirEscalonamentoProducao env iarPrazoEntrega Fabricar Facturar Enviar Encomendar
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
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’.
Actividade 1 Actividade 2 Activitdade 3 Actividade 1 Actividade 2 Actividade 3 Actividade 1 Actividade 2 Actividade 3 Actividade 4 Actividade 5 Actividade 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.
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
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 é
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.
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.
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’.
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ção Dep. Comercial Cliente
Cliente Dep. Comercial Dep. Produção
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.
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 S e q uen ci a1 S e q uen ci a2 S e q uen ci a3 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 S e q uen ci a1 S e q uen ci a2 S e q uen ci a3 Ligação de controlo
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
(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.
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.
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
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’.
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.
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.
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>> Fabricar Facturar Enviar Encomendar
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.
Cliente nome : String morada : String <<data>> PedidoEntrega <<messageContent>> +cliente EncomendaFault descricaoProblema : String <<messageContent>> Factura eid : String input : String <<messageContent>> InformacaoEntrega eid : String input : String <<messageContent>> PrazoEntrega eid : String input : String <<messageContent>> Encomenda eid : String <<messageContent>> +cliente Linha nomeProduto : String quantidade : Integer precoUnitario : Float <<data>> LinhaEncomenda <<data>> +linhaEncomenda 1..n 1..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.
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.
ServicoEncomenda
(from Encom endar)
<<role>> ClienteFacturacao (from Facturar) <<role>> ClienteProducao (from Fabricar) <<role>> ClienteDistribuicao (from Enviar) <<role>> ProcessoReceberEncomenda encomenda : Encomenda factura : Factura encomendaFault : EncomendaFault prazoEntrega : PrazoEntrega informacaoEntrega : InformacaoEntrega pedidoEntrega : 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
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...
Fabricar Facturar
Enviar Encomendar
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
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.
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.
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
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’.
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
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
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.
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> ClasseA attribA : String attribB : Boolean attribC : Integer <<data>> ClasseA <<data>> ClasseB <<data>> 1..n 0..1 0..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>
Modelo UML Conversão para XSD ClasseA <<data>> ClasseB <<data>> 1..n 0..1 0..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” /> ClasseA attribA : String <<data>> ClasseB attribB : 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
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.
Cliente nome : String morada : String <<data>> Encomenda eid : String <<messageContent>> +cliente Linha nomeProduto : String quantidade : Integer precoUnitario : Float <<data>> LinhaEncomenda <<data>> +linhaEncomenda 1..n 1..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> …
