Arquitetura Orientada a Serviços

Arquitetura Orientada a Serviços: Aspectos de Modelagem de Negócios

A abordagem voltada a serviços propõe uma solução mais próxima dos processos de negócio, uma vez que se tem um fluxo de execução montado a partir de peças ou unidades bem definidas que executam determinada funcionalidade. Sendo assim, uma unidade demanda, como pré-requisito, informações na entrada e, necessariamente, criará algo modificado como resultado do sucesso de sua execução.

SOA propõe que se faça a modelagem de um processo, não mais como um monobloco, mas sim por um conjunto ordenado de unidades bem definidas, cada qual com sua funcionalidade convenientemente descrita, de modo que, ao final da execução de todas as unidades, teremos o resultado esperado. Esse conjunto ordenado de unidades recebe o nome de workflow (fluxo de trabalho) e cada unidade recebe o nome de serviço.

Mais que uma simples proposta de modelagem ou resolução de problemas computacionais, SOA é uma arquitetura de TI e, como tal, define cada componente como um serviço gerenciável, sendo que cada serviço deve possuir um ciclo de vida próprio, os quais, também, devem possuir aspectos funcionais e de qualidade mensuráveis.

Podemos notar que uma arquitetura SOA é mais que um sistema, pois envolve uma abordagem e dita o modo como um sistema de informação será modelado. O importante é saber que podemos montar soluções baseadas em serviços e workflow com tecnologias bastante variadas, desde que sejam respeitados os aspectos arquiteturais de serviços e os processos de negócio.

A arquitetura orientada a serviços trata-se de um modelo, em que as funcionalidades ou serviços são totalmente desacoplados e independentes, buscando atender às mais diversas tarefas e, ainda, podem ser reutilizados nos mais diferentes tipos de domínios de negócios demandados pelo mercado coorporativo.

Esses mesmos serviços são publicáveis, de tal forma que possam ter suas interfaces acessíveis por meio de mecanismos de localização e, também, são descritos por meio de uma linguagem totalmente independente da plataforma utilizada.

Já no ponto de vista do negócio, SOA se apresenta como uma solução de maior flexibilidade, permitindo que as mais diversas demandas do mercado sejam absorvidas e atendidas pela empresa com agilidade e eficiência.

Questões que envolvem aspectos como segurança, benefícios e recomendações sobre implantação, dentre outros, não serão abordados neste artigo. Pretendemos, portanto, mostrar os aspectos de modelagem de processos na arquitetura SOA voltados para Web Services, conceitos, ferramentas e exemplos de modelagem que possam contribuir com os diversos profissionais de TI na tomada de decisão de se adotar a arquitetura SOA em detrimento às demais existentes no mercado.

Modelagem de Processos na Arquitetura SOA

As tecnologias descritas a seguir, não somente buscam uma aproximação de modo a permitir que haja uma maior comunicação entre as áreas de negócio e TI, mas também de forma que partes de um sistema possam ser criadas ou gerenciadas fora do ambiente de TI pelos próprios profissionais de negócio, tornando esta relação de proximidade cada vez mais estreita.

BPM (Business Process Management)

BPM pode ser definido como uma disciplina de gerência focada na melhora do desempenho corporativo através da gestão dos processos de negócio da empresa. BPM é a forma de se atingir os objetivos de uma organização através do aperfeiçoamento, gestão e controle dos processos essenciais do negócio (PEREIRA, 2007).

Os grandes institutos de pesquisa estão validando essa visão. O Gartner aponta projetos de BPM como os de maior ROI (Return On Investiment) em TI, e o Forrester Research anunciou um novo acrônimo, IC-BPMS (Integration Centric BPMS), como um novo modelo de desenvolvimento de aplicações.

BPMS (Business Process Management Suite)

BPMS é um sistema que automatiza a gestão por processos (execução, controle e monitoração). Tipicamente, inclui o mapeamento dos processos ponta a ponta, desenho dos fluxos e formulários eletrônicos, definição de workflow, regras de negócio, integradores, monitoração em tempo real das atividades e alertas. É uma poderosa ferramenta de gestão, para garantir que os processos estão sendo efetivamente executados como modelados, contribuindo para os objetivos da organização.

