BT

InfoQ Homepage News Article: Workflow Orchestration Using Spring AOP and AspectJ

Article: Workflow Orchestration Using Spring AOP and AspectJ

Bookmarks

This article provides a practical example of light-weight workflow orchestration using Spring AOP and AspectJ.

Read: Workflow Orchestration Using Spring AOP and AspectJ

AOP has long been a science of discovering and modularizing cross-cutting concerns which are generally realized in the area of non-functional requirements such as error handling, logging, security, transaction. However, AOP is also an architectural paradigm which allows a radically different approach to addressing functional requirements. Using AOP, functional processes can be broken down into a set of individual activities which, in many cases, are shared across other processes. These activities are realized as a set of independent, stateless POJO's implemented as AOP advisors / interceptors. Each process instance, represented by a stateful token, passes through a dynamic chain of AOP interceptors and is advised by each one. Functional processes are then quickly and easily assembled from such modules using standard AOP configuration.

Some of the key benefits of this architectural approach include:

  • Improved understanding of functional requirements
  • Full process visibility and externalized control
  • Much looser coupling between individual components which allows for quick substitution when requirements change and promotes reusability
  • Improved testing, since each module has a well defined input/output contract and could be developed and tested individually
  • Simple, scalable performance allowed by no central point of control (i.e., BPM engine)
  • Management

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Small change

    by Tuomas Kassila /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Thanks about your very nice and interesting article! I would change an order of the lines 51-54 and 55 (at first), and then add a new 56 line with return statement. Because if executing a method does not succeed, if it is throwing an exception and there should not be false fact in the registery!

  • Re: Small change

    by Oleg Zhurakousky /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Thank you Tuomas.
    One thing to remember is that this example was greatly simplified and generalized from the actual implementation that was delivered, but here are couple of points to keep in mind.
    Although at first it might seem like each Activity delivers a single fact, in reality that is not true. Each fact is nothing more then a signal of some accomplishment therefore if you have a complex activity there could me more them a single fact registered per such Activity. However, if you decide that a particular Activity is transactional and must output all the facts or none, then you should implemented as such, but by default I am not implying transactional characteristics on fact registry, which means that a failed Activity could still register few facts based on things it managed to accomplish.

  • Branching, etc

    by D S /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Your method looks good for linear process models with conditional activities, but would you agree that most process models will also require branches and other process model features?

  • Re: Branching, etc

    by Oleg Zhurakousky /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I completely agree and in no way I think of this particular approach as replacement for BPM engine. Just a quick example on how using AOP and Spring in general, one can quickly build and orchestrate a light-weight, embedded process flow.
    Having said that, I do have to acknowledge that this sample and this article is greatly simplified from what I am currently working on along the lines of Workflow Orchestration and BPM, where branching/forking, asynchronous processes, event handling and cloud-deployable tasks are all part of the implementation.

  • Tool Support

    by John Reynolds /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Just curious on your take on Tool Support - specifically Process Visualization via BPMN or something similar.

  • Re: Tool Support

    by Oleg Zhurakousky /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    John

    That's a good question and I'll be honest, I haven't given it much thought yet. For now it's more about experimenting/prototyping with several different implementations at the conceptual level without set scope or constraint.
    However, BPMN (in my view) is notation mechanism to document and understand "business processes" while formalizing them around basic elements such as Events, Activities, Gateways, Connections etc. . . It also recognizes and formalizes various process modeling patterns such as Basic Control, Branching and Synchronization, Iteration etc. . . However, BPMN doesn't mandate an implementation model (although one might argue this from BPEL perspective). In any event, I am currently more curious in trying to experiment with different (lighter-weight) approaches of implementing such concepts and patterns outside of current execution models implemented around BPEL. So, although I don't see any conflict in how Business process is documented (BPMN or Flow Chart), I am drawing a clear separation between Process Modeling and Process Execution.

  • Re: Tool Support

    by Suresh K /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Isn't this Chain of reponsibility pattern?

    I am somewhat confused as to whether AOP is really adding any advantage to a simple bean doing the same.
    [code]
    <bean id="workflowExecutor" class="com..WorkflowExecutor">
    <property name="processors">
    <list>
    <ref bean="bean1"/>
    <ref bean="bean2"/>
    <ref bean="bean3"/>
    </list>
    <processors></processors>
    <bean></bean>
    [/code]
    I am not advantage of AOP but in this particular case, is it really needed to facilitate the activities?
    </property></bean>

  • Scalability

    by Tom McCuch /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Since AOP is bound to a single JVM, have you thought about how this light-weight BPM can scale to support high-concurrency?

  • Re: Tool Support

    by Oleg Zhurakousky /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Well
    As far as AOP adding any advantage is rater objective and is up to the community to decide.
    Having said that. . .
    In your example WorkflowExecutor must maintain the code to build the list (although Spring's property editor will take care of it) of activities, then it has to iterate through it and invoke each activity etc. . . In other words you are defining the execution model, which in AOP you don't have to since AOP already defines the execution model to trigger invocation of every interceptor in the order they were defined. Second, in your example, bean1,2,3 seem to be invoked without any rule, unless the rules are programmatically maintained by WorkflowExecutor. Applying second layer of AOP allows you to introduce control and transition governance model separate from the execution model. It also allows you to introduce transition changes without changing individual activities.

  • Re: Scalability

    by Oleg Zhurakousky /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    In this case it's really not about AOP, but rather about the transitioning between the activities which is strictly goverend by the registered facts.
    AOP in this particular example is just an enabler to address two concerns:
    1. Execution and direction of the activities
    2. Activity transition which is based on the facts

    Concurrency and parallelism comes from the actual implementation of the Activity and Transitioning interceptor(s)
    Let's assume the process made of 3 activities A, B and C. Following the formula described in the article let's say it looks like this:

    ProcessContext = A(d-1, 2; p-3) -> B (d-1, 3; p-4, 5) -> C(d-4, 5);

    Let's say Activity B is implemented as asynchronous activity which means that B and C will be invoked "almost" concurrently. However C depends on the facts that must be registered by activity B, which most likely will not be present in the fact registry when C is invoked so it will be skipped. Activity B, however based on its implementation could easily, upon completion and fact registration, resubmit the actual process, thus allowing activity C to complete. You could also implement the wait with timeout inside of transitioning interceptor allowing activity C to wait for required facts. Don't forget, activities could register more then one fact throughout its execution which means that while activity B is still executing it might register enough facts to allow activity C to begin its execution before B is actually finished.
    As for multiple VMs, activities do not have to be bound to the single JVM and could reside in the distributed environment, as long as they are reachable by some remoting mechanism(i.e., RMI or going all the way to utilize technologies such as Terracota, GridGain etc. . .)

  • Re: Scalability

    by Suresh K /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    bean1,2,3 are equivalent of your *filter beans.

    Nevertheless, I completely agree with your solution.

    Ah! Execution Model is handled by AOP in your example. My question was more around the benefit provided by AOP for this particular use case - "light-weight" workflow orchestration solution.

  • Re: Scalability

    by Oleg Zhurakousky /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    There are two layers of AOP.
    1. Execution (functional)
    2. Transition/orchestration (non-functional)

    Read the previous post for more details.

  • What about debugging?

    by Ze Ro /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    We are currently using Ant as kind of "workflow engine" in a project(don't look at me). The problem is that Ant seems to start new processes for some tasks, which makes debugging of a whole "process" impossible.
    I want to re-design the project to a single process model based on Spring. This article is really great and gave me a lot of ideas, but:

    1. What about debugging? Is Aspectj debuggable with load time weaving?

    2. I am not experienced in AOP (know the principles), so all the configuration is a bit hard to catch. I need an *easy* way to design new processes with exisiting Activities. This example does not look like easy and I think I would rather prefer Suresh's version of defining a process, since it's more intuitive and easier to grasp (although from the SW architectural point of view I understand the good ideas behind the Oleg's article).

    Thanks, Roman

  • Transaction

    by Gustavo Stachera /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    First of all, congratulations for the article. I was looking for some solution to fix my project issues and this design looks like Kaleesh with her dragons saving me from the White Walkers.

    But, before start my refactoring, I really would like a suggestion about how to deal with Spring Transitions, for example, if I have some Activities in my Process that I would like to set with Transitions, and others without. How does the workflow can deal with the problem?

    Could you give me any advice?

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT

Is your profile up-to-date? Please take a moment to review and update.

Note: If updating/changing your email, a validation request will be sent

Company name:
Company role:
Company size:
Country/Zone:
State/Province/Region:
You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.