系统设计期间的验证的制作方法

专利名称：：系统设计期间的验证的制作方法
技术领域：
：本发明涉及系统的设计，更特别地涉及系统设计期间的验证。
背景技术：
：过去的几年间，互联网的使用蓬勃发展并且还在继续扩大。人们已经很习惯万维网(或者简称为“网络”)提供的许多服务，例如电子邮件、在线购物、收集新闻和信息、听音乐、浏览视频剪辑、找工作，等等。为了跟上这种不断扩大的基于互联网服务的需求，在致力于宿主站点、为这些站点提供的后端服务以及存储相关站点数据的计算机系统方面也已经有了很大的发展。分布式计算机系统的一种类型是数据中心(例如互联网数据中心(IDC)或者企业数据中心(EDC))，该中心是特殊设计的包括多个宿主基于网络的服务的计算机的联合体。也被称为“网络群”或“服务器群”的数据中心典型地在一个气候可控的、物理上安全的建筑物中具有几百至几千台计算机。典型地，数据中心提供可靠地互联网访问、可靠地电力供应以及安全的操作环境。不同的数据中心可以对运行在该数据中心的应用程序有不同的要求。例如，不同的数据中心可能需要实施不同类型的安全措施，或者需要应用程序支持不同的通信协议。另外，一些数据中心可能在一段时间后要改变这些需求。由于为了使应用程序可以在需要的数据中心上运行，设计员要知晓这些不同的需求并且在设计应用程序的时候要考虑到这些，所以数据中心间的差异就使得应用程序的设计过程变得困难。进一步地，目前程序员在将他们的应用程序配置在数据中心时，一般仅仅可以评价他们的应用程序是否将运行在一个特殊的数据中心上。如果由于应用程序不能满足数据中心的一个或多个必要条件而使得程序运行不成功，那么设计员就要修补应用程序的问题并在数据中心上重新试验该应用程序的运行。此过程将被重复许多次，并且会造成效率低下和不如人意的设计过程的结果。这里将描述的系统设计期间的验证将解决这些和其他的问题。发明概述这里将描述系统设计期间的验证。根据系统设计期间的验证的某些方面，接收将被设计的系统的描述和环境的描述。这些描述都用于在设计系统时以及在配置系统之前对照环境来验证系统。附图的简要说明在整个附图中，相同的附图标记表示相同的特征。图1说明了一个示例性的网络设置。图2是一个说明使用系统定义模块的示例性体系结构的方框图。图3说明了一个示例性的分层设置。图4是一个说明用于设计期间的验证的示例性过程的流程图。图5A和5B是一个说明创建一实例空间的示例性的递归扩展过程的流程图。图6A和6B是一个说明用于评估信息流的示例性过程的流程图。图7A、7B、7C、7D和7E是一个说明评估约束条件的示例性过程的流程图。图8说明了一个示例性的SDM文档。图9说明了一个示例性的SDM定义。图10说明了一个示例性的SDM成员。图11说明了一个示例性的设置成员。图12说明了一个示例性的约束条件的定义。图13说明了一个示例性的描述对象。图14说明了一个将在一层中的网络应用程序映射到另一层中的网络服务器主机的实例。图15说明了一个示例性的嵌入式数据类型的分级结构。图16说明了一个上投射和下投射的例子。图17说明了一个类型变换的例子。图18说明了一个示例性的关系树。图19说明了一个利用授权公开主机实现的例子。图20说明了一个利用授权向父体公开一成员实现的例子。图21和22说明了一个通信连接的验证的例子。图23说明了一个区域边界的例子。图24说明了一个示例性的实体空间。图25说明了一个示例性的可以执行这里描述的技术的普通计算机环境。实施例的详细描述下面公开的内容描述了与系统设计期间的验证的结构有关的各个方面。此公开包括系统定义模型(SDM)的论述，其也可以认为是服务定义模型(SDM)。SDM向应用程序设计者提供工具和上下文用以设计抽象的分布式计算机应用程序和数据中心。该模块定义了一系列表示应用程序的功能单元的元素，该程序最终将被物理计算机资源和软件执行。与该模块元素相关的是规划表，其表示如何指定由成员表示的功能性操作。正如这里所使用，术语“接线”也可以认为是“连接”、“通信”或者“通信关系”。术语“系统”也可以认为是“模块”并且术语“资源空间”也可以认为是“资源”。另外，术语“应用空间”也可以认为是“应用程序”，并且术语“实体空间”也可以认为是“实体”。进一步地，术语“类”也可以认为是“抽象定义”，术语“端口”也可以认为是“端点”，以及术语“类型”也可以认为是“定义”。图1说明了一个示例性的网络设置100。在设置100中，多(x)计算设备102(1)，102(2)，...102(x)连接到网络106。网络106代表各种常规网络拓扑结构和类型(包括有线和/或无线网络)中的任意一种，其使用各种常规网络协议(包括公共和/或专有协议)中任意一种。网络106包括，例如局域网(LAN)、广域网(WAN)、互联网的一部分等等。设置100表示大量不同的设置中的任意一种，各种设置包括，例如数据中心(例如互联网数据中心(IDC))、办公或商业设置、家庭设置教育或研究设施、零售或销售设置、数据存储装置等等。计算设备102可以是各种常规计算设备中的任意一种，包括台式PC、工作站、大型计算机、服务器计算机、互联网仪器、游戏控制台、掌上电脑、移动电话、个人数字助理(PDA)等等。设备102的一个或多个设备可以是相同类型的设备，或者可选择地为不同类型的设备。另外，即使在多个设备是相同的设备类型的情况下，多个设备也可以进行不同的配置(例如，两个设备102可以都是服务器计算机，但是可以有不同的硬件配置，诸如，不同的处理器、不同数量的RAM、不同容量的硬盘驱动器，等等)。在添加到设置100中后，一个或多个设备102也可以进行重新配置。例如，特殊计算设备102使用一段时间(例如，类似于分钟、小时、天、月等)来执行一个功能，然后管理员可以决定需要不同的功能(例如，从服务器计算机改变为工作站计算机、从web服务器改变为本地文件服务器，等等)。图2是一个说明使用SDM的示例性体系结构200的方框图。SDM被设计成在系统的设计过程中使用，并且被用于在设计过程结束后使用和/或管理系统。一个系统是一组可以共同工作并完成共有的功能的相关联的软件和/或硬件资源。这样的系统的一个例子是应用程序，其是指一组可以被计算设备运行或执行来完成各种功能的指令。应用程序的实例包括诸如游戏的娱乐应用程序、诸如文字处理器的产出应用程序、诸如电子百科全书的参考应用程序、可以用于web服务或金融分析的分布式应用程序，等等。此系统的另一个实例是可以调度一应用程序(或另一环境)的环境。环境是指可以使用应用程序(或另一个环境)的软件和/或硬件资源。以上环境可彼此分层。一般地，在系统的设计过程或阶段(也被称为开发过程或阶段)中，支持SDM的开发工具用于定义一个由通信软件和/或硬件部件组成的系统。系统的定义包括使用和操作一个分布式系统必须的所有信息，其包括所需的资源、配置、可操作的特点、策略等。设计阶段完成之后，使用阶段也可以利用系统定义来使用该系统并且动态地分配和配置所需的软件和硬件(例如，服务器、存储器和网络)资源。相同的系统定义可以针对于不同的主机环境和不同程度的使用。体系结构200既使用SDM定义模型也使用定义了SDM定义模块内的函数运算的计划表。该定义模块包括各种不同类型的数据结构，该数据结构整体被称为“定义”。通过一个或多个平台服务，例如应用程序接口(APIs)，揭示了SDM的函数性。一个系统的设计阶段期间，开发部件202产生一个包括系统定义的的文档，例如SDM文档204。开发部件202可以是任何不同的开发部件，诸如华盛顿州雷蒙德市的微软公司出售的VisualStudio开发系统。SDM文档204定义了所有的与系统的使用(和可选择地管理)有关的信息(这里也被称为知识)。任何在使用系统或管理系统时必要或使用的信息都包含在SDM文档204中。尽管在这里被描述为一个文档，但是应当认识到该知识也可选地被分配并保存到多个文档中。系统定义定义了根据一个或多个资源、端点、关系和子系统的系统。在一个SDM文档中(例如，XML文档)说明系统定义。资源可以是硬件资源或软件资源。端点代表跨系统的通信。关系定义了系统、资源和端点之间的联系。子系统可以表现为完整的系统并且典型地是一个较大系统的一部分。系统定义记录了动态系统的基本结构。它可以被看作是要在其上添加所有其他信息的框架。典型地，此结构在开发过程中由设计者和开发者指定，并且不会频繁改变。除了结构外，SDM还记录了使用信息、安装过程、配置表、事件和仪器、自动控制任务、完整的模型、操作策略等。由操作人员、卖主和/或贯穿分布式系统生命期中由管理系统添加其它的信息。SDM文档204包括系统的一个或多个约束条件(也可以称为必要条件)，调用并/或运行此系统的环境必需满足此约束条件。利用SDM文档，该环境本身被描述为“逻辑基础结构”(LIM)文档206、或数据中心说明或数据中心模型。与SDM文档204相似，LIM文档206可以是单一的文档或者可选地由两个或多个文档组成。LIM文档206可以使用任何不同的开发部件产生，例如类似于开发部件202的部件。LIM文档206也可以利用开发部件202产生(也就是相同的开发部件既可以用于产生SDM文档204也可以用于产生LIM文档206)。LIM文档206所描述的环境可以是单一的计算设备、或可选择的是计算设备的集合(例如，数据中心)、应用程序主机等等。不同的系统甚至是相同的系统可以安装到不同的环境中。例如，一个数据中心可以包括五十个计算设备，并且五个以上计算设备可调度此系统，而三十五个以上计算设备可调度另一系统。这些必要条件可以采取各种形式，例如关于配置该系统的计算设备的硬件必要条件(例如，处理器的最低速度、存储器的最小量、可用硬盘空间的最小量、有效网络带宽的最小量、有效特别安全机制，等等)、关于配置该系统的计算设备的软件必要条件(例如，特定的操作系统、一个或多个其它必须安装的应用程序、关于特定系统和/或操作系统如何配置的说明、要用的安全或加密的特定类型等等)、关于配置该系统的计算设备的其它必要条件(例如，可靠的特定安全密钥、必须执行的数据中心策略、使用的验证机制、环境拓扑结构等等)。相对于不同的LIM206中所描述的多个不同的环境，在SDMA文档204中描述的单一系统也是有效的。必要条件也可以用于其它的方面一也就是，环境可以具有关于要安装的系统的配置的约束条件或必要条件(例如，要执行的环境的标准或策略)。这些可以是由环境操作员创建的“显式”必要条件，诸如，系统必须具有的特定设置或配置、系统必须提供或支持的特定功能、系统必须支持的特定安全机制等等。这些也可以是环境的特定配置所产生的隐式必要条件。例如，如果环境中的主计算设备使用了一个特定类型的文件系统，那么利用此系统就不可能执行某些行为(尽管利用另一个文件系统可以执行那些相同的行为)。在系统的设计阶段，SDM文档204可以被验证部件208用于验证适合一个或多个特定环境的系统。这是一个两方面的验证验证用于环境的系统以及验证用于系统的环境。验证部件208可以通过将SDM文档204标识的必要条件与在LIM文档206中描述的环境进行比较，来验证用于系统的环境，并且确定该环境是否满足所有的必要条件。验证部件208可以通过将LIM文档206标识的必要条件与在SDM文档204中描述的系统进行比较，来验证用于环境的系统，并确定该系统是否满足所有的必要条件。如果系统和环境都满足所有的必要条件，那么设计者或开发者就知道该系统可以在该环境中配置并运行。但是，如果环境和/或系统并不满足所有的必要条件，那么验证部件208就通知不被满足的必要条件的设计者或开发者要作出对SDM文档204(以及响应的系统)和/或环境作出改变，以便使系统能在该环境中配置并运行。LIM文档206可以用于实际环境或者可选择地用于模拟环境。对于实际环境，LIM描述了一个存在的或者已经描述好但还没有建立的环境。例如，实体环境可以是现有的数据中心，或者数据中心已经设计好了但是还没有实际实现。对于模拟环境，LIM描述了一个不必要存在的预期中的环境。对预期中的环境可以作出各种设想，但是对于实际环境就不需要作出这样的设想。典型地，在系统的设计过程期间，LIM文档206描述了一个模拟环境。但是，当一实际环境存在于一特殊时间点时描述了此环境的LIM文档可选地用于整个设计阶段。验证部件208可以是一个或多个与数据中心分离的计算设备，在此数据中心中将调度被开发的系统。例如，验证部件208可以是单一的计算设备，或者可选择地将该验证职责分配到多个设备。可替换地，验证部件208可以是将调度要开发的系统的数据中心中的一个或多个计算设备。SDM使系统的操作组合跨越了横向和纵向。横向的组合由系统和子系统实现。纵向的组合由“层”来实现。应用程序、服务站点、网络拓扑结构和硬件都在分布式系统中起作用，但是典型的也被单独定义并且属于不同的组或组织。由定义了一组主机的约束条件的成员实现了分层，并且反之亦然。图3说明了一个示例性的分层设置。图3中显示了四层层302、层304、层306以及层308。虽然在图3中显示了四层，但是实际上层的数量可以改变，并且可以大于或小于四。另外，在不同实施例中不同层的内容也可以改变。如图3所示，不同的层可以位于其它层的上面和/或下面(例如，层306在成304的上面但是在层308的下面)。在一层中的不同的系统和子系统可以相互作用，并且也可以其它层中的系统和子系统相互作用。例如，层308中的子系统310既可以与层308中的子系统312相互作用，也可以与层306中的子系统314相互作用。另外，每个层可以看作是其相邻高层的环境。例如，层306是层308中的系统和子系统的环境，而层304是层306中的系统和子系统的环境。每个层302、304、306及308都有其各自关联的SDM文档。不同的层302、304、306及308可以表示不同的内容。在某些实施例中，层302是硬件层，层304是网络拓扑和操作系统层，层306是应用程序主机层，并且层308是应用程序层。硬件层是构建分层系统(例如，图1中的设备102)的物理设备(例如计算设备)。网路拓扑和操作系统层表示计算设备的网络拓扑(例如，图1的网络设置100)和安装在那些计算设备上的操作系统。应用程序主机层表示安装在计算设备上并可以宿主其它程序的应用程序(例如，SQLServer、IIS等等)。应用程序层表示安装在计算设备上并且不可以宿主其它程序的应用程序(例如，诸如游戏的娱乐软件、诸如文字处理器的产品应用程序、诸如电子百科全书的参考应用程序、可以用于web服务或金融分析的分布式应用程序，等等)。再参照图2，应用程序开发者可以利用开发部件202设计并开发应用程序。当开发者定义他或她的系统的不同部分以及这些部分之间如何相互关联的时候，产生获得这些部分和关系的SDM文件204。依靠LIM文件206所描述的环境，开发者可以使用验证部件208验证系统属性。在设计阶段的这个验证也可以被称为“设计期间的验证”。在下面的“示例性的SDM执行”部分将详细讨论的SDM将被设计，用以支持分布式系统(模型化系统)中成员的配置、相互作用和改变的说明。SDM基于对象关系模型。“对象”描述了存在于一个系统中的实体，并且“关系”表示不同实体间联系。进一步定义对象和关系是为了获得与SDM相关的语义信息。特别地，对象被分为组件、端点和资源。关系被分为下面几种连接(也被成为通信)、包含、宿主、授权和引用。有关对象和关系的进一步的细节将在下面提供。SDM包括“抽象定义”，其提供了系统成员的公共分类，为大部分系统提供了工具支持以及为在设计期间的定义检测提供了基础。一组抽象的定义为维护设计提供了全面的基础。“具体定义”表示实体系统或数据中心的设计的各部分。通过选择抽象定义以及提供一限定具体定义的属性的数量和设定值的执行过程，产生具体定义。利用这些具体定义的集合产生应用程序。SDM也包括“约束条件”，即基于所允许地多组关系实例可参与的关系的模型限制。约束条件用于描述依赖于包含在一关系中的对象配置的必要条件。例如，约束条件可以用于确定在通信协议的每个端点上的参与者是否使用了一致的安全设置。LIM文件206和SDM文件204被输入验证部件208的接口和处理层210。接口和处理层210控制SDM文件204的验证。验证部件208也可以被称为编译器。接口和处理层210包括装入器212、检验器214和模拟器218。装入器212分析SDM文件204，并将任何的参考文件或者类型装入到一个内存类型空间中。SDM文件204定义了SDM类(例如，以XML形式)，装入器212将SDM文件翻译成在内存类型空间中的SDM类。检验器214检查在SDM文件204中是否存在任何错误，为了使装入器212装入SDM文件204，检验SDM文件204是否正确书写。如果检验器214或装入器212检查到错误，该错误将被返回到开发部件202，其包括会导致错误的问题的任何指示。检验器214也“遍历”类型空间，检查设置值、类型和SDM文件参考。典型地，如果检验器214或装入器212检查到错误，将中止设计期间的验证。然后模拟器218通过调用下面将要讨论的扩展引擎220、信息流引擎222以及约束引擎224，模拟由LIM文档定义的环境。模拟器218遇到的任何错误都要返回给部件202(例如，作为结果226)，其包括会导致错误的问题的指示。典型的，如果模拟器218遇到错误，错误的指示将返回给开发部件，但设计期间的验证会继续进行。接口和处理层210调用扩展引擎220、信息流引擎222以及约束条件引擎224，来执行SDM文件204的验证。通常，扩展引擎220将创建基于SDM文件204的实体空间的操作组，用以添加需要的并包含传值的子代和关系的实例和操作，或者正确删除实例和关系。流引擎222”遍历”实例“图”并查找定义在实例上的流，以及将信息流中的值设定为合适的值。约束条件引擎224”遍历”实例空间同时查找和评估每个约束条件成员。在某些的实施例中，如果所有的约束条件都被评估为真实的(也就是，所有的约束条件都满足)，并且在处理SDM文档204时，验证部件208没有遇到错误，那么验证部件208就数字标记SDM文档204。此数字签名表示SDM文档204已经被成功的编译了。SDM文档204以任何各种不同的方式数字标记，一般的包括产生一个基于SDM文档204数字签名以及一个于验证部件208有关的公开/私人的密钥对。这样，数字标记的SDM文档可以随后被认为(举例来说，当使用他们的时候)已经被验证。已数字标记的SDM文档也被称为已编译SDM文档。除了评估各种约束条件，验证部件208也利用那些参考文档的全名(以及任意版本)更新其它SDM文档的说明书。于是，已编译SDM文档将包括这些全名。例如SDM文档可以通过名字而不是版本信息，引入另一个SDM文档并参考那个SDM文档，并且当验证部件208引入那个参考文档时，将识别被引入的那个文档的版本并将其添加到该已编译SDM文档。这里的论述涉及包含在SDM文档204中的各成员和定义。定义限定了如何在实例空间中创建一个实例。换句话说，定义限定了什么是可能的。成员描述了根据一个定义的特定用法或方案。例如，一个定义描述了对于一个特定的实例什么是可能的，一个构建描述了哪个可能性被包含在一个特定的实例中。下面的表格说明了成员或定义的例子，也说明了每个成员或定义的总体描述。这里所讨论的引擎参考了传值成员、传引用成员、扩展、监听程序以及最高级定义。传值成员指一个成员，在扩展的过程中为此成员自动创建的实例。在某些的实施中，传值成员不能是抽象的。传引用成员指一个成员，扩展引擎不能在扩展期间为此成员自动创建实例。相反地，用于此事件地外源监听程序创建了该实例(例如，接口和处理层210可以在模拟期间创建该实例，或者可以在模拟或使用期间询问(举例来说，通过用户接口)设计者或开发者来创建该实例)。扩展是指给定一个根实例然后实例空间就被该根实例填充的过程。根实例的所有成员都被递归创建。传引用成员不是由扩展引擎创建的，而是由外部资源创建的。监听器(例如，模拟器218)在事件刚触发时就被通知了。该事件的一个例子就是创建一个传引用成员的需求。最高级定义是指在SDM文档的根级限定的定义。SDM文档一般只有一个最高级定义，，但是在可选择的实施例中，一个SDM文档可以有两个或三个最高级定义。图4是一个说明用于设计期间的验证的示例性过程400的流程图。此过程由图2的验证部件208执行，并且可以以软件、固件、硬件或它们的组合的方式执行。响应于创建、删除或修改系统的请求，SDM文档和任何与该SDM文档有关的参考都被加载(步骤402)，可选择加载验证该SDM文档。在某些的实施例中，LIM文档已经被加载了并且由该LIM文档描述的实例空间也已经被创建了。但是，如果这些还么有进行，那么就加载LIM文档并且在步骤402中创建由该LIM文档描述的实例空间。在某些的实施例中，在步骤402加载SDM文档之前，由在这里描述的扩展、信息流和约束条件引擎创建LIM文档描述的实例空间。然后进行检测，用以确定在加载SDM文档的时候在SDM文档或创建的类型空间中是否存在错误(步骤404)。步骤404中的检测涉及SDM文档本身的结构或格式，而不涉及系统设计。例如，在步骤404中，进行检测是为了验证SDM文档的格式是正确(例如，文档具有正确的XML格式)，或者在SDM文档中存在未知的元素和类型，或者SDM文档中的类型参考是有效的，等等。如果存在任何错误，那么将返回这些错误的指示(步骤406)并且过程400结束。这些错误将例如，作为结果226返回给图2中的开发部件202。但是，如果没有错误，就选择步骤402中加载的SDM文档中的最高级定义。在某些实施例中，只有一个最高级定义。然后创建该选择的最高级定义的实例(步骤410)，并且扩展实例空间(步骤412)。该最高级定义被用作扩展的起点，其由图4的扩展引擎410来执行。实例空间是这样扩展的分析该最高级的定义并创建根实例的每个成员的实例，然后分析每个创建的实例并创建他们的每个成员的实例，等等。此过程将在标题“扩展引擎”之下详细讨论。当基于最高级定义的扩展完成之后，识别由扩展的实例空间中的实例限定的信息流，并且将信息流中的值设定为适当值(步骤414)。此过程将在标题“信息流引擎”之下讨论。估计信息流的值被设定后，就检验约束条件(步骤416)。作为约束条件检验的一部分，实例空间中的每个约束条件都要被验证，这将在标题“约束条件引擎”下面详细讨论。一般的，这些约束条件将对照模拟环境中的设置进行验证，而该模拟环境(例如，在LIM206中所描述的)是在验证系统时所对照的。在检验完约束条件之后，将进行关于SDM文档中是否存在其它尚未选择的任何附加最高级定义的检验(步骤418)。如果在SDM文档中存在一个或多个其它附加最高级定义，那么就选择此一个或多个其它的最高级定义(步骤420)并且处理返回到创建选择的最高级定义的实例的步骤410。但是，如果不存在其它未选择的最高级定义，将检测是否检测到任何错误(步骤422)。步骤422中的错误是指在步骤412的扩展、步骤414中的信息流及步骤416中的约束条件的检测中产生的错误和/或警告。如果存在任何错误或警告，返回那些错误或警告的指示(步骤406)，同时处理400结束。这些错误将被例如，作为结果226返回给图2中的开发部件202。通过在步骤406中将错误和/或警告返回给开发部件202，或者步骤424中的成功的指示，SDM文档204描述的系统的设计期间的验证的结果将返回给开发部件202。这些错误和/警告或者成功的指示也可以显示给使用开发部件202的设计者，用以允许告知设计者设计后(并在SDM文档204中描述)的系统是否已经被验证过，或者是否存在潜在的问题。通过将特定错误和/或警告的指示返回给设计者，可以更好地通知设计者潜在的问题是什么以及如何解决他们(或者是否有必要解决它们)。此反馈可以在设计过程中返回给设计者，而不需要设计者在发现设计的系统中存在问题之前，将系统配置在一个数据中心上。模拟如上所述，图2的接口和处理层210模拟了LIM文档206中定义的环境。这就允许在系统的设计期间对照预期的环境验证SDM文档204描述的系统，以便在将系统配置到环境中去之前就识别出错误。实例空间中的许多实例可以由扩展引擎创建，这将在以下详述。但是某些实例由模拟器218创建而不是由扩展引擎创建。在某些实施例中，由模拟器218创建的实例是最高级的定义并且是传引用成员。在某些实施中，每个最高级定义在其自己的实例空间中被模拟。模拟器218模拟在已编译文档的根部发现的两种类型的定义(这些被称为最高级的定义)(1)系统定义，以及(2)其中主机和客机是系统定义的宿主关系定义。这两种类型的定义是由模拟器218创建实例的相当独立的定义。其它的定义通常仅仅用在其它定义的上下文中，从而由扩展引擎220创建。在某些实施例中，模拟器218并不模拟抽象的定义，这样典型地导致少量的，即便要，有意义的验证。通过创建定义的实例并且将此实例添加为实例空间的根实例来模拟系统定义。然后通过调用扩展引擎220例示该实例的成员和嵌套成员。宿主定义的模拟提供了主机和客机之间的验证。在某些实施例中，宿主关系的实例并不用作根实例，这样看来，特殊的根实例在调用扩展引擎之前就创建好了。这个特殊的根实例是具有三个成员的系统定义(1)关于宿主关系的主机的系统定义；(2)关于宿主关系的客机的系统定义；(3)与第一个两成员的主机和客机系统定义的实例有关的宿主关系定义。然后调用扩展引擎222例示该特殊的根实例的成员和嵌套成员。扩展引擎220并不创建传引用成员的实例，因为要创建的实例的数量是未知的并且要由配置环境确定。另外，传引用成员可以是抽象的，这样用于例示组成成员的具体定义就是未知的。人为干预(例如，系统管理员所带来的)通常用于回答在配置期间的问题。可选地，这样的干预也可用在设计期间的验证期间。但是，更典型地，接口和处理层210(例如模拟器218)会如下模拟人类操作员可能的选择，这样就减轻了在模拟期间对人为干预的需要。模拟器218创建一定数量的组成成员的实例，该数量等于一个或者发生的事件的最小数量中的比较大的数(例如，由传引用成员在一参数MinOccurs中指定)。如果传引用成员是抽象的，那么模拟器218就不创建该成员的实例，但是会向用户返回一个警告信息(例如，表示不能模拟一个抽象的传引用成员)。扩展引擎扩展引擎220允许向验证部件208输入主要的命令，并且将那些命令展开以识别这些命令所作用的正确的对象和关系。典型地，这些主要的命令是用于创建或删除特定对象或关系的命令(例如，创建一个网络应用程序的命令，或删除一个网络应用程序的命令)。为了创建一基于SDM文件204的实例空间而添加所有附加实例和网络包括传值子代和关系所需的动作，或者删除恰当的实例和关系，扩展引擎220展开一组操作。最初，在模拟期间创建了最高级定义的实例(也称为最高级实例)后，调用扩展引擎220来填充此实例空间。根实例作为扩展的起始位置传给扩展引擎。通过扩展而创建的实例会与根实例相关联。一特殊实例空间第一次调用扩展引擎220时，传给扩展引擎220的根实例是最高级的实例(最高级定义的实例)。但是，扩展引擎220可以并且典型地被递归调用，这样最高级实例的成员和嵌套成员才能称为此递归调用的根实例。扩展引擎220由创建根实例的每个成员的实例开始。由于要例示每个成员，就要检查每个嵌套成员。任何在另一个成员内部定义的成员都被称为嵌套在其它成员之内。可以通过多级嵌套成员(例如，一个成员可以具有定义在其内部的嵌套成员，并且这些成员的每一个都可以有定义在他们中的嵌套成员，依次可具有定义在其内部的嵌套成员等等)。可以在每个成员和嵌套成员上递归执行扩展过程，直到已经完全建立根实例的实例空间。在某些实施例中，在扩展过程中仅仅例示各种成员的子集。在扩展过程中创建的此实例的子集包括以下对象成员子系统、资源以及端点。在扩展过程中创建的此实例子集还包括下面的关系成员包含、通信、宿主、授权以及参考。其它不包括在此子集中的成员就不被扩展过程所例示，而是在扩展过程创建上述实例之一时，创建过程检查成员或定义并自动为其它成员创建其子成员的实例。这些其它成员的例子包括信息流成员和约束条件成员。在某些实施例中，在调用扩展引擎220时，成员的实例已经存在的情况下，就不再创建该实例。但是扩展引擎220继续对每个实例递归从而验证其实例空间是否完全创建(并且从没有创建的递归调用中创建一些嵌套成员)。图5A和5B是一个说明创建一示例空间的示例性的递归扩展过程500的流程图。此实例空间由SDM文档定义，例如图2中的SDM文档204。过程500由图2中的扩展引擎220完成，并且可以以软件、固件、硬件或它们的组合的形式执行。最初，访问一个实例定义(步骤502)。在调用后，扩展引擎220被告知有一个要扩展的实例定义(如此部分已经讨论的根实例)，并且在步骤502中访问此实例定义。此实例定义将传给扩展引擎220，也可以传送一个表示此实例定义的所在位置的标识符(例如，一指针)，或者可以通知从何处和/或如何访问此实例定义。在此实例定义是最高级定义的情况下过程500可以被模拟器218调用，或者可选择地可以被过程500本身递归调用。然后选择实例定义的一个组成成员(步骤504)。可以以任意顺序选择实例定义中成员，一般以它们出现在定义实例空间的SDM文件的顺序进行选择。在某些实施例中，所有对象成员在所有关系成员之前进行选择。然后对于选择的成员是对象成员还是关系成员进行检查(步骤506)，同时根据检查的结果继续进行过程500。如果选择的成员是对象成员，那么就检查在创建的实例空间中是否存在正确数量的所选择的成员的实例(步骤508)。每个成员都包括一个关于要创建多少成员的实例的指示。在某些实施例中，使用一个实例的默认值，这样除非该成员指定了要创建更多的实例，否则每个成员只创建一个实例(无论在此成员中是否显性指定)。如果尚未存在正确数量的实例，那么就检查该对象成员是否是一个传值成员(步骤510)。如果对象成员是一个传值成员，那么就创建最小数量的该成员定义中所指定存在的对象成员(步骤512)。但是，如果该对象成员不是传值成员，那么它就是传引用成员，这样就触发一个事件，其允许监听器(例如图2的模拟器218)从而创建传引用成员的实例(步骤514)。创建对象成员的实例之后，不管是在步骤512或步骤514，或者如果在步骤508中确定已经存在正确数量的成员实例，过程500进行到步骤516。在步骤516中，过程500，为在步骤512或步骤514中创建的实例的每个成员实例(或者确定已经在步骤508中创建的实例)调用过程500。当递归调用过程500时，调用过程500的每个成员实例都成为每个调用的过程500的实例定义。这样，根据实例成员递归调用过程500，直到在实例空间中创建了所有的实例。另外，还要进行检测是否在在步骤504中没有选择的实例定义中还有附加成员(步骤518)。如果在实例定义中还存在一个或多个附加成员，那么步骤500返回到步骤504从而选择这些成员中的一个。但是，如果在实例定义中不存在此附加成员，那么这些实例定义的步骤500就完成了。返回到步骤506，如果选择的成员是一个关系成员，过程500根据包含在此关系中的源实例的数量和目标实例的数量，确定要创建的关系实例的数量(图5B的步骤522)。通过将原实例的数量和目标实例的数量相乘确定要创建的关系实例的数量，相乘的结果就是要创建的关系实例的数量(步骤524)。可选择地，将原实例的数量与目标实例的数量相乘的结果可以得到关系实例的最大值，而在步骤524中仅仅创建该最大数量的一个子集。例如，存在多个可以使用的主机，在步骤524中可能仅仅选择一个。类似于上述的传引用成员，基于选择的关系实例的子集，调用监听器(例如，人类操作员或者模拟器218)。模拟器218可以利用例如，用于确定要创建的关系实例的子集的不同条件或规则进行配置或编程。根据关系成员的类型以不同方式创建该关系实例。在某些实施例中，可以使用关系组成成员的类型如下包含定义成员、通信定义成员、参考定义成员、宿主定义成员、以及授权定义成员。包含定义成员是一个一对多的关系，其将每个实例的父体和子成员联系起来。包含定义成员描述了一个对象成员可以包含另一个对象成员。通信定义成员是一个多对多的关系，其将所有的服务器和客户机成员实例的组合联系起来。通信定义成员描述了独立配置的软件单元之间的相互作用。参考定义成员一个多对多的关系，其将所有的依靠原成员定义的组合联系起来。参考定义成员用于取得实例间的从属性(除宿主关系定义成员外)。这些从属性可以用于，例如在配置过程中控制构造顺序以及在安装和更新过程中控制系统间信息流参数。宿主定义成员是一对多的关系，其将一个宿主和每个客户机的成员实例相关联。宿主关系成员用于识别为了被构造，一个客机需要一个主机。授权定义成员是一个一对一的关系，其将与两个系统的通信端点相关。授权定义成员用于从一个系统向另一个系统传送一个行为(例如，传送一个系统直接到其他系统的端点的所有交互作用)。对于关系的每个实例，该关系实例都与源和目标实例相联系(步骤526)。然后过程500返回图5A的步骤518，检测在实例定义中是否存在要选择的其他成员。因此递归调用过程500，在递归调用该过程的过程中，创建了不同的对象和关系实例。该递归扩展过程可以了解当已经创建了所有的成员实例时何时完成实例空间的创建。由于扩展过程的递归特性，产生的实例与作为图2中的信息流引擎222和约束条件引擎224的入口点的最顶层实例相互连接。这样创建的实例空间可以被看作是实例树，其中树的每个节点都表示一个成员实例。另外，树的每个节点(最高层节点除外)都连接到一个父节点，该父节点表示调用扩展过程为创建树节点而调用扩展处理的成员实例。进一步地，树的每个节点都与零个或更多的子节点相连，该子节点是树节点的成员实例的成员。当叶成员确实没有任何嵌套成员的时候(例如，所有的叶成员都有零个子节点)，该递归扩展过程就知道何时完成创建实例图。另外，为了避免由于一个定义具有一个和它同类型的成员而使得扩展过程无线循环下去，如果一定义并没有被例示为祖先实例，在某一特定的实施例中，实例扩展过程仅仅选择创建该实例。例如，如果存在一个目录的定义，并且该定义在其内部还具有一个目录，那么一旦存在单个目录，扩展引擎就停止扩展过程。信息流引擎在扩展引擎220完成扩展处理后，调用扩展处理产生的实例空间中的信息流引擎222。信息流引擎222“遍历”实例空间的实例图，并且发现实例图中定义的信息流实例。然后信息流引擎222将信息流中的值设置成适当值。可以在SM文件204的定义中说明设置，并且相应的设置值可以存在于由这些定义创建的实例中。设置值可以是非计算设置值或者计算的设置值。非计算设置值是由来自定义的默认值或初始值设置的设定值，或者是由明确设定值的用户设定的值。非计算设置值可以被限定在创建其所属的SDM实例时，来设置，或者可选择地，在SDM实例的生命期中改变。非计算设置值并不是信息流的输出，但是它们可以作为信息流的输入。计算的设置值是一个信息流的输出的设定值。因此，信息流可以将值设置为计算后的设定值的值，但是其它的实体一般不可以。在某些实施中，仅仅存在一个信息流来给该值提供一个特定的计算的设置值。在某些实施中，如果多个信息流输出给相同的设置值实例，那么就报告错误并且信息流的输出设定为错误状态。计算的设置值基于一个或多个输入。这些输入可以是计算的设置值和/或非计算设置值。在某些实施例中，计算设置值可以被分为两类配置值和非配置值。配置值是由信息流计算的值，此值产生将之作为一部分的SDM实例配置。例如一个文件或者数据库名的完全路径可以是配置值。非配置值是由信息流计算但不产生配置的值。反而，他们仅仅作为约束条件的交换值。例如，考虑所有继承的web.config的最终web.config设置就是一个非配置值。另一个非配置值的例子是考虑了文件的包含目录和内容以及关于该文件的配置的访问控制列表的该文件的最终访问控制列表。信息流引擎222随意不同地处理设置值和非设置值。例如，可以给配置值一个较高的优先级，这样可以在设置非配置值的信息流之前国际设置配置值的信息流。一般来说，通识别实例空间中的信息流实例以及识别该信息流实例的输入值(例如，识别作为这些输入的源的其它实例的设定值)来估计信息流的值。信息流实例引用一指令模块和一组指令，此指令模块或此组指令可以处理相应于该信息流实例的信息流函数。根据输入的值处理信息流函数，并获得该信息流函数的结果。该信息流函数的结果设置为信息流实例的输出。一个信息流可以有零或多个输入值，以及一个或多个输出(例如，一个或多个实例的设置值可以根据该信息流的输出进行设置)。可以使用各种信息流函数的任何一种。信息流函数可以由系统开发者和/或其他人员定义。例如，与创建SDM文件204相同的设计者可以定义一个或多个信息流函数。作为在另一个例子中，开发部件202的制造商或某些其他第三方开发者都可以定义一个或多个信息流函数。信息流函数本身也可以包括任何不同的计算和/或操作，例如运用代数、几何、微积分等的运算，基于日期和/或时间的计算，随机值计算，等等。在某些实施例中，定义在SDM文件中的信息流成员与管理器定义有关。反过来，管理器定义包括一个指针，该指针指向一组可以执行处理信息流函数的指令或代码。这样，为了估计用于一个信息流实例的信息流，确定该相关的管理器定义并且例示该相关的管理器(如果还没有例示的话)。从该管理器中获得指向指令或代码组的指针，为了确定该信息流的输出，允许获得并执行该指令或代码组。另外，在某些实施例中，该管理器也支持类型变换。在这样的实施例中，管理器允许一个信息流基于两个或更多的不同类型的设置值。例如，输入值可以是一个与输出类型不同的类型。管理器提供了一个或多个允许作出这样的类型转换的方法，或者可选择的包括了一个指针，该指针指向用于执行该转换的一组可获得的并且可执行的指令或代码。不同的管理器支持不同的转换(例如，管理器设计者可以将管理器设计为支持任何他们想要的类型转换)。图6A和6B是一个说明用于评估信息流的示例性过程600的流程图。过程600由图2重的信息流引擎222执行，并且可以以软件、固件、硬件或者它们的组合的方式执行。最初，找出实例空间中的关于实例的所有设置(步骤602)。这些设置可以以不同的方式发现，诸如通过检查用于设置值的实例图中的每个节点的方式。然后标识出实例空间中的所有的信息流实例(步骤604)。实例空间中的每个信息流实例都被标识为“脏的”并且“未访问”(步骤606)。标记“脏的”表示该信息流尚未被执行或者求值。标记“未访问”表示该信息流的执行或求值还没有开始。信息流实例的标记可以以各种不同的方式执行。例如，每个信息流可以有一个“脏的”标志位，其可以设置为标记该信息流为“脏的”，并且“没有被访问”的标志位可以设置为标记该信息流为“没有被访问”。作为另一个例子中，信息流引擎222可以保存一个列表、表格或其它数据结构，在其中引擎222可以保存一个信息流实例的记录以及它们的相关标记。然后确定接收作为信息流实例的结果的值的设置(步骤608)。在步骤608中，确定所有计算的设置值。设定本身表示它们是不是计算的设定值或者非计算设定值(例如，它们可以具有一个标志或属性，例如一个“固定的”属性，其可以被设置为表示它们是非计算设定值)(在不周608也可产生识别值从属性的从属性图)。从属性图为每个设定值表示它依靠哪个其他设定值(即，此其它设定值是其输入)以及哪个其他设定值依靠它(即，用它作为输入值的其它设定值)。然后选择在步骤604中标识为“脏的”并且“未访问”的信息流实例的其中之一(步骤610)。信息流实例可以以任何顺序选择，诸如，以信息流在步骤604中被标识的顺序、随机的、基于输入值的编号，等等。然后将该选择的信息流实例标记为“已访问”，但是保持为“脏的”标记(步骤612)。这就表示与信息流实例有关的信息流的求值或执行已经开始，但是该信息流还没有被执行或者求值(例如，该信息流的输出值还没有确定)。然后标识信息流实例的输入值(步骤614)。每个信息流实例具有一个表示每个输入源(例如，另一实例的一特定设置值)的参数。然后检查该标识的输入是否被赋值(图6B的步骤616)。非计算设置值输入已被赋值，正如由已被求值的信息流实例计算的已计算设置值输入。但是由未被估计的信息流实例计算的已计算设置值将不被赋值(例如，它们可能有一个空值)。如果一个或多个指定的输入还没有被赋值，那么就暂停这个信息流实例(在步骤610中选择)的求值(步骤618)。暂停求值是为了计算输入值。对于每个还没有值的输入，识别设定输入值的信息流实例(步骤620)。然后过程600返回到图6a中的步骤612来开始求信息流实例的值(步骤622)。然后当所有的输入都具有其值的时候，在步骤618暂停的信息流的求值就重新开始(步骤624)。例如在下面将要讨论的步骤616或者步骤626中，可以恢复求值。应当注意的是，在步骤620中标识的一个或多个信息流实例的求值可以由于标识的输入还没有值而自行中止。返回到步骤616，如果标识的输入具有了值，那么输入的值从其源处获得(步骤626)。该值可以从不同的源获得，例如，从SDM文件204、从根据SDM文件204例示的对象实例、从信息流实例(信息流的输出)，等等。然后识别用于执行求信息流成员的信息流函数的值的指令或代码组(步骤628)。可选择的，与其运行一组指令或代码，该信息流函数还不如由硬件执行。然后执行这组指令或代码，然后指令或代码的执行结果被用作信息流实例的输出(步骤603)，其也被称为信息流的输出。然后将信息流标记为“不脏”，用以表明该信息流已经被执行或求值(步骤632)。该信息流应该已经在步骤612中被标记为“已访问”，但是，如果该信息流没有被标记为“已访问”，那么在步骤632中将该信息流实例标记为“已访问”。然后检查在实例中间是否还存在其它的被标记为“脏的”或“未访问”的信息流实例(步骤634)。如果还存在任何其他实例，那么过程返回到图6A的步骤610，用于选择此信息流实例之一。当所有的信息流实例都被求过值之后(例如在步骤604中没有一个信息流实例被标记为“脏的”或“未被访问过”)，然后信息流求值过程600结束(步骤636)。当信息流结束，模拟器218有了一个具有设定值的完整的实例空间。在图6A和6B中的过程600被描述为，暂停具有输入但是还没有值的信息流实例的求值，并且求设置这些值的信息流实例的值。但是过程600也可以以可选方式执行。例如，与其求设置那些值的信息流实例的值，过程600可以返回到选择一个信息流实例的图6A的步骤610(不考虑其是否为暂停的信息流设定了一个输入值)。在此可选择的方式中，信息流的求值可以导致完成某些信息流实例的求值而其它信息实例的求值被暂停了的情况。当发生这种情况的时候，可以重复步骤616用以为每个暂停的信息流实例确定标识的输入是否具有值。至少有一个被暂停的信息流实例的输入具有值，并且重复步骤616的过程可以一直进行，直到所有的信息流实例都被求值了。信息流引擎222也检测图6A和6B中的信息流求值过程中的循环引用。循环引用指一个或多个信息流实例中每一个至少它们的属性之一都依靠(直接或间接)其他的输出。例如，信息流实例A具有一个输出值，该值也是信息流实例A的输入值。在另一个例子中，信息流实例A的输入值源自信息流实例B的输出，但是信息流实例B的输入值源自信息流实例A的输出值。还一个例子，信息流实例A的输入值源自信息流实例B的输出，信息流实例B的输入值源自信息流实例C的输出，而信息流实例C的输入值源自信息流实例A的输出。这样的循环引用不能被求值，但是信息流引擎222还能检测它，并且在此循环引用中的设置值被设置为错误状态。循环引用可以利用“脏的”和“已访问”标记被检测出。在上面讨论的步骤618中当暂停了一个信息流的求值的时候，该信息流被标记为“已访问”，但是也被标记为“脏的”，并且开始另一个信息流的求值。该另一个信息流的求值也可以被暂停，等等。如果在此信息流求值的暂停期间，一个被求值的信息流已经在前面被标记为“已访问”并且仍然是“脏的”，那么就检测到一个循环引用。换句话说，一个或多个信息流被暂停，并且在该暂停期间，求值所选择的另一个信息流也已经被标记为“已访问”和“脏的”，那么由于另一个求值所选择的信息流的求值也已经被暂停了，就检测到了一个循环引用。可选择地，可以以其它任何不同的方式检测循环引用。例如，在上面讨论的步骤618中可以创建表示值从属性的从属关系图，此从属关系图可以用于识别循环引用。当检测到循环引用时，此循环引用的所有信息流都被标记为错误(例如，循环信息流错误)。检测到循环引用时所进行求值的信息流是此循环引用的一部分，在检测到循环引用时从正在进行求值的信息流接受输入的其它信息流以及从这些信息流之一接收输入的每一个其它信息流也是此循环引用的一部分。然后停止所有的作为此循环引用的一部分的信息流的求值。这些信息流都被标记为“已访问”和“脏的”，这样才能继续进行其余的信息流。应当注意到的是，信息流可以是确定性的或非确定性的。确定性的信息流在任何时候用特定的输入值集合调用它时，都输出相同的值。例如，信息流可以输出两个输入值的和。由于信息流总是给定特定的输入值集合而输出相同的值，因此这样的信息流被称为是确定性的。然而，非确定性的信息流在每次用相同的输入值集合调用它时，都可以输出不同的值。例如，根据一个输入值，信息流产生一个随机数。由于该信息流可以在每次用相同输入值调用时，都产生一个不同的随机数，因此此信息流被称为非确定的。不具有输入值的信息流可以是确定的(总是输出相同的值)或非确定的(每次调用时都输出不同的值)。在某些实施例中，设定值可以有一个错误状态。当处于一个错误状态时，设定值可以保留错误信息(例如，错误代码或者错误的描述)。如果设定值不保留错误信息，那么此错误信息将会以其它的某种方式报告(例如，通过将设置置为错误状态的事件)。一个设定值可以以不同的方式被设为错误状态。例如，当在执行一个信息流的过程中发生错误时(例如，由于信息流返回错误；由于信息流引擎不能执行信息流，诸如当信息流引擎检测到一个循环引用或者由于输入问题不能运行一个信息流；等等)，信息流引擎222将此信息流的输出值设为错误状态。错误状态可以通过信息流传播，这样具有错误状态的输入的任何信息流将会使信息流引擎将此错误状态传播给其输出。此错误状态最终会被信息流引擎222返回给开发部件202(例如，作为图2的结果226)。可选择地，引起源错误的事件也会被信息流引擎222返回给开发部件202(例如，作为图2的结果226)，而是通过该信息流返回错误状态的传播结果。另外，在某些实施例中，一个信息流的输入和/或输出涉及当前并不存在的实例(例如，输入或输出可以涉及还没有创建的成员)。当一个信息流的输入涉及当前并不存在的实例的时候，如果对该信息流定义默认值，该输入就被认为被复位或还原为一个默认值(例如，被还原为一个指定的值)。在信息流中不存在这样的指定，那么它将被还原为一个该成员的数据类型的默认值。当一个信息流的输出涉及一个当前不存在的实例，那么就不使用此输出值。如果信息流的输出不存在，那么信息流由于其没有被设为任何值，就不必执行。但是，即使当前所有的输入都不存在，如果至少存在一个输出，该信息流将被运行。也可以假设设计期间的验证允许继承的设置模式。继承的设置是指实例空间具有一层次结构的对象，并且设置值可以用于一对象并使得此值用于此对象层次结构之下的所有对象。实际上，这为在该对象下面的那些对象创建了一个默认值，除非在该对象下面的那些对象不考虑该默认值并具有它们自己的明确的适用值。这些可以被称为对象的适用设置(该设置用于一个特定的对象)和对象的结果设置(将适用设置和继承其父对象的设置合并的结果)。此继承的设置可以用于不同的方式。在某些实施例中，此继承的设置可以在SDM文件204的创建期间使用。SDM文件204的设计者知道此继承的设置存在的位置，并在SDM文件204的设计中考虑到它们。例如，SDM文件204的设计者可以说明此适用设置和结果设置，但是约束条件正好与此结果设置相反。在可替换的实施例中，每个设置都具有适用设置值和结果设置值。这样，在一个实例中的每个设置都受两个值的影响而不是一个值。适用设置值是由该值的初始化或者明确设置的值设置。结果设置值由信息流设置。默认地，参考该设置会得到该结果设置值，除非没有信息流设置它，在这种情况下，它们将获得适用设置值。在另一方面参考一个信息流的输出会涉及默认的结果值。另外，所有的引用都可以任意向明确参考两个设置值的其中之一添加一个值类型限定符。典型地，每次对信息流进行求值，都使信息流的输出发生改变。也就是说，信息流的执行可以导致重写该信息流的任何以前的输出。但是，在每个设置都具有适用设置值和结果设置值的实施例中，每个信息流可以将使用设置值作为其输入之一写入。给定一个恰当的推定的信息流函数，会导致信息流的输出成为附加到其它信息流的输入的适用设置。这样，在这些实施例中，可能会在实际上具有一个附加到一个信息流输出的新的输入。约束条件引擎为了为由SDM文档204定义的系统评估约束条件，模拟器218调用约束条件引擎224。由约束条件引擎224执行的评估相对于环境评估在SDM文档204中定义的约束条件(验证该环境是否满足由SDM文档204提出的约束条件)，和/或相对于在SDM文档204中定义的系统评估环境定义的约束条件(验证在SDM文档204中定义的系统是否满足由系统提出的约束条件)。约束条件引擎224“遍历”实例空间，并查找和评估每个约束条件。约束条件引擎224既评估由SDM文档204定义的约束条件，也评估由LIM文档206定义的约束条件。一般地，在信息流引擎222完成信息流的求值后，模拟器218调用约束条件引擎224，这样就能在扩展以及信息流求值处理所得到的实例空间的基础上，执行约束条件的检查。但是，在可替换的实施例中，可以在信息流引擎222完成信息流的求值之前，调用约束条件引擎224。约束条件可以采用不同的形式，在特定的实施例中，约束条件包括设置约束条件、关系约束条件以及对象约束条件。设置约束条件约束了一个对象的设置并且由管理器或代码返回从而执行此评估。关系约束条件约束了一个对象可以参与的关系。对象约束条件约束了在一个关系中的对象。典型地，约束条件定义标识了一个应用约束条件的目标定义，并且进一步限定了该约束条件是什么。在一个设置约束条件的情况下，一组指令或代码(或者可选择的为一个硬件模块)与该约束条件(例如，由约束条件定义指定)相关联，该指令或代码可以被执行用以评估目标是否满足约束条件。在特定的实施例中，该约束条件与一个指向一组指令或代码的管理器定义相关联，并类似于上述关于信息流评估的讨论中的管理器定义。图7A-7E是一个说明评估约束条件的示例性处理700的流程图。处理700由图2中的约束条件引擎224执行，并且可以以软件、固件、硬件或者它们的组合的方式执行。最初，识别实例空间中的所有的约束条件(步骤702)。步骤702中的识别包括识别设置约束条件、关系约束条件以及对象约束条件。步骤702中的识别既可以识别由系统(例如SDM文档204中)限定的约束条件，也可以识别由环境(例如LIM文档206中)限定的约束条件。然后选择一个识别的约束条件(步骤704)。该约束条件可以以任何不同的方式选择。例如，约束条件可以以它们在步骤702中标识的顺序进行选择，不同类型的约束条件可以在其它类型之前选择(例如，设置约束条件可以在关系约束条件前面选择)，可以随机选择约束条件，等等。然后根据该约束条件是关系约束条件、设置约束条件还是对象约束条件，评估该选择的约束条件。如果该约束条件是一个设置约束条件，那么就从该约束条件的目标实例中获得适当值(步骤706)。此约束条件识别要评估的目标实例(例如，通过名字识别是该约束条件的目标的对象)。约束条件也标识了要评估该目标实例的哪个设置值，并且这些设置值从目标实例中获得。然后标识出用于执行评估约束条件的约束条件函数的指令或代码组(步骤708)。可选择地，不执行指令或代码组，约束条件函数可以以硬件的方式完成。然后执行指令或代码组，用以确定(或者硬件确定)在步骤706中获得的值是否满足约束条件(步骤710)。例如，指定组可以将获得的值与约束条件中的值进行比较，如果获得的一个或多个值与一个或多个约束条件相同，就确定约束条件满足。然后返回约束条件函数的结果(步骤712)。此结果可以作为结果226返回给图2中的开发部件202。约束条件可以任意地包括一个名字或其它信息，该信息描述了可以在步骤712中作为结果返回的约束条件，该信息允许向开发部件202地设计者呈现描述任何错误的附加信息。然后检查在实例空间中是否存在任何其它没有选择的约束条件(步骤714)。如果所有的约束条件都已经被选择并评估过，那么约束条件的检查过程就完成了(步骤716)。但是，如果还有一个或多个约束条件没有被选择，那么处理700就返回到步骤704来选择另一个标识的约束条件。返回到步骤704，如果选择的约束条件是一个对象约束条件，那么就标识出该约束条件的目标实例的第一角色和第一对象定义(图7B中的步骤718)。对于一个对象约束条件，该约束条件的目标实例是一个关系实例。该目标实例的第一对象定义指的是所选择的约束条件目标的对象名称。该对象实例的第一角色标识了必须与由第一对象定义标识的定义相匹配的关系作用。然后检查是否存在由约束条件标定的第二角色和第二对象定义(步骤720)。在某些实施例中，约束条件可以标定多个对象和/或角色，并且第二角色和第二对象定义可以用于标识出由约束条件标定的第二角色和/或对象定义。如果存在由约束条件标定的第二角色和第二对象定义，那么就检查该约束条件的第一、第二角色和第一、第二对象定义是否都与目标实例相匹配(步骤722)。如果一个或多个角色或者一个或多个对象定义与目标实例不匹配，那么匹配计数变量就设为零(步骤724)，并且处理700继续到图7C的步骤726，其将在下面详细讨论。但是，如果该约束条件的第一、第二角色和第一、第二对象定义都与目标实例相匹配，那么就评估第一对象实例的所有嵌套的约束条件(步骤728)。嵌套的约束条件既指该约束条件定义的任何子实例，也指这些子实例的任何子实例，等等。嵌套的约束条件可以是对象约束条件、关系约束条件和/或设置约束条件。如果存在任何的嵌套约束条件已经在前面评估过了，那么就记录它们的结果，然后在步骤728中使用那些结果。但是，对于任何还没有评估过的嵌套约束条件，通过调用处理700并且利用每个嵌套约束条件作为在图7A的步骤704中选择的约束条件，评估该约束条件。一旦所有的嵌套的约束条件都已经评估过了，那么就检测所有的嵌套约束条件是否都为真(步骤730)。如果存在一个或多个嵌套的约束条件被评估不为真，那么匹配计数变量就设为零(步骤724)。但是，如果所有的嵌套约束条件都评估为真，那么匹配计数变量就设为1(步骤732)，并且处理700继续到图7C中的步骤726，这将在下面详细讨论。可选择地，由于步骤730是一个评估所有嵌套约束条件是否都为真的检测，在某些情况下，并不是所有的嵌套约束条件都需要评估，一旦有一个嵌套约束条件被评估不为真，就可以停止嵌套约束条件的评估并且处理700可以继续到步骤730。例如，存在三个嵌套约束条件并且被评估为错误或者不为真的第二个嵌套约束条件，那么不管第三嵌套约束条件是否评估为真，步骤730的结果都是相同的(转向步骤724)。再返回到步骤720，如果不存在由约束条件标定的第二角色和第二对象定义，那么就检查约束条件的第一角色和第一对象定义是否满足目标实例(步骤734)。步骤734与步骤722类似，但是其仅仅根据第一角色和第一对象定义而执行；在步骤734中不存在第二角色和第二对象定义，所以仅仅考虑第一角色和第一对象定义。如果该第一角色或者第一对象定义与目标实例不匹配，那么匹配计数变量就设为零(步骤736)，并且处理700继续到图7C中的步骤726，其将在下面详细讨论。但是，如果约束条件的第一角色和第一对象定义与一个对象实例相匹配，那么处理700就进行到步骤728，在此步骤中评估该第一对象实例的所有的嵌套约束条件。现在讨论图7C的步骤726，进行检测该匹配计数的值是否最起码是一个最小值并且不大于一个最大值(步骤726)。这些最小值和最大值由约束条件指定，并且可以是任何值。如果匹配计数最起码是一个最小值并且不大于一个最大值，那么此约束条件返回真值(步骤738)。此为真的返回值也可以返回给评估其它的实例的过程。例如，当图7B的步骤728的一个嵌套约束条件评估为真，那么此真值可以返回给评估父节点的过程，用以在步骤730中作出确定。此为真的返回值也可以选择性地作为结果226的一部分返回给图2中的开发部件202。另外，所满足的(评估为真)约束条件的名称或其它的标识信息也可选择的返回给开发部件202。但是，如果匹配计数并不至少为最小数值或者大于最大数值(步骤726)，那么就检查是否要为这个约束条件产生一个错误信息(步骤740)。约束条件具有一个用来表示是否要为此约束条件返回一个错误信息的参数或设置。此参数或设置可以由例如约束条件的设计者或开发者设置。步骤740的检测可以通过检查此约束条件的参数或设置是否表示应该产生一个错误信息而执行。如果要产生此约束条件的错误消息，那么就产生一个错误消息(步骤742)。此错误信息可选择地包括以名称或其它可以帮助用户(例如设计者或开发者)识别产生错误的约束条件的特性的识别信息。然后向此约束条件返回为假的值(步骤744)。在步骤724中产生的为假的值和/或错误信息可以作为结果226的一部分返回给图2中的开发部件202。与步骤738中的为真的返回值相似，为假的返回值和/或错误消息可以返回给评估其他实例的过程。在步骤738中返回为真的值后，或者在步骤744返回为假的值，过程100返回图7A的步骤714从而检查是否有任何附加约束条件仍未选择。当返回到图7A的步骤704时，如果选择的约束条件是一个关系约束条件，那么就初始化一个匹配计数变量(图7D中的步骤746)。该匹配计数变量可以通过例如将此匹配计数变量设置为零来进行初始化。此约束条件的目标实例所参与的关系实例将被识别出来(步骤748)，并且识别出这些识别的关系实例的其中之一(步骤750)。然后检查此约束条件的关系定义和/或指向是否满足所选择的关系实例(步骤752)。关系定义指此关系的类型(例如，宿主、授权、通信等等)，并且方向是指角色或关系的方向(例如，此关系是否指向一个宿主关系中的主机或客机)。如果此约束条件的关系定义和指向关系定义和所选择的关系实例的方向相同，那么此关系定义和约束条件的方向就与标识的关系实例相匹配。如果此约束条件的关系定义和指向与选择的关系实例不匹配，那么就检查是否存在在步骤748中附加的被标识了但还没有被选择的关系(步骤754)。如果存在一个和多个这样的附加的关系，那么处理700就返回到750选择一个还没有被选择的附加关系。但是，如果不存在此附加标识的关系，那么处理700就前进到图7E中的步骤756，将在下面详细讨论。返回到步骤752，如果此约束条件的关系定义和指向确实与选择的关系实例相匹配，那么就检查在此约束条件中是否存在目标对象定义(步骤758)。目标对象定义在一个约束关系中是可选择的，并且指的是被评估的关系实例的相对一方的对象实例。例如，如果该关系实例是一个宿主关系，并且目标对象实例是主机，那么此宿主关系的相对一方的对象实例就是客机实例。如果在约束条件中存在目标实例，那么就检查此约束条件的目标对象实例是否与此关系实例的相对一方的实例相匹配(步骤760)。如果此约束条件中的目标关系定义和此关系实例的相对一方的的实例相同，那么此约束条件中的目标对象定义就与此关系实例的相对一方的实例相匹配。如果约束条件中的目标对象定义与此关系实例的相对一方的实例不匹配，那么处理700就前进到步骤754，检查是否存在任何附加标识关系仍未被选择。但是，如果约束条件中的目标对象定义与此关系实例的相对一方的实例相匹配，或者如果在此约束定义中不存在目标对象定义，那么处理700就进一步评估此关系实例的所有的嵌套约束条件(图7E中的步骤762)。然后处理700根据是否所有的嵌套约束条件都评估为真(步骤764)继续进行。步骤762和764的评估和检查与图7B的步骤728和730的评估和检查是类似。如果并不是所有的嵌套约束条件都评估为真，那么处理700就返回到图7D步骤754，检查是否存在任何附加标识关系仍未被选择。但是，如果所有的嵌套约束条件都评估为真，那么匹配计数变量就增加(步骤766)。匹配计数变量被增加不同的数量，例如加1。然后处理700返回到图7D的步骤754，检查还存在任何附加标识关系仍未被选择。然后检查匹配计数值是否最起码是最小数值并且不大于最大数值(步骤756)，其与图7C中的步骤726相似。如果匹配计数值最起码是最小数值并且不大于最大数值，那么就返回一个真值(步骤768)，其与图7C中的步骤738相似。但是如果匹配计数值并非是最起码的最小数值或者大于最大数值，那么就检查是否要为此约束条件产生一个错误(步骤770)，其与图7C中的步骤740相似。如果要产生一个错误，那么就产生一个错误(步骤722)，其与图7C中的步骤742相似。当产生了一个错误消息时，或者无错误消息产生时，那么就返回一个为假的值(步骤774)，其与图7C的步骤744相似。另外，应当注意的是约束条件的检查也可以进行成组的约束条件的检查。为了评估一组约束条件，利用处理700独立地评估每个约束条件，并且该组的结果依赖于单独的约束条件的评估的结果。在某些实施例中，如果该组中的至少一个实施例为真，那么，该组就评估为真。通过在处理700中向开发部件202返回表示成功的约束条件的验证(例如为真的值)或不成功的约束条件的验证(例如为假的值)，以及错误信息，在SDM文档204中描述的系统的设计期间的验证的结果就返回给开发部件202。这些指示和/或错误信息可以利用开发部件202显示给设计者，用以允许通知设计者正在设计的系统(并且在SDM文档204中描述)是否已经被验证，或者是否存在潜在的错误。通过返回错误信息，设计者被更好的通知了潜在的错误是什么以及如果去解决它们。此反馈可以在设计期间提交给设计者，而不需要设计者在找到设计好的系统的错误之前，将此系统配置在一个数据中心上。错误执行的例子此部分说明了一个图2的验证部件208如何报告错误以及警告的执行的例子。错误和警告可以是任何形式的，例如此部分讨论的XML格式的例子。如果通过CLR(公用语言运行期间)期间使用验证部件，那么将返回带有与此部分讨论的XML格式等同的信息的类。此部分标识了与一类错误相同的值。但是其并不排除其它的值。在类型空间验证期间(语法分析和解析错误)发生的错误阻止编译的SDM文档的全部写出。但是在实例空间验证期间(信息流和约束条件错误)发生的错误将不会阻止编译的SDM文档的全部写出。基本的错误格式基本的错误包括对于所有的错误通用的错误信息。用于此基本错误格式的XML格式的例子是<xscomplexTypename＝″DocumentError″><xsattributename＝″category″type＝″Severity″use＝″required″/><xsattributename＝″code″type＝″xsstring″use＝″required″/><xsattributename＝″description″type＝″xsstring″use＝″required″/><xsattributename＝″sdmFile″type＝″xsstring″use＝″required″/></xscomplexType>下表表述了基本错误的格式的属性或者元素。语法分析错误在试图加载SDM文档的失败导致了语法分析错误。此错误包括行号和列号。用于此语法分析错误格式的XML格式的实例是<xscomplexTypename＝″DocumentParseError″><xscomplexContent><xsextensionbase＝″DocumentError″><xsattributename＝″lineNumber″type″xsint″/><xsattributename＝″columnNumber″type-″xsint″/></xsextension></xscomplexContent></xscomplexType>下表将描述语法分析错误格式的属性或元素。解析错误加载文件和解析文件类型的失败会导致解析错误。这类错误包括解析导入失败，解析类型、成员和路径失败。在此阶段，存在一全面分析对象模型，所以依据此对象模型而不是文件中的行号和列号来引用产生一错误的部分。用于解析错误格式的XMI格式的实例是<xscomplexTypename＝″DocumentResolutionError″><xscomplexContent><xsextensionbase＝″DocumentError″><xsattributename＝″statement″type＝″documentPath″/></xsextension></xscomplexContent></xscomplexType>下表描述了解析错误的属性或元素。信息流错误当执行信息流并为一个或多个输入或输出返回错误的时候发生信息流错误。识别出信息流成员，目的设置成员的错误发生类型和上下文包括当前组的输入和输出值。用于信息流错误格式的XML格式的实例是<xscomplexTypename＝″DocumentFlowError″><xscomplexContent><xsextensionbase＝″DocumentError″><xssequence><xselementname＝″inputValue″type＝″flowlnput″minOccurs＝″0″maxOccurs＝″unbounded″/><xselementname＝″outputValue″type-″fiowOutput″minOccurs＝″0″maxOccurs＝′unbounded″/></xssequence><xsattributename＝″flowType″typc″documentPath″/><xsattributename＝″flowMember″type″documentPath″/><xsattributename＝″memberContext″type＝″containmentPath″/><xsattributename＝″flowErrorlD″type＝″xsint″/></xsextension></xscomplexContent></xscomplexType>下表描述了信息流错误的属性或元素。用于信息流输入格式的说明的XML格式的实例是<xscomplexTypename＝″flowlnput″><xssequence><xselementname＝″value″type＝″xsanyType″minOccurs＝″0″/></xssequence><xsattributename＝″setting″type＝″sdmsimpleName″/><xsattributename＝″source″type＝″documentPath″/></xscomplexType>下表描述了信息流输入格式的说明的属性或元素。用于信息流输出格式说明的XML格式的实例是<xscomplexTypename＝″flowOutput″><xssequence><xselementname＝″value″type＝″xsanyType″minOccurs＝″0″/></xssequence><xsattributename＝″setting″type＝″sdmsimpleName″/><xsattributename＝′destination″type＝″documentPath″/></xscomplexType>下表中描述了信息流输出格式的说明的属性或元素。约束条件错误当评估一个设置的约束条件时产生一约束条件错误，当防护装置未执行其基数约束条件，或者约束条件组的至少一个成员没有被评估为真时，返回一错误。当一个设定约束条件失败时，返回包括约束条件类型、该约束条件执行的上下文以及该约束条件的输入值的设置的约束条件成员的说明。约束条件也可以返回一个客户错误id，其随后可以用于查找附加的错误信息。用于这样的约束条件错误格式的XML格式的实例是<xscomplexContent><xsextensionbase＝″Docun～entError″><xssequence><xselementname＝″inputValue″type＝″constraintlnput″/></xssequence><xsattributename＝″constraintMember″type＝″documentPath″/><xsattributename＝″constraintType″type＝″docmnentPath″/><xsattributename＝″memberContext″type＝″containmentPath″/><xsattributename＝″constraintErrorlD″type＝″xsint″/></xsextension></xscomplexContent></xscomplexType>下表描述了此约束条件错误格式的属性或元素。用于一个约束条件输入格式的描述的XML格式的实例是<xscomplexTypename-″constraintlnput″><xssequence><xselementname＝″value″type＝″xsanyType″/></xssequence><xsattributename＝″setting″type＝″sdmsimpleName″/><xsattributename＝″source″type＝″documentPath″/></xscomplexType>下表描述了约束条件输入格式的说明的属性或元素。当防护装置或组失败时，识别约束条件成员以及该成员的上下文和评估的上下文关系。当约束条件上下文关系识别评估该嵌套约束条件所对照的类型和关系时，该评估上下文关系不同于嵌套约束条件的成员上下文关系。用于这样的约束条件错误格式的XML格式的实例是<xscomplexTypename-″constraintGuardOrGroupError″><xsattributename＝″constraintMember″type＝″docmnentPath″/><xsattributename＝″evaluationContext″type＝″containmentPath″/><xsattributename＝″memberContext″type＝″containmentPath″/></xscomplexType>下表描述了约束条件错误格式的属性或元素。文档路径这是一个在SDM文档内到达一个特定SDM元素的路径。用于文档路径格式的XML格式的实例是<xssimplcTypename＝″documentPath″><xsrestrictionbase＝″xsstring″></xsrestriction></xssimpleType>此路径一般具有格式namespace/root_type(/nested_type)*/member(/nested_member)*将关系和约束条件的公知设置作为嵌套成员。包含路径包含路径识别了从根到一特定成员的一成员序列。包含路径穿过了许多成员，从根模拟组件通过它们的成员等直到产生此错误的成员，以此来定位此路径。用于文档路径格式的XML格式的实例是<xssimpleTypename＝″containmentPath″><xsrestrictionbase＝″xsstring″></xsrestriction></xssimpleType>此路径一般具有格式Namespace/rootType(/nested_type)*member(/nested_member)*实例错误编译器返回来自编译中的将显示给用户的错误和警告。在一个SDM文档的编译过程中所遇到的错误可以具有不同的严重等级。大多数的错误是致命的，但是也存在某些错误，其可能导致其它错误或者当其被忽略时是安全的。关于每个等级的安全性的实例细节如下。错误此类错误是致命的，并且具有下面的含义·不能在编译中创建一输出sdm文件(.sdmDocument)·错误会导致编译器完成编译的当前阶段然后终止。例如，如果出现一个XML语法分析错误，那么就不加载文档。如果出现加载错误，就会发现更多的加载错误，但是不会继续进行信息流和约束条件的检查。警告1(W1)警告不妨碍编译SDM文档。警告1的原则包括·可能会导致在编译的将来阶段中的错误。例如，如果一个引用的文件没有找到，如果从那个引用中使用所有的类型，那么在加载该目标SDM文件时会出现错误。·在模拟实例空间期间的错误。警告2(W2)警告2是最不严重的错误。例如，在XML文件中找到额外的属性。警告2的原则是·忽略警告2是安全的·为了清理SDM，建议进行修补。警告3(W3)警告3是一个信息消息。·警告3是信息性的。·默认的，这些警告不被报告下表列出了可能会由图2中的验证部件208报告的错误的例子。独立的表格用于表示一般编译器错误、文档加载错误、定义空间校验错误、信息流错误以及约束条件错误的实例。这些错误的描述和它们的级别都包括在下表中。也标识了每个错误的格式(例如，错误(基本错误)的格式、语法分析格式、解析格式、信息流格式以及约束条件格式)。一般编译器错误文档加载错误定义空间校验错误信息流错误约束条件错误SDM实施的例子下面是SDM的实施的一个例子。此SDM实施的例子包括定义部分(第1部分)、体系结构综述部分(第2部分)以及实施细节部分(第3部分)。应当理解的是，在此实施的例子中描述了各种的特定值和必要条件，并且并不是所有的实施都限定于这些特定的值和必要条件。1定义2体系结构综述系统定义模型(SDM)支持连接的系统的单元之间的配置和相互关系的描述，我们称此系统为模型化系统。SDM基于一个对象关系模型。利用对象描述存在于该模型化的系统中的元素，并且利用关系指定它们之间的联系。SDM进一步定义了对象和关系，其用来获得对SDM很重要的语义。特别地，我们将对象分为系统、端点以及资源，并且将关系分为通信、包含、宿主、授权和引用。我们利用抽象对象定义提供了系统部件的通用分类，其允许对大范围的应用程序提供了工具支持，并为设计期间的类型检查提供了基础。我们期望抽象定义组为系统设计提供全面的技术，并且我们期望它们会随着时间慢慢地改变。然后我们利用此抽象的定义作为限定具体定义的基础，该具体定义表示实际应用程序和数据中心的设计的一部分。我们采用一个抽象定义，并且提供定义具体类型的成员的实施，并且为它的属性设定值。然后根据这些定义的集合创建系统。约束条件用于模拟允许的关系组上的限定条件，其中实例可以参与到该关系组中。我们利用约束条件获得精细的必要条件，该必要条件依靠包含在一个关系中的对象的配置。例如，一个约束条件可用于验证一通信协议的每一端点上的参与者是否使用兼容的安全设置。为了实现目标系统上的改变，可以使用一个需要的改变的说明性的描述，其被称为变更请求。SDM定义的用于扩展的过程将变更请求作为SDM执行模块的一部分进行验证和执行。实例空间获得被管理的应用程序的需要的和当前的状态。我们可以跟踪实例空间中的变化并将它们与初始化变更的变更请求相联系。管理器既用于提供专用的行为也用于支持运行期间和模型化系统之间的交互作用。2.1对象对象用于表示模型化的系统的逻辑和物理方面。例如，它们可以用于表示IIS中的文件、路径并配置。它们也可以用于表示一个应用程序或分布式系统的界限。我们将对象分为三类。每一类表示了模型化的系统的一个方面，其每一个都将被揭示并被理解为SDM模块本身的一部分，而不是特定模型实例的属性或强制继承结构。2.2.1资源资源表示可以被组合创建一个系统模块的行为的基础单元。资源可以用于与其它的资源组合在一起，以增加系统模块的结构。每个资源表明对于其它资源的依赖性，该其它资源是为了进行模型化行为所需要的资源。为了创建一个资源的实例，要为该系统标识出主机环境。资源的实例包括作为操作系统的一部分的文件、路径、登记关键字以及值、作为IIS和表格的一部分的web路径和web文件，作为数据库的一部分的行和所存储的过程。2.1.2系统系统既用于表示执行一适当限定的任务的资源的集合，也用于表示交互执行一适当限定的任务的系统的集合。一个系统范围内的资源不能依赖该范围之外的资源。同时，我们也不需要资源来证明与同一系统范围内的其它资源进行通信的机构。这意味着在系统间交互作用必须利用通信关系显式模型化。这也表明在一般的系统中该装置是配置的最小单元，如果它们独立地使用，我们不能保证它们会工作。系统的例子包括操作系统、宿主在IIS上的web应用程序以及被SQL宿主的数据库。2.1.3端点端点用于定义使系统支持与其它系统的通信的接口。由于我们不允许资源具有跨系统范围的依赖性，所以端点必须用于模拟允许系统正确操作所请求的交互作用。端点的实例包括Http、Tcpip以及Soap端点。2.2关系我们利用关系获得对象之间的交互作用的各个方面。所有的关系都是二元的和有方向的。除了获得对象之间的交互作用，关系还可以在参与该关系的对象上设置约束条件，并且可以在参与者之间传递配置信息。同样，为了要在这些关系上添加特定的语义，我们标识了一组可以被SDM模型所理解的关系。这就允许我们推导出模型系统的运行期间的状态。特别的，需要描述的特定对象实例的情况是a)它的生命期b)谁可以与它交互c)它位于系统结构的什么位置d)它与谁通信e)它依靠谁进行它的工作f)它在什么环境中执行g)它是否可以正确、可靠地操作我们也利用关系来定义应用程序的允许的结构。这些情况包括a)另一个对象可以包括哪些对象b)哪些端点可以连接起来c)什么样的环境可以宿主一个特定的对象以下的每个关系都可获得上述一个或多个情况的一部分。2.2.1包含包含关系用于定义SDM模型的包含结构。包含关系的存在用于表明一个对象可以包含另一个对象。在设计期间使用这个信息是为了当它将如何与系统、资源和端点相联系的选项提供给设计者或体系结构设计师的时候可以指导设计环境。定义包含关系是为了限制一个SDM模型的结构。例如，体系结构设计师可以设计一个包含网络目录、文件系统目录和文件的网络b应用程序模型。另一个体系结构设计师可以扩展该模型以允许它包含网络站点。通过理解这些模型的基础结构，操作者和工具创建者可以推导出模型实例需要什么样的环境以及特定的模型在其所配置的系统上会产生什么影响。例如，在上面定义的第一个模型中，操作者提供了一个网络站点来使配置应用程序。包含关系定义可一个对象的生命期、对象的所有者以及对象出现在模型化的系统结构的什么位置。如果一个对象仅仅具有一个父包含者，那么该父体的生命期就限定了该包含的对象的生命期。父体拥有被包含的对象。这意味着父体具有对象可见性的控制权，并且可以决定是否将对象或者该对象一部分展示给它的母源。最后，父体为对象提供了上下文信息。此上下文信息可以用于帮助开发者与其它的开发者或者应用程序的用户就他们的应用程序的结构进行交流。例如，在一个运行的应用程序中定位错误的时候，包含链可以提供大量的详细表示应用程序失败的部分的上下文信息。包含关系的使用包括表示一个网络应用程序的虚拟目录的结构以及该网络应用程序配置的文件和目录的结构。包含也可以用于描述网络应用程序和是其一部分的连接的系统模型之间的关系。2.2.2宿主宿主关系用于模型化已模拟化的环境的包含结构。此关系获得环境的功能性的限定。例如，文件必须被包含在一个目录或者一个网络目录中的限定必须包含在一个网络站点中。宿主关系定义了一个对象的生命期和它所要执行的环境。为了存在，一个对象必须具有至少一个宿主。这就意味着宿主的生命期限定了该对象的生命期，并且如果宿主被标记为脱机，那么此对象也被标记为脱机。宿主关系负责一个在宿主限定的环境中的对象实例的创建和维护。这种方式就使该关系担负起在一个宿主上创建客户的实例的责任，而不是该客户也不是该宿主。通过提供一定范围的宿主关系，一个客机可以被多个主机环境支持。宿主关系的存在表明在一个主机对象上放置一个客机对象是可能的。对于一个包含了许多宿主在另一个系统上的资源的系统来说，此客机系统中的所有的资源都与主机系统中的至少一个资源具有宿主关系。2.2.3通信通信关系用于模型化在连接系统中的子系统之间的通信。由于它们被表示在端点对象之间，所以它们仅仅被设置在具有端点的系统之间。如果一个系统包含也具有端点的嵌套系统，那么通过已被内部系统端点依次授权的位于外部系统上的代理端点揭示了这些端点。如果一组端点之间不存在通信关系，那么就不能在这些端点之间建立连接。如果一个系统被标记为脱机，那么该系统的所有客机都被更新，用以反映该系统不能使用的事实。通过基于该系统的通信关系传播该改变，实现此更新。2.2.4引用引用关系用于获得正确的操作所需的资源或系统间的从属关系，但是其并不认为是从属对象的执行环境的一部分。例如，为了向网络服务的用户提供一个网络内容，网络目录需要对本地目录或者远程共享的引用。这就被表示为网络目录与本地目录或远程共享之间的从属关系。2.2.5授权授权关系用于将代理的交互作用传递给一个对象实例，该对象实例执行由该代理指示的行为。一般使用授权是从一个父系统的端点向一个被包含的系统的端点传送通信关系。2.3定义对象和关系定义用于创建可重复使用的配置，该配置可以被例示为创建该配置的实例。然后这些实例共享由该定义指定的公共特性。抽象定义由于它不完善，所有不能被直接例示。为了完善它，另一定义要扩展它，用以添加丢失元素。利用抽象的定义创建在建立一个实体系统的模型时要用到的建立块。抽象定义间的关系限定了扩展该抽象定义的定义的允许的结构。这就允许设计界面使用抽象定义，定义界面的用户可以执行的动作。例如，一个网络应用程序参与的包含关系指导了扩展该抽象定义的网络应用程序的结构。本质上，抽象对象定义和关系定义的组合限定了模型化目标系统的模式。具体对象定义的角色是，根据一个或多个抽象定义，利用抽象定义空间的一个子集创建一个可重复使用的配置。作一个简单的推理，抽象定义空间可以与数据库的规划相比较；具体对象定义空间表示了在数据库中的一组行的可重复使用的模板。当创建具体对象的实例时，在数据库中仅仅创建这些行。为了执行设计期间的验证，我们可以相对于抽象定义空间验证一个具体对象定义，同样的方式，我们可以相对于规划的约束条件(例如外国关键字等)验证数据库中的这些行。设置定义用于创建简单的值元素。这些值元素可以用于存储配置信息。2.4成员一个定义可以包括引用其它定义的成员。成员可以以定制特定的应用程序的方式，允许一个定义重新使用另一个定义。设置成员用于识别与定义有关的配置信息。设置成员以设置定义为基础。对象成员用于创建一个特定对象定义的实例。设置信息流可以用于提供对象的值。当说明一个对象成员时，用户可以决定对象成员是否与外部系统(值语义)同时创建，或者对象成员是否由一个随后将发生的明确的新操作创建(引用语义)。关系成员限定了创建对象成员时其所参与的关系。如果一个对象不禁暗被其母源包含，那么将说明该成员和包含定义之间的包含关系成员。如果一个对象成员被授权，那么将在对象成员和源对象成员之间限定授权关系成员。可以在通信的端点之间说明通信关系成员。可以在从属物和源对象成员之间说明从属关系成员(引用和宿主)。约束成语用于缩小特定对象将要参与的关系组或者参与到一个特定的关系中的对象组。它们标识了一个对象或者关系上的约束条件，该约束条件可以指向该对象或者关系的设置，或者约束了与该对象或关系相关的交互作用。信息流成员用于限定成员间的配置的信息流。它们从成员的设置中收集数据值，根据这些信息执行某西处理，然后向这些成员的设置分发结果。2.5实例实例空间反映了模拟系统的当前状态。保存了已经创建的实例和这些实例之间的关系的完整的记录。每个实例具有一个相关的版本历史，其中每个版本都与一个变更请求相关联。变更请求初始化创建新实例的过程。此变更请求定义了与一现有实例的特定成员的类型和关系相关的一组创建、更新和删除请求；根是一特殊情况。此变更请求在运行期间扩展，相对于所有约束条件校正，然后构建。扩展过程将隐含构建的对象和关系实例识别为包含对象的构建请求的一部分，然后通过所有关系来求设置信息流的值。识别步骤检查所有请求关系是存在的以及此关系实现所有约束条件。最后，构建过程确定每个实例的调度、更新和删除的适当顺序，然后以正确顺序将每个实例传递给一实例管理器从而执行适当操作。2.6对象模型以下uml图取得了SDM模型对象之间的主要交互作用。简而言之，在基本类型之间定义了这些相互作用中的一部分，其中导出类型之间存在实际交互作用，因而其更特殊。SDM文档包含描述以下内容的信息文档、文档中定义的管理器、引用其他文档的导入语句以及一组由该文档所描述的对象和关系的定义。许多SDM元素也可以包含设计数据，允许设计表面由设计表面内元素显示和制造产生具有特定信息的SDM元素。图8描述了一示例性的SDM文档。从如图9的一公用基本定义派生出所有SDM定义。定义可包含一描述、一组成员、一组设置值和设计数据。我们将定义分为对象、关系、约束条件、信息流和设置定义。对象定义进一步分为系统、资源和端点定义。关系定义进一步分为宿主、通信、授权、参考和包含定义。成员用于将一名称与一特殊实例或如图10所示的多组实例相关。所有成员涉及一定义。每个成员可包含一组设置值、一描述和设计数据。成员可基于它们参考的定义种类来划分。信息流和约束成员增加了限定输入的能力，该其从包含定义范围内的设置成员获得源设置值。信息流成员也增加了输出，此输出允许将所处理的信息流值传给包含定义内的设置成员。一示例性的设置成员如图11所示。设置值涉及一设置定义，该设置定义表示一复杂或简单的设置定义。一复杂设置定义可包含嵌套设置成员。一简单定义限定了一单值域。输入和输出对象用于定义了在设置成员之间的设置值的传送。一示例性的约束条件定义如图12所示。约束条件用于限制设置值和SDM模型结构的限制条件。一约束条件定义标定于一特殊对象或关系定义。此约束条件定义可对对象参与的关系或参与一关系的对象设置结构约束条件。此结构约束条件也可以直接加到该对象或关系定义中。描述对象用于提供SDM元素的自然语言描述，如图13所示。这些元素可响应管理器而定位。设计数据元素包含由编辑SDM文档的设计表面定义的结构化数据。2.7分层SDM文档的目的是允许区分应用程序的开发者、软件基础结构的设计者以及数据中心体系结构设计者之间的关注点。这些组中每一个着重于特殊服务且具有一组各不相同的相关性。例如，开发者主要关注依靠诸如SQL、IIS和CLR的主机的配置及其之间的联系。主机配置的设计者关注网络拓扑结构和OS配置，而开发网络结构、OS配置和存储映射的体系结构设计者需要知道数据中心的硬件。为支持关注点区分，SDM揭示了分层的概念。利用宿主关系可实现分层。通过定义操作系统、诸如sql的宿主以及sql提供的例如数据库的服务之间的宿主关系，就允许应用开发者定义包含数据库的应用应用程序，而允许体系结构设计者定义包含SQL宿主的系统。通过连接宿主系统和客户系统之间的宿主关系，将分层合并这些分离的系统。层边界可以是任何存在宿主关系的地方。为简化设置层边界的选择，我们定义了四个基本层作为SDM模型的部分。然后将系统与其中一层相联系。此四个层为应用程序层·此应用程序层支持约束环境的应用程序结构。由主机层中标识的主机配置定义此环境。·应用程序层中的系统定义的例子包括网络服务、数据库和新闻组对话时间表。宿主层·在软件部件外部构建数据中心。配置部件之间的连接。一些部件作为应用层的宿主。·在此层中系统定义的例子——IIS、SQL、AD、EXCHANGE、DNS和Biztalk。网络/OS/存储器层·建立数据中心网络和平台。配置网络安全模型和操作系统平台配置。将存储器加入操作系统配置。·在此层中的系统定义的例子一VLAN、Windows、滤波器、存储器硬件层此硬件层识别数据中心中的机器类型以及这些机器之间的物理连接。图14表示层4网络应用程序映射到层3网络服务器主机的例子。每层的外方框代表一系统，在边缘上的方框代表端点而在内部的方框代表资源。通过宿主关系将每个元素映射到下层主机上。3实施细节3.1命名在SDM中有很多地方需要一强大的命名系统来识别对象。以下命名系统允许SDM文档的创建者以以下方式标记文档用户能确信此文档的定义与开发者原始公布的相同。以下是用于SDM文档识别器的例子<SystemDefinitionModelName＝″System.OperatingSystem.FileSystem″Version＝″0.1.0.0″DocumentLanguage＝″en″Xmlns＝http//schemas.microsoft.com/SystemDefinitionModel/2003/10″Version＝″0.1.0.0″PublicKeyToken＝″AAAABBBBCCCCDDDD″Culture＝″neutral″Platform＝″neutral″></SystemDefinitionModel>为了引用在另一个名称空间中的一类型，要导入此名称空间<lmportAlias＝″FileSystem″Name＝″System.OperatingSystem.FileSystem″Version＝″0.1.0.0″/>然后可以利用别名引用名称空间内的定义FileSystemFile3.1.1身份SDM名称被定义在它们的名称空间的范围内。名称空间通过名称、版本和一公钥令牌来识别且包含在一单个文件中。身份的基本形式包括名称、版本、文化、平台和一公钥令牌。<xsattributeGroupname＝″ldentiy″><xsattributename＝″Name″type＝″Path″use＝″required″/><xsattributename＝″Version″type＝″FourPartVersionType″use＝″required″/><xsattributename＝″PublicKeyToken″type＝″PublicKeyTokenType″use＝″optional″/><xsattributename＝″Culture″type＝″CultureNeutral″use＝″optional″/><xsattributename＝″Platform″type＝″xsstring″use＝″optional″/></xsattributeGroup>基本身份可结合一签名和一公钥使用，用以创建被称为名称空间身份的新的强大的身份。此身份用于识别一SDM文档。为创建此身份，利用私钥对此文档进行标记，从而允许文档用户利用公钥校验其上下文。公钥令牌是识别一公钥/私钥对的公共部分的16进制字符串。它不是公钥；它只是公钥的64位混编信息。<xssimpleTypename＝″PublicKeyTokenType″><xsrestrictionbase＝″xsstring″><xspatternvalue＝″(|[a-f]|[A-F]){16}″></xsrestriction></xssimpleType>利用一文化标识符指定文档语言，此文化标识符包含定义语言的两个小写字母和定义国家或区域的两个或三个大写字母。<xssimpleTypename＝″Culture″><xsrestrictionbase＝″xsstring″><xspatternvalue＝″[a-z]{2}((-[A-Z]{2})？|(-[A-Z]{3})？)″></xsrestriction></xssimpleType><xssimpleTypename＝″CultureNeutral″><xsunionmemberTypes＝″Culture″><xssimpleType><xsrestrictionbase＝″xsstring″><xsenumerationvalue＝″neutral″/></xsrestriction></xssimpleType></xsunion></xssimpleType>3.1.2版本文件版本由N.N.N.N形式的四部分数字来定义，其中0＜＝N＜65535。按照惯例，数字参考主.次.建立.修正。版本号标识文档所包含的所有定义的版本。这意味着当文档中所有的定义一起升级时，此文档成为版本单元。<xssHnpleTypename＝″FourPartVersionType″><xsrestrictionbase＝″xsstring″><xspatternvalue＝″({1，4}|{4}|64{3}|655|6553[0-5))(\.({1，4}|{4}|64{3}|655|6553)){3}7></xsrestriction></xssimpleType>3.13简名简名是由字母-数字字符和有限的标点符号组成。此名称以非数字字符开始。<xssimpleTypename＝″SimpieName″><xsrestrictionbase＝″xsstring″><xspattemvalue＝″[a-z，A-Z，J{1}(<simpleName>(.<simpleName>)*([<别名>]<简名>(.<简名>)*)在导入语句内定义简名。<xssimpleTypename＝″QualifiedName″><xsrestrictionbase＝″xsstring″><xspatternvalue＝″[a-z，A-Z，_]{1}()*([a-z，A-Z，_]{1}()*)？(\.[a-z.A-Z，_]{1}()*)*″/></xsrestriction></xssimpleType>3.1.7名称辖区定义的名称由它们在其中定义的上下文来确定辖区。最主要辖区是文档。假如一定义被嵌套，那么它的名称由此定义确定辖区。这意味着在其父辖区内可隐藏名称。也意味着对一个在其定义辖区之外的定义的引用可以由其父辖区的名称限定。一完全限定名称包括从文档根到嵌套定义的所有名称。3.1.8成员路径成员路径是一名称序列，该名称序列相应于定义所通过的成员。路径应以一成员名称开始，此成员名称定义在声明此路径的上下文中。一些成员名称被自动加入一定义。我们称之为公知名称。公知名称的例子包括在一定义或引用声明中的“这个”、在一宿主关系声明中的“宿主”和“客户”、或在一约束声明中定义的“目标”。此设置目标也标识对相关信息流定义的设置，此设置将用作由路径标识的设置的源值或目的设置成员名称以点分隔。<simpleName>(.<simpleName>)*(<简名>(.<简名>)*)<xssimpleTypename＝″Path″><xsrestrictionbase＝″xsstringH><xspatternvalue＝″[a-z，A-Z]{1}()*(\.[a-z，A-Z]{1}()*)*″/></xsrestriction></xssimpleType>3.1.9实例路径实例空间中的路径基于xpath，其中在xpath中的元素名称对应于成员名称，且在xpath中的属性对应于设置。3.1.10签名为了提供一个验证文档内容并将一强大名称与文档相关联的机制，利用一密钥标记一已编译SDM文档。此签名机制利用DSIG标准(http//www.w3.org/2000/09/xmldsig#)来标记文档。在一标记文档中嵌入一个与以下描述类似的签名节点。<Signaturexmlns＝″http//www.w3.org/2000/09/xmldsig#″><Signedlnfo><CanonicalizationMethodAlgorithm＝″http//www.w3.org/TR/2001/REC-xml-c14n-20010315″/><SignatureMethodAlgorithm＝http//vww.w3.org/2000/09/xmldsig#rsa-shal″/><ReferenceURI＝″″><Transforms><TransformAlgorithm＝″http//www.w3.org/TR/2001/REC-xml-c14n-20010315″/><TransformAlgorithm＝″http//www.w3.org/2000/09/xmldsig#enveloped-signature″/></Transforms><DigestMethodAlgorithm＝″http//www.w3.org/2000/09/xmldsig#shal″/><DigestValue>Dn9BN6rKnnzzgGxaWI3j0aW8/1g＝</DigestValue></Reference></Signedlnfo><SignatureValue>JaNLAktv2+n4Xz3p0jM8zqwmUc8T91AOtwasKOVBwHgvYAGijRFI0U1kcVfHbDJoi8ln33prnS5ITNj46rGYRn/UK11vjvpprfgz2a+QI7G4o7hBwO0SZzLLPO7/y7+Gkw0Cr6zaoDmOFSdP8IAATuVJC40pZhbDmcmHJduaXm0＝</SignatureValue><Keylnfo><KeyValuexmlns＝″http//www.w3.org/2000/09/xmidsig#″><RSAKeyValue><Modulus>wxxlCIOui6J77CZcnzLOcBBxl/3uuFrUBEyFivVklRtTTzQpgirdaNouQ9ziCAK6aipeM6RjgYAoDPs/iWFnrHmtDoxgP2H4/W9lttXO5EjQDb76XAZRPSvthJYtreKEGE0d6L6iTRdg25hYGFkyY/Ys0s0ONh3+5VO0Wxq+Fx0＝</Modulus><Exponent>AQAB</Exponent></RSAKeyValue></KeyValue></Keylnfo></Signature>此结点是文档的一根结点，其应该文档的任何其他内容之前产生。我们利用“any”(“任何”)标记来声明此元素，但我们在此位置上只承认并处理一“Signature”(“签名”)结点。<xsanynamespace＝″http//www.w3.org/2000/09/xmldsig#″processContents＝″skip″minOccurs＝″0″/>3.1.11定义、引用和解析名称空间的名称在此部分，描述了匹配一引用特定名称空间的名称空间所用到的的处理。如3.1.1部分所定义的，一名称空间身份包括五属性·Simplename简名·PublickeyToken公钥令牌·Version版本·Language语言·Platform平台名称空间的客户利用这些属性识别所需的名称空间(名称空间引用)，名称空间的开发者用它来提供一名称空间的公知身份(名称空间定义)。依据这些属性是名称空间引用的一部分还是名称空间定义的一部分，每个属性可以有不同解释。3.1.11.1名称空间定义当一开发者希望创建并公布一新的名称空间时，此开发者·提供此名称空间的一个简名·提供此名称空间的一个版本此开发者可选地·以密钥标记名称空间·标识此名称空间的一个特定文化(默认为文化中立)·识别此名称空间的一个特定平台(默认为平台中立)假如未标记此名称空间，则无公钥令牌且此名称空间将具有一弱名称。可延迟标记一名称空间，从而允许开发者将标记处理和编译处理分开。一个已编译但未标记的延迟标记名称空间可在编译过程中引用但不能在运行期间使用。3.1.11.2名称空间引用当一客户在一SDM文件中引用(导入)一名称空间时，他们需要·提供所引用的名称空间的名称他们可选地可以提供其它信息，包括·引用的名称空间的公钥令牌·引用的名称空间的最低版本·引用的名称空间的文化或一通配符(*)·引用的名称空间的平台或一通配符(*)所有未提供的属性默认为一个匹配该属性的任何值的通配符。3.1.11.3将一引用与一定义匹配以下算法用于匹配引用一名称空间定义的名称空间。当编译一名称空间和解析所编译的名称空间之间的引用时，均可采用此算法。在编译和编译后的情况之间只有一个微小的不同在编译期间忽略名称空间的版本域，但在运行期间则必须给出。编译处理将更新名称空间引用，用以增加来自编译期间一引用所要被解析到的名称空间的其它信息。一般会添加名称空间的版本。假如不提供公钥令牌且此令牌在解析名称空间中存在，则将其加入到名称空间引用中。逻辑上，解析算法如下1、查找所有具有与引用中的名称相匹配的名称的名称空间。2、假如此引用提供一公钥令牌，那么只选择也与所提供的公钥令牌相匹配的名称空间。3、假如引用提供了一特定语言，那么删除与该语言不匹配的所有名称空间。假如此语言属性被设置为未提供的通配符，那么保持所有名称空间。4、假如提供了一特定平台，那么删除与此平台不匹配的所有名称空间。假如平台属性被设置为未提供的通配符，那么保持所有名称空间。5、然后利用版本策略，从此可能的名称空间组中选择一特殊名称空间。以下的部分更详细地定义了这些步骤3.1.11.3.1匹配名称空间名称匹配是一精确的字符串匹配。此名称区分大小写。3.1.11.3.2匹配公钥令牌令牌匹配为一精确匹配3.1.11.3.3匹配语言有三种语言匹配的情况1、引用＝*，定义＝特定语言。2、引用＝特定语言，定义＝*。3、引用＝特定语言，定义＝特定语言。在第一和第二情况下，定义与引用相匹配。在第三情况下，假如语言为精确匹配，则定义只与引用匹配。3.1.11.3.4匹配平台有三种平台匹配的情况1、引用＝*，定义＝特定平台。2、引用＝特定平台，定义＝*。3、引用＝特定平台，定义＝特定平台。在第一和第二情况下，定义与引用匹配。在第三情况下，假如语言为精确匹配，则定义只与引用匹配。3.1.11.3.5匹配版本版本匹配依赖于编译器或运行期间所使用的版本策略。3.2设置所有定义能公开设置值，这在XML模式中被称为设置声明。这些成员用于描述与此定义相关的配置值。利用SettingValue语句来提供值。这些被使用a)被定义使用，该定义声明将设置定义为默认值的设置成员。b)被一定义使用，该定义扩展另一定义用以提供此基本定义的默认或固定值。c)被成员使用，该成员引用一定义，并通过在引用此定义的成员处终止的成员路径使用。d)通过关系的信息流使用。为定义一设置，首先需要利用xsd定义此设置的定义。<SettingDefinitions><xsschematargetNamespace＝″System.OperatingSystem.Registry″xmlns＝″System.OperatingSystem.Registry″xmlnsxs＝″http//www.w3.org/2001/XMLSchema″><xssimpleTypename＝″PathType″><xsrestrictionbase＝″xsstring″/></xssimpieType><xssimpleTypename＝″RegistryValueType″><xsrestrictionbase＝″xsNMTOKEN″><xsenumerationvalue＝″binary″/><xsenumerationvalue＝″integer″/><xsenumerationValue＝″long″/><xsenumerationvalue＝″expandString″/><xsenumerationvalue＝″multiString″/><xsenumerationvalue＝″string″/></xsrestriction></xssimpleType></xsschema></SettingDefinitions>然后，可声明一个使用此定义并包括一组属性的设置，从而定义设置的状态。<SettingDeclarationName＝″Definition″Definition＝″RegistryValueType″Access＝″Readwrite″Required＝″true″/>一旦具有了一设置说明，就能为该设置提供一个值。<SettingValueName＝′Definition″Fixed＝″true″>long</SettingVaiue>3.2.1设置定义利用XSD模式定义设置成员所用到的设置定义。我们只支持使用一模式的简单和复杂类型，尽管存在可支持那些类型的定义的其他模式的元素。设置定义部分应该包含一完整的xml模式，其包括名称空间声明和名称空间导入。除xsd模式名称空间之外，我们将检查xsd模式中导入与SDM文件中导入的匹配。这意味着所有引用的类型应定义在另一SDM文件中；此模式不能引用定义在任意xsd文件中的类型。模式的目标名称空间必须与SDM文档的名称相匹配。当为保证名称空间名称的唯一性而标记文档时，会将文档的公钥加入到名称空间名称中。所以编译器将targetNamespace＝“System”改变为targetNamespace＝“System/AAAABBBBCCCCDDDD”。当一设置定义模式引用来自另一文档的名称空间时，它们将使用用完整的名称空间名xmlnssystem＝″System/AAAABBBBCCCCDDDD″<xscomplexTypename＝″SettingDefinitions″><xssequence><xsanynamespace＝″http//www.w3.org/2001/XMLSchema″/></xssequence><xsattributename＝″Manager″type＝″QualifiedName″use＝″optional″/><xsattributename＝″ClrNamespace″type＝″xsstring″use＝″optional″/></xscomplexType>设置可从三个独立的名称空间解析a)SDM名称空间——当涉及系统、资源、端点、关系、约束条件或信息流类型中设置类型时。b)clr名称空间——当涉及利用clrz中的强类型类的设置时并且当在其他设置类型上建立设置类型时。c)XSD名称空间——当利用其他设置类型建立设置类型时。为此，在设置声明中设置一些限制a)所有设置必须在每个clr、SDM和xsd名称空间的相同组内。也就是说，假如两个设置共同在一个名称空间内，那么它们必须共同在所有三个名称空间内。b)在一xsd模式定义中的导入名称空间必须与SDM文件中的导入名称空间以及相关帮助集合的导入名称空间相匹配。c)除xsd名称空间之外，在一xsd模式中的所有导入名称空间都必须定义在一个SDM文件中。来自导入的SDM文档的XSD类型可以利用Qname访问<alias><type-name>以下例子采用了上面所登记的例子中定义的类型。文档导入了所登记的包括设置定义的文档。<lmportAlias＝″Registry″Name＝″System.OperatingSystem.Registry″Version＝″0.1.0.0″PublicKeyToken＝″AAAABBBBCCCCDDDD″/>此设置定义模式也可引用Syetem.Operatinsyetem.registry(系统.操作系统.登记)名称空间。<SettingDefinitions><xsschematargetNamespace＝″http//DocumentExamples″xmlns＝″http//DociimentExamples″xmlnsreg＝″System.OperatingSystem.Registry/AAAABBBBCCCCDDDD″xmlns；xs＝″http//www.w3.org/2001/XMLSchema″><xssimpleTypename＝″UsesReg″><xsrestrictionbase＝″regRegistryValueType″><xsenumerationvalue＝″guid″/></xsrestriction></xssimpleType></xsschema></SettingDefinitions>3.2.2内部简单数据类型SDM支持有限组的作为XSD和C#名称空间交集的内部数据类型。SDM运行期间自然支持这些类型，并且这些类型定义如下表。除了这些类型，用户可以自由构建并使用他们自己的在xsd和els类型之间映射。这些类型可变为C#和xsd类型空间中的这些类型的兼容派生类型。例如，string(字符串)的值可变为定义了字符串限制的xsd类型，而且任何值可以传递给接受类型＝“any”的设置。3.2.2.1XSD嵌入式类型图15表示一个示例性的内部数据类型的分级结构。在图15中，所有复杂类型源自扩展或限制。NMTOKENS、IDREFS和ENTITIES类型源自列表。如图15所示的所有其他类型源自限制。3.2.2.2C#数据类型3.2.2.3所支持的变换xsd类型和els类型之间可以变换。指标对比。染料上染百分率测量及计算分别在85℃下染色60分钟后取出织物，且用蒸馏水洗涤三次，并收集残液和洗液，转移到250ml容量瓶中，冷却、定容。在相同条件下测其残液(A残)及原染液(A0)吸光度，采用UltraScanXE型测色配色仪(HunterLabLtd.，美国)测量、计算匀染性。按GB251～84≈ISO/A03-1978标准，分别对染色样品进行干湿摩擦牢度测试，并用彩色沾色样卡进行评级摩擦牢度。按GB250-84≈ISO105/A02-1982及GB250-84≈ISO105/A03-1982标准，评定其沾色和褪色牢度。表1表2由表1、2所示数据可以看到，经氩低温等离子体处理后，其练减率、织物白度、毛效，可与常规精练相当，并且精练织物的抗弯刚度有所提高。此3.2.3设置成员设置说明部分利用前面的设置定义来创建指定的设置。利用一个限定名称来引用xsd模式内的设置定义(假如设置定义在当前文档中则不需要)，此限定名称包括包含设置的文档的别名，和设置的名称。当参考一设置定义时我们没有采用xsd名称空间。属性用于进一步提供每个设置成员的参考信息。<xscomplexTypename＝″SettingMember″><xscomplexContent><xsextensionbase＝″Member″><xsattributename＝″List″type＝″xsboolean″/><xsattributeGroupref＝″SettingsAttributes″/></xsextension></xscomplexContent></xscomplexType>3.2.4列表支持为支持多值设置的操作，就要支持设置值的简单列表。一列表是与设置声明具有相同定义的值序列。列表可变换为其可替换或附加到的其他列表。当利用设置流可以更灵活地将值附加到一列表中时，就不支持副本检测，并且不确保任何形式的排序。一列表声明包括一个设置为真的属性列表<SettingDeclarationName＝″roles″Definition＝″String″List＝″true″/>利用settingValueList提供值。当提供此列表时，用户能指定是替换还是附加先前值。<SettingValuel_istPath＝″roles″Fixed＝″true″Replace＝″true″><Value>6taticContent</Value><Value>aspPages</Value></SettingValueList>SDM支持多列值的简单操作。当来自一信息流成员的路径指向一设置说明，那么其结果就依赖于路径两端的定义。3.2.5设置属性运行期间利用设置属性来描述一特殊设置的操作。<xsattributeGroupname＝″SettingsAttributes″><xsattributename＝″Access″><xssimpieType><xsrestrictionbase＝″xsstring″><xsenumerationvalue＝″Readwrite″/><xsenumerationvalue＝″Readonly″/><xsenumerationvalue＝″Writeonly″/></xsrestriction></xssimpleType></xsattribute><xsattributename＝″Secure″type＝″xsboolean″/><xsattributename＝″DeploymentTime″type＝″xsboolean″/><xsattributename＝″Dynamic″type-′xsboolean″/><xsattributename＝″Required″type＝″xsboolean″/><xsattributename＝″KeyValue″type＝″xsboolean″/><xsattributename＝″Nillable″type＝″xsboolean″/></xsattributeGroup>3.2.6设置值按照设置是被声明为单个值还是一列表，可利用一设置值元素或一设置值列表元素来提供此设置的值。3.2.6.1设置值设置值语句用于为一特殊设置声明明提供值。此值必须匹配与声明相关的定义，而此声明必须能够投射或被转换成与设置声明明相关的定义。假如此值被声明为固定，那么根据此值被固定的点，所提供的值将用于所有导出定义或引用成员。一旦此值被固定，则其不能被覆盖。<xscomplexTypename＝″SettingValue″mixed＝″true″><xssequence><xsanyprocessContents＝″skip″minOccurs＝″0″maxOccurs＝″unbounded″/></xssequence><xsattributename＝″Path″type＝″Path″use＝″required″/><xsattributename＝″Fixed″type＝″xsboolean″use＝″optional″/><xsattributename＝″Nil″type＝″xsbooiean″/><xsattributename＝″Definition″type＝″QualifiedName″use＝″optional″/></xscomplexType>3.2.6.2设置值列表一设置值列表用于提供用于以列表形式说明的设置的一或多值。当说明此值时，用户能决定合并先前值或覆盖所有先前值。<xscomplexTypename＝″SettingValueList″><xssequence><xselementname＝″Value″minOccurs＝″0″maxOccurs＝″unbounded″><xscomplexTypemixed＝″true″><xssequence><xsanyprocessContents＝″skip″minOccurs＝″0″maxOccurs＝″unbounded″/></xssequence></xscomplexType></xselement></xssequence><xsattributename＝″Path″type＝″SimpleName″use＝″required″/><xsattributename-′Fixed″type＝″xsboolean″use＝″optionai″/><xsattributename＝″Replace″type＝″xsboolean″use＝″optionar/><xsattributename＝″Definition″type＝″QualifiedName″use＝″optional″/></xscomplexType>3.2.7设置继承设置继承意思是导出定义隐含地包含来自基本定义的所有设置声明。设置继承的一些重要方面为设置继承是可传递的。假如C从B导出，且B从A导出，则C继承了B中声明的设置同时也继承了A中声明的设置。一导出定义可将新设置说明加入到从它所扩展的基本定义中所继承的设置说明中，但不能删除和改变所继承设置的定义。3.2.8设置实例实例空间中的设置实例保存了设置成员的实际值。一设置实例的值最初由定义空间中的设置值语句指定。然后求设置信息流的值，更新作为流目标的设置实例的值在一些情况下，需要区分从设置值语句导出的设置值和随后通过信息流提供的任何值。前者被称之为“分配”值，后者被称为“结果”值。3.2.9值传输为了将设置值从一信息流或者约束条件中传入或传出，采用了值传输。在评估与成员相关的定义之前，先评估一输入传输，并且在评估了与成员相关的定义之后，评估一输出传输。每个值传输通过Name属性标识将用作输入目的地或输出源的定义的设置。路径属性标识了一个作为输入的源或输出的目的地的设置声明。<xscomplexTypename＝″ValueTransfer″><xsattributename＝″Name″type＝″SimpleName″/><xsattributename＝″Path″type＝″Path″/></xscomplexType>3.2.9.1输入输入语句标识了在执行信息流或约束条件之前将被传输的输入值。此输入能利用ValueSource元素选择是将“分配”设置值还是将“结果”设置值作为输入(参看分配/结果定义的XX部分)。<xscomplexTypename＝″lnput″><xscomplexContent><xsextensionbase＝″ValueTransfer″></xsextension></xscomplexContent></xscomplexType>3.2.9.2输出输出随值传输而变化，其支持固定和替换目标值的语义。<xscomplexTypename＝″Output″><xscomplexContent><xsextensionbase＝″ValueTransfer″><xsattributename＝″Fix″type＝″xsboolean″use＝″optional″/><xsattributename＝″Replace″type＝″xsboolean″use＝″optional″/></xsextension></xscomplexContent></xscomplexType>3.2.10投射我们支持向上和向下投射设置定义继承树。当从目的定义导出一源定义时，从源到目的的投射被称为上投射。当从源定义导出目的定义时，从源到目的的投射被称为下投射。由于树根为Any定义，所有定义均可上投射到Any。图16表示上投射和下投射的例子。在图16中，User定义扩展基本定义Any。接下来ExtendedUser定义扩展基本定义User。通过构建此定义层级，我们指示可在任何需要User定义的地方提供ExtendedUser定义，且可在任何需要Any定义的地方都提供ExtendedUser和User定义。以下设置声明语句采用了如图16的定义，并且将用在以下部分的例子中。<SettingDeclarationName＝″First″Definition＝″ExtendedUser″/><SettingDeclarationName＝″Second″Definition＝″Any″/><SettingDeclarationName＝″Third″Definition＝″User″/>3.2.10.1上投射在图16中，当ExtendedUser定义的实例被分配到一个需要User或Any定义的设置声明时，将发生上投射。一个上投射的例子就是从设置说明First到设置说明Second的值传输。这将作为信息流输入声明的一部分发生。自动支持上投射。无需任何与开发者部分的特殊相互作用，任何值都可投射到其基本定义之一。当上投射一设置实例时，此实例的实际定义将保持其设置值。3.2.10.2下投射在图16中，当用户将一设置值从一被标记为Any设置声明转移到一被标记为User的设置声明时将发生下投射。在此情况下，假如与实例相关的定义是User或ExtendedUser则只发生生指定。这意味着此设置实例可具有与当前相关的设置声明不同的定义。通过将一参考传递给四周都是该实例本身的实例的实际定义，可以在实例空间中追踪到下投射。当将一设置实例从Second传递到Third，假设此实例最初来自First，则发生一个下投射的例子。在此情况下，此设置实例是一个ExtendedUser定义的实例。当将一设置实例从一信息流定义中传递出时则发生此实例。假如此实例的运行期间定义不等于或不是从目标定义导出的，则下投射要由开发者明确地请求而且将会失败。为请求一下投射，开发者将相关传递操作(输入或输出)的设置Cast属性设为真。假如请求一投射，假如目的定义不是来源于源定义那么用户将接收到一编译错误，而且假如设置实例的定义与目的定义不同或者不是来源于目的定义那么用户将接受到一运行错误。3.2.11转换当用户希望将一设置实例转移到一设置声明中，其中此设置声明具有与此实例不同的定义而且此设置说明的定义不是此实例定义的一基本定义，则需要类型转换。图17表示一个类型转换的例子。如图17所示，在位于继承树的不同分支中的定义之间，并且当在继承树一分支中目的定义处于源定义之下时，就发生类型转换。由设置管理器处理类型转换。源和目的管理器均可支持转换。这意味着一旦给定如图17的定义和从一User定义到一String定义的指定，用于User的管理器提供到String的转换或用于String的管理器能提供从User的转换。运行期间将首先请求源管理器转换此实例，然后是目的管理器，假如不存在有效转换则最后返回一错误。为了请求一类型转换，开发者将设置转移(输入或输出)的属性Convert标记为真。假如不指定Convert，并且源定义与目标定义不同或者源定义不是从目标定义导出的，则编译器将返回一错误。假如指定了转换，编译器将通过询问两个管理器是否都支持此转换，来检查两种类型之间的转换是否可以进行。假如此实例具有一个源自与设置声明相关的定义的定义，首先将在返回到上投射之前尝试着将导出定义转换为目的定义，然后转换此值。注意，假如进行上投射，可能失去作为转换处理的一部分的信息。例如，假如我们指定在User和String之间的转换，并且实际实例是一ExtendedUser，那么在返回到将User转换到String之前，我们将首先尝试将ExtendedUser转换为String。3.2.12CLR至SDM类型映射在SDM模型中，所有设置定义均具有相应的CLR类型。这些类型由与SDM模型中SettingDefinitons元素相关的管理器定义。当一信息流、约束条件或配置管理器代表一SDM定义时，通过CLR类型的实例而不是SDM设置定义的实例来实现。这为开发者提供了一个更自然的编程模型，但是也意味着，为了将信息从SDM运行期间传递到管理器，SDM运行期间应该能够从SDM定义映射到CLR类型，并且为了从管理器接受返回信息，SDM运行期间应该能够从CLR类型映射到SDM定义。例如，在一个SDM模型中，开发者可定义以下设置定义<xssimpleTypename＝″AppPoolIdentityType″><xsrestrictionbase＝″xsstring″><xsenumerationvalue＝″LocalSystem″/><xsenumerationvalue＝″LocalService″/><xsenumerationvalue＝″NetworkService″/><xsenumerationvalue＝″UserDefined″/></xsrestriction></xssimpleType>然后开发者可写一管理器，该管理器处理与获得一个以下CLR类型的实例的设置定义相关的值publicenumAppPoolIdentityType{LocalSystem，LocalService，NetworkService，UserDefined，}此问题分为两部分第一能够从定义映射到类型并返回，第二能够从SDM实例映射到CLR实例并返回。3.2.12.1定义到类型的映射为了从设置定义映射到一clr类型，我们采用管理器声明、设置定义名称空间和设置定义名称。从SettingDefinition元素的Manager属性所标识的管理器声明中，我们能获得包含此类型的集合的一强大的名称和位置，从SettingDefinition元素的ClrNamespace属性，我们能获得包含此类型的名称空间的名称。最后，我们能将设置定义的名称加入到名称空间名称中，从而从集合中检索此clr类型。相反的处理利用相同信息从一clr类型映射到一SDM定义。首先，我们从运行期间提供的类型信息中获得集合名称。然后我们发现引用此集合的管理器声明，该集合给出一或多个模型文件。然后从模型文件中的设置定义部分，我们能发现名称空间名称和类型名称的匹配对。3.2.12.2转换实例值为了将设置实例从其XML格式的SDM表述转换成Clr对象实例并返回，我们再利用与SettingDefinition元素相关的管理器。在此情况下，实现此变换的Clr类是由ClrClassName属性和由Manager属性标识的管理器声明的集合信息的组合来标识。Clr类实现了在管理器接口规格说明(ref)中描述的ISettingSerialization接口。此接口既支持从SDMXml表述到Clr实例的转换，也支持从一Clr对象实例到SDMXml表述的转换。在Model文件中创建设置定义的开发者负责写执行该转换的代码。Clr类应支持SettingDefinition元素中的所有设置定义的转换。3.3属性SDM中的许多对象能获得与此对象的核心行为无关的行为。我们采用一个如下定义的通用属性模型3.4定义定义用于创建资源和系统的可重用配置。它们与面向对象语言中的类相似。3.4.1定义定义是导出对象、关系、约束条件和信息流定义的基础。所有定义可包括以描述、设置成员、设置值和设计表面数据。每个定义由一简名标识并且引用一管理器。此管理器通过该定义标识的类为此特殊定义的SDM运行期间提供支持。定义的名称对于包含此定义的范围内的所有定义来说应为独一无二的。此范围可为一SDM文档或另一定义。<xscomplexTypename＝″Definition″><xssequence><xselementname＝″Desaiption″type＝″Description″minOccurs＝″0″/><xselementname＝″DesignData″type＝″DesignData″minOccurs＝″0″/><xschoiceminOccurs＝″0″maxOccurs＝″unbounded″><xselementname＝″SettingDeclaration″type＝″SettingMember7><xselementname＝″SettingValue″type＝″SettingValue″/><xselementname＝″SettingValueList″type＝″SettingValueList″/></xschoice></xssequence><xsattributename＝″Name″type＝″SimpleName″use＝″required″/><xsattributename＝″Manager″type＝″QualifiedName″use＝″optional″/><xsattributename＝″ClrClassName″type＝″xsstring″use＝″optional″/></xscomplexType>3.4.2对象定义一抽象的对象定义公开了一组设置声明，可包含其所参与的关系的约束条件并在运行期间具有一相关管理器。以下是一个网络服务器的抽象系统定义。此网络服务器具有两个设置和一个要求其包含至少在vsite类型上的关系约束条件。<SystemDefinitionAbstract＝″true″Name＝″WebServer″ClrClassName＝″micorosft.sdm.llSSupportClass″Manager＝″IISSupportCode″><SettingDeclarationName＝″serverName″Definition＝″String7><SettingDeclarationName＝″category″Definition＝″String″/><SettingDeclarationName＝″roles″Definition＝″String″List＝″true7><RelationshipConstraintName＝″containsVsites″RelationshipDefinition＝″containmentRelationship″TargetRole-′Member″TargetObjectDefinition＝″vsite″MinOccurs＝″1″WlaxOccurs＝″unbounded″/></SystemDefmition>Vsite是一个包含服务器捆绑信息的抽象端点定义<EndpointDefinitionAbstract＝″true″Name＝″vsite″><SettingDeclarationName＝″ipAddress″Definition＝″ipaddress″required＝″true7<SettingDeclarationName＝″port″Definition＝″lnt7><SettingDeclarationName＝″domainName″Definition＝″lnt″/><SettingDeclarationName＝″securityModel″Defintion＝″securityModelEnum7></EndpointDefinition>一个前端网络服务器的具体系统定义标识了网络服务器的范畴为静态内容，包含代表1和100之间的端点实例的单个传引用的端点成员。此端点的具体端点定义嵌套在系统定义中，并且其将vsite的ip端点定义为端点80。<SystemDefinittonName＝″FrontendWebServer″Extends＝″WebServer″><SettingValuePath＝″serverName″Fixed＝″true″>myFEServer</SettingValue><SettingValueListPath＝″roles″Fixed＝″true″Replace＝″true″><Value>staticContent<A/alue><Value>aspPages<A/alue></SettingValueList><EndpointDefinitionName＝″port80Vsite″Extends＝″vsite″><SettingValuePath＝″port″Fixed＝″true″>80</SettingValue></EndpointDefinition><EndpointName＝″contentOnlyVsite″Definition＝″port80Vsite″Reference＝″true″MinOccurs＝″TMaxOccurs＝″100″/></SystemDefinition>3.4.2.1对象定义抽象和具体对象扩展了以下基本对象定义。除了基本类型定义的元素之外，它们共同具有约束对象所参与的关系的能力。<xscomplexTypename＝″ObjectDefinition″><xscomplexContent><xsextensionbase＝″Definition″><xschoiceminOccurs＝″0″maxOccurs＝″unbounded″><xselementname＝″Flow″type＝″FlowMember″minOccurs＝″0″maxOccurs＝″unbounded″/><xselementname＝″RelationshipConstraintGroup″type＝″RelationshipConstraintGroup″/><xselementname＝″RelationshipConstraint″type＝″RelationshipConstraint″/><xselementname＝″Constraint″type＝″ConstraintMember″/></xschoice><xsattributename＝″Visibility″type＝′VisibilityEnum″use＝″optional″/><xsattributename＝″Layer″type＝″xsstring″use＝″optional″/><xsattributename＝″Extends″type＝″QualifiedName″use＝″optional″/><xsattributename＝″Abstract″type＝″xsboolean″use＝″optional″/></xsextension></xscomplexContent></xscomplexType>抽象对象定义用于定义设计表面公开的结构块，并且从其中能导出所有具体对象一具体对象定义实现了一抽象对象定义。抽象对象定义通过加入简单继承来扩展SDM对象“extends”属性用于标识一抽象对象定义的基本对象定义。此抽象对象定义然后从基本对象定义中继承设置和关系约束条件。通过继承，对象定义可通过加入新设置和约束条件来扩展抽象对象定义的设置和约束条件。抽象对象定义也能加入它们希望参与的关系上的约束条件。例如，一抽象对象定义可要求存在某些关系，可约束处于关系另一端的对象定义或可约束参与一给定关系的实例的设置。对象定义也可包含嵌套定义的声明。这些定义可用于在包含定义范围内的成员并且可以被引用到该定义范围之外的约束条件中。具体对象定义提供了一抽象对象定义的实现。该实现根据对象和关系成员、所实现的抽象定义的设置值、新设置声明、成员间的信息流和成员的约束条件构成了该实现。3.4.2.2隐含基本定义所有未扩展另一对象定义的对象定义隐含地扩展了端点、系统或源基本定义之一。这些基本定义形成了用在关系和约束条件声明的每个树的根。这允许关系或约束条件指示任何从根导出的类型可用在所标识的根定义。这些根类型总是抽象的并且不能直接例示。这些类型的定义包括控制模型内的例示的基本约束条件。3.4.2.3端点定义端点定义通过增加声明嵌套资源类型、资源成员以及宿主、包含和引用关系成员的能力来扩展基本对象定义。<xscomplexTypename＝″EndpointDefinition″><xscomplexContent><xsextensionbase＝″ObjectDefinition″><xschoiceminOccurs＝″0″maxOccurs＝″unbounded″><xselementname＝″ResourceDefinition″type＝″ResourceDefinition″/><xselementname＝″Resource″type＝″ResourceMember″/><xselementname＝″Hosting″type＝″HostingMember″/><xselementname＝″Containment″type＝″ContainmentMember″/><xselementname＝″Reference″type＝″ReferenceMember″/></xschoice></xsextension></xscomplexContent></xscomplexType>3.4.2.4系统定义一系统类型通过增加对以下内容的支持扩展了基本类型嵌套端点、系统和资源类型；端点、系统和资源成员以及宿主、包含、连接、授权和参考关系。<xscomplexTypename＝″SystemDefinition″><xscomplexContent><xsextensionbase＝″ObjectDefinition″><xschoiceminOccurs＝″0″maxOccurs＝″unbounded″><xselementname＝″EndpointDefinition″type＝″EndpointDefinition″/><xselementname＝″SystemDefinition″type＝″SystemDefinition7><xselementname＝″ResourceDefinition″type＝″ResourceDefinition″/><xselementname＝″Endpoint″type＝″EndpointMember7><xselementname＝″Subsystem″type＝″SystemMember7><xselementname＝″Resource″type＝″ResourceMember″/><xselementname＝″Hosting″type＝″HostingMember″/><xselementname＝″Containment″type＝″ContainmentMember″/><xselementname＝″Connection″type＝″CommunicationMember″/><xselementname＝″Delegation″type＝″DelegationMember″/><xselementname＝″Reference″type＝″ReferenceMember″/></xschoice><xsattributename＝″SimulationRoot″type＝″xsbooiean″use＝″optional″/></xsextension></xscomplexContent></xscomplexType>3.4.2.5资源定义一资源类型可包含嵌套资源类型定义、资源成员以及宿主、包含和引用关系成员。<xscomplexTypename＝″ResourceDefinition″><xscomplexContent><xsextensionbase＝″ObjectDefinition″><xschoiceminOccurs＝″0″maxOccurs＝″unbounded″><xselementname＝″ResourceDefinition″type＝″ResourceDefinition7><xselementname＝″Resource″type＝″ResourceMember″/><xselementname＝″Hosting″type＝″HostingMember″/><xselementname＝″Containment″type＝″ContainmentMember″/><xselementname＝″Reference″type＝″ReferenceMember7></xschoice></xsextension></xscomplexContent></xscomplexType>3.4.2.6关系规则对于一对象定义的一特殊实例，下表标识了与实例所能扮演的角色相关的基数。3.4.2.6.1系统规则3.4.2.6.2端点规则3.4.2.6.3资源规则3.4.2.6.3资源规则3.4.2.6.4注意每个实例应该正确参与一个包含关系和至少一个宿主关系。这意味着a)非引用(传值)成员应标识一个在相同定义中的包含关系b)为了被构建一引用成员应标识一包含关系。3.4.3关系定义关系用于标识类型之间的可能的交互作用。它们是二元的并且是直接的，每个标识都标识了能参与此关系的实例类型。关系也能约束参与此关系的实例的设置，并能通过此关系传递设置值。以下是一个用于在类型部分所述的网络服务器的webApplication的可能的宿主关系。此关系包含一约束条件，此约束条件验证两个系统的安全模型是兼容的，并且此关系还包括了一设置信息流，而此设置信息流将服务器名称从vsite复制到vdir。<HostingDefinitionName＝″vsiteHostsVdir″GuestDefinition＝″vdir″HostDeffinition＝″vsite″><ObjectConstraintName＝″checkCompatibility″PrimaryRole＝″Guest″PrimaryObjectDefinition＝″vdir″><ConstraintName＝″constrainSecurityModel″Definition＝″SimpleOperatorComparison″><SettingValuePath＝″operator″>＝</SettingValue><lnputName＝″LHS″Path＝″host.securityModel7><lnputName＝″RHS″path＝″guest.securityModeP/></Constraint></ObjectConstraint><FlowDefinition＝″copy″Name＝″copyServerToVdir″><lnputName＝″source″Path＝″host.server″/><OutputName＝″desination″Path＝″guest.server″/></Flow></HostingDefinition>通过声明一个标识了将参与此关系的类型成员的关系成员来使用关系。<SystemDefinitionName＝″TestSystemt″Extends＝″DistributedApplication″><ResourceName＝″myVdir″Definition＝″vdir″Reference＝″false″/><ResourceName＝″myVsite″Definition＝″vsite″Reference＝″false″/><HostingName＝″HostMyVsite″Definition＝″vsiteHostsVdir″GuestMember＝″myVdir″HostMember＝″myVsite″/></SystemDefinition>3.4.3.1关系定义基本关系定义将对象约束条件和信息流加入到定义中。对象约束条件是关于参与此关系实例的对象实例的设置值的语句。例如，一个表示DCOM连接的通信关系可检查客户机和服务器是兼容的安全设置。在此情况下，在易于获得的作为部分设计处理的设置间存在严格的关系；在此关系上存在四阶设置组合，但只有少得多的有效组合。信息流赋予关系开发者将值从一个实例传递给另一实例的能力。为充分描述一特殊实例，信息流允许对象定义与其可能的交互关系独立开发且允许此实例独立作为一信息引用点而无需一关系图子集。具体关系是两个具体对象定义之间的关系。每个具体关系可实现一抽象关系。此抽象关系应在由具体对象定义直接或间接(通过继承)实现的的抽象对象定义的一匹配对之间。关系的名称应在包含此关系的名称空间内是独一无二的。<xscomplexTypename＝″RelationshipDefinition″><xscomplexContent><xsextensionbase＝″Definition″><xschoiceminOccurs＝″0″maxOccurs＝″unbounded″><xselementname＝″ObjectConstraintGroup″type＝″ObjectConstraintGroup″/><xselementname＝″ObjectConstraint″type＝″ObjectConstraint″/><xselementname＝″Flow″type＝″FlowMember″/></xschoice><xsattributename＝″Extends″type＝″QualifiedName″use＝″optionai″/><xsattributename＝″Abstract″type＝″xsboolean″use＝″optional″/></xsextension></xscx)mplexContent></xscomplexType>3.4.3.2通信关系通信关系用于获得端点定义之间可能的通信链接。它们用于描述独立配置的软件元素之间的相互作用。通信关系模式通过增加客户机和服务器端点引用从而扩展了基本关系模式。<xscomplexTypename＝″CommunicationDefinition″><xscomplexContent><xsextensionbase＝″RelationshipDefinition″><xssequence><xselementname＝″Connection″type＝″HostingMember″minOccurs＝″0″maxOccurs＝″unbounded″/></xssequence><xsattributename＝″ClientDefinition″type＝″QualifiedName″use＝″required″/><xsattributename＝″ServerDefinition″type＝″QuaiifiedName″use＝″required″/></xsextension></xscomplexContent></xscomplexType>以下抽象类型对的组合对于通信关系是有效的3.4.3.3宿主关系宿主关系用于获得一客户为了被构件需要一宿主的事实。由于一个客户可存在超过一个可能的宿主，这意味着宿主关系也负责在一宿主上的客机的构造。所以为了创建一对象的一实例，宿主关系是从一客户到一可兼容宿主。例如，在一Webservice对象定义和一IIS对象定义之间可存在一宿主关系。在此情况下，假定MyWebservice和MyIIS分别实现网络服务和IIS，此关系表示有可能利用宿主关系的管理器，在系统MyIIS实例上创建系统MyWebservice实例。直到评估了系统和关系的约束条件后，我们才知道将是否有可能创建此关系。当我将一应用程序配置到一数据中心时，需要解析在此应用程序中系统的所有典型宿主关系。为此，操作者需要为每个所需的宿主关系创建宿主成员。为简化操作者的任务并允许开发者引导配置过程，开发者可创建一具体宿主关系。此具体宿主关系用于将一组宿主关系成员按以下方式分组当配置此应用程序时操作者只需声明一单个宿主成员。一客户可被归为一宿主iff对于客户中的每个客户成员在宿主中存在一个或多个宿主成员，其中guestMeraber.Type与withhostMember.type具有宿主关系并且guestMember.hostConstraints相对于hostMember.settings进行验证并且hostMember.settings相对于guestMember.settings进行验证并且对于guestMember的每个成员，都存在一到hostMember的成员的归并(AguestcanbeboundtoahostiffForeachguestMemberinGuestThereexistsoneormorehostMemberinHostwhere)guestMeraber.TypehasahostingrelationwithhostMember.type)andguestMember.hostConstraintsvalidateagainsthostMember.settings)andhostMember.guestConstraintsvalidateagainstguestMember.settingsandforeachmemberofguestMemberthereexistsabindingtoamemberofhostMember)例如，以下具体关系将一层三个系统(Bike)归并到一层两个主机(操作系统)。在此情况下，我们定义一个用于宿主关系的设置，其默认值被设为“系统文件夹”。我们将此设置传给定义层3应用系统和层2主机系统之间的宿主关系的三个主机成员之一。<HostingDefinitionName＝″DefaultBikePlacement″GuestDefinition＝″Bike″HostDefinition＝″OperatingSystemOperatingSystem″><SettingDeclarationName＝″fileLocationRelativeToRoot″Definition＝″xssting″Access＝″Readwrite″/><Sett！ngValuePath＝″dirPath″>systemFolder</SettingValue><FlowName＝″copyPath″Definition＝″copy″><lnputName＝″source″Path＝″dirPath″/><OutputName＝″destination″Path＝″bikeExecutableHost.hostRelativePath″/></Row><HostingName＝″bikeExecutableHosfDefinition＝″fileDirectoryHost″GuestMember＝″guest.bikeFile″HostMember＝″host.FileSystem″/><HostingName＝″bikeEventKeyHost″Definition＝″registryKeyRegistryKeyHost″GuestMember＝″guest.bikeEventKey″HostMember＝″host.Registry.ApplicationEventKey″/><HostingName＝″bikeSoftwareKeyHost″Definition＝″registryKeyRegistryKeyHost″GuestMember＝″guest.bikeSoftwareKey″HostMember＝″host.Registry.HKLM″/></HostingDefinition><xscomplexTypename＝″HostingDefinition″><xscomplexContent><xsextensionbase＝″RelationshipDefinition″><xssequence><xselementname＝″Hosting″type＝″HostingMember″minOccurs＝″0″maxOccurs＝″unbounded7></xssequence><xsattributename＝″GuestDefinition″type＝″QualifiedName″use＝″required″/><xsattributename＝″HostDefinition″type＝″QualifiedName″use＝″required″/><xsattributename＝″SimulationRoot″type＝″xsboolean″use＝″optional″/></xsextension></xscomplexContent></xscomplexType>以下抽象定义对的组合对于宿主关系是有效的3.4.3.4包含关系在两个抽象对象之间的包含关系用于获得基于parentType的具体类型可包含基于memberType的成员的事实。包含意味着父实例可控制成员实例的生命期，并且可授权成员实例的行为。<xscomplexTypename＝″ContainmentDefinition″><xscomplexContent><xsextenstonbase＝″RelationshipDefinition″><xssequence><xselementname＝″Containment″type＝″HostingMember″minOccurs＝″0″maxOccurs＝″unbounded″/></xssequence><xsattributename＝″ParentDefinition″type＝″QualifiedName″use＝″required″/><xsattributename＝″MemberDefinition″type＝″QualifiedName″use＝″required″/></xsextension></xscomplexContent></xscomplexType>以下抽象定义对的组合对于包含关系是有效的3.4.3.5授权关系授权用于将行为从一个外部系统传递给一个被包含的系统。这通过将外部系统的端点授权给内部系统的端点来实现。这就有效地将所有直接对外部系统的交互作用传送给了内部系统端点。授权可以是一连串的，允许内部系统将该行为进一步授权给另一系统。一授权关系限定了多对能参与授权的抽象端点定义。每个关系标识了作为一代理的抽象端点定义和能授权此行为的一抽象端点定义。<xscomplexTypename＝″DelegationDefinition″><xscomplexContent><xsextensionbase＝″RelationshipDefinition″><xssequence><xselementname＝″Delegation″type＝″HostingMember″minOccurs＝″0″maxOccurs＝″unbounded″/></xssequence><xsattributename＝″ProxyDefinition″type＝″QualifiedName″use＝″required″/><xsattributename＝″DelegateDefinition″type＝″QualifiedName″use＝″required″/></xsextension></xscomplexContent></xscomplexType>以下抽象类型对的组合对于授权关系是有效的为支持层间的结合，我们允许资源和系统的授权。例如，允许IIS无需配置文件系统便可公开部分文件系统。3.4.3.6参考关系我们利用参考关系给出实例之间除宿主关系从属性之外的强大从属性。这些从属性用于控制配置期间的构建顺序以及安装和更新期间系统之间的信息流参数。由于引用关系表示一强大的从属性，就不能允许引用关系跨越一系统边界。这意味着系统内资源以来另一系统资源。这使得此系统不再是一个独立的配置单元。在系统之间存在从属性的地方，我们使用通信关系。通信关系无需重安装系统便可随着时间推移而改变。<xscomplexTypename＝″ReferenceDefinition″><xscomplexContent><xsextensionbase＝″RelationshipDefinition″><xssequence><xselementname＝″Reference″type＝″HostingMember″minOccurs＝″0″maxOccurs＝″unbounded″/></xssequence><xsattributename＝″DependentDefinition″type＝″QualifiedName″use＝″required″/><xsattributename＝″SourceDefinition″type＝″QualifiedName″use＝″required″/></xsextension></xscomplexContent></xscomplexType>以下抽象类型对的组合对于参考关系是有效的3.4.3.7隐含基本关系所有抽象关系隐含地扩展一个基本关系定义。这些定义形成了每个关系树的根。图18描述了一个示例性的关系树。为此，我们可从约束条件定义内参考根定义且能从根类型继承通用类型约束条件3.5成员3.5.1成员成员用于标识一个在运行期间存在的特殊定义的实例。所有成员均通过一名称标识，此名称在包含此成员的定义范围内的成员组中是独一无二的。一成员可为其所引用的定义提供设置。一成员也可包含设计表面特定数据。<xscomplexTypename＝″Member″><xssequence><xselementname＝″Description″type＝″Description″minOccurs＝″0″/><xselementname＝″DesignData″type＝″DesignData″minOccurs＝″0″/><xschoiceminOccurs＝″0″maxOccurs＝″unbounded″><xselementname＝°SettingValue″type＝″SettingValue″/><xselementname＝″SettingValueList″type＝″SettingValueList″/></xschoice></xssequence><xsattributename＝″Name″type＝″SimpleName″use＝″required″/><xsattributename＝″Definition″type＝″QualifiedName″use＝″required″/><xsattributename＝″Visibility″type＝″VisibilityEnum″use＝″optional″/></xscomplexType>3.5.2对象成员对象成员可参考一抽象或具体的对象定义。它们能表示一实例阵列，在这种情况下，它们能定义此阵列的上限和下限。假如它们是引用成员，那么用户例示此对象就隐含构建了一个此成员的实例。假如它们不是引用成员，那么此运行期间将在创建外部对象的同时创建一实例。<xscomplexTypename＝″ObjectMember″><xscomplexContent><xsextensionbase＝″Member″><xsattributename＝″MinOccurs″type＝″MinOccurs″use＝″optional″/><xsattributename＝″MaxOccurs″type＝″MaxOccurs″use＝″optional″/><xsattributename＝″Reference″type＝″xsboolean″use＝″required″/></xsextension></xscomplexContent></xscomplexType>在一SDM模型中，我们需要将当构建父体时创建并且消灭父体时也被消灭的成员与其生命期独立于其父体的成员相区分。为此我们使用IsReference属性。一简单的模拟是C++说明，其基于“new”是否用于创建一实例，允许基于堆栈和堆结构。假如一成员标记为IsReference，那么部分操作者需要一清楚的新的操作，用以创建一个实例并将其与成员相关。有许多原因导致我们要1.当一操作者构建一系统时，我们只需给出构建isReference成员的能力。这大大简化了操作者的操作过程。2.但我们处理一SDM文档时，我们对文档的实例空间与具体定义空间明确区分。3.5.3关系成员关系成员标识了当创建对象成员时它们之间存在的关系。关系实例是由操作者明确地创建或由运行期间隐含地创建。前者的例子是实例之间的宿主关系，后者的例子是系统之间的通信关系。<xscomplexTypename＝″RelationshipMember″><xscomplexContent><xsextensionbase＝″Member″/></xscomplexContent></xscomplexType>3.5.4端点成员<xscomplexTypename＝″EndpointMember″><xscomplexContent><xsextensionbase＝″ObjectMember″/></xscomplexContent></xscomplexType>3.5.5系统成员<xscomplexTypename＝″SystemMember″><xscomplexContent><xsextensionbase＝″ObjectMember″/></xscomplexContent></xscomplexType>3.5.6资源成员<xscomplexTypename＝″ResourceMember″><xscomplexContent><xsextensionbase＝″ObjectMember″/></xscomplexContent></xscomplexType>3.5.7宿主成员宿主成员用于声明两个对象成员之间的宿主关系。此对象成员是包含定义的直接成员或是与此定义具有一成员关系的嵌套成员。在被引用的成员和包含成员之间存在一成员关系链。<xscomplexTypename＝″HostingMember″><xscomplexContent><xsextensionbase＝″RelationshipMember″><xsattributename＝″GuestMember″type＝″Path″use＝″required″/><xsattributename＝″HostMember″type＝″Path″use＝″required″/></xsextension></xscomplexContent></xscomplexType>3.5.8通信成员通信成员用于声明在定义的即时系统的端点成员中的端点成员之间的通信关系。<xscomplexTypename＝″CommunicationMember″><xscomplexContent><xsextensionbase＝″RelationshipMember″><xsattributename＝″ClientMember″type＝″Path″use＝″required″/><xsattributename＝″ServerMember″type＝″Path″use＝″required″/></xsextension></xscomplexContent></xscomplexType>3.5.9包含成员包含成员用于声明一个类型成员被该类型所包含。每个类型成员可被包含或授权。包含成员自动将包含关系的父值设置成该关系的指针。<xscomplexTypename＝″ContainmentMember″><xscomplexContent><xsextensionbase＝″RelationshipMember″><xsattributename＝″ChildMember″type＝″Path″use＝″required″/></xsextension></xscomplexContent></xscomplexType>3.5.10授权成员一授权成员用于建立在外部类型的端点定义成员和外部类型的及时系统成员的端点定义成员之间的授权关系。<xscomplexTypename＝″DelegationMember″><xscomplexContent><xsextensionbase＝″RelationshipMember″><xsattributename＝″ProxyMember″type＝″Path″use＝″required″/><xsattributename＝″DelegateMember″type-′Path″use＝″required″/></xsextension></xscomplexContent></xscomplexType>3.5.11参考成员参考成员用于在外部定义的两个即时或嵌套成员之间建立一个参考关系。<xscomplexTypename＝″ReferenceMember″><xscomplexContent><xsextensionbase＝″ReiationshipMember″><xsattributename＝″DependentMember″type＝″Path″use＝″required″/><xsattributename＝″SourceMember″type＝″Path″use＝″required″/></xsextension></xscomplexContent></xscomplexType>3.6信息流设置信息流用于在一对象定义的成员之间以及关系的参与者之间传递参数。作为信息流的一部分，用户可利用变换来组合或分离设置值以及计算新的设置值。所有设置信息流成员利用一信息流定义来实现变换。以下是分析url的信息流定义。<FlowDefinitionName＝″urlToComponents″><SettingDeclarationName＝″url″Definition＝″url″Access＝″Writeonly″/><SettingDeclarationName＝″protocol″Definition＝″String″Access＝″Readonly″/><SettingDeclarationName＝″server″Definition＝″String″Access＝″Readonly″/><SettingDeclarationName＝″Path″Definition＝″String″Access＝″Readonly″/><SettingDeclarationName-′file″Definition＝″String″Access＝″Readonly″/></FlowDefinition>在一对象或关系中声明一信息流成员。信息流成员提供了信息流定义的输入，然后将信息流的输出导入目标设置。<FlowName＝″deconstructUrl″Definition＝″urlToComponents″><lnputName＝″url″Path＝″webservice.ul″/><OutputName＝″server″Path＝″webservice.server″Replace＝″false″/></Flow>3.6.1信息流定义我们利用信息流定义来定义我们希望对一组设置值应用的特殊变换。信息流定义给出了定义输入设置(只写设置)和输出设置(制度设置)的一设置模式，一用于设计表面特定信息的DesignData部分，例如用于定义变换的输入接口、以及当浏览SDM文件时使用的描述。信息流定义是由在其中定义该信息流定义的名称空间内的名称来标识。，此定义也标识了一个将支持评估信息流的运行的管理器。我们希望运行期间将包括几个标准信息流定义从而简化需要直接变换的信息流元素的构建。例子可包括复制、合并和字符串替换。由于信息流定义可参数化，我们也希望有一或多个基于配置参数来执行不同动作的变换。<xscomplexTypename＝″FlowDefinition″><xscomplexContent><xsextensionbase＝″Definition″/></xscomplexContent></xscomplexType>3.6.2信息流成员每个信息流成员标识一或多个输入设置、一或多个目的设置可提供固定设置值并且能标识一信息流定义。当评估此信息流时，从输入收集源数据，合并固定设置值并将其传递给用于变换的信息流定义。依据信息流成员列出的输出，将定义的输出传递给目的设置。只要其中的一个源值改变便会触发信息流的再评估。因此，我们需要避免导致值振荡的循环信息流。假如此值保持不变，那么将终止循环。运行期间通过跟踪堆栈的深度来检测并终止无极限的回路。从分离的信息流成员到对象实例的相同设置成员的输出是一错误。<xscomplexTypename＝″FlowMember″><xscomplexContent><xsextensionbase＝″Member″><xschoiceminOccurs＝″0″maxOccurs＝″unbounded″><xselementname＝″lnput″type＝″SettingTarget″/><xselementname＝″Output″type＝″OutputPath″/></xschoice></xsextension></xscomplexContent></xscomplexType>3.7约束条件约束条件用于标识对一定义的成员的设置值或者一关系的参与者的限定。在设计期间和配置期间的在实例空间中都要评估这些限定。所有设置约束条件采用一约束条件定义来评估设置值。约束条件定义采用设置声明来标识它所约束的值。以下约束条件定义实现了将两个变量和一操作者简单比较的功能，然后评估约束条件，最后返回成功或错误。<ConstraintDefinitionName＝″SimpleOperatorComparison″><SettingDeclarationName＝″LHS″Definition＝″Any″Access＝″Writeonly″/><SettingDeclarationName＝″operator″Definition＝″operator″Access＝″Writeonly″/><SettingDeclarationName＝″RHS″Definition＝″Any″Access＝″Writeonly″/></ConstraintDefinition>一约束条件成员然后将此值提供给用于评估的约束条件类型。<ConstraintName＝″constraintSecurityMode″Definition＝″SimpleOperatorComparison″><SettingValuePath＝″operator″>＝</SettingValue><SettingValuePath＝″RHS″>basicAuth</SettingValue><lnputName＝″LHS″Path＝″webservice.securityMode″/></Constraint>3.7.1约束条件定义一约束条件定义限定了一组输入值的约束条件。此约束条件可参数化，从而选择客户行为或支持一简单的利用参数来定义其行为的约束条件引擎。我们希望为简单参数值约束条件和一组复杂约束条件的写一组标准约束条件定义从而支持抽象对象的已知关系。<xscomplexTypename＝″ConstraintDefinition″><xscomplexContent><xsextensionbase＝″Definition″><xschoiceminOccurs＝″0″maxOccurs＝″unbounded″><xselementname＝″RelationshipConstraint″type＝″RelationshipConstraint″/><xselementname＝″RelationshipConstraintGroup″type＝″RelationshipConstraintGroup″/><xselementname＝″ObjectConstraint″type＝″ObjectConstraint″/><xselementname＝″ObjectConstraintGroup″type＝″ObjectConstraintGroup″/></xschoice><xsattributename＝″TargetDefinition″type＝″QualifiedName″use＝″optional″/></xsextension></xscomplexContent></xscomplexType>3.7.2约束条件成员一约束条件成员标识了特殊约束条件定义的一组输入值。此成员可标识设置的静态值，并且也能利用输入语句将一约束条件设置结合到一路径中。<xscomplexTypename＝″ConstraintMember″><xscomplexContent><xsextensionbase＝″Member″><xschoiceminOccurs＝″0″maxOccurs＝″unbounded″><xselementname＝″Input″type＝″Input″/></xschoice></xsextension></xscomplexContent></xscomplexType>3.7.3结构的约束条件我们采用对象和关系约束条件来定义具体空间的拓扑结构并约束用于特定关系中的对象设置。例如，在一抽象对象定义(A)中，我们想标识此抽象定义的实现应包含另一抽象对象定义的实例(B)。假定已存在至少一个适当的包含关系，为此，我们将采用A中的一关系约束条件，其如下所示<RelationshipConstraintname＝″AContainsB″relationship＝″ContainmentDefinition″myRole＝″parent″targetType＝″B″minOccurs＝TmaxOccurs＝″1″/>此约束条件标识了应当存在的一约束条件关系，其中A为父角色而关系另一端的类型(成员)是类型B。假如我们需要经一步控制B的配置，我们可在类型B上增加如下设置约束条件<RelationshipConstraintName＝″AContainsB″RelationshipDefinition＝″containementRelationship″TargetRole＝″Member″TargetObjectDefinition＝″B″MinOccurs＝″1″MaxOccurs＝″1″><ConstraintDefinition＝″simpleValueConstraint″Name＝″BValueConstraint″><SettingValuePath＝″operator″>＝</SettingValue><SettingValuePath＝″RHS″>myPort</SettingValue><lnputPath＝″member.Name″Name＝″LHS″/></Constraint></RelationshipConstraint>在这种情况下，我们增加了一个要求成员名称等于字符串“myPort”的约束条件。我们也能给关系增加约束条件；我们调用这些对象约束条件。从一关系中，我们约束参与此关系的对象。对于关系中的每个角色，我们可标识一对象定义然后将设置约束条件加入到那些对象定义上。从关系角度来看，基数一直是minOccurs＝1且maxOccurs＝1，所以其未出现在约束条件声明中。<ObjectConstraintName＝″allowedPair″PrimaryRole＝″Host″PrimaryObjectDefinition＝″IIS″SecondaryRole＝″Guest″SecondaryObjectDefinition＝″webApp″/>最后，我们可嵌套约束条件。这使得我们能够将约束条件链接在一起，外部约束条件设置了内部约束条件的上下文。以下是一个宿主到Webapp系统的IIS系统的例子，其仅仅约束了一特定类型的webApp包含端点。在这种情况下，我们利用一组对象约束条件来标识一组至少一个为真的可能性。<SystemDefinitionName＝″test″><RelationshipConstraintName＝″WebAppHostConstraint″RelationshipDefinition＝″HostingDefinition″TargetRole＝″Guest″TargetObjectDefinition＝″webApp″><RelationshipConstraintName＝″WebAppContainsPort1″RelationshipDefinition＝″containmentRelationship″TargetRole＝″Member″TargetObjectDefinition＝″EndpointDefinition″MinOccurs＝″1″MaxOccurs＝″unbounded″><ObjectConstraintGroup><ObjectConstraintName＝″hasWebPort″PrimaryRole＝″Member″PrimaryObjectDefinition＝″webPort″/><ObjectConstraintName＝″hasSqiPort″PrimaryRole＝″Member″PrimatyObjectDefinition＝″sqlPort″/></ObjectConstraintGroup></RelationshipConstraint></RelationshipConstraint>嵌套约束条件形成了一条我们可从内到外评估的路径。路径的每个约束条件可向对当前实例一样访问路径上先前实例的设置。就像该约束条件已定义在已标识系统中一样，传播对嵌套约束条件的评估。从foo角度来看，以下两种情况应该是相等的。在第一种情况下，foo在一包含系统bar上设置了一嵌套约束条件，在第二种情况下，类型bar已经包含了此约束条件。情况1<SystemDefinitionname＝″foo″><RelationshipConstraintName＝″containsBar″RelattonshipDefinition＝″containment″TargetRole＝″Member″TargetObjectDefinition＝″bar″MinOccurs＝T><RelationshipConstraintName＝″containsX″RelationshipDefinition＝″containment″TargetRole＝″MembernTargetObjectDefinition＝″X″MinOccurs＝″1″/></RelatbnshipConstraint></SystemDefinition><SystemDefinitionname＝″bar″/>情况2<SystemDefinitionName＝″foo″><RelationshipConstraintName＝″containsBar″RelationshipDefinition＝″containment″TargetRole＝″Member″TargetObjectDefinition＝″bar″MinOccurs＝″1″/></SystemDefinition><SystemDefinitionName＝″bar″><RelationshipConstraintName＝″containsX″RelationshipDefinition＝″containment″TargetRole＝°Member″TargetObjectDefinition＝″X″MinOccurs＝″1″/></SystemDefinition>3.7.3.1约束条件模型约束条件模型具有两部分防护和判定。利用防护定义执行判定的上下文。例如在一关系中，我们利用防护来标识我们想执行的断定的类型的一特殊组合。在一对象内，我们利用防护来标识与其他对象的一组关系。当遇到防护的需求时，执行判定。我们有两种形式的判定验证设置值的设置约束条件和验证一组约束条件的组约束条件。我们可在防护内嵌套防护，在这种情况下，当满足外防护时只检查内防护。这就允许我们建立支持关系结构的验证的路径。一防护及其判定的组合具有一基数，其指示了防护应该匹配且判定被评计为真的次数。更正式地，Guard＝ObjectConstraint(ObjectDefintion，ObjectDefintion.required){(Guard|predicate)*}|RelationshipConstraint(RelationshipDefinition，Targetobject，1Bound，uBound){(Guard|predicate)*}防护被定义为ObjectConstraint或RelatiomshipConstraint。对象约束条件标识了与关系两端相关的两个对象定义。关系约束条件标识了一关系定义和一目标对象定义。当一关系约束条件具有一下限和一上限时，对象约束条件是可选地或必需地。基数不同反映了一关系只能标识两种类型而一种类型可参与多个关系。predicat＝Settingsconstraint(rule)|group{(group)*}判定是一个包含一规则的设置约束条件或者是包含了一组防护的组。在防护的上下文中评估约束条件。在其是设置约束条件的情况下，判定可标识来自根防护的所有者以及由每个嵌套防护所标识的内容的设置。组用于标识一组防护，其中该防护中的至少一个应匹配且评估为真。例1.RelationshipConstraint(containmentRelationship，webapp，0，1){}此例表示了一个防护，其中只要存在包含webapp的包含关系，该防护就被评估为真。此防护最多一次评估为真。进一步的匹配将向用户返回一错误。2.RelationshipConstraint(containmentRelationship.webapp，0，1){settingsconstraint(webapp.name＝2)}此例给防护增加了一判定。只有当关系和目标定义相匹配并且设置约束条件被评估真时，此防护被评估为真。假如关系和目标定义相匹配且设置约束条件不为真，那么将向用户返回一错误。假如关系和目标类型匹配且设置约束条件多次被评估为真，那么向用户返回一错误。3.RelationshipConstraint(containmentRelationship，webapp，0，1){RelationshipConstraint(containmentRelationship，vdir，0，1)}在此例中，在一防护中嵌套一防护。当外部防护为真(包含约束条件的类型也包含一webapp)，然后评估在外部防护上下文中的内部防护。这意味着将在一webapp实例的上下文中评估内部关系约束条件。假如webApp包含0或一个vdir，则此内部约束条件将返回真，假如它包含超过一个vdir，则此约束条件将向用户返回一错误。4.objectConstraint(webapp，iis，0，1){RelationshipConstraint(containmentRelationship，systemType，0，1){ObjectConstraint(webapp，vdir，0，1)}}对象约束条件的上下文为第一对象定义(第一对象定义)。这意味着将在webapp的上下文中评估关系约束条件。此关系约束条件定义了两种可能的上下文，第一种是关系，将成为用作对象约束条件的上下文，而第二种是目标对象定义，其用作关系约束条件的上下文。5.RelationshipConstraint(containmentRelationship，webapp，0，1){group{RelationshipConstraint(containmentRelationship，vdir，0，1)RelationshipConstraint(containmentRelationship，directory，0，1)}}在此例中，我们利用一个组来包含将在Webapp上下文中评估的两个关系约束条件。除非解除至少一个关系并返回真，否则此组将产生一个错误。在此情况下，Webapp应包含一Vdir或一目录。3.7.3.2基本约束条件所有结构的约束条件源自一个被称为StructualConatraint的通用基本约束条件。每个结构的约束条件可包含一描述元素和设计数据。当所需约束条件失败时，此描述元素将作为错误消息返回。每个约束条件也具有一个名称和一个标识此约束条件是必需还是仅仅是一形成较大约束条件的一部分的标志。最后当评估约束条件时，约束条件的评估元素可用于指示。参看与约束条件评估相关的更多信息的3.7.3.7部分。<xscomplexTypename＝″StructuralConstrainr><xssequence><xselementname＝″Description″type＝″Description″minOccurs＝″0″/><xselementname＝″DesignData″type＝″DesignData″minOccurs＝″0″/></xssequence><xsatlributename＝″Name″type＝″SimpleName″use＝″required″/><xsattributename＝″Evaluate″type＝″ConstraintEvaluation″use＝″optional″/><xsattributename＝″Required″type＝″xsboolean″use＝″optional″/></xscomplexType>3.7.3.3对象约束条件一对象约束条件描述了关系中一或两个角色上的约束条件。此约束条件具有一名称，其用于在它失败的情况下辅助识别约束条件。此约束条件评估如下a)第一角色和第一定义与一对象实例是否匹配，而且假如被提供，第二角色和第二定义是否匹配一对象实例。假如这些不匹配，那么设置match＝0并跳到c)b)评估第一对象实例上下文中的所有嵌套约束条件。假如所有的评估计均为真，那么设置match＝1，否则设置match＝0。c)假如匹配>MinOccurs且匹配<MaxOccurs，那么设置result＝真，否则设置result＝假。d)假如请求为真且结果为假，则向用户返回一消息。e)向父上下文返回结果。<xscomplexTypename＝″ObjectConstraint″><xscomplexContent><xsextensionbase＝″StructuralConstraint″><xschoiceminOccurs＝″0″maxOccurs＝″unbounded″><xselementname＝″Constraint″type＝″ConstraintMember″/><xselementname＝″RelationshipConstraint″type＝″RelationshipConstraint″/><xselementname＝″RelationshipConstraintGroup″type＝″RelationshipConstraintGroup″/></xschoice><xsattributename＝″PrimaryRole″type＝″RolesList″use＝″required″/><xsaltributename＝″PrimaryObjectDefinition″type＝″QualifiedName″use＝″required″/><xsattributename＝″SecondaryRole″type＝″RolesList″use＝″optional″/><xsattributename＝″SecondaryObjectDeflnition″type＝″QualifiedName″use＝″optional″/><xsattributename＝″MinOccurs″type＝″MinOccurs″use＝″optional″/><xsattributename＝″MaxOccurs″type＝″MaxOccurs″use＝″optiona！″/></xsextension></xscomplexContent></xscomplexType>3.7.3.4对象约束条件组对象约束条件组允许多组对象约束条件的组合，从而它们可利用至少一语义来评估。除非组中至少一个约束条件被评估为真，否则此组将返回一错误。约束条件组进行如下评估a)依次评估每个嵌套约束条件组。假如至少一个被评估为真，那么设置result＝真，否则设置result＝假。b)假如result＝假且required＝真，那么产生一错误。c)向父上下文返回结果。<xscomplexTypename＝″ObjectConstraintGroup″><xscomplexContent><xsextensionbase＝″Constraint″><xssequence><xselementname＝″ObjectConstraint″type＝″ObjectConstraint″maxOccurs＝″unbounded″/></xssequence></xsextension></xscomplexContent></xscomplexType>3.7.3.5关系约束条件关系约束条件用于约束对象可参与的关系。一关系约束条件标识关系定义，可选地标识了在关系另一端的实例的对象定义和关系的基数。此约束条件被给定一名称，这样在错误消息中就可以识别它。关系约束条件的主体包含进一步提炼此约束条件的嵌套约束条件。关系约束条件可用于一些目的无需附加判定简单地利用基数，它们就能用于标识为一实例正确操作所提供的关系，利用判定，它们用于缩小当前实例希望交互作用的实例的配置。关系进行如下的评估a)设置matches＝0b)对于对象实例参与的每个关系实例a.关系定义与关系实例定义是否匹配，关系方向与目标角色所标识的方向是否匹配，而且假如提供了，目标对象定义与关系的另一端的实例定义是否匹配。假如这些都不匹配则跳到下一关系b.评估关系实例上下文中的所有嵌套约束条件。假如均评估为真，设置matches＝matches+1。c)假如matches＞MinOccurs且matches＜MaxOccurs则设置result＝真，否则设置result＝假。d)假如required为真result为假则向用户返回一消息。e)向父上下文返回结果。<xscomplexTypename＝″RelationshipConstraint″><xscomplexContent><xsextensionbase＝″StructuralConstraint″><xschoiceminOccurs＝″0″maxOccurs＝″unbounded″><xselementname＝″Constraint″type＝″ConstraintMember″/><xselementname＝″RelationshipConstraint″type＝″RelationshipConstraint″/><xselementname＝″RelationshipConstraintGroup″lype＝″RelationshipConstraintGroup″/><xselementname＝″ObjectConstraint″type＝″ObjectConstraint″/><xselementname＝″ObjectConstraintGroup″type＝″ObjectConstraintGroup″/></xschoice><xsattributename＝″RelationshipDefinition″type＝″QualifiedName″use＝″required″/><xsattributename＝″TargetRole″type＝″RolesList″use＝″required″/><xsattributename＝″TargetObjectDefinition″type＝″QualifiedName″use＝″optional″/><xsattributename＝″MinOccurs″type＝″MinOccurs″use＝″optional″/><xsattributename＝″MaxOccurs″type＝″MaxOccurs″use＝″optional″/><xsattributename＝″DelegationAware″type＝″xsboolean″use＝″optional″/></xsextension></xscompiexContent></xscomplexType>3.7.3.6关系约束条件组关系约束条件允许多组关系约束条件组合到一起，这使得可将它们评估为具有至少一语义的一个判定。约束条件组进行如下评计d)依次评估每个嵌套约束条件。假如至少一个被评估为真，那么设置result＝真否则设置result＝假。e)假如result＝假且required＝真，那么产生一错误。f)向父上下文返回结果。<xscomplexTypenam′e＝″RelationshipConstraintGroup″><xscomplexContent><xsextensionbase＝″StructuralConstraint″><xssequence><xselementname＝″RelationshipConstraint″type＝″RelationshipConstraint″maxOccurs＝″unbounded7></xssequence></xsextension></xscomplexContent></xscomplexType>3.7.3.7约束条件评估在三个明显的时机可评估一约束条件设计过程期间、一应用程序的配置过程中以及一旦配置了应用程序，在操作者想检查或更新应用程序配置的任何时候。评估一约束条件的时机改变了对约束条件有用的信息组。在设计期间评估的约束条件不能依赖于只在配置期间提供或在配置之后有效的值。在配置期间评估的约束条件不能依赖于只在配置之后有效的值。在配置之后评估的约束条件可访问应用程序中的任何设置。我们允许一约束条件开发者依据其何时运行来标记他们的约束条件。假如当输入无效时我们试着运行一约束条件，此信息用于避免即将发生的错误。编译器然后能检查一设计约束条件不依赖于它所知道的配置或确认之后才生效的值，同样它能检查一调度约束条件不依赖于它所知道在的配置之后才生效的值。假如编译器完全知晓何时设置将生效，那么可以计算可运行约束条件的时机，但不幸地，事实并非如此。为一设置提供值的时机可改变，例如，目录名可预先知道或可利用产生独一无二的标识符的算法在配置过程中创建一目录名。约束条件进行如下标记a)Design(设计)——指示了在设计期间、配置期间或验证期间可运行约束条件b)Deployment(配置)——指示了在配置或验证期间可运行约束条件c)Validation(验证)——指示了只能在验证期间运行约束条件d)Never(从不)——指示从不运行约束条件以下列举用于获得这些选项<xssimpleTypename＝″ConstraintEvaluation″><xsrestrictionbase＝″xsstring″><xsenumerationvalue＝″Design″/><xsenumerationvalue＝″Deployment″/><xsenumerationvalue＝″Validate″/><xsenumerationvalue＝″Never″/></xsrestriction></xssimpleType>可对结构的约束条件和约束条件成员设置约束条件的评估行为。在以上两种情况下，对结构的约束条件或约束条件成员应用所有的嵌套约束条件。约束条件默认地被标记为设计期间约束条件并且其可在任何期间运行。3.8授权授权的目的是允许一模型的开发者向一客机或父体公开主机或所包含的组件的特定行为。这允许开发者设计一个重用现有实施的组件，并提供一更全面的用于其客户机的实施。图19描述了一个利用授权向客机公开的主机的实施的例子。在图19，应用平台部件利用一授权关系向客机公开了主机的文件系统、操作系统组件、应用程序。这样，此应用平台无需直接实现它们便能控制操作系统哪部分对其客机有效的。图20描述了一个利用授权向父层公开一成员的实施的例子。在图20中，客户机应用程序公开了票务应用程序的定购服务端点。这允许票务应用程序然后将此端点连接到服务器应用程序，此服务器应用程序反过来将其端点授权给用户数据应用程序。3.8.1原则以下原则指导了授权模型的设计。·在目标系统中不存在代理。代理对于模型来说是方便的并且无物理显示。假如不为真，那么使用授权将对目标系统具有侧面影响。·代理不能改变授权的行为除非授权支持此改变。由于目标系统中不存在代理，代理只能改变模型而非实际的系统行为。假如授权公开了影响其行为的设置，那么和其他关系一样，授权关系可通过信息流来改变那些设置。·从一外部用户角度来看，用户不用知道一特殊实例是否是一代理或一实际实施。假如不为真，那么约束条件和信息流作者将不得不覆盖导致复杂和易碎代码的情况。·一用户能明确将代理作为约束条件表达的一部分。为了通过一部件边界实现控制行为的约束条件，这是必需的。3.8.2情况以下是描述在一系统中与利用授权相关的问题的两种情况3.8.2.1通信连接验证为验证一客户机端口能连接到一服务器端口，通信关系包含一通到此服务器的约束条件，然后返回此服务器主机，然后沿层3的通信关系返回，然后沿宿主关系到层4客户机并且最后返回通信关系。这在图21中示出。由于包含边界的存在，在两层的客户机和服务器之间存在授权关系。图22就描述了这样的一个例子。为写沿此路径的约束条件，用户应当能复制任意数量的这些关系，这使得约束条件的描述更复杂且减少了约束条件语言的可用性。为避免以上情况，我们需要用户能够不用事先知道是否将有代理且有多少代理的情况下写约束条件。3.8.2.2区域边界在数据中心，区域经常用于区分带有不同保密需要或行为的系统。当一通信关系与区域边界交叉时，用户希望在关系的行为上设置约束条件。例如，一用户希望只允许在一特定端点与后终端服务器之间http通信。为此，用户应该在通讯关系与区域边界交叉时能够标识该通信关系代理是他们唯一可取的方法。图23描述了区域边界的一个例子。在图23中，假如开发者希望约束从区域1到区域2的输出通信，那么他们将通过约束授权给区域边界的端点来实现。例如，他们可写一个只允许输入http且输出sql通信流的约束条件。此约束条件对区域公开的每个代理端点无效。为约束一代理，其对于约束条件应该是可视的。这意味着约束条件能将代理所参与的关系与实现此行为的授权分离开来。这使得在与不对用户透明的代理的情况相同先前情况下，期望的行为变得复杂。3.8.3与模型其他部分的交互作用利用如图24所示的例实例空间来描述授权的规则。3.8.3.1代理和授权代理应该与授权相同或是授权的一基本类。在如图24的例子中，作为一代理的b，应该与c相同是c的一基本定义，c是授权。因为代理b只能公开c的行为，所以这是必需的。假如允许区分类型，那么所公开的b的行为可与c的行为不同，但没有b的实现所需行为的物理显示。在此实例空间，一代理实例只能有一个授权，即只能有一个来自b的授权关系，其中b为此关系中的代理。此约束条件是必需的，因为没有它不可能返回授权的设置值或成员集合——运行期间不会知道选择哪个授权作为此值的源。3.8.3.2关系角色一代理可担当以下关系角色3.8，3.3成员过滤和路径解析代理只公开来自被定义为部分代理定义的授权的成员。在代理和授权定义相同的情况下，代理公开了所有授权的成员。当代理定义是授权定义的基本定义时，代理将只能公开那些两者定义通用的成员。以下给出的定义用于如图24的B和C<DefinitionName＝″B″><SettingDeclarationName＝″height″Definition＝″lnt″/></Definition><DefinitionName＝″C″Extends＝″B″><SettingDeclarationName＝″weight″Definition＝″lnt7></Definition>然后代理b将只公开高度设置而不公开重量设置。当在一代理上设置一设置值时，通过授权关系将此行为传递给授权直接将新设置值记录在授权上并且其对于任何指向此授权的其他代理均是可视的。当从一代理中检索一设置值时，请求被传递给授权并且直接从此授权返回设置值。对象和关系成员过滤与设置过滤工作方式相同。只有被声明为代理定义的一部分的公共成员被此代理公开。成员的改变立即影响授权的成员，并且其对于所有指向此授权的代理均是可视的。当一成员路径引用一代理的成员时，此路径自动解析成授权的成员。这意味着无论成员是代理或是授权都不改变此路径的语法。3.8.3.4关系过滤每个对象实例参与一组关系。这些关系用于评估约束条件和信息流，并且用于控制例示的过程。为实现向用户表示代理和授权的一致性，代理和授权都参与应该结合在一起的关系组。从此代理中，我们需要公开与代理关系结合的授权关系的子集。假如我们隐藏实现，那么此代理需要向用户返回其自身的包含关系，且可能只是一个授权得关系的小型子集。假如我们希望代理完全透明，那么我们就公开所有授权的关系并隐藏代理的关系。从此代理中，我们需要结合其代理参与的关系子集公开它的的直接关系。也就是说，假如一代理与另一端点具有通信关系，那么它应当表现为好像授权直接参与此关系一样。另一方面，我们不希望公开作为授权的一部分的代理的包含关系。由约束条件所造成的行为在3.8.3.6部分描述。3.8.3.4.1代理身份和关系过滤我们有两种代理——透明代理和不透明代理。当开发者希望向代理的客户机公开授权的实施时使用透明代理，而当开发者希望向授权的客户机隐藏代理的实施时使用不透明代理。3.8.3.4.1.1透明协议透明代理用于向客户机公开授权的实施。一典型的例子如图23所示，其中区域纯粹用作模型目的且不应隐藏它们包含的系统。在这种情况下，与区域2的Sql系统通信的开发者知道授权端点的实施是一Sql服务器而不是一区域。透明代理从授权而非服务器中返回所有标识信息。这意味着实例ID、定义、版本和包含信息都源自授权而非代理。当查询时，透明代理也将返回代理所参与的关系集而不是那些授权。3.8.3.4.1.2不透明代理不透明代理用于隐藏授权的实施，这使得开发者不需断开客户机便可自由改变实施。例如在图19中，IIS系统可利用不透明协议隐藏文件系统实施，这使得IIS的客户不依赖实现此文件系统的操作系统。不透明协议将从代理而不是授权中返回实例ID、定义和版本和包含信息。当查询时，不透明代理将只返回它所直接参与的不包括其授权关系的关系。3.8.3.5信息流指向一代理的信息流将无需知晓目标是一代理而不是实际实施，就可以自动重定向到授权。由于代理将对所有成员的请求发到与授权相关的实例，信息流得影响直接通过代理传送到授权。被声明为代理的一部分的信息流将不被评估。这是因为由于授权应当与代理定义相同或从代理定义导出，此信息流也将作为授权的一部分而进行评估。假如其被评估，我们将获得有关授权设置值的双重信息流错误。3.8.3.6约束条件约束条件可被写入用以让授权知晓也可不写入。假如一约束条件是一授权知晓，那么无需出现任何此代理所参与的关系，就其将在每个代理实例上进行评估。授权关系将对约束条件公开。例如，如图24从x指向b的一授权知晓通信约束条件将看到代理b及其x、c、d、e和i所参与的关系。然后假设它向c传递授权关系，则其可看到从c到b、f、h和g的关系。假如一约束条件未被标记为授权知晓，那么当评估指向一代理的关系时，此约束条件引擎将自动跳过透明代理。假如约束条件的目标实例是一代理，那么约束条件引擎将用授权替代它。此约束条件将不能看见授权关系。假如无授权知晓来评估相同约束条件，则该约束条件完全看不到b。取而代之，只能相对于c进行评估。当评估c时，其可看见在c和x、d、f、h、g、I之间的关系。应当注意在此情况下，我们使所有来自b的关系都出现，除了其包含关系，并且我们隐藏了授权关系。通过将一结构的约束条件(对象或关系约束条件——参看3.7.3部分)的DelegationAware属性设置为真，从而将一约束条件标记为授权知晓。声明作为代理定义的一部分进行的约束条件将不在代理上进行评估。这是因为此约束条件也将相对于授权被评估。而这对于代理和授权定义是通用的。3.9管理器管理器是类型和关系通过它将客户行为插入到运行期间环境的机制。对于其管理的每种类型，管理器可支持几个作用它能参与类型安装，它能提供类型的一CLR表达，它能涉及关于如何解析类型间结合的策略决定中，并且它能提供用于复杂约束条件和信息流的实施。由CLR揭示的所有的对象管理器作为强大名称类的输入点。与SDM其他类型相同的方式一样，对象管理器被打包并设置其版本；它们被分配在系统分布单元内，并且它们的版本和强大名称源自声明它们的SDM文件。<xscomplexTypename＝″ManagerDeclaration″><xssequence><xselementname＝″Description″type＝″Description″minOccurs＝″0″/></xssequence><xsattributename＝″Name″type＝″SimpleName″use＝″required″/><xsattributename＝″AssemblyName″type＝″xsstring″use＝″required″/><xsattributename＝″Version″type＝″FourPartVersionType″use＝″optional″/><xsattributename＝″PublicKeyToken″type＝″PublicKeyTokenType″use＝″optiona！″/><xsattributename＝″Culture″typr″CultureNeutral″use＝″optional″/><xsattributename＝″Platform″type＝″xsstring″use＝″optional″/><xsattributename＝″SourcePath″type＝″xsstring″use＝″optionai″/></xscomplexType>3.9.1作用一对象管理器能支持用于它所支持类型的一或多个作用。这些作用包括a)评估类型或关系的约束条件b)评估类型或关系的信息流c)构建/消除/更新一类型的支持d)公开一个用于类型或关系的设置的对象表达e)执行类型或关系的发现f)支持一类型或关系的设计表面特定UI3.9.2注意管理器依赖于其他管理器，但这些依赖应反映在用户管理器的SDM文件的导入语句。假如未描述这些依赖，那么将在运行期间将不能装载一特定管理器所依赖的其他管理器，并且管理器将不能运行。3.10设计数据和描述描述包含描述相关SDM元素的文本。此文本采用以DocumentLanguage属性标识的文档的语言。为支持文本定位，可提供一源标识符。运行期间将询问描述中识别的管理器或是否没应用默认管理器，该默认管理器用于与描述相关的定位文本的文档。<xscomplexTypename＝″Description″mixed＝″true″><xsattributename＝″ResourcelcPtype＝″xsstring″use＝″optional″/><xsattributename＝″Manager″type＝″QualifiedName″use＝″optiona！″/></xscomplexType>Adesigndatatypecontainsstructureddatathatdefinedbyadesignsurface.Eachdesignsurfaceshouldusetheirownschematoidentifyandtostricturethedata.<xscomplexTypename＝″DesignData″><xssequence><xsanynamespace＝″##other″processContents＝″lax″minOccurs＝″0″maxOccurs＝″unbounded″/></xssequence></xscomplexType>3.11SDM文档结构SDM文档提供了用于一组关系、对象和管理器的强大身份、版本和定位信息。<xselementname＝″SystemDefinitionModer><xscomplexType><xssequence><xselementname＝″lnformation″type＝″lnformation″minOccurs＝″0″/><xselementname＝″lmport″type＝″lmport″minOccurs＝″0″maxOccurs＝″unbounded″/><xselementname＝″DesignData″type＝″DesignData″minOccurs＝″0″/><xselementname＝″SettingDefinitions″type＝″SettingDefinitions″minOccurs＝″0″/><xschoiceminOccurs＝″0″maxQccurs＝″unbounded″><xselementname＝″CommunicationDefinition″type＝″CommunicationDefinition″/><xselementname＝″ContainmentDefinition″type＝″ContainmentDefinition″/><xselementname＝″DeIegationDefinition″type＝″DelegationDefinition″/><xselementname＝″ReferenceDefinition″type＝″ReferenceDefinition″/><xselementname＝″HostingDefinition″type＝″HostingDefinition″/><xselementname＝″EndpointDefinition″type＝″EndpointDefinition″/><xselementname＝″ResourceDefmition″type＝″ResourceDefinition″/><xselementname＝″SystemDefinition″type＝″SystemDefinition″/><xselementname＝″ConstraintDefinition″type＝″ConstraintDefinition″/><xselementname＝″FlowDefinition″type＝″FlowDefinition″/><xselementname＝″Manager″type＝″ManagerDeclaration″/></xschoice></xssequence><xsattributeGroupref＝″Namespaceldentity″/><xsattributename＝″DocumentLanguage″type＝″Culture″/></xscomplexType></xselement>3.11.1信息SDM文档的信息部分包含支持SDM文档的识别和管理的人类可读信息。<xscomplexTypename＝″Information″><xsannotation><xsdocumentation>HumanreadableinformattonabouttheSDMDefinitionlibrary.</xsdocumentation></xsannotation><xssequence><xselementname＝″FriendlyName″type＝″xsstring″minOccurs＝″0″/><xselementname＝″CompanyName″type＝″xsstring″minOccurs＝″0″/><xselementname＝″Copyright″type＝″xsstring″minOccurs＝″0″/><xselementname＝″Trademark″type＝″xsstring″minOccurs＝″0″/><xselementname＝″Description″type＝″Description″minOccurs＝″0″/><xselementname＝″Comments″type＝″xsstring″minOccurs＝″0″/></xssequence></xscomplexType>计算机环境举例图25描述了一通用计算机环境800，其可用于实现这里所描述的技术。计算机环境800只是计算机环境的一个例子，并不对计算机和网络结构的使用或功能范围做任何限制。计算机环境800不解释为涉及具有典型计算机环境800所述的组件或其组合的依赖性或要求。计算机环境800包括一通用目的的计算设备，其形式为计算机802。计算机802可以是，例如，图1中的计算设备102，或图2中的实现开发系统202或有效部件208。计算机802的部件可包括但不局限于，一或多个处理器或处理单元804，一系统存储器806以及将包括处理器804的各系统组件耦合到系统存储器806的一系统总线808。系统总线808表示几种总线结构中的一或多个，其包括一存储器总线或存储控制器、一外围总线、一加速图形端口以及一处理器或采用任意一种总线结构的局域总线。例如，此总线结构可包括工业标准结构(ISA)总线，微通道结构(MCA)总线，增强ISA(EISA)总线、视频电子标准协会(VESA)局域总线以及也称之为夹层总线的外设部件互连(PCI)总线，。计算机802典型地包括多种计算机可读介质。此介质可以是计算机802可访问的任何可用得介质并且包括易失性和非易失性介质、可移动和不可移动介质。系统存储器806包括易失性存储器形式的计算机可读介质，例如随机存储器(RAM)810，和/或非易失性存储器，例如只读存储器(ROM)812。一存储在ROM812中的基本输入/输出系统(BIOS)814，其包含有助于在计算机802内的元素之间传输信息的基本例程，例如在启动过程中。RAM810典型地包含处理单元804可即时访问和/或操作的数据和/或程序模型计算机802也可包括其他可移动/不可移动、易失性/非易失性计算机存储介质。例如，图25描述了一个用于读出和写入一不可移动非易失性磁介质(未示出)的硬盘驱动器816、一个用于读出和写入一可移动非易失性磁盘驱动器820(例如，一“软盘”)的磁盘驱动器818、以及一个用于读出和/或写入诸如一CD-ROM、DVD-ROM或其他光介质的一可移动非易失性光盘824的光盘驱动器822。硬盘驱动器816、磁盘驱动器818和光盘驱动器822都通过一或多个数据介质接口826与系统总线808相连。可选地，硬盘驱动器816、磁盘驱动器818和光盘驱动器822可通过一或多个接口(未示出)与系统总线808相连。盘驱动器及其相关的计算机可读介质提供了计算机可读指令、数据结构、程序模型及其他计算机802的数据的非易失性存储器。尽管此例描述了一硬盘816、一可移动磁盘820以及一可移动光盘824，也可以理解存储计算机可访问数据的其它类型的计算机可读介质也能用于实现典型的计算机系统和环境，例如盒式磁带或其它磁性存储设备、闪存卡、CD-ROM、数字化通用盘(DVD)或其它光学存储器、随机访问存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)等。任何数量的程序模块都可以存储在硬盘816、磁盘820、光盘824、ROM812和/或RAM810中，包括例如，一操作系统826、一个或多个应用程序828、其它程序模型830和程序数据832。此操作系统826、一或多个应用程序828、其他程序模块830和程序数据832或它们的组合中的每一个均可实现支持分布式文件系统的所有或部分常驻组件。用户可经由诸如键盘834和指示设备836(例如一“鼠标”)的输入设备将命令和信息输入到计算机802中。其他输入设备838(未特别示出)可包括一麦克风、操纵杆、游戏盘、卫星天线、串行端口、扫描仪等。这些和其他输入设备经由耦合到系统总线808的输入/输出接口840与处理单元804相连，也可通过其他接口和总线结构，例如一并行端口，游戏端口或一通用串行总线(USB)连接。监视器842或其他类型的显示设备也可经由接口，例如一视频适配器844，与系统总线808相连。除监控器842之外，其他输出外设可包括诸如扬声器(未示出)组件和一个经由输入/输出接口840与计算机802相连的打印机846。利用与一个或多个例如一远程计算设备848的远程计算机的连接，，计算机802可工作在网络环境中。例如，远程计算设备848可以是一个人计算机、便携式计算机、一服务器、一路由器、一网络计算机、一对等设备或其他通用网络结点等。远程计算设备848被表示为一便携式计算机，其包括许多或所有此处描述的与计算机802相关的元素和特征。在计算机802和远程计算机848之间的逻辑连接被描述为一局域网(LAN)850和一通用广域网(WAN)852。此网络环境通常在办公室、公司范围的计算机网络、内部网和Internet。当在一LAN网络环境中实施时，计算机802经由一网络接口或适配器854与局域网850相连。当在一WAN网络环境中实施时，计算机802典型地包括一调制解调器856或其他与广域网852通信的装置。可在计算机802的内部或外部的调制解调器856，，经由输入/输出接口840或其他适当结构与系统总线808相连。可以理解所描述的网络连接是典型的并且可使用其他方式建立计算机802和848之间的通信链接。在一网络环境中，例如计算环境800的描述，与计算机802相关的程序模块，或其中的部分，可存储在远程存储设备中。例如，远程应用程序858驻留在远程计算机848的存储设备中。为方便描述，应用程序和其他诸如操作系统的可运行程序组件被描述为不连续块，尽管此程序和组件在不同时段驻留在计算设备802的不同存储组件中，并由计算机的数据处理器执行。此处将描述在计算机可运行指令的通用上下文中的由一或多个计算机或其他设备执行的不同模块和技术，例如程序模块。通常，程序模块包括执行特殊任务或实现特殊抽象数据类型的例程、程序、对象、组件、数据结构等。典型地，在各实施例中可根据需要合并或分布程序模块的功能。这些模块和技术的实施存储在或通过一些形式传送到计算机可读介质。计算机可读介质可以是任何计算机可访问的有效介质。例如，但不限于，计算机可读介质可包括“计算机存储介质”和“通信介质”。“计算机存储介质”包括以任何信息存储的方法或技术实现的易失性和非易失性、可移动和不可移动介质，此信息例如是计算机可读指令、数据结构、程序模块或其他数据。计算机存储介质包括，但不局限于，RAM、ROM、EEPROM、闪存或其他存储技术、CD-ROM、数字通用磁盘(DVD)或其他光学存储器、盒式磁带、磁带、磁盘存储器或其它磁性存储设备，或任何其它可用于存储所需信息且计算机可访问的介质。“通信介质”典型地是计算机可读指令、数据结构、程序模块或在调制数据信号中的其他数据，例如载波或其他传送机制。通信介质也包括任何信息传递介质。术语“调制数据信号”的意思是具有一个或多个特征设置或通过与编码此信号中信息相同的方式来改变的信号。例如，但不限于，通信介质包括诸如一有线网络或直接有线连接的有线介质，以及诸如声音、RF、红外的无线介质以及其它无线介质。上述内容的任何组合都包括在计算机可读介质范围内。可选地，可用硬件或硬件、软件和/或固件的组合来实现框架部分。例如，可设计或编程一或多个专用集成电路(ASIC)或可编程逻辑设备(PLD)来实现一个或多个框架部分。结论尽管本发明已经用特定于结构特征和方法行为的语言进行了描述，但是可以理解由所附权利要求所限定的本发明并不局限于所述特定特征或行为。相反地，所述特定特征和行为仅仅是实现所要求保护的发明的示例性的形式。权利要求1.一种方法，包括接收一个将要设计的系统的描述；接收一个将要设计的环境的描述；以及在所述系统正在设计期间并且将要配置所述系统之前，利用这两个所接收的描述相对于所述环境验证所述系统。2.如权利要求1中所述的方法，所述系统的描述包括一个SDM文档。3.如权利要求1中所述的方法，所述环境的描述包括一个LIM文档。4.如权利要求1中所述的方法，所述系统包括一个软件应用程序，并且所述环境包括一个数据中心。5.如权利要求1中所述的方法，所述环境包括一个在其中预期部署所述系统的环境。6.一种或多种计算机可读媒体，其上存储了多条指令，当一个或多个处理器执行该指令时，能够使所述一个或多个处理器在一或多个处理器运行地程序设计过程中，访问描述了系统的系统描述；以及利用所述系统描述，相对于一个模拟的环境验证所述系统。7.如权利要求6所述的一种或多种计算机可读媒体，所述多条计算机指令进一步使所述处理器从一个请求者那里接收一个验证所述系统的请求；以及向所述请求者返回所述验证的结果。8.如权利要求6所述的一种或多种计算机可读媒体，其中使所述一个或多个处理器相对于所述模拟的环境验证所述系统的指令进一步使所述一个或多个处理器从所述系统描述中选择一个最高级定义；为一个实例空间，产生一个由最高级定义所描述的适当的实例；选择嵌套在所述最高级定义中的附加定义；根据所述选择的定义是限定了一个对象还是一个关系，为所述实例空间，产生一个由附加定义所描述的适当实例；以及继续进行所述附加定义的选择以及如所述附加定义所描述的适当实例产生，直到为所述实例空间产生了嵌套在所述最高级定义中的所有定义的实例为止。9.如权利要求6所述的一种或多种计算机可读媒体，其中使所述一个或多个处理器相对于所述模拟的环境验证所述系统的指令进一步使所述一个或多个处理器识别一个实例空间中的一个或多个信息流，所述实例空间描述了所述系统；为一个或多个信息流中的至少一个信息流的每一个识别所述信息流的一个或多个输入值，所述输入值从所述实例空间中的其它实例中获得；以及至少部分地根据所述输入值，产生所述信息流的输出值。10.如权利要求6所述的一种或多种计算机可读媒体，其中使所述一个或多个处理器相对于所述模拟的环境验证所述系统的指令进一步使所述一个或多个处理器识别一个实例空间中的一个或多个约束条件，所述实例空间描述了所述系统；检查是否满足了所述一个或多个约束条件；以及对于所述一个或多个约束条件的每一个，返回表示是否满足所述约束条件的一个值。11.一种装置，包括加载器，其被配置为加载一个或多个描述了一个系统的文档，所述加载所述一个或多个文档时，所述系统正在被设计；模拟器，其被配置为模拟了一个数据中心的环境，并且相对于所述环境验证所述系统；以及所述装置与所述数据中心相分离。12.如权利要求11所述的装置，其进一步包括扩展引擎，其用于从所述一个或多个文档中的其中之一中识别一个最高级定义，并且通过例示嵌套在所述作高级定义中的成员，扩展所述最高级定义，来填充一个实例空间。13.如权利要求12所述的装置，其进一步包括信息流引擎，其用于识别所述实例空间中的信息流，识别输入到所述信息流中的所述值，以及根据所述信息流的所述输入，设置所述信息流的一个输出。14.如权利要求13所述的装置，其进一步包括约束条件引擎，其用于识别和评估所述实例空间中的约束条件。15.一种或多种计算机可读媒体，其上存储了多个指令，当一个或多个处理器执行该指令时，能够使所述一个或多个处理器访问一个描述了一个系统的文档，所述系统被设计用于一个数据中心的环境中；从所述文档中选择一个最高级定义；为一个实例空间，产生一个由所述最高级定义所描述的适当实例；选择嵌套在所述最高级定义中的附加定义；根据所述选择的定义限定的是一个对象还是一个关系，为所述实例空间，产生一个由所述附加定义所描述的适当实例；以及继续进行所述附加定义的选择以及如所述附加定义所描述的适当实例的产生，直到为所述实例空间产生了嵌套在所述最高级定义中的所有定义的实例为止。16.如权利要求15所述的一种或多种计算机可读媒体，其中当所述选择的定义限定了一个关系时，使所述一个或多个处理器产生一个如所述附加定义描述的适当实例的所述系统指令进一步使所述一个或多个处理器根据包含在所定义的关系中的许多源实例和许多目标实例，识别许多要创建的关系实例；创建所标识的数量的关系实例；以及为每个所创建的关系实例，将源和目标实例与所述关系实例相联系。17.如权利要求16所述的一种或多种计算机可读媒体，所述选择的定义限定了一个包含关系，该包含关系描述了一个实例可以包含在另一个实例中。18.如权利要求16所述的一种或多种计算机可读媒体，所述选择的定义限定了一个通信关系，该通信关系描述了在独立部署的软件元素之间的交互关系。19.如权利要求16所述的一种或多种计算机可读媒体，所述选择的定义限定了一个引用关系，该引用关系用于捕获实例间的从属关系。20.如权利要求16所述的一种或多种计算机可读媒体，所述选择的定义限定了一个宿主关系，该宿主关系将一个主机和一个或多个其客机成员实例相联系。21.如权利要求16所述的一种或多种计算机可读媒体，所述选择的定义限定了一个授权关系，该授权关系将两个系统的通信端点相联系。22.如权利要求15所述的一种或多种计算机可读媒体，其中当所述选择的定义限定了一个关系时，使所述一个或多个处理器产生一个如所述附加定义描述的适当实例的所述系统指令进一步使所述一个或多个处理器识别在所选择的定义中标识的所述对象的最小出现次数；根据所标识的最小出现次数和已经产生了所选定义的多少个实例，识别要产生的所选定义的实例的数量；以及产生所识别数量的所选定义的实例。23.如权利要求15所述的一种或多种计算机可读媒体，其中其中当所述选择的定义限定了一个对象时，使所述一个或多个处理器产生一个如所述附加定义描述的适当实例的所述系统指令进一步使所述一个或多个处理器触发一个事件，该事件允许一监听器创建由所述附加信息描述的所述适当实例。24.如权利要求15所述的一种或多种计算机可读媒体，其中中当所述选择的定义限定了一个关系时，使所述一个或多个处理器产生一个如所述附加定义描述的适当实例的所述系统指令进一步使所述一个或多个处理器触发一个事件，该事件允许一监听器创建由所述附加信息描述的所述适当实例。25.如权利要求15所述的一种或多种计算机可读媒体，其中在开始在所述数据中心中部署所述系统之前，执行所述指令。26.一种或多种计算机可读媒体，其上存储了多条指令，当一个或多个处理器执行该指令时，能够使所述一个或多个处理器识别一个实例空间中的一个或多个信息流，所述实例空间描述了为了用于数据中心的环境中而设计的系统；为一个或多个信息流中的至少一个信息流的每一个识别所述信息流的一个或多个输入值，所述输入值从所述实例空间中的其它实例中获得；以及至少部分地根据所述输入值，产生所述信息流的输出值。27.如权利要求26所述的一种或多种计算机可读媒体，其中使所述一个或多个处理器识别所述信息流的一个或多个输入值的所述指令进一步使所述一个或多个处理器识别是否已经指定了输入值；如果已经指定了输入值，那么从其它的实例中获得所述输入值；如果至少一个所述输入值还没有被指定，那么对于每一个还没有被指定的所述输入值识别设定所述输入值的一个其它的信息流；识别所述其它信息流的一个或多个输入值，所述输入值从所述实例空间的其它实例中获得；以及至少部分地根据所述输入值，产生所述其它信息流的一个输出值。28.如权利要求26所述的一种或多种计算机可读媒体，其中使所述一个或多个处理器至少部分地根据所述输入值产生所述其它信息流的所述输出值的所述指令进一步使所述一个或多个处理器识别与所述信息流相关的一组指令，所述指令可以被执行以产生一个结果；执行所识别的指令组；以及用所产生的结果作为所述信息流的所述输出值。29.如权利要求26所述的一种或多种计算机可读媒体，所述系统包括一个部署在所述环境中的应用程序。30.如权利要求26所述的一种或多种计算机可读媒体，所述环境包括一数据中心的一硬件描述。31.如权利要求26所述的一种或多种计算机可读媒体，其中在开始在所述环境中部署所述系统之前，执行所述指令。32.一种或多种计算机可读媒体，其上存储了多个指令，当一个或多个处理器执行该指令时，能够使所述一个或多个处理器识别一个实例空间中的一个或多个约束条件，所述实例空间描述了一个为用于一数据中心的环境中而设计的系统；检查是否满足了所述一个或多个约束条件；以及对于所述一个或多个约束条件，返回表示所述约束条件是否满足的一个值。33.如权利要求32所述的一种或多种计算机可读媒体，所述一个或多个约束条件包括设定约束条件、关系约束条件以及对象约束条件。34.如权利要求32所述的一种或多种计算机可读媒体，其中使所述一个或多个处理器检查是否满足所述一个或多个约束条件的所述指令进一步使所述一个或多个处理器为所述约束条件的其中之一识别与所述信息流相关的一组指令，所述指令可以被执行以产生一个结果；执行所识别的指令组；以及用所产生的结果作为表示所述约束条件是否满足的所述返回值。35.如权利要求32所述的一种或多种计算机可读媒体，其中使所述一个或多个处理器检查是否满足所述一个或多个约束条件的所述指令进一步使所述一个或多个处理器为所述约束条件的其中之一识别所述约束条件的目标实例的角色和对象定义；检查所述约束条件的所述角色和所述对象定义是否与所述目标实例的角色和对象定义相匹配；以及根据所述约束条件的所述角色和所述对象定义是否与所述目标实例的角色和对象定义相匹配，产生表示所述约束条件是否满足的所述返回值。36.如权利要求35所述的一种或多种计算机可读媒体，其中使所述一个或多个处理器检查是否满足所述一个或多个约束条件的所述指令进一步使所述一个或多个处理器为所述约束条件的其中之一识别所述约束条件的所述目标实例的第二角色和第二对象定义；检查所述约束条件的所述第二角色和所述第二对象定义是否与所述目标实例的所述角色和所述对象定义相匹配；以及根据所述约束条件的所述角色和所述对象定义是否与所述目标实例的所述角色和所述对象定义以及所述目标实例的所述第二角色和所述第二对象定义相匹配，产生表示所述约束条件是否满足的所述返回值。37.如权利要求35所述的一种或多种计算机可读媒体，其中使所述一个或多个处理器检查是否满足所述一个或多个约束条件的所述指令进一步使所述一个或多个处理器为所述约束条件的其中之一评估所述目标实例的一个或多个嵌套约束条件；接收所述嵌套约束条件的一个或多个返回值，所述一个或多个返回值表示所述一个或多个嵌套约束条件是否满足；以及根据所述嵌套约束条件的所述一个或多个返回值，产生表示所述约束条件是否满足的返回值。38.如权利要求32所述的一种或多种计算机可读媒体，其中使所述一个或多个处理器为每个所述一个或多个约束条件返回一个表示所述约束条件是否满足的值的所述指令，进一步使所述一个或多个处理器为所述约束条件的其中之一如果将返回的值表示所述约束条件没有满足，那么检查是否产生了所述约束条件的一个错误消息；以及如果产生了所述错误消息，那么产生包括标识所述约束条件的信息的所述错误消息。39.如权利要求32所述的一种或多种计算机可读媒体，其中使所述一个或多个处理器检查是否满足所述一个或多个约束条件的所述指令进一步使所述一个或多个处理器为所述约束条件的其中之一初始化一个匹配计数变量；识别所述约束条件的所述目标实例参与的一个或多个关系实例；为所述一个或多个关系实例中的每一个，评估所述关系实例是否满足所述约束条件；对于满足所述约束条件的所述一个或多个关系实例中的每一个，增加所述匹配计数变量；以及根据评估了所述一个或多个关系实例后的所述匹配计数变量的值，产生表示所述约束条件是否满足的返回值。40.如权利要求39所述的一种或多种计算机可读媒体，其中使所述一个或多个处理器为每个所述一个或多个关系实例评估所述关系实例是否满足所述约束条件所述指令，进一步使所述一个或多个处理器为所述约束条件的其中之一检查所述约束条件的一关系定义是否与所述关系实例的一关系定义相匹配；检查所述约束条件的一指向是否与所述关系实例的一指向相匹配；检查是否所述关系实例的所有的嵌套约束条件都满足；以及如果所述约束条件的所述关系定义与所述关系实例的所述关系定义相匹配，所述约束条件的所述指向与所述关系实例的所述指向相匹配以及所述关系实例的所有的嵌套约束条件都满足，那么就返回一个表示所述约束条件满足的值。41.如权利要求39所述的一种或多种计算机可读媒体，其中使所述一个或多个处理器为每个所述一个或多个关系实例评估所述关系实例是否满足所述约束条件所述指令，进一步使所述一个或多个处理器为所述约束条件的其中之一检查所述约束条件的一目标对象是否与所述关系实例的另一方实例相匹配；如果所述约束条件的所述关系定义与所述关系实例的所述关系定义相匹配，所述约束条件的所述指向与所述关系实例的所述指向相匹配，所述关系实例的所有的嵌套约束条件都满足以及所述约束条件的所述目标对象与所述关系实例的所述另一方实例相匹配，那么就返回一个表示所述约束条件满足的值。42.如权利要求39所述的一种或多种计算机可读媒体，其中使所述一个或多个处理器根据评估所述一个或多个关系实例后的所述匹配计数变量的值，产生表示所述约束条件是否满足的所述返回值的所述指令，进一步使所述一个或多个处理器为所述约束条件的其中之一检查所述匹配计数变量是否至少是所述约束条件的一最小值并且不大于所述约束条件的一最大值；以及如果所述匹配计数变量至少是所述约束条件的所述最小值并且不大于所述约束条件的所述最大值，那么产生表示满足所述约束条件的所述返回值，否则产生表示所述约束条件不满足的返回值。43.如权利要求32所述的一种或多种计算机可读媒体，其中在将所述系统配置到所述系统中之前，执行所述指令。全文摘要根据系统设计期间的验证的一个某些的方面，要接收将被设计的系统的描述和环境的描述。这些描述都用于在设计系统时以及在配置系统之前对照环境来验证系统。文档编号G06Q50/00GK1570860SQ200410032700公开日2005年1月26日申请日期2004年3月5日优先权日2003年3月6日发明者G·奥斯莱德,K·格里利希,R·门辛,B·塔巴拉,R·V·维兰德申请人:微软公司