Describing the usefulness of AOP (Aspect-Oriented Programming) requires a quick detour into the philosophy behind it.AOP recognizes that objects often possess characteristics — aspects — that cut across lines of inheritance. Furthermore, aspects are intrinsic to objects; they cannot be (easily) implemented by external objects. So building shared aspects into unrelated objects using unaltered Java syntax requires replicating code in each object because Java does not allow multiple inheritance.Object persistence is a good example of an aspect. In a system implementing an object-oriented database, objects that require persistence are often derived from different parent classes. (In an object-oriented database application, persistent objects will likely be derived from different parent classes.) For example, a single database might store “Employee” and “Manager” objects, which would have “Person” as a common ancestor, as well as “Computer” and “Desk” objects, which would have “Equipment” as a common ancestor. Though both lineages of object need persistence capabilities, they have different ancestors. JBoss 4.0’s use of AOP allows a developer to endow ordinary Java objects with capabilities beyond what is otherwise possible within the bounds of ordinary Java syntax. In some ways, this is reminiscent of WebLogic Workshop, which lets you program with standard Java classes and handles all the J2EE dirty work in an invisible runtime framework. Both approaches share the notion that programmers would much rather work with “plain” Java objects most of the time, and if programmers want to give those objects special characteristics, they would rather do so in a way that keeps the already working code unmolested. Software Development