Main -> Documentation -> Building Your WebZ Interface -> How the WebZ Interface Works -> Detailed Description of a WebZ Session

Detailed Description of a WebZ Session - continued

Start Page, Stage 1, Stage 2, Stage 3


Stage 2: WebZ processes the request for a new session.

In Stage 1, the user sent in a request to begin a new WebZ session. The user did this by clicking the GO! button on the Logon screen of the Out-of-the-Box Interface. In Stage 2, we will discuss the events that take place when WebZ receives the logon request.


The User Request for the New WebZ Session

As presented in Stage 1, the following is the content of the user request sent to WebZ in order to begin a new session:

POST /WebZ/Authorize:sessionid=0:  \
     next=html%2Fhomeframe.html:  \
     bad=error%2Fauthofail.html:  \
     autho=WebZGuest:password=WebZGuest:  \
     x=14:y=20


Order of Events

The following events take place when WebZ receives the user request for a new session. These events are described in detail in the remaining sections in this stage.

  • The OpServe component of WebZ creates a new session id and a UserState object for the user.
  • The JaSSI component creates an Action object and a RequestManager object to handle the user request.
  • JaSSI attempts to authorize the user.
  • If authorization is successful, JaSSI loads data about the user.
  • Finally, JaSSI executes the next command (as specified in the user request for the new session) and the new session is under way.


Creating a New Session ID and UserState Object

The presence of "sessionid=0" within the user request causes the OpServe component to create a new session id and UserState object for the user. When OpServe detects sessionid=0, it assigns the user to an available JaSSI and gives the user a unique, randomly generated id number identifies the user's session until logoff. The following is an example of a typical session id. We will use this session id throughout the remaining stages of the example WebZ session.

01-37542-1619472257

Description of the Session ID:

  • "01" indicates which JaSSI host the user session belongs to. The WebZ system can run on multiple hosts. Each host must be defined in the HostMap.ini configuration file. The "01" is defined by the HostID variable in this configuration file.
  • "37542" indicates the port at which the JaSSI is registered. The OpServe component routes the user requests to this JaSSI port.
  • "1619472257" is a randomly generated number that uniquely identifies the user's session.

The UserState Object

The UserState object is a memory object (specifically, an extended hashtable) in which the user's session data is stored and retrieved. Throughout the user's session, the UserState object is the storage object for the user's list of databases, the user's interface style, search results, etc. Each user session has its own UserState object. The UserState object makes it possible for WebZ to maintain a stateful session and thus makes it seem as though the user has a dedicated connection from the web browser to the WebZ system. Without the UserState object, a user's session could not occur because there would be no way of maintaining persistent data about the user's activities within the session.


The Action and RequestManager Objects

When the JaSSI component receives the user request, it creates an Action object and a RequestManager object to process the request. The information contained in the user request is reduced to its essential elements and is stored in the Action object. The RequestManager object uses the information in the Action object for executing all instructions in the user request, and for preparing and sending a response back to the user.

The following example shows the information contained in the Action object and RequestManager object for the user request in our example WebZ session. Log File Tip: This information was taken directly from the JaSSI user logfile (with trace level set to TRACE_ALL). Every instance of an Action object or RequestManager object created during a WebZ session is recorded in the JaSSI user log, which is extremely helpful if you are learning about the system or are trying to debug your customized interface.

--------------
Action Object
---------------
uri          = /WebZ/Authorize:sessionid=0
documentRoot = /webz_root/htdocs/
nameSpace    = /WebZ/
nextCmd      = 
className    = /WebZ/Authorize
mimeTypeExt  = 
rawWidgets   = :sessionid=0:next=html%2Fhomeframe.html:  \
                bad=error%2Fauthofail.html:autho=WebZGuest:  \
                password=WebZGuest:x=16:y=21
widgets      = [sessionid=0, next=html/homeframe.html,  \
                bad=error/authofail.html, autho=WebZGuest,  \
                password=WebZGuest, x=16, y=21]

