www v/s www1 v/s www2. Role of CNAME and DNS.

How are www, www1, www2, etc. different? Role of CNAME & DNS?

Let's start with discussing what the different parts of a typical web site address mean? Say for example, if we take http://www.google.com then the first part from left http denotes the protocol being used for communication on Internet. The two most popular protocols being used are http and ftp. Requests using different protocols connect to server at a separate (default unless otherwise explicitly specified) port on the targeted server. Like an http request connects to the server via TCP and connects by default at port number 80. An 'http' request is also called a Web request.

Now that we have kind of understood what the first part of a typical URL means, let's move on to the next parts. We're discussing only the web site addresses in this article so the first part will always be either 'http' or 'https' which is nothing but HTTP running on SSL (Secure Sockets Layer). Following this there will be a set of 3 characters (://), usually termed as delimiters and they separate the protocol from the web site address.

The web site address in our example is www.google.com like every other web site address this is also of the form CNAME.secondaryName.TopLevelDomain where TopLevelDomain is something like '.com', '.org', ... etc. and they are resolved by the top level domain name servers called the root servers. These root servers are maintained by naming authroities like ICANN. The TopLevelDomain are normally one word long only, but they can be made of two (or maybe more) words separated by '.' as well, for example 'co.in', 'co.uk', ... etc. they are also top level domain names.

Left to the top level domain names comes the secondaryName which is the normally the unique name you choose for your website. Like in our example this name is 'google'. These names are resolved using the lower level domain name servers (DNS). Again it's not necessary that the secondaryName will always be one word long. It can be made up of severalwords maybe to maintain a hierarchy for the purpose of segregating (and then serving) requests of different types based on country, sub-domains, etc.

The leftmost part of a web site address is normally 'www' which is nothing but the name of the web server of the company hosting and running the web site. As it's a name and hence it can anything like 'aaa', 'aa', 'aaaa', 'www1' , 'www2' or any other string unique in context of the company specific DNS as these names are not resolved by the root or intermediate level DNS instead it's the company specific DNS which resolves it. Resolving a name simply means returning the IP address of the computer so that a combination of IP Adrress and a port (normally a default port) can be used by a client to establish a TCP connection.

This leftmost part of the web site which is normally resolved by the company specific DNS is usually called CNAME or Canonical Name. In case of our example, CNAME is 'www'. Like every other part this part is not required to be a one-word long name only. It all depends how much string is mapped to the actual IP address of the server in the company specific DNS mapping table. Needless to re-iterate that this can be any string (unique in the particular DNS context) you want and not only 'www'.

Let's take another example. The address of this blog is http://geekexplains.blogspot.com, so for this address 'com' is the top level domain, 'blogspot' is the secondaryName and 'geekexplains' is the canonical name which identifies this blog uniquely under the context of the secondary domain named 'blogspot'. The same physical server might (or probably for sure) is used for many other blogs running under 'blogspot'. This is probably achieved by having separate active ports (on the physical machine) each of which hosting processes responsible for one blog each. Ever wondered why the address 'http://www.geekexplains.blogspot.com' also takes you to the same blog? Well... because two canonical names 'geekexplains' and 'www.geekexplains' are probably mapped to the same IP Address - Port combination which hosts the process servicing the GeekExplains blog. The DNS at secondary domain requires that all the canonical names are unique in its context which is why you're asked to pick an unique name for your blog while you create one. Another interesting point to note here is that the client browser establishes TCP connection on the default Port Number 80 only as it connects to the server hosting 'blogspot.com' only and the request is further resolved there to return the HTTP response of the actual blog to the client. The mapping table of 'blogspot' DNS makes sure that the requests to any of the blogs running under it are intercepted by it and subsequently all the requests are serviced as expected. Hope this helps. Any doubts? Or, have anything to add/modify here? Feel free to reach me by dropping a comment.

Liked the article? You may like to Subscribe to this blog for regular updates. You may also like to follow the blog to manage the bookmark easily and to tell the world that you enjoy GeekExplains. You can find the 'Followers' widget in the rightmost sidebar.

How does Password Encryption work in real world?

Password encryption in work: illustration using SBI Sign In process

Last week I received an email (from one of our visitors, Anil) inquiring about what all actually takes place to ensure that the password (or any other sensitive data for that matter) gets encrypted before the request is sent to the Web/App Server? Thanks Anil for raising such a nice point.

In this article, I'll try to discuss how the password encryption feature typically works. Few details might be implementation dependent and hence might be little different in your case than what is mentioned below (and in the follow-up article), but the underlying idea will probably remain the same (more or less) for most of real world applications which require authentication.

Okay, let's start from thinking about which all places do we actually need to put encryption into action and how do we implement them? Except the possible encryption done at the Database end, there are two popular approaches of implementing encryption - One, which is done at the client side (the one we will mainly talk about in this article) and Two, which is done at the server side (i.e., the request carries the actual password and at the server it's encrypted to be processed further).

