SOAP Web Services

balecomputerΑσφάλεια

3 Νοε 2013 (πριν από 3 χρόνια και 9 μήνες)

89 εμφανίσεις

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 networ
k.


In contrast

to
the
access to web information
by

humans interacting with the web via a
web browser (In
ternet Explorer, Firefox etc), W
eb

S
ervice technology is aimed at
satisfying the
need for
systematic or programmatic access to web information by
soft
ware 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 thei
r underlying implementation are said to follow a
Service
-
Oriented Architecture (SOA). A SOA environment
is usually based on Web
S
ervices
,

which have
now
gained industry acceptance, and so adoption of SOA will
enable a independent resource, such as a databa
se, 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
.

T
hese are described further below.


Although everyone knows roughly what a "web service" is, there is no universally
accepted definition. Desp
ite the difficulty of defining Web S
ervices

precisely
, it is
generally accepted that a web service
is a Service
-
Ori
ented 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

R
EST.

SOAP Web S
ervices

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 S
ervice is the most common and marketed form o
f web service in the
industry. Some people simply collapse "web service" into SOAP an
d 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 flavo
u
rs of SOAP web services, SOAP RPC and
document
-
centric SOAP web ser
vice
. 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
name
spaces.


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 re
trieve 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.



T
he 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


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


WSDL describ
es the public interface to the Web S
ervice; namely the protocol
bindings and message formats required to interact with
the Web S
ervices listed

in its
directory. The supported operations and messages are described abstractly, and then
bound to a concrete network protocol and message format.


A cl
ient (program) connecting to a Web S
ervice 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 UD
DI 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 W
eb

S
ervice breaks the sec
ond 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 b
oth system behavio
u
rs and
application semantics. Because system behavio
u
rs 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 introduc
ed by Roy
Fielding to describ
e the web architecture. A REST Web S
ervice 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 exis
t if
no representation is avail
able for that resource. A REST Web S
ervice 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
c
onsumer 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 encod
ing.

4.

Service and service providers must be resources while a consumer can be a
resource.

REST Web S
ervices require little infrastructure support apart from standard HTTP
and XML processing technologies, which are now well supported by most
programming

lang
uages and platforms. REST Web S
ervices 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 additi
onal transport layer.



A
Case Study: W
eb

S
ervices a
t
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 bioinformatic
s

applications. These data and tools are mainly accessed using browser
-
b
ased World
Wide Web interfaces.


When large amounts of data need to be retrieved and analysed, thi
s 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 pa
rticular 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 bioinformat
ics 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 syste
m is not a suitable
option for most individu
al researchers or institutions.


On the basis of these observations, the EBI has chosen to use the Web Services
techn
ology to expose its services

in a progra
mmatically accessible manner
. Web
Services technology e
nables 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 tool
s 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 l
ightweight 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 suc
h 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 us
ing 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 W
eb Ser
vices 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


Reference
s

XML.
Wi
kipedia.

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/Sche
ma

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.o
rg/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

WS
DL. 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 provid
ed by the European Bioinformatics Institute.

Nucleic Acids Res.

33(1):W25
-
W28 (2005
).

http://nar.oxfordjournals.org/cgi/content/abstract/33/suppl_2/W25