Re: action framework was Re: [esb-dev] divide and conquer samples?
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.
It may or may not be
the right place to put business logic, but do we
really care? Now that we have the .esb deployment it's pretty well
encapsulated. So I see no downside to deploying business logic there.
Leaving it where it is is good, but new stuff can be put where ever it
makes sense no? So I'm not so sure this debate is worth having.
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.
- 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).
ESB action don't have a specific interface/super
class (other then
lifecycle support, which has nothing to do with this). And we don't yet
have ESB context (in code), so we can still be accommodating.
Technically they are different animals.
Yes they are different
animals, but I think there maybe a foundation
that work for both.
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. jBPM is
also focused on the BPM space while the ESB is focused on the EAI
space. One is human interaction oriented. The other system to system,
application to application, business to business focused. They have 2
fundamentally different usage scenarios.
I don't see JPDL (as it is today)
describing flow between endpoints, I
think that is something ESB specific, but once you are in an
ESB-service, it looks very much like a jBPM process with actions..
I don't think jBPM-as-it-is-today integration is the way to go, however
integrating on a common foundation is worth exploring in my mind.
anyway my 2 cents.
I'd really like to know if someone is working on the remaining 2
QuickStarts ;)