A Review of the Web Service Dynamic Discovery (WS-Discovery) Specification

Roushdat Elaheebocus Quand Hung Ngo Ahmed Alarifi

School Of Electronics and Computer Science School Of Electronics and Computer Science School Of Electronics and Computer Science
University of Southampton, UK University of Southampton, UK University of Southampton, UK
re1e08@soton.ac.uk qhn108@soton.ac.uk asa1e08@soton.ac.uk

Abstract. In this paper, we have reviewed the Web Service Dynamic Discovery (WS-Discovery)
specification by describing the problem and how WS-Discovery attempts to solve it. We also analysed its
technical aspects, its strong points and limitations.
Keywords: WS-Discovery, Web Services, Dynamic Discovery, Web Service Specification
 1 Introduction
Web services are network-based software which are normally accessed through published APIs to allow "inter-operable
machine-to-machine interaction" [1].Capability enhancements for Web services come in the form of Web specifications (WS-*)
and the ones that reach a good maturity level are standardised.
Among the dozens of specifications, there is one which looks promising and useful for the future of Web services based on ad-
hoc or pervasive networks; Web Service Dynamic Discovery (WS-Discovery) is a specification put forward by 5 major companies
including Microsoft and Intel in the year 2005. Its purpose is to help clients locate web services and allow establishment of
communication between client and service.
WS-Discovery is described as a multicast discovery protocol that 'discover' services available and the means to access them
through the sending of probe messages by clients and receipt of probe-match messages from services. Other mechanisms used by
the Web services to advertise their status are the use of 'Hellos' and 'Byes' messages to notify all those subscribed to them.
However it should be made clear from the very beginning that WS-Discovery has not yet been fully accepted by any standards
body and is still in some kind of beta version almost three years after it has been published.

2 The problem
With the number of Web services growing, it becomes difficult for clients to remember details of each service, including its
name, type, address and available methods to use on it. This gets even more complicated when the service changes address often
like for example in ad-hoc networks for example where a service can be available at one time and disappears in the next hour or
changes its name.

3 The solution
Researchers have come up with a directory service comparable to our phone directory called the Universal Description,
Discovery and Integration (UDDI). Sponsored by OASIS, UDDI serves as a registry for Web services that can publish
themselves on it while enabling clients to access it to find out about services available. While this registry service is appropriate
for static networks, it is very inefficient in ad-hoc networks where high service volatility is a normal occurrence. Not all services
will get published in the registry and those that do, will falsely be displayed as available long after their withdrawal from the
network since UDDI in not able to dynamically update Web services states. As a solution for the problems highlighted above,
WS-Discovery has been proposed to tackle the lacking of UDDI and adopts a decentralised strategy whereby each client is able
to discover services on its own without consulting any registry. Also clients in a multicast group are notified about the states of a
Web service when the latter joins the network through a Hello message and a Bye message to signal its departure.
4 A brief comparison between WS-Discovery and UDDI

Management
OGSA Management

Process / Coordination
Composition Coordination QOS

Security / Identity
Protocols Assertions

UDDI WS-Addr WS-MEX WS-D

Metadata
Description Sharing / Discovering
s

Messaging
Messaging / Addressing Message QOS

HTTP HTTPS SMTP Transport

Figure 1: Simplified adapted version of Web Service Architecture from Moreau & Luck

The diagram above shows a stripped-down version of a WS architecture proposed by Moreau & Luck. We have included the most
probable location of the new specification (WS-Discovery) which is in the Metadata layer together with UDDI. Although WS-
Discovery performs discovery of Web services, the other sharing/discovering components were already present in the model. Thus
we need to emphasize that WS-Discovery is only an additional extension to compensate for short-comings in UDDI for example.

