Hi guys, Thanks for your feedback!
2007/10/9, Alex Boisvert <[EMAIL PROTECTED]>: > On 10/9/07, Tammo van Lessen <[EMAIL PROTECTED]> 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 anyways. > > 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 :) Cheers, Tammo -- Tammo van Lessen - [EMAIL PROTECTED] - http://www.taval.de
