Related Topics: SOA & WOA Magazine

SOA & WOA: Article

AOP-Enabled ESB

Updating The Enterprise Nervous System

The rules engine evaluates the rules against the state of the system. The rules are defined in XML and are loaded at startup. The rules are grouped into rule sets. (See Listing 4). Each rule consists of parameters, zero or more conditions, and a consequence. The parameters define the classes in the RuleSession that will be used in the conditions and consequence.

For example, the Event object published by the EventInterceptor will be the root container of all objects used in the rule. Since the objects contained in the event are entity beans their relationships to other objects can be traversed by the rules to retrieve additional system data relevant to evaluating the state of the system. If a rule evaluates to true, then logic is executed that will invoke the next services in the business process. Those services will in turn publish their own events. Since the MDB uses container-managed transactions all the services invoked by rules will be part of the same transaction. Furthermore, the rules are evaluated asynchronously with regard to the session bean that fired the event. So the service doesn't have to wait for all the rules to complete.

The onSubmitOrder rule tests the source and name of the event. It then extracts the Order from the event and invokes the OrderService provision operation. The onProvisionOrder rule initiates a manual step in the business process by using the TaskService to assign someone with the "Shipper" role to ship the order.


Using this approach, developers can focus on the true intent of their services and a business is free to change the rules to stay in tune with business drivers. The service operations are focused on the atomic unit of functionality that they must provide. They aren't burdened by tedious plumbing code for publishing events to the bus and they are decoupled from the rules about how they might interact with other services.

The architecture is also extensible. Services can be added and removed without breaking other services. Rules can be added, changed, and removed without modifying the services. Any number of JMS subscribers can be added to the bus. Some examples might be: additional rules engines, an AuditMDB that logs all events, an IndexerMDB that indexes all the entity beans contained in an event for access by search engines, or a DataSummarizationMDB that loads a data warehouse in real-time. Legacy services can also be enhanced by AOP to publish to the bus without modifying the code.

The biggest payoff is when this approach is scaled up and plugged into a federated peer-to-peer network of JMS providers. Each JMS provider broadcasts its presence to the others. Events then flow across the ESB from provider to provider the way e-mail flows through mail servers and packets flow through routers. As a result, services are free to be composed into enterprise-wise business processes without upfront knowledge or modification and without being coupled into a monolithic monster. All you have to do to prepare for this is add a little AOP to your services.


  • Demystifying the Enterprise Service Bus -
  • 12 Steps Toward SOA -
  • EJB 3.0 Tutorial -
  • JSR-94 Rules Engine Specification -
  • Drools Rules Engine -


  • Introduction to Aspect-Oriented Programming -
  • JBoss AOP -
  • AspectWerkz -
  • AspectJ -
  • Nanning -


    What AOP Entails

    Aspect Oriented Programming (AOP) is the name given to the approach of dynamically inserting new code into existing code. Typical uses of AOP are referred to as crosscutting concerns. These are secondary requirements that need to be applied consistently across all code. Classic examples are logging and security. Other examples can include persistence, validation, caching, and, in this article, publishing an event to a JMS topic.

    The actual code that's inserted is referred to as the advice and it must adhere to a particular method signature. The advice is inserted around the existing code at a point-cut. Point-cuts are defined in one of two ways. Most frameworks use XML and regular expressions to define where the advice should be inserted. This is good for enhancing existing or third-party code whose source code you don't have access to. With the addition of Annotations to Java 5.0 it's now possible to define point-cuts in the code. This is the approach used in EJB 3.0.

    The combination of a point-cut and the advice make up the aspect. Your code can be enhanced with the aspect at either runtime or compile time. At runtime the classloader works with the framework libraries to manipulate the bytecode based on the XML descriptor or the annotations. At compile time a second compilation step is needed in which the framework's compiler enhances the classes generated by the javac compiler.

    Both approaches have their benefits. Compile time avoids the extra startup cost demanded by the runtime approach, which enhances a class when it's first loaded. However, EJB 3.0 implementations use the runtime approach so their aspect framework can be used with standard annotations. This way you don't have to compile your EJBs for every application server.

  • More Stories By John Gilbert

    John Gilbert is a consultant with 12 years of experience as an architect of service oriented systems. He holds a master's degree in software engineering from George Mason University and is an avid proponent of open source software.

    Comments (0)

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.