Desktop applications

[Jon Mithe <jo...@gmail.com>]

Hello,

I'm trying to figure out if activemq would be a good fit to broker messages
from a desktop application to a backend services.

In particular what is confusing me is say 100 users log on to the system (I
see activemq has user auth) how do I can manage the users session.

For example, each user will make requests to and subscribe to common
services (for example, to send an order and listen for order updates) but
each user must only recieve their own information, i.e. I dont think I can
have a generic "orders" queue.

So I think each user will need their own unique end points / queues and on
disconnect the broker would I assume bring all these down.

Its almost like a template, each user will have acess to these 5 end points
but unique instance for each one based on the login credentials, I imagine
something like "orders-jon123".

>From all the books I've read, they are focused more on backend and web app. 
I.e. effectivley 1 user thats handling requests/subscriptions on behalf of
users and can securly spread / filter out information to the relevant users.

Alot of the systems I work on are monolithic point to point systems which
are a nightmare to deal with / enhance so I'm interested learning more about
service orientated architecture, EIP's, activemq to try and break down the
point to point pain.  

Any help or point in the right direction would be great thanks, I'm not
afraid of a suggestion that I can research, activemq is seems so
big/powerfull I just dont know where to start.

Cheers,
Jon



--
View this message in context: http://activemq.2283324.n4.nabble.com/Desktop-applications-tp4684858.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: Desktop applications

[artnaseef <ar...@artnaseef.com>]

Yup - request/reply with temp queues is a good model.  With ActiveMQ, it is
important to reuse temp destinations, so choose the right model:

    GOOD
    - create connection
    - create temp destination
    - repeat
        - send request with reply-to = temp destination
        - receive response
    - delete temp destination (closing the connection is sufficient)
    - shutdown

    NOT GOOD
    - create connection
    - repeat
        - create temp destination
        - send request with reply-to = temp destination
        - receive response
        - delete temp destination
    - shutdown

The latter is especially troublesome over a network of brokers.

BTW, correlation IDs can be used with a common queue, but try to avoid that
- the overhead of selectors is generally a bad thing, and message flow
problems become harder to resolve.



--
View this message in context: http://activemq.2283324.n4.nabble.com/Desktop-applications-tp4684858p4684882.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: Desktop applications

[Matt Pavlovich <ma...@gmail.com>]

Hi Jon-

This is an application design question, and is tough to accomplish over a mailing list. A quick suggestion:

JMS has a request-reply model that uses message headers to specify a ReplyTo queue. You can do this to solve the “user” problem.  Don’t think of it as a per-user situation, but think of it as a per-Request model with a special reply queue that each user knows for each request.   

   Bob sends a message to the queue://Orders.Submit  with a ReplyTo: temp-queue://UUID-DF432423  
     — Bob’s desktop program sets a listener on temp-queue://UUID-DF432423 
     — Reply received and client-side program processes the data  
     — Bob’s desktop program closes the temp-queue://UUID-DF432423 and ActiveMQ deletes the temporary queue

   This is repeated per-user and per-request.  

This drastically simplifies the back-end application, because it doesn’t need to care about users or requests.. it just knows to process the message from the Orders.Submit queue and then publish back to the temp queue. 

Take this as the base design, and then it can be scaled vertically and horizontally as needed, but the application and ActiveMQ infrastructure will all be straight-forward.
  
Best of luck!

-Matt Pavlovich

On Aug 21, 2014, at 6:25 AM, Jon Mithe <jo...@gmail.com> wrote:

> Hello,
> 
> I'm trying to figure out if activemq would be a good fit to broker messages
> from a desktop application to a backend services.
> 
> In particular what is confusing me is say 100 users log on to the system (I
> see activemq has user auth) how do I can manage the users session.
> 
> For example, each user will make requests to and subscribe to common
> services (for example, to send an order and listen for order updates) but
> each user must only recieve their own information, i.e. I dont think I can
> have a generic "orders" queue.
> 
> So I think each user will need their own unique end points / queues and on
> disconnect the broker would I assume bring all these down.
> 
> Its almost like a template, each user will have acess to these 5 end points
> but unique instance for each one based on the login credentials, I imagine
> something like "orders-jon123".
> 
> From all the books I've read, they are focused more on backend and web app. 
> I.e. effectivley 1 user thats handling requests/subscriptions on behalf of
> users and can securly spread / filter out information to the relevant users.
> 
> Alot of the systems I work on are monolithic point to point systems which
> are a nightmare to deal with / enhance so I'm interested learning more about
> service orientated architecture, EIP's, activemq to try and break down the
> point to point pain.  
> 
> Any help or point in the right direction would be great thanks, I'm not
> afraid of a suggestion that I can research, activemq is seems so
> big/powerfull I just dont know where to start.
> 
> Cheers,
> Jon
> 
> 
> 
> --
> View this message in context: http://activemq.2283324.n4.nabble.com/Desktop-applications-tp4684858.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.