On 8/19/07, Nicolas Modrzyk <[EMAIL PROTECTED]> wrote: > > Hi list, > > Trying to find a way to introduce BPEL4People callbacks to the > current BPEL compiler in Ode.
Cool! So this would possibly implies: > - a new BPEL20WithPeopleCompiler class that would extend BPELCompiler > - a new WSDLFactoryBPEL20WithPeople class that would implement > WSDLFactory4BPEL > - Some modifications to the BpelC class to handle those new classes > - extensions to the XPath compiler, as proposed by the people spec > (- and quite a few others changes, but trying to limit the scope > right now) Actually I'm not sure we should have subclasses for this and try to isolate it from the rest of the code. BPEL4People requires BPEL anyway and having in built-in in ODE isn't really a problem either, it doesn't "leak" on other functionalities. So I would just add BPEL4People extensions to the current code, ODE would just support both BPEL and BPEL4People natively. Given that the BPEL4People spec is an extension to BPEL, it looks to > me kind of orthogonal to what is currently done to implement the bpel > specs. It is, but I don't think that it necessarily means that they must be separated. Actually it's a good reason to have then together as they don't conflict. So, if a new BPEL spec comes out (say 3.0) and the extension for > people is still there, that requires to duplicate the code quite a bit. We already need to support several versions of BPEL, ODE has side by side support of 1.1 and 2.0. Just like a J2EE app server needs to support different versions of the spec. So I don't think that's a problem either. Would it be better for example to take a BPEL compiler implementation > as a parameter to some kind of newInstance() method call ? > Something like: > Bpel4People.newInstance(BPEL20Compiler) > > What do think ? What would be the better approach ? So to conclude, I'd just recommend you add your code directly into existing classes, without trying to "partition" things. It doesn't mean that things can't be refactored if parts of the existing code doesn't play nice though or that you can't use separate packages, just that BPEL4People, I think, doesn't need to be something pluggable. So you would just have the same compiler, add BOM elements for BPEL4People activities, add methods on the existing BPEL BOM to support BPEL4People extension attributes, add needed XPath functions and that's pretty much it. Does that make sense to you? Any other opinion? Cheers, Matthieu Thanks you in advance for any ideas or pointers, > > Niko, > > > >