WS-Discovery UDDI
To discover services, the client needs to send probe messages UDDI consisting of a registry which resembles a phone
over the network. Services that match what the client is looking directory, contains entries for services that have been published
for answer back through a probe-match message. Also, clients to it. Therefore, a client need only to query the registry to find a
can send a resolve message if it is searching for a service by service.
name. In this case, the matching service will reply accordingly
with a resolve-match message.
Services can update their service status, that is whether they are This is one of the major drawbacks of UDDI; UDDI has to cope
available or not by sending a 'Hello' message when joining and with out-dated service status on its own which is no easy task if
a 'Bye' message when parting. Thus clients can invalidate cache there are hundreds of services published on it and the registry
entries that they hold for that particular service. has to do the housekeeping tasks.
Using WS-Discovery, services can be discovered without them In order for a service to be accessible, it should publish itself to
needing to publish their details to any registry since each the registry so that clients can look-up its details. Thus if it does
individual client can send probe messages to discover services not know the address of the registry, it also means it can't let
over the network. This makes WS-Discovery suitable for others know how to access and use it.
mobile environments where services are volatile such as
ubiquitous computing environments [8].
WS-Discovery can be readily used over distributed systems due UDDI makes use of a centralised registry. Thus for some reason
to its inherent characteristic of being decentralised and can thus if the registry goes down, no clients will be able to access
be considered as robust since if a service or a client goes down, services since they will not be aware of services' details.
the remaining components continue to operate without much
disturbance.
Although the specification has seen the participation of big UDDI has been published as a third version already and is
companies like Microsoft, it has not yet been ratified by any considered quite mature. OASIS governs UDDI.
standards body.
[2][3][4]

4.1 Is WS-Discovery a replacement for UDDI?

Definitely not. While using WS-Discovery proves advantageous in a mobile network, it is not suitable for static ones. In fact,
WS-Discovery is a complement for UDDI and the latter will continue to play an important role for static networks.
An example where WS-Discovery will be preferable compared to UDDI will be a dating application over mobile phones.
Scenario: People gathered at a crowded place such as a train station or a supermarket can use their dating application installed on
their mobile phones to search for people having common interests or treats as them. The application need not have any pre-defined
address for a centralised registry service (as it would have been the case for UDDI). Instead, each mobile device can send probes
over the ad-hoc network of mobile phones to detect matches and establish communication. One of the most apparent usage of WS-
Discovery in a commercial application till now (November 2008) is the “People near me” application in Windows Vista by
Microsoft.
On the contrary, a printing service available in a computer lab will always be there, thus, UDDI is more appropriate. This is
because the address of the service (in this case a print-service) will be the same for quite a long time and all computers on the
network will be pre-configured to access a particular registry address for service look-up. On the contrary if we were to use WS-
Discovery, each time a client needs to access the print service, it will send probes over the network which can flood the network
with traffic that could have been easily avoided through the use of a centralised registry.
As we have seen with the above two examples, both specifications, UDDI and WS-Discovery still have their role to play and
are suitable for different scenarios. And thus WS-Discovery primarily make up for its counter-part in areas where the latter has
deficiencies.
5 Technical Details

Exchange

ServiceHost Client

Service

P robe

Probe
Probe

Find

Result
Probe
Publisher Probe-Match
Hello Discovery Proxy Pro ServiceHost
be
Bye Pro
be-
Ma
tch
He Finder
llo
Hel Bye
lo
Bye
Listener

Figure 2: WS-Discovery process architecture

5.1 Architecture of a WS-Discovery process

The figure gives an overview of a WS-Discovery process. Initially the client who needs to find a service, communicate internally
with a process responsible for sending a probe message; labeled as 'Finder'. The probe message is either sent to a multicast
group, or if a discovery proxy is available (this case), it is sent to it. The discovery proxy then proceeds by sending probe
messages over the network and forward probe-matches to the client. The latter can then communicate directly with the service.
Services joining and leaving the network also send Hello and Bye messages to dynamically inform clients about their states.
The primary mode of discovery is through the searching service[4], in which the scope or the type of service will be defined. A
client looks for the services on the network by sending a multicast request. If there is a match, a unicast solution will be replied to
the client. To avoid multicast probing, a discovery proxy is needed to reference discovery queries [5].

5.1.1 Prerequisites of a WS-Discovery Processing

In order to implement a WS-Discovery specification, some of the requirements to be considered are as follows:
Protocol
WS-Discovery uses the IPv4 239.255.250.250 or IPv6 FF02::C (link local scope) using port 3372 (UDP/TCP). If it the UDP
protocol is being used, messages must be delivered using SOAP/UDP. Outside this protocol, other addresses can be bound.

XML namespaces
A number of NameSpaces can be used for WS-Discovery. Nevertheless, the URI
NameSpaces:http://schemas.xmlsoap.org/ws/2005/04/discovery that defines the directory of WS-Discovery including its schema
and WSDL must be used for development of this specification. Other URI namespaces[4] are optional.

