SOA na Prática – Criando uma Aplicação BPMN com Bonita Open Solution, Mule ESB e Google App Engine

SOA na Prática – Criando uma Aplicação BPMN com Bonita Open Solution, Mule ESB e Google App Engine 1 Michel A. Soares1 Universidade de Fortaleza – Desenvolvimento de Sistemas com Ênfase na Plataforma JEE {michel.azevedo@gmail.com} Abstract. SOA and cloud computing are two close related subjects. Knowing how to take advantage of these paradigms might place a company ahead of its competitors, especially in a demanding market where a company has to adapt quickly to changes. This paper shows a proof of concept application that basead only on open source tools, highlights the benefits of SOA and cloud computing to SMEs. To achieve that goal, we model a BPMN 2.0 business process that calls cloud services (e.g., google app engine and twitter) during its flow through the Mule ESB, message oriented middleware. Resumo. Arquitetura orientada a serviços e computação nas nuvens possuem um estreito relacionamento. Saber como tirar proveito desses dois paradigmas pode representar grande vantagem competitiva em um mercado que demanda rápida adaptação a mudanças. Este artigo mostra uma prova de conceito que, baseado apenas em ferramentas open source, destaca os benefícios de SOA e computação em nuvens para pequenas e médias empresas. Para isso foi modelado um processo de negócio no padrão BPMN 2.0 que durante sua execução chama serviços nas nuvens (ex: google app engine e twitter) via middleware orientado a mensagens, Mule ESB.1. IntroduçãoAté poucos anos atrás, quando se falava em implantar uma arquitetura orientada aserviços (SOA, da sigla em inglês), mencionava-se que esse tipo de abordagem era maisadequada para empresas que possuíam grandes sistemas legados. Josuttis(2007) afirmaque SOA é um conceito para grandes sistemas distribuídos. Ele afirma que SOA é umatécnica para a manutenção desses grandes sistemas. Dessa forma, era natural que seassociasse a implantação desse tipo de arquitetura a grandes empresas. Outros fatoresque limitavam SOA às grandes empresas eram: o custo e a complexidade dos projetos.O custo era elevado porque apenas ferramentas de mercado com licenças bastante caraseram capazes de oferecer as funcionalidades necessárias para um ambiente de produçãobaseado em SOA. A complexidade era outro fator crítico porque a implantação de taissoluções demandavam um grande esforço e mudanças de paradigmas nas empresas,portanto, justificando-se apenas para grandes empresas capazes de suportar tamanhamudança e dispostas ao investimento necessário. Contudo, a adoção de SOA nos últimos anos entre empresas de diferentes portese ramos de atividades tem aumentado. É o que comprova Heffner (2010) no estudo

realizado pelo instituto Forrester. Ele mostra que as iniciativas SOA avançaram 27%entre grandes empresas e 45% entre médias e pequenas empresas mesmo em tempos decrise. O estudo foi realizado em 2009, ano em que a economia global ainda serecuperava da grande crise de 2008. No Brasil, em estudo realizado na Universidade de Brasília por Puttini andSousa (2011), pôde ser constado que 91.67% das empresas já consideram SOAimportante ou muito importante em sua estrutura de TI e 53.8% consideram que SOAtem importância estratégica no negócio; 100% observaram, em parte ou totalmente, oaumento do alinhamento entre TI e Negócio, e também o aumento na reutilização dasaplicações; 90% observaram alguma redução do custo de TI; 54% observaram,totalmente ou acima do esperado, o suporte a novos serviços. Com o surgimento de ferramentas open source mais completas e com o adventoda computação nas nuvens (Cloud Computing), soluções SOA passaram a ser maisacessíveis para empresas de pequeno e médio porte, além de permitir para diferentesempresas a realização de uma prova de conceito, sem muito custo, o que permite aavaliação da solução também com menor esforço. Power (2010) descreve alguns problemas que atingiam pequenas empresas antesdo surgimento da arquitetura orientada a serviços. Segundo este trabalho, essasempresas sofreram no passado devido ao custo de integração com seus fornecedores degrande porte, que era muitas vezes proibitivo. Com o advento de SOA, seus parceirosestão agora aptos a expor serviços que podem ser consumidos por diversas aplicaçõesque são usadas hoje. Produtos como Excel e Word podem se integrar com os sistemasde TI dos seus parceiros de uma forma antes inimaginável. Com o advento do Softwarecomo Serviço (SaaS, da sigla em inglês) e dos serviços estabelecidos nas nuvens,pequenas e médias empresas podem se utilizar de sistemas complexos e antes de altocusto ao utilizar apenas uma fração deles e, consequentemente, sendo cobradas apenaspor essa utilização e não pelo custo envolvido no desenvolvimento da aplicação. Podemos entender que SOA não deve restringir-se apenas a grandes empresas,embora grandes empresas com sistemas legados configurem um cenário bastantepropício para implantação desse tipo de arquitetura. Sezov (2011) aponta algumas vantagens dos projetos que utilizam ferramentasopen source: • Não tem o problema de ter que aguardar muito tempo por correções e decisões sobre melhorias; • Tendem a implementar o que os usuários querem o mais rápido possível; • Geralmente são mais leves: não há necessidade de um servidor dedicado para iniciar a implantação; • Elas permitem que o desenvolvimento flua mais rapidamente pelo fato de não ser necessário o entendimento de toda a arquitetura para ser efetivo; • Não é necessário grande investimento para iniciar um projeto que utilize ferramentas open source. Pode-se iniciar pequeno (open source) e então aumentar os investimentos conforme sua aplicação cresça.

