O documento discute a relação entre arquitetura orientada a serviços (SOA) e computação em nuvem, destacando sua relevância para pequenas e médias empresas. Apresenta uma aplicação de conceito desenvolvida com ferramentas open source, como Bonita Open Solution e Mule ESB, para ilustrar essas tecnologias em uso. O estudo também enfatiza a acessibilidade dessas soluções para empresas de diversos tamanhos, permitindo uma adaptação mais ágil em um mercado em constante mudança.

1. SOA na Prática – Criando uma Aplicação BPMN com Bonita
Open Solution, Mule ESB e Google App Engine
1
Michel A. Soares
1
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ção
Até poucos anos atrás, quando se falava em implantar uma arquitetura orientada a
serviços (SOA, da sigla em inglês), mencionava-se que esse tipo de abordagem era mais
adequada para empresas que possuíam grandes sistemas legados. Josuttis(2007) afirma
que SOA é um conceito para grandes sistemas distribuídos. Ele afirma que SOA é uma
técnica para a manutenção desses grandes sistemas. Dessa forma, era natural que se
associasse a implantação desse tipo de arquitetura a grandes empresas. Outros fatores
que 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 caras
eram capazes de oferecer as funcionalidades necessárias para um ambiente de produção
baseado em SOA. A complexidade era outro fator crítico porque a implantação de tais
soluções demandavam um grande esforço e mudanças de paradigmas nas empresas,
portanto, justificando-se apenas para grandes empresas capazes de suportar tamanha
mudança e dispostas ao investimento necessário.
Contudo, a adoção de SOA nos últimos anos entre empresas de diferentes portes
e ramos de atividades tem aumentado. É o que comprova Heffner (2010) no estudo

2. 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 de
crise. O estudo foi realizado em 2009, ano em que a economia global ainda se
recuperava da grande crise de 2008.
No Brasil, em estudo realizado na Universidade de Brasília por Puttini and
Sousa (2011), pôde ser constado que 91.67% das empresas já consideram SOA
importante ou muito importante em sua estrutura de TI e 53.8% consideram que SOA
tem importância estratégica no negócio; 100% observaram, em parte ou totalmente, o
aumento do alinhamento entre TI e Negócio, e também o aumento na reutilização das
aplicaçõ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 advento
da computação nas nuvens (Cloud Computing), soluções SOA passaram a ser mais
acessíveis para empresas de pequeno e médio porte, além de permitir para diferentes
empresas a realização de uma prova de conceito, sem muito custo, o que permite a
avaliação da solução também com menor esforço.
Power (2010) descreve alguns problemas que atingiam pequenas empresas antes
do surgimento da arquitetura orientada a serviços. Segundo este trabalho, essas
empresas sofreram no passado devido ao custo de integração com seus fornecedores de
grande porte, que era muitas vezes proibitivo. Com o advento de SOA, seus parceiros
estão agora aptos a expor serviços que podem ser consumidos por diversas aplicações
que são usadas hoje. Produtos como Excel e Word podem se integrar com os sistemas
de TI dos seus parceiros de uma forma antes inimaginável. Com o advento do Software
como 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 alto
custo ao utilizar apenas uma fração deles e, consequentemente, sendo cobradas apenas
por 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 bastante
propício para implantação desse tipo de arquitetura.
Sezov (2011) aponta algumas vantagens dos projetos que utilizam ferramentas
open 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.

3. A motivação para a realização deste estudo parte do princípio de que podemos
fazer não apenas aplicações complexas, mas também aplicações mais simples. O
objetivo deste artigo é dar subsídios para o entendimento de como podemos iniciar a
implantação de um projeto SOA utilizando apenas ferramentas open source. Para isso,
será desenvolvido um estudo de caso em que será implementado um processo de
negócio utilizando o BPMS Bonita Open Solution. O processo será responsável por
coordenar chamadas a serviços disponíveis em plataformas nas nuvens, como Google
App Engine e Twitter. Esses serviços por sua vez, serão chamados por meio de um ESB
open source, o Mule ESB.
O artigo será compreendido da seguinte forma: na seção 2 temos uma visão
geral de SOA, Computação em nuvem, ESB e BPMS, onde será mostrado como os
conceitos se relacionam. Em seguida, na seção 3, são apresentadas as ferramentas
utilizadas na implementação e dada uma breve explanação de como elas são utilizadas
no estudo de caso. Na seção 4, é apresentado o estudo de caso, em que foi escolhida
uma 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, na
seçã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 BPMS
2.1 SOA
De acordo com Davis (2009), arquitetura orientada a serviços é uma estratégia de TI
que organiza as funções discretas nas aplicações empresariais em serviços
interoperáveis e baseados em padrões que podem ser combinados e reusados
rapidamente 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 suporta
orientação a serviço. Orientação a serviço é uma forma de pensar em termos de
serviç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 a
arquitetura é executada ou expressa. O estilo da arquitetura empregada em SOA tem as
seguintes características:
• É baseado no design dos serviços – que espelha as atividades comerciais do
mundo real – compreendendo os processos de negócios da empresa;