Messages
WS-Discovery is based on a powerful set of messages with types: Hello, Bye, Probe(Probe Match) and Resolve(Resolve Match).
These messages must be packed using SOAP 1.1 or SOAP 1.2 envelopes. A WS-Discovery processing must have at least one type
of these messages.
Hello Message
A one way multicast Hello Message is used in two cases. One is when a target service joins the network, another is when
metadata or scope is changed [6]. The Hello message may be unicast in case there is discovery proxy in the network. The discovery
proxy will then forward the message as multicast. In case no discovery proxy is available, the service can send the Hello as a
multicast over the network.

Figure 3: A Hello Message Structure

Figure 3 shows a screenshot of a formal Hello Message structure in which there are two main parts; <header> and <body>.The
<Header> contains information about the type and mechanisms to be used. In particular, the sub-tag <RelatesTo
RelationshipType="d:suppression"> must be used by a Discovery Proxy for responding to multicast Probes from clients. The body
defines the destination of the message through the sub tag <a:EndpointReference>.This part may also define other mechanisms
such as type and scope of the message.

Bye Message
A Bye message is sent by a service when it prepares to leave the network. By listening the Bye messages, the client can invalidate
corresponding data in the cache for that particular service. Similarly to the Hello message, the Bye message can be unicast if a
discovery proxy exists in the network. The structure of Bye Message is the same as the Hello Message structure,except for the
message type.

Probe (Probe Match) Message

A probe message is one way multicast message sent by client in case of no availability of a discovery proxy otherwise the message
is sent as a one way unicast from client to proxy and is then multicasted by the later to target services within the scope specified by
the client.
 Figure 4: A probe message structure
The figure above shows the structure of a typical Probe Message. Note that in the header, an enpoint-reference is used inside the
<a:ReplyTo> tag so that services matching the probe know how to contact the sending-client. The scope and type of service that
the client is looking for is specified in the sub tags <d:Scopes> and <d:Types> inside the <d:Probe> tag container.

Figure 5: A probe-match message structure

For a probe-match message, the service that finds itself matching a probe will include its own parameters such as type, score and
most importantly its address. The address is in the <d:XAddrs> tag that the client receiving the probe-match message can then use
to establish communication. <d:ProbeMatch>. In case the service is responding directly to a client, it will contain only one
<d:ProbleMatch> child but if it replying to a discovery proxy instead, the latter when forwading probe-matches will concatenate
probe-match messages from several services and thus the probe-match message from the proxy can have more than one
<d:ProbeMatch> child.
Resolve(Resolve-Match) Message
A resolve message is a one way multicast message sent by a client in case of being aware of a reference point to a target service but
not having "enough metadata to bootstrap communication with the target service"[6]. The resolve (and resolve-match) structure is
almost similar that of a Probe (and probe-match) message.

5.2 WS-Discovery processing models

5.2.1 Discovery model without Discovery Proxy

Figure 6: A discovery model without discovery proxy

The above model shows a typical set of message exchanges between a client and a target service.
In the first case, when a target service joins the network, it sends a Hello message to the multicast group in the network. This will
help the client to dynamically detect the newly available service thus reducing probing by the client. As a result multicast traffic
over the network will be reduced.
The example below [8] shows the content of a Hello Message sent by a service when joining network.

Figure 7
Line (11-13) identifies this message as being a Hello message, line (17-20) contains application sequencing information such as
instance id, sequence id and message number as well. Line (25-27) refers to an endpoint reference in the network. Line (29)
indicates the type of target service.
In the second scenario, a client finds a service on the network by type or by scope by sending a multicast probe message. For
example,a client looking for a print service will send a message as shown below [4].

Figure 8
Line (7-9) show the message type which is a probe. Line (13) indicates that the message will be directed to a well-known address.
Line(17) specifies the type of service that the client wants to find. Line (18-21) illustrates the scope in which the target service
resides , in this case;an engineering department. If the target service matches the request, it replies to the client with a unicast
probe-match message (3).
A target service that adapt the above request will send a probe-match message as shown below [4].
 Figure 9
Line(08) indicates that the message is a probe-match. Line(13-15)shows that it is a response to a particular probe. Line(16-18)
shows that this message was sent through a resource identifier using TCP port. Line(29) list the type of service that target provides.
Line(30-34) lists all the scope that service resides in.