A motivação para a realização deste estudo parte do princípio de que podemosfazer não apenas aplicações complexas, mas também aplicações mais simples. Oobjetivo deste artigo é dar subsídios para o entendimento de como podemos iniciar aimplantação de um projeto SOA utilizando apenas ferramentas open source. Para isso,será desenvolvido um estudo de caso em que será implementado um processo denegócio utilizando o BPMS Bonita Open Solution. O processo será responsável porcoordenar chamadas a serviços disponíveis em plataformas nas nuvens, como GoogleApp Engine e Twitter. Esses serviços por sua vez, serão chamados por meio de um ESBopen source, o Mule ESB. O artigo será compreendido da seguinte forma: na seção 2 temos uma visãogeral de SOA, Computação em nuvem, ESB e BPMS, onde será mostrado como osconceitos se relacionam. Em seguida, na seção 3, são apresentadas as ferramentasutilizadas na implementação e dada uma breve explanação de como elas são utilizadasno estudo de caso. Na seção 4, é apresentado o estudo de caso, em que foi escolhidauma aplicação para ser desenvolvida utilizando as ferramentas apresentadas na seção 3.Na seção 5, são apresentados trabalhos relacionados ao tema em estudo. Por fim, naseção 6, são descritas a conclusão e sugestão de trabalhos futuros.2. Visão geral sobre SOA, Computação em nuvem, ESB e BPMS2.1 SOADe acordo com Davis (2009), arquitetura orientada a serviços é uma estratégia de TIque organiza as funções discretas nas aplicações empresariais em serviçosinteroperáveis e baseados em padrões que podem ser combinados e reusadosrapidamente de forma a atender as necessidades de negócios. Outra definição mais atual pode ser a dada por OpenGroup (2011): Arquitetura orientada a serviços é um estilo de arquitetura que suportaorientação a serviço. Orientação a serviço é uma forma de pensar em termos deserviços e desenvolvimento baseado em serviços e seus resultados. Um serviço: • É uma representação lógica de uma atividade de negócio que pode ser executada repetidamente e tem um resultado específico (ex., consultar crédito do cliente; consulta saldo em estoque); • É autônomo, independente; • Pode ser composto por outros serviços; • É uma “caixa preta” para os seus consumidores. Um estilo arquitetural é uma combinação de características distintas em que aarquitetura é executada ou expressa. O estilo da arquitetura empregada em SOA tem asseguintes características: • É baseado no design dos serviços – que espelha as atividades comerciais do mundo real – compreendendo os processos de negócios da empresa;

• A representação de serviços utiliza descrições de negócios para fornecer o contexto (ex., processos de negócios, objetivo, regra, política) e implementa serviços usando orquestração; • Demanda aspectos específicos de infraestrutura – recomenda-se o uso de padrões abertos (ex: SOAP, WSDL, REST) de modo a atingir a interoperabilidade. Figura 1. Metamodelo SOA (Linthicum, 2009) O metamodelo SOA oferece uma boa maneira de ver como SOA utiliza umacamada de processo / orquestração para mudar os processos de negócios importantes,sem promover mudanças em todos os sistemas. Esta é uma arquitetura de baixoacoplamento (Linthicum, 2009). Neste artigo essa camada de orquestração seráexecutada pelo processo desenhado no Bonita Open Solution (que será apresentado naseção 4, com o estudo de caso), e a camada “Services” será executada pelo Mule ESB.2.2 Cloud ComputingUma definição de Cloud Computing (Computação nas Nuvens, em português) bastanteutilizada é a dada por Mell and Grance (2011), que dizem que Computação nas Nuvensé um modelo que permite acesso à rede de forma ubíqua, conveniente e sob demanda aum pool de recursos computacionais (redes, servidores virtuais ou físicos,armazenamento, aplicações e serviços) que podem ser rapidamente provisionados. Cloud Computing pode ser visto como um recurso de TI, que pode ser utilizadona implantação de uma arquitetura orientada a serviços. Recursos comoarmazenamento, capacidade de processamento e softwares provendo serviços podem serutilizados e pagos sob demanda, além de delegar a responsabilidade de gerenciamentodesses recursos para o provedor de nuvem.

