"burrsutter" wrote : 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.
Sure, but this can already be done.
"burrsutter" wrote : 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.
Actually there are wait states, at least one with every invocation of an ESB service.
"burrsutter" wrote : 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).
Kill is certainly valid, and we have agreed to include that. Signal is not however as
there is insufficient information to do this safely.
"burrsutter" wrote : 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.
Not only forks but loops
"burrsutter" wrote : 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
Status and killing are certainly valid, I agree with those.
I think we need to discuss the process instance variable scenario further before deciding
on that course. It would be restricted to root tokens only (i.e. global variables) and
there is absolutely no guarantee of the process state (and therefore variables) when you
query it. Having the process instance inform a service would be a cleaner way of handling
this scenario.
Kev
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4199161#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...