JP2004272908A - Method for integrating phase of design, development and management of system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To integrate the phases of the design, development and management of the system. <P>SOLUTION: The integration of the phases of the design, development and management of the system includes the design of the system by using a system definition model in accordance with various configurations. Afterwards, the system is developed on one or more computing devices by using the system definition model, and after the system is developed, the system developed on one or more computing devices is managed by using the system definition model. <P>COPYRIGHT: (C)2004,JPO&NCIPI

Description

  The present invention relates to an architecture for a distributed computing system.

  Internet use has exploded over the past several years and continues to grow. People have become very comfortable with the many services offered on the World Wide Web (or simply "Web"), such as email, online shopping, news and information gathering, listening to music, watching video clips, and job hunting. . To keep up with the increasing demand for Internet-based services, the number of dedicated computer systems for hosting websites, providing back-end services for these sites, and storing data related to the sites has increased significantly. .

  One type of distributed computer system is a data center (such as an Internet Data Center (IDC) or an Enterprise Data Center (EDC)), which is a specially designed system that houses many computers to host network-based services. This is the composite that was obtained. Data centers, sometimes referred to as "web farms" or "server farms", typically have hundreds to thousands of computers in physically secure buildings with controlled temperature and humidity. To accommodate. Data centers generally provide Internet access, reliable power supply, and a secure operating environment.

  Today, large data centers are complex and often required to host multiple applications. For example, some websites operate thousands of computers and host many distributed applications. These distributed applications often have complex networking requirements, and operators need to physically connect computers to certain network switches and manually configure cabling within the data center to support complex applications. It is necessary to. As a result, this task of building a physical network topology to meet application requirements can be a time-consuming and cumbersome process, and is prone to human error.

  Accordingly, there is a need for improved techniques for designing and deploying distributed applications on physical computing systems.

  The present invention has been made in view of such a situation, and an object of the present invention is to provide a method for efficiently designing, deploying, and managing a system, and a method for integrating the phases of system design, deployment, and management. To provide.

  The integration of the system design, deployment, and management phases is described herein.

  According to some aspects, a system is designed using a system-defined model. Thereafter, the system is deployed on one or more computing devices using the system-defined model. After system deployment, the system-defined model is used to manage the system deployed on one or more computing devices.

  Hereinafter, embodiments to which the present invention can be applied will be described in detail with reference to the drawings. The same numbers are used throughout the drawings to refer to the same features.

  The following disclosure describes some aspects related to an architecture for designing and implementing a distributed computing system having large-scale application services. This disclosure includes a description of a system definition model (SDM) (sometimes called a service definition model (SDM)) and an SDM runtime environment. SDM provides tools and context for application designers to design distributed computer applications and data centers in an abstract manner. This model defines a set of elements that represent the functional units of an application that will ultimately be implemented by physical computer resources and software. Associated with the model element is a schema that dictates how the functional behavior represented by the component should be specified.

  In this specification, the term “wiring” may be referred to as “connection”, “communication”, or “communication relation”. The term “system” may be referred to as “module”, and the term “resource space” may be referred to as “resource”. Further, the term “application space” may be referred to as “application”, and the term “instance space” may be referred to as “instance”. Further, the term "class" may be referred to as "abstract definition", the term "port" may be referred to as "endpoint", and the term "type" may be referred to as "definition".

  FIG. 1 illustrates an exemplary network 100. In the configuration of network 100, a plurality (x) of computing devices 102 (1), 102 (2),. . . , 102 (x) are coupled to the network 106. Network 106 may represent any of a variety of conventional network topologies and types (including wired and / or wireless networks) employing various conventional network protocols (including public and / or proprietary protocols). And Network 106 may include, for example, a local area network (LAN), a wide area network (WAN), a portion of the Internet, and the like. The configuration of network 100 may be any of a wide variety of settings, including, for example, a data center (eg, an Internet data center (IDC)), an office or business setting, a home setting, an education or research facility, a retail or sales setting, a data storage setting, and the like. Represents

  Computing device 102 may be a variety of conventional devices, including desktop personal computers (PCs), workstations, mainframe computers, server computers, Internet devices, gaming consoles, handheld computers, mobile phones, personal digital assistants (PDAs), and the like. It can be any of the types of computing devices. One or more devices 102 may be the same type of device or different types of devices. Further, even if the devices are the same type of device, the devices may still be configured differently (eg, the two devices 102 are server computers but have different processors, different amounts of random access memory). (RAMs, hard disk drives of different sizes, etc.).

  One or more computing devices 102 may also be reconfigured after being added to the settings of network 100. For example, a particular computing device 102 may operate over a period of time (eg, in units of minutes, hours, days, months, etc.) to perform one function, and then the administrator may determine that a different function is desired. (Eg, changing from a server computer to a workstation computer, changing from a web server to a local file server).

  FIG. 2 is a block diagram illustrating an exemplary architecture 200 that uses a system-defined model. SDM is designed to be used throughout the life cycle of the system. A system is a set of related software and / or hardware resources that can work together to achieve a common function. One example of such a system is an application, which refers to a set of instructions that can be run or executed by a computing device to perform various functions. Examples of applications include entertainment applications such as games, productivity applications such as word processors, reference applications such as electronic encyclopedias, distributed applications that can be used for web services and financial analysis, and the like. Another example of such a system is an environment in which an application (or another environment) can be deployed. An environment refers to software and / or hardware resources on which an application (or another environment) is deployed. Such an environment can be layered as discussed in more detail below.

  The life cycle of a system typically includes three major phases (also called stages). That is, a design or development phase, followed by a deployment or installation phase, and a subsequent operation or management phase. Since this model applies to all three phases of the system life cycle, it can be viewed as an integration point for the various phases of the system life cycle, facilitating each of the three phases. In addition, using this model, knowledge can be transferred between these phases. Knowledge may include knowledge of system management (eg, feedback given to the design and development team so that the design and development team can modify the system for future versions or to improve the performance of the current version) and the structure of the system. , Deployment requirements, knowledge of the behavior (vehavior), knowledge of the operating environment from the desktop to the data center, and knowledge of the service level observed by the end user.

  Generally, during the design phase, a development tool that affects the SDM is used to define a system consisting of communication software and hardware components. The system definition contains all the information needed to deploy and operate a distributed system, including necessary resources, configurations, operating characteristics, policies, and the like. During the deployment phase, the system is automatically deployed using system definitions, and the required software and hardware (eg, server, storage, and network) resources are dynamically allocated and configured. The same system definition can be used for deployment to different host environments and different sizes. During the management phase, an SDM service in the operating system provides a system-level view for managing the system. This allows new management tools to drive resource allocation, configuration management, upgrades, and process automation from a system perspective.

  Architecture 200 employs an SDM-defined model and a schema that defines the functional operations within the SDM-defined model. Definition models include various different types of data structures, which are collectively referred to as "definitions." The functionality of the SDM is exposed through one or more platform services, such as an application program interface (API).

  During the design phase of the system, the development system 202 generates a document containing the system definition, such as the SDM document 204. Development system 202 may be any of a variety of development systems, such as the Visual Studio® development system available from Microsoft® Corporation of Redmond, Washington. The SDM document 204 defines all information (also referred to herein as knowledge) related to the deployment and management of the system. Any knowledge needed or used in deploying or managing the system is included in the SDM document 204. Although the knowledge is described herein as a single document, it should be understood that the knowledge may alternatively be maintained in multiple documents.

  A system definition defines a system in terms of one or more resources, endpoints, relationships, and subsystems. The system definition is declared in an SDM document (for example, an XML (Extensible Markup Language) document). Resources can be hardware resources or software resources. Endpoints represent communications across systems. Relationships define the relationships between systems, resources, and endpoints. Subsystems can be treated as complete systems and are usually part of a larger system.

  The system definition captures the basic structure of the dynamic system. This can be viewed as a skeleton on which all other information is added. This structure is generally specified by the designer and developer during the development process and usually does not change frequently. In addition to the structure, the SDM can also include deployment information, installation processes, schemas for configuration, events and measurements, automation tasks, health models, operational policies, and the like. Throughout the life of the distributed system, operations staff, vendors, and / or management systems can add other information.

  SDM document 204 includes one or more system constraints (also referred to as requirements) that must be met by the environment in which the system will be deployed and / or executed. The environment itself is also described using an SDM document. Such an environment may be a single computing device, or a collection of computing devices (eg, a data center), a collection of application hosts, and so on. Different systems can be installed in different environments. For example, if a data center includes 50 computing devices, deploy one system to five of these computing devices and deploy another system to 35 of these computing devices. be able to. These requirements can take various forms: That is, the hardware requirements (eg, minimum processor speed, minimum memory, minimum hard drive space, minimum available network bandwidth, specific security mechanisms available, etc.) for the computing device on which the system is deployed. And the software requirements for the computing device on which the system is deployed (eg, a particular operating system, one or more other applications that must be installed with it, how to configure the particular system and / or operating system) Specifications, specific types of security or encryption used, and other requirements for the computing device on which the system is deployed (eg, available security keys, security Data center policies that must be, authentication used is an environment topology, etc.) and the like.

  Requirements may be heading in another direction. That is, the environment may have restrictions or requirements on the configuration of the system to be installed (eg, to enforce environmental standards or policies). These can be "explicit" requirements created by the environment's operators, specific settings or configurations that the system must have, specific features that the system must provide or support, Such as the specific security mechanisms that must be supported. These can also be "implicit" requirements caused by a particular configuration of the environment. For example, if the host computing device in the environment uses a particular type of file system, there may be actions that cannot be performed using this file system (if another file system is used, Although these actions can be performed).

  During the system design and development phase, the SDM document 204 can be used to validate the system for one or more specific environments. This is a two-way validation. That is, the system is validated for the environment, and the environment is validated for the system. Validating the environment for the system may be performed by comparing the requirements identified in the SDM document 204 to the environment and determining whether all requirements are met by the environment. Validating the system for the environment can be done by comparing the requirements identified for the environment in the SDM document with the system and determining whether all requirements are met by the system. If all requirements are met by the environment and the system, the designer or developer will know that the system can be deployed in this environment and that the system will run in this environment. However, if not all requirements are met by the environment and / or the system, the designer or developer is optionally notified of the missing requirements, thereby deploying and running the system in this environment. Inform the SDM document 204 (and correspondingly to the system) and / or to the environment to make changes.

  The system deployment knowledge contained in the SDM document 204 describes how to deploy the system in one or more environments. The SDM document 204 is made available to a controller 206, which comprises a deployment module 208 and a management module 210. In one embodiment, the SDM document 204, as well as all system files (eg, binaries, data, libraries, etc.) needed to install the system, are stored in a single container (eg, a single file ) Will be packaged together. Controller 206 may be one or more of computing device 102 of FIG. For example, the single device 102 of FIG. 1 may be a controller for a particular data center, or the responsibilities of the controller may be distributed among multiple devices 102.

  Deployment module 208 includes services used to deploy the system into the environment. In FIG. 2, the environment in which the system is deployed is (or has been deployed on) one or more target devices 212. The system can also be deployed on the controller 206. These services of the deployment module 208 include one or more functions that can be called to install or deploy one or more systems into the environment.

  The SDM document 204 can include different knowledge for deployment in different environments. This deployment knowledge is based on any changes that need to be made in the environment (eg, system registry, folders, directories, or files that need to be created, other settings on the computing device that need to be set to specific values, etc.). Changes to parameters or configuration parameters, etc.), and what files (eg, program files and / or data files) in the environment need to be copied to the computing device and need to be performed on these files Describe any operations (eg, some files need to be decompressed and / or decrypted). In many implementations, the deployment knowledge in the SDM document 204 includes information similar to information currently found in, for example, a normal setup or installation program for the system.

  During the deployment process, the controller 206 generates a record or storage of the software and hardware resources involved in the deployment, and their relationships. This record or storage can be used later by the controller 206 during the management phase.

  Management module 210 includes services used to manage the system after the system has been installed in the environment. These services of the service management module 210 include one or more functions that can be called to manage the system in the environment. The knowledge of system management contained in the SDM document 204 describes how to manage the system in one or more environments.

  The SDM document 204 can include different knowledge for managing the system in different environments. Management knowledge includes any knowledge used in managing or operating the system. Management includes, for example, configuration (and optionally later reconfiguration), patches and upgrades, maintenance operations (eg, backup), health monitoring or performance monitoring, and the like.

  Changes to the deployed system are made via the management module 210. The services of the management module 210 include one or more functions that can be called to make changes to one or more systems deployed in the environment. By making these changes through the management module 210, several benefits can be realized. One such advantage is that the controller 206 can maintain a record of the changes made. Controller 206 maintains a copy of SDM document 204 for the system and can record any changes made to the system in SDM document 204. Alternatively, controller 206 may maintain a separate record of changes made to the system.

  This change log maintained by the controller 206 can be used to resolve system and / or environmental issues, or when a hardware failure requires the system to be reinstalled (reinstalling the system and using the same parameters / Subsequent operations can be simplified. By having such changes made by controller 206, and by having controller 206 maintain a record, some human error can be eliminated from the environment (eg, the administrator making the change). If he is supposed to record the change on paper and forgets to do so, there will be no record of this change. This problem is solved by having the controller 206 maintain a record).

  In addition, by making changes to the system via the controller 206 and deploying the system via the controller 206, the controller 206 communicates with the environment, the systems deployed in the environment, and the interactions between them. Can act as a repository of knowledge about Knowledge of the environment and / or systems deployed in the environment can be readily obtained from the controller 206. This knowledge can be used to ensure the consistency of the controlled environment by validating that the controlled devices in the environment reflect the state stored in the central controller 206. .

  Note that in some circumstances, changes may be made to the system and / or environment without going through the controller 206. For example, a computing device may be accidentally turned off or disabled. In these situations, an attempt is made to reflect such changes in the controller 206. These changes can also be automatically reflected in the controller 206 (eg, activate a system that detects device failures and notifies the controller 206 of such failures using the services of the management module 210). (Eg, an administrator can notify controller 206 of such changes using a service of management module 210). Alternatively, the changes made may be undone and some of the system and / or environment may again match the desired system state recorded by controller 206.

  Thus, the SDM document 204 can be considered a "live" document. That is, it can change continuously throughout the life cycle of the system based on environmental changes and / or system changes.

  SDM allows the system to be functionally configured across the horizontal and vertical axes. Configuration along the horizontal axis is performed by systems and subsystems. The configuration along the vertical axis is performed by “layer”. Applications, services, network topologies, and hardware play a role in distributed systems, but are typically defined independently and owned by different teams or organizations. Layering is achieved by the component defining a set of constraints for the host and vice versa.

  FIG. 3 shows an exemplary layering setting. FIG. 3 shows four layers, that is, a layer 302, a layer 304, a layer 306, and a layer 308. Although four layers are shown in FIG. 3, the actual number of layers may vary, and may be more or less than four. Furthermore, the contents of the various layers can also be varied according to the embodiment. As can be seen from FIG. 3, the various layers are above and / or below other layers (eg, layer 306 is above layer 304 but below layer 308).

  Various systems and subsystems within a layer can interact with each other and with systems and subsystems at different layers. For example, subsystem 310 in layer 308 may interact with subsystem 312 in layer 308, as well as subsystem 314 in layer 306. Further, each layer can be considered an environment for the next higher layer. For example, layer 306 is the environment for the systems and subsystems in layer 308, and layer 304 is the environment for the systems and subsystems in layer 306. Each layer 302, 304, 306, 308 has its own associated SDM document.

  The various layers 302, 304, 306, 308 may represent different content. In some embodiments, layer 302 is a hardware layer, layer 304 is a network topology and operating system layer, layer 306 is an application host layer, and layer 308 is an application layer. A hardware layer represents a physical device (eg, a computing device) upon which a layered system is built (eg, device 102 of FIG. 1). The network topology and operating system layers represent the network topology of the computing devices (eg, the configuration of network 100 of FIG. 1), as well as the operating systems installed on those computing devices. The application host layer represents an application installed on the computing device that can host other applications (eg, a Structured Query Language (SQL) server, Internet Information Service (IIS) (trademark), etc.). The application layer represents applications installed on the computing device that do not host other applications (for example, entertainment applications such as games, productivity applications such as word processors, reference applications such as electronic encyclopedias, web services and financial analysis). Distributed applications that can be used).

  FIG. 4 is a flowchart illustrating an exemplary process 400 for using SDM throughout the life cycle of the system. The various operations of the process 400 of FIG. 4 may be implemented in software, firmware, hardware, or a combination thereof.

  First, a system is designed based on the SDM (operation 402). The system is designed to include the requirements that the environment must meet in order for the system to be deployed and run in the environment, as well as other knowledge used to deploy and manage the system. This knowledge is contained in the SDM document associated with the system. After design, the system can optionally be validated using SDM (operation 404). This validation allows the designer or developer to verify that the system can be deployed and executed in the environment being validated. As discussed above, not only is the system validated against the environment in which the system is deployed, but also the environment is validated against the system. If the validation fails for a particular environment, additional design steps can be taken to modify the system so that it can run in this environment (or to take steps to modify the environment). Can be).

  After validation, the system can be deployed using SDM (operation 406). When you deploy a system into an environment, you install the system into the environment so that you can run it later in this environment. The knowledge used to install the system is contained in the SDM document associated with the system. After deployment, the system is monitored and / or managed using SDM (operation 408). The knowledge in the SDM document associated with the system identifies how to monitor and / or manage the system, and the system is monitored and / or managed in the environment according to this knowledge.

  The process 400 of FIG. 4 can be used with a system as an application, as well as a system as an environment. For example, the application can be validated against the SDM of the environment (eg, the application in layer 308 of FIG. 3 is validated against the environment of layer 306 of FIG. 3). As another example, an operator or system designer designs environments (eg, layers 306 or 304 in FIG. 3) and associates these environments with the environment (eg, layers 304 and 302, respectively) into which they are deployed. Can be validated.

  Constraints on the system and / or environment may also be used during runtime (while the system is being monitored / managed) to validate changes to the system and / or environment during runtime. Such run-time validation allows, for example, an operator of an environment to determine how changes to the environment will affect a running system, or allow a system designer to determine which changes to a system Can be determined to affect its execution in the environment.

  In the following explanation, the flow and the setting flow concerning the runtime will be referred to. Flows are used to pass configuration information between parts of a distributed system (eg, allowing a developer to specify configuration information for a location, or allowing an operator to provide only a single entry). Do). Flow is also used to determine the impact of changes to the configuration by following the flow of configuration data between parts of the system.

  FIG. 5 illustrates an exemplary architecture 500 that uses an SDM runtime. Architecture 500 is an example of architecture 200 of FIG. 2 and uses SDM runtime 510 and an exemplary implementation of SDM, which will be discussed later in the “Exemplary SDM Implementation” section. The SDM runtime 510 receives and validates SDM files, loads SDUs (System Definition Units, packages of one or more SDM files and their associated files), generates and executes SDM change requests. And includes a set of components and processes for deploying an SDM-based system to a target environment. This runtime capability allows a system described using SDM to be defined and validated, deployed and managed on a set of computing devices.

  The SDM is designed to support the description of the composition, interaction, and modification of components in a distributed system (modeling system), which will be discussed in more detail in the "Example SDM Implementation" section below. Is done. SDM is based on an object relational model. "Definitions" describe the entities that exist in the system, and "relationships" identify the links between the various entities. Definitions and relationships are further defined to capture semantic information related to the SDM. Specifically, definitions are divided into components, endpoints, and resources. Relationships can be broken down into connections (also called communications), inclusion, hosting, delegation, and referrals. More details on the definitions and relationships will be provided later.

  SDM includes "abstract definitions". This provides a common categorization of parts of the system, tool support for a wide range of systems, and a basis for design-time definition checking. The set of abstract definitions provides a comprehensive foundation for service design. The "concrete definition" represents each part of the actual system design or data center design. The generation of a concrete definition is performed by selecting an abstract definition and providing an implementation that defines the members of the concrete definition and the setting values of their properties. A distributed application is generated using a set of these concrete definitions.

  SDM also includes "constraint". Constraints model constraints based on the set of allowed relationships that an instance of the relationship can participate in. Constraints are useful in describing requirements according to the composition of the objects involved in the relationship. For example, constraints can be used to determine whether participants at both ends of the communication protocol are using compatible security settings.

  To implement changes to the target system, the SDM uses a declarative description of the required change, called a "change request" or CR. The SDM defines the process used to expand, validate, and execute change requests as part of the "SDM execution model".

  The "instance space" captures both the desired state and the current state of the managed application. Changes in the instance space are tracked and associated with the change request that initiated the change. The instance space is stored in the SDM runtime and reflects the current state of the modeling system. The runtime contains a complete record of the instances created and the relationships between these instances. Each instance is associated with a version history in which each version is linked to a change request. The process of creating a new instance is started by a change request. A change request defines a set of create, update, and delete requests for definitions and relationships associated with a particular member of an existing instance.

  The following is a brief functional description of how the components of FIG. 5 work together. Describe the environment where operators or administrators can deploy applications, such as data center topologies. The operator or administrator creates an SDM file that describes the environment, which is called the "Logical Infrastructure" (LIM) 502, or data center description or data center model. The SDM file can be generated using any of a variety of development systems, such as the Visual Studio® development system available from Microsoft® Corporation of Redmond, Washington, USA.

  In addition, application developers can design and develop their applications using any of a variety of development systems, such as the Visual Studio® development system. The developer can validate the application description against the data center description 502 by defining the components of the application and how these components interact. This is also referred to as “design-time validation”.

  When the application is complete, the developer saves the description in the SDM and requests packaging of the application so that the application is deployed as SDU 504. The SDU contains the application SDM and the application binaries and other reference files used to install the application.

  The LIM 502 and SDU 504 are provided to a deployment tool 506 of the controller device 520 for deployment. The deployment tool 506 includes a user interface (UI) that allows an operator to load a desired SDU 504. The deployment tool 506 cooperates with the CR generation module 530 to install an application related to the SDU 504 according to the information in the SDM in the SDU 504. Further, SDM definitions and instances from SDU 504 are populated in SDM runtime 510 in SDM store 508. The SDUs are managed by the SDU management module 540 in the SDM runtime 510, which makes the other components of the runtime 510 and the target 522 available to the appropriate parts of the SDU.

  The operator can also specify what action the operator wants to take on a target 522 (eg, a target computing device) to which the application being deployed is to be deployed. The operator can do this via a deployment file, which is also referred to herein as a change request (CR). CR is performed through one or more engines 512, 514, 516, 518. In general, the CR deployment engine 512 deploys the CR to identify all relevant components and their connections and actions. The value flow engine 514 flows values for components (such as connection strings). The constraint check engine 516 checks the constraints between the environment and the application. Action ordering engine 518 specifies the order of all required actions on the CR.

  To initiate changes to the system (including application deployment) or model validation, the operator or process submits the CR. The CR contains the set of actions that the operator wants to perform via the instance in runtime 510. These actions can be, for example, create actions, update actions, and / or delete actions.

  In addition to user or operator initiated change requests, there may be deployment / auto-generated change requests, which are generated as part of the deployment process discussed in more detail below. The change request, regardless of its source, is executed by sending actions such as discovering, installing, uninstalling, and modifying the target instance to the target 522 after being fully deployed and checked.

  CRs are treated as atomic action sets that complete or fail as a group. This allows, for example, the constraint checking engine 516 to consider all actions when testing for validity.

  For design-time validation, the CR will be generated by the SDM compiler 528 and will include one or a minimum of each SDM component in the SDM file. The CR of the instance generation command flows through the CR expansion engine 512, the value flow engine 514, and the constraint check engine 516. Errors found in these three phases are returned to the user via the development system used by the user.

  At the time of deployment, the operator generates a CR with a UI (user interface) presented by the deployment tool 506. The CR flows through all the engines 512, 514, 516, 518 in the SDM runtime 510, and the appropriate actions and information are sent from the CR execution module 532 to the appropriate target 522, where the request is executed. (For example, an application is installed). A suitable target 522 for a particular installation is typically the target where the application will be installed.

  To begin processing the CR, in a definition resolution phase, the CR generation module 530 resolves all definitions and members referenced in the change request. The change request assumes that they have already been loaded by the runtime 510. If they do not exist, CR generation module 530 initiates a load / compile action. The CR generation module 530 also implements a path resolution phase to resolve references to existing instances and instances defined by the generation action in the change request.

  The deployment performed by the CR deployment engine 512 is, for a given change request, a process that populates all remaining actions required to execute this request. Generally, these actions are construction and destruction actions on definition instances and relationship instances. The operator can optionally provide details regarding all actions required to build or destroy the instance, or some of this process can be automated. For example, the operator provides key information regarding changes desired by the operator by identifying an action on a member (eg, a byReference member). Then, for the nested members (eg, byReference and byValue members) and relationships, the remainder of the action is filled. As another example, automated deployments can also refer to an external resource manager, which selects devices with available resources and locates applications that are close to the data it needs A deployment decision can be made based on such things.

  The CR development engine 512 also performs “automatic writing (writing)”. During the automatic description, the CR unfolding engine 512 analyzes the scale-invariant grouping of components and composite components specified in the SDM and how the components are grouped when the components are scaled to the required level. And should be interconnected.

  The CR expansion engine 512 also performs value member expansion, reference member expansion, and relationship expansion.

  Value member expansion refers to identifying all non-reference defined members. Since the cardinality of these members is indicated and all necessary parameters are known, for each member, a creation request is added to the change request for the member whose parent is being created. If the change request includes a destruction operation, the destruction operation is added for all instances included in the change request.

  Reference member expansion refers to reference members (as opposed to non-reference definition members). The cardinality of the reference member is often undefined, and the reference member may have an unfolding setting that requires a value for the instance to be constructed. Thus, the process of expanding a reference member (eg, a byReference member) may require more information about the instance than the runtime can provide.

  Reference member expansion involves a process called discovery, which is the process used to find already expanded instances. Discovery is an action usually initiated by the environment operator. For example, during an install request, the CR deployment engine 512 determines whether the instance already exists, if so, what exists, and if not, creates it. An instance manager (IM) 534 on controller 520 communicates with an instance manager 526 on target device 522 to initiate the discovery process. The discovery process returns data about the instance from the target device 522 to the controller 520.

  The discovery process populates the reference definition members as part of the build or update action. Typically, only the reference members for the object managers that support discovery (the instance managers that also perform discovery) participate in this process.

  When a new instance is discovered, use the instance-specific key value to check that this instance does not yet exist in the SDM database. If a new instance is found, the instance is classified according to the definition of the discovered member. If the instance does not match the member, or if there is an ambiguous match, the member reference is left blank and the instance is marked offline and incomplete.

  Relationship expansion refers to creating a relationship instance that binds the definition instances together after all the definition instances to be built are known. If the definition instance is being destroyed, delete all relationship instances that reference the definition instance.

  To create a relationship, the member space is used to identify the composition of the relationship that must exist between instances. If the defining member has a cardinality greater than one, the topology of the relationship is inferred from the base relationship definition. For example, in the case of a communication relationship, “automatic description” can be performed, and in the case of a host relationship, a host is selected based on an algorithm related to the hosting relationship.

  During the flow stage, the value flow engine 514 evaluates the flow across all relationship instances. The value flow engine 514 can add update requests to change requests for instances affected by the modified parameter flow. The value flow engine 514 evaluates the flow by determining the set of instances whose settings have been updated as a result of the change request. For each of these, evaluate any outgoing configuration flows that depend on the modified configuration and add the target node to the set of modified instances. This process continues until the set is empty or the set contains a cycle.

  After the flow stage, the process of duplicate detection is performed. Duplicate detection may be performed by one of the engines shown in FIG. 5 (eg, value flow engine 514 or constraint checking engine 516), or may be performed by another engine not shown in FIG. (For example, a duplicate detection engine can be included in the SDM runtime 510). The process of duplicate detection matches the deployed instance with the instance that already exists in the SDM data storage. For example, the process detects whether another application has installed the shared file. When an already existing instance is detected, one of several actions can be performed depending on the version of the existing instance. That is, the installation can be failed, the instance can be reference counted, the instance can be upgraded, or the installation can be performed in parallel.

  The constraint check engine 516 performs a constraint evaluation phase. In this phase, all constraints in the model are checked to see if they are still valid after the change request has been processed.

  After the constraint check engine 516 has completed the constraint evaluation phase, a complete action list is available. Accordingly, the action ordering engine 518 can use the relationships between the components to determine a valid change ordering. This determination can be made using any of a variety of algorithms.

  Once the action ordering engine 518 finishes ordering, deployment can be performed by delivering a subset of the machine-specific ordered set of actions. After the actions are ordered and grouped by machine, the actions and a copy of the required portion of the runtime's SDM storage 508, including instance information, are sent to the target computing device 522. The SDM may be temporarily stored in the storage cache 538 of the target device.

  The target computing device comprises a target portion 536 of the SDM runtime that communicates with the SDM runtime 510. Target computing device 522 also includes an agent, which includes an execution engine 524 that communicates with an appropriate instance manager (IM) 526 on the target device to target changes such as create, update, delete actions, and the like. Can be done against Each action is sent to the instance manager 526 as an atomic call. The instance manager 526 returns a status message and, depending on the action, also data (eg, in case of a discovery). When all actions are completed on target 522, the target agent returns an error, if any, and status to controller 520. Controller 520 then uses this information to update runtime SDM storage 508.

  As discussed above, changes are made by breaking the change request into deliverables based on the affected relationships. When all parts are complete (or after one or more parts have failed), the results are matched in runtime 510 and a summary is returned to the operator. In case of failure, all actions can be "rolled back" and the system can be returned to its state before the change was initiated.

  In some embodiments, during the design-time validation discussed above, the SDM compiler 528 receives the SDM file, generates a test CR, and tests it through the SDM runtime's deployment engine, value flow engine, and constraint checking engine. Executes the CR and returns any errors to the development system. This process provides developers with SDM validation for deployment during design time.

