Exemplo de Funcionamento

Esta seção apresenta um exemplo de funcionamento do protótipo computacional implementado, mostrando um passo a passo resumido do sistema.

O fluxo de trabalho começa com o usuário-projetista iniciando a ferramenta de edição de processos, o IBM Websphere Business Modeler. Em seguida, o usuário escolhe a opção de importar um processo do catálogo de processos de negócio para o editor BPM. A Figura 57 apresenta a tela de importação do processo.

Figura 57 – Importação de Processo do Catálogo

O plug-in se conecta ao catálogo e lista todos os processos que estão disponíveis. O projetista escolhe um deles e solicita a importação, como pode ser visto na Figura 58. As duas abas presentes no canto superior da figura permitem escolher entre a importação de um processo da especificação (Processes from Standard Specifications) ou processos previamente armazenados no catálogo (User stored process). Neste exemplo considera-se que o usuário está importando um processo da especificação UBL.

Figura 58 – Processo importado para o editor

Após a importação ser realizada, o processo modelado em BPMN é apresentado na tela. O processo importado é fiel à especificação UBL, contendo todas as atividades e estruturas de fluxo descritas na especificação. As classificações ontológicas do processo e das atividades que o compõe já vêm pré-atribuídas no momento da importação. Assim, o usuário-projetista já tem um processo padronizado que pode ser usado como base para a concepção de suas aplicações SOA.

A fim de poder encontrar serviços adequados para serem vinculados ao seu processo, o projetista define as restrições de qualidade de serviço a cada uma das atividades do processo. Selecionando a atividade, a aba “QoS Constraints” fica disponível. Através do botão “Add QoS Constraint” pode-se adicionar um critério de QoS, conforme apresentado na Figura 59.

Figura 59 – Tela de Atribuição de QoS

Após selecionar a opção “Add QoS Constraint”, uma tela contendo a lista de critérios de QoS disponíveis é apresentada (Figura 60).

Essa lista de critérios de QoS é a mesma apresentada na Tabela 9 da seção 3.4.6. Ela é dividida em itens, cada um deles podendo ter um ou mais atributos. Por exemplo, o item Performace tem os atributos

ResponseTime, TransactionTime, Latency, Throughput e

ExecutionTime. O usuário escolhe um desses itens e define qual valor o

mesmo deve ter, como pode ser visto na Figura 61. Além do valor, o usuário também pode definir qual a comparação que deve ser feita em relação a esse, por exemplo, menor, maior, menor ou igual, maior ou igual ou igual. O tipo de comparação depende do item de QoS escolhido. Podem haver casos em que valores menores sejam melhores, como, por exemplo, o tempo de resposta, latência etc. Por outro lado, pode-se desejar valores maiores como por exemplo no item robustez ou disponibilidade.

Figura 61 – Definindo o valor do atributo QoS

Depois de ter-se escolhido as restrições de qualidade de serviço, o próximo passo é selecionar a aba “Service Association”, que permite fazer a busca e a vinculação dos serviços às atividades do processo.

Figura 62 – Tela de Associação de Serviços

O usuário seleciona a opção “Discover Service” (Figura 62), que irá invocar o mecanismo de busca, que utiliza como parâmetros a classificação ontológica da tarefa e a lista de critérios de QoS. O retorno

da operação é um conjunto de serviços, divididos entre os que atendem totalmente os critérios de QoS e os que atendem parcialmente. Com base nesse o resultado, o projetista pode decidir se as restrições de qualidade de serviço escolhidas são adequadas. Caso nenhum serviço tenha atendido-as totalmente a essas restrições, a vinculação não será feita. Nesse caso ele tem a opção de relaxar os critérios de QoS a fim de encontrar algum serviço ou correr o risco e tentar fazer essa descoberta em tempo de execução, quando o processo já estiver no Ambiente de Execução.

O procedimento de definição de QoS e associação de serviços deve ser feito para cada atividade do processo. Comumente, o mesmo conjunto de restrições de qualidade de serviço aplica-se a todas as atividades do processo. Pensando nisso, o plug-in de integração possui uma opção que permite definir de uma só vez um conjunto de critérios de QoS a todas as atividades do processo e também fazer a busca de serviços. Dessa forma, poupa-se tempo do usuário-projetista.

A Figura 63 apresenta essa funcionalidade. A lista das tarefas do processo é mostrada, juntamente com o a classificação ontológica de cada uma delas, o número de restrições de QoS de cada uma e a quantidade de serviços que possuem o matching total e parcial.

Figura 63 – Descoberta de Serviços para Todas as Atividades

Depois de ter o processo com todos os serviços vinculados e com as restrições do QoS definidas, o usuário-projetista irá exportá-lo para a linguagem de execução BPEL.