4. • 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 uma
camada de processo / orquestração para mudar os processos de negócios importantes,
sem promover mudanças em todos os sistemas. Esta é uma arquitetura de baixo
acoplamento (Linthicum, 2009). Neste artigo essa camada de orquestração será
executada pelo processo desenhado no Bonita Open Solution (que será apresentado na
seção 4, com o estudo de caso), e a camada “Services” será executada pelo Mule ESB.
2.2 Cloud Computing
Uma definição de Cloud Computing (Computação nas Nuvens, em português) bastante
utilizada é 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 a
um 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 utilizado
na implantação de uma arquitetura orientada a serviços. Recursos como
armazenamento, capacidade de processamento e softwares provendo serviços podem ser
utilizados e pagos sob demanda, além de delegar a responsabilidade de gerenciamento
desses recursos para o provedor de nuvem.

5. 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 entre
sistemas. É também muito provável que esses sistemas não “falem” a mesma língua, ou
seja, não utilizem o mesmo protocolo para se comunicarem. Muitas vezes, não é apenas
a comunicação que é diferente; pode ocorrer que a disponibilidade de uma aplicação
seja diferente do momento em que outra necessite de uma informação. É nesse tipo de
cenário que um Enterprise Service Bus (ESB) pode ser bastante útil.

6. De acordo com Josuttis (2009), em SOA, o ESB faz parte da infraestrutura que
nos permite usar serviços em ambiente de produção. É de responsabilidade dele expor
serviços e deixá-los disponíveis para serem consumidos pelas aplicações clientes. Seu
principal papel é prover a interoperabilidade. Essa sua caracterização se deve pelo fato
de essa camada da arquitetura SOA servir para promover a integração de diferentes
plataformas, serviços, linguagens de programação, além da transformação e do
roteamento de dados, que são algumas de suas principais atribuições. Um ESB deve
permitir a chamada e o recebimento de mensagens de um consumidor para um provedor
de serviço e vice-versa.
2.4 Business Process Management (BPM) e Business Process Management
System (BPMS)
Business Process Management (BPM) está cada vez mais ganhando atenção em grandes
e 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 a
tirarem vantagens competitivas disso. Serve também para proporcionar ao gestor do
negócio uma maior facilidade de encontrar oportunidades de melhoria para o serviço
prestado ao cliente, através de indicadores de resultados. As ferramentas tecnológicas
que são utilizadas para aplicar efetivamente BPM nas empresas são chamadas de
Business Process Management Systems (ou Suites), ou apenas BMPS. Existem várias
definiçõ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érico
que é orientado por representações de processos para coordenar a execução de processos
de 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 numa
ferramenta dessas. As ferramentas open source podem ajudar nesse sentido de auxiliar
no processo de entrada no universo BPM sem grandes investimentos. Até pouco tempo
atrás, não se imaginava essa possibilidade, porque existia uma grande distância entre o
que as ferramentas comerciais implementavam e o que as open source
disponibilizavam. Hoje, as soluções gratuitas já representam uma ótima opção para a
implantação da cultura BPM nas empresas, além de trazer os benefícios intrínsecos do
open source como possibilidade de obter correções mais rápidas da comunidade
mantenedora e das soluções inovadoras muitas vezes disponibilizadas.
3. Ferramentas utilizadas
3.1 Google App Engine
O Google App Engine pode ser classificado como um PaaS e com ele, segundo
Appengine (2011), é possível que aplicações sejam desenvolvidas através de um
framework que facilita a implementação de aplicações em diversas linguagens, como
Java, 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 objetivo
combinar a eficiência de linguagens tipadas e compiladas com as facilidades de linguagens interpretadas
(Pike, 2009).

