使用50+第三方Web服务，我应该使用BizTalk还是只使用C＃？

Question

我正在构建一个后端应用程序，需要从超过50多个第三方Web服务获取各种日程安排的数据，并且该数字将继续增长。来自这些服务的数据当前可以分为3种类型，因此每个响应都需要映射到3种已知模式中的1种。

编写自定义c＃来点击每个Web服务似乎是一个管理噩梦，更不用说在代码中拥有所有数据映射。

目前的想法是在BizTalk 2009之上构建它，仍然需要很多维护，但至少已经定义了具有映射/转换功能的平台。

我正在寻找任何可能之前做过此事的人的建议，这真的给我们买了什么吗？我知道BTS缺乏轮询功能，但是有足够的工作让人对解决方案感到满意。

谢谢！

Answer 1

听到有人考虑BizTalk而不是C＃，这令人耳目一新！

我建议使用BizTalk方法，利用ESB Toolkit 2.0和UDDI Services v3（在BizTalk Server 2009中找到）的功能，原因如下：

• 可以在UDDI注册中心维护50个Web服务端点 - 一个可以添加和维护未来端点的通用管理门户;
• 轮询每个Web服务调用，并将生成的消息带到总线上，映射到三个消息之一并传送到特定端点;

关于映射，需要为三种常见消息类型和每种Web服务响应中的每一种定义模式;然后需要创建映射以将响应消息映射到适当的公共模式。

在这种情况下使用ESB功能的美妙之处在于，解决方案的任何方面都不会紧密耦合：当收到Web服务响应时，会解析正确的映射（在运行时 ）来自响应消息的属性。一旦消息映射到其通用模式格式，就可以相应地路由它。

Answer 2

之前已经实现了这样的解决方案，确定工具集的一个重要因素将是您需要调用的Web服务的复杂性。使用BizTalk，您将为每个第三方Web服务开发转换。在大多数情况下，这是一项简单的任务，但您可能会遇到映射变得非常重要的情况 - 在这些情况下，实现映射所需的时间会快速超过直接在C＃中编写映射所需的等效时间。

任何网络服务是否需要多次通话？例如。在轮询之前获取身份验证令牌？这些服务需要通过BizTalk调用更复杂的编排。

总的来说，我认为您会发现开发和维护针对该问题的目标C＃解决方案比使用BizTalk等企业系统更容易。根据我实施BizTalk解决方案的经验，所需的维护量和解决问题的难度大大超过了平台提供的任何好处。但是，我的经验是BizTalk 2006 R2 - 2009可能已经解决了我们遇到的问题。