KR101044173B1 - Architecture for distributed computing system and automated design, deployment, and management of distributed applications - Google Patents

Abstract

Design tools include a service definition model that enables the abstraction of distributed computing systems and distributed applications. The design tool also includes a schema for indicating how functional operations should be specified within the service definition model. Functional operations include designing distributed applications, deploying distributed applications, and managing distributed applications.

Design tools, distributed applications, abstraction technologies, service definition models

Description

A method and apparatus for designing, deploying, and managing distributed applications on a distributed computing system, a resource manager, and a computer readable recording medium.

1 is a diagram illustrating an example of an internet data center.

2 is a diagram illustrating an example of a service.

3-8 illustrate examples of layer abstractions.

9 to 10 are diagrams showing an example of an SDM type space.

11-15 illustrate examples of hierarchical abstraction.

16 shows an example of a process.

17-19 illustrate examples of components discussed herein.

20-21 illustrate one example of a graphical user interface.

22 is a diagram illustrating an example of an SDM model.

Fig. 23 shows an example of distribution;

24 shows an example of types.

FIG. 25 illustrates an example of instance requests. FIG.

FIG. 26 illustrates an example of validation of constraints. FIG.

FIG. 27 illustrates an example of a logical architecture of an SDM runtime. FIG.

28 illustrates an example of a graphical representation of a service.

29 shows an example of an instance space.

30 is a diagram illustrating an example of packaging data into an SDU.

31 is a diagram illustrating an example of a type space, a member space, and an instance space.

32 is a diagram illustrating an example of a member tree.

33 is a diagram illustrating an example of an instance tree.

34 illustrates an example implementation of the system described herein.

FIG. 35 illustrates an example of tracking the creation of component instances. FIG.

36-39 illustrate examples of component instance events.

40 illustrates an example of a segmented runtime.

41 shows an example of a member space.

42 illustrates an example of an instance hierarchy.

43 is a diagram illustrating an example of dividing an instance space.

44 illustrates an example of a relationship between various components.

FIG. 45 illustrates an example of a fixed identity trust relationship. FIG.

46-47 illustrate an example of an arrangement of components.

48 illustrates an example of a platform architecture.

FIG. 49 illustrates an example of a usage flow for application distribution. FIG.

50 shows an example of an application setting and a host setting;

FIG. 51 illustrates an example of phases for a deployment tool. FIG.

52 illustrates an example of visualization of a data center technology.

53 to 54 show examples of flowcharts.

55 illustrates an example of processing an SDU.

56 to 58 show examples of flowcharts.

59 illustrates an example of model architecture.

60 illustrates an example of layers of management.

61 shows an example of the operation of the system.

62 shows an example of a connector arrangement;

63-67 illustrate an example of a physical configuration of devices.

FIG. 68 illustrates an example of a request graph. FIG.

69 is a diagram showing an example of a response graph.

70-86 illustrate examples of scenarios in which the present invention may be used.

87 illustrates an example of a service platform architecture.

88 illustrates an example of components in a system.

89 illustrates an example of products that may be included in the system described herein.

90 illustrates various resource management components.

91 illustrates an example of an arrangement of multiple LANs.

92 illustrates an example of an ADS architecture.

FIG. 93 illustrates an example of an ADS remote boot and imaging system. FIG.

94 shows an example of a topology arrangement;

95 is a diagram illustrating an example of SDML.

96 shows an example of a data set in an SDU;

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

98 is a diagram showing an example of an SDM array;

99 shows an example of distribution;

100 illustrates an example of a system architecture.

101 illustrates an example of various distribution layers.

102 illustrates an example of operation logic.

103 to 105 show examples of changes caused by the Internet.

106 illustrates an example of an application lifecycle.

107 illustrates an example of the benefits of a new architecture.

108 shows an example of changing a complex system into a simple diagram.

109 illustrates an example of a service;

110 is a diagram illustrating an example of an SQL cluster.

111 illustrates an example of an SDM data center model.

FIG. 112 illustrates an example of a design application surface. FIG.

113 is a diagram illustrating an example of SDM service in a data center.

114 is a diagram illustrating an example of a resource manager.

115 is a diagram illustrating an example of resource visualization.

116 illustrates an example of programming operation logic.

117 illustrates an example of interaction with operational logic.

118-119 illustrate an example of managing heterogeneous environments.

* Description of the symbols for the main parts of the drawings *

100 internet data centers

102 server computer

104 Pool of Additional Computers

Related application

This application claims the benefit of US Provisional Application No. 60 / 452,736, filed March 6, 2003, incorporated herein by reference.

In addition, the present application relates to the following US patent applications (incorporated herein as part of):

US Patent Application No. 10 / 382,942, filed March 6, 2003, entitled "Virtual Network Topology Generation";

US patent application Ser. No. 09 / 695,812, filed Oct. 24, 2000, entitled "System and Method for Distributed Management of Shared Computers";

US patent application Ser. No. 09 / 695,813, filed Oct. 24, 2000, entitled "System and Method for Logical Modeling of Distributed Computer Systems";

US Patent Application No. 09 / 695,820, filed October 24, 2000, entitled "System and Method for Restricting Data Transfers and Managing Software Components of Distributed Computers";

US Patent Application No. 09 / 695,821, filed October 24, 2000, entitled "Using Packet Filters and Network Virtualization to Restrict Network Communications";

US Patent Application No. 09 / 696,707, filed Oct. 24, 2000, entitled "System and Method for Designing a Logical Model of Distributed Computer Systems and Deploying Physical Resources According to the Logical Model"; And

US patent application Ser. No. 09 / 696,752, filed Oct. 24, 2000, entitled "System and Method Providing Automatic Policy Enforcement in a Multi-Computer Service Application."

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

Internet usage has exploded over the years and continues to grow. People are very satisfied with the variety of services offered on the World Wide Web (or simply "Web"), such as e-mail, online shopping, news and information collection, listening to music, watching video clips, and finding a job. . In order to keep pace with the growing demand of Internet-based services, there has been a tremendous growth in computer systems for hosting websites that provide a backend service for hosting websites and store data associated with that site.

One type of distributed computer system is the Internet data center (IDC), which is a specially designed complex that provides a place for multiple computers to host Internet-based services. IDCs, also known as "Webfarms" and "server farms," generally provide places for hundreds to thousands of computers in climate-controlled and physically secure buildings. These computers are interconnected to run one or more programs that support one or more Internet services or websites. IDCs provide reliable Internet access, reliable power, and a secure operating environment.

1 illustrates an internet data center 100. It has a number of server computers 102 arranged in a specially configured space. Computers are general purpose computers and are generally configured as servers. Internet data centers can provide a place on one site for one entity (eg, a data center for Yahoo! or MSN) or to accommodate multiple sites for multiple entities (eg, Exodus centers that host sites for companies.

IDC 100 is illustrated as having three entities that share computer resources: entity A, entity B, entity C. These entities represent a number of companies that wish to exist on the Web. IDC 100 has additional computers 104 that can be used by entities in the context of heavy traffic. For example, entities engaged in online retailing may experience even more demand during the Christmas season. Additional computers give IDC the flexibility to meet this demand.

Today, large IDCs are complex and are often required to host multiple applications. For example, some websites can run thousands of computers and host many distributed applications. These distributed applications often have complex networked requirements and requirements that require operators to connect to some network switches, as well as manually arrange wiring configurations within IDC to support complex applications. As a result, this task of establishing a physical network topology to comply with application requests can be a cumbersome and time-consuming process that is prone to human error. Accordingly, there is a need for improved techniques for designing and deploying distributed applications on physical computing systems.

An architecture and method for designing, deploying, and managing distributed applications on a distributed computing system are described.

The following disclosure describes a number of aspects suitable for an architecture for designing and implementing distributed computing systems with large application services. The disclosure includes a discussion of the service definition model (SDM) and the SDM runtime environment. The disclosure includes techniques for modeling data center components, how to model distributed application technologies, and techniques for logically deploying modeled applications onto a modeled data center and verifying this logical deployment at design time. The same design aspects are further included. The disclosure further describes deployment aspects, such as how to demonstrate a physical distribution of distributed applications on physical resources, a model of using physical resources to facilitate application deployment to a physical data center. The disclosure also refers to management aspects that include using contextual management feedback, tracking, and operational feedback using SDM. The disclosure is used to distribute applications across physical resources and discusses a number of resource managers for supporting the above aspects of management.

Service Definition Model (SDM)

The Service Definition Model (SDM) provides application designers with the context and tools to design data centers and distributed computer applications in an abstract way. The model defines a set of elements that ultimately represent functional units of applications to be implemented by physical computer resources and software. A schema indicating how to specify the functional actions represented by the components is associated with the model elements.

SDM Overview

Internet Era

Over the past decade, we have seen the Internet turn out to be a computing platform. More software companies are adopting the software as a service model. These services typically consist of a number of components that run a number of machines, including servers, network 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 decentralized services.

We are also witnessing a change in hardware trends. High density servers and specialized network hardware are widespread in data centers. Switched fabrics replace the system bus and provide greater flexibility in system configuration. Now, hardware costs only play a small role in the Total Cost of Ownership (TCO) metric compared to the cost of training and managing dedicated operations staff. Rock-solid operational practices are extremely important for any high-availability service, but it is difficult to continually repeat these practices because they are prone to errors due to the people who perform the manual procedures. In emerging software as a service age, the focus of development is shifting from desktop to server. With this shift in focus, new issues arise for software developers, hardware vendors, and IT professionals:

Services are larger and more complex-they are time-consuming to develop, difficult to maintain and expensive, and risk extending additional functionality.

-Services are likely to be uniform-Services are likely to depend on the specific components and the components that have become habits. Some of many services cannot be removed, independently improved, or replaced with replacements without affecting the usefulness of the service.

-Services depend on specific hardware configuration-Whether there is a dependency on a specific network topology or a specific network device, the binding between hardware and software significantly reduces the ability to host services in various data centers.

-Services require operational consistency-Most services require operations staff to operate. Lack of a common platform reduces the ability to reuse code across services and establish best practices for operation. Unfortunately, operations staff must be trained on the characteristics of each service and again when each service is developed.

The terms "service" and "application" are used herein in a interchangeable sense. In general, an application can be considered a collection of distributed services. For example, Hotmail can be an application that consists of various services, each of which performs a different function.

These problems are unlikely to be different from those in the desktop and DOS era (around 1980s). DOS defines very useful core services for application developers such as disk management, file system, console facilities, and so on. However, DOS has left many complex tasks to ISVs. As an example, WordPerfect and Lotus 123 had to write printer drivers independently within each application to support the print function. Similarly, printer hardware vendors had to deal with software companies to have a successful product. Barriers to joining ISVs and hardware bends were exceptionally high. This has resulted in only a few software and hardware companies succeeding during that era.

Microsoft addressed this issue in creating the Windows platform, dramatically reducing the barrier to subscription. Windows has defined an abstraction layer for most hardware devices on the PC platform. This relieved ISVs from having to worry about supporting specific hardware devices. Windows managed all the resources inside the PC, including memory, disks, and the network. In addition, Windows added a number of additional services that could be used by ISVs. This platform has led to huge growth in the industry. ISVs targeting the Windows platform were extremely productive. Many new hardware vendors have emerged from offering cheaper hardware due to the useful effects of having a common platform, Windows.

Service Definition Model (SDM)

SDM principle

SDM is:

Defines an abstraction that makes it easier to design distributed applications / services.

Enable a framework for automation and reuse of operational practices

Simplify the operation and deployment of distributed applications and services.

By considering capturing what is commonly seen as a complex diagram on the wall near the operator of today's service, it can be easier to understand what SDM is. In these diagrams, the boxes generally represent the elements of service execution, and the lines connecting the boxes represent the communication path between the elements of service. For example, there is a load balancer connected to some IIS front-end machines that in turn connect to one or more middle-tier or back-end services.

Another way to think about SDM is that it is both a meta-model for the behavior of distributed applications / services, and a "live" blueprint for the applications / services you run in your computing environment. In a declarative and scale-invariant way, including possible software operations, SDM captures the structure of an application in a computing environment. The ability to declaratively describe the service's topology and valid behavior of software components, including bindings between hardware and network resources, is very powerful.

As a similar one, take a look at Microsoft's Common Object Model (COM). COM has standardized how components are packaged, registered, activated, and discovered. COM imposes strict rules on lifetime, memory management, and interface implementation. These primitives are necessary for information processing 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.

Similarly, SDM needs to define some basic prototypes to make more sophisticated characteristics. These prototypes are:

-Components-units of implementation, deployment and management

Port-a specified endpoint with an associated type and a set of valid actions

Allowed communication paths between wires and ports

-Hierarchy-Separation of resource management ownership and binding

-Mapping-binding between components, ports and wires in each layer

The remainder of this specification will describe each of these circles in more detail.

Components, ports, and wires

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

MyService is a composite component because it uses components called MyFrontEnd and MyBackEnd.

MyService has one visible port called web, which is a delegated port implemented by the MyFrontEnd component.

MyFrontEnd has two ports, a delegation port and a port labeled catalog.

MyBackEnd has a single port labeled data.

The MyFrontEnd and MyBackEnd components have a potential communication relationship that wires the catalog and data ports over wires.

component

Components are the units of implementation, deployment and management. Examples of components are dedicated servers running Windows Server, IIS virtual Web sites, or SQL databases. Components generally have machine boundaries, but are not required to be proven by web services hosted on a single IIS server.

Components expose functions through ports and communicate over wires. Simple components can only have ports as members. Components that use other components are called compound components and may have ports and wires in addition to other components.

Composite components are created through synthesis and have no implementation associated with them. Composite component ports are delegate ports from internal components. Composite components enable collocation, encapsulation and reuse, and thus can be thought of as one way to organize applications / services and their behavior.

Only public ports of the component are visible outside the component. Complex components appear as simple components to the outside world, encapsulating the internal structure of the components they use. In fact, as long as the behaviors and port types supported by both are exactly the same, a simple component can be replaced with a composite component and vice versa.

port

Ports are named end-points that define a set of behaviors. Ports have an associated type and role and are generally associated with a set of operations that are allowed. Examples of ports are a SOAP port, an HTTP server port, etc., with a set of allowed operations. Ports can be delegated, which means that external components can publish ports of internal components as their own. Ports form a public interface (behavior) for one component. Ports are the only members of a component that can be made public.

wire

Wires are allowed bindings between ports and represent a topological relationship between ports (and components). The wires do not specify any instance interconnect topology, but instead represent a "potentiality" for the instance interconnect topology.

The wires are essentially buses and may include one or more port members. Wires should not be mistaken for a point-to-point relationship. A given port may not appear more than once in the same wire.

Schema

To describe an application / service, you need to have a standard schema for SDM. SDM schemas must be able to be expressed using XSD and XML grammar. Describing the SDM schema in detail is beyond the scope of this specification, but it is necessary to provide a brief description as context for the subject matter described later herein. The following is a simplified representation of the SDM schema.

<sdm>

<identityReference />

<portClasses />

<wireClasses />

<componentClasses />

<hostRelations />

<portTypes />

<wireTypes />

<componentTypes />

</ sdm>

For more detailed information on the SDM schema, read the SDM schema specification at http: // big / and review the sample XSD file.

SDM class

All components, ports, and wires in an application / service are of a type created through the use of classes. The new type can be created from existing classes and types. For example, a web service can be modeled as a class like a SQL database. SDM classes are basically abstractions of common features. In the MyService application, MyFrontEnd is a new type derived from the class Web service, and MyBackEnd is a new type derived from the class SQL database.

Below is an example of a class schema for ports, wires and components.

<portClass name = "ServerDataAccess" 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>

Note that each of the componentClass and wireClass schemas can contain the allowed settings schema, deployment schema, and port classes. portClass does not have a section where port classes are allowed. These schemas are defined as follows:

The configuration schema is an XSD for configuration parameters on components, ports and wires that can be validated at design time.

-The deployment schema is an XSD representing which installation parameters need to be set before the component, port, or wire can be installed. This list can be a schema for Fusion or any other installer technology.

Port Classes Allowed is a location that declares an allowable port by referring to the port class where the component and wire are declared.

For more information on class schemas, see the SDM Schema Design Specification at http: // big.

Class relationships

Components, ports, or wires that can host other components are declared using the hostRelations schema, which identifies installers and component classes that they can host. The hostRelations element can be thought of as a directional link between classes in which one of the components, ports or wires is acting as the host for the other.

Hosting a component means providing an execution environment for the component's code. For example, SQL may be a host for a class database, as shown by way of example below.

<hostRelations>

  <installer name = "DatabaseInstaller" codeType = "InstallerPlugIn" />

    <hostRelation classRef = "database" componentHostClassRef = "host: SQL" installerRef = "DatabaseInstaller" />

</ hostRelations>

SDM Types

There are three distinct spaces for SDM to model resources, applications, and instances. Instance spaces are described later herein. The resource space is where the classes live in that space, and the classes are the building blocks from which the applications are constructed. The application space is where the types exist. Below is an example of XML for ports, wires, and component types.

<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>

Note that portType, wireType, and componentType each have configuration and deployment values in the SDM schema.

-The configuration is XML to a configuration schema that provides configuration values for components, ports, and wires, and can be validated at design time.

-A distribution is XML to a distribution list that represents the value of a configuration parameter that a component, port, or wire needs to be set for proper installation.

For more information on types, see the SDM Schema Design Specification at http: // big.

Composite component

Composite components can be used to define the topological relationship to the application and its other components, ports and wires. Composite components do not have an associated implementation, instead they use port delegation and host relationships to expose the behavior of ports and member components. The XML below shows how the composite component MyService can be described using SDM.

<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>

Instance

Components, ports, and wires define the structure and behavior of an application / service, but not the instances on which they run. Every component, port, and wire type declaration can have one or more instances. Instances are the result of deploying an application / service so that physical resources (servers, network switch ports, and disks) are allocated and software resources (operating system, runtime hosts, application code) are installed and configured.

It is up to the SDM runtime to track all instances from creation to deletion.

SDM runtime

The SDM runtime does not itself create instances of components, ports and wires, but instead provides a set of APIs used to coordinate the creation and management of SDM instances. Like a server running Windows Server with IIS as a host for a Web service component, the actual creation of an instance typically involves multiple entities, which can take hours or days to complete.

The SDM runtime knows when the "create SDM instance" process begins and when it ends with success or failure. The SDM runtime also knows what changes should be made to the SDM instance during its lifetime. An SDM runtime can be considered an accountant that records all transactions associated with a given application / service so that it can be queried for information about instances associated with a given SDM.

The first step in creating an SDM instance is to register an application / service SDM with the SDM runtime. Once the SDM runtime knows a given SDM, the instance creation process can be invoked using factories and Resource Managers (described below).

For more information on the API and runtime design, see the SDM runtime architecture specification at http: // big /.

Hosts and Factories

Components that can "host" other components are called hosts and act as factories for the classes they support. A component may be declared as a host of one or more component classes using the hostRelations element of the SDM schema described above.

The host provides an execution environment for the code of the component, but the factory is the actual service that creates some type of SDM instances and interacts with the SDM runtime through the SDM runtime APIs. The factory can support more than one component class and must register with the SDM runtime specifying which component classes are supported.

A given factory may support a plurality of hosts of the same type having different configurations, and individual factories may also exist for each type of host configuration. For example, an IIS factory can support multiple classes, such as web services and web applications. Similarly, an SQL factory can support different database types, such as databases, partitioned databases, and highly available databases.

The factory does not manage physical resources such as storage, network and servers by itself. Factories interact with physical resources (and their logical equivalents) through resource managers.

Resource manager

The resource manager manages the specified physical and logical resources either (1) discovered or created as part of the bootstrap process, or (2) via some declarative XML-based description of the physical environment. The resource manager holds all storage, network, and server resources and exposes common resource management APIs to handle resource allocation requests and track the ownership of these resources.

Examples of resource managers are Network Resource Manager (NRM), Storage Resource Manager (SRM), and PC Resource Manager (PRM). Each of these resource managers is responsible for allocating logical resources such as physical ports or disks or servers and the VLANs they expose, logical disk volumes, file shares, web servers, and so on. The resource manager is also responsible for programming the physical devices to achieve allocation and de-allocation.

To program the physical hardware, the resource manager interacts with the hardware through resource providers that hide the implementation details of the hardware device, for example, so that network switches from multiple vendors can be used interchangeably (for the device of the manufacturer). If a provider exists). Similar to Windows' hardware abstraction layer (HAL) and device driver models, there is an equivalent abstraction layer for data center environments ranging from servers, networks, and storage devices.

Hierarchy and Mapping

Components, ports, and wires are powerful abstractions when combined with hosts, factories, resource managers, and SDM runtimes, but they are not enough to deploy and manage distributed applications / services. In order to create and manage physical instances of this logical abstraction, some additional constructs are needed. These additional constructs are layers and mappings.

hierarchy

The need for tiers is motivated by the desire to establish at design time the deployment requirements of an application / service. 3 illustrates the hierarchical abstraction defined by SDM.

The application layer describes the distributable components, their deployment requirements and constraints, and their communication relationships in the context of the application / service.

The host layer describes configuration and policy settings and restrictions for hosts such as IIS, CLR, and SQL, among others.

The Virtual Data Center (VDC) layer describes the data center configuration and limitations from the operating system through the network topology to servers, networks, and storage devices.

The hardware layer describes the physical data center environment, which is found or specified in a declarative manner, for example using XML. This layer is not modeled in SDM because it is not scale invariant, but is included for completeness.

Mappings

Since SDM is layered, there is a need to bind various layers. A mapping is essentially a binding of a component or port in one layer to a component or port in the next layer below. The 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 ] + [...]

Where M represents a component, port, or wire, and n represents a hierarchy. Arrows indicate the direction of the mapping and always point from the higher layer to the lower layer.

For example, the component in the application layer named MyFrontEnd in FIG. 4 is mapped to the component in the host layer called IIS. Similarly, a component named MyBackEnd is mapped to an SQL component in the host layer.

Design-time Validation

The binding between the component and its component in the lower layer can cause problems for the developer before the application / service is actually deployed to the live data center. This problem may be due to type incompatibility, conflict of configuration, mismatch of operation, lack of topological relationship, and the like. 5 shows the configuration and limit check error between a component and its host for verification.

In FIG. 6, the mapping attempt shown in the diagram can be error prone because there is no potential communication relationship between IIS and SQL components in the deployment layer.

The mapping from the MyBackEnd component to the SQL host component might have been a valid binding in that the component and host type were compatible and there was no configuration conflict, but since MyServiceSDM defined the topological relationship between MyFrontEnd and MyBackEnd that does not exist in the specified deployment layer, not valid.

Settings and Constraints Checking

The ability to map from the application layer to the deployment layer (and so on) allows you to verify the configuration of a component at design time against host constraints, and also to verify the configuration of the host against component constraints. It's quite powerful because it helps.

7 illustrates in more detail the relationship between components and hosts in different layers. In this figure, note that there is a binding between a component in one layer and a host component in the next layer below, all the way down to the VDC layer.

In FIG. 7, MyFrontEnd is a web service hosted by IIS, and IIS is a Windows application hosted by a Windows server. Just as there is a Windows application factory responsible for creating and deleting instances of IIS and SQL, there is an IIS factory that supports the creation and deletion of instances of web services and web application components.

FIG. 8 illustrates how validation works when designing between components in different layers using the SDM configuration and constraint semantics described above.

Note that the constraints of the component in the upper layer are validated against the configuration of the host component in the lower layer. Also note that the constraints of the host component are validated against the configuration of the component to be hosted.

Bidirectional configuration and constraint checking allows developers to reliably develop their applications / services in the context of the described operating environment using SDM semantics all the way down. To describe a data center so that the description of the data center can be trusted during the development process, it is necessary to create an abstraction of the data center called a virtual data center (VDC).

Virtual data center (VDC)

VDC is a logical representation of the physical data center environment that simplifies the point at which developers see the data center. Ideally, an IT professional or architect should be able to describe the data center in the same way that developers can describe distributed applications / services in a scale-invariant way. A VDC may be considered an abstraction of servers, networks, and storage resources and their topology relationships within a data center. A typical data center diagram is quite complex because multiple interconnected servers, network equipment, IP addresses, VLANs, operating systems, storage devices, etc. are all represented on a single diagram drawn using Visio or similar tools. . In addition to this diagram, there is usually a long document that prescribes exactly how the data center is divided, configured and managed.

An example of this complexity is the Microsoft Systems Architecture (MSA) Enterprise Data Center (EDC). As updates and upgrades are applied, it is clear that keeping the hand-drawn charts and documents up-to-date, reflecting the state of the data center, is expensive, if not impossible. Similarly, validating the environment against documentation requirements is difficult and human error can occur.

The ability to mark complex data centers like the MSA EDC in a scale-invariant way is very powerful for both designers and IT professionals. The ability to describe data centers as components, ports, and wires provides a powerful framework for modeling and validating deployment requirements that are lacking in today's design and deployment processes.

SDM principle

SDM is:

Defines an abstraction that makes it easier to design distributed applications / services.

Enable a framework for automation and reuse of operational practices

Simplify the operation and deployment of distributed applications and services.

By considering capturing what is commonly seen as a complex diagram on the wall near the operator of today's service, it can be easier to understand what SDM is. In these diagrams, the boxes generally represent the elements of service execution, and the lines connecting the boxes represent the communication path between the elements of service. For example, there is 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.

Another way to think about SDM is that it is both a meta-model for the behavior of distributed applications / services, and a "live" blueprint for the applications / services you run in your computing environment. In a declarative and scale-invariant way, including possible software operations, SDM captures the structure of an application in a computing environment. The ability to declaratively describe the service's topology and valid behavior of software components, including bindings between hardware and network resources, is very powerful.