The former of the two is obviously safer to have as it eliminates the risk of the request being intercepted in the middle before it actually reaches the web/app server. Well... you can say that the data packaged in a HTTP POST request is automatically encrypted in case of HTTPS, but an extra level of encryption will only add to the security of the web application. Of course, the implementation should not be too much time consuming otherwise the benefits of having a more secure application will be ruled over by the frustration it might cause to its end-users.

Though, it depends upon the actual implementation, but possibly the preferred choice (in highly secure systems) is that the actual password should not be exposed anywhere in system, which means the encrypted password stored in DB is fetched and probably not decrypted back to actual password which the end-user uses, but instead some other form which is matched with the decrypted one at the middle-tier to authenticate the user. Find below a pictorial representation of how actually such a password authentication scenario works:


The entered password is first encrypted at the client side using the Public Key ('public key1' in the above diagram) and then the encrypted password reaches the App Server where it's decrypted a corresponding Private Key ('private key1' in the above diagram). App Server also fetches the password stored in the database, which might need to be decrypted using another Private Key ('private key2' in the above diagram). Now, the implementation of the algorithms and the generation of the keys should be such that both the decrypted passwords 'decryptedpwd1' and 'decryptedpwd2' should match equal for all the valid cases and they should be unequal otherwise.

How can the encryption be implemented? Will JavaScript/VBScript suffice?

Next question arises, how can we do it effectively and at the same time without consuming much time? The fastest possible way would probably be to have some mechanism in place so that the encryption can take place at the client side only. Okay, so how can the encryption take place at the client side? If we put both the encryption also definition and the public key in the JavaScript (or VBScript) code then one can easily see everything just by viewing the page source. Did you think that making the JavaScript external can solve your problem? As in you only declare the JS file in that case and not list down the contents. Well... if you did think this, you got to think again. A external JS file is equally exposed for viewing by the clients as you can simply type the path (if the path is absolute OR just append the relative path to the roor URL) in the browser window and the complete JS will be there for you to be viewed. We'll see examples below. Evidently, the encryption won't really carry any benefit here.

How else can we do it at the client side? How good would Applets be?

Yeah... now you got a better way of handling the situation. As we all know that applets are also downloaded to the client machine and are executed at client machine itself, so we can now make use of the Java programming language and its security mechanism for having the encryption implemented in a far better manner. What's probably an even more appealing about this approach is that you can NOT see the source of the applet class(es) directly. They are normally shipped in JAR bundles which gives an extra layer of security. You can claim that since the JARs are downloaded and the .class file of the applet class runs within the vicinity of the client JVM so the bytecodes would certainly be available which can then be de-compiled to have a look at the source. Yeah, you're are right that the bytecodes are available at the client machine and it can be decompiled. But, what makes this approach better than the JavaScript approach can be understood by following points:

