Web Center Architecture

DirX Identity Web Center is a Java-based Web application that must be deployed on a servlet container such as Apache Tomcat. Web Center uses the following technologies:

  • The Jakarta Struts framework of the Apache Software Foundation for action processing (controller).

  • The Jakarta Tiles framework to create the graphical representation (view).

  • Java Server Pages (JSP) to handle the business logic (model) via the Identity API (Java).

The architecture is shown in the following figure:

Web Center Architecture
Figure 1. Web Center Architecture

Software Components

The application consists of the following structural components:

  • Action servlet and action handler

  • Controller JSP pages and tags

  • Identity API

  • View JSP pages and tags

  • Renderers and resources

  • Configuration files

The next sections describe these components in more detail.

Action Servlet

The action servlet is the main component of Web Center and represents the entire application to the servlet engine. When the servlet engine is started, the action servlet is the first Java class that is accessed, and performs all necessary initial configurations. When a client requests the top URL of the application, the request is passed to this class which forwards it to the request processor of the Struts framework. The request processor loads the necessary form component, calculates the action to be performed and forwards the request together with this information to Web Center’s action handler.

Action Handler

The action handler is a Java class that performs the requested operation. Instead of implementing this type of Java class for each operation, it is implemented as a generic class, using a Java Server Page (JSP) that contains the proper action code for execution. When the JSP page is accessed for the first time, a special parser and compiler is used to convert the JSP page to a standard Java class file which is then reused for all subsequent requests for the same page as long as the content of the respective JSP file is not changed. This means that finally pure Java code is executed, but instead of having it bundled as a black-box Java archive, it can be modified according to the customer’s needs.

Controller JSP Pages

The JSP pages used by the action-handler class are called controller JSP pages in contrast to the view JSP pages mainly used for the construction of the resulting HTML pages. The set of controller JSP pages located in WEB-INF/jsp/controller is divided into the following types of page:

  • Core pages, which perform basic operations like login and logout, reading and storing data, and performing basic assignments. These pages are not typically customized but can be included into customized pages.

  • Task pages, which are JSP pages for particular tasks like password change operations, delegation handling or user listing (under certain conditions).

  • Utility pages, which are pure Java code pages coded to cover the majority of use cases. While JSP pages usually contain JSP tags and in some exceptions scripted pure Java code, this file category consists of pure Java code. We recommend that you do not change the implementation of these files.

  • Workflow pages, which are special JSP pages required for all tasks associated with request workflows. These pages read workflow definitions and current tasks of the user, perform approvals, update activity states with the user’s modifications and create signatures for the user’s actions.

Controller JSP Tags

The content of the controller JSP pages usually consists of a logically-arranged set of JSP tags. While an extensive use of the Java Standard Tag Library (JSTL) is made, application-specific tags also exist and serve to hide the implementation of some basic operations like reading and storing form properties, performing the proper login or logout operation and so on.

Identity API

The Identity API contains a set of interfaces for performing the proper identity management operations by the DirX Identity system. The interface classes are well documented and can be used to build add-on features not covered by the Web Center application. The interface classes hide implementation details of the DirX Identity service classes and provide an object model of solely basic Java types. The Web Center application in turn uses some own helper classes to convert these basic object types into convenient ones.

View JSP Pages

When the action handler has performed its request-specific task, it returns the request to the Struts request processor. To construct the resulting HTML pages, the application uses the Struts Tiles component. The Tiles framework allows page modularization and building pages out of global and specific components.

The view JSP pages located in WEB-INF/jsp/view do not represent complete result pages, but rather the components and building blocks of these pages. They are divided into two parts:

  • Form pages
    The form pages folder contains the page layoutPage.jsp taken as a basis for all other pages except those appearing in pop-up windows. There are some other "higher integrated" pages used for special purposes (tab-sheet, assignment page and pop-up window).

  • Tiles pages
    This set contains all page components used to construct tables, forms out of a form configuration list, menus, page headers and footers, and so on.

View JSP Tags

The view JSP tags are used for rendering complex user interface components like tables, tab-sheets, search panels, and tree controls. These tags are used in the view JSP pages in addition to the Java Standard Tag Library (JSTL). A view JSP tag together with an appropriate renderer set produces the final proper HTML code to be sent to the client that will display it in the browser window.

Renderers

The renderers are the face of the Web application.These are the modules that will produce the HTML code that is sent to the client and displayed in the Web browser window.A renderer receives its runtime data usually from a view JSP tag and uses predefined HTML or JavaScript code fragments called "snippets" that contain placeholders for the runtime data.The renderers format the data, replace the placeholders with runtime data and return the completed HTML or JavaScript code to the view tag that will add it to the response object.

Resources

The resource folders contain all necessary items to display a ready-made HTML page, like code snippets, text fragments and message strings in various languages as well as images and styles.Resources that should not be made directly accessible to clients lie in folders below WEB-INF.The other ones like images, styles and Javascript files reside in folder resources parallel to WEB-INF.

Configuration Files