As a similar one, take a look at Microsoft's Common Object Model (COM). COM has standardized how components are packaged, registered, activated, and discovered. COM imposes strict rules on lifetime, memory management, and interface implementation. These primitives are necessary for information processing 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.

Similarly, SDM needs to define some basic prototypes to make more sophisticated characteristics. These prototypes are:

-Components-units of implementation, deployment and management

Port-a specified endpoint with an associated type and a set of valid actions

Allowed communication paths between wires and ports

-Hierarchy-Separation of resource management ownership and binding

-Mapping-binding between components, ports and wires in each layer

The remainder of this specification will describe each of these circles in more detail.

Components, ports, and wires

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

MyService is a composite component because it uses components called MyFrontEnd and MyBackEnd.

MyService has one visible port called web, which is a delegated port implemented by the MyFrontEnd component.

MyFrontEnd has two ports, a delegation port and a port labeled catalog.

MyBackEnd has a single port labeled data.

The MyFrontEnd and MyBackEnd components have a potential communication relationship that wires the catalog and data ports over wires.

component

Components are the units of implementation, deployment and management. Examples of components are dedicated servers running Windows Server, IIS virtual Web sites, or SQL databases. Components generally have machine boundaries, but are not required to be verified by multiple IIS virtual Web sites hosted on a single server.

Components expose their functions through ports and communicate over the wires. Simple components can only have ports as members. Components that use other components are called compound components and may have ports and wires in addition to other components.

Composite components are created through synthesis and have no implementation associated with them. Composite component ports are delegate ports from internal components. Composite components enable collocation, encapsulation and reuse, and thus can be thought of as one way to organize applications / services and their behavior.

Only public ports of the component are visible outside the component. Complex components appear as simple components to the outside world, encapsulating the internal structure of the components they use. In fact, as long as the behaviors and port types supported by both are exactly the same, a simple component can be replaced with a composite component and vice versa.

port

Ports are named end-points that have an associated type and are generally associated with a protocol role and a set of operations that are allowed. Examples of ports are SOAP port, HTTP server port, etc., which have a set of operations allowed. Ports can be delegated, which means that an external component can publish an internal component's port as its own. Ports form a public interface (behavior) for one component. Ports are the only members of a component that can be made public.

wire

Wires are allowed bindings between ports and represent a topological relationship between ports (and components). The wires do not specify any instance interconnect topology, but instead represent a "potentiality" for the instance interconnect topology.

The wires are essentially buses and may include one or more port members. Wires should not be mistaken for a point-to-point relationship. A given port may not appear more than once in the same wire.

Schema

To describe an application / service, you need to have a standard schema for SDM. SDM schemas must be able to be expressed using XSD and XML grammar. Describing the SDM schema in detail is beyond the scope of this specification, but it is necessary to provide a brief description as context for the subject matter described later herein. The following is a simplified representation of the SDM schema.

<sdm>

<import />

<identityReference />

<information />

<portImplementationType />

<wireImplementationType />

<componentImplementationType />

<hostRelations />

<portTypes />

<wireTypes />

<componentTypes />

</ sdm>

For more detailed information on the SDM schema, read the SDM schema specification at http: // big / and review the sample XSD file.

Types

All components, ports, and wires used in an application / service are types. Types are essentially equivalent to classes in object-oriented languages such as C + and C #, and, like classes, new types can be created from existing types. Scale-invariant spaces are represented by portTypes, wireTypes, and componentTypes in the SDM schema. Scale invariant means that a component, port, or wire can be represented once in an application / service SDM even if there are multiple instances of each of these in an actual data center.

Types are ultimately derived from an implementation type, which is essentially an abstraction of common technical features. For example, a Web service can be modeled as an implementation type, just like a SQL database. In the MyService application, MyFrontEnd is a new type derived from the implementation type Web service, and MyBackEnd is a new type derived from the implementation type SQL database.

Each of the componentImplementationType and wireImplementationType SDM schema elements may include a settings schema, a deployment manifest, and a port implementation reference. The portImplemenationType element does not have a port implementation reference. 9 shows what the SDM implementation type space looks like.

The configuration schema is an XSD for configuration parameters on components, ports and wires that can be validated at design time.

-The distribution list is an XSD representing which installation parameters need to be set before the component, port, or wire can be installed. This list can be a schema for Fusion or any other installer technology.

A port implementation reference is where to declare an acceptable port by referring to the port implementation type in which the component and wire are declared.

In addition, components that can host other components are declared using a hostRelations SDM schema element that identifies the installer and the component implementation type that it can host. The hostRelations element may be considered as a directional link between component implementation types when one of the components acts as a host for the other component (s). Hosting a component means providing an execution environment for the component's code. IIS, for example, is a host for components of implementation type web services and web applications. The host will be described in more detail later in this specification.

In the SDM schema, each of the portType, wireType, and componentType elements includes an application constraint value, a deployment value, and a host constraint value. The wireType element also contains a port type element that defines the acceptable port types on the specified wire type, and the componentType element contains a hosted types list element that identifies implementation types that can be hosted on the specified component type. Include. 10 illustrates an SDM type space.

Configuration values are XML to configuration schemas that provide configuration values for components, ports and wires, and can be validated at design time against host constraints.

-A distribution value is XML for a distribution list that represents the value of a configuration parameter that a component, port, or wire needs to be set for to function properly.

Constraints are XML for a configuration schema that provides configuration parameter values for which components, ports, or wires of the host should be set. Constraints can be validated against the settings of an underlying host at design time.

Port type is an XML listing the allowable port types that may be members of the specified wire.

A hosted type list is an XML that declares a list of component implementation types that a component can host.

Instances

Components, ports, and wires define the structure and behavior of an application / service, but do not define the instances on which they run. Every component, port, and wire type declaration can have one or more instances. Instances are the result of deploying an application / service so that physical resources (servers, network switch ports, and disks) are allocated and software resources (operating system, runtime hosts, application code) are installed and configured.

It is up to the SDM runtime to track all instances from creation to deletion.

SDM Runtime

The SDM runtime does not itself create instances of components, ports and wires, but instead provides a set of APIs used to coordinate the creation and management of SDM instances. Like the server running Windows Server with IIS as the host for the Web service component, the actual creation of an instance usually involves multiple entities, which can take hours or days to complete. Can be.

The SDM runtime knows when the "create SDM instance" process begins and when it ends with success or failure. The SDM runtime also knows what changes should be made to the SDM instance during its lifetime. An SDM runtime can be considered an accountant that records all transactions associated with a given application / service so that it can be queried for information about instances associated with a given SDM.

The first step in creating an SDM instance is to register an application / service SDM with the SDM runtime. Once the SDM runtime knows a given SDM, the instance creation process can be invoked using factories and Resource Managers (described below).

For more information on the API and runtime design, refer to the SDM runtime architecture specification at http: // big /.

Hosts and Factories

Components that can "host" other components are called hosts and act as factories for the implementation types they support. A component may be declared as a host of one or more component implementation types using the hostRelations element of the SDM schema described above.

The host provides an execution environment for the code of the component, but the factory is the actual service that creates some type of SDM instances and interacts with the SDM runtime through the SDM runtime APIs. The factory can support one or more component implementation types, and must register with the SDM runtime specifying which component implementation types are supported. A given factory may support a plurality of hosts of the same type having different configurations, and individual factories may also exist for each type of host configuration. For example, an IIS factory can support multiple implementation types, such as web services and web applications. Similarly, an SQL factory can support different database types, such as databases, partitioned databases, and highly available databases.

The factory does not manage physical resources such as storage, network and servers by itself. Factories interact with physical resources (and their logical equivalents) through resource managers.

Resource Managers

The resource manager manages the specified physical and logical resources either (1) discovered or created as part of the bootstrap process, or (2) via some declarative XML-based description of the physical environment. The resource manager holds all storage, network, and server resources and exposes common resource management APIs to handle resource allocation requests and track the ownership of these resources.

Examples of resource managers are Network Resource Manager (NRM), Storage Resource Manager (SRM), and PC Resource Manager (PRM). Each of these resource managers is responsible for allocating logical resources such as physical ports or disks or servers and the VLANs they expose, logical disk volumes, file shares, web servers, and so on. The resource manager is also responsible for programming the physical devices to achieve allocation and de-allocation.

To program the physical hardware, the resource manager interacts with the hardware through resource providers that hide the implementation details of the hardware device, for example, allowing network switches provided from multiple vendors to be interchanged (manufacturer's If a provider exists for the device). Similar to the hardware abstraction layer (HAL) and device driver models of Windows, there is an equivalent abstraction layer for data center environments ranging from servers, networks, and storage devices.

Layers and Mappings

Components, ports, and wires are powerful abstractions when combined with hosts, factories, resource managers, and the SDM runtime, but they are not sufficient to deploy and manage distributed applications / services. In order to create and manage physical instances of this logical abstraction, some additional constructs are needed. These additional constructs are layers and mappings.

Layers

The need for layers is motivated by the desire to validate the design / deployment requirements of the application / service at design time. 11 shows the hierarchical abstraction defined by SDM.

The application layer describes distributable components, their deployment requirements and constraints, and their communication relationships in the context of an application / service.

The deployment layer describes, among other things, configuration and policy settings and constraints for hosts such as IIS, CLR, and SQL.

The Virtual Data Center (VDC) layer describes data center configuration and constraints from the operating system through the network topology to servers, networks, and storage devices.

The hardware layer describes the physical data center environment, which is found or specified in a declarative manner, for example using XML. This layer is not modeled in SDM because it is not scale invariant, but is included for completeness.

Mappings

Since SDM is layered, there is a need to bind various layers. A mapping is essentially a binding of a component or port in one layer to a component or port in the next layer below. The 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 ] + [...]

Where M represents a component, port, or wire, and n represents a hierarchy. Arrows indicate the direction of the mapping and always point from the higher layer to the lower layer.

For example, in FIG. 12 a component in the application layer named MyFrontEnd is mapped to a component in a distribution layer called IIS. Similarly, a component named MyBackEnd is mapped to an SQL component in the deployment layer.

Design-time Validation

The binding between the component and its component in the lower layer can cause problems for the developer before the application / service is actually deployed to the live data center. This problem may be due to type incompatibility, conflict of configuration, mismatch of operation, lack of topological relationship, and the like. For example, the mapping attempt shown in FIG. 13 can be error prone because there is no potential communication relationship between IIS and SQL components in the distribution layer.

The mapping from the MyBackEnd component to the SQL host component might have been a valid binding in that the component and host type were compatible and there was no configuration conflict, but since MyServiceSDM defined the topological relationship between MyFrontEnd and MyBackEnd that does not exist in the specified deployment layer, not valid.

Settings and Constraints Checking

The ability to map from the application layer to the distribution layer (and so on) allows you to verify, at design time, the validity of a component's configuration against host constraints, and also to validate the host configuration against component constraints. It is quite powerful because it allows us to verify it.

14 illustrates in more detail the relationship between components and hosts in different layers. In this figure, note that there is a binding between a component in one layer and a host component in the next layer below, all the way down to the VDC layer.

In FIG. 14, MyFrontEnd is a web service hosted by IIS, and IIS is a Windows application hosted by a Windows server. Just as there is a Windows application factory that is responsible for creating and deleting instances of IIS and SQL, there is an IIS factory that supports the creation and deletion of instances of web services and web application components.

FIG. 15 illustrates how validation in design works between components in different layers using SDM configuration and constraint semantics described above.

Note that the constraints of the component in the upper layer are validated against the configuration of the host component in the lower layer. Also note that the constraints of the host component are validated against the configuration of the component to be hosted.

Bidirectional configuration and constraint checking allows developers to reliably develop their applications / services in the context of the described operating environment using SDM semantics all the way down. To describe a data center so that the description of the data center can be trusted during the development process, it is necessary to create an abstraction of the data center called a virtual data center (VDC).

Virtual data center (VDC)

VDC is a logical representation of the physical data center environment that simplifies the point at which developers see the data center. Ideally, an IT professional or architect should be able to describe the data center in the same way that developers can describe distributed applications / services in a scale-invariant way. A VDC may be considered an abstraction of servers, networks, and storage resources and their topology relationships within a data center. A typical data center diagram is quite complex because multiple interconnected servers, network equipment, IP addresses, VLANs, operating systems, and storage devices are all represented on a single diagram drawn using Visio or similar tools. Do. In addition to this diagram, there is usually a long document that prescribes exactly how the data center is divided, configured and managed.

An example of this complexity is the Microsoft Systems Architecture (MSA) Enterprise Data Center (EDC). As updates and upgrades are applied, it is clear that keeping the hand-drawn charts and documents up-to-date, reflecting the state of the data center, is expensive, if not impossible. Similarly, validating the environment against documentation requirements is difficult and human error can occur.

The ability to mark complex data centers like the MSA EDC in a scale-invariant way is very powerful for both designers and IT professionals. The ability to describe data centers as components, ports, and wires provides a powerful framework for modeling and validating deployment requirements that are lacking in today's design and deployment processes.

Agenda: Overview, SDM Building Blocks, Example Applications, Example Hosts, Logical Placement, Deployment, Status

SDM is a meta-model suitable for capturing the component parts of distributed applications and their deployment environments. SDM has authority. That is, applications and environments are built from their SDMs, changes to applications and environments are made through SDMs, and namespaces are provided for management processes.

The Service Definition Model is an interrelated schema,

Classes, class relationships, and installer schemas

Component, Port, and Wire Type Schemas

Logical deployment schema

Physical deployment schema

Instantiation request schema

Instance schema

Refers to the set of.

SDM classes are the basic building blocks for all distributed applications and deployment environments. Application classes include ASP.Net Web Service, ASP.Net Web Site, BizTalk Orchestration Schedule, and Services Components (COM +). The Service class includes IIS Server, SQL Sever, and BizTalk Server. OS, Network & Storage classes include Windows VLAN, Filter, and Disk. Hardware classes include Server, Switch, Firewall, Load Balancer, and SAN. Classes are created by system-level developers and do not change often. The class is behind each and every component, port, and wire of the SDM. Each class includes public settings (called simply settings) and private settings (called deployments). Relationships are captured between classes: component classes for port classes, wire classes for port classes, and component classes for component classes.

ASP.Net Web Site Class

<componentClass name = "WebSite" 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>

  <portClassesAllowed closed = "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 the hosting relationship between classes. IIS can host Web Sites.

The installer is a "plugin" to the SDM runtime and is responsible for creating new instances of components, ports and / or wire classes. The installer also plays a role in configuring instances of the class. Different installers can use the same underlying deployment and configuration technology, such as Fusion or WMI.Config.

Distributed Application

Distributed applications are built from components, ports, and wires. Developers create components, ports, and wire types from classes. The type is the "uses" of the class and supplies the values of the configuration and deployment schemas. Type is a unit of recycling. Types are mapped to a single project in Visual Studio.

SDM supports composition of types through compound component types. Synthesis allows you to build larger distributed applications from smaller applications. Composite component types are mapped to the new project type in Visual Studio, Whitehorse.

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 composite 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

Components, ports, and wire types for distributed applications may be packaged together with binaries in a service deployment unit (SDU). Binaries include all .DLLs, .EXEs, .configs, and static content. SDUs represent distributed applications that are portable and can be installed independently. It is similar to the Windows Installer MSI file for desktop applications. However, unlike desktop applications that primarily target a uniform environment (Windows), distributed applications can be hosted in different deployment environments that change significantly, and must be able to express their requirements in the deployment environment. All policies of the environment should be followed.

Therefore, a model is needed that can represent the requirements and constraints of both the application and the deployment environment. The MyWebSite component type requires an IIS server configured with session state stored in a SQL database. The web zone only hosts webSites components that use certificate authentication.

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 (Revisit)

<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

Before SDUs can be distributed, the types must be logically placed on the target deployment environment. Logical layout can be made at design time. Requirements and constraints are checked, and developers notice errors or warnings. The result of the logical placement is captured in a file separate from the SDU. SDUs can have different logical arrangements for different deployment environments (development, test, production, etc.).

Constraint checks are implemented using XPath and XSD assigned to each component, port, and wire class.

Building the deployment environment

The deployment environment is built using the SDM model. See FIG. 22. In essence, this environment is an SDM application at a different layer. Components, ports, and wire types are used in the same way to configure service hosts, network architecture, and hardware. The Whidbey timeframe only supports deployment of the application layer. In ADS V2.0, Service Host, Network and Hardware layers can be deployed. Visual Studio builds designers for building deployments. Visual Studio refers to this as Logical Infrastructure. 23 illustrates an example distribution.

Instance Request Document

The SDM type is scale invariant and can be generated on any scale. The instance request document is a declarative definition of the instances that need to be created and includes a wiring topology. FIG. 24 illustrates example types and FIG. 25 illustrates example instance requests.

Physical Placement

Physical placement is the act of picking out specific host instances that are intended for deployment. Physical placement is constrained by logical placement. Constraints are revalidated during physical deployment. See FIG. 26.

Deployment

SDUs, logical batch files, instance requests, and physical batch files are supplied to the SDM runtime. The SDM runtime invokes the appropriate installer based on the class and host relationships. The installer is responsible for creating a new instance on the host and configuring it to match the type settings. The SDM runtime maintains a database of all instances, their final settings, and batches. The runtime API supports instance space queries.

SDM Schema Design Specification

Three key elements of the SDM schema are ports, wires, and components. Ports represent communication endpoints, components represent parts of distributed applications, and wires represent communication links between application parts. They appear in different forms in three distinct spaces: resource space, application space, and instance space.

In a resource space, resource classes (from which applications within the application space are built) are defined. These classes provide a common categorization of application parts, thereby enabling tool support for a wide range of applications, and providing a basis for type checking at design time. These core classes provide a comprehensive set of features for service design and are considered to change slowly over time.

In the application space, the application type is built. Select a resource class to fill in the details, such as providing a link to the content, or providing settings for properties. You then build a distributed application from the application type by associating the port type with the component type, using component types within the composite component type, and describing the communication relationships between members of the composite component type using wire types. Is done.

Instance space consists of instances created during the process of deploying and running an application. By exposing the communication relationships defined in the application space through the SDM runtime, the instances can find other instances.

Resource Classes

You use resource classes to check the configuration at design time and then define the elements of the application that you need to know to deploy at run time. These elements are as follows.

a) The application is the target of communication. To verify a distributed application against a network topology, you 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 endpoints. Wire classes are used to describe the relationships that can be established between these endpoints.

b) Settings that apply to the application and how the application is distributed. Component classes define building blocks that can be used to build applications. Component classes define settings that can be used to control aspects specific to that component, and define a schema for files and scripts that can be provided to distribute the component.

c) The application depends on to function correctly. In order to function correctly, a component may rely on certain functionality already present in the target environment. An example is a web service that depends on IIS. This requirement is expressed as a hosting relationship between resources. Using this relationship, you can build a dependency tree for a set of resource types that allow you to check in advance whether a particular application will run in a particular environment.

Application Types

Application types can be built using resource classes defined in the resource space. Port types and wire types are derived from these classes to model communication links specific to the application, and component types are built to model separate parts of the application.

Port types are communication endpoints that describe aspects that are specific to the application. It takes port resources and provides information specific to their use within the application. An example is a port type that takes a SOAP resource and provides a WSDL file that defines the functionality that the application publishes.

Wire types define application-specific communication paths. The wire type defines a particular wire resource as connecting two compatible application endpoints. For example, you can take a SOAP wire resource and confine it to concatenating the SOAP port types defined earlier.

Component types are used to model parts of an application that can be deployed independently and distributed across machine boundaries. For example, an application with a web frontend and a database backend may consist of several component types. In this case, you can take a web service resource and use it to generate a web frontend component type, and you can take a database resource and use it to generate a database backend component type. You then model the application interface by adding the appropriate port type to the component type. This is called a port member.

The composite component type used here is a group component type that together form a new component type. The use of a component type within a composite component type is called a component member. Using the wire type defined above, connect the interface exposed by the component member to other members. These become wire members of the composite component.

In order for composite components to look like components, they need to expose their interfaces, capabilities, and requirements just like components. This is done by delegating a subset of port members from the component member of the composite component.

To meet a component's requirements, the component must be bound to another component with matching performance. This is called process binding.

Exemplary Implementation

This section describes the XML schema used to define the elements of the SDM model. Since the settings are used by both the application and the resource, they are first described, followed by the resource class, then the application, and finally the instance space.

Naming

Namespaces are used to define naming scopes in which classes and types can be defined. Within the namespace all class and type names are unique. Namespaces are defined by name, version, and cryptographic key (which can be used to validate the contents of the namespace).

<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>

The file version is defined by a four-part number of the form N.N.N.N (0 <N <65535).

<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>

The public key token is a 16-character hex string that identifies the public part of a public / private key pair. The document is signed using a private key, whereby the user of the document can verify its content using the public key.

<xs: simpleType name = "publicKeyTokenType">
<xs: annotation>
<xs: documentation> Public Key Token: 16 hex digits in size </ xs: documentation>
</ xs: annotation>
<xs: restriction base = "xs: string">
<xs: pattern value = "([0-9] | [af] | [AF]) {16}"/>
</ xs: restriction>
</ xs: simpleType>

Construct a simple name in a namespace using a string. Namespaces can refer to other namespaces by importing another namespace into the current namespace and then associating aliases with that namespace.

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

References to classes and types are either simple names that refer to objects defined in the current namespace or compound names that use both aliases and simple names to identify objects defined in other namespaces.

Settings

Both resource classes and application types can expose configuration schemas. This schema contains 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 composite component type. Used to describe.

Settings schema

The configuration schema is described using XSD. For the initial release, use a list of element types and subsets of XSD that are constrained to a single type.

<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

Settings are provided when the type is generated based on a class or when the type is used within a component or composite component. The configuration value is an XML block that conforms to the appropriate configuration schema.

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

Settings flow

The configuration flow is used to ensure that settings are passed from component type to member of the component type. The configuration flow is implemented using the XPATH of the configuration section, which selects values from the configuration schema defined by the type.

A special attribute defined in the SDM namespace is used to identify the value to which content should be sent. If this attribute is present on any element, the attribute value is considered to be an XPath to the configuration schema for the type.

Setting Constraints

Configuration constraints are used to validate and restrict configuration values. For example, an IIS server may require that its settings be limited to a specific value or a range of values for all web services it hosts. XPATH (or XQUERY if fully supported) is used to validate the settings. The following forms of query are supported.

-Path must exist

-Path must not exist

-If path exists [(path must exist | path must not exist) ^* ]

The first form may require that the setting be set to a specific value or set of values, and the second form may require that the setting not be set to any value or set of values. Thus, a relationship between settings requiring a combination of settings to be set together can be established.

<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>

If the path does not exist, an option to handle it needs to be published. The following allows the designer to choose to cause an error, insert a value, or ignore a test.

<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>

example

The following are simple schema modeling values that computer classes can expose. This schema has a single top level node that identifies configuration groups and three properties under the node.

<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>

The following values can be provided for a schema within a type.

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

If you want to provide a setpoint when the type is used, use the setup flow.

Constraints can be recorded for these values. For example, the first is a simple mustExist constraint. The second constraint uses a test to determine whether to evaluate nested constraints.

<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

Every resource class is derived from a class. They share configuration schemas, deployment schemas, and name and hierarchy attributes. The configuration schema describes the settings that apply to types based on that class, the values they can take, and their descriptions. A deployment schema describes the information needed to distribute a type based on that resource. Hierarchical attributes associate a resource with respect to one layer where the resource is in the design space. Name attributes are used to give classes unique names within the namespace.

<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>

For deployment schemas, the namespace is left undefined. The constraints on the schema are entirely the installer's responsibility for the class.

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

The values provided as part of the deployment section must match the relevant deployment schema.

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

Hierarchical attributes list four hierarchical types. The application layer contains high level application components such as databases and web servers. The service layer includes middleware services such as IIS and SQL. The network layer contains the operating system, storage and network definitions. The hardware layer contains the definition of hardware components of the data center.

<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

The port class does not contain any of the information previously defined in the resource base type.

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

Component class

The component class extends the base class by adding a list of allowed port classes.

<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>

The list of port classes can be opened or closed, and if closed, only port types based on the classes shown in the list can be used in the relevant component type. The minOccurs and maxOccurs attributes define the number of times one of these port types can be used.

<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

Wire classes also extend the base class by adding a list of allowed port classes. In this case, the list defines the classes of port types that can be associated with the wire type.

<x <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

The hosting relationship defines a triple that identifies the source class, target class, and installer. The presence of a relationship indicates that an instance of the type based on the source class can be created using an instance of the type based on the target class and the installer associated with the relationship. The target class must be a component class.

For example, a web service can be a source class in a hosting relationship with an IIS class and a web service installer. In this case, the relationship indicates that an installer can create an instance of type MyWebService on type MyIIS. Until you evaluate the constraints that exist in both application space and instance space, you don't know whether you can create a relationship.

<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>

Installers are identified by name, code type, and a link to the binary that implements the installer.

<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>

example

These examples are taken from an example of an extended four layer. See the complete example file for details.

First, we create some port classes to model access to the database. In this case, a server port and a client port exist.

<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"/>

It then creates a wire class that models the communication link between the two port classes. The wire class has settings and references to the two port classes defined above. In this case the wire constraint models the fact that there must be only one server for the connection, and the client port does not know how to load balance the connections across multiple servers. More complex wire implementations may allow multiple servers and allow some form of management to be implemented to resolve connections.

