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??
???
T.
Mark Little wrote:
What you're suggesting is strong coupling of jBPM to JBossESB,
such
that any user of JBossESB also has to be a user of jBPM. That's
certainly a way of going. However, the way we're going is to support
jBPM on JBossESB in a way that only those users who want to use/know
about jBPM have to know about it and use it. But if I want to control
the flow of messages using some other process engine, or even
mix-and-match with difference engines for different parts of my
application, then I'll be able to. However, from the perspective of
the jBPM user, it shouldn't matter: if we do it right then they
shouldn't notice the difference. We're a superset of the capabilities
you're suggesting so I don't see the conflict.
Mark.
On 22 Mar 2007, at 20:53, Bill Burke wrote:
>
>
> Burr Sutter wrote:
>> ESB Actions vs jBPM Actions OR Actions vs JBI/SCA/Spring/Seam are
>> different discussions.
>> Let's take the Actions vs JBI/SCA/Spring, etc debate first:
>> - It has been my push in the outbound evangelism to state that
>> actions are not the ideal place for your business logic. Leave your
>> business logic where it lives today in WSs, EJBs, Spring beans, etc
>> and simply enable those components as bus services by building some
>> ESB action glue. - Ideally we'll give you numerous actions "out of
>> the box" (OOTB) that allows you to simply configure the capabilities
>> of your solution. You'll get actions (OOTB) for splitter,
>> aggregator, routing, CBR, transformation, etc. - There will be times
>> when you need to build your own custom actions so that you can
>> enable to a specific endpoint in a specific way. For instance, you
>> might have your own action that handles specialized transformation
>> or specialized routing that the current OOTB actions/engines don't
>> yet handle correctly.
>> Now on the ESB actions vs jBPM actions debate:
>> - jBPM actions have a specific interface/super class that is not
>> "message oriented" they require access to the jBPM context and they
>> are tied to particular "events" like node-enter, node-leave. They
>> are not meant to be "pipelined" or chained together.
>
> I don't believe you are right. After looking at things like
> Servicemix, reading JBPM docs, reading JBPM forums, doing my own
> prototyping, contributing to ESB project, I see so much overlap and
> redundant thinking between the two projects.
>
> On "jBPM actions aren't 'message-oriented':
>
> You can stuff anything you want in a map. Reply-to destination.
> Context data, anything. And you can wire anything in a map into an
> action. Take a look at JBoss's EJB Invocation object. It is really
> a set of 3 maps. 1 map is transient data is not sent across the
> wire. 1 map is a distributable payload that is not classloader
> boundary sensative. The last is a distributable payload that is
> sensitive to classloader boundaries. These maps have message
> information (parameters, and method to be invoked) and context
> information (Tx ID, principal, credentials). JBoss's EJB invocation
> also has a reference to which aspects/interceptors that are being
> invoked, and where in the aspect/interceptor chain you are invoking.
> jBPM has an exact analogous structure. The jBPM token could be
> transformed from an incoming JMS message, or transformed to an
> outgoing XML document, or just sent AS IS. (jBPM does exactly this
> when transitioning over JMS).
>
> On "JBPM actions aren't meant to be pipelined or chained tgoether":
>
> Go look at what JBPM users are doing.
>
>> - ESB actions have a specific interface/super class, they are
>> message oriented (take a Message in), require access to the ESB
>> context and are not tied to any events. They are meant to be
>> chained together (in/out Message objects).
>
>
> Disagree. Takencontent based routing. As you enter the routing
> decision ("node-enter"), you need to transform the message body from
> text to a XML document. As you leave ("node-leave"), you might want
> to notify a auditing layer of what decision was made. In a process
> view, all you want to see at a high level is input coming in and what
> are the decision routes. What I've been reading about Tom's
> philosophy is that the definition of an event, action, or node is
> often blurred depending on how you want the process view to look.
>
> BTW, there's no reason the JBPM process instance context and ESB
> message context can't be the same. They already do semantically the
> same thing.
>
>> Technically they are different animals.
>
> I don't think so. Go look at jBPM 3.2. Its starting to look very
> much like an ESB except it includes long-running processes and human
> interaction as well as the plain vanilla message flow that ESB
> offers. IMO, its only natural for the jBPM team to start looking,
> feeling, and acting like an ESB. Its the same for JBoss Rules and
> workflow. Its only natural for them to head in this direction. The
> thing is though, we're not separate companies, we're one company.
>
>
>> Plus jBPM's JPDL isn't feature rich enough to express things like a
>> JMS endpoint service with 4 associated OOTB ESB actions and 2 custom
>> ESB actions that is currently expressed in the jboss-esb.xml.
>
> Ditch jboss-esb.xml. There is nothing complicated there. I've
> already written a prototype that does everything but inbound
> declaration in a process definition. If jBPM 4.0 was ready, I could
> even do inbound declaration. And I'm sure the jBPM team or a
> contributor will end up doing this. Its only natural for them to
> proceed in this direction. Sit on their user forums for a week or so
> like I did and you'll see what I mean.
>
>> jBPM is also focused on the BPM space while the ESB is focused on
>> the EAI space.
>
> I disagree on the focus of jBPM. jBPM is focused on graph oriented
> programming and state machines. Everything else is just a plugin.
>
>
>> One is human interaction oriented. The other system to system,
>> application to application, business to business focused. They have
>> 2 fundamentally different usage scenarios.
>
> jBPM is a definition of a state machine. That's it. Message flow is
> pretty fundamental, IMO, to both EAI and BPM.
>
>
>> It should be noted that we believe ESB users will also wish to
>> involve humans and long-running "processes" in which case having an
>> OOTB ESB action that starts or signals a jBPM process instance is a
>> very good thing (and what Esteban has been working on). Plus having
>> the jBPM action that is clever enough to "signal" an ESB registered
>> service is also important.
>
> My whole point with using jBPM as the action framework is that it is
> lightweight enough to act as a simple action and expandable enough to
> have long running processes and human interaction. What's even more
> interesting is that the state-machine metadata could travel along
> with the message thus giving you smart messages. A client could
> define the message flow and the servers just be set of dumb ESB
> servers that receive smart messages that know how to process and
> route themselves.
>
>
> Tom B and company know how to write state-machines. They also know
> how these state-machines should be implemented to run long running
> processes . ESB teams knows more about the issues of remote
> connections better. Combine them, and you have something compelling
> (1 + 1 > 2). Treat each other as black boxes, and JBPM and ESB might
> as well be two different products from two different companies (1 + 1
> < 2).
>
> 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