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

[Antoine Mensch <antoine.mensch@odonata.fr>]

Hi Doug,

please see further comments below.

Cheers

Antoine

Doug Davis a écrit :
>
> 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?
No. In the Hello/ProbeMatches/ResolveMatches messages, there are two 
address-related elements:
- A mandatory wsa:EndpointReference element, which contains the stable 
identifier. This can feature reference parameters. In DPWS, the use of 
UUIDs is recommended for the address element of this EPR.
- An optional wsd:XAddrs element, which contains a list of transport 
addresses URIs (and not UUIDs). In my previous answer, I was trying to 
say that it could be useful to have EPRs instead, because they could 
carry more info such as policy and binding, but that in the case of 
DPWS, we don't need this additional info because the spec restricts the 
binding to be used to SOAP1.2 over HTTP. So we are happy with the 
transport address as it is (in fact, I did not answer your question, 
which may be the reason why my answer was confusing).
You were asking whether having EPRs in wsd: WAddrs could be useful to 
distinguish between the transport address of the target service (device) 
and that of its hosted services by using reference parameters: it could 
be useful, but it is probably not required, as hosted services can 
define their own endpoints, possibly with reference parameters, so there 
is no ambiguity. One important aspect to keep in mind is that discovery 
messages are carried over UDP, so we should try to keep them short, to 
avoid packet fragmentation.
> 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
>
>
> ------------------------------------------------------------------------
>
>
> 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
>
>