Difference between revisions of "Umlaut Technical Overview"

From Code4Lib
Jump to: navigation, search
(→‎OpenURL parsing and storing)
m (link)
 
(29 intermediate revisions by 4 users not shown)
Line 1: Line 1:
−
To give you an overview of the technical architecture of umlaut, we will go through a typical Resolve request, identifying all the classes involved, and pointing to their api doc if possible.  
+
To give you an overview of the technical architecture of [[Umlaut]], we will go through a typical Resolve request, identifying all the classes involved, and pointing to their api doc if possible.  
  
 
OpenURLs are sent to the default index action of the [http://umlaut.rubyforge.org/api/files/app/controllers/resolve_controller_rb.html resolve controller].
 
OpenURLs are sent to the default index action of the [http://umlaut.rubyforge.org/api/files/app/controllers/resolve_controller_rb.html resolve controller].
Line 5: Line 5:
 
In the resolve controller, a before filter method called init_processing is run to parse the OpenURL and set up the Umlaut request (or retrieve an existing request).  
 
In the resolve controller, a before filter method called init_processing is run to parse the OpenURL and set up the Umlaut request (or retrieve an existing request).  
  
−
==Setting up the Request and it's context==
+
==Technical Overview Sections==
  
−
===OpenURL parsing and storing===
+
# [[Request Setup and Environmental Context]]
−
 
+
# [[ServiceResponse data structures and generation]] -- Includes guide to writing your own services.  
−
In understanding Umlaut, it's helpful to understand a bit about the nature of an OpenURL, including that an OpenURL is composed of several entities or groupings of metadata. Jeff Young's [http://q6.oclc.org/2006/08/welcome_1.html Q6 blog] includes one good explanation of the six OpenURL entities.
+
# [[View architecture and control flow]]
−
 
+
# [[Background services]] -- control and view architectures for background services
−
Two sets of classes are involved in dealing with OpenURLs in Umlaut. The ropenurl library is generally used to parse OpenURLs. However, Umlaut serializes OpenURLs to it's own ActiveRecord classes--[http://umlaut.rubyforge.org/api/files/app/models/request_rb.html Request], to represent an incoming OpenURL request, and some constituent data in [http://umlaut.rubyforge.org/api/files/app/models/referent_rb.html Referrent], [http://umlaut.rubyforge.org/api/files/app/models/referent_value_rb.html Referent Value], and [http://umlaut.rubyforge.org/api/files/app/models/referrer_rb.html Referrer].
+
−
 
+
−
Once the OpenURL is parsed with the ropenurl library, the data is stored in internal Umlaut classes, which are generally used subsequently to deal with the request data.
+
−
 
+
−
A bit confusingly, Umlaut's own Request (an ActiveRecord which represents a parsed OpenURL request, and other persistent state related to Umlaut's handling of that OpenURL request) should not be confused with the Rails ActionController::Request class (which represents the complete details of the current 'raw' HTTP request, and is not stored persistently in the db).  
+
−
 
+
−
So the first thing the resolve action does is pass the incoming HTTP request details to the Umlaut Request#new_request method, which will ''''either'''' create a new Request, or recover an already created Request from the db--in either case return a Request matching the OpenURL.
+
−
 
+
−
====Request caching====
+
−
 
+
−
The point of this recovery is that if the user presses the browser reload button, the app should be connected with the same already created request--allowing the same already generated responses to be used, among other things.  Cache matching is based on: Must be from the same session, must be from the same originating IP address, must have the same OpenURL parameters (same OpenURL parameters measured by a serialized version (Request#serialized_co_params) of recognized openurl paramters stored in the 'params' attribute.
+
−
 
+
−
Alternately, if the request ID is passed in (in query var "umlaut.request_id"), that is used instead of context object matching. Umlaut often passes requestID internally, to make sure the same request is recovered. If request_id matches, sessions is not required to match--this is intentional to recover the request even if browser isn't returning cookies, thus not connecting to same session.
+
−
 
+
−
===Building the service Collection: Institutions and Services===
+

Latest revision as of 09:13, 26 November 2008

To give you an overview of the technical architecture of Umlaut, we will go through a typical Resolve request, identifying all the classes involved, and pointing to their api doc if possible.

OpenURLs are sent to the default index action of the resolve controller.

In the resolve controller, a before filter method called init_processing is run to parse the OpenURL and set up the Umlaut request (or retrieve an existing request).

Technical Overview Sections

  1. Request Setup and Environmental Context
  2. ServiceResponse data structures and generation -- Includes guide to writing your own services.
  3. View architecture and control flow
  4. Background services -- control and view architectures for background services
Retrieved from "https://wiki.code4lib.org/index.php?title=Umlaut_Technical_Overview&oldid=1457"