If a user wants to interact with other process engines, then they'll
need to write an action that bridges the two. This is no different than
what you are currently doing now with jBPM in JBoss ESB 4.0. Having
jBPM as core process engine just takes out one step the user has to do
to integrate two of our products that overlap each other. I really
think jBPM's core engine is lightweight enough to handle the simple case.
If you build in Seam's bi-jection, IoC, and token/message mappings to
method invocations (like Seam does) into jBPM there's really no reason
the majority of ESB or jBPM actions ever need to see the token or
Message interface. What becomes really interesting in this model is
that ESB components can start to bleed into the Seam web-flow space and
JEMS really starts to look like a complete integrated product.
If jBPM becomes core, you can let them do what they do best and have
them handle writing the ESB's kernel, while ESB team can focus on the
interesting enterprise problems. Not only that, but you can start
leveraging the jBPM community to gain visibility for ESB rather than
jBPM competing with you guys on a bunch of different features and semantics.
You know, working with you guys the past few weeks really got me excited
of what we can do with JEMS as an integrated product line.
Bill
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.
--
Bill Burke
JBoss, a division of Red Hat Inc.