A velha questão... BPEL modelando processo?

A um pouco mais de um ano participei de um projeto onde foram experimentados 3 produtos de BPM/SOA onde lutávamos para atender os requisitos de nosso cliente, basicamente eram o Sun JCAPS, o projeto OpenESB da Sun acompanhado do BPEL Service Engine + NetBeans SOA Plugin e o desconhecido Savvion. O JCAPS, na época, no Enterprise Designer modelávamos processos utilizando BPEL 1.0 com uma notação visual própria, da ferramenta fundamentalmente nosso projeto sofria com o fato do cliente exigir que o processo, na sua notação visual, utilizasse a representação BPMN. O NetBeans por sua vez esbarrava no mesmo problema, modelava BPEL com uma notação visual bem distante do que o cliente desejava oferecer para seus analistas de negocio. E por fim o Savvion oferecia uma plataforma muito amigável ao analista de negocio, contudo bastante distante de um tradicional modelador BPEL.

Muitas pessoas acreditavam que os elementos da semântica BPEL poderiam representados visualmente pelos elementos BPMN e assim atenderiam aos requisitos exigidos pelo cliente, a experiência deste projeto levou-me a perceber que isso é um grande equivoco e o contato na época com o Savvion confirmou minhas expectativas. O Savvion trabalhava com uma notação visual BPMN, uma modelagem simples, extremamente focada na necessidade de um analista de negocio, e com código sendo gerado em XPDL. Eu sei que é difícil levar alguém, principalmente uma pessoa altamente focada em tecnologia a compreender que so porque BPEL modela blocos lógicos de orquestração de serviços este é ou não melhor para modelagem de negócio, contudo o que venho a perceber que BPEL é ótimo para desenvolvimento de serviços compostos, ou seja, orquestração de serviços para a composição de serviços de alto nível, modelados e construídos com enfoque SOA e não enfoque de processo (processo de negocio), claro que tais serviços tem como rastreabilidade em requisitos de um processo desenhado por um analista de negocio, mas estes em si não são modelados em função do negócio mas como um bloco lógico de alto nível para atender a diversos processos de negocio, ou seja, um fragmento de código reutilizável.

Então depois de muito quebrar a cabeça com o que o cliente desejava e o que poderíamos oferecer diante dos produtos que tínhamos disponíveis chegamos a conclusão que para modelagem de processo de negócio utilizaríamos uma ferramenta que seria capaz de modelar processos focados no negocio numa semântica dominada pelo profissional desta área (o analista de negocio) e por seguinte, este processo seria cliente de uma camada de serviços onde fundamentalmente os serviços seriam definidos em serviços atômicos, unidades mínimas de serviços e serviços compostos, composição de serviços orquestrados por uma linguagem para este fim, que neste caso seria BPEL. Ou seja os dois mundos existiam, o modelo BPEL era focado exclusivamente na modelagem da colaboração de serviços atômicos e compostos enquanto que o XPDL era utilizado na modelagem da colaboração dos passos identificados no processo de negocio, que poderiam ou não estar sendo realizados por serviços compostos ou atômicos. De fato o XPDL aqui é apenas a linguagem computacional utilizada para execução do modelo BPMN elaborado na camada de negócio, portanto o que temos na modelagem de fato é um diagrama BPMN e uma relação de realização deste modelo no service layer e na forma serviços (sejam estes atômicos ou compostos). Certamente não sei dizer se esta é a melhor abordagem, contudo para meu cliente era bastante interessante, deixe eu tentar citar algumas vantagens de maneira bem objetiva:

- O processo de negocio desenhado pelo analista de negocio era executável não necessitando uma conversão intermediária entre um modelo BPMN e uma ferramenta de execução de processo baseada em BPEL.

- O processo de negocio poderia ser simulado e melhorado orientado a critérios de negocio, ou seja a modelagem da estrutura do processo não tinha nenhuma relação com a semântica de orquestração dos serviços de tecnologia, deste modo a competência do arquiteto de negocio não se misturava com a competência do arquiteto dos serviços.

- Objetivos de negocio eram realizados na modelagem do processo de negocio, objetivos não-funcionais de infraestrutura eram rastreados nos objetivos de negocio e realizados nos serviços atômicos ou serviços compostos (na forma de processos de tecnologia).

- Definição clara de o que é um processo de negocio e o que é um serviço composto reaproveitável corporativamente.

Bom, eu poderia ficar falando sobre este assunto por horas sem chegar a lugar algum pois, como eu disse, são questões ainda pouco resolvidas até mesmo no mercado, minha percepção e experiência levam-me a crer que a solução é contingencial e irá depender do que seu cliente quer. De maneira geral eu comecei a falar disso para introduzir um artigo bem interessante que li recentemente e intitulado Why BPEL is not the holy grail for BPM.

Em breve falaremos como a abordagem citada aqui pode ser implementada utilizando o JBPM, e dentro desta filosofia é interessante observar o conceito de PVM (process virtual machine) oferecida por esta API onde permitirá trabalharmos de maneira plugável com a linguagem de execução, permitindo assim os dois mundos, tanto ao orientado ao processo de negócio quanto o orientado ao processo de tecnologia (composite services) serem oferecidos por uma única suite simplificando bastante a arquitetura.

Para quem se interessar em quebrar a cabeça com as relações entre XPDL e BPEL segue o link para um paper publicado pela Universidade Karlsruhe na Alemanha, http://wi.wu-wien.ac.at/home/mendling/publications/TR-Caise06.pdf, boa sorte na leitura.