Option 2 is basically replacing jboss-esb.xml with a .jpdl, right?
And we've have a ton of work to do to make .jpdl expressive enough to
support what jboss-esb.xml does today. When the ESB was presented to
Tom B he suggested we build our own process language on top of jBPM. He
thought that would take approximately 2 people 2 months assuming all of
the features mapped into the underlying engine.
Bill, is this what you are suggesting?
Mark Little wrote:
Now I'd have thought we were talking about 1! If you were talking
about 2 then I can see the disconnect.
Mark.
On 22 Mar 2007, at 21:39, Bill Burke wrote:
>
>
> Tom Fennelly wrote:
>> Are we talking about 2 things here:
>> 1. Service Orchestration. Higher level - sitting above bus and
>> interfacing to it via SOAP, JMS etc (message unaware). In this
>> case, being able to mix and match different process management
>> tools is important (jpdl, bpel etc).
>> 2. Bus Level Orchestration. Lower level - sitting inside the
>> bus. Here you orchestrate message routing (CBR etc),
>> transformation,
>> auditing etc. In this case, perhaps it's not so important to be
>> able to plug and play different process models. This is perhaps
>> where jBPM and ESB Actions cross paths??
>
> Thanks for clarifying Tom. I've been talking about #2. Although I
> think jBPM would be a very interesting option for #1, you wouldn't be
> an ESB if you couldn't plug in #1. Maybe that's where Mark and I
> have been disconnecting?
>
> Bill
>
> --Bill Burke
> JBoss, a division of Red Hat Inc.