<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>

Finally, create a component class that models the database. This class has a configuration and deployment schema and identifies ports that can exist on component types based on this class.

<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>

All these components need to be mapped for compatible host types. In this case, the SQL server acts as a host for the server port, and the database and IIS act as a host for the SQL client port. These classes are defined in separate namespaces that are aliased to middleware.

<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>

Application

The application developer models his application by creating components, ports, and wire types in the application space. These types are created by selecting a class that matches the hierarchy in which you are working and supplying a value for that class.

Application base type

All application type schemas are based on the following application base schemas. The base schema attribute identifies the class on which the type is based and the name of that type. The body of the schema identifies the deployment value that allows the type to be distributed and the configuration for the configuration schema on the associated class. The type also defines a new configuration schema that identifies the values that can be provided if the type is used within another type. Finally, the base type contains a section for host constraints. This section identifies possible host-side constraints on that type based on host relationships that exist in the resource space for the class associated with this type.

<xs: complexType name = "baseType">
<xs: sequence>

<xs: element name = "deployment" type = "deploymentValues"
minOccurs = "0" maxOccurs = "1"/>

<xs: element name = "settings" type = "settingsValues"
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>

The hostConstraints section contains a set of constraints for each class that can host classes associated with that type. These classes are identified by host relationships in the resource space. Constraints associated with these classes relate to configuration schemas and classes. The form of constraint has been defined above.

<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

The port type simply uses the base type. There is no more information related to the port type.

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

Wire type

Wire type adds a list of allowable port types by extending the base type. Using these port types may involve using wire types within composite components. By defining the wire type in this way, an application designer can constrain the allowable set of connections between parts of his application only by creating the wire type for compatible port types.

<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

The component type adds a list of port members and a list of hosted classes by extending the base type.

Each port member uses an existing port type. The list of hosted classes identifies the classes that the component can host. These classes are a subset of the classes identified by the host relationship of the resource space, in which case this type of class is identified as a potential host.

<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>

Each port member in the port 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 by the component class associated with this component type. For each port member, you can provide a list of settings that match the schema defined by the port type.

<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>

A list of constraints can be combined for each class in the hosted classes list. These constraints are written regarding the setting schema of the hosted class.

<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

A composite component type (referred to herein as a composite component) defines a new component type. When defining a composite component, you can choose whether or not to specify that members of that type should be co-located in the same place. If members are placed in the same place, then all members of that type must be distributed on a single host if the type is deployed. The composite component also includes a list of component members, a list of wire members, a section defining a port to which the component delegates, and a list that identifies classes that the component can host.

<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>

The component list identifies the use of already defined component types and is called component members of the composite component. Each member has a unique name within the composite component, a reference to the type that defines that member, and a flag indicating whether the member is a singleton or not.

If a component member is marked as a singleton, there can be only one instance of this component member in the instance of the composite component that contains that member. If it is not marked as a singleton, instances of the member can be created and deleted depending on external factors such as load changes. This means that any component member associated with a non-singleton member can see one or more instances of that non-singleton member at runtime.

Each component member can also provide setting values for the configuration schema defined in the associated component type.

<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>

The use of wire types in composite components is called wire member. Each wire member is a unique name for that composite component, with a name that identifies the associated wire type. Wire members can also provide configuration values for the configuration schema defined in the wire type.

The main role of wire members is to identify the connections between component members within a composite component. This is done by adding a port reference to the wire member. Each port reference identifies a port on a component member within the composite component. The port type of the reference port must match the port type associated with the wire type.

<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>

The port reference identifies that component member within the composite component that contains the component member. The port name is the name of the port member on the component type associated with that component member.

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

Because a component is related to the composite component and there is no code that the port member can bind to, the composite component cannot use the port type directly. Instead, port members are delegated out from the component members of the composite component. This means that when composite components are used as component types, these ports appear as if they belong to the composite component.

When a port is delegated, the port is identified by first identifying the component member and then identifying the port member within that component. As part of this process, the names of the ports may be changed to prevent the names from clashing with each other if ports with the same name are delegated from different component members.

<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>

Composite components are permitted to publish hosted class declarations from their component members in order to construct a host that can provide services for a wide range of different classes. When a composite component is used as a component type, it is assumed that this composite component can serve as a host for all declared classes.

Delegation is used in a similar way to delegating port members to publish such hosted class declarations. Identifies the component member containing the hosted class, and then identifies the class requesting that the component can be hosted.

<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

Binding is the process of identifying a host for a member of a particular composite component. This is done to check the compatibility between the application and the environment in which it will be hosted and to distribute the application. Both the application and the host environment are modeled using composite components, so the binding process is to find the matching members from both components that support the connection topology between the members.

In order to identify compatible hosts for members, we begin to examine the relationships between the classes in the resource space. First review the type of wire or component member, and then identify the class associated with that member. Next, in the host component, look for component members with compatible classes related to the component type of the members of the host component. Then review the host constraints on the type associated with the (wire or component) member and see if the constraints correspond to the configuration on the type of host member. Next, on the other hand, check the hostedClass constraint on the type of host member against the configuration on the type of member you want to host.

When attempting to match a component member, it is necessary to check whether all port members with the type of that component member can be hosted on any potential host for that component member.

If you want to match wire members, you must match any component member that exists on the path between the hosts you selected for the component members of the composite component you want to host.

Based on the port class described in the previous example, we create two port types.

<portType name = "UserDataServer" class = "ServerDataAccess">
<deployment />
<settings />
</ portType>

<portType name = "UserDataClient" class = "ServerDataAccess">
<deployment />
<settings />
</ portType>

These types are given by wire type.

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

Now a component type based on the database class is created. The database type exposes one server data port.

<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>

You could create complex component types that use some of these types. The following composite 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. You connect these components using two wire types: UserData and QueryManager. Data wires connect the middle tier with the database, and query wires connect the frontend with the middle tier. Then we expose the two ports, signup and enquiry, from the frontend using delegation.

<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

SDM documents have a strong nature of defining a document's namespace. SDM documents import lists of references to other namespaces. This document also includes an information section that allows you to identify document specific attributes such as document owner, company name, and date modified. The document then includes a list of ports, wires, and component classes, followed by a list of host relationships, followed by a list of ports, wires, and component types.

<xs: element name = "sdm">
<xs: annotation>
<xs: documentation> The SDM root element. This is a container for the SDM type.
</ 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 of a change request.

<? 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: 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 = "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: complexType name = "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 a class.

<? 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 exemplary structure for a deployment unit.

<? 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 an instance.

<? 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 exemplary structure for mapping.

<? 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 a name.

<? xml version = "1.0" encoding = "UTF-8"?>

<xs: schema targetNamespace = "urn: schemas-microsoft-com: sdmNames" xmlns: xs = "http://www.w3.org/2001/XMLSchema" xmlns = "urn: schemas-microsoft-com: sdmNames" elementFormDefault = "qualified" version = "0.7" id = "sdmNames">

<xs: import namespace = "http://www.w3.org/2001/XMLSchema" />

<!-import creates an alias to another SDM file->

<xs: complexType name = "import">

<xs: attribute name = "alias" type = "xs: NCName" use = "required" />

<xs: attribute name = "location" type = "xs: NCName" use = "optional" />

<xs: attributeGroup ref = "Identity" />

</ xs: complexType>

<!-class and type files are identified by name, version and public key->

<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: attributeGroup name = "namespaceIdentity">

<xs: attributeGroup ref = "Identity" />

<xs: attribute name = "signature" type = "xs: string" use = "optional" />

<xs: attribute name = "publicKey" type = "xs: string" use = "optional" />

</ xs: attributeGroup>

<!-simple version number->

<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>

<!-public key for verifying signed docs->

<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: schema>

The following is an exemplary structure for the setting.

<? xml version = "1.0" encoding = "utf-8"?>

<xs: schema targetNamespace = "urn: schemas-microsoft-com: sdmSettings" xmlns: xs = "http://www.w3.org/2001/XMLSchema" xmlns = "urn: schemas-microsoft-com: sdmSettings" elementFormDefault = "qualified" version = "0.7" id = "sdmSettings">

<xs: import namespace = "http://www.w3.org/2001/XMLSchema" />

<!-settings schema, values and constraints->

<xs: complexType name = "openSchema">

<xs: sequence>

<xs: any namespace = "## other" processContents = "lax" />

</ xs: sequence>

</ xs: complexType>

<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>

<xs: complexType name = "settingValues">

<xs: sequence>

<xs: any namespace = "## other" processContents = "lax" />

</ xs: sequence>

</ xs: complexType>

<!-constraints->

<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 = "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: 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>

<xs: complexType name = "deploymentSchema">

<xs: sequence>

<xs: any namespace = "## other" processContents = "lax" />

</ xs: sequence>

</ xs: complexType>

<xs: complexType name = "deploymentValues">

<xs: sequence>

<xs: any namespace = "## other" processContents = "lax" />

</ xs: sequence>

</ xs: complexType>

<!-================= Simple Types ==========================- ->

<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>

</ xs: schema>

The following is an exemplary structure for the type.

<? xml version = "1.0" encoding = "utf-8"?>

<xs: schema targetNamespace = "urn: schemas-microsoft-com: sdmTypes" xmlns: xs = "http://www.w3.org/2001/XMLSchema" xmlns = "urn: schemas-microsoft-com: sdmTypes" xmlns : names = "urn: schemas-microsoft-com: sdmNames" xmlns: settings = "urn: schemas-microsoft-com: sdmSettings" elementFormDefault = "qualified" version = "0.7" id = "sdmTypes">

<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]: 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 = "sdmTypes">

<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 = "names: import" minOccurs = "0" maxOccurs = "unbounded" />

<xs: element name = "information" type = "information" minOccurs = "0" />

<xs: element name = "portTypes" minOccurs = "0">

<xs: complexType>

<xs: sequence>

<xs: element name = "portType" type = "portType" minOccurs = "0" maxOccurs = "unbounded" />

</ xs: sequence>

</ xs: complexType>

</ xs: element>

<xs: element name = "componentTypes" minOccurs = "0">

<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 = "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>

<!-============================================== = _u61? =============================================== =====================->

<!-base complexType for component, port, and wire types->

<!-============================================== ================================================== =====================->

<xs: complexType name = "baseType">

<xs: annotation>

<xs: documentation> base type for Component Type and Port Type. </ xs: documentation>

</ xs: annotation>

<xs: sequence>

<xs: element name = "deployment" type = "settings: deploymentValues" minOccurs = "0" />

<xs: element name = "settings" type = "settings: settingValues" minOccurs = "0" />

<xs: element name = "settingSchema" type = "settings: settingSchema" minOccurs = "0" />

<xs: element name = "hostConstraints" type = "hostConstraints" minOccurs = "0" />

<xs: element name = "hostedClasses" type = "hostedClassesList" minOccurs = "0" />

<!-deployment section contains the deployment instructions for the type. The

schema for this deployment is specified on the "unit". ->

<!-The settings for this component. These are in terms of the schema

that is specified on the unit. ->

<!-Setting Schema. New setting schema that can be exposed by the type.

The values for this schema are set on members of this type. Note

also that we will support flowing setting values to the settings

on the unit. ->

<!-This section contains any constraints on the settings of the host that

is hosting this unit. Note that there can be more than one host for

each unit and we can supply constraints on each. ->

<!-This section contains the list of hosted units and any constraints on the classs' settings.

The constraints are specified in terms of the class's schema. Note that there can be

more than one class that is hosted here. ->

</ xs: sequence>

<xs: attribute name = "class" type = "xs: string" use = "required" />

<xs: attribute name = "name" type = "xs: string" use = "required" />

</ xs: complexType>

<!-============================================== ================================================== =====================->

<!-Constraints->

<!-============================================== ================================================== =====================->

<xs: complexType name = "hostConstraints">

<xs: annotation>

<xs: documentation> Host constraints are constrains against the classes that can host this component or port type. </ xs: documentation>

</ xs: annotation>

<xs: sequence>

<xs: element name = "hostConstraint">

<xs: complexType>

<xs: sequence>

<xs: element name = "constraints" type = "settings: settingConstraints" />

</ xs: sequence>

<xs: attribute name = "host" type = "xs: string" use = "required" />

<!-the name of the component unit that is the host.

May include an alias, for example, "otherSDM: myPortType"->

</ xs: complexType>

</ xs: element>

</ xs: sequence>

</ xs: complexType>

<xs: complexType name = "hostedClassesList">

<xs: annotation>

<xs: documentation> These are constraint against the classes that this type can host </ xs: documentation>

</ xs: annotation>

<xs: sequence>

<xs: element name = "hostedClass" maxOccurs = "unbounded">

<xs: complexType>

<xs: sequence>

<xs: element name = "constraints" type = "settings: settingConstraints" />

</ xs: sequence>

<xs: attribute name = "class" type = "xs: string" use = "required" />

<!-the name of the component class that we are hosting.

May include an alias, for example, "otherSDM: myPortType"->

</ xs: complexType>

</ xs: element>

</ xs: sequence>

</ xs: complexType>

<!-============================================== ================================================== =====================->

<!-Ports->

<!-============================================== ================================================== =====================->

<xs: complexType name = "portType">

<xs: complexContent>

<xs: extension base = "baseType">

<xs: sequence>

<xs: element name = "portConstraints" type = "portConstraints" minOccurs = "0" maxOccurs = "unbounded" />

</ xs: sequence>

</ xs: extension>

</ xs: complexContent>

</ xs: complexType>

<xs: complexType name = "portConstraints">

<xs: annotation>

<xs: documentation> These are constraint against the classes that this type can host </ xs: documentation>

</ xs: annotation>

<xs: sequence>

<xs: element name = "portConstraint">

<xs: complexType>

<xs: sequence>

<xs: element name = "constraints" type = "settings: settingConstraints" />

</ xs: sequence>

<xs: attribute name = "portClass" type = "xs: string" use = "required" />

<xs: attribute name = "portType" type = "xs: string" use = "optional" />

<xs: attribute name = "minOccurs" type = "xs: int" use = "optional" />

<xs: attribute name = "maxOccurs" type = "xs: int" use = "optional" />

<xs: attribute name = "visible" type = "xs: boolean" use = "optional" />

<!-port type is here to allow you to bind to a port type that has behavior not exposed

through settings. In this case settings would not be enough to allow an appropriate port to be identified->

<!-visible identifies whether the application wants to see ports that match this constraint. An application may

only choose to constrain port that it is connected to without wanting connection values for their endpoints->

</ xs: complexType>

</ xs: element>

<!-we probable need a mechanism here to allow a

port to identify sets of optional port endpoints.

i.e. I can bind to X, Y or Z but I must bind to at least one->

</ xs: sequence>

</ xs: complexType>

<!-============================================== ================================================== =====================->

<!-Components->

<!-============================================== ================================================== =====================->

<xs: complexType name = "componentType">

<xs: complexContent>

<xs: extension base = "baseType">

<xs: sequence>

<xs: element name = "ports" type = "portsList" minOccurs = "0" />

</ xs: sequence>

<!-the exclusive attribute indicates whether an instance of the type at the layer below can host instance of other types

-shallow implies that the only instances hosted by the instance are instance of this type

-deep implies that the host must also be marked as exclusive->

<xs: attribute name = "exclusive" type = "depth" use = "optional" default = "notSet" />

</ xs: extension>

</ xs: complexContent>

</ xs: complexType>

<xs: complexType name = "portsList">

<xs: sequence>

<xs: element name = "port" minOccurs = "0" maxOccurs = "unbounded">

<xs: complexType>

<xs: sequence>

<xs: element name = "settings" type = "settings: settingValues" minOccurs = "0" />

<!-member setting values. These are in terms of the setting schema

specified on the type->

</ 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>

<!-============================================== ================================================== =====================->

<!-Compound Component Types. ->

<!-============================================== ================================================== =====================->

<xs: complexType name = "compoundComponentType">

<xs: sequence>

<xs: element name = "components" type = "components" minOccurs = "0" />

<xs: element name = "wires" type = "wires" minOccurs = "0" />

<xs: element name = "delegatePorts" type = "delegatePorts" minOccurs = "0" />

<xs: element name = "delegateHostedClasses" type = "delegateHostedClasses" minOccurs = "0" />

<!-delegate ports->

<!-delegate hosts. These allow a compound component to act as a host just as a simple

component. ->

</ xs: sequence>

<xs: attribute name = "name" type = "xs: string" use = "required" />

<!-shallow co-location implies that instances of the members of this compound component will be placed on the

same host instance at the layer below-deep co-location implies that that host is also colocated->

<xs: attribute name = "colocate" type = "depth" use = "optional" default = "notSet" />

<!-the open attribute indicates whether bindings can see the internalstructure of the compound component

or simply bind to the compound component as though it was a simple component->

<xs: attribute name = "open" type = "xs: boolean" use = "optional" default = "false" />

<!-the exclusive attribute indicates whether an instance of the type at the layer below can host instance of other types

-shallow implies that the only instances hosted by the instance are instance of this type

-deep implies that the host must also be marked as exclusive->

<xs: attribute name = "exclusive" type = "depth" use = "optional" default = "notSet" />

</ xs: complexType>

<xs: complexType name = "components">

<xs: sequence>

<xs: element name = "component" minOccurs = "0" maxOccurs = "unbounded">

<xs: complexType>

<xs: sequence>

<xs: element name = "settings" type = "settings: settingValues" minOccurs = "0" />

<!-member setting values. These are in terms of the setting schema

specified on the type->

</ 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>

<xs: complexType name = "wires">

<xs: sequence>

<xs: element name = "wire" minOccurs = "0" maxOccurs = "unbounded">

<xs: complexType>

<xs: sequence>

<xs: element name = "members">

<xs: complexType>

<xs: sequence>

<xs: element name = "member" type = "componentPortRef" minOccurs = "0" maxOccurs = "unbounded" />

</ xs: sequence>

</ xs: complexType>

</ xs: element>

<!-member setting values. These are in terms of the setting schema

specified on the type->

</ xs: sequence>

<xs: attribute name = "name" type = "xs: string" use = "required" />

<xs: attribute name = "protocol" type = "xs: string" />

</ xs: complexType>

</ xs: element>

</ xs: sequence>

</ xs: complexType>

<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>

<xs: complexType name = "componentPortRef">

<xs: attribute name = "componentName" type = "xs: string" />

<xs: attribute name = "portName" type = "xs: string" use = "required" />

</ xs: complexType>

<xs: complexType name = "delegateHostedClasses">

<xs: sequence>

<xs: element name = "hostedClassRef" 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>

<!-============================================== ================================================== =====================->

<!-SimpleTypes. ->

<!-============================================== ================================================== =====================->

<!-depth identifies whether the settings applies to only the next layer (shallow), or must apply to the next layer and be set on the next layer (deep)->

<xs: simpleType name = "depth">

<xs: restriction base = "xs: string">

<xs: enumeration value = "notSet" />

<xs: enumeration value = "shallow" />

<xs: enumeration value = "deep" />

</ xs: restriction>

</ xs: simpleType>

</ xs: schema>

SDM Runtime

The SDR runtime (or simply runtime) hosts the implementation of the SDM. It is a highly available distributed service that exposes set APIs for manipulating SDM types, members, and instance space. The runtime is responsible for keeping track of all SDM instances in a consistent manner. It provides a mechanism for deployment, versioning, security, and recovery. 27 shows the logical architecture of the SDM runtime.

The SDM runtime consists of the following:

SDM Runtime-This is the SDM Runtime implementation. This is a distributed implementation that implements one or more physical machines. The runtime exposes functionality through the SDM API, which is a set of calls to manipulate SDM and instances.

SDM Store-This is a permanent store for SDM Models and instances. This store is highly available, and consistency is important. The store survives catastrophic events.

Service Deployment Unit-This is a read-only store for SDUs. Like the SDM store, it is high availability and withstands fatal events.

Component implementation host-This is a framework for hosting CLR code referenced from SDM components.

The SDM runtime is typically used by the following client classes.

Component Instances-These are the component instants that communicate with the runtime to use the SDM Runtime Library (RTL). We distinguish between two types of component instants, runtime-hosted component instances and non-run-time component instances.

Development and Deployment tools-These include the SDM compiler, SDU installation tools, and other deployment tools.

Management tools-These are privileged tools used to register and manage the runtime itself.

The client communicates with the runtime through the SDM runtime library (RTL). They typically perform the following operations.

Install / Uninstall SDUs: This is the process of adding and removing new SDUs to the running instant of the SDM runtime.

Add, remove, and modify SDM types and instances: Clients can create new components, ports, and wire types.

Creating and Deleting Instances: Clients can create new component, port, and wire instances.

Sourcing and Sinking Events: If a change is made to the type and / or instance space, the runtime sends the event to the affected client. The event may be triggered by a specific operation, such as setting port binding information.

Query the type and instance space: The client can reflect the type and instance space.

Service Definition Model Runtime Architecture

Introduction

This section reviews the Service Definition Model (SDM) and the SDM Runtime. A technical discussion of the runtime architecture, key characteristics, and implementation is provided. The intended audience is the technical evaluators of BIG, the developers who want to create services and components, or those who are interested in the details of the system.

Service Era

Over the last decade we have seen the Internet emerge as a computing platform. More and more software companies are adopting "software as a service model." Services typically include several components that run on a number of machines, including servers, networking gear, and other specific hardware. Loosely coupled, asynchronous programming models are the norm. Scalability, availability and reliability are critical to the success of these services.

We have also seen changes in hardware trends. High density servers and specialized network hardware have become widespread in data centers. Switched fabrics are replacing system buses that provide greater flexibility in system configuration. Hardware costs make up a small portion of the total cost of ownership metric. This has been replaced by the cost of having a dedicated operator. While rock-solid motion execution is rare, it is absolutely critical for any service. This practice is mainly implemented by humans.

Effectively, the focus of development is to shift from a single PC to a network of PCs. However, in all these changes, there are a lot of new problems for service developers, software providers, hardware providers, and end-users.

Services are massive and complex-they are time-consuming to develop, difficult to maintain and expensive, and risk extending additional functionality.

* Services are monolithic-they depend on custom components and configurations. Some of the Services may not be independently removed or upgraded or replaced by others.

* The service depends on a specific hardware configuration-whether it depends on a particular network topology or on a particular network equipment machine. This significantly reduces the ability to host servers in other environments.

* Services are developed in silos-since there is no common platform, even code sharing or even optimal behavior execution is a daunting task.

Nightmares of operation-Most services require an operating staff to function. This operator must be trained in the details of each service and must be retrained as the service develops.

Some of these problems are not the same as those during the DOS era (around 1980s). DOS has defined useful core services for application developers such as disk management, file systems, console facilities, and so on. However, this has left a lot of complicated work up to ISVs. For example, WordPerfect and Lotus 123 both had independent recording printer drivers to support printing in their respective applications. Similarly, printer hardware suppliers had to deal with software companies to produce a successful product. The barrier to entry for writing hardware providers and DOS applications was exceptionally large. This created only a few successful software companies.

Windows addresses this problem by defining a platform that dramatically reduces the barriers to entry. Windows has defined an abstraction layer for most hardware on the PC platform. This relieved the developer of having to support specific hardware devices. Windows managed all the resources in the PC, including memory, disks, and networks. It also had a rich set of services that could be used by Windows application developers. This platform has caused tremendous developments in industry. Software providers targeting the Windows platform have made huge profits. Many new hardware providers have provided cheaper hardware due to Windows' commoditization.

The service age should still experience this growth. The revolution that took place on desktop machines also needs to happen in services.

BIG services Platform

BIG produces a platform for high availability and scalable services. This platform enables:

* Develop distributed, scalable, high availability services using reusable building blocks such as Visual Studio and SQL and IIS

Development across a set of abstracted hardware and software resources that are automatically assigned, intended, and configured

Reduction of cost of ownership through automation of optimal execution of operations.

* Acquisition of standardized data center hardware that affects the commodity economy

The BIG platform is an extension to the Windows platform and builds on existing technologies such as .NET, SQL, and other Microsoft assets. The BIG Service Platform consists of many parts, including:

* A hardware reference platform that collects commodity hardware for building one large computer we call a BIG computer. This includes numerous interconnected servers, network devices, and storage devices.

Hardware abstraction layer that makes the resource visible. It enables dynamic hardware manufacturing, redistribution, and automated network configuration.

A service definition model (SDM) in which the developer describes the entire service. It allows developers to quickly build new services using high availability SQL, IIS, and other reusable building block components.

* High availability runtime with SDM support. Enable hosting of multiple scalable services in BIG computers.

Operations logic framework for automating optimal operation execution. Enable policy representation and enforcement.

This document focuses only on the SDM and SDM runtimes.

Service Definition Mode

This section describes the Service Definition Model (SDM). For a complete technical description of the SDM and SDML languages, please refer to the "Service Definition Model Language" document.

SDM is the foundation on which all services are built.

SDM enables the synthesis of services from smaller units. These units form the basis of hardware and software abstraction.

SDM serves as a vivid blueprint for services-SDM captures the entire structure of a service in a scale-invariant way.

SDM provides a framework for automating operational execution and promotes their reuse.

SDM defines standards for the deployment, reuse, discovery, versioning, and recovery of services.

Component Model for Services

In essence, SDM is a component model for services. Like traditional component models, SDM defines primitives on which more complex functions can be built. Consider an analogy. Microsoft's Component Object Model (COM) defines a programming model for building components. It standardized on how components are packaged, registered, activated, and discovered. COM mandated strict rules regarding lifetime, memory management, and interface implementation. This fundamental was essential for interoperability-this allows components to be treated as black boxes. Com was the basis for more sophisticated services such as persistent storage, eventing, automation and OLE.

