A Review of the Web Service Dynamic Discovery Discovery) Specification

8/14/2019 A Review of the Web Service Dynamic Discovery Discovery) Specification

1/14

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

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

Roushdat Elaheebocus

School Of Electronics and Computer Science

University of Southampton, UK

[email protected]

Ahmed Alarifi

School Of Electronics and Computer Scienc


[email protected]

Quand Hung Ngo

School Of Electronics and Computer Science


[email protected]


2/14

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 adhoc or pervasive networks; Web Service Dynamic Discovery (WS-Discovery) is a specification put forward by 5 major companie

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 bythe 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 itname, type, address and available methods to use on it. This gets even more complicated when the service changes address ofte

like for example in ad-hoc networks for example where a service can be available at one time and disappears in the next hour o

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 publis

themselves on it while enabling clients to access it to find out about services available. While this registry service is appropriat

for static networks, it is very inefficient in ad-hoc networks where high service volatility is a normal occurrence. Not all service

will get published in the registry and those that do, will falsely be displayed as available long after their withdrawal from th

network since UDDI in not able to dynamically update Web services states. As a solution for the problems highlighted aboveWS-Discovery has been proposed to tackle the lacking of UDDI and adopts a decentralised strategy whereby each client is abl

to discover services on its own without consulting any registry. Also clients in a multicast group are notified about the states of

Web service when the latter joins the network through a Hello message and a Bye message to signal its departure.


3/14

4 A brief comparison between WS-Discovery and UDDI

The diagram above shows a stripped-down version of a WS architecture proposed by Moreau & Luck. We have included the mo

probable location of the new specification (WS-Discovery) which is in the Metadata layer together with UDDI. Although W

Discovery performs discovery of Web services, the other sharing/discovering components were already present in the model. Th

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

over the network. Services that match what the client is looking

for answer back through a probe-match message. Also, clients

can send a resolve message if it is searching for a service by

name. In this case, the matching service will reply accordingly

with a resolve-match message.

UDDI consisting of a registry which resembles a phon

directory, contains entries for services that have been publishe

to it. Therefore, a client need only to query the registry to find

service.

Services can update their service status, that is whether they are

available or not by sending a 'Hello' message when joining anda 'Bye' message when parting. Thus clients can invalidate cache

entries that they hold for that particular service.

This is one of the major drawbacks of UDDI; UDDI has to cop

with out-dated service status on its own which is no easy task there are hundreds of services published on it and the regist

has to do the housekeeping tasks.

Using WS-Discovery, services can be discovered without them

needing to publish their details to any registry since each

individual client can send probe messages to discover services

over the network. This makes WS-Discovery suitable for

mobile environments where services are volatile such as

ubiquitous computing environments [8].

In order for a service to be accessible, it should publish itself t

the registry so that clients can look-up its details. Thus if it do

not know the address of the registry, it also means it can't l

others know how to access and use it.

WS-Discovery can be readily used over distributed systems due

to its inherent characteristic of being decentralised and can thusbe considered as robust since if a service or a client goes down,

the remaining components continue to operate without much

disturbance.

UDDI makes use of a centralised registry. Thus for some reaso

if the registry goes down, no clients will be able to accessservices since they will not be aware of services' details.

UDDI WS-Addr WS-MEX WS-D

Sharing / Discovering

Messaging / Addressing

Protocols

Composition

OGSA

Message QOS

Description

Assertions

Coordination QOS

Management

HTTP HTTPS SMTP

Management

Process / Coordination

Security / Identity

Metadata

Messaging

Transport

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


4/14

Although the specification has seen the participation of big

companies like Microsoft, it has not yet been ratified by any

standards body.

UDDI has been published as a third version already and is

considered quite mature. OASIS governs UDDI.

