Behind the Scenes of the Distributed Application Architecture (Magic xpa 2.x)
Usually, when you install Magic xpa, you don't have to know how the distributed application architecture is set up. However, sometimes when working with a Rich Client or Browser project, it can be helpful to understand what is happening behind the scenes, so that you can tweak some of the settings.
The following image displays Magic xpa's distributed application architecture. Below is an explanation of each of the steps.
-
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 receives the request and assigns a request ID to the client's request.
-
The broker scans its list of servers (*) to find a server that is not busy. This is prioritized based on the EnginesPriority parameter in the mgrb.ini file. If the parameter is not defined, the order of servers is decided by the broker.
(*) When the server starts up, it notifies its broker that it is available. The server proceeds to listen on a known port.
-
The broker informs the requester which engine is available.
If all the engines are busy, the event is added to the broker's request queue.
For synchronous requests, during the request process, the client must wait for the Runtime engine to return the request results.
For asynchronous requests, the client must query the broker to receive request results through the use of its request ID.
-
The client's request (including the request ID and the engine's address) is sent to the engine. During the execution of the request, the engine sends "I'm Alive" messages to either the broker or the client, at intervals of ServerTimeout seconds. A Server Timeout second is a value that the client sends along with the request.
The requester now works directly with that engine, and the broker is no longer involved. This is the scenario for synchronous requests (Call Remote: Wait=Yes).
For asynchronous requests (Wait=No or command line requester: mgrqcmdl –app=x –prg=y –nowait), the requester does not wait for the results before resuming operation. The broker does not return the engine's address to the client, nor do the client and engine communicate directly.
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.
|
Note:
|
The Magic xpa Runtime engine can handle a request from only one broker.
If enterprise servers are available to serve asynchronous requests, and yet there is a delay until the request reaches the enterprise server for execution, it is most likely to be a case of host name resolving, meaning that the broker cannot resolve the host name of the enterprise server. It is the administrator’s responsibility to verify that the host name of the enterprise servers are known on the computer on which the broker was activated.
The Magic Request Broker can be set to run on the same system with the Magic xpa engine instances or on different systems. No separate setup is required, because in both cases the communication between the MRB and the Runtime engine is done via TCP/IP sockets.
|
