Why AOP?


AOP extends the traditional object-oriented programming (OOP) model to improve code reuse across different object hierarchies. The basic concept in AOP is an aspect, which is a common behavior that's typically scattered across methods, classes, object hierarchies, and sometimes even entire object models. For example, metrics is one common aspect. To generate useful logs from an application, you have to sprinkle informative messages throughout the code. However, metrics is something that your class or object model really shouldn't be concerned about. After all, metrics is irrelevant to your actual application: It doesn't represent a customer or an account, and it doesn't realize a business rule. It's an orthogonal behavior that requires duplicated code in traditional OOP systems.

In AOP, a feature such as metrics is called a cross-cutting concern, as it's a behavior that cuts across multiple points in your object models yet is distinctly different. As a development methodology, AOP recommends that you abstract and encapsulate cross-cutting concerns into aspects.

In the context of enterprise middleware, container-managed services are cross-cutting concerns. Once deployed, each J2EE component (for example, an EJB or a servlet) automatically gets services, such as logging, security, and transaction services, from the container. Those services are orthogonal to the core business logic. The application developers could reuse those services without writing any code. The J2EE services have the basic characteristics of aspects, as discussed earlier. However, compared with a true AOP solution, the J2EE services model has a number of limitations:

  • The J2EE component classes must implement certain base classes or interfaces in the J2EE framework. It is impossible for components to inherit from each other. Therefore, it is difficult to build a complex OOP system based on those components.

  • The J2EE infrastructure code and deployment descriptors are complex. They are designed for fully distributed services and are overkill for many smaller-scale middleware applications.

  • You cannot extend the J2EE container for services that are not shipped with the application server.

  • You cannot use J2EE services in standalone applications without the J2EE application server.

JBoss AOP helps you solve all these problems. It works with plain old Java objects (POJOs) as opposed to predefined components. JBoss AOP allows you to apply EJB-style services to POJOs without the complex EJB infrastructure code and deployment descriptors. You can develop new aspects and deploy them into the application server for all applications to use. That essentially extends the existing container services. You can also use JBoss AOP in standalone Java applications. You can find a detailed introduction to AOP and the JBoss AOP framework on the JBoss website at http://www.jboss.org/products/aop.



JBoss 4. 0(c) The Official Guide
JBoss 4.0 - The Official Guide
ISBN: B003D7JU58
EAN: N/A
Year: 2006
Pages: 137

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net