Algumas características do modelo de nuvem, segundo Mell and Grance (2011),são: • Atendimento self-service e sob demanda. Um consumidor de um serviço de nuvem pode requisitar automaticamente (normalmente usando-se de interfaces de programação ou APIs) um recurso computacional (por exemplo, um servidor virtual ou espaço em um servidor de armazenamento em rede); • Elasticidade. O consumidor do serviço pode requisitar dinamicamente mais ou menos recursos para sua aplicação para se adaptar à demanda dos seus usuários. Por exemplo, em períodos de pico, o consumidor solicita à nuvem mais recursos computacionais (como, por exemplo, servidores adicionais), podendo, depois, liberar tais recursos, quando estes não forem mais necessários; • Pagamento pelo Uso e Garantias de Serviço (Service Level Agreements – SLAs). Os consumidores pagam aos provedores de serviço de nuvem de acordo com o consumo efetuado (modelo de pagamento pelo uso semelhante a utilidades como energia e gás). A nuvem possui mecanismos para permitir o compartilhamento dos recursos existentes de forma eficiente para os diversos clientes e monitorar as aplicações e os recursos de forma a respeitar as garantias de serviço oferecidas, como, por exemplo, disponibilidade de 99.9%; • Acesso ubíquo através da rede. Os recursos computacionais podem ser acessados através de padrões (como APIs REST baseadas em HTTP ou SOAP) por diversos tipos de clientes (browsers, PDAs, celulares) e seus detalhes de funcionamento e complexidades ficam “escondidos” pela nuvem.Quanto ao modelo de serviço, podemos ter os seguintes tipos de nuvem: • Software as a Service (SaaS): quando software é fornecido como um serviço na internet para vários dispositivos através de um cliente (como um browser), eliminando a necessidade de instalação da aplicação no computador consumidor do serviço (Ex: Google Docs); • Platform as a Service (PaaS): quando uma infraestrutura é disponibilizada como serviço. Facilita a disponibilização de aplicações criadas usando as linguagens de programação e ferramentas suportadas pelo provedor. O consumidor não controla a infraestrutura da nuvem, incluindo rede, servidores, sistemas operacionais ou banco de dados, mas tem controle sobre as aplicações e suas configurações (Ex: Google App Engine); • Infrastructure as a Service (IaaS): disponibiliza infraestrutura de equipamentos - tipicamente em ambiente virtualizado - como serviço. Essa infraestrutura pode incluir: processamento, sistema operacional, banco de dados, rede e firewall (Ex: EC2 da Amazon).2.3 Enterprise Service Bus (ESB)Em grandes implantações, é muito provável a necessidade de se fazer integração entresistemas. É também muito provável que esses sistemas não “falem” a mesma língua, ouseja, não utilizem o mesmo protocolo para se comunicarem. Muitas vezes, não é apenasa comunicação que é diferente; pode ocorrer que a disponibilidade de uma aplicaçãoseja diferente do momento em que outra necessite de uma informação. É nesse tipo decenário que um Enterprise Service Bus (ESB) pode ser bastante útil.

De acordo com Josuttis (2009), em SOA, o ESB faz parte da infraestrutura quenos permite usar serviços em ambiente de produção. É de responsabilidade dele exporserviços e deixá-los disponíveis para serem consumidos pelas aplicações clientes. Seuprincipal papel é prover a interoperabilidade. Essa sua caracterização se deve pelo fatode essa camada da arquitetura SOA servir para promover a integração de diferentesplataformas, serviços, linguagens de programação, além da transformação e doroteamento de dados, que são algumas de suas principais atribuições. Um ESB devepermitir a chamada e o recebimento de mensagens de um consumidor para um provedorde serviço e vice-versa.2.4 Business Process Management (BPM) e Business Process ManagementSystem (BPMS)Business Process Management (BPM) está cada vez mais ganhando atenção em grandese médias empresas e é vista como uma ponte entre o setor de TI e a área de negócios.BPM ajuda as empresas a identificarem a importância estratégica de seus processos e atirarem vantagens competitivas disso. Serve também para proporcionar ao gestor donegócio uma maior facilidade de encontrar oportunidades de melhoria para o serviçoprestado ao cliente, através de indicadores de resultados. As ferramentas tecnológicasque são utilizadas para aplicar efetivamente BPM nas empresas são chamadas deBusiness Process Management Systems (ou Suites), ou apenas BMPS. Existem váriasdefinições para BPMS, mas uma que é bem recente e influente é a dada por Weske(2007), que diz que um Business Process Management System é um software genéricoque é orientado por representações de processos para coordenar a execução de processosde negócios. A maioria das ferramentas de BPM, atualmente, são comerciais pagas e caras.Não é toda empresa que está disposta a realizar um grande investimento numaferramenta dessas. As ferramentas open source podem ajudar nesse sentido de auxiliarno processo de entrada no universo BPM sem grandes investimentos. Até pouco tempoatrás, não se imaginava essa possibilidade, porque existia uma grande distância entre oque as ferramentas comerciais implementavam e o que as open sourcedisponibilizavam. Hoje, as soluções gratuitas já representam uma ótima opção para aimplantação da cultura BPM nas empresas, além de trazer os benefícios intrínsecos doopen source como possibilidade de obter correções mais rápidas da comunidademantenedora e das soluções inovadoras muitas vezes disponibilizadas.3. Ferramentas utilizadas3.1 Google App EngineO Google App Engine pode ser classificado como um PaaS e com ele, segundoAppengine (2011), é possível que aplicações sejam desenvolvidas através de umframework que facilita a implementação de aplicações em diversas linguagens, comoJava, Phyton e Go1, e sua implantação utilizando a infraestrutura de nuvem do Google.Além disso, a plataforma permite escalar o tráfico da aplicação de forma automática àmedida que a demanda imposta pelos usuários da aplicação aumentar ou diminuir.1 Go é uma linguagem de programação desenvolvida pelo Google e tem como principal objetivocombinar a eficiência de linguagens tipadas e compiladas com as facilidades de linguagens interpretadas(Pike, 2009).

