TIBCO Activematrix Architecture

AMSG Architecture and Message flow

Here we take a simple use-case in which a SOAP-Java Composite Service is invoked by an externalSOAP Client over HTTP. The following diagram depicts a typical message flow for an in-out message exchange for an invocation of this service.

Note :

SOAP Service and Java Component are deployed on the same AMSG node for a local Provider and on 2 different nodes (SOAP Service on one node and Java Component on another node) for a remote provider. 

Step 1:

Concurrent users send SOAP requests(over HTTP) to be serviced by a service provider in the AMSG Environment.

Step 2:
The SOAP (over HTTP) Requests from the client reach the SOAP Service in the AMSG Environment. They are serviced by the HTTP Server Shared Resource threads (HTTP Server threads) which are initialized for the HTTP Server Shared Resource configured through the AMSG Administrator. The MIN and MAX size of the HTTP Server Thread pool can be can be set through the AMSG Administrator. The default values of these properties are 10 and 75, respectively. An HTTP Server thread is allocated for each request that is concurrently executing and is released only after the response is sent back (i.e. The HTTP Server thread is blocked till the response is received). The HTTP Server thread routes the request for further processing to service provider (Java). The Java provider can be a Local Provider (residing on the same node) or a Remote Provider. For a Local Provider the message is routed directly to the appropriate provider for further processing.

Step 2a: Remote Provider: If the service provider is remote the requests are routed through the Consumer Queue on the EMS Server.

Step 3:. For Local or Remote Provider, the thread from the provider thread pool picks up the routed message for further processing. The max value of the thread pool can be set in the Node’s TRA configuration file using the property:  
java.property.com.tibco.matrix.amxframework.messaging.maxpoolsize

(This property determines the maximum thread pool size. This property is applicable to every service unit deployed on that node. A separate thread pool is created every service unit deployed on the node.)

Step 3a:Remote Provider: If Java provider is deployed on a different node, The provider pool thread acquires an available JMS session from the session-pool. It then gets the request message from the Consumer queue(on EMS) and processes the request.

The number of sessions that can be created depends on the max value specified in the Node’s TRA configuration file.

java.property.com.tibco.matrix.amxframework.messaging.sessioncount

(This property determines the maximum number of JMS sessions that may be created with the EMS server. Like max thread pool property, this property also applies to every service unit deployed on that node. A separate session pool is created for each service unit)

Step 4 Local Provider: The request is then forwarded to the Java implementation which is executed and the response is delivered.

Step 4.A: Remote Provider: If Java Component is present on a different node, as soon as the request is processed; the response is delivered to the Provider queue on EMS.

Step 5: Local Provider: The SOAP Consumer pool thread picks up the response and delivers it to the HTTP Server Thread (which is blocked waiting for a response).

Step 5.A:Remote Provider: If the Java Component was deployed on a different node, each SOAP Consumer thread acquires a session from the session pool with EMS and picks up the response delivered in the Provider queue. The response is then delivered to the HTTP Server Thread that is blocked on the response. The number of sessions that can be created depends on the max value specified in the Node’s TRA configuration file.

java.property.com.tibco.matrix.amxframework.messaging.sessioncount

Step 6:
The HTTP thread sends back the response to the external SOAP Client.