The Lazy Dev

Since a year I'm developing my applications following the usual principle of "non duplication" but pushing it to an higher level then just code duplication.
I'm moving to eliminate the "runtime duplication", or maybe I something that can be called like that.
This lead me to decoupled modules that communicate through messages, of course. This is pretty normal in the world of software integrations, is a well known Integration Pattern. But I wanted to put this into a single, standard application, like a CMS that manage images. There are two way I can achieve this.

Scenario

Let's say that there is a message broker I can use, external to the application, that just works. The app receive a file uploaded by the user. It's an image I need to:

1. handle the file upload to file system
2. convert file into expected formats
3. store file somewhere into the cloud (S3 or such)
4. make the image available to the system  (associate with database)

Now point 1 is handled by the web framework and is synchronous (but some tricks on the user interface side that are outside the scope of my analysis now)
Simplest solution is to do 2,3 and 4 in a row: that stuck the gui of course. I should have a scheduled thread to search for new files and performed 2, 3, 4 so that the GUI becomes free as long as upload is complete, and the "backend" perform the rest of the processing: there's the scheduled thread to tune and is not that nice, is it?

What I'd rather do today? I'll send a message, I do delegate. This is nice.

At the end of point 1, the gui send a light message to the broker saying "there's a new file called ..." and it send this to the right recipient(s). The receiver performs the conversion and send a new message, this time to a new component that perform the upload to S3 and when it's finished send a last message that is received by the original application that performs the association between the stored blob and the database: now the image is available and we can eventually notify the user, maybe with some cool user interface async message.

Push further

Now if the broker is something like ActiveMQ, the components have some listener to different queues or topics and that's done. What is the next question?

Where does those components lives? In the same process of the application? Or maybe somewhere else?
It can be both. If they live with the application they can be some spring beans that register a listener on the right topic at startup. But this is a solution that does not satisfy me.
Cause there's duplication, and not enough decoupling.

The duplication is that each new app will have to have it's own instances (and configuration) of the same components. Also, if the app is hanged, all those components are and there is no reason for this to be.
Better make them leave somewhere else, and the message broker (and the right queue/topic) is the only link between who procuce a message (say: upload is done!) and the consumer (ok, I'll do perform the conversion!) and so on.

There's a better environment than java?

Now, this is something I've done many times in the last year and I'm trying to make it more "standard" for all my apps. What I'm wiondering is: there a more natural way to do this? I mean, something more deeply integrated with the language?

In java, there are a lot of good tools to do this but everything only exists in my mind and some docs. This kind of architecture really is not supported by the environment, and unit testing that is possible but hard to do an maintain.

I'm talking, maybe, about the actor model. Or something that is possible with node.js. Are those technologies really more suitable to create programs the way I just narrated? If so, what is the dark side of the moon?

Very busy couple of weeks. I got over some new (for me) technologies that are actually pretty cool.

I got a lot of free degree of movement in the rejuvenation and restructuring of a software infrastructure that aims to deliver an ecommerce store for different countries.

The plan was to build a new message driven middleware based on ActiveMQ to manage the store orders distribution to some external system (like SAP). We need to have a lot of different small, very specific subject that are able to consume and manage the store orders in, ehm, order to manipulate them the most natural solution to me seem to run them in a OSGi container that allows to install, uninstall, upgrade, start and stop many different OSGI bundles (nothing more than simple jars with some meta information) in the easiest and fastest way.

So I got the change to play with Apache ActiveMQ to build the middleware and Apache Felix to have the OSGi container.
I got over both of them in less than two weeks, doing other tasks in the meantime.
Now I have a running Felix and I am able to produce a bundle that got activated once installed and started. This without changing my build tool chain, a simple "mvn install" is enough to produce the bundle, I just miss the way to deploy directly to the felix install.
And on the  ActiveMQ side I can connect producer as well as subscribers to my queues or topics and my subscribers are able to reconnect and recover messages they lost when they were offline.

This solve all the first wave of technical challenges and put the basis for a nice infrastructure.

So I am satisfied and I deserve a present, let's go looking for that Android phone...