Demystifying Web services: How they really work

More than any recent technology, Web services are surrounded by hype, mystery, and a bit of mumbo jumbo thrown in for good measure. Does anyone really know what they are or how they work? Find out how Web services really work.

The Web Services Advisor

Demystifying Web services: How they really work More than any recent technology, Web services are surrounded by

hype, mystery, and a bit of mumbo jumbo thrown in for good measure. Does anyone really know what they are or how they work? To give you a leg up, in this column I'll demystify Web services for you and explain how Web services protocols do their work.

Let's start with the basics. Web services are modular software components wrapped inside a specific set of Internet communications protocols and that can be run over the Internet. These components can communicate with other components automatically without human intervention. They can be used on an Intranet inside a firewall, or out across the greater Internet. A Web service itself is a software module delivered over the Internet or an intranet via XML (eXtensible Markup Language) messaging. The software module can be built in a variety of ways, most notably, but not exclusively, using Java.

At the heart of the Web services architecture is the need for program-to-program communications. And in order for that communication to take place, the Web service itself first needs to be described in detail so that other programs can understand what it is and know how to connect to it. That is what XML does - it describes the service in a manner that can be understood and used. This XML depiction is called a service description, and includes all the details necessary for the Web service to be accessed, including its location, transport protocols and message formats it uses.

Understanding the key roles in the Web services architecture
In order for a computer or program to use a Web service, it needs be able to find the service description and then bind to it. To accomplish this, there are three key roles in Web services architecture: a service provider, a service registry and a service requestor. Together, they perform three operations on a Web service: publish, find and bind. The nearby figure (Fig. 1) shows how this all fits together.


Fig. 1

The publish operation makes information about the service available so that it can be found and used - in other words, it makes the service description publicly available. The find operation discovers the Web service - it's the way in which the computer or program searches for, and understands, what the Web service is, where it's located, and how to link to it. The bind operation allows the service to be used by the person or program requesting the service.

Let's take a look at a typical scenario detailing how the service provider, service registry and service requestor work together to deliver a Web service. First the Web service is built as a software module, then a service description is created for it using XML. A service provider hosts the module. The provider also hosts the XML service description for the Web service, which includes details about the service, including its location, transport protocols and message formats it uses.

The service provider publishes this service description to a service registry, a public, searchable index of service descriptions through which people can find Web services. Included is information about the Web service, such as details about the service provider/host. The service registry's role is to make available service descriptions so that Web services can be found and run. A service registry isn't absolutely required for Web services to be run - service descriptions can be found in other ways, such as from an ftp site, a Web site, a local file, or from other sources.

The service requestor is the business looking to run a Web service, or an application looking to interact with a Web service. It can be a person using a Web browser, or can also be a program, or even another Web service. The service requestor searches the service registry and finds the service description for the Web service. Based on the information it finds in the service registry, it connects to the service provider hosting the Web service using a bind operation, and then runs the service.

A look at the underlying protocols
All of this is made possible by the basic building blocks of Web services, a group of three standards: Simple Object Access Protocol (SOAP); Web Services Description Language (WSDL); and Universal Description, Discovery and Integration (UDDI). Here's how they work together:

  • WSDL is the language used to create service descriptions. It is able to create descriptions not only about the location of the service and how to run it, but also higher-level information, such as what business is hosting the service, the kind of service it is, keywords associated with the service and similar information.
  • SOAP is the means through which the service provider, service registry and service requestor communicate. It's an XML-based technology used to exchange structured data between network applications. SOAP is used to publish the service description to a service registry. Similarly, all other interactions between service registry, service requestor and service provider are done via SOAP.
  • UDDI is the directory technology used by service registries that contain the description of Web services and that allows the directory to be searched for a particular Web service. UDDI is in essence a Yellow Pages that can be used to locate Web services. There can be both private and public UDDI directories.

That, in a nutshell, is how Web services work. In future columns, we'll examine the architecture and each of the protocols in more detail.


 

About the Author

Preston Gralla, a well-known technology expert, is the author of more than 20 books, including "How the Internet Works," which has been translated into 14 languages and sold several hundred thousand copies worldwide. He is an expert on Web services and the author of a major research and white paper for the Software and Information Industry Association on the topic. Gralla was the founding managing editor of PC Week, a founding editor and then editor and editorial director of PC/Computing, and an executive editor for ZDNet and CNet. He has written about technology for more than 15 years for many major magazines and newspapers, including PC Magazine, Computerworld, CIO Magazine, eWeek and its forerunner PC Week, PC/Computing, the Los Angeles Times, USA Today, and the Dallas Morning News among others. As a well-known technology guru, he appears frequently on TV and radio shows and networks, including CNN, MSNBC, ABC World News Now, the CBS Early Show, PBS's All Things Considered and others. He has won a number of awards for his writing, including from the Computer Press Association for the Best Feature in a Computer Publication. He can be reached at preston@gralla.com.

 

For More Information

 

  • What do you think about this column? If you'd like to send feedback, you can E-mail the Editor.
  • Visit our Best Web Links for Web Services for the best editor-selected resources on the Web.
  • Post your technical questions, or help out your peers by answering questions, in our Discussion Forums.
  • Ask the Experts! Our Web Services, XML, .NET, Java, EAI, and App Server gurus answer your toughest questions.

Dig deeper on BPM

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

SearchSoftwareQuality

SearchCloudApplications

SearchAWS

TheServerSide

SearchWinDevelopment

Close