.NET Remoting and Delphi - Benefits of Multitier Application Development
(Page 3 of 11 )
A multitier design offers several advantages over two-tier client/server designs, although it is probably more complex to understand and implement.
Scalability and Fault Tolerance
The first and most prominent advantage of multitier architectures is scalability.
Client/server systems depend on a central database server and require permanent connections to be present. The more clients, the worse the server will perform because of the increased resource consumption (that is, network connections constantly open, frequent access to tables, cursors, and so on). Client/server systems aren't usually capable of handling more than a couple of hundred concurrent users in an efficient manner.
By having a middle tier composed of multiple servers (cluster), you will be able to divide the workload between them and only hit the database server when really needed. By implementing caching techniques, you could also minimize access to what is strictly necessary, increasing overall performance.
Figure 29.5 shows two (or more) clients accessing a cluster of two (or more) servers, which, in turn, are connected to a single database server.
Figure 29.5
Multitier cluster model.
In order to benefit from clustering, your clients will need to operate in a disconnected fashion and only connect to the middle-tier when they need to read data or send some updates. Regardless of the status of the remote machine—which could have become irresponsive or have been shut down for maintenance—this ensures that the client will continue to function by using another server.
From a server perspective, this approach is called stateless. The server only has a means to communicate with clients when they initiate a call. Once this is completed, the client ceases to exist for the server.
If you are familiar with Web development, you will find many analogies: Stateless design is almost mandatory when you need high scalability and have large numbers of concurrent clients.
We will explain how remote objects are instantiated later in the sections "Server Activation" and "Client Activation." In order to ensure that your system is highly scalable, you'll have to use one of the two Server Activation models (SingleCall or Singleton). If you need a more coupled, but less scalable and certainly not clusterable approach, you could instead decide to tie a client to a specific instance of an object residing on one server, using Client activation.
Note - You can find .NET specific articles on distributed architectures at http://msdn.microsoft.com/architecture/
Development and Deployment
In client/server systems, business processing is mostly done on the client applications—sometimes with the help of stored procedures running on the database server.
Unfortunately, because stored procedures are more complex to write and debug than Delphi code, they are not used extensively—especially in companies that don't have a dedicated database administration staff.
If the number of clients is large, updating each desktop with a new copy of the client executable might be laborious and error prone.
In multitier systems, a big part (if not all) of business processing happens in the middle tier. The applications running on the middle tier are simple to write (Delphi code), and, once updated, all clients automatically benefit from fixes or enhancements without the need for redeployment.
Somebody might argue that having an executable placed on a shared network drive could be just as easy to update, but consider what would happen if a workstation is keeping the file locked or if you needed to access it from an office in another city.
Security
Because clients don't directly communicate with the database, it becomes much easier for administrators to enforce programmatic security into their applications and protect the database from unauthorized access.
The request made by clients can travel, encrypted, over SSL connections. Methods of business objects can return less data to clients based on session information: This would be transparent to the caller and changeable over time without the need to redeploy the clients.
 This chapter is from Delphi for .NET Developer's Guide, by Xavier Pacheco (Sams, 2004, ISBN: 0-672-32443-1). Check it out at your favorite bookstore today.
Buy this book now. |
Next: .NET Remoting Basics >>
More .NET Articles
More By Xavier Pacheco
