Java Reference
In-Depth Information
What's aspect-oriented programming?
Aspect-oriented programming is a programming methodology that's rather different
from the object-oriented programming most of us know and love. In object-oriented
programming, you try to identify groups of data that represent state and encapsulate
them within an object. In aspect-oriented programming, you try to identify common
problems or functions (usually known as cross-cutting concerns) and encapsulate
them within aspects. These aspects (sometimes known as
advice
) are then
woven
into the code at points defined by
pointcuts
.
Aspect-oriented programming is a powerful mechanism for adding common code to
objects, removing the need for them to declare it directly. This can significantly simplify
the code within the object, and is particularly useful for things like logging and trans-
actions, which are typically orthogonal to the main purpose of the running method.
You've already seen how to use the Aries transactions project to add declarative trans-
actions to Blueprint beans in section 3.3.6, but it's worth looking at the following list-
ing to see how Blueprint compares to Spring.
Listing 11.6
Controlling transactions with Blueprint
<?xml version="1.0" encoding="UTF-8"?>
<blueprint
xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
xmlns:jpa="http://aries.apache.org/xmlns/jpa/v1.0.0"
xmlns:tx="http://aries.apache.org/xmlns/transactions/v1.0.0">
<bean id="inventory" class="fancyfoods.persistence.Inventor
yIm
pl">
<tx:transaction method="*" value="Required"/>
All methods require
transaction
</bean>
</blueprint>
As you can see, it's easy to add transactionality to Blueprint beans using the Blueprint
transactions namespace, as Spring beans can with the Spring transactions namespace.
Because of their equivalent levels of function, it's entirely possible to move between
Aries Blueprint and Spring's transaction syntax as necessary.
11.3
Summary
We've now covered a broad range of migration strategies for a variety of enterprise
module types. We hope that you agree that moving enterprise applications to
OSG
i
need not be an impossible, or even painful, process. The new standards introduced by
the
OSG
i Enterprise Expert Group and the extensions provided in the Apache Aries
project allow for many commonly used technologies to be migrated easily, often with
no code changes.
In cases where migration
is
difficult, or where you don't wish to migrate away from
the existing system but do want to use
OSG
i for other parts of the application, then