Como é característica de uma nuvem PaaS, abstrai-se a necessidade demanutenção de servidores e facilita-se o desenvolvimento de aplicações prontas paraexecutarem em um ambiente de nuvem escondendo os detalhes do programador.3.2 TwitterÉ uma ferramenta online de microblogging que permite compartilhar posts (conhecidoscomo tweets) de até 140 caracteres. É definido por Twitter (2011) como uma rede emtempo real em que é possível se conectar às mais recentes informações sobre o que sejulga interessante.3.3 Mule ESBDe acordo com Mulesoft (2011), Mule ESB é uma plataforma de integraçãodesenvolvida na linguagem Java que permite aos desenvolvedores conectar aplicaçõesde forma rápida e fácil, fazendo com que elas possam trocar mensagens. Ele permite aintegração de sistemas independentes das diferentes tecnologias que eles utilizem,incluindo JMS, Web Services, JDBC, HTTP, entre outros. A vantagem principal de um ESB é que ele permite que diferentes aplicações secomuniquem com outras atuando como um sistema de transporte por carregarem dadosentre aplicações e das aplicações para a internet. Mule ESB possui poderosasfuncionalidades, dentre elas: • Criação e hospedagem de serviços — é possível expor e hospedar serviços, usando Mule como um repositório; • Mediação de serviços — proteger serviços de formatos e protocolos, separar a lógica de negócios das mensagens, e habilitar chamadas de serviços independente de onde eles estejam disponíveis; • Roteamento de mensagens — rotear, filtrar, juntar e resequenciar mensagens, baseando-se no seu conteúdo e regras; • Transformação de dados — troca de dados entre uma variedade de formatos e protocolos. Figura 2. Infraestrutura do Mule ESB (Dirksen, 2008) Conforme indicado na Figura 2, a arquitetura do Mule ESB, segundo Dirksen(2008), pode ser definida da seguinte forma: • Component: Contém a lógica do negócio. Pode ser, por exemplo, um spring bean, um serviço REST, um simples POJO etc; • Transport: Lida com a conectividade com a tecnologia em questão ou com a aplicação (ex: JMS, SAP, FTP, HTTP);

• Transformers: Transforma os dados para o formato que o próximo componente está esperando receber; • Inbound Routers: determina o que fazer com a mensagem recebida antes de ela ser enviada para um serviço; • Outbound Routers: determina para onde a mensagem precisar ser enviada após ter sido processada por um serviço.3.4 Bonita Open SolutionBonita Open Solution, da empresa BonitaSoft, vem sendo chamada de a ferramentaresponsável por democratizar BPM ao disponibilizar funcionalidades antes apenasvistas em ferramentas comerciais, tornando-a altamente competitiva nesse mercado(Rigsby, 2011). Lançada em 2009, não demorou muito para ela se popularizar. Emmenos de dois anos, a comunidade atingiu a marca de 3.000 membros, meio milhão dedownloads e 100 clientes. Esse rápido crescimento é atribuído ao forte foco daferramenta em usabilidade, facilitando o manuseio por usuários não técnicos. Carthuatocto (2011) realizou um estudo em que compara algumas dasferramentas BPMS open source mais populares do mercado. O estudo mostra queBonita Open Solution é a solução mais completa quando foram analisados os critérios:workflow, modelador de processos, criador de formulários, monitoramento deprocessos, motor de regras de negócios e conexão com ferramentas externas. Bonita é composta de três componentes principais: • Bonita Studio: permite ao usuário graficamente alterar processos de negócios seguindo o padrão BPMN 2.0. O usuário pode também conectar o processo a outros sistemas (como, ERP, ECM, databases...) de forma a permitir a criação de uma aplicação autônoma e acessível como formulário web. Bonita Studio, que é baseado no eclipse, também permite o usuário desenhar graficamente os formulários que serão exibidos para o usuário final do processo permitindo a interação com o processo; • Bonita BPM Engine: o motor de execução é próprio e disponibiliza uma API Java que permite a interação com os processos; • Bonita User Experience: é um portal que permite cada usuário final controlar na forma de webmail todas as suas tarefas que lhe foram atribuídas ou que o envolvem de alguma forma. O portal também permite ao responsável pelo processo administrar e obter relatórios sobre os processos.4. Estudo de CasoAtualmente, é muito improvável que uma empresa, seja ela, pequena, média ou grande,não tenha um sistema para controlar suas rotinas básicas, como compra de mercadoriase/ou serviços, estoque, vendas, contas a pagar e a receber etc. Muitas possuem oschamados ERPs, que são sistemas que integram todos os módulos usados pelas diversasáreas da empresa em um único sistema. Não é raro encontrar casos em que é necessário se realizar uma integração, sejapela chegada de um novo parceiro comercial, seja devido à equipe de TI ter julgadonecessária a adoção de uma nova tecnologia, por decisão estratégica da direção daempresa ou até mesmo por uma fusão.

