Lightweight Embedded Process Flow Using AOP with Spring and AspectJ

The article introduces the need for a lightweight, embedded process‑flow engine that can be easily configured, extended, and maintained without the overhead of a full BPM system. It proposes using Aspect‑Oriented Programming (AOP) techniques, specifically Spring AOP and AspectJ, to assemble and orchestrate such flows.

It defines the essential elements of a process: activities, shared data/context, transition rules, execution decisions, and optional initialization data. Activities are stateless workers that operate on a token representing shared data.

The Activity interface is defined as:

public interface Activity {
    public void process(Object data);
}

The shared data token can be any object, commonly a java.lang.Object or a structured type like Map.

Process execution is modeled as a chain of intercepting filters (activity filters). Each filter can pre‑process, redirect, post‑process, or replace the request/response, similar to the Intercepting Filter pattern used in servlet filters.

Two AOP layers are employed:

Functional AOP Layer (Spring AOP) : assembles the ordered filter chain and delegates to POJO activities.

Non‑Functional AOP Layer (AspectJ) : evaluates fact‑based transition rules to decide whether a filter (activity) should execute.

The GenericProcess class serves as the target object for the filter chain:

public class GenericProcess {
    public void process(Object obj){
        System.out.println("executing process");
    }
}

An around advice in TransitionGovernorAspect compares registered facts with rule conditions to either proceed with or skip the activity filter.

A concrete use case, Purchase Item , demonstrates three activities: validate item quantity, obtain credit authorization, and delivery. Facts such as VALIDATED_ITEM and CREDIT_AUTHORIZED control the flow, allowing activities to be skipped or resumed without manual orchestration.

Configuration snippets (shown as images in the source) illustrate:

Spring AOP pointcut definition for GenericProcessImpl.execute(..).

Three ActivityFilterInterceptor beans linking POJO activities with fact rules.

Bean definitions for the POJO activities themselves.

Testing involves obtaining the ApplicationContext, creating a fact registry, preparing a context map, and invoking process(). The test is run with the JVM -javaagent:lib/spring-agent.jar option to enable load‑time weaving.

Results show that when the fact registry is empty, activities execute sequentially; when facts are pre‑registered (e.g., uncommenting // factRegistry.add("VALIDATED_ITEM");), the corresponding activity is skipped, demonstrating dynamic flow control.

The conclusion emphasizes that a two‑layer AOP approach provides a lightweight, embedded process engine without requiring a separate BPM system, offering loose coupling, easy testing, OSGi compatibility, and reusability of activities.