In case a client is already aware of a service's name, it can establish communication by using a Resolve message. If a target service
matches the request, it will reply directly to the client using a Relsolve-Match message.
In the fourth scenario, a service sends a Bye message to a multicast group when it prepares to leave the network. By listening to the
multicast group, the client will be aware of the state of the service and thus be able to dynamically remove all invalid metadata for
that target service from its cache.
5.2.2 Discovery Model with one or more Discovery Proxies in the network

Figure 10
The use of discovery proxies helps reduce multicast traffic over the network and enables scaling. To respond to multicast Probe or
Resolve messages from clients, the discovery proxies will send a unicast Hello message Also, a well-known discovery proxy may
send a unicast Probe or Resolve match message to client if it receives an unicast probe or resolve message from client. For the
client, they send unicast Probe(Resolve) message for subsequence searches or ,multicast probe or resolve message. Each discovery
proxy has a time out with a default value of 5 seconds. After this time out, if discovery proxy does not respond to the request, the
client will proceed by sending a multicast message. As for the services,they always send multicast Hello and Bye messages and
respond to the request of clients without needing to detect the presence of discovery proxies in the network.

6 Security Model

The WS-Discovery specification does not have any security aspect in-built but rather just mentions about considerations. The
security aspects are mostly left for another specification, namely; WS-Security to take care of. However, it recommends that some
kind of security be implemented to mitigate the risks for various kinds of attacks.
One of the recommendation is the use of signatures when sending messages as illustrated in below:
Step 1: Client signs the Probe Message and send over th ad-hoc network.

Figure 11
Step 2: Target service can verify the signature by opening it using his key. If the target service cannot verify the signature (message
has been tampered with) the message will be ignored.

Figure 12

Step 3: The Probe-Match message is then signed and sent back to the client which should have the key to open the message.

Figure 13

Compact Signature Format

Figure 14
Tag Element
Purpose

d:Security A sub-class of the wsse:Security header block [WS-

Security] that has the same processing model and rules but
is restricted in terms of content and usage.
provides a compact message signature. Its format is a
compact form of XML Signature. To process the signature,
d:Sig the compact form is parsed, and an XML Signature
ds:SignedInfo block is created and used for signature
verification.
Processing of the d:Security header block is not mandatory;
d:Security/@s11:mustUnderstand |
therefore, the d:Security header block SHOULD NOT be
d:Security/@s12:mustUnderstand
marked mustUnderstand with a value of "true".
7 Strong points of WS-Discovery

Dynamic discovery of services :

Services do not need to register with any registry to become available. Instead they can simply send a Hello message and
clients will be notified about their presence. Also discovery can be performed by clients through the use of probes as described
earlier.
Robustness:
WS-Discovery provides a robust way of accessing services to clients since it does not rely on any centralised registry.
Each client can independently discover services.

SOAP 1.1 and SOAP 1.2 support:

Thus it benefits from all SOAP advantages. Like running on different operating systems platforms, with different
technologies and programming languages and using the large number of development tools that are available for SOAP.

Extensibility :
WS-Discovery has been designed in such a way so as to enable the composition of other Web Specifications based on it.

Little networking service requirements:

There is no need for any DNS or Directory service to be available to use WS-Discovery and to be able to find out
services on the network.

Allow bootstrapping :
Due to its nature of not requiring prior knowledge of any address of a service such as a registry, any compatible device
can just connect to the network and access other services.

Reduce network traffic in managed networks where such services exist :

The flexibility of clients behavior can limit multicast traffic, because if the client detects a Discovery Proxy it will send
unicast Probe or Resolve[4]. Also through the use of Hello and Bye messages, the need for polling is reduced thus decreasing the
consumption of bandwidth.

8 Limitations

Ambiguous licensing :
From the specification document, developers are made aware that the group of companies involved in working out this
specification “"each agree to grant you a license, under reasonable, non-discriminatory terms and conditions, to their respective
essential Licensed Claims, which reasonable, non-discriminatory terms and conditions may include, for example, the payment of
royalties and an affirmation of the obligation to grant reciprocal licenses under any of the licensee's patents that are necessary to
implement the Specification." [4]. Thus it is not as free as other specification. This has definitely been one of the reasons to its slow
adoption.

