Architecture for distributed computing system and automated design, deployment, and management of distributed applications

[0001] This patent application claims the benefit of U.S. Provisional Application No. 60/452,736, filed Mar. 6, 2003, the disclosure of which is incorporated herein by reference.

[0002] This patent application is also related to the following U.S. patent applications (all of which are incorporated herein by reference):

[0003] U.S. patent application Ser. No. 10/382,942, filed on Mar. 6, 2003, titled “Virtual Network Topology Generation”;

[0004] U.S. patent application Ser. No. 09/695,812, filed on Oct. 24, 2000, titled “System and Method for Distributed Management of Shared Computers”;

[0005] U.S. patent application Ser. No. 09/695,813, filed on Oct. 24, 2000, titled “System and Method for Logical Modeling of Distributed Computer Systems”;

[0006] U.S. patent application Ser. No. 09/695,820, filed on Oct. 24, 2000, titled “System and Method for Restricting Data Transfers and Managing Software Components of Distributed Computers”;

[0007] U.S. patent application Ser. No. 09/695,821, filed on Oct. 24, 2000, titled “Using Packet Filters and Network Virtualization to Restrict Network Communications”;

[0008] U.S. patent application Ser. No. 09/696,707, filed on Oct. 24, 2000, titled “System and Method for Designing a Logical Model of Distributed Computer System and Deploying Physical Resources According to the Logical Model”; and

[0009] U.S. patent application Ser. No. 09/696,752, filed on Oct. 24, 2000, titled “System and Method Providing Automatic Policy Enforcement in a Multi-Computer Service Application”.

[0010] The invention relates to an architecture for a distributed computing system and automated design, deployment, and management of distributed applications on the distributed computing system.

[0011] Internet usage has exploded over the past several years and continues to grow. People have become very comfortable with many services offered on the World Wide Web (or simply “Web”), such as electronic mail, online shopping, gathering news and information, listening to music, viewing video clips, looking for jobs, and so forth. To keep pace with the growing demand for Internet-based services, there has been tremendous growth in the computer systems dedicated to hosting Websites, providing backend services for those sites, and storing data associated with the sites. One type of distributed computer system is an Internet data center (IDC), which is a specifically designed complex that houses many computers for hosting Internet-based services. IDCs, which also go by the names “Webfarms” and “server farms”, typically house hundreds to thousands of computers in climate-controlled, physically secure buildings. These computers are interconnected to run one or more programs supporting one or more Internet services or Websites. IDCs provide reliable Internet access, reliable power supplies, and a secure operating environment.

[0012] FIG. 1 shows an Internet data center 100. It has many server computers 102 arranged in a specially constructed room. The computers are general-purpose computers, typically configured as servers. An Internet data center may be constructed to house a single site for a single entity (e.g., a data center for Yahoo! or MSN), or to accommodate multiple sites for multiple entities (e.g., an Exodus center that host sites for multiple companies).

[0013] The IDC 100 is illustrated with three entities—entity A, entity B, and entity C—that share the computer resources. These entities represent various companies that want a presence on the Web. The IDC 100 has a pool of additional computers 104 that may be used by the entities at times of heavy traffic. For example, an entity engaged in online retailing may experience significantly more demand during the Christmas season. The additional computers give the IDC flexibility to meet this demand.

[0014] Today, large IDCs are complex and often called upon to host multiple applications. For instance, some websites may operate several thousand computers, and host many distributed applications. These distributed applications often have complex networking requirements that require operators to physically connect computers to certain network switches, as well as manually arrange the wiring configurations within the IDC to support the complex applications. As a result, this task of building physical network topologies to conform to the application requirements can be a cumbersome, time consuming process that is prone to human error. Accordingly, there is a need for improved techniques for designing and deploying distributed applications onto the physical computing system.

[0015] An architecture and methodology for designing, deploying, and managing a distributed application onto a distributed computing system is described.

[0016] Similar reference numbers are used throughout the figures to reference like components and/or features.

[0017] FIG. 1 illustrates an example of an Internet data center.

[0018] FIG. 2 illustrates an example of a service.

[0019] FIGS. 3–8 illustrate example layer abstractions.

[0020] FIGS. 9–10 illustrate an example SDM type space.

[0021] FIGS. 11–15 illustrate example layer abstractions.

[0022] FIG. 16 illustrates an example process.

[0023] FIGS. 17–19 illustrate example components as discussed herein.

[0024] FIGS. 20–21 illustrate an example graphical user interface.

[0025] FIG. 22 illustrates an example SDM model.

[0026] FIG. 23 illustrates an example deployment.

[0027] FIG. 24 illustrates example types.

[0028] FIG. 25 illustrates example instance requests.

[0029] FIG. 26 illustrates example revalidation of constraints.

[0030] FIG. 27 illustrates an example logical architecture of an SDM runtime.

[0031] FIG. 28 illustrates an example graphical representation of a service.

[0032] FIG. 29 illustrates an example instance space.

[0033] FIG. 30 illustrates an example of packaging data into an SDU.

[0034] FIG. 31 illustrates an example type space, member space, and instance space.

[0035] FIG. 32 illustrates an example m ember tree.

[0036] FIG. 33 illustrates an example instance tree.

[0037] FIG. 34 illustrates an example implementation of the systems described herein.

[0038] FIG. 35 illustrates example of tracking creation of component instances.

[0039] FIGS. 36–39 illustrate example component instance events.

[0040] FIG. 40 illustrates an example of a partitioned runtime.

[0041] FIG. 41 illustrates an example member space.

[0042] FIG. 42 illustrates an example instance hierarchy.

[0043] FIG. 43 illustrates an example of partitioning an instance space.

[0044] FIG. 44 illustrates example relationships between various components.

[0045] FIG. 45 illustrates an example fixed identity trust relationship.

[0046] FIGS. 46–47 illustrate an example arrangement of components.

[0047] FIG. 48 illustrates an example platform architecture.

[0048] FIG. 49 illustrates example usage flow for application deployment.

[0049] FIG. 50 illustrates example application settings and host settings.

[0050] FIG. 51 illustrates example phases for a deployment tool.

[0051] FIG. 52 illustrates an example visualization of a data center description.

[0052] FIGS. 53–54 illustrate example flow diagrams.

[0053] FIG. 55 illustrates an example of handling an SDU.

[0054] FIGS. 56–58 illustrate example flow diagrams.

[0055] FIG. 59 illustrates an example model architecture.

[0056] FIG. 60 illustrates example layers of management.

[0057] FIG. 61 illustrates an example operation of a system.

[0058] FIG. 62 illustrates an example connector arrangement.

[0059] FIGS. 63–67 illustrate an example physical configuration of devices.

[0060] FIG. 68 illustrates an example request graph.

[0061] FIG. 69 illustrates an example reply graph.

[0062] FIGS. 70–86 illustrates example scenarios in which the invention may be used.

[0063] FIG. 87 illustrates an example services platform architecture.

[0064] FIG. 88 illustrates example components in a system.

[0065] FIG. 89 illustrates example products that may be included in a system described herein.

[0066] FIG. 90 illustrates various resource management components.

[0067] FIG. 91 illustrates an example arrangement of multiple LANs.

[0068] FIG. 92 illustrates an example ADS architecture.

[0069] FIG. 93 illustrates an example ADS remote boot and imaging system.

[0070] FIG. 94 illustrates an example topology arrangement.

[0071] FIG. 95 illustrates an SDML example.

[0072] FIG. 96 illustrates an example collection of data in a SDU.

[0073] FIG. 97 illustrates an example of dynamic binding using SDM runtime APIs.

[0074] FIG. 98 illustrates an example SDM arrangement.

[0075] FIG. 99 illustrates an example deployment.

[0076] FIG. 100 illustrates an example system architecture.

[0077] FIG. 101 illustrates an example of various deployment layers.

[0078] FIG. 102 illustrates example operations logic.

[0079] FIGS. 103–105 illustrate example changes due to the Internet.

[0080] FIG. 106 illustrates an example application lifecycle.

[0081] FIG. 107 illustrates example benefits of a new architecture.

[0082] FIG. 108 illustrates an example of converting complex systems into simple diagrams.

[0083] FIG. 109 illustrates an example service.

[0084] FIG. 110 illustrates an example SQL cluster.

[0085] FIG. 111 illustrates an example SDM data center model.

[0086] FIG. 112 illustrates an example design application surface.

[0087] FIG. 113 illustrates an example SDM service in a data center.

[0088] FIG. 114 illustrates example resource managers.

[0089] FIG. 115 illustrates an example of resource virtualization.

[0090] FIG. 116 illustrates example programming operations logic.

[0091] FIG. 117 illustrates example interaction with operations logic.

[0092] FIGS. 118–119 illustrate an example of managing heterogeneous environments.

[0093] The following disclosure describes a number of aspects pertaining to an architecture for designing and implementing a distributed computing system with large-scale application services. The disclosure includes discussion of a service definition model (SDM) and an SDM runtime environment. The disclosure further includes design aspects such as how to model data center components, how to model a distributed application description, and techniques for logically placing a modeled application onto a modeled data center and validating this logical placement at design time. The disclosure further explains deployment aspects such as how to instantiate the model using physical resources, physical placement of the distributed application on the physical resources to facilitate application deployment at the physical data center. The disclosure also addresses management aspects, including using the SDM to provide contextual management feedback, tracking, and operations feedback. The disclosure discusses various resource managers used in deployment of the application across physical resources and to support the management aspects.

Service Definition Model (SDM)

[0094] The service definition model (SDM) provides tools and a context for an application architect to design distributed computer applications and data centers in an abstract manner. The model defines a set of elements that represent functional units of the applications that will eventually be implemented by physical computer resources and software. Associated with the model elements is a schema that dictates how functional operations represented by the components are to be specified.

SDM Overview

Introduction

Internet Era

[0095] Over the last decade we have witnessed the Internet emerge as a computing platform. More and more software companies are adopting the “software as a service” model. These services are typically comprised of several components running on many machines including servers, networking equipment and other specialized hardware. Loosely coupled, asynchronous programming models are becoming the norm. Scalability, availability and reliability are critical to the success of these distributed services.

[0096] We are also witnessing a change in hardware trends. High density servers and specialized network hardware are widespread in data centers. Switched fabrics are replacing system buses and providing greater flexibility in system configurations. Hardware cost now plays a small role in the Total Cost of Ownership (TCO) metric compared to the cost of training and maintaining a dedicated operations staff. While rock-solid operational practices are vital to any highly available service, these practices are difficult to repeat consistently because of the fallibility that results from people executing manual procedures. In the emerging software as a service era, the focus of development is shifting away from the desktop and toward the server. Along with this change of focus comes a plethora of new problems for software developers, hardware vendors, and IT professionals:

• • [0097] Services are larger and more complex—services are time-consuming to develop, difficult and costly to maintain, and risky to extend with additional functionality.
  • [0098] Services tend to be monolithic—services tend to rely on custom components and specific configurations. Portions of many services cannot be removed, upgraded independently, or replaced with alternatives without impacting the availability of the service.
  • [0099] Services rely on specific hardware configurations—whether it's a certain network topology or a dependency on a specific network appliance, the binding between hardware and software significantly reduces the ability to host services in different data center environments.
  • [0100] Services demand operational consistency—most services require a staff of operations personnel to function. The lack of a common platform reduces the ability to reuse code and enact operational best practices across services. Unfortunately, operations staff must be trained in the specifics of each service and retrained as each service evolves.

[0101] The terms “service” and “application” are used interchangeably throughout this document. In general, an application could be viewed as a collection of distributed services. For example, Hotmail would be an application comprised of multiple services where each service performs a different function.

