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, [123]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 ([124]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 "[125]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
   [127]xml.apache.org/axis

   Apache SOAP
   [128]xml.apache.org/soap

   Google APIs
   [129]www.google.com/apis

   How To Consume Sirius Web Services
   [130]ptolemy.bookmarc.pt:8001/kb/kb000002.html

   IBM developerWorks
   [131]www-106.ibm.com/developerworks

   An Introduction to Web Services
   [132]www.ariadne.ac.uk/issue29/gardner

   Overview of SOAP
   [133]dcb.sun.com/practices/webservices/overviews/overview_soap.jsp

   Overview of WSDL
   [134]dcb.sun.com/practices/webservices/overviews/overview_wsdl.jsp

   Simple Object Access Protocol [135]www.w3.org/TR/SOAP

   UDDI Registry
   [136]www.uddi.org

   Web Services Description Language
   [137]www.w3.org/TR/wsdl

   XML in Libraries
   [138]www.neal-schuman.com/db/0/290.html

   ZING SRW
   [139]www.loc.gov/z3950/agency/zing/srw.html