[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-define

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 byMicrosoft.

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/14

5 Technical Details

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 internall

with a process responsible for sending a probe message; labeled as 'Finder'. The probe message is either sent to a multicas

group, or if a discovery proxy is available (this case), it is sent to it. The discovery proxy then proceeds by sending probmessages 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 UD

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 UR

NameSpaces:http://schemas.xmlsoap.org/ws/2005/04/discovery that defines the directory of WS-Discovery including its schem

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 ty

of these messages.

Figure 2: WS-Discovery process architecture

Exchange

Service

Publisher

ServiceHost

Discovery Proxy

Client

Fin

d

Resu

lt

Finder

Listener

ProbeProbe-MatchHell

oByeHelloBye

Bye

Hello

Probe

Probe-Match

Probe

Pro

be

Probe

ServiceHost


6/14

Hello Message

A one way multicast Hello Message is used in two cases. One is when a target service joins the network, another is whmetadata or scope is changed [6]. The Hello message may be unicast in case there is discovery proxy in the network. The discove

proxy will then forward the message as multicast. In case no discovery proxy is available, the service can send the Hello as

multicast over the network.

Figure 3 shows a screenshot of a formal Hello Message structure in which there are two main parts; and .Th contains information about the type and mechanisms to be used. In particular, the sub-tag must be used by a Discovery Proxy for responding to multicast Probes from clients. The bo

defines the destination of the message through the sub tag .This part may also define other mechanism

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 invalida

corresponding data in the cache for that particular service. Similarly to the Hello message, the Bye message can be unicast if

discovery proxy exists in the network. The structure of Bye Message is the same as the Hello Message structure,except for th

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 messa

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

the client.

Figure 3: A Hello Message Structure


7/14

The figure above shows the structure of a typical Probe Message. Note that in the header, an enpoint-reference is used inside t

tag so that services matching the probe know how to contact the sending-client. The scope and type of service ththe client is looking for is specified in the sub tags and inside the tag container.

For aprobe-match message, the service that finds itself matching a probe will include its own parameters such as type, score a

most importantly its address. The address is in the tag that the client receiving the probe-match message can then u

to establish communication. . In case the service is responding directly to a client, it will contain only o

child but if it replying to a discovery proxy instead, the latter when forwading probe-matches will concatena

probe-match messages from several services and thus the probe-match message from the proxy can have more than o

child.

Figure 4: A probe message structure

Figure 5: A probe-match message structure


8/14

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 bnot having "enough metadata to bootstrap communication with the target service"[6]. The resolve (and resolve-match) structure

almost similar that of a Probe (and probe-match) message.

5.2 WS-Discovery processing models

5.2.1 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 w

help the client to dynamically detect the newly available service thus reducing probing by the client. As a result multicast traf

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 6: A discovery model without discovery proxy

Figure 7


9/14

Line (11-13) identifies this message as being a Hello message, line (17-20) contains application sequencing information such

instance id, sequence id and message number as well. Line (25-27) refers to an endpoint reference in the network. Line (2

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. Fo

example,a client looking for a print service will send a message as shown below [4].

Line (7-9) show the message type which is a probe. Line (13) indicates that the message will be directed to a well-known addre

Line(17) specifies the type of service that the client wants to find. Line (18-21) illustrates the scope in which the target servic

resides , in this case;an engineering department. If the target service matches the request, it replies to the client with a unicaprobe-match message (3).

A target service that adapt the above request will send a probe-match message as shown below [4].

Figure 8


10/14

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-1

shows that this message was sent through a resource identifier using TCP port. Line(29) list the type of service that target provide

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 servi

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 t

multicast group, the client will be aware of the state of the service and thus be able to dynamically remove all invalid metadata fthat target service from its cache.

Figure 9


11/14

5.2.2Discovery Model with one or more Discovery Proxies in the network

The use of discovery proxies helps reduce multicast traffic over the network and enables scaling. To respond to multicast Probe

Resolve messages from clients, the discovery proxies will send a unicast Hello message Also, a well-known discovery proxy m

send a unicast Probe or Resolve match message to client if it receives an unicast probe or resolve message from client. For t

client, they send unicast Probe(Resolve) message for subsequence searches or ,multicast probe or resolve message. Each discove

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, th

client will proceed by sending a multicast message. As for the services,they always send multicast Hello and Bye messages an

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. Tsecurity aspects are mostly left for another specification, namely; WS-Security to take care of. However, it recommends that som

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 belo

Step 1: Client signs the Probe Message and send over th ad-hoc network.

Figure 10

Figure 11


12/14

Step 2: Target service can verify the signature by opening it using his key. If the target service cannot verify the signature (messa

has been tampered with) the message will be ignored.

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

Compact Signature Format

Tag ElementPurpose

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.

d:Sig

provides a compact message signature. Its format is a

compact form of XML Signature. To process the signature,the compact form is parsed, and an XML Signature

ds:SignedInfo block is created and used for signature

verification.

d:Security/@s11:mustUnderstand |

d:Security/@s12:mustUnderstand

Processing of the d:Security header block is not mandatory;therefore, the d:Security header block SHOULD NOT be

marked mustUnderstand with a value of "true".

Figure 12

Figure 13

Figure 14


13/14

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 a

clients will be notified about their presence. Also discovery can be performed by clients through the use of probes as describeearlier.

Robustness:

WS-Discovery provides a robust way of accessing services to clients since it does not rely on any centralised regist

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 differe

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 ouservices 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 sendunicast Probe or Resolve[4]. Also through the use of Hello and Bye messages, the need for polling is reduced thus decreasing th

consumption of bandwidth.

8 Limitations

Ambiguous licensing :From the specification document, developers are made aware that the group of companies involved in working out th

specification "each agree to grant you a license, under reasonable, non-discriminatory terms and conditions, to their respectiv

essential Licensed Claims, which reasonable, non-discriminatory terms and conditions may include, for example, the payment royalties and an affirmation of the obligation to grant reciprocal licenses under any of the licensee's patents that are necessary

implement the Specification." [4]. Thus it is not as free as other specification. This has definitely been one of the reasons to its slo

adoption.

Scalability :

Although the use of WS-Discovery can be scaled to a certain extent through the use of discovery proxies, at present it

not able to scale over networks as large as the Internet [4]. This is mainly due to the high possibility of probes and other messag

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 softwaincompatible with multicasting systems will not be able to operate using this specification. Also, clients sending probes to

multicast group can easily flood the network when they require access to several services concurrently in a ubiquitous computienvironment for example [8].

Security :

During the discovery phase, there is no access control mechanism in place and thusservices are prone to denial of servi

attacks in case a malicious client may either flood the network with probes with the objective of slowing or even preventing oth

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.


14/14

Others :

WS-Discovery does not provide liveness of information that is a service which has not been able to send a Bye messagbefore leaving will cause clients to have out-dated state information about it. Neither is a rich metadata model on WS informatio

[6].

9 Conclusion

WS-Discovery is a promising specification for near-future networks that tend to be mobile and pervasive. It successfully tack

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 n

here to replace the latter. The major concern that the industry had about adopting it was whether it will still be here after a fewyears 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 thin

have changed and we are moving towards an era of pervasive computing where ad-hoc networks are simply everywhere. So we c

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 Specificationhttp://specs.xmlsoap.org/ws/2005/04/discovery/ws-discovery.pdf. Accessed on Decembe12, 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 Roudier, Secure WebService Discovery: Overcoming Challenges of Ubiquitous Computing, inProceedings of the European Conference on

Web Services (IEEE Computer Society, 2006), 35-43, http://portal.acm.org/citation.cfm?id=1192641.

Slim Trabelsi, Jean-Christphe Pazzaglia, and Yves Roudier, Secure Web Service Discovery: Overcoming Challenges o

Ubiquitous Computing, inProceedings of the European Conference on Web Services (IEEE Computer Society, 2006)

http://portal.acm.org/citation.cfm?id=1192641.
http://specs.xmlsoap.org/ws/2005/04/discovery/ws-discovery.pdfhttp://specs.xmlsoap.org/ws/2005/04/discovery/ws-discovery.pdfhttp://grids.ucs.indiana.edu/ptliupages/presentations/WStutorialjuly04/services/UDDI2.ppthttp://grids.ucs.indiana.edu/ptliupages/presentations/WStutorialjuly04/services/UDDI2.ppthttp://msdn.microsoft.com/en-us/library/bb513682%5C(VS.85%5C).aspxhttp://grids.ucs.indiana.edu/ptliupages/presentations/WStutorialjuly04/services/UDDI2.ppthttp://msdn.microsoft.com/en-us/library/bb513682%5C(VS.85%5C).aspxhttp://specs.xmlsoap.org/ws/2005/04/discovery/ws-discovery.pdf

Documents

A Review of the Web Service Dynamic Discovery Discovery) Specification