After some more consideration of this matter here is where I am at, I
still like both models.
I still like our "lightweight" orchestration model that allows the end
user to lay out their flow by simply adding actions to jboss-esb.xml.
It is very easy to use and there are number of out of the box actions
that get me going (e.g. transformation, static router, CBR, splitter,
aggregator, notifier, etc). The "cons" for the current lightweight
model are:
- No tools - just raw XML editing, no drag & drop
- No BAM - stats on how long it takes to flow from A to B to C
- No persistence so it is an "all or nothing" flow
The "pros" for the lightweight model are:
- Lots of examples (quickstarts) that illustrate the various ways to use
it in the context of SOA
- Fairly easy to use & learn - simply action tags
Now Esteban is working on our jBPM integration which will give us
"enterprise-class" orchestration. The "pros" for jBPM-based
orchestration are:
- Tools - assuming we keep the .jpdl file separate (outside of
jboss-esb.xml) then the current tools will allow for editing, dragging &
dropping
- really, really basic BAM - and it will improve in the future
- human-interaction if needed
- persistence which means a flow can be "paused" and "restarted"
- You can actually mix & match the lightweight flow (e.g. call to the
SmooksTranformer then a call to a jBPM process instance) in the same
jboss-esb.xml
The "cons" for jBPM-based orchestration:
- Does require learning of jPDL and jBPM actions. This is not a trivial
undertaking.
- It requires lots of setup & configuration for jBPM such as getting the
database configured correctly and Hibernate mapped correctly. This is
not well documented and involves some heavy lifting on the part of the
user. It is improving but does have a real learning curve.
Burr Sutter wrote:
I'm not seeing any real value. Trying to replacing jboss-esb.xml
with
a .jpdl does mean we (the ESB team) don't have to write any "flow"
code for action "chaining" but I don't believe there is much code in
that area to begin with. I need something more concrete to debate.
Here is a jboss-esb.xml file. The only value I see in using jPDL
would be to replace the action area of the service definition,
basically the actions section could in theory be JPDL. Instead of
action1, action2, action3 you would have state1 - transition1, state2
- transition1 with actions tied to either states/transitions. Is
this more or less what you are proposing?
<?xml version = "1.0" encoding = "UTF-8"?>
<jbossesb
xmlns="http://anonsvn.labs.jboss.com/labs/jbossesb/trunk/product/etc...
parameterReloadSecs="5">
<providers>
<jms-provider name="JBossMQ"
connection-factory="ConnectionFactory">
<jms-bus busid="quickstartGwChannel">
<jms-message-filter
dest-type="QUEUE"
dest-name="queue/quickstart_helloworld_action_Request"
/>
</jms-bus>
<jms-bus busid="quickstartEsbChannel">
<jms-message-filter
dest-type="QUEUE"
dest-name="queue/B"
/>
</jms-bus>
</jms-provider>
</providers>
<services>
<service category="HelloWorld_ActionESB"
name="SimpleListener"
description="Hello World" >
<listeners>
<jms-listener name="JMS-Gateway"
busidref="quickstartGwChannel"
maxThreads="1"
is-gateway="true"
/>
<jms-listener name="JMS-ESBListener"
busidref="quickstartEsbChannel"
maxThreads="1"
/> </listeners>
<actions>
<action name="displayAction"
class="quickstart.helloworld_action.MyJMSListenerAction"
process="displayMessage">
<property name="exceptionMethod"
value="exceptionHandler"/>
</action>
<action name="playAction"
class="quickstart.helloworld_action.MyJMSListenerAction"
process="playWithMessage">
<property
name="exceptionMethod" value="exceptionHandler"/>
</action>
<action name="notificationAction"
class="org.jboss.soa.esb.actions.Notifier">
<property name="okMethod" value="notifyOK"
/>
<property name="notification-details">
<NotificationList type="OK">
<target class="NotifyConsole" />
<target class="NotifyQueues">
<queue
jndiName="queue/quickstart_helloworld_action_Response">
<messageProp name="quickstart"
value="hello_world_action" />
</queue>
</target>
</NotificationList>
</property>
</action> </actions>
</service>
</services>
</jbossesb>
Bill Burke wrote:
>
>
> Burr Sutter wrote:
>> Option 2 is basically replacing jboss-esb.xml with a .jpdl, right?
>>
>
> A mixture of MC and .jdpl yes. You'd need MC beans to define
> connectors that are shared between services. (or any bean that is
> shared between services).
>
>> And we've have a ton of work to do to make .jpdl expressive enough
>> to support what jboss-esb.xml does today.
>
> Actually the opposite. You have tons of work to do to make
> jboss-esb.xml as expressive as .jdpl. IMO, ESB's kernel is pretty
> basic. Its all the converters, connectors, and transformers where
> all the hard work went into from what I've seen.
>
>> When the ESB was presented to Tom B he suggested we build our own
>> process language on top of jBPM. He thought that would take
>> approximately 2 people 2 months assuming all of the features mapped
>> into the underlying engine. Bill, is this what you are suggesting?
>>
>
> No, that's not what I'm suggesting. I'm suggesting jBPM team does
> most of the work with the underlying kernel and ESB team focuses on
> enterprise features around and within it like connectors,
> transformers, EJB, JPA, Hibernate integration, ESP, Rules
> integration, and ESB federation.
>
> I think with 2 man weeks of work you could beanatize ESB components
> as well as the jBPM object model. Then 1st iteration could be wiring
> everything together (inbound, outbound, nodes, actions, transitions)
> using MC XML. From there you could see the usability patterns and
> write a schema to simplify things for developers. Or, still
> beanitize ESB components, but prototype by hacking jbpm 3.2 while
> jBPM team works on jbpm 4.0 based on requirements from ESB, Rules,
> and Seam teams.
>
> Again, my main drive here is to have a well integrated, uniform look
> and feel to web-flow, esb, and bpm. I really think these
> technologies work just as well together as they do apart. If all
> these guys are sharing the same underlying architecture, then it
> makes it easier to for Seam to tie them together in a unifying API
> and to share components between them.
>
> I'm sorry I'm being so aggressive about this. I just feel that its
> so crucial to have a unified, seamless platform.
>
> Bill
>
_______________________________________________
esb-dev mailing list
esb-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/esb-dev