Ilustramos na Figura 1 os elementos que compõem um sistema BPMS, de acordo com Glauco Reis (2007).

A figura em forma de um pentágono ilustra em seus cinco vértices, os principais componentes de um sistema BPMS, como o BPMN, ferramenta responsável pelo desenho dos processos de negócio; o BPEL4WS que se destina a orquestração destes serviços, de forma a organizá-los melhor; a arquitetura SOA, que busca de forma padronizada a componentização dos serviços; o DashBoard, ou seja, o monitoramento em tempo real dos seus processos; e, finalmente, o BPMN + SOA, que permite o realinhamento de todos os processos.

Um BPMS Completo

Para que tenhamos um ambiente de processos de negócio que englobe uma solução BPMS, torna-se necessário a observância de alguns pontos de suma importância, tais como mencionados a seguir. Um BPMS completo teria os seguintes módulos ou funcionalidades para ser classificado como tal (Ghalimi, 2006):

• Funcionalidades mínimas
• Ferramenta de modelagem e desenho do processo;
• Engenho de execução do processo;
• Orquestração de web services;
• Interface de workflow para usuários.
• Funcionalidades intermediárias
• Suporte para regras de negócio complexas;
• Business Activity Monitoring (BAM);
• Controle de versão dos documentos anexados a instâncias do processo.
• Funcionalidades completas
• Enterprise Service Bus (ESB);
• Repositório de metadados;
• Uma suite de business intelligence.

BPMN (Business Process Modeling Notation)

O BPMN é uma tecnologia gráfica para construção de modelos destinados a representar os processos de negócio da empresa, que serão abordados e exemplificados a seguir.

Enquanto o BPEL é um formato binário para execução de serviços em seqüência, o BPMN é a notação gráfica que permite representar como os serviços irão interagir.

O BPMN define os símbolos e como estes devem ser conectados para gerar modelos representativos. Por outro lado, ele não define formatos de arquivos nem mesmo características particulares de ambientes de execução. Trata-se de uma notação visual para representação de fluxos de processos que pode ser mapeada para diversos formatos de execução, como BPML e BPEL. Em uma analogia com a orientação a objetos, o BPMN seria como a UML (Unified Modeling Language), que define elementos gráficos para representar objetos e classes, como também sua interação. Da mesma forma que a UML, o BPMN não define formatos de armazenamento nem elementos programáticos relacionados à implementação, como por exemplo, as rotinas. Por outro lado, a especificação é completa o suficiente para permitir a representação de fluxos de processo pelas áreas de negócio, com detalhamento bem próximo das complexidades de um ambiente real, além de ter elementos que se aproximam de mecanismos de execução.

Diagramas

Observamos também que a notação do BPMN se assemelha bastante a de alguns diagramas da UML, como os diagramas de atividades – que também podem ser comparados aos fluxogramas. Também é relevante mencionar que o BPMN é composto por um conjunto de BPDs (Business Process Diagram), sendo que esses diagramas de processos devem permitir que o desenho em questão, de alguma forma, possa ser mapeado para um formato de execução, tal como o próprio BPEL ou BPML.

O objetivo da notação BPMN é criar modelos gráficos de alto nível, visando uma proximidade maior à realidade dos analistas de negócio. Os elementos gráficos permitem desde a modelagem mais simples até as mais complexas. Na seqüência iremos definir o conjunto de elementos representativos que darão origem aos nossos diagramas, como Atividades, Eventos, Condicionais e Ligações. Esses elementos podem ser subdivididos em categorias, tais como são apresentadas pelo software livre Editor BPMN (Portal BPM, 2008) para desenho de modelos BPMN, apresentados a seguir.

Atividades

As atividades são representadas por retângulos com bordas arredondadas, conforme a Figura 2, e podem representar diferentes tipos de atividades conforme a necessidade do modelo a ser representado.

Eventos

Eventos indicam acontecimentos que, de alguma forma, podem alterar a seqüência de execução em um fluxo, sendo que iniciar ou terminar a realização de um processo são exemplos de eventos, conforme a Figura 3.

Condicionais

Os losangos indicam tanto pontos em que o fluxo pode divergir ou convergir, como pontos de tomada de decisão, conforme a Figura 4.

Ligações

