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/cliente entry/ factura/data := getDataHora()

Figura 4.21 – Exemplo de uma Actividade de Atribuição

<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:

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:

invocar1 <<invoke>>

entry/ operacao1( atrib1 )

invocar2 <<invoke>>

entry/ atrib3 := operacao2( atrib2 )

ligacaoParceiro2 ligacaoParceiro1

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

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 )

ligacaoParceiro2 ligacaoParceiro1

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:

<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 actividade¹. 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:

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.