Understanding Web Services
Chances are by now you've heard the term "Web Services" and been baffled by the onslaught of associated acronyms.
You may also have heard, depending on the level of hype driving whatever channel you receive your information from, that they're a revolutionary way to do business on the internet; the end of software as we know it; and nothing less than a total paradigm shift representing what will go down in history as the single-greatest technology impact on eBusiness the world has ever seen...
Ok, hype. Great. But what are Web Services, really? Are they all they're cracked up to be? Are they really that revolutionary? And most importantly, what do you need to know from a technical standpoint in order to understand if and how they'll impact your business?
This Coffee Talk is intended to provide you with an easy-to-understand introduction to the world of Web Services. We'll describe the basic components of the Web Services model, highlight some evolving issues which will undoubtably impact the future of Web Services, and give you some pointers to other resources where you can further your knowledge.
Web Services in 25 Words or Less
Simply put, Web Services are self-describing, modular software components made available to other applications using public networks, standardized languages, and transported via commonly available internet technologies.
...And by the end of this article, you'll understand exactly what that definition means! Ready?
Self-describing, Modular Software Components
One helpful way to understand the concept and power of Web Services may be to first look no further than your desktop. Most of today's software applications require you to have tens or even hundreds of Megabytes available to install and run the program. Many of these software packages may provide you with functionality that you or your business simply do not need (animated paperclip, anyone?).
Yet, because this software comes packaged as a single application, you still pay for the all of the software's functionality, whether or not you actually need or use it.
Now think of a software application as simply an integrated set of individual sub-applications, each responsible for providing a specific set of functionalities. What if you could (to a degree) only pay for and have access to those sub-applications for which you actually have a business need? That, in an abstract sense, is what Web Services are all about: They are relatively small, specialized software code fragments that, depending on business needs, can be dynamically combined and integrated as a suite of functionalities that can solve a specific business problem.
Companies or individuals can create Web Services and make them available to others for use in their own applications. If someone had created an Application Help service, for example, we could conceivably decide not to install the paper clip and instead rely on the external Web Service to provide dynamic Help functionality.
The "self-describing" aspect of Web Services deals with how those individual software code fragments communicate with each other in order to be effectively integrated. By using WSDL (Web Services Description Language, an XML-based language), an individual Web Service describes itself in terms of what it can do, where it is located, how to invoke it (inputs), and what to expect in return (outputs).
If a number of different companies had created Application Help services, you could ask each individual service to describe itself and decide, based on the parameters you deem important, which particular Help service, or multiple services, to incorporate into your application.
Making Web Services Available to Others
Before you can use someone else's Web Service (or assemble a number of Web Services together to accomplish more complex business goals), you must be able to find them first. If you already know which Web Service you want to use (and the technical details of how to use it), then you're all set. However, another option is to search a directory of web services, commonly referred to as the UDDI (Universal Description, Discovery, and Integration) Registry.
The UDDI Registry is intended to be somewhat the Web Services version of Napster - a dynamic, publicly available collection of pointers to Web Services' WSDL files, all organized according to a number of different schemas (such as name, functional category, technical details, etc.). By accessing the UDDI (using a special query language) businesses and/or applications can search for and find Web Services that are relevant to the business problem being addressed.
Keep in mind, however, that the "Napster of Web Services" label is a bit of a misnomer. Issues such as data security, testing, reliability, accountability, and potential Web Service "versioning" problems (such as when a Web Service gets updated) indicate the need for a more controlled, Web-Service-as-an-extension-of-an-already-established-business-relationship type of environment than the Glory Days of free-for-all music downloads that defined the Napster Era.
Using Standardized Languages
Industry optimists soon expect the number of transmitted "I'm looking for a Web Service" requests (and the corresponding "Here's a listing of Web Services" responses) to be significant. In addition to these messages, however, there is also a need to accommodate an almost incalculable number of other data-related messages that get sent between individual Web Services and between Web Services and their integrating applications.
SOAP (Simple Object Access Protocol), which is also an XML-based language, is a lightweight messaging protocol designed to provide a uniform way of passing XML-encoded data in a platform-independent, distributed, and decentralized environment. Essentially, SOAP is a way to "package" XML data such that any request and/or response is universally acceptable by the receiving party - be it the UDDI registry, another Web Service, or an integrating application.
The main benefit to using SOAP is that data messages can be transmitted between applications and Web Services without requiring any understanding of the original development language or network specifications for where that Web Service is located. Web Services can be created in just about any software language (Java, C++, Visual Basic, Perl, PHP, etc.) and accessed by just about any client - what matters is that the data inputs and outputs are XML-based and can be packaged via SOAP.
Transported Via Common Technologies
Once a request (or response) is packaged as a SOAP message, there needs to be a way to transport it to its destination. In theory, SOAP requests can be sent using just about any data transfer protocol (FTP, SMTP, Instant Messaging, etc.). The widespread adoption of the internet, however, makes HTTP (Hypertext Tranportation Protocol) the most logical choice - your web browser uses HTTP to send a request to a web server and the the HTTP daemon in the destination server machine receives the request and, after any necessary processing, returns the requested file.
(R)Evolutionizing Business
Today, most Web Services provide relatively simple functionality: stock quotes, weather bulletins, and currency exchange rates are the norm. However, it is not difficult to imagine more complex applications built using Web Services.
For example, a company's Travel Service could be intergrated with a Project Management System to automatically use Web Services to find and book flights, rental cars, and hotel rooms based on the dynamic scheduling of meetings. If the project involves international travel, we can automatically send off a request to the IT department for a power converter for laptops and the currency converter will help out when it's time to reconcile travel expense reports. And finally, the traveler can get real-time upates of all of the necessary travel information via his/her wireless device.
That's a tall order, to be sure, and it will be a while before we get to that level of interoperability. However, with many of the the proposed standards (described above) already in place, it's not unreasonable to imagine people already working towards such lofty goals. Web Services may enable revolutionary business processes, but it's based on evolutionary technologies.
The "Final" Word
Now that you actually have a basic understanding of the overall concept of Web Services, casually utter the following at your next office party and watch people clamor around you for enlightenment: "Web Services (developed in whatever programming language the author prefers) are described using WSDL, available for discovery in the UDDI registry, and use SOAP to package XML-based data using HTTP."
_______________________________
For more information on the technologies discussed in this Coffee Talk, please see the following:
WebServices.org
http://www.webservices.org/
How Web Services Came To Be - WebServicesArchitect
http://www.webservicesarchitect.com/content/articles/hart01.asp
XML.com Web Services Resource Center
http://www.xml.com/webservices/
IBM DeveloperWorks
http://www.ibm.com/developerworks/webservices/
Microsoft Developer Network
http://msdn.microsoft.com/webservices/
UDDI Project
http://www.uddi.org/