A seqüência em que os elementos são executados dentro de um fluxo é indicada pelas setas de fluxo, e dois elementos conectados indicam o sentido deste fluxo, conforme a Figura 5.

Dados e Outros

Os elementos de dados fornecem informações a serem compartilhadas entre várias atividades em um fluxo. Dados como valores de cartões de crédito, carrinhos de compras podem ser, por exemplo, indicados por essa notação, conforme a Figura 6.

Os diagramas podem ser representados de diversas maneiras, desde uma visão mais superficial, ou de alto nível, até uma representação minuciosa de um processo.

Conforme a notação BPMN, exemplificamos um tipo de diagrama de “Processo de negócio privado”, quando se está interessado no detalhe. Neste diagrama, pode-se visualizar um “pedaço” de um processo sem se importar com seu modo de contextualização em relação ao restante do processo. Podemos observar esta característica na Figura 7.

O processo se “inicia” com a escolha de uma forma de pagamento. Observando-se o fluxo, conseguiremos notar como ele pode ser parte de um fluxo maior, por exemplo, um processo de compra em uma loja. Nesta representação, não importa quem está envolvido com a tarefa nem quais outras atividades foram ou serão executadas.

BPEL (Business Process Execution Language) – Orquestração

BPEL (Business Process Execution Language) é uma linguagem baseada em XML para a especificação formal dos processos empresariais e de negócios.

BPEL alarga o modelo de interação e serviços Web que lhe permite apoiar as operações comerciais. É o resultado de uma iniciativa cruzada entre IBM, BEA e Microsoft para desenvolver um processo universalmente relacionado com a linguagem suportada.

Na programação tradicional, a execução de serviços de maneira coordenada se faz mediante a criação de códigos que se conectam aos objetos. Esses códigos obtêm informações e as repassam a outros objetos. Um programa orientado a objetos é exatamente isso, uma seqüência de objetos se comunicando e passando informações uns aos outros.

A proposta do BPEL ou BPEL4WS é executar serviços em seqüência, mas por meio de um mecanismo não programático, reduzindo custos de manutenção causados por alterações freqüentes nos códigos. Sua versão inicial foi liberada em 2002, exatamente como proposta para a execução de serviços Web em seqüência.

O caminho adotado foi o de arquivos XML que descrevem como os serviços se comunicam, definindo-se mecanismos para armazenar informações de forma não programática, e criando-se engines que interpretam o XML, de modo a atuar como se fosse o programa em si.

Em resumo, os engines BPEL funcionam como grandes interpretadores de código XML, que executam atividades como se fosse um programa, mas de manutenção facilitada, já que apenas esses XML são afetados nessa atividade. Não utilizar tecnologias programáticas nos traz o benefício de se ter ferramentas de criação gráfica mais simples, que podem ser geridas e até mesmo mantidas pelas áreas de negócio.

É relevante dizer que o BPEL orquestra apenas Web Services. Se o mecanismo adotado para realizar a comunicação entre os serviços não for um Web Service, o BPEL se torna inaplicável, o que não é este caso, pois este artigo se baseia totalmente na tecnologia de Web Services.

Desta forma, diríamos que o BPEL torna uniformes vários paradigmas da TI, traduzindo-os em Web Services. Por outro lado, em função das suas características, não é interessante a sua utilização em aplicações que demandam a troca de documentos e nem em aplicações que geram muita interação humana.

Quando for utilizada alguma ferramenta visual com notação BPMN, alguns elementos gráficos como eventos gerados por dados não terão mapeamento direto para o BPEL, sendo normalmente disponibilizados por serviços de execução. O início de uma atividade causado pela alteração no valor de uma cotação, por exemplo, precisa ser codificado como elemento programático e disponibilizado como Web Service.

O BPEL ainda não define nada relacionado às telas de interação com o usuário. Isso significa que, se a ferramenta de desenho estiver gerando BPEL, serão necessários outros artefatos para que se tenha condições de operacionalizar o processo da forma esperada.

A característica de orquestrar apenas Web Services, peculiar ao BPEL, tornam necessários estudos no intuito de identificar se os elementos programáticos do legado da empresa, necessários à operacionalização do fluxo, proporcionam a capacidade de se tornar Web Services.

