Whats happening in web service world?

Web service is being a very cool mechanism to make heterogeneous systems to talk to each other. It is really powerful and so its being a hit. Since this technology is widely used, its common to find tons of evolving concepts in and around web service. Web service makes possible to send SOAP messages over any transport protocol. Heterogeneous system talk to each other by exchanging those SOAP based XML documents. JAX-RPC based web services were mainly focused on calling remote procedures using SOAP over http. Slowly people found the real power of web service is not really to call remote procedures but to exchange certain XML documents over http/SMTP/TCP etc. Hence the newer specification is called as JAX-WS which supports - REST based web service, request-response based services, asynchronous services etc.
But there are lot of improvements are happening around web service. For example, web service gateway - this technique helps enterprise to expose their internal web service to the external world. Web Service aggregation - this helps to aggregate many number of smaller web services to one bigger one. SOAP OVER JSMS - this is also very interesting as HTTP being unreliable transport mechanism, if B2B communication is happening where reliability is necessary, use JMS instead of HTTP as transport mechanism of the SOAP messages. JMS will make sure that the SOAP messages are sent to the other end (it will persist the SOAP message and if communication fails, it will resend the message again).
There is another interesting JSR called - WSRP web service for remote portlets. This allows one portal server to consume local portlets as well as remote portlets through web services.
I am really thrilled to see all of these developments around web services.

Hibernate - great tool - greater responsibility

I really like the movie "Spiderman" and the way Peter Parker was told - "With Great Power comes Great Responsibility". Similarly Hibernate is a great tool. It has awesome capabilities in transforming "Relational Database Tables" to "Set of related objects". But we, the developers need to be responsible of how to use this tool effectively. Performance of the application can become worse if we are not careful enough with different options available in Hibernate. Here are the list of items which I found are useful to know while developing complex database oriented applications.

1) The famous n+1 problem - Hibernate usually fetches the associations lazily (lazy = true is by default). For example, if one Node can generate any number of events. In this case, hibernate will load the events for the Node only if we need the events. This is a very nice feature otherwise if you ask to load all the nodes , hibernate would have loaded all nodes and its associated events (the complete db) in the memory which will lead to "out of memory" error if the events are really large in number. So lazy loading is really a nice feature. But if you have to traverse all the nodes and process all the events - it will fire n+1 (where n is the number of nodes) to the database leading it to inefficient.
More efficient approach could be to use "batch size" option of hibernate which will make the db round trips from n+1 to n/batch_size + 1.
Another option could be to use outer-join which will fetch all the associated data using an database outer join.
Or else probably better approach is to use FetchMode.EAGER at the runtime (not in the xml file) which will load all the associated objects at once.

2) the lazy fetching can cause another problem with MVC architecture. In our case, the events of the nodes will be loaded lazily, but if we are using one DAO layer which will open the hibernate session, load the node and send that node object to the JSP file, when JSP will try to access the events of the node, it will throw one lazyinitialization exception. There are many ways to solve it and one of the most useful way is to use - Filters or one can load the association eagerly.

Singleton is not really a singleton?

Singleton design pattern is one of the oldest pattern which I learn in college. People like me who have migrated to java world from C++ world finds it hard to digest that if we are not very clear, there can be cases when a singleton java class can have more than one instance. There could be multiple reason for this, details can be found under "Sun Developer Site". One of the reason which C++ people might find difficult is that - if one application uses two different class loaders, then you will get two instances of the singleton class (Each class loader represents one unique namespace, so two classes even if they are the same, if gets loaded by two different class loaders, become two distinct instances). If we think about it in Servlet world, the Servlet container decides when to load the singleton class and when to destroy it. If we are not very clear about the way servlet engine is loading the servlet classes, we might end up having two different instances of the singleton class.

Httpsession Vs Stateful Session Bean

This is an interesting topic and many people have talked about it and wrote in internet. As far as I understood is that - httpsession is an wonderful mechanism to track client's state (you can even get the callback functionality through HttpSessionBindingListener), its easy to use and faster to implement. Whereas Stateful session bean comes with some overhead (its known that Stateful Session beans are heavier than Stateless session bean, though I think newer EJB specifications are going to change those perceptions), httpsession is much an immediate solution.
Think of the use case that if all the clients of your business layer are coming through WEB, its safer to implement stateful-ness through httpsession. But what if there are other clients as well - like Plain Java Swing based clients, WAP enabled phones etc are also your client of the business layer and then it makes clear sense to adopt Stateful Session bean rather than tracking states through Stateful session beans.

