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.
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.
