Re: [ws-dd] Couple of questions on Understanding Devices Profile for WebServices, WS-Discovery, and SOAP-over-UDP

[Doug Davis <dug@us.ibm.com>]

Hi Antoine and Ram
  thanks for the responses.
1 - I struggled with whether DPWS could
(or should) say anything about this too - part of me does agree that its
an implementation choice.  But figured I'd pose the question anyway
in case some guidance emerged as part the discussion.
2- Antonie said:
        In
the case of DPWS however, the transport addresses are enough, as the profile
requires the use of the SOAP1.2 over HTTP binding.
  could you elaborate on this one?
 Ram seemed to indicate in his answer that the xaddrs would be one
of those unique IDs (e.g. UUID) and not a network address.  Is this
what you mean too?
3 - Yep - filtering on Action probably
isn't granular enough.
4 - I keep forgetting that there are
two types of EPRs - ones with real network addresses (192.168.0.1) and
ones with UUID type of addresses.  What's the proper term for the
network-address ones?

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

Antoine Mensch <antoine.mensch@odonata.fr>

10/09/2008 03:33 AM

Please respond to
antoine.mensch@odonata.fr

To	ws-dd@lists.oasis-open.org
cc
Subject	Re: [ws-dd] Couple of questions on Understanding Devices Profile for Web Services, WS-Discovery, and SOAP-over-UDP

Hi,

some additional comments on Doug's questions.

Cheers

Antoine

Doug Davis a écrit :
>
> 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.
Per WS-Eventing, when a client subscribes for a given duration (or even
for an infinite duration), it is up to the event source to actually 
accept the requested duration or grant a different one (which can be 
shorter). So the client must be prepared to handle short-term 
subscriptions and renew them as needed. I am not sure that prescribing
a 
given behavior for event sources in case of notification failures should
be part of the DPWS spec or just an implementation choice (in our 
implementation, we notify the event source application that a 
notification failure occurred and leave the resolution to the application).
>
>
> 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.
The transport addresses are used to provide clients with addresses to 
which the WS-Transfer Get request is sent: hosted service endpoints are
provided as EPR (which may reuse the transport address and add reference
parameters) in the GetResponse message. I agree however that using EPR
in XAddrs would increase the generality of the spec, as additional 
information such as binding or policy to access the target service 
metadata could be added to them. In the case of DPWS however, the 
transport addresses are enough, as the profile requires the use of the
SOAP1.2 over HTTP binding.
>
>
> 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?
This relates to issues 52 and 56. DPWS restricts the use of filtering as
defined in WS-Eventing, as only filtering on actions (i.e. message type)
is allowed. The more complex XPath-based filtering is not supported. So
even a more complex example would not avoid the problem in the current
state of the spec.
>
> 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  :-)
The TS address is a logical address (typically a UUID, although it is 
not a rquirement) that remains stable across all networks. The XAddrs 
are used to associate in a transient way the stable address with network
addresses, that can differ on different network interfaces. However, the
way this association is managed is not crystal-clear in the spec yet. 
Please see issues 8 and 10 on the subject.
>
>
> 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
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - http://www.avg.com 
> Version: 8.0.173 / Virus Database: 270.7.6/1711 - Release Date: 06/10/2008
17:37
>
>   

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php