Tracking states through httpsession is a presentation layer trick , whereas tracking states through session beans is a business layer trick. If we keep this in mind it will be easier for us to choose one or the other depending our use-case.

Java's Synchronization support may lead to read/write performance bottlenecks

In order to support multi-threading applications, Java provides "synchronized" keyword. The problem with Java's basic support of synchronization is that - synchronized keyword locks on the object level. For example, if we mark one method of a class as synchronized, then if one thread is inside this method, no other thread can not run any synchronized code of the same object.
lets take an example of a Cache implementation. Lets say we created one hashtable which is the cahche in our application. It caches some objects which are otherwise to be fetched from the database. In order to save the round-trip, some of the objects are read from the database and are cached inside the hashtable. Now as it is a cache, so there will be more reads than writes. If we use synchronized keyword and use the cache object as synchronized object, all reads and writes to this cache will be serialized. Whereas in reality, multiple reads can happen concurrently and can enhance performance.

For a minute, lets think about a database table, most of the time we read from the table and at times we write into the table. If reads are serialized, the whole application will become slower. So database have concept like "shared lock" and "exclusive lock".

Sometimes it become very obvious in case of Java applications also to adopt to this type of "shared lock" and "exclusive lock". Reads from the cache should hold a shared lock and write to it should hold an exclusive lock.

Since Java's native API does not support this one needs to write his own logic to make sure he is following this shared/exclusvie concepts.

Here comes this book which is very handy - "Concurrent Programming in Java: Design Principals and Practices". The author Doug Lea maintains a site http://gee.cs.oswego.edu/dl/ where he has a package called util.concurrent which can perform lot of such locking. These packages are also getting included in JSR166.

EJB3 does not have EJBHandle

People who have worked extensively on EJB2, might have used EJBHandle. According to EJB specifications, when we use EJB2.1 and get the EJB stub from the EJB home interface, this stub can not be serialized. Hence in case of a stateful session bean, if you want to store the handle to the particular session bean, you can get the handle of the bean and store the handle by serializing it. Later you can de-serialize it and can connect to the same bean and go back to the same state. This was particularly useful in case of "Failover scenarios" or in case of advanced spftwares where we can provide resume later kind of option. So you save the state to your disk, come back later and get hooked to the same state. (Think of accessing one Stateful session bean from servlet and you want to store the handle in the Httpsession to make sure any browser refresh or so can get you back to the same session bean always)

This is being modified in EJB3, EJB 3 actually does not support EJB Handle. It was tough for me to digest this fact for some time till I realized that in case of EJB 3, the proxy object that the container provides when we look up the bean using context or by using "dependency injection", is serializable. So the proxy object that we get from the context can be serialized and later de-serialized to connect to the same Stateful session bean. This eliminates the need to EJBHandle altogether.

EJBHome and EJBObject are missing in EJB3.0

Programmers when migrate from EJB 2 to EJB 3, get their first doubt around the fact that EJB 3 does not need any HOME interface or EJBObject interface.
Why does EJB 3 do not need these interfaces ?

Home interface is nothing but serves as a "factory" for creating references to the remote EJB Object. Home interface was same for stateless session beans and message driven beans as they are initialized in a similar way. In case of stateful session bean, the home interface used to take an argument which used to take parameters to initialized the states. This is a programming practice and in case of EJB 3, you achieve the same thing by "setting the states" on the bean using some setter methods. Thus we can actually remove the home interface all together and get the handle of the remote business interface directly as we do in case of EJB3.

EJBobject interface was required to provide a client view of the EJB. Container used to provide implementation of this interface and container used this EJBObject interface as a nice hook for invoking container provided services like transaction, security etc. Fortunately the EJB containters in EJB 3 have made this more behind the scene and they actually do not depend upon an extra interface , rather they implement the Business interface and provide the same container services between the business interfaces and the bean object.