Web Services


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

133 εμφανίσεις

Raveendra N Landa


Class Notes




Web Services


A web service is a collection of protocols and standards used for exchanging data between applications
or systems. Software applications written in various programming languages and running on various
platforms can use web services
to exchange data over computer networks like the Internet in a manner
similar to inter
process communication on a single computer.

Web services are the fundamental building blocks in the move to distributed computing on the internet.
Open Standards and th
e focus on the communication and collaboration among people and applications
have created an environment where XML web services are becoming the platform for application
integration. Applications are constructed using multiple XML web services from variou
s sources that
work together regardless of where they reside or how they were implemented.

There are probably as
many definitions of XML web service
s as there are companies building them,
but almost all definitions have these things in common:

XML Web Se
rvices expose useful functionality to Web users through a standard web protocol.
In most cases, the protocol used is SOAP.

XML Web Services provide a way to describe their interfaces in enough detail to allow a user
to build a client application to talk to

them. This description is usually provided in an XML
document called a Web Services Description Langague (WSDL) document.

XML Web services are registered so that potential users can find them easily. This is done with
Universal Discovery Description and I
ntegration (UDDI).

One of the primary advantages of the XML Web Services architecture is that it allows programs
written in different languages on different platforms to communicate with each other in standards
based way.

The two widely used languages t
o write Web Services are C# and Java.

Salient Features of Web Services

Web services allow a server to expose a set of functions that other computers can then call

Web Services are
Platform and language independent.

The client and server applications ca
n both be written in any language that is capable of
packaging and parsing an XML document, and transmitting and receiving messages over a

Web Services

occurs over the HTTP protocol and hence they are fire wall

Raveendra N Landa


Class Notes






Today's applications communicate using Remote Procedure Calls (RPC) between objects like DCOM
and CORBA, but HTTP was not designed for this. RPC represents a compatibility and security
problem; firewalls and proxy servers will normally block this ki
nd of traffic.

A better way to communicate between applications is over HTTP using XML, because HTTP is
supported by all Internet browsers and servers and XML is a widely accepted technology for passing
information. SOAP was created to accomplish this.


codifies the use of XML as an encoding scheme for request and response parameters using
HTTP as a transport. SOAP deals in a small number of abstractions. In particular, a SOAP method is
simply an HTTP request and response that complies with the SOAP e
ncoding rules.

A SOAP endpoint is simply an HTTP
based URL that identifies a target for method invocation. Like
CORBA/IIOP, SOAP does not require that a specific object be tied to a given endpoint. Rather, it is up
to the implementer to decide how to map
the object endpoint identifier onto a server
side object.

A SOAP request is an HTTP POST request. SOAP requests must use the text/xml content
Additionally, they must contain a Request
URI as per the HTTP specification. How the server
interprets this

URI is implementation
specific, but many implementations are likely to use it
to map to either a class or an object. A SOAP request must also indicate the method to be invoked
using the SOAPMethodName HTTP header. The SOAPMethodName header is simp
ly the application
specific method name scoped by a URI using a # character as a delimeter:

SOAPMethodName: urn:strings

This header indicates that the method name is reverse and that the scoping URI is urn:strings
com:IString. The nam
espace URI that scopes the method name in SOAP is functionally equivalent to
the interface ID that scopes a method name in DCOM or IIOP.

The HTTP payload of a SOAP request is simply an XML document that contains the values of the [in]
and [in,out] paramet
ers of the method. These values are encoded as child elements of a distinguished
call element that shares the method name and namespace URI of the SOAPMethodName HTTP
header. The call element must appear inside the standard SOAP <Envelope> and <Body> eleme
(more on these later). The following illustrates a minimal SOAP method request:

POST /string_server/Object17 HTTP/1.1


Type: text/xml

Length: 152

SOAPMethodName: urn:strings

Raveendra N Landa


Class Notes






<m:reverse xmlns:m='urn:strings

<theString>Hello, World</theString>




The SOAPMethodName header must match the first child element under the <Body> element,
otherwise the call must be rejected. This allow
s firewall administrators to reliably filter calls to a
particular method without parsing the XML.

The SOAP response format is similar to that of the request. The response payload will contain the [out]
and [in,out] parameters of the method encoded as chi
ld elements of a distinguished response element.
This element's name is the same as the request's call element concatenated with the Response suffix.
The following is a minimal SOAP response to the request shown earlier:

200 OK

Type: text/xml

Length: 162



<m:reverseResponse xmlns:m='urn:strings

<result>dlroW ,olleH</result>




In this case, the response element is named reverseResponse, which is simply the met
hod name
followed by the Response suffix. Also, note that the SOAPMethodName HTTP header is absent. This
header is only required in the request message, not in the response.