The public interface to SDM runtime 510 and / or controller 520 is through an object model (API) library. This library is a managed code object model that enables the following items to be implemented.
Manage the SDM in runtime. -SDM files can be loaded at runtime. SDMs are immutable and are loaded one at a time (ie, load one SDM file rather than just a portion of the file (eg, each individual definition, class, or mapping from the SDM file). can do). The SDM can be deleted from the runtime and an XML document can be created for the SDM in the runtime.
Managing SDUs known by the runtime.
-Manage SDM definitions. Find and review SDM elements (from SDM loaded at runtime). There is no public API provided for authoring new SDMs (ie, this is a read-only object model for SDM invariants). This includes SDM, SDU, identification, version, class, definition, binding / mapping, and versioning policy.
-Manage SDM instances. -Find and review instances of components, endpoints, resources and relationships. In the instance space, each instance can be identified by a GUID, stable path, or array-based path. Paths are strings and can be relative. These identifiers, including the relative path, allow instances to be found and referenced in documents such as change request documents.
-Operate the instance. Make changes to the SDM instance, including creation, topology change, upgrade, configuration change, delete. Instance changes are made within the scope of a change request, which provides an atomic unit of update so that any error or constraint violation causes the request to fail altogether. The instance request also allows the instance to exist temporarily without binding to the host. This is because the instance must have a host when the request is committed. It also allows many operations that affect the installation or configuration of a single component to take place, and ensures that installation or configuration updates are deferred until commit so that a single update occurs on the component. To The SDM model check is performed before or at the time of committing the change request, and if there is a model violation or a constraint violation, the commit fails.
Load the change request. The change request is a document that presents a set of instance space operations, for example an XML file. This document can be a reusable "script" for creating or deleting an application instance using a relative path.
• Find and review change requests. -Include install / update tasks and all error information, and retry install / update of components affected by the request.
Generate a change request document from the change request in the database. Such documents are somewhat portable.
Sign up for notifications of events related to change request tasks, such as progress, logs, or updated status. The lifetime of these event subscriptions is limited by the lifetime of the process that loaded the client library (ie, they are periodic CLR events).

  The SDM runtime engine performs inference on SDM models and functions exposed by the API. The library communicates to the runtime engine as a web service using fairly coarse-grained calls, such as loading the SDM, creating component instances, and getting the entire SDM (to consider the SDM entity). The format of many parameters for this web service is XML with the same schema as for SDM files. The engine may also perform a check for permission.

