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


some additional comments on Doug's questions.



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

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