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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-dd message

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


Subject: RE: Issue 137 - DPWS - Discovery/Service types WSDL attribute


I keep forgetting to add a concrete example of what this would look like.  Sorry for the delay.

 

The proposed addition is highlighted.

 

<wsdl:definitions

        xmlns:wsdl="..."

        xmlns:dpws="..."

        xmlns:tns="http://example.org/example"

        targetNamespace="http://example.org/example"

        ... >

 

        <!-- WSDL Types and Messages go here -->

 

        <wsdl:portType name="WSDToasterService" dpws:DiscoveryType="tns:WSDToasterDevice">

                <!-- WSDToasterService operations go here -->

        </wsdl:portType>

 

        <!-- optionally, also include an empty portType for the device-layer type. -->

        <wsdl:portType name="WSDToasterDevice" />

 

</wsdl:definitions>

 

 

From: Ram Jeyaraman [mailto:Ram.Jeyaraman@microsoft.com]
Sent: Tuesday, December 16, 2008 7:52 PM
To: ws-dd@lists.oasis-open.org
Subject: [ws-dd] Issue 137 - DPWS - Discovery/Service types WSDL attribute

 

This issue is assigned the number 137. For further discussions on this issue, please refer to this issue number or use this thread.

 

From: Dan Driscoll
Sent: Tuesday, December 16, 2008 4:54 PM
To: Ram Jeyaraman
Subject: NEW Issue - DPWS - Discovery/Service types WSDL attribute

 

This issue covers the case where we need an automated way to identify the empty discovery-layer portType from the Hosted Service type.  Unless otherwise overridden in another spec, I expect all applications require a discovery-layer type to advertise at the Device endpoint.  We can generate much better code for these applications by inspecting these in the WSDL that defines the service-layer portType.

 

Richer type description languages may also be defined outside of DPWS 1.1, but this lightweight solution meets a basic requirement for all WSDLs built for DPWS.

 

This mechanism cannot be mandatory, since some non-DPWS WSDLs are sometimes hosted in DPWS devices, and it is unreasonable to change the WSDL solely to fit into DPWS.

 

I propose adding an Appendix that describes how applications may add an attribute to identify this discovery-layer type.

 

Proposed addition:

 

Appendix ??? – Declaring Discovery Types in WSDL

Solutions built on DPWS often define portTypes implemented by Hosted Services, and a discovery-layer portType implemented by the Host Service so the presence of these functional services can be determined at the discovery layer.  The binding between a service-layer type and its discovery-layer type can be defined purely in descriptive text, but this appendix provides an optional mechanism to declare a discovery-layer type inside WSDL that can be consumed and understood by tools.

 

This appendix defines @dpws:DiscoveryType attribute to annotate the portType for the service-layer type.  The normative outline for @dpws:DiscoveryType is:

 

<wsdl:definitions …>

    [<wsdl:portType [dpws:DiscoveryType=”xs:QName”]? >

        …

    </wsdl:portType>]*

</wsdl:definitions>

 

The following describes additional, normative constraints to the outline listed above:

 

/wsdl:definitions/wsdl:portType/@dpws:DiscoveryType

               The name of the portType to be advertised by the Host Service to indicate that this device supports the annotated Hosted Service portType.

 

                If omitted, no implied value

 

[example usage follows]



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