SDM defines a component model for services. This model is well suited for loosely connected, distributed, and asynchronous services. SDM defines standards for deployment, versioning, recovery, and scoping. SDM is a model that provides more sophisticated services such as network management, hardware management, and storage abstraction. How do you compare SDM to other component models?

Clearly, among other technologies, technologies such as DCOM and COBRA are well defined methods for developing applications based on reusable components. However, while existing component technologies are powerful, they have not been widely successful in the Internet or in loosely coupled scenarios. This is mainly because of the following reasons.

* Existing component technology is not designed for large scale-most implementations are optimized for one machine or very few machines. Internet applications are typically associated with many interrelated components, running on many machines.

Existing component technologies mandate invocation protocols such as RPC-they either do not use well-proven network protocols or do not allow branching protocols.

Existing component technologies lack the concept of an application-most have well-defined component definitions, but lack the overall definition of an application made up of smaller components.

Existing component technologies are limited to software running on a general purpose computer-a network device with a single purpose cannot engage as a component.

Many of the more important aspects of the service world must be applied to existing component technologies.

SDM Fundamentals

SDM is a declarative definition of a service structure. This definition relates to components, ports, and wires.

A component is an implementation, distribution, and operation unit. The component may be a dedicated server running a .NET server, an IIS virtual Web site on a network facility or shared machine, such as Cisco's LocalDirector. The component exposes functionality through the port and establishes a communication path through the wire. A component can be nested within an external component called a composite component.

* Ports are so-called endpoints with related types. The port type often represents a protocol, for example an HTTP server. The port acquires the information required to establish communication.

* Wire is an acceptable communication path between ports. They declare the relationship of the topology between the ports.

Services are created using the declarative Service Definition Model Language (SDML). Consider the following example.

(SDML). Lets consider an example:

using System;

using System.Iis;

using System.Sql;

[sdmassembly: name ("MyService")];

sdmassembly: version (1);

componenttype MyFrontEnd: AspApplication

{

   port SqlClient catalog;

   implementation "MyFE, MyClrAssembly";

}

componenttype MyBackEnd: SqlDatabase

{

   implementation "MyBE, MyClrAssembly";

}

componenttype MyService

{

   component MyFrontEnd fe;

   component MyBackEnd be;

   port http = fe.http;

   wire SqlTds tds

   {

         fe.catalog;

         be.sqlServer;

   }

   implementation "MyService, MyClrAssembly";

}

As you can see, the syntax for SDML comes from C #. SDML defines components, ports, and wire types. Consider this definition as follows.

The using directive refers to namespaces of type SDM. These include the system namespace provided by the SDM runtime and defining basic types such as the http wire type. Other namespaces define the types associated with IIS and SQL Server.

The assembly name and assembly version provide a strong name for the SDM assembly. Note that this has nothing to do with CLR assembly. SDM assembly is the smallest unit of SDM deployment. It is named as a collection of components, ports and wire types and includes them. SDM assemblies should not be confused with CLR assemblies-they are completely separate from CLR assemblies.

A component type called MyFronEnd is declared as inherited from the component type AspApplication, which is a referenced type defined in the Systme.Iis SDM assembly. Components are abstract concepts; A component is called a class, not an instance. MyFrontEnd identifies a component from which zero or more component instances can be created.

port SqlClient catalog; Declare the port in the MyFrontEnd component of type SqlClient. The port is called a "catalog". This port is where MyFrontEnd is added to the ports, components, and wires inherited from the base component type AspApplication.

The implementation keyword refers to the implementation for the component type. This execution is a reference to the CLR class in the CLR assembly. This can be thought of as an entry point or constructor for a component type. When the component instance is created, this code is invoked.

The MyService component type is defined by two subcomponents called fe and be. These are the types MyFrontEnd and MyBackEnd. An instance of the component MyService may subsequently have instances of fe and be that form a hierarchy of component instances.

port http = fe.http; It declares a port on the MyService component type delegated to the http port on the fe component.

wire SqlTds declares a wire of type MyService component of type SqlTds, named tds. Two ports are attached by wires. This declaration allows an instance of MyService to have zero or more instances of wire tds, each of which can have a catalog port from the fe component attached to it and an SQL port from the be component attached to them. .

It is often helpful to consider a graphical representation of the service. See FIG. 28. The boxes represent components, the diamonds represent ports, and the lines represent wires.

Component Implementation

All components can refer to an implementation of the form of a CLR class in a CLR assembly. CLR assemblies are hosted by the SDM runtime and are invoked at component instance creation time. The CLR class that executes SDM can perform SDM operations by calling the SDM runtime API. This is described in detail later in this document. The following is a part of C # code to execute the MyService SDM component type.

using System;

using Microsoft.SDM;

public class MyService: SDMComponentInstance

{

public override OnCreate (...)

{

SDMComponent fe1 = CreateComponentInstance ("fe", "");

SDMComponent fe2 = CreateComponentInstance ("fe", "");

SDMComponent be1 = CreateComponentInstance ("be", "");

SDMWire tds1 = CreateWire instanceance ("tds");

tds1.Members.Add (fe1.Ports ["catalog"]);

tds1.Members.Add (fe2.Ports ["catalog"]);

tds1.Members.Add (be1.Ports ["sqlServer"]);

}

}

This code defines the C # class MyService that inherits from SDMComponent. The class overrides the OnCreate () method and creates two instances of the fe component, one instance of the be component, and one wire instance. This adds three ports to the wire instance.

This CLR code is compiled into an assembly called MyClrAssembly that is referenced in the SDM for MyService. When a component of type MyService is instantiated with a component, this code is invoked and the OnCreate method is called.

Consider a strongly typed version of the [BassamT] C # code.

Instances

SDML is used to define components, ports, and wire types; This does not define an instance. An instance can be created using the SDM runtime API as shown in the C # code above. The C # code created multiple instances and formed a wiring topology in the instance space. This instance will be tracked by the SDM runtime. For example, the SDM runtime stores the following information after the OnCreate call completes the above:

component instance ms [1]

port instance http [1]

component instance fe [1]

component instance fe [2]

component instance be [1]

wire instance tds [1]

fe [1] .catalog

fe [2] .catalog

be [1] .SqlServer;

Note: The syntax used here is not SDML; This is used to illustrate the instance space tracked by the SDM runtime.

ms [1] is a component instance with three child component instances, fe [1], fe [2], and be [1]. fe [1] and fe [2] are instances of the fe component. be [1] is an instance of the be component. tds [1] is a wire instance containing three members. Schematically, instance space is shown in FIG.

Component instances contain the actual physical manifestations-in this example, fe [1] and fe [2] are two ASP.NET applications running on IIS running on a Windows machine. When a call to CreateComponentInstance is made, a new ASP.NET application is created and configured with an IIS box. Multiple intermediate steps may be invoked-for example, imposed on the caller's credit card to use the new resource, or a new machine is allocated due to lack of capacity. We will test the machine after the component descriptions later in this document.

Service Deployment Units

The SDM model for MyService defines the structure of services as components, ports, and wires. This results in an SDM assembly that can be installed on the SDM runtime machine. Obviously, SDM assembly is not enough to instantiate a service. In addition to the SDM assembly, you must also consider the CLR assembly, which is the implementation of the component. We should consider everything needed by ASP.NET code, SQL scripts, and services. The sum of all these parts is packaged in a service distribution unit (SDU). See FIG. 30.

SDM runtime

The SDR runtime (or simply runtime) hosts the implementation of the SDM. It is a high availability distributed service that exposes set APIs for manipulating SDM types, members, and instance space. The runtime is responsible for keeping track of all SDM instances in a consistent manner. It provides a mechanism for deployment, versioning, security, and recovery.

This section describes the design and implementation of the SDM runtime proposed in the BIG V1.0 publication. There may of course be other embodiments of the SDM runtime, but we focus on one thing in this document-consider a high availability SDM runtime implementation hosted on a BIG computer (see _____ for details).

Runtime Architecture

27 illustrates the logical architecture of the SDM runtime.

The SDM runtime consists of the following:

SDM runtime-This is the SDM runtime implementation. This is a distributed implementation that runs on one or more physical machines. The runtime performs its functions through the SDM API, which is a set of calls to manipulate SDM and instances.

SDM Store-This is a permanent store for SDM models and instances. This store is highly available and consistency is important. The store survives catastrophic events.

Service Deployment Units-This is a read-only store for SDUs. Like the SDM store, it is highly available and withstands fatal events.

Component Implementation Host-This is a framework for hosting CLR code referenced from SDM components.

The SDM runtime is typically used by the following client classes:

Component Instances-These are component instants that communicate with the runtime using the SDM runtime library (RTL). We distinguish between two types of component instances-runtime-hosted component instances and runtime non-hosted component instances.

Development and Deployment tools-These include SDM compilers, SDU installation tools, and other development tools.

Management tools-These are privileged tools used to register and manage the runtime itself.

The client communicates with the runtime through the SDM runtime library (RTL). They typically perform operations that include the following.

Install / Uninstall SDUs: This is the process of adding and removing new SDUs to the running instant of the SDM runtime.

Add, remove, and modify SDM types and instances: Clients can create new components, ports, and wire types.

Creating and Deleting Instances: Clients can create new component, port, and wire instances.

Sourcing and Sinking Events: If changes are made to the type and / or instance space, the runtime sends the events to the affected clients. The event may be triggered by a specific operation, such as setting port binding information.

Query the type and instance space: The client can reflect the type and instance space.

Type, member and instance space

The relationship between component types, components, and component instances is similar to classes, class members, and objects in modern object-oriented languages. SDM defines separation between types, members, and instance spaces. Component types are in type space, components are in member space, and component instances are in instance space. 31 shows separation between three spaces.

"Member space" contains instances of type space. An "instance space" includes an instance of a member space. The SDM runtime is responsible for keeping track of all three spaces and their relationships. This information is stored in the SDM store and can be queried by using the runtime API. Components and wires can have zero or more instances. A port has only one instance.

SDM member and instance spaces follow a strict hierarchy. All components in the member and instance spaces are arranged in a tree. The root component is a special component called a "root" or "universal" component. Let's look at the member tree from the MyService example in the previous section (Figure 32). The boxes represent components, and the lines are parent / children relationships. myService is a member component of the root component. The instance tree may be configured as shown in FIG. 33. Note that there are two instances of the myService component with different number of child instances. myService [1] .fe [1] and myService [2] .fe [2] have the same component member "fe" and the same component type "MyFrontEnd", but otherwise they are completely separate component instances. "root [1]" is just an instance of the root component.

Component Instantiation

One of the basic operations provided by the SDM runtime is component instance creation. This is the process by which component instances exist. Unlike traditional component models, where creating an instance (or object) typically involves allocating and initializing chunks of memory for an instance, SDM components typically require many steps to be performed by different parts. Related, and may take hours or days to complete. For example, if a component of type ASP.NET application is instantiated, the result is a new virtual Web site on the machine running IIS followed by a configuration act. Considering the scenario of reaching the capacity of an IIS machine, a new one must be allocated before the ASP.NET application is instantiated. This process can take several hours because it involves allocating new machines from the pool, possibly generating building changes, and installing an operating system that includes IIS. The SDM runtime supports two methods for creating component instances, two methods: 1) a factory instantiating a component and 2) a runtime creating a component instance. This method is briefly described below. See the "Component Instantiation" specification for more details.

Factory instantiated components

A component factory (or simply factory) is the entity responsible for creating instances for one or more component types. The factory is the component itself that exposes one or more ports for instantiation. One way to think of factories is as a resource manager. Resources managed by the factory are component types. The factory knows how to map resources to instances of the component. For example, suppose we have a type component "File Storage". When this component is instantiated, NTFS discovery will be created, and appropriate ACLs will be prepared. The factory for this component manages a number of window machines to allocate storage. The factory is responsible for creating NTFS shares, setting up ACLs and shares to share. Component factories play an important role in the SDM runtime. Because they typically manage resources for services, they are expected to be reliable and high availability. The number of component factories supported by the SDM runtime is open ended, but we expect BIG V1.0 to have a small number of default component factories. The component factory looks like this:

Hardware-This is the base level factory responsible for allocating and managing instances of hardware. For example, it can allocate server machines using 1GB of memory, or storage devices such as NAS.

Network-This factory is responsible for VLANs, public IP addresses, DNS names, etc.

PC-This factory can allocate machines and distribute full OS-images to it.

* Storage-This factory is responsible for managing and allocating storage.

* Software resources-ASP.NET, IIS web site, SQL server, database, etc.

Instantiation process

The factory must register using the SDM runtime, which specifies which component type is responsible for creating the instance. At high level, the process of instantiation is as follows:

The caller asks the SDM runtime for a component factory for a given component type.

1. The SDM runtime is responsible for finding the appropriate component factory and returning it to the caller.

2. The caller then communicates directly with the component factory, requesting that one or more instances be created.

Running Factory Table

The SDM runtime keeps a table of component types and their appropriate factories. Every component instance has a running factory table. The running factory table structure is as follows:

(ComponentTypeID, PortType)-> (PortInstance, [cookie])

Component instances can add / remove entities to their tables and their direct children's tables. By default, when a new child component instance is created, the parent's running factory table is inherited.

Running factory tables are tracked for all component instances to support different factories for the same component type in different environments. Since factories are typically where resources are allocated, hosting an environment can require different policies for resource allocation. For example, consider a scenario where hosting entities such as Digex have different plans for their customers. Customers paying for Gold get a dedicated IIS box, and customers paying for Silver get a shared IIS box. The customer's service includes components of the "ASP.NET application" type, which does not know whether it is hosted on a dedicated IIS machine or a shared IIS machine. Digex may implement this as shown in FIG.

Digex is a component with two components: Gold Factory and Silver Factory. The factory is the component itself. Digex also defines other components called "gold" and "silver". This "gold" component is the parent of all services paid for the gold service.

When Digex is instantiated, it creates an instance of the factory and instances of "gold" and "silver" components. Gold [1] has its own running factory table. Digex registers a gold factory in this table by calling the appropriate SDM runtime API. When a new customer's service is instantiated as a child of Gold [1], it inherits Gold [1] 's running factory table. This means that when a component instance of an "ASP.NET application" is created, the Gold Factory processes this request and charges the customer's account accordingly.

Factory tracking

The SDM runtime keeps track of the factory that created each component instance. See FIG. 35. The dotted line represents the "created by" relationship between the component instance and the factory that created it. As mentioned above, the factory is the component itself, so the factory must have a factory. Ending the infinite iteration of the runtime is a factory for "runtime-hosted components" as described below. Note that the root component instance is special and it is its own factory.

Factories and Transactions

The factory supports transactions so that service developers can be less concerned about complex rollback and error handling logic. Factories not built on top of the transacted subsystems need to support compensation. The factory must also support enlisting in distributed transactions.

The factory typically holds a number of bookkeeping information related to instance creation. This bookkeeping information should be kept consistent with the SDM runtime to ensure proper recovery. To facilitate this, the SDM runtime provides a transacted storage service for the component instance containing the factory. A well-written factory stores all bookkeeping information in this store.

Factory port

The factory typically exposes one or more ports that can be used for component instantiation. The port type is not commanded by the SDM runtime, but it is recommended that all component factories support the SDM_Factory port. SDM_Factory is a SOAP based port that is called to create a new component instance. The C # interface for this port is:

public interface ISDMFactory

{

ComponentInstance Instantiate (

ComponentInstance parent,

Component component,

ComponentType componentType, object args);

void Alloc (ComponentInstance allocInstance);

void Construct (ComponentInstance constructInstance);

}

ISDMFactory supports three pass instantiation processes:

Instantiation Pass: This pass uses the SDM runtime to iteratively create all component instances. However, it does not assign or construct. It just creates the required "skeleton" component instance.

Allocation Pass: During this pass, all relevant component factories allocate all resources necessary for instance creation.

Construction Pass: If the assignment succeeds, the construction pass is started. This is typically the longest running pass. The factory typically does all the actual work during the creation pass.

The factory can of course support other port types for instantiation. However, the SDM runtime and runtime APIs have a number of auxiliary functions that work well with the SDM_Factory implementation. These APIs will certainly enhance the developer experience for the majority of developers.

Runtime-hosted component instances

In addition to the factory, the SDM runtime also hosts implementations for SDM components that reference CLR assemblies using implementation SDML keywords. The referenced CLR assembly is a literal string that is the fully qualified name of the CLR class. E.g,

componenttype A

{

port pt x;

implementation

"MyNamespace.MyClassName, MyClrAssemblyName"

}

Alternatively, you can specify the culture, version, and key for a strongly named CLR assembly:

componenttype A

{

port pt x;

implementation "MyNamespace.MyClassName, MyClrAssemblyName, culture = neutral, version = 1.0.0.1234, PublicKeyToken = 9a33f27632997fcc"

}

For these components, the SDM runtime acts as a factory, and the SDM runtime hosts and manages these CLR classes. This also ends the infinite iteration of the factory described above since the base level factory is implemented as a CLR assembly hosted by the SDM runtime.

CLR assemblies are hosted using Microsoft's IIS server. Implementation keywords refer to classes, which must inherit from MarchalByRefObject and implement the IRuntimeHostedImplementation and ISDMFactory interfaces. For convenience, the default class SdmComponentInstance provides a default implementation of this interface. The following is an example of a runtime hosted CLR implementation for component type A above.

public class A: SdmComponentInstance

{

protected override void OnCreate (object args)

{

// do something

}

}

Class A is a C # class that inherits from SdmComponentInstance and can therefore be hosted by the SDM runtime. The CLR assembly for this class must be located in the / bin directory of the SDU for this to work properly. When an instance of a component of type A is created, the runtime is responsible for searching for available host IIS machines and instantiating CLR code on those machines. The CLR code is hosted as a .NET remote application hosted by IIS. All CLR assemblies in an SDU share an IIS process and have their own AppDomain within that process.

When the CLR assembly is loaded, the runtime makes .NET remote calls to well-defined entry points on the IRuntimeHostedImplementation interface. In this respect, the CLR class is equivalent to the ComponentFactory, and the ISDMFactory interface is consumed as mentioned in the previous section.

Ports and Wires

Ports and wires are the basis for communication within the SDM runtime. Ports and wires solve many of the common problems in service deployment today:

Hard coding of communication information-Many services typically hard code the server's name or ip address into code. For example, front end servers typically hard code SQL Server machine names as well as connection information such as database names, logins, and passwords.

Defining a communication topology-Most service distributions typically use a DMZ as the only mechanism for defining boundaries for communication. No other constraints are required, for example if the front end server needs to communicate with other front end servers, this is not captured anywhere.

Discovery-Finding new components added to or removed from a service is typically a problem facing services today.

SDM solves this problem using ports and wires. A port is a typed entity that is exposed to a component. A port is similar to a server access point-this is where the component exposes well-defined functionality. For example, a "storage" component defines a port of type SMB.Server that can be used for file system operation. Wires define acceptable binding between ports. This forms a communication topology that can limit the communication path.

From the above, let's try the MyService example again.

componenttype MyService

{

component MyFrontEnd fe;

component MyBackEnd be;

port http = fe.http;

wire SqlTds tds

{

fe.catalog;

be.sqlServer;

}

implementation "MyService, MyClrAssembly";

}

MyService contains a single wire called tds. Wires can have instances just like components. For example, here are two component instances of MyService ms [1] and ms [2] with two different wire instance topologies.

component instance ms [1]

wire instance tds [1]

fe [1] .catalog

fe [2] .catalog

be [1] .SqlServer;

component instance ms [2]

wire instance tds [1]

fe [1] .catalog

be [1] .SqlServer;

wire instance tds [2]

fe [2] .catalog

be [1] .SqlServer;

ms [1] has a single wire instance tds [1] containing three port instances. ms [2] has two wire instances tds [1] and tds [2] each with two port instances. In the first case, fe [1] and fe [2] can be seen from each other. In the second case, fe [1] and fe [2] are not visible to each other.

Wire instances form a physical communication topology. Port instances are members of wire instances. They can do the following:

1) You can query each other or find each other-the runtime API supports the ability to query and discover other port instances on the same wire instance. All members are visible within the same wire instance. Also, the owner of a wire instance can query a member at any time.

2) Can Receive an Event-A member of a wire can receive an event triggered by an SDM operation on a member port instance. See "Events" below for details.

3) You can restrict communication-wire instances limit the allowed communication paths between component instances.

Port binding information

A port is a typed entity that is exposed by a component. The port has exactly one instance. A port instance can carry binding information, which is typically all that is required to establish a communication channel between components. For example, the above-described "be [1] .SqlServer" port instance may have the following binding information for connecting to the SQL backend.

"server = mySQLServer; uid = myLogin; pwd = myPwd;"

This string can be sent to ADO or OLEDB and the TDS connection can be established to the backend SQL server. The SDM runtime does not interfere with communicating parties. It merely acts as a holder of any information required to initiate communication.

Port visibility and wire instance

Port instances on a component instance can only be viewed as different component instances if attached to the same wire instance. This is a fairly powerful mechanism for building logical network topologies for services. The SDM runtime also supports means for creating the physical virtual network needed to implement wire instance constraints and for using packet filtering. See "Networking Architecture" for more information.

Events

The SDM runtime generates some intrinsic events as a result of operations on the SDM instance space. For example, an event occurs when a component instance creates a port instance. Depending on the specified event, the destination is a port instance or composite component instance on a given wire.

All events are forwarded to component instances on runtime ports. The SDM runtime library is responsible for trapping these events and translating them into language-specific calls. For example, the CLR-based SDM runtime library generates CLR events.

Component instance events

These events occur when a component instance is created or an existing component instance is deleted. The destination of an event is always a parent compound component instance. Events are only sent to the parent component instance directly above-they do not spread the instance tree. From the above example, assume that component instance "u [1] .foo [2]" requests that the runtime create a new instance of member component "c". See FIG. 36.

The code for component instance "u [1] .foo [2]" is currently running on machine 1. Using the SDM RTL, it asks the runtime to create a new instance of component "c". The runtime knows which component instance to call, and can disambiguate and scope. A new component instance is created, an event is raised and passed back to the calling component instance. If the instance is destroyed or fails, the runtime sends the appropriate event to the parent component instance and the appropriate component factory.

Port instance events

When a component instance creates a port instance or deletes an existing port instance, the parent component instance will notice the change. See FIG. 37. When a port instance is attached to a wire instance, all members of the wire instance know of the change as well as the parent component instance. This is described in the next section.

Port states

Every port instance can be in one of the following states:

Created-This is the state of the port when it was first created. This triggers an event sent to the parent component instance.

Attached-The port is in this state when the port is attached to the wire instance. This triggers an event that is sent to all member and parent component instances of the wire instance.

Online-The port is in this state when it is ready for operation. This triggers an event that is sent to all member and parent component instances of the wire instance.

Offline-The port is in this state if it wants to stop normal operation. This triggers an event that is sent to all member and parent component instances of the wire instance.

Detached-The port is in this state when the port is detached from the wire instance. This triggers an event that is sent to all member and parent component instances of the wire instance.

Deleted-The port is in this state when the port is removed from the instance space. This triggers an event sent to the parent component instance.

Wire instance events

Wire instance events occur when wire instances are created or deleted. The destination of these events is always the parent component instance with the wire. See FIG. 38.

The wire instance may include port references to its members. This wire membership determines the destination of certain member port events. Review the example above. Assume "foo [2] .c [2]" creates a number of new instances such as:

component instance universal [1]

component instance foo [2]

component instance c [2]

port instance y [1]

component instance b1 [1]

port instance x [1]

component instance b2 [1]

port instance x [1]

wire instance p [1]

b1 [1] .x [1]

b2 [1] .x [1]

Note that the wire instance "p [1]" includes references to two port instances, "b [1] .x [1]" and "b2 [1] .x [1]". It is assumed that component instances "b1 [1]" and "b2 [2]" each run a separate machine. In FIG. 39, an event occurs when "b2 [1]" changes its port state to offline.

It should be noted that "b2 [1]" is hosted on machine 3, which invokes "set port state" on runtime. The runtime records the change and sends three states-one to the wire instance owner "u [1] .foo [2] .c [2]", and two to the wire port instance member, "b1 [ 1] .x [1] "and" b2 [1] .x [1] ".

Event Delivery and Queues

The runtime guarantees to deliver events in order, but does not guarantee complete virtual synchronism between all members of a given wire instance. In other words, the SDM runtime can allow future progress even if the component instance is running or stopped slowly.

SDM events are queued for each component instance. If the event is successfully queued to the target's queues, the action that triggered the event is considered successful. Cues are inherently circular and repeat if the component is severely delayed or stopped. By looping iteration a new "wrap-around" event will be generated. This event is sent not only to the component instance itself, but to the parent and any owning factories.

Runtime split

To support multiple clients, the runtime can be partitioned. Because of the strict hierarchy of SDM instance space, this problem is very easy to handle. The SDM runtime can be hosted on many machines across specific deployments. Each SDM runtime instance is responsible for tracking part of the instance space. Component instances use the SDM runtime library to communicate with the appropriate runtime. 40 shows a segmented runtime and several clients.

The machine 1 includes two component instances and an SDM runtime library. The machine 2 includes a single component example and a runtime library. The machine 3 becomes a host for the dedicated SDM runtime. The machine 4 has an SDM runtime and component instances. It should also be noted that two SDM runtimes on machines 3 and 4 communicate.

Division

The runtime splits itself by affecting the native layer in the SDM. The partitioning action involves distributing portions of the SDM type and instance space across different operational runtime examples. Variance is essential for scalability. Dispersion occurs differently for types and examples.

