CN1619490A - 系统的集成设计，部署和管理阶段 - Google Patents

Abstract

根据某一方面，一个系统的集成设计，部署和管理阶段，包括使用一个系统定义模块来设计一个系统。接着，在一个或多个计算装置上，使用该系统定义模块部署该系统，并且，在系统部署之后，使用该系统定义模块管理在一个或多个计算装置上所部署的系统。

Description

系统的集成设计，部署和管理阶段

相关申请

本申请要求2003年3月6日提交的，名为“用于分布式计算系统的架构以及分布式应用的自动设计，部署和管理”的美国临时申请第60/452,736号的优先权，其在此合并作为参考。

本申请涉及下列美国专利申请(在此将其全部合并作为参考)：

2003年3月6日提交的，题目为“虚拟网络拓扑结构的产生”的美国专利申请序号第10/382,942号，在此合并作为参考。

2000年10月24日提交的，题目为“用于共享计算机的分布式管理的系统和方法”的美国专利申请序号第09/695,812号，在此合并作为参考。

2000年10月24日提交的，题目为“用于分布式计算机系统的逻辑建模的系统和方法”的美国专利申请序号第09/695,813号，在此合并作为参考。

2000年10月24日提交的，题目为“用于分布式计算机的数据传送约束和软件组件管理的系统和方法”的美国专利申请序号第09/695,820号，在此合并作为参考。

2000年10月24日提交的，题目为“利用数据包过滤器和网络虚拟化以约束网络通信”的美国专利申请序号第09/695,821号，在此合并作为参考。

2000年10月24日提交的，题目为“用于设计分布式计算机系统的一个逻辑模型，并根据所述逻辑模型部署物理资源的系统和方法”的美国专利申请序号第09/696,707号，在此合并作为参考。

2000年10月24日提交的，题目为“在一个多计算机服务应用程序中，提供自动政策执行的系统和方法”的美国专利申请序号第09/696,752号，在此合并作为参考。

技术领域

本发明涉及用于一个分布式计算系统的架构。

背景技术

互联网的使用，在过去的几年中迅速增长并持续发展。人们对于在万维网(或简称为″网络″)上提供的，诸如电子邮件，在线购物，搜集新闻和信息，收听音乐，观看视频剪辑，寻找工作等等之类的许多服务，变得非常满意。为了跟上对基于互联网的服务的需要的发展，从而在用于主网点计算机系统中，存在提供用于站点的后台服务，和存储与站点相关的数据的巨大增长。

分布式计算机系统的一种类型，是一资源处理中心(诸如一互联网资源处理中心(IDC)或一企业资源处理中心(EDC))，是一种专门设计的复杂的、放置有许多用于基于网络主服务的计算机。资源处理中心，也可以被称为“网页农场(webfarms)”或“服务器农场(server farms)”，一般在气候控制，物理保密的建筑物中，放置成百上千的计算机。典型地，资源处理中心提供可靠的Internet访问，可靠的能源供应以及安全的操作环境。

目前，大型的资源处理中心都是复杂的、且调用主多级应用程序(hostmultiple application)。例如，一些网点可以操作数千个计算机，并容纳许多分布式应用程序。这些分布式应用程序，通常具有需要(require)操作者将计算机物理连接至某一网络交换机(neting switch)的复杂网络要求(requirement)，并手动地安排(arrange)所述资源处理中心内部的电线结构，从而支持所述复杂的应用程序。因此，这种构造使物理网络拓扑结构与所述应用程序的要求相一致的任务，是一个麻烦的，费时的过程，也就是说，存在人为误差的倾向。因此，存在提高在所述物理的计算机系统上设计并部署分布式应用程序的技术的需要。

概要

在这里，描述了系统的集成设计，部署和管理阶段。

根据某一方面，使用一系统定义模型设计一个系统。随后，使用所述系统定义模型，从而在一个或多个计算机上部署所述系统。在部署所述系统以后，使用所述系统定义模型，从而在一个或多个计算装置上管理所部署的系统。

附图的简要描述

全部附图中，相同的数字指相同的特征。

附图1说明了一个网络设置的实例。

附图2说明了一个使用SDM定义模型的架构的实例的框图。

附图3说明了一个分层设置的实例。

附图4说明了一个在一个系统的整个生命周期中，使用系统定义模型(SDM)的处理的实例的流程图。

附图5说明了一个使用SDM运行时间的架构的实例。

附图6说明了一个SDM文档的实例。

附图7说明了一个基本定义以及成员。

附图8说明了一个成员的实例。

附图9说明了一个设置值以及值列表的实例。

附图10说明了根据某一实施例，一个SDM应用程序的生命周期的实例。

附图11示出了一个将一个网络应用程序映射至一个网络服务器主机的实例。

附图12说明了一个嵌入数据类型的层次的实例。

附图13说明了一个抽象对象定义的隐含的扩充的实例。

附图14说明了一个抽象关系的隐含的扩充的实例。

附图15说明了一个更改请求的实例。

附图16说明了一个将新的定义载入所述运行时间的处理的实例。

附图17说明了一个执行更改请求的实例。

附图18说明了相连接的成员的实例。

附图19说明了关于连接的结构的实例。

附图20说明了一个提供范例空间的概述的UML框图的实例。

附图21说明了一个可用于执行在这里所描述的技术的通用计算机环境。

详细说明

以下公开的内容，描述了关于用于设计和执行具有大规模应用程序服务的一个分布式计算系统的一个架构的多个方面。所述公开内容包括一个系统定义模型(SDM)的论述，其也可以称为一个服务定义模型(SDM)，以及一个SDM运行时间环境。所述SDM向一个应用程序架构设计者提供工具和一个上下文环境(context)，从而以一种抽象的方式，设计分布式计算机应用程序以及资源处理中心。所述模型定义表示所述应用程序的功能单元的一组元素，所述应用程序，最终通过物理的(physical，或改“实际的”)计算机资源和软件执行。与所述模型元素相关的，是一个指示如何指定通过所述组成部分表示的功能操作的模式。

如同这里所使用的，所述术语“有线”也可以称为“连接”，“通信”，或“通信关系”。同样，所述术语“系统”可以称为“模块”，并所述术语“资源空间”可以称为“资源”。另外，所述术语“应用程序空间”也可以称为“应用程序”，且所述术语“范例空间”也可以称为“范例”。此外，所述术语“类”可以也称为“摘要定义”，所述术语“端口”也可以称为“端点”，且所述术语“类型”可以也称为“定义”。

附图1说明了一个网络100的实例。在设置100中，多个(x个)计算装置102(1)，102(2)…102(x)与一网络106相耦合。网络106用于表现各种传统的网络拓扑结构和类型(包括有线和/或无线网络)中的任何一种，使用各种传统的网络协议(包括公共和/或专有协议)中的任何一种。例如，网络106可以包括，一局域网(LAN)，一广域网(WAN)，所述互联网的部分，等等。设置100表现多种设置的任何一种，包括例如，资源处理中心(例如，互联网资源处理中心(IDCs))，办公室或商业设置，家庭设置，教育或研究所，零售或销售设置，数据存储设置，等等。

计算装置102可以是各种传统计算装置的任何一种，包括台式PC，工作站，大型机，服务器计算机，互联网设备，游戏控制器，便携式计算机，蜂窝电话，个人数字助理(PDA)等等。一个或多个装置102可以是相同类型的装置，或可选择的，是不同类型的装置。另外，即使多个装置是相同类型的装置，所述多个装置仍可以进行不同的配置(例如，两个装置102可以是服务器计算机，但可以具有不同的硬件配置，例如，不同的处理器，不同数量的RAM，不同大小的硬盘驱动器等等)。

一个或多个计算装置102在加入设置100之后，也可以进行重新配置。例如，可以在一时间段(例如，类似于分钟，小时，天，月等等)运行一特定计算装置102，以执行一种功能，然后，一个管理员可以确定所需的一种不同的功能(例如，从一服务器计算机改变为一工作站计算机，从一网页服务器改变为一本地文件服务器等等)。

附图2是说明一个使用系统定义模型架构200的实例的框图。所述SDM设计为能够在整个系统的生命周期中使用。一个系统，是能够协调工作，以实现一种普通功能的一组相关的软件和/或硬件资源。上述系统的一个实例是一个应用程序，该应用程序涉及能够通过一计算装置运行或执行，从而实现不同的功能性的一组指令。应用程序的实例包括诸如游戏程序的娱乐应用程序，诸如文字处理的生产性应用程序，诸如电子百科全书的参考文献应用程序，诸如网页服务或金融分析的分布式应用程序等等。上述系统的另一个实例是一个环境，该环境上能够部署一应用程序(或另一环境)。涉及软件和/或硬件资源的一个环境，该环境上能够部署一应用程序(或另一环境)。上述环境能够按照以下的详细描述进行分层。

一个系统的生命周期，典型的，包括三个主要的阶段(也称为时期)：一个设计或开发阶段，接着是一个部署或安装阶段，接着是一个操作或管理阶段。随着将所述模型应用至一个系统的生命周期的全部三个阶段，因此，所述模型可以被看作一个系统的生命周期种的不同阶段的一个集成点(integration point)，并辅助这些阶段的每一个。另外，通过使用所述模型，能够在这些阶段之间进行知识的传送，诸如：关于系统的管理的知识(例如，反馈至所述设计和开发组，允许所述设计和开发组修改所述系统，诸如用于未来的版本或改善当前版本的性能)；所述知识的结构，部署系统的要求和操作性行为；从所述台式机到所述资源处理中心的操作环境的知识；如同最终用户所观察到的所述服务级(level)的知识等等。

通常，在所述设计阶段，利用(leveraging)所述SDM的开发工具，可以用于定义一个包括通信软件和硬件组成部分的系统。一个系统定义包括部署和操作一个分布式系统的全部信息，包括所需资源，配置，操作特征，策略(policies)等等。在所述部署阶段，应用所述系统定义，以自动部署所述系统，并动态分配和配置所需的所述软件及硬件(例如，服务器，存储器和网络)资源。相同的系统定义能够用于部署不同的主机(host)环境和不同的规模。在所述管理阶段，所述操作系统中的一个SDM服务，提供了用于管理所述系统的一个系统级(level)视图(view)。这使新的管理工具能够驱动资源分配，配置管理，更新和一个系统透视图的过程自动化(process automation)。

所述架构200使用所述SDM定义模型，以及在所述SDM定义模型中定义功能操作的模式(schema)。所述定义模型包括各种不同种类的数据结构，所述数据结构可以总的称为“定义”。所述SDM的功能，可以通过一个或多个平台服务，诸如应用程序接口(API)得到公开。

在一个系统的设计阶段，一个开发系统202产生包括所述系统定义的一个文档，诸如一个SDM文档204。开发系统202可以是诸如可以从华盛顿州雷蒙德市的Microsoft公司得到的Visual Studio开发系统的多种开发系统中的任意一种。SDM文档204定义涉及所述系统的部署和管理的全部信息(这里也称为知识)。当部署所述系统或管理所述系统时，所使用或需要的知识包括在SDM文档204中。虽然这里所描述的是一个单独的文档，可以理解的是所述知识能够在多个文档中交替展开和保存。

一个系统定义根据一个或多个资源，端点，关系和子系统，定义一个系统。在一个SDM文档(例如一个XML文档)中，声明了一个系统定义。资源可以是硬件资源或软件资源。端点表示系统之间的通信。关系定义了系统，资源和端点之间的联系。子系统可以作为完整的系统对待，且典型的，包括一个大型系统的一部分。

一个系统定义记录一个动态系统的基本结构。所述系统定义能够看作框架，在该框架上能够添加所有其他信息。在所述开发处理期间，通过所述架构的构造者和开发者，典型的指定或所述结构，且典型的，不会频繁的改变。除所述结构之外，所述SDM能够包括部署信息，安装处理，用于配置的模式，事件以及工具(instrumentation)，自动任务，健康模型，操作策略等等。其他信息，可以通过所述操作人员，供应商，和/或一个分布式系统的生存期过程中的管理系统来增加。

SDM文档204包括所述系统的一个或多个约束条件(也称为必要条件)，一个环境中必须能够部署和/或运行所述系统。所述环境本身也是使用一个SDM文档来描述的。上述环境能够是单个计算装置，或者也可以是计算装置的集合(例如，资源处理中心)，应用程序主机等等。不同的系统能够安装在不同的环境。例如，一个资源处理中心可以包括五十个计算装置，且当另一个系统部署那些计算装置中的三十五个的时候，一个系统可以部署那些计算装置中的五个。这些必要条件能够采用多种形式，诸如：关于系统所部署的计算装置的硬件必要条件(例如，一个最小处理器速度，一个最小数量的存储器，一个最小数量的空闲硬盘空间，一个最小数量的有效网络带宽，特定的有效保密机制等等)，关于系统所部署的计算装置的软件必要条件(例如，一个特定的操作系统，一个或多个其他也必须安装的应用程序，关于如何配置一个特定的系统和/或所述操作系统的说明，所使用的一个特定保密或加密技术等等)，关于系统所部署的计算装置的其他的必要条件(例如，特定的有效安全密钥，必须执行的资源处理中心策略，所使用的认证，拓扑结构环境等等)。

必要条件还可以从另一个方向实现(go)-也就是说，所述环境能够在所要安装系统的结构上具有约束条件或必要条件(例如，执行所述环境的标准或策略)。这样可以“明确”必要条件，也就是说由所述环境的操作者创建的必要条件，诸如所述系统必须具有的特定的设置或配置，所述系统必须提供或支持的特定的功能，所述系统必须支持的特定的安全机制等等。这样还可以“隐含”必要条件，就是那些由于所述环境的特定的配置而出现的必要条件。例如，如果所述环境中的一个主计算装置，使用一个特定类型的文件系统，那么使用那些文件系统将不可能执行一些功能(虽然可能使用另一个文件系统执行前述的功能)。

在所述系统的设计和开发阶段的期间，SDM文档204可用于确认用于一个或多个特殊环境的所述系统。这是一个双向的确认：所述系统用于所述环境的确认，且所述环境也用于该系统的确认。所述环境能够通过比较在具有所述环境的SDM文档204中识别的必要条件，并通过该环境确定是否满足全部必要条件来进行所述系统的确认。所述系统能够通过比较在用于具有所述系统的环境的一个SDM文档中识别的必要条件，并通过所述系统确定是否满足全部必要条件来进行所述环境的确认。如果所述环境和系统满足全部必要条件，那么所述设计者或开发者认为，所述系统能够在所述环境中部署并运行。然而，如果所述环境和/或系统不满足全部必要条件，那么选择性地将没有满足的必要条件通知所述设计者或开发者，因此，为了使所述系统能够在上述环境中部署并运行，所述SDM文档204(并相应于所述系统)和/或所述环境，必须将发生的变化通知设计者或开发者。

关于所述系统，也就是说包括在所述SDM文档204中的系统，的部署的知识，描述了如何在一个或多个环境中部署所述系统。所述SDM文档204是适用于一个控制器206，所述控制器包括一个部署模块208和一个管理模块210。在某一个实施例中，所述SDM文档204以及安装所述系统所需要的所述系统的全部文件(例如，二进制码，数据，库等等)，均被封装为一个单独的容器(例如，一个单独的文件)，称为一个SDU(系统定义单元)。控制器206可以是附图1的一个或多个计算装置102。例如，附图1的一个单独装置102可以是用于一个特定的资源处理中心的控制器，或者换句话说所述控制器的任务在于是在多个装置102之间进行分配。

部署模块208包括用于在所述环境中部署所述系统的服务。在附图2中，部署所述系统的环境(或在其上部署的)，是一个或多个目标装置212。系统也可以是由控制器206部署。部署模块208的服务包括可以在所述环境中请求或调用，从而安装或部署一个或多个系统的一个或多个功能。

在不同的环境中部署的不同的知识，可能包括在所述SDM文档204中。该部署知识描述了在所述环境中必须需要的任一变化(例如，转换为一个系统记录；文件夹，目录，或需要创建的文件；计算装置的其他的设置或配置参数需要设置为特殊值等等)，以及将拷贝至所述环境中的所述计算装置的所需的文件(例如，程序和/或数据文件)和需要在那些文件上执行的任一操作(例如，需要解压和/或解密的一些文件)。在许多实施例中，在所述SDM文档204中的所述部署知识包括，例如，类似于在典型的用于系统的安装或安装程序中即时发现的信息。

在所述部署过程的期间，控制器206产生在所述部署中涉及的软件和硬件资源以及二者之间的关系的一个记录或存储区(store)。其次，该记录或存储可以随后在所述管理阶段期间由控制器206使用。

管理模块210包括服务，即一旦将其安装在所述环境中，就用于管理所述系统。管理模块210的这些服务，包括可以在所述环境中请求或调用，从而管理所述系统的一个或多个功能。关于所述系统的管理的知识，即包括在所述SDM文档204内的知识，描述了如何在一个或多个环境中管理所述系统。

用于在不同的环境中管理一个系统的不同的知识，可以包括在所述SDM文档204中。所述管理知识包括用于所述系统的管理或操作的任一知识。管理包括，例如，配置(和可选的其后的重构)，修补和升级，维护任务(例如，备份)，健康或性能监测，等等。

转换为部署系统是通过管理模块210完成的。所述管理模块210的服务包括可以在所述环境中请求或调用，从而转换为一个或多个系统的一个或多个功能。通过所述管理模块210完成的上述转换，可以实现多个益处。上述益处之一是，所述控制器206能够保存已完成的所述转换的一个记录。控制器206可以保存用于所述系统的所述SDM文档204的一份副本，并在所述SDM文档204中记录对所述系统做出的任一转换。换句话说，控制器206可以保存对所述系统做出的转换的一个独立的记录。

由控制器206保存的转换的记录可以简化其后的操作，诸如解决所述系统和/或环境的问题，或当由于一个硬件故障(允许所述系统重新安装并返回至以故障时所具有的相同的参数/设置运行状态)，而不得不重新安装所述系统。通过控制器206完成上述的转换，以及控制器206保存所述记录，可以从所述环境中消除一些人为误差(例如，如果完成所述转换的管理员认为应将所述转换记录在一本书中，但是忘记了记录，所以并不存在所述转换的记录-这个问题是可以通过控制器206保存所述记录解决的)。

此外，通过控制器206完成系统的转换，以及通过控制器206部署系统，控制器206可以作为关于所述环境，在所述环境中部署的系统，以及二者之间相互作用的知识的储存库。关于所述环境和/或在所述环境中部署的系统的知识，可以很容易从控制器206中得到。这些知识可用于通过确认在所述环境中的控制装置反映的存储在所述中央控制器206中的状态，保护所控制的环境的一致性(consistency)。

还应注意的是，在一些状态中，可以对一个系统和/或环境做出转换，但是并不是通过控制器206做出的。例如，一个计算装置可能意外地关闭或出现故障。在这些状态中，试图(attempt)在控制器206中反映上述转换。这些转换可以在控制器206中自动反映(例如，一个系统可运行以试图检测装置故障，并使用管理模块210的服务，以将上述故障通知控制器206)，或可以在控制器206中手动反映(例如，一个管理员可以使用管理模块210的服务，以将上述故障通知控制器206)。换句话说，已完成的所述转换是可以反向的，从而将所述系统和/或所述环境的一部分，返回至通过如同控制器206记录的，具有所述系统的所需状态的排列。

因此，所述SDM文档204可以看作一个“活的”文档-可以基于在整个所述系统的生命周期中，转换为所述环境和/或转换为所述系统，进行经常转换。

所述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，和306(原文如此，应为308)可以表示不同的内容。在某一实施例中，层302是一个硬件层，层304，是一个网络拓扑结构以及操作系统层，层306是一个主应用程序层，且层308是一个应用程序层。所述硬件层表示所述物理设备(例如，计算装置)，在所述物理设备上，建立所述分层系统(例如，附图1的装置102)。所述网络拓扑结构和操作系统层，表示所述计算装置的网络拓扑结构(例如，附图1的网络设置100)以及安装在那些计算装置上的操作系统。所述主应用程序层，表示在所述计算装置上安装的应用程序，所述应用程序可以管理其他的应用程序(例如SQL服务器，IIS等等)。所述应用程序层表示在所述计算装置上安装的，没有管理其他应用程序的应用程序(例如，诸如游戏的娱乐应用程序，诸如文字处理软件的生产性应用程序，诸如电子百科全书的参考文献应用程序，诸如可用作网页服务或金融分析等等)。

附图4说明了一个在一个系统的整个生命周期中，使用SDM的处理400的实例的流程图。附图4中处理400的不同操作，可以通过软件，固件，硬件，或其中的组合来执行。

起初，基于所述SDM设计所述系统(操作402)。为了在所述环境中部署并运行所述系统，所述系统被设计为包括一个必须满足的环境的必要条件，以及用于部署和管理所述系统的额外的知识。这些知识包括在与所述系统相关的一个SDM文档中。一旦设计完成，所述系统可以可选的利用所述SDM进行确认(操作404)。该确认允许所述设计者或开发者验证所述系统能够在相对于该系统而言已经过确认的所述环境中部署和运行。如上所述，不仅仅是相对于将要部署所述系统的环境确认所述系统，而且所述环境也相对于所述系统进行确认。如果所述确认在一特定环境中出现故障，则可以开始附加的设计步骤，从而改变所述系统，以使所述系统可以在所述环境中运行(或可以开始替换的步骤从而改变所述环境)。

一旦确认完成，可以利用所述SDM部署所述系统(操作406)。当在一个环境中部署所述系统时，所述系统安装在所述环境中，以使其能够随后在所述环境中运行。用于安装所述系统的知识包括在与所述系统相关的所述SDM文档中。一旦部署结束，利用所述SDM，监控和/或管理所述系统(操作408)。在与所述系统相关的所述SDM文档中的知识，识别如何监控和/或管理所述系统，且所述系统根据这些知识，在所述环境内监控和/或管理所述系统。

附图4的处理400可以用于应用程序系统以及环境系统。例如，可以相对于所述应用程序的环境的SDM，确认该应用程序(例如，在附图3的层308中的一个应用程序，相对于附图3的层306的环境进行确认)。通过另一个实例，一个操作者或系统设计师可以设计环境(例如，附图3的层306或层304)，且相对于其中能够部署上述应用程序的所述环境(例如，分别在层304和302)，确认所述环境。

还可以在运行时间期间(当监控和/或管理所述系统时)，使用一系统和/或环境上的约束条件，从而在运行时间期间，确认将其转换为所述系统和/或环境。例如，上述运行时间的确认允许一个环境的操作者确定如何将其转换为可以影响一个正在运行的系统的环境，或者允许一个系统设计者确定如何将其转换为可以影响该系统在所述环境中的运行的系统。

在下列论述中，涉及关于所述运行时间的数据流和设置数据流。数据流，用于在一分布式系统的各部分之间传递配置信息(例如，允许一个开发者指定在一个位置中的所述配置信息，或者允许一个操作者仅仅提供一个单独的记录)。数据流也用于通过下列在所述系统的各部分之间设置数据的数据流，确定转换为配置的影响。

附图5说明了一个使用SDM运行时间的架构500的实例。架构500是使用一个SDM运行时间510的附图2的架构200的一个实例，以及以下在“SDM执行实例”部分中论述的SDM的执行实例。所述SDM运行时间510包含一组用于接收并确认SDM文件，载入SDU(系统定义单元-封装一个或多个SDM文件及其相关文件)，创建并执行SDM转换请求，以及部署SDM将系统变为目标环境的组成部分和处理。所述运行时间功能性允许对使用所述SDM描述的系统进行定义和确认，作为一组计算装置部署以及管理。

设计将在以下“SDM执行实例”部分中进行详细论述的所述SDM，从而支持在一个分布式系统(所述建模系统)中的所述配置，相互作用以及转换为所述组成部分的说明。SDM是以一个对象-关系模型为基础的。“定义”描述了在一个系统中存在的实体，且“关系”识别在所述不同的实体之间的连接。此外，定义与关系是定义以捕获与所述SDM有关的语义信息的。特别是，定义被分成组成部分，端点和资源。关系被分成以下：连接(也称为通信)，封装，管理，代理和引用。以下将提供关于定义与关系的更多的细节。

所述SDM包括提供一个“抽象定义”，该“抽象定义”提供系统部分的一个公共分类，提供支持大范围系统的工具并提供核对在设计时间的定义的基础。一组抽象定义提供用于服务设计的一个全面的基础。“具体定义”表示一个实际的系统或资源处理中心设计的各部分。一个具体定义，是通过选择一个抽象定义并提供一个定义所述具体定义的成员以及设置其属性的值的执行过程。分布式应用程序是使用这些具体定义的集合产生的。

所述SDM也包括“约束条件”，基于所允许的关系的设置，上述模型限制一个关系的范例的参与。约束条件对于描述由涉及一个关系的对象的配置而确定的需要是有用的。例如，可以用一个约束条件来决定参与者在一个通信协议的每一终点上，是否使用了适应的安全设置。