7. Como é característica de uma nuvem PaaS, abstrai-se a necessidade de
manutenção de servidores e facilita-se o desenvolvimento de aplicações prontas para
executarem em um ambiente de nuvem escondendo os detalhes do programador.
3.2 Twitter
É uma ferramenta online de microblogging que permite compartilhar posts (conhecidos
como tweets) de até 140 caracteres. É definido por Twitter (2011) como uma rede em
tempo real em que é possível se conectar às mais recentes informações sobre o que se
julga interessante.
3.3 Mule ESB
De acordo com Mulesoft (2011), Mule ESB é uma plataforma de integração
desenvolvida na linguagem Java que permite aos desenvolvedores conectar aplicações
de forma rápida e fácil, fazendo com que elas possam trocar mensagens. Ele permite a
integraçã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 se
comuniquem com outras atuando como um sistema de transporte por carregarem dados
entre aplicações e das aplicações para a internet. Mule ESB possui poderosas
funcionalidades, 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);

8. • 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 Solution
Bonita Open Solution, da empresa BonitaSoft, vem sendo chamada de a ferramenta
responsável por democratizar BPM ao disponibilizar funcionalidades antes apenas
vistas em ferramentas comerciais, tornando-a altamente competitiva nesse mercado
(Rigsby, 2011). Lançada em 2009, não demorou muito para ela se popularizar. Em
menos de dois anos, a comunidade atingiu a marca de 3.000 membros, meio milhão de
downloads e 100 clientes. Esse rápido crescimento é atribuído ao forte foco da
ferramenta em usabilidade, facilitando o manuseio por usuários não técnicos.
Carthuatocto (2011) realizou um estudo em que compara algumas das
ferramentas BPMS open source mais populares do mercado. O estudo mostra que
Bonita Open Solution é a solução mais completa quando foram analisados os critérios:
workflow, modelador de processos, criador de formulários, monitoramento de
processos, 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 Caso
Atualmente, é 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 mercadorias
e/ou serviços, estoque, vendas, contas a pagar e a receber etc. Muitas possuem os
chamados 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, seja
pela chegada de um novo parceiro comercial, seja devido à equipe de TI ter julgado
necessária a adoção de uma nova tecnologia, por decisão estratégica da direção da
empresa ou até mesmo por uma fusão.

9. O caso a ser demonstrado abaixo tem como objetivo a simulação de um cenário
muito possível em empresas que estão dispostas a adotar uma solução SOA para
projetos internos. Principalmente para empresas que não se utilizam ou não têm
experiência, ele ilustra uma possível alternativa dando a direção para a criação de uma
prova de conceito com algum processo da empresa, o que permite a avaliação da
arquitetura 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 a
criação de um tutorial de como utilizar as ferramentas utilizadas, e, sim, o de apresentar
os 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 altos
custos. Dessa forma, esse exemplo é uma aplicação simplificada, comparada a uma
aplicação que seria desenvolvida em ambiente de produção. Portanto alguns aspectos
que devem ser levados em consideração em aplicações corporativas não foram
observados, como fatores de segurança, validações das entradas de dados e tratamento
de exceções no processo (situação que será bastante comum nas aplicações dessa
natureza).
Como pode ser observado na Figura 3, a aplicação consiste de um processo
desenhado 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 o
processo, serão realizadas chamadas a serviços que estão sendo executados em
plataforma de nuvem, um deles é um serviço disponibilizado no Google App Engine, e
outro é uma conta no Twitter. As chamadas serão realizadas utilizando o intermédio do
Mule ESB.
4.1. Processo no Bonita
Nesse exemplo, foi escolhido um processo de compra para ser automatizado. O
processo envolve os seguintes atores:
• Cliente: usuário final que usará a interface web para solicitar a compra do
material

10. • 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 processo
contém as tarefas definidas a seguir.
4.2. Criar Pedido
Essa é a primeira tarefa e foi definida para ser atendida pelo “usuário iniciador”
(Initiator) do processo. Quando o processo “Pedido de compra” é executado pela
interface 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 de
acordo 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 no
botão “Enviar”, o processo segue, conforme foi definido no diagrama do processo, para
a próxima tarefa, “Verificar Pendência”.

