如何从 Biztalk 向许多 Web 服务发送消息
假设我们有一个基于 BizTalk 构建的通知服务。一旦服务收到通知，它就应该将该通知发送到其他系统。如果我们有 2-3 个系统，我们只需添加一些 Web 服务引用并通过相应的端口发送消息。但我想知道如果我们应该向数百个订阅的 Web 服务发送消息怎么办？向 100 个 Web 服务重新发送消息的最佳方式是什么？
Imagine we have a Notification service build on BizTalk. Once the service receives a notification it should then send this notification to other systems. If we have had 2-3 systems we could just add a few web service references and send the message thru corresponding port. But I wonder what if there are hundred of subscribed web services to which we should send a message? What's the best way to resend a message to 100 web services?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
正如费尔伯特所说！您的编排中将有一个逻辑发送端口，并且您可以将编排绑定到管理控制台中的发送端口组；这样您就可以随意添加或删除发送端口。如果任何服务也需要转换消息，则可以执行出站任何映射。
As Filburt said! You would have one logical send port out of your orchestration and you would bind your orchestration to a send port group in the Admin console; so you could add or remove send ports at will. Any mapping could be performed outbound if any services need the message transformed too.
与 Filburt + teepeeboy 一致，并补充一点，如果您提供推送数据服务，您可能希望控制每个端口，以便控制 SLA、重试、可能链接到计费等。您可能需要增加相关 WCF 适配器上的线程数和/或增加发送主机和/或群集服务器的数量以实现可扩展性。
您还可以考虑使用异步适配器（例如 MSMQ 或 MQSeries），因为 100 个订阅者中的一个订阅者出现故障的可能性会变得更高。对于“ACK”回复，通过限制对队列的访问并使队列具有事务性，您可以“证明”您的订阅者已通过事务性方式将消息从队列中删除。
In agreement with Filburt + teepeeboy, and to add, if you offered push data services you would probably want control over each and every port, in order to control SLA's, Retries, possibly linked to billing, etc. You would likely need to increase the number of threads on the relevant WCF adapter and / or increase the number of Send Hosts and / or Clustered Servers for scalability.
You might also consider using an asynchronous adapter like MSMQ or MQSeries, as the chances that one of more of your 100 subscribers is down becomes higher. w.r.t. "ACK" replies, by restricting access on the queue and making the queue transactional, you could 'prove' that your subscriber had transactionally removed the message off the queue.