So, in the case where we replace the ODE Process Store module with one implemented by Tuscany, is this new module going to be responsible for handling all the versioning and matching a running process instance with the right BPEL process version ?
Also, can the modules that handle deploy.xml and process store be implemented separately (e.g Tuscany would handle deploy.xml but still use ode process store module) ? Thanks Luciano On Mon, May 19, 2008 at 11:23 AM, Matthieu Riou <[EMAIL PROTECTED]> wrote: > On Mon, May 19, 2008 at 9:11 AM, Mike Edwards < > [EMAIL PROTECTED]> wrote: > >> Folks, >> >> I am interested in getting rid of the need to have a physical deploy.xml >> file in the directory with a BPEL process file. >> >> Can I supply the same information to the ODE runtime through some other >> means, such as method parameters or some in-memory mechanism? >> > > The short answer is: yes, you can. The long answer is... a bit longer :) > > >> >> For the SCA integration, the SCA runtime has all the information contained >> in the deploy.xml file, but in another form. It would be great to relieve >> the developers from the need to create this file. >> > > Let me explain a bit how that works. The ODE runtime doesn't know anything > about the file system, descriptors or even BPEL files. It just knows that > something is supposed to call it, passing an interface implementation > (ProcessConf [1]) that provides everything it needs (and a bit more > actually). It's so dumb that it doesn't even know which processes it should > know about, so every time the server is restarted, it expects to be called > again with the same process definition information. > > Parrallely in ODE we have a process store that handles all the nitty gritty > details of knowing where is what in which version and remembering it. The > process store doesn't know about the runtime and the runtime doesn't know > about the store. The advantage is that, in theory, you could pick different > clustering models (one store / multiple servers, multiple stores / multiple > servers) depending on how you want things to be arranged. The other > advantage is that you can get rid of the store altogether if you have all > the necessary information. > > When a new process is deployed (or undeployed, or retired, or ...), the > store just produces an event. Same thing when the whole server is restarted, > the store produces several events for each process the runtime should know > about. These events are just relayed by the Integration Layer that binds the > store and the runtime and implements external communication (all the > interfaces Luciano has implemented). > > Getting back to Tuscany, what I'm thinking is that we should remove the > store (and its events) from the equation. Tuscany would just let the runtime > know when when a process is available by calling > BpelServer.register(ProcessConf), providing its own implementation of > ProcessConf. The current Tuscany integration layer already has a reference > to the BpelServer, so that's easy. The caveat is that in this case, Tuscany > will also need to compile the .bpel file to provide the CBP (Compiled > Business Process) but that's fairly painless (see > DeploymentUnitDir.compile(File) [2]). > > The net advantage of this for Tuscany will be a much better integration and > much more control over the process lifecycle. So let me know what you think > and I can help with your ProcessConf implementation. > > Cheers, > Matthieu > > [1] > http://svn.apache.org/repos/asf/ode/trunk/bpel-api/src/main/java/org/apache/ode/bpel/iapi/ProcessConf.java > [2] > http://svn.apache.org/repos/asf/ode/trunk/bpel-store/src/main/java/org/apache/ode/store/DeploymentUnitDir.java > > >> >> Yours, Mike Edwards >> Apache Tuscany team. >> > -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/
