JavaMail : Altering the From field

There are 2 APIs on the MimeMessage Object, sentSender and setFrom. If you are thinking that the Sender address would go in to the From Address field and using the setAddress field to set it, that would not work. It only sets the RFC 822 "Sender" header field. It does not alter the "From" Header which is used to show the From Address on the email. The code you should be using would look like the following

 MimeMessage message = new MimeMessage(session);

 message.setFrom(new InternetAddress("support@mydomain.com"));
 message.setSubject(subject);
 message.setContent(body, "text/html");
 message.setRecipient(Message.RecipientType.TO, new InternetAddress(recipients));

 Transport.send(message);

Going Mobile for your enterprise? What to consider?

There is a lot of buzz out there. Every enterprise wants a presence on the hand held device and rightly so. We have enough proof that it is the future. There are a plethora of platforms to run on, all of them distinct and to an extent proprietary. It is always a tough choice for the architects to choose what are the steps to follow and what to target. The following are some of my experiences and learning on this.

The Mobile Web

For any organization which is venturing out to the mobile platform, the first and the easiest option to have a presence is the Mobile Web. Most smart phones come with full fledged HTML browsers capable of running JavaScript and even flash. It is very quick to do so as all you need is to make a customized UI for fitting in the smaller screen sizes. (More on what to consider on my earlier post here)

The advantages are many,

• The time to market and cost is minimal.
• You target all or most of the devices in one shot.
• You can reuse your entire back-end infrastructure as it is.
• You could always have 2 versions of your site - one for high-end devices and other for lower end and redirect traffic according to the User Agent headers.
• It helps to understand your user base. (Explained in next section)

Understand your user base

If you look at the web there is enough data available on the prominent platforms, which is most popular today, which one is growing faster etc etc. I would think that as architects we look at our specific enterprises user base before jumping in to conclusions.

For following points to be noted regarding developing native apps:

• It is practically impossible for enterprises to target all platforms.
• Also generic solutions like J2ME (which can run on all platforms having the run time installed) have been found to be not as powerful in exploiting the phone's specific features in a lot of platforms. So at times, your application loses the coolness it could have had by developing on the native SDK.

Which platform should I target?

I believe the answer lies in knowing your user base. And that is where your mobile website helps. By capturing the analytics on your mobile website, you could easily come up with the required data for the most prominent platforms in your user base. This is a fairly quick exercise and the patterns should be clear in a couple of months if you have enough traffic on your mobile web site.

It makes sense to drive your decision based on data and customize your solutions to your specific user base.

Exposing the Server Code of your Web application as REST Services using Jersey

I am sure you might have scenarios where you have written a Web Application and modeled your server components as POJO based service methods. You would have a controller layer (Struts/Stripes/Spring MVC/Servlet) to take care of rendering your Web pages as well as responding to AJAX calls.

Now comes the need for developing a Mobile app for your application. Invariably the first and the most common thought would be to expose the POJO methods as REST Services on the Web and access them from the device. JAX-RS (Jersey JSR311) is a great means of very easily converting your POJO methods to REST Services. One another option is to use the controller layer to expose the REST services (Possible with most of the web frameworks), but I am dealing specifically with Jersey on this blog

So assuming you are going to use a Tomcat based deployment, the following are the steps you would perform.

