BPEL

Versus BPEL, BPML, WSFL, XLANG, XPDL

 

Até um tempo atrás, não havia nenhum padrão para processos executáveis. XLANG estava emergindo, WSFL não existia, e pessoal do workflow haviam produzido nada mais do que um conjunto de relações totalmente inúteis. Então o BPMI.org liberou a especificação da BPML, que forçou Microsoft e IBM para abandonar XLANG e WSFL respectivamente. Por razões políticas, Microsoft e IBM decidiram escrever sua própria especificação, em vez de adotar BPML, que conduziu à liberação de WS-BPEL, um ano depois que a primeira execução comercial da especificação da BPML distribuída em produção. Três anos das discussões públicas seguidas, até que o BPMI.org foi fundido com a OMG e decidido finalmente deixar a BPML em favor de BPEL. Até então, nenhum padrão real estava disponível nos últimos seis anos, que contribuíram a retardar a baixa adoção do BPM.

As coisas são um pouco diferentes hoje. BPEL ganhou, BPEL 2.0 é uma especificação boa o bastante para os clientes construírem processos de missão crítica com, e todos os grandes fornecedores adotaram-na. BPM 2.0 trabalha graças ao BPEL, bem como bases de dados relacionais trabalha graças ao SQL. Os analistas de processos não devem realmente importar-se com ele, porque não terá que escrever uma única linha do código de BPEL se escolherem a ferramenta certa, mas BPEL é como o DNA do processo, ele é o padrão em que tudo é construído ao redor. Assim se você estiver ouvindo que BPEL não importa, ou que o produto que você está considerando para aquisição declarar que suportará BPEL ano seguinte, não se engane: você está a ponto de comprar uma parte muito cara de software proprietário que você terá que se livrar de mais cedo do que você pensa, assim como os que a recém se adaptaram ao padrão.

Mas por que BPEL importa? Fora os 250 fornecedores de BPM podem ser encontrados no Google, menos de 10 suportam BPEL de forma nativa. Os outros 240 fazem geralmente um caso que BPEL não importa realmente, porque nenhum analista do negócio o usaria diretamente. Estão certos e errados.

Estão certos, no sentido que, nenhum analista de negócio . ou analista de processos . terá que escrever uma única linha do código de BPEL. Em vez deste, usarão uma ferramenta de modelagem de processos que gere o código para eles. Mas são também estão errados, o que se importam com a maneira que o código é gerado, por três razões principais.

Primeiramente, usar um motor de processos que suporte BPEL de forma nativa assegura que os processos que são distribuídos nele poderão ser distribuídos em outro motor de processos também. Tanto quanto eu posso dizer, esta é a melhor política que de seguro todo o cliente poderia iniciar. Admitidamente, o fato é que BPEL tem as versões múltiplas (1.0, 1.1, 2.0) e suporta definição proprietária de extensão . muito semelhante ao SQL com SQL-87, SQL-92 e stored procedures proprietárias . tal portabilidade deverá ocorrer. Não obstante, é muito mais fácil do que optar por uma linguagem proprietária do fornecedor tal.

Em segundo, projetando os processos que são ser distribuído visado um servidor executável de BPEL permite que os desenvolvedores façam algumas suposições a respeito da execução ambiente que os hospedará: as interfaces web services estarão lá para interagir em qualquer momento com os processos em sua execução, os dados par auditoria terão certo formato . ou pelo menos são definidos uma semântica comum, e uma coleção de processos estarão definidos e construídos antecipadamente, sem ambigüidade. Isto faz o desenvolvimento de ferramentas baseadas em padrões para monitoração da atividade de negócio e análise dos processos e simulação muito mais fáceis dentro do eco-sistema do BPM.

Em terceiro lugar, se os fornecedores do workflow, gostando ou não . usualmente para eles BPEL não se transformou em um padrão de fato na indústria. A maioria de fornecedores de BPM hoje foram fornecedores do workflow no passado, e a grande comunidade de workflow fez um bom trabalho que fragmentou o mercado, e ninguém desenvolveu nem suportou um padrão útil. Pensar em dividir-se para conquistar é uma estratégia onde ninguém conquista realmente qualquer coisa em primeiro lugar. Em conseqüência, os fornecedores de workflow tem um interesse investido dentro BPEL, a fim retardar sua baixa adoção e sua própria evolução em relação à sua irrelevância. Mas não há engano. Quando a maioria dos fornecedores de TI . incluindo IBM, Microsoft, Oracle e SAP . concordam com o padrão fornecido, não há muito espaço para mais outro. QL pode ter sido melhor do que o SQL vinte anos atrás, mas a suporte que a IBM deu ao SQL o fez um vencedor certo. O suporte para XPDL seria uma perseguição nobre somente se XPDL fosse tecnicamente superior a BPEL. Não é, e conseqüentemente eu não vejo razão em não usar BPEL. E se você pretender usar um produto que não suporte BPEL de forma nativa, certifique-se de pedir que o fornecedor de BPEL ajude-o migrar para um que o faça. A última vez onde eu verifiquei isto, não era tão difícil.

Um dos melhores lugares para aprender mais sobre BPEL está no blog de um de meus concorrentes, uma publicação excelente no BPEL Radio publicado por Edwin Khodabakchian, vice-presidente de desenvolvimento de produto da Oracle. Edwin foi fundador da Collaxa, companhia que desenvolveu o primeiro trabalhando para execução de BPEL. Ele sabe o que está falando, e confia nisto.

http://www.projeler.com.br/artigos_bpm20e.jsp