I don't think anyone is saying it's not worth considering. It's just
whether or not it makes sense to do it to the exclusion of other
approaches, such as JBossRules. We will be doing much closer
integration between all of these products as we move forward with the
SI platform (aka SOA platform), so it's not something we can avoid.
That will give all of the teams much more experience of what's
possible from each others projects and is bounce to be a good thing.
Mark.
On 23 Mar 2007, at 11:55, Tom Fennelly wrote:
Perhaps I need to see more of this, but it seems to make a whole
lot of sense to me (i.e. to take advantage of jBPM in an option #2
type scenario). jBPM, the tools that are directly around it, the
other JEMS products that are integrating with it etc
From an ESB perspcetive.... Surely it offers an easier path for us
to be able to do stuff like CBR (GOP, state machines and all that
other funky stuff I know f*ck all about :-) ), Transformation
triggering/assignment (via GOP) etc This all seems like stuff we
need at the heart of the ESB. I don't think this stuff is trivial.
From a JEMS/SOA-Platform perspectives... Seam to jBPM integration
was already mentioned. With what else does jBPM offer an
integration point?
Sure, the jBPM stuff may need to evolve in order to support the ESB
better, but isn't that a natural enough direction for it to go? I
suspect they have more know-how in this area too - apologies to
anyone who thinks otherwise ;-)
At a minimum, it definitely sounds like something that's worth a
closer look. Can't hurt :-)
T.
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/schemas/xml/jbossesb-1.0.1.xsd"
>> 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
> _______________________________________________
> esb-dev mailing list
> esb-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/esb-dev
_______________________________________________
esb-dev mailing list
esb-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/esb-dev