Burr Sutter wrote:
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
Using jbpm AS IS is possible, but it needs to be refactored to support
ESB usecases as well. My thought is to iterate with 3.2 but push
requirements to jbpm 4.0 team.
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.
This is a relevant issue, but I think we can refactor base jbpm to
handle the simple usecases.
- 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.
I think this is an irrelevant issue. This can be fixed. ESB 4.0
release had the same problems.
Bill
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
--
Bill Burke
JBoss, a division of Red Hat Inc.