11. 4.4. Verificar Pendência
Essa é uma tarefa que, de acordo com a notação BPMN 2.0 (Silver, 2009), é chamada
de “Service Task”. Ela é assim chamada por ser uma tarefa automática, sem a
intervenção humana. Comumente, essas tarefas terão associadas a elas conectores. O
Bonita pode se comunicar com diversas plataformas e sistemas via conectores. Essa foi
um das formas que os idealizadores da ferramenta encontraram para permitir que a
comunidade contribua de forma mais ativa e direta para o desenvolvimento da
ferramenta.
Dentro do nosso processo, a atividade “Verificar Pendência” se utiliza do Mule
ESB Conector (BonitaSoft, 2011). Ele possibilita que um processo no Bonita se
aproveite de toda a infraestrutura do Mule ESB. Dessa forma, foi criada uma aplicação
que faz a consulta ao serviço publicado no Google App Engine. Aplicações no Mule são
XMLs 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 o
serviç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-endpoint
address=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, um
serviç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 no
cabeçalho da requisição. Neste caso, foi realizado um simples redirecionamento, mas o
Mule permite o uso de transformadores de mensagens, mecanismos de decisão e
escolha, que poderiam também ser utilizados para incrementar segurança ou escolher o
serviço a ser chamado, dependendo da mensagem que chegar. Uma vantagem de se
utilizar o Mule como intermediário neste ponto, além dos citados, é que, caso a url do
serviço precise ser alterada, por exemplo, ou a aplicação seja movida para outra
plataforma de nuvens, o processo no Bonita não precisaria ser alterado, apenas a
aplicaçã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 a
regra de negócio, no caso, verificar se o usuário possui alguma pendência financeira que
o 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óximo
elemento do diagrama, que é um “Gateway de decisão Exclusivo”. Esse Gateway
verifica se o valor retornado é igual a “ok”, caso afirmativo, segue para “Avisar
Gerente”; do contrário, vai para “Avisar Solicitante de Pendência”.

12. Figura 6. Gateway que decide para onde seguir após consulta ao serviço no
GAE
4.5. Avisar Solicitante de Pendência
Essa atividade existe apenas para avisar ao usuário que ele não pode realizar o pedido
pelo fato de existirem pendências financeiras. Foi criado um formulário com a
identificaçã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 financeira
4.6. Avisar Gerente
Essa 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 do
pedido e posta uma mensagem no twitter usado pelo gerente para acompanhar a
necessidade de aprovar novos pedidos.

13. 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ções
HTTP e encaminha para o Twitter.
Para conseguir a comunicação, foi necessária a geração de alguns parâmetros
pelo próprio Twitter. Após isso, foram configurados no componente os dados para que o
acesso à conta fosse permitido.
Figura 9. Fluxo da aplicação que atualiza o twitter desenhada no Mule Studio
A 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="Update
Twitter status with message."/>

14. 4.7. Aprovar Pedido
Após o gerente ser avisado de que existe um pedido novo para ser aprovado, ele deve
seguir para sua caixa de entrada de pendências no Bonita User XP (Figura 12), onde
poderá 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 (Figura
11), e ele terá a oportunidade de aprovar ou não o pedido. Após a decisão do gerente, o
solicitante do pedido será notificado da decisão na próxima atividade “Notificar
Resultado”.
Figura 11. Tela de aprovação de pedido
4.8. Notificar Resultado
Depois que o gerente toma a decisão na tarefa “Aprovar Pedido”, a tarefa “Notificar
Resultado” 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 o
qual permite fazer a configuração dos dados da conta de email que será utilizada e o
corpo da mensagem (Figura 12). Após o envio do email, o processo é finalizado.

15. Figura 12. Configuração do conector para envio de email
5. Trabalhos relacionados
Wei and Blake (2010) mencionam as dificuldades encontradas pelas empresas de lidar
com as rápidas mudanças exigidas pelo mercado, pelas demandas de seus clientes e as
constantes mudanças nos processos de negócios. Eles trazem uma análise dos desafios
surgidos com o uso da computação em nuvens, a arquitetura SOA e de como as
empresas podem se beneficiar desses dois paradigmas.
Raines (2009) destaca o grande movimento em direção à plataforma de nuvens e
a mudança nas relações entre fornecedores e clientes, com o surgimento desse novo
paradigma. Ele destaca os benefícios e os riscos que devem ser analisados pelos
gestores de TI nesse novo cenário e lembra que SOA e Cloud computing são atividades
complementares e que devem desempenhar papel de destaque no planejamento de TI.
O estudo realizado por Allweyer (2011) mostra um cenário de colaboração entre
dois parceiros que utilizam um BPMS. Ele reforça que é cada vez mais comum a adoção
de 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 nas
aplicações, além de usar também o engine de execução de processos e orquestração. No
cenário, ele utiliza um banco de dados para intermediação de mensagens entre os dois
processos. A utilização do Mule ESB para essa finalidade também é possível com a
utilização de uma fila de mensagens, conforme descreve Ricston (2010).
Vollmer (2009) fala sobre a experiência do uso de SOA e BPM na Florida
Community College, em Jacksonville. Ele destaca o tempo de preparação que a equipe
levou antes de colocar a solução em produção e de como o parceiro ajudou para que os
objetivos fossem atingidos. Ele conclui mostrando que os planos de crescimento da
universidade para comportar mais alunos só foram possíveis devido à estratégia adotada
com a adoção do novo modelo de desenvolvimento utilizando SOA.

