[译]Web Service 还是 Message Queue (Web services vs. a message queue system)
看到了一个不错的探讨Web Service和Message Queue的文章，翻译了过来：
英文网址是：http://searchsoa.techtarget.com/expert/KnowledgebaseAnswer/0,289625,sid26_gci818509,00.html
问：
我们正在考虑使用Web Service实现一些内部集成的工作。看起来Web Service相对于一些其他选择，比如Message queue，要好一些。你是否可以给我一些建议，如何在Web Service和Message Queue之间做出选择。
答[Dave Ranck， CTO, Software Consortium, Inc.]：
首先，让我们达成一个基本的共识。Web Service并不能解决我们目前遇到的所以业务问题。有时，会有一些更好的选择。也就是说，我们应当考虑一些基本的准则。
Web Service相对来说比较简单，而且易于实现。这是它的一个主要的优势。大多数消息服务方案(messaging service solutions)并不是这样这样，而且相对于Web Service相当昂贵。短期内，大多数Web Service的应用仍然是企业内部集成。
Web Service具有分布式计算系统天然的扩展性，而且可以有效的将分布的系统连接在一些。因为Web Service基于公开的标准和协议，比如SOAP和TCP，所以目前大多数平台能够非常容易的实现Web Service。如果，你在新的.NET程序中需要的功能已经在你已有的J2EE应用程序中实现，那么没有必要再重新实现一边，直接使用Web Service从.Net调用J2EE的程序即可。
在什么情况下我不推荐Web Service哪？Web Service 目前缺少两个主要的功能，而在Message Queue中却得到很好的支持。首先，Web Service并不能内在的支持事务(transaction)。大多数Message Queue系统都能够很好的支持事务，甚至支持多个数据源间的事务。如果这种这种跨应用的事务支持对于你的系统很重要，那么你应该选择Message Queue.
其次，Message Queue能够保证消息传输一定会传输到目的地，Web Service却不能够。因为使用消息队列能够实现消息的异步发送（也就是说，发送后不管），这一点对于Message Queue非常重要，也是它为什么成为队列。
最后，你应当详细勾画出你的业务需求并且排好他们的优先级。不但包括技术细节，也要考虑以后的支持和维护，以及全部的代价(cost)
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/51146/viewspace-659844/ ，如需转载，请注明出处，否则将追究法律责任。
