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
Hi,
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.
thanks
-Doug
______________________________________________________
STSM | Web Services Architect | IBM Software Group
(919) 254-6905 | IBM T/L 444-6905 | dug@us.ibm.com