Tuesday, November 01, 2005

Standardization

This term in software means adopting the same protocol, format or development methodology as other people do. Patterns is another means of standardization. I like standardization, because it makes things look familiar to many people and it's easier for others to understand.

The bad thing about standardization is sometimes that certain developers see it as a "Holy Grail" of development. For instance, if an application runs on Tomcat, it has been developed quite strongly, does the job well, and it is doing quite an important job, it is likely some guy comes in and says:"Really, this ought to run on an application server, because the service has become so important, we should not risk....".

And there goes another million dollars against a project that was running fine in the first place and now is being rewritten to run inside an expensive application container.

I'm not especially against J2EE, but I've found the actual 'benefit', for what J2EE was developed, to become less and less marking, considering there are now technologies like Spring, Hibernate, Apache libraries and log4j. As in another article written on OpenSource and the costs of software development, I see no problem if someone uses a Tomcat engine properly and writes an application using Servlets or other technologies. As long as it works great and is consistent in behaviour, why change it to EJB's and the rest, *only for the purpose of being standards-compliant*?

I've seen people developing enormous presentations about *why* everything should run on J2EE, that the industry has shown in practice J2EE is the winning factor, that an application server can cater all your needs, etc... etc.. etc...

In practice, from experience, J2EE development is not as cost-effective as people want others to believe. Actually, I am writing software my own using *only* Tomcat, Hibernate, Apache libraries and some XML libraries. The development speed for that project is 3 times higher than if I would have used solely J2EE standards, plus that the testing and unit-testing cycle time is 5 times lower, because Tomcat starts up in 10 seconds, but JBoss in 50 for example ( WebLogic taking even more than that ).

Another defense in favour is remote-ness. "Anybody can use this object as a service...". In reality and practice, people develop an HTTP interface and don't go through the EJB container directly. I'd rather use SOAP probably, if the volumes of using the service permits it.

No comments: