KR20060112184A

KR20060112184A - 모니터링 규칙의 스케일가능 동기 및 비동기 처리

Info

Publication number: KR20060112184A
Application number: KR1020057009402A
Authority: KR
Inventors: 더글라스 알. 벡; 스티븐 제이. 맨지스; 레이몬드 더블유. 맥콜럼; 라두 알. 팔랑카
Original assignee: 마이크로소프트 코포레이션
Priority date: 2003-10-24
Filing date: 2004-07-27
Publication date: 2006-10-31
Also published as: US7539974B2; WO2005045739A3; JP5030592B2; US20050114494A1; CN101410795A; CN101410795B; KR101203224B1; JP2007519075A; WO2005045739A2; EP1678653A2; EP1678653A4

Abstract

규칙의 스케줄링 및 병행 처리를 위한 규칙 런타임 엔진. 이 엔진은 병렬 방식으로 다수의 규칙을 효율적으로 실행한다. 이는 규칙 정의 언어로 규칙을 제작하고, 이들 규칙을 런타임 엔진으로의 통신을 위해 번역기를 통해 전달하며, 런타임 엔진을 사용하여 번역된 명령을 스케줄 및 병행 처리함으로써 달성된다. 또한, 엔진은 명령을 인스턴스화하는 구성 데이터를 수신함으로써, 일련의 규칙에 형태를 부여한다.

동기 처리, 모니터링, 규칙 런타임 엔진, 번역된 명령, 병행 처리

Description

모니터링 규칙의 스케일가능 동기 및 비동기 처리{SCALABLE SYNCHRONOUS AND ASYNCHRONOUS PROCESSING OF MONITORING RULES}

<관련 출원의 상호 참조>

본 출원은 2003년 10월24일에 출원되고 발명의 명칭이 "SCALABLE SYNCHRONOUS AND ASYNCHRONOUS PROCESSING OF MONITORING RULES"인 미국 특허출원번호 제10/693,072호에 대해 우선권을 향유하며, 다음의 함께 계류중이며 2003년 10월23일에 출원되고 발명의 명칭이 "MODEL-BASED MANAGEMENT OF COMPUTER SYSTEMS AND DISTRIBUTED APPLICATIONS"인 미국 특허출원번호 제10/692,216호, 2003년 10월24일에 출원되고 발명의 명칭이 "RULES DEFINITION LANGUAGE"인 미국 특허출원번호 제10/692,660호, 2003년 10월24일에 출원되고 발명의 명칭이 "USING URI'S TO IDENTIFY MULTIPLE INSTANCES WITH A COMMON SCHEMA"인 미국 특허출원번호 제10/693,588호, 및 2003년 10월23일에 출원되고 발명의 명칭이 "USE OF ATTRIBUTION TO DESCRIBE MANAGEMENT INFORMATION"인 미국 특허출원번호 제10/692,432호와 관련된다.

본 발명은 소프트웨어 애플리케이션의 시스템 관리에 관한 것이며, 보다 구체적으로는, 규칙의 비동기 처리를 위한 규칙 엔진에 관한 것이다.

종래 시스템 관리는 대부분 임시적이다. 애플리케이션 개발자는 그들의 애플리케이션을 관리하고 높은 신뢰성을 달성하기 위한 구조화된 프레임워크를 가지고 있지 않다. 이러한 관리 아키텍처를 용이하게 하는데 사용되는 많은 언어는 본질적으로 단일 스레드되고 멀티태스킹에 대한 지원을 추가한다. 그 결과, 이들 언어에서 스레드 등의 운영 체계 지원 구성체를 통해 멀티태스킹를 달성하는 것은 사용자의 책임이다.

규칙 기반 메커니즘의 사용은 소프트웨어에서 유연성을 제공하여, 작업 및 데이터가 하나 이상의 규칙을 대체하여 쉽게 변경될 수 있게 한다. 가장 기본적인 원칙은 규칙이며, 이는 조건을 평가하여 동작을 개시하는 논리를 구현한다. 예를 들면, 규칙은 시스템 디스크의 상태를 관측하여 디스크 사용이 특정 임계치 이하로 떨어지는 경우에 에러를 보고할 수 있다. 다른 규칙은 프로세서 활용을 모니터링하여 활용이 특정 임계치를 초과하는 경우 에러를 보고할 수 있다. 통상의 모니터링 시스템에서, 두 규칙은 동시에 실행될 수 있다. 사용자가 통상의 프로그래밍 언어, 예를 들어, Visual Basic .Net를 사용하기를 원하는 경우, 규칙이 동시에 실행될 수 있도록 스케줄링하는 코드와 규칙 의도를 나타내는 논리를 기입하여야 한다.

많은 규칙의 병행 처리를 용이하게 하는 개선된 규칙 기발 엔진이 필요하다.

본 발명의 몇몇 양태의 기본적 이해를 제공하기 위해 이하 본 발명의 간략한 요약을 제공한다. 본 요약은 본 발명의 전반에 걸친 개요가 아니다. 본 발명의 주요/중요 요소를 식별하거나 본 발명의 범위를 나타내려는 것도 아니다. 이의 유일한 목적은 후술하는 보다 상세한 설명에 대한 도입부로서 본 발명의 일부 개념을 보다 간략한 형태로 제공하는 것이다.

여기서 개시되어 청구된 본 발명의 일 양태는, 규칙 런타임 엔진에서 규칙을 명령의 병행 처리를 용이하게 하는 명령으로 번역하는 번역기 컴포넌트를 포함한다. 이 번역이 컴포넌트는 모든 상태가 런타임 엔진으로 유지되도록 명령의 인스턴스화를 용이하게 한다. 명령은 유틸리티 함수를 호출하고 런타임 엔진의 코드 실행 스위칭의 산출을 용이하게 하는 산출 문장(yield statement)을 포함한다.

다른 양태에서, 개발자들이 시스템을 건강(healthy)하게 하는데 충족되어야 할 기준을 표현하는 다수의 규칙을 용이하게 만들 수 있게 하는 창의적 모델 기반 관리의 규칙 엔진이 제공된다. 프레임은 다수의 규칙의 스케줄링과 병행 처리를 용이하게 하는 런타임 아키텍처를 제공한다.

모니터링 규칙 엔진은 규칙의 자동 스케줄링을 처리함으로써, 사용자에게 이 부담을 덜어주고 사용자가 모니터링 논리를 표현하는 것에만 집중할 수 있게 한다. 예를 들면, "내 디스크가 80%이상 채워지면, 시스템 관리자에게 알린다"는 의도를 표현하는 규칙이 기재될 수 있다. 비컴퓨터 세계의 임의의 규칙 본문과 같은 규칙의 모니터링은 동시에 묵시적으로 처리되기 때문에 모든 규칙은 동시에 강제로 개념화된다(그와 달리 명시적으로 기재되지 않은 경우). 규칙 엔진은 사용자로부터 규칙 스케줄링 표면 부담을 덜어주는 방식으로 많은 규칙의 이러한 묵시적 병행 처리를 용이하게 하는 런타임 아키텍처를 제공한다. 그 결과, 사용자가 해야 하는 것은 모두 사용자가 스케줄링에 대한 고려 없이 이 규칙을 기재하는 것뿐이며, 이 시스템은 스케줄링과 병행 처리를 고려할 수 있다.

규칙 엔진은 RDL(규칙 정의 언어)로 알려진 규칙을 지원한다. 규칙 모니터링 시스템은 다음의 하이 레벨 요건: 고유 병렬성(intrinsic parallelism) - 여러 개를 동시에 감시; 상호관련성; 사용 용이성; 스케일가능성; 규칙 개수를 갖는 낮은 메모리 풋프린트 및 선형 성장; 낮은 CPU 활용; 및 확장가능성을 제공하여 기존 규칙과 런타임 소프트웨어를 용이하게 사용하여 확장한다.

상기 요건, 특히, 특히 사용 용이성과 고유 병렬성은 규칙 엔진의 설계에 유리한 영향을 부여한다. 대부분의 다른 언어는 내재적으로 단일 스레드되고 멀티태스킹에 대한 지원을 추가한다. 그러나, 이와 달리 RDL 언어는 규칙의 논리적 병렬 실행을 가능하게 하여 규칙 개발자는 동시적 규칙 평가를 달성하기 위해 많은 노력을 행할 필요가 없게 되기 때문에 매우 강력하다. 고유 병렬성으로 인해, 이러한 아키텍처는 다수의 스레드 중에서 규칙의 스케줄링을 지원한다.

상기 및 관련 목적의 달성을 위해, 본 발명의 특정한 예시적인 양태는 후술하는 설명 및 첨부 도면에 관련하여 설명한다. 그러나, 이들 양태는 본 발명의 원리가 사용될 수 있으며 본 발명은 모든 이러한 양태와 이들의 균등물을 포함하려는 다양한 방식 중 일부를 나타낸다. 본 발명의 다른 이점 및 신규한 특성은 첨부 도면을 참조하여 본 발명의 후술하는 상세한 설명으로부터 명확하게 될 것이다.

도 1은 본 발명의 컴포넌트의 블럭도.

도 2는 규칙 모니터링 처리의 흐름도.

도 3은 본 발명에 따른 규칙 인스턴스화의 흐름도.

도 4는 규칙 대 규칙 호출 처리의 흐름도.

도 5는 본 발명에 따라 규칙 엔진을 사용하여 모델 기반 아키텍처를 나타내는 도면.

도 6은 모델 기반 관리 아키텍처의 주요 컴포넌트를 나타내는 것에 관련된 도면.

도 7a는 모델 기반 관리 아키텍처의 모델 컴포넌트에 관련된 블럭을 나타내는 도면.

도 7b는 모델 기반 관리 아키텍처의 명백한 컴포넌트에 관련된 블럭을 나타내는 도면.

도 7c는 모델 기반 관리 아키텍처에 따른 애플리케이션 또는 서비스를 관리하는데 사용되는 시스템 컴포넌트의 코어 시스템 API의 블럭도.

도 7d는 모델 기반 관리 아키텍처의 시스템 컴포넌트의 관리 관련 API의 블럭도.

도 7e는 모델 기반 관리 아키텍처의 작업 컴포넌트의 주요 서브컴포넌트를 나타내는 도면.

도 8은 모델 기반 관리의 처리의 흐름도.

도 9는 모델 기반 관리를 구현하는 처리의 보다 상세한 흐름도.

도 10은 모델 기반 관리의 바람직한 상태를 구현하는 처리의 흐름도.

도 11은 개시된 아키텍처를 실행하는 컴퓨터의 블럭도.

도 12는 본 발명에 따른 예시적인 컴퓨팅 환경의 개략 블럭도.

본 발명은 이하 도면을 참조하여 설명하며, 동일 참조부호는 동일 요소를 나타내는데 사용된다. 후술하는 설명에서, 설명의 목적으로, 수많은 특정 세부사항이 본 발명의 철저한 이해를 제공하기 위해 기재된다. 그러나, 본 발명은 이들 특정 세부사항없이 실행될 수 없음이 명백할 수 있다. 다른 경우, 기지의 구조 및 장치가 본 발명의 설명을 용이하게 하기 위해서 블럭도 형태로 도시되어 있다.

이 애플리케이션에서 사용되는 바와 같이, "컴포넌트"와 "시스템"이라는 용어는 컴퓨터 관련 엔티티, 하드웨어, 하드웨어와 소프트웨어의 조합, 소프트웨어, 또는 소프트웨어의 실행을 지칭하려는 것이다. 예를 들면, 컴포넌트는 프로세서 상에 동작하는 처리, 프로세서, 객체, 실행가능(executable), 실행 스레드, 프로그램 및/또는 컴퓨터일 수 있지만 이에 국한되는 것은 아니다. 예를 들면, 서버 상에서 동작하는 애플리케이션과 서버는 모두 컴포넌트일 수 있다. 하나 이상의 컴포넌트가 실행의 처리 및/또는 스레드 내에 상주할 수 있으며, 컴포넌트는 하나의 컴퓨터 상에서 로컬화되거나 및/또는 둘 이상의 컴퓨터 사이에 분산될 수 있다.

도 1을 이하 참조하면, 본 발명의 컴포넌트의 블럭도가 도시되어 있다. 병행 방식으로 규칙 실행을 용이하게 하는 규칙 모니터링 시스템(100)이 제공된다. 모니터링 시스템(100)은 세개의 논리 엔티티를 포함한다: 시스템(100)에 입력되는 하나 이상의 규칙(104)을 표현하는 입력 명령 컴포넌트(102; 규칙 정의 언어(RDL) 로 불림); 명령(102)을 판독하여 이들을 병렬 실행 형태로 변형시키는 번역기 컴포넌트(106); 및 번역된 명령을 판독하여 번역된 명령의 효율적인 스케줄링과 병렬 처리를 용이하게 하는 규칙 런타임 엔진(108).

RDL 명령(102)은 소프트웨어와 하드웨어 컴포넌트의 이용가능성을 모니터링할 목적으로 하는 규칙 정의를 가능하게 한다. 예를 들면, 규칙은 시스템 디스크의 상태를 감시하여 디스크 사용이 특정 임계치 이하로 저감되는 경우 에로를 보고할 수 있다. 다른 규칙은 CPU 활용을 모니터링하여 활용이 특정 임계치를 교차할 때 에러를 보고할 수 있다. 통상의 모니터링 시스템에서, 두 규칙은 동시에 동작할 수 있다.

런타임 엔진(108)은 RDL로 표현된 규칙 코드뿐만 아니라 규칙 코드를 인스턴스화하는데 사용되는 구성 데이터(110)를 입력으로서 취급한다. 이 규칙 코드는 일련의 규칙 유형으로 구성된다. 각 유형은 하드웨어 및/또는 소프트웨어 타겟이 모니터링되는 시스템에 대한 바람직한 상태에 있는지를 판정하는데 필요한 논리를 나타낸다. 타겟이 바람직한 상태에 있지 않다고 유형이 판단하면, 통상 몇몇 동작을 수행한다. 예를 들면, 아래 코드는 시스템이 바람직하지 않은 상태에 있는 경우 다수의 에러 이벤트의 전송을 억압하는 규칙 유형을 사용한다. 규칙 논리는 RuleType...End RuleType 키워드에 의해 분리되고 구별된다. 코드는 번역기 컴포넌트(106)에 의해 번역되고 규칙 엔진(108)에 로딩되어 인스턴스화될 수 있는 상태에 있게 된다. 규칙 코드는 구성 데이터(110)를 런타임 엔진(108)으로 로딩하여 인스턴스화되며, 그 구성 데이터는 어느 규칙이 동작할지 그리고 규칙을 실행하는 데 필요하는 파라미터를 규정한다.

통상, 사용자가 통상의 프로그래밍 언어를 사용하기 원하는 경우, 병행 실행되는 규칙뿐만 아니라 규칙 의도를 표현하는 논리를 스케줄링하는 코드가 기입될 필요가 있다. 본 발명의 신규한 규칙 엔진(108)은 규칙 스케줄링을 처리함으로써, 사용자에게 이러한 부담을 덜어주어 모니터링 로직 표현에 집중할 수 있게 한다.

