I agree that we need to be much more integrated in order to offer a
full ESB/SOA capability out-of-the-box. jBPM and/or a BPEL engine
(ideally our own) would be there for the user and they wouldn't see
the underlying ESB components. Adding more capabilities to this ESB-
ized jBPM would happen at the jBPM level and they'd not have to see
the ESB. Seam integration would be similarly tight out-of-the-box. So
from that perspective what you're talking about makes complete sense
and is right along the lines we've been discussing for a while.
However, it doesn't mean the ESB has to be tied to jBPM or Seam if
someone wants to plug in their own components.
Mark.
On 22 Mar 2007, at 21:34, Bill Burke wrote:
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.