extensions in WSDL CM, in Woden

Hi John, 

thanks for the background info, I now understand better how Woden got
where it is. Since I have my workaround, which does the job with the
exception of the relatively minor bug WODEN-158, the fix is not urgent
for me.

Alas, there is one point in what you described that might get hairy:

While WSDL extensions are namespace-qualified, the WSDL component model
properties resulting from these extensions are not. For instance,
wsoap:mep results in {soap mep} property. In fact, another extension,
my:fancyDefaulting="true" for instance, may also create {soap mep}. 
I believe this is the intention of the WSDL spec. How should Woden react
to this kind of situation?

IMO, getExtensionProperty() should be able to take the name like "soap
mep" and not just the qname like wsoap:mep. Both options could be
offered. But just with the qname, it could be hard or counterintuitive
to implement my:fancyDefaulting as a Woden extension.

Just something that we may want to be cautious about,
Jacek

On Thu, 2007-05-03 at 17:49 +0100, John Kaputin (gmail) wrote:
> Jacek,
> Originally, in Woden M6 (mid-2006), extension properties were grouped
> strictly by namespace into statically defined types like
> HTTPBindingExtensions and SOAPBindingExtensions. So the
> isHttpCookies() method was only present on HTTPBindingExtensions and
> to retrieve the extension properties of a Binding component where the
> binding type was SOAP and the protocol was HTTP, two invocations of
> Binding.getComponentExtensionsForNamespace(uri) were required; one
> specifying the SOAP namespace to return SOAPBindingExtensions and one
> for the HTTP namespace to return HTTPBindingExtensions.
> 
> At the 2nd WSDL2 interop in November a different POV was put forward
> that it should be possible to get all of the extension properties for
> a binding 'type' in one go. So for a SOAP binding type the method call
> Binding.getComponentExtensionsForNamespace(soap NS uri) would return a
> SOAPBindingExtensions object that exposed the SOAP extensions
> properties and also, if the protocol was HTTP, the relevant HTTP
> extension properties. Hence the duplication of some of the HTTP
> extension properties in the SOAP extension interfaces. This is what we
> ended up with in Woden M7, although the method should probably have
> been renamed to getComponentExtensionsForBindingType(uri) which more
> accurately reflects it's current behaviour. 
> 
> However, that doesn't solve the problem you pose.
> 
> I think the fundamental problem is that the extensions API evolved
> from my data model view of the extension properties rather than a
> proper understanding of their use cases and we've ended up with this
> grouping of extension properties into statically defined interfaces
> and methods. A meeting with Glen Daniels at ApacheCon last year about
> extensions use cases for tools and generic GUIs led me to open JIRA
> WODEN-42 to change the extensions programming model to make it more
> generic and flexible. Due to CR completion priorities I didn't have
> time to implement the solution, but I have now targetted WODEN-42 for
> our next milestone M8 and I intend to start working on it when I've
> completed WODEN-122. Your description of your RDF mapping requirements
> is both useful and timely.
> 
> With WODEN-42 I expect there will be some new abstraction representing
> an extension property and methods available on WSDL components to
> return a collection of extension properties by some criteria. As
> examples, getExtensionPropertiesForNamespace(uri) and
> getExtensionPropertiesForBindingType(uri).  I think there will also be
> methods to retrieve a specified property - for example,
> getExtensionProperty(qname).  I think I can understand your use case
> from your previous post and I'll post again when I have some code in
> Woden trunk for you to try out, but in the meantime tell me if you
> have any requirements that I may not have covered above.
> 
> regards,
> John Kaputin.

Received on Thursday, 3 May 2007 17:36:29 UTC