At the simplest level, Dynamics AX is designed as a three-tier architecture and requires three main components to function: a database server, an application server, and a client.
The database server performs two roles; it hosts both the business database and the model store database. The database server must be a supported edition of Microsoft SQL Server.
The application server is referred to as the Application Object Server (AOS) or AX Server. This provides many services, including web services, to the client Windows AX.
The Windows AX client is the application that the users use to perform their tasks. It also allows us to access the integrated development environment (IDE).
All requests for application elements (such as forms) and data are made to the AOS through remote procedure calls (RPC) or the Windows Communication Foundation (WCF). There is no direct communication between the client and the SQL Server. All data goes through the AOS; this is fundamental to the design. It ensures that all of the business logic is common across all clients and enforces data integrity and security.
The following diagram, which has been recreated from Microsoft TechNet, highlights this:
The full details can be accessed at http://technet.microsoft.com/en-us/library/dd362112.aspx.
The element named Application pages using MorphX forms in the preceding diagram represents the vast majority of all content viewed within the Windows AX client, for example, the Sales order details form.
Note
All forms written within the AX client development environment under the Forms node are MorphX forms; they may include .NET controls such as Print preview and custom .NET controls.
The client primarily uses RPC for communication between the client and the AOS, but certain elements within the client use WCF; for example, the Report viewer control. Applications such as Microsoft Office, SQL Server Reporting Services (SSRS), and custom applications also use WCF. These applications access services that are hosted by the AOS.
Much of the complexity is hidden from us, and we do not have to remember every nuance of the integration between the tiers. Gaining an understanding of the structure, however, is important.
For example, we will later be writing code that will run on a specific tier (AOS or client). In this case, it is important to pay attention to where the objects are instantiated and how they are marshalled between the client and server.
The model store is a database hosted by the same SQL server as the business database. It is always named after the business database and suffixed with _model. For example, if the database is called MsDynAXLive, then the model store database is called MSDynAXLive_Model.
This model store contains the application code and metadata. The application code is stored in both the source code and compiled forms. This means that all objects in the AOT, such as database table definitions, forms, classes, reports, and Visual Studio projects, are stored in this database.
Note
There are many benefits of this design, one of which is that it is now more easily handled as part of our high availability and disaster recovery plans.
Each element (such as a class, method, database table, field, and so on) has an element ID. These have many uses, which are mainly internal. One such use is for handling the link between the elements' stored table definitions and the physical table definition within SQL Server.
The primary language for development in AX is X++, and it is syntactically similar to C#. AX compiles code as required to its intermediary language, p-code. This p-code is AX's native object code and AX will execute most code in this way. The compiled code stored in the Model store database is p-code.
Microsoft introduced a .NET Common Intermediate Language (CIL) compiler to AX 2012. This allows AX code to run under the .NET runtime and achieves better performance. This does not replace the p-code, and is generated from the compiled p-code—not directly from the source code.
Note
This means we have two sets of executable code, p-code and CIL. The form-level logic still uses p-code, but some table events and server-side code and all of the code accessed through WCF will run the CIL-compiled code.
CIL generation also creates physical DLLs and updates the WCF services (both those hosted by the AX Service and those hosted by IIS).