Re: a few Woden problems

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.

On 5/2/07, Jacek Kopecky <jacek.kopecky@deri.org> wrote:
>
>
> Arthur, John,
>
> I think I understand, but I also think that such approach is somewhat
> short-sighted. The thing is - the HTTP properties are not changed by
> being reused (in particular, the names and the extension attributes stay
> the same) so I expect that they should be accessible as HTTP properties,
> whether or not they are also accessible as SOAP properties as well.
>
> With the current Woden design, I can have some extension properties (in
> this case HTTP properties) and extend Woden to handle them, but somebody
> else can create other extensions (like another binding, in this case
> SOAP) and extend Woden and invalidate my old way of getting to my
> properties that haven't changed at all. None of the extensions involved
> is mustUnderstand, therefore they shouldn't have such effects on each
> other.
>
> I guess the question is whether the meaning of a property like {http
> location} can change with the presence of other non-mustUnderstand
> extension properties or values. The change of the meaning would give a
> reason for an API change.
>
> Wondering what John thinks,
> Jacek
>
> On Wed, 2007-05-02 at 15:56 -0400, Arthur Ryman wrote:
> >
> > Jacek,
> >
> > I believe the rationale is that the binding is SOAP but it just
> > happens to reuse some properties defined in the HTTP binding. I am
> > including John who can give his opinion.
> >
> > Arthur Ryman, PhD, AoT, DE
> > Process and Portfolio Management, Rational Division
> >
> > phone: +1-905-413-3077, TL 969-3077
> > assistant: +1-905-413-3831 (T/L: 318-8867)
> > fax: +1-905-413-4920, TL 969-4920
> > mobile: +1-416-939-5063, text: 4169395063@fido.ca
> >
> >
> > Jacek Kopecky
> > <jacek.kopecky@deri.org>
> > Sent by:
> > www-ws-desc-request@w3.org
> >
> > 05/02/2007 02:42 PM
> >
> >
> >                To
> > Arthur
> > Ryman/Toronto/IBM@IBMCA
> >                cc
> > WS-Description WG
> > <www-ws-desc@w3.org>
> >           Subject
> > a few Woden
> > problems
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Hi Arthur,
> > I uncovered a few more Woden problems. If I'm emailing you improperly,
> > please let me know who to address instead.*
> >
> > 1) (design) the SOAP binding reuses HTTP properties. In Woden, the
> > reused properties are returned when looking at the SOAP extensions
> > (for instance SOAPBindingExtensions.isHttpCookies(), and all similar
> > occurrences). I believe this is counterintuitive - when I'm looking
> > for
> > the value of the {http cookies} property on a binding, it's defined by
> > a
> > WHTTP extension attribute and it should be available under that
> > namespace.
> >
> > Why do I care? The RDF binding maps {http cookies} into the same thing
> > whether it is on an HTTP binding or on a SOAP binding, and I must
> > check
> > two different extensions to get the value of this property.
> >
> > SOAPBindingExtensions.isHttpCookies(), if it's there at all, should
> > IMHO
> > be syntactic sugar for HTTPBindingExtensions.isHttpCookies() on the
> > same
> > binding, but as it is, I don't even get HTTPBindingExtensions on a
> > SOAP
> > binding. The type of a binding should not dictate the namespaces of
> > allowed extensions, or under what namespaces one can find some
> > properties. I don't think the spec intends that.
> >
> >
> > 2) (may get obsoleted if you agree on the point above)
> > SOAPBindingOperationExtensions does not have
> > isHttpLocationIgnoreUncited
> > even though the SOAP binding seems to import this property (cf. first
> > bullet in section 5) Currently, Woden does not give me the value of
> > this
> > property on SOAP bindings.
> >
> >
> > 3) InterfaceImpl.getAllInterfaceOperations and getAllInterfaceFaults
> > are
> > not quite recursive, they only go one level of interface extension
> > deep.
> > This manifests in the flickr test-suite WSDL file when trying to
> > access
> > the InterfaceOperation of the BindingOperation for
> > "flickr.groups.pools.add" - the method getInterfaceOperation() returns
> > null because the actual operation is too deep in the hierarchy of
> > extended interfaces.
> >
> > Fix: in both InterfaceImpl.getDerivedInterface*, change getInterface*
> > to
> > getAllInterface* - this can get into an infinite loop if a circular
> > interface extension is not detected as an error first.
> >
> >
> > For the purpose of finishing the RDF mapping, I have a work-around for
> > 1), I fixed 3) in my copy of Woden, but I can't easily fix 2).
> >
> > Best regards,
> > Jacek
> >
> > *P.S: I don't want to have to subscribe for a mailing list or register
> > in a bug reporting system, though, to be able to submit these
> > questions.
> >
> >
> >
> >
>
>
>