CN101836200A

CN101836200A - 基于模型的合成应用程序平台

Info

Publication number: CN101836200A
Application number: CN200880113463A
Authority: CN
Inventors: D·F·布克斯; D·W·胡德; B·H·洛夫林; S·T·斯沃茨; J·S·品克斯顿
Original assignee: Microsoft Corp
Current assignee: Microsoft Technology Licensing LLC
Priority date: 2007-10-23
Filing date: 2008-10-22
Publication date: 2010-09-15
Anticipated expiration: 2028-10-22
Also published as: EP2203848A4; EP2203848A1; CN101836200B; BRPI0816893A2; US20090157872A1; JP2011501854A; RU2010116037A; JP5277251B2; US8751626B2; WO2009055492A1; RU2502127C2

Abstract

各实施例提供一种用于使得能够构建和部署合成的自主的合成应用程序和服务的体系结构。另外，提供了一种允许分布式应用程序和服务之间的通信的基础结构。在一个或多个实施例中，一种示例体系结构包括或以其他方式使用五个逻辑模块，包括连接服务、进程服务、身份服务、生存期服务、以及工具。

Description

基于模型的合成应用程序平台

背景

开发并部署数据驱动的合成应用程序(即通过组合多个模块来构建的应用程序)是具有挑战性的任务，尤其是在考虑在分布式环境中进行部署的情况下。

迄今，对特殊低级编程知识的需求对数据驱动的合成应用程序的开发和部署造成了难以克服的壁垒。

概述

提供本概述是为了以简化的形式介绍将在以下详细描述中进一步描述的一些概念。本概述并不旨在标识出所要求保护的主题的关键特征或必要特征，也不旨在用于限定所要求保护的主题的范围。

各实施例提供一种用于使得能够构建和部署自主的合成应用程序和服务的体系结构。另外，提供了一种允许分布式应用程序和服务之间的通信的基础结构。

在一个或多个实施例中，一种示例体系结构包括或以其他方式使用五个逻辑模块，包括连接服务、进程服务、身份服务、生存期服务、以及工具。

附图简述

在全部附图中，使用相同的标号来指示相同的特征：

图1示出根据一个或多个实施例的体系结构或平台的示例高级视图。

图2示出根据一个或多个实施例的示例服务总线的各方面。

图3示出根据一个或多个实施例的、联合名字空间组件可在其中操作的环境。

图4示出根据一个或多个实施例的示例安全体系结构。

图5示出根据一个或多个实施例的示例事务服务环境。

图6示出根据一个或多个实施例的示例消息通信服务节点。

图7示出根据一个或多个实施例的示例消息通信服务互连。

图8示出根据一个或多个实施例的示例进程服务组件。

图9示出根据一个或多个实施例的示例进程服务环境。

图10示出根据一个或多个实施例的示例目录服务环境。

图11示出根据一个或多个实施例的示例访问服务环境。

图12示出根据一个或多个实施例的示例集成服务环境。

图13示出根据一个或多个实施例的示例应用程序生存期服务环境。

图14示出根据一个或多个实施例的示例储存库。

图15示出根据一个或多个实施例的示例执行组件。

图16示出根据一个或多个实施例的示例分析服务环境。

图17示出可用于实现一个或多个实施例的示例系统。

详细描述

概览

如上所述，通过组合多个模块来构建的应用程序被称为“合成应用程序”。合成应用程序的各不同部分(例如客户机部分、业务处理部分、数据存储部分等)可以在完全不同的环境(例如，ASP.NET、BizTalk、SQL服务器)中运行，这极大地增加了将该应用程序作为整体进行处理的难度。另外，合成应用程序生存期中的各不同时刻通常缺乏自动化。迄今，合成应用程序基础结构当前滞后于其要求，例如丰富合成应用程序的作者报告他们花费超过90％的资源来编写基础结构代码根本不罕见。随着分布式处理和带宽变得越来越无处不在，公司等面临着他们所想的与他们为构建、部署以及管理所能负担的之间的令人着急的缺口。

开发合成应用程序的模型使得非传统编程团体参与构建重要的应用程序成为可能。通过使人们能够在不必编写脚本或代码的情况下操作应用程序来使这一点成为可能。诸如规则或工作流(以下描述)等功能抽象与代码和安装脚本相比有点更接近于人们实际上想象系统的方式。

在以下讨论中，介绍一平台或体系结构的概念。该平台可以提供声明性编程体验和域特定语言的统一目标。声明性体验可以在应用程序的整个生存期中提供，以使得编程最终用户能够根据声明性抽象而非根据代码或脚本来处理他们的特定系统。如下所述，利用由各应用程序、工具以及服务所共享的共同储存库，并且该储存库通过减少应用程序生存期中涉及的不同存储的数量而简化了开发和管理。储存库的更大价值是其包含模型形式的模式(schema)和内容。对储存库的进行中的使用可以教导应用程序编写者根据模型来思考。随着应用程序的更多方面表现为储存库中的内容，各部分之间的新的协同将变得显而易见并可以之前从不可能的方式来利用。

当今，管理和分析合成应用程序涉及针对该应用程序的每一部分的完全不同的体验。根据以下描述的各实施例，合成应用程序可以作为整体而非不同的部分来管理和分析。在至少一些实施例中，通过单个接口将应用程序作为整个实体来进行部署、管理、以及分析是可能的。另外，这些应用程序的各单独部分可以使用所描述的平台来增量地进行版本化。在一个或多个实施例中，观察模型可以从整个应用程序的观点来建立，这使得按照统一的分析者友好的比喻通过其各部分来理解合成应用程序的执行。

在以下描述的各实施例中，描述了一种体系结构，该体系结构使得能够构建、部署以及管理自主的合成应用程序和服务。该体系结构可以使得不同类型的合成应用程序能够按照模型来描述。合成应用程序是由数据改变事件驱动的应用程序。合成应用程序通常按照确切地指定对哪一类数据改变感兴趣的规则和在数据改变时所触发的动作来指定。例如，消息驱动的合成应用程序是由消息交换所驱动的应用程序。该组分解成n层(请求-响应)合成应用程序、排队合成应用程序、以及发布-订阅或事件驱动的合成应用程序。调度的合成应用程序是由调度器驱动的应用程序。调度器由描述通过各模块的控制流的模型来编程。工作流应用程序是这一类型的应用程序的良好示例。对于这些类型的应用程序中的每一个，存在对应的通信基础结构，或确切地说，存在该通信基础结构的对应的使用模式。

另外，提供了一种允许分布式应用程序和服务之间的通信的基础结构。该体系结构也被称为“平台”，提供一种使开发者能够构建丰富的自主的合成应用程序和服务的机制。合成应用程序由模型形式的数据来描述，其随后用来以分布式方式构建并部署应用程序组件。所描述的平台或体系结构可用来管理机器或计算设备集合和在它们之上运行的应用程序集合。

在一个或多个实施例中，示例体系结构包括或以其他方式使用五个逻辑模块，包括连接服务、进程服务、身份服务、生存期服务、以及工具，但各模块所包括的功能不必由该特定体系结构来表示。相反，可以利用其他体系结构而不背离所要求保护的主题的精神和范围。

在以下讨论中，提供了标题为“合成应用程序”的章节并讨论了合成应用程序的概念和“合成应用程序”所意味的事物。此后，提供了标题为“示例体系结构或平台”的章节并根据一个或多个实施例描述了可用来使得能够开发和部署合成应用程序的一个示例体系结构或平台。在该章节中，将提供若干子章节以描述该体系结构的各方面。最后，提供了标题为“示例系统”的章节并描述了可用来实现所描述的实施例的一个或多个方面的示例计算设备。

合成应用程序

如上所示，合成应用程序是由模型来描述的应用程序。随后可使用该模型来选择应用程序的各组成部分，构建对应的应用程序的实例，并将该应用程序实例部署在适当的环境中。因此，该平台的一个目标是能够用模型来描述合成应用程序，并随后在该平台上设计、开发、部署、以及管理这些应用程序。

具体地，在至少一些实施例中，整个连接的应用程序的结构按分布式模型来描述。该模型可以假定若干类型的模型中的一个或多个，这些模型诸如，作为示例而非限制，消息驱动的模型、数据驱动的模型、调度(或工作流)模型等。处于一个粒度级别的应用程序的各单独组件可以是处于下一粒度级别的整个连接的应用程序。更具体地，用来描述应用程序的各部分的模型的类型可以相当显著地改变。所以例如，在一个级别，可具有包括网页、某业务逻辑、和数据库的消息驱动或调用驱动的应用程序。该应用程序随后可由一种类型的模型来描述。具体查看该应用程序的业务逻辑方面，可发现其由规则和声明性工作流组成的第二类型的模型来描述。在至少一些实施例中，通过按照规则和声明性工作流来表达应用程序，向开发者提供更高级的抽象以使开发者不必理解低级编程细节。因此，通过将开发过程开放给不必具有低级编程语言知识的人员，增加了灵活性。