O caso a ser demonstrado abaixo tem como objetivo a simulação de um cenáriomuito possível em empresas que estão dispostas a adotar uma solução SOA paraprojetos internos. Principalmente para empresas que não se utilizam ou não têmexperiência, ele ilustra uma possível alternativa dando a direção para a criação de umaprova de conceito com algum processo da empresa, o que permite a avaliação daarquitetura para projetos maiores. Figura 3. Arquitetura da aplicação Mule ESB Não é objetivo deste estudo a criação de uma aplicação complexa e nem acriação de um tutorial de como utilizar as ferramentas utilizadas, e, sim, o de apresentaros conceitos envolvidos e mostrar que é possível, apenas com ferramentas open source,a criação de uma solução SOA, que pode ser aplicada na realidade de qualquer empresa,desassociando a imagem de que SOA é apenas para grandes empresas e envolve altoscustos. Dessa forma, esse exemplo é uma aplicação simplificada, comparada a umaaplicação que seria desenvolvida em ambiente de produção. Portanto alguns aspectosque devem ser levados em consideração em aplicações corporativas não foramobservados, como fatores de segurança, validações das entradas de dados e tratamentode exceções no processo (situação que será bastante comum nas aplicações dessanatureza). Como pode ser observado na Figura 3, a aplicação consiste de um processodesenhado no Bonita Open Solution (processo completo pode ser visto no Apêndice B),processo esse que fará a orquestração de todas as etapas da aplicação. Durante oprocesso, serão realizadas chamadas a serviços que estão sendo executados emplataforma de nuvem, um deles é um serviço disponibilizado no Google App Engine, eoutro é uma conta no Twitter. As chamadas serão realizadas utilizando o intermédio doMule ESB.4.1. Processo no BonitaNesse exemplo, foi escolhido um processo de compra para ser automatizado. Oprocesso envolve os seguintes atores: • Cliente: usuário final que usará a interface web para solicitar a compra do material

• Mule ESB: será responsável pela comunicação com a aplicação no Google App Engine e com a conta do gerente no twitter, durante a execução do processo; • Gerente: será responsável por aprovar novos pedidos Inicialmente, foi desenvolvido o processo no designer do Bonita. O processocontém as tarefas definidas a seguir.4.2. Criar PedidoEssa é a primeira tarefa e foi definida para ser atendida pelo “usuário iniciador”(Initiator) do processo. Quando o processo “Pedido de compra” é executado pelainterface web do Bonita, conhecida como User XP, o formulário que foi desenhado,como mostrado na Figura 4 e atribuído a essa tarefa, é apresentado para o usuário deacordo com a Figura 5. Figura 4. Formulário desenhado no gerador de formulários do Bonita Figura 5. Formulário em execução no browser Quando o usuário preenche as informações relativas ao seu pedido e clica nobotão “Enviar”, o processo segue, conforme foi definido no diagrama do processo, paraa próxima tarefa, “Verificar Pendência”.

