KR20040079337A - 분산형 컴퓨팅 시스템을 위한 아키텍처 및 분산형애플리케이션들의 자동화된 설계, 배포와 관리 - Google Patents

Abstract

설계 도구는 분산형 컴퓨팅 시스템 및 분산형 애플리케이션의 추상화 기술을 가능하게 하는 서비스 정의 모델을 포함한다. 설계 도구는 또한 서비스 정의 모델 내에서 어떻게 기능적 동작들이 지정되어야 하는지를 지시하기 위한 스키마를 포함한다. 기능적 동작은 분산형 애플리케이션의 설계, 분산형 애플리케이션의 배포, 분산형 애플리케이션의 관리를 포함한다.

Description

분산형 컴퓨팅 시스템을 위한 아키텍처 및 분산형 애플리케이션들의 자동화된 설계, 배포와 관리{ARCHITECTURE FOR DISTRIBUTED COMPUTING SYSTEM AND AUTOMATED DESIGN, DEPLOYMENT, AND MANAGEMENT OF DISTRIBUTED APPLICATIONS}

관련 출원

본 출원은, 2003년 3월 6일자로 출원되어 여기서 일부로서 참조되는 미국 가출원 제60/452,736호의 이익을 주장한다.

또한, 본 출원은 (여기서 일부로서 참조되는) 다음의 미국 특허 출원들에 관계된다:

2003년 3월 6일 출원된, 발명의 명칭이 "Virtual Network Topology Generation"인 미국 특허 출원 제10/382,942호;

2000년 10월 24일 출원된, 발명의 명칭이 "System and Method for Distributed Management of Shared Computers"인 미국 특허 출원 제09/695,812호;

2000년 10월 24일 출원된, 발명의 명칭이 "System and Method for Logical Modeling of Distributed Computer Systems"인 미국 특허 출원 제09/695,813호;

2000년 10월 24일 출원된, 발명의 명칭이 "System and Method for Restricting Data Transfers and Managing Software Components of Distributed Computers"인 미국 특허 출원 제09/695,820호;

2000년 10월 24일 출원된, 발명의 명칭이 "Using Packet Filters and Network Virtualization to Restrict Network Communications"인 미국 특허 출원 제09/695,821호;

2000년 10월 24일 출원된, 발명의 명칭이 "System and Method for Designing a Logical Model of Distributed Computer Systems and Deploying PhysicalResources According to the Logical Model"인 미국 특허 출원 제09/696,707호; 및

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

본 발명은 분산형 컴퓨팅 시스템을 위한 아키텍처 및 그 분산형 컴퓨팅 시스템 상의 분산형 애플리케이션의 자동화된 설계, 배포와 관리에 관한 것이다.

인터넷 사용은 지난 수년 동안 폭발적으로 증가하였으며, 계속 증가하고 있다. 사람들은 전자 메일, 온라인 쇼핑, 뉴스 및 정보의 수집, 음악의 청취, 비디오 클립의 감상, 구직 등과 같은 월드 와이드 웹(World Wide Web, 단순히 "Web") 상에서 제공되는 다양한 서비스들에 매우 만족하게 되었다. 인터넷-기반 서비스들의 성장 수요와 보조를 맞추기 위해서, 호스팅 웹사이트들을 위한 백엔드 서비스(backend service)를 제공하고 그 사이트와 관련된 데이터를 저장하는, 호스팅 웹사이트용 컴퓨터 시스템들에서 대단한 성장이 있어 왔다.

분산형 컴퓨터 시스템의 일 유형은 인터넷 데이터 센터(Internet data center; IDC)인데, IDC는 인터넷-기반 서비스들을 호스팅하기 위한 다수의 컴퓨터들에게 장소를 제공하는 특별히 설계된 복합체(complex)이다. "웹농장(Webfarms)" 및 "서버 농장(server farms)"이라는 이름으로도 통하는 IDC들은 일반적으로 수백에서 수천개의 컴퓨터들에게 기후가 제어되고 물리적으로 안전한 건물내에 장소를 제공한다. 이들 컴퓨터들은 상호 연결되어, 하나 이상의 인터넷 서비스 또는 웹사이트를 지원하는 하나 이상의 프로그램을 실행시킨다. IDC들은 신뢰할 수 있는 인터넷 액세스, 신뢰할 수 있는 전원, 및 안전한 운영 환경을 제공한다.

도 1은 인터넷 데이터 센터(100)를 도시한다. 그것은 특별하게 구성된 스페이스에 배열된 다수의 서버 컴퓨터들(102)을 가진다. 컴퓨터들은 범용 컴퓨터이며, 일반적으로 서버들로서 구성된다. 인터넷 데이터 센터는 하나의 엔티티를 위한 하나의 사이트에 장소를 제공하도록(예를 들어, Yahoo! 또는 MSN을 위한 데이터 센터) 또는 다수의 엔티티들을 위한 다수의 사이트들을 수용하도록(예를 들어, 다수의 회사들을 위한 사이트들을 호스트하는 Exodus 센터) 구성될 수 있다.

IDC(100)는 컴퓨터 자원을 공유하는 3개의 엔티티들 -엔티티 A, 엔티티 B, 엔티티 C-을 가진 것으로 예시되고 있다. 이들 엔티티는 Web 상에 존재하기를 희망하는 다수의 회사들을 나타낸다. IDC(100)는 격심한 트래픽(heavy traffic)의 상황에서 엔티티들에 의해 사용될 수 있는 추가적인 컴퓨터들(104)을 가지고 있다. 예를 들어, 온라인 소매에 종사하는 엔티티는 크리스마스 시즌 동안 훨씬 더 많은 수요를 경험할 수 있다. 추가적인 컴퓨터는 IDC에게 이러한 수요를 충족시킬 수 있는 유연성을 제공한다.

오늘날, 큰 IDC들은 복합체이며, 종종 다수의 애플리케이션들을 호스트하도록 요청된다. 예를 들어, 일부 웹사이트들은 수천개의 컴퓨터들을 운영할 수 있고, 많은 분산형 애플리케이션들을 호스트할 수 있다. 이들 분산형 애플리케이션은 종종 복잡한 애플리케이션들을 지원할 수 있도록 오퍼레이터가 IDC 내에 와이어링 구성을 수동적으로 배열할 뿐 아니라 어떤 네트워크 스위치들에 연결하도록 요청하는 필수품들(requirements)과 네트워크로 접속된 복합체를 가진다. 그 결과, 애플리케이션 요청들에 따르기 위해 물리적 네트워크 토폴로지를 세우는 이 작업은 사람들의 오류를 일으키기 쉬운 성가시고, 시간 소모적인 프로세스일 수 있다. 따라서, 물리적 컴퓨팅 시스템 상에 분산형 애플리케이션을 설계하고 배포하기 위한 개량된 기술에 대한 필요가 존재한다.

도 1은 인터넷 데이터 센터의 일예를 나타내는 도면.

도 2는 서비스의 일예를 나타내는 도면.

도 3 내지 8은 계층 추상화(layer abstractions)의 예를 나타내는 도면.

도 9 내지 10은 SDM 형 스페이스(SDM type space)의 일예를 나타내는 도면.

도 11 내지 15는 계층 추상화의 예를 나타내는 도면.

도 16은 프로세스의 예를 나타내는 도면.

도 17 내지 19는 여기서 논의되는 컴포넌트들의 예를 나타내는 도면.

도 20 내지 21은 그래픽 사용자 인터페이스(graphical user interface)의 일예를 나타내는 도면.

도 22는 SDM 모델의 일예를 나타내는 도면.

도 23은 배포의 일예를 나타내는 도면.

도 24는 유형들의 예를 나타내는 도면.

도 25는 인스턴스 요청들(instance requests)의 예를 나타내는 도면.

도 26은 제약의 유효성 재검증(revalidation of constraints)의 예를 나타내는 도면.

도 27은 SDM 런타임(SDM runtime)의 논리 아키텍처의 일예를 나타내는 도면.

도 28은 서비스의 그래픽 표현의 일예를 나타내는 도면.

도 29는 인스턴스 스페이스의 일예를 나타내는 도면.

도 30은 데이터를 SDU로 포장하는 일예를 나타내는 도면.

도 31은 유형 스페이스, 멤버 스페이스, 및 인스턴스 스페이스의 일예를 나타내는 도면.

도 32는 멤버 트리의 일예를 나타내는 도면.

도 33은 인스턴스 트리의 일예를 나타내는 도면.

도 34는 여기서 설명되는 시스템을 구현한 일예를 나타내는 도면.

도 35는 컴포넌트 인스턴스(component instances)의 생성을 추적하는 일예를 나타내는 도면.

도 36 내지 39는 컴포넌트 인스턴스 이벤트의 예를 나타내는 도면.

도 40은 분할된 런타임의 일예를 나타내는 도면.

도 41은 멤버 스페이스의 일예를 나타내는 도면.

도 42는 인스턴스 계층의 일예를 나타내는 도면.

도 43은 인스턴스 스페이스를 분할하는 일예를 나타내는 도면.

도 44는 다양한 컴포넌트들 간의 관계의 예를 나타내는 도면.

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

도 46 내지 47은 컴포넌트들의 배열의 일예를 나타내는 도면.

도 48은 플랫폼 아키텍처의 일예를 나타내는 도면.

도 49는 애플리케이션 배포를 위한 사용 흐름(usage flow)의 예를 나타내는 도면.

도 50은 애플리케이션 설정 및 호스트 설정의 예를 나타내는 도면.

도 51은 배포 도구에 대한 국면(phases)의 예를 나타내는 도면.

도 52는 데이터 센터 기술의 시각화의 일예를 나타내는 도면.

도 53 내지 54는 흐름도의 예를 나타내는 도면.

도 55는 SDU를 처리하는 일예를 나타내는 도면.

도 56 내지 58은 흐름도의 예를 나타내는 도면.

도 59는 모델 아키텍처의 일예를 나타내는 도면.

도 60은 관리의 계층들(layers of management)의 예를 나타내는 도면.

도 61은 시스템의 동작의 일예를 나타내는 도면.

도 62는 커넥터 배열의 일예를 나타내는 도면.

도 63 내지 67은 디바이스들의 물리적 구성의 일예를 나타내는 도면.

도 68은 요청 그래프(request graph)의 일예를 나타내는 도면.

도 69는 응답 그래프의 일예를 나타내는 도면.

도 70 내지 86은 본 발명이 사용될 수 있는 시나리오의 예를 나타내는 도면.

도 87은 서비스 플랫폼 아키텍처의 일예를 나타내는 도면.

도 88은 시스템에서의 컴포넌트들의 예를 나타내는 도면.

도 89는 여기서 설명된 시스템에 포함될 수 있는 제품들의 예를 나타내는 도면.

도 90은 다양한 자원 관리 컴포넌트들을 나타내는 도면.

도 91은 다수의 LAN들의 배열의 일예를 나타내는 도면.

도 92는 ADS 아키텍처의 일예를 나타내는 도면.

도 93은 ADS 원격 부트 및 이미징 시스템(ADS remote boot and imaging system)의 일예를 나타내는 도면.

도 94는 토폴로지 배열의 일예를 나타내는 도면.

도 95는 SDML의 일예를 나타내는 도면.

도 96은 SDU에서의 데이터 집합의 일예를 나타내는 도면.

도 97은 SDM 실행 시간 API들을 사용하는 동적 바인딩(dynamic binding)의 일예를 나타내는 도면.

도 98은 SDM 배열의 일예를 나타내는 도면.

도 99는 배포의 일예를 나타내는 도면.

도 100은 시스템 아키텍처의 일예를 나타내는 도면.

도 101은 다양한 배포 계층들의 일예를 나타내는 도면.

도 102는 동작 논리의 예를 나타내는 도면.

도 103 내지 105는 인터넷으로 인한 변화의 예를 나타내는 도면.

도 106은 애플리케이션 라이프사이클의 일예를 나타내는 도면.

도 107은 새로운 아키텍처의 이점의 예를 나타내는 도면.

도 108은 복잡한 시스템을 단순한 다이어그램으로 변화하는 일예를 나타내는 도면.

도 109는 서비스의 일예를 나타내는 도면.

도 110은 SQL 클러스터의 일예를 나타내는 도면.

도 111은 SDM 데이터 센터 모델의 일예를 나타내는 도면.

도 112는 설계 애플리케이션 외면(design application surface)의 일예를 나타내는 도면.

도 113은 데이터 센터에서의 SDM 서비스의 일예를 나타내는 도면.

도 114는 자원 관리자의 예를 나타내는 도면.

도 115는 자원 시각화의 일예를 나타내는 도면.

도 116은 프로그래밍 동작 논리의 예를 나타내는 도면.

도 117은 동작 논리와의 상호작용의 예를 나타내는 도면.

도 118 내지 119는 이질적 환경(heterogeneous environments)을 관리하는 일예를 나타내는 도면.

*도면의 주요부분에 대한 부호의 설명*

100 인터넷 데이터 센터

102 서버 컴퓨터

104 부가적 컴퓨터의 풀

분산형 컴퓨팅 시스템 상에 분산형 애플리케이션을 설계하고, 배포하며, 관리하기 위한 아키텍처 및 방법이 설명된다.

다음 개시는 대규모 애플리케이션 서비스와 함께 분산형 컴퓨팅 시스템을 설계하고 구현하기 위한 아키텍처에 어울리는 다수의 양상들을 설명한다. 그 개시는 서비스 정의 모델(service definition model; SDM) 및 SDM 런타임 환경에 대한 논의를 포함한다. 그 개시는 어떻게 데이터 센터 컴포넌트들을 모델링할 것인지, 어떻게 분산형 애플리케이션 기술을 모델링할 것인지, 및 모델링된 데이터 센터 상으로 모델링된 애플리케이션을 논리적으로 배포하고 설계 시에 이 논리적 배포를 확인하기 위한 기술들과 같은 설계 양상들을 더 포함한다. 그 개시는 물리적 데이터 센터에 애플리케이션 배포를 용이하게 하기 위해서 어떻게 물리적 자원들 상에 분산형 애플리케이션의 물리적 배포, 물리적 자원들을 사용하는 모델을 실증할 것인지와 같은 배포 양상들을 더 설명한다. 또한, 그 개시는 SDM을 사용하여 문맥적 관리 피드백(contextual management feedback), 추적, 및 운영 피드백을 사용하는 것을 포함하는 관리 양상도 언급한다. 그 개시는 물리적 자원을 가로질러 애플리케이션의 배포에 사용되며, 상기 관리 양상들을 지원하기 위한 다수의 자원 관리자들에 대해서 논의한다.

서비스 정의 모델(SDM)

서비스 정의 모델(SDM)은 애플리케이션 설계자가 추상적인 방법으로 데이터 센터 및 분산형 컴퓨터 애플리케이션을 설계하기 위한 문맥과 도구를 제공한다. 그 모델은 결국 물리적 컴퓨터 자원 및 소프트웨어에 의해 구현될 애플리케이션들의 기능 유닛들을 나타내는 요소들의 집합을 정의한다. 컴포넌트들에 의해 표현되는 기능 동작들을 어떻게 지정할 것인지를 지시하는 스키마는 모델 요소들과 관련되어 있다.

SDM 개괄

- 인터넷 시대(Internet Era)

지난 십년 동안, 우리는 인터넷이 컴퓨팅 플랫폼으로서 판명되는 것을 목격해 왔다. 더 많은 소프트웨어 회사들이 그 소프트웨어를 서비스 모델로서 채택하고 있다. 이들 서비스는 일반적으로 서버, 네트워크 장비 및 다른 전문 하드웨어를 포함하는 다수의 기계들을 운행시키는 다수의 컴포넌트들로 이루어진다. 느슨하게 연결된 비동기 프로그래밍 모델(loosely coupled, asynchronous programming models)은 표준이 되어 가고 있다. 계량성(scalability), 유용성(availability), 및 신뢰성은 이들 분산형 서비스의 성공에 중요하다.

우리는 또한 하드웨어 유행에서의 변화를 목격하고 있다. 고밀도 서버들 및 전문 네트워크 하드웨어는 데이터 센터에서 널리 보급되어 있다. 스위치형구조물(switched fabrics)이 시스템 버스를 대신하여 시스템 구성에 보다 큰 유연성을 제공하고 있다. 이제, 하드웨어 비용은 전용 운영 직원을 교육하고 관리하는 비용에 비하면 소유권의 총 비용(Total Cost of Ownership; TCO) 측정 기준에서 작은 역할만 할 뿐이다. 바위처럼 단단한 운영 실행(rock-solid operational practices)은 임의의 고 유용성 서비스에 극히 중요하지만, 수동적인 프로시저들을 실행하는 사람들로 인하여 오류를 범하기 쉽기 때문에 이들 실행을 지속적으로 반복하기는 어렵다. 서비스 시대로서 신흥 소프트웨어에서, 개발의 초점은 데스크탑에서 서버로 옮겨가고 있다. 이러한 초점의 변화와 함께, 소프트웨어 개발자, 하드웨어 벤더, 및 IT 전문가들에게 다음과 같은 새로운 문제들이 대두되고 있다:

- 서비스들이 보다 크고 보다 복잡하다 - 서비스들이 개발하기에 시간-소모적이고, 유지하기 어렵고 비싸며, 추가적인 기능을 확장하기 위험하다.

- 서비스들이 획일적이 되기 쉽다 - 서비스들이 습관이 된 컴포넌트들 및 특정 구성에 의존하기 쉽다. 많은 서비스들 중 일부분이 서비스의 유용성에 영향을 주지 않고 제거되거나, 독립적으로 개선되거나, 또는 대체물로 교체될 수 없다.

- 서비스들이 특정 하드웨어 구성에 의존한다 - 특정 네트워크 토폴로지 또는 특정 네트워크 장치에 대한 의존성이 있는지, 하드웨어와 소프트웨어 간의 바인딩은 다양한 데이터 센터에서 서비스를 호스트할 수 있는 능력을 상당히 감소시킨다.

- 서비스들이 운영적인 일관성을 요구한다 - 대부분의 서비스들은 동작을 위해 운영 직원을 필요로 한다. 일반적인 플랫폼의 부족은 서비스들을 가로질러 코드를 재사용하고 운영상의 최상의 실시를 제정할 수 있는 능력을 감소시킨다. 불행하게도, 운영 직원은 각 서비스의 특징들을 훈련받아야 하고, 각 서비스가 발전될 때 다시 훈련받아야 한다.

"서비스"와 "애플리케이션"이라는 용어들은 본 명세서에서 호환할 수 있는 의미로 사용된다. 일반적으로, 애플리케이션은 분산형 서비스들의 집합으로 간주될 수 있다. 예를 들어, Hotmail은 각 서비스가 다른 기능을 수행하는 다양한 서비스들로 구성된 애플리케이션일 수있다.

이들 문제는 데스크탑 과 DOS 시대(약 1980년대경)의 문제들과 다른 것 같지 않다. DOS는 디스크 관리, 파일 시스템, 콘솔 기능(console facilities) 등과 같은 애플리케이션 개발자들을 위한 매우 유용한 코어 서비스들을 정의하였다. 그러나, DOS는 많은 복잡한 작업들을 ISV들에게 남겨 놓았다. 일 예로서, WordPerfect와 Lotus 123은 프린트 기능을 지원하기 위해 각 애플리케이션들 내에 모두 독립적으로 프린터 드라이버를 기록해야만 했다. 유사하게, 프린터 하드웨어 벤더들은 성공적인 제품을 가지기 위하여 소프트웨어 회사들과 거래해야만 했다. ISV들과 하드웨어 벤드들에 대한 가입에 대한 장벽은 이례적으로 높았다. 이것은 그 시대 동안 단지 소수의 소프트웨어 및 하드웨어 회사들만이 성공할 수 있는 결과를 초래하였다.

Microsoft는 Windows 플랫폼을 생성하는 데 있어서 이 문제를 처리하여, 가입에 대한 장벽을 극적으로 감소시켰다. Windows는 PC 플랫폼 상의 대부분의 하드웨어 장치에 대하여 추상화 계층(abstraction layer)을 정의하였다. 이것은 ISV들이 특정 하드웨어 장치들을 지원하기 위하여 걱정해야만 하는 것을 덜어 주었다. Windows는 메모리, 디스크 및 네트워크를 포함하는 PC 내부의 모든 자원을 관리하였다. 또한, Windows는 ISV들에 의해 사용될 수 있는 수많은 추가적인 서비스들을 부가하였다. 이 플랫폼은 당 산업계에서 커다란 성장을 유발하였다. Windows 플랫폼을 타겟으로 한 ISV들은 지극히 생산적이었다. 많은 새로운 하드웨어 벤더들이 공통 플랫폼, Windows를 가지는 유용한 효과에 기인한 보다 저렴한 하드웨어를 제공하면서 생겨났다.

서비스 정의 모델(SDM)

SDM 원리

SDM은:

- 분산형 애플리케이션들/서비스들을 설계하는 것을 보다 쉽게 하는 추상화를 정의한다.

- 운영 실시의 자동화 및 재사용을 위한 프레임워크를 가능하게 한다.

- 분산형 애플리케이션 및 서비스들의 운영 및 배포를 단순화한다.

오늘날 서비스의 오퍼레이터 부근의 벽 상에서 복잡한 다이어그램으로서 흔히 보여지는 것을 캡쳐하는 것을 고려함으로써, SDM이 무엇인지를 이해하는 것이 더 쉬워질 수 있다. 이들 다이어그램에서, 박스는 일반적으로 서비스의 실행 요소를 나타내며, 박스들을 연결하는 선들은 서비스 요소들 간의 통신 경로를 나타낸다. 예를 들어, 다시 하나 이상의 중간-층(middle-tier) 또는 백-엔드 서비스들에 연결되는 일부 IIS 프론트-엔드 기계들에 연결된 로드 밸런서(load balancer)가 있다.

SDM에 대하여 생각하는 또다른 방법은 SDM은 분산형 애플리케이션/서비스의 동작에 대한 메타-모델(meta-model)과 컴퓨팅 환경에서 실행하는 애플리케이션/서비스의 "생생한" 청사진 모두라는 것이다. 가능한 소프트웨어 동작들을 포함하여, 선언적이고 스케일-불변의 방식으로, SDM은 컴퓨팅 환경에서 애플리케이션의 구조를 캡처한다. 하드웨어와 네트워크 자원 간의 바인딩을 포함하여 서비스의 토폴로지 및 소프트웨어 컴포넌트의 유효한 동작들을 선언적으로 기술하는 능력은 매우 강력하다.

유사한 것으로서, Microsoft의 Common Object Model(COM)을 살펴보자. COM은 컴포넌트들이 어떻게 패키지되고, 등록되고, 활성화되고, 발견되는지 등을 표준화하였다. COM은 라이프타임, 메모리 관리, 및 인터페이스 구현에 관한 엄격한 룰들을 명령한다. 이들 원형(primitives)은, 컴포넌트들이 블랙 박스로서 처리될 수 있도록 하기 때문에, 정보처리 상호운용(interoperability)에 필수적이다. COM은 이벤팅, 자동화 및 OLE와 같은 보다 정교한 서비스들을 위한 기초이다.

마찬가지로, SDM은 보다 정교한 특성을 만들기 위한 일부 기본 원형들을 정의하는 것을 필요로 한다. 이들 원형들은:

- 컴포넌트 - 구현, 배포 및 관리의 유닛

- 포트 - 관련 유형 및 유효한 동작들의 집합을 가지는 지정된 종단점

- 와이어 - 포트들간의 허용되는 통신 경로

- 계층 - 자원 관리 소유권 및 바인딩의 분리

- 맵핑 - 각 계층에서 컴포넌트, 포트 및 와이어 간의 바인딩

본 명세서의 나머지는 이들 원형들 각각을 보다 상세하게 설명할 것이다.

컴포넌트, 포트 및 와이어

본 명세서의 목적을 위하여, 컴포넌트, 포트 및 와이어를 사용하여 그려진 MyService라고 불리는 단순한 서비스의 그래픽적인 표현을 고려하는 것이 유용하다. 도 2을 참조하자. 다이어그램에서, 박스들은 컴포넌트들을 나타내고, 다이아몬드들은 포트들을 나타내며, 파선은 와이어들을 나타낸다.

- MyService는, MyFrontEnd와 MyBackEnd라는 컴포넌트들을 사용하기 때문에 복합 컴포넌트이다.

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

- MyFrontEnd는 2개의 포트, 즉 위임 포트와 catalog라고 라벨이 붙은 포트를 가진다.

- MyBackEnd는 data라고 라벨이 붙은 하나의 포트를 가진다.

- MyFrontEnd와 MyBackEnd 컴포넌트들은 catalog 포트와 data포트를 와이어를 통하여 묶는 잠재적인 통신 관계를 가진다.

컴포넌트

컴포넌트들은 구현, 배포 및 관리의 유닛들이다. 컴포넌트들의 예들은 Windows Server를 실행하는 전용 서버, IIS 가상 웹 사이트 또는 SQL 데이터베이스이다. 컴포넌트들은 일반적으로 기계 경계를 가지나, 단일 IIS 서버 상에서 호스팅되는 웹 서비스들에 의해 증명되어질 것이 요청되지는 않는다.

컴포넌트들은 포트들을 통하여 기능들을 공개하며, 와이들을 통하여 통신한다. 단순한 컴포넌트들은 단지 멤버들로서 포트들을 가질 수 있다. 다른 컴포넌트들을 사용하는 컴포넌트들은 복합 컴포넌트(compound component)라고 불리며, 다른 컴포넌트들에 덧붙여 포트들과 와이어들을 가질 수 있다.

복합 컴포넌트들은 합성을 통하여 생성되며, 그와 관련된 어떠한 구현도 가지지 않는다. 복합 컴포넌트 포트들은 내부 컴포넌트들로부터의 위임 포트들이다. 복합 컴포넌트들은 배열(collocation), 캡슐화(encapsulation) 및 재사용을 가능하게 하며, 따라서 애플리케이션/서비스 및 그 행동을 조직화하는 하나의 방법으로 생각될 수 있다.

컴포넌트의 단지 공용 포트들(public ports)만이 컴포넌트 외부에서 가시적이다. 복합 컴포넌트들은 캡슐화를 통하여 자신이 사용하는 컴포넌트들의 내부 구조를 숨긴채 외부 세계에는 단순 컴포넌트들(simple components)로 보인다. 사실, 양자에 의해 지원되는 행동들과 포트 유형들이 완전히 동일하기만 하다면, 단순 컴포넌트는 복합 컴포넌트로 교체될 수 있으며, 그 역도 가능하다.

포트

포트들은 행동들의 집합을 정의하는 지정된 종단점(named end-points)이다. 포트들은 관련 유형 및 역할을 가지며, 일반적으로 허용되는 동작들의 집합과 관련된다. 포트들의 예들은 허용되는 동작들의 집합을 가지는 SOAP 포트, HTTP 서버 포트 등이 있다. 포트들은 위임될 수 있는데, 이는 외부 컴포넌트가 내부 컴포넌트의 포트를 자신의 것인양 공개할 수 있다는 것을 의미한다. 포트들은 하나의 컴포넌트에 대한 공용 인터페이스(행동)를 형성한다. 포트들은 공용으로(가시적으로) 될 수 있는 컴포넌트의 유일한 멤버들이다.

와이어

와이어들은 포트들간의 허용되는 바인딩들이며, 포트들 (및 컴포넌트들) 간의 토폴로지적 관계를 나타낸다. 와이어들은 임의의 인스턴스 상호연결 토폴로지(instance interconnect topology)를 지정하지 않으며, 대신 인스턴스 상호연결 토폴로지를 위한 "잠재성(potentiality)"을 표현한다.

와이어들은 본질적으로 버스들이며, 하나 이상의 포트 멤버들을 포함할 수 있다. 와이어들은 포인트-투-포인트 관계로 오해되어서는 안 된다. 주어진 포트는 동일한 와이어 내에서 한번 이상 나타날 수 없다.

스키마(Schema)

애플리케이션/서비스를 설명하기 위해서는, SDM을 위한 표준 스키마를 가질 필요가 있다. SDM 스키마는 XSD 및 XML 문법을 이용하여 표현될 수 있어야 한다. SDM 스키마를 상세히 설명하는 것은 본 명세서의 범위를 벗어나는 것이지만, 본 명세서에서 이후에 설명할 주제를 위한 맥락으로서 간략한 설명을 하는 것이 필요하다. 이하는 SDM 스키마를 간략하게 나타낸 것이다.

<sdm>

<identityReference />

<portClasses/>

<wireClasses />

<componentClasses />

<hostRelations />

<portTypes />

<wireTypes />

<componentTypes />

</sdm>

SDM 스키마에 대한 더욱 상세한 정보를 얻고자 하면 http://big/에 있는 SDM 스키마 사양(specification)을 읽고 샘플 XSD 파일을 검토하도록 한다.

SDM 클래스

애플리케이션/서비스에서 모든 컴포넌트, 포트 및 와이어는 클래스의 사용을 통하여 생성되는 타입이다. 새로운 타입은 기존의 클래스들 및 타입들로부터 생성될 수 있다. 예컨대, 웹 서비스는 SQL 데이터베이스와 마찬가지로 클래스로서 모델링될 수 있다. SDM 클래스는 기본적으로 공통 특징에 대한 추상화이다. MyService 애플리케이션에서는, MyFrontEnd는 클래스 웹 서비스로부터 파생되는 새로운 타입이고, MyBackEnd는 클래스 SQL 데이터베이스로부터 파생되는 새로운 타입이다.

아래는 포트들, 와이어들 및 컴포넌트들에 대한 클래스 스키마의 일예이다.

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

<settingSchema>

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

</settingSchema>

</portClass>

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

<settingSchema>

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

</settingSchema>

<portClassesAllowed>

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

<portClassRef name="ClientDataAccess" />

</portClassesAllowed>

</wireClass>

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

<deploymentSchema>

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

</deploymentSchema>

<settingSchema>

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

</settingSchema>

<portClassesAllowed closed="true">

<portClassRef name="ServerDataAccess" />

</portClassesAllowed>

</componentClass>

componentClass 및 wireClass 스키마 각각은 허용되는 설정 스키마(settings schema), 배포 스키마(deployment schema) 및 포트 클래스들을 포함할 수 있다는 것에 주의하자. portClass는 포트 클래스가 허용되는 섹션을 갖지 않는다. 이들 스키마는 다음과 같이 정의된다:

- 설정 스키마는 설계시(design-time)에 확증(validate)될 수 있는 컴포넌트, 포트 및 와이어 상의 구성 파라미터(configuration parameter)들에 대한 XSD이다.

- 배포 스키마는 컴포넌트, 포트, 또는 와이어가 설치되려면 어느 설치 파라미터들이 설정될 필요가 있는지를 표현하는 XSD이다. 이 목록은 Fusion 또는 그 밖의 어떠한 설치자(installer) 기술에 대한 스키마일 수 있다.

- 포트 Classes Allowed는 컴포넌트 및 와이어가 선언(declare)된 포트 클래스를 참조함으로써 허용 가능한 포트를 선언하는 위치이다.

클래스 스키마에 대한 더욱 상세한 정보를 얻고자 하면 http://big에 있는 SDM 스키마 설계 사양을 참조하면 된다.

클래스 관계들

다른 컴포넌트들을 호스팅할 수 있는 컴포넌트, 포트 또는 와이어는 설치자 및 자신이 호스팅할 수 있는 컴포넌트 클래스를 식별하는 hostRelations 스키마를 사용하여 선언된다. hostRelations 요소는 컴포넌트들, 포트들 또는 와이어들 중 하나가 다른 것들에 대한 호스트로서 작동하고 있는 클래스들 간의 방향성 링크로 생각될 수 있다.

컴포넌트를 호스팅한다는 것은 컴포넌트의 코드에 대한 실행 환경을 제공하는 것을 의미한다. 예를 들어, 아래에 예로서 도시된 바와 같이 SQL은 클래스 Database에 대한 호스트일 수 있다.

<hostRelations>

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

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

</hostRelations>

SDM 유형들

SDM이 자원, 애플리케이션 및 인스턴스를 모델링하는 3가지 별개 스페이스들이 있다. 인스턴스 스페이스는 본 명세서에서 나중에 설명된다. 자원 스페이스는 그 스페이스에서 클래스들이 살아 있고, 클래스들이 애플리케이션들이 구성되는 재료가 되는 빌딩 블럭들인 곳이다. 애플리케이션 스페이스는 유형들이 존재하는 곳이다. 아래는 포트, 와이어 및 컴포넌트 유형들에 대한 XML의 일예이다.

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

<deployment />

<setttings />

</portType>

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

<deployment />

<settings>

<useSSL>false</useSSL>

</settings>

<portTypeRefs>

<portTypeRef name="UserDataServer"/>

<portTypeRef name="UserDataClient"/>

</portTypeRefs>

</wireType>

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

<deployment>

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

</deployment>

<settings>

<databaseName>UserData</databaseName>

</settings>

<ports>

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

</ports>

</componentType>

SDM 스키마에서 portType, wireType 및 componentType 각각은 설정 및 배포 값들을 가진다는 것에 주의해야 한다.

- 설정은 컴포넌트, 포트 및 와이어에 대한 구성값을 제공하는 설정 스키마에 대한 XML이고, 설계 시에 유효성이 검증될 수 있다.

- 배포는 컴포넌트, 포트, 또는 와이어가 제대로 설치하기 위해 설정될 필요가 있는 구성 파라미터의 값을 표현하는 배포 목록에 대한 XML이다.

유형들에 대한 더욱 상세한 정보를 얻고자 하면 http://big에 있는 SDM 스키마 설계 사양을 참조하면 된다.

복합 컴포넌트

애플리케이션 및 그것의 다른 컴포넌트들, 포트들 및 와이어들에 대한 토폴로지적인 관계를 정의하기 위해 복합 컴포넌트들이 사용될 수 있다. 복합 컴포넌트들은 관련 구현을 갖지 않으며, 대신에 포트들의 위임 및 호스트 관계들을 사용하여 포트들과 멤버 컴포넌트들의 행동을 드러낸다. 아래의 XML은 복합 컴포넌트 MyService가 SDM을 사용하여 어떻게 기술될 수 있는지를 도시한다.

<compoundComponentType name="MyService">

<components>

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

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

  </components>

<wires>

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

<members>

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

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

  </members>

  </wire>

  </wires>

</compoundComponentType>

인스턴스

컴포넌트, 포트 및 와이어는 애플리케이션/서비스의 구조 및 행동을 정의하지만, 실행되는 인스턴스를 정의하지는 않는다. 매 구성요소, 포트 및 와이어 타입 선언은 하나 또는 그 이상의 인스턴스를 가질 수 있다. 인스턴스들은, 물리적 자원(서버, 네트워크 스위치 포트 및 디스크)이 할당되고 소프트웨어 자원(운영 체제, 런타임 호스트, 애플리케이션 코드)이 설치 및 구성되도록 애플리케이션/서비스를 배포한 결과이다.

모든 인스턴스들을 생성시부터 삭제시까지 추적하는 것은 SDM 런타임이 할 일이다.

SDM 런타임

SDM 런타임은 그 자신이 컴포넌트, 포트 및 와이어의 인스턴스들을 생성하지는 않고, 대신 SDM 인스턴스들의 생성 및 관리를 조정하는 데 사용되는 일단의 API들을 제공한다. 웹 서비스 컴포넌트에 대한 호스트로서 IIS와 함께 Windows Server를 실행시키는 서버와 같이, 인스턴스를 실제로 생성하는 데에는 통상적으로 복수의 엔티티가 관련되며, 완료되기까지는 수시간 또는 수일이 걸릴 수 있다.

SDM 런타임은 언제 "SDM 인스턴스 생성" 프로세스가 개시되고, 언제 성공 또는 실패로 종료될지를 알고 있다. 또한 SDM 런타임은 SDM 인스턴스에 대하여 그 존속 기간(lifetime)동안 어떤 변경이 가해져야 하는지를 알고 있다. SDM 런타임은 지정된 SDM과 관련된 인스턴스들에 관한 정보에 대하여 질의(query)를 받을 수 있도록 소정의 애플리케이션/서비스와 관련된 모든 트랜잭션(transaction)들을 기록하는 어카운턴트(accountant)라고 간주될 수 있다.

SDM 인스턴스를 생성하는 제1 단계는 애플리케이션/서비스 SDM을 SDM 런타임으로 등록하는 것이다. 일단 SDM 런타임이 주어진 SDM을 알게 되면, 인스턴스 생성 프로세스가 팩토리(Factory)들과 자원 관리자(Resource Manager; 이하 설명할 것임)들을 이용하여 호출될 수 있다.

API 및 런타임 설계에 관한 더욱 상세한 정보를 얻기 위해서는 http://big/에 있는 SDM 런타임 아키텍처 사양을 참조하면 된다.

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

다른 컴포넌트들을 "호스팅"할 수 있는 컴포넌트는 호스트라고 불리며, 이들이 지원하는 클래스들에 대한 팩토리로서 작용한다. 컴포넌트는 앞서 설명한 SDM 스키마의 hostRelations 요소를 이용하여 하나 또는 그 이상의 컴포넌트 클래스들의 호스트로서 선언될 수 있다.

호스트는 컴포넌트의 코드를 위한 실행 환경을 제공하지만, 팩토리는 소정 타입의 SDM 인스턴스들을 생성하고 SDM 런타임 API들을 통해 SDM 런타임과 상호작용하는 실제 서비스이다. 팩토리는 하나 이상의 컴포넌트 클래스를 지원할 수 있고, 어느 컴포넌트 클래스가 지원되는지를 지정하는 SDM 런타임으로 등록해야 한다.

소정의 팩토리는 상이한 구성을 갖는 동일한 타입의 호스트를 복수 개 지원할 수 있고, 또한 개개의 팩토리는 호스트 구성의 타입 각각에 대하여 존재할 수도 있다. 예컨대 IIS 팩토리는 웹 서비스 및 웹 애플리케이션과 같은 복수의 클래스를 지원할 수 있다. 마찬가지로, SQL 팩토리는 데이터베이스, 분할된 데이터베이스(Partitioned Database) 및 고가용 데이터베이스(Highly Available Database)와같은 상이한 데이터베이스 타입을 지원할 수 있다.

팩토리는 기억장치(storage), 네트워크 및 서버와 같은 물리적 자원을 그 자신이 관리하지는 않는다. 팩토리는 자원 관리자를 통해 물리적 자원(그리고 이들의 논리적 등가물)과 상호작용한다.

자원 관리자

자원 관리자는 (1) 부트스트랩(bootstrap) 프로세스의 일부로서 발견(discover) 또는 생성되거나, (2) 물리적 환경의 소정의 선언적 XML 기반의 기술을 통해 지정된 물리적 및 논리적 자원을 관리한다. 자원 관리자는 모든 기억장치, 네트워크 및 서버 자원을 보유하며, 공통의 자원 관리 API를 공개하여 자원 할당 요청을 처리하고 이러한 자원들의 소유권(ownership)을 추적한다.

자원 관리자의 예는 NRM(Network Resource Manager), SRM(Storage Resource Manager) 및 PRM(PC Resource Manager)이다. 이들 자원 관리자들 각각은 물리적 포트나 디스크 또는 서버 및 이들이 공개하는 VLAN, 논리적 디스크 볼륨(logical disk volumes), 공유 파일(file shares), 웹 서버 등과 같은 논리적 자원의 할당을 담당한다. 자원 관리자는 또한 할당 및 해제(de-allocation)를 달성하도록 물리적 장치들을 프로그래밍하는 역할을 한다.

물리적 하드웨어를 프로그램하기 위해, 자원 관리자는 하드웨어 장치의 구현 세부 사항을 숨기고 있는 자원 제공자들을 통해 하드웨어와 상호작용함으로써, 예컨대 복수의 벤더로부터 제공된 네트워크 스위치들이 서로 바뀌어 쓰일 수 있도록 한다(제조자의 장치에 대한 제공자가 존재하는 경우). Windows의 하드웨어 추상화계층(HAL; hardware abstraction layer) 및 장치 드라이버 모델과 마찬가지로, 서버, 네트워크 및 저장 장치에 이르는 데이터 센터 환경에 대해서도 동등한 추상화 계층이 존재한다.

계층 및 매핑

컴포넌트, 포트 및 와이어는 호스트, 팩토리, 자원 관리자 및 SDM 런타임과 결합되는 경우 강력한 추상화이지만, 이들은 분산형 애플리케이션/서비스를 배치 및 관리하기에는 충분하지 않다. 이러한 논리적 추상화의 물리적 인스턴스를 생성 및 관리하기 위해서는, 어떠한 추가적인 구축물(construct)이 필요하다. 이러한 추가적인 구축물은 계층 및 매핑이다.

계층

계층에 대한 필요는 애플리케이션/서비스의 배치 요건(deployment requirement)들을 설계시에 확증하고자 하는 욕구가 그 동기가 된다. 도 3은 SDM에 의해 정의된 계층 추상화를 나타내고 있다.

- 애플리케이션 계층은 분산 가능한 컴포넌트, 이들의 배치 요건 및 제한(constraints), 그리고 이들의 통신 관계(communication relationship)를 애플리케이션/서비스의 맥락에서 기술한다.

- 호스트 계층은 다른 것 들 중에서도 IIS, CLR 및 SQL과 같은 호스트에 대한 구성 및 정책(policy) 설정 및 제한을 기술한다.

- 가상 데이터 센터(VDC; Virtual Data Center) 계층은 운영 체제로부터 네트워크 토폴로지(topology)를 통해 서버, 네트워크 및 저장 장치에 이르기까지의데이터 센터 환경 설정 및 제한을 기술한다.

- 하드웨어 계층은 물리적 데이터 센터 환경을 기술하고, 이는 발견되거나 예컨대 XML을 이용하여 선언적 방식으로 지정된다. 이 계층은 스케일 불변이 아니므로 SDM에서 모델링되지 않으나, 완전함을 위해 포함되었다.

매핑(Mappings)

SDM이 계층화되어 있으므로, 다양한 계층을 바인딩(binding)할 필요가 존재한다. 매핑은 본질적으로 어떤 계층에 있는 컴포넌트 또는 포트를 아래의 다음 계층에 있는 컴포넌트 또는 포트와 바인딩한 것이다. 매핑은 다음과 같이 기술될 수 있다.

M_T= [T_n->T_n-1] + [T_n-1->T_n-2] + [T_n-2->T_n-3] + [...]

여기서 M은 컴포넌트, 포트, 또는 와이어를 나타내며, n은 계층을 나타낸다. 화살표는 매핑의 방향을 나타내며, 항상 높은 계층으로부터 낮은 계층 쪽으로 향한다.

예컨대, 도 4에서 MyFrontEnd라는 이름의 애플리케이션 계층에 있는 컴포넌트는 IIS라 불리는 호스트 계층에 있는 컴포넌트에 매핑된다. 마찬가지로 MyBackEnd라는 이름의 컴포넌트는 호스트 계층에 있는 SQL 컴포넌트에 매핑된다.

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

컴포넌트와 아래쪽 계층에 있는 그 컴포넌트의 호스트 컴포넌트 사이의 바인딩은, 애플리케이션/서비스가 실제로 라이브 데이터 센터(live data center)에 배치되기 전에 개발자에게 문제를 안겨줄 수 있다. 이러한 문제는 타입의 비호환, 구성의 충돌(conflict), 동작의 불일치(mismatch), 토폴로지 관계(topological relationship)의 결여 등에 기인한 것일 수 있다. 도 5는 컴포넌트와 입증에 관한 그것의 호스트 간의 설정 및 제한 체크 에러를 도시한다.

도 6에서, 다이어그램으로 도시된 매핑 시도는 오류를 낳을 수 있는 바, 배포 계층에 있는 IIS 및 SQL 컴포넌트 사이에는 잠재적인 통신 관계가 존재하지 않기 때문이다.

MyBackEnd 컴포넌트로부터 SQL 호스트 컴포넌트로의 매핑은 컴포넌트 및 호스트 타입의 호환성이 있고 구성 충돌이 없다는 점에서 유효한 바인딩이었을 수 있지만, MyFrontEnd와 지정된 배포 계층에 존재하지 않는 MyBackEnd 사이의 토폴로지 관계를 MyServiceSDM이 정의하였으므로 이는 유효하지 않다.

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

애플리케이션 계층으로부터 배치 계층(그리고 기타 등등)으로 매핑할 수 있는 능력은, 호스트의 제한에 대하여 컴포넌트의 설정을 설계시에 확증할 수 있도록 해 주고, 또한 컴포넌트의 제약에 대하여 호스트의 설정을 확증할 수 있도록 해 주므로 상당히 강력하다.

도 7은 상이한 계층에 있는 컴포넌트들 및 호스트 사이의 관계를 더욱 상세히 나타내고 있다. 이 도면에서, VDC 계층에 이르기까지 쭉, 어떤 계층에 있는 컴포넌트와 아래의 다음 계층에 있는 호스트 컴포넌트간에 바인딩이 존재함에 주목하자.

도 7에서, MyFrontEnd는 IIS에 의해 호스팅되는 웹 서비스이며, IIS는 윈도우 서버에 의해 호스팅되는 윈도우 애플리케이션(Windows Application)이다. IIS 및 SQL의 인스턴스들의 생성 및 삭제를 담당하는 윈도우 애플리케이션 팩토리가 존재하는 것과 마찬가지로, 웹 서비스 및 웹 애플리케이션 컴포넌트의 인스턴스들의 생성 및 삭제를 지원하는 IIS 팩토리가 존재한다.

도 8은 앞서 설명한 SDM 설정 및 제한 시멘틱(semantics)을 이용하여 상이한 계층에 있는 컴포넌트들 사이에서 설계 시 확증이 어떻게 동작하는지를 나타내고 있다.

여기서 위쪽 계층에 있는 컴포넌트의 제약은 아래쪽 계층에 있는 호스트 컴포넌트의 설정에 대하여 유효성이 검증됨에 주목하자. 또한 호스트 컴포넌트의 제약은 호스팅될 컴포넌트의 설정에 대하여 유효성이 검증됨에 주목하자.

양방향 설정 및 제약 체크는 개발자로 하여금, 아래 방향으로 쭉 SDM 시멘틱을 이용하여 기술된 동작 환경의 맥락에서 자신의 애플리케이션/서비스를 신뢰성있게 개발할 수 있도록 해 준다. 개발 프로세스 도중 데이터 센터에 관한 기술(description)이 신뢰받을 수 있도록 데이터 센터를 기술하기 위해서는, VDC(Virtual Data Center)라 일컬어지는 데이터 센터의 추상화를 생성할 필요가 있다.

가상 데이터 센터(VDC)

VDC는 개발자가 데이터 센터를 보는 시점을 간략하게 해 주는 물리적 데이터 센터 환경의 논리적 표현이다. 이상적으로 IT 전문가 또는 설계자(Architect)는개발자가 분산형 애플리케이션/서비스를 기술할 수 있는 스케일 불변 방식과 동일한 방식으로 데이터 센터를 기술할 수 있어야 한다. VDC는 데이터 센터 내의 서버, 네트워크 및 저장 자원 및 이들의 토폴로지 관계의 추상화인 것으로 간주될 수 있다. 통상적인 데이터 센터의 도표(diagram)는, 복수의 상호 연결된 서버, 네트워크 장비, IP 주소, VLAN, 운영 체제, 저장 장치 등이 Visio나 유사한 도구를 이용하여 그린 단일 도표상에 모두 표현되어 상당히 복잡하다. 이 도표에 추가하여, 데이터 센터가 어떻게 분할, 구성 및 관리되는지를 정확히 규정(prescribe)하는 통상적으로 긴 문서가 존재한다.

이러한 복잡함의 예로서는 MSA(Microsoft Systems Architecture) EDC(Enterprise Data Center)가 있다. 업데이트(update) 및 업그레이드(upgrade)가 적용됨에 따라 데이터 센터의 상태를 반영하여, 손으로 그린 도표 및 문서를 최신으로 유지하는 것은 불가능한 것은 아니더라도 비용이 많이 드는 일임이 분명하다. 마찬가지로, 문서의 규정 사항에 대하여 환경의 유효성을 검증하는 것은 어려울 뿐만 아니라 사람에 의한 오류가 발생할 수 있다.

스케일 불변 방식으로 MSA EDC와 같은 복잡한 데이터 센터를 표시하는 능력은 설계자 및 IT 전문가 모두에게 매우 강력한 것이다. 데이터 센터를 컴포넌트, 포트 및 와이어로 기술할 수 있는 능력은, 오늘날의 설계 및 배포 프로세스에서 결여되어 있는 배포 요건의 모델링 및 유효성 검증이 가능한 강력한 프레임워크를 제공한다.

SDM 원리

SDM은:

- 분산형 애플리케이션들/서비스들을 설계하는 것을 보다 쉽게 하는 추상화를 정의한다.

- 운영 실시의 자동화 및 재사용을 위한 프레임워크를 가능하게 한다.

- 분산형 애플리케이션 및 서비스들의 운영 및 배포를 단순화한다.

오늘날 서비스의 오퍼레이터 부근의 벽 상에서 복잡한 다이어그램으로서 흔히 보여지는 것을 캡쳐하는 것을 고려함으로써, SDM이 무엇인지를 이해하는 것이 더 쉬워질 수 있다. 이들 다이어그램에서, 박스는 일반적으로 서비스의 실행 요소를 나타내며, 박스들을 연결하는 선들은 서비스 요소들 간의 통신 경로를 나타낸다. 예를 들어, 다시 하나 이상의 중간-층(middle-tier) 또는 백-엔드 서비스들에 연결되는 일부 IIS 프론트-엔드 기계들에 연결된 로드 밸런서(load balancer)가 있다.

SDM에 대하여 생각하는 또다른 방법은 SDM은 분산형 애플리케이션/서비스의 동작에 대한 메타-모델(meta-model)과 컴퓨팅 환경에서 실행하는 애플리케이션/서비스의 "생생한" 청사진 모두라는 것이다. 가능한 소프트웨어 동작들을 포함하여, 선언적이고 스케일-불변의 방식으로, SDM은 컴퓨팅 환경에서 애플리케이션의 구조를 캡처한다. 하드웨어와 네트워크 자원 간의 바인딩을 포함하여 서비스의 토폴로지 및 소프트웨어 컴포넌트의 유효한 동작들을 선언적으로 기술하는 능력은 매우 강력하다.

유사한 것으로서, Microsoft의 Common Object Model(COM)을 살펴보자. COM은 컴포턴트들이 어떻게 패키지되고, 등록되고, 활성화되고, 발견되는지 등을 표준화하였다. COM은 라이프타임, 메모리 관리, 및 인터페이스 구현에 관한 엄격한 룰들을 명령한다. 이들 원형(primitives)은, 컴포넌트들이 블랙 박스로서 처리될 수 있도록 하기 때문에, 정보처리 상호운용(interoperability)에 필수적이다. COM은 이벤팅, 자동화 및 OLE와 같은 보다 정교한 서비스들을 위한 기초이다.

마찬가지로, SDM은 보다 정교한 특성을 만들기 위한 일부 기본 원형들을 정의하는 것을 필요로 한다. 이들 원형들은:

- 컴포넌트 - 구현, 배포 및 관리의 유닛

- 포트 - 관련 유형 및 유효한 동작들의 집합을 가지는 지정된 종단점

- 와이어 - 포트들간의 허용되는 통신 경로

- 계층 - 자원 관리 소유권 및 바인딩의 분리

- 맵핑 - 각 계층에서 컴포넌트, 포트 및 와이어 간의 바인딩

본 명세서의 나머지는 이들 원형들 각각을 보다 상세하게 설명할 것이다.

컴포넌트, 포트 및 와이어

본 명세서의 목적을 위하여, 컴포넌트, 포트 및 와이어를 사용하여 그려진 MyService라고 불리는 단순한 서비스의 그래픽적인 표현을 고려하는 것이 유용하다. 도 2에서, 박스들은 컴포넌트들을 나타내고, 다이아몬드들은 포트들을 나타내며, 파선은 와이어들을 나타낸다.

- MyService는, MyFrontEnd와 MyBackEnd라는 컴포넌트들을 사용하기 때문에 복합 컴포넌트이다.

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

- MyFrontEnd는 2개의 포트, 즉 위임 포트와 catalog라고 라벨이 붙은 포트를 가진다.

- MyBackEnd는 data라고 라벨이 붙은 하나의 포트를 가진다.

- MyFrontEnd와 MyBackEnd 컴포넌트들은 catalog 포트와 data포트를 와이어를 통하여 묶는 잠재적인 통신 관계를 가진다.

컴포넌트

컴포넌트들은 구현, 배포 및 관리의 유닛들이다. 컴포넌트들의 예들은 Windows Server를 실행하는 전용 서버, IIS 가상 웹 사이트 또는 SQL 데이터베이스이다. 컴포넌트들은 일반적으로 기계 경계를 가지나, 단일 서버 상에서 호스팅되는 다수의 IIS 가상 웹 사이트들에 의해 증명되어질 것을 요청되지는 않는다.

컴포넌트들은 포트들을 통하여 기능들을 공개하며, 와이들을 통하여 통신한다. 단순한 컴포넌트들은 단지 멤버들로서 포트들을 가질 수 있다. 다른 컴포넌트들을 사용하는 컴포넌트들은 복합 컴포넌트(compound component)라고 불리며, 다른 컴포넌트들에 덧붙여 포트들과 와이어들을 가질 수 있다.

복합 컴포넌트들은 합성을 통하여 생성되며, 그와 관련된 어떠한 구현도 가지지 않는다. 복합 컴포넌트 포트들은 내부 컴포넌트들로부터의 위임 포트들이다. 복합 컴포넌트들은 배열(collocation), 캡슐화(encapsulation) 및 재사용을 가능하게 하며, 따라서 애플리케이션/서비스 및 그 행동을 조직화하는 하나의 방법으로생각될 수 있다.

컴포넌트의 단지 공용 포트들(public ports)만이 컴포넌트 외부에서 가시적이다. 복합 컴포넌트들은 캡슐화를 통하여 자신이 사용하는 컴포넌트들의 내부 구조를 숨긴채 외부 세계에는 단순 컴포넌트들(simple components)로 보인다. 사실, 양자에 의해 지원되는 행동들과 포트 유형들이 완전히 동일하기만 하다면, 단순 컴포넌트는 복합 컴포넌트로 교체될 수 있으며, 그 역도 가능하다.

포트

포트들은, 관련 유형을 가지며 일반적으로 프로토콜 역할(protocol role)과 허용되는 동작들의 집합과 관련되는, 명명된 종단점(named end-points)이다. 포트들은 포트들의 예들은 허용되는 동작들의 집합을 가지는 SOAP 포트, HTTP 서버 포트 등이 있다. 포트들은 위임될 수 있는데, 이는 외부 컴포넌트가 내부 컴포넌트의 포트를 자신의 것인양 공개할 수 있다는 것을 의미한다. 포트들은 하나의 컴포넌트에 대한 공용 인터페이스(행동)를 형성한다. 포트들은 공용으로(가시적으로) 될 수 있는 컴포넌트의 유일한 멤버들이다.

와이어

와이어들은 포트들간의 허용되는 바인딩들이며, 포트들 (및 컴포넌트들) 간의 토폴로지적 관계를 나타낸다. 와이어들은 임의의 인스턴스 상호연결 토폴로지(instance interconnect topology)를 지정하지 않으며, 대신 인스턴스 상호연결 토폴로지를 위한 "잠재성(potentiality)"을 표현한다.

와이어들은 본질적으로 버스들이며, 하나 이상의 포트 멤버들을 포함할 수있다. 와이어들은 포인트-투-포인트 관계로 오해되어서는 안 된다. 주어진 포트는 동일한 와이어 내에서 한번 이상 나타날 수 없다.

스키마(Schema)

애플리케이션/서비스를 설명하기 위해서는, SDM을 위한 표준 스키마를 가질 필요가 있다. SDM 스키마는 XSD 및 XML 문법을 이용하여 표현될 수 있어야 한다. SDM 스키마를 상세히 설명하는 것은 본 명세서의 범위를 벗어나는 것이지만, 본 명세서에서 이후에 설명할 주제를 위한 맥락으로서 간략한 설명을 하는 것이 필요하다. 이하는 SDM 스키마를 간략하게 나타낸 것이다.

<sdm>

<import />

<identityReference />

<information />

<portImplementationType />

<wireImplementationType />

<componentImplementationType />

<hostRelations />

<portTypes />

<wireTypes />

<componentTypes />

</sdm>

SDM 스키마에 대한 더욱 상세한 정보를 얻고자 하면 http://big/에 있는 SDM 스키마 사양(specification)을 읽고 샘플 XSD 파일을 검토하도록 한다.

유형(Types)

애플리케이션/서비스에서 사용되는 모든 컴포넌트, 포트 및 와이어(wire)는 유형이다. 유형은 본질적으로 C+ 및 C# 등과 같은 객체지향형 언어에서의 클래스에 상당하는 것이며, 클래스와 마찬가지로 새로운 유형은 기존의 유형들로부터 생성(create)될 수 있다. 스케일 불변(scale-invariant) 스페이스는 SDM 스키마에서 portTypes, wireTypes 및 componentTypes로 나타내어진다. 스케일 불변이라 함은, 컴포넌트, 포트, 또는 와이어는 실제의 데이터 센터에 이들 각각의 복수의 인스턴스가 존재하는 경우라 하더라도 애플리케이션/서비스 SDM에서 일단 표현될 수 있음을 의미한다.

유형은 궁극적으로 구현 유형(implementation type)으로부터 파생되며, 이는 본질적으로 공통된 기술 특징에 대한 추상화(abstraction)이다. 예컨대 웹 서비스(Web Service)는 SQL 데이터베이스와 마찬가지로 구현 유형으로서 모델링될 수 있다. MyService 애플리케이션에서는, MyFrontEnd는 구현 유형 웹 서비스로부터 파생되는 새로운 유형이고, MyBackEnd는 구현 유형 SQL 데이터베이스로부터 파생되는 새로운 유형이다.

componentImplementationType 및 wireImplementationType SDM 스키마 요소(element) 각각은 설정 스키마(settings schema), 배포 목록(deployment manifest) 및 포트 구현 참조(reference)를 포함할 수 있다.portImplemenationType 요소는 포트 구현 참조를 갖지 않는다. 도 9는 SDM 구현 유형 스페이스가 어떻게 생겼는지를 나타내고 있다.

- 설정 스키마는 설계시(design-time) 유효성이 검증될 수 있는 컴포넌트, 포트 및 와이어 상의 구성 파라미터(configuration parameter)들에 대한 XSD이다.

- 배포 목록은 컴포넌트, 포트, 또는 와이어가 설치되려면 어느 설치 파라미터들이 설정될 필요가 있는지를 표현하는 XSD이다. 이 목록은 Fusion 또는 그 밖의 어떠한 설치자(installer) 기술에 대한 스키마일 수 있다.

- 포트 구현 참조는 컴포넌트 및 와이어가 선언(declare)된 포트 구현 유형을 참조함으로써 허용 가능한 포트를 선언하는 위치이다.

또한, 다른 컴포넌트들을 호스팅할 수 있는 컴포넌트는, 설치자 및 자신이 호스팅할 수 있는 컴포넌트 구현 유형을 식별하는 hostRelations SDM 스키마 요소를 이용하여 선언된다. hostRelations 요소는 컴포넌트들 중 하나가 다른 컴포넌트(들)을 위한 호스트로서 작용하는 경우 컴포넌트 구현 유형간의 방향성 링크(directional link)로서 간주될 수 있다. 컴포넌트를 호스팅한다는 것은 컴포넌트의 코드를 위한 실행 환경을 제공한다는 것을 의미한다. 예컨대 IIS는 구현 유형 웹 서비스 및 웹 애플리케이션(Web Application)의 컴포넌트들을 위한 호스트이다. 호스트는 본 명세서에서 이후에 더욱 상세히 설명하기로 한다.

SDM 스키마에서 portType, wireType 및 componentType 요소 각각은 애플리케이션 제약값(application constraint value), 배포 값(deployment value) 및 호스트 제약값(host constraint value)을 포함한다. 또한 wireType 요소는 지정된 와이어 유형 상에서 허용 가능한 포트 유형을 정의하는 포트 유형 요소를 포함하며, componentType 요소는 지정된 컴포넌트 유형 상에서 호스팅될 수 있는 구현 유형을 식별하는 호스팅된 유형 리스트(hosted types list) 요소를 포함한다. 도 10은 SDM 유형 스페이스를 나타낸다.

- 설정값은 컴포넌트, 포트 및 와이어에 대한 구성값을 제공하는 설정 스키마에 대한 XML이고, 호스트의 제약값에 대하여 설계시에 유효성이 검증될 수 있다.

- 배포값은 컴포넌트, 포트, 또는 와이어가 제대로 기능하기 위해 설정될 필요가 있는 구성 파라미터의 값을 표현하는 배포 목록에 대한 XML이다.

- 제약값은 호스트의 컴포넌트, 포트, 또는 와이어가 설정되어야 하는 구성 파라미터 값을 제공하는 설정 스키마를 위한 XML이다. 제약값은 설계시에 기저 호스트(underlying host)의 설정값에 대하여 유효성이 검증될 수 있다.

- 포트 유형은 지정된 와이어의 멤버일 수 있는 허용 가능한 포트 유형을 열거하는 XML이다.

- 호스팅된 유형 리스트는 어떤 컴포넌트가 호스팅할 수 있는 컴포넌트 구현 유형의 리스트를 그 컴포넌트가 선언하는 XML이다.

인스턴스(Instances)

컴포넌트, 포트 및 와이어는 애플리케이션/서비스의 구조 및 양상(behavior)을 정의하지만, 실행되는 인스턴스를 정의하지는 않는다. 매 구성요소, 포트 및 와이어 유형 선언은 하나 또는 그 이상의 인스턴스를 가질 수 있다. 인스턴스들은, 물리적 자원(서버, 네트워크 스위치 포트 및 디스크)이 할당되고 소프트웨어자원(운영 체제, 런타임 호스트, 애플리케이션 코드)이 설치 및 구성되도록 애플리케이션/서비스를 배포한 결과이다.

모든 인스턴스들을 생성시부터 삭제시까지 추적하는 것은 SDM 런타임이 할 일이다.

SDM 런타임(SDM Runtime)

SDM 런타임은 그 자신이 컴포넌트, 포트 및 와이어의 인스턴스들을 생성하지는 않고, 대신 SDM 인스턴스들의 생성 및 관리를 조정하는 데 사용되는 일단의 API들을 제공한다. 웹 서비스 컴포넌트에 대한 호스트로서 IIS와 함께 윈도우 서버(Windows Server)를 실행시키는 서버와 같이, 인스턴스를 실제로 생성하는 데에는 통상적으로 복수의 엔티티(entity)가 관련되며, 완료되기까지는 수시간 또는 수일이 걸릴 수 있다.

SDM 런타임은 언제 "SDM 인스턴스 생성" 프로세스가 개시되고, 언제 성공 또는 실패로 종료될지를 알고 있다. 또한 SDM 런타임은 SDM 인스턴스에 대하여 그 존속 기간(lifetime)동안 어떤 변경이 가해져야 하는지를 알고 있다. SDM 런타임은 지정된 SDM과 관련된 인스턴스들에 관한 정보에 대하여 질의(query)를 받을 수 있도록 소정의 애플리케이션/서비스와 관련된 모든 트랜잭션(transaction)들을 기록하는 어카운턴트(accountant)라고 간주될 수 있다.

SDM 인스턴스를 생성하는 제1 단계는 애플리케이션/서비스 SDM을 SDM 런타임으로 등록하는 것이다. 일단 SDM 런타임이 주어진 SDM을 알게 되면, 인스턴스 생성 프로세스가 팩토리(Factory)들과 자원 관리자(Resource Manager; 이하 설명할것임)들을 이용하여 호출될 수 있다.

API 및 런타임 설계에 관한 더욱 상세한 정보를 얻기 위해서는 http://big/에 있는 SDM 런타임 아키텍쳐 사양을 참조하면 된다.

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

다른 컴포넌트들을 "호스팅"할 수 있는 컴포넌트는 호스트라고 불리며, 이들이 지원하는 구현 유형에 대한 팩토리로서 작용한다. 컴포넌트는 앞서 설명한 SDM 스키마의 hostRelations 요소를 이용하여 하나 또는 그 이상의 컴포넌트 구현 유형의 호스트로서 선포될 수 있다.

호스트는 컴포넌트의 코드를 위한 실행 환경을 제공하지만, 팩토리는 소정 유형의 SDM 인스턴스들을 생성하고 SDM 런타임 API들을 통해 SDM 런타임과 상호작용하는 실제 서비스이다. 팩토리는 하나 또는 그 이상의 컴포넌트 구현 유형을 지원할 수 있고, 어느 컴포넌트 구현 유형이 지원되는지를 지정하는 SDM 런타임으로 등록해야 한다. 소정의 팩토리는 상이한 구성을 갖는 동일한 유형의 호스트를 복수 개 지원할 수 있고, 또한 개개의 팩토리는 호스트 구성의 유형 각각에 대하여 존재할 수도 있다. 예컨대 IIS 팩토리는 웹 서비스 및 웹 애플리케이션과 같은 복수의 구현 유형을 지원할 수 있다. 마찬가지로, SQL 팩토리는 데이터베이스, 분할된 데이터베이스(Partitioned Database) 및 고가용 데이터베이스(Highly Available Database)와 같은 상이한 데이터베이스 유형을 지원할 수 있다.

팩토리는 기억장치(storage), 네트워크 및 서버와 같은 물리적 자원을 그 자신이 관리하지는 않는다. 팩토리는 자원 관리자를 통해 물리적 자원(그리고 이들의 논리적 등가물)과 상호작용한다.

자원 관리자(Resource Managers)

자원 관리자는 (1) 부트스트랩(bootstrap) 프로세스의 일부로서 발견(discover) 또는 생성되거나, (2) 물리적 환경의 소정의 선언적 XML 기반의 기술(description)을 통해 지정된 물리적 및 논리적 자원을 관리한다. 자원 관리자는 모든 기억장치, 네트워크 및 서버 자원을 보유하며, 공통의 자원 관리 API를 공개하여 자원 할당 요청을 처리하고 이러한 자원들의 소유권(ownership)을 추적한다.

자원 관리자의 예는 NRM(Network Resource Manager), SRM(Storage Resource Manager) 및 PRM(PC Resource Manager)이다. 이들 자원 관리자들 각각은 물리적 포트나 디스크 또는 서버 및 이들이 공개하는 VLAN, 논리적 디스크 볼륨(logical disk volumes), 공유 파일(file shares), 웹 서버 등과 같은 논리적 자원의 할당을 담당한다. 자원 관리자는 또한 할당 및 해제(de-allocation)를 달성하도록 물리적 장치들을 프로그래밍하는 역할을 한다.

물리적 하드웨어를 프로그램하기 위해, 자원 관리자는 하드웨어 장치의 구현 세부 사항을 숨기고 있는 자원 제공자들을 통해 하드웨어와 상호작용함으로써, 예컨대 복수의 공급자(vendor)로부터 제공된 네트워크 스위치들이 서로 바뀌어 쓰일 수 있도록 한다(제조자의 장치에 대한 제공자가 존재하는 경우). 윈도우(Windows)의 하드웨어 추상화 계층(HAL; hardware abstraction layer) 및 장치 드라이버 모델과 마찬가지로, 서버, 네트워크 및 저장 장치에 이르는 데이터 센터 환경에 대해서도 동등한 추상화 계층이 존재한다.

계층 및 매핑(Layers and Mappings)

컴포넌트, 포트 및 와이어는 호스트, 팩토리, 자원 관리자 및 SDM 런타임과 결합되는 경우 강력한 추상화(abstraction)이지만, 이들은 분산형 애플리케이션/서비스를 배포 및 관리하기에는 충분하지 않다. 이러한 논리적 추상화의 물리적 인스턴스를 생성 및 관리하기 위해서는, 어떠한 추가적인 구축물(construct)이 필요하다. 이러한 추가적인 구축물은 계층 및 매핑이다.

계층(Layers)

계층에 대한 필요는 애플리케이션/서비스의 배포 요건(deployment requirement)들의 유효성을 설계시에 검증하고자 하는 욕구가 그 동기가 된다. 도 11은 SDM에 의해 정의된 계층 추상화를 나타내고 있다.

- 애플리케이션 계층은 분산 가능한 컴포넌트, 이들의 배포 요건 및 제약(constraints), 그리고 이들의 통신 관계(communication relationship)를 애플리케이션/서비스의 맥락에서 기술한다.

- 배포 계층은 다른 것 들 중에서도 IIS, CLR 및 SQL과 같은 호스트에 대한 구성 및 정책(policy) 설정 및 제약을 기술한다.

- 가상 데이터 센터(VDC; Virtual Data Center) 계층은 운영 체제로부터 네트워크 토폴로지(topology)를 통해 서버, 네트워크 및 저장 장치에 이르기까지의 데이터 센터 환경 설정 및 제약을 기술한다.

- 하드웨어 계층은 물리적 데이터 센터 환경을 기술하고, 이는 발견되거나예컨대 XML을 이용하여 선언적 방식으로 지정된다. 이 계층은 스케일 불변이 아니므로 SDM에서 모델링되지 않으나, 완전함을 위해 포함되었다.

매핑(Mappings)

SDM이 계층화되어 있으므로, 다양한 계층을 바인딩(binding)할 필요가 존재한다. 매핑은 본질적으로 어떤 계층에 있는 컴포넌트 또는 포트를 아래의 다음 계층에 있는 컴포넌트 또는 포트와 바인딩한 것이다. 매핑은 다음과 같이 기술될 수 있다.

M_T= [T_n->T_n-1] + [T_n-1->T_n-2] + [T_n-2->T_n-3] + [...]

여기서 M은 컴포넌트, 포트, 또는 와이어를 나타내며, n은 계층을 나타낸다. 화살표는 매핑의 방향을 나타내며, 항상 높은 계층으로부터 낮은 계층 쪽으로 향한다.

예컨대, 도 12에서 MyFrontEnd라는 이름의 애플리케이션 계층에 있는 컴포넌트는 IIS라 불리는 배포 계층에 있는 컴포넌트에 매핑된다. 마찬가지로 MyBackEnd라는 이름의 컴포넌트는 배포 계층에 있는 SQL 컴포넌트에 매핑된다.

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

컴포넌트와 아래쪽 계층에 있는 그 컴포넌트의 호스트 컴포넌트 사이의 바인딩은, 애플리케이션/서비스가 실제로 라이브 데이터 센터(live data center)에 배포되기 전에 개발자에게 문제를 안겨줄 수 있다. 이러한 문제는 유형의 비호환, 구성의 충돌(conflict), 동작의 불일치(mismatch), 토폴로지 관계(topologicalrelationship)의 결여 등에 기인한 것일 수 있다. 예컨대 도 13에 도시된 매핑 시도는 오류를 낳을 수 있는 바, 배포 계층에 있는 IIS 및 SQL 컴포넌트 사이에는 잠재적인 통신 관계가 존재하지 않기 때문이다.

MyBackEnd 컴포넌트로부터 SQL 호스트 컴포넌트로의 매핑은 컴포넌트 및 호스트 유형의 호환성이 있고 구성 충돌이 없다는 점에서 유효한 바인딩이었을 수 있지만, MyFrontEnd와 지정된 배포 계층에 존재하지 않는 MyBackEnd 사이의 토폴로지 관계를 MyServiceSDM이 정의하였으므로 이는 유효하지 않다.

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

애플리케이션 계층으로부터 배포 계층(그리고 기타 등등)으로 매핑할 수 있는 능력은, 호스트의 제약에 대하여 컴포넌트의 설정의 유효성을 설계시에 검증할 수 있도록 해 주고, 또한 컴포넌트의 제약에 대하여 호스트 설정의 유효성을 검증할 수 있도록 해 주므로 상당히 강력하다.

도 14는 상이한 계층에 있는 컴포넌트들 및 호스트 사이의 관계를 더욱 상세히 나타내고 있다. 이 도면에서, VDC 계층에 이르기까지 쭉, 어떤 계층에 있는 컴포넌트와 아래의 다음 계층에 있는 호스트 컴포넌트간에 바인딩이 존재함에 주목하자.

도 14에서, MyFrontEnd는 IIS에 의해 호스팅되는 웹 서비스이며, IIS는 윈도우 서버에 의해 호스팅되는 윈도우 애플리케이션(Windows Application)이다. IIS 및 SQL의 인스턴스들의 생성 및 삭제를 담당하는 윈도우 애플리케이션 팩토리가 존재하는 것과 마찬가지로, 웹 서비스 및 웹 애플리케이션 컴포넌트의 인스턴스들의 생성 및 삭제를 지원하는 IIS 팩토리가 존재한다.

도 15는 앞서 설명한 SDM 설정 및 제약 시멘틱(semantics)을 이용하여 상이한 계층에 있는 컴포넌트들 사이에서 설계시 유효성 검증이 어떻게 동작하는지를 나타내고 있다.

여기서 위쪽 계층에 있는 컴포넌트의 제약은 아래쪽 계층에 있는 호스트 컴포넌트의 설정에 대하여 유효성이 검증됨에 주목하자. 또한 호스트 컴포넌트의 제약은 호스팅될 컴포넌트의 설정에 대하여 유효성이 검증됨에 주목하자.

양방향 설정 및 제약 체크는 개발자로 하여금, 아래 방향으로 쭉 SDM 시멘틱을 이용하여 기술된 동작 환경의 맥락에서 자신의 애플리케이션/서비스를 신뢰성있게 개발할 수 있도록 해 준다. 개발 프로세스 도중 데이터 센터에 관한 기술(description)이 신뢰받을 수 있도록 데이터 센터를 기술하기 위해서는, VDC(Virtual Data Center)라 일컬어지는 데이터 센터의 추상화를 생성할 필요가 있다.

가상 데이터 센터(VDC)

VDC는 개발자가 데이터 센터를 보는 시점을 간략하게 해 주는 물리적 데이터 센터 환경의 논리적 표현이다. 이상적으로 IT 전문가 또는 설계자(Architect)는 개발자가 분산형 애플리케이션/서비스를 기술할 수 있는 스케일 불변 방식과 동일한 방식으로 데이터 센터를 기술할 수 있어야 한다. VDC는 데이터 센터 내의 서버, 네트워크 및 저장 자원 및 이들의 토폴로지 관계의 추상화인 것으로 간주될 수 있다. 통상적인 데이터 센터의 도표(diagram)는, 복수의 상호 연결된 서버, 네트워크 장비, IP 주소, VLAN, 운영 체제, 저장 장치 등이 Visio나 유사한 도구를 이용하여 그린 단일 도표상에 모두 표현되어 상당히 복잡하다. 이 도표에 추가하여, 데이터 센터가 어떻게 분할, 구성 및 관리되는지를 정확히 규정(prescribe)하는 통상적으로 긴 문서가 존재한다.

이러한 복잡함의 예로서는 MSA(Microsoft Systems Architecture) EDC(Enterprise Data Center)가 있다. 업데이트(update) 및 업그레이드(upgrade)가 적용됨에 따라 데이터 센터의 상태를 반영하여, 손으로 그린 도표 및 문서를 최신으로 유지하는 것은 불가능한 것은 아니더라도 비용이 많이 드는 일임이 분명하다. 마찬가지로, 문서의 규정 사항에 대하여 환경의 유효성을 검증하는 것은 어려울 뿐만 아니라 사람에 의한 오류가 발생할 수 있다.

스케일 불변 방식으로 MSA EDC와 같은 복잡한 데이터 센터를 표시하는 능력은 설계자 및 IT 전문가 모두에게 매우 강력한 것이다. 데이터 센터를 컴포넌트, 포트 및 와이어로 기술할 수 있는 능력은, 오늘날의 설계 및 배포 프로세스에서 결여되어 있는 배포 요건의 모델링 및 유효성 검증이 가능한 강력한 프레임워크를 제공한다.

아젠다(Agenda): 개요, SDM 빌딩 블록(Building Blocks), 예시 애플리케이션, 예시 호스트, 논리적 배치(Logical Placement), 배포, 상태(Status)

SDM은 분산형 애플리케이션 및 이들의 배포 환경의 요소 부분을 캡쳐(capture)하는 데에 적합한 메타모델(meta-model)이다. SDM은 권한을 갖는다. 즉 애플리케이션 및 환경은 이들의 SDM으로부터 구축되고, 애플리케이션 및 환경에대한 변경은 SDM을 통해 이루어지며, 관리 프로세스를 위한 네임스페이스 (namespace)가 제공된다.

서비스 정의 모델(Service Definition Model)은 상호 관련된 스키마, 즉

클래스, 클래스 관계 및 설치자 스키마

컴포넌트, 포트 및 와이어 유형 스키마

논리적 배치 스키마

물리적 배치 스키마

인스턴스화(instantiation) 요청 스키마

인스턴스 스키마

의 집합을 지칭한다.

SDM 클래스는 모든 분산형 애플리케이션 및 배포 환경에 대한 기본 빌딩 블록이다. Application 클래스에는 ASP.Net Web Service, ASP.Net Web Site, BizTalk Orchestration Schedule, Services Components(COM+) 등이 있다. Service 클래스에는 IIS Server, SQL Sever, BizTalk Server가 있다. OS, Network & Storage 클래스에는 Windows VLAN, Filter, Disk 등이 있다. Hardware 클래스에는 Server, Switch, Firewall, Load Balancer, SAN 등이 있다. 클래스는 시스템 레벨 개발자에 의해 만들어지며, 자주 바뀌지 않는다. 클래스는 SDM의 모든 컴포넌트, 포트 및 와이어 각각의 배후에 있다. 클래스 각각은 공개 설정(public settings; 설정이라고 간단히 불림) 및 개인 설정(private settings; 배포라고 불림)을 포함한다. 관계(relationship)는 클래스 사이, 즉 포트 클래스에 대한 컴포넌트 클래스, 포트 클래스에 대한 와이어 클래스 및 컴포넌트 클래스에 대한 컴포넌트 클래스에서 캡쳐된다.

ASP.Net Web Site 클래스

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

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

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

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

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

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

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

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

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

<portClassesAllowed closed="true">

<portClassRef name="ClientDataAccess" />

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

<portClassRef name="SoapClientInterface" />

<portClassRef name="RemotingClientInterface" />

</portClassesAllowed>

</componentClass>

SOAP Client Port 클래스

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

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

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

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

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

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

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

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

</portClass>

SOAP Wire 클래스

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

<settingSchema/>

<deploymentSchema/>

<portClassesAllowed>

<portClassRef name="SoapServerInterface"/>

<portClassRef name="SoapClientInterface"/>

</portClassesAllowed>

</wireClass>

IIS Component 클래스

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

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

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

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

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

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

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

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

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

- <portClassesAllowed>

<portClassRef name="HTTPServer"/>

<portClassRef name="HTTPClient"/>

<portClassRef name="TDSClient"/>

</portClassesAllowed>

</componentClass>

클래스 관계 및 설치자

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

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

<HostRelation>은 클래스들 사이의 호스팅 관계를 캡쳐한다. 즉 IIS는 WebSites를 호스팅할 수 있다.

설치자는 SDM 런타임으로의 "플러그인(plugin)"이며, 컴포넌트, 포트 및/또는 와이어 클래스의 새로운 인스턴스를 생성하는 역할을 한다. 설치자는 또한 클래스의 인스턴스들을 구성하는 역할도 한다. 상이한 설치자들은 동일한 기저 배포 및 구성 기술, 예컨대 Fusion 또는 WMI.Config을 사용할 수 있다.

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

분산형 애플리케이션은 컴포넌트, 포트 및 와이어로부터 구축된다. 개발자는 컴포넌트, 포트 및 와이어 유형을 클래스로부터 생성한다. 유형은 클래스의 "용도(uses)"이며, 설정 및 배포 스키마의 값들을 공급한다. 유형은 재활용의 단위이다. 유형은 Visual Studio에서의 단일 프로젝트에 대하여 매핑된다.

SDM은 복합 컴포넌트 유형(compound component type)을 통해 유형의 합성(composition)을 지원한다. 합성에 의해 작은 애플리케이션으로부터 더욱 큰 분산형 애플리케이션을 구축할 수 있다. 복합 컴포넌트 유형은 Visual Studio의 새로운 프로젝트 유형, 즉 Whitehorse에 대하여 매핑된다.

FMStocks.Web 컴포넌트 유형

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

<ports>

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

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

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

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

</ports>

<settings>

<webSiteName>FMStocks.Web</webSiteName>

<authentication>Certificate</authentication>

<sessionState>true</sessionState>

</settings>

<deployment>

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

</deployment>

</componentType>

FMStocks7 복합 컴포넌트 유형

<compoundComponentType name="FMStocks">

<components>

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

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

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

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

</components>

<wires/>

<delegatePorts>

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

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

</delegateports>

</componentType>

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

분산형 애플리케이션에 대한 컴포넌트, 포트 및 와이어 유형은 서비스 배포 유닛(SDU; Service Deployment Unit) 내에 바이너리(binary)와 함께 패키징될 수 있다. 바이너리는 모든 .DLL, .EXE, .config 및 정적 콘텐츠(static content) 등을 포함한다. SDU는 이동 가능(portable)하고, 독립적으로 설치 가능한 분산형 애플리케이션을 나타낸다. 데스크탑 애플리케이션을 위한 Windows Installer MSI 파일과 유사하다. 그러나 균일한 환경(Windows)을 주로 목표(target)로 삼는 데스크탑 애플리케이션과 달리, 분산형 애플리케이션은 현저하게 바뀌는 상이한 배포 환경에서 호스팅될 수 있고, 배포 환경 상에서의 이들의 요건을 표현할 수 있어야 하며, 배포 환경의 모든 정책에 따라야 한다.

따라서 애플리케이션 및 배포 환경 모두의 요건 및 제약을 표현할 수 있는 모델이 필요하다. MyWebSite 컴포넌트 유형은 SQL 데이터베이스에 저장된 세션 상태로 구성되어 있는 IIS 서버를 필요로 한다. 웹 존(web zone)은 자격 인증(certificate authentication)을 이용하는 webSites 컴포넌트만을 호스팅한다.

IIS 컴포넌트 유형

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

<ports/>

<settings>

<certificateAuth>true</certificateAuth>

<ntlmAuth>false</ntlmAuth>

<sessionStateType>true</sessionStateType>

</settings>

<deployment/>

<hostedClasses>

<hostedClass class="WebSite">

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

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

</hostedClass>

</hostedClasses>

</componentType>

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

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

<ports/>

<settings>

<webSiteName>FMStocks.Web</webSiteName>

<authentication>Certificate</authentication>

<sessionState>true</sessionState>

</settings>

<deployment>

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

</deployment>

<hostConstraints>

<hostConstraint hostClass="IIS">

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

</hostConstraint>

</hostConstraints>

</componentType>

논리적 배치(Logical Placement)

SDU가 배포되기에 앞서, 우선 목표 배포 환경 상에서 유형들을 논리적으로 배치(placement)해야 한다. 논리적 배치는 설계시에 이루어질 수 있다. 요구 및 제약 사항이 체크되며, 개발자는 오류 또는 경고를 알게 된다. 논리적 배치의 결과는 SDU와는 별개의 파일에 캡쳐된다. SDU는 상이한 배포 환경(개발, 테스트, 생산 등)에 대한 상이한 논리적 배치를 가질 수 있다.

제약 체크는 각 컴포넌트, 포트 및 와이어 클래스에 지정된 XPath 및 XSD를 이용하여 구현된다.

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

배포 환경은 SDM 모델을 이용하여 구축된다. 도 22를 참조하자. 본질적으로, 이러한 환경은 상이한 계층에 있는 SDM 애플리케이션이다. 컴포넌트, 포트 및 와이어 유형은 서비스 호스트, 네트워크 아키텍쳐 및 하드웨어를 구성하는 데 있어 동일한 방식으로 이용된다. Whidbey 타임프레임(timeframe)에서는 오직 애플리케이션 계층의 배포를 지원한다. ADS V2.0에서는 Service Host, Network 및 Hardware 계층을 배포할 수 있다. Visual Studio는 배포 환경을 제작하기 위한 설계자(designer)를 구축한다. Visual Studio는 이를 논리적 인프라스트럭처(Logical Infrastructure)라 칭한다. 도 23은 예시 배포를 나타낸 것이다.

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

SDM 유형은 스케일 불변이며 어떤 스케일로도 생성될 수 있다. 인스턴스 요청 문서는 생성될 필요가 있는 인스턴스들의 선언적 정의이며, 와이어링 토폴로지(wiring topology)를 포함한다. 도 24는 예시 유형을 도시하고 있으며, 도 25는 예시 인스턴스 요청을 나타내고 있다.

물리적 배치(Physical Placement)

물리적 배치는 배포의 목표인 특정 호스트 인스턴스를 골라내는 동작이다. 물리적 배치는 논리적 배치에 의해 제약된다. 제약은 물리적 배치 도중에 유효성이 재검증(revalidate)된다. 도 26을 참조한다.

배포(Deployment)

SDU, 논리적 배치 파일, 인스턴스 요청 및 물리적 배치 파일이 SDM 런타임에 공급된다. SDM 런타임은 클래스 및 호스트 관계에 기초하여 적합한 설치자를 호출한다. 설치자는 새로운 인스턴스를 호스트상에 생성하고 이것이 유형상의 설정값에 일치하도록 구성하는 역할을 맡는다. SDM 런타임은 모든 인스턴스, 이들의 최종 설정값 및 배치의 데이터베이스를 유지한다. 런타임 API는 인스턴스 스페이스의 질의를 지원한다.

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

SDM 스키마의 세 가지 핵심 요소는 포트, 와이어 및 컴포넌트이다. 포트는 통신 종단점(endpoint)을 나타내고, 컴포넌트는 분산형 애플리케이션의 부분을 나타내고, 와이어는 애플리케이션 부분 사이의 통신 링크를 나타낸다. 이들은 세 가지 별개의 스페이스, 즉 자원 스페이스, 애플리케이션 스페이스 및 인스턴스 스페이스에서 상이한 형태로 나타난다.

자원 스페이스에서는 자원 클래스(이것으로부터 애플리케이션 스페이스 내의 애플리케이션이 구축됨)가 정의된다. 이들 클래스는 애플리케이션 부분들의 공통의 카테고리화를 제공하며, 이에 의해 넓은 범위의 애플리케이션에 대한 도구 지원을 가능하게 하며, 설계시에 유형 체크의 기초를 제공한다. 이러한 핵심 클래스는 서비스 설계를 위한 포괄적인 피처(feature) 세트를 제공하고, 시간에 따라 천천히 변화하는 간주된다.

애플리케이션 스페이스에서는 애플리케이션 유형이 구축된다. 자원 클래스를 택하여 세부 사항을 채워 넣는 바, 예컨대 콘텐츠에 대한 링크를 제공하거나,특성(property)들에 대한 설정값들을 제공하는 것이 그것이다. 그 후 포트 유형을 컴포넌트 유형과 연관시킴으로써 애플리케이션 유형으로부터 분산형 애플리케이션을 구축하는 바, 이는 복합 컴포넌트 유형 내의 컴포넌트 유형을 이용하고, 복합 컴포넌트 유형의 멤버들 사이의 통신 관계를 와이어 유형을 이용하여 기술함으로써 이루어진다.

인스턴스 스페이스는 애플리케이션의 배포 및 실행 프로세스 도중에 생성되는 인스턴스들로 이루어진다. 애플리케이션 스페이스에서 정의한 통신 관계를 SDM 런타임을 통해 공개함으로써 인스턴스들이 다른 인스턴스들을 찾을 수 있도록 해 준다.

자원 클래스(Resource Classes)

설계시에 구성을 체크한 후 실행시에 배포하기 위해 알아야 할 필요가 있는 애플리케이션의 요소를 정의하기 위해 자원 클래스를 이용한다. 이들 요소는 다음과 같다.

a) 애플리케이션이 통신하는 대상이다. 분산형 애플리케이션을 네트워크 토폴로지에 대하여 검증(verify)하기 위해서는, 애플리케이션의 부분들이 서로 통신하는 데 사용할 수 있는 프로토콜에 관하여 알아야 할 필요가 있다. 포트 클래스는 프로토콜 종단점을 기술하는 데 이용된다. 와이어 클래스는 이들 종단점 사이에 구축될 수 있는 관계를 기술하는 데 이용된다.

b) 애플리케이션에 적용되는 설정 및 애플리케이션이 배포되는 방법이다. 컴포넌트 클래스는 애플리케이션을 구축하는 데 이용될 수 있는 빌딩 블록을 정의한다. 컴포넌트 클래스는 그 컴포넌트에 특유한 양상을 제어하는 데 이용될 수 있는 설정을 정의하며, 상기 컴포넌트를 배포하는 데 제공될 수 있는 파일 및 스크립트들에 대한 스키마를 정의한다.

c) 애플리케이션이 정확히 기능하기 위해 의존하는 대상이다. 정확히 동작하기 위해서 컴포넌트는 목표 환경에 이미 존재하는 소정의 기능에 의존할 수 있다. 그 예로서는 IIS에 의존하는 웹 서비스가 있다. 이러한 요건은 자원간의 호스팅 관계로서 표현한다. 이러한 관계를 이용하여, 특정한 애플리케이션이 특정 환경에서 실행될지 여부를 미리 체크할 수 있도록 해 주는 일단의 자원 유형에 대하여 의존 관계 트리(dependency tree)를 구축할 수 있다.

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

애플리케이션 유형은 자원 스페이스에서 정의된 자원 클래스를 이용하여 구축될 수 있다. 포트 유형 및 와이어 유형은 이들 클래스로부터 파생되어 애플리케이션에 특유한 통신 링크가 모델링되고, 컴포넌트 유형이 구축되어 애플리케이션의 별개의 부분들이 모델링된다.

포트 유형은 애플리케이션에 특유한 양상을 기술하는 통신 종단점이다. 포트 자원을 취하여 이것의 애플리케이션 내에서의 용도에 특유한 정보를 제공한다. SOAP 자원을 취하여 애플리케이션이 공개하는 기능을 정의하는 WSDL 파일을 제공하는 포트 유형이 그 예이다.

와이어 유형은 애플리케이션 특유의 통신 경로를 정의한다. 와이어 유형은 특정한 와이어 자원을 호환 가능한 두 애플리케이션 종단점을 연결하는 것으로 한정시킨다. 예컨대 SOAP 와이어 자원을 취하여 이를 앞서 정의한 SOAP 포트 유형을 연결하는 것으로 한정시킬 수 있다.

컴포넌트 유형은 독립적으로 배포될 수 있고 머신의 경계에 걸쳐 분산될 수 있는 애플리케이션의 부분들을 모델링하는 데 사용된다. 예컨대 웹 프론트엔드(web frontend) 및 데이터베이스 백엔드(database backend)를 갖는 애플리케이션은 몇몇의 컴포넌트 유형으로 이루어질 수 있다. 이러한 경우 웹 서비스 자원을 취하여 이를 웹 프론트엔드 컴포넌트 유형을 생성하는 데 사용할 수 있고, 데이터베이스 자원을 취하여 데이터베이스 백엔드 컴포넌트 유형을 생성하는 데 사용할 수 있다. 그 후 적합한 포트 유형을 컴포넌트 유형에 추가함으로써 애플리케이션 인터페이스를 모델링한다. 이것을 포트 멤버라 칭한다.

여기서 사용되는 복합 컴포넌트 유형은 새로운 컴포넌트 유형을 함께 형성하는 그룹 컴포넌트 유형이다. 컴포넌트 유형을 복합 컴포넌트 유형 내에서 사용한 것을 컴포넌트 멤버라 칭한다. 앞서 정의한 와이어 유형을 이용하여, 컴포넌트 멤버가 공개하는 인터페이스를 다른 멤버에 대하여 연결시킨다. 이들은 복합 컴포넌트의 와이어 멤버가 된다.

복합 컴포넌트가 컴포넌트와 같이 보이도록 하기 위해서는, 이들이 인터페이스, 성능(capability) 및 요건을 컴포넌트와 마찬가지로 공개해야 할 필요가 있다. 이는 복합 컴포넌트의 컴포넌트 멤버로부터 포트 멤버들의 부분 집합(subset)을 위임하여 보냄(delegate out)으로써 이루어진다.

컴포넌트의 요건을 충족하기 위해서는 일치하는 성능을 갖는 다른 컴포넌트에 대하여 그 컴포넌트를 바인딩해야 한다. 이를 프로세스 바인딩이라 칭한다.

예시 구현(Exemplary Implementation)

이 섹션에서는 SDM 모델의 요소를 정의하는 데 이용되는 XML 스키마에 관하여 설명한다. 설정은 애플리케이션 및 자원 모두에 의해 사용되므로 이를 먼저 설명하고, 이어서 자원 클래스를 설명하고, 다음으로 애플리케이션을 설명한 후 마지막으로 인스턴스 스페이스를 설명한다.

네임 부여(Naming)

네임 스페이스는 클래스 및 유형이 정의될 수 있는 네임 부여 범위(naming scope)를 정의하는 데 이용된다. 네임 스페이스 내에서 모든 클래스 및 유형 네임은 고유하다. 네임 스페이스는 네임, 버전 및 암호 키(cryptographic key; 네임 스페이스의 콘텐츠의 유효성을 검증하는 데 사용될 수 있음)에 의해 정의된다.

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

파일 버전은 N.N.N.N(0<N<65535) 형태의 네 부분의 숫자에 의해 정의된다.

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

공개 키 토큰(public key token)은 16자의 16진 문자열(hex string)이며, 공개/개인 키 쌍 중 공개 부분을 식별한다. 문서는 개인 키를 이용하여 서명되며, 이에 의해 문서의 사용자는 공개 키를 이용하여 그 콘텐츠를 검증할 수 있다.

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

네임 스페이스 내의 단순 네임(simple name)을 문자열을 이용하여 구축한다. 네임 스페이스는 다른 네임 스페이스를 현재의 네임 스페이스으로 도입(import)한 후 별칭(alias)을 그 네임 스페이스과 연관시킴으로써 다른 네임 스페이스를 참조할 수 있다.

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

클래스 및 유형에 대한 참조는 현재의 네임 스페이스에서 정의된 객체를 지칭하는 단순 네임이거나 또는 다른 네임 스페이스에서 정의된 객체를 식별하기 위하여 별칭 및 단순 네임 모두를 이용하는 복합 네임(compound name)이다.

설정(Settings)

자원 클래스 및 애플리케이션 유형 모두는 설정 스키마를 공개할 수 있다. 이 스키마는 새로운 포트, 와이어 또는 컴포넌트 유형이 클래스로부터 생성되는 경우나, 포트 유형이 컴포넌트 유형에 추가되는 경우나, 또는 와이어 유형 또는 컴포넌트 유형이 복합 컴포넌트 유형에서 사용되는 경우에 제공될 수 있는 값을 기술하는 데 이용된다.

설정 스키마(Settings schema)

설정 스키마는 XSD를 이용하여 기술된다. 최초 릴리즈(release)를 위해, 단일 유형으로 제약되는 XSD의 부분 집합 및 요소 유형의 리스트를 이용한다.

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

설정값(Setting Values)

설정값은 유형이 클래스에 기초하여 생성되는 경우 또는 유형이 컴포넌트 또는 복합 컴포넌트 내에서 사용되는 경우에 제공된다. 설정값은 적합한 설정 스키마에 따르는 XML 블록이다.

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

설정 플로우(Settings flow)

설정 플로우는 설정값이 컴포넌트 유형으로부터 컴포넌트 유형의 멤버로 전달되도록 하는 데 사용된다. 설정 플로우는 유형에 의해 정의된 설정 스키마로부터 값을 선택하는 설정값 섹션의 XPATH를 이용하여 구현된다.

SDM 네임 스페이스에서 정의된 특별한 속성(attribute)을 이용하여, 콘텐츠를 흘려보내고자 하는 값을 식별한다. 이 속성이 어떠한 요소 상에 존재하는 경우, 그 속성값은 유형에 대한 설정 스키마로의 XPath인 것으로 간주된다.

설정 제약(Setting Constraints)

설정 제약은 설정값의 유효성을 검증 및 제약하는 데 사용된다. 예컨대 IIS 서버는 자신이 호스팅하는 모든 웹 서비스에 대하여 이들의 설정값이 특정한 값 또는 특정 범위의 값으로 한정되기를 요구할 수 있다. XPATH(또는 완전히 지원되는 경우 XQUERY)는 설정값의 유효성을 검증하는 데 이용된다. 이하의 질의 양식(forms of query)이 지원된다.

- 경로가 존재해야 함

- 경로가 존재하지 않아야 함

- 경로가 존재하는 경우[(경로가 존재해야 함|경로가 존재하지 않아야 함)^*]

첫 번째 양식을 이용하여 특정한 값 또는 값의 집합으로 설정이 설정될 것을 요구할 수 있으며, 두 번째 양식을 이용하여 어떤 값 또는 값의 집합으로 설정이 설정되지 않을 것을 요구할 수 있으며, 세 번째 양식을 이용하여 함께 설정되어야할 설정의 조합을 필요로 하는 설정 사이의 관계를 구축할 수 있다.

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

경로가 존재하지 않는 경우 이를 처리하기 위한 옵션이 공개될 필요가 있다. 이하는 설계자로 하여금 오류를 야기하거나, 값을 삽입하거나 또는 테스트를 무시하는 것을 선택할 수 있도록 해 준다.

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

예시

이하는 컴퓨터 클래스가 공개할 수 있는 단순한 스키마 모델링 값이다. 이 스키마는 노드 아래의 설정 그룹 및 세 특성을 식별하는 단일 최상위 노드(top level node)를 갖는다.

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

이하의 값을 유형 내에서 스키마에 대하여 제공할 수 있다.

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

유형이 사용된 경우에 설정값을 제공하고자 하면, 설정 플로우를 이용한다.

이들 값에 대하여 제약이 기록될 수 있다. 예컨대 첫 번째는 단순한 mustExist 제약이다. 두 번째 제약은 중첩 제약(nested constraints)을평가(evaluate)할지 여부를 결정하기 위한 테스트를 이용한다.

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

자원(Resources)

베이스 클래스(Base Class)

모든 자원 클래스는 클래스로부터 파생된다. 이들은 설정 스키마, 배포 스키마 및 네임 및 계층 속성을 공유한다. 설정 스키마는 그 클래스에 기초한 유형에 적용되는 설정, 이들이 취할 수 있는 값, 그리고 각각의 기술(description)을 기술한다. 배포 스키마는 그 자원에 기초한 유형을 배포하는 데 필요한 정보를 기술한다. 계층 속성은 자원은 설계 스페이스에 있는 한 계층에 대하여 자원을 연관시킨다. 네임 속성은 네임 스페이스 내에서 클래스에게 고유의 네임을 부여하는 데 사용된다.

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

배포 스키마에 대해서, 네임 스페이스는 정의되지 않은 상태로 남는다. 스키마에 대한 제약은 그 전체가 클래스에 대한 설치자의 책임이다.

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

배포 섹션의 일부로서 제공되는 값은 관련 배포 스키마와 일치해야 한다.

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

계층 속성은 4개의 계층 유형을 열거한 것이다. 애플리케이션 계층은 데이터베이스 및 웹서버와 같은 고수준 애플리케이션 컴포넌트를 포함한다. 서비스 계층은 IIS 및 SQL과 같은 미들웨어(middleware) 서비스를 포함한다. 네트워크 계층은 운영 체제, 기억장치 및 네트워크 정의를 포함한다. 하드웨어 계층은 데이터 센터의 하드웨어 컴포넌트의 정의를 포함한다.

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

포트 클래스

포트 클래스는 자원 기초 유형에서 앞서 정의된 어떤 정보도 포함하지 않는다.

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

컴포넌트 클래스

컴포넌트 클래스는 허용되는 포트 클래스들의 리스트를 추가함으로써 베이스 클래스를 확장시킨다.

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

포트 클래스들의 리스트는 열리거나 닫힐 수 있으며, 닫혀 있는 경우에는 리스트에 나타나 있는 클래스에 기초한 포트 유형만이 관련 컴포넌트 유형에서 사용될 수 있다. minOccurs 및 maxOccurs 속성은 이들 포트 유형들 중 하나가 사용될 수 있는 횟수를 정의한다.

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

와이어 클래스

와이어 클래스도 또한 허용되는 포트 클래스들의 리스트를 추가함으로써 베이스 클래스를 확장시킨다. 이 경우 리스트는 와이어 유형과 관련될 수 있는 포트 유형의 클래스들을 정의한다.

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

호스팅 관계

호스팅 관계는 소스 클래스, 목표 클래스 및 설치자를 식별하는 트리플(triple)을 정의한다. 관계의 존재는 소스 클래스에 기초한 유형의 인스턴스가 목표 클래스에 기초한 유형의 인스턴스 및 상기 관계와 관련된 설치자를 이용하여 생성될 수 있음을 가리킨다. 목표 클래스는 컴포넌트 클래스이어야 한다.

예컨대 웹 서비스는 IIS 클래스 및 웹 서비스 설치자와의 호스팅 관계에서 소스 클래스일 수 있다. 이 경우 상기 관계는 설치자를 이용하여 MyIIS 유형상에 MyWebService 유형의 인스턴스를 생성할 수 있음을 가리킨다. 애플리케이션 스페이스 및 인스턴스 스페이스 모두에 존재하는 제약을 평가하기 전까지는, 관계를 생성할 수 있을지 여부를 알지 못한다.

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

설치자는 네임, 코드 유형 및 설치자를 구현하는 바이너리에 대한 링크에 의해 식별된다.

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

예시

이들 예는 확장된 4 계층의 예시로부터 발췌된 것이다. 세부 사항을 위해서는 완전한 예시 파일을 참조하면 된다.

우선 데이터베이스에 대한 액세스를 모델링하기 위해 소정의 포트 클래스들을 생성한다. 이 경우 서버 포트 및 클라이언트 포트가 존재한다.

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

그 후 상기 두 포트 클래스들 사이의 통신 링크를 모델링하는 와이어 클래스를 생성한다. 와이어 클래스는 앞서 정의된 두 포트 클래스에 대한 설정 및 참조를 갖는다. 이 경우 와이어 제약은 접속에 대해서 오직 하나의 서버가 있어야 하며, 클라이언트 포트는 복수의 서버에 걸쳐 접속들의 로드 밸런스(load balance)를 어떻게 해야할지 알지 못한다는 사실을 모델링한다. 더욱 복잡한 와이어 구현에 의해 복수의 서버를 허용할 수 있고, 접속을 해결하기 위해 소정 형태의 관리를 구현할 수 있도록 해 준다.

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

마지막으로 데이터베이스를 모델링하는 컴포넌트 클래스를 생성한다. 이 클래스는 설정 및 배포 스키마를 가지며, 이 클래스에 기초한 컴포넌트 유형상에 존재할 수 있는 포트들을 식별한다.

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

이러한 모든 컴포넌트들은 호환 가능한 호스트 유형에 대하여 매핑될 필요가 있다. 이 경우 SQL 서버는 서버 포트에 대한 호스트로서 작용하고, 데이터베이스 및 IIS는 SQL 클라이언트 포트에 대한 호스트로서 작용한다. 이들 클래스는 미들웨어로 별칭되는 별개의 네임 스페이스에서 정의된다.

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

애플리케이션

애플리케이션 개발자는 컴포넌트, 포트 및 와이어 유형을 애플리케이션 스페이스에서 생성함으로서 그의 애플리케이션을 모델링한다. 이들 유형은 개발자가 작업하고 있는 계층과 일치하는 클래스를 선택하고 그 클래스에 대한 값을 공급함으로써 생성된다.

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

모든 애플리케이션 유형 스키마는 이하의 애플리케이션 베이스 스키마를 기초로 한다. 베이스 스키마 속성은 상기 유형이 기초한 클래스 및 그 유형의 네임을 식별한다. 스키마의 본체(body)에서는 그 유형이 배포될 수 있도록 해 주는 배포값과, 관련 클래스 상의 설정 스키마에 대한 설정을 식별한다. 유형은 또한 그 유형이 다른 유형 내에서 사용되는 경우에 제공될 수 있는 값들을 식별하는 새로운 설정 스키마를 정의한다. 마지막으로 베이스 유형은 호스트 제약을 위한 섹션을 포함한다. 이 섹션은 이 유형과 관련된 클래스를 위한 자원 스페이스 내에 존재하는 호스트 관계에 기초한, 그 유형에 대한 가능한 호스트 상의 제약을 식별한다.

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

hostConstraints 섹션은 그 유형과 관련된 클래스를 호스팅할 수 있는 클래스 각각에 대한 일단의 제약을 포함한다. 이들 클래스는 자원 스페이스 내의 호스트 관계에 의해 식별된다. 이들 클래스와 관련된 제약은 설정 스키마 및 클래스에 관한 것이다. 제약의 양식은 앞서 정의된 바 있다.

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

포트 유형

포트 유형은 단순히 베이스 유형을 이용한다. 포트 유형과 관련된 더 이상의 정보가 존재하지 않는다.

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

와이어 유형

와이어 유형은 베이스 유형을 확장함으로써 허용 가능한 포트 유형의 리스트를 추가한다. 이들 포트 유형을 사용하는 것은 복합 컴포넌트 내에서 와이어 유형을 이용하는 것과 관련될 수 있다. 와이어 유형을 이러한 방식으로 정의함으로써, 애플리케이션 설계자는 단지 호환 가능한 포트 유형에 대하여 와이어 유형을 생성하는 것에 의해 그의 애플리케이션의 부분들 사이의 허용 가능한 일단의 접속을 제약할 수 있다.

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

컴포넌트 유형

컴포넌트 유형은 베이스 유형을 확장함으로써 포트 멤버의 리스트 및 호스팅되는 클래스의 리스트를 추가한다.

각 포트 멤버는 기존의 포트 유형을 사용한 것이다. 호스팅된 클래스의 리스트는 그 컴포넌트가 호스팅할 수 있는 클래스들을 식별한다. 이들 클래스들은 자원 스페이스의 호스트 관계에 의해 식별되는 클래스들의 부분 집합이며, 이 경우 이러한 유형의 클래스는 잠재적인 호스트로서 식별된다.

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

포트 리스트에 있는 포트 멤버 각각은 네임 및 유형에 의해 식별된다. 포트 네임은 컴포넌트 내에서 고유해야 한다. 포트 유형은 이러한 컴포넌트 유형과 관련된 컴포넌트 클래스에서 허용되는 관련 포트 클래스를 가져야 한다. 각 포트 멤버에 대하여, 포트 유형에 의해 정의되는 스키마와 일치하는 설정의 리스트를 제공할 수 있다.

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

호스팅된 클래스 리스트(hosted classes list)의 각각의 클래스에 대하여 제약 리스트(a list of constraints)를 결합할 수 있다. 이러한 제약들은 호스팅된 클래스의 설정 스키마(setting schema)에 관하여 쓰여진 것이다.

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

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

복합 컴포넌트 유형(본 명세서에서는 복합 컴포넌트라고 칭한다)은 새로운 컴포넌트 유형을 정의한다. 복합 컴포넌트를 정의할 때, 그 유형의 멤버들이 같은 곳에 배치(co-located)되어야 한다고 명시할 것인지의 여부를 선택할 수 있다. 만약 멤버들이 같은 곳에 배치되어 있다면, 상기 유형이 배포되는 경우 그 유형의 모든 멤버들은 단일 호스트 상에 배포되어야 한다. 복합 컴포넌트는 또한 컴포넌트 멤버의 리스트, 와이어 멤버의 리스트, 상기 컴포넌트가 위임(delegate)하는 포트를 정의하는 섹션 및 상기 컴포넌트가 호스팅할 수 있는 클래스를 식별하는 리스트를 포함한다.

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

컴포넌트 리스트는 이미 정의된 컴포넌트 유형을 사용하는 것을 식별하며 이를 상기 복합 컴포넌트의 컴포넌트 멤버라고 부른다. 각각의 멤버는 복합 컴포넌트 내의 고유한 네임, 그 멤버를 정의하는 유형에 대한 참조 및 그 멤버가 싱글톤(singleton)인지 아닌지를 지시하는 플래그를 갖는다.

컴포넌트 멤버가 싱글톤이라고 표시된 경우에는, 그 멤버를 포함하는 복합 컴포넌트의 인스턴스에서 이 컴포넌트 멤버의 인스턴스는 오직 하나만이 존재할 수 있다. 그것이 싱글톤이라고 표시되지 않은 경우에는, 멤버의 인스턴스들은 로드변화와 같은 외적 요인에 따라 생성되고 삭제될 수 있다. 이는 싱글톤이 아닌 멤버와 연결된 컴포넌트 멤버라면 어느 멤버든지 런타임(runtime)에 그 싱글톤이 아닌 멤버의 인스턴스를 하나 또는 그 이상 볼 수 있다는 것을 의미한다.

각각의 컴포넌트 멤버는 또한 관련된 컴포넌트 유형에서 정의된 설정 스키마에 대한 설정 값(setting values)을 제공할 수 있다.

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

복합 컴포넌트에서 와이어 유형을 사용하는 것을 와이어 멤버라고 한다. 각각의 와이어 멤버는 그 복합 컴포넌트에 대하여 고유한 네임(name)으로서, 관련된 와이어 유형을 식별시켜주는 네임을 갖는다. 와이어 멤버는 또한 와이어 유형에서 정의된 설정 스키마에 대한 설정 값을 제공할 수 있다.

와이어 멤버의 주된 역할은 복합 컴포넌트 내에서 컴포넌트 멤버간의 연결을 식별하는 것이다. 이는 와이어 멤버에 포트 참조를 덧붙이는 방법으로 행해진다. 각각의 포트 참조는 복합 컴포넌트 내의 컴포넌트 멤버 상의 포트를 식별한다. 참조 포트의 포트 유형은 상기 와이어 유형과 관련된 포트 유형과 일치(match)해야 한다.

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

포트 참조는 컴포넌트 멤버를 포함하는 복합 컴포넌트 내에서 그 컴포넌트 멤버를 식별한다. 포트 네임은 상기 컴포넌트 멤버와 관련된 컴포넌트 유형 상의 포트 멤버의 네임이다.

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

복합 컴포넌트와 관련되고 포트 멤버가 바인딩할 수 있는 코드가 없기 때문에 복합 컴포넌트는 포트 유형을 직접적으로 사용할 수 없다. 그 대신 복합 컴포넌트의 컴포넌트 멤버들로부터 포트 멤버들이 위임을 받는다(delegate out). 이는 복합 컴포넌트가 컴포넌트 유형으로서 사용될 때 이러한 포트들이 그들이 복합 컴포넌트에 속하는 것처럼 나타나는 것을 의미한다.

포트가 위임을 받으면, 먼저 컴포넌트 멤버를 식별하고 그 다음에 그 컴포넌트 내의 포트 멤버를 식별함으로써 그 포트가 식별된다. 이 과정의 일부로서 포트의 네임이 바뀔 수도 있는데 이는 상이한 컴포넌트 멤버들로부터 동일한 네임을 갖는 포트들이 위임을 받는 경우 그 네임이 서로 충돌하는 것을 막기 위한 것이다.

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

다양한 범위의 상이한 클래스에 대하여 서비스를 제공할 수 있는 호스트를 구성하기 위하여 복합 컴포넌트가 그의 컴포넌트 멤버들로부터 호스팅된 클래스 선언(hosted class declarations)을 공개하는 것이 허용된다. 복합 컴포넌트가 컴포넌트 유형으로서 사용되는 때에는, 이 복합 컴포넌트는 모든 선언된 클래스에 대하여 호스트로서의 역할을 할 수 있다고 보여진다.

이러한 호스팅된 클래스 선언을 공개하기 위하여 포트 멤버를 위임했던 방법과 유사한 방법으로 위임(delegation)이 사용된다. 호스팅된 클래스를 포함하는 컴포넌트 멤버를 식별하고, 그 후 그 컴포넌트가 호스팅할 수 있다고 요청하는 클래스를 식별한다.

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

바인딩

바인딩은 특정한 복합 컴포넌트의 멤버에 대하여 호스트를 식별하는 프로세스이다. 이는 애플리케이션과 그 애플리케이션이 호스팅될 환경 사이의 호환성을 검사하고 그 애플리케이션을 배포하기 위하여 행해진다. 애플리케이션과 호스트 환경은 모두 복합 컴포넌트를 사용하여 모델링되며 따라서 바인딩 프로세스는 멤버간의 연결 토폴로지(connection topology)를 지원(support)하는 서로 대응(match)하는 멤버를 양 컴포넌트로부터 찾는 것이다.

멤버에 대하여 호환 가능한 호스트를 식별하기 위하여, 리소스 공간에서 클래스들 사이의 관계의 검토를 시작한다. 먼저 와이어 또는 컴포넌트 멤버의 유형을 검토한 후 그 멤버와 관련된 클래스를 식별한다. 그 다음에는 호스트 컴포넌트에서 호스트 컴포넌트의 멤버들의 컴포넌트 유형과 관련된 호환 가능한 클래스를갖는 컴포넌트 멤버들을 찾는다. 그 후 상기 (와이어 또는 컴포넌트) 멤버와 관련된 유형 상의 호스트 제약을 검토하고 그 제약이 호스트 멤버의 유형 상의 설정과 대응하는지를 본다. 그 다음에는 이와 반대로 호스트 멤버의 유형 상의 hostedClass 제약을, 호스팅하기를 원하는 멤버의 유형 상의 설정에 대하여 점검한다.

컴포넌트 멤버를 대응시키려고 하는 경우에는, 그 컴포넌트 멤버의 유형을 갖는 모든 포트 멤버들이 그 컴포넌트 멤버에 대한 어떠한 잠재적인 호스트 상에라도 호스팅될 수 있는지를 점검할 필요가 있다.

와이어 멤버를 대응시키려고 하는 경우에는, 호스팅하려고 하는 복합 컴포넌트의 컴포넌트 멤버를 위하여 선택한 호스트들간의 경로 상에 존재하는 컴포넌트 멤버라면 어느 것이든지 대응시켜 보아야 한다.

앞선 예에서 설명된 포트 클래스를 기반으로, 두 가지의 포트 유형을 생성한다.

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

이러한 유형들은 와이어 유형에 의해 주어진다.

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

이제 데이터베이스 클래스에 기초한 컴포넌트 유형이 생성된다. 데이터 베이스 유형은 하나의 서버 데이터 포트를 공개한다.

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

이러한 유형들 중 일부를 사용하는 복합 컴포넌트 유형을 생성할 수 있었다. 이하의 복합 컴포넌트는 세 가지 컴포넌트 유형을 사용한다. 제1 유형 UserPages는 두 접근점(access point)을 갖는 웹 서비스를 나타내고 제2 유형 QueryManagement는 미들 계층 논리 컴포넌트(middle tier logic component)이며 마지막 유형은 우리의 데이터베이스 유형이다. 이러한 컴포넌트들을 두 와이어 유형, 즉 UserData 및 QueryManager를 사용하여 연결한다. 데이터 와이어는 미들 계층을 데이터베이스와 연결하고 쿼리 와이어는 프론트엔드(frontend)를 미들 계층와연결한다. 그 후 두 포트, 즉 signup 및 enquiry를 위임(deligation)을 사용하여 프론트엔드로부터 공개시킨다.

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

SDM 문서 구조

SDM 문서는 문서의 네임스페이스(namespace)를 정의하는 강한 본질을 지니고 있다. SDM 문서는 다른 네임스페이스에 대한 참조의 리스트를 가져 온다(import). 이 문서는 또한 문서 소유자, 회사명 및 수정된 날짜와 같은 문서의 특정속성(document specific attribute)을 확인하게 하는 정보 섹션을 포함한다. 문서는 그 다음에 포트, 와이어 및 컴포넌트 클래스들의 리스트, 이어서 호스트 관계들의 리스트, 차례로 이어서 포트, 와이어 및 컴포넌트 유형들의 리스트를 포함한다.

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

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

관련된 XSD(Associated XSD)

이하는 변화 요청(change request)에 대한 하나의 예시이다.

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

<xs:schema targetNamespace="urn:schemas-microsoft- com:sdmChangeRequest" xmlns="urn:schemas-microsoft- com:sdmChangeRequest" xmlns:settings="urn:schemas-microsoft- com:sdmSettings" xmlns:mstns="http://tempuri.org/XMLSchema.xsd" xmlns:xs="http://www.w3.org/2001/XMLSchema"

elementFormDefault="qualified" version="0.7" id="sdmChangeRequest">

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

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

<xs:complexType name="ChangeRequestType">

<xs:sequence>

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

</xs:sequence>

</xs:complexType>

<xs:complexType name="groupType">

<xs:sequence>

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

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

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

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

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

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

</xs:sequence>

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

</xs:complexType>

<xs:complexType name="addInstanceType">

<xs:sequence>

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

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

<!-- setting values for class -->

<!-- setting values for type -->

</xs:sequence>

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

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

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

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

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

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

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

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

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

<!-- alias for the id that can be filled in when the instance is created.

this name must be unique for all instances of the same member. -->

</xs:complexType>

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

<xs:complexType name="updateInstanceType">

<xs:sequence>

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

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

<!-- setting values for class -->

<!-- setting values for type -->

</xs:sequence>

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

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

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

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

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

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

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

and is immutable -->

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

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

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

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

<!-- alias for the id that can be filled in when the instance is created.

this name must be unique for all instances of the same member. -->

</xs:complexType>

<xs:complexType name="deleteInstanceType">

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

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

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

and is immutable -_cf2 >

</xs:complexType>

<xs:complexType name="addConnectionType">

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

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

</xs:complexType>

<xs:complexType name="deleteConnectionType">

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

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

</xs:complexType>

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

<xs:simpleType name="reference">

<xs:union></xs:union>

</xs:simpleType>

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

<xs:simpleType name="deleteOptionType">

<xs:union></xs:union>

</xs:simpleType>

</xs:schema>

이하는 클래스에 대한 예시적인 구조이다.

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

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

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

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

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

<!-- TODO [BassamT]: Normalize the port class refs, port type refs and port members on wire classs, wire types and wire members -->

<!-- TODO [BassamT]: Is the layer attribute mandatory on a class? -->

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

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

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

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

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

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

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

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

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

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

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

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

<!-- SDM root element -->

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

<xs:element name="sdmClasses">

<xs:complexType>

<xs:sequence>

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

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

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

<xs:complexType>

<xs:sequence>

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

</xs:sequence>

</xs:complexType>

</xs:element>

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

<xs:complexType>

<xs:sequence>

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

</xs:sequence>

</xs:complexType>

</xs:element>

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

<xs:complexType>

<xs:sequence>

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

</xs:sequence>

</xs:complexType>

</xs:element>

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

<xs:complexType>

<xs:sequence>

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

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

</xs:sequence>

</xs:complexType>

</xs:element>

</xs:sequence>

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

</xs:complexType>

</xs:element>

<!-- SDM type library information -->

<xs:complexType name="information">

<xs:annotation>

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

</xs:annotation>

<xs:sequence>

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

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

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

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

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

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

</xs:sequence>

</xs:complexType>

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

<!-- Classes -->

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

<xs:complexType name="baseClass">

<xs:sequence>

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

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

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

<!-- Setting schema -->

</xs:sequence>

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

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

<!-- REVIEW [BassamT] Are these layers just for benefit of tools, or are they

strictly enforced in the SDM model? There are

cases where mixing components from different layers makes

sense. For example, the filter component might be a

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

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

</xs:complexType>

<!-- port class -->

<xs:complexType name="portClass">

<xs:complexContent>

<xs:extension base="baseClass" />

</xs:complexContent>

</xs:complexType>

<!-- Component class -->

<xs:complexType name="componentClass">

<xs:complexContent>

<xs:extension base="baseClass">

<xs:sequence>

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

<xs:complexType>

<xs:sequence>

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

</xs:sequence>

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

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

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

</xs:complexType>

</xs:element>

<!-- this will specify a set of constraints on the set of allowable ports

that can show up on a component type of this meta type. -->

</xs:sequence>

</xs:extension>

</xs:complexContent>

</xs:complexType>

<xs:complexType name="portClassRef">

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

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

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

<!-- singleton implies that there can only be one instance of this port within the parents scope -->

</xs:complexType>

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

<!-- relations -->

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

<xs:complexType name="relation">

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

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

</xs:complexType>

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

<xs:complexType name="protocol">

<xs:complexContent>

<xs:extension base="relation">

<xs:sequence>

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

</xs:sequence>

</xs:extension>

</xs:complexContent>

</xs:complexType>

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

<xs:complexType name="hostRelation">

<xs:complexContent>

<xs:extension base="relation">

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

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

</xs:extension>

</xs:complexContent>

</xs:complexType>

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

<xs:complexType name="installer">

<xs:sequence>

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

</xs:sequence>

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

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

</xs:complexType>

</xs:schema>

이하는 배포 유닛(deployment unit)에 대한 예시적인 구조이다.

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

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

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

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

<!-- an sdm deployment unit imports one or more sdm type files the includes mappings for a subset of the types from the imported file -->

<xs:element name="sdmDeploymentUnit">

<xs:annotation>

<xs:documentation>

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

</xs:documentation>

</xs:annotation>

<xs:complexType>

<xs:sequence>

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

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

</xs:sequence>

</xs:complexType>

</xs:element>

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

<xs:complexType name="deploymentDescription">

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

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

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

</xs:complexType>

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

<xs:complexType name="implementationMap">

<xs:sequence>

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

</xs:sequence>

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

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

</xs:complexType>

</xs:schema>

이하는 인스턴스에 대한 예시적인 구조이다.

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

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

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

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

<xs:element name="sdmInstances">

<xs:complexType>

<xs:sequence>

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

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

<xs:complexType>

<xs:sequence>

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

</xs:sequence>

</xs:complexType>

</xs:element>

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

<xs:complexType>

<xs:sequence>

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

</xs:sequence>

</xs:complexType>

</xs:element>

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

<xs:complexType>

<xs:sequence>

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

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

</xs:sequence>

</xs:complexType>

</xs:element>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:complexType name="import">

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

<xs:attributeGroup ref="identity" />

</xs:complexType>

<!-- ================== Instance Schema =============== -->

<xs:complexType name="instanceBase">

<xs:sequence>

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

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

<!-- setting values for class -->

<!-- setting values for type -->

</xs:sequence>

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

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

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

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

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

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

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

and is immutable -->

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

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

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

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

<!-- alias for the id that can be filled in when the instance is created_par this name must be unique for all instances of the same member. -->

</xs:complexType>

<xs:complexType name="componentInstance">

<xs:complexContent>

<xs:extension base="instanceBase">

<xs:sequence>

<xs:element name="portInstances">

<xs:complexType>

<xs:sequence>

<xs:element name="portInstance" type="instanceRef" />

<!-- the port Instances that I own -->

</xs:sequence>

</xs:complexType>

</xs:element>

</xs:sequence>

</xs:extension>

</xs:complexContent>

</xs:complexType>

<xs:complexType name="compoundComponentInstance">

<xs:complexContent>

<xs:extension base="instanceBase">

<xs:sequence>

<xs:element name="portInstances">

<xs:complexType>

<xs:sequence>

<xs:element name="portInstance" type="instanceRef" />

<!-- the port Instances that I delegate -->

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name="componentInstances">

<xs:complexType>

<xs:sequence>

<xs:element name="componentInstance" type="instanceRef" />

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name="wireInstances">

<xs:complexType>

<xs:sequence>

<xs:element name="wireInstance" type="instanceRef" />

</xs:sequence>

</xs:complexType>

</xs:element>

</xs:sequence>

</xs:extension>

</xs:complexContent>

</xs:complexType>

<xs:complexType name="portInstance">

<xs:complexContent>

<xs:extension base="instanceBase">

<xs:sequence />

</xs:extension>

</xs:complexContent>

</xs:complexType>

<xs:complexType name="wireInstance">

<xs:complexContent>

<xs:extension base="instanceBase">

<xs:sequence>

<xs:element name="portInstances">

<xs:complexType>

<xs:sequence>

<xs:element name="portInstance" type="instanceRef" />

<!-- the ports that Ihave attached -->

</xs:sequence>

</xs:complexType>

</xs:element>

</xs:sequence>

</xs:extension>

</xs:complexContent>

</xs:complexType>

<xs:complexType name="instanceRef">

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

</xs:complexType>

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

<xs:simpleType name="fourPartVersionType">

<xs:annotation>

<xs:documentation>Four part version numbers where the segments are in the range 0-65535 </xs:documentation>

</xs:annotation>

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

<xs:patternvalue="(0|[1-5][0-9]0,4|[7-9][0-9]0,3|6[0-4][0-9]0,3|6[6-9][0-9]0,2|65|65[0-4][0-9]0,2|65[6-9][0-9]?|655|655[0-2][0-9]?|655[4-9]|6553[0-5]?).(0|[1-5][0-9]0,4|[7-9][0-9]0,3|6[0-4][0-9]0,3|6[6-9][0-9]0,2|65|65[0-4][0-9]0,2|65[6-9][0-9]?|655|655[0-2][0-9]?|655[4-9]|6553[0-5]?).(0|[1-5][0-9]0,4|[7-9][0-9]0,3|6[0-4][0-9]0,3|6[6-9][0-9]0,2|65|65[0-4][0-9]0,2|65[6-9][0-9]?|655|655[0-2][0-9]?|655[4-9]|6553[0-5]?).(0|[1-5][0-9]0,4|[7-9][0-9]0,3|6[0-4][0-9]0,3|6[6-9][0-9]0,2|65|65[0-4][0-9]0,2|65[6-9][0-9]?|655|655[0-2][0-9]?|655[4-9]|6553[0-5]?)" />

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="publicKeyTokenType">

<xs:annotation>

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

</xs:annotation>

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

<xs:pattern value="([0-9]|[a-f]|[A-F])16" />

</xs:restriction>

</xs:simpleType>

<xs:attributeGroup name="identity">

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

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

<xs:attribute name="publicKeyToken" type="publicKeyTokenType" use="optional" />

</xs:attributeGroup>

<xs:simpleType name="guid">

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

<xs:pattern value="[0-9a-fA-F]8-[0-9a-fA-F]4-[0-9a-fA-F]4-[0-9a-fA-F]4-[0-9a-fA-F]12" />

</xs:restriction>

</xs:simpleType>

</xs:schema>

이하는 매핑(mapping)에 대한 예시적인 구조이다.

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

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

<!-- REVIEW [BassamT]: Do we allow mappings to components within the same compound component? -->

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

<xs:element name="logicalPlacement">

<xs:annotation>

<xs:documentation>

This file contains the mapping information between SDM members.

Mappings are constructed in a outside in fashion, first binding the outer compound component, then its members and so on.

</xs:documentation>

</xs:annotation>

<xs:complexType>

<xs:sequence>

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

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

<xs:complexType>

<xs:sequence>

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

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

</xs:sequence>

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

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

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

</xs:complexType>

</xs:element>

</xs:sequence>

</xs:complexType>

</xs:element>

<!-- a member binding may be a:

1. compound component member - in which case we bind all the members and wires of the compound component

2. a simple component member - in which case we bind the component and its ports

3. a port member - in which case we bind it to a port and there is no further binding

-->

<xs:complexType name="memberBinding">

<xs:sequence>

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

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

</xs:sequence>

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

<!-- if a target member is not provided then the component must be a compound component and its members

will be bound to the members of the compoundcomponent that its parent is bound to

If a target member is provided and we are binding a compound component, then the ports on the

source compound component must be able to be bound to the ports on the target compound component-->

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

</xs:complexType>

<!-- wires are bound to a path in the target compound component.

This path consists of port, wire and component instances-->

<xs:complexType name="wireBinding">

<xs:sequence>

<xs:element name="path">

<xs:complexType>

<xs:sequence>

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

<xs:complexType>

<xs:attributename="name" type="xs:string" />

</xs:complexType>

</xs:element>

</xs:sequence>

</xs:complexType>

</xs:element>

</xs:sequence>

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

</xs:complexType>

<!-- import -->

</xs:schema>

이하는 네임(name)에 대한 예시적인 구조이다.

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

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

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

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

<xs:complexType name="import">

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

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

<xs:attributeGroup ref="Identity" />

</xs:complexType>

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

<xs:attributeGroup name="Identity">

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

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

<xs:attribute name="publicKeyToken" type="publicKeyTokenType" use="optional" />

</xs:attributeGroup>

<xs:attributeGroup name="namespaceIdentity">

<xs:attributeGroup ref="Identity" />

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

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

</xs:attributeGroup>

<!-- simple version number -->

<xs:simpleType name="fourPartVersionType">

<xs:annotation>

<xs:documentation>Four part version numbers where the segments are in the range 0-65535 </xs:documentation>

</xs:annotation>

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

<xs:pattern value="(0|[1-5][0-9]0,4|[7-9][0-9]0,3|6[0-4][0-9]0,3|6[6-9][0-9]0,2|65|65[0-4][0-9]0,2|65[6-9][0-9]?|655|655[0-2][0-9]?|655[4-9]|6553[0-5]?).(0|[1-5][0-9]0,4|[7-9][0-9]0,3|6[0-4][0-9]0,3|6[6-9][0-9]0,2|65|65[0-4][0-9]0,2|65[6-9][0-9]?|655|655[0-2][0-9]?|655[4-9]|6553[0-5]?).(0|[1-5][0-9]0,4|[7-9][0-9]0,3|6[0-4][0-9]0,3|6[6-9][0-9]0,2|65|65[0-4][0-9]0,2|65[6-9][0-9]?|655|655[0-2][0-9]?|655[4-9]|6553[0-5]?).(0|[1-5][0-9]0,4|[7-9][0-9]0,3|6[0-4][0-9]0,3|6[6-9][0-9]0,2|65|65[0-4][0-9]0,2|65[6-9][0-9]?|655|655[0-2][0-9]?|655[4-9]|6553[0-5]?)" />

</xs:restriction>

</xs:simpleType>

<!-- public key for verifying signed docs -->

<xs:simpleType name="publicKeyTokenType">

<xs:annotation>

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

</xs:annotation>

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

<xs:pattern value="([0-9]|[a-f]|[A-F])16" />

</xs:restriction>

</xs:simpleType>

</xs:schema>

이하는 설정(setting)에 대한 예시적인 구조이다.

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

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

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

<!-- settings schema, values and constraints -->

<xs:complexType name="openSchema">

<xs:sequence>

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

</xs:sequence>

</xs:complexType>

<xs:complexType name="settingSchema">

<xs:sequence>

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

</xs:sequence>

</xs:complexType>

<xs:complexType name="settingValues">

<xs:sequence>

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

</xs:sequence>

</xs:complexType>

<!-- constraints -->

<xs:attributeGroup name="testAttributes">

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

<xs:attribute name="ifNullPath" type="ifNullPath" />

<xs:attribute name="error" type="xs:int" />

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

</xs:attributeGroup>

<xs:complexType name="simpleTest">

<xs:attributeGroup ref="testAttributes" />

</xs:complexType>

<xs:complexType name="settingConstraints">

<xs:sequence>

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

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

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

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

</xs:sequence>

</xs:complexType>

<xs:complexType name="nestedTest">

<xs:sequence>

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

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

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

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

</xs:sequence>

<xs:attributeGroup ref="testAttributes" />

</xs:complexType>

<xs:complexType name="deploymentSchema">

<xs:sequence>

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

</xs:sequence>

</xs:complexType>

<xs:complexType name="deploymentValues">

<xs:sequence>

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

</xs:sequence>

</xs:complexType>

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

<xs:simpleType name="ifNullPath">

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

<xs:enumeration value="skip" />

<xs:enumeration value="override" />

<xs:enumeration value="returnError" />

</xs:restriction>

</xs:simpleType>

</xs:schema>

이하는 유형에 대한 예시적인 구조이다.

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

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

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

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

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

<!-- TODO [BassamT]: Normalize the port class refs, port type refs and port members on wire classs, wire types and wire members -->

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

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

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

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

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

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

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

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

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

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

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

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

<!-- SDM root element -->

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

<xs:element name="sdmTypes">

<xs:annotation>

<xs:documentation>SDM root element. It is a container for SDM types.</xs:documentation>

</xs:annotation>

<xs:complexType>

<xs:sequence>

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

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

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

<xs:complexType>

<xs:sequence>

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

</xs:sequence>

</xs:complexType>

</xs:element>

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

<xs:complexType>

<xs:sequence>

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

<xs:elementname="compoundComponentType" type="compoundComponentType" minOccurs="0" maxOccurs="unbounded" />

</xs:sequence>

</xs:complexType>

</xs:element>

</xs:sequence>

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

</xs:complexType>

</xs:element>

<!-- SDM type library information -->

<xs:complexType name="information">

<xs:annotation>

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

</xs:annotation>

<xs:sequence>

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

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

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

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

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

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

</xs:sequence>

</xs:complexType>

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

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

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

<xs:complexType name="baseType">

<xs:annotation>

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

</xs:annotation>

<xs:sequence>

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

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

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

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

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

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

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

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

that is specified on the unit. -->

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

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

also that we will support flowing setting values to the settings

on the unit. -->

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

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

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

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

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

more than one class that is hosted here. -->

</xs:sequence>

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

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

</xs:complexType>

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

<!-- Constraints -->

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

<xs:complexType name="hostConstraints">

<xs:annotation>

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

</xs:annotation>

<xs:sequence>

<xs:element name="hostConstraint">

<xs:complexType>

<xs:sequence>

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

</xs:sequence>

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

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

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

</xs:complexType>

</xs:element>

</xs:sequence>

</xs:complexType>

<xs:complexType name="hostedClassesList">

<xs:annotation>

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

</xs:annotation>

<xs:sequence>

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

<xs:complexType>

<xs:sequence>

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

</xs:sequence>

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

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

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

</xs:complexType>

</xs:element>

</xs:sequence>

</xs:complexType>

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

<!-- Ports -->

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

<xs:complexType name="portType">

<xs:complexContent>

<xs:extension base="baseType">

<xs:sequence>

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

</xs:sequence>

</xs:extension>

</xs:complexContent>

</xs:complexType>

<xs:complexType name="portConstraints">

<xs:annotation>

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

</xs:annotation>

<xs:sequence>

<xs:element name="portConstraint">

<xs:complexType>

<xs:sequence>

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

</xs:sequence>

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

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

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

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

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

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

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

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

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

</xs:complexType>

</xs:element>

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

port to identify sets of optional port endpoints.

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

</xs:sequence>

</xs:complexType>

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

<!-- Components -->

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

<xs:complexType name="componentType">

<xs:complexContent>

<xs:extension base="baseType">

<xs:sequence>

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

</xs:sequence>

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

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

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

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

</xs:extension>

</xs:complexContent>

</xs:complexType>

<xs:complexType name="portsList">

<xs:sequence>

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

<xs:complexType>

<xs:sequence>

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

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

specified on the type -->

</xs:sequence>

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

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

</xs:complexType>

</xs:element>

</xs:sequence>

</xs:complexType>

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

<!-- Compound Component Types. -->

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

<xs:complexType name="compoundComponentType">

<xs:sequence>

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

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

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

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

<!-- delegate ports -->

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

component. -->

</xs:sequence>

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

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

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

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

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

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

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

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

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

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

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

</xs:complexType>

<xs:complexType name="components">

<xs:sequence>

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

<xs:complexType>

<xs:sequence>

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

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

specified on the type -->

</xs:sequence>

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

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

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

</xs:complexType>

</xs:element>

</xs:sequence>

</xs:complexType>

<xs:complexType name="wires">

<xs:sequence>

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

<xs:complexType>

<xs:sequence>

<xs:element name="members">

<xs:complexType>

<xs:sequence>

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

</xs:sequence>

</xs:complexType>

</xs:element>

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

specified on the type -->

</xs:sequence>

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

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

</xs:complexType>

</xs:element>

</xs:sequence>

</xs:complexType>

<xs:complexType name="delegatePorts">

<xs:sequence>

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

<xs:complexType>

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

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

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

</xs:complexType>

</xs:element>

</xs:sequence>

</xs:complexType>

<xs:complexType name="componentPortRef">

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

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

</xs:complexType>

<xs:complexType name="delegateHostedClasses">

<xs:sequence>

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

<xs:complexType>

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

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

</xs:complexType>

</xs:element>

</xs:sequence>

</xs:complexType>

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

<!-- SimpleTypes. -->

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

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

<xs:simpleType name="depth">

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

<xs:enumeration value="notSet" />

<xs:enumeration value="shallow" />

<xs:enumeration value="deep" />

</xs:restriction>

</xs:simpleType>

</xs:schema>

SDM 런타임(SDM Runtime)

SDR 런타임(또는 단순히 런타임)은 SDM의 구현을 호스팅한다. 이는 SDM 유형(type), 멤버(member) 및 인스턴스 스페이스(instance space)를 조작하기 위한 세트 API들을 공개하는 고가용성 분배 서비스(highly available distributed service)이다. 런타임은 일관된 방식으로 모든 SDM 인스턴스를 추적할 책임이 있다. 이는 배포(deployment), 버져닝(versioning), 보안, 및 복구를 위한 기계 장치를 제공한다. 도 27은 SDM 런타임의 논리적인 아키텍처를 나타낸다.

SDM 런타임은 다음과 같이 구성된다.

* SDM 런타임(Runtime) - 이는 SDM Runtime 구현(implementation)이다. 이는 하나 이상의 물리적인 기계를 실행하는 분배 구현(distributed implementation)이다. 런타임은 SDM 및 인스턴스를 조작하는 호출의 세트인 SDM API를 통하여 기능을 나타낸다.

* SDM 스토어(Store) - 이는 SDM 모델들(Models) 및 인스턴스를 위한 영구적인 스토어이다. 이 스토어는 고가용성이며, 그 일관성이 중요하다. 이 스토어는 치명적인 이벤트에도 견뎌 낸다.

* Service 배포 유닛(Deployment Unit) - 이는 SDU들을 위한 읽기 전용 스토어이다. SDM 스토어와 마찬가지로, 이는 고가용성이고, 치명적인 이벤트에도 견뎌 낸다.

* 컴포넌트 구현 호스트(Component implementation Host) - 이는 SDM 컴포넌트로부터 참조된 CLR 코드를 호스팅하기 위한 프레임워크(framework)이다.

SDM 런타임은 전형적으로 다음과 같은 클라이언트 클래스에 의하여 사용된다.

* 컴포넌트 인스턴트(Component Instances) - 이들은 SDM 런타임 라이브러리(RTL, Runtime Library)를 사용하기 위한 런타임과 통신하는 컴포넌트 인스턴트이다. 우리는 2가지 유형의 컴포넌트 인스턴트를 구분하는데, 그것은 런타임-호스팅된(runtime-hosted) 컴포넌트 인스턴스 및 런타임-호스팅되지 않은 컴포넌트 인스턴스이다.

* 개발 및 배포 도구(Development and Deployment tools) - 이들은 SDM 컴파일러, SDU 설치 도구 및 기타 전개 도구를 포함한다.

* 관리 도구(Management tools) - 이들은 런타임 자체를 등록하고 관리하기 위하여 사용되는 특별 허가된 도구(privileged tools)이다.

클라이언트는 SDM 런타임 라이브러리(RTL)를 통하여 런타임과 통신한다. 이들은 전형적으로 다음과 같은 동작을 수행한다.

* SDU들의 설치/설치제거: 이는 새로운 SDU들을 SDM 런타임의 실행중인 인스턴트에 추가 및 제거하는 프로세스이다.

* SDM 유형 및 인스턴스의 추가, 제거 및 수정: 클라이언트는 새로운 컴포넌트, 포트 및 와이어 유형을 생성할 수 있다.

* 인스턴스의 생성 및 삭제: 클라이언트는 새로운 컴포넌트, 포트 및 와이어 인스턴스를 생성할 수 있다.

* 이벤트의 소싱(Sourcing) 및 하강(sinking): 유형 및/또는 인스턴스 스페이스에 변경이 행해진 경우, 런타임은 영향을 받는 클라이언트에게 이벤트를 전송한다. 이벤트는 포트 바인딩 정보(port binding information)를 설정하는 것과 같이 특정 동작에 의해 트리거될 수 있다.

* 유형 및 인스턴스 스페이스를 질의한다(query): 클라이언트는 유형 및 인스턴스 스페이스를 반영할 수 있다.

서비스 정의 모델 런타임 아키텍처(Service Definition Model Runtime Architecture)

도입

이 부분에서는 서비스 정의 모델(SDM) 및 SDM 런타임에 대해서 검토한다. 런타임 아키텍처, 핵심 특성 및 구현에 대한 기술적인 논의가 제공된다. 의도된 청중은, BIG의 기술 평가자, 서비스 및 컴포넌트를 만들어 내고자 하는 개발자, 또는 시스템의 세부 사항에 대하여 관심이 있는 사람들이다.

서비스 시기(Service Era)

최근 10년에 걸쳐서 우리는 인터넷이 컴퓨팅 플랫폼으로서 등장한 것을 보아 왔다. 점점 더 많은 소프트웨어회사가 "서비스 모델로서의 소프트웨어"를 채택하고 있다. 서비스는 전형적으로 서버, 네트워킹 기어 및 기타 특정 하드웨어를 포함하는 수많은 기계에서 실행되는 여러 개의 컴포넌트를 포함한다. 느슨하게 연결된(loosely coupled), 비동기식 프로그래밍 모델이 기준(norm)이 되고 있다. 이러한 서비스의 성공을 위해서는 확장성(scalability), 가용성(availability) 및 신뢰성(reliability)이 중요하다.

우리는 하드웨어 경향에서의 변화도 보아 왔다. 고밀도 서버 및 특수화된 네트워크 하드웨어는 데이터 센터에서 널리 보급되었다. 스위칭 구조(switched fabrics)가 시스템 구성에서 큰 유연성을 제공하는 시스템 버스를 대체하고 있다. 하드웨어 비용은 소유권 메트릭(Ownership metric)의 총 비용의 작은 부분을 차지한다. 이는 전용 작동 요원을 보유하기 위한 비용으로 대체되었다. 바위와 같이 견고한 동작 실행은 드물지만, 어느 서비스에 있어서나 절대적으로 중요하다. 이러한 실행은 주로 사람에 의하여 구현된다.

효과적으로는, 개발의 초점을 단일 PC로부터 PC들의 네트워크로 바꾸는 것이다. 그러나, 이러한 모든 변화에 있어서, 서비스 개발자, 소프트웨어 공급자, 하드웨어 공급자, 및 최종 사용자(end-user)를 위한 과다한 새로운 문제점이 발생하였다.

* 서비스가 방대하고 복잡하다 - 이들은 개발하는데 시간이 많이 걸리고, 유지하기 힘들고 고가이며, 추가적인 기능을 확장하는데 위험이 있다.

* 서비스가 획일적이다(monolithic) - 이들은 맞춤식(custom) 컴포넌트 및 구성에 의존한다. 서비스의 일부가 독립적으로 제거 또는 업그레이드되거나, 다른 것으로 대체될 수 없다.

* 서비스가 특정 하드웨어 구성에 의존한다 - 특정 네트워크 토폴로지 또는 특정 네트워크 설비 기계의 의존성 여부이다. 이는 다른 환경의 서버를 호스팅하는 능력을 상당히 감소시킨다.

* 서비스가 사일로(silos)에서 개발된다 - 공통적인 플랫폼이 없기 때문에, 코드 공유 또는 최적의 동작 실행조차 위협적인 작업이다.

* 동작의 악몽 - 대부분의 서비스는 기능시키기 위한 작동 직원을 요구한다. 이 작동 직원은 각 서비스의 세부 내용에 대하여 훈련되어야 하며, 서비스가 발달함에 따라 다시 훈련되어야 한다.

이러한 문제의 일부는 DOS 시절(1980년대 경) 동안의 문제점과 같지는 않다. DOS는 디스크 관리, 파일 시스템, 콘솔 시설 등과 같은 애플리케이션 개발자를 위한 유용한 핵심 서비스를 정의하였다. 그러나, 이는 ISV들까지 수많은 복잡한 작업을 남겨 놓았다. 예를 들어, WordPerfect 및 Lotus 123은 모두 그 각각의 애플리케이션 내에 인쇄를 지원하기 위한 기록 프린터 드라이버를 독립적으로 구비하고 있었다. 이와 유사하게 프린터 하드웨어 공급자는 성공적인 제품을 생산하기 위해서는 소프트웨어 회사와 거래하여야 했다. 하드웨어 공급자 및 DOS 애플리케이션을 기록하기 위한 입구로의 장벽은 유난히 컸다. 이 때문에 단지 몇 개만의 성공적인 소프트웨어 회사가 생겨났다.

윈도우는 입구로의 장벽을 획기적으로 감소시킨 플랫폼을 정의함으로써 이 문제점을 다루었다. 윈도우는 PC 플랫폼 상의 대부분의 하드웨어를 위한 추상화 계층(abstraction layer)을 정의하였다. 이는 개발자로 하여금 특정 하드웨어 장치를 지원하도록 하기 위한 걱정을 덜어주었다. 윈도우는 메모리, 디스크 및 네트워크를 포함하는 PC 내의 모든 자원을 관리하였다. 또한, 윈도우 애플리케이션 개발자에 의하여 사용될 수 있는 풍부한 서비스를 갖추고 있었다. 이 플랫폼은 산업상의 엄청난 발전을 야기하였다. 윈도우 플랫폼을 타깃으로 삼은 소프트웨어 공급자는 엄청나게 이익을 냈다. 많은 새로운 하드웨어 공급자는 윈도우의 일반화(commoditization)로 인해 더 값싼 하드웨어를 제공하였다.

서비스 시대는 아직도 이러한 성장을 경험하여야 한다. 데스크탑 기계에서 일어난 혁명은 서비스에서도 발생할 필요가 있다.

BIG 서비스 플랫폼(BIG services Platform)

BIG은 고가용성이고, 스케일 가능한(scalable) 서비스를 위한 플랫폼을 생산하고 있다. 이 플랫폼은 이하를 가능하게 한다.

* Visual Studio 및 SQL, IIS 등의 재사용 가능한 빌딩 블록을 사용한 분배된, 스칼러블하고 고가용성 서비스의 개발

* 자동적으로 할당되고, 의도되고, 구성되는 추상화된 하드웨어 및 소프트웨어 자원의 세트에 걸친 개발

* 동작의 최적의 실행의 자동화를 통한 소유 비용의 저감.

* 상품 경제에 영향을 주는 표준화된 데이터 센터 하드웨어의 획득

BIG 플랫폼은 윈도우 플랫폼으로의 확장이고, .NET, SQL, 및 기타 마이크로소프트 자산과 같은 현존하는 기술 위에 구축된다. BIG 서비스 플랫폼은 이하를 포함하는 많은 부분으로 이루어져 있다.

* 우리가 BIG 컴퓨터라고 부르는 하나의 대형 컴퓨터를 만들기 위한 상품 하드웨어를 모아 놓은 하드웨어 기준 플랫폼. 이는 수많은 상호 접속된 서버, 네트워크 장치, 및 기억장치를 포함한다.

* 자원이 보이게 하는 하드웨어 추상화 계층(hardware abstraction layer). 동적 하드웨어 제조, 재배포, 및 자동화 네트워크 구성을 가능하게 한다.

* 개발자가 전체 서비스를 설명하는 서비스 정의 모델(SDM). 개발자로 하여금, 고가용성 SQL, IIS, 및 기타 재사용 가능한 빌딩 블록 컴포넌트를 사용하여 새로운 서비스를 신속하게 구축할 수 있게 한다.

* SDM을 지원하는 고가용성 런타임. BIG 컴퓨터 내의 다중 스케일 가능한 서비스의 호스팅을 가능하게 한다.

* 최적의 동작 실행을 자동화하기 위한 동작 논리 체제(operations logic framework). 폴리시 표현 및 시행을 가능하게 한다.

이 문서는 SDM 및 SDM 런타임에만 초점을 맞추어 설명한다.

서비스 정의 모드(Service Definition Mode)

이 섹션에서는 서비스 정의 모델(SDM)에 대하여 설명한다. SDM 및 SDML 언어에 대한 완벽한 기술적인 설명을 위해서는 "서비스 정의 모델 언어(Service Definition Model Language)" 문서를 참조하기 바란다.

SDM은 모든 서비스가 구축되는 기초이다.

* SDM은, 더 작은 유닛으로부터 서비스의 합성을 가능하게 한다. 이러한 유닛은 하드웨어 및 소프트웨어 추상화(abstraction)의 기초를 형성한다.

* SDM은, 서비스의 생생한 청사진으로서 제공한다 - SDM은 스케일 불변 방식으로 서비스의 전체 구조를 포착한다.

* SDM은, 동작적인 실행을 자동화하기 위한 프레임워크를 제공하고, 그들의재사용을 촉진한다.

* SDM은, 서비스의 배포, 재사용, 발견, 버져닝(versioning), 및 복구를 위한 표준을 정의한다.

서비스를 위한 컴포넌트 모델(Component Model for Services)

본질적으로, SDM은 서비스를 위한 컴포넌트 모델이다. 전통적인 컴포넌트 모델과 마찬가지로 SDM은, 더 복잡한 기능이 구축될 수 있는 근본(primitives)을 정의한다. 유추법을 고려해 보자. 마이크로소프트의 컴포넌트 객체 모델(Component Object Model, COM)은 컴포넌트를 만들기 위한 프로그래밍 모델을 정의하였다. 이는 컴포넌트가 어떻게 패키지되고, 등록되고, 활성화되고, 발견되는지에 관하여 표준화하였다. COM은 수명, 메모리 관리, 및 인터페이스 구현과 관련된 엄격한 규칙을 명령하였다(mandated). 이러한 근본이 상호 운영(interoperability)을 위하여 필수적이었다 - 이는 컴포넌트가 블랙 박스로서 취급될 수 있게 한다. Com은 영구적인 기억장치, 이벤팅(eventing), 자동화 및 OLE와 같은 더 정교한 서비스의 기초였다.

SDM은 서비스를 위한 컴포넌트 모델을 정의한다. 이 모델은 느슨하게(loosely) 연결된, 분산된, 그리고 비동기식의 서비스를 위해 매우 적절하다. SDM은 배포, 버져닝, 복구, 및 스코핑(scoping)을 위한 표준을 정의한다. SDM은 네트워크 관리, 하드웨어 관리, 기억장치 추상화 등과 같은 더 정교한 서비스가 제공되는 모델이다. SDM을 기타 컴포넌트 모델과 어떻게 비교하겠는가?

확실히 기타 기술들 중에서 DCOM 및 COBRA와 같은 기술은, 재사용 가능한 컴포넌트에 기초한 애플리케이션을 개발하기 위한 방법을 잘 정의하고 있다. 그러나, 현존하는 컴포넌트 기술도 강력하지만, 그들은 인터넷 또는 느슨하게 연결된 시나리오에 있어서 광범위하게 성공적이지는 못하였다. 이는 주로 다음과 같은 이유 때문이다.

* 현존하는 컴포넌트 기술은 대규모를 위하여 설계된 것이 아니다 - 대부분의 실행은 하나의 기계 또는 아주 적은 수의 기계를 위하여 최적화되었다. 인터넷 애플리케이션은 전형적으로 많은 기계에서 실행하는, 많은 상호 관련된 컴포넌트와 관련되어 있다.

* 현존하는 컴포넌트 기술은 RPC와 같은 발동 프로토콜(invocation protocols)을 명령한다(mandate) - 이들은 잘 확증된 네트워크 프로토콜을 이용하지도 않거나, 분기하는 프로토콜을 허용하지 않는다.

* 현존하는 컴포넌트 기술은 애플리케이션의 개념이 결여되어 있다 - 대부분은 잘 개발된 컴포넌트의 정의를 구비하지만, 더 작은 컴포넌트로 구성된 애플리케이션의 전체적인 정의가 결여되어 있다.

* 현존하는 컴포넌트 기술은 범용 컴퓨터에서 실행하는 소프트웨어로 제한된다 - 하나의 목적을 갖는 네트워크 장치는 컴포넌트로서 관여할 수 없다.

서비스 세계와 더 중요하게 관련되어 있는 많은 것들을 현존하는 컴포넌트 기술에 적용하여야 한다.

SDM 원리(SDM Fundamentals)

SDM은 서비스 구조의 선언적인 정의(a declarative definition)이다. 이 정의는 컴포넌트, 포트 및 와이어와 관련된다.

* 컴포넌트는 구현, 배포 및 동작 유닛이다. 컴포넌트는 Cisco의 로컬 디렉터(LocalDirector)와 같은 네트워크 설비 또는 공유 기계 상의 IIS 가상 웹 사이트, .NET 서버를 실행하는 전용 서버일 수 있다. 컴포넌트는 포트를 통하여 기능을 공개하고, 와이어를 통하여 통신 경로를 설정한다. 컴포넌트는, 복합 컴포넌트라고 하는 외부 컴포넌트 내에 맞추어질 수 있다(nested).

* 포트는 관련 유형을 갖는 이른바 종단점(endpoints)이다. 포트 유형은 종종 프로토콜, 예를 들어 HTTP 서버를 나타낸다. 포트는 통신을 설정하기 위하여 요구되는 정보를 획득한다.

* 와이어는 포트간의 허용되는 통신 경로이다. 이들은 포트간의 토폴로지의 관계를 선언한다.

서비스는 선언적인 서비스 정의 모델 언어(SDML)를 사용하여 만들어진다. 다음의 예를 고려해 보자.

(SDML). Lets consider an example:

using System;

using System.Iis;

using System.Sql;

[sdmassembly:name("MyService")];

[sdmassembly:version(1)];

componenttype MyFrontEnd : AspApplication

{

port SqlClient catalog;

implementation "MyFE, MyClrAssembly";

}

componenttype MyBackEnd : SqlDatabase

{

implementation "MyBE, MyClrAssembly";

}

componenttype MyService

{

component MyFrontEnd fe;

component MyBackEnd be;

port http = fe.http;

wire SqlTds tds

{

fe.catalog;

be.sqlServer;

}

implementation "MyService, MyClrAssembly";

}

위를 보면 알 수 있듯이, SDML을 위한 체계(syntax)는 C#로부터 많이 도입한 것이다. SDML은 컴포넌트, 포트 및 와이어 유형을 정의한다. 이 정의를 고려하면 다음과 같다.

* 사용하는 지령(the using directive)은 SDM 유형의 네임 스페이스(namespaces)를 참조한다. 이들은, SDM 런타임에 의하여 제공되고 http 와이어 유형과 같은 기본적인 유형을 정의하는 시스템 네임 스페이스를 포함한다. 기타 네임 스페이스는 IIS 및 SQL 서버와 관련된 유형을 정의한다.

* 어셈블리 이름 및 어셈블리 버전은 SDM 어셈블리를 위한 강력한 이름을 제공한다. 이는 CLR 어셈블리와 아무런 관련이 없다는 것을 유의하여야 한다. SDM 어셈블리는 SDM 배포 중 가장 작은 유닛이다. 이는 컴포넌트, 포트 및 와이어 유형의 집합체로 명명되고, 이를 포함한다. SDM 어셈블리는 CLR 어셈블리와 혼동되어서는 안 된다 - CLR 어셈블리와는 완전히 구별된다.

* MyFronEnd라고 하는 컴포넌트 유형은, Systme.Iis SDM 어셈블리에서 정의되는 참조 유형(referenced type)인 컴포넌트 유형 AspApplication으로부터 상속받은 것으로 선언된다. 컴포넌트는 추상적 개념이다; 컴포넌트는 클래스라고 하고, 인스턴스라고는 하지 않는다. MyFrontEnd는 컴포넌트를 식별하는데, 이로부터 0개 또는 그 이상의 컴포넌트 인스턴스가 생성될 수 있다.

* port SqlClient catalog; 유형 SqlClient의 MyFrontEnd 컴포넌트에서 포트를 선언한다. 포트를 이른바 "카탈로그(catalog)"라 한다. 이 포트는, MyFrontEnd가 베이스 컴포넌트 유형 AspApplication으로부터 상속받은 포트, 컴포넌트 및 와이어에 추가되는 것이다.

* implementation 키워드는 컴포넌트 유형에 대한 실행을 참조한다. 이 실행은 CLR 어셈블리 내의 CLR 클래스로의 참조이다. 이는 컴포넌트 유형에 대한 입구점(entry point) 또는 구조자(constructor)로 생각할 수 있다. 컴포넌트 인스턴스가 생성되면, 이 코드가 발동된다(invoked).

* MyService 컴포넌트 유형은 fe 및 be라고 하는 두 개의 서브 컴포넌트로 정의된다. 이들은 유형 MyFrontEnd 및 MyBackEnd이다. 컴포넌트 MyService의 인스턴스는 컴포넌트 인스턴스의 분류체계(hierarchy)를 형성하는 fe 및 be의 인스턴스를 후속하여 가질 수 있다.

* port http=fe.http; 이는 fe 컴포넌트 상의 http 포트로 위임된 MyService 컴포넌트 유형 상의 포트를 선언한다.

* wire SqlTds는 유형 SqlTds의 MyService 컴포넌트 유형의 와이어를, 이름 tds로 선언한다. 두 개의 포트가 와이어로 부착된다. 이 선언은, MyService의 인스턴스가 0개 또는 그 이상의 와이어 tds의 인스턴스를 가질 수 있고, 이들 와이어 인스턴스 각각은, 그들에 부착된 fe 컴포넌트로부터의 카탈로그 포트 및 be 컴포넌트로부터의 SQL 포트를 구비할 수 있다.

서비스의 그래픽적인 표시를 고려하는 것이 종종 도움이 된다. 도 28을 참고하라. 박스는 컴포넌트를 나타내고, 다이아몬드는 포트를 나타내며, 선은 와이어를 나타낸다.

컴포넌트 구현(Component Implementation)

모든 컴포넌트는 CLR 어셈블리 내의 CLR 클래스의 형태의 구현을 참조할 수 있다. CLR 어셈블리는 SDM 런타임에 의하여 호스팅되고, 컴포넌트 인스턴스 생성 시간(instantiation time)에 발동된다. SDM을 실행하는 CLR 클래스는 SDM 런타임 API를 호출함으로써 SDM 동작을 수행할 수 있다. 이는 이 문서의 뒷부분에서 상세하게 설명한다. 다음은 상기의 MyService SDM 컴포넌트 유형의 실행을 위한 C# 코드의 일부이다.

using System;

using Microsoft.SDM;

public class MyService: SDMComponentInstance

{

public override OnCreate(...)

{

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

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

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

SDMWire tds1 = CreateWire instanceance("tds");

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

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

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

}

}

이 코드는 SDMComponent로부터 상속받은 C# 클래스 MyService를 정의한다. 클래스는 OnCreate() 방법에 우선하고, fe 컴포넌트의 2개의 인스턴스, be 컴포넌트의 하나의 인스턴스 및 하나의 와이어 인스턴스를 생성한다. 그리고 이는 와이어 인스턴스로 3개의 포트를 추가한다.

이 CLR 코드는, MyService를 위한 SDM 내에서 참조되는 MyClrAssembly라고 하는 어셈블리로 컴파일된다. 유형 MyService의 컴포넌트가 컴포넌트가 인스턴스 생성(instantiate)되면, 이 코드가 발동되고, OnCreate 방법이 호출된다.

[BassamT] C# 코드의 강력하게 유형화된 버전을 고려해 보자.

인스턴스(Instances)

SDML은 컴포넌트, 포트 및 와이어 유형을 정의하기 위하여 사용된다; 이는 인스턴스를 정의하지는 않는다. 인스턴스는, 상기 C# 코드에 나타낸 바와 같이 SDM 런타임 API를 사용하여 생성될 수 있다. 상기 C# 코드는 다수의 인스턴스를 생성하였고, 인스턴스 스페이스에 와이어링 토폴로지를 형성하였다. 이러한 인스턴스는 SDM 런타임에 의하여 추적될 것이다. 예를 들어, SDM 런타임은, OnCreate 호출이 상기의 것을 완료한 후 다음의 정보를 저장한다:

component instance ms[1]

port instance http[1]

component instance fe[1]

component instance fe[2]

component instance be[1]

wire instance tds[1]

fe[1].catalog

fe[2].catalog

be[1].SqlServer;

주의: 여기서 사용된 체계(syntax)는 SDML이 아니다; 이는 SDM 런타임에 의하여 추적되는 인스턴스 스페이스를 예시하기 위하여 사용된다.

ms[1]은 3개의 자식 컴포넌트 인스턴스(children component instance), fe[1], fe[2], 및 be[1]을 갖는 컴포넌트 인스턴스이다. fe[1] 및 fe[2]는 fe 컴포넌트의 인스턴스이다. be[1]은 be 컴포넌트의 인스턴스이다. tds[1]은 3개의 멤버를 포함하는 와이어 인스턴스이다. 도식적으로는, 도 29에 인스턴스 스페이스가 도시되어 있다.

컴포넌트 인스턴스는 실제 물리적인 명시(manifestations)를 포함한다 - 이 예에서 fe[1] 및 fe[2]가 윈도우 기계에서 실행하는 IIS상에서 실행되는 두 개의 ASP.NET 애플리케이션이다. CreateComponentInstance로의 호출이 행해지면, 새로운 ASP.NET 애플리케이션이 생성되고 IIS 박스로 구성된다. 다수의 중간 단계가 발동될 수도 있다 - 예를 들어, 새로운 자원을 사용하기 위하여 호출자의 신용 카드에 부과되거나, 용량의 부족으로 인하여 새로운 기계가 할당된다. 이 문서의 뒷부분에서 컴포넌트 설명 후에 기계를 실험한다.

서비스 배포 유닛(Service Deployment Units)

MyService를 위한 SDM 모뎀은 컴포넌트, 포트 및 와이어로서 서비스의 구조를 정의하였다. 이는 SDM 런타임 기계에 설치될 수 있는 SDM 어셈블리로 귀착된다. 명백하게, SDM 어셈블리는 서비스를 인스턴스 생성(instantiating)하기에 충분하지는 않다. SDM 어셈블리에 추가하여, 컴포넌트의 구현인 CLR 어셈블리도 고려하여야 한다. 우리는 ASP.NET 코드, SQL 스크립트, 및 서비스에 의하여 필요한 모든 것을 고려하여야 한다. 이러한 모든 부분의 총합이 서비스 배포 유닛(SDU)에 패키징된다. 도 30을 참고하라.

SDM 런타임

SDR 런타임(또는 단순히 런타임)은 SDM의 구현을 호스팅한다. 이는 SDM 유형, 멤버 및 인스턴스 스페이스(instance space)를 조작하기 위한 세트 API들을 공개하는 고가용성 분배 서비스(distributed service)이다. 런타임은 일관된 방식으로 모든 SDM 인스턴스를 추적할 책임이 있다. 이는 배포(deployment), 버져닝(versioning), 보안, 및 복구를 위한 기계 장치를 제공한다.

이 섹션에서는 BIG V1.0 공개물에서 제안된 SDM 런타임의 설계 및 구현에 대하여 설명한다. SDM 런타임의 다른 실시예가 물론 있을 수 있지만, 우리는 이 문서에서 한 가지에 초점을 맞춘다 - BIG 컴퓨터 상에 호스팅되는 고가용성 SDM 런타임 구현을 고려한다(상세한 사항은 _____를 참고하라).

런타임 아키텍처(Runtime Architecture)

도 27은 SDM 런타임의 논리적인 아키텍처를 도시한다.

SDM 런타임은 다음과 같이 구성된다.

* SDM 런타임 - 이는 SDM 런타임 구현이다. 이는 하나 이상의 물리적인 기계에서 실행되는 분산된 구현이다. 런타임은, SDM 및 인스턴스를 조작하는 호출의 세트인 SDM API를 통하여 그 기능을 발휘한다.

* SDM 스토어(SDM Store) - 이는 SDM 모델 및 인스턴스를 위한 영구적인 스토어이다. 이 스토어는 고가용성이며, 일관성이 중요하다. 이 스토어는 치명적인 이벤트에도 견뎌낸다.

* 서비스 배포 유닛(Service Deployment Units) - 이는 SDU들을 위한 읽기 전용 스토어이다. SDM 스토어와 마찬가지로, 이는 고가용성이며, 치명적인 이벤트에도 견뎌낸다.

* 컴포넌트 구현 호스트(Component Implementation Host) - 이는 SDM 컴포넌트로부터 참조된 CLR 코드를 호스팅하기 위한 프레임워크(framework)이다.

SDM 런타임은 전형적으로 이하의 클라이언트 클래스에 의하여 사용된다:

* 컴포넌트 인스턴스(Component Instances) - 이들은 SDM 런타임 라이브러리(RTL)를 사용하는 런타임과 통신하는 컴포넌트 인스턴트이다. 우리는 두 가지 유형의 컴포넌트 인스턴스 - 런타임 호스팅된 컴포넌트 인스턴스(runtime-hosted component instances) 및 런타임 호스팅되지 않은 컴포넌트 인스턴스를 구별한다.

* 개발 및 배포 도구(Development and Deployment tools) - 이들은 SDM 컴파일러, SDU 설치 도구 및 기타 개발 도구를 포함한다.

* 관리 도구(Management tools) - 이들은 런타임 자체를 등록하고 관리하기 위하여 사용되는 권한이 부여된 도구(privileged tools)이다.

클라이언트는 SDM 런타임 라이브러리(RTL)를 통하여 런타임과 통신한다. 이들은 전형적으로 이하를 포함하는 동작을 수행한다.

* SDU들의 설치/설치제거: 이는 새로운 SDU들을 SDM 런타임의 실행중인 인스턴트에 추가 및 제거하는 프로세스이다.

* SDM 유형 및 인스턴스의 추가, 제거 및 수정: 클라이언트는 새로운 컴포넌트, 포트 및 와이어 유형을 생성할 수 있다.

* 인스턴스의 생성 및 삭제: 클라이언트는 새로운 컴포넌트, 포트 및 와이어 인스턴스를 생성할 수 있다.

* 이벤트의 소싱(Sourcing) 및 하강(sinking): 유형 및/또는 인스턴스 스페이스에 변경이 행해진 경우, 런타임은 영향을 받는 클라이언트에게 이벤트를 전송한다. 이벤트는 포트 바인딩 정보(port binding information)를 설정하는 것과 같이 특정 동작에 의해 트리거될 수 있다.

* 유형 및 인스턴스 스페이스를 질의한다: 클라이언트는 유형 및 인스턴스 스페이스를 반영할 수 있다.

유형, 멤버 및 인스턴스 스페이스(Type, member and instance space)

컴포넌트 유형, 컴포넌트 및 컴포넌트 인스턴스간의 관계는 최신 객체 지향 언어의 클래스, 클래스 멤버, 및 객체와 유사하다. SDM은 유형, 멤버 및 인스턴스스페이스간의 분리를 정의한다. 컴포넌트 유형은 유형 스페이스(type space)에 있고, 컴포넌트는 멤버 스페이스(member space)에 있으며, 컴포넌트 인스턴스는 인스턴스 스페이스(instance space)에 있다. 도 31은 3개의 스페이스간의 분리를 도시한다.

"멤버 스페이스"는 유형 스페이스의 인스턴스를 포함한다. "인스턴스 스페이스"는 멤버 스페이스의 인스턴스를 포함한다. SDM 런타임은 3개의 모든 스페이스 및 이들의 관계를 추적할 책임이 있다. 이 정보는 SDM 스토어 내에 저장되고, 런타임 API를 사용함으로써 질의될 수 있다. 컴포넌트 및 와이어는 0개 또는 그 이상의 인스턴스를 가질 수 있다. 포트는 하나의 인스턴스만을 갖는다.

SDM 멤버 및 인스턴스 스페이스는 엄격한 계층을 따른다. 멤버 및 인스턴스 스페이스 내의 모든 컴포넌트는 트리로 배열된다. 루트 컴포넌트는 "루트(root)" 또는 "범용(universal)" 컴포넌트라고 하는 특별한 컴포넌트이다. 이전 섹션의 MyService 예로부터 멤버 트리를 보자(도 32). 박스는 컴포넌트를 나타내고, 선은 부모/자식(parent/children) 관계이다. myService는 루트 컴포넌트의 멤버 컴포넌트이다. 인스턴스 트리는 도 33에 도시된 것과 같이 구성될 수 있다. 서로 다른 수의 자식 인스턴스를 갖는 myService 컴포넌트의 2개의 인스턴스가 있다는 것을 유의하여야 한다. myService[1].fe[1] 및 myService[2].fe[2]는 같은 컴포넌트 멤버 "fe"를 가지고, 같은 컴포넌트 유형 "MyFrontEnd"를 갖지만, 그 이외에는 전혀 별개의 컴포넌트 인스턴스이다. "root[1]"은 루트 컴포넌트의 인스턴스일 뿐이다.

컴포넌트 인스턴스 생성(Component Instantiation)

SDM 런타임에 의하여 제공되는 기본적인 동작 중 하나는 컴포넌트 인스턴스 생성이다. 이는 컴포넌트 인스턴스가 존재하게 되는 프로세스이다. 인스턴스(또는 객체)를 생성하는 것이 전형적으로 인스턴스를 위한 메모리의 청크(chunk)를 할당하고 초기화하는 것과 관련되어 있는 전통적인 컴포넌트 모델과 달리, SDM 컴포넌트는 전형적으로 서로 다른 부분에 의하여 수행되는 많은 단계와 관련되고, 완료하기 위하여 수시간, 아니면 수일이 걸릴 수 있다. 예를 들어, 유형 ASP.NET 애플리케이션의 컴포넌트가 인스턴스 생성되면, 결과는 구성 동작(configuration act)이 후속하는 IIS를 실행하는 기계 상의 새로운 가상 웹 사이트이다. IIS 기계의 용량에 도달하는 시나리오를 고려하면, ASP.NET 애플리케이션이 인스턴스 생성되기 전에 새로운 하나가 할당되어야 한다. 이 프로세스는, 풀(pool)로부터 새로운 기계를 할당하는 것, 가능하면 빌딩 변경을 발생시키는 것, 및 IIS를 포함하는 오퍼레이팅 시스템을 설치하는 것을 포함하기 때문에 수시간 걸릴 수 있다. SDM 런타임은 컴포넌트 인스턴스 생성을 위한 두 가지 방법을 지원하는데, 두 가지 방식이란 1) 팩토리(Factory)가 컴포넌트를 인스턴스 생성하는 것과, 2) 런타임이 컴포넌트 인스턴스를 생성하는 것이다. 이러한 방법은 이하에서 간략히 설명한다. 더 자세한 내용은 "Component Instantiation" 명세서를 참조하라.

팩토리가 컴포넌트 인스턴스를 생성(Factory instantiated components)

컴포넌트 팩토리(또는 단순히 팩토리)는 하나 이상의 컴포넌트 유형을 위한 인스턴스를 생성할 책임이 있는 엔티티이다. 팩토리는 인스턴스 생성을 위하여 하나 이상의 포트를 공개하는 컴포넌트 자체이다. 팩토리를 생각하는 한 가지 방법은 자원 관리자로서이다. 팩토리가 관리하는 자원은 컴포넌트 유형이다. 팩토리는 자원을 컴포넌트의 인스턴스로 맵핑(mapping)하는 방법을 알고 있다. 예를 들어, 우리가 유형 컴포넌트 "File Storage"를 갖는다고 가정해 보자. 이 컴포넌트가 인스턴스 생성되면, NTFS 발견이 생성되고, 적절한 ACL들이 준비될 것이다. 이 컴포넌트를 위한 팩토리는 기억장치를 할당하기 위한 다수의 윈도우 기계를 관리한다. 팩토리는 NTFS 공유를 생성하고, ACL들 및 분담할 몫(quotas) 등을 설정하는 책임이 있다. 컴포넌트 팩토리는 SDM 런타임에서 중요한 역할을 수행한다. 이들은 전형적으로 서비스를 위하여 자원을 관리하기 때문에, 이들은 신뢰성 있으며 고가용성이라 예상된다. SDM 런타임에 의하여 지원되는 컴포넌트 팩토리의 수는 개방 종료되지만(open ended), 우리는 BIG V1.0이 적은 수의 기본 컴포넌트 팩토리를 가질 것으로 예상한다. 컴포넌트 팩토리는 이하와 같다.

* 하드웨어 - 이는 하드웨어의 인스턴스를 할당하고 관리하기 위한 책임이 있는 기본 레벨 팩토리이다. 예를 들어, 이는 1GB의 메모리, 또는 NAS와 같은 기억장치 장치를 사용하여 서버 기계를 할당할 수 있다.

* 네트워크 - 이 팩토리는 VLANs, 공용 IP 어드레스, DNS 네임 등을 책임진다.

* PC - 이 팩토리는 기계를 할당하고 풀 OS 이미지(full OS-image)를 그것에 배포할 수 있다.

* 기억장치 - 이 팩토리는 기억장치를 관리하고 할당하는 책임이 있다.

* 소프트웨어 자원 - ASP.NET, IIS 웹 사이트, SQL 서버, 데이터베이스 등.

인스턴스 생성 프로세스(Instantiation process)

팩토리는 어느 컴포넌트 유형이 그 인스턴스를 생성할 책임이 있는지를 지정하는 SDM 런타임을 사용하여 등록하여야 한다. 하이레벨에 있어서, 인스턴스 생성의 프로세스는 다음과 같다:

호출자(caller)는 SDM 런타임으로 주어진 컴포넌트 유형에 대한 컴포넌트 팩토리를 요청한다.

1. SDM 런타임은 적절한 컴포넌트 팩토리를 발견하고, 이를 호출자에게 반환하는 책임을 진다.

2. 그 후, 호출자는 컴포넌트 팩토리와 직접 통신하여, 하나 이상의 인스턴스를 생성하도록 요청한다.

런닝 팩토리 테이블(Running Factory Table)

SDM 런타임은 컴포넌트 유형 및 그들의 적절한 팩토리의 테이블을 보유한다. 모든 컴포넌트 인스턴스는 런닝 팩토리 테이블을 갖는다. 런닝 팩토리 테이블 구조는 다음과 같다.

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

컴포넌트 인스턴스는 그들의 테이블 및 그들의 바로 자식인 테이블(direct children's tables)에 엔티티를 추가/제거할 수 있다. 디폴트로서, 새로운 자식 컴포넌트 인스턴스가 생성되었을 때, 부모의 런닝 팩토리 테이블이 상속된다.

런닝 팩토리 테이블은 다른 환경의 동일한 컴포넌트 유형을 위한 다른 팩토리를 지원하기 위하여 모든 컴포넌트 인스턴스에 대하여 추적된다. 팩토리는 전형적으로 리소스가 할당되는 곳이기 때문에, 환경을 호스팅하는 것은 자원 할당에 대한 서로 다른 폴리시를 요구할 수 있다. 예를 들어, Digex와 같은 호스팅 엔티티가 그들의 고객에 대하여 서로 다른 계획을 갖는 시나리오를 고려해 보자. 골드(Gold)를 위해 지불한 고객은 전용 IIS 박스(dedicated IIS box)를 획득하고, 실버(Silver)를 위해 지불한 고객은 공유 IIS 박스(shared IIS box)를 획득한다. 고객의 서비스는 "ASP.NET 애플리케이션" 유형의 컴포넌트를 포함하고, 이는 전용 IIS 기계 또는 공유되는 IIS 기계로 호스팅되는지 여부를 알지 못한다. Digex는 도 34에 도시한 것과 같이 이를 구현할 수 있다.

Digex는 골드 팩토리(Gold Factory) 및 실버 팩토리(Silver Factory)의 2가지 컴포넌트를 갖는 컴포넌트이다. 팩토리는 컴포넌트 자체이다. Digex는 또한 "골드" 및 "실버"라고 하는 기타 컴포넌트를 정의한다. 이러한 "골드" 컴포넌트는 골드 서비스를 위하여 지불한 모든 서비스의 부모(parent)이다.

Digex가 인스턴스 생성되면, 이는 팩토리의 인스턴스 및 "골드" 및 "실버" 컴포넌트의 인스턴스를 생성한다. Gold[1]은 고유의 런닝 팩토리 테이블을 갖는다. Digex는 적절한 SDM 런타임 API를 호출함으로써 이 테이블에 골드 팩토리를 등록한다. 새로운 고객의 서비스가 Gold[1]의 자식으로서 인스턴스 생성되면, 이는 Gold[1]의 런닝 팩토리 테이블을 상속받는다. 이는, "ASP.NET 애플리케이션"의 컴포넌트 인스턴스가 생성되었을 때, 골드 팩토리가 이 요청을 처리하고 고객의 구좌에 적절히 부과한다.

팩토리 추적(Factory tracking)

SDM 런타임은 각 컴포넌트 인스턴스를 생성한 팩토리의 추적(track)을 보유한다. 도 35를 참고하라. 점선은 컴포넌트 인스턴스와 이를 생성한 팩토리 사이의 "~에 의하여 생성된(created by)" 관계를 나타낸다. 상술한 바와 같이, 팩토리는 컴포넌트 자체이고, 따라서 팩토리는 팩토리를 가지고 있어야 한다. 런타임의 무한 반복을 종료하는 것은 이하에서 설명하는 바와 같이 "런타임 호스팅된 컴포넌트(runtime-hosted components)"에 대한 팩토리이다. 루트 컴포넌트 인스턴스는 특수한 것이며, 이는 고유의 팩토리임을 유의하여야 한다.

팩토리 및 트랜잭션(Factories and Transactions)

팩토리는 서비스 개발자가 복잡한 롤백(rollback) 및 오류 처리 논리(error handling logic)에 대한 걱정을 덜 수 있도록 트랜잭션을 지원한다. 트랜잭션된 서브시스템(transacted subsystems)의 상부(top)에 구축되지 않은 팩토리는 보상을 지원할 필요가 있다. 팩토리는 또한 분산 트랜잭션에서 협력(enlisting)을 지원하여야 한다.

팩토리는 전형적으로 인스턴스 생성과 관련된 다수의 부기 정보(bookkeeping information)를 보유한다. 이 부기 정보는 적절한 복구를 보장하기 위하여 SDM 런타임과 함께 일관되게 유지되어야 한다. 이를 용이하게 하기 위하여, SDM 런타임은, 팩토리를 포함하는 컴포넌트 인스턴스를 위한 트랜잭션된 기억장치 서비스(transacted storage service)를 제공한다. 잘 쓰여진 팩토리(well-written factory)는 이 스토어 내에 모든 부기 정보를 저장한다.

팩토리 포트(Factory port)

팩토리는 전형적으로 컴포넌트 인스턴스 생성을 위하여 사용될 수 있는 하나 이상의 포트를 공개한다. 포트 유형은 SDM 런타임에 의해 명령되지 않지만, 모든 컴포넌트 팩토리가 SDM_Factory 포트를 지원하는 것을 추천한다. SDM_Factory는 새로운 컴포넌트 인스턴스를 생성하기 위하여 호출되는 SOAP 기반 포트(SOAP based port)이다. 이 포트를 위한 C# 인터페이스는 다음과 같다.

public interface ISDMFactory

{

ComponentInstance Instantiate(

ComponentInstance parent,

Component component,

ComponentType componentType, object args);

void Alloc(ComponentInstance allocInstance);

void Construct(ComponentInstance constructInstance);

}

ISDMFactory는 3개의 패스 인스턴스 생성 프로세스(pass instantiation process)를 지원한다:

인스턴스 생성 패스(Instantiation Pass): 이 패스는 SDM 런타임을 사용하여 모든 컴포넌트 인스턴스를 반복적으로 생성한다. 그러나 이는 할당이나 작성(construction)은 하지 않는다. 이는 단지 요구되는 "뼈대(skeleton)" 컴포넌트 인스턴스를 생성할 뿐이다.

할당 패스(Allocation Pass): 이 패스 동안, 모든 관련 컴포넌트 팩토리는 인스턴스 생성을 위하여 필요한 모든 자원을 할당한다.

작성 패스(Construction Pass): 할당이 성공하면, 작성 패스가 개시된다. 이는 전형적으로 가장 긴 런닝 패스(running pass)이다. 팩토리는 전형적으로 작성 패스 동안 모든 실제 작업을 행한다.

팩토리는 물론 인스턴스 생성을 위하여 다른 포트 유형을 지원할 수 있다. 그러나, SDM 런타임 및 런타임 API들은 SDM_Factory 구현과 양호하게 동작하는 다수의 보조 기능을 구비한다. 이러한 API들은 확실하게 대다수의 개발자를 위한 개발자 경험을 향상시킬 것이다.

런타임 호스팅된 컴포넌트 인스턴스(Runtime-hosted component instances)

팩토리 외에, SDM 런타임은, 구현 SDML 키워드를 사용하여 CLR 어셈블리를 참조하는 SDM 컴포넌트를 위한 구현도 호스팅한다. 참조된 CLR 어셈블리는 CLR 클래스의 완전한 자격이 있는 네임(fully qualified name)인 문자열(literal string)이다. 예를 들어,

componenttype A

{

port pt x;

implementation

"MyNamespace.MyClassName,MyClrAssemblyName"

}

또는, 강력하게 명명된 CLR 어셈블리를 위하여 컬쳐(culture), 버전, 및 키를 지정할 수 있다:

componenttype A

{

port pt x;

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

}

이러한 컴포넌트에 대하여, SDM 런타임은 팩토리로서 동작하고, SDM 런타임은 이러한 CLR 클래스를 호스팅하고 관리한다. 또한 이는, 기본 레벨 팩토리가 SDM 런타임에 의하여 호스팅된 CLR 어셈블리로서 구현되기 때문에 상술한 팩토리의 무한 반복을 종료시킨다.

CLR 어셈블리는 마이크로소프트의 IIS 서버를 사용하여 호스팅된다. 구현 키워드는 클래스를 참조하는데, 이 클래스는 MarchalByRefObject로부터 상속받아야 하고, IRuntimeHostedImplementation 및 ISDMFactory 인터페이스를 구현하여야 한다. 편의를 위하여, 기본 클래 SdmComponentInstance는 이러한 인터페이스에 대한 디폴트 구현을 제공한다. 다음은 상기 컴포넌트 유형 A를 위한 런타임 호스팅된 CLR 구현의 예이다.

public class A : SdmComponentInstance

{

protected override void OnCreate(object args)

{

// do something

}

}

클래스 A는 SdmComponentInstance로부터 상속받은 C# 클래스이며, 따라서 SDM 런타임에 의하여 호스팅될 수 있다. 이 클래스를 위한 CLR 어셈블리는, 이것이 적절하게 동작하도록 하기 위하여 SDU의 /bin 디렉토리에 위치하여야 한다. 유형 A의 컴포넌트의 인스턴스가 생성되면, 런타임은 가용한 호스트 IIS 기계를 탐색하고 그 기계에 CLR 코드를 인스턴스 생성하는 책임이 있다. CLR 코드는, IIS에 의하여 호스팅되는 .NET 원격 애플리케이션으로서 호스팅된다. SDU 내의 모든 CLR 어셈블리는 IIS 프로세스를 공유하고, 그 프로세스 내에 고유의 AppDomain을 갖는다.

CLR 어셈블 리가 로딩되면, 런타임은 IRuntimeHostedImplementation 인터페이스 상의 잘 정의된 입구점(entrypoint)으로 .NET 원격 호출을 수행한다. 이 점에서, CLR 클래스는 ComponentFactory와 동등하고, ISDMFactory 인터페이스는 이전 섹션에서 언급한 것과 같이 소비된다.

포트 및 와이어(Ports and Wires)

포트 및 와이어는 SDM 런타임 내의 통신을 위한 베이시스(basis)이다. 포트 및 와이어는 오늘날 서비스 배포에 있어서 공통적인 수많은 문제를 해결한다:

통신 정보의 하드 코딩(Hard coding of communication information) - 많은 서비스는 전형적으로 그 서버의 이름 또는 ip 어드레스를 코드 내에 하드 코딩한다. 예를 들어, 프론트 엔드 서버(front end server)는 전형적으로 데이터베이스 이름, 로그인 및 패스워드와 같은 접속 정보뿐만 아니라 SQL 서버 기계 이름을 하드 코딩한다.

통신 토폴로지의 정의(Defining a communication topology) - 대부분의 서비스 배포는 전형적으로 DMZ를, 통신을 위한 경계를 정의하기 위한 메커니즘만으로 사용한다. 다른 제약은 요구되지 않으며, 예를 들어 프론트 엔드 서버가 다른 프론트 엔드 서버와 통신할 필요가 있다면 이는 어디서도 포착되지 않는다.

발견(Discovery) - 서비스에 추가되거나 서비스로부터 제거된 새로운 컴포넌트에 대하여 찾아내는 것은 전형적으로 오늘날 서비스가 직면하고 있는 문제점이다.

SDM은 이러한 문제를 포트 및 와이어를 사용하여 해결한다. 포트는 컴포넌트에 공개되는 유형화된 엔티티(typed entities)이다. 포트는 서버 액세스 점(server access point)과 유사하다 - 이는 컴포넌트가, 잘 정의된 기능을 공개하는 곳이다. 예를 들어, "기억장치(storage)" 컴포넌트는, 파일 시스템 동작을 위하여 사용될 수 있는 유형 SMB.Server의 포트를 정의한다. 와이어는 포트간의 허용 가능한 바이딩(binding)을 정의한다. 이는 통신 경로를 제한할 수 있는 통신 토폴로지를 형성한다.

상술한 내용으로부터, MyService 예를 다시 시험해보자.

componenttype MyService

{

component MyFrontEnd fe;

component MyBackEnd be;

port http = fe.http;

wire SqlTds tds

{

fe.catalog;

be.sqlServer;

}

implementation "MyService, MyClrAssembly";

}

MyService는 tds라는 하나의 와이어를 포함한다. 와이어는, 컴포넌트와 마찬가지로 인스턴스를 가질 수 있다. 예를 들어, 다음은 2개의 서로 다른 와이어 인스턴스 토폴로지를 갖는 MyService ms[1] 및 ms[2]의 2개의 컴포넌트 인스턴스이다.

component instance ms[1]

wire instance tds[1]

fe[1].catalog

fe[2].catalog

be[1].SqlServer;

component instance ms[2]

wire instance tds[1]

fe[1].catalog

be[1].SqlServer;

wire instance tds[2]

fe[2].catalog

be[1].SqlServer;

ms[1]은 3개의 포트 인스턴스를 포함하는 단일 와이어 인스턴스 tds[1]을 갖는다. ms[2]는 각각 2개의 포트 인스턴스를 갖는 2개의 와이어 인스턴스 tds[1] 및 tds[2]를 갖는다. 첫 번째 경우에 있어서, fe[1] 및 fe[2]는 서로 볼 수 있다. 두 번째 경우에 있어서는, fe[1] 및 fe[2]는 서로 볼 수 없다.

와이어 인스턴스는 물리적인 통신 토폴로지를 형성한다. 포트 인스턴스는 와이어 인스턴스의 멤버이다. 이들은 다음과 같은 것을 할 수 있다:

1) 서로에게 질의하거나 서로를 발견할 수 있다 - 런타임 API는 동일한 와이어 인스턴스 상의 다른 포트 인스턴스에 질의하고 발견하기 위한 기능을 지원한다. 모든 멤버는 동일한 와이어 인스턴스 내에서 볼 수 있다. 또한, 와이어 인스턴스의 소유자는 어느 때나 멤버에 질의할 수 있다.

2) 이벤트를 수신할 수 있다 - 와이어의 멤버는 멤버 포트 인스턴스 상의 SDM 동작에 의하여 트리거되는 이벤트를 수신할 수 있다. 자세한 사항은 아래의 "이벤트(Events)"를 참고하라.

3) 통신을 제한할 수 있다 - 와이어 인스턴스는 컴포넌트 인스턴스간의 허용되는 통신 경로를 제한한다.

포트 바인딩 정보(Port binding information)

포트는, 컴포넌트에 의하여 공개되는 유형화된 엔티티(typed entities)이다. 포트는 정확하게 하나의 인스턴스를 갖는다. 포트 인스턴스는 바인딩 정보를 운반할 수 있는데, 바인딩 정보는 전형적으로 컴포넌트 간의 통신 채널을 설정하기 위하여 요구되는 모든 것이다. 예를 들어, 상술한 "be[1].SqlServer" 포트 인스턴스는 SQL 백엔드(backend)로 접속하기 위한 다음과 같은 바인딩 정보를 가질 수 있다.

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

이 문자열은 ADO 또는 OLEDB로 보내질 수 있고, TDS 접속이 백엔드 SQL 서버로 설정될 수 있다. SDM 런타임은 통신부(communicating parties)를 방해하지 않는다. 이는 단지, 통신을 시작하도록 요구된 임의의 정보의 보유부(holder)로서 동작한다.

포트 가시성 및 와이어 인스턴스(Port visibility and wire instance)

컴포넌트 인스턴스 상의 포트 인스턴스는, 동일한 와이어 인스턴스에 부착되어 있다면 다른 컴포넌트 인스턴스로만 볼 수 있다. 이는 서비스를 위한 논리적인 네트워크 토폴로지를 구축하기 위한 상당히 강력한 메커니즘이다. SDM 런타임은 또한, 와이어 인스턴스 제약을 구현하기 위하여 필요한 물리적인 가상 네트워크를생성하고 패킷 필터링을 사용하기 위한 수단을 지원한다. 자세한 정보는 "네트워킹 아키텍처(Networking Architecture)"를 참고하라.

이벤트(Events)

SDM 런타임은 SDM 인스턴스 스페이스 상의 동작의 결과로서 어떤 고유의 이벤트(intrinsic events)를 발생시킨다. 예를 들어, 컴포넌트 인스턴스가 포트 인스턴스를 생성하면 이벤트가 발생한다. 지정된 이벤트에 따라서, 목적지(destination)는 주어진 와이어 상의 포트 인스턴스 또는 합성 컴포넌트 인스턴스이다.

모든 이벤트는 런타임 포트 상의 컴포넌트 인스턴스로 전달된다. SDM 런타임 라이브러리는 이러한 이벤트를 트랩핑(trapping)하고 이들을 언어-특정 호출(language-specific call)로 번역하는 책임을 진다. 예를 들어, CLR-기반 SDM 런타임 라이브러리는 CLR 이벤트를 발생시킨다.

컴포넌트 인스턴스 이벤트(Component instance events)

이 이벤트들은, 컴포넌트 인스턴스가 생성되거나 존재하는 컴포넌트 인스턴스가 삭제될 때에 발생한다. 이벤트의 목적지는 언제나 부모 합성 컴포넌트 인스턴스(parent compound component instance)이다. 이벤트는 바로 위의 부모 컴포넌트 인스턴스로만 전송된다 - 이벤트들은 인스턴스 트리를 퍼지게 하지 않는다. 상술한 예로부터, 컴포넌트 인스턴스 "u[1].foo[2]"는 런타임이 멤버 컴포넌트 "c"의 새로운 인스턴스를 생성하도록 요청한다고 가정한다. 도 36을 참고하라.

컴포넌트 인스턴스 "u[1].foo[2]"의 코드는 현재 기계 1에서 실행중이다.SDM RTL을 사용하여, 이는 런타임에게 컴포넌트 "c"의 새로운 인스턴스를 생성할 것을 요청한다. 런타임은 호출하는 컴포넌트 인스턴스를 알고 있고, 동작을 명확하게 하고(disambiguate) 살펴볼 수 있다(scope). 새로운 컴포넌트 인스턴스가 생성되고, 이벤트가 발생하고 호출한 컴포넌트 인스턴스로 다시 전달된다. 인스턴스가 파괴되거나 실패하면, 런타임은 적절한 이벤트를 부모 컴포넌트 인스턴스 및 적절한 컴포넌트 팩토리로 전송한다.

포트 인스턴스 이벤트(Port instance events)

컴포넌트 인스턴스가 포트 인스턴스를 생성하고나 존재하는 포트 인스턴스를 삭제하면, 부모 컴포넌트 인스턴스는 그 변경을 알게 된다. 도 37을 참고하라. 포트 인스턴스가 와이어 인스턴스에 부착되면, 와이어 인스턴스의 모든 멤버는 부모 컴포넌트 인스턴스뿐만 아니라 변경을 알게 된다. 이에 대해서는 다음 섹션에서 설명한다.

포트 상태(Port states)

모든 포트 인스턴스는 다음의 상태 중 어느 하나일 수 있다.

* 생성(Created) - 이는 처음 생성되었을 때, 포트의 상태이다. 이는 부모 컴포넌트 인스턴스로 전송된 이벤트를 트리거한다.

* 부착(Attached) - 포트가 와이어 인스턴스로 부착되면 포트는 이 상태가 된다. 이는 와이어 인스턴스의 모든 멤버 및 부모 컴포넌트 인스턴스로 전송되는 이벤트를 트리거한다.

* 온라인(Online) - 포트가 동작을 위해 준비가 되면, 포트는 이 상태가 된다. 이는 와이어 인스턴스의 모든 멤버 및 부모 컴포넌트 인스턴스로 전송되는 이벤트를 트리거한다.

* 오프라인(Offline) - 포트가 일반적인 동작을 중단하고자 하면 포트는 이 상태가 된다. 이는 와이어 인스턴스의 모든 멤버 및 부모 컴포넌트 인스턴스로 전송되는 이벤트를 트리거한다.

* 분리(Detached) - 포트가 와이어 인스턴스로부터 분리되면 포트는 이 상태가 된다. 이는 와이어 인스턴스의 모든 멤버 및 부모 컴포넌트 인스턴스로 전송되는 이벤트를 트리거한다.

* 삭제(Deleted) - 포트가 인스턴스 스페이스로부터 제거되었을 때 포트는 이 상태가 된다. 이는 부모 컴포넌트 인스턴스로 전송되는 이벤트를 트리거한다.

와이어 인스턴스 이벤트(Wire instance events)

와이어 인스턴스 이벤트는, 와이어 인스턴스가 생성되거나 삭제될 때 발생한다. 이 이벤트들의 목적지는 언제나, 와이어를 갖는 부모 컴포넌트 인스턴스이다. 도 38을 참고하라.

와이어 인스턴스는 그 멤버로의 포트 참조(port references)를 포함할 수도 있다. 이 와이어 멤버십(membership)은 일정한 멤버 포트 이벤트의 목적지를 결정한다. 상술한 예제를 계속 검토한다. "foo[2].c[2]"는 다음과 같은 다수의 새로운 인스턴스를 생성한다고 가정한다:

component instance universal[1]

component instance foo[2]

component instance c[2]

port instance y[1]

component instance b1[1]

port instance x[1]

component instance b2[1]

port instance x[1]

wire instance p[1]

b1[1].x[1]

b2[1].x[1]

와이어 인스턴스 "p[1]"은 2개의 포트 인스턴스, "b[1].x[1]" 및 "b2[1].x[1]"로의 참조를 포함한다는 것을 유의하여야 한다. 컴포넌트 인스턴스 "b1[1]" 및 "b2[2]"은 각각 별도의 기계를 실행시킨다고 가정하다. 도 39에, "b2[1]"이 그 포트 상태를 오프라인으로 바꾸었을 때 이벤트가 발생하는 것이 도시되어 있다.

"b2[1]"은 기계 3 상에 호스팅되고, 이는 런타임 상의 "포트 상태 설정(set port state)"를 발동시킨다는 것을 유의하여야 한다. 런타임은 변경을 기록하고 3개의 상태를 전송한다 - 한 개는 와이어 인스턴스 소유자 "u[1].foo[2].c[2]"로 전송되고, 두 개는 와이어 포트 인스턴스 멤버, "b1[1].x[1]" 및 "b2[1].x[1]"로 전송된다.

이벤트 전달(Event Delivery) 및 큐들(Queues)

런타임은 이벤트들을 순서대로 전달하는 것을 보장하지만, 소정의 와이어 인스턴스의 모든 멤버들 사이의 완전한 가상 공시상태(synchronism)를 보장하지는 않는다. 즉, SDM 런타임은, 컴포넌트 인스턴스가 천천히 운영되거나 정지하더라도, 앞으로의 진행이 가능하도록 할 수 있다.

SDM 사건들은 각각의 컴포넌트 인스턴스에 대하여 큐된다. 만일 이벤트가 대상의 큐들에 성공적으로 큐되면, 이벤트를 트리거한 동작은 성공으로 간주된다. 큐들은 본래 원형이고, 만일 컴포넌트가 심하게 지체되거나 멈추면 순환 반복한다. 순환 반복함으로써 새로운 "순환 반복(wrap-around)" 이벤트가 생성될 것이다. 이 사건은, 컴포넌트 인스턴스 자신뿐만 아니라 부모와 임의의 소유 팩토리들에게도 보내진다.

런타임 분할

다수의 클라이언트를 지원하기 위하여, 런타임은 분할될 수 있다. SDM 인스턴스 스페이스의 엄격한 계층때문에, 이 문제는 아주 다루기가 쉽다. SDM 런타임은 특정 배포에 걸친 많은 기계에서 호스트가 될 수 있다. 각 SDM 런타임 인스턴스는 인스턴스 스페이스의 일부를 추적하는 역할을 한다. 컴포넌트 인스턴스들은 SDM 런타임 라이브러리를 사용하여 적절한 런타임과 통신한다. 도 40은 분할된 런타임과 몇몇의 클라이언트들을 도시한다.

기계(1)는 두개의 컴포넌트 인스턴스와 SDM 런타임 라이브러리를 포함한다. 기계(2)는 단일 컴포넌트 예와 런타임 라이브러리를 포함한다. 기계(3)는 전용 SDM 런타임에 대해 호스트가 된다. 기계(4)는 SDM 런타임과 컴포넌트 인스턴스를가진다. 기계(3, 4) 상의 두개의 SDM 런타임이 통신한다는 것을 또한 알아야 한다.

분할

런타임은 SDM 내의 본래의 고유 계층에 영향을 줘서 자신을 분할한다. 분할 행위는 SDM 유형과 인스턴스 스페이스의 부분들을 다른 동작 런타임 예들에 걸쳐 분산하는 것을 포함한다. 분산은 비율화(scalability)를 위해 반드시 필요하다. 분산은 유형들과 예들에 대해 다르게 발생한다.

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

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

componenttype B {

port X x;

}

componenttype C {

port Y y;

component B b1;

component B b2;

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

componenttype A {

port internal Z z;

component C c;

wire W w { z; c.y}

}

componenttype universal u {

component A foo;

component A bar;

}

이 정의는 세 컴포넌트 유형(A, B, C)를 포함한다. A는 루트 범용 컴포넌트(root universal component)의 멤버이다. B와 C는 A의 멤버들이다. 도 41에 도시된 바와 같이, 멤버 스페이스를 그림으로 나타내었다. 복합 컴포넌트들을 나타내기 위해 상자들이 사용될 것이다. 다른 복합 컴포넌트들이 아닌 복합 컴포넌트 멤버들이 컴포넌트 상자 안에서 설명된다. 이 예에서, 와이어 "w"은 복합 컴포넌트 "foo"와 "bar"의 멤버이고, 따라서 "a" 상자 안에 나타낸다.

인스턴스 스페이스에서, 각 컴포넌트, 포트 및 와이어의 많은 예들이 있다. 인스턴스 계층이 도 42에 도시된다. 여기에서 상자는 컴포넌트 인스턴스에 대한추적된 인스턴스 상태를 나타낸다. 이것은 컴포넌트 인스턴스 구현 코드가 아니다.

세개의 런타임, 런타임1, 런타임2 및 런타임3 사이에서 SDM 모델을 분할하기를 원한다고 가정하자. 도 43은 예 스페이스를 분할하는 예시이다. 이 예에서, 런타임1은 "범용[1]", "foo[1]", "foo[2]" 및 "bar[1]"을 추적한다. 런타임2는 "foo[1].c[1]", "foo[1].c[2]" 및 "foo[2].c[1]"을 추적한다. 런타임3은 "bar[1].c[1]"을 추적한다. 게다가, 런타임들은, 런타임이 추적하는 인스턴스들에 대한 모든 유형에 대해 알아야 한다. 이 예에서, 런타임3은 부모 "bar"에 의한 컴포넌트 유형 "C", "B" 및 "A"에 대해 알아야 한다. 또한, 포트 유형 "Y"와 와이어 "P"에 대해서도 알아야만 한다.

다른 런타임들은 또한 그들의 관계를 보유하고 있어야만 한다. 이 관계는 SDM 계층에 의해 요구된다. 전의 예에서, 런타임1과 런타임2은 "foo[1].c[1]", "foo[1].c[2]" 및 "foo[2].c[1]" 관계를 관리하기 위해 각각을 알아야만 한다. 유사하게, 런타임1과 런타임3은 "bar[1].c[1]"을 둘러싼 작업을 조정해야만 한다. 런타임2와 런타임3은 서로에 대해 알 필요가 없다는 것에 주목하자.

분할 방법

런타임은 자기 분할을 위한 충분한 논리를 포함한다. 특정 분할 방법은 수행, 용량 및 SDM 정의 제약들에 기초한다. 이 분할은 동적이고 SDM 모델이 발달함에 따라 변화한다.

단일루트 런타임(Single-root Runtime)

단일루트 컴포넌트 예의 모든 예들인 복합 컴포넌트 인스턴스들을 추적하는 런타임들은 단일루트 런타임들로 참조된다. 위 예시에서, 런타임1 및 런타임3은 단일루트 런타임들이다. 런타임1은 "universal[1]"에서 시작하는 루트 인스턴스 트리를 가지고, 런타임3은 "bar[1].c[1]"에서 시작하는 루트 인스턴스 트리를 가진다.

다중루트 런타임(Multi-root Runtime)

루트 복합 컴포넌트 예를 갖지 않는 복합 인스턴스들을 추적하는 런타임들은 다중루트 런타임들로 참조된다. 위 예시에서, 런타임2은 모두 루트들인 "foo[1].c[1]", "foo[1].c[2]" 및 "foo[2].c[1]"을 추적하기 때문에 다중루트 런타임이다.

서비스 설치

소정의 SDM 런타임 상에서 서비스가 설명되기 전에, SDM 런타임이 먼저 설치되어야 한다. 설치 과정은 다음 단계들을 포함한다.

서비스 배포 유닛을 런타임 배포 할당(runtime deployment share)으로 복사하는 단계

SDM 런타임 API를 호출하여 설치를 시작하는 단계

서비스 배포 유닛들

SDU는 서비스 배포 유닛이다. 이는,

SDM 어셈블리 - 새로운 서비스에 대한 유형 정보이다. 이 서비스에 대한 모든 컴포넌트 유형, 와이어 유형들 및 포트 유형들을 포함한다. 이 어셈블리는SDML 서비스를 컴파일한 결과이다.

런타임-호스트 컴포넌트 인스턴스 코드(Runtime-hosted component instance code) - 런타임에 의해 호스트되고 SDML 내의 구현 키워드에 의해 참조되는 임의의 CLR 코드는 SDU에 포함되어야 한다.

다른 서비스 바이너리들(binaries) - 구성 파일들, DLL, GIF, HTML, SQL 스크립트 등과 같은 모든 다른 바이너리들이 배포 유닛의 일부로 또한 간주된다.

로 구성된다.

SDU는 변경되지 않는다. SDU에 대한 변경은 허용되지 않는다. 일단 SDU가 설치되면, 변경될 수 없다. 물론, 업그레이드된 새로운 버전의 SDU를 설치할 수 있고, 예전 버전(들)을 사용하지 않을 수 있다.

SDU 형식

SDU는 SDM 런타임에 의해 사용되는 바이너리들의 디렉토리이고 잠재적인 컴포넌트 팩토리들이다. 디렉토리는 형식상 큰 제약이 없으나 다음 구조가 기대된다.

\sduroot

\<assembly name>.<version>

\<assembly name>.sdmassembly

\bin

\<Runtime hosted CLR assembly_1>.dll

\<Runtime hosted CLR assembly_2>.dll

\<Runtime hosted CLR assembly_n>.dll

\<other files and directories>

SDU는 CAB 파일로 포장된다.

구현

SDM 런타임은 IIL 서버 상에서 동작하는 .NET 웹서비스로서 구현된다. SDM 저장은 신뢰성 있는 SQL 서버 데이터베이스이다. SDM 런타임 웹서비스는 비상태유지(stateless) 웹서비스이다. 즉, SDM 런타임 서비스 내의 임의의 상태는 일시적이다. 모든 영속적인 상태가 명확한 처리 경계들에 있는 기억장치에 기록된다.

SDM 런타임 서비스는 종료되고 임의의 지점, 서로 다른 기계들에서조차 재시작될 수 있다. 만일 SDM 런타임이 동일한 SDM 기억장치에서 지시되면, 모든 작업이 방해가 없거나 거의 없이 다시 시작될 수 있다.

SDM 기억

SDM 런타임은 SDM들과 인스턴스들을 위해 영속적인 기억장치를 이용한다. 이 기억장치는, SDM 런타임 서비스와 같이 동일한 기계 상에 통상적으로 위치하지만, 확실히 다르게 배포될 수 있다. SDM 기억장치는, 모든 SDM 모델들과 그들의 인스턴스들에 대한 정보를 포함하는 SQL 서버 데이터베이스이다.

SDM 기억장치의 이러한 신뢰성과 가용성은 필수적이다. SDM을 위한 키 설계 목적들 중의 하나는, 마지막에 아는 일관된 상태(last know consistent state)에서 시스템을 재시작할 수 있는 능력이다. SDM은, 따라서, 높은 신뢰성을 필요로 하고, 큰 재난 시나리오들에서 견뎌야만 한다. 이는 두가지 방법으로 구현된다.

SDM 기억장치는 복제되고 여분의 핫 백업은 언제나 사용 가능하다. 이는 유콘의 여분 데이터베이스 기술(Yukon's redundant database technology)을 사용하여 구현된다.

SDM 기억장치는 정기적으로 백업되고 사이트 밖에서 저장된다. 백업은 현 모델들, 예들, 및 SDM 기억장치 내에 저장된 임의의 서비스 상태의 자기-일관 스냅샷(self-consistent snapshot)이다.

서비스 기억장치

SDM 런타임은 컴포넌트 인스턴스 레벨에서 저장을 용이하게 한다. 모든 컴포넌트 인스턴스는 런타임 API를 사용하여 데이터를 SDM 기억장치에 저장한다. 반-구조 기억장치(semi-structure store)를 고려하더라도, 최소한 이 기억장치는 BLOB 기억장치이다.

런타임에 저장된 서비스 상태는 SDM 런타임만큼 신뢰성 있고 영속적인 것이 보장된다. 서비스 상태는 또한 다른 런타임 상태와 일관성 있는 것이 보장된다. 서비스가 충분한 정보를 그들의 상태에 (지시자들의 측면에서) 저장하는 것을 기대하는 대신에, SDM 기억장치 내에 저장될 모든 서비스 상태에 대해 말하는 것은 물론 아니다. 복구되면, 서비스는 그 데이터의 지시자들을 검색하고 필요한 단계들을 수행할 수 있다. 아래의 복구를 보자.

SDM 런타임 보안

시나리오 설명

SDM 런타임을 위한 보안 모델을 정의할 두개의 기본 시나리오가 있다. 개발자 테스트-런 시나리오와 오퍼레이터 생산 배포 시나리오이다. 두 시나리오에 대한 공통적인 요구사항은 다음과 같다.

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

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

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

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

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

개발자 테스트 런 시나리오

개발자는 테스트 환경에서 분산 애플리케이션을 하나 이상의 서버로 배포할 수 있어야 한다. 대상 서버들은 단독 워크그룹의 일부이거나 동일한 액티브 디렉토리 도메인 내에 있다. 테스트 런 배포가 초기화되는 컴퓨터는 타겟 서버(들)로써 동일한 워크그룹이나 도메인에 있어야만 한다.

1. 개발자는 비쥬얼 스튜디오(Visual Studio)를 사용하여 서비스 배포 유닛(Service Deployment Unit; SDU)를 생성한다.

2. 생성된 SDU는, SDM 런타임 서비스가 실행되는 컴퓨터 상의 배포 폴더 내에 위치한다.

3. 개발자는 배포 행동(설치, 업데이트, 설치제거)을 선택하고, 윈도우 인증적격에 대해 상기한다.

4. 개발자는 인증을 받고, 인증받은 사용자가 요청된 배포 동작을 수행하도록 허가되는지를 결정하는 배포 역할에 매핑된다.

5. 개발자는, 어느 컴포넌트들을 어느 타겟 서버들 상에서 설치, 업데이트 또는 삭제할지를 선택한다.

6. SDM 런타임 서비스는 두 방법 중 하나로 선택된 타겟 서버들에 연결된다. 만일 SDM 런타임 서비스가 액티브 디렉토리에서 신뢰 서비스 계정으로써 동작하고 있다면, 타겟 서버들 상의 계정으로써 연결될 것이다. 그렇지 않으면, SDM 런타임 서비스는 인증된 사용자처럼 연결될 것이고, 이는 인격화가 가능하지 않다면 타겟 서버에서 추가적인 인증을 필요로 할 수 있다.

오퍼레이터 생산 배포 시나리오

오퍼레이터는 데이터 센터 환경에서 분산된 애플리케이션을 하나 이상의 서버에 배포해야 한다. 타겟 서버들은 액티브 디렉토리 도메인 또는 포레스트의 부분이어야 한다. 테스트 런 배포가 초기화되는 컴퓨터는 타겟 서버(들)로써 동일한 도메인 또는 포레스트 내에 있어야 한다.

1. 애플리케이션 SDU는 SDM 런타임 서비스가 실행되는 컴퓨터 상의 배포 폴더 내에 위치한다.

2. 오퍼레이터는 배포 행동(설치, 업데이트, 설치제거)을 선택하고 도메인 적격에 대해 상기한다.

3. 오퍼레이터는 인증되고, 인증받은 사용자가 요청된 배포 동작을 수행하도록 허가되는지를 결정하는 배포 역할에 매핑된다.

4. 오퍼레이터는, 어느 컴포넌트들을 어느 타겟 서버들 상에서 설치, 업데이트 또는 삭제할지를 선택한다.

5. SDM 런타임 서비스는 신뢰 서비스 계정으로써 선택된 타겟 서버들에 연결되고 동작을 수행한다.

특징 설명

행동 특정

SDM 런타임은 모든 SDM 클래스, 유형 및 인스턴스를 추적하는 것을 담당한다. SDM 런타임은 분산된 애플리케이션을 배포하기 위한 목적으로 SDM 문서에서의 운영과 등록을 위해 SOAP 인터페이스 세트를 공개한다.

SDM 런타임은 다음의 주요 컴포넌트들을 포함한다.

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

윈도우 서비스,

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

도 44는 SDM 런타임 컴포넌트들, 배포 도구 및 타겟 서버들 사이의 관계를 도시한다. 도 44에서, 사용자는 배포 행동을 초기화하기 위해 배포 도구 UI 또는 명령-라인 인터페이스와 상호 작용한다.

런타임 라이브러리는 웹 서비스에 의해 공개된 SOAP 인터페이스들의 세트를 제공한다. 웹 서비스는 배포 행동을 수행하기 위해 윈도우 서비스가 검색하는 데이터베이스에 정보를 기입한다. 웹 서비스는 윈도우 인증을 사용하여 SDM 런타임데이터베이스에 대해 사용자를 인증하고, 데이터베이스에 의해 정의된 역할들에 기초한 배포 행동들을 허가한다.

생산 환경에서, 윈도우 서비스는 액티브 디렉토리 서비스 계정으로써 수행되고 타겟 서버들은 관리 목적으로 도메인 서비스 계정을 신뢰하도록 구성된다. 윈도우 서비스는, 서비스 계정의 인격화(사용자가 아님)를 사용하는 타겟 서버들과 원격에 있는 WMI를 사용한다. 이러한 신뢰 서비스 모델은 더욱 축소 가능하고 사용자당 기반의 목적 서브 ACL들을 관리할 필요를 최소화한다. 오퍼레이터들은 배포 동작들을 실행하기 위하여 타겟 서버들 상에서 관리자들이 되지 않아도 된다.

테스트 런 환경에서, 윈도우 서비스는 액티브 디렉토리 서비스 계정 또는 액티브 데릭토리가 없는 비-특권 네트워크서비스 계정 중의 어느 하나로써 수행된다. 후자는 타겟 서버들 상에서 인증된 사용자 계정의 인격화를 요구한다.

UI 설명

SDM 런타임 자체를 위한 UI는 없다. SDM 런타임은, 배포 도구 UI를 통하거나 명령-라인 도구들의 세트를 통해 야기될 수 있는 API들의 세트를 공개한다. 배포 도구 UI는 별도의 문서 내에서 특정된다.

보안 모델

SDM 런타임을 위한 보안 모델은 타겟 서버들로 접근하는 고정된 신원을 사용하는 신뢰 서브시스템 모델이고, 이러한 고정 서버들로 분산 컴포넌트들이 배포된다. 인증된 사용자의 보안 컨텍스트는 이 모델에서 타겟 서버들까지 이르지 않는다. 이 보안 모델의 기본적인 가정은 타겟 서버들이 SDM 런타임 서비스의 고정된신원을 신뢰한다는 것으로, 따라서 타겟 서버들 상의 각각의 사용자들을 위한 관리권을 처리할 필요를 제거한다. 도 45는 고정된 신원 신뢰 관계를 도시한다.

신뢰 서브시스템으로, 신뢰 도메인 계정 하에서 확실히 SDM 런타임 서비스를 구동하거나, 심지어 지역 비-특권 네트워크서비스 계정으로써 이를 구동할 수 있다. 이해의 요점은 임의의 배포 행동에 대한 인증은 역할-기반 허가를 사용하여 SDM 런타임에 의해 관리된다는 것과, SDM 런타임 서비스만이, 일단 사용자가 인증되고 요구된 배포 동작을 허용하는 역할에 매핑되면, 타겟 서버들 상에서 설치, 업데이트 및 설치제거 행동들이다.

인증

인증은 사용자의 신원을, 사용자와 근원적인 보안 기반시설에만 알려진 적격 비밀(credential secrete)에 기초하여 입증하는 과정이다. 분산형 애플리케이션 배포의 목적으로, 액티브 디렉토리 도메인 계정들 또는 지역 계정들을 통해 사용자는 윈도우 인증을 사용하여 인증된다. 지역 계정들이 사용되면, 배포 컴퓨터 상의 지역 계정 이름들과 암호들은 타겟 서버들 상에서 동일해야만 한다.

허가

일단 사용자가 인증되면, 설치, 업데이트 또는 설치제거와 같은 배포 동작을 수행하기 위한 허가가, 인증된 사용자가 멤버인 데이터베이스 역할에 기초하여 승인된다. 윈도우 사용자와 그룹 계정들은 SQL 서버 데이터베이스 역할의 멤버들이기 때문에, 기본적인 허가 순서는 다음과 같다.

1. 웹 서비스는 윈도우 인증을 사용하여 사용자를 인증한다.

2. 웹 서비스는 인증된 사용자로써 데이터베이스에 연결된다.

3. 사용자는, 사용자 또는 그룹 계정 멤버쉽에 기초하여 데이터베이스 역할에 매핑된다.

4. 웹 서비스는, SDM 런타임의 윈도우 서비스 컴포넌트에 의해 비동기적으로 판독될 수 있는 적절한 데이터베이스 테이블에 배포 행동 정보를 기입한다.

운영 체제 기반 시설 밖에서 암호를 관리할 필요없고 사용자 단위로 타겟 서버들 상의 ACL들을 관리할 필요가 없다는 점에 주목하자.

인격화(Impersonation)

인격화는 현재의 과정 소유자가 아닌 다른 계정의 보안 컨텍스트 내의 코드를 실행하는 능력이다. 타겟 서버들로의 원격 연결들은 인격화를 작동시킨 상태에서 WMI를 사용하여 설정된다. 인격화는, 액티브 디렉토리가 존재할 때 신뢰 서비스 신원에 기초하고, 액티브 디렉토리가 사용 가능하지 않을 때(예를 들면, 테스트 런 환경) 인증된 사용자의 보안 컨텍스트에 기초한다.

윈도우 서비스

SDM 런타임의 윈도우 서비스 컴포넌트는 타겟 서버들 상의 관리권과 함께 서비스 계정으로써 구동되어야 한다. 타겟 서버들 상에 소프트웨어를 설치하고 IIS, SQL 및 등록을 위한 다양한 설정을 생성하는 요구 조건들이 있기 때문에, 관리권이 필요하다.

액티브 디렉토리 도메인 계정이 없는 경우에, 윈도우 서비스는 타겟 서버들 상에서 관리 행동들을 수행하도록 허가된 사용자 계정을 인격화한다. 이 경우에윈도우 서비스는 암호를 요구하지 않는 네트워크서비스 계정으로써 구동하고 지역 컴퓨터 상의 비-특권 사용자이다. 윈도우 서비스는 연결될 때 지역 컴퓨터 적격을 원격 컴퓨터에 제공한다.

IIS

SQL 서버

SQL 서버는 두개의 인증 모드를 운영할 수 있다. 윈도우 인증 모드와 혼합 모드이다. 윈도우 인증 모드는 혼합 모드보다 안전하기 때문에, SDM 런타임 데이터베이스를 위한 SQL 서버는 윈도우 인증 모드만을 위해 구성된다. 이것은 sa 계정이 SDM 런타임 데이터베이스를 인증하는데 사용하지 못하도록 한다. SDM 런타임 데이터베이스에 대한 관리 특권들은 액티브 디렉토리 인증 기반시설에 영향을 주기 위하여 윈도우 그룹 멤버쉽을 통해 제어된다. SQL 서버를 관리하고 특정 사용자들을 그룹에 추가하기 위해 액티브 디렉토리 그룹을 사용함으로써, 특별한 계정 상의 암호들을 관리할 필요 없이 SDM 런타임 데이터베이스로의 접근을 제어하는 것이 보다 용이해진다.

SDM 런타임 데이터베이스에 부가하여, SQL 서버를 구동하는 타겟 서버들은 또한 윈도우 인증 모드를 사용하고 윈도우 그룹 멤버쉽을 통한 관리 접근을 처리한다. SDM 런타임 데이터베이스를 위한 윈도우 그룹과 타겟 서버들을 위한 윈도우 그룹은 서로 다른 그룹들이어야 한다. 고객이 SQL 서버 기계들을 관리하기 위해 하나 또는 몇몇의 윈도우 그룹을 가질지는 정책적 결정이다.

예를 들면:

SDM 런타임 관리자 그룹

사용자 A, 사용자 B

SQL 서버 계층 1 관리자 그룹

사용자 C, 사용자 D

SQL 서버 계층 2 관리자 그룹

사용자 C, 사용자 E

SDM 서버 개요

소개

SDM 서버란 무엇인가 - SDM 서버는 SDM 주변을 바탕으로 하는 서비스들의 세트이다. 현재, 두개의 배포 도구의 아키텍쳐 상으로 접근하는 두가지 일반적인 방법이 있다. 각각이 여기서 설명된다.

분산 접근

이 접근에서, SDM 런타임과 배포 엔진을 사용하는 도구들은, 웹 서비스를 사용하여 SDU(의 바이너리들)를 위치시키기 위한 파일 할당 및 SDM 런타임 엔진과 교대로 통신하는 런타임 OM 클라이언트 라이브러리에 대해 형성된다. SDM과 배포 엔진들은 배포 일들과 SDM 엔티티들의 데이터베이스를 공유한다. 배포 태스크들은 WMI와 SMB (파일 할당)을 사용하는 배포 엔진들에 의해 비동기적으로 수행되어 목적 기계들과 통신한다.

단순 접근

이 접근에서 클라이언트, SDM 객체 모델 라이브러리, SDM 엔진, 및 설치자 플러그-인들 모두가 동일한 프로세스에서 구동하여 그러한 서비스가 없다. 런타임 데이터베이스와 바이너리들은 다른 기계들에 있을 수 있다. WMI와 SMB의 목적 기계들로의 접속은 클라이언트나 UI가 구동되는 곳에서 직접 이루어진다.

사용자 인터페이스 및 다른 클라이언트들

SDM 서버를 위한 사용자 인터페이스는 다음을 포함한다.

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

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

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

런타임 OM 라이브러리

SDM 서버의 일반 인터페이스는 이 라이브러리를 통한다. 이는 관리되는 코드 객체 모델이고 이를 사용하여 다음을 할 수 있다.

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

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

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

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

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

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

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

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

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

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

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

SDM 런타임 엔진

SDM 런타임 엔진은 SDM 모델 상에서 추론과 객체 모델에 의해 나타나는 기능들을 수행한다.

분산형 접근에서, 라이브러리는 웹 서비스로써 런타임 엔진과, SDM을 로딩하고 컴포넌트 인스턴스를 생성하고 (SDM 엔티티들 상에서 반사하기 위해) SDM 전체를 획득하는 등의 적절한 코스 콜(course call)을 사용하여 통신한다. 이는 서버로의 왕복을 감소시킨다. 이 웹 서비스를 위한 많은 파라미터의 포맷은, SDM 파일들에 대해 동일한 구성을 가진 XML이다.

어떤 면에서, 웹 서비스는 SDM 서비스의 모든 기능을 클라이언트 라이브러리에 제공하여 사용하기에 훨씬 간단하게 만든다.

분산 접근에서, 엔진은 허가에 대한 체크를 수행한다(자세한 사항은 보안 설명서 참조).

설치자 플러그-인들

설치자 플러그-인들은 클래스 호스트 관계와 연관된다. 이들은 밀접하게 클래스에 대한 설계 경험을 제공하고 SDU 내의 연관된 바이너리들과 배포 값들을 생성하는 비쥬얼 스튜디오를 사용하는 플러그-인과 관련된다. 이들은 다음 기능을 SDM 서버에 제공한다.

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

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

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

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

심사 설정(Audit settings)

심사 존재(Audit existence)

가득 찬 심사(Audit Full)

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

컴포넌트들의 매핑 설정

인터페이스

베이스 메카니즘들의 세트를 호스트들 상의 지역 시스템으로써 실행 명령과 같은 설치자들에 제공한다. 장래, 다른 것들이 넷 주소와 계정만을 요구하는 그 이상의 메카니즘들을 제공한다.

인터페이스는 관리되는 코드이다.

설계

다음 섹션들은 데이터 센터들로 호스트되는 분산형 애플리케이션들과 데이터 센터들을 어떻게 설계할 것인지를 설명한다. 설계자는 SDM을 사용하여, 데이터 센터에 이용되는 물리적 자원들의 구성에 사용되는 다양한 빌딩 블럭들(예를 들면, 하드웨어, 네트워크, 호스트 서버들)과 애플리케이션들을 만든다.

데이터 센터 설명

이 섹션은, 많은 기계들과 같은 특정 자원들을 나타내지 않고 데이터 센터 컴포넌트들을 만드는 방법을 설명한다. 이는 서비스 정의 모델(service definition model; SDM) 의미론을 사용하여 물리적 데이터 센터 환경의 스케일-불변(scale-invariant) 모델을 제공한다.

가상 데이터 센터(virtual data center; VDC)는 데이터 센터에 대한 개발자의 관점을 단순화하는 물리적 데이터 센터 환경의 논리적 표현이다. 이상적으로, IT 전문가 또는 건축가는, 개발자가 분산형 애플리케이션/서비스를 설명할 수 있는 동일한 스케일-불변 방법으로 데이터 센터를 설명할 수 있다. VDC는 데이터 센터와 그들의 토폴로지 관계들 내의 서버, 네트워크 및 저장 자원들의 추상적 개념이다.

전형적인 데이터 센터 다이어그램은, 비지오나 유사 도구를 사용하여 하나의 다이어그램으로 그려져 나타낸 다중 상호연결된 서버, 네트워크 장비, IP 주소, VLAN, 운영 체제, 저장 장치 등으로 아주 복잡하다. 다이어그램에 부가하여, 어떻게 데이터 센터가 분할되고, 구성되고 관리되는지를 정확히 설명하는 긴 문서들이 보통 있다.

이 복잡성의 예는 마이크로소프트 시스템 아키텍쳐(Microsoft Systems Architecture; MSA) 사업 데이터 센터(Enterprise Data Center; EDC)이다. 손으로 그려진 다이어그램들과 문서들을 수회 데이터 센터의 상태로 업데이트와 업그레이드가 적용되면서 현재 유지하는 것이 불가능하면 태스크가 아니라면 고비용이 된다는 것은 당연하다. 유사하게, 문서 규정들에 대한 환경을 유효하게 하는 능력이 어렵고 사람에 에러를 범하기 쉽게 한다.

MSA EDC와 같은 복잡한 데이터 센터를 스케일-불변 방법으로 나타내는 능력은 개발자와 IT 전문가 양측에 아주 강력하다. 데이터 센터를 컴포넌트, 포트, 와이어을 사용하여 설명하는 능력은 강력한 프레임워크를 제공하고, 이 안에서 오늘날의 설계과 배포 프로세스에서 사라진 배포 요건들을 만들고 유효화한다.

데이터 센터 설명의 일면은 집합적 컴퓨팅 환경을 위한 하드웨어와 구성 메카니즘들을 사실화하는 능력이다. 전통적인 데이터 센터 환경에서, 오퍼레이터들은 전형적으로 특정 애플리케이션에 맞는 하드웨어 환경을 제작한다. 예를 들면,새로운 이메일 시스템을 데이터 센터에 배포할 때, 오퍼레이터들은 서버 세트를 구매하고, 네트워크 어댑터들을 백업과 데이터 존과 같은 다른 네트워크를 위해 더하고, 스위치와 로드 밸런서와 같은 네트워크 하드웨어를 더한다. 애플리케이션을 위한 하드웨어의 배포는 물리적인 노력을 더 필요로 한다.

만들기에 비싼 애플리케이션 특정 하드웨어 구성들이 손으로 제작될 뿐만 아니라, 쉽게 변경되지도 않는다. 이들의 고정된 본성은, 업무 로드가 변경됨에 따라 자원들이 쉽게 새로운 애플리케이션들로 이동해 가므로, 빈약한 자원 활용이 된다.

이러한 개시 내용은, 오퍼레이터들이 서버들, 저장 장치 및 네트워크 장치들을 포함하는 물리적 자원들의 하나의 풀을 구동할 수 있도록 하는 데이터 센터 사실화 환경을 생성하는 방법을 설명한다. 이 하나의 풀로부터, 요청에 따라 자원들이 할당되고 배포되어 애플리케이션 필요를 만족시킨다. 자원 세트 제공자들은 자원들의 소유를 추적하고 애플리케이션 필요를 만족시키기 위하여 어떻게 자원들을 구성하는지를 안다.

새로운 애플리케이션을 데이터 센터 환경에 배포할 때, 오퍼레이터들은 애플리케이션이 필요로 하는 자원들의 추상화 기술을 생성한다. 요청은, 추상화 기술이 진정한 자원들로 바뀌도록 요구하는 서비스 플랫폼과 관련된다. 서비스 플랫폼은, 자원 관리자들과 협력하여 요청을 실행할 수 있는 자원들을 위치시키고, 가장 경제적으로 요청을 실행하는 자원들을 선택하고, 사용되는 자원들을 마킹하고, 자원들을 구성하여 요청 요건들에 맞추고, 할당된 자원들의 구체적 설명을 추상화 기술에 위치시킨다. 애플리케이션의 필요가 변경됨에 따라, 오퍼레이터는 자원 설명을 업데이트하고 서비스 플랫폼이 업데이트 애플리케이션 설명을 분석하도록 요구한다. 각각의 자원 제공자들은 물리적 자원들을 구성하여 애플리케이션 필요를 만족시키는 하드웨어 또는 OS 특정 소프트웨어 드라이버들을 사용할 수 있다.

데이터 센터 설명과 연관된 개념들은 (1) 바람직한 자원들, 자원 요청들, 및 승인된 자원들을 설명하기 위한 그래프 언어; (2) 소정 유형의 사용 가능한 자원을 알고 이 자원들을 구성하여 애플리케이션 요건들을 만족시키는 능력을 가진 도메인 특정 자원 제공자들의 세트; 및 (3) 자원 요청들을 처리하고, 자원 제공자들과 통신하여 적절한 가용 자원들을 찾고, 특정 자원들의 선택을 선택적으로 최적화하고, 자원 제공자들에게 선택된 자원들을 구성하도록 요구하고, 선택된 자원들을 반영하도록 자원 요청을 업데이트하는 자원 관리자를 포함한다.

애플리케이션 설명

애플리케이션들은 유사하게 SDM 의미론을 사용하여 정의될 수 있다. 이는 0 단락에서 시작되는 SDM 섹션을 참조하여 더욱 상세히 위에서 설명된다. 도 20은 구조가 큰 비율의 분산형 애플리케이션을 SDM 의미론의 측면에서 설명하도록 하는 그래픽 사용자 인터페이스(UI)를 보여준다.

애플리케이션의 물리 시스템으로의 논리적 배치

일단 애플리케이션들 및 가상 데이터 센터들이 SDM 의미론을 사용하여 구성되면, 구조는 논리적으로 애플리케이션 요소들을 가상 하드웨어 요소들의 논리적으로 다르게 위치시키는 것을 시도한다. 다른 배포 환경(개발, 테스트, 생산 등)에대해 다른 논리 위치가 있을 수 있다. 논리 위치는 설계 시에 이루어질 수 있고, 요건 및 제약이 체크되고, 개발자는 임의의 에러나 경고에 대해 경계한다. 논리 위치의 결과는, 각 컴포넌트, 포트 및 와이어 클래스 상에 특정된 X패스와 XSD를 사용하여 구현되는 제약 체크와 함께 별도의 파일에 기록된다. 이것은 도 21에 도시된다. 설계자는, 다른 애플리케이션 요소들을 물리 요소들에 위치시킬 때, 직관적 제스처를 위한 UI(사용자 인터페이스)를 사용할 수 있다.

설계 시간 유효성 검증

다음 섹션은 애플리케이션을 물리적 자원들에 논리적으로 위치시키는 설계 시간 유효화에 대한 접근을 설명한다. SDM 컴포넌트들로의 확장, 포트 및 와이어은 계층과, 분산형 애플리케이션 설계의 설계-시간 유효화를 달성하는 계층과 배포 요건들 사이의 매핑을 추가한다.

컴포넌트, 포트 및 와이어링 호스트, 팩토리, 자원 관리자 및 SDM 런타임과 결합할 때, 강력한 추상적 개념이지만, 이들은 분산형 애플리케이션/서비스를 배포하고 관리하는데 충분하지 않다. 이러한 논리 추상적 개념의 물리적 인스턴스들을 생성하고 관리하기 위하여, 몇몇의 부가적인 구조들이 포함된다. 이러한 부가적인 구조들은 계층들이고 매핑들이다.

계층들

도 11은 SDM에 의해 정의되는 계층 추상적 개념을 나타낸다.

애플리케이션 계층은 애플리케이션/서비스의 관점에서 분산할 수 있는 컴포넌트들, 이들의 배포 요건들과 제약들, 및 이들의 통신 관계를 설명한다.

배포 계층은 구성과 정책 설정과 IIS, CLR 및 SQL 등과 같은 호스트들에 대한 제약들을 설명한다.

가상 데이터 센터(Virtual Data Center; VDC) 계층은 데이터 센터 환경 설정과 네트워크 토폴로지를 통해 서버, 네트워크 및 저장 장치에 이르기까지 운영 체제로부터의 제약들을 설명한다.

하드웨어 계층은 물리적 데이터 센터 환경을 설명하고, 예를 들면, XML을 사용한 선언적인 방법으로 드러나거나 특정된다. 이 계층은 스케일-불변이 아니고, 따라서, SDM 내에 만들어지지 않고, 완성을 위해 포함된다.

매핑들

SDM은 계층으로 이루어지기 때문에, 여러 계층들을 묶는 방법이 필요하다. 매핑은 반드시 하나의 계층에 있는 컴포넌트나 포트를 다음 계층 아래에 있는 컴포넌트나 포트에 묶는다. 매핑은 다음과 같이 설명될 수 있다.

M_T= [T_n→T_n-1]+[T_n-1→T_n-2]+[T_n-2→T_n-3][...]

M은 매핑을 나타내고, T는 컴포넌트, 포트 또는 와이어를 나타내고, n은 계층을 나타낸다. 화살표는 항상 상위 계층에서 하위 계층으로 향하는 매핑의 방향을 나타낸다.

예를 들어, 도 12에서, MyFrontEnd라고 명명된 애플리케이션 계층에서의 컴포넌트는 IIS라고 불리는 배포 계층의 컴포넌트로 매핑된다. 같은 방식으로, MyBackEnd라고 명명된 컴포넌트는 배포 계층의 SQL 컴포넌트에 매핑된다.

설계-시간 유효성 검증

하위 계층의 컴포넌트와 그 호스트 컴포넌트 사이의 바인딩은, 애플리케이션/서비스가 실제로 라이브 데이터 센터에 배포되기 전에 개발자에게 문제가 될 수 있다. 이러한 문제는 양립하지 않는 유형, 구성 충돌, 부조화된 동작, 토폴로지 관계 결여 등에 기인할 수 있다. 예를 들어, 도 13에 도시된 시도된 매핑은, 배포 계층에서의 IIS와 SQL 컴포넌트들 사이에 잠재적인 통신 관계가 없기 때문에, 에러가 될 수 있다.

MyBackEnd 컴포넌트로부터 SQL 호스트 컴포넌트로의 매핑이 컴포넌트와 호스트 유형 양립성과 구성 충돌 결여에 기초한 유효한 바인딩이지만, MyService SDM이 MyFrontEnd와 특정 배포 계층에 존재하지 않는 MyBackEnd 사이의 토폴로지 관계를 정의하기 때문에 유효하지 않다.

계층 아키텍쳐

도 48은 분재된 컴퓨팅 시스템 상의 분산형 애플리케이션들의 자동화 설계, 배포, 및 관리를 위한 플랫폼 아키텍쳐를 보여준다. 아키텍쳐는, 분산형 컴퓨팅 시스템의 물리 컴퓨터 자원을 나타내는 베이스 계층(302) 최상위에 있는 다중 계층들을 보여준다. 자동화 배포 서비스 계층(304)는 기계를 분산형 컴퓨팅 시스템에 사용되는 서버로 변환하기 위한 도구들을 제공한다. 이러한 도구들은, OS(운영 체제) 영상들의 생성, 편집 및 배포를 허가한다. 기계의 원격 프로그래밍은, 시스템과 네트워크 장치들이 구성되고 관리되도록 하는 마이크로소프트 윈도우(Microsoft's Windows?) 운영 체제 내의 프로그래밍 인터페이스(API)인WMI(Windows Management Instrumentation)와 같은 완전한 프로그램 인터페이스들을 사용하여 달성된다.

네트워크 관리 계층(306)은 자동화 배포 서비스 계층(304)의 최상위에 위치한다. 네트워크 관리 계층(306)은 네트워크 관리와 가상 토폴로지 생성을 고려한다. 부분적으로, 네트워크 관리 계층은, 각 컴퓨터들의 하나 이상의 VLAN으로의 네트워크 스위치들의 관련 포토에 연결되는 단일 물리 네트워크 인터페이스를 통한 접속을 용이하게 하는 네트워크 컴퓨터를 위한 드라이버 모델을 지지한다. 드라이버 모델에 따라써, VLAN 드라이버는 서버에 설치되고 단일 물리 네트워크 인터페이스 상위의 가상 네트워크 인터페이스들(VNICs)을 생성하도록 사용된다. VLAN 드라이버는 각 VLAN을 위한 하나의 가상 네트워크 인터페이스(VNIC)를 생성한다. VNIC들은 서버에 있는 IP 스택 내에서 네트워크 인터페이스(NIC) 바로 위에 상주하여, 모든 패킷이 동일한 물리 NIC를 통해 지나가지만, 서버는 하나 이상의 VLAN을 거쳐 통과하는 패킷들을 다룰 수 있다.

드라이버 모델은, 속하는 VLAN의 신원으로 태그를 달기 위해 데이터 패킷들이 분산형 컴퓨팅 시스템을 지나가도록 태그를 단 VLAN을 지지한다. 네트워크 스위치들은 태그를 달고 스위치가 속하는 VLAN을 확인하는 태그를 가진 패킷들을 수신하기만 한다. 일실시예에서, 네트워크 스위치들은 태그가 달린 포트들과 태그가 달리지 않은 포트들 모두를 가진다. 스위치의 태그 달린 포트들은 VLAN 확인자로 태그가 달리고 다른 스위치들의 태그 달린 포트들로의 접속을 위해 사용된다. 이는 스위치 네트워크를 통한 패킷들의 빠른 전송을 가능하게 한다. 스위치의 태그가 달리지 않은 포트들은 서버들 또는 컴퓨터들로의 접속을 위해 사용된다. 패킷들이 이들의 타겟 서버에 도달했을 때, VLAN 태그들은, 상위의 패킷들을 서버들에 전달하기 전에, 패킷들로부터 제거되어 서버들은 태그에 대해 알 필요가 없다.

물리적 자원 관리 계층(308)은 네트워크 관리 계층(306)의 최상위에 상주한다. 물리적 자원 관리 계층(308)은, 소유를 추적하고 모든 물리 컴퓨팅 자원들의 할당을 조정하면서, 분산형 컴퓨팅 시스템의 물리 모델을 유지한다. 물리 관리 계층(308)은 또한, 뱃치(batch) 자원 할당을 지원하여, 물리 컴퓨팅 자원들의 동적 구성과 관리를 가능하게 한다.

논리적 자원 관리 계층(310)은 물리적 자원 관리 계층(308)의 최상위에 위치한다. 논리적 자원 관리 계층(310)은 분산형 애플리케이션에 의해 요청되는 논리적 자원들의 할당을 용이하게 한다. 예를 들면, 애플리케이션은 데이터 베이스 로드 밸런스 서비스, 방화벽, 웹 서비스 등의 자원을 요구할 수 있다. 논리적 자원 관리 계층(310)은 이러한 논리적 자원들을 공개한다.

다음 계층은 서비스 정의 모델과 런타임 계층(312)인데, 이는 분산형 애플리케이션을 과 그 동작의 추적을 설명할 수 있다. 서비스 정의 모델(service definition model; SDM)은 동작 프로세스를 설명하기 위한 네임스페이스과 관점, 및 애플리케이션 자체감시(introspection)와 애플리케이션 자원들의 제어를 위한 API를 제공한다.

컴퓨팅 자원들 계층 최상위의 6번째 계층은 컴포넌트 계층(314)이다. 이 계층은, SDM API들을 관점, 명명 및 바인딩을 위해 사용하는 분산형 애플리케이션의재사용 가능한 빌딩 블럭들의 정의를 허용한다.

최상위 계층은 동작 논리 계층(316)인데, 이는 분산형 애플리케이션의 동작 측면을 수용한다. 동작 논리는 서비스를 시작하고, 서비스를 발전 및 위축시키고, 업그레이드 및 다운그레이드시키고, 오류를 탐지 및 복구하고, 상태 분할하는 것을 담당한다. 동작 논리는, 배포들 및 애플리케이션들에 걸쳐 입증된 동작 실행의 재사용을 가능하게 한다. SDM 계층의 사용을 통해, 동작 논리는 발생할 수 있는 놈점을 더 잘 이해할 수 있다. 예를 들면, 오류가 발생할 때, 동작 논리는, 방 가운데의 어떤 서버라기 보다 이메일 서비스의 앞쪽 끝에서 발생했다는 것을 결정할 수 있다.

배포

다음 섹션들은 데이터 센터들 및 분산형 애플리케이션들의 배포를 설명한다. 이는 논리 모델들의 즉각성, 애플리케이션의 물리 위치, 및 애플리케이션과 데이터 센터의 배포를 포함한다. 도 23은 일반적으로 배포 단계를 도시한다.

즉각성(Instantiation)

SDM 유형들은 비율 불변이고 임의의 비율로도 생성될 수 있기 때문에, 배포의 일면은, 소정의 논리 컴포넌트 및 와이어 토폴로지에 대해 생성되는 인스턴스들의 수를 정의하여 물리적으로 하드웨어/애플리케이션을 구현하는 것이다. 인스턴스 요청 문서는, 생성될 필요가 있는 인스턴스들의 선언적 정의를 제공하도록 생성된다.

애플리케이션의 물리적 배치

물리적 배치(physical placement)는 배포(deployment)의 대상인 특정한 호스트 인스턴스를 추출하는 행위를 말한다. 물리적 배치는 논리적 배치(logical placement)에 의해 제약 받으며, 제약 조건들(constraints)은 물리적 배치 중에 업데이트된다. 물리적 배치들은 물리적 배치 파일 내에 저장된다.

데이터 센터 및 애플리케이션 배포

SDU, 논리적 배치 파일, 인스턴스 요구 및 물리적 배치 파일은 SDM 런타임으로 공급된다. SDM 런타임은, 호스트 상에서 새로운 인스턴스를 생성하여 그 종류 상에서의 설정 값들을 부합시키는 책임이 있는 (클래스 및 호스트 관계에 기초하여) 적절한 설치자(installer)를 불러낸다. SDM 런타임은 모든 인스턴스들, 그들의 최종 설정 값들 및 위치의 데이터베이스를 유지할 것이다. 런타임 API는 인스턴스 스페이스의 질문들을 지원한다.

BIG 배포 도구

시나리오 설명

특징 요약

BIG 배포 도구는 데이터센터 오퍼레이터들과 애플리케이션들을 시험하는 개발자들에 대한 분산형 SDM 애플리케이션 배포를 수행한다. 이것에 의해, 애플리케이션 (SDU)의 비트들, 맵핑 파일들, 및 배포 제약 조건들의 세트를 포함하는 SDM(Service Definition Model) 애플리케이션들을 소비하게 된다. 사용자는 사용자의 서버들에 대한 애플리케이션의 배치를 특정하고 배포 시간 설정들을 제공한다. 상기 도구는 원격 기계들에 대한 인스턴스들을 설치하거나 설치제거하며, 상황들을 오퍼레이터에게 제공한다. 오퍼레이터는 이후에 새로운 인스턴스들, 사용 중지 인스턴스들(decommission instances)을 추가하고, 애플리케이션의 토폴로지를 재구성할 수 있다.

시나리오들

대기업은 개별적인 데이터센터와 개발자 조직(developer organization)을 가진다. 데이터센터는 종업원들과 고객들 모두에 대해 서비스를 하는 최종 사용자들(end-users)에 대한 애플리케이션을 배포, 유지 및 호스팅한다. 데이터센터의 토폴로지는 가끔 변경하여 BIG 컴퓨터가 아닌 MSA EDC 1.5와 밀접하게 부합한다.

데이터센터 조직은 개발자들에게 소위 LIM(Logical Information Model)이라고 하는 호스팅 폴리시(hosting policy)의 스케일 불변 추상화(scale-invariant abstraction)를 제공한다. 상기 폴리시는 애플리케이션들에 대한 제약 조건들, 허용 설정들, 및 기본적인 토폴로지를 포함하는 호스트들의 구성을 규정한다.

개발자 조직은 최종 사용자들의 요구에 부합하고 데이터센터의 폴리시 내에 머무르도록 이들 애플리케이션들을 코딩하고 핫 픽스한다. 개발자는 애플리케이션들 요구들 및 예상된 호스트들을 규정함으로써 배포 지침(deployment guidance)을 제공한다.

애플리케이션 오퍼레이터는 데이터센터 내의 애플리케이션들을 배포하기 위하여 BIG 배포 도구를 사용한다. 상기 배포 도구는 적절한 배포를 보장하기 위하여 개발자 지침(developer guidance) 및 데이터센터를 사용한다. 애플리케이션 오퍼레이터는 나중에 상기 배포 도구를 사용하여 애플리케이션 토폴로지를 스케일-아웃(scale-out), 재구성하거나 또는 설치제거한다.

특징 설명

행동 규격(Behavioral Specification)

이하에서는 상기 배포 도구가 어떻게 "Whidbey" 및 다른 제품들과 조화를 이루는지에 대한 개관을 설명한다. SDM 런타임, LIM, SDM/SDU 및 Whidbey는 다른 규격들로 설명되는 것에 유의하여야 한다. 도 49는 애플리케이션 배포에 대한 예시적인 사용 흐름을 나타낸다.

도 49에서의 통신에 대한 중요한 점들은 다음과 같다(좌로부터 우로).

개발자는 SDM, 2진수들 및 SDU 맵핑들을 포함하는 애플리케이션 SDU를 전달한다. (여기서 애플리케이션 비트들과 콘텐츠를 의미하도록 2진수들을 사용한다.)

개발자 및 데이터센터 조직은 별개이지만 동일한 LIM을 공유한다. 상기 배포 도구를 구현하는 기계에는 저장 장치와 API들을 갖는 SDM 런타임이 있다.

애플리케이션 오퍼레이터는 데이터센터 설명, 배포 설명에 대해 책임이 있으며, LIM, SDU 및 SDU 맵핑들을 사용한다.

에이젼트 및 "미니 팩토리들(mini-factories)"이 대상 서버들에 상주하며, 이러한 서버들은 배포를 위한 입력으로서 SDU, 배포 디스크립터(Deployment Descriptor), 및 데이터센터 디스크립터(Datacenter Descriptor)를 갖는다.

에이전트들은 공통의 미니 팩토리 API를 사용하여 미니 팩토리들과 대화한다.

본 실시예에서의 미니 팩토리들은 SQL 및 IIS이며, 다른 제품들로 확장 가능하다. 이들은 설치, 구성, 및 설치제거의 작업을 할 수 있다.

설정들 및 제약 조건들의 개관

BIG 배포 도구는 SDM 애플리케이션들을 소비한다. 상기 배포 도구가 어떻게 설정들과 제약 조건들을 사용할 것인지를 이해하기 위해서, 여기에서 SDM과 함께 설정들과 제약 조건들의 기초적인 개관을 제공한다. 설정들, 제약 조건들, 및 스키마에 대한 완전한 설명을 위해서는 관련된 설명을 참조하기 바란다. 본 논의에서, 설정들/제약 조건들이 SDM 메타-타입, 타입 또는 멤버 상에 있는지 여부는 구별하지 않는다.

SDM 모델에 의해, 개발자들, 네트워크 아키텍트들(Network Architects), 및 애플리케이션 오퍼레이터들이 설정들/제약 조건들(네트워크 아키텍트 및 개발자들), SDU 맵핑들(개발자들), 및 배포-시간 설정들(애플리케이션 오퍼레이터들)을 제공할 수 있는 능력을 가질 것이다. 이러한 제약 조건들 및 설정들은 각각 그 자신의 스키마, 규칙들, 및 값들을 가지는 호스트(즉, IIS, SQL, BizTalk) 마다 범위가 정해질 것이다.

각각의 호스트의 공개그룹의 설정들은 애플리케이션에 의해 설정 가능한 것들과 호스트에 의해 보존되는 것들로 분할될 것이다. 여기서 전자의 것은 애플리케이션 설정들이라고 하고, 후자의 것은 호스트 설정들이라고 하기로 한다. 또한, 호스트는 "호스트 제약 조건들(host constraints)"을 규정함으로써 애플리케이션 설정들을 제한하며, 애플리케이션은 "애플리케이션 제약 조건들(applicationconstraints)을 통해 호스트 설정들에 필요 조건들을 부여한다. 필요 조건들은 설정 값 범위이거나, 특정한 값 또는 변하는 값일 수 있다.

다음의 표는 호스트들 및 애플리케이션들에 대한 설정들 및 제약 조건들을 요약하고 있다.

표 1: 설정 정의들

설정들/제약 조건들의 정의	예
애플리케이션 설정들 - 설정들은 애플리케이션에 관한 개발자에 의해 만들어짐	쇼핑 애플리케이션: maxWorkerThreads=8401k 애플리케이션: maxWorkerThreads=4
애플리케이션 제약 조건들 - "호스트 설정들"에 대한 필요 조건들이 애플리케이션을 구현하는데 필요함	Mode=WorkerProcessIsolationMode
호스트 설정들 - 자원에 호스팅된 모든 애플리케이션에 대한 설정들의 그룹	Mode=WorkerProcessIsolationMode
호스트 제약 조건들 - 애플리케이션 설정들에 대한 한계들(정확한 값들, 값들의 범위)	High-perf 호스트: maxWorkerThreads<25Best-effort 호스트들: maxWorkerThreads<5

LIM(Logical Information Model)의 목표는 데이터센터의 정책과 배포 블록커들(deployment blockers)의 추상화된 관점을 제공하는 것이다. LIM은 호스트 제약 조건들/설정들과 애플리케이션 제약 조건들/설정들 간의 분할을 나타낸다. LIM이 갖는 정책은 네트워크 아키텍트에 의해 저술된다. 이러한 정책은 네트워크 아키텍트, 개발자에 의해 LIM 파일로 분류되거나, 노트패트(Notepad)로 편집되는 정규 마이크로소프트 LIM(canonical Microsoft LIM)을 사용하여 용이하게 될 수 있다.

그 후, LIM은 개발자들에 의해 사용되어, 애플리케이션들을 기록하고 데이터센터의 표현에 대해 시험하게 된다. 개발자들은 LIM이 허용하는 애플리케이션 설정들에 대한 값들, 애플리케이션이 구현하고 있는 호스트 제약 조건들, 및 호스트들 상에 컴포넌트들을 배치하는 것에 대한 메타데이터를 애플리케이션의 일부로서 제공한다. 개발자들은 맵핑 파일을 통해 호스트들 상에 애플리케이션의 배치에 관한 지시를 제공한다. 비특정 설정들은 애플리케이션 오퍼레이터들이 제공하는 배포-시간 설정들로서 전달될 것이다(즉, IP 주소 또는 App_pool_ID).

기본적인 예는, 네트워크 아키텍트가 "High-perf" 호스트들 및 "Best-effort" 호스트들에 관한 서비스들을 구입하는 고객들에 대한 다른 호스트 제약 조건들을 규정하는 것이다. 호스트 제약 조건은 "IO" 또는 "WorkerThreads"의 수를 다르게 제한할 수 있다. 이 예에서, "High-perf" 호스트 설정들 및 "Best-effort" 호스트 설정들은 동일하며, IIS_6'의 새로운 모드를 사용한다. 개발자는 두 개의 애플리케이션을 다른 예산과 요구 조건으로 기록할 것이다. 제1 쇼핑 애플리케이션(Shopping application)은 더 많은 "WorkerThreads"를 원할 것이다. "401K 애플리케이션"은 덜 차별적이다. 두 애플리케이션은 모두 "WorkerProcessIsolationMode"에서의 구현을 억제(요구)한다. 도 50은 애플리케이션 설정들 및 제약 조건들과, 호스트 설정들 및 제약 조건들을 나타내고 있다.

배포의 국면들

BIG 배포 도구를 사용할 때, SDM 애플리케이션 배포 주위에는 후술하는 바와 같이 네 개의 국면(phase)이 있다. 도 51은 배포 도구에 대한 예시적인 국면들을 나타내고 있다.

초기 국면(Initial Phase)은, LIM이 산출되어 스케일 불변 방식으로 데이터센터에서 나타내고 그 후 하드웨어 분류 파일(데이터센터 디스크립터)을 생성하는국면이다.

애플리케이션 개발 국면(Application Development Phase)은, 개발자가 LIM에 대해 코딩하고 배포 도구 API들을 사용하여 개발자의 SDM 애플리케이션을 시험 및 디버그하는 국면이다.

설치 국면(Install Phase)은, 애플리케이션 오퍼레이터가 이미 구성된 기계에 애플리케이션들을 설치하는 국면이다.

실행 국면(Running Phase)은, 애플리케이션 오퍼레이터가 토폴로지를 스케일-아웃 및 재구성하거나, 이미 실행되고 있는 애플리케이션을 설치제거하는 국면이다.

본 명에서 전체에 걸쳐 또한 본 흐름도에 있어서 "배포(deployment)"라는 용어를 사용하는데, 이는 필요한 호스트 설정/제약 조건 검사, 호스트 및 애플리케이션 양립 불가능성의 신호, 애플리케이션 설정들의 기록, 및 미니-팩토리 액션을 호출 등을 모두 포함하기 위함이다. 미니 팩토리 액션들은 설치와, 설치제거를 수행하고, 구성하고, 또한 Fusion, MSI 또는 미래의 마이크로소프트 설치자로 훅(hook)하는 모든 것들이다.

초기 국면

초기 국면은 LIM과 데이터센터 디스크립터가 생성되는 시점이다.

데이터센터의 네트워크 아키텍트는 "Microsoft.com"으로부터 가장 근접하게 부합하고 디지털 서명된 LIM을 선택하여 다운로드한다. 그 후, 네트워크 아키텍트는 파일을 편집하여 네트워크 토폴로지, 허용된 애플리케이션 설정들, 및 호스팅제약 조건들을 포함하는 원하는 데이터센터 정책들을 반영한다.

또한, LIM은 "Visual Studio Whidbey"의 디자인 표면(design surface)으로 저술될 수 있다. 그 다음 단계에서, 네트워크 아키텍트는 요즈음 "Word" 문서나 "Visio" 도면으로 캡쳐되는 모든 관련된 정책 및 토폴로지 정보를 개발자 조직에게 부여한다. 그 후 개발자는 데이터센터를 나타내는 적절한 LIM을 생성하고, 정확성을 보장하기 위하여 네트워크 아키텍트와 반복한다.

일단 LIM이 생성되면, 데이터센터 조직은 데이터센터 디스크립터 파일을 생성함으로써 LIM에 따라 그 자신의 하드웨어를 분류한다. 데이터센터 디스크립터는 실행되고 있는 하드웨어에 대한 LIM 컴포넌트들을 맵핑하며, 이를 분류 작업(act of classification)이라고 한다. 그러므로, 데이터센터 디스크립터는 스케일 변동적이지 않으며, IP 주소와 같은 기계 고유의 상세를 포함한다. 다음의 도면은 데이터센터 디스크립터를 시각화하지만, UI를 제시하지는 않는다. LIM이 "IIS gold" 및 "IIS silver" 논리적 호스트들의 개념을 가질 수 있다는 것에 유의하여야 한다. 데이터센터 디스크립터에서, 이들 논리적 호스트들이 물리적 기계들로 맵핑됨으로써, "IIS[1] gold"가 IP 주소 "192.168.11.2"에 위치하고, "IIS[2] gold"가 IP 주소 "192.168.11.3"에 위치하게 된다. 도 52는 데이터센터 디스크립터의 예시적인 시각화를 나타내고 있다.

데이터센터 오퍼레이터가 서버들, 네트워크, 자원들, 및 애플리케이션 아래의 모든 것들을 설치/구성함에 따라, 동작들(actions)은 LIM 내에 머무를 필요가 있다는 것에 유의하여야 한다. (데이터센터 오퍼레이터는 애플리케이션 아래의 모든 것에 대해 책임이 있다는 것에 유의하여야 한다.) 네트워크 아키텍트 및 데이터 오퍼레이터 양자는 상기 배포 도구 외부에서 그들의 작업을 수행한다.

애플리케이션 개발 국면

이 국면에서, 개발자는 LIM에 대해 코딩하고, BIG 배포 도구 API들을 사용하여 배포들을 시험/디버그한다. 이러한 LIM은 데이터센터에 의해 제공되거나 또는 데이터센터를 대신하여 개발자에 의해 분류된다(상술한 바와 같음).

배포 도구 API들은 "Visual Studio Whidbey"에 대한 두 개의 시나리오가 "F5" 및 "시험/디버그" 배포들을 수행할 수 있도록 한다. F5 및 시험/디버그 배포들은 각각 단일 개발자 박스(single developer box) 및 다중 기계들에 대한 것이다. F5 시스템에서, 필요한 비트들은 이미 대상 단일 개발자 박스에 있다. 시험/디버그의 경우, 통상의 배포들에서와 마찬가지로, 상기 배포 도구가 대상 기계(들)에게 비트들을 전달하도록 요구한다. 그러나, F5 및 시험/디버그 시나리오들은 개발자들로 하여금 충돌하는 설정들에 대해 경고를 받게 하고, 애플리케이션 및 호스트 설정들을 중복 기입(overwrite)한다. (통상적으로, 단지 애플리케이션 설정들만이 상기 배포 도구에 의해 기록될 수 있다.) 이들 VS 시나리오들은 SDM 런타임을 사용하지 않을 것이라는 것에 유의하여야 한다. 도 53은 이들 VS 시나리오들을 나타내고 있다.

Visual Studio "F5" and "시험/디버그" 시나리오들에 대한 중요한 경고들(caveats)은 다음과 같다.

BIG 배포 도구 API들은 마법사(wizard)를 통하여 VS로부터 호출될 것이다.

VS 마법사는 배포할 기계들을 선택하고 배포-시간 설정들(즉, IP_address 또는 App_pool_ID=17)을 얻을 것이다.

VS는 사용자 인터페이스를 실행할 것이다.

F5 시나리오에서, SDM, SDU, 2진수들, 및 모든 비트들은 이미 대상 단일 개발 박스에 존재한다. 따라서, 기록 설정들이 필요한 모든 것이 된다.

시험/디버그 루프에서, "배포"는 필요한 설정들을 기록하는 것을 포함한다.

두 시나리오들은 설정들이 충돌할 때 신호를 보내며, 호스트 및 애플리케이션을 포함하여 대상 기계들의 설정들을 중복 기입하도록 한다.

개발자가 LIM에 대한 SDU 맵핑들의 개념과 LIM에 대한 애플리케이션을 코딩하는 것에 대해서는 도 53에 나타내지 않았다. (LIM에 대해 더 자세한 것은 LIM/LID 설명 부분을 참조하기 바람.) 개발자는 애플리케이션 오퍼레이터에게 SDM, 2진수들, SDU 맵핑 파일들을 포함하는 SDU를 전달한다.

설치 국면

설치 국면에 있어서, 오퍼레이터는 애플리케이션(맵핑들을 갖는 SDU) 및 데이터센터 디스크립터(이것은 LIM을 확장한다)를 제공 받는다.

애플리케이션 설치를 나타내는 도 54에 있어서, 다음의 경고들이 중요하다.

애플리케이션 오퍼레이터가 상기 도구(GUIGCLI)를 착수한다.

모든 파일들과 데이터센터 설명을 복사하여 로딩한다.

애플리케이션은 SDM 런타임에서 등록된다.

애플리케이션 오퍼레이터는 애플리케이션 컴포넌트들의 호스트/기계를 선택한다. (실시예들은 다음 항목에서 제공된다.)

이러한 선택(이것을 "맵핑"이라 한다) 중에, 런타임의 관점(Runtime's view of the world)에 대해 제약 조건들이 검사된다. 만약 이러한 도구의 외부의 설정들을 변경하여 디스조인트 뷰(disjoint view)를 일으킬 경우에는 어떠한 결과도 보장할 수 없다.

배포는 호스트 및 애플리케이션 제약 조건들/설정들 검사를 수행하고 설치한다. (네트워크 고장을 피하기 위해 캐시 상에 설정 ACL 및 캐싱 파일을 구비하는 경우 실행이 더욱 복잡해질 것이라는 것에 유의해야 한다.)

상기 도구는 UI 또는 도큐멘테이션(documentation)을 통해 상태 데이터(stateful data)(예컨대, 현재 차지하고 있는 SQL 데이터베이스)를 취급할 수 없다는 것을 분명히 한다.

이상의 단계들은 배포 설명(Deployment Description)을 생성하며, 이것은 구체적인 배포를 위해 재사용되거나 수정될 수 있다. (실시예들은 다음 부분에서 제공된다.)

"미리 보기(Preview)" 기능은 상기 도구가 행하는 변경들의 리스트를 애플리케이션 오퍼레이터가 구할 수 있도록 한다. 그러면, 사용자는 미리 보기가 생성된 배포 디스크립터를 사용하여 상기 도구를 재실행할 수 있다.

이미 생성된 배포 디스크립터가 로딩되고 실행되며, SDM 런타임이 애플리케이션을 알고 있다고 가정하면, 애플리케이션 비트들은 여전히 이용 가능하며, 동일한 데이터센터 디스크립터가 유효하다. 도 54는 예시적인 설치 시나리오를 나타낸다.

배포를 규정하는 실시예

배포를 규정하는데 필요한 데이터의 흐름을 명백하게 하기 위하여, LIM을 통해 데이터센터를 제약하는 MSN의 예를 사용한다.

LIM은 디지털적으로 서명하고, 시간 날인하고, 버전을 붙일 수 있다. 개발 조직은 LIM을 사용하여 MSN 데이터센터의 호스트들(IIS 및 SQL 서버들) 상에 호스팅된 두 계층의 애플리케이션을 코딩한다. 개발자는 컴포넌트가 호스팅되어야 하는 호스트를 규정하며, SDU 맵핑 파일을 생성한다. 이러한 MSN 예를 도 55에 나타내고 있다.

다음은 도 55에 관한 것으로 애플리케이션 배포에서의 데이터 흐름을 나타내고 있다.

SDU는 SDM을 포함한다.

개발자는 SDU 컴포넌트들을 LIM(MSNdatacenter.LIM)으로 맵핑하여, SDU 맵핑 파일을 생성한다. 맵핑들은 허용 가능한 위치들이다.

데이터센터 디스크립션은 LIM 컴포넌트들에 따라서 실제적/물리적 서버들을 분류하며, 스케일 불변이다.

SDU, SDU 맵핑들, 데이터센터 디스크립션, 및 사용자 입력은 상기 배포 도구로 공급되어 배포 디스크립터를 생성한다.

배포 디스크립터는 (SDU로부터의) 컴포넌트들을 규정하여 (데이터센터 디스크립션으로부터의) 기계들 상에 설치한다.

배포 디스크립터는 URL 등의 배포-시간 설정들을 얻는다.

도 55는 배포 디스크립터 파일을 생성하는 예를 나타내고 있다.

상기 예에서, SDU 맵핑 파일은 개발자가 SDM 컴포넌트 2TierApp.MyWeb를 MSN에 구속된 호스트 컴포넌트 MSN9.IIS_MSN로, 마찬가지로 2TierApp.MyDB를 MSN9.SQL_MSN로 구속시킨다. (여기서 합성 컴포넌트(Compound Component)를 규정하여 다중 MyWeb들의 경우 불명확한 점을 없앤다.)

네트워크 아키텍트는 IIS 및 SQL 제약 조건들과 설정들을 어떻게 구성하는가를 나타내는 MSNdatacenter.LIM을 편집한다. 이러한 LIM은 스케일 불변인데, 왜냐하면 LIM이 IIS 또는 SQL을 실행하는 특별한 기계들이 아니라, IIS 및 SQL 호스트들을 나타내기 때문이다. 그 후, 데이터센터는 데이터센터 디스크립터를 유도하는데, 이러한 데이터센터 디스크립터는 어떠한 기계들이 LIM에서 구성된 바와 같이 IIS 및 SQL을 실행하는지에 대해 나타낸다. IIS_MSN 컴포넌트를 실행하는 두 개의 기계가 있다는 것을 나타내기 위하여 IIS_MSN[1] 및 IIS_MSN[2]의 표시를 사용한다.

BIG 배포 도구는 입력으로서 SDU, SDU 맵핑들, 데이터센터 디스크립터, (사용자가 공급한) 배포 설정들을 받아서, 배포 디스크립터를 생성한다. 본 예에서, 배포 디스크립터는 배포를 규정한다. 배포 디스크립터를 실행하면 대상 서버들에 대해 소프트웨어를 설치/스케일-아웃/재구성/설치제거 할 수 있다.

배포 디스크립터 본문에서 설명하는 바와 같이, MyWeb(MyWeb[1])의 경우는 서버 IIS_MSN[1]에 설치될 것이고, MyWeb[2]는 서버 IS_MSN[2]에 설치될 것이고,MyDB[1]은 서버 SQL_MSN[1]에 설치될 것이다. 배포-시간 설정들은 IP 주소 또는 App_Pool_ID 등의 애플리케이션 오퍼레이터에 의해 제공된다. 이러한 배포 디스크립터는 그것이 의존하는 파일들이 존재한다는 조건 하에서 재사용될 수 있다.

실행 국면

스케일-아웃[인] 시나리오

이미 실행되고 있는 애플리케이션에 있어서, 스케일-아웃[인] 시나리오는 애플리케이션 오퍼레이터가 컴포넌트, 포트, 또는 와이어를 추가[삭제]하도록 허용한다. 이러한 특징의 유용성의 예는 "Joe_Millionaire" 웹사이트일 수 있으며, 여기서 트래픽이 엄청나게 증가하고 정규 TV 시기에만 스케일-아웃하고 그 후(또는 밤마다)에는 스케일-인하는 것을 알 수 있다.

애플리케이션 스케일-아웃[인]에 대한 흐름도에 있어서, 다음이 중요한 점들이다.

스케일-아웃[인]은 설치의 서브 세트이다.

애플리케이션 오퍼레이터는 실행되는 SDM 애플리케이션을 선택하여 다음을 행할 수 있다.

컴포넌트들, 포트들, 와이어들을 추가하고, 배포-설정들을 기입하기.

컴포넌트들, 포트들, 및 와이어들을 삭제하기.

시나리오는 이미 생성되거나 변경된 배포 디스크립터로부터 실행될 수 있다. (동일한 데이터센터 디스크립터/LIM의 경고들이 애플리케이션에 대해 액세스한다고 가정할 때, SDM 런타임은 여전히 등록된 애플리케이션을 갖는다.) 도 56은 예시적인 스케일-아웃 시나리오를 나타낸다.

토폴로지-재구성 시나리오(Topology-reconfiguration scenario)

토폴로지-재구성에 의해 애플리케이션 오퍼레이터가 설치제거, 재설치 없이 실행되고 있는 애플리케이션을 리와이어(rewire)할 수 있다. 리와이어의 예들은 프론트 엔드 데이터베이스(front-end database)를 백엔드 데이터베이스(back-end database)로 변경시킬 것이다.

토폴로지-재구성에서의 중요한 점들은 이하와 같다.

이러한 시나리오는 설치제거, 재설치 없이 존재하는 포트 및 와이어들의 편집을 할 수 있다는 점에서 스케일-아웃과 다르다.

또한 잠정적으로 사용자들로 하여금 두 개의 다른 SDM 애플리케이션들을 "브릿지(bridge)"하는 것을 허용한다.

도 57은 예시적인 토폴로지-재구성 시나리오를 나타내고 있다.

토폴로지-재구성은 고장 시, 전체 애플리케이션을 재배포하고 싶지 않은 경우에 유용하다. 예컨대, "패스포트(Passport)"는 모든 신용 카드 번호를 백엔드에 저장하고 IIS 프론트 엔드를 통해 이용 가능하게 된다. 프론트 엔드가 고장이 나면, 데이터를 재배포/이전(redeploy/migrate)하기를 원할 수 있다. 그 대신에, (정상적인 설치의 일부로서) 새로운 프론트 엔드를 배포하고, 그 새로운 프론트 엔드를 패스포트 데이터베이스로 리와이어할 수 있다.

토폴로지-재구성과 브릿지하는 예는 "beta_MSN10" 애플리케이션이 "MSN9" 애플리케이션의 데이터베이스를 공유하기를 원했던 경우일 것이다. 애플리케이션 오퍼레이터는 "beta_MSN10"을 정상적으로 배포한다. 이제는, "beta_MSN10"의 프론트 엔드가 "MSN9"의 데이터베이스와 대화할 필요가 있으며, "MSN9"의 데이터베이스에서의 재구성(및 새로운 와이어)을 요구할 것이다.

설치제거 시나리오

설치제거 시나리오에 따라, 애플리케이션 오퍼레이터는 애플리케이션을 선택하고, 모든 실행되고 있는 인스턴스들이 삭제되며 런타임이 업데이트된다. 사용자는 설치제거할 정확한 인스턴스를 선택하지는 않는데, 이는 스케일-인 시나리오들을 통하여 가능하기 때문이다.

다음의 점들은 설치제거 시나리오에 있어서 중요하다.

설치제거는 존재하는(편집되었을 수도 있는) 배포 디스크립터를 통해 수행될 수 있다.

사용자는 설치제거할 애플리케이션을 선택하고 모든 인스턴스들을 제거한다.

상태 콘텐츠(stateful content)는 존재하는 수단을 통해 이러한 도구 외부에서 제거되어야 한다.

도 58은 예시적인 설치제거 시나리오를 나타내고 있다.

관리

이하의 부분에서는 데이터센터들의 관리와 데이터센터들이 배포된 후의 분산된 애플리케이션들에 대해 설명한다. 먼저 모델-기반 관리 도구에 대해 설명하고, 이후에 자체감시(introspection)/추적 메커니즘(introspection/ tracking mechanism)과 동작 논리(operational logic)에 대해 논의한다.

모델-기반 관리

델-기반 관리(또는 Ops 논리)가 처리되어, 애플리케이션의 SDM 기반 모델의 애플리케이션 개발자 목적 및 정책과 오퍼레이터의 정의들에 기초하여 물리적 환경으로부터 이벤트 트리거들을 받아들이고, 모델의 상황에서 일련의 태스크들 또는 프로세싱을 활성화하고 조직함으로써, 변화를 조장하고 모델과 물리적 세계 간의 일관성을 제공한다.

트리거(trigger) 또는 요청(request) 또는 다른 쓰레시홀드가 SDM에서의 특별한 인스턴스에서 목표한 이벤트일 것이다. 컴포넌트 인스턴스는 트리거를 수신할 것이고, SDM으로 표현된 전체 애플리케이션 및 하드웨어 환경의 상황의 제반 사항에 기초하여, 트리거에 의해 식별된 이슈를 어드레싱할 일련의 단계를 개시할 것이다. SDM으로부터의 애플리케이션 및 자원들의 문맥(context)은 이러한 자동화를 원활하게 하고 서비스의 동작 스탭에게 더 우수한 조작 용이성을 제공할 수 있는 능력을 부여한다.

도 59는 Ops 논리 또는 모델-기반 관리라고 하는 모델(BIG) 및 관리 부분들에 대한 전체적인 아키텍쳐 이다. 전체적인 아키텍쳐에서의 프로세서의 흐름을 요약하면 다음과 같다.

ㆍ 애플리케이션 개발자는 새로운 애플리케이션의 집합적 모델(SDM)을 정의할 수 있거나, 또는 최종 사용자 애플리케이션 또는 서비스를 구성할 수 있는 컴포넌트 종류들의 클래스들을 정의할 수 있을 것이다.

ㆍ 개발자 또는 동작 개발자는 실행되어야 하는 서버들의 최소 수를 설정하는 등, 동작을 위한 정책과 가이드라인을 갖는 모델에 컴포넌트 종류들을 주석 처리함으로써 모델에 "오퍼레이터 인텐트(operator intent)"를 추가할 수도 있을 것이다.

ㆍ 애플리케이션의 특별한 실행을 위해 실행된 인스턴스들의 유닛 모델 또는 SDM 런타임은 "Unit Model"에 유지될 것이다. 각 기계의 바람직한 상태를 유지하고 있는 인스턴스들과 물리적 기계 간에는 1대1 대응 관계가 있다.

ㆍ BIG의 자원 관리자들은 "Unit Model"과 작업하여 서버들의 물리적 세계에서의 변화를 수행한다.

ㆍ 각 서버는 부분적으로는 BIG에 의해 관리되고, 부분적으로는 오퍼레이터들에 의해 모델의 외부에서 관리될 것이다.

ㆍ 집합적 모델과 유닛 모델 간에는, 모델을 통하여 물리적 기계들로의 변화를 조직하고 오퍼레이터 목적을 실행하도록 하는 모멜-기반 프로세싱의 한 유형이 있다.

ㆍ 모델-기반 프로세스의 또 다른 유형은 다른 방법으로 처리될 것이고, 물리적 스페이스과 모델 간의 일치성을 제공할 것이다.

ㆍ 관리 영역에서, 모니터링 시스템(Monitoring System)이 이벤트들을 수집하고 그것들을 경고기들(alerts)로 그룹화할 것이다.

ㆍ 이벤트들과 경고기들에 사용되는 컴포넌트들은 중요한 이벤트들로 통지될 것이다. 이벤트 정보는 관여된 인스턴스 또는 런타임 SDM에 관한 정보와 함께 컴포넌트에 제공됨으로써, 모델에 맵핑을 제공할 것이다.

ㆍ 이벤트가 동작 트리거일 경우, 이벤트는 모델-기반 프로세싱을 트리거함으로써, 일련의 조직화된 애플리케이션 태스크들을 통해 물리적 기계들에서의 변화를 조장할 수 있다.

도 60은 관리의 표현 계층을 나타낸다. 이것은 수평적으로 쌓인 전체적 아키텍쳐의 모델 부분의 확대도이며, 집합적 모델은 SDM에 해당하고, 유닛 모델은 SDM 인스턴스 스페이스(Instance Space)에 해당한다. 전체적 자원 관리자는 개별적 자원 관리자들("팩토리들"이라 함)에 대한 요청들을 관리한다.

자체감시/추적 메커니즘

사용자 요청, 하드웨어 트리거, 또는 하드웨어 쓰레시홀드 등의 트리거가 선택되면, 적절한 동작 프로세스가 기동될 것이다. 동작 프로세스는 실행될 동작 태스크들의 세트일 것이다. 동작 태스크들의 실행은 오케스트레이션(orchestration)에 의해 프로세스 될 것을 요구하는데, 이는 각각의 태스크가 다음의 태스크 전에 개시 및 종료를 요구하고 장수명일 수 있는 트랜잭션이기 때문이다. 동작 프로세스들을 실행하기 위한 일련의 행동을 감시하는 엔진은 Ops 논리용 오케스트레이션 엔진이다.

잠정적으로 분산된 서버들 또는 하드웨어 자원에 대한 일련의 동작 태스크들에 오케스트레이션을 적용하는 것은 고유의 접근 방식이다. 이러한 Ops 논리의 특성들은 트랜잭션 프로세싱에 더 정교한 접근 방식을 제공한다.

ㆍ 장수명 - 동작 프로세스들은 몇일 또는 몇 달 등의 장시간 실행될 수 있다.

ㆍ 비동기 - 트리거 또는 이벤트는 트랜잭션 또는 프로세스를 개시할 수 있으나, 트리거된 태스크가 완료되어 다른 이벤트들을 프로세싱할 때까지 기다릴 수 없다.

ㆍ 트랜잭션 - 동작 프로세스에서의 단계들은 그것을 개시하거나 전송하는 에이전트, 그것을 수신하거나 프로세싱하는 에이전트, 및 태스크가 실패할 경우라면 변화를 취소하는 보상 프로세스(compensation process) 등의 액션들이다.

ㆍ 내구성 - Ops 프로세스들은 손상되거나 불안정되지 않고 장시간 지속될 필요가 있다.

ㆍ 높은 이용 가능성 - 높은 이용 가능성의 BIG 컴퓨터 및 서비스의 동작 프로세스들에 있어서는 신뢰성 뿐만 아니라 이용 가능성이 요구된다.

Ops 논리는 동작들과 애플리케이션 개발자들에게 BIG 환경에서의 트리거에 기초하여 일련의 오퍼레이터 행동들을 분류하고 표준화할 기회를 제공할 것이다. 일단 트리거가 활성화되면, 관련된 일련의 태스크들이 기동될 것이다. 특별한 상황에 대한 단계들은 개별 기계에 대한 명령, 애플리케이션 컴포넌트 인스턴스에서의 변화, 또는 모델 또는 인간 단계들에서의 변화를 포함할 수 있다. 각 단계는 개시 및 종료를 가지고 성공 또는 실패할 수 있는 트랜잭션이다. 이러한 태스크들을 거친 단계에 오케스트레이션 엔진을 사용함으로써, 프로세스를 관리하고, 추적하고, 보고할 수 있다. 오케스트레이션 엔진은 태스크를 개시하고, 그 진행 상황을 감시하고, 완료 또는 실패를 보고할 것이다. 또한 오케스트레이션은 오케스트레이션 프로세스가 어떻게 정의되었는가에 따라, 부분적 또는 완전한 실패의 상황에서 대안적인 행동들이 취해질 수 있도록 한다. 도 61을 참조하라.

자원 관리자

자원 관리자는 분산형 컴퓨팅 시스템 내에서 논리적 및 물리적 자원들을 할당하는 책임이 있다. 자원 관리자는 이용 가능한 하드웨어, 프로세스 자원 할당 요청들, 및 논리적 및 물리적 자원들의 트랙 오너쉽을 발견한다. 자원들의 다이나믹 풀(dynamic pool)에 대한 인터페이스를 제공함으로써, 자원 관리자는 서버 내의 이용 가능성 및 확장성(scalability)에 대한 베드락(bed-rock)을 제공한다.

자원 관리자는 스위치들 등의 네트워크 장치들과 컴퓨터들을 모두 포함하는 분산형 컴퓨팅 시스템 내의 모든 하드웨어를 소유하고 제어한다. 본 시스템 내의 하드웨어 자원들에 대한 액세스는 자원 관리자를 통해 제어된다. 또한, 자원 관리자는 로드 밸런싱 그룹들(load balancing groups) 등의 논리적 자원들을 제어하기 위한 기본적인 메커니즘을 제공한다.

자원 관리자는 본 시스템 내의 모든 자원 관리에 대한 공통적인 API를 제공한다. 서비스와 런타임은 자원 관리자 API를 통해 대화를 하여, 자원 질문들을 만들고, 자원들을 할당하고, 자원 요구들을 변경하고, 자원들을 해방시킨다.

BIG 자원 관리자

도입

특징 요약

BIG는 분산형 서비스 런타임, 공통 하드웨어 참조 플랫폼(common hardware reference platform), 및 자원 관리자를 정의한다. 분산형 서비스 런타임은 서비스에게 서비스 컴포넌트들을 정의하는 빼대(skeleton), 그들의 관계, 및 동작 논리의 형태로 확장성 및 이용 가능성에 대한 실행 환경을 제공한다. 상기 하드웨어 참조 플랫폼은 서비스가 1 내지 수천의 컴퓨터에 이르는 시스템들 상에서 실행될 수 있도록 하는 공통의 하드웨어 구조를 정의한다.

BIG 자원 관리자는 BIG 컴퓨터 내의 논리적 및 물리적 자원들을 할당하는 책임이 있다. 자원 관리자는 이용 가능한 하드웨어, 프로세스 자원 할당 요청들, 및 논리적 및 물리적 자원들의 트랙 오너쉽을 발견한다. 자원들의 다이나믹 풀에 대한 인터페이스를 제공함으로써, 자원 관리자는 BIG 기계 내의 이용 가능성 및 확장성에 대한 베드락을 제공한다.

이 문서는 목적, 아키텍쳐, 및 BIG 자원 관리자의 실행에 대해 설명한다. 제1장은 목적과 구동 시나리오를 설명한다. 제2장은 자원 관리자의 아키텍쳐와 그와 연관된 자원 제공자들을 설명한다. 제3장은 실행의 세부 사항과 API들을 설명한다.

논의(Discussion)

BIG 자원 관리자는 BIG 컴퓨터 내의 자원들의 할당 및 사용에 대한 관리에 대해 책임이 있다. BIG 자원 관리자는 스위치들 등의 네트워크 장치들과 컴퓨터들을 모두 포함하는 BIG 컴퓨터 내의 모든 하드웨어를 소유하고 제어한다. BIG 컴퓨터 내의 하드웨어 자원들에 대한 액세스는 자원 관리자를 통해 제어된다. 또한, 자원 관리자는 로드 밸런싱 그룹들 등의 논리적 자원들을 제어하기 위한 기본적인 메커니즘을 제공한다.

BIG 자원 관리자는 BIG 컴퓨터 내의 모든 자원 관리에 대한 공통적인 API를 제공한다. 서비스와 BIG 런타임은 자원 관리자 API를 통해 대화를 하여, 자원 질문들을 만들고, 자원들을 할당하고, 자원 요구들을 변경하고, 자원들을 해방시킨다.

자원 제공자들

자원 관리자는 자원 관리 내로 공통의 인터페이스를 제공하는 반면에, 실제적인 자원들의 지식은 자원 제공자들의 세트로부터 나온다. 자원 제공자는 특별한 클래스의 자원들의 존재와 관리에 관한 구체적인 지식을 갖는다. 예컨대, 네트워크 자원 제공자는 관리하는 VLAN들의 존재와 구체 사항들에 대해 알고 있다. BIG 내의 다른 자원 제공자들은 물리적 장치 제공자, "IIS VRoot" 제공자, "SQL" 데이터베이스 제공자, "CLR AppDomain" 제공자, 및 "Win32 Surface" 자원 제공자를 포함한다.

자원 제공자들은 자원-특정 지식으로 자원 관리자를 확장시킨다. 자원 제공자들은 자원에 특정된 요청들을 공통의 질문 형태로의 변환을 관리한다. 자원 제공자들은 제공자 조력자(provider helper) DLL을 통하여 자원-특정 구성 API들을 갖는 자원 관리자 API를 확장시킨다. 최종적으로, 자원 제공자들은 자원 관리자 데이터 저장 장치에 적절한 상태를 부가하여, 자원에 특정된 정보의 추적을 허용한다. 더 높은 레벨의 자원 제공자들은 더 낮은 레벨의 자원 제공자들 위에 쌓인다. 예컨대, "IIS VRoot" 자원 제공자는 물리적 장치 자원 제공자를 통하여 기계들을 할당한다. 자원 제공자들의 계층화에 의해 리던던시를 최초화하고, 자원 관리의균일성을 증가시킨다.

윈도우 내의 I/O 관리 시스템과 BIG 내의 자원 관리 시스템 간에는 강한 유사성이 있다. BIG 자원 관리자는 윈도우 I/O 관리자와 마찬가지로, 공통 API, 자원 액세스 제어용 공통 논리, 공통 자원 추적, 및 요청들을 위한 공통 메커니즘을 다양한 제공자들 세트를 통해 제공한다. BIG 자원 제공자들은 윈도우 장치 드라이버들과 마찬가지로, 별개 클래스의 자원들을 제어하기 위한 특별한 지식으로 관리 시스템을 확장시킨다. BIG 자원 관리자는 윈도우 I/O 관리자와 마찬가지로, 공통 엄브렐러(common umbrella) 하의 다양한 자원들을 통합하기 위한 모델을 제공한다.

자동 자원 관리 및 최적화

BIG 자원 관리자는 데이터센터 오퍼레이터가, 자원들에 대해 컴포넌트들을 할당하고 배치하는데 직접 관여할 필요가 없게 한다. 예컨대, 새로운 서비스가 BIG 컴퓨터에 설치될 경우, 오퍼레이터들이 어떠한 컴퓨터가 그 서비스를 배치할 것인지를 결정할 필요가 없다. 오퍼레이터들은 단지 서비스에 대해 자원 쿼터(resource quota)만을 부여하면 되고, 그러면 자원 관리자는 코어 네트워크 대역폭(core network bandwidth) 등의 제한된 공유 자원들을 보존하기 위하여 어떻게 최적으로 서비스를 BIG 컴퓨터 내에 배치할 것인지를 결정한다.

신뢰된 자원 제공자들의 기본 세트는 자원 관리자와 함께 컴포넌트 배치의 최적화에 관여한다. 자원 제공자들은 자원 관리자에게 배치 선택권들(placement choices)과 제공자-특정 관련 비용 선택권들(provider-specific relative cost preferences)을 제공함으로써 배치 최적화에 관여한다. 그러면, 자원 관리자는 전체적인 고려 사항과 각 자원 제공자의 국부적인 고려 사항간에 균형을 맞추어, 효율을 최대화하고 자원 사용을 최소화한다.

최적의 컴포넌트 배치는 계속되는 고려 사항이다. 시간이 지남에 따라, 개별적인 서비스가 요구하는 자원은 줄어 들거나 커진다. 이용 가능한 물리적 자원들은 새로운 장치가 BIG 컴퓨터에 부가되고 낡은 장치가 해제됨에 따라 변화한다. 자원 관리자는 주기적으로 배치 결정들을 재검사하여, 컴포넌트들의 이동에 대한 장점을 평가한다. 자원 제공자들은 자원 관리자에게 컴포넌트의 이전 비용을 제공함으로써 배치 재평가에 관여한다. 이동 비용은 비이동 저장 장치에 대해서는 엄청날 것이지만, 소속이 없는 IIS 컴포넌트의 경우에는 매우 작을 것이다.

BIG 자원 관리자는 오퍼레이터들로 하여금, 자원 할당이나 컴포넌트 배치에 대해 염려할 필요가 없게 한다. 자원 관리자는 또한 개발자들로 하여금, 복잡한 할당 논리를 기록할 필요가 없도록 하며, 개발자들은 대신에 단순히 자원 관리자에게 자원 요구 조건들의 그래프를 제공하기만 하면 된다. 자원 관리자는 논리적 및 전체적 자원 요구 조건 모두를 고려하여, 컴포넌트들을 BIG 컴퓨터 내에 최적으로 배치한다.

특징 설명

실행 환경

BIG 자원 관리자는 이용 가능성이 높은 SQL에 의해 지원되는 CLR 관리 서비스로서 실행한다. 각각의 BIG 기계는 HA SQL 클러스터 내의 SQL 서버 쌍을 통하여 복제된 단일 자원 관리자만을 가질 것으로 기대된다.

BIG 자원 제공자들은 BIG 자원 관리자 프로세스 내에서 실행한다. 자원 관리자는 자원 제공자들에게 조작할 수 있는 비동기 실행 환경과, 그들의 상태를 저장하는 공유 데이터베이스를 제공한다. BIG 동작 논리 모델을 사용함으로써 모든 자원 제공자들이 CLR 관리 코드가 될 것이라고 기대된다.

모든 자원 제공자들은 그들의 상태를 자원 관리자 데이터베이스 내에 유지한다. 자원 제공자들은 그들의 관리 요구 조건들을 만족시키기 위하여 필요한 바에 따라 그들 자신의 테이블들을 생성할 수 있다.

자원 관리자 데이터베이스 내의 자원 제공자의 상태는 강압적이다. 따라서, 예컨대, IIS 메타베이스는 자원 관리자 데이터베이스 내의 데이터의 캐시이다. 만약 IIS VRoot 엔트리가 자원 관리자 데이터베이스 내의 대응 엔트리 없이 IIS 메타베이스 내에서 발견된다면, 메타베이스 내의 VRoot는 제거된다.

모든 자원 할당 및 재할당 요청들은 트랜잭션들 내에서 통합된다. 자원 제공자들은 자원 관리자 데이터베이스를 독점적으로 사용하여 자원 관리자 프로세스 내에서 독점적으로 실행한다. 심지어 집합적인 교차-제공자(cross-provider) 요청들은 결정적이고, 비분산적 방식으로 실행한다. 이것은 자원 제공자들의 디자인과 실행을 단순화하고, 자원들이 실패 시나리오들 내의 서버들 간에서 결코 손실되지 않는다는 것을 보장한다.

BIG 자원 관리자는 자원 할당과 자원 초기화를 두 개의 별개의 행동으로 분리한다. 자원 할당은 비분산형이고 결정적인 오퍼레이터이며, 자원 관리자 프로세스 내에서 독점적으로 실행한다. 한편, 자원 초기화는 고유적으로 분산적이며 비결정적인 프로세스이다.

자원 할당은 주로, 컴포넌트들이 실증되고, 와이어들과 연결되고, 필요에 따라서 자원 요구 조건들로 속성이 정해지는 깊이-우선 동작 논리 국면(depth-first operations logic phase)에 의해 시작된다.

자원 초기화로부터 컴포넌트 실증과 자원 할당을 분리시킴으로써, BIG 런타임 및 서비스는, 자원의 초기화가 완료되지 않았기 때문에 자원을 이용 할 수 없다거나, 자원이 머무른 장치가 증발되어서 자원을 이용할 수 없다거나 하는 것에 대하여, 공통의 에러 조작 메커니즘(error-handling mechanisms)을 사용할 수 있다. 자원 초기화는 주로 상태 기계(state machine)에 의해 구동될 것이며, 상태 기계는 자원 관리자 데이터베이스 또는 SDM 데이터베이스와 같이 HA SQL 저장 장치 내에 상태를 저장한다.

자원 제공자들

BIG 자원 관리자는 BIG 컴퓨터 내의 모든 자원들을 소유한다. 자원-특정 자원 제공자들을 통하여, 자원 관리자는 별개의 클래스의 자원들에 특정된 지식으로 확장된다. 자원 관리자는 저장 장치에게 집합적 자원 동작의 관리를 제공하고, 자원 제공자들용 호스트로서 작용한다.

BIG 자원 관리자는 제한된 수의 자원 제공자들을 통하여 작은, 특정한 자원들 세트를 제공한다. 자원 제공자들(그 수는 적음)의 기본 세트는, 대상 고객들의 전부는 아니더라도 대부분의 요구 조건을 커버할 것이라고 기대된다. 이하의 자원 제공자들은 첫번째 제품 릴리스(product release)에서 기대된다.

ㆍ 물리적 자원 제공자(원시 장치들)

ㆍ 네트워크 자원 제공자(VLAN들)

ㆍ 외부 자원 제공자(DNS 네임들, 외부 IP 주소들)

ㆍ IP 로드 밸런싱 그룹 자원 제공자(IP Load Balancing Group Resource Provider)

ㆍ IIS VRoot 자원 제공자

ㆍ SQL DB 자원 제공자

ㆍ CLR AppDomain 자원 제공자

ㆍ "Win32 Surface" 자원 제공자(Win32 프로그램)

생성 패턴

주로 자원 관리는 실행되는 CLR 관리 코드로서 패키징된 동작 논리에 의해 구동될 것이다. 동작 논리는 CLR 관리 객체가 대상 컴포넌트를 나타내는 "해체된 객체(disembodied object)" 패턴에 기록될 것이다. 해체된 객체는 컴포넌트가 필요로 하는 논리적 또는 물리적 자원들의 할당, 그러한 자원들의 초기화, 컴포넌트가 더 이상 필요하지 않을 때 그러한 자원들을 궁극적으로 분해 및 해제하는 것에 대해 책임이 있다.

FrontEnd f = new FrontEnd(); // Instantiate the disembodied object.

이상과 같은 호출은 단지 해체된 객체, 즉, 런타임 데이터베이스 내의 컴포넌트 인스턴스 기록을 갖는 CLR 클래스를 생성할 뿐이며, 그 이상은 아니다. 동작 논리는 "FrontEnd f"와 작용하여 스케일 요구 조건들(scaling requirements) 등과같은 파라미터들을 설정한다.

해체된 객체, 즉 본 예에서 "FrontEnd f"는, 원하는 자원들의 그래프에 대한 요구와 후속하는 자원들의 설정에 반응함으로써, 임의의 자원 할당에 참여한다.

r = f.GetResourceGraph(); // Ask f to produce the logical resource request graph (recursively if f is compound).

rgo = BigAllocateResources(rgi); // Ask the Resource Manager to do the global allocation request.

f.SetResources(rgo); // Notify f of the actual resources allocated (recursively if f is compound).

해체된 객체는 소위 디스크를 포맷하고 이미지를 저장하는 등, 모든 객체 초기화를 지시한다.

f.BeginConstruct(); // Kick off the construction/initialization state machines.

f.EndConstruct(); // Get results when construction has finished (this is just the .NET async pattern).

또한, 해체된 객체의 수명은 파괴를 지시하는 해체된 객체를 갖는 객체의 수명을 넘어선다. 이전의 진술이 객체 정지(object quiescence)를 금지하지는 않는다.

f.BeginDestruct(); // Kick off the destruction state machines.

f.EndDesctruct(); // Get results when destruction has finished.

해체된 객체도 그 자원들을 해제한다.

f.ReleaseResources();

이후에, 자원이 파괴될 수 있다.

f = null;

아무 가치 없는 것들도 있다. "f"는 단지 해체된 객체이고, 자원 할당은 자원 초기화/구축과는 별개이기 때문에, 이하의 라인들은 모두 단일의 결정적인 트랜잭션 내에 배치될 수 있다. RM DB가 SDM DB와 동일한 SQL 내에 있다고 가정하면, 상기 트랜잭션은 비분산형 트랜잭션일 수도 있다.

BeginTransaction();

FrontEnd f = new FrontEnd;

r = f.GetResourceGraph(); // Ask f to produce the logical resource request graph

rgo = BigAllocateResources(rgi); // Ask the Resource Manager to do the global allocation request.

f.SetResources(rgo); // Notify f of the actual resources allocated.

EndTransaction();

어떤 순간에는 모든 자원 제공자들이 분산형 동작들을 불러낼 것이지만, "BigAllocateResources()" 호출 동안에는 그러하지 않을 것이다. 주어진 자원 제공자의 실행에 의해, SDM 모델링 서비스를 통하여 분산형 코드(distributed code)를 레버리지(leverage)할 수 있다.

배치 최적화

첫째로, 이 논의의 상황에서, 배치 최적화에 관한 다음의 용어를 정의한다.

I. 국부 최적화(Local Optimization): 최적화는 단일의 컴포넌트 팩토리에 국한되며, 다른 컴포넌트 팩토리들 내의 배치에 대한 영향을 무시한다.

II. 집합적 최적화: 다중 컴포넌트 팩토리들을 고려하여 최적화한다. 예컨대, IIS 애플리케이션들과 SQL 데이터베이스들의 배치를 고려하여 최적화한다.

III. 전체적 최적화: (존재하는 컴포넌트들의 이동을 포함하여) 전체 시스템, 즉 BIG 컴퓨터 내의 모든 애플리케이션들을 최적화한다. 전체적 최적화는 존재하는 컴포넌트들의 이동을 고려한다는 점에서 집합적 최적화와 차이가 있다.

한편, 이하의 점들을 이해하여야 할 것이다.

I. BIG V1은 집합적 할당 API를 제공하여야 한다. 집합적 할당 API는 컴포넌트에 대한 구성 파라미터를 갖는 와이어 인스턴스들과 컴포넌트의 집합 및, SAM내의 와이어 인스턴스들을 고려한다. 단일 트랜잭션에서, 집합적 할당 API는 컴포넌트 팩토리들을 호출하여 필요한 자원들을 보존한다. [주의: 할당이 다른 컴포넌트 팩토리들을 포함할 수 있다는 사실을 강조하기 위하여 "배치(batch)" 대신에 "집합적(aggregate)"이라는 용어가 사용되었다. 이러한 점에서 "집합적 최적화 할당 API(aggregated optimized allocation API)"라는 말은 사용되지 않았음에 유의하여야 한다.]

II. 결국, BIG는 전체적인 배치 최적화(global placement optimization)를 제공하여야 하다. 전체적인 배치 최적화의 목적은 일정한 특성들을 최적화하기 위하여 BIG 기계 내의 컴포넌트 인스턴스들의 배치를 재조정하는 것이며, 주된 특성은 BIG 기계의 공유 자원들을 사용하는 것이다.

III. 집합적 배치 최적화는 초기 할당 시에 발생할 수 있거나, 제어된 애플리케이션 동의(controlled application consent)로 이후에 전체적 최적화의 형태를 취할 수 있다. 배치에 영향을 줄 수 있는 가장 용이한 시간은 컴포넌트 인스턴스가 초기에 할당될 때이다.

IV. 초기 배치 후의 컴포넌트의 이동은 매우 비용이 많이 들며, 심지어 엄두를 못 낼 정도로 비싸다. 큰 SQL 백엔드를 이동시키는 것은 대단히 비용이 많이 들며, 애플리케이션 이용 가능성을 심하게 훼손할 수 있다. 컴포넌트를 이동시킬 때는 애플리케이션의 요망 사항을 고려하여야 한다.

V. 장기간 실행되는 애플리케이션의 경우, 컴포넌트들을 이동시키는 것은 전체적인 배치 최적화 없이도 필연적일 것이다. 하드웨어가 갑자기 망가질 수도 있다. 하드웨어는 정상적인 감가상각 및 라이프 사이클 제약(life-cycle constraints)으로 인해 분명히 해체될 것이다. 따라서, 장시간 실행되는 어떠한 애플리케이션이라도 궁극적으로는 컴포넌트들을 이동시키기 위한 일부의 메커니즘을 필요로 할 것이다. 이러한 메커니즘들이 전체적 배치 최적화에 의해 레버리지되는지 여부는 그 존재에 달려 있다.

VI. 장시간 실행되는 애플리케이션은 업그레이드를 위한 일정한 형태의 이동을 지원할 것이다. 예컨대, 업그레이드를 위한 메커니즘은 전체적 배치 최적화에 의해 레버리지될 것이다. 예컨대, 만약 애플리케이션 업그레이드 정책이 새로운 프론트 엔드 온라인을 가져오고 옛날 것을 해체하는 것이면, 새로운 프론트 엔드를 할당하는 것이 배치를 최적화하는 최고의 시간이다. 업그레이드는 전체적 배치 최적화에 대한 기회를 제공한다.

이상의 설명으로부터, BIG V1를 위해 다음의 것을 제안할 수 있다.

1) BIG V1는 배치 할당(batch allocation) API를 제공한다. 배치(batch) API는 컴포넌트에 대한 구성 파라미터를 갖는 와이어 인스턴스들과 컴포넌트의 집합 및, SAM 내의 와이어 인스턴스들을 고려한다. 단일 트랜잭션에서, 배치 API는 컴포넌트 팩토리들을 호출하여 필요한 자원들을 보존한다.

2) BIG V1는 컴포넌트들의 이동을 형식화한다. BIG V1는 최소한 표준 컴포넌트 인터페이스를 포함하여 오프라인의 컴포넌트를 얻을 수 있고, 또한 그 컴포넌트를 또 다른 위치로 가져갈 수 있다. "Iserialize"와 동등한 컴포넌트를 상정해 보면 될 것이다. 이러한 형식화는, 동작을 사용하여 업그레이드를 수행하고 전체프론트 엔드를 클로닝(cloning)할 것이다. 또한 SQL 백엔드를 분할 작업(partitioning)하는 데도 사용될 것이다. 또한 하드웨어 등을 해체하는 데에도 사용될 것이다. 여기서, 이동 컴포넌트의 개념과, 다른 유형의 컴포넌트들을 이동시키는 것이 무엇을 의미하는가, 어떻게 비용을 평가하는가 등에 대한 개념을 가져야 한다.

3) BIG V1은 집합적 배치 최적화기(optimizer)를 제공한다. 최적화기의 복잡성은 개발 사이클의 요구에 부응하여 조절된다. 최적화기는 조잡한 클러스터 최적화기(clustering optimizer) 또는 좀 더 세련된 최적화기일 수 있다.

4) 집합적 배치 최적화기는 초기 배치(initial placement) 중에 배치(batch) 할당 API에 의해 사용된다. 컴포넌트 팩토리들은 배치 최적화기와 협력하여 그 결정들에 도움을 준다.

5) 애플리케이션의 수명 동안, 집합적 배치 최적화기가 주기적으로 불려져서 컴포넌트 인스턴스들을 이동시킴으로써 전체적 배치 최적화를 수행할 수 있다. 최적화기는 애플리케이션에 의해 자연적으로 제시된 기회의 영역을 레버리지할 수 있다. 최적화기는 또한 다른 시간에 컴포넌트 이동을 고려하도록 애플리케이션에 요청할 수 있다. 기본적으로, 전체적 최적화는 집합적 배치 최적화기와, 이동 컴포넌트들을 위한 기존의 지원을 레버리지한다.

6) BIG V1 IIS 애플리케이션 컴포넌트 팩토리는 애플리케이션 허용 여부에 따라서 이동 컴포넌트들을 실행한다. 전체적 배치 최적화의 많은 장점은 SQL 데이터베이스 등의 무거운 컴포넌트들을 무시하고 VRoot들을 이동시킴으로써 실현될 것이다. IIS는 또한 자연적으로, VRoot들의 이동을 용이하게 하는 드레인(drain) 등의 동작들을 지원한다. 사실상, IIS VRoot 컴포넌트 인자(component factor)는 전체적 배치 최적화 및 컴포넌트 이동을 위한 V1 포스터 차일드(poster child)가 될 것이다.

물리적 자원의 모델링

전체 자원 관리 시스템(entire resource management system) 하부에는 하드웨어 자원 그래프가 있다. 하드웨어 자원 그래프는 BIG 자원 관리자(Resource Manager)에 이용 가능한 하드웨어 자원의 접속성(connectivity) 및 하드웨어 자원의 전체성(totality)을 설명한다. 하드웨어 자원 그래프는 서버, 네트워크 장치 및 네트워크 토폴로지(network topology)를 포함한다. 또한, 하드웨어 자원 그래프는 전력망(power grid) 및 물리적 포함 관계에 관한 정보를 포함할 수 있다.

하드웨어 자원 그래프는 세 개의 기본적인 엘리먼트인 엔티티(entity), 커넥터(connector) 및 접속(connection)으로 이루어진다.

엔티티는 소프트웨어에 의하여 액세스 가능한 하드웨어의 기본적인 유닛이다. 엔티티의 예에는 서버, 디스크 드라이버, 네트워크 장치 등이 포함된다.

커넥터는 엔티티에 대한 물리적 인터페이스이다. 커넥터는 정확하게 하나의 엔티티와 항상 연관된다. 커넥터의 예에는 네트워크 인터페이스, IDE 인터페이스, AC 전력 커넥터 및 물리적 포함관계 등이 포함된다.

접속은 정확히 두 개의 커넥터들간의 물리적 접속 관계이다. 접속의 예에는 네트워크 케이블, IDE 케이블, AC 케이블 등이 포함된다.

모든 세 개의 엘리먼트 유형, 엔티티, 커넥터 및 접속은 연관 특성(associated properties)을 갖는다. 특성은 특성 이름, 최대 값 및 이용 가능한 값으로 이루어진 투플(tuple)이다.

모든 세 개의 엘리먼트 유형은 듀얼(dual)을 가질 수 있다. 듀얼은 장애 극복(fail over)을 위하여 사용되는 피어(peer)이다. 엘리먼트 및 이것의 듀얼은 항상 함께 할당되어, 고가용성(high availability)을 위하여 필요한 중복(redundancy)을 제공한다. 일반적인 듀얼의 예에는, 중복 네트워크 상의 장애 극복 스위치, 중복 NIC, 및 중복 NIC를 중복 스위치에 접속하는 케이블이 포함된다.

모든 커넥터는 커넥터 당 허용된 접속의 최대 수를 지정하는 카디날리티(cardinality)를 갖는다. 예를 들면, IDE 커넥터는 하나의 마스터 및 하나의 슬레이브 장치인 2의 카디날리티를 갖는다. 도 62 참조.

기본적인 유형을 정의하는 원리:

■무엇이 기본적인 하드웨어 프로토콜인가?

■하드웨어 레벨에서, 장치는 어떤 언어를 말하는(speak)가?

■기본적인 엔티티는 정확히 하나의 소유자(owner)를 갖는다.

■커넥터 및 접속 카테고리는 부합하여야 한다.

■듀얼은 하나로서 할당되어야 하는 장애 극복 쌍이다.

■엔티티, 커넥터 또는 접속은 듀얼일 수 있다.

무엇이 모델링 엘리먼트인가?

■엔티티

■커넥터 Src = 엔티티

■접속 Src = 커넥터, Dst = 커넥터

무엇이 기본적인 카테고리인가?

■엔티티 카테고리:

■X86 PC: 소프트웨어/CPU/RAM 상호 작용을 설명한다. CPU 및 RAM은 값(value)이다.

■EFI PC: 소프트웨어/CPU/RAM 상호 작용을 설명한다. CPU 및 RAM은 값이다.

■네트워크 장치. IP + SNMP를 말한다. 제품 식별자는 값이다.

■디스크. 섹터(sector)를 송신하고 수신한다.

■물리적 포함기(Physical Container).

■커넥터/접속 카테고리:

■에더넷. 대역폭(bandwidth)이 값이다.

■ATA. 대역폭 및 포맷(format)이 값이다.

■SCSI. 대역폭 및 포맷이 값이다.

■전력(Power)

■물리적 (포함).

■다른 것들: 파이버채널(FibreChannel), 시리얼, 병렬(Parallel), USB, 파이어와이어(FireWire), 802.11, Infiniband

초기 물리적 구성(Initial Physical Configuration) - 도 63 참조.

상세한 예 - 도 64 및 도 65 참조.

위치 기반 장치 식별자(Location-Based Device Identifiers)

모든 네트워크된 장치는 네트워크에서 그것의 위치의 고유한 식별자를 갖는다.

각각의 레벨에서, 값 = 부모 스위치(parent switch) 상의 포트 번호.

종료된 레벨(terminated level)은 종료 값, "#"을 갖는다.

예를 들면, 도 66 참조.

두 개의 장치들 간의 경로를 계산

두 개의 장치 (2,0,1) 및 (2,1,#)를 고려하자.

각각의 장치에 대하여, 종료된 프리픽스(terminated prefix)를 계산:

(2,0,1) -> (#,#,#), (2,#,#), (2,0,#)

(2,1,#)->(#,#,#), (2,#,#)

가장 특정한 공통의 종료된 프리픽스는 공통 부모이다.

(2,#,#)

남아있는 종료된 프리픽스는 이름 중간 스위치(name intermediate switch)이다.

(2,0,1) -> (2,0,#)

(2,1,#) -> 없음(none).

최종 경로:

(2,0,1)에서 (2,1,#)로 -> (2,0,#), (2,#,#) = 두 개의 스위치 홉(switch hop) = 세 개의 와이어 홉(wire hop).

또한, 장치에 가장 근접합 피어를 탐색하는 것은 단순하다:

(2,0,1) -> (2,0,?)

(2,1,#) -> (2,?,#)

도 67 참조.

자원 요구(Resource Requests)를 모델링

BIG 자원 관리자는 BIG 기계(machine)를 노드(node)(자원) 및 에지(edge)(관계)의 그래프로서 모델링한다. 노드 및 에지는 모두 속성(attribute)(이름- 값 쌍)으로 주석 처리될(annotated) 수 있다.

자원 그래프에 대한 질의(query)의 가장 일반적인 유형 중 하나는 서브그래프 동형이질(sub-graph isomorphism)이다. 클라이언트는 요구 그래프를 생성하고, 동일한 형태 및 특성을 가진 하드웨어 자원 그래프 내의 서브그래프를 자원 관리자가 탐색하도록 요청한다. 자원 관리자는 부합하는 것을 탐색하고, 완전히 주석처리된 응답 그래프(reply graph)를 반환한다.

서브그래프 동형이질의 부분으로서, 자원 관리자는 그래프 노드들을 겹치거나 결합해서는 안된다. 즉, 요구 그래프가 두 개의 PC 노드를 포함하면, 응답 그래프는 두 개의 PC 고유한 노드들을 포함해야 한다.

요구 그래프는 PC 노드를 탐색하거나 또는 적어도 256MB RAM을 갖는 PC 노드를 탐색하는 것과 같은 검색 파라미터(search parameter)를 포함할 수 있다. 응답그래프는 각각의 부합하는 엘리먼트(노드 및 에지)의 특정 id를 포함한다.

기본적인 경우에, 요구 그래프는 읽기 전용 질의(read-only queries)이다. 그러나, 공통 최적화(common optimization)는 자원 할당(resource allocation)의 형태로 읽기-쓰기 동작을 허용한다. 지면에 그려지면, 쓰기 동작은 괄호로 라벨링된다.

도 68은 IDE 또는 SCSI와 같은 저장 전송(storage transport)을 통하여 접속된 부착 디스크(attached disk) 및 PC를 할당하기 위한 요구 그래프이다. 노드는 끝이 둥근 사각형으로 표시되고, 에지는 속성이 지정된 겹쳐진 사각형을 갖는 어두운 선으로서 표시된다는 것을 유의하여야 한다. 성공적인 할당은 도 69의 응답 그래프를 유발할 것이다.

구동 시나리오(Driving Scenario)

죠(Joe) 꽃집은 도 70에 도시된 자원 요구를 만든다. MSN은, 죠가 "골드" SLA를 가지고 있기 때문에 적어도 500MHz PC를 얻는다는 것과, 그의 PC가 집약성(locality)을 유지하기 위하여 Switch5에 부착된다는 것을 보장한다. 도 71에 도시된 추가로, Exodus는, MSN이 항상 Rack17의 기계를 얻고 또한 작은 디스크를 얻는다는 것을 보증하는데, 이는 이들이 "2^nd" 클래스 저장 SLA를 갖기 때문이다. 도 72 참조.

구현 아이디어

class Graph;

class Client

{

private IResourceMediator mediators[];

private Object mediatorStates[];

}

interface IResourceMediator

{

public void MediateRequest(ref Graph graph, ref Object state);

public void MediateReply(ref Graph graph, ref Object state);

}

class ResourceManager

{

public Graph Allocate(Graph request, Client client)

{

for (int n = 0; n < client.mediators.Length; n++)

{

client.mediators[n].MediateRequest(ref request, ref client.mediatorStates[n]);

}

Graph reply = PrimitveAllocate(request);

for (int n = client.mediators.Length - 1; n >= 0; n--)

{

client.mediators[n].MediateReply(ref reply, ref client.mediatorStates[n]);

}

return reply;

}

private Graph PrimitiveAllocate(Graph request);

}

기본적인 자원 할당 시나리오

이 부분은 다수의 시나리오를 나열한다. 각각의 시나리오와 함께, 해당 요구 그래프가 포함된다. 질의 트랜잭션(query transaction)의 결과로서 할당될 노드는 "[Allocate]"로 라벨링된다. 할당되지 않고 부합에 대한 탐색을 위하여 할당되지 않아야하는 노드는 "[Free]"로 라벨링된다. 괄호로 된 라벨이 없는 노드는 할당되지 않으며, 대신 요구 그래프의 나머지에 대한 콘텍스트(context)를 제공한다.

PC

Akamai는 적어도 1GHz CPU, 512MB RAM 및 100GB 로컬 디스크 저장 장치를 갖는 Digix 데이터 센터의 서버를 할당할 필요가 있다. 도 73 참조.

VLAN

MSN 인스턴스 메시징은 프론트-엔드(front-end)를 포함하는 DMZ를 구현하기로 결정했다. 이렇게 하기 위하여, 그것은 프론트-엔드의 커버리지(coverage)를 갖는 2 VLAN을 필요로 한다. 도 74 참조.

공개 IP 주소 또는 DNS 네임

죠의 웹 서비스는 외부 세계에 자신을 보이게 할 필요가 있다. 그는 DNS 엔트리 및 라우팅 가능한(routable) IP 주소를 할당할 필요가 있다. 도 75 참조.

로드 밸런싱 그룹(Load Balancing Group)

죠의 웹 서비스는 단일 PC에 대하여 너무 커졌다. 그는 로드 밸런싱 그룹 및 다른 PC를 할당할 필요가 있다. 그 후, 그는 로드 밸런싱된 그룹의 가상 IP 주소 뒤에 PC들을 위치시킬 필요가 있다. 도 76 참조.

경로(Path)

핫메일(Hotmail)은 하나의 UStore로부터 다른 것으로 이메일 계정(email account)을 전달하기 위하여 80Mbps 경로를 할달할 필요가 있다. 또한, 핫메일은 경로에 대한 QOS 요건 및 지연(latency)을 지정할 수 있다. 도 77 참조.

특정 저장 장치

핫메일은 새로운 UStore를 생성하기를 원한다. 그것은 10,000 RPM 이상으로 회전하는 공유되지 않은 헤드(unshared head)의 적어도 4개의 세트에서 펼쳐진 100GB를 갖는 Raid 1 box를 원한다. 도 78 참조.

클러스터(Cluster)(Quorum) 저장 장치

핫메일은 장애 극복 클러스터를 위하여 공유된 디스크를 갖는 한 쌍의 기계를 할당하기를 원한다. 그것은 10,000 RPM 이상으로 회전하는 공유되지 않은 헤드의 적어도 4개의 세트에서 펼쳐진 100GB를 갖는 Raid 1 box를 원한다. 도 79 참조.

공유된 저장 장치

죠의 웹 서비스는 서비스 특정 구성(configuration)의 롤백 이미지(rollback image)를 유지하기 위하여 다수의 기계에 의하여 사용 가능한 50GB 공통 저장 장치를 필요로 한다. 이 저장 장치는 0부터 N 기계까지 이용 가능하다. 도 80 참조.

할당 배치 시나리오(Allocation Placement Scenario)

인접한 기계 할당(Proximal Machine Allocation)

핫메일은 새로운 프론트-엔드를 할당할 필요가 있다. 그것은 백-엔드 클러스터(back-end cluster)에 대하여 충분한 대역폭을 갖는 다른 프론트-엔드와 동일한 스위치 상의 기계를 탐색하기를 원한다. 도 81 참조.

원거리 기계 할당

Expedia 고객 신상 정보 데이터베이스는 SQL 복제(replication)를 위하여 다른 기계를 필요로 한다. 그것은 상이한 배터리 백업 유닛에 의하여 커버된 데이터 센터의 부분에 위치된다. 도 82 참조. 또는 혹은 도 83의 예.

지연 구동 할당(Latency Driven Allocation)

핫메일 백-엔드는 클러스터 조정(cluster coordination)을 위한 기계를 할당할 필요가 있다. 기계는 클러스터에 이미 있는 기계의 5ms 지연 내에 있어야 하지만, 대역폭은 낮다. 선택적으로, 이것은 기계가 1 네트워크 홉 내에 있는 것으로필요로 함으로써 표시될 수 잇다. 도 84 참조.

합성 컴포넌트를 시딩(seeding)

핫메일은 새로운 이메일 유닛을 생성하려고 한다. 그 유닛은 적어도 500 PC로 성장하기 위한 공간(room)을 갖는 단일 홉 클러스터에 할당되어야 하지만, 핫메일은 단지 초기에 수십개의 기계를 할당할 수 있다. 도 85 참조.

일괄 할당(Batch Allocation)

MSN 검색은 작은 음악 샘플에 기초하여 MP3를 검색하는 기능을 추가하기로 결정한다. 그것은 400 PC의 블록, 로드 밸런서 및 20TB 저장 장치를 할당하기를 원한다. 그것은 전부가 아니면 아예 없는 할당(all-or-nothing allocation)을 원한다. 도 86 참조.

폐지 시나리오(Revocation Scenario)

복구(Recovery)

죠의 웹 서비스는 IDC에 지불하는 것을 멈췄다. IDC는 죠의 웹 서비스에 할당된 모든 자원을 복구하고, 이것을 이용 가능한 자원의 풀에 반환할 필요가 있다.

하드웨어 수명 폐지(Hardware Lifetime Revocation)

Expedia의 프론트-엔드 중 하나는 생명 주기(life cycle)의 끝에 도달한 PC이다. IDC 동작 논리(operation logic)에 의하여 트리거되면, 자원 관리자는 Expedia에게 그것은 기계가 IDC로 반환되기까지 72 시간을 가졌다는 것을 통지한다.

제어된 폐지

핫메일은 UStore의 대용량 리셔플링(massive reshuffling)을 위하여 20 단기간 기계(short-term machine)를 할당하였다. 그것의 SLA에 따르면, IDC는 이제 하나의 기계가 반환될 것을 요청한다. 핫메일은 다른 동등한 기계 또는 20개 중 하나를 반환할 수 있다.

BIG 비전(Vision) - 이네이블(Enable)

■Visual Studio와 SQL, IIS, ...와 같은 재사용 가능한 빌딩 블록을 사용하여 분산되고 스케일링 가능하며(scalable) 고가용성인 서비스(highly available service)의 개발

■자동으로 할당되고 목적되며(purposed) 구성되는 한 세트의 추상화된 하드웨어(abstracted hardware) 및 소프트웨어에 걸친 배포(deployment)

■서비스 가용성 및 성장을 제어하기 위하여 동작상의 최상의 실시예(operational best practice)를 코드화(codifying)함으로써 자동화를 통하여 소유권(ownership)의 낮은 비용

■물품 경제학(commodity economics)을 레버리지(leverage)하는 표준화된 데이터 센터 하드웨어의 획득(procurement)

BIG 서비스 플랫폼 아키텍처 - 도 87 참조.

BIG 컴퓨터 - 하드웨어 기준 플랫폼(Hardware Reference Platform)

설계, 테스트 및 동작의 비용을 감소시킴:

·지원할 하드웨어 장치의 수를 제한

·네트워크 토폴로지를 제약

·네트워크 구성의 자동화를 이네이블

BIG 기술 배포 요건에 관한 고객 염려를 제거

·PXE, DHCP, DNS, VLAN

IP 게이트웨이

■외부 네트워크와 내부 네트워크간의 IP 트래픽을 조정

■네트워크 주소 번역(Network Address Translation; NAT), 방화벽(firewall), 로드 밸런싱

내부 네트워크

■IP 주소 및 VLAN은 BIG에 의하여 배타적으로 관리된다

■VLAN은 자동으로 구성된다

하드웨어 빌딩 블록

■물품 서버, 네트워크 스위치 및 디스크의 조합.

도 88 참조.

도 89는 BIG 컴퓨터 내부에 있을 수 있는 현재의 제품의 예를 설명한다.

자원 관리 특징

●서버, 저장 장치 또는 네트워크 하드웨어 자원의 동적 발견.

●(물리적 및 논리적) 자원을 포함하는 고가용성 데이터베이스.

●자원의 열거(enumeration), 질의 및 업데이트를 지원하는 런타임 API.

●자원 드라이버를 물리적 하드웨어 장치에 바인드(bind)하기 위한 논리적 자원 드라이버 모델 및 API.

●서버 자원의 프로그램적 할당 및 해제(deallocation).

●VLAN 및 로드 밸런싱 그룹과 같은 네트워크 자원의 자동 구성 및 관리.

●블록 및 파일 기반 저장 자원의 동적 구성 및 관리.

●장애 검출 모니터링 및 통지.

자원 관리 컴포넌트

●자원 관리자는 BIG 컴퓨터 내의 하드웨어 및 소프트웨어 자원의 할당을 책임진다

■자원 관리자는 BIG 런타임에 등록한다

■자원 관리자는 주어진 자원 유형에 대하여 본질적으로 팩토리(factory)이다.

●하드웨어 자원 관리자

■하드웨어 인스턴스를 할당할 책임이 있는 베이스 레벨 팩토리

●네트워크 자원 관리자

■VLAN, 로드 밸런싱 그룹, IP 주소 ...를 할당할 책임

●저장 자원 관리자

■디스크 및 파일과 같은 저장 자원을 관리한다

●PC 자원 관리자

■iBIG 서비스를 사용하여 타겟 서버를 할당하고 OS를 배포한다

●소프트웨어 자원 관리자

■IIS vroots, SQL 데이터베이스, ASP.NET을 할당하고 구성한다

도 90은 다양한 자원 관리 컴포넌트를 도시한다.

하드웨어 자원 발견 및 관리

특성: 전력, 네트워크, 저장 장치, 프로세서, 메모리, 위치(Location)

BIG 컴퓨터 내의 하드웨어는 자동으로 발견된다. 자원 드라이버는 하드웨어 장치에 제약되고 논리적 자원을 하드웨어 자원 관리자(Hardware Resource Manager; HRM)에 공개한다. HRM은 논리적 자원 할당 요구를 물리적 자원 바인딩으로 번역한다. 도 63, 64 및 65 참조.

BIG 컴퓨터 내의 네트워크 자원 관리

BIG 컴퓨터는 네트워크 자원에 대한 추상화를 정의한다.

네트워크 자원 관리자: BIG 컴퓨터 내에서 네트워크 자원을 할당하고 네트워크 스위치 및 로드 밸런서를 프로그램하며, 네트워크 자원 드라이버와 인터페이스한다.

VLAN은 BIG 컴퓨터 내에서 고립(isolation)을 제공하고 네트워크를 분할한다(partition).

네트워크 자원의 예: VLAN, 로드 밸런싱 그룹, 네트워크 필터, IP 주소, DNS 네임.

BIG 저장 자원 관리 요건

●파일 및 블록 기반 저장 자원을 포함하는 BIG 컴퓨터에 접속된 저장 장치의 전체적인 조망(global view).

●저장 상호 접속 패브릭(storage interconnect fabric)의가상화(virtualization)

●LUN, 볼륨, 어레이 등과 같은 고레벨 저장 추상화를 생성하고 관리하는 프레임워크.

●기존 및 새로운 저장 장치가 BIG 컴퓨터에 플러그되는 것을 허용하는 드라이버/제공자.

●SAN 시스템을 갖는 상호운용성(interoperability).

기반 구조 서비스(Infrastructure Services){자동화된 배포 서비스(Automated Deployment Services; ADS)} - 특징

●베이스 배포 서비스

■기본적인 네트워크 부트 서비스(Basic Network Boot Service)(PXE) 및 이미지 빌더 서비스(Image Builder Service)

■프리-부트 OS 환경(Pre-boot OS environment)(BMonitor)

■레거시 도구 지원(legacy tools support)을 위하여 네트워크 상으로 전달된 가상 플로피

●이미지 배포 및 관리

■이미지를 생성, 편집 및 삭제하기 위한 도구

■프리-OS(pre-OS)를 실행하는 시스템에 이미지의 배포

●다중 장치 관리(Multiple Device Management; MDM)

■공통 작업에 대한 스크립트(script)

■배포에 대한 다중 단계 및 프로세스를 조정하기 위한 작업시퀀싱(task sequencing)

■완전한 프로그램적 인터페이스(Full programmatic interface)(WMI)

●.NET 서버 RTM으로부터 60일 선적(Ships 60 days)

■Windows 2000 및 .NET 서버 타겟을 지원

도 92는 예시적인 ADS 아키텍처를 도시한다.

도 93은 예시적인 ADS 원격 부트 및 이미징 시스템(Remote Boot and Imaging system)을 도시한다.

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

●전체 서비스의 프로그램적 설명

■서비스의 서술적인 정의(declarative definition)

■스케일 불변 방식(scale-invariant manner)으로 서비스의 전체적인 서비스 구조를 정의한다

■배포, 관리 및 동작에 대한 프레임워크를 제공한다

■컴포넌트-기반 모델은 모듈 양식(modular fashion)으로 서비스 엘리먼트를 포착한다

●SDML은 서비스 정의 모델을 정의하는 서술적인 언어이다

■컴포넌트, 포트 및 와이어

■유형, 멤버 및 인스턴스 공간

■조직(composition) 및 캡슐화(encapsulation)를 지원

SDM: 컴포넌트, 포트 및 와이어

●컴포넌트는 구현, 배포 및 동작의 유닛이다

■예를 들면, .NET 서버, IIS 가상 웹 사이트, SQL 데이터베이스를 실행하는 전용 서버

■포트를 통하여 기능을 공개하고 와이어를 통하여 통신한다

■조직에 의하여 생성된 합성 컴포넌트(compound component)

●포트는 연관 유형(프로토콜)을 갖는 이름(서비스 액세스 포인트)이다

■BIG은 통신을 위하여 어떤 프로토콜을 사용할지를 위임(mandate)하지 않는다

■프로토콜은 통신을 확립하기 위하여 요구되는 정보를 포착한다

●와이어는 포트들간의 허용 가능한 바인딩(permissible bindings)이다

■와이어는 포트들간의 토폴로지 관계를 선언한다

도 94 참조.

도 95는 SDML 예를 도시한다: MyService.sdml. 또한, 도 28은 이 SDML 예에 관련된다.

서비스 배포 유닛(Service Deployment Unit; SDU) - 다음을 포함하여, 서비스를 구성하는 모든 부분(piece)을 캡슐화한다: 애플리케이션/서비스에 대한 SDM 모델, 컴포넌트 구현을 위한 CLR 어셈블리, 및 MSI, ASP.NET, SQL 스크립트, 스태틱 내용 등. 도 96 참조.

SDM 런타임

●SDM 런타임은 SDM 모델 및 인스턴스를 추적할 책임이 있다

■IIS에 의하여 호스트되는 웹 서비스로서 구현된다

■확장성(scalability)을 위하여 분할될 수 있다

●런타임 API는 SOAP 엔드포인트를 공개한다

■런타임과의 통신은 런타임 라이브러리를 통하여 수행된다

●고가용성 SDM Store(Yukon의 중복 데이터베이스 기술을 사용함)

■두 개의 SQL 서버 및 목격자 서버(witness server)

도 27 참조.

예: 컴포넌트 인스턴스 생성(Component Instantiation)

using Microsoft.SDM;

public class MyService:

SDMComponent

{

public OnCreate(…) {

fe1 = CreateInstance("fe", "");

be1 = CreateInstance("be", "");

w1 = CreateWireInstance("tds");

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

w1.Members.Add(be1.Ports["sql"]);

}

}

myservice.cs는 SDM API를 사용하는 C# 코드이다.

componenttype MyService

{

component MyFrontEnd fe;

component MyBackEnd be;

port http = fe.http;

wire TDS tds {

fe.catalog;

be.sql;

}

implementation "MyService, MyCLRApp"

}

도 35 참조.

SDM 런타임 API를 사용하는 동적 바인딩의 예(도 97 참조)

1. be[1]은 DeclarePort()를 사용하여, sql[1] 포트가 준비되었고 그것의 포트 접속 정보를 SDM 런타임에 등록한다는 것을 선언한다

2. fe[1]은 catalog[1] 포트를 위하여 피어 정보에 대한 SDM 런타임을 초기화하고 요청하며, GetPeerPort()를 사용하여 sql[1] 포트에 관한 정보를 수신한다

3. 그 후, fe[1]는 SDM 런타임에 의하여 동적으로 제공된 포트 접속 정보를사용하여 be[1]에 접속한다

서비스 정의 모델(SDM) 워크그룹

●SDM 워크그룹은 5 팀으로 이루어진다

■Indigo

■Whitehorse

■Fusion

■Management

■BIG

●면허장(charter)은, 분산되고 그리고/또는 이종 애플리케이션에 대한 클래스 레벨 애플리케이션 스키마(schema)를 정의하는 것이다

■컴포넌트, 포트 및 와이어를 사용하여 애플리케이션을 설명한다

■배포, 구성 및 관리 정보를 포함한다

●SDM은 Fusion 및 Management(그리고 잠재적으로 다른) 스키마를 참조하는 외골격(exoskeleton)이다

■Fusion 어셈블리는 (적용 가능한 곳에서) 배포를 위하여 참조된다

■MBU 설정(Setting) 및 계측 스키마(Instrumentation schema)는 구성 및 모니터링을 위하여 참조되고 지정된다

SDM 스키마 (간략화됨)

<sdm>

<identity /> // identifies the group of definitions

<porttypes /> // descriptions of ports

<wiretypes /> // descriptions of topologies

<componenttypes> // set of components defined in this library

<componenttype>

<ports /> // communications capabilities

<settings /> // configuration settings for component

<instrumentation /> // monitoring schema

<deployment /> // installer type, installer info,(e.g.,Fusion)

<components /> // subcomponents for composition

<wires /> // defines relationships between ports

</componentType>

</componenttypes>

</sdm>

SDM 및 Fusion- 도 98 참조.

●디폴트 값을 갖는 로컬 설정은 Fusion Manifest(또는 다른 로컬 설치 기술)로 지정된다.

●SDM의 설정은 Ops Logic 및 BIG 런타임에 의하여 처리된다.

■예: "사용자의 수"는 애플리케이션의 초기 스케일-아웃 조건(initial scale-out condition)을 결정하기 위하여 사용될 수 있다

SDM 및 배포 - 도 99 참조.

스케일 불변 방식으로 애플리케이션의 구조를 설명하려면, 애플리케이션 호스트 환경의 유사한 스케일 불변 설명이 배포 요건 및 제약의 설계-시간 유효성 검증(design-time validation)을 이네이블할 것이 요구된다.

■마이크로소프트 및 고객은 데이터 센터 환경의 정교한 설명을 그리고 그 도면을 설명하기 위하여 매우 많은 문서를 작성하는데 많은 에너지를 소비한다.

■이들 도면 및 문서는 물리적 기계 이름으로부터 서버 역할(role)에 대한 VLAN에 대한 Ip 주소로의 다수의 계층(layer)의 정보를, 흔히 혼동을 일으키는 하나의 포괄적인 조망(view)으로 병합한다.

도 100은 예시적인 시스템 아키텍처를 도시한다.

도 101은 다양한 배포 계층의 예를 도시한다.

동작 논리(Operations Logic)은 동작의 "비즈니스 논리(Business Logic)"이다

동작 논리는 재사용 가능한 최상의 실시예로서 인코딩된 반복 가능한 패턴을 포착하는 CLR 코드이다

■서비스 또는 동작 환경에 특정하지 않음

■개발되고 테스트되며 선적될 수 있다

■사람이 그것을 실행하도록 요구하는 수동 프로시져에 대한 필요성을 감소시킨다

OpsLogic은 서비스의 전체 동작에 대한 책임이 있다

■서비스를 구동

■서비스 성장 및 축소(shrinkage)

■업그레이드 및 업데이트

■장애 검출 및 복구

■데이터베이스 분할

OpsLogic은 MS 미들-계층 기술(middle-tier technologies)을 사용하여 구현될 것이다

■IIS 상에 호스트된 ASP.NET 웹 서비스

■트랜잭션 조정을 위한 DTC

■저장을 위한 SQL 서버

■모니터링 및 관리를 위한 WMI

■메시징을 위한 MSMQ

반복 가능한 업그레이드 패턴 -> 동작 논리

●업그레이드는, 우리가 BIG과 함께 선적하기를 원하는 재사용 가능한 동작 논리 템플릿(template)의 유형의 예이다

●인-플레이스 업그레이드 패턴(In-place Upgrade Pattern)

■데이터를 이동하는 비용은 높고, 코드 인스턴스 생성 비용은 낮다, 또는 어떠한 중복 자원도 없다

■서비스로부터 컴포넌트를 가져오고, 업데이터를 실행하며, 그것을 서비스에 다시 둔다

●나란히 있는 업그레이드 패턴(Side-by-side Upgrade Pattern)

■데이터를 이동하는 비용은 높고, 코드 인스턴스 생성 비용은 낮다, 중복 자원을 갖는다

■새로운 컴포넌트를 생성; 서비스로부터 오래된 컴포넌트를 가져온다; 데이터를 새로운 컴포넌트로 이송한다(migrate); 새로운 컴포넌트를 서비스에 둔다

●대체 업그레이드 패턴(Replacement Upgrade Pattern)

■데이터 이송이 없음

■새로운 컴포넌트를 추가; 오래된 컴포넌트를 제거; 서비스 가용성을 유지하기 위하여 조정함

●롤링 업그레이드(Rolling Upgrade)는 코드화된 업그레이드 패턴을 재사용할 수 있는 고레벨 동작 논리의 예이다

■동작 논리는 테스트될 수 있고, 프레임워크는 롤백을 지원한다

■소프트웨어가 단계들을 수행하게 함으로써 실행으로부터 사람의 에러를 제거한다

동작 논리, BIG 및 마이크로소프트 프로그래밍 모델 - 도 102 참조.

인터넷은 기업형 애플리케이션(enterprise application)을 변모시킨다 - 증가된 공개는 비용을 증가시켰다. 도 103 참조. 새로운 아키텍처는 HW, 사람에 의한 비용을 증가시켰고, 복잡성에 의하여 민첩성(agility)을 감소시켰다. 도 104 참조. Moore의 변호사업(Law)은 DC 상으로 확장하고 있다 - 디스크 밀도, NW 처리율(throughput) 및 처리력(processing power)에서의 급격한 증가

서비스 전달은 사람 집약적(human intensive)이다 - 사람이 포함되면, 보안성, 신뢰성, 유연성(flexibility) 및 비용에 큰 영향을 미친다. 도 105 참조.

이것은 수명 문제이다 - 고객 고통 스팬(customer pain spans)이 발생하고, 배포되며 페이즈(phase)를 동작한다. 도 106 참조. 애플리케이션은 다음 사항으로 개발되지 않는다: HW 구성에 묶인 마음의 스케일(scale in mind-tied to HW configuration), 마음의 관리 가능성(manageability in mind), 마음의 동작 - 나의 데이터 센터의 요건은 무엇인가? 테스트 - "벽으로 던져짐(Thrown over the wall)". 개발자 데스크톱 -> 테스트 구성? 이것이 나의 생산 환경으로 매핑되는 법. 배포 도전(Deployment challenges): 나는 어떤 서버를 사용하는가? 무엇이 올바른 토폴로지인가? 서버, 저장 장치 및 네트워크 팀을 검사하였는가? 얼마나 많은 미래 수요를 예상할 필요가 있는가? 동작상의 도전: 나는 모든 이러한 경고(alert)를 가지고 무엇을 하는가? 장애가 있는 NIC가 나의 애플리케이션에 어떤 영향을 미치는가? 나의 서비스의 성능이 왜 열화하는가? 나는 나의 이메일 admin을 복제할 수 있기를 소망한다.

서비스 전달 도전을 발표(addressing) - 고객에 대하여 존립 가능한 솔루션(viable solution)의 코어 테넌트(core tenant)

수명의 각각의 단계에서의 독립적인 값

개발, 배포, 동작

전체 수명에 대한 아키텍처를 통합함

단계들간의 향상된 조정 및 피드백

비즈니스 필요성을 변화시키는 것(changing business needs)으로의 매핑을 이네이블

매핑은, 당신이 민첩성을 가지면, 단지 수행될 수 있다

최하위 TCO 플랫폼 상에서 빌드됨

스케일 아웃을 통하여 산업계 표준 하드웨어를 효과적으로 레버리지한다

프로젝트 서미트(Project Summit) - 혁명적인 서비스 전달 아키텍처. 도 106 참조. 기계가 설치되고(instrumented) 관리 가능한 서비스를 개발한다, 배포 요건을 포함한다, 동작 지식(operations knowledge)을 캡슐화하고, 표준 빌딩 블록을 레버리지한다. 서비스를 용이하게 배포: 빠른 설비 공급(rapid provisioning), DC 자원 가상화(resource virtualization), 자기 포함됨, 원-클릭 배포(one-click deploy), 일관되게 테스트로부터 생산으로, 그리고 스케일에 독립적임. 간략화된 동작: 집합된 운용(aggregated administration), 모니터링 및 변화 관리, 애플리케이션이 아닌 관리 서비스, 콘텍스트를 통한 진정한 자동화, 풍부한 서비스 중심 관리 콘솔(rich service-centric management console)

맵 비즈니스는 IT 시스템을 필요로 한다. 도구로 IT 동작 지식을 포착한다.

프로젝트 서미트 - 포괄적인 새로운 아키텍처 및 산업 범위 이니시어티브(industry wide initiative). 도 107 참조.

개념 -> 아키텍처 -> 제품

장기간, 고객 및 파트너-구동된 노력(partner-driven effort)

1999년에 시작하는 주요 투자

대형 MS 인터넷 특성의 동작 필요에 대한 깊은 재연구로 시작했다

넓은 고객 베이스 상에서 유효성이 검증된 초기 발견(Validated initial finding)

2000년 후반에서 제품 그룹으로부터의 프로토타입

조인트 개발 파트너의 강한 세트(Strong set of joint development partners)

제품 정의에 포함된 대형 기업 및 서비스 제공자 고객

API를 통하여 공개된 기능을 정의하는데 도움을 주기위하여 자문된 IHV 및 ISV 파트너

윈도우즈 서버 2003으로 초기 제품 선적

고객은 복잡한 시스템을 간단한 다이어그램으로 변환한다. 도 108 참조.

누가 당신의 IT 서비스를 전달하는데 포함되는가? - 사람은 시스템의 불가분의 부분(integral part)이다.

애플리케이션 설계자(architect) - 서비스를 설계.

네트워크 설계자 - 네트워크를 구성.

저장 장치 설계자 - 원격 저장 장치를 구성.

애플리케이션 조작자(operator) - 서비스를 유지함.

저장 장치 조작자 - 원격 저장 장치를 유지함.

서버 조작자 - 서버를 유지함.

이 모델에 있어서의 문제점 - 다수의 사람의 상호 작용, 공통적이지 않은 언어, 도메인 지식(domain knowledge)의 불선명(blurring).

솔루션의 상세 사항:

서비스 정의 모델

자원 가상화

동작 자동화

관리 API 및 솔루션

산업계 범위 이니시어티브를 구동(Driving an Industry wide initiative)

서비스 정의 모델(SDM) - 완전한 서비스를 포착.

서비스의 전체적인 설명

애플리케이션 컴포넌트 및 계측(instrumentation)

서비스 토폴로지

하부 자원(서버, 저장 장치, 네트워크)

개발자 및 조작자에 관련

책임을 계층화하고 분리한다

기준의 일관된 프레임을 제공한다

개발자를 위하여 Visual Studio에서 공개된

조작자를 위하여 런 타임에서의 리빙 모델(living model)

할당된 자원에 독립하여 논리적으로 일관됨

실시간으로 자원을 추적한다

서비스 조직(service composition) 상의 단일 권위(single authority)

진정한 자동화를 위한 콘텍스트를 제공

SDM 전문 용어

컴포넌트 - 서비스의 빌딩 블록

논리적 구조(Logical construct)

스케일 불변

하나의 컴포넌트는 다수의 인스턴스를 가질 수 있다

간단한 또는 합성

단일 논리적 엔티티(데이터베이스, 웹 서비스, 파일 분할)

결합된 논리적 엔티티(HA 데이터베이스, 이메일 등)

컴포넌트에 특정한 배포 송장(deployment manifest)을 포함

DB 컴포넌트는 데이터베이스 스키마를 포함한다

웹 서비스 컴포넌트는 URL 디렉토리, 내용, 코드를 포함한다

포트 및 와이어와 상호접속됨

포트 - 서비스 액세스 포인트

와이어 - 포트들간의 통신 관계

SDM은 추상화 및 캡슐화를 위한 수단을 제공한다. 도 110 참조.

재사용을 이네이블

복잡성을 구성한다

사람을 SDM으로 매핑 - 기준의 일관된 프레임을 제공한다. 도 111 참조.

SDM 애플리케이션을 개발 - 새로운 Visual Studio 설계 표면. 도 112 참조. 레거시 애플리케이션, 새로운 애플리케이션.

데이터 센터에서의 SDM 서비스 - 자원을 추적하는 리빙 모델을 갖는 전체적인 설명. 도 113 참조.

서미트 컴퓨터가 무엇인가?

가상화된 하드웨어 자원의 민첩한 풀(agile pool)

서버, 저장 장치, 네트워크 장치, 관리된 패브릭.

수십개로부터 수천개의 서버.

기존의 HW로부터 어셈블되거나 OEM으로부터 하나의 SKU로서 주문됨(ordered).

단일 관리된 엔티티

서미트는 서미트 컴퓨터내의 모든 HW 자원을 제공하고 관리한다.

서미트는 내부 네트워크 패브릭의 완전한 구성을 소유한다.

제어의 제약된 영역

표준화된 토폴로지는 빌드, 테스트 및 동작의 복잡성을 제약한다.

서미트 컴퓨터 외부의 자원에 대하여 변화되지 않은 소유권

소프트웨어 혁명(innovation)을 위한 촉매제

Q: 나는 나의 서버 애플리케이션을 위하여 어떤 데이터 센터 환경을 타겟으로 해야하는가?

A: 서미트 컴퓨터.

Win3와 같이, ISV가 프린터 및 그래픽 카드의 상세 사항에 관하여 잊어버릴 수 있게 한다.

하드웨어 혁명을 위한 촉매제

마이크로소프트는 주요 하드웨어 벤더와 계약하여 기준 플랫폼을 정의하였다.

WinHEC (2003년 5월)에서 나타나는 제1 스펙 & 혁신

서미트는 집합 혁신(aggregation innovations)을 위한 SW 환경을 제공한다.

덴스 블레이드(Dense blades), 스마트 랙(Smart racks) 등

서미트는 하드웨어의 간략화를 가능하게 한다. 예를 들면, 다음을 허용한다:

서버로부터 KVM을 그리고 네트워크 장치로부터 사람의 인터페이스를 제거한다.

도 114는 예시적인 자원 관리자를 설명한다.

자원 가상화 - SDM과 컴포넌트 인스턴스간의 브리지(bridge).

공유, 할당 및 복구에 대한 책임. 도 115 참조.

서버 자원 가상화 - 윈도우즈 서버 2003에서 자동화된 배포 서비스(Automated Deployment Services; ADS).

빠르게 윈도우즈 서버를 목적하고 재목적하기 위한 완전한 기반 구조

윈도우즈 2000 및 윈도우즈 서버 2003 이미지를 포착하고 편집하기 위한 이미징 도구

베어 메탈(bare metal)로부터 제로 터치 서버 빌드(zero touch server builds)를 가능하게 하는 보안, 원격 배포 프레임워크

대규모 서버 운용을 위한 프레임워크

안정한, 신뢰할 수 있는, 스크립트 실행 기반 구조

당신의 윈도우즈 데이터센터의 프로그램적 모델

모든 운용적인 활동의 지속적인 로그

그래픽 및 프로그램적 인터페이스

GUI 기반 동작을 위한 간단한 MMC UI

명령어 라인 도구 및/또는 WMI 계층을 통해 공개된 완전한 기능

ADS의 주요 이점

1. 베어 메탈 서버 빌드 및 스크립트 기반 운용과 연관된 TCO를 낮춘다

베어 메탈로부터 제로-터치 서버 빌드를 가능하게 한다

1 서버만큼 용이하게 1000 서버의 스크립트 기반 운용을 안전하게 한다

2. 당신의 윈도우즈 서버 데이터센터의 일관성, 보안성 및 확장성을 향상시킨다

동작하는 최상의 실시예를 인코딩하고 사람의 에러를 제거한다

모든 운용적인 활동의 지속적인 저장을 유지한다

당신의 전체 윈도우즈 데이터센터의 안전하고 스크립트 기반 운용을 중앙적으로 수행한다

작업 로드 요건(workload requirement)의 변화에 응답하여 서버 역할을 빠르게 변화시킨다

3. 당신의 기존의 서버 운용 투자를 레버리지한다

당신의 기존의 스크립트 기반 자동화 방법을 확장하고 향상시킨다

동작 자동화(Operational Automation) - 자동화의 코어 테넌트

동작상의 최상의 실시예의 포착 및 재사용을 가능하게 하는 유연한 프레임워크

동작 논리(Operations Logic)

자동화될 것 내의 풍부한 콘텍스트

이벤트는 SDM에 의하여 콘텍스트화되어(contextualized) 시스템 관리의 진정한 자동화를 가능하게 한다

"어떤 애플리케이션이 랙 22의 5번째 DL380 상에서 죽는(die) NIC에 의하여 영향을 받을 것이가?

트랜잭트-에이블(Transact-able)

보상 기반 모델(Compensation based model)은 롤백 및 언두(un-do)를 허용한다.

동작 논리 - 개발자 및 조작자 자동화를 위한 프레임워크.

동작 논리가 무엇인가?

오래 살고, 고가용성이며 내구성(durable)이 있는 인코딩된 동작 프로세스

서미트 컴퓨터 자원의 제어 및 콘텍스트를 위한 SDM을 레버리지

조작자가 시스템의 자동화 레벨을 변화시키는 것을 가능하게 함

개발자에 대한 이점

시스템이 (반환 코드와 같은) 애플리케이션 이벤트 및 메시지에 어떻게 반응하고 해결하는지를 개발자가 포착하도록 허용함

개발자가 사용하거나 확장할 수 있는 미리 정의된 동작상의 프로세스

자원을 배포, 업그레이드, 스케일-아웃 및 제거

ITPro 또는 조작자에 대한 이점

데이터센터에 대한 증명된 동작상의 최상의 실시예의 용이한 재사용을 가능하게 함

동작 자동화 - 프로그래밍 동작 논리. 도 116 참조.

SDM이 동작 논리과 상호작용하는 법:

이벤트는 인스턴스 및 컴포넌트 정보를 지시하기 위하여 주석 처리된다

모니터링 서브시스템은 시간-기반 이벤트 상관(time-based event correlation)을 한다

경고는 이벤트의 롤업(roll-up)이다

더 큰 의미론적 의미(Greater semantic meaning)

코맨드레트(Commandlet)는,

컴포넌트에 의하여 공개된 관리 명령의 세트

자기 설명적(self-describing)이다

쉘(shell) 바로 내에서 사용될 수 있다

GUI 형태 표시를 가질 수 있다

조작자를 위하여 사용하기 위한 "man-page"를 제공할 수 있다

도 117 참조.

동작 자동화 - 트랜잭트-에이블

트랜잭션은 고장 허용 동작(fault-tolerant operations)을 지원하기 위하여 중요하다

예: 웹 서비스를 추가

애드-혹 쉘 스크립트(ad-hoc shell script)로의 강력한 확장

트랜잭션 모델의 후원(auspices) 하의 모든 형태의 동작 논리

보상-기반

내구성

편성(orchestration)을 사용하면, 트랜잭션은 다수의 기계에 미칠 수 있다

관리 API 및 솔루션 - SDM의 풍부함을 레버리지.

시각화(visualization)는 SDM을 통하여 발생한다

제3자 콘솔(3rd party console)은 SDM으로부터 바로 정보를 끌어내거나 마이크로소프트 관리 솔루션의 플랫폼 노하우를 레버리지할 수 있다

마이크로소프트는 데이터 센터를 위한 SDM-기반 관리 콘솔을 빌드할 것이다

고객은 SDM을 통하여 커스텀 콘솔(custom console)을 생성할 수 있었다

도 118 참조.

산업계 범위 이니시어티브 - IHV, ISV, SI 혁신을 해방함(unleashing).

IHV HW 기준 플랫폼 사양(specification)

주요 OEM 및 스위치 제조자와 밀접하게 작업함

WinHEC (03년 5월)에서 릴리스하는 것을 목표로 함

새로운 강제적인 특징을 미래 HW 신청(offerings)에 넣음

주요 제3자 ISV와 계약함

Visual Studio를 위하여 애플리케이션 컴포넌트를 생성한다

SDM 내의 애플리케이션을 위한 자원 관리자

SDM 기반 관리 콘솔을 생성하기 위한 Mgmt ISV

고객 및 파트너로서 SI와 작업한다

고객

동작 비용을 급격하게 낮춘다

파트너

이 플랫폼 상에서 혁신적인 새로운 서비스 신청을 생성한다

동작 전문 지식(operations expertise)을 이용한다 -> 동작 논리를 개발한다

주요 고객 이점: 데이터 센터에 대한 선택권을 제공하고 가장 경제적이며 관리 가능한 플랫폼을 생성할 수 있다.

산업계 범위 시작 - SDM의 풍부함을 이종 환경으로 확장. Visual Studio(윈도우즈를 위한 SDM 애플리케이션의 개발을 가능하게 함) 또는 제3자 도구(다른 플랫폼을 위한 SDM 애플리케이션의 개발을 가능하게 함)를 사용하여 이종 SDM 애플리케이션을 개발.

결론

본 발명이 구조적인 특징 및/또는 방법론적인 동작에 특정한 말로 설명되었지만, 예시적으로 첨부된 청구항에 정의된 본 발명은 개시된 특정 특징 또는 동작에 의하여 제한되지 않는다는 것을 이해하여야 한다. 오히려, 특정 특징 및 동작은 청구된 본 발명을 구현하는 예시적인 형태로서 개시된다. 더욱이, 이들 청구항은 범위 및 기술적 사상(subject matter)에서 보면 예시적이다. 본 특징의 다수의 다른 조합 및 서브 조합은 본 출원에 대하여 우선권을 주장하는 특허 출원에서 후에 청구될 수 있다.

본 설명이 구조적인 특징 및/또는 방법론적인 동작에 특정한 말로 설명되었지만, 첨부된 청구항에 정의된 본 발명은 개시된 특정 특징 또는 동작에 의하여 제한되지 않는다는 것을 이해하여야 한다. 오히려, 특정 특징 및 동작은 본 발명을 구현하는 예시적인 형태로서 개시된다.

오늘날, 예를 들어, 일부 웹사이트들은 수천개의 컴퓨터들을 운영할 수 있고, 많은 분산형 애플리케이션들을 호스트할 수 있으며, 이들 분산형 애플리케이션은 종종 복잡한 애플리케이션들을 지원할 수 있도록 오퍼레이터가 IDC 내에 와이어링 구성을 수동적으로 배열할 뿐 아니라 어떤 네트워크 스위치들에 연결하도록 요청하는 필수품들(requirements)과 네트워크로 접속된 복합체를 가진다. 이러한 환경 하에서, 사람들의 오류를 적게 일으키면서도 시간 소모적은 프로세스를 방지할 수 있는, 물리적 컴퓨팅 시스템 상에 분산형 애플리케이션을 설계하고 배포하기 위한 개량된 기술을 제공할 수 있게 된다.

Claims (26)

1. 분산형 컴퓨팅 시스템(distributed computing system)들 및 분산형 애플리케이션(distributed application)들의 추상화 기술(abstract description)을 가능하게 하는 서비스 정의 모델(Service definition model;SDM) 및

   상기 서비스 정의 모델 내에서 어떻게 기능적 동작(functional operation)들이 지정되어야 하는지를 지시하기(dictate) 위한 스키마(schema)

   를 포함하며,

   상기 기능적 동작들은 분산형 애플리케이션의 설계, 분산형 애플리케이션의 배포(deployment), 및 분산형 애플리케이션의 관리를 포함하는 설계 도구.
2. 서비스 정의 모델(SDM)을 이용하여 구축된 분산형 시스템의 구현(implementation)을 호스팅하는(hosting) 단계;

   SDM 유형을 조작하기 위한 설정된 API들을 공개하는(exposing) 단계; 및

   분산형 애플리케이션들의 배포 및 관리를 위해 SDM 인스턴스(instance)들을 추적하는(tracking) 단계

   를 포함하는 방법.
3. 제2항에 있어서,

   설계 시간 유효성 검증(design time validation)을 위해 SDM 인스턴스들을추적하는 단계를 더 포함하는 방법.
4. 제2항에 있어서,

   상기 분산형 시스템 상에 분산형 애플리케이션들을 설계하는 단계를 더 포함하는 방법.
5. 제2항에 있어서,

   상기 서비스 정의 모델을 이용하여 상기 분산형 시스템 상에 분산형 애플리케이션들을 설계하는 단계를 더 포함하는 방법.
6. 서비스 정의 모델에 따라 물리적 데이터 센터(physical data center)를 기술함에 의해 상기 물리적 데이터 센터를 나타내는 스케일-불변 가상 데이터 센터(scale-invariant virtual data center)의 설계를 실행하는 단계를 포함하고,

   여기서, 상기 서비스 정의 모델은, 분산형 애플리케이션의 설계와 관련된 서비스들, 분산형 애플리케이션의 배포와 관련된 서비스들, 및 분산형 애플리케이션의 관리와 관련된 서비스들을 포함하는 방법.
7. 제6항에 있어서,

   상기 가상 데이터 센터는 제1 데이터 센터 및 제2 데이터 센터에 의해 지원되며, 상기 애플리케이션 부분들과 상기 가상 데이터 센터 부분들 간의 논리적 모델 매핑(logical model mapping)에서의 변화를 요청함이 없이 상기 제1 데이터 센터 및 제2 데이터 센터 중 하나로 애플리케이션을 배포할 수 있는 방법.
8. 제6항에 있어서,

   상기 물리적 데이터 센터의 특정한 논리적 컴포넌트를 위해 생성되도록 다수의 인스턴스를 결정하는 단계, 및

   상기 물리적 데이터 센터를 구현하기 위해 와이어링 토폴로지(wiring topology)를 결정하는 단계

   를 더 포함하는 방법.
9. 제6항에 있어서,

   물리적 자원(physical resource)들 및 분산형 애플리케이션을 자동으로 배포하는 단계를 더 포함하는 방법
10. 제6항에 있어서,

    모델 기반 관리 접근방식(model-based management approach)을 이용하여 상기 물리적 데이터 센터 상에서 분산형 애플리케이션을 관리하는 단계를 더 포함하는 방법.
11. 제6항에 있어서,

    상기 물리적 데이터 센터는 트리거링 이벤트(triggering event)에 응답하여 일련의 동작 태스크들을 조정하기(orchestrating) 위한 동작 엔진을 포함하는 방법.
12. 제11항에 있어서,

    상기 트리거링 이벤트는 상기 서비스 정의 모델로부터의 애플리케이션 문맥(application context)으로 주석 처리되는(annotated) 방법.
13. 제11항에 있어서,

    상기 일련의 동작 태스크들은 자원 관리 시스템을 이용하여 새로운 자원을 배포하는 단계를 포함하는 방법,
14. 가상 데이터 센터 및 분산형 애플리케이션의 설계를 실행하는 단계;

    상기 분산형 애플리케이션의 부분들을 상기 가상 데이터 센터 상으로 논리적으로 배치하는(placing) 단계; 및

    상기 가상 데이터 센터에 기초하여 물리적 데이터 센터를 구현하는 단계

    를 포함하는 방법.
15. 제14항에 있어서,

    상기 분산형 애플리케이션의 부분들을 상기 가상 데이터 센터 상으로 논리적으로 배치하는 단계를 수행할 때, 상기 가상 데이터 센터의 오퍼레이터의 뷰(view)는, 상기 분산형 애플리케이션의 배치와 연관된 부분들만을 포함하도록 제한되는 방법.
16. 제14항에 있어서,

    상기 가상 데이터 센터는 복수의 서비스 정의 모델 계층 - 상기 계층 각각은 그 아래에 있는 계층 상에 논리적으로 배치됨 - 을 포함하는 방법.
17. 제14항에 있어서,

    상기 분산형 애플리케이션을 지원하기 위하여, 상기 가상 데이터 센터의 자원들을 할당하는 단계를 더 포함하는 방법.
18. 가상 데이터 센터 및 분산형 애플리케이션의 설계를 실행하는 단계;

    상기 분산형 애플리케이션의 부분들을 상기 가상 데이터 센터 상으로 논리적으로 배치하는 단계; 및

    상기 분산형 애플리케이션의 부분들의 배치가 유효한지 여부를 결정하는 단계

    를 포함하는 방법.
19. 제18항에 있어서,

    상기 분산형 애플리케이션의 부분들의 배치가 유효하지 않은 경우, 경고 메시지를 생성하는 단계를 더 포함하는 방법.
20. 제18항에 있어서,

    상기 가상 데이터 센터에 기초하여 물리적 데이터 센터를 구현하는 단계를 더 포함하는 방법.
21. 제18항에 있어서,

    상기 분산형 애플리케이션을 지원하기 위하여, 상기 가상 데이터 센터의 자원들을 할당하는 단계를 더 포함하는 방법.
22. 분산형 컴퓨팅 시스템 상에 분산형 애플리케이션들을 설계, 배포, 및 관리하는데 사용하기 위한 소프트웨어 아키텍쳐로서,

    기계들을 상기 분산형 컴퓨팅 시스템에 사용되는 서버들로 변환하기 위해 사용되는 도구(tool)들을 위한 제1 소프트웨어 계층;

    분산형 애플리케이션들의 가상 토폴로지 생성 및 네트워크 관리를 위한 제2 소프트웨어 계층;

    상기 분산형 컴퓨팅 시스템의 물리적 모델을 유지하기 위한 제3 소프트웨어 계층;

    상기 분산형 애플리케이션에 의해 요청되는 논리적 자원들의 할당을 촉진하기 위한 제4 소프트웨어 계층;

    애플리케이션 자체 감시(introspection) 및 애플리케이션 자원의 제어를 위한 API 및 동작 프로세스를 기술하기 위한 문맥(context)과 네임스페이스 (namespace)를 제공하는 서비스 정의 모델(SDM)를 위한 제5 소프트웨어 계층;

    문맥, 명칭 부여(naming), 및 바인딩(binding)을 위해 상기 SDM API를 이용하는 분산형 애플리케이션의 재사용가능한 빌딩 블럭(building block)들을 정의하기 위한 제6 소프트웨어 계층; 및

    상기 분산형 애플리케이션의 동작 관리를 위한 제7 소프트웨어 계층

    을 포함하는 소프트웨어 아키텍쳐.
23. 분산형 컴퓨팅 시스템 내에 자원들을 할당하기 위한 수단;

    가용 하드웨어를 발견하기 위한 수단;

    자원 할당 요청들을 처리하기 위한 수단;

    자원들의 소유권(ownership)을 추적하기 위한 수단;

    자원들을 제어하기 위한 수단; 및

    상기 분산형 컴퓨팅 시스템 내에서 모든 자원 관리를 위한 공통 API를 제공하기 위한 수단

    을 포함하는 자원 관리자.
24. 제23항에 있어서,

    상기 자원을 할당하기 위한 수단은 상기 분산형 컴퓨팅 시스템 내에 논리적 자원들 및 물리적 자원들을 할당하도록 구성된 자원 관리자.
25. 제23항에 있어서,

    상기 분산형 컴퓨팅 시스템 상에서 분산형 애플리케이션을 관리하기 위한 수단을 더 포함하는 자원 관리자.
26. 제23항에 있어서,

    상기 자원을 제어하기 위한 수단은 이벤트에 응답하여 일련의 동작 태스크들을 조정하도록 구성된 자원 관리자.