• Bytecode tempering is automatically detected: if an intruder somehow gets hold of the bytecodes and changes that, the changed bytecode will throw an exception while running whereas any such changes in the JavaScript (or VBSCript) source won't be detected.
• Security Mechanism of Java is much more versatile: what we talked about in the above point is also an integral part of the Java Security mechanism, but it's not only limited to this. It's quite versatile and layered. No such benefit is available with JavaScript (or VBScript).
• JVM offers a far more consistent environment: bytecodes run within a Java Virtual Machine which obviously offers a far more consistent and stable environment as compared to the environment in which JavaScript (or VBSCript) code runs.
• Impl of different public/private keys for every new request: you would probably be aware of the Secure Key concept which forms a part of the password on many systems. The underlying idea in such implementations is to have part of the password which keeps on changing on a continuous basis and thus making it virtually impossible for the attackers to guess that. Similarly, if we want to step up the encryption strength to an even higher level, we can put in place different public/private key combinations for every new request.

Now that we have understood the underlying concept of password encryption, let's move on and see a pictorial representation of how password encryption has been implemented in a real world live scenario. We'll take example of SBI Net Banking and try to understand how the user entered password is getting encrypted there - Diagrammatic representation of Password Encryption >>

Liked the article? You may like to Subscribe to this blog for regular updates. You may also like to follow the blog to manage the bookmark easily and to tell the world that you enjoy GeekExplains. You can find the 'Followers' widget in the rightmost sidebar.

Pictorial rep of Client-side password encryption

This article is a part #2 of the article 'How does Password Encryption work in real world?'. If you have landed directly on this article then you would probably like to go through the first part of the article - Complete working of Password Encryption >>

Diagrammatic rep of how password encryption works for SBI Net Banking

#1: typing the Login URL of Online SBI will get you a web page which will have a JS function named encrypt() and an applet named encryptApplet. Find below the code-snippet as obtained from the Page Source of the Login page:


#2: Once you enter the password and click 'Login' button, the entered password first goes through the basic checks (minimum and maximum length) and if it passes that then it is encrypted by the applet before it's sent to the web/app server. Notice that the public key id is set as it travels to the server as a hidden key which is where used for identifying the corresponding private key id for decrypting the password. This makes the web app implement a different public/private key combo for every new request. Find below the relevant code-snippets doing these tasks:



#3: see the change in password length before and after pressing 'Login' button which actually shows that the encryption is taking place before the request being sent to the server. Notice that the password is encrypted when the 'Login' button is clicked (it turns grey when clicked). Clicking the button first performs the basic validations, then the password encryption, and finally it submits the request to the web/app server.


#4: see below a snapshot showing how an external JavaScript code looks like when opened in the browser versus how an applet JAR file opened in browser looks like. Evidently JavaScript code is easily visible as it's plain text. Whereas, opening up the downloaded JAR/Bytecodes will mostly have special characters and you got to try hard to get hold of the source, if at all that's possible:


Note: On the face of it (by going through the HTML source of the Login page), this is how the password encryption process seems to work for SBI, but this is as per my understanding and of course I can't claim about the actual process. Anyway, the intention here was just to discuss a typical Client-side encryption process.

Liked the article? You may like to Subscribe to this blog for regular updates. You may also like to follow the blog to manage the bookmark easily and to tell the world that you enjoy GeekExplains. You can find the 'Followers' widget in the rightmost sidebar.

Constructor Injection: how it works? Impl using Pico

Implementation of Constructor Injection using Pico. How CI works?

Constructor Injection is mainly used by a highly embeddable, lightweight, and full-service IoC Container named PicoContainer. Should you need to refresh your understanding of DI and its types, go through this article - Dependency Injection & its types>>

Let's see how the Constructor Injection phenomenon works. We will take one example scenario and will implement that using PicoContainer. First we'll see the source code and subsequently we'll discuss how the various pieces of the code fit together and how actually do they work.

Example Scenario: Suppose we have a requirement of displaying bank account details which might come from various sources. The requirement is fairy simple and to implement it we can easily think of having two interfaces, one which would take care of the presentation of the account details and the other would capture the details. Say for example we have named these interfaces as 'DisplayAccount' and 'BankAccount'.

interface DisplayAccount{
void displayAccountDetails(BankAccount bankAccount);
}

interface BankAccount{
Map getAccountDetails(long accountNumber);
}

Source Code: How to code Constructor Injection using PicoContainer?

