Understanding Web Services

wrackbaaΚινητά – Ασύρματες Τεχνολογίες

10 Δεκ 2013 (πριν από 3 χρόνια και 8 μήνες)

58 εμφανίσεις

Understanding Web Services

by
PATRICK COONEY


The web services concept being championed by computing giants like Sun, Oracle, HP
, Microsoft, and IBM
doesn’t contain many new ideas, but it is a great step towards simple access to software over the network.
By promoting standards

based communication, web services might change the way we build websites.

What is a web service?

Web serv
ices make software functionality available over the Internet so that programs like PHP, ASP, JSP,
JavaBeans, the COM object, and all our other favorite widgets can make a request to a program running on
another server (a web service) and use that program’s

response in a website, WAP service, or other
application.

So when I need to get some programming task done, and am too busy (or not crazy enough) to attempt it
myself, I can make use of a web service by calling it over the Internet. By passing parameter d
ata with the
request, I can expect to receive a response containing the result generated by the web service.

Anyone who has used
Hotmail

recently has had a brush with web services: the passport aut
hentication
system is one of the web services in Microsoft’s .NET initiative, and is available without charge for the
moment, so developers can use passport authentication within their own sites.

THE BASICS

The principles behind web services are stunningl
y simple, and are nothing new in the world of distributed
computing and the Internet:



the web service provider defines a format for requests for its service and the response the service
will generate



a computer makes a request for the web services across
the network



the web service performs some action, and sends the response back

This action might be retrieving a stock quote, finding the best price for a particular product on the net,
saving a new meeting to a calendar, translating a passage of text to a
nother language, or validating a credit
card number.

STANDARDS SUPPORT

The reason that we should be suddenly interested in the services model is the incorporation of standard,
open protocols for calling services and transmitting data.

While in the past ma
ny data and service providers have had proprietary standards or rough

and

ready data
formats, we can now rely on simple
eXtensible Markup Language

(XML) based access over plain old HTTP. This
means easier access and shou
ld let developers working with all sorts of technologies start playing the web
services game.

The difference between web services and technologies developers have used in the past like DCOM, named
pipes, and RMI, is that most web services rely on open stan
dards, are relatively easy to command, and have
widespread support across the Unix / Windows divide.

The
Simple Object Access Protocol

(SOAP) is a
W3C

standard protocol that defines t
he format for web service
requests.

SOAP messages are sent back and forth between the service provider and service user in SOAP envelopes,
containing a request for some action and the result of that action. SOAP envelopes are XML formatted, and
are easy en
ough to decode. This is a simple SOAP request, which could be sent via an HTTP request to a
web service:

<env:Envelope

xmlns:env="http://www.w3.org/2001/06/soap
-
envelope">

<env:Body>


<m:ValidatePostcode


env:encodingStyle="http://www.w3.org/2001/06/soa
p
-
encoding"


xmlns:m="http://www.somesite.com/Postcode">


<Postcode>WC1A8GH</Postcode>


<Country>UK</Country>


</m:ValidatePostcode>

</env:Body>

</env:Envelope>

The key elements of our SOAP envelope are easy to recognize: two parameters (postcode and cou
ntry) are
contained within an element named ValidatePostcode, which happens to be the name of the web service we
are calling. Other data within the envelope, like the text encoding and SOAP version, helps the web service
process the request.

A response to
this request might look like this:

<env:Envelope

xmlns:env="http://www.w3.org/2001/06/soap
-
envelope" >

<env:Body>


<m:ValidatePostcodeResponse


env:encodingStyle="http://www.w3.org/2001/06/soap
-
encoding"


xmlns:m="http://www.somesite.com/Postcode">

<Val
id>Yes</Valid>


</m:ValidatePostcodeResponse>

</env:Body>

</env:Envelope>

This message is even simpler to interpret. The ValidatePostcode element in our request has been answered
by a ValidatePostcodeResponse element in this SOAP message, which contains
a single element, Valid,
indicating whether or not our postal code was okay. Thus through the magic of SOAP we can construct a
request to get some work done, and have a consistently formatted XML response returned across the
network.

