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