Reason # 18: Distributed Application Architecture

20 Reasons to Migrate Magic eDeveloper, uniPaaS and Magic xpa to .NET by Upgrading Rather than Converting

Magic xpa Application Platform utilizes a Distributed Application Architecture that offers a high level of choice between different computing environments. The interoperable nature of Distributed Application Architecture also means that Magic xpa applications have the ability to operate in multi-database, multi-platform, and multi-network data processing contexts. Using the simple interface common to all Magic xpa applications, every user, from any workstation, can access any type of local or remote database, execute queries, and update the data. As we shall see, Magic xpa Application Platform provides capabilities for distributed architecture, application partitioning, MDI, and secure communications out-of-the-box. When converting Magic eDeveloper, uniPaaS or Magic xpa to C#.NET, these advantages are lost.

In an environment where multiple computers are connected by a Local Area Network (LAN) or Wide Area Network (WAN), Magic xpa’s distributed application architectures automatically utilize a specific form of distributed processing.

Fortunately, when you install Magic xpa, you don't have to know how the distributed application architecture is set up, however you can adjust the settings if desired. The diagram below illustrates what is happening behind the scenes in Magic xpa's distributed application architecture.

The process begins when a client, such as a browser or Rich Client application, makes a request to the enterprise server. It does this via a requester, usually a Web server. Each client has its own requester.

The requester uses the broker to communicate with the Magic xpa enterprise servers. This is a Magic xpa Runtime engine (MgxpaRuntime.exe) functioning as an enterprise server. The broker scans its list of prioritized servers to find a server that is not busy and informs the requester which engine is available. If all the engines are busy, the event is added to the broker's request queue.

Once an engine has finished handling a request, the Runtime engine sends the request results directly to the client and notifies the broker that it is available to process the next client request. A check is made if there are pending requests in the queue which are for the same application as the one loaded in the Magic xpa engine. If there are pending requests, the broker extracts the requests with a higher priority and sends it to the engine.

The term application partitioning is used to describe the process of developing Magic xpa applications that distribute the application logic among two or more computers in a network. In the simplest case, the application can run on a single PC, as a remote service, and send task requests for execution to a server. In more advanced cases, the application logic can be distributed among several servers.

The first step in creating a partitioned application is choosing which components of the application run on the server system or systems. The criteria for making the choice are the components that would most benefit in performance and maintainability, if they were to run on the server. Note that the decision whether a program or task runs in the Requester Client or in the system need not necessarily be made when the application is designed, but the design must take this into consideration as only background-mode tasks are applicants for partitioning.

In Magic xpa, background enterprise servers and Online programs are multi-threaded. This gives you the ability to have parallel task execution in your projects.

Each thread accesses a different Runtime context, and does not interact with other threads. To work with multiple threads in Online programs, Magic xpa provides you with Multiple Document Interface (MDI) and Single Document Interface (SDI) functionality.

Communication between the Magic xpa client and the Web server (requester) is compressed while communication between non-Magic xpa clients (such as Web clients) and the Web server (requester) is not. The Magic xpa developer secures these communications using the https protocol. The https protocol (SSL\TLS) encrypts the communication between the client and the Web server and ensures that the server is a trusted one.

Communication between the requester, broker and engine is encrypted using Asymmetrical and Symmetrical encryption. No hard-coded keys are used and it is possible to define the Symmetric encryption mechanism and the key length.

For additional information on how an upgrade to Magic xpa is superior to Magic to .NET conversion please convert here.