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 <mailto:esb-dev@lists.jboss.org>
>
https://lists.jboss.org/mailman/listinfo/esb-dev