Estudo de Caso

Pretendemos neste estudo de caso utilizar novas metodologias e técnicas aplicadas ao gerenciamento de negócios, utilizando-se BPM e seus derivados.

O uso dessas novas tecnologias de projeto e desenvolvimento de software, aliadas ao mapeamento de processos das empresas, facilita a produção e manutenção de uma solução que se baseia em Web. Portanto, este artigo trata de projetar um sistema BPM utilizando tecnologias relacionadas no lugar onde foram usadas tecnologias de Workflow tradicionais, o qual é mais restritivo quanto à flexibilidade de um projeto e sua manutenção.

Este estudo de caso consiste na elaboração de diversos diagramas, entre eles, um diagrama com o fluxo e a macro arquitetura do projeto BPM, um diagrama BPMN, diagramas BPEL e alguns trechos de XML gerados automaticamente pelas ferramentas utilizadas.

É importante observarmos que este projeto de Workflow parte do ponto em que a solicitação do aplicativo já foi feita aos Web Services disponibilizados, os quais irão se comunicar com os fluxos BPEL, que por sua vez irão executar todas as regras de negócio, conforme exemplificado nos diagramas a seguir.

Ferramentas utilizadas

Para a confecção deste trabalho foi necessária a utilização de um aparato de tecnologias voltadas ao BPM e SOA. Optamos por utilizar as ferramentas da Oracle, devido à grande capacidade de integração das tecnologias envolvidas oferecidas por estas e, ainda, pela robustez e confiabilidade destas, já consagradas no mercado e atestadas por diversos profissionais da área.

Como servidor de Banco de Dados utilizamos o Oracle 10g; alem do servidor de aplicações Oracle Application Server e BPEL Control; para manipulação do BPEL utilizamos o JDeveloper e, finalmente, para a criação dos diagramas BPMN e conversão para o BPEL, a ferramenta BPA (Oracle Business Process Architect). Todas as ferramentas citadas podem ser encontradas em Oracle SOA Suite (2009).

Com relação às licenças de uso das ferramentas Oracle SOA Suite, as mesmas podem ser obtidas com licença trial de acordo com OTN License Agreement (2009), a qual foi utilizada para o desenvolvimento deste estudo.

Necessidades do Negócio

Nosso contexto compreende uma empresa do ramo de eletrônicos, a qual disponibiliza, através da Internet, seus produtos e serviços, os quais podem ser contratados por meio de solicitações enviadas pela Web, utilizando-se o computador ou mesmo um dispositivo móvel, como um celular. Em suma, o cliente estará efetuando pedidos em uma loja virtual.

A fim de definirmos um escopo para o estudo de caso, partiremos de uma empresa fictícia, a qual denominamos de M-Eletronics, com o objetivo de modernizar seus negócios e expandir suas fronteiras, além de estar buscando novas tecnologias que a possibilitem alçar novos mercados.

Desta forma, a empresa tem uma expectativa em médio prazo, de poder alcançar maior lucratividade, associada ao bom atendimento ao seu cliente.

Requisitos

O sistema desenvolvido trata-se de um gerenciador de pedidos, destinado a qualquer processo de pedidos, podendo ainda ser invocado a partir de qualquer plataforma. Este foi projetado, desenvolvido e executado a fim de facilitar, agilizar e tornar mais confiáveis tarefas que anteriormente eram executadas manualmente, sem desprezar a intervenção humana quando necessária.

Os principais requisitos são:

1. O Sistema deve receber o pedido através de um arquivo XML contendo as informações do mesmo;
2. O Sistema deve processar o arquivo XML, extraindo as informações do pedido;
3. O Sistema deve inserir o pedido;
4. O Sistema deve ler os dados do cliente, e validar os mesmos;
5. O Sistema deve verificar em estoque a disponibilidade do produto;
6. O Sistema deve validar os dados do cartão de crédito do cliente;
7. O Sistema deve efetivar o pedido caso todas as informações necessárias sejam validadas;
8. O Sistema deve dar baixa em estoque da quantidade do produto comprado.

Como regras de negócio, podemos definir:

