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