Skip to main content

Is Client-Server Dead?

Posted by sgsst on January 9, 2004 at 1:30 PM PST

The relational database (based on SQL) has given us an elegant way to model the way different parts of an application relate to one another. Relationships allow us to eliminate redundant data, to relate data in meaningful ways, and to enforce those relationships at the lowest levels to ensure consistency. Enter the Object-oriented approach and its inherent desire to encapsulate and isolate, and the interconnectedness of the relational database no longer seems desirable. But, like it or not, much of the functionality of any business application is locked into the very structure of the data itself. Additionally, even the user interface is directly affected by this same structure-- no matter how isolated one is from the other, they are still part of the same application.

As I understand the world, the modern application now has at least three distinct layers: data or persistence, application logic, and user interface. In the old client-server days, we used only two layers: data (based on SQL) and the user interface, which was proprietary. One of the main shortcomings of client-server paradigm was the inability to migrate an application from one proprietary vendor to anther-- there was no standard user interface specification supported by multiple vendors. So, if you developed your application in PowerBuilder, for example, you couldn't easily migrate it to VisualBasic or Oracle Forms or to the web without a complete re-write--thus the evolution of the 3-tier modern day applications.

Now, I see great value in isolating the business logic and data access from the user interface when supporting more than one user interface is required. Say your super-slick new application must be available to a traditional web user, a blind web user, on a cell phone, from a rich graphical interface, and even to a command-line utility; well, then, you had better isolate the business logic in a single place or you'll go crazy maintaining changes to the 5 different interfaces as the application evolves over time.

And, I can also see value in isolation of the data or persistence layer from any specific vendor's relational database. It makes perfect sense to me to support easily switching from one database vendor to another. But, beyond that the data layer is really tightly bound to the business logic layer.

But, I do not believe using all three tiers is always necessary or justified. When an application has limited business logic beyond what is inherent in the structure of the data itself and will only ever require a single user interface, the extra overhead of a 3-tier implementation may not be necessary or justified. Today we have JDBC and JSP as common, vendor neutral tools to interface with any relational database and any compliant J2EE application server.

As an example, consider the rather trivial example of adding a column to an existing table in an existing 3-tier application. You must modify the database to include the new column. Then you must modify any place within the business logic that uses this table. Then you must find and fix each select , update, and insert statement. Then you must modify the interface or "API" that is used by the user interface to accommodate this new field. Lastly, the user interface must be modified to not only use this newly modified "API" but also to display and process the new field on the "screens". Finally, the roll-out of these changes must be tightly coordinated so as not to break any one layer that depends on the others.

As you can see, maintenance of a three-tier application can be somewhat complicated and error prone, and for that smaller application, perhaps, a client-server implementation using JSP and JDBC is just the ticket.

Related Topics >>