A integração BPMS e SOA

: : www.mundoj.com.br : :
Glauco dos Santos Reis
([email protected]): é bacharel e mestrando em Ciências da Computação.
Trabalha com Java desde 1996 e é especialista em orientação para objetos,
utilizando linguagens OO há mais de 24 anos (C++ e Java). Tem as certificações SCJP
1.1 e 1.5, SCWCD 1.4, e é certificado em Websphere pela IBM. Atuou em dezenas
de projetos Java, SOA e BPM, e tem mais de 160 artigos publicados em revistas
do segmento de informática. É especialista em BPM e publicou um livro sobre a
notação BPMN (www.glaucoreis.com.br). Também é mantenedor do site PortalBPM
(www.portalbpm.com.br), que trata dos assuntos SOA, BPM, BPMS e CEP. Atuou
na criação da arquitetura e implementação da primeira solução CEP do mercado
nacional. Atua como consultor em projetos e implantação SOA e de soluções BPMS.
A integração BPMS e SOA
Como o SOA se integra com BPMS?
Atualmente existe um rico arsenal de
ferramentas que favorecem o aumento
de produtividade no desenvolvimento de
sistemas, muitas delas sob a denominação
de soluções SOA e/ou BPM. Quando
são apresentadas ao negócio, quase
sempre são aceitas e incorporadas como
ferramentas corporativas, não partindo de
uma decisão de TI, mas sim uma solução
de negócio que a TI deve suportar. Isso faz
com que os desenvolvedores precisem se
adapatar a esta nova realidade, tendo que
assimilar estas novas tecnologias e atender
aos requisitos dos sistemas. Vamos explorar
o que significa a mudança para este novo
paradigma SOA/BPM nas empresas, e
como esta subdivisão deve acontecer.
44
uase todas as grandes empresas de software comercializam
hoje no mercado soluções BPMS e SOA. Elas utilizam a
ideia de aumento de produtividade baseada em geradores de códigos, que acabou ficando popular no Brasil lá pela década
de 80, com as ferramentas geradoras de código e posteriormente as
soluções RAD. Infelizmente, naquela época, os avanços da OO, componentização e paterns não eram tão populares e as soluções acabavam
por gerar códigos ineficientes e de difícil manutenção. O processo de
amadurecimento deste tipo de gerador de códigos fez com que hoje
fosse possível a construção de aplicações de produtividade, e por isso a
ideia retorna ao cenário atual. Na verdade, este tipo de solução costuma
ser chamada de DSL (Domain specific Language), um termo bastante
explorado por Martin Fowler. Uma DSL é uma linguagem para um
domínio específico, mantendo características que aumentam imensamente a produtividade no nicho para o qual ela foi criada. Talvez a
mais conhecida linguagem DSL seja o Cobol. Neste quesito, ferramentas programáticas como o Mathematica e Matlab também poderiam
ser consideradas DSL. Muitas vezes engenheiros e matemáticos têm
dificuldades na manipulação de linguagens de programação. O que
as DSL fazem é trazer a programação para um linguajar mais próximo
do domínio destes profissionais. Como este profissional normalmente
sabe resolver o problema específico do domínio (calcular uma estrutura de concreto, por exemplo), ele acaba solucionando o problema com
uma linguagem DSL, sem o auxílio de um programador. Normalmente
os programadores não dominam o conhecimento do negócio, e isto é
tão verdade quanto mais profundo for o conhecimento do programador na linguagem. Ou seja, é muito difícil encontrar um programador
com profundos conhecimentos em Java e sua diversidade de APIs, e
também com conhecimentos específicos sobre o mercado financeiro,
de capitais, engenharia ou outro qualquer. O conhecimento específico
vai sendo adquirido com o tempo de experiência no domínio em ques-
tão, e normalmente quanto mais este conhecimento se destaca, mais
longe da programação o profissional acaba por se posicionar. Ou seja,
conhecimentos específicos são mais valorizados do que conhecimentos genéricos (se é que podemos considerar dominar uma linguagem
de programação com a complexidade do Java como genérico). Mas
o que eu quis dizer neste caso é que utilizar STRUTS é o mesmo em
qualquer empresa. Os mecanismos são os mesmos, e um programador
que souber programar bem em Struts o faz em qualquer ambiente. Já
um profissional que conhece como funciona o mercado financeiro, por
exemplo, é mais escasso (até pela limitação do número de empresas
neste segmento) e acaba sendo mais valorizado. É neste sentido que
se aplica o genérico. No caso dos DSL, é como que o oposto de uma
linguagem de uso geral, como o Java e o C++, que mantém uma abrangência grande, sem uma especialização em um domínio específico. Eles
costumam resolver problemas específicos, como a modelagem e execução de processos de negócios, no caso de uma solução BPMS. Poderíamos imaginar que Java seria um DSL, já que mais de 90% do mercado
a utiliza para construção de aplicativos Web. Na verdade o que faz o
Java ser popular para aplicativos Web não é a linguagem em si, mas sim
a integração entre os servidores de aplicação e um framework de mais
alto nível (as APIs de Servlets e JSP), que proporciona um conjunto
de alta produtividade para este tipo de aplicação (muito maior ainda
se considerarmos frameworks como Struts e JSF). Neste artigo, vamos
mostrar como a implementação do SOA está atrelada ao uso de um
BPMS e aos desafios que os programadores deverão enfrentar para se
adequar a este novo paradigma.
evolução da tecnologia, já que ciclos de treinamento seriam necessários para preparar os desenvolvedores a cada nova solução que fosse
utilizada. O histórico também demonstrou que o uso de soluções
proprietárias tendia a ser um problema, quando o fabricante da solução evoluía sua arquitetura.
O realinhamento rápido do negócio
Por exemplo, pode-se armazenar o desenho em alguma variação de
XML, sendo a mais famosa e utilizada o BPEL. O BPEL é uma linguagem DSL, já que permite a orquestração de serviços em um nível
mais alto de programação, e poderia ser desenhado por especialistas
com conhecimentos mais próximos ao negócio. Entretanto, como é um
padrão formal para execução, têm regras rígidas sua criação, e muitas
das representações que poderiam ser modeladas em BPMN não têm a
contrapartida em BPEL. Ou seja, ou se utiliza o set completo BPMN e
um formato para armazenamento proprietário, ou a opção é armazenar
em BPEL, que é apropriado para execução, mas limita as variações do
desenho a ser criado. Este é um dos desafios que se tenta superar neste
momento. A solução da IBM utiliza uma extensão do BPEL (BPEL4People) que agrega o elemento humano como parte do desenho. No
caso do Oracle BPM, por exemplo, o padrão utilizado foi o XPDL (veja
figura 1). Este é um padrão que permite um leque de representações
muito mais amplo, mas a um custo mais alto. O XPDL representa
os elementos visuais e sua dimensão na tela de forma padronizada,
mas permite que outros elementos sejam agregados, extendendo-se
a notação com particularidades que o set padrão não contempla. Foi
exatamente o que a Oracle fez. Agregou outros elementos que fazem
com que a execução do fluxo fosse possível no seu contexto. Com isto,
outras ferramentas de desenho que conseguem visualizar a notação
XPDL têm difuldades em ler e escrever um arquivo para a solução da
Oracle. O programador deve desenhar os fluxos na ferramenta que o
próprio fabricante disponibiliza.
Existe uma premissa (um tanto quanto subjetiva), normalmente atribuida às soluções BPMS, que é permitir algo chamado de realinhamento rápido do negócio, o que acontece quando temos um mercado competitivo, estratégias agressivas de vendas e de marketing que forçam a
mudanças nos sistemas. Grandes lojas de varejo, por exemplo, estão
constantemente competindo pelos mercados. Isto acontece na forma
de promoções que alteram a forma de negociação durante um período
muito curto de uma promoção, retornando logo após ao funcionamento normal, até que uma nova campanha seja aplicada. Metodologias
tradicionais demandam grandes períodos de análise e redesenho, para
alterações de durabilidade muito curtas. O retorno ao estado original
também demanda um ciclo de desenvolvimento e testes que também
demanda tempo. Os ciclos longos de desenvolvimento, proporcionados pelas metodologias tradicionais, como RUP, não se aplicam nestes
casos, pois demoram a surtir efeito. A demora na geração de resultados
fez surgir um conjunto de técnicas e metodologias mais recentes, como
as metodologias ágeis e scrum, que prometem resultados mais rápidos
sem perda na qualidade. Esta é uma premissa de uma solução BPMS,
ou seja, gerar resultados rápidos em prazos mais curtos. Na verdade, a
maneira como se atinge este objetivo é diferente nos dois casos. No caso
das metodologias ágeis, se buscam formas de tornar os artefatos mais
simples, ou aumentando a comunicação entre as pessoas. Por outro
lado, a abordagem das soluções BPMS é criar representações gráficas
que facilitam alterações, tornando o processo de criação e manutenção
algo visual e, portanto, mais rápido. Na maioria das vezes, o que se
tenta fazer é criar soluções nas quais muito pouco código precise ser
criado, e a maioria das tarefas seja feita com o arrastar de imagens e
conexões de linhas na tela.
Uma vez que a aceleração na geração de resultados é conseguida através
de algum artefato normalmente visual, houve um estudo no sentido
de produzir e amadurecer algum padrão que fosse qualificado para a
representação de processos de negócios, e que ainda fosse padronizada
entre os fabricantes. Embora possamos utilizar diagramas de atividades
para representação de fluxos de negócios, se mostrou necessária a criação de um artefato específico e mais adequado para a representação de
todo tipo de situação, que é a notação BPMN. Esta notação pode ser
vista como um superset dos elementos gráficos existentes em um diagrama de atividades da UML, e este provavelmente foi utilizado como
base para sua criação. Infelizmente, embora a representação visual das
soluções BPMS sejam hoje relativamente padronizadas (quase todos
migraram ou estão migrando para o BPMN), o formato de armazenamento ainda não é. É verdade que hoje se trabalha na especificação
BPMN 2.0, cujo principal diferencial é a criação de um padrão universal de armazenamento. Todos os fabricantes deverão suportá-la quando
estiver consolidada. Isto vai favorecer a migração de aplicativos entre
as soluções BPMS. O problema não é tão simples, já que este não é o
único artefato necessário para descrever completamente um desenho
de processo que se pretende executar.
Sobre o BPMN (Business Process Modeling
Notation)
Figura 1. Desenho de processos no OBPM.
Nas versões mais antigas das soluções BPMS, cada fabricante optou
por criar uma notação para o desenho que tivesse adequação com
a implementação da própria ferramenta, gerando ferramentas de
desenho específicas por produto. Isso repercutiu negativamente na
De uma forma mais clara, o BPMN é apenas uma representação gráfica,
e permite uma riqueza no desenho que não é acompanhada pelo BPEL
ou qualquer formato de execução atualmente conhecido. O BPEL, por
45
: : www.mundoj.com.br : :
outro lado, é um formato apropriado e com rigidez necessária para
execução, mas tem estruturas definidas e que não permitem muita
variação. Já o XPDL é mais abrangente e permite a representação de
todo o BPMN, mas sua definição agrega extensões que torna difícil a
leitura por várias soluções, já que cada fabricante implementa estas
extensões de uma forma diferente, além de não ser apropriado para
execução (embora a Oracle tenha implementado esta característica
neste formato).
Como as soluções BPMS resolvem estas
questões
Como dito no caso do Oracle BPM, a escolha foi pelo XPDL enquanto
que o IBM utiliza o BPEL4WS. Na verdade, o problema da notação e
representação do fluxo de processos é apenas um dos problemas que
devemos enfrentar quando pretendemos ter uma solução que execute
como um programa. O BPMN apenas representa a sequência de passos
para execução de um processo. Um programa ou processo para ser
executável ainda precisa de telas, informações, acessos a serviços remotos, regras de negócio etc. Aqui realmente não existe consenso entre
os fabricantes. Cada fabricante acabou adotando uma abordagem para
suprir o BPMN com um conjunto de artefatos auxiliares que representam cada um destes aspectos citados.
A IBM tem uma visão mais voltada para isolamento entre o perfil criador de códigos e o perfil orquestrador. As ferramentas utilizadas pelo
desenvolvedor de serviços são programáticas e não escondem particularidades da linguagem de programação (Java, claro). A ferramenta
para orquestração dos serviços, ainda está dividida em dois perfis,
sendo um para desenho puro e outro mais próximo da execução, com
elementos específicos do BPEL. O ponto positivo desta abordagem é
uma divisão de papéis mais clara, que tem como ponto negativo uma
estrutura de TI maior, com papéis específicos para cada atividade. Já
no caso da Oracle (estamos falando do OBPM, já que frequentemente
os fabricantes têm mais de uma solução BPMS adquirida ao longo do
tempo) ao menos na versão atual, se tentou criar um ambiente de mais
alto nível que tivesse a representação tanto do fluxo em BPMN quanto
elementos visuais que tornassem possível a criação de telas e objetos
de informação. Isto tornou a ferramenta trivial na utilização, mas que
obriga grandes esforços por parte dos programadores, quando se deseja
características mais avançadas no sistema. Como a ferramenta de desenho é única e simplificada, certas atividades que deveriam ser simples,
como a criação de uma página JSP customizada ou a depuração de um
fluxo de processos acabam sendo bastante difíceis.
Este conjunto de arquivos e/ou códigos criados são exportados para
uma plataforma de execução (um motor que faz efetivamente a execução dos fluxos). Neste processo de publicação, muito dos elementos
representados em XML são convertidos para classes Java (que ficam
escondidas e não podem ser alteradas) para facilitar a execução do desenho. Esta característica torna este tipo de produto muito interessante.
Como a publicação é feita em um formato intermediário, o servidor
tem a liberdade de criar versões distintas da execução (as classes podem
ter nomes diferentes). E ainda várias versões podem estar em execução
de forma concorrente. Isto seria complicado de implementar, e principalmente gerenciar em Java para Web, pois implicaria a existência
de classes diferentes. Este tipo de implementação é contemplada em
orientação para objetos através de patterns como State, Decorator,
Proxy etc., mas demandam maior análise, e o código que irá receber o
pattern precisa ser identificado e preparado para recebê-lo. Na maioria
das vezes, não se tem esta visibilidade, e qualquer código é candidato a
se modificar com o tempo.
Embora seja uma vantagem, provavelmente esta é uma das fontes de
reclamações por parte dos programadores java, pois se tem acesso
apenas aos códigos intermediários, e não aos códigos finais. Normal46
mente as ferramentas de depuração neste tipo de implementação são
limitadas. É difícil colocar break points ou mesmo saber por que o
código não está executando corretamente. Com frequência o programador é obrigado a compreender os códigos gerados pela solução, e
até mesmo desassemblando-os para poder depurar efetivamente. As
soluções BPMS fazem com que o processo de criação seja algo limitado,
reduzido ao arrastar de componentes sobre um desenhador visual. O
processo criativo de sistemas orientados para Objeto, com definição de
padrões e códigos reaproveitáveis desaparecem sob uma implementação visual, o que de certa forma proporciona também a velocidade
de prototipação desejada (isto pode ser discutível). Mas anteriormente
utilizamos o discurso de que a linguagem DSL permite que usuários de
outras áreas se tornassem programadores. Isto infelizmente parece não
estar acontecendo com as soluções BPMS.
Linguagens como o VBA (Visual Basic for Applications), que foi originalmente criada para que os usuários comuns de planilhas tivessem
um poder programático à sua disposição, na realidade acabaram criando novos nichos de programadores (que o usuário final contrata para
fazer os códigos). O mesmo parece acontecer com os desenhadores de
fluxos das soluções BPMS. Normalmente um programador vindo do
mercado Java acaba trabalhando em conjunto com um especialista em
modelagem, e a atividade de programação, que no Java seria algo rico,
acaba por ser algo limitado a um desenhador visual com regras fixas.
Por outro lado, qualquer solicitação que saia do domínio de atuação da
ferramenta acaba por ser imensamente complicado de se implementar
utilizando a solução BPMS, sendo muitas vezes mais complicado do
que seria se o sistema fosse totalmente em Java, causando grandes
esforços de programação para proporcionar contornos que a solução
não possue nativamente.
Como isto se encaixa com SOA?
Se as soluções BPMS são o nicho de trabalho dos profissionais mais
próximos ao negócio, o SOA por outro lado é onde as atividades de
programação acabam acontecendo (embora existam também soluções
SOA que tornam o desenvolvimento de serviços puramente visual).
Cada uma das atividades de um desenho BPMN irá acionar um ou
mais serviços e estes, por sua vez, talvez sejam codificados em Java. Na
verdade, como a interface entre o desenho e os códigos acaba sendo
um XML, os serviços podem ser criados em qualquer linguagem de
programação que se deseje. E ainda há um desacoplamento entre a
camada de serviços e a orquestração dos serviços em si. Desta forma,
a TI pode se encarregar da criação de serviços, que normalmente se
procura que sejam o mais genérico possível, enquanto que o negócio
orquestra a chamada destes serviços gerando produtos que são mais
ágeis na criação e refatoramento. Bom, na prática, tanto o SOA quanto
as soluções BPMS parecem se aproximar da orquestração. Normalmente orquestrações de mais alto nível (aquelas que envolvem usuários no
processo) acontecem nas camadas BPMS, entretanto serviços mais
complexos podem ser criados pela chamada em sequência de outros
serviços. Este mecanismo normalmente acaba recebendo o nome de
coreografia, e cria alguns transtornos entre a TI e a camada de negócios. Isto porque se reduz a visibilidade do negócio. Uma alteração em
uma coreografia pode fazer com que um processo publicado apresente
problemas, embora nada tenha se alterado em termos de desenho, ao
menos o desenho que o negócio visualiza. Isto tudo na teoria é muito
interessante, e provavelmente estamos próximos de conseguir estes
efeitos com a atual evolução das ferramentas. A questão é como contornar os problemas das soluções atuais, de forma a continuar mantendo a
agilidade na criação. Na verdade, as soluções BPMS atuais não obrigam
a adoção de SOA para sua implantação. Mas se uma empresa estiver
madura em relação ao uso do SOA, a implantação acaba se tornando
mais simples. O mesmo pode-se dizer em relação ao SOA. A implantação do SOA não precisa visar a utilização de uma solução BPMS para
orquestração. Mas é uma preparação natural para sua implementação.
Quem toma a decisão?
Uma questão não tão óbvia, é que se a TI implementa serviços reutilizáveis e genéricos, como as decisões ao longo do processamento são
tomadas? Afirmamos que o desenho do processo deveria ser o mais
genérico possível, e preferencialmente com poucos elementos programáticos. Bom, aqui temos algumas possibilidades.
Algumas soluções procuram reduzir ao mínimo a geração de códigos
do lado BPMS, e entre as soluções que fazem isto estão principalmente
aquelas que utilizam BPEL (as decisões são mais simples, basicamente
aquelas proporcionadas pelos XMLSchemas). A maior parte das decisões acontece do lado serviço, ou melhor, dentro da implementação do
serviço, que fica sob controle da TI. Isto pode ser uma desvantagem, já
que nas regras do TI a história tem mostrado que a agilidade é menor
na tomada de decisão (também pode ser discutível). Como se pretende
agilidade, quanto maior for o controle estas regras também não ficam
visíveis no desenho de processos, que é o artefato que o negócio consulta. Como a decisão fica implementada como parte dos serviços, os
ciclos de desenvolvimento acabam se tornando mais demorados. A
vantagem desta abordagem é uma clara divisão entre papéis.
Mas existem também soluções que levam a capacidade de geração de
códigos para o mundo BPMS, que é o caso do Oracle BPM. Nele foi
incorporado um engine de scripts que permite a criação de códigos
atrelados ao desenho do processo (figura 2). Estes scripts permitem manipular dados retornados pelos serviços e efetuar tomadas de decisão,
inclusive alterando dados e reenviando às camadas de serviços. Como
principal vantagem está a praticidade e maior controle da decisão nas
camadas de negócios. Por outro lado, exigem um conhecimento maior
de programação, o que deveria estar distante do negócio. Uma desvantagem desta abordagem é que os desenhos de processos e os serviços
acabam ficando mais acoplados, ou seja, alterações nas informações
retornadas pelos serviços podem exigir refatoramento dos desenhos de
processos. Atualmente a Oracle trabalha na nova versão de sua suite
que deve estar disponível em alguns meses. Uma das linhas que parece
ser seguida é cada vez mais desacoplar a camada de serviços da camada
de orquestração, até mesmo desaparecendo com este recurso de scripts
da próxima geração, permanecendo apenas como legado.
Figura 2. Como o OBPM atrela códigos ao desenho de processos.
Bem, e qual é o modelo que resolve a maior parte dos problemas?
Certamente esta resposta ainda não existe hoje, e as ferramentas vão
amadurecendo a cada nova abordagem que se tenta implementar.
ou mesmo influência nestas áreas de negócios, para não funcionar
como uma “fábrica indiscriminada de serviços sob demanda”. Este
certamente seria o pior cenário existente, retirando a inteligência da
área que tradicionalmente têm tomado as decisões em informática. Da
mesma forma, as soluções BPMS deveriam estar 100% sob domínio do
negócio, mas isto também não deve acontecer porque as soluções BPMS
necessitam das áreas de TI para execução. Existe todo um controle de
versionamento, instalação de novas versões, e mais uma série de atividades que a TI já está habituada a lidar no dia-a-dia. A melhor forma
de implementar uma campanha de marketing, por exemplo, precisa
do aval da TI para se tornar assertiva. Creio que o desenho mais realista
de que tenho conhecimento é aquele em que SOA vai aumentando sua
influência quanto mais próximo está da TI (figura 3), enquanto o BPM
tem mais influência quanto mais próximo está do negócio.
Figura 3. Relacionamento entre SOA e BPM em uma corporação.
Na verdade a influência (ou relevância) do SOA se reduz quando
caminhamos para as áreas de negócio e a influência das soluções
BPMS diminuem quando caminhamos para as áreas de TI. Nunca
nenhuma das duas é completamente independente da outra.
Considerações finais
Como seria de se esperar, os processos evolutivos das linguagens de
programação estão fazendo com que cada vez menos programação
seja necessária. Inicialmente, os programas eram criados em Assembly.
Com o advento das linguagens descritivas, de mais alto nível, como
Cobol, Fortran e ADA, os programadores aprenderam linguagens de
mais alto nível. Isto não tornou os sistemas mais simples de serem codificados. Na verdade as regras ficaram mais complicadas. Nem as APIs
e frameworks de mais alto nível tornaram as atividades mais simples
ou demandando menor quantidade de programadores. Mas cada vez
mais a linguagem Java será utilizada como infraestrutura de criação dos
produtos, e menos codificação de sistemas. Na maioria das situações,
teremos que lidar com editores gráficos que irão abstrair a implementação na maioria dos casos. Continuar insistindo nos modelos atuais
de implementação seria o mesmo que implementar uma folha de
pagamentos hoje em assembly (totalmente inviável). O plugin WTP do
eclipse, por exemplo, permite uma grande parte das atividades de codificação de um aplicativo Web com pouco acesso aos códigos. Soluções
específicas dos fabricantes aumentam ainda mais este patamar. Entretanto, quando uma destas soluções inevitavelmente falhar, as pessoas
que tiverem conhecimento profundo das bases de funcionamento do
+BWBFTUBSÍPNBJTBEBQUBEBTBSFTPMWFSPTQSPCMFNBTt
SOA é atrelado ao negócio ou à TI ?
Bem, esta é uma discussão que normalmente gera polêmica. Parece-me
que se seguirmos a linha de pensamento deste artigo, SOA está muito
relacionado à TI. Mas como a abordagem do SOA proporciona uma
criação de serviços mais genéricos, e que atendam a várias demandas
de várias das áreas de negócios, a TI precisaria de algum conhecimento
Referências
http://www.oracle.com/us/technologies/bpm/index.html
http://www-01.ibm.com/software/br/websphere/info/bpm/
http://www.bpmn.org/
http://www-01.ibm.com/software/solutions/soa/
47