Nando's Weblog

delirios e ilusiones

Archive for Frameworks

Spring benefits

Why Spring ?

For the re-engineering of DieTiX, it has been necessary to make a choice, regarding a Java Framework.

Two major solutions have been proposed for that. They are not the only ones, but they are the two ones with major acceptance: EJBs and Spring.

The selected option was Spring.

Why ?

The long answer can be found in Rod Johnson’s book, “J2EE Design and Development

The short one is that Spring provides just what we need.

Because … what is an integration framework about ?

In the same way that WS orchestration just coordinates different webservices without forcing them to be “orchestration-aware”, a good integration framework should not force the components to handle additional complexity to solve other problems.

Divide and conquer is easier to say than to implement. It is clear that a subdivision of a system helps to tackle the issues separately, in a much smaller scale. But this is useless if encapsulation is not strong enough and if it is, the relation among these components is the remaining problem.

Your abstraction and conceptualization capabilities during the analysis are the key factors to partitionate a system. A framework can afterwards help you to integrate them seamlessly. Here is precisely where a good framework should show its strength, and connections among beans have one special moment: instantiation.

After instantiation, the reference to this object can be handled in many ways (ideally, among certain limits to keep layers independent) but this part of the story means a different challenge. The point is that instantiation is the first step that builds a link among the different components in any application.

Some GRASP patterns try to address exactly this problem, very well solved by Spring.

Information Expert and Creator are principles about who should instantiate an object and this is done with Spring in a way that is transparent for the beans involved. Furthermore, instantiation is actually done by the container itself and beans are then available to the others, which need to use them. This is obviously right and an Application Server does it also. Where the EJB approach fails, is when forcing the beans to use lookup code (JNDI) to find the beans they need.

Even after having defined (really) large XML descriptors in the early versions, nobody took this responsibility away from the bean.

Whilst in EJB you should write something like this (i.e. with JBoss):
InitialContext ctx = new InitialContext();
MyBean myBean = (MyBean) ctx.lookup("MyBeanImplementation/remote");

With Spring you just define the property and a standard way to set its value, even by a setter or through a value received in the constructor.

But the best of all, is that none of the participating beans have to be aware that one is injected into the other.

In EJB 3.0 there are big improvements into the right direction. These improvements are clearly influenced by the main alternatives to the previous EJB specifications which are Spring and Hibernate. The open question is then which one to choose and also which configuration option (annotations or xml).

In this case, we answered this two points starting with the configuration issue. The decision was that annotations are ok for persistence, since it makes perfect sense that a persisted bean is aware of its nature. But for DI, we prefer to keep the bean as much unaware as possible and therefore, xml is the prefered option.

From this point of view, Spring is then not only future-proof but also a simpler solution that can run just within a servlet container like Tomcat, without the need of an Application Server. Even though JBoss has now an embeddable container, it is still considered as an additional level of configuration that if possible, is prefered to be avoided.

Some Spring benefits:

  • no lookup code
  • simple descriptors
  • autowiring