Expirations in WS-Eventing

  • Article

WS-Eventing is one of the building-block specifications that DPWS profiles and makes available for solution authors.  Some applications require the device to send notification messages back to the client; e.g., a printer sends a message to the PC when it has finished printing a document.  WS-Eventing doesn't describe the content in these notifications, but it does describe the messages that the client and device use to set up and manage the subscription for those events.  The way this works is that the client subscribes to events; the device sends zero or more events; and some cleanup happens to tear the subscription down.

It's actually a lot more complicated at the protocol level, but the important point to remember is that a subscription ties a service (in this case, a service running on a device) to a client, and that subscription may have an expiration--either an absolute time, or a relative duration from the start of the subscription.  These expirations are communicated through WS-Eventing, and are in either the duration or the datetime formats described by XML schema.  An example SOAP Body for a Subscribe request with an 18-hour expiration could look something like this:
    <wse:Subscribe>
        <wse:Delivery>...</wse:Delivery>
        <wse:Expires>PT18H</wse:Expires>
    </wse:Subscribe>

The interesting part is that although the client can suggest an expiration, the service is ultimately free to ignore it and choose a different value.  In fact, the service can ignore an absolute expiration and return a relative expiration.  The client should always rely on whatever the service sent back--if the service sent back a different value, the client should use that.

This is really important for devices.  A device should make some attempt to honor a client's request, but it may not support long-lived expirations or absolute datetimes.  Many embedded devices do not have an absolute clock source, and even if they did, they may not know what time zone they're in.  In these cases, the device can rely on relative expirations as an easy way to manage subscription requests from any client, regardless of the suggested expiration.