Since early January that I've been trying and looking for MQ's already implemented by someone else but they all seemed unadjusted to what I had in mind.
So, to keep things simple I've written a message queue server using a database running on HSQL that is also embedded inside the application.
It was a bit of a marathon, since early design up to implementation it took less than one day and a half but I'm happy that it is available and working as intended.
The advantage of using a built-in message queue is the ease in maintaining several disperse services working with each other in asynchronous manner. For example, A wants B to receive an update. So, A leaves the message on the queue that B will receive whenever becomes possible.
This is handy for cases where a massive amount of information needs to be handled by B from multiple sources, becoming a simple tool that smooths the peak usage from daytime activities that would otherwise require more hardware to cope with the resource demand.
So, the next step is implementing a process manager using the same technique. The overall idea is to implement a publisher-subcriber-alike feature at the running processes. This way, process A is running while processes B, C, D (..) can check the ongoing status of process A since he only needs to update his process status on the process manager.
This way we provide a real abstraction layer between the presentation and business logic of our system, allowing to expand a given application to other platforms and interfaces, let them be web-based, GUI based on even plain command line.
----
Still, I would have preferred to use a COTS or open source project that could save my time and effort to implement these features. There's only so much that one or two developers can do on their own.
I believe that the limitation of working in a small team can also bring advantages, for example, we can't afford to support the bulk associated with typical enterprise-level frameworks and we are constantly reminded that any given implementation needs to be simple or we'll risk not reaching our goals.
Not using enterprise-level frameworks, doesn't necessarily translate to "it won't scale". The idea is to start little and add abstraction at critical locations from the start, so that we can replace components by others with more power (and resource demands) as we progress across the years. So, start small, keep growing as needed.
After all this is done, the final step is moving a bit higher in the ladder and allow connectivity between several clients on a given network using the same application. Let's move forward.
:)