NEVER SAY UDDI

Even w
ith a simple protocol like SOAP, web services wouldn’t be much good to us if we had no way of
finding them. Luckily IBM, Microsoft, and Ariba stepped in and started the
Universal Description, Discovery and
Integration

(UD
DI) project, which they hope will be the definitive directory to services over the web.

The UDDI allows companies to offer their web services to other companies by acting like a telephone book
for web services. There are no costs associated with registerin
g your web service in the UDDI, and the
founders hope it will provide a central reference listing all the services residing across the net, so that
developers looking for a service can simply use the UDDI to locate the most appropriate provider.

How it wor
ks

So when would I use a web service?

Let’s imagine I’m a developer and I have been asked to provide a new feature on my company’s website: I
have to include a postal code validation facility to check that postal codes are correct as customers submit a
re
gistration form.

The validation will have to check postal codes for all 30 countries where we do business, and it should also
check if the city entry corresponds to the postal code. I don’t have this data, and I suspect it will cost me
some serious money t
o get it.

Rather than buy the data, write the code myself, maintain the data and tune performance of my code, I am
going to investigate the UDDI and see if anyone provides a web service that does this sort of work.
Navigating to
www.uddi.org
, I perform a search and find the perfect service from XYZ Corp.

I prudently examine the web service definition (written in the
Web Services Description Language
, an XML syntax
for defining web se
rvices) so I am certain the web service does what I need. I then check with my industry
buddies that XYZ Corp is solid, and get in touch with XYZ to talk dollars. After finding the pricing within my
budget, I write some hasty code that calls the XYZ servic
e from my JSP page, and voila, instant postal code
validation.

WORTH YOUR TIME

Even if you are not involved in any of the coding or architecture associated with site development, web
services are still worth knowing about. Picture yourself in a client mee
ting, discussing the features of their
new project. Everything is going brilliantly: the budget and expectations are in line, they like the site map,
they like the interface samples. It all works.

Then they mention they want a monster feature added that ma
kes your web developer sitting across the
table grow pale and make furious choking noises. This is the developer’s signal that this feature is way too
expensive to develop/not possible in ASP/too painful to consider.

Fear not! Web services might already ex
ist that provide the functionality you need, and the cost of using
them will probably never get close to the cost of developing them yourself. Save your developer pain and
your client some money by doing some research on the UDDI.

SERVICE DEVELOPMENT

Deve
lopers don’t have to content themselves with employing web services other people have created. Using
one of the new development frameworks, we can use built in SOAP and XML tools to create services of our
own, and then make them available for others to use
.

Developers have plenty options for developing web services. As well as offerings from companies like
Sun

(Open Net),
Microsoft

(.NET),
HP

(e
-
services), and
IBM

(Web Services), there is an open source project aimed
at providing a complete framework for service development. The
Mono Project

aims to replace the .NET
development project by providing a runtime, compilers and libraries for development on Unix and other
platforms.

Despite the proliferation of web service development tools and servers, common support or plan
ned support
for SOAP, XML and UDDI bode well for interoperability and consistency.

CAVEATS

So before I hang up my coding hat forever and content myself with using web services wherever possible, I
must ask myself , “What’s wrong with this rosy picture?” S
adly, all the great potential of the web services
concept comes at some costs:



The use of XML as a transfer format means our messages are large: XML tags take up a lot of
space, and this places a burden on us to create and interpret, as well as transport,
our messages.



The use of remote computers to do our processing puts us at the mercy of the Internet, and creates
many potential points of failure between our web server and our web service.



Few companies currently provide web services, and few companies
use them. It will take time for
web services to proliferate and be tested properly by the developer community.



Licensing and charging models for web services must be acceptable for developers. With so few web
services out there, and most companies trying
hard to make a good impression by keeping cost low
and terms reasonable, it might be a while before the cost of services becomes clear.

Once they are in place and are affordable, web services may prove a great asset to site developers, and give
us all acce
ss to a world of computing power and flexibility. It’s time for people who build websites to start
experimenting with web services and find out what they can offer.