As a follow up... here is the JPDL example for action chaining/service
flow (this is one of my demos today). Note: there is a bunch of code
around this for handling of what jboss-esb.xml calls a provider,
service, listener, etc. And this particular demo was a bitch to
create since the jBPM team hadn't yet fully cooked this particular use
case (non-human flow).
<?xml version="1.0" encoding="UTF-8"?>
<process-definition
xmlns="" name="ProcessThree">
<start-state name="start">
<transition name="" to="Validation"></transition>
</start-state>
<state name="Validation">
<event type="node-enter">
<action name="action1"
class="actionhandlers.MessagePusherActionHandler">
<queueName>Demo3Validator_Request</queueName>
</action>
</event>
<transition name="" to="Any Validation
Errors"></transition>
</state>
<decision name="Any Validation Errors"
expression="#{ERROR=='true'}">
<transition name="true" to="Send Errors
1"></transition>
<transition name="false" to="fork1"></transition>
</decision>
<decision name="Any Service A Errors"
expression="#{ERROR=='true'}">
<transition name="false" to="join1"></transition>
<transition name="" to="Send Errors
1"></transition>
</decision>
<node name="Provide Response">
<event type="node-enter">
<action name="action1"
class="actionhandlers.MessagePusherActionHandler">
<queueName>Demo3_Response</queueName>
</action>
</event>
<transition name="" to="end1"></transition>
</node>
<end-state name="end1"></end-state>
<fork name="fork1">
<transition name="B" to="Service B"></transition>
<transition name="A" to="Service A"></transition>
</fork>
<join name="join1">
<transition name="" to="Provide
Response"></transition>
</join>
<state name="Service B">
<event type="node-enter">
<action name="action1"
class="actionhandlers.MessagePusherActionHandler">
<queueName>Demo3TransformerB_Request</queueName>
</action>
</event>
<transition name="" to="Any Service B
Errors"></transition>
</state>
<state name="Service A">
<event type="node-enter">
<action name="action1"
class="actionhandlers.MessagePusherActionHandler">
<queueName>Demo3TransformerA_Request</queueName>
</action>
</event>
<transition name="" to="Any Service A
Errors"></transition>
</state>
<decision name="Any Service B Errors"
expression="#{ERROR=='true'}">
<transition name="false" to="join1"></transition>
<transition name="true" to="Send Errors
3"></transition>
</decision>
<node name="Send Errors 1">
<event type="node-enter">
<action name="action1"
class="actionhandlers.MessagePusherActionHandler">
<queueName>Demo3_Errors</queueName>
</action>
</event>
<transition name="" to="end1"></transition>
</node>
<node name="Send Errors 3">
<event type="node-enter">
<action name="action1"
class="actionhandlers.MessagePusherActionHandler">
<queueName>Demo3_Errors</queueName>
</action>
</event>
<transition name="" to="end1"></transition>
</node>
</process-definition>
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