Browse Prior Art Database

Method for Sharing Data at the J2EE Enterprise Application Scope Disclosure Number: IPCOM000020805D
Original Publication Date: 2003-Dec-15
Included in the Prior Art Database: 2003-Dec-15
Document File: 2 page(s) / 6K

Publishing Venue



Proposed is an extension to the J2EE specification that would formalize a method for sharing data between Web Applications in an Enterprise Application.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 51% of the total text.

Page 1 of 2

Method for Sharing Data at the J2EE Enterprise Application Scope

Currently J2EE applications provide for four levels of data scope: Page, Request, Session, and Application. These are all used by accessing the appropriate context object (PageContext,ServletRequest,HttpSession, and ServletContext) and using attribute get/set methods. There is not an equivalent mechanism for storing data at a scope such that it can be shared between multiple Web Applications within a single Enterprise Applications, either in a client-specific or client-agnostic container.

For instance, a developer may have two related web applications in an enterprise application. The first web application is used to retrieve a user's serial number, which is stored in the http session, whereafter control is transferred via an html link to the second web application. The second web application may want to use the serial number stored in the http session of the first web application. In the absence of a standard J2EE mechanism for transmitting this information, multiple solutions to this problem have arisen, some of which are enumerated below:

1) The data could be encoded in the url linking to the second web application, then taken from the request. Possible drawbacks are that the data is directly exposed in the URL to the user, and that the control must be transferred via the special url.

2) The first web application could contact the second web application directly, either using sockets (not strictly j2ee) or some other messaging protocol. It would not be a core solution available in j2ee, and would require preparation for non-web network traffic, and possible maintenance of separate servers used to perform the message relaying.

3) The first web application could write out the data to a location outside of the j2ee infrastructure, such as a database or a flat file. This leads to possible synchronization problems, additional server maintenance, network traffic, etc.

4) WebSphere allows a flag which can change the scope of the HTTPSession to allow it to be used across web applications, but this doesn't alter the API in such a way that you can alternately use web appli...