Table of Contents
In response to a request on the -dev mailing list, this is a very rough map of the Evergreen functionality. The original author of this document (dmcmorris) cannot guarantee its functionality or accuracy, but hopes it will at least start a building block for the *real* knowers' to build upon.
Note: I'm going to attempt to adopt the de-facto standard OSI model to the OpenSRF functionality. Some of the labels aren't quite accurate in the OSI sense, but at least the layers are in order.
| Layer | Responsible Portion | Description/Examples |
|---|---|---|
| Application | Staff client/web browser | Web OPAC, Staff Client, SIP/NCIP Client, etc. |
| Presentation | High-level servers | Apache server for OPAC/Staff Client, Z39.50 server, SIP/NCIP server, etc. |
| Session | Perl | |
| Transport | Jabber Server | OpenSRF uses Jabber to communicate |
| Network | OpenSRF Router | |
| Datalink | OpenSRF modules | See below |
| Physical | Databases | Evergreen uses PostgreSQL, but I suppose something other could be adapted. |
General
Fairly trivial…
- Application: the UI for most end-users, through which they will initiate a function.1).
- Presentation: takes the user-initiated function, determine what OpenSRF module (and parameters) are needed, and will pass the requests to the OpenSRF Router via Jabber.
- Session: Evergreen uses Perl and perl modules.
- Transport: Jabber. Used for communication between the Presentation-level function and the OpenSRF router.
- Network: The OpenSRF Router. This keeps track of the available OpenSRF portions and will pass the requested function on to the appropriate one.
- DataLink: The OpenSRF modules/workers. Usually, they will query the backend databases and return data (sometimes just an error code, sometimes much much more).
- Physical: Databases. Of course, databases aren't physical. But this is the bottom-level for OpenSRF, and Physical is the bottom-level of the OSI model that we're using, so that's where I put it ;)
Example 1: log in of staff
- APPLICATION: Staff opens the staff client, enters username/password. Username/password/workstation/version/etc. is passed on to the
- PRESENTATION: Web server. This goes to the
- SESSION: Perl modules, which knows it has to go to open-ils.auth modules with the parameters. It will send a message (Ex:
) via - TRANSPORT: the Jabber server to
- NETWORK: the OpenSRF router, which will call the
- DATALINK: open-ils.auth module. The open-ils.auth module will
- PHYSICAL: query the database and pass the response back to the
- DATALINK: open-ils.auth module, which will determine that the credentials are valid and will pass it back to the
- NETWORK: OpenSRF router, which will return the message via
- TRANSPORT: the Jabber server to
- SESSION: the Perl module, which will start to bring together the stuff needed to compile
- PRESENTATION: the coding and serve it to
- APPLICATION: the Staff client as the interface.
OpenSRF
Please put details of the OpenSRF workers for Evergreen here.
1)
some clients could connect directly to Jabber, which would be both in the Application and Presentation layers