为了实现在一个目标系统上的转换，SDM使用一个称作一个“转换请求”或CR的所需转换的公告性说明。SDM将所述处理定义为所述“SDM执行模型”的一部分，所述处理即用于扩展，确认和执行一个转换请求的处理。

所述“范例空间”捕获所管理的应用程序的预期状态和当前状态。跟踪在所述范例空间中的转换，并与开始所述转换的转换请求相关。将所述范例空间存储在一个SDM运行时间，并反映所述建模系统的当前状态。所述运行时间包含一个已创建的所述范例的完整的记录，以及这些范例之间的关系。每一个范例都具有一个相关的版本历史，每一个版本均连接至一个转换请求。通过一个转换请求，开始创建新范例的处理。所述转换请求定义一组创建，更新和删除用于与一个已存在范例的具体成员相关的定义和关系的请求。

以下是附图5中的组成部分如何一起工作的一个简要的，功能性的论述。一个操作者或管理员能够描述一个可以部署应用程序的环境，诸如一个资源处理中心的拓扑结构。所述操作者或管理员生成一个描述所述环境的SDM文档，所述文档称为“逻辑基础结构”(LIM)502，或作为一个资源处理中心说明或资源处理中心模型。这些SDM文档可以使用多种开发系统的任意一种来产生，诸如可以从华盛顿州雷蒙德市的Microsoft公司得到的Visual Studio开发系统。

此外，开发者可以利用任何一种开发系统，例如Visual Studio开发系统，设计和开发他们的应用程序。着所述开发者定义所述应用程序的组成部分，以及这些组成部分如何彼此相关，所述开发者能够确认相对于所述资源处理中心说明502的所述应用程序的说明。这也称为“设计时间确认”。

只要所述应用程序是完整的，所述开发者在一个SDM中保存所述说明，并请求所述应用程序封装以作为一个用于部署的SDU504。所述SDU包括所述应用程序SDM，以及所述应用程序二进制码和其他用于安装所述应用程序所引用的文档。

将所述LIM502和SDU504提供给用于部署的一个控制装置520的部署工具506。部署工具506包括一个用户界面(UI)，该用户界面用以使一个操作者载入所需SDU504。部署工具506与创建CR模块530协同工作，从而根据在SDU504内部的所述SDM中的信息，安装与所述SDU504相关的所述应用程序。另外，将来自SDU504的SDM定义和范例，填充至所述SDM运行时间510的一个存储区508中。SDU在SDM运行时间510中通过SDU管理模块540进行管理，所述SDU管理模块540，使SDU的适当部分对运行时间510的其他的组成部分和目标522都是有效的。

所述操作者还可以在正在部署的应用程序上，指定他或她所希望采用的目标522(例如，目标计算装置)。所述操作者通过一个部署文档实现上述指定，这里也可以将所述部署文档称为一个转换请求(CR)。所述CR通过一个或多个引擎512，514，516，和518来运行。通常，扩展CR引擎512，扩展所述CR，从而识别所有相关组成部分以及他们的连接和活动，数据流值引擎514，流动用于所述组成部分的值(诸如连接串)，核对约束条件引擎516，核对所述环境和所述应用程序之间的约束条件，以及排序活动引擎518，指定所述CR所有必要的活动的排序。

为了开始将一个模型转换为所述系统(包括部署一个应用程序)或对该模型进行确认，一个操作者或处理，提出一个CR。所述CR包含一组所述操作者希望在所述运行时间510的范例中执行的活动。例如，这些活动可以是创建活动，更新活动，和/或删除活动。

以下将更详细地论述除用户或操作者开始的转换请求之外，同时可以存在的扩展/自动产生转换请求，即产生作为所述扩展处理的一部分的所述转换请求。与所述转换请求的来源无关，只要已完全展开并核对所述转换请求，则通过将活动发送至所述目标522，即可执行所述转换请求，诸如：发现，安装，卸载和转换一个目标范例。

所述CR被当做作为一个整体完整的或故障的活动的一个极小的组。例如，当测试有效时，允许所述约束条件校验引擎516考虑所有的活动。

在设计时间确认中，将通过所述SDM编译器528创建所述CR，并包含所述SDM文档中的每一个SDM组成部分的一个或最小量。CR的创建范例命令将流过所述扩展引擎512，所述流值引擎514，和所述约束条件校验引擎516。在这三个阶段中发现的错误，将通过他或她使用的所述开发系统，返回至所述用户

在部署中，所述操作者将创建一个具有通过部署工具506表现的所述UI的CR。所述CR流过所述SDM运行时间510所有的所述引擎512，514，516和518，并且通过CR模块532，将适当的活动和信息发送至适当的执行所述请求(例如，安装所述应用程序)的目标522。用于一个特定的安装的适当的目标522，一般是将要在其上安装所述应用程序的那些目标。

当开始处理一个CR时，在一个定义分解度阶段中，创建CR模块530分解所有的定义和在所述转换请求中引用的成员。假定通过所述运行时间510，已载入所述转换请求；如果其不存在，创建CR模块530开始一个载入/编译活动。创建CR模块530还执行一个路径分解度阶段，该阶段参考了已存在的范例和通过分解所述转换请求内的创建活动所定义的范例。

通过扩展引擎512执行的所述扩展，是一个给定一个转换请求，执行所有剩余的所需活动，从而填充所述要求的处理。通常，这些活动是用于定义与关系范例的构造和分解活动。所述操作者可以可选的提供用于构造或分解一个范例所需要的所有所述活动的细节，或者可以使所述处理的各部分自动化：例如，所述操作者通过识别对于各成员的动作(例如，按照引用的成员)，提供关于他或她需要的所述转换的关键信息，以及所述动作的剩余部分插入所嵌套的成员(例如，按照引用和按照值的成员)和关系。通过另一个实例，自动扩展还可以涉及外来资源管理者，即可以基于选择具有可用资源的装置，定位接近于它需要的数据的应用程序等等，完成部署决定。

扩展引擎512还执行“自动写入”。在自动写入的期间，引擎512分析组成部分的比例恒定的组和在所述SDM中指定的复合组成部分，并确定在按照所述请求级的规定的情况下，如何将所述组成部分分组并互连。

扩展引擎512还执行值成员扩展，引用成员扩展，与关系扩展。

值成员扩展涉及所有非引用定义成员的识别。这些成员的所述基数是标明的，且由于所有所需参数都是已知的，则对于每一个成员，将所创建的要求添加到其父母被创建的那些成员的转换请求。如果所述转换请求包含分解操作，则将所述分解操作添加给所有其所包含的范例。

引用成员的扩展，涉及引用成员(相对于非引用定义成员)。所述引用成员的基数，经常是未定义的，且为了构造所述实例，所述引用成员具有设置所需值的部署时间。所以，扩展一引用成员(例如，一参照引用成员)的处理，需要能够提供的与所述实例有关的，比运行时间更多的信息。

与引用成员的扩展相关的，是称为发现的一个处理，其中该处理是用于寻找已部署的实例的一个处理。发现是起源于所述环境的一个操作者的一个典型活动。例如，在一个安装请求的过程中，扩展引擎512确定所述实例是否已经存在，如果存在，确定存在什么样的实例，且如果不存在，则创建所述实例。所述控制器520上的一个实例管理器(IM)534，和所述目标装置522上的所述实例管理器526进行通信，从而启动一个发现处理。所述发现处理将关于所述实例的数据，从所述目标装置522，返回至所述控制器520。

所述发现的处理，将引用定义成员作为一个结构或者更新活动的一部分引入。典型地，只有带有支持发现的对象管理器(实例管理器也可以进行发现)的引用成员，参与这个处理。

当发现一个新的实例时，利用实例专用密钥值，对所述实例并未存在于已有的所述SDM数据库中进行核对。一旦得知其是一个新的实例，则根据已发现的所述成员的定义，对所述实例进行分类。如果所述实例无法与一个成员，或者已存在的一个模糊的相似实例相匹配，则所述成员引用保留空白，且将所述实例标记为不可用的和不完整的。

关系扩展涉及，一旦已知所有将要构造的定义实例，则创建与所述定义实例结合在一起的关系实例。如果定义实例被分解，则删除所有引用所述实例的关系实例。

为了创建所述关系，应用所述成员空间，以识别所述实例之间所存在的所述关系的配置。其中，所述定义成员具有大于一的基数，由所述基础关系定义，推测所述关系的拓扑结构。例如，对于通信关系，可以执行一个“自动配线”，且对于宿主关系，根据与所述宿主关系相关的算法，选取一个宿主。

在一个数据流阶段中，流值引擎514对通过所有关系实例的数据流进行评估。对于受任何一个已改变的参数流所影响的实例，流值引擎514，可以把更新请求添加到所述变更请求中。作为所述变更请求的结果，引擎514通过确定具有已更新设置的实例集，对数据流进行评估。对于其中的每一个，根据所述已修改的设置，评估输出的任一设置数据流，并将所述目标节点添加到所述已变更的实例集中。继续所述过程，直到所述集为空，或者所述集包含一个周期。

所述数据流阶段之后，执行一个副本检测的处理。所述副本检测，可以通过附图5中所描述的多个引擎之一(例如，流值引擎514或者核对约束条件引擎516)，或者通过附图5中没有示出的其它引擎(例如包括在SDM运行时间510)，来执行所述检测。相对于已经存在于所述SDM数据库中的实例，所述副本检测的处理，与扩展实例的过程相匹配。例如，该处理检测其它应用程序是否已安装了一个共享文件。当检测到已经存在一个实例时，可以根据所存在的实例的版本，采用多个活动之一：所述安装可能失败；所述实例可能是所统计的引用；所述实例可能被升级；或者所述安装可能被并列执行。

核对约束条件引擎516，执行一个约束条件求值阶段，其中核对所述模型中的所有约束条件，从而查看在已经处理所述变更请求之后，所述约束条件是否仍然有效。

在核对约束条件引擎516结束所述约束条件求值阶段以后，可得到一份活动的完整列表。所以，活动排序引擎518，可以使用所述组成部分之间的关系，从而确定一个有效的变更顺序。多种算法中的任意一个，均可用于进行该确认。

一旦排序活动引擎518结束所述排序的确定，则可以通过分配机器指定活动的顺序集的子集，执行部署。一旦所述活动已经通过机器排序并分组，则将所述活动，以及具有实例信息的所述SDM运行时间库508的必需部分的副本，发送至一个目标计算装置522。所述SDM，可以临时存储在一个库缓存538的目标装置中。

所述目标计算装置，包括SDM运行时间的一个目标部分536，该部分与SDM运行时间510进行通信。所述目标计算装置522，也包括一个代理，该代理包含一个执行引擎524，所述目标计算装置522可以在所述目标装置上，与适当的实例管理器(IMs)526通信，从而在所述目标上进行诸如创建，更新以及删除活动的变化。将每一个活动，作为一个基本呼叫，发送至所述实例管理器526，且所述实例管理器526返回一个状态消息，且对于一些活动，也返回数据(例如，对于发现活动)。一旦在目标522上结束所有的所述活动，所述目标的代理将所有的错误和状态，返回至所述控制器520。然后，所述控制器510使用该信息，更新所述SDM运行时间库508。

如上所述，通过根据已影响的所述关系，将所述变更请求拆散为多个可分配的部分，从而执行变更。一旦结束所有的多个所述部分(或者在一个或多个所述部分的失败之后)，在所述运行时间510中校对所述结果，并且将一个概要返回给所述操作者。如果出现一个故障，所有的所述活动可以“退回重来”，并且所述系统返回到启动所述变更以前的状态。

在某些实施例中，在上述设计时间确认的过程中，一个SDM编译器528接收一个SDM文件，创建一个测试CR，通过扩展，流值，运行所述测试CR，并且核对所述SDM运行时间的约束条件引擎，并且将所有的错误返回至所述开发系统。对于开发者，该处理在设计时间的过程中，提供对于部署的SDM确认。

SDM运行时间510和/或控制器520的公共界面，连接至一个对象模型(APIs)库。所述库，是一个管理代码的对象模型，并且允许执行下列操作：

·在所述运行时间中管理SDM-SDM文件可以载入所述运行时间。SDM是不可改变的，并且是一次载入一个(即，可以载入一个SDM文件，而不是只有所述文件的一部分(例如，所述SDM文件中的独立的定义，类或者映像的独立的一个))。可以从所述运行时间中删除SDM，并且在所述运行时间中，生成一个SDM的XML文档。

·通过所述运行时间管理已知的SDU。

·管理SDM定义-寻找并反映各SDM元素(从载入到所述运行时间的一个SDM中)。不存在用于编辑一个新的SDM的公共的API(即，所述SDM的不可改变的元素，存在一个只读对象模型)。这包括SDM，SDU，身份，版本，类，定义，绑定/映像以及版本策略。

·管理SDM实例-寻找并反映组成部分，端点，源与关系的实例。在所述实例空间中，可以通过一个GUID，一个稳定的路径或者一个基于路径的矩阵，识别每一个实例。所述路径，是成串的，且可以是相对的。这些标识符，包括在诸如所述变更请求文档的文档中，允许寻找并引用的实例的相对路径。

·处理多个实例-改变SDM实例，包括创建，变更拓扑结构，升级，变更设置以及删除。在提供一个更新的基础单元的一个变更请求范围内，进行实例变更，以使所有的错误或者约束条件的违反，将导致所述全部请求的失败。由于提交该请求时，一个实例必须具有一个主机，实例请求还考虑到临时存在的，无需绑定到主机的实例。该实例请求还考虑到多个将影响一个单独的组成部分的安装的操作，或者所要执行的设置，且该实例请求具有延迟到提交该请求才更新的安装或者设置，以便在该组成部分上出现一个单独的更新。在提交变更请求之前，或者在提交的同时，执行该SDM模型的核对，且该提交在违反任何模型或者约束条件的时候无效。

·载入一个变更请求-一个变更请求是表示一组实例空间操作的一个文档，例如一个XML文件。该文档可利用将作为可重复使用的“脚本”的相对路径，创建或者删除应用实例。

·寻找和反映变更请求-包括获得该安装/更新任务以及所有的误差信息，并重试受该请求影响的安装/更新组成部分。

·从数据库的一个变更请求中，产生一个变更请求文档。上述文档有些是可移动的。

·在变更请求任务上订阅事件，诸如处理，日志或者更新状态。通过载入客户库的该过程的生存期(即普通的CLR事件)，限定该事件订阅的生存期。

SDM运行时间引擎，执行在SDM模型上的推理，且通过API实现该功能。该库作为一个具有相当粗糙的通话，诸如载入SDM，创建组成部分实例以及获得整个SDM(反映SDM实体)之类的网络服务，与运行时间引擎进行通信。用于该网络服务的许多参数的格式，是具有用于SDM文件的相同模式(schema)的XML。该引擎也可以执行许可核对。

控制器520可利用实例管理器(IM)，实例管理器可以与该模型中的任一定义或关系相关。IM可以实现下列作用中的一个或多个：

·支持实例的部署。

·一旦已经部署(审核)该实例，则支持该实例的有效性。

·支持已部署实例的发现，也就是说在该运行时间中未对其进行部署。

·支持设定值的流动。

·支持约束条件的评估。

·支持一个变更请求的扩展。

·支持实例对一个用户，作为一个CLR类通过API的表现。

为了进行部署，插入在控制器520上的一个实例管理器(IM)，与一个类宿主关系相关，且在开发系统中和插件程序相分离，所述开发系统，提供用于该类的设计经验，并在SDU504中生成相关的二进制文件和设置模式。将实例管理器，作为CLR类(例如，在一个dll组件中)提供给SDM运行时间510，CLR类实现一个实例管理器界面，或者可以从抽象类中获得。一个SDM实例管理器，也称为一个实例管理器(IM)插件程序，对控制器520提供下列功能：

·产生文件和命令(任务)，以在他们的宿主上安装，卸载或者重新安装组成部分实例-当一个变更请求导致产生一个新的组成部分实例，删除的一个组成部分实例或者对一个组成部分进行改变，而需要一个卸载和重新安装时，该实例管理器，对该实例，宿主实例，与组成部分相关的定义以及SDU204中与那些定义相关的二进制文件进行设置，并生成在对象服务器上，准备人工执行或者通过部署引擎调度，以执行安装或者卸载需要的文件和命令。

·当一个组成部分实例的设置改变时，或者当从其终点之一的改变(例如，由于通信关系拓扑结构改变或者一个可见端点设置的改变)考虑时，产生文件和命令(例如，任务)，以更新一个组成部分实例。在一个组成部分实例的端点上，将可见的端点实例映射至组成部分实例上的设置-在SDM中，作为一些通信关系拓扑结构的结果，具有端点实例的一个组成部分实例，可以了解其他端点实例。

·另一个端点实例的细节，通常映像至可以在运行时间取得的组成部分实例的设置，以便该实例可以绑定于其上。例如，一个网址可以具有一个数据库客户端点实例，这样可以与一个数据库建立一个通信关系。当正确建立通信关系时，它的数据库客户端点能够了解一个单独的数据库服务器端点实例，以及那些服务器端点上的设置。通过实例管理器，使用该信息，在一个配置文件中以客户端点的名义，配置一个用于该服务器的连接串。最终结果是从它的结构设置中简单地读取用于该数据库的连接串的代码。

·产生该文件以及命令(任务)，以审核一个组成部分实例-审核确认存在，正确的设置。这也可以应用于宿主实例设置。

·对于将报告状态的任一任务-IM将局部或者全部转换所捕获的输出，并提供如成功，失败或者未完成的该任务的状态，并可选的提供在未完成的进程(％或者最后的响应)，失败的详情(错误信息)以及在任一状态上的一个人类可读日志。通过返回实例管理器，解释一个任务的输出，该实例管理器可以自由拥有它的任务日志结构信息(例如，作为XML乃至SOAP)，而不是在日志保持人类可读的时候，设法生成用于诊断的足够的日志。

·实例管理器还可以提供宿主及其客人之间执行约束条件核对的代码。安装者可以使用一个公共的约束条件语言，例如基于XML，XPath和XQuery。

SDM执行实例

以下论述描述了一个定义所述SDM元素概要的实施例。

1  定义

术语                     定义变更请求                 一个描述转换为模型化系统的一个集合的公告性文档充分限定变更请求         通过模型评估阶段的变更请求，且准备由目标系统执行抽象类型                 用来定义对一个建模的系统对象起作用的设置的一个类型一个建模的系统对象的一个可重复使用的定义，包含用于成员类型与关具体类型系的定义关系                     用来描述建模的系统元素之间的相互作用的一个sdm对象系统定义模型(SDM)文档    包含用于抽象对象，具体类型与关系的定义的一个xml文档需要将那些类型部署到一个SDM管理系统中的一组SDM文档和相关二进软件分配单元(SDU)制信息(文件)的集合

一个层是在层中指定的建模的对象的一组抽象对象。例如，应用层的类型可以包括网络应用和数据库，而该操作系统层可以包括用于文件系统SDM层和网络设备的类型。一些类型不会分配到层，且将可以在替代贯穿层的范围内使用。SDM实例空间    表示该建模的系统的具体类型与关系实例的集合

2  架构概述

设计系统定义模型(SDM)，以支持对配置，相互作用的说明，且在一个分布式系统(建模系统)中，变更为组成部分。

SDM是以一个对象关系模型为基础的。我们使用对象来描述存在于该系统中的实体，并使用关系来识别它们之间的连接。此外，SDM提炼对象与关系，以捕获对SDM来说很重要的语义。尤其是，我们把对象分成系统，端点和资源，且我们把关系分成通信，管理，宿主，授权，和引用。

我们使用摘要定义，提供一个公共归类的系统部分，以允许用于大范围的应用地工具支持，并在设计时间提供用于类型检查的基础。我们希望摘要定义的集合，提供一个用于系统设计的全面的基础，并且我们希望它们将随着时间的过去渐渐改变。

我们建立具体对象定义，来表示一个实际应用或者资料处理中心设计的一部分。我们采用一个抽象对象定义，并且提供定义该成员的具体类型的一个执行过程，并且设置它的属性值。此后，我们从这些定义的集合中建立系统。

约束条件，用来模型限定所允许的，可加入实例的关系的集合。我们使用约束条件，来根据包括在一个关系中的对象的配置，捕获微小的必要条件。例如，一个约束条件可以利用可兼容的安全设置，来确认在一个通信协议的每个端点上的参与者。

为了在目标系统上产生改变，SDM使用了称为一个变更请求的所需要的改变的公告性说明。SDM将定义一个用于扩展，确认并执行一个变更请求的处理，作为SDM执行模型的一部分。

该实例空间捕获所需要的，和所管理的应用程序的当前状态。我们在实例空间中追踪变更，以及已启动变更的，与该变更请求相关的变更。

下列uml框图捕获sdm模型中对象之间的主要的相互作用。为简单起见，已经定义了基础类型之间的相互作用中的一些，其中实际的相互作用存在于派生类型之间，且因此，相互作用更加专业化。例如，通信关系可以仅参考摘要端点定义。

一个SDM文档，包含描述该文档的信息，该文档中定义的管理器，引入引用其他文档的语句一组定义的输入语句。

图6说明了一个实例文档。

从一个公共的基础定义衍生出所有的SDM定义，且SDM定义包含附图7所示的成员。定义和成员之间的关系，可以比在下列框图中示出的更加复杂。

按照附图8中示出的成员所引用的定义的种类，将成员进行划分。

设置声明引用一个设置定义。设定值和值列表，提供附图9所示的设置的值。

2.1  一个SDM应用程序的生命周期

附图10中示出的，是根据某一个实施例的一个SDM应用程序的生命周期的范例。

在可视化工作环境中，设计并执行该应用程序(模块1002)。开发者执行各组成部分，并且此后将它们组合在复合组成部分之内。在一个SDM文件之内，描述该应用程序。为了验证他们的应用程序将在一个特定的资料处理中心之内进行部署，一个开发者将他们的应用程序绑定到在一个SDM文件中描述的该资料处理中心的一个代表上(模块1004)。这个代表将包括在他们的应用程序的配置上，用于他们的应用程序组件和约束条件的宿主的定义。如果绑定失败，那么该开发者可以修正他 们的应用程序设计。

一旦一个开发者与他们的应用程序是幸运的，则他们可以署名并公开该应用程序，因此现在，存在一个与该应用程序强烈相关的名称和版本(模块1006)。一个应用程序公开的格式，被称作一个软件分配单元(SDU)。操作者采用来自开发者的SDU，并将应用程序载入至SDM运行时间(模块1008)。在载入该应用程序的过程中，操作者选择他们想要绑定该应用程序的资料处理中心的模型。当操作者选定部署一个应用程序时，他 们向该应用程序提供的部署时间参数，并确定该应用程序的规模(模块1010)。这里利用一个变更请求来执行上述操作。

一旦部署一个应用程序，操作者可以与运行时间相互作用，从而确定应用程序的配置，并设置该应用程序的每一部分(模块1012)。该运行时间还可以验证应用程序的实际配置与记录在运行时间里的希望的配置是否相相配。该操作者可以通过提交一个变更请求，删除一个部署应用程序(模块1014)。该操作者还可以退回重来对运行的应用程序进行的独立的变更，诸如删除一个服务包。在模块1016中，可以通过添加或删除所部署的应用程序的一部分来变更一个运行的应用程序的配置，以便达到网络前端的程度。该应用程序还可以通过安装新版本的一个或多个应用程序组件来进行升级。

2.2  抽象对象和关系定义

抽象对象定义，定义了为了在设计时间核对应用程序配置，并且此后在运行时间部署和管理一个应用程序，我们所需要的构造模块。这些构造模块，表示存在于该建模的系统的实体。例如，我们使用抽象对象定义来对文件和目录，一个网络服务器内部的配置或者一个结构化查询语言服务器内部的数据库进行模型化。

我们使用摘要关系定义，对出现在抽象对象定义之间的相互作用进行模型化。关系是二进制的，并且是直接的，识别定义参与关系的声明的实例的对象定义。关系提供一个将对象约束在一起的方式，因此我们可以对对象之间的包容，结构和通信连接进行模型化。

我们使用抽象关系定义，对出现在抽象对象定义之间的相互作用进行建模。关系是二进制的，并且是直接的，识别定义参与关系的声明的实例的对象定义。关系提供一个将对象约束在一起的方式，因此我们可以对对象之间的包含，结构和通信连接进行建模。

通过对象，将约束条件用于约束他们所参与的关系，并且通过关系约束可以连接的对象。这些约束条件可以将定义和一个关系中的参与者的设置作为目标。这允许一个约束条件，来将一个关系中的参与者，缩小至由一个特定的定义派生的实例，并且需要具有落入一个特定范围的设置值的实例。

我们把对象定义分成三个种类：系统，终端和资源。

抽象系统定义，用于描述一个应用程序的可独立整装部署的一部分。这里，定义表示通过可以超越处理和机器界限的、明确定义的通信信道相互作用的一个应用程序的一部分。

抽象终端定义，用于描述一个系统可以公开的通信终端。为了在设计时间，验证系统的连通性，并在运行时间启动连接，将系统能察觉的通信的所有格式建模。