Controller 520 can utilize an instance manager (IM), which can be associated with any definition or relationship in the model. An IM may perform one or more of the following roles.
-Supports instance deployment.
Supports instance validation after an instance has been deployed (audit).
-Supports discovery of deployed instances that have not been deployed via the runtime.
・ Supports the flow of setting values.
・ Supports constraint evaluation.
-Support the deployment of change requests.
Support for presenting instances as CLR classes to users via APIs.

For deployment, an instance manager (IM) plug-in on controller 520 is associated with the class host relationship, which provides the design experience for the classes used in the development system, and is used in SDU 504 and configuration. It is separate from the plugin that creates the relevant binaries in the schema. The instance manager is provided to the SDM runtime 510 as a CLR class that implements the instance manager interface or inherits from an abstract class (eg, in a dll assembly). The SDM instance manager, also called an instance manager (IM) plug-in, provides the following functions to the controller 520.
Generate files and commands (tasks) to install, uninstall, or reinstall component instances on their hosts. -When a change request results in a new component instance or a component change that requires the removal or uninstallation and reinstallation of the component instance, the instance manager may define the instance, host instance, component related definitions in the SDU 504, etc. Utilizes the binary settings related to the definition of the to create the files and commands needed to perform an installation or uninstallation on a target server that is ready for manual execution or dispatch via the deployment engine.
A component instance when the configuration of the component instance changes, or when the view from one of its endpoints changes (eg due to a change in the communication relationship topology or the visible endpoint has a configuration change). Generate files and commands (eg, tasks) to update

Map the endpoint instance visible on the component instance endpoint to the settings on the component instance. -In SDM, component instances have endpoint instances in which other endpoint instances are visible as a result of some communication relationship topology. The details of the other endpoint instance are mapped to settings that the component instance can fetch at runtime, and thus can usually bind to it. For example, a website has a database client endpoint, so that communication relationships can be established using a database. When properly established, the database client endpoint can see a single database server endpoint instance and settings on this server endpoint. This information is used by the instance manager to place a connection string for the server in a configuration file, named client endpoint. As a result, the code simply reads the connection string for the database from its configuration settings.
Generate files and commands (tasks) for auditing component instances. -Audits confirm existence and correct settings. This can also be applied to host instance settings.
-Report status for any task. -IM transforms some or all of the captured output and provides the status of the task as successful, failed or incomplete, optionally progress on incomplete (% or final response), on failure Provides details (error messages) and human-readable logs for any status. By returning to the instance manager and interpreting the output of the task, the instance manager does not have to create enough logs for diagnosis and keeps it readable by humans, but (For example, XML, or SOAP (Simple Object Access Protocol)).
-The instance manager can also provide code to perform constraint checks between the host and their guests. The installer can use a common constraint language, for example, a language based on XML, XPath, XQuery.

Exemplary SDM Implementation The following discussion describes one embodiment of a schema that defines the elements of SDM.

  1 Definition

2 Architecture Overview The System Definition Model (SDM) is designed to support the description of the composition, interaction, and change of components in a distributed system (modeling system).

  SDM is based on an object relationship model. Objects are used to describe the entities that exist in the system, and relationships are used to identify the links between them. In SDM, objects and relationships are further refined to capture semantics important to SDM. Specifically, objects are divided into systems, endpoints, and resources, and relationships are divided into communication, containment, hosting, delegation, and reference.

  Describe the architecture of your feature. Include any necessary block diagrams. Describe the components (which identify what will be changed or left by this feature), internal interfaces, data flows, and other interactions.

  Use abstract definitions to provide common categorization of parts of the system. This allows tool support for a wide range of applications and provides the basis for type checking at design time. The set of abstract definitions is considered to provide a comprehensive basis for system design, and these are expected to change slowly over time.

  Build concrete object definitions that represent parts of the actual application or data center design. Using the abstract object definition, provide an implementation that defines concrete type members and their property setting values. Next, a system is constructed from the set of these definitions.

  Use constraints to model the limits on the set of allowed relationships that an instance can participate in. Constraints are used to capture fine-grained requirements depending on the composition of the objects involved in the relationship. For example, constraints can be used to validate that participants at both ends of a communication protocol are using compatible security settings.

  To make changes to the target system, the SDM uses a declarative description of the required change, called a change request. SDM defines the processes used to deploy, validate, and execute change requests as part of the SDM execution model.

  The instance space captures both the desired state and the current state of the managed application. Changes in the instance space are tracked and associated with the change request that initiated the change.

  Subsequent unified modeling language (UML) diagrams capture extensive interaction between objects in the SDM model. For simplicity, some of these conversations are defined between base types, but the actual conversations exist between derived types, and as a result are more specialized. For example, a communication relationship may reference only an abstract endpoint definition.

  An SDM document contains information describing the document, a manager for the definitions in the document, an import statement referring to other documents, and a definition set.

  FIG. 6 shows an exemplary document.

  As shown in FIG. 7, all SDM definitions are derived from a common base definition and can include members. The relationships between definitions and members can be more complex than those shown in subsequent figures.

  As shown in FIG. 8, members are classified according to the type of definition to which they refer.

  The setting declaration refers to the setting definition. As shown in FIG. 9, the setting value and the value list provide values for the setting.

2.1 Life Cycle of an SDM Application FIG. 10 illustrates an example SDM application life cycle according to some embodiments.

  The application is designed and implemented within the Visual Studio® environment (block 1002). Developers implement the components and then combine them in a composite component. The application is described in the SDM file. To verify that the developer's application is deployed in a particular data center, the developer binds the application to a data center representation also described in the SDM file (block 1004). This representation includes a definition of the developer's application component host and constraints on the configuration of the developer's application. If the binding fails, the developer can modify the application design.

  If the developer is satisfied with his application, he can sign and publish the application, and thus the application is now associated with a strong name and version (block 1006). The published form of the application is called a software distribution unit (SDU). The operator takes the SDU from the developer and loads the application into the SDM runtime (block 1008). During the process of loading the application, the operator selects the model of the data center to which he wants to bind the application. If the operator decides to deploy the application, it supplies the deployment parameters to the application and determines the scale of the application (block 1010). This is done using change requests.

  Upon deploying the application, the operator can interact with the runtime to determine the configuration of the application and the settings for each portion of the application (block 1012). The runtime may also verify that the actual configuration of the application matches the desired configuration recorded in the runtime. The operator can delete the deployed application by submitting a change request (block 1014). The operator can also roll back individual changes made to the running application, such as deleting a service pack. At block 1016, the configuration of the running application can be changed by adding or removing portions of the deployed application, such as from a web front end. Applications can also be upgraded by installing newer versions of one or more application components.

2.2 Abstract Object Definitions and Relationship Definitions Abstract object definitions define the building blocks required to check the application configuration at design time and then deploy and manage the application at runtime. These building blocks represent entities that exist in the modeling system. For example, the abstract object definitions are used to model files and directories, configurations inside web servers, or databases inside SQL servers.

  Abstract relationship definitions are used to model possible interactions between abstract object definitions. Relationships are binary and directed and identify object definitions that define the instances that participate in the manifestation of the relationship. Relationships provide a way to connect objects together so that the containment, construction, and communication links between objects can be modeled.

  The object then uses the constraint to constrain the participating relationships of the object, and the relationship uses the constraint to constrain the objects that can be linked. These constraints can target both the definition and setting of participants in the relationship. This allows the constraint to limit participants to the relationship to instances that derive from a particular definition and may require that instances have settings that fall within a particular range.

  Object definitions fall into three categories: systems, endpoints, and resources.

  Abstract system definitions are used to describe self-contained and independently deployable parts of an application. These definitions represent the parts of the application that interact via well-defined communication channels that can cross process and machine boundaries.

  Abstract endpoint definitions are used to describe the communication endpoints that the system can expose. These are used to model all the forms of communication that the system must be aware of to verify system connectivity at design time and to enable connectivity at runtime.

  An abstract resource definition describes the behavior contained in the system. Resource definitions may have strong dependencies on other resource definitions. These dependencies can include requiring a particular installation order, or initiating a runtime interaction via a communication mechanism that is not officially documented.

  All abstract object definitions share the ability to disclose settings. These settings are simple name-value pairs and use an XML schema to define the type of the settings. The setting can be dynamic or static, but if static, it can only be set during the deployment process; if dynamic, it can be changed after deployment. The code responsible for applying the settings to the running system is hosted in the SDM runtime.

  SDM supports inheritance over abstract object definitions. A derived definition can extend the properties disclosed by its parent and set values for properties of its parent. A derived definition can participate in any of the relationships that identify its parent as a participant.

  Relationship definitions fall into five categories: communication, containment, delegation, hosting, and reference.

  Communication relationships are used to capture possible communication interactions between abstract endpoint definitions. Having a communication relationship indicates that the system disclosing the identified definition endpoint may be able to communicate. The actual link establishment is constrained by the endpoint and the exposure of the endpoint.

  The containment relationship states that an abstract object definition can include members of another abstract object definition. More specifically, in the containment relationship between two abstract object definitions A and B, a concrete object definition that implements A can include members of a concrete object definition that implements B.

  Containment is used to model the natural nesting that occurs when developers build applications. By including member objects, the parent can control the lifetime and visibility of the included objects. All object instances in the runtime space exist as members of other object instances, forming a fully connected instance set. Thus, a set of containment relationships describes the allowed containment patterns that occur in instance space.

  Delegation relationships are used to selectively disclose the contained object members. Specifically, delegation is used to disclose endpoint members from the system definition. By delegating the endpoint from the subsystem, the outer system presents the ability to communicate on a particular protocol without disclosing the implementation behind the protocol.

  Hosting relationships and reference relationships are two forms of dependency relationships. Hosting relationships describe key dependencies between abstract objects that must exist before an instance of a concrete object can be created. Every instance should participate as a guest in exactly one hosting relationship, so that the hosting relationship also forms a fully connected tree over the instance space. Reference relationships capture additional dependencies that can be used for parameter flow and construction ordering.

2.3 Concrete object definition and relation definition A concrete object definition is constructed from an abstract object definition, and a concrete relation definition is constructed from an abstract relation definition.

  The combination of the abstract object definition and the abstract relationship definition defines a schema for modeling the target system. The role of a concrete object definition is to use a subset of the abstract definition space to create a reusable composition based on one or more abstract definitions. As a simple analogy, an abstract definition space can be compared to a schema for a database. In this case, the concrete object definition will represent a reusable template for a set of rows in the database. A row is created in the database only when an instance of a concrete object is created. Validate a concrete object definition against an abstract definition space in the same way that a row in a database is validated against a schema constraint (eg, a foreign key) for design-time validation. Can be inspected.

  Each concrete object definition provides an implementation for a particular abstract object definition. The implementation includes extensions to the settings schema, values for settings, and declarations for object members, relationship members, constraint members, and flow members. The behavior of a concrete object follows the definition of an abstract object. That is, the abstract system definition becomes a concrete system definition, the abstract endpoint definition becomes a concrete endpoint definition, and the abstract resource definition becomes a concrete resource definition.

  Each concrete relationship definition provides an implementation for a particular abstract relationship definition. Implementations can include configuration declarations and values, nested members of the same relationship category (hosting, containment, communication, etc.), and constraints on the types that can participate in the relationship.

  Concrete hosting relationships are used to define the mapping of members of one concrete object onto another concrete object. For example, a concrete hosting relationship can be used to identify the binding between the web application and the IIS host where it will be deployed. There can be multiple concrete hosting relationships for a given type, which allows developers to define various deployment configurations for a particular topology.

2.4 Members Concrete types can declare members of other concrete or abstract objects. These are called object members. In this case, these members are referenced from relationship members that define the relationship between object members.

  Object members are used to create instances of a particular object definition. The configuration flow can be used to provide values for the object. When declaring an object member, the user is asked whether the object member is to be created at the same time that the outer system is created (value semantics) or by some new explicit action to be taken later (see Semantics) can be determined.

  Relationship members define the relationships they will participate in when the object members are created. If the object member is contained in its parent, declare the containment member between the type member and the outer type. If the object members are delegated, delegate relationship members are defined between the object members and the nested object members. Communication relationship members can be declared between endpoints on object members, and dependency relationship members (reference and hosting) can be declared between object members or nested object members.

  Relationship constraints are used to limit the set of relationships that a particular object wants to participate. These identify constraints on a particular relationship and constraints on participants at the other end of the relationship.