유형과 멤버 스페이스: 소정의 런타임은, 통상적으로 이름 스페이스 내에 체계화되는 많은 유형 정의를 포함할 수 있다. 각 런타임은 추적하는 예들에 의해 정의되는 멤버들과 유형들에 대해 알기만 하면 된다. 이들은 다중 런타임 상에 나타날 수 있다. 즉, 유형과 멤버 스페이스 내에 오버랩이 허용된다.

Types and Member Spaces: Certain runtimes may include many type definitions, typically organized within a namespace. Each runtime only needs to know about the members and types defined by the tracking examples. These can appear on multiple runtimes. That is, overlaps are allowed within types and member spaces.

인스턴스 스페이스: 소정의 런타임은 인스턴스 스페이스의 일부분을 추적하기만 하면 된다. 인스턴스 스페이스는 복합 컴포넌트 인스턴스 경계들 상에서 분할된다. 인스턴스 스페이스 내의 오버랩은 허용되지 않는다. 이것은 예에 의해 가장 잘 설명된다. 다음의 컴포넌트 유형 정의를 보자.

Instance space: Some runtimes only need to keep track of a portion of the instance space. The instance space is partitioned on the composite component instance boundaries. Overlap in instance space is not allowed. This is best explained by example. Consider the following component type definition.

componenttype B {

port X x;

}

componenttype C {

port Y y;

component B b1;

component B b2;

wire P p {b1.x; b2.x; }

componenttype A {

port internal Z z;

component C c;

wire W w {z; c.y}

}

componenttype universal u {

component A foo;

component A bar;

}

This definition contains three component types: A, B, and C. A is a member of the root universal component. B and C are members of A. As shown in FIG. 41, the member space is shown in a picture. Boxes will be used to represent composite components. Compound component members, not other composite components, are described in the component box. In this example, the wire "w" is a member of the composite components "foo" and "bar" and therefore appears in the box "a".

In the instance space, there are many examples of each component, port, and wire. The instance hierarchy is shown in FIG. 42. The box here represents the tracked instance state for the component instance. This is not component instance implementation code.

Suppose you want to split the SDM model between three runtimes, Runtime1, Runtime2, and Runtime3. 43 shows an example of dividing the example space. In this example, runtime1 tracks "general [1]", "foo [1]", "foo [2]" and "bar [1]". Runtime2 tracks "foo [1] .c [1]", "foo [1] .c [2]" and "foo [2] .c [1]". Runtime3 tracks "bar [1] .c [1]". In addition, runtimes must know about all types of instances that the runtime tracks. In this example, Runtime3 must know about component types "C", "B" and "A" by the parent "bar". You also need to know port type "Y" and wire "P".

Other runtimes must also have their relationships. This relationship is required by the SDM layer. In the previous example, Runtime1 and Runtime2 manage the relationships "foo [1] .c [1]", "foo [1] .c [2]", and "foo [2] .c [1]". You must know each one. Similarly, runtime 1 and runtime 3 must coordinate the work surrounding "bar [1] .c [1]". Note that Runtime2 and Runtime3 do not need to know about each other.

Split method

The runtime includes enough logic for self partitioning. The specific partitioning method is based on performance, capacity and SDM definition constraints. This division is dynamic and changes as the SDM model evolves.

Single-root runtime

Runtimes that track composite component instances, which are all examples of single-root component examples, are referred to as single-root runtimes. In the above example, Runtime1 and Runtime3 are single root runtimes. Runtime1 has a root instance tree starting at "universal [1]", and runtime3 has a root instance tree starting at "bar [1] .c [1]".

Multi-root runtime

Runtimes tracking complex instances that do not have a root composite component example are referred to as multiroot runtimes. In the example above, run-time2 tracks the roots "foo [1] .c [1]", "foo [1] .c [2]" and "foo [2] .c [1]" all together. Root runtime.

Service installation

Before a service is described on a given SDM runtime, the SDM runtime must first be installed. The installation process includes the following steps:

Steps to Copy Service Deployment Units to Runtime Deployment Shares

Steps to start the installation by calling the SDM runtime API

Service distribution units

SDUs are service distribution units. this is,

SDM assembly-Type information about the new service. Contains all component types, wire types, and port types for this service. This assembly is the result of compiling the SDML service.

Runtime-hosted component instance code-Any CLR code hosted by the runtime and referenced by an implementation keyword in the SDML must be included in the SDU.

Other service binaries-all other binaries such as configuration files, DLLs, GIFs, HTML, SQL scripts, etc. are also considered part of the distribution unit.

It consists of.

SDUs are not changed. Changes to SDUs are not allowed. Once an SDU is installed, it cannot be changed. Of course, you can install an upgraded new version of the SDU and not use the old version (s).

SDU format

SDUs are directories of binaries and potential component factories used by the SDM runtime. The directory is not restricted in format, but the following structure is expected.

\ sduroot

\ <assembly name>. <version>

\ <assembly name> .sdmassembly

\ bin

\ <Runtime hosted CLR assembly_1> .dll

\ <Runtime hosted CLR assembly_2> .dll

\ <Runtime hosted CLR assembly_n> .dll

\ <other files and directories>

SDUs are packaged in CAB files.

avatar

The SDM runtime is implemented as a .NET web service running on an IIL server. SDM storage is a reliable SQL Server database. SDM runtime web services are stateless web services. In other words, any state in the SDM runtime service is temporary. All persistent states are recorded in memory at clear processing boundaries.

The SDM runtime service can be terminated and restarted at any point, even on different machines. If the SDM runtime is pointed at the same SDM storage, all jobs can be restarted with little or no interruption.

SDM memory

The SDM runtime uses persistent storage for SDMs and instances. This storage is typically located on the same machine as the SDM runtime service, but can certainly be distributed differently. SDM storage is a SQL Server database that contains information about all SDM models and their instances.

This reliability and availability of SDM storage is essential. One of the key design goals for SDM is the ability to restart the system in a last know consistent state. SDM thus requires high reliability and must withstand large disaster scenarios. This is implemented in two ways.

SDM storage is duplicated and an extra hot backup is always available. This is implemented using Yukon's redundant database technology.

SDM storage is regularly backed up and stored off site. A backup is a self-consistent snapshot of current models, examples, and any service state stored in SDM storage.

Service storage

The SDM runtime facilitates storage at the component instance level. All component instances use runtime APIs to store data in SDM storage. Even when considering a semi-structure store, at least this is a BLOB store.

The service state stored at runtime is guaranteed to be as reliable and persistent as the SDM runtime. The service state is also guaranteed to be consistent with other runtime states. Instead of expecting services to store enough information in their state (in terms of indicators), it does not, of course, talk about all service states to be stored in SDM storage. Once recovered, the service can retrieve the indicators of that data and perform the necessary steps. See recovery below.

SDM runtime security

Scenario description

There are two basic scenarios for defining a security model for the SDM runtime. Developer test-run scenarios and operator production deployment scenarios. Common requirements for both scenarios are as follows.

SDM 런타임이 실행되고 있는 컴퓨터로부터 타겟 서버들로 접속할 수 있는 능력

Ability to connect to target servers from the computer running the SDM runtime

액티브 디렉토리(Active Directory) 도메인 계정들을 사용한 윈도우 인증

Windows Authentication Using Active Directory Domain Accounts

설치, 업데이트 및 설치제거 동작들을 위해 타겟 서버 자원들에 접근하기 위한 신뢰 서브시스템 모델

Trusted subsystem model for accessing target server resources for install, update, and uninstall operations

윈도우 서비스로 구현되고 신뢰 서비스 계정으로 동작되는 SDM 런타임

SDM runtime implemented as a Windows service and operating as a trusted service account

SDM 클래스, 유형 및 인스턴스 정보를 추적하는 데이터베이스 역할, 및 윈도우 인증을 사용하도록 구성된 데이터베이스(MSDE)

Database roles that track SDM class, type, and instance information, and databases configured to use Windows Authentication (MSDE)

Developer Test Run Scenario

Developers need to be able to deploy distributed applications to one or more servers in a test environment. Target servers are either part of a single workgroup or in the same Active Directory domain. The computer on which the test run deployment is initiated must be in the same workgroup or domain as the target server (s).

1. A developer creates a Service Deployment Unit (SDU) using Visual Studio.

2. The created SDU is located in a distribution folder on the computer on which the SDM runtime service runs.

3. The developer chooses the distribution behavior (install, update, uninstall) and reminds them of their Windows certification eligibility.

4. The developer is authenticated and mapped to a deployment role that determines whether the authenticated user is authorized to perform the requested deployment action.

5. The developer chooses which components to install, update or delete on which target servers.

6. The SDM runtime service connects to the selected target servers in one of two ways.
If the SDM runtime service is running as a trusted service account in Active Directory, it will connect as an account on the target servers. Otherwise, the SDM runtime service will connect as an authenticated user, which may require additional authentication at the target server if personalization is not possible.

Operator Production Deployment Scenario

Operators must deploy distributed applications on one or more servers in a data center environment. Target servers must be part of an Active Directory domain or forest. The computer on which the test run deployment is initiated must be in the same domain or forest as the target server (s).

1. Application SDUs are located in a distribution folder on the computer on which the SDM runtime service runs.

2. The operator selects the distribution behavior (install, update, uninstall) and recalls about domain eligibility.

3. The operator is authenticated and mapped to a deployment role that determines whether the authenticated user is authorized to perform the requested deployment operation.

4. The operator selects which components to install, update or delete on which target servers.

5. The SDM runtime service connects to the selected target servers as a trusted service account and performs the actions.

Feature Description

Behavior specific

The SDM runtime is responsible for keeping track of all SDM classes, types, and instances. The SDM runtime exposes a set of SOAP interfaces for operation and registration in SDM documents for the purpose of distributing distributed applications.

The SDM runtime includes the following major components.

관련된 런타임 라이브러리를 구비한 웹 서비스,

Web services with associated runtime libraries,

윈도우 서비스,

Windows Service,

MSDE(또는 유콘)와 같은 데이터베이스.

Database such as MSDE (or Yukon).

44 illustrates the relationship between SDM runtime components, deployment tool, and target servers. In FIG. 44, a user interacts with a deployment tool UI or command-line interface to initiate deployment behavior.

The runtime library provides a set of SOAP interfaces exposed by the web service. The web service writes information to the database that the Windows service retrieves to perform the distribution behavior. The web service uses Windows authentication to authenticate the user against the SDM runtime database and permits distribution actions based on the roles defined by the database.

In a production environment, Windows services are run as Active Directory service accounts and target servers are configured to trust domain service accounts for administrative purposes. Windows services use remote WMI with target servers that use personalization (not users) of service accounts. This trust service model is more scalable and minimizes the need to manage per-user based destination sub ACLs. Operators do not have to be administrators on target servers to perform deployment operations.

In a test run environment, the Windows service runs as either an Active Directory service account or a non-privileged network service account without an active directory. The latter requires personalization of the authenticated user account on the target servers.

UI description

There is no UI for the SDM runtime itself. The SDM runtime exposes a set of APIs that can be raised via the deployment tool UI or through a set of command-line tools. The deployment tool UI is specified within a separate document.

Security model

The security model for the SDM runtime is a trust subsystem model that uses a fixed identity to access target servers, and distributed components are distributed to these fixed servers. The security context of an authenticated user does not reach the target servers in this model. The basic assumption of this security model is that the target servers trust the fixed identity of the SDM runtime service, thus eliminating the need to handle administrative rights for each user on the target servers. 45 illustrates a fixed identity trust relationship.

With the trust subsystem, you can run the SDM runtime service under the trusted domain account, or even as a local non-privileged network service account. The point of understanding is that authentication for any deployment behavior is managed by the SDM runtime using role-based authorization, and that only the SDM runtime service, once a user is mapped to a role that allows authenticated and requested deployment behavior, Install, update, and uninstall actions on target servers.

certification

Authentication is the process of verifying a user's identity based on a credential secrete known only to the user and the underlying security infrastructure. For distributed application distribution purposes, users are authenticated using Windows authentication through Active Directory domain accounts or local accounts. If local accounts are used, the local account names and passwords on the distribution computer must be the same on the target servers.

permission

Once a user is authenticated, permission to perform a deployment operation such as install, update or uninstall is granted based on the database role of which the authenticated user is a member. Because Windows user and group accounts are members of the SQL Server database role, the basic order of authorization is as follows:

1. The web service uses Windows authentication to authenticate the user.

2. The web service connects to the database as an authenticated user.

3. A user is mapped to a database role based on user or group account membership.

4. The web service writes the distribution behavior information to the appropriate database table which can be read asynchronously by the window service component of the SDM runtime.

Note that there is no need to manage passwords outside the operating system infrastructure and to manage ACLs on target servers on a per-user basis.

Impersonation

Personalization is the ability to execute code in the security context of an account other than the current process owner. Remote connections to target servers are established using WMI with personalization enabled. Personalization is based on trusted service identity when Active Directory is present and based on the security context of an authenticated user when Active Directory is not available (eg, a test run environment).

Windows service

The Windows service component of the SDM runtime must be run as a service account with administrative rights on the target servers. Because there are requirements to install software on target servers and create various settings for IIS, SQL, and registration, administrative rights are required.

In the absence of an Active Directory domain account, the Windows service personalizes a user account authorized to perform administrative actions on target servers. In this case, the Windows service runs as a network service account that does not require a password and is a non-privileged user on the local computer. Windows services provide local computer eligibility to remote computers when connected.

IIS

SQL Server

SQL Server can operate in two authentication modes. Windows authentication mode and mixed mode. Because Windows authentication mode is more secure than mixed mode, the SQL server for the SDM runtime database is configured for Windows authentication mode only. This prevents the sa account from being used to authenticate the SDM runtime database. Administrative privileges on the SDM runtime database are controlled through window group membership to affect the Active Directory authentication infrastructure. By using Active Directory groups to manage SQL Server and add specific users to groups, it is easier to control access to the SDM runtime database without having to manage passwords on special accounts.

In addition to the SDM runtime database, target servers running SQL Server also use Windows Authentication mode and handle administrative access through Windows group membership. The window group for the SDM runtime database and the window group for the target servers must be different groups. It is a policy decision whether a customer will have one or several window groups to manage SQL Server machines.

For example:

SDM Runtime Administrator Group

User A, User B

SQL Server Tier 1 Administrators Group

User C, User D

SQL Server Tier 2 Administrators Group

User C, User E

SDM Server Overview

Introduce

What is an SDM server-An SDM server is a set of services based around an SDM. Currently, there are two general ways to approach the architecture of two deployment tools. Each is described herein.

Distributed approach

In this approach, tools using the SDM runtime and the distribution engine are formed for the file allocation to locate SDUs (the binaries) using web services and the runtime OM client library that communicates alternately with the SDM runtime engine. SDM and deployment engines share a database of deployment days and SDM entities. Deployment tasks are performed asynchronously by deployment engines using WMI and SMB (file allocation) to communicate with target machines.

Simple approach

In this approach, the client, SDM object model library, SDM engine, and installer plug-ins all run in the same process, so there is no such service. The runtime database and binaries can be on different machines. Connections to WMI and SMB's target machines are made directly from the client or UI.

User interface and other clients

The user interface for the SDM server includes:

애플리케이션의 테스트 인스턴스를 배포, 업데이트 또는 제거하는 간단한 방법을 제공하는 비쥬얼 스튜디오(Visual Studio) 내의 마법사.

Wizard within Visual Studio that provides a simple way to deploy, update, or remove test instances of an application.

SDM, SDU 및 인스턴스 요구들을 로딩하는 명령 라인 도구들.

Command line tools for loading SDM, SDU and instance requests.

객체 모델의 모든 기능을 나타내고 호스트 모델들과 인스턴스 요구들을 구성하기 위한 시각 도구들을 부가적으로 제공하는 완전한 UI.

A complete UI that presents all the functionality of the object model and additionally provides visual tools for constructing host models and instance requests.

Runtime OM Library

The general interface of the SDM server is through this library. This is a managed code object model that allows you to:

런타임에서 SDM을 관리한다. SDM을 런타임에 로딩할 수 있다. SDM은 강경하게 명명되어 변하지 않고 SDM으로 하나씩 로딩된다(즉, 각각의 유형들, 클래스들 또는 매핑들이 아니라 SDM 파일을 로딩한다). SDM을 런타임으로부터 제거하고 런타임에서 SDM을 위한 XML 문서를 생성할 수 있다. SDM은, 런타임 내의 다른 SDM으로부터 또는 인스턴스들로부터 이에 대한 참조가 있는 한, 런타임으로부터 삭제될 수 없다.

Manage SDM at runtime. SDM can be loaded at runtime. SDMs are strongly named and unloaded into the SDMs one by one (ie, loading SDM files rather than individual types, classes or mappings). You can remove SDM from the runtime and generate XML documents for SDM at runtime. An SDM cannot be deleted from the runtime as long as there is a reference to it from other SDMs or from instances in the runtime.

런타임에 의해 알려진 SDU를 관리한다.

Manage SDUs known by the runtime.

(런타임에서 로딩된 SDM으로부터) SDM 요소들을 찾아내고 반사한다. 새로운 SDM을 생성하기 위해 제공되는 API는 없다(즉, 이는 SDM의 불변 요소들에 대한 판독 전용 객체 모델이다). 이는, SDM, SDU, 신원, 버전, 클래스, 유형, 바인딩/매핑 및 버전 정책을 포함한다.

Find and reflect SDM elements (from SDM loaded at runtime). There is no API provided to create a new SDM (ie it is a read-only object model for the constant elements of the SDM). This includes SDM, SDU, Identity, Version, Class, Type, Binding / Mapping and Version Policy.

컴포넌트, 포트, 와이어 및 물리 위치(인스턴스 스페이스에서 호스트 관계)의 인스턴스들을 찾아내고 반사한다. 인스턴스 스페이스에서 각 인스턴스는, 안정된 경로 또는 어레이 기반 경로인 GUID에 의해 확인될 수 있다. 경로들은 스트링이고 관련될 수 있다. 관련 경로들을 포함하는 이러한 확인자들은, 인스턴스 요구 문서와 같은 문서들에서 발견되고 참조되는 것을 허용한다.

Find and reflect instances of components, ports, wires, and physical locations (host relationships in instance space). Each instance in the instance space can be identified by a GUID, which is either a stable path or an array based path. Paths are strings and can be associated. These identifiers, including the relevant paths, allow them to be found and referenced in documents such as instance request documents.

생성, 토폴로지 변경, 업그레이드, 설정 변경 및 삭제를 포함하는 인스턴스들을 조작한다. 인스턴스 변경은, 업데이트의 원자 유닛을 제공하는 인스턴스 요구의 경계들 내에서 이루어져서 어떠한 에러나 제약 위반은 완전한 요구 실패로 이어진다. 인스턴스는 요구가 있을 때 호스트를 가져야 하므로, 인스턴스 요구들은 또한, 호스트에 바인딩되지 않고 임시적으로 빠져 나가는 것을 허용한다. 이는 또한 하나의 컴포넌트의 설치나 설정에 영향을 미치는 많은 동작들이 수행되고, 설치나 설정 업데이트를 요구가 있을 때까지 연기하여 하나의 업데이트가 컴포넌트 상에서 발생하도록 한다.

Manipulate instances, including creation, topology changes, upgrades, configuration changes, and deletions. The instance change is made within the boundaries of the instance request providing the atomic unit of update so that any error or constraint violation leads to a complete request failure. Because an instance must have a host when there is a request, instance requests also allow temporary exits without being bound to the host. It also performs many actions that affect the installation or configuration of a component, and defers an installation or configuration update until a request is made so that one update occurs on the component.

인스턴스 요구를 생성할 때 인스턴스 요구 내에서 시퀀스를 생성한다. 시퀀스는, 인스턴스 요구로부터 생기는 컴포넌트들 상에서 설치의 순서에 대한 제 어를 허용한다.

When you create an instance request, you create a sequence within the instance request. The sequence allows control over the order of installation on the components resulting from the instance request.

상태가 모든 에러 정보를 포함하게 하고, 요구에 의해 영향받는 컴포넌트들의 설치/업그레이드를 재시도하는 단계를 포함하는 인스턴스 요구들을 찾아내고 반사한다.

Find and reflect instance requests, including having the state include all error information and retrying the installation / upgrade of components affected by the request.

인스턴스 요구를 로딩한다. 인스턴스 요구는, 인스턴스 스페이스 동작들을 대표하는 XML 파일이다. 이 문서는 관련 경로들을 이용하여 애플리케이션 인스턴스들을 생성하거나 삭제하기 위해 재사용 가능한 '스크립트'가 될 수 있다.

Load the instance request. An instance request is an XML file that represents instance space operations. This document can be a reusable 'script' to create or delete application instances using the relevant paths.

데이터베이스 내의 인스턴스 요구로부터 인스턴스 요구 문서를 생성한다. 이러한 문서들은 어느정도 휴대 가능하다.

Create an instance request document from an instance request in the database. These documents are somewhat portable.

SDM 서비스로의 보안 허가를 관리한다. 이는, 목적 기계들을 조작하는데 사용되는 적격들을 설정하는 것과, 특정 호스트 인스턴스 상에서 호스트된 인스턴스들을 누가 창조할 수 있는지와 같은 인스턴스 동작들 주변의 허가를 포함한다.

Manage security permissions to SDM services. This includes setting up the qualifications used to manipulate the target machines and permissions around instance operations such as who can create instances hosted on a particular host instance.

완료된 인스턴스 요구 설치를 포함하는, 위 기능들에 관한 이벤트들에 가입한다. 클라이언트 라이브러리를 로딩한 프로세스의 수명에 의해 이러한 이벤트 가입들은 제한된다(즉, 이들은 일반적인 CLR 이벤트들이다).

Subscribe to events related to the above features, including complete instance request installation. These event subscriptions are limited by the lifetime of the process that loaded the client library (ie they are normal CLR events).

SDM runtime engine

The SDM runtime engine performs the functions represented by the inference and object models on the SDM model.

In a decentralized approach, the library communicates with the runtime engine as a web service and the appropriate course call such as loading the SDM, creating component instances, and obtaining the entire SDM (to reflect on SDM entities). do. This reduces the round trip to the server. The format of many parameters for this web service is XML with the same configuration for SDM files.

In some ways, Web services make all of the functionality of SDM services available to client libraries, making them much simpler to use.

In a distributed approach, the engine performs a check on permissions (see the security documentation for details).

Installer plug-ins

Installer plug-ins are associated with class host relationships. These are closely related to plug-ins that use Visual Studio to provide design experience for the class and generate associated binaries and distribution values within the SDU. They provide the following functions to the SDM server.

호스트들 상의 설치, 설치제거 및 재설치 컴포넌트들. 인스턴스 요구가 새로운 컴포넌트 인스턴스, 컴포넌트 인스턴스의 제거 또는 재설치를 필요로 하는 컴포넌트의 변화가 될 때, 인스턴스, 호스트 인스턴스, 컴포넌트와 연관된 유형들 및 SDU 내의 이 유형들과 연관된 바이너리들를 위해 설정을 하고, 인스턴스의 설치나 설치제거를 수행하는 것은 설치자이다. SDM의 애플리케이션 계층에서, 설치자가 단순히 유형 제공 기반의 .msi를 요구하여 (특정 파라미터들로) 호스트에 설치되고 두번째 태스크를 요구하여 적절한 설정과 포트 관점을 설정하는 호스트 상에서 실행하는 것이 가장 일반적이다.

Install, uninstall and reinstall components on hosts. When an instance request is a change in a new component instance, a component that requires the removal or reinstallation of a component instance, the instance, host instance, types associated with the component, and binaries associated with these types in the SDU are configured and It is the installer who performs the installation or uninstallation of. In the application layer of SDM, it is most common for an installer to simply run a type-provided .msi installed on the host (with certain parameters) and run on a host that requires a second task to set up the proper configuration and port perspective.

컴포넌트 인스턴스를, (토폴로지 변경 또는 가시 포트가 변경됨으로 인해) 그 설정들이 변경될 때 또는 그 포토들 중 하나로부터의 관점이 변경될 때, 업데이트한다. SDM의 애플리케이션 계층에서, 이것이 설치의 두번째 부분의 재구동이 되는 것이 가장 일반적이다.

Update a component instance when its settings change (due to a topology change or a visible port change) or when the view from one of its photos changes. In the application layer of SDM, it is most common for this to be a reboot of the second part of the installation.

포트들 상의 가시 포트들을 설치된 컴포넌트 인스턴스 상의 설정들에 매핑한다. SDM 내에서, 컴포넌트 인스턴스는, 몇몇 와이어 토폴로지의 결과로, 다른 포트 인스턴스들의 상세를 볼 수 있게 하는 포트 인스턴스들을 가져서, 통상 이에 속박된다. 예를 들면, ASP.NET 웹 사이트는 데이터베이스 클라이언트 포트 인스턴스를 구비하여 데이터베이스에 전송될 수 있다. 올바로 전송될 때, 그 데이터베이스 클라이언트 포트는 하나의 데이터베이스 서버 포트를 볼 수 있다. 이 정보는 ASP.NET 설치자에 의해 사용되어 서버를 위한 접속 스트링을 클라이언트 포트의 이름으로 web.config 파일 내에 위치시킨다.

Map visible ports on ports to configurations on installed component instances. Within an SDM, component instances have port instances, which are typically constrained to them, as a result of some wire topologies, allowing them to see details of other port instances. For example, an ASP.NET Web site can have a database client port instance and be sent to a database. When sent correctly, the database client port can see a single database server port. This information is used by the ASP.NET installer to locate the connection string for the server in the web.config file with the name of the client port.

설치자는 또한 호스트들과 그들의 게스트들 사이의 제약을 체크하는 코드를 제공한다. 이러한 체크는 SDM 엔진에 의해 수행되는데, SDM 엔진은 상기의 분산된 접근에는 나타나지 않았다. 대부분의 설치자들은 XML, X패스(XPath) 및 X쿼리(XQuery)에 기초한 공통 제한 언어를 사용하는 것으로 기대된다.

The installer also provides code to check the constraints between hosts and their guests. This check is performed by the SDM engine, which did not appear in the distributed approach above. Most installers are expected to use a common restriction language based on XML, XPath and XQuery.

심사 설정(Audit settings)

Audit settings

심사 존재(Audit existence)

Audit existence

가득 찬 심사(Audit Full)

Audit Full

심사 호스트된 인스턴스들(Audit hosted instances)

Audit hosted instances

Set mapping of components

interface

It provides a set of base mechanisms to installers, such as executable commands, as local systems on hosts. In the future, others provide more mechanisms that only require net addresses and accounts.

The interface is managed code.

design

The following sections describe how to design distributed applications and data centers hosted by data centers. Designers use SDM to create various building blocks (eg, hardware, networks, host servers) and applications that are used to organize the physical resources used in the data center.

Data center description

This section describes how to create data center components without representing specific resources such as many machines. It uses a service definition model (SDM) semantics to provide a scale-invariant model of the physical data center environment.

A virtual data center (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 could describe a data center in the same scale-invariant way that developers can describe distributed applications / services. VDC is an abstraction of servers, networks, and storage resources within data centers and their topology relationships.

A typical data center diagram is very complex, with multiple interconnected servers, network equipment, IP addresses, VLANs, operating systems, and storage devices, all represented in a single diagram using business or similar tools. In addition to diagrams, there are usually long documents that describe exactly how the data center is divided, organized and managed.

An example of this complexity is the Microsoft Systems Architecture (MSA) Enterprise Data Center (EDC). It's no surprise that updating and upgrading hand-drawn diagrams and documents to the status of several data centers is expensive if not impossible, if not possible to maintain at present. Similarly, the ability to validate the environment for document specifications is difficult and prone to human error.

The ability to scale-invariably represent complex data centers such as the MSA EDC is powerful for both developers and IT professionals. The ability to describe data centers using components, ports, and wires provides a powerful framework within which to create and validate deployment requirements that are missing from today's design and deployment processes.

One aspect of the data center description is the ability to realisticize the hardware and configuration mechanisms for a collective computing environment. In traditional data center environments, operators typically create hardware environments for specific applications. For example, when deploying a new email system to a data center, operators purchase a set of servers, add network adapters for other networks such as backups and data zones, and add network hardware such as switches and load balancers. The deployment of hardware for the application requires more physical effort.

Expensive to make Application-specific hardware configurations are not only made by hand, but easily changed. Their fixed nature results in poor resource utilization as resources move easily into new applications as the work load changes.

This disclosure describes a method of creating a data center realization environment that enables operators to run a pool of physical resources including servers, storage devices and network devices. From this one pool, resources are allocated and distributed on demand to meet application needs. Resource set providers track the ownership of resources and know how to organize them to meet application needs.

When deploying a new application to a data center environment, operators create an abstraction of the resources the application needs. The request relates to a service platform that requires the abstraction technology to turn into true resources. The service platform works with resource managers to locate resources that can execute requests, select the resources that make the most economical execution of the request, mark the resources used, configure the resources to meet the requirements of the request, and allocate them. Place a detailed description of the resources involved in the abstraction technique. As the needs of the application change, the operator updates the resource description and requires the service platform to resolve the updated application description. Each resource provider can configure hardware resources to use hardware or OS specific software drivers to meet application needs.

Concepts associated with data center descriptions include: (1) a graph language for describing preferred resources, resource requests, and approved resources; (2) a set of domain specific resource providers with the ability to know certain types of available resources and to configure these resources to meet application requirements; And (3) process resource requests, communicate with resource providers to find appropriate available resources, selectively optimize the selection of specific resources, require resource providers to configure selected resources, and reflect the selected resources. Contains a resource manager that updates the request.

Application description

Applications can similarly be defined using SDM semantics. This is described above in more detail with reference to the SDM section beginning at paragraph 0. 20 shows a graphical user interface (UI) that allows a large proportion of distributed applications to be described in terms of SDM semantics.

Logical Placement of Applications into Physical Systems

Once applications and virtual data centers are configured using SDM semantics, the architecture logically attempts to place application elements logically differently of virtual hardware elements. There can be different logical locations for different deployment environments (development, test, production, etc.). Logical locations can be made at design time, requirements and constraints are checked, and the developer is alert to any errors or warnings. The result of the logical location is recorded in a separate file with constraint checks implemented using XPath and XSD specific to each component, port and wire class. This is shown in FIG. The designer can use a user interface (UI) for intuitive gestures when placing other application elements in the physical elements.

Design time validation

The next section describes an approach to design time validation that logically places an application on physical resources. Extensions to SDM components, ports, and wires add layers and mappings between layers and deployment requirements to achieve design-time validation of distributed application designs.

When combined with components, ports and wiring hosts, factories, resource managers, and the SDM runtime, they are powerful abstractions, but they are not enough to deploy and manage distributed applications / services. In order to create and manage physical instances of this logical abstraction concept, some additional structures are included. These additional structures are layers and mappings.

Tiers

11 illustrates the hierarchical abstraction concept defined by the SDM.

The application layer describes components that can be distributed in terms of applications / services, their deployment requirements and constraints, and their communication relationships.

The distribution layer describes the configuration, policy settings, and restrictions for hosts such as IIS, CLR, and SQL.

The Virtual Data Center (VDC) layer describes the constraints from the operating system down to servers, networks and storage through data center configuration and network topology.

The hardware layer describes the physical data center environment and is exposed or specified in a declarative way using, for example, XML. This layer is not scale-invariant and therefore is not created within the SDM and is included for completion.

Mappings

Since SDM is layered, there is a need for a way to tie several layers together. Mappings must bind components or ports in one layer to components or ports below the next layer. The 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 ] [...]

M represents a mapping, T represents a component, port or wire, and n represents a hierarchy. The arrow always indicates the direction of the mapping from the upper layer to the lower layer.

For example, in FIG. 12, a component in the application layer named MyFrontEnd is mapped to a component in the distribution layer called IIS. In the same way, a component named MyBackEnd is mapped to a SQL component in the distribution layer.

Design-time validation

The binding between the lower layer components and their host components can be a problem for developers before the application / service is actually deployed to the live data center. This can be due to incompatible types, configuration conflicts, inconsistent behavior, lack of topology relationships, and so on. For example, the attempted mapping shown in FIG. 13 may be an error because there is no potential communication relationship between IIS and SQL components at the distribution layer.

Although the mapping from the MyBackEnd component to the SQL host component is a valid binding based on component and host type compatibility and lack of configuration conflict, it is not valid because MyService SDM defines a topology relationship between MyFrontEnd and MyBackEnd that does not exist in a particular deployment layer.

Layered architecture

48 illustrates a platform architecture for automated design, deployment, and management of distributed applications on a distributed computing system. The architecture shows multiple layers on top of the base layer 302 that represent the physical computer resources of the distributed computing system. The automated distribution service layer 304 provides tools for converting a machine into a server for use in a distributed computing system. These tools allow the creation, editing and distribution of operating system (OS) images. Remote programming of a machine is accomplished using complete programmatic interfaces, such as Windows Management Instrumentation (WMI), a programming interface (API) within the Microsoft's Windows® operating system that allows system and network devices to be configured and managed.

The network management layer 306 is located at the top of the automated distribution service layer 304. The network management layer 306 considers network management and virtual topology creation. In part, the network management layer supports a driver model for network computers that facilitates connection through a single physical network interface that is connected to an associated port of network switches to one or more VLANs of each computer. Depending on the driver model, the VLAN driver is installed on the server and used to create virtual network interfaces (VNICs) on top of a single physical network interface. The VLAN driver creates one virtual network interface (VNIC) for each VLAN. VNICs reside directly above the network interface (NIC) within the server's IP stack, so that all packets pass through the same physical NIC, but the server can handle packets passing through one or more VLANs.

The driver model supports tagged VLANs so that data packets pass through a distributed computing system to tag them with the identity of the VLAN to which they belong. Network switches only receive packets with tags that tag and identify the VLAN to which the switch belongs. In one embodiment, network switches have both tagged and untagged ports. The tagged ports on the switch are tagged with the VLAN identifier and are used for access to tagged ports on other switches. This allows for fast transmission of packets over the switch network. Untagged ports on the switch are used to connect to servers or computers. When packets arrive at their target server, the VLAN tags are removed from the packets before delivering the upper packets to the servers so that the servers do not need to know about the tag.

Physical resource management layer 308 resides on top of network management layer 306. Physical resource management layer 308 maintains a physical model of a distributed computing system, while tracking ownership and adjusting the allocation of all physical computing resources. Physical management layer 308 also supports batch resource allocation, enabling dynamic configuration and management of physical computing resources.

The logical resource management layer 310 is located at the top of the physical resource management layer 308. The logical resource management layer 310 facilitates the allocation of logical resources requested by the distributed application. For example, an application may require resources such as database load balancing services, firewalls, and web services. Logical resource management layer 310 publishes these logical resources.

The next layer is the service definition model and runtime layer 312, which may describe the tracking of distributed applications and their behavior. The service definition model (SDM) provides namespaces and perspectives to describe the operational process, and APIs for application introspection and control of application resources.

The sixth layer on top of the computing resources layer is the component layer 314. This layer allows the definition of reusable building blocks of distributed applications that use SDM APIs for perspective, naming and binding.

The top layer is the operational logic layer 316, which accommodates the operational aspects of distributed applications. The operational logic is responsible for starting services, advancing and shrinking services, upgrading and downgrading, detecting and repairing errors, and partitioning the state. Operational logic enables reuse of proven operational execution across deployments and applications. Through the use of the SDM layer, operational logic can better understand the issues that may arise. For example, when an error occurs, the operation logic can determine that it occurred at the front end of the email service rather than any server in the room.

distribute

The following sections describe the deployment of data centers and distributed applications. This includes the immediateness of logical models, the physical location of applications, and the deployment of applications and data centers. Figure 23 generally shows the distribution phase.

Instantiation

Since SDM types are rate invariant and can be generated at any rate, one aspect of deployment is to physically implement the hardware / application by defining the number of instances created for a given logical component and wire topology. The instance request document is created to provide a declarative definition of the instances that need to be created.

Physical placement of the application

Physical placement refers to the act of extracting a specific host instance that is the target of deployment. Physical placement is constrained by logical placement, and constraints are updated during physical placement. Physical batches are stored in a physical batch file.

Data center and application deployment

SDUs, logical batch files, instance requests, and physical batch files are supplied to the SDM runtime. The SDM runtime creates a new instance on the host and invokes the appropriate installer (based on class and host relationships) responsible for matching the configuration values on that type. The SDM runtime will maintain a database of all instances, their final configuration values and location. The runtime API supports instance space questions.

BIG Deployment Tool

Scenario description

Feature summary

The BIG Deployment Tool performs distributed SDM application deployment for data center operators and developers who test applications. This consumes Service Definition Model (SDM) applications that include a set of bits of the application (SDU), mapping files, and distribution constraints. The user specifies the deployment of the application to the users' servers and provides deployment time settings. The tool installs or uninstalls instances for remote machines and provides situations to the operator. The operator can later add new instances, decommission instances, and reconfigure the application's topology.

Scenarios

Large enterprises have separate data centers and developer organizations. The data center distributes, maintains, and hosts applications for end-users who serve both employees and customers. The topology of the data center has changed from time to time to closely match the MSA EDC 1.5, not the BIG computer.

Data center organizations provide developers with a scale-invariant abstraction of a hosting policy called the Logical Information Model (LIM). The policy defines the configuration of hosts including constraints, admission settings, and basic topology for the applications.

The developer organization codes and hot fixes these applications to meet end user needs and stay within the policy of the data center. The developer provides deployment guidance by specifying application requirements and expected hosts.

Application operators use the BIG deployment tool to deploy applications in the data center. The deployment tool uses developer guidance and data centers to ensure proper deployment. The application operator later uses the deployment tool to scale out, reconfigure, or uninstall the application topology.

Feature Description

Behavioral Specification

The following describes an overview of how the distribution tool harmonizes with "Whidbey" and other products. Note that SDM runtime, LIM, SDM / SDU and Whidbey are described in other specifications. 49 illustrates an example usage flow for application distribution.

Important points about the communication in FIG. 49 are as follows (from left to right).

The developer delivers an application SDU containing SDM, binary numbers and SDU mappings. (We use binary numbers here to mean application bits and content.)

Developer and data center organizations are separate but share the same LIM. The machine implementing the distribution tool has an SDM runtime with storage and APIs.

The application operator is responsible for the data center description, deployment description, and uses LIM, SDU, and SDU mappings.

An agent and "mini-factories" reside on the target servers, which have SDUs, Deployment Descriptors, and Datacenter Descriptors as inputs for deployment.

Agents interact with mini factories using a common mini factory API.

The mini factories in this embodiment are SQL and IIS and can be extended to other products. They can work on installation, configuration, and uninstallation.

Overview of settings and constraints

The BIG deployment tool consumes SDM applications. In order to understand how the deployment tool will use settings and constraints, here is a basic overview of the settings and constraints in conjunction with SDM. For a complete description of the settings, constraints, and schemas, see the related description. In this discussion, it does not distinguish whether the settings / constraints are on an SDM meta-type, type or member.

By the SDM model, developers, network architects, and application operators can configure / constrain conditions (network architects and developers), SDU mappings (developers), and deployment-time settings (applications). Operators). These constraints and settings will be scoped to a host (ie IIS, SQL, BizTalk) each having its own schema, rules, and values.

