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

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

Info

Publication number
KR101044173B1
KR101044173B1 KR20040015346A KR20040015346A KR101044173B1 KR 101044173 B1 KR101044173 B1 KR 101044173B1 KR 20040015346 A KR20040015346 A KR 20040015346A KR 20040015346 A KR20040015346 A KR 20040015346A KR 101044173 B1 KR101044173 B1 KR 101044173B1
Authority
KR
South Korea
Prior art keywords
gt
lt
xs
sdm
layer
Prior art date
Application number
KR20040015346A
Other languages
Korean (ko)
Other versions
KR20040079337A (en
Inventor
케빈 그레리시
데이비드 노블
틸다 브라운
제프리 아드레드
로버트브이. 웰랜드
샬리에디. 챠세
바삼 타바라
알렉산더 토론
글렌알. 피터슨
갈렌씨 헌트
히드리에아머
Original Assignee
마이크로소프트 코포레이션
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority to US60/452,736 priority Critical
Priority to US10/789,440 priority
Application filed by 마이크로소프트 코포레이션 filed Critical 마이크로소프트 코포레이션
Priority to KR20040015346A priority patent/KR101044173B1/en
Publication of KR20040079337A publication Critical patent/KR20040079337A/en
Application granted granted Critical
Publication of KR101044173B1 publication Critical patent/KR101044173B1/en

Links

Images

Abstract

설계 도구는 분산형 컴퓨팅 시스템 및 분산형 애플리케이션의 추상화 기술을 가능하게 하는 서비스 정의 모델을 포함한다. Design tools include a service definition model to enable abstract description of distributed computing systems and distributed applications. 설계 도구는 또한 서비스 정의 모델 내에서 어떻게 기능적 동작들이 지정되어야 하는지를 지시하기 위한 스키마를 포함한다. Design tool also includes a schema to indicate whether they should specify how functional operations within the service definition model. 기능적 동작은 분산형 애플리케이션의 설계, 분산형 애플리케이션의 배포, 분산형 애플리케이션의 관리를 포함한다. Functional operations include the management of the distribution, distributed application design, distributed applications in a distributed application.
Figure R1020040015346
설계 도구, 분산형 애플리케이션, 추상화 기술, 서비스 정의 모델 Design tools, distributed applications, abstraction technology, service definition model

Description

분산형 컴퓨팅 시스템상에서 분산형 애플리케이션들을 설계, 배포 및 관리하기 위한 방법 및 장치, 자원 관리자 및 컴퓨터 판독가능 기록 매체{ARCHITECTURE FOR DISTRIBUTED COMPUTING SYSTEM AND AUTOMATED DESIGN, DEPLOYMENT, AND MANAGEMENT OF DISTRIBUTED APPLICATIONS} Distributed computing design of a distributed application on a system, and method for deployment and management apparatus, and a resource manager providing medium {ARCHITECTURE FOR DISTRIBUTED COMPUTING SYSTEM AND AUTOMATED DESIGN, DEPLOYMENT, AND MANAGEMENT OF DISTRIBUTED APPLICATIONS}

도 1은 인터넷 데이터 센터의 일예를 나타내는 도면. 1 is a view showing one example of the Internet data center.

도 2는 서비스의 일예를 나타내는 도면. Figure 2 is a diagram illustrating an example of a service.

도 3 내지 8은 계층 추상화(layer abstractions)의 예를 나타내는 도면. Figures 3 to 8 is a view showing an example of a hierarchical abstraction (layer abstractions).

도 9 내지 10은 SDM 형 스페이스(SDM type space)의 일예를 나타내는 도면. 9 to 10 are views showing an example of SDM-shaped space (SDM type space).

도 11 내지 15는 계층 추상화의 예를 나타내는 도면. 11 to 15 is a view showing an example of the hierarchical abstraction.

도 16은 프로세스의 예를 나타내는 도면. Figure 16 is a view showing an example of the process.

도 17 내지 19는 여기서 논의되는 컴포넌트들의 예를 나타내는 도면. 17 to 19 is a view showing an example of the components discussed herein.

도 20 내지 21은 그래픽 사용자 인터페이스(graphical user interface)의 일예를 나타내는 도면. 20 to 21 are views showing an example of a GUI (graphical user interface).

도 22는 SDM 모델의 일예를 나타내는 도면. 22 is a view showing an example of SDM model.

도 23은 배포의 일예를 나타내는 도면. 23 is a view showing an example of distribution.

도 24는 유형들의 예를 나타내는 도면. 24 is a view showing an example of the type.

도 25는 인스턴스 요청들(instance requests)의 예를 나타내는 도면. Figure 25 is a view showing an example of the request instance (instance requests).

도 26은 제약의 유효성 재검증(revalidation of constraints)의 예를 나타내 는 도면. 26 is a diagram which represents an example of the effectiveness revalidation (revalidation of constraints) of the pharmaceutical.

도 27은 SDM 런타임(SDM runtime)의 논리 아키텍처의 일예를 나타내는 도면. 27 is a view showing an example of a logical architecture of the SDM runtime (SDM runtime).

도 28은 서비스의 그래픽 표현의 일예를 나타내는 도면. 28 is a view illustrating an example of a graphical representation of the services.

도 29는 인스턴스 스페이스의 일예를 나타내는 도면. 29 is a view showing an example of the instance space.

도 30은 데이터를 SDU로 포장하는 일예를 나타내는 도면. 30 is a view showing an example for packing the data to the SDU.

도 31은 유형 스페이스, 멤버 스페이스, 및 인스턴스 스페이스의 일예를 나타내는 도면. 31 is a view showing a type of space, an example of the member space, and the instance space.

도 32는 멤버 트리의 일예를 나타내는 도면. 32 is a view showing an example of the tree members.

도 33은 인스턴스 트리의 일예를 나타내는 도면. 33 is a view showing an example of an instance tree.

도 34는 여기서 설명되는 시스템을 구현한 일예를 나타내는 도면. 34 is a diagram illustrating an example implementation of the system described herein.

도 35는 컴포넌트 인스턴스(component instances)의 생성을 추적하는 일예를 나타내는 도면. 35 is a view showing an example of tracking the production of component instance (component instances).

도 36 내지 39는 컴포넌트 인스턴스 이벤트의 예를 나타내는 도면. 36 to 39 is a view showing an example of component instance events.

도 40은 분할된 런타임의 일예를 나타내는 도면. 40 is a view showing an example of the divided run-time.

도 41은 멤버 스페이스의 일예를 나타내는 도면. 41 is a view showing an example of the member space.

도 42는 인스턴스 계층의 일예를 나타내는 도면. 42 is a view showing an example of the instance hierarchy.

도 43은 인스턴스 스페이스를 분할하는 일예를 나타내는 도면. 43 is a view showing an example of dividing the instance space.

도 44는 다양한 컴포넌트들 간의 관계의 예를 나타내는 도면. 44 is a view showing an example of the relationship between the various components.

도 45는 고정 아이덴티티 신뢰 관계(fixed identity trust relationship)의 일예를 나타내는 도면. 45 is a view showing an example of a fixed identity trust relationship (fixed identity trust relationship).

도 46 내지 47은 컴포넌트들의 배열의 일예를 나타내는 도면. 46 to 47 shows an example of the arrangement of the components.

도 48은 플랫폼 아키텍처의 일예를 나타내는 도면. 48 is a view illustrating an example of a platform architecture.

도 49는 애플리케이션 배포를 위한 사용 흐름(usage flow)의 예를 나타내는 도면. 49 is a view showing an example of using the flow (usage flow) for application deployment.

도 50은 애플리케이션 설정 및 호스트 설정의 예를 나타내는 도면. 50 is a view showing an example of an application set, and host configuration.

도 51은 배포 도구에 대한 국면(phases)의 예를 나타내는 도면. 51 is a diagram showing an example of a phase (phases) of the deployment tool.

도 52는 데이터 센터 기술의 시각화의 일예를 나타내는 도면. 52 is a view showing an example of the data center technology, the visualization.

도 53 내지 54는 흐름도의 예를 나타내는 도면. 53 to 54 is a view showing an example of a flow chart.

도 55는 SDU를 처리하는 일예를 나타내는 도면. 55 is a view showing an example of processing the SDU.

도 56 내지 58은 흐름도의 예를 나타내는 도면. 56 to 58 are views showing an example of a flow chart.

도 59는 모델 아키텍처의 일예를 나타내는 도면. 59 is a view showing an example of the model architecture.

도 60은 관리의 계층들(layers of management)의 예를 나타내는 도면. 60 is a view showing an example of the management of the layer (layers of management).

도 61은 시스템의 동작의 일예를 나타내는 도면. 61 is a view showing an example of the system operation.

도 62는 커넥터 배열의 일예를 나타내는 도면. 62 is a view showing an example of a connector arrangement.

도 63 내지 67은 디바이스들의 물리적 구성의 일예를 나타내는 도면. 63 to 67 are views showing an example of a physical configuration of the devices.

도 68은 요청 그래프(request graph)의 일예를 나타내는 도면. 68 is a view showing an example of a graph request (request graph).

도 69는 응답 그래프의 일예를 나타내는 도면. 69 is a view showing an example of a response graph.

도 70 내지 86은 본 발명이 사용될 수 있는 시나리오의 예를 나타내는 도면. Figure 70 to 86 is a view showing an example of a scenario that can be used by the present invention.

도 87은 서비스 플랫폼 아키텍처의 일예를 나타내는 도면. 87 is a view showing an example of a service platform architecture.

도 88은 시스템에서의 컴포넌트들의 예를 나타내는 도면. 88 is a view showing an example of the components in the system.

도 89는 여기서 설명된 시스템에 포함될 수 있는 제품들의 예를 나타내는 도면. 89 is a view showing an example of products that may be included in the systems described herein.

도 90은 다양한 자원 관리 컴포넌트들을 나타내는 도면. 90 is a diagram showing a variety of resource management component.

도 91은 다수의 LAN들의 배열의 일예를 나타내는 도면. 91 is a view showing an example of arrangement of a plurality of LAN.

도 92는 ADS 아키텍처의 일예를 나타내는 도면. 92 is a view showing an example of the ADS architecture.

도 93은 ADS 원격 부트 및 이미징 시스템(ADS remote boot and imaging system)의 일예를 나타내는 도면. 93 is a view showing an example of ADS remote boot, and the imaging system (ADS remote boot and imaging system).

도 94는 토폴로지 배열의 일예를 나타내는 도면. 94 is a view showing an example of the array topology.

도 95는 SDML의 일예를 나타내는 도면. 95 is a view showing an example of SDML.

도 96은 SDU에서의 데이터 집합의 일예를 나타내는 도면. 96 is a view showing an example of data set in the SDU.

도 97은 SDM 실행 시간 API들을 사용하는 동적 바인딩(dynamic binding)의 일예를 나타내는 도면. 97 is a view showing an example of dynamic binding (dynamic binding) using the SDM runtime API.

도 98은 SDM 배열의 일예를 나타내는 도면. 98 is a view showing an example of SDM array.

도 99는 배포의 일예를 나타내는 도면. 99 is a view showing an example of distribution.

도 100은 시스템 아키텍처의 일예를 나타내는 도면. Figure 100 is a view illustrating an example of a system architecture.

도 101은 다양한 배포 계층들의 일예를 나타내는 도면. Figure 101 is a view showing an example of the various distribution tier.

도 102는 동작 논리의 예를 나타내는 도면. 102 is a view showing an example of operation logic.

도 103 내지 105는 인터넷으로 인한 변화의 예를 나타내는 도면. 103 to 105 is a view showing an example of change due to the Internet.

도 106은 애플리케이션 라이프사이클의 일예를 나타내는 도면. 106 is a view showing an example of the application life cycle.

도 107은 새로운 아키텍처의 이점의 예를 나타내는 도면. 107 is a view showing an example of the advantages of the new architecture.

도 108은 복잡한 시스템을 단순한 다이어그램으로 변화하는 일예를 나타내는 도면. 108 is a view showing an example of changes in a complex system with a simple diagram.

도 109는 서비스의 일예를 나타내는 도면. 109 is a view showing an example of a service.

도 110은 SQL 클러스터의 일예를 나타내는 도면. 110 is a view showing an example of a SQL cluster.

도 111은 SDM 데이터 센터 모델의 일예를 나타내는 도면. 111 is a view showing an example of SDM data center model.

도 112는 설계 애플리케이션 외면(design application surface)의 일예를 나타내는 도면. Figure 112 is a view illustrating an example of a design application, the outer surface (design surface application).

도 113은 데이터 센터에서의 SDM 서비스의 일예를 나타내는 도면. Figure 113 is a diagram showing an example of SDM Service in the data center.

도 114는 자원 관리자의 예를 나타내는 도면. Figure 114 is a view showing an example of a resource manager.

도 115는 자원 시각화의 일예를 나타내는 도면. 115 is a view showing an example of resource visualization.

도 116은 프로그래밍 동작 논리의 예를 나타내는 도면. Figure 116 is a diagram showing an example of the programming operation logic.

도 117은 동작 논리와의 상호작용의 예를 나타내는 도면. Figure 117 is a diagram showing an example of interaction with the logic operation.

도 118 내지 119는 이질적 환경(heterogeneous environments)을 관리하는 일예를 나타내는 도면. 118 to 119 is a view illustrating an example of managing a heterogeneous environment (heterogeneous environments).

*도면의 주요부분에 대한 부호의 설명* * Description of the Related Art *

100 인터넷 데이터 센터 100 Internet Data Center

102 서버 컴퓨터 102 server computers

104 부가적 컴퓨터의 풀 104 pool of additional computers

관련 출원 Related Applications

본 출원은, 2003년 3월 6일자로 출원되어 여기서 일부로서 참조되는 미국 가출원 제60/452,736호의 이익을 주장한다. This application has been filed on March 06, 2003. The claims of No. 60 / 452,736 U.S. Provisional profit referred to as some.

또한, 본 출원은 (여기서 일부로서 참조되는) 다음의 미국 특허 출원들에 관계된다: Further, this application is related to the following US patent applications (here referred to as part):

2003년 3월 6일 출원된, 발명의 명칭이 "Virtual Network Topology Generation"인 미국 특허 출원 제10/382,942호; Filed March 6, 2003, the title of the invention a "Virtual Network Topology Generation" US Patent Application No. 10 / 382,942;

2000년 10월 24일 출원된, 발명의 명칭이 "System and Method for Distributed Management of Shared Computers"인 미국 특허 출원 제09/695,812호; Filed October 24, 2000, the title of the invention the "System and Method for Distributed Management of Shared Computers" US Patent Application No. 09 / 695,812 calls;

2000년 10월 24일 출원된, 발명의 명칭이 "System and Method for Logical Modeling of Distributed Computer Systems"인 미국 특허 출원 제09/695,813호; Filed October 24, 2000, the title of the invention the "System and Method for Logical Modeling of Distributed Computer Systems" US Patent Application No. 09 / 695,813 calls;

2000년 10월 24일 출원된, 발명의 명칭이 "System and Method for Restricting Data Transfers and Managing Software Components of Distributed Computers"인 미국 특허 출원 제09/695,820호; Filed October 24, 2000, the title of the invention "System and Method for Restricting Data Transfers and Managing Software Components of Distributed Computers" US Patent Application No. 09 / 695,820 calls;

2000년 10월 24일 출원된, 발명의 명칭이 "Using Packet Filters and Network Virtualization to Restrict Network Communications"인 미국 특허 출원 제09/695,821호; Filed October 24, 2000, the title of the invention in "Using Packet Filters and Network Virtualization to Restrict Network Communications" US Patent Application No. 09 / 695,821 calls;

2000년 10월 24일 출원된, 발명의 명칭이 "System and Method for Designing a Logical Model of Distributed Computer Systems and Deploying Physical Resources According to the Logical Model"인 미국 특허 출원 제09/696,707호; Filed October 24, 2000, the title of the invention the "System and Method for Designing a Logical Model of Distributed Computer Systems and Deploying Physical Resources According to the Logical Model" US Patent Application No. 09 / 696,707 calls; And

2000년 10월 24일 출원된, 발명의 명칭이 "System and Method Providing Automatic Policy Enforcement in a Multi-Computer Service Application"인 미국 특허 출원 제09/696,752호. Filed October 24, 2000, the title of the invention "System and Method Providing Automatic Policy Enforcement in a Multi-Computer Service Application" US Patent Application No. 09 / 696,752 calls.

본 발명은 분산형 컴퓨팅 시스템을 위한 아키텍처 및 그 분산형 컴퓨팅 시스템 상의 분산형 애플리케이션의 자동화된 설계, 배포와 관리에 관한 것이다. The present invention relates to an automated design, deployment and management of distributed applications on a distributed computing architecture, and the system for a distributed computing system.

인터넷 사용은 지난 수년 동안 폭발적으로 증가하였으며, 계속 증가하고 있다. Internet use has increased explosively over the past few years and continues to increase. 사람들은 전자 메일, 온라인 쇼핑, 뉴스 및 정보의 수집, 음악의 청취, 비디오 클립의 감상, 구직 등과 같은 월드 와이드 웹(World Wide Web, 단순히 "Web") 상에서 제공되는 다양한 서비스들에 매우 만족하게 되었다. People were very satisfied with the e-mail, online shopping, news and gathering of information, listening to music, watching a video clip, the World Wide Web, such as employment (World Wide Web, simply "Web") various services provided on . 인터넷-기반 서비스들의 성장 수요와 보조를 맞추기 위해서, 호스팅 웹사이트들을 위한 백엔드 서비스(backend service)를 제공하고 그 사이트와 관련된 데이터를 저장하는, 호스팅 웹사이트용 컴퓨터 시스템들에서 대단한 성장이 있어 왔다. Internet - in order to meet the growing demand and accessories of based services, providing back-end services (backend service) for hosting Web sites, there has been a great growth in data, computer systems, hosting Web sites that store associated with the site.

분산형 컴퓨터 시스템의 일 유형은 인터넷 데이터 센터(Internet data center; IDC)인데, IDC는 인터넷-기반 서비스들을 호스팅하기 위한 다수의 컴퓨터들에게 장소를 제공하는 특별히 설계된 복합체(complex)이다. One type of distributed computer system is an Internet data center; inde (Internet data center IDC), IDC Internet - a complex (complex) specifically designed to provide a place for a large number of computers for hosting based services. "웹농장(Webfarms)" 및 "서버 농장(server farms)"이라는 이름으로도 통하는 IDC들은 일반적으로 수백에서 수천개의 컴퓨터들에게 기후가 제어되고 물리적으로 안전한 건물내에 장소를 제공한다. "Web farm (Webfarms)" and "server farm (server farms)" also leads IDC named are generally easy to control thousands of computers in hundreds provides a safe place within the building physically. 이들 컴퓨터들은 상호 연결되어, 하나 이상의 인터넷 서비스 또는 웹사이트를 지원하는 하나 이상의 프로그램을 실행시킨다. These computers are connected to each other, thereby executing one or more programs supporting one or more Internet services or Web sites. IDC들은 신뢰할 수 있는 인 터넷 액세스, 신뢰할 수 있는 전원, 및 안전한 운영 환경을 제공한다. IDC will provide reliable Internet access, reliable power, and secure operating environment that can be.

도 1은 인터넷 데이터 센터(100)를 도시한다. Figure 1 shows an Internet data center (100). 그것은 특별하게 구성된 스페이스에 배열된 다수의 서버 컴퓨터들(102)을 가진다. It has a number of server computer (102) arranged in a specially constructed space. 컴퓨터들은 범용 컴퓨터이며, 일반적으로 서버들로서 구성된다. Computers and general purpose computer, and is generally configured as a server. 인터넷 데이터 센터는 하나의 엔티티를 위한 하나의 사이트에 장소를 제공하도록(예를 들어, Yahoo! 또는 MSN을 위한 데이터 센터) 또는 다수의 엔티티들을 위한 다수의 사이트들을 수용하도록(예를 들어, 다수의 회사들을 위한 사이트들을 호스트하는 Exodus 센터) 구성될 수 있다. Internet data center to accommodate multiple sites for (the data center for example, Yahoo! or MSN) to provide a place in one site for a single entity or multiple entities (e.g., a number of It can be configured Exodus center that host sites for the company).

IDC(100)는 컴퓨터 자원을 공유하는 3개의 엔티티들 -엔티티 A, 엔티티 B, 엔티티 C-을 가진 것으로 예시되고 있다. IDC (100) are three entities that share the computer resources - has been illustrated as having the entity A, entity B, entity C-. 이들 엔티티는 Web 상에 존재하기를 희망하는 다수의 회사들을 나타낸다. These entities represent a number of companies who wish to present on the Web. IDC(100)는 격심한 트래픽(heavy traffic)의 상황에서 엔티티들에 의해 사용될 수 있는 추가적인 컴퓨터들(104)을 가지고 있다. IDC (100) has an additional computers 104 that may be used by the entity in the context of severe traffic (heavy traffic). 예를 들어, 온라인 소매에 종사하는 엔티티는 크리스마스 시즌 동안 훨씬 더 많은 수요를 경험할 수 있다. For example, an entity engaged in online retailing may experience a lot more demand during the Christmas season. 추가적인 컴퓨터는 IDC에게 이러한 수요를 충족시킬 수 있는 유연성을 제공한다. Additional computer provides the flexibility to meet the demand for IDC.

오늘날, 큰 IDC들은 복합체이며, 종종 다수의 애플리케이션들을 호스트하도록 요청된다. Today, a large IDC are complex and are often asked to host multiple applications. 예를 들어, 일부 웹사이트들은 수천개의 컴퓨터들을 운영할 수 있고, 많은 분산형 애플리케이션들을 호스트할 수 있다. For example, some websites may operate several thousand computers, can host many distributed applications. 이들 분산형 애플리케이션은 종종 복잡한 애플리케이션들을 지원할 수 있도록 오퍼레이터가 IDC 내에 와이어링 구성을 수동적으로 배열할 뿐 아니라 어떤 네트워크 스위치들에 연결하도록 요 청하는 필수품들(requirements)과 네트워크로 접속된 복합체를 가진다. These distributed applications often reaching required the operator to support the complex applications to connect to certain network switches, as well as manually arrange the wiring configurations within the IDC has a complex connection to the necessity to (requirements) and the network. 그 결과, 애플리케이션 요청들에 따르기 위해 물리적 네트워크 토폴로지를 세우는 이 작업은 사람들의 오류를 일으키기 쉬운 성가시고, 시간 소모적인 프로세스일 수 있다. As a result, the job building a physical network topologies to conform to the application request is cumbersome prone to errors of the people Castle, it can be a time-consuming process. 따라서, 물리적 컴퓨팅 시스템 상에 분산형 애플리케이션을 설계하고 배포하기 위한 개량된 기술에 대한 필요가 존재한다. Therefore, a need exists for improved techniques for designing and deploying distributed applications on a physical computing system.

분산형 컴퓨팅 시스템 상에 분산형 애플리케이션을 설계하고, 배포하며, 관리하기 위한 아키텍처 및 방법이 설명된다. The design of distributed applications on a distributed computing system, the distribution, the architecture and method for management is described.

다음 개시는 대규모 애플리케이션 서비스와 함께 분산형 컴퓨팅 시스템을 설계하고 구현하기 위한 아키텍처에 어울리는 다수의 양상들을 설명한다. The following disclosure describes a number of aspects to match the architecture for designing a distributed computing system with large-scale application services and implementation. 그 개시는 서비스 정의 모델(service definition model; SDM) 및 SDM 런타임 환경에 대한 논의를 포함한다. The disclosure is the service definition model; and a discussion on the (service definition model SDM) and SDM runtime environment. 그 개시는 어떻게 데이터 센터 컴포넌트들을 모델링할 것인지, 어떻게 분산형 애플리케이션 기술을 모델링할 것인지, 및 모델링된 데이터 센터 상으로 모델링된 애플리케이션을 논리적으로 배포하고 설계 시에 이 논리적 배포를 확인하기 위한 기술들과 같은 설계 양상들을 더 포함한다. As disclosed want to model how data center components, and how to model the distributed application technology, and logical distribution of applications modeled in the modeling data centers on and with techniques for checking the logical deployment in the design further it includes such design aspects. 그 개시는 물리적 데이터 센터에 애플리케이션 배포를 용이하게 하기 위해서 어떻게 물리적 자원들 상에 분산형 애플리케이션의 물리적 배포, 물리적 자원들을 사용하는 모델을 실증할 것인지와 같은 배포 양상들을 더 설명한다. The disclosure further describes the deployment aspects, such as whether to demonstrate the physical distribution, the model used by the physical resources of the distributed application on how the physical resources in order to facilitate the application deployed on the physical data center. 또한, 그 개시는 SDM을 사용하여 문맥적 관리 피드백(contextual management feedback), 추적, 및 운영 피드백을 사용하는 것을 포함하는 관리 양상도 언급한다. Further, the disclosure refers to manage aspects, comprising using the SDM using contextual feedback management (management contextual feedback), tracking, and operational feedback. 그 개시는 물리적 자원을 가로질러 애플리 케이션의 배포에 사용되며, 상기 관리 양상들을 지원하기 위한 다수의 자원 관리자들에 대해서 논의한다. The disclosure is directed across the physical resources used for distribution of the application, it will be discussed with respect to a plurality of resource manager for supporting the management aspect.

서비스 정의 모델(SDM) Service Definition Model (SDM)

서비스 정의 모델(SDM)은 애플리케이션 설계자가 추상적인 방법으로 데이터 센터 및 분산형 컴퓨터 애플리케이션을 설계하기 위한 문맥과 도구를 제공한다. Service Definition Model (SDM) provides the context and tools for designing data centers and distributed computer applications with the application designers abstract way. 그 모델은 결국 물리적 컴퓨터 자원 및 소프트웨어에 의해 구현될 애플리케이션들의 기능 유닛들을 나타내는 요소들의 집합을 정의한다. The model defines a set of elements that represent functional units of the end application to be implemented by physical computer resources and software. 컴포넌트들에 의해 표현되는 기능 동작들을 어떻게 지정할 것인지를 지시하는 스키마는 모델 요소들과 관련되어 있다. Schema that indicates how you want to specify the functional behavior represented by the components are associated with model elements.

SDM 개괄 SDM overview

- 인터넷 시대(Internet Era) - Internet era (Internet Era)

지난 십년 동안, 우리는 인터넷이 컴퓨팅 플랫폼으로서 판명되는 것을 목격해 왔다. Over the past decade, we have witnessed that the Internet has proved a computing platform. 더 많은 소프트웨어 회사들이 그 소프트웨어를 서비스 모델로서 채택하고 있다. More and more software companies are adopting the software as a service model. 이들 서비스는 일반적으로 서버, 네트워크 장비 및 다른 전문 하드웨어를 포함하는 다수의 기계들을 운행시키는 다수의 컴포넌트들로 이루어진다. These services are typically comprised of multiple components of the server, runs a number of machines, including network equipment and other specialized hardware. 느슨하게 연결된 비동기 프로그래밍 모델(loosely coupled, asynchronous programming models)은 표준이 되어 가고 있다. Loosely coupled asynchronous programming model (loosely coupled, asynchronous programming models) are becoming the norm. 계량성(scalability), 유용성(availability), 및 신뢰성은 이들 분산형 서비스의 성공에 중요하다. Weighing Castle (scalability), availability (availability), and reliability is critical to the success of these distributed services.

우리는 또한 하드웨어 유행에서의 변화를 목격하고 있다. We are also witnessing a change in hardware fashion. 고밀도 서버들 및 전문 네트워크 하드웨어는 데이터 센터에서 널리 보급되어 있다. The high-density servers and specialized network hardware is widely used in data centers. 스위치형 구조물(switched fabrics)이 시스템 버스를 대신하여 시스템 구성에 보다 큰 유연성을 제공하고 있다. Switch-type structure (switched fabrics) and the system bus on behalf of providing greater flexibility in the system configuration. 이제, 하드웨어 비용은 전용 운영 직원을 교육하고 관리하는 비용에 비하면 소유권의 총 비용(Total Cost of Ownership; TCO) 측정 기준에서 작은 역할만 할 뿐이다. Now, the hardware cost is the total cost of ownership when compared to the cost of training and managing a dedicated operations staff; only be only (Total Cost of Ownership TCO) metrics in a small role. 바위처럼 단단한 운영 실행(rock-solid operational practices)은 임의의 고 유용성 서비스에 극히 중요하지만, 수동적인 프로시저들을 실행하는 사람들로 인하여 오류를 범하기 쉽기 때문에 이들 실행을 지속적으로 반복하기는 어렵다. Solid operational execution as a rock (rock-solid operational practices) are extremely important to any high-availability service, but it is difficult to continuously repeat their run because it is easy to commit errors due to people running a manual procedure. 서비스 시대로서 신흥 소프트웨어에서, 개발의 초점은 데스크탑에서 서버로 옮겨가고 있다. In the emerging software as a service era, the focus of the development is moving from the desktop to the server. 이러한 초점의 변화와 함께, 소프트웨어 개발자, 하드웨어 벤더, 및 IT 전문가들에게 다음과 같은 새로운 문제들이 대두되고 있다: With this change of focus, and to software developers, hardware vendors, and IT professionals have emerged following new issues:

- 서비스들이 보다 크고 보다 복잡하다 - 서비스들이 개발하기에 시간-소모적이고, 유지하기 어렵고 비싸며, 추가적인 기능을 확장하기 위험하다. - Services will be larger and more complex - services have time to develop-consuming and expensive and difficult to maintain, it is dangerous to extend additional functionality.

- 서비스들이 획일적이 되기 쉽다 - 서비스들이 습관이 된 컴포넌트들 및 특정 구성에 의존하기 쉽다. - Services are likely to be a uniform-services are likely to depend on the habits and component-specific configuration. 많은 서비스들 중 일부분이 서비스의 유용성에 영향을 주지 않고 제거되거나, 독립적으로 개선되거나, 또는 대체물로 교체될 수 없다. Many services partially or removed without affecting the usability of the service, or improved independently, or can not be replaced by substitutes.

- 서비스들이 특정 하드웨어 구성에 의존한다 - 특정 네트워크 토폴로지 또는 특정 네트워크 장치에 대한 의존성이 있는지, 하드웨어와 소프트웨어 간의 바인딩은 다양한 데이터 센터에서 서비스를 호스트할 수 있는 능력을 상당히 감소시킨다. - services are dependent on specific hardware configurations - then that is dependent on the particular network topology or a particular network device, the binding between the hardware and software greatly reduces the ability to host a variety of services in the data center.

- 서비스들이 운영적인 일관성을 요구한다 - 대부분의 서비스들은 동작을 위해 운영 직원을 필요로 한다. - The required services are operational consistency - most services require operating personnel to the operation. 일반적인 플랫폼의 부족은 서비스들을 가로질러 코 드를 재사용하고 운영상의 최상의 실시를 제정할 수 있는 능력을 감소시킨다. The lack of a common platform, thereby reusing code across the service and reduce the ability to establish a superb operational implementation. 불행하게도, 운영 직원은 각 서비스의 특징들을 훈련받아야 하고, 각 서비스가 발전될 때 다시 훈련받아야 한다. Unfortunately, the operating staff must be trained characteristics of each service and must be re-trained as each service develops.

"서비스"와 "애플리케이션"이라는 용어들은 본 명세서에서 호환할 수 있는 의미로 사용된다. The term "service" and "application" are used interchangeably herein can be compatible. 일반적으로, 애플리케이션은 분산형 서비스들의 집합으로 간주될 수 있다. In general, the application can be considered as a set of distributed services. 예를 들어, Hotmail은 각 서비스가 다른 기능을 수행하는 다양한 서비스들로 구성된 애플리케이션일 수있다. For example, Hotmail may be configured in a variety of application services that each service is performing other functions.

이들 문제는 데스크탑과 DOS 시대(약 1980년대경)의 문제들과 다른 것 같지 않다. The problem does not seem different from the problems of desktop and DOS era (about 1980 large diameter). DOS는 디스크 관리, 파일 시스템, 콘솔 기능(console facilities) 등과 같은 애플리케이션 개발자들을 위한 매우 유용한 코어 서비스들을 정의하였다. DOS has defined the core services very useful for application developers, such as disk management, file system, console feature (console facilities). 그러나, DOS는 많은 복잡한 작업들을 ISV들에게 남겨 놓았다. However, DOS is leaving many complex tasks to ISV. 일 예로서, WordPerfect와 Lotus 123은 프린트 기능을 지원하기 위해 각 애플리케이션들 내에 모두 독립적으로 프린터 드라이버를 기록해야만 했다. As an example, WordPerfect and Lotus 123 had to be recorded by the printer driver, both independently in the respective application in order to support the print function. 유사하게, 프린터 하드웨어 벤더들은 성공적인 제품을 가지기 위하여 소프트웨어 회사들과 거래해야만 했다. Similarly, the printer hardware vendors, software companies have had to deal with in order to have a successful product. ISV들과 하드웨어 벤드들에 대한 가입에 대한 장벽은 이례적으로 높았다. Barriers to accession to the ISV and hardware Bend is exceptionally high. 이것은 그 시대 동안 단지 소수의 소프트웨어 및 하드웨어 회사들만이 성공할 수 있는 결과를 초래하였다. It was just a result of success, only a small number of software and hardware companies during that period.

Microsoft는 Windows 플랫폼을 생성하는 데 있어서 이 문제를 처리하여, 가입에 대한 장벽을 극적으로 감소시켰다. Microsoft will handle the matter according to create a Windows platform, reduced barriers to join dramatically. Windows는 PC 플랫폼 상의 대부분의 하드웨어 장치에 대하여 추상화 계층(abstraction layer)을 정의하였다. Windows has defined an abstraction layer (abstraction layer) for most of the hardware devices on the PC platform. 이것은 ISV들 이 특정 하드웨어 장치들을 지원하기 위하여 걱정해야만 하는 것을 덜어 주었다. It was relieving to have to worry about the ISV to support a particular hardware device. Windows는 메모리, 디스크 및 네트워크를 포함하는 PC 내부의 모든 자원을 관리하였다. Windows were managing all the resources inside the PC, including memory, disk, and network. 또한, Windows는 ISV들에 의해 사용될 수 있는 수많은 추가적인 서비스들을 부가하였다. In addition, Windows had added a number of additional services that can be used by the ISV. 이 플랫폼은 당 산업계에서 커다란 성장을 유발하였다. The platform was causing a huge growth in the industry parties. Windows 플랫폼을 타겟으로 한 ISV들은 지극히 생산적이었다. ISV one Windows platform to the target, it was extremely productive. 많은 새로운 하드웨어 벤더들이 공통 플랫폼, Windows를 가지는 유용한 효과에 기인한 보다 저렴한 하드웨어를 제공하면서 생겨났다. Many new hardware vendors have emerged, providing a more affordable hardware, due to the beneficial effects with a common platform, Windows.

서비스 정의 모델(SDM) Service Definition Model (SDM)

SDM 원리 SDM principles

SDM은: The SDM:

- 분산형 애플리케이션들/서비스들을 설계하는 것을 보다 쉽게 하는 추상화를 정의한다. - Define abstractions easier to design of distributed applications / services.

- 운영 실시의 자동화 및 재사용을 위한 프레임워크를 가능하게 한다. - allow a framework for the automation and reuse of operations conducted.

- 분산형 애플리케이션 및 서비스들의 운영 및 배포를 단순화한다. - simplifies the administration and deployment of distributed applications and services.

오늘날 서비스의 오퍼레이터 부근의 벽 상에서 복잡한 다이어그램으로서 흔히 보여지는 것을 캡쳐하는 것을 고려함으로써, SDM이 무엇인지를 이해하는 것이 더 쉬워질 수 있다. By considering that capture that is often viewed as a complex diagram on the wall in the vicinity of today's service operator, it may be easier to understand if what the SDM. 이들 다이어그램에서, 박스는 일반적으로 서비스의 실행 요소를 나타내며, 박스들을 연결하는 선들은 서비스 요소들 간의 통신 경로를 나타낸다. In these diagrams, the box is generally denotes the execution of the service element, the lines connecting the boxes represents a communication path between the service components. 예를 들어, 다시 하나 이상의 중간-층(middle-tier) 또는 백-엔드 서비스들에 연결되는 일부 IIS 프론트-엔드 기계들에 연결된 로드 밸런서(load balancer)가 있 다. For example, one or more intermediate back-there is a load balancer (load balancer) attached to the machine end-part IIS front end connected to the service-layer (middle-tier), or back.

SDM에 대하여 생각하는 또다른 방법은 SDM은 분산형 애플리케이션/서비스의 동작에 대한 메타-모델(meta-model)과 컴퓨팅 환경에서 실행하는 애플리케이션/서비스의 "생생한" 청사진 모두라는 것이다. Another way to think about the SDM The SDM metadata about the operations of distributed applications / services - will be a "live" blueprint of all applications / services run on the model (meta-model) and the computing environment. 가능한 소프트웨어 동작들을 포함하여, 선언적이고 스케일-불변의 방식으로, SDM은 컴퓨팅 환경에서 애플리케이션의 구조를 캡처한다. Including the software operation, declarative and scale-invariant in the manner of, SDM captures the structure of the application in a computing environment. 하드웨어와 네트워크 자원 간의 바인딩을 포함하여 서비스의 토폴로지 및 소프트웨어 컴포넌트의 유효한 동작들을 선언적으로 기술하는 능력은 매우 강력하다. The ability to declaratively described as the effective operation of the service topology and software components, including the binding between the hardware and network resources is very powerful.

유사한 것으로서, Microsoft의 Common Object Model(COM)을 살펴보자. As similar to, let's look at Microsoft's Common Object Model (COM). COM은 컴포넌트들이 어떻게 패키지되고, 등록되고, 활성화되고, 발견되는지 등을 표준화하였다. COM is standardized, etc., and how the component packages, registered and, being active, if found. COM은 라이프타임, 메모리 관리, 및 인터페이스 구현에 관한 엄격한 룰들을 명령한다. COM commands the strict rules regarding lifetime, memory management, and interface implementation. 이들 원형(primitives)은, 컴포넌트들이 블랙 박스로서 처리될 수 있도록 하기 때문에, 정보처리 상호운용(interoperability)에 필수적이다. These circular (primitives) is, because it allows components to be treated as a black box, is essential for Interoperability (interoperability). COM은 이벤팅, 자동화 및 OLE와 같은 보다 정교한 서비스들을 위한 기초이다. COM is the basis for more sophisticated services such as eventing, automation, and OLE.

마찬가지로, SDM은 보다 정교한 특성을 만들기 위한 일부 기본 원형들을 정의하는 것을 필요로 한다. Similarly, SDM requires you to define some basic prototype for creating more sophisticated features. 이들 원형들은: These are circular:

- 컴포넌트 - 구현, 배포 및 관리의 유닛 - the component-units of implementation, deployment and management

- 포트 - 관련 유형 및 유효한 동작들의 집합을 가지는 지정된 종단점 - port-related type and the specified endpoint has a set of effective operation

- 와이어 - 포트들간의 허용되는 통신 경로 - Wire communication is allowed between the port channel

- 계층 - 자원 관리 소유권 및 바인딩의 분리 - tier-resource management, separation of ownership and binding

- 맵핑 - 각 계층에서 컴포넌트, 포트 및 와이어 간의 바인딩 - Mapping-binding between components, ports and wires in each layer

본 명세서의 나머지는 이들 원형들 각각을 보다 상세하게 설명할 것이다. The rest of this specification will describe in more detail these circular each.

컴포넌트, 포트 및 와이어 Components, ports, and wire

본 명세서의 목적을 위하여, 컴포넌트, 포트 및 와이어를 사용하여 그려진 MyService라고 불리는 단순한 서비스의 그래픽적인 표현을 고려하는 것이 유용하다. For the purposes of this disclosure, it is useful to consider a graphical representation of a simple service called MyService drawn using the components, ports, and wires. 도 2을 참조하자. Let's see Fig. 2. 다이어그램에서, 박스들은 컴포넌트들을 나타내고, 다이아몬드들은 포트들을 나타내며, 파선은 와이어들을 나타낸다. In the diagram, boxes represent components, diamonds represent ports, and the broken line represents the wire.

- MyService는, MyFrontEnd와 MyBackEnd라는 컴포넌트들을 사용하기 때문에 복합 컴포넌트이다. - MyService is a composite component due to the use of components of the MyFrontEnd MyBackEnd.

- MyService는 MyFrontEnd 컴포넌트에 의해 구현된 위임 포트(delegated port)인 web이라고 불리는 하나의 가시적 포트를 가진다. - MyService has one visible port called a web delegated port (delegated port) implemented by MyFrontEnd component.

- MyFrontEnd는 2개의 포트, 즉 위임 포트와 catalog라고 라벨이 붙은 포트를 가진다. - MyFrontEnd has two ports, i.e. a port is attached to the label that delegation ports and catalog.

- MyBackEnd는 data라고 라벨이 붙은 하나의 포트를 가진다. - MyBackEnd is that having a port labeled data.

- MyFrontEnd와 MyBackEnd 컴포넌트들은 catalog 포트와 data포트를 와이어를 통하여 묶는 잠재적인 통신 관계를 가진다. - MyFrontEnd and MyBackEnd components have the potential to tie a communication relationship via a wire to catalog port and data port.

컴포넌트 component

컴포넌트들은 구현, 배포 및 관리의 유닛들이다. Components are units of implementation, deployment and management. 컴포넌트들의 예들은 Windows Server를 실행하는 전용 서버, IIS 가상 웹 사이트 또는 SQL 데이터베이스이다. Examples of components a dedicated server, IIS virtual Web site or the SQL database that is running Windows Server. 컴포넌트들은 일반적으로 기계 경계를 가지나, 단일 IIS 서버 상에서 호스 팅되는 웹 서비스들에 의해 증명되어질 것이 요청되지는 않는다. Components are typically gajina machine boundaries, but are not asked to be proved by putting Web services host on a single IIS server.

컴포넌트들은 포트들을 통하여 기능들을 공개하며, 와이어들을 통하여 통신한다. Components are also disclose the functions through the port and communicates through wires. 단순한 컴포넌트들은 단지 멤버들로서 포트들을 가질 수 있다. Simple components can only have the ports as members. 다른 컴포넌트들을 사용하는 컴포넌트들은 복합 컴포넌트(compound component)라고 불리며, 다른 컴포넌트들에 덧붙여 포트들과 와이어들을 가질 수 있다. Components using other components are referred to as a composite component (compound component), in addition to the other components may have the port and wire.

복합 컴포넌트들은 합성을 통하여 생성되며, 그와 관련된 어떠한 구현도 가지지 않는다. Composite components are produced by a synthetic, it does not have any implementation associated with it. 복합 컴포넌트 포트들은 내부 컴포넌트들로부터의 위임 포트들이다. Composite component ports are the ports of the delegation from the internal components. 복합 컴포넌트들은 배열(collocation), 캡슐화(encapsulation) 및 재사용을 가능하게 하며, 따라서 애플리케이션/서비스 및 그 행동을 조직화하는 하나의 방법으로 생각될 수 있다. Composite components are also enables the arrangement (collocation), encapsulated (encapsulation) and re-use, and thus may be thought of as a way to organize the applications / services and their behaviors.

컴포넌트의 단지 공용 포트들(public ports)만이 컴포넌트 외부에서 가시적이다. Only the only common port of the component (public ports) is visible from outside the component. 복합 컴포넌트들은 캡슐화를 통하여 자신이 사용하는 컴포넌트들의 내부 구조를 숨긴채 외부 세계에는 단순 컴포넌트들(simple components)로 보인다. Composite components outside world while hiding the internal structure of the components they use through encapsulation appears to be the simple component (simple components). 사실, 양자에 의해 지원되는 행동들과 포트 유형들이 완전히 동일하기만 하다면, 단순 컴포넌트는 복합 컴포넌트로 교체될 수 있으며, 그 역도 가능하다. In fact, if only the behavior that is supported by both the port type and are completely the same, simple component can be replaced by a composite component, and vice versa.

포트 port

포트들은 행동들의 집합을 정의하는 지정된 종단점(named end-points)이다. Ports are the endpoints (named end-points) that defines a set of specified actions. 포트들은 관련 유형 및 역할을 가지며, 일반적으로 허용되는 동작들의 집합과 관련된다. Ports has an associated type and the role is associated a set of operations would normally have. 포트들의 예들은 허용되는 동작들의 집합을 가지는 SOAP 포트, HTTP 서버 포트 등이 있다. Examples of ports include port SOAP, HTTP server port with a set of allowed operations. 포트들은 위임될 수 있는데, 이는 외부 컴포넌트가 내부 컴포넌 트의 포트를 자신의 것인양 공개할 수 있다는 것을 의미한다. There are ports can be delegated, which means that the external component is a port of the internal component can publish it in their salvage. 포트들은 하나의 컴포넌트에 대한 공용 인터페이스(행동)를 형성한다. Ports form a common interface (action) on the one component. 포트들은 공용으로(가시적으로) 될 수 있는 컴포넌트의 유일한 멤버들이다. Ports are the only members of the component can be (visually), public.

와이어 wire

와이어들은 포트들간의 허용되는 바인딩들이며, 포트들 (및 컴포넌트들) 간의 토폴로지적 관계를 나타낸다. Wires deulyimyeo acceptable binding between the port represents the topology relationship between the port (and components). 와이어들은 임의의 인스턴스 상호연결 토폴로지(instance interconnect topology)를 지정하지 않으며, 대신 인스턴스 상호연결 토폴로지를 위한 "잠재성(potentiality)"을 표현한다. Wires does not specify any instance interconnect topology (instance interconnect topology), instead expresses the "potential (potentiality)" for instance interconnection topology.

와이어들은 본질적으로 버스들이며, 하나 이상의 포트 멤버들을 포함할 수 있다. Deulyimyeo wires are inherently bus may include one or more port members. 와이어들은 포인트-투-포인트 관계로 오해되어서는 안 된다. Wire are point-to-point should not be misunderstood as a relationship-to. 주어진 포트는 동일한 와이어 내에서 한번 이상 나타날 수 없다. Given port can not occur more than once within the same wire.

스키마(Schema) Schema (Schema)

애플리케이션/서비스를 설명하기 위해서는, SDM을 위한 표준 스키마를 가질 필요가 있다. In order to explain the application / services, it is necessary to have a standard schema for the SDM. SDM 스키마는 XSD 및 XML 문법을 이용하여 표현될 수 있어야 한다. SDM schema must be represented by an XSD and XML syntax. SDM 스키마를 상세히 설명하는 것은 본 명세서의 범위를 벗어나는 것이지만, 본 명세서에서 이후에 설명할 주제를 위한 맥락으로서 간략한 설명을 하는 것이 필요하다. To explain in detail the SDM scheme is beyond the scope of this specification, it is necessary that a short description as a context for the subject to be described later herein. 이하는 SDM 스키마를 간략하게 나타낸 것이다. Below shows an overview of the SDM scheme.

<sdm> <Sdm>

<identityReference /> <IdentityReference />

<portClasses/> <PortClasses />

<wireClasses /> <WireClasses />

<componentClasses /> <ComponentClasses />

<hostRelations /> <HostRelations />

<portTypes /> <PortTypes />

<wireTypes /> <WireTypes />

<componentTypes /> <ComponentTypes />

</sdm> </ Sdm>

SDM 스키마에 대한 더욱 상세한 정보를 얻고자 하면 http://big/에 있는 SDM 스키마 사양(specification)을 읽고 샘플 XSD 파일을 검토하도록 한다. If you want to get more detailed information about the SDM schema http: read the SDM schema specification (specification) in // big / and to review sample XSD file.

SDM 클래스 SDM classes

애플리케이션/서비스에서 모든 컴포넌트, 포트 및 와이어는 클래스의 사용을 통하여 생성되는 타입이다. All the components, ports, and the wire by the application / service is a type that is generated through the use of classes. 새로운 타입은 기존의 클래스들 및 타입들로부터 생성될 수 있다. A new type can be created from existing classes and types. 예컨대, 웹 서비스는 SQL 데이터베이스와 마찬가지로 클래스로서 모델링될 수 있다. For example, Web services can be modeled as a class, as in the SQL database. SDM 클래스는 기본적으로 공통 특징에 대한 추상화이다. SDM class is basically an abstraction of the common features. MyService 애플리케이션에서는, MyFrontEnd는 클래스 웹 서비스로부터 파생되는 새로운 타입이고, MyBackEnd는 클래스 SQL 데이터베이스로부터 파생되는 새로운 타입이다. In MyService applications, MyFrontEnd is a new type that derives from the Web service class, MyBackEnd is a new type that derives from the class SQL database.

아래는 포트들, 와이어들 및 컴포넌트들에 대한 클래스 스키마의 일예이다. Below is an example of a class schema for the ports, wires and components.

<portClass name="ServerDataAccess" layer="Application"> <PortClass name = "ServerDataAccess" layer = "Application">

<settingSchema> <SettingSchema>

<xs:element name="databaseName" type="xs:string" /> <Xs: element name = "databaseName" type = "xs: string" />

</settingSchema> </ SettingSchema>

</portClass> </ PortClass>

<wireClass name="DataConnection" layer="Application"> <WireClass name = "DataConnection" layer = "Application">

<settingSchema> <SettingSchema>

<xs:element name="useSSL" type="xs:boolean" /> <Xs: element name = "useSSL" type = "xs: boolean" />

</settingSchema> </ SettingSchema>

<portClassesAllowed> <PortClassesAllowed>

<portClassRef name="ServerDataAccess" maxOccurs="1" /> <PortClassRef name = "ServerDataAccess" maxOccurs = "1" />

<portClassRef name="ClientDataAccess" /> <PortClassRef name = "ClientDataAccess" />

</portClassesAllowed> </ PortClassesAllowed>

</wireClass> </ WireClass>

<componentClass name="Database" layer="Application"> <ComponentClass name = "Database" layer = "Application">

<deploymentSchema> <DeploymentSchema>

<xs:element name="sqlScriptFilePath" type="xs:string" maxOccurs="unbounded" /> <Xs: element name = "sqlScriptFilePath" type = "xs: string" maxOccurs = "unbounded" />

</deploymentSchema> </ DeploymentSchema>

<settingSchema> <SettingSchema>

<xs:element name="databaseName" type="xs:string"/> <Xs: element name = "databaseName" type = "xs: string" />

</settingSchema> </ SettingSchema>

<portClassesAllowed closed="true"> <PortClassesAllowed closed = "true">

<portClassRef name="ServerDataAccess" /> <PortClassRef name = "ServerDataAccess" />

</portClassesAllowed> </ PortClassesAllowed>

</componentClass> </ ComponentClass>

componentClass 및 wireClass 스키마 각각은 허용되는 설정 스키마(settings schema), 배포 스키마(deployment schema) 및 포트 클래스들을 포함할 수 있다는 것에 주의하자. componentClass wireClass and schemas, let's note that you can include settings that permit scheme (settings schema), schema deployment (deployment schema) and port class. portClass는 포트 클래스가 허용되는 섹션을 갖지 않는다. portClass does not have a section where Fort class is allowed. 이들 스키마는 다음과 같이 정의된다: These schemas are defined as follows:

- 설정 스키마는 설계시(design-time)에 확증(validate)될 수 있는 컴포넌트, 포트 및 와이어 상의 구성 파라미터(configuration parameter)들에 대한 XSD이다. - setting a XSD schema for the design process (design-time) confirm (validate) components, ports, and configuration parameters on the wire (configuration parameter) that can be on.

- 배포 스키마는 컴포넌트, 포트, 또는 와이어가 설치되려면 어느 설치 파라미터들이 설정될 필요가 있는지를 표현하는 XSD이다. - XSD schema is deployed to express the need to be sure that any installation parameters are set in order to install a component, port or wire. 이 목록은 Fusion 또는 그 밖의 어떠한 설치자(installer) 기술에 대한 스키마일 수 있다. This list can be a schema for Fusion or any other installer (installer) technology.

- 포트 Classes Allowed는 컴포넌트 및 와이어가 선언(declare)된 포트 클래스를 참조함으로써 허용 가능한 포트를 선언하는 위치이다. - Allowed Classes port is a location that declares the allowable port by referring to the component and the wire declaration (declare) the effort class.

클래스 스키마에 대한 더욱 상세한 정보를 얻고자 하면 http://big에 있는 SDM 스키마 설계 사양을 참조하면 된다. If you want to get more detailed information about the schema class http: If you are referring to SDM schema design specification in the // big.

클래스 관계들 The class relationships

다른 컴포넌트들을 호스팅할 수 있는 컴포넌트, 포트 또는 와이어는 설치자 및 자신이 호스팅할 수 있는 컴포넌트 클래스를 식별하는 hostRelations 스키마를 사용하여 선언된다. That can host other components, component, port or wire is declared using a hostRelations schema that identifies the component class that can be installer, and their hosts. hostRelations 요소는 컴포넌트들, 포트들 또는 와이어들 중 하나가 다른 것들에 대한 호스트로서 작동하고 있는 클래스들 간의 방향성 링크로 생각될 수 있다. hostRelations elements can be thought of as a directional link between the class and act as a host for one of the wires or components, ports others.

컴포넌트를 호스팅한다는 것은 컴포넌트의 코드에 대한 실행 환경을 제공하는 것을 의미한다. That hosts the component is meant to provide an execution environment for the code of the component. 예를 들어, 아래에 예로서 도시된 바와 같이 SQL은 클래스 Database에 대한 호스트일 수 있다. For example, SQL, as illustrated by way of example below may be a host for a Class Database.

<hostRelations> <HostRelations>

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

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

</hostRelations> </ HostRelations>

SDM 유형들 The SDM Type

SDM이 자원, 애플리케이션 및 인스턴스를 모델링하는 3가지 별개 스페이스들이 있다. There are three distinct spaces that the SDM model the resources, applications and instances. 인스턴스 스페이스는 본 명세서에서 나중에 설명된다. Instance space is described later herein. 자원 스페이스는 그 스페이스에서 클래스들이 살아 있고, 클래스들이 애플리케이션들이 구성되는 재료가 되는 빌딩 블럭들인 곳이다. Resources, space and class are living in the space, the classes, which are building blocks that is where the material that applications are configured. 애플리케이션 스페이스는 유형들이 존재하는 곳이다. Application space is where you type exist. 아래는 포트, 와이어 및 컴포넌트 유형들에 대한 XML의 일예이다. Below is an example of the XML for the port, wire and component types.

<portType name="UserDataServer" class="ServerDataAccess"> <PortType name = "UserDataServer" class = "ServerDataAccess">

<deployment /> <Deployment />

<setttings /> <Setttings />

</portType> </ PortType>

<wireType name="UserData" class="DataConnection"> <WireType name = "UserData" class = "DataConnection">

<deployment /> <Deployment />

<settings> <Settings>

<useSSL>false</useSSL> <UseSSL> false </ useSSL>

</settings> </ Settings>

<portTypeRefs> <PortTypeRefs>

<portTypeRef name="UserDataServer"/> <PortTypeRef name = "UserDataServer" />

<portTypeRef name="UserDataClient"/> <PortTypeRef name = "UserDataClient" />

</portTypeRefs> </ PortTypeRefs>

</wireType> </ WireType>

<componentType name="SQLBackEnd" class="Database"> <ComponentType name = "SQLBackEnd" class = "Database">

<deployment> <Deployment>

<sqlScriptFilePath>%install%\mydatabaseDfn.sql</sqlScriptFilePath> <SqlScriptFilePath>% install% \ mydatabaseDfn.sql </ sqlScriptFilePath>

</deployment> </ Deployment>

<settings> <Settings>

<databaseName>UserData</databaseName> <DatabaseName> UserData </ ​​databaseName>

</settings> </ Settings>

<ports> <Ports>

<port name="UserData" type="UserDataServer"/> <Port name = "UserData" type = "UserDataServer" />

</ports> </ Ports>

</componentType> </ ComponentType>

SDM 스키마에서 portType, wireType 및 componentType 각각은 설정 및 배포 값들을 가진다는 것에 주의해야 한다. In the SDM schema each portType, wireType and componentType should note that has a set value and distribution.

- 설정은 컴포넌트, 포트 및 와이어에 대한 구성값을 제공하는 설정 스키마에 대한 XML이고, 설계 시에 유효성이 검증될 수 있다. - setting an XML schema that provides for setting the configuration values ​​for components, ports and wires, it can be validated at design time.

- 배포는 컴포넌트, 포트, 또는 와이어가 제대로 설치하기 위해 설정될 필요가 있는 구성 파라미터의 값을 표현하는 배포 목록에 대한 XML이다. - Distribution is an XML representation of the distribution list to the values ​​of the configuration parameters that need to be set in order to properly install the component, port or wire.

유형들에 대한 더욱 상세한 정보를 얻고자 하면 http://big에 있는 SDM 스키마 설계 사양을 참조하면 된다. If you want to get more detailed information on the type http: will you see the SDM schema design specification in the // big.

복합 컴포넌트 Composite Components

애플리케이션 및 그것의 다른 컴포넌트들, 포트들 및 와이어들에 대한 토폴로지적인 관계를 정의하기 위해 복합 컴포넌트들이 사용될 수 있다. There are a composite component can be used to define the topological relationship to the application and its different components, ports and wires. 복합 컴포넌트들은 관련 구현을 갖지 않으며, 대신에 포트들의 위임 및 호스트 관계들을 사용 하여 포트들과 멤버 컴포넌트들의 행동을 드러낸다. Composite components do not have a specific implementation, using the ports delegates and host relationships, instead of revealing the behavior of port and component members. 아래의 XML은 복합 컴포넌트 MyService가 SDM을 사용하여 어떻게 기술될 수 있는지를 도시한다. XML below shows a composite component that MyService how technology can be used by the SDM.

<compoundComponentType name="MyService"> <CompoundComponentType name = "MyService">

<components> <Components>

<component name="MyFrontEnd" type="IISFrontEnd" /> <Component name = "MyFrontEnd" type = "IISFrontEnd" />

<component name="MyBackEnd" type="SQLBackEnd" /> <Component name = "MyBackEnd" type = "SQLBackEnd" />

</components> </ Components>

<wires> <Wires>

<wire name="data" type="UserData"> <Wire name = "data" type = "UserData">

<members> <Members>

<member componentName="MyFrontEnd" portName="serverData" /> <Member componentName = "MyFrontEnd" portName = "serverData" />

<member componentName="MyBackEnd" portName="userData" /> <Member componentName = "MyBackEnd" portName = "userData" />

</members> </ Members>

</wire> </ Wire>

</wires> </ Wires>

</compoundComponentType> </ CompoundComponentType>

인스턴스 Instances

컴포넌트, 포트 및 와이어는 애플리케이션/서비스의 구조 및 행동을 정의하 지만, 실행되는 인스턴스를 정의하지는 않는다. But to define the component, port and wire structure and behavior of the application / services, it does not define the instance is running. 매 구성요소, 포트 및 와이어 타입 선언은 하나 또는 그 이상의 인스턴스를 가질 수 있다. Every component, port and wire type declaration may have one or more instances. 인스턴스들은, 물리적 자원(서버, 네트워크 스위치 포트 및 디스크)이 할당되고 소프트웨어 자원(운영 체제, 런타임 호스트, 애플리케이션 코드)이 설치 및 구성되도록 애플리케이션/서비스를 배포한 결과이다. Instances, the result of physical resources (servers, network, switch ports, and disk) deploy applications / services to be assigned and software resources (operating systems, run-time host, application code) to install and configure.

모든 인스턴스들을 생성시부터 삭제시까지 추적하는 것은 SDM 런타임이 할 일이다. It is a day to the SDM runtime to track all instances until removed from the time of creation.

SDM 런타임 SDM runtime

SDM 런타임은 그 자신이 컴포넌트, 포트 및 와이어의 인스턴스들을 생성하지는 않고, 대신 SDM 인스턴스들의 생성 및 관리를 조정하는 데 사용되는 일단의 API들을 제공한다. SDM runtime that they do not generate the components, an instance of the port and the wire, instead of providing one end of the API used to control the creation and management of the SDM instance. 웹 서비스 컴포넌트에 대한 호스트로서 IIS와 함께 Windows Server를 실행시키는 서버와 같이, 인스턴스를 실제로 생성하는 데에는 통상적으로 복수의 엔티티가 관련되며, 완료되기까지는 수시간 또는 수일이 걸릴 수 있다. As a host for the Web service component, such as a server that is running Windows Server with IIS, There are actually creating an instance is usually associated with a plurality of entities, which can take hours or days until it is completed.

SDM 런타임은 언제 "SDM 인스턴스 생성" 프로세스가 개시되고, 언제 성공 또는 실패로 종료될지를 알고 있다. SDM runtime will know whether and when "SDM instance creation" process is initiated, and when exits with success or failure. 또한 SDM 런타임은 SDM 인스턴스에 대하여 그 존속 기간(lifetime)동안 어떤 변경이 가해져야 하는지를 알고 있다. Also I know how SDM runtime will be no change is applied during the duration (lifetime) with respect to SDM instances. SDM 런타임은 지정된 SDM과 관련된 인스턴스들에 관한 정보에 대하여 질의(query)를 받을 수 있도록 소정의 애플리케이션/서비스와 관련된 모든 트랜잭션(transaction)들을 기록하는 어카운턴트(accountant)라고 간주될 수 있다. SDM runtime can be considered a word count consultants (accountant) to record all transactions (transaction) associated with a given application / service that can be queried (query) for information about the instances associated with a given SDM.

SDM 인스턴스를 생성하는 제1 단계는 애플리케이션/서비스 SDM을 SDM 런타임 으로 등록하는 것이다. A first step of generating the SDM instance is to register the application / service SDM to the SDM runtime. 일단 SDM 런타임이 주어진 SDM을 알게 되면, 인스턴스 생성 프로세스가 팩토리(Factory)들과 자원 관리자(Resource Manager; 이하 설명할 것임)들을 이용하여 호출될 수 있다. Once the SDM runtime find a given SDM, instance creation process, the factory (Factory) and resource managers; could be called using (Resource Manager will be described below).

API 및 런타임 설계에 관한 더욱 상세한 정보를 얻기 위해서는 http://big/에 있는 SDM 런타임 아키텍처 사양을 참조하면 된다. To get more detailed information about the API and runtime designed to http: Referring to the SDM Runtime Architecture specification on // big /.

호스트 및 팩토리(Hosts and Factories) Hosts and Factories (Hosts and Factories)

다른 컴포넌트들을 "호스팅"할 수 있는 컴포넌트는 호스트라고 불리며, 이들이 지원하는 클래스들에 대한 팩토리로서 작용한다. It referred to other components as components that can "host" is a host acts as a factory for the classes they support. 컴포넌트는 앞서 설명한 SDM 스키마의 hostRelations 요소를 이용하여 하나 또는 그 이상의 컴포넌트 클래스들의 호스트로서 선언될 수 있다. Component may be declared as the host of one or more component classes using hostRelations elements of the SDM schema described above.

호스트는 컴포넌트의 코드를 위한 실행 환경을 제공하지만, 팩토리는 소정 타입의 SDM 인스턴스들을 생성하고 SDM 런타임 API들을 통해 SDM 런타임과 상호작용하는 실제 서비스이다. The host provides the execution environment for the code component, but the factory is an actual service generating SDM instance of a certain type, and interact with the SDM runtime via the SDM runtime API. 팩토리는 하나 이상의 컴포넌트 클래스를 지원할 수 있고, 어느 컴포넌트 클래스가 지원되는지를 지정하는 SDM 런타임으로 등록해야 한다. Factories must register with the SDM runtime that can support more than one component class, which specifies whether the component class support.

소정의 팩토리는 상이한 구성을 갖는 동일한 타입의 호스트를 복수 개 지원할 수 있고, 또한 개개의 팩토리는 호스트 구성의 타입 각각에 대하여 존재할 수도 있다. Predetermined factory may support a plurality of hosts on the same type having different configurations, and each of the factory may be present with respect to each type of host configuration. 예컨대 IIS 팩토리는 웹 서비스 및 웹 애플리케이션과 같은 복수의 클래스를 지원할 수 있다. For example, IIS Factory can support multiple classes, such as web services and web applications. 마찬가지로, SQL 팩토리는 데이터베이스, 분할된 데이터베이스(Partitioned Database) 및 고가용 데이터베이스(Highly Available Database)와 같은 상이한 데이터베이스 타입을 지원할 수 있다. Similarly, SQL factory may support a different type of database, such as a database, the database partitioning (Partitioned Database) and high availability database (Highly Available Database).

팩토리는 기억장치(storage), 네트워크 및 서버와 같은 물리적 자원을 그 자신이 관리하지는 않는다. Factory storage (storage), physical resources such as network and server does not have its own management. 팩토리는 자원 관리자를 통해 물리적 자원(그리고 이들의 논리적 등가물)과 상호작용한다. Factory interacts with the physical resources (and their logical equivalents) by the resource manager.

자원 관리자 Resource Manager

자원 관리자는 (1) 부트스트랩(bootstrap) 프로세스의 일부로서 발견(discover) 또는 생성되거나, (2) 물리적 환경의 소정의 선언적 XML 기반의 기술을 통해 지정된 물리적 및 논리적 자원을 관리한다. The resource manager (1) a bootstrap (bootstrap), or as part of a discovery process (discover) or generated, (2) manages the physical and logical resources assigned through a predetermined declarative XML-based description of the physical environment. 자원 관리자는 모든 기억장치, 네트워크 및 서버 자원을 보유하며, 공통의 자원 관리 API를 공개하여 자원 할당 요청을 처리하고 이러한 자원들의 소유권(ownership)을 추적한다. The resource manager reserves all storage devices, network and server resources, and to disclose a common resource management API handles the resource allocation request and track title (ownership) of these resources.

자원 관리자의 예는 NRM(Network Resource Manager), SRM(Storage Resource Manager) 및 PRM(PC Resource Manager)이다. Examples of resource managers are NRM (Network Resource Manager), SRM (Storage Resource Manager) and PRM (PC Resource Manager). 이들 자원 관리자들 각각은 물리적 포트나 디스크 또는 서버 및 이들이 공개하는 VLAN, 논리적 디스크 볼륨(logical disk volumes), 공유 파일(file shares), 웹 서버 등과 같은 논리적 자원의 할당을 담당한다. Each of these resources manager is responsible for the allocation of resources, such as physical port or logical disk or server, and VLAN to which they are released, the logical disk volume (logical disk volumes), file sharing (file shares), the web server. 자원 관리자는 또한 할당 및 해제(de-allocation)를 달성하도록 물리적 장치들을 프로그래밍하는 역할을 한다. The resource manager also serves to program the physical device to achieve the allocation and release (de-allocation).

물리적 하드웨어를 프로그램하기 위해, 자원 관리자는 하드웨어 장치의 구현 세부 사항을 숨기고 있는 자원 제공자들을 통해 하드웨어와 상호작용함으로써, 예컨대 복수의 벤더로부터 제공된 네트워크 스위치들이 서로 바뀌어 쓰일 수 있도록 한다(제조자의 장치에 대한 제공자가 존재하는 경우). To program the physical hardware, the resource manager so by interacting with the hardware through a resource provider that hides the implementation details of the hardware device locations, such as to the network switch is provided from a plurality of vendors can be used interchangeably (for the producer device If the provider is present). Windows의 하드웨어 추상화 계층(HAL; hardware abstraction layer) 및 장치 드라이버 모델과 마찬가지로, 서버, 네트워크 및 저장 장치에 이르는 데이터 센터 환경에 대해서도 동등한 추상화 계층이 존재한다. Windows hardware abstraction layer; as well as (HAL hardware abstraction layer) and device driver model, and even the server and data center environments, ranging from network and storage devices, there is an equivalent abstraction layer.

계층 및 매핑 Hierarchy and Mapping

컴포넌트, 포트 및 와이어는 호스트, 팩토리, 자원 관리자 및 SDM 런타임과 결합되는 경우 강력한 추상화이지만, 이들은 분산형 애플리케이션/서비스를 배치 및 관리하기에는 충분하지 않다. If a component, port and wire bonding with the host, factories, resource managers and the SDM runtime, but powerful abstraction, they are not sufficient to deploy and manage distributed applications / services. 이러한 논리적 추상화의 물리적 인스턴스를 생성 및 관리하기 위해서는, 어떠한 추가적인 구축물(construct)이 필요하다. In order to create and manage the physical instances of such logical abstraction, it is no need for additional constructs (construct). 이러한 추가적인 구축물은 계층 및 매핑이다. These additional structures are hierarchical and mapping.

계층 hierarchy

계층에 대한 필요는 애플리케이션/서비스의 배치 요건(deployment requirement)들을 설계시에 확증하고자 하는 욕구가 그 동기가 된다. The need for a hierarchy that needs to be confirmed at the time of designing the layout requirements (deployment requirement) of the application / service that is motivated. 도 3은 SDM에 의해 정의된 계층 추상화를 나타내고 있다. 3 shows a layer of abstraction defined by the SDM.

- 애플리케이션 계층은 분산 가능한 컴포넌트, 이들의 배치 요건 및 제한(constraints), 그리고 이들의 통신 관계(communication relationship)를 애플리케이션/서비스의 맥락에서 기술한다. - the application layer will be described in the context of the dispersible component, and their placement requirements and the limits (constraints), and the applications / services in their communication relationships (communication relationship).

- 호스트 계층은 다른 것들 중에서도 IIS, CLR 및 SQL과 같은 호스트에 대한 구성 및 정책(policy) 설정 및 제한을 기술한다. - Host layer describes the configuration and policy (policy) and setting limits on the host, such as IIS, CLR and SQL, among other things.

- 가상 데이터 센터(VDC; Virtual Data Center) 계층은 운영 체제로부터 네트워크 토폴로지(topology)를 통해 서버, 네트워크 및 저장 장치에 이르기까지의 데이터 센터 환경 설정 및 제한을 기술한다. - virtual data center (VDC; Virtual Data Center) layer from the operating system and technology data center preferences and restrictions leading up to the server, network and storage through a network topology (topology).

- 하드웨어 계층은 물리적 데이터 센터 환경을 기술하고, 이는 발견되거나 예컨대 XML을 이용하여 선언적 방식으로 지정된다. Hardware layer describes the physical data center environments, it is detected, or for example using XML is specified in a declarative manner. 이 계층은 스케일 불변이 아니므로 SDM에서 모델링되지 않으나, 완전함을 위해 포함되었다. This layer is included, but not for model scale in the SDM is not a constant, complete.

매핑(Mappings) Mapping (Mappings)

SDM이 계층화되어 있으므로, 다양한 계층을 바인딩(binding)할 필요가 존재한다. Because SDM is layered, there is a need to bind (binding) the various layers. 매핑은 본질적으로 어떤 계층에 있는 컴포넌트 또는 포트를 아래의 다음 계층에 있는 컴포넌트 또는 포트와 바인딩한 것이다. Mapping is essentially bound to the component ports or in any layer or components and ports in the next layer below. 매핑은 다음과 같이 기술될 수 있다. 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 T = [T n -> T n-1] + [T n-1 -> T n-2] + [T n-2 -> T n-3] + [...]

여기서 M은 컴포넌트, 포트, 또는 와이어를 나타내며, n은 계층을 나타낸다. Where M represents the components, ports, or wire, n represents a hierarchy. 화살표는 매핑의 방향을 나타내며, 항상 높은 계층으로부터 낮은 계층 쪽으로 향한다. The arrows indicate the direction of the map, all the time directed towards the lower layer from the higher layer.

예컨대, 도 4에서 MyFrontEnd라는 이름의 애플리케이션 계층에 있는 컴포넌트는 IIS라 불리는 호스트 계층에 있는 컴포넌트에 매핑된다. For example, in Fig. 4, the components in the application layer named MyFrontEnd is mapped to a component at the host layer called IIS. 마찬가지로 MyBackEnd라는 이름의 컴포넌트는 호스트 계층에 있는 SQL 컴포넌트에 매핑된다. Similarly named MyBackEnd components are mapped to SQL component in the host layer.

설계시 유효성검증(Design-time Validation) Design Validation (Design-time Validation)

컴포넌트와 아래쪽 계층에 있는 그 컴포넌트의 호스트 컴포넌트 사이의 바인딩은, 애플리케이션/서비스가 실제로 라이브 데이터 센터(live data center)에 배 치되기 전에 개발자에게 문제를 안겨줄 수 있다. Binding between the components of the host component in the component and the lower layer, application / services may actually favor this problem to the developers before they placed in a live data center (live data center). 이러한 문제는 타입의 비호환, 구성의 충돌(conflict), 동작의 불일치(mismatch), 토폴로지 관계(topological relationship)의 결여 등에 기인한 것일 수 있다. This problem can be caused such as the absence of incompatibilities, configuration conflicts (conflict), inconsistency of behavior (mismatch), the topology relationship (topological relationship) of the type. 도 5는 컴포넌트와 입증에 관한 그것의 호스트 간의 설정 및 제한 체크 에러를 도시한다. Figure 5 shows a set up and limit check error between its host on the components and demonstrated.

도 6에서, 다이어그램으로 도시된 매핑 시도는 오류를 낳을 수 있는 바, 배포 계층에 있는 IIS 및 SQL 컴포넌트 사이에는 잠재적인 통신 관계가 존재하지 않기 때문이다. In Figure 6, it mapped the city to try the diagram is that the bar can lead to errors between IIS and SQL components in the distribution hierarchy is not a potential communication relationship exists.

MyBackEnd 컴포넌트로부터 SQL 호스트 컴포넌트로의 매핑은 컴포넌트 및 호스트 타입의 호환성이 있고 구성 충돌이 없다는 점에서 유효한 바인딩이었을 수 있지만, MyFrontEnd와 지정된 배포 계층에 존재하지 않는 MyBackEnd 사이의 토폴로지 관계를 MyServiceSDM이 정의하였으므로 이는 유효하지 않다. Mapping from MyBackEnd components to SQL host component which hayeoteumeuro defined MyServiceSDM the topology relationship between nonexistent in, MyFrontEnd a specified distribution layer may have been a valid binding in that the compatibility of the components and the host type, and there is no configuration conflicts MyBackEnd not valid.

설정 및 제약 체크(Settings and Constraints Checking) Check settings and restrictions (Settings and Constraints Checking)

애플리케이션 계층으로부터 배치 계층(그리고 기타 등등)으로 매핑할 수 있는 능력은, 호스트의 제한에 대하여 컴포넌트의 설정을 설계시에 확증할 수 있도록 해 주고, 또한 컴포넌트의 제약에 대하여 호스트의 설정을 확증할 수 있도록 해 주므로 상당히 강력하다. The ability to map in a batch layer (and so on) from the application layer, send it to confirm the settings of the components in the design with respect to the restriction of the host, you can also confirm the setting of the host against the constraints of the component because it is so extremely powerful.

도 7은 상이한 계층에 있는 컴포넌트들 및 호스트 사이의 관계를 더욱 상세히 나타내고 있다. 7 shows in more detail the relationship between the components and the host in the different layers. 이 도면에서, VDC 계층에 이르기까지 쭉, 어떤 계층에 있는 컴포넌트와 아래의 다음 계층에 있는 호스트 컴포넌트간에 바인딩이 존재함에 주목하자. Note As in the drawing, all the way down to the VDC layer, the binding between the host component in the following hierarchy of components and down in any hierarchy exists.

도 7에서, MyFrontEnd는 IIS에 의해 호스팅되는 웹 서비스이며, IIS는 윈도우 서버에 의해 호스팅되는 윈도우 애플리케이션(Windows Application)이다. In Figure 7, MyFrontEnd is a web service that is hosted by IIS, IIS is a Windows application (Windows Application) that is hosted by Windows Server. IIS 및 SQL의 인스턴스들의 생성 및 삭제를 담당하는 윈도우 애플리케이션 팩토리가 존재하는 것과 마찬가지로, 웹 서비스 및 웹 애플리케이션 컴포넌트의 인스턴스들의 생성 및 삭제를 지원하는 IIS 팩토리가 존재한다. Similar to the Windows Application Factory, which is responsible for the creation and deletion of instances of SQL and IIS is present, there is a factory that IIS supports the creation and deletion of instances of web services and web application components.

도 8은 앞서 설명한 SDM 설정 및 제한 시멘틱(semantics)을 이용하여 상이한 계층에 있는 컴포넌트들 사이에서 설계 시 확증이 어떻게 동작하는지를 나타내고 있다. 8 shows using the SDM set and limited semantics (semantics) previously described how the confirmation in design among the components in the different layers operation.

여기서 위쪽 계층에 있는 컴포넌트의 제약은 아래쪽 계층에 있는 호스트 컴포넌트의 설정에 대하여 유효성이 검증됨에 주목하자. The pharmaceutical component in the upper layer Notice As validated against a set of host components in the lower layer. 또한 호스트 컴포넌트의 제약은 호스팅될 컴포넌트의 설정에 대하여 유효성이 검증됨에 주목하자. Also Note As the constraints of the host component is validated against a set of components to be hosted.

양방향 설정 및 제약 체크는 개발자로 하여금, 아래 방향으로 쭉 SDM 시멘틱을 이용하여 기술된 동작 환경의 맥락에서 자신의 애플리케이션/서비스를 신뢰성있게 개발할 수 있도록 해 준다. Interactive settings and check constraints gives it allows the developers to make in the context of the technology all the time using SDM semantics downward reliable operating environment to develop your own applications / services. 개발 프로세스 도중 데이터 센터에 관한 기술(description)이 신뢰받을 수 있도록 데이터 센터를 기술하기 위해서는, VDC(Virtual Data Center)라 일컬어지는 데이터 센터의 추상화를 생성할 필요가 있다. In order to describe the data center to help technology (description) of the data center during the development process it can not be trusted, it is necessary to create an abstraction of the data center, which is referred to as (Virtual Data Center) VDC.

가상 데이터 센터(VDC) Virtual Data Center (VDC)

VDC는 개발자가 데이터 센터를 보는 시점을 간략하게 해 주는 물리적 데이터 센터 환경의 논리적 표현이다. VDC is a logical representation of the physical data center environment that briefly when the developer looks at the data center. 이상적으로 IT 전문가 또는 설계자(Architect)는 개발자가 분산형 애플리케이션/서비스를 기술할 수 있는 스케일 불변 방식과 동일한 방식으로 데이터 센터를 기술할 수 있어야 한다. Ideally, IT professionals or architects (Architect) should the developer to describe the data center in the same manner and scale invariant way to describe distributed applications / services. VDC는 데이터 센터 내의 서버, 네트워크 및 저장 자원 및 이들의 토폴로지 관계의 추상화인 것으로 간주될 수 있다. VDC can be regarded as an abstraction of server, network and storage resource topologies and their relationships within the data center. 통상적인 데이터 센터의 도표(diagram)는, 복수의 상호 연결된 서버, 네트워크 장비, IP 주소, VLAN, 운영 체제, 저장 장치 등이 Visio나 유사한 도구를 이용하여 그린 단일 도표상에 모두 표현되어 상당히 복잡하다. Chart (diagram) of a typical data center, a plurality of interconnected servers, network equipment, IP address, VLAN, operating systems, storage devices, such as the use Visio or similar tool is expressed both in the green on the single chart is fairly complicated . 이 도표에 추가하여, 데이터 센터가 어떻게 분할, 구성 및 관리되는지를 정확히 규정(prescribe)하는 통상적으로 긴 문서가 존재한다. In addition to the Figure, there is typically a long document that exactly defined (prescribe) how the data center split, configuration and management.

이러한 복잡함의 예로서는 MSA(Microsoft Systems Architecture) EDC(Enterprise Data Center)가 있다. An example of such a complex has (Enterprise Data Center) (Microsoft Systems Architecture) MSA EDC. 업데이트(update) 및 업그레이드(upgrade)가 적용됨에 따라 데이터 센터의 상태를 반영하여, 손으로 그린 도표 및 문서를 최신으로 유지하는 것은 불가능한 것은 아니더라도 비용이 많이 드는 일임이 분명하다. Reflecting the state of the data center, according to the update (update) and upgrades (upgrade) is applied, it is impossible to maintain a hand-drawn graphics and documents up to date it is clear that, if not discretionary and costly. 마찬가지로, 문서의 규정 사항에 대하여 환경의 유효성을 검증하는 것은 어려울 뿐만 아니라 사람에 의한 오류가 발생할 수 있다. Likewise, in order to validate the environment with respect to the requirements of this article it may occur, as well as errors caused by difficult people.

스케일 불변 방식으로 MSA EDC와 같은 복잡한 데이터 센터를 표시하는 능력은 설계자 및 IT 전문가 모두에게 매우 강력한 것이다. Scale approach to the immutable ability to display complex data centers, such as the MSA EDC is very powerful for both designers and IT professionals. 데이터 센터를 컴포넌트, 포트 및 와이어로 기술할 수 있는 능력은, 오늘날의 설계 및 배포 프로세스에서 결여되어 있는 배포 요건의 모델링 및 유효성 검증이 가능한 강력한 프레임워크를 제공한다. The ability to describe data center components, ports and wires, provides a powerful modeling and validation framework capable of deployment requirements that are lacking in today's design and deployment process.

SDM 원리 SDM principles

SDM은: The SDM:

- 분산형 애플리케이션들/서비스들을 설계하는 것을 보다 쉽게 하는 추상화를 정의한다. - Define abstractions easier to design of distributed applications / services.

- 운영 실시의 자동화 및 재사용을 위한 프레임워크를 가능하게 한다. - allow a framework for the automation and reuse of operations conducted.

- 분산형 애플리케이션 및 서비스들의 운영 및 배포를 단순화한다. - simplifies the administration and deployment of distributed applications and services.

오늘날 서비스의 오퍼레이터 부근의 벽 상에서 복잡한 다이어그램으로서 흔히 보여지는 것을 캡쳐하는 것을 고려함으로써, SDM이 무엇인지를 이해하는 것이 더 쉬워질 수 있다. By considering that capture that is often viewed as a complex diagram on the wall in the vicinity of today's service operator, it may be easier to understand if what the SDM. 이들 다이어그램에서, 박스는 일반적으로 서비스의 실행 요소를 나타내며, 박스들을 연결하는 선들은 서비스 요소들 간의 통신 경로를 나타낸다. In these diagrams, the box is generally denotes the execution of the service element, the lines connecting the boxes represents a communication path between the service components. 예를 들어, 다시 하나 이상의 중간-층(middle-tier) 또는 백-엔드 서비스들에 연결되는 일부 IIS 프론트-엔드 기계들에 연결된 로드 밸런서(load balancer)가 있다. For example, one or more intermediate back - a load balancer (load balancer) attached to the machine end of the layer (middle-tier), or a back-end service to some IIS front connected to.

SDM에 대하여 생각하는 또다른 방법은 SDM은 분산형 애플리케이션/서비스의 동작에 대한 메타-모델(meta-model)과 컴퓨팅 환경에서 실행하는 애플리케이션/서비스의 "생생한" 청사진 모두라는 것이다. Another way to think about the SDM The SDM metadata about the operations of distributed applications / services - will be a "live" blueprint of all applications / services run on the model (meta-model) and the computing environment. 가능한 소프트웨어 동작들을 포함하여, 선언적이고 스케일-불변의 방식으로, SDM은 컴퓨팅 환경에서 애플리케이션의 구조를 캡처한다. Including the software operation, declarative and scale-invariant in the manner of, SDM captures the structure of the application in a computing environment. 하드웨어와 네트워크 자원 간의 바인딩을 포함하여 서비스의 토폴로지 및 소프트웨어 컴포넌트의 유효한 동작들을 선언적으로 기술하는 능력은 매우 강력하다. The ability to declaratively described as the effective operation of the service topology and software components, including the binding between the hardware and network resources is very powerful.

유사한 것으로서, Microsoft의 Common Object Model(COM)을 살펴보자. As similar to, let's look at Microsoft's Common Object Model (COM). COM 은 컴포턴트들이 어떻게 패키지되고, 등록되고, 활성화되고, 발견되는지 등을 표준화하였다. COM is standardized, etc., and how the component package consultant, registered and, being active, if found. COM은 라이프타임, 메모리 관리, 및 인터페이스 구현에 관한 엄격한 룰들을 명령한다. COM commands the strict rules regarding lifetime, memory management, and interface implementation. 이들 원형(primitives)은, 컴포넌트들이 블랙 박스로서 처리될 수 있도록 하기 때문에, 정보처리 상호운용(interoperability)에 필수적이다. These circular (primitives) is, because it allows components to be treated as a black box, is essential for Interoperability (interoperability). COM은 이벤팅, 자동화 및 OLE와 같은 보다 정교한 서비스들을 위한 기초이다. COM is the basis for more sophisticated services such as eventing, automation, and OLE.

마찬가지로, SDM은 보다 정교한 특성을 만들기 위한 일부 기본 원형들을 정의하는 것을 필요로 한다. Similarly, SDM requires you to define some basic prototype for creating more sophisticated features. 이들 원형들은: These are circular:

- 컴포넌트 - 구현, 배포 및 관리의 유닛 - the component-units of implementation, deployment and management

- 포트 - 관련 유형 및 유효한 동작들의 집합을 가지는 지정된 종단점 - port-related type and the specified endpoint has a set of effective operation

- 와이어 - 포트들간의 허용되는 통신 경로 - Wire communication is allowed between the port channel

- 계층 - 자원 관리 소유권 및 바인딩의 분리 - tier-resource management, separation of ownership and binding

- 맵핑 - 각 계층에서 컴포넌트, 포트 및 와이어 간의 바인딩 - Mapping-binding between components, ports and wires in each layer

본 명세서의 나머지는 이들 원형들 각각을 보다 상세하게 설명할 것이다. The rest of this specification will describe in more detail these circular each.

컴포넌트, 포트 및 와이어 Components, ports, and wire

본 명세서의 목적을 위하여, 컴포넌트, 포트 및 와이어를 사용하여 그려진 MyService라고 불리는 단순한 서비스의 그래픽적인 표현을 고려하는 것이 유용하다. For the purposes of this disclosure, it is useful to consider a graphical representation of a simple service called MyService drawn using the components, ports, and wires. 도 2에서, 박스들은 컴포넌트들을 나타내고, 다이아몬드들은 포트들을 나타내며, 파선은 와이어들을 나타낸다. In Figure 2, boxes represent components, diamonds represent ports, and the broken line represents the wire.

- MyService는, MyFrontEnd와 MyBackEnd라는 컴포넌트들을 사용하기 때문에 복합 컴포넌트이다. - MyService is a composite component due to the use of components of the MyFrontEnd MyBackEnd.

- MyService는 MyFrontEnd 컴포넌트에 의해 구현된 위임 포트(delegated port)인 web이라고 불리는 하나의 가시적 포트를 가진다. - MyService has one visible port called a web delegated port (delegated port) implemented by MyFrontEnd component.

- MyFrontEnd는 2개의 포트, 즉 위임 포트와 catalog라고 라벨이 붙은 포트를 가진다. - MyFrontEnd has two ports, i.e. a port is attached to the label that delegation ports and catalog.

- MyBackEnd는 data라고 라벨이 붙은 하나의 포트를 가진다. - MyBackEnd is that having a port labeled data.

- MyFrontEnd와 MyBackEnd 컴포넌트들은 catalog 포트와 data포트를 와이어를 통하여 묶는 잠재적인 통신 관계를 가진다. - MyFrontEnd and MyBackEnd components have the potential to tie a communication relationship via a wire to catalog port and data port.

컴포넌트 component

컴포넌트들은 구현, 배포 및 관리의 유닛들이다. Components are units of implementation, deployment and management. 컴포넌트들의 예들은 Windows Server를 실행하는 전용 서버, IIS 가상 웹 사이트 또는 SQL 데이터베이스이다. Examples of components a dedicated server, IIS virtual Web site or the SQL database that is running Windows Server. 컴포넌트들은 일반적으로 기계 경계를 가지나, 단일 서버 상에서 호스팅되는 다수의 IIS 가상 웹 사이트들에 의해 증명되어질 것을 요청되지는 않는다. Components are typically gajina machine boundaries, but are not asked to be proved by the large number of IIS virtual Web site that is hosted on a single server.

컴포넌트들은 포트들을 통하여 기능들을 공개하며, 와이들을 통하여 통신한다. Components are also disclose the functions through the port and communicates through wires. 단순한 컴포넌트들은 단지 멤버들로서 포트들을 가질 수 있다. Simple components can only have the ports as members. 다른 컴포넌트들을 사용하는 컴포넌트들은 복합 컴포넌트(compound component)라고 불리며, 다른 컴포넌트들에 덧붙여 포트들과 와이어들을 가질 수 있다. Components using other components are referred to as a composite component (compound component), in addition to the other components may have the port and wire.

복합 컴포넌트들은 합성을 통하여 생성되며, 그와 관련된 어떠한 구현도 가지지 않는다. Composite components are produced by a synthetic, it does not have any implementation associated with it. 복합 컴포넌트 포트들은 내부 컴포넌트들로부터의 위임 포트들이다. Composite component ports are the ports of the delegation from the internal components. 복합 컴포넌트들은 배열(collocation), 캡슐화(encapsulation) 및 재사용을 가능하게 하며, 따라서 애플리케이션/서비스 및 그 행동을 조직화하는 하나의 방법으로 생각될 수 있다. Composite components are also enables the arrangement (collocation), encapsulated (encapsulation) and re-use, and thus may be thought of as a way to organize the applications / services and their behaviors.

컴포넌트의 단지 공용 포트들(public ports)만이 컴포넌트 외부에서 가시적이다. Only the only common port of the component (public ports) is visible from outside the component. 복합 컴포넌트들은 캡슐화를 통하여 자신이 사용하는 컴포넌트들의 내부 구조를 숨긴채 외부 세계에는 단순 컴포넌트들(simple components)로 보인다. Composite components outside world while hiding the internal structure of the components they use through encapsulation appears to be the simple component (simple components). 사실, 양자에 의해 지원되는 행동들과 포트 유형들이 완전히 동일하기만 하다면, 단순 컴포넌트는 복합 컴포넌트로 교체될 수 있으며, 그 역도 가능하다. In fact, if only the behavior that is supported by both the port type and are completely the same, simple component can be replaced by a composite component, and vice versa.

포트 port

포트들은, 관련 유형을 가지며 일반적으로 프로토콜 역할(protocol role)과 허용되는 동작들의 집합과 관련되는, 명명된 종단점(named end-points)이다. Ports, has a related type is typically protocol role (role protocol) operations, named end points (named end-points) according to a set of acceptable and. 포트들은 포트들의 예들은 허용되는 동작들의 집합을 가지는 SOAP 포트, HTTP 서버 포트 등이 있다. Ports include port SOAP, HTTP server port Examples of ports have a set of allowed operations. 포트들은 위임될 수 있는데, 이는 외부 컴포넌트가 내부 컴포넌트의 포트를 자신의 것인양 공개할 수 있다는 것을 의미한다. There are ports can be delegated, which means that the external component is a port of the internal components will be released in their salvage. 포트들은 하나의 컴포넌트에 대한 공용 인터페이스(행동)를 형성한다. Ports form a common interface (action) on the one component. 포트들은 공용으로(가시적으로) 될 수 있는 컴포넌트의 유일한 멤버들이다. Ports are the only members of the component can be (visually), public.

와이어 wire

와이어들은 포트들간의 허용되는 바인딩들이며, 포트들 (및 컴포넌트들) 간의 토폴로지적 관계를 나타낸다. Wires deulyimyeo acceptable binding between the port represents the topology relationship between the port (and components). 와이어들은 임의의 인스턴스 상호연결 토폴로지(instance interconnect topology)를 지정하지 않으며, 대신 인스턴스 상호연결 토폴로지를 위한 "잠재성(potentiality)"을 표현한다. Wires does not specify any instance interconnect topology (instance interconnect topology), instead expresses the "potential (potentiality)" for instance interconnection topology.

와이어들은 본질적으로 버스들이며, 하나 이상의 포트 멤버들을 포함할 수 있다. Deulyimyeo wires are inherently bus may include one or more port members. 와이어들은 포인트-투-포인트 관계로 오해되어서는 안 된다. Wire are point-to-point should not be misunderstood as a relationship-to. 주어진 포트는 동일한 와이어 내에서 한번 이상 나타날 수 없다. Given port can not occur more than once within the same wire.

스키마(Schema) Schema (Schema)

애플리케이션/서비스를 설명하기 위해서는, SDM을 위한 표준 스키마를 가질 필요가 있다. In order to explain the application / services, it is necessary to have a standard schema for the SDM. SDM 스키마는 XSD 및 XML 문법을 이용하여 표현될 수 있어야 한다. SDM schema must be represented by an XSD and XML syntax. SDM 스키마를 상세히 설명하는 것은 본 명세서의 범위를 벗어나는 것이지만, 본 명세서에서 이후에 설명할 주제를 위한 맥락으로서 간략한 설명을 하는 것이 필요하다. To explain in detail the SDM scheme is beyond the scope of this specification, it is necessary that a short description as a context for the subject to be described later herein. 이하는 SDM 스키마를 간략하게 나타낸 것이다. Below shows an overview of the SDM scheme.

<sdm> <Sdm>

<import /> <Import />

<identityReference /> <IdentityReference />

<information /> <Information />

<portImplementationType /> <PortImplementationType />

<wireImplementationType /> <WireImplementationType />

<componentImplementationType /> <ComponentImplementationType />

<hostRelations /> <HostRelations />

<portTypes /> <PortTypes />

<wireTypes /> <WireTypes />

<componentTypes /> <ComponentTypes />

</sdm> </ Sdm>

SDM 스키마에 대한 더욱 상세한 정보를 얻고자 하면 http://big/에 있는 SDM 스키마 사양(specification)을 읽고 샘플 XSD 파일을 검토하도록 한다. If you want to get more detailed information about the SDM schema http: read the SDM schema specification (specification) in // big / and to review sample XSD file.

유형(Types) Types (Types)

애플리케이션/서비스에서 사용되는 모든 컴포넌트, 포트 및 와이어(wire)는 유형이다. All components, ports and wires (wire) used in the application / service is a type. 유형은 본질적으로 C+ 및 C# 등과 같은 객체지향형 언어에서의 클래스에 상당하는 것이며, 클래스와 마찬가지로 새로운 유형은 기존의 유형들로부터 생성(create)될 수 있다. Type is essentially intended to correspond to the class in object-oriented languages ​​such as C + and C #, a new type just as a class can be (create) generated from existing types. 스케일 불변(scale-invariant) 스페이스는 SDM 스키마에서 portTypes, wireTypes 및 componentTypes로 나타내어진다. Scale invariant (scale-invariant) space is represented in a SDM scheme portTypes, wireTypes and componentTypes. 스케일 불변이라 함은, 컴포넌트, 포트, 또는 와이어는 실제의 데이터 센터에 이들 각각의 복수의 인스턴스가 존재하는 경우라 하더라도 애플리케이션/서비스 SDM에서 일단 표현될 수 있음을 의미한다. The term scale is unchanged, even if the components, ports, or wire is a plurality of instances of each of these to the actual data center, there will be means to be one expressed by the application / service SDM.

유형은 궁극적으로 구현 유형(implementation type)으로부터 파생되며, 이는 본질적으로 공통된 기술 특징에 대한 추상화(abstraction)이다. Types are ultimately derived from the implementation type (implementation type), which is essentially an abstraction (abstraction) on a common technical features. 예컨대 웹 서비스(Web Service)는 SQL 데이터베이스와 마찬가지로 구현 유형으로서 모델링될 수 있다. Such as Web services (Web Service) can be modeled as an implementation type, as in the SQL database. MyService 애플리케이션에서는, MyFrontEnd는 구현 유형 웹 서비스로부터 파생되는 새로운 유형이고, MyBackEnd는 구현 유형 SQL 데이터베이스로부터 파생되는 새로운 유형이다. In MyService applications, MyFrontEnd is a new type that derives from the Web service implementation type, MyBackEnd is a new type that is derived from the implementation of SQL type database.

componentImplementationType 및 wireImplementationType SDM 스키마 요소(element) 각각은 설정 스키마(settings schema), 배포 목록(deployment manifest) 및 포트 구현 참조(reference)를 포함할 수 있다. componentImplementationType and wireImplementationType SDM schema element (element), respectively may include a settings schema (schema settings), the distribution list (deployment manifest) and a reference port implementation (reference). portImplemenationType 요소는 포트 구현 참조를 갖지 않는다. portImplemenationType elements do not have a reference implementation of the port. 도 9는 SDM 구현 유형 스페이스가 어떻게 생겼는지를 나타내고 있다. 9 shows how the implementation of SDM types of space looks like.

- 설정 스키마는 설계시(design-time) 유효성이 검증될 수 있는 컴포넌트, 포트 및 와이어 상의 구성 파라미터(configuration parameter)들에 대한 XSD이다. - setting a XSD schema for the design process (design-time) configuration parameters on the components, ports, and wires that effectiveness can be verified (configuration parameter).

- 배포 목록은 컴포넌트, 포트, 또는 와이어가 설치되려면 어느 설치 파라미터들이 설정될 필요가 있는지를 표현하는 XSD이다. - Distribution lists are XSD to express that need to be installed which parameters are set in order to install a component, port or wire. 이 목록은 Fusion 또는 그 밖의 어떠한 설치자(installer) 기술에 대한 스키마일 수 있다. This list can be a schema for Fusion or any other installer (installer) technology.

- 포트 구현 참조는 컴포넌트 및 와이어가 선언(declare)된 포트 구현 유형을 참조함으로써 허용 가능한 포트를 선언하는 위치이다. -Port implementation is a reference position that declares the allowable port by referring to the component and the wire declaration (declare) the port implementation type.

또한, 다른 컴포넌트들을 호스팅할 수 있는 컴포넌트는, 설치자 및 자신이 호스팅할 수 있는 컴포넌트 구현 유형을 식별하는 hostRelations SDM 스키마 요소를 이용하여 선언된다. In addition, components that can host other component is declared using the hostRelations SDM schema element that identifies installers and component implementation types that you can own hosting. hostRelations 요소는 컴포넌트들 중 하나가 다른 컴포넌트(들)을 위한 호스트로서 작용하는 경우 컴포넌트 구현 유형간의 방향성 링크(directional link)로서 간주될 수 있다. hostRelations element may be thought of as a directional link (directional link) between the case that acts as a host for the other component (s) one of the components, component implementation type. 컴포넌트를 호스팅한다는 것은 컴포넌트의 코드를 위한 실행 환경을 제공한다는 것을 의미한다. That hosts a component means that it provides the execution environment for the code of the component. 예컨대 IIS는 구현 유형 웹 서비스 및 웹 애플리케이션(Web Application)의 컴포넌트들을 위한 호스트이다. For example, IIS is the host for the components of the implementation type Web services and Web applications (Web Application). 호스트는 본 명세서에서 이후에 더욱 상세히 설명하기로 한다. The host will be further described later in this specification.

SDM 스키마에서 portType, wireType 및 componentType 요소 각각은 애플리케이션 제약값(application constraint value), 배포 값(deployment value) 및 호스트 제약값(host constraint value)을 포함한다. In the SDM schema each portType, wireType and componentType factors include the value of pharmaceutical applications (application constraint value), distributed value (deployment value) and host restriction value (host constraint value). 또한 wireType 요소는 지정된 와 이어 유형 상에서 허용 가능한 포트 유형을 정의하는 포트 유형 요소를 포함하며, componentType 요소는 지정된 컴포넌트 유형 상에서 호스팅될 수 있는 구현 유형을 식별하는 호스팅된 유형 리스트(hosted types list) 요소를 포함한다. Also wireType element includes a port type element defining the permissible type of port on the type followed by the specified, componentType element is a host type list (hosted types list) element that identifies the implementation of the type that can be hosted on a given component type It includes. 도 10은 SDM 유형 스페이스를 나타낸다. 10 shows an SDM type space.

- 설정값은 컴포넌트, 포트 및 와이어에 대한 구성값을 제공하는 설정 스키마에 대한 XML이고, 호스트의 제약값에 대하여 설계시에 유효성이 검증될 수 있다. - setting values ​​are set for the XML schema to provide configuration values ​​for the components, ports, and the wire may be validated in the design against the constraints value of the host.

- 배포값은 컴포넌트, 포트, 또는 와이어가 제대로 기능하기 위해 설정될 필요가 있는 구성 파라미터의 값을 표현하는 배포 목록에 대한 XML이다. - Distribution value is XML for distribution lists representing the value of the configuration parameters that need to be set up in order to function properly component, port or wire.

- 제약값은 호스트의 컴포넌트, 포트, 또는 와이어가 설정되어야 하는 구성 파라미터 값을 제공하는 설정 스키마를 위한 XML이다. - constraint value is set for the XML schema that provides configuration parameters to the host component, a port, or a wire to be set. 제약값은 설계시에 기저 호스트(underlying host)의 설정값에 대하여 유효성이 검증될 수 있다. Pharmaceutical value can be validated against a set value of the underlying host (underlying host) in the design.

- 포트 유형은 지정된 와이어의 멤버일 수 있는 허용 가능한 포트 유형을 열거하는 XML이다. - The port type is the XML that lists the allowable port type, which can be a member of a given wire.

- 호스팅된 유형 리스트는 어떤 컴포넌트가 호스팅할 수 있는 컴포넌트 구현 유형의 리스트를 그 컴포넌트가 선언하는 XML이다. - hosted type of list is an XML component to any component that declares a list of component implementation types that can be hosted.

인스턴스(Instances) Instance (Instances)

컴포넌트, 포트 및 와이어는 애플리케이션/서비스의 구조 및 양상(behavior)을 정의하지만, 실행되는 인스턴스를 정의하지는 않는다. Components, ports, and the wire define the structures and aspects (behavior) of the applications / services, but does not define the instance is running. 매 구성요소, 포트 및 와이어 유형 선언은 하나 또는 그 이상의 인스턴스를 가질 수 있다. Every component, port and wire type declaration may have one or more instances. 인스턴스들은, 물리적 자원(서버, 네트워크 스위치 포트 및 디스크)이 할당되고 소프트웨어 자원(운영 체제, 런타임 호스트, 애플리케이션 코드)이 설치 및 구성되도록 애플리케이션/서비스를 배포한 결과이다. Instances, the result of physical resources (servers, network, switch ports, and disk) deploy applications / services to be assigned and software resources (operating systems, run-time host, application code) to install and configure.

모든 인스턴스들을 생성시부터 삭제시까지 추적하는 것은 SDM 런타임이 할 일이다. It is a day to the SDM runtime to track all instances until removed from the time of creation.

SDM 런타임(SDM Runtime) SDM runtime (SDM Runtime)

SDM 런타임은 그 자신이 컴포넌트, 포트 및 와이어의 인스턴스들을 생성하지는 않고, 대신 SDM 인스턴스들의 생성 및 관리를 조정하는 데 사용되는 일단의 API들을 제공한다. SDM runtime that they do not generate the components, an instance of the port and the wire, instead of providing one end of the API used to control the creation and management of the SDM instance. 웹 서비스 컴포넌트에 대한 호스트로서 IIS와 함께 윈도우 서버(Windows Server)를 실행시키는 서버와 같이, 인스턴스를 실제로 생성하는 데에는 통상적으로 복수의 엔티티(entity)가 관련되며, 완료되기까지는 수시간 또는 수일이 걸릴 수 있다. As a host for the Web service component, such as a server that is running Windows Server (Windows Server) with IIS, There are actually creating an instance is usually associated with a plurality of entities (entity), take a few hours or a few days until it is complete can.

SDM 런타임은 언제 "SDM 인스턴스 생성" 프로세스가 개시되고, 언제 성공 또는 실패로 종료될지를 알고 있다. SDM runtime will know whether and when "SDM instance creation" process is initiated, and when exits with success or failure. 또한 SDM 런타임은 SDM 인스턴스에 대하여 그 존속 기간(lifetime)동안 어떤 변경이 가해져야 하는지를 알고 있다. Also I know how SDM runtime will be no change is applied during the duration (lifetime) with respect to SDM instances. SDM 런타임은 지정된 SDM과 관련된 인스턴스들에 관한 정보에 대하여 질의(query)를 받을 수 있도록 소정의 애플리케이션/서비스와 관련된 모든 트랜잭션(transaction)들을 기록하는 어카운턴트(accountant)라고 간주될 수 있다. SDM runtime can be considered a word count consultants (accountant) to record all transactions (transaction) associated with a given application / service that can be queried (query) for information about the instances associated with a given SDM.

SDM 인스턴스를 생성하는 제1 단계는 애플리케이션/서비스 SDM을 SDM 런타임으로 등록하는 것이다. A first step of generating the SDM instance is to register the application / service SDM to the SDM runtime. 일단 SDM 런타임이 주어진 SDM을 알게 되면, 인스턴스 생성 프로세스가 팩토리(Factory)들과 자원 관리자(Resource Manager; 이하 설명할 것임)들을 이용하여 호출될 수 있다. Once the SDM runtime find a given SDM, instance creation process, the factory (Factory) and resource managers; could be called using (Resource Manager will be described below).

API 및 런타임 설계에 관한 더욱 상세한 정보를 얻기 위해서는 http://big/에 있는 SDM 런타임 아키텍쳐 사양을 참조하면 된다. To get more detailed information about the API and runtime designed to http: Referring to the SDM Runtime Architecture specification on // big /.

호스트 및 팩토리(Hosts and Factories) Hosts and Factories (Hosts and Factories)

다른 컴포넌트들을 "호스팅"할 수 있는 컴포넌트는 호스트라고 불리며, 이들이 지원하는 구현 유형에 대한 팩토리로서 작용한다. It referred to other components as components that can "host" is a host acts as a factory for the implementation types they support. 컴포넌트는 앞서 설명한 SDM 스키마의 hostRelations 요소를 이용하여 하나 또는 그 이상의 컴포넌트 구현 유형의 호스트로서 선포될 수 있다. Component may be declared as one or more components of the implementation type of the host using the hostRelations elements of the SDM schema described above.

호스트는 컴포넌트의 코드를 위한 실행 환경을 제공하지만, 팩토리는 소정 유형의 SDM 인스턴스들을 생성하고 SDM 런타임 API들을 통해 SDM 런타임과 상호작용하는 실제 서비스이다. The host provides the execution environment for the code component, but the factory is an actual service generating SDM instances of a given type, and interact with the SDM runtime via the SDM runtime API. 팩토리는 하나 또는 그 이상의 컴포넌트 구현 유형을 지원할 수 있고, 어느 컴포넌트 구현 유형이 지원되는지를 지정하는 SDM 런타임으로 등록해야 한다. Factories must register with the SDM runtime that can support one or more component implementation type, which specifies whether the component implementation types are supported. 소정의 팩토리는 상이한 구성을 갖는 동일한 유형의 호스트를 복수 개 지원할 수 있고, 또한 개개의 팩토리는 호스트 구성의 유형 각각에 대하여 존재할 수도 있다. Predetermined factory may support a plurality of the same type of host having a different configuration, and each of the factory may be present, for each type of host configuration. 예컨대 IIS 팩토리는 웹 서비스 및 웹 애플리케이션과 같은 복수의 구현 유형을 지원할 수 있다. For example, IIS Factory can support multiple types of implementations, such as Web services and Web applications. 마찬가지로, SQL 팩토리는 데이터베이스, 분할된 데이터베이스(Partitioned Database) 및 고가용 데이터베이스(Highly Available Database)와 같은 상이한 데이터베이스 유형을 지원할 수 있다. Similarly, SQL factory can support different types of databases, such as databases, splitting databases (Partitioned Database), and high-availability database (Highly Available Database).

팩토리는 기억장치(storage), 네트워크 및 서버와 같은 물리적 자원을 그 자신이 관리하지는 않는다. Factory storage (storage), physical resources such as network and server does not have its own management. 팩토리는 자원 관리자를 통해 물리적 자원(그리고 이들 의 논리적 등가물)과 상호작용한다. Factory interacts with the physical resources (and their logical equivalents) by the resource manager.

자원 관리자(Resource Managers) Resource Manager (Resource Managers)

자원 관리자는 (1) 부트스트랩(bootstrap) 프로세스의 일부로서 발견(discover) 또는 생성되거나, (2) 물리적 환경의 소정의 선언적 XML 기반의 기술(description)을 통해 지정된 물리적 및 논리적 자원을 관리한다. The resource manager (1) a bootstrap (bootstrap), or as part of the process found (discover) or generated, (2) manages the physical and logical resources assigned through a predetermined declarative technique (description) of the XML-based physical environment. 자원 관리자는 모든 기억장치, 네트워크 및 서버 자원을 보유하며, 공통의 자원 관리 API를 공개하여 자원 할당 요청을 처리하고 이러한 자원들의 소유권(ownership)을 추적한다. The resource manager reserves all storage devices, network and server resources, and to disclose a common resource management API handles the resource allocation request and track title (ownership) of these resources.

자원 관리자의 예는 NRM(Network Resource Manager), SRM(Storage Resource Manager) 및 PRM(PC Resource Manager)이다. Examples of resource managers are NRM (Network Resource Manager), SRM (Storage Resource Manager) and PRM (PC Resource Manager). 이들 자원 관리자들 각각은 물리적 포트나 디스크 또는 서버 및 이들이 공개하는 VLAN, 논리적 디스크 볼륨(logical disk volumes), 공유 파일(file shares), 웹 서버 등과 같은 논리적 자원의 할당을 담당한다. Each of these resources manager is responsible for the allocation of resources, such as physical port or logical disk or server, and VLAN to which they are released, the logical disk volume (logical disk volumes), file sharing (file shares), the web server. 자원 관리자는 또한 할당 및 해제(de-allocation)를 달성하도록 물리적 장치들을 프로그래밍하는 역할을 한다. The resource manager also serves to program the physical device to achieve the allocation and release (de-allocation).

물리적 하드웨어를 프로그램하기 위해, 자원 관리자는 하드웨어 장치의 구현 세부 사항을 숨기고 있는 자원 제공자들을 통해 하드웨어와 상호작용함으로써, 예컨대 복수의 공급자(vendor)로부터 제공된 네트워크 스위치들이 서로 바뀌어 쓰일 수 있도록 한다(제조자의 장치에 대한 제공자가 존재하는 경우). To program the physical hardware, the resource manager is to be used by the interaction with hardware, such as a plurality of provider network switch as provided by the (vendor) are replaced with each other via the resource provider to hide the implementation details of the hardware device information (the manufacturer's If the provider of the device present). 윈도우(Windows)의 하드웨어 추상화 계층(HAL; hardware abstraction layer) 및 장치 드라이버 모델과 마찬가지로, 서버, 네트워크 및 저장 장치에 이르는 데이터 센터 환경에 대해 서도 동등한 추상화 계층이 존재한다. Hardware abstraction layer for Windows (Windows); as well as (HAL hardware abstraction layer) and device driver model, even for servers and data center environments, ranging from network and storage devices, there is an equivalent abstraction layer.

계층 및 매핑(Layers and Mappings) Hierarchy and Mapping (Layers and Mappings)

컴포넌트, 포트 및 와이어는 호스트, 팩토리, 자원 관리자 및 SDM 런타임과 결합되는 경우 강력한 추상화(abstraction)이지만, 이들은 분산형 애플리케이션/서비스를 배포 및 관리하기에는 충분하지 않다. Component, port and wire is a powerful abstraction (abstraction) when combined with hosts, factories, resource managers and the SDM runtime, they are not sufficient to deploy and manage distributed applications / services. 이러한 논리적 추상화의 물리적 인스턴스를 생성 및 관리하기 위해서는, 어떠한 추가적인 구축물(construct)이 필요하다. In order to create and manage the physical instances of such logical abstraction, it is no need for additional constructs (construct). 이러한 추가적인 구축물은 계층 및 매핑이다. These additional structures are hierarchical and mapping.

계층(Layers) Layers (Layers)

계층에 대한 필요는 애플리케이션/서비스의 배포 요건(deployment requirement)들의 유효성을 설계시에 검증하고자 하는 욕구가 그 동기가 된다. The need for a hierarchy that needs to be verified during the design validation of deployment requirements (deployment requirement) of the application / service that is motivated. 도 11은 SDM에 의해 정의된 계층 추상화를 나타내고 있다. 11 shows a layer of abstraction defined by the SDM.

- 애플리케이션 계층은 분산 가능한 컴포넌트, 이들의 배포 요건 및 제약(constraints), 그리고 이들의 통신 관계(communication relationship)를 애플리케이션/서비스의 맥락에서 기술한다. - the application layer will be described in the context of the dispersible component, the distribution of these requirements, and limitations (constraints), and those of a communication relationship (communication relationship) applications / services.

- 배포 계층은 다른 것 들 중에서도 IIS, CLR 및 SQL과 같은 호스트에 대한 구성 및 정책(policy) 설정 및 제약을 기술한다. - Distribution layer describes the configuration and policy (policy) settings and constraints for hosts such as IIS, CLR and SQL, among others.

- 가상 데이터 센터(VDC; Virtual Data Center) 계층은 운영 체제로부터 네트워크 토폴로지(topology)를 통해 서버, 네트워크 및 저장 장치에 이르기까지의 데이터 센터 환경 설정 및 제약을 기술한다. - virtual data center (VDC; Virtual Data Center) layer describes a data center preferences and constraints from the operating system from the server, network and storage through a network topology (topology).

- 하드웨어 계층은 물리적 데이터 센터 환경을 기술하고, 이는 발견되거나 예컨대 XML을 이용하여 선언적 방식으로 지정된다. Hardware layer describes the physical data center environments, it is detected, or for example using XML is specified in a declarative manner. 이 계층은 스케일 불변이 아니므로 SDM에서 모델링되지 않으나, 완전함을 위해 포함되었다. This layer is included, but not for model scale in the SDM is not a constant, complete.

매핑(Mappings) Mapping (Mappings)

SDM이 계층화되어 있으므로, 다양한 계층을 바인딩(binding)할 필요가 존재한다. Because SDM is layered, there is a need to bind (binding) the various layers. 매핑은 본질적으로 어떤 계층에 있는 컴포넌트 또는 포트를 아래의 다음 계층에 있는 컴포넌트 또는 포트와 바인딩한 것이다. Mapping is essentially bound to the component ports or in any layer or components and ports in the next layer below. 매핑은 다음과 같이 기술될 수 있다. 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 T = [T n -> T n-1] + [T n-1 -> T n-2] + [T n-2 -> T n-3] + [...]

여기서 M은 컴포넌트, 포트, 또는 와이어를 나타내며, n은 계층을 나타낸다. Where M represents the components, ports, or wire, n represents a hierarchy. 화살표는 매핑의 방향을 나타내며, 항상 높은 계층으로부터 낮은 계층 쪽으로 향한다. The arrows indicate the direction of the map, all the time directed towards the lower layer from the higher layer.

예컨대, 도 12에서 MyFrontEnd라는 이름의 애플리케이션 계층에 있는 컴포넌트는 IIS라 불리는 배포 계층에 있는 컴포넌트에 매핑된다. For example, in Fig. 12 components in the application layer named MyFrontEnd is mapped to the components in the distribution layer called IIS. 마찬가지로 MyBackEnd라는 이름의 컴포넌트는 배포 계층에 있는 SQL 컴포넌트에 매핑된다. Similarly named MyBackEnd components are mapped to SQL component in the distribution layer.

설계시 유효성 검증 (Design-time Validation) Design Validation (Design-time Validation)

컴포넌트와 아래쪽 계층에 있는 그 컴포넌트의 호스트 컴포넌트 사이의 바인딩은, 애플리케이션/서비스가 실제로 라이브 데이터 센터(live data center)에 배포되기 전에 개발자에게 문제를 안겨줄 수 있다. Binding between the components of the host component in the component and the lower layer, application / services may actually favor the issue to the developer before deployment to a live data center (live data center). 이러한 문제는 유형의 비호환, 구성의 충돌(conflict), 동작의 불일치(mismatch), 토폴로지 관계(topological relationship)의 결여 등에 기인한 것일 수 있다. This problem can be caused such as the lack of inconsistency (mismatch), the topology relationship (topological relationship) of the type of non-compliant, the configuration of the collision (conflict), operation. 예컨대 도 13에 도시된 매핑 시도는 오류를 낳을 수 있는 바, 배포 계층에 있는 IIS 및 SQL 컴포넌트 사이에는 잠재적인 통신 관계가 존재하지 않기 때문이다. For example, a map shown in FIG. 13 is an attempt because the bar can lead to errors between IIS and SQL components in the distribution hierarchy is not a potential communication relationship exists.

MyBackEnd 컴포넌트로부터 SQL 호스트 컴포넌트로의 매핑은 컴포넌트 및 호스트 유형의 호환성이 있고 구성 충돌이 없다는 점에서 유효한 바인딩이었을 수 있지만, MyFrontEnd와 지정된 배포 계층에 존재하지 않는 MyBackEnd 사이의 토폴로지 관계를 MyServiceSDM이 정의하였으므로 이는 유효하지 않다. Mapping from MyBackEnd components to SQL host component which hayeoteumeuro defined MyServiceSDM the topology relationship between nonexistent in, MyFrontEnd a specified distribution layer may have been a valid binding in that the compatibility of the components and the host type, and there is no configuration conflicts MyBackEnd not valid.

설정 및 제약 체크(Settings and Constraints Checking) Check settings and restrictions (Settings and Constraints Checking)

애플리케이션 계층으로부터 배포 계층(그리고 기타 등등)으로 매핑할 수 있는 능력은, 호스트의 제약에 대하여 컴포넌트의 설정의 유효성을 설계시에 검증할 수 있도록 해 주고, 또한 컴포넌트의 제약에 대하여 호스트 설정의 유효성을 검증할 수 있도록 해 주므로 상당히 강력하다. The ability to map to the distribution layer (and others) from the application layer, give it to validate a set of components in the design against the constraints of the host, but also the validity of the host set against the constraints of component because it is proven to be extremely powerful.

도 14는 상이한 계층에 있는 컴포넌트들 및 호스트 사이의 관계를 더욱 상세히 나타내고 있다. 14 shows in more detail the relationship between the components and the host in the different layers. 이 도면에서, VDC 계층에 이르기까지 쭉, 어떤 계층에 있는 컴포넌트와 아래의 다음 계층에 있는 호스트 컴포넌트간에 바인딩이 존재함에 주목하자. Note As in the drawing, all the way down to the VDC layer, the binding between the host component in the following hierarchy of components and down in any hierarchy exists.

도 14에서, MyFrontEnd는 IIS에 의해 호스팅되는 웹 서비스이며, IIS는 윈도우 서버에 의해 호스팅되는 윈도우 애플리케이션(Windows Application)이다. In Figure 14, MyFrontEnd is a web service that is hosted by IIS, IIS is a Windows application (Windows Application) that is hosted by Windows Server. IIS 및 SQL의 인스턴스들의 생성 및 삭제를 담당하는 윈도우 애플리케이션 팩토리가 존재하는 것과 마찬가지로, 웹 서비스 및 웹 애플리케이션 컴포넌트의 인스턴스 들의 생성 및 삭제를 지원하는 IIS 팩토리가 존재한다. Similar to the Windows Application Factory, which is responsible for the creation and deletion of instances of SQL and IIS is present, there is a factory that IIS supports the creation and deletion of instances of web services and web application components.

도 15는 앞서 설명한 SDM 설정 및 제약 시멘틱(semantics)을 이용하여 상이한 계층에 있는 컴포넌트들 사이에서 설계시 유효성 검증이 어떻게 동작하는지를 나타내고 있다. 15 shows how the validation operation is how the design among the above-described set and pharmaceutical SDM semantics (semantics) using the components in the different layers.

여기서 위쪽 계층에 있는 컴포넌트의 제약은 아래쪽 계층에 있는 호스트 컴포넌트의 설정에 대하여 유효성이 검증됨에 주목하자. The pharmaceutical component in the upper layer Notice As validated against a set of host components in the lower layer. 또한 호스트 컴포넌트의 제약은 호스팅될 컴포넌트의 설정에 대하여 유효성이 검증됨에 주목하자. Also Note As the constraints of the host component is validated against a set of components to be hosted.

양방향 설정 및 제약 체크는 개발자로 하여금, 아래 방향으로 쭉 SDM 시멘틱을 이용하여 기술된 동작 환경의 맥락에서 자신의 애플리케이션/서비스를 신뢰성있게 개발할 수 있도록 해 준다. Interactive settings and check constraints gives it allows the developers to make in the context of the technology all the time using SDM semantics downward reliable operating environment to develop your own applications / services. 개발 프로세스 도중 데이터 센터에 관한 기술(description)이 신뢰받을 수 있도록 데이터 센터를 기술하기 위해서는, VDC(Virtual Data Center)라 일컬어지는 데이터 센터의 추상화를 생성할 필요가 있다. In order to describe the data center to help technology (description) of the data center during the development process it can not be trusted, it is necessary to create an abstraction of the data center, which is referred to as (Virtual Data Center) VDC.

가상 데이터 센터(VDC) Virtual Data Center (VDC)

VDC는 개발자가 데이터 센터를 보는 시점을 간략하게 해 주는 물리적 데이터 센터 환경의 논리적 표현이다. VDC is a logical representation of the physical data center environment that briefly when the developer looks at the data center. 이상적으로 IT 전문가 또는 설계자(Architect)는 개발자가 분산형 애플리케이션/서비스를 기술할 수 있는 스케일 불변 방식과 동일한 방식으로 데이터 센터를 기술할 수 있어야 한다. Ideally, IT professionals or architects (Architect) should the developer to describe the data center in the same manner and scale invariant way to describe distributed applications / services. VDC는 데이터 센터 내의 서버, 네트워크 및 저장 자원 및 이들의 토폴로지 관계의 추상화인 것으로 간주될 수 있다. VDC can be regarded as an abstraction of server, network and storage resource topologies and their relationships within the data center. 통상적인 데이터 센터의 도표(diagram)는, 복수의 상호 연결된 서버, 네트 워크 장비, IP 주소, VLAN, 운영 체제, 저장 장치 등이 Visio나 유사한 도구를 이용하여 그린 단일 도표상에 모두 표현되어 상당히 복잡하다. A typical data center chart (diagram) of is quite complicated plurality of interconnected servers, network equipment, IP address, VLAN, operating systems, storage devices, etc. are all expressed on a green single chart using Visio or similar tool Do. 이 도표에 추가하여, 데이터 센터가 어떻게 분할, 구성 및 관리되는지를 정확히 규정(prescribe)하는 통상적으로 긴 문서가 존재한다. In addition to the Figure, there is typically a long document that exactly defined (prescribe) how the data center split, configuration and management.

이러한 복잡함의 예로서는 MSA(Microsoft Systems Architecture) EDC(Enterprise Data Center)가 있다. An example of such a complex has (Enterprise Data Center) (Microsoft Systems Architecture) MSA EDC. 업데이트(update) 및 업그레이드(upgrade)가 적용됨에 따라 데이터 센터의 상태를 반영하여, 손으로 그린 도표 및 문서를 최신으로 유지하는 것은 불가능한 것은 아니더라도 비용이 많이 드는 일임이 분명하다. Reflecting the state of the data center, according to the update (update) and upgrades (upgrade) is applied, it is impossible to maintain a hand-drawn graphics and documents up to date it is clear that, if not discretionary and costly. 마찬가지로, 문서의 규정 사항에 대하여 환경의 유효성을 검증하는 것은 어려울 뿐만 아니라 사람에 의한 오류가 발생할 수 있다. Likewise, in order to validate the environment with respect to the requirements of this article it may occur, as well as errors caused by difficult people.

스케일 불변 방식으로 MSA EDC와 같은 복잡한 데이터 센터를 표시하는 능력은 설계자 및 IT 전문가 모두에게 매우 강력한 것이다. Scale approach to the immutable ability to display complex data centers, such as the MSA EDC is very powerful for both designers and IT professionals. 데이터 센터를 컴포넌트, 포트 및 와이어로 기술할 수 있는 능력은, 오늘날의 설계 및 배포 프로세스에서 결여되어 있는 배포 요건의 모델링 및 유효성 검증이 가능한 강력한 프레임워크를 제공한다. The ability to describe data center components, ports and wires, provides a powerful modeling and validation framework capable of deployment requirements that are lacking in today's design and deployment process.

아젠다(Agenda): 개요, SDM 빌딩 블록(Building Blocks), 예시 애플리케이션, 예시 호스트, 논리적 배치(Logical Placement), 배포, 상태(Status) Agenda (Agenda): Overview, SDM building blocks (Building Blocks), illustrative application, the exemplary host, a logical arrangement (Logical Placement), distribute, status (Status)

SDM은 분산형 애플리케이션 및 이들의 배포 환경의 요소 부분을 캡쳐(capture)하는 데에 적합한 메타모델(meta-model)이다. SDM is an appropriate meta-model (meta-model) for the capture (capture) the component parts of distributed applications and their deployment. SDM은 권한을 갖는다. SDM has the authority. 즉 애플리케이션 및 환경은 이들의 SDM으로부터 구축되고, 애플리케이션 및 환경에 대한 변경은 SDM을 통해 이루어지며, 관리 프로세스를 위한 네임스페이스 (namespace)가 제공된다. That is being built from the SDM of these applications and environments, changes to the application and environment is done through the SDM, the namespace (namespace) for management processes is provided.

서비스 정의 모델(Service Definition Model)은 상호 관련된 스키마, 즉 Service Definition Model (Service Definition Model) is correlated to the schema, ie

클래스, 클래스 관계 및 설치자 스키마 Class, class relations and installers scheme

컴포넌트, 포트 및 와이어 유형 스키마 Component, port and wire types schema

논리적 배치 스키마 Logically arranged scheme

물리적 배치 스키마 Physical placement scheme

인스턴스화(instantiation) 요청 스키마 Instantiation (instantiation) Request Schema

인스턴스 스키마 Schema Instance

의 집합을 지칭한다. It refers to the set.

SDM 클래스는 모든 분산형 애플리케이션 및 배포 환경에 대한 기본 빌딩 블록이다. SDM class is a basic building block for all distributed applications and distributed environments. Application 클래스에는 ASP.Net Web Service, ASP.Net Web Site, BizTalk Orchestration Schedule, Services Components(COM+) 등이 있다. Application class has such ASP.Net Web Service, ASP.Net Web Site, BizTalk Orchestration Schedule, Services Components (COM +). Service 클래스에는 IIS Server, SQL Sever, BizTalk Server가 있다. Service class has IIS Server, SQL Sever, BizTalk Server. OS, Network & Storage 클래스에는 Windows VLAN, Filter, Disk 등이 있다. OS, Network & Storage class include Windows VLAN, Filter, Disk. Hardware 클래스에는 Server, Switch, Firewall, Load Balancer, SAN 등이 있다. Hardware class has the Server, Switch, Firewall, Load Balancer, SAN, etc. 클래스는 시스템 레벨 개발자에 의해 만들어지며, 자주 바뀌지 않는다. Class are created by the system level developers, it does not change frequently. 클래스는 SDM의 모든 컴포넌트, 포트 및 와이어 각각의 배후에 있다. Classes are every component, each of the rear ports and wires SDM. 클래스 각각은 공개 설정(public settings; 설정이라고 간단히 불림) 및 개인 설정(private settings; 배포라고 불림)을 포함한다. Each class includes a public setting;; (called a distributed private settings) (public settings set called simply referred to), and personal settings. 관계(relationship)는 클래스 사이, 즉 포트 클래스에 대한 컴포넌트 클래 스, 포트 클래스에 대한 와이어 클래스 및 컴포넌트 클래스에 대한 컴포넌트 클래스에서 캡쳐된다. Relationship (relationship) is captured in between class, that is, the component class of the wire class and the component class of the component class, the class port to the port class.

ASP.Net Web Site 클래스 ASP.Net Web Site Class

<componentClass name="WebSite" layer="Application">http://big/ <ComponentClass name = "WebSite" layer = "Application"> http: // big /

<settingSchema><xs:schema><xs:complexType><xs:sequence> <SettingSchema> <xs: schema> <xs: complexType> <xs: sequence>

<xs:element name="webSiteName" type="xs:string"/> <Xs: element name = "webSiteName" type = "xs: string" />

<xs:element name="authentication" type="xs:string"/> <Xs: element name = "authentication" type = "xs: string" />

<xs:element name="sessionState" type="xs:boolean"/> <Xs: element name = "sessionState" type = "xs: boolean" />

</xs:sequence></xs:complexType></xs:schema></settingSchema> </ Xs: sequence> </ xs: complexType> </ xs: schema> </ settingSchema>

<deploymentSchema><xs:schema><xs:complexType><xs:sequence> <DeploymentSchema> <xs: schema> <xs: complexType> <xs: sequence>

<xs:element name="fusionManifest" type="xs:string"/> <Xs: element name = "fusionManifest" type = "xs: string" />

</xs:sequence></xs:complexType></xs:schema></deploymentSchema> </ Xs: sequence> </ xs: complexType> </ xs: schema> </ deploymentSchema>

<portClassesAllowed closed="true"> <PortClassesAllowed closed = "true">

<portClassRef name="ClientDataAccess" /> <PortClassRef name = "ClientDataAccess" />

<portClassRef name="WebServer" maxOccurs="1"/> <PortClassRef name = "WebServer" maxOccurs = "1" />

<portClassRef name="SoapClientInterface" /> <PortClassRef name = "SoapClientInterface" />

<portClassRef name="RemotingClientInterface" /> <PortClassRef name = "RemotingClientInterface" />

</portClassesAllowed> </ PortClassesAllowed>

</componentClass> </ ComponentClass>

SOAP Client Port 클래스 SOAP Client Port Class

<portClass name="SoapClientInterface" layer="Application">http://big/ <PortClass name = "SoapClientInterface" layer = "Application"> http: // big /

<settingSchema><xs:schema><xs:complexType><xs:sequence> <SettingSchema> <xs: schema> <xs: complexType> <xs: sequence>

<xs:element name="formatter" type="xs:string"/> <Xs: element name = "formatter" type = "xs: string" />

<xs:element name="transport" type="xs:string"/> <Xs: element name = "transport" type = "xs: string" />

</xs:sequence></xs:complexType></xs:schema></settingSchema> </ Xs: sequence> </ xs: complexType> </ xs: schema> </ settingSchema>

<deploymentSchema><xs:schema><xs:complexType><xs:sequence> <DeploymentSchema> <xs: schema> <xs: complexType> <xs: sequence>

<xs:element name="wsdlFile" type="xs:string"/> <Xs: element name = "wsdlFile" type = "xs: string" />

</xs:sequence></xs:complexType></xs:schema></deploymentSchema> </ Xs: sequence> </ xs: complexType> </ xs: schema> </ deploymentSchema>

</portClass> </ PortClass>

SOAP Wire 클래스 SOAP Wire Class

<wireClass name="SoapConnnection" layer="Application"> <WireClass name = "SoapConnnection" layer = "Application">

<settingSchema/> <SettingSchema />

<deploymentSchema/> <DeploymentSchema />

<portClassesAllowed> <PortClassesAllowed>

<portClassRef name="SoapServerInterface"/> <PortClassRef name = "SoapServerInterface" />

<portClassRef name="SoapClientInterface"/> <PortClassRef name = "SoapClientInterface" />

</portClassesAllowed> </ PortClassesAllowed>

</wireClass> </ WireClass>

IIS Component 클래스 IIS Component Class

<componentClass name="IIS" layer="Service"> <ComponentClass name = "IIS" layer = "Service">

<settingSchema><xs:schema><xs:complexType><xs:sequence> <SettingSchema> <xs: schema> <xs: complexType> <xs: sequence>

<xs:element name="certificateAuth" type="xs:boolean"/> <Xs: element name = "certificateAuth" type = "xs: boolean" />

<xs:element name="ntlmAuth" type="xs:boolean"/> <Xs: element name = "ntlmAuth" type = "xs: boolean" />

<xs:element name="sessionStateType" type="xs:string"/> <Xs: element name = "sessionStateType" type = "xs: string" />

</xs:sequence></xs:complexType></xs:schema></settingSchema> </ Xs: sequence> </ xs: complexType> </ xs: schema> </ settingSchema>

<deploymentSchema><xs:schema><xs:complexType><xs:sequence> <DeploymentSchema> <xs: schema> <xs: complexType> <xs: sequence>

<xs:element name="fusionManifest" type="xs:string"/> <Xs: element name = "fusionManifest" type = "xs: string" />

</xs:sequence></xs:complexType></xs:schema></deploymentSchema> </ Xs: sequence> </ xs: complexType> </ xs: schema> </ deploymentSchema>

- <portClassesAllowed> - <portClassesAllowed>

<portClassRef name="HTTPServer"/> <PortClassRef name = "HTTPServer" />

<portClassRef name="HTTPClient"/> <PortClassRef name = "HTTPClient" />

<portClassRef name="TDSClient"/> <PortClassRef name = "TDSClient" />

</portClassesAllowed> </ PortClassesAllowed>

</componentClass> </ ComponentClass>

클래스 관계 및 설치자 Class relations and installers

<hostRelation classRef="WebSite" hostClassRef="IIS" installerRef="WebSiteInstaller"/> <HostRelation classRef = "WebSite" hostClassRef = "IIS" installerRef = "WebSiteInstaller" />

<installer name="WebSiteInstaller" code="WebSiteInstaller, IISInstaller" codeType="assembly" /> <Installer name = "WebSiteInstaller" code = "WebSiteInstaller, IISInstaller" codeType = "assembly" />

<HostRelation>은 클래스들 사이의 호스팅 관계를 캡쳐한다. <HostRelation> it will capture the hosting relationship between the classes. 즉 IIS는 Web Sites를 호스팅할 수 있다. In other words, IIS can host the Web Sites.

설치자는 SDM 런타임으로의 "플러그인(plugin)"이며, 컴포넌트, 포트 및/또는 와이어 클래스의 새로운 인스턴스를 생성하는 역할을 한다. The "plug-ins (plugin)" The installation of the SDM runtime, a component serves to generate a new instance of the port and / or wire class. 설치자는 또한 클래스의 인스턴스들을 구성하는 역할도 한다. It also installed a role to configure the instance of the class. 상이한 설치자들은 동일한 기저 배포 및 구성 기술, 예컨대 Fusion 또는 WMI.Config을 사용할 수 있다. Different installers can use the same underlying technology deployed and configured, for example, Fusion or WMI.Config.

분산형 애플리케이션(Distributed Application) Distributed application (Distributed Application)

분산형 애플리케이션은 컴포넌트, 포트 및 와이어로부터 구축된다. Distributed applications are constructed from components, ports, and wires. 개발자는 컴포넌트, 포트 및 와이어 유형을 클래스로부터 생성한다. The developer creates a class from the component, port and wire types. 유형은 클래스의 "용도(uses)"이며, 설정 및 배포 스키마의 값들을 공급한다. Type is "use (uses)" of the class, and supplies the values ​​of the settings and schema deployment. 유형은 재활용의 단위이다. Type is the unit of reuse. 유형은 Visual Studio에서의 단일 프로젝트에 대하여 매핑된다. Types are mapped on a single project in Visual Studio.

SDM은 복합 컴포넌트 유형(compound component type)을 통해 유형의 합성(composition)을 지원한다. SDM supports composite (composition) of the complex type by the component types (component type compound). 합성에 의해 작은 애플리케이션으로부터 더욱 큰 분산형 애플리케이션을 구축할 수 있다. It is possible to build a larger distributed application from a small application of a synthetic. 복합 컴포넌트 유형은 Visual Studio의 새로운 프로젝트 유형, 즉 Whitehorse에 대하여 매핑된다. Composite component type is a new type of project in Visual Studio, that is mapped with respect to Whitehorse.

FMStocks.Web 컴포넌트 유형 FMStocks.Web component type

<componentType name="FMStocks.Web" class="WebSite"> <ComponentType name = "FMStocks.Web" class = "WebSite">

<ports> <Ports>

<port name="web" type="webServer"/> <Port name = "web" type = "webServer" />

<port name="stock" type="StockClient"/> <Port name = "stock" type = "StockClient" />

<port name="accounts" type="AccountClient"/> <Port name = "accounts" type = "AccountClient" />

<port name="trades" type="TradeClient"/> <Port name = "trades" type = "TradeClient" />

</ports> </ Ports>

<settings> <Settings>

<webSiteName>FMStocks.Web</webSiteName> <WebSiteName> FMStocks.Web </ webSiteName>

<authentication>Certificate</authentication> <Authentication> Certificate </ authentication>

<sessionState>true</sessionState> <SessionState> true </ sessionState>

</settings> </ Settings>

<deployment> <Deployment>

<fusionManifest>fmstocks.web.manifest</fusionManifest> <FusionManifest> fmstocks.web.manifest </ fusionManifest>

</deployment> </ Deployment>

</componentType> </ ComponentType>

FMStocks7 복합 컴포넌트 유형 FMStocks7 composite component types

<compoundComponentType name="FMStocks"> <CompoundComponentType name = "FMStocks">

<components> <Components>

<component name="web" type="FMStocks.Web"/> <Component name = "web" type = "FMStocks.Web" />

<component name="svc" type="FMStocks.WebService"/> <Component name = "svc" type = "FMStocks.WebService" />

<component name="biz" type="FMStocks.BusinessService"/> <Component name = "biz" type = "FMStocks.BusinessService" />

<component name="custdb" type="FMStocks.CustomerDatabase"/> <Component name = "custdb" type = "FMStocks.CustomerDatabase" />

</components> </ Components>

<wires/> <Wires />

<delegatePorts> <DelegatePorts>

<port name="web" componentname="web" portname="web"/> <Port name = "web" componentname = "web" portname = "web" />

<port name="svc" componentname="svc" portname="svc"/> <Port name = "svc" componentname = "svc" portname = "svc" />

</delegateports> </ Delegateports>

</componentType> </ ComponentType>

SDU 및 배포 환경(SDU and Deployment Environment) SDU and deployment (SDU and Deployment Environment)

분산형 애플리케이션에 대한 컴포넌트, 포트 및 와이어 유형은 서비스 배포 유닛(SDU; Service Deployment Unit) 내에 바이너리(binary)와 함께 패키징될 수 있다. Components, ports, and the wire type for a distributed application service deployment unit; may be packaged with a binary (binary) in the (SDU Service Deployment Unit). 바이너리는 모든 .DLL, .EXE, .config 및 정적 콘텐츠(static content) 등을 포함한다. Binary includes all .DLL, .EXE, .config and static content (static content) and the like. SDU는 이동 가능(portable)하고, 독립적으로 설치 가능한 분산형 애플리케이션을 나타낸다. SDU is moveable (portable) and shows a distributed application that can be installed independently. 데스크탑 애플리케이션을 위한 Windows Installer MSI 파일과 유사하다. It is similar to the Windows Installer MSI file for desktop applications. 그러나 균일한 환경(Windows)을 주로 목표(target)로 삼는 데스크탑 애플리케이션과 달리, 분산형 애플리케이션은 현저하게 바뀌는 상이한 배포 환경에서 호스팅될 수 있고, 배포 환경 상에서의 이들의 요건을 표현할 수 있어야 하며, 배포 환경의 모든 정책에 따라야 한다. But unlike desktop applications samneun a uniform environment (Windows) primarily targets (target), distributed applications can be hosted on different deployment significantly changed, be able to express their requirements on deployment, and deployment It shall comply with all the policies of the environment.

따라서 애플리케이션 및 배포 환경 모두의 요건 및 제약을 표현할 수 있는 모델이 필요하다. It is therefore required that the model be expressed in both the application and deployment requirements and constraints. MyWebSite 컴포넌트 유형은 SQL 데이터베이스에 저장된 세션 상태로 구성되어 있는 IIS 서버를 필요로 한다. MyWebSite type of component requires the IIS server that is configured with session state is stored in SQL databases. 웹 존(web zone)은 자격 인증(certificate authentication)을 이용하는 webSites 컴포넌트만을 호스팅한다. Web Zone (web zone) will be hosting components using only webSites certification (certificate authentication).

IIS 컴포넌트 유형 IIS component types

<componentType name="WebTierIIS" class="IIS"> <ComponentType name = "WebTierIIS" class = "IIS">

<ports/> <Ports />

<settings> <Settings>

<certificateAuth>true</certificateAuth> <CertificateAuth> true </ certificateAuth>

<ntlmAuth>false</ntlmAuth> <NtlmAuth> false </ ntlmAuth>

<sessionStateType>true</sessionStateType> <SessionStateType> true </ sessionStateType>

</settings> </ Settings>

<deployment/> <Deployment />

<hostedClasses> <HostedClasses>

<hostedClass class="WebSite"> <HostedClass class = "WebSite">

<!-- constraint language expressed using XPath --> <-! Constraint language expressed using XPath ->

<constraint>/[authentication="certificate"</constraint> <Constraint> / [authentication = "certificate" </ constraint>

</hostedClass> </ HostedClass>

</hostedClasses> </ HostedClasses>

</componentType> </ ComponentType>

FMStocks.Web 컴포넌트 유형 (재방문) FMStocks.Web component type (revisited)

<componentType name="FMStocks.Web" class="WebSite"> <ComponentType name = "FMStocks.Web" class = "WebSite">

<ports/> <Ports />

<settings> <Settings>

<webSiteName>FMStocks.Web</webSiteName> <WebSiteName> FMStocks.Web </ webSiteName>

<authentication>Certificate</authentication> <Authentication> Certificate </ authentication>

<sessionState>true</sessionState> <SessionState> true </ sessionState>

</settings> </ Settings>

<deployment> <Deployment>

<fusionManifest>fmstocks.web.manifest</fusionManifest> <FusionManifest> fmstocks.web.manifest </ fusionManifest>

</deployment> </ Deployment>

<hostConstraints> <HostConstraints>

<hostConstraint hostClass="IIS"> <HostConstraint hostClass = "IIS">

<constraints>/[sessiontStateType="SQL"]</constraints> <Constraints> / [sessiontStateType = "SQL"] </ constraints>

</hostConstraint> </ HostConstraint>

</hostConstraints> </ HostConstraints>

</componentType> </ ComponentType>

논리적 배치(Logical Placement) Logical arrangement (Logical Placement)

SDU가 배포되기에 앞서, 우선 목표 배포 환경 상에서 유형들을 논리적으로 배치(placement)해야 한다. SDU prior to deployment, priority should be logically placed (placement) of the type on the target deployment environment. 논리적 배치는 설계시에 이루어질 수 있다. Logical arrangement can be made in the design. 요구 및 제약 사항이 체크되며, 개발자는 오류 또는 경고를 알게 된다. Requirements and constraints are checked and the developer finds an error or warning. 논리적 배치의 결과는 SDU와는 별개의 파일에 캡쳐된다. The results of logical layout is captured in a separate file than SDU. SDU는 상이한 배포 환경(개발, 테스트, 생산 등)에 대한 상이한 논리적 배치를 가질 수 있다. SDU may have a different logical layout for different deployment (development, testing, production, etc.).

제약 체크는 각 컴포넌트, 포트 및 와이어 클래스에 지정된 XPath 및 XSD를 이용하여 구현된다. Pharmaceutical check is implemented using the XPath, and XSD assigned to each component, port, and wire class.

배포 환경 구축(Building the Deployment Environment) Build deployment (Building the Deployment Environment)

배포 환경은 SDM 모델을 이용하여 구축된다. Deployment environment is built using the SDM model. 도 22를 참조하자. Let's see Fig. 본질적으로, 이러한 환경은 상이한 계층에 있는 SDM 애플리케이션이다. In essence, this environment is an SDM application in the different layers. 컴포넌트, 포트 및 와이어 유형은 서비스 호스트, 네트워크 아키텍쳐 및 하드웨어를 구성하는 데 있어 동일한 방식으로 이용된다. Components, ports, and the wire type of configuring the host service, a network architecture and hardware is used in the same way. Whidbey 타임프레임(timeframe)에서는 오직 애플리케이션 계층의 배포를 지원한다. In Whidbey timeframe (timeframe) only supports the deployment of the application layer. ADS V2.0에서는 Service Host, Network 및 Hardware 계층을 배포할 수 있다. The ADS V2.0 you can distribute the Service Host, Network and Hardware layer. Visual Studio는 배포 환경을 제작하기 위한 설계자(designer)를 구축한다. Visual Studio builds the designer (designer) for making the deployment. Visual Studio는 이를 논리적 인프라스트럭처(Logical Infrastructure)라 칭한다. Visual Studio this is referred to as a logical infrastructure (Logical Infrastructure). 도 23은 예시 배포를 나타낸 것이다. Figure 23 shows an exemplary deployment.

인스턴스 요청 문서(Instance Request Document) Instance the requested document (Instance Request Document)

SDM 유형은 스케일 불변이며 어떤 스케일로도 생성될 수 있다. SDM types are scale invariant and can also be produced in any scale. 인스턴스 요청 문서는 생성될 필요가 있는 인스턴스들의 선언적 정의이며, 와이어링 토폴로지(wiring topology)를 포함한다. Instances requested document is the declarative definition of the instance that needs to be generated, and a wiring topology (wiring topology). 도 24는 예시 유형을 도시하고 있으며, 도 25는 예시 인스턴스 요청을 나타내고 있다. Figure 24 is illustrates an example type, indicates the request instance is illustrated Figure 25.

물리적 배치(Physical Placement) Physical layout (Physical Placement)

물리적 배치는 배포의 목표인 특정 호스트 인스턴스를 골라내는 동작이다. Physical layout is operated picking out a target of a specific instance of a host distribution. 물리적 배치는 논리적 배치에 의해 제약된다. Physical placement is constrained by the logical layout. 제약은 물리적 배치 도중에 유효성이 재검증(revalidate)된다. Pharmaceuticals are re-validated during the physical layout (revalidate). 도 26을 참조한다. See Figure 26.

배포(Deployment) Deployment (Deployment)

SDU, 논리적 배치 파일, 인스턴스 요청 및 물리적 배치 파일이 SDM 런타임에 공급된다. The SDU, logical arrangement file, instance request and the physical layout file are supplied to the SDM runtime. SDM 런타임은 클래스 및 호스트 관계에 기초하여 적합한 설치자를 호출한다. SDM runtime calls the appropriate installer on the basis of the class and the host relationship. 설치자는 새로운 인스턴스를 호스트상에 생성하고 이것이 유형상의 설정값에 일치하도록 구성하는 역할을 맡는다. Create a new instance of the installer on the host, and it assumes the role of configurations to match the settings on the type. SDM 런타임은 모든 인스턴스, 이들의 최종 설정값 및 배치의 데이터베이스를 유지한다. SDM runtime maintains a database of all instances, their final settings and placement. 런타임 API는 인스턴스 스페이스의 질의를 지원한다. Runtime API supports queries in the instance space.

SDM 스키마 설계 사양(SDM Schema Design Specification) SDM Schema Design Specification (SDM Schema Design Specification)

SDM 스키마의 세 가지 핵심 요소는 포트, 와이어 및 컴포넌트이다. Three key elements of the SDM schema is the port, wires and components. 포트는 통신 종단점(endpoint)을 나타내고, 컴포넌트는 분산형 애플리케이션의 부분을 나타내고, 와이어는 애플리케이션 부분 사이의 통신 링크를 나타낸다. Port represents a communication end-point (endpoint), component represents the portion of the distributed application, the wire represents the communications link between the application part. 이들은 세 가지 별개의 스페이스, 즉 자원 스페이스, 애플리케이션 스페이스 및 인스턴스 스페이스에서 상이한 형태로 나타난다. These three distinct spaces, that is, when in a resource space, application space, and the instance space into different forms.

자원 스페이스에서는 자원 클래스(이것으로부터 애플리케이션 스페이스 내의 애플리케이션이 구축됨)가 정의된다. The resource space is defined by the resource class (the application is built in the application space from it). 이들 클래스는 애플리케이션 부분들의 공통의 카테고리화를 제공하며, 이에 의해 넓은 범위의 애플리케이션에 대한 도구 지원을 가능하게 하며, 설계시에 유형 체크의 기초를 제공한다. These classes enables the tool support for a wide range of applications, and thereby provide a common categorization of the application portion, and provides the basis for type checking at design time. 이러한 핵심 클래스는 서비스 설계를 위한 포괄적인 피처(feature) 세트를 제공하고, 시간에 따라 천천히 변화하는 간주된다. These core classes provide a comprehensive feature (feature) set for service design, and is considered to change slowly over time.

애플리케이션 스페이스에서는 애플리케이션 유형이 구축된다. In the application space, the types of applications are built. 자원 클래스를 택하여 세부 사항을 채워 넣는 바, 예컨대 콘텐츠에 대한 링크를 제공하거나, 특성(property)들에 대한 설정값들을 제공하는 것이 그것이다. Select the resource class provides a link to a bar, for example, the content filling the details, or is it to provide the setting for the property (property). 그 후 포트 유형을 컴포넌트 유형과 연관시킴으로써 애플리케이션 유형으로부터 분산형 애플리케이션을 구축하는 바, 이는 복합 컴포넌트 유형 내의 컴포넌트 유형을 이용하고, 복합 컴포넌트 유형의 멤버들 사이의 통신 관계를 와이어 유형을 이용하여 기술함으로써 이루어진다. Then using the component type in the port type of the component type bar, to build a distributed application from the application type by associating with it a composite component type, by writing by the communication between the wire type, between the members of a composite component type achieved.

인스턴스 스페이스는 애플리케이션의 배포 및 실행 프로세스 도중에 생성되는 인스턴스들로 이루어진다. Instances space consists of the instance that is generated during the application deployment and execution process. 애플리케이션 스페이스에서 정의한 통신 관계를 SDM 런타임을 통해 공개함으로써 인스턴스들이 다른 인스턴스들을 찾을 수 있도록 해 준다. By publishing a communication relationship defined in the application space through the SDM runtime makes it so that instances can find other instances.

자원 클래스(Resource Classes) Resource Class (Resource Classes)

설계시에 구성을 체크한 후 실행시에 배포하기 위해 알아야 할 필요가 있는 애플리케이션의 요소를 정의하기 위해 자원 클래스를 이용한다. Use a resource class to define the elements of an application you need to know to deploy at run time, check the configuration in the design. 이들 요소는 다음과 같다. These elements are as follows:

a) 애플리케이션이 통신하는 대상이다. a) a destination for the communication application. 분산형 애플리케이션을 네트워크 토폴로지에 대하여 검증(verify)하기 위해서는, 애플리케이션의 부분들이 서로 통신하는 데 사용할 수 있는 프로토콜에 관하여 알아야 할 필요가 있다. In order to verify (verify) for the distributed application on the network topology, it is necessary to know about the protocol that can be used for parts of the application communicate with each other. 포트 클래스는 프로토콜 종단점을 기술하는 데 이용된다. Port class is used to describe a protocol endpoints. 와이어 클래스는 이들 종단점 사이에 구축될 수 있는 관계를 기술하는 데 이용된다. Wire class is used to describe the relationship can be established between these endpoints.

b) 애플리케이션에 적용되는 설정 및 애플리케이션이 배포되는 방법이다. b) a method of setting up and deploying the application to be applied to the application. 컴포넌트 클래스는 애플리케이션을 구축하는 데 이용될 수 있는 빌딩 블록을 정의 한다. Component class defines the building blocks that can be used to build applications. 컴포넌트 클래스는 그 컴포넌트에 특유한 양상을 제어하는 데 이용될 수 있는 설정을 정의하며, 상기 컴포넌트를 배포하는 데 제공될 수 있는 파일 및 스크립트들에 대한 스키마를 정의한다. Component class defines a set that can be used to control the specific aspects on the component, define the schema for the files and scripts that can be offered to deploy the components.

c) 애플리케이션이 정확히 기능하기 위해 의존하는 대상이다. c) is subject to the application rely on to function correctly. 정확히 동작하기 위해서 컴포넌트는 목표 환경에 이미 존재하는 소정의 기능에 의존할 수 있다. In order to accurately operate a component it may depend on the predetermined function that already exists in the target environment. 그 예로서는 IIS에 의존하는 웹 서비스가 있다. As examples there are web services that rely on IIS. 이러한 요건은 자원간의 호스팅 관계로서 표현한다. This requirement is expressed as a hosting relationship between resources. 이러한 관계를 이용하여, 특정한 애플리케이션이 특정 환경에서 실행될지 여부를 미리 체크할 수 있도록 해 주는 일단의 자원 유형에 대하여 의존 관계 트리(dependency tree)를 구축할 수 있다. Using these relationships, the specific application can build dependency trees (dependency tree) with respect to one type of resource that allows you to check in advance whether running in a particular environment.

애플리케이션 유형(Application Types) Application Type (Application Types)

애플리케이션 유형은 자원 스페이스에서 정의된 자원 클래스를 이용하여 구축될 수 있다. Types of applications can be built using the resources in the resource classes defined space. 포트 유형 및 와이어 유형은 이들 클래스로부터 파생되어 애플리케이션에 특유한 통신 링크가 모델링되고, 컴포넌트 유형이 구축되어 애플리케이션의 별개의 부분들이 모델링된다. Port types and wire types are derived from these classes and modeling the distinctive communication link to the application, the component type is built is modeled to a separate part of the application.

포트 유형은 애플리케이션에 특유한 양상을 기술하는 통신 종단점이다. Port type is a communication endpoint to describe the distinctive aspects to the application. 포트 자원을 취하여 이것의 애플리케이션 내에서의 용도에 특유한 정보를 제공한다. By taking the port resource provides information specific to the application in the application of this. SOAP 자원을 취하여 애플리케이션이 공개하는 기능을 정의하는 WSDL 파일을 제공하는 포트 유형이 그 예이다. This type of port that provides a WSDL file that defines the function of the application is publicly taking a SOAP resource is an example.

와이어 유형은 애플리케이션 특유의 통신 경로를 정의한다. Wire type defines the specific communication path applications. 와이어 유형은 특정한 와이어 자원을 호환 가능한 두 애플리케이션 종단점을 연결하는 것으로 한 정시킨다. Wire type is then defined as one that connects the two application endpoints available resources compatible with the particular wire. 예컨대 SOAP 와이어 자원을 취하여 이를 앞서 정의한 SOAP 포트 유형을 연결하는 것으로 한정시킬 수 있다. For example, by taking the wire SOAP resources it can be limited by connecting the SOAP defined by the port type it previously.

컴포넌트 유형은 독립적으로 배포될 수 있고 머신의 경계에 걸쳐 분산될 수 있는 애플리케이션의 부분들을 모델링하는 데 사용된다. Component types are to be deployed independently and is used to model the parts of the application that can be distributed across the boundaries of the machine. 예컨대 웹 프론트엔드(web frontend) 및 데이터베이스 백엔드(database backend)를 갖는 애플리케이션은 몇몇의 컴포넌트 유형으로 이루어질 수 있다. For example, an application with a Web front-end (web frontend) and the back-end database (database backend) can be made of several types of components. 이러한 경우 웹 서비스 자원을 취하여 이를 웹 프론트엔드 컴포넌트 유형을 생성하는 데 사용할 수 있고, 데이터베이스 자원을 취하여 데이터베이스 백엔드 컴포넌트 유형을 생성하는 데 사용할 수 있다. In this case, take the Web service resources and can use them to create Web front-end component types can be used to create a database back-end component type by taking the database resources. 그 후 적합한 포트 유형을 컴포넌트 유형에 추가함으로써 애플리케이션 인터페이스를 모델링한다. By adding the appropriate ports and then type the component types to model the application interface. 이것을 포트 멤버라 칭한다. This is called port members.

여기서 사용되는 복합 컴포넌트 유형은 새로운 컴포넌트 유형을 함께 형성하는 그룹 컴포넌트 유형이다. Composite component type that is used herein is a group which forms a component type with the new component type. 컴포넌트 유형을 복합 컴포넌트 유형 내에서 사용한 것을 컴포넌트 멤버라 칭한다. Using the component type within the multiple component types, referred to as component members. 앞서 정의한 와이어 유형을 이용하여, 컴포넌트 멤버가 공개하는 인터페이스를 다른 멤버에 대하여 연결시킨다. Using the above-defined type of wire, the connection for an interface that the component members of the public to other members. 이들은 복합 컴포넌트의 와이어 멤버가 된다. These are the wire member of the composite component.

복합 컴포넌트가 컴포넌트와 같이 보이도록 하기 위해서는, 이들이 인터페이스, 성능(capability) 및 요건을 컴포넌트와 마찬가지로 공개해야 할 필요가 있다. To look to the composite components, such as components, it is necessary that they should disclose the interfaces, performance (capability) and requirements as in the component. 이는 복합 컴포넌트의 컴포넌트 멤버로부터 포트 멤버들의 부분 집합(subset)을 위임하여 보냄(delegate out)으로써 이루어진다. This is done by sending to delegate a portion of the port member from the component members of the composite component set (subset) (delegate out).

컴포넌트의 요건을 충족하기 위해서는 일치하는 성능을 갖는 다른 컴포넌트 에 대하여 그 컴포넌트를 바인딩해야 한다. In order to meet the requirements of the component must bind the component against another component with a matching performance. 이를 프로세스 바인딩이라 칭한다. This process is referred to as binding.

예시 구현(Exemplary Implementation) Example implementation (Exemplary Implementation)

이 섹션에서는 SDM 모델의 요소를 정의하는 데 이용되는 XML 스키마에 관하여 설명한다. This section explains about the XML schema used to define the elements of the SDM model. 설정은 애플리케이션 및 자원 모두에 의해 사용되므로 이를 먼저 설명하고, 이어서 자원 클래스를 설명하고, 다음으로 애플리케이션을 설명한 후 마지막으로 인스턴스 스페이스를 설명한다. Setting will be described and finally the instance space after the application described in the following description, it first, followed by description of the resource class, and are used by both the application and resource.

네임 부여(Naming) Given name (Naming)

네임 스페이스는 클래스 및 유형이 정의될 수 있는 네임 부여 범위(naming scope)를 정의하는 데 이용된다. Namespaces are used to define the name given range of classes and types can be defined (naming scope). 네임 스페이스 내에서 모든 클래스 및 유형 네임은 고유하다. All classes and types within a namespace name is unique. 네임 스페이스는 네임, 버전 및 암호 키(cryptographic key; 네임 스페이스의 콘텐츠의 유효성을 검증하는 데 사용될 수 있음)에 의해 정의된다. The namespace name, version, and the encryption key; is defined by the (cryptographic key that can be used to validate the contents of the namespace).

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

파일 버전은 NNNN(0<N<65535) 형태의 네 부분의 숫자에 의해 정의된다. File version is defined by a number of four parts of NNNN (0 <N <65535) form.

<xs:simpleType name="fourPartVersionType"> <Xs: simpleType name = "fourPartVersionType">
<xs:annotation> <Xs: annotation>
<xs:documentation>Four part version numbers where the segments are in the range 0-65535 </xs:documentation> <Xs: documentation> Four part version numbers where the segments are in the range 0-65535 </ xs: documentation>
</xs:annotation> </ Xs: annotation>
<xs:restriction base="xs:string"> <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: 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: restriction>
</xs:simpleType> </ Xs: simpleType>

공개 키 토큰(public key token)은 16자의 16진 문자열(hex string)이며, 공개/개인 키 쌍 중 공개 부분을 식별한다. Public key token (public key token) identifies the 16 character string of hexadecimal (hex string), and the disclosure of the public / private key pair part. 문서는 개인 키를 이용하여 서명되며, 이에 의해 문서의 사용자는 공개 키를 이용하여 그 콘텐츠를 검증할 수 있다. Document is signed using the private key, so users can document by using the public key to verify the content.

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

네임 스페이스 내의 단순 네임(simple name)을 문자열을 이용하여 구축한다. A simple name (simple name) in the namespace to build using a string. 네임 스페이스는 다른 네임 스페이스를 현재의 네임 스페이스으로 도입(import)한 후 별칭(alias)을 그 네임 스페이스과 연관시킴으로써 다른 네임 스페이스를 참조할 수 있다. The namespace can be referred to by a different namespace associated with the introduction (import) alias (alias) after the current namespace name of the seupeyiseugwa different namespace.

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

클래스 및 유형에 대한 참조는 현재의 네임 스페이스에서 정의된 객체를 지 칭하는 단순 네임이거나 또는 다른 네임 스페이스에서 정의된 객체를 식별하기 위하여 별칭 및 단순 네임 모두를 이용하는 복합 네임(compound name)이다. Class, and references to the type name is a compound (compound name) use both aliases and simple names to identify objects defined in simple call or whether the objects defined in the current namespace name or another namespace.

설정(Settings) Setting (Settings)

자원 클래스 및 애플리케이션 유형 모두는 설정 스키마를 공개할 수 있다. All resource classes and types of applications can publish settings schema. 이 스키마는 새로운 포트, 와이어 또는 컴포넌트 유형이 클래스로부터 생성되는 경우나, 포트 유형이 컴포넌트 유형에 추가되는 경우나, 또는 와이어 유형 또는 컴포넌트 유형이 복합 컴포넌트 유형에서 사용되는 경우에 제공될 수 있는 값을 기술하는 데 이용된다. The value of this scheme is to be provided to the new port, If that, or type of port when the wire or component type is created from a class added to the component type and or type of wire or component type is used in the composite component types to be used for technology.

설정 스키마(Settings schema) Set schema (Settings schema)

설정 스키마는 XSD를 이용하여 기술된다. Setting the schema is described using XSD. 최초 릴리즈(release)를 위해, 단일 유형으로 제약되는 XSD의 부분 집합 및 요소 유형의 리스트를 이용한다. For the first release (release), it utilizes a list of subsets and the element type of the XSD is constrained to a single type.

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

설정값(Setting Values) Settings (Setting Values)

설정값은 유형이 클래스에 기초하여 생성되는 경우 또는 유형이 컴포넌트 또는 복합 컴포넌트 내에서 사용되는 경우에 제공된다. Setting is provided to the case to be used in the type or a component or composite component when the type is generated based on the class. 설정값은 적합한 설정 스키마에 따르는 XML 블록이다. Setting a block in accordance with the appropriate XML schema settings.

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

설정 플로우(Settings flow) Setting the flow (flow Settings)

설정 플로우는 설정값이 컴포넌트 유형으로부터 컴포넌트 유형의 멤버로 전달되도록 하는 데 사용된다. Settings flow is used to ensure that the set value is passed to the type of the component members from the component type. 설정 플로우는 유형에 의해 정의된 설정 스키마로부터 값을 선택하는 설정값 섹션의 XPATH를 이용하여 구현된다. Settings flow is implemented using XPATH of setting section for selecting a value from the set defined by the schema type.

SDM 네임 스페이스에서 정의된 특별한 속성(attribute)을 이용하여, 콘텐츠를 흘려보내고자 하는 값을 식별한다. Using the special property (attribute) as defined in the SDM name space, and identifies a value to send the content flowing character. 이 속성이 어떠한 요소 상에 존재하는 경우, 그 속성값은 유형에 대한 설정 스키마로의 XPath인 것으로 간주된다. If this attribute is present on any element, the attribute value is considered to be a set of XPath schema for the type.

설정 제약(Setting Constraints) Set constraints (Setting Constraints)

설정 제약은 설정값의 유효성을 검증 및 제약하는 데 사용된다. Setting constraints are used to verify the validity of the settings and constraints. 예컨대 IIS 서버는 자신이 호스팅하는 모든 웹 서비스에 대하여 이들의 설정값이 특정한 값 또는 특정 범위의 값으로 한정되기를 요구할 수 있다. For example, the IIS server may require to be hosting their own settings limited to a specific value or values ​​in a specific range for all Web services. XPATH(또는 완전히 지원되는 경우 XQUERY)는 설정값의 유효성을 검증하는 데 이용된다. XPATH (or if fully supported XQUERY) is used to validate the set value. 이하의 질의 양식(forms of query)이 지원된다. This is less of a support inquiry form (forms of query).

- 경로가 존재해야 함 - Good paths must exist

- 경로가 존재하지 않아야 함 - Good path must not exist

- 경로가 존재하는 경우[(경로가 존재해야 함|경로가 존재하지 않아야 함) * ] - If the path exists [(path must exist | should not be the path must exist) *]

첫 번째 양식을 이용하여 특정한 값 또는 값의 집합으로 설정이 설정될 것을 요구할 수 있으며, 두 번째 양식을 이용하여 어떤 값 또는 값의 집합으로 설정이 설정되지 않을 것을 요구할 수 있으며, 세 번째 양식을 이용하여 함께 설정되어야 할 설정의 조합을 필요로 하는 설정 사이의 관계를 구축할 수 있다. May require first using a second form may require that the settings may be set to a set of specific values, or values, both using a second form does not set this setting to set the value or values, using the third form a combination of settings to be set together may establish a relationship between the setting that requires.

<xs:complexType name="settingConstraints"> <Xs: complexType name = "settingConstraints">
<xs:sequence> <Xs: sequence>
<xs:element name="mustExist" type="simpleTest" <Xs: element name = "mustExist" type = "simpleTest"
minOccurs="0" maxOccurs="unbounded"/> minOccurs = "0" maxOccurs = "unbounded" />
<xs:element name="mustNotExist" type="simpleTest" <Xs: element name = "mustNotExist" type = "simpleTest"
minOccurs="0" maxOccurs="unbounded"/> minOccurs = "0" maxOccurs = "unbounded" />
<xs:element name="ifExists" type="nestedTest" <Xs: element name = "ifExists" type = "nestedTest"
minOccurs="0" maxOccurs="unbounded"/> minOccurs = "0" maxOccurs = "unbounded" />
<xs:element name="ifNotExists" type="nestedTest" <Xs: element name = "ifNotExists" type = "nestedTest"
minOccurs="0" maxOccurs="unbounded"/> minOccurs = "0" maxOccurs = "unbounded" />
</xs:sequence> </ Xs: sequence>
</xs:complexType> </ Xs: complexType>

<xs:attributeGroup name="testAttributes"> <Xs: attributeGroup name = "testAttributes">
<xs:attribute name="path" type="xs:string"/> <Xs: attribute name = "path" type = "xs: string" />
<xs:attribute name="ifNullPath" type="ifNullPath"/> <Xs: attribute name = "ifNullPath" type = "ifNullPath" />
<xs:attribute name="error" type="xs:int"/> <Xs: attribute name = "error" type = "xs: int" />
<xs:attribute name="errorDesc" type="xs:string"/> <Xs: attribute name = "errorDesc" type = "xs: string" />
</xs:attributeGroup> </ Xs: attributeGroup>

<xs:complexType name="simpleTest"> <Xs: complexType name = "simpleTest">
<xs:attributeGroup ref="testAttributes"/> <Xs: attributeGroup ref = "testAttributes" />
</xs:complexType> </ Xs: complexType>

<xs:complexType name="nestedTest"> <Xs: complexType name = "nestedTest">
<xs:sequence> <Xs: sequence>
<xs:element name="mustExist" type="simpleTest" <Xs: element name = "mustExist" type = "simpleTest"
minOccurs="0" maxOccurs="unbounded"/> minOccurs = "0" maxOccurs = "unbounded" />
<xs:element name="mustNotExist" type="simpleTest" <Xs: element name = "mustNotExist" type = "simpleTest"
minOccurs="0" maxOccurs="unbounded"/> minOccurs = "0" maxOccurs = "unbounded" />
<xs:element name="ifExists" type="nestedTest" <Xs: element name = "ifExists" type = "nestedTest"
minOccurs="0" maxOccurs="unbounded"/> minOccurs = "0" maxOccurs = "unbounded" />
<xs:element name="ifNotExists" type="nestedTest" <Xs: element name = "ifNotExists" type = "nestedTest"
minOccurs="0" maxOccurs="unbounded"/> minOccurs = "0" maxOccurs = "unbounded" />
</xs:sequence> </ Xs: sequence>
<xs:attributeGroup ref="testAttributes"/> <Xs: attributeGroup ref = "testAttributes" />
</xs:complexType> </ Xs: complexType>

경로가 존재하지 않는 경우 이를 처리하기 위한 옵션이 공개될 필요가 있다. If the path does not exist, it is necessary to have the option to process it to be published. 이하는 설계자로 하여금 오류를 야기하거나, 값을 삽입하거나 또는 테스트를 무시하는 것을 선택할 수 있도록 해 준다. Or less makes it so that you can choose to allow the designer to lead to errors, inserting, or ignore the value tested.

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

예시 example

이하는 컴퓨터 클래스가 공개할 수 있는 단순한 스키마 모델링 값이다. The following is a simple schema modeling values ​​in the computer classes to the public. 이 스키마는 노드 아래의 설정 그룹 및 세 특성을 식별하는 단일 최상위 노드(top level node)를 갖는다. This scheme has a single top-level node (top level node) to identify the characteristics of the three groups and set down the node.

<settingSchema> <SettingSchema>
<xs:schema> <Xs: schema>
<xs:element name="processorSettings"> <Xs: element name = "processorSettings">
<xs:complexType> <Xs: complexType>
<xs:sequence> <Xs: sequence>
<xs:element name="numberOfCpus" type="xs:int"/> <Xs: element name = "numberOfCpus" type = "xs: int" />
<xs:element name="memory" type="xs:int" /> <Xs: element name = "memory" type = "xs: int" />
<xs:element name="dualHomed" type="xs:boolean"/> <Xs: element name = "dualHomed" type = "xs: boolean" />
</xs:sequence> </ Xs: sequence>
</xs:complexType> </ Xs: complexType>
</xs:element> </ Xs: element>
</xs:schema> </ Xs: schema>
</settingSchema> </ SettingSchema>

이하의 값을 유형 내에서 스키마에 대하여 제공할 수 있다. A value less than or equal in type can be provided for the schema.

<settings> <Settings>
<processorSettings> <ProcessorSettings>
<numberOfCpus>4</numberOfCpus> <NumberOfCpus> 4 </ numberOfCpus>
<memory>8000</memory> <Memory> 8000 </ memory>
<dualHomed>false</dualHomed> <DualHomed> false </ dualHomed>
</processorSettings> </ ProcessorSettings>
</settings> </ Settings>

유형이 사용된 경우에 설정값을 제공하고자 하면, 설정 플로우를 이용한다. When to provide a set value when the type is used, it uses a set flow.

이들 값에 대하여 제약이 기록될 수 있다. There are constraints may be written with respect to these values. 예컨대 첫 번째는 단순한 mustExist 제약이다. For example, the first is the simple mustExist constraints. 두 번째 제약은 중첩 제약(nested constraints)을 평가(evaluate)할지 여부를 결정하기 위한 테스트를 이용한다. The second constraint is used in a test to determine whether the overlap constraints (nested constraints) to assess (evaluate).

<constraints> <Constraints>

<mustExist path="ProcessorSettings/[memory >= 1000]" <MustExist path = "ProcessorSettings / [memory> = 1000]"
errorDesc="Host machine does not have enough memory"/> errorDesc = "Host machine does not have enough memory" />

<ifExists path="ProcessorSettings/[cpu >= 2]" <IfExists path = "ProcessorSettings / [cpu> = 2]"
errorDesc="Host machine has two processors but not enough resources"> errorDesc = "Host machine has two processors but not enough resources">

<mustExist path="ProcessorSettings/[memory >= 2000]" <MustExist path = "ProcessorSettings / [memory> = 2000]"
errorDesc="Host machine does not have enough memory"/> errorDesc = "Host machine does not have enough memory" />
</ifExists > </ IfExists>

</constraints> </ Constraints>

자원(Resources) Resources (Resources)

베이스 클래스(Base Class) Base class (Base Class)

모든 자원 클래스는 클래스로부터 파생된다. All resource class is derived from the class. 이들은 설정 스키마, 배포 스키마 및 네임 및 계층 속성을 공유한다. Share a set schema, deploy the schema and layer names and attributes. 설정 스키마는 그 클래스에 기초한 유형에 적용되는 설정, 이들이 취할 수 있는 값, 그리고 각각의 기술(description)을 기술한다. Setting the schema settings applied based on the type of the class, describe the value, and each technology (description) in which they take. 배포 스키마는 그 자원에 기초한 유형을 배포하는 데 필요한 정보를 기술한다. Deploy schema describes the information required to deploy based on the type of the resource. 계층 속성은 자원은 설계 스페이스에 있는 한 계층에 대하여 자원을 연관시킨다. Layer property resources and associate resources with respect to the hierarchy in the design space. 네임 속성은 네임 스페이스 내에서 클래스에게 고유의 네임을 부여하는 데 사용된다. Name attribute is used to give a unique name to the class in a namespace.

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

배포 스키마에 대해서, 네임 스페이스는 정의되지 않은 상태로 남는다. For the deployment schema, the namespace remains undefined. 스키마에 대한 제약은 그 전체가 클래스에 대한 설치자의 책임이다. Constraints on the schema is the responsibility of the installer for the whole class.

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

배포 섹션의 일부로서 제공되는 값은 관련 배포 스키마와 일치해야 한다. Values ​​that are provided as part of the deployment section shall be consistent with the relevant schema deployment.

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

계층 속성은 4개의 계층 유형을 열거한 것이다. Layer property is listed with four-layer type. 애플리케이션 계층은 데이터베이스 및 웹서버와 같은 고수준 애플리케이션 컴포넌트를 포함한다. The application layer includes a high-level application components, such as databases and web servers. 서비스 계층은 IIS 및 SQL과 같은 미들웨어(middleware) 서비스를 포함한다. Service layer includes a middleware (middleware) services, such as IIS and SQL. 네트워크 계층은 운영 체제, 기억장치 및 네트워크 정의를 포함한다. The network layer contains the operating system, storage, and network definitions. 하드웨어 계층은 데이터 센터의 하드웨어 컴포넌트의 정의를 포함한다. Hardware layer includes the definition of the hardware components of the data center.

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

포트 클래스 Port Class

포트 클래스는 자원 기초 유형에서 앞서 정의된 어떤 정보도 포함하지 않는다. Port class does not contain any information as defined in the resource base types.

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

컴포넌트 클래스 Component Class

컴포넌트 클래스는 허용되는 포트 클래스들의 리스트를 추가함으로써 베이스 클래스를 확장시킨다. Component class extends the base class by adding a list of allowed port class.

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

포트 클래스들의 리스트는 열리거나 닫힐 수 있으며, 닫혀 있는 경우에는 리스트에 나타나 있는 클래스에 기초한 포트 유형만이 관련 컴포넌트 유형에서 사용될 수 있다. If the list of ports classes may be opened or closed, closed, there is a port type (s) based on the classes that appear on the list may be used in the relevant component type. minOccurs 및 maxOccurs 속성은 이들 포트 유형들 중 하나가 사용될 수 있는 횟수를 정의한다. minOccurs and maxOccurs attribute defines the number of times that one of these port types can be used.

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

와이어 클래스 Class Wire

와이어 클래스도 또한 허용되는 포트 클래스들의 리스트를 추가함으로써 베이스 클래스를 확장시킨다. By adding the list of the port class that also allow the wire class extends the base class. 이 경우 리스트는 와이어 유형과 관련될 수 있는 포트 유형의 클래스들을 정의한다. In this case, the list defines the class of the port type that can be related to the type of wire.

<x<xs:complexType name="wireClass"> <X <xs: complexType name = "wireClass">
<xs:complexContent> <Xs: complexContent>
<xs:extension base="class"> <Xs: extension base = "class">
<xs:sequence> <Xs: sequence>
<xs:element name="portClassesAllowed" type="portClassesAllowed" minOccurs="0" maxOccurs="1"/> <Xs: element name = "portClassesAllowed" type = "portClassesAllowed" minOccurs = "0" maxOccurs = "1" />
</xs:sequence> </ Xs: sequence>
</xs:extension> </ Xs: extension>
</xs:complexContent> </ Xs: complexContent>
</xs:complexType> </ Xs: complexType>

호스팅 관계 Hosting Relationship

호스팅 관계는 소스 클래스, 목표 클래스 및 설치자를 식별하는 트리플(triple)을 정의한다. Hosting relationship defines a triple (triple) to identify the source class and target class, and installers. 관계의 존재는 소스 클래스에 기초한 유형의 인스턴스가 목표 클래스에 기초한 유형의 인스턴스 및 상기 관계와 관련된 설치자를 이용하여 생성될 수 있음을 가리킨다. The presence of the relationship indicates that it can be produced using the installer related to the type of an instance of the class based on the source type and the instance relations based on the target class. 목표 클래스는 컴포넌트 클래스이어야 한다. Target class should be a component class.

예컨대 웹 서비스는 IIS 클래스 및 웹 서비스 설치자와의 호스팅 관계에서 소스 클래스일 수 있다. For example, a Web service can be a source class in the hosting relationship between IIS Web service class and installers. 이 경우 상기 관계는 설치자를 이용하여 MyIIS 유형상에 MyWebService 유형의 인스턴스를 생성할 수 있음을 가리킨다. In this case, the relationship indicates that it is possible to use the installer creates an instance of the type MyWebService on MyIIS type. 애플리케이션 스페이스 및 인스턴스 스페이스 모두에 존재하는 제약을 평가하기 전까지는, 관계를 생성할 수 있을지 여부를 알지 못한다. Before assessing the constraints that exist in both the application and the instance space is the space, I do not know whether we can create a relationship.

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

설치자는 네임, 코드 유형 및 설치자를 구현하는 바이너리에 대한 링크에 의해 식별된다. It is identified by a link to the binary implementation of the installation The name, type code and installers.

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

예시 example

이들 예는 확장된 4 계층의 예시로부터 발췌된 것이다. These examples are taken from the example of a four-layer expansion. 세부 사항을 위해서는 완전한 예시 파일을 참조하면 된다. For details, see the complete example is when you file.

우선 데이터베이스에 대한 액세스를 모델링하기 위해 소정의 포트 클래스들을 생성한다. First, create a class to model a given port access to the database. 이 경우 서버 포트 및 클라이언트 포트가 존재한다. In this case, the client port and server port exists.

<portClass name="ServerDataAccess" layer="Application"> <PortClass name = "ServerDataAccess" layer = "Application">
<settingSchema> <SettingSchema>
<xs:schema> <Xs: schema>
<xs:complexType> <Xs: complexType>
<xs:sequence> <Xs: sequence>
<xs:element name="databaseName" type="xs:string"/> <Xs: element name = "databaseName" type = "xs: string" />
<!-- other connection string properties --> <-! Other connection string properties ->
</xs:sequence> </ Xs: sequence>
</xs:complexType> </ Xs: complexType>
</xs:schema> </ Xs: schema>
</settingSchema> </ SettingSchema>
</portClass> </ PortClass>
<portClass name="ClientDataAccess" layer="Application"/> <PortClass name = "ClientDataAccess" layer = "Application" />

그 후 상기 두 포트 클래스들 사이의 통신 링크를 모델링하는 와이어 클래스를 생성한다. After that generates the wire class of modeling a communications link between the two port class. 와이어 클래스는 앞서 정의된 두 포트 클래스에 대한 설정 및 참조 를 갖는다. Wire class has a set and a reference to the two ports classes defined above. 이 경우 와이어 제약은 접속에 대해서 오직 하나의 서버가 있어야 하며, 클라이언트 포트는 복수의 서버에 걸쳐 접속들의 로드 밸런스(load balance)를 어떻게 해야할지 알지 못한다는 사실을 모델링한다. In this case, the wire constraint must have only one server, for the connection, and the client port will know how to model the fact, it is not able to determine the load balancing (load balance) of connection over a plurality of servers. 더욱 복잡한 와이어 구현에 의해 복수의 서버를 허용할 수 있고, 접속을 해결하기 위해 소정 형태의 관리를 구현할 수 있도록 해 준다. To allow the plurality of servers by a more complex implementation of the wire, and makes it to implement a control of a predetermined form to fix the connection.

<wireClass name="DataConnection" layer="Application"> <WireClass name = "DataConnection" layer = "Application">
<settingSchema> <SettingSchema>
<xs:schema> <Xs: schema>
<xs:complexType> <Xs: complexType>
<xs:sequence> <Xs: sequence>
<xs:element name="useSSL" type="xs:boolean"/> <Xs: element name = "useSSL" type = "xs: boolean" />
</xs:sequence> </ Xs: sequence>
</xs:complexType> </ Xs: complexType>
</xs:schema> </ Xs: schema>
</settingSchema> </ SettingSchema>
<portClassesAllowed> <PortClassesAllowed>
<portClassRef name="ServerDataAccess" maxOccurs="1"/> <PortClassRef name = "ServerDataAccess" maxOccurs = "1" />
<portClassRef name="ClientDataAccess"/> <PortClassRef name = "ClientDataAccess" />
</portClassesAllowed> </ PortClassesAllowed>
</wireClass> </ WireClass>

마지막으로 데이터베이스를 모델링하는 컴포넌트 클래스를 생성한다. Finally, create a component class that models the database. 이 클래스는 설정 및 배포 스키마를 가지며, 이 클래스에 기초한 컴포넌트 유형상에 존재할 수 있는 포트들을 식별한다. It has the set up and deploy the schema, identify the ports that may be present on the component type based on the class.

<componentClass name="Database" layer="Application"> <ComponentClass name = "Database" layer = "Application">
<deploymentSchema> <DeploymentSchema>
<xs:schema> <Xs: schema>
<xs:complexType> <Xs: complexType>
<xs:sequence> <Xs: sequence>
<xs:element name="sqlScriptFilePath" type="xs:string" maxOccurs="unbounded"/> <Xs: element name = "sqlScriptFilePath" type = "xs: string" maxOccurs = "unbounded" />
</xs:sequence> </ Xs: sequence>
</xs:complexType> </ Xs: complexType>
</xs:schema> </ Xs: schema>
</deploymentSchema> </ DeploymentSchema>
<settingSchema> <SettingSchema>
<xs:schema> <Xs: schema>
<xs:complexType> <Xs: complexType>
<xs:sequence> <Xs: sequence>
<xs:element name="databaseName" type="xs:string"/> <Xs: element name = "databaseName" type = "xs: string" />
</xs:sequence> </ Xs: sequence>
</xs:complexType> </ Xs: complexType>
</xs:schema> </ Xs: schema>
</settingSchema> </ SettingSchema>
<portClassesAllowed closed="true"> <PortClassesAllowed closed = "true">
<portClassRef name="ServerDataAccess"/> <PortClassRef name = "ServerDataAccess" />
</portClassesAllowed> </ PortClassesAllowed>
</componentClass> </ ComponentClass>

이러한 모든 컴포넌트들은 호환 가능한 호스트 유형에 대하여 매핑될 필요가 있다. All these components need to be mapped against a compatible host type. 이 경우 SQL 서버는 서버 포트에 대한 호스트로서 작용하고, 데이터베이스 및 IIS는 SQL 클라이언트 포트에 대한 호스트로서 작용한다. If SQL Server is acting as a host for the server, port, and database and IIS acts as the host for the SQL client port. 이들 클래스는 미들웨어로 별칭되는 별개의 네임 스페이스에서 정의된다. These classes are defined in a separate namespace alias middleware.

<hostRelations> <HostRelations>

<installer name="DatabaseInstaller" codeType="InstallerPlugin"/> <Installer name = "DatabaseInstaller" codeType = "InstallerPlugin" />

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

<hostRelation classRef="ServerDataAccess" <HostRelation classRef = "ServerDataAccess"
componentHostClassRef=" middleware:SQL" componentHostClassRef = "middleware: SQL"
installerRef="DatabaseInstaller"/> installerRef = "DatabaseInstaller" />

<hostRelation classRef="ClientDataAccess" <HostRelation classRef = "ClientDataAccess"
componentHostClassRef=" middleware:IIS" componentHostClassRef = "middleware: IIS"
installerRef="WebServiceInstaller"/> installerRef = "WebServiceInstaller" />

</hostRelations> </ HostRelations>

애플리케이션 Applications

애플리케이션 개발자는 컴포넌트, 포트 및 와이어 유형을 애플리케이션 스페이스에서 생성함으로서 그의 애플리케이션을 모델링한다. Application developers modeled his application by creating a component, port and wire types in the application space. 이들 유형은 개발자가 작업하고 있는 계층과 일치하는 클래스를 선택하고 그 클래스에 대한 값을 공급함으로써 생성된다. These types are generated by selecting a class that matches the hierarchy that developers are working to supply a value for that class.

애플리케이션 베이스 유형(Application base type) Application database type (Application base type)

모든 애플리케이션 유형 스키마는 이하의 애플리케이션 베이스 스키마를 기초로 한다. Any type of application schema is based on the application database schema below. 베이스 스키마 속성은 상기 유형이 기초한 클래스 및 그 유형의 네임을 식별한다. Base schema attribute identifies the class and the type of the name is based on the type. 스키마의 본체(body)에서는 그 유형이 배포될 수 있도록 해 주는 배포값과, 관련 클래스 상의 설정 스키마에 대한 설정을 식별한다. In the body (body) of the schema identifies the deployment values ​​and settings for the settings schema on related classes that make that type can be deployed. 유형은 또한 그 유형이 다른 유형 내에서 사용되는 경우에 제공될 수 있는 값들을 식별하는 새로운 설정 스키마를 정의한다. Type also defines a new scheme set up to identify the values ​​that can be provided in the case in which the type is used in different types. 마지막으로 베이스 유형은 호스트 제약을 위한 섹션을 포함한다. Finally, the base types include a section for host restriction. 이 섹션은 이 유형과 관련된 클래스를 위한 자원 스페이스 내에 존재하는 호스트 관계에 기초한, 그 유형에 대한 가능한 호스트 상의 제약을 식별한다. This section is based on the relationship between the host present in the resource space to a class related to this type, and identifies the possible constraints on the host for that type.

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

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

<xs:element name="settings" type="settingsValues" <Xs: element name = "settings" type = "settingsValues"
minOccurs="0" maxOccurs="1"/> minOccurs = "0" maxOccurs = "1" />

<xs:element name="settingSchema" type="settingSchema" <Xs: element name = "settingSchema" type = "settingSchema"
minOccurs="0" maxOccurs="1"/> minOccurs = "0" maxOccurs = "1" />

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

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

hostConstraints 섹션은 그 유형과 관련된 클래스를 호스팅할 수 있는 클래스 각각에 대한 일단의 제약을 포함한다. The hostConstraints section including one of the constraints for each class that can host a class associated with that type. 이들 클래스는 자원 스페이스 내의 호스트 관계에 의해 식별된다. These classes are identified by the host relationship in the resource space. 이들 클래스와 관련된 제약은 설정 스키마 및 클래스에 관한 것이다. Constraints associated with these classes is related to a set schema and class. 제약의 양식은 앞서 정의된 바 있다. Form of Pharmaceutical bar is defined above.

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

포트 유형 Port Type

포트 유형은 단순히 베이스 유형을 이용한다. Port types are simply uses the base type. 포트 유형과 관련된 더 이상의 정보가 존재하지 않는다. Further information related to the port type does not exist.

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

와이어 유형 Wire Type

와이어 유형은 베이스 유형을 확장함으로써 허용 가능한 포트 유형의 리스트를 추가한다. Wire type and adds a list of allowable port type by extending the base type. 이들 포트 유형을 사용하는 것은 복합 컴포넌트 내에서 와이어 유형을 이용하는 것과 관련될 수 있다. The use of these port types may be associated with using a wire type, in the composite component. 와이어 유형을 이러한 방식으로 정의함으로써, 애플리케이션 설계자는 단지 호환 가능한 포트 유형에 대하여 와이어 유형을 생성하는 것에 의해 그의 애플리케이션의 부분들 사이의 허용 가능한 일단의 접속을 제약할 수 있다. By defining a type of wire in this way, the application designer can constrain the allowable one end of connection between the part of his application by simply creating a wire type with respect to a compatible port type.

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

컴포넌트 유형 Component Type

컴포넌트 유형은 베이스 유형을 확장함으로써 포트 멤버의 리스트 및 호스팅 되는 클래스의 리스트를 추가한다. Component type list and add a list of classes and hosting of the port members by extending the base type.

각 포트 멤버는 기존의 포트 유형을 사용한 것이다. Each port members will use the existing port type. 호스팅된 클래스의 리스트는 그 컴포넌트가 호스팅할 수 있는 클래스들을 식별한다. The list of hosting class identifies the class to the component is hosted. 이들 클래스들은 자원 스페이스의 호스트 관계에 의해 식별되는 클래스들의 부분 집합이며, 이 경우 이러한 유형의 클래스는 잠재적인 호스트로서 식별된다. These classes are a subset of the classes that are identified by a host of related resources, space, and in this case this type of class is identified as a potential host.

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

포트 리스트에 있는 포트 멤버 각각은 네임 및 유형에 의해 식별된다. Each member ports in the port list is identified by name and type. 포트 네임은 컴포넌트 내에서 고유해야 한다. Port Name should be unique within the component. 포트 유형은 이러한 컴포넌트 유형과 관련된 컴포넌트 클래스에서 허용되는 관련 포트 클래스를 가져야 한다. Port Type the port should have a relevant component classes are allowed in the class associated with this type of component. 각 포트 멤버에 대하여, 포트 유형에 의해 정의되는 스키마와 일치하는 설정의 리스트를 제공할 수 있다. For each member port can provide a list of the settings that match the schema defined by the type of port.

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

호스팅된 클래스 리스트(hosted classes list)의 각각의 클래스에 대하여 제약 리스트(a list of constraints)를 결합할 수 있다. For each class of the class list of hosts (hosted list classes) it may be bonded to the constraint list (a list of constraints). 이러한 제약들은 호스팅된 클래스의 설정 스키마(setting schema)에 관하여 쓰여진 것이다. These constraints will be written about in the settings of the host class schema (setting schema).

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

복합 컴포넌트 유형(Compound Component Type) Composite component type (Compound Component Type)

복합 컴포넌트 유형(본 명세서에서는 복합 컴포넌트라고 칭한다)은 새로운 컴포넌트 유형을 정의한다. Multiple component types (herein referred to as the composite components) defines a new type of component. 복합 컴포넌트를 정의할 때, 그 유형의 멤버들이 같은 곳에 배치(co-located)되어야 한다고 명시할 것인지의 여부를 선택할 수 있다. When defining a composite component, you can choose whether or not to specify that where a member of that type have the same arrangement (co-located) should be. 만 약 멤버들이 같은 곳에 배치되어 있다면, 상기 유형이 배포되는 경우 그 유형의 모든 멤버들은 단일 호스트 상에 배포되어야 한다. If only approx members are arranged in the same place, if the type of deployment all members of that type are to be deployed on a single host. 복합 컴포넌트는 또한 컴포넌트 멤버의 리스트, 와이어 멤버의 리스트, 상기 컴포넌트가 위임(delegate)하는 포트를 정의하는 섹션 및 상기 컴포넌트가 호스팅할 수 있는 클래스를 식별하는 리스트를 포함한다. Composite component also includes a list that identifies a class with the section and the component that defines the port on which the list, the list, the component members of the wire of the component members are delegated (delegate) can host.

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

컴포넌트 리스트는 이미 정의된 컴포넌트 유형을 사용하는 것을 식별하며 이를 상기 복합 컴포넌트의 컴포넌트 멤버라고 부른다. Component list to identify the use of the already-defined component type, and call it the component members of the composite component. 각각의 멤버는 복합 컴포넌트 내의 고유한 네임, 그 멤버를 정의하는 유형에 대한 참조 및 그 멤버가 싱글톤(singleton)인지 아닌지를 지시하는 플래그를 갖는다. Each member has a flag indicative of a unique name, a reference to the type that defines the members and the members in the composite component whether singleton (singleton).

컴포넌트 멤버가 싱글톤이라고 표시된 경우에는, 그 멤버를 포함하는 복합 컴포넌트의 인스턴스에서 이 컴포넌트 멤버의 인스턴스는 오직 하나만이 존재할 수 있다. If labeled component member is a singleton, then at the instance of the composite component instance of the component members including the members can only be only one. 그것이 싱글톤이라고 표시되지 않은 경우에는, 멤버의 인스턴스들은 로드 변화와 같은 외적 요인에 따라 생성되고 삭제될 수 있다. If it is not marked as a singleton, the instance of a member can be created and deleted along with external factors such as the load changes. 이는 싱글톤이 아닌 멤버와 연결된 컴포넌트 멤버라면 어느 멤버든지 런타임(runtime)에 그 싱글톤이 아닌 멤버의 인스턴스를 하나 또는 그 이상 볼 수 있다는 것을 의미한다. This means that, if the connected component members and non-members Singleton any member at any one instance of its members that are not singletons at runtime (runtime) or to see more.

각각의 컴포넌트 멤버는 또한 관련된 컴포넌트 유형에서 정의된 설정 스키마에 대한 설정 값(setting values)을 제공할 수 있다. Each component Members may also provide the setting for the settings schema defined in the relevant type of component (setting values).

<xs:complexType name="components"> <Xs: complexType name = "components">
<xs:sequence> <Xs: sequence>
<xs:element name="component" minOccurs="0" maxOccurs="unbounded"> <Xs: element name = "component" minOccurs = "0" maxOccurs = "unbounded">
<xs:complexType> <Xs: complexType>
<xs:sequence> <Xs: sequence>
<xs:element name="settings" type="settingValues" minOccurs="0" maxOccurs="1"/> <Xs: element name = "settings" type = "settingValues" minOccurs = "0" maxOccurs = "1" />
</xs:sequence> </ Xs: sequence>
<xs:attribute name="name" type="xs:string" use="required"/> <Xs: attribute name = "name" type = "xs: string" use = "required" />
<xs:attribute name="type" 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: attribute name = "singleton" type = "xs: boolean" use = "optional" default = "false" />
</xs:complexType> </ Xs: complexType>
</xs:element> </ Xs: element>
</xs:sequence> </ Xs: sequence>
</xs:complexType> </ Xs: complexType>

복합 컴포넌트에서 와이어 유형을 사용하는 것을 와이어 멤버라고 한다. Called wire members to use the type of wire in the composite component. 각각의 와이어 멤버는 그 복합 컴포넌트에 대하여 고유한 네임(name)으로서, 관련된 와이어 유형을 식별시켜주는 네임을 갖는다. Each of the wire members of a unique name (name) with respect to the composite component has a name, which to identify the related wire type. 와이어 멤버는 또한 와이어 유형에서 정의된 설정 스키마에 대한 설정 값을 제공할 수 있다. Wire members may also provide the setting for the settings schema defined in the wire type.

와이어 멤버의 주된 역할은 복합 컴포넌트 내에서 컴포넌트 멤버간의 연결을 식별하는 것이다. The main role of the wire members is to identify the connection between the component members in the composite component. 이는 와이어 멤버에 포트 참조를 덧붙이는 방법으로 행해진다. This is done in a manner to provide further reference port to the wire member. 각각의 포트 참조는 복합 컴포넌트 내의 컴포넌트 멤버 상의 포트를 식별한다. Each port reference identifies the port on the component members in the composite component. 참 조 포트의 포트 유형은 상기 와이어 유형과 관련된 포트 유형과 일치(match)해야 한다. The port type of the reference port should match the port type (match) associated with the type of wire.

<xs:complexType name="wires"> <Xs: complexType name = "wires">
<xs:sequence> <Xs: sequence>
<xs:element name="wire" minOccurs="0" maxOccurs="unbounded"> <Xs: element name = "wire" minOccurs = "0" maxOccurs = "unbounded">
<xs:complexType> <Xs: complexType>
<xs:sequence> <Xs: sequence>

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

<xs:element name="members" minOccurs="1" maxOccurs="1"> <Xs: element name = "members" minOccurs = "1" maxOccurs = "1">
<xs:complexType> <Xs: complexType>
<xs:sequence> <Xs: sequence>
<xs:element name="member" type="componentPortRef" minOccurs="0" maxOccurs="unbounded"/> <Xs: element name = "member" type = "componentPortRef" minOccurs = "0" maxOccurs = "unbounded" />
</xs:sequence> </ Xs: sequence>
</xs:complexType> </ Xs: complexType>
</xs:element> </ Xs: element>
</xs:sequence> </ Xs: sequence>
<xs:attribute name="name" type="xs:string" use="required"/> <Xs: attribute name = "name" type = "xs: string" use = "required" />
<xs:attribute name="type" type="xs:string"/> <Xs: attribute name = "type" type = "xs: string" />
</xs:complexType> </ Xs: complexType>
</xs:element> </ Xs: element>
</xs:sequence> </ Xs: sequence>
</xs:complexType> </ Xs: complexType>

포트 참조는 컴포넌트 멤버를 포함하는 복합 컴포넌트 내에서 그 컴포넌트 멤버를 식별한다. Port reference identifies the component members in the composite component including a component member. 포트 네임은 상기 컴포넌트 멤버와 관련된 컴포넌트 유형 상의 포트 멤버의 네임이다. Port Name is the name of the member ports on the associated component type and the component members.

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

복합 컴포넌트와 관련되고 포트 멤버가 바인딩할 수 있는 코드가 없기 때문 에 복합 컴포넌트는 포트 유형을 직접적으로 사용할 수 없다. Is associated with a composite component because there is no code in the port member can bind the composite component can not directly use the port type. 그 대신 복합 컴포넌트의 컴포넌트 멤버들로부터 포트 멤버들이 위임을 받는다(delegate out). The port member from the component members of the complex components instead they receive a delegation (delegate out). 이는 복합 컴포넌트가 컴포넌트 유형으로서 사용될 때 이러한 포트들이 그들이 복합 컴포넌트에 속하는 것처럼 나타나는 것을 의미한다. This means that this port will appear as if they belong to the composite component when the composite component used as the component type.

포트가 위임을 받으면, 먼저 컴포넌트 멤버를 식별하고 그 다음에 그 컴포넌트 내의 포트 멤버를 식별함으로써 그 포트가 식별된다. The port is receiving the delegation, its ports are identified by first identifying a component members and identify the port members within the component to the next. 이 과정의 일부로서 포트의 네임이 바뀔 수도 있는데 이는 상이한 컴포넌트 멤버들로부터 동일한 네임을 갖는 포트들이 위임을 받는 경우 그 네임이 서로 충돌하는 것을 막기 위한 것이다. There as part of the process may change the name of the port on which port if they have the same names from different component members receiving the delegation is to prevent that a name conflict.

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

다양한 범위의 상이한 클래스에 대하여 서비스를 제공할 수 있는 호스트를 구성하기 위하여 복합 컴포넌트가 그의 컴포넌트 멤버들로부터 호스팅된 클래스 선언(hosted class declarations)을 공개하는 것이 허용된다. To disclose the composite components hosted from the component members of his class declaration (hosted class declarations) to configure a host that can provide services to a wide range of different classes is allowed. 복합 컴포넌트가 컴포넌트 유형으로서 사용되는 때에는, 이 복합 컴포넌트는 모든 선언된 클래스에 대하여 호스트로서의 역할을 할 수 있다고 보여진다. If that is the composite component is used as a type of component, composite components are shown that they can act as a host to all the declared class.

이러한 호스팅된 클래스 선언을 공개하기 위하여 포트 멤버를 위임했던 방법 과 유사한 방법으로 위임(delegation)이 사용된다. The delegation hosted a class declaration in a way that the delegation members and the port similar manner to the public (delegation) is used. 호스팅된 클래스를 포함하는 컴포넌트 멤버를 식별하고, 그 후 그 컴포넌트가 호스팅할 수 있다고 요청하는 클래스를 식별한다. Identify the component members including the hosting class and identify classes to request that the component can then be hosted.

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

바인딩 Binding

바인딩은 특정한 복합 컴포넌트의 멤버에 대하여 호스트를 식별하는 프로세스이다. Binding is the process of identifying the host against members of a particular composite component. 이는 애플리케이션과 그 애플리케이션이 호스팅될 환경 사이의 호환성을 검사하고 그 애플리케이션을 배포하기 위하여 행해진다. This is done to check the compatibility between the application and the application is hosted environment to deploy their applications. 애플리케이션과 호스트 환경은 모두 복합 컴포넌트를 사용하여 모델링되며 따라서 바인딩 프로세스는 멤버간의 연결 토폴로지(connection topology)를 지원(support)하는 서로 대응(match)하는 멤버를 양 컴포넌트로부터 찾는 것이다. Application and the host environment is modeled using all the composite components according binding process is to find the members corresponding to (match) with each other to support the connection topology (connection topology) between the members (support) from both components.

멤버에 대하여 호환 가능한 호스트를 식별하기 위하여, 리소스 공간에서 클래스들 사이의 관계의 검토를 시작한다. To identify a compatible host for the members, and start a review of the relationship between the classes in the resource space. 먼저 와이어 또는 컴포넌트 멤버의 유형을 검토한 후 그 멤버와 관련된 클래스를 식별한다. First, review the types of wire or component members identify the relevant class and its members. 그 다음에는 호스트 컴포넌트에서 호스트 컴포넌트의 멤버들의 컴포넌트 유형과 관련된 호환 가능한 클래스를 갖는 컴포넌트 멤버들을 찾는다. Then look for the component members having compatible classes related to the component type of the component members of the host from the host component. 그 후 상기 (와이어 또는 컴포넌트) 멤버와 관련된 유형 상의 호스트 제약을 검토하고 그 제약이 호스트 멤버의 유형 상의 설정과 대응하는지를 본다. After reviewing the constraints on the type of host associated with the (wire or component) members and see if the constraint and the corresponding settings on the type of host members. 그 다음에는 이와 반대로 호스트 멤버의 유형 상의 hostedClass 제약을, 호스팅하기를 원하는 멤버의 유형 상의 설정에 대하여 점검한다. Then check with respect to the contrary on the type of members you want to set a restriction on the type of host hostedClass members to host.

컴포넌트 멤버를 대응시키려고 하는 경우에는, 그 컴포넌트 멤버의 유형을 갖는 모든 포트 멤버들이 그 컴포넌트 멤버에 대한 어떠한 잠재적인 호스트 상에라도 호스팅될 수 있는지를 점검할 필요가 있다. If you try to respond to the component members, it is necessary to all its port members having the type of component members are checking whether it can be hosted on In any potential host for its component members.

와이어 멤버를 대응시키려고 하는 경우에는, 호스팅하려고 하는 복합 컴포넌트의 컴포넌트 멤버를 위하여 선택한 호스트들간의 경로 상에 존재하는 컴포넌트 멤버라면 어느 것이든지 대응시켜 보아야 한다. If you try to respond to the wire member you have, if present on the path between the selected host to the component members of the complex components that attempt to host the component members must see to correspond to any one.

앞선 예에서 설명된 포트 클래스를 기반으로, 두 가지의 포트 유형을 생성한다. Based on the port class described in the preceding example, it produces two types of ports.

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

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

이러한 유형들은 와이어 유형에 의해 주어진다. These types are given by the wire type.

<wireType name="UserData" class="DataConnection"> <WireType name = "UserData" class = "DataConnection">
<deployment/> <Deployment />
<settings> <Settings>
<useSSL>false</useSSL> <UseSSL> false </ useSSL>
</settings> </ Settings>
<portTypeRefs> <PortTypeRefs>
<portTypeRef name="UserDataServer"/> <PortTypeRef name = "UserDataServer" />
<portTypeRef name="UserDataClient"/> <PortTypeRef name = "UserDataClient" />
</portTypeRefs> </ PortTypeRefs>
</wireType> </ WireType>

이제 데이터베이스 클래스에 기초한 컴포넌트 유형이 생성된다. Now the component type based on the database class is created. 데이터 베이스 유형은 하나의 서버 데이터 포트를 공개한다. Database type exposes a single server data port.

<componentType name="UserData" class="Database"> <ComponentType name = "UserData" class = "Database">
<deployment> <Deployment>
<sqlScriptFilePath>%install%\mydatabaseDfn.sql</sqlScriptFilePath> <SqlScriptFilePath>% install% \ mydatabaseDfn.sql </ sqlScriptFilePath>
</deployment> </ Deployment>
<settings> <Settings>
<databaseName>UserData</databaseName> <DatabaseName> UserData </ ​​databaseName>
</settings> </ Settings>
<ports> <Ports>
<port name="userData" type="UserDataServer"/> <Port name = "userData" type = "UserDataServer" />
</ports> </ Ports>
</componentType> </ ComponentType>

이러한 유형들 중 일부를 사용하는 복합 컴포넌트 유형을 생성할 수 있었다. Composite component type that uses some of these types could be created. 이하의 복합 컴포넌트는 세 가지 컴포넌트 유형을 사용한다. Composite components under the use of three types of components. 제1 유형 UserPages는 두 접근점(access point)을 갖는 웹 서비스를 나타내고 제2 유형 QueryManagement는 미들 계층 논리 컴포넌트(middle tier logic component)이며 마지막 유형은 우리의 데이터베이스 유형이다. The first type is UserPages two access points (access point) represents a web service having a second type of QueryManagement is a middle-tier logical components (middle tier logic component) The last type is our database types. 이러한 컴포넌트들을 두 와이어 유형, 즉 UserData 및 QueryManager를 사용하여 연결한다. These two components, wire type, that is connected using the UserData and QueryManager. 데이터 와이어는 미들 계층을 데이터베이스와 연결하고 쿼리 와이어는 프론트엔드(frontend)를 미들 계층와 연결한다. Data wire is connected to the middle layer and the database query and the wire connecting the middle gyecheungwa the front end (frontend). 그 후 두 포트, 즉 signup 및 enquiry를 위임(deligation)을 사용하여 프론트엔드로부터 공개시킨다. Then using two ports, that is delegated to signup and enquiry (deligation) thus released from the front-end.

<compoundComponentType name="UserManagementApplication"> <CompoundComponentType name = "UserManagementApplication">
<components> <Components>
<component name="userPages" type="UserPages"/> <Component name = "userPages" type = "UserPages" />
<component name="queryLogic" type="QueryManagement"/> <Component name = "queryLogic" type = "QueryManagement" />
<component name="userData" type="UserData" singleton="true"/> <Component name = "userData" type = "UserData" singleton = "true" />
</components> </ Components>
<wires> <Wires>
<wire name="data" type="UserData"> <Wire name = "data" type = "UserData">
<members> <Members>
<member componentName="queryLogic" portName="userData"/> <Member componentName = "queryLogic" portName = "userData" />
<member componentName="userData" portName="userData"/> <Member componentName = "userData" portName = "userData" />
</members> </ Members>
</wire> </ Wire>
<wire name="query" type="QueryManager"> <Wire name = "query" type = "QueryManager">
<members> <Members>
<member componentName="userPages" portName="queryManager1"/> <Member componentName = "userPages" portName = "queryManager1" />
<member componentName="userPages" portName="queryManager2"/> <Member componentName = "userPages" portName = "queryManager2" />
<member componentName="queryLogic" portName="queryManager"/> <Member componentName = "queryLogic" portName = "queryManager" />
</members> </ Members>
</wire> </ Wire>
</wires> </ Wires>
<delegatePorts> <DelegatePorts>
<delegatePort name="signup" componentName="userPages" <DelegatePort name = "signup" componentName = "userPages"
portName="signup"/> portName = "signup" />
<delegatePort name="enquiry" componentName="userPages" <DelegatePort name = "enquiry" componentName = "userPages"
portName="enquiry"/> portName = "enquiry" />
</delegatePorts> </ DelegatePorts>
</compoundComponentType> </ CompoundComponentType>

SDM 문서 구조 SDM Document Structure

SDM 문서는 문서의 네임스페이스(namespace)를 정의하는 강한 본질을 지니고 있다. SDM document has the strongest essence that defines the namespace (namespace) of the document. SDM 문서는 다른 네임스페이스에 대한 참조의 리스트를 가져 온다(import). SDM document fetches a list of references to other namespaces (import). 이 문서는 또한 문서 소유자, 회사명 및 수정된 날짜와 같은 문서의 특정 속성(document specific attribute)을 확인하게 하는 정보 섹션을 포함한다. This article also includes information sections that identify specific attributes (document specific attribute) of a document, such as document owner, company name, and date modified. 문서는 그 다음에 포트, 와이어 및 컴포넌트 클래스들의 리스트, 이어서 호스트 관계들의 리스트, 차례로 이어서 포트, 와이어 및 컴포넌트 유형들의 리스트를 포함한다. The document is then a list of ports, wire and component classes, followed by a list, in order of then-host relationship, including a list of ports, wire and component types.

<xs:element name="sdm"> <Xs: element name = "sdm">
<xs:annotation> <Xs: annotation>
<xs:documentation>SDM 최상위 요소(SDM root element)이다. <Xs: documentation> SDM is a top-level element (SDM root element). 이는 SDM 유형을 위한 컨테이너이다. This is a type of container for the SDM.
</xs:documentation> </ Xs: documentation>
</xs:annotation> </ Xs: annotation>
<xs:complexType> <Xs: complexType>
<xs:sequence> <Xs: sequence>
<xs:element name="import" type="import" minOccurs="0" maxOccurs="unbounded"/> <Xs: element name = "import" type = "import" minOccurs = "0" maxOccurs = "unbounded" />
<xs:element name="information" type="information" minOccurs="0" maxOccurs="1"/> <Xs: element name = "information" type = "information" minOccurs = "0" maxOccurs = "1" />
<xs:element name="portClasses" minOccurs="0" maxOccurs="1"> <Xs: element name = "portClasses" minOccurs = "0" maxOccurs = "1">
<xs:complexType> <Xs: complexType>
<xs:sequence> <Xs: sequence>
<xs:element name="portClass" type="portClass" minOccurs="1" maxOccurs="unbounded"/> <Xs: element name = "portClass" type = "portClass" minOccurs = "1" maxOccurs = "unbounded" />
</xs:sequence> </ Xs: sequence>
</xs:complexType> </ Xs: complexType>
</xs:element> </ Xs: element>
<xs:element name="wireClasses" minOccurs="0" maxOccurs="1"> <Xs: element name = "wireClasses" minOccurs = "0" maxOccurs = "1">
<xs:complexType> <Xs: complexType>
<xs:sequence> <Xs: sequence>
<xs:element name="wireClass" type="wireClass" minOccurs="1" maxOccurs="unbounded"/> <Xs: element name = "wireClass" type = "wireClass" minOccurs = "1" maxOccurs = "unbounded" />
</xs:sequence> </ Xs: sequence>
</xs:complexType> </ Xs: complexType>
</xs:element> </ Xs: element>
<xs:element name="componentClasses" minOccurs="0" maxOccurs="1"> <Xs: element name = "componentClasses" minOccurs = "0" maxOccurs = "1">
<xs:complexType> <Xs: complexType>
<xs:sequence> <Xs: sequence>
<xs:element name="componentClass" type="componentClass" minOccurs="1" maxOccurs="unbounded"/> <Xs: element name = "componentClass" type = "componentClass" minOccurs = "1" maxOccurs = "unbounded" />
</xs:sequence> </ Xs: sequence>


</xs:complexType> </ Xs: complexType>
</xs:element> </ Xs: element>
<xs:element name="hostRelations" minOccurs="0" maxOccurs="1"> <Xs: element name = "hostRelations" minOccurs = "0" maxOccurs = "1">
<xs:complexType> <Xs: complexType>
<xs:sequence> <Xs: sequence>
<xs:element name="installer" type="installer" minOccurs="1" maxOccurs="unbounded"/> <Xs: element name = "installer" type = "installer" minOccurs = "1" maxOccurs = "unbounded" />
<xs:element name="hostRelation" type="hostRelation" minOccurs="1" maxOccurs="unbounded"/> <Xs: element name = "hostRelation" type = "hostRelation" minOccurs = "1" maxOccurs = "unbounded" />
</xs:sequence> </ Xs: sequence>
</xs:complexType> </ Xs: complexType>
</xs:element> </ Xs: element>
<xs:element name="portTypes" minOccurs="0" <Xs: element name = "portTypes" minOccurs = "0"
maxOccurs="1"> maxOccurs = "1">
<xs:complexType> <Xs: complexType>
<xs:sequence> <Xs: sequence>
<xs:element name="portType" type="portType" minOccurs="0" maxOccurs="unbounded"/> <Xs: element name = "portType" type = "portType" minOccurs = "0" maxOccurs = "unbounded" />
</xs:sequence> </ Xs: sequence>
</xs:complexType> </ Xs: complexType>
</xs:element> </ Xs: element>
<xs:element name="wireTypes" minOccurs="0" maxOccurs="1"> <Xs: element name = "wireTypes" minOccurs = "0" maxOccurs = "1">
<xs:complexType> <Xs: complexType>
<xs:sequence> <Xs: sequence>
<xs:element name="wireType" type="wireType" minOccurs="0" maxOccurs="unbounded"/> <Xs: element name = "wireType" type = "wireType" minOccurs = "0" maxOccurs = "unbounded" />
</xs:sequence> </ Xs: sequence>
</xs:complexType> </ Xs: complexType>
</xs:element> </ Xs: element>
<xs:element name="componentTypes" minOccurs="0" maxOccurs="1"> <Xs: element name = "componentTypes" minOccurs = "0" maxOccurs = "1">
<xs:complexType> <Xs: complexType>
<xs:sequence> <Xs: sequence>
<xs:element name="componentType" type="componentType" minOccurs="0" maxOccurs="unbounded"/> <Xs: element name = "componentType" type = "componentType" minOccurs = "0" maxOccurs = "unbounded" />
<xs:element name="compoundComponentType" type="compoundComponentType" minOccurs="0" maxOccurs="unbounded"/> <Xs: element name = "compoundComponentType" type = "compoundComponentType" minOccurs = "0" maxOccurs = "unbounded" />
</xs:sequence> </ Xs: sequence>
</xs:complexType> </ Xs: complexType>
</xs:element> </ Xs: element>
</xs:sequence> </ Xs: sequence>
<xs:attributeGroup ref="identity"/> <Xs: attributeGroup ref = "identity" />
</xs:complexType> </ Xs: complexType>
</xs:element> </ Xs: element>

관련된 XSD(Associated XSD) Associated XSD (Associated XSD)

이하는 변화 요청(change request)에 대한 하나의 예시이다. The following is one example of a request for a change (change request).

<?xml version="1.0" encoding="utf-8" ?> <? 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" <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"> 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: sdmSettings" schemaLocation = "SDM7Settings.xsd" />

<xs:import namespace="urn:schemas-microsoft-com:sdmNames" schemaLocation="SDM7Names.xsd" /> <Xs: import namespace = "urn: schemas-microsoft-com: sdmNames" schemaLocation = "SDM7Names.xsd" />

<xs:complexType name="ChangeRequestType"> <Xs: complexType name = "ChangeRequestType">

<xs:sequence> <Xs: sequence>

<xs:element name="group" type="groupType" minOccurs="0" maxOccurs="unbounded" /> <Xs: element name = "group" type = "groupType" minOccurs = "0" maxOccurs = "unbounded" />

</xs:sequence> </ Xs: sequence>

</xs:complexType> </ Xs: complexType>

<xs:complexType name="groupType"> <Xs: complexType name = "groupType">

<xs:sequence> <Xs: sequence>

<xs:element name="group" type="groupType" minOccurs="0" maxOccurs="unbounded" /> <Xs: element name = "group" type = "groupType" minOccurs = "0" maxOccurs = "unbounded" />

<xs:element name="addInstance" type="addInstanceType" 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 = "updateInstance" type = "updateInstanceType" minOccurs = "0" maxOccurs = "unbounded" />

<xs:element name="deleteInstance" type="deleteInstanceType" 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 = "addConnection" type = "addConnectionType" minOccurs = "0" maxOccurs = "unbounded" />

<xs:element name="deleteConnection" type="deleteConnectionType" minOccurs="0" maxOccurs="unbounded" /> <Xs: element name = "deleteConnection" type = "deleteConnectionType" minOccurs = "0" maxOccurs = "unbounded" />

</xs:sequence> </ Xs: sequence>

<xs:attribute name="canLeConcurrentlyExecuted" type="xs:boolean" /> <Xs: attribute name = "canLeConcurrentlyExecuted" type = "xs: boolean" />

</xs:complexType> </ Xs: complexType>

<xs:complexType name="addInstanceType"> <Xs: complexType name = "addInstanceType">

<xs:sequence> <Xs: sequence>

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

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

<!-- setting values for class --> <-! Setting values ​​for class ->

<!-- setting values for type --> <-! Setting values ​​for type ->

</xs:sequence> </ Xs: sequence>

<xs:attribute name="parent" type="reference" use="optional" /> <Xs: attribute name = "parent" type = "reference" use = "optional" />

<xs:attribute name="host" type="reference" use="optional" /> <Xs: attribute name = "host" type = "reference" use = "optional" />

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

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

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

<!-- the parent of this instance --> <-! The parent of this instance ->

<!-- the host of this instance --> <-! The host of this instance ->

<!-- Name of the member on the parent type --> <-! Name of the member on the parent type ->

<!-- Fully qualified type that this is an instance of --> <-! Fully qualified type that this is an instance of ->

<!-- alias for the id that can be filled in when the instance is created. <-! 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. this name must be unique for all instances of the same member. --> ->

</xs:complexType> </ Xs: complexType>

<!-- what can we change about an instance? <-! What can we change about an instance? --> ->

<xs:complexType name="updateInstanceType"> <Xs: complexType name = "updateInstanceType">

<xs:sequence> <Xs: sequence>

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

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

<!-- setting values for class --> <-! Setting values ​​for class ->

<!-- setting values for type --> <-! Setting values ​​for type ->

</xs:sequence> </ Xs: sequence>

<xs:attribute name="id" type="reference" use="required" /> <Xs: attribute name = "id" type = "reference" use = "required" />

<xs:attribute name="parent" type="reference" use="optional" /> <Xs: attribute name = "parent" type = "reference" use = "optional" />

<xs:attribute name="host" type="reference" use="optional" /> <Xs: attribute name = "host" type = "reference" use = "optional" />

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

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

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

<!-- Unique identifier scoped to the SDM Runtime. <-! Unique identifier scoped to the SDM Runtime. This is generated by t_u101 ? This is generated by t_u101? SDM runtime SDM runtime

and is immutable --> and is immutable ->

<!-- the parent of this instance --> <-! The parent of this instance ->

<!-- the host of this instance --> <-! The host of this instance ->

<!-- Name of the member on the parent type --> <-! Name of the member on the parent type ->

<!-- Fully qualified type that this is an instance of --> <-! Fully qualified type that this is an instance of ->

<!-- alias for the id that can be filled in when the instance is created. <-! 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. this name must be unique for all instances of the same member. --> ->

</xs:complexType> </ Xs: complexType>

<xs:complexType name="deleteInstanceType"> <Xs: complexType name = "deleteInstanceType">

<xs:attribute name="id" type="reference" use="required" /> <Xs: attribute name = "id" type = "reference" use = "required" />

<xs:attribute name="option" type="deleteOptionType" use="required" /> <Xs: attribute name = "option" type = "deleteOptionType" use = "required" />

<!-- Unique identifier scoped to the SDM Runtime. <-! Unique identifier scoped to the SDM Runtime. This is generated by the SDM runtime This is generated by the SDM runtime

and is immutable -_cf2 > and is immutable -_cf2>

</xs:complexType> </ Xs: complexType>

<xs:complexType name="addConnectionType"> <Xs: complexType name = "addConnectionType">

<xs:attribute name="port" type="reference" use="required" /> <Xs: attribute name = "port" type = "reference" use = "required" />

<xs:attribute name="wire" type="reference" use="required" /> <Xs: attribute name = "wire" type = "reference" use = "required" />

</xs:complexType> </ Xs: complexType>

<xs:complexType name="deleteConnectionType"> <Xs: complexType name = "deleteConnectionType">

<xs:attribute name="port" type="reference" use="required" /> <Xs: attribute name = "port" type = "reference" use = "required" />

<xs:attribute name="wire" type="reference" use="required" /> <Xs: attribute name = "wire" type = "reference" use = "required" />

</xs:complexType> </ Xs: complexType>

<!-- reference can be guid or path --> <-! Reference can be guid or path ->

<xs:simpleType name="reference"> <Xs: simpleType name = "reference">

<xs:union></xs:union> <Xs: union> </ xs: union>

</xs:simpleType> </ Xs: simpleType>

<!-- delete options are: ??? <- delete options are:! ??? --> ->

<xs:simpleType name="deleteOptionType"> <Xs: simpleType name = "deleteOptionType">

<xs:union></xs:union> <Xs: union> </ xs: union>

</xs:simpleType> </ Xs: simpleType>

</xs:schema> </ Xs: schema>

이하는 클래스에 대한 예시적인 구조이다. The following is an exemplary structure for the class.

<?xml version="1.0" encoding="utf-8" ?> <? 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: 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 = "http://www.w3.org/2001/XMLSchema" />

<xs:import namespace="urn:schemas-microsoft-com:sdmSettings" schemaLocation="SDM7Settings.xsd" /> <Xs: import namespace = "urn: schemas-microsoft-com: sdmSettings" schemaLocation = "SDM7Settings.xsd" />

<xs:import namespace="urn:schemas-microsoft-com:sdmNames" schemaLocation="SDM7Names.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]:! 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]:! Is the layer attribute mandatory on a class? --> ->

<!-- TODO [BassamT]: Add keys and keyefs for validation --> <- TODO [BassamT]:! Add keys and keyefs for validation ->

<!-- TODO [BassamT]: Add support for inlined types --> <- TODO [BassamT]:! Add support for inlined types ->

<!-- TODO [BassamT]: scrub minOccurs and maxOccurs --> <- TODO [BassamT]:! Scrub minOccurs and maxOccurs ->

<!-- TODO [BassamT]: New name for "class", possibly "deployment" --> <- TODO [BassamT]:! New name for "class", possibly "deployment" ->

<!-- TODO [BassamT]: New name for "host", possibly "provider" --> <- TODO [BassamT]:! New name for "host", possibly "provider" ->

<!-- REVIEW [BassamT]: Can we merge the definitions of port, component, wire classs in this XSD. <- 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. It would make it less verbose at the cost more semantic analysis. --> ->

<!-- CONSIDER [BassamT]: General attribute mechanism for things like Singleton, Colocation, Inline. <- CONSIDER [BassamT]:! General attribute mechanism for things like Singleton, Colocation, Inline. --> ->

<!-- TODO [BassamT]: Bindings: member to component member --> <-! TODO [BassamT]: Bindings: member to component member ->

<!-- TODO [geoffo]: ports - are they singleton? <- TODO [geoffo]:! Ports - are they singleton? --> ->

<!-- TODO [geoffo]: delegation - how do we combine ports? <- TODO [geoffo]:! Delegation - how do we combine ports? --> ->

<!-- TODO [geoffo] Add back <any> in appropriate places --> <-! TODO [geoffo] Add back <any> in appropriate places ->

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

<!-- SDM root element --> <-! SDM root element ->

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

<xs:element name="sdmClasses"> <Xs: element name = "sdmClasses">

<xs:complexType> <Xs: complexType>

<xs:sequence> <Xs: sequence>

<xs:element name="import" type="names:import" minOccurs="0" maxOccurs="unbounded" /> <Xs: element name = "import" type = "names: import" minOccurs = "0" maxOccurs = "unbounded" />

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

<xs:element name="portClasses" minOccurs="0"> <Xs: element name = "portClasses" minOccurs = "0">

<xs:complexType> <Xs: complexType>

<xs:sequence> <Xs: sequence>

<xs:element name="portClass" type="portClass" maxOccurs="unbounded" /> <Xs: element name = "portClass" type = "portClass" maxOccurs = "unbounded" />

</xs:sequence> </ Xs: sequence>

</xs:complexType> </ Xs: complexType>

</xs:element> </ Xs: element>

<xs:element name="componentClasses" minOccurs="0"> <Xs: element name = "componentClasses" minOccurs = "0">

<xs:complexType> <Xs: complexType>

<xs:sequence> <Xs: sequence>

<xs:element name="componentClass" type="componentClass" maxOccurs="unbounded" /> <Xs: element name = "componentClass" type = "componentClass" maxOccurs = "unbounded" />

</xs:sequence> </ Xs: sequence>

</xs:complexType> </ Xs: complexType>

</xs:element> </ Xs: element>

<xs:element name="protocols" minOccurs="0"> <Xs: element name = "protocols" minOccurs = "0">

<xs:complexType> <Xs: complexType>

<xs:sequence> <Xs: sequence>

<xs:element name="protocol" type="protocol" maxOccurs="unbounded" /> <Xs: element name = "protocol" type = "protocol" maxOccurs = "unbounded" />

</xs:sequence> </ Xs: sequence>

</xs:complexType> </ Xs: complexType>

</xs:element> </ Xs: element>

<xs:element name="hostRelations" minOccurs="0"> <Xs: element name = "hostRelations" minOccurs = "0">

<xs:complexType> <Xs: complexType>

<xs:sequence> <Xs: sequence>

<xs:element name="installer" type="installer" maxOccurs="unbounded" /> <Xs: element name = "installer" type = "installer" maxOccurs = "unbounded" />

<xs:element name="hostRelation" type="hostRelation" maxOccurs="unbounded" /> <Xs: element name = "hostRelation" type = "hostRelation" maxOccurs = "unbounded" />

</xs:sequence> </ Xs: sequence>

</xs:complexType> </ Xs: complexType>

</xs:element> </ Xs: element>

</xs:sequence> </ Xs: sequence>

<xs:attributeGroup ref="names:namespaceIdentity" /> <Xs: attributeGroup ref = "names: namespaceIdentity" />

</xs:complexType> </ Xs: complexType>

</xs:element> </ Xs: element>

<!-- SDM type library information --> <-! SDM type library information ->

<xs:complexType name="information"> <Xs: complexType name = "information">

<xs:annotation> <Xs: annotation>

<xs:documentation>Human readable information about the SDM type library.</xs:documentation> . <Xs: documentation> Human readable information about the SDM type library </ xs: documentation>

</xs:annotation> </ Xs: annotation>

<xs:sequence> <Xs: sequence>

<xs:element name="friendlyName" type="xs:string" minOccurs="0" /> <Xs: element name = "friendlyName" type = "xs: string" minOccurs = "0" />

<xs:element name="companyName" 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 = "copyright" type = "xs: string" minOccurs = "0" />

<xs:element name="trademark" 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 = "description" type = "xs: string" minOccurs = "0" />

<xs:element name="comments" type="xs:string" minOccurs="0" /> <Xs: element name = "comments" type = "xs: string" minOccurs = "0" />

</xs:sequence> </ Xs: sequence>

</xs:complexType> </ Xs: complexType>

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

<!-- Classes --> <-! Classes ->

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

<xs:complexType name="baseClass"> <Xs: complexType name = "baseClass">

<xs:sequence> <Xs: sequence>

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

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

<!-- XSD schema that for how a class is deployed --> <-! XSD schema that for how a class is deployed ->

<!-- Setting schema --> <-! Setting schema ->

</xs:sequence> </ Xs: sequence>

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

<xs:attribute name="layer" 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 <-! REVIEW [BassamT] Are these layers just for benefit of tools, or are they

strictly enforced in the SDM model? strictly enforced in the SDM model? There are There are

cases where mixing components from different layers makes cases where mixing components from different layers makes

sense. sense. For example, the filter component might be a For example, the filter component might be a

a component meta type hosted ISA server which lives in layer 3. a component meta type hosted ISA server which lives in layer 3.

However, we want to use the Filter meta-type in layer 2. --> However, we want to use the Filter meta-type in layer 2. ->

</xs:complexType> </ Xs: complexType>

<!-- port class --> <-! Port class ->

<xs:complexType name="portClass"> <Xs: complexType name = "portClass">

<xs:complexContent> <Xs: complexContent>

<xs:extension base="baseClass" /> <Xs: extension base = "baseClass" />

</xs:complexContent> </ Xs: complexContent>

</xs:complexType> </ Xs: complexType>

<!-- Component class --> <-! Component class ->

<xs:complexType name="componentClass"> <Xs: complexType name = "componentClass">

<xs:complexContent> <Xs: complexContent>

<xs:extension base="baseClass"> <Xs: extension base = "baseClass">

<xs:sequence> <Xs: sequence>

<xs:element name="portClassesAllowed" minOccurs="0"> <Xs: element name = "portClassesAllowed" minOccurs = "0">

<xs:complexType> <Xs: complexType>

<xs:sequence> <Xs: sequence>

<xs:element name="portClassRef" minOccurs="0" maxOccurs="unbounded" /> <Xs: element name = "portClassRef" minOccurs = "0" maxOccurs = "unbounded" />

</xs:sequence> </ Xs: sequence>

<xs:attribute name="closed" type="xs:boolean" use="optional" default="true" /> <Xs: attribute name = "closed" type = "xs: boolean" use = "optional" default = "true" />

<!-- Whether the allowable ports is closed list --> <-! Whether the allowable ports is closed list ->

<!-- If this value is "true" then the list of ports is non-extensible. <-! 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. If this value is "false" then the list of ports is open-ended, the ports listed will be considered mandatory. --> ->

</xs:complexType> </ Xs: complexType>

</xs:element> </ Xs: element>

<!-- this will specify a set of constraints on the set of allowable ports <-! 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. that can show up on a component type of this meta type. --> ->

</xs:sequence> </ Xs: sequence>

</xs:extension> </ Xs: extension>

</xs:complexContent> </ Xs: complexContent>

</xs:complexType> </ Xs: complexType>

<xs:complexType name="portClassRef"> <Xs: complexType name = "portClassRef">

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

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

<xs:attribute name="singleton" 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 --> <-! Singleton implies that there can only be one instance of this port within the parents scope ->

</xs:complexType> </ Xs: complexType>

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

<!-- relations --> <-! Relations ->

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

<xs:complexType name="relation"> <Xs: complexType name = "relation">

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

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

</xs:complexType> </ Xs: complexType>

<!-- a protocol is a relationship between one or more port classes --> <-! A protocol is a relationship between one or more port classes ->

<xs:complexType name="protocol"> <Xs: complexType name = "protocol">

<xs:complexContent> <Xs: complexContent>

<xs:extension base="relation"> <Xs: extension base = "relation">

<xs:sequence> <Xs: sequence>

<xs:element name="portClassRef" type="portClassRef" maxOccurs="unbounded" /> <Xs: element name = "portClassRef" type = "portClassRef" maxOccurs = "unbounded" />

</xs:sequence> </ Xs: sequence>

</xs:extension> </ Xs: extension>

</xs:complexContent> </ Xs: complexContent>

</xs:complexType> </ Xs: complexType>

<!-- defines the host relationship between two classs --> <-! Defines the host relationship between two classs ->

<xs:complexType name="hostRelation"> <Xs: complexType name = "hostRelation">

<xs:complexContent> <Xs: complexContent>

<xs:extension base="relation"> <Xs: extension base = "relation">

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

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

</xs:extension> </ Xs: extension>

</xs:complexContent> </ Xs: complexContent>

</xs:complexType> </ Xs: complexType>

<!-- the installer type identifes the code responsible for instantiating a relationship --> <-! The installer type identifes the code responsible for instantiating a relationship ->

<xs:complexType name="installer"> <Xs: complexType name = "installer">

<xs:sequence> <Xs: sequence>

<xs:element name="binary" type="xs:string" /> <Xs: element name = "binary" type = "xs: string" />

</xs:sequence> </ Xs: sequence>

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

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

</xs:complexType> </ Xs: complexType>

</xs:schema> </ Xs: schema>

이하는 배포 유닛(deployment unit)에 대한 예시적인 구조이다. The following is an exemplary structure for the distribution unit (deployment unit).

<?xml version="1.0" encoding="UTF-8" ?> <? 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: 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 = "http://www.w3.org/2001/XMLSchema" />

<xs:import namespace="urn:schemas-microsoft-com:sdmNames" schemaLocation="SDM7Names.xsd" /> <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 --> <-! 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: element name = "sdmDeploymentUnit">

<xs:annotation> <Xs: annotation>

<xs:documentation> <Xs: documentation>

The sdu contains a mapping of SDM types to their implementation. The sdu contains a mapping of SDM types to their implementation.

</xs:documentation> </ Xs: documentation>

</xs:annotation> </ Xs: annotation>

<xs:complexType> <Xs: complexType>

<xs:sequence> <Xs: sequence>

<xs:element name="import" type="names:import" minOccurs="0" maxOccurs="unbounded" /> <Xs: element name = "import" type = "names: import" minOccurs = "0" maxOccurs = "unbounded" />

<xs:element name="implementation" type="implementationMap" minOccurs="0" maxOccurs="unbounded" /> <Xs: element name = "implementation" type = "implementationMap" minOccurs = "0" maxOccurs = "unbounded" />

</xs:sequence> </ Xs: sequence>

</xs:complexType> </ Xs: complexType>

</xs:element> </ Xs: element>

<!-- a description of this deployment unit --> <-! A description of this deployment unit ->

<xs:complexType name="deploymentDescription"> <Xs: complexType name = "deploymentDescription">

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

<xs:attribute name="dateCreated" type="xs:string" /> <Xs: attribute name = "dateCreated" type = "xs: string" />

<xs:attribute name="creator" type="xs:string" /> <Xs: attribute name = "creator" type = "xs: string" />

</xs:complexType> </ Xs: complexType>

<!-- a mapping from a type to an implementation of the type --> <-! A mapping from a type to an implementation of the type ->

<xs:complexType name="implementationMap"> <Xs: complexType name = "implementationMap">

<xs:sequence> <Xs: sequence>

<xs:element name="version" type="xs:string" minOccurs="0" maxOccurs="unbounded" /> <Xs: element name = "version" type = "xs: string" minOccurs = "0" maxOccurs = "unbounded" />

</xs:sequence> </ Xs: sequence>

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

<xs:attribute name="path" type="xs:string" /> <Xs: attribute name = "path" type = "xs: string" />

</xs:complexType> </ Xs: complexType>

</xs:schema> </ Xs: schema>

이하는 인스턴스에 대한 예시적인 구조이다. The following is an exemplary structure for the instance.

<?xml version="1.0" encoding="utf-8" ?> <? 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: 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 = "http://www.w3.org/2001/XMLSchema" />

<xs:import namespace="urn:schemas-microsoft-com:sdmSettings" schemaLocation="SDM7Settings.xsd" /> <Xs: import namespace = "urn: schemas-microsoft-com: sdmSettings" schemaLocation = "SDM7Settings.xsd" />

<xs:element name="sdmInstances"> <Xs: element name = "sdmInstances">

<xs:complexType> <Xs: complexType>

<xs:sequence> <Xs: sequence>

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

<xs:element name="portInstances" minOccurs="0"> <Xs: element name = "portInstances" minOccurs = "0">

<xs:complexType> <Xs: complexType>

<xs:sequence> <Xs: sequence>

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

</xs:sequence> </ Xs: sequence>

</xs:complexType> </ Xs: complexType>

</xs:element> </ Xs: element>

<xs:element name="wireInstances" minOccurs="0"> <Xs: element name = "wireInstances" minOccurs = "0">

<xs:complexType> <Xs: complexType>

<xs:sequence> <Xs: sequence>

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

</xs:sequence> </ Xs: sequence>

</xs:complexType> </ Xs: complexType>

</xs:element> </ Xs: element>

<xs:element name="componentInstances" minOccurs="0"> <Xs: element name = "componentInstances" minOccurs = "0">

<xs:complexType> <Xs: complexType>

<xs:sequence> <Xs: sequence>

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

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

</xs:sequence> </ Xs: sequence>

</xs:complexType> </ Xs: complexType>

</xs:element> </ Xs: element>

</xs:sequence> </ Xs: sequence>

</xs:complexType> </ Xs: complexType>

</xs:element> </ Xs: element>

<xs:complexType name="import"> <Xs: complexType name = "import">

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

<xs:attributeGroup ref="identity" /> <Xs: attributeGroup ref = "identity" />

</xs:complexType> </ Xs: complexType>

<!-- ================== Instance Schema =============== --> <-! ================== Instance Schema =============== ->

<xs:complexType name="instanceBase"> <Xs: complexType name = "instanceBase">

<xs:sequence> <Xs: sequence>

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

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

<!-- setting values for class --> <-! Setting values ​​for class ->

<!-- setting values for type --> <-! Setting values ​​for type ->

</xs:sequence> </ Xs: sequence>

<xs:attribute name="id" type="guid" use="required" /> <Xs: attribute name = "id" type = "guid" use = "required" />

<xs:attribute name="parent" type="guid" use="optional" /> <Xs: attribute name = "parent" type = "guid" use = "optional" />

<xs:attribute name="host" type="guid" use="optional" /> <Xs: attribute name = "host" type = "guid" use = "optional" />

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

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

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

<!-- Unique identifier scoped to the SDM Runtime. <-! Unique identifier scoped to the SDM Runtime. This is generated by the SDM runtime This is generated by the SDM runtime

and is immutable --> and is immutable ->

<!-- the parent of this instance --> <-! The parent of this instance ->

<!-- the host of this instance --> <-! The host of this instance ->

<!-- Name of the member on the parent type --> <-! Name of the member on the parent type ->

<!-- Fully qualified type that this is an instance of --> <-! 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. <-! 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>

<xs:complexType name="componentInstance"> <Xs: complexType name = "componentInstance">

<xs:complexContent> <Xs: complexContent>

<xs:extension base="instanceBase"> <Xs: extension base = "instanceBase">

<xs:sequence> <Xs: sequence>

<xs:element name="portInstances"> <Xs: element name = "portInstances">

<xs:complexType> <Xs: complexType>

<xs:sequence> <Xs: sequence>

<xs:element name="portInstance" type="instanceRef" /> <Xs: element name = "portInstance" type = "instanceRef" />

<!-- the port Instances that I own --> <-! The port Instances that I own ->

</xs:sequence> </ Xs: sequence>

</xs:complexType> </ Xs: complexType>

</xs:element> </ Xs: element>

</xs:sequence> </ Xs: sequence>

</xs:extension> </ Xs: extension>

</xs:complexContent> </ Xs: complexContent>

</xs:complexType> </ Xs: complexType>

<xs:complexType name="compoundComponentInstance"> <Xs: complexType name = "compoundComponentInstance">

<xs:complexContent> <Xs: complexContent>

<xs:extension base="instanceBase"> <Xs: extension base = "instanceBase">

<xs:sequence> <Xs: sequence>

<xs:element name="portInstances"> <Xs: element name = "portInstances">

<xs:complexType> <Xs: complexType>

<xs:sequence> <Xs: sequence>

<xs:element name="portInstance" type="instanceRef" /> <Xs: element name = "portInstance" type = "instanceRef" />

<!-- the port Instances that I delegate --> <-! The port Instances that I delegate ->

</xs:sequence> </ Xs: sequence>

</xs:complexType> </ Xs: complexType>

</xs:element> </ Xs: element>

<xs:element name="componentInstances"> <Xs: element name = "componentInstances">

<xs:complexType> <Xs: complexType>

<xs:sequence> <Xs: sequence>

<xs:element name="componentInstance" type="instanceRef" /> <Xs: element name = "componentInstance" type = "instanceRef" />

</xs:sequence> </ Xs: sequence>

</xs:complexType> </ Xs: complexType>

</xs:element> </ Xs: element>

<xs:element name="wireInstances"> <Xs: element name = "wireInstances">

<xs:complexType> <Xs: complexType>

<xs:sequence> <Xs: sequence>

<xs:element name="wireInstance" type="instanceRef" /> <Xs: element name = "wireInstance" type = "instanceRef" />

</xs:sequence> </ Xs: sequence>

</xs:complexType> </ Xs: complexType>

</xs:element> </ Xs: element>

</xs:sequence> </ Xs: sequence>

</xs:extension> </ Xs: extension>

</xs:complexContent> </ Xs: complexContent>

</xs:complexType> </ Xs: complexType>

<xs:complexType name="portInstance"> <Xs: complexType name = "portInstance">

<xs:complexContent> <Xs: complexContent>

<xs:extension base="instanceBase"> <Xs: extension base = "instanceBase">

<xs:sequence /> <Xs: sequence />

</xs:extension> </ Xs: extension>

</xs:complexContent> </ Xs: complexContent>

</xs:complexType> </ Xs: complexType>

<xs:complexType name="wireInstance"> <Xs: complexType name = "wireInstance">

<xs:complexContent> <Xs: complexContent>

<xs:extension base="instanceBase"> <Xs: extension base = "instanceBase">

<xs:sequence> <Xs: sequence>

<xs:element name="portInstances"> <Xs: element name = "portInstances">

<xs:complexType> <Xs: complexType>

<xs:sequence> <Xs: sequence>

<xs:element name="portInstance" type="instanceRef" /> <Xs: element name = "portInstance" type = "instanceRef" />

<!-- the ports that I have attached --> <-! The ports that I have attached ->

</xs:sequence> </ Xs: sequence>

</xs:complexType> </ Xs: complexType>

</xs:element> </ Xs: element>

</xs:sequence> </ Xs: sequence>

</xs:extension> </ Xs: extension>

</xs:complexContent> </ Xs: complexContent>

</xs:complexType> </ Xs: complexType>

<xs:complexType name="instanceRef"> <Xs: complexType name = "instanceRef">

<xs:attribute name="uniqueId" type="xs:string" /> <Xs: attribute name = "uniqueId" type = "xs: string" />

</xs:complexType> </ Xs: complexType>

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

<xs:simpleType name="fourPartVersionType"> <Xs: simpleType name = "fourPartVersionType">

<xs:annotation> <Xs: annotation>

<xs:documentation>Four part version numbers where the segments are in the range 0-65535 </xs:documentation> <Xs: documentation> Four part version numbers where the segments are in the range 0-65535 </ xs: documentation>

</xs:annotation> </ Xs: annotation>

<xs:restriction base="xs:string"> <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: 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: restriction>

</xs:simpleType> </ Xs: simpleType>

<xs:simpleType name="publicKeyTokenType"> <Xs: simpleType name = "publicKeyTokenType">

<xs:annotation> <Xs: annotation>

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

</xs:annotation> </ Xs: annotation>

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

<xs:pattern value="([0-9]|[af]|[AF])16" /> <Xs: pattern value = "([0-9] | [af] | [AF]) 16" />

</xs:restriction> </ Xs: restriction>

</xs:simpleType> </ Xs: simpleType>

<xs:attributeGroup name="identity"> <Xs: attributeGroup name = "identity">

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

<xs:attribute name="version" type="fourPartVersionType" use="required" /> <Xs: attribute name = "version" type = "fourPartVersionType" use = "required" />

<xs:attribute name="publicKeyToken" type="publicKeyTokenType" use="optional" /> <Xs: attribute name = "publicKeyToken" type = "publicKeyTokenType" use = "optional" />

</xs:attributeGroup> </ Xs: attributeGroup>

<xs:simpleType name="guid"> <Xs: simpleType name = "guid">

<xs:restriction base="xs:string"> <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: 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: restriction>

</xs:simpleType> </ Xs: simpleType>

</xs:schema> </ Xs: schema>

이하는 매핑(mapping)에 대한 예시적인 구조이다. The following is an exemplary structure for mapping (mapping).

<?xml version="1.0" encoding="utf-8" ?> <? 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"> <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? <- 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: import namespace = "urn: schemas-microsoft-com: sdmNames" schemaLocation = "SDM7Names.xsd" />

<xs:element name="logicalPlacement"> <Xs: element name = "logicalPlacement">

<xs:annotation> <Xs: annotation>

<xs:documentation> <Xs: documentation>

This file contains the mapping information between SDM members. 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. Mappings are constructed in a outside in fashion, first binding the outer compound component, then its members and so on.

</xs:documentation> </ Xs: documentation>

</xs:annotation> </ Xs: annotation>

<xs:complexType> <Xs: complexType>

<xs:sequence> <Xs: sequence>

<xs:element name="import" type="names:import" minOccurs="0" maxOccurs="unbounded" /> <Xs: element name = "import" type = "names: import" minOccurs = "0" maxOccurs = "unbounded" />

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

<xs:complexType> <Xs: complexType>

<xs:sequence> <Xs: sequence>

<xs:element name="memberBinding" type="memberBinding" maxOccurs="unbounded" /> <Xs: element name = "memberBinding" type = "memberBinding" maxOccurs = "unbounded" />

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

</xs:sequence> </ Xs: sequence>

<xs:attribute name="sourceComponentType" type="xs:string" /> <Xs: attribute name = "sourceComponentType" type = "xs: string" />

<xs:attribute name="targetComponentType" type="xs:string" /> <Xs: attribute name = "targetComponentType" type = "xs: string" />

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

</xs:complexType> </ Xs: complexType>

</xs:element> </ Xs: element>

</xs:sequence> </ Xs: sequence>

</xs:complexType> </ Xs: complexType>

</xs:element> </ Xs: element>

<!-- a member binding may be a: <- a member binding may be a!:

1. compound component member - in which case we bind all the members and wires of the compound component 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 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 3. a port member - in which case we bind it to a port and there is no further binding

--> ->

<xs:complexType name="memberBinding"> <Xs: complexType name = "memberBinding">

<xs:sequence> <Xs: sequence>

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

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

</xs:sequence> </ Xs: sequence>

<xs:attribute name="sourceMember" type="xs:string" use="required" /> <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 <-! 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 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 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--> 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: attribute name = "targetMember" type = "xs: string" use = "optional" />

</xs:complexType> </ Xs: complexType>

<!-- wires are bound to a path in the target compound component. <-! Wires are bound to a path in the target compound component.

This path consists of port, wire and component instances--> This path consists of port, wire and component instances ->

<xs:complexType name="wireBinding"> <Xs: complexType name = "wireBinding">

<xs:sequence> <Xs: sequence>

<xs:element name="path"> <Xs: element name = "path">

<xs:complexType> <Xs: complexType>

<xs:sequence> <Xs: sequence>

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

<xs:complexType> <Xs: complexType>

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

</xs:complexType> </ Xs: complexType>

</xs:element> </ Xs: element>

</xs:sequence> </ Xs: sequence>

</xs:complexType> </ Xs: complexType>

</xs:element> </ Xs: element>

</xs:sequence> </ Xs: sequence>

<xs:attribute name="sourceWire" type="xs:string" /> <Xs: attribute name = "sourceWire" type = "xs: string" />

</xs:complexType> </ Xs: complexType>

<!-- import --> <-! Import ->

</xs:schema> </ Xs: schema>

이하는 네임(name)에 대한 예시적인 구조이다. The following is an exemplary structure of the name (name).

<?xml version="1.0" encoding="UTF-8" ?> <? 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: 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" /> <Xs: import namespace = "http://www.w3.org/2001/XMLSchema" />

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

<xs:complexType name="import"> <Xs: complexType name = "import">

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

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

<xs:attributeGroup ref="Identity" /> <Xs: attributeGroup ref = "Identity" />

</xs:complexType> </ Xs: complexType>

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

<xs:attributeGroup name="Identity"> <Xs: attributeGroup name = "Identity">

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

<xs:attribute name="version" type="fourPartVersionType" use="required" /> <Xs: attribute name = "version" type = "fourPartVersionType" use = "required" />

<xs:attribute name="publicKeyToken" type="publicKeyTokenType" use="optional" /> <Xs: attribute name = "publicKeyToken" type = "publicKeyTokenType" use = "optional" />

</xs:attributeGroup> </ Xs: attributeGroup>

<xs:attributeGroup name="namespaceIdentity"> <Xs: attributeGroup name = "namespaceIdentity">

<xs:attributeGroup ref="Identity" /> <Xs: attributeGroup ref = "Identity" />

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

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

</xs:attributeGroup> </ Xs: attributeGroup>

<!-- simple version number --> <-! Simple version number ->

<xs:simpleType name="fourPartVersionType"> <Xs: simpleType name = "fourPartVersionType">

<xs:annotation> <Xs: annotation>

<xs:documentation>Four part version numbers where the segments are in the range 0-65535 </xs:documentation> <Xs: documentation> Four part version numbers where the segments are in the range 0-65535 </ xs: documentation>

</xs:annotation> </ Xs: annotation>

<xs:restriction base="xs:string"> <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: 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: restriction>

</xs:simpleType> </ Xs: simpleType>

<!-- public key for verifying signed docs --> <-! Public key for verifying signed docs ->

<xs:simpleType name="publicKeyTokenType"> <Xs: simpleType name = "publicKeyTokenType">

<xs:annotation> <Xs: annotation>

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

</xs:annotation> </ Xs: annotation>

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

<xs:pattern value="([0-9]|[af]|[AF])16" /> <Xs: pattern value = "([0-9] | [af] | [AF]) 16" />

</xs:restriction> </ Xs: restriction>

</xs:simpleType> </ Xs: simpleType>

</xs:schema> </ Xs: schema>

이하는 설정(setting)에 대한 예시적인 구조이다. The following is an exemplary structure for the setting (setting).

<?xml version="1.0" encoding="utf-8" ?> <? 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: 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" /> <Xs: import namespace = "http://www.w3.org/2001/XMLSchema" />

<!-- settings schema, values and constraints --> <-! Settings schema, values ​​and constraints ->

<xs:complexType name="openSchema"> <Xs: complexType name = "openSchema">

<xs:sequence> <Xs: sequence>

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

</xs:sequence> </ Xs: sequence>

</xs:complexType> </ Xs: complexType>

<xs:complexType name="settingSchema"> <Xs: complexType name = "settingSchema">

<xs:sequence> <Xs: sequence>

<xs:any namespace="http://www.w3.org/2001/XMLSchema" processContents="skip" minOccurs="0" maxOccurs="unbounded" /> <Xs: any namespace = "http://www.w3.org/2001/XMLSchema" processContents = "skip" minOccurs = "0" maxOccurs = "unbounded" />

</xs:sequence> </ Xs: sequence>

</xs:complexType> </ Xs: complexType>

<xs:complexType name="settingValues"> <Xs: complexType name = "settingValues">

<xs:sequence> <Xs: sequence>

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

</xs:sequence> </ Xs: sequence>

</xs:complexType> </ Xs: complexType>

<!-- constraints --> <-! Constraints ->

<xs:attributeGroup name="testAttributes"> <Xs: attributeGroup name = "testAttributes">

<xs:attribute name="path" type="xs:string" /> <Xs: attribute name = "path" type = "xs: string" />

<xs:attribute name="ifNullPath" type="ifNullPath" /> <Xs: attribute name = "ifNullPath" type = "ifNullPath" />

<xs:attribute name="error" type="xs:int" /> <Xs: attribute name = "error" type = "xs: int" />

<xs:attribute name="errorDesc" type="xs:string" /> <Xs: attribute name = "errorDesc" type = "xs: string" />

</xs:attributeGroup> </ Xs: attributeGroup>

<xs:complexType name="simpleTest"> <Xs: complexType name = "simpleTest">

<xs:attributeGroup ref="testAttributes" /> <Xs: attributeGroup ref = "testAttributes" />

</xs:complexType> </ Xs: complexType>

<xs:complexType name="settingConstraints"> <Xs: complexType name = "settingConstraints">

<xs:sequence> <Xs: sequence>

<xs:element name="mustExist" type="simpleTest" minOccurs="0" maxOccurs="unbounded" /> <Xs: element name = "mustExist" type = "simpleTest" minOccurs = "0" maxOccurs = "unbounded" />

<xs:element name="mustNotExist" 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 = "ifExists" type = "nestedTest" minOccurs = "0" maxOccurs = "unbounded" />

<xs:element name="ifNotExists" type="nestedTest" minOccurs="0" maxOccurs="unbounded" /> <Xs: element name = "ifNotExists" type = "nestedTest" minOccurs = "0" maxOccurs = "unbounded" />

</xs:sequence> </ Xs: sequence>

</xs:complexType> </ Xs: complexType>

<xs:complexType name="nestedTest"> <Xs: complexType name = "nestedTest">

<xs:sequence> <Xs: sequence>

<xs:element name="mustExist" type="simpleTest" minOccurs="0" maxOccurs="unbounded" /> <Xs: element name = "mustExist" type = "simpleTest" minOccurs = "0" maxOccurs = "unbounded" />

<xs:element name="mustNotExist" 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 = "ifExists" type = "nestedTest" minOccurs = "0" maxOccurs = "unbounded" />

<xs:element name="ifNotExists" type="nestedTest" minOccurs="0" maxOccurs="unbounded" /> <Xs: element name = "ifNotExists" type = "nestedTest" minOccurs = "0" maxOccurs = "unbounded" />

</xs:sequence> </ Xs: sequence>

<xs:attributeGroup ref="testAttributes" /> <Xs: attributeGroup ref = "testAttributes" />

</xs:complexType> </ Xs: complexType>

<xs:complexType name="deploymentSchema"> <Xs: complexType name = "deploymentSchema">

<xs:sequence> <Xs: sequence>

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

</xs:sequence> </ Xs: sequence>

</xs:complexType> </ Xs: complexType>

<xs:complexType name="deploymentValues"> <Xs: complexType name = "deploymentValues">

<xs:sequence> <Xs: sequence>

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

</xs:sequence> </ Xs: sequence>

</xs:complexType> </ Xs: complexType>

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

<xs:simpleType name="ifNullPath"> <Xs: simpleType name = "ifNullPath">

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

<xs:enumeration value="skip" /> <Xs: enumeration value = "skip" />

<xs:enumeration value="override" /> <Xs: enumeration value = "override" />

<xs:enumeration value="returnError" /> <Xs: enumeration value = "returnError" />

</xs:restriction> </ Xs: restriction>

</xs:simpleType> </ Xs: simpleType>

</xs:schema> </ Xs: schema>

이하는 유형에 대한 예시적인 구조이다. The following is an exemplary structure for this type.

<?xml version="1.0" encoding="utf-8" ?> <? 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: 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 = "http://www.w3.org/2001/XMLSchema" />

<xs:import namespace="urn:schemas-microsoft-com:sdmSettings" schemaLocation="SDM7Settings.xsd" /> <Xs: import namespace = "urn: schemas-microsoft-com: sdmSettings" schemaLocation = "SDM7Settings.xsd" />

<xs:import namespace="urn:schemas-microsoft-com:sdmNames" schemaLocation="SDM7Names.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]:! 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 keys and keyefs for validation ->

<!-- TODO [BassamT]: Add support for inlined types --> <- TODO [BassamT]:! Add support for inlined types ->

<!-- TODO [BassamT]: scrub minOccurs and maxOccurs --> <- TODO [BassamT]:! Scrub minOccurs and maxOccurs ->

<!-- TODO [BassamT]: New name for "class", possibly "deployment" --> <- TODO [BassamT]:! New name for "class", possibly "deployment" ->

<!-- TODO [BassamT]: New name for "host", possibly "provider" --> <- TODO [BassamT]:! New name for "host", possibly "provider" ->

<!-- REVIEW [BassamT]: Can we merge the definitions of port, component, wire classs in this XSD. <- 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. It would make it less verbose at the cost more semantic analysis. --> ->

<!-- CONSIDER [BassamT]: General attribute mechanism for things like Singleton, Colocation, Inline. <- CONSIDER [BassamT]:! General attribute mechanism for things like Singleton, Colocation, Inline. --> ->

<!-- TODO [BassamT]: Bindings: member to component member --> <-! TODO [BassamT]: Bindings: member to component member ->

<!-- TODO [geoffo]: ports - are they singleton? <- TODO [geoffo]:! Ports - are they singleton? --> ->

<!-- TODO [geoffo]: delegation - how do we combine ports? <- TODO [geoffo]:! Delegation - how do we combine ports? --> ->

<!-- TODO [geoffo] Add back <any> in appropriate places --> <-! TODO [geoffo] Add back <any> in appropriate places ->

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

<!-- SDM root element --> <-! SDM root element ->

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

<xs:element name="sdmTypes"> <Xs: element name = "sdmTypes">

<xs:annotation> <Xs: annotation>

<xs:documentation>SDM root element. <Xs: documentation> SDM root element. It is a container for SDM types.</xs:documentation> . It is a container for SDM types </ xs: documentation>

</xs:annotation> </ Xs: annotation>

<xs:complexType> <Xs: complexType>

<xs:sequence> <Xs: sequence>

<xs:element name="import" type="names:import" minOccurs="0" maxOccurs="unbounded" /> <Xs: element name = "import" type = "names: import" minOccurs = "0" maxOccurs = "unbounded" />

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

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

<xs:complexType> <Xs: complexType>

<xs:sequence> <Xs: sequence>

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

</xs:sequence> </ Xs: sequence>

</xs:complexType> </ Xs: complexType>

</xs:element> </ Xs: element>

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

<xs:complexType> <Xs: complexType>

<xs:sequence> <Xs: sequence>

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

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

</xs:sequence> </ Xs: sequence>

</xs:complexType> </ Xs: complexType>

</xs:element> </ Xs: element>

</xs:sequence> </ Xs: sequence>

<xs:attributeGroup ref="names:namespaceIdentity" /> <Xs: attributeGroup ref = "names: namespaceIdentity" />

</xs:complexType> </ Xs: complexType>

</xs:element> </ Xs: element>

<!-- SDM type library information --> <-! SDM type library information ->

<xs:complexType name="information"> <Xs: complexType name = "information">

<xs:annotation> <Xs: annotation>

<xs:documentation>Human readable information about the SDM type library.</xs:documentation> . <Xs: documentation> Human readable information about the SDM type library </ xs: documentation>

</xs:annotation> </ Xs: annotation>

<xs:sequence> <Xs: sequence>

<xs:element name="friendlyName" type="xs:string" minOccurs="0" /> <Xs: element name = "friendlyName" type = "xs: string" minOccurs = "0" />

<xs:element name="companyName" 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 = "copyright" type = "xs: string" minOccurs = "0" />

<xs:element name="trademark" 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 = "description" type = "xs: string" minOccurs = "0" />

<xs:element name="comments" type="xs:string" minOccurs="0" /> <Xs: element name = "comments" type = "xs: string" minOccurs = "0" />

</xs:sequence> </ Xs: sequence>

</xs:complexType> </ Xs: complexType>

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

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

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

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

<xs:annotation> <Xs: annotation>

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

</xs:annotation> </ Xs: annotation>

<xs:sequence> <Xs: sequence>

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

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

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

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

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

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

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

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

that is specified on the unit. that is specified on the unit. --> ->

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

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

also that we will support flowing setting values to the settings also that we will support flowing setting values ​​to the settings

on the unit. on the unit. --> ->

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

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

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

<!-- This section contains the list of hosted units and any constraints on the classs' settings. <-! 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. The constraints are specified in terms of the class's schema. Note that there can be Note that there can be

more than one class that is hosted here. more than one class that is hosted here. --> ->

</xs:sequence> </ Xs: sequence>

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

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

</xs:complexType> </ Xs: complexType>

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

<!-- Constraints --> <-! Constraints ->

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

<xs:complexType name="hostConstraints"> <Xs: complexType name = "hostConstraints">

<xs:annotation> <Xs: annotation>

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

</xs:annotation> </ Xs: annotation>

<xs:sequence> <Xs: sequence>

<xs:element name="hostConstraint"> <Xs: element name = "hostConstraint">

<xs:complexType> <Xs: complexType>

<xs:sequence> <Xs: sequence>

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

</xs:sequence> </ Xs: sequence>

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

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

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

</xs:complexType> </ Xs: complexType>

</xs:element> </ Xs: element>

</xs:sequence> </ Xs: sequence>

</xs:complexType> </ Xs: complexType>

<xs:complexType name="hostedClassesList"> <Xs: complexType name = "hostedClassesList">

<xs:annotation> <Xs: annotation>

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

</xs:annotation> </ Xs: annotation>

<xs:sequence> <Xs: sequence>

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

<xs:complexType> <Xs: complexType>

<xs:sequence> <Xs: sequence>

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

</xs:sequence> </ Xs: sequence>

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

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

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

</xs:complexType> </ Xs: complexType>

</xs:element> </ Xs: element>

</xs:sequence> </ Xs: sequence>

</xs:complexType> </ Xs: complexType>

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

<!-- Ports --> <-! Ports ->

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

<xs:complexType name="portType"> <Xs: complexType name = "portType">

<xs:complexContent> <Xs: complexContent>

<xs:extension base="baseType"> <Xs: extension base = "baseType">

<xs:sequence> <Xs: sequence>

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

</xs:sequence> </ Xs: sequence>

</xs:extension> </ Xs: extension>

</xs:complexContent> </ Xs: complexContent>

</xs:complexType> </ Xs: complexType>

<xs:complexType name="portConstraints"> <Xs: complexType name = "portConstraints">

<xs:annotation> <Xs: annotation>

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

</xs:annotation> </ Xs: annotation>

<xs:sequence> <Xs: sequence>

<xs:element name="portConstraint"> <Xs: element name = "portConstraint">

<xs:complexType> <Xs: complexType>

<xs:sequence> <Xs: sequence>

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

</xs:sequence> </ Xs: sequence>

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

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

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

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

<xs:attribute name="visible" type="xs:boolean" 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 <-! Port type is here to allow you to bind to a port type that has behavior not exposed

through settings. through settings. In this case settings would not be enough to allow an appropriate port to be identified --> 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. <-! Visible identifies whether the application wants to see ports that match this constraint. An application may An application may

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

</xs:complexType> </ Xs: complexType>

</xs:element> </ Xs: element>

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

port to identify sets of optional port endpoints. port to identify sets of optional port endpoints.

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

</xs:sequence> </ Xs: sequence>

</xs:complexType> </ Xs: complexType>

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

<!-- Components --> <-! Components ->

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

<xs:complexType name="componentType"> <Xs: complexType name = "componentType">

<xs:complexContent> <Xs: complexContent>

<xs:extension base="baseType"> <Xs: extension base = "baseType">

<xs:sequence> <Xs: sequence>

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

</xs:sequence> </ Xs: sequence>

<!-- the exclusive attribute indicates whether an instance of the type at the layer below can host instance of other types <-! 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 - 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 --> - deep implies that the host must also be marked as exclusive ->

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

</xs:extension> </ Xs: extension>

</xs:complexContent> </ Xs: complexContent>

</xs:complexType> </ Xs: complexType>

<xs:complexType name="portsList"> <Xs: complexType name = "portsList">

<xs:sequence> <Xs: sequence>

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

<xs:complexType> <Xs: complexType>

<xs:sequence> <Xs: sequence>

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

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

specified on the type --> specified on the type ->

</xs:sequence> </ Xs: sequence>

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

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

</xs:complexType> </ Xs: complexType>

</xs:element> </ Xs: element>

</xs:sequence> </ Xs: sequence>

</xs:complexType> </ Xs: complexType>

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

<!-- Compound Component Types. <-! Compound Component Types. --> ->

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

<xs:complexType name="compoundComponentType"> <Xs: complexType name = "compoundComponentType">

<xs:sequence> <Xs: sequence>

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

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

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

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

<!-- delegate ports --> <-! Delegate ports ->

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

component. component. --> ->

</xs:sequence> </ Xs: sequence>

<xs:attribute name="name" type="xs:string" use="required" /> <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 <-! 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--> 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" /> <Xs: attribute name = "colocate" type = "depth" use = "optional" default = "notSet" />

<!-- the open attribute indicates whether bindings can see the internalstructure of the compound component <-! 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 --> 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" /> <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 <-! 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 - 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 --> - deep implies that the host must also be marked as exclusive ->

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

</xs:complexType> </ Xs: complexType>

<xs:complexType name="components"> <Xs: complexType name = "components">

<xs:sequence> <Xs: sequence>

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

<xs:complexType> <Xs: complexType>

<xs:sequence> <Xs: sequence>

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

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

specified on the type --> specified on the type ->

</xs:sequence> </ Xs: sequence>

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

<xs:attribute name="type" 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: attribute name = "singleton" type = "xs: boolean" use = "optional" default = "false" />

</xs:complexType> </ Xs: complexType>

</xs:element> </ Xs: element>

</xs:sequence> </ Xs: sequence>

</xs:complexType> </ Xs: complexType>

<xs:complexType name="wires"> <Xs: complexType name = "wires">

<xs:sequence> <Xs: sequence>

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

<xs:complexType> <Xs: complexType>

<xs:sequence> <Xs: sequence>

<xs:element name="members"> <Xs: element name = "members">

<xs:complexType> <Xs: complexType>

<xs:sequence> <Xs: sequence>

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

</xs:sequence> </ Xs: sequence>

</xs:complexType> </ Xs: complexType>

</xs:element> </ Xs: element>

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

specified on the type --> specified on the type ->

</xs:sequence> </ Xs: sequence>

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

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

</xs:complexType> </ Xs: complexType>

</xs:element> </ Xs: element>

</xs:sequence> </ Xs: sequence>

</xs:complexType> </ Xs: complexType>

<xs:complexType name="delegatePorts"> <Xs: complexType name = "delegatePorts">

<xs:sequence> <Xs: sequence>

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

<xs:complexType> <Xs: complexType>

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

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

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

</xs:complexType> </ Xs: complexType>

</xs:element> </ Xs: element>

</xs:sequence> </ Xs: sequence>

</xs:complexType> </ Xs: complexType>

<xs:complexType name="componentPortRef"> <Xs: complexType name = "componentPortRef">

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

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

</xs:complexType> </ Xs: complexType>

<xs:complexType name="delegateHostedClasses"> <Xs: complexType name = "delegateHostedClasses">

<xs:sequence> <Xs: sequence>

<xs:element name="hostedClassRef" maxOccurs="unbounded"> <Xs: element name = "hostedClassRef" maxOccurs = "unbounded">

<xs:complexType> <Xs: complexType>

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

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

</xs:complexType> </ Xs: complexType>

</xs:element> </ Xs: element>

</xs:sequence> </ Xs: sequence>

</xs:complexType> </ Xs: complexType>

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

<!-- SimpleTypes. <-! 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) --> <-! 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: simpleType name = "depth">

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

<xs:enumeration value="notSet" /> <Xs: enumeration value = "notSet" />

<xs:enumeration value="shallow" /> <Xs: enumeration value = "shallow" />

<xs:enumeration value="deep" /> <Xs: enumeration value = "deep" />

</xs:restriction> </ Xs: restriction>

</xs:simpleType> </ Xs: simpleType>

</xs:schema> </ Xs: schema>

SDM 런타임(SDM Runtime) SDM runtime (SDM Runtime)

SDR 런타임(또는 단순히 런타임)은 SDM의 구현을 호스팅한다. SDR Runtime (or just runtime) is hosting the implementation of the SDM. 이는 SDM 유형(type), 멤버(member) 및 인스턴스 스페이스(instance space)를 조작하기 위한 세트 API들을 공개하는 고가용성 분배 서비스(highly available distributed service)이다. This is the SDM type (type), member (member) and instance space (instance space) set of high availability, distribution services (highly available distributed service) to publish the API for manipulating. 런타임은 일관된 방식으로 모든 SDM 인스턴스를 추적할 책임이 있다. Runtime is responsible for tracking all SDM instances in a consistent manner. 이는 배포(deployment), 버져닝(versioning), 보안, 및 복구를 위한 기계 장치를 제공한다. This provides a mechanism for the deployment (deployment), versioning (versioning), security, and recovery. 도 27은 SDM 런타임의 논리적인 아키텍처를 나타낸다. 27 shows the logical architecture of the SDM runtime.

SDM 런타임은 다음과 같이 구성된다. SDM runtime will be configured as follows:

* SDM 런타임(Runtime) - 이는 SDM Runtime 구현(implementation)이다. * SDM runtime (Runtime) - This is the SDM Runtime implementation (implementation). 이는 하나 이상의 물리적인 기계를 실행하는 분배 구현(distributed implementation)이다. This is the distribution implement (distributed implementation) that execute one or more physical machines. 런타임은 SDM 및 인스턴스를 조작하는 호출의 세트인 SDM API를 통하여 기능을 나타낸다. Run time indicates the function through the SDM API is the set of calls to manipulate the SDM and instances.

* SDM 스토어(Store) - 이는 SDM 모델들(Models) 및 인스턴스를 위한 영구적인 스토어이다. * SDM Store (Store) - This is a permanent store for the SDM models (Models) and instances. 이 스토어는 고가용성이며, 그 일관성이 중요하다. The store is a high-availability, that consistency is important. 이 스토어는 치명적인 이벤트에도 견뎌 낸다. The store will also produce enduring catastrophic events.

* Service 배포 유닛(Deployment Unit) - 이는 SDU들을 위한 읽기 전용 스토어이다. * Service Deployment Unit (Deployment Unit) - This is a read-only store for the SDU. SDM 스토어와 마찬가지로, 이는 고가용성이고, 치명적인 이벤트에도 견뎌 낸다. Like the SDM Store, which is a high-availability, it produces withstand even catastrophic events.

* 컴포넌트 구현 호스트(Component implementation Host) - 이는 SDM 컴포넌트로부터 참조된 CLR 코드를 호스팅하기 위한 프레임워크(framework)이다. * Component implementation host (Component implementation Host) - which is a framework (framework) to host a CLR reference code from the SDM component.

SDM 런타임은 전형적으로 다음과 같은 클라이언트 클래스에 의하여 사용된다. SDM Runtime is typically used by clients in the following classes:

* 컴포넌트 인스턴스(Component Instances) - 이들은 SDM 런타임 라이브러리(RTL, Runtime Library)를 사용하기 위한 런타임과 통신하는 컴포넌트 인스턴트이다. * Component instance (Component Instances) - These are the components to communicate with the run-time instant for using the SDM runtime library (RTL, Runtime Library). 우리는 2가지 유형의 컴포넌트 인스턴트를 구분하는데, 그것은 런타임-호스팅된(runtime-hosted) 컴포넌트 인스턴스 및 런타임-호스팅되지 않은 컴포넌트 인스턴스이다. We have to distinguish between the two types of component instant, it is run - a non-hosted component instances - hosted (runtime-hosted) and the runtime component instances.

* 개발 및 배포 도구(Development and Deployment tools) - 이들은 SDM 컴파일러, SDU 설치 도구 및 기타 전개 도구를 포함한다. * Development and deployment tools (Development and Deployment tools) - These include the SDM compiler, SDU installation tools and other deployment tools.

* 관리 도구(Management tools) - 이들은 런타임 자체를 등록하고 관리하기 위하여 사용되는 특별 허가된 도구(privileged tools)이다. * Management tools (Management tools) - these are privileged tools (privileged tools) that are used to register and manage the runtime itself.

클라이언트는 SDM 런타임 라이브러리(RTL)를 통하여 런타임과 통신한다. The client communicates with the runtime through the SDM Runtime Library (RTL). 이들은 전형적으로 다음과 같은 동작을 수행한다. It typically performs the following actions:

* SDU들의 설치/설치제거: 이는 새로운 SDU들을 SDM 런타임의 실행중인 인스턴트에 추가 및 제거하는 프로세스이다. * Uninstall / install of SDU: This is the process of adding and removing new SDU in an instant running of the SDM runtime.

* SDM 유형 및 인스턴스의 추가, 제거 및 수정: 클라이언트는 새로운 컴포넌트, 포트 및 와이어 유형을 생성할 수 있다. * Add, remove, and modify the SDM types and instances: the client can create a new component, port and wire types.

* 인스턴스의 생성 및 삭제: 클라이언트는 새로운 컴포넌트, 포트 및 와이어 인스턴스를 생성할 수 있다. * Creation and deletion of instances: the client can create a new component, port and wire instance.

* 이벤트의 소싱(Sourcing) 및 하강(sinking): 유형 및/또는 인스턴스 스페 이스에 변경이 행해진 경우, 런타임은 영향을 받는 클라이언트에게 이벤트를 전송한다. - sourcing (Sourcing) and lowered (sinking) of the event: if a change is made to the types and / or instances spaces, run time, and transmits the event to the clients that are affected. 이벤트는 포트 바인딩 정보(port binding information)를 설정하는 것과 같이 특정 동작에 의해 트리거될 수 있다. Event may be triggered by a specific operation such as to set the port binding information (port binding information).

* 유형 및 인스턴스 스페이스를 질의한다(query): 클라이언트는 유형 및 인스턴스 스페이스를 반영할 수 있다. * Query the type and instance space (query): the client can reflect the type and instance space.

서비스 정의 모델 런타임 아키텍처(Service Definition Model Runtime Architecture) Service definition model runtime architecture (Service Definition Model Runtime Architecture)

도입 Introduced

이 부분에서는 서비스 정의 모델(SDM) 및 SDM 런타임에 대해서 검토한다. This section reviews about the service definition model (SDM) and SDM runtime. 런타임 아키텍처, 핵심 특성 및 구현에 대한 기술적인 논의가 제공된다. The technical discussions about the runtime architectures, key features and implementation is provided. 의도된 청중은, BIG의 기술 평가자, 서비스 및 컴포넌트를 만들어 내고자 하는 개발자, 또는 시스템의 세부 사항에 대하여 관심이 있는 사람들이다. The intended audience is those who are concerned about the developers that you want to create the technical evaluators, services, and components of the BIG, or details of the system requirements.

서비스 시기(Service Era) Service time (Service Era)

최근 10년에 걸쳐서 우리는 인터넷이 컴퓨팅 플랫폼으로서 등장한 것을 보아 왔다. Over the last 10 years, we have seen that the Internet is emerging as a computing platform. 점점 더 많은 소프트웨어회사가 "서비스 모델로서의 소프트웨어"를 채택하고 있다. More and more software companies are adopting a "software as a service model." 서비스는 전형적으로 서버, 네트워킹 기어 및 기타 특정 하드웨어를 포함하는 수많은 기계에서 실행되는 여러 개의 컴포넌트를 포함한다. Services typically include servers, networking gear and other several components that run on many machines, including the specific hardware. 느슨하게 연결된(loosely coupled), 비동기식 프로그래밍 모델이 기준(norm)이 되고 있다. Loosely attached (loosely coupled), asynchronous programming model is the standard (norm). 이러한 서비스의 성공을 위해서는 확장성(scalability), 가용성(availability) 및 신뢰 성(reliability)이 중요하다. Scalability (scalability), availability (availability) and reliability (reliability) is critical to the success of these services.

우리는 하드웨어 경향에서의 변화도 보아 왔다. We have also seen a change in hardware trends. 고밀도 서버 및 특수화된 네트워크 하드웨어는 데이터 센터에서 널리 보급되었다. High-density servers and specialized network hardware has been widely used in data centers. 스위칭 구조(switched fabrics)가 시스템 구성에서 큰 유연성을 제공하는 시스템 버스를 대체하고 있다. A switching structure (switched fabrics) and replacing the system bus, which provides great flexibility in system configuration. 하드웨어 비용은 소유권 메트릭(Ownership metric)의 총 비용의 작은 부분을 차지한다. Hardware costs account for a small portion of the total cost of ownership metrics (Ownership metric). 이는 전용 작동 요원을 보유하기 위한 비용으로 대체되었다. This has been replaced by the cost to retain an agent-only operation. 바위와 같이 견고한 동작 실행은 드물지만, 어느 서비스에 있어서나 절대적으로 중요하다. Robust operation running as rocks are rare, and it is absolutely essential according to any services. 이러한 실행은 주로 사람에 의하여 구현된다. These runs are mainly implemented by the people.

효과적으로는, 개발의 초점을 단일 PC로부터 PC들의 네트워크로 바꾸는 것이다. Effectively, it is to change the focus of the development of the network from a single PC to PC. 그러나, 이러한 모든 변화에 있어서, 서비스 개발자, 소프트웨어 공급자, 하드웨어 공급자, 및 최종 사용자(end-user)를 위한 과다한 새로운 문제점이 발생하였다. However, in all these changes it was caused excessive new problems for service developers and software providers, hardware providers, and end users (end-user).

* 서비스가 방대하고 복잡하다 - 이들은 개발하는데 시간이 많이 걸리고, 유지하기 힘들고 고가이며, 추가적인 기능을 확장하는데 위험이 있다. * Service is vast and complex - they are time-consuming to develop, expensive and difficult to maintain, there is a risk to extend additional functionality.

* 서비스가 획일적이다(monolithic) - 이들은 맞춤식(custom) 컴포넌트 및 구성에 의존한다. - a service is uniform (monolithic) - which depends on the custom (custom) and component configuration. 서비스의 일부가 독립적으로 제거 또는 업그레이드되거나, 다른 것으로 대체될 수 없다. Some of the service, or removed, or upgraded independently, and can not be replaced.

* 서비스가 특정 하드웨어 구성에 의존한다 - 특정 네트워크 토폴로지 또는 특정 네트워크 설비 기계의 의존성 여부이다. * Service is dependent on the particular hardware configuration - whether a specific network topology or the dependence of the specific network equipment machines. 이는 다른 환경의 서버를 호스팅하는 능력을 상당히 감소시킨다. This significantly reduces the ability to host a server in a different environment.

* 서비스가 사일로(silos)에서 개발된다 - 공통적인 플랫폼이 없기 때문에, 코드 공유 또는 최적의 동작 실행조차 위협적인 작업이다. * Services are developed in silos (silos) - because there is no common platform, code-sharing, or even run the best operation is dangerous work.

* 동작의 악몽 - 대부분의 서비스는 기능시키기 위한 작동 직원을 요구한다. * Nightmare behavior - most services require the employee works for functionality. 이 작동 직원은 각 서비스의 세부 내용에 대하여 훈련되어야 하며, 서비스가 발달함에 따라 다시 훈련되어야 한다. The work staff should be trained in the details of each service should be re-trained as service development.

이러한 문제의 일부는 DOS 시절(1980년대 경) 동안의 문제점과 같지는 않다. Some of these problems are not the same problems during the DOS era (circa 1980). DOS는 디스크 관리, 파일 시스템, 콘솔 시설 등과 같은 애플리케이션 개발자를 위한 유용한 핵심 서비스를 정의하였다. DOS has defined the core services useful for application developers, such as disk management, file system, console facility. 그러나, 이는 ISV들까지 수많은 복잡한 작업을 남겨 놓았다. However, it left behind a number of complex tasks, even those ISV support. 예를 들어, WordPerfect 및 Lotus 123은 모두 그 각각의 애플리케이션 내에 인쇄를 지원하기 위한 기록 프린터 드라이버를 독립적으로 구비하고 있었다. For example, WordPerfect and Lotus 123 were all provided with a recording printer driver for supporting a print in that each application independently. 이와 유사하게 프린터 하드웨어 공급자는 성공적인 제품을 생산하기 위해서는 소프트웨어 회사와 거래하여야 했다. Similarly, the printer has a hardware provider in order to produce a successful product should deal with software company. 하드웨어 공급자 및 DOS 애플리케이션을 기록하기 위한 입구로의 장벽은 유난히 컸다. Barriers to entry for hardware providers to record and DOS application is unusually large. 이 때문에 단지 몇 개만의 성공적인 소프트웨어 회사가 생겨났다. This was just blossomed, because a successful software company a few.

윈도우는 입구로의 장벽을 획기적으로 감소시킨 플랫폼을 정의함으로써 이 문제점을 다루었다. Window has dealt with this problem by defining a platform, which greatly reduce the barriers to the inlet. 윈도우는 PC 플랫폼 상의 대부분의 하드웨어를 위한 추상화 계층(abstraction layer)을 정의하였다. Windows has defined an abstraction layer (abstraction layer) for most of the hardware on the PC platform. 이는 개발자로 하여금 특정 하드웨어 장치를 지원하도록 하기 위한 걱정을 덜어주었다. This was a worry to allow the developer to support a particular hardware device. 윈도우는 메모리, 디스크 및 네트워크를 포함하는 PC 내의 모든 자원을 관리하였다. Windows were managing all resources in the PC, including memory, disk, and network. 또한, 윈도우 애플리케이션 개발자에 의하여 사용될 수 있는 풍부한 서비스를 갖추고 있었다. In addition, it was equipped with a rich set of services that can be used by Windows application developers. 이 플랫폼은 산업 상의 엄청난 발전을 야기하였다. The platform was causing tremendous progress on the industry. 윈도우 플랫폼을 타깃으로 삼은 소프트웨어 공급자는 엄청나게 이익을 냈다. Ginseng software providers to target the Windows platform has found a tremendous interest. 많은 새로운 하드웨어 공급자는 윈도우의 일반화(commoditization)로 인해 더 값싼 하드웨어를 제공하였다. Many new hardware provider has provided cheaper hardware because of the generalized (commoditization) of the window.

서비스 시대는 아직도 이러한 성장을 경험하여야 한다. Service times should still be experiencing this growth. 데스크탑 기계에서 일어난 혁명은 서비스에서도 발생할 필요가 있다. Revolution in desktop machines need to occur in service.

BIG 서비스 플랫폼(BIG services Platform) BIG Services Platform (BIG services Platform)

BIG은 고가용성이고, 스케일 가능한(scalable) 서비스를 위한 플랫폼을 생산하고 있다. BIG is a high-availability, and production platforms for the scalable (scalable) services. 이 플랫폼은 이하를 가능하게 한다. The platform allows for less.

* Visual Studio 및 SQL, IIS 등의 재사용 가능한 빌딩 블록을 사용한 분배된, 스칼러블하고 고가용성 서비스의 개발 * Visual Studio and SQL, development of, Skal and scalable high-availability service distribution using reusable building blocks of IIS, etc.

* 자동적으로 할당되고, 의도되고, 구성되는 추상화된 하드웨어 및 소프트웨어 자원의 세트에 걸친 개발 * Automatically assigned, is intended to be, developed across a set of abstracted hardware and software resources configured

* 동작의 최적의 실행의 자동화를 통한 소유 비용의 저감. * Reduced cost of ownership through automation of best practices in action.

* 상품 경제에 영향을 주는 표준화된 데이터 센터 하드웨어의 획득 * Acquisition of standardized data center hardware products that affect the economy

BIG 플랫폼은 윈도우 플랫폼으로의 확장이고, .NET, SQL, 및 기타 마이크로소프트 자산과 같은 현존하는 기술 위에 구축된다. BIG platform is an extension of a Windows platform is built on top of existing technologies, such as for .NET, SQL, Microsoft and other assets. BIG 서비스 플랫폼은 이하를 포함하는 많은 부분으로 이루어져 있다. BIG service platform consists of many parts, which include the following.

* 우리가 BIG 컴퓨터라고 부르는 하나의 대형 컴퓨터를 만들기 위한 상품 하드웨어를 모아 놓은 하드웨어 기준 플랫폼. * Hardware Platform Based on our collection of commodity hardware to create a single large computer called the BIG computer. 이는 수많은 상호 접속된 서버, 네트워크 장치, 및 기억장치를 포함한다. This includes a number of interconnected servers, network devices, and the memory device.

* 자원이 보이게 하는 하드웨어 추상화 계층(hardware abstraction layer). * Hardware Abstraction Layer is visible to resources (hardware abstraction layer). 동적 하드웨어 제조, 재배포, 및 자동화 네트워크 구성을 가능하게 한다. It allows for dynamic hardware manufacture, redistribution, and automated network configuration.

* 개발자가 전체 서비스를 설명하는 서비스 정의 모델(SDM). * Service Definition Model (SDM) for developers to explain the whole service. 개발자로 하여금, 고가용성 SQL, IIS, 및 기타 재사용 가능한 빌딩 블록 컴포넌트를 사용하여 새로운 서비스를 신속하게 구축할 수 있게 한다. Allowing developers to use the high-availability SQL, IIS, and other building blocks of reusable components makes it possible to quickly deploy new services.

* SDM을 지원하는 고가용성 런타임. * SDM runtime that supports highly available. BIG 컴퓨터 내의 다중 스케일 가능한 서비스의 호스팅을 가능하게 한다. It enables the hosting of multiple scalable services within the BIG computer.

* 최적의 동작 실행을 자동화하기 위한 동작 논리 체제(operations logic framework). * Operating system logic to automate the optimum operation is performed (operations logic framework). 폴리시 표현 및 시행을 가능하게 한다. Enabling policy expression and enforcement.

이 문서는 SDM 및 SDM 런타임에만 초점을 맞추어 설명한다. This document describes focusing only SDM and SDM runtime.

서비스 정의 모드(Service Definition Mode) Service definition mode (Service Definition Mode)

이 섹션에서는 서비스 정의 모델(SDM)에 대하여 설명한다. This section will be described in the service definition model (SDM). SDM 및 SDML 언어에 대한 완벽한 기술적인 설명을 위해서는 "서비스 정의 모델 언어(Service Definition Model Language)" 문서를 참조하기 바란다. For a complete technical description of the SDM and SDML language please refer to the "Service Definition Model Language (Service Definition Model Language)" document.

SDM은 모든 서비스가 구축되는 기초이다. SDM is the foundation on which all services are built.

* SDM은, 더 작은 유닛으로부터 서비스의 합성을 가능하게 한다. * SDM is, enables the synthesis of the service from the smaller unit. 이러한 유닛은 하드웨어 및 소프트웨어 추상화(abstraction)의 기초를 형성한다. This unit forms the basis of hardware and software abstractions (abstraction).

* SDM은, 서비스의 생생한 청사진으로서 제공한다 - SDM은 스케일 불변 방식으로 서비스의 전체 구조를 포착한다. * SDM, there is provided a live blueprint of service - SDM captures the entire structure of the service to the scale invariant manner.

* SDM은, 동작적인 실행을 자동화하기 위한 프레임워크를 제공하고, 그들의 재사용을 촉진한다. * SDM is to provide a framework for automating the operation execution, and to facilitate their re-use.

* SDM은, 서비스의 배포, 재사용, 발견, 버져닝(versioning), 및 복구를 위한 표준을 정의한다. * SDM has defined the standard for the distribution of services, re-use, discovery, versioning (versioning), and recovery.

서비스를 위한 컴포넌트 모델(Component Model for Services) Component model for services (Component Model for Services)

본질적으로, SDM은 서비스를 위한 컴포넌트 모델이다. Essentially, SDM is a component model for the service. 전통적인 컴포넌트 모델과 마찬가지로 SDM은, 더 복잡한 기능이 구축될 수 있는 근본(primitives)을 정의한다. Like a traditional component model, SDM, to define with more complex functions it can be built Root (primitives). 유추법을 고려해 보자. Consider the analogy. 마이크로소프트의 컴포넌트 객체 모델(Component Object Model, COM)은 컴포넌트를 만들기 위한 프로그래밍 모델을 정의하였다. Microsoft's component object model (Component Object Model, COM) was defined as a programming model for creating components. 이는 컴포넌트가 어떻게 패키지되고, 등록되고, 활성화되고, 발견되는지에 관하여 표준화하였다. It was normalized with respect to whether and how the component package is registered and the activation and discovery. COM은 수명, 메모리 관리, 및 인터페이스 구현과 관련된 엄격한 규칙을 명령하였다(mandated). COM has ordered strict rules related to lifetime, memory management, and interface implementation (mandated). 이러한 근본이 상호 운영(interoperability)을 위하여 필수적이었다 - 이는 컴포넌트가 블랙 박스로서 취급될 수 있게 한다. The root was essential to interoperability (interoperability) - This allows the component is treated as a black box. Com은 영구적인 기억장치, 이벤팅(eventing), 자동화 및 OLE와 같은 더 정교한 서비스의 기초였다. Com was the basis of more sophisticated services such as permanent storage, Eventing (eventing), automation, and OLE.

SDM은 서비스를 위한 컴포넌트 모델을 정의한다. SDM defines a component model for the service. 이 모델은 느슨하게(loosely) 연결된, 분산된, 그리고 비동기식의 서비스를 위해 매우 적절하다. This model is loosely (loosely) is very well suited for the attached, distributed, and asynchronous services. SDM은 배포, 버져닝, 복구, 및 스코핑(scoping)을 위한 표준을 정의한다. SDM defines the standards for deployment, versioning, recovery, and scoping (scoping). SDM은 네트워크 관리, 하드웨어 관리, 기억장치 추상화 등과 같은 더 정교한 서비스가 제공되는 모델이다. SDM is a model that is more sophisticated services such as network management, hardware management, memory abstraction provided. SDM을 기타 컴포넌트 모델과 어떻게 비교하겠는가? How would you compare the SDM and the other component model?

확실히 기타 기술들 중에서 DCOM 및 COBRA와 같은 기술은, 재사용 가능한 컴 포넌트에 기초한 애플리케이션을 개발하기 위한 방법을 잘 정의하고 있다. Among other quite technical skills, such as DCOM and COBRA it is well-defined and how to develop applications based on reusable components. 그러나, 현존하는 컴포넌트 기술도 강력하지만, 그들은 인터넷 또는 느슨하게 연결된 시나리오에 있어서 광범위하게 성공적이지는 못하였다. However, even strong existing component technologies, but they did not succeed is widespread in the Internet or loosely coupled scenario. 이는 주로 다음과 같은 이유 때문이다. This is mainly due to the following reasons:

* 현존하는 컴포넌트 기술은 대규모를 위하여 설계된 것이 아니다 - 대부분의 실행은 하나의 기계 또는 아주 적은 수의 기계를 위하여 최적화되었다. * Existing component technologies that are not designed for large-Most runs are optimized for a single machine or a small number of machines. 인터넷 애플리케이션은 전형적으로 많은 기계에서 실행하는, 많은 상호 관련된 컴포넌트와 관련되어 있다. Internet applications are typically running on many machines, it is associated with a number of interrelated components.

* 현존하는 컴포넌트 기술은 RPC와 같은 발동 프로토콜(invocation protocols)을 명령한다(mandate) - 이들은 잘 확증된 네트워크 프로토콜을 이용하지도 않거나, 분기하는 프로토콜을 허용하지 않는다. * Existing component technologies that will activate the command protocol (invocation protocols) such as RPC (mandate) - which does not even use a well-assurance network protocol does not allow for protocols that quarter.

* 현존하는 컴포넌트 기술은 애플리케이션의 개념이 결여되어 있다 - 대부분은 잘 개발된 컴포넌트의 정의를 구비하지만, 더 작은 컴포넌트로 구성된 애플리케이션의 전체적인 정의가 결여되어 있다. * Existing component technology that lacks the concept of application - mostly having a definition of well-developed components, but the overall definition of the application composed of smaller components is lacking.

* 현존하는 컴포넌트 기술은 범용 컴퓨터에서 실행하는 소프트웨어로 제한된다 - 하나의 목적을 갖는 네트워크 장치는 컴포넌트로서 관여할 수 없다. * Existing component technology which is limited to software running on a general-purpose computer - a network device having a single object can not be involved as a component.

서비스 세계와 더 중요하게 관련되어 있는 많은 것들을 현존하는 컴포넌트 기술에 적용하여야 한다. It shall be applied to many component technologies to existing ones that are more important and relevant service in the world.

SDM 원리(SDM Fundamentals) Principle SDM (SDM Fundamentals)

SDM은 서비스 구조의 선언적인 정의(a declarative definition)이다. SDM is a declarative definition (a declarative definition) in the service structure. 이 정 의는 컴포넌트, 포트 및 와이어와 관련된다. This definition is related to the components, ports, and wires.

* 컴포넌트는 구현, 배포 및 동작 유닛이다. * This component is the implementation, deployment, and operation unit. 컴포넌트는 Cisco의 로컬 디렉터(LocalDirector)와 같은 네트워크 설비 또는 공유 기계 상의 IIS 가상 웹 사이트, .NET 서버를 실행하는 전용 서버일 수 있다. Components may be a dedicated server running IIS virtual Web sites, .NET server on the network facilities or shared equipment, such as Cisco's Local Director (LocalDirector). 컴포넌트는 포트를 통하여 기능을 공개하고, 와이어를 통하여 통신 경로를 설정한다. Component sets the communication path to release the function through the port and through the wire. 컴포넌트는, 복합 컴포넌트라고 하는 외부 컴포넌트 내에 맞추어질 수 있다(nested). Components, can be fitted in the outer component, called a composite component (nested).

* 포트는 관련 유형을 갖는 이른바 종단점(endpoints)이다. * Is a so-called end-point port (endpoints) that has an associated type. 포트 유형은 종종 프로토콜, 예를 들어 HTTP 서버를 나타낸다. Port type often contains a protocol, for example, shows an HTTP server. 포트는 통신을 설정하기 위하여 요구되는 정보를 획득한다. Port, to obtain the information required to establish communication.

* 와이어는 포트간의 허용되는 통신 경로이다. * Wire is a communication path between the allowed ports. 이들은 포트간의 토폴로지의 관계를 선언한다. It declared the topological relationships between ports.

서비스는 선언적인 서비스 정의 모델 언어(SDML)를 사용하여 만들어진다. Service is made using declarative Service Definition Model Language (SDML). 다음의 예를 고려해 보자. Consider the following example.

(SDML). (SDML). Lets consider an example: Lets consider an example:

using System; using System;

using System.Iis; using System.Iis;

using System.Sql; using System.Sql;

[sdmassembly:name("MyService")]; [Sdmassembly: name ( "MyService")];

[sdmassembly:version(1)]; [Sdmassembly: version (1)];

componenttype MyFrontEnd : AspApplication componenttype MyFrontEnd: AspApplication

{ {

port SqlClient catalog; port SqlClient catalog;

implementation "MyFE, MyClrAssembly"; implementation "MyFE, MyClrAssembly";

} }

componenttype MyBackEnd : SqlDatabase componenttype MyBackEnd: SqlDatabase

{ {

implementation "MyBE, MyClrAssembly"; implementation "MyBE, MyClrAssembly";

} }

componenttype MyService componenttype MyService

{ {

component MyFrontEnd fe; component MyFrontEnd fe;

component MyBackEnd be; component MyBackEnd be;

port http = fe.http; port http = fe.http;

wire SqlTds tds wire SqlTds tds

{ {

fe.catalog; fe.catalog;

be.sqlServer; be.sqlServer;

} }

implementation "MyService, MyClrAssembly"; implementation "MyService, MyClrAssembly";

} }

위를 보면 알 수 있듯이, SDML을 위한 체계(syntax)는 C#로부터 많이 도입한 것이다. As you can see from the above, the system (syntax) for SDML is introduced from a lot of C #. SDML은 컴포넌트, 포트 및 와이어 유형을 정의한다. SDML defines the component, port and wire types. 이 정의를 고려하면 다음과 같다. Considering this definition as follows:

* 사용하는 지령(the using directive)은 SDM 유형의 네임 스페이스(namespaces)를 참조한다. * Command to use (the using directive) is the namespace (namespaces) of SDM types. 이들은, SDM 런타임에 의하여 제공되고 http 와이어 유형과 같은 기본적인 유형을 정의하는 시스템 네임 스페이스를 포함한다. It will be provided by the SDM runtime is included for the system namespace that defines the basic type, such as http-wire type. 기타 네임 스페이스는 IIS 및 SQL 서버와 관련된 유형을 정의한다. Other namespace defines types that are associated with IIS and SQL Server.

* 어셈블리 이름 및 어셈블리 버전은 SDM 어셈블리를 위한 강력한 이름을 제공한다. * The assembly name and version of the assembly provides a strong name for an assembly SDM. 이는 CLR 어셈블리와 아무런 관련이 없다는 것을 유의하여야 한다. It should be noted that there is no connection with the CLR assembly. SDM 어셈블리는 SDM 배포 중 가장 작은 유닛이다. SDM SDM assembly is the smallest unit of deployment. 이는 컴포넌트, 포트 및 와이어 유형의 집합체로 명명되고, 이를 포함한다. This is named as a collection of components, ports, and the wire type, and includes them. SDM 어셈블리는 CLR 어셈블리와 혼동되어서는 안 된다 - CLR 어셈블리와는 완전히 구별된다. SDM assembly is not to be confused with the CLR assembly - is entirely distinct from the CLR assembly.

* MyFronEnd라고 하는 컴포넌트 유형은, Systme.Iis SDM 어셈블리에서 정의되는 참조 유형(referenced type)인 컴포넌트 유형 AspApplication으로부터 상속받은 것으로 선언된다. * Component type that is MyFronEnd, is declared to have been inherited from the reference type, component type AspApplication (referenced type) which is defined in the SDM Systme.Iis assembly. 컴포넌트는 추상적 개념이다; Component is an abstract concept; 컴포넌트는 클래스라고 하고, 인스턴스라고는 하지 않는다. This component is not called, and called the class instance. MyFrontEnd는 컴포넌트를 식별하는데, 이로부터 0개 또는 그 이상의 컴포넌트 인스턴스가 생성될 수 있다. MyFrontEnd is to identify the component, and may be zero or more component instances are generated therefrom.

* port SqlClient catalog; * Port SqlClient catalog; 유형 SqlClient의 MyFrontEnd 컴포넌트에서 포트 를 선언한다. Declare the port in MyFrontEnd components of the type SqlClient. 포트를 이른바 "카탈로그(catalog)"라 한다. Referred to as a port called "catalog (catalog)". 이 포트는, MyFrontEnd가 베이스 컴포넌트 유형 AspApplication으로부터 상속받은 포트, 컴포넌트 및 와이어에 추가되는 것이다. This port will be added to the MyFrontEnd port, component and wire inherited from the base component type AspApplication.

* implementation 키워드는 컴포넌트 유형에 대한 실행을 참조한다. * Implementation Keywords See Run for the component type. 이 실행은 CLR 어셈블리 내의 CLR 클래스로의 참조이다. The run is a reference to a CLR class within a CLR assembly. 이는 컴포넌트 유형에 대한 입구점(entry point) 또는 구조자(constructor)로 생각할 수 있다. This can be thought of as the entry point (entry point) or the rescuer (constructor) for the component type. 컴포넌트 인스턴스가 생성되면, 이 코드가 발동된다(invoked). When the component instance is created, the code is triggered (invoked).

* MyService 컴포넌트 유형은 fe 및 be라고 하는 두 개의 서브 컴포넌트로 정의된다. * MyService component type is defined by two sub-components that fe and be. 이들은 유형 MyFrontEnd 및 MyBackEnd이다. These are the types MyFrontEnd and MyBackEnd. 컴포넌트 MyService의 인스턴스는 컴포넌트 인스턴스의 분류체계(hierarchy)를 형성하는 fe 및 be의 인스턴스를 후속하여 가질 수 있다. MyService instance of the component may have to follow an instance of fe and be formed to a classification system (hierarchy) of the component instance.

* port http=fe.http; * Port http = fe.http; 이는 fe 컴포넌트 상의 http 포트로 위임된 MyService 컴포넌트 유형 상의 포트를 선언한다. It declared a delegated MyService port on the component type the http port on fe components.

* wire SqlTds는 유형 SqlTds의 MyService 컴포넌트 유형의 와이어를, 이름 tds로 선언한다. * Wire SqlTds declares wire MyService component type of type SqlTds, with the name tds. 두 개의 포트가 와이어로 부착된다. The two ports are attached to the wire. 이 선언은, MyService의 인스턴스가 0개 또는 그 이상의 와이어 tds의 인스턴스를 가질 수 있고, 이들 와이어 인스턴스 각각은, 그들에 부착된 fe 컴포넌트로부터의 카탈로그 포트 및 be 컴포넌트로부터의 SQL 포트를 구비할 수 있다. This declaration, the instance of the MyService may have an instance of zero or more wires tds, each of the wire instance, it may include a SQL port from the catalog port and be a component from the fe components attached to them .

서비스의 그래픽적인 표시를 고려하는 것이 종종 도움이 된다. To consider a graphical representation of the service is often helpful. 도 28을 참고하라. Refer to Figure 28. 박스는 컴포넌트를 나타내고, 다이아몬드는 포트를 나타내며, 선은 와이 어를 나타낸다. Box represents a component, a diamond indicates a port, line represents the wire.

컴포넌트 구현(Component Implementation) Component Implementation (Component Implementation)

모든 컴포넌트는 CLR 어셈블리 내의 CLR 클래스의 형태의 구현을 참조할 수 있다. All component may refer to the form of implementation of the CLR CLR class in the assembly. CLR 어셈블리는 SDM 런타임에 의하여 호스팅되고, 컴포넌트 인스턴스 생성 시간(instantiation time)에 발동된다. CLR assemblies being hosted by the SDM runtime, and is triggered on the component instantiation time (instantiation time). SDM을 실행하는 CLR 클래스는 SDM 런타임 API를 호출함으로써 SDM 동작을 수행할 수 있다. CLR class that runs the SDM can perform the operation by calling the SDM SDM Runtime API. 이는 이 문서의 뒷부분에서 상세하게 설명한다. This will be described in detail later in this article. 다음은 상기의 MyService SDM 컴포넌트 유형의 실행을 위한 C# 코드의 일부이다. The following is a part of the C # code of the MyService SDM component type of the run.

using System; using System;

using Microsoft.SDM; using Microsoft.SDM;

public class MyService: SDMComponentInstance public class MyService: SDMComponentInstance

{ {

public override OnCreate(...) public override OnCreate (...)

{ {

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

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

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

SDMWire tds1 = CreateWire instanceance("tds"); SDMWire tds1 = CreateWire instanceance ( "tds");

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

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

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

} }

} }

이 코드는 SDMComponent로부터 상속받은 C# 클래스 MyService를 정의한다. This code defines a C # class that inherits from MyService SDMComponent. 클래스는 OnCreate() 방법에 우선하고, fe 컴포넌트의 2개의 인스턴스, be 컴포넌트의 하나의 인스턴스 및 하나의 와이어 인스턴스를 생성한다. First, the class OnCreate () method, and generates a second one of the instances and the instances of the one wire instances, be a component of the component fe. 그리고 이는 와이어 인스턴스로 3개의 포트를 추가한다. And that adds three ports to the wire instance.

이 CLR 코드는, MyService를 위한 SDM 내에서 참조되는 MyClrAssembly라고 하는 어셈블리로 컴파일된다. The CLR code is compiled into an assembly that MyClrAssembly referenced within the SDM for MyService. 유형 MyService의 컴포넌트가 컴포넌트가 인스턴스 생성(instantiate)되면, 이 코드가 발동되고, OnCreate 방법이 호출된다. If the type of component MyService component is generating an instance (instantiate), the code is invoked, the OnCreate method is called.

[BassamT] C# 코드의 강력하게 유형화된 버전을 고려해 보자. Let [BassamT] consider a strongly typed version of the C # code.

인스턴스(Instances) Instance (Instances)

SDML은 컴포넌트, 포트 및 와이어 유형을 정의하기 위하여 사용된다; SDML is used to define the components, ports, and the wire type; 이는 인스턴스를 정의하지는 않는다. It does not define an instance. 인스턴스는, 상기 C# 코드에 나타낸 바와 같이 SDM 런타임 API를 사용하여 생성될 수 있다. Instance, it can be generated using the SDM runtime API, as shown in the C # code. 상기 C# 코드는 다수의 인스턴스를 생성하였고, 인스턴스 스페이스에 와이어링 토폴로지를 형성하였다. The C # code was created a number of instances, thereby forming the wiring topology in the instance space. 이러한 인스턴스는 SDM 런타임에 의하여 추적될 것이다. These instances will be tracked by the SDM runtime. 예를 들어, SDM 런타임은, OnCreate 호출이 상기의 것을 완료한 후 다음의 정보를 저장한다: For example, SDM runtime, OnCreate after the call is completed to the stores the following information:

component instance ms[1] component instance ms [1]

port instance http[1] port instance http [1]

component instance fe[1] component instance fe [1]

component instance fe[2] component instance fe [2]

component instance be[1] component instance be [1]

wire instance tds[1] wire instance tds [1]

fe[1].catalog fe [1] .catalog

fe[2].catalog fe [2] .catalog

be[1].SqlServer; be [1] .SqlServer;

주의: 여기서 사용된 체계(syntax)는 SDML이 아니다; Note: The system (syntax) is not used here SDML; 이는 SDM 런타임에 의하여 추적되는 인스턴스 스페이스를 예시하기 위하여 사용된다. Which is used to illustrate the instance space it is tracked by the SDM runtime.

ms[1]은 3개의 자식 컴포넌트 인스턴스(children component instance), fe[1], fe[2], 및 be[1]을 갖는 컴포넌트 인스턴스이다. ms [1] is three child component instance (children component instance), fe [1], fe [2], and a component having an instance be [1]. fe[1] 및 fe[2]는 fe 컴포넌트의 인스턴스이다. fe [1], and fe [2] is an instance of a component fe. be[1]은 be 컴포넌트의 인스턴스이다. be [1] is an instance of the component be. tds[1]은 3개의 멤버를 포함하는 와이어 인스턴스이다. tds [1] is a wire instance including three members. 도식적으로는, 도 29에 인스턴스 스페이스가 도시되어 있다. Diagrammatically, there is an instance space is shown in Figure 29.

컴포넌트 인스턴스는 실제 물리적인 명시(manifestations)를 포함한다 - 이 예에서 fe[1] 및 fe[2]가 윈도우 기계에서 실행하는 IIS상에서 실행되는 두 개의 ASP.NET 애플리케이션이다. Component instance and a specified (manifestations) actual physical - the two ASP.NET application In this example, fe [1], and fe [2] is executed on the IIS running on a Windows machine. CreateComponentInstance로의 호출이 행해지면, 새로운 ASP.NET 애플리케이션이 생성되고 IIS 박스로 구성된다. If you made a call to CreateComponentInstance, a new ASP.NET application is created and configured with IIS box. 다수의 중간 단계가 발동될 수도 있다 - 예를 들어, 새로운 자원을 사용하기 위하여 호출자의 신용 카드에 부과되거나, 용량의 부족으로 인하여 새로운 기계가 할당된다. There are a number of intermediate steps may be played-for example, or charged to the caller's credit card to use the new resources, the new machine is allocated due to lack of capacity. 이 문서의 뒷 부분에서 컴포넌트 설명 후에 기계를 실험한다. Later in the document the experimental machine after component description.

서비스 배포 유닛(Service Deployment Units) Service Deployment Unit (Service Deployment Units)

MyService를 위한 SDM 모델은 컴포넌트, 포트 및 와이어로서 서비스의 구조를 정의하였다. SDM model for MyService was defined as the structure of a service component, the port and wire. 이는 SDM 런타임 기계에 설치될 수 있는 SDM 어셈블리로 귀착된다. This results in a SDM SDM runtime assembly that can be installed on the machine. 명백하게, SDM 어셈블리는 서비스를 인스턴스 생성(instantiating)하기에 충분하지는 않다. Apparently, SDM assembly is not sufficient for generating (instantiating) an instance of service. SDM 어셈블리에 추가하여, 컴포넌트의 구현인 CLR 어셈블리도 고려하여야 한다. In addition to the SDM assembly, it should be considered in the implementation of the CLR assembly components. 우리는 ASP.NET 코드, SQL 스크립트, 및 서비스에 의하여 필요한 모든 것을 고려하여야 한다. We should consider all the code required by ASP.NET, SQL scripts, and services. 이러한 모든 부분의 총합이 서비스 배포 유닛(SDU)에 패키징된다. The sum of all these parts are packaged in a service distribution unit (SDU). 도 30을 참고하라. Refer to Figure 30.

SDM 런타임 SDM runtime

SDR 런타임(또는 단순히 런타임)은 SDM의 구현을 호스팅한다. SDR Runtime (or just runtime) is hosting the implementation of the SDM. 이는 SDM 유형, 멤버 및 인스턴스 스페이스(instance space)를 조작하기 위한 세트 API들을 공개하는 고가용성 분배 서비스(distributed service)이다. This is a high-availability distributed services (distributed service) to set the public API for manipulating the SDM type, member and instance space (instance space). 런타임은 일관된 방식으로 모든 SDM 인스턴스를 추적할 책임이 있다. Runtime is responsible for tracking all SDM instances in a consistent manner. 이는 배포(deployment), 버져닝(versioning), 보안, 및 복구를 위한 기계 장치를 제공한다. This provides a mechanism for the deployment (deployment), versioning (versioning), security, and recovery.

이 섹션에서는 BIG V1.0 공개물에서 제안된 SDM 런타임의 설계 및 구현에 대하여 설명한다. This section describes the design and implementation of the proposed SDM runtime in BIG V1.0 publications. SDM 런타임의 다른 실시예가 물론 있을 수 있지만, 우리는 이 문서에서 한 가지에 초점을 맞춘다 - BIG 컴퓨터 상에 호스팅되는 고가용성 SDM 런타임 구현을 고려한다(상세한 사항은 _____를 참고하라). Consider the availability SDM Runtime implementation that is hosted on the BIG computer (for details, see Do _____) - SDM runtime, there may be other embodiments of the examples, of course, we have to focus on one thing in the documentation.

런타임 아키텍처(Runtime Architecture) Runtime Architecture (Runtime Architecture)

도 27은 SDM 런타임의 논리적인 아키텍처를 도시한다. Figure 27 shows the logical architecture of the SDM runtime.

SDM 런타임은 다음과 같이 구성된다. SDM runtime will be configured as follows:

* SDM 런타임 - 이는 SDM 런타임 구현이다. * SDM runtime - which is implementing the SDM runtime. 이는 하나 이상의 물리적인 기계에서 실행되는 분산된 구현이다. This is a distributed implementation that runs on one or more physical machines. 런타임은, SDM 및 인스턴스를 조작하는 호출의 세트인 SDM API를 통하여 그 기능을 발휘한다. Run time, exerts its function through a set of SDM API call, and for operating the SDM instance.

* SDM 스토어(SDM Store) - 이는 SDM 모델 및 인스턴스를 위한 영구적인 스토어이다. * SDM Store (SDM Store) - This is a permanent store for SDM Models and instances. 이 스토어는 고가용성이며, 일관성이 중요하다. The store is a high-availability, consistency is important. 이 스토어는 치명적인 이벤트에도 견뎌낸다. The store will also produce enduring catastrophic events.

* 서비스 배포 유닛(Service Deployment Units) - 이는 SDU들을 위한 읽기 전용 스토어이다. * Service Deployment Unit (Service Deployment Units) - This is a read-only store for the SDU. SDM 스토어와 마찬가지로, 이는 고가용성이며, 치명적인 이벤트에도 견뎌낸다. Like the SDM Store, which is a high-availability, it produces withstand even catastrophic events.

* 컴포넌트 구현 호스트(Component Implementation Host) - 이는 SDM 컴포넌트로부터 참조된 CLR 코드를 호스팅하기 위한 프레임워크(framework)이다. * Component implementation host (Component Implementation Host) - which is a framework (framework) to host a CLR reference code from the SDM component.

SDM 런타임은 전형적으로 이하의 클라이언트 클래스에 의하여 사용된다: SDM Runtime is typically used by the client class below:

* 컴포넌트 인스턴스(Component Instances) - 이들은 SDM 런타임 라이브러리(RTL)를 사용하는 런타임과 통신하는 컴포넌트 인스턴트이다. * Component instance (Component Instances) - These are the components to communicate with the run time instant using the SDM runtime library (RTL). 우리는 두 가지 유형의 컴포넌트 인스턴스 - 런타임 호스팅된 컴포넌트 인스턴스(runtime-hosted component instances) 및 런타임 호스팅되지 않은 컴포넌트 인스턴스를 구별한다. We have two types of component instances - to run a hosted component instance (runtime-hosted component instances) and distinguish between a component instance that is not runtime hosting.

* 개발 및 배포 도구(Development and Deployment tools) - 이들은 SDM 컴파 일러, SDU 설치 도구 및 기타 개발 도구를 포함한다. * Development and deployment tools (Development and Deployment tools) - they SDM compiler, SDU includes installation tools, and other development tools.

* 관리 도구(Management tools) - 이들은 런타임 자체를 등록하고 관리하기 위하여 사용되는 권한이 부여된 도구(privileged tools)이다. * Management tools (Management tools) - These are the tools (privileged tools) is authorized to be used to register and manage the runtime itself.

클라이언트는 SDM 런타임 라이브러리(RTL)를 통하여 런타임과 통신한다. The client communicates with the runtime through the SDM Runtime Library (RTL). 이들은 전형적으로 이하를 포함하는 동작을 수행한다. It typically performs operations that include more than a.

* SDU들의 설치/설치제거: 이는 새로운 SDU들을 SDM 런타임의 실행중인 인스턴트에 추가 및 제거하는 프로세스이다. * Uninstall / install of SDU: This is the process of adding and removing new SDU in an instant running of the SDM runtime.

* SDM 유형 및 인스턴스의 추가, 제거 및 수정: 클라이언트는 새로운 컴포넌트, 포트 및 와이어 유형을 생성할 수 있다. * Add, remove, and modify the SDM types and instances: the client can create a new component, port and wire types.

* 인스턴스의 생성 및 삭제: 클라이언트는 새로운 컴포넌트, 포트 및 와이어 인스턴스를 생성할 수 있다. * Creation and deletion of instances: the client can create a new component, port and wire instance.

* 이벤트의 소싱(Sourcing) 및 하강(sinking): 유형 및/또는 인스턴스 스페이스에 변경이 행해진 경우, 런타임은 영향을 받는 클라이언트에게 이벤트를 전송한다. - sourcing (Sourcing) and lowered (sinking) of the event: when subjected to changes in the type and / or the instance space, run-time and transmits the event to the clients that are affected. 이벤트는 포트 바인딩 정보(port binding information)를 설정하는 것과 같이 특정 동작에 의해 트리거될 수 있다. Event may be triggered by a specific operation such as to set the port binding information (port binding information).

* 유형 및 인스턴스 스페이스를 질의한다: 클라이언트는 유형 및 인스턴스 스페이스를 반영할 수 있다. * Query the type and instance space: Clients can reflect the type and instance space.

유형, 멤버 및 인스턴스 스페이스(Type, member and instance space) Type, member and instance space (Type, member and instance space)

컴포넌트 유형, 컴포넌트 및 컴포넌트 인스턴스간의 관계는 최신 객체 지향 언어의 클래스, 클래스 멤버, 및 객체와 유사하다. The relationship between the component type, component and component instance is similar to the latest object-oriented languages, classes, class members, and objects. SDM은 유형, 멤버 및 인스턴스 스페이스간의 분리를 정의한다. SDM defines the separation between the types, members, and the instance space. 컴포넌트 유형은 유형 스페이스(type space)에 있고, 컴포넌트는 멤버 스페이스(member space)에 있으며, 컴포넌트 인스턴스는 인스턴스 스페이스(instance space)에 있다. Component type and the type of space (type space), the space component and the members (member space), a component instance is the instance space (instance space). 도 31은 3개의 스페이스간의 분리를 도시한다. Figure 31 shows the separation between the three spaces.

"멤버 스페이스"는 유형 스페이스의 인스턴스를 포함한다. The "member space" includes an instance of the type of space. "인스턴스 스페이스"는 멤버 스페이스의 인스턴스를 포함한다. The "instance space" includes an instance of the member space. SDM 런타임은 3개의 모든 스페이스 및 이들의 관계를 추적할 책임이 있다. SDM runtime is responsible to keep track of all three spaces and their relationship. 이 정보는 SDM 스토어 내에 저장되고, 런타임 API를 사용함으로써 질의될 수 있다. This information is stored in the SDM store, it can be queried by using the run-time API. 컴포넌트 및 와이어는 0개 또는 그 이상의 인스턴스를 가질 수 있다. Components, and the wire may have one or more instance 0. 포트는 하나의 인스턴스만을 갖는다. Port has only one instance.

SDM 멤버 및 인스턴스 스페이스는 엄격한 계층을 따른다. SDM instance space is member and follows a strict hierarchy. 멤버 및 인스턴스 스페이스 내의 모든 컴포넌트는 트리로 배열된다. Members instance and all components within the space are arranged in a tree. 루트 컴포넌트는 "루트(root)" 또는 "범용(universal)" 컴포넌트라고 하는 특별한 컴포넌트이다. Root component is a special component called a "root (root)" or "general-purpose (universal)" component. 이전 섹션의 MyService 예로부터 멤버 트리를 보자(도 32). Let the member trees from MyService example of the previous section (Fig. 32). 박스는 컴포넌트를 나타내고, 선은 부모/자식(parent/children) 관계이다. Box represents the components, the line parent / child (parent / children) a relationship. myService는 루트 컴포넌트의 멤버 컴포넌트이다. myService component is a member of the root component. 인스턴스 트리는 도 33에 도시된 것과 같이 구성될 수 있다. Instance tree can be configured as illustrated in FIG. 서로 다른 수의 자식 인스턴스를 갖는 myService 컴포넌트의 2개의 인스턴스가 있다는 것을 유의하여야 한다. It should be noted that the two instances of myService components having a different number of child instances. myService[1].fe[1] 및 myService[2].fe[2]는 같은 컴포넌트 멤버 "fe"를 가지고, 같은 컴포넌트 유형 "MyFrontEnd"를 갖지만, 그 이외에는 전혀 별개의 컴포넌트 인스턴스이다. myService [1] .fe [1] and myService [2] .fe [2] has the same component members "fe", gatjiman the same component type "MyFrontEnd", it is a separate component instance Otherwise all. "root[1]"은 루트 컴포넌트의 인스턴스일 뿐이다. "Root [1]" is only one instance of the root component.

컴포넌트 인스턴스 생성(Component Instantiation) Generating component instance (Component Instantiation)

SDM 런타임에 의하여 제공되는 기본적인 동작 중 하나는 컴포넌트 인스턴스 생성이다. One of the fundamental operations which are provided by the SDM runtime is generating component instance. 이는 컴포넌트 인스턴스가 존재하게 되는 프로세스이다. This is a process in which the there is a component instance. 인스턴스(또는 객체)를 생성하는 것이 전형적으로 인스턴스를 위한 메모리의 청크(chunk)를 할당하고 초기화하는 것과 관련되어 있는 전통적인 컴포넌트 모델과 달리, SDM 컴포넌트는 전형적으로 서로 다른 부분에 의하여 수행되는 많은 단계와 관련되고, 완료하기 위하여 수시간, 아니면 수일이 걸릴 수 있다. A number of steps to create an instance (or object) that is typically assigned to the chunks (chunk) in the memory for instance, unlike traditional component model, and that are related to the initialization SDM component is typically carried out with each other by the other part and In order to be relevant and, completion time, or you can take a few days. 예를 들어, 유형 ASP.NET 애플리케이션의 컴포넌트가 인스턴스 생성되면, 결과는 구성 동작(configuration act)이 후속하는 IIS를 실행하는 기계 상의 새로운 가상 웹 사이트이다. For example, if the type of ASP.NET application components to create an instance, the result is a new virtual Web site on the machine running IIS to configure a subsequent operation (configuration act). IIS 기계의 용량에 도달하는 시나리오를 고려하면, ASP.NET 애플리케이션이 인스턴스 생성되기 전에 새로운 하나가 할당되어야 한다. Given the scenario, to reach the capacity of the IIS machine and should be assigned a new one before the ASP.NET application to create an instance. 이 프로세스는, 풀(pool)로부터 새로운 기계를 할당하는 것, 가능하면 빌딩 변경을 발생시키는 것, 및 IIS를 포함하는 오퍼레이팅 시스템을 설치하는 것을 포함하기 때문에 수시간 걸릴 수 있다. This process is, for assigning a new machine from the pool (pool), if possible, it may take several hours because it involves the installation of the operating system including the one that generates a building changes, and IIS. SDM 런타임은 컴포넌트 인스턴스 생성을 위한 두 가지 방법을 지원하는데, 두 가지 방식이란 1) 팩토리(Factory)가 컴포넌트를 인스턴스 생성하는 것과, 2) 런타임이 컴포넌트 인스턴스를 생성하는 것이다. SDM runtime supports two methods for generating component instance, two methods is 1) to the factory (Factory) is generated as a component instance, and 2) to create a run-time component instance. 이러한 방법은 이하에서 간략히 설명한다. This method will be described briefly below. 더 자세한 내용은 "Component Instantiation" 명세서를 참조하라. Do more, see the "Component Instantiation" herein for more information.

팩토리가 컴포넌트 인스턴스를 생성(Factory instantiated components) Factory generates a component instance (Factory instantiated components)

컴포넌트 팩토리(또는 단순히 팩토리)는 하나 이상의 컴포넌트 유형을 위한 인스턴스를 생성할 책임이 있는 엔티티이다. Component factory (or simply Factory) is an entity that is responsible for creating instances for one or more of the component types. 팩토리는 인스턴스 생성을 위하여 하나 이상의 포트를 공개하는 컴포넌트 자체이다. Is factory component itself to release the at least one port for the instantiation. 팩토리를 생각하는 한 가지 방법 은 자원 관리자로서이다. One way to think of the factory is as a resource manager. 팩토리가 관리하는 자원은 컴포넌트 유형이다. Resource management is a factory component type. 팩토리는 자원을 컴포넌트의 인스턴스로 맵핑(mapping)하는 방법을 알고 있다. Factory knows how to map (mapping) of resources as an instance of the component. 예를 들어, 우리가 유형 컴포넌트 "File Storage"를 갖는다고 가정해 보자. For example, let's assume that we have the type of component "File Storage". 이 컴포넌트가 인스턴스 생성되면, NTFS 발견이 생성되고, 적절한 ACL들이 준비될 것이다. When this component is generated instance, NTFS discovery is created would be prepared to the appropriate ACL. 이 컴포넌트를 위한 팩토리는 기억장치를 할당하기 위한 다수의 윈도우 기계를 관리한다. Factory for this component manages multiple windows machine for allocating storage. 팩토리는 NTFS 공유를 생성하고, ACL들 및 분담할 몫(quotas) 등을 설정하는 책임이 있다. The factory is responsible for creating the shared NTFS, and set the shares (quotas), etc. to the ACL and sharing. 컴포넌트 팩토리는 SDM 런타임에서 중요한 역할을 수행한다. Component factory plays an important role in the SDM runtime. 이들은 전형적으로 서비스를 위하여 자원을 관리하기 때문에, 이들은 신뢰성 있으며 고가용성이라 예상된다. Because they typically to manage resources for the service, it can be reliably estimated as high availability. SDM 런타임에 의하여 지원되는 컴포넌트 팩토리의 수는 개방 종료되지만(open ended), 우리는 BIG V1.0이 적은 수의 기본 컴포넌트 팩토리를 가질 것으로 예상한다. The number of component factories that are supported by the SDM runtime is terminated, but the open (open ended), we expect to have a small number of basic components factory, the BIG V1.0. 컴포넌트 팩토리는 이하와 같다. Factory component is as follows.

* 하드웨어 - 이는 하드웨어의 인스턴스를 할당하고 관리하기 위한 책임이 있는 기본 레벨 팩토리이다. * Hardware - This is the default factory level which is responsible for allocating and managing instances of hardware. 예를 들어, 이는 1GB의 메모리, 또는 NAS와 같은 기억장치 장치를 사용하여 서버 기계를 할당할 수 있다. For example, it can be assigned to the server machine by using the storage device, such as 1GB of memory, or NAS.

* 네트워크 - 이 팩토리는 VLANs, 공용 IP 어드레스, DNS 네임 등을 책임진다. * Network - This factory is responsible for the VLANs, a public IP address, DNS name and the like.

* PC - 이 팩토리는 기계를 할당하고 풀 OS 이미지(full OS-image)를 그것에 배포할 수 있다. * PC - the factory may assign the machine and deploy a full OS image (full-OS image) on it.

* 기억장치 - 이 팩토리는 기억장치를 관리하고 할당하는 책임이 있다. * Memory - this factory is responsible for managing and allocating the storage device.

* 소프트웨어 자원 - ASP.NET, IIS 웹 사이트, SQL 서버, 데이터베이스 등. Such as ASP.NET, IIS Web sites, SQL Server, database-software resources *.

인스턴스 생성 프로세스(Instantiation process) Instance generation process (process Instantiation)

팩토리는 어느 컴포넌트 유형이 그 인스턴스를 생성할 책임이 있는지를 지정하는 SDM 런타임을 사용하여 등록하여야 한다. Factories must register with the SDM runtime specifying whether the obligation to generate a certain type of component that instance. 하이레벨에 있어서, 인스턴스 생성의 프로세스는 다음과 같다: In the high level, the process of generating an instance is as follows:

호출자(caller)는 SDM 런타임으로 주어진 컴포넌트 유형에 대한 컴포넌트 팩토리를 요청한다. Caller (caller) makes a request to the component factory for a given component type in the SDM runtime.

1. SDM 런타임은 적절한 컴포넌트 팩토리를 발견하고, 이를 호출자에게 반환하는 책임을 진다. 1. SDM Runtime is responsible for finding the appropriate components factory, and returns it to the caller.

2. 그 후, 호출자는 컴포넌트 팩토리와 직접 통신하여, 하나 이상의 인스턴스를 생성하도록 요청한다. 2. Then, the caller is requested to communicate directly with the component factory, generate one or more instances.

런닝 팩토리 테이블(Running Factory Table) Running Factory table (Running Factory Table)

SDM 런타임은 컴포넌트 유형 및 그들의 적절한 팩토리의 테이블을 보유한다. SDM runtime will have a table of component types and their appropriate factory. 모든 컴포넌트 인스턴스는 런닝 팩토리 테이블을 갖는다. All component instance has a running factory table. 런닝 팩토리 테이블 구조는 다음과 같다. Running Factory table structure is as follows:

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

컴포넌트 인스턴스는 그들의 테이블 및 그들의 바로 자식인 테이블(direct children's tables)에 엔티티를 추가/제거할 수 있다. Component instances can be added / removed entities on their tables, and the tables of their child directly (direct children's tables). 디폴트로서, 새로운 자식 컴포넌트 인스턴스가 생성되었을 때, 부모의 런닝 팩토리 테이블이 상속된다. As a default, when a new child component instance is created, it is inherited by running a factory of the parent table.

런닝 팩토리 테이블은 다른 환경의 동일한 컴포넌트 유형을 위한 다른 팩토리를 지원하기 위하여 모든 컴포넌트 인스턴스에 대하여 추적된다. Running factories table is tracked for every component instance to support other factories for the same types of components in other environments. 팩토리는 전형 적으로 리소스가 할당되는 곳이기 때문에, 환경을 호스팅하는 것은 자원 할당에 대한 서로 다른 폴리시를 요구할 수 있다. Since the factory where the typical enemies in resource allocation, which is hosting environment may require a different policy for resource allocation. 예를 들어, Digex와 같은 호스팅 엔티티가 그들의 고객에 대하여 서로 다른 계획을 갖는 시나리오를 고려해 보자. For example, the hosting entity, such as Digex Consider a scenario with different plans for their customers. 골드(Gold)를 위해 지불한 고객은 전용 IIS 박스(dedicated IIS box)를 획득하고, 실버(Silver)를 위해 지불한 고객은 공유 IIS 박스(shared IIS box)를 획득한다. Customers pay for the Gold (Gold) has acquired a dedicated IIS box (dedicated IIS box), and the customer pays for the Silver (Silver) acquires shares IIS box (shared IIS box). 고객의 서비스는 "ASP.NET 애플리케이션" 유형의 컴포넌트를 포함하고, 이는 전용 IIS 기계 또는 공유되는 IIS 기계로 호스팅되는지 여부를 알지 못한다. Customer service, including the type of component "ASP.NET Applications", which does not know whether a dedicated hosting or shared IIS IIS machines machines are. Digex는 도 34에 도시한 것과 같이 이를 구현할 수 있다. Digex may implement this, as shown in FIG.

Digex는 골드 팩토리(Gold Factory) 및 실버 팩토리(Silver Factory)의 2가지 컴포넌트를 갖는 컴포넌트이다. Digex is a component having two components of a gold factory (Gold Factory) and Silver Factory (Silver Factory). 팩토리는 컴포넌트 자체이다. Factory is a component itself. Digex는 또한 "골드" 및 "실버"라고 하는 기타 컴포넌트를 정의한다. Digex also defines other components, referred to as "gold" and "silver". 이러한 "골드" 컴포넌트는 골드 서비스를 위하여 지불한 모든 서비스의 부모(parent)이다. The "Gold" component is the parent (parent) of all services paid for gold services.

Digex가 인스턴스 생성되면, 이는 팩토리의 인스턴스 및 "골드" 및 "실버" 컴포넌트의 인스턴스를 생성한다. When Digex instance creation, which creates an instance of the factory instance, and "gold" and "silver" component. Gold[1]은 고유의 런닝 팩토리 테이블을 갖는다. Gold [1] has a specific running factory table. Digex는 적절한 SDM 런타임 API를 호출함으로써 이 테이블에 골드 팩토리를 등록한다. Digex registers a gold factory on the table by calling the appropriate SDM Runtime API. 새로운 고객의 서비스가 Gold[1]의 자식으로서 인스턴스 생성되면, 이는 Gold[1]의 런닝 팩토리 테이블을 상속받는다. When a new customer service create an instance as a child of Gold [1], which inherits the running factory table of Gold [1]. 이는, "ASP.NET 애플리케이션"의 컴포넌트 인스턴스가 생성되었을 때, 골드 팩토리가 이 요청을 처리하고 고객의 구좌에 적절히 부과한다. This will be when the component instance of "ASP.NET Applications" generation, gold factory to process the request and properly charged to the customer's account.

팩토리 추적(Factory tracking) Factory Tracking (Factory tracking)

SDM 런타임은 각 컴포넌트 인스턴스를 생성한 팩토리의 추적(track)을 보유한다. SDM runtime will hold the track (track) of the factory generated for each component instance. 도 35를 참고하라. See Figure 35. 점선은 컴포넌트 인스턴스와 이를 생성한 팩토리 사이의 "~에 의하여 생성된(created by)" 관계를 나타낸다. The dotted line represents a "(created by) produced by ~" between the component instances with the factory create this relationship. 상술한 바와 같이, 팩토리는 컴포넌트 자체이고, 따라서 팩토리는 팩토리를 가지고 있어야 한다. As described above, the factory component itself, and thus the factory shall have a factory. 런타임의 무한 반복을 종료하는 것은 이하에서 설명하는 바와 같이 "런타임 호스팅된 컴포넌트(runtime-hosted components)"에 대한 팩토리이다. It is a factory for "components (runtime-hosted components) host run-time" as described below to terminate the endless loop of the run time. 루트 컴포넌트 인스턴스는 특수한 것이며, 이는 고유의 팩토리임을 유의하여야 한다. Root component instance will the special, it should be noted that own factories.

팩토리 및 트랜잭션(Factories and Transactions) Factories and transactions (Factories and Transactions)

팩토리는 서비스 개발자가 복잡한 롤백(rollback) 및 오류 처리 논리(error handling logic)에 대한 걱정을 덜 수 있도록 트랜잭션을 지원한다. Factory support the transaction service allows developers to worry less about complicated rollback (rollback) and error-handling logic (error handling logic). 트랜잭션된 서브시스템(transacted subsystems)의 상부(top)에 구축되지 않은 팩토리는 보상을 지원할 필요가 있다. Factories are not built in the upper (top) of the transaction subsystem (transacted subsystems) may need to support compensation. 팩토리는 또한 분산 트랜잭션에서 협력(enlisting)을 지원하여야 한다. Factory shall also support cooperation (enlisting) in a distributed transaction.

팩토리는 전형적으로 인스턴스 생성과 관련된 다수의 부기 정보(bookkeeping information)를 보유한다. Factory typically has a number of bookkeeping information (bookkeeping information) associated with the instantiation. 이 부기 정보는 적절한 복구를 보장하기 위하여 SDM 런타임과 함께 일관되게 유지되어야 한다. The bookkeeping information shall be consistent with the SDM runtime in order to ensure adequate recovery. 이를 용이하게 하기 위하여, SDM 런타임은, 팩토리를 포함하는 컴포넌트 인스턴스를 위한 트랜잭션된 기억장치 서비스(transacted storage service)를 제공한다. In order to facilitate this, SDM runtime, and provides a storage service (transacted storage service) for transaction component instance comprising a factory. 잘 쓰여진 팩토리(well-written factory)는 이 스토어 내에 모든 부기 정보를 저장한다. Factory (well-written factory) well-written and stores all the information in the store bookkeeping.

팩토리 포트(Factory port) Port Factory (Factory port)

팩토리는 전형적으로 컴포넌트 인스턴스 생성을 위하여 사용될 수 있는 하나 이상의 포트를 공개한다. Factory will typically release the one or more ports that can be used as the component instantiation. 포트 유형은 SDM 런타임에 의해 명령되지 않지만, 모든 컴포넌트 팩토리가 SDM_Factory 포트를 지원하는 것을 추천한다. Port types are not mandated by the SDM runtime, it is recommended that all components factory support SDM_Factory port. SDM_Factory는 새로운 컴포넌트 인스턴스를 생성하기 위하여 호출되는 SOAP 기반 포트(SOAP based port)이다. SDM_Factory is a SOAP-based port (port based SOAP), which is called in order to create a new component instance. 이 포트를 위한 C# 인터페이스는 다음과 같다. C # interface for this port are as follows:

public interface ISDMFactory public interface ISDMFactory

{ {

ComponentInstance Instantiate( ComponentInstance Instantiate (

ComponentInstance parent, ComponentInstance parent,

Component component, Component component,

ComponentType componentType, object args); ComponentType componentType, object args);

void Alloc(ComponentInstance allocInstance); void Alloc (ComponentInstance allocInstance);

void Construct(ComponentInstance constructInstance); void Construct (ComponentInstance constructInstance);

} }

ISDMFactory는 3개의 패스 인스턴스 생성 프로세스(pass instantiation process)를 지원한다: ISDMFactory supports three passes instantiation process (pass instantiation process):

인스턴스 생성 패스(Instantiation Pass): 이 패스는 SDM 런타임을 사용하여 모든 컴포넌트 인스턴스를 반복적으로 생성한다. Generating an instance path (Instantiation Pass): a path is repeatedly generated by all elements of the instance using the SDM runtime. 그러나 이는 할당이나 작성(construction)은 하지 않는다. However, this assignment or right (construction) is not. 이는 단지 요구되는 "뼈대(skeleton)" 컴포넌트 인스턴스를 생성할 뿐이다. This is just to create a "skeleton (skeleton)" component instances that just demands.

할당 패스(Allocation Pass): 이 패스 동안, 모든 관련 컴포넌트 팩토리는 인스턴스 생성을 위하여 필요한 모든 자원을 할당한다. Assigning path (Allocation Pass): During this pass, any relevant components factory allocates all the resources required for the instantiation.

작성 패스(Construction Pass): 할당이 성공하면, 작성 패스가 개시된다. Writing pass (Pass Construction): If the allocation is successful, starts the write path. 이는 전형적으로 가장 긴 런닝 패스(running pass)이다. This is typically the longest running path (running pass). 팩토리는 전형적으로 작성 패스 동안 모든 실제 작업을 행한다. Factories typically performs all the real work while right path.

팩토리는 물론 인스턴스 생성을 위하여 다른 포트 유형을 지원할 수 있다. Factories may support, as well as any other type of port for the instance is created. 그러나, SDM 런타임 및 런타임 API들은 SDM_Factory 구현과 양호하게 동작하는 다수의 보조 기능을 구비한다. However, SDM runtime and run-time API are provided with a plurality of auxiliary function to operate satisfactorily and SDM_Factory implemented. 이러한 API들은 확실하게 대다수의 개발자를 위한 개발자 경험을 향상시킬 것이다. This API will be sure to enhance the developer experience for the majority of developers.

런타임 호스팅된 컴포넌트 인스턴스(Runtime-hosted component instances) The component instance is hosted runtime (Runtime-hosted component instances)

팩토리 외에, SDM 런타임은, 구현 SDML 키워드를 사용하여 CLR 어셈블리를 참조하는 SDM 컴포넌트를 위한 구현도 호스팅한다. In addition to the factory, SDM runtime will use the implements keyword SDML also hosting implementations for SDM components that reference the CLR assembly. 참조된 CLR 어셈블리는 CLR 클래스의 완전한 자격이 있는 네임(fully qualified name)인 문자열(literal string)이다. See the CLR assembly is a fully qualified class name of the CLR string (literal string) a (fully qualified name) in. 예를 들어, E.g,

componenttype A componenttype A

{ {

port pt x; port pt x;

implementation implementation

"MyNamespace.MyClassName,MyClrAssemblyName" "MyNamespace.MyClassName, MyClrAssemblyName"

} }

또는, 강력하게 명명된 CLR 어셈블리를 위하여 컬쳐(culture), 버전, 및 키를 지정할 수 있다: Alternatively, you can order a strongly named assembly CLR specify the culture (culture), version, and key:

componenttype A componenttype A

{ {

port pt x; port pt x;

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

} }

이러한 컴포넌트에 대하여, SDM 런타임은 팩토리로서 동작하고, SDM 런타임은 이러한 CLR 클래스를 호스팅하고 관리한다. For these components, the SDM runtime is operated as a factory, and the SDM runtime host and manage these CLR class. 또한 이는, 기본 레벨 팩토리가 SDM 런타임에 의하여 호스팅된 CLR 어셈블리로서 구현되기 때문에 상술한 팩토리의 무한 반복을 종료시킨다. This also, to terminate the endless loop of the above-described factory because the factory default level is implemented as a CLR assembly hosted by the SDM runtime.

CLR 어셈블리는 마이크로소프트의 IIS 서버를 사용하여 호스팅된다. CLR assembly is hosted using Microsoft's IIS server. 구현 키워드는 클래스를 참조하는데, 이 클래스는 MarchalByRefObject로부터 상속받아야 하고, IRuntimeHostedImplementation 및 ISDMFactory 인터페이스를 구현하여야 한다. Implementation keyword to refer to a class, the class should be inherited from MarchalByRefObject, implement and IRuntimeHostedImplementation ISDMFactory interface. 편의를 위하여, 기본 클래 SdmComponentInstance는 이러한 인터페이스에 대한 디폴트 구현을 제공한다. For convenience, SdmComponentInstance base class provides default implementations for these interfaces. 다음은 상기 컴포넌트 유형 A를 위한 런타임 호스팅된 CLR 구현의 예이다. The following is an example of the implementation of the runtime CLR host for the component type A.

public class A : SdmComponentInstance public class A: SdmComponentInstance

{ {

protected override void OnCreate(object args) protected override void OnCreate (object args)

{ {

// do something // do something

} }

} }

클래스 A는 SdmComponentInstance로부터 상속받은 C# 클래스이며, 따라서 SDM 런타임에 의하여 호스팅될 수 있다. Class A is a C # class that inherits from SdmComponentInstance, and can therefore be hosted by the SDM runtime. 이 클래스를 위한 CLR 어셈블리는, 이것이 적절하게 동작하도록 하기 위하여 SDU의 /bin 디렉토리에 위치하여야 한다. CLR assembly for this class, which will be located in the SDU / bin directory to ensure proper operation. 유형 A의 컴포넌트의 인스턴스가 생성되면, 런타임은 가용한 호스트 IIS 기계를 탐색하고 그 기계에 CLR 코드를 인스턴스 생성하는 책임이 있다. When an instance of the Type A components created, the runtime is responsible for searching the IIS machines available host and create instances of the CLR code on the machine. CLR 코드는, IIS에 의하여 호스팅되는 .NET 원격 애플리케이션으로서 호스팅된다. CLR code is hosting a .NET remoting applications hosted by IIS. SDU 내의 모든 CLR 어셈블리는 IIS 프로세스를 공유하고, 그 프로세스 내에 고유의 AppDomain을 갖는다. All CLR assemblies in the SDU share the IIS process, and has a unique AppDomain of within that process.

CLR 어셈블리가 로딩되면, 런타임은 IRuntimeHostedImplementation 인터페이스 상의 잘 정의된 입구점(entrypoint)으로 .NET 원격 호출을 수행한다. When the CLR assembly is loaded, the runtime performs a .NET remote calls to the entry point (entrypoint) IRuntimeHostedImplementation well defined on the interface. 이 점에서, CLR 클래스는 ComponentFactory와 동등하고, ISDMFactory 인터페이스는 이전 섹션에서 언급한 것과 같이 소비된다. At this point, CLR class and equal ComponentFactory, ISDMFactory interface is consumed, as mentioned in the previous section.

포트 및 와이어(Ports and Wires) Ports and wires (Ports and Wires)

포트 및 와이어는 SDM 런타임 내의 통신을 위한 베이시스(basis)이다. Port and the wire is a basis (basis) for communication in the SDM runtime. 포트 및 와이어는 오늘날 서비스 배포에 있어서 공통적인 수많은 문제를 해결한다: Port and wire solves many common problems in today's service deployment:

통신 정보의 하드 코딩(Hard coding of communication information) - 많은 서비스는 전형적으로 그 서버의 이름 또는 ip 어드레스를 코드 내에 하드 코딩한다. Hard-coded (Hard coding of communication information) of the communication information-number service is typically hard-coded name or ip address of the server in the code. 예를 들어, 프론트 엔드 서버(front end server)는 전형적으로 데이터베이스 이름, 로그인 및 패스워드와 같은 접속 정보뿐만 아니라 SQL 서버 기계 이름을 하드 코딩한다. For example, the front-end servers (front end server) is typically hardcoded the SQL Server machine name, as well as contact information such as the database name, login and password.

통신 토폴로지의 정의(Defining a communication topology) - 대부분의 서비스 배포는 전형적으로 DMZ를, 통신을 위한 경계를 정의하기 위한 메커니즘만으로 사용한다. Definition of the communication topology (Defining a communication topology) - Most of the services are deployed typically in the DMZ, it uses only a mechanism for defining the boundaries for communication. 다른 제약은 요구되지 않으며, 예를 들어 프론트 엔드 서버가 다른 프론트 엔드 서버와 통신할 필요가 있다면 이는 어디서도 포착되지 않는다. Another limitation is not required, for example, there needs to be a front-end server communicates with the other front-end server, which is not captured anywhere.

발견(Discovery) - 서비스에 추가되거나 서비스로부터 제거된 새로운 컴포넌트에 대하여 찾아내는 것은 전형적으로 오늘날 서비스가 직면하고 있는 문제점이다. Discovery (Discovery) - is added to the service or finding with respect to the new components have been removed from service a problem that typically service today is facing.

SDM은 이러한 문제를 포트 및 와이어를 사용하여 해결한다. SDM solves this problem by using the ports and wires. 포트는 컴포넌트에 공개되는 유형화된 엔티티(typed entities)이다. Port is the entity (entities typed) typed exposed to the component. 포트는 서버 액세스 점(server access point)과 유사하다 - 이는 컴포넌트가, 잘 정의된 기능을 공개하는 곳이다. Port is similar to the access point server (server access point) - This is where the public functions of components are well defined. 예를 들어, "기억장치(storage)" 컴포넌트는, 파일 시스템 동작을 위하여 사용될 수 있는 유형 SMB.Server의 포트를 정의한다. For example, a "storage apparatus (storage)" component, defines a port type of SMB.Server that may be used for file system operations. 와이어는 포트간의 허용 가능한 바이딩(binding)을 정의한다. Wire defines the acceptable by grinding (binding) between the ports. 이는 통신 경로를 제한할 수 있는 통신 토폴로지를 형성한다. This forms a communication topology that can restrict the communication path.

상술한 내용으로부터, MyService 예를 다시 시험해보자. From the foregoing, let's examine the example MyService again.

componenttype MyService componenttype MyService

{ {

component MyFrontEnd fe; component MyFrontEnd fe;

component MyBackEnd be; component MyBackEnd be;

port http = fe.http; port http = fe.http;

wire SqlTds tds wire SqlTds tds

{ {

fe.catalog; fe.catalog;

be.sqlServer; be.sqlServer;

} }

implementation "MyService, MyClrAssembly"; implementation "MyService, MyClrAssembly";

} }

MyService는 tds라는 하나의 와이어를 포함한다. MyService include one wire that tds. 와이어는, 컴포넌트와 마찬가지로 인스턴스를 가질 수 있다. Wire, may have an instance like the component. 예를 들어, 다음은 2개의 서로 다른 와이어 인스턴스 토폴로지를 갖는 MyService ms[1] 및 ms[2]의 2개의 컴포넌트 인스턴스이다. For example, the following is an instance of a two component MyService ms [1], and ms [2] having the two different wires instance topology.

component instance ms[1] component instance ms [1]

wire instance tds[1] wire instance tds [1]

fe[1].catalog fe [1] .catalog

fe[2].catalog fe [2] .catalog

be[1].SqlServer; be [1] .SqlServer;

component instance ms[2] component instance ms [2]

wire instance tds[1] wire instance tds [1]

fe[1].catalog fe [1] .catalog

be[1].SqlServer; be [1] .SqlServer;

wire instance tds[2] wire instance tds [2]

fe[2].catalog fe [2] .catalog

be[1].SqlServer; be [1] .SqlServer;

ms[1]은 3개의 포트 인스턴스를 포함하는 단일 와이어 인스턴스 tds[1]을 갖는다. ms [1] has a single-wire instance tds [1], which includes three ports instance. ms[2]는 각각 2개의 포트 인스턴스를 갖는 2개의 와이어 인스턴스 tds[1] 및 tds[2]를 갖는다. ms [2] has two wire instance tds [1] and tds [2] each having two ports instance. 첫 번째 경우에 있어서, fe[1] 및 fe[2]는 서로 볼 수 있다. In the first case, fe [1], and fe [2] can be seen together. 두 번째 경우에 있어서는, fe[1] 및 fe[2]는 서로 볼 수 없다. In the second case, fe [1], and fe [2] can not see each other.

와이어 인스턴스는 물리적인 통신 토폴로지를 형성한다. Wire instance forms a physical communication topology. 포트 인스턴스는 와이어 인스턴스의 멤버이다. Port instance is a member of the wire instance. 이들은 다음과 같은 것을 할 수 있다: You can do the following:

1) 서로에게 질의하거나 서로를 발견할 수 있다 - 런타임 API는 동일한 와이어 인스턴스 상의 다른 포트 인스턴스에 질의하고 발견하기 위한 기능을 지원한다. 1) can be queried to find each other or each other - Runtime API supports the ability to query and find a different port instance on the same wire instance. 모든 멤버는 동일한 와이어 인스턴스 내에서 볼 수 있다. All members can be seen in the same wire instance. 또한, 와이어 인스턴스의 소유자는 어느 때나 멤버에 질의할 수 있다. In addition, the owner of wire instances can be queried at any time to the members.

2) 이벤트를 수신할 수 있다 - 와이어의 멤버는 멤버 포트 인스턴스 상의 SDM 동작에 의하여 트리거되는 이벤트를 수신할 수 있다. 2) can receive the event - a member of the wire may receive events triggered by the operation on the SDM instance port member. 자세한 사항은 아래의 " 이벤트(Events)"를 참고하라. Make more details, refer to the "Events (Events)" below.

3) 통신을 제한할 수 있다 - 와이어 인스턴스는 컴포넌트 인스턴스간의 허용되는 통신 경로를 제한한다. 3) it is possible to limit the communication-wire instance limits the communication path is allowed between the component instance.

포트 바인딩 정보(Port binding information) Port binding information (Port binding information)

포트는, 컴포넌트에 의하여 공개되는 유형화된 엔티티(typed entities)이다. Port, is an entity (entities typed) typed exposed by the component. 포트는 정확하게 하나의 인스턴스를 갖는다. Port may have one instance of exactly. 포트 인스턴스는 바인딩 정보를 운반할 수 있는데, 바인딩 정보는 전형적으로 컴포넌트 간의 통신 채널을 설정하기 위하여 요구되는 모든 것이다. There is a port instance can carry a binding information, binding information is typically all that is required is to set up a communication channel between the components to. 예를 들어, 상술한 "be[1].SqlServer" 포트 인스턴스는 SQL 백엔드(backend)로 접속하기 위한 다음과 같은 바인딩 정보를 가질 수 있다. For example, the aforementioned "be [1] .SqlServer" port instance can have the following binding information for connecting to the SQL back end (backend).

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

이 문자열은 ADO 또는 OLEDB로 보내질 수 있고, TDS 접속이 백엔드 SQL 서버로 설정될 수 있다. This string can be sent to the ADO or OLEDB, the TDS can be set up as a back-end SQL server. SDM 런타임은 통신부(communicating parties)를 방해하지 않는다. SDM runtime does not interfere with the communication (communicating parties). 이는 단지, 통신을 시작하도록 요구된 임의의 정보의 보유부(holder)로서 동작한다. This only, and operates as a holding part (holder) of any of the information required to start communication.

포트 가시성 및 와이어 인스턴스(Port visibility and wire instance) Fort Visibility and wire instances (Port visibility and wire instance)

컴포넌트 인스턴스 상의 포트 인스턴스는, 동일한 와이어 인스턴스에 부착되어 있다면 다른 컴포넌트 인스턴스로만 볼 수 있다. Port instance on the component instance, if it is attached to the same wire instance can be seen only other component instances. 이는 서비스를 위한 논리적인 네트워크 토폴로지를 구축하기 위한 상당히 강력한 메커니즘이다. This is a very powerful mechanism to build a logical network topology for services. SDM 런타임은 또한, 와이어 인스턴스 제약을 구현하기 위하여 필요한 물리적인 가상 네트워크를 생성하고 패킷 필터링을 사용하기 위한 수단을 지원한다. SDM runtime will also generate a physical virtual network that are necessary to implement the wire instance constraint, and support the means for using the packet filter. 자세한 정보는 "네트워킹 아키텍처(Networking Architecture)"를 참고하라. Do refer to "Networking Architecture (Networking Architecture)" for more information.

이벤트(Events) Events (Events)

SDM 런타임은 SDM 인스턴스 스페이스 상의 동작의 결과로서 어떤 고유의 이벤트(intrinsic events)를 발생시킨다. Thereby SDM runtime trigger an event (intrinsic events) for some unique as a result of the operation on the SDM instance space. 예를 들어, 컴포넌트 인스턴스가 포트 인스턴스를 생성하면 이벤트가 발생한다. For example, an event occurs if the component instantiation port instance. 지정된 이벤트에 따라서, 목적지(destination)는 주어진 와이어 상의 포트 인스턴스 또는 합성 컴포넌트 인스턴스이다. Therefore, the specified event, the destination (destination) port is an instance, or synthetic component instances on a given wire.

모든 이벤트는 런타임 포트 상의 컴포넌트 인스턴스로 전달된다. All events are passed to the runtime component instances on the port. SDM 런타임 라이브러리는 이러한 이벤트를 트랩핑(trapping)하고 이들을 언어-특정 호출(language-specific call)로 번역하는 책임을 진다. SDM runtime library trapping (trapping) of these events and these languages ​​- is responsible for translating a specific call (language-specific call). 예를 들어, CLR-기반 SDM 런타임 라이브러리는 CLR 이벤트를 발생시킨다. For example, CLR- based SDM runtime library generates a CLR event.

컴포넌트 인스턴스 이벤트(Component instance events) Component instance event (Component instance events)

이 이벤트들은, 컴포넌트 인스턴스가 생성되거나 존재하는 컴포넌트 인스턴스가 삭제될 때에 발생한다. This event will be generated when deleting a component instance that the component instantiation or presence. 이벤트의 목적지는 언제나 부모 합성 컴포넌트 인스턴스(parent compound component instance)이다. The destination of the event is always the parent composite component instance (parent compound component instance). 이벤트는 바로 위의 부모 컴포넌트 인스턴스로만 전송된다 - 이벤트들은 인스턴스 트리를 퍼지게 하지 않는다. Events are sent directly only to the parent component instance above-events do not spread the instance tree. 상술한 예로부터, 컴포넌트 인스턴스 "u[1].foo[2]"는 런타임이 멤버 컴포넌트 "c"의 새로운 인스턴스를 생성하도록 요청한다고 가정한다. From the above-described example, a component instance "u [1] .foo [2]" is assumed that the request to create a new instance of a "c" run-time component of this member. 도 36을 참고하라. Refer to Figure 36.

컴포넌트 인스턴스 "u[1].foo[2]"의 코드는 현재 기계 1에서 실행중이다. Component instance "u [1] .foo [2]" the code is currently running on one machine. SDM RTL을 사용하여, 이는 런타임에게 컴포넌트 "c"의 새로운 인스턴스를 생성할 것을 요청한다. Using the SDM RTL, which is requested to create a new instance of the component "c" to run. 런타임은 호출하는 컴포넌트 인스턴스를 알고 있고, 동작을 명확하게 하고(disambiguate) 살펴볼 수 있다(scope). Run time, and to know the component instances to call, it is possible to see clearly the operation, and (disambiguate) (scope). 새로운 컴포넌트 인스턴스가 생성되고, 이벤트가 발생하고 호출한 컴포넌트 인스턴스로 다시 전달된다. A new component instance is generated and the event is generated and passed back to the calling component instance. 인스턴스가 파괴되거나 실패하면, 런타임은 적절한 이벤트를 부모 컴포넌트 인스턴스 및 적절한 컴포넌트 팩토리로 전송한다. If the instance is destroyed or fails, the runtime sends the appropriate events to the parent component instance and the appropriate component factory.

포트 인스턴스 이벤트(Port instance events) Port instance events (events Port instance)

컴포넌트 인스턴스가 포트 인스턴스를 생성하고나 존재하는 포트 인스턴스를 삭제하면, 부모 컴포넌트 인스턴스는 그 변경을 알게 된다. If a component instance, delete the port instance to create a port or instance exists, the parent component instance is aware of the change. 도 37을 참고하라. Refer to Figure 37. 포트 인스턴스가 와이어 인스턴스에 부착되면, 와이어 인스턴스의 모든 멤버는 부모 컴포넌트 인스턴스뿐만 아니라 변경을 알게 된다. If the port instance attached to the wire instance, all members of the wire instance is aware of changes as well as the parent component instance. 이에 대해서는 다음 섹션에서 설명한다. As will be described in the following sections.

포트 상태(Port states) Port status (Port states)

모든 포트 인스턴스는 다음의 상태 중 어느 하나일 수 있다. All ports instance, may be one of the following conditions:

* 생성(Created) - 이는 처음 생성되었을 때, 포트의 상태이다. * Generating (Created) - This is the state when the port is first generated. 이는 부모 컴포넌트 인스턴스로 전송된 이벤트를 트리거한다. This triggers the events that are sent to the parent component instance.

* 부착(Attached) - 포트가 와이어 인스턴스로 부착되면 포트는 이 상태가 된다. * Attachment (Attached) - If a port is attached to the wire instance port is in this state. 이는 와이어 인스턴스의 모든 멤버 및 부모 컴포넌트 인스턴스로 전송되는 이벤트를 트리거한다. This triggers an event that is sent to all members and parent component instance of the wire instance.

* 온라인(Online) - 포트가 동작을 위해 준비가 되면, 포트는 이 상태가 된 다. * Online (Online) - When the port is ready for operation, the port is in this state. 이는 와이어 인스턴스의 모든 멤버 및 부모 컴포넌트 인스턴스로 전송되는 이벤트를 트리거한다. This triggers an event that is sent to all members and parent component instance of the wire instance.

* 오프라인(Offline) - 포트가 일반적인 동작을 중단하고자 하면 포트는 이 상태가 된다. * Offline (Offline) - port if you want to interrupt the normal operation port is in this state. 이는 와이어 인스턴스의 모든 멤버 및 부모 컴포넌트 인스턴스로 전송되는 이벤트를 트리거한다. This triggers an event that is sent to all members and parent component instance of the wire instance.

* 분리(Detached) - 포트가 와이어 인스턴스로부터 분리되면 포트는 이 상태가 된다. * Remove (Detached) - If the port is separated from the wire instance port is in this state. 이는 와이어 인스턴스의 모든 멤버 및 부모 컴포넌트 인스턴스로 전송되는 이벤트를 트리거한다. This triggers an event that is sent to all members and parent component instance of the wire instance.

* 삭제(Deleted) - 포트가 인스턴스 스페이스로부터 제거되었을 때 포트는 이 상태가 된다. * Deletion (Deleted) - the port when the port is removed from the instance space is in this state. 이는 부모 컴포넌트 인스턴스로 전송되는 이벤트를 트리거한다. This triggers an event that is sent to the parent component instance.

와이어 인스턴스 이벤트(Wire instance events) Wire instance events (Wire instance events)

와이어 인스턴스 이벤트는, 와이어 인스턴스가 생성되거나 삭제될 때 발생한다. Wire instance events are generated when a wire instance is created or deleted. 이 이벤트들의 목적지는 언제나, 와이어를 갖는 부모 컴포넌트 인스턴스이다. Destinations of the event is always a parent component instance with a wire. 도 38을 참고하라. Refer to Figure 38.

와이어 인스턴스는 그 멤버로의 포트 참조(port references)를 포함할 수도 있다. Wire instance may include a reference port (port references) to its members. 이 와이어 멤버십(membership)은 일정한 멤버 포트 이벤트의 목적지를 결정한다. The wire membership (membership) will determine the destination of the regular member port events. 상술한 예제를 계속 검토한다. Continue reviewing the above example. "foo[2].c[2]"는 다음과 같은 다수의 새로운 인스턴스를 생성한다고 가정한다: "Foo [2] .c [2]" It is assumed that the following generate multiple new instances of:

component instance universal[1] universal component instance [1]

component instance foo[2] component instance foo [2]

component instance c[2] component instance c [2]

port instance y[1] port instance y [1]

component instance b1[1] component instance b1 [1]

port instance x[1] port instance x [1]

component instance b2[1] component b2 instance [1]

port instance x[1] port instance x [1]

wire instance p[1] wire instance p [1]

b1[1].x[1] b1 [1] .x [1]

b2[1].x[1] b2 [1] .x [1]

와이어 인스턴스 "p[1]"은 2개의 포트 인스턴스, "b[1].x[1]" 및 "b2[1].x[1]"로의 참조를 포함한다는 것을 유의하여야 한다. Wire instance "p [1]" to 2 It should be noted that the ports instance, include a reference to the "b [1] .x [1]" and "b2 [1] .x [1]". 컴포넌트 인스턴스 "b1[1]" 및 "b2[2]"은 각각 별도의 기계를 실행시킨다고 가정하다. Component instance "b1 [1]" and "b2 [2]" is the assumption that each running a separate machine. 도 39에, "b2[1]"이 그 포트 상태를 오프라인으로 바꾸었을 때 이벤트가 발생하는 것이 도시되어 있다. In Figure 39, it has been shown that the event occurs when "b2 [1]" is eoteul change the port state to offline.

"b2[1]"은 기계 3 상에 호스팅되고, 이는 런타임 상의 "포트 상태 설정(set port state)"를 발동시킨다는 것을 유의하여야 한다. "B2 [1]" is being hosted on the machine 3, it should be noted that sikindaneun trigger the "Port Status (set port state)" on the run-time. 런타임은 변경을 기록하고 3개의 상태를 전송한다 - 한 개는 와이어 인스턴스 소유자 "u[1].foo[2].c[2]"로 전송되고, 두 개는 와이어 포트 인스턴스 멤버, "b1[1].x[1]" 및 "b2[1].x[1]"로 전송된다. Run time, and record the changes, and sends the three states - one of which is transmitted to the wire instance owner "u [1] .foo [2] .c [2]", two-wire port is an instance member, "b1 [ 1] .x [1] "and" b2 [1] .x [1] is sent to the ".

이벤트 전달(Event Delivery) 및 큐들(Queues) Event Forwarding (Event Delivery) and queues (Queues)

런타임은 이벤트들을 순서대로 전달하는 것을 보장하지만, 소정의 와이어 인스턴스의 모든 멤버들 사이의 완전한 가상 공시상태(synchronism)를 보장하지는 않는다. The runtime ensures that the delivery of events in the order, but it does not ensure the complete disclosure virtual state (synchronism) between all members of a given wire instance. 즉, SDM 런타임은, 컴포넌트 인스턴스가 천천히 운영되거나 정지하더라도, 앞으로의 진행이 가능하도록 할 수 있다. In other words, the SDM runtime, even if the component instance operating or stopped slowly, it is possible to enable the progress of the future.

SDM 사건들은 각각의 컴포넌트 인스턴스에 대하여 큐된다. SDM events are queues for each component instance. 만일 이벤트가 대상의 큐들에 성공적으로 큐되면, 이벤트를 트리거한 동작은 성공으로 간주된다. If the event is successful, the queue in the queues on the target, the operation that triggered the event is considered to be a success. 큐들은 본래 원형이고, 만일 컴포넌트가 심하게 지체되거나 멈추면 순환 반복한다. Cues and original prototype, if the cycle repeats chumyeon component is severely retarded or stopped. 순환 반복함으로써 새로운 "순환 반복(wrap-around)" 이벤트가 생성될 것이다. By cyclically new "cyclic redundancy (wrap-around)" it is an event is generated. 이 사건은, 컴포넌트 인스턴스 자신뿐만 아니라 부모와 임의의 소유 팩토리들에게도 보내진다. This event is also sent to a component instance, as well as their parents and any owned factories.

런타임 분할 Runtime Split

다수의 클라이언트를 지원하기 위하여, 런타임은 분할될 수 있다. In order to support multiple clients, the runtime may be divided. SDM 인스턴스 스페이스의 엄격한 계층때문에, 이 문제는 아주 다루기가 쉽다. Because of the strict hierarchy of the SDM instance space, this problem is very easy to handle. SDM 런타임은 특정 배포에 걸친 많은 기계에서 호스트가 될 수 있다. SDM runtime can be a host for many machines over a specific deployment. 각 SDM 런타임 인스턴스는 인스턴스 스페이스의 일부를 추적하는 역할을 한다. Each SDM runtime instance is responsible for tracking some of the instance space. 컴포넌트 인스턴스들은 SDM 런타임 라이브러리를 사용하여 적절한 런타임과 통신한다. Component instance communicate with the appropriate runtime using the SDM runtime library. 도 40은 분할된 런타임과 몇몇의 클라이언트들을 도시한다. 40 shows the run time divided and some of the client.

기계(1)는 두개의 컴포넌트 인스턴스와 SDM 런타임 라이브러리를 포함한다. Machine 1 comprises a two component instances with SDM runtime library. 기계(2)는 단일 컴포넌트 예와 런타임 라이브러리를 포함한다. And (2) comprises a single component, for example, the run-time library. 기계(3)는 전용 SDM 런타임에 대해 호스트가 된다. (3) is the host for a dedicated SDM runtime. 기계(4)는 SDM 런타임과 컴포넌트 인스턴스를 가진다. (4) has a run-time and SDM a component instance. 기계(3, 4) 상의 두개의 SDM 런타임이 통신한다는 것을 또한 알아야 한다. Should also be appreciated that the two SDM runtime on the machine (3, 4) communication.

분할 Division

런타임은 SDM 내의 본래의 고유 계층에 영향을 줘서 자신을 분할한다. Runtime divides itself for being influenced in the original-specific layers in the SDM. 분할 행위는 SDM 유형과 인스턴스 스페이스의 부분들을 다른 동작 런타임 예들에 걸쳐 분산하는 것을 포함한다. Divides behavior includes distributed over the parts of the SDM instance space type and the other run-time operation examples. 분산은 비율화(scalability)를 위해 반드시 필요하다. Balancing is essential for the rate screen (scalability). 분산은 유형들과 예들에 대해 다르게 발생한다. Dispersion takes place differently for the type of the examples.

Figure 112004009477667-pat00001
유형과 멤버 스페이스: 소정의 런타임은, 통상적으로 이름 스페이스 내에 체계화되는 많은 유형 정의를 포함할 수 있다. Type and Space Members: given runtime and can include many types of commonly defined as being organized in a namespace. 각 런타임은 추적하는 예들에 의해 정의되는 멤버들과 유형들에 대해 알기만 하면 된다. Each run will only need to know about the members and types that are defined by the examples that track. 이들은 다중 런타임 상에 나타날 수 있다. They can appear on multiple runtime. 즉, 유형과 멤버 스페이스 내에 오버랩이 허용된다. In other words, the overlap is permitted in Type and member space.

Figure 112004009477667-pat00002
인스턴스 스페이스: 소정의 런타임은 인스턴스 스페이스의 일부분을 추적하기만 하면 된다. Instance Space: a predetermined run time is only required to track a portion of the instance space. 인스턴스 스페이스는 복합 컴포넌트 인스턴스 경계들 상에서 분할된다. Instance space is divided on the composite component instance boundaries. 인스턴스 스페이스 내의 오버랩은 허용되지 않는다. Instances of overlap in space is not allowed. 이것은 예에 의해 가장 잘 설명된다. This is best illustrated by an example. 다음의 컴포넌트 유형 정의를 보자. Consider the following definition of the component types.

componenttype B { componenttype B {

port X x; port X x;

} }

componenttype C { componenttype C {

port Y y; port Y y;

component B b1; component B b1;

component B b2; component B b2;

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

componenttype A { componenttype A {

port internal Z z; port internal Z z;

component C c; component C c;

wire W w { z; wire W w {z; cy} cy}

} }

componenttype universal u { componenttype universal u {

component A foo; A component foo;

component A bar; component A bar;

} }

이 정의는 세 컴포넌트 유형(A, B, C)를 포함한다. This definition includes the three component types (A, B, C). A는 루트 범용 컴포넌트(root universal component)의 멤버이다. A is a member of the root Universal component (root universal component). B와 C는 A의 멤버들이다. B and C are the members of the A. 도 41에 도시된 바와 같이, 멤버 스페이스를 그림으로 나타내었다. As it is shown in Figure 41, showing the members of the picture space. 복합 컴포넌트들을 나타내기 위해 상자들이 사용될 것이다. They will be used to represent a composite component box. 다른 복합 컴포넌트들이 아닌 복합 컴포넌트 멤버들이 컴포넌트 상자 안에서 설명된다. Composite components which are not members of other composite components are described in the component box. 이 예에서, 와이어 "w"은 복합 컴포넌트 "foo"와 "bar"의 멤버이고, 따라서 "a" 상자 안에 나타낸다. In this example, the wire "w" is a member of a complex component "foo" and "bar", therefore represents in the "a" box.

인스턴스 스페이스에서, 각 컴포넌트, 포트 및 와이어의 많은 예들이 있다. In the instance space, there are many examples of each of the components, ports and wires. 인스턴스 계층이 도 42에 도시된다. Instance hierarchy is shown in Figure 42. 여기에서 상자는 컴포넌트 인스턴스에 대한 추적된 인스턴스 상태를 나타낸다. Here the box represents the instance state tracked for a component instance. 이것은 컴포넌트 인스턴스 구현 코드가 아니다. This is not an instance of the component implementation.

세개의 런타임, 런타임1, 런타임2 및 런타임3 사이에서 SDM 모델을 분할하기를 원한다고 가정하자. Let's suppose you want to divide the SDM model between three runtimes, runtime 1, 2 and runtime Runtime 3. 도 43은 예 스페이스를 분할하는 예시이다. Figure 43 is a diagram illustrating an example of dividing space. 이 예에서, 런타임1은 "범용[1]", "foo[1]", "foo[2]" 및 "bar[1]"을 추적한다. In this example, the runtime tracks the first "universal [1]", "foo [1]", "foo [2]" and "bar [1]". 런타임2는 "foo[1].c[1]", "foo[1].c[2]" 및 "foo[2].c[1]"을 추적한다. 2 is a run-time to track the "foo [1] .c [1]", "foo [1] .c [2]", and "foo [2] .c [1]". 런타임3은 "bar[1].c[1]"을 추적한다. 3 runtime tracks the "bar [1] .c [1]". 게다가, 런타임들은, 런타임이 추적하는 인스턴스들에 대한 모든 유형에 대해 알아야 한다. In addition, they run, you need to know about all types for instance that the runtime tracking. 이 예에서, 런타임3은 부모 "bar"에 의한 컴포넌트 유형 "C", "B" 및 "A"에 대해 알아야 한다. In this example, the run-time 3 It should be noted for the component type "C", "B" and "A" by the parents "bar". 또한, 포트 유형 "Y"와 와이어 "P"에 대해서도 알아야만 한다. In addition, the need to know about the port type "Y" and the wire "P".

다른 런타임들은 또한 그들의 관계를 보유하고 있어야만 한다. Other runtime are also must hold their relationship. 이 관계는 SDM 계층에 의해 요구된다. This relationship is required by the SDM layer. 전의 예에서, 런타임1과 런타임2은 "foo[1].c[1]", "foo[1].c[2]" 및 "foo[2].c[1]" 관계를 관리하기 위해 각각을 알아야만 한다. In the previous example, run 1 and run 2 "foo [1] .c [1]", "foo [1] .c [2]", and "foo [2] .c [first]" in order to manage the relationships You must know each. 유사하게, 런타임1과 런타임3은 "bar[1].c[1]"을 둘러싼 작업을 조정해야만 한다. Similarly, run 1 and run 3 must adjust the work around the "bar [1] .c [one]". 런타임2와 런타임3은 서로에 대해 알 필요가 없다는 것에 주목하자. Run 2 and run 3 Notice that you do not need to know about each other.

분할 방법 Split Method

런타임은 자기 분할을 위한 충분한 논리를 포함한다. Runtime includes sufficient logic for self-division. 특정 분할 방법은 수행, 용량 및 SDM 정의 제약들에 기초한다. Specific division method is based on the performance, capacity, and SDM-defined constraints. 이 분할은 동적이고 SDM 모델이 발달함에 따라 변화한다. This division is dynamic and changes as the SDM model development.

단일루트 런타임(Single-root Runtime) Single-root runtime (Single-root Runtime)

단일루트 컴포넌트 예의 모든 예들인 복합 컴포넌트 인스턴스들을 추적하는 런타임들은 단일루트 런타임들로 참조된다. Run-time to track the single root component cases, which are all cases composite component instances are referred to as the single root run. 위 예시에서, 런타임1 및 런타임3은 단일루트 런타임들이다. In the above example, the first run-time and run-time 3 are single root run. 런타임1은 "universal[1]"에서 시작하는 루트 인스턴스 트리를 가지고, 런타임3은 "bar[1].c[1]"에서 시작하는 루트 인스턴스 트리를 가진다. Run 1 has a root instance tree starting at "universal [1]", run 3 has a root instance tree starting at "bar [1] .c [1]".

다중루트 런타임(Multi-root Runtime) Multi-root runtime (Multi-root Runtime)

루트 복합 컴포넌트 예를 갖지 않는 복합 인스턴스들을 추적하는 런타임들은 다중루트 런타임들로 참조된다. Run-time to track the composite instance does not have a root complex component examples of which are referred to as the multiple root run. 위 예시에서, 런타임2은 모두 루트들인 "foo[1].c[1]", "foo[1].c[2]" 및 "foo[2].c[1]"을 추적하기 때문에 다중루트 런타임이다. In the above example, the second run-time are all multi because it keeps track of the root, which are "foo [1] .c [1]", "foo [1] .c [2]", and "foo [2] .c [1]" the root runtime.

서비스 설치 Installation Services

소정의 SDM 런타임 상에서 서비스가 설명되기 전에, SDM 런타임이 먼저 설치되어야 한다. Before service is described on the predetermined run-time SDM, the SDM runtime to be installed first. 설치 과정은 다음 단계들을 포함한다. The installation process includes the following steps:

서비스 배포 유닛을 런타임 배포 할당(runtime deployment share)으로 복사하는 단계 Copying the service deployment unit to allocate run-time distribution (runtime deployment share)

SDM 런타임 API를 호출하여 설치를 시작하는 단계 Step by calling the SDM Runtime API to start the installation

서비스 배포 유닛들 The service deployment unit

SDU는 서비스 배포 유닛이다. SDU is a service deployment unit. 이는, this is,

SDM 어셈블리 - 새로운 서비스에 대한 유형 정보이다. SDM assembly - a type information about the new service. 이 서비스에 대한 모든 컴포넌트 유형, 와이어 유형들 및 포트 유형들을 포함한다. Including all component types, wire types and port type for the service. 이 어셈블리는 SDML 서비스를 컴파일한 결과이다. This assembly is the result of compiling SDML services.

런타임-호스트 컴포넌트 인스턴스 코드(Runtime-hosted component instance code) - 런타임에 의해 호스트되고 SDML 내의 구현 키워드에 의해 참조되는 임의의 CLR 코드는 SDU에 포함되어야 한다. Run-time-host component instance code (Runtime-hosted component instance code) - and the host by any of the runtime CLR code referenced by the implementation of a keyword in the SDML is to be included in the SDU.

다른 서비스 바이너리들(binaries) - 구성 파일들, DLL, GIF, HTML, SQL 스크립트 등과 같은 모든 다른 바이너리들이 배포 유닛의 일부로 또한 간주된다. Other services binaries (binaries) - All other binaries such as configuration files, DLL, GIF, HTML, SQL scripts are also considered part of the distribution unit.

로 구성된다. It consists of a.

SDU는 변경되지 않는다. SDU is not changed. SDU에 대한 변경은 허용되지 않는다. Changes to the SDU is not allowed. 일단 SDU가 설치되면, 변경될 수 없다. Once the SDU has been installed, it can not be changed. 물론, 업그레이드된 새로운 버전의 SDU를 설치할 수 있고, 예전 버전(들)을 사용하지 않을 수 있다. Of course, you can install the upgraded new version of the SDU can not use the old version (s).

SDU 형식 SDU format

SDU는 SDM 런타임에 의해 사용되는 바이너리들의 디렉토리이고 잠재적인 컴포넌트 팩토리들이다. SDU is a directory of the binaries used by the SDM runtime components are potential factories. 디렉토리는 형식상 큰 제약이 없으나 다음 구조가 기대된다. The directory format, but the greater the restrictions, the following structure is expected.

\sduroot \ Sduroot

\<assembly name>.<version> \ <Assembly name>. <Version>

\<assembly name>.sdmassembly \ <Assembly name> .sdmassembly

\bin \ Bin

\<Runtime hosted CLR assembly_1>.dll \ <Runtime hosted CLR assembly_1> .dll

\<Runtime hosted CLR assembly_2>.dll \ <Runtime hosted CLR assembly_2> .dll

\<Runtime hosted CLR assembly_n>.dll \ <Runtime hosted CLR assembly_n> .dll

\<other files and directories> \ <Other files and directories>

SDU는 CAB 파일로 포장된다. SDU is packaged in a CAB file.

구현 avatar

SDM 런타임은 IIL 서버 상에서 동작하는 .NET 웹서비스로서 구현된다. SDM runtime is implemented as a .NET web service running on the server IIL. SDM 저장은 신뢰성 있는 SQL 서버 데이터베이스이다. SDM is stored in a SQL Server database reliability. SDM 런타임 웹서비스는 비상태유지(stateless) 웹서비스이다. SDM runtime, web services maintain a stateless (stateless) is a web service. 즉, SDM 런타임 서비스 내의 임의의 상태는 일시적이다. In other words, any state in the SDM runtime service is temporary. 모든 영속적인 상태가 명확한 처리 경계들에 있는 기억장치에 기록된다. All the persistent state is written to the memory device in the processing of clear boundary.

SDM 런타임 서비스는 종료되고 임의의 지점, 서로 다른 기계들에서조차 재시작될 수 있다. SDM runtime service can be shut down and restarted even any point of different machines. 만일 SDM 런타임이 동일한 SDM 기억장치에서 지시되면, 모든 작업이 방해가 없거나 거의 없이 다시 시작될 수 있다. If SDM SDM runtime is directed in the same storage device, all operations can be restarted or interfere with little.

SDM 기억 SDM memory

SDM 런타임은 SDM들과 인스턴스들을 위해 영속적인 기억장치를 이용한다. SDM runtime uses the persistent storage for the instance of the SDM. 이 기억장치는, SDM 런타임 서비스와 같이 동일한 기계 상에 통상적으로 위치하지만, 확실히 다르게 배포될 수 있다. The storage device is typically located on the same machine as in the SDM runtime services, but can be distributed quite differently. SDM 기억장치는, 모든 SDM 모델들과 그들의 인스턴스들에 대한 정보를 포함하는 SQL 서버 데이터베이스이다. SDM memory is a SQL Server database containing information on all SDM models and their instances.

SDM 기억장치의 이러한 신뢰성과 가용성은 필수적이다. The reliability and availability of the SDM memory is essential. SDM을 위한 키 설계 목적들 중의 하나는, 마지막에 아는 일관된 상태(last know consistent state)에서 시스템을 재시작할 수 있는 능력이다. One of the key design goals for the SDM has the ability to restart the system in a consistent state of knowledge at the end (last know consistent state). SDM은, 따라서, 높은 신뢰성을 필요로 하고, 큰 재난 시나리오들에서 견뎌야만 한다. SDM will, therefore, require high reliability, and must withstand the catastrophic scenario. 이는 두가지 방법으로 구현된다. This is accomplished in two ways.

SDM 기억장치는 복제되고 여분의 핫 백업은 언제나 사용 가능하다. SDM memory is replicated and can always use an extra hot backup. 이는 유콘의 여분 데이터베이스 기술(Yukon's redundant database technology)을 사용하여 구현된다. This is accomplished by using an extra database technology (Yukon's redundant database technology) in the Yukon.

SDM 기억장치는 정기적으로 백업되고 사이트 밖에서 저장된다. SDM memory is regularly backed up and stored out of site. 백업은 현 모델들, 예들, 및 SDM 기억장치 내에 저장된 임의의 서비스 상태의 자기-일관 스냅샷(self-consistent snapshot)이다. Backup the current models, examples, and any of the self-service state stored in the SDM memory device - a consistent snapshot (self-consistent snapshot).

서비스 기억장치 Storage services

SDM 런타임은 컴포넌트 인스턴스 레벨에서 저장을 용이하게 한다. SDM runtime will facilitate storage component in the instance level. 모든 컴포넌트 인스턴스는 런타임 API를 사용하여 데이터를 SDM 기억장치에 저장한다. All component instances in the SDM memory device stores data using a run-time API. 반-구조 기억장치(semi-structure store)를 고려하더라도, 최소한 이 기억장치는 BLOB 기억장치이다. Semi-, even considering the structure of the storage device (semi-structure store), at least a storage device is a storage device BLOB.

런타임에 저장된 서비스 상태는 SDM 런타임만큼 신뢰성 있고 영속적인 것이 보장된다. Service state stored in the run time, it is ensured that the reliability by the SDM runtime and persistent. 서비스 상태는 또한 다른 런타임 상태와 일관성 있는 것이 보장된다. Service state is also guaranteed to run in different states and consistency. 서비스가 충분한 정보를 그들의 상태에 (지시자들의 측면에서) 저장하는 것을 기대하는 대신에, SDM 기억장치 내에 저장될 모든 서비스 상태에 대해 말하는 것은 물론 아니다. Instead of hoping that the service is stored (in terms of the directive) sufficient information on their status, it is of course not talking about all the services the state to be stored in the SDM memory. 복구되면, 서비스는 그 데이터의 지시자들을 검색하고 필요한 단계들을 수행할 수 있다. After the repair, the service can search for indicators of the data and perform the necessary steps. 아래의 복구를 보자. Consider the following recovery.

SDM 런타임 보안 SDM runtime security

시나리오 설명 Scenario Description

SDM 런타임을 위한 보안 모델을 정의할 두개의 기본 시나리오가 있다. SDM There are two basic scenarios to define a security model for runtime. 개발 자 테스트-런 시나리오와 오퍼레이터 생산 배포 시나리오이다. Developers test-run a scenario and operator production deployment scenario. 두 시나리오에 대한 공통적인 요구사항은 다음과 같다. Common requirement for both scenarios are as follows:

Figure 112004009477667-pat00003
SDM 런타임이 실행되고 있는 컴퓨터로부터 타겟 서버들로 접속할 수 있는 능력 Ability to connect to the target server from a computer that is running SDM runtime

Figure 112004009477667-pat00004
액티브 디렉토리(Active Directory) 도메인 계정들을 사용한 윈도우 인증 Active Directory using the Windows (Active Directory) domain account authentication

Figure 112004009477667-pat00005
설치, 업데이트 및 설치제거 동작들을 위해 타겟 서버 자원들에 접근하기 위한 신뢰 서브시스템 모델 Trusted subsystem model to access the server resources targeted for installation, update, and uninstall operations

Figure 112004009477667-pat00006
윈도우 서비스로 구현되고 신뢰 서비스 계정으로 동작되는 SDM 런타임 SDM runtime is implemented as a Windows service is operated by trusted service account

Figure 112004009477667-pat00007
SDM 클래스, 유형 및 인스턴스 정보를 추적하는 데이터베이스 역할, 및 윈도우 인증을 사용하도록 구성된 데이터베이스(MSDE) A database configured to use the SDM classes, database roles, which tracks the type and instance information, and Windows authentication (MSDE)

개발자 테스트 런 시나리오 Scenario developers test run

개발자는 테스트 환경에서 분산 애플리케이션을 하나 이상의 서버로 배포할 수 있어야 한다. Developers should be able to deploy a distributed application in a test environment with one or more servers. 대상 서버들은 단독 워크그룹의 일부이거나 동일한 액티브 디렉토리 도메인 내에 있다. The destination server may be part of a single work group within the same Active Directory domain. 테스트 런 배포가 초기화되는 컴퓨터는 타겟 서버(들)로써 동일한 워크그룹이나 도메인에 있어야만 한다. Test run the computer on which the deployment is initialized to be in the same workgroup or domain as the target server (s).

1. 개발자는 비쥬얼 스튜디오(Visual Studio)를 사용하여 서비스 배포 유닛(Service Deployment Unit; SDU)를 생성한다. 1. The developer service deployment unit by using Visual Studio (Visual Studio); and generates (Service Deployment Unit SDU).

2. 생성된 SDU는, SDM 런타임 서비스가 실행되는 컴퓨터 상의 배포 폴더 내에 위치한다. 2. The resulting SDU is located in the deployment folder on a computer that is running SDM runtime service.

3. 개발자는 배포 행동(설치, 업데이트, 설치제거)을 선택하고, 윈도우 인증 적격에 대해 상기한다. 3. Select the distribution developers actions (install, update and uninstall), and the eligibility for Windows Authentication.

4. 개발자는 인증을 받고, 인증받은 사용자가 요청된 배포 동작을 수행하도록 허가되는지를 결정하는 배포 역할에 매핑된다. 4. The developer is mapped to the deployment role in determining whether a permit under the certification, to perform the authorized user requests deployment operation.

5. 개발자는, 어느 컴포넌트들을 어느 타겟 서버들 상에서 설치, 업데이트 또는 삭제할지를 선택한다. 5. The developer selects how to install, update, or delete any of the components on which the target server.

6. SDM 런타임 서비스는 두 방법 중 하나로 선택된 타겟 서버들에 연결된다. 6. SDM runtime service is connected to the one selected target servers of two ways.
만일 SDM 런타임 서비스가 액티브 디렉토리에서 신뢰 서비스 계정으로써 동작하고 있다면, 타겟 서버들 상의 계정으로써 연결될 것이다. Ten thousand and one SDM runtime service if you are operating as a trusted service account in Active Directory, will be connected by an account on the target server. 그렇지 않으면, SDM 런타임 서비스는 인증된 사용자처럼 연결될 것이고, 이는 인격화가 가능하지 않다면 타겟 서버에서 추가적인 인증을 필요로 할 수 있다. Otherwise, SDM runtime service will connect as an authenticated user, which may require additional authentication from the target server is not possible, it personified.

오퍼레이터 생산 배포 시나리오 Operator production deployment scenarios

오퍼레이터는 데이터 센터 환경에서 분산된 애플리케이션을 하나 이상의 서버에 배포해야 한다. The operator must deploy distributed applications from the data center environment on one or more servers. 타겟 서버들은 액티브 디렉토리 도메인 또는 포레스트의 부분이어야 한다. The target server must be part of an Active Directory domain or forest. 테스트 런 배포가 초기화되는 컴퓨터는 타겟 서버(들)로써 동일한 도메인 또는 포레스트 내에 있어야 한다. Test run the computer on which the deployment is to initialize must be within the same domain or forest as the target server (s).

1. 애플리케이션 SDU는 SDM 런타임 서비스가 실행되는 컴퓨터 상의 배포 폴더 내에 위치한다. 1. Application SDU is located in the deployment folder on a computer that is running SDM runtime service.

2. 오퍼레이터는 배포 행동(설치, 업데이트, 설치제거)을 선택하고 도메인 적격에 대해 상기한다. 2. Select the distribution operator actions (install, update and uninstall) and the eligibility for the domain.

3. 오퍼레이터는 인증되고, 인증받은 사용자가 요청된 배포 동작을 수행하도 록 허가되는지를 결정하는 배포 역할에 매핑된다. 3. The operator is authenticated, is mapped to an authenticated user requests distribution operation in the distribution serve to determine if the lock grant undercoating performed.

4. 오퍼레이터는, 어느 컴포넌트들을 어느 타겟 서버들 상에서 설치, 업데이트 또는 삭제할지를 선택한다. 4. The operator selects whether to install, update, or delete any of the components on which the target server.

5. SDM 런타임 서비스는 신뢰 서비스 계정으로써 선택된 타겟 서버들에 연결되고 동작을 수행한다. 5. SDM runtime service to connect to the selected target server as a trusted service account, and perform the operation.

특징 설명 Features Description

행동 특정 Specific actions

SDM 런타임은 모든 SDM 클래스, 유형 및 인스턴스를 추적하는 것을 담당한다. The SDM runtime is responsible for tracking all SDM classes, types and instances. SDM 런타임은 분산된 애플리케이션을 배포하기 위한 목적으로 SDM 문서에서의 운영과 등록을 위해 SOAP 인터페이스 세트를 공개한다. SDM runtime exposes a SOAP interface set for the operation and registration in the SDM document for the purpose of deploying distributed applications.

SDM 런타임은 다음의 주요 컴포넌트들을 포함한다. SDM runtime includes the following key components of the.

Figure 112004009477667-pat00008
관련된 런타임 라이브러리를 구비한 웹 서비스, Associated Web service includes a runtime library,

Figure 112004009477667-pat00009
윈도우 서비스, Windows services,

Figure 112004009477667-pat00010
MSDE(또는 유콘)와 같은 데이터베이스. Databases such as MSDE (or the Yukon).

도 44는 SDM 런타임 컴포넌트들, 배포 도구 및 타겟 서버들 사이의 관계를 도시한다. Figure 44 shows the relationship between the SDM runtime components, the deployment tool and the target server. 도 44에서, 사용자는 배포 행동을 초기화하기 위해 배포 도구 UI 또는 명령-라인 인터페이스와 상호 작용한다. In Figure 44, the user deployment tool UI or a command to initiate a deployment action - and interaction with the line interface.

런타임 라이브러리는 웹 서비스에 의해 공개된 SOAP 인터페이스들의 세트를 제공한다. The run-time library provides a set of SOAP interfaces exposed by the Web service. 웹 서비스는 배포 행동을 수행하기 위해 윈도우 서비스가 검색하는 데이터베이스에 정보를 기입한다. The web service writes the information to a database that Windows Search service to perform a deployment action. 웹 서비스는 윈도우 인증을 사용하여 SDM 런타임 데이터베이스에 대해 사용자를 인증하고, 데이터베이스에 의해 정의된 역할들에 기초한 배포 행동들을 허가한다. Web services and authenticate the user to the SDM runtime database using Windows authentication, authorization and deployment of actions based on roles defined by the database.

생산 환경에서, 윈도우 서비스는 액티브 디렉토리 서비스 계정으로써 수행되고 타겟 서버들은 관리 목적으로 도메인 서비스 계정을 신뢰하도록 구성된다. In production environments, Windows services are performed by Active Directory service account target servers are configured to trust the domain service account for administrative purposes. 윈도우 서비스는, 서비스 계정의 인격화(사용자가 아님)를 사용하는 타겟 서버들과 원격에 있는 WMI를 사용한다. Windows services, use WMI on remote target servers and to use personalized (not the user) of the service account. 이러한 신뢰 서비스 모델은 더욱 축소 가능하고 사용자당 기반의 목적 서브 ACL들을 관리할 필요를 최소화한다. This trust services model is further reduced and can minimize the need to manage the per-user-based sub-objectives ACL. 오퍼레이터들은 배포 동작들을 실행하기 위하여 타겟 서버들 상에서 관리자들이 되지 않아도 된다. Operators need not have an administrator on the target server in order to execute the deployment operation.

테스트 런 환경에서, 윈도우 서비스는 액티브 디렉토리 서비스 계정 또는 액티브 데릭토리가 없는 비-특권 네트워크서비스 계정 중의 어느 하나로써 수행된다. In a test run environment, Windows Active Directory service or active service account is a non-Tory Derek is not - is performed by either the Network Service account privileges. 후자는 타겟 서버들 상에서 인증된 사용자 계정의 인격화를 요구한다. The latter requires the impersonation of an authorized user account on the target server.

UI 설명 Description UI

SDM 런타임 자체를 위한 UI는 없다. There is no UI for the SDM runtime itself. SDM 런타임은, 배포 도구 UI를 통하거나 명령-라인 도구들의 세트를 통해 야기될 수 있는 API들의 세트를 공개한다. SDM runtime, deployment tools through the UI or command exposes a set of API that can be caused by a set of line tools. 배포 도구 UI는 별도의 문서 내에서 특정된다. Deployment Tools UI is specified in a separate document.

보안 모델 Security Model

SDM 런타임을 위한 보안 모델은 타겟 서버들로 접근하는 고정된 신원을 사용하는 신뢰 서브시스템 모델이고, 이러한 고정 서버들로 분산 컴포넌트들이 배포된다. The security model for the SDM runtime is trusted subsystem model using a fixed identity to access to the target server, are distributed components are distributed to these fixed server. 인증된 사용자의 보안 컨텍스트는 이 모델에서 타겟 서버들까지 이르지 않는다. The security context of the authenticated user does not come from the model to the target server. 이 보안 모델의 기본적인 가정은 타겟 서버들이 SDM 런타임 서비스의 고정된 신원을 신뢰한다는 것으로, 따라서 타겟 서버들 상의 각각의 사용자들을 위한 관리권을 처리할 필요를 제거한다. The basic assumption of this security model eliminates that target server as a fixed identity to trust the SDM runtime service, hence the need to handle the management rights for each user on the target server. 도 45는 고정된 신원 신뢰 관계를 도시한다. Figure 45 shows a fixed identity trust relationship.

신뢰 서브시스템으로, 신뢰 도메인 계정 하에서 확실히 SDM 런타임 서비스를 구동하거나, 심지어 지역 비-특권 네트워크서비스 계정으로써 이를 구동할 수 있다. Trust subsystem, under a trusted domain account, make sure the drive SDM runtime service, or even a local non-privileged as it can drive the Network Service account. 이해의 요점은 임의의 배포 행동에 대한 인증은 역할-기반 허가를 사용하여 SDM 런타임에 의해 관리된다는 것과, SDM 런타임 서비스만이, 일단 사용자가 인증되고 요구된 배포 동작을 허용하는 역할에 매핑되면, 타겟 서버들 상에서 설치, 업데이트 및 설치제거 행동들이다. If those using the base license that is managed by the SDM runtime, SDM only the runtime services, once the user is authenticated and mapped on to allow the required deployment operations roles - Key points of interest are authenticated role for any deployment actions installed on the target server are updated and uninstall behavior.

인증 certification

인증은 사용자의 신원을, 사용자와 근원적인 보안 기반시설에만 알려진 적격 비밀(credential secrete)에 기초하여 입증하는 과정이다. Authentication is the process of proving the identity of the user based on the user and the underlying security infrastructure eligible secret known only (credential secrete). 분산형 애플리케이션 배포의 목적으로, 액티브 디렉토리 도메인 계정들 또는 지역 계정들을 통해 사용자는 윈도우 인증을 사용하여 인증된다. The purpose of the distributed application distributed via the Active Directory domain account or a local account, the user is authenticated using Windows authentication. 지역 계정들이 사용되면, 배포 컴퓨터 상의 지역 계정 이름들과 암호들은 타겟 서버들 상에서 동일해야만 한다. If local accounts are used, deployed on the local computer account name and password must be identical on the target server.

허가 permission

일단 사용자가 인증되면, 설치, 업데이트 또는 설치제거와 같은 배포 동작을 수행하기 위한 허가가, 인증된 사용자가 멤버인 데이터베이스 역할에 기초하여 승인된다. Once the user is authenticated and is authorized by the license for performing deployment operations, such as installing, updating, or uninstalling, based on the authenticated user is a member of a database role. 윈도우 사용자와 그룹 계정들은 SQL 서버 데이터베이스 역할의 멤버들이기 때문에, 기본적인 허가 순서는 다음과 같다. Since reading the Windows user and group accounts are members of the SQL Server database roles, the basic authorization procedure is as follows.

1. 웹 서비스는 윈도우 인증을 사용하여 사용자를 인증한다. 1. The Web service authenticates the user using Windows Authentication.

2. 웹 서비스는 인증된 사용자로써 데이터베이스에 연결된다. 2. Web services are connected to the database as the authenticated user.

3. 사용자는, 사용자 또는 그룹 계정 멤버쉽에 기초하여 데이터베이스 역할에 매핑된다. 3. The user is mapped to the database roles based on user or group account membership.

4. 웹 서비스는, SDM 런타임의 윈도우 서비스 컴포넌트에 의해 비동기적으로 판독될 수 있는 적절한 데이터베이스 테이블에 배포 행동 정보를 기입한다. 4. Web service writes the information to the appropriate deployment actions database table by the window of the SDM runtime service component can be read asynchronously.

운영 체제 기반 시설 밖에서 암호를 관리할 필요없고 사용자 단위로 타겟 서버들 상의 ACL들을 관리할 필요가 없다는 점에 주목하자. No need to manage passwords outside of the operating system infrastructure Notice that you do not have to manage the ACL on the target server on a per-user basis.

인격화(Impersonation) Personified (Impersonation)

인격화는 현재의 과정 소유자가 아닌 다른 계정의 보안 컨텍스트 내의 코드를 실행하는 능력이다. Personified is the ability to run code in a different account than the current security context of the process owner. 타겟 서버들로의 원격 연결들은 인격화를 작동시킨 상태에서 WMI를 사용하여 설정된다. Remote connection to the target server, are set by using the WMI, while it is running a personalized. 인격화는, 액티브 디렉토리가 존재할 때 신뢰 서비스 신원에 기초하고, 액티브 디렉토리가 사용 가능하지 않을 때(예를 들면, 테스트 런 환경) 인증된 사용자의 보안 컨텍스트에 기초한다. Personified, when the active directory exist based on trust service identity, and when the active directory is not available based on the (e. G., A test run environment) of the authenticated user's security context.

윈도우 서비스 Windows Service

SDM 런타임의 윈도우 서비스 컴포넌트는 타겟 서버들 상의 관리권과 함께 서비스 계정으로써 구동되어야 한다. Windows of the SDM runtime service component must be driven by service accounts with management rights on the target server. 타겟 서버들 상에 소프트웨어를 설치하고 IIS, SQL 및 등록을 위한 다양한 설정을 생성하는 요구 조건들이 있기 때문에, 관리권이 필요하다. Since installing the software onto the target server, and there are requirements to produce a variety of settings for IIS, SQL, and registration, it is necessary to control over.

액티브 디렉토리 도메인 계정이 없는 경우에, 윈도우 서비스는 타겟 서버들 상에서 관리 행동들을 수행하도록 허가된 사용자 계정을 인격화한다. If you do not have an Active Directory domain account, Windows services are personalized for the user account is authorized to perform administrative actions on the target server. 이 경우에 윈도우 서비스는 암호를 요구하지 않는 네트워크서비스 계정으로써 구동하고 지역 컴퓨터 상의 비-특권 사용자이다. In this case, the non-Windows service on the local computer by running the Network Service account does not require a password - a privileged user. 윈도우 서비스는 연결될 때 지역 컴퓨터 적격을 원격 컴퓨터에 제공한다. The Windows service provides a local computer to a remote computer when connected eligibility.

IIS IIS

SQL 서버 SQL Server

SQL 서버는 두개의 인증 모드를 운영할 수 있다. SQL Server can operate two authentication modes. 윈도우 인증 모드와 혼합 모드이다. The Windows authentication mode and mixed mode. 윈도우 인증 모드는 혼합 모드보다 안전하기 때문에, SDM 런타임 데이터베이스를 위한 SQL 서버는 윈도우 인증 모드만을 위해 구성된다. Windows Authentication mode is more secure than mixed mode because it is SQL Server for the SDM Runtime database is configured for Windows Authentication mode only. 이것은 sa 계정이 SDM 런타임 데이터베이스를 인증하는데 사용하지 못하도록 한다. This prevents you from using the sa account to authenticate the SDM runtime database. SDM 런타임 데이터베이스에 대한 관리 특권들은 액티브 디렉토리 인증 기반시설에 영향을 주기 위하여 윈도우 그룹 멤버쉽을 통해 제어된다. Administrative privileges on the SDM Runtime database are controlled through a Windows group membership to influence the Active Directory authentication infrastructure. SQL 서버를 관리하고 특정 사용자들을 그룹에 추가하기 위해 액티브 디렉토리 그룹을 사용함으로써, 특별한 계정 상의 암호들을 관리할 필요 없이 SDM 런타임 데이터베이스로의 접근을 제어하는 것이 보다 용이해진다. Manage SQL Server, and it becomes easier to control access to by using Active Directory group, without the need to manage passwords on a special account, the SDM runtime database to add a specific user groups.

SDM 런타임 데이터베이스에 부가하여, SQL 서버를 구동하는 타겟 서버들은 또한 윈도우 인증 모드를 사용하고 윈도우 그룹 멤버쉽을 통한 관리 접근을 처리한다. In addition to the SDM runtime database and target servers running SQL Server you can also use Windows Authentication mode and process management approach through the Windows group membership. SDM 런타임 데이터베이스를 위한 윈도우 그룹과 타겟 서버들을 위한 윈도우 그룹은 서로 다른 그룹들이어야 한다. SDM runtime for Windows Group window for the database server and the target group must be different groups. 고객이 SQL 서버 기계들을 관리하기 위해 하나 또는 몇몇의 윈도우 그룹을 가질지는 정책적 결정이다. Customers are policy decisions that have one or several Windows groups to manage the SQL Server machine.

예를 들면: For example:

SDM 런타임 관리자 그룹 SDM Runtime Administrator Group

사용자 A, 사용자 B User A, User B

SQL 서버 계층 1 관리자 그룹 SQL Server tier 1 administrator group

사용자 C, 사용자 D User C, user D

SQL 서버 계층 2 관리자 그룹 SQL Server Layer 2 Manager Group

사용자 C, 사용자 E User C, User E

SDM 서버 개요 SDM Server Overview

소개 Introduce

SDM 서버란 무엇인가 - SDM 서버는 SDM 주변을 바탕으로 하는 서비스들의 세트이다. What is SDM server application - SDM Server is a set of services based on the SDM around. 현재, 두개의 배포 도구의 아키텍쳐 상으로 접근하는 두가지 일반적인 방법이 있다. Currently, there are two common ways to approach the architecture of the two deployment tools. 각각이 여기서 설명된다. Each of which is described herein.

분산 접근 Distributed Approach

이 접근에서, SDM 런타임과 배포 엔진을 사용하는 도구들은, 웹 서비스를 사용하여 SDU(의 바이너리들)를 위치시키기 위한 파일 할당 및 SDM 런타임 엔진과 교대로 통신하는 런타임 OM 클라이언트 라이브러리에 대해 형성된다. In this approach, tools used by the SDM runtime and deployment engines, using web services is formed on a file allocation and runtime OM client library to communicate with the SDM runtime engine and shift to position the SDU (the binaries). SDM과 배포 엔진들은 배포 일들과 SDM 엔티티들의 데이터베이스를 공유한다. SDM and distribution engines share the distributed database of events and SDM entities. 배포 태스크들은 WMI와 SMB (파일 할당)을 사용하는 배포 엔진들에 의해 비동기적으로 수행되어 목적 기계들과 통신한다. Deployment tasks are are done asynchronously by the deployment engine that uses the WMI and SMB (file allocation) communicates with the purpose machine.

단순 접근 Simple Approach

이 접근에서 클라이언트, SDM 객체 모델 라이브러리, SDM 엔진, 및 설치자 플러그-인들 모두가 동일한 프로세스에서 구동하여 그러한 서비스가 없다. Clients in this approach, SDM object model libraries, SDM engine, and the installer plug-in that is driving everyone in the same process, there is no such service. 런타임 데이터베이스와 바이너리들은 다른 기계들에 있을 수 있다. And binary runtime database may be on different machines. WMI와 SMB의 목적 기계들로의 접속은 클라이언트나 UI가 구동되는 곳에서 직접 이루어진다. Access to the objectives of WMI and SMB machines are made directly from the place where the client or driven UI.

사용자 인터페이스 및 다른 클라이언트들 User interface and other clients

SDM 서버를 위한 사용자 인터페이스는 다음을 포함한다. The user interface for the SDM server include the following:

Figure 112004009477667-pat00011
애플리케이션의 테스트 인스턴스를 배포, 업데이트 또는 제거하는 간단한 방법을 제공하는 비쥬얼 스튜디오(Visual Studio) 내의 마법사. Wizard in Visual Studio (Visual Studio) to provide a simple way to deploy, update, or remove a test instance of the application.

Figure 112004009477667-pat00012
SDM, SDU 및 인스턴스 요구들을 로딩하는 명령 라인 도구들. SDM, the command-line tool to load the SDU and the instance requirements.

Figure 112004009477667-pat00013
객체 모델의 모든 기능을 나타내고 호스트 모델들과 인스턴스 요구들을 구성하기 위한 시각 도구들을 부가적으로 제공하는 완전한 UI. It represents the complete UI that provides all the features of the object model, the visual tools for configuring the host model and instances requiring additionally.

런타임 OM 라이브러리 Runtime OM Library

SDM 서버의 일반 인터페이스는 이 라이브러리를 통한다. General interface of the SDM server is through this library. 이는 관리되는 코드 객체 모델이고 이를 사용하여 다음을 할 수 있다. This is a managed code object model that you can use them to:

Figure 112004009477667-pat00014
런타임에서 SDM을 관리한다. The management at the SDM runtime. SDM을 런타임에 로딩할 수 있다. The SDM can be loaded at runtime. SDM은 강경하게 명명되어 변하지 않고 SDM으로 하나씩 로딩된다(즉, 각각의 유형들, 클래스들 또는 매핑들이 아니라 SDM 파일을 로딩한다). SDM is unchanged and is tough named Single loaded SDM (i.e., as to each of the types, classes or mappings loads the SDM file). SDM을 런타임으로부터 제거하고 런타임에서 SDM을 위한 XML 문서를 생성할 수 있다. Remove from the SDM runtime and can generate XML documents for the SDM in the runtime. SDM은, 런타임 내의 다른 SDM으로부터 또는 인스턴스들로부터 이에 대한 참조가 있는 한, 런타임으로부터 삭제될 수 없다. The SDM, which with this reference from the instance, or from any other in the SDM runtime and can not be deleted from the runtime.

Figure 112004009477667-pat00015
런타임에 의해 알려진 SDU를 관리한다. It manages the SDU known by the runtime.

Figure 112004009477667-pat00016
(런타임에서 로딩된 SDM으로부터) SDM 요소들을 찾아내고 반사한다. It reflects find the SDM elements (from an SDM loaded in the runtime). 새로운 SDM을 생성하기 위해 제공되는 API는 없다(즉, 이는 SDM의 불변 요소들에 대한 판독 전용 객체 모델이다). API is not available to create a new SDM (i.e., this is a read only object model for the constant component of the SDM). 이는, SDM, SDU, 신원, 버전, 클래스, 유형, 바인딩/매핑 및 버전 정책을 포함한다. This includes the SDM, SDU, identity, version, class, type, binding / mapping and policy version.

Figure 112004009477667-pat00017
컴포넌트, 포트, 와이어 및 물리 위치(인스턴스 스페이스에서 호스트 관계)의 인스턴스들을 찾아내고 반사한다. It reflects find instances of a component, port and wire and physical location (host relationship at the instance space). 인스