ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Boisvert" <boisv...@intalio.com>
Subject Re: Extending ODE
Date Tue, 09 Oct 2007 15:37:16 GMT
On 10/9/07, Tammo van Lessen <tvanlessen@gmail.com> wrote:
> The compiler DOES NOT check whether  the implementation of an
> extension is installed since the compilation does not necessarily take
> place on the same system.

I'm a bit confused here;  I would have thought the extension would/could
register into the compiler to parse and validate the extension code and then
generate the necessary O-model objects.  Is this possible?    I think
compile-time validation of BPEL extensions is quite important.

I agree we do not require the runtime implementation to be available at

Here I'm still not sure whether we should abstract from the O* classes
> and provide a simplified API or that we want the extension developer
> to have access to the whole obj-model. What do you think?

I would go with the full O-model rather than a simplified API unless someone
wants to make a case for the portability of extension bundles.  Except for
simple cases, I assume intimacy is required between extensions and the

These extension bundles can then be registered to the engine via Ode's
> config file (comma separated list of class names). During hydration,
> the engine checks for mustUnderstand extensions and throws an
> exception if there are no extension bundles registered for them.


The execution of the extensions is actually straight forward. One
> thing we should discuss is : Is there a need to support 'new'
> structured activities. If so this is gonna be tricky as the extension
> developers needs access to Jacob specific stuff. Opinions on that?

I think we should cross that bridge when we have a couple use-cases lined
up.  Looking back on the activity failure extension, I don't see how we
could have provided a decent API to support that work up-front, or even
now.  This lends me to believe that structured activity extensions need to
be part of the engine.

I think thats basically it, of course I'm curious what you guys think of it.

I like it!

Should we also add an "extension zoo" to list our own and third-party
> extensions?

Yes, definitely!

Where should we put our own extensions? (sandbox, or trunk/extensions,
> or something?)

I would go with trunk/extensions.  That way, the lifecycle is the same as
the engine so it's easier to checkout, compile, and use together.

I'm currently working on an extension that allows for using
> Javascript/E4X within assign activities. This was actually thought as
> an example but now I think it is way too cool to be just an example :)

Indeed.  This is one we've had an eye on for some time.  I think we should
support it as a base extension for Ode.


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