[D19990218.T101104.599] [Action.init()]
Exit method.
[D19990218.T101104.603] [RequestManager()]
-------------------
RequestManager Object
-------------------
hostName       = 01
JaSSIPort      = 37542
next           = 
postProcess    = 
htmlPage       = 
httpResponse   = 
mimeTypeExt    = 
httpMsg        = 
url, POST /WebZ/Authorize:sessionid=0 HTTP/1.0
Referer, http://bongo:26013/
Connection, Keep-Alive
User-Agent, Mozilla/3.01Gold (WinNT; I)
Host, bongo:26013
Accept, image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
Extension, Security/Remote-Passphrase
Content-type, application/x-www-form-urlencoded
Content-length, 98
Peer-Host, dhcp211-217
Peer-Address, 132.174.211.217
ThreadID, 91935066433811188
SessionID, 0
body, next=html%2Fhomeframe.html&bad=error%2Fauthofail.html  \
&autho=WebZGuest&password=WebZGuest&x=16&y=21







Note:


The backslashes ( \ ) are included for readability and are not part of the HTTP message. 








Authorizing the User


Once the Action object and RequestManager objects are created, the JaSSI is essentially ready to begin processing the instructions contained in the user request. To begin the processing, the RequestManager attempts to execute the instruction contained in the className field of the Action object. In our example WebZ session, the className field contains the following:



className    = /WebZ/Authorize



Class/File Load Order

        The RequestManager ignores the "/WebZ/" portion of the instruction (because 
        it is the WebZ namespace) and attempts to load (i.e., execute) a Java 
        class or HTML file called Authorize. In order to load the Authorize 
        class or file, the RequestManager must locate it. To do this, the RequestManager 
        searches for Authorize in the following locations:


    

  • The WebZ document root. This is defined by the DocumentRoot variable in the JaSSIServer.ini configuration file.
    • 

  • The WebZ class root. This is defined by the ClassRoot variable in the JaSSIServer.ini configuration file.
    • 

    In addition to the document and class root directories, the RequestManager searches the Java packages defined in the [PackageOrder] section of the JaSSIServer.ini configuration file, which is configured at installation to be the following:
    

  • The ORG.oclc.obi package. 
    • 

  • The ORG.oclc.obi.extverb package.
    • 

  • The ORG.oclc.webz package.
    • 

  • The ORG.oclc.jassi package.
    • 



The search sequence listed above is referred to as the Class/File Load Order, and it is the process by which the JaSSI is able to locate and load Java classes and HTML files. Why does it search in this particular order? The JaSSI is hard-coded to search the WebZ document root and WebZ class root, and both of these locations are user-definable. You can also assign additional locations for the JaSSI to search, such as specific Java class packages. The benefit of being able to specify Java packages is that it allows the JaSSI to locate classes and files faster, and it allows you to use your own, custom Java packages and keep them separate from the WebZ packages.



Locating the Authorize Class

        The Authorize class is 
        located in the ORG.oclc.obi package. The RequestManager goes through the 
        Class/File Load Order outlined above and locates the Authorize class. 
        The following section of the JaSSI user log shows the entire Class/File 
        Load Order process, from the RequestManager.processCommand() method to 
        the execution of the Authorize class.



 1  [D19990218.T101104.607] [RequestManager.processCommand()]
 2  Enter method.
 3  Class/file load order:
 4  ----------------------
 5  [/webz_root/htdocs/Authorize, Authorize, ORG.oclc.obi.Authorize,  \
    ORG.oclc.obi.extverb.Authorize, ORG.oclc.webz.Authorize,  \
    ORG.oclc.jassi.Authorize]
 6  [D19990218.T101104.610] [RequestManager.executeCommand()]
 7  Enter method.
 8  Try to load class = /webz_root/htdocs/Authorize
 9  Try to load class = Authorize
10  Try to load class = ORG.oclc.obi.Authorize
11  [D19990218.T101104.639] [AccessUserData.get()]
12  Enter method.





The RequestManager's planned search path for Authorize is in line 5. In line 6, the RequestManager begins the search. It searches the document root (line 8) and the class root (line 9), and then it finds Authorize (line 10) in the ORG.oclc.obi package. When the Authorize class loads, the AccessUserData.get method is executed (lines 11 and 12) and the authorization process is under way.






Note:


Notice in the log file (line 8) that whereas the document root path is fully displayed, the class root is not (line 9). Even though the log file shows only "Authorize", the RequestManager is actually searching the "/webz_root/classes/Authorize" path, or whatever the root is as defined in ClassRoot variable of the JaSSIServer.ini file.