스케줄링을 용이하게 하기 위해서, 규칙은 RDL로 기재된 후 임의의 적절한 언어, 예를 들면, C#으로 번역될 수 있다. 번역된 코드는 "산출" 구문을 코드로 도입하여 여러 코드 중에서 스케줄링을 지원하도록 설계된다. 이 경우, "산출"은 규칙 코드에서 엔진 코드에 그리고 다른 규칙 코드에 스위칭하게 한다. 이는 규칙 엔진(108)이 한정된 개수의 스레드로 규칙을 멀티태스크할 수 있게 한다.

다음 규칙에서, 구성 데이터는 규칙으로서 실행할 DnsRule를 규정하고, TimeLimit, CountLimit, 및 RestartInterval 파라미터에 대한 값을 제공한다.

병렬 방식으로 예시화된 규칙을 동작하기 위해서, 번역기 컴포넌트(106)는 규칙 코드를 런타임 엔진(108)과의 상호동작을 용이하게 하는 중간 형태로 번역한다. 중간 형태는 규칙(인수 및 로컨 변수)에 대한 모든 상태가 엔진(108)에 의해 유지되도록 설계된다. 규칙은 코드 실행 스위칭에 대한 엔진(108)의 런타임을 산출하고, 엔진(108)에 의해 제공되는 유틸리티 함수를 호출한다. 번역된 코드는 주기적 산출 명령을 코드에 입력한다. 상기 예에서, 번역은 매 루프의 끝에서 적어도 GetEvent 호출 후에 산출할 수 있다.

상기 코드 샘플은 인수 및 로컬 변수의 두 형태로 상태 정보를 유지한다. 예는 TimeLimit와 Count를 각각 포함한다. 엔진(108)이 이 코드의 실행을 중지하는 경우, 이들 변수의 상태가 유지되어 코드가 엔진(108)에 의해 실행된 다음에 이용가능하다.

Within 블럭은 엔진(108) 상의 유틸리티 함수가 이용되는 예를 제공한다. 상기 코드에서, 포함된 코드에 대한 시간 제한을 엔진(108)이 가하게 하는 Within...End Within 문장이 존재한다. 포함된 코드가 실행하도록 규정된 시간보다 긴 경우, 엔진(108)은 자동적으로 블럭의 Else 부분이 Within...Else 문장 사이에 코드의 실행을 동시 중단하면서 동작하게 한다. 이 블럭의 번역 버전은 명령을 Within 블럭이 입력된 엔진(108)에 명령을 전송한다. 그 후, 엔진(108)은 규칙 코드의 실행을 모니터링하고 상술한 구문이 명확해지도록 적절한 동작을 수행한다.

규칙 모니터링에서, 통상, 특정 이벤트가 발생할 때까지 대기한 후 동작한다. 엔진(108)은 다수의 이벤트에 대한 효율적인 대기를 지원하면서 이러한 대기를 코드로 표현하기 쉽게 한다. GetEvent 명령 호출은 (Within 문장으로 표현된 바와 같은 시간으로 한정되는) 무언가가 발생할 때까지 대기한 후 그 정보에 동작하는 요구를 용이하게 표현한다. GetEvent 명령은 엔진(108)이 코드를 슬리프(sleep) 상태에 두고 이에 대한 이벤트를 대기하도록 번역된다. 이벤트가 발생한 경우, 코드가 재개되어 이벤트 상에 동작할 수 있게 된다.

요컨대, 엔진(108)은 병렬 방식으로 다수의 규칙을 효율적으로 동작한다. 이는 규칙을 RDL로 기재하고, 이들 규칙을 번역기(106)를 통해 런타임 엔진(108)으로 전달하여 달성된다. 엔진(108)은 명령을 인스턴스화하는 구성 데이터를 수신하여, 일련의 규칙에 형태를 부여한다.

규칙 엔진과 그 모든 컴포넌트는 컴퓨터 판독가능 매체에 구체화될 수 있음을 이해할 수 있다.

도 2를 이하 참조하면, 규칙 모니터링의 처리의 흐름도를 나타낸다. 설명의 간이함을 위해서, 하나 이상의 방법론이 여기에, 예를 들면, 흐름도의 형태로 도시되고, 일련의 동작으로 설명되지만, 본 발명은 이 동작 순서에 한 정되지 않으며, 몇몇 동작이 본 발명에 따라 상이한 순서로 및/또는 여기서 설명된 다른 동작과 동시에 발생할 수 있다. 예를 들면, 당업자는 방법론이 다르게는 상태도 등의 일련의 상호관련 상태 또는 이벤트로서 표시될 수 있음을 이해할 것이다. 더욱이, 도시된 모든 동작이 본 발명에 따른 방법을 구현하는데 필요한 것은 아니다.

200에서, 규칙은 시스템에 수신되어 RDL로 기재된다. 202에서, 규칙은 규칙 엔진과의 상호동작을 용이하게 하는 중간 형태로 번역된다. 204에서, 번역 규칙이 런타임 엔진으로 로딩된다. 206에서, 엔진은 구성 데이터를 수신하여 코딩 및 번 역 규칙을 인스턴스화한다. 208에서, 번역 규칙은 병렬 처리를 위해 런타임 엔진으로 스케줄링되고 처리된다. 그 후, 처리는 정지 블럭에 도달한다.

도 3을 이하 참조하면, 본 발명에 따른 규칙 인스턴스화의 흐름도가 도시되어 있다. 300에서, 규칙은 엔진과의 상호동작을 위해 중간 형태로 번역된다. 302에서, 엔진은 규칙에 대한 모든 상태를 유지한다. 304에서, 번역 형태는 산출 명령을 코드에 입력한다. 306에서, 번역 형태는 규칙 코드 실행을 위한 엔진 런타임을 산출한다. 308에서, 번역 형태는 엔진에 의해 제공된 유틸리티 함수를 호출한다. 그 후, 처리는 정지 블럭에 도달한다.

변역 알고리즘

번역 동안, 깊이 우선 트래버스 라벨(depth-first traversal label)과 임시 변수가 좌에서 우로 그리고 아래에서 위로 순서가 정해지도록 각각의 적절한 노드에서 생성된다. 각 라벨 노드(모든 노드가 라벨을 수신하는 것은 아님)는 임시 변수 할당, 연속 라벨에 대한 명령 블럭 할당, 및 리턴 문장을 생성한다. 번역 알고리즘은 코딩하기 용이하다는 이점이 있다. 이는 다수의 명령 블럭을 생성하여 엔진에 리턴한다. 다음은 단순 할당 문장(판독용이성을 위해 간략한 표기가 사용됨)의 번역을 나타낸다.

r Ln - 명령 블럭을 Ln에 설정하여 리턴.

RDL:

myOjbect.Property = a+b-c

할당 문장의 번역은 다음과 같다:

RDL로 기재된 규칙은 모듈에 그룹화된다. 모듈은 컴파일러를 사용하여 클래스, 예를 들어, 다음과 같은 Visual Basic StandardModuleAttribute로 번역될 수 있다:

