The Value of Standards

I was assisting a systems integrator with proving the scalability of an application yesterday and the problems we had rammed home to me the value of using standard ways of doing things, and working within the standards that exist.

Some of the problems we had illustrate the importance of understanding how standard APIs work and what can happen if we don't follow them

The case of the missing graphics

We had deployed a J2EE application onto Oracle application server, integrated it with single sign on and got the custom login screen up.  Well almost, the graphics didn't display but we could log in!  Investigating the page I discovered that the links to the graphics were all wrong.  Investigating the JSP pages I discovered that the author had used the wrong API call to figure out the base URL of his application.  Instead of using the "HttpServletRequest.getContextPath()" call which returns the root URL of your application he had used "ServletContext.getServletContextName()" which returns the name of the application as deployed.  Once we had worked this out we redeployed the application with its name set to be same as the root URL of the application.  It looked strange having an application called "/AppNameChangedToProtectTheIncompetent".

Lesson 1 Make sure you understand the Standard API you are using.

The case of the lost time

I couldn't understand why it took so long to deploy the application.  Then I noticed a couple of things about the deployment process.  First the application was 42MB in size, 40+MB being libraries, several of which already shipped with App Server, several of which had equivalents in App Server and finally a couple of libraries were from another App Server

Lesson 2 Only package what you need.

Some of the libraries would have been better installed into the App Server itself instead of being deployed as part of the application.

Once the JDBC connection pools were set up for the application you would have thought that it was ready to use.  WRONG!  They use EJBs, but rather than rely on the container configuration they embedded the location of the EJBs in a property file.  This required the installer to go through half a dozen property files after installation and configure them for use with the EJBs in the container in which they had just been deployed.  Unfortunately the EJBs didn't seem to have any way to configure the user principal and user credentials, so they could only be called if they were in the same container as the web components.

Lesson 3 Put configuration in standard places such J2EE properties and environment settings rather than in custom files.

Because all the config was put in custom files when we started clustering the application the SI had to spend another half hour changing the settings to work on the new machine.  All needless, the connection pools moved across seamlessly.  This also caused another problem, to allow the container to short-circuit the remote login for EJBs and use the web credentials we had to fix the port number of the RMI server, making it impossible to run multiple JVM instances in the same OC4J container.

This experience left me with concerns about the ability of anyone to scale this application to multiple servers because of the complexity of configuration.

The violation of Internet law

The effects of yesterday left me reflecting on the sage advice of RFC 791 that can be summarised as

Be liberal in what you accept, and conservative in what you send

The same principles should hold true in application development, if I may paraphrase

Be liberal in what you expect, and conservative in what you need from your environment

Standards are a key way of making sure we understand what is expected from us and what we can expect from our environment, use them or spend hours configuring a simple database application!