4.4. Verificar PendênciaEssa é uma tarefa que, de acordo com a notação BPMN 2.0 (Silver, 2009), é chamadade “Service Task”. Ela é assim chamada por ser uma tarefa automática, sem aintervenção humana. Comumente, essas tarefas terão associadas a elas conectores. OBonita pode se comunicar com diversas plataformas e sistemas via conectores. Essa foium das formas que os idealizadores da ferramenta encontraram para permitir que acomunidade contribua de forma mais ativa e direta para o desenvolvimento daferramenta. Dentro do nosso processo, a atividade “Verificar Pendência” se utiliza do MuleESB Conector (BonitaSoft, 2011). Ele possibilita que um processo no Bonita seaproveite de toda a infraestrutura do Mule ESB. Dessa forma, foi criada uma aplicaçãoque faz a consulta ao serviço publicado no Google App Engine. Aplicações no Mule sãoXMLs com as instruções de como tratar a mensagem que foi enviada para ele. A seguir parte do XML da aplicação que é responsável pela comunicação com oserviço no App Engine (para ver o XML completo, ver Apêndice A) <http:inbound-endpoint address=http://localhost:8888 exchange-pattern="request-response"/> <http:outbound-endpointaddress=http://aplicacao.appspot.com#[header:INBOUND:http.request] exchange-pattern="request-response" /> A aplicação está publicando na máquina local em, http://localhost:8888, umserviço que, automaticamente, redireciona a chamada para a aplicação que estádisponível no endereço http://aplicacao.appspot.com, e repassa os dados recebidos nocabeçalho da requisição. Neste caso, foi realizado um simples redirecionamento, mas oMule permite o uso de transformadores de mensagens, mecanismos de decisão eescolha, que poderiam também ser utilizados para incrementar segurança ou escolher oserviço a ser chamado, dependendo da mensagem que chegar. Uma vantagem de seutilizar o Mule como intermediário neste ponto, além dos citados, é que, caso a url doserviço precise ser alterada, por exemplo, ou a aplicação seja movida para outraplataforma de nuvens, o processo no Bonita não precisaria ser alterado, apenas aaplicação no Mule, um simples XML, o que é bem mais simples. O “Verificar Pendência”, portanto, chama o serviço, que, por sua vez, executa aregra de negócio, no caso, verificar se o usuário possui alguma pendência financeira queo impeça de realizar novos pedidos, e retorna para o Bonita. O retorno dessa chamada éguardado em uma variável global definida na modelagem e será usada no próximoelemento do diagrama, que é um “Gateway de decisão Exclusivo”. Esse Gatewayverifica se o valor retornado é igual a “ok”, caso afirmativo, segue para “AvisarGerente”; do contrário, vai para “Avisar Solicitante de Pendência”.

Figura 6. Gateway que decide para onde seguir após consulta ao serviço no GAE4.5. Avisar Solicitante de PendênciaEssa atividade existe apenas para avisar ao usuário que ele não pode realizar o pedidopelo fato de existirem pendências financeiras. Foi criado um formulário com aidentificação do pedido e uma descrição sobre a pendência encontrada no sistema. Figura 7. Formulário apresentado para o cliente em caso de pendência financeira4.6. Avisar GerenteEssa tarefa é executada caso o solicitante não possua nenhuma pendência financeira.Neste caso, o processo aciona o Mule via Connector, a aplicação recebe o número dopedido e posta uma mensagem no twitter usado pelo gerente para acompanhar anecessidade de aprovar novos pedidos.

Figura 8. Conta do gerente no Twitter, com mensagem indicando que deve ser aprovado pedido. Conforme ilustrado na Figura 9 (a aplicação foi desenvolvida no Mule Studio -ferramenta gráfica para criação dos XMLs do Mule ESB), o Mule aguarda requisiçõesHTTP e encaminha para o Twitter. Para conseguir a comunicação, foi necessária a geração de alguns parâmetrospelo próprio Twitter. Após isso, foram configurados no componente os dados para que oacesso à conta fosse permitido. Figura 9. Fluxo da aplicação que atualiza o twitter desenhada no Mule StudioA seguir, parte do XML que foi gerado pelo Mule Studio.<twitter:update-status consumerKey="xx" consumerSecret="xx"status="#[header:INBOUND:status]" doc:name="Update Status" doc:description="UpdateTwitter status with message."/>

4.7. Aprovar PedidoApós o gerente ser avisado de que existe um pedido novo para ser aprovado, ele deveseguir para sua caixa de entrada de pendências no Bonita User XP (Figura 12), ondepoderá ser visualizada a tarefa de aprovação de pedido. Figura 10. Inbox do usuário com a tarefa “Aprovar Pedido” pendente de atendimento Ao clicar na tarefa, será aberto o formulário com os dados do pedido (Figura11), e ele terá a oportunidade de aprovar ou não o pedido. Após a decisão do gerente, osolicitante do pedido será notificado da decisão na próxima atividade “NotificarResultado”. Figura 11. Tela de aprovação de pedido4.8. Notificar ResultadoDepois que o gerente toma a decisão na tarefa “Aprovar Pedido”, a tarefa “NotificarResultado” se encarrega de enviar um email para o solicitante informando a decisão.Nesse caso, foi utilizado o conector Mail Connector do Bonita Open Solution, com oqual permite fazer a configuração dos dados da conta de email que será utilizada e ocorpo da mensagem (Figura 12). Após o envio do email, o processo é finalizado.