抽象资源定义，描述一个系统内所包含的动作。资源定义可以在其他资源定义上具有稳固的依赖性。这些依赖性，可以包括需要一个指定安装顺序，并通过无正式文档的通信装置启动运行时间的相互作用。

所有的抽象对象定义能够共享公开设置。这些设置是简单的名称-值配对，使用xml模式以定义所述设置的类型。设置可以是动态或者静态的，如果他们是静态的，则他们只能在所述部署过程中被设置，如果他们是动态，则他们可以在部署之后进行变更。适用于该运行系统设置值的代码，容纳于SDM运行时间中。

SDM支持对于抽象对象定义的继承。一个派生定义，可以通过它的父母扩展所公开的特性，并且可以设置它的父母特性值。一个派生定义，可以参与任何关系，以识别作为一个参与者的它的父母。

关系定义被分为五个种类：通信，包含，授权，宿主，和引用。

通信关系，用于捕获抽象终端定义之间潜在的通信。通信关系的存在，标明了对于系统，可能将所识别定义的终端公开以进行通信。连接的实际建立，服从于在终点上的约束条件和终端的公开。

包容关系，描述了能够使抽象对象定义包含另一个抽象对象定义的成员。更具体地说，两个抽象对象定义A和B之间的包含关系，允许实现A的具体对象定义包含实现B的具体对象定义的一个成员。

我们使用包含，将开发者构造应用程序时出现的自然的成组结构建模。通过包含一个成员对象，父母能够控制所包含对象的生存期和可视性。运行时间空间中的所有对象实例，作为其他对象实例的成员而存在，形成一个完全连通的实例组。因此，这组包容关系描述了实例空间中出现的所允许的包容模式。

授权关系用于有选择地公开所包含的对象成员；特别是，我们使用授权来公开系统定义中的终端成员。通过从一个子系统中授权一个终端，该外部系统在该协议之后，公开了与一个没有公开该实施例的特定协议进行通信的能力。

容纳和引用关系是依赖关系的两种格式。一个宿主关系，描述了抽象对象之间的一个基本的依赖性，上述抽象对象应该存在于创建一个具体对象的实例之前。在严格的单宿主关系中，每一个实例都应该作为一个客人参与，使该宿主关系对于该实例空间，也形成一个完全连接树。引用关系，捕获增加的可用于参数数据流和用于结构排序的依赖性。

2.3  具体对象与关系定义

我们从抽象对象定义中构造具体对象定义，并且从抽象关系定义中定义具体关系定义。

抽象对象定义和抽象关系定义的组合，定义一个用于将该目标系统建模的模式。一个具体对象定义的角色，将使用该抽象定义空间的一个子集，以基于一个或多个抽象定义，创建一个可再次使用的配置。作为简单的模拟，该抽象定义空间可以与用于数据库的模式相比；然后，该具体对象定义将表示一个用于数据库中一个行的组的，可再次使用的模板。当创建该具体对象的一个实例时，只有在数据库中创建所述行。为了执行设计时间确认，我们可以用相同的方式对所述抽象定义空间，确认一具体对象定义，我们将对所述模式的约束条件(例如外来的密钥，等等)确认所述数据库中的行。

每一个具体对象定义提供一个用于指定抽象对象定义的实施例。所述实施例包括对于设置模式的扩展，用于设置和声明对象成员，关系成员和约束条件成员以及数据流成员的值。具体对象的动作遵循抽象对象的定义：抽象系统定义变成具体系统定义，抽象终端定义变成具体终端定义，以及抽象资源定义变成具体资源定义。

每一个具体关系定义提供一个用于指定抽象关系定义的实施例。所述实施例可以包括设置声明以及值，相同关系种类的分组成员(宿主，包含，通信等等)，以及对可以参与的关系的类型的约束条件。

具体宿主关系，用于在另一个具体对象上定义一个具体对象的成员的映射。例如，一个具体宿主关系可用于识别一个网络应用程序和将要部署的IIS宿主之间的绑定。更多的具体宿主关系，可以存在一个给定类型，该类型允许开发者定义用于指定拓扑结构的不同部署配置。

2.4  成员

一个具体类型可以声明其他具体或者抽象对象的成员-我们将这些成员称为对象成员。然后，这些成员引用定义对象成员之间关系的关系。

对象成员用于创建一个特定对象定义的实例。设置数据流可用于提供所述对象的值。当声明一个对象成员时，所述用户可以决定是否在创建外部系统(值语义)的同时创建所述对象成员，或者通过在以后的某一时间出现的一个明确的新操作(引用语义)创建。

当创建关系成员时，关系成员定义对象成员将参与的关系。如果一个对象成员被它的父母包含，那么将在类型成员和外部类型之间声明一个包含关系成员。如果授权一个对象成员，那么将在对象成员和一个分组对象成员之间定义一个授权关系成员。可以在对象成员的终端之间声明通信关系成员，并且在对象成员或者分组对象成员之间声明从属关系成员(引用和宿主)。

关系约束条件，用于限制一个特定对象将参与的关系的组。它们识别对于一个特定关系，以及对于关系另一端的参与者的约束条件。

2.5  实例空间

保存在SDM运行时间内的所述实例空间，反映所述模型系统的当前状态。所述运行时间包含已创建实例的一个完整记录和这些实例之间的关系。每一个实例具有一个相关版本历史，其中每一个版本连接到一个变更请求。

所述创建新实例的处理，是起源于一个变更请求。变更请求定义创建，更新和删除用于类型和与一个已存在实例的指定成员相关的关系的一组请求；所述根是一个特例。

通过所述运行时间扩展该变更请求，对所有约束条件验证该变更请求，然后构造该变更请求。该扩展处理识别对象与关系实例，也就是说隐含的构造该扩展处理，作为该包含对象的结构请求的一部分，然后通过所有关系评估设置数据流。该验证步骤，核对所有存在的所需关系，以及满足所有约束条件的关系。最终，该结构处理对每一个实例的部署，更新或者删除，确定一个适当的顺序，然后在正确的序列中将每一个实例传送至执行适当活动的一个实例管理器。

2.6  分层

SDM模型的目标，在于允许应用程序的开发者，软件基础结构的设计者和资料处理中心的设计师之间，存在一个利害关系的分析。这些组中的每一个，集中在特定的服务，且具有一个依赖关系的不同设置。

例如，开发者主要根据诸如SQL IIS和CLR，关心宿主之间的配置和连通性。该宿主配置的设计者关心网络拓扑结构和操作系统配置，而设计师开发网络拓扑结构，操作系统配置，以及需要了解存在于资料处理中心中的硬件的存储映射。

为了支持这些利害关系的分析，SDM公开了一个分层的概念。分层是将一个应用程序绑定到服务的宿主关系的应用，所述服务取决于没有声明作为该应用程序的包容结构的一部分的那些服务。

我们识别作为SDM模型的一部分的四个层……

应用程序层

·该应用程序层支持在一个被约束的内容中的应用程序的结构。通过在宿主层中识别的宿主的配置定义该内容。

·应用程序层中系统定义的范例，包括网络服务，数据库以及biztalk进程。

宿主层

·从软件组成部分中构造资料处理中心。配置组成部分之间的连接。组成部分中的一些可作为用于该应用程序层的宿主。

·该层中的系统定义的范例-IIS，SQL，AD，EXCHANGE，DNS以及Biztalk。

网络/操作系统/存储层

·构造数据中心网络和平台。配置该网络安全性模型和该操作系统平台配置。将存储器添加到操作系统配置。

·该层中的系统定义的范例-VLAN，窗口，过滤程序，存储器。

硬件层

该硬件层识别存在于资料处理中心中的机器的类型，和存在于这些机器之间的物理连接。

附图11示出了一个4层网络应用程序到一个3层网络服务器宿主的映射的范例。每一个层的外层方框表示一个系统，在边缘上的方框表示终端，且在内部的方框表示资源。我们通过一个宿主关系，将这些元素中的每一个映射到在该层以下的一个宿主。

为了满足一个系统所需的关系，我们将那些系统绑定到一个具有相匹配能力的主机系统。我们将这些处理称为布局。在设计时间，我们构造表示一个合理布局的一个具体宿主关系。在部署时间，我们将用具体例子说明将客人系统实例绑定到该主机系统实例的该具体宿主关系的一个实例。

2.7  模型评估

与该SDM模型相关的，是用于管理转变为一个分布式系统，意义明确的处理。

通过一个说明性的变更请求，驱动每一个变更，该变更请求在对目标系统分配并执行该请求中的活动之前，经过多个处理步骤。

3  实施细节

3.1  命名

在SDM中存在过许多，我们需要一个用于识别目标的稳定的命名系统。以下命名系统，允许一个类型的创建者通过上述方式标记该定义，该的用户可以确信其是与开发者最初公开的定义相同的定义。

以下头文件，是一个用于SDM命名空间的标识符的范例：

<sdm name＝″FileSystem″

version＝″0.1.0.0″

publicKeyToken＝″AAAABBBBCCCCDDDD″

culture＝″neutral″

platform＝″neutraP

publicKey＝″aLongKey″

signature＝″TheHashOfTheFileContents″>

</sdm>

为了在另一个命名空间中引用一个类型，你需要输入该命名空间：

<import alias＝″FileSystem″name＝″FileSystem″version＝″0.1.0.0″

publicKeyToken＝″AAAABBBBCCCCDDDD”/>

然后，你可以在命名空间中使用涉及

FileSystem：file(文件系统：文件)

3.1.1  本体

SDM名称是通 过该命名空间所限定的，该命名空间中定义SDM名称。通过一个名称，版本，语言以及公共密钥令牌识别一个命名空间，且所述SDM名称被包含在一个单独的文件中。

本体的基本形式包括名称，版本，风格(culture)，平台，公共密钥令牌.

<xs：attributeGroup name＝″ldentity″>

<xs：attribute name＝″name″type＝″simpleName″use＝″required″/>

<xs：attribute name＝″version″type＝″fourPartVerstonType″use＝″required″/>

<xs：attribute name＝″publicKeyToken″type＝″publicKeyTokenType″use＝″optional7>

<xs：attribute name＝″clture″type＝″xs：string″use＝″optional″/>

<xs：attribute name＝″platform″type＝″xs：string″use＝″optional″/>

</xs：attributeGroup>

属性/元素 说明名称      该SDM文件的名称是一个友好的名称，以使开发者可用于引用该文件的内容。与公共密钥令牌相结合的名称，提供了一个用于该文件的稳定的名称。版本      版本是用于识别文件的内容的版本。所有文件的元素采用相同的版本号。公共密钥  公共密钥令牌，是一个用于与该文件相关的公共密钥的短名称。风格      二进制的风格，默认为空平台      二进制支持的平台

基础本体可用于引用一个已存在的本体，或者与一个标记和一个公共密钥相结合，以创建一个新稳定的本体。允许该文档的用户使用专用密钥，标记该文档，以使用公共密钥验证它的内容。

<xs：attributeGroupname＝″namespaceldentity″>

<xs：attributeGroupref＝″ldentity″/>

<xs：attribute name＝″signature″type＝″xs：string″use＝″optional″/>

<xs：attribute name＝″publicKey″type＝″xs：string″use＝″optional″/>

</xs：attributeGroup>

属性/元素    说明标记         所包含SDM类型定义的所标记的无用信息公共密钥     可用于核对文件的标记的公共密钥

一个公共密钥令牌，是一个16个字符的十六进制符号串，以便识别一个公共/专用密钥组的公共部分。这不是公共密钥，仅仅是公共密钥的64位的哈希(hash)序列。

<xs：simpleType name＝″publicKeyTokenType″><xs：annotation>

<xs：documentation>Public Key Token：16 hex digits in size</xs：documentation>

</xs：annotation>

<xs：restriction base＝″xs：string″>

<xs：pattern value＝″([0-9]|[a-f]|[A-F]){16}″/>

</xs：restriction>

</xs：simpleType>

3.1.2  版本

通过一个格式为4部分的数字，定义一个文档的版本，其中0＜＝N＜65535。按照惯例，该数字设计Major.Minor.Build.Revision。

<xs：simpleType name＝″fourPartVersionType″>

<xs：restriction base＝″xs：string″>

<xs：pattern value＝″([0-9]{1，4}|[0-5][0-9]4)|64[0-9]{3}|655[0-2][0-9]|6553[0-5])(\.([0-9]{1，4}|[0-5][0-9]{4}|64[0-9]{3}|655[0-2][0-9]|6553[0-5]){3}}″/>

</xs：restriction>

</xs：simpleType>

3.1.3  简单名称

简单名称由字母数字混合的字符和有限的标点符号组成。所述名称应该以一个非数字字符开始。

<xs：simpleType name＝″simpleName″>

<xs：annotation>

<xs：documentation>name of a type or member</xs：documentation>

<xs：annotation>

<xs：restriction base＝″xs：string″>

<xs：pattern value＝″[a-z，A-Z]{1}{([0-9，a-z，A-Z，_])*”/>

</xs：restriction>

</xs：simpleType>

我们计划与C#定义的标识符相一致；以下插入相适应的章节(2.4.2)。所述说明可以在以下地址得到：

http：∥devdiv/SpecTool/Documents/Whidbey/VCSharp/Formal％20Language％2 0Specification/CSharp％20Language％20Specification.doc

注意，在SDM模型中，我们不支持将“@”放在名称的前面。

本节中提出的用于标识符的规则，除允许下划线作为一个首写字符以外(如同C程序设计语言中的传统一样)，完全与统一的字符编码标准附录(Unicode Standard Annex)15相一致，在标识符中，允许换码序列(escape sequences)统一的字符编码标准，且为了使关键字能用作标识符，允许“@”字符作为首写字符。identifier：available-identifier@ identifier-or-keywordavailable-identifier：An identifier-or-keyword that is not a keywordidentifier-or-keyword：identifier-start-character identifier-part-charactersoptidentifier-start-character：letter-character_(the underscore character U+005F)identifier-part-characters：identifier-part-characteridentifier-part-characters identifier-part-characteridentifier-part-character：letter-characterdecimal-digit-characterconnecting-charactercombining-characterformatting-characterletter-character：A Unicode character of classes Lu，Ll，Lt，Lm，Lo，or NlA unicode-escape-sequence representing a character of classes Lu，Ll，Lt，Lm，Lo，or Nlcombining-character：

A Unicode character of classes Mn or McA unicode-escape-sequence representing a character of classes Mn or Mcdecimal-digit-character：A Unicode character of the class NdA unicode-escape-sequence representing a character of the class Ndconnecting-character：A Unicode character of the class PCA unicode-escape-sequence representing a character of the class PCformatting-character：A Unicode character of the class CfA unicode-escape-sequence representing a character of the class Cf对于在上述统一的字符编码标准(Unicode)字符组中的信息，参见统一的字符编码标准(Unicode Standard)，版本3.0，章节4.5。有效标识符的范例，包括“identifier1”，“_identifier2”，和“@if”。在一个适应程序中的标识符，正如统一的字符编码标准附录15(Unicode StandardAnnex)所定义的，应该处于通过统一的字符编码标准标准化格式C(UnicodeNormalization Form C)定义的规范的格式中。然而，当遇到一个不在标准化格式C里时，进行定义实施例的动作，而不需要一个诊断。首字符“@”可以通过使用关键字作为标识符，当与其他编程语言相连接时，可使用首字符“@”。实际上，字符@不是标识符的一部分，因此可以在其他语言中将该标识符作为普通的，没有该首字符的标识符进行查看。具有首字符为“@”的一个标识符，称作一个逐字逐句的标识符。没有关键字的首字符为@的使用，是允许的，但是作为格式的问题是坚决不行的。所述实例：class@class{public static void @static(bool@bool){if(@bool)System.Console.WriteLine(″true″)；

elseSystem.Console.WriteLine(″false″)；}}class Class1{static void M(){clu0061ss.stu0061 tic(true)；}}定义了一个称为“class”的类，该类具有一个称为“static”的静态方法，该方法采用称为“bool”的参数。应注意的是，因为在关键字中不允许统一的字符编码标准换码(Unicode escapes)，所以令牌“clu0061ss”是一个标识符，又是与“@class”相同的标识符。如果在应用以下变换之后，两个标识符完全相同的，那么认为他们是同样的，符合：■如果使用首字符“@”，则删除。■每一个统一的字符编码标准换码序列(unicode escape sequence)，转化为它相应的统一的字符编码标准字符。■删除所有格式化的字符。标识符包含实施例专用的，两个连续的下划线字符(U+005F)。例如，提供一个实施例，以扩展由两个下划线开始的关键字。

3.1.4  反转名称

下面是一个保留名称的列表，当在一个SDM模型中创建对象的名称时，我们将阻止用户使用该列表。

在某些范围内，将存储某些名称

内容                      名称抽象和具体定义            这个抽象和具体宿主关系定义    客户机，主机抽象和具体容纳关系定义    父母，成员抽象和具体通信关系定义    客户机，服务器抽象和具体引用关系定义    源，附属的抽象和具体代理关系定义    协议，代理

由于我们具有CLR的集成，存储这些名称。

C# keywordsAddHandler AddressOf      Alias          And          AnsiAs         Assembly       Auto           Base         BooleanByRef      Byte           ByVal          Call         CaseCatch      CBool          CByte          CChar        CDateCDec       CDbl           Char           CInt         ClassCLng       CObj           Const          CShort       CSngCStr       CType          Date           Decimal      DeclareDefault    Delegate       Dim            Do           DoubleEach       Else           ElseIf         End          EnumErase      Error          Event          Exit         ExternalSourceFalse      Finalize       Finally        Float        ForFriend     Function       Get            GetType      GotoHandles    If             Implements     Imports      InInherits   Integer        Interface      Is           LetLib        Like           Long           Loop         MeMod        Module         MustInherit    MustOverride MyBaseMyClass    Namespace      New            Next         NotNothing    NotInheritable NotOverridable Object       OnOption     Optional       Or             Overloads    OverridableOverrides  ParamArray     Preserve       Private      PropertyProtected  Public         RaiseEvent     Readonly     ReDimRegion     REM            RemoveHandler  Resume       ReturnSelect     Set            Shadows        Shared       Short

Single     Static    Step     Stop     StringStructure  Sub       SyncLock Then     ThrowTo         True      Try      TypeOf   UnicodeUntil      volatile  When     While    WithWithEvents WriteOnly Xor      eval     extendsinstanceof package   Var

3.1.5  其它名称空间的引用

我们通过将他们输入到当前命名空间里，然后使具有该命名空间的别名相关联，从而允许命名空间引用其他命名空间。通过名称，版本和公共密钥令牌，引用所输入的命名空间。版本将在章节3.16部分描述。

<xs：complexType name＝″import″>

<xs：attribute name＝″alias″type＝″simpleName″use＝″required″/>

<xs：attributeGroup ref＝″identity″/>

</xs：complexType>

属性/元素                    说明别名             所述别名用于在当前SDM文档的范围内引用外部SDM文档

3.1.6  所限定的路径

所限定的路径，是涉及定义的名称，或者在当前的命名空间中或者在一个别名的命名空间中所定义的管理器。

[<alias>：]<simpleName>(.<simpleName>)*

所述别名是在一个输入语句中定义的。以下简名，标明一个类型，或者一个路径，一个分组的类型而言。

<xs：simpleType name＝″qualifiedName″>

<xs：restriction base＝″xs：string″>

<xs：patternvalue＝″[a-z，A-Z]{1}([0-9，a-z，A-Z，-])*(：[a-z，A-Z]{1}([0-9，a-z，A-Z，-])*)？(\.[a-z，A-Z]{1}([0-9.a-z，A-Z，-])*)*″/>

</xs：restriction></xs：simpleType>

3.1.7  定义和成员路径

一个路径是标明一个成员或者设置的名称的序列。一个路径能从一个公知的名称或者通过对象或与该路径的关系相关进行定义的成员名称开始。

<simpleName>(.<simpleName>)*

<xs：simpleType name＝″path″>

<xs：restriction base＝″xs：string″>

<xs：pattemvalue＝″[a-z，A-Z]{1}([0-9，a-z，A-Z，-])*(\.[a-z，A-Z]{1}([0-9，a-z，A-Z，_])*)*”/>

</xs：restriction></xs：simpleType>

3.1.8  实例路径

在该实例空间中的路径，是基于xpaths的，其中在该xpath中的元件名称，对应于成员名，且在该xpath中的属性，对应于设置。

3.1.9  名称解析

不从一个别名开始的名称，是不完全限定的。这意味着，在对它们进行评估的范围中，可以变更所结果的绑定。这一个范例，是分组定义的。当解析一个分组定义名称时，在局部范围内的定义，将隐藏在一个宽的范围中的定义里。

3.2  设置

可以设置声明公开所有定义。使用这些设置，以描述当从一个抽象定义创建一个具体定义时所提供的值，或者从在另一个定义内的一个成员引用一个定义时所提供的值。

为了定义一个设置，你首先需要使用xsd，定义设置的定义。

<xs：schema>

<xs：simpleType name＝″registryValueType″>

<xs：restriction base＝″xs：string″>

<xs：enumeration value＝″binary″/>

<xs：enumeration value＝″integer″/>

<xs：enumeration value＝″long″/>

<xs：enumeration value＝″expandString″/>

<xs：enumeration value＝″multiString″/>

<xs：enumeration value＝″string″/>

</xs：restriction>

</xs：simpleType>

</xs：schema>

然后，你可以使用该定义，且包括定义该设置的动作的一组属性来声明一个设置。

<settingDeclaration name＝″valueType″type＝″registryValueType′access＝″readwrite″dynamic＝″false″required＝″true″/>

一旦你具有一个设置声明，那么你可以提供一个用于该设置的值。

<settingValue name＝″valueType″fixed＝″true″>long</settingValue>

3.2.1  设置定义

我们使用XSD模式来定义通过设置声明所使用的设置定义。即使存在其他模式元素，我们也支持一个模式中的所述简单和复杂类型的使用，从而支持那些类型的定义。

所述设置定义部分应该包含一个完整的XML模式，包括命名空间声明和命名空间引入。我们将核对在XSD模式中的引入，是否与除XSD模式命名空间之外的SDM文件中的引入相匹配。这意味着所有引用类型应该在另一个SDM文件中定义；该模式不能在任意xsd文件中定义引用类型。

<xs：complexType name＝″settingDefinitions″>

<xs：sequence>

<xs：element ref＝″xs：schema″/>

</xs：sequence>

<xs：attribute name＝″manager″type＝″qualifiedName″use＝″optional″/>

<xs：attribute name＝″clrNamespace″type＝″xs：string″use＝″optional″/>

</xs：complexType>

属性/元素      说明xs：大纲       在命名空间 http：∥www.w3.org/2001/XMLSchma中的一个大纲管理器         所述clr假定包含用于该模式的辅助分类clr域名空间    所述clr域名空间中定义这些类。所有设置类型，通过CLR序列，基于它们的映像，确定一个CLR

设置将从三个独立的命名空间中进行确定：

a)sdm命名空间-当我们在系统，资源，端点，关系，约束条件或数据流类型中涉及设置类型时。

b)clr命名空间-当我们在clr内使用稳定类型的类进行设置时，以及当设置类型基于其他设置类型时。

c)XSD命名空间-当使用其他设置类型构造设置类型时。

为了使其运行，我们在声明设置的过程中设置了许多限制条件：

a)所有的设置应置于在每一个clr，sdm和xsd命名空间内的相同的组中。也就是说，如果在一个命名空间中，将两个设置置于一起，那么在所有三个命名空间中，它们都会在一起。

b)在一个xsd模式定义内输入的命名空间，可以与在一个SDM文件中输入的命名空间，以及在相关辅助装置中输入的命名空间相匹配。

c)除该xsd命名空间外，在一个xsd模式中所有输入的命名空间应该定义在一个SDM文件内。

使用QNames，可访问所输入的SDM文档中的XSD类型：

<alias>：<type-name>

然而，例如，如果Foo.sdm输入Bar.sdm，则Bar.sdm的设置类型可以在Foo.sdm的设置类型的元素中引用，如同范例中所描述的：

<！-Foo.sdm->

<import alias＝″bar″location＝″Bar.sdm″.../>

<settingTypes>

<xs：simpleType name＝″D″>

<xs：restriction base＝″bar：B″.../>

</xs：simpleType>

</settingTypes>

<！-Bar.sdm->

...

<settingTypes>

...

<xs：simpleType name＝″B″>

<xs：restriction base＝″xs：string″.../>

</xs：simpleType>

...

</settingTypes>

3.2.2  嵌入简单数据类型

该SDM支持一个所嵌入数据类型的有限集，也就是说，XSD和C#命名空间的一个交集。通过SDM运行时间自然地支持这些类型，和在以下表格中定义这些类型，除这些类型之外，用户自由地构造和使用他们在xsd和cls类型之间自己映象的类型。

类型              说明                        XSD类型     C#类型(string)字符串型  一个字符串是统一的编码标准  字符串型    字符串型字符的一个序列(integer)整型     64位有符号的整数类型        长型        长型(float)单精度型   单精度浮点类型              单精度型    单精度型(double)双精度型  双精度浮点类型              双精度型    双精度型(boolean)布尔型   一个布尔值为真或者假        布尔型      布尔型(any)任意型       所有其它类型的基础类型      任意型      对象(Date)日期型      一个简单的日期              日期型      日期时间