2.5 Instance Space The instance space stored in the SDM runtime reflects the current state of the modeling system. The runtime contains a complete record of the instances created and the relationships between these instances. Each instance is associated with a version history in which each version is linked to a change request.

  The process of creating a new instance is started by a change request. A change request defines a set of create, update, and delete requests for types and relationships associated with a particular member of an existing instance. Routes are a special case.

  Change requests are deployed by the runtime and validated against all constraints before being built. The deployment process identifies the object instances and relationship instances contained in the object that are implicitly constructed as part of the object construction request, and then evaluates the configuration flow across all relationships. The verification step checks that all required relationships exist and that the relationships satisfy all constraints. Finally, the build process determines the proper ordering for deployment, update, or deletion of each instance, and then passes each instance in the correct sequence to the instance manager so that the appropriate action is performed.

2.6 Layering The goal of the SDM model is to allow for a separation of concerns between application developers, software infrastructure designers, and data center builders. Each of these groups focuses on a particular service and has a different set of dependencies.

  For example, developers mainly care about configuration and connectivity between hosts on which they rely, such as SQL, IIS, CLR, and the like. The designer of the host configuration cares about the network topology and the operating system (OS) configuration, and the builder who develops the network topology, the OS configuration, and the storage mapping needs to know the hardware existing in the data center.

  To support this separation of concerns, SDM presents the concept of layering. Layering binds an application to a service using a hosting relationship without declaring the services that the application depends on as part of the containment structure of the application.

The following four layers are identified as part of the SDM model.
Application Layer The application layer supports building an application in a restricted context. The context is defined by the configuration of the host defined in the host layer.
-Examples of system definitions in the application layer include web services, databases, and BizTalk (TM) schedules.
Host layer-Build a data center from software components. Configure connections between components. Some of these components act as hosts for the application layer.
-Examples of system definition in this layer-IIS (trademark), SQL, AD, EXCHANGE, DNS (Domain Name System), BizTalk (trademark)
Network / OS / Storage Layer Build data center network and platform. Configure the network security model and operating system platform configuration. Add storage to the operating system configuration.
-Example of system definition in this layer-VLAN, Windows (registered trademark), Filter, Storage
Hardware Layer The hardware layer identifies the types of machines that exist in the data center and the physical connections that exist between these machines.

  FIG. 11 shows an example of mapping a layer 4 web application to a layer 3 web server host. The box outside each layer represents the system, the box on the border represents the endpoint, and the box inside represents the resource. Each of these elements is mapped to a host at a lower layer via a hosting relationship.

  Bind this system to a host system with matching features to satisfy the required relationships for the system. This process is called placement. At design time, build concrete hosting relationships that represent possible locations. Upon deployment, instantiate a concrete hosting relationship instance and bind the guest system instance to the host system instance.

2.7 Model Evaluation The SDM model is associated with a well-defined process for managing changes to the distributed system.

  Each change is driven by a declarative change request that goes through a number of processing steps, after which the requested action is delivered and then performed on the target system.

3 Implementation details Describe the implementation details of this design. For example, how each component works, what low-level algorithms are, what classes and data structures are important to the implementation, and so on. By reading this, someone must be able to fully understand your implementation without having to read your code.

3.1 Naming There are several places in the SDM where a strict naming system is needed to identify objects. The following naming system allows a type creator to sign a definition in such a way that the user of the definition can be assured that the definition is the same as the definition originally published by the developer.

  The following header is an example of an identifier in the SDM namespace.

To reference a type in another namespace, you need to import that namespace.
<import alias = ”FileSystem” name = ”FileSystem” version = ”0.1.0.0” publicKeyToken = ”AAAABBBBCCCCDDDD” />
The alias can then be used to refer to the type in that namespace.
FileSystem: file

3.1.1 Identification SDM names cover the namespace in which they are defined. Namespaces are identified by name, version, language, and public key token and are contained within a single file.

The basic forms of identification include name, version, culture, platform, and public key token.
<xs: attributeGroup name = ”Identity”>
<xs: attribute name = ”name” type = ”simpleName” use = ”required” />
<xs: attribute name = ”version” type = ”fourPartVersionType” use = ”required” />
<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: attributeGroup>

  The base identity can be used to reference an existing identity, or a new strong identity can be generated along with the signature and public key. The document will be signed using the private key so that the user of the document can verify its contents using the public key.

The public key token is a 16 character hexadecimal string that identifies the public part of the public / private key pair. This is not a public key, but simply a 64-bit hash of the public key.
<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] | [af] | [AF]) {16}” />
</ xs: restriction>
</ xs: simpleType>

3.1.2 Version The file version is N.D. N. N. It is defined by a four-part number in the form of N, where 0 ≦ N <65535. By convention, this number is a measure. minor. Build. Represents a revision.

3.1.3 Simple Names Simple names consist of alphanumeric characters and limited punctuation. The name must begin with a non-numeric character.

  The identifier will be based on the C # definition. An appropriate section (2.4.2) is inserted below. The specifications can be found below.

http: //devdiv/SpecTool/Documents/Whidbey/VCSharp/Formal%20Language%20Specification/CSharp%20Language%20Specification.doc
Note that the SDM model does not support names prefixed with "$".

3.1.4 Reserved Names The following is a list of reserved names that users cannot use when generating names for objects in the SDM model.

  Some names are reserved in certain contexts.

  The following names are reserved for integration with the CLR.

3.1.5 Referencing Other Namespaces It is possible for a namespace to reference another namespace by importing the other namespace into the current namespace and then associating the alias with the namespace. The imported namespace is referenced by name, version, and public key token. Versioning is described in Section 3.16.

3.1.6 Qualified Path A qualified path is in this case a name that points to either the definition and the manager defined in the current namespace or in the aliased namespace.
[<alias>:] <simpleName> (. <simpleName>) *
Aliases are defined in import statements. The following simple names identify the type, and in the case of a path, the nested type.

3.1.7 Definition and Member Path A path is a series of names that identify a member or setting. The path should begin with a well-known name or member name defined by the object or relationship associated with the path.

3.1.8 Instance Path The path in the instance space is based on XPath. The element names in the XPath correspond to the member names, and the attributes in the XPath correspond to the settings.

3.1.9 Name Resolution Names that do not begin with an alias are not fully qualified. This means that the extent to which they are evaluated can change the resulting binding. One example of this is a nested definition. When resolving nested definition names, definitions in the local scope hide definitions in the wider scope.

3.2 Settings All definitions can disclose setting declarations. These settings can be used to describe the values that can be provided when generating a concrete definition from an abstract definition, or when referencing a definition from a member in another definition.

  To define a setting, you must first define the definition of the setting using XSD.

A setting that uses this definition and that includes a set of attributes to define the behavior of the setting can then be declared.
<settingDeclaration name = ”valueType” type = ”registryValueType” access = ”readwrite” dynamic = ”false” required = ”true” />
Once the settings declaration is obtained, the value of this setting can be provided.
<settingValue name = ”valueType” fixed = ”true”> long </ settingValue>

3.2.1 Setting Definition The XSD schema is used to define the setting definition used by the setting declaration. Use of simple and complex types from schemas is supported. However, there may be other schema elements that support the definition of these types.

The section of the configuration definition should include the complete XML schema, including namespace declarations and namespace imports. Check that the import in the XSD schema matches the import in the SDM file except for the namespace of the XSD schema. This means that all referenced types should be defined in another SDM file. A schema cannot reference types defined in a discretionary XSD file.
<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>

The settings should be resolvable from the following three separable namespaces:
a) SDM namespace-when referring to a system, resource, endpoint, relationship, constraint, or configuration type within a flow type.
b) CLR namespace-when referring to settings that use strongly typed classes in the CLR, and when setting types are built on other setting types.
c) XSD namespace-when a configuration type is built using other configuration types.

In order for this to work, there should be some restrictions on how the settings are declared.
a) All settings should be in the same group within the CLR, SDM, and XSD namespaces. That is, if two settings are together in one namespace, they should be together in all three namespaces.
b) The imported namespace in the XSD schema definition should match the imported namespace in the SDM file, and the imported namespace in the associated helper assembly.
c) Except for the XSD namespace, all imported namespaces in the XSD schema should be defined in the SDM file.

The XSD type from the imported SDM document is accessible using QName.
<alias>: <type-name>
Therefore, for example, as shown in the following example, Foo. sdm is Bar. When importing sdm, Bar. The setting type of sdm is Foo. It can be referenced in the sdm settingTypes element.
<!-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. Built-in Simple Data Types SDM supports a limited set of built-in data types that are a common part of the XSD and C # namespaces. These types are supported natively by the SDM runtime and are defined in the table below. In addition to these types, the user is free to build and use his own mapping between XSD and CLS types.

  These types can flow to compatible derivatives of these types in the C # and XSD type spaces. For example, the value of string can flow to an XSD type that defines restrictions on strings, and the value of any can flow to a setting that accepts type = "any".

3.2.2.1 XSD Embedded Type FIG. 12 illustrates an exemplary embedded data type hierarchy.

  3.2.2.2 C # data type

3.2.2.3 Supported Conversions The following are the conversions that exist between the XSD and CLS types.

3.2.3 Configuration Declaration The configuration declaration section uses the configuration declaration from the previous section to generate a named configuration. Use attributes to further provide information about each setting.

3.2.4 List Support A simple list of settings is supported to support the operation of multi-value settings. A list is a sequence of values with the same definition as a setting declaration. A list can flow to another list that can be replaced or merged. Duplicate detection when merging values into a list is not supported. This is because this can be done more flexibly using the configuration flow. Also, no form of ordering is supported.

The list declaration includes the attribute list set to true as follows:
<settingDeclaration name = ”roles” type = ”xs: string” list = ”true” />
The value is then provided using the settingValueList. When providing a list, the user can specify whether to replace or merge with previous values.

  SDM supports simple manipulation of lists of values. When a path from a flow member targets a configuration declaration, the resulting behavior depends on the definition at either end of the path.

3.2.5 Configuration attributes Configuration attributes are used by the runtime to describe the behavior of a particular configuration.

3.2.6 Setting Values Depending on whether the setting is declared as a single value or as a list, the value for the setting may be provided using either the setting element or the setting list element. it can.

3.2.6.1 Setting Value Setting value is used to provide a value for a specific setting declaration. The value should match the definition associated with the declaration. If the value is declared fixed, the value provided will be used in all derived definitions or in referenced members, depending on the point at which the value is fixed. Once the value is fixed, it cannot be overridden.

3.2.6.2 Settings List The settings list is used to provide one or more values for the settings declared as a list. When declaring a value, the user can decide to merge with the previous value or overwrite all previous values.

3.2.7 Setting inheritance Setting inheritance means that the derived definition implicitly includes all setting declarations from the base definition. Some of the important aspects of setting inheritance are:
・ Setting inheritance is transitive. If C derives from B and B derives from A, C inherits the settings declared in B as well as the settings declared in A.
A derived definition can add new setting declarations to the setting declarations inherited from the base definition it extends, but cannot delete the definition of the inherited settings.

3.2.8 Type Conversion Lossless conversion between built-in types is supported. Other type conversions require a flow to perform the appropriate conversion.

3.3 Attributes Many of the objects in the SDM can be attributed to capture behavior orthogonal to the core behavior of the object. A general attribution model defined as follows is used.

3.4 Definitions and Members 3.4.1 Definition Definitions are the basis from which object definitions, relationship definitions, constraint definitions, and flow definitions are derived. All definitions can include setup schema and design surface data. Each definition is identified by a simple name and references a manager. The manager is responsible for providing extended support to the SDM runtime for this particular definition.

The configuration schema defines the values found on instances of this definition. Use the DesignData element to include data specific to displaying and editing this definition on the design surface.
<xs: complexType name = ”Definition”>
<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 = ”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 = ”optional” />
</ xs: complexType>

3.4.2 Members Members are used to identify definition instances that can exist at runtime. All members are identified by unique names within the type, can provide settings for the definitions they reference, and can include design surface specific data.

3.5 Configuration Flow The configuration flow is used to pass parameters between members of an object definition and between participants in a relationship. As part of the flow, the user can combine or separate the settings using transformations and calculate new settings.

  All configuration flow members implement the transformation using the flow definition. Flow definitions are declared in the SDM file. The following is a flow type for analyzing a URL (Uniform Resource Locator).

  Then, declare the flow members in objects or relationships. The flow member provides the input to the flow definition and then sends the output from the flow to target settings.

3.5.1 Flow definitions Flow definitions are used to define the specific transformations that you want to apply to a set of configuration values. The flow definition is used when browsing SDM files, including input settings (write-only settings) and output settings (read-only settings), and configuration data sections for information specific to the design surface, such as input interfaces for defining transformations. Disclose a configuration schema that defines the description to be made. A flow definition is identified by a name in the namespace in which it is defined. The definition also identifies the manager that will support the runtime when it evaluates the flow.

  To simplify the construction of flow elements when simple transformations are needed, the runtime is considered to include some standard flow definitions. Examples include copy, merge, and string substitution. Since the flow definition can be parameterized, there may be one or more simple variants that perform different actions based on the configuration parameters.

3.5.2 Flow members Each flow element identifies one or more source nodes, one or more destination nodes, some static settings, and a flow definition. When a flow is evaluated, source data is collected from source nodes, combined with settings from the flow elements, and passed to the flow definition for transformation. The output data is passed to the destination node.

  When one of the source values changes, a re-evaluation of the flow is triggered. For this reason, it is necessary to avoid circulating flows that cause value inversion. If the value remains constant, the loop ends. The runtime detects and terminates an infinite loop by keeping track of the stack depth.

3.5.3 Configuration Target The configuration target identifies the path to the configuration value in a member or nested member associated with a name that is well known in the context in which the flow is defined. Examples of well-known names include this in a definition or reference declaration, host and guest in a hosting relationship declaration, or target defined in a constraint declaration. The configuration target also identifies settings on the associated flow definition that will be used as either the source value or the destination configuration of the configuration identified by the path.

  An output path is a variant of a set target that supports the semantics for fixing and replacing target values.

3.6 Setting Constraints Constraints are used to identify restrictions on the settings of members of a definition, or on participants in a relationship. These limitations are evaluated in instance space, both at design time and at deployment time.

  All configuration constraints evaluate the configuration values using the constraint definition. Constraint definitions use configuration declarations to identify the values they constrain. The following constraint definition implements a simple comparison function that utilizes two arguments and one operator, then evaluates the constraint, and finally returns success or error.

  The constraint members are then used to provide values to the constraint types for evaluation.

3.6.1 Constraint definition A constraint definition defines a constraint that acts on a set of input values. Constraints can be parameterized to select a custom behavior, or a simple constraint engine that uses parameters to define that behavior can be supported. In order to support known relationships between abstract objects, a standard set of constraint definitions could be written for simple parameter value constraints and complex constraint sets.

3.6.2 Constraint Member A constraint member identifies a set of input values for a particular constraint definition. Members can identify static values for settings and bind constraint settings to paths using input statements.

