Library Journal "Digital Libraries" Columns 1997-2007, Roy Tennant
Please note: these columns are an archive of my Library Journal column from 1997-2007. They have not been altered in content, so please keep in mind some of this content will be out of date.
What To Know About Web Services
As amazing as technological progress in libraries has been in the last decade, more dramatic opportunities await. One such opportunity, under the prosaic name "Web Services," would knit together software applications to construct powerful new services. Just imagine being able to pull patron information--transparently and fast--from one system to complete an ILL transaction in a completely different system. Not only that, but those transactions would not need to be written in the same language, or executed on the same platform, or even be dependent on more than basic, publicly available information. In other words, we are talking about interoperability of a high order. Web Services defined In a nutshell, Web Services are a suite of protocols that define how requests and responses between software applications should be encoded (using XML) and transferred (e.g., over the web using HTTP or e-mail) and how such services should be described and registered for discovery and use. Tracy Gardner, in a recent Ariadne article, called Web Services "interoperable building blocks for constructing applications." If you know of CORBA and Remote Procedure Calls (RPC), then you are halfway there, since those are similar technologies. Still, examples should make the concept easier to comprehend. The Portuguese National Library The Portuguese National Library is developing Web Services (in association with its catalog vendor BookMARC) using the Portuguese National Catalog, a database of one million UNIMARC records. By sending a properly formatted message to the catalog (using SOAP, see below), a UNIMARC record can be retrieved in response to an ISBN. Another service allows for retrieving sets of records by searching various record fields. These examples are part of a larger set being implemented by the library, says Joaquim Carvalho of BookMARC. Additional services due out this summer include searching, inserting, updating, and validating records. Such an infrastructure offers robust interoperability with disparate systems. This project is one of the best documented, including step-by-step instructions and source code in "How To Consume Sirius Web Services." WRL Consortium The digital library system of the Washington Research Library Consortium (WRLC), called ALADIN, provides subscription databases, digital collections, and library catalogs for seven medium-sized academic research libraries. Recently, ALADIN has begun using Web Services to provide simple, network-based interfaces to its services. By providing a Web Services interface to patron information (e.g., items checked out), individual campus libraries can easily provide this information as part of their own services. Thorny issues such as user authentication can become part of the infrastructure supporting these functions. As Don Gourley of the WRLC says, "With Web Services we can use our existing infrastructure and knowledge of web applications to link together different systems." This project is described in much greater detail in a forthcoming book I'm editing from Neal-Schuman called XML in Libraries. A rebirth for Z39.50? Web Services may also give Z39.50 a new lease on life. Z39.50 International- The Next Generation (ZING) is Z39.50 using Web Services protocols. The Koninklijke Bibliotheek in the Netherlands is using the ZING Search/Retrieve Web (SRW) service to make its catalog accessible via SOAP. For more information, see my forthcoming book. Web Services protocols The web is based on a collection of protocols (conventions for communication), ranging from defining how the bits get from place to place (TCP/IP) to those that define the web itself (HTTP and HTML). Web Services add extra protocols to the mix--including SOAP, WSDL, and UDDI--which help define a new set of opportunities for communication. Of all the Web Services protocols, the Simple Object Access Protocol (SOAP) is the most essential. SOAP allows disparate software on a variety of platforms to communicate by specifying a standard XML encoding for messages between systems. See "Overview of SOAP" for a good start. Once you understand how SOAP works, it can be more powerful than simply sending a message from one application to another. SOAP provides for three parts to a message: an optional header, a mandatory body, and optional attachments. The body, plus any optional attachments, is intended for the final destination. The header, however, can support in-transit processing. For example, an authentication server could process only the header of a SOAP message, passing the body of authenticated messages on to the final destination. For those who want to get a quick start on using SOAP to create Web Services, the Apache project has software that can help. Apache SOAP takes care of reading and writing the XML and sending and receiving it over the network. See also the Apache SOAP follow-up project, Apache Axis, now in beta testing. WSDL & UDDI Pronounced "wiz-dull," the Web Service Description Language (WSDL) is the method by which a specific Web Service is described. A WSDL definition for a specific Web Service will specify the format of the messages that can be passed from requester to responder, the address (URL) of a service, and the protocol to use (e.g., the web, secure web or HTTPS, or e-mail). These descriptions are then deposited in a UDDI repository (see below). The depository holds these descriptions for discovery by those wishing to use Web Services. See the "Overview of WSDL." Universal Description, Discovery, and Integration (UDDI) is the part of Web Services that enables potential users to discover the existence of individual Web Services. Potential users search a UDDI repository, or are pointed to a particular WSDL description that they can retrieve from a UDDI repository. Limitations of Web Services As interesting and encouraging as these emerging services are, Web Services are not the be-all and end-all of library web opportunities. Art Rhyno of the University of Windsor, ON, cautions that Web Services "may not be enough to wire together a busy circulation system and a patron database." However, he says, Web Services can be "a way to bring together systems that don't have to talk together for their primary function but can take advantage of each other for extended services." Some examples he cites are linking the online catalog to Google (Google is Web Services-enabled, see "Google APIs" in the Link List), or allowing item due date information to populate a personal calendar. As with most technologies, we will likely discover that Web Services can be very useful for solving particular problems but not so great for others. Since the protocols upon which Web Services are based are still new, we are still discovering the best applications for it. __________________________________________________________________ LINK LIST Apache Axis Project xml.apache.org/axis Apache SOAP xml.apache.org/soap Google APIs www.google.com/apis How To Consume Sirius Web Services ptolemy.bookmarc.pt:8001/kb/kb000002.html IBM developerWorks www-106.ibm.com/developerworks An Introduction to Web Services www.ariadne.ac.uk/issue29/gardner Overview of SOAP dcb.sun.com/practices/webservices/overviews/overview_soap.jsp Overview of WSDL dcb.sun.com/practices/webservices/overviews/overview_wsdl.jsp Simple Object Access Protocol www.w3.org/TR/SOAP UDDI Registry www.uddi.org Web Services Description Language www.w3.org/TR/wsdl XML in Libraries www.neal-schuman.com/db/0/290.html ZING SRW www.loc.gov/z3950/agency/zing/srw.html