- From: John Kaputin (gmail) <jakaputin@gmail.com>
- Date: Fri, 4 May 2007 09:48:52 +0100
- To: "Jacek Kopecky" <jacek.kopecky@deri.org>
- Cc: "Arthur Ryman" <ryman@ca.ibm.com>, "John Kaputin" <KAPUTIN@uk.ibm.com>, "WS-Description WG" <www-ws-desc@w3.org>, woden-dev@ws.apache.org
- Message-ID: <4c2ae8f80705040148j1c449013i62b33a4e13f3cd6d@mail.gmail.com>
Hi Jacek, good point! I guess I was thinking at the document level rather than the component model when I proposed the qname argument in my example. What we have now, in the statically defined API, are methods that refer explicitly to extension properties - like getSoapMepDefault() or getSoapVersion(). I think we can replace these with a generic style of getter method that takes the type of extension property as an argument....but not as a qname argument. Rather as a 'name' in some other format, as you suggest. For the pre-defined extensions these could be defined as constants on the Woden API, but in anycase the new extension programming model should probably include a mechanism to register the 'names' of the extension properties so that other extensions can be easily used with Woden. Will give this more thought when I get on to WODEN-42. thanks, John. On 5/3/07, Jacek Kopecky <jacek.kopecky@deri.org> wrote: > > 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 Friday, 4 May 2007 08:48:54 UTC