SESSION STATE MANAGEMENT: A web service-based enterprise application consists of distributive services located on J2EE tiers that are shared amongst applications. A client accesses components by opening a session with a web tier. The session begins with an initial request for service and ends once the client no longer requests services. During the session, a client and components exchange information which is called session state. A component is an entity whose sole purpose is to receive information from a client, process that information, and return information to the client when necessary. This means that it is up to the enterprise application to devise a way to maintain session state until the session is completed. There are two common ways to manage session state: Client side session state Server side session state CLIENT SIDE SESSION STATE: Session state can be maintained by the client rather than on the server using one or a combination of three techniques. These are: Hidden Form Field URL Rewriting Cookies HIDDEN FORM FIELD: The hidden form field component can include in the HTML form a field that is not displayed on the form. This field is called a hidden field. <INPUT TYPE=”HIDDEN” NAME=”ACCOUNT NUMBER” VALUE=”1234”> <INPUT TYPE=”TEXT” NAME=”FIRSTNAME” SIZE=”40”> <INPUT TYPE=”SUBMIT” VALUE=”SUBMIT”> <INPUT TYPE=”RESET” VALUE”CLEAR”>BEST PRACTICE: The best practice for using a hidden field to maintain the session state is to do so only when small amounts of string information needs to be retained. In addition hidden fields contain only the string values and not numeric, dates, and other data types, which means the component might need to convert string values into more appropriate values each time the page is sent to the component. URL REWRITING: URL rewriting is another strategy for managing session state. a URL is the element within web page that uniquely identifies a component and is used by the browser to request a service. URL rewriting simulates the routine the browser performs to extract field names and values from an HTML form. That is, the developer places field names and field values into a query string as part of the URL statement. When the user selects the hyperlink that is associated with the URL statement, the browser calls the component identified by the URL and passes the component field names and field values that are contained in the URL statement. BEST PRACTICE: The best practice is to use URL rewriting to retain session state whenever an HTML form is not used by the client. COOKIES: A cookie is a small amount of data that the enterprise application stores on the client’s machine. A cookie can be used to store session state. Cookies are always sent with the request to the web server and information can be retrieved from the cookies at the web server. Cookies can be temporary and permanent in nature. There are two major disadvantages of using cookies to retain session state. First, cookies can be disabled, thereby prohibiting the enterprise application from using a cookie to manage session state. Other disadvantage us that cookie are shared amongst instances. This means a client might run two instances of a browser, creating two sessions. All instances access the same cookie and therefore share the same session state, which is likely to cause conflicts when processing information because the wrong session state might be processed. BEST PRACTICE: The best practice is to use a cookie only to retain minimum data such as Client ID and use other techniques described in this section to retain large amounts of information. A developer must also implement a contingency routine should the user discard the cookie or deactivate the cookie feature. SERVER SIDE SESSION STATE: An alternative to maintaining the session state on the client side is to store session state on the server BEST PRACTICE: The best practice is to maintain session state on the Enterprise Java Beans tier using an Enterprise Java Bean or on the web tier using the HTTP Session interface REPLICATION SERVERS: It is not uncommon for an enterprise application to use a cluster of replication servers where each server has the full complement of components.BEST PRACTICE: The best practice is to maintain sticky user experience, depending on your business needs. This means the client always uses the same server during the session and the session state is stored on one server within the client. This also means that the session is lost should server go down. VALID SESSION STATE: Another common issue that is common with an enterprise application that stores session state on a server is whether or not the session state is valid. Session state is automatically becomes invalid and removed when the session ends. However, there might be occasions when the session ungracefully terminates without removing the session state, such as during a communication failure that occurs during the session. BEST PRACTICE: The best practice is to always set a session timeout, which automatically invalidates session state after time has passed and the session state has not been accessed. However once time has expired, the session ends and therefore the session state is removed.