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.