这些类型可以在c#和xsd类型空间中流向这些类型的并存的派生。例如一个字符串值可以流向一个定义对字符串的限制的xsd类型，并且任何一个值均可流向接受类型＝“any″的一个设置。

3.2.2.1  XSD  嵌入类型

附图12说明了分层嵌入数据类型的实例。

3.2.2.2  C#数据类型

类型	说明	实例
			object	所有其它类型的最基础的类型	object o＝null；
string	字符串类型，一个字符串是一个统一的编码标准字符序列	string s＝″hello″；
			sbyte	8位有符号数据类型	sbyte val＝12；

short	16位有符号数据类型	short val＝12；
			int	32位有符号数据类型	int val＝12；
long	64位有符号数据类型	long val1＝12；long val2＝34L；
			byte	8位无符号数据类型	byte val1＝12；
ushort	16位无符号数据类型	ushort val1＝12；
			uint	32位无符号数据类型	uint val1＝12；uint val2＝34U；
ulong	64位无符号数据类型	ulong val1＝12；ulong val2＝34U；ulongval3＝56L；ulong val4＝78UL；
			float	单精度浮点类型	float val＝1.23F；
double	双精度浮点类型	double val1＝1.23；double val2＝4.56D；
			bool	布尔类型；一个布尔值为真或者假	bool val1＝true；bool val2＝false；
char	字符类型，一个字符值是一个统一的编码标准字符	char val＝′h′；
			decimal	具有28个有效数字的精确十进制类型	decimal val＝1.23M；

3.2.2.3  所支持的换算

这里是xsd类型和cls类型之间存在的换算。

XML Schema(XSD)type                NMTOKEN

(XML模式(XSD)类型)                 NMTOKENS

anyURI                             nonNegativelnteger

base64Binary                       nonPositivelnteger

Boolean                            normalizedString

Byte                               .NET Framework type

Date                               (.NET帧类型)

dateTime

decimal                            System.Uri

double                             System.Byte

duration                           System.Boolean

ENTITIES                           System.SByte

ENTITY                             System.DateTime

Float                              System.DateTime

gDay                               System.Decimal

gMonthDay                          Double

gYear                              System.Double

gYearMonth                         System.TimeSpan

hexBinary                          System.String

ID                                 System.String

IDREF                              System.Single

IDREFS                             System.DateTime

int                                System.DateTime

integer                            System.DateTime

language                           System.DateTime

long_                              System.ByteQ

month                              System.String

Name                               System.String

NCName                             System.StringQ

negativelnteger                    System.lnt32

System.Decimal                       System.DateTime

System.String                        System.DateTime

System.lnt64                         System.String

System.DateTime                      System.Byte

System.String                        System.Ulnt32

System.String                        System.Ulnt64

System.Decimal                       System.Ulnt16

System.String

System.StringQ

System.String

System.Decimal

NOTATION

positivelnteger

QName

short

string

time

timePeriod

token

unsignedByte

unsignedlnt

unsignedLong

unsignedShort

System.Decimal

System.Xml.XmlQualifiedName

System.lnt16

System.String

3.2.3  设置声明

该设置声明部分使用前一部分中的设置定义，以创建已命名的设置。使用属性，以提供关于每一个设置的更多信息。

<xs：complexType name＝″SettingDeclaration″>

<xs：complexContent>

<xs：extension base＝″Member″>

<xs：attribute name＝″List″type＝″xs：boolean″/>

<xs：attributeGroupref＝″settingsAttributes″/>

</xs：extension>

</xs：complexContent>

</xs：complexType>

属性/元素 说明设置属性  可应用于一个单独的设置声明的属性的集合列表      用于指示该设置是一个多于一个独立的值的列表的属性

3.2.4  列表支持

为了支持多个值的设置的计算，我们支持简单的设置值的列表。一个列表，是一个与设置声明相同的定义的值的序列。列表可以流动到其它可替换或合并的列表。当将值合并到一个列表时，因为可以更灵活地执行，我们不支持副本检测，并且不保证任何一种排序的形式。

一个列表声明包括一 个设置为true的属 性列表：

<settingDeclaration name＝″roles″type＝″xs：string″list＝″true″/>

使用一个设置值列表，提供多个值。当提供该列表时，用户可以指定是否替换或合并之前的值。

<settingValueList name＝″roles″fix＝″true″replace＝″true″>

<value>staticContent</value>

<value>aspPages</value>

</settingValueList>

该sdm支持简单的值的列表的计算。当一个路径从一个数据流成员中确定一个设置声明为目标时，所产生的行为，是在路径的任一端点的定义。

源      目的    结果元素    列表    替换＝假-元素被添加至该列表替换＝真-列表具有一个元素列表    列表    替换＝假-源列表和目标列表合并替换＝真-源列表列表    元素    sdm不能确定从该列表中选择哪个元素，所以不支持这个组合

3.2.5  设置属性

通过运行时间，设置用于描述特定设置的行为的属性。

<xs：attributeGroup name＝″settingsAttributes″>

<xs：attribute name＝″access″>

<xs：simpleType>

<xs：restriction base＝″xs：string″>

<xs：enumeration value＝″readwrite″/>

<xs：enumeration value＝″readonly″/>

<xs：enumeration value＝″writeonly″/>

</xs：restriction>

</xs：simpleType>

<xs：attribute>

<xs：attribute name＝″secure″type＝″xs：boolean″/>

<xs：attribute name＝″deploymentTime″type＝″xs：boolean″/>

<xs：attribute name＝″required″type＝″xs：boolean″/>

<xs：attribute name＝″dynamic″type＝″xs：boolean″/>

<xs：attribute name＝″keyValue″type＝″xs：boolean″/>

<xs：attribute name＝″nillable″type＝″xs：boolean″/>

<xs：attributeGroup>

属性名称  说明                                                    默认访问      一个设置的访问属性指定是否允许读取和写入该设置的值；    读写提供SDM运行时间访问控制，并显示/编辑对于设计者的规则属性值    在SDM运行时间中的意义  显示/编辑规则读写      表示设置值可以读取和写入  能够对值进行显示和编辑只读      表示设置值只能读取，而不  能够显示值，能写入。这个值不能成为数  但不能编辑据流的目标。通常，一个只读设置，是能够由现实世界实例计算，或提供的。例如：一个服务器上表示连接的个数的值。只写      表示设置值只能写入，但不能  屏蔽了值，但读取。这个值不能成为数据流  能够进行编辑的源。例如：一个服务帐户的密码部署时间  只能提供作为一个实例的部署处理的一部分的一个值。设计    假时间约束条件不能对该值进行评估。一个定义或成员不能为这个设置提供一个固定的值。需求      如果需求为真，那么在部署一个实例之前，提供用于该设置    假的值。该设置不能为只读。动态      如果动态为真，那么在部署一个实例之后，实例管理员支持    真对该值的变更。密钥值    密钥值是用来表示在它的宿主范围内的唯一的一个设置。实    假例管理员在路径中使用该设置，来识别对象实例，并检测已存在实例的冲突。安全      一个设置的安全属性，指定当存储一个SDM文档时，该设置     假的值是否加密(真或假)。也表示在诸如安装的处理过程中，工具是否输入这个值。

Nillable 一个设置的nillable属性表示如果执行来自命名空间       假http：∥www.w3.org/2001/XMLSchema-instance的命名空间确认属性xsi：nil，一个设置值是否有效

3.2.6  设置值

根据设置是否声明为一个单独的值或一个列表，使用一个设置值元素或一个设置值列表元素，提供用于该设置的值。

3.2.6.1  设置值

一个设置值用于提供特定设置声明的值。该值与和该声明相关的定义相匹配。如果这个值声明为固定的，那么根据这个值固定的点，将所提供的值用于所有所得到的定义或引用成员。一旦固定一个值，则这个值将不能被替换。

<xs：complexType name＝″settingValue″>

<xs：complexContent>

<xs：restriction base＝″xs：anyType″>

<xs：attribute name＝″name″type＝″simpleName″use＝″required″/>

<xs：attribute name＝fixed″type＝″xs：boolean″use＝″opeional default＝″false″/>

<xs：attribute ref＝″xsi：nil″use＝″optional default＝″false″/>

<xs：restricttion>

</xs：complexContent>

<xs：complexType>

属性/元素 说明名称      将应用该值的设置声明的名称固定      固定属性控制所提供的值可以随后被新的值替换。一个固定值的真，表示所提供的设置值不能被替换。如果对于一个具体定义成员的设置值，固定的值为真，则将在成员的一        所有部署中固定该值。否则，如果固定的值为假，则在该成员的每

个部署中替换该值。如果对于一个具体定义的设置值，固定的值为真，则将对该具体定义的所有成员(例如使用)固定该值。否则，如果固定的值为假，则对该具体定义成员的每一个成员变化该值。如果对于一个抽象定义的设置值，固定的值为真，则对所实现的具体定义，或扩展抽象定义的抽象对象，固定该值。否则，如果固定的值为假，则可以在派生抽象定义，或成员声明中，通过具体定义替换该值。零(Nil)最后，如果一个设置值具有值为真的属性xsi：nil，则将没有内容的设置值看作有效。标明的一个元素应该为空，但如果该设置定义允许，则仍可以带有属性。

3.2.6.2  设置值列表

设置值列表用于提供一个作为列表声明的设置的一个或多个值。当声明多个值时，用户能够确定合并之前的值，或覆盖所有之前的值。

<xs：complexTypename＝″settingValueList″>

<xs：sequence>

<xs：element name＝″value″minOccurs＝″0″maxOccurs＝″unbounded″>

<xs：complexType>

<xs：complexContent>

<xs：restrictionbase＝″xs：anyType″>

</xs：restriction>

</xs：complexContent>

</xs：complexType>

</xs：element>

</xs：sequence>

<xs：attribute name＝″name″type＝″simpleName″use＝″required″/>

<xs：attribute name＝″fixed″type＝″xs：boolean″：use＝″optional″default＝″false″/>

<xs：attribute name＝″replace″type＝″xs：boolean″use＝″optional″default＝″false″/>

</xs：complexType>

属性/元素    说明名称         将应用该值的设置声明的名称固定         固定属性控制所提供的值可以随后被新的值替换。一个固定值的真，表示所提供的值不能被替换。如果对于一个具体定义成员的设置值，固定的值为真，则将在成员的所有部署中固定该值。否则，如果固定的值为假，则在该成员的每一个部署中替换该值。如果对于一个具体定义的设置值，固定的值为真，则将对该具体定义的所有成员(例如使用)固定该值。否则，如果固定的值为假，则对该具体定义成员的每一个成员变化该值。如果对于一个抽象定义的设置值，固定的值为真，则对所实现的具体定义，或扩展抽象定义的抽象对象，固定该值。否则，如果固定的值为假，则可以在派生抽象定义，或成员声明中，通过具体定义替换该值。替换      替换属性，用于标明一个设置的新值是否与一个设置之前的任意一个未固定的值进行替换或合并。如果“替换”为真，则忽略所有之前的值。如果“替换”为假，则新的和之前的值将被组合至一个单独列表。在合并期间将不检测副本。

3.2.7  设置继承

设置继承意味着一个派生定义，该定义隐含基础定义中的所有设置声明。设置继承的一些重要方面是：

●设置继承是可传递的。如果从B派生C，且B是从A派生的，那么C继承了B中声明的设置，以及A中声明的设置。

●一个派生定义，能够将新的设置声明添加至那些从基础定义中扩展的继承的定义，但是它无法删除一个继承组的定义。

3.2.8  类型转换

我们支持在嵌入类型之间的无损转换。为了执行适当的转换，需要流经其它类型转换。

3.3  属性

SDM中的许多对象，可以是捕获行为的结果，即对该对象的核心行为互不相关。我们使用一个通用属性模型进行如下定义：

3.4  定义和成员

3.4.1  定义

定义是派生出对象，关系，约束条件和数据流定义的基础。所有定义可以包括一个设置模式，和设计表面数据。通过一个简单名识别每一个定义，并引用一个管理器。该管理器负责提供扩展名，以支持用于特定定义的SDM运行时间。

该设置模式定义在这个定义的一个实例上找到的值。该设计数据元素，用于指定在设计表面上的定义的显示和编辑的包含数据。

<xs：complexType name＝″Definition″>

<xs：sequence>

<xs：element name＝″Description″type＝″Description″minOccurs＝″0″/>

<xs：element name＝″DesignData″type＝″DesignData″minOccurs＝″07>

<xs：choice minOccurs＝″0″maxOccurs＝″unbounded″>

<xs：element name＝″SettingDeclaration″type＝″SettingDeclaration″/>

<xs：element name＝″SettingValue″type＝″SettingValue″/>

<xs：element name＝″SettingValueList″type＝″SettingValueList″/>

</xs：choice>

</xs：sequence>

<xs：attribute name＝″Name″type＝″SimpleName″use＝″required″/>

<xs：attribute name＝″Manager″type＝″QualifiedName″use＝″optional″/>

<xs：attribute name＝″ClrClassName″type＝″xs：string″use＝″optional7>

</xs：complexType>

属性/元素   说明设置声明    一个设置的声明设置值      在定义或它的基础定义上的一个设置的值在一个定义内，将一个值一次提供给一个设置声明。设置值列表  在定义或它的基础定义上设置的用于可写列表值的值的列表设计数据    设计表面特定数据名称        该定义的名称，在包含SDM文件范围内是唯一的管理器      用于该定义的管理器声明的引用。参见用于管理器定义的章节3.10CLR类名称   clr类的名称，支持在运行时间中的定义。该类存在于管理器识别的集合中。如果该属性存在，则应表现为管理器属性。说明        该定义的一个文本说明

3.4.2  成员

使用成员，来识别存在于运行时间的定义实例。在类型的范围之内，使用唯一的名称，识别所有成员，所有的成员可以提供用于他们所引用的定义的设置，且可以包含设计表面特定数据。

<xs：complexType name＝″Member″>

<xs：sequence>

<xs：element name＝″Description″type＝″Description″minOccurs＝″0″/>

<xs：element name＝″DesignData″type＝″DesignData″minOccurs＝″0″/>

<xs：choice minOccurs＝″0″maxOccurs＝″unbounded″>

<xs：element name＝″SettingValue″type＝″SettingValue″/>

<xs：element name＝″SettingValueList″type＝″SettingValueList″/>

</xs：choice>

</xs：sequence>

<xs：attribute name＝″Name″type＝″SimpleName″use＝″required″/>

<xs：attribute name＝″Definition″type＝″QualifiedName″use＝″required″/>

</xs：complexType>

属性/元素   说明说明        成员的一个说明设计数据    关于成员的设计表面特定信息

设置值      设置值，相应于引用类型上的可写设置。如果将这些值标记为固定，那么当创建一个用于成员的实例时，使用这些值，如果他们不是固定的，那么通过部署或流经的参数，替换这些值。设置值列表  在引用类型上设置用于可写列表的值的列表名称        在包含类型范围内，唯一的成员名称定义        该成员引用的定义的名称。

3.5  设置数据流

在一个对象定义的成员之间，和关系中的参与者之间，通过参数使用数据流。作为一个数据流的一部分，用户可以使用转换来组合或分离设置值，并计算新的设置值。

所有设置数据流成员，使用一个数据流定义来执行该转换。在sdm文件中声明一个数据流定义。以下是一个分析一个url的数据流类型。

<FlowDefinition name＝″UrlToComponents″>

<SettingDeclaration name＝″url″type＝″url″access＝″writeonly″/>

<SettingDeclaration name＝″protocol″type＝″xs：string″access＝″readonly″/>

<SettingDeclaraion name＝″server′type＝″xs：string″access＝″readonly″/>

<SettingDeclaration name＝″path″type＝″xs：string″access＝″readonly″/>

<SetlingDeclaration name＝″file″type＝″xs：string″access＝″readorty″/>

</FlowDefinitton>

然后，在一个对象或关系中，声明一个数据流成员。该数据流成员提供该数据流定义的输入，且然后直接从该数据流输出至目标设置。

<Flow name＝″deconstructUrl″type＝″UrlToComponents″>

<lnput name＝″url″path＝″webservice.url″/>

<Output name＝″server″path＝″webservice.server″/>

</Flow>

3.5.1  数据流定义

我们使用一个数据流定义，来定义我们希望应用于一组设置值的一个特定转换。该数据流定义公开了一个设置模式，该设置模式，定义了输入设置(只写设置)和输出设置(只读设置)，一个用于诸如一个用于定义该转换的输入接口，和一个浏览该sdm文件时使用的说明之类的设计表面指定信息的设计数据章节。该数据流定义，是在其所定义的命名空间内，通过名称进行识别的。当评估该数据流时，该定义也识别支持运行时间的一个管理器。

我们希望运行时间将包括多个标准数据流定义，以简化需要直接的转换的数据流元素的构成。实例可以包括副本，合并和字符串置换。由于数据流定义可以是参数化的，我们也希望存在基于配置参数，执行不同的活动的，一个或多个简单的转换。

<xs：complexType name＝″FlowDefinition″>

<xs：complexContent>

<xs：extension base＝″Definition″/>

</xs：complexContent>

</xs：complexType>

3.5.2  数据流成员

每一个数据流元素识别一个或多个源节点，一个或多个目标节点，一些静态设置和一个数据流定义。当评估数据流时，从源节点采集源数据，并与数据流元素中的设置相结合，并传送至用于转换的数据流定义。将输出数据传送至目标节点。

只要源值之一发生变更，将触发数据流的再次评估。因此，我们需要避免使值进入触发电路的循环数据流。如果该值保持不变，则结束该循环。运行时间将通 过跟踪堆栈深度，检测并结束初始循环。

<xs：complexType name＝″FlowMember″>

<xs：complexContent>

<xs：extension base＝″Member″>

<xs：choice minOccurs＝″0″maxOccurs＝″unbounded″>

<xs：element name＝″lnput″type＝″SettingTarget″/>

<xs：element name＝″Output″type＝″OutputPath″/>

</xs：choice>

</xs：extension>

</xs：complexContent>

</xs：complexType>

属性/元素 说明输入      关于用于输入至该数据流的设置值的路径的列表。每一个输入，将识别在该数据流定义中的一个只写设置。输出      关于将被设置为该数据流的结果的设置的路径列表。每一个输出，将识别在该数据流定义中的一个只读设置。

3.5.3  设置目标

一个设置目标在一个成员或分组成员中，识别一个关于一个设置值的路径，该设置值相对于上下文中对该数据流进行定义的一个已知名称。已知名称的实例包括在一个定义或引用声明中的值，在一个宿主关系声明中的宿主和客人，或在一个约束条件声明范围内所定义的一个目标。该设置目标也识别相关数据流定义的设置，所述相关数据流定义，通过路径，识别设置的源值或目标设置。

<xs：complexType name＝″SettingTarget″>

<xs：attribute name＝″Name″type＝″SimpleName″/>

<xs：attribute name＝″Path″type＝″Path″/>

</xs：complexType>

属性/元素 说明名称      对于数据流或约束条件定义的设置的名称，可通过该路径，识别设置的源设置或目标设置。路径      通向源设置或者目标设置的路径，相对于上下文对该数据流进行的定义。该路径将识别一个单独的设置-这意味着该路径的所有成员的最大基数应为1或者0。

输出路径在设置目标上是一个变量，该设置目标是支持固定和替换该目标值的语义。

<xs：complexType name＝″OutputPath″>

<xs：complexContent>

<xs：extension base＝″SettingTarget″>

<xs：attribute name＝″Fix″type＝″xs：boolean″use＝″optional″/>

<xs：attribute name＝″Replace″type＝″xs：boolean″use＝″optional″/>

</xs：extension>

</xs：complexContent>

</xs：complexType>

属性/元素 说明固定      这里声明该目标值是固定的。这意味着任何一种试图随后修改该值的企图，都将产生一个错误。替换      当一个列表是路径的目标时，我们可以选择合并或替换列表的当前内容。默认行为将与当前内容合并。

3.6  设置约束条件

约束条件用于识别对一个定义的成员的设置值的限制，或者对一个关系中的参与者的限制。实例空间中，在设计时间和部署时间对这些限制进行评估。

所有的设置约束条件，使用一个约束条件定义，以评估该设置值。该约束条件定义，使用设置声明，来识别它所约束的值。以下约束条件定义，采用两个自变量和一个操作者，实现一个简单的比较函数，然后评估该约束条件并最终返回成功或者错误。

<ConstraintDefinition name＝″SimpleOperatorComparison″>

<SettingDeclaratton name＝″LHS″type＝″xs：any″access＝″writeonly″/>

<SettingDeclaration name＝″operator″type＝″operator″access＝″writeonly″/>

<SettingDeclaration name＝″RHS″type＝″xs：any″access＝″writeonly″/>

</ConstraintDefinition>

然后应用一个约束条件来将值提供给用于评估的约束条件类型。

<Constraint                 name＝″constraintSecurityMode″definition＝″SimpleOperatorComparison″>

<lnput name＝″LHS″path＝″webservice.securityMode″/>

<SettingValue name＝″operator″>＝＝</settingValue>

<SettingValue name＝″RHS″>basicAuth<settingValue>

</Constraint>

3.6.1  约束条件定义

一个约束条件定义定义作用于一组输入值的一个约束条件。可以对该约束条件进行参数化，以选择常规行为，或者使用参数来支持一个简单的约束条件引擎，以定义其行为。我们希望写入一组用于简单参数值约束条件的标准约束条件定义，以及一组支持抽象对象之间的已知关系的复杂约束条件。

<xs：complexTypename＝″ConstraintDefinition″>

<xs：complexContent>

<xs：extension base＝″Definition″/>

</xs：complexContent>

</xs：complexType>

3.6.2  约束条件成员

一个约束条件成员识别一组用于一个特定的约束条件定义的输入值。成员可以识别用于设置的静态参数值，且可以使用输入语句来将一个约束条件设置绑定至一个路径。

<xs：complexType name＝″ConstraintMember″>

<xs：complexContent>

<xs：extension base＝″Member″>

<xs：choice minOccurs＝″0″maxOccurs＝″unbounded″>

<xs：element name＝″lnput″type＝″SettingTarget″/>

</xs：choice>

</xs：extension>

</xs：complexContent>

</xs：complexType>

属性/元素 说明输入      对于约束条件的输入的列表。一个输入，识别一个关于该源设置值的路径，该源设置值将被传送至约束条件，且因此将设置该约束条件设置。源设置定义以及约束条件设置定义将是兼容的。

3.7  系统终端和资源定义

这一节将描述用于抽象和具体对象定义的模式。

一个抽象对象定义公开了一组设置声明，能够包含参与关系的约束条件，且在运行时间中具有一个相关的管理器。

以下是用于一个网络服务器的一个抽象系统定义。该网络服务器具有两个设置，且具有一个 需要至少包含vsite类型的关系约束条件。

<AbstractSystemDefinitionname＝″WebServer″

clrClassName＝″micorosft.sdm.IISSupportClass″manager＝″IISSupportCode″>

<SettingDeclaration name＝″serverName″type＝″xs：string″/>

<SettingDeclaration name＝″category″type＝″xs：string″/>

<RelationshipConstraint name＝″containsVsites″

relationship＝″containmentRelationship″

myRole＝″parent″

targetType＝″vsite″

minOccurs＝″1″

maxOccurs＝″unbounded″/>

</AbstractSystemDefinition>

Vsite是一个包含服务器绑定信息的抽象终端定义。

<AbstractEndpointDefinition name＝″vsite″>

<SettingDeclaration name＝″ipAddress″type＝″ipaddress″required＝″true″/>

<SettingDeclaration name＝″Endpoint″type＝″xs：int″/>

<SettingDeclaration name＝″domainName″type＝″xs：int″/>

<SettingDeclaration name＝″securityModel″type＝″securityModelEnum″/>

</AbstracEndpointDefinition>

用于前端网络服务器的一个具体系统定义，将网络服务器类别作为静态内容识别，包含一个单独的参数引用终端成员，该成员能够表示1到100之间的终端实例。对用于终端的具体终端定义，在系统定义内进行分组，且其定义用于vsite的ip终端为终端80。

<SystemDefinition name＝″FrontendWebServer″implements＝″WebServer″>

<SettingValue name＝″category″fixed＝″true″>staticContentOnly</settingValue>

<Port name＝″contentOnlyVsite″type＝″port80Vsite″isReference＝″true″

minOccurs＝″1″maxOccurs＝″100″/>

<PortDefinition name＝″port80Vsite″implements＝″vsite″>

<SettingValue name＝″Endpoint″fixed＝″true″>80</settingValue>

</PortDefinition>

</SystemDefinition>

3.7.1  对象定义

抽象和具体对象扩展至以下基础对象定义。除基础类型定义的元素之外，他们能够共享约束对象所参与的关系。

<xs：complexTypename＝″ObjectDefinition″>

<xs：complexContent>

<xs：extension base＝″Definition″>

