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 thejobto be executed and grab itsresultwhen done or you use ahandleto grab theresultlater on. Thejobis being executed asynchronously, it is up to thejob-buswhere and when it is being executed: For example thejobcould be transported to some remoteJVMto be executed there or thejobcould get executed as soon as aworkerthread is happy to grab the job from ajob-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-jobbusaccompanied with a plain simple example on how to use it.
Beyond the realms of your JVM …
Combining the
refcodes-jobbuswith therefcodes-remotingRPC(remote procedure call) framework would extend therefcodes-jobbusbeyond the borders of a singleJVM. RegardingRPC, 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 …”