Since the injection is handled by the constructor and hence it should have the declaration of all the objects that it might depend on.

class DisplayAccountImpl implements DisplayAccount{

private BankAccount bankAccount;
...

public DisplayAccountImpl(BankAccount bankAccount){

 this.bankAccount = bankAccount;
}

public void displayAccountDetails(){

 /*... display the details as required ...*/
 Map acDetails = bankAccount.getAccountDetails();
 ...
}
...
}

class BankAccountImpl implements BankAccount{

private long accountNumber;
private Map acDetails;
...
...

public BankAccountImpl(long accountNumber){

 this.accountNumber = accountNumber;
}

public Map getAccountDetails(){

 Map acDetails = new HashMap();

 /*... get the details maybe from a DB...*/
 /*... form a Map object out of the details ...*/     
 ...
 ...
 ...

return acDetails;
}
...
}

Having these two classes well in place, we can now use PicoContainer (or any other IoC Container supporting Constructor Injection such as Spring) to implement the Constructor Injection.

class TestConstructorInjectionWithPico{

private MutablePicoContainer getConfiguredContainer() {

        /*... Step #1: get a default Container instance ...*/
 MutablePicoContainer picoContainer = new DefaultPicoContainer();

 /*... Step #2: populate the Container parameters ...*/
 /*... we need to make the parameter value(s) available in this scope ...*/
 ConstantParameter constantParameter1 = new ConstantParameter(accountNumber);
 ...

        Parameter[] parametersForBankAccountImpl =  {constantParameter1, ...};


 /*... Step #3: registering the components with the Container ...*/
       picoContainer.registerComponentImplementation(BankAccount.class, BankAccountImpl.class, requiredParameters);
        pico.registerComponentImplementation(DisplayAccountImpl.class);

 /*... Step #4: return the configured Container instance ...*/
       return picoContainer;
}

...

public static void main(String[] args){

 /*... get an instance of configured Container ...*/
 MutablePicoContainer picoContainer = getConfiguredContainer();

 /*... get the components having the injected dependencies ...*/
 DisplayAccountImpl displayAccountImpl = (DisplayAccountImpl) picoContainer.getComponentInstance(DisplayAccountImpl.class);

 /*... use ready-to-be used components: using for display ac details ...*/
 displayAccountImpl.displayAccountDetails();
}
}

Let's try to understand how the above code-segments work. The sample class and interface definitions are fairly simple and straightforward. Coming directly to the getConfiguredContainer method where we are creating an instance of the PicoContainer and configuring the instance. PicoContainer is actually an interface having MutablePicoContainer as one of its various sub-interfaces. The MutablePicoContainer interface has many variants of the method registerComponentImplementation. The two variants which we have used have their signatures as:

• ComponentAdapter registerComponentImplementation(Object componentKey, Class componentImplementation, Parameter[] parameters) throws PicoRegistrationException;
• ComponentAdapter registerComponentImplementation(Class componentImplementation) throws PicoRegistrationException;

Here the 'componentKey' is the unique Key within the Container used to identify the component and 'componentImplementation' is the component's implementation class which should of course be a concrete class as otherwise the Container won't be able to create an object of it. The third parameter 'parameters' of type Parameter is an array and it serves as the hint about what all parameters the constructor of the implementing class would require. Depending upon the implementation of the Container, one or more of these hints may be ignored.

Second variant is internally translated into a call of this variant 'registerComponentImplementation(Object componentKey, Class componentImplementation)' which means the same type is used as the key to register the component with the Container. Another point to note here is that we didn't require to pass the parameter of type 'BankAccount' as it's already registered and the Container will pick that automatically. Moreover, as mentioned above the parameters passed serve just as hints and how many of them are treated (or ignored) by the Container depends on the particular implementation of the Container.

Once we have got the configured PicoContainer instance then we have used the getComponentInstance method (this method is a member of the PicoContainer interface and its signature is 'Object getComponentInstance(Object componentKey);' and it finds the component registered with the specified key) to fetch the well-built instances of the classes having all their dependencies injected into them. Notice that we have used 'DisplayAccountImpl.class' to fetch the instance of type 'DisplayAccountImpl' as we registered the instance with the same key.

