Differences

This shows you the differences between two versions of the page.

--- scratchpad:lowlevelmap [2007/03/17 05:36] – Trying the OSI model. dmcmorris
+++ scratchpad:lowlevelmap [2022/02/10 13:34] (current) – external edit 127.0.0.1
@@ Line 1: / Line 1: @@
+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.