Fairly trivial…

• Application: the UI for most end-users, through which they will initiate a function.¹⁾.
• 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 ;)

• 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.

Please put details of the OpenSRF workers for Evergreen here.