Now we can use those instances as per the application requirements - in our case we are using the instance to call a public method named 'displayAccountDetails'.

The code-snippets listed above is just to give you an idea of how can we actually use a IoC Container to exploit the Constructor Injection feature. I've not compiled or tested the code. You may probably need to make some changes, but I suppose most of them would be cosmetic in nature.

Liked the article? You may like to Subscribe to this blog for regular updates. You may also like to follow the blog to manage the bookmark easily and to tell the world that you enjoy GeekExplains. You can find the 'Followers' widget in the rightmost sidebar.

Spring: Beans, Container, Metadata, IoC Instantiation

Spring fwk: Beans, Containers, Configuration Metadata, IoC Instantiation

Beans - what are they and why do we call them beans?

Any object in your Spring application which is instantiated, assembled, and otherwise managed by the Spring IoC Container is called a Bean. Nothing special about these objects, except that the configuration metadata of the Spring framework contains details of these objects as how can they be instantiated and managed by the Spring IoC Container otherwise these objects are just like any other object used by your application.

Such objects were called Beans as the Spring framework was designed and developed in response to counter-attack the complexities of the Enterprise JavaBeans (EJB).

The Spring IoC Container

The central interface of the Spring IoC Container is BeanFactory, which is responsible for instantiating the application objects, configuring such objects, and managing the dependencies among these objects.

There are a number of implementations of this interface available today with one of the most popular being the XmlBeanFactory which allows the developers to specify the details of the object instantiation and their inter-dependencies in an XML File and the XmlBeanFactory takes care of interpreting the configuration XML metadata and subsequently providing a fully configured application taking the heavy load of object instantiation and inter-object dependency management off from the developers.

Configuration Metadata

This covers the details of object instantiation details of the application and also the details about inter-object dependencies. Depending on the form in which the metadata is supplied, the Spring framework would be required to use the corresponding type of IoC Container. The simplest and most popular form in which the metadata is supplied to the Spring framework is a simple and intuitive XML format. Evidently the XmlBeanFactory implementation of the BeanFactory interface is used as the Spring IoC Container in this case.

The other forms in which the configuration metadata can be supplied to the Spring framework are: using the Java Properties format, using Spring's public APIs to specify the metadata programmatically. Below is an image (taken from SpringFramework) which shows how all these pieces (POJOs, Config Metadata, and Container) magically fit together to produce a fully configured system ready to be used.

Instantiating the Spring IoC Container

Not always you would be required to instantiate a Spring IoC Container explicitly like in case of a Web Application some 8 lines of boilerplate code written in the Web Descriptor file named web.xml will do that for us. Otherwise we would be required to write just a few lines explicitly to instantiate the Container.

Configuration Metadata files are passed to the BeanFactory or ApplicationContext constructors in form of objects of type Resource which encapsulates the metadata details as obtained from external resources like the local file system, from the Java CLASSPATH, etc.

Few examples of Container instantiation are:

Resource resource = new FileSystemResource("beans.xml");
BeanFactory beanFactory = new XmlBeanfactory(resource);

or

ClassPathResource classPathResource = new ClassPathResource("beans.xml");
BeanFactory beanFactory = new XmlBeanFactory(classPathResource);

or

String[] appContextResorce = new String[] {"applicationContext.xml", "applicationContext-part2.xml"};
ApplicationContext applicationContext = new ClassPathXmlApplicationContext(appContextResource);
BeanFactory beanFactory = (BeanFactory)applicationContext;

Which all beans/objects will have their configuration details in the Spring configuration metadata?

Well... the configuration metadata needs to have the definition of at least one bean which the container would manage. How many other bean definitions would be captured by the configuration metadata, is something which depends upon your application requirements. Spring framework supports enormous possibilities and hence it's probably limited to your application requirements and your imagination.

Some of the common entries in the configuration metadata include service layer objects, DAOs, presentation layer objects such as Struts Action instances, infrastructure objects such as Hibernate SessionFactory instances, JMS Queue references, etc.

