Tammo van Lessen wrote:
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).
extensionActivity and extensibleAssign are both placeholders for
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?
Correct, we would need to add extensionActivity and extensibleAssign to
the compiler. What I meant is the infrastructure to support "any"
content in those elements is already available.
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?
Yes, I think so. Like any extension, it's up to the users to judge
whether the benefits outweigh the portability costs, but I believe it's
good to have that door open.
alex
