Nando's Weblog

delirios e ilusiones

Archive for basic concepts

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

Underestimating concurrency issues

More often than you can imagine, I have seen systems where the problems of concurrency were severely underestimated. Even people that I considered quite intelligent, when I was commenting about the lack of a concurrency control, argued: But chances are quite low.

Or even worst: a kind of optimistic locking was implemented, but the check of the time-stamp was done through a SELECT statement previous to the update without locking the row. Again, the argument was it is really improbable to get an update in between.

The problem is simple, low probability does not mean impossible and when this happens, it is specially tricky to find the reason for an error in a system that was running without any problem for a long time.

Fixing a bug has two parts: detection and correction. From these two steps, the first one is the most difficult and concurrency problems are (precisely, because of their low probability) very hard to reproduce.

Thinking that it doesn’t worth the effort to solve them, due to the low-probability, is like playing Russian roulette with a single bullet.

Hibernate now makes everything easier. Be aware however, that EntityManager is not thread-safe.

High performant (but useless) systems

Many times, I heard people talking about the problems of performance, when defining some constraints at DB level. Anyone can understand that no matter how fast a response is generated, it is totally useless if it is wrong. However, some people sometimes think that actually it depends and it is just about finding the right balance between performance and data integrity.

For those who are still not sure about this point, this example might be helpful.

The company was an electricity company.

Just few years before, it had paid several millions for a huge consulting project that implied a broad reengineering of the processes and information systems.

Whilst relational databases were already an industry standard, the implementation option on which the solution was based was a non-relational database (Adabas). In order to improve performance, one-to-many relationships were implemented as arrays, with no FK constraint. The result was a much performant system and everyone was proud of it.

But after having seen many inconsistencies, I made a small program in Natural. The input was a screen where the user declared the FK constraints and the source of a Cobol program was automatically generated, compiled and run, in order to make the checks and produce a report of the inconsistencies.

We all know how bad inconsistencies are and how they tend to reproduce themselves. What we might not always be aware of, is about the business and economical consequences they may have.

As said before, many processes were improved not only internally, but also the communication among them. An electricity company has many offices distributed across the service area. Each of these offices does maintenance and other kind of tasks. So the Operations and CRM systems were feeding the service orders each office needed to do on a given day.

One of this types of orders, was to read the meters in order to generate the invoices.

The problem, is that some meters were assigned to invalid offices.

This means, that this meters were never included into any service order to read them.

Yes, you are right. No reading means that no invoice was being generated. They were getting electricity for free. There were many of them. Happy customers, of course.

I hope inconsistencies will no further be seen as a technical problem. They might mean huge amounts of money.