BizTalk 2010 学习笔记——第二章 BizTalk 2010 开发简述

这章简要介绍：

BizTalk的开发体验；

解决方案架构的最佳实践；

BizTalk中的类型

监控一个解决方案

2.1 开发BizTalk解决方案

BizTalk解决方案的开发很大程度上包含Visual Studiog的开发。

创建一个BizTalk解决方案通常包含下列操作：

Creating
schemas

Creating maps

Creating orchestrations

Deploying locally

Binding the solution

Creating visibility and
monitoring

Testing the solution

前面4个步骤都是通过Visual Studio完成的。第5步通过BizTalk管理控制台完成，第6步通过在Excel和Tracking Profile Editor完成。第7步可以需要在很多环境下完成，比如单元测试中。

开发流程中的主要组成部分：



Schemas 用来描述内部和外部的数据类型。

映射（Maps）是用来桥接内部和外部消息格式的转换。

流程（Orchestrations）用来描述消息流。

绑定（Binding）用来连接流程、终结点（Ports）、映射和架构。

BAM用来提供可视化的监控。

所有我们在VS里创建的东西编译后会进入.NET assemblies，BizTalk运行时会加载这些程序集，来执行BizTalk应用程序。

2.2 分解BizTalk解决方案

BizTalk解决方案的结构的好坏对于该应用开发、部署和后期维护都非常重要。

2.2.1 详述解决方案的结构

BizTalk的结构模式必需支持下面的几个要求：

多人同时开发

可以在任何开发者的机器上编译开发

可以在任何开发者的机器上做测试

TDD支持

自动化功能测试

持续集成（CI）

自动性能测试

2.3 理解BizTalk解决方案的层次（layers）

下图描述了BizTalk中各层的相互影响关系：



这种组织方式也告知我们如何组织我们的解决方案项目。比如外部的schema不能影响我们的流程，流程的变化也对外部是不可见的，透明的。

这个理念也可以通过UML图描述，如下：



2.4 Visual Studio 解决方案结构

首先启动一个空白VS解决方案，添加项目，一般会添加6个项目如下：



2.4.1 项目

下面是典型的VS中BizTalk项目

2.4.1.1 外部架构（.xsd files）

2.4.1.2 内部架构（.xsd files）

2.4.1.3 映射（.btm files）

此项目引用上述2.4.1.1和2.4.1.2两个项目。

上项目也防止BizTalk项目对外部的依赖。

2.4.1.4 管道（.btp files）

引项目引用 2.4.1.1或者2.4.1.2.

2.4.1.4 管道组件（.cs files）

并不是每个解决方案都需要这个项目，这个项目是一个.net 类库。

2.4.1.5 流程（.odx files）

2.4.1.6 库（C#,resources,and so on）

2.4.1.7 测试（.xml,.dtd,.cs files）

2.4.1.8 非项目事物

还有一些解决方案层级的文件夹。

这些文件夹都是逻辑文件夹，不是物理文件夹，但是你也可以创建物理目录来匹配这些目录，用来保存对应的信息，这此目录包括：

第三方程序集

绑定

编译

策略

跟踪

2.4.2 解决方案结构的动机

其实就是为了分离部署，什么模块有问题只有更新对应的程序集就行了。

2.5 理解BizTalk中的类型

所有BizTalk构件通过编译后都会变成 .net的类型。

在大多数编程语言中，类型是开发过程中用来组织代码的结构。BizTalk用来桥接消息传输。这就意味着BizTalk同有支持消息类型和.net 类型，XML消息是消息传输类型，但是任何东西都是一个.net类型。

VS项目中的每个BizTalk构件有一个命名空间和类型名称。

2.5.1 消息类型

XML消息有自己的消息类型，XML通常用ROOT元素来识别唯一性，包括命名空间和元素名。

Biztalk通过命名空间和根元素名来匹配指定的架构。比如：



此消息类型就是"http://somecompany.net#order"

对于非XML的消息，它们是非类型化的。这就意味着这些数据内容不能路由或者在映射模块中使用它们。但是仍然可以在上下文和BizTalk内部用.net 类型来使用它们。

