|
| |
| Sun Java System Communications Express 6 2004Q2 Administration Guide | |
Chapter 2
Overview of Communications ExpressSun Java™ System Communications Express 6 2004Q2 provides an integrated web-based communication and collaboration client that caters to the needs of Internet Service Providers, Enterprises, and Original Equipment Manufacturers.
As a web-based client, the three client modules - Calendar, Address Book and Mail of Communications Express depends on a web server for access and a browser for presentation.
Product Features
- Communications Express has an integrated user interface for calendar, mail, and address book and enables the access of one client module from another without re-authenticating user credentials.
- Communication between mail and calendar is established using Identity or Messaging Single sign-on mechanism.
- Both calendar and mail applications share the same address book.
- All modules share the common user preferences specified in the Options tab of Communications Express.
This chapter contains the following sections:
High-Level Architecture
The Calendar and Address Book client modules are deployed as a single application on any web container and are collectively referred to as the unified web client (UWC) throughout this guide.
Figure 2-1 High Level Architecture
Messenger Express is the standalone web interface mail application that uses the HTTP service of the Messaging Server. Messenger Express should be deployed on the same system as the Calendar and Address Book modules. Messenger Express is the standalone web interface mail application that uses the HTTP service of the Messaging Server. Messenger Express should be deployed on the same system as the Calendar and Address Book modules.
UWC is based on JATO, the Sun ONE Application Framework. It requires a J2EE compliant web server to serve HTTP requests made to access UWC.
Every user request passes through a dedicated application controller servlet which delegates the request to the appropriate communication client module, such as mail, calendar, or address book. Before delegating a request, the application servlet checks for the presence of a valid HTTP session for the browser client attempting to access UWC. In the absence of a valid HTTP session the controller servlet directs the request flow through the authentication process.
The authentication process is handled by a set of web filters and an authentication servlet.
- Identity Server SSO Filter. It checks for established sessions with Sun Java System Identity Server using the Identity Server’s Single Sign-On mechanism. If a valid Identity Server session is found, the filter creates an HTTP Session for UWC and passes the control to other filters in the chain. Otherwise, the control is transferred without creating a session.
- Messaging SSO Filter. It checks for established sessions with peer Sun Java System applications for example, Portal Server or stand alone Messenger Express participating in Messaging SSO mechanism.
- If the Identity Server SSO filter has already created a session for UWC, this filter passes the control seamlessly to the rest of the filters.
- If no session is created by the Identity Server SSO filter, this filter checks for an established Messaging SSO session. If it finds a valid session, it creates an HTTP session for UWC and then forwards the control to the next web filter.
- LDAP Auth Filter. This filter is used to support applications supporting Sun ONE LDAP Schema, v1 and when both Identity Server SSO and Messaging SSO filters have not been able to create a successful HTTP session. The filter uses the username and password to validate the credentials against the authentication LDAP configured for UWC. Once the credentials are authenticated it creates an HTTP session and transfers the request to the next filter.
- Anonymous Access Filter. In the absence of a valid session, this filter checks for the presence of a URL in the format http://host:port/?calid=calid. The presence of a URL in this format indicates an anonymous access.
- Authentication Servlet. The Authentication Servlet determines whether any of the web filters could create a successful HTTP session for UWC. If the Servlet does not find a valid session, it directs the request to a login page for the user to enter the user name and password. If Identity Server is enabled in UWC, the UWC login page is displayed.
The credentials entered in the Identity Server login page are authenticated by the Identity Server using one of the configured services. For example, LDAP services.
The credentials submitted via the Communications Express login page are authenticated against the authentication LDAP configured for UWC.
After the credentials are submitted and authenticated, the request is again routed through the filters to obtain a valid HTTP session for UWC.
Once the Authentication Servlet determines the presence of a valid session it redirects the request to the application controller that displays the requested client module.
Sun Java System Communications Express comprises of the following three modules:
- Mail. The Mail architecture uses Javascript to present the user interface and interacts with Sun Java System Messaging Server over HTTP protocol to fetch the data.
- Calendar. The presentation layer in the Calendar module is based on Sun ONE Application Framework. The data layer accesses a Java API for Calendar (JCAPI) to enable exchange of data with Sun Java System Calendar Server over HTTP based protocol.
- Address Book. The Address Book architecture uses XML/XSLT for the presentation layer and LDAP for data storage. Data storage is accessed using LDAP SDK API.
Each client module is further defined as a Sun ONE Application framework module, which is handled by the module specific controller servlets.
The JATO modules defined for UWC are:
- Base Level Module. All application-wide tasks such as views for options and application-level initialization are handled by the base level module. The controller servlet for this module is UWCServletBase and it handles all requests for the URI “base.” All other module’s controller servlets inherit from this servlet.
- Calendar Module. All views and models belonging to the calendar application are handled by this module. The controller servlet for this module is CalModuleServlet and it handles all requests for the URI “calclient.”
- Mail Module. All views and models belonging to the mail application are handled by this module. The controller servlet for this module is MailModuleServlet and it handles all requests for the URI “mailclient.”
- Address Book Module. All views and models belonging to the address book application are handled by this module. The controller servlet for this module is ABModuleServlet and it handles all requests for the URI “abclient.”
Overview of the Request Flow
A request to UWC can initiate the following phases:
- Authentication.In this phase a user session is created by the web filters.
- Session Creation. Once a user session is created, the following actions are performed to enable the application for the rest of the user session:
- UI Rendering. During this phase, a completed request outputs the resultant page for display.
- Request Forwarding (submission). In this phase, server-level validations are performed on the data entered and submitted by users. Based on the success or failure of the validation, the request is forwarded to the appropriate target.
- Error Handling. In the event of an error or an exception, an error page pertaining to the request is displayed.
- Anonymous Access. Anonymous calendars provide a limited “read only” access to the calendar being viewed. The anonymous calendar displays only the events list, day, week, month, and year views. Contents of the mail, address book, and options tab cannot be viewed in an anonymous access.
Initialization
UWC refers to a number of objects that are shared throughout the application during a user session. These objects are initialized either when a new user session is created or when the application is started. Initialization can be categorized into:
Application Initialization
All application-wide objects are cached in the application scope.
- Authentication and Application Configuration. Authentication and application configuration parameters are present in uwcauth.properties and uwcconfig.properties under WEB-INF/config directory. Application configuration details are loaded when the application is started. Authentication parameters are used when UWC is accessed for the first time.
- Domain Configuration. Domain configuration is stored in the user’s domain LDAP entry and in uwcdomainconfig.properties file. Each defined domain for UWC is read and stored. The application then obtains the domain configuration details from the cache instead of reading it from LDAP every time.
- Resource Bundle Caching. All i18n strings, image paths, and other items that are localizable and customizable are read once and cached.
- LDAP Pool. A connection pool for the user/group LDAP is created when the application is started. The pool is destroyed when the application is stopped.
User Session Based Initialization
The following are initialized for a new user session:
- User Preferences.The User’s global preferences are read from the LDAP user entry and stored in the scope of the session.
- Mail and Calendar Active Status. The mail and calendar modules’s service availability status is computed and stored within the scope of the session. This information is later used by the UI to determine whether the mail or calendar application should be displayed.
Module Level Initialization
Module level initializations are performed when a request is made specifically to a module’s Uniform Resource Identifier (URI).
Calendar Store, Calendar Preferences, and Calendar data Objects are examples of module level initializations for the calendar module of a user.