Liked the article? You may like to Subscribe to this blog for regular updates. You may also like to follow the blog to manage the bookmark easily and to tell the world that you enjoy GeekExplains. You can find the 'Followers' widget in the rightmost sidebar.

Spring: Inversion of Control, Dependency Injection

Spring IoC - Inversion of Control. DI - Dependency Injection.

Spring IoC - Inversion of Control

IoC pattern is defined as "A software design pattern and set of associated programming techniques in which the flow of control of a system is inverted in comparison to the traditional interaction mode." which means instead of the application calling the framework for services (as is the case with traditional patterns) it's the framework which calls the components as specified by the application.

DI - Dependency Injection

As you can deduce from the above para that IoC is quite generic in nature and perhaps not used by the Spring framework in entirety. The aspect of IoC used by the Spring framework is usually termed as DI or Dependency Injection as it focuses on injection of dependencies (required resources) into the dependent components at run time.

There are three main ways through which dependencies are injected into the dependent components. All these forms are supported in Spring either directly or indirectly. These forms are:

• Constructor Injection - as the name suggests, in this form the dependencies are injected using a constructor and hence the constructor needs to have all the dependencies (either scalar values or object references) declared into it. Though, this form of DI is directly supported by the Spring IoC Container. But, Constructor Injection is mainly used by a highly embeddable, lightweight, and full-service IoC Container named PicoContainer. Read more about how do we actually code Constructor Injection using Pico in this article - Implementing CI using Pico. How CI works?
  
• Setter/Mutator Injection - this form of DI uses the setter methods (also known as mutators) to inject the dependencies into the dependent components. Evidently all the dependent objects will have setter methods in their respective classes which would eventually be used by the Spring IoC container. This form of DI is also directly supported by Spring IoC Container. Though Spring framework supports both forms of DI namely the Constructor Injection and the Setter/Mutator Injection directly, but the IoC Container prefers the latter over the first.
• Interface Injection - in this case any implementation of the interface can be injected and hence it's relatively complex than the other two where the objects of specified classes are injected. It's not supported directly by the Spring IoC Container. Interface Injection is used by The Apache Avalon. In 2004 Apache Avalon project closed after growing into several sub-projects including Excalibur, Loom, Metro, and Castle.
  

Setter vs Constructor Injection. Why Spring prefers the former?

• Hard to manage a large number of constructor arguments: Spring framework prefers Setter/Mutator Injection over Constructor Injection because a large number of constructor arguments can become really hard to manage especially when many of them are optional. The Spring IoC Container will of course not have any such problem with Setter Injection type.
• Re-injection or Amendment: One important thing to note here is that in case of Constructor Injection the dependencies are handed over at the time of object instantiation of the dependent objects whereas in case of Setter/Mutator Injection the dependencies are injected after the dependent object has already been created. Now if a re-injection or re-configuration of a dependent object is required , it can be easily done by calling the respective Setters in case of Setter Injection, but not the same in case of the Constructor Injection. So, should you need any re-configuration of the dependent objects, you would be better off with Setter Injection.

Why at all do we have Constructor Injection then? Any real need?

Well... by saying that Spring IoC prefers Setter/Mutator Injection you should not deduce that the Constructor Injection has no real uses. Constructor Injection has its own benefit(s). This form of injection is preferred by the purists for the reason that the dependent objects are always handed over in a completely initialized state and no less than that. Right?

The obvious disadvantage in this case is that the dependent object becomes less flexible and hence any re-configuration becomes difficult.

How has the IoC pattern (or DI) been implemented in Spring framework?

Spring framework has two packages supporting this core functionality. These packages are: org.springframework.beans and org.springframework.context and the two interfaces which are the building blocks of Spring IoC are: BeanFactory and ApplicationContext.

ApplicationContext interface is actually a sub-interface of the BeanFactory interface. The top level interface, BeanFactory takes care of supporting an advanced configuration mechanism to manage objects of any type. ApplicationContext interface on the other hand is responsible for functionalities like integration to Spring AOP, message resource handling, event prorogation, and other enterprise-centric functionalities.

