ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tammo van Lessen" <tvanles...@gmail.com>
Subject Re: Extending ODE
Date Tue, 09 Oct 2007 19:28:58 GMT
Hi guys,

Thanks for your feedback!

2007/10/9, Alex Boisvert <boisvert@intalio.com>:
> 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 tried to avoid that. When each extension is able to extend the
O-model, we will completely lose binary compatibility. That's why I
just introduced as few fields and classes in the O-model as possible.
But I agree, an extension point in the compiler for an
extension-specific syntax/semantic validation is a very good idea.
I'll go for it.

> I agree we do not require the runtime implementation to be available at
> compile-time.
So then the compiler just cannot validate the extended BPEL code but
will compile it

> 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
> engine.
That's what I think, too. So then I'll also expose getters for the
related OActivity and the scopeFrame (also the ACTIVITY?) plus some
convenient methods like readVariable([O]Variable) and
readVariable(String) etc. Then it's possible to access the
BpelRuntimeContext which actually should be sufficient for the most
cases. If not one would need to modify the engine anyhow :)

>> 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 hoped to hear that. I absolutely agree and I'm glad that I don't
need to tackle it :)


Tammo van Lessen - tvanlessen@gmail.com - http://www.taval.de

View raw message