2.5.2 上下文中的类型

在BizTalk中，在不同的上下文背景下也有不同的类型。

所有BizTalk的消息引擎，包括管道组件，都把消息描述为下面接口的实例：

Microsoft.BizTalk.Message.Interop.IbaseMessage.

一旦进入流程，消息被呈现为：

Microsoft.XLANGs.BaseTypes.XLANMessage的实例。

但是这些类不能被互相转换，它们是各种组件专有的。

一个消息到达BizTalk，穿过管道（及其组件）和映射，到达消息数据库。这个过程中消息被呈现为IBaseMessage.

之后如果一个流程使用了这个消息，这会当作XLANGMessage类型的新的消息，与之前的完全没有关系。

这个过程其实是两个过程，但是在外部看来它是一个连续的过程。

再深入一点，一个消息在一个流程中也可以被声明为“System.Xml.XmlDocument”的一个实例。这两种类型同时存在本质上没有多大的联系，只是它们同时被使用，有历史上的原因。从历史来说，以前的BizTalk版本通过使用DOM扩展来传输XML文档，所以就用了XmlDocument类，这是.net的DOM对象。另外一个原因是它允许用户在流程中通过一种简单的方式来操作非XML消息。

但是对于非XML类型消息，如果使用XmlDocument的成员去操作它，BizTalk会在运行时抛出异常。

XmlDocument在流程中使用是非常危险的，应该避免它在流程中使用。

2.5.3 类型解析

在一个只有消息传递，而没有流程的场景中，BizTalk做了一个双向的类型解析。

首先是确定消息的类型，这时通知命名空间和根元素也确定消息的类型。

BizTalk通过这个消息类型从.net程序集中去检索架构信息。

在BizTalk中不能存在两个命名空间相同，同时根节点也相同的架构，系统会抛出异常：Multiple schemas match the message type.

另外，Pass Thru 管道不会检查和修改消息。

2.6 理解解决方案的运行时

之前我们已经讨论过BizTalk通过管理数据库和加载GAC中的程序集来运行应用程序。

本节涉及以下几个方面：

BizTalk runtime(.Net runtime)

Message Box

Management database

Global Assembly
Cache（GAC）

这几个除了GAC其它都上面有说到，GAC是.net程序集的数据库或者说是仓库，有了GAC我们可以不用关心COM DLLs版本带来的问题。

GAC中的程序集必需包含一些参数，最重要的就是强命名。

所以BizTalk的程序集也必需是强命名的。它带来的好处有很多。比如允许多版本存在，安全等等。

下面的图表描述了BizTalk加载解决方案时的步骤：



当一个消息到达BizTalk时，宿主实例（BizTalk运行时）接收消息，检查消息是否能匹配到已知的消息类型。已知的类型列表存在管理数据库中。

找到匹配消息类型后，运行时从GAC中加载程序集。

运行时自由地加载.net类型，可能是一个schema,映射，管道或者是一个流程。

上图描述了BizTalk解析消息类型和从GAC中加载架构。重要的一点是，每种类型从GAC中加載在一个宿主实例的一个生命周期中只会发生一次。当重启实例时（Windows的服务），它们才会在第一次使用时再被加载。不过BizTalk中的有些程序集也会在某个空闲时间点被卸载。

每个.net应用使用GAC时，并不是真正地从GAC运行程序集，而是复制出来放在自己的工作区域。所以当程序运行时更新和修改GAC里的程序集是不需要被中断。当然新更新的GAC里的程序集也是不会马上被加载到正在运行的.net程序域中的，除非应用程序域被重新加载，也就是重启宿主进程，或者说BizTalk的运行时。

2.7 监控

如果一个解决方案没有监控部分是不完整的。

监控分为两部分：技术上的或者平台上的。

2.7.1 为什么需要BAM

BAM是一个强大的工具集，通过它我们可以不需要写一行代码实现业务信息的收集，分析。包括复杂的统计和聚合。

BAM可以被用在非BizTalk的环境，比如WCF服务。

2.7.2 理解BAM的概念

略….以后再看。