aspose file tools*
The moose likes Web Component Certification (SCWCD/OCPJWCD) and the fly likes request handling mechanism in a distributable web application Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Web Component Certification (SCWCD/OCPJWCD)
Bookmark "request handling mechanism in a distributable web application" Watch "request handling mechanism in a distributable web application" New topic
Author

request handling mechanism in a distributable web application

Kiaama Liames
Ranch Hand

Joined: Jun 30, 2006
Posts: 52
can anyone explain the request handling mechanism in case of a distributable application ???


scjp 1.4<br />scwcd 1.4
Phil Kurian
Ranch Hand

Joined: Feb 26, 2006
Posts: 35
Rather general question, but here's a start.

A distributable application is an app (for the SCWCD purposes a web-app) which run on multiple servers. Usually the purpose for this is for load-balancing.

Lets say, the app is distributed across two servers A and B (it can be more than 2). In such a situation, the code, config files etc on both these servers would be identical.

When the user makes a request it passes through a load balancing server (physical or virtual) which directs the request to one of these servers.
Which server is chosen is at the discretion of the the load balancing server. This is completely transparent to the user.

What is important however is that whilst the user makes more requests, these requests will not necessarily be directed to the same server.

e.g. request1 -> server A
request2 -> server B
request3 -> server B
request4 -> server B
request5 -> server A
....
etc.

This has important implications for the developer of the web app. If it's a distributed app, the developer has to make sure that the application doesn't rely on servletContext attributes. This is because any attributes added to the servlet context are NOT migrated to the servlet context objects on the other web servers. Also, if the user is using a session, and the next request ends up going to a different server, the session migrates to the other server. This has implications for the objects bound to this session.

Hope that helps


SCJP (1.4)
Kiaama Liames
Ranch Hand

Joined: Jun 30, 2006
Posts: 52
Thanks phil!!
In case of a distributable application each JVM has their own instance of ServletContext and ServletContext is not shared across applications and there is only one default context in distributed environment have you refered to the default context as a load balancing server (physical or virtual)

correct me if i am wrong
Phil Kurian
Ranch Hand

Joined: Feb 26, 2006
Posts: 35
In case of a distributable application each JVM has their own instance of ServletContext and ServletContext is not shared across applications and there is only one default context in distributed environment have you refered to the default context as a load balancing server (physical or virtual)


Yes, there each JVM has it's own context, and it is good practice to ensure that the context on each JVM is identical (i.e. same context-params, no attributes).
I'm not entirely familiar with the terminology of default context, but I know that a load balancing server is a completely different concept. Load balancing is a feature thrown in by Web App servers, and is usually vendor specific. On Websphere for instance receives all requests, and then redirects the request to the server with the least load. All of this is hidden from the user.

This stuff isn't really applicable to the exam. All you should really know is , the rules you need to follow if you make your app distributable. These rules basically boil down to ensuring your servlet context is consistent across all JVM, that objects bound to a session are serializable, and that you may want to use a HttpSessionActivationListener for informing when the session migrates from JVM to JVM
Kiaama Liames
Ranch Hand

Joined: Jun 30, 2006
Posts: 52
Thanks Phil
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: request handling mechanism in a distributable web application