elare Technologies' ATCT (Asynchronous Transfer of Control Threading) is a versatile new programming library that implements a "separation of concerns" approachone of the key precepts of aspect-oriented programmingto enable programmers and framework developers to create scalable systems capable of complex execution paths with very simple source code.
This article presents two specific situations in which ATCT makes the developer's job easier, asynchronous messaging and Java scripting. Applied to asynchronous messaging, it simplifies the structure of the code and makes it linear. Applied to scripting engines, ATCT overcomes a current limitation of the JVM. Finally, some internal details about the library are provided with a look under the hood.
ATCT and Asynchronous Messaging
Today, most asynchronous messaging technologies use some form of callback mechanism. Programmers implement one or more interfaces that define a behavioral contract with the underlying messaging engine. When the proper circumstances arise, the engine calls into the client code via a method designated for that purpose. One very popular Java messaging technology is JMS. In the case of JMS 1.1, the interface is called
MessageConsumer and the method is
onMessage(). The JMS specification guaranties that your code is invoked for each incoming message.
Figure 1 shows a sequence diagram that illustrates a generic asynchronous messaging call sequence. The concept applies, but is not limited, to JMS as the messaging engine. Other possible asynchronous messaging technologies include the upcoming SOAP 1.2.
|Figure 1: Typical Sequence Diagram for an Asynchronous Messaging System|
To better understand Figure 1, think of Step 3:
verifyCreditCard() as a request that the back end of an online travel agent would issue prior to authorizing an airplane ticket purchase. A real-life business process might include the additional steps of checking the customer's rewards point account balance or the availability of sufficient funds. This messaging approach affects the structure of the code. Firstly, it splits the process controller code: one portion sends the request while the second processes the response. Secondly, it requires glue code to maintain some internal state data between successive calls to the messaging engine. This generally takes the form of a persistence store that tracks the details of pending transactions until the response messages are received. The store itself can be anything from a simple HashMap to a relational database.
Multiply the call sequence by the number of messages necessary to implement the complete business process and the code can rapidly become unmanageable. Enter ATCT. Using this technology, programmers can turn the code showed in Listing 1 into the more maintainable code in Listing 2. The entire business process now resides inside one single method. But more importantly, Listing 2 hides the complexity of dealing with the underlying asynchronous system (see Figure 2 for an ATCT version of the sequence diagram in Figure 1). The new code is linear, flowing from one step to the next sequentially, even though some of the method calls wrap around complex asynchronous call sequences. (View the accompanying source code for more details. Although not a working sample, it illustrates the concepts described in this section.)
|Figure 2: ATCT Sequence Diagram for an Asynchronous Messaging System|
The next section covers how using ATCT with new enhancements to the JVM extends current scripting engines.