在一些实施例中，提供了用户界面形式的应用程序外壳(或诸如以下描述的工具等某一其他工具)并且允许开发者开发应用程序。通过该应用程序外壳，开发者可以提供对他或她的应用程序的声明性描述并可以定义命令、文档、可视化、作业或任务、通信联系人、身份、以及更多的事务。因此，该外壳可以提供一种开发者可开发并插入其应用程序的机制。该应用程序外壳于是具有在执行时使用该体系结构的较低层的机制。这些较低层机制对开发者而言是透明的。

讨论了合成应用程序的一般概念，现在考虑使得能够开发和部署这些应用程序的示例体系结构或平台的讨论。

示例体系结构或平台

在以下讨论中，描述了一种示例体系结构或平台。可以明白和理解，所描述的体系结构或平台仅构成描述本文所描述的功能的一种方式。因此，可以利用其他体系结构或平台而不背离所要求保护的主题的精神和范围。

图1在100处概括地示出根据一个或多个实施例的体系结构或平台的示例高级视图。在该示例中，体系结构100包括五个逻辑组件——连接服务组件102、进程服务组件104、身份服务组件106、生存期服务组件108、以及工具组件110。这些单独的体系结构组件具有其自己的子组件，每一个子组件都在以下对应的子章节中描述。

但简言之，在该示例中，连接服务组件102包括服务总线组件112、事务服务组件114、以及消息通信服务组件116。进程服务组件104包括工作流/规则组件118。身份服务组件106包括目录服务组件120和访问服务组件122。生存期服务组件108包括储存库组件124、集成组件126、执行组件128、以及分析组件130。工具组件110包括基于代码的组件(如VisualStudio)132、基于模型的工具(如Quadrant)134、以及企业管理工具(如系统中心组件)136。

如将在以下显而易见的，体系结构100及其各组成部分共同使得能够开发和部署合成应用程序。

连接服务组件

在一个或多个实施例中，在该示例中，连接服务组件102包括服务总线组件112、事务服务组件114、以及消息通信服务组件116。

服务总线组件

在一个或多个实施例中，服务总线组件112(或更简单地“服务总线”)提供允许应用程序和服务彼此通信的基础结构。为此，服务总线可被认为是服务和应用程序之间的连接物。

从功能观点看，服务总线被用来虚拟化不同“端点”之间的传输、发现、以及同步。值得注意的是，在至少一些实施例中，服务总线还在各端点处提供转换、过滤、组装和分解、以及协议/运输桥接。

各端点可包括在所描述的体系结构上构建的或利用该所描述的体系结构的应用程序，各端点的示例在以下提供。服务总线在分层数据模型上构建，提供基于名称的和基于谓词的查找和发现功能，以及以下描述的所谓的基于声明(claims-based)的安全性。在该示例中，通过分层的和可扩展的元数据栈来对端点特征(即发生监听的位置的特征)进行建模。服务总线利用或以其他方式可以提供各种可插入实体以实现其任务。例如，可以使用可插入运输来独立于端点语义来虚拟化消息传输。可以使用可插入编码器来独立于本地数据模型来虚拟化消息表示。此外，可以使用可插入适配器将来自端点集合的元数据和消息桥接到总线上。

在实践中，各应用程序利用服务总线来与服务或其他应用程序通信。对于服务和应用程序，考虑以下类比。与对象是本地应用程序的组件的方式相同，服务是合成应用程序的组件。在编写面向对象的应用程序时，该整个应用程序是一个对象并且随后只按照其他对象来编写该对象。正是如此，在编写面向服务的应用程序时，该应用程序可以是服务，并且随后根据其他服务来编写这些服务。最后，这些服务具有本地实现，并且它们是用对象编写的。在一些实施例中，在与另一应用程序或服务进行通信之前，该应用程序可以搜索并查找期望与其进行通信的特定实体。为此，服务总线提供使得能够(经由例如网络地址)发现该应用程序期望与其进行通信的应用程序或服务的搜索和发现组件。作为补充或替换，可以对通信模式进行建模，并且可以在某一模型中标识期望与其进行通信的实体。另外，服务总线包括同步功能，该同步功能操作来确保通过服务总线通信的各实体之间的数据是同步的。即，在一些实施例中，服务总线可以提供基于消息的通信模式和基于数据的通信模式两者。基于消息的通信模式可以例如指定A将消息发送到B，或A将消息多播到B1、B2、B3、B4等。另一方面，基于数据的通信模式可以指定如果A改变了数据则触发对该数据的改变感兴趣的各方。然后，任何感兴趣的一方可以在任何时候读或修改该数据。用于传递该信息或数据的协议是可配置和可扩展的。

在一个或多个实施例中，服务总线还可包括确保应用程序、资源等被一致地命名的联合命名组件。消息通信适配器和框架处理来自不同源的数据可以是信息的同一逻辑片段的概念。然而，该数据可能需要被转换以使服务总线上的其他组件可以识别它。因此，消息通信适配器和框架处理数据转换以确保跨平台的数据一致性和兼容性。例如，在至少一些实施例中，应用程序可以创建该应用程序所使用的一组名称。随后将这些名称与元数据相关联并且应用程序可以通过对元数据进行查询来搜索名称。应用程序可以直接向名称发送消息并且名字空间可受基于声明的机制的保护。服务总线抽象发送者和接收者的概念。接收者因而可操作数据而不关心该数据源于何处。在服务总线的多播版本中，发送者可以向一名称进行发送并且接收者可以监听一名称。因此，在至少一些实施例中，发送者不知道有“0”个还是“N”个人在监听，且接收者不知道谁发送了消息。

此外，在至少一些实施例中，服务总线端点可以支持用于将消息从发送者格式转换成应用程序在端点处所期望的格式的各种特征。这些特征可包括，作为示例而非限制，原始转换、过滤、聚集和解聚(通常称为“成批处理”，例如从单个消息拉出许多消息，或将许多消息构建成单个消息)、以及协议桥接(使得到达端点处的消息在服务总线的不同实例上再发送)。

服务总线还包括关于对利用该服务总线的不同实体之间的通信进行保护的消息通信和信道安全功能。例如，可以保护消息交换和对服务总线资源(例如配置、名字空间)的访问。对特征的保护可包括，作为示例而非限制，认证(即他们是他们所说的人吗？)和授权(即允许他们做他们正在请求做的吗？)。另外，安全功能还提供对各单独的消息和/或消息部分进行加密和其他数字权限管理(DRM)。

仅作为根据一个或多个实施例的服务总线的一个示例，考虑图2。在这里，在200概括示出示例服务总线组件。在该示例中，服务总线组件200包括编码器层202、信道层204、以及提供以上和以下所描述的功能各种其他更高层组件。具体地，在该示例中，服务总线组件200包括发现组件206、联合名字空间组件208、联合身份组件210、以及中继组件212。在中继组件被集成到服务总线中时，于是服务总线参与由防火墙分开的或因其他原因彼此不可寻址的各端点之间的通信成为可能。如本领域技术人员可明白的，中继功能可以使用两端点都可见的高级连网特征和中间组件的组合来实现以达到该目的。

在该示例中，编码器和信道层202、204提供允许点对点通信的功能。为此，编码器层202支持例如SOAP、XBIN、POX/RSS等多个不同的编码标准以及字符集。信道层204包括便于点对点通信的不同组件。作为示例而非限制，这些组件包括监听器组件、运输组件、适配器组件、以及特征组件。

在一个或多个实施例中，监听器组件负责监视通信系统并当消息在系统上可用时激发事件。监听器组件被用来触发诸如在主机系统中的激活等事情。

运输组件用于在一个端点与另一个端点之间移动消息。根据定义，运输组件使用诸如TCP或HTTP等原始运输系统。运输组件可以直接与对应的监听器组件相链接。例如，监听器组件可以激发“连接可用”事件，并且应用程序随后可以为该事件创建运输信道。该应用程序随后可以读该连接上的新消息，该新消息的存在是由监听器组件来用信号通知的。

对其用户而言，适配器组件可显得像运输组件。适配器组件将消息的源或宿进行包装并使其看起来像运输组件。在至少一些实施例中，可以存在不同类型的适配器组件。例如，行业(LOB)适配器组件将诸如SAP或Peoplesoft等行业系统进行包装。消息通信适配器组件将诸如DCOM、MSMQ、MQ或TibCo等消息通信基础结构或中介进行包装。

