Ok I've definitely got what you're trying to say concerning the use of DBs and message broker.<br><br>To explain a bit more, I'll answer the few questiosn you've scattered across your reply :<br><br>Is it a distributed architecture ? <br>
���� <br>Definitely yes, each app will run on a different server<br><br>Why do I need to keep apps separate ? <br><br>Simply because my project can be viewed as a application suite composed of about 5 different apps. The end-user will be able to choose which of the apps he wants and I want to only provide what is absolutely necessary for the end-user based on what he asked for, nothing more nothing less. Therefore if the end user only wants one app out five I'm not going to provide him with a RabbitMQ, he will have no use for it. However should he asked for a set of apps that need to communicate, then I'll install a RabbitMQ to let them communicate.<br>
Now like I said, I'm looking for a way to do this without changing anything in the apps' code. <br>What I'm looking for is a solution where I would have something like a "watcher" external app that would keep an eye on what's going on in each app and manage the content of each RabbitMQ queues accordingly.<br>
<br>That peculiar aspect of the apps is for my longterm evolution of my app : for my personal use, the simpler approach of the code for pushing a mesage in the queues embedded in the app would be fine. But since I'd like to make it evolve to something else, I'd rather think ahead and try to do so right now.<br>
<br>Hope these explanations help a little more.<br><br>Cheers,<br>Ryan.<br><br><div class="gmail_quote">2012/10/17 Tim Watson <span dir="ltr"><<a href="mailto:tim@rabbitmq.com" target="_blank">tim@rabbitmq.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 10/17/2012 11:40 AM, Ryan R. wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think I understand what you mean with the shared library.<br>
However, in my case, RabbitMQ would only be installed if need be (meaning more than one of the apps are present, and two of those need to be synchronised for part of their data).<br>
<br>
</blockquote>
<br></div>
That actually complicates the picture somewhat - is there a reason why this is the case? In a typical integration architecture, the messaging broker is deployed centrally (on the LAN somewhere) and clients choose whether or not they want to connect to it from whatever machine they're running on. To me, it is sounding like you're describing an architecture where both applications reside on the same machine and assuming that the broker will also need to be co-resident with them, which is not really the case, though there's nothing to prohibit that either.<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
That said, using a shared library would require me to "include/import" said library when I need to, therefore making me change my app code depending of the situation I'm in.<br>
<br>
</blockquote>
<br></div>
Well yes, if you're going to add messaging capabilities to your applications that don't currently support it, then you are going to have to write *some* code and integrate it into them! :)<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
And said library would only be required when there's a RabbitMQ available anyway.<br>
<br>
</blockquote>
<br></div>
I think you're making your life more complicated than it needs to be by thinking about whether the messaging broker is available vs. not. The broker should *always* be available when applications residing on different machines need to communicate with one another, regardless of whether those applications are running or not. Again, it feels like you're trying to deal with applications running on the same machine - have I picked that up correctly? It might help if you explained your architecture in a bit more detail, so I can understand exactly what you're trying to achieve.<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Now a bit further in your message you talk about a listener library.<br>
I'd like to know a bit more about this.<br>
How would an external library be able to listen to anything happening within my app ?<br>
Would it be listening on the DB queries ?<br>
<br>
</blockquote>
<br></div>
No, not at all. Let's say you've got two applications, App1 and App2. You'll write some library code that both applications share, that probably looks something like this (with *wide* variations depending on language/platform - I've just written pseudo code to keep things simple):<br>
<br>
------------------------------<u></u>-------<br>
<br>
function init = do<br>
� � read_config_file_for_this_app<br>
� � open_connection_to_broker<br>
� � store_connection_somewhere_in_<u></u>memory<br>
end<br>
<br>
function listen = do<br>
� � get_connection_from_memory<br>
� � read_message_from_broker<br>
� � pass_message_to_application_<u></u>thread_somehow<br>
� � listen<br>
end<br>
<br>
function publish = do<br>
� � get_connection_from_memory<br>
� � send_message_to_broker<br>
end<br>
<br>
------------------------------<u></u>-------<br>
<br>
Now in your applications, you'll call the shared 'init' library function when you're starting up to bootstrap the connection to the broker. When your application is publishing data, it calls publish and if/when you need to subscribe to data then you'll call 'listen'. The fact is that 'how to listen' for incoming messages really depends on how you're going to use them. But the point is that the applications read from and write to the messaging broker, and do so independently of database tables. You *may* decide to do something like write a middle-man application that periodically reads a database table and publishes each row to the messaging broker so it can be read from a queue, or do that with a worker thread instead of a separate application. I would *not* do anything here with the database though. If applications need to share data, then **they should send it to one another via message queues.** If they need to persist data, they should persist their own data in their own tables in the database, but they should **not use the database to communicate with one another.** That is the key thing with using messaging instead shared data(bases).<br>
<br>
There is an overhead in sending (and in some cases, duplicating) data between applications of course. This is *more* than compensated for by the reduced coupling that comes from integrating using messaging technology. This approach may not be suited to integrating applications that are running on the same physical machine and are tightly and deliberately coupled however. I can't really elaborate on the suitability of messaging for your project without understanding a good deal more about it I'm afraid.<br>
<br>
I hope that clears a few things up at least! :)<br>
<br>
Cheers,<br>
Tim<br>
<br>
</blockquote></div><br>