Try to find an article on the Web that explains, in plain English, what a “Web Service” is and you’ll be going around in rhetorical circles with no simple explanation, and no examples. Most articles start out with some ambiguous explanation like: “Web services identified with WSDL and UDDI protocols make functionality available over the Internet using SOAP encapsulated in XML envelopes” and then the articles start spewing out programming code. Examples of programming code don’t help if you don’t have an overview of what a Web Service is.
David Berlind in his article “What are Web services anyway?” for ZDNet.com says, “At last fall’s Gartner Symposium I asked several attendees — presumably C-level technology executives — if they could give me a definition of Web services … No one knew. Before the session’s end, over half the attendees had left because they were expecting a discussion about something else.”
When you do find examples of Web Services, they are applications like; retrieving a stock quote, finding the best price for a product, saving an appointment to a calendar, or validating a credit card number. These are all things that we have been doing on the Web for years. So, what’s the big deal about Web Services?
Web services can be thought of as an evolution of the software components concept. For example, say you have several different word processors on your computer, or on your network. In the early days of software, each application needed to contain it’s own separate spell checking code. With components, the spell checking function is programmed into a separate module that can be shared by several different word processor programs. Every programmer doesn’t have to write their own spell checking code, they can license the use of a spell checking module from a components vender.
The same thing is possible over the internet using DCOM, CORBA, JavaBeans, etc. But these technologies were all created by different organizations. The components find it difficult to communicate with each other. It requires a lot of information sharing and pre-planning to make these components work together. “Web Services” is a set of vendor-neutral specifications and protocols developed by standards organizations such as OASIS and the W3C.
Using these standard protocols, Web sites can share Web applications in a manner similar to how a spell checking component can be shared between word processor programs. Every Web site does not have to write it’s own program code to retrieve a stock quote, find a best price, saving an appointment to a calendar, or validate a credit card number. They can license the use of these functions from Web Service providers.
From the human Web users point of view, the Web still appears to work the same. There is nothing new. That is why it’s so difficult to find a simple explanation of “Web Services”. The new technology of Web Services is what goes on under the hood. That’s why most articles about the subject jump right into the programming code. Many “Web Service” articles are just articles about XML.
The html code used by the Web today is inadequate for the Web services task. Html is great for formatting Web pages, but it tells you nothing about the data contained in the Web page. XML (eXtensible Markup Language) allows programmers to define their own tags to describe the data on a Web page, and communicate those definitions to the receiving system. XML is not binary computer code, similar to html, XML is just ASCII text.
When a Web site wants to use a Web Service, it makes a request in a standard format called SOAP (Simple Object Access Protocol). SOAP messages are written in XML. SOAP messages are sent back and forth between the service provider and service consumer. How does a programmer know what services are provided and what messages to use in accessing them? Web services use a standard message format called WSDL (Web Services Description Language) to describe themselves. WSDL is written in XML.
How does a developer find available Web Services? They can be found by using a protocol called UDDI (Universal Description, Discovery and Integration) to search a directory of services available. Web Service providers register their services in the directory. Developers can locate and select a provider for the service that meet their requirements. Similar to the licensing fees paid by the developer of the word processor for the spell checking component, web developers will have to pay for the use of Web Services.
Developers don’t have to use Web Services developed by other people. Microsoft’s .NET and Sun Microsystems’s J2EE are frameworks that contain resources and class libraries for developing Web Services. There are also a number of open source framework’s available, for example the Mono project hosted by the open Source software company Ximian. www.ximian.com/devzone/projects/mono.html
When you use a Web Service or a Web site that uses a Web Service, either licensed or directly, you will be required to pay, and you WILL use Web Services, because desktop applications will no longer be available. The former practice of paying one-time to use a software application as much as you want does not generate a continuous stream of revenue for software companies. Web Services allow the software companies to milk a continuous stream of money from you. Maybe that is the simple explanation of Web services that we can’t seem to find.
Stephen Bucaro
To learn how to maintain your computer and use it more effectively to design a Web site and make money on the Web visit bucarotechelp.com. To subscribe to Bucaro TecHelp Newsletter visit http://bucarotechelp.com/search/000800.asp.
