A Review of the Web Service Dynamic Discovery Discovery) Specification
Transcript of 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
Ahmed Alarifi
School Of Electronics and Computer Scienc
University of Southampton, UK
Quand Hung Ngo
School Of Electronics and Computer Science
University of Southampton, UK
-
8/14/2019 A Review of the Web Service Dynamic Discovery Discovery) Specification
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.
-
8/14/2019 A Review of the Web Service Dynamic Discovery Discovery) Specification
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
-
8/14/2019 A Review of the Web Service Dynamic Discovery Discovery) Specification
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.
-
8/14/2019 A Review of the Web Service Dynamic Discovery Discovery) Specification
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
-
8/14/2019 A Review of the Web Service Dynamic Discovery Discovery) Specification
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
-
8/14/2019 A Review of the Web Service Dynamic Discovery Discovery) Specification
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/2019 A Review of the Web Service Dynamic Discovery Discovery) Specification
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
-
8/14/2019 A Review of the Web Service Dynamic Discovery Discovery) Specification
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
-
8/14/2019 A Review of the Web Service Dynamic Discovery Discovery) Specification
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
-
8/14/2019 A Review of the Web Service Dynamic Discovery Discovery) Specification
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
-
8/14/2019 A Review of the Web Service Dynamic Discovery Discovery) Specification
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
-
8/14/2019 A Review of the Web Service Dynamic Discovery Discovery) Specification
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.
-
8/14/2019 A Review of the Web Service Dynamic Discovery Discovery) Specification
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