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