Loading User Data for the New Session


When the Authorize class executes, it first checks to see if the user's id and password (supplied in the original user request) are valid. If so, it creates the following data for the user and stores the data (or references to the data) in the user's UserState object.


User Data


    
        
  • ZUserData. 
          This information is a summary of the user's Z39.50 transactions/history 
          for the WebZ session.
    • 

  • Database list. This is a list of references to the databases and group databases that the user has access to. Using the Access component, the list of databases can be defined by the user's authorization profile.
    • 

  • Interface style. This is a reference to the interface style assigned to the user based on the user's authorization profile. You can customize WebZ to assign different interface styles to users based on their authorization profile. An interface style controls the look and feel of the interface displayed to the user in the web browser.
    • 



Once this information is created, the user's session is ready to begin.



Executing the 'next' Command


Upon successful completion of the Authorize class, the RequestManager searches the Action object for a next command in the user request. The next command contains instructions for what should occur now that the Authorize class was successfully executed. In our example WebZ session, the user request contains the following next command, which, when processed, will instruct the RequestManager to load the homeframe.html file.



next=html%2Fhomeframe.html



The RequestManager locates the next command and updates the Action object as follows:



 1  ---------------
 2  Action Object
 3  ---------------
 4  uri          = html/homeframe.html:sessionid=0:  \
                   bad=error%2Fauthofail.html:  \
                   autho=WebZGuest:password=WebZGuest:  \
                   x=16:y=21
 5  documentRoot = /webz_root/htdocs/
 6  nameSpace    = /WebZ/
 7  nextCmd      = 
 8  className    = html/homeframe.html
 9  mimeTypeExt  = html
10  rawWidgets   = :sessionid=0:  \
                    bad=error%2Fauthofail.html:  \
                    autho=WebZGuest:password=WebZGuest:  \
                    x=16:y=21:
11  widgets      = [sessionid=0, bad=error/authofail.html,  \
                    autho=WebZGuest, password=WebZGuest, x=16, y=21]







Note:


Notice that the next command is listed in the className field (line 8) and is no longer listed with the raw widgets (line 10).







The RequestManager now attempts to execute the instruction contained in the className field of the Action object (line 8 above). To do this, the RequestManager first tries to locate the homeframe.html file using the same Class/File Load Order it used when executing the Authorize class. The following section of the JaSSI user log shows the RequestManager loading the homeframe.html file:



 1  Class/file load order:
 2  ----------------------
 3  [/webz_root/htdocs/html/homeframe.html, homeframe.html,  \
    ORG.oclc.obi.homeframe.html, ORG.oclc.obi.extverb.homeframe.html, \
    ORG.oclc.webz.homeframe.html, ORG.oclc.jassi.homeframe.html]
 4  [D19990218.T101104.754] [RequestManager.executeCommand()]
 5  Enter method.
 6  Try to load class = /webz_root/htdocs/html/homeframe.html
 7  [D19990218.T101104.756] [RequestManager.readHtmlFile()]
 8  Enter method.




The homeframe.html file is located in the WebZ document root directory, which is defined in the DocumentRoot variable in the JaSSIServer.ini configuration file. In accordance with the Class/File Load Order, the RequestManager searches the document root first and locates homeframe.html (line 6) and begins reading the file (line 7). The homeframe.html file will eventually become the Home screen displayed to the user in the WebZ interface.



Summary


In Stage 1, the user opened the WebZ logon screen and clicked the GO! button, which sent an HTTP message to WebZ requesting a new user session. In Stage 2, WebZ created a session id and UserState object, created a RequestManager object to handle the request, authorized the user, loaded data about the user, and began reading the homeframe.html in order to build the Home screen of the interface.


What Happens Next?
In Stage 3, the RequestManager processes the homeframe.html file and sends it back to the web browser. The process by which this occurs is referred to as the page preparation process.



Start Page, Stage 1, Stage 2, Stage 3















 


  

        
 		
      

      

        
    [Main][Documentation][Support][Technical 
      Reference][Community][Glossary][Search] 
      

        
        
      
		
    		
      

    





   Last Modified: