在Biztalk中序列化或反序列化程序集引用的位置和方式是什么

Question

我被一个问题卡住了。我有一个引用第三方Schema dll的BizTalk 2010应用程序。我们的架构师告诉我们不要直接引用它，因为序列化这个大约9MB的巨大dll需要更多的时间，这将导致Biztalk的工作更多。

我们的编排消息具有从该架构dll引用的messagetype。

我想知道的是，这个外部dll的序列化发生在哪里，因为这个dll已经被部署，并且编排实例可以针对传入的任何请求消息引用它。

是否对创建编排实例的每条消息进行序列化。

请分享你的想法。

谢谢。

Answer 1

虽然被引用的程序集将被添加到MgmtDB中是事实，但添加的只是关于程序集和其中工件的元数据，例如

use BizTalkMgmtDb
select * from dbo.bts_assembly
... dbo.bts_orchestration
... dbo.bt_DocumentSpec
etc.

他/她可能指的是从程序集中的模式类创建的消息实例(并存储在messagebox中)。但是消息的大小将由其中的数据大小决定，而不是由程序集的大小决定。

因为你似乎需要引用的消息模式，所以除了在你的新项目中引用它之外，没有太多的选择(例如，除非你有第三方程序集的源代码，在那里你可以重构它并将其拆分成几个较小的程序集)。第三方程序集需要部署在您的BizTalk服务器上，并进行签名和GACed。

但是，如果这个引用的模式程序集还包含其他工件，比如在编排中用作变量的自定义类，那么一旦编排达到脱水点，这些类就需要是serializable的(为了避免这种情况，您需要在脱水点之前确定变量的范围，并且/或者使用原子作用域来防止BizTalk完全脱水，但这通常不是一个好主意，因为它会限制可伸缩性)。

Answer 2

您的架构师对BizTalk何时根据其定义的模式执行文档验证做出了错误的假设。

根据庞大的Schema (如EDIFACT或OASIS )验证大型文档可能会占用大量资源。因此，除非您在接收管道中显式要求BizTalk验证传入文档的相关架构，否则它不会这样做。默认情况下，大多数管道组件的'ValidateDocument‘属性将设置为'False’。因此，BizTalk将仅基于名称空间和根节点执行文档识别，这是在流读取文档流的前几百个字节时完成的。

因此，您可以自由地“引用”第三方DLL，唯一的性能损失将是在编译和部署时。如果出于某种原因，您需要根据此模式验证文档，则无论如何都需要将其放在Management DB中。