OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ws-dd message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [ws-dd] Couple of questions on Understanding Devices Profilefor Web Services, WS-Discovery, and SOAP-over-UDP

Hi Doug,


Thanks for the comments.


Please find below my comments.


From: Doug Davis [mailto:dug@us.ibm.com]
Sent: Wednesday, October 08, 2008 3:14 PM
To: ws-dd@lists.oasis-open.org
Subject: [ws-dd] Couple of questions on Understanding Devices Profile for Web Services, WS-Discovery, and SOAP-over-UDP


  I was reading Understanding Devices Profile for Web Services, WS-Discovery, and SOAP-over-UDP and I had a couple of questions:

1: Section 2 say:
        The user decides to shut down the laptop. The laptop unsubscribes itself from receiving event notifications from the printer. This is done using WS-Eventing.
Odds are just as likely that the laptop will leave the network w/o getting a chance to unsubscribe.  So, the subscription will probably timeout - if an expires was specified.  Is there some guidance on what value the subscriber should use for Expires on the subscribe or when an event sink should destroy a Subscription in the case of infinite expires times?  When the first notification fails?  What if there's a network burp and its lost - the laptop could still be there but the event source terminated the subscription due to this burp?  These might be questions best answered as requirements in DPWS, but wasn't sure.

[Ram Jeyaraman] Good question. Unless the event delivery is reliable, the event source will need to remove such subscriptions based on its internal subscription management policy.

2:  In WS-Discovery - xaddrs is an address/URI and not an EPR, why?  I'm wondering about the case where a single endpoint is hosting multiple services behind it. In this case they might all have the same address/URI but different reference parameters to distinguish them.

[Ram Jeyaraman] The EPR for a Target service uniquely identifies the Target Service. The [address] field of the EPR contains the unique identity of the Target Service that is unique across network interfaces, transport addresses, IPv4/IPv6 networks supported by the Target Service. This EPR may contain reference parameters; this allows the Target Service to route/forward received messages to other services it front-ends. But the transport address itself is one temporal accessibility point of the Target Service that may change over time; and there could be many such transport addresses for a Target Service during its lifetime.

3:  In the printer example the notification of the printer status is sent to everyone, not just the sender of that one job (no filter on the subscribe).  Is this intended or in a more real example will the subscribe contain the proper filter to make sure we don't overload the network?

[Ram Jeyaraman] Yes, in the real world the subscribe would typically have a filter specified. This could be added to the example in the white paper.

4: Section 4.2.1 says:
3. A Target Service (or Discovery Proxy) should use the same WS-Addressing [address] and [reference parameters] properties for all messages over all network interfaces. This allows a Client to recognize a Target Service (or Discovery Proxy) when they share multiple networks.

Does this mean that it needs to have the same IP address for all networks that its on? That doesn't seem possible to guarantee.  I would think that some other unique ID (perhaps as part of the metadata) would be used to check identity/equality of devices.  The other concern here is that no spec actually defines how to compare EPRs - and its a very messy subject  :-)

[Ram Jeyaraman] The WS-Addressing [address] in the EPR of the Target Service uniquely identifies the Target Service independent of the transport / IP addresses it supports. A Target Service may be accessible via two different network interfaces; in that case, the Target Service is accessible via two different transport addresses even though the WS-Addressing [address] in the EPR of the Target Service is invariant across the two network interfaces.

Aside from those I found it a very easy read.  Nice job.

STSM  |  Web Services Architect  |  IBM Software Group
(919) 254-6905  |  IBM T/L 444-6905  |  dug@us.ibm.com

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]