[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: Issue 137 - DPWS - Discovery/Service types WSDL attribute
|
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
| www.microsoft.com
| V: +1 425 706 2792 | M: +1 206 790 6377 | F: +1 425
708 4811 From: Dan Driscoll 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 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
| 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] 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] 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 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]