Advising Components Managed by Spring

In the previous section, you refactored the service entry point to use a Spring-managed bean. Now I'll show you how that could help you improve your component and implement new features.

First of all, imagine that users would like to see the prices for symbols that are not managed by your
TradeManager component. In other words, you would need to hook up to an external service for retrieving the current market price for requested symbols that you don't currently handle. As an example, you can use a free HTTP-based service from Yahoo portal, though a real application would hook up to the data feed from vendors that serve real-time data, such as Reuters, Thomson, Bloomberg, NAQ, and a number of others.

Begin by creating a new
YahooFeed component that implements the same
TradeManager interface, and that pulls the price information from the Yahoo finance portal. A naive implementation can send an HTTP request using
HttpURLConnection and then parse the response using regular expressions. For example:

After this implementation is finished and tested (outside of container!), you can integrate it with other components. Traditionally, one would add some code to the
TradeManager2Impl to check the value returned from the
getPrice() method. This would at least double the number of tests and will require you to set additional preconditions for each test case. However, using the Spring AOP framework, you can do this in a nice way. You can implement an advice that will use the
YahooFeed component to retrieve the price if the original
TradeManager returns no value for the requested symbol (in this case it is just
null, but you may as well catch a
UnknownSymbol exception).

To apply advice to a concrete method you'll need to declare an
Advisor in Spring's bean configuration. A convenient
NameMatchMethodPointcutAdvisor class allows you to select methods by their names, and in this case, you need a
getPrice:

As you can see, the above advisor assigns a
ForeignTradeAdvice to the
getPrice() method. The Spring AOP framework uses the
AOP Alliance API for advice classes, which means that your
ForeignTradeAdvice around advice should implement the
MethodInterceptor interface. For example:

The above code invokes an original component using
invocation.proceed(), and if it returns
null, it will call another
tradeManager injected as a constructor parameter on advice creation. See the declaration of the
foreignTradeAdvisor bean above.

Now you can rename the
tradeManager bean defined in Spring's bean configuration to the
baseTradeManager and declare
tradeManager as a proxy using
ProxyFactoryBean. The new
baseTradeManager will be a
target you will advise with the
foreignTradeAdvisor defined above:

Basically, this is it. You implemented additional functionality without changing the original component, using only the Spring application context to reconfigure dependencies. To implement similar change in a classic EJB component without the Spring AOP framework, you would have to either add additional logic to the EJB (making it more difficult to test) or use a decorator pattern (effectively increasing the number of EJBs, which will also increase complexity of the tests, as well as increase deployment time). You can see in the above example that with Spring it became very easy to attach additional logic to the existing components without changing them. Instead of tightly coupled beans you now have several lightweight components that can be tested in isolation and assembled using the Spring Framework. Note that with this approach your
ForeignTradeAdvice is a self-contained component, which implements its own piece of functionality and which can be tested as a standalone unit outside of an application server as I'll show you in the next section.