• Nenhum resultado encontrado

Conversão das Propriedades e Conjuntos de Correlação

4 Conversão entre FCEO e BPELWS

4.5 Conversão das Propriedades e Conjuntos de Correlação

<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

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

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’.

ConjuntoPropriedades propriedade1 : String

propriedade2 : Integer

propriedade1(msg1 : TipoMensagem1) : String propriedade1(msg2 : TipoMensagem2) : String propriedade2(msg2 : TipoMensagem2) : Integer propriedade2(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.

ConjuntoCorrelacao1 propriedade1 : String propriedade2 : 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

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

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.

<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

Documentos relacionados