Sorry, totally forgot I had to meet with tax accountant today.
Tom Fennelly wrote:
lol
He's probably offline at the moment... making his way to your's (or
maybe Mark's) house... armed... and dangerous ;-)
Burr Sutter wrote:
> Come on Bill. Keep up the fight! This is fun. :-)
>
> 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
>>
>> 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.
>> - 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.
>>
>>
>> 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
> _______________________________________________
> esb-dev mailing list
> esb-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/esb-dev