Table of Contents
This chapter provides a general introduction to the use and deployment of Pazpar2.
Pazpar2 implements a simple but efficient HTTP server, and it is designed to interact directly with scripting running in the browser for the best possible performance, and to limit overhead when several browser clients generate numerous webservice requests. However, it is still desirable to use a conventional webserver, such as Apache HTTP Server, to serve up graphics, HTML documents, and server-side scripting. Because the security sandbox environment of most browser-side programming environments only allows communication with the server from which the enclosing HTML page or object originated, Pazpar2 is designed so that it can act as a transparent proxy in front of an existing webserver (see Pazpar2 conf(5) for details). In this mode, all regular HTTP requests are transparently passed through to your webserver, while Pazpar2 only intercepts search-related webservice requests.
If you want to expose your combined service on port 80, you can either run your regular webserver on a different port, a different server, or a different IP address associated with the same server.
Pazpar2 can also work behind a reverse Proxy. Refer to Section 6, “Apache 2 Proxy” for more information. This allows your existing HTTP server to operate on port 80 as usual. Pazpar2 can be started on another (internal) port.
Sometimes, it may be necessary to implement functionality on your regular webserver that makes use of search results, for example to implement data import functionality, emailing results, history lists, personal citation lists, interlibrary loan functionality, etc. Fortunately, it is simple to exchange information between Pazpar2, your browser scripting, and backend server-side scripting. You can send a session ID and possibly a record ID from your browser code to your server code, and from there use Pazpar2's webservice API to access result sets or individual records. You could even 'hide' all of Pazpar2's functionality between your own API implemented on the server-side, and access that from the browser or elsewhere. The possibilities are just about endless.