了解 BizTalk 开发答案

【问题标题】：Understanding BizTalk Development了解 BizTalk 开发
【发布时间】：2015-02-18 15:45:23
【问题描述】：

从 .net 开发人员的角度来看，最近有人向我介绍了 BizTalk。我期待着一系列服务参考、自动映射类和工作流。我真的没想到会大量使用 XSD，并且对编排图感到惊讶。

我只是不明白为什么它不像是一堆建立在 WCF 基础上的企业功能。

谁能帮我理解 BizTalk 的设计理念？

【问题讨论】：

【解决方案1】：

BizTalk 可以与 WCF 服务一起使用，但对于一些简单的场景不需要。它还可以在需要自定义非 WCF 适配器的情况下工作 - 它包括许多开箱即用的有用适配器，例如 FTP、SFTP、文件系统访问、POP3、Sharepoint、Azure ServiceBus、MSMQ 和 MQSeries。可以为不公开 WCF 终结点的旧系统和服务编写自定义适配器。在 WCF 有用的情况下，有许多 WCF 适配器，并且这些适配器的使用和配置比从头开始绘制 WCF 服务更容易一些。 BizTalk 还可以将其服务公开为 WCF 终结点。

BizTalk 的真正强大之处在于其服务器架构，它允许高可用性、持久消息传递、暂停和恢复消息、高级调试选项以及工件（如地图和编排）的快速开发。它还为 EDI、HL7 和 WCF LoB 集成工作提供了一些强大的开箱即用支持。

XML 是 BizTalk 消息传递引擎的核心和灵魂。这很好，因为 XML 是标准化且强大的；这很糟糕，因为 XML 有时很笨拙，尤其是在处理较大的消息和 BLOB 时。

ReceivePorts 将数据导入 BizTalk 的消息传递引擎（使用适配器和接收位置）。发送端口使用上述适配器将 XML（或其他）数据发送出去。

地图在后台使用 XSLT 来转换 XML 消息；可以引导地图使用自定义 XSLT，或者也可以使用 C#、VB 或 JScript。然而，对于大多数琐碎的映射任务，可视映射界面允许快速开发和测试不同消息类型之间的映射。它们可以从接收端口、发送端口或编排中调用。

编排或多或少是使用 XLANGs 语言的服务。如果设计得当，它们可以提供非常强大的业务逻辑处理和应用程序处理，所有这些都具有 BizTalk 提供的上述架构特性（持久消息传递、高可用性）。

【讨论】：

我习惯于将我的 XML（或任何标准）直接从 C# 类反序列化到 C# 类。而且我不知道 XLANG 被用于编排之外的任何事情——为什么我们坚持使用设计师或使用专业语言？
BizTalk 将通过直接使用 XML 来节省一些反序列化的成本。仍然可以将其序列化为 .net 类（并在从管道或业务流程调用的 .NET 类库中对其进行操作），但在 BizTalk 中通常不需要这样做。设计师起初有点烦人，但它提供了对流程和逻辑的快速视觉查看。如果您有更复杂的需求，可以从表达式形状调用 .NET 库

【解决方案2】：

我从不同的角度看待它。 BizTalk 比 WCF 更符合 Web/SOAP 和跨平台标准、Xml 和现在的 JSON。 BizTalk 还支持比 WCF 更多的协议。 BizTalk 支持 WCF，而不是相反。

WCF 堆栈可以在 .Net 类上构建合同和序列化/反序列化是自定义方法。请记住，WCF 只是对您隐藏所有 Xml/Xsd，它仍然存在并且与 BizTalk 使用的相同。

BizTalk 是在 WCF 之前作为可靠的跨平台多协议集成引擎设计和交付的。就能力而言，BizTalk 堆栈作为一个整体比 WCF 高出几个数量级。在实践中，我们在 BizTalk 应用程序中花费了大量时间来解决 WCF 的限制。*

*为了清楚起见，我主要指的是 OOB 绑定元素以及它们在实际实现中的应用。 WCF 作为一个框架是完全可用的。

【讨论】：

【解决方案3】：

我的研究表明，BizTalk 自 2004 年以来基本保持不变，因此不会出现在 Microsoft 堆栈的其他领域中看到的那种技术融合。其原因似乎是因为从 BizTalk 2002 到 2004 的痛苦迁移，没有人愿意复制。让我想起实体框架的许多版本。

在 2010-2011 年，出现了一场“BizTalk 已死”运动，并承诺 WCF、Workflow Foundation 和 Azure 上的 AppFabric 的组合将成为替代工具。自 2012 年以来几乎没有人谈论它——看起来这两种技术都有其独特的优点和缺点，但两者永远不会竞争。

BizTalk 具有开箱即用的节流和磁盘持久性以及其他地方未标准化的各种适配器（企业级）的优势。就好像它的姿态是驯服一头笨重的野兽一样。它似乎仍然受到利用过去 10 年出现的可扩展性选项的影响。另一个堆栈更符合我最初的预期，但缺乏企业性。

我不太明白 BizTalk 被描述为发布/订阅模型与……其他模型。需要对此进行更多研究。

总之，我不喜欢这两种技术，我认为它们都需要改进。

感谢所有阅读此问题和回答问题的人。我知道主观答案对堆栈溢出来说不是什么大事。

【讨论】：

“证明”是描述 BizTalk Server 的最佳词汇之一。是的，产品的核心到现在已经 11 年了，但是……嗯……那又怎样？它已经奏效，现在奏效，并将在可预见的未来继续奏效。 WF 是替换 BizTalk 核心的唯一真正机会，有一段时间，平价似乎是合理的，但随后，WF 就停滞不前了。请记住，BizTalk Server 和 WCF 没有可比性。这就像将 Windows Phone 与 Polycom 进行比较 :)
@Johns-305 - 我读到他们想用 WF 替换 BizTalk Server 的核心，但他们将其比作心脏手术。他们一定在某个时候得出了结论，不要惹它。当我说“WCF”时，除了 wsdl 标准之外，我真的在考虑 svcutil.exe 及其产生的合同，从而抽象出 XSD。从开发的角度而不是胆量/引擎的角度来看，BizTalk 确实停留在 2004 年。