特征组件是实现并非编码器或运输的端点处的特征的组件。这些组件包括诸如WS-安全或WS-RM等协议组件、诸如在BizTalk流水线中找到的转换和过滤组件、以及协议桥接组件。

如本领域技术人员将明白的，在一个或多个实施例中，各个适配器可以被编写成运输信道，以使接收或获得消息的同一软件体系结构也可用来将应用程序连接到其他应用程序、消息通信基础结构等。

编码器和信道层202、204可共同被认为是以被发送或接收到平台中的消息的形式发送、接收、以及处理数据的消息总线。该消息总线可以处理消息，对信息集(infoset)或二进制表示等各种形式的消息执行转换，和/或以其他方式使得消息内容对该平台的其他组件可用。

除消息处理和用作较低层的点对点运输服务之外，服务总线组件200还包括更高层组件，如所示的发现组件206、联合名字空间组件208、联合身份组件210、以及中继组件212。

在所示出并描述的实施例中，发现组件206包括使得各单独的查询能够进入服务总线并且返回与该各单独的查询相匹配的结果的功能。例如，应用程序可以发出寻找打印机、寻找处理订购单的服务等的查询。发现组件使得这些查询和相关联的结果能够被返回给查询方。因此，发现组件206支持连接的应用程序中的各模块之间的间接性。例如，在先前讨论中，讨论了命名的概念。在至少一些实施例中，在此考虑两种密切相关的名称。首先，端点可具有名称。因此，可以向服务总线呈现期望与其进行通信的名称。希望与其他实体进行通信的实体使用相关联的名称而非特定地址。其次，服务总线基础结构在其内部具有名称，例如比任何特定端点更持久的资源的名称。这些名称可以是，作为示例而非限制，队列的名称(是具有单个读取者以及单个写入者的名称)、和/或它们可以是主题的名称(是具有多个读取者和/或多个写入者的名称)。这些名称可以与“元数据”相关联，元数据意味着描述被命名的事物的结构化数据。发现组件所实现的发现涉及直接通过名称(如果知道)或间接通过查询元数据(例如，如果你知道你需要无论谁来“处理订购单”)来在服务总线中查找名称的业务。

在处理将具有其自己的装饰名称的基础结构进行包装的适配器的情况下，这可以由消息通信基础结构来实现。在使用轻量运输(HTTP)的服务希望向服务总线注册名称的情况下，其还可由发现服务器来实现。图3概括地在300示出根据一个或多个实施例的、联合名字空间组件可在其中操作的环境。在此，联合名字空间组件包括两层——会合层302和名字空间层304。这些层被示为在逻辑上介于信道层306(其对应于图2的消息总线的信道层204并且其用于点对点通信)与构建在名字空间层304之上的多个特征之间。这些附加特征逻辑地表示在308处，并且包括作为示例而非限制，发现服务、通知服务、目录服务、以及消息服务器服务。所有这些服务都可以利用名字空间层304来实质上“插入”到该平台，并使用名字空间功能来提供丰富的功能套件。

在所示出并描述的实施例中，会合层302实现广域邻近性知晓路由。在所示出并描述的实施例中，会合层302提供联合地址空间。机器或设备可以加入某一地址空间而不管该机器或设备实际上是否对该地址空间中的其他机器或设备“可见”。例如，机器或设备可能由防火墙分开，可能位于不可被公共寻址的企业子网中等等。机器或设备可以通过地址向该联合地址空间上的特定机器或设备进行发送，并且它们可以多播到该地址空间中的所有机器或设备。所以，在一些情况下，提供了TCP子网的特征，除了它们可被动态建立和拆卸并且不必位于一处之外。

名字空间层304在逻辑上位于会合层302之上，并且提供对该联合地址空间中的特定地址或地址编组的名称的支持。多个服务可以监听同一名称，并且名称可以与元数据相关联。可以基于元数据来搜索名称。在使用该联合名字空间时，名称给予用户某一级别的间接性。可以动态地并在每应用程序的基础上创建和销毁名称。

概括地在308示出的附加特征构成该基础结构或其上所构建的服务的用途。例如，“发现”有时可指的是检查地址空间上的名称以查找与某些种类的元数据相关联的名称的能力。“发现”还可指的是该基础结构上的跟踪元数据/地址关联并通过诸如UDDI、WS-发现等标准发现协议来提供该信息的服务。“通知”指的是在向其发送通知的名称处注册服务的能力。“目录”指的是提供对一组储存库的管理服务(例如访问控制、复制控制等)的应用程序。“消息服务器”指的是在该组件内/上生存的、向该组件的用户提供可靠性和/或持久性的服务。

在一个或多个实施例中，联合身份组件210(图2)向该平台提供安全体系结构和范例。作为安全体系结构的一个示例，考虑图4。在此，示例安全体系结构或系统概括地在400示出。在此，系统400包括管理令牌的一个或多个服务器技术服务组件402，策略管理器404，cardspace(卡空间)系统406，卡空间代理408，安全令牌管理器410、418，客户机412，服务414，以及服务授权管理器416。

在操作中并且根据一个或多个实施例，安全体系结构400按以下方式工作。在消息通信栈中，在客户机402希望使用服务414时，客户机412通过利用诸如密钥等声明(claim)来这样做。在基本的水平上，声明可被认为是构成某一事实的断言的数据。声明的完整性和保密性通过安全技术来保护。因此，在该示例中，客户机412与安全令牌管理器410进行通信以查明是否存在与服务414相关联的、可用来利用服务414的声明或密钥。与服务414相关联的策略标识访问服务414所需的声明，或可以使用安全协议来询问服务414需要什么声明。客户机412将其所拥有的声明和其所需的关于该声明的信息传递给其安全令牌管理器410。安全令牌管理器咨询各声明策略存储(如cardspace系统600和/或策略管理器404)以查明其可向客户机412提供那些声明以供在其通信中使用。此时，客户机412与服务414通信，这采用客户机412所提供的声明。服务414与服务授权管理器416经历类似的声明解决过程。再一次，客户机412所提供的声明集合可在服务器侧用该服务器的策略存储中的与该客户机的声明相关联的声明来扩充。最后，该过程完成并且计算最终客户机声明集合。如果该声明集合包括与服务414通信所需的声明，则准予访问。

在至少一些实施例中，可以发生另一级别的递归，其中服务414可以指向客户机可用来获取声明的中间声明服务器。该中间声明服务器可以重定向到又一声明服务器，以此类推。最后，在没有要采取的更多步骤或取得了所需声明时递归停止。

因此，在某种程度上，服务侧的机制与客户机侧的机制相同。即，服务414以声明开始，将它们呈现给策略存储(例如策略管理器404)，并扩充声明。该策略存储可以重定向到另一策略存储，以此类推。

事务服务组件

事务服务组件114(图1)支持针对分布式应用程序中的各模块的一个或多个中的预期和非预期状态来协调这些模块的响应。可能遇到的一个基本模式如下。一组资源管理器决定通过事务来进行协调。这些资源管理器将它们的状态发送到将这些状态聚集成事务结果的事务管理器，并且该结果被发送回资源管理器。在更长运行的有状态业务过程或面向服务的应用程序的上下文中，该模式可如下一般化。来自该分布式应用程序模型的信息可被用来标识事务所涉及的该组资源管理器。有状态的应用程序模块需要起逻辑资源管理器的作用。资源管理器与事务之间的协议必须是丰富的并且是应用程序特定的，并且将本地状态聚集成事务状态需要是通用的并且是策略驱动的。

仅作为事务服务过程的一个示例，结合图5考虑以下内容。在此，事务服务环境概括地在500示出。在该示例中，环境500包括编程模型502、事务栈504、以及资源506。这些中的每一个又具有单独的组成部分或过程。

具体而言，编程模型可包括受管代码508和本机代码510。如图所示，事务栈504可包括系统事务API 512、分布式事务协调器(DTC)514、以及与内核模式KTM组件518进行通信的KTMRM组件516。资源506可包括多个不同类型的资源，如数据库资源520、MDAC资源522、本地和远程分布式事务协调器524、HIS资源526、与TM/RM的互操作性528、远程TM 530、TxF 532、以及TxR 534。

