Gateway for Bio-Informatics web services driven by
Quality of Service
Abineshraj Rajagopal
School of Computing, Clemson University
arajago@clemson.edu
Abstract— Bioinformatics usually involve huge volumes of data
and web services are really a convenient interface of providing
data to the clients who want to use the data. Many bioinformatics
institutions have started providing web services for their
services, So there is need for the user to determine the best web
service for his functionality and use it. In this paper we propose
a model that will provide a common single interface for different
web services offering the same functionality. This interface will
select the web service based on the performance of the web
service against certain Quality of Service(QoS) parameters. This
model avoids overhead in the user part in selecting the web
service for executing his request to the web service.
Keywords—Bio-informatics web services, Quality of Service,
Interface for Bio-informatics web services
Introduction
Definition:
A Web service is a software system designed to support
interoperable machine-to-machine interaction over a network
[1].
Web services are loosely coupled software components
delivered over standard Internet technologies. Web services
are platform- and vendor-neutral protocols that enable
different applications from different sources to communicate
with one another in a common XML format without time-
consuming custom coding.
Web services are described by standard internet protocols
such as the, which makes them independent of the platform,
since all of these use xml underneath.
SOAP (Simple Object Access Protocol)
UDDI (Universal Description, Discovery and Integration)
WSDL (Web Services Description Language)
Web services in Bio-informatics:
Bioinformatics institutions have started providing web
services for their various services. This enables the people
who want biological data to run and get the results
asynchronously without interaction of the human beings. This
allows faster and convenient retrieval of data.
Bioinformatics usually involves large volume of data since
they primarily deal with genomic sequences, DNA, RNA,
protein and sequence data. (Require some solid thing). So
there are various sources (Bioinformatics Institutions) like
EBI, NCBI, DDBJ, and SWISS Port that provide web services
for their different functionalities like
• Retrieval of Genomic data
• Multiple Sequence Alignment
• Similarity Analysis
Since there is large number of web-services provided by
various institutions, the user has a lot of options to choose
from. So there should be a system that provides knowledge of
the existing web services and provides a thorough evaluation
of different web services so that the user can chose the best
service required for his necessity.
Web services do not provide any guaranteed level of
service[6]
Quality of Service (Qos) measures has been established as a
well-accepted method to evaluate the effectiveness of a web
service, since they consider various important Quality aspects
of the web service in to consideration. QoS of a web service
refers to the non-functional properties of the web service such
as the performance, reliability and availability [2]. Especially
with the growing popularity of web services among the bio-
informatics data domain the QoS plays a vital role in
determining the success of the web service as well as its usage
to the user. [3] [7]
The QoS a service provider delivers will become a decisive
criterion when services with the same functionalities are
available at customers’ choice.[9
Qos Broker:
A QoS broker receives clients’ QoS service requests and
identifies qualified services for them.[8]
So it is very important to evaluate the Bioinformatics web
service for Quality of Service (QoS). Right now there is no
common system that gives an idea of how well the web
services for bioinformatics performs, particularly a biology
scientist in order to choose the web service would want to
consider the Quality of Service of the web services. So there
ss definite necessity of a QoS broker for bioinformatics web
services, in this paper we propose and implement a system
that will enable a user to run his request on the web service
with the best Quality of Service (QoS) metrics for that
particular functionality. In a way our system is going to act
like QoS broker[4] for Bioinformatics web services.
Another important aspect of the bioinformatics web servers
are that they sometimes receive a bulk of requests in a short
period of time at which they are busy and find difficult to
process other requests. Also they may be down for a particular
period of time on a scheduled maintenance. So it is very
important that the QoS broker for bioinformatics data
considers the most recent activity of the web services in to
account and chooses the best web service. Our system
incorporates the idea taking the most recent QoS metric
performance of the webservice in selecting the required web
service.
Also different web services have different interfaces, so a
person who is interested in finding biological data might have
to give requests to all the different web services and get the
results in different pages. Our system aims in integrating all
the interface of different web services and provide a single
interface for a particular request. This avoids the user from
going around different web pages for getting results from
different web services.
Another important aspect of our proposed system is that, it
allows the user to specify the number of web services for
which the request has to be processed.
Background and Related Work:
There are several web services registers that act like a
common portal for different web services. They provide
information on web services like their availability, how well
the web service rated was previous users and some other
information on the web services. For example EMBRACE
service registry[5], is a common portal for many biologica
web services. EMBRACE service registry is a collection of the
life science web services with built-in service testing[5]. They
also provide non-functional information about the web
services like the availability, the current status of the web
services and also some historical information. There are few
registers that provide similar services. Some of the similar
web service registry provide a rating and feedback facility to
be given by the user, once they are used. This allows to give
better information for someone who wants to use the web
service for the first time.
At present, UDDI is just a registry database that allows
clients to look for Web services based on their functionality
but not QoS information. The lack of adequate QoS support
prevents the adoption of performance sensitive web services.
[8]
The system we have proposed is also similar in a way that
it integrates all the different web services and provides a
portal to access to all the different web services. It also is in a
way a common pool for web services. The important
difference comes is that our system aims in comparing the
different web services and analysing the performance of the
web services relative to each other based on certain Quality of
Service (QoS) parameters. Contrast to this the registry’s are
designed to provide an common pool for web services and
aimed at giving information about the individual web service.
Also the main purpose of our system is to avoid any user
role in selecting the web service when he has to run a
particular task. This is different from the objective of the
already existing registry services for web services which is
provide information abour the web services and then allow the
user to select the web service. Our system enables a naïve user
with no knowledge of the web services to execute a task on a
web service that will efficiently finish the job. Also since the
choice of web services is done based on the most recent
behaviour of the web service, there is a lot of possibility that it
will avoid choosing a web service that is down or very slow.
Moreover, most of the current approaches rely on service
providers to advertise their QoS information or provide an
interface to access the QoS values, which is subject to
manipulation by the providers. Obviously, service providers
may not advertise their QoS information in a “neutral”
manner, for example, execution duration, reliability, etc
The major limitations of our system would be, if the user
wants to run a particular web service, at this moment we don’t
have provision to do that. And we don’t have a feedback
system for our model that will effectively help in improving
our system.
We have a QoS broker sitting in between the web services
servers and the clients.
Difference QoS broker of our model and existing QoS
brokers.
Highlight the difference between the QoS broker that I have
designed and the actual QoS broker how the negotiations of
QoS takes place.
IBM’s Web Service Level Agreement (WSLA)
QoS Model Architecture:
Our model:
No commitment (no negotiation) from the server regarding
providing the promised level of QoS to the client. All the
connections providing is based on the historical information.

Implementation
A Client Perceived QoS
Model for Web Services
Selection
Optimal Selection of Web Services for
Composition Based on
Interface-Matching and Weighted
Multistage Graph
Describes how to calculate the effecitive QoS from various
QoS parameters.
I. PAGE LAYOUT
An easy way to comply with the conference paper
formatting requirements is to use this document as a template
and simply type your text into it.
A. Page Layout
Your paper must use a page size corresponding to A4
which is 210mm (8.27") wide and 297mm (11.69") long. The
margins must be set as follows:
• Top = 19mm (0.75")
• Bottom = 43mm (1.69")
• Left = Right = 14.32mm (0.56")
Your paper must be in two column format with a space of
4.22mm (0.17") between columns.
Our System
A. Quality of service:
Quality of Service (QoS) parameters:
Quality of Service parameters for a web service refers the
non-functional aspects of the web services and there are many
parameters that can be considered for web services [2]. IBM
describes a concise list of web services that can be
incorporated for web services. In bioinformatics web services
we have considered only those that are available free and
adhere to standards to parameters such as “Execution
cost”[11] were not considered. Some other QoS parameters
such as the compliance, successability and Reputation can be
incorporated in the web service only if there is a feedback
system from the Client used[12]. We have considered only
instance-level[13] / uncertain attibutes[14] QoS metrics
whose values will vary between two different invocations of
the same web service.
Round Trip Time:
QoS of a web service represents the time difference between
the start of the invocation of the request to the time at which
the response is obtained from the server.
Availability:
Availability is defined as the probability that the service is
available for use[2, 13, 16]. It can be mathematically
represented as the ratio of number of times the web service is
available to the total number invocations of that particular
web service [14].
Reliability:
Reliability can be defined as the probability that the web
service completes its service functionality [13, 14]. An
effective way to incorporate reliability metric in web service
is to compute the probability that the service was completed
within a specific time [16].
The above parameters were considered in designing the QoS
broker for bioinformatics web services.
Architecture of the System:
Bioinformatics institutions offer web services for many
functionalities. In our interface we have considered three main
categories of web services in the bioinformatics domain.
Multiple Sequences (MSA), Similarity Analysis and Data
Retrieval. The architecture of the system includes three main
roles the QoS Engine, Web service Requester and the Web
service Provider.
Web Service Provider:
Web Service provider is the provider of a particular web
service functionality. In our case the web service providers
were EBI, NCBI and DDBJ.
Web Service Requester:
Web service Requester is the person who wants to use the web
service to obtain results for his queries.
QoS Broker:
The core of the system is a Web Service QoS broker [] that
acts as in interface between the web service client requests
and the web services provider. The QoS broker that we used
in our system is a monitoring QoS broker. The broker
periodically monitors the performance of the web services and
stores the QoS values. We have implemented Web service
clients for three categories of web services, the QoS broker
invokes the web services using these web service clients.
Corresponding to each functionality of bioinformatics
services, there is a set of web services offered by different
providers. The web services are invoked using test data by
their client implementations. The same test data is queried
against all the web services under a category, so consistency is
maintained during evaluation of the web services. The Round
trip time it takes to complete the service, availability and
Reliability readings for each we service are stored in a QoS
database table corresponding to the functionality. This
evaluation of the web services by this monitoring technique is
done in a regular basis and the QoS database is up to date.
Since we have a system that has composite QoS parameter,
that considers many QoS parameters under consideration
before selecting a web service, there is a necessity to find a
methodology to calculate the effective QoS value to select the
web service. Our system uses weighted values for QoS
parameters based on the importance of the QoS parameter,
frequency of change in value of the parameter and how far it
can impact the effectiveness in usage to the client. Based on
experimental result Round Trip time was considered as the
most important QoS parameter and it was given of weight of
60% in the effective QoS. Almost all the web services were
available for most of the time and reliability also seemed not
to affect much, so the parameters were given weights of 20%
So the effective QoS was computed using a simplified
approach that was proposed in [14]. The summation of all
weights given to QoS parameters is 1. The effective QoS
would be summation of product of QoS values and their
corresponding weights [14].
During a client invocation the QoS broker does the following
steps to ensure the selection of optimal web service for the
functionality.
(a) Identifies the entire set of web services associated
with the category of the Request.
(b) Looks up the QoS database to find the web service
that has the best effective QoS value among all the
web service.
(c) Invokes the web service that has been found in (b).
Interface:
Even though clients for many web services were
implemented, only one interface was given to enter the data
for all web services meant for a same functionality. When the
user makes a request the QoS broker invokes the optimal web
service based on Quality of Service parameters. The output of
the request is displayed to the user, a Result ID is also given to
the user to enable the future retrieval of the result.
The system stores QoS values for actual requests made by the
user also. They are also treated as normal QoS values and
helps the QoS broker in understanding how the web services
behave in real data.
Another important aspect of the interface is that, it has a
provision for the user to specify the number of web services in
which his request has to be processed. For example if the user
requests that his request has to be processed by “n” web
services the QoS broker executes the request on top “n” web
services which are selected based on the QoS parameters. The
results are displayed to the user in a single page. This
particular case is important for a user who wants to carry out
his request in more that one web service and compare his
results. Without a gateway, a user has to typically run his
request on multiple interfaces obtain his results in distinct
pages and should compare them. The retrieval of this result
for future usage is also made easy in our system by giving a
single result ID.
Implementation:
Web service clients have to be created for web services, in
order to use them. WSDL [references] is an XML based
language used to describe the public interface of the web
service. Every web service publishes a WSDL document and a
client implementation should use this WSDL file to know
server details and functions. Axis2 Client API provided by
apache and Netbeans web service tool provided by Sub were
used in the creation of the web service clients. Eclipse IDE
was used to build client programs that used Axis2 Client API.
Java Server Pages (JSP) was used to develop the front-end
interface of the web service clients. Web engines Apache
Tomcat 6.5 was used to deploy JSP files generated in eclipse
IDE and Glassfish server V2 was used deploy JSP files
generated using Netbeans.
Technical Diagram
MySQL database and interaction with the application server
Experiment:
Classes of web services.
DATa
Graphs
Btw web services
How often the optimal web service changed.
Conclusion:
B. Title and Author Details
Title must be in 24 pt Regular font. Author name must be
in 11 pt Regular font. Author affiliation must be in 10 pt
Italic. Email address must be in 9 pt Courier Regular font.
TABLE I
FONT SIZES FOR PAPERS
 Font Appearance (in Time New Roman or Times) Graphics may be full color. All colors will be retained on
Size Regular Bold Italic the CDROM. Graphics must not use stipple fill patterns
8 table caption (in reference item because they may not be reproduced properly. Please use
Small Caps), (partial) only SOLID FILL colors which contrast well both on screen
figure caption, and on a black-and-white hardcopy, as shown in Fig. 1.
reference item
9 author email address abstract abstract heading
(in Courier), body (also in Bold)
cell in a table
10 level-1 heading (in level-2 heading,
Small Caps), level-3 heading,
paragraph author affiliation
11 author name
24 title

All title and author details must be in single-column format

and must be centered.
Every word in a title must be capitalized except for short
minor words such as “a”, “an”, “and”, “as”, “at”, “by”, “for”,
“from”, “if”, “in”, “into”, “on”, “or”, “of”, “the”, “to”, “with”.
Author details must not show any professional title (e.g.
Managing Director), any academic title (e.g. Dr.) or any
membership of any professional organization (e.g. Senior
Member IEEE).
To avoid confusion, the family name must be written as the
last part of each author name (e.g. John A.K. Smith).
Each affiliation must include, at the very least, the name of
the company and the name of the country where the author is
based (e.g. Causal Productions Pty Ltd, Australia).
Email address is compulsory for the corresponding author.
C. Section Headings
No more than 3 levels of headings should be used. All
headings must be in 10pt font. Every word in a heading must
be capitalized except for short minor words as listed in
Section III-B.
1) Level-1 Heading: A level-1 heading must be in Small
Caps, centered and numbered using uppercase Roman
numerals. For example, see heading “III. Page Style” of this
document. The two level-1 headings which must not be
numbered are “Acknowledgment” and “References”.
Fig. 1 A sample line graph using colors which contrast well both on screen
and on a black-and-white hardcopy
Fig. 2 shows an example of a low-resolution image which
would not be acceptable, whereas Fig. 3 shows an example of
an image with adequate resolution. Check that the resolution
is adequate to reveal the important detail in the figure.
Please check all figures in your paper both on screen and on
a black-and-white hardcopy. When you check your paper on
a black-and-white hardcopy, please ensure that:
• the colors used in each figure contrast well,
• the image used in each figure is clear,
• all text labels in each figure are legible.
E. Figure Captions
Figures must be numbered using Arabic numerals. Figure
captions must be in 8 pt Regular font. Captions of a single
line (e.g. Fig. 2) must be centered whereas multi-line captions
must be justified (e.g. Fig. 1). Captions with figure numbers
must be placed after their associated figures, as shown in
Fig. 1.

2) Level-2 Heading: A level-2 heading must be in Italic,

left-justified and numbered using an uppercase alphabetic
letter followed by a period. For example, see heading “C.
Section Headings” above.
3) Level-3 Heading: A level-3 heading must be indented,
in Italic and numbered with an Arabic numeral followed by a
right parenthesis. The level-3 heading must end with a colon.
The body of the level-3 section immediately follows the level-
3 heading in the same paragraph. For example, this paragraph
begins with a level-3 heading.
D. Figures and Tables
Figures and tables must be centered in the column. Large
figures and tables may span across both columns. Any table
or figure that takes up more than 1 column width must be
positioned either at the top or at the bottom of the page. Fig. 2 Example of an unacceptable low-resolution image

Fig. 3 Example of an image with acceptable resolution
F. Table Captions
Tables must be numbered using uppercase Roman
numerals. Table captions must be centred and in 8 pt Regular
font with Small Caps. Every word in a table caption must be
capitalized except for short minor words as listed in Section
III-B. Captions with table numbers must be placed before
their associated tables, as shown in Table 1.
G. Page Numbers, Headers and Footers
Page numbers, headers and footers must not be used.
H. Links and Bookmarks
All hypertext links and section bookmarks will be removed
from papers during the processing of papers for publication.
If you need to refer to an Internet email address or URL in
your paper, you must type out the address or URL fully in
Regular font.
I. References
The heading of the References section must not be
numbered. All reference items must be in 8 pt font. Please
use Regular and Italic styles to distinguish different fields as
shown in the References section. Number the reference items
consecutively in square brackets (e.g. [1]).
When referring to a reference item, please simply use the
reference number, as in [2]. Do not use “Ref. [3]” or
“Reference [3]” except at the beginning of a sentence, e.g.
“Reference [3] shows …”. Multiple references are each
numbered with separate brackets (e.g. [2], [3], [4]–[6]).
Examples of reference items of different categories shown
in the References section include:
• example of a book in [1]
• example of a book in a series in [2]
• example of a journal article in [3]
• example of a conference paper in [4]
• example of a patent in [5]
• example of a website in [6]
• example of a web page in [7]
• example of a databook as a manual in [8]
• example of a datasheet in [9]
• example of a master’s thesis in [10]
• example of a technical report in [11]
• example of a standard in [12]
II. CONCLUSIONS
The version of this template is V2. Most of the formatting
instructions in this document have been compiled by Causal
Productions from the IEEE LaTeX style files. Causal
Productions offers both A4 templates and US Letter templates
for LaTeX and Microsoft Word. The LaTeX templates
depend on the official IEEEtran.cls and IEEEtran.bst files,
whereas the Microsoft Word templates are self-contained.
Causal Productions has used its best efforts to ensure that the
templates have the same appearance.
Causal Productions permits the distribution and revision of
these templates on the condition that Causal Productions is
credited in the revised template as follows: “original version
of this template was provided by courtesy of Causal
Productions (www.causalproductions.com)”.
ACKNOWLEDGMENT
The heading of the Acknowledgment section and the
References section must not be numbered.
Causal Productions wishes to acknowledge Michael Shell
and other contributors for developing and maintaining the
IEEE LaTeX style files which have been used in the
preparation of this template. To see the list of contributors,
please refer to the top of file IEEETran.cls in the IEEE LaTeX
distribution.
REFERENCES
[1] W3c schools
[2] http://www.ibm.com/developerworks/library/ws-quality.html
[3] A Concept for QoS Integration in Web Services [13] A probabilistic approach to modeling and estimating the QoS
[http://neptune.netcomp.monash.edu.au/cpe5014/doc/QoSWS2003.pdf of web-services-based workflows
] [14] A Client Perceived QoS Model for Web Services Selection
[4] Design and Implementation of Web Services QoS Broker [15] Web Services Essentials
[5] http://www.embraceregistry.net/ [16] QoS awareness support in Web-Service semantics
[6] The Design of QoS Broker Algorithms for QoS-Capable Web Services [17]
[7] A QoS broker based architecture for efficient web services selection [18]
[8] The Design of QoS Broker Algorithms for QoS-Capable Web Services [19]
[9] A Concept for QoS Integration in Web Services [20]
[10] QoS Computation and Policing in Dynamic Web Service Selection [21]
[11] QoS Aspects in Web Services Compositions [22] ****************************************************
[12] A QoS Broker Based Architecture for Dynamic Web Service Selection