I do understand the need to maintain the "whole" reply-to EPR as it has the
context of the last node which is important. With that said, it is fairly common to have
the ESB expose a WS endpoint (using either the 181+SOAPProcessor or XSD based mechanisms)
and have the WS provide a response, synchronously to its waiting client.
One goal is to orchestrate multiple ESB hosted services and have the "composite"
response sent back to the waiting client. In this case, there are no wait states in the
jBPM process. This same use case should be achievable via routers as well.
Another goal is to start the business process via a EBWS/SOAPProcessor, return some
context variable to the waiting client (e.g process instance id) so that the client can
return at some later date to inquiry about the process status, the process instance
variables, cancel/kill the process instance or if it is waiting tell it to move forward
(aka signal).
Kevin, I believe that you are very wary of signal because the command doesn't know if
the process instance is in a known/consistent state. Signal doesn't take into account
that it is possible that another user via some other mechanism has already signaled that
same instance. Plus, there are challenges with forks which involve multiple token ids
instead of the single process instance id.
So I believe the following use cases are valid:
- Inquiry about a process instances status (running, completed)
- Inquiry about a process instances variables (get me the order total)
- Cancel/kill a process instance
Do we agree on those?
Burr
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4197738#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...