I'm assuming we're still talking about replacing the action framework
too.
Mark.
On 26 Mar 2007, at 17:10, Tom Fennelly wrote:
Sorry, I'm getting a bit confused here. I get the impression
we're
talking about orchestration like it's one big black box. So, in
order to try get some clarification, I doctored a picture I threw
together for something else.
It's a usecase along the lines Burr outlined earlier (Broadband
Provisioning in this case). My confusion with Burr's usecase
however is that we seem to be blurring together 2 different
categories of orchestration that are fundamentally different (at
least in my head) - Service Level Orchestration and Bus Level
Orchestration (as we mentioned a few days ago). I find it
difficult to see how you solve both of them in a unified way
without first addressing each of them in isolation. I think there
are solutions there for the Service Level Orchestration.
So, I thought we were now just talking about ESB Level Orch based
on jBPM, but I get the impression now that we're talking about a
solution that merges the 2 worlds (that I see anyway :-) ). If so,
how will we make sure we can still support situations where
customers want/have a Service Orchestration solution that isn't in
our unified view of the world?
<orchestration-etc.gif>
Burr Sutter wrote:
> I've had similar debates in the past and the scenario below is a
> likely candidate for how we'll go to market on the "platform"
> therefore better integration at the "project" level makes great
> sense. The market wants SOA to solve a governance, SLA
> performance, policy enforcement and most importantly visibility
> issue (who has the ball, who dropped the ball, why was it dropped,
> how to re-route around the broken connection, etc).
>
> BPEL can actually solve this use case and we'll need to carefully
> think it through since the market is moving in that direction. If
> you wrap your task management code with Web Services then they can
> be orchestrated into a BPEL process definition.
> The crawl before we walk and walk before we run approach would be
> to take what Esteban has done with basic jBPM JPDL integration and
> smooth off the rough edges on jbpm configuration and the
> programming model and get some users on board with the ideas (such
> as the one described below). At the same priority level we'll
> need solid WS-* support and BPEL.
> Perhaps JPDL can outrun BPEL the way Hibernate outran EJB Entity
> Beans or Spring outran Session Beans but I'm not so sure of that.
> jBPM has to become much, much more user friendly for both service
> orchestration and human task-management. It needs an eco-system
> of people writing articles and books. It needs a series of
> demonstrations/examples that illustrate its utility. We'll need
> to find a way to increase its mass adoption. In theory, jBPM
> should be at least 30% as utilized as Hibernate and Spring. With
> a well developed ESB approaching the same utilization of J2EE
> application servers.
>
> So the whole BPEL vs JPDL is whole new debate!
> I think better integration between the ESB & jBPM is something we
> have wanted for quite some time. Now we'll just need to hammer
> out the details and get some feedback on the user experience
> related to the basic integration that has already occurred.
> Concepts like Advanced Splitter/Aggregator have been on the task
> list for a little while now and they are likely candidates for
> jBPM since the "advanced" part is related to long-running processes.
>
> In any case, the original debate was related to replacement of the
> ESB action framework with jBPM's JPDLs action framework. I'm not
> sure if we've resolved that concern just yet.
> Bill Burke wrote:
>> Yeah, Burr. This is exactly the overall picture I envisioned. I
>> don't see how BPEL could solve such a use case where your overall
>> flow involves both a messaging system(s) and various web
>> applications.
>>
>> This is why I think it is crucial for ESB and jBPM to be built
>> upon the same component model and core engine. In your use case
>> below, there really is no clear separation between the ESB and
>> your process flow. You might want to do transformations between
>> page flows, fork a notification to a backend system, wait on a
>> task to be performed by a web application. Do you see how it all
>> bleeds together and why it all needs to be one integrated product?
>>
>> Please, keep arguing. My initial push of having deeper
>> integration between ESB and jBPM was based on intuition. The
>> more I dive into it, the more I think my intuition was correct,
>> but I am still not totally sure.
>>
>> Bill
>>
>> Burr Sutter wrote:
>>> Human-centric means there are some features that are
>>> particularly important like management of swim-lanes, group task
>>> queues, individual user task queues and a dynamically rendered
>>> website that allows end-users (accountants, lawyers, clerks,
>>> etc) to interact with process instances (with supervisor
>>> override capability). The website/console alone requires about
>>> 30+% of the jBPM's teams current resources.
>>> With our current ESB+jBPM integration we should be able to
>>> orchestrate a single "process" between multiple ESB-hosted
>>> services and humans. Consider this scenario:
>>> 1- An order is received via FTP
>>> 2- Order is routed to a validator
>>> 3- Order is routed to a transformer
>>> 4- Order is over $500 and therefore must be sent to a group task
>>> queue (the order processing team)
>>> 5- Simultaneously an async credit check request for the customer
>>> on the order header is made
>>> 6- Process goes to sleep and awaits a response from the order
>>> processing team and the credit check
>>> 7- Once the credit check returns the process is now only waiting
>>> on the order processing team
>>> 8- Every 2 hours an alert is sent out to the order processing
>>> team to let them know that this order is getting old
>>> 9- Sally (a member of the order processing team) picks up the
>>> order from the group queue and moves it to her own queue
>>> 10- She visually inspects the order (nicely transformed by step
>>> 3) and visually inspects the credit report. While the customers
>>> credit score from Dun and Bradstreet is somewhat poor, the
>>> customer has excellent payment history with our business
>>> therefore Sally makes this additional note on the record and
>>> pushes it from her queue to her supervisors (additional approval
>>> required).
>>> 11- Her supervisor is currently out on vacation
>>> 12- Her supervisor's supervisor is covering these tasks and logs
>>> into to finish the order
>>> 13- Now that all approvals are secured the order is routed to
>>> the approach fulfillment team
>>> 14-Parts of the order require service activation (e.g. this is
>>> an order for a new cell phone hardware and services) so those
>>> line-items are split off and routed to the appropriate team -
>>> that team's queue is updated to reflect the needed work (e.g.
>>> some services require the dispatch of field workers)
>>> 15-Parts of the order require multiple warehouses to be notified
>>> and used (e.g. one line-item is for a phone from warehouse A,
>>> another line-item is for an blue tooth earbud from warehouse B)
>>> both warehouses respond with real shipping costs (note customer
>>> has already been quoted so this is just to offset the real book
>>> keeping)
>>> 16-Various email alerts are collected and properly organized and
>>> sent out to concerned parties (e.g. the person who initiated the
>>> order is notified that it has shipped)
>>> 17- Once all parties report in that there part of the order has
>>> been fulfilled then accounting is alerted, the executive
>>> dashboard is updated, etc)
>>>
>>> My ESB+jBPM should allow me to see this process laid out
>>> visually. Allow me to make ad-hoc process changes to both
>>> process instances that are "above" the current change (altering
>>> step 14 for all new process instances and process instances
>>> living prior to step 14). Allow me to have complete visibility
>>> into how "long" something is taking at any given step (so I can
>>> fire my order processing team). Allow me to understand who/what
>>> is perform optimally (number of orders processed, complexity of
>>> orders, warehouse A team is rocking along, etc). Assuming this
>>> end-to-end process involves various 3rd parties (e.g. partners
>>> who fulfill parts of the process), legacy systems (e.g mainframe
>>> customer history system) and you still want a robust, easily
>>> reconfigurable solution - well that is the promise of SOA for
>>> the enterprise.
>>>
>>>
>>>
>>>
>>> Tom Fennelly wrote:
>>>> Excuse my ignorance, but why exactly do they differentiate
>>>> between the different types of orchestration (human, service
>>>> etc)? I'd have just imagined it all as being event-centric,
>>>> with whatever triggers (??) the event as being somewhat
>>>> secondary. Where does that fall down??
>>>>
>>>> Burr Sutter wrote:
>>>>> jBPM 4.0 isn't due until late Q1/early Q2 2008. If we had
>>>>> specific requirements we might be able to get the jBPM team
>>>>> focused on a deliverable between now and and then but the
>>>>> challenge for jBPM is focus: human-centric BPM/workflow or
>>>>> service-centric orchestration.
>>>>> Bill Burke wrote:
>>>>>> Huh? I'm confused on exactly what 4.2 is. Mark told me that
>>>>>> it should basically be in maintenance mode and only one
>>>>>> person was going to be maintaining it while the rest of the
>>>>>> team focused on 5.0.
>>>>>>
>>>>>> Better integration, not a single repository.
>>>>>>
>>>>>> Burr Sutter wrote:
>>>>>>> What is your timeframe for this concept?
>>>>>>> I don't believe there are enough bodies to throw at jBPM
>>>>>>> 3.3/3.4 and ESB 4.2 to get them both out the door by June
>>>>>>> 2007 to bring those different worlds closely in-line. Are
>>>>>>> you proposing a single repository/single codebase or simply
>>>>>>> looking for better integration?
>>>>>>> Burr
>>>>>>>
>>>>>>> Bill Burke wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> Bill Burke wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Burr Sutter wrote:
>>>>>>>>>> The "cons" for jBPM-based
orchestration:
>>>>>>>>>> - Does require learning of jPDL and jBPM actions.
This
>>>>>>>>>> is not a trivial undertaking.
>>>>>>>>>
>>>>>>>>> This is a relevant issue, but I think we can refactor
base
>>>>>>>>> jbpm to handle the simple usecases.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> - 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.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I think this is an irrelevant issue. This can be
fixed.
>>>>>>>>> ESB 4.0 release had the same problems.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Let me expand on this. Burr, we have to stop thinking of
>>>>>>>> other JEMS projects like black boxes.
>>>>>>>>
>>>>>>>> a) Its all open source
>>>>>>>> b) We all work for the same company
>>>>>>>> c) jBPM team is under Mark anyways
>>>>>>>>
>>>>>>>> We need to foster cross-contributors.
>>>>>>>>
>>>>>>>> Bill
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> esb-dev mailing list
>>>>> esb-dev(a)lists.jboss.org
>>>>>
https://lists.jboss.org/mailman/listinfo/esb-dev
>>>
>>
>
<orchestration-etc.gif>
_______________________________________________
esb-dev mailing list
esb-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/esb-dev