ContentsApplication DesignAdvantages of loosely-coupled design

Previous: Leaks | Next: Avoiding "Analysis Paralysis"

Fat client applications are often monolithic at runtime. What I mean by that is that the entire program runs in one process space. This has pro's and con's. On the good side, it is much more efficient while it is running. On the bad side, it has to be replaced and maintained in it's totality instead of it's components. If you've ever had a stereo system which has the tuner, tape, and CD all in one cabinet you understand the convenience; if one of these integrated components has failed, you also know the aggravation of not being able to swap that component out.

A frequent misunderstanding is the assumption that the mere act making your application with an object-oriented tool will make it more robust and easier to maintain. This couldn't be further from the truth. Often times, the false sense of security causes programmers to get lazy and do some really stupid things - just because they are using a professional development tool that they have confidence in.

Loosely-coupled application development requires that your components be designed in a way that they can communicate and collaborate using a protocol that permits them to be run in separate process spaces at runtime. The protocol should be well-known and nonproprietary to permit maximum flexibility. For the most part, these protocols are built upon a network protocol, preferably TCP/IP.

In the case of servlets, there are at least two protocols which get used: HTTP and the "connector protocol" for the servlet container. The end user's browser communicates with the web server using HTTP and the web server communicates with the servlet container using a protocol provided by the servlet container. It is also common for the servlet to communicate with other server-side components using CORBA, RMI, or JDBC.

The advantage of this loosely coupled architecture is that any or all of the components can reside on different computing hardware. They could also all run on the same hardware. The primary benefit of the ability to have parts of your system scattered across the network is to make it robust. The Internet was designed to survive nuclear attack. Distributed computing was found to be the way to accomplish this.

Scalability may not seem as difficult as the ability to survive a nuclear attack, but it requires that your application be able to grow (and shrink) as demands change. It also means that you should be able to replace any ailing component without bringing the entire system down. It also means that you should be able to do these things without disrupting the end user.

In the case of web applications, the end user doesn't know how the server side works - and shouldn't care. The end user doesn't know if your application is hosted on Windows NT today, Solaris tomorrow, and an OS/390 mainframe next week. It may be hosted by a Macintosh TurboLinux cluster next month.

This is a radically different way of looking at things, compared to the attitude that we build thinks on Windows98 and install them on other systems, hoping they will work. This approach insures that your application will not only survive scalability; but also that it will survive the future changes to the IT infrastructure that are inevitable.

ContentsApplication DesignAdvantages of loosely-coupled design

Previous: Leaks | Next: Avoiding "Analysis Paralysis"