1. Field of the Invention
This invention relates generally to the field of data processing systems. More particularly, the invention relates to a system and method for managing related session lifecycles within an enterprise network.
2. Description of the Related Art
Multi-Tiered Enterprise Computing Systems
Traditional client-server systems employed a two-tiered architecture such as that illustrated in FIG. 1a. Applications 102 executed on the client side 100 of the two-tiered architecture are comprised of a monolithic set of program code including a graphical user interface component, presentation logic, business logic and a network interface that enables the client 100 to communicate over a network 103 with one or more servers 101. A database 104 maintained on the server 101 provides non-volatile or “persistent” storage for the data accessed and/or processed by the application 102.
The “business logic” component of the application represents the core program code of the application, i.e., the rules governing the underlying business process (or other functionality) provided by the application. The “presentation logic” describes the specific manner in which the results of the business logic are formatted for display on the user interface. The “database” 104 includes data access logic used by the business logic to store and retrieve data.
The limitations of the two-tiered architecture illustrated in FIG. 1a become apparent when employed within a large enterprise. For example, installing and maintaining up-to-date client-side applications on a large number of different clients is a difficult task, even with the aid of automated administration tools. Moreover, a tight coupling of business logic, presentation logic and the user interface logic makes the client-side code very brittle. Changing the client-side user interface of such applications is extremely hard without breaking the business logic, and vice versa. This problem is aggravated by the fact that, in a dynamic enterprise environment, the business logic may be changed frequently in response to changing business rules. Accordingly, the two-tiered architecture is an inefficient solution for enterprise systems.
In response to limitations associated with the two-tiered client-server architecture, a multi-tiered architecture has been developed, as illustrated in FIG. 1b. In the multi-tiered system, the presentation logic 121, business logic 122 and database 123 are logically separated from the user interface 120 of the application. These layers are moved off of the client 125 to one or more dedicated servers on the network 103. For example, the presentation logic 121, the business logic 122, and the database 123 may each be maintained on separate servers, 126, 127 and 128, respectively.
This separation of logical components and the user interface provides a more flexible and scalable architecture compared to that provided by the two-tier model. For example, the separation ensures that all clients 125 share a single implementation of business logic 122. If business rules change, changing the current implementation of business logic 122 to a new version may not require updating any client-side program code. In addition, presentation logic 121 may be provided which generates code for a variety of different user interfaces 120, which may be standard browsers such as Internet Explorer® or Netscape Navigator®.
The multi-tiered architecture illustrated in FIG. 1b may be implemented using a variety of different application technologies at each of the layers of the multi-tier architecture, including those based on the Java ™2 Enterprise Edition (“J2EE™”) standard, the Microsoft .NET standard and/or the Advanced Business Application Programming (“ABAP”) standard developed by SAP AG. For example, as described below, in a J2EE environment, the business layer 122, which handles the core business logic of the application, is comprised of Enterprise Java Bean (“EJB™”) components with support for EJB containers. Within a J2EE environment, the presentation layer 121 is responsible for generating servlets and Java Server Pages (“JSP™”) interpretable by different types of browsers at the user interface layer 120.
J2EE Application Server Architecture
FIG. 2a illustrates a typical J2EE application server 200 in which the presentation layer is implemented by a “Web container” 211 and the business layer is implemented by an Enterprise Java Bean (“EJB”) container 201. Containers are runtime environments which provide standard common services 219, 209 to runtime components. For example, the Java Naming and Directory Interface (“JNDI”) is a service that provides application components with methods for performing standard naming and directory services. Containers also provide unified access to enterprise information systems 217 such as relational databases through the Java Database Connectivity (“JDBC”) service, and legacy computer systems through the J2EE Connector Architecture (“JCA”) service. In addition, containers provide a declarative mechanism for configuring application components at deployment time through the use of deployment descriptors.
As illustrated in FIG. 2a, each layer of the J2EE architecture includes multiple containers. The Web container 211, for example, is itself comprised of a servlet container 215 for processing servlets and a Java Server Pages (“JSP”) container 216 for processing Java server pages. The EJB container 201 includes three different containers for supporting three different types of enterprise Java beans: a session bean container 205 for session beans, a entity bean container 206 for entity beans, and a message driven bean container 207 for message driven beans. A more detailed description of J2EE containers and J2EE services can be found in RAGAE GHALY AND KRISHNA KOTHAPALLI, SAMS TEACH YOURSELF EJB IN 21 DAYS (2003) (see, e.g., pages 353-376).
Session Management
An application server 200 manages “session data” associated with each client interaction. The session data defines the current conversational state between the client and the application server. For example, if the user is purchasing books from an online bookstore, the session data may define the current state of the user's “shopping cart” (e.g., the books the user has selected for purchase). Similarly, if the user is logged in to a particular Web portal (e.g., “My Yahoo”), the session data may define the state of the Web pages opened in the user's Web browser.
Different types of session data are maintained at each logical layer of the application server 200. For example, referring to FIG. 2b, in response to a single client 230 request from a Web browser, an HTTP session object 241 (e.g., an instance of javax.servlet.HttpSession) containing HTTP session data is managed within the Web container 240 and (depending on the type of application) multiple session beans 251-253 may be managed within the EJB container 250 . Additional HTTP session objects 242 and session beans 254-255 may be managed concurrently to define the conversational state with additional clients 231 for the same application (e.g., the shopping cart application) or other applications (e.g., a “search” application). Thus, the state of any given set of applications such as the user's shopping cart may be spread across multiple containers.
USPTO Backgrounds
USPTO Backgrounds