The Aspect Pattern
Richard Shapiro, John Zinky, Paul Rubel
BBN Technologies, a Verizon company
Cambridge MA 02138
By dynamically chaining together a series of delegating wrappers around a collection of base instances created by Factories, a
simple but effective form of Aspect Oriented Programming (AOP) with dynamic weaving can be constructed directly in ordinary
OOP languages like Java and C++. This form of AOP is particularly beneficial in the handling of dynamic adaption in
Consider the problem of adding dynamic quality of service (QoS) to the message-passing infrastructure of a
distributed agent-based system built on a Component Model (see COUGAAR: http://www.cougaar.org/). The
core structure of message passing is straightforward: find the destination Agent, choose an appropriate protocol,
establish a connection if necessary, and send the data. Queues would probably be useful at several points to
ensure that messages are processed in order and to prevent threads from blocking. One workable message flow
Sending Agent => Send Link =>
Send Queue [per sender] =>
Destination Queue [per destination] =>
[protocol-specific send-side processing] =>
[protocol-specific receive-side processing] =>
Receive Link [per destination] => Receiving Agent
The Send Link and Receive Link are simply service entry and exit points. The Send Queue keeps messages in
order and detaches the caller's thread from the message-processing thread. The Router finds the appropriate
Destination Queue for the message, and detaches the Send Queue thread from the Destination Queue threads.
The Destination Queue selects an appropriate protocol for the communication, attempts to send the message
with that protocol and handles retries if necessary. The Deliverer finds the Receive Link for the message. The
protocol-specific processing might, as one example, resolve a remote reference using a name-server and make a
CORBA remote call on the send side, and invoke the Deliverer from the CORBA servant on the receive side.
This structure is simple, modular and easy to maintain, but nonetheless provides a fairly general solution for
point-to-point communication using a range of potential protocols. Although sufficient for the most common
case, such a structure is also too simple for other useful cases (eg multicast) and too rigid for an adaptive
system. In a real-world system it would need extensions of various sorts, to be mixed and matched under
For example, suppose we need to add support for multicast. One approach would be to create a special
11/6/02 9:35 AMThe Aspect Pattern
Page 1 of 7http://stout.bbn.com/~rshapiro/aspect-plop-final.html
In common with other forms of AOP, the primary benefit provided by the Aspect Pattern is separation of
concerns, the ability to encapsulate the implementations of distinct software concerns. This greatly improves the
maintainability and extensibility of large software systems.
On the other hand, the Aspect Pattern has two significant liabilities:
The Aspect Pattern offers three additional benefits vis-a-vis other approaches to AOP:
Dynamic code-weaving. The implementations of the various concerns are selected and combined at run-
time in the Aspect Pattern, not at compile or configuration time.
Dynamic meta-data. The dynamic selection of concerns in the Aspect Pattern can be communicated
between processes in a distributed system.
Ordinary programming languages. The Aspect Pattern is written directly in ordinary program languages
like Java and C++ and requires no third-party preprocessors or code generators.
Delegation only. Full AOP tools are more flexible and general than the Aspect Pattern, which is
restricted to implementations that can be combined by delegation.
Modifications to existing code-base. Full AOP tools do not require any modifications to an existing
code-base. With the Aspect Pattern, factories must be modified to use the Aspect Attachment Service.
11/6/02 9:35 AM The Aspect Pattern
Page 7 of 7 http://stout.bbn.com/~rshapiro/aspect-plop-final.html