An Aspect-Oriented Approach - Autonomics Development: A Domain-Specific Aspect Language Approach - page 56

• Increased performance (compared to a purely reflective implementation) by
deploying reflection using aspects only where required.
Surajbali et al. [105] argue that the reflective middleware approach is limiting as
the reflective APIs have been found to expose a steep learning curve and places
too much expressive power in the hands of developers. Instead their approach
is to build an AOP support layer on top of an underlying component-based re-
flective middleware substrate. Surajbali et al. [105] provide an implementation of
their model using the OpenCOM component model and the GridKit middleware
platform and claim their approach provides the following benefits [105]:
• The complexity of the reflection layer is hidden from programmers.
• The AOP support layer can be dynamically deployed and undeployed when
required thereby avoiding overhead when not in use.
• As the AOP support layer is constructed from OpenCOM components like the
rest of the system, the underlying middleware system and the AOP support
layer can be the target of an advice.
• As distributed dynamic aspects are supported, aspects can be dynamically
deployed across a distributed system on the basis of distributed pointcut
expressions.
Greenwood and Blair [44] have proposed the use of dynamic AOP to imple-
ment autonomics. This approach allows adaptions to be encapsulated as aspects,
thereby allowing adaptions to be contained and applied retrospectively at runtime.
Greenwood and Blair's implementation [45] uses the AspectWerkz [16]dy-
namic AOP framework combined with reflection and a policy framework to define
adaptive behaviour based on Event-Condition-Action rules.
3.8 AOP and the Distribution Concern
Several attempts have been made to apply distribution aspects to existing Java
code. These attempts typically target a single distribution protocol, RMI, and
either generate code in the general purpose aspect language, AspectJ [18, 91, 114],
use a domain-specific language [66, 73], extend Java [83], or extend the AspectJ
language to provide distribution [74].
While RMI is the most widely used distribution protocol in Java systems and
is used as the protocol for Enterprise JavaBeans (EJB), Jini and JavaSpaces, there
are a number of other distributed systems, such as CORBA, JMS, SOAP, HTTP,
Java sockets etc. that Java programmers may choose to use and indeed may have
to use to solve a particular integration problem.
Programmers therefore have a large choice of protocols, each with its own
framework and possibly different programming convention. This significantly com-
plicates distributed systems development.