What is a Web Service?
Web services are a standardized way for two computer systems to communicate leveraging XML (Extensible Markup Language) and Internet communications protocols. Web services allow systems to send and receive formatted messages despite their location, software platform or even programming language.
Web Services was championed by Microsoft Corporation’s dream of a Service Oriented Architecture (SOA). The goal is to deploy service registries, which essentially work like a database in that you can query and locate services, then direct your system to use them however you like. Software companies such as Microsoft aim to publish their products as subscription services, running on a remote platform, allowing them control for software updates and anti-piracy protection. This has yet to completely take off, but more businesses are exploring the possibilities available given these technological triumphs.
Web Services has been adopted by more organizations, and their use varies as much as the systems that publish and use them. This article will explain how web services work and serve as a primer to future technical articles on how to write, publish and use your own web services.
Who’s Using Them?
The userbase for web services varies, however most commercial uses are between trading partners primarily in the telecommunications industry. More deployments for web services are occurring each day that we may never know about. Some popular web services are those published by Amazon, Google, Yahoo and eBay. These vary from book searches, web searches, map queries and even product searches. Developers are finding ways to create their own commercial solution, sometimes by building a solution that integrates many web services together. This is commonly referred to as “mashing” and entirely new companies have formed as a result.
Methods of Web Service Implementations
For decades, business systems have needed the ability to send/receive information to other systems and there are limitless ways to accomplish this. These all could be considered “web services” in their own right. This information exchange could be a manual process, such as transferring files from one computer to another, either via floppy disk, FTP or even EDI (Electronic Data Interchange). The uses can vary from backing up information, synchronizing information, validating information or merely processing and returning some needed result data.
As the technologies have matured, two primary methods for publishing/subscribing to web services have emerged, SOAP RPC (Simple Object Access Protocol - Remote Procedure Call) and REST (Representational State Transfer). Both methods have pros/cons, yet the SOAP RPC method offers more control for specific uses. Both of them leverage HTTP (Hypertext Transfer Protocol) which is the communications protocol used by web browsers and web servers, publishing web pages. Given that most corporate firewalls allow access via this protocol, it makes the communication possible regardless of where and what makes up a remote system.
SOAP RPC
SOAP RPC ombined make up the communication method (RPC) and message format (SOAP) that allow two systems to interact. SOAP messages are XML documents that adhere to a strict definition, and create what is called an envelope, complete with header and message body. This envelope defines what is in the message, who should deal with it and whether it is optional or mandatory.
IBM
To implement a SOAP RPC solution, you will likely use toolsets provided by your software platform provider, simplifying the tasks of generating formatted messages and parsing/consuming them. Of course you could write a program to manually generate your message, and sent it to a remote system via HTTP post, then parsing the response message manually. There are many free tools and APIs available which eliminate the need for this, however depending on the level of control you want, it may be the best option.
REST
REST implementation of a web service allows commands to be sent via an encoded URI, just like a web page address with variables attached, and returns an XML document whose format is defined by the web service descriptor, or WSDL file.
Example URI:
http://webservice/?operation=doSomething&key=12345&query=dogs
REST has been reported as the most popular method of implementing web services by developers. This information, provided by service providers such as Amazon (85% REST to 15% SOAP RPC), is likely skewed given their free web services and tutorials are being used as a primer for developers to learn web services. Given most online resources direct people to create a free account and write their first client using Amazon, they undoubtably choose the easiest possible method to learn on, before venturing off and building their own.
In it’s simplest form, a REST implementation could consist of an HTTP call to a URI, executing some operation or sending some data. The host application will have to translate the information in the URI (?operation=doSomething&key=12345&query=dogs) to determine what action is required, whether it is available and/or authorized and whether any information must be sent in return. There are some rules on minimum requirements for response messages, but again these are merely guidelines and how two systems interact is ultimately up to the owners of those two systems and how they agree to work together.
Summary
This article’s purpose is to merely give a primer to web services, and the two primary methods of publishing/subscribing to them. For a more technical description, please view one of our “how to” articles.
