For several reasons, Java became the solution to the multiple-language problem. Java tools were available for each part of the project, from establishing a middle layer that could handle multiple connections for staff updates to working with JDBC8 database drivers for loading data into the system. Java also provided a technology called Enterprise Java Beans (EJB) which had the double benefit of both supplying a powerful middleware framework and hiding most of the messy details that had added so much bulk to the original C version of the middle layer. A related and java-based toolkit from Exolab called Castor9 enhances the capabilities of the EJB server while XML10-enabling many of the components of PYTHEAS, which in turn, allowed SOAP/Web Services11 support to be easily incorporated. Finally, Java was one half of a technology originally conceived by Netscape called LiveConnect12, which was an essential component for making the web browser a viable platform for staff client software. The overall architecture of PYTHEAS can be seen in the following diagram.
Of course, no journey is complete without several interpretations on the optimal route to reach the destination. It seemed unworkable to use a standard web form/cgi-bin setup for the level of updating that would be required for staff to do MARC cataloguing or ordering library materials, yet several observers sent discreet e-mails questioning if the architecture was too complex and “over-engineered” for a library system. Some of the components certainly required the consumption of more caffeine than is recommended for most humans but almost all of the technologies were selected in order to tap into mainstream applications.
In other words, the architecture was designed to maximize contributions from other communities, so that, for example, the general ledger required for Acquisitions could be plugged in using EJB and free up the resources required to develop the ledger from scratch. EJB and SOAP, in particular, free a developer from spending enormous amounts of time implementing tricky programming constructs like transactions and resource pooling.