Yeah, that's because they don't have lifecycle and their model needs to
change just as the action lifecycle changed in MP1. They know this.
Burr Sutter wrote:
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