XATMI Extensions

The following sections are intended to highlight some aspects of the BlackTie system that may not be obvious from the XATMI specifications but that are in perfect conformance to the specification and allow some advanced behavior to be added to users applications.

Pluggable Transport Layer

We currently have a single transports:

1. atmibroker-hybrid - The recommended (and default) transport, supports clustering

The hybrid transport initiates communication with a single JMS message which can be processed by any service in the cluster, after the service processes the message all return communication is then handled via the CORBA transport. This gives us performance (point-to-point communication where possible) alongside clustering (as the JMS message goes to a queue that all relevant services are listening to).

Out-of-bounds Messages

It may appear that when developing a client application there is no scope for services to deliver unsolicited out-of-bounds messages to it, such as the situation on the left in the below diagrams.

However, you will be please to know that due to the lightweight nature of the BlackTie library deployed onto machines, it is as easy to collocate a simple callback service in the client as it is the BlackTie server. There are a couple of bootstrap methods that must be invoked to initialize the “server” threads within the client and therefore allow service processing to commence, but after that the client is free to act as client and server combined and as such it can receive the full support of resource managers or not as the situation demands.

Messaging based transport and disconnected operation

Along with the standard CORBA transport we have developed a messaging based transport utilizing JBoss Messaging accessed via StompConnect. This allows queuing behavior to be fully supported by BlackTie, even better this is all using the standard XATMI RPC and Conversational operations such as tpcall, tpacall, tpgetrply, tpsend, tprecv!

The following diagram illustrates how the BlackTie framework handles requests for service on behalf of the client tpcall operations:

As can be seen, the support for disconnected operation (e.g. where service “svc” in the diagram is temporarily unavailable) is supported by the use of administered objects such as queues or topics managed by JBoss Messaging.

If the reader considers the situation where instead of tpcall, the method tpacall is issued with the TPNOREPLY flag then the requests can easily remain queued for an extended period of time until svc is brought back online.

Furthermore, if the reader also considers that the client can similarly be invoked (as shown in the previous session) with out-of-bounds messages then this allows the entire enqueue, dequeue messaging primitives to be accessible using the XATMI operations.

A final note related to messaging is that it is not strictly necessary to use a “Queue” (i.e. one message to one receiver messaging) to relay XATMI requests. It is also possible to use a “Topic” (i.e. one message to multiple receives) for broadcasting of XATMI requests to several services (or clients).

Priority-based Load Balancing

The BlackTie configuration allows service handler pools (those parts of BlackTie retaining a thread to invoke tpservice using) to have their size of pool be configured on a per service basis. This allows high-priority services to have a higher likelihood of service to the lower priority services as defined by the application developer.

In the previous figure you can see that the high-priority service of the application (in this case a trading application) is configured with 5 service handlers, whereas the low-priority service (the quote service) has only 2 service handlers.

NOTE This does not have strict guarantees over actual numbers of invocations but does provide an ability for the designer to indicate their intended distribution of service invocations.

Click to go on to BlackTie Architecture (Page 5)