In Java EE, there is rarely an obvious use case for AOP.
According to Wikipedia, aspectoriented programming aims to separate reusable functionality from the business logic:
Aspects Are Commodities The integral parts of the Enterprise JavaBeans (EJB) 1.0 specification (JSR 318) in early 1998 were aspects. The developer had to develop the Bean class and the Remote and Home interfaces but none of the cross-cutting aspects. Threading, pooling, security, transactions, session handling, and even persistence were configurable aspects cleanly separated from the business logic.
The cross-cutting functionality was configurable in the early EJB 1.0 days with POJOs.
With the advent of EJB 1.1 and J2EE, Java classes were replaced with XML, and the recent Java EE 5 and Java EE 6 specifications made XML optional. You can configure the vast majority of all use cases with annotations and override them with XML.
Although the whole EJB 1.0 idea was based on aspects, you will find only two mentions of the word aspect in the original specification in different contexts.
AOP and EJB 1.0 were “invented” nearly at the same time.
In J2EE, the configurable decoration of an EJB bean with, for example, transactions was just an integral part of the development experience. Other frameworks
provided the same functionality but called that functionality AOP.
You will have a number of aspects by defining a simple EJB 3.1 bean. For example, a stateless EJB 3.1 bean comes with transaction and lifecycle aspects out of the box.
The method greet() is never invoked directly. The container dispatches the invocations to free EJB instances from the pool. Also, transactions are started before each method invocation.
The method call is processed by a chain of default and configurable aspects until it reaches the actual business logic. Outside the application server, you would probably implement the same functionality with the decorator pattern or with a more generic solution, such as AOP.
* For complete article by Adam Bien in Java Magazine check it out here
According to Wikipedia, aspectoriented programming aims to separate reusable functionality from the business logic:
“In computing, aspectoriented programming (AOP) is a programming paradigm which aims to increase modularity by allowing the separation of cross-cutting concerns. AOP forms a basis for aspect-oriented software development.”AOP was a hot topic a few years ago, but it never really took off in J2EE—and for good reason.
Aspects Are Commodities The integral parts of the Enterprise JavaBeans (EJB) 1.0 specification (JSR 318) in early 1998 were aspects. The developer had to develop the Bean class and the Remote and Home interfaces but none of the cross-cutting aspects. Threading, pooling, security, transactions, session handling, and even persistence were configurable aspects cleanly separated from the business logic.
The cross-cutting functionality was configurable in the early EJB 1.0 days with POJOs.
With the advent of EJB 1.1 and J2EE, Java classes were replaced with XML, and the recent Java EE 5 and Java EE 6 specifications made XML optional. You can configure the vast majority of all use cases with annotations and override them with XML.
Although the whole EJB 1.0 idea was based on aspects, you will find only two mentions of the word aspect in the original specification in different contexts.
AOP and EJB 1.0 were “invented” nearly at the same time.
In J2EE, the configurable decoration of an EJB bean with, for example, transactions was just an integral part of the development experience. Other frameworks
provided the same functionality but called that functionality AOP.
You will have a number of aspects by defining a simple EJB 3.1 bean. For example, a stateless EJB 3.1 bean comes with transaction and lifecycle aspects out of the box.
The method greet() is never invoked directly. The container dispatches the invocations to free EJB instances from the pool. Also, transactions are started before each method invocation.
The method call is processed by a chain of default and configurable aspects until it reaches the actual business logic. Outside the application server, you would probably implement the same functionality with the decorator pattern or with a more generic solution, such as AOP.
* For complete article by Adam Bien in Java Magazine check it out here
Main benefit of decorator is that it affect only individual object and not all object which itself a big control and flexibility inheritance doesn't offer. See here for another example of decorator pattern in Java.
ReplyDelete