Figura 12. Configuração do conector para envio de email5. Trabalhos relacionadosWei and Blake (2010) mencionam as dificuldades encontradas pelas empresas de lidarcom as rápidas mudanças exigidas pelo mercado, pelas demandas de seus clientes e asconstantes mudanças nos processos de negócios. Eles trazem uma análise dos desafiossurgidos com o uso da computação em nuvens, a arquitetura SOA e de como asempresas podem se beneficiar desses dois paradigmas. Raines (2009) destaca o grande movimento em direção à plataforma de nuvens ea mudança nas relações entre fornecedores e clientes, com o surgimento desse novoparadigma. Ele destaca os benefícios e os riscos que devem ser analisados pelosgestores de TI nesse novo cenário e lembra que SOA e Cloud computing são atividadescomplementares e que devem desempenhar papel de destaque no planejamento de TI. O estudo realizado por Allweyer (2011) mostra um cenário de colaboração entredois parceiros que utilizam um BPMS. Ele reforça que é cada vez mais comum a adoçãode sistemas BPMS nas empresas e que o cenário proposto é muito provável de ocorrer.Ele utiliza o Bonita Open Solution para a criação dos diagramas utilizados nasaplicações, além de usar também o engine de execução de processos e orquestração. Nocenário, ele utiliza um banco de dados para intermediação de mensagens entre os doisprocessos. A utilização do Mule ESB para essa finalidade também é possível com autilização de uma fila de mensagens, conforme descreve Ricston (2010). Vollmer (2009) fala sobre a experiência do uso de SOA e BPM na FloridaCommunity College, em Jacksonville. Ele destaca o tempo de preparação que a equipelevou antes de colocar a solução em produção e de como o parceiro ajudou para que osobjetivos fossem atingidos. Ele conclui mostrando que os planos de crescimento dauniversidade para comportar mais alunos só foram possíveis devido à estratégia adotadacom a adoção do novo modelo de desenvolvimento utilizando SOA.

6. Conclusão e trabalhos futurosComo o objetivo do artigo foi o de mostrar como seria possível o desenvolvimento deuma aplicação SOA utilizando apenas ferramentas open source e dar subsídios parapermitir a criação de uma prova de conceito utilizando um processo de negócio daempresa, as ferramentas foram selecionadas e utilizadas na criação de um estudo decaso. A aplicação foi definida de forma a permitir a utilização das camadas“orquestração” e “serviços” descritas no metamodelo SOA. A orquestração, nesse caso,foi feita pelo processo de negócio modelado no Bonita Open Solution, e os serviçosforam disponibilizados no Mule ESB que, por sua vez, se comunicava com o Twitter ecom uma aplicação disponível na plataforma de nuvens do Google. A utilização do Bonita se mostrou bastante intuitiva, revelando o que já seesperava quando da escolha da ferramenta. O uso dos conectores para integração comserviços e aplicações externas também se mostrou bastante eficiente. A criação deformulários também não apresentou dificuldades. O gerador só deixa a desejar napossibilidade de se personalizar o espaçamento dos campos, mas isso pode sercontornado com a utilização de templates, que permitem inclusive a total remodelagemda aparência dos formulários. O fato de o designer utilizar, a notação BPMN 2.0também ajuda bastante, uma vez que o padrão é familiar aos analistas de processos quevão modelar o processo. É importante ressaltar a importância da escolha de qualprocesso automatizar em um ambiente corporativo. A escolha de um processo nãocrítico e de baixa complexidade pode fazer grande diferença nas primeirasimplementações. A utilização do Mule ESB intermediando as chamadas aos serviços pôde revelaralgumas vantagens: na necessidade de alterações dos urls dos serviços, o processo nãoprecisou ser alterado, apenas o XML da aplicação do Mule. Isso pode ser importantepara evitar o envolvimento desnecessário de analistas de processos nesse tipo demudança. Por se tratar de uma aplicação que utiliza apenas ferramentas open source, adocumentação poderia representar um problema na criação do estudo de caso. Contudo,foi constatada uma boa documentação das ferramentas nos sites dos fabricantes e umaampla base de conhecimento disponibilizada pela comunidade que as utiliza. Um estudo semelhante com a utilização de ferramentas comerciais seria válidopara a comprovação do benefício da utilização de ferramentas open source. Podemtambém ser realizados os seguintes estudos complementares ao apresentado aqui: • Integração de processos de negócios com o portal open source Liferay para disponibilização de processos dentro de uma intranet; • Adicionar um motor de regras de negócios open source, por exemplo, o Drools. Ele possui integração com o Bonita e com o Mule ESB.