1) Add Jersey JAR files to your WEB-INF/lib
2) Add a servlet mapping for the Jersey's Servlet Container as shown below

    <servlet>
        <servlet-name>JerseyServlet</servlet-name>
        <servlet-class>
            com.sun.jersey.spi.container.servlet.ServletContainer
        </servlet-class>
        <load-on-startup>1</load-on-startup>
    </servlet>
    <servlet-mapping>
           <servlet-name>JerseyServlet</servlet-name>
           <url-pattern>/*</url-pattern>
    </servlet-mapping>

3) Annotate your POJO with the @Path and @GET/@POST etc annotations - A sample can be seen in Sun's site

Trouble starts now

ALL is Well till you run Jersey alone. The moment I merge this content to my Original Web application and add the web.xml, all my Other Servlet Controllers do not work. Even cannot access static files like index.html or images

On carefully looking at it, the problem is definitely due to the Servlet mapping. Now everything goes through the Jersey Container, due to this mapping

<url-pattern>/*</url-pattern>

OK, now that is simple, just change the mapping to something like this

<url-pattern>/api/*</url-pattern>

Now your Jersey mapping changes to the Sub Context and the following url works http://localhost:8080/RestServiceProject/api/helloworld - assuming that the annotation is defined like this @Path("/helloworld")

Another approach for solving the problem is to have a servlet filter definition for Jersey and that approach is explained here

I have configured Jersey along with my web application with the different servlet path approach and that seems to work good so far.

Why Hibernate Session Management needs careful analysis and implementation

What is the most complicated part in Hibernate? I would think it is the session handling. It is quite a confusing topic with a lot of material everywhere, but a lot of them confusing at the best.

I have been Stuggling with the session management for a little time now, with some hibernate errors thrown in every now and then like the ones below

 - Illegal attempt to associate a collection with two open sessions
 - a different object with the same identifier value was already associated with the session
 - LazyInitializationException: could not initialize proxy - no Session Data Access.
 - Many more -----

PHEW !!!.

I decided to take a lot more in-depth view of session handling and after reading some of the articles and books by Gavin King, finally arrived at some conclusions. Then I wrote test implementations for all the patterns and analyzed their behavior. So far the experiments has given me a good stable implementation of session handling so wanted to write a few words about what I found during the my experiments with hibernate.

The EntityManager/Persistence Context (Read Session in Hibernate)

The JPA entity manager is nothing but the session in pure Hibernate terms. I am not going to make an attempt to explain what the session does, but the following features are atmost important.

- Session is the Level 1 cache of Hibernate
- It is a cache of managed entity instances
- It defines the scope of a POJO's persistent Identity

Why Session management is so critical ?

Hibernate believes in Lazy loading (and rightly so). It is the default behavior of the O/R mapper and it tries to defer the loading of a associated Object/Collection till the last moment it could afford. This has the following implications

- If you have many-to-one or many-to-many relationships defined, hibernate will to proxy all of them when the base object is fetched. This means that all the associated objects are not populated by default (Unless you force it to be loaded by a lazy="false" on your XML definition) . It holds only a reference to the IDs of the associated objects making the collection (There are some exceptions to this as to what API was called to get the entity in to persistent state Please see documentation of get() and load() methods)

- The session has to be alive for Hibernate to intialize any of the associated objects it proxied during the initial fetch. Which means that you would get a "LazyInitializationException" if the session is closed and then you call "Entity.getAssociatedCollection()"

Patterns in session management and their applications

session-per-operation:

This is the simplest one of all to understand - In this pattern the session spans only a single operation from the database. The sample code will look like the following

Session sess = factory.openSession();
Transaction tx;
try {
     tx = sess.beginTransaction();
    
     //do a single DB operation
     ...
     tx.commit();
}
catch (Exception e) {
     if (tx!=null)
    tx.rollback();
     throw e;
}
finally {
     sess.close();
}

Though very simple in its implementation, this approach suffers from some serious drawbacks. It absolutely does not use any of Hibernate's lazy loading or L1 cache capabilities. It will force you to agressively load almost all the associated objects on the tree. Mostly this is an anti-pattern and should be avoided as far as possible.

session-per-request:

This is an extension of the session-per-operation pattern, In this pattern the session spans multiple related operations from the database. This approach works prertty good for Client Server applications. the session is closed immediately after the db operation is completed. A sample of this code is shown below.

Session sess = factory.openSession(); 
Transaction tx;
try {
     tx = sess.beginTransaction();
     
     //do multiple related DB operations, Debit account A, Credit Account B etc.
        
     ...
     tx.commit();
}
catch (Exception e) {
     if (tx!=null) 
    tx.rollback();
     throw e;
}
finally {
     sess.close();
}

This pattern though betters the Session-per-operation, is still sub optimal for Web applications where a interaction with the user can span multiple db operations and round trips between Client and Server. The same logic is extended in the "session-per-request-with-detached-objects" pattern to derive some more use of the objects loaded.

session-per-request-with-detached-objects:

Session per request with detached objects extends the above pattern with the promise of "re attaching" the entity back on to a new session when the user has completed modifications on the same. This is a really powerful feature of Hibernate. This really means that you could use your domain POJOs as carriers of information to other layers of the application in a "detached" form. Hibernate makes sure that there is no DB connection maintained durng the think time and also makes sure that the object is re attached to the new session when it is sent back. Amazing and nice for a web app !

Now lets examine this in a little more detail:

As in the session-per-request pattern, the session-per-request-with-detached-objects pattern also uses the session for the duration of multiple related db operations. This pattern relies on implementing a partly "custom aggressive fetch" strategy. As the session gets closed at the end of the DB operations, the code following cannot be relying on the session to initialize the proxied data on the Entity. This means that the designer has to carefully decide what is the granularity of the fetch needed for the "conversation" which is currently taking place.

There are multiple ways to control the depth of the fetch tree. One option is to make the lazy="false" setting on the "entity.hbm.xml" file for the required associations. But this is not a great option unless you are absolutely sure that this entity needs to be always fetched with the associations. A designer has to be extremely careful about setting this option as the associated tree could grow exponentially and could strangle your machine to death.

The better way I have seen is to programatically control the depth of the fetch by using the "initialize" method of the Hibernate Class. In this approach, the code fetching the Entity looks like the following

Transaction tx = null;
long entityIdentifier = 1234;
try
{
    Session hiberSession = HibernateUtil.currentSession();        
    tx = hiberSession.beginTransaction();

    Entity entity = (Entity) hiberSession.get(Entity.class, entityIdentifier);
            
    // initialize the mandatory collections 
            
    Hibernate.initialize(entity.getAttributeValueSet()); //Attribute value many-to many mapping - associated collection
    Hibernate.initialize(entity.getCategories()); //Product categories for this entity - associated collection
                    
            
    return entity;
}
catch (Exception e) 
{
    tx.rollback();
    return null; // OR throw this Error ----- 
}
finally
{
    HibernateUtil.closeSession();
} 

Re attaching the "Detached" Objects:

Once the session is closed after the fetch, the persistent object enters a "detached" state. A "detached" object can be made persistent again by re attaching it to a session. The easiest approach to be followed is to call the "Session.update(Entity)". Hibernate would take care of attaching the object to the current session and make it persistent again. Another option is to use the Session.merge(Entity). You have to be aware that there are some fundamental differences between the "update" and the "merge" which is explained in this document:

Key observations about the pattern:

 - It enables you to use the domain objects as transport objects as they can be detached from their persistent state
 - It forces you to fetch some of the data eagerly as the session is closed before they are accessed
 - Fine grained control of the depth of fetch is possible using programmatic constructs
 - This is suited for applications which use a lot of AJAX calls due to some reasons I have explained in the section below.

session-per-conversation:

The session per conversation pattern leverages the "extension" of the life of a session to the length of a "conversation". In a N-tier web application, the "conversation" can be often longer than the normal single DB operation. There could be considerable think time between the user actions, and the session is kept alive till such time that one complete conversation is completed.

The key advantage of this pattern is that it makes the best use of "lazy loading". The loading of all associations are delayed till such time that it becomes absolutely necessary to load them. This ideally should do away with a lot of the performance overheads with the "eager" loading of associations. The typical way of closing the session in this approach is to write a Servlet Filter where the session is closed just before the view is refreshed. A sample of such a Filter is given below. This filter can be plugged into only those pages which need to close the session when the view is rendered

public class SessionFilter implements Filter
{
    private FilterConfig filterConfig;
    private static Set<String> publicUrls = new HashSet<String>();
    
    //initializer block.
    static 
    {
         //Add urls which demarcate the boundaries of your conversation
         //publicUrls.add("CreateOffer.action");
         
    }    

    @Override
    public void destroy() 
    {
        // TODO Auto-generated method stub
        
    }

    @Override
    public void doFilter(ServletRequest request, ServletResponse response,
            FilterChain chain) throws IOException, ServletException 
    {
        try {
            chain.doFilter (request, response);
        }
        catch(Exception e) {
            // handle!
        }
        finally {
            HibernateUtil.closeSession();
        }
        
    }

    @Override
    public void init(FilterConfig arg0) throws ServletException 
    {
        // TODO Auto-generated method stub
        
    }
    
    protected boolean isPublicResource(HttpServletRequest request) 
    {
        String resource = request.getServletPath();
        return publicUrls.contains(request.getServletPath());
                
    }
}

One of the key challenges for the designer using this pattern is to clearly identify all "conversation" boundaries. Another problem is that with Web 2.0 and the number of AJAX based applications, the boundaries of the conversation are often blurred. Or rather, sometimes, it is really difficult to identify the boundaries and sometimes it is very easy to do a wrong assessment of the boundary. The pitfall of not able to identify the boundary correctly and failing to insert the filter, can cause some really confusing Errors which are tougher to debug. Sometimes it's easier to go with the detached-objects design in applications with heavy AJAX based transactions.

SOA, Web Services Basics and Advanced concepts

Conducted some trainings recently on SOA and Web Services. One on basic concepts and another one on some advanced concepts. The slides from the training are on SlideShare and the links are below.

SOA Basics Presentation

SOA Advanced Presentation

Google Maps On Android

This one is a really amazing article on this subject. Helped me a lot with some of the marker apps we were trying out. http://mobiforge.com/developing/story/using-google-maps-android