Scalability :
Although the use of WS-Discovery can be scaled to a certain extent through the use of discovery proxies, at present it is
not able to scale over networks as large as the Internet [4]. This is mainly due to the high possibility of probes and other messages
getting lost, delayed or corrupted while traveling the Internet.

Multicasting :
The WS-Discovery protocol relies heavily on multicast messaging to function. And thus hardware and software
incompatible with multicasting systems will not be able to operate using this specification. Also, clients sending probes to a
multicast group can easily flood the network when they require access to several services concurrently in a ubiquitous computing
environment for example [8].

Security :
During the discovery phase, there is no access control mechanism in place and thus services are prone to denial of service
attacks in case a malicious client may either flood the network with probes with the objective of slowing or even preventing other
legitimate clients from accessing services [10].

No provision for a discovery-proxy protocol for interactions between clients and registries :
Because the main purpose of service registries is capturing or storing interface of new service, unlike UDDI which
defines a registry to allow client can interact to or WSDL that provides interface of service , WS-discovery is a protocol which
only supports the location of services through the exchanging of messages.
Others :
WS-Discovery does not provide liveness of information that is a service which has not been able to send a Bye message
before leaving will cause clients to have out-dated state information about it. Neither is a rich metadata model on WS information
[6].

9 Conclusion

WS-Discovery is a promising specification for near-future networks that tend to be mobile and pervasive. It successfully tackles
the limitations of UDDI through its approach of distributed system and dynamism. However for the time being it cannot be used
over networks as large as the Internet. WS-Discovery is an extension to Web Services that complements UDDI and is definitely not
here to replace the latter. The major concern that the industry had about adopting it was whether it will still be here after a few
years since it was not even standardised . This problem is at the very moment being solved by OASIS which is attempting to
ratified WS-Discovery as a standard [7].
We believe that the slow adoption of WS-Discovery is due to a timing problem; The time was not right yet in 2005 for the use
of WS-Discovery since the kind of ubiquitous and mobile networks that it is suitable for were very few in numbers. But now things
have changed and we are moving towards an era of pervasive computing where ad-hoc networks are simply everywhere. So we can
expect a widespread use of this specification in less than one year from now on.

10 References

1. “Web Services @ W3C,” http://www.w3.org/2002/ws/. Accessed on December 12, 2008

2. “WS-Discovery and its Relationship to UDDI - Travis Spencer - Software Engineer,”

http://travisspencer.com/blog/2007/09/post.html. Accessed on December 12, 2008

3. “UDDI Specification,” http://uddi.org/pubs/uddi-exec-wp.pdf. Accessed on December 12, 2008

4. “WS-Discovery Specification” http://specs.xmlsoap.org/ws/2005/04/discovery/ws-discovery.pdf. Accessed on December

12, 2008

5. "Evaluation of UDDI as a provider of Resource Discovery Services for OGSA-based Grids",

ieeexplore.ieee.org/iel5/10917/34366/01639275.pdf, Accessed on December 12, 2008

6. "Service Discovery by UDDI and Ws-Discovery",

http://grids.ucs.indiana.edu/ptliupages/presentations/WStutorialjuly04/services/UDDI2.ppt , Accessed on December 12,
2008

7. “OASIS Web Services Discovery and Web Services Devices Profile (WS-DD) TC,” http://www.oasis-
open.org/committees/ws-dd/charter.php. Accessed on December 12, 2008

8. Yun-Young Hwang et al., “Universal Service Discovery Protocol,” in Convergence Information Technology, 2007.
International Conference on, 2007, 2380-2385.

9. "Hello Message", http://msdn.microsoft.com/en-us/library/bb513682(VS.85).aspx Accessed on December 12, 2008

10. Slim Trabelsi, Jean-Christphe Pazzaglia, and Yves

;Slim Roudier,Jean-Christphe
Trabelsi, “Secure Web Pazzaglia,
Service Discovery:
and YvesOvercoming Challenges
Roudier, “Secure Web of
Ubiquitous Computing,” in Proceedings of the European Conference on Web Services (IEEE Computer Society,
Service Discovery: Overcoming Challenges of Ubiquitous Computing,” in Proceedings of the European Conference 2006),
on 35-43,
http://portal.acm.org/citation.cfm?id=1192641.
Web Services (IEEE Computer Society, 2006), 35-43, http://portal.acm.org/citation.cfm?id=1192641.