BPM sem BPEL Parte 2

No post anterior, escrevi um pouco sobre BPM e bem como andam os padrões que seguem esse modelo, neste post pretendo falar sobre a ligação de BPEL com BPM. Vou citar outras referencias que confiram 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. Se você quiser saber mais sobre SOA pode ler esses posts:
Para maior entendimento desse post, recomendo muito a leitura do post anterior e esses outros posts que fiz sobre BPEL:
Nos posts anterior sobre BPEL falei dos pontos positivos e neste post vou mostrar os pontos negativos do uso de BPEL em conjunto com BPM. Não digo que é de todo o mal a abordagem mas o mercado já salienta diversos problemas os quais alguns 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. Por que SOA vai mexer muito com a TI e BPM vai mexer muito com o negócio.



Você pode realizar uma implantação parcial e 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 aos meus olhos acredito que só aumenta a complexidade e os riscos de se ter sucesso e ROI em curto prazo.

Mas como juntar BPM e SOA?

Na verdade é simples, essa cola pode existir apénas em tempo de análise/design, tudo tem inicio do 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.

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

Esse casamento pode dar divorcio ou até mesmo...
MERDA!!!


Mas com 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% mapeavel do BPM para o BPEL. Se vocês tem suas dúvidas confiram esses outros posts/artigos:
No FAQ do WS-BPEL 2.0 item 4 vocês acharam isso:

  1. What is the relationship between BPMN and WS-BPEL2.0?
    1. 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 gera o BPEL com BPMN se eu conseguir fazer posso não conseguir pegar as mudanças feitas no BPEL para o BPM de volta, que insiste nisso são os grandes players como disse antes ORACLE e IBM, por que?

Eles querem fazer o bom e velho lock-in e prender vocês ao ferramental deles, por sinal o IBM Modeler 6.0 nem implementar BPMN implementa, 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 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 por que as grandes empresas estão jogando nisso, mas o mercado não está comprando, a prova disso é esse gráfico:

Gráfico de tendências do site In Deed

Como vocês podem ver o uso de BPM vem crescendo muito e assim como de forma menor a demande de BPEL mas ainda é grande, agora 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 da no mesmo, isso pode ser feito com um bom ESB como o Apache Service Mix usando o Camel da Apache por exemplo.

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 ira 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 se não é impossível faer 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: http://www.nabble.com/SimPEL-early-feedback-td19380187.html.

O SimPEL é muito novo, é do final de 2008, não sei se evoluiu muito, apareceu na lista de discussão de desenvolvimento do Apache ODE e está em passos de bebe, mas achei muito interessante e gostaria muito de ver as coisas evoluindo para esse lado, o SimPEL é algo tipo isso:

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

Como disse antes não sei se a iniciativa foi para frente, mas é algo muito legal. 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.

Popular posts from this blog

Telemetry and Microservices part2

Installing and Running ntop 2 on Amazon Linux OS

Fun with Apache Kafka