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: Understanding WS-Discovery operational modes - WS-D Primer


Hi Alain,

 

Thanks for taking time to review the document. Following are some of the high level points that address many of your concerns listed below.

 

* The ad-hoc and managed mode are characterized by the MEPs used for the discovery of services. For example, an actor say a Target Service; is in an ad-hoc mode if it sends multicast Hello, Bye, listens for multicast Probe and Resolve. A Target Service is in a managed mode if it sends unicast Hello and Bye. A client is in an ad-hoc mode if it sends multicast Probe, Resolve and listens to multicast Hello and Bye. It is in a managed mode if it sends unicast Probe and Resolve.

 

* The operational modes per actor are not mutually exclusive. For example, a Target Service can be in an ad-hoc mode and a managed mode at the same time. Additionally, various actors on a physical network can be in operating in different modes.

 

Please find additional comments below.

 

Thanks,

Vipul

 

 

 

From: Alain Regnier [mailto:alain@ricoh-tech.com]
Sent: Saturday, October 11, 2008 3:24 AM
To: ws-dd@lists.oasis-open.org
Subject: RE: [ws-dd] Understanding WS-Discovery operational modes - WS-D Primer

 

Hi Vipul,

 

thanks for the document.

 

Following are some questions/feedback on the WS-D Primer.

 

--

 

1.2.1 “. In this mode the protocol messages are sent multicast on the network. “
Not all the protocol messages are sent multicast on the network in ad-hoc discovery mode. ProbeMatch and ResolveMatch are sent unicast. It would be more appropriate to say protocol messages are sent multicast to Target Service.
 

[vipul] Agree, not all messages are sent multicast.
 
Figure 3 – The scenario illustrated in this diagram does not quite fit the scope defined by ws-discovery, or seem practical in real world. DP acts more like proxy defined in ws-discovery remote extension document.

[vipul] The scenario is illustrating one of the high level point I mentioned above, i.e. a Target Service can be in more than one mode at the same time depending upon its configuration. 

 

Figure 4: This figure shows a client receiving unicast Hello: it should probably be mentioned in the bullet points above the figure, since it is not strictly ad-hoc mode messages, or removed and placed in section 3.3 instead.

 

[vipul] This is a multicast suppression Hello that a Client operating in an ad hoc mode receives from a Discovery Proxy.

 
2.2 the agent mentioned in this section should be described with more details
 
 
section 4 Discovery Proxy
"Additionally it can be configured to act as a multicast suppression agent"
According to 1.1 (and in a lot of people's mind) it is the first of three things that a DP does (or the main thing a DP does). That's why this sentence doesn't seem to be a good choice. (it make it sounds like it's an additional benefit, instead of a core benefit)

 

[vipul] Agree, that this can be reworded better. At a high level there are two main functionalities of a Discovery Proxy.

1.       Support discovery in a managed mode

2.       Suppress multicast on an ad hoc network by redirecting the traffic to its managed endpoint.

 

There are scenarios for both functionality. For example, for an enterprise service registry in a data center it does not make sense to participate in a multicast suppression as there may not be any multicast traffic in the data center for the services it represents.

 

There should be a section about security, and particularly things like man in the middle attacks
 
[vipul] The goal of the primer right now is to get us on the same page with respect to operation modes of discovery; as a stepping stone for the managed mode cluster proposal.


Is Managed Mode applied uniformly to all Target Services, Clients and Discovery Proxies on a network? If so it should be mentioned as such. If not, then a DP can be in Managed Mode and a TS/Client may not be, and therefore the DP can receive multicast Hellos/Byes/Probes/Resolves, and that should be indicated in Figure 7.

 

[vipul] As I mentioned earlier on a physical network different actors can be in different mode. One actor can be in more than one mode at the same time.


Section 4.2: What is the wsd:Types of a Discovery Proxy when it advertises itself?

 

[vipul] d:DiscoveryProxy.


Section 4.2, line 145-147: “It then offers the Clients to query this information via managed mode….” Does this mean the DP running in ad-hoc mode can let Clients query it as if in managed mode? Does this mean DP is converting itself to ad-hoc mode, or just that Clients get converted to managed mode and DP stay in ad-hoc mode?

 

[vipul] Conceptually a Discovery Proxy that is suppressing multicast has two endpoints,

1.             A managed endpoint that is operating in a managed mode (managed mode MEP).

2.             An ad hoc endpoint that is operating in an ad hoc mode that does multicast suppression and redirect the clients to the managed endpoint.

 

The proxy is operating in both modes and continue to do so. If Clients sends multicast Probe/Resolve, the proxy receives this through the ad hoc endpoint and try to suppress it by sending unicast Hello that contains information about managed endpoint. The client upon receiving this information switches to the managed mode and sends messages to the managed endpoint of the proxy.


