Web Services

							Web Services


Web Services (http://www.w3.org/ws) is an integration technology. According to the
World Wide Wed Consortium (W3C), a Web service is defined as a software system
designed to support interoperable machine-to-machine interaction over a network.

In contrast to the access to web information by humans interacting with the web via a
web browser (Internet Explorer, Firefox etc), Web Service technology is aimed at
satisfying the need for systematic or programmatic access to web information by
software systems. These systems typically exchange data in structured forms such as
XML, rather than human-readable HTML typically seen in web pages.

Resources on a network made available as independent services which can be
accessed without knowledge of their underlying implementation are said to follow a
Service-Oriented Architecture (SOA). A SOA environment is usually based on Web
Services, which have now gained industry acceptance, and so adoption of SOA will
enable a independent resource, such as a database, to interoperate with other resources
on the web through standard mechanisms..

To ensure software from various sources work well together, this technology is built
on open standards such as:
   - SOAP, Simple Object Access Protocol, a messaging protocol for transporting
       information;
   - WSDL, Web Services Description Language, a standard method of describing
       Web Services and their capabilities, and
   - UDDI, Universal Description, Discovery, and Integration, a platform-
       independent, XML-based registry for services.
These are described further below.



Although everyone knows roughly what a "web service" is, there is no universally
accepted definition. Despite the difficulty of defining Web Services precisely, it is
generally accepted that a web service is a Service-Oriented Architecture (SOA) with
at least the following constraints:

-      Interfaces must be based on Internet protocols, eg HTTP, FTP, and SMTP.
-      Except for binary data attachment, messages must be in XML.


There are two main styles of Web services: SOAP and REST.

SOAP Web Services
A SOAP web service introduces the following constraints:

-      Except for binary data attachment, messages must be carried by SOAP.
-      The description of a service must be in WSDL.
A SOAP Web Service is the most common and marketed form of web service in the
industry. Some people simply collapse "web service" into SOAP and WSDL services.
SOAP provides a message construct that can be exchanged over a variety of
underlying protocols. SOAP acts like an envelope that carries its contents. One
advantage of SOAP is that it allows rich message exchange patterns ranging from
traditional request-and-response to broadcasting and sophisticated message
correlations. There are two flavours of SOAP web services, SOAP RPC and
document-centric SOAP web service. SOAP RPC web services are not SOA;
document-centric SOAP web services are SOA.

SOAP (http://www.w3.org/TR/soap), is a protocol for exchanging XML-based
messages over a computer network, normally using HTTP. SOAP forms the
foundation layer of the web services stack, providing a basic messaging framework
that more abstract layers can build on.

A SOAP message is contained in an envelope. Within this envelope are two additional
sections: the header and the body of the message. SOAP messages use XML
namespaces.

Code 1 is an example of how a client might format a SOAP message requesting a
database entry from EBI WSDbfetch web service. The user wants to retrieve the
EMBL record with the accession number J00021, in XML format.

<soap:Envelope xmlns:soap =”http://
schemas.xmlsoap.org/soap/envelope/”>
<soap:Body>
<fetchData xmlns=”http://www.
ebi.ac.uk/webservices”>
<query>embl:J00021</query>
<format>embl</format>
<style>xml</style>
</fetchData>
</soap:Body>
</soap:Envelope>

Code 1. SOAP message example.


The header contains relevant information about the message. For example, a header
can contain the date the message is sent, or authentication information, addressing,
etc.
Figure 1. SOAP message structure.


WSDL: Web Services Description Language

The Web Services Description Language (WSDL) is an XML format published for
describing Web services.

WSDL describes the public interface to the Web Service; namely the protocol
bindings and message formats required to interact with the Web Services listed in its
directory. The supported operations and messages are described abstractly, and then
bound to a concrete network protocol and message format.

A client (program) connecting to a Web Service can read the WSDL to determine
what functions are available on the server. Any special data types used are embedded
in the WSDL file in the form of an XML Schema. The client can then use SOAP to
actually call one of the functions listed in the WSDL.

For more information on WSDL, please refer to the W3C WSDL v1.1 Document
(http://www.w3.org/TR/wsdl).
                  SOAP, WSDL and UDDI interaction scheme


UDDI: Universal Description, Discovery, and Integration

The Universal Description, Discovery, and Integration is a platform-independent,
XML-based registry for services worldwide to list themselves on the Internet. It is
designed to be interrogated by SOAP messages and to provide access to WSDL
documents describing the protocol bindings and message formats required to interact
with the web services listed in its directory.




SOAP RPC Web Services
A SOAP RPC Web Service breaks the second constraint required by an SOA. A
SOAP RPC Web service encodes RPC (remote procedure calls) in SOAP messages.
In other words, SOAP RPC "tunnels" new application-specific RPC interfaces though
an underlying generic interface. Effectively, it prescribes both system behaviours and
application semantics. Because system behaviours are very difficult to prescribe in a
distributed environment, applications created with SOAP RPC are not interoperable
by nature. Many real life implementations have confirmed this.

Faced with this difficulty, SOAP 1.2 has made the support of RPC optional. RPC also
tends to be instructive rather than descriptive, which is against the spirit of SOA.
REST Web Services
The term REST (Representational State Transfer) was first introduced by Roy
Fielding to describe the web architecture. A REST Web Service is an SOA based on
the concept of "resource". A resource is anything that has a URI. A resource may
have zero or more representations. Usually, people say that a resource does not exist if
no representation is available for that resource. A REST Web Service requires the
following additional constraints:

   1. Interfaces are limited to HTTP. The following semantics are defined:
          o HTTP GET is used for obtaining a representation of a resource. A
              consumer uses it to retrieve a representation from a URI. Services
              provided through this interface must not incur any obligation from
              consumers.
          o HTTP DELETE is used for removing representations of a resource.
          o HTTP POST is used for updating or creating the representations of a
              resource.
          o HTTP PUT is used for creating representations of a resource.
   2. Most messages are in XML, confined by a schema written in a schema
      language such as XML Schema from W3C or RELAX NG.
   3. Simple messages can be encoded with URL encoding.
   4. Service and service providers must be resources while a consumer can be a
      resource.

REST Web Services require little infrastructure support apart from standard HTTP
and XML processing technologies, which are now well supported by most
programming languages and platforms. REST Web Services are simple and effective
because HTTP is the most widely available interface, and it is good enough for most
applications. In many cases, the simplicity of HTTP simply outweighs the complexity
of introducing an additional transport layer.



A Case Study: Web Services at European Bioinformatics Institute (EBI)

Today, biological databases comprise large collections of data that are relatively
difficult to maintain outside the centres and institutions that produce them. The EBI
provides access to more than 200 such databases and to about 150 bioinformatics
applications. These data and tools are mainly accessed using browser-based World
Wide Web interfaces.

When large amounts of data need to be retrieved and analysed, this often proves to be
tedious and impractical. EBI also provides other mechanisms such as email batch job
submissions, but this method lacks the interactivity of the web interfaces. Moreover,
research is rarely completed just by retrieving or analyzing a particular nucleotide or
protein sequence. Database information retrieval and analysis services have to be
linked, so that, for example, search results from one database can be used as the base
of a search in another, the results of which are then analyzed. When performing these
operations using a Web browser, researchers are forced to repeat the troublesome
tasks of searching, copying the results for subsequent searches to other databases, and
again copy the results for analysis. Creating a local bioinformatics work environment
is possible by downloading and installing the necessary database content and services
(such as retrieval and analysis programs). This has the advantage that processes that
otherwise require manual operations can be automated. However, the amount of disk
space required to store biological sequence databases can be huge, often exceeding
several terabytes, requiring several hours, if not days, to complete analysis, even when
using a supercomputer. For this reason, creation of a local system is not a suitable
option for most individual researchers or institutions.

On the basis of these observations, the EBI has chosen to use the Web Services
technology to expose its services in a programmatically accessible manner. Web
Services technology enables scientists to access EBI data and analysis applications as
if they were installed on their laboratory computers. Similarly, it enables
programmers to build complex applications without the need to install and maintain
the databases and analysis tools and without having to take on the financial overheads
that accompany these. Moreover, Web Services provide easier integration and
interoperability between bioinformatics applications and the data they require. All that
is required at the user side is a lightweight program that communicates with the
servers running at the EBI. These services have several advantages. As traditional
web browsers cannot be used programmatically, these services provide an easy and
flexible way to deal with repetitive tasks such as bulk submission with minimal
intervention from the user. Web Services clients allow the programmer as well as the
service provider to integrate and build more complex analysis workflows using
existing EBI services.

We have implemented our services using SOAP and HTTP using Apache Axis (http://
ws.apache.org/axis/) for Java based development and SOAP::Lite (http://www.
soaplite.com) for Perl based development. Both of these software packages are open
source. Details of other platforms for delivery of Web Services can be seen in
Wikipedia at http://en.wikipedia.org/wiki/Web_services#Platforms_.26_Tools

Further details of EBI Web Services are available at:
www.ebi.ac.uk/Tools/webservices



References

XML. Wikipedia. http://en.wikipedia.org/wiki/XML

XML. O’Reilly xml.com. http://www.xml.com/

XML Schema. W3C Web Architecture Domain. http://www.w3.org/XML/Schema

Web Services. Wikipedia. http://en.wikipedia.org/wiki/Web_services

Web Services. W3C Web Architecture Domain. http://www.w3.org/2002/ws/

Web Services. O’Reilly webservices.xml.com. http://webservices.xml.com/
SOAP. W3C XML Protocol Working Group. http://www.w3.org/2000/xp/Group/

SOAP 1.2 Primer. W3C. http://www.w3.org/TR/soap12-part0/

SOAP. Wikipedia. http://en.wikipedia.org/wiki/SOAP

REST. Wikiopedia. http://en.wikipedia.org/wiki/REST

REST and the Real World. http://www.xml.com/pub/a/ws/2002/02/20/rest.html

REST. Fielding, R.T. Thesis (2000). University of California, Irving.
http://www1.ics.uci.edu/%7Efielding/pubs/dissertation/rest_arch_style.htm

UDDI. Wikipedia. http://en.wikipedia.org/wiki/UDDI

WSDL. W3C Web Architecture Domain. http://www.w3.org/TR/wsdl20/

WSDL. Wikipedia. http://en.wikipedia.org/wiki/WSDL

Labarga, A. et al. Web services at EBI EMBnet.news, 11(4) 18-23 (2005)
http://www.embnet.org/download/embnetnews/embnet_news11_4-high.pdf

Pillai S., Silventoinen V., Kallio K., Senger M., Sobhany S., Tate J., Velankar S.,
Golovin A., Henrick K., Rice P., Stoehr P., Lopez R.
SOAP-based services provided by the European Bioinformatics Institute.
Nucleic Acids Res. 33(1):W25-W28 (2005).
http://nar.oxfordjournals.org/cgi/content/abstract/33/suppl_2/W25