ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matthieu Riou" <matth...@offthelip.org>
Subject Re: Extend BPEL
Date Mon, 20 Aug 2007 21:24:49 GMT
On 8/19/07, Nicolas Modrzyk <Nicolas.Modrzyk@macnica.com> wrote:
> Hi list,
> Trying to find a way to introduce BPEL4People callbacks to the
> current BPEL compiler in Ode.


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

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?


Thanks you in advance for any ideas or pointers,
> Niko,

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message