OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsdm message

[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 kreger@us.ibm.com (~ 05-Oct-04 2:08 PM ~)...
The document Manageability Capabilities.091004.doc has been submitted by Heather Kreger (kreger@us.ibm.com) to the OASIS Web Services Distributed Management TC document repository.
  
I just want to clarify that my understanding of this is correct and what it really means...

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:fred.carter@amberpoint.com
tel:+1.510.433.6525 fax:+1.510.663.6301


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]