Figura 64 – Exportação BPEL

A Figura 64 apresenta a tela de exportação BPEL. O usuário escolhe qual processo deseja exportar e para qual pasta os arquivos serão gravados. Essa pasta é então copiada para o Ambiente de Execução de Processos, onde o processo ficará disponível para ser executado. Nesse sentido, nota-se que a exportação do processo é totalmente transparente ao usuário, pois o processo exportado já está pronto para ser executado. Não há necessidade de conhecimento técnico por parte do usuário-projetista para se fazer esse procedimento. O uso de padrões, como por exemplo, a especificação UBL, permite que a ligação entre o processo descrito num nível mais abstrato, em BPMN, e a implementação concreta do mesmo, em BPEL, seja feita de maneira automatizada. A classificação ontológica precisa do processo permite que a ligação com os serviços, presentes na federação e encontrados através do ambiente de descoberta dinâmica de serviços, ocorra de maneira natural.

Nesse sentido, a abordagem mostrada no exemplo é mais ágil do que as soluções tradicionais, onde por exemplo é necessário uma equipe técnica para se implementar ou vincular manualmente os serviços junto ao processo ou mesmo para se traduzir o processo em BPMN para BPEL.

Após o processo ter sido exportado , o mesmo fica disponível para execução. Nota-se na Figura 65 o processo “Payment Process”, pronto para se executado. O Usuário-Executor de Aplicações irá ter

acesso a interface do ambiente de execução e, através dela, solicitar a execução do processo. O motor de execução Apache ODE é então acionado, começando a fazer a orquestração dos serviços. Nesse momento, cada um dos serviços que foram previamente vinculados pelo usuário-projetista, na fase de concepção do processo, é invocado.

Figura 65 – Ambiente de Execução – Intalio BPMS

Na seção 4.2.3 foi apresentado o mecanismo utilizado para se simular a interação humana, no momento da execução do processo. Portanto, cada serviço no momento da invocação, apresenta uma mensagem de confirmação, que faz o serviço responder ao processo que o invocou. A Figura 66 apresenta um exemplo dessa mensagem de confirmação. No momento em que o usuário seleciona a opção “OK”, a resposta do serviço é retornada ao processo.

Depois de todos os serviços envolvidos no processo retornarem a resposta, o processo é finalizado. Através da interface administrativa do Intalio BPMS (Figura 65), pode-se ver quais instâncias do processo foram executadas com sucesso, em quais ocorreram erros etc. A partir desse ponto, o exemplo de funcionamento da arquitetura conceitual proposta é finalizado.

Com base no exemplo apresentado, pode-se ter uma noção dos módulos da arquitetura funcionando conjuntamente, com o intuito de agilizar a integração de BPM com SOA desde o momento em que processo é importado e ajustado pelo usuário-projetista, passando pela sua exportação em BPEL, até quando o mesmo é executado no ambiente de execução de processos.

4.5 Considerações

O objetivo desse capítulo foi apresentar o protótipo computacional, que foi implementado para por em prática as funcionalidades do modelo proposto.

Um dos destaques é o uso intensivo de padrões, tais como web-

services, BPMN, BPEL, UDDI, SCA etc. O seu uso permite

desenvolver aplicações interoperáveis, utilizando as melhores práticas estabelecidas pelo uso desses padrões.

A implementação do plug-in de integração com o editor BPM mostrou que é possível tornar transparente para o usuário o uso do catálogo de processos de negócio.

Em respeito ao catálogo, a sua implementação em módulos permitiu separar eficientemente às responsabilidades de cada um deles. A tecnologia SCA permite modelá-los como componentes, de forma que a questão de comunicação entre eles fica abstraída, ficando ao encargo do middleware, no caso o Apache Tuscany.

O Ambiente de Execução de Processos foi desenvolvido utilizando ferramentas de mercado e consolidadas, como o Intalio BPMS e o Apache ODE. Isso permitiu verificar a execução dos processos e a eficácia da conversão do processo para BPEL num ambiente realista, passível de ser usado em produção. As implementações dos serviços UBL permitiram testar o mecanismo de invocação e orquestração utilizado pelo ambiente de execução.

O exemplo de funcionamento serviu como uma demonstração sucinta das funcionalidades da arquitetura proposta, abrangendo desde a

fase de concepção da aplicação (onde o usuário-projetista utiliza o ambiente pra facilitar a modelagem do seu processo) até a fase de execução (onde o processo com os serviços já vinculados é executado).

Por último, pode-se concluir que o protótipo desenvolvido serviu como base para avaliação do modelo, que será detalhada no próximo capítulo.

Capítulo 5

5 Verificação, Avaliação e Análise