3.7 System Endpoint Definitions and Resource Definitions This section describes the schema for abstract and concrete object definitions.

  An abstract object definition discloses a set of configuration declarations, which can include constraints on the relationships it participates in, and has an associated manager in the runtime.

  The following is an abstract system definition for a web server. The web server has two settings and has a relational constraint that requires it to include at least one vsite type.

  vsite is an abstract endpoint definition including server binding information.

A concrete system definition for a front-end web server includes a single byReference endpoint member that can identify a web server category as static content and represent between 1 and 100 endpoint instances. The concrete endpoint definition for the endpoint is nested inside the system definition and defines ip Endpoint for vsite as Endpoint80.
<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 Object Definitions Abstract and concrete objects extend the following base object definitions. In addition to the elements of the base type definition, they also share the ability to constrain the relationships in which objects participate.

3.7.2 Abstract object definition The abstract object definition is used to define the structural unit that the design surface discloses and that is the source of all concrete objects. That is, a concrete object definition should implement an abstract object definition.

  Abstract object definitions extend SDM objects by adding simple inheritance. That is, the extend attributes attribute is used to identify the base object definition for the abstract object definition. The abstract object definition then inherits the settings and relationship constraints from the base object definition. Through inheritance, an object definition can extend the settings and constraints of an abstract object definition by adding new settings and constraints.

  Abstract object definitions can also add constraints on the relationships they want to participate in. For example, an abstract object definition may require that certain relationships exist, or may constrain the object definitions that can be placed at the other end of the relationship, or on an instance that participates in a given relationship. Can be restricted.

3.7.2.1 Abstract Object Definitions All abstract objects can identify the layer to which they want to be associated. If this is not provided, the object definition is assumed to be usable at any layer. Abstract object definitions can identify the base object definitions that they extend, in which case they inherit the settings and constraints of the object definition and replace the base object definition in the relationships in which the base object definition participates. Can be.

3.7.2.2 Abstract Endpoint, System, and Resource Object Definitions There are three categories of abstract object definitions in the SDM model. That is, an abstract endpoint definition, an abstract system definition, and an abstract resource definition. Each of these is a simple rename of an abstract object definition.

  The endpoint definition represents a communication endpoint. The settings on the endpoint relate to its use in the binding process. For example, in the case of a client-server protocol, the server endpoint definition can use a configuration schema to identify the settings needed to bind to the endpoint, and the client endpoint definition discloses client-specific connection attributes can do.

  System definitions are used to represent sets of data, software, or hardware elements. Examples include web services, databases, and switches. Resource definitions are used to capture specific elements that can be identified as part of the system definition.

3.7.3 Implicit Base Definition As shown in Figure 13, all abstract objects that do not extend another abstract object definition implicitly extend one of the endpoint, system, or resource base definitions. I do. These base definitions form the root of each tree that can be used in relationship and constraint declarations. This allows the relationship or constraint to indicate that any type derived from the root can be used in place of the identified route definition. These root types are always abstract and cannot be directly instantiated.

  The definition of these types includes the base constraints that control their instantiation in the model. These are described in System. sdm. You can see it in

3.7.4 Concrete object definition A concrete object definition provides the implementation for an abstract object definition. The implementation is built from object members and relationship members, values for the settings of the abstract definitions to be implemented, new setting declarations, and flows between members and constraints on members.

  Concrete definitions can also include nested definition declarations. These definitions can be used for members within the containing definition and can be referenced in constraints outside the definition.

3.7.4.1 Base Concrete Object Definition The base concrete type is the ability to provide values for object definitions, inherited configuration declarations, design data, optional manager references, names, constraints on participating relationships, and settings for abstract definitions. Extend the ability to describe the flow between its settings and its members. The concrete definition then adds the ability to identify the abstract definition to implement, and some optional attributes add the ability to customize the binding behavior of the definition.

3.7.4.2 Object Members Object members should reference either abstract or concrete object definitions. These can represent an array of instances, in which case the upper and lower bounds of the array can be defined. If they are reference members, the user instantiating the object should explicitly construct an instance for the member. If it is not a reference member, the runtime will instantiate it at the same time that the outer object is created.

  In the SDM model, members that are created when the parent is constructed and destroyed when the parent is destroyed need to be distinguished from members that have a lifetime regardless of the parent. For this purpose, the IsReference attribute is used. In a simple analogy, it is similar to a C ++ declaration that allows stack-based and heap-based constructions based on whether new is used to create instances. If a member is marked as IsReference, the operator needs an explicit new operation to instantiate and associate with the member.

There are several reasons for doing this.
1. It is disclosed that when an operator builds a system, an IsReference member can be built. This greatly simplifies the operator experience.
2. When an SDM document is processed, there are clear boundaries where the instance space of the document can change from the instance space of the concrete definition space.

3.7.4.3 Relationship members Relationship members identify the relationships that exist between object members when the object members are created. Relationship instances are either explicitly created by the operator or implicitly created by the runtime. The former example is a hosting relationship between instances, and the latter example is a communication relationship between systems.

3.7.4.1.3.1 Hosting Member The host member is used to declare a hosting relationship between two object members. An object member can be a direct member of the containing definition or a nested member that has a membership relationship with the definition. There should be a membership chain between the referenced member and the containing definition.

3.7.4.3.2 Communication Member The communication member is used to declare the communication relationship between the endpoint members of the system member of the definition directly.

3.7.4.3.3 Containment members Containment members are used to declare that a type member is contained by a type. Each type member can be either contained or delegated. The containing member automatically sets the parent value of the containing relationship to the relationship's this pointer.

3.7.3.4.3.4 Delegate Member The delegate member sets up a delegate relationship between an endpoint definition member on the outer type and an endpoint definition member on a direct system member of the outer type. Used for

3.7.3.4.3.5 Reference Members Reference members are used to set up a reference relationship between two direct or nested members of the outer system.

3.7.4.4 Endpoint Definition Endpoint definitions extend the base object by adding the ability to declare nested source types, resource members, host relationship members, containment relationship members, and reference relationship members. .

3.7.4.5 Service Definition System types are for nested endpoints, system types, resource types, endpoint members, system members, resource members, host relationships, containment relationships, connection relationships, delegation relationships, and reference relationships. Extend the base type by adding support.

3.7.4.6 Resource Definitions Resource types can include nested resource type definitions, resource members, host relationship members, containment relationship members, and reference relationship members.

3.7.4.7 Relational Rules For a particular instance of an object definition, the cardinality associated with each role that this instance can play is identified in the following table.

  3.7.4.7.1 System rules

  3.7.7.4.2 Endpoint rules

  3.7.7.4.3 Resource rules

3.7.7.4.7.4 Note Every instance should participate in exactly one containment relationship and at least one hosting relationship.

This means that:
A) Non-referencing members should identify containment relationships.
b) For a reference member to be constructed, the reference member should identify the containment relationship.
c) Reference members that do not have an inclusion relationship can only be delegated to other members.

3.8 Relationships Relationships are used to identify possible interactions between types. These are binary and directed, each identifying a type of instance that can participate in the relationship. Relationships can also constrain the settings of instances that participate in the relationship and can flow settings over the relationship.

  The following are possible hosting relationships for web applications on the web server mentioned in the types section. This relationship includes the constraint of verifying that the security models of the two systems are compatible, and includes a configuration flow member that copies the server name from vsite to vdir.

  Relationships are used by declaring relationship members that identify the type members that will participate in the relationship.

3.8.1 Relationship definition The base relationship definition adds object constraints and flows to the definition. An object constraint is a statement about the settings of an object instance participating in the instance of this relationship. For example, the communication relationship representing a DCOM (Distributed Component Object Model) connection can check that the security settings of the client and the server are compatible. In this case, there is a strict relationship between the settings that can be easily captured as part of the design process. There are four factorial settings combinations for relationships, but the valid combinations are much smaller.

  Flows allow a developer of a relationship to transfer a value from one instance to another. This allows object definitions to be developed separately from their possible interactions, where instances do not require a subset of the relational graph to completely describe a particular instance, but rather reference for information. You can stand alone as a point.

The name of the relationship should be unique within the namespace that contains the relationship.
<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.8.2 Abstract Relationship An abstract relationship is a relationship defined between two abstract object definitions. These represent possible interactions between the two definitions.

3.8.2.1 Abstract Communication Relationships Communication relationships are used to capture possible communication links between endpoint definitions. These are used to describe interactions between independently deployed software elements. The communication relationship schema extends the base relationship schema by adding client and server endpoint references.

  In communication relations, the following combinations of abstract types are effective.

3.8.2.2 Abstract Hosting Relationship The hosting relationship is used to capture the need for a host to be built by a guest. This means that the hosting relationship is also responsible for building guests on the host, since there can be multiple possible hosts for one guest. Therefore, in order to create an instance of an object, there should be a hosting relationship from the guest to the matching host.

  For example, assume that there is a hosting relationship between a web service object definition and an IIS object definition. In this case, assuming that MyWebservice and MyIIs implement web services and IIS, respectively, this relationship may be able to create an instance of system MyWebservice on an instance of system MyIIS using a manager for the hosting relationship. It is shown that. Until we have evaluated the constraints that exist in both the system and the relationship, we do not know if it will be possible to create this relationship.

  For hosting relationships, the following combinations of abstract definition pairs are valid:

3.8.2.3 Abstract Inclusion Relationship The inclusion relationship between two abstract objects captures that a concrete type based on a parent type (parentType) can contain a member based on a member type (memberType). Containment means that the parent instance can control the lifetime of the member instance and can delegate behavior to the member instance.

  In the inclusion relation, the following combination of abstract definition pairs is effective.

3.8.2.4 Abstract Delegation Relationships Delegation relationships are used to transfer behavior from an external system to a contained system. This is done by delegating endpoints on the outer system to endpoints on the inner system. This allows any interaction that would have been directed to the outer system to be effectively forwarded to the endpoint on the inner system. Delegations can be chained so that the inner system can further delegate its behavior to another system.

  Delegation relationships define pairs of abstract endpoint definitions that can participate in delegation. Each relationship identifies an abstract endpoint definition that can act as a proxy and an abstract endpoint definition that can be delegated behavior.

  In a delegation relationship, the following combinations of abstract type pairs are valid.

  Delegation of resources and systems may also be able to support binding between layers. For example, IIS may be able to disclose a portion of a file system without having to deploy it.

3.8.2.5 Abstract Reference Relationships Reference relationships are used to capture strong dependencies between instances in addition to hosting relationship dependencies. These dependencies are used to control the build order during deployment and to flow parameters between systems during installation and updates. Since reference relationships exhibit strong dependencies, it is unacceptable for reference relationships to cross system boundaries. This means that resources in one system cannot have dependencies on resources in another system. With such dependencies, the system is no longer an independent deployment unit. If there are dependencies between systems, use communication relationships. Communication relationships can change over time without requiring reinstallation of the system.

  In a reference relationship, the following combination of abstract type pairs is valid.

3.8.3 Implicit Base Relationships As shown in FIG. 14, all abstract relationships implicitly extend one of the base relationship definitions. These definitions form the root of each relation tree. By doing so, the root definition can be referenced from within the constraint definition, and the common type constraint can be inherited from the root type.

3.8.4 Concrete relationship A concrete relationship is a relationship between two concrete object definitions. Each concrete relationship should implement an abstract relationship. An abstract relationship should be between a matching pair of abstract object definitions that are implemented directly or indirectly (by inheritance) by concrete object definitions.

3.8.4.1 Hosting Relationships When deploying an application to a data center, all outstanding hosting relationships for the systems within the application need to be resolved. To do this, the operator will need to create a hosting member for each required hosting relationship. To simplify the operator's task and allow the developer to guide the deployment process, the developer can create a concrete hosting relationship instead. Grouping a set of hosting relationship members using concrete hosting relationships in such a way that the operator need only declare a single hosting member during application deployment.
<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>

  In the hosting relation, the following combinations of concrete type pairs are effective.

A guest can bind to a host if and only if:
For each guest member in the Guest,
There is one or more hostMembers in the Host, where
guestMember. Type is hostMember. Has a hosting relationship with type
guestMember. hostConstraints is hostMember. have validity for settings,
hostMember. guestConstraints is guestMember. have validity for settings,
For each member of guestMember, there is a binding to a member of hostMember.

For example, the following concrete relationship binds a layer 3 system (Bike) to a layer 2 host (operatingSystem). In this case, the setting related to the hosting relationship is defined by the default value of “system folder”. This setting is flowed to one of three hosting members that define a hosting relationship between the system of the layer 3 application and the system of the layer 2 host.
<HostingDefinition name = ”DefaultBikePlacement” guestDefinition = ”Bike” hostDefinition = ”OperatingSystem: OperatingSystem”>
<settingDeclaration name = ”fileLocationRelativeToRoot” definition = ”xs: sting” access = ”readwrite” dynamic = ”false” />
<settingValue name = ”dirPath”> systemFolder </ settingValue>
<flow name = ”copyPath” definition = ”copy”>
<input name = ”source” path = ”dirPath” />
<output name = ”destination” path = ”bikeExecutableHost.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 = ”bikeSoftwareKeyHost” relationship = ”registryKeyRegistryKeyHost”
guestMember = ”guest.bikeSoftwareKey” hostMember = ”host.Registry.HKLM” />
</ HostingDefinition>

3.8.4.2 Reference Relationships A concrete reference relationship between two concrete types can be used to capture specific dependencies between systems that do not include a communication relationship. For example, for one application to be installed, it can be captured that another application should already exist.

  In the reference relation, the following combinations of concrete type pairs are effective.

3.9 Object and Relationship Constraints Object and relationship constraints define the topology of the concrete space and are used to constrain the settings of an object when it is used in a particular relationship.

  For example, within one abstract object definition (A), one may wish to identify that the implementation of this abstract definition should include one instance of another abstract object definition (B). Assuming that there is already at least one suitable constraint relationship, this would have used a relationship constraint in A that looks like this:

  This constraint identifies that an containment relationship exists where the implementation of A plays the role of parent and the type at the other end (member) of the relationship is type B. If more control over the configuration of B is desired, a constraint on the type B setting can be added as follows.

  In this case, a constraint has been added that requires that the member's name be equal to the string "myPort".

  Constraints can also be added to relationships. These are called object constraints. Restrict objects participating in the relationship from within the relationship. For each role in the relationship, object definitions can be identified, and configuration constraints can then be added to these object definitions. From a relational perspective, the cardinality is always minOccurs = 1 and maxOccurs = 1, so it does not appear in the constraint declaration.

  Finally, constraints can be nested. This allows the constraints to be chained together, with the outer constraints setting the context for the inner constraints. The following is an example of an IIS system hosting a webApp system, which in this case constrains the webApp to include only certain types of endpoints.

  In this case, a group of object constraints is used to specify a set of probabilities where at least one is true.

  Nested constraints form a path that can be evaluated from outside to inside. Each constraint on the path can access the settings of the previous instance on the path as well as the current instance. The evaluation of nested constraints occurs as if the constraints were defined in the identified system.

  The following two scenarios should be equivalent from a foo perspective. In the first scenario, foo places a nested constraint for the included system bar, and in the second scenario, the type bar already contains the constraint.

  Scenario 1:

  Scenario 2:

