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

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

Hi Toby,

I actually think your initial understanding and concerns are shared by 
many people, especially in the case where one would like to specify a 
family of related devices (as might happen in vertical committees). I 
think Dan's proposal works well in cases where a device is an aggregate 
of unrelated services (like in his example below), as well as for some 
technical generic services like a management service. On the other hand, 
it is not as convenient for devices that feature a lot of hosted 
services, as (i) the Hello/ProbeMatches messages will likely become too 
large and (ii) the client will need to construct a extensive list of all 
types supported by a given device to make sure it is retrieving the 
right one when doing a Probe. For instance, consider an industrial 
application where a machine is made of several devices, like an assembly 
line including a driller and a conveyor. Both devices feature a Motor 
service, but it very likely that a client would not look for a Motor 
device before operating it, as the purpose of both devices is completely 
different.

So I consider that Dan's proposal is an acceptable optional DPWS 
extension to WSDL, as long as we make clear in the accompanying text 
that it is optional and does not prevent the definition of richer 
approaches to handle more complex use cases. This could also be 
explained in the white paper.

In addition, I want to make it clear that I do not consider this 
proposal to be a complete resolution for the related issue 025.

Cheers

Antoine

Toby Nixon a écrit :
>
> Amazing how someone can work with a document for YEARS and not 
> understand a fundamental principle, but that’s my problem. Coming from 
> the UPnP world, where devices can only expose a single type, it just 
> never hit me clearly that in DPWS a single device could expose 
> multiple DEVICE types. Just your explaining “The device advertises 
> both of these” made it perfectly clear.
>
> I think this is something we’re going to need to make clear, at least 
> in the white paper, for the benefit of people coming over from the 
> UPnP world, or they’ll be stuck in the same confusion I’ve been. Sorry 
> about that!
>
> Toby Nixon | Senior Standards Program Manager | Windows Device and 
> Storage Technologies | Microsoft Corporation
>
> toby.nixon@microsoft.com <mailto:toby.nixon@microsoft.com> | 
> www.microsoft.com <http://www.microsoft.com/> | V: +1 425 706 2792 | 
> M: +1 206 790 6377 | F: +1 425 708 4811
>
> *From:* Dan Driscoll
> *Sent:* Monday, January 12, 2009 3:22 PM
> *To:* Toby Nixon; Ram Jeyaraman; ws-dd@lists.oasis-open.org
> *Subject:* RE: Issue 137 - DPWS - Discovery/Service types WSDL attribute
>
> These are good questions, Toby. The short version is that the device 
> would expose both.
>
> Let’s take the case of printer which exposes a printer service (e.g., 
> PrinterService) and a memory card service (MemoryCardService). 
> Consumer printers often contain flash memory card readers.
>
> Now PrinterService is incredibly unrelated to MemoryCardService. There 
> is very little overlap in how they function and what they do, and we 
> would expect they will be standardized in completely separate 
> standards bodies. Similarly, client software for PrinterService is 
> going to be completely unrelated to client software for 
> MemoryCardService. Neither one cares about the other whatsoever.
>
> So both the printer and the memory card organizations define their own 
> device types: PrinterDevice and MemoryCardDevice. The device 
> advertises both of these. Clients for MemoryCardService know that they 
> need to search for MemoryCardDevice, and clients that search for 
> PrinterService know they need to search for PrinterDevice.
>
> I suppose it’s always a possibility that someone could define a type 
> that encapsulates both: we’ll call it MixedDevice. If this is the 
> case, PrinterService clients would now have to search for both 
> MixedDevice /and /PrinterDevice types, which doubles our WS-Discovery 
> traffic. Maybe you could build rules around MixedDevice that would 
> allow it to respond to PrinterDevice probes, but this does not work 
> with discovery proxies (suppressing and non-suppressing).
>
> Notice that I’m specifically not talking about the device /class 
> /here, because I seriously doubt that this TC wants to be involved in 
> the business of defining device classes. One of the big attractions to 
> DPWS is that there is no authority who defines what a “printer” 
> is—it’s up to whoever builds a printer service and client. A “device 
> class” is a very tricky thing to properly define: if a PC exposes a 
> USB-attached printer as a PrinterService, what “device class” is it in?
>
> PrinterService clients want to talk to printers. Why should they care 
> about whether it is hosted on a physical printer, a PC, or a receipt 
> printer attached to a cash register? All they care about is the 
> shortest possible path to discover and connect to a PrinterService. 
> This is what’s great about Web Services.
>
> Now there are cases where many related services may be similar enough 
> that advertising separate discovery types for each is too much 
> overhead. Example: the Kitchen Working Group may define 
> MicrowaveService and ToasterService, and decide that they want all of 
> them to use KitchenDevice. This is an acceptable solution: clients of 
> MicrowaveService and ToasterService both have a very clear path to get 
> to the service they want to use.
>
> Lastly, I want to reiterate that no spec authors would be obligated to 
> use the mechanism I’m proposing. If someone wants to build a complex 
> device/service topology, they are absolutely free to do so. They can 
> simply describe the situation in their normative text and let 
> implementers build it. This is exactly the situation we’re in right 
> now for /all /devices: implementers have to read the text and figure 
> out that PrinterDevice is used to find PrinterService. I’m proposing 
> this appendix so that in the very common case of a single device type, 
> spec authors have a very simple tool they can use to help their 
> implementers identify the right type to use in discovery.
>
> Thanks
>
> --D
>
> *From:* Toby Nixon
> *Sent:* Monday, January 12, 2009 2:04 PM
> *To:* Dan Driscoll; Ram Jeyaraman; ws-dd@lists.oasis-open.org
> *Subject:* RE: Issue 137 - DPWS - Discovery/Service types WSDL attribute
>
> What happens if you have a device that has multiple services in it? 
> Which discovery type would actually be used? Is the assumption that 
> they would all have the same discovery type? This seems to completely 
> defeat the reuse of standard services in multiple device classes.
>
> Toby Nixon | Senior Standards Program Manager | Windows Device and 
> Storage Technologies | Microsoft Corporation
>
> toby.nixon@microsoft.com <mailto:toby.nixon@microsoft.com> | 
> www.microsoft.com <http://www.microsoft.com/> | V: +1 425 706 2792 | 
> M: +1 206 790 6377 | F: +1 425 708 4811
>
> *From:* Dan Driscoll [mailto:Dan.Driscoll@microsoft.com]
> *Sent:* Monday, January 12, 2009 11:32 AM
> *To:* Ram Jeyaraman; ws-dd@lists.oasis-open.org
> *Subject:* [ws-dd] 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]
>
> ------------------------------------------------------------------------
>
>
> Internal Virus Database is out of date.
> Checked by AVG - http://www.avg.com 
> Version: 8.0.176 / Virus Database: 270.10.5/1882 - Release Date: 08/01/2009 08:13
>
>