Do you want a scalable workflow processing platform?
I spent some time with a customer this week that’s using Terracotta and the Master-Worker pattern to build a scalable workflow processing platform. Very cool stuff.
The system consists of a set of application nodes (each a separate JVM running on a set of servers). The nodes are clustered with Terracotta and have two shared queues (which are “roots” in Terracotta terms). Incoming events arrive on the Message Queue and will be picked up on one of the application nodes. The message is handed to a factory that knows how to build a work plan for that event message. The plans can be either serial or parallel. The work items are then placed onto a Work Queue to be executed. Workers on the application nodes pick the work items off the queue and execute them as necessary.
The events in question are coming from the front half of the application (running on Mule) which is receiving events from RFID, GUIs, and automated systems in a variety of formats, providing some data conversion and translation and ultimately dropping the message onto the workflow grid.
The customer has a specific app in mind that will run on this system but they are also hoping to use it as a general platform for other applications that have similar patterns. It seems to me that with the rising prominence of BPM right now that there has to be a reasonably large set of applications that could benefit from this general model.
Even cooler, this customer is considering open-sourcing the application and making it available for general use. I think this would be fantastic. They are not sure whether there is enough demand out there for this kind of system for it to be worth their while. If you’d be interested in such a system, please drop a note in the comments.
Hi! My name is Alex Miller and I live in St. Louis. I write code for a living and currently work for 
hi there,
When I was reading the 1st para, I thought how nice it would be if your customer would open source it. Think of the surprise and joy when I found that they’re indeed considering it.
Can you email me if such a thing eventually happens ?
Thank you,
BR,
~A
Hi Alex,
This is real interesting.. Would be most definitely interested in such a system..
-Suresh.
Very interesting…
Definitely interesting. Keep the news flowing.
Hi Alex,
I’ve been working on something similar but with a totally different approach by using continuations for workflow tasks and clustering them with Terracotta. I will formally release this soon, but it’s already open-source and available through SVN from http://svn.rifers.org/rife-workflow/trunk . You can read more about it here: http://www.terracotta.org/confluence/display/wiki/RIFE+Workflow
(there seem to be problems with the wiki, this page has the same info: http://svn.rifers.org/rife-workflow/trunk/README)
Maybe this can be interesting to look at and either integrate or get ideas from.
The advantage is that the workflow is simply written in Java and that you wait for events from other tasks. During the wait state, no thread is running anymore since the location and state is captured in a continuation. Afterwards, when related events are triggered, the correct continuations are simply looked up and resumed. This means that idle tasks don’t have to take up resources by blocking a thread and poll for event at regular intervals. A RIFE user did this internally in his company a few years ago, and he got massive performance improvements.
Just thought I’d mention this.
Take care,
Geert
Hello,
Nice post
I’m trying to put mule clustered with terracotta, because queues in database are dam slow :)
Can you share some information ?
you made a queue implementation, or you use activemq ?
Cumps
As far as I know no one has clustered Mule with Terracotta.
The company is just using standard java.util queues, which are clustered via Terracotta. They are using ActiveMQ as a way to feed their Mule instance with messages I believe, but that that’s not used in the grid servers.
Disclaimer: I am the customer to which Alex refers in his post.
Geert,
Sounds like you have done some work in the worklfow area with Terracotta. I wanted to point out that the platform we’re developing is more than just workflow. I have not checked out your site, but will because we have not yet settled on the workflow engine to be used within our platform.
All,
Now for the shameless sales job:
We are trying to solve several “recurring problems” in our domain, which I think are applicable to many applications (being developers, we are inherently lazy and don’t like writing the same software twice):
1. Integration…with anything (thus Mule)
2. High-volume transactions, upwards of hundreds of millions a day and complex algorithm processing…thus Grid Computing
3. Workflow/BPM
4. Business Rules to drive the end-to-end processing
5. Real-time analytics to statistically analyze any or all of the hundreds of millions of messages in the system
6. Configuration – all of the above are to be configurations and not code to reduce cost of ownership
7. Commodity hardware. e.g. the Google model of having one enormous farm of really cheap computers that are self-aware, discovered, assimilated, provisioned and begin working on application logic.
Out of the above, we have about 40% put together already. Thus the consideration for Open Sourcing the project. I’m interested in any other thoughts anyone may have.
Mike