WSDL (often pronounced whiz
dull) stands for Web Services Description Languag
e. A WSDL file is
an XML document that describes a set of SOAP messages and how the messages are exchanged. In
other words, WSDL is to SOAP what IDL is to CORBA or COM. Since WSDL is XML, it is readable
and editable but in most cases, it is generated and c
onsumed by software.

To see the value of WSDL, imagine you want to start calling a SOAP method provided by one of your
business partners. You could ask him for some sample SOAP messages and write your application to
produce and consume messages that look
like the samples, but this can be error
prone. For example,
you might see a customer ID of 2837 and assume it's an integer when in fact it's a string. WSDL
specifies what a request message must contain and what the response message will look like in
guous notation.

The notation that a WSDL file uses to describe message formats is based on the XML Schema
standard which means it is both programming
language neutral and standards
based which makes it
suitable for describing XML Web services interfaces th
at are accessible from a wide variety of
platforms and programming languages. In addition to describing message contents, WSDL defines
Raveendra N Landa


Class Notes




where the service is available and what communications protocol is used to talk to the service. This
means that the WSDL
file defines everything required to write a program to work with an XML Web
service. There are several tools available to read a WSDL file and generate the code required to
communicate with an XML Web service. Some of the most capable of these tools are in

Visual Studio® .NET.


Universal Discovery Description and Integration is the yellow pages of Web services. As with
traditional yellow pages, you can search for a company that offers the services you need, read about
the service offered and
contact someone for more information. You can, of course, offer a Web service
without registering it in UDDI, just as you can open a business in your basement and rely on word
mouth advertising but if you want to reach a significant market, you need UDD
I so your customers can
find you.

A UDDI directory entry is an XML file that describes a business and the services it offers. There are
three parts to an entry in the UDDI directory. The "white pages" describe the company offering the
service: name, addres
s, contacts, etc. The "yellow pages" include industrial categories based on
standard taxonomies such as the North American Industry Classification System and the Standard
Industrial Classification. The "green pages" describe the interface to the service in

enough detail for
someone to write an application to use the Web service. The way services are defined is through a
UDDI document called a Type Model or tModel. In many cases, the tModel contains a WSDL file that
describes a SOAP interface to an XML Web s
ervice, but the tModel is flexible enough to describe
almost any kind of service.

The UDDI directory also includes several ways to search for the services you need to build your
applications. For example, you can search for providers of a service in a spec
ified geographic location
or for business of a specified type. The UDDI directory will then supply information, contacts, links,
and technical data to allow you to evaluate which services meet your requirements.

Development products

Microsoft provides a f
ull set of products and tools to develop and deploy Web Services. Similarly
Apache provides a set of tools and products for the same purpose. The following table summarizes the
tools and products provided by Microsoft and Apache.



Web Se
rvice Product

.NET Frame Work

Tomcat 4.0.3

Web Service Authoring

Many including C, C++, C#,
Visual Basic.NET


Creation/Deployment tool

GUI or command based

Command Line

Platforms Supported

Windows NT4.0, 2000 or higher
, though you may
port to
other platforms on your own.

Most windows and Unix based

Raveendra N Landa


Class Notes




Document Descriptor

To deploy a web service using Tomcat, a document descriptor must be created, which is merely an
XML document with a few required tags

The id attribute of th
e service tag gives the name of the web service that is exposed to the client

The methods attribute of the provider tag, which is a child of the service tag, gives the name of the
methods that are exposed to the client

The class attribute of the java tag
, which is a child of the provider tag, gives the name of the class
that is exposed to the client

The mappings tag, which is a child of the service tag, provides mappings from Java objects to the
equivalent SOAP objects if SOAP does not already know how t
o convert the data type

All primitive Java data types, primitive arrays, and Strings are known by the Apache SOAP


Web Services provide a new method of distributed computing.

Using standard protocols, the theory behind web se
rvices makes it appear as if a client does not need to
concern itself with the platform running the web service.

Although this is somewhat true, the implementation of the SOAP protocol does need to be known, as
can be seen by the differences between the S
OAP messages that need to be received by the web
services, and the messages returned from the web services, on the different SOAP implementations.

When objects start being used, the protocol implementation becomes even more critical because those
object t
ypes must be defined on the server running the web service so that it knows how to decode the
object into the types SOAP is capable of understanding.

Web services will most likely become the next paradigm for distributed computing, overcoming the

dependency issues with RPC and COM.

However, if the different companies implementing the SOAP protocol do not conform to a standard,
web services will lose one of the key features underlying the technology: the ability for different
platforms and differe
nt languages to seamlessly integrate over a network.