The application requires a number of configuration files.Some are part of the Struts and Tiles framework (struts-config.xml, tiles-defs.xml), others are Web Center proprietary and define objects, forms and renderers.See the chapter “Web Center Configuration” for further details.

Typical Request Flow

When a request is sent from a client to the Web Center application, the servlet engine prepares and forwards it to the action servlet.

The action servlet processes the request using the Struts request processor.Struts transfers the request form data into the action form objects, selects the action based on the URL and the action mapping in the Struts configuration file and invokes the action handler.The action mapping contains the name of the form, the parameter variable (which is a set of name-value pairs here) and a set of possible forward definitions.A forward could be either another action URL or a Tiles definition.

The Web Center action handler copies any parameters defined in the action mapping of the Struts configuration to the request as its attributes, looks up the file with the controller JSP page to be used and passes it to the request dispatcher module.The dispatcher executes the controller JSP page which results in a series of controller JSP tag invocations.The controller JSP page functionality depends very much on the action.At a minimum, it calculates a forward name, stores it as a request attribute and returns to the action handler.Typically, it performs the necessary actions in the Identity domain, like searching for objects and storing attribute modifications.When the controller JSP page returns, the action handler looks up the requested forward and returns this item to the request processor.

This sequence is then repeated or, if the forward contains a Tiles definition, the Tiles processor is called to produce the HTTP response.The Tiles processor prepares the view JSP page to be rendered from usually nested definitions.Once the coding of the JSP page is completed, it is compiled and processed.

Processing the view JSP page leads to invocations of the view JSP tag library and in turn to the renderer set for formatting the final HTML page.The code of this page is passed to the servlet engine’s response object for sending a response to the client.

A Sample: List Users

Let’s study the typical flow for a sample.Assume the servlet receives an HTTP request with an action “/listSingleUser”.

The following action mapping in the Struts configuration tells the Struts request processor to fill the form “userListForm” and to call the action handler “JSPAction”:

<action path="/listSingleUser"
        type="com.siemens.webMgr.controller.action.JSPAction"
        name="userListForm"
        parameter="jspPage:/WEB-INF/jsp/controller/tasks/listUsers.jsp;
            elements:users;
            object:${sessionScope['com.siemens.webMgr.loginDN']};
 defaultSearchBase:cn=Users,${initParam['com.siemens.webMgr.ldap.baseDN']};
            defaultFilter:objectClass=dxrUser">
        <forward name="search" path="/getUsers.do"/>
        <forward name="selectUser" path="/showUserData.do" redirect="true"/>
        <forward …/>
        <forward name="tile" path=".users"/>
</action>

The action handler takes the name of the controller JSP page “listUsers” from the parameter attribute, locates the JSP file and invokes the request dispatcher with the JSP page.

The following diagram gives an overview of the affected JSP pages, tag libraries, utility methods and the resulting action.

Example JSP Page Control Flow

Example JSP Page Control Flow

The JSP page “listUsers” includes the page “listObjects”, which contains some tags; for example, “getActionInfo”, “get” and “set”. The tag implementation uses the Identity API and its associated Java utilities to read and update the Identity domain entries such as the user. For example, the “get” tag calls the method “fetchDataset” of the Java utility class “DataUtils” to search for objects according the filter, base node and other attributes passed.

Let’s assume one user is selected. The JSP page returns the forward “selectUser”. The action handler returns this forward to the Struts request processor, which in turn looks for the appropriate action mapping and may find the following:

<action path="/showUserData"
	type="com.siemens.webMgr.controller.action.JSPAction"
	name="overviewUserForm"
	parameter="jspPage:/WEB-INF/jsp/controller/core/showData.jsp;  	    objectVar:selectedUser;                                 	    object:${sessionScope['com.siemens.webMgr.selectedUser']}">
	<forward name="tile" path=".overviewUserWithTabs"/>
	<forward name="tileContentOnly" path="..."/>
</action>

The Struts request handler re-calls the same Web Center action handler “JSPAction” with the form “overviewUserForm”. The action handler finds the controller JSP page “showData”, which is typically used for presenting entity objects and their attributes.

The default forward references a Tiles definition “.overviewUserWithTabs”. It is defined in the Tiles configuration file “tiles-defs.xml”, where we may find the following:

<definition name=".overviewUserWithTabs" extends=".base">
        <put name="formContent" value=".overviewUserForm"/>
        <put name="formContent2" value=".userPrivilegesTab"/>
        <put name="formContent3" value=".userBinaryTab"/>
        <put name="textFile" value="overview.html"/>
    </definition>

The page definition extends a basic page definition and references a form definition “.overviewUserForm” which may be defined as follows:

<definition name=".overviewUserForm"
path="/WEB-INF/jsp/view/tiles/form.jsp">
      <put name="action" value="/showUserData.do"/>
      <put name="styleClass" value="standardList"/>
</definition>

The Tiles processor aggregates the complete HTML page from the given “tiles”. The user attributes are presented using the generic JSP page “form.jsp”. It contains some Web Center view tags, which evaluate the context beans and build the HTML code.

The resulting HTML page is passed back to the servlet, which returns it to the client browser.