Multi-tier architecture has been bandied about as one of the newest technology in the computing world. Through this post I would like to discuss the similarities and "differences" between the client/server model and the multi-tier architecture.
In the 1980s, the client/server model became widely known and accepted in the computing world, when PCs were used in a networking environment such as LANs or as user interfaces to mainframes.
Tandem computers professionals, for example, already used and perfected this model before PCs were invented. They called it requester/server pairs. Tandem used an environment called Pathway in which servers are configured and in which requester’s code is stored before being "pasted" onto any dumb terminal.
When someone figured to use PC power for user interface purposes, requester’s code was moved (recoded) into client applications. This made it possible to use multimedia on the client while the servers needed little or no changes.
This development, in turn, gave rise to Remote Procedure Calls. A client application could, for example, directly access a database on the server computer without having a server program previously coded to implement the IO. In order to improve on the versatility of user queries, relational databases gained a lot of acceptance. With such a decentralized base of users, it became imperative to satisfy a variety of (unpredictable) queries without constantly coding/recoding servers.
This simple client/server model is now called the two-tier architecture. Same technology, new moniker.
Soon, users became more computer literate and, of course, more demanding. The stress on servers was increasing. It even became necessary to process single transactions in more than one server machine. Multi-tier architecture was born.
In a three-tier system, for example, the middle layer can be used to monitor traffic, manage "messages", stage databases, and even process some transactions.
Programmers typically use the middle layers to monitor, queue and prioritize transactions. They can check passwords, retrieve user profiles and reroute transactions: this always happens when using an average ATM machine, for example. They can even implement protocols for accessing "strange" devices and special servers. They can "free" a client and send them results, later, when they are ready for display.
All of that revolution in client/server technology assumes that the programmer "knows" how to code communication modules between all the computers involved. Well, actually, not any more: enter the world of Object Request Brokers (ORB).
An ORB is simply an application designed to "hide" annoying communications and data exchange details from the programmer. A COBOL programmer can, for example, code an application that interacts with other applications written in different languages and residing in remote machines without being bothered by the logistics involved. All the programmer needs to know is how to "call" the ORB, which handles the dirty job. An application developed with ORB is highly portable and interoperable across languages, platforms and operating systems.
The most widely used ORBs are CORBA and COM/DCOM.
This is said of CORBA: "Using a CORBA-compliant ORB, a client can transparently invoke a method on a server object, which can be on the same machine or across a network. The ORB intercepts the call, and is responsible for finding an object that can implement the request, passing it the parameters, invoking its method, and returning the results of the invocation. The client does not have to be aware of where the object is located, its programming language, its operating system or any other aspects that are not part of an object's interface".
And this about COM/DCOM (a Microsoft technology): "Distributed COM [DCOM] is an extension to COM that allows network-based component interaction. While COM processes can run on the same machine but in different address spaces, the DCOM extension allows processes to be spread across a network. With DCOM, components operating on a variety of platforms can interact, as long as DCOM is available within the environment."
Dimandja
In the 1980s, the client/server model became widely known and accepted in the computing world, when PCs were used in a networking environment such as LANs or as user interfaces to mainframes.
Tandem computers professionals, for example, already used and perfected this model before PCs were invented. They called it requester/server pairs. Tandem used an environment called Pathway in which servers are configured and in which requester’s code is stored before being "pasted" onto any dumb terminal.
When someone figured to use PC power for user interface purposes, requester’s code was moved (recoded) into client applications. This made it possible to use multimedia on the client while the servers needed little or no changes.
This development, in turn, gave rise to Remote Procedure Calls. A client application could, for example, directly access a database on the server computer without having a server program previously coded to implement the IO. In order to improve on the versatility of user queries, relational databases gained a lot of acceptance. With such a decentralized base of users, it became imperative to satisfy a variety of (unpredictable) queries without constantly coding/recoding servers.
This simple client/server model is now called the two-tier architecture. Same technology, new moniker.
Soon, users became more computer literate and, of course, more demanding. The stress on servers was increasing. It even became necessary to process single transactions in more than one server machine. Multi-tier architecture was born.
In a three-tier system, for example, the middle layer can be used to monitor traffic, manage "messages", stage databases, and even process some transactions.
Programmers typically use the middle layers to monitor, queue and prioritize transactions. They can check passwords, retrieve user profiles and reroute transactions: this always happens when using an average ATM machine, for example. They can even implement protocols for accessing "strange" devices and special servers. They can "free" a client and send them results, later, when they are ready for display.
All of that revolution in client/server technology assumes that the programmer "knows" how to code communication modules between all the computers involved. Well, actually, not any more: enter the world of Object Request Brokers (ORB).
An ORB is simply an application designed to "hide" annoying communications and data exchange details from the programmer. A COBOL programmer can, for example, code an application that interacts with other applications written in different languages and residing in remote machines without being bothered by the logistics involved. All the programmer needs to know is how to "call" the ORB, which handles the dirty job. An application developed with ORB is highly portable and interoperable across languages, platforms and operating systems.
The most widely used ORBs are CORBA and COM/DCOM.
This is said of CORBA: "Using a CORBA-compliant ORB, a client can transparently invoke a method on a server object, which can be on the same machine or across a network. The ORB intercepts the call, and is responsible for finding an object that can implement the request, passing it the parameters, invoking its method, and returning the results of the invocation. The client does not have to be aware of where the object is located, its programming language, its operating system or any other aspects that are not part of an object's interface".
And this about COM/DCOM (a Microsoft technology): "Distributed COM [DCOM] is an extension to COM that allows network-based component interaction. While COM processes can run on the same machine but in different address spaces, the DCOM extension allows processes to be spread across a network. With DCOM, components operating on a variety of platforms can interact, as long as DCOM is available within the environment."
Dimandja