Hi guys, last weekend I committed support for extension activities and assign operations to the ode trunk.
Before documenting the API etc. in the wiki I'd like to discuss the extension mechanisms with you in order to find any misconceptions. 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 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. This leads us to the runtime part: I added 3 abstract classes / interfaces to the API module: o ExtensionContext o ExtensionOperation o AbstractExtensionBundle To implement a new extension, implement a new extension bundle which is responsible for a certain extension namespace and register one or many ExtensionOperation implementations. The latter contain the code to be executed by the extension and are bound to a particular localname. So the namespace part of a BPEL extensibility element identifies the ExtensionBundle and the local name of the element identifies the ExtensionOperation class within this bundle (Downside: it is not possible to have more than one bundle for the same namespace). See [1] for an example. The ExtensionContext provides a collection of useful functions to be used within the extension to interact with the engine (i.e. readVariable, writeVariable, etc.). 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? 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 thats basically it, of course I'm curious what you guys think of it. Should we also add an "extension zoo" to list our own and third-party extensions? Where should we put our own extensions? (sandbox, or trunk/extensions, or something?) 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 :) However this raises another question to the OS license experts of you: Is it allowed to depend on Mozilla Rhino (MPL/GPL)? Cheers (and sorry for the lengthy mail, I hope it was worth reading :) Tammo [1] http://fisheye6.cenqua.com/browse/ode/trunk/bpel-test/src/test/java/org/apache/ode/test/ExtensibilityTest.java?r=582679 -- Tammo van Lessen - [EMAIL PROTECTED] - http://www.taval.de