3.9.1 Constraint Model The constraint model has two parts: guard and predicate. Guards are used to define the context in which the predicate is executed. For example, in a relationship, guards are used to identify specific combinations of types for which one wants to perform a predicate. Within an object, guards are used to identify a set of relationships to other objects.

  The predicate is then executed when those guard requirements are met. Predicates come in two forms. That is, there are a setting constraint for validating a set value and a group constraint for validating a set of constraints.

  Guards can be nested inside guards, in which case the inner guard is checked only when the outer guard is satisfied. This makes it possible to construct a path that supports the verification of the relationship structure.

  The combination of a guard and its predicate can have a cardinality indicating the number of times the guard matches and the predicate is truly evaluated.

  More formally:

  A guard is defined as either an ObjectConstraint or a RelationshipConstraint. An object constraint identifies two object definitions associated with either end of the relationship. Relationship constraints identify the relationship definition and the target object definition. Object constraints can be optional or mandatory, and relationship constraints have lower and upper bounds. This difference in cardinality reflects that relationships can always identify only two types, but types can participate in multiple relationships.

Predicate: == SettingsConstraint (rule) | group {(guard) *}
A predicate is either a configuration constraint containing rules or a group containing a set of guards. Predicates are evaluated in the context of a guard. For configuration constraints, the predicate can identify the configuration from the root guard's owner and the context identified by each nested guard. Groups are used to identify a set of guards that include at least one guard to be matched and truly evaluated.

Example:
1. RelationshipConstraint (containmentRelationship, webapp, 0,1 {}
This example shows a guard that is evaluated as true whenever there is an inclusion relationship with webapp. This guard can be truly evaluated at most once. If there are more matches, an error is returned to the user.

  In this example, a predicate is added to the guard. Guards are evaluated true only when the relationship definition and the target definition match and the configuration constraint evaluates to true. If the relationship definition and the target definition match and the configuration constraint is not true, an error is returned to the user. If the relationship and target type match and the set constraint evaluates to true multiple times, an error is returned to the user.

  In this example, guards are nested inside guards. When the outer guard is true (the type containing the constraint also includes webapp), the inner guard is evaluated in the context of the outer guard. This means that the inner relational constraint is evaluated in the context of the webapp instance. If webApp contains zero or one vdir, the inner constraint returns true. If it contains more than one vdir, the constraint returns an error to the user.

  The context of the object constraint is the primary object definition (first object definition). This means that the relation constraints are evaluated in the context of webapp. Relationship constraints define two possible contexts. The first is the relationship, which is the context for object constraints. Second is the target object definition, which is the context for the relational constraint.

  In this example, a group is used to include two relationship constraints that will be evaluated together in the context of webapp. The group generates an error until at least one of the relationships fires and returns true. In this case, webapp should include either vdir or directory.

3.9.2 Base constraints
<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 Object constraints Object constraints describe constraints on one or both roles of a relationship. The constraint has a name to help identify the constraint if the constraint fails, contains a list of configuration constraints that target the type associated with the role, and derives an instance from the definition associated with the role. You can also constrain it to be an instance of the object.

3.9.4 Object Constraint Group An object constraint group allows a set of object constraints to be grouped together for evaluation using at least one semantics. The group returns an error unless at least one of the object constraints matches the object on the relation and then the predicates contained therein do not evaluate to true. If the type constraint is a direct member of the group, the required attribute on the constraint is ignored.

3.9.5 Relationship constraints Relationship constraints are used to limit the relationships that objects can participate in. Relationship constraints identify the relationship definition and, optionally, the object definition of the instance at the other end of the relationship and the cardinality of the relationship. The constraint is given a name so that the constraint can be identified in the error message. The body of the relation constraint contains predicates on both the relation and the instance at the other end of the relation.

Relationship constraints can be used for several purposes. If we simply use cardinality without adding predicates, they can be used to identify the relationships that must be provided for the instance to work properly. With predicates, this object can be used to limit the set of configurations for the instances that we want to interact with.
<xs: complexType name = ”RelationshipConstraint”>
<xs: complexContent>
<xs: extension base = ”Constraint”>
<xs: choice minOccurs = ”0” maxOccurs = ”unbounded”>
<xs: element name = ”SettingsConstraint” type = ”ConstraintMember” />
<xs: element name = ”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 = ”optional” />
<xs: attribute name = ”MaxOccurs” type = ”MaxOccurs” use = ”optional” />
</ xs: extension>
</ xs: complexContent>
</ xs: complexType>

3.9.6 Relationship constraint groups Relationship constraint groups allow a set of relationship constraints to be grouped together for evaluation as a predicate using at least one semantic. The group returns an error unless at least one of the included relation constraints matches the relation definition and the target object and the predicate contained therein does not return true. If any of the predicates in the included constraints return errors, these errors are communicated to the user. The minOccurs cardinality of the contained relational constraint is ignored, but if the maxOccurs cardinality is violated, an error is returned to the user.

3.10 Object Manager The object manager is the mechanism used by types and relationships to insert custom behavior into the runtime environment. There are several roles that managers can support for each type they manage. That is, it can participate in the installation of types, can provide CLR representations of types, can participate in policy decisions on how to resolve bindings between types, and has complex constraints and flows. Can be provided.

All roles of the object manager are exposed via the CLR as entry points to strongly named classes. The object manager is packaged and versioned like any other type in the SDM. That is, delivered in the system delivery unit, their version and strong name come from the SDM file in which they are declared.
<xs: complexType name = ”Manager”>
<xs: sequence>
<xs: element name = ”Description” 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 = ”optional” />
</ xs: complexType>

3.10.1 Roles An object manager can support one or more roles for each type it supports. These roles include:
a) Evaluation of constraints on types or relationships b) Evaluation of flows on types or relationships c) Construction / destruction / update support on types d) Disclosure of object representations on settings on types or relationships e) Implementation of discovery on types or relationships f) Support for design surface specific UI surrounding types or relationships

3.11 SDM Document Structure An SDM document provides strong identification, versioning, and localization information for a set of relationships, objects, and managers.
<xs: element name = ”Sdm”>
<xs: complexType>
<xs: sequence>
<xs: element name = ”Information” type = ”Information” minOccurs = ”0” />
<xs: element name = ”Import” type = ”Import” minOccurs = ”0” maxOccurs = ”unbounded” />
<xs: element name = ”DesignData” type = ”DesignData” minOccurs = ”0” />
<xs: element name = ”SettingDefinitions” type = ”SettingDefinitions” minOccurs = ”0” />
<xs: choice minOccurs = ”0” maxOccurs = ”unbounded”>
<xs: element name = ”AbstractEndpointDefinition” type = ”AbstractEndpointDefinition” />
<xs: element name = ”AbstractSystemDefinition” type = ”AbstractSystemDefinition” />
<xs: element name = ”AbstractResourceDefinition” type = ”AbstractResourceDefinition” />
<xs: element name = ”AbstractCommunicationDefinition” type = ”AbstractCommunicationDefinition” />
<xs: element name = ”AbstractHostingDefinition” type = ”AbstractHostingDefinition” />
<xs: element name = ”AbstractContainmentDefinition” type = ”AbstractContainmentDefinition” />
<xs: element name = ”AbstractDelegationDefinition” type = ”AbstractDelegationDefinition” />
<xs: element name = ”AbstractReferenceDefinition” type = ”AbstractReferenceDefinition” />
<xs: element name = ”ReferenceDefinition” type = ”ReferenceDefinition” />
<xs: element name = ”HostingDefinition” type = ”HostingDefinition” />
<xs: element name = ”EndpointDefinition” type = ”EndpointDefinition” />
<xs: element name = ”ResourceDefinition” type = ”ResourceDefinition” />
<xs: element name = ”ServiceDefinition” type = ”ServiceDefinition” />
<xs: element name = ”ConstraintDefinition” type = ”ConstraintDefinition” />
<xs: element name = ”FlowDefinition” type = ”FlowDefinition” />
<xs: element name = ”Manager” type = ”Manager” />
</ xs: choice>
</ xs: sequence>
<xs: attributeGroup ref = ”NamespaceIdentity” />
<xs: attribute name = ”documentLanguage” type = ”Culture” />
</ xs: complexType>
</ xs: element>

3.11.1 Information The information section of an SDM document contains human-readable information to support identification and management of the SDM document.

3.12 Change Request FIG. 15 shows an example of a change request. The change request identifies a set of changes to the SDM runtime. All changes to the runtime are initiated using an API that allows the construction of the request or using a change request in XML format.

  The initial request contains a single action group. As requests are processed by the runtime, more structure is added by nested groupings, and more actions are added as a result of the expansion and flow process. A change request that is now ready to be executed on the target machine after this evaluation process is called a fully qualified change request. See section 3.13 for more information.

3.12.1 Consistency Rules When performing an action on an SDM instance space, it validates that all instances in the SDM instance space are in a consistent state after the action is completed. Consistent state means that all constraints that apply to the instance are still valid. For example, if you create an instance of a client that requires a connection to the server, a connection exists between the client and the server even when the sequence of actions used to create and connect to the client is complete. Should.

  The constraints used to evaluate model consistency can be evaluated on an action basis or at the end of a set of actions. The two types of consistency are called operation consistency and transaction consistency.

  If the object becomes inconsistent after the transaction completes, the user can explicitly mark this instance as offline. When an instance is offline, the constraints applied to the instance are not evaluated and the instance does not appear to exist to other instances. This may mean that all of these instances should also be marked as offline. Offline is propagated from parent to child and from host to guest. Thus, marking a system as offline will mark all instances owned by the system as offline and all instances hosted on the system as offline.

3.13 Model evaluation This section describes the behavior of SDM models within the scope of the SDM runtime.

3.13.1 Definition space The definition space contains all the definitions known to the SDM runtime. Each step in FIG. 16 defines an exemplary process for loading a new definition into the runtime. This process is also shared by the compilation process that occurs when the design surface validates the SDM document.

3.13.1.1 Load The SDM document is presented at runtime as part of an SDU or as a standalone document. An attempt is made to load the file from disk.

3.13.1.2 Schema Validation The first step is to validate that the SDM document matches the SDM schema. At this point, an error is returned for all unknown elements, missing types of required elements, and attributes or types containing invalid data.

3.13.1.3 Settings and Type Resolution The type resolution phase resolves all references to types in the SDM file (anywhere in the schema where qualified names are used). First, validate that all type references within the document are valid. These are all type references without aliases. Then try to resolve all import statements. If the import statement cannot be resolved, it generates a namespace load error; if the import statement can be resolved, it attempts to locate the type in the namespace. If the namespace has to be loaded from an SDM file, the namespace resolution process may cause other errors.

3.13.1.4 Path Resolution During the path resolution phase, attempt to resolve all paths to the members and settings defined in the document. Paths that reference members or settings that have an unresolved type do not generate an error.

3.13.1.5 Participation in relations In the type space, check that the type declaration does not violate any constraints on the relation participation of its members. To do this, evaluate all type and relationship constraints that do not have an associated set constraint.

3.13.1.6 Instance Simulation In instance simulation, constraints that are known to fail can be identified and constraints that may or may not fail based on user input not be flagged. Try to evaluate the constraints by flowing values in a simple way. To do this, a model of the instance space is built and flows and constraints based on this instance space are evaluated. Raises an error if the flow or constraint is known to be in error, and issues a warning if it is possible.

  Construct an instance space change request using the minOccurs constraint on all byReference systems. If minOccurs is 0, create a single instance and mark it as optional. The change request is then passed through the same deployment and flow processes used for the standard change request.

  It then evaluates all flows that have fully defined input values. If the input value is not fixed and can be changed by the user, the output of this flow is marked as provisional. The tentative input will be chained by any flow operation that consumes it. If the flow does not have a complete input value and the user can provide a value, mark all outputs of this flow as undefined. Flows from optional systems also produce provisional values.

  After flowing the values, the constraints are evaluated based on these values. Warn about constraints that could not supply a value. A warning is also issued when a constraint cannot be evaluated because of an undefined value.

3.13.2 Instance Space The model evaluation process begins by submitting a Declaration Change Request. The request includes a set of create, update, or delete operations targeted to the instance in the runtime. Then, as shown in FIG. 17, after passing the request through a series of pipeline stages, the necessary changes are made to the target system.

  The following sections outline the role of each expansion step.

3.13.2.1 Submit Request To initiate a change to the system, the operator or process should submit a change request. The change request contains the set of actions that the operator wants to perform on the instance in the runtime. These actions are categorized into three groups: create actions, update actions, and delete actions.

  The requests are then treated as a set of atomic actions to complete or fail as a group. This allows the constraint validation process to consider all actions in the request when evaluating whether the action set will result in a valid change to the model.

3.13.2.1.1 Type Resolution In the type resolution phase, all types and members referenced in the change request are resolved. Change requests consider these already loaded by the runtime. If they are not present, the runtime needs to initiate a load / compile action.

3.13.2.1.2 Path Resolution During the path resolution phase, resolve references to existing instances and instances defined by the create action in the change request.

3.13.2.2.2 Expansion
Deployment is the process of, for a change request, populating all the remaining actions required to execute the request. Generally, these actions are build and destroy actions on type instances and relationship instances. In theory, the operator could provide details about all the actions needed to build or destroy the instance, but this is not required as it greatly complicates the change request authoring process. Instead, attempts are made to automate this process as much as possible. The operator provides key information regarding the changes the operator desires by identifying actions on the byReference members. Then, for the nested byReference and byValue members and relationships, the rest of the action is filled.

3.13.2.2.1 Value members During the expansion stage, identify all non-reference type members. We know the cardinality of these members, and we know all the required parameters. Therefore, for each member, the generation request is added to the change request for the member whose parent is being generated. If the change request includes a destruction operation, the destruction operation is added for all instances included in the change request.

3.13.2.2.2 Expansion of reference members (discovery)
In general, building a reference member requires more information than a value member. These cardinalities are often undefined and may have deployment settings that require values for the instance to be built. Thus, the process of expanding the byReference members may require more information about the instance than the runtime can provide. The process of obtaining this information is called discovery.

  The discovery process populates reference type members as part of a build or update action. Only reference members that have an object manager that supports discovery participate in this process.

  When a new instance is discovered, it first checks that the instance does not yet exist in the SDM database using the instance-specific key value. If it is found to be a new instance, then classify the instance according to the type of the member being discovered. If the instance does not match the member, or if there is an ambiguous match, leave the member reference blank and mark the instance as offline and incomplete.

3.13.2.2.3 Relationship Evolution Once all the type instances to be constructed are known, create a relationship instance that binds the type instances together. If the type instance is being destroyed, delete all relationship instances that reference the type instance.

  To create a relationship, look into the member space and identify the composition of the relationship that should exist between the instances. If the type members have a cardinality greater than one, the topology of the relationship must be inferred. How to do this is discussed in detail in section XX.