The settings of each host's public group will be divided into those that can be configured by the application and those that are preserved by the host. The former is called application settings and the latter is called host settings. In addition, the host restricts application settings by defining "host constraints," and the application imposes the requirements on the host settings via "application constraints." It can be a range of values, or a specific value or a variable value.

The following table summarizes the settings and constraints for hosts and applications.

Table 1: Configuration Definitions

Definition of settings / constraints Yes Application settings-settings are made by the developer for the application Shopping application: maxWorkerThreads = 8
401k application: maxWorkerThreads = 4 Application Constraints-Requirements for "host settings" are required to implement the application Mode = WorkerProcessIsolationMode Host Configurations-group of settings for all applications hosted on the resource Mode = WorkerProcessIsolationMode Host Constraints-Limits on application settings (exact values, range of values) High-perf host: maxWorkerThreads <25
Best-effort hosts: maxWorkerThreads <5

The goal of the Logical Information Model (LIM) is to provide an abstracted view of data center policies and deployment blockers. LIM represents the division between host constraints / settings and application constraints / settings. The policy of LIM is authored by the network architect. This policy can be facilitated using a regular Microsoft canonical Microsoft LIM (LIM) that is classified as a LIM file by network architects, developers, or edited into Notepad.

The LIM is then used by developers to record applications and to test the representation of the data center. Developers provide as part of the application metadata for the application settings that the LIM allows, the host constraints the application is implementing, and the placement of components on the hosts. Developers provide instructions for deploying an application on hosts through a mapping file. Non-specific settings will be passed as deployment-time settings provided by application operators (ie IP address or App_pool_ID).

The basic example is that the network architect prescribes other host constraints for customers who purchase services on " High-perf " hosts and " Best-effort " hosts. Host constraints can limit the number of "IO" or "WorkerThreads" differently. In this example, the " High-perf " host settings and the " Best-effort " host settings are the same, using the new mode of IIS_6 '. The developer will record the two applications at different budgets and requirements. The first shopping application will want more "WorkerThreads". The "401K application" is less discriminating. Both applications suppress (require) implementations in "WorkerProcessIsolationMode". 50 shows application settings and constraints, and host settings and constraints.

Aspects of Distribution

When using the BIG deployment tool, there are four phases around SDM application deployment as described below. 51 illustrates exemplary aspects of a deployment tool.

The initial phase is the phase in which the LIM is calculated and represented in the data center in a scale invariant manner and then generates a hardware classification file (data center descriptor).

The Application Development Phase is where developers code for LIM and test and debug their SDM applications using deployment tool APIs.

The install phase is the phase in which the application operator installs the applications on a machine already configured.

The running phase is where the application operator scales out and reconfigures the topology or uninstalls an application that is already running.

Throughout this specification and throughout this flow chart, the term "deployment" is used, which checks for necessary host configuration / constraint checks, signals of host and application incompatibility, recording of application configurations, and mini-factory actions. To include all calls, etc. Mini factory actions are everything that installs, uninstalls, configures, and also hooks into Fusion, MSI, or future Microsoft installers.

Early phase

The initial phase is when LIMs and data center descriptors are created.

The data center's network architect selects and downloads the closest matched, digitally signed LIM from "Microsoft.com." The network architect then edits the file to reflect the desired data center policies, including network topology, allowed application settings, and hosting constraints.

LIM can also be written as the design surface of "Visual Studio Whidbey". In the next step, the network architect nowadays gives the developer organization all relevant policy and topology information that is captured in the "Word" document or the "Visio" drawing. The developer then creates an appropriate LIM to represent the data center and iterates with the network architect to ensure accuracy.

Once the LIM is created, the data center organization classifies its own hardware according to the LIM by creating a data center descriptor file. The data center descriptor maps the LIM components to the running hardware and is called the act of classification. Therefore, data center descriptors are not scale-variable and contain machine-specific details such as IP addresses. The following figure visualizes the data center descriptor but does not present a UI. Note that the LIM may have the concept of "IIS gold" and "IIS silver" logical hosts. In the data center descriptor, these logical hosts are mapped to physical machines, so that "IIS [1] gold" is located at IP address "192.168.11.2" and "IIS [2] gold" is located at IP address "192.168.11.3". Will be located. 52 shows an exemplary visualization of the data center descriptor.

It should be noted that as the data center operator installs / configures the servers, the network, the resources, and everything below the application, the actions need to stay within the LIM. (Note that data center operators are responsible for everything under the application.) Both network architects and data operators perform their work outside the deployment tool.

Application Development Phase

In this phase, the developer codes for the LIM and tests / debugs the deployments using the BIG deployment tool APIs. Such LIM is provided by the data center or classified by the developer on behalf of the data center (as described above).

The deployment tool APIs allow two scenarios for "Visual Studio Whidbey" to perform "F5" and "test / debug" deployments. F5 and test / debug distributions are for a single developer box and multiple machines, respectively. In the F5 system, the necessary bits are already in the target single developer box. In the case of a test / debug, as in normal distributions, the distribution tool requires delivery of bits to the target machine (s). However, F5 and test / debug scenarios allow developers to be warned of conflicting settings and overwrite application and host settings. (Usually, only application settings can be recorded by the deployment tool.) It should be noted that these VS scenarios will not use the SDM runtime. 53 illustrates these VS scenarios.

Important caveats for the Visual Studio "F5" and "Test / Debug" scenarios are:

The BIG Deployment Tool APIs will be called from VS through the wizard.

The VS wizard will select the machines to deploy and get the deployment-time settings (ie IP_address or App_pool_ID = 17).

VS will launch the user interface.

In the F5 scenario, the SDM, SDU, binary numbers, and all the bits already exist in the target single development box. Thus, the recording settings are all that is necessary.

In the test / debug loop, "deploy" involves recording the necessary settings.

Both scenarios signal when settings conflict, allowing you to overwrite the settings of the target machines, including the host and application.

The developer is not shown in FIG. 53 about the concept of SDU mappings for the LIM and coding the application for the LIM. (See the LIM / LID description for more details on LIM.) The developer passes an SDU containing the SDM, binary numbers, and SDU mapping files to the application operator.

Installation phase

In the installation phase, the operator is provided with an application (SDU with mappings) and a data center descriptor (which extends LIM).

In Figure 54 showing application installation, the following warnings are important.

The application operator launches the tool (GUIGCLI).

Copy and load all files and the data center description.

The application is registered at the SDM runtime.

The application operator selects a host / machine of application components. (Examples are provided in the following section.)

During this choice (called "mapping"), constraints are checked against the runtime's view of the world. If you change the external settings of these tools to create a disjoint view, no results can be guaranteed.

The distribution performs and installs host and application constraints / settings checks. (Note that if you have configuration ACLs and caching files on the cache to avoid network crashes, execution will be more complicated.)

The tool makes it clear that it cannot handle stateful data (e.g., the SQL database it currently occupies) via the UI or documentation.

The above steps create a deployment description, which can be reused or modified for specific deployment. (Examples are provided in the following sections.)

The "Preview" function allows the application operator to obtain a list of changes made by the tool. The user can then rerun the tool using the deployment descriptor for which the preview was generated.

Assuming that the distribution descriptor already created is loaded and executed, and the SDM runtime knows the application, the application bits are still available and the same data center descriptor is valid. 54 illustrates an example installation scenario.

Embodiments That Prescribe Distribution

To clarify the flow of data needed to define the distribution, we use the example of MSN that constrains the data center via LIM.

LIM can be digitally signed, time stamped, and versioned. The development organization uses LIM to code two layers of applications hosted on hosts (IIS and SQL servers) in the MSN data center. The developer specifies the host where the component should be hosted and creates an SDU mapping file. This MSN example is shown in FIG.

The following relates to FIG. 55 and illustrates the data flow in application distribution.

SDUs include SDMs.

The developer maps the SDU components to LIM (MSNdatacenter.LIM) to create an SDU mapping file. Mappings are allowable locations.

The data center description classifies real / physical servers according to LIM components and is scale invariant.

SDUs, SDU mappings, data center descriptions, and user input are supplied to the deployment tool to generate a deployment descriptor.

The distribution descriptor defines the components (from the SDU) and installs them on the machines (from the data center description).

The deployment descriptor gets the distribution-time settings such as the URL.

55 shows an example of generating a deployment descriptor file.

In this example, the SDU mapping file allows the developer to constrain the SDM component 2TierApp.MyWeb to the host component MSN9.IIS_MSN bound to MSN, and likewise to 2TierApp.MyDB to MSN9.SQL_MSN. (Here we define a compound component to eliminate the ambiguity for multiple MyWebs.)

The network architect edits MSNdatacenter.LIM, which shows how to configure IIS and SQL constraints and settings. This LIM is not immutable because LIM represents IIS and SQL hosts, not special machines running IIS or SQL. The data center then derives a data center descriptor, which indicates which machines run IIS and SQL as configured in the LIM. Use the notation IIS_MSN [1] and IIS_MSN [2] to indicate that there are two machines running the IIS_MSN component.

The BIG deployment tool takes as input SDUs, SDU mappings, data center descriptors, and (user-supplied) deployment settings, and generates a deployment descriptor. In this example, the distribution descriptor specifies the distribution. Running the deployment descriptor allows you to install / scale-out / reconfigure / uninstall the software for the target servers.

As described in the deployment descriptor body, MyWeb (MyWeb [1]) would be installed on server IIS_MSN [1], MyWeb [2] would be installed on server IS_MSN [2], and MyDB [1] would be server It will be installed in SQL_MSN [1]. Release-time settings are provided by an application operator such as an IP address or App_Pool_ID. Such a deployment descriptor can be reused under the condition that the files it depends on exist.

Phase of execution

Scale-out [in] scenario

For applications already running, the scale-out [in] scenario allows the application operator to add [remove] components, ports, or wires. An example of the usefulness of this feature may be the "Joe_Millionaire" website, where it can be seen that the traffic increases tremendously, scales out only during regular TV periods and then scales in (or nightly).

In the flow diagram for application scale-out [in], the following are important points.

Scale-out [in] is a subset of the installation.

The application operator can select the SDM application to run to:

Add components, ports, wires, and fill in deployment-configurations.

Deleting components, ports, and wires.

Scenarios can be run from deployment descriptors that have already been created or changed. (Assuming the alerts in the same data center descriptor / LIM access to the application, the SDM runtime still has a registered application.) FIG. 56 shows an example scale-out scenario.

Topology-reconfiguration scenario

Topology-reconfiguration allows application operators to rewire running applications without uninstalling and reinstalling. Rewire's examples will change the front-end database into a back-end database.

Important points in topology-reconstruction are as follows.

This scenario differs from scale-out in that you can edit existing ports and wires without uninstalling or reinstalling.

It also potentially allows users to "bridge" two different SDM applications.

57 illustrates an example topology-reconfiguration scenario.

Topology-reconfiguration is useful if you do not want to redistribute the entire application in the event of a failure. For example, "Passport" stores all credit card numbers in the back end and becomes available through the IIS front end. If the front end fails, you may want to redeploy / migrate the data. Instead, you can deploy a new front end (as part of your normal installation) and rewire that new front end to your passport database.

An example of bridging with topology-reconfiguration would be if the "beta_MSN10" application wanted to share the database of the "MSN9" application. The application operator normally distributes "beta_MSN10". Now, the front end of "beta_MSN10" needs to talk to the database of "MSN9" and will require reconfiguration (and new wire) in the database of "MSN9".

Uninstall scenario

Depending on the uninstall scenario, the application operator selects the application, deletes all running instances and updates the runtime. The user does not choose the correct instance to uninstall because this is possible through scale-in scenarios.

The following points are important in an uninstall scenario.

Uninstallation can be performed via existing deployment descriptors (which may have been edited).

The user selects the application to uninstall and removes all instances.

Stateful content must be removed outside of these tools by means of existing means.

58 illustrates an example uninstall scenario.

