Building WSDXML sections

Last year I described the general structure of WSDAPI’s WSDXML sections and provided some hints for creating and consuming these structures.  I’ve received a few requests since then to provide more concrete examples of how to build these structures in code. Before we get started, I do recommend you re-read my original post on WSDXML. …

0

WS-DD v1.1 specs are now standards

OASIS has just announced that version 1.1 of DPWS, WS-Discovery, and SOAP-over-UDP are now officially standards! The links to the RDDL and spec pages currently point to the Committee Specification 1 (CS1) revisions of the specs, but OASIS will update these links to the fully standardized versions of the documents soon. This is a big milestone in the progress of…

13

Using MTOM to set up binary streams

The SOAP Message Transmission Optimization Mechanism is a building-block spec that DPWS profiles so that specifications built on top can use it in a consistent and device-friendly way.  MTOM isn’t used in any of DPWS’s messages, but it is available to solution authors and is included in many specs built on DPWS. In short, MTOM…

0

DPWS v1.1 update

It’s been a while since I last provided an update on the standardization of DPWS, WS-Discovery, and SOAP-over-UDP.  I’m pleased to say that the standardization committee has produced Committee Specification versions of these three specs–that doesn’t mean that they’re standards, but the committee has finished with these versions and has sent them to the greater…

0

xAddrs optionality in WS-Discovery messages

Traditional big web services, like a billing system or a service running in the cloud, nearly always have fixed addresses–often HTTP URLs.  Smaller web services, such as those on a PC or a device, often have logical identifiers (“urn:uuid:c3de740f-9227-4706-b3ee-9494243c040d”) that let you recognize the service, but which don’t actually tell you anything about how to contact…

5

Service-level metadata

DPWS defines two different levels of metadata: the Device delivers metadata about the entire device, and about the relationship between the Device and its Hosted Services; and each Hosted Service delivers metadata about itself (and optionally about its relationship with the Device). Of these two, the device-level metadata is the most important.  Since WS-Discovery only…

0

Discovery-layer types in DPWS applications

The roles of Types in WS-Discovery messages is really clear for generic, non-DPWS services.  Types are qualified names expressed in the <d:Types> element of WS-Discovery messages, and these names identify a set of operations; the service advertised in the WS-Discovery message supports those operations.  In many cases a language like WSDL is used to express…

3

WS-DD standardization update

Just under six months ago, DPWS, WS-Discovery and SOAP-over-UDP entered standardization in the OASIS WS-DD technical committee.  An incredible amount of work and progress has been made during that time, and the committee has just published the second draft of the 1.1 versions of each specification. As I mentioned in my earlier posts, this is…

0

Release and Terminate in WSDAPI objects

A lot of WSDAPI objects implement IUnknown, so the expose the Release() method.  A few more also support Terminate().  What’s the difference, and which should you call? Ultimately, you should always refer to the documentation, as rules for specific objects may differ from the norm.  But in most cases, the following guidelines apply: Terminate should always…

0

Web Services stacks on Windows

It has never been particularly easy to choose a Web Services stack on which to build your application.  Microsoft has produced many over the years (for example, WCF and WSDAPI) and other software vendors produce even more.  The feature sets of these stacks often overlaps, but rarely are they all exactly the same–so making a decision…

6