There are other specialized sub-interfaces as well which are targeted to add the specific set of functionalities on top of the the functionalities provided by ApplicationContext and BeanFactory interfaces. One such example is WebApplicationContext which is sub-interface of the ApplicationContext interafce and is responsible for providing enterprise-centric functionalities to be used in Web Applications.

Liked the article? You may like to Subscribe to this blog for regular updates. You may also like to follow the blog to manage the bookmark easily and to tell the world that you enjoy GeekExplains. You can find the 'Followers' widget in the rightmost sidebar.

Session impl of a Web App served by multiple JVMs

Session implementation of a Web App spread on multiple JVMs/Servers

Should you need a refreshed understanding of what HTTP Sessions are and why are they actually needed, please refer to the article - Need for Session Tracking and Session Tracking Mechanism >>

All the three techniques of HTTP session maintenance namely Cookies, URL Rewriting, and Hidden Fields have quite a few limitations. Some of them are:

• Support for small volume of data - especially in case of URL Rewriting as can be easily understood.
• Support for simple character data only - URLs are made up of character strings.
• Vulnerable to attacks - since all the data is visible to the clients hence attackers may get hold of the data and change them in between before the request reaches the server.
• Developer needs to manage the session - the entire responsibility of maintaining the session (when to use the existing and when to create a new, ensuring uniqueness, consistent client-session integration, etc.) comes to the developer which obviously adds to the complexity of the overall application development.

How can we manage the session more effectively and more easily?

Using the HttpSession interface of the The Java Servlet Specification is one of the possible ways of maintaining the sessions more effectively and far more easily. All the J2EE compliant containers have the implementation of the underlying classes and the user simply need to call the APIs to use the services. For example, calling getSession() will return the session for the corresponding client if it already exists otherwise it will create a new session. Similarly, we can use the APIs putAttribute(String attrName, Object attrValue) and getAttribute(String attrName) to save the attribute values to the session OR to get them from the session, respectively. Here the important point to note is that we can save a value of type Object (i.e., effectively any Data Type supported by Java) which means we are no more limited to the character based name-value pairs. Almost all of the above mentioned limitations either get eliminated OR at least get reduced to a considerable extent by using this approach. Right?

Managing the Session Manager of your Application Server

Almost all the Application Servers come with an integrated Session Manager which facilitates an even easier way of configuring the session handling for your web application by facilitating the session configuration via simple GUI screens. You may refer to your Web/App Server manual for more details. Some common taks which we can do via App Server Session Manager are:

• Enable Sessions - if it's not enabled then the runtime system will throw an exception if the servlet tries to create one (and of course no existing session would be returned as there wouln't be any existing...right?). Why at all do we need this configuration? Well... because not all your web applications require Session Support and for them it's wiser to disable this feature to avoid the extra overhead which the runtime system incurs for session management.
• Enable Cookies - Ohh, back to Cookies again? Yeah... the reason why we still need cookies is because we need the client to maintain the unique Session ID of the session object created and maintained on the server. But, now we are left with storing just a single ID either in the Cookies or via URL Rewriting and not the entire session information. That definitely makes a web developer's life easier.
• Enable URL Rewriting - Again for the same purpose of passing the unique Session ID to and from the individual clients. This of course requires a piece of code to be written as the Session ID needs to be added to the URL programmatically and hence this approach is not supported for static pages (plain HTML pages). How to overcome this limitation? Pretty simple... convert all the plain HTML pages to JSP pages as every HTML page is a valid JSP page so this should not be a problem. You would of course not like to convert your static HTML pages to Servlets :-) You of course need to encode the URL in these converted JSP pages as well. Any JSP page or Servlet which doesn't do the URL encoding will not be able to access the session if it relies on URL Rewriting approach. Beware of this!
• Enable Persistent Sessions - sessions are maintained in the Application/Web Server memory and hence the data will be lost if the server is shut down. If you're interested in maintaining the session data then you need to store it in some database or in some other persistent medium. Almost all the Application Servers support this feature and you just need to specify the Data Source which would be used to store the session data.

