O propósito de um service bus é outro, é fazer roteamento, transformação, mapeamento e também composição de serviços, mas não da mesma maneira que BPEL se propões fazer (aí entra questão de human-readable, e etc). O propósito principal de um service bus é catalogar servicos e permitir a integração entre eles em um paradigma baseado em mensagens.

BPEL possui por exemplo muitos mais recursos para implementação de regras de negócios complexas. Já um ESB é mais focado em integrações e não em modelagem como BPEL.

BPEL e ESB podem ser usados juntos, não é só pq vc usa um que não deva usar o outro, mais uma vez, o propósito de ambos são diferentes.

Veja bem, não estou defendendo BPEL, apenas estou dizendo que ele tem o seu propósito. Agora se ele pode ser substituído ou não, ou até se pode ser esquecido, aí é outro assunto.

ESBs fazem composição também.. mas fazem muito mais do que isso..

Se BPEL serve na pratica so pra compor (coreografar e orquestrar) continuo achando q não vale a pena

Travel.wsdl

http://localhost:9700/orabpel/default/Employee/Employee?wsdl

http://localhost:9700/orabpel/default/AmericanAirline/AmericanAirline?wsdl

http://localhost:9700/orabpel/default/DeltaAirline/DeltaAirline?wsdl

A questão é que BPEL tem o seu propósito, que é composição de serviços, se vale a pena ou não, acho que depende da situação, é discutível.

Java assim como Python são totalmente compativeis com webservices WS-*, SOAP etc..

O meu questionamento não é com relação ao papel do BPEL e sim com a sua adoção.

Simplesmente não vale a pena..

http://architecture-journal.blogspot.com/2007/07/bpel-no-bpm.html

Não vamos confudir as coisas, BPEL serve para orquestração e coreografia de Webservices, ou seja, é fazer com que cenários complexos de negócios sejam convertidos para um formato mais amigável de ser entendido e modelado.

Sem contar outras questões que BPEL te oferece como ferramentas para acompanhamento, controle e execução dos processos.

Só não vejo porque ficar no meio do caminho. BPEL não tras os beneficios do BPM na questão de visualização dos negócios nem na implementação.

Porque nao Java JPD? http://en.wikipedia.org/wiki/JPD

É melhor manter uma parte tecnica(sim, código) sem BPEL e tentar introduzir o BPM efetivamente do que perder tempo e dinheiro com BPEL.

Se é pra ter alguem técnico na equipe, prefiro que essa pessoa seja mais efetiva com codigo (pode ser anotado com JPD para dar a visualização gráfica do processo de negocio) do que ocupa-la com BPEL.

Na hora de mapear os processos de negocio realmente importantes(macros) usamos o BPM.

Java te daria a possibilidade de um analista mapear todo um processo para TI implementar? Acho difícil…

No exemplo eu usei BPEL para um processo de negócio, mas que só envolvia questões técnicas (serviços) e BPM ficou em um nível mais acima, por envolver pessoas, setores, departamentos, etc..

Baixo nivel? Eu fico com Java.. e muitas outras pessoas também.

http://blog.lombardicto.com/2006/03/more_bpmn_vs_bp.html

Quote: “BPEL is expressive, it just is too little, too late. Stick with Java and C# for the short-term, and move to a truly services-oriented representation strategically. This will result in the quickest move to the next-gen architecture, and the lowest cost, most scalable implementations in the short run. “

Acho que uma das dificuldades seria determinar o que exatamente seria tratado usando BPM e o que seria executado usando BPEL. Voce definiu que BPEL no seu exemplo seria usado para operações de baixo nivel. Mas esse conceito eu acho um pouco vago.

É claro que no mundo ideal tudo é mais simples mas no mundo real acho que BPM e BPEL ainda são muito confundidos como ferramenta porque na hora de executar tarefas conseguimos o mesmo resultado com ambos. De qualquer forma não podemos esquequer que cada ferramente tem um proposito.