Interpretação nativa do código BPEL
Versus geração de código de Java
Recentes implementações da BPEL e da BPML confiaram na geração do código de Java: você escreve o código em BPEL, e um gerador de código traduz automaticamente em um conjunto de classes de Java que são distribuídas em uma Máquina Virtual Java ou em um Servidor de Aplicação J2EE. A boa notícia: é uma maneira relativamente fácil para que os fornecedores de um software iniciem o jogo com BPEL. A má notícia: não funciona bem. Assim como o banco de dados Oracle não gera o código de C para executar uma pergunta em SQL, um bom BPMS não deve ter que gerar o código de Java para executar um processo em BPEL.
A geração do código de Java ruim porque a distribuição dos processos mais complexa do que deve ser, cria a descontinuidade semântica do processo, que torna mais difícil a sua depuração e a monitoração em relação à interpretação nativa, e finalmente, deixa tudo mais lento.
As coisas começam mesmo a ficar ruins quando tais execuções confiam e um componente do modelo EJB para persistir os dados dos processos, especialmente quando Entity Beans com Container-Managed Persistência são usados. Para que trabalhe em uma grande escala o governo holandês, acima já mencionado, está rodando 250 milhões de processos concorrentes simultâneos que tem até cinco anos para terminar em uma máquina com 4 CPUs - BPM 2.0 deve interpretar de forma nativa o código de BPEL 2.0, idealmente através da compilação no momento do bytecode muito próximo da semântica Pi-Calculus, e renunciam o uso de todo o componente de EJB para o persistência, confiando no canal direto de conectividade com o banco de dados. Se você necessitar o desempenho e escalabilbidade, você deve ir para este modelo.
Mas por que a interpretação nativa de BPEL importa? Quando você é um fornecedor do software e você investiu dez se não as centenas de homen/ano no desenvolvimento de algum motor processos proprietário, acaba muito tentado em adicionar uma camada simples da tradução que faça a rodar código BPEL que seu motor possa digerir. Os clientes devem passar longe de tais soluções, porque criam mais problemas do que soluções.
Algumas edições descritas no artigo original em BPM 2.0, considerações adicionais são apresentadas. Primeiramente, traduzir BPEL em outra linguagem proprietária cria a tentação de modificar o código executável nesse nível, que adiciona uma terceira camada debaixo de BPMN e de BPEL, e faz a tarefa duas vezes mais difícil que ele deve ser. Para manter coisas simples, BPMN deve ser colocado em série em uma maneira canônica usando tecnologias tais como o MOF ou o EMF, a seguir ser traduzido no código de BPEL no tempo da distribuição. Isto é muito melhor que as ferramentas de desenvolvimento para bancos de dados do cliente servidor tem trabalhado usando UML e SQL ha anos, e as ferramentas de desenvolvimento de processos não são muito diferentes nesse respeito.
Além disso, não adotar um modelo nativo da execução de BPEL cria uma má combinação de impedância entre a semântica da execução do processo definida pela BPEL e a suportada pelo servidor executável proprietário. Na maioria de casos, isto conduz ao desenvolvimento dos motores de processos que suportarão somente um subconjunto da especificação BPEL, ao adicionar algumas características extras que requerem extensões proprietárias. Se você investir em padrões da indústria, será plano e simples.
Adicionalmente, os fornecedores que inventaram sua própria linguagem e construíram a suporte para ele dentro de sua ferramenta de modelagem de processos e de seu servidor de execução de processos tem geralmente uma base dos clientes legados para cuidar. Se a estratégia da migração for suportar linguagens dentro da ferramenta e do servidor executável, o esforço de engenharia necessário será pelo menos quatro vezes mais significativo que suportando uma única linguagem da execução. Em conseqüência, é muito provável que as necessidades de clientes legados prevalecerão sobre as necessidades de novos clientes em perspectiva, e o suporte para BPEL será pobre no melhor dos casos.
Como ele ou não, BPEL é uma linguagem muito poderosa, contudo extremamente complexa, e suportá-la não é uma tarefa simples. Se você fosse um fornecedor de BPM e se encontrasse na posição onde os clientes estão solicitando, eu recomendaria fortemente que você o abrace inteiramente e migre seus clientes existentes a um produto da nova geração que execute a suporte nativa para a especificação, e nada mais. E se você for um usuário final, meu conselho é ainda mais radical: não considere usar nenhum produto que não for construído nativamente em torno de BPEL, porque você pagará o preço de não ser compatível com o padrão no futuro.
