[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsdm] Groups - Manageability Capabilities.091004.doc uploaded
Thus quoth firstname.lastname@example.org (~ 05-Oct-04 2:08 PM ~)...|
I just want to clarify that my understanding of this is correct and what it really means...The document Manageability Capabilities.091004.doc has been submitted by Heather Kreger (email@example.com) to the OASIS Web Services Distributed Management TC document repository.
As background, in many discussions, we [and others] talk of cut & paste inheritance/extension for portTypes/interfaces for WSDL 1.1. For better or worse, that's what there is until WSDL 2 comes along. In some places, there is the use of attribute extension to back-port "hints" as to what some portType extends. Fine.
The Manageability Capabilities document says (amongst other things)
Manageability capabilities are identified by the QName of the portType that declares a capability (the “capability portType”).I think that this means that if some service wishes to advertise that it support some WSDM managability capability, then it must (or SHOULD) advertise a portType named wsdm:identity (say), where wsdm is set to the WSDM namespace (or one of them).
If this is the case, then a service supporting multiple capabilities must define a separate port for each, since a binding can support at most one port type, and a port can reference at most one binding.
Moreover, in WSDL 1.1, a portType's name is a nmtoken, that is an NCName. Its namespace is the targetNamespace of the WSDL file (or, more correctly, the enclosing <wsdl:definitions/> tag) in which a portType finds itself. Since that's the case, the WSDL file for a service which supports some WSDM capabilities will import the WSDM WSDL file(s), obtaining its portTypes therefrom, then referencing them in the associated bindings. That's fine -- just want to clarify.
One could argue that it's the operations that count, and since operations are really just a notational convenience anyway, it's really just the message [exchanges] that count, so no one needs any separate portTypes. If that's the case, why equate/notate a capability with a portType?
As it stands, I think that this means that if I were to offer a managability provider endpoint which supported metrics & identity, its WSDL would look something like this... (replace the namespaces with the right things...)
<wsdl:definitions name="fredsExample" targetNamespace="urn:freds:example" xmlns:metrics="urn:muws:metrics" xmlns:identity="urn:muws:identity"...> <!-- These each suck in the schema, porttype & bindings... --> <wsdl:import namspace="urn:muws:metrics" location="somePlace @ oasis"/> <wsdl:import namspace="urn:muws:identity" location="someOtherPlace @ oasis"/> <!-- If I want to restrict the operations supported, I reproduce a subset of the included binding, leaving out the uninteresting bits? --> <wsdl:service name="fredService1"> <wsdl:port name="metricPort" binding="metric:SoapBinding"> <soap:address location="http://foo.com/bar"/> </wsd:port> <wsdl:port name="identityPort" binding="identity:SoapBinding"> <soap:address location="http://foo.com/bar"/> </wsd:port> </wsdl:service> </wsdl:definitions>
-- Fred Carter / AmberPoint, Inc. mailto:firstname.lastname@example.org tel:+1.510.433.6525 fax:+1.510.663.6301