dvrom.eu

System architecture, object design, build-release-test cycle definitions, tool configuration, coding…etc…

These are just some of the things that bring me back to software engineering in June, in my new company.

I consider myself to be extremely lucky to have worked with some exceptional technical and functional domain experts as a Technical Consultant for one of the world’s private banking software solution leaders, in one of the banking capitals of Europe for the past year and a half.

Being able to harvest knowledge from hardened veterans who have been in the trenches for years has certainly given me a good understanding on how things work in the Private, Retail and Core Banking world.

I must say though, that going from codebase and development junkie to functional and technical product evangelist was quite a revealing experience.

As a developer, I had always seen the consultants with whom I had worked with from a skeptic dilbertesque point of view: the fancy suits, the nice cars and the expensive hotels already created an important distance before even starting to work together.

There are many stories out there about the mystical Consultant that appears in a messiah manner to save the souls of the doomed project: whether it be with magic wordings, sacred vendor-specific knowledge or just pointing out the obvious, their presence is almost always mysterious and ethereal.

The mysterious aura surrounding consultants tends to exaggerate their performance: good consultants will be remembered as wizards with efficient problem solving techniques, while others will be remembered like the strange guy who nobody knew and just wandered around all day.

Having worked on the past as a developer taming one certain beast, I was often frustrated when one of the beast’s consultants could not answer some of my questions.

After being on the other side, I now see that probably the most important virtue of a vendor specific consultant is not what he /she knows, but rather what he / she can find out: the consultant will probably be your best link to the developers behind the product, and the key to the knowledge you are looking for.

So next time your are face to face with one of theses mysterious vendor consultants, remember to throttle frustration if your answers are not given to you on the spot, and instead be patient for the information to be collected by your only link to the products core…

One of the first projects I worked on has finally been replaced and gone to wherever dead code goes…

Looking back now, this extremely simple CMS was one of the most successful projects I have ever worked on so far, in terms of longevity (it was in production for the past 5 years) and user feedback.

It is also probably the simplest solution I ever worked on (no complicated development processes, no clever code, no pattern abuse…) and it reminds me of a quote I remember reading once that was somewhere on the lines of:

I would probably rephrase this statement to:

In the same sense, I would also state:

My quick exposure to the vast world of J2EE, ORM Frameworks, Enterprise Patterns, the Java API, Web Frameworks and other candidates for abuse in the projects that followed this simple CMS, combined with my “bring it on!” rookie prepotency, led to some ugly code and some terrible over-engineering…

Not only wisdom, but also ignorance, can sometimes produce the best results…

Stress testing, Load testing, Performance testing, Capacity testing…they all are based on the same idea:

• Software systems are usually built to be used, and chances are that, at one point or another, you will want to know how your system reacts on heavy loads, and, in case the results are not satisfactory, you will want to improve the systems performance.

A first question arises:

Should it be done at some particular phase or should it be triggered by some specific requirement?

The combination of Tomcat, Apache and mod_jk can be a good choice on delivering a scalable and robust solution for a simple JSP/Servlet based web application.

Scalability and HTTP session failover can be achieved in a simple manner with a straightforward lightweight servlet container like Tomcat, which offers cluster functionalities.

Load Balancing is achieved through the mod_jk apache module, which distributes incoming requests with a simple weighed-round-robin mechanism through the AJP protocol.

(mod_jk seems to be the best supported and most widespread Tomcat – Apache connector)

In order to offer HTTP session failover (avoidance of session loss in case of failure of the Tomcat instance holding the session), session replication can be used.

Tomcat can share sessions through a database, a file or through in-memory replication.

To get an idea of the overall architecture, you will end up with something like this:

Tomcat uses a very simple clustering mechanism:

Clustering membership is established using multicast pings. Once a multicast ping has been received, the member is added to the cluster. Upon the next replication request, the sending instance will use the host and port info and establish a TCP socket. Using this socket it sends over the serialized data.

It is possible to have an initial starting point for this architecture in no time, and the following is a very brief proof of concept with Apache HTTP Server 2.2.11, mod_jk 1.2.28,Apache Tomcat 6.0.18 running on Mac OS X 10.5.6 (Darwin 9.6.0).

In this example, one Apache HTTP Server will be load balancing http requests between two Apache Tomcat instances through the mod_jk module.