Client/Server Done Right?

In my experience with 2-tier RDBMS client/server, the major issues have been (1) software configuration management, (2) scalability and (3) narrow middleware paradigm. The first can be dealt with either using management software or having workstations load the applications from a file server. The second is helped by the ODBC implementation of OpenLink, which is "cheating" since it effectively moves the architecture to 3-tier.

Current Intranet technology improves on the 2-tier paradigm in much the same way as the OpenLink drivers and LAN file serving. By moving to 3 tiers, the network protocol used by the client can be more efficient, and some processing of the results from an RDBMS query can be done on the middle tier. If you use Java, Intranet technology deals with software configuration management in much the same way as a file server would: the workstation loads the applications from a Web server.

The Intranet does nothing to address the lack of middleware richness. Different applications require different paradigms (such as RPC, MOM, TP monitors or distributed objects), yet the protocol endemic to Intranets, HTTP, behaves like an RPC. Java's RMI will add distributed objects. Of course, this will require a Java VM on the server. The Intranet does nothing to simplify or abstact MOM and TP monitor implementations, so these will rely on the same products that are used in non-Intranet 3-tier applications today.

Those who have started to implement systems based on middleware such as MQ Series, Orbix, Forte or Tuxedo would find Intranet development a huge step backward. Instead of 'Client/Server Done Right', to me, today's Intranet is 'Client/Server Done the Old Way'.