Re: [ws-dd] Issue 137 - DPWS - Discovery/Service types WSDL attribute

[Antoine Mensch <antoine.mensch@odonata.fr>]

Hi,

This issue is related to issue 25, and contains one possible concrete 
proposal to solve the issue. I see a couple of problems with the proposal:
- it assumes that a given portType (implemented by a hosted service) is 
hosted by a single type of devices. This may not be true in all cases, 
as new devices may be defined that reuse that existing portType. 
Allowing multiple QNames in the attribute could partially solve the 
problem, but it would still require to edit the WSDL of the hosted 
service every time a new device reuses it.
- a more formal problem is that QNames are normally defined within 
specific documents such as XML Schemas and WSDLs. Where will the QName 
for device types be defined then?

Cheers

Antoine

Ram Jeyaraman a écrit :
>
> 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]
>
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - http://www.avg.com 
> Version: 8.0.176 / Virus Database: 270.9.18/1850 - Release Date: 15/12/2008 17:04
>
>