0

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+ 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

Improve this question

1 Answer 1

Reset to default
1

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.

Improve this answer
Sign up to request clarification or add additional context in comments.

3 Comments

yea the features that you mentioned are the reasons I am inclined towards queue based messaging ... Dealer ---> Network side can do with one queue because its many to one relationship from Dealer to network, and the network has to process all messages in the order in which they are received. but on the reverse side, i.e Network ---> Dealer side, if the network puts a message on the outgoing queue, how will each Dealer know whether the message is addressed to them or not ? Of course we cannot afford to have a msg addressed for a dealer1 be pickedup (and hence removed from queue) by dealer2.
-and the issuer side, they can live with one incoming and outgoing queue. - the network can get those messages and look at the contents to determine the dealer they are addressed to.. and put in the appropriate outgoing queue. so we have reduced the number of queues significantly now before it was (2* noOfDealers + 2*noOfIssuers) now it is (1 + noOfDealers + 1 + 1) - the message would be XML based and could be max 10-15k. - if the dealers are in a trusted extranet based environment, cann't their client programs just lookup our queues and connectionFactories through JNDI..
- but even with this we are still looking at queue number equal to the number of dealers (if there are 500 dealers) it could take around 0.5GB memory on the server. - what other solutions would be recommended in this case? - will Websphere MQ be a better platform for this kind of situation

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.