Expirations in WS-Eventing

  • [アーティクル]

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.

Comments

  • Anonymous
    February 17, 2010
    Hi Dan, We are developing a WSD device/print service. After installing the printer driver the printer status is seen Ready, but if we reboot the Windows 7/Windows Vista PC, the printer shows offline. We don't get to see any Event Subscription after the PC reboots. Could you please let us know why this could be happening? Thanks and regards, Mridu

  • Anonymous
    February 18, 2010
    Hi Mridu- If the device does not show up when the PC is booted, it is likely that the device is not generating properly formed ResolveMatches messages. --Dan

  • Anonymous
    February 18, 2010
    Thanks Dan. But I forgot to mention in the previous mail that:

  1. Device is getting discovered by Network Explorer and displayed normally. but
  2. Printer Status is shown as Offline on the Printer Driver window. That is the reason we thought issue is not with ResolveMatch but something to do with Event notification notifying the printer status. Any idea what could be the issue? Thanks and regards, Mridu

  • Anonymous
    February 19, 2010
    Hi Mridu- Again, I would recommend checking your ResolveMatches messages. If you can successfully install your device after bringing it online, Hello and Metadata are working properly.  The Network Explorer window sends out Probe messages (not Resolve).  The only message pattern which is unique to the situation you describe is Resolve/ResolveMatches. It is also possible that your Metadata is different when retrieved based on ResolveMatches vs. Hello, or that there is a lower-layer networking issue, but ResolveMatches is the right place to start. --Dan

  • Anonymous
    February 22, 2010
    Hi Dan, Thanks a lot for the reply. We are seeing that the printer is shown offline even when we STOP/START the spooler (need not restart the PC). Problem as you said could be with the ResolveMatch. But we are passing DTM (WLK 1.5 WSDMon Printer Verification Test). As far as I understand, in a working scenario, the sequence of request from the PC should be Resolve, Get request, GetPrinterElement, subscription request. But in our case, we see that the PC stops after sending out Get request. Could you please let us know which part of ResolveMatch we need to look at for resolving this printer going offline issue? Thanks and regards, Mridu

  • Anonymous
    February 22, 2010
    My general-purpose guidance is to look at the last message in the chain (the metadata response) and compare it against working samples, either from your own device, or from WSDAPI itself.  Because the problem is isolated to patterns beginning with Resolve/ResolveMatches, see if there's anything in the metadata that changes based on these messages (specifically transport addresses, which sometimes differ between metadata preceded by Hello and metadata preceded by Resolve/ResolveMatches). For more specific issues, Microsoft developer support can help you troubleshoot. --Dan

  • Anonymous
    February 23, 2010
    Hello Dan, We removed XAddrs from ProbeMatch, to force a Resolve request at time of discovery. And discovery happened fine with ResolveMatch. When we stop and start the spooler, in case of a working printer device, we don't see any Resolve request from the PC (in fact no UDP msgs). PC starts sending Get request and follows by GetPrinterElements. But in our case, we get to see Resolve and Get and no further communication after we reply with GetResponse from device. Could you please guide us what else we can look for? Thanks and regards, Mridu

  • Anonymous
    February 23, 2010
    Hi Mridu- Sorry, blog comment fields are not suitable for debugging a detailed problem like this. --Dan

  • Anonymous
    February 08, 2012
    Hi sir, How about RenewResponse? Will this work to keep the pc from not un-subscribing? --Efren D.