<xs：choice minOccurs＝″0″maxOccurs＝″unbounded″>

<xs：element name＝″Flow″type＝″FlowMember″minOccurs＝″0″

maxOccurs＝″unbounded″/>

<xs：element name＝″RelationshipConstraintGroup″

type＝″RelationshipConstraintGroup″/>

<xs：elementname＝″RelationshipConstraint″type＝″RelationshipConstraint″/>

</xs：choice>

</xs：extension>

</xs：complexContent>

</xs：complexType>

属性/元素       说明数据流          一个数据流成员声明关系约束条件    能够参与这些类型的关系的约束条件关系约束条件组  能够参与这些类型的关系的约束条件

3.7.2  抽象对象定义

使用抽象对象定义，定义设计表面公开的结构单元，并从其中派生所有的具体对象：一个具体对象定义将实现一个抽象对象定义。

通过添加简单的继承，将抽象对象定义扩展到SDM对象：扩展属性用于识别一个用于一个抽象对象定义的基础对象定义。然后，该抽象对象定义继承从基础对象定义中得到的设置和关系约束条件。经过继承，该对象定义通过添加新的设置和约束条件，扩展该抽象对象定义的设置和约束条件。

抽象对象定义，还可以在他们希望参与的关系上添加约束条件。例如一个抽象对象定义可能需要某些关系的存在，可以在关系的另一个终点上约束该对象定义，或者可以在参与一个给定关系的实例上约束该设置。

3.7.2.1  抽象对象定义

所有抽象对象可以识别他 们希望相关的层。如果这些没有提供这些层，假定该对象定义可以在任何一层中使用。抽象对象定义可以识别一个扩展的基础对象定义，而在这样情况下他们继承那些对象定义的设置和约束条件，并且可以在基础对象定义参与的关系中被基础对象定义所代替。

<xs：complexType name＝″AbstractObjectDefinition″>

<xs：complexContent>

<xs：extension base＝″ObjectDefinition″>

<xs：attribute name＝″Layer″type＝″xs：string″use＝″optional″/>

<xs：attribute name＝″Extends″type＝″QualifiedName″use＝″optionarl″/>

</xs：extension>

</xs：complexContent>

</xs：complexType>

属性/元素  说明层         层属性识别可以用作抽象对象定义的层。如果不提供这些层，该抽象对象定义可以在任何一层中使用。扩展       识别由抽象对象定义派生的对象定义

3.7.2.2  抽象终端，系统和资源对象定义

在SDM模型中存在三个类别的抽象对象定义，他们是：抽象终端定义，抽象系统定义以及抽象资源定义。它们中的每一个，都是抽象对象定义的一个简单的重命名。

<xs：complexType name＝″AbstractEndpointDefinition″>

<xs：complexContent>

<xs：extension base＝″AbstractObjectDefinition″/>

</xs：complexContent>

</xs：complexType>

<xs：complexType name＝″AbstractSystemDefinition″>

<xs：complexContent>

<xs：extension base＝″AbstractObjectDefinition″/>

</xs：complexContent>

</xs：complexType>

<xs：complexType name＝″AbstractResourceDefinition″>

<xs：complexContent>

<xs：extension base＝″AbstractObjectDefinition″/>

</xs：complexContent>

</xs：complexType>

终端定义表示通信终端。在终端的设置，涉及它在绑定过程中的使用。例如，对于一个客户机服务器协议，服务器终点定义可以使用该设置模式，以识别需要绑定至该终端的设置，客户机终端定义可以公开客户指定的连接属性。

系统定义用于表示数据，软件或者硬件元素的集合。范例包括网页服务，数据库以及交换机。资源定义用于捕获识别为一个系统定义的一部分的指定元素。

3.7.3  隐含基础定义

如附图13中所说明的，所有未扩展至另一个抽象对象定义的抽象对象定义，隐含扩展至该终端，系统或者资源基础定义之一。这些基础定义形成一个用于每一个可以用在关系和约束条件声明中的树的根。这允许以关系或者约束条件来表示将由根派生的类型的任意一种，用于代替所识别的根定义。这些根类型总是抽象的，且不能直接用具体的例子说明。

这些类型的定义包括在该模型内控制它们用具体例子说明的基础约束条件；他们可以在System.sdm中找到。

3.7.4  具体对象定义

具体对象定义提供了抽象对象定义的实现。该实现是由对象和关系成员、用于对所实现的抽象定义进行设置的值、新的设置说明、成员与成员上的约束条件之间的信息流构造而成的。

具体定义还可以包括成组定义的说明。这些定义用于包含定义范围之内的成员并且这些定义引用位于该定义范围之外的约束条件。

3.7.4.1  基本具体对象定义

基本具体类型扩展了对象定义、固有设置声明、设计数据、可选管理引用、名称、其所参与的关系的约束条件、可提供用于抽象定义设置的值、并且可描述其设置与其成员设置之间的信息流。此后具体定义进一步可识别其所实现的抽象定义，并且若干可选属 性进一步可定制该定义的绑定特性。

<xs：complexType name＝″ConcreteObjectDefinition″>

<xs：complexContent>

<xs：extension base＝″ObjectDefinition″>

<xs：attribute name＝″lmplements″type＝″QualifiedName″use＝″required″/>

</xs：extension>

</xs：complexContent>

</xs：complexType>

属性/元素   说明实现        识别具体类型所实现的抽象类型

3.7.4.2  对象成员

对象成员将引用抽象对象定义或者具体对象定义。它们可表示这样一个实例的阵列，即在这些例子的情况下它们可定义该阵列的上下界限。如果它们是一引用成员，那么此后例示该对象的用户将明确的构造该成员的实例。如果它们不是引用成员，那么此后，在创建外部对象的同时运行时间将创建一实例。

<xs：complexType name＝″ObjectMember″>

<xs：complexContent>

<xs：extension base＝″Member″>

<xs：attribute name＝″MinOccurs″type＝″xs：int″use＝″optional”/>

<xs：attribute name＝″MaxOccurs″type＝″xs：int″use＝″optional″/>

<xs：attribute name＝″lsReference″type＝″xs：boolean″use＝″required″/>

</xs：extension>

</xs：complexContent>

</xs：complexType>

属性/元素  描述MinOccurs  实例数目的下限与该成员有关。如果其是零，那么此后可选择该成员。缺省值是1。

MaxOccurs   实例数目的上限与该成员有关。应该为1或者更大。缺省值是1。IsReference 如果该值是真，那么此后操作员将明确的创建与该成员有关的实例并且在另一个类中将引用该实例。如果其是假，那么此后当创建了该类型时创建该实例。

在sdm模型中我们必须区分这样的成员，该成员是当构造父母时所创建的，并且当由具有与父母无关的使用期限的那些成员破坏了父母时，该成员被破坏。为此我们使用IsReference属性。利用C++声明来进行简单的类比，该C++声明根据是否使用新的来创建一实例而允许基于栈和基于堆的结构。如果一成员被标记为IsReference，那么此后操作员需要清楚的新操作以创建实例并且使其与该成员相关。

我们这样做是有多种原因的：

1、当操作员构造一系统时，我们显示出能够构造IsReference成员。这极大的简化了操作员经验。

2、当我们对sdm文档进行处理时，我们具有很高的界限，在这个界限该文档的实例空间不同于具体定义空间的实例空间。

3.7.4.3  关系成员

关系成员识别这样的关系，即当创建了对象成员时存在于对象成员之间的关系。关系实例是由操作员明确创建的或者是由运行时间隐含创建的。前者的例子是实例之间的宿主关系，后者的例子是系统之间的通信关系。

<xs：complexType name＝″RelationshipMember″>

<xs：complexContent>

<xs：extension base＝″Member″>

</xs：extension>

</xs：complexContent>

</xs：complexType>

3.7.4.3.1  宿主成员

主成员用于声明两个对象成员之间的宿主关系。对象成员可以是指包括定义的成员或者是其具有与定义的成员关系的成组成员。应该有所引用成员与包括定义之间的成员链。

<xs：complexTypename＝″HostingMember″>

<xs：complexContent>

<xs：extension base＝″RelationshipMember″>

<xs：attribute name＝″GuestMember″type＝″Path″use＝″required″/>

<xs：attribute name＝″HostMember″type＝″Path″use＝″required″/>

</xs：extension>

</xs：complexContent>

</xs：complexType>

属性/元素   描述寄宿者成员  识别这样的成员，该成员具有与关系的寄宿者不矛盾的一定义。成员是成组的。主成员      识别这样的成员，该成员具有与关系的宿主不矛盾的一定义。成员是成组的。

3.7.4.3.2  通信成员

通信成员用来声明该定义的即时系统成员的终端成员之间的通信关系。

<xs：complexTypename＝″CommunicationMember″>

<xs：complexContent>

<xs：extension base＝″RelationshipMember″>

<xs：attribute name＝″ClientMember″type＝″Path″use＝″required″/>

<xs：attribute name＝″ServerMember″type＝″Path″use＝″required″/>

</xs：extension>

</xs：complexContent>

</xs：complexType>

属性/元素   描述客户机成员  识别这样的终端成员，该终端成员具有与关系的客户定义不矛盾的一定义。终点成员可以是该定义的即时系统成员的一成员。服务器成员  识别这样的终端成员，该终端成员具有与该关系的服务器定义不矛盾的一定义。终端成员可以是该定义的即时系统成员的一成员。

3.7.4.3.3  包含成员

包含成员用来声明该类型包含类型成员。每个类型成员可以被包含或者被授权。包含成员自动的设置其即就是关系指针的包含关系的父母值。

<xs：complexType name＝″ContainmentMember″>

<xs：complexContent>

<xs：extension base＝″RelationshipMember″>

<xs：attribute name＝″ChildMember″type＝″Path″use＝″required″/>

</xs：extension>

</xs：complexContent>

</xs：complexType>

属性/元素    描述子成员       识别父母所包含的即时对象成员。

3.7.4.3.4  授权成员

授权成员用来建立外部类型的终端定义成员与外部类型的即时系统成员的终端定义成员之间的授权关系。

<xs：complexType name＝″DelegationMember″>

<xs：complexContent>

<xs：extension base＝″RelationshipMember″>

<xs：attribute name＝″ProxyMember″type＝″Path″use＝″required″/>

<xs：attribute name＝″DelegateMember″type＝″Path″use＝″required″/>

</xs：extension>

</xs：complexContent>

</xs：complexType>

属性/元素   描述代理成员    代理识别其不具有与该系统的包含关系的系统上的即时终端成员。该成员的定义与授权关系上的代理的定义相匹配。授权成员    授权识别该类型即时成员上的终端成员。该类终端成员与该授权关系上的授权类型相匹配。

3.7.4.3.5  引用成员

引用成员用来建立外部系统的两个即时成员或者成组成员之间的引用关系。

<xs：complexType name＝″ReferenceMember″>

<xs：compIexContent>

<xs：extension base＝″RelationshipMember″>

<xs：attribute name＝″DependentMember″type＝″Path″use＝″required″/>

<xs：attribute name＝″SourceMember″type＝″Path″use＝″required″/>

</xs：extension>

</xs：complexContent>

</xs：complexType>

属性/元素  描述相关成员   视源成员而定的对象成员。与引用关系中的相关对象的定义相匹配。源成员     源对象成员。与引用关系中的源对象的定义相匹配。

3.7.4.4  终端定义

终端定义通过进一步可声明成组资源类型、资源成员及主机、包含且引用关系成员。

<xs：complexType name＝″EndpointDefinition″>

<xs：complexContent>

<xs：extension base＝″ConcreteObjectDefinition″>

<xs：choice minOccurs＝″0″maxOccurs＝″unbounded″>

<xs：element name＝″ResourceDefinition″type＝″ResourceDefinition″/>

<xs：element name＝″Resource″type＝″ResourceMember″/>

<xs：element name＝″Hosting″type＝″HostingMember″/>

<xs：element name＝″Containment″type＝″ContainmentMember″/>

<xs：element name＝″Reference″type＝″ReferenceMember″/>

</xs：choice>

</xs：extension>

</xs：complexContent>

</xs：com plexType>

属性/元素      描述

资源定义    外部类型定义范围之内的类型成员所使用的成组资源定义。资源        引用源类型的资源成员说明。宿主        宿主关系成员说明。包含        包含关系成员说明。引用        引用关系成员说明。

3.7.4.5  服务定义

系统类型通过添加对成组终端、系统以及资源类型的支持；终端、系统、源成员以及主机、包含、连接、授权及引用关系来扩展基本类型。

<xs：complexType name＝″ServiceDefinition″>

<xs：complexContent>

<xs：extension base＝″ConcreteObjectDefinition″>

<xs：choice minOccurs＝″0″maxOccurs＝″unbounded″>

<xs：element name＝″EndpointDefinition″type＝″EndpointDefinition″/>

<xs：element name＝″ServiceDefinition″type＝″ServiceDefinition″/>

<xs：element name＝″ResourceDefinition″type＝″ResourceDefinition″/>

<xs：element name＝″Endpoint″type＝″EndpointMember″/>

<xs：element name＝″Subsystem″type＝″SubSystem″/>

<xs：element name＝″Resource″type＝″ResourceMember″/>

<xs：element name＝″Hosting″type＝″HostingMember″/>

<xs：element name＝″Containment″type＝″ContainmentMember″/>

<xs：element name＝″Connection″type＝″CommunicationMember″/>

<xs：element name＝″Delegation″type＝″DelegationMember″/>

<xs：element name＝″Reference″type＝″ReferenceMember″/>

</xs：choice>

</xs：extension>

</xs：complexContent>

</xs：complexType>

属性/元素     描述终端定义      位于外部服务定义的范围内，成员所使用的成组终端定义。资源定义      位于外部类型定义范围之内，类型成员所使用的成组终端定义

。系统定义    位于外部系统定义范围之内，成员所使用的成组系统定义。终端        引用终端定义的终端成员说明子系统      引用系统定义的子系统成员说明资源        引用资源定义的源成员说明包含        包含关系成员说明宿主        宿主关系成员说明连接        连接关系成员说明授权        授权关系成员说明引用        引用关系成员说明

3.7.4.6  资源定义

资源类型包括成组资源类型定义、资源成员、以及宿主、包含及引用关系成员。

<xs：complexTypename＝″ResourceDefinition″>

<xs：complexContent>

<xs：extension base＝″ConcreteObjectDefinition″>

<xs：choice minOccurs＝″0″maxOccurs＝″unbounded″>

<xs：element name＝″ResourceDefinition″type＝″ResourceDefinition″/>

<xs：element name＝″Resource″type＝″ResourceMember″/>

<xs：element name＝″Hosting″type＝″HostingMember″/>

<xs：element name＝″Containment″type＝″ContainmentMember″/>

<xs：element name＝″Reference″type＝″ReferenceMember″/>

</xs：choice>

</xs：extension>

</xs：complexContent>

</xs：complexType>

属性/元素   描述资源定义    位于外部资源定义范围之内的成员所使用的成组资源定义资源        引用资源定义的资源成员说明

宿主    宿主关系成员说明包含    包含关系成员说明引用    引用关系成员说明

3.7.4.7  关系规则

对于对象定义的特定实例而言，下表识别与该实例所扮演(play)的每一个角色相关联的基数。

3.7.4.7.1  系统规则

定义  角色            系统         终端            资源系统  Parent(0...*)   Contains     Contains        ContainsMember(1...1)   ContainedBy  Not Allowed     Not AllowedProxy(0...*)    Not Allowed  Not Allowed     Not AllowedDelegate(0...*) Not Allowed  Not Allowed     Not AllowedClient(0...*)   Not Allowed  Not Allowed     Not AllowedServer(0..*)    Not Allowed  Not llowed      Not AllowedGuest(1..1)     HostedBy     HostedBy(??)    HostedByHost(0..*)      Hosts        Hosts HostsSource(0..*)    Provides     Not Allowed     Not AllowedDependent(0..*) Consumes     Not Allowed     Not Allowed

3.7.4.7.2  终端规则

角色             系统          终端           资源终端  Parent(0*)       Not Allowed   Not Allowed    ContainsMember(1...1)    Contained By  Not Allowed    Not AllowedProxy(0...*)     Not Allowed   DelegatesTo    Not AllowedDelegate(0...*)  Not Allowed   Implements     Not AllowedClient(0...*)    Not Allowed   ConnectsTo     Not Alllowed

Server(0..*)     Not Allowed  ProvidesSerice Not AllowedGuest(1..1)      HostedBy     HostedBy       HostedByHost(0..*)       Hosts        Hosts          HostsSource(0..*)     Not Allowed  Provides       ProvidesDependent(0..*)  Not Allowed  Consumes       Consumes

3.7.4.7.3  资源规则

角色             系统           终端           资源资源  Parent(0...*)    Not Allowed    Not Allowed    ContainsMember(1...1)    ContainedBy    ContainedBy    ContainedByProxy(0...*)     Not Allowed    Not Allowed    Not AllowedDelegate(0...*)  Not Allowed    Not Allowed    Not AllowedClient(0...*)    Not Allowed    Not Allowed    Not AllowedServer(0..*)     Not Allowed    Not Allowed    Not AllowedGuest(1..1)      HostedBy       HostedBy       HostedByHost(0..*)       Hosts          Hosts          HostsSource(0..*)     Not Allowed    Provides       ProvidesDependent(0..*)  Not Allowed    Consumes       Consumes

3.7.4.7.4  附注

每个实例将准确的参与一个包含关系及至少一个宿主关系。

这是指：

A)非引用成员将识别包含关系

B)以便被构造，引用成员将识别包含关系

C)其不具有包含关系的引用成员只得授权给其他成员。

3.8  关系

关系用来识别类型之间的可能交互作用。它们是二元的且定向的，每一个识别参与关系的实例的类型。关系还可以限制对其参与关系的实例的设置并且使设定值流过该关系。

下列是类型部分中所描述的网络服务器上的webApplication的可能宿主关系。该关系包括用于核实两个系统的安全模型是兼容的一约束条件并且该关系包含其将服务器名从vsite拷贝到vdir的一设置信息流成员。

<AbstractHostingDefinition name＝″vsiteHostsVdir″guestType＝″vdir″hostType＝″vsite″>

<ObjectConstraint name＝″checkCompatibility″primaryRole＝″guest″primaryType＝″vdir″>

<Constraintname＝″constrainSecityModel″type＝″SimpleOperatorComparison″>

<input name＝″LHS″path＝″host.securityModel″/>

<settingValue name＝″operator″>＝＝</settingValue>

<input name＝″RHS″path＝″guest.securityModel″/>

</Constraint>

</ObjectConstraint>

<flow type＝″copy″name＝″co)pyServerToVdir″>

<input name＝″source″path＝″host.server″/>

<output name＝″destination″path＝″guest.server″/>

</flow>-

</AbstractHostingDefinition>

通过声明识别将加入关系的类型成员的一个关系成员，应用一个关系。

<SystemDefinition name＝″testSystem″implements＝″ApplicationSpace″>

<resource name＝″myVdir″type＝″vdir″isReference＝″false″/>

<resource name＝″myVsite″type＝″vsite″isReference＝″false″/>

<hosting relationship＝″vsiteHostsVdir″guestMember＝″myVdir″hostMember＝″myVsite″/>

</SystemDefinition>

3.8.1  关系定义

基本关系定义添加了对象约束条件和流向定义。对象约束条件是与其参与该关系的实例的目标实例的设置值有关的语句。例如，其表示DCOM连接的通信关系可检查客户机和服务器的安全设置是兼容的。在这种情况下，其可很容易被捕获的设置之间存在严格的关系以作为设计处理的一部分；该关系存在四个因子设置组合，但是远远小于有效组合的数目。

信息流给出了关系开发者的能力以将值从一个实例传送到另一个实例。这可使对象定义独立于其可能的交互作用而发展并且可使实例独立以作为信息的参考点而不是需要关系曲线图的子集以便完全的描述特定实例。

关系名应该在其包括该关系的域名空间内唯一。

<xs：complexType name＝″RelationshipDefinition″>

<xs：complexContent>

<xs：extension base＝″Definition″>

<xs：choice minOccurs＝″0″maxOccurs＝″unbounded″>

<xs：element name＝″ObjectConstraintGroup″type＝″ObjectConstraintGroup″/>

<xs：element name＝″ObjectConstraint″type＝″ObjectConstraint″/>

<xs：element name＝″Flow″type＝″FlowMember″/>

</xs：choice>

</xs：extension>

</xs：complexContent>

</xs：complexType>

属性/元素     描述对象约束条件  参与该关系的实例的约束条件，参见章节3.5.3(组)信息流        参与该关系的实例之间的信息流

3.8.2  抽象关系

抽象关系是两个抽象对象定义之间所定义的关系。它们表示两个定义之间的可能交互作用。

<xs：complexType name＝″AbstractRelationshipDefinition″>

<xs：complexContent>

<xs：extension base＝″RelationshipDefinition″>

<xs：attribute name＝″extends″type＝″QualifiedName″use＝″optional″/>

</xs：extension>

</xs：complexContent>

</xs：complexType>

3.8.2.1  抽象通信关系

通信关系用来捕获终端定义之间的可能通信链路。它们用来描述所独立配置的软件元件之间的交互作用。通信关系略图通过添加客户机和服务器终端引用来扩展基本关系略图。

<xs：complexType name＝″AbstractCommunicationDefinition″>

<xs：complexContent>

<xs：extension base＝″AbstractRelationshipDefinition″>

<xs：attribute name＝″ClientDefinition″type＝″QualifiedName″use＝″required″>

<xs：attribute name＝″ServerDefinition″type＝″QualifiedName″use＝″required″/>

</xs：extension>

</xs：complexContent>

</xs：com plexType>

属性/元素   描述客户机定义  通信关系中所涉及的客户实例的定义服务器定义  该关系中所涉及的服务器实例的类型

下列成对的抽象类型的组合对于通信关系而言是有效的：

客户机类型    服务器类型终端          终端

3.8.2.2  抽象宿主关系

宿主关系用来捕获客人需要寄主这样的事实以便被构造。因为一客人有多个可能宿主，因此这意味着宿主关系还对宿主的客人的结构负责。因此为了创建一对象的实例，宿主关系从客人而存在于兼容的宿主。

例如，宿主关系可存在于Webservice(网络服务)对象定义与IIS对象定义之间。在这种情况下，该关系表明假定MyWebservice和MyIIS分别实现了webservice和IIS，可利用宿主关系上的管理器来创建系统MyIIS的实例上的系统MyWebservice的实例。我们不知道在我们对存在于系统和关系中的约束条件进行评估之前是否可创建该关系。

<xs：complexTypename＝″AbstractHostingDefinition″>

<xs：complexContent>

<xs：extension base＝″AbstractRelationshipDefinition″>

<xs：attribute name＝″GuestDefinition″type＝″QualifiedName″use＝″required″/>

<xs：attribute name＝″HostDefinition″type＝″QualifiedName″use＝″required″/>

</xs：extension>

</xs：complexContent>

</xs：complexType>

属性/元素     描述客人定义      识别客人实例的定义宿主定义      识别宿主实例的定义

下列成对抽象定义的组合对于宿主关系而言是有效的：

客人类型    宿主类型终端        终端资源        资源资源        系统系统        资源系统        系统

3.8.2.3  抽象包含关系

两个抽象对象之间的包含关系捕获这样的事实，即基于parentType的具体类型可包含基于memberType的成员。包含意味着父母实例可对成员实例的使用期限进行控制并且可将特性授权给成员实例。

<xs：complexType name＝″AbstractContainmentDefinition″>

<xs：complexContent>

<xs：extension base＝″AbstractRelationshipDefinition″>

<xs：attribute name＝″ParentDefinition″type＝″QualifiedName″use＝″required″/>

<xs：attribute name＝″MemberDefinition″type＝″QualifiedName″use＝″required″/>

</xs：extension>

</xs：complexContent>

</xs：complexType>

属性/元素     描述父母定义      识别其包含成员的实例的定义成员定义      识别其即就是所包含成员的实例的定义

下列成对抽象定义的组合对于包含关系而言是有效的：

父母类型    成员类型系统        终端系统        资源系统        系统终端        资源资源        资源

3.8.2.4  抽象授权关系

授权用来将特性从外部系统转送到所包含系统。我们执行此的方法是将外部系统上的终端授权给内部系统上的终端。这有效的将其已导向外部系统的所有交互作用转送到内部系统中的终端上。授权被链接，这使得内部系统进一步将其行为授权给另一个系统。

授权关系定义了其参与该授权的一对抽象终端定义。每一个关系识别其作为一代理的抽象终端定义以及其对行为进行授权的抽象终端定义。

<xs：co>>mplexType name＝″AbstractDelegationDefinition″>

<xs：complexContent>

<xs：extension base＝″AbstractRelationshipDefinition″>

<xs：attribute name＝″ProxyDefinition″type＝″QualifiedName″use＝″required″/>

<xs：attribute name＝″DelegateDefinition″type＝″QuaifiedName″use＝″required″/>

</xs：extension>

</xs：complexContent>

</xs：complex Type>