在操作中，在编程模型505希望与其他软件进行协调时，其利用系统事务API 512，系统事务API 512是可用于与该系统进行交互的本地API或框架。在这种情况下，API 512担当分布式事务协调器514的前端。所以，例如，编程模型502使用该API来建立用于协调错误的域。API 512返回该协调域的名称，该名称随后被传递给编程模型502与其进行通信的其他实体。如图所示，这些其他实体随后与分布式事务协调器514进行通信，并且指示它们正在该特定域内进行工作。分布式事务协调器514随后可以与诸如数据库资源520等其他资源进行通信来协调错误。

在所示出并描述的实施例中，DTC 514通过例如创建事务、跟踪作为事务的一部分的所有资源、处理对事务的投票、以及将投票结果通知给资源来对事务进行协调。事务具有DTC 514所创建的“事务ID”。事务ID唯一地标识该各个事务和创建它的事务协调器。

在所示实施例中，示出了具有各种事务管理器或协调器的五种不同的交互模式的示例。在该示例中，KTM 518是用于内核代码的事务管理器并且主要结合文件和注册表来使用。KTM 518可以与DTC 514进行协调，并且通过DTC 514与其他远程事务管理器进行协调(即，本地和远程DTC524、HIS 526、与TM/RM的互操作性528、以及远程TM 530)KTM 518可以允许对文件和注册表设置进行改变。所示示例示出用于与其他事务协调器(即，Ole TX、LU6.2等)进行通信的机制和与其进行通信的事务协调器的类型。事务协调器使用某种主-从策略，创建者是主而其他协调器是从。

数据库520和MDAC 522是DTC 514协调其状态改变的资源的示例。其他远程事务协调器处理其他资源管理器。在要求资源管理器在事务“中”改变状态时，它们必须确保它们将该状态的视图呈现得如同对带来同一事务的每一个资源管理器作出了该改变一样。另外，它们将对该状态的访问锁定到任何其他实体。通过这样做并随后贯彻对该状态的改变，可以维持良好的状态情况。

作为事务的寿命的示例，考虑以下内容。首先，创建事务并且创建者将该事务传递给所涉及的所有资源管理器。每一资源管理器或者履行事务承诺或者进入坏状态。此时，创建该事务的代码宣布该事务完成。资源管理器随后可以立即进行它们的改变。如果出于某种原因资源管理器选择不进行它们的状态改变，则存在故障并且不进行改变。

编程模型502从编程者抽象该过程。编程模型在事务生存期(创建和完成)期间处理与事务管理器的协商并使事务对资源管理器可用。编程模型还知道事务何时结束。如果发生本地错误，则它们将适当的投票发送回事务管理器。

消息通信服务组件

在一个或多个实施例中，消息通信服务组件116(图1)提供更高级的消息代理服务，如持久性和常设查询。消息通信服务组件可被实现成一主存的服务，能以独立模式操作，以其中若干服务可直接通信的“群集”模式操作，或以服务能在客户机、企业服务器、和/或在诸如因特网等网络所主控的服务器上运行的“分布式”模式操作。在一个或多个实施例中，消息通信服务组件实现诸如排队和发布/订阅(也被称为“pub/sub”)等常见消息通信模式，以及如基于内容的路由和事件相关等更丰富的特征。在所示出并描述的实施例中，消息通信服务是通过消息总线的信道抽象(以上描述的)来访问的，这在涉及协议和集成的范围内提供标准API和灵活性。在以下讨论中，首先结合图6来描述示例消息节点。此后，提供了消息节点可如何连接到一起的示例以示出所描述的体系结构所提供的灵活性和稳健的互连性。

仅作为可被用来实现以上描述的功能的体系结构的一个示例，考虑图6。在此，系统600包括所谓的个体消息节点602。在该示例中，消息节点602包括多个组件或组成部分。具体而言，该节点的第一层包括订阅管理组件604、捕捉组件606、以及传递组件608，其中的每一个都展示一组灵活的应用程序接口(API)以实现其功能。该层主要针对处理进入该节点和从该节点外出的消息。

具体而言，在该示例中，订阅管理组件604表示订阅端点，并且负责管理消息和其他事件的注册。例如，如图所示，消息节点可以注册来自一个或多个不同的应用程序的消息。捕捉组件606表示负责接收给予该节点的消息的捕捉端点。传递组件608表示负责发送或以其他方式从该消息节点传递消息的传递端点。

该节点的第二层包括负责对消息和事件进行排队并将这些消息和事件路由到正确的实体的排队和路由层610。发布/订阅也可在该层发生。此外，在至少一些实施例中，诸如过滤和转换等功能也可在该层实现。过滤涉及将消息与常设查询进行比较，并且只在它们满足该查询时才通过传递组件传递它们。转换涉及注册在通过传递模块发送传入消息之前对其进行转换的映射。转换可以操作单个消息(即将所有串转换成某一格式)，或操作消息群(例如，某人可能跨数百消息的群来请求消息中的整数的平均值)。

此外，在一个或多个实施例中，可以按照信道地址来对各个队列和发布-订阅主题进行命名。信道栈中的过滤器和转换信道可以将过滤器和转换附连到本地栈中的消息属性，其随后可通过消息服务运输信道传递到消息服务节点。在传递消息时，在应用了信道栈的过滤器和/或转换的情况下，运输在该消息中标记一标志。在运输不操作的情况下，过滤器和/或转换信道只需要作用于外出消息。

节点602第三层或底层包括可用来与其他节点进行连接的各组件。例如，传输组件612可被用来以点对点的方式与其他节点进行连接。作为补充或替换，传输组件612可被用来连接到相对于服务总线而运行的会合网络。此外，传输组件612是可扩展的，因为它可被用来以各种其他方式连接。

在一个或多个实施例中，第三层包括可实现基于内容的路由的基于内容的路由模块614。如本领域技术人员将明白的，基于内容的路由涉及基于内容将该特定内容发送到其他节点的概念。这可以允许该节点中的大型分布式排队系统的流水线处理。例如，如果消息被发送到发布/订阅系统并且该消息涉及纽约州的天气，则加利福尼亚州的某人不可能关心该消息。因此，基于内容的路由随后可只将该消息发送到纽约州的计算设备。

在一个或多个实施例中，第三层包括事件相关服务组件616。组件616可允许丰富的服务集合，如随时间保留消息、操作这些消息、并随后响应于某一事件来发出该消息。例如，在一个或多个实施例中，每一消息服务节点具有可被编程成在消息流在进行中时以特定方式操作该消息流的事件相关服务组件。对于“流”部分，考虑以下内容。在一个或多个实施例中，事件相关服务组件与系统中的队列进行交互，并且因此可以操作历史系列消息以及各个消息。事件相关服务组件可应用于消息或消息流的功能包括在以上较不特殊的情况下提到的转换和过滤。

此外，在一个或多个实施例中，事件相关服务组件可取得相对直接的抽象请求(例如，“测量消息调用的平均响应时间”)，并将其转换成在一组分布式的事件相关服务模块上运行的操作。在某种意义上，这推动了计算“上行流”。例如，如果调用发生在大量机器上，则每一机器上的事件相关服务节点可以计算其自己机器上的调用的平均值，并随后在下行流上发送包含该平均值和该节点处的调用的计数的周期性消息。与涉及对每一回调下行流发送“进入/外出”消息的分布式较差的替换方案相比，这可以显著地降低网络负载。

描述了消息通信节点的概念后，现在结合图7考虑消息通信节点可连接到一起的各种方式。在此，连接环境700概括地在700示出。根据一个或多个实施例环境700包括多个不同的连接范例。在此，存在多个主机(主机1-8)，其中的各个主机都运行消息服务节点602(图6)。

在该示例中，在该附图的右上方开始，主机3正在运行消息节点，并且因为与该节点相关联的接口是分布式接口，所以主机4可以通过简单地向主机3上的节点直接发送消息来使用该消息节点系统。

主机2和3示出两个节点可以使用传输组件612(图6)直接连接。因此，可将可在主机2上捕捉的消息插入到该系统。如果该消息满足主机3上的订阅，则可将该消息简单地发送到主机3。

诸如SOAP场景等其中不同的人可进行协作的宽泛协作场景可由诸如在主机1、2、5和8之间示出的连接等连接来支持。该连接构成会合环并且是一个示例，在该示例中消息节点被插入到服务总线并且构建在服务总线之上。一旦被插入，在这些节点之一捕捉到消息时，该节点可以将该消息多播到参与该环的所有其他节点。因此，许多不同的服务可被连接并接收广播消息。该特定安排可将消息非常快速地路由到环的成员，其中成员节点能以高效且流水线化的方式接收、处理、并且在适当时将这些消息路由到其他成员。

因此，在以上示例中，主机3和2之间的关系示出可如何在小尺度上利用直接连接。另一方面，该环示出在更宽泛的场景中可如何利用消息服务节点。