5.1. Typo in step 12: Target Service 2 is projector, not scanner.

 

[vipul] Good catch. Thanks.


line 147: it could be helpful to clarify what exactly is the "managed mode endpoint"
 

[vipul] Ok, in this context it is an endpoint of a Discovery Proxy that supports managed mode message exchange pattern (or d:DiscoveryProxy).
 
Line 150-154: This bullet point should clarify that the Probe the DP is listening for is a Probe for DP wsd:Types, not a Probe for TargetServices
 

[vipul] Agree.

 

Figure 9: the figure is difficult to read... it could help if the numbers were ordered.

 

[vipul] I know it has a lot of information, I tried best to have relevant information and yet fit it in one page.  The point that this is illustrating is that Target Services that operate in an ad-hoc mode are unaffected by the presence of a Discovery Proxy that does multicast suppression and continue to operate normally.

 
- if a service gets aware of the presence of a DP on the network (for example through DHCP) should it switch to managed mode and talk only to this DP (through unicast)?
 

[vipul] This is up to a service implementation. The protocol defines the message exchanges in each mode for all of the roles. For each implemented mode and role the protocol exchanges must follow the specification. A higher level profile for example in this case DPWS can define requirement and conditions to operate in a particular mode.
 
- How can a client be sure that DP always provides up-to-date information of all the TARGET SERVICE, for instance, what if a DP responds to a client’s Probe, but not to a TARGET SERVICE’s Hello?
 

[vipul] If a DP does not have information about a Target Service it should not be doing multicast suppression. This would be an implementation issue.
 
- How can a Target Service verify whether DP is responsive? In managed mode, a TARGET SERVICE sends unicast Hello to a DP once its metadata has been changed. If a DP is not responsive, a TARGET SERVICE has to send multicast Hello.
 
 [vipul] If a Target Service is using HTTP, it can determine the responsiveness by loss of a HTTP/TCP connection. A service can operate in an ad hoc mode and a managed mode at the same time or as you described may switched from managed to ad hoc mode, but this would be determined by the implementation support and configuration of the service.


- How can a Target Service opt not to be presented by a DP?
 

[vipul] A Target Service can opt to not operate in a managed mode and send information to DP. In an ad hoc mode a Target Service multicast its information so it does not have any control over who uses this information.
 
- Is there any difference between a DP and a proxy as defined in ws-discovery remote extension?

 

The document assumes that a Service needs to know in advance what a DP is, preventing a seemless integration.
Some people assume that a DP should be a component that is inserted in an existing network, mainly to suppress multicast. (ie the Service, including those services that are already shipping, don't even need to know they are talking to a DP) Some think it should help cross network communications in secure/internal environment.

We may need a broader discussion about the expected goals of a Discovery Proxy...
A way to deal with it would be to define several "levels" of DP: a first level would be a seemless multicast suppression (useful in trusted environments for example), and a second level would be a more complex DP as defined in this document, and requiring several changes to services.

[vipul] I agree with the requirement you mentioned about seamless integration in an ad hoc mode. The document isn’t making any assumptions otherwise If you introduce a discovery proxy that does multicast suppression to an ad hoc network, the Target Services would not change. The proxy would obtain information about the Target Services on the network by sending multicast Probe and listening for multicast Hello/Bye. It would then suppress the clients on a ad hoc network and redirect them to managed mode.

 
--

 

 

Alain

 

 

 

 

 

 


From: Vipul Modi [mailto:Vipul.Modi@microsoft.com]
Sent: Mon 10/6/2008 5:18 PM
To: ws-dd@lists.oasis-open.org
Subject: [ws-dd] Understanding WS-Discovery operational modes - WS-D Primer

Hello all,

 

During the first face to face, some of us felt that the current WS-Discovery specification does not provide a clear description of requirements and responsibilities of various actors in an ad hoc mode and a managed mode. We made good progress on this during the technical discussions and white boarded our understanding of the specification in this regard. We filed and accepted a number of issues called “managed cluster” in this regard.

 

Please find the attached document titled “WS-Discovery Primer” that captures the essence of our discussions and understanding, and explains the behavior of a Target Service, a Client and a Discovery Proxy in a managed mode and an ad hoc mode as defined by the current specification. This document should allows us to be on the same page with respect to understanding ad hoc and managed modes and message exchanges in these modes, and help us make progress on the “managed cluster” issues.

 

Thanks,

Vipul Modi

Senior Development Lead, Microsoft Corporation.

vipul.modi@microsoft.com | 425-707-2402

 



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