何时通过UDP套接字API选择JMS API，反之亦然？ [英] When to choose JMS API over UDP socket API or vice versa?

问题描述

可以激励程序员在分布式Java应用程序中使用Java JMS（Java消息服务）API而不是java.net包的UDP套接字API，或者使用UDP套接字API代替JMS API的原因是什么？如果可能，请提供示例应用程序。

What are the reasons that can motivate a programmer to use Java JMS (Java Message Service) API instead of UDP socket API of the java.net package in a distributed Java application or to use UDP socket API instead of JMS API? If possible, please give example applications.

推荐答案

UDP 和 JMS 在许多方面都有所不同，从根本上说，因为JMS通常依赖于 TCP 固有的功能（请参阅比较UDP和TCP 以了解两种基础协议的差异。）

UDP and JMS are different in many ways, and fundamentally since JMS typically relies on the features inherent to TCP (see this comparison of UDP and TCP to get an idea of the differences of the two underlying protocols).

基本上UDP适用于不需要任何可靠性，排序，拥塞控制或网络之间路由的应用程序（因为许多消费级和商用级路由器不转发UDP数据包）。 JMS提供UDP和更多功能缺失的所有这些功能（如事务，发布/订阅和排队，持久订阅等）。

Basically UDP is suitable for applications which do not require any reliability, ordering, congestion control, or routing between networks (since many consumer and commercial grade routers do not forward UDP packets). JMS provides all of these features missing from UDP and more (like transactions, pub/sub and queueing, durable subscriptions, etc).

UDP可能适合于大量流式传输局域网内不需要绝对质量的数据;对于需要在广域网主机之间进行可靠消息传递的应用程序，JMS会更好。此外，JMS模糊了套接字，服务器，绑定等的细节，并提供了一个更适合企业集成的高级API。

UDP might be appropriate for streaming large amounts of data within a local area network where absolute quality is not a requirement; JMS would be better for applications requiring reliable messaging between wide area network hosts. Moreover, JMS obscures the details of sockets, servers, binding, etc. and provides a high-level API which is better suited for enterprise integration.

这篇关于何时通过UDP套接字API选择JMS API，反之亦然？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！