WS-DISCOVERY
출처 : http://docs.oasis-open.org/ws-dd/discovery/1.1/os/wsdd-discovery-1.1-spec-os.html
WS-Addressing 1.0 홈페이지 : http://www.w3.org/2005/08/addressing
What is WS-DISCOVERY
This specification defines a discovery protocol to locate services. The primary scenario for discovery is a client searching for one or more target services. The protocol defines two modes of operation, an ad hoc mode and a managed mode. In an ad hoc mode, to find a target service by the type of the target service, a scope in which the target service resides, or both, a client sends a probe message to a multicast group; target services that match the probe send a response directly to the client. To locate a target service by name, a client sends a resolution request message to the same multicast group, and again, the target service that matches sends a response directly to the client.1. Operational Modes
1) Ad hoc Mode
In an ad hoc mode discovery messages are sent
multicast and response messages are sent unicast. Figure 1 depicts the
message exchanges between a Target Service and a Client operating in an
ad hoc mode.
Figure 1 : Message Exchanges in an ad hoc mode.
A Target Service sends a multicast Hello message (1) when it joins a network (see Section 4.1.1 Target Service).
A Client listens for multicast Hello messages (see
Section 4.1.2 Client). A Client sends a multicast Probe message (2) to
locate Target Services (see Section 5.2.1 Client).
If a Target Service matches the Probe it responds
with a unicast Probe Match (PM) message (3) (see Section 5.3.1 Target
Service).
Other matching Target Services MAY also send
unicast Probe Match. A Target Service MAY also accept and respond to
unicast Probe messages sent to its transport address(es) (see Section
5.2.2 Target Service).
A Client sends a multicast Resolve message (4) to locate a particular Target Service (see Section 6.2.1 Client).
If a Target Service matches the Resolve it responds
with a unicast Resolve Match (RM) message (5) (see Section 6.3.1 Target
Service).
A Target Service makes an effort to send a
multicast Bye message (6) when it leaves a network (see Section 4.2.1
Target Service).
A Client listens for multicast Bye messages (see 4.2.2 Client).
Figure 2 depicts the message exchanges in an ad hoc mode when a Discovery Proxy is present on the network.
Figure 2: Message exchanges in an ad hoc mode in the presence of a Discovery Proxy.
A Target Service sends multicast Hello and Bye (4) and responds to matching multicast Probe and Resolve (5,7).
A Client listens for multicast Hello and Bye (4) and sends multicast Probe and Resolve (5).
A Discovery Proxy is also a Target Service of a well known d:DiscoveryProxy
type and sends a multicast Hello message annoucing its arrival on the
network and a multicast Bye message annoucing its departure from the
network (1).
It responds to the matching Probe and Resolve for itself (2), with a Probe Match (PM) and a Resolve Match (RM) respectively (3).
If a Discovery Proxy is configured to reduce
multicast traffic on the network, it listens for multicast Hello and Bye
from other Target Services (4) and store/update information for
corresponding Target Services (see Section 4.1.3 Discovery Proxy and
4.2.3 Discovery Proxy).
It responds to the multicast Probe and Resolve for
other Target Services (5), with a Hello message (6) (see Section 4.1.3
Discovery Proxy), indicating the Client to switch to managed mode and to
send unicast Probe and Resolve (see Section 2.2.2 Managed Mode).
2) Managed Mode
In a managed mode discovery messages are sent
unicast to a Discovery Proxy. Figure 3 depicts the message exchanges
between a Client, a Target Service and a Discovery Proxy in a managed
mode.
A Target Service sends a unicast Hello message (1)
to a Discovery Proxy when it joins a network (see Section 4.1.1 Target
Service).
A Client sends a unicast Probe request (2) to a Discovery Proxy to locate services (see Section 5.2.1 Client).
A Discovery Proxy responds to a unicast Probe
request with a Probe Match response (3) containing matching Target
Services, if any (see Section 5.3.2 Discovery Proxy).
A Client sends a unicast Resolve request (4) to a
Discovery Proxy to locate a particular Target Service (see Section 6.2.1
Client).
A Discovery Proxy respond to a unicast Resolve
request with a Resolve Match response (4) containing the matching Target
Service, if any (see Section 6.3.2 Discovery Proxy).
A Target Service makes an effort to send a unicast
Bye message (6) to a Discovery Proxy when it leaves a network (see
Section 4.2.1 Target Service).
Figure 3: Message exchanges in a managed mode.
To operate in a managed mode a Target Service and a
Client need an Endpoint Reference of the Discovery Proxy. A Target
Service or a Client can acquire this information from a number of ways
including, but not limited to explicit configuration, explicit Probe for
Discovery Proxy, DNS or DHCP, specifics of which are outside the scope
of this specification. One such method that reduces the traffic in an ad
hoc network and allows Client to dynamically switch to managed mode is
described below.
4) Dynamic Mode Switching
To limit multicast traffic, Clients MAY be
configured to dynamically switch from an ad hoc mode to a managed mode
and vice versa, depicted in Figure 4.
Figure 4: State transitions of a Client configured to dynamically switch operational modes.
By
default, a Client assumes that no Discovery Proxy (DP) is available
because a Discovery Proxy is an optional component and may not be
present on the network. The Client operates in an ad hoc mode and
listens for multicast Hello and Bye announcements, sends multicast
Probe and/or Resolve messages, and listens for Probe Match and/or
Resolve Match messages (see Section 2.2.1Ad hoc Mode).
However, if one or
more DP that provide multicast suppression are available, those DP send a
unicast Hello that contains information about an endpoint that
implements a well-known "discovery proxy" type d:DiscoveryProxyin managed mode in response to any multicast Probe or Resolve. As depicted in Figure 4,
Clients listen for this signal that one or more DP are available, and
for subsequent searches switch to a managed mode and instead of
multicast, send Probe and Resolve messages unicast to one or more DP
they trust whilst ignoring multicast Hello and Bye from Target Services.
In a managed mode, a Client communicates with a DP
as described in Section 2.2.2 Managed Mode; using the transport
information contained in the DP Hello; this is typically indicated by
the scheme of a transport URI, e.g., "http:" (HTTP), "soap.udp:" (UDP [SOAP/UDP]), or other.
If the DP is unresponsive after DP_MAX_TIMEOUT, or if the Client finds the responses from the DP unsatisfactory, the Client reverts to using the multicast messages specified herein.
4) Example
able 2 lists an example Probe message sent multicast by a Client searching for a printer in an ad hoc mode.
Table 2: Example Probe sent multicast in an ad hoc mode.
(01) <s:Envelope
(02) xmlns:a="http://www.w3.org/2005/08/addressing"
(03) xmlns:d="http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01"
(04) xmlns:i="http://printer.example.org/2003/imaging"
(05) xmlns:s="http://www.w3.org/2003/05/soap-envelope" >
(06) <s:Header>
(07) <a:Action>
(08) http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/Probe
(09) </a:Action>
(10) <a:MessageID>
(11) urn:uuid:0a6dc791-2be6-4991-9af1-454778a1917a
(12) </a:MessageID>
(13) <a:To>urn:docs-oasis-open-org:ws-dd:ns:discovery:2009:01</a:To>
(14) </s:Header>
(15) <s:Body>
(16) <d:Probe>
(17) <d:Types>i:PrintBasic</d:Types>
(18) <d:Scopes
(19) MatchBy="http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/ldap" >
(20) ldap:///ou=engineering,o=examplecom,c=us
(21) </d:Scopes>
(22) </d:Probe>
(23) </s:Body>
(24) </s:Envelope>
(25)
Lines (07-09) in Table 2 indicate the message is a Probe, and Line (13) indicates it is being sent to a well-known address [RFC 2141].
Because there is no explicit ReplyTo SOAP header block [WS-Addressing],
any response to this Probe message will be sent as a UDP packet to the
source IP address and port of the Probe transport header [SOAP/UDP].
Lines (17-21) specify two constraints on the Probe:
Line (17) constrains responses to Target Services that implement a
basic print Type; Lines (18-21) constrain responses to Target Services
in the Scope for an engineering department. Only Target Services that
satisfy both of these constraints will respond. Though both constraints
are included in this example of a Probe, they are OPTIONAL.
Table 3 lists an example Probe Match message sent in response to the Probe in Table 2.
Table 3: Example ProbeMatch sent in response to the ad hoc Probe in Table 2.
(01) <s:Envelope
(02) xmlns:a="http://www.w3.org/2005/08/addressing"
(03) xmlns:d="http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01"
(04) xmlns:i="http://printer.example.org/2003/imaging"
(05) xmlns:s="http://www.w3.org/2003/05/soap-envelope" >
(06) <s:Header>
(07) <a:Action>
(08) http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/ProbeMatches
(09) </a:Action>
(10) <a:MessageID>
(11) urn:uuid:e32e6863-ea5e-4ee4-997e-69539d1ff2cc
(12) </a:MessageID>
(13) <a:RelatesTo>
(14) urn:uuid:0a6dc791-2be6-4991-9af1-454778a1917a
(15) </a:RelatesTo>
(16) <a:To>
(17) http://www.w3.org/2005/08/addressing/anonymous
(18) </a:To>
(19) <d:AppSequence InstanceId="1077004800" MessageNumber="2" />
(20) </s:Header>
(21) <s:Body>
(22) <d:ProbeMatches>
(23) <d:ProbeMatch>
(24) <a:EndpointReference>
(25) <a:Address>
(26) urn:uuid:98190dc2-0890-4ef8-ac9a-5940995e6119
(27) </a:Address>
(28) </a:EndpointReference>
(29) <d:Types>i:PrintBasic i:PrintAdvanced</d:Types>
(30) <d:Scopes>
(31) ldap:///ou=engineering,o=examplecom,c=us
(32) ldap:///ou=floor1,ou=b42,ou=anytown,o=examplecom,c=us
(33) http://itdept/imaging/deployment/2004-12-04
(34) </d:Scopes>
(35) <d:XAddrs>http://prn-example/PRN42/b42-1668-a</d:XAddrs>
(36) <d:MetadataVersion>75965</d:MetadataVersion>
(37) </d:ProbeMatch>
(38) </d:ProbeMatches>
(39) </s:Body>
(40) </s:Envelope>
(41)
Lines (07-09) in Table 3 indicate this message is a
Probe Match, and Lines (13-15) indicate that it is a response to the
Probe in Table 2. Because the Probe did not have an explicit ReplyTo
SOAP header block, Lines (16-18) indicate that the response was sent to
the source IP address and port of the transport header of the Probe.
Line (19) contains an instance identifier as well as a message number;
this information allows the receiver to reorder discovery messages
received from a Target Service.
Lines (23-37) describe a single Target Service.
Lines (24-28) contain the stable, unique identifier
for the Target Service that is constant across network interfaces,
transport addresses, and IPv4/v6. In this case, the value is a UUID
based URN [RFC 4122] scheme URI, but it can be a transport URI (like the one in Line 35) if it meets stability and uniqueness requirements.
Line (29) lists the Types (see, e.g., [WSDL 1.1])
implemented by the Target Service, in this example, a basic print type
that matched the Probe as well as an advanced print type.
Lines (30-34) list three administrative Scopes, one
that matched the Probe (Line 31), one that is specific to a particular
physical location (Line 32), and one that includes data useful when
switching over to new infrastructure (Line 33). As in this case, the
Scopes can be a heterogeneous collection of deployment-related
information.
Line (35) indicates the transport addresses where
the Target Service can be reached; in this case, a single HTTP transport
address.
Line (36) contains the version of the metadata for
the Target Service; as explained below, this version is incremented if
there is a change in the metadata for the Target Service (including
Lines 29-34).
5)Protocol Assignments
5.1) Ad hoc mode over IP multicast
If IP multicast is used to send multicast messages described herein, they MUST be sent using the following assignments:-
DISCOVERY_PORT: port 3702 [IANA]
-
IPv4 multicast address: 239.255.255.250
-
IPv6 multicast address: FF02::C (link-local scope)
Other address bindings MAY be defined but are beyond the scope of this specification.
Messages sent over UDP MUST be sent using SOAP over UDP [SOAP/UDP]. To compensate for possible UDP unreliability, senders MUST use the example transmission algorithm in Appendix I of SOAP over UDP. In order to improve interoperability and network efficiency use of SOAP 1.2 protocol [SOAP 1.2] is RECOMMENDED.
댓글 없음:
댓글 쓰기