• A partir de uma aplicação executada em um dispositivo móvel, será repassado para o BPEL, no formato XML, o id do cliente e uma coleção com os ids dos produtos selecionados, também o número do cartão de crédito do cliente;
• O pedido é armazenado e controlado em banco de dados pelo próprio BPEL, que mantém o estado de cada solicitação realizada, e ainda as persiste em Banco de Dados, sem nenhuma interferência humana. Para o objeto em questão, optamos por utilizar um BPEL assíncrono, pois algumas etapas do fluxo, como por exemplo, a "validação de cartão de crédito", eventualmente pode estar fora de operação e, desta forma, o processo ficaria aguardando uma resposta, até que o serviço se restabeleça;
• São recuperados todos os dados do cliente como, por exemplo, o endereço de entrega;
• Os produtos são debitados em estoque;
• É efetuado o débito no cartão de crédito do cliente;
• Em caso de erro na operação, como falta de crédito disponível no cartão, por exemplo, os produtos são retornados para estoque novamente.

Arquitetura do Projeto

Este projeto BPM tem como objetivo receber uma requisição de compra, disparada por meio de qualquer dispositivo computacional que ofereça suporte à linguagem XML. Neste estudo de caso, iremos enfatizar uma requisição enviada por meio de um dispositivo móvel, conforme a Figura 8.

Vale ressaltar, ainda, a importância da utilização de uma arquitetura baseada no Enterprise Service Bus - ESB, que tem a funcionalidade de melhorar o acoplamento, fazendo a função de um roteador das informações que por ali trafegam.

Desta forma, caso o sistema evolua sofrendo modificações, que é um fato normal, haverá necessidade de mudanças nos processos em BPEL. Sendo assim, bastará apenas alterarmos o ESB de entrada. O mesmo fato ocorrerá com o serviço dos Correios, por exemplo, caso a empresa passe a negociar com uma outra transportadora, o BPEL não precisa ser alterado.

Modelagem BPMN

No diagrama BPMN da Figura 9 demonstramos graficamente o fluxo no qual se enquadra nosso processo de negócio.

Os elementos apresentados no gráfico demonstram de forma clara e objetiva as ligações entre as atividades, eventos e condicionais existentes em um processo de realização de um pedido no que se refere ao negócio da empresa.

Na seqüência, detalharemos melhor as atividades que envolvem o processo de negócio de um pedido, na concepção de nosso estudo de caso.

Após o início do fluxo, foi criada uma atividade Criar Pedido, responsável por criar e gravar um conjunto de registros com status do pedido e receber a ordem de compra.

Posteriormente, foi inserida a atividade Get Dados Cliente, na qual utilizamos o id (identificador único) do cliente para o registro da ordem de compra, sendo este, a chave de busca para os dados do cliente.

Inserimos agora a atividade Get Informações de Credito, que tem o objetivo de recuperar o número do cartão de crédito do cliente e verificar o status do mesmo, ou seja, se o cartão é válido e se o saldo é suficiente para realizar aquela operação.

Em seguida, a atividade Aprovar Pedido deve fazer a aprovação do pedido, podendo ter dois resultados: “aprovar” ou “rejeitar”.

No caso do pedido ser rejeitado, o fluxo será direcionado para a atividade Cancelar Pedido, que efetuará o cancelamento do pedido, desfazendo todas as operações anteriormente realizadas, finalizando o fluxo. No caso do pedido ser aprovado, o fluxo será direcionado para a atividade Fechar Pedido que, por sua vez, efetiva o pedido solicitado e conclui o fluxo de um pedido, finalizando o fluxo.

Modelagem BPEL

Os diagramas a seguir correspondem exatamente ao fluxo representado no digrama anterior em BPMN. Por esse motivo, não será necessário descrever novamente passo a passo a sua execução, observando apenas que os diagramas BPEL foram separados em duas partes. A primeira, conforme a Figura 10, exibe o fluxo como um todo, contendo apenas as principais funções, quase idêntico ao diagrama BPMN, diferindo apenas na representação gráfica e nas interfaces com os serviços disponíveis. Um segundo diagrama BPEL poderia ser feito para demonstrar, detalhadamente, todas as funcionalidades desempenhadas pelo fluxo, bem como os tratamentos de exceção e suas interfaces com os serviços. Porém procuramos não estender demasiadamente este estudo de caso, optando por não incluí-los.