主机5、7和8示出其他场景。例如，主机5示出可如何利用专有协议来与其他发布/订阅系统(在此是BizTalk服务器)进行通信。主机7示出可如何使用诸如WS-^*互操作性协议等其他可互操作的协议来在消息服务节点与恰好理解该可互操作的协议的某一其他外来队列服务之间进行通信，该服务随后可将消息以其喜欢的任何形式传递给其自己的应用程序。

主机8示出即使消息服务节点具有其自己的捕捉和订阅过程，该节点也可如何连接以用通常标准的方式来进行通信，如通过RSS馈源或通过REST连接。

现在已经讨论了连接服务组件102(图1)，现在考虑进程服务组件104(图1)。

进程服务组件

在一个或多个实施例中，进程服务组件104担当包括被用于运行诸如工作流或规则集等持久有状态操作的特征的主机。进程服务组件包括可运行工作流或规则集的工作流/规则运行时118。因此，进程服务组件提供集成框架和服务的集合，该集成框架和服务的集合提供运行程序的运行时环境。作为示例而非限制，该运行时环境包括激活、调度、错误处理、状态管理、与该环境的接口等。在一个或多个实施例中，所有程序都根据该定义在运行时环境中运行。存在其中可以运行例如Win32应用程序的非受管运行时环境。另外，存在其中可以运行公共语言运行时(CLR)应用程序的受管运行时环境。在当前示例中，该运行时环境可运行代码服务，但被定制成运行模型(例如，工作流、规则集等)。

作为进程服务组件的示例，考虑图8，其概括地在800示出根据一个或多个实施例进程服务组件可操作的环境。在该示例中，环境800包括进程服务器组件802、服务总线804(以上描述的)、储存库806(以下描述的)、以及实例数据存储808。