[0102] These problems are not unlike those of the desktop and DOS era (circa 1980's). DOS defined valuable core services for application developers such as disk management, file system, console facilities, etc. It did, however, leave many complex tasks up to the ISVs. As an example, WordPerfect and Lotus 123 both independently had to write printer drivers in order to support printing within their respective applications. Similarly, printer hardware vendors had to make deals with the software companies in order to have a successful product. The barrier to entry for ISVs and hardware vendors was exceptionally high. This resulted in only a few successful software and hardware companies during this era. Microsoft addressed this problem by creating the Windows platform, which dramatically reduced the barrier to entry. Windows defined an abstraction layer for most hardware devices on the PC platform. This relieved the ISVs from having to worry about supporting specific hardware devices. Windows managed all resources within the PC including memory, disk and network. Windows also came with a wealth of additional services that could be utilized by ISVs. This platform sparked enormous growth in the industry. ISVs that targeted the Windows platform were extremely productive. Many new hardware vendors emerged offering cheaper hardware due to the commoditization effect of having a common platform: Windows.

Service Definition Model (SDM)

SDM Fundamentals

The SDM:

• • [0103] Defines abstractions that make it easier to design distributed applications/services.
  • [0104] Enables a framework for reuse and automation of operational practices.
  • [0105] Simplifies deployment and operations of distributed applications and services.

[0106] It can be easier to understand what the SDM is by considering that it captures what today is often seen as a complex diagram on the wall near the operators of a service. In these diagrams a box typically represents a running element of the service and the lines connecting the boxes represent communication paths between the service elements. For example, a load balancer connected to some IIS front-end machines which in turn are connected to one or more middle-tier or back-end services.

[0107] Another way to think about the SDM is that it is both a meta-model for the behavior of distributed applications/services and a “live” blueprint of a running application/service in its computing environment. The SDM captures the structure of the application in its computing environment, including its allowable software operations, in a declarative and scale-invariant manner. The ability to declaratively describe the topology of a service, including the bindings between the hardware and network resources, and the valid operations of its software components, is quite powerful.

[0108] As an analogy, let's look at Microsoft's Common Object Model (COM). COM standardized how components are packaged, registered, activated, discovered, etc. COM mandates strict rules related to lifetime, memory management and interface implementation. These primitives are essential for interoperability because they allow components to be treated as black boxes. COM is the basis for more sophisticated services such as eventing, automation, and OLE.

[0109] Likewise the SDM needs to define some basic primitives on which to build more sophisticated capabilities. These primitives are:

• • [0110] Components—units of implementation, deployment and management.
  • [0111] Ports—named end-points that have an associated type and a set of valid operations.
  • [0112] Wires—permissible communication paths between ports.
  • [0113] Layers—separation of resource management ownership and bindings.
  • [0114] Mappings—bindings between components, ports and wires at each layer.

[0115] The remainder of this document will describe each of these primitives in more detail.

Components, Ports and Wires

[0116] For the purposes of this document, it is useful to consider a graphical representation of a simple service called MyService drawn using components, ports and wires. See FIG. 2. In the diagram, boxes represent components, diamonds represent ports, and dashed lines represent wires.

• • [0117] MyService is a compound component because it uses the components MyFrontEnd and MyBackEnd.
  • [0118] MyService has one visible port called web which is a delegated port implemented by the MyFrontEnd component.
  • [0119] MyFrontEnd has two ports, the delegated port and a port labeled catalog.
  • [0120] MyBackEnd has one port labeled data.
  • [0121] The MyFrontEnd and MyBackEnd components have a potential communication relationship that binds the catalog port to the data port through a wire.
    Components

[0122] Components are units of implementation, deployment and management.

[0123] Examples of components are a dedicated server running Windows Server, an IIS virtual web site or a SQL database. Components generally have machine boundaries, but are not required to as evidenced by web services hosted on a single IIS server.

[0124] Components expose functionality through ports and communicate through wires. Simple components can only have ports as members. Components that use other components are referred to as compound components, which can have ports and wires as members in addition to other components.

[0125] Compound components are created through composition and do not have any implementation associated with them. Compound component ports are delegated ports from inner components. Compound components make collocation, encapsulation and reuse possible and so can be thought of as a way to organize an application/service and its behaviors.

[0126] Only the public ports of a component are visible outside the component.

[0127] Compound components to the outside world look like simple components with the internal structure of the components they use hidden through encapsulation. In fact, a simple component could be replaced with a compound component or vice versa as along as the port types and behaviors supported by both are exactly the same.

Ports

[0128] Ports are named end-points that define a set of behaviors. Ports have an associated type or role and are typically associated with a set of allowed operations. Examples of ports are an HTTP server port, a SOAP port with a set of allowed operations, etc. Ports can be delegated which means that an outer component can expose the port of an inner component as its own. Ports form the public interface (behavior) to a component. Ports are the only members of a component that can be made public (visible).

Wires

[0129] Wires are permissible bindings between ports and represent topological relationships between ports (and components). Wires do not specify any instance interconnect topology but instead express a “potentiality” for an instance interconnect topology.

[0130] Wires are essentially busses and can contain one or more port members. Wires should not be mistaken for a point-to-point relationship. A given port cannot appear more than once within the same wire.

Schema

[0131] In order to describe an application/service, it is necessary to have a standard schema for the SDM. The SDM schema should be expressible using XSD and XML grammars. While it is beyond the scope of this document to describe the SDM schema in great detail, it is necessary to provide some brief explanation as context for the subject matter described later in this document. Below is a simplified view of the SDM schema.

[0132]

	<sdm>
	<identityReference />
	<portClasses/>
	<wireClasses />
	<componentClasses />
	<hostRelations />
	<portTypes />
	<wireTypes />
	<componentTypes />
	</sdm>

Please read the SDM Schema specification and review the sample XSD files at http://big/for more detailed information on the SDM schema.
SDM Class

[0133] Every component, port and wire in an application/service is a type created through use of a class. New types can be created from existing classes and types. An SDM class is essentially an abstraction for common features. For example, Web Service can be modeled as class as can a SQL Database. In the MyService application, MyFrontEnd would be a new type derived from the class Web Service; and MyBackEnd would be a new type derived from the class SQL Database.

[0134] Below is an example of the class schemas for ports, wires and components.

[0135]

<portClass name=“ServerDataAceess” layer=“Application”>
	<settingSchema>
	<xs:element name=“databaseName” type=“xs:string” />
	</settingSchema>
</portClass>
<wireClass name=“DataConnection” layer=“Application”>
	<settingSchema>
	<xs:element name=“useSSL” type=“xs:boolean” />
	</settingSchema>
	<portClassesAllowed>
	<portClassRef name=“ServerDataAccess” maxOccurs=“1” />
	<portClassRef name=“ClientDataAccess” />
	</portClassesAllowed>
</wireClass>
<componentClass name=“Database” layer=“Application”>
	<deploymentSchema>
	<xs:element name=“sqlScriptFilePath” type=“xs:string”
maxOccurs=“unbounded”/>
	</deploymentSchema>
	<settingSchema>
	<xs:element name=“databaseName” type=“xs:string”/>
	</settingSchema>
	<portClassesAllowed closed=“true”>
	<portClassRef name=“ServerDataAccess” />
	</portClassesAllowed>
</componentClass>

Notice that each componentClass and wireClass schema can contain a setting schema, deployment schema and port classes allowed. The portClass does not have a port classes allowed section. These schemas are defined as follows:

• • [0136] Setting Schema is the XSD for the configuration parameters on components, ports and wires that can be design-time validated.
  • [0137] Deployment Schema is the XSD that expresses what installation parameters need to be set in order for the component, port or wire to be installed. This manifest could be the schema for Fusion or some other installer technology.
  • [0138] Port Classes Allowed is where components and wires declare the allowable ports by referencing declared port classes.
    Please refer to the SDM Schema Design Specification at http://big for more details on the class schemas.
    Class Relationships

[0139] A component, port or wire that can host other components is declared using a hostRelations schema that identifies the installer and the component classes it can host. One can think of the hostRelations element as a directional link between classes where one of the components, ports or wires is acting as a host for the others.

[0140] Hosting a component means providing the execution environment for a component's code. For example, SQL can be a host for components of class Database as shown in the example below.

[0141]

<hostRelations>
	<installer name=“DatabaseInstaller” codeType=“InstallerPlugIn“ />
	<hostRelation	classRef=“database”
componentHostClassRef=“host:SQL” installerRef=“DatabaseInstaller”
/>
</hostRelations>

SDM Types

[0142] There are three distinct spaces that the SDM models: resource, application and instance. The instance space is discussed later in this document. The resource space is where classes live and are the building blocks from which applications are constructed. The application space is where types reside. Below is an example of the XML for port, wire and component types.

[0143]

<portType name=“UserDataServer” class=“ServerDataAccess”>
	<deployment />
	<setttings />
</portType>
<wireType name=“UserData” class=“DataConnection”>
	<deployment />
	<settings>
	<useSSL>false</useSSL>
	</settings>
	<portTypeRefs>
	<portTypeRef name=“UserDataServer”/>
	<portTypeRef name=“UserDataClient”/>
	</portTypeRefs>
</wireType>
<componentType name=“SQLBackEnd” class=“Database”>
	<deployment>
<sqlScriptFilePath>%install%\mydatabaseDfn.sql</sqlScriptFilePath>
	</deployment>
	<settings>
	<databaseName>UserData</databaseName>
	</settings>
	<ports>
	<port name=“userData” type=“UserDataServer”/>
	</ports>
</componentType>

Notice each portType, wireType and componentType in the SDM schema contains setting and deployment values.

• • [0144] Settings is XML for the settings schema that supplies the configuration values for components, ports and wires and can be design-time validated.
  • [0145] Deployment is the XML for the deployment manifest that expresses the values that the configuration parameters need to be set to in order for the component, port or wire to install properly.
    Please refer to the SDM Schema Design Specification at http://big for more details on types.
    Compound Components

[0146] Compound components can be used to define an application and its topological relationships to other components, ports and wires. Compound components do not have an associated implementation and instead use delegation of ports and host relationships to expose behavior of member components and ports. The XML below shows how the compound component MyService might be described using the SDM.

[0147]

<compoundComponentType name=“MyService”>
	<components>
	<component name=“MyFrontEnd” type=“IISFrontEnd” />
	<component name=“MyBackEnd” type=“SQLBackEnd” />
	</components>
	<wires>
	<wire name=“data” type=“UserData”>
	<members>
	<member componentName=“MyFrontEnd”
portName=“serverData” />
	<member componentName=“MyBackEnd”
portName=“userData” />
	</members>
	</wire>
	</wires>
</compoundComponentType>

Instances

[0148] While components, ports and wires define the structure and behavior of an application/service, they do not define the running instances. Every component, port and wire type declaration can have one or more instances. Instances are the result of deploying an application/service such that physical resources (servers, network switch ports and disks) are allocated, and software resources (operating systems, runtime hosts, application code) are installed and configured. It is the job of the SDM Runtime to track all instances from the time of creation until they have been deleted.

SDM Runtime

[0149] The SDM Runtime does not itself create instances of components, ports and wires; instead, it provides a set of APIs that are used to coordinate the creation and management of SDM instances. The actual creation of an instance, such as a server running Windows Server with IIS as the host for a web service component, will typically involve multiple entities and could possibly take hours or days to complete.

[0150] The SDM Runtime knows when a “create SDM instance” process starts and when it terminates, either with success or failure. The SDM Runtime also knows what changes are made to an SDM instance during its lifetime. One way to think about the SDM Runtime is that it is an accountant that records all transactions related to a given application/service SDM such that it can be queried for information about the instances associated with the specified SDM. The first step in creating an SDM instance is registration of an application/service SDM with the SDM Runtime. Once the SDM Runtime knows about a given SDM, the instance creation process can be invoked using Factories and Resource Managers (explained below).

[0151] Please read the SDM Runtime Architecture specification at http://big/ for more detailed information on the APIs and runtime design.

Hosts and Factories

[0152] Components that are capable of “hosting” other components are called hosts and act as factories for the classes they support. A component can be declared a host of one or more component classes using the SDM schema hostRelations element described previously.

[0153] While hosts provide the execution environment for a component's code, factories are the actual services that create SDM instances of a given type and interact with the SDM Runtime through the SDM Runtime APIs. Factories can support one or more component classes and must register with the SDM Runtime specifying which component classes they support.

[0154] It is possible for a given factory to support multiple hosts of the same type with different configurations as well as for individual factories to exist for each type of host configuration. For example, an IIS Factory can support multiple classes such as Web Service and Web Application. Likewise, the SQL Factory can support different database types such as Database, Partitioned Database and Highly Available Database.

[0155] Factories do not themselves manage physical resources such as storage, network and servers. Factories interact with physical resources (and their logical equivalents) through Resource Managers.

Resource Managers

[0156] Resource Managers manage the physical and logical resources that are (1) discovered or created as part of a bootstrap process or (2) specified through some declarative XML-based description of the physical environment. Resource managers own all storage, network and server resources and expose a common resource management API to process resource allocation requests and to track ownership of these resources.

[0157] Examples of resource managers are the NRM (Network Resource Manager), the SRM (Storage Resource Manager), and the PRM (PC Resource Manager). Each of these resource managers is responsible for allocation of a physical port or disk or server and the logical resources they expose such as VLANs, logical disk volumes, file shares, web server, etc. Resource managers are also responsible for programming the physical devices to effect allocation and de-allocation.

[0158] In order to program the physical hardware, resource managers interact with the hardware through resource providers that hide the implementation details of the hardware device so that, for example, network switches from multiple vendors can be used interchangeably (given that a provider for the manufacturer's device exists). Like the hardware abstraction layer (HAL) and device driver model in Windows, there is an equivalent abstraction layer for the data center environment that spans servers, network and storage devices.

Layers and Mappings

[0159] While components, ports and wires are powerful abstractions when combined with hosts, factories, resource managers and the SDM runtime, they are not sufficient to deploy and manage a distributed application/service. In order to create and manage the physical instances of these logical abstractions, some additional constructs are needed. Those additional constructs are layers and mappings.

Layers

[0160] The need for layers is motivated by the desire to perform design-time validation of deployment requirements of an application/service. FIG. 3 shows the layer abstractions defined by the SDM.

• • [0161] Application layer describes the distributable components, their deployment requirements and constraints, and their communication relationships in the context of an application/service.
  • [0162] Host layer describes the configuration and policy settings and constraints for hosts such as IIS, CLR and SQL, among others.
  • [0163] Virtual Data Center (VDC) layer describes the data center environment settings and constraints from the operating system through the network topology down to the servers, network and storage devices.
  • [0164] Hardware layer is describes the physical data center environment and is either discovered or specified in a declarative manner using XML, for example. This layer is not scale-invariant and therefore not modeled in the SDM, but is included for completeness.
    Mappings

[0165] Because the SDM is layered, there needs to be a way to bind between the various layers. A mapping is essentially a binding of a component or port at one layer to a component or port at the next layer down. A mapping can be described as follows:
M_T=[T_n→T_n−1]+[T_n−1→T_n−2]+[T_n-2→T_n-3][ . . . ]

• • [0166] where M represents a mapping and T represents a component, port or wire and n represents the layer. The arrow symbol represents the direction of the mapping which is always from a higher layer to a lower layer.
    For example, in FIG. 4 the component at the application layer named MyFrontEnd is mapped to a component at the host layer called IIS. Likewise the component named MyBackEnd is mapped to the SQL component at the host layer.
    Design-time Validation

[0167] The binding between a component and its host component at the layer below can surface problems to the developer before the application/service is actually deployed in the live data center. These problems can be due to incompatible types, configuration conflicts, mismatched operations, missing topological relationships, etc. FIG. 5 depicts a settings and constraints checking error between a component and its host with regards to authentication.

[0168] In FIG. 6, the attempted mapping depicted in the diagram below would result in an error because there is no potential communication relationship between the IIS and SQL components at the deployment layer.

[0169] While the mapping from the MyBackEnd component to the SQL host component could have been a valid binding based on the component and host type compatibility and the lack of configuration conflicts, it is invalid because the MyService SDM defined a topological relationship between MyFrontEnd and MyBackEnd that does not exist at the specified deployment layer.

Settings and Constraints Checking

[0170] The ability to map from the application layer to the deployment layer (and so on) is quite powerful because it enables design-time validation of a component's settings against a host's constraints; and it also allows validation of a host's settings against a component's constraints.

[0171] FIG. 7 shows a more detailed view of the relationships between components and host at the different layers. Notice that there is a binding between a component at one layer and a host component at the next layer down all the way through to the VDC layer.

[0172] In FIG. 7, MyFrontEnd is a Web Service hosted by IIS which is in turn a Windows Application hosted by Windows Server. There is an IIS factory that supports creation and deletion of Web Service and Web Application component instances just as there is a Windows Application factory that is responsible for creating and deleting instances of IIS and SQL.

[0173] FIG. 8 shows how design-time validation would work between components at the different layers using the SDM settings and constraints semantics described previously.

[0174] Notice that the constraints of a component at the layer above are validated against the settings of a host component at the layer below. Also notice that the constraints of the host component are validated against the settings of the component to be hosted.

[0175] This two-way settings and constraint checking allows a developer to reliably develop his/her application/service in the context of the operational environment described using SDM semantics all the way down. In order to describe a data center such that its description can be relied upon during the development process, it is necessary to create an abstraction of the data center referred to as the VDC.

Virtual Data Center (VDC)

[0176] A VDC is a logical representation of a physical data center environment that simplifies the developer's view of the data center. Ideally an IT Professional or Architect should be able to describe the data center in the same scale-invariant manner that a developer can describe a distributed application/service. The way to think about the VDC is that it is an abstraction of the server, network and storage resources within the data center and their topological relationships. A typical data center diagram is quite complex with multiple interconnected servers, network equipment, IP addresses, VLANs, operating systems, storage, etc. all expressed on a single diagram drawn using Visio or a similar tool. In addition to the diagram, there are usually long documents that prescribe exactly how the data center is partitioned, configured and managed.

[0177] An example of this complexity is the Microsoft Systems Architecture (MSA) Enterprise Data Center (EDC). It should be obvious that keeping the manually drawn diagrams and documents current with the state of the data center over time as updates and upgrades are applied becomes a costly if not impossible task. Likewise, the ability to validate the environment against the document prescriptions is difficult and prone to human error.

[0178] The ability to represent a complex data center such as the MSA EDC in a scale-invariant manner would be immensely powerful to both the developer and the IT professional. The ability to describe a data center using components, ports and wires provides a powerful framework within which to model and validate deployment requirements that is missing in today's design and deployment process.

SDM Fundamentals

The SDM:

• • [0179] Defines abstractions that make it easier to design distributed applications/services.
  • [0180] Enables a framework for reuse and automation of operational practices.
  • [0181] Simplifies deployment and operations of distributed applications and services.

[0182] It can be easier to understand what the SDM is by considering that it captures what today is often seen as a complex diagram on the wall near the operators of a service. In these diagrams a box typically represents a running element of the service and the lines connecting the boxes represent communication paths between the service elements. For example, a load balancer connected to some IIS front-end machines which in turn are connected to one or more middle-tier or back-end services.

[0183] Another way to think about the SDM is that it is both a meta-model for the behavior of distributed applications/services and a “live” blueprint of a running application/service in its computing environment. The SDM captures the structure of the application in its computing environment, including its allowable software operations, in a declarative and scale-invariant manner. The ability to declaratively describe the topology of a service, including the bindings between the hardware and network resources, and the valid operations of its software components, is quite powerful.

[0184] As an analogy, let's look at Microsoft's Common Object Model (COM). COM standardized how components are packaged, registered, activated, discovered, etc. COM mandates strict rules related to lifetime, memory management and interface implementation. These primitives are essential for interoperability because they allow components to be treated as black boxes. COM is the basis for more sophisticated services such as eventing, automation, and OLE.

[0185] Likewise the SDM needs to define some basic primitives on which to build more sophisticated capabilities. These primitives are:

• • [0186] Components—units of implementation, deployment and management.
  • [0187] Ports—named end-points that have an associated type and a set of valid operations.
  • [0188] Wires—permissible communication paths between ports.
  • [0189] Layers—separation of resource management ownership and bindings.
  • [0190] Mappings—bindings between components, ports and wires at each layer.
    The remainder of this document will describe each of these primitives in more detail.
    Components, Ports and Wires

[0191] For the purposes of this document, it is useful to consider a graphical representation of a simple service called MyService drawn using components, ports and wires.

In FIG. 2, boxes represent components, diamonds represent ports, and dashed lines represent wires.

• • [0192] MyService is a compound component because it uses the components MyFrontEnd and MyBackEnd.
  • [0193] MyService has one visible port called web which is a delegated port implemented by the MyFrontEnd component.
  • [0194] MyFrontEnd has two ports, the delegated port and a port labeled catalog.
  • [0195] MyBackEnd has one port labeled data.
  • [0196] The MyFrontEnd and MyBackEnd components have a potential communication relationship that binds the catalog port to the data port through a wire.
    Components

[0197] Components are units of implementation, deployment and management. Examples of components are a dedicated server running Windows Server, an IIS virtual web site or a SQL database. Components generally have machine boundaries, but are not required to as evidenced by multiple IIS virtual web sites hosted on a single server.

[0198] Components expose functionality through ports and communicate through wires. Simple components can only have ports as members. Components that use other components are referred to as compound components, which can have ports and wires as members in addition to other components.

[0199] Compound components are created through composition and do not have any implementation associated with them. Compound component ports are delegated ports from inner components. Compound components make collocation, encapsulation and reuse possible and so can be thought of as a way to organize an application/service and its behaviors.

[0200] Only the public ports of a component are visible outside the component. Compound components to the outside world look like simple components with the internal structure of the components they use hidden through encapsulation. In fact, a simple component could be replaced with a compound component or vice versa as along as the port types and behaviors supported by both are exactly the same.

Ports

[0201] Ports are named end-points that have an associated type and are typically associated with a protocol role and a set of allowed operations. Examples of ports are an HTTP server port, a SOAP port with a set of allowed operations, etc. Ports can be delegated which means that an outer component can expose the port of an inner component as its own.

[0202] Ports form the public interface (behavior) to a component. Ports are the only members of a component that can be made public (visible).

Wires

[0203] Wires are permissible bindings between ports and represent topological relationships between ports (and components). Wires do not specify any instance interconnect topology but instead express a “potentiality” for an instance interconnect topology.

[0204] Wires are essentially busses and can contain one or more port members. Wires should not be mistaken for a point-to-point relationship. A given port cannot appear more than once within the same wire.

Schema

[0205] In order to describe an application/service, it is necessary to have a standard schema for the SDM. The SDM schema should be expressible using XSD and XML grammars. While it is beyond the scope of this document to describe the SDM schema in great detail, it is necessary to provide some brief explanation as context for the subject matter described later in this document. Below is a simplified view of the SDM schema.

[0206]

	<sdm>
	<import />
	<identityReference />
	<information />
	<portImplementationType />
	<wireImplementationType />
	<componentImplementationType />
	<hostRelations />
	<portTypes />
	<wireTypes />
	<componentTypes />
	</sdm>

Please read the SDM Schema specification and review the sample XSD files at http://big/for more detailed information on the SDM schema.
Types

[0207] Every component, port and wire used in an application/service is a type. Type is essentially equivalent to class in object-oriented languages like C++ and C#, and like it is with classes, new types can be created from existing types. The scale-invariant space is represented in the SDM schema by portTypes, wireTypes and componentTypes. Scale-invariance implies that a component, port or wire can be represented once in an application/service SDM even though there may be multiple instances of each in the actual data center.

[0208] A type is ultimately derived from an implementation type, which is essentially an abstraction for common technology features. For example, Web Service can be modeled as an implementation type as can SQL Database. In the MyService application, MyFrontEnd would be a new type derived from the implementation type Web Service and MyBackEnd would be a new type derived from the implementation type SQL Database.

[0209] Each componentImplementationType and wireImplementationType SDM schema element can contain a settings schema, deployment manifest and port implementation reference. The portImplementationType element does not have a port implementation reference. FIG. 9 illustrates what the SDM implementation type space looks like.

• • [0210] Settings Schema is the XSD for the configuration parameters on components, ports and wires that can be design-time validated.
  • [0211] Deployment Manifest is the XSD that expresses what installation parameters need to be set in order for the component, port or wire to be installed. This manifest could be the schema for Fusion or some other installer technology.
  • [0212] Port Implementation Reference is where components and wires declare the allowable ports by referencing declared port implementation types.

[0213] In addition, a component that can host other components is declared using a hostRelations SDM schema element that identifies the installer and the component implementation types it can host. One can think of the hostRelations element as a directional link between component implementation types where one of the components is acting as a host for the other component(s). Hosting a component means providing the execution environment for a component's code. For example, IIS is a host for components of implementation type Web Service and Web Application. Hosts will be explained in more detail later in this document.

[0214] Each portType, wireType and componentType element in the SDM schema contains application constraint values, deployment values and host constraint values. In addition, the wireType element contains a port types element that defines the allowable port types on the specified wire type; and the componentType element contains a hosted types list element that identifies those implementation types that can be hosted on the specified component type. FIG. 10 shows the SDM type space.

• • [0215] Settings Values is XML for the settings schema that supplies the configuration values for components, ports and wires and can be design-time validated against a host's constraints values.
  • [0216] Deployment Values is the XML for the deployment manifest that expresses the values that the configuration parameters need to be set to in order for the component, port or wire to function properly.
  • [0217] Constraints Values is the XML for the settings schema that supplies the configuration parameter values that a component, port or wire of a host must be set to. Constraints values can be design-time validated against the settings values of the underlying host.
  • [0218] Port Types is the XML that lists the allowable port types that can be a member of the specified wire.
  • [0219] Hosted Type List is the XML where a component declares the list of component implementation types it can host.
    Instances

[0220] While components, ports and wires define the structure and behavior of an application/service, they do not define the running instances. Every component, port and wire type declaration can have one or more instances. Instances are the result of deploying an application/service such that physical resources (servers, network switch ports and disks) are allocated, and software resources (operating systems, runtime hosts, application code) are installed and configured.

[0221] It is the job of the SDM Runtime to track all instances from the time of creation until they have been deleted.

SDM Runtime

[0222] The SDM Runtime does not itself create instances of components, ports and wires; instead, it provides a set of APIs that are used to coordinate the creation and management of SDM instances. The actual creation of an instance, such as a server running Windows Server with IIS as the host for a web service component, will typically involve multiple entities and could possibly take hours or days to complete.

[0223] The SDM Runtime knows when a “create SDM instance” process starts and when it terminates, either with success or failure. The SDM Runtime also knows what changes are made to an SDM instance during its lifetime. One way to think about the SDM Runtime is that it is an accountant that records all transactions related to a given application/service SDM such that it can be queried for information about the instances associated with the specified SDM.

[0224] The first step in creating an SDM instance is registration of an application/service SDM with the SDM Runtime. Once the SDM Runtime knows about a given SDM, the instance creation process can be invoked using Factories and Resource Managers (explained below).

[0225] Please read the SDM Runtime Architecture specification at http://big/ for more detailed information on the APIs and runtime design.

Hosts and Factories

[0226] Components that are capable of “hosting” other components are called hosts and act as factories for the implementation types they support. A component can be declared a host of one or more component implementation types using the SDM schema hostRelations element described previously.

[0227] While hosts provide the execution environment for a component's code, factories are the actual services that create SDM instances of a given type and interact with the SDM Runtime through the SDM Runtime APIs. Factories can support one or more component implementation types and must register with the SDM Runtime specifying which component implementation types they support. It is possible for a given factory to support multiple hosts of the same type with different configurations as well as for individual factories to exist for each type of host configuration. For example, an IIS Factory can support multiple implementation types such as Web Service and Web Application. Likewise, the SQL Factory can support different database types such as Database, Partitioned Database and Highly Available Database.

[0228] Factories do not themselves manage physical resources such as storage, network and servers. Factories interact with physical resources (and their logical equivalents) through Resource Managers.

Resource Managers

[0229] Resource Managers manage the physical and logical resources that are (1) discovered or created as part of a bootstrap process or (2) specified through some declarative XML-based description of the physical environment. Resource managers own all storage, network and server resources and expose a common resource management API to process resource allocation requests and to track ownership of these resources.

[0230] Examples of resource managers are the NRM (Network Resource Manager), the SRM (Storage Resource Manager), and the PRM (PC Resource Manager). Each of these resource managers is responsible for allocation of a physical port or disk or server and the logical resources they expose such as VLANs, logical disk volumes, file shares, web server, etc. Resource managers are also responsible for programming the physical devices to effect allocation and de-allocation.

[0231] In order to program the physical hardware, resource managers interact with the hardware through resource providers that hide the implementation details of the hardware device so that, for example, network switches from multiple vendors can be used interchangeably (given that a provider for the manufacturer's device exists). Like the hardware abstraction layer (HAL) and device driver model in Windows, there is an equivalent abstraction layer for the data center environment that spans servers, network and storage devices.

Layers and Mappings

[0232] While components, ports and wires are powerful abstractions when combined with hosts, factories, resource managers and the SDM runtime, they are not sufficient to deploy and manage a distributed application/service. In order to create and manage the physical instances of these logical abstractions, some additional constructs are needed. Those additional constructs are layers and mappings.

Layers

[0233] The need for layers is motivated by the desire to perform design-time validation of deployment requirements of an application/service. FIG. 11 shows the layer abstractions defined by the SDM.

• • [0234] Application layer describes the distributable components, their deployment requirements and constraints, and their communication relationships in the context of an application/service.
  • [0235] Deployment layer describes the configuration and policy settings and constraints for hosts such as IIS, CLR and SQL, among others.
  • [0236] Virtual Data Center (VDC) layer describes the data center environment settings and constraints from the operating system through the network topology down to the servers, network and storage devices.
  • [0237] Hardware layer is describes the physical data center environment and is either discovered or specified in a declarative manner using XML, for example. This layer is not scale-invariant and therefore not modeled in the SDM, but is included for completeness.
    Mappings

[0238] Because the SDM is layered, there needs to be a way to bind between the various layers. A mapping is essentially a binding of a component or port at one layer to a component or port at the next layer down. A mapping can be described as follows:
M_T=[T_n→T_n−1]+[T_n−1→T_n−2]+[T_n−2→T_n−3][ . . .]

• • [0239] where M represents a mapping and T represents a component, port or wire and n represents the layer. The arrow symbol represents the direction of the mapping which is always from a higher layer to a lower layer.
    For example, in FIG. 12 the component at the application layer named MyFrontEnd is mapped to a component at the deployment layer called IIS. Likewise the component named MyBackEnd is mapped to the SQL component at the deployment layer.
    Design-time Validation

[0240] The binding between a component and its host component at the layer below can surface problems to the developer before the application/service is actually deployed in the live data center. These problems can be due to incompatible types, configuration conflicts, mismatched operations, missing topological relationships, etc. For example, the attempted mapping depicted in FIG. 13 would result in an error because there is no potential communication relationship between the IIS and SQL components at the deployment layer.

[0241] While the mapping from the MyBackEnd component to the SQL host component could have been a valid binding based on the component and host type compatibility and the lack of configuration conflicts, it is invalid because the MyService SDM defined a topological relationship between MyFrontEnd and MyBackEnd that does not exist at the specified deployment layer.

Settings and Constraints Checking

[0242] The ability to map from the application layer to the deployment layer (and so on) is quite powerful because it enables design-time validation of a component's settings against a host's constraints; and it also allows validation of a host's settings against a component's constraints.

[0243] FIG. 14 shows a more detailed view of the relationships between components and host at the different layers. Notice that there is a binding between a component at one layer and a host component at the next layer down all the way through to the VDC layer.

[0244] In FIG. 14, MyFrontEnd is a Web Service hosted by IIS which is in turn a Windows Application hosted by Windows Server. There is an IIS factory that supports creation and deletion of Web Service and Web Application component instances just as there is a Windows Application factory that is responsible for creating and deleting instances of IIS and SQL.

[0245] FIG. 15 shows how design-time validation would work between components at the different layers using the SDM settings and constraints semantics described previously.

[0246] Notice that the constraints of a component at the layer above are validated against the settings of the host component at the layer below. Also notice that the constraints of the host component are validated against the settings of the component to be hosted.

[0247] This two-way settings and constraint checking allows a developer to reliably develop his/her application/service in the context of the operational environment described using SDM semantics all the way down. In order to describe a data center such that its description can be relied upon during the development process, it is necessary to create an abstraction of the data center referred to as the VDC.

Virtual Data Center (VDC)

[0248] A VDC is a logical representation of a physical data center environment that simplifies the developer's view of the data center. Ideally an IT Professional or Architect should be able to describe the data center in the same scale-invariant manner that a developer can describe a distributed application/service. The way to think about the VDC is that it is an abstraction of the server, network and storage resources within the data center and their topological relationships. A typical data center diagram is quite complex with multiple interconnected servers, network equipment, IP addresses, VLANs, operating systems, storage, etc. all expressed on a single diagram drawn using Visio or a similar tool. In addition to the diagram, there are usually long documents that prescribe exactly how the data center is partitioned, configured and managed.

[0249] An example of this complexity is the Microsoft Systems Architecture (MSA) Enterprise Data Center (EDC). It should be obvious that keeping the manually drawn diagrams and documents current with the state of the data center over time as updates and upgrades are applied becomes a costly if not impossible task. Likewise, the ability to validate the environment against the document prescriptions is difficult and prone to human error.

[0250] The ability to represent a complex data center such as the MSA EDC in a scale-invariant manner would be immensely powerful to both the developer and the IT professional. The ability to describe a data center using components, ports and wires provides a powerful framework within which to model and validate deployment requirements that is missing in today's design and deployment process.

[0251] Agenda: Overview, SDM Building Blocks, Example Application, Example Host, Logical Placement, Deployment, Status.

[0252] The SDM is a meta-model well-suited for capturing the elemental pieces of distributed applications and their deployment environments. The SDM is authoritative: Application and environment are constructed from their SDM, Changes to the application and environment will be done through the SDM. Provide a namespace for management processes.

[0253] The Service Definition Model refers to a collection of interrelated schemas:

[0254] Classes, class relationship and installer schema

[0255] Component, Port and Wire Types schema

[0256] Logical placement schema

[0257] Physical placement schema

[0258] Instantiation request schema

[0259] Instance schema

[0260] SDM Classes are the basic building blocks for all distributed applications and deployment environments. Application classes: ASP.Net Web Service, ASP.Net Web Site, BizTalk Orchestration Schedule, Services Components (COM+), etc. Service classes: IIS Server, SQL Server, BizTalk Server. OS, Network & Storage classes: Windows VLAN, Filter, Disk, etc. Hardware classes: Server, Switch, Firewall, Load Balancer, SAN, etc. Classes are authored by system level developers and don't change frequently. Classes are behind every component, port and wire in the SDM. Each class contains a schema for its public settings (simply called settings) and private settings (called deployment). Relationships are captured between classes: component class to port class, wire class to port class, and component class to component class.

[0261]

ASP.Net Web Site Class
	<componentClass name=“Web Site”
	layer=“Application”>http://big/
	<settingSchema><xs:schema><xs:complexType>
	<xs:sequence>
	<xs:element name=“webSiteName” type=“xs:string”/>
	<xs:element name=“authentication” type=“xs:string”/>
	<xs:element name=“sessionState” type=“xs:boolean”/>
	</xs:sequence></xs:complexType></xs:schema>
	</settingSchema>
	<deploymentSchema><xs:schema><xs:complexType>
	<xs:sequence>
	<xs:element name=“fusionManifest” type=“xs:string”/>
	</xs:sequence></xs:complexType></xs:schema>
	</deploymentSchema>
	<portClassesAllowedclosed=“true”>
	<portClassRef name=“ClientDataAccess” />
	<portClassRef name=“WebServer” maxOccurs=“1”/>
	<portClassRef name=“SoapClientInterface” />
	<portClassRef name=“RemotingClientInterface” />
	</portClassesAllowed>
	</componentClass>
SOAP Client Port Class
	<portClass name=“SoapClientInterface“
	layer=“Application”>http://big/
	<settingSchema><xs:schema><xs:complexType><xs:sequence>
	<xs:element name=“formatter” type=“xs:string”/>
	<xs:element name=“transport” type=“xs:string”/>
	</xs:sequence></xs:complexType></xs:schema>
	</settingSchema>
	<deploymentSchema><xs:schema><xs:complexType>
	<xs:sequence>
	<xs:element name=“wsdlFile” type=“xs:string”/>
	</xs:sequence></xs:complexType></xs:schema>
	</deploymentSchema>
	</portClass>
SOAP Wire Class
	<wireClass name=“SoapConnnection” layer=“Application”>
	<settingSchema/>
	<deploymentSchema/>
	<portClassesAllowed>
	<portClassRef name=“SoapServerInterface”/>
	<portClassRef name=“SoapClientInterface”/>
	</portClassesAllowed>
	</wireClass>
IIS Component Class
	<componentClass name=“IIS” layer=“Service”>
	<settingSchema><xs:schema><xs:complexType>
	<xs:sequence>
	<xs:element name=“certificateAuth”
	type=“xs:boolean”/>
	<xs:element name=“ntlmAuth” type=“xs:boolean”/>
	<xs:element name=“sessionStateType”
	type=“xs:string”/>
	</xs:sequence></xs:complexType></xs:schema>
	</settingSchema>
	<deploymentSchema><xs:schema><xs:complexType>
	<xs:sequence>
	<xs:element name=“fusionManifest” type=“xs:string”/>
	</xs:sequence></xs:complexType></xs:schema>
	</deploymentSchema>
	- <portClassesAllowed>
	<portClassRef name=“HTTPServer”/>
	<portClassRef name=“HTTPClient”/>
	<portClassRef name=“TDSClient”/>
	</portClassesAllowed>
	</componentClass>
Class Relationships and Installers
	<hostRelation classRef=“WebSite” hostClassRef=“IIS”
installerRef=“WebSiteInstaller”/>
	<installer name=“WebSiteInstaller” code=“WebSiteInstaller,
	IISInstaller”
codeType=“assembly“ />
<HostRelation> captures a hosting relationship between classes:
IIS can host Web Sites

Installers are “plugins” into the SDM Runtime that are responsible for creating a new instances of the component, port and/or wire classes. Installers are also responsible for configuring instances of the class. Different installers might use the same underlying deployment & configuration technology, such as Fusion or WMI.Config.
Distributed Application

[0262] Distributed Applications are constructed from component, port and wire classes. Developers create component, port and wire types from classes. Types are “uses” of classes and supply the values of the setting and deployment schema. Types are a units of reuse. Types map to a single project in Visual Studio.

[0263] SDM supports composition of types through compound component types. Composition allows bigger distributed applications to be built from smaller ones. Compound component types map to a new project type in Visual Studio—Whitehorse.

[0264]

FMStocks.Web Component Type
	<componentType name=“FMStocks.Web” class=“WebSite”>
	<ports>
	<port name=“web” type=“webServer”/>
	<port name=“stock” type=“StockClient”/>
	<port name=“accounts” type=“AccountClient”/>
	<port name=“trades” type=“TradeClient”/>
	</ports>
	<settings>
	<webSiteName>FMStocks.Web</webSiteName>
	<authentication>Certificate</authentication>
	<sessionState>true</sessionState>
	</settings>
	<deployment>
	<fusionManifest>fmstocks.web.manifest
	</fusionManifest>
	</deployment>
	</componentType>
FMStocks7 Compound Component Type
	<compoundComponentType name=“FMStocks”>
	<components>
	<component name=“web” type=“FMStocks.Web”/>
	<component name=“svc” type=“FMStocks.WebService”/>
	<component name=“biz”
	type=“FMStocks.BusinessService”/>
	<component name=“custdb”
	type=“FMStocks.CustomerDatabase”/>
	</components>
	<wires/>
	<delegatePorts>
	<port name=“web” componentname=“web”
	portname=“web”/>
	<port name=“svc” componentname=“svc”
	portname=“svc”/>
	</delegateports>
	</componentType>

SDU and Deployment Environment

[0265] Component, port and wire types for a distributed application are packaged along with any binaries in an Service Deployment Unit (SDU). Binaries include all .DLLs, .EXE, config, static content, etc. SDU represents a portable, independently installable, distributed application. Analogous to the Windows Installer MSI file for Desktop applications. But, unlike desktop applications which primarily target a uniform environment (Windows), distributed applications. Can be hosted on different deployment environments that vary significantly. Must be able to express their requirements on the deployment environment. Must honor all policies of their deployment environment.

[0266] Therefore, we need a model to express requirements and constraints of both the application and the deployment environment. My WebSite component type needs an IIS server that has been configured with sessions state stored in a SQL database. The web zone will only host webSites components that are using certificate authentication.

[0267]

IIS Component Type
	<componentType name=“WebTierIIS” class=“IIS”>
	<ports/>
	<settings>
	<certificateAuth>true</certificateAuth>
	<ntlmAuth>false</ntlmAuth>
	<sessionStateType>true</sessionStateType>
	</settings>
	<deployment/>
	<hostedClasses>
	<hostedClass class=“WebSite”>
	<!-- constraint language expressed using
	XPath -->
	<constraint>/[authentication=
	“certificate”</constraint>
	</hostedClass>
	</hostedClasses>
	</componentType>
FMStocks.Web Component Type (revisited)
	<componentType name=“FMStocks.Web” class=“WebSite”>
	<ports/>
	<settings>
	<webSiteName>FMStocks.Web
	</webSiteName>
	<authentication>Certificate
	</authentication>
	<sessionState>true</sessionState>
	</settings>
	<deployment>
	<fusionManifest>fmstocks.web.manifest
	</fusionManifest>
	</deployment>
	<hostConstraints>
	<hostConstraint hostClass=“IIS”>
	<constraints>/[sessiontStateType=
	“SQL”]</constraints>
	</hostConstraint>
	</hostConstraints>
	</componentType>

Logical Placement

[0268] Before an SDU can be deployed, we must first do a logical placement of the types on the target deployment environment. Logical placement can be done at design time. Requirements and constraints are checked and the developer is alerted of any errors or warnings. The result of the logical placement is captured in a separate file from the SDU. An SDU can be have different logical placements for different deployment environments (Development, Test, Production, etc.) Constraint checking is implemented using XPath and the XSD specified on each component, port and wire class.

Building the Deployment Environment

[0269] Deployment environments are built using the SDM model. See FIG. 22. In essence, they are SDM Applications at a different layer. Component, port and wire types are used in the same way to compose service hosts, network architectures, and hardware. In the Whidbey timeframe we will support deploying the application layer only. In ADS V2.0 we will be able to deploy the Service Host, Network and Hardware Layers. Visual studio is building a designer for authoring deployment environments. Visual Studio refers to this as the Logical Infrastructure Model. FIG. 23 illustrates an example deployment.

Instance Request Document

[0270] SDM types are scale invariant and can be created to any scale. The Instance Request Document is a declarative definition of the instances that need to be created. Includes the wiring topology. FIG. 24 illustrates example types and FIG. 25 illustrates example instance requests.

Physical Placement

[0271] Physical placement is the act of picking the specific host instance that is the target of deployment. Physical placement is constrained by the logical placement. Constraints are revalidated during physical placement. See FIG. 26.

Deployment

[0272] SDU, Logical Placement file, Instance Request, and Physical Placement file are fed into the SDM Runtime. The SDM Runtime will then invoke the appropriate installer based on the class and host relationship. The installer is responsible for creating a new instance on the host and configuring it to match the settings values on the type. SDM Runtime will maintain a database of all instances, their final setting values, and placement. Runtime API will support querying of the instance space.

SDM Schema Design Specification

[0273] There are three core elements of the SDM schema: ports, wires and components. Ports represent communication endpoints, components represent parts of a distributed application and wires represent communication links between applications parts. These appear in different forms in three separate spaces: the resource space, the application space, and the instance space.

[0274] In the resource space, the resource classes that applications in the application space will be built from are defined. These classes provide a common categorization of the application parts allowing tool support for a wide range of applications and providing the basis for type checking at design time. We expect these core classes to provide a comprehensive set of features for service design and we expect that they will change slowly over time.

[0275] In the application space, application types are built. We take a resource class and fill in the details, such as providing links to content, and providing setting values for the properties. We then build distributed applications from these types by associating port types with component types, using component types within a compound component types and describing the communication relationships between the members of a compound component type by using wire types.

[0276] The instance space consists of the instances created during the process deploying and running an application. We expose the communication relationships we defined in application space through the SDM runtime thus allowing instances to find other instances.

Resource Classes

[0277] We use resource classes to define the elements of application that we need to know about in order to check configuration at design time and then to deploy at run time. These elements are:

• • [0278] a) Who an application communicates with. In order to verify a distributed application against a network topology we need to know about the protocols that parts of the application can use to communicate with each other. Port classes are used to describe protocol end points. Wire classes are used to describe the relationships that can be constructed between these endpoints.
  • [0279] b) What settings apply to an application and how is it deployed. Component classes define building blocks that can be used to construct an application. A component class defines the settings that can be used to control behavior specific to the component and defines a schema for the files and scripts that can be provided to deploy the component.
  • [0280] c) What an application depends on in order to function correctly. In order to work correctly a component may depend on certain functionality that must already exist in the target environment. An example is a web service that depends on IIS. We express these requirements as hosting relationships between resources. Using these relationships we can build a dependency tree over the set of resource types that allows us to check ahead of time whether a specific application will run in a particular environment.
    Application Types

[0281] We build applications types using the resource classes defined in the resource space. From these classes, we derive port types and wire types to model application specific communication links and we build component types to model the discrete parts of the application.

[0282] Port types are communications endpoints that describe behavior particular to an application. We take a port resource and provide information that is specific to its use within the application. An example might be a port type that takes a soap resource and provides a WSDL file to define the functions that the application exposes.

[0283] Wire types define application specific communication paths. A wire type confines a particular wire resource to connecting two compatible application end points. For example, we might take a soap wire resource and confine it to connecting the soap port types that we defined above.

[0284] Component types are used to model the parts of an application that can be deployed independently and can also be distributed across machine boundaries. For example, an application having a web front end and a database backend is likely to consist of several component types. In this case we might take a web service resource and use it to create the web front end component type and a database resource to create the database backend component type. We would then add the appropriate port types to the component types in order to model the application interfaces. We call these port members.

[0285] Compound component types used are group component types together to form a new component type. A use of a component type inside a compound component is called a component member. We connect the interfaces that component members expose to other members using the wire types we defined earlier. These become the wire members of the compound component.

[0286] In order for compound components to look like a component, they need to expose interfaces, capabilities and requirements just like a component. We do this by delegating out a subset of the ports members from the component members of the compound component.

[0287] In order to satisfy the requirements of a component we have to bind that component to another component that has matching capabilities. We call this process binding.

Exemplary Implementation

[0288] In this section we describe the XML schema that we use to define the elements of the SDM model. Settings are used by both applications and resources so we describe them first, then we describe resource classes, then application types and finally the instance space.

Naming

[0289] Namespaces are used to define naming scopes within which classes and types can be defined. Within a namespace all class and type names are unique. A namespace is defined by a name, version, and a cryptographic key that can be used to validate the contents of the namespace.

[0290]

<xs:attributeGroup name=“identity”>
	<xs:attribute name=“name” type=“xs:string” use=“required”/>
	<xs:attribute name=“version” type=“fourPartVersionType”
	use=“required”/>
	<xs:attribute name=“publicKeyToken” type=“publicKeyTokenType”
	use=“optional”/>
</xs:attributeGroup>

A file version is defined by a four part number of the form N.N.N.N where 0<N<65535.

[0291]

<xs:simpleType name=“fourPartVersionType”>
	<xs:annotation>
	<xs:documentation>Four part version numbers where
	the segments
are in the range 0–65535 </xs:documentation>
	</xs:annotation>
	<xs:restriction base=“xs:string”>
	<xs:pattern value=“(0|[1–5][0–9]{0,4}|[7–9][0–9]{0,3}|6[0–
4][0–9]{0,3}|6[6–9][0–9]{0,2}|65|65[0–4][0–9]{0,2}|65[6–9][0–
9]?|655|655[0–2][0–9]?|655[4–9]|6553[0–5]?).(0|[1–5][0–9]{0,4}|[7–9][0–
9]{0,3}|6[0–4][0–9]{0,3}|6[6–9][0–9]{0,2}|65|65[0–4][0–9]{0,2}|65[6–
9][0–9]?|655|655[0–2][0–9]?|655[4–9]|6553[0–5]?).(0|[1–5][0–9]{0,4}|[7–
9][0–9]{0,3}|6[0–4][0–9]{0,3}|6[6–9][0–9]{0,2}|65|65[0–4][0–
9]{0,2}|65[6–9][0–9]?|655|655[0–2][0–9]?|655[4–9]|6553[0–5]?).(0|[1–
5][0–9]{0,4}|[7–9][0–9]{0,3}|6[0–4][0–9]{0,3}|6[6–9][0–9]{0,2}|65|
65[0–4][0–9]{0,2}|65[6–9][0–9]?|655|655[0–2][0–9]?|655[4–9]|6553[0–
5]?)”/>
	</xs:restriction>
	</xs:simpleType>

A public key token is a 16 character hex string that identifies the public part of a public/private key pair. The document will be signed using the private key, allowing the user of the document to verify its contents using the public key.

[0292]

	<xs:simpleType name=“publicKeyTokenType”>
	<xs:annotation>
	<xs:documentation>Public Key Token: 16 hex digits in
	size</xs:documentation>
	</xs:annotation>
	<xs:restriction base=“xs:string”>
	<xs:pattern value=“([0–9]|[a–f]|[A–F]){16}”/>
	</xs:restriction>
	</xs:simpleType>

Simple names within the namespace are then constructed using strings. We allow namespaces to reference other namespaces by importing them into the current namespace and then associating an alias with the namespace.

[0293]

	<xs:complexType name=“import”>
	<xs:attribute name=“alias” type=“xs:string” use=“required”/>
	<xs:attributeGroup ref=“identity”/>
	</xs:complexType>

[0294] References to classes and types are then either simple names that refer to objects defined in the current namespace or compound names that use both an alias and a simple name to identify an object defined in another namespace.

Settings

[0295] Both resource classes and application types can expose a settings schema. This schema is used to describe the values that can be provided when a new port, wire or component type is created from a class, when a port type is added to a component type, or when a wire type or component type is used in a compound component type.

Settings Schema

[0296] We use XSD to describe the settings schema. For the initial release we use a subset of XSD that is limited to simple types and a list of element types.

[0297]

<xs:complexType name=“settingSchema”>
	<xs:sequence>
	<xs:any namespace=“http://www.w3.org/2001/XMLSchema”
	processContents=“skip” minOccurs=“0”
maxOccurs=“unbounded”/>
	</xs:sequence>
</xs:complexType>

Setting Values

[0298] Setting values are provided when a type is created based on a class or when a type is used inside a component or compound component. The settings values are a XML block that conforms to the appropriate settings schema.

[0299]

	<xs:complexType name=“settingValues”>
	<xs:sequence>
	<xs:any namespace=“##other” processContents=“lax”/>
	</xs:sequence>
	</xs:complexType>

Settings Flow

[0300] We use settings flow to allow settings values to pass from the component type to the members of the component type. Settings flow is implemented using XPATH in setting values sections that select values from the settings schema defined by the type.

[0301] We identify values that we want to flow contents to by the use of a special attribute that is defined in the SDM namespace. If this attribute exists on an element then we expect the attribute value to be an XPath into the settings schema for the type.

Settings Constraints

[0302] Settings constraints are used to validate and constrain settings values. For example an IIS server may require all web services that it hosts to have some of their settings values confined to a particular value or range of values. We use XPATH to validate settings values (or XQUERY once it is fully supported). We support the following forms of query:

• • [0303] Path must exist.
  • [0304] Path must not exist.
  • [0305] If path exists then [(path must exist|path must not exist)*]

[0306] Using the first form we can require settings to be set to a particular value or set of values, using the second we can require that a setting not be set to a value or set of values and using the third form we can construct relationships between settings requiring combinations of settings to be set together.

[0307]

	<xs:complexType name=“settingConstraints”>
	<xs:sequence>
	<xs:element name=“mustExist” type=“simpleTest”
	minOccurs=“0” maxOccurs=“unbounded”/>
	<xs:element name=“mustNotExist” type=“simpleTest”
	minOccurs=“0” maxOccurs=“unbounded”/>
	<xs:element name=“ifExists” type=“nestedTest”
	minOccurs=“0” maxOccurs=“unbounded”/>
	<xs:element name=“ifNotExists” type=“nestedTest”
	minOccurs=“0” maxOccurs=“unbounded”/>
	</xs:sequence>
	</xs:complexType>
	<xs:attributeGroup name=“testAttributes”>
	<xs:attribute name=“path” type=“xs:string”/>
	<xs:attribute name=“ifNullPath” type=“ifNullPath”/>
	<xs:attribute name=“error” type=“xs:int”/>
	<xs:attribute name=“errorDesc” type=“xs:string”/>
	</xs:attributeGroup>
	<xs:complexType name=“simpleTest”>
	<xs:attributeGroup ref=“testAttributes”/>
	</xs:complexType>
	<xs:complexType name=“nestedTest”>
	<xs:sequence>
	<xs:element name=“mustExist” type=“simpleTest”
	minOccurs=“0” maxOccurs=“unbounded”/>
	<xs:element name=“mustNotExist” type=“simpleTest”
	minOccurs=“0” maxOccurs=“unbounded”/>
	<xs:element name=“ifExists” type=“nestedTest”
	minOccurs=“0” maxOccurs=“unbounded”/>
	<xs:element name=“ifNotExists” type=“nestedTest”
	minOccurs=“0” maxOccurs=“unbounded”/>
	</xs:sequence>
	<xs:attributeGroup ref=“testAttributes”/>
	</xs:complexType>

[0308] We need to expose options for dealing with the case when the path does not exist. The following allow the designer to choose to raise an error, insert a value or ignore the test.

[0309]

	<xs:simpleType name=“ifNullPath”>
	<xs:restriction base=“xs:string”>
	<xs:enumeration value=“skip”/>
	<xs:enumeration value=“override”/>
	<xs:enumeration value=“returnError”/>
	</xs:restriction>
	</xs:simpleType>

[0310] The following is a simple schema modeling values a computer class might expose. The schema has a single top level node that identifies the settings group and three properties underneath the node.

[0311]

<settingSchema>
	<xs:schema>
	<xs:element name=“processorSettings”>
	<xs:complexType>
	<xs:sequence>
	<xs:element name=“numberOfCpus”
	type=“xs:int”/>
	<xs:element name=“memory” type=“xs:int” />
	<xs:element name=“dualHomed”
	type=“xs:boolean”/>
	</xs:sequence>
	</xs:complexType>
	</xs:element>
	</xs:schema>
</settingSchema>

We could provide the following values for the schema within a type.

[0312]

	<settings>
	<processorSettings>
	<numberOfCpus>4</numberOfCpus>
	<memory>8000</memory>
	<dualHomed>false</dualHomed>
	</processorSettings>
	</settings>

[0313] If we wanted to provide the settings values when the type was used then we would use settings flow.

[0314] Constraints may be written against these values. In the example, the first is a simple mustExist constraint. The second constraint uses a test to determine whether to evaluate the nested constraints.

[0315]

	<constraints>
	<mustExist path=“ProcessorSettings/[memory >= 1000]”
	errorDesc=“Host machine does not have enough
	memory”/>
	<ifExists path=“ProcessorSettings/[cpu >= 2]”
	errorDesc=“Host machine has two processors but
	not enough
	resources”>
	<mustExist path=“ProcessorSettings/[memory >= 2000]”
	errorDesc=“Host machine does not have enough
	memory”/>
	</ifExists >
	</constraints>

Resources
Base Class

[0316] All resource class schemas derive from class. They share a settings schema, deployment schema and name and layer attributes. The settings schema describes the settings that apply to types based on this class, the values that they can take and description of each. The deployment schema describes the information that is required to deploy a type that is based on this resource. The layer attribute associated the resource with one layer in the design space. The name attribute is used to give the class a unique name within the namespace.

[0317]

	<xs:complexType name=“class”>
	<xs:sequence>
	<xs:element name=“deploymentSchema”
	type=“deploymentSchema”
	minOccurs=“0” maxOccurs=“1”/>
	<xs:element name=“settingSchema”
	type=“settingsSchema”
	minOccurs=“0” maxOccurs=“1”/>
	</xs:sequence>
	<xs:attribute name=“name” type=“xs:string” use=“required”/>
	<xs:attribute name =“layer” type=“layer” use=“required”/>
	</xs:complexType>

[0318] For the deployment schema the namespace is left undefined. The constraints on the schema are entirely the responsibility of the installer for the class.

[0319]

	<xs:complexType name=“deploymentSchema”>
	<xs:sequence>
	<xs:any namespace=“##other” processContents=“lax”/>
	</xs:sequence>
	</xs:complexType>

[0320] The values provides as part of the deployment section must match the associated deployment schema.

[0321]

	<xs:complexType name=“deploymentValues”>
	<xs:sequence>
	<xs:any namespace=“##other” processContents=“lax”/>
	</xs:sequence>
	</xs:complexType>

[0322] The layer attribute is an enumeration of four layer types. The application layer contains high level application components such as database and webserver. The service layer contains middleware services such as IIS and SQL. The network layer contains operating system, storage and network definitions. The hardware layer contains definitions of the hardware components of a data center.

[0323]

	<xs:simpleType name=“layer”>
	<xs:restriction base=“xs:string”>
	<xs:enumeration value=“Application”/>
	<xs:enumeration value=“Service”/>
	<xs:enumeration value=“Network”/>
	<xs:enumeration value=“Hardware”/>
	</xs:restriction>
	</xs:simpleType>

Port Class

[0324] Port classes do not contain any information above that defined in the resource base type.

[0325]

	<xs:complexType name=“portClass”>
	<xs:complexContent>
	<xs:extension base=“class”>
	</xs:extension>
	</xs:complexContent>
	</xs:complexType>

Component Class

[0326] A component class extends the base class by adding a list of allowed port classes.

[0327]

	<xs:complexType name=“componentClass”>
	<xs:complexContent>
	<xs:extension base=“class”>
	<xs:sequence>
	<xs:element name=“portClassesAllowed”
	type=“portClassesAllowed”
	minOccurs=“0” maxOccurs=“1”/>
	</xs:sequence>
	</xs:extension>
	</xs:complexContent>
	</xs:complexType>

[0328] The list of port classes can be open or closed, if it is closed, then only those port types based on classes that appear in the list can be used on the associated component type. The minOccurs and maxOccurs attributes define the number of times one of these port types can be used.

[0329]

<xs:complexType name=“portClassesAllowed”>
	<xs:sequence>
	<xs:element name=“portClassRef” minOccurs=“0”
maxOccurs=“unbounded”>
	<xs:complexType>
	<xs:attribute name=“name” type=“xs:string”
	use=“required”/>
	<xs:attribute name=“minOccurs” type=“xs:int”
	use=“optional”/>
	<xs:attribute name=“maxOccurs” type=“xs:string”
	use=“optional”/>
	</xs:complexType>
	</xs:element>
	</xs:sequence>
	<xs:attribute name=“closed” type=“xs:boolean”
	default=“true” use=“optional”/>
</xs:complexType>

Wire Class

[0330] The wire class also extends the base schema by adding a list of allowed port classes. In this case the list defines the classes of the port types that may be associated with the wire type.

[0331]

	<xs:complexType name=“wireClass”>
	<xs:complexContent>
	<xs:extension base=“class”>
	<xs:sequence>
	<xs:element name=“portClassesAllowed”
	type=“portClassesAllowed” minOccurs=“0” maxOccurs=“1”/>
	</xs:sequence>
	</xs:extension>
	</xs:complexContent>
	</xs:complexType>

Hosting Relationship

[0332] A hosting relationship defines is a triple identifying a source class, a target class and an installer. The existence of the relationship indicates that an instance of a type based on the source class could be created using an instance of a type based on the target class and the installer associated with the relationship. The target class must be a component class.

[0333] For example a webservice class may be the source class in a hosting relationship with an IIS class and the webservice installer. In this case the relationship indicates that it may be possible to create an instance of type MyWebservice on type MyIIS using the installer. We do not know whether it will be possible to create the relationship until we have evaluated constraints that exist in both the application space and the instance space.

[0334]

<xs:complexType name=“hostRelation”>
	<xs:attribute name=“classRef type=”xs:string“ use=“required”/>
	<xs:attribute name=“componentHostClassRef” type=“xs:string”
use=“required”/>
	<xs:attribute name=“installerRef” type=“xs:string” use=“required”/>
</xs:complexType>

[0335] The installer is identified by name, code type and a link to the binary that implements the installer.

[0336]

<xs:complexType name=“installer”>
	<xs:sequence>
	<xs:element name=“binary” type=“xs:string” minOccurs=“1”
maxOccurs=“1”/>
	</xs:sequence>
	<xs:attribute name=“codeType” type=“xs:string” use=“required”/>
	<xs:attribute name=“name” type=“xs:string” use=“required”/>
</xs:complexType>

[0337] These examples are excerpts from the extended four layer example. See the complete example files for details.

[0338] First we create some port classes to model access to a database. In this case we have a server port and a client port.

[0339]

	<portClass name=“ServerDataAccess” layer=“Application”>
	<settingSchema>
	<xs:schema>
	<xs:complexType>
	<xs:sequence>
	<xs:element name=“databaseName”
	type=“xs:string”/>
	<!-- other connection string properties
	-->
	</xs:sequence>
	</xs:complexType>
	</xs:schema>
	</settingSchema>
	</portClass>
	<portClass name=“ClientDataAccess” layer=“Application”/>

[0340] We then create a wire class that models the communication link between the two port classes. The wire class has some settings and references the two port classes defined above. In this case the wire constrains there to be only one server on the connection, modeling the fact that the client port does not know how to load balance connections across multiple servers. A more complex wire implementation may allow multiple servers and implement some form of management to resolve connections.

[0341]

<wireClass name=“DataConnection” layer=“Application”>
	<settingSchema>
	<xs:schema>
	<xs:complexType>
	<xs:sequence>
	<xs:element name=“useSSL”
	type=“xs:boolean”/>
	</xs:sequence>
	</xs:complexType>
	</xs:schema>
	</settingSchema>
	<portClassesAllowed>
	<portClassRef name=“ServerDataAccess” maxOccurs=“1”/>
	<portClassRef name=“ClientDataAccess”/>
	</portClassesAllowed>
</wireClass>

[0342] Finally we create a component class that models a database. This class has both a settings and a deployment schema and identifies the ports that can exist on a component type based on this class.

[0343]

	<componentClass name=“Database” layer=“Application”>
	<deploymentSchema>
	<xs:schema>
	<xs:complexType>
	<xs:sequence>
	<xs:element name=“sqlScriptFilePath”
	type=“xs:string”
	maxOccurs=“unbounded”/>
	</xs:sequence>
	</xs:complexType>
	</xs:schema>
	</deploymentSchema>
	<settingSchema>
	<xs:schema>
	<xs:complexType>
	<xs:sequence>
	<xs:element name=“databaseName”
	type=“xs:string”/>
	</xs:sequence>
	</xs:complexType>
	</xs:schema>
	</settingSchema>
	<portClassesAllowed closed=“true”>
	<portClassRef name=“ServerDataAccess”/>
	</portClassesAllowed>
	</componentClass>

[0344] All these components need mapping to compatible host types. In this case SQL server acts as a host for the server port and the database and IIS acts as a host for the sql client port. These classes are defined in a separate namespace aliased to middleware.

[0345]

	<hostRelations>
	<installer name=“DatabaseInstaller”
	codeType=“InstallerPlugin”/>
	<hostRelation classRef=“database”
	componentHostClassRef=“middleware:SQL”
	installerRef=“DatabaseInstaller”/>
	<hostRelation classRef=“ServerDataAccess”
	componentHostClassRef=“ middleware:SQL”
	installerRef=“DatabaseInstaller”/>
	<hostRelation classRef=“ClientDataAccess”
	componentHostClassRef=“ middleware:IIS”
	installerRef=“WebServiceInstaller”/>
	</hostRelations>

Applications

[0346] The application developer creates component, port and wire types in the application space to model his application. These types are created by selecting classes that match the layer that the developer is working within and then supplying values for the classes.

Application Base Type

[0347] All application type schemas are based on the following application base schema. The base schema attributes identify the class that the type is based on and the name of the type. In the body of the schema we identify the deployment values that will allow this type to be deployed, and the settings for the settings schema on the associated class. The type may define also define a new settings schema that identifies values that can be provided when this type is used within other types. Finally the base type includes a section for host constraints. This section identifies constraints on possible hosts for this type based on the host relationships that exist in the resource space for the class associated with this type.

[0348]

	<xs:complexType name=“baseType”>
	<xs:sequence>
	<xs:element name=“deployment” type=“deploymentValues”
	minOccurs=“0” maxOccurs=“1”/>
	<xs:element name=“settings” type=“settings Values”
	minOccurs=“0” maxOccurs=“1”/>
	<xs:element name=“settingSchema” type=“settingSchema”
	minOccurs=“0” maxOccurs=“1”/>
	<xs:element name=“hostConstraints” type=“hostConstraints”
	minOccurs=“0” maxOccurs=“1”/>
	</xs:sequence>
	<xs:attribute name=“class” type=“xs:string”
	use=“required”/>
	<xs:attribute name=“name” type=“xs:string” use=“required”/>
	</xs:complexType>

[0349] The hostConstraints section includes a set of constraints for each of the classes that could host the class associated with this type. These classes are identified by the host relations in the resource space. The constraints associated with each class are in terms of the settings schema the classes. The form of the constraints was defined above.

[0350]

	<xs:complexType name=“hostConstraints”>
	<xs:sequence>
	<xs:element name=“hostConstraint” minOccurs=“1”
	maxOccurs=“1”>
	<xs:complexType>
	<xs:sequence>
	<xs:element name=“constraint”
	type=“settingConstraint”/>
	</xs:sequence>
	<xs:attribute name=“host” type=“xs:string”
	use=“required”/>
	</xs:complexType>
	</xs:element>
	</xs:sequence>
	</xs:complexType>

Port Type

[0351] Port types simply use the base type. There is no further information associated with a port type.

[0352]

	<xs:complexType name=“portType”>
	<xs:complexContent>
	<xs:extension base=“baseType”>
	</xs:extension>
	</xs:complexContent>
	</xs:complexType>

Wire Type

[0353] Wire types extend the base type to add a list of allowed port types. Uses of these port types may then be associated with a use of the wire type within a compound component. By defining wire types in this way, the application designer can constrain the set of allowable connections between parts of his application by only creating wires types for compatible port types.

[0354]

<xs:complexType name=“wireType”>
	<xs:complexContent>
	<xs:extension base=“baseType”>
	<xs:sequence>
	<xs:element name=“portTypeRefs” minOccurs=“0”>
	<xs:complexType>
	<xs:sequence>
	<xs:element name=“portTypeRef”
	minOccurs=“0”
	maxOccurs=“unbounded”>
	<xs:complexType>
	<xs:attribute name=“name”
	type=“xs:string”
	use=“required”/>
	</xs:complexType>
	</xs:element>
	</xs:sequence>
	</xs:complexType>
	</xs:element>
	</xs:sequence>
	</xs:extension>
	</xs:complexContent>
</xs:complexType>

Component Type

[0355] A component type extends the base type to add a list of port members and a list of hosted classes.

[0356] Each port member is a use of an existing port type. The list of hosted classes identifies the classes that this component can host. These classes are a subset of the classes identified by the host relationships in the resource space, where this type's class is identified as a potential host.

[0357]

	<xs:complexType name=“componentType”>
	<xs:complexContent>
	<xs:extension base=“baseType”>
	<xs:sequence>
	<xs:element name=“ports” type=“portsList”
	minOccurs=“0” maxOccurs=“1”/>
	<xs:element name=“hostedClasses”
	type=“hostedClassesList”
	minOccurs=“0” maxOccurs=“1”>
	</xs:sequence>
	</xs:extension>
	</xs:complexContent>
	</xs:complexType>

[0358] Each port member in the ports list is identified by name and type. The port name must be unique within the component. The port type must have an associated port class that is allowed on the component class associated with this component type. For each port member we can provide a list of settings that match the schema defined by the port type.

[0359]

	<xs:complexType name=“portsList”>
	<xs:sequence>
	<xs:element name=“port” minOccurs=“0”
	maxOccurs=“unbounded”>
	<xs:complexType>
	<xs:sequence>
	<xs:element name=“settings”
	type=“settingValues”
	minOccurs=“0”
	maxOccurs=“1”/>
	</xs:sequence>
	<xs:attribute name=“name” type=“xs:string”
	use=“required”/>
	<xs:attribute name=“type” type=“xs:string”/>
	</xs:complexType>
	</xs:element>
	</xs:sequence>
	</xs:complexType>

[0360] For each class in the hosted classes list we can associate a list of constraints. These constraints are written with respect to the setting schema of the hosted class.

[0361]

	<xs:complexType name=“hostedClassesList”>
	<xs:sequence>
	<xs:element name=“hostedClass” minOccurs=“1”
	maxOccurs=“1”>
	<xs:complexType>
	<xs:sequence>
	<xs:element name=“constraints”
	type=“settingConstraints”
	minOccurs=“1” maxOccurs=“1”/>
	</xs:sequence>
	<xs:attribute name=“class” type=“xs:string”
	use=“required”/>
	</xs:complexType>
	</xs:element>
	</xs:sequence>
	</xs:complexType>

Compound Component Type

[0362] A compound component type (hereafter referred to as compound component) defines a new component type. When defining the compound component, there is the option to specify that the members of the type should be co-located. If the members are co-located, then when the type is deployed all the members of the type must be deployed on a single host. The compound component also contains a list of component members, a list of wire members, a section defining the ports that the component delegates and a list identifying the classes that the component can host.

[0363]

	<xs:complexType name=“compoundComponentType”>
	<xs:sequence>
	<xs:element name=“components” type=“components”
	minOccurs=“0” maxOccurs=“1”/>
	<xs:element name=“wires” type=“wires”
	minOccurs=“0” maxOccurs=“1”/>
	<xs:element name=“delegatePorts” type=“delegatePorts”
	minOccurs=“0” maxOccurs=“1”/>
	<xs:element name=“delegateHostedClasses”
	type=“delegateHostedClasses”
	minOccurs=“0” maxOccurs=“1”/>
	</xs:sequence>
	<xs:attribute name=“name” type=“xs:string” use=“required”/>
	<xs:attribute name=“colocate” type=“xs:boolean”
	use=“optional” default=“false”/>
	</xs:complexType>

[0364] The component list identifies uses of component types that have already been defined—we call these the component members of the compound component. Each member has a unique name within the compound component, a reference to the type that defines it and a flag that indicates whether it is singleton or not.

[0365] If a component member is marked as singleton, then there can only be once instance of this component member within an instance of the containing compound component. If it is not marked as singleton, then instances of a member may be created and deleted according to external factors such as load changes. This means that any component member that is connected to a non-singleton member may see one or more instances of that member at runtime.

[0366] Each component member may also provide settings values for the settings schema defined in the associated component type.

[0367]

	<xs:complexType name=“components”>
	<xs:sequence>
	<xs:element name=“component” minOccurs=“0”
	maxOccurs=“unbounded”>
	<xs:complexType>
	<xs:sequence>
	<xs:element name=“settings”
	type=“settingValues”
	minOccurs=“0” maxOccurs=“1”>
	</xs:sequence>
	<xs:attribute name=“name” type=“xs:string”
	use=“required”/>
	<xs:attribute name=“type” type=“xs:string”
	use=“required”/>
	<xs:attribute name=“singleton”
	type=“xs:boolean”
	use=“optional” default=“false”/>
	</xs:complexType>
	</xs:element>
	</xs:sequence>
	</xs:complexType>

[0368] A use of wire type within a compound component is called a wire member. Each wire member has a name that is unique to the compound component and identifies an associated wire type. Wire member can also provide settings values for the settings schema defined in the wire type.

[0369] The key role of a wire member is to identify connection between component members within the compound component. The way this is done is to add port references to the wire member. Each port reference identifies a port on a component member within the compound component. The port types of the references ports must match the port types that are associated with the wire type.

[0370]

<xs:complexType name=“wires”>
	<xs:sequence>
	<xs:element name=“wire”
	minOccurs=“0” maxOccurs=“unbounded”>
	<xs:complexType>
	<xs:sequence>
	<xs:element name=“settings”
	type=“settingValues” minOccurs=“0”
maxOccurs=“1”/>
	<xs:element name=“members” minOccurs=“1”
	maxOccurs=“1”>
	<xs:complexType>
	<xs:sequence>
	<xs:element name=“member”
	type=“componentPortRef”
minOccurs=“0” maxOccurs=“unbounded”/>
	</xs:sequence>
	</xs:complexType>
	</xs:element>
	</xs:sequence>
	<xs:attribute name=“name” type=“xs:string”
	use=“required”/>
	<xs:attribute name=“type” type=“xs:string”/>
	</xs:complexType>
	</xs:element>
	</xs:sequence>
</xs:complexType>

[0371] A port reference identifies a component member within the same containing compound component. The port name is the name of a port member on the component type associated with the component member.

[0372]

<xs:complexType name=“componentPortRef”>
	<xs:attribute name=“componentName” type=“xs:string”/>
	<xs:attribute name=“portName” type=“xs:string” use=“required”/>
</xs:complexType>

[0373] A compound component cannot use port types directly as there is no code associated with the compound component that the port member could bind to. Instead we delegate out port members from the component members of the compound component. This means that these ports appear as though they belong to the compound component when it is used as a component type.

[0374] When a port is delegated, it is identified by first identifying the component member and then the port member within that component. The port can be renamed as part of this process in order to avoid name clashes in cases where ports with the same name are delegated from different component members.

[0375]

	<xs:complexType name=“delegatePorts”>
	<xs:sequence>
	<xs:element name=“delegatePort” minOccurs=“0”
	maxOccurs=“unbounded”>
	<xs:complexType>
	<xs:attribute name=“name” type=“xs:string”/>
	<xs:attribute name=“componentName”
	type=“xs:string”/>
	<xs:attribute name=“portName”
	type=“xs:string” use=“optional”/>
	</xs:complexType>
	</xs:element>
	</xs:sequence>
	</xs:complexType>

[0376] In order to construct hosts that may provide services for a range of different classes we allow a compound component to expose the hosted class declarations from its component members. When the compound component is used as a component type, it then appears that the compound component can act as a host for all the declared classes.

[0377] To expose these hosted class declarations we use delegation in a similar way to the way in which we delegated port members. We identify the component member that contains the hosted class, and then we identify the class that the component claims to be able to host.

[0378]

<xs:complexType name=“delegateHostedClasses”>
	<xs:sequence>
	<xs:element name=“hostedClassRef”
	minOccurs=“1” maxOccurs=“unbounded”>
	<xs:complexType>
	<xs:attribute name=“componentName”
	type=“xs:string”/>
	<xs:attribute name=“hostedClass”
	type=“xs:string”
	use=“required”/>
	</xs:complexType>
	</xs:element>
	</xs:sequence>
</xs:complexType>

Binding

[0379] Binding is the process where we identify hosts for the members of a particular compound component. We do this in order to check compatibility between an application and the environment in which it will be hosted and to deploy the application. Both the application and the host environment are modeled using compound components so the process of binding is to find matching members from both components that support the connection topology between the members.

[0380] To identify compatible hosts for a member, we start by looking at the relationship between classes in the resource space. We look at the type of wire or component member and then identify the class associated with the member. We then look for component members in the host component that have compatible classes associated with their component types. We then look at the host constraints on the type associated with the member and see if they match the settings on the host member's type. We then do the reverse, checking the hostedClass constraints on the host member's type against the settings on the type of the member that we want to host.

[0381] If we are trying to match a component member then we need to check that all the port members of the component member's type can also be hosted on any potential host for the component member.

[0382] If we are trying to match a wire member, then we have to match any component members that exist on the path between the hosts that we choose for component members in the compound component that we are trying to host.

[0383] Based on the port classes we described in the previous example, we create two port types.

[0384]

	<portType name=“UserDataServer” class=“ServerDataAccess”>
	<deployment/>
	<settings/>
	</portType>
	<portType name=“UserDataClient” class=“ServerDataAccess”>
	<deployment/>
	<settings/>
	</portType>

These types are complimented by a wire type.

[0385]

	<wireType name=“UserData” class=“DataConnection”>
	<deployment/>
	<settings>
	<useSSL>false</useSSL>
	</settings>
	<portTypeRefs>
	<portTypeRef name=“UserDataServer”/>
	<portTypeRef name=“UserDataClient”/>
	</portTypeRefs>
	</wireType>

[0386] Now we create a component type based on the database class. The database type exposes one server data port.

[0387]

	<componentType name=“UserData” class=“Database”>
	<deployment>
	<sqlScriptFilePath>%install%\mydatabaseDfn.sql</sqlScriptFilePath>
	</deployment>
	<settings>
	<databaseName>UserData</databaseName>
	</settings>
	<ports>
	<port name=“userData” type=“UserDataServer”/>
	</ports>
	</componentType>

[0388] We could create a compound component type that uses some of these types. The following compound component uses three component types. The first type UserPages represents a web service with two access points, the second type QueryManagement is a middle tier logic component, and the last type is our database type. We connect these components up using two wire types: UserData and QueryManager. The data wire connects the middle tier to the database and the query wire connects the front end to the middle tier. We then expose two ports: signup and enquiry, from the front end using delegation.

[0389]

<compoundComponentType name=“UserManagementApplication”>
	<components>
	<component name=“userPages” type=“UserPages”/>
	<component name=“queryLogic” type=“QueryManagement”/>
	<component name=“userData” type=“UserData”
	singleton=“true”/>
	</components>
	<wires>
	<wire name=“data” type=“UserData”>
	<members>
	<member componentName=“queryLogic”
	portName=“userData”/>
	<member componentName=“userData”
	portName=“userData”/>
	</members>
	</wire>
	<wire name=“query” type=“QueryManager”>
	<members>
	<member componentName=“userPages”
portName=“queryManager1”/>
	<member componentName=“userPages”
portName=“queryManager2”/>
	<member componentName=“queryLogic”
portName=“queryManager”/>
	</members>
	</wire>
	</wires>
	<delegatePorts>
	<delegatePort name=“signup”
	componentName=“userPages”
	portName=“signup”/>
	<delegatePort name=“enquiry”
	componentName=“userPages”
	portName=“enquiry”/>
	</delegatePorts>
</compoundComponentType>

SDM Document Structure

[0390] An SDM document has a strong identity which defines the namespace of the document. It imports a list of references other namespaces. The document also contains a information section that identifies document specific attribute such as the document owner, company name and revision date. It then contains lists of port, wire and component classes, followed by a list of host relationships, followed in turn by lists of port, wire and component types.

[0391]

<xs:element name=“sdm”>
	<xs:annotation>
	<xs:documentation>SDM root element. It is a container for SDM
types.</xs:documentation>
	</xs:annotation>
	<xs:complexType>
	<xs:sequence>
	<xs:element name=“import” type=“import” minOccurs=“0”
maxOccurs=“unbounded”/>
	<xs:element name=“information” type=“information”
minOccurs=“0” maxOccurs=“1”/>
	<xs:element name=“portClasses” minOccurs=“0” maxOccurs=“1”>
	<xs:complexType>
	<xs:sequence>
	<xs:element name=“portClass” type=“portClass”
minOccurs=“1” maxOccurs=“unbounded”/>
	</xs:sequence>
	</xs:complexType>
	</xs:element>
	<xs:element name=“wireClasses” minOccurs=“0” maxOccurs=“1”>
	<xs:complexType>
	<xs:sequence>
	<xs:element name=“wireClass” type=“wireClass”
minOccurs=“1” maxOccurs=“unbounded”/>
	</xs:sequence>
	</xs:complexType>
	</xs:element>
	<xs:element name=“componentClasses” minOccurs=“0”
maxOccurs=“1”>
	<xs:complexType>
	<xs:sequence>
	<xs:element name=“componentClass” type=“componentClass”
minOccurs=“1” maxOccurs=“unbounded”/>
	</xs:sequence>
	</xs:complexType>
	</xs:element>
	<xs:element name=“hostRelations” minOccurs=“0”
maxOccurs=“1”>
	<xs:complexType>
	<xs:sequence>
	<xs:element name=“installer” type=“installer” minOccurs=“1”
maxOccurs=“unbounded”/>
	<xs:element name=“hostRelation” type=“hostRelation”
minOccurs=“1” maxOccurs=“unbounded”/>
	</xs:sequence>
	</xs:complexType>
	</xs:element>
	<xs:element name=“portTypes” minOccurs=“0” maxOccurs=“1”>
	<xs:complexType>
	<xs:sequence>
	<xs:element name=“portType” type=“portType”
minOccurs=“0” maxOccurs=“unbounded”/>
	</xs:sequence>
	</xs:complexType>
	</xs:element>
	<xs:element name=“wireTypes” minOccurs=“0” maxOccurs=“1”>
	<xs:complexType>
	<xs:sequence>
	<xs:element name=“wireType” type=“wireType”
minOccurs=“0” maxOccurs=“unbounded”/>
	</xs:sequence>
	</xs:complexType>
	</xs:element>
	<xs:element name=“componentTypes” minOccurs=“0”
maxOccurs=“1”>
	<xs:complexType>
	<xs:sequence>
	<xs:element name=“componentType” type=“componentType”
minOccurs=“0” maxOccurs=“unbounded”/>
	<xs:element name=“compoundComponentType”
type=“compoundComponentType” minOccurs=“0”
maxOccurs=“unbounded”/>
	</xs:sequence>
	</xs:complexType>
	</xs:element>
	</xs:sequence>
	<xs:attributeGroup ref=“identity”/>
	</xs:complexType>
	</xs:element>

Associated XSD
The following is an example structure for a change request.

[0392]

	<?xml version=“1.0” encoding=“utf-8” ?>
	<xs:schema targetNamespace=“urn:schemas-microsoft-
com:sdmChangeRequest” xmlns=“urn:schemas-microsoft-
com:sdmChangeRequest” xmlns:settings=“urn:schemas-microsoft-
com:sdmSettings” xmlns:mstns=“http://tempuri.org/XMLSchema.xsd”
xmlns:xs=“http://www.w3.org/2001/XMLSchema”
elementFormDefault=“qualified” version=“0.7”id=“sdmChangeRequest”>
	<xs:import namespace=“urn:schemas-microsoft-com:sdmSettings”
schemaLocation=“SDM7Settings.xsd” />
	<xs:import namespace=“urn:schemas-microsoft-com:sdmNames”
schemaLocation=“SDM7Names.xsd” />
	<xs:complexType name=“ChangeRequestType”>
	<xs:sequence>
	<xs:element name=“group” type=“groupType”
minOccurs=“0” maxOccurs=“unbounded” />
	</xs:sequence>
	</xs:complexType>
	<xs:complexType name=“groupType”>
	<xs:sequence>
	<xs:element name=“group” type=“groupType”
minOccurs=“0” maxOccurs=“unbounded” />
	<xs:element name=“addInstance”
type=“addInstanceType” minOccurs=“0” maxOccurs=“unbounded” />
	<xs:element name=“updateInstance”
type=“updateInstanceType” minOccurs=“0” maxOccurs=“unbounded” />
	<xs:element name=“deleteInstance”
type=“deleteInstanceType” minOccurs=“0” maxOccurs=“unbounded” />
	<xs:element name=“addConnection”
type=“addConnectionType” minOccurs=“0” maxOccurs=“unbounded” />
	<xs:element name=“deleteConnection”
type=“deleteConnectionType” minOccurs=“0” maxOccurs=“unbounded” />
	</xs:sequence>
	<xs:attribute name=“canLeConcurrentlyExecuted”
type=“xs:boolean” />
	</xs:complexType>
	<xs:complexType name=“addInstanceType”>
	<xs:sequence>
	<xs:element name=“classSettings”
type=“settings:settingValues” minOccurs=“0” />
	<xs:element name=“typeSettings”
type=“settings:settingValues” minOccurs=“0” />
	<!-- setting values for class -->
	<!-- setting values for type -->
	</xs:sequence>
	<xs:attribute name=“parent” type=“reference” use=“optional”
/>
	<xs:attribute name=“host” type=“reference” use=“optional”
/>
	<xs:attribute name=“member” type=“xs:string”
use=“optional” />
	<xs:attribute name=“type” type=“xs:string” use=“optional” />
	<xs:attribute name=“name” type=“xs:string” use=“optional”
/>
	<!-- the parent of this instance -->
	<!-- the host of this instance -->
	<!-- Name of the member on the parent type -->
	<!-- Fully qualified type that this is an instance of -->
	<!-- alias for the id that can be filled in when the instance is
created.
	this name must be unique for all instances of the same
member. -->
	</xs:complexType>
	<!-- what can we change about an instance? -->
	<xs:complexType name=“updateInstanceType”>
	<xs:sequence>
	<xs:element name=“classSettings”
type=“settings:setting Values” minOccurs=“0” />
	<xs:element name=“typeSettings”
type=“settings:settingValues” minOccurs=“0” />
	<!-- setting values for class -->
	<!-- setting values for type -->
	</xs:sequence>
	<xs:attribute name=“id” type=“reference” use=“required” />
	<xs:attribute name=“parent” type=“reference” use=“optional”
/>
	<xs:attribute name=“host” type=“reference” use=“optional”
/>
	<xs:attribute name=“member” type=“xs:string”
use=“optional” />
	<xs:attribute name=“type” type=“xs:string” use=“optional” />
	<xs:attribute name=“name” type=“xs:string” use=“optional”
/>
	<!-- Unique identifier scoped to the SDM Runtime. This is
generated by t_u101 ? SDM runtime
	and is immutable -->
	<!-- the parent of this instance -->
	<!-- the host of this instance -->
	<!-- Name of the member on the parent type -->
	<!-- Fully qualified type that this is an instance of -->
	<!-- alias for the id that can be filled in when the instance is
created.
	this name must be unique for all instances of the same
member. -->
	</xs:complexType>
	<xs:complexTypename=“deleteInstanceType”>
	<xs:attribute name=“id” type=“reference” use=“required” />
	<xs:attribute name=“option” type=“deleteOptionType”
use=“required” />
	<!-- Unique identifier scoped to the SDM Runtime. This is
generated by the SDM runtime
	and is immutable -_cf2 >
	</xs:complexType>
	<xs:complexType name=“addConnectionType”>
	<xs:attribute name=“port” type=“reference” use=“required”
/>
	<xs:attribute name=“wire” type=“reference” use=“required”
/>
	</xs:complexType>
	<xs:complexType name=“deleteConnectionType”>
	<xs:attribute name=“port” type=“reference” use=“required”
/>
	<xs:attribute name=“wire” type=“reference” use=“required”
/>
	</xs:complexType>
	<!-- reference can be guid or path -->
	<xs:simpleType name=“reference”>
	<xs:union></xs:union>
	</xs:simpleType>
	<!-- delete options are: ??? -->
	<xs:simpleType name=“deleteOptionType”>
	<xs:union></xs:union>
	</xs:simpleType>
	</xs:schema>

The following is an example structure for classes.

[0393]

	<?xml version=“1.0” encoding=“utf-8” ?>
	<xs:schema targetNamespace=“urn:schemas-microsoft-com:sdmClasses”
xmlns=“urn:schemas-microsoft-com:sdmClasses” xmlns:names=“urn:schemas-
microsoft-com:sdmNames” xmlns:settings=“urn:schemas-microsoft-
com:sdmSettings” xmlns:xs=“http://www.w3.org/2001/XMLSchema”
elementFormDefault=“qualified” version=“0.7” id=“sdmClasses”>
	<xs:import namespace=“http://www.w3.org/2001/XMLSchema” />
	<xs:import namespace=“urn:schemas-microsoft-com:sdmSettings”
schemaLocation=“SDM7Settings.xsd” />
	<xs:import namespace=“urn:schemas-microsoft-com:sdmNames”
schemaLocation=“SDM7Names.xsd” />
	<!-- TODO [BassamT]:Normalize the port class refs, port type refs
and port members on wire classs, wire types and wire members -->
	<!-- TODO [BassamT]: Is the layer attribute mandatory on a class? -
->
	<!-- TODO [BassamT]: Add keys and keyefs for validation -->
	<!-- TODO [BassamT]: Add support for inlined types -->
	<!-- TODO [BassamT]: scrub minOccurs and maxOccurs -->
	<!-- TODO [BassamT]: New name for “class”, possibly
“deployment” -->
	<!-- TODO [BassamT]: New name for “host”, possibly “provider” --
>
	<!-- REVIEW [BassamT]: Can we merge the definitions of port,
component, wire classs in this XSD. It would make it less verbose at the cost more
semantic analysis. -->
	<!-- CONSIDER [BassamT]: General attribute mechanism for things
like Singleton, Colocation, Inline. -->
	<!-- TODO [BassamT]: Bindings:member to component member --
>
	<!-- TODO [geoffo]: ports - are they singleton? -->
	<!-- TODO [geoffo]: delegation - how do we combine ports? -->
	<!-- TODO [geoffo] Add back <any> in appropriate places -->
	<!--
==========================================================
==========================================================
= -->
	<!-- SDM root element -->
	<!--
==========================================================
==========================================================
= -->
	<xs:element name=“sdmClasses”>
	<xs:complexType>
	<xs:sequence>
	<xs:element name=“import”
type=“names:import” minOccurs=“0” maxOccurs=“unbounded” />
	<xs:element name=“information”
type=“information” minOccurs=“0” />
	<xs:element name=“portClasses”
minOccurs=“0”>
	<xs:complexType>
	<xs:sequence>
	<xs:element
name=“portClass” type=“portClass” maxOccurs=“unbounded” />
	</xs:sequence>
	</xs:complexType>
	</xs:element>
	<xs:element name=“componentClasses”
minOccurs=“0”>
	<xs:complexType>
	<xs:sequence>
	<xs:element
name=“componentClass” type=“componentClass” maxOccurs=“unbounded” />
	</xs:sequence>
	</xs:complexType>
	</xs:element>
	<xs:element name=“protocols”
minOccurs=“0”>
	<xs:complexType>
	<xs:sequence>
	<xs:element
name=“protocol” type=“protocol” maxOccurs=“unbounded” />
	</xs:sequence>
	</xs:complexType>
	</xs:element>
	<xs:element name=“hostRelations”
minOccurs=“0”>
	<xs:complexType>
	<xs:sequence>
	<xs:element
name=“installer” type=“installer” maxOccurs=“unbounded” />
	<xs:element
name=“hostRelation” type=“hostRelation” maxOccurs=“unbounded” />
	</xs:sequence>
	</xs:complexType>
	</xs:element>
	</xs:sequence>
	<xs:attributeGroup ref=“names:namespaceIdentity” />
	</xs:complexType>
	</xs:element>
	<!-- SDM type library information -->
	<xs:complexType name=“information”>
	<xs:annotation>
	<xs:documentation>Human readable information
about the SDM type library.</xs:documentation>
	</xs:annotation>
	<xs:sequence>
	<xs:element name=“friendlyName” type=“xs:string”
minOccurs=“0” />
	<xs:element name=“companyName” type=“xs:string”
minOccurs=“0” />
	<xs:element name=“copyright” type=“xs:string”
minOccurs=“0” />
	<xs:element name=“trademark” type=“xs:string”
minOccurs=“0” />
	<xs:element name=“description” type=“xs:string”
minOccurs=“0” />
	<xs:element name=“comments” type=“xs:string”
minOccurs=“0” />
	</xs:sequence>
	</xs:complexType>
	<!--
==========================================================
==========================================================
= -->
	<!-- Classes -->
	<!--
==========================================================
==========================================================
= -->
	<xs:complexType name=“baseClass”>
	<xs:sequence>
	<xs:element name=“deploymentSchema”
type=“settings:deploymentSchema” minOccurs=“0” />
	<xs:element name=“settingSchema”
type=“settings:settingSchema” minOccurs=“0” />
	<!-- XSD schema that for how a class is deployed -->
	<!-- Setting schema -->
	</xs:sequence>
	<xs:attribute name=“name” type=“xs:string” use=“required”
/>
	<xs:attribute name=“layer” type=“xs:string” use=“required”
/>
	<!-- REVIEW [BassamT] Are these layers just for benefit of
tools, or are they
	strictly enforced in the SDM model? There are
	cases where mixing components from different
layers makes
	sense. For example, the filter component might
be a
	a component meta type hosted ISA server which
lives in layer 3.
	However, we want to use the Filter meta-type in
layer 2. -->
	</xs:complexType>
	<!-- port class -->
	<xs:complexType name=“portClass”>
	<xs:complexContent>
	<xs:extension base=“baseClass” />
	</xs:complexContent>
	</xs:complexType>
	<!-- Component class -->
	<xs:complexType name=“componentClass”>
	<xs:complexContent>
	<xs:extension base=“baseClass”>
	<xs:sequence>
	<xs:element
name=“portClassesAllowed”minOccurs=“0”>
	<xs:complexType>
	<xs:sequence>
	<xs:element
name=“portClassRef” minOccurs=“0” maxOccurs=“unbounded” />
	</xs:sequence>
	<xs:attribute
name=“closed” type=“xs:boolean” use=“optional” default=“true” />
	<!-- Whether the allowable
ports is closed list -->
	<!-- If this value is “true”
then the list of ports is non-extensible. If this value is “false” then the list of ports
is open-ended, the ports listed will be considered mandatory. -->
	</xs:complexType>
	</xs:element>
	<!-- this will specify a set of constraints
on the set of allowable ports
	that can show up on a component
type of this meta type. -->
	</xs:sequence>
	</xs:extension>
	</xs:complexContent>
	</xs:complexType>
	<xs:complexType name=“portClassRef”>
	<xs:attribute name=“name” type=“xs:string” use=“required”
/>
	<xs:attribute name=“required” type=“xs:boolean”
use=“required” />
	<xs:attribute name=“singleton” type=“xs:boolean”
use=“required” />
	<!-- singleton implies that there can only be one instance of
this port within the parents scope -->
	</xs:complexType>
	<!--
==========================================================
==========================================================
= -->
	<!-- relations -->
	<!--
==========================================================
==========================================================
= -->
	<xs:complexType name=“relation”>
	<xs:attribute name=“name” type=“xs:string” use=“required”
/>
	<xs:attribute name=“installer” type=“xs:string”
use=“optional” />
	</xs:complexType>
	<!-- a protocol is a relationship between one or more port classes -->
	<xs:complexType name=“protocol”>
	<xs:complexContent>
	<xs:extension base=“relation”>
	<xs:sequence>
	<xs:element name=“portClassRef”
type=“portClassRef” maxOccurs=“unbounded” />
	</xs:sequence>
	</xs:extension>
	</xs:complexContent>
	</xs:complexType>
	<!-- defines the host relationship between two classs -->
	<xs:complexType name=“hostRelation”>
	<xs:complexContent>
	<xs:extension base=“relation”>
	<xs:attribute name=“classRef” type=“xs:string”
use=“required” />
	<xs:attribute name=“hostClassRef”
type=“xs:string” use=“required” />
	</xs:extension>
	</xs:complexContent>
	</xs:complexType>
	<!-- the installer type identifes the code responsible for instantiating
a relationship -->
	<xs:complexType name=“installer”>
	<xs:sequence>
	<xs:element name=“binary” type=“xs:string” />
	</xs:sequence>
	<xs:attribute name=“codeType” type=“xs:string”
use=“required” />
	<xs:attribute name=“name” type=“xs:string” use=“required”
/>
	</xs:complexType>
	</xs:schema>

The following is an example structure for a deployment unit.

[0394]

	<?xml version=“1.0” encoding=“UTF-8” ?>
	<xs:schema targetNamespace=“urn:schemas-microsoft-com:sdmSDU”
xmlns:xs=“http://www.w3.org/2001/XMLSchema” xmlns:names=“urn:schemas-
microsoft-com:sdmNames” xmlns=“urn:schemas-microsoft-com:sdmSDU”
elementFormDefault=“qualified” version=“0.7” id=“sdmSDU”>
	<xs:import namespace=“http://www.w3.org/2001/XMLSchema” />
	<xs:import namespace=“urn:schemas-microsoft-com:sdmNames”
schemaLocation=“SDM7Names.xsd” />
	<!-- an sdm deployment unit imports one or more sdm type files the
includes mappings for a subset of the types from the imported file -->
	<xs:element name=“sdmDeploymentUnit”>
	<xs:annotation>
	<xs:documentation>
	The sdu contains a mapping of SDM types to
their implementation.
	</xs:documentation>
	</xs:annotation>
	<xs:complexType>
	<xs:sequence>
	<xs:element name=“import”
type=“names:import” minOccurs=“0” maxOccurs=“unbounded” />
	<xs:element name=“implementation”
type=“implementationMap” minOccurs=“0” maxOccurs=“unbounded” />
	</xs:sequence>
	</xs:complexType>
	</xs:element>
	<!-- a description of this deployment unit -->
	<xs:complexType name=“deploymentDescription”>
	<xs:attribute name=“name” type=“xs:string” />
	<xs:attribute name=“dateCreated” type=“xs:string” />
	<xs:attribute name=“creator” type=“xs:string” />
	</xs:complexType>
	<!-- a mapping from a type to an implementation of the type -->
	<xs:complexType name=“implementationMap”>
	<xs:sequence>
	<xs:element name=“version” type=“xs:string”
minOccurs=“0” maxOccurs=“unbounded” />
	</xs:sequence>
	<xs:attribute name=“type” type=“xs:string” />
	<xs:attribute name=“path” type=“xs:string” />
	</xs:complexType>
	</xs:schema>

The following is an example structure for instances.

[0395]

	<?xml version=“1.0” encoding=“utf-8” ?>
	<xs:schema targetNamespace=“urn:schemas-microsoft-com:sdmInstances”
xmlns:xs=“http://www.w3.org/2001/XMLSchema” xmlns:settings=“urn:schemas-
microsoft-com:sdmSettings” xmlns=“urn:schemas-microsoft-com:sdmInstances”
elementFormDefault=“qualified” version=“0.7” id=“sdmInstances”>
	<xs:import namespace=“http://www.w3.org/2001/XMLSchema” />
	<xs:import namespace=“urn:schemas-microsoft-com:sdmSettings”
schemaLocation=“SDM7Settings.xsd” />
	<xs:element name=“sdmInstances”>
	<xs:complexType>
	<xs:sequence>
	<xs:element name=“import” type=“import”
minOccurs=“0” maxOccurs=“unbounded” />
	<xs:element name=“portInstances”
minOccurs=“0”>
	<xs:complexType>
	<xs:sequence>
	<xs:element
name=“portInstance” type=“portInstance” minOccurs=“0”
maxOccurs=“unbounded” />
	</xs:sequence>
	</xs:complexType>
	</xs:element>
	<xs:element name=“wireInstances”
minOccurs=“0”>
	<xs:complexType>
	<xs:sequence>
	<xs:element
name=“wireInstance” type=“wireInstance” minOccurs=“0”
maxOccurs=“unbounded” />
	</xs:sequence>
	</xs:complexType>
	</xs:element>
	<xs:element name=“componentInstances”
minOccurs=“0”>
	<xs:complexType>
	<xs:sequence>
	<xs:element
name=“componentInstance” type=“componentInstance” minOccurs=“0”
maxOccurs=“unbounded” />
	<xs:element
name=“compoundComponentInstance” type=“compoundComponentInstance”
minOccurs=“0” maxOccurs=“unbounded” />
	</xs:sequence>
	</xs:complexType>
	</xs:element>
	</xs:sequence>
	</xs:complexType>
	</xs:element>
	<xs:complexType name=“import”>
	<xs:attribute name=“alias” type=“xs:string” use=“required” />
	<xs:attributeGroup ref=“identity” />
	</xs:complexType>
	<!-- ================== Instance Schema ===============
-->
	<xs:complexType name=“instanceBase”>
	<xs:sequence>
	<xs:element name=“classSettings”
type=“settings:settingValues” minOccurs=“0” />
	<xs:element name=“typeSettings”
type=“settings:settingValues” minOccurs=“0” />
	<!-- setting values for class -->
	<!-- setting values for type -->
	</xs:sequence>
	<xs:attribute name=“id” type=“guid” use=“required” />
	<xs:attribute name=“parent” type=“guid” use=“optional” />
	<xs:attribute name=“host” type=“guid” use=“optional” />
	<xs:attribute name=“member” type=“xs:string”
use=“optional” />
	<xs:attribute name=“type” type=“xs:string” use=“required” />
	<xs:attribute name=“name” type=“xs:string” use=“optional”
/>
	<!-- Unique identifier scoped to the SDM Runtime. This is
generated by the SDM runtime
	and is immutable -->
	<!-- the parent of this instance -->
	<!-- the host of this instance -->
	<!-- Name of the member on the parent type -->
	<!-- Fully qualified type that this is an instance of -->
	<!-- alias for the id that can be filled in when the instance is
created_par	this name must be unique for all instances of the same
member. -->
	</xs:complexType>
	<xs:complexType name=“componentInstance”>
	<xs:complexContent>
	<xs:extension base=“instanceBase”>
	<xs:sequence>
	<xs:element name=“portInstances”>
	<xs:complexType>
	<xs:sequence>
	<xs:element
name=“portInstance” type=“instanceRef” />
	<!-- the port
Instances that I own -->
	</xs:sequence>
	</xs:complexType>
	</xs:element>
	</xs:sequence>
	</xs:extension>
	</xs:complexContent>
	</xs:complexType>
	<xs:complexType name=“compoundComponentInstance”>
	<xs:complexContent>
	<xs:extension base=“instanceBase”>
	<xs:sequence>
	<xs:element name=“portInstances”>
	<xs:complexType>
	<xs:sequence>
	<xs:element
name=“portInstance” type=“instanceRef” />
	<!-- the port
Instances that I delegate -->
	</xs:sequence>
	</xs:complexType>
	</xs:element>
	<xs:element
name=“componentInstances”>
	<xs:complexType>
	<xs:sequence>
	<xs:element
name=“componentInstance” type=“instanceRef” />
	</xs:sequence>
	</xs:complexType>
	</xs:element>
	<xs:element name=“wireInstances”>
	<xs:complexType>
	<xs:sequence>
	<xs:element
name=“wireInstance” type=“instanceRef” />
	</xs:sequence>
	</xs:complexType>
	</xs:element>
	</xs:sequence>
	</xs:extension>
	</xs:complexContent>
	</xs:complexType>
	<xs:complexType name=“portInstance”>
	<xs:complexContent>
	<xs:extension base=“instanceBase”>
	<xs:sequence />
	</xs:extension>
	</xs:complexContent>
	</xs:complexType>
	<xs:complexType name=“wireInstance”>
	<xs:complexContent>
	<xs:extension base=“instanceBase”>
	<xs:sequence>
	<xs:element name=“portInstances”>
	<xs:complexType>
	<xs:sequence>
	<xs:element
name=“portInstance” type=“instanceRef” />
	<!-- the ports that I
have attached -->
	</xs:sequence>
	</xs:complexType>
	</xs:element>
	</xs:sequence>
	</xs:extension>
	</xs:complexContent>
	</xs:complexType>
	<xs:complexType name=“instanceRef”>
	<xs:attribute name=“uniqueId” type=“xs:string” />
	</xs:complexType>
	<!-- ================= Simple Types
========================== -->
	<xs:simpleType name=“fourPartVersionType”>
	<xs:annotation>
	<xs:documentation>Four part version numbers where
the segments are in the range 0–65535 </xs:documentation>
	</xs:annotation>
	<xs:restriction base=“xs:string”>
	<xs:pattern value=“(0|[1–5][0–9]{0,4}|[7–9][0–
9]{0,3}|6[0–4][0–9]{0,3 }|6[6–9][0–9]{0,2}|65|65[0–4][0–9]{0,2}|65[6–9][0–
9]?|655|655[0–2][0–9]?|655[4–9]|6553[0–5]?).(0|[1–5][0–9]{0,4}|[7–9][0–
9]{0,3}|6[0–4][0–9]{0,3}|6[6–9][0–9]{0,2}|65|65[0–4][0–9]{0,2}|65[6–9][0–
9]?|655|655[0–2][0–9]?|655[4–9]|6553[0–5]?).(0|[1–5][0–9]{0,4}|[7–9][0–
9]{0,3}|6[0–4][0–9]{0,3}|6[6–9][0–9]{0,2}|65|65[0–4][0–9]{0,2}|65[6–9][0–
9]?|655|655[0–2][0–9]?|655[4–9]|6553[0–5]?).(0|[1–5][0–9]{0,4}|[7–9][0–
9]{0,3}|6[0–4][0–9]{0,3}|6[6–9][0–9]{0,2}|65|65[0–4][0–9]{0,2}|65[6–9][0–
9]?|655|655[0–2][0–9]?|655[4–9]|6553[0–5]?)” />
	</xs:restriction>
	</xs:simpleType>
	<xs:simpleType name=“publicKeyTokenType”>
	<xs:annotation>
	<xs:documentation>Public Key Token: 16 hex digits in
size</xs:documentation>
	</xs:annotation>
	<xs:restriction base=“xs:string”>
	<xs:pattern value=“([0–9]|[a–f]|[A–F]){16}” />
	</xs:restriction>
	</xs:simpleType>
	<xs:attributeGroup name=“identity”>
	<xs:attribute name=“name” type=“xs:string” use=“required”
/>
	<xs:attribute name=“version” type=“fourPartVersionType”
use=“required” />
	<xs:attribute name=“publicKeyToken”
type=“publicKeyTokenType” use=“optional” />
	</xs:attributeGroup>
	<xs:simpleType name=“guid”>
	<xs:restriction base=“xs:string”>
	<xs:pattern value=“[0-9a-fA-F] {8}-[0-9a-fA-F]{4}-[0-
9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}” />
	</xs:restriction>
	</xs:simpleType>
	</xs:schema>

The following is an example structure for mappings.

[0396]

	<?xml version=“1.0” encoding=“utf-8” ?>
	<xs:schema targetNamespace=“urn:schemas-microsoft-com:sdmMapping”
xmlns:xs=“http://www.w3.org/2001/XMLSchema” xmlns:names=“urn:schemas-
microsoft-com:sdmNames” xmlns=“urn:schemas-microsoft-com:sdmMapping”
elementFormDefault=“qualified” version=“0.7” id=“sdmMapping”>
	<!-- REVIEW [BassamT]: Do we allow mappings to components
within the same compound component? -->
	<xs:import namespace=“urn:schemas-microsoft-com:sdmNames”
schemaLocation=“SDM7Names.xsd” />
	<xs:element name=“logicalPlacement”>
	<xs:annotation>
	<xs:documentation>
	This file contains the mapping information
between SDM members.
	Mappings are constructed in a outside in
fashion, first binding the outer compound component, then its members and so on.
	</xs:documentation>
	</xs:annotation>
	<xs:complexType>
	<xs:sequence>
	<xs:element name=“import”
type=“names:import” minOccurs=“0” maxOccurs=“unbounded” />
	<xs:element name=“placement” minOccurs=“0”
maxOccurs=“unbounded”>
	<xs:complexType>
	<xs:sequence>
	<xs:element
name=“memberBinding” type=“memberBinding” maxOccurs=“unbounded” />
	<xs:element
name=“wireBinding” type=“wireBinding” minOccurs=“0”
maxOccurs=“unbounded” />
	</xs:sequence>
	<xs:attribute
name=“sourceComponentType” type=“xs:string” />
	<xs:attribute
name=“targetComponentType” type=“xs:string” />
	<xs:attribute name=“name”
type=“xs:string” />
	</xs:complexType>
	</xs:element>
	</xs:sequence>
	</xs:complexType>
	</xs:element>
	<!-- a member binding may be a:
	1. compound component member - in which case we bind all
the members and wires of the compound component
	2. a simple component member - in which case we bind the
component and its ports
	3. a port member - in which case we bind it to a port and there
is no further binding
	-->
	<xs:complexType name=“memberBinding”>
	<xs:sequence>
	<xs:element name=“memberBinding”
type=“memberBinding” minOccurs=“0” maxOccurs=“unbounded” />
	<xs:element name=“wireBinding” type=“wireBinding”
minOccurs=“0” maxOccurs=“unbounded” />
	</xs:sequence>
	<xs:attribute name=“sourceMember” type=“xs:string”
use=“required” />
	<!-- if a target member is not provided then the component
must be a compound component and its members
	will be bound to the members of the compound
component that its parent is bound to
	If a target member is provided and we are binding a
compound component, then the ports on the
	source compound component must be able to be bound to
the ports on the target compound component-->
	<xs:attribute name=“targetMember” type=“xs:string”
use=“optional” />
	</xs:complexType>
	<!-- wires are bound to a path in the target compound component.
	This path consists of port, wire and component instances-->
	<xs:complexType name=“wireBinding”>
	<xs:sequence>
	<xs:element name=“path”>
	<xs:complexType>
	<xs:sequence>
	<xs:element name=“element”
maxOccurs=“unbounded”>
	<xs:complexType>
	<xs:attribute
name=“name” type=“xs:string” />
	</xs:complexType>
	</xs:element>
	</xs:sequence>
	</xs:complexType>
	</xs:element>
	</xs:sequence>
	<xs:attribute name=“sourceWire” type=“xs:string” />
	</xs:complexType>
	<!-- import -->
	</xs:schema>

The following is an example structure for names.