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.

Sequence Diagram - when and why

Even till recent past, I was not a fan of Sequence Diagram. I always thought if I have proper class diagram and have a fair idea on the "Use Case", I do not really need to draw a Sequence Diagram.
Its only recently I discovered that if I draw sequence diagram of a system, sometimes its become very clear which are the "chatty-interfaces". This in turn can help us to improve performance by reducing "round-trips". If we draw a sequence diagram, the interactions between the components get clear which sometimes lead to identification of "chatty-interfaces". This might sound obvious that we know how many times we are sending requests to database or webservices and the request is going over the network, but in a complex application, it might not be very straight forward. It becomes very easy to see how many times we are going across network if we draw the sequence diagram. This in turn can help us to improve the design by introducing "Caching" and reducing round-trips across networks.

Cache vs Pool, when and why?

Cache and Pool both are very related topics in J2EE world. We use these techniques to improve performance. For example, we try to Pool the JDBC connection as opening a Database connection is costly. Similarly we Cache data in the form of objects in memory to reduce the "round-trip" time across network.
Note the way we used Pooling at one place but Caching in another place. Question is when we pool and when we cache ? We do Pooling when the objects we pool have no state in them. We do Caching when objects have states. For example, any JDBC connection object will be sufficient for the application to connect to the database. It does not matter which one is giving you the service. Hence we Pool them. But in another case, when we are looking for objects from database, lets say we have read the Customer information from database and stored them in the forms of objects in memory, in this case, we do not want any Customer object to see but we want a specific customer object whose customer id is X or whose name is 'XYZ Inc'. So the easier way to remember is - stateless information can be pooled and stateful information needs to be cached.

Command Design Pattern in J2EE

Command is one of the oldest design pattern which exists from the days of SmallTalk. It is popular for its simplicity and yet the power. The heart of this pattern is its command interface which can have simple methods like init (), execute(). The concrete command objects will implement this interface. This design pattern can take a request and pass that to the proper object for being processed without any knowledge from client. The client code does not need to know actually which concrete object is going to process this request.
In J2EE world, to adhere to MVC model, there are several design patterns available to wrap the business logic or model. For example, EJB uses Facade Design pattern and hides the model complexities from controller. Similarly Struts framework uses something called "actions". If you do not want to use EJB or Struts type of framework, yet want to adhere to MVC model, its best to use Command Design pattern. Here is a small description how -

Develop some command beans which needs to have series of Set methods to set the parameters, a series of get methods to get the results after the processing, one init method to initialize (like open JDBC connection etc) the environment before processing start and finally one execute method to really perform the processing.

Develop one command interface which will have init and execute method so that the Controller Servlet can use this interface to send the processing request without really knowing which concrete command object will process it.
Lot of time we can use Class.forName to initialize the concrete command object. For example, in the controller servlet we can have some code like this -

DBCommandBean command = (DBCommandBean)Class.forName("com.mycom."+requestType+"CommandBean).newInstance();
command.set(hashtable) -- hashtable contains some parameter and value which will be used for processing.
command.execute() -- this will perform the real processing
command.get() -- this will give back one hashtable with key and value pairs which need to be accessed to see the result of the processing.

Distributed Transaction in J2EE framework

Distributed transaction is a fascinating topic. Think about developing a software application which needs to manage multiple databases. We usually develop software that talks to only one database in a single transaction. This is called as local transaction. If one transaction encompasses multiple databases, it is known as Distributed transactions. The distributed transaction is possible through the usage of JTA - Java Transaction API.
Before we discuss more, lets get the definitions of some terms correct -




Resource - Thnk about this as a database or JMS Queue.
Resource Manager - Its the JDBC Driver which manages the Resource - like database.
Transaction Manager - It manages the transactions across resource managers.
Transaction originator - its the client code that starts the transaction.


The transaction originator is the EJB beans that kicks off the transaction. EJB containers support distributed transactions through a protocol called "Two Phase Commit". In case of two phase commit, the Transaction Manager sends a request to all the resources before really committing the transaction. If the response is OK from all the resource managers, the transaction gets committed in the second phase or else get rolled back.

The beauty of distributed transaction is that, the transaction manager can propagate the "Transaction Context" from one Resource Manager to other Resource Manager. And all this happens in the background at the EJB Container level. Of course, your container needs to support this feature, like WebLogic Server supports distributed transactions and the two-phase commit protocol for enterprise applications.

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.

Rule based engines to automatically validate upgrades

It is a headache for install/upgrade developers of an enterprise application, to make sure their product will install/upgrade properly at the customer site. By nature, enterprise applications are far more complex than a simple product because of their distributed nature and different varieties of setup that these enterprise applications usually provide. Now software by nature can fail anywhere as we do not have prior knowledge of the system where it will be installing. For a simple example, we might be having an application which is installing fine on the developers and testers boxes but fails at the customer location just because customer had many "non-active" logical volumes !! which we do not usually have.
So in summary, it is not possible to make sure the product with lot of third party integrations/dependencies will really install properly. One way to attack this problem is to produce a framework which will run before and after the install/upgrade of your application and will make sure that 1) the system is ready to install your application (by checking all pre-requisite patches, third party product versions etc) and 2) perform some basic sanity test of the product after install.
Thinking about it, is not very complex with Java and XML. Lets say developer publish one XML schema where in one can put in "several test" and the output to be looked for in that result is a good idea.

For example, lets say your product X depends upon Oracle version 10g. Now you create one sql file which selects the oracle version from v$version and you mention in the XML rule file to run this sql file and check for a regular expression like "10.2.0.3.0". Your framework can run and check for the proper oracle version. Like this a series of "tests" can be performed using this framework.

The beauty of this solution is, as and when you find more failure conditions of your install/upgrade, you can add more tests in your XML based rule file and make the product more failure proof.