3:08 p.m.
Sorry for the late reply....
I'm proposing replacing elements within <services> as transformation of
a JMS message to a token and/or org.jboss.esb.Message should be an
action too.
JBPM needs to have true lifecycle for nodes/actions. Once you have that
you can implement inbound listeners.
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
>
--
Bill Burke
JBoss, a division of Red Hat Inc.