从.net开发人员的角度来看，我最近被介绍给了BizTalk。我期待像一系列服务引用，自动映射类和工作流程。我真的不希望使用大量的XSD，我对编排地图感到惊讶。
我只是不明白为什么它不像是在WCF基础上构建的一堆企业功能。
任何人都可以帮助我理解BizTalk的设计背后的想法吗？
答案 0 :(得分：2)
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（或其他）数据。
Maps在后台使用XSLT来转换XML消息;可以指示地图使用自定义XSLT，也可以使用C＃，VB或JScript。但是，对于大多数平凡的映射任务，可视化映射接口允许快速开发和测试不同消息类型之间的映射。可以从接收端口，发送端口或业务流程调用它们。
Orchestrations或多或少使用XLANGs语言的服务。如果设计得当，它们可以提供非常强大的业务逻辑和应用程序处理处理，所有这些都具有BizTalk提供的上述架构特性（持久消息传递，高可用性）。
答案 1 :(得分：2)
我从不同的角度看待它。与WCF相比，BizTalk更符合Web / SOAP和跨平台标准，Xml和现在的JSON。 BizTalk还支持比WCF更多的协议。 BizTalk支持WCF，而不是相反。
WCF堆栈可以构建合同并序列化/反序列化.Net类是自定义方法。请记住，WCF只是隐藏了你的所有Xml / Xsd，它仍然存在，并且与BizTalk使用的相同。
BizTalk是在WCF之前设计和发布的，是一种可靠的，跨平台的多协议集成引擎。就功能而言，BizTalk堆栈整体上比WCF高出几个数量级。在实践中，我们花了很多时间在BizTalk应用程序中解决WCF的限制。*
*为清楚起见，我主要指的是OOB绑定元素及其在实际实现中的应用。 WCF作为一个框架是完全可用的。
答案 2 :(得分：0)
我的研究表明，BizTalk自2004年以来基本保持不变，因此不会遇到微软堆栈其他领域的技术融合。这样做的原因似乎是因为从BizTalk 2002到2004年的一次痛苦的迁移，没有人想要复制。让我回想一下实体框架的许多版本。
在2010-2011，有一个＆＃34; BizTalk已经死了＆＃34;运动，承诺Azure上的WCF，Workflow Foundation和AppFabric的组合将成为替代工具。自2012年以来，几乎没有人谈论它 - 看起来这两种技术都有其独特的优点和缺点，但两者都不会竞争。
BizTalk具有开箱即用的限制和磁盘持久性以及各种其他地方未标准化的适配器（企业级）的优势。好像它的立场就是驯服一个笨拙的野兽。它似乎仍然受益于过去十年中出现的可扩展性选项。另一个堆栈更符合我最初的预期，但缺乏企业性。
我并没有把我的头脑包裹在BizTalk被描述为发布/订阅模型而不是......其他一些模型。需要更多地了解它。
总之，我不喜欢任何一种技术，我认为他们都需要工作。
感谢所有阅读此问题的人和回答此问题的人。我知道主观答案在堆栈溢出方面并不重要。