ltr: Vol. 42 Issue 3: p. 27
Chapter 3: Creating a Web Service
Marshall Breeding


“In an era of computing dominated by the World Wide Web, technology referred to as Web services stands as a key one for allowing computers to communicate machine to machine, program to program.…Web services make it easy to connect all types of computer applications to each other. As you will see throughout this report, Web services deliver a foundation of interoperability greatly needed in a world where computer services and digital information exist in many different forms and flavors,” says Breeding in his “Introduction” in the latest issue of Library Technology Reports, “Web Services and the Service-Oriented Architecture.”

“If, in the future, libraries want to be isolated islands in the ocean of content and information, they can ignore Web services. But because much of what libraries do centers on providing information to library clientele and because information is increasingly more electronic—which causes libraries to overlap with many other organizations in the information sphere—it is necessary for libraries to cooperate and interact with a broad set of other organizations and their technical infrastructures. Web services provide mechanisms that allow libraries to expand their services in many important ways.”—Marshall Breeding, “Web Services and the Service-Oriented Architecture.”

About the Author

Marshall Breeding is Director for Innovative Technologies and Research for the Jean and Alexander Heard Library at Vanderbilt University and is responsible for strategic planning for technology and digital library projects. He also serves as the Executive Director and Chief Technology Officer of the Vanderbilt Television News Archive. In his twenty years at Vanderbilt, he has been involved with network administration, library automation, database development, and a wide array of technology projects. In addition, has served as principal investigator on grants from the National Science Foundation and the National Endowment for the Humanities.

In addition to his work at Vanderbilt, Breeding is an eminent independent consultant, analyst, and writer in the fields of networking and library automation. He is a regular speaker and teacher at library conferences, having given more than one hundred presentations or workshops. Breeding has authored the annual “Automated System Marketplace” feature in Library Journal for the last four years; is a contributing editor to Smart Libraries Newsletter; is author of the Sep/Oct 2005 (41:5) issue of Library Technology Reports, “Wireless Networks in Libraries,” published by ALA TechSource; and writes the “Systems Librarian” column published monthly in Computers in Libraries.

According to Breeding, “Web Services and the Service-Oriented Architecture” aims to provide information about Web Services to a library audience. The report includes conceptual descriptions of the technology as well as some technical information on how Web services are implemented. “Library administrators or others that need to make decisions regarding library-related technology systems or issues will gain a perspective on the importance of this technology as well as how the implementation of Web services may relate to other library trends and initiatives. Library technical staff will gain from both the conceptual descriptions and the implementation examples.”

The last chapter demonstrated how to use SOAP to create a Web-service client. This chapter will focus on how a user can create a Web service. The environment utilized will be similar to the one covered for the SOAP client examples (see Amazon Web Services, page 19), including the Windows Server 2003, Perl, the SOAP::Lite Perl module, and IIS 6.0 running on an Intel-based server.

The example that will be demonstrated is fictional. Although I may, at some time, offer a Web service similar to the one discussed in this chapter, it is not currently a public Web service.

A User-Created Web Service for Searching/Retrieving Results from a Database of Libraries

