考虑一个全新的应用程序，它将具有以下架构
经销商 <--> 网络 <--> 发行人
1）经销商将下订单，2）网络对其进行基本处理，然后将它们传递给发行者进行处理，3）发行者处理它们，4）将它们发送回网络（进行一些日志记录）5）并通过返还给经销商。
我们正在考虑使用队列来实现它。目前我对 JMS 的了解有限。我想知道我们是否有 500 多个经销商（比方说）我们是否可以有 500 多个传入队列（每个经销商的传入消息各一个）和相同数量的传出队列（从网络到每个经销商的传出消息各一个）.. .
在发行人方面也是如此。假设有 50 个发行者（所以那一侧有 50 + 50 个队列，所以总共有 600 个队列）
这种架构在当前的 JEE5 应用程序服务器上是否实用并受支持。如果可以在如上所述的 JEE5 服务器等常规 JMS 提供程序上实现，我们不想引入任何重型 MQ 实现，例如 websphere MQ 吗？
提前谢谢，鲁班
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.