Here are two examples / use cases: --------------------------------------------------------------- First, we have an organization that wants to accept loan applications via web services from various sources. In this case, the logical loan application process is a long running process containing human tasks. So, they want to expose one Web Service on the ESB that accepts the loan application and begins processing it. An email will be sent when the application is approved or denied, but they also want to provide a mechanism for the requester to check status while the process is running. So, they want to expose a second web service on the ESB that allows the requester to get back status on the loan application in process. This status may be stored in a textual jBPM variable or maybe the ESB service returns the root token's current process node name or something. The point is, without the process instance ID that was created with the application submission, how will the status check web service be able to know which process ID to check for intermediate status? --------------------------------------------------------------- Second use case - something NAVTEQ was wanting to do and something another SA's customer was wanting to do (among others): Customer wants to do BPEL like service orchestration but leverage the JBoss ESB concept of a service rather than be limited to and deal with the complexity of SOAP services. For this case, let's use the same loan application example, but let's say that now the loan application process is completely automated. There is still the initial SubmitLoanApplication WS, but it actually synchronously returns an approved or denied message. There are several steps to the loan application. First, we need to validate the application (ValidateApplicationService), then, we need to do a quick credit check (CreditCheckService), then we need to check for existing loans (RetrieveExistingCustomerLoans), then, we need to calculate a loan rate based on customer info, credit score, etc. (CalculateLoanRate), finally, we need to kick off a separate process that starts the loan process or puts the loan in a queue or something. Of course, there are conditional paths in here too. For example, based on the type of loan, we may call different CacluateLoanRate service or something, or if the RetrieveExistingCustomerLoans actually returns some existing loans, we may need to do some checking on them, etc. So, customer has these individual services exposed on the bus. They've got the orchestration of the service defined in jBPM so they can create it easily, see it easily, change it easily without pausing acceptance of applications, etc. They want the initial SubmitLoanApplication WS to accept the request, synchronously kick of the jBPM orchestration, wait for the process to finish, and return the contents of a loanDecision jBPM variable or something more complicated. Currently, the only way to do something like this (that I'm aware of) is with Sync Continuation which means the customer really has to understand the internals of our ESB, has to create a separate replyTo service in the ESB and update the jBPM process to call back to it so that the replyTo service can response to the replyTo endpoint of the original SubmitLoanApplication WS that is basically hanging out there waiting for a reply-to message. I'm sure some of my terminology is wrong there, but the point is that the customer doesn't want to hear about that complexity. They want to just create a SubmitLoanApplication WS, have that service kickoff the jBPM service orchestration, and return a result when the jBPM process finishes. --------------------------------------------------------------- Please let me know if these do not make sense. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4197725#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...