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.
Of course it is. We need to show people the "right way". Having
portable business logic between my web apps, c/s apps and soa apps is a
good thing. Granted, if you wish to put all of your code in an ESB
action and therefore tie yourself forever to the proprietary JBoss ESB
API then go for it. At least Spring beans, WSs, EJBs and POJOs are
"portable" across multiple implementations of ASs and ESBs with no
vendor lock-in. That is the purpose of the business_service quickstart,
to illustrate this point.
> 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.
Check out the more_action quickstart actions. They extend
AbstractActionLifecycle and have a ConfigTree stuck into their
constructors. This is very different from the jBPM actions. jBPM
actions implement ActionHandler and have an "execute" method which takes
an ExecutionContent object. Different APIs for different purposes.
> Technically they are different animals.
>
Yes they are different animals, but I think there maybe a foundation
that work for both.
There could be a common foundation but I think you would also have to
blend jboss-esb.xml with JPDL to realize any real benefit. JBPM actions
are essentially event handlers tied to JPDL's nodes. Perhaps you wish
to simply stick the JPDL directly into the jboss-esb.xml instead of
having an external file?
> 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..
Agree that a specific service might be jBPM enabled. That is the work
that Esteban has been focused on. This is a very important
competitive differentiator. Also Rules-enabled services as well though
we don't have quickstart that explicitly demos this capability yet.
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 ;)