maximum number of queues in JMS application

Thinking of a brand new application which will have the following architecture

Dealers <--> Network <--> Issuers

1) The Dealers will place orders, 2) Network processes them for basic sanity and then passes them to the Issuers for processing, 3) Issuer processes them and 4) send them back to the network (which does some logging) 5) and passes it back to the Dealer.

We are thinking of implementing it using queues. My knowledge of JMS is limited at this time. I wonder if we had 500+开发者_如何学Python dealers (lets say) can we have 500+ incoming queues (one each for incoming messages from each dealer) and the same number of outgoing queues (one each for outgoing messages from network to each dealer)...

and the same repeats on the issuers side. lets say there are 50 issuers (so 50 + 50 queues for that side, so in total 600 queues)

Is this kinda architecture practical and supported on current breed of JEE5 application servers. We don't want to introduce any heavy MQ implentations like websphere MQ if this is achievable on a regular JMS providers like the JEE5 servers as mentioned above ?

thx in advance, Rooban

500+ queues? Oh, my. I can't find anything to say it's not possible, but at best it'll be very difficult to maintain.

If dealers are outside your network, I'd imagine that they'd connect to you via HTTP, so a input queue per dealer would be out. You'd have clustered HTTP listeners to handle incoming requests.

You might have a chance at a pool of message driven beans for each dealer, but even 1MB per queue/MDB pair would mean you'd have to have 0.5-1GB just to have the queues. That's on top of all the other requirements for your Java EE app server.

Sounds like a configuration/management nightmare to me.

Why do you think you need the queues? Is it 'guaranteed delivery', reliability, asynchronous processing, etc. that attracts you?

Why does each dealer need their own queue? Is the processing different for each dealer?

What kind of message volume per dealer have you observed? What kind of growth do you expect? How large is each message? What is the payload of the message - XML, JSON, or something else?

I would make sure that I had explored several alternatives, none of which required queues, before I took this route. I think it's suspect.