中文BTS04 Architecture WhitepaperWord文档格式.docx
《中文BTS04 Architecture WhitepaperWord文档格式.docx》由会员分享，可在线阅读，更多相关《中文BTS04 Architecture WhitepaperWord文档格式.docx（15页珍藏版）》请在冰点文库上搜索。
SOA模型的出现，使得应用程序的概念被重新定义。
应用程序不再是一种非透明、程式化的实现机制。
相反，它是一个由通讯、路由、处理和转换事件构成的和谐体系，可以处理丰富（XML）文档公开声明的属性。
工作流程、集成应用或者业务伙伴的交流都是SOA模型的特定类，仅通过有关参与者的特性、执行位置以及参与者的特有安全需求来区分。
融合了SOA模型后，BPM/EAI平台将变得如虎添翼，它们可以在开发和操作方面体现诸多优点：
∙它们可以改善严重的低效开发现象，并且为实现有效的生命周期维护减少障碍。
∙它们有利于在高度分散的基础上对组件实现灵活的“松散耦合”。
∙它们允许在不影响流程的情况下添加、删除和重新配置任何流程操作。
∙它们从根本上为长期运行的异步事务提供支持，并且这些事务可以灵活地缩放。
∙它们为应用程序的良好管理和监视提供了保证，因为进程操作、组件和函数都是公开的，并且都能自我描述。
∙借助它们，可以对应用程序组件和整个应用程序进行扩展或者重新利用。
∙它们可以利用Internet网络基础设施和WorldWideWeb协议标准。
使用基于SOA模型的开发环境需要对应用程序的开发概念和思想进行重新定位。
在本文中，我们介绍了最基本的SOA概念和开发思想。
随后从两个具体的环节上探讨了Microsoft®
EAI开发环境，即BizTalk®
Server2004，是如何实现这些概念和思想的。
这两个环节是：
所创建应用程序的设计、行为和功能；
以及开发过程本身。
本文最后介绍了同VisualStudio®
.NET集成在一起的BizTalkServer开发工具是如何在.NETFramework架构和SOA模型之间搭起一座桥梁的。
BizTalkServer–SOA实现
如果您希望获得上述的开发和操作优点，则在BizTalkServer中实现SOA的价值也就不言而喻了。
首先，我们可以审视一下开发过程的低效现象以及BizTalkServer解决它们的具体方式。
传统的编程思想不足以将应用程序或业务流程的概念模型（例如：
设计规范）转换成可执行的形式（即程序）。
尽管开发注释系统（如UML）允许业务分析人员使用结构化方法编写功能规范和使用范畴，但编程人员仍需要对这些文档进行分析，并将其意图转换为不同的语言和结构。
这种手工化并且需要高度分析的转换过程有着非常明显的不足之处，这就使得效率低下，尤其是需要反复进行修订。
一旦将业务流程精确地转换为程序代码，另一个问题通常又会凸现出来：
同代码所模拟的业务流程相比，代码的行为更加缺乏可预见性。
这种偏差来源于程序化代码实现方法的本质。
程序化代码同机器执行模型紧密联系在一起，在它对业务流程的不透明体现中封装了多个级别的相互联系、相互依存的功能。
其结果便是：
程序化代码非常容易导致程序错误，而这些错误往往很难和需要大量的时间来进行识别和修正。
这样就不难理解，为何在软件稳定运行后就不鼓励进行后续修改。
通常的情况是，即使到了非修改业务流程不可的时候，也会容忍这些僵化的代码所存在的种种限制。
BPM/EAI开发环境允许业务分析人员和编程人员在一个融合并关联了两者各自任务的可视化流程模型上使用公共的工作区进行协作。
通过使用拖放式的图形用户界面对代表消息、消息事件、业务规则和逻辑、信息流、活动、操作、转换以及子流程的高级对象进行协调安排，编程人员和分析人员可以协同创建应用程序。
而模型自身会直接针对流程生成可执行的运行时程序集。
这种机制将传统方法所固有的模糊性和大量修订过程减少到最低程度，从而大幅度提高开发效率和灵活性。
尤其是，对于那些极度复杂的函数，比如需要两步式的事务提交过程、回滚ACID事务支持以及嵌套和并行操作，它都将其实现机制内置于对象的函数中，因此不再需要编写复杂的程序语句来实现这些功能。
为了更好地说明SOA开发机制，下述步骤介绍了在遵循该模型的BizTalkServer中创建应用程序的过程：
创建在应用程序/流程中涉及的文档及其各自的架构定义。
这将在“架构编辑器”（BizTalkSchemaEditor）中完成。
“架构编辑器”是一个BizTalkServer模块，可从VisualStudio.NET内访问。
通过架构编辑器，您可以定义结构和语义方面的元数据。
对从该架构创建的文档（即一个“实例”），这些元数据“声明”了其内容的含义、功能和处理要求。
当BizTalkServer收到一个文档实例时，同该文档关联的流程会根据该文档的架构定义来检查其内容，以确保该文档的形式和内容都符合架构以及符合应用程序的处理要求。
BizTalkServer架构编辑器可以为架构创建符合W3C标准的XSD文档以及可视化的树状节点参考模型。
以下是架构编辑器的示例。
该架构编辑器在左窗格中显示了架构的树状节点模型，在右窗格中显示了文档架构的XML表示形式。
创建和定义面向任何文档交换操作的转换要求。
如果应用程序是由XML对象之间的松散交互组成的，文档转换将是一个在功能上向外界暴露的映射子过程。
在BizTalkServer中，这种子过程将通过BizTalkServer映射器来创建。
通过转换映射，可对任何源信息（基于其架构表示）的内容和结构进行处理，然后转换为任何目标文档格式（比如报告）。
通过使用与BizTalk架构编辑器一样的架构树状节点模型，BizTalkServer映射器可以用可视化的方式显示源信息和目标信息的格式。
信息可以从源架构的一个或多个节点映射到目标架构的一个或多个节点，方法是用线条连接这些节点。
Functoid提供了补充性（额外的）的转换、处理和解析功能（循环、累加、日期和时间、递归，等等）。
通过（图形化实现）将一个或多个源节点连接到某个functoid，然后将该functoid连接到一个或多个目标节点。
每个转换映射（以及所涉及的源和目标架构）都将变成BizTalkServer的项目资源，随后可作为一个流程环节将这些资源嵌入业务流程中并编译成业务流程程序集。
可以根据需要重新利用和修改映射，以实现任意数量的转换要求以及将它们部署在任何数量的业务流程中。
BizTalkServer映射器创建的映射基于转换XML信息的开放式标准协议，即XSLT。
指定控制事件执行的业务逻辑。
如果业务逻辑比较简单，则可以将它作为一个表达式直接嵌入到BizTalkServer业务流程决策步骤中。
如果业务逻辑比较复杂，可以使用BizTalkServer业务规则设计器来创建和处理复杂的规则集。
每个规则集（或者说“策略”）驱动一种特定的操作或功能，并且将成为内嵌在BizTalkServer业务流程中的资源对象。
同整个BizTalkServer架构一样，创建和实现业务规则的整个过程也是透明的，并且联系松散。
一个嵌入BizTalkServer业务流程的业务规则集可以在设计或者运行时被查看、修改或者完全被替换而不影响其它的流程操作或者中断本流程的实例的运行。
由一个向外界暴露功能的组件化规则引擎提供灵活修改商业流程的特点具有极其重要的意义。
在传统的应用程序开发过程中，业务规则逻辑嵌入在程序的代码之中，如果不修改代码，则无法修改这些业务逻辑。
由于对业务流程生命期的大多数修改都仅限于业务规则的变动（相对与技术方面的修改），因此是否能将业务规则同程序代码完全隔离开来，或者同任何流程实现机制隔离开来，将决定是否能大幅度提高在整个业务流程生命期中管理和调整业务流程的效率。
在定义业务规则方面，BizTalkServer业务规则编辑器支持创建同行业领域有关的词汇，其功能是通过公共接口呈现的，因此它具有极其高的灵活性和扩展性。
下图显示了BizTalkServer业务规则编辑器模块。
确定和实现消息前期处理和后期处理的要求。
这一步在BizTalkServer管道设计器模块中完成。
管道设计器可从BizTalkServer的业务流程工作区访问。
该模块用于实现同外部应用程序和团体在交换上的加密、身份验证和数据格式转换要求。
管道是指在业务流程或消息数据仓库收到消息或从它们分派消息之前发生的处理操作序列。
“接收管道”可根据要求接受传入的消息、将消息解密或解压缩、将消息分解成消息的部件，将消息转换为XML文档（按照在BizTalkServer架构中的说明）、验证消息以及验证消息发送者的身份。
一旦有消息通过管道，该消息就会被传送到BizTalkServer的MessageBox存储。
“发送管道”执行的操作与“接收管道”相同，只不过是反方向的。
它可以根据外部接收者的要求对消息进行组装、格式化、加密、压缩和数字签名。
编辑和编排应用程序/流程环节。
这一步在BizTalkServer业务流程设计器中进行。
业务流程设计器是VisualStudio.NET中的主要工作区，在此可以开发和实现完整的BizTalkServer应用程序。
通过拖放业务流程工具箱上的对象形状并将它们连接在一起，可以编排业务流程图表。
这些形状代表了各种流程活动，比如接收、调用、序列、流程、连接和来源。
借助这些形状，可以编辑和执行消息流、消息事件、业务规则、活动、操作、转换以及子流程。
下图显示的BizTalkServer业务流程图表实现了这样的工作流程：
∙流程应用程序（一个BizTalkServer业务流程）收到一个库存订单补给请求（“Request”）。
∙流程应用程序检查所订购商品的数量。
如果订单的商品数量超过500件，则拒绝该订单。
如果订单的商品数量未超过500件，则接受该订单。
∙如果订单被拒绝，将创建通知（“ReqDenied”）并发送给进行订购的人员。
∙如果接受了订单，则原始的订单请求将被提交给ERP系统处理。
在编辑如图所示的流程图时，可以从工具箱中拖放下列形状，然后对其进行修改：
∙在设计窗口的顶部放置一个“接收”（Receive）形状，并将其命名为Receive_Req。
∙在Receive形状之下放置一个“决策”（Decision）形状，并将其命名为CheckQuantity。
该决策形状会自动创建两个活动分支形状（“If”或者“Else”）。
If形状被重命名为Decline。
Decline形状被连接到一个表达式编辑器。
在该编辑器中创建了“RequestInstance.Item.Quantity>
500”的XPATH表达式。
该XPATH表达式将按照“If”规则（该规则指定了对订单请求的拒绝条件）执行操作。
∙在Decline形状之下放置一个“构造消息”（ConstructMessage）形状，并将其命名为Construct_ReqDenied。
∙在Construct_ReqDenied形状中放置一个“转换”（Transform）形状。
∙在Construct_ReqDenied形状之下放置一个“发送”（Send）形状，并将其命名为Send_ReqDenied。
∙在Else形状图形之下放置一个“发送”（Send）形状，并将其命名为Send_REQToERP。
将设计形状同实现对象链接起来。
编排了各个流程步骤之后，下一步是将这些形状同为实现流程而所需的对象链接到一起。
这些对象可能包括实际的消息文档、发送和接收消息的端口位置以及为了传送消息而要求的传输机制。
该阶段也同样在业务流程设计器中执行。
在业务流程图表示例中，当运行的进程收到一个Request文档实例时（注意，该进程是Receive形状启动的），该进程会根据该文档的架构定义来检查其内容，以确保该文档的形式和内容都符合架构以及符合应用程序的处理要求。
如果Request文档不符合要求，嵌入在ConstructMessage流程中的Transform子流程将引用一个负责将Request文档转换为ReqDenied文档的XSLT转换映射（按照在步骤2中的说明）。
如果可行，定义团体和团体的角色，并将其连接到业务流程功能。
这一步在BizTalkServer浏览器（为构成具体BizTalkServer项目的业务流程和外部组件提供配置信息的工具）中完成。
该浏览器以分层的树状结构组织。
借助该浏览器，可以配置项目业务流程编排同其它项目组件（比如角色、团体、发送和接收端口以及接收位置）的关系和交互。
在业务流程编排图表中实现了所有的逻辑步骤之后，则可通过对该业务流程图表执行“生成”操作来生成VisualStudio.NET运行时程序集（DLL文件）。
该程序集可作为一个单独的应用程序来实现，或作为一个组件包括在更大的BizTalkServer解决方案中。
BizTalkServer解决方案（一个流程应用程序）包括一个或多个VisualStudio.NET项目，而后者又含有架构、业务流程、转换映射和管道等BizTalkServer组件。
就以此前介绍的示例来说，在一个不连续的BizTalkServer项目（该项目生成经过编译的程序集）中包含有Request和ReqDenied文档以及它们的转换映射。
在该解决方案中，对流程进行了详细描述的BizTalkServer业务流程图表也是一个不连续的BizTalkServer项目。
通过引用（封装）架构和映射程序集，该编排图表可以像功能对象那样引入这些架构和映射。
随后可将所有的BizTalkServer项目程序集作为在BizTalkServer运行时引擎管理下的可执行应用进行部署和安装。
SOA——底层技术
介绍了如何使用BizTalkServer2004中的高级工具来开发和实现应用程序之后，现在我们可以站在面向服务架构（SOA）模型的底层支持技术的角度来审视这种开发思想。
如前所述，SOA的基本原则是暴露功能、用文档交换信息、松散耦合以及平台无关性。
XML提供了透明性和应用程序无关性，它使用元标记“声明”数据的含义和作用。
使用XML的前提条件是，将同程序相关的数据转换为自我描述因此同程序无关的数据。
这不仅涉及内容，而且还包括用来处理内容的指令。
XML架构提供了语义上的一致性和互操作性。
作为一种规范，XML架构为创建XML文档正式定义了一组扩展的数据类型基元和结构组件；
其作用就有如用来提取元素、属性实体和组织规则的一本词典。
创建符合架构“词典”的XML文档将具有非凡意义：
对支持XML并且可以访问XML文档的底层架构的应用程序来说，可以了解XML文档内容的含义、功能和使用方法，并且可以执行相应的操作。
在各个行业中，所有针对信息交换和处理而制定通用词汇和过程集合的行业计划都无一例外地基于XML架构。
事实上，XML架构甚至已充当了Web服务协议的基础。
Web服务协议包括简单对象访问协议（SOAP）和Web服务定义语言（WSDL）。
借助它们所提供的功能和消息处理能力，用户无需自定义代码即可在任何平台上的任何位置绑定和执行程序化功能。
Web服务规范的意义在于，它们为在Internet上构建复杂、可互操作的计算流程提供了第一个切实可行的架构。
SOAP是一个基于XML的消息处理协议，用于对文档进行编码，以便通过网络进行传输。
“SOAP客户程序”可在SOAP封装中插入XML文档，并使用HTTP将其发送到接收该信息的“SOAP接收程序”（后一个操作也被称为“编组”）。
SOAP消息处理具有诸多优点：
∙SOAP客户程序和接收程序的构建都比较简单。
用户可以方便地将SOAP客户程序作为例程嵌入任何程序或网页中，并且使用URL终端程序作为SOAP接收程序。
∙通过使用HTTP作为传输机制，SOAP消息可被发送到任何位置，并且可使用现有的SSL功能进行身份验证和加密。
另外，还可以充分利用万维网现有的基础设施规模。
∙消息、SOAP封装、消息头以及消息正文中的所有信息都以XML表示，因而使得整个对象都完全透明。
由于文档的语义和结构都是完全暴露的，因此不必编写应用程序代码即可对文档执行广泛的验证、操作、路由和转换功能。
与CORBA不同的是，Web服务网络终端（HTTP、URL或其它地址）可以支持多种XML格式，从而可以实现真正多形态的接口，并且不会受新版本的影响。
∙由于HTTP是SOAP使用的传输机制之一，因此可以在全球任何位置的任何支持Web的计算机之间调用Web服务方法。
这样一来，SOAP就有望建立同万维网的规模一样大的分布式计算流程。
Web服务定义语言（WSDL）是通过信息交换或远程过程调用（二者都使用SOAP协议和按照XML格式封装的信息）来描述、传达以及调用程序功能的规范。
WSDL文档驻留在URL位置，并且同位于其它任意位置的实际程序模块链接在一起。
业务流程内或者可通过业务流程访问的大多数功能都可以用Web服务的方式暴露出来，例如查看数据库、调用复杂的业务规则或者调用整个业务流程自身。
由于公共Web服务接口同程序的私有实现方法无关，因此可以非常容易地构造高度模块化和高度分布的应用程序。
BizTalkServer中的BusinessRuleFramework（业务规则架构）代表了一种实现面向服务架构（SOA）模型的创新途径。
每一个单独和组合级别的功能在设计上都是公开、独立，并且可以进行松散组合。
任何策略组件（词汇或规则集）都可以随时查看或更改，并且不会影响其它任何流程操作或者相关流程正在运行的实例。
另外，还可以利用策略的语义和可声明的XML定义将策略直接编译到VisualStudio.NET程序集中，从而完全不再需要任何程序化的编程实现方式。
该功能使得开发效率和生命周期管理效率得到了质的飞跃，仅此就可以证明面向服务架构模型的价值所在。
一个公开的组件化的规则引擎是否能为修改业务流程提供足够的灵活性，其意义将非常重大。
在传统的应用程序开发中，业务规则逻辑内嵌在程序代码中，如果不更改代码，将无法修改业务规则逻辑。
而频繁改动代码，不仅费时费力，而且往往会造成不可预计的程序行为。
.我们可以清楚地看到，如果能将业务规则同程序代码或者同任何流程实现机制完全隔离开来，将可以大幅度提高管理效率和针对新需求或新业务形势做出调整的效率。
单从在业务流程设计器中的开发过程来看，就足以说明何谓功能暴露和何谓松散耦合。
借助业务流程设计器，开发人员可以让复杂的业务逻辑及其对应的实现方法变得可见，从而提高了软件开发的可管理性和降低了其抽象性。
每个逻辑流程都同离散的实现机制相组合。
这些实现机制含有自我描述的方法。
借助功能上的透明和隔离，可从VisualStudio.NET宿主环境或直接通过XML表述来访问解决方案中各个对象的属性（业务流程、架构、映射等等）。
此外，已完成的业务流程还可以为整个流程生成业务流程执行语言（BPEL）文档。
由于BPEL指令集是流程的XML表示，具有精确的语言和语法结构，因此可为流程描述提供可阅读和可理解的指令集。
这个价值不可低估。
在过去，描述方面的欠缺使得软件和流程无法轻易修改和调整。
事实上，业务流程设计器中的流程形状形象地描述了基本和结构化的BPEL元素，比如接收、调用、序列、流程、角色、连接和来源。
在BizTalkServer业务流程设计器中开发的流程可以用BPEL文档的格式导出，然后可以导入其它任何兼容BPEL的应用程序中。
反过来看，也可以将BPEL文档导入BizTalkServer业务流程设计器来生成业务流程图表。
这种流程指令的标准化交换，可以有力促进业务伙伴之间的协作性业务流程开发。
随着在BizTalkServer2004中应用SOA模型，XML功能的重要性无疑将与日俱增：
∙XML和XML架构使得Web服务协议（SOAP和WSDL）的创建成为可能。
∙BPEL功能在上述核心的Web服务协议之上，为在流程中添加额外的XML功能（比如业务规则或处理逻辑）创造了条件。
∙虽然每个流程的价值都是独立的，但一旦同其它流程组合在一起，它们就能发挥整体性效应并且针对众多的难题提供创新性的解决方案。
这也正好说明了整体要优于组件的简单组合。
由于BizTalkServer业务流程设计器内嵌在VisualStudio.NET内，因此它还成为了SOA和.NET这两个框架之间的桥梁。
.NET框架包括两个主要部件：
公共语言运行时（CLR）和一组统一的类库。
这些类库包括用于Web应用和Web服务的ASP.NET、用于智能客户端应用的WindowsForms以及用于松散组合式数据访问的ADO.NET。
.NET框架为将现有的信息技术投资同下一代应用和服务进行集成提供了高生产性和基于标准的环境。
一旦同BizTalkServer中高级的XML抽象功能和可视化设计能力结合，它将为人们呈现一个提供了空前功能和效率的开发和部署环境。
另外，它还提供了始终一致的风格，开发人员不仅可迅速掌握SOA方法，而且仍然能利用他们原有的.NET技术专长。
我们正在迈入一个新的计算时代。
在这个新时代中，信息来源于各种完全独立的应用，但各个信息的结构、成分以及行为都将基本相同。
在创建和发布信息时将不必考虑信息的处理或使用方式。
应用程序将同时处理信息和方法，然后它又被其它系统继续处理。
流程将可以实现自我配置和修改。
我们将看到从面向服务的架构模型涌现出全新的应用程序、新的业务模型以及新的手段，而它们将为我们带来前所未有的新体验。
同任何模型转换一样，SOA凭借它所携带的优势必将得到广泛的认同。
各方面的事实都明显证明了这一点。
开发效率的大步提升、投资回报的加
升级会员 