Web Services HTTP vs. JMS

HTTP is the most common Web Services protocol. However,
web services are currently built on multiple transports each with different communications Quality of Service (QoS)
and message semantics. The platforms that support these transports,
the most common being HTTP(s) and JMS, also provide different performance,
scalability and reliability characteristics.
HTTP 是最为普通的Web Services传输协议。然而，现在Web Services可以构建再多种传输协议上，每种协议都有不同的
通信服务质量(QoS)和消息语义。一般平台都支持这些传输协议，其中最为普通的有Http(s)和JMS，也提供了不同的性能，
可测试性和稳定性。

Message semantics include synchronous/asynchronous, request/reply, transactional, publish/subscribe and
guaranteed delivery. The choice of protocol should depend on messaging requirements,
for example a common requirement is point-to-point versus one-to-many,
which drives the request/reply or publish/subscribe decision.
Another example would be a fast message producer paired with a slow message consumer,
which is easily implemented with a message queue.
消息语义包含：异步/同步，请求/回复，交互性，发布/订阅和可靠的传递(guaranteed delivery)，协议的选择依赖于消息的需求。
例如point-to-point对应request/reply，one-to-many对应publish/subscribe，
另外一个实例就是一个快的消息生产者对应一个慢的消费者，通过消息队列很容易实现。


HTTP is the defacto standard for web services and should be considered first
but potentially eliminated due to requirements. For example, HTTP would be eliminated if the requirement is one-to-many communications.
There are WS standard proposals to close some of the gaps such as transactions, routing, security,
but these standards are not widely implemented or it may be simpler to use JMS.
HTTP是一个事实标准，对于web services是优先考虑的传输协议，但也存在者一些潜在的限制，例如都有one-to-many的通信模式时，
就不大灵了。WS已有的标准在transactions, routing, security方便存在一些缺陷，而且这些标准没有被广泛的实现，
而使用JMS一切变得简单了。

Since HTTP has limitations many SOA implementations use JMS internally and
web services externally by implementing an internal service bus.
For example, it is straightforward to consume web services and publish JMS messages with an ESB mediation.

Consider using SOAP over HTTP for:

? Externally facing web services (e.g. customers or suppliers)
? For simple point-to-point and stateless services
? Where you need a thin client with no MOM installations

Consider using SOAP over JMS for:

? High-volume distributed messaging
? Asynchronous messaging
? Where a transaction boundary is needed in the middleware
? Where the message consumers are slower than the producers
? Guaranteed deliver and/or only once delivery of messages
? Publish/subscribe
? Distributed peer systems that might at times be disconnected

Note also that you may not need the SOAP envelope inside the firewall
if there are no WS policies to communicate.
For example, you could switch to context based routing
(message routing based on the content of the message) inside the firewall.