3.13.3.2.3 Flow During the flow stage, evaluate the flow across all relationship instances. At this stage, an update request can be added to the change request for the instances affected by the modified parameter flow.

  The flow is evaluated by determining the set of instances whose settings have been updated as a result of a change request. For each of these, evaluate any outgoing configuration flows that depend on the modified configuration and add the target node to the set of modified instances. This process continues until the set is empty or the set contains a cycle.

3.13.2.4 Duplicate Detection In the process of duplicate detection, the expanded instances are matched against the instances already present in the SDM data storage. For example, it detects whether another application has installed the shared file. When it is detected that an instance already exists, one of several actions can be performed, depending on the version of the existing instance, such as:
a) Fail the installation.
b) Reference counting of instances.
c) Upgrade the instance.
d) Perform the installation in parallel.

3.13.2.5 Constraint Evaluation During the constraint evaluation phase, it is checked whether all constraints in the model are still valid even after the change request has been processed.

3.13.2.6 Request Ordering At this point, there is a complete action list so relationships between systems can be used to determine a valid change ordering.

3.13.2.7 Execution Deliver a subset of the machine-specific ordered action set. These machine specific sets should support inter-machine synchronization.

3.13.2.8 Request Return Changes are made by breaking change requests into deliverables based on the affected hosting relationships. When all parts are complete (or failed), match the result in runtime and return a summary to the user.

3.13.3 Expansion Details This section discusses the expansion process in terms of types and relationships in detail.

3.13.3.1 Expansion of reference members (discovery)
Just as hosting relationships are responsible for building new instances of a type, hosting relationships are also used to perform discovery of existing type instances. To do this, the hosting relationship is uniquely arranged to do this, since the manner in which instances of a type are represented on the host is only conscious of the hosting relationship.

  When the referencing member is marked for discovery, check if the hosting relationship supports discovery. If so, pass the host instance to the relationship and ask the relationship to return a build action for the guest instance that the relationship found on the host.

  Use validation to discover that the instance no longer exists. Again, a hosting relationship is used to verify the presence of a guest on the host. If the guest no longer exists, the hosting relationship adds a destroy action to the change request.

3.13.3.2 Unreferenced Member Expansion The runtime determines all build or destroy actions in a change request by simply adding a build or destroy action for each non-referenced member of the type already identified. Handle unreferenced member expansion.

3.13.3.3 Expansion of communication relationship When there is a communication relationship member between two type members, and if the operator does not specify an instance of the communication relationship, a fully connected mesh exists between the members. The communication relationship is developed by assuming that

  What does this mean? If two members are connected in member space, all instances of each member must be visible to each other. As shown in FIG. 18, when there are the following two members, the instance space topology is restricted by the cardinality of the members. At 1800, two exemplary members are shown. At 1802, a simple point-to-point relationship between the two largest instances is shown. At 1804, the fan out of the connection is shown. An example would be a client that can load balance requests across a set of servers. At 1806, the fan in of the connection is shown. One example would be a group of clients sharing a single server. 1808 shows a combination of these cases. At 1808, a set of clients is sharing a set of servers.

  When establishing a communication link, the delegating endpoint becomes transparent so that it has a connection that matches all communication relationships that would exist even if it were deleted. FIG. 19 shows two structures 1902 and 1904. These are equivalent as far as the connection between the instances A, B and C is concerned.

3.13.3.4 Evolving Hosting Relationships If the hosting relationship is ambiguous, it is necessary for the operator or manager of the hosting relationship to determine the correct topology.

  If the hosting relationship supports deployment, pass the host and guest set to the relationship manager and ask the manager to return the correct build action. If the manager does not support deployment, return a change request to the operator so that the operator can provide more information.

3.13.3.5 Expansion of reference relations 3.13.3.6 Expansion of containment relations Because the containment relations are not ambiguous, the runtime can always add appropriate build actions to the change request.

3.13.3.7 Deployment of delegation relationships In deployment, delegation relationships follow the same rules as communication relationships.

3.13.4 Flow 3.13.5 Execution

3.14 SDM instance space The following section defines the object model for the instance space of the SDM runtime. The instance space is used to track changes to the configuration of the system modeled by SDM.

  FIG. 20 shows an exemplary UML diagram that provides an overview of the instance space. Boxes 2002, 2004, 2006, 2008 indicate the types defined in other chapters of this document.

  The instance space is built around versioned changes initiated by change requests. Each instance can have a linearly continuous version that represents the atomic changes made to the running instance. Future versions may be present in the runtime before it reaches the running system.

  In this version of the SDM model, only linear changes are possible for a given instance. In the future, version branching will be possible and a version resolution model will be introduced. This allows multiple changes to be outstanding for a particular instance.

  Since linear versioning is possible, it is possible to load a series of change requests that build on the previous change. This supports pre-validation of a series of actions that may be performed during a process such as a rolling upgrade.

3.14.1 SDM instances All instances are derived from SDM instances. They share elements that define values for the configuration schema and elements that define a list of members that match members on the instance definition. They also share a set of attributes that define the unique identifier of the instance, the version number of the instance, the name of the instance, and a flag indicating whether this version represents the running state of the system.

3.14.2 Member The member member is used to associate a member of an instance with a set of referenced instances. The members of an instance are defined by the definition of the instance. The referenced instance is the instance created for the member or the instance to which the member is delegated. A member can represent an array, in which case there can be multiple referenced instances.

3.14.3 Change The change indicates a change to the instance state. This associates the change request with the set of affected instances. It also identifies the status of the change (see section XXX) and the change response if the change was made.

3.14.3.1 Change Status A change request can take one or more of the following states:
NotStarted-Indicates that no execution has been attempted for the change request.
InProgress-indicates that it is currently running.
Complete-indicates that the change request was successfully completed.
Failed—indicates that the change request has failed and the change is incomplete.
RolledBack-Indicates that a failed change request was successfully rolled back.

3.14.4 Concrete Object Instance A concrete object instance represents an instance of a concrete type identified by a type attribute. Since an instance can have a real-world representation, you need to keep track of whether the instance is in sync with its real-world counterpart. It is also desirable to know if the instance will be online as a result of this change. An online instance should be valid for all its constraints. An offline instance is invisible to other participants in the communication relationship in which it is participating. If the instance is incomplete, a further change request is required before the instance can be brought online.
<xs: complexType name = ”ObjectInstance”>
<xs: complexContent>
<xs: extension base = ”sdmInstance”>
<xs: attribute name = ”inSync” type = ”xs: boolean” use = ”required” />
<xs: attribute name = ”online” type = ”xs: boolean” use = ”required” />
<xs: attribute name = ”type” type = ”qualifiedName” use = ”required” />
</ xs: extension>
</ xs: complexContent>
</ xs: complexType>

3.14.5 Relation Instance The relation instance represents an instance of the identified relation type. Because relationships do not have a direct real-world representation, they need to keep information about whether the relationship is synchronized or online. Also, relationships may not be able to meet these constraints, but are relatively simple and are not expected to be incomplete.

3.14.5.1 Containment instance
This represents an instance of the containment relationship.

3.14.5.2. Communication instance
This represents an instance of a communication relationship.

3.14.5.3 delegation instance
It represents an instance of a delegation relationship.

3.14.5.4 hosting instance
This represents an instance of the hosting relationship.

3.14.5.5 reference instance
This represents an instance of the reference relationship.

3.14.6 Instances The instances group represents a set of instance elements that can be present in the SDM instance file.
<xs: group name = ”instances”>
<xs: choice minOccurs = ”0” maxOccurs = ”unbounded”>
<xs: element name = ”SystemInstance” type = ”concreteTypeInstance” />
<xs: element name = ”portInstance” type = ”concreteTypeInstance” />
<xs: element name = ”resourceInstance” type = ”concreteTypeInstance” />
<xs: element name = ”member” type = ”member” />
<xs: element name = ”containmentInstance” type = ”containmentInstance” />
<xs: element name = ”communicationInstance” type = ”communicationInstance” />
<xs: element name = ”hostingInstance” type = ”hostingInstance” />
<xs: element name = ”delegationInstance” type = ”delegationInstance” />
<xs: element name = ”referenceInstance” type = ”referenceInstance” />
<xs: element name = ”placementInstance” type = ”placementInstance” />
</ xs: choice>
</ xs: group>

3.14.7 Instance reference 3.14.7.1 instance Ref
instance Ref is a simple reference to the instance. Unless the reference is made in the context of a change request and the instance is not affected by the change request, it defaults to the isCurrent instance.

3.14.7.2 instance Version Ref
instance Version Ref identifies a particular version of the instance.

3.15 Deployment Unit Structure Requirements • Includes all bits needed to install the SDM-type set.
・ Can sign and version.
・ Easy to build / package / ship.
-Other SDUs can be referenced by reference or inclusion.
The expansion section of the SDM type definition directly refers to the file in the SDU

3.16 Localization It is necessary to determine which parts of the SDM model support localization and how localization is supported through system design and deployment.

First method:
Localization is completely up to the individual types and the types to be managed. Localization is implicit through constraints. Localization is not a first type citizen. This means that:
a) The SDU may contain a specific version of the type implementation. That is, there is one implementation of a particular version. This means that there can be no implementation where the differences are based solely on localization. Therefore, each implementation should support a range of locales, or the implementations should be of different types (it is not good to use versioning for this purpose!).
b) The localization is then achieved by using the resource as a mixin to support a particular version, or by using a set of types that identify implementations that support different versions.
c) The client cannot distinguish / request a localized version of the server.

Second method:
Localization is a first type citizen of identification along name and version. This means that localization should be considered wherever a reference to a type is made.
a) In this case, the client can distinguish the localized version of the server in any of the inclusion relation, the hosting relation, and the communication relation.
b) The deployment engine should be localization aware and allow the operator to choose between localized versions of the mold.
c) SDUs are identified by name, version, and locale. Alternatively, the SDU may include multiple implementations where the differences are based only on location. (In the first case, this implies more granular SDU packaging since the non-localized code should be placed in a separate SDU. The second case means that you can have multiple SDUs with the same name Yes.)

  The second approach can be very complex from a design / UI perspective if locales are widely used as constraints. For example, if the endpoints were localized, or if the host localized their guests, finding the connection / placement would be much more complicated. If the second approach is used in conjunction with b) of the first approach as the proposed mechanism, the complexity may be more manageable, but someone must identify, package and ship the localized resources. No.

3.11 Versioning and Change Management 3.17.1 General Comments • It is desirable to be able to version the system on the fly. That is, it is desirable that QFE can be applied to SQL without changing the instance identification. This means changing the type of the instance.
-It is desirable that the versioning policy be able to control the allowed version changes. For example, a system-type designer can select how stringent the versioning policy for members of the system, or an operator can unilaterally upgrade member versions for security reasons.
It is desirable to limit the propagation of versioning changes. For example, if the type of a member changes, it is undesirable to have to change the type of the system and thus propagate the type change to the root.
• A continuous change is indicated by a change in the first two parts of the version number, and a continuous change is indicated by a change in the second two parts of the version number.

If you distribute this document to anyone, you must add the specification EULA to the beginning of this document, even under the NDA. Refer < http: //dealpoint/Info/Feedback/TDA.asp> for information. Documents distributed without this EULA are a significant legal risk to us.
May I distribute this specification under the NDA and with proper consent?
May I distribute this specification to the public?

4. Template Instructions 4.1 Feature Process Information The purpose is to ensure that all Windows® features use the same specification template. It should be understood that some sections may not apply, depending on your feature area.

If this template does not meet your needs or has errors, contact mailto: johnray . Also, if you have any best practice information to help the new PM and Dev fill out the template, send suggestions to mailto: johnray .

  To be on schedule for feature review, cover pages (contacts, etc.), section 1 foreword, section 3.1 dependencies, section 6 schedule / staffing should be completed. It is understood that these sections may not be able to be completed completely at first. I'll do my best to complete what I know now, and update as I go. The intent is to outline the key impact of your features so that your team can prepare for possible interactions.

  To prepare for a feature review, you should fill in 80% of this specification template and make sure each section has something (even N / A or TBD).

4.2 How to Fill in a Template Select a new file and open this template as a document. Use styles such as headings 1-5, body text, block quotes, list bullets, and list numbers in the style control on the formatting toolbar for the body of your specification.

  Be sure to write the feature name below the document title in the document properties.

4.2.1 Contents Each section lists basic instructions to help you understand what to write. All instructions are listed in blue.

  You can show or hide this text by checking or unchecking Hide in the Tools / Options / View tab under Format Marks. It can also be displayed by using the "paragraph" text display button on the toolbar or the "display / hide" instruction button on the last page (the macro must be turned on).

4.2.2 How to create bullet and number lists • To create such a bullet list, select one or more paragraphs and select the list bullet style from the style drop-down list on the format toolbar. To create a numbered list, such as the numbered paragraph above, select one or more paragraphs and select a list number style from the Style drop-down list.

4.2.3 How to create a problem block You may want to emphasize a problem in a line of your specification. Problem blocks can be used to draw attention to them. Write the text you want to be the heading of the question block and the paragraph of text you want to include in the question block. Next, highlight the heading text and select a question block heading from the Style drop-down list. Next, highlight the paragraph of text you want to include in the question block and select a question block style from the drop-down list.

4.3 How to update the table of contents To update the table of contents of this specification, place the cursor on the TOC page, right-click and select the update field. You can choose to update only the page number or the entire table of contents.

4.4 Specification Template Revision This documents the revision history of the specification template itself. This section should be removed from individual specifications.