This Web-service example will provide the ability to search a database of libraries and retrieve the results. The service is based on the database of libraries available in lib-web-cats (; this database includes information on more than twenty-five thousand libraries worldwide.

The Web service discussed in this chapter is designed to operate with two types of messages, the first to pass the service request to the server, and the second to pass the response back to the client. This is considered a synchronous service.

First, a plan for how the messages should be constructed needs to be established. The basic input for the Web service will invoke a method named LibrarySearch within the designated namespace LibraryInformation Server, and the input will pass the text to be searched as a string. I'll also include an optional parameter, which specifies the fields to search. The service request might be conceptualized in the simple XML fragment shown in figure 5.

The application will take the basic structure shown in figure 5 and transform it into a SOAP message, including all the headers needed; provide references to each of the schemas and namespaces involved; and specify the data types that apply. The resulting SOAP message would look something like the script shown in figure 6.

Compared to the service request, the service response will be more complex. Instead of passing a single value and qualifier, the response will carry much more information. After the service provider carries out the LibrarySearch method, a user may want to receive some information about each of the items returned in the search; the response will also tell the user the number of items returned.

Such a response requires the user to define a complex data structure. One component of the results will consist of an object that tells him or her about each library found by the query. The structure will be called item and will include several descriptive elements. The item structure can be conceptualized as the script shown in figure 7.

The user, however, will receive many of these, so he or she will need to build an array of <item>. This array is deemed ResultElements, and it will hold as many instances of <ResultElement> as the user needs. The result set will also tell the user the number of items to be returned. This value will be passed in a data structure called TotalResultsCount. So, the request response will consist of a complex data structure called <return>, which includes <ResultElements> and <TotalResultsCount> where ResultElements is an array of multiple <ResultElement>. As the application wraps the results in SOAP, it will look something like the script shown in appendix 13.

I have described the design of the service, so now I'll describe how to construct a WSDL file, which will render the data structures involved and the methods and messages available. This WSDL file will include each of the concepts covered in chapter one.

Because the WSDL file is an XML document (see appendix 14), it begins with the appropriate declaration. The root element of the document will be <definitions> as are all WSDL files. The <types> section specifies the data structures involved in the service, and you can see the structure outline for the complex object (described above). The WSDL includes a section that defines the <messages>, which include one for the service request called <LibrarySearch> and one for the service response called <LibrarySearchResponse> . The <PortType> section references the previously defined messages. The <bindings> and <service> provide the specifications for how this service can be invoked. Note that this listing is meant to illustrate the structure of WSDL and should not be considered the specification of a publicly available service.q

Now that the user has determined what he or she wants the service to do, the user can write some programs to implement it. I'll continue in the mode of using Perl with SOAP::Lite.

The most complex part of the programming project will be to create a Perl module that implements the service. This program will need to access the underlying database and be able to deliver results to the SOAP environment. The Perl module illustrated in appendix 15 performs these tasks.

This module uses the Open Database Connectivity (ODBC) model to communicate with the underlying database. The ODBC layer is provided by the Win32::ODBC Perl module and the ODBC driver of the underlying database. Using ODBC makes the program database independent, and it can be used with any database with an ODBC driver available.

The Perl module contains the sub-routine Library- Search, which serves as the primary method for the user-created Web service. The module receives as its input parameters the messages passed by the service request. The <query> parameter is passed into the sub-routine, into the local variable $request, which is then inserted into an SQL statement. The SQL statement is stored as a string in the global variable $SqlStatement, and it's executed by the ODBC engine by the sub-routine executeSQL. ODBC returns the results of the query in the object $db. The user can then use the ODBC method FetchRow to retrieve each of the table rows returned by the query. An associative array named data holds the values for each field. As each row is processed, the values in the data array are pushed into the SOAP data structures. The rows are counted as it goes along, so it can also return the number of results in the TotalResultsCount component of the structured response.

The user must ensure that all data passed in the service response is valid XML. The MakeValidXML sub-routine performs this function. In the simple example, it only fixes the known problem of unescaped ampersands. In a production service, the user would need to perform a rigorous check of the data to ensure the service does not fail due to problems with the data (such as using characters outside the defined encoding or character set).

Once the module has been developed that performs the work defined in the service, the user can activate it through a program that sets up the server to monitor SOAP requests. There are many ways to activate a SOAP service; in the SOAP::Lite environment, for example, a user can establish a service with the few simple lines of code (appendix 16), and the service operates through TCP sockets.

With the service operational, the user can use the following command-line client (appendix 17) to access it, which continues to rely on Perl and SOAP::Lite.

Although it is clearly more complex to develop a Web service than to access an existing one, it can be accomplished without too much effort (as illustrated in this chapter). This Web service performs a relatively simple task—that of searching a database and delivering a result. Most of the complexity comes into play in the setting up the data types and message structures needed for the SOAP environment, and many programming environments automate much of this part of the development process.

Appendix 13: <ResultElement> Array

Appendix 14: WSDL File for User-Created Web Service

Appendix 15: Perl Module That Implements the User-Created Web-Service

Appendix 16: Code for User-Created Web Service in a SOAP::Lite Environment

Appendix 17: Command Line Client to Access User-Created Web Service


[Figure ID: fig1]
Figure 5 

Simple XML Fragment—Service Request in LibrarySearch Method

[Figure ID: fig2]
Figure 6 

SOAP Message Generated from Simple XML Fragment in Figure 5

[Figure ID: fig3]
Figure 7 

Item Structure

Article Categories:
  • Information Science
  • Library Science


  • There are currently no refbacks.

Published by ALA TechSource, an imprint of the American Library Association.
Copyright Statement | ALA Privacy Policy