management

The following sections describe the management of data centers and the distributed applications after they are deployed. Model-based management tools are discussed first, followed by the introduction of introspection / tracking mechanisms and operational logic.

Model-Based Management

Model-based management (or Ops logic) is handled to accept event triggers from the physical environment based on the application developer's purpose of the SDM-based model of the application and policies and operator definitions, and a series of tasks or processing in the context of the model. By activating and organizing them, they encourage change and provide consistency between the model and the physical world.

A trigger or request or other threshold may be the event targeted at a particular instance in the SDM. The component instance will receive the trigger and initiate a series of steps to address the issue identified by the trigger, based on the prerequisites of the situation of the overall application and hardware environment, expressed in SDM. The context of applications and resources from the SDM gives this ability to facilitate this automation and provide greater operational ease to the operational staff of the service.

59 is an overall architecture for the model (BIG) and management portions, referred to as Ops logic or model-based management. The summary of the processor flow in the overall architecture is as follows.

The application developer may define a collective model (SDM) of the new application or define classes of component types that may constitute an end user application or service.

A developer or developer can add an "operator intent" to the model by annotating component types to the model with policies and guidelines for operation, such as setting the minimum number of servers that must be run. Could be

The unit model or SDM runtime of instances executed for the special execution of the application will be kept in the "Unit Model". There is a one-to-one correspondence between the physical machine and the instances that maintain the desired state of each machine.

BIG resource managers work with the "Unit Model" to make changes in the physical world of servers.

Each server will be managed in part by the BIG and in part by the operators outside of the model.

Between the collective model and the unit model, there is a type of Momel-based processing that allows the model to organize changes to physical machines and to perform operator objectives.

Another type of model-based process will be handled in different ways, providing consistency between the physical space and the model.

In the management area, a monitoring system will collect events and group them into alerts.

Components used for events and alerters will be notified of important events. Event information will be provided to the component along with information about the instance or runtime SDM involved to provide a mapping to the model.

If the event is an action trigger, the event can trigger model-based processing, thereby encouraging change in physical machines through a series of organized application tasks.

60 shows a presentation hierarchy of management. This is an enlargement of the model part of the overall architecture stacked horizontally, the collective model corresponds to the SDM, and the unit model corresponds to the SDM instance space. The global resource manager manages requests for individual resource managers (called "factories").

Self-Monitoring / Tracking Mechanism

If a trigger, such as a user request, hardware trigger, or hardware threshold, is selected, the appropriate operating process will be started. The operational process will be a set of operational tasks to be executed. Execution of operational tasks requires processing by orchestration, since each task is a transaction that requires initiation and termination before the next task and may be of long life. The engine that monitors a set of behaviors for executing operational processes is an orchestration engine for Ops logic.

Applying orchestration to a series of operational tasks for potentially distributed servers or hardware resources is a unique approach. These features of Ops logic provide a more sophisticated approach to transaction processing.

Long Life-The operating processes can run for a long time, such as days or months.

Asynchronous-a trigger or event can initiate a transaction or process but cannot wait for the triggered task to complete and process other events.

The steps in a transaction-operational process are actions such as an agent that initiates or sends it, an agent that receives or processes it, and a compensation process that cancels the change if the task fails.

Durability-Ops processes need to last long without being damaged or unstable.

High availability—Availability as well as reliability is required for the operational processes of high availability BIG computers and services.

Ops logic will provide behaviors and application developers with the opportunity to classify and standardize a set of operator behaviors based on triggers in the BIG environment. Once the trigger is activated, the associated series of tasks will be launched. The steps for a particular situation may include instructions for an individual machine, a change in an application component instance, or a change in model or human steps. Each step is a transaction that can succeed or fail with start and end. By using the orchestration engine to step through these tasks, you can manage, track, and report on the process. The orchestration engine will initiate the task, monitor its progress, and report its completion or failure. Orchestration also allows alternative actions to be taken in situations of partial or complete failure, depending on how the orchestration process is defined. See FIG. 61.

Resource manager

The resource manager is responsible for allocating logical and physical resources within the distributed computing system. The resource manager discovers available hardware, process resource allocation requests, and track ownership of logical and physical resources. By providing an interface to a dynamic pool of resources, the resource manager provides a bed-rock for availability and scalability within the server.

The resource manager owns and controls all hardware in a distributed computing system that includes both computers and network devices such as switches. Access to hardware resources in the system is controlled through the resource manager. In addition, the resource manager provides a basic mechanism for controlling logical resources such as load balancing groups.

The resource manager provides a common API for all resource management in the system. Services and runtimes communicate through the resource manager APIs to create resource questions, allocate resources, change resource requests, and free resources.

BIG Resource Manager

Introduction

Feature summary

The BIG defines a distributed service runtime, a common hardware reference platform, and a resource manager. The distributed service runtime provides services with an execution environment for scalability and availability in the form of skeletons, their relationships, and operational logic that define service components. The hardware reference platform defines a common hardware structure that allows a service to run on systems ranging from one to thousands of computers.

The BIG Resource Manager is responsible for allocating logical and physical resources within the BIG computer. The resource manager discovers available hardware, process resource allocation requests, and track ownership of logical and physical resources. By providing an interface to a dynamic pool of resources, the resource manager provides a bedlock for availability and scalability within the BIG machine.

This document describes the purpose, architecture, and implementation of the BIG resource manager. Chapter 1 describes the objectives and driving scenarios. Chapter 2 describes the architecture of resource managers and their associated resource providers. Chapter 3 describes implementation details and APIs.

Discussion

The BIG Resource Manager is responsible for managing the allocation and use of resources within the BIG computer. The BIG resource manager owns and controls all hardware within the BIG computer, including both computers and network devices such as switches. Access to hardware resources in the BIG computer is controlled through the resource manager. In addition, the resource manager provides a basic mechanism for controlling logical resources such as load balancing groups.

The BIG Resource Manager provides a common API for managing all resources within the BIG computer. The service and the BIG runtime communicate through the resource manager API, creating resource questions, assigning resources, changing resource needs, and freeing resources.

Resource providers

Resource managers provide a common interface into resource management, while the actual knowledge of resources comes from a set of resource providers. Resource providers have specific knowledge of the existence and management of a particular class of resources. For example, a network resource provider knows the existence and details of managing VLANs. Other resource providers in the BIG include physical device providers, "IIS VRoot" providers, "SQL" database providers, "CLR AppDomain" providers, and "Win32 Surface" resource providers.

Resource providers extend resource managers with resource-specific knowledge. Resource providers manage the conversion of resource-specific requests into a common question. Resource providers extend the resource manager API with resource-specific configuration APIs through a provider helper DLL. Finally, resource providers add the appropriate state to the resource manager data storage device to allow tracking of information specific to the resource. Higher level resource providers build up on lower level resource providers. For example, an "IIS VRoot" resource provider allocates machines through a physical device resource provider. The stratification of resource providers initiates redundancy and increases the uniformity of resource management.

There is a strong similarity between I / O management systems in Windows and resource management systems in BIG. BIG resource managers, like Windows I / O managers, provide a common API, common logic for resource access control, common resource tracking, and a common mechanism for requests through various sets of providers. BIG resource providers, like Windows device drivers, extend the management system with special knowledge for controlling separate classes of resources. BIG resource managers, like Windows I / O managers, provide a model for integrating various resources under a common umbrella.

Automated Resource Management and Optimization

The BIG Resource Manager eliminates the need for data center operators to be directly involved in allocating and deploying components for resources. For example, when a new service is installed on a BIG computer, operators do not have to decide which computer will deploy that service. Operators only need to assign a resource quota to the service, and then the resource manager can choose how best to deploy the service within the BIG computer to conserve limited shared resources such as core network bandwidth. Decide

The base set of trusted resource providers is involved with the resource manager in optimizing component placement. Resource providers are involved in deployment optimization by providing placement managers with placement choices and provider-specific relative cost preferences. The resource manager then balances overall considerations with each resource provider's local considerations to maximize efficiency and minimize resource use.

Optimal component placement is an ongoing consideration. Over time, the resources required by individual services may shrink or grow. Available physical resources change as new devices are added to the BIG computer and old devices are released. The resource manager periodically re-examines deployment decisions to evaluate the benefits of moving components. Resource providers are involved in reassessing deployments by providing the resource manager with the transfer cost of the component. The cost of movement will be enormous for non-removable storage, but very small for non-member IIS components.

The BIG resource manager frees operators from worrying about resource allocation or component placement. Resource managers also eliminate the need for developers to record complex allocation logic, and instead they simply provide the resource manager with a graph of resource requirements. The resource manager optimally deploys components within the BIG computer, taking into account both logical and global resource requirements.

Feature Description

Execution environment

The BIG resource manager runs as a CLR managed service backed by highly available SQL. Each BIG machine is expected to have only a single resource manager replicated through a pair of SQL servers in the HA SQL cluster.

BIG resource providers run within the BIG resource manager process. Resource managers provide resource providers with an asynchronous execution environment that can be manipulated and a shared database that stores their state. By using the BIG behavioral logic model, it is expected that all resource providers will be CLR managed code.

All resource providers maintain their status in the resource manager database. Resource providers can create their own tables as needed to satisfy their management requirements.

 The status of resource providers in the resource manager database is coercive. Thus, for example, the IIS metabase is a cache of data in the resource manager database. If an IIS VRoot entry is found in the IIS metabase without a corresponding entry in the resource manager database, the VRoot in the metabase is removed.

All resource allocation and reallocation requests are consolidated within transactions. Resource providers use the resource manager database exclusively to run exclusively within the resource manager process. Even aggregate cross-provider requests execute in a deterministic, non-distributive manner. This simplifies the design and execution of resource providers and ensures that resources are never lost between servers in failure scenarios.

The BIG resource manager separates resource allocation and resource initialization into two separate actions. Resource allocation is a non-distributed, deterministic operator and runs exclusively within the resource manager process. Resource initialization, on the other hand, is inherently distributed and nondeterministic.

Resource allocation is primarily initiated by a depth-first operations logic phase in which components are demonstrated, connected to wires, and attribute to resource requirements as needed.

By separating component demonstrations and resource allocations from resource initialization, BIG runtimes and services can not use resources because they have not been initialized, or the device on which they reside has evaporated and cannot use them. However, common error-handling mechanisms can be used. Resource initialization will mainly be driven by a state machine, which stores state in HA SQL storage, such as a resource manager database or an SDM database.

Resource providers

The BIG Resource Manager owns all the resources in the BIG computer. Through resource-specific resource providers, the resource manager extends to knowledge specific to resources of a separate class. The resource manager provides the storage device with management of collective resource operations and acts as a host for resource providers.

The BIG Resource Manager provides a small, specific set of resources through a limited number of resource providers. It is expected that a basic set of resource providers (which are small in number) will cover most, if not all, of the target customers. The following resource providers are expected in the first product release.

Physical resource provider (raw devices)

Network Resource Providers (VLANs)

External resource providers (DNS names, external IP addresses)

IP Load Balancing Group Resource Provider

IIS VRoot Resource Provider

SQL DB Resource Provider

CLR AppDomain Resource Provider

ㆍ "Win32 Surface" resource provider (Win32 program)

Generation pattern

Resource management will primarily be driven by operational logic packaged as CLR managed code executed. The operation logic will be written in a "disembodied object" pattern in which the CLR managed object represents the target component. The dismantled object is responsible for allocating logical or physical resources required by the component, initializing those resources, and ultimately decomposing and freeing those resources when the component is no longer needed.

FrontEnd f = new FrontEnd (); // Instantiate the disembodied object.

Such a call only creates a decomposed object, that is, a CLR class with a record of component instances in the runtime database. The operation logic works with "FrontEnd f" to set parameters such as scaling requirements and the like.

The dismantled object, i. E. "FrontEnd f" in this example, participates in any resource allocation by responding to a request for a graph of desired resources and subsequent setting of resources.

r = f.GetResourceGraph (); // Ask f to produce the logical resource request graph (recursively if f is compound).

rgo = BigAllocateResources (rgi); // Ask the Resource Manager to do the global allocation request.

f.SetResources (rgo); // Notify f of the actual resources allocated (recursively if f is compound).

A deconstructed object dictates all object initialization, such as formatting the disk and saving the image.

f.BeginConstruct (); // Kick off the construction / initialization state machines.

f.EndConstruct (); // Get results when construction has finished (this is just the .NET async pattern).

Also, the lifetime of a dismantled object goes beyond the life of the object with the dismantled object indicating destruction. The previous statement does not prohibit object quiescence.

f.BeginDestruct (); // Kick off the destruction state machines.

f.EndDesctruct (); // Get results when destruction has finished.

Deconstructed objects also release their resources.

f.ReleaseResources ();

After that, the resources can be destroyed.

f = null;

There are some things worthless. Since "f" is only a decommissioned object, and resource allocation is separate from resource initialization / construction, the following lines can all be placed in a single deterministic transaction. Assuming that the RM DB is in the same SQL as the SDM DB, the transaction may be a non-distributed transaction.

BeginTransaction ();

FrontEnd f = new FrontEnd;

r = f.GetResourceGraph (); // Ask f to produce the logical resource request graph

rgo = BigAllocateResources (rgi); // Ask the Resource Manager to do the global allocation request.

f.SetResources (rgo); // Notify f of the actual resources allocated.

EndTransaction ();

At some point all resource providers will invoke distributed operations, but not during the "BigAllocateResources ()" call. By executing a given resource provider, it is possible to leverage distributed code through the SDM modeling service.

Batch optimization

First, in the context of this discussion, we define the following terms for batch optimization.

I. Local Optimization: Optimization is limited to a single component factory, ignoring the impact on deployment within other component factories.

II. Collective Optimization: Optimize for multiple component factories. For example, consider the deployment of IIS applications and SQL databases.

III. Global Optimization: Optimizes all applications in the entire system, including the movement of existing components, ie BIG computers. Global optimization differs from collective optimization in that it considers the movement of existing components.

Meanwhile, the following points should be understood.

I. BIG V1 must provide a collective allocation API. The collective allocation API takes into account a set of wire instances and components with configuration parameters for the component, and wire instances in the SAM. In a single transaction, the collective allocation API calls component factories to conserve the necessary resources. [NOTE: The term "aggregate" is used instead of "batch" to emphasize the fact that assignments can include other component factories. Note that in this respect the term "aggregated optimized allocation API" is not used.]

II. In the end, BIG must provide global placement optimization. The goal of overall placement optimization is to rebalance the placement of component instances within a BIG machine to optimize certain features, and the main feature is to use shared resources of the BIG machine.

III. Collective batch optimization may occur at initial allocation or may take the form of global optimization later with controlled application consent. The easiest time to affect placement is when the component instance is initially allocated.

IV. Moving components after initial deployment is very expensive and even expensive. Moving a large SQL backend is very expensive and can seriously compromise application availability. When moving components, consider the needs of the application.

V. For long-running applications, moving components will be inevitable without overall deployment optimization. The hardware may suddenly break. The hardware will obviously be dismantled due to normal depreciation and life-cycle constraints. Thus, any application that runs for a long time will eventually need some mechanism to move the components. Whether these mechanisms are leveraged by global placement optimization depends on their existence.

VI. Long running applications will support some form of migration for upgrades. For example, the mechanism for upgrading will be leveraged by global placement optimization. For example, if the application upgrade policy is to bring a new front end online and dismantle the old one, then allocating a new front end is the best time to optimize deployment. Upgrades provide an opportunity for global deployment optimization.

From the above description, the following can be proposed for BIG V1.

1) BIG V1 provides a batch allocation API. The batch API takes into account a set of wire instances and components with configuration parameters for the component, and wire instances in the SAM. In a single transaction, the deployment API calls component factories to conserve the necessary resources.

2) BIG V1 formats the movement of components. BIG V1 can get off-line components, including at least standard component interfaces, and can also take those components to another location. Imagine a component equivalent to "Iserialize". This formalization will use the operation to perform the upgrade and clone the entire front end. It will also be used to partition the SQL backend. It will also be used to disassemble the hardware. Here, you should have the concept of a mobile component, what it means to move other types of components, how to evaluate costs, and so on.

3) BIG V1 provides a collective batch optimizer. The complexity of the optimizer is adjusted to meet the needs of the development cycle. The optimizer can be a crude cluster optimizer or a more sophisticated optimizer.

4) Collective batch optimizer is used by batch allocation API during initial placement. Component factories work with the deployment optimizer to help with those decisions.

5) During the lifetime of the application, the collective batch optimizer can be called periodically to perform global batch optimization by moving component instances. The optimizer can leverage the area of opportunity naturally presented by the application. The optimizer can also ask the application to consider moving components at different times. Basically, global optimization leverages the collective placement optimizer and existing support for mobile components.

6) The BIG V1 IIS application component factory runs mobile components depending on whether the application is allowed. Many of the benefits of global batch optimization will be realized by moving VRoots around, ignoring heavy components such as SQL databases. IIS also naturally supports operations such as drains that facilitate the movement of VRoots. In fact, the IIS VRoot component factor will be the V1 poster child for global placement optimization and component migration.

Modeling of Physical Resources

Underneath the entire resource management system is a hardware resource graph. The hardware resource graph describes the connectivity of the hardware resources available to the BIG Resource Manager and the totality of the hardware resources. Hardware resource graphs include servers, network devices, and network topologies. In addition, the hardware resource graph may include information regarding a power grid and a physical inclusion relationship.

The hardware resource graph consists of three basic elements: an entity, a connector, and a connection.

An entity is a basic unit of hardware accessible by software. Examples of entities include servers, disk drivers, network devices, and the like.

A connector is a physical interface to an entity. A connector is always associated with exactly one entity. Examples of connectors include network interfaces, IDE interfaces, AC power connectors and physical containment.

A connection is exactly a physical connection between two connectors. Examples of connections include network cables, IDE cables, AC cables, and the like.

All three element types, entities, connectors, and connections have associated properties. A property is a tuple of property names, maximum values, and available values.

All three element types may have a dual. Dual is a peer used for fail over. The element and its dual are always assigned together, providing the redundancy required for high availability. Typical dual examples include failover switches on redundant networks, redundant NICs, and cables connecting redundant NICs to redundant switches.

Every connector has cardinality that specifies the maximum number of connections allowed per connector. For example, an IDE connector has a cardinality of two, one master and one slave device. See FIG. 62.

Principles of defining the basic types:

What is the basic hardware protocol?

At the hardware level, what language does the device speak?

The basic entity has exactly one owner.

■ Connectors and connection categories must match.

Dual is a failover pair that must be assigned as one.

An entity, connector or connection can be dual.

What is a modeling element?

Entity

Connector Src = entity

Connection Src = Connector, Dst = Connector

What is the basic category?

Entity category:

X86 PC: Describes software / CPU / RAM interaction. CPU and RAM are values.

EFI PC: Describes software / CPU / RAM interaction. CPU and RAM are values.

■ Network device. Say IP + SNMP. The product identifier is a value.

■ Disk. Send and receive sectors.

Physical Container.

Connector / connection category:

■ Ethernet. Bandwidth is the value.

■ ATA. Bandwidth and format are values.

SCSI. Bandwidth and format are values.

Power

■ Physical (included).

Others: FiberChannel, Serial, Parallel, USB, FireWire, 802.11, Infiniband

Initial Physical Configuration—See FIG. 63.

Detailed example-see FIGS. 64 and 65.

Location-Based Device Identifiers

Every networked device has a unique identifier for its location in the network.

At each level, the value = port number on the parent switch.

The terminated level has a termination value, "#".

See, eg, FIG. 66.

Calculate the path between two devices

