You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by Bob M <rg...@orcon.net.nz> on 2015/10/23 08:01:16 UTC

simple xml message broker

Hi

I have a server program and several client programs
These programs run concurrently

I wish to use ActiveMQ to send simple messages back and forth as follows:-

1) at a certain point each client sends new data to the server
2) once the server has received new data from each and every client, it
processes the new data
3) once the processing is finished, it sends amended new data back to each
and every client

Can the activeMQ send/receive code 'pause' the server until it receives all
incoming messages from the clients ?

Can the activeMQ send/receive code 'pause' the clients until they receive
the amended new data fromthe server ?



--
View this message in context: http://activemq.2283324.n4.nabble.com/simple-xml-message-broker-tp4703319.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: simple xml message broker

Posted by Bob M <rg...@orcon.net.nz>.
Thanks Tim

I shall try and follow your advice :)

Bob M



--
View this message in context: http://activemq.2283324.n4.nabble.com/simple-xml-message-broker-tp4703319p4703357.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: simple xml message broker

Posted by Tim Bain <tb...@alumni.duke.edu>.
Not at all.  I'd say that if your clients had only one message and your
server had none at all, ActiveMQ isn't overkill.

Using a JMS implementation such as ActiveMQ gives you (for free) a number
of capabilities that you'd otherwise have to implement (and test) yourself
or live without:

   - The simple ability to transfer data between applications
   - The ability for producers to not need to know who will consume the
   messages they produced, and for consumers to not need to know who produced
   them
   - The ability to use asynchronous messaging so that producers and
   consumers can operate at their own rate and on their own schedule, even if
   the other client isn't currently online
   - The ability to send messages to multiple consumers without any
   additional code and without needing to know who those consumers are in
   advance (though in fact your use-case of receiving a response from all
   consumers does require knowledge of all consumers, but that's a separate
   issue)
   - The ability to use multiple protocols (TCP, HTTP, STOMP, etc.) as well
   as encryption (SSL, HTTPS) when transferring messages
   - And lots more

Using a message-driven architecture also frees you up to reorganize where
your clients are deployed without needing to reconfigure property files
that tell your clients where to find each other, and makes it easier to
scale out if you need to in the future.

In short, I have a hard time constructing an argument that implementing and
testing the functionality you would need to implement yourself to make this
work without JMS is a better use of your time than spending a little time
learning how to configure and use the features that ActiveMQ provides
(tested and generally quite stable) for free.

Tim

On Fri, Oct 23, 2015 at 12:56 PM, Bob M <rg...@orcon.net.nz> wrote:

> Hi again (Tim)
>
> One last question...............
>
> If my clients have only the following messages
> (a) subscribe
> (b) unsubscribe
> (c) new data
>
> and my server has only the following message
> (a) amended new data
>
> is activeMQ overkill ?
>
>
>
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/simple-xml-message-broker-tp4703319p4703341.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>

Re: simple xml message broker

Posted by Bob M <rg...@orcon.net.nz>.
Hi again (Tim)

One last question...............

If my clients have only the following messages
(a) subscribe
(b) unsubscribe
(c) new data

and my server has only the following message
(a) amended new data

is activeMQ overkill ?



--
View this message in context: http://activemq.2283324.n4.nabble.com/simple-xml-message-broker-tp4703319p4703341.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: simple xml message broker

Posted by Bob M <rg...@orcon.net.nz>.
Thank you Tim for a very clear reply

Bob M



--
View this message in context: http://activemq.2283324.n4.nabble.com/simple-xml-message-broker-tp4703319p4703340.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: simple xml message broker

Posted by Tim Bain <tb...@alumni.duke.edu>.
Yes it can be done, but most of the work will be you figuring out how to
pause and resume your client and your server and what multithreading
constructs to use, not in ActiveMQ.

I'd encourage you to figure out (in detail) how you'd do this if all of the
clients and the server were all connected to each other with sockets.

Once you know that, translate any command that goes to all clients into a
publish to a topic, and any command that goes only to the server into a
publish to a queue.  (You may need multiple queues and/or multiple topics,
if your have multiple commands that should be processed independently; that
will depend on your use case.)

Tim
On Oct 23, 2015 12:13 AM, "Bob M" <rg...@orcon.net.nz> wrote:

> Hi
>
> I have a server program and several client programs
> These programs run concurrently
>
> I wish to use ActiveMQ to send simple messages back and forth as follows:-
>
> 1) at a certain point each client sends new data to the server
> 2) once the server has received new data from each and every client, it
> processes the new data
> 3) once the processing is finished, it sends amended new data back to each
> and every client
>
> Can the activeMQ send/receive code 'pause' the server until it receives all
> incoming messages from the clients ?
>
> Can the activeMQ send/receive code 'pause' the clients until they receive
> the amended new data fromthe server ?
>
>
>
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/simple-xml-message-broker-tp4703319.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>