Implementation of Runtime Web Service Discovery
Ms. Rohini Jadhav, M.Tech Student
Dept of Computer Engineering,B. V. U. College of Engineering,
Pune, Maharashtra 411043, India
[email protected]
Abstract— During the execution of service based application
there is an important issue for replacing the service in them which
fails to satisfy the current requirement or is no longer present.
Identification of services based on different service parameters
such as structural, quality, behavioral and contextual leads to
effective runtime discovery of service. So in this paper, we are
introducing a framework that support runtime services discovery.
The framework supports two modes of execution of query for
service discovery namely pull and push mode. In pull mode
(reactive way), queries are executed when a need for finding a
replacement service arises (for example: unavailability or
malfunctioning of service, emergence of new service, changes in
structure functionality etc.).In push mode (proactive way),
execution of query is carried out in parallel to the service-based
system execution. Hence, if there is a need to replace a service in
service based application, push mode of execution of query makes
it possible to avoid interruptions in the operation of application.
Both types (i.e., pull and push) of queries are specified in a XML
based query language called SerDiQueL. SerDiQueL is the
language that allows the representation of behavioral
(functionality), structural (interface),quality, and contextual
conditions of services to be identified. So in this paper, we are
going
to
discuss
the
runtime
service
discovery
framework.Keywords—component; formatting; style; styling;
insert (key words)
Index Terms— Web Service Discovery, Web Services, XML,
Dynamic Service Discovery.
I.INTRODUCTION
Services are nothing but entities that are owned by a third
party in a service based application. Such services are
helpful in creating the dynamic business processes. Due to
various changes in market, it is necessary to identify the
services that will directly fulfill the need of user by
providing the appropriate quality and functional features of
service based application .The process of identifying such
services is called as service discovery. Several researches
and approaches has been developed to support service
discovery, classified as static[1], [2], [3], [4] and dynamic
[5], [6], [7], [8] approaches. The services which are
identified during the application development and prior to
execution comes under static approach while the services
that are identified during the execution of the application
comes under dynamic approach. There are various scenarios
where we need to replace the service during the execution of
application.
Following are the scenarios due to which we need to replace
the services:
1) Due to service unavailability , service malfunctioning.
Prof. Dr. S.D.Joshi, Professor
Dept of Computer Engineering, B. V. U. College of Engineering
Pune, Maharashtra 411043, India
[email protected]
2) Changes in the interface, behavioral, quality, service
context in the application due to the service which no
longer fulfill its task.
3) The emergence of new services that which fulfill the task
in better way than the existing service.
4) Changes in the application context due to services which
is used no longer fulfill its task.
The above scenarios give rise to a question, i.e, how to
support the application when the service which is being used
is not working properly or stop functioning as desired, as
well as changing the application and their services
continuously at runtime .To address such questions we
require a flexible and dynamic service identification at the
runtime of service based application.
Currently most of the approaches uses pull mode of query
execution for dynamic service discovery. This mode of
query execution is often not effective because the discovery
process starts only if the requirement for a new service
arises (as in case 1 above) and it may also consume more
time to complete, which will affect the application
performance and its capability to produce acceptable or
appropriate services (as in case 3 above). Similarly, for
cases 2 and 4 above, pull mode discovery would need to
wait until the changes that made used services become
inadequate arise at runtime, as in case 1. Alternatively, the
pull mode of query execution would need to be enhanced
for
polling service registries regularly and/or context
information resources to identify changes that can create
subsequent problems. Such polling would consume
resources as even if there is no need to do so it would need
to be executed at regular intervals (i.e., in case of emergence
of new services ,application environment, in the absence of
service context changes or context changes).
Furthermore, existing approaches to service discovery (with
the exception of [8]) do not consider different characteristics
of the application at the same time when attempting to
identify services such as interface(structural), functional
(behavioral), quality, and contextual aspects .
To address the existing approaches limitations, we present a
web service discovery framework that supports runtime
service discovery based on complex queries that can express
flexible combinations of structural, quality, contextual and
behavioral
parameters. These complex queries are
specified in an XML-based query language, called
SerDiQueL. The framework assumes services that have
different descriptions including service behavioral,
interface, quality, and context descriptions.
To support entire cases 1 to 4 above and avoid the
limitations of traditional mechanisms for polling, our framework allows service discovery based on both push and pull
query execution modes. Pull mode query execution is
triggered in cases 1 like scenarios above. In push mode,
query execution is performed in parallel to the execution of
the application using queries. These queries maintain up-todate sets of candidate replacement services for these
services and are associated with specific services in an
application . In both pull and push modes, execution of
query is based on matching and the computation of service
specifications and distances between query.
response time will need to be identified and bound to onthe-go-News.
A third condition arises when, while a user of application
is traveling by train, he loses access to the service that
displays and supports flipping through news (i.e., a service
called SDisFlip) since SDisFlip cannot be accessed at his current
location. This change in the location of on-the-go-News
(Case 3) requires searching for an alternative service that
could be used in the user’s current location.
A fourth condition arises when a new service that allows
payments by debiting the user’s bank account and credit
card payments instead of charging the user’s phone bill
becomes available (Case 4). If flexibility in payment is
desirable in on-the-go-News, the new service should be
bound to the application.
II. OVERVIEW
2.2 Framework Support
In this section, we will be presenting some scenarios for
runtime web service discovery and give an overall
description of how our framework will be useful to address
these scenarios.
2.1 Runtime Web Service Discovery Scenarios
Various scenarios regarding runtime service discovery can
beidentified in reference to a mobile service based
applicationcalled On-the-go-News[10] .
On-the-go-News allows its users to request and receive
news from different sites from their mobile phone. To do so,
the application offers services allowing users to:
1.
Searching of news topics and select the from where
they want to receive the news,
2. from different sources, display news about a
searched topic
3. create customized on-the-fly “magazines”
4. flip through articles in a customized magazine from
several sources,
5. Get and pay for the paid available information,
charging the amount in the user’s phone bill at the
end of the month, and
6. see the new balance of their phone bill after using
the application for 5.
The above application uses an external service, called
SService, which go through different news sites to get news
about specific topics, and another service, called SCustMag,
which enables the amalgamation of news and make them
available in an on-the-fly magazine.
After receiving a request one condition of runtime
service discovery can arise , and application is not able to
connect SService due to which the service which is ahead is
unavailable (Case 1). In this case, the application will need
to search or identify a new service to replace SService. After
the new service is noticed and bound to application,the user
who sent the request will start receiving the requested
information from various sites.
A second condition may arise if a user who wants an onthe-fly magazine on his/her mobile phone about climate
change and created such a magazine using SCustMag starts
getting a slow response from SCustMag as the service is used
by many different users simultaneously (Case 2). In such
cases, an alternative service for SCustMag with acceptable
Fig.1 Architecture of various components in runtime
service discovery framework
Runtime service discovery consists of web service user
interface, application data server, service data server,
service analyzer, request web service, match finder, service
catalog system, external service catalogs.
The web service user interface is used by the user
to query for a web service which provides access to
framework. It represent request entry point and response
exit point.
The request web service block offers various
functionalities. It instantiates the service queries to be
executed by the matchfinder based on the various situations,
receives responses from matchfinder, collect, organize the
result and send it to the web service interface etc.
The matchfinder is responsible to parse the
constraints of a query and evaluate these constraints against
service specifications in the various service registries. The
matchfinder
consists of two stages filtering and ranking.
The service catalog system provides the use of
different service registries. Its main aim is to provide an
interface, which allows the matchfinder to access services
from various different type registries.
The service data server and application data server
enable context information is to be subscribed. They also
allow to spread context information of the services and
application environment.
The service analyzer provides the information
about the new service available or information about
changes in structural, behavioural, quality characteristics of
existing services of an application.
3.WEB SERVICE DISCOVERY QUERY LANGUAGE
A runtime service discovery query may contain
different criteria, namely: 1) constraints, specifying
additional conditions for the service to be discovered; 2)
structural criteria, specifying the interface of the required
service; 3) behavioral criteria, specifying the functionality
of the required service; and. The latter conditions may refer
to quality parameter of the required service or interface
characteristics of services that cannot be represented by the
standardized forms of structural descriptions used in the
framework. Examples of constraints referring to quality
characteristics of services may concern the maximum
response time or cost to execute a certain operation in a
service.
The constraints in a query can be contextual or noncontextual. A non-contextual constraint is concerned with
static information, while a contextual constraint is mostly
concerned with information that changes dynamically
during the operation of the service-based application or the
services that the application deploys. The constraints are of
two types namely hard or soft. Soft constraints do not need
to be satisfied by all discovered services, but are used to
rank candidate services.
To specify runtime service discovery queries, we have
developed an XML-based language,called SerDiQueL.
SerDiQueL allows the specification of all the behavioral,
structural, quality, and contextual characteristics required
from the services to be discovered. An earlier version of
SerDiQueL was presented in [9]. The new version of the
language that we present in this paper enables the
specification of the required behavior of a service using
behavioral conditions rather than a full BPEL model of
service behavior as in the original version.
3.1 Structural Subquery
The structural subquery describes the interface of
the required service. Structural subqueries in SerDiQueL are
specified using WSDL [16]. The use of WSDL in this
scenerio is due to its wide acceptance as a service interface
description language. In addition, during runtime service
discovery, any replacement service that might be identified
for an existing service in a service-based application will
need to conform to the interface of the existing service. A
structural subquery in SerDiQueL is specified as the WSDL
specification of the service to be replaced.
3.2 Behavioral Subquery
Behavioral subqueries in SerDiQueL support the
specification of
1. the order in which the required functionalities should be
executed by the service,
2. the existence of required functionalities in a service
specification,
3. dependencies between functionalities (e.g., a functionality
realized by an operation always requires the existence of a
functionality of another operation),
4. loops concerning execution of certain functionalities.
Behavioral subqueries are expressed by elements that are
similar to temporal logic operators . and
5.. preconditions
3.3 Constraint Subquery
A constraint subquery in SerDiQueL is defined as
a conjunction/ disjunction of two or more logical
expressions, or single logical expression combined by
logical operators AND and OR, or a negated logical
expression. Query constraints have four attributes:
1. name, specifying the name of the constraint;
2. type, indicating whether the constraint is hard or soft;
3. weight, specifying the significance of the constraint as a
real number in the range [1.0, 0.0]; and
4. contextual, indicating whether the constraint refers to a
noncontextual or contextual feature of a service.
The weight of a constraint is used to prioritize it
against other soft constraints when inexact matches are
found in query evaluation. A constraint subquery whose
contextual attribute is true contains ContextOperand
elements. When this attribute is set to false, the query may
only contain NonContextOperand elements.
A logical expression is defined as a condition, or
logical combination of conditions, over elements or
attributes of service specifications or context aspects of
operations.
4. WEB SERVICE DISCOVERY PROCESS
Service Discovery process contains following process:
4.1 Query Matching Process
Matching between services and queries is executed
in two stages: the filtering stage and the ranking stage. In
the filtering stage, only the hard non contextual constraints
of a query are evaluated against service specifications and
the candidate services that comply with these constraints are
identified.
The ranking stage has three sub stages.
In the first of these sub stages, the structural and
behavioral parts of a query are evaluated against the services
maintained by the filtering stage and a structural-behavioral
partial distance between each of these services and the query
is computed.
In the second sub stage, the soft non contextual
constraints of the query are evaluated against each candidate
service and a soft non contextual partial distance is
computed for each such service.
Finally, in the third sub stage, the contextual
constraints of the query are evaluated against the candidate
services and a contextual partial distance is computed for
each candidate service.
At the end of the ranking stage, the partial
distances computed for each service are aggregated into an
overall distance and only services whose distance to the
query is below a certain threshold are maintained.
4.3 Module Information
Module1:
Design the Graphical User Interface (GUI) and database for
our system. Login and registration of user.
Module2:
Registration of new services and initialization of data.
Register to the framework a list of service
endpoints that it wishes to use along with one query for each
such service that should be used for discovering alternatives
to it.
Module3:
On The Go News Application.
On-the-go-News allows its users to request and
receive news.
To do so, the application offers services allowing users to:
1. Search for certain news.
2. Display news about a topic from various sources.
3. Pay for news if it is ‘paid news’.
Module4:
Runtime Service Discovery Framework (RSDF):
Building various components of Runtime Service
Discovery Framework (RSDF) such as Service Requester,
Service Listener, Execution Engine, service Matchmaker,
Service registry intermediately etc.
5. RESULTS
Below are the web services that we have retrieved
when we search for it by considering the structural ,
behavioural, quality, location parameters. The user can also
subscribe for the web service and update the same. We have
also created the log files to compute the time required by
both modes and we found that push mode is 10 times faster
than that of pull mode.
6. CONCLUSION
In this paper, we have seen a framework for dynamic
service discovery in which candidate services are used to
replace the existing services of service based application.
This framework also overcome the problem of various
scenarios for eg. Malfunctioning or unavailability of
services, etc. In both pull and push query execution modes,
a service is matched against a query based on computation
of distances between query and service specifications. The
framework uses complex queries expressed in an XMLbased query language named SerDiQueL. The language
allows the representation of structural, behavioral, quality,
and contextual characteristics of services and applications.
And also we have compared the results of pull and push
mode.
REFERENCES
[1] D. Grirori, J.C. Corrales, and M. Bouzeghoub,
“Behavioral Matching for Service Retrieval,” Proc. Int’l
Conf. Web Services, 2006.
[2] U. Keller, R. Lara, H. Lausen, A. Polleres, and D.
Fensel, “Automatic Location of Services,” Proc.
European Semantic Web Conf., 2005.
[3] L. Li and I. Horrock, “A Software Framework for
Matchmaking Based on Semantic Web Technology,”
Proc. Int’l Conf. World Wide Web, 2003.
[4] Z. Shen and J. Su, “Web Service Discovery Based on
Behavior Signatures,” Proc. Third Int’l Conf. Service
Computing, 2005.
[5] S. Cuddy, M. Katchabaw, and H. Lutfiyya, “ContextAware Service Selection Based on Dynamic and Static
Service Attributes,”
Proc. IEEE Int’l Conf. Wireless and Mobile
Computing, Networking, and Comm., 2005.
[6] C. Doulkeridis, N. Loutas, and M. Vazirgiannis, “A
System Architecture for Context-Aware Service
Discovery,” Electronic Notes of Theoretical Computer
Science, vol. 146, no. 1, pp. 101-116, 2006
[7] H. Niu and Y. Park, “An Execution-Based Retrieval of
Object-Oriented Components,” Proc. 37th ACM
Southeast Regional Conf.,1999
[8] S. Singh, J. Grundy, J. Hosking, and J. Sun, “An
Architecture for Developing Aspect-Oriented Web
Services,” Proc. Third European Conf. Web Services,
2005.
[9] G. Spanoudakis, K. Mahbub, and A. Zisman, “A
Platform for Context-Aware RunTime Service
Discovery,” Proc. IEEE Int’l Conf. Web Services,
2007.
[10] G. Spanoudakis, A. Zisman,James Dooley,Igor Siveroni
“Proactive
and
Reactive
Runtime
Service
Discovery:Framework and its evaluation. ”
[11] I. Horrocks, P.F. Patel-Schneider, and F. van Harmelen,
“From SHIQ and RDF to OWL: The Making of a Web
Ontology Language,” J. Web Semantics, vol. 1, no. 1,
pp. 7-26, 2003.
[12] J. Kim, J. Lee, and B. Lee, “Runtime Service Discovery
and Reconfiguration Using OWL-S Based Semantic
Web Service,” Proc. Seventh IEEE Int’l Conf.
Computer and Information Technology, 2007.
[13] L. Baresi, C. Ghezzi, and S. Guinea, “Towards SelfHealing Compositions of Services,” Studies in
Computational Intelligence, vol. 42, Springer, 2007
[14] O. Moser, F. Rosenberg, and S. Dustdar, “NonIntrusive Monitor- ing and Service Adaptation for WSBPEL,” Proc. 17th Int’l World Wide Web Conf., 2008.
[15] D. Ardagna, M. Comussi, E. Musi, B. Pernici, and P.
Plebani, “PAWS: A Framework for Executing Adaptive
Web-Service Processes,” IEEE Software, vol. 24, no. 6,
pp. 39-46, Nov./Dec. 2007.
[16] “WSDL,” http://www.w3.org/TR/wsdl, 2013.