7. ReferênciasHeffner, Randy and Leganza, Gene (2010) Pesquisa “Adoption Of SOA: Still Strong, Even In Hard Times” publicada por Forrester Research, Inc., em 21 de junho de 2010Sezov, Rich Jr. (2011) “Liferay in Action”. ManningLinthicum , David S., (2009) “Cloud Computing and SOA Convergence in Your Enterprise” Addison WesleyDavis, Jeff. (2009) “Open Source SOA”. ManningPower, Jonh. (2010) “Is SOA Only for Large Organizations?” Disponível em: http://www.theinfoboom.com/articles/is-soa-only-for-large-organizations/, Acessado em 11/09/2011Carthuatocto, Roger. (2011) “jBPM, Bonita, Intalio, ProcessMaker, Activiti. Qué BPM Suite uso” Disponível em: http://holisticsecurity.wordpress.com/2011/07/21/jbpm- bonita-intalio-processmaker-activiti-que-bpm-suite-uso/, Acessado em: 24/09/2011Mell, P. and Grance, T. (2011), "National Institute of Standards and Technology,Information Technology Laboratory (NIST) Working Definition of Cloud ", Disponível em: http://www.nist.gov/itl/cloud/index.cfm, Acessado em: 11/09/2011Appengine (2009) “Google App Engine” Disponível em: http://code.google.com/appengine/docs/whatisgoogleappengine.html, Acessado em: 11/09/2011.Josuttis, Nicolai M., (2007) “SOA in Practice” O’ReillyPuttini, Ricardo and Sousa, Rafael. (2011) “SOA Adoption in Brazilian Institutions: How Is It Going?”. Disponível em: http://www.soasymposium.com/home2011/pdf_brazil/Ricardo_Puttini_Agnostic_Ser vices.pdf, Acessado em: 20/09/2011OpenGroup (2011), “Service-Oriented Architecture” Disponível em: http://www.opengroup.org/projects/soa/page.tpl?CALLER=newpage.tpl&ggid=1575 , Acessado em: 20/09/2011MuleSoft (2011), “What is Mule ESB”, Disponível em: http://www.mulesoft.org/what- mule-esb, Acessado em: 01/09/2011BonitaSoft (2011) “Bonita Mule Connector”, Disponível em: http://www.bonitasoft.org/exchange/extension_view.php?eid=117, Acessado em: 15/08/2011Silver, Bruce (2009) “BPMN Method & Style”, Cody-Cassidy PressRigsby, Josette. (2011) “BonitaSofts Open Source BPM Platform Supports CMIS, Cloud Deployments” Disponível em : http://www.cmswire.com/cms/information- management/bonitasofts-open-source-bpm-platform-supports-cmis-cloud- deployments-010071.php, Acessado em: 01/09/2011Dirksen, Jos (2008) “Open-Source ESBs in Action: Example Implementations in Mule and ServiceMix” Manning ( p. 42)

Allweyer , Thomas (2011) “Creating a Simple Business Colaboration Scenario With a BPMS – Using BPMN 2.0 and Bonita Open Solution”, Disponível em: http://www.kurze-prozesse.de/implementing-a-business-collaboration-with-bpmn- and-bonita/, Acessado em: 15/08/2011Wei, Yi and Blake, M. Brian. (2010) "Service-Oriented Computing and Cloud Computing - Challenges and Opportunities". IEEE Internet Computing,Volume: 14 Issue:6 páginas(s): 72 - 75Vollmer, Ken and Leganza, Gene and Czarnecki, Matt (2009) "Case Study: Using SOA And BPM To Support Enterprise Agility: How A Florida College Used An Integrated Approach To Reach Its Goals", Forrester ResearchRaines, Geoffrey (2009) "Cloud Computing and SOA". MITRE, Relatório técnico número: 09-0743 MTR090026Ricston (2010) “Asynchronous Processing With Mule”, Disponível em: http://www.ricston.com/portal/web/guest/bonita-mule-connector, Acessado em: 15/07/2011

Apêndice AAplicação que se comunica com o Twitter via Mule ESB<?xml version="1.0" encoding="UTF-8"?>//[schema definitions ocultadas] <twitter:config name="twitter" format="JSON" oauthToken="xxxx"oauthTokenSecret="xxx" consumerKey="xxx" consumerSecret="xxx" doc:name="TwitterConfiguration" doc:description="Global Twitter configuration information"/> <flow name="7ebc1f53-2e83-4248-8ea9-73c686c9174a"> <http:inbound-endpoint host="localhost" port="1081" path="updateTwitterStatus"keep-alive="false" disableTransportTransformer="true" exchange-pattern="request-response" doc:name="HTTP" doc:description="Process HTTP request for web service."/> <async doc:name="Async" doc:description="Asynchronous block of execution"> <twitter:update-status consumerKey="xx" consumerSecret="xx"status="#[header:INBOUND:status]" doc:name="Update Status" doc:description="UpdateTwitter status with message."/> </async></flow>Aplicação que se comunica com o Google App Engine via Mule ESB<?xml version="1.0" encoding="UTF-8"?>//[schema definitions ocultadas]<flow name="check_account_serviceFlow1"> <http:inbound-endpoint address=http://localhost:8888 exchange-pattern="request-response" /> <http:outbound-endpointaddress=http://aplicacao.appspot.com#[header:INBOUND:http.request] exchange-pattern="request-response" /></flow>

Apêndice B

http://www.leandrobenitez.com.br	419
http://www.itacanet.com.br	7
http://translate.googleusercontent.com	3

SOA na Prática – Criando uma Aplicação BPMN com Bonita Open Solution, Mule ESB e Google App Engine

by Michel Azevedo on Oct 09, 2011

Accessibility

Tags

Upload Details

Usage Rights

3 Embeds 429

Statistics

SOA na Prática – Criando uma Aplicação BPMN com Bonita Open Solution, Mule ESB e Google App Engine — Document Transcript