ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Maciej Szefler" <...@intalio.com>
Subject Re: Extending ODE
Date Tue, 09 Oct 2007 18:09:52 GMT
Tammo,

see comments:

On 10/9/07, Tammo van Lessen <tvanlessen@gmail.com> wrote:
>
> So, lets begin with the parser and compiler, actually nothing special
> happened here but the object model has slightly changed so that we'll
> lose binary compatibility with Ode 1.1 processes. This is mostly


We'd like to avoid binary compatibility changes as much as possible since
they are very disruptive. So I would suggest that the runtime code check the
field containing ExtensionAssignOperations for nullity and interpret this as
"no extension". This will allow for backwards compatibility, since
Serialization can handle new fields popping up.

because the OAssign class was changed to contain both Copies and
> ExtensionAssignOperations. Additionally the compilers knows now how to
> handle <extensionActivity>, <extensions> and <extension> elements and
> also checks whether extension namespaces have been declared or not.
> 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 think I agree with Alex on this. The general approach thus far (for
example if you look at the way expression languages are handled) has been to
provide a compile-time component and a run-time component. It's  a little
bit more of a hassle, since the compiler has to be informed of the available
extensions, but worth it in my view.


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


My vote is whole object model. We've got plenty of abstractions to go
around, adding more will just create more code maintenance issues. Also, I
think we should view these "extensions" as first-class objects, i.e. it
should be possible to reimplement the functionality of any activity as an
extension.


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


so... per above, a definite yes on access to JACOB specific stuff; otherwise
the extensions will be rather limited in power. Of course that is not
suggest that there should not be some way to easily implement extensions
that do not need that additional baggage.

Cheers (and sorry for the lengthy mail, I hope it was worth reading :)
>   Tammo


Great job btw. I have a feeling this will be a very popular feature.
-mbs

[1] http://fisheye6.cenqua.com/browse/ode/trunk/bpel-test/src/test/java/org/apache/ode/test/ExtensibilityTest.java?r=582679
>
>
> --
> Tammo van Lessen - tvanlessen@gmail.com - http://www.taval.de
>

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