On 3/23/07, Mark Little <mlittle(a)redhat.com> wrote:
On 23 Mar 2007, at 03:13, Dan Marchant wrote:
> 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.
I'm not sure if JBossRules can play as much of a role as jBPM, but
it's certainly able to fulfill some of the criteria. We're using it
successfully for CBR, where it supports XPATH as well as "native"
expressions.
> 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?
Depends what you mean by service ;-)
Ah yes, that is a good conversation that I have seen before.
Inherently everything could be a service
:)
>
> 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.
Yes. It should be possible to tie together the components using
different technologies in the way you describe.
>
> 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?
The ESB needs to support all of this. While we'd expect people to
write new services from scratch, given where we see ESB, SOA and Web
Services taking off, plugging in existing services will be the
dominant scenario for the short-to-medium term. The ESB itself
doesn't provide orchestration per se but supports it (I hope that
distinction makes sense). Things like aggregation, CBR,
transformation, are out-of-the-box services/components that plug into
the ESB and do "clever" things with the messages. How those services
are implemented is important and we've got some good candidates for
technology to do this.
>
> 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.
+1
> The ESB needs to
> be very simple to add and update protocols, formats, transformations,
> etc... for a competitive edge.
+1
>
> 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.
+1
>
> 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.
+1
>
> Thoughts? How do you see people using the bus? Just another framework
> or something more useful?
A useful framework ;-)?
:)
Mark.
>
>
>
>
>
> 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
>>