Understanding Web Services

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?#section2

Web services 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 data 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 authentication 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 stunningly 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 another 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 many 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 should 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 standards, 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 the 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 enough 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: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 country) 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:encoding
 xmlns:m="http://www.somesite.com/Postcode">
<Valid>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#section3

Even with 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  (UDDI) 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 registering 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 works

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 registration 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 to 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 services) 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 service 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 meeting, 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 makes 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 exist 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

Developers 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 planned 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?”  Sadly, 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 access 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.