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 | [[#OpenSRF|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.((some clients could connect directly to Jabber, which would be both in the Application and Presentation layers)).
  * 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: FIXME) 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 ======
FIXME Please put details of the OpenSRF workers for Evergreen here.