What will happen if both 'Enable Cookies' and Enable URL Rewriting' are enabled?

If both these features are selected then the approach which would actually be used to maintain the session will depend upon the browser setting (to see if it accepts cookies or not) and also on the fact whether Servlet (in use) is using URL encoding or not. Below are the two possible cases where the session will be maintained if both 'Enable Cookies' and 'Enable URL Rewriting' are enabled:

• Servlet has URL Encoding code - if this is the case then URL Rewriting approach will be used irrespective of whether Cookies are enabled or not. Even if the browser is set to accept the Cookies.
• No URL Encoding code in Servlet and Browser accepting Cookies - cookies approach will be followed to maintain the sessions.

Implementing HTTP sessions for Web Applications spread across multiple physical servers (or JVMs)

Say your Web Application is spread across multiple physical servers (or may be on the same server, but using different JVMs which is of course a rarity) which might have been done to balance the load of your application OR may be the requirement is such that separate physical servers is a need than a luxury. Whatever be the case, in such a scenario if a user say log into one of the machines (JVMs to be specific) and then s/he is taken to some other Servlet/JSP running on some other server (JVM) to fulfill the client request. Now if that Servlet/JSP also requires authentication (which it would in most of the practical scenarios) then the user would be prompted to enter his/her credentials once again which s/he would of course not like. It's the applications responsibility to transfer the credentials from one server (JVM) to another)... right?

Using Persistent Sessions, we can easily achieve a solution to this complex problem. This approach requires the session to be saved in a data source which can easily be accessed by any of the scattered servers (JVMs) and the client gets a feeling that his application is virtually running on a single server (JVM). It's a better practice to have a completely separate data Source just for the purpose of session persistence and not to integrate session data with the application data source(s) for the obvious reason of making the overall implementation loosely coupled and hence better maintainable and more scalable.

Though the Session Manager discussed above behaves more or less the same for all the popular Application Servers like BEA WebLogic, IBM WebSphere, Oracle Application Server, etc., but the article is based on IBM WebSphere Application Server.

References: Maintaining Session Data with WebSphere, The WebSphere InfoCenter

Liked the article? You may like to Subscribe to this blog for regular updates. You may also like to follow the blog to manage the bookmark easily and to tell the world that you enjoy GeekExplains. You can find the 'Followers' widget in the rightmost sidebar.

Creating documents directly from emails in GMail

Creating documents straight out of your emails in GMail

If you have not noticed (or used) this feature so far then probably you are missing a really nice feature of GMail Labs. The feature was introduced to the entire world at the Official GMail Blog on Dec 16, 2008.

Okay, what's this used for? As the name might suggest, it's for creating documents straightaway from your emails. So, if you think any of your email conversations in your GMail a/c are needed to be saved, edited, and/or shared as a document then this feature will make your life easier. You just need to click a link named 'Create a document' which appears to the right of your opened email along with 'New window', 'Print all', 'Expand all', and 'Forward all' links.

This feature is not enabled by default and you need to turn it on by selcting "Enable" against "Create a document" and subsequently by clicking 'Save Changes' on the page Settings -> Labs. Find below a screenshot showing all these steps in the required order.


If you were to create a blank document then you need to press 'G' and while this key is pressed you just need to press 'W'. Make sure that the Keyboard Shortcuts are ON for this to work.

The official GMail Blog post which introduces and talks in detail about the feature can be found here - GMail Labs: Create a document. The need for this feature and the potential benefits of using this feature are summarized by the official blog post as below:

"More than once, I've had a conversation over email and later realized that the information contained in the messages would make a great starting point for a document. So I built an experimental feature for Gmail Labs that does just that: with one simple click, "Create a document" converts an email into a Google Docs document.

No more copying and pasting the text from your email -- just open the message you wish to convert, click the "Create a document" link on the right side of the page, and voila, you have a brand new document which you can then modify and share!"

Enjoy the cool GMail Labs feature which might eventually help you by saving your time in your sincere efforts to Go Green by making/keeping/managing as many documents online as possible.