번역 코드는 일련의 명령 블럭으로 나뉘어진다. 명령 블럭은 스위치 케이스 블럭으로 분리되고 규칙 프레임은 현재 블럭을 유지하는 필드를 갖는다. 번역 블럭이 MSIL와 같이 동일 레벨의 세분성(granularity)을 갖지 않더라도 함수 블럭은 MSIL(마이크로소프트 중간 언어) 주소의 등가이다. MSIL은 다수의 컴파일러(예를 들어, C#, VB, 및 .NET)의 출력으로서 사용되는 언어이다. 각 명령 블럭은 블럭 내의 모든 코드가 하나의 단위로서 실행되어 엔진으로의 산출이 블럭 사이에 발생한다는 의미에서 동작 항목을 나타낸다.

다음 코드는 명령 블럭이 사용되는 방식의 단순 예를 나타낸다. 아래 도시된 규칙은 3개의 고유 블럭으로 나뉘어진다. 각 블럭은 리턴 문장으로 종료한다. 규칙이 엔진으로 리턴하기 전에, 규칙 프레임은 규칙에 재입력 시에 다음에 실행되어야 하는 명령 블럭으로 갱신된다. 제2 블럭에서 나타낸 바와 같이 스위치 문장에서 브레이크가 발생하는 경우, 이는 규칙을 종료시킨다.

규칙은 종료 전에 IExecutionStack.SetCallerFrame()를 호출하여 엔진은 다음에 호출자 규칙을 입력할 수 있다.

모든 규칙은 서명, 예를 들어, 다음과 같은 서명을 갖도록 번역된다:

public static void RuleName(IExecutionStack stack)

리턴값과 파라미터는 모두 스택 상에 위치한다. 나타낸 바와 같이, 모든 규칙은 정의될 수 있는 모듈의 멤버인 정적 함수로서 구현된다. 모듈은 여기서 설명되는 바와 같이 클래스로 번역된다.

규칙명은 RDL 파일에 표현된 이름과 정확하게 일치한다. 다음은 완전하게 적격한 규칙명의 일 예이다:

Namespace.ModuleName.RuleName

스타트업 규칙은 스타트업 속성 <Startup>으로 마킹된다. 모든 스타트업 규칙은 성공적인 로딩 시에 규칙 엔진에 의해 호출된다.

Rule MyRule

End Rule

번역된 스타트업 규칙은 다음과 같다:

[Startup]

public static void MyRule(IExecutionStack stack)

ValueType이 Start를 통한 함수인 ByRef에 전달되면, 아래 메커니즘을 통해 복사본만을 수신한다. 이는 호출자 내의 원래의 복사본이 변하지 않음을 의미한다.

도 4를 이하 참조하면, 규칙 대 규칙 호출을 위한 흐름도가 도시되어 있다. RDL은 하나의 규칙이 다른 규칙을 호출하도록 조정한다. 규칙 대 규칙 호출은 번 역 코드로 다음 단계를 포함한다. 400에서, 리턴 어드레스는 호출자에 대하여 설정된다(케이블 블럭 값). 402에서, 수신자(callee)에 관련된 규칙 프레임("RuleFrame")이 생성된다. 404에서, 규칙 프레임에 대하 구성체는 번역된 함수에 대한 델리게이트(delegate)를 취하며, 엔진에 의해 사용되어 실제 통화를 행한다. 406에서, 수신자 함수에 대한 파라미터는 프레임 내에 설정된다. 408에서, 수신자 프레임은 그 후 스택 상에 푸시되고, 엔진으로 흐름이 리턴된다. 단계 400 내지 508은 프롤로그를 나타낸다. 410에서, 스택은 호출자의 설정이다. 412에서, 수신자 프레임은 스택으로부터 팝된다(popped). 414에서, 로컬 변수가 임의의 ByRef 파라미터에 대하여 설정된다. 그 후, 416에서 나타낸 바와 같이 흐름이 엔진에 리턴된다. 단계 412 및 414는 에필로그를 나타낸다.

RDL 표현은 다음 조건을 제외하면 번역된 코드와 대략 일대일로 매핑한다: 표현이 규칙 호출을 포함하는 경우; 그리고 표현이 비동기 함수 호출을 포함하는 경우. 표현이 이러한 유형의 용어를 포함하는 경우, 표현은 3개의 어드레스 코드에 분해된다. 컴파일러는 상에서 하로 그리고 좌에서 우로 트리를 조회하여 각 노드에서 원형 번역을 생성한다. 요약 구문 트리(AST)가 트래버스됨에 따라, 라벨과 임시 변수 지정이 획득된다.

RDL은 변수에 대한 2개의 영역을 포함한다: 즉, 인수 및 로컨 변수. 표현이 완전히 감소되는 경우, 인수 또는 로컬 변수에 대한 할당이 행해져서 번역될 수 있다.

모든 번역 함수는 관련 커스텀 RuleFrame 유도 클래스를 갖는다. 유도 클래 스는 RDL 함수에 전달된 파라미터에 직접 관련되는 멤버를 포함한다. 이는 함수로 번역된다.

함수가 호출되는 경우, 유도된 RuleFrame 내의 멤버는 상술한 바와 같이 프롤로그 내에서 적절하게 설정되고, RuleFrame은 스택 상에 푸시된다. 리턴 시에, ByRef 멤버는 판독되어 상술한 바와 같이 에필로그 내에 적절하게 호출자 프레임에 전달된다.

폴링이 RDL 내에 지원된다. 폴링을 지원하기 위해서, RuleFrame 클래스는 폴링 구조의 스택을 유지한다. 스택은 단일 함수 내에 폴링 중첩을 가능하게 한다. 엔진은 단지 현재 프레임에 대한 폴링 구조와 스택의 상부에 있는 폴링 구조에 따라 스케줄링한다. 폴링에 대하여 구성하기 위해서, 폴링 구조는 스택 상부에서 설정된다. 폴링 명령은 폴링 구조를 생성하여 이를 스택 상에 푸시하기 때문에 폴링 블럭 당 한 번만 호출된다. 블럭 엔트리 시에, 타임 구간이 설정된다. 그 후, 리턴 명령이 설정되고 엔진으로 흐름이 진행한다.

그 후, 엔진은 폴링이 설정되었는지를 점검하여, 실행을 위한 실행 스택을 스케줄링한다. 폴링 간격이 설정될 때마다, 플래그가 프레임 내에 설정되어 폴링이 설정되었는지를 나타낸다. 폴링 간격이 변경되지 않았으면, 폴링 플래그가 수동으로 설정될 수 있다. 엔진은 스케줄링 후에 플래그를 설정한다. 따라서, 생성 코드는 결코 폴링 플래그를 재설정하지 않는다. 폴링 구조는 그 후 퇴거(exit) 시에 폴링 스택에서 팝핑된다.

RDL은 두 개의 데이터형, 즉, 참조 유형과 값 유형을 사용한다. RDL 참조 데이터형은 일대일로 프로그래밍 언어 대응부분으로 번역하고(예를 들어, C#), 그 범위에 따라 로컬 프레임 또는 규칙 프레임 내에 상주한다. 이라 변수에 대한 범위를 설명한다. 값 유형은 참조에 의해 전달될 수 없기 때문에 수많은 이슈 포함 복싱(issues surrounding boxing)을 제공한다. 이는 참조 유형 내에 둘러싸일 수 있다.

변수는 RDL 내에 두개의 고유 집약성(locality)을 갖는다. 변수는 함수에 대한 파라미터 리스트 내에 또는 함수 자체 내에 범위지정된다. 변수가 파라미터 리스트의 일부인 경우, 유도된 RuleFrame 명령 내에 생성된다. 변수가 함수 내에 선언되면, 함수의 로컬 프레임 내에 상주한다. 로컬 프레임은 컨테이너 함수에 매우 특정된다. 기본 RuleFrame 클래스는 로컬 프레임에 대한 참조를 유지한다.

분석자 호출은 임의의 종래의 객체 호출과 동일하다. 이들 호출은 두개의 방식, 즉, 동기 및 비동기로 행해진다. 동기 호출은 집적적인 호출로서, 함수에 대한 파리미터 및 리턴값은 로컬 프레임 상의 번수(또는 리터럴)이다. 동기 호출은 다음과 같이 나타낸다:

몇몇 경우, 메소드 호출은 비동기이다. 이들 호출은 표준 비동기 설계 패턴을 따른다. 리턴 어드레스가 설정되고, 프레임은 지연되는 것으로 표시된다. 그 후 비동기 BEGIN 연산이 객체에 대하여 호출된다.

마지막 두개의 파라미터는 비동기 콜백을 제공하며, 비동기 콜백은 규칙 엔진에 대한 실행배정기(dispatcher) 및 규칙에 대한 실행 스택이다. 마지막 두개의 파라미터는 동일하며 모든 비동기 호출에 대하여 요구된다. 제1 세트의 파라미터는 비동기 컴포넌트의 속성에 따라 가변한다. 비동기 호출이 완료하는 경우, 스레드는 궁극적으로 콜백을 규칙에 전달하는 엔진 디스패치 핸들러에 디스패치된다.

루프

상술한 바와 같이, 규칙은 일련의 명령 블럭으로 나뉘어진다. 그 결과, 루핑은 조건부 점검, 명령 블럭 설정으로 분해되어 엔진에 리턴한다. 이는 브랜칭 명령이 주요 구별을 갖는 상이한 어드레스에 실행을 이동시키는 MSIL과 유사하다. 점핑 전에, 규칙은 비선취권 스케줄링(non-preemptive scheduling)이 달성될 수 있도록 엔진에 항상 리턴한다. 조건이 보장되면 엔진이 작업에 즉시 리턴할 수 있는 것처럼, 엔진에 대한 리턴은 작업이 스위치 아웃될 수 있음을 반드시 의미하는 것은 아니다.

루핑 구성체는 구성 블럭의 말단에서 조건을 점검하여 모든 루핑 구성체가 동일 번역을 모두 공유하도록 MSIL과 유사한 방식으로 매핑된다. 이는 WHILE 루프는 루프 이전의 명령이 초기 브랜치를 블럭의 말단으로 하여 조건이 초기 엔트리 시에 점검되는 것을 의미한다.

RDL 언어는 많은 규칙 중에서 멀티태스킹을 고유하게 지원하도록 설계되어 있다. 따라서, 번역 코드는 규칙 엔진이 한정된 개수의 스레드를 갖는 다수의 규칙 중에서 스위칭할 수 있게 구성되어 결과적인 아키텍처는 기본적으로 비선취권 스케줄링 시스템으로 요약된다.

스케줄링

스케줄링 솔루션의 기본을 설명하기 전에, 문제의 명확한 설명을 확인한다. 다수의 규칙을 포함하는 규칙을 고려하면, CheckCDiskSpace, CheckCounter, 및 CreateEvent와 같은 세개의 규칙이 문서 내에 있다. 또한, 간이함을 위해서, 규칙 엔진은 일련의 작업 가운데 멀티태스킹을 위한 단일 스레드만을 사용하도록 구성된다. (CheckCDiskSpace는 스타트업 규칙으로서 이를 표시하는 속성을 포함하며 이는 유사하게 표시된 다른 규칙과 병행하여 실행되어야 한다.) 개념적으로, 규칙 엔진은 컴파일된 어셈블리를 처리하고 병렬로 처리되어야 하는 모든 규칙, 예를 들어, 후술하는 CheckCDiskSpace의 리스트를 구성한다.

그 후, 각 규칙은 규칙 엔진 스레드에 의한 소모용 작업 실행 큐에 있다. 아래 나타낸 경우에서, CheckCDiskSpace는 초기 실행 큐에 있다. 시간 상 일부 지점에서, 스레드는 규칙을 대기행렬방출(dequeue)하고 CheckCDiskSpace의 실행을 개시한다. 시간 상 어떤 추후 지점에서, 스레드는 CheckCounter를 마주친다. 스레드는 나타낸 바와 같이 동기적으로 함수를 호출하여 이러한 내부 함수를 호출하여, 번역 프로그램 언어 코드(예를 들어, C#)가 아래 RDL 샘플에 거의 정확하게 나타낼 수 있음을 의미한다.

그러나, 이러한 응답은 규칙 엔진에 대한 이슈를 생성한다. 규칙은 "While-Sleep(time)-End While" 형태의 연속 루프를 포함한다는 점과 스레드가 이러한 루프에 입력한다고 가정하자. 이러한 유형의 구성체를 만나는 경우, 스레드는 리턴할 수 없는 상황에 입력하고, 이에 따라, 다른 작업에 스케줄링되지 않는다. 수신자는 계산을 행하는 과도한 시간양을 소비하는 경우에 덜 심각한 편이가 발생한다. 그 원인 무엇이 되든지, 최종 결과는 작업 결어(task starvation)이다. 번역 코드는 스레드가 공정한 처리를 위한 작업들 사이에 스케줄링될 수 있도록 작업 스위칭을 용이하게 하여야 한다. 따라서, 번역된 코드는 함수 실행 상태가 저장되어(인수, 로컬 변수 및 현재 명령) 추후 재구성될 수 있도록 협업적 멀티태스킹을 용이하게 한다.

작업 스위칭

협업 멀티태스킹 시스템은 다른 작업이 실행될 수 있도록 스케줄 작업이 스레드의 제어를 포기하도록 요구한다. RDL 코드의 번역이 제어되기 때문에, 각 작업이 제어를 포기할 수 있는지에 대한 판정이 행해진다. 작업은 현재 실행 함수에서 정상 방식으로 단지 리턴하여 제어를 포기한다. 그러나, 리턴 전에, 각 작업은 파라미터, 로컬 변수 및 재입력 시에 함수 내에 점프하는 곳에 대한 정보를 포함하는 스택 프레임을 갱신할 수 있다(스택 프레임 상의 세부사항을 이하 나타낸다). 작업 스위치가 함수 리턴을 포함하기 때문에, 시스템 스택이 풀리지 않고(unwound) 상실된다. 그 결과, 시스템 스택은 규칙 간의 함수 호출이 수신자 함수 엔트리 전에 런타임으로의 리턴을 포함하도록 하는 것의 깊이에 제한될 수 있다. 함수가 런타임으로 리턴되는 경우, 두 실행 경로 중 하나가 발생할 수 있다. 런타임이 수신자 함수에 진입하여 동일 스레드 상의 실행을 개시하거나 작업 스택 프레임이 동작 항목 큐 상에 푸시되기 때문에, 작업 스위치를 야기한다.

스택 프레임

규칙 간의 작업 스위칭을 용이하게 하기 위해서, RDL 코드는 결과적인 코드가 호출 프레임을 구성하는 명령을 포함하도록 번역된다. 이들 프레임은 함수 파라미터, 현재 명령 블럭, 현재 함수, 및 로컬 변수를 포함한다. 함수가 호출되는 경우, 이들 프레임은 구성 및 연결되어 호출 스택을 포함한다. 이러한 호출 스택의 유지는 계산 상태에서 명령을 분리하여 함수가 무상태로 되고 작업 스위칭을 용이하게 한다.

RuleFrame 구조는 함수 특정 프레임 구조가 생성되는 기본 구조로서 동작한 다. RuleFrame 구조는 호출 함수가 수신자 함수를 호출할 때마다 생성되고 채워지며 다음 특성을 갖는다: m_RuleDelegate는 이 프레임의 함수에 대한 델리게이트; m_InstructionBlock은 현재(또는 다음 실행) 실행하는 명령 블럭; m_Mode는 함수가 호출(동기 또는 비동기)되어야 하는 방식; m_RetVal은 함수의 리턴값; m_LocalFrame은 함수에 대한 로컬 변수를 포함; 및 m_ParentFrame은 이 프레임의 호출자 함수.

모든 함수는 RuleFrame 구조에서 유도하는 커스텀화된 프레임을 갖는다. 다음은 상기 CheckCounter 함수에 대한 프레임이 어떠한 것인지를 나타낸다:

각 호출자는 모든 수신자 호출 프레임 구조를 인식한다. 로컬 프레임 구조는 또한 그것이 적용하는 함수에 고유하다. 다음은 CheckCDiskSpace 함수에 대한 로컬 프레임을 나타낸다.

상술한 바와 같이, RDL은 폴링을 통해 주기적 기반으로 호출되는 규칙을 갖는 성능을 지원한다. 폴링된 규칙은 광범위하게 사용될 것으로 예상되며, 그 결과, 수천개의 규칙이 있을 수 있다. RDL 코드 부분은 후술하는 통상의 폴링된 규칙을 나타낸다.

상기 규칙은 규칙 엔진에 의해 호출되고, 계산은 규칙 내에서 수행된 후 다음 호출 전에 30분 동안 논리적으로 슬리프한다. 규칙 엔진은 가능하게는 이들 수천개의 규칙 유형을 지원하면서 중앙 프로세서 활용을 최소화하는 것이 필요하다. 따라서, 엔진은 폴링된 규칙의 호출을 스케줄링하여 확산하는 알고리즘을 구현한다. 탈동기화(de-synchronizing) 폴링 규칙의 문제는 다수의 규칙이 활성화될 것으로 예측되는 스타트업 동안 가장 민감하다. 폴이 시간 내에 확산되지 않으면, 프로세서 활용은 작업 그룹이 만기가 될 때마다 주기적으로 스파이크할 수 있다. 폴링 간격이 짧아질 수록 이 이슈는 보다 민감하게 된다.

현재, 엔진은 1초의 세분성으로 폴링 간격을 지원하게 된다. 프로세서 활용을 낮게 유지하기 위해서, 작업 활용이 대략 5퍼센트가 되게 하는 시간 간격으로 작업이 인위적으로 분리된다. 간격의 크기는 작업의 프로세서 집약 계산이 간격의 기껏해야 5퍼센트를 차지하여야 하도록 설정된다. 예를 들면, 평균으로 작업이 1㎓ 프로세서의 단일 프로세서 머신 상에서 프로세서 타임의 3밀리초를 요구한다고 가정하자. 작업 확산 간격은 활용을 5퍼센트에 유지하기 위해서 약 60밀리초이어 야 할 수 있다. 이는 활용이 5퍼센트 이상으로 상승하기 전에 1초의 폴 동안 총 16개의 규칙만을 지원할 수 있음을 의미한다.

상기 예를 다시 참조하면, 폴링된 규칙은 (상기와 같이 스타트업이 아닌)임의의 시간에서 초기화될 수 있다. 그 결과, 어떤 코드의 분석이 없으면, 엔진은 폴링 요청이 언제 행해질 수 있는 지를 인식하지 못한다. 예를 들면, 천 개의 30초 폴링 규칙은 동시에 모두 하나의 폴을 요구하거나 또는, 요청들이 규칙의 기재 방식에 따라 20분에 걸쳐 확산될 수 있다. 폴 요청이 20분 기간 동안 균일하게 도달하는 경우에도, 엔진이 다수의 규칙이 주기적인 방식으로 동시에 호출되는 상태가 되지 않을 수 있으므로, 매 30초 마다 활용 시에 다루기 힘든 스파이크를 야기한다.

이러한 가능성을 최소화하기 위해서, 엔진은 다음 문제 발견(heuristic)을 사용하여 동기화된 규칙 호출을 최소화한다. 엔진은 일부 임의의 절대 시간으로부터 시간의 고정된 증분으로 모든 작업을 스케줄링한다. 스케줄 확산은 규칙이 스케줄 함수를 명시적으로 호출하는 경우에 발생한다

firstInvocation이 참이면, 스프레딩 알고리즘이 적용된다. 다르게는, 규칙은 규정된 간격에 있어서 즉시 스케줄링된다. 제1 호출은 다음과 같이 스케줄링된다:

여기서, m_MinSpread는 작업들 간의 최소 스케줄링이고 런타임 동안 고정(수십밀리초의 차수); m_ReferenceTime은 모든 폴이 기초하는 고정 시간(규칙 엔진은 스타트업시에 이러한 값을 설정); 및 m_DefaultInterval은 폴링된 호출을 확산하는 시간 간격(이는 수 분의 차수이고, 초기 호출에서 부당한 지연을 야기하지 않고 수천개의 폴을 확산하기에 충분히 커야 한다).

계산은 해당 폴링 주기 동안 일련의 개별 타임 슬롯에 대하여 폴링 호출을 확산시킨다. 폴링 간격이 매우 크면, 스타트업 간격에서 부당한 지연을 방지하기 위해서 호출은 보다 작게 충분히 큰 간격에서 확산된다. 작은 폴링 간격이 이들의 각 주기동안 균일하게 확산되지 않으면, 동상으로 발생하는 것과 동일한 폴링 간격으로 클러스터링 효과가 규칙 사이에서 발생할 수 있다.

초기 규칙 스타트업

스타트업 동안, 규칙 엔진은 반사를 사용하고, 스타트업 속성으로 표시된 규칙에 따라 동작하는 작업 리스트를 구축한다. 작업 리스트가 구축되면, 엔진은 그 스케줄링 함수를 사용하여 모든 규칙의 개시를 확산한다. 규칙은 각 배치(batch)가 시간 구성의 시간 간격(즉, 상술한 m_DefaultInterval) 내에서 스케줄링되도록 일련의 배치 내에서 스타트 업될 수 있다. 이 기준 간격은 구성가능하고 컴퓨터 내에 사용되는 프로세서의 개수에 의존할 수 있다 - 프로세서가 많을 수록, 간격이 보다 작아진다.

비동기 함수 호출

많은 분석자가 규칙 엔진에 의해 직접 유도된다. 이들 분석자는 규칙에 의해 생성되고, 규칙에 의한 데이터가 입력되며, 그 후, 계산 결과에 대하여 조회된다. 통상의 사이클은 다음과 같이 발생한다. 분석자는 상승 기울기에 같이 생성되고 초기화된다. 폴링 기반 상에서, 운영 체계는 성능 카운터가 조회되어 이 데이터를 분석자에게 전달한다. 그 후, 분석자는 계산을 완료하는데 충분한 데이터를 갖는지를 문의한다. 그러한 경우, 이 결과가 획득되어 처리된다. 그러지 않는 경우, 다음 폴이 대기되어 사이클은 새롭게 개시된다. 다음 RDL 단편은 이 사이클을 나타낸다.

이 사이클은 분석자의 일부와 완전히 동기이며 엔진 또는 분석자에 어떤 큐도 요구하지 않는다.

다른 대안은 분석자를 비동기로 하여 데이터가 이용가능할 때 이를 엔진에 통지하는 것이다. 엔진은 그 후 통지 시에 데이터를 검색하여 이를 처리한다. 다음 코드는 이 아이디어를 나타낸다.

이 패턴은 엔진이 비동기 방식으로 GetSlope를 호출하도록 요구하기 때문에 스레드가 블럭되지 않는다. 이 패턴에서, GetSlope는 호출을 상호관련시키는 결과 객체를 사용하여 두 단계로 나뉘어진다. 제1 단계는 엔진이 호출 프레임과 함께 콜백 함수를 통과하여 리턴으로 비동기 문맥 객체를 수신하는 Begin 연산 메소드를 포함한다. 시간 상 어떤 지점에서, 분석자는 콜백을 호출하여 비동기 객체를 공급한다. 엔진은 비동기 객체로부터 이 문백을 획득하고 스레드 풀(thread pool)을 사용하여 실행을 위한 규칙을 스케줄링한다. 규칙이 실행될 때, 이는 분석자 종료 연산을 호출하고, 비동기 객체를 통과하며, 호출 결과를 수신하여 이들 결과를 처리한다.

분석자는 이 시나리오에서 계속 동작하기 때문에 처리되고 있으면서 보다 많은 결과를 생성할 수 있다. 이 경우, 분석자는 규칙에서 큐를 유지하여 Begin Get 요청을 대기할 수 있다. 많은 경우, 엔진이 통상 분석자에 입력하기 때문에 이러한 유형의 모델은 필요하지 않다. 이에 대한 하나의 예외는 엔진과 독립적으로 데이터를 수신한다는 점이다.

모델 기반 관리 아키텍처

도 5를 이하 참조하면, 본 발명에 따라 규칙 엔진을 사용하는 모델 기반 관리 아키텍처(500)가 도시되어 있다. 모델 기반 관리 방식은 개발자가 애플리케이션 또는 서비스(502)를 그 구성요소로 그리고 바람직한 상태를 기능, 구성, 보안 및 성능 등으로 나타낼 수 있게 한다. 따라서, 애플리케이션 또는 서비스 설명(504)은 애플리케이션 서비스(502)를 모델 컴포넌트(506), 목록(manifest) 컴포넌트(508), 시스템 컴포넌트(510), 및 작업 컴포넌트(512)를 적어도 포함하는 하나 이상의 관리가능 컴포넌트로 용이하게 나타낸다. 모델 기반 관리 시스템(500)은 속성 컴포넌트(514)를 사용하여 모델 컴포넌트(506)에서 목록 컴포넌트(508)로의 소스 코드의 속성을 용이하게 한다.

컴퓨터 시스템(516)은 애플리케이션(502)의 설치에서 애플리케이션 또는 서비스 설명(504)을 사용하여 컴퓨터 운영 체계에 관련된 관리 서비스(518)를 구성한다. 그 후, 관리 서비스(518)는 구성 관리, 문제 검출, 진단 및 복구 등의 자동 관리 동작을 통해 애플리케이션 또는 서비스(502)의 이용가능성을 보장할 수 있게 한다. 모델(506)은 또한 관리자가 수행할 수 있는 공통 작업을 나타낸다. 모델 기반 관리 아키텍처(500)는 보다 적은 총비용의 소유를 가능하게 하며, 개발에서, 배치, 동작 및 비즈니즈 분석까지 애플리케이션 생명 주기에 걸쳐 사용된다. 통상, 개발자는 애플리케이션이 동작하는 방식, 그 구성 요소 개발자가 정의하여 모니터링하도록 선택한 바람직한 헬스(health) 상태, 적어도 설치 방식과 애플리케이션 또는 서비스의 요청 설정사항에 대한 구성 양태, 및 관리 작업 및 그 스케줄링 으로 서비스의 애플리케이션의 하나 이상의 모델을 생성하여 개시한다. 그 후, 모델의 소스 코드는 목록의 특정 영역에 기여한다(또는 태그된다).

모델은 계측 목록에 모인다. 모델은 텍스트 문서, 스프레드시트 문서, 및 코드, 스크립, 도구를 통해 변형되거나 또는 수동으로 XML 스키마이고 또한 모신 처리 및 머신 판독되는 목록으로 변형되는 형태일 수 있다. 즉, 모델 문서는 보다 인간 판독가능하고 목록은 보다 머신 판독가능하다. 목록은 그 후 시스템 관리를 용이하게 하는데 사용된다.

속성 서브컴포넌트(514)는 소스 코드 속성에 관련된다. 속성은 관련 코드와 함께 관리 정보를 표현하는데 사용된다. 속성이 없는 경우, 두개의 개별 코드가 기재될 필요가 있다 - 하나는 정상 애플리케이션 동작 그리고 나머지 하나는 이를 관리하는 것. 소스 코드 내의 속성은 코드의 어느 부분(프로브로 불림)이 헬스를 결정 및/또는 정정하는데 사용되어야 하는지를 나타낼 뿐만 아니라 모니터링 규칙을 언제 실행할 지를 규정하는데 사용된다. 프로브는 기존 운영 체계 API(애플리케이션 프로그램 인터페이스)를 액세스하는 컴포넌트 또는 동작 애플리케이션 또는 서비스 내에 로딩된 컴포넌트로부터 보여질 수 있다. 두 경우, 개발자는 컴포넌트 내의 유형 중 어느 서브세트가 보여져야 하는지 그리고 이들이 식별되는 방식을 나타내는 속성을 추가한다. 프로브는 관리자 네임스페이스 내에 URI(균일 자원 식별자)를 사용하여 식별된다. 런타임 시에, 프로브는 컴퓨터 상의 모든 프로브의 카탈로그 내에서 식별하고 프로브에 대한 관련 정보를 추적하여 검색된다.

소스 코드 속성은 또한 모니터링 서비스, 예를 들면, 모니터링 규칙으로서 사용되고 스타트업 시에 로딩되며, 주기적으로 폴링되어 이벤트 상에서 동작되어야 하는 속성 함수에 명령을 제공할 수 있다. 이 속성은 계측과 동일 방식으로 목록 내에 자동 처리되어 배치된다. 따라서, 속성은 단지 계측이 아닌 다른 관리 목적을 위한 것이다. 또한, 속성은 관리 작업 및/또는 교정 동작을 지원하는데 사용될 수 있다.

도 6을 이하 참조하면, 모델 기반 관리 아키텍처(500)의 주요 컴포넌트를 나타내는데 관련되는 그림 맵(600)에 도시되어 있다. 아키텍처는 도 7a에서 설명된 모델 컴포넌트(506), 도 7b에서 설명된 목록 컴포넌트(508), 도 7c 및 도 7d에서 설명된 시스템 컴포넌트(510), 및 도 7e에서 설명된 작업 컴포넌트(512)를 포함한다. 속성은 이미 설명하였으며, 명세서에 걸쳐 기재될 것이다.

도 7a를 이하 참조하면, 모델 기반 관리 아키텍처의 모델 컴포넌트(506)에 관련된 블럭이 도시되어 있다. 모델은 애플리케이션, 헬스 상태 및 복구, 구성 설정 및 관리 작업을 생성하는 컴포넌트에 대하여 개발된다.

그 지원으로, 임의의 그리고 모든 시스템의 컴포넌트(및 관게, 의존성과 관련 서비스 역할)를 모델링하는 컴포넌트 모델 서브컴포넌트(700)가 있다. 컴포넌트 모델(700)은 파일, 구성, 애플리케이션이 설치될 수 있는 다양한 방식 등을 나타낸다.

헬스 모델 서브컴포넌트(701)는 애플리케이션 또는 서비스가 실패할 수 있는 다양한 실패 상태 또는 방식을 나타내도록 개발될 수 있다. 헬스 모델(701)은 건강 특징을 자동화되도록 취할 필요가 있는 단계를 나타낸다. 헬스 모델(701)은 적 어도 실패 상태, 상태 검출, 검증, 진단, 시스템 상태의 결정을 나타낸다. 헬스 상태는 완전히 헬스 상태, 완전히 실패, 그리고 임의의 중간 상태, 예를 들어, 성능 열화, 부분적 동작, 고객 성능 일부가 동작하고 서비스의 예측 레벨을 전달하는 애플리케이션 또는 서비스인 것으로 간주되기 위해, 어느 기준이 충족되어야 하는지에 대하여 설명될 수 있다. 또한, 헬스는 기능이 우수하지만 성능이 애플리케이션 또는 서비스가 헬스 상태가 아님을 나타내는 표준을 고려한다.

구성 모델 서브컴포넌트(702)는 시스템 구성을 모델링하는데 관련된다. 구성 모델(702)은 애플리케이션 설정, 사용자 컨트롤, 기준 값, 다양한 제한 등을 나타내는데 사용된다. 관리 작업 모델 서브컴포넌트(703)는 관리 작업을 모델링하는데 관련되고, 헬스 모델(701)로부터 호출될 수 있는 시작, 정지, 사용자 추가, 및 보정 동작 등 사용자가 시스템 상에서 취할 수 있는 동작을 포함한다. 모델(702)은 애플리케이션 또는 서비스를 사용하여 행해질 수 있다. 아키텍처 모델(704)은, 예를 들면, 동일 또는 유사 하드웨어 및 소프트웨어 설정 및 구성, 분산 데이터페이스를 갖는 큰 클라이언트 네트워크에 통상 관련된 분산 환경 및 관련 배치를 나타내는데 사용된다. 따라서, 로컬 애플리케이션은 원격 디스크 어레이 상에 의존할 수 있다. 배치 상에서, 디스크 어레이는 목록의 배치 레벨에서 그리고 URI를 사용하여 인스턴스화될 필요가 있다. URI가 머신 독립이기 때문에, 분산 시스템은 또한 모델 기반 관리 시스템의 이점을 획득할 수 있다. 성능 모델(705)은 개발자가 애플리케이션 또는 서비스의 성능을 모니터링하기 위한 메트릭을 사용하기 원하는 방식을 나타내도록 개발될 수 있다. 이는 시스템의 헬스에 밀접하게 관련된다. 애플리케이션 또는 서비스에 관련된 보안 유형을 나타내는 보안 모델(706)이 생성될 수 있다.

여기서 제공되는 모델의 수는 단지 예시이며, 개발자는 애플리케이션 또는 서비스의 다양한 양태를 관리하는 다수의 상이한 모델을 제공할 수 있다.

본 모델 기반 시스템은 다양한 양태를 실행하는 다양한 인공 지능 기반 방식을 사용할 수 있다. 예를 들면, 모델에 있어서, 어느 모델이 해당 인스턴스 또는 구현에 대하여 사용될 수 있는지를 판정하는 처리는 자동 분류 시스템 및 처리를 통해 용이하게 될 수 있다. 더욱이, 이러한 분류자는 시스템 패턴을 검출하기 시작하고 양호한 상태, 열약한 상태 및 연속 및 비연속 트랜잭션이 무엇인지를 학습하는 시스템의 동작 프로파일을 구축하는데 사용될 수 있다. 그 후, 이정보는 대응 모델에 입력되어 팔로우 온 시스템(follow-on system)에 대한 갱신 모델로서 사용될 수 있다. 이러한 분류는 확률 및/또는 통계 기반 분석(예를 들면, 분석 유틸리티 및 비용으로 분해)을 사용하여 사용자가 자동으로 수행되기를 원하는 동작을 진단 또는 유추할 수 있다. 예를 들면, 지지 벡터 머신(SVM) 분류자가 사용될 수 있다. 다른 분류 방식은 베이지안 네트워크(Bayesian network), 결정 트리를 포함하며, 상이한 독립 패턴을 제공하는 확률 분류 모델이 사용될 수 있다. 또한, 여기서 사용되는 분류는 우선 모델의 개발하는데 사용되는 통계 회구를 포함한다.

본 명세서에서 용이하게 이해될 수 있는 바와 같이, 모델 기반 시스템은 명시적으로 트레이닝(예를 들어, 일반 트레이닝 데이터를 통해)될 뿐만 아니라 묵시적으로 트레이닝(예를 들어, 사용자 동작 관측, 외부 정보 수신을 통해)되는 분류 자를 사용할 수 있어 분류자(들)가 소정의 기준, 예를 들면, 해당 구현에 대하여 사용하는 초기 설정이 무엇인지를 결정하고, 그 후, 시스템이 성숙함에 따라 시간 경과에 따라 설정을 조정하고 데이터, 설치된 애플리케이션의 수, 및 상호동작하는 노드의 개수에 대한 여러 로딩 조건을 경험하는데 사용된다. 예를 들면, 공지된 SVM에 있어서, SVM은 분류자 구성체 및 특징 선택 모듈 내의 학습 또는 트레이닝 단계를 통해 구성된다. 분류자는 입력 속성 벡터, x=(x1, x2, x3, x4, xn)을 입력이 클래스에 속한다는 신뢰성, 즉, f(x)=confidence(class)인 신뢰성에 매핑하는 함수가다. 관리 시스템의 경우, 예를 들면, 속성은 바람직한 상태의 시스템 파라미터이며, 클래스는 관심 영역의 카테고리이다(예를 들어, 모든 드라이브, 모든 네이티브 처리). 또한, 분류자는 트랜잭션 로그를 캡처 및 분석하고, 패턴을 관측하며, 성공 및 실패 패턴을 관측하여 시스템을 진단하는데 사용될 수 있다.

구성 헬스는, 예를 들면, 5에서 10으로 큐 크기를 변경하고, 변경이 애플리케이션, 서비스 또는 시스템에 가할 수 있는 영향을 무엇인지를 결정하는 것을 포함한다. 이는 또한 보안 및 성능에 적용하며, 여기서, 분류자는 성능 카운터를 모니터링하여 시스템이 이에 따라 변경하여 성능을 최적화하는데 사용될 수 있다. 보안은 또한 패턴에 대하여 모니터링 및 분석될 수 있으며, 그 영향은 보안 정책을 제안 또는 변경하는데 사용될 수 있다. 따라서, 헬스는 시스템의 많은 영역에 적용될 수 있는 넓은 개념임이 이해될 것이다. 전 시스템에 대하여, 성능은 양호하지만 보안은 열악할 수 있다. 따라서, 시스템의 다수의 원칙에 걸친 전체적인 관점이 유리하다.

관리자의 바람직한 상태가 코드로 표현될 수 있으며, 이는 목록 내의 표면화되어(surfaced) 모니터링 서비스에 의한 모니터링을 위해 전달된다. 목록 내의 명령에 기초하여 시스템은 애플리케이션 또는 서비스를 모니터링하고, 관리자에게 애플리케이션 또는 서비스가 성능을 충족하는지를 알리고, 이 명령에 따라 교정 동작을 취할 수 있다. 예를 들면, 이메일에 대한 테스트 설정이 유지되지 않고, 기간 동안 임계치 아래로 떨어지는 경우, 다른 머신이 부하가 가라앉을 때까지 추가될 수 있으며 네트워크 트래픽은 또한 리소스 개수를 증가시켜 해당 부하를 처리하는 트리거로서 사용될 수 있다. 목적은 가능한 한 많이 자동화되어 관리자는 수동 동작이 필요한 경우에만 관여하게 된다.

모델 기반 관리 시스템은 조립가능하다(composable). 대부분 무엇이든 포함하는 컴포넌트를 갖는 컴포넌트 기반이다. 따라서, 시스템은 최저 관리가능 부분으로 감소되어 백업 제작될 수 있다. 데이터베이스에서, 예를 들면, 인스턴스, 데이터베이스, 테이블 및 저장된 프로시저를 갖는 애플리케이션이 있으며, 단일 파일 만큼 적에 축소될 수 있다. 401k 애플리케이션을 고려하자. 401k 애플리케이션은 데이터베이스, 웹 서버, 및 고객 자신의 비즈니즈 로직에서 관련 운영 체계에 따른 데이터베이스까지 의존할 수 있다. 다양한 레벨에서 관리 및 보고하는 것이 바람직하다. 컴포넌트 간의 관계를 통해 애플리케이션을 설명한다. 이들 관계는 개별 애플리케이션이 조립되는 방식(예를 들어, SQL 서버는 서비스, 인스턴스, 및 데이터베이스를 포함), 플랫폼 요건(예를 들면, 운영 체계 및 다른 애플리케이션), 및 다른 컴포넌트로의 통신(SQL 서버에 접속하는 웹 서버)을 표현한다. 단일 관리자 는 데이터베이스와 단일 머신에 대하여 관심을 가질 수 있지만, 재정 관리자는 401k 애플리케이션에 관심을 가질 수 있으며, CIO는 모든 애플리케이션과 머신에 대하여 관심을 갖는다. 모델, 보고 및 요구 상태는 시스템이 예측된 것을 행하는지를 판정하는 것을 개별 메트릭이 참조할 수 있도록 모든 것을 처리해야 한다.

모든 모델은 URI 네임스페이스에 결합되어, 시스템 네비게이션의 표준 방식을 제공하고, 설치된 모든 컴포넌트를 열거하며, 제공하고, 헬스로 간주되며, 구비한 이벤트가 무엇이며, 마지막 일 또는 시간에 발생한 컴포넌트, 포함된 구성 설정, 마지막 시간에 발생된 변경이 무엇인지를 문의한다.

도 7b를 이하 참조하면, 모델 기반 관리 아키텍처의 목록 컴포넌트(508)에 관련된 블럭이 도시되어 있다. 애플리케이션을 사용하여 실린 목록은 모델로부터의 정보와 관리 시스템 서비스에 의해 사용되는 머신 판독가능 형태의 소스 코드 속성을 포함한다. 애플리케이션에 대한 관리 작업은 목록 내에 한정된다. 다음을 포함하는 모델에 대응하여 다수의 목록이 생성될 수 있다: 컴포넌트 의존성, 컴포넌트 간의 관계 및 서비스 역할에 관련된 제1 목록 서브컴포넌트(707); 이벤트, 프로브, 규칙 및 동작에 관련된 제2 목록 서브컴포넌트(708); 설정 및 단정(assertion)에 관련된 제3 목록 서브컴포넌트(709); 명령(즉, 씨엠디리트(cmdlet)) 및 관리 역할에 관련된 제4 목록 서브컴포넌트(710); 분산 환경에 관련된 제5 목록 서브컴포넌트(711); 및 배치에 관련된 제6 목록 서브컴포넌트(712).

목록은 개발자, 운영 팀 및 관리자 간의 "브리지"이며, 속성 코드에 대한 모델을 스위프(sweep)하는 도구를 사용하여 자동 생성된다. 컴포넌트 목록(707)은 애플리케이션 또는 서비스의 설치 방식을 결정하는데 설정 엔진에 의해 사용된다. 이는 논리 컴포넌트, 파일, 파일이 설치되어야 하는 장소, 및 구성 설정(또는 임의의 설정)을 나타낸다. 의존성은 설치 전에 한정될 필요가 있는 것이며, 다양한 역할을 포함하기 때문에, 애플리케이션은 상이한 모드로 설치될 수 있으며, 다양한 보안 정도와 상이한 동작 프로파일을 갖는다. 컴포넌트 목록(707)은 사용자와 시스템이 수동 및 자동으로 무엇을 행하는지를 보다 용이하게 인식하게 한다. 목록 세분성은 컴포넌트마다 하나의 목록으로 감축될 수 있다.

통상, 실제 필요한 것보다 많은 파일이 설치된다. 목록은 필요한 파일 만을 설치할 수 있게 한다. 이는 적어도 성능 및 보안을 개선시킨다. 소프트웨어 의존성은 목록(707)에 한정된다. 애플리케이션 레벨에서, 의존성은 단일 머신에 특정할 수 있으며 컴포넌트 관계 및 하드웨어 자원을 한정할 수 있다. 컴퓨터는 목록에 의해 설명될 수 있으며, 예를 들면, 애플리케이션이 특정 제조사의 듀얼 프로세서 머신 또는 4-프로세서 머신에 대한 인터페이스 상에 배치되어야 한다. 이 목록(707)은 구현에 필요한 하드웨어 세분성 레벨까지 프로세서, 메모리, 드라이브 등을 나타낸다. 따라서, 관리는 종래 시스템에서와 같이 반응적이기 보다 혁신적이다. 하드 디스크 고장은 열 고장에 의해 야기되도록 결정, 예를 들면, 시스템 온도가 시간 경과에 따라 모니터링되고 전원 레일 전압이 모니터링되지만, 충분한 것으로 판단될 수 있다.

헬스 모델(701)은 헬스 목록(708)을 생성(spawn)하는데 사용된다. 헬스 목록(708)은 속성 및 다른 도구를 사용하여 헬스 모델(701)로부터 채워진다. 이벤트 는 모델(701)에서 호출되지 않고 자원 파일에서 호출된다. 도구는 자원 파일 및 속성 소스 코드를 스위프하고 헬스 목록(708)을 채운다. 고장 상태는 이벤트의 소정 시퀀스를 감시하거나 성능 카운터 임계치를 모니터링함으로써 검출될 수 있다. 명령은 이러한 고장 상태를 해결하는 방식에 대하여 시스템에 제공될 수 있다. 헬스 모델은 규칙으로 변형된다. 헬스 목록(708)은 이벤트1, 이벤트2, 타임3 등과 같은 파라미터를 갖는 규칙 유형 이벤트 시퀀스를 포함한다.

구성 모델(702)은 어떤 설정이 포함되어는지 그리고 컴포넌트가 설치될 때 시스템이 설정을 생성하는 명령 스키마를 제공하는 설정 및 단정 목록(709)으로 변형된다.

관리 작업 모델(703)은 씨엠디리트 및 관리 역할 목록(710)을 통해 동작으로 변형된다. 예를 들면, 데이터 백업이 필요하면, 씨엠디리트는 백업 작업을 용이하게 하는데 사용되는 실제 코드 또는 URI이다. 수많은 관리 작업이 수행될 필요가 없는 경우, 목록(710)은 URI 경로를 이들 명령과 가능하게는 코드에 제공한다. 씨엠디리트는 코드에 대한 단정을 통해 처리될 수 있거나 외부 코드를 획득할 수 있다. 관리 역할은 다른 요약 지원이며, 예를 들면, 애플리케이션 또는 서비스를 관리하는 다수의 사용자 클래스, 및 그들이 각각 실행할 수 있는 제어 레벨 등이다. 이는 역할 기반 액세스에 관련한다. 메타데이터는 다양한 사용자의 역할과 이들의 허용된 성능을 나타내는데 필요하다. 역할은 시스템의 모든 양태에 걸쳐 있다 - 누가 설치할 수 있는지, 누가 모니터링을 변경할 수 있는지, 누가 헬스를 관측할 수 있는지, 누가 경계를 해결할 수 있는지, 누가 이 다양한 동작을 취할 수 있는지 등.

작업 모델(703)은 목록(710)에서 표현되고 그들의 환경에 대한 운영 팀에 의해 커스텀화된 바와 같이 관리자가 해야 한다고 개발자가 생각하는 것을 한정한다. 이러한 커스텀화는 클래스 레벨 및 인스턴스 레벨에서 행해질 수 있다. 변화는 클래스 레벨과 인스턴스 레벨에서 목록에 행해질 수 있으며, 변화는 런타임 시에 직접 행해질 수 있다. 개시된 모델 기반 관리 아키텍처의 매우 강력한 특징은 성능이 클래스 레벨에서 우선 기재될 수 있지만 런타임 시에 액세스가 인스턴스 공간에 대한 것이라는 점이다.

아키텍처 모델(704)은 분산 컴포넌트 목록(711)과 배치 목록(7123)을 표면화한다. 예를 들면, 머신 간의 네트워크 접속, 하드웨어 요건이 여기에서 커버된다. 배치 목록(712)은 적어도 웹서버, 미들 계층 서버, 및 데이터베이스 서버를 포함하는 애플리케이션을 지원하고 프론트엔드/백엔드 애플리케이션, 두 애플리케이션 간의 네트워크 접속을 포함하고, 개별 노드 간의 관계를 나타낸다. 배치 시간은 전반적인 아키텍처 모델(704)에 기재된 인스턴스를 생성한다.

성능 및 보안 모델(705 및 706)은 각각 이들 관련 함수 및 동작을 나타내는 대응 목록(미도시)을 지원한다.

머신 기반 학습의 사용에 복귀하면, 분류자는 예를 들면 제1 배치 동안 요건에 따라 모델 코드의 선택된 부분의 목록을 선택하여 동적으로 생성하는데 사용될 수 있다. 기본 모델은 다소의 속성을 사용하여 자동 생성될 수 있다. 시간 상, 시스템 동작 정보가 이용가능하게 됨에 따라, 이러한 정보는 목록의 세분성 레벨이 에를 들면 가장 최근의 데이터 트랜드와 로고에 따라 특정 영역의 시스템을 보다 가까이 모니터링하도록 조절될 수 있게 분석될 수 있다. 갱신된 목록은 그 후 애플리케이션 또는 서비스를 보다 가까이 모니터링할 필요가 있음에 따라 재생성 및 사용된다.

목록이 기준 설치를 설명하거나 제작사로부터 최선의 실시를 추적하는 경우, 관리자는 변경하기를 원할 수 있다. 예를 들면, 헬스 규칙에 있어서, 관리자는 30에서 40으로 임계치를 변경하거나, 컴포넌트를 설치하거나 보안 정책을 취소시키려 할 수 있다. 이는 목록의 커스컴화된 버전을 생성하여 제작사에 의해 제공된 목록을 취소함으로서 행해질 수 있다. 상이한 버전이 설치 동안 검출될 수 있어, 사용자가 기준 목록 또는 커스텀 목록을 선택을 가능하게 한다. 다르게는, 시스템이 취소할 리스트를 판독하는 개별 파일이 있을 수 있으며, 그 후, 기준 설정이 취소되도록 설치 동안 또는 사용자에 의해 기준 목록에 적용될 선택이 디스플레이 된다.

분산 애플리케이션에 있어서, 관리자는 그 또는 그녀가 이들 중 3개, 이것에서 4개, 저것에서 4개를 이 구성에서 모두 유선으로 원한다고 보다 일반적으로 규정할 수 있다. 관리자는 해당 환경에 대한 배치 목록(712)을 이에 따라 커스텀화할 수 있다.

도 7c를 참조하면, 모델 기반 관리 아키텍처에 따라 애플리케이션 또는 서비스를 관리하는데 사용되는 시스템 컴포넌트(510)의 코어 시스템 API의 블럭도가 도시되어 있다. 시스템 컴포넌트(510)는 관리될 애플리케이션 또는 서비스(714)를 포함한다. 시스템(510)은 모델 기반 관리를 용이하게 하는 협업적 통신에서 다수의 API를 포함한다. 시스템(510)은 애플리케이션(도 7b에서 설명) 내의 정보에 의해 구성되는 다수의 서비스로 이루어진다.

시스템(510)은 애플리케이션의 이용가능성을 보장하는데 필요한 서비스로 이루어지고 목록 컴포넌트(508)에서 표현되고 다음을 수행하기 위해 관리자에 의해 변형되는 바람직한 상태를 사용한다: 의존성을 검증하고 단지 필요 파일, 설정, 및 보안을 설치하는 설치; 이벤트에 기입하여 규정된 바와 같이 진행하는 이벤트 가입; 계측 및 카운터를 주기적으로 수집하는 폴링된 계측; 및 합성 트랜잭션 또는 시뮬레이팅 사용자 트랜잭션. 애플리케이션이 이용가능한지를 판정하는 최선의 방식 중 하나와 예측된 것(바람직한 상태)과 같은 수행은 사용자인 것처럼 모니터링 시스템이 애플리케이션을 사용하는 것이다. 이는 액티브 모니터링이다. 가능한 두번째 방식은 실제 사용자 트랜잭션을 액티브 모니터링하고 전체 데이터를 분석을 위해 시스템에까지 보고하는 것이다. 이들 단계는 루프를 닫고 내부 애플리케이션 데이터가 충분하지 않음을 나타낸다. 모델 기반 관리는 또한 애플리케이션 외부에서 동작한다.

시스템(510)은 목록 컴포넌트(508)에서 표현된 바람직한 상태를 사용하여 자동 작업 관리에 대한 작업 스케줄링을 또한 사용한다; 액세스를 프로그램 함수에 제한하지 않은 규칙 기반 액세스; 문제점을 검출하고, 근본 원인을 진단하여 교정 동작을 취하는 모니터링; 및 중재가 필요한 경우 시스템 관리자에 게 통지; 및 상술한 정책을 커스텀화하여 많은 머신에 적용하는 중심 구성.

애플리케이션(714)과 통신하여 설치 애플리케이션의 설치, 애플리케이션 갱신 및 패치를 용이하게 하는 설치 API(716)가 제공된다. 설치 API(716)는 코드를 통해 목록 어셈블리를 취하고, 시스템에 이 컴포넌트, 이 목록, 및 이 버전을 머신 상에서 설치하도록 지시함으로써 어셈블리를 인스턴스화한다. 설치 API(716)는 프로토콜(718)과 뷰어(720)에 관련된다. 프로토콜(718)은 컴포넌트 API관련 데이터를 시스템(510)의 다른 컴포넌트와의 통신을 용이하게 한다. 뷰어(720)는 설치 API(716)에 관련된 데이터를 디스플레이한다. 설치 API(716)는 단일 머신 상의 설치뿐만 아니라, 로컬 및 원격 시스템을 포함하는 분산 애플리케이션 또는 서비스와 하드웨어 준비 및 요약을 용이하게 한다. 분산 데이터 중심 환경에서, 하드웨어 시스템을 전반적으로 보다 세밀한 세분성으로 특정 머신 요약에 대하여 요약하는 것이 중요하다. API에 대하여 여기서 고찰된 프로토콜은 API 관련 데이터의 송신 및 수신을 관리하는 규칙이다. 이 설명에서 이해되는 바와 같이, 뷰어(720)는 API, 여기서는 설치 API(716)에 관련된 데이터를 디스플레이하는 프로그램이다. API 데이터는 사운드 파일, 비디오 파일, 예를 들면, 다른 유형의 데이터 파일을 포함하지만 이에 국한되는 것은 아니다.

시스템(510)은 애플리케이션(714)과 통신하여 애플리케이션(714)의 구성을 용이하게 하는 구성 API(722)를 포함한다. 구성 API(722)는 스키마(723), 프로토콜(724), 및 뷰어(726)에 관련된다. 스키마(723)는 API(722)와 애플리케이션(714) 사이에 전달되는 데이터의 구조 및 내용을 한정한다. 프로토콜(724)은 AP 관련 데이터의 시스템(510)의 다른 컴포넌트와의 통신을 용이하게 한다. 뷰어(726)는 구 성 API(722) 관련 데이터를 디스플레이한다.

또한, 분산 환경에서 다대일(many-to-one) 관리를 용이하게 하는 관리 API(728)가 포함된다. API(728)는 관리 애플리케이션(714)과 또한 원격 시스템(미도시)과 통신한다. API(728)는 관련 프로토콜(730)과 뷰어(732)를 갖는다.

시스템(510)은 애플리케이션(514)과 통신하여 애플리케이션(714)을 관리하는데 사용되는 카운터 변수의 추적으로 용이하게 하는 성능 카운터 API(734)를 포함한다. 카운터 API(734)는 프로토콜(736)과 뷰어(738)에 관련된다. 프로토콜(736)은 API 관련 데이터의 시스템(510)의 다른 컴포넌트와의 통신을 용이하게 한다. 뷰어(738)는 카운터 API(734)에 관련된 데이터를 디스플레이한다. 성능 카운터는 애플리케이션(714)에 의해 보여지고 뷰어(738)를 통해 카운터를 알린다.

애플리케이션(714)과 통신하여 계측 구성과 애플리케이션(714)을 이용한 계측 데이터의 전달을 용이하게 하는 계측 API(740)가 제공된다. 계측 API(740)는 계측이 보여지는 프로토콜(742)과 뷰어(744)에 관련된다. 프로토콜(742)은 시스템(510)의 다른 컴포넌트와 API 관련 데이터와의 통신을 용이하게 한다. 뷰어(744)는 계측 API(740)에 관련된 데이터를 디스플레이한다. 계측 API(740)는 IPC(처리간 통신; 746)를 통해 관리 애플리케이션(714)과 통신한다. IPC는 동일 컴퓨터 내에서 또는 네트워크 상으로 하나의 프로그램과 다른 프로그램 간의 데이터의 자동 교환이다. IPC 함수의 일 예는 사용자가 하나의 파일에서 다른 파일로 클립보드를 사용하여 수동으로 오려두기 및 붙이기(cut and paste)하는 경우 수행된다. 카운터는 항상 공유 메모리를 통해 알려지는 반면, 계측은 요구시에 전달된다. 계측 API(740)는 또한 이벤트 스키마와 유사한 방식으로 계측 클래스의 표현을 나타내는 스키마(748)를 포함한다. 또한, 계측 로그(미도시)가 포함되지만; 많은 관리자는 이벤트 로그를 사용하는 것을 선호한다.

시스템(510)은 추적하는 저장소인 카탈로그(747) 및 캐시 컴포넌트와 모드 정보를 포함한다. 이 모드 정보는 설치 시에 목록에서 나오며, 일부는 런타임 시에 동적으로 갱신된다. 카탈로그(747)는 카탈로그 API를 포함하며, 여기에 저장된 몇가지 데이터 유형을 들면, 이벤트, 카운터, 계측 및 구성 데이터에 대한 액세스를 제공한다. 카탈로그(747)에 대한 액세스는 프로토콜(751)과 뷰어(753)에 의해 용이하게 된다. 중심 구성 데이터베이스는 다수의 관리 노드에 걸쳐 모여지거나 집합적인 카탈로그를 포함한다.

시스템(510)은 애플리케이션 또는 서비스(714)와 통신하여 애플리케이션(714)을 매핑할 때 사용되는 이벤트를 구현하고 추적하는 것을 용이하게 하는 이벤트 API(750)를 포함한다. 이벤트 API(750)는 발생한 모든 이벤트에 대한 저장소로서의 역할을 하는 이벤트 로그(752)에 인터페이스한다. 이벤트 API(750)는 프로토콜(754)과 뷰어(756)에 관련된다. 프로토콜(754)은 시스템(510)의 다른 컴포넌트의 API 관련 데이터와의 통신을 용이하게 한다. 뷰어(756)는 이벤트 API(750) 관련 데이터를 디스플레이한다. 애플리케이션(714)과의 통신은 그 사이에 전달되는 데이터의 내용과 구조를 한정하는 이벤트 스키마(758)에 따른다. 이벤트는 상술한 바와 같이 나타내어 발생한다. 스키마는 이벤트의 표면을 나타낸다.

시스템(510)은 애플리케이션(714)과 통신하여 애플리케이션(714)과 상호동작 으로 통상 행해질 수 있는 자동화 절차를 용이하게 하는 자동화 API(760)를 포함한다. 자동화 API(760)는 프로토콜(762)과 쉘(764)에 관련된다. 프로토콜(762)은 시스템(510)의 다른 컴포넌트와 API 관련 데이터와의 통신을 용이하게 한다. 쉘(764)은 사용자 인터페이스에 자동화 API(760)를 제공하여 자동화 처리에 관련된 데이터와 자동화 처리의 사용자 제어를 입력 및 디스플레이하는 사용자 상호동작을 용이하게 한다.

시스템(510)은 애플리케이션(714)과 자동화 API(766)에 통신하여 스케줄링된 작업 API(766)를 더 포함한다. 스케줄링된 작업 API(766)는 적어도 자동화 API(760)와 관리 애플리케이션(714)에 대한 작업 또는 프로그램의 스케줄링을 용이하게 한다. 이는 동작하는 작업 리스트를 유지하며 이에 따라 자원을 할당한다. 스케줄링된 작업 API(766)는 프로토콜(768) 및 뷰어(770)에 관련된다. 프로토콜(768)은 시스템(510)의 다른 컴포넌트와 API 관련 데이터의 통신을 용이하게 한다. 뷰어(770)는 스케줄링된 작업 API(766)에 관련된 데이터를 디스플레이한다. 작업 스키마(722)는 작업 API와 다른 컴포넌트 사이에 전달된 테이터의 내용 및 구조를 한정한다.

자동화 및 작업 데이터는 작업 및 씨엠디리트 모델로부터 수신된다. 이들 특징은 로컬 또는 원격으로 관리 쉘을 통해 자동화될 수 있다. 이 스케줄링 시스템은 이들, 예를 들어, 오전 3시에 백업을 실행할 수 있다.

도 7c에서 설명된 컴포넌트는 로컬 구현의 것을 나타낼 수 있지만, 도 7d의 컴포넌트는 분석이 많은 머신과 소프트웨어 시스템에 걸쳐 발생하도록 분산 구현에 관련된 것을 나타낼 수 있음이 이해될 것이다. 따라서, 분산 구현에서, 도 7d의 컴포넌트는 도 7c의 로컬 시스템 중 적어도 하나, 그러나, 통상 이러한 복수의 로컬 구현과 유선 및/또는 무선 방식으로 통신한다. 로컬 구현에서, 시스템(510)은 또한 로컬 모니터링 서비스 API(765)를 포함하는 도 7d의 임의의 또는 모든 컴포넌트를 포함할 수 있다. 로컬 모니터링 서비스 API(765)는 또한 프로토콜(767), 뷰어(769), 및 스키마(771)를 포함하고, 이들 각각은 이러한 다른 API 컴포넌트와 유사한 기능을 용이하게 한다. 분산 구현에서, 로컬 모니터링 서비스(765)는 그 후 후술하는 바와 같이 분산 모니터링 서비스에 모니터링 정보를 전달한다.

도 7d를 이하 참조하면, 모델 기반 관리 아키텍처의 시스템 컴포넌트(510)의 관리 관련 API의 블럭도가 도시되어 있다. 중심 구성 API(776)를 통해 액세스와 제어가 제공되는 구성 데이터베이스 서브컴포넌트(774)가 제공된다. 중심 구성 API(776)는 시스템(510)의 모든 서브컴포넌트와 인터페이스하며, 통신과 상호동작을 위해 프로토콜(778)과 뷰어(780)에 관련되고, 단정 및 기본값 등의 구성 설정 및 속성 형상을 나타내는 스키마 컴포넌트(782)에 관련된다. 프로토콜(778)은 시스템(510)의 다른 컴포넌트와 API 관련 데이터와의 통신을 용이하게 한다.

또한, 관리 시스템의 동작 관련 데이터, 예를 들어, 보고, 현재 상태 및 역사적 데이터에 대한 리포지토리(repository)로서 동작하는 동작 데이터베이스 서브컴포넌트(783)가 제공된다. 모니터링 API(784)는 동작 데이터베이스(783)과 모델 기반 관리 시스템의 모든 서브컴포넌트에 인터페이스하며, 프로토콜(785), 뷰어(786) 및 스키마(787)에 더 관련된다. 프로토콜(785)은 시스템(510)의 다른 컴포 넌트와 API 관련 데이터와의 통신을 용이하게 한다. 뷰어(786)는 모니터링 API(784)에 관련된 데이터를 디스플레이한다. 스키마(787)는 적어도 구조 내의 각 데이터 요소가 포함할 수 있는 컨텐츠 유형과 구조에 있어서, 전체 동작 데이터베이스(783)에 대한 정의를 제공한다.

중심 구성은 모든 API를 접촉할 수 있으며, 애플리케이션이 어느 머신에 설치되어야 하는 등의 분산 애플리케이션 시나리오에 대한 세부사항을 포함할 수 있는 구성 세부사항을 관리자에 의해 설정하는데 사용된다. 또한, 구성은 모니터링 구성을 포함한다. 예를 들면, 모든 머신은 5분 동안 적어도 80%의 CPU 활용을 나타내야 한다. 따라서, 모니터링 시스템은 구성 시스템을 사용한다. 모니터링은 관리자가 관리 시스템을 통해 애플리케이션이 모델 마다 동작, 구성, 및 설치되게 하는 방식이다. 또한, 예측된 기능, 바람직한 보안 정도를 확보하고 적절하게 수행하며 사용자에 예측가능한 바와 같이 데이터를 전달하는 등을 포함한다. 따라서, 모니터링은 모든 영역에 걸쳐있다. 통상의 처리는 요구 시에 작업을 설치, 구성, 동작하여 이벤트를 소비하고, 계측, 구성을 제공하며 데이터 및 결과를 저장하는 것이다. 헬스 목록은 모니터링 시스템에 대한 명령인 규칙의 형태로 모니터링 시스템에 동작 명령을 제공한다. 통상, 목록은 런타임 명령을 포함하고, 런타임은 바람직한 상태를 구현한다.

모니터링 서비스는 중심 또는 분산 메커니즘 뿐만 아니라 로컬 서비스이다. 분산 구현에서, 헬스는 로컬 머신 뿐만 아니라 로컬 및 원격 머신 간의 관계를 포함한다. 예를 들면, 10개의 머신 클러스터에서, 6개가 적절하게 동작하는 경우, 시스템은 헬스 상태로 간주된다. 그러나, 5개 이하의 머신이 동작하는 경우, 시스템 헬스 상태는 주의 상태로 열화한다. 4개 이하의 머신이 동작하는 경우, 시스템 헬스는 고장 상태로 간주될 수 있다. 하나 이상의 클러스터 머신이 고장 또는 오프라인이 되는 경우 하드웨어 요약 설비는 하나 이상의 백업 시스템 또는 애플리케이션/서비스를 쉽게 온라인이 되도록 한다. 따라서, 휴지 또는 공유 자원의 풀(poll)은 명령에 따라 제어될 수 있다. 이러한 특징은 데이터 중심 환경에서 특히 유용하다. 자동화된 동작은 시스템이 최적 또는 적어도 최소의 기능을 유지하게 보장하도록 구현될 수 있다.

모델 기반 관리 아키텍처의 일 양태는 시스템이 헬스 상태라고 간주되기 위해 충족하여야 하는 기준을 나타내는 다수의 규칙을 개발자가 작성할 수 있게 한다. 모니터링 API(784)는 규칙의 묵시적 병행 처리를 용이하게 하는 규칙 런타임 엔진을 포함한다. 규칙 엔진은 규칙을 중간 형태로서 표현하는 입력 명령을 수신하고, 이 규칙은 규칙 정의 언어(RDL)를 사용하여 표현된다. 또한, 규칙 엔진은 규칙 코드를 인스턴스화하는데 사용되는 구성 데이터베이스(774)로부터 구성 데이터를 수신한다. 번역기는 입력 명령을 판독하고 이들을 병렬 실행 형태로 변형한다. 런타임 엔진은 번역된 명령을 판독하고 병렬 실행을 용이하게 한다. 규칙 코드는 어느 규칙이 동작할 지를 규정하는 런타임 엔진에 구성 데이터뿐만 아니라 규칙을 실행하는데 필요한 파라미터를 로딩함으로써 인스턴스화된다. 규칙 파라미터는 문제가 검출된 경우에만 심각한 시스템 영향을 갖는 규칙을 가능하게 하는 등, 규칙 파라미터가 런타임 시에 변경될 수 있다. 따라서, 규칙은 동적이며 이에 따 라 변경될 수 있는 임계치이다. 또한, 모니터링 API(784)는 시스템(510)의 모든 서브컴포넌트에 접속한다.

관리자에 의해 사용되는 목록 저장 및 편집 서비스(788)가 제공된다. 목록 서비스(788)는 프로토콜(789)과 뷰어(790)에 관련되어 이들 목록 함수를 관리자에게 나타낸다. 목록 서비스(788)는 프로토콜(789)과 뷰어(790)를 통해 관리자에게 목록을 입력하여, 관리자가 목록을 관측 및 변경을 설치 전에 가능하게 한다. 목록 서비스(788)는 또한 갱신 및 커스텀화에 따라 목록의 버전개선(versioning)을 용이하게 한다.

모델 기반 관리 시스템의 모든 서브컴포넌트에 인터페이스하는 규칙 기반 액세스 API(791)가 제공되며, 또한, 프로토콜(792)과 뷰어(793)에 관련된다. 프로토콜(792)은 시스템(510)의 다른 컴포넌트와 API 관련 데이터와의 통신을 용이하게 한다. 뷰어(793)는 규칙 기반 API(791)에 관련된 데이터를 디스플레이한다. 이 API(791)는 상기 레벨에서 다양한 컴포넌트로의 액세스와 모델 기반 관리 시스템의 양태의 전반적인 관리를 제공하는 모니터링 및 구성 컴포넌트가 제공된다. 이들 함수는 시스템(510)의 다른 컴포넌트에 의해 용이하게 될 수 있기 때문에, 규칙 기반 액세스 API(791)는 프로토콜(792)과 뷰어(793)가 필요하지 않다.

또한, 시스템은 머신 기반 학습 및 제어를 위한 분류자(794)를 포함한다. 상술한 바와 같이, 분류자(794)는 몇가지 예를 들면 시스템 및 성능을 향상시키는 많은 방식으로 사용될 수 있다. 머신 기반 학습을 용이하게 하기 위해서, 분류자(794)는 시스템의 모든 컴포넌트가 액세스될 수 있고 그 데이터가 사용될 수 있도 록 중심 구성 서비스(776)와 인터페이스한다.

도 7e를 이하 참조하면, 모델 기반 관리 아키텍처의 작업 컴포넌트(512)의 주요 서브컴포넌트가 도시되어 있다. 작업은 관리 작업 모델을 통해 설명한다. 작업은 3개의 서브컴포넌트에 속하게 된다: 모니터링 서브컴포넌트(795), 장애 해소 서브컴포넌트(796), 및 관리 서브컴포넌트(797).

모니터링 서브컴포넌트(795)에 대한 작업은 헬스, 보안, 패치, 구성, 성능 및 애플리케이션 데이터의 감시를 포함한다. 장애 해소 서브컴포넌트(796)의 작업은 헬스 상태의 진단, 경고 처리, 및 갱신 이벤트, 계측 및 성능 로그를 포함한다. 관리 서브컴포넌트(797)의 작업은 중심 구성/정책, 스케줄링, 및 갱신 배치를 포함한다. 관리는 단일 시스템의 관리뿐만 아니라 예를 들면, 다수의 머신, 애플리케이션, 시스템, 정책, 백업 시간, 변화, 및 갱신을 관리하는 것을 포함한다.

URI는 추상 또는 물리적 자원 또는 자원 모음을 고유하게 식별하기 위해 모델 기반의 관리 아키텍처에서 사용된다. 자원에 대한 스키마는 자원에 대한 위치보유자(placeholder)를 갖는 URI에 의해 식별될 수 있다. 위치보유자를 갖는 URI는 URI 템플릿이라 불린다. 시스템의 카탈로그는 URI 템플릿에 의존하여 특정 인스턴스를 참조하지 않고 계측을 나타낸다. URI 템플릿은 프로브가 식별되고, 이들 특성은 특정 인스턴스에 대하여 프로브를 실제 검색하지 않고 이해될 수 있게 한다. 성능을 보호하여 인스턴스에서 계측을 선정하는 것은 규칙의 배치 및 제작을 용이하게 하고 관련 운영 체계가 관리가능하게 한다.

모델 기반 관리 프레임워크는 RDL을 사용하여 소프트웨어와 하드웨어의 이용 가능성을 모니터링을 할 목적으로 규칙의 한정을 가능하게 한다. RDL로 기재된 규칙은 모니터링 서비스의 일부로서 런타임 엔진에 의해 실행된다. RDL의 목적은 단정을 검사하고, 런타임 정보를 사용하여 제한을 실행하며, 유추 수행, 상관 수행, 및 다른 컴포넌트에 대한 동적 테스트의 결과를 통신하게 하는 점이다. RDL은 규칙 유형(즉, 클래스)을 한정하지만, 개별 XML(확장형 마크업 언어) 문서는 그 인스턴스화에 필요한 파라미터 값을 규정하여 규칙 유형의 인스턴스를 생성하는데 사용된다. 문제 검출, 진단, 해결, 검증 및 경고를 위해 시스템이 취해야 할 단계의 시퀀스를 나타내는 스키마가 존재한다. 이는 모델 내에서 기재되고, 목록에 표현되며, 모니터링 시스템에 의해 실행/관리되는 것이다.

모델 기반 관리 프레임워크는 성능 카운터의 이벤트 및 갱신 값을 사용하여 상술한, 서비스의 헬스 모델(또는 상태), 및 테스트 또는 합성 트랜잭션을 나타낸다. 헬스 모델(701)은 서비스 또는 컴포넌트가 실행하는 방식의 그래픽 및/또는 텍스트 표현으로서, 관리자가 서비스의 성능 카운터와 다양한 이벤트의 중요성을 이해할 수 있게 한다. 개발자는 모델과 소스 코드 속성으로부터 생성된 대응 파일을 사용하여 헬스 모델(701)을 구축한다.

헬스 모델(701)은 의존성에 더하여 컴포넌트 관계의 설명을 포함한다. 검출된 문제에 따라, 시스템은 관계 트리를 조회하여 다른 컴포넌트의 헬스에 기초하여 근본 원인의 판단을 시도한다. 이러한 방식은 모델과 목록에 의해 지원된다.

도 8을 이하 참조하면, 모델 기반 관리의 처리의 흐름도가 도시되어 있다. 800에서, 설치될 애플리케이션 또는 서비스는 그 컴포넌트로 나타낸다. 802에서, 애플리케이션 또는 서비스는 기능, 구성, 보안, 및 성능으로 바람직한 상태를 나타낸다. 804에서, 설명이 시스템에 의해 사용되어 시스템의 관리 서비스를 구성하도록, 설명은 설치 동안 애플리케이션 또는 서비스와 함께 제공된다. 그 후, 처리는 정지 블럭에 도달한다.

도 9를 이하 참조하면, 모델 기반 관리를 구현하는 처리의 흐름도가 도시되어 있다. 900에서, 애플리케이션 컴포넌트, 헬스 상태 및 복구, 구성 설정 및 관리 작업에 대한 모델이 개발된다. 902에서, 사용자는 환경에 따라 시스템/규칙/모델을 커스텀화한다. 904에서, 속성은 소스 코드에 삽입되어 모니터링을 위한 계측 및 논리를 나타낸다. 906에서, 모델 정보과 소스 코드 속성의 목록이 관리 시스템 서비스에 의한 사용을 위해 제공된다. 목록은 머신 판독가능 형태의 관리 시스템 서비스에 의해 사용되기 위해 제공된다. 908에서, 관리 시스템 서비스 중 하나 이상은 목록 정보에 따라 구성된다. 910에서, 관리 작업은 시스템으로 씨엠디리트 등록, 스케줄 설정 등과 같은 목록 내의 애플리케이션에 대하여 한정된다. 그 후, 이 처리는 정지 블럭에 도달한다.

도 10을 이하 참조하면, 모델 기반 관리의 바람직한 상태를 구현하는 프로세서의 흐름도가 도시되어 있다. 1000에서, 바람직한 상태는 목록에서 액세스된다. 1002에서, 의존성이 검증되고 단지 필요한 파일, 설정, 및 보안 특징이 설치된다. 1004에서, 이벤트는 목록에 규정된 바와 같이 기입 및 전송된다. 1006에서, 계측 데이터와 카운터 데이터는 주기적으로 수집될 뿐만 아니라 테스트와 합성 트랜잭션이 수행된다. 1008에서, 자동 관리 작업이 수행된다. 1010에서, 프로그램 함수 로의 액세스가 제한된다. 그러나, 이는 모델 기반 관리를 용이하게 하기 위해 반드시 포함될 필요는 없다. 1012에서, 문제가 검출되어, 근본 문제가 진단되며, 교정 동작이 취해서, 시스템 관리자가 중재하는 때를 통지받는다. 1014에서, 상기 모든 것에 대한 정책은 애플리케이션에 있어서 머신 및 시스템의 많은 다른 유형에 커스텀화된다. 그 후, 처리는 정지 블럭에 도달한다.

도 11을 이하 참조하면, 개시된 아키텍처를 실행하도록 동작하는 컴퓨터의 블럭도가 도시되어 있다. 본 발명의 다양한 양태에 대한 추가 경우를 제공하기 위해서, 도 11 및 다음 설명은 본 발명의 다양한 양태가 구현될 수 있는 적절한 컴퓨팅 환경(110)의 간단하고 일반적인 설명을 제공하려는 것이다. 본 발명은 하나 이상의 컴퓨터 상에서 동작할 수 있는 컴퓨터 실행가능 명령의 일반적인 경우로 상술하였지만, 당업자는 본 발명이 또한 다른 프로그램 모듈과의 조합 및/또는 하드웨어와 소프트웨어의 조합으로 구현될 수 있음을 인식할 것이다. 통상, 프로그램 모듈은 특정 작업을 수행하거나 특정 추상 데이터형을 구현하는 루틴, 프로그램, 컴포넌트, 데이터 구조 등을 포함한다. 더욱이, 당업자는 본 발명의 방법이 단일 프로세서 또는 멀티프로세서, 컴퓨터 시스템, 미니컴퓨터, 메인프레임 컴퓨터뿐만 아니라 개인용 컴퓨터, 핸드헬드 컴퓨팅 장치, 마이크로프로세서 기반 또는 프로그래머블 소비자 전자제품 등을 포함하는 다른 컴퓨터 시스템 구성으로 실시될 수 있으며, 이들 각각은 하나 이상의 관련 장치에 결합될 수 있다. 본 발명의 도시된 양태는 특정 작업이 통신 네트워크를 통해 연결된 원격 처리 장치에 의해 수행되는 분산 컴퓨팅 환경에서 실시될 수 있다. 분산 컴퓨팅 환경에서, 프로그램 모듈은 로컬 및 원격 메모리 스토리지 장치에 배치될 수 있다.

도 11을 다시 참조하면, 컴퓨터를 포함하는 본 발명의 다양한 양태를 구현하는 예시적인 환경(1100)이 도시되어 있으며, 컴퓨터(1102)는 처리부(1104), 시스템 메모리(1106), 및 시스템 버스(1108)를 포함한다. 시스템 버스(1108)는 시스템 메모리(1106)를 포함하지만 이에 국한되지 않는 시스템을 처리부(1104)에 결합한다. 처리부(1104)는 임의의 다양한 상업적으로 입수가능한 프로세서일 수 있다. 듀얼 멀티프로세서 및 다른 멀티프로세서 아키텍처가 또한 처리부(1104)로서 사용될 수 있다.

시스템 버스(1108)는 메모리 버스(메모리 컨트롤러와 함께 또는 없이), 주변 버스 및 임의의 다양한 상업적으로 입수가능한 버스 아키텍처를 사용한 로컬 버스에 더 상호접속될 수 있는 여러 유형의 버스 구조 중 임의의 것일 수 있다. 시스템 메모리(1106)는 판독 전용 메모리(ROM; 1110) 및 랜덤 액세스 메모리(RAM; 1112)를 포함한다. 기본 입출력 시스템(BIOS)은 ROM, EPROM, EEPROM 등의 비휘발성 메모리(1110)에 저장되며, BIOS는 시동 동안과 같이 컴퓨터(1102) 내의 요소들 간의 정보를 전송할 수 있게 하는 기본 루틴을 포함한다. RAM(1112)은 또한 데이터 캐시를 위한 정적 RAM 등과 같은 고속 RAM을 포함할 수 있다.

또한, 컴퓨터(1102)는 하드 디스크 드라이브(1114), 자기 디스크 드라이브(1116; 예를 들어, 분리형 디스크(1118)로부터 판독하거나 이에 기입함) 및 광 디스크 드라이브(1120; 예를 들어, CD-ROM 디스크(1122)를 판독하거나, 디지털 비디오 디스크(DVD) 등의 다른 대용량 광 매체로부터 판독하거나 이에 기입)를 더 포함 한다. 하드 디스크 드라이브(1114), 자기 디스크 드라이브(1114) 및 광 디스크 드라이브(1120)는 하드 디스크 드라이브 인터페이스(1124), 자기 디스크 드라이브 인터페이스(1126) 및 광 디스크 드라이브 인터페이스(1128)에 의해 각각 시스템 버스에 접속될 수 있다. 드라이브 및 이들의 관련 컴퓨터 판독가능 매체는 데이터, 데이터 구조, 컴퓨터 판독가능 명령 등을 제공한다. 컴퓨터(1102)에 있어서, 드라이브 및 매체는 적절한 디지털 포맷으로 동보 프로그래밍의 스토리지를 조정한다. 상기 컴퓨터 판독가능 매체의 설명은 하드 디스크, 분리형 자기 디스크, 및 CD를 지칭하지만, 집 드라이브, 자기 카세트, 플래시 메모리 카드, 디지털 비디오 디스크, 카트리지 등과 같이 컴퓨터에 의해 판독가능한 다른 유형의 매체가 예시적인 운영 환경에서 사용될 수 있고 임의의 이러한 매체는 본 발명의 방법을 수행하는 컴퓨터 실행가능 명령을 포함할 수 있음이 당업자는 이해하여야 한다.

운영 체계(1130), 하나 이상의 애플리케이션 프로그램(1132), 다른 프로그램 모듈(1134) 및 프로그램 데이터(1136) 등의 다수의 프로그램 모듈이 드라이브 및 RAM(1112)에 저장될 수 있다. 또한, 운영 체계, 애플리케이션, 모듈, 및/또는 데이터의 전부 또는 일부가 RAM(1112) 내에 캐싱될 수 있다.

본 발명은 다양한 상업적으로 입수가능한 운영 체계 또는 운영 체계의 조합으로 구현될 수 있다.

사용자는 키보드(1138) 및 마우스(1140)와 같은 포인팅 장치를 통해 컴퓨터(1102)에 명령 및 정보를 입력할 수 있다. 다른 입력 장치(미도시)는 마이크로폰, IR 원격 제어, 조이스틱, 게임 패드, 위성 접시, 스캐너 등을 포함할 수 있다. 이 들 및 다른 입력 장치는 종종 시스템 버스(1108)에 결합된 직렬 포트 인터페이스(1142)를 통해 처리부(1104)에 접속되지만, 병렬 포트, 게임 포트, 범용 직렬 포트("USB"), IR 인터페이스 등의 다른 인터페이스에 의해 접속될 수 있다. 모니터링(1144) 또는 다른 유형의 디스플레이 장치가 또한 비디오 어댑터(1146) 등의 인터페이스를 통해 시스템 버스(1108)에 접속된다. 모니터링(114)에 더하여, 컴퓨터는 통상 스피커, 프린터 등의 다른 병렬 출력 장치(미도시)를 포함한다.

컴퓨터(1102)는 원격 컴퓨터(1148) 등의 하나 이상의 원격 컴퓨터로의 유선 및/또는 무선 통신을 통한 논리적 접속을 사용하는 네트워킹 환경에서 동작할 수 있다. 원격 컴퓨터(1148)는 워크스테이션, 서버 컴퓨터, 라우터, 개인용 컴퓨터, 휴대용 컴퓨터, 마이크로프로세서 기반 엔터테인먼트 기기, 피어 장치 또는 다른 공통 네트워크 노드일 수 있으며, 통상 간이함을 위해서 단지 메모리 스토리지 장치(1150)가 도시되지만 컴퓨터(1102)에 대하여 설명된 많은 또는 모든 요소를 포함한다. 도시된 논리적 접속은 근거리 네트워크(LAN; 1152)와 광역 네트워크(WAN; 1154)를 포함한다. 이러한 네트워킹 환경은 사무실, 범사내 컴퓨터 네트워크, 인트라넷 및 인터넷에서 흔히 볼 수 있다.

LAN 네트워킹 환경에서 사용되는 경우, 컴퓨터(1102)는 유선 또는 무선 통신 네트워크 인터페이스 또는 어댑터(1156)를 통해 로컬 네트워크(1152)에 접속된다. 어댑터(1156)는 LAN(1152)으로의 유선 또는 무선 통신을 용이하게 할 수 있으며, 또한, 무선 어댑터(1156)에 통신하는 무선 액세스 포인트를 포함할 수 있다. WAN 네트워킹 환경에서 사용되는 경우, 컴퓨터(1102)는 통상 모뎀(1158)을 포함하거나 LAN 상의 통신 서버에 접속되거나 인터넷과 같은 WAN(1154) 상으로 통신을 설정하는 다른 수단을 갖는다. 모뎀(1158)은 내장형 또는 외장형 그리고 유선 또는 무선 장치일 수 있으며, 직렬 포트 인터페이스(1142)를 통해 시스템 버스(1108)에 접속된다. 네트워킹 환경에서, 컴퓨터(1102)와 그 일부에 대하여 도시된 프로그램 모듈은 원격 메모리 스토리지 장치(1150)에 저장될 수 있다. 도시된 네트워크 접속은 예시적이며 컴퓨터 간의 통신 링크를 설정하는 다른 수단이 사용될 수 있음이 이해될 것이다.

컴퓨터(1102)는 무선 통신에 동작가능하게 배치되는 임의의 무선 장치 또는 엔티티, 예를 들어, 프린터, 스캐너, 데스크탑 및/또는 휴대용 컴퓨터, 휴대용 데이터 단말, 무선 검출가능 태그에 관련된 임의의 장비 또는 위치(예를 들어, 키오스크, 신문 판매대, 휴게실) 및 전화기 등과 통신하도록 동작한다. 이는 적어도 Wi-Fi 및 Bluetooth^TM 무선 기술을 포함한다. 따라서, 통신은 통상의 네트워크 또는 단지 적어도 두 장치 간의 임시 통신과 같은 소정의 구조일 수 있다.

Wi-Fi 또는 무선 충실도는 홈에서의 소파, 호텔 방의 침실, 작업시 회의실에서 인터넷으로의 접속을 무선으로 가능하게 한다. Wi-Fi는 이러한 장치, 예를 들어, 컴퓨터가 기지국 범위 내의 임의의 곳에서 데이터를 실내 및 실외에서 데이터를 송수신할 수 있게 하는 셀룰러 폰과 같은 무선 기술이다. Wi-Fi 네트워크는 IEEE 802.11(a, b, g 등)으로 불리는 무선 기술을 사용하여 안전하고, 신뢰성있는 고속 무선 접속을 제공한다. Wi-Fi 네트워크는 서로, 인터넷에, 그리고 유선 네트 워크(IEEE 802.3 또는 이더넷을 사용)에 접속하는데 사용될 수 있다. Wi-Fi 네트워크는 무허가 2.4 및 5㎓ 대역에서 11Mbps(802.11b) 또는 54Mbps(802.11a) 데이터 레이트로 또는 대역(듀얼 대역)을 포함하는 제품으로 동작하므로 네트워크는 많은 사무실에서 사용되는 기본 10BaseT 유선 이더넷 네트워크와 유사한 실제 성능을 제공할 수 있다.

도 12를 이하 참조하면, 본 발명에 따라 예시적인 컴퓨팅 환경(1200)의 개략 블럭도가 도시되어 있다. 시스템(1200)은 하나 이상의 클라이언트(1202)를 포함한다. 클라이언트(1202)는 하드웨어 및/또는 소프트웨어(예를 들어, 스레드, 처리, 컴퓨팅 장치)일 수 있다. 클라이언트(1202)는 예를 들면 본 발명을 사용하여 쿠키 및/또는 관련 문맥 정보를 수용할 수 있다. 또한, 시스템(1200)은 하나 이상의 서버(1204)를 포함한다. 서버(1204)는 또한 하드웨어 및/또는 소프트웨어(예를 들어, 스레드, 처리, 컴퓨팅 장치)일 수 있다. 서버(1204)는 예를 들면 본 발명을 사용하여 변환을 수행하는 스레드를 수용할 수 있다. 클라이언트(1202)와 서버(1204) 간의 하나의 가능한 통신은 둘 이상의 컴퓨터 처리 사이에 전송되기에 적합한 데이터 패킷의 형태일 수 있다. 데이터 패킷은 예를 들면 쿠키 및/또는 관련 문맥 정보를 포함할 수 있다. 시스템(1200)은 클라이언트(1202)와 서버(1204) 간의 통신을 용이하게 하도록 사용될 수 있는 통신 프레임워크(1206; 예를 들어, 인터넷 등의 글로벌 통신 네트워크)를 포함한다.

통신은 유선(광섬유 등) 및/또는 무선 기술을 통해 촉진될 수 있다. 클라이언트(1202)는 클라이언트(1202)에 로컬인 정보를 저장하도록 사용될 수 있는 하나 이상의 클라이언트 데이터 저장소(1208)에 접속한다(예를 들어, 쿠키 및/또는 관련 문맥 정보). 유사하게, 서버(1204)는 서버(1204)에 로컬인 정보를 저장하도록 사용될 수 있는 하나 이상의 서버 데이터 저장소(1210)에 접속한다.

상술한 것은 본 발명의 예를 포함한다. 물론, 본 발명을 나타내는 목적으로 컴포넌트 또는 방법의 모든 고려가능 조합을 나타내는 것은 가능하지 않지만, 당업자는 본 발명의 많은 다른 조합 및 변경이 가능함을 인식할 수 있다. 따라서, 본 발명은 본 발명의 취지 및 범위에 속하는 모든 이러한 변경, 변형 및 변화를 포함하려는 것이다. 더욱이, "구비하다(include)"라는 용어가 상세한 설명 또는 청구항에서 사용되는 경우에서, 이러한 용어는 "포함하다(comprising)"가 청구항에서 전환어로서 사용되는 경우에 해석되는 것과 같이 "포함하다(comprising)"라는 용어에 유사한 방식이 포함시키려는 것이다.

Claims

규칙 처리를 용이하게 하는 시스템으로서,

동기 문장을 동기 프로그래밍 모델을 사용하여 비동기 명령으로 번역하는 번역기 컴포넌트를 포함하는 규칙 처리 시스템.
제1항에 있어서,

상기 문장은 일련의 규칙 유형으로 구성된 규칙 처리 시스템.
제2항에 있어서,

상기 규칙 유형은 타겟 자원의 바람직한 상태를 판정하는 논리를 표현하는 규칙 처리 시스템.
제3항에 있어서,

바람직한 상태에 응답하여, 동작이 취해지는 규칙 처리 시스템.
제1항에 있어서,

상기 번역기 컴포넌트는 상기 비동기 명령의 인스턴스화를 용이하게 하는 규칙 처리 시스템.
제1항에 있어서,

상기 명령은 런타임 엔진에 의한 병행 처리를 용이하게 하는 규칙 처리 시스템.
제6항에 있어서,

상기 명령은 상기 런타임 엔진에 의해 모든 상태를 유지하게 하고, 상기 상태는 적어도 하나의 인수 및 로컬 변수를 포함하는 규칙 처리 시스템.
제1항에 있어서,

상기 명령은 런타임 규칙 실행 스위칭의 산출(yield) 및 유틸리티 함수의 호출 중 적어도 하나를 용이하게 하는 규칙 처리 시스템.
제1항에 있어서,

상기 명령은 주기적 산출 문장을 삽입하는 규칙 처리 시스템.
제1항에 있어서,

상기 번역기 컴포넌트가 깊이 우선 트래버설을 용이하게 하여 대응 노드에 대한 라벨 및 임시 변수 중 적어도 하나를 생성하는 규칙 처리 시스템.
제1항에 있어서,

상기 번역기 컴포넌트는 상기 규칙의 클래스로의 모듈을 번역하는 규칙 처리 시스템.
제1항에 있어서,

상기 명령은 런타임 엔진에 의한 문맥 스위칭을 용이하게 하는 어드레스 코드 표현을 포함하는 규칙 처리 시스템.
제12항에 있어서,

상기 어드레스 코드 표현은 적어도 3개의 어드레스 코드를 사용하며, 상기 표현은 문장 또는 표현이 비동기 호출을 포함하는 경우 사용되는 규칙 처리 시스템.
제1항에 있어서,

상기 명령은 스위치 케이스 블럭으로 분리되는 일련의 명령 블럭에 번역되는 규칙 처리 시스템.
제14항에 있어서,

상기 명령 블럭 내의 명령은 하나의 유닛으로서 실행되고, 이러한 명령 블럭 사이에만 런타임 실행을 산출하는 규칙 처리 시스템.
제14항에 있어서,

상기 일련의 명령 블럭은 상기 일련의 것 중 어느 명령 블럭이 상기 규칙으로의 재입력 시에 다음에 실행되도록 유지하는 갱신 식별자에 관련되는 규칙 처리 시스템.
규칙의 병행 처리를 용이하게 하는 시스템으로서,

상기 규칙을 병행 처리를 위한 명령으로 번역하는 번역기 컴포넌트; 및

처리를 위한 상기 명령을 스케줄링하고 상기 스케줄에 따라 동시에 일부 또는 전부의 명령을 처리하는 런타임 엔진을 포함하는 규칙 병행 처리 시스템.
제17항에 있어서,

상기 런타임 엔진은 상기 규칙의 묵시적 병행 처리를 용이하게 하는 규칙 병행 처리 시스템.
제17항에 있어서,

상기 런타임 엔진은 상기 명령과 구성 데이터를 수신하고, 상기 구성 데이터는 어느 규칙을 실행할지 그리고 상기 규칙을 실행하는데 필요한 상기 파라미터 중 적어도 하나를 규정하는 규칙 병행 처리 시스템.
모델 기반 관리 아키텍처에서 규칙의 처리를 용이하게 하는 시스템으로서,

상기 아키텍처에 대한 헬스 기준을 나타내는 복수의 규칙;

상기 규칙을 병행 처리를 위한 비동기 명령을 번역하는 번역기 컴포넌트; 및

처리를 위한 상기 번역된 명령을 스케줄링하고 상기 스케줄에 따라 동시에 일부 또는 전부의 명령을 처리하는 런타임 엔진을 포함하는 규칙 처리 시스템.
제20항에 있어서,

상기 런타임 엔진은 코드의 처리를 일시정지하는 상기 명령 중 하나에 따라 동작하여 이벤트 발생을 대기하며, 이에 응답하여 상기 코드가 재개되어 상기 이벤트에 대하여 동작할 수 있게 하는 규칙 처리 시스템.
제20항에 있어서,

상기 복수의 규칙 중 하나는 다른 규칙을 호출하는 규칙 처리 시스템.
제20항에 있어서,

상기 엔진은 상기 현재 프레임에 대한 폴링 구조에 따라 실행 스택의 실행을 스케줄링하고 상기 폴링 구조가 상기 실행 스택의 상부에 있는 규칙 처리 시스템.
제20항에 있어서,

상기 명령 컴포넌트는 점핑 이전에 규칙이 비선취권(non-preemptive) 스케줄링을 용이하게 하는 런타임 엔진에 리턴하도록 루프를 용이하게 하는 언어를 포함 하는 규칙 처리 시스템.
제20항에 있어서,

상기 번역된 명령은 협업 멀티태스킹을 용이하게 하여 함수의 실행 상태가 보전되고 추후 구성되는 규칙 처리 시스템.
제20항에 있어서,

상기 명령은 호출 프레임의 구성을 용이하게 하며, 상기 호출 프레임은 함수 파라미터, 현재 명령 블럭, 현재 함수 및 로컬 변수 중 적어도 하나를 포함하는 규칙 처리 시스템.
제20항에 있어서,

상기 런타임 엔진은 임의의 시간에서 시작한 구간 동안 작업 실행을 확산하여 과도 활용을 저감시키는 확산 알고리즘을 포함하는 규칙 처리 시스템.
제20항의 시스템에 따른 컴퓨터 시스템.
규칙 처리 방법으로서,

복수의 규칙을 수신하는 단계;

상기 규칙을 런타임 엔진으로의 통신을 위한 명령으로 번역하는 단계;

상기 런타임 엔진에 의한 처리를 위해 상기 번역된 명령을 스케줄링하는 단계;

상기 런타임 엔진과 동시에 상기 복수의 명령 중 적어도 두개를 처리하는 단계; 및

구성 데이터를 상기 런타임 엔진으로 수신하여 상기 규칙을 인스턴스화하는 단계를 포함하는 규칙 처리 방법.
제29항에 있어서,

상기 규칙에 산출 명령을 입력하여 상기 런타임 엔진에 의한 처리 동안 상기 규칙별 코드 실행 스위칭의 산출 실행을 용이하게 하고 상기 런타임 엔진에 의해 제공되는 호출 유틸리티 함수를 용이하게 하는 규칙 처리 방법.
제29항에 있어서,

상기 번역된 명령은 일련의 명령 블럭으로 번역되고, 상기 명령 블럭의 실행의 개시는 상기 명령 블럭이 상기 런타임 엔진의 산출 전에 그 전체로 실행되게 하는 규칙 처리 방법.
제29항에 있어서,

스타트업 처리 동안, 스타트업 시에 상기 런타임 엔진에 의한 실행을 위해 표시된 규칙의 작업 리스트를 구축하는 단계와 규칙의 각 배치가 시간 구성된 구간 내의 처리를 위해 스케줄링되도록 배치 내의 규칙 초기화를 확산시키는 단계를 더 포함하는 규칙 처리 방법.
제32항에 있어서,

소정 기준에 따라 상기 구간을 구성하는 단계를 더 포함하되, 상기 기준은 상기 컴퓨터에 의해 사용되는 다수의 프로세서를 구비하는 규칙 처리 방법.
제29항에 있어서,

상기 명령은 상기 런타임 엔진에 의한 배치 처리를 위해 스케줄링되어, 배치의 규칙이 상기 배치의 처리를 위한 관련 구간에 대하여 균일한 처리를 위해 스케줄링되는 규칙 처리 방법.
제29항에 있어서,

폴링 구조에 따라 처리를 위한 상기 번역된 명령을 스케줄링하는 단계를 더 포함하되, 상기 처리는 현재 프레임의 상기 폴링 구조와 스택 상부에서의 상기 폴링 구조 중 적어도 하나에 대하여 발생하는 규칙 처리 방법.
제29항에 있어서,

스케줄링은 비선취권 스케줄링 방식에 따라 수행되는 규칙 처리 방법.
규칙 처리 시스템으로서,

복수의 규칙을 수신하는 수단;

상기 규칙을 명령으로 변환하는 수단;

런타임 엔진에 의한 처리를 위해 상기 명령을 번역하는 수단; 및

상기 복수의 명령 중 적어도 두개를 스케줄링 및 병행 처리하는 수단을 포함하는 규칙 처리 시스템.
제37항에 있어서,

상기 변환 수단은, 실행 동안 상기 관련 번역된 명령의 제어를 어디서 포기하는지, 어느 포기 코드가 파라미터와 로컬 변수들 중 적어도 하나를 포함하는 스택 프레임에 관련되는지, 및 재입력시에 상기 변역된 명령 내의 어느 곳에 점프하는지를 결정하는 규칙으로 제어 포기 코드를 삽입하는 수단을 포함하는 규칙 처리 시스템.
제37항에 있어서,

규칙 간의 작업 스위칭 수단을 더 포함하되, 상기 번역된 명령은 작업 스위칭을 용이하게 하는 호출 프레임을 포함하는 규칙 처리 시스템.
규칙의 병행 처리를 수행하는 컴퓨터 판독가능 명령을 갖는 컴퓨터 판독가능 매체로서,

동기 규칙 문장을 동기 프로그래밍 모델을 사용하여 비동기 명령으로 번역하는 번역기 컴포넌트를 포함하되,

상기 명령은 유틸리티 함수 호출과 런타임 코드 스위칭의 산출을 용이하게 하는 컴퓨터 판독가능 매체.