Consider two devices (2,0,1) and (2,1, #).

For each device, calculate the terminated prefix:

(2,0,1)-> (#, #, #), (2, #, #), (2,0, #)

(2,1, #)-> (#, #, #), (2, #, #)

The most specific common terminated prefix is a common parent.

(2,#,#)

The remaining terminated prefix is the name intermediate switch.

(2,0,1)-> (2,0, #)

(2,1, #)-> none.

Final path:

(2,0,1) to (2,1, #)-> (2,0, #), (2, #, #) = two switch hops = three wire hops ).

Also, finding the closest peer to a device is simple:

(2,0,1)-> (2,0 ,?)

(2,1, #)-> (2,?, #)

See FIG. 67.

Model Resource Requests

The BIG resource manager models the BIG machine as a graph of nodes (resources) and edges (relationships). Both nodes and edges can be annotated with attributes (name-value pairs).

One of the most common types of queries for resource graphs is sub-graph isomorphism. The client creates a request graph and requests the resource manager to search for a subgraph in the hardware resource graph with the same shape and characteristics. The resource manager searches for a match and returns a fully commented response graph.

As part of the subgraph isomorphism, the resource manager should not overlap or combine graph nodes. In other words, if the request graph includes two PC nodes, then the response graph should include two PC-specific nodes.

The request graph may include a search parameter, such as searching for a PC node or searching for a PC node with at least 256 MB RAM. The response graph includes the specific id of each matching element (node and edge).

In the basic case, the request graph is read-only queries. However, common optimization allows read-write operations in the form of resource allocation. When drawn on the ground, the write operation is labeled with parentheses.

FIG. 68 is a request graph for allocating attached disks and PCs connected via storage transport such as IDE or SCSI. Note that the nodes are indicated by rounded rectangles and the edges are indicated by dark lines with overlapping rectangles with attributes specified. Successful assignment will result in the response graph of FIG. 69.

Driving Scenario

Joe Florist makes the resource needs shown in FIG. MSN guarantees that Joe gets at least a 500MHz PC because he has a "gold" SLA, and that his PC is attached to Switch5 to maintain locality. In addition to that shown in FIG. 71, Exodus assures that MSN always gets a Rack17 machine and also a small disk, because they have a "2 ^nd " class storage SLA. See FIG. 72.

Implementation ideas

class Graph;

class Client

{

    private IResourceMediator mediators [];

    private Object mediatorStates [];

}

interface IResourceMediator

{

    public void MediateRequest (ref Graph graph, ref Object state);

    public void MediateReply (ref Graph graph, ref Object state);

}

class ResourceManager

{

    public Graph Allocate (Graph request, Client client)

    {

        for (int n = 0; n <client.mediators.Length; n ++)

        {

                    client.mediators [n] .MediateRequest (ref request, ref client.mediatorStates [n]);

        }

        Graph reply = PrimitveAllocate (request);

        for (int n = client.mediators.Length-1; n> = 0; n--)

        {

            client.mediators [n] .MediateReply (ref reply, ref client.mediatorStates [n]);

        }

        return reply;

    }

    private Graph PrimitiveAllocate (Graph request);

}

Basic resource allocation scenario

This section lists a number of scenarios. With each scenario, the corresponding demand graph is included. Nodes to be allocated as a result of a query transaction are labeled "[Allocate]". Nodes that are not allocated and should not be allocated for searching for a match are labeled "[Free]". Nodes without parenthesized labels are not assigned, but instead provide a context for the rest of the request graph.

PC

Akamai needs to allocate servers in the Digix data center with at least 1GHz CPU, 512MB RAM and 100GB local disk storage. See FIG. 73.

VLAN

MSN Instance Messaging has decided to implement a DMZ that includes a front-end. To do this, it needs 2 VLANs with front-end coverage. See FIG. 74.

Public IP Address or DNS Name

Joe's web service needs to make itself visible to the outside world. He needs to assign DNS entries and routable IP addresses. See FIG. 75.

Load Balancing Group

Joe's web service is too big for a single PC. He needs to assign load balancing groups and other PCs. Then he needs to place the PCs behind the load balanced group's virtual IP address. See FIG. 76.

Path

Hotmail needs an 80 Mbps route to deliver an email account from one UStore to another. Hotmail can also specify QOS requirements and latency for the route. See FIG. 77.

Specific storage devices

Hotmail wants to create a new UStore. It wants a Raid 1 box with 100GB unfolded in at least four sets of unshared heads spinning above 10,000 RPM. See FIG. 78.

Cluster storage device

Hotmail wants to allocate a pair of machines with shared disks for failover clusters. It wants a Raid 1 box with 100GB unfolded in at least four sets of unshared heads spinning at over 10,000 RPM. See FIG. 79.

Shared storage

Joe's web services require 50GB of common storage available by multiple machines to maintain a rollback image of a service-specific configuration. This storage device is available from 0 to N machines. See FIG. 80.

Allocation Placement Scenario

Proximal Machine Allocation

Hotmail needs to assign a new front-end. It wants to search for machines on the same switch as other front-ends with enough bandwidth for the back-end cluster. See FIG. 81.

Remote machine allocation

Expedia's personal database of information requires another machine for SQL replication. It is located in a part of the data center covered by different battery backup units. See FIG. 82. Or or the example of FIG. 83.

Latency Driven Allocation

The hotmail back-end needs to allocate a machine for cluster coordination. The machine must be within the 5ms delay of a machine already in the cluster, but the bandwidth is low. Optionally, this can be indicated by requiring the machine to be within one network hop. See FIG. 84.

Seeding composite components

Hotmail attempts to create a new email unit. The unit must be allocated to a single hop cluster with room to grow to at least 500 PCs, but Hotmail can only initially allocate dozens of machines. See FIG. 85.

Batch Allocation

MSN Search decides to add the ability to search for MP3s based on small music samples. It wants to allocate 400 PC blocks, load balancer and 20TB storage. It wants all-or-nothing allocation if not all. See FIG. 86.

Revocation Scenario

Recovery

Joe's web service stopped paying IDC. IDC needs to recover all resources assigned to Joe's Web service and return them to the pool of available resources.

Hardware Lifetime Revocation

One of Expedia's front-ends is a PC that has reached the end of its life cycle. When triggered by IDC operation logic, the resource manager notifies Expedia that it had 72 hours before the machine returned to IDC.

Controlled revocation

Hotmail has allocated 20 short-term machines for the massive store resilient of UStore. According to its SLA, IDC now requests that one machine be returned. Hotmail can return another equivalent machine or one of twenty.

BIG Vision-Enable

Develop distributed, scalable, and highly available services using reusable building blocks such as Visual Studio and SQL, IIS, ...

Deployment across a set of abstracted hardware and software that is automatically assigned, purposed, and configured

Low cost of ownership through automation by coding operational best practices to control service availability and growth

Procurement of standardized data center hardware leveraging commodity economics

BIG Service Platform Architecture-see FIG.

BIG Computers-Hardware Reference Platform

Reduces the cost of design, test and operation:

Limit the number of hardware devices to support

Limit network topology

Enable automation of network configuration

Eliminate customer concerns about BIG technology deployment requirements

PXE, DHCP, DNS, VLAN

IP gateway

Coordinate IP traffic between external and internal networks

Network Address Translation (NAT), Firewall, Load Balancing

Internal network

IP addresses and VLANs are managed exclusively by the BIG

VLAN is automatically configured

Hardware building blocks

■ Combination of item server, network switch, and disk.

See FIG. 88.

89 illustrates an example of a current product that may be inside a BIG computer.

Resource Management Features

Dynamic discovery of server, storage or network hardware resources.

High availability database containing (physical and logical) resources.

Runtime APIs that support enumeration, querying, and updating of resources.

Logical resource driver models and APIs for binding resource drivers to physical hardware devices.

Programmatic allocation and deallocation of server resources.

● Automatic configuration and management of network resources such as VLANs and load balancing groups.

Dynamic configuration and management of block and file-based storage resources.

Fault detection monitoring and notification.

Resource Management Component

The resource manager is responsible for allocating hardware and software resources within the BIG computer.

Resource manager registers with BIG runtime

A resource manager is essentially a factory for a given resource type.

Hardware resource manager

Base-level factory responsible for allocating hardware instances

Network Resource Manager

Responsibility to assign VLANs, load balancing groups, IP addresses ...

Storage Resource Manager

■ Manage storage resources such as disks and files

PC resource manager

Use iBIG services to allocate target servers and deploy OS

● Software Resource Manager

Allocate and configure IIS vroots, SQL databases, and ASP.NET

90 illustrates various resource management components.

Hardware resource discovery and management

Characteristics: power, network, storage, processor, memory, location

The hardware in the BIG computer is automatically discovered. Resource drivers are constrained to hardware devices and expose logical resources to a Hardware Resource Manager (HRM). HRM translates logical resource allocation requests into physical resource bindings. See Figures 63, 64 and 65.

Network resource management within BIG computers

BIG computers define abstractions for network resources.

Network Resource Manager: Allocate network resources, program network switches and load balancers within the BIG computer, and interface with network resource drivers.

VLANs provide isolation and partition networks within BIG computers.

Examples of network resources: VLANs, load balancing groups, network filters, IP addresses, DNS names.

BIG Storage Resource Management Requirements

Global view of storage devices connected to BIG computers, including file and block-based storage resources.

Virtualization of the storage interconnect fabric

Framework for creating and managing high-level storage abstractions, such as LUNs, volumes, and arrays.

Drivers / providers that allow existing and new storage devices to plug into BIG computers.

Interoperability with SAN system.

Infrastructure Services {Automated Deployment Services (ADS)}-Features

Base Distribution Service

Basic Network Boot Service (PXE) and Image Builder Service

Pre-boot OS environment (BMonitor)

Virtual floppies delivered over the network for legacy tools support

Image distribution and management

■ Tools for creating, editing and deleting images

■ Deploying an image to a system running pre-OS (pre-OS)

Multiple Device Management (MDM)

Scripts for common tasks

Task sequencing to coordinate multiple steps and processes for deployment

Full programmatic interface (WMI)

Ships 60 days from .NET server RTM

■ Supports Windows 2000 and .NET server targets

92 illustrates an example ADS architecture.

93 shows an example ADS Remote Boot and Imaging system.

Service Definition Model (SDM)

Programmatic description of the whole service

■ declarative definition of the service

Define the overall service structure of the service in a scale-invariant manner

■ Provide a framework for deployment, management and operation

Component-based model captures service elements in a modular fashion

SDML is a descriptive language that defines a service definition model.

Component, port and wire

■ Type, member, and instance space

Support for composition and encapsulation

SDM: components, ports, and wires

A component is a unit of implementation, distribution, and operation.

For example, a dedicated server running .NET servers, IIS virtual Web sites, and SQL databases.

■ Disclose functions through ports and communicate via wires

Compound components created by the organization

Port is a name (service access point) with association type (protocol)

BIG does not mandate which protocol to use for communication

Protocol captures the information required to establish communication

Wires are permissible bindings between ports

Wires declare topology relationships between ports

See FIG. 94.

95 shows an SDML example: MyService.sdml. In addition, FIG. 28 relates to this SDML example.

Service Deployment Unit (SDU)-encapsulates all the pieces that make up a service, including: SDM model for application / service, CLR assembly for component implementation, and MSI, ASP.NET , SQL scripts, static content, and more. See FIG. 96.

SDM runtime

SDM runtime is responsible for tracking SDM models and instances

Implemented as a web service hosted by IIS

Can be partitioned for scalability

Runtime APIs expose SOAP endpoints

■ Communication with runtime is done through runtime library

Highly available SDM Store (using Yukon's redundant database technology)

Two SQL Servers and Witness Server

See FIG. 27.

Example: Component Instantiation

using Microsoft.SDM;

public class MyService:

SDMComponent

{

   public OnCreate (…) {

   fe1 = CreateInstance ("fe", "");

   be1 = CreateInstance ("be", "");

   w1 = CreateWireInstance ("tds");

   w1.Members.Add (fe1.Ports ["catalog"]);

   w1.Members.Add (be1.Ports ["sql"]);

}

}

myservice.cs is C # code that uses the SDM API.

componenttype MyService

{

component MyFrontEnd fe;

component MyBackEnd be;

port http = fe.http;

wire TDS tds {

fe.catalog;

be.sql;

}

implementation "MyService, MyCLRApp"

}

See FIG. 35.

Example of dynamic binding using the SDM runtime APIs (see Figure 97)

1. be [1] uses DeclarePort () to declare that the sql [1] port is ready and registers its port connection information with the SDM runtime.

2. fe [1] initializes and requests the SDM runtime for peer information for port catalog [1] and uses GetPeerPort () to receive information about port sql [1].

3. fe [1] then connects to be [1] using the port connection information dynamically provided by the SDM runtime.

Service Definition Model Workgroup

SDM workgroup consists of 5 teams

Indigo

Whitehorse

Fusion

Management

BIG

A charter is to define a class level application schema for distributed and / or heterogeneous applications.

■ Describe applications using components, ports, and wires

Include distribution, configuration, and management information

SDM is an exoskeleton that references Fusion and Management (and potentially other) schemas

Fusion assemblies are referenced for distribution (where applicable).

MBU Settings and Instrumentation schemas are referenced and specified for configuration and monitoring

SDM schema (simplified)

<sdm>

   <identity /> // identifies the group of definitions

   <porttypes /> // descriptions of ports

   <wiretypes /> // descriptions of topologies

   <componenttypes> // set of components defined in this library

      <componenttype>

         <ports /> // communications capabilities

         <settings /> // configuration settings for component

         <instrumentation /> // monitoring schema

         <deployment /> // installer type, installer info, (e.g., Fusion)

         <components /> // subcomponents for composition

         <wires /> // defines relationships between ports

      </ componentType>

   </ componenttypes>

</ sdm>

SDM and Fusion —see FIG. 98.

Local settings with default values are specified with Fusion Manifest (or other local installation technology).

The configuration of the SDM is handled by the Ops Logic and BIG runtimes.

Example: "Number of users" can be used to determine the initial scale-out condition of an application.

SDM and Deployment-see FIG. 99.

To describe the structure of an application in a scale invariant manner, a similar scale invariant description of the application host environment is required to enable design-time validation of deployment requirements and constraints.

■ Microsoft and its customers spend a lot of energy to produce so many documents to elaborate descriptions of the data center environment and to illustrate the drawings.

These figures and documents merge information from multiple layers from the physical machine name to the Ip address for the VLAN for the server role into one comprehensive view, often confusing.

100 illustrates an example system architecture.

101 illustrates examples of various distribution layers.

Operations logic is the "business logic" of the operation

Operational logic is CLR code that captures an encoded repeatable pattern as the best reusable embodiment

■ Not specific to service or operating environment

Can be developed, tested and shipped

Reduce the need for manual procedures that require people to run it

OpsLogic is responsible for the overall operation of the service

■ Run service

■ Service Growth and Shrinkage

Upgrade and update

Fault detection and recovery

Database partition

OpsLogic will be implemented using MS middle-tier technologies

ASP.NET Web Services Hosted on IIS

DTC for transaction coordination

SQL server for storage

WMI for monitoring and management

MSMQ for messaging

Repeatable Upgrade Pattern-> Behavior Logic

Upgrade is an example of the type of reusable motion logic template that we want to ship with the BIG.

In-place Upgrade Pattern

High cost of moving data, low cost of code instantiation, or no redundant resources

■ Get the component from the service, run the updater, and put it back in the service

Side-by-side Upgrade Pattern

High cost of moving data, low cost of code instance creation, redundant resources

■ create new components; Pull out old components from services; Migrate data to new components; Put the new component into service

Replacement Upgrade Pattern

No data transfer

■ add new components; Remove old components; Adjusted to maintain service availability

Rolling Upgrade is an example of high-level operation logic that can reuse coded upgrade patterns.

Behavioral logic can be tested, framework supports rollback

■ Eliminate human errors from execution by having the software perform the steps

Operational Logic, BIG, and Microsoft Programming Model—See FIG. 102.

The Internet is transforming enterprise applications-increased publicity has increased costs. See FIG. 103. The new architecture increases the cost of HW, humans, and reduces agility by complexity. See FIG. 104. Moore's Law is expanding on DC-a sharp increase in disk density, NW throughput, and processing power

Service delivery is human intensive-including people has a big impact on security, reliability, flexibility and cost. See FIG. 105.

This is a lifespan problem-customer pain spans occur, are distributed and run phases. See FIG. 106. The application is not developed with: scale in mind-tied to HW configuration, manageability in mind, mind behavior-what are my data center requirements? Test-"Thrown over the wall". Developer Desktop-> Test Configuration? How this maps to my production environment. Deployment challenges: What server am I using? What is the correct topology? Have you checked the server, storage and network teams? How much future demand do you need to anticipate? Operational Challenges: What Do I Do With All These Alerts? How does a failed NIC affect my application? Why is my service degrading? I hope to be able to clone my email admin.

Addressing service delivery challenges-core tenant of viable solutions for customers

Independent value at each stage of life

Development, deployment, behavior

Integrate architecture for lifespan

Improved coordination and feedback between steps

Enable mapping to changing business needs

The mapping can only be performed if you have agility

Built on the lowest TCO platform

Effectively leverage industry standard hardware with scale out

Project Summit-A revolutionary service delivery architecture. See FIG. 106. Develop services that are instrumented and manageable, include deployment requirements, encapsulate operations knowledge, and leverage standard building blocks. Easily deploy services: rapid provisioning, DC resource virtualization, self-contained, one-click deploy, consistently test to production, and scale independent. Simplified operation: Aggregated administration, monitoring and change management, non-application management services, true automation through context, rich service-centric management console

The map business needs IT systems. Capture IT operational knowledge with tools.

Project Summit-A comprehensive new architecture and industry wide initiative. See FIG.

Concept-> Architecture-> Products

Long-term, customer- and partner-driven effort

Key investments starting in 1999

Started with a deep re-study on the operational needs of large MS Internet characteristics

Validated initial finding on a wide customer base

Prototype from product group in late 2000

Strong set of joint development partners

Large enterprise and service provider customers included in the product definition

Consulted IHV and ISV partners to help define the publicly available functionality through the API

Initial product shipments to Windows Server 2003

The customer transforms a complex system into a simple diagram. See FIG. 108.

Who is involved in delivering your IT services? People are an integral part of the system.

Application architect-design services.

Network Architect-Configure your network.

Storage Designer-Configure remote storage.

Application operator-maintains the service.

Storage Operator-Maintains remote storage.

Server Operator-Keep the server.

Problems with this model-multiple human interactions, uncommon language, blurring of domain knowledge.

Details of the solution:

Service definition model

Resource virtualization

Motion automation

Management APIs and Solutions

Driving an Industry wide initiative

Service Definition Model (SDM)-Capture complete services.

Overall description of the service

Application component and instrumentation

Service topology

Underlying resources (server, storage, network)

Related to developers and operators

Layer and separate responsibilities

Provide a consistent frame of reference

Opened in Visual Studio for Developers

Living model at run time for the operator

Logically consistent independent of allocated resources

Track resources in real time

Single authority in service composition

Provide a context for true automation

SDM jargon

Components-Building Blocks of Services

Logical construct

Invariant to scale

One component can have multiple instances

Simple or synthetic

Single logical entity (database, web service, file split)

Combined logical entities (HA database, email, etc.)

Contains a deployment manifest specific to the component

DB components contain database schemas

Web service components contain URL directories, content, and code

Interconnected with ports and wires

Port-Service Access Point

Wire-to-port communication relationship

SDM provides a means for abstraction and encapsulation. See FIG. 110.

Enable Reuse

Construct complexity

Mapping People to SDM-Provides a consistent frame of reference. See FIG. 111.

Developing SDM Applications-New Visual Studio Design Surfaces. See FIG. 112. Legacy application, new application.

SDM Service in the Data Center-A holistic description with a living model that tracks resources. See FIG. 113.

What is a Summit Computer?

Agile pool of virtualized hardware resources

Servers, storage devices, network devices, managed fabrics.

Dozens to thousands of servers.

Assembled from an existing HW or ordered as an SKU from an OEM.

Single managed entity

The Summit provides and manages all the HW resources in the Summit computer.

The summit owns the complete configuration of the internal network fabric.

Constrained Areas of Control

Standardized topologies limit the complexity of build, test, and operation.

Unchanged Ownership of Resources Outside the Summit Computer

Catalysts for Software Innovation

Q: What data center environment should I target for my server application?

A: Summit computer.

Like Win3, it allows ISVs to forget about the details of printers and graphics cards.

Catalysts for the Hardware Revolution

Microsoft has contracted with major hardware vendors to define the reference platform.

First Specification & Innovations in WinHEC (May 2003)

Summit provides a SW environment for aggregation innovations.

Dense blades, smart racks, etc.

Summits allow for simplified hardware. For example, allow:

Remove the KVM from the server and the human interface from the network devices.

114 illustrates an example resource manager.

Resource Virtualization-Bridge between SDM and component instances.

Responsibility for sharing, allocation and recovery. See FIG. 115.

Server Resource Virtualization-Automated Deployment Services (ADS) in Windows Server 2003.

Complete infrastructure to quickly target and repurpose Windows Server

Imaging tools for capturing and editing Windows 2000 and Windows Server 2003 images

Secure, remote deployment framework that enables zero touch server builds from bare metal

Framework for Large Server Operations

Stable, reliable, script execution infrastructure

Programmatic Model of Your Windows Data Center

Continuous log of all operational activities

Graphical and programmatic interface

Simple MMC UI for GUI-based Operation

Full functionality exposed through command line tools and / or WMI layer

Key Benefits of ADS

Lower TCO associated with bare metal server builds and script-based operations

Enable zero-touch server builds from bare metal

Secure script-based operation of 1000 servers as easily as 1 server

2. Improve the consistency, security and scalability of your Windows Server data center

Encode the best working example and eliminate human error

Maintain a continuous storage of all operational activities

Centralize secure, script-based operation of your entire Windows data center

Rapidly change server roles in response to changes in workload requirements

3. Leverage your existing server investment

Extend and enhance your existing script-based automation methods

Operational Automation-Core Tenant of Automation

Flexible framework to enable capture and reuse of best-in-class embodiments

Operations Logic

Rich context within the thing to be automated

Events are contextualized by SDM to enable true automation of system management

"What applications will be affected by the die NIC on rack 22's fifth DL380?

Transact-able

Compensation based model allows rollback and undo.

Behavioral logic-a framework for developer and operator automation.

What is the operation logic?

Long live, highly available and durable encoded operating process

Leverage SDM for control and context of summit computer resources

Allows the operator to change the automation level of the system

Benefits for Developers

Allow developers to capture how the system reacts to and resolves application events and messages (such as return code)

Predefined behavioral processes that developers can use or extend

Deploy, upgrade, scale out, and remove resources

Benefits for ITPro or Operators

Enables easy reuse of proven operational best practices for data centers

Motion Automation-Programming Motion Logic. See FIG.

How SDM interacts with behavioral logic:

Events are annotated to indicate instance and component information.

The monitoring subsystem has time-based event correlation

Alerts are rollups of events

Greater semantic meaning

Commandlet (Commandlet),

Set of administrative commands published by a component

Self-describing

Can be used directly within a shell

Can have a GUI form indication

You can provide a "man-page" for use by the operator.

See FIG.

Motion Automation-Transact-Enable

Transactions are important to support fault-tolerant operations

Example: add a web service

Powerful extension to ad-hoc shell scripts

All forms of behavioral logic under the auspices of the transaction model

Reward-based

durability

Using orchestration, a transaction can span multiple machines

Management API and Solutions-Leverage the richness of SDM.

Visualization occurs through SDM

Third party consoles can derive information directly from SDM or leverage the platform know-how of Microsoft management solutions.

Microsoft will build an SDM-based management console for the data center

Customers could create custom consoles via SDM

See FIG.

Industry Scope Initiatives-Unleashing IHV, ISV, and SI innovations.

IHV HW Reference Platform Specification

Work closely with major OEMs and switch manufacturers

Aiming to release from WinHEC (May 03)

Incorporating new mandatory features into future HW offerings

Contracted with major third party ISVs

Create an application component for Visual Studio

Resource manager for applications within SDM

Mgmt ISV to create an SDM-based management console

Work with SI as a customer and partner

customer

Lower operation costs

partner

Create innovative new service subscriptions on this platform

Use operations expertise-> develop operational logic

Key customer benefits: Offer choices for your data center and create the most economical and manageable platform.

Beginning the Industry Range-Extending the Richness of SDM to Heterogeneous Environments. Develop heterogeneous SDM applications using Visual Studio (which enables the development of SDM applications for Windows) or third-party tools (which enable the development of SDM applications for other platforms).

conclusion

Although the invention has been described in language specific to structural features and / or methodological acts, it is to be understood that the invention as defined in the appended claims is not limited by the specific features or acts disclosed. Rather, the specific features and acts are disclosed as example forms of implementing the claimed invention. Moreover, these claims are illustrative in scope and subject matter. Many other combinations and sub-combinations of this feature can be claimed later in a patent application claiming priority for the present application.

Although the description has been described in language specific to structural features and / or methodological acts, it is to be understood that the invention defined in the appended claims is not limited by the specific features or acts disclosed. Rather, the specific features and acts are disclosed as example forms of implementing the invention.

Today, for example, some websites can run thousands of computers, can host many distributed applications, and these distributed applications often allow the operator to manually configure the wiring configuration within IDC to support complex applications. In addition to arranging them, they have a networked complex with the requirements to request connection to some network switches. Under these circumstances, it is possible to provide an improved technique for designing and deploying distributed applications on physical computing systems that can prevent time-consuming processes while producing fewer human errors.

Claims (26)

Facilitating the design of virtual data centers and distributed applications; Logically placing portions of the distributed application onto the virtual data center; And Implementing a physical data center based on the virtual data center Including, The virtual data center is logically located on a layer below each layer, including a plurality of service definition model (SDM) layers, The SDM layer provides a context and namespace for describing APIs and operational processes for application self-inspection and control of application resources. The method of claim 1, When logically deploying portions of the distributed application onto the virtual data center, a view of an operator of the virtual data center is limited to include only portions associated with the deployment of the distributed application. Facilitating the design of virtual data centers and distributed applications; Logically placing portions of the distributed application onto the virtual data center; And Determining whether the placement of parts of the distributed application is valid Including, The virtual data center is logically located on a layer below each layer, including a plurality of service definition model (SDM) layers, The SDM layer provides a context and namespace for describing APIs and operational processes for application self-inspection and control of application resources. The method of claim 3, Allocating resources of the virtual data center to support the distributed application. A computer-readable recording medium having recorded thereon a program for realizing a software architecture on a computer for use in designing, deploying, and managing distributed applications on a distributed computing system. A first software layer for tools used to convert machines into servers used in the distributed computing system; A second software layer for virtual topology generation and network management of the distributed applications, the second software layer being located at the top of the first software layer; A third software layer for maintaining a physical model of the distributed computing system, the third software layer being located on top of the second software layer; A fourth software layer for facilitating the allocation of logical resources requested by the distributed application, the fourth software layer being located on top of the third software layer; A fifth software layer for a service definition model (SDM) that provides a context and namespace for describing APIs and operational processes for application self-inspection and control of application resources; A software layer is located on top of the fourth software layer; Sixth software layer for defining reusable building blocks of a distributed application that uses the API provided by the SDM for context, naming, and binding-the sixth software A layer is located above the fifth software layer; And A seventh software layer for operation management of the distributed application, wherein the seventh software layer is located at the top of the sixth software layer A computer-readable recording medium having recorded thereon a program for realizing a software architecture comprising a computer. A service definition model (SDM) that enables abstract descriptions of distributed computing systems and distributed applications, and Schema for dictating how functional operations should be specified in the service definition model Including; And said functional operations record a program for realizing a design tool on a computer comprising design of distributed applications, deployment of distributed applications, and management of distributed applications. Hosting an implementation of a distributed system built using a service definition model (SDM); Exposing established APIs for manipulating the SDM type; And Tracking SDM instances for deployment and management of distributed applications How to include. A method of facilitating the design of a scale-invariant virtual data center representing a physical data center, Describing the physical data center according to a service definition model, wherein the service definition model comprises: Services related to the design of distributed applications; Services related to the distribution of distributed applications; And Contains services related to the management of distributed applications Determining a number of instances to be created for a particular logical component of the physical data center; And Determining a wiring topology to implement the physical data center How to include. delete One or more computer-readable recording media storing a plurality of instructions, wherein the instructions, when executed by one or more processors, cause the one or more processors to: Facilitate the design of virtual data centers and distributed applications, Logically deploy portions of the distributed application onto the virtual data center, Implement a physical data center based on the virtual data center, The virtual data center is logically located on a layer below each layer, including a plurality of service definition model (SDM) layers, The SDM layer is a computer readable recording medium for an SDM that provides a context and a namespace for describing APIs and operational processes for application self-inspection and control of application resources. Means for facilitating the design of virtual data centers and distributed applications; Means for logically placing portions of the distributed application onto the virtual data center; And Means for implementing a physical data center based on the virtual data center Including, The virtual data center is logically located on a layer below each layer, including a plurality of service definition model (SDM) layers, The SDM layer is an apparatus for SDM that provides a context and namespace for describing APIs and operational processes for application self-inspection and control of application resources. One or more processors, One or more computer readable media having instructions executable by the one or more processors Including, The instructions are A first application to facilitate the design of virtual data centers and distributed applications, A second application for logically deploying portions of the distributed application onto the virtual data center; A third application for implementing a physical data center based on the virtual data center Implement The virtual data center is logically located on a layer below each layer, including a plurality of service definition model (SDM) layers, The SDM layer is an apparatus for SDM that provides a context and namespace for describing APIs and operational processes for application self-inspection and control of application resources. One or more computer-readable recording media storing a plurality of instructions, wherein the instructions, when executed by one or more processors, cause the one or more processors to: Facilitate the design of virtual data centers and distributed applications, Logically deploy portions of the distributed application onto the virtual data center, Determine whether the placement of parts of the distributed application is valid, The virtual data center is logically located on a layer below each layer, including a plurality of service definition model (SDM) layers, The SDM layer is a computer readable recording medium for an SDM that provides a context and a namespace for describing APIs and operational processes for application self-inspection and control of application resources. A first application for facilitating the design of virtual data centers and distributed applications; A second application for logically placing portions of the distributed application onto the virtual data center; And A third application for determining whether placement of portions of the distributed application is valid Including, The virtual data center is logically located on a layer below each layer, including a plurality of service definition model (SDM) layers, The SDM layer is for an SDM that provides a context and namespace for describing APIs and operational processes for application self-inspection and control of application resources. Providing a first software layer for tools used to convert machines into servers used in a distributed computing system; Providing a second software layer for virtual topology generation and network management of distributed applications, the second software layer being located on top of the first software layer; Providing a third software layer for maintaining a physical model of the distributed computing system, the third software layer being located at the top of the second software layer; Providing a fourth software layer to facilitate allocation of logical resources requested by the distributed application, the fourth software layer being located at the top of the third software layer; Providing a fifth software layer for a service definition model (SDM) that provides a context and namespace for describing APIs and operational processes for application self-monitoring and control of application resources. 4 located at the top of the software layer-; Providing a sixth software layer for defining reusable building blocks of a distributed application utilizing the API provided by the SDM for context, naming, and binding, the sixth software layer being the fifth software Located at the top of the hierarchy-; And A seventh software layer for operation management of the distributed application, wherein the seventh software layer is located at the top of the sixth software layer Providing a method. delete delete delete delete delete delete delete delete delete delete delete

Images