Exemplary Computer Environment FIG. 21 illustrates an example of a general computer environment 600 that can be used to implement the techniques described herein. Computing environment 600 is merely an example of a computing environment and does not imply any limitations as to the scope of use or functionality of the computer and network architecture. Neither should the computing environment 600 be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in the exemplary computing environment 600.

  Computer environment 600 includes a general purpose computing device in the form of a computer 602. The computer 602 can be, for example, the computing device 102 of FIG. 1, can implement the development system 202 of FIG. 2, can be the controller 206 of FIG. 2, and can be the target device 212 of FIG. Alternatively, the controller 520 or the target 522 in FIG. 5 can be used. Components of computer 602 include, but are not limited to, one or more processors or processing units 604, a system memory 606, and a system bus 608 that couples various system components, including processor 604, to system memory 606. be able to.

  System bus 608 may be any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port (AGP), a processor bus or a local bus, using any of a variety of bus architectures. Represents one or more of For example, such an architecture includes an ISA (Industry Standard Architecture) bus, an MCA (Micro Channel Architecture) bus, an EISA (Enhanced ISA) bus, a VESA (Video Electronics bus, and a local bus called "Electronics and Standards"). Interconnects) bus can be included.

  Computer 602 typically includes a variety of computer readable media. Such media can be any available media that can be accessed by computer 602 and includes both volatile and nonvolatile media, removable and non-removable media.

  System memory 606 includes computer-readable media in the form of volatile memory, such as random access memory (RAM) 610, and / or non-volatile memory, such as read-only memory (ROM) 612. The ROM 612 stores a basic input / output system (BIOS) 614 that includes basic routines that help transfer information between elements within the computer 602, such as during startup. RAM 610 typically contains data and / or program modules that are immediately accessible to and / or presently being operated on by processor 604.

  Computer 602 can also include other removable / non-removable, volatile / non-volatile computer storage media. For example, FIG. 21 shows a hard disk drive 616 for reading from and writing to a non-removable and non-volatile magnetic medium (not shown), and a removable and non-volatile magnetic disk 620 (for example, a “floppy (registered trademark) disk”). A magnetic disk drive 618 for reading and writing data to and from an optical disk for reading and writing to a removable and nonvolatile optical disk 624 such as a CD (compact disc) -ROM, a DVD (Digital Versatile Disc) -ROM and other optical media The drive 622 is shown. The hard disk drive 616, magnetic disk drive 618, and optical disk drive 622 are each connected to the system bus 608 by one or more data media interfaces 626. Alternatively, hard disk drive 616, magnetic disk drive 618, and optical disk drive 622 may be connected to system bus 608 by one or more interfaces (not shown).

  Each disk drive and its associated computer-readable medium provides nonvolatile storage of computer-readable instructions, data structures, program modules, and other data for computer 602. In this example, a hard disk 616, a removable magnetic disk 620, and a removable optical disk 624 are shown, but a magnetic cassette or other magnetic storage device, flash memory card, CD-ROM, DVD or other optical storage, random Other types of computer readable media that can store computer accessible data, such as access memory (RAM), read only memory (ROM), and EEPROM (Electronically Erasable and Programmable Read Only Memory), are also examples of this. It should be understood that it can be used to implement computing systems and environments.

  The hard disk 616, magnetic disk 620, optical disk 624, ROM 612, and / or RAM 610 can store any number of program modules. For example, these include an operating system 626, one or more application programs 628, other program modules 630, and program data 632. Such operating system 626, one or more application programs 628, other program modules 630, and program data 632 (or some combination thereof) each provide all or some of the resident components that support the distributed file system. Can be implemented.

  A user can enter commands and information into the computer 602 via input devices such as a keyboard 634 and a pointing device 636 (eg, a “mouse”). Other input devices 638 (not specifically shown) may include a microphone, joystick, game pad, satellite dish, serial port, scanner, and / or the like. These and other input devices are connected to the processor 604 via an input / output interface 640 coupled to a system bus 608, but other interfaces and bus structures, such as a parallel port, a game port, a universal serial bus (USB), etc. May be connected.

  A monitor 642 or other type of display device may also be connected to the system bus 608 via an interface, such as a video adapter 644. In addition to the monitor 642, other output peripheral devices can include components such as speakers (not shown) and a printer 646, which can be connected to the computer 602 via an input / output interface 640.

  Computer 602 can operate in a networked environment with logical connections to one or more remote computers, such as a remote computing device 648. For example, remote computing device 648 can be a personal computer, a portable computer, a server, a router, a network computer, a peer device, or other common network node. Remote computing device 648 is illustrated as a portable computer that can include many or all of the elements and features described herein with respect to computer 602.

  Logical connections between computer 602 and remote computer 648 are shown as local area network (LAN) 650 and general wide area network (WAN) 652. Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets, and the Internet.

  Computer 602 is connected to local network 650 via a network interface or adapter 654 when implemented in a LAN networking environment. When implemented in a WAN networking environment, it typically comprises a modem 656 or other means for establishing communication over the wide network 652. Modem 656 may be internal or external to computer 602 and may be connected to system bus 608 via input / output interface 640 or other suitable mechanism. It should be understood that the network connections shown are exemplary and other means of establishing a communication link between the computers 602 and 648 may be employed.

  In a networked environment, such as that depicted by computing environment 600, program modules depicted relative to computer 602, or portions thereof, may be stored in a remote memory storage device. By way of example, remote application programs 658 reside on a memory device of remote computer 648. Application programs and other executable program components, such as operating systems, are shown here as separate blocks for purposes of explanation. It should be understood, however, that such programs and components are at various times in the various storage components of computing device 602 and are executed by the data processors of the computer.

  Various modules and techniques may be described herein in the general context of computer-executable instructions, such as program modules, being executed by one or more computers or other devices. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Generally, the functionality of the program modules can be combined or distributed as desired in various embodiments.

  Implementations of these modules and techniques may be stored on or transmitted over some form of computer readable media. Computer readable media can be any available media that can be accessed by a computer. By way of example, and not limitation, computer readable media may comprise "computer storage media" and "communications media."

  "Computer storage media" includes volatile and non-volatile, removable and non-removable media implemented by any method or technique for storing information such as computer readable instructions, data structures, program modules, and other data. Medium is included. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, DVD or other optical storage device, magnetic cassette, magnetic tape, magnetic disk storage device or other magnetic storage A device may be included, or any other medium that can be used to store desired information and accessible from a computer.

  A "communications medium" typically incorporates computer readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave or other transport mechanism. Communication media also includes any information delivery media. The term "modulated data signal" means a signal that has one or more of its characteristics set or changed in such a manner that information is encoded in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, radio frequency, infrared and other wireless media. Any combination of the above should also be included within the scope of computer readable media.

  Alternatively, portions of this framework may be implemented in hardware or a combination of hardware, software, and / or firmware. For example, one or more application specific integrated circuits (ASICs) or programmable logic devices (PLDs) can be designed or programmed to implement one or more portions of the framework.

Conclusion Although the invention has been described in terms of structural features and / or methodical operations, the invention as defined in the appended claims is not necessarily limited to the specific features or operations described. I want to be understood. Rather, these specific features and acts are disclosed as exemplary forms of implementing the claimed invention.

FIG. 3 illustrates an exemplary network configuration of an embodiment to which the present invention can be applied. FIG. 2 is a block diagram illustrating an exemplary architecture that uses an SDM-defined model of an embodiment to which the present invention can be applied. FIG. 4 is a diagram illustrating an exemplary layering setting of an embodiment to which the present invention can be applied. 3 is a flowchart illustrating an exemplary process for using a system definition model (SDM) throughout the life cycle of a system of an embodiment to which the present invention can be applied. FIG. 3 illustrates an exemplary architecture using an SDM runtime of an embodiment to which the present invention can be applied. FIG. 4 illustrates an exemplary SDM document of an embodiment to which the present invention can be applied. It is a figure showing a base definition and a member of an embodiment to which the present invention can be applied. FIG. 4 illustrates exemplary members of an embodiment to which the present invention can be applied. It is a figure showing an example set value and a value list of an embodiment to which the present invention can be applied. FIG. 3 illustrates an example SDM application life cycle according to some embodiments of the present invention. FIG. 4 is a diagram illustrating an example of mapping a web application of the embodiment to which the present invention can be applied to a web server host. FIG. 4 illustrates an exemplary embedded data type hierarchy of an embodiment to which the present invention can be applied. FIG. 4 is a diagram illustrating an example of an implicit extension of an abstract object definition according to an embodiment to which the present invention can be applied. FIG. 11 is a diagram illustrating an example of an implicit extension of an abstract relationship according to an embodiment to which the present invention can be applied. It is a figure showing an example of a change demand of an embodiment to which the present invention can be applied. FIG. 4 illustrates an exemplary process for loading a new definition into the runtime. It is a figure showing an example which implements a change request of an embodiment to which the present invention can be applied. It is a figure showing the example of the connected member of the embodiment to which the present invention can be applied. FIG. 4 is a diagram illustrating an exemplary structure for connection. FIG. 3 is an exemplary UML diagram providing an overview of instance space of an embodiment to which the present invention can be applied. FIG. 4 illustrates a general computer environment that can be used to implement the techniques described herein in embodiments to which the present invention can be applied.

Explanation of reference numerals

200 Exemplary Architecture 202 Development System 204 SDM Document 206 Controller 208 Deployment Module 210 Management Module 212 Target Device

Claims (47)

Designing a system using a system-defined model;
Then deploying the system on one or more computing devices using the system-defined model;
Using the system-defined model after deploying the system to manage the system deployed on the one or more computing devices. The method of claim 1, wherein the system includes an application. The method of claim 1, wherein the system includes an environment. The method of claim 1, further comprising: using knowledge obtained during management of the system to design a subsequent version of the system. The method of claim 1, wherein the system-defined model includes knowledge describing how to deploy the system on the one or more computing devices. The system definition model includes knowledge describing how to deploy the system on a plurality of different computing devices, wherein the knowledge describes how to deploy the system to each of the plurality of different computing devices. The method of claim 1, comprising different knowledge describing what to deploy. The system defined model according to claim 1, wherein the one or more computing devices have constraints that must be met in order for the system to execute on the one or more computing devices. The method described in. The design of the system, the system-defined model may be used to check whether the constraint is satisfied by the one or more computing devices. Method. During design of the system and management of the system, the system-defined model may be used to check whether the constraint is satisfied by the one or more computing devices. The method according to claim 7. The method of claim 1, wherein the system definition model includes knowledge describing how to manage the system after deployment of the system. The method of claim 1, further comprising: using a flow to automatically communicate configuration changes to the system during management of the system. The system is deployed in an environment on the one or more computing devices, and prior to design, deployment, and management of the system,
Designing the environment using another system-defined model;
Then deploying the environment on the one or more computing devices using the another system-defined model;
Managing the deployed environment on the one or more computing devices using the another system-defined model after deployment of the environment. the method of. The method of claim 12, wherein the system-defined model for the environment is obtained by considering a configuration of one or more computing devices. The system-defined model includes constraints that the environment must meet in order for the system to execute on the one or more computing devices, and the another system-defined model indicates that the system 13. The method of claim 12, comprising: or other constraints that the system must satisfy to execute on multiple computing devices. A plurality of environments deployed on the one or more computing devices;
Designing each of the plurality of environments using a plurality of different system-defined models, each of the plurality of environments being associated with one of the plurality of different system-defined models;
Deploying, for each environment, the environment using the associated one of the plurality of different system-defined models;
And after the deployment, for each environment, using the associated one of the plurality of different system-defined models to manage the environment. . 16. The environment of claim 15, wherein the plurality of environments are each layered, and each of the plurality of environments serves as an environment for another one of the plurality of environments or as an environment for the system. Method. One or more computer-readable storage media storing a plurality of instructions for implementing a schema, wherein the plurality of instructions, when executed by a processor,
Steps to facilitate system design;
Facilitating deployment of said system;
Causing the processor to perform the steps of: facilitating management of the system; and a computer-readable recording medium. The one or more computer-readable media of claim 17, wherein the system includes an application. The one or more computer-readable media of claim 17, wherein the system includes an environment. 18. The one or more computers according to claim 17, wherein the step of facilitating deployment of the system comprises including knowledge describing how to deploy the system in a system-defined model. A readable recording medium. The step of facilitating the deployment of the system is to include in a system definition model knowledge describing how to deploy the system in a plurality of different environments, wherein the knowledge describes how the system is deployed. 18. The one or more computer-readable storage media of claim 17, including different knowledge describing whether to deploy to each of a plurality of different environments. The method of claim 17, wherein the step of facilitating the design of the system is to include in a system definition model constraints that the environment must satisfy in order for the system to execute in the environment. One or more computer-readable recording media. The method of facilitating the design of the system comprises, during the design of the system, using the system definition model to check whether the constraints are satisfied by the environment. 23. One or more computer-readable storage media according to claim 22. 18. One or more computers according to claim 17, wherein the step of facilitating management of the system includes including knowledge describing how to manage the system in a system definition model. A readable recording medium. Means to facilitate system design;
Means for facilitating deployment of the system;
Means for facilitating the management of the system. 26. The apparatus of claim 25, wherein the means for facilitating deployment of the system includes means for including knowledge describing how to deploy the system in a system-defined model. The means for facilitating deployment of the system includes means for including in a system definition model knowledge describing how to deploy the system in a plurality of different environments, the knowledge comprising: 26. The apparatus of claim 25, comprising different knowledge describing whether to deploy to each of a plurality of different environments. 26. The system of claim 25, wherein the means for facilitating the design of the system includes means for including in a system definition model constraints that the environment must satisfy in order for the system to execute in the environment. apparatus. The means for facilitating the design of the system includes means for using the system-defined model during the design of the system to check whether the constraints are satisfied by the environment. The device according to claim 28. 26. The apparatus of claim 25, wherein the means for facilitating management of the system includes means for including knowledge describing how to manage the system in a system definition model. A system comprising a system definition model applicable throughout the life cycle of an application, wherein the life cycle of the application includes design of the application, deployment of the application, and management of the application;
A schema for instructing how to specify a functional operation in the system definition model. The system of claim 31, wherein the system definition model includes information describing how to deploy the application. The system definition model includes information describing how to deploy the application to a plurality of different environments, wherein the information describes how to deploy the application to each of the plurality of different environments. 32. The system of claim 31, comprising different information. The system of claim 31, wherein the system-defined model includes constraints that the environment must satisfy in order for the application to execute in the environment. During the design of the application and the management of the application, the system-defined model can be used to check whether the constraints are satisfied by one or more computing devices in the system. 35. The system of claim 34. The system of claim 34, wherein during design of the application, the system-defined model can be used to check whether the constraints are satisfied by the environment. The system according to claim 31, wherein the system definition model includes information describing how to manage the application. Further comprising another system definition model applicable throughout the life cycle of the environment, wherein the life cycle of the environment includes designing the environment, deploying the environment, and managing the environment;
The system of claim 31, wherein the schema further indicates how to specify functional behavior in the another system-defined model. The system of claim 38, wherein the system-defined model for the environment is obtained by considering a configuration of one or more computing devices. The system-defined model includes constraints that the environment must meet in order for the application to run in the environment, and the another system-defined model indicates that the application must run in 39. The system of claim 38, including other constraints that must be met. Further comprising an additional system definition model applicable throughout the life cycle of the additional environment, wherein the life cycle of the additional environment includes designing the additional environment, deploying the additional environment, and managing the additional environment Including
The additional environment is layered below the environment;
39. The system of claim 38, wherein the schema further indicates how to specify functional behavior in the additional system-defined model. Defining an instance of the system-defined model used during the design of the system and used with the system-defined model runtime during deployment and management of the system. 43. The method of claim 42, wherein the system-defined model includes information describing how to deploy the system. The system definition model includes information describing how to deploy the system into a plurality of different runtimes, the information describing how to deploy the system to each of the plurality of different runtimes. 43. The method of claim 42, comprising different information described. 43. The method of claim 42, wherein the system-defined model includes constraints that the runtime must satisfy in order for the system to execute within the runtime. The method of claim 45, wherein during system design, the system-defined model can be used to check whether the constraints are satisfied by the runtime. 43. The method of claim 42, wherein the system definition model includes information describing how to manage the system in the runtime.

Images