属性/元素     描述代理定义      识别其用于将其行为授权给内部终端的外部终端的定义授权定义      识别其提供所需行为的内部终端的定义

下列成对抽象定义的组合对于授权关系而言是有效的：

代理类型    授权类型终端        终端

我们允许将资源和系统授权以支持层之间的绑定。例如，在无需部署IIS而使得IIS暴露出部分文件系统。

3.8.2.5  抽象引用关系

除了宿主关系相关性之外，我们使用引用关系以捕获实例之间的强相关性。这些相关性用来在部署期间控制构造系列并且在安装期间使系统之间的参数流动并且对其进行更新。因为引用关系表明强相关性，因此我们不允许引用关系越过系统边界。这是指一个系统内的资源不具有与另一个系统中的资源的相关性。这使得系统不再是部署的独立单位。在相关性存在于系统之中的地方，我们使用通信关系。通信关系可无需重新安装系统即可随时间而改变。

<xs：complexType name＝″AbstractReferenceDefinition″>

<xs：complexContent>

<xs：extension base＝″AbstractRelationshipDefinition″>

<xs：attribute name＝″DependentDefinition″type＝″QualifiedName″use＝″required″/>

<xs：attribute name＝″SourceDefinition″type＝″QalifiedName″use＝″required″/>

</xs：extension>

</xs：complexContent>

</xs：complexType>

属性/元素    描述相关定义     其视源实例而定的实例的定义源定义       源实例的定义。不要求该实例知道相关性。

下列成对抽象定义的组合对于应用关系而言是有效的：

相关类型  源类型系统      系统资源      资源

3.8.3  隐含的基本关系

所有抽象关系隐含的扩展如图14所示的基本关系之一定义。这些定义形成了每一关系树的根。通过这样做，我们可以参考约束条件定义之内的根定义并且我们可继承根类型的普通型约束条件。

3.8.4  具体关系

具体关系是两个具体对象定义之间的关系。每一个具体关系将实现一抽象关系。该抽象关系是具体对象定义所直接或者间接(通过继承)实现的一对匹配的抽象对象定义之间的关系。

<xs：complexType name＝″ConcreteRelationship″>

<xs：complexContent>

<xs：extension base＝″RelationshipDefinition″>

<xs：attribute name＝″lmplements″type＝″QualifiedName″/>

</xs：extension>

</xs：complexContent>

</xs：complexType>

3.8.4.1  宿主关系

当我们将一应用部署给资料处理中心时，我们必须对该应用内的系统的所有突出寄主关系进行解析。为此操作员必须为每个所需宿主关系创建宿主成员。为了简化操作员的任务并且允许开发者对配置处理导向，开发者改为创建具体宿主关系。具体宿主关系用来以这样一种方法来使一组寄主关系成员成组，该方法就是当部署该应用程序时操作员只需要声明单个宿主成员。

<xs：complexType name＝″HostingDefinition″>

<xs：complexContent>

<xs：extension base＝″ConcreteRelationship″>

<xs：sequence>

<xs：element name＝″Hosting″type＝″HostingMember″minOccurs＝″0″maxOccurs＝″unbounded″/>

</xs：sequence>

<xs：attribute name＝″GuestDefinition″type＝″QualifiedName″use＝″required″/>

<xs：attribute name＝″HostDefinition″type＝″QualifiedName″use＝″required″/>

</xs：extension>

</xs：complexContent>

</xs：complexType>

属性/元素 描述宿主定义  宿主关系所应用的客人具体对象定义的名称客人定义  宿主关系所应用的宿主具体对象定义的名称宿主      其引用以客人为根的成员的一列宿主关系成员以及具体关系的宿主定义。

下列成对抽象定义的组合对于宿主关系而言是有效的：

客人类型  宿主类型系统      系统

A guest can be bound to ahost iff

For each guestMember in Guest

There exists one or more hostMember in Host where

guestMember.Type has a hosting relation with hostMember.type

and guestMember.hostConstraints validate against hostMember.settings

and hostMember.guestConstraints validate against guestMember.settings

and for each member of guestMember there exists a binding to a member of hostMember

例如下列具体关系将三个系统(BIKE)的一个层绑定到两个宿主的一个层(操作系统)。在这种情况下，我们将宿主关系的设置定义为″系统文件夹″的缺省值。我们使该设置流动到三个宿主成员之一，所述三个宿主成员之一，定义层3应用程序的系统与层2宿主的系统之间的宿主关系。

<HostingDefinition name＝″DefaultBikePlacement″guestDefinition＝″Bike″

hostDefinition＝″OperatingSystem：OperatingSystem″>

<settingDeclaration name＝″fileLocationRelativeToRoot″definition＝″xs：sting″

access＝″readwrite″dynamic＝″false″/>

<settingValuename＝″dirPath″>systemFolder<settingValue>

<flow name＝″copyPath″definition＝″copy″>

<input name＝″source″path＝″dirPath″/>

<output name＝″destination″path＝″bike ExecutableHost.hostRelativePath″/>

</flow>

<hosting name＝″bikeExecutableHost″relationship＝″fileDirectoryHost

guestMember＝″guest.bikeFile″hostMember＝″host.FileSystem″/>

<hosting name＝″bikeEventKeyHost″relationship＝″registryKeyRegistryKeyHost″

guestMember＝″guest.bikeEventKey″hostMember＝″host.Registry.ApplicationEventKey″/>

<hosting name＝″bikeSofiwareKeyHost″relationship＝″registryKeyRegistryKeyHost″

guestMember＝″guest.bikeSoftwareKey″hostMember＝″host.Registry.HKLM″/>

</HostingDefinition>

3.8.4.2  引用关系

我们可以使用两个具体类型之间的具体引用关系以捕获其不涉及通信关系的系统之间的特定相关性。例如，我们可捕获这样的事实，即对于所要安装的一个应用程序而言已存在另一个应用程序。

<xs：complexType name＝″ReferenceDefinition″>

<xs：complexContent>

<xs：extension base＝″ConcreteRelationship″>

<xs：sequence>

<xs：element name＝″Reference″type＝″HostingMember″minOccurs＝″0″maxOccurs＝″unbounded″/>

</xs：sequence>

<xs：attribute name＝″DependentDefinition″type＝″QualifiedName″use＝″required″/>

<xs：attribute name＝″SourceDefinition″type＝″QualifiedName″use＝″required″/>

</xs：extension>

</xs：complexContent>

</xs：complexType>

属性/元素   描述相关定义    该引用关系所应用的相关具体对象定义的名称源定义      该引用关系所应用的源具体对象定义的名称

引用      其引用客人的成员以及宿主定义的引用关系成员

下列成对抽象定义的组合对于引用关系而言是有效的：

相关类型  源类型系统      系统资源      资源资源      终端终端      资源

3.9  对象和关系约束条件

我们使用对象和关系约束条件以定义具体空间的拓扑结构并且当其用于特定关系时限制对象的设置。

例如在抽象对象定义(A)内我们可以想到识别出该抽象定义的实现将包含另一个抽象对象定义的一个实例(B)。假定已经存在至少一个适当的包含关系，为此我们将使用如下的所注意的A之内的关系约束条件：

<RelationshipConstraint name＝″AContainsB″

relationship＝″ContainmentDefinition″

myRole＝″parent″

targetType＝″B″

minOccurs＝″1″

maxOccurs＝″1″/>

该约束条件 识别是否存在的一个包含关系，其中，A的实现扮演了父母的角色，且在关系的另一端的类型(成员)，属于类型B。如果我们更想要控制B的配置，我们能够以如下方式将一个约束条件添加至类型B的设置上：

<RelationshipConstraint name＝″AContainsB″

relationship＝″ContainmentDefinition″

myRole＝″parent″

targetType＝″B″

minOccurs＝″1″

maxOccurs＝″1″/>

<Constraintdefinition＝″simpleValueConstraint″

name＝″BValueConstraint″>

<input name＝″LHS″path＝″member.name″/>

<settingValue name＝″operator″>＝</settingValue>

<settingValue name＝″RHS″>myPort</settingValue>

</Constraint>

</RelationshipConstraint>

在这种情况下，我们将其需要成员名称的约束条件添加到相等的串“myPort”上。

我们还可以将约束条件添加到关系上：我们调用这些对象约束条件。从一关系中我们限制其参与该关系的对象。对于该关系中的每个角色而言，我们可以识别对象定义并且此后我们可以将设置约束条件添加到那些对象定义上。从该关系角度来看基数总是minOccurs＝1并且maxOccurs＝1，因此这不会出现在约束条件说明中。

<ObjectConstraint name＝″allowedPair″

primaryRole＝″host″

primaryType＝″IIS″

secondaryRole＝″guest″

secondaryType＝″webApp″/>

最后，我们可以使约束条件成组。这使我们能够将约束条件链接在一起；外部约束条件设置内部约束条件的前后关系。下列是其宿主webapp系统的IIS系统的一例子，该webapp系统此后只限制特定类型的webApp containendpoints。

在这种情况下，我们使用一组对象约束条件以指定其至少一个为真的一组可能性。

<AbstractSystemDefinition name＝″IIShost″>

<RelafonshipConstraint name＝″WebAppHostConstraint″

relationship＝″hostingRelafonship″myRole＝″host″targetType＝″webApp″>

<RelatbnshipConstraint name＝″WebAppContainsPort″

relationship＝″containmentRelatbnship″myRole＝″parent″targetType＝″portType″>

<ObjectConstraintGroup mode＝″oneTrue″>

<ObjectConstraint name＝″hasWebPort″primaryRole＝″member″primaryType＝″webPort7>

<ObjectConstraint name＝″hasSqlPort″primaryRole＝″member″primaryType＝″sqlPort″/>

</ObjectConstraintGroup>

</RelationshipConstraint>

</RelatbnshipConstraint>

</AbstractSystemDefinition>

成组的约束条件形成了我们可以从外部来对其进行评估的一路径。该路径上的每个约束条件存取该路径上的先前实例以及当前实例的设置。若约束条件被定义在所识别的系统之内，则引导对成组约束条件的评估。

从foo的角度来看下列两个方案是等效的。在第一个中foo将成组约束条件配置在所包含的系统棒(bar)中，在第二个中类型棒已包含约束条件。

方案1：

<AbstractSystemDefinition name＝″foo″>

<RelationshipConstraint name＝″containsBar″relationship＝″containment″

myRole＝″parenr targetType＝″bar″minOccurs＝″1″>

<RelationshipConstraint name＝″containsX″relationship＝″containment″

myRole＝″parent″targetType＝″X″minOccurs＝″1″/>

</RelationshipConstraint>

</AbstractSystemDefinition>

<AbstractSystemDefinition name＝″bar″/>

方案2：

<AbstractSystemDefinition name＝″foo″>

<RelationshipConstraint name＝″containsBar″relattonship＝″containment″

myRole＝″parent″targetType＝″bar″minOccurs＝″1″/>

</AbstractSystemDefinition>

<AbstractSystemDefinition name＝″bar″>

<RelationshipConstraint name＝″containsX″relationship＝″containment″

myRole＝″parent″targetType＝″X″minOccurs＝″1″/>

</AbstractSystemDefinition>

3.9.1  约束条件模型

存在两部分约束条件模型：防护(guards)及谓词(predicates)。我们使用防护以定义我们执行谓词的前后关系。例如在一关系内，我们使用防护以识别我们想执行的其谓词的类型的特定组合。在一对象内，我们使用防护以识别与其他对象的一组关系。

此后当已经满足其防护的要求时执行谓词。我们具有两种形式的谓词：用于使设定值有效的设置约束条件以及用于使一组约束条件有效的组约束条件。

我们可以使防护之内的防护成组，在这种情况下，当满足外部防护时只检查内部防护。这使我们修建其支持关系结构核对的路径。

防护与其谓词的组合具有这样的基数，该基数表明防护匹配并且谓语评估为真的次数。更正式的，

Guard：＝ObjectConstraint(ObjectDefintion，ObjectDefintion，required){(Guard|predicate)*}|

Rel ati onshi pconsnint(RelationshipDefinition，

Targetobject，1 Bound，uBound){(Guard|predicate)*}

将防护定义为ObjectConstraint或者RelationshipConstraint。对象约束条件识别其与关系的任一端相关的两个对象定义。关系约束条件识别关系定义及对象对象定义。对象约束条件是可选择的或者当关系约束条件具有下限和上限时其是必需的。基数中的差值反映出这样的事实，即当类型参与多关系时一关系只识别两个类型。

Predicate：＝SettingsConstraint(rule)|group{(guard)*}

谓词或者是其包含一规则的设置约束条件或者是其包含一组防护的组。在防护的前后关系中对该谓词进行评估。在设置约束条件的情况下，该谓词可从根防护的所有者以及每一个成组防护所识别的前后关系中识别出设置。组用来识别其至少一个将匹配并且评估为真的一组防护。

例子：

1.RelationshipConstraint(containmentRelationship，webapp，0，1){}

这个例子给出了这样的一防护，该防护评估为真，只要存在相对于webapp的包含关系。该防护最多一次评估为真。进一步匹配将导致返回一错误给用户。

2.RelafionshipConstraint(ContainmentRelationship，webapp，0，1)SettingsConstrai nt(webapp.name＝2)

这个例子将一谓词添加到防护上。当关系与目标定义相匹配并且设置约束条件评估为真时防护只评估为真。如果关系与与目标定义相匹配并且设置约束条件不是真，那么此后向用户返回一错误。如果关系与目标定义相匹配并且设置约束条件不止一次评估为真，那么向用户返回一错误。

3.RelationshipConstraint(containmentRelationship，webapp，0，1)

{

Relationshipconstraint(containmentRelationship，vdir，0，1)

}

在这个例子中，我们使防护之内的一防护成组。当外部防护是真(其包含约束条件的类型还包含webapp)时，此后我们在外部防护的前后关系中对内部防护进行评估。这意味着在webapp实例的前后关系中对内部关系约束条件进行评估。如果webApp包含零或者一个vdirs，那么内部约束条件将返回真。如果它包含不止一个vdir，那么此后约束条件向用户返回一错误。

4.ObjectConstraint(webapp，ii s，0，1)

