Get your jobs executed asynchronously - anywhere!

Asynchronous execution has revived some kind of hype nowadays. Be it as of *design constraints [1] and performance considerations [2] regarding the underlying runtime (such as JavaScript) or upcoming runtime independent requirements processing big data.*

Latter forces developers to process huge amounts of data on different distributed systems and therewith asynchronously; them need to scale out because vertical scaling has its limits. Whilst former such as Node.js or io.js work much better in an asynchronous way as of the single threaded design approach of JavaScript (engines) [1] and the considerations on getting more (web) throughput on a single threaded asynchronously designed server [2].

Let the job-bus do the work …

Yet another approach regarding asynchronous processing is the use of a job-bus - for asynchronous method invocation and therewith asynchronous execution of your jobs. This approach makes heavy use of the command pattern:

“Simply speaking, you push a job into your job-bus. You can either wait for the job to be executed and grab its result when done or you use a handle to grab the result later on. The job is being executed asynchronously, it is up to the job-bus where and when it is being executed: For example the job could be transported to some remote JVM to be executed there or the job could get executed as soon as a worker thread is happy to grab the job from a job-queue.” [refcodes-jobbus: Asynchronous job execution]

The refcodes-jobbus artifact makes use of the Command pattern and provides a frame to work with Command (job) instances - also in a distributed environment (e.g. REST, SOA, Cloud Computing) and provides do/undo functionality.

In the article refcodes-jobbus: Asynchronous job execution I describe the refcodes-jobbus accompanied with a plain simple example on how to use it.

Beyond the realms of your JVM …

Combining the refcodes-jobbus with the refcodes-remoting RPC (remote procedure call) framework would extend the refcodes-jobbus beyond the borders of a single JVM. Regarding RPC, see also the article on refcodes-remoting: Face-to-face lightweight remote method calls!


[1] “node draws from V8, which is internally single-threaded” “… (actually) Node.js uses several threads, but only one execution thread. The background threads are for dealing with IO to make all of the asynchronous goodness work. Dealing with threads efficiently is a royal pain, so the next best option is to run in an event loop so code can run while background threads are blocked on IO

[2] “Node.js was created explicitly as an experiment in async processing. The theory was that doing async processing on a single thread could provide more performance and scalability under typical web loads than the typical thread-based implementation