ONJava.com -- The Independent Source for Enterprise Java
oreilly.comSafari Books Online.Conferences.

advertisement

AddThis Social Bookmark Button

Web and Enterprise Architecture Design Patterns for J2EE, Part 1
Pages: 1, 2

Scope Patterns

Scope refers to the lifetime of certain pieces of information, and the most commonly encountered scopes, in our experience, are Request, Session, and Relationship.



A request-scoped variable must be accessible as long as the client's request has not returned from the server. A session-scoped variable must be accessible as long as the user's login session remains. Finally, a relationship-scoped variable must remain as long as the details of the user remain in the application's database. Relationship is not a scope defined by the JSP specification, but crops up repeatedly in real-world situations such as personalization. (We have not faced any significant issues dealing with two other JSP-defined scopes: Page and Application.)

4. Request Accessor

Intent

To provide a uniform mechanism to access request-scoped variables in multi-step server-side processing.

Problem and Solution

One of the cruel and apparently senseless limitations of JavaServer Pages discovered with dismay by most novice web programmers is that there is no setter equivalent to the HttpServletRequest object's getParameter() method. This can become a serious issue in applications where the processing on the web tier takes place in a series of steps, with the request object being forwarded from component to component. It may be necessary to modify request-scoped data as part of such processing, but in the absence of a setParameter() method, this becomes extremely cumbersome.

One glimmer of hope comes from the existence of the getAttribute() and setAttribute() methods of the request object, which deal with any named object (in contrast to the getParameter() method, which returns a named String). However, using getAttribute() to retrieve parameters from a request object that is freshly received from the browser will not do the trick. The getParameter() method has to be called for this.

The Request Accessor pattern is designed to manage the retrieval, storage and re-retrieval of request-scoped variables using a consistent interface. In its simplest form, the pattern is a static method (say, getAttributeOrParameter()) of a utility class that searches the HttpServletRequest object for a named object. It first calls getAttribute(), and if nothing is retrieved, calls getParameter(). Any server-side component that needs to retrieve a request-scoped variable merely calls this method. The very first access will then retrieve the parameter passed by the browser. When this variable is modified and put back into the request, it must be done using setAttribute(). Subsequent calls to the Request Accessor will then retrieve the modified attribute, not the original parameter. Since all passed parameters are strings, and all strings are objects, it is a trivial matter for the Request Accessor to do the casting to a string whenever an object is retrieved.

(In multi-part forms, an added complication has been observed in that the entire request object is thrown away and recreated when one component forwards to another. This obviously results in the loss of all request-scoped variables. In this case, it may be necessary for components to pass request-scoped variables (with care!) through the session object, for example. The Request Accessor can be modified to cater to such a wrinkle as well.)

Consequences

The positive consequence of the Request Accessor pattern is a simpler way to handle request-scoped variables in multi-step server-side processing, such as Struts.

The negative consequence of the pattern is the extra vigilance required to use attribute names in such a way as to avoid conflicts.

5. Stateless Channel

Intent

To free application state management from dependence on web-centric mechanisms.

Problem and Solution

Most web applications that maintain session state use the JSP engine's implicit "session" object to hold session-scoped variables. However, multi-channel applications may explicitly want to avoid tying themselves to a web-centric mechanism. They would prefer state to be maintained end-to-end between the client and the application server, with the intermediate web tier (JSP engine) remaining stateless. This approach makes it easier to add channels (such as IVR -- Interactive Voice Response) without duplicating the state maintenance logic. It also helps to avoid making web sessions "sticky" by decoupling them from physical JSP engines. Horizontal load balancing in the web tier can then be achieved more simply through a round-robin scheme than through clustering. (Besides, clustering in the web tier is relatively new and may not be supported by all JSP engines.)

The Stateless Channel design pattern helps to manage session-scoped variables in multi-channel applications. Here, the application server generates a session token string after successful authentication, which is passed back through the web tier to the client (e.g., browser). The web tier does not store this session token, either in the HttpSession object or elsewhere. The client (browser) tier holds this token, in the shape of a form's hidden variable or as a "get" parameter in hyperlinks. Thus, when the user submits a form or follows a hyperlink, the session token is passed back and is automatically available to the web tier, which passes it on (again, without storing it locally) to the application tier for validation, and retrieval of session-scoped (and relationship-scoped) variables. Thus, session state is maintained end-to-end, in a completely channel-neutral manner. Hence the name Stateless Channel.

Consequences

The main positive consequence of the Stateless Channel pattern is the ability to build multi-channel applications without redeveloping state management in every channel tier. It also renders the channel tier capable of horizontal scaling through a simple load-balancing scheme such as round-robin.

The main negative consequence of the pattern is an increase in complexity, as well as the extra discipline required to avoid the temptation to use the web session object. Developers who are used to purely web-based applications may have difficulty adjusting to this mindset.

Next week, in the conclusion to this two-part series on Web and Enterprise Architecture Design Patterns, the authors will describe patterns in the remaining three categories: Security, Navigation, and Data Volume Control.

Ganesh Prasad is an architect with Westpac Banking Corporation, Australia's third-largest bank.

Rajat Taneja is a contractor with Sun Microsystems, Australia.

Vikrant Todankar is a senior consultant with EDS Australia, on assignment to the Commonwealth Bank of Australia, Australia's second-largest bank.


Return to ONJava.com.