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.