16. 6. Conclusão e trabalhos futuros
Como o objetivo do artigo foi o de mostrar como seria possível o desenvolvimento de
uma aplicação SOA utilizando apenas ferramentas open source e dar subsídios para
permitir a criação de uma prova de conceito utilizando um processo de negócio da
empresa, as ferramentas foram selecionadas e utilizadas na criação de um estudo de
caso. 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ços
foram disponibilizados no Mule ESB que, por sua vez, se comunicava com o Twitter e
com uma aplicação disponível na plataforma de nuvens do Google.
A utilização do Bonita se mostrou bastante intuitiva, revelando o que já se
esperava quando da escolha da ferramenta. O uso dos conectores para integração com
serviços e aplicações externas também se mostrou bastante eficiente. A criação de
formulários também não apresentou dificuldades. O gerador só deixa a desejar na
possibilidade de se personalizar o espaçamento dos campos, mas isso pode ser
contornado com a utilização de templates, que permitem inclusive a total remodelagem
da aparência dos formulários. O fato de o designer utilizar, a notação BPMN 2.0
também ajuda bastante, uma vez que o padrão é familiar aos analistas de processos que
vão modelar o processo. É importante ressaltar a importância da escolha de qual
processo automatizar em um ambiente corporativo. A escolha de um processo não
crítico e de baixa complexidade pode fazer grande diferença nas primeiras
implementações.
A utilização do Mule ESB intermediando as chamadas aos serviços pôde revelar
algumas vantagens: na necessidade de alterações dos urls dos serviços, o processo não
precisou ser alterado, apenas o XML da aplicação do Mule. Isso pode ser importante
para evitar o envolvimento desnecessário de analistas de processos nesse tipo de
mudança.
Por se tratar de uma aplicação que utiliza apenas ferramentas open source, a
documentaçã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 uma
ampla base de conhecimento disponibilizada pela comunidade que as utiliza.
Um estudo semelhante com a utilização de ferramentas comerciais seria válido
para a comprovação do benefício da utilização de ferramentas open source. Podem
també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.

17. 7. Referências
Heffner, 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 2010
Sezov, Rich Jr. (2011) “Liferay in Action”. Manning
Linthicum , David S., (2009) “Cloud Computing and SOA Convergence in Your
Enterprise” Addison Wesley
Davis, Jeff. (2009) “Open Source SOA”. Manning
Power, 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/2011
Carthuatocto, 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/2011
Mell, 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/2011
Appengine (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’Reilly
Puttini, 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/2011
OpenGroup (2011), “Service-Oriented Architecture” Disponível em:
http://www.opengroup.org/projects/soa/page.tpl?CALLER=newpage.tpl&ggid=1575
, Acessado em: 20/09/2011
MuleSoft (2011), “What is Mule ESB”, Disponível em: http://www.mulesoft.org/what-
mule-esb, Acessado em: 01/09/2011
BonitaSoft (2011) “Bonita Mule Connector”, Disponível em:
http://www.bonitasoft.org/exchange/extension_view.php?eid=117, Acessado em:
15/08/2011
Silver, Bruce (2009) “BPMN Method & Style”, Cody-Cassidy Press
Rigsby, Josette. (2011) “BonitaSoft's 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/2011
Dirksen, Jos (2008) “Open-Source ESBs in Action: Example Implementations in Mule
and ServiceMix” Manning ( p. 42)

18. 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/2011
Wei, 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 - 75
Vollmer, 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 Research
Raines, Geoffrey (2009) "Cloud Computing and SOA". MITRE, Relatório técnico
número: 09-0743 MTR090026
Ricston (2010) “Asynchronous Processing With Mule”, Disponível em:
http://www.ricston.com/portal/web/guest/bonita-mule-connector, Acessado em:
15/07/2011

19. Apêndice A
Aplicaçã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="Twitter
Configuration" 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="Update
Twitter 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-endpoint
address=http://aplicacao.appspot.com#[header:INBOUND:http.request] exchange-
pattern="request-response" />
</flow>

20. Apêndice B