No artigo anterior, escrevi um pouco sobre BPM e bem como andam os
padrões que seguem esse modelo. Hoje pretendo falar sobre a
ligação de BPEL com BPM. Vou citar outras referências que confirmam a
minha visão de que BPM e BPEL talvez não seja o casamento perfeito.

Quando
falamos de BPMN, BPMS, simulação, estamos falando obrigatoriamente de
BPM. Se falarmos de WS-BPEL, WebServices, WSDL podemos estar falando de
SOA, mas nem sempre. Usar WS-BPEL, WebServices, WSDL não significa ter
SOA.

Para maior
entendimento desse artigo, recomendo muito a leitura do anterior e desses outros textos que fiz sobre BPEL:

• Como
  vamos de BPEL – Parte 01

• Como
  vamos de BPEL – Parte 02 – ODE

No artigo anterior sobre
BPEL falei dos pontos positivos e neste vou mostrar os pontos
negativos do uso de BPEL em conjunto com BPM. Não digo que é de todo mal a abordagem, mas o mercado já salienta diversos problemas, e alguns eu vi na prática.

O
Casamento de SOA com BPM

BPM é negócio, é o fluxo da sua
empresa, é gestão de processos, SOA é arquitetura corporativa, ou pelo
menos uma parte dela, focada em serviços. Serviços estão relacionados a
processos, então BPM e SOA são feitos um para o outro? Em alguns casos
essa abordagem pode ser muito produtiva, implantar os dois do zero pode
ser um grande risco, porque SOA vai mexer muito com a TI, e BPM vai
mexer muito com o negócio.

Você pode
realizar uma implantação parcial, primeiro colocar BPM e depois disso
ir para SOA, para mim é o melhor cenário. Não digo que seja impossível
colocar os dois ao mesmo tempo, mas acredito que só
aumentam a complexidade e os riscos de se ter sucesso e ROI em curto
prazo.

Como juntar BPM e
SOA?

Na verdade é simples, essa cola pode existir apenas
em tempo de análise/design. Tudo tem início no processo da empresa, do
fluxo; desse fluxo se derivam aplicações, serviços, sistemas legados,
sistemas de terceiros, tarefas manuais do negócio, tarefas manuais da
TI etc.

Tudo isso pode ser controlado com uma boa ferramenta
de metadados. Um exemplo é o ORACLE Design, que não deixa de ser uma
ferramenta de metadados para o banco ORACLE. Você pode fazer esse
sistema com meia dúzia de cadastros, ainda é possível usar algum sistema
de gestão de assets.

Porém, essa não é a única abordagem. Existe
outra vertente que é até defendida por grandes players como IBM e ORACLE, de gerar o BPEL a partir de um diagrama de processo do BPM.

Esse
casamento pode dar divórcio ou até mesmo coisa pior (acredite!).

Qual o problema dessa abordagem?

Se existisse
só um problema eu não estava falando disso :). São vários os problemas…
primeiro é que um processo BPM pode não ser 100% mapeável do BPM para o
BPEL.

No FAQ do
WS-BPEL 2.0 item 4, é possível encontrar isto:

What is the relationship between BPMN and WS-BPEL2.0?
There
is no direct relationship between BPMN and WS-BPEL 2.0. WS-BPEL
is a standard from OASIS and the BPMN specification is currently
an OMG standard for visual representation of Business processes.

Em
resumo, não existe relação direta de BPM e BPMN para BPEL, são padrões
diferentes, de empresas diferentes, com propósitos diferentes. Ainda
existe o grande problema de ‘round-trip’, ou seja, se eu gerar o BPEL com
BPMN, se eu conseguir fazer, posso não conseguir pegar as mudanças feitas
no BPEL para o BPM de volta. Quem insiste nisso são os grandes players,
como disse antes, ORACLE e IBM, por quê?

Eles querem fazer o bom e
velho lock-in e prender vocês ao ferramental deles. Por sinal, o IBM
Modeler 6.0 nem implementa BPMN.

Voltando a falar de BPEL,
existem outros problemas sérios no uso de BPEL:

• Tudo é
  WebService, WDSL, XML, XPATH pra todo o lado
• Desenvolvimento
  pesado e complexo
• Problemas de performance e dimensionamento de
  máquinas
• Impossibilidade de forma portável de acessos mais leves

Vou
explicar esse último item. Como dito antes, o BPEL tem problemas de
performance por ser tudo WebServices, xml, etc… Uma solução seria
acessar os serviços ou os tasks através de uma mera classe java ou um EJB
ou um bean do Spring. Isso é possível na IBM, por exemplo, através do uso
de SCA, mas isso é feito no BPEL através de extensões; logo, perdemos a
portabilidade, e mais uma vez a IBM fez o lock in de novo e você está
preso aos caras.

E o Pega
Gerente?

Esse é o problema. Todo esse papo furado de gerar
o BPEL pelo BPM é algo que os gerentes adoram, ou seja, uma solução
mágica que, com ferramentas, vai eliminar, erros, descuidos, dar
flexibilidade e até tirar o peso da responsabilidade das pessoas. É um
mundo mágico que infelizmente não existe. Existe apoio dos gerentes, porque as grandes empresas estão jogando nisso, mas o mercado não está
comprando, a prova disso é este gráfico:

Gráfico
de tendências do site Indeed

Como
vocês podem ver, o uso de BPM vem crescendo muito, assim como, mas de forma
menor, a demanda de BPEL. Quando olhamos as duas
coisas associadas, que seria a linha verde, vemos que isso é muito
pequeno. BPEL pode ser usado, mas tem que existir um cenário que
justifique muito isso e, de preferência, com uma boa solução como o Apache
ODE, e usando o SOA Tools do eclipse, que são ferramentas open source
para BPEL.

Alternativas ao
WS-BPEL

Muitas vezes, uma alternativa viável e
simples é, ao invés de fazer orquestração, fazer roteamento de serviços. Não resolve 100% dos casos, mas em alguns casos dá no mesmo. Isso pode
ser feito com um bom ESB, como o Apache Service Mix usando o Camel da
Apache.

Uma idéia que me agrada muito é,fazer
orquestração de forma padronizada, assim como no BPEL, mas usando formas
mais leves como interfaces java, ejbs, beans do Spring, apis REST, mas
tudo isso de forma padronizada por alguma especificação. Mas nada indica
que esse caminho irá surgir fora das extensões.

BPEL em DSL?

Essa seria uma
coisa ótima, usar BPEL com schema XSD, xml e WSDL é algo muito ruim,
muito pesado, que cria uma dependência muito forte com um ferramental, senão é impossível fazer algo que preste com o mínimo de produtividade.

Ouvi
falar do SimPEL que seria um BPEL simplificado em forma de DSL, espero
que isso vá para frente, confiram isso neste link.

O
SimPEL é relativamente novo, é do final de 2008. Achei muito interessante e gostaria muito de ver
as coisas evoluindo para esse lado, o SimPEL é algo assim:

process HelloWorld {
    receive(myPl, helloOp) { |msgIn|
        msgOut = msgIn + \" World\";
        reply(msgOut);
    }
 }

Mesmo com isso ainda não temos a tão sonhada cola do BPM com o
BPEL e não vamos ter isso com ferramental nenhum, certas coisas ainda
devem ser feitas da maneira antiga, com ferramentas, sim, com pessoas e o
bom e velho processo.

Abraços a até a próxima.