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. >