Descrição do Escopo “Criar_Pedido”

Detalharemos a seguir, um dos principais escopos do nosso diagrama BPEL, “Criar_Pedido”, conforme indicado pelo próprio nome, o qual é o responsável pela efetivação do pedido recebido pelo BPEL, apresentado na Figura 11.

Os seguintes passos são observados:

1. O BPEL solicita ao serviço “PedidoSequencia”, que retorna um número sequencial do pedido referente ao pedido em questão;
2. O BPEL irá definir as diversas variáveis do sistema para seu controle interno;
3. Irá adicionar os itens do pedido;
4. Em seguida, irá inserir o pedido através do serviço “InserirPedido” e, ainda, dar baixa no estoque caso o pedido seja concluído.

Por meio do JDeveloper, podemos manipular todas as entradas e saídas necessárias no mapeamento dos arquivos XML a serem gerados. Por exemplo, no escopo Criar_Pedido, podemos transferir um determinado conteúdo de entrada de uma variável para sua saída. Definimos, desta forma, um status “Pendente” para a variável de controle do status “AssignStatusOrdem”, conforme a Figura 12.

Executando um duplo clique sobre a variável em questão, será aberta uma nova tela, ilustrada pela Figura 13, na qual podemos notar a recuperação do “ID” que foi previamente gerado. Conforme se pode observar na figura, escolhemos na origem e destino a opção “Variable” e expandimos o escopo “CriarPedido”. Em “orderSequenceOutput” identifica-se sua origem e, selecionamos a sequence “order_seq_id_gen.nextval”, direcionando para a saída, à direita, conforme a árvore Variable > inputVariable > payload > client > PurchaseOrder > ID.

Através da próxima interface, podemos observar que será definido o status do nosso pedido para “Pendente”, atribuído em forma de String ao selecionarmos o Type Expression, conforme a Figura 14. Desta forma, a String “Pendente” será atribuída à variável OrderStatus.

Após a execução dos passos anteriores, teremos o arquivo XML gerado pela ferramenta (Listagem 1), representando o escopo “Criar_Pedido”, que expressa exatamente os passos executados anteriormente.

<scope name="Criar_Pedido">

   <variables>

     <variable name="orderRequest" messageType="ns8:OrdersCollection_msg"/>

      <variable name="orderSequenceInput"

                messageType="ns12:OrderSequenceInput_msg"/>

      <variable name="orderSequenceOutput"

                messageType="ns12:OrderSequenceOutputCollection_msg"/>

    </variables>

    <sequence name="Sequence_11">

       <invoke name="RecuperarIdPedido" partnerLink="PedidoSequencia"

             portType="ns12:OrderSequence_ptt" operation="OrderSequence"

               inputVariable="orderSequenceInput"

               outputVariable="orderSequenceOutput"/>

       <assign name="AssignStatusOrdem">

         <copy>

          <from variable="orderSequenceOutput"

                 part="OrderSequenceOutputCollection"

                 query="/ns18:OrderSequenceOutputCollection/

                  ns18:OrderSequenceOutput/ns18:order_seq_id_gen.nextval"/>

           <to variable="inputVariable" part="payload"

               query="/client:SOAOrderBookingProcessRequest/

                ns4:PurchaseOrder/ns4:ID"/>

         </copy>

         <copy>

           <from expression="string('Pendente')"/>

           <to variable="inputVariable" part="payload"

               query="/client:SOAOrderBookingProcessRequest/

                ns4:PurchaseOrder/ns4:OrderInfo/ns4:OrderStatus"/>

         </copy>

       </assign>

       <assign name="AdicionarItensPedidos">

         <bpelx:annotation>

           <bpelx:pattern>transformation</bpelx:pattern>

         </bpelx:annotation>

         <copy>

           <from expression="ora:processXSLT('TransformOrder.xsl',

              bpws:getVariableData('inputVariable','payload'))"/>

           <to variable="orderRequest" part="OrdersCollection"/>

        </copy>

       </assign>

       <invoke name="InserirPedido" partnerLink="InseriPedido"

               portType="ns8:Order_ptt" operation="write"

               inputVariable="orderRequest"/>

     </sequence>

   </scope>