As multi-tier systems demonstrate, the architecture of most information systems today is very complex and can encompass many different tiers as successive integration efforts build systems that later become building blocks of further integration. This is in fact the main disadvantage of the multitier model: there is too much middleware involved, often with redundant functionality, and the difficulty and costs of developing, tuning, maintaining, and evolving these systems increases almost exponentially with the number of tiers. The infrastructure and development cost of multitiered architecture is higher than client-server, for example.
Many multitier systems today encompass a large collection of networks, single computers, clusters, and links between different systems. In an multi-tier system it might be difficult to identify where one system ends and the next starts. Remote clients access the system via the Internet after going through a firewall. Their requests are forwarded to a cluster of machines that together comprise the Web server (cluster of machines are a very typical configuration for the layers of multitier systems; they provide higher fault tolerance and higher throughput for less cost than a single machine with equivalent processing capacity.
Internally, there might be additional clients spread out all over the company that also use the services of the system either through the Web server or by directly accessing the application logic distributed across a cluster of machines. There might even be several middleware platforms for different applications and functionalities coexisting in the same system. Underlying all this machinery, the often-called back end or back office constitutes the resource management layer. The back end can encompass a bewildering variety of systems, ranging from a simple file server to a database running on a mainframe and including links to additional 2-, 3-, and multitier systems.
A more robust solution is to introduce a load balancer between the clients and a farm of identical middle tier servers. The load balancer routes requests to one of the middle tiers servers based on the load and network topology. If one middle tier server fails, it can reroute the request to another to prevent single point of failure. This architecture requires that the servers in the middle tier farm synchronize user sessions with each other in case one has to take over a client from another.
The business logic resides in the back-end – that is, the Oracle database. The database serves as PL/SQL-based application server and is based on a logical multittiered architecture with data access, business logic, and presentation layers.
By the same token, the database server can also be clustered. Both client-server and multitiered architectures can be developed using either Java or .NET technology, although .NET is a more natural choice for a rich client on Windows-based client PCs. It is also possible to take a hybrid approach – develop rich client in .NET but business logic in Java, and integrate using SOAP-based Web services.
Which architecture to choose should be determined on a case-by-case basis. No single architecture fits all situations.
Available here and other leading retailers:
David G. Peterson is a business consultant and author of Handling the Remedy. He has extensive international experience managing projects and operations for large financial institutions. He has worked in North America, Europe, Middle East and Asia skillfully managing business and technical requirements, core systems enhancement and support, merger and acquisition integration's, business process reengineering, off-shoring and outsourcing.