{

RelationshipConstraint(containmentRelationship，systemType，0，1)

{

TypeConstraint(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.9.2  基本约束条件

<xs：complexType name＝″Constraint″>

<xs：sequence>

<xs：element name＝″Description″type＝″Description″minOccurs＝″0″/>

<xs：element name＝″DesignData″type＝″DesignData″minOccurs＝″0″/>

</xs：sequence>

<xs：attribute name＝″name″type＝″SimpleName″/>

</xs：complexType>

属性/元素     描述名称          该约束条件章节设计的名称设计数据      与该约束条件有关的设计表面特定信息

3.9.3  对象约束条件

对象约束条件描述了对一个或者两个关系角色的约束条件。在它失败的情况下，该约束条件具有一名称以有助于对该约束条件的标识。它包含其目标为与角色有关的类型的一列设置约束条件，并且它可以进一步对从与该角色相关的定义中所得来的一对象的实例进行限制。

<xs：complexTypename＝″ObjectConstraint″>

<xs：complexContent>

<xs：extension base＝″Constraint″>

<xs：choice minOccurs＝″0″maxOccurs＝″unbounded′>

<xs：elementname＝″SettingsConstraint″type＝″ConstraintMember″/>

<xs：elementname＝″RelationshipConstraint″type＝″RelationshipConstraint″/>

<xs：elementname＝″RelationshipConstraintGroup″type＝″RelationshipConstraintGroup″/>

</xs：choice>

<xs：attribute name＝″PrimaryRole″type＝″RolesList″use＝″required″/>

<xs：attribute name＝″PrimaryObject″type＝″QualifiedName″use＝″required″/>

<xs：attribute name＝″SecondaryRole″type＝″RolesList″use＝″optional″/>

<xs：attribute name＝″SecondaryObject″type＝″QualifiedName″use＝″optional″/>

<xs：attribute name＝″Required″type＝″xs：boolean″use＝″optional″/>

</xs：extension>

</xs：complexContent>

</xs：complexType>

属性/元素       描述设置约束条件    相对应用于约束条件的内容上的一列设置约束条件关系约束条件    成组关系约束条件。如果该关系已经声明了与最初角色相关的类型，那么对该关系进行评估。关系约束条件组  如果已经声明了与最初角色相关的类型，那么对该组中的成组关系组-关系进行评估。先前约束条件众所周知的以设置根命名。最初角色        其是约束条件目标的关系中的一角色的名称最初对象        与最初角色相关的对象定义的名称次级角色        其是约束条件目标的关系中的另一角色的名称次级对象        与关系中的次级角色相关的对象定义的名称。如果指定了次级角色那么其是必需的。所需            如果所需为真，那么此后该约束条件与定义相匹配。它声明赞成该关系上的角色。如果所需为假，此后防护不必与所使用的类型相匹配。所需用来强制一关系以使用特定组合类型。

3.9.4  对象约束条件组

对象约束条件组可使对象组集中在一起以便利用最小一个语义来对其进行评估。该组将返回一错误，除非至少一个对象约束条件与该关系的对象相匹配并且此后其所包含的谓词评估为真。如果约束条件是该组的直接构件，那么我们可以忽略类型约束条件的所需属性。

<xs：complexTypename＝″ObjectConstraintGroup″>

<xs：complexContent>

<xs：extension base＝″Constraint″>

<xs：sequence>

<xs：elemenl name＝″ObjectConstraint″type＝″ObjectConstraint″maxOccurs＝″unbounded″/>

</xs：sequence>

</xs：extension>

</xs：complexContent>

</xs：complexType>

属性/元素         描述对象约束条件      在组中定义的约束条件的类型的列表

3.9.5  关系约束条件

关系约束条件用来限制对象所参与的关系。关系约束条件识别关系定义、可选的位于关系另一端的实例的对象定义以及关系的基数。给定约束条件一名称以便它可在错误消息中被识别。关系约束条件的本体包含与两个关系有关的谓词以及位于关系另一端的实例。

关系约束条件用于多个目的：在没有附加谓词的情况下仅利用基数，它们可用于识别为一实例所提供的关系以正确的进行操作，具有谓词的它们用于诸如对象愿与其进行相互作用的有限组的结构。

<xs：complexType name＝″RelationshipConstraint″>

<xs：complexContent>

<xs：extension base＝″Constraint″>

<xs：choice minOccurs＝″0″maxOccurs＝″unbounded″>

<xs：element name＝″SettingsConstraint″type＝″ConstraintMember″/>

<xs：elementname＝″RelationshipConstraint″type＝″RelationshipConstraint″/>

<xs：element name＝″RelationshipConstraintGroup″type＝″RelationshipConstraintGroup″/>

<xs：element name＝″ObjectConstraint″type＝″ObjectConstraint″/>

<xs：element name＝″ObjectConstraintGroup″type＝″ObjectConstraintGroup″/>

</xs：choice>

<xs：attribute name＝″Relationship″type＝″QualifiedName″use＝″required″/>

<xs：attribute.name＝″MyRole″type＝″RolesList″use＝″required″/>

<xs：attribute name＝″TargetObject″type＝″QualifiedName″use＝″optional″/>

<xs：attribute name＝″MinOccurs″type＝″MinOccurs″use＝″optiona！″/>

<xs：attribute name＝″MaxOccurs″type＝″MaxOccurs″use＝″optional″/>

</xs：extension>

</xs：complexContent>

</xs：com plexType>

属性/元素       描述设置约束条件    关系之内的设置值的约束条件或者位于关系另一端的对象的约束条件关系约束条件    在目标对象的内容中所评估的关系约束条件(目标对象定义被指定)。这等效于将约束条件添加到目标对象上。关系约束条件组  在目标对象的内容中所评估的关系组(目标对象被指定)。这等效于将该组添加到目标对象上。对象约束条件    所评估的成组对象约束条件，虽然它是外部约束条件所识别的关系定义的一部分。对象约束条件组  所评估的成组对象约束条件，虽然它是外部约束条件所识别的关系定义的一部分。名称            位于包含定义范围之内的约束条件的唯一名称关系            受到限制的关系定义的名称我的角色        标实例在该关系中所扮演的角色的名称-这是与关系定义中的属性名称相对应的名称，例如客户机/服务器、顾客/宿主等等。如果这没有被提供，我们可以从该关系所涉及的类型中推断出角色。目标对象        在关系的对方侧所呈现出的对象的的定义的可选名称最大次数        其被识别为参与命名关系中的定义角色的对象的实例的最大次数。如果是零，此后该类型明确的禁止参与命名关系

。最小次数      其被识别为参与命名关系中的定义角色的对象的实例的最小次数。

3.9.6  关系约束条件组

关系约束条件组可使关系约束条件组集中在一起以便将其评估为具有至少一个语义的谓词。该组将返回一错误，除非至少一个包含关系约束条件与一关系定义相匹配并且目标对象和其包含谓词返回真。如果包含约束条件中的任一个谓词返回一错误，那么此后将这些错误传送到该用户。忽略包含关系约束条件的minOccurs基数，但是如果违反了maxOccurs基数，那么此后向用户返回一错误。

<xs：complexType name＝″RelationshipConstraintGroup″>

<xs：complexContent>

<xs：extension base＝″Constraint″>

<xs：sequence>

<xs：element name＝″RelationshipConstraint″type＝″RelationshipConstraint″maxOccurs＝″unbounded″/>

</xs：sequence>

</xs：extension>

</xs：complexContent>

</xs：complexType>

属性/元素     描述关系约束条件  在组内所定义的关系约束条件

3.10  对象管理器

对象管理器是这样的机件，即类型与关系通过该机件而将定制特性插入到运行时间环境中。对于其所管理的每个类型而言存在若干个管理器可支持的角色：它参与可类型的安装、它可提供类型的CLR表示、它可涉及与怎样解析类型之间的绑定有关的方针决策、并且它可提供复杂约束条件和信息流的实现。

所有对象管理器角色通过其作为实体点的CLR而暴露于强的命名类别中。按照与sdm中的其他类型相同的方法来包装包装并且解释对象管理器；它们被分配在系统分配单元中并且其版本和强的名称源自于声明它们的sdm文件。

<xs：complexType name＝″Manager″>

<xs：sequence>

<xs：element name＝″Descriptton″type＝″Description″minOccurs＝″0″/>

</xs：sequence>

<xs：attribute name＝″Name″type＝″SimpleName″use＝″required″/>

<xs：attribute name＝″AssemblyName″type＝″xs：string″use＝″required″/>

<xs：attribute name＝″Version″type＝″FourPartVersionType″use＝″optional″/>

<xs：attribute name＝″PublicKeyToken″type＝″PublicKeyTokenType″use＝″optional″/>

<xs：attribute name＝″Culture″type＝″xs：string″use＝″optional″/>

<xs：attribute name＝″Platform″type＝″xs：string″use＝″optional″/>

<xs：attribute name＝″SourcePath″type＝″xs：string″use＝″opt′ional″/></xs：com plexType>

属性/元素                     描述Name(名称)                    位于包含sdm文件的范围之中的管理器的唯一名称Description(描述)             管理器的文本描述AssemblyName(组件名称)        组件名称Version(版本)                 组件版本PublicKeyToken(公共密钥令牌)  组件的公共密钥令牌Culture(培养)                 组件的培养Platform(平台)                组件的平台SourcePath(源路径)            通向SDU之内的路径

3.10.1  角色

对象管理器可支持其所支持的每个类型的一个或多个角色。这些角色包含：

(a)评估类型或关系的约束条件

(b)评估类型或关系的信息流

(c)结构/分解/更新支持类型

(d)暴露类型或关系设置的对象表示

(e)执行类型或关系的发现

(f)围绕类型或关系，支持设计表面指定UI

3.11  SDM DOCUMENT STRUCTURE(SDM文档结构)

一个sdm文档，为关系，对象和管理器，提供强识别，版本和定位信息。

<xs：element name＝″Sdm″>

<xs：complexType>

<xs：sequence>

<xs：element name＝″lnformation″type＝″lnformation″minOccurs＝″0″/>

<xs：element name＝″lmport″type＝″lmport″minOccurs＝″0″maxOccurs＝″unbounded″/>

<xs：element name＝″DesignData″type＝″DesignData″minOccurs＝″0″/>

<xs：element name＝″SettingDefinitions″type＝″SettingOefinitions″minOccurs＝″0″/>

<xs：choice minOccurs＝″0″maxOccurs＝″unbounded″>

<xs：elementname＝′AbstractEndpointDefinition″type＝″AbstractEndpointDefinition″/>

<xs：elementname＝″AbstractSystemDefinition′type＝″AbstractSystemDefinition″/>

<xs：element name＝″AbstracrResourceDefinition″type＝″AbstractResourceDefinition″/>

<xs：elementname＝″AbstractCommunicationDefinition″type＝″AbstractCommunicationDefinition″/>

<xs：elementname＝″AbstractHostingDefinition″type＝″AbstractHostingDefinition″/>

<xs：elementname＝″AbstractContainmentDefinition″type＝″AbstractContainmentDefinition″/>

<xs：element name＝″AbstractDelegationDefinition″type＝″AbstractDelegationDefinition″/>

<xs：elementname＝″AbstractReferenceDefinition″type＝″AbstractReferenceDefinition″/>

<xs：element name＝″ReferenceDefinition″type＝″ReferenceDefinition″/>

<xs：element name＝″HostingDefinition″type＝″HostingDefinitbn″/>

<xs：element name＝″EndpointDefinition″type＝″EndpointDefinition″/>

<xs：element name＝″ResourceDeflnition″type＝″ResourceDefinition″/>

<xs：element name＝″ServiceDefinition″type＝″ServiceDefinition″/>

<xs：elementname＝″ConstraintDefinition″type＝′ConstraintDefinition″/>

<xs：element name＝″FlowDefinition″type＝″FlowOefinition″/>

<xs：element name＝″Manager″type＝″Manager′/>

</xs：choice>

</xs：sequence>

<xs：attributeGroup ref＝″Namespaceldentity″/>

<xs：attribute name＝″documentLanguage″type＝″Culture″/>.

</xs：complexType>

</xs：element>

3.11.1  信息

一个SDM文档的信息部分，包括支持SDM文档的识别和管理的人类可读信息

<xs：complexType name＝″lnformation″>

<xs：annotation>

<xs：documentation>Human readable information about the SDM Definitionlibrary.</xs：documentation>

</xs：annotation>

<xs：sequence>

<xs：element name＝″FriendIyName″type＝″xs：string″minOccurs＝″0″/>

<xs：element name＝″CompanyName″type＝″xs：string″minOccurs＝″0″/>

<xs：element name＝″Copyright″type＝″xs：string″minOccurs＝″0″/>

<xs：element name＝Trademark″type＝″xs：string″minOccurs＝″0″/>

<xs：element name＝″Description″type＝″Description″minOccurs＝″0″/>

<xs：element name＝″Comments″type＝″xs：string″minOccurs＝″0″/>

<xs：sequence>

<xs：com plexTy pe>

属性/元素         描述FriendlyName(友好名称)CompanyName(公司名称)Copyright(版权)Trademark(商标)Description(描述)Comments(注释)

3.12  变更请求

附图15描述了一个变更请求的范例。一个变更请求识别一组对于SDM运行时间的变更。利用变更请求，通过允许构造一个请求的API或者在一个xml格式中，启动对于运行时间的所有变更。

启动请求包含一个单独的活动组。作为通过运行时间处理的请求，通过分组添加更多的结构，且通过扩展及数据流处理，添加更多的活动。通过该评估处理，执行一个变更请求，且相对于目标机器，准备执行称作一个完全限定的变更请求。更多信息参见章节3.13。

3.12.1  一致性规则

当在SDM实例空间上执行活动时，我们确认在结束该活动之后，SDM实例空间中的所有实例仍然在一个一致状态中。借助于一致状态，我们了解所有适用于该实例的约束条件仍然有效。例如，如果我们创建一个需要连接至服务器的客户机的实例，当用于创建和连接到该客户机的活动序列结束时，该连接存在于客户机和服务器之间。

可以在每一个活动基础上或者在一组活动的结论上评估用于评估模型一致性的约束条件。我们将这两个类型的一致性称为操作一致性和处理一致性。

如果一个对象在结束处理之后，存在于一个不一致的情况中，则我们允许该用户将该实例明确标记为不可用的。当一个实例不可用时，我们无法评估适用于该实例的约束条件，且从其他实例的联系中，无法看出该实例的存在。这可能使所有那些实例也依次被标记为不可用的。不可用状态从父母传播到孩子，并从宿主传播到客人，所以将一个系统标记为不可用，将使其所拥有的实例全部标记为不可用，且所有寄生于其上的实例也不可用。

3.13  模型评估

在本节中，我们描述SDM模型在SDM运行时间范围内的动作。

3.13.1  定义空间

该定义空间包含所有SDM运行时间已知的定义。附图16的各步骤，定义了一个将新定义载入至运行时间的范例处理。设计表面确认一个SDM文件时，这个处理也可以通过所出现的编译处理共享。

3.13.1.1  载入

出现在运行时间前的一个SDM文档，作为一个sdu的一部分，或者作为一个独立的文档。我们试图将从载入该文件。

有效错误    描述未知文件    我们不能在指定位置找到该文件拒绝访问    拒绝我们访问该文件

3.13.1.2  模式确认

第一步，将确认与sdm设计相匹配的sdm文档。在这一点上，我们将返回对于所有未知元素的错误，缺少所需元素或属性的类型，或包含无效数据的类型。

错误确认      说明无效文档      该文档具有无效的xml语法-未闭合节点，多于一个顶层节点等等。未知元素      在该sdm文档中寻找一个意外元素未知属性      在该sdm文档中寻找一个未知属性无效值        一个模式确认失败的值(这不包括设置值确认)缺少属性      缺少的一个所需属性缺少元素      缺少的一个所需元素无效属性组合  使用过的，无效的一个属性或者元素的组合，诸如：

-minOccurs！＝maxOccurs|minOccurs＝0 with byValue

我们可以返回用于未知元素和属性的警告，且仅仅忽略他们。

3.13.1.3  设置值和类型解析

在类型解析阶段中，我们在adm文件内解决所有对类型的引用(无论在模式中的任何地方使用过的限定名称)。首先我们在有效文档范围内确认所有类型引用。这是不包含一个别名的所有类型引用。然后，我们则设法解析所有输入语句。如果我们不能解析一个输入语句，则我们创建一个命名空间载入错误，如果我们可以解析并输入语句，则我们设法在命名空间内定位该类型。如果我们被迫从一个sdm文件载入该命名空间，该命名空间解析过程可能产生其他错误。

类型解析错误    说明未知类型        无法在本地或者别名命名空间中找到的一个类型。这将出现在设置，系统，终端，资源，关系，约束条件和数据流中未知命名空间    无法找到的一个命名空间。该命名空间并未预先载入版本冲突        我们无法定位具有匹配版本信息的一个命名空间信息风格冲突        我们无法定位具有匹配的风格信息的一个命名空间。类型的无效使用  在这些情况，例如设置一个关系成员中的类型，中的无效类型的使用。无效设置值      一个没有传递它的类型确认的设置值非法设置值      提供一个设置值，对于一个设置声明或者一个类型或者基础类型中的一个预先声明的固定值，其违反一个访问修改程序。

3.13.1.4  路径解析

在路径期间解析阶段的过程中，我们设法决定通向成员和在该文档中定义的设置的所有路径。那些涉及成员或者具有未定类型的路径，不会产生一个错误。

路径分解错误  说明未知设置      无法找到与该路径相匹配的一个设置声明未知成员      无法找到与该路径中的一个名称相匹配的一个成员声明基数错配      一个通向数据流中的一个设置值的路径，且包括一个成员或关系的约束条件语句具有大于一的基数。类型错配      变量的所声明的类型和所决定设置或者成员的类型不匹配。使用错配      路径的所声明的目的，-输入/输出-违反设置声明上的一个访问修改程序，或者一个值上的一个固定的修改程序。没有值        引用一个设置的一个所需数据流输入路径，该设置没有缺省值且没有公开，以便允许一个用户提供一个值。

路径解析报警        说明运行时间路径报警   一个路径引用一个isReference成员，该isReference成员引用一个抽象类型，在运行时间以前，该类型可以不必核实(我们无法核对在用户创建具体类型以前存在的一个成员)。数据流报警         如果为一个设置提供一个值，该值也是同时或及早定义的数据流的目标，则我们将产生一个报警。只要该设置不固定，在提供所述设置值之后定义数据流，我们将不会产生一个报警。

3.13.1.5  关系参与

对于关系中的成员的参与，在该类型空间中，我们核对一个类型说明并未违反约束条件中的任意一种。为了实现这些，我们对所有类型与关系约束条件进行评估，所述约束条件没有与背景约束条件相关。

类型空间约束条件错误  说明违反关系类型          一个关系成员基于通过关系识别的类型，识别一个特定的关系和两个矛盾的成员。在一个vdir和一个文件

之间，宣布Eg a vdirToVsite是宿主关系违反关系使用      在两个成员之间声明一个关系，但是在这里，因为多个成员是不可访问的，所以关系的使用是不允许的。例如，声明两个终点之间的一个授权关系，所述两个终点不在直接的包容关系中的系统上。违反关系约束条件  关系约束条件违反  基于关系内的约束条件，在一个不支持的类型组合之间声明一个关系。例如在vsites之间声明一个关系，但是它只支持来源于vsite的某些类型。

类型空间约束条件报警  说明可能基数错配          当计算用于一个成员的maxOccurs时，产生一组将违反一个关系约束条件的基数。

3.13.1.6  实例模拟

在实例模拟中，我们试图流动值且通过我们可识别约束条件的方式，评价约束条件，我们认为基于用户输入，可能或可能不出现故障而不是标记约束条件。为了实现这些，基于实例空间，我们构造一个实例空间的模型。如果该数据流或约束条件，是已知将产生一个错误，则我们产生一个错误，如果它可能或者产生一个错误，则我们产生一个警告。

在所有参数引用(byReference)系统上，使用该minOccurs约束条件，我们建立一个范例空间变更请求。当该minoccurs为0时，我们创建一个单独的实例，且将其标记为可选。然后，我们通过相同的扩展和数据流处理，将该变更请求视为对于一个标准变更请求的使用。

模拟报警     说明可选系统     因为该系统是可选的，所以运行时间无法完全决定可能由配置产生的所有错误。

然后，我们评估所有具有完全定义输入值的数据流。如果该输入值不固定，且是可以通过用户进行变更的，那么我们将该数据流的输出标记为临时的。通过所使用的数据流操作的任何一种，约束一个临时输入。如果一个数据流不具有完整的输入值，且一个用户可以提供这些值，那么我们将数据流的所有输出标记为未定义的。来自可选系统的数据流，也产生临时值。

数据流错误          说明未定义数据流输入    没有提供一个值给一个所需数据流输入值。

一旦我们具有了流动的值，则我们基于这些值，评估该约束条件。将产生无效提供值的约束条件作为报警；当由于未定义值，而不能评估一个约束条件时，也将产生一个报警。

设置约束条件错误    说明未定义设置输入      没有提供一个值给一个所需约束条件输入值。设置违反约束条件    对于一个约束条件，在一个约束条件违反中产生一个或多个输入设置。

设置约束条件报警      说明设置可以违反约束条件  基于缺省值，一个输入设置的组合可以违反该约束条件。未评估设置约束条件    因为其取决于在部署或使用时间提供的设置，所以不能评估一个约束条件。

3.13.2  实例空间

该模型评估处理，是起源于一个公告性变更请求的提交。在运行时间内，把包含一组创建，更新或删除操作的这些要求作为目标。在运行时间内，把包含一组创建，更新或删除操作的这些要求作为目标。在如图17所示的目标系统上，在制定所需的改变之前，我们则通过一系列管线阶段传递该请求。

以下章节将标出每一扩展步骤的任务。

3.13.2.1  请求提交

为了对于该系统启动一个变更，一个操作者或处理将提交一个变更请求。该变更请求，包含一组该操作者想要在运行时间的该实例中执行的活动；这些活动分成三个组：创建活动，更新活动以及删除活动。

然后，所述要求被当做一个整体的，完成或无效活动的一个极小的组。当评估活动的组是否对该模型产生一个有效变更时，允许约束条件确认过程，以在该要求中考虑所有活动。

变更请求             说明确认错误无效文档未知的元素/属性      在该xml模式中寻找一个未知元素或属性

3.13.2.1.1  类型解析

在该类型解析阶段中，我们分解在该变更请求中引用的所有类型和成员。假定通过所述运行期，已载入所述变更请求；如果其不存在，该运行时间将必须开始一个载入/编译活动。

3.13.2.1.2  路径解析

在路径解析阶段的期间，我们决定引用已存在的实例和在变更请求内通过创建活动定义的实例。

3.13.2.2  扩展

扩展是我们采用变更请求，并引入执行该请求所需的所有剩余活动的过程。通常，这些活动是用于类型与关系范例的构成和毁坏的活动。理论上，该操作者可以提供用于构造或分解一个实例所需的所有活动的细节，但是我们并不需要这些，因为它将使变更请求创造过程变得非常复杂。取而代之，我们设法自动操作这些过程中的大部分：该操作者通过识别对参数引用成员的活动，提供关于所需变更的密钥信息；然后，我们插入对分组参数引用和值引用成员以及关系的其余的活动。

3.13.2.2.1  值成员

在扩展阶段期间，我们识别所有非引用类型成员。我们了解这些成员的所述基数，且我们了解所有所需参数，因此对于每一个成员，我们将所创建的要求添加到其父母被创建的那些成员的变更请求。如果所述转换请求包含分解操作，我们将所述分解操作添加给所有其所包含的实例。

3.13.2.2.2  引用成员扩展(发现)

通常，引用成员需要比构建值成员更多的信息。他们的基数通常是未定义的，且他们具有构造他们的范例的所需值的部署时间设置。因此，扩展一个参数引用成员的过程，需要比同一位置的运行时间所提供的更多的信息。通过该过程，我们获得被称作发现的这些信息。

发现的过程，将引入引用类型成员，作为一个构成或更新活动的一部分。只有具有支持发现的对象管理者的引用成员，参与这个过程。

当发现一个新的实例时，我们首先使用实例专用密钥值，核对该实例没有存在于SDM数据库中。一旦我们了解它是一个新的实例，然后我们根据我们发现的成员的类型对所述实例进行分类。如果所述实例没有与一个成员相匹配或存在一个模糊的匹配，则我们保留成员引用空白，且将所述实例标记为离线且未完成的。

3.13.2.2.3  关系扩展

一旦我们了解将构造的所有类型实例，则我们创建与类型实例绑定在一起的关系实例。如果已分解类型实例，我们将删除引用该类型实例的全部关系实例。

为了创建关系，我们开始使成员空间识别将存在于实例之间的关系的配置。其中类型成员具有大于1的基数，我们不得不推断该关系的拓扑结构。在章节XX中，我们将详细讨论我们如何执行。

3.13.2.3  数据流

在数据流阶段期间，我们评估通过所有关系实例的数据流。这个阶段可以把更新请求添加到受已改变参数数据流的影响的实例的变更请求上。

通过决定作为变更请求的结果，已更新设置实例的组，对数据流进行评估。对于其中的每一个，评估任何一种取决于修改设置的输出设置数据流，并且将目标节点添加到已变更实例的组中。继续该过程，直到该组是空的或该组包含一个循环。

错误/报警      说明无终端数据流

3.13.2.4  副本检测

副本检测的过程，相对于已存在于sdm数据库中的实例，与扩展实例相匹配。例如，我们将检测如果另一个应用程序安装一个共享文件。当我们检测已存在的一个实例时，我们可以凭借存在实例的版本，执行多个活动之一：

a)我们可以无效该安装

b)我们可以引用计算该实例

c)我们可以升级该实例

d)我们可以并行的安装

3.13.2.5  约束条件评估

在约束条件评估期间，我们核对模型中所有的约束条件，在已处理变更请求之后，上述约束条件仍然有效。

对于v1，我们可以必须访问图表中具有一个决定约束条件范围的约束条件的每一个节点，可能困难的(我们也许可能通过这样的方式标记成员空间，以使我们可以精减该实例空间)

3.13.2.6  请求排序

现在，我们具有一个完整的活动列表，因此，我们能够在系统之间使用关系，以确定一个有效变更顺序。

3.13.2.7  执行

我们将分配机器指定的活动的顺序集的子集。我们应该支持这些机器指定集的机器同步。

3.13.2.8  请求返回

通过基于所影响的宿主关系，将该变更请求拆散为多个可分配部分，以执行该变更。一旦结束(或失败)所有部分，在该运行时间中校对该结果，并且将一个概要返回至该用户。

3.13.3  深度扩展

在这一节中，我们将更详细的讨论类型和关系的扩展处理。

3.13.3.1  引用成员扩展(发现)

通过一种相同的方式，宿主关系负责构建一个类型的新的实例，我们也使用宿主关系来发现现存的类型实例。宿主关系是唯一存在以指定宿主关系是作为单独意识到在一个宿主上表示一个类型实例的方法的唯一存在以执行的关系。

当标记用于发现的一个引用成员时，我们核对以查看该宿主关系是否支持发现。如果它支持，则我们把该宿主实例传送给关系，并且让它返回用于在宿主上找到的客人实例的构成活动。

我们使用验证，从而发现实例不再存在。再一次使用该宿主关系，以验证在一个宿主上的一个客人的存在。如果客人们不再存在，则然后将这个宿主关系添加至该变更请求。

3.13.3.2  非引用成员扩展

在该变更请求内，对于已识别的构成或分解的一个类型的每一个非引用成员，运行时间通过简单地添加构成或分解活动，处理所有非引用成员扩展。

3.13.3.3  通信关系扩展

如果该操作者不指定一个通信关系的实例，其中一个通信关系成员存在于两个类型成员之间，然后我们通过假定在成员之间存在的一个完全连接网络，扩展该通信关系。

如果存在我们无法捕获的重要的拓扑结构，也可以放松该连通性约束条件，但是它使该部署的过程复杂化。例如，如果我们允许宽松的拓扑结构，那么我们可以提供一个创建并且管理这个连线的方法，执行对于任何一种变更的路径核对，并且将该拓扑结构公开，以使操作者创建该部署。

这个意味着什么？如果在成员空间中两个成员相连接，那么每一个成员的所有实例将能够互相查看。如附图18所示，给定以下两个成员，通过成员的基数约束该实例空间的拓扑结构。在1800示出了两个实例成员。在1802，在两个实例的最大限度之间，说明了一个简单的点对点关系。在1804，说明了一个连接的扇出。一个实例可以是一个客户机，通过一组服务器，该客户机可以载入平衡请求。在1806，说明了一个连接的扇出。一个实例可以是一群共享一个单独的服务器的客户机。在1808，说明了上述案例的一个组合，其中一组客户共享一组服务器。

当我们构造通信连接时，如果删除该授权端点，则授权端点变得透明，以便我们结束与所有存在的通信关系相匹配的连接。附图19说明了两个结构1902和1904，上述结构就在实例A，B和C之间的连接而言是等效的。

3.13.3.4  宿主关系扩展

在宿主关系模糊的位置，我们需要宿主关系的操作者或管理员决定该正确的拓扑结构。

如果该宿主关系支持扩展，那么我们将宿主和客人的组送至关系管理员，并让管理员将其返回正确的构成活动。如果管理员不支持扩展，那么我们将变更请求返回给操作者，以便他们能够提供更多信息。

3.13.3.5  引用关系扩展

3.13.3.6  包含关系扩展

包容关系决不会模糊不清，因此该运行时间总是可以将适当的构造活动添加给变更请求。

3.13.3.7  授权关系扩展

对于扩展，授权关系遵守与通信关系相同的规则。

3.13.4  数据流

3.13.5  执行

3.14  SDM实例空间

以下章节，定义用于sdm运行时间的实例空间的对象模型。该实例空间，用于跟踪通过sdm模型化的系统配置的变更。

附图20说明了一个范例的UML框图，其中通过实例空间的一个概述。方框2002、2004、2006和2008表示在该文档的其它章节所定义的类型。

该实例空间围绕通过变更请求所启动的，确定版本的变更进行结构化。每一个实例可以具有一个线性系列的版本，上述版本表示对于所运行实例的微小的变化。未来的版本，还可以存在于他们传播给运行系统之前的该运行时间中。

对于SDM模型的这个版本，我们只有允许对于一个给定实例的线性变更。在将来，我们可以允许版本分支，并引入一个版本解析模型。相对于一个特定的实例，这将允许显示出超过一个的变更。

既然我们允许线性版本控制，那么我们可以载入一系列建立在上述的变更上的变更请求。在一个诸如一个滚动升级之类的处理期间，支持在先确认一个所采用的活动的序列。

3.14.1  SDM实例

所有的实例由SDM实例派生。他们共享定义用于设置模式的元素，以及与该实例定义上的成员相匹配的成员列表。他们也共享一组属性，上述属性定义了一个用于该实例的唯一标识符，一个用于该实例的版本号，一个用于该实例的名称以及表示该版本是否表示该系统运行状态的标记。

<xs：complexTypename＝″samlnstance″>

<xs：sequence>

<xs：element name＝″settingValues″type＝″settingValues″minOccurs＝″0″/>

<xs：element name＝″member″type＝″member″minOccurs＝″0″maxOccurs＝″unbounded″/>

</xs：sequence>

<xs：attribute name＝″id″type＝″instancelD″use＝″required″/>

<xs：attribute name＝″version″type＝″xs：int″use＝″required″/>

<xs：attribute name＝″isCurrent″type＝″xs：boolean″use＝″required″/>

<xs：attribute name＝″name″type＝″xs：string″use＝″optional″/>

<xs：attribute name＝″incomplete″type＝″xs：boolean″use＝″required″/>

</xs：com plexType>

属性/元素    说明设置值       定义该建模的系统对象的所需状态的设置值的列表。该列表包括所有所定义的值，上述值当部署该实例或通过来自相关实例的数据流时，通过在定义的开发者或成员，操作者进行定义。成员         这是该定义上表示成员的成员列表。每一个成员识别分配给该成员的实例。标识符       一个用于该实例的标识符，是全局范围内唯一的(对于支持所分配的运行时间)。版本         该版本号随对于实例的变更线性增加。IsCurrent    这是一个表示该版本是否表示该相同的运行状态的标记。可以存在表示更新那些没有传播给该运行系统的最新版本。名称         一个用于该实例的，在其所包含的成员范围中唯一的名称(从授权成员的角度来看可以不是唯一的)

3.14.2  成员

一个成员，用于与一个实例的成员相关，其中一组所引用的实例。一个实例的成员，是通过该实例的定义来进行定义的。所引用的实例，是那些具有为成员或实例而创建的，授权给成员的实例。一个成员可以表示一个存在超过一个所引用实例的阵列。

<xs：complexType name＝″member″>

<xs：sequence>

<xs：element name＝″instance″type＝″instanceRef minOccurs＝″0″maxOccurs＝″unbounded″/>

</xs：sequence>

<xs：attribute name＝″memberDeclaration″type＝″qualifiedName″use＝″optional″/>

<xs：attribute name＝″name″type＝″xs：string″use＝″required″/>

</xs：complexType>

属性/元素   说明实例        通过该成员引用的实例成员授权    在相关定义上的该成员的授权名称        在定义上的相关成员的名称

3.14.3  变更

一个变更表示一个对实例状态的变更。其与一个具有所影响实例的组的变更请求相关。该变更还识别变更的状态(查看章节XXX)且该变更表示是否执行该变更。

<xs：complexType name＝″change″>

<xs：sequence>

<xs：element name＝″instance″type＝″instanceVersionRer minOccurs＝″0″maxOccurs＝″unbounded″/>

</xs：sequence>

<xs：attribute name＝″id″type＝″changelD″use＝″required″/>

<xs：attribute name＝″status″type＝″changeStatus″use＝″required″/>

<xs：attribute name＝″changeRequest″lype＝″qualifiedName″use＝″optional″/>

<xs：attribute name＝″changeResponse″type＝″qualifiedName″use＝″required″/>

</xs：complexType>

属性/元素    说明实例         我们创建的作为相关变更请求的实例版本的列表标识符       用于该变更的唯一的标识符(至少对运行时间是唯一的

)状态        识别该变更的当前状态的列举变更请求    用于创建该变更的变更请求的连接变更响应    从变更的执行返回的结果的连接

3.14.3.1  变更状态

表现为以下状态之一的变更请求：

●未开始-表示对于一个变更请求，并没有尝试执行

●处理中-表示当前正在执行变更请求

●结束-表示该变更请求已成功结束

●失败-表示该变更请求失败，且该变更处于未完成状态

●退回重来-表示一个失败的变更请求已经成功退回重来

<xs：simpleTypename＝″changeStatus″>

<xs：restriction base＝″xs：string″>

<xs：enumerationvalue＝″notStarted″/>

<xs：enumeration value＝″inProgress″/>

<xs：enumeration value＝″completed″/>

<xs：enumeration value＝″failed″/>

<xs：enumeration value＝″rolledBack″/>

</xs：restriction>

</xs：simpleType>

3.14.4  具体对象实例

一个具体对象实例表示通过该类型属性识别的具体类型的一个实例。由于该实例能够表现为现实世界，所以我们需要跟踪该实例是否与现实世界中相对应的部分同步。我们也希望了解该实例作为该变更的结果，是否在线。对于所有的约束条件，一个在线的实例应该是有效的。一个离线的实例是无法看到通信关系中的另一个相关部分的。如果该实例是未完成的，那么，在该实例在线之前，需要另外的变更请求。

<xs：complexTypename＝″Objectlnstance″><xs：complexContent>

<xs：extension base＝″sdmlnstance″>

<xs：attribute name＝″inSync″type＝″xs：boolean″use＝″requireo″/>

<xs：attribute name＝″online″type＝″xs：boolean″use＝″required″/>

<xs：attribute name＝″type″type＝″qualifiedName″use＝″required″/>

</xs：extension>

