Biztalk 与 MSMQ
我们需要在销售点系统和 Java Web 服务（在我们的网络之外）之间发送 XML 消息。这些消息包含非常敏感的数据。消息传递必须是安全的、事务性的，并且具有故障转移的高可用性（24/7）。该解决方案需要开发一个执行以下操作的代理：
- 从系统的 POS 轮询消息（3 种类型的消息）
- 对消息进行一些转换
- 将消息的一部分转发到 java webservice
- 将消息的一部分存储在数据库中
- 通知结果的 POS 系统
基于这些稍微简化的要求，您认为 Biztalk 会大材小用吗？ MSMQ/WCF 能解决这个问题吗？
谢谢你的帮助
阿明
We need to send an XML messages between a point of sale system and a java webservice (outside of our network). the messages contain very sensitive data. The messaging has to be secure and transactional and highly available (24/7) with failover. The solution requires the developement of a broker that does the following:
- Poll messages from the POS of system (3 types of messages)
- do some transformation to the messages
- forward part of the message to the java webservice
- store part of the message in a database
- notify the POS system of the result
Based on these somewhat simplified requirements, do you believe that Biztalk would be overkill? would MSMQ/WCF do the trick here?
Thank you for your help
Amine
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
IMO 如果您有能力异步接收和传递消息，那么 MSMQ（或其他面向消息的中间件）将是可靠的事务传输的明显选择，而不管解决方案的其余部分如何。 MSMQ 的日志记录还可用于审计和调试目的（但您需要一种归档日志的策略）。
对于轮询、路由、映射/代理和审核要求，您可以选择 BizTalk、其他 ESB 和 EAI 产品或 DIY 解决方案。
正如您所建议的，很难证明 BizTalk 在诸如此类的单个消息交换场景上的成本和学习曲线是合理的 - 您可能会启动 .NET Windows 服务（例如使用 WCF、Workflow Foundation、Transaction Scopes、一些用于映射和数据访问层的 XSLT）将在几天内完成。
但是，如果这不是一次性集成方案并且需要进行额外的集成（需要集成更多应用程序、更多服务、额外侦听器、不同的通信技术等），那么建议您的公司花很长时间关于 EAI 和 ESB 技术的术语观点。 IMO 集成中的主要挑战不是最初的开发工作，而是持续的运营管理要求 - 例如安全、审计、故障转移、监控、不良消息和其他异常的处理 - BizTalk 等产品确实值得投资。
IMO if you have the ability to receive and deliver messages asynchronously, then MSMQ (or other Message Oriented Middleware) would be an obvious choice for reliable, transactional transport, irrespective of the rest of the solution. MSMQ's journalling can also be used for audit and debugging purposes (but you will need a strategy for archiving the journal).
For the Polling, Routing, Mapping / Broker and Auditing requirements you then have the choice of BizTalk, other ESB and EAI products, or a DIY solution.
As you've suggested, it is difficult to justify the cost and learning curve of BizTalk on a single message exchange scenario such as this - you could probably knock up a .NET Windows Service (e.g. using WCF, Workflow Foundation, Transaction Scopes, some XSLT for mapping and a data access layer) in a few days.
However, if this isn't a one-off integration scenario and the need for additional integration arises (more applications to integrate, more services, additional listeners, different communications technologies etc), then it would be advisable for your company to take a long term view on EAI and ESB technologies. IMO the main challenge in integration isn't the initial development work, but is instead the ongoing operational management requirements - e.g. security, auditing, failover, monitoring, handling of bad messages and other exceptions - where products such as BizTalk are really worth the outlay.
您是否想要并且有足够的资源来开发、监控和维护自己的定制解决方案？如果您不介意这样做，那么采用基于 .net 的自定义 MSMQ/WCF 解决方案可能会效果很好。
BizTalk 还将满足您列出的所有要求。有一个学习曲线，但它肯定不是不可克服的。初始启动可能比自定义代码解决方案更长，但有相当大的好处，特别是可靠地满足您的所有要求的好处：
如果 BizTalk 需要轮询 POS 系统，那么您无需担心使用 MSMQ。 BizTalk 可以可靠地处理消息传输（它们被持久保存到 SQL Server，而 MSMQ 将消息持久保存到磁盘）。
另请注意，使 MSMQ 高度可用的唯一方法是将其集群化。因此，无论哪种方式，您都需要对某些内容进行聚类。
随着时间的推移，BizTalk 解决方案将更容易维护，特别是如果您只想更新转换。通过版本控制，您可以不需要停机的方式来完成此操作。在不停机的情况下更新自定义解决方案将是很困难的。
过去，有些人在监视 BizTalk 是否有失败的消息方面遇到了困难，但我发现它比尝试监视消息队列更容易，尤其是使用 SCOM 或 BizTalk 360 等工具，后者通常需要更多的自定义工作来监视。只需确保将监控纳入解决方案生命周期的成本估算中即可。
如果您确实需要审核，那么 BizTalk 也能满足您的需求。 MSMQ 日记将为您保留每条消息的副本，但没有重要的事务详细信息，也没有开箱即用的方式来搜索或存档数据。
构建您自己的 .NET 客户端代码来使用 Java Web 服务可能需要大量工作，无论您采取哪种方式。对于 BizTalk，这意味着针对端点或针对 WSDL 运行向导。对于 WCF，这意味着一切都需要手动完成或在 svcutil 工具的帮助下完成。
Do you want to and have the bandwidth to develop, monitor, and maintain your own custom solution? If you don't mind doing that, then going the route of a custom .net-based, MSMQ/WCF solution might work well.
BizTalk will also cover all of the requirements you have listed. There is a learning curve but it is certainly not insurmountable. The initial ramp-up may be lengthier than would a custom-code solution, but there are considerable benefits, particularly the benefit of having all your requirements reliably met:
If BizTalk needs to poll the POS system, then you do not need to worry about using MSMQ. BizTalk can handle transferring messages reliably (they're persisted to SQL Server, while MSMQ persists messages to disk).
Note too that the only way to make MSMQ highly available is to cluster it. So either way you'll need to cluster something.
A BizTalk solution will be easier to maintain over time, particularly if you just want to update your transformations. With versioning you can do so in a way that doesn't require downtime. It'll be tough to update a custom solution without downtime.
Some people have had difficulty in the past with monitoring BizTalk for failed messages, but I have found it to be easier, especially with a tool like SCOM or BizTalk 360, than trying to monitor message queues, which often requires even more custom work to monitor. Just make sure to include monitoring in your cost estimates for the life of your solution.
If you do need auditing, then BizTalk also has you covered. MSMQ Journaling will keep a copy of each message for you, but without significant transaction details and with no out-of-the-box way to search through or archive the data.
Building your own .NET client code to work with a Java web service will likely take a good bit of work regardless of which way you go. With BizTalk that means running a wizard against the endpoint or against the WSDL. With WCF it means doing everything by hand or with the assistance of the svcutil tool.
无论哪种方式，您都应该使用 MSMQ 进行传输。
如果您使用 .NET 中的 MSMQ，您应该知道它的限制：消息大小为 4 MB。
另一方面，BizTalk 具有 MSMQ 适配器，它克服了此限制（如果第二个 BizTalk 服务器在通道的另一端侦听）。除此之外，BizTalk 还为您提供了以下功能：易于配置的消息跟踪、可视化转换映射。它也可以在集群中设置（仅限 Ent. 版本）。
但问题是你能（或者你愿意）为它的服务器提供 biztalk 许可证和硬件吗（它比定制的 .net 解决方案慢）。
You should go with MSMQ transporting either way.
If you use MSMQ from .NET you should know its limitation: 4 MB on a message size.
BizTalk on the other hand has MSMQ adapter which overcomes this limitation (if a second BizTalk server listen on the other side of the channel).On top of that BizTalk gives you features like: easy configurable message tracking, visual transformation maps. It can be set up in cluster too (Ent. version only).
But the question is can you (or do you want) afford biztalk licenses and hardware for it servers (it's slower then custom .net solution).