Hi Alex, thanks for your answer.
extensionActivity and extensibleAssign are both placeholders for extensibility element and thus have little semantic of their own. The BPEL compiler should be able to parser those and store them in the internal runtime object model for later processing (much like any extension element).
As far as I can see, the BPEL20Graph would choke on these elements since they are not in a extension namespace but in the BPEL 2.0 namespace?
However, as of today, Ode does not implement any BPEL extensions so placing anything in those elements would not effect much. You would need to extend the BPEL runtime to implement the behavior of your specific extensions.
I see. One might consider implementing a default extensionActivity which delegates the actual execution via a defined interface to some kind of extension plugin (identified by a qname). But this would need some investigation of what kind the most extensionActivities would be. For "basic activities" equivalents it is probably possible to hide the JACOB stuff behind an interface. For structured activities I don't know if it is feasible. Anyway, I think such a plugin mechanism for extension would be a great feature for Ode, wouldn't it be nice?
What extensions are you considering?
It will be actually an invoke activity, but without portType/operation pairs to realize some kind of dynamic binding. Best, Tammo -- Tammo van Lessen - [EMAIL PROTECTED] - http://www.taval.de
