A related question came up on a JBDS training session today, regarding being able to debug (step through) a BPEL process.
Its something we should think about for a future version of the BPEL editor and riftsaw runtime. But we need to understand whether this will work by embedding the ODE engine in the editor, or interacting with the riftsaw engine inside the server.
Also, where a BPEL process uses a third party service, should this be replaced by a mock service (possibly appropriate in the simulation case) or use a real service - and whether this is an issue if ODE is embedded in the editor.
I was not actually thinking of interacting with the ODE engine on the server. In that case it would not really be a simulation. There would be no need for persistence, or for the simulator to send messages to actual services. Instead the simulator would "simulate" each activity. For example for an assign activity it would compare the output variable created to the sample message defined by the scenario. Perhaps a subset of ODE.
I agree in terms of simulation, however it has a number of characteristics also required for debugging a running process, so we need to understand any common features.
In terms of simulation, I think we would need to use an embedded ODE engine - we wouldn't want to reimplement the BPEL state machine. ODE can run in "in-memory" mode, so persistence is not an issue, and the invocations of external services could be handled by comparing the invoked requests against the messages in the scenario, before returning the response defined by the scenario.
Actually thinking about it, there may not be as much overlap between simulation and debugging as I first thought.
Simulation would be based on the scenarios, just using the embedded BPEL/ODE state machine instead of the choreography/protocol monitor, with the results reflected back in the scenario.
Debugging would potentially use an embedded ODE state machine, but may actually 'attach' to a running process instance on a server, with the result being reflected back in the BPEL editor.
I think might be a good idea to create the simulation feature request in the Savara project.
Correct me if I'm wrong Jeff, but it sounds like what is desired here is a more rigorous validation of the BPEL - dynamic vs static analysis. In that case, I don't think it's really necessary to get an embedded ODE involved here at all. In fact, it may even be a hinderance in a development environment where external services may not be available, or not even implemented yet.
In the case referred to by Jeff, an external service (whether implemented or not) would not be required, as its behaviour would be simulated based on information previously defined by a user, using the Savara scenario tooling.
The only reason I was suggesting an embedded ODE engine is that you need something that can interpret the BPEL process and determine when a messages should be sent/received, and how the XML should be processed between those messages - it just seems unnecessary to reimplement this BPEL state machine when ODE already provides one - as long as it is possible to strip ODE down to its based core
I think we are on the right track here with an embedded, stripped down ODE. I think doing this in Savara makes sense as well, as it is validation of an artifact. By using the same sample messages and scenarios as used with the choreography simulation, we can better ensure the the process definition remains consistent with the requirements.