Scope and methodology issues



Download 212.29 Kb.
Page4/7
Date02.02.2017
Size212.29 Kb.
#15350
1   2   3   4   5   6   7

Web services

Web services (or, less confusingly, application services) have been succinctly defined as “self-contained, self-describing modular applications that can be published, located and invoked across the Web”. Web services “perform functions, which can be anything from simple requests to complicated business processes”. In other words, they are “interoperable building blocks for constructing applications” (Gardner 2001). Web services allow an application to invoke a remote process or application as if it were part of the invoking application (Jacobson 2002). The infrastructure required to support Web services may be described in terms of three roles: service provider, service requestor and service registry, and three interactions: publish, find, bind. It may be seen that Web services have the potential to provide robust interoperability between different systems (compare the discussion of library system components above, p. .). Major commercial software providers heavily support them: the two competing environments for the development of Web services are Enterprise Java Beans (Sun Microsystems) and Microsoft’s .NET.


Web services depend upon a suite of XML-based open standards:

  1. The Web Services Description Language (WSDL) which describe a service as a set of “ports” which group related interactions that are possible between the application (service requestor) and the Web service (service provider);

  2. The Simple Object Access Protocol (SOAP), a standard for XML-based information exchange between distributed applications. It is typically transmitted over HTTP. It has the advantage of working across firewalls;

  3. Universal Discovery, Description and Integration (UDDI), which is a specification for distributed registries and services.

Other than library portal solutions (see above, p.....) I have not been able to identify any commercially-available library systems incorporating Web services. However, there are a number of local implementations and experimental projects within the library community which are highly significant:




  1. The work of ZiNG on Web services implementations of Z39.50 has already been discussed (above p. )

  2. The Portuguese National Library is using Web services architecture to support the Portuguese National Catalogue. The system allows record retrieval and the searching, insertion, validation and updating of records (Tennant 2002).

  3. The ALADIN digital library system of the Washington Research Library Consortium (WRLC) uses Web services to provide a network-based interface to its services, permitting more effective integration with the systems of the individual member libraries. 19

  4. Most significant, perhaps, is the PYTHEAS experimental multi-tier open source library system or library application framework (see above….) developed by Rhyno and his team at the University of Windsor, Ontario (Rhyno 2002c). PYTHEAS uses RDF and MARC as its major metadata formats. The server is based on XML, Web services, and Enterprise Java Beans, with Exolab’s Castor XML mapping tool as middleware.

Web services are currently receiving a great deal of attention within the information technology industry as a whole. It remains to be seen whether the early expectations will be borne out.





  1. Java

Java is an important enabling technology for library systems, allowing the rapid development of new functions. It relates closely to XML in that many XML tools and applications are coded in Java. It shares with it the characteristic of platform-independence. . Using XML and Java together, developers can build sophisticated, interoperable Web applications more quickly and at a lower cost.


Java is a high-level programming language that was launched by Sun Microsystems in 1995, and is steadily becoming more significant in web-mediated information delivery. It has the advantage over other programming languages of being object-oriented (like C++, but simpler to learn); platform-independent, portable and secure; according to the developers, it will “write once, run anywhere, on anything, anytime, safely…” (Jones 1997). Java code is relatively easy to reuse and maintain, giving it an advantage as compared with scripting languages.
Java programs running on client PCs enhance considerably the possibilities for interactivity of Web pages. Users can run programs (applets) on remote servers from within a Web browser: they are embedded within HTML pages using the tag and execute within the so-called Java Virtual Machine (JVM) (Rhyno 1997b), a subsystem that can be incorporated within a variety of computing environments.
Java programs will run on PCs using Windows 9x / NT/2000/XP, Macintoshes, and Unix workstations, using any microprocessor. Operating systems do not necessarily come with the JVM installed; it is provided either through a Java Development Kit (which includes tools for developing and running Java applications) or a Java Runtime Environment (which simply allows Java applications to run). This is the standard approach for servers running network operating systems; the primary vehicle for providing a (more limited) JVM is the Web browser (Breeding 2000b). Java is supported by recent versions of the main Web browsers.
Java applets and applications are easily distributed via the Web, but can work offline, which facilitates system maintenance and upgrading. The network becomes the distribution vehicle for the software applications. Java code loads from the network to the client PC’s RAM: there is no need for it to install to the hard disc. Portability of applets across architectures is not perfect, however (Hickey 1997); vendors’ JVMs vary, and large applets can take some time to download. “Platform independence” has in practice generated a whole raft of semi-standards, spin-off technologies and legal difficulties.
The information retrieval capabilities of Java are much improved over the HTML forms/CGI approach, which can return only one page at a time and cannot deal well with large result sets. It was realised early on by library systems experts (e.g. Rhyno 1997b, McKiernan 1997, Hickey 1997, Rosenberg 1996) that Java, on account of the advances in functionality it offers, would be an excellent tool for developing OPACs and Z39.50 clients. It has the functionality to handle the complex interface between the client and the Web server, being able for instance, to support the sorting and analysing of relationships between records displayed within a browser, and the holding open of a connection to a remote library service. Using Java to create the Z39.50 client provides a standard browser interface without loss of the Z39.50 functionality.
Java permits the running of animation, video and sound internally within a browser; it provides for pop-through windows and for the integration of different types of tools and documents within the Web environment. It also offers the possibility of annotating documents, of linking composite documents, and of customisation (Chu 1996, Jones 1997, McKiernan 1997). The Java Database Connectivity (JDBC) interface is a significant technology, comparable to Microsoft’ ASP. It allows programs written in Java to access any ANSI SQL-2 standard database; it presents a means of dynamically generating HTML pages; and it allows applications to present the same interface to all databases on all platforms.
Running programs over the internet obviously creates security issues. Java was designed in such a way that the applets must operate within a strictly defined environment called the sandbox, they are restricted from reading from or writing to the local hard disc, from gaining access to the operating system, data files, and hardware, and from opening connections to servers other than the one from which they originated. Hence it is a) difficult to save retrieved items and b) impossible to connect to several Z39.50 servers at once. However, there are ways of overcoming these limitations: email can generally be used to send results to users; also the host server can be set up to act as a bridge to other Z39.50 servers.

Sun Microsystems made a deliberate pitch for the library systems market at an early stage (Chu 1996, Pasquinelli 1997); it was perceived that its platform independence could effectively extend the life of legacy library computer systems. However, it has made a presence in library automation only slowly (Breeding 1997). While the trend towards its use is not overwhelming, there are now a number of major products using Java in one or more of their components. TLC has a cataloguing system, CATNOW!, and a Java-based circulation systems and OPAC, Library*Solution. Innovative’s Millenium system incorporates several Java modules, while CyberTools, BiblioMondo, and epixtech have Java OPACs. The new Java 2 Enterprise Edition (J2EE) is claimed to have transformed a streamlined, thin programming language into a complete computing platform, of which the language is just one component. It has recently started to be implemented within integrated library systems, for instance Talis’ new library portal, TalisPrism.





Download 212.29 Kb.

Share with your friends:
1   2   3   4   5   6   7




The database is protected by copyright ©ininet.org 2024
send message

    Main page