在你打过技术限制之前,你可能会打上实际限制。 也就是说,电文长度在时间上可能会有技术性限制,可以直线或长期表示,但这种限制不大可能成为你首当其冲的制约因素。

Mega比特的电传长度往往高。 想把几个K作为你想要的球园。

有时使用的一种技术是发出小信息,说“项目123435已经更新”,消费者然后从数据库或其他储存机制检索与项目12345有关的数据。 因此,每个客户只能获得他们所需要的数据,当用户可能不需要数据时,我们不喷洒大量数据。

我建议你检查<bookEnterprise Integration patternss,其中详尽分析了处理你要求的问题的许多模式。 尤其是,如果你的信息量很大,你可以使用<>载荷来解决这个问题:

Huge amounts of data: Sometimes applications want to transfer a really large data structure, one that may not fit comfortably in a single message. In this case, break the data into more managable chunks and send them as a Message Sequence. The chunks have to be sent as a sequence, and not just a bunch of messages, so that the receiver can reconstruct the original data structure.

Quoted from http://www.eaipatterns.com/MessageConstructionIntro.html<>。

The home page for a summary of each patterns of the book is available at http://www.eaipatterns.com/index.html。

具体执行。 如你所期望的那样,规模越小越好。 例如,Tibco建议将电量保持在100KB以下。

小型电文很迅速,显然也比较快。 说到这一点,基本的JMS服务器安装可以改善性能,例如,通过电文压缩,例如网络9()。