在该示例中，进程服务器组件802被用来运行应用程序、本机代码、或者规则或工作流。即，在一个或多个实施例中，进程服务器组件可以运行声明性代码(例如图形工作流等)以及命令性代码(例如C#)。进程服务器组件可以运行生存期等于单个调用的“无状态”进程，并且可以运行持久的进程，即跨可能由长时间段分开的多个调用而存在的进程。

进程服务器组件的组成部分包括(作为示例而非限制)激活服务810，实例/会话相关组件812，包括公共语言运行时组件814、规则引擎816(运行视状态改变而定的活动)、工作流引擎818(允许指定要由规则引擎运行的单个活动或活动图)、以及活动库820(构成预定义或预配置的活动)的运行时环境。进程服务器还包括域特定语言程序822。

在操作中，在该示例中，达到以在进程服务器组件处触发工作的所有消息是从消息或服务总线804离开的。实例/会话相关组件812检查传入消息，并决定它们是否可被路由到运行时的现有实例和用户应用程序模块。这些实例可能在存储器中，或者它们可能在盘上。激活服务810还可以在传入消息流需要时创建运行时的新实例和用户程序(即，在现有实例已经不合适的情况形创建新实例)。进程服务器具有适用于声明性程序(工作流、规则)、受管命令性程序(C#、VB.NET)、以及非受管命令性程序(C++、C)的运行时。另外，进程服务器具有实际程序(其可以是或不是DSL)。

在消息从服务总线到达时，实例/会话相关组件812决定正在运行的运行时实例是否是可接受的或新运行时实例是否是适当的。激活服务的责任是在适当时提供可用来运行向其发送该消息的进程的新环境。激活服务与所有应用程序、模型、以及规则和工作流驻留于其上的储存库806通信链接。在消息到达且激活服务知道其需要启动新应用程序时，该应用程序被从储存库806拉出。

在一个或多个实施例中，各进程可以长期运行并且因为这一点，在消息到达时，实例/会话相关组件812处理传入消息并尝试将其与可能正在运行的进程相关联。在找到该适当的进程时，组件812从实例数据存储808中检索出该进程的当前状态，加载该进程，并随后运行工作流的下一部分。

可使用丰富的资源集合来构建各进程。具体而言，可以使用公共语言运行时(CLR)组件814来构建各进程。规则引擎816提供工作流基础，并且可被扩展以只使用规则来运行进程。因此，可以只使用规则来构建各程序。可以在规则上构建工作流引擎818，并且可以在工作流引擎818上构建足以使开发者能够在不编写任何代码的情况下编写程序的活动库，从而在至少某些情况下提供包括打包的组件和模型的程序。该程序是可执行模型。该模型可以用图形表示、以文本语言表示、或表示在储存库中。在所示出并描述的实施例中，CLR是构成.NET核心的公共语言运行时。CLR是一起能执行逻辑操作码的虚拟机和运行时，其中C#和VB.NET代码被编译成所述逻辑操作码。规则是条件/活动对。条件被连接到数据，数据有时可以是固定数据并且有时可以是呈现给规则的数据。活动在规则与其数据相匹配时激发。

CLR及该特定系统之间的关系在考虑什么构成了活动时可以得到最好的理解。具体而言，活动是相对公知实例实现的代码的一部分(即在满足规则时调用的代码)或如同是代码集合一样进行动作的规则/活动图。活动库820在某种意义上与.NET所伴随的基类库或与任何其他软件环境所伴随的库(即，不必独立地创作的通用库)等效。

域特定语言(DSL)程序与针对特定的任务子集定义和利用的语言有关。因此，可以生成组成使得便于构建特定种类的进程的规则或活动子集的DSL程序。实际上，随后，DSL是作为使得易于构建特定种类的应用程序的更一般的系统的约束或子集的特定预打包的活动和规则。

讨论了进程服务器组件的一般概念，现在结合图9考虑可如何使用进程服务器组件。图9示出可如何将图8的系统扩大到多个不同的机器。图9的系统所解决的问题之一涉及在其中各实例可被再循环或由于机器故障而丢失的系统的上下文中如何使消息到达当前恰巧正在管理实例的位置。

在此，示例环境概括地在900示出。在操作中，消息通过与路由器904相关联的所谓端口902离开服务总线。因此，消息流通过该端口进入路由器。这些端口是与服务总线相关联的端点并且对应于图2中描述的信道栈。在该实施例中，路由器具有非常类似于图8中的实例管理器的分布式世界中的功能。该路由器计算出实例是否已经处于进程服务器之一中或其是否是新实例。如果消息是针对现有实例的，则路由器将该消息发送到持有该实例的进程服务器。如果该消息是针对新实例的(或针对当前未固定到特定进程服务器的实例)，则路由器选择进程服务器并随后转发它。进程服务器的实例部分映射到路由器。

在至少一些实施例中，协议可用来将消息与长期运行进程的实例相关联。在所示出并描述的实施例中，存在这一点可以有效的几种方式。例如，消息可包含特定实例协议的首部。这使得易于处理实例-位置逻辑。在另一方面，如果消息不包含实例协议首部，则映射功能基于消息中的唯一地标识该实例的信息(例如，订购单)来创建将处于该协议中的信息。其可以通过利用标识属性906的数据库来这样做。这些属性可以定义如何通过端口中的转换将该消息映射到实例。继续，消息进入端口并随后被发送到路由器904。路由器经由进程服务器数据库908查明哪些进程服务器正在运行。在该示例中，这是用跟踪正在运行的进程服务器的表来完成的。实例映射数据库或存储910跟踪与进程服务器之一相关联的实例。路由器查明要将该消息路由到哪一进程服务器。这经由维护进程实例到进程服务器的映射的实例映射存储910来完成。路由器随后可将该消息路由到正确的进程服务器，该进程服务器又可将该消息路由到正确的实例。对于现有实例，路由器904查明该实例正在哪里运行以便可将该消息发送到正确的进程服务器92、914、和916。如果该实例是新实例或如果该实例当前未被映射到进程服务器，则路由器904从正在运行的进程服务器中选择一进程服务器。作为补充或替换，情况可以是自针对某一实例的消息到达以来过去了很长一段时间(例如3个星期)。在这种情况下，该特定实例可能已被放回实例状态存储918。如果是这种情况，则检索该即时状态并将其拉入到适当的进程服务器的存储器中。

维护标识属性存储906和实例状态存储908之间的链接以使标识属性存储能够具有正在运行的各个的实例的映射。

身份服务组件

在一个或多个实施例中，在该示例中，身份服务组件106(图1)包括目录服务组件120以及访问服务组件122。身份服务组件提供可用来执行相对复杂的身份操纵的服务。

仅作为目录服务组件的一个示例，考虑图10，其概括地在1000示出示例系统。在该示例中，目录服务组件包括可被认为是访问层1002和目录栈1004的部分。访问层1002包括一个或多个组件，可通过这些组件展示目录栈。在所示出并描述的实施例中，这些组件包括API组件1006、消息通信API(MAPI)组件1008、KDC组件1010、和/或服务总线组件1012。

API组件1006可被认为是可任选地用来访问目录栈的传统API或标准API。在此，API组件的API更具体地链接到目录栈中可用的数据。

MAPI组件1008指的是MAPI子系统、客户机应用程序编写者、以及服务提供程序编写者所使用的编程接口。主编程接口是被称为MAPI编程接口的基于对象的接口。如本领域技术人员将明白的，基于OLE组件对象模型，MAPI编程接口由MAPI子系统使用并由使用C或C++编写的基于消息通信的客户机应用程序和服务提供程序来使用。

KDC组件1010是包含在目录中的身份与可针对特定个人发出的安全密钥之间进行映射的策略的密钥分发中心。在某一个人接近目录时，通常向他们要求密钥。针对该个人来运行策略并且取决于该策略可返回或不返回密钥。

服务总线组件1012可被用来访问目录栈1004。在此，服务总线组件包括可允许与各种各样的实体进行通信的更一般化的API集合。一般化API提供针对目录栈中的数据或可通过目录栈访问的数据的创建、读取、更新、以及删除功能。

在所示出并描述的实施例中，目录栈1004包括多个组件，包括含有复制组件1016的目录服务代理1014、数据访问组件1018、以及核心安全模块1020。此外，目录栈还包括储存库1022和存储1024。在该示例中，储存库是以可由本文中所描述的平台利用的形式来存储数据的实体。因此，其可被认为是担当“新格式”的数据的存储。类似地，存储1024担当可被认为是传统数据或以传统格式存在的数据等数据的存储。在该特定示例中，核心安全模块1020向存储1024提供安全层以使其向数据访问组件1018正确地呈现。

目录服务代理1014可被认为是所有不同的访问API用来与数据库系统进行接口的通用层。该软件层了解其他数据存储在该系统中的位置。如此，其将这一知识用于数据访问(例如，在API试图获取在本地存储中不可获得的某些信息的情况下)，并且其还可以将该知识用于复制(例如，将数据置于网络中的关键位置以使其可从需要它的地方高效地被访问)。该分布式访问工作在各目录服务代理(例如附图中的“其他目录服务代理”实体)之间发生。因为该信息恰好在该层可用，所以域信息也从目录服务代理提供给DNS系统以跟踪机器名、IP地址和子网等。

在该示例中，数据访问组件1018被用来不仅使得API组件1006(即，传统API)能够访问最初未被构造来访问的数据，还允许服务总线组件1012访问传统数据。

通过访问服务组件122(图1)，访问服务提供对分布式应用程序内的身份的管理和使用的丰富支持。在所示出并描述的实施例中，该方法以声明为中心：关于实体的声明、关于资源的声明、关于实体对资源所采取的动作的声明、以及关于可发生这些动作的环境的声明。规则或策略可通过这些声明来表达。随后可以在各种上下文中评估这些规则：作为对资源进行授权检查的一种方式(允许实体在给定环境中查看资源？)，或更一般地，作为业务规则(实体的管理器被授权给定额度的订货单？)。这些规则可以完全在本地处理，或它们可导致传递到某联合处理授权机构以供进一步分析的部分结果。

在一个或多个实施例中，访问服务组件构成图4系统的扩展，其使用进程服务器的能力来用于以上和以下所描述的目的。为此，以下讨论描述图4的一般体系结构的特定应用。

作为示例访问服务体系结构，考虑图11，其概括地在1100示出一系统。在此，系统1100包括储存库1102、服务总线1104、以及逻辑上介于储存库和服务总线之间的服务器技术服务1106。在此，服务1106包括访问策略组件1108和进程服务器1110。进程服务器1110包括工作流组件1112和规则组件1114。在此，访问策略组件1118包含用于访问资源的相关策略。工作流组件1112和规则组件1114定义或以其他方式描述访问关系。这些组件在服务器中运行以实现提供对资源的访问的服务器技术服务。具体而言，在一个或多个实施例中，该访问服务体系结构所实现的访问服务包括运行特定程序的进程服务器，该程序具有适当的接口以插入到图4的体系结构。

生存期服务组件

在一个或多个实施例中，生存期服务组件108(图1)包括储存库组件124、集成组件126、执行组件128、以及分析组件130。在所示出并描述的实施例中，这些组件共同工作来提供其中可以运行分布式异类应用程序的环境。

首先结合图12考虑集成组件。在此，系统1200包括逻辑上介于储存库1204、元空间(metaverse)组件1206、以及多个数据源1208之间的集成服务器1202形式的集成组件。集成组件的努力之一是能够协调可驻留在企业中的不同存储内的数据。为此，并且如以下描述的，集成组件能够“挂钩”到可跨企业来使用的所有不同数据存储。另外，在集成组件中运行的特定类型的声明性程序的目标是实现企业用来处理潜在冲突的策略。另外，集成组件的另一努力是构建应用程序对驻留在诸如不同的数据库、不同的LOB应用程序等不同位置的数据的统一或单个视图。因此，在该努力中，应用程序定义并建立数据的工作视图，标识该应用程序的视图与底层数据存储之间的映射，并随后建立用于对数据存储中的改变与应用程序的视图中的改变进行协调的策略。这些策略通常驻留在应用程序逻辑中。

为此，在至少一些实施例中，将要描述的集成服务器构成图8中描绘的进程服务器的修改形式。

在该示例中，集成服务器1202包括同步策略组件1210、以及包含工作流组件1214和规则组件1216的进程服务器1212。

在操作中，要由某一合成应用程序利用的数据可驻留在多个位置，这些位置中的一些由数据源1208示出。然而，通常，程序期望在一个位置中查找数据，如在本地计算设备上。在所示出并描述的实施例中，数据可以从多个不同的位置(即数据源1208)被访问，通过同步策略组件1210被处理到被称为元空间(metaverse)1206的中央位置。元空间构成应用程序期望看到的数据视图，并且同步策略组件1210负责处理来自各个源的数据并将数据以该应用程序期望看到的形式放置。一旦置于适当的形式，各组成部分驻留在储存库1204中的该应用程序可操作元空间1206中的数据。

一旦该应用程序操作了元空间中的数据，则其可以转储清除回其适当的数据源。同步策略组件1210与其进程服务器1212一起和相关联的工作流及规则组件1214、1216一起工作来确保该数据是同步的并且保持同步。一旦数据被同步，则其可被推送回其适当的数据源。对于元空间组件1206，考虑以下内容。在以上协调场景中(即所提到的第一努力)，元空间构成作为被协调的所有系统中的所有数据的组合的数据视图。协调策略通常按照元空间模式和原始源来处理。在统一视图场景中(即以上提到的第二努力)，元空间构成应用程序关心的视图，即所有周围存储中的数据的、与该特定应用程序相关的特定子集。

在一个或多个实施例中，被执行的该程序的部分可包括由诸如进程服务器等计算设备执行的各部分和由个人使用所谓的人就绪(people-ready)进程执行的各部分。人就绪进程的示例可被认为是业务通常可实现的进程。在该场景中，人就绪进程的一部分可以是通过用户界面进程呈现允许个人执行某一些工作的特定用户界面。例如，如果某一进程涉及三个步骤A→B→C，则在完全自动化进程中，A和B和C将由代码、规则、或工作流来指定。在人就绪进程中，可能B向某人发送邮件以要求报告的副本，并且C将任务插入到

以要求管理器读该报告并批准它。图13概括地在1300示出示例应用程序生存期服务环境。在此，环境1300包括执行组件1302、储存库1304、分析组件1306、以及应用程序1308和馈送到储存库的各种创作或开发工具1310。

在此，代码模块可以使用各种开发工具1310来编写，可被存储在源控制系统中以供测试，并最终发布到储存库1304中。源控制系统可以出于以下原因来被使用：这些系统通常被用来例如跟踪历史和修订以及流入构建并测试系统的进程。开发工具可以提供个人可创作代码模块的多个不同的粒度级别。

在要部署应用程序时，执行组件1302从储存库1304访问该应用程序并使其对执行就绪。为此，执行组件作出诸如将在其上运行应用程序的机器、要使用的运输、安全凭证等的决定。就此，该执行体实现了被称为进程细化的事物，在该示例中这由工作流来驱动。在该执行体完成其工作并且已经对所有部署参数做出了决定时，该应用程序可以运行。为此，执行组件1302使连接的应用程序经历各种状态改变。这些状态改变可包括，作为示例而非限制，从“构建”状态移动到“细化”状态、从“细化”状态移动到“部署”状态、和/或从“部署”状态移动到“运行”状态。这在某种程度上对应用程序可经历的状态集合进行了一般化。在所示出并描述的实施例中，各单独的状态改变被实现成进行造成状态改变的工作的工作流。

在操作中，该执行体可以将应用程序的各组件分发到不同的机器上，并随后将它们当作一个逻辑单元对待。在一个或多个实施例中，执行组件可在不同的环境(IIS、WAS、BizTalk、SQL)中运行各组件。这些环境可以在不同的机器上，但它们还可在不同的操作系统上。与更多地面向编程协调基础结构的其他技术相比，执行组件对基础结构是不可知的。

因此，储存库1304将全异的信息源，具体而言是储存库中的各模型(包括集中式、分布式模型)聚集在一起。储存库具有使其插入其他数据源来使其可以向基础结构并向应用程序提供统一模型视图的适配器。

从执行组件的观点看，储存库提供应用程序的统一视图。执行组件的任务是通过对应用程序进行细化、通过部署应用程序、通过打开应用程序等来使应用程序准备好运行。

执行组件所涉及的差异性是应用程序需要在其中或其上运行的主存的或其他基础结构子系统的差异性。为此，该执行体可被认为是联合该差异性，在所有这些不同种类的软件基础结构之上提供单个逻辑主机的视图。

为避免将特定种类的基础结构的知识直接构建到执行组件中，该执行组件具有被称为“驱动程序”的模型，用来处理底层基础结构。执行组件通过为该基础结构的每一个位生成指令并随后将这些指令发送到对应的驱动程序来操作该分布式模型。各单独的驱动程序实现相同的接口，使得执行组件可以通过对和与驱动程序的接口进行通信来抽象地处理底层基础结构。

可以将这一点认为是执行组件的“命令-和-控制”部分。如果希望在分布式模型中执行任务，则通知执行组件。执行组件随后分析适当的模型并为每一主机和基础结构模块创建命令。其随后经由驱动程序将这些命令发送到该基础结构。所以该执行体允许人们认为他们正在向整个模型给出命令，并隐藏运行时环境中的所有差异性。

现在请注意执行组件1302、应用程序1308、分析组件1306、以及储存库1304之间的循环。该循环的一个具体原因是存在定义应用程序如何和何时回答查询的服务级协定的概念。例如，可以查询分析组件1306以查明应用程序1308回答查询或执行某一其他任务有多快。如果应用程序的性能不合需要或因某种其他原因不能满足某些性能度量，则随后可以在储存库中调谐该模型以使该应用程序可满足性能度量。执行组件1302随后可以更新正在运行的模型以使该应用程序更高效。因此，动态反馈循环可以实现面向目标的行为并可以确保该应用程序最终用户接收到良好的性能。但更一般地，除支持联合命令-和-控制之外，执行组件1302还支持关于该应用程序的联合智能-收集。为收集关于应用程序的智能，“观察模型”可作为分布式应用程序模型的一部分被添加到储存库1304。执行组件分析该观察模型，查明在该应用程序的每一部分应收集什么数据，并将这些请求推送到驱动程序。驱动程序随后执行使用的任何任务来使他们的那一部分系统收集适当的数据。

随着应用程序的运行，其在其各部分中的每一个中发出事件。每一部分所发出的事件通常可以是不同的格式，例如数据库发出一种事件、网页发出第二种事件等等。在应用程序的智能-收集方面，驱动程序的任务是收集这些不同事件，将这些事件转换成通用格式，并将经转换的事件插入到分析组件1306。分析组件1306根据观察模型对事件进行处理。例如，如果被要求报告平均响应时间，则分析组件将使“进入”和“退出”事件变成响应时间事件，并随后对它们进行平均。这些结果最终可通过储存库1304获得。因此，所发生的是与该应用程序相关的事件的集合并且观察模型由执行组件生成。

以上的服务级协定示例构成该系统的某一特定用途。服务级协定被实现为观察模型，用于测量相关数据和查看由分析组件产生的事件流的事件处理程序，并用于在违反协定的情况下采取某一动作。该动作例如可包括人类过程(例如，向某人发送的电子邮件、在门户上产生的警报等)，或该动作可以是自动化过程，如重调谐该应用程序。

图14概括地在1400示出根据一个或多个实施例的示例储存库环境。在此，储存库1304被示为在逻辑上介于开发工具1310与集成服务组件1402之间。该储存库包括关于应用程序及其性能、生存期、要求的信息以及所有其他相关信息。如此，储存库1304可以从概括地在1404指定的各个源接收其数据。例如，可以使用诸如在1406指定的机制等各种不同的机制来描述应用程序数据。作为补充或替换，在1408，如果应用程序使用SQL表或存储的过程，则SQL目录可密切相关。作为补充或替换，在1410，可以使用各种源代码控制系统或在1412的第三方描述来描述应用程序数据。因此，开发工具1310通常具有与储存库的主要关系，并且储存库具有与其他数据存储的主要关系。储存库使用集成服务组件产生跨这些不同数据存储的联合视图。

在一个或多个实施例中，集成服务组件1402可以处理所有这种数据并使其通过储存库1304可见。在实践中，储存库可以被实现成SQL应用程序。因此，被用来访问储存库的API可以是SQL API。作为这可如何全都一起工作的示例，考虑以下内容。假定应用程序具有网页、工作流、以及数据库。用户可能通常使用现有工具来构建网页和将这些人工产物存储在源代码控件中的数据库。用户将使用建模工具来在储存库中构建工作流和分布式应用程序模型。分布式应用程序模型在源代码控件系统中指出网页和工作流。在执行组件读该模型时，储存库1304使其看起来像网页并且数据库描述处于储存库中，而在实际上该描述驻留在其他存储中并且经由集成服务组件1402被桥接到储存库。

图15概括地在1500示出根据一个或多个实施例的示例执行环境。在该示例中，环境1500包括逻辑上介于储存库1504和服务总线1506之间的执行体1502。

在一个或多个实施例中，执行体1502联合诸如共享点、IIS/WAS、BizTalk、以及SQL服务器等主机或容器来提供对分布式应用程序的应用程序范围的(即，整个应用程序)命令、控制、以及监视。执行体1502所执行的功能中作为示例而非限制，将在整个模型范围的命令和控制请求转换成对于该分布式模型的各部分将在其中运行的容器的命令和控制请求。在所示出并描述的实施例中，这一转换由实现可定制业务流程的工作流来驱动。另外，执行体1502将整个模型范围上指定的观察模型转换成各个容器生成特定种类的事件的请求。当在容器中生成这些事件时，执行体将它们转换回标准格式并经由服务总线1506将它们发送到被展示为储存库1504的一部分的高效(performant)存储。执行体1502支持实时地对正在运行的模型的参数的配置中的某一些的改变，以使得可以调节应用程序并可改变观察模型而不重启底层应用程序。通过支持将诸如“部署”和“运行”等动词应用于模型的能力并通过聚集观察到的关于模型的信息，执行体联合现有容器并提供分布式模型在单个系统上运行的体验。

现在更具体地转向图15的图示，储存库1504保持应用程序和作为该应用程序所遵循的规则的策略断言。该储存库还包括与应用程序相关联的所有资源，例如该特定应用程序可以在这些特定八个计算机、四个SQL服务器、以及两个web服务器上运行。这些应用程序、资源、以及其他储存库数据可以由多种不同的方式来访问。例如，访问可通过门户发生、通过管理控制台(MMC)发生、或通过Quadrant(或直接以储存库为目标的某一其他建模工具)发生。因此，执行体是访问来自储存库的应用程序并细化、部署、启动、停止、版本化、以及执行相对于应用程序的其他功能的实体。

在操作中，执行体1502由多个不同的服务组成，其中的每一个都可以运行于不同的机器上。在该特定示例中，所部署的应用程序模型可以是共享点应用程序，如图所示，具有由进程服务器和SQL数据库管理的进程。执行体通常取得应用程序模型并执行某些细化，如查明哪些特定SQL和进程服务器将被使用等。在查明要使用哪些特定服务器或服务后，执行体知道哪些驱动程序要用于部署并随后可部署该模型。执行体的驱动程序管理功能向该执行体提供了用于处理例如共享点SQL、COM+、SQL、Windows外壳等应用程序可以在其中运行的所有不同位置的能力。

因此，应用程序驻留在储存库中并且从可以想到的许多不同组件模块中构建。执行体理解这些模块，获得这些模块或模块的知识，并将模块部署到这些模块要运行的位置。

这些组件模块随后可出于两个不同的目的来使用服务总线1506。第一，这些组件模块可以使用该服务总线彼此通信。另外，这些组件模块可以获取相关事件数据并经由诸如图13中的分析组件等分析组件使用该服务总线来将该事件数据提供回储存库。这使得观察模型能够结合该应用程序来被使用。该观察模型向在主机中运行的应用程序模块提供指令，从而告诉它们应当聚集哪些事件。观察模型还指示分析组件如何对事件进行后处理，以使它们回答观察模型的观察要求。因此，观察模型有选择地收集关于应用程序的、可被用来进行涉及该应用程序的执行的分析的信息。这样的信息可被用来细化该应用程序或在进行中进行改进应用程序的执行的改变。这样的信息对于诸如日志记录、管控、监视等事物一般更有用。

图16概括地在1600示出根据一个或多个实施例的示例环境。在此，在适当时使用与来自图15实施例相同的标号来描绘相同的组件。除包括执行体1502、储存库1504、以及服务总线1506之外，环境1600包括分析组件1602，该分析组件包括可被认为是该系统的分析服务的一部分的事物。

具体而言，在此，分析组件1602被配置成从储存库1504读取事件数据(即，事件实例)并以某种方式操作该事件数据。回想先前产生的并被经由服务总线提供给储存库的事件数据。

在操作中，分析组件1602可以用任何合适的方式来处理事件数据。例如，分析组件可以对事件运行统计分析以回答关于应用程序的性能的问题。另外，用户可以经由提供描述特定应用程序如何操作的用户界面的门户访问分析组件所产生的数据。

另外，分析组件还可被配置成读取密钥性能指示符(KPI)和服务级协定(SLA)，并将这些用于其对应用程序性能的分析中。通过例如重新配置应用程序或其组件之一并重新部署该应用程序，这随后可被用于提高应用程序性能。

工具组件

在一个或多个实施例中，工具组件110(图1)包括各种工具，其示例包括诸如visual studio组件132等基于代码的工具、诸如quadrant组件134等基于模型的工具、以及诸如系统中心组件136等企业管理工具。

在一个或多个实施例中，存在可被利用的多种不同的模型并且每一个都可以是紧密相关的。具体而言，应用程序由模型和代码人工产物来构建，并且在企业管理工具的较大上下文中来管理。诸如Visual Studio等基于代码的工具支持对代码人工产物的创建、测试、以及更新。诸如Quadrant等基于模型的工具支持对模型的创建、测试、以及更新。基于模型的工具知道各模型之间的关系和模型与代码人工产物之间的关系，因为这些关系都在模型中得到描述。

基本上，基于模型的工具提供通用编辑体验，允许通过使得模型的某些特定属性(框-和-线、表单、表等)透明的视图来查看所有模型。用户可以定制该通用编辑体验并存储定制的视图，并随后在将来处理类似数据时回调。开发者可以构建针对特定模型而定制的新编辑器。这些可提供自定义编辑体验，或者这些可提供专用于某些特定模型的特征(例如，能够在工作流编辑器中对工作流进行调试)。

储存库1504包含用于模型的模式(schema)和模型的实例。因为模型模式只是模型，并且因为储存库具有模式，所以各种基于模型的工具可被用来生成新模型以及现有模型的实例。

示例系统

图17示出可以实现上述各实施例的示例计算设备1700。计算设备1700可以是例如任何合适的计算设备，如客户机设备和/或服务器设备。

计算设备1700包括一个或多个处理器或处理单元1702、一个或多个存储器和/或存储组件1704、一个或多个输入/输出(I/O)设备1706、以及允许各组件和设备彼此通信的总线1708。总线1708表示任何若干类型的总线结构中的一个或多个，包括存储器总线或存储器控制器、外围总线、加速图形端口、以及使用各种总线体系结构的任一种的处理器或局部总线。总线1708可包括有线和/或无线总线。

存储器/存储组件1704表示一个或多个计算机存储介质。组件1704可包括易失性介质(如随机存取存储器(RAM))和/或非易失性介质(如只读存储器(ROM)、闪存、光盘、磁盘等等)。组件1704可包括固定介质(例如，RAM、ROM、固定硬盘驱动器等)以及可移动介质(例如闪存驱动器、可移动硬盘驱动器、光盘等等)。

一个或多个输入/输出设备1706允许用户向计算设备1700输入命令和信息，并还允许向用户和/或其他组件或设备呈现信息。输入设备的示例包括键盘、光标控制设备(例如鼠标)、话筒、扫描仪等。输出设备的示例包括显示设备(例如监视器或投影仪)、扬声器、打印机、网卡等。

各种技术在此可以在软件或程序模块的一般上下文中描述。一般而言，软件包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。这些模块和技术的实现可以存储在某种形式的计算机可读介质上或通过某种形式的计算机可读介质传输。计算机可读介质可以是可由计算机访问的任何一个或多个可用介质。作为示例而非限制，计算机可读介质可包括“计算机存储介质”和“通信介质”。

“计算机存储介质”包括以用于存储诸如计算机可读指令、数据结构、程序模块或其它数据等信息的任何方法或技术实现的易失性和非易失性、可移动和不可移动介质。计算机存储介质包括但不限于，RAM、ROM、EEPROM、闪存或其他存储器技术、CD-ROM、数字多功能盘(DVD)或其他光盘存储、盒式磁带、磁带、磁盘存储或其他磁存储设备，或者可用于存储所需信息并可由计算机访问的任何其他介质。

“通信介质”通常用诸如载波或其他传输机制等已调制数据信号来体现计算机可读指令、数据结构、程序模块或其他数据。通信介质还包括任意信息传递介质。术语“已调制数据信号”指的是其一个或多个特征以在信号中编码信息的方式被设定或更改的信号。作为示例而非限制，通信介质包括有线介质，诸如有线网络或直接线连接，以及无线介质，诸如声学、RF、红外线和其他无线介质。以上的任一种的组合也包括在计算机可读介质的范围之内。

结论

各实施例提供一种用于使得能够构建和部署合成的、自主的应用程序和服务的体系结构。另外，提供了一种允许分布式应用程序和服务之间的通信的基础结构。

尽管用结构特征和/或方法动作专用的语言描述了本主题，但可以理解，所附权利要求书中定义的主题不必限于上述具体特征或动作。相反，上述具体特征和动作是作为实现权利要求的示例形式公开的。

Claims

1.一种计算机实现的方法，包括：

提供用于允许合成应用程序和服务彼此通信的连接服务，其中所述连接服务支持针对一个或多个应用程序模块中的预期和非预期状态的响应协调，提供消息代理服务，以及将多个端点上的传输、发现和同步虚拟化，其中所述连接服务支持多个不同的编码标准，便于基于消息的点对点通信，支持查询，确保应用程序被一致地命名，以及为所述合成应用程序提供安全体系结构，其中所述连接服务实现广域邻近性知晓路由并提供联合名字空间；

提供进程服务来为合成应用程序提供运行时，其中所述进程服务接收消息并且作为响应提供能被用来运行一进程的环境，其中已为该进程发送了一消息，以及处理消息且尝试将消息与可能正在运行的进程相关联；

提供执行与合成应用程序相关联的身份操作的身份服务，其中所述身份服务包括访问层和通过所述访问层能访问的目录栈，其中所述访问层包括用于访问所述目录栈中的数据的多种不同类型的API和用于结合合成应用程序来管理和使用身份的访问服务；

提供生存期服务，所述生存期服务提供合成应用程序能运行的环境，其中所述生存期服务维护与合成应用程序相关联的信息，在多个不同的数据源与合成应用程序之间同步数据，访问合成应用程序并在不同的机器上分布所述合成应用程序，以及分析一个或多个合成应用程序的性能。

2.一个或多个包含指令的计算机可读存储介质，所述指令在被执行时实现一种方法，所述方法包括：

提供用于允许合成应用程序与服务彼此通信的连接服务，其中所述连接服务支持针对一个或多个应用程序模块中的预期和非预期状态的响应协调，提供消息代理服务，以及将多个端点上的传输、发现、和同步虚拟化；

3.如权利要求2所述的一个或多个计算机可读介质，其特征在于，所述连接服务支持多个不同的编码标准，便于基于消息的点对点通信，支持查询，确保应用程序被一致地命名，以及为所述合成应用程序提供安全体系结构。

4.如权利要求3所述的一个或多个计算机可读介质，其特征在于，所述连接服务实现广域邻近性知晓路由并提供联合名字空间。

5.如权利要求2所述的一个或多个计算机可读介质，其特征在于，所述连接服务管理消息和事件的注册，接收针对消息节点的消息，并发送来自消息节点的消息。