</xs：complexContent>

</xs：complexType>

属性/元素   说明InSync      表示对于实例的设置是否与其在现实世界中相对应的部分匹配在线        表示认为现实世界相对应的部分是否在线且激活。如果一个实例不能满足任何一个约束条件，则无法将其置于在线状态。通信关系中引用它的的其他的参与者不能看到一个离线的实例(数据流无法评估？)未完成     这个标记表示一个实例的版本中缺少的必要信息。这个状态可能作为一个发现过程的结果，或者作为一个变更请求的结果而产生，所述发现过程，无法识别实例需要的所有信息，所述变更请求不能提供所有的必要信息。类型       对于实例的类型的引用

3.14.5  关系实例

一个关系实例表示所识别的关系类型的一个实例。由于关系不具有直接的现实世界表示，所以我们不需要保留关系是否在线或同步的信息。同样，由于关系是相对简单的，所以我们不希望他们是未完成的，虽然他们不满足他们的约束条件。

<xs：complexTypename＝″relalionshiplnstance″>

<xs：complexContent>

<xs：extension base＝″sdmlnstance″>

<xs：attribute name＝″relationship″type＝″qualifiedName″use＝″required″/>

</xs：extension>

</xs：complexContent>

</xs：complexType>

属性/元素   说明关系        与该实例相关的关系类型

3.14.5.1  包含实例

这表示包含关系的一个实例。

<xs：complexType name＝″containmentlnstance″>

<xs：complexContent>

<xs：extension base＝″relationshiplnstance″>

<xs：attribute name＝″parentlnstance″type＝″instancelD″use＝″required″/>

<xs：attribute name＝″childlnstance″type＝″instancelD″use＝″required″/>

</xs：extension>

</xs：complexContent>

</xs：complexType>

属性/元素   说明父母实例    识别参与关系中的父母实例孩子实例    识别参与关系中的孩子实例

3.14.5.2  通信实例

这表示通信关系的一个实例。

<xs：complexType name＝″communicationlnstance″>

<xs：complexContent>

<xs：extension base＝″relationshiplnstance″>

<xs：attribute name＝″clientlnstance″type＝″instancelD″use＝″required″/>

<xs：attribute name＝″serverlnstance″type＝″instancelD″use＝″required″/>

</xs：extension>

</xs：complexContent>

</xs：com plexType>

属性/元素      说明

客户机实例        识别参与关系中的客户机实例服务器实例        识别参与关系中的服务器实例

3.14.5.3  授权实例

这表示授权关系的一个实例。

<xs：complexType name＝″delegationlnstance″>

<xs：complexContent>

<xs：extension base＝″relationshiplnstance″>

<xs：attribute name＝″proxylnstance″type＝″instancelD″use＝″required″/>

<xs：attribute name＝″delegatelnstance″type＝″instancelD″use＝″required″/>

</xs：extension>

</xs：complexContent>

</xs：complexType>

属性/元素       说明代理实例        识别参与关系中的代理实例授权实例        识别参与关系中的授权实例

3.14.5.4  宿主实例

这表示宿主关系的一个实例。

<xs：complexType name＝″hostinglnstance″>

<xs：complexContent>

<xs：extension base＝″relationshiplnstance″>

<xs：attribute name＝″guestlnstance″type＝″instancelD″use＝″required″/>

<xs：attribute name＝″hostlnstance″type＝″instancelD″use＝″required″/>

</xs：extension>

</xs：complexContent>

</xs：com plexType>

属性/元素       说明客人实例        识别参与关系中的客人实例宿主实例        识别参与关系中的宿主实例

3.14.5.5  引用实例

这表示引用关系的一个实例。

<xs：complexType name＝″referencelnstance″>

<xs：complexContent>

<xs：extension base＝″relationshipl nstance″>

<xs：attribute name＝″sourcelnstance″type＝″instancelD″use＝″required″/>

<xs：attribute name＝″dependentlnstance″type＝″instancelD″use＝″required″/>

</xs：extension>

</xs：complexContent>

</xs：com plexType>

属性/元素     说明源实例        识别参与关系中的源实例从属实例      识别参与关系中的从属实例

3.14.6  实例

该实例组表示在sdm实例文件中存在的实例元素的集合。

<xs：group name＝″instances″>

<xs：choice minOccurs＝″0″maxOccurs＝″unbounded″>

<xs：element name＝″Systemlnstance″type＝″concreteTypelnstance″/>

<xs：element name＝″portlnstance″type＝″concreteTypelnstance″/>

<xs：element name＝″resourcelnstance″type＝″concreteTypelnstance″/>

<xs：element name＝″member″type＝″member″/>

<xs：element name＝″containmentlnstance″type＝″containmentlnstance″/>

<xs：element name＝″communicationlnstance″type＝″communicationlnstance″/>

<xs：element name＝″hostinglnstance″type＝″hostinglnstance″/>

<xs：element name＝″delegationlnstance″type＝″delegationlnstance″/>

<xs：element name＝″referencelnstance″type＝″referencelnstance″/>

<xs：element name＝″placementlnstance″type＝″placementlnstance″/>

</xs：choice>

</xs：group>

3.14.7  实例引用

3.14.7.1  实例引用

实例引用是对一个实例的简单引用。除在变更请求的条件下做出该引用的情况之外，实例将默认为isCurrent实例，且该实例受变更请求的影响。

<xs：complexType name＝″instanceRef″>

<xs：attribute name＝″instancelD″type＝″instancelD″use＝″required″/>

</xs：complexType>

3.14.7.2  实例版本引用

实例版本引用识别一个实例的特定版本。

<xs：complexType name＝″instanceVersionRer>

<xs：attribute name＝″instancelD″type＝″instancelD″use＝″required″/>

<xs：attribute name＝″version″type＝″xs：int″use＝″required″/>

</xs：complexType>

3.15  部署单元结构

必要条件

●包含需要安装一个SDM类型的组的所有比特

●可以进行标记和版本控制

●很容易被构造/封装/运送

●可以通过引用或者包含涉及其他的SDUs

● SDM类型定义的部署章节将直接地参阅SDU中的文档

3.16  定位

我们必须确定SDM模型的哪一部分支持定位并且我们怎样通过系统设计及配置来支持定位。

第一个方法：

我们全部定位以至逐个类型以进行管理。定位通过约束条件而隐含的。定位不是第一类型成员(citizen)。这意味着：

(a)SDUs可包含特定类型版本的实现：存在一个特定版本的实现。这是指根据单独的定位而不存在不同的实现。因此每一实现将支持一范围的区域或者该实现是不同类型的(为此利用版本控制这是错误的)。

(b)此后通过利用资源作为mixins以支持特定版本或者通过利用其可识别支持不同版本的实现的一组类型来实现定位。

(c)客户不能区分/需要定位的服务器版本。

第二个方法：

定位与名称及版本均是标识的第一类型成员。这意味着定位应该考虑其所涉及类型的任何地方。

a)现在客户可以区别在任何包含，宿主或者通信关系上所定位服务器的版本。

b)该部署引擎将意识到定位，并允许操作者在类型版本的定位之间进行选择。

c)通过名称，版本以及位置识别多个SDU，或者可以将多个实施例包含在一个SDU中，所述多个实施例根据它们的位置(第一指的是作为应置于单独的SDU中的非局限代码的SDU的微小的程序包，第二指的是我们可具有多个名称相同SDU...)

第二个方法如果广泛应用为一个约束条件，则可以从一个design/ui联系中得到很复杂的潜能。例如，如果定位在端点，或者如果宿主定位他们的客人，则寻找一个连接/位置，以得到更多的复合体。如果第二个方法作为所建议的装置，用于从第一个方法的b)开始的方法，则复杂性是便于管理，但是某人不得不识别，包装以及发送所定位的源。

3.17  版本和变更管理

3.17.1  一般注释

·我们想要适当的对系统进行版本变更-例如，不改变实例的本体，将一个qfe应用至sql。这意味着变更该实例的类型。

·我们想要允许控制所允许的版本变更的版本政策-例如，一个系统类型设计者可以选择如何明确用于系统成员的版本策略，或者，由于安全原因，一个操作者可以选择单方面升级的成员的版本。

·我们想要限制版本变更的传播-例如，如果我们变更一个成员的类型，则我们不得不变更系统的类型，从而将传播的类型转变为根。

·将通过第一个版本号的前两部分的改变，标明中断变更，将通过第二个版本号的第二两部分的改变，标明非中断变更。

计算机环境示例

图21给出了其用于实现这里所描述的技术的一通用计算机环境600。该计算机环境600只是计算环境的一个例子而并不是想对计算机和网络结构的使用及功能范围做出任何限制。不能将计算机环境600释为具有任何相关性或者与该示例性计算机环境600所示部件的任何一个或者其组合有关的要求。

计算机环境600包括以计算机602形式的通用计算装置。计算机602例如可以是图1的计算装置102、或者可实现开发系统202、或者可以是图2的控制器206、或者可以是图2的目标设备212、或者可以是图5的控制器520或者目标522。计算机602的部件包括但是不局限于一个或多个处理器或者处理单元604、系统存储器606、以及可使其包括处理器604的各种系统部件与系统存储器606相耦合的系统总线608。

系统总线608表示几类总线结构的任何一个或多个，这几类总线结构包括存储器总线或者存储控制器、外围总线、加速图形端口、处理器或者利用任一种总线结构的本地总线。举例来说，这种结构包括工业标准结构(ISA)总线、微通道结构(MCA)总线。扩展工业标准结构(EISA)总线、视频电子标准协会(VESA)本地总线、以及亦称为附加板总线的外设部件互连(PCI)总线。

计算机602典型的包括各种计算机可读介质。这种介质可以是由计算机602可访问的任何可用介质并且包括易失性的及非易失性介质、可移动的及固定介质。

该系统存储器606包括以诸如随机存取存储器(RAM)610这样的易失性存储器和/或诸如只读存储器(ROM)612这样的非易失性存储器形式的计算机可读介质。将包含有线程的基本输入/输出系统(BIOS)614存储在ROM 612中，该基本例程有助于例如在启动期间在计算机602之内的元件之间传送信息。RAM610典型的包含处理单元即刻所存取的和/或不久所操作的数据和/或程序模块。

计算机602还包括其他可移动的/固定的、易失性的/非易失性的计算机存储器介质。举例来说，图21给出了用于从固定的、非易失性的磁介质(未给出)中进行读取并进行写入的硬盘驱动器616，从可移动的、非易失性的磁盘620(例如“软盘”)中进行读取并且进行写入的磁盘驱动器618，以及用于从诸如CD-ROM、DVD-ROM、或者其他光介质这样的光盘624中进行读取和/或写入的光盘驱动器622。硬盘驱动器616、磁盘驱动器618、以及光盘驱动器622均通过一个或多个数据媒介接口626而与系统总线608相连。或者，硬盘驱动器616、磁盘驱动器618、以及光盘驱动器622通过一个或多个接口(未给出)而与系统总线608相连。

磁盘驱动器和其相关的计算机可读介质提供了非易失性存储的计算机可读指令、数据结构、程序模块、及其他计算机602的数据。尽管该示例示出了硬盘616、可移动的磁盘620、以及可移动的光盘624，但是应该理解的是还可以利用诸如磁带盒或者其他磁存储器、快擦写存储卡、CD-ROM、数字多用盘(DVD)或者其他光存储器、随机存取存储器(RAM)、只读存储器(ROM)、电可擦可编程只读存储器(EEPROM)等等这样的其可存储计算机可存取的数据的其他类型的计算机可读介质以实现该示例性计算机系统及环境。

将许多程序模块存储在硬盘616、磁盘620、光盘624、ROM 612、和/或RAM610上，该程序模块例如包括操作系统626、一个或多个应用程序628、其他程序模块630、以及程序数据632。该操作系统626、一个或多个应用程序628、其他程序模块630、以及程序数据632(或者其若干组合)的每一个均可实现用于支持分布式文件系统的所有或部分驻留部件。

用户通过诸如键盘634及指示设备636(例如“鼠标”)这样的输入设备而将命令及信息键入计算机602。其他输入设备638(具体未给出)可以包括扩音器、操纵杆、游戏垫、卫星碟、串行端口、扫描仪、和/或类似设备。这些及其他输入设备通过与系统总线608相耦合的输入/输出接口640而与处理单元604相连，但是可通过诸如并行端口、游戏端口、或者通用串行总线(USB)这样的其他接口和总线结构而连。

监控器642或者其他类型的显示器还可以通过诸如视频适配器644这样的接口而与系统总线608相连。除了监控器642之外，其他输出外围设备包括诸如扩音器(未给出)和打印机646这样的其通过输入/输出接口640而与计算机602相连的部件。

计算机602利用与诸如远程计算设备648这样的一个或多个远程计算机的逻辑连接而在网络环境中进行操作。举例来说，远程计算设备648可以是个人计算机、便携式计算机、服务器、路由器、网络计算机、对等设备、或者其他公用网络节点等等。远程计算设备648例如可以是便携式计算机，其包括这里所描述的与计算机602有关的多个或所有元件和特征。

计算机602与远程计算机648之间的逻辑连接被描述为局域网(LAN)650及广域网652。这种网络环境在办公室、企业广域计算机网络、内部网、以及互联网中是很平常的。

当在局域网网络环境中实现时，计算机602通过网络接口或者适配器654而与局部网络650相连。当在WAN网络环境中实现时，计算机602典型的包括一调制解调器656或者用于建立广域网652上的通信的其他装置。位于计算机602内部或者之外的调制解调器656通过输入/输出接口640或者其他适当机构而与系统总线608相连。应该理解的是所示出的网络连接是示例性的，并且可采用用于建立计算机602和648之间的通信链接的其他装置。

在一个网络环境中，诸如用计算环境600来说明的之类的，相对于计算机602所描述的程序模块，或它的一部分可能存储在一个远程存储器存储装置中。举例来说，远程应用程序658保存在一个远程计算机648的存储器件中。为了进行说明，虽然识别了计算装置602的不同存储部件中在不同时间存储的上述的程序和组成部分，但这里，将诸如所描述的操作系统之类的的应用程序及其他可执行程序组成部分，作为不连续的模块进行说明，并通过所述计算机的数据处理器进行执行。

这里，在普通的计算机可执行指令的上下文中，描述了诸如通过一个或多个计算机或其他装置执行的程序模块之类的不同的模块和技术。通常，程序模块包括线程，程序，对象，组成部分，数据结构等等，这些模块执行特定的任务，或实现特定的抽象数据类型。一般地，可以在不同的实施例中，组合或分配所述程序模块的功能。

这些模块和技术的实现，可以存储在计算机可读介质上，或通过计算机可读介质的形式进行传输。计算机可读介质可以是任何一种可以通过一个计算机访问的有效介质。举例来说，且并不局限于，计算机可读介质包括“计算机存储介质”和“传播介质”的计算机可读介质。

“计算机存储器介质”包括在诸如计算机可读指令，数据结构，程序模块，或其他数据之类的用于信息存储的任何一种方法或技术中实现的易失性介质和非易失性介质，可移动介质和固定介质。计算机存储介质包括，但不局限于，RAM，ROM，EEPROM，闪存或其他存储技术，CD-ROM，数字多用光盘(DVD)或其他光存储器，磁带盒，磁带，磁盘存储器或其他磁存储器，或任何一种可用于存储所需信息，且可以通过计算机访问的其他介质。

“传播介质”一般包括计算机可读指令，数据结构，程序模块，或在一个诸如载波之类的已调制数据信号，或其他传送装置中的其他数据。传播介质还包括任何一种信息传送介质。所述术语“已调制数据信号”，指的是具有一个或多个特征集或用这样的方式进行转换为所述信号中的编码信息的一个信号。举例来说，且不局限于，传播介质包括诸如有线网络或直接连线网络之类的有线介质，和诸如声音，RF，红外线以及其它无线介质之类的无线介质。上述任一介质的组合，也包括在计算机可读介质范围之内。

换句话说，所述结构的一部分可以在硬件或硬件的组合，软件和/或固件的形式实现。例如，可以设计或程式化一个或多个专用集成电路(ASIC)或可编程逻辑设备(PLDs)，以实现所述结构的一个或多个部分。

结论

虽然以结构特征和/或方法过程在语言中对本发明进行了描述，但是可以理解在附加的权利要求书中定义的本发明，不局限于所描述的具体特征或过程。相反地，将所述具体特征和过程，作为实现所请求的发明的实施形式予以公开。

Claims (47)

1、一种方法包括：

利用一个系统定义模型来设计一个系统；

随后在一个或多个计算装置上，利用系统定义模型，来部署该系统；以及

在部署该系统以后，利用系统定义模型管理在一个或多个计算装置上所部署的系统。

2、如权利要求1中所述的一种方法，其中所述系统包括一个应用程序

3、如权利要求1中所述的一种方法，其中该系统包括一个环境。

4、如权利要求1中所述的一种方法，进一步包括：利用在系统管理过程中所获得的知识，设计该系统的后续版本。

5、如权利要求1中所述的一种方法，其中该系统定义模型包括描述如何在一个或多个计算装置上部署该系统的知识。

6、如权利要求1中所述的一种方法，其中该系统定义模型包括描述如何在多个不同的计算装置上部署该系统的知识，其中所述知识包括描述如何在多个不同计算装置每一个上部署该系统的不同的知识。

7、如权利要求1中所述的一种方法，其中为了在一个或多个计算装置上运行所述系统，所述系统定义模型包括一个或多个计算装置必须满足的约束条件。

8、如权利要求7中所述的一种方法，其中所述系统定义模型用于在系统设计的过程中，核对通过一个或多个计算装置是否能够满足所述约束条件。

9、如权利要求7中所述的一种方法，其中所述系统定义模型用于在系统设计，以及系统管理的过程中，核对通过一个或多个计算装置是否能够满足所述约束条件。

10、如权利要求1中所述的一种方法，其中该系统定义模型包括描述如何在部署该系统之后管理所述系统的知识。

11、如权利要求1中所述的一种方法，进一步包括：在管理该系统的过程中，利用一个数据流，将一个配置变更自动传播给该系统。

12、如权利要求1中所述的一种方法，其中在一个或多个计算装置上将该系统部署给一个环境，该方法进一步包括，在该系统的设计，部署和管理之前：

利用另一个系统定义模型设计该环境；

随后，利用另一个系统定义模型，在一个或多个计算装置上部署该环境；以及

在部署该环境以后，利用另一个系统定义模型，管理在一个或多个计算装置上所部署的环境。

13、如权利要求12中所述的一种方法，其中通过一个或多个计算装置的配置的审查，得到用于该环境的系统定义模型。

14、如权利要求12中所述的一种方法，其中为了在一个或多个计算装置上运行该系统，系统定义模型包括环境必须要满足的约束条件，且其中为了在一个或多个计算装置上运行该系统，另一个系统定义模型包括系统必须要满足的其他约束条件。

15、如权利要求1中所述的一种方法，其中在一个或多个计算装置上部署多个环境，该方法进一步包括：

利用多个不同的系统定义模型，设计多个环境中的每一个，其中多个环境中的每一个，与多个不同的系统定义模型之一相关联；

对于每一个环境，利用相关的多个不同的系统定义模型之一，部署该环境；以及

对于每一个环境，在利用相关的多个不同的系统定义模型之一进行部署之后，管理该环境。

16、如权利要求15中所述的一种方法，其中多个环境中的每一个是分层的，且其中多个环境中的每一个，作为多个环境中其他环境中的一个环境的环境，或者该系统的环境。

17、一个或多个计算机可读介质，其中存储了多条指令，这些指令实现一个模式，其中该多条指令，当由处理器执行时，使处理器：

便于系统设计；

便于系统部署；以及

便于管理系统。

18、如权利要求17中所述的一个或多个计算机可读介质，其中所述系统包括一个应用程序。

19、如权利要求17中所述的一个或多个计算机可读介质，其中所述系统包括一个环境。

20、如权利要求17中所述的一个或多个计算机可读介质，其中便于部署该系统，将包括，在一个系统定义模型中，描述了如何在多个不同的环境中部署该系统的知识。

21、如权利要求17中所述的一个或多个计算机可读介质，其中为了便于部署该系统，将包括，在一个系统定义模型中，描述了如何在多个不同的环境中部署该系统的知识，且其中该知识包括描述了如何在多个不同环境的每一个中部署该系统的不同的知识。

22、如权利要求17中所述的一个或多个计算机可读介质，其中为了便于设计该系统，将包括，为了在该环境中运行该系统，系统定义模型包括环境必须要满足的约束条件。

23、如权利要求22中所述的一个或多个计算机可读介质，其中为了便于设计该系统，将使用系统定义模型，以核对设计该系统的过程中，该环境是否满足约束条件。

24、如权利要求17中所述的一个或多个计算机可读介质，其中为了便于管理该系统，将包括，在一个系统定义模型中，描述如何管理该系统的知识。

25、一个执行一个模式的装置包括：

便于设计一个系统的装置；

便于部署该系统的装置；

以及便于管理该系统的装置。

26、如权利要求25中所述的一个装置，其中便于部署该系统的装置包括包含在一个系统定义模型中，描述如何部署该系统的知识的装置。

27、如权利要求25中所述的一个装置，其中便于部署该系统的装置包括在一个系统定义模型中，包含描述如何在多个不同的环境中部署该系统的知识的装置，以及其中该知识包括描述了如何在多个不同环境的每一个中部署该系统的不同的知识。

28、如权利要求25中所述的一个装置，其中便于设计该系统的装置包括一个装置，该装置在一个系统定义模型中，为了在该环境中运行该系统，包含一个环境必须满足的约束条件的装置。

29、如权利要求28中所述的一个装置，其中便于设计该系统的装置包括一个装置，该装置在系统设计过程中，利用系统定义模型，核对该环境是否满足约束条件。

30、如权利要求25中所述的一个装置，其中便于管理该系统的装置包括一个装置，该装置在一个系统定义模型中，包含描述如何管理该系统的知识。

31、一个系统包括：

在一个应用程序的生命周期中均可应用的一个系统定义模型，其中该应用程序的生命周期包括该应用程序的设计，该应用程序的部署，以及该应用程序的管理；以及

决定如何在系统定义模型内，指定功能操作的一个模式。

32、如权利要求31中所述的一个系统，其中该系统定义模型包括描述如何部署该应用程序的信息。

33、如权利要求31中所述的一个系统，其中该系统定义模型包括描述如何在多个不同环境中部署该应用程序的信息，且其中该信息包括描述如何在多个不同环境的每一个中部署该应用程序的不同信息。

34、如权利要求31中所述的一个系统，其中所述系统定义模型包括为了在该环境中运行所述应用程序，一个环境必须满足的多个约束条件。

35、如权利要求34中所述的一个系统，其中所述系统定义模型用于在应用程序设计，以及应用程序管理的过程中，核对一个或多个计算装置是否能够满足多个所述约束条件。

36、如权利要求34中所述的一个系统，其中所述系统定义模型用于在应用程序设计的过程中，核对该环境是否能够满足所述约束条件。

37、如权利要求31中所述的一个系统，其中该系统定义模型包括描述如何管理该应用程序的信息。

38、如权利要求31中所述的一个系统，其中该系统进一步包括：

在一个环境的生命周期中均可应用的环境的另一个系统定义模型，其中该环境的生命周期包括该环境的设计，该环境的部署，以及该环境的管理；

其中该模式进一步决定如何在另一个系统定义模型内，指定功能操作。

39、如权利要求38中所述的一个系统，其中通过一个或多个计算装置的配置的审查，得到用于该环境的系统定义模型。

40、如权利要求38中所述的一个系统，其中为了在环境中运行该应用程序，系统定义模型包括环境必须要满足的约束条件，且其中为了在该环境中运行该应用程序，另一个系统定义模型包括应用程序必须要满足的其他约束条件。

41、如权利要求38中所述的一个系统，其中该系统进一步包括：

在一个附加环境的生命周期中均可应用的环境的一个附加系统定义模型，其中该附加环境的生命周期包括该附加环境的设计，该附加环境的部署，以及该附加环境的管理；

其中该附加环境分层为以下环境；

以及其中该模式进一步决定如何在该附加系统定义模型内，指定功能操作。

42、一个方法包括：

在一个系统的设计过程中，结合在该系统的部署和管理过程中一个系统定义模型运行时间，定义一个使用过的系统定义模型的实例。

43、如权利要求42中所述的一个方法，其中该系统定义模型包括描述如何部署该系统的信息。

44、如权利要求42中所述的一个方法，其中该系统定义模型包括描述如何在多个不同运行时间中部署该系统的信息，且其中该信息包括描述如何在多个不同运行时间的每一个中部署该系统的不同信息。

45、如权利要求42中所述的一个方法，其中所述系统定义模型包括为了在该运行时间中运行该系统，该运行时间必须满足的约束条件。

46、如权利要求45中所述的一种方法，其中所述系统定义模型用于在系统设计的过程中，核对运行时间是否能够满足所述约束条件。

47、如权利要求42中所述的一个方法，其中该系统定义模型包括描述在运行时间中，如何管理该系统的信息。

Images