Improve performance of JAX-WS

JAX-WS comes with JaXB. The raw SOAP packet does not come to the web service consumer, instead they get unmarshalled to the Java Objects by the JAX-WS runtime engines.
Lot of time it is however better not to convert the payload of the SOAP packet i.e. the XML to the java objects. Think of a situation where we are getting one XML and we are going to use that XML to another web service. This happens in case of SOA environment, where we talk to one web service, get some data and we pass that to another web service. If we are converting the received XML to another XML only then we should try to avoid the JAXB layer.
Lets consider the steps involved if we have the JAXB layer -

Response SOAP --> Response Object --> transferred to another object --> Send to another Web Service

Instead if we remove the XML to Object layer, it becomes -

Response SOAP --> XSLT transfer to another XML format and send to another web service. This is faster, only pain point is - we need to work with RAW XML like using StaX API instead of using the Objects of JaXB.

DAO layer in J2EE Apps

Phew.... its been a crazy time. There was a product release and things were pretty hectic. Hence did not get time to write anything on the post. Now that the Chrismas vacation is here, need to spend time with family also :-)

Anyway, I thought of writing this post on Data Access Layer of J2EE. How many times we write DAO layers yet we dont get it right at the first time. I was reviewing some of the codes and found out that people do not understand why they are writing a DAO and just write it cause its mentioned somewhere that it is a good practice.

okay, so as we all know that we introduce DAO layer to abstract the data access layer. For example, if your application runs on MySQL, SQL Server, Sybase and Oracle, the DAO developer makes sure that he introduces a nice abstraction layer which hides all of these database related differences. The client code of DAO - which is many times the Session Facade or Value List Handers, do not have to worry about loading the JDBC driver and creating DB specific SQLs.
Doing so, DAO layer needs to make sure that it opens a connection with database, prepare statement object, create resultset , retrieve data and close the connection and resultset. Closing the connection and resultset are important otherwise you will have leaked cursors at the database layer. It is also important to make sure DAO layer catches all the JDBC/SQL specific exceptions and convert them to application specific exceptions. Lot of DAO developers do not handle the exceptions from the DAO layer which defets the purpose of having another layer. The idea is that any code which is going to use the DAO, should not have to use java.sql.* or javax.sql.* packages at all.
There are many ways to create a DAO layer, if we refer to the Suns J2EE blueprint site -
http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html

Evolution from Inheritance to Composition to Dependecy Injection (Inversion of Control)

Inheritance and compositions are the most basic concepts of Object Oriented design. If there is a is-a relationship between objects, we tend to use inheritance and if there is a has-a relationship, we tend to use compositions. For example, Manager is a Employee, so Manager will be a sub-class of Employee. Otherwise, Machine has disks, so Machine object can contain many Disk objects following Composition.
It is a usual practice to follow more of Composition rather than inheriance. Reason is - composition allows loose coupling than Inheriance. In case of Inheritance, any change is super-class methods can break the client code which are using the super-class or any of its sub-classes. Whereas in case of composition, any change in the back-end class (the class that is encapsulated within another class) might not lead to changes to the client code which uses the front-end class (the class that encapsulates the back-end class).
Hence when we develop enterprise applications, we develop complex class maps where one class holds refernece of many other classes. The problem is the front end class needs to explicitely get a hold of the back-end class. For example, class A has-a Class B. In that case, we can find some code like

Class A{
private B b;
A()
{
B b = new B():
}

....

Now it becomes a problem for class A sometimes to get these references of its composite classes. Think about Class A as one EJB bean which is going to class another EJB bean B. In that case, A needs to look for B's home interface from JNDI. Or think of B's reference is available in JNDI (like B is a JDBC Datasource), in that case also A needs to look for the reference of B from JNDI.

Instead of class A, getting the reference of Class B explicitely, if some framework can inject or set the reference of class B in class A, that becomes very easy. As a result class A can concentrate on other activities. This is called "Dependency injection" (previously known as Inversion of Control). Spring framework make use of this concept very much. Even EJB 3 uses dependecny injection to inject EJB references or Persistence Contexts. Dependency injection of these frameworks can really help developers to develop cleaner code.