Design Consideration for the Middle Tier In this
Design Consideration for the Middle Tier In this section we will make important design decisions and set guidelines that will be followed by all the application’s PHP scripts. Authentication The user, when entering the site, enters their user id and password. The PHP script verifies the user id and password, and, depending on the result, allows the user to use the application. After this, the user need not specify their user id and password again. The HTTP protocol is a stateless protocol, which means that for each browser request a new network connection is opened with the web server. The PHP script (running on the web server) should have a mechanism to identify the user from the request. The shopping cart application will use PHP sessions to implement the authentication mechanism. The application will create a PHP session after the user is authenticated. The user id and the isAuthenticated flag will be stored in the PHP session. All the PHP scripts will use the session variable isAuthenticated, to find out if the session is authenticated. The user of the session can be found from the value of session variable $userId. Session Storage One of the requirements of the application was to support multiple instances of the middle tier. This would require additional load balancing software that would distribute HTTP requests (depending on the load balancing policy) to different middle tier servers. Now the deployment scenario will look something like this: With the above deployment scenario, requests of a session might get forwarded to different middle tier servers. This would require the sessions to be shared across all the middle tier servers. The default session implementation of PHP does not allow session sharing between multiple PHP instances running on different machines. We will implement session handlers to store and retrieve session data from the back-end database. With these session handler functions, middle tier instances running on different machines will be able to share PHP sessions. This scheme of storing sessions in the database provides additional reliability, which means that the user will be able to access the application even if one of the middle tier instances goes down. WML Issues The application implementation will follow the following guidelines to take care of WML device constraints (small display size, navigational difficulty). A WML introduction has been provided along with the code which can be downloaded from the Wrox web site at http://www.wrox.com/: . Only relevant information, with links to get the details, will be displayed in the first card of the WML page. For example, in the first card of the search results page only the titles of the searched items will be displayed as links pointing to another card in the same page. The user can select the link to get the details of the item. . Only three items will be displayed per WML page. A link will be provided to view next items. For example, if there are ten transactions in a user’s account, then the view account details page will display only the first three transactions in the first page and will provide a link View Next Items (pointing back to the server), to view the remaining transactions. . A HOME link, pointing to the main page of the application, will be provided in all the WML cards. The user can select the HOME link anytime for going to the main page of the application. This way the user will have to traverse only two links to access any functionality. The WML page is of mime type text/vnd.wap.wml, so all the PHP scripts will send the Content-Type: text/vnd.wap.wml HTTP header. Performance Most PHP programs that access a back-end database will do the following tasks: Page 551
Note: If you are looking for top 10 and very good webhost to host and run your jsp application check Actions jsp hosting services