Microsoft Dynamics NAV 2009 biggest technological improvement is the migration from a client-server to a 3-tier architecture.
At my work, we received several questions from the partners about what does it mean and which are the advantages and I realized that, in general, not much is known about the multi-tier architectures, so here is a small summary.
The client-server model is a distributed application structure where the server provides a function or service and one or many clients request and consume them. This was a progress from the initial architecture where one monolithic and centralized mainframe was computing and presenting all the functions or services.
The advantage being to have clients remotely away from the main computer.
Many business applications use this model, sometimes called also two-tier architecture.
As a difference, in peer-to-peer architectures, each host or instance of the program can simultaneously act as both a client and a server, and each has equivalent responsibilities and status.
A small excursus: the layers
A suggested software engineering practice is to divide an application in layers according to their function. You can have several layers but the most common use is to have these three:
Aka user interface layer, its purpose is to show the users the data and results from a function or a service, acquire and process the user inputs, authenticate the users and in generally everything specific to user interaction.
aka domain or application or model layer, it separates the business logic from the other layers and is therefore the hearth of the application, containing all the domain rules to be applied but not the data.
aka infrastructure layer, its purpose is to store and provide access to the data, often using a database.
This tier keeps data neutral and independent from application servers or business logic. Giving data its own tier also improves scalability and performance.
Two-tier and the layers
How do you map the three layers above into a client-server architecture?
You have two possibilities:
The presentation layer is in the client. The business and the data layer are in the server.
It does not require powerful (and expensive) clients but the communication between client and server is much more and can bring to bottlenecks.
The presentation and the business layer are in the client. The data layer is in the server.
It needs a lot more resources on the client(s) but can be faster as the application resides in the client.
This is the approach of the older Microsoft Dynamics NAV clients, including the classic client.
In this the server-side consists of an Application Server and a Database Server. Thus the three tiers become Client, Application Server and Database, mapping exactly the layers discussed above.
All three tiers are relatively independent; for example you can switch to a different Application Server while maintaining the integrity of the model.
A fundamental rule in a three-tier architecture is the client tier never communicates directly with the data tier; in a three-tier model all communication must pass through the middleware (application) tier.
This is the most common architecture used by web applications: a client (the browser), the application server (such as a Web Server) and a database (such as a SQL Server) and now spreading to the enterprise applciations.
It’s also the architecture introduced by Microsoft for NAV 2009: the RTC client (presentation layer), a service tier (the business logic, the application, the web services) and the database (SQL server).
The advantages are a clear separation of the presentation and the business logic (you could change the user interface without touching the application) and cheaper clients as in the thin client but also a better scalability and a faster communication among the layers, as in the fat client.
The 3-tier architecture is the most widespread multi-tier architecture but also other kinds exist, for example the business logic layer could be split into two, adding a service layer that would be the first object beyond the User Interface layer that – through a set of high-level APIs – delegates to the domain layer which itself contains all the business processes.
Or the infrastructure layer could be split into low and high level technical services.