Re: action framework was Re: [esb-dev] divide and conquer samples?
Personally I like the idea of JBPM as a way of gluing the things
together. With that said you could just as easily do this with Drools
as well. Salience could represent the version of the service and
multiple services could be retrieved and run depending on the criteria
of the message. Does the BUS really care about process? Is a service
always part of a process?
My thought is that maybe the initialization of the bus is based on
OSGI/microcontainer and as part of that the process engine loads
based on the definition types (could be JBPM/ variant) that strings
utility based services to business based services.
I guess the question really is what is the core offering that the ESB
wants to fill going forward? A service infrastructure, a service
router, etc... What do you want people to use the ESB for? Abstracting
existing services, adding new services, aggregation, orchestration?
I see alot of conversations about what technologies to use for
replacing existing parts but only a couple comments about the goals of
the ESB. My thoughts are that the ESB needs to very flexible and
whether it has JBPM as an action framework or not for a type of
orchestration is just a different type of provider. The ESB needs to
be very simple to add and update protocols, formats, transformations,
etc... for a competitive edge.
The faster you can add any type of protocol, listener, action
framework, etc... the better we can react to the changing demands of
the service space. This also allows additions based on standards
fairly easily. Right now it is a bit messy to incorporate new listener
types, etc... based on various protocols or message formats.
One of the benefits I see the ESB could give people going forward is a
light-weight service infrastructure that would allow users to talk to
a service in JSON, XML over HTTP, MQ, or whatever someone desires to
talk to the service with. The benefit of the bus is that it opens up
the possibilities of how to manage services, monitor services, route
and version services.
Thoughts? How do you see people using the bus? Just another framework
or something more useful?
On 3/22/07, Burr Sutter <bsutter(a)redhat.com> wrote:
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.
>
_______________________________________________
esb-dev mailing list
esb-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/esb-dev