KR20060130478A

KR20060130478A - 관리 도구 환경

Info

Publication number: KR20060130478A
Application number: KR1020057008069A
Authority: KR
Inventors: 제프리 피. 스노버; 다일 더블유. 워레이; 제임스 더블유. 3세 트루허; 브루스 지. 페이예트
Original assignee: 마이크로소프트 코포레이션
Priority date: 2003-10-24
Filing date: 2004-07-23
Publication date: 2006-12-19
Also published as: CN100547552C; US7155706B2; EP1631887A4; CN101091160A; WO2005045568A2; US20070135949A1; WO2005045568A3; KR101120853B1; EP1631887A2; US7243344B2; US20050091258A1; JP2007519073A; US8230405B2; US20050091201A1

Abstract

관리 도구 환경에서, 사용자 입력은 처리를 위해 관리 도구 프레임워크로 제공된다. 관리 도구 프레임워크는 사용자 입력을 cmdlet 객체들로 맵핑한다. cmdlet 객체들은 예측 입력 파라미터를 얻기 위해 사용자 입력 및 입력 객체들을 분석하기 위한 문법을 기술한다. 입력 객체들은 하나의 cmdlet에 의해 발행되고, 다른 cmdlet에 대한 입력으로서 이용될 수 있다. 입력 객체들은 .NET 객체들, 플레인 스트링들, XML 문서들 등과 같은 임의의 정밀하게 분석 가능한 입력일 수 있다. cmdlet들은 동일 프로세스 내에서 동작할 수 있다. 대안으로, 하나의 cmdlet는 로컬하게 동작하는 반면 다른 cmdlet는 원격적으로 동작할 수 있다. cmdlet들은 관리 도구 프레임워크에 의해 제공되거나 삼자 개발자에 의해 제공될 수 있다. 사용자 입력은 호스트 cmdlet를 통해 프레임워크에 제공될 수 있다.

관리 도구 프레임워크, cmdlet, 예측 입력 파라미터, 입력 객체

Description

관리 도구 환경{ADMINISTRATIVE TOOL ENVIRONMENT}

본 발명은 실행 시간 환경에 관한 것으로서, 특히 관리 작업을 자동화하기 위한 관리 도구 환경에 관한 것이다.

관리 작업은 랩탑, 데스크탑 등과 같은 컴퓨팅 장치들의 일상 동작을 지원한다. 예를 들어, 관리 작업은 일반적으로 사용자가 새로운 폴더를 생성하고, 애플리케이션을 설치 또는 업그레이드하고, 다양한 다른 시스템 작업을 행하는 것을 허용한다. 네트워킹된 컴퓨터들을 관리하는 시스템 관리자는 새로운 사용자를 생성하고, 소프트웨어 및 소프트웨어 패치를 배포하고, 네트워크를 모니터링하고, 네트워크의 문제를 해결하는 등 훨씬 더 복잡한 관리 작업을 수행한다. 종종, 명령 라인 인터페이스 또는 그래픽 사용자 인터페이스(GUI)는 관리 작업의 실행을 용이하게 한다.

대부분의 그래픽 사용자 인터페이스는 사용자가 일련의 메뉴 또는 페이지를 네비게이트한 후 원하는 옵션을 클릭할 것을 요구한다. 이러한 인터페이스에 따르면, 사용자는 일련의 메뉴 또는 페이지를 따라야 하며, 일련의 페이지를 통해 시작하거나 트래버스하지 않고 하나의 페이지에서 다른 페이지로 점프할 수 없다. 이러한 인터페이스는 사용자가 관리 목표를 달성하기 위해 통제되고 예정된 절차를 따라야 하는 제한된 네비게이션 인터페이스로서 지칭될 수 있다. 초보 사용자는 이러한 GUI를 이용함으로써 이익을 얻을 수 있는데, 이는 GUI가 초보 사용자를 원하는 관리 작업으로 안내하는 각각의 메뉴 또는 페이지 상에 도움이 되는 정보를 제공하기 때문이다. 그러나, 시스템 관리자와 같은 많은 고급 사용자들이 엄격한 네비게이션 제한을 가진 GUI를 사용하는 것은 매우 번거롭다. 이러한 고급 사용자들은 이들이 수행하고자 하는 관리 작업을 이미 알고 있다. 또한, 고급 사용자들은 적어도 어느 정도의 작업 자동화를 원한다. 그러나, GUI를 통해 액세스되는 관리 작업의 자동화는 매우 어렵다. 또한, GUI가 변경되는 경우, 대응하는 자동화는 더 이상 적절히 동작할 수 없게 된다. 따라서, 많은 고급 사용자들은 보다 강력한 명령 라인 인터페이스의 사용을 선호한다.

명령 라인 인터페이스는 사용자가 명령을 직접 타이핑해 넣음으로써 작업을 수행할 수 있게 해준다. 명령 라인 인터페이스의 한 가지 단점은 디스플레이 상에 도움 정보가 제공되지 않으므로 사용자가 타이핑해 넣어야 할 정확한 명령을 알아야 한다는 점이다. 그러나, 명령을 알 경우에는 일련의 메뉴를 네비게이트하는 것보다 명령을 타이핑하는 것이 훨씬 더 효율적이다. 또한, 명령 라인 인터페이스로부터 실행되는 작업들은 자동화될 수 있다. 예를 들어, 사용자들이 계속 동일한 명령들(예를 들어, 일련의 명령들 등)을 타이핑하고 있음을 인지한 경우, 이들은 반복 명령들을 포함하는 스크립트(예를 들어, .bat 파일)를 생성할 수 있다. 스크립트가 생성되면, 스크립트 내의 모든 명령이 실행된다. 사용자들은 또한 상이한 스크립트들이 유사한 항목들을 갖고 있음을 곧 인식할 수 있다. 이것을 인식한 사 용자들은 작업들을 더욱 자동화하기 위해 스크립트 내에 파라미터화된 서브 루틴들을 생성하기를 원할 수 있다.

그러나, 정교한 자동화 기능들(예를 들어, 파라미터화된 서브 루틴들)을 제공하는 많은 스크립팅 솔루션은 풀-블로운 애플리케이션(full-blown application)과 같은 방식으로 개발되며, 시스템 프로그래밍 지식을 요구한다. 따라서, 이 솔루션은 일반적으로 복잡한 프로그래밍 지식을 갖고 있지 않은 시스템 관리자들에게는 이상적이지 못하다.

따라서, 현재 시스템 관리자들은 자동화를 보류하거나 시스템 프로그래밍 기술을 이용하여 자동화해야 한다. 어느 옵션도 크게 바람직하지는 않다. 관리자가 자동화를 보류하기로 선택한 경우, 여러 다른 관리자들이 수동 작업을 돕도록 지원하기 위해 추가 비용이 발생한다. 그러나, 관리자가 작업을 자동화하기로 선택한 경우에는, 프로그래밍 환경을 지원하고 필요한 프로그래밍 기술을 취득하기 위한 비용이 발생한다. 또한, 자동화된 도구는 변경이 발생할 때마다 재구축되어야 하므로 유지 비용이 많이 든다.

따라서, 관리자들이 관리 작업을 효과적으로, 효율적으로 자동화하는 것을 허용하는 관리 도구 프레임워크가 필요하다.

관리 도구 프레임워크가 제공된다. 사용자 입력은 처리를 위해 관리 도구 프레임워크로 제공된다. 관리 도구 프레임워크는 사용자 입력을 cmdlet 객체들로 맵핑한다. cmdlet 객체들은 cmdlet 내에서 식별되는 예측 입력 파라미터를 얻기 위해 사용자 입력 및 입력 객체들을 분석하기 위한 문법과 연관된다. 문법은 파라미터 선언의 이용과 같이 cmdlet 내에 직접 연관될 수 있다. 대안으로, 문법은 예를 들어 XML 문서를 통해 cmdlet와 간접적으로 연관될 수 있다. 입력 객체들은 하나의 cmdlet에 의해 발행되고, 다른 cmdlet에 대한 입력으로서 이용될 수 있다. 입력 객체들은 .NET 객체들, 플레인 스트링들, XML 문서들 등과 같은 임의의 정밀하게 분석 가능한 입력일 수 있다. cmdlet들은 동일 프로세스 내에서 동작할 수 있다. 대안으로, 하나의 cmdlet는 로컬하게 동작하는 반면 다른 cmdlet는 다른 프로세스에서 또는 원격적으로 동작할 수 있다. cmdlet들은 관리 도구 프레임워크에 의해 제공되거나 삼자 개발자에 의해 제공될 수 있다. 사용자 입력은 호스트 cmdlet를 통해 프레임워크에 제공될 수 있다.

도 1은 예시적인 관리 도구 환경을 사용할 수 있는 예시적인 컴퓨팅 장치이다.

도 2는 본 발명의 관리 도구 환경에 대한 예시적인 관리 도구 프레임워크의 개요를 나타내는 블록도이다.

도 3은 도 2에 도시된 관리 도구 프레임워크의 호스트 특정 컴포넌트들 내의 컴포넌트들을 나타내는 블록도이다.

도 4는 도 2에 도시된 관리 도구 프레임워크의 코어 엔진 컴포넌트 내의 컴포넌트들을 나타내는 블록도이다.

도 5는 도 2에 도시된 관리 도구 프레임워크에서 사용하기에 적합한 cdmlet 를 지정하기 위한 예시적인 데이타 구조이다.

도 6은 도 5에 도시된 cmdlet가 도출되는 명령 기본 타입을 지정하기 위한 예시적인 데이타 구조이다.

도 7은 도 2에 도시된 관리 도구 프레임워크에서 사용하기에 적합한 cmdlet를 지정하기 위한 다른 예시적인 데이타 구조이다.

도 8은 도 2에 도시된 관리 도구 프레임워크에서 수행되는 호스트 처리를 위한 예시적인 프로세스를 나타내는 논리 흐름도이다.

도 9는 도 2에 도시된 관리 도구 프레임워크에서 수행되는 입력 핸들링을 위한 예시적인 프로세스를 나타내는 논리 흐름도이다.

도 10은 도 9에 도시된 입력 핸들링을 위한 프로세스에서 사용하기에 적합한 스크립트를 처리하기 위한 프로세스를 나타내는 논리 흐름도이다.

도 11은 도 10에 도시된 스크립트 처리 프로세스에서 사용하기에 적합한 스크립트 사전 처리 프로세스를 나타내는 논리 흐름도이다.

도 12는 도 10에 도시된 스크립트 처리 프로세스에서 사용하기에 적합한 제한을 적용하기 위한 프로세스를 나타내는 논리 흐름도이다.

도 13은 도 2에 도시된 관리 도구 프레임워크에서 명령 스트림의 처리를 나타내는 기능 흐름도이다.

도 14는 도 9에 도시된 입력 핸들링을 위한 프로세스에서 사용하기에 적합한 명령 스트링을 처리하기 위한 프로세스를 나타내는 논리 흐름도이다.

도 15는 도 14에 도시된 명령 스트링의 처리에 사용하기에 적합한 cmdlet의 인스턴스를 생성하기 위한 예시적인 프로세스를 나타내는 논리 흐름도이다.

도 16은 도 14에 도시된 명령의 처리에 사용하기에 적합한 cmdlet의 특성들을 팝퓰레이트하기 위한 예시적인 프로세스를 나타내는 논리 흐름도이다.

도 17은 도 14에 도시된 명령의 처리에 사용하기에 적합한 cmdlet를 실행하기 위한 예시적인 프로세스를 나타내는 논리 흐름도이다.

도 18은 도 2에 도시된 관리 도구 프레임워크에 사용하기에 적합한 예시적인 확장 타입 관리자의 기능 블록도이다.

도 19는 파이프라인 내의 출력 처리 cmdlet들에 대한 예시적인 시퀀스를 나타내는 도면이다.

도 20은 도 19에 도시된 출력 처리 cmdlet들 중 하나에 의해 수행되는 예시적인 처리를 나타내는 도면이다.

도 21은 도 20의 처리 동안 액세스되는 디스플레이 정보에 대한 예시적인 구조를 나타내는 도면이다.

도 22는 예시적인 출력 처리 cmdlet들에 대한 예시적인 신택스를 나타내는 테이블이다.

도 23은 출력 처리 cmdlet들의 다양한 파이프라인 시퀀스를 이용하여 출력/콘솔 cmdlet에 의해 렌더링된 결과를 나타내는 도면이다.

요컨대, 본 발명의 관리 도구 환경은 컴퓨터들 및 컴퓨터 네트워크들의 관리 및 지원과 관련된 관리 비용을 감소시키는 컴퓨팅 프레임워크를 제공한다. 또한, 이 프레임워크는 프로그래머 및 논-프로그래머 양자에 의한 관리 도구의 빠른 특별 개발을 지원한다.

아래의 설명은 특정의 예시적인 관리 도구 환경을 설명한다. 다른 예시적인 환경들은 이 특정 실시예의 기능들 및/또는 관리 작업을 용이하게 하는 다른 기능들을 포함할 수 있다.

다음의 상세한 설명은 여러 섹션으로 나뉜다. 제1 섹션은 관리 도구 환경이 동작할 수 있는 예시적인 컴퓨팅 환경을 설명한다. 제2 섹션은 관리 도구 환경에 대한 예시적인 프레임워크를 설명한다. 후속 섹션들은 예시적인 프레임워크의 개별 컴포넌트들, 및 이들 컴포넌트의 동작을 설명한다.

예시적인 컴퓨팅 환경

도 1은 예시적인 관리 도구 환경에서 사용될 수 있는 예시적인 컴퓨팅 장치를 나타낸다. 매우 기본적인 구성에 있어서, 컴퓨팅 장치(100)는 일반적으로 적어도 하나의 처리 유닛(102) 및 시스템 메모리(104)를 포함한다. 컴퓨팅 장치의 정확한 구성 및 타입에 따라, 시스템 메모리(104)는 휘발성(RAM 등), 불휘발성(ROM, 플래시 메모리 등) 또는 이 둘의 소정의 조합일 수 있다. 시스템 메모리(104)는 일반적으로 운영 체제(105), 하나 이상의 프로그램 모듈(106)을 포함하며, 프로그램 데이타(107)를 포함할 수 있다. 운영 체제(105)는 컴포넌트(특성 및 이벤트 포함), 객체, 상속성, 다형성, 반사를 지원하는 컴포넌트 기반 프레임워크(120)를 포함하며, 마이크로소프트 사에 의해 개발된 .NET 프레임워크와 같은 객체 지향 컴포넌트 기반 애플리케이션 프로그래밍 인터페이스(API)를 제공한다. 운영 체제(105) 는 또한 관리 도구(도시되지 않음)의 개발을 지원하기 위해 컴포넌트 기반 프레임워크(120)와 상호작용하는 관리 도구 프레임워크(200)를 포함한다. 이러한 기본 구성은 도 1에 점선(108) 내의 컴포넌트들에 의해 도시되어 있다.

컴퓨팅 장치(100)는 추가적인 기능 또는 기능성을 가질 수 있다. 예를 들어, 컴퓨팅 장치(100)는 또한 예컨대, 자기 디스크, 광 디스크 또는 테이프와 같은 추가적인 데이타 저장 장치들(분리식 및/또는 비분리식)을 포함할 수 있다. 이러한 추가적인 저장 장치는 도 1에 분리식 저장 장치(109) 및 비분리식 저장장치(110)에 의해 도시되어 있다. 컴퓨터 저장 매체는 컴퓨터 판독 가능 명령, 데이타 구조, 프로그램 모듈, 또는 기타 데이타와 같은 정보의 저장을 위한 임의의 방법 또는 기술로 구현되는 휘발성 및 불휘발성, 분리식 및 비분리식 매체를 포함할 수 있다. 시스템 메모리(104), 분리식 저장장치(109) 및 비분리식 저장장치(110)는 모두 컴퓨터 저장 매체의 예이다. 컴퓨터 저장 매체는 RAM, ROM, EEPROM, 플래시 메모리 또는 다른 메모리 기술, CD-ROM, DVD 또는 다른 광학 저장장치, 자기 카세트, 자기 테이프, 자기 디스크 저장장치 또는 다른 자기 저장 장치, 또는 원하는 정보를 저장하는 데 사용될 수 있고 컴퓨팅 장치(100)에 의해 액세스될 수 있는 임의의 다른 매체를 포함하지만, 이에 한하지 않는다. 이러한 임의의 컴퓨터 저장 매체는 장치(100)의 일부일 수 있다. 컴퓨팅 장치(100)는 키보드, 마우스, 펜, 음성 입력 장치, 터치 입력 장치 등과 같은 입력 장치(112)를 가질 수도 있다. 디스플레이, 스피커, 프린터 등과 같은 출력 장치(114)도 포함될 수 있다. 이 장치들은 이 분야에 잘 알려져 있으므로, 여기서는 상세히 설명될 필요는 없다.

컴퓨팅 장치(100)는 이 장치가 예를 들어 네트워크를 통해 다른 컴퓨팅 장치(118)와 통신하는 것을 허용하는 통신 접속들(116)을 포함할 수 있다. 통신 접속들(116)은 통신 매체의 일례이다. 통신 매체는 일반적으로 컴퓨터 판독 가능 명령, 데이타 구조, 프로그램 모듈, 또는 반송파 또는 다른 전송 메카니즘과 같은 변조 데이타 신호 내의 다른 데이타에 의해 구현될 수 있으며, 임의의 정보 전달 매체를 포함한다. "변조 데이타 신호"라는 용어는 신호의 특성들 중 하나 이상이 그 신호 내의 정보를 인코딩하는 방식으로 설정되거나 변경된 신호를 의미한다. 예를 들어, 통신 매체는 유선 네트워크 또는 직접적인 유선 접속과 같은 유선 매체, 및 어쿠스틱, RF, 적외선 및 다른 무선 매체와 같은 무선 매체를 포함하지만, 이에 한하지 않는다. 본 명세서에서 사용되는 컴퓨터 판독 가능 매체라는 용어는 저장 매체 및 통신 매체 양자를 포함한다.

예시적인 관리 도구 프레임워크

도 2는 예시적인 관리 도구 프레임워크(200)의 개요를 나타내는 블록이다. 관리 도구 프레임워크(200)는 하나 이상의 호스트 컴퓨터(202), 호스트 특정 컴포넌트(204), 호스트 독립 컴포넌트(206) 및 핸들러 컴포넌트(208)를 포함한다. 호스트 독립 컴포넌트(206)는 다른 컴포넌트(즉, 호스트 컴포넌트(202), 호스트 특정 컴포넌트(204) 및 핸들러 컴포넌트(208)) 각각과 통신할 수 있다. 이들 컴포넌트 각각은 아래에 간단하게 설명되며, 필요에 따라 후속 섹션에서 상세히 설명된다.

호스트 컴포넌트

호스트 컴포넌트(202)는 관련 애플리케이션에 대한 자동화 기능을 사용자에 게 또는 다른 프로그램에게 표시하는 하나 이상의 호스트 프로그램(예를 들어, 호스트 프로그램(210-214)을 포함한다. 각각의 호스트 프로그램(210-214)은 예를 들어 명령 라인, 그래픽 사용자 인터페이스(GUI), 음성 인식 인터페이스, 애플리케이션 프로그래밍 인터페이스(API), 스크립팅 언어, 웹 서비스 등을 통해 그 자신의 특정 스타일로 자동화 기능을 표시할 수 있다. 그러나, 호스트 프로그램(210-214) 각각은 관리 도구 프레임워크에 의해 제공되는 메카니즘을 통해 하나 이상의 자동화 기능을 표시한다.

이 예에서, 메카니즘은 cmdlet를 사용하여 관리 도구 능력을 관련 호스트 프로그램(210-214)의 사용자에게 표시한다. 또한, 메카니즘은 호스트에 의해 이용할 수 있게 만들어진 한 세트의 인터페이스를 사용하여 관리 도구 환경을 대응하는 호스트 프로그램(210-214)와 관련된 애플리케이션 내에 삽입한다. 아래의 설명 전반에서, "cmdlet"라는 용어는 도 2-23을 참조하여 설명되는 예시적인 관리 도구 환경에서 사용되는 명령을 지칭하기 위해 사용된다.

cmdlet는 통상적인 관리 환경 내의 명령에 대응한다. 그러나, cmdlet는 통상의 명령과는 아주 다르다. 예를 들어, cmdlet는 일반적으로 그의 대응 명령보다 크기가 작은데, 이는 cmdlet가 분석, 데이타 검증, 에러 보고 등과 같이 관리 도구 프레임워크에 의해 제공되는 공통 기능들을 이용할 수 있기 때문이다. 이러한 공통 기능들은 한번 구현되고, 한번 테스트되므로, 관리 도구 프레임워크를 통한 cmdlet의 사용은 애플리케이션 특정 기능들과 관련된 증가하는 개발 및 테스트 비용이 통상의 환경에 비해 아주 낮게 한다.

또한, 통상의 환경과 달리, cmdlet는 독립 실행 가능 프로그램일 필요가 없다. 오히려, cmdlet는 관리 도구 프레임워크 내의 동일 프로세스에서 실행될 수 있다. 이것은 cmdlet들이 서로 "라이브(live)" 객체를 교환하는 것을 허용한다. "라이브" 객체를 교환할 수 있는 이러한 능력은 cmdlet들이 객체들 상에 메소드를 직접 호출하는 것을 허용한다. cmdlet의 생성 및 사용에 대한 상세는 후술된다.

개략적으로, 각 호스트 프로그램(210-214)은 사용자와 관리 도구 프레임워크 내의 다른 컴포넌트들 사이의 상호작용을 관리한다. 이러한 상호작용은 파라미터에 대한 프롬프트, 에러의 보고 등을 포함할 수 있다. 일반적으로, 각 호스트 프로그램(210-213)은 그 자신의 특정 호스트 cmdlet들(예를 들어, cmdlet들(218))의 세트를 제공할 수 있다. 예를 들어, 호스트 프로그램이 이메일 프로그램인 경우, 호스트 프로그램은 메일 박스 및 메시지와 상호작용하는 호스트 cmdlet를 제공할 수 있다. 도 2는 호스트 프로그램(210-214)을 도시하고 있지만, 호스트 컴포넌트(202)는 기존의 또는 새로 생성된 애플리케이션과 관련된 다른 호스트 프로그램을 포함할 수 있다는 것을 당업자는 이해할 것이다. 이러한 다른 호스트 프로그램은 관리 도구 환경에 의해 제공되는 기능을 그들의 관련 애플리케이션에 삽입하기도 한다. 호스트 프로그램에 의해 제공되는 처리는 도 8과 관련하여 후술된다.

도 2에 도시된 예에서, 호스트 프로그램은 사용자가 컴퓨팅 장치의 하드웨어, 소프트웨어 및 네트워크 컴포넌트를 관리하는 관리 도구를 생성하고, 저장하고, 열 수 있도록 간단하고, 일관성 있는 관리 사용자 인터페이스를 제공하는 관리 콘솔(즉, 호스트 프로그램(210))일 수 있다. 이러한 기능을 달성하기 위하여, 호 스트 프로그램(210)은 관리 도구 프레임워크의 최상부에 관리 GUI를 구축하기 위한 한 세트의 서비스를 제공한다. GUI 상호작용은 또한 사용자에게 관리 도구 환경에 의해 제공되는 스크립팅 능력을 가르치는 것을 돕는 사용자 가시 스크립트로서 표시될 수 있다.

다른 예에서, 호스트 프로그램은 명령 라인 상호작용 쉘(즉, 호스트 프로그램(212))일 수 있다. 명령 라인 상호작용 쉘은 쉘 메타데이타(216)가 명령 라인의 처리에 영향을 미치도록 명령 라인 상에 입력되는 것을 허용할 수 있다.

또 다른 예에서, 호스트 프로그램은 플랫폼, 프로그래밍 언어 및 애플리케이션 전반에서의 분산 컴퓨팅 및 연동에 대한 산업 표준 사양을 이용하는 웹 서비스(즉, 호스트 프로그램(214))일 수 있다.

이들 예 외에, 삼자들이 그들의 호스트 프로그램 또는 다른 호스트 프로그램과 함께 사용되는 "삼자" 또는 "제공자" 인터페이스 및 제공자 cmdlet를 생성함으로써 그들 자신의 호스트 컴포넌트를 추가할 수 있다. 제공자 인터페이스는 애플리케이션 또는 기반구조를 표시하여, 이 애플리케이션 또는 기반구조가 관리 도구 프레임워크에 의해 조작될 수 있게 한다. 제공자 cmdlet는 네비게이션, 진단, 구성, 라이프 싸이클, 동작 등에 대한 자동화를 제공한다. 제공자 cmdlet는 완전히 혼성인 데이타 스토어들의 세트 상에 다형성 cmdlet 거동을 표시한다. 관리 도구 환경은 제공자 cmdlet 상에서 다른 cmdlet 클래스와 동일한 우선 순위로 동작한다. 제공자 cmdlet는 다른 cmdlet들과 동일한 메카니즘을 이용하여 생성된다. 제공자 cmdlet는 애플리케이션 또는 기반 구조의 특정 기능을 관리 도구 프레임워크에게 표시한다. 따라서, cmdlet의 사용을 통해, 제품 개발자들은 그들의 제품이 많은 관리 도구와 함께 동작하는 것을 허용하는 하나의 호스트 컴포넌트만을 생성하면 된다. 예를 들어, 예시적인 관리 도구 환경에서, 시스템 레벨 그래픽 사용자 인터페이스 헬프 메뉴는 기존 애플리케이션에 통합되고, 포팅될 수 있다.

호스트 특정 컴포넌트

호스트 특정 컴포넌트(204)는 컴퓨팅 시스템(예를 들어, 도 1의 컴퓨팅 장치(100))이 관리 도구 프레임워크가 실행되고 있는 플랫폼의 특성들로부터 관리 도구 프레임워크를 격리시키는 데 사용하는 서비스들의 집합을 포함한다. 따라서, 각 타입의 플랫폼에 대해 한 세트의 호스트 특정 컴포넌트들이 존재한다. 호스트 특정 컴포넌트들은 사용자들이 상이한 운영 체제들 상에서 동일한 관리 도구들을 사용하는 것을 허용한다.

도 3을 참조하면, 호스트 특정 컴포넌트(204)는 지능/메타데이타 액세스 컴포넌트(302), 헬프 cmdlet 컴포넌트(304), 구성/등록 컴포넌트(306), cmdlet 셋업 컴포넌트(308) 및 출력 인터페이스 컴포넌트(309)를 포함할 수 있다. 컴포넌트들(302-308)은 데이타베이스 스토어(314)와 관련된 데이타베이스 스토어 관리자(312)와 통신한다. 파서(220) 및 스크립트 엔진(222)은 지능/메타데이타 액세스 컴포넌트(302)와 통신한다. 코어 엔진(224)은 헬프 cmdlet 컴포넌트(304), 구성/등록 컴포넌트(306), cmdlet 셋업 컴포넌트(308) 및 출력 인터페이스 컴포넌트(309)와 통신한다. 출력 인터페이스 컴포넌트(309)는 out cmdlet들로 호스트에 의해 제공되는 인터페이스를 포함한다. 이들 out cmdlet는 렌더링을 수행하기 위해 호스트의 출력 객체를 호출할 수 있다. 호스트 특정 컴포넌트(204)는 또한, 코어 엔진(224)이 래깅 및 오디팅 능력을 제공하는 호스트 특정(즉, 플랫폼 특정) 서비스들과 통신하기 위해 사용하는 래깅/오디팅 컴포넌트(310)를 포함할 수 있다.

하나의 예시적인 관리 도구 프레임워크에서, 지능/메타데이타 액세스 컴포넌트(302)는 명령, 파라미터 및 파라미터 값의 자동 완료를 제공한다. 헬프 cmdlet 컴포넌트(304)는 호스트 사용자 인터페이스에 기초하여 주문화된 헬프 시스템을 제공한다.

핸들러 컴포넌트

도 2를 다시 참조하면, 핸들러 컴포넌트(208)는 레거시 유틸리티(230), 관리 cmdlet(232), 비관리 cmdlet(234), 원격화 cmdlet(236) 및 웹 서비스 인터페이스(238)를 포함한다. 관리 cmdlet(232)(플랫폼 cmdlet라고도 함)는 컴퓨팅 장치와 관련된 구성 정보를 질의하거나 조작하는 cmdlet를 포함한다. 관리 cmdlet(232)는 시스템 타입 정보를 조작하므로, 특정 플랫폼에 종속한다. 그러나, 각각의 플랫폼은 일반적으로 다른 플랫폼들 상의 관리 cmdlet(232)와 유사한 액션을 제공하는 관리 cmdlet(232)를 갖는다. 예를 들어, 각 플랫폼은 시스템 관리 속성들(예를 들어, get/process, set/IPAddress)을 취득하고 설정하는 관리 cmdlet(232)를 지원한다. 호스트 독립 컴포넌트(206)는 호스트 독립 컴포넌트(206) 내에 생성되는 cmdlet 객체를 통해 관리 cmdlet와 통신한다. cmdlet에 대한 예시적인 데이타 구조는 도 5-7과 관련하여 후술된다.

비관리 cmdlet(234)(가끔 기본 cmdlet라고도 함)는 관리 cmdlet(232)에 의해 제공되는 객체들을 그룹화하고, 분류하고, 필터링하고, 이들에 대해 다른 처리를 행하는 cmdlet를 포함한다. 비관리 cmdlet(234)는 또한 파이프라인 객체들과 관련된 데이타를 포맷하고 출력하기 위한 cmdlet를 포함할 수 있다. 데이타 구동 명령 라인 출력을 제공하기 위한 예시적인 메카니즘이 도 19-23과 관련하여 후술된다. 비관리 cmdlet(234)는 각각의 플랫폼 상에서 동일하고, cmdlet 객체를 통해 호스트 독립 컴포넌트(206)와 상호작용하는 한 세트의 유틸리티를 제공할 수 있다. 비관리 cmdlet(234)와 호스트 독립 컴포넌트(206) 사이의 상호작용은 객체들의 반사를 허용하고, 이들 (객체) 타입에 독립적인 반사된 객체들 상의 처리를 허용한다. 따라서, 이들 유틸리티는 개발자들이 비관리 cmdlet를 한번 작성한 후 이 비관리 cmdlet를 컴퓨팅 시스템 상에서 지원되는 객체들의 모든 클래스에 적용하는 것을 허용한다. 과거에 개발자들은 처리될 데이타의 포맷을 먼저 이해한 후 그 데이타만을 처리하는 애플리케이션을 작성해야 했다. 결과적으로, 통상의 애플리케이션들은 매우 한정된 범위의 데이타만을 처리할 수 있었다. 객체 타입에 독립적으로 객체를 처리하기 위한 하나의 예시적인 메카니즘이 도 18과 관련하여 후술된다.

레거시 유틸리티(230)는 cmd.exe 하에 실행되는 win32 실행 명령들과 같은 기존의 실행 명령들을 포함한다. 각각의 레거시 유틸리티(230)는 객체 프레임워크 내의 한 타입의 객체인 텍스트 스트림들(즉, stdin 및 stdout)을 이용하여 관리 도구 프레임워크와 통신한다. 레거시 유틸리티(230)는 텍스트 스트림을 이용하므로, 관리 도구 프레임워크에 의해 제공되는 반사 기반 동작들은 이용할 수 없다. 레거시 유틸리티(230)는 관리 도구 프레임워크와 다른 프로세스에서 실행된다. 도시되 지 않았지만, 다른 cmdlet들도 프로세스 밖에서 동작할 수 있다.

원격화 cmdlet(236)는 웹 서비스 인터페이스(238)와 협력하여 인터넷 또는 인트라넷(예를 들어 도 2에 도시된 인터넷/인트라넷 240)과 같은 통신 매체를 통해 다른 컴퓨팅 장치 상의 상호작용적이고 프로그램적인 관리 도구 환경에 액세스할 수 있는 원격화 메카니즘을 제공한다. 하나의 예시적인 관리 도구 프레임워크에서, 원격화 메카니즘은 다수의 독립 제어 도메인을 연결하는 기반구조에 의존하는 연합 서비스들을 지원한다. 원격화 메카니즘은 스크립트들이 원격 컴퓨팅 장치에서 실행되는 것을 허용한다. 스크립트들은 단일 또는 다수의 원격 시스템에서 실행될 수 있다. 스크립트들의 결과들은 각각의 개별 스크립트가 완료될 때 처리되거나, 다양한 컴퓨팅 장치 상의 모든 스크립트들이 완료된 후에 모아져서 한꺼번에 처리될 수 있다.

예를 들어, 호스트 컴포넌트들(202) 중 하나로서 도시된 웹 서비스(204)는 원격 에이젼트일 수 있다. 원격 에이젼트는 원격 명령 요구들을 타겟 시스템 상의 파서 및 관리 도구 프레임워크로 제출하는 것을 처리한다. 원격화 cmdlet는 원격 에이젼트에 대한 액세스를 제공하기 위한 원격 클라이언트로서 기능한다. 원격 에이젼트 및 원격화 cmdlet는 분석된 스트림을 통해 통신한다. 이러한 분석된 스트림은 보호 계층에서 보호되거나, 추가적인 cmdlet들이 분석된 스트림을 암호화한 후 해독하는 데 사용될 수 있다.

호스트 독립 컴포넌트

호스트 독립 컴포넌트(206)는 파서(220), 스크립트 엔진(222) 및 코어 엔진 (224)을 포함한다. 호스트 독립 컴포넌트(226)는 다수의 cmdlet를 그룹화하고, cmdlet들의 동작을 조정하고, 다른 자원들, 세션들 및 작업들과 cmdlet들의 상호작용을 조정하기 위한 메카니즘 및 서비스를 제공한다.

예시적인 파서

파서(220)는 다양한 호스트 프로그램으로부터 입력 요구를 수신하고, 예를 들어 코어 엔진(224) 내에서 관리 도구 프레임워크 전반에서 사용되는 균일한 cmdlet 객체들로 맵핑하기 위한 메카니즘을 제공한다. 또한, 파서(220)는 수신된 입력에 기초하여 데이타 처리를 수행할 수 있다. 입력에 기초하여 데이타 처리를 수행하는 하나의 예시적인 방법이 도 12와 관련하여 후술된다. 본 관리 도구 프레임워크의 파서(220)는 동일한 능력들을 위해 상이한 언어들 또는 신택스를 사용자들에게 쉽게 표시할 수 있는 능력을 제공한다. 예를 들어, 파서(220)는 입력 요구의 해석을 담당하므로, 예측되는 입력 신택스에 영향을 미치는 파서(220) 내의 코드에 대한 변경은 본질적으로 관리 도구 프레임워크의 각 사용자에게 영향을 미친다. 따라서, 시스템 관리자들은 상이한 신택스를 지원하는 상이한 컴퓨팅 장치들 상에 상이한 파서들을 제공할 수 있다. 그러나, 동일 파서와 함께 동작하는 각각의 사용자는 각각의 cmdlet에 대한 일관된 신택스를 경험하게 된다. 이와 달리, 통상의 환경에서는, 각각의 환경이 여러 상이한 신택스를 지원했으며, 대개 이들 중 다수는 서로 모순되었다.

예시적인 스크립트 엔진

스크립트 엔진(222)은 스크립트를 사용하여 다수의 cmdlet를 함께 결합할 수 있는 메카니즘 및 서비스를 제공한다. 스크립트는 엄격한 상속 규칙들 하에 세션 상태를 공유하는 명령 라인들의 집합이다. 스크립트 내의 다수의 명령 라인은 입력 요구에서 제공되는 신택스에 기초하여 동기적으로 또는 비동기적으로 실행될 수 있다. 스크립트 엔진(222)은 루프 및 조건부 절과 같은 제어 구조를 처리하고, 스크립트 내의 변수들을 처리할 수 있는 능력을 갖는다. 스크립트 엔진은 또한 세션 상태를 관리하며, cmdlet들에게 정책(도시되지 않음)에 기초한 세션 데이타에 대한 액세스를 제공한다.

예시적인 코어 엔진

코어 엔진(224)은 파서(220)에 의해 식별되는 cmdlet들의 처리를 담당한다. 도 4를 참조하면, 관리 도구 프레임워크(200) 내의 예시적인 코어 엔진(224)이 도시되어 있다. 예시적인 코어 엔진(224)은 파이프라인 프로세서(402), 로더(404), 메타데이타 프로세서(406), 에러 및 이벤트 핸들러(408), 세션 관리자(410) 및 확장 타입 관리자(412)를 포함한다.

예시적인 메타데이타 프로세서

메타데이타 프로세서(406)는 도 3에 도시된 데이타베이스 스토어(314)와 같은 메타데이타 스토어 내의 메타데이타에 액세스하고 저장하도록 구성되어 있다. 메타데이타는 cmdlet 클래스 정의 등에 명령 라인을 통해 제공될 수 있다. 관리 도구 프레임워크(200) 내의 상이한 컴포넌트들은 그들의 처리를 수행할 때 메타데이타를 요구할 수 있다. 예를 들어, 파서(202)는 명령 라인 상에 제공되는 파라미터들을 검증하기 위해 메타데이타를 요구할 수 있다.

예시적인 에러 및 이벤트 프로세서

에러 및 이벤트 프로세서(408)는 명령라인의 처리 동안 각각의 에러 발생에 대한 정보를 저장하기 위한 에러 객체를 제공한다. 본 관리 도구 프레임워크에 특히 적합한 특정 에러 및 이벤트 프로세서에 대한 추가적인 정보를 위해, 본 발명과 동일한 양수인에 의해 소유되고 본 명세서에 참고로 반영된 "명령 라인 환경에서 에러 정보를 유지하기 위한 시스템 및 방법"이라는 제목을 가진 미국 특허 출원 제_호/제_호를 참조하라.

예시적인 세션 관리자

세션 관리자(410)는 세션 및 상태 정보를 관리 도구 프레임워크(200) 내의 다른 컴포넌트들에 제공한다. 세션 관리자에 의해 관리되는 상태 정보는 프로그래밍 인터페이스를 통해 임의의 cmdlet, 호스트 또는 코어 엔진에 의해 액세스될 수 있다. 이러한 프로그래밍 인터페이스는 상태 정보의 생성, 변경 및 삭제를 허용한다.

예시적인 파이프라인 프로세서 및 로더

로더(404)는 파이프라인 프로세서(402)가 cmdlet를 실행할 수 있도록 각각의 cmdlet를 메모리에 로딩하도록 구성되어 있다. 파이프라인 프로세서(402)는 cmdlet 프로세서(420) 및 cmdlet 관리자(422)를 포함한다. cmdlet 프로세서(420)는 개별 cmdlet들을 디스패치한다. cmdlet가 하나의 원격 머신 또는 한 세트의 원격 머신들 상에서의 실행을 요구하는 경우, cmdlet 프로세서(420)는 도 2에 도시된 원격화 cmdlet(236)로 실행을 조정한다. cmdlet 관리자(422)는 cmdlet들의 집합의 실행을 처리한다. cmdlet 관리자(422), cmdlet 프로세서(420) 및 스크립트 엔진(222)(도 2)은 호스트 프로그램(210-214)으로부터 수신되는 입력에 대한 처리를 수행하기 위해 서로 통신한다. 통신은 사실상 회귀적일 수 있다. 예를 들어, 호스트 프로그램이 스크립트를 제공하는 경우, 이 스크립트는 그 자체가 스크립트일 수 있는 cmdlet를 처리하기 위해 cmdlet 관리자(422)를 호출할 수 있다. 이어서, 스크립트는 스크립트 엔진(222)에 의해 실행될 수 있다. 코어 엔진에 대한 하나의 예시적인 프로세스 흐름이 도 14와 관련하여 후술된다.

예시적인 확장 타입 관리자

전술한 바와 같이, 관리 도구 프레임워크는 객체들의 반사를 허용하고 그들의 (객체) 타입에 독립적으로 반사 객체들의 처리를 허용하는 한 세트의 유틸리티들을 제공한다. 관리 도구 프레임워크(200)는 이러한 반사를 수행하기 위하여 컴퓨팅 시스템 상의 컴포넌트 프레임워크(도 1의 컴포넌트 프레임워크 120)와 상호작용한다. 반사는 객체에 질의하여 객체에 대한 타입을 취득한 다음 그 객체 타입과 관련된 다양한 객체들 및 특성들에 반사시켜 다른 객체들 및/또는 원하는 값을 얻을 수 있는 능력을 제공한다는 것을 당업자는 이해할 것이다.

반사가 관리 도구 프레임워크(200)에게 객체들에 대한 많은 양의 정보를 제공하지만, 본 발명자는 반사가 객체의 타입에 집중한다는 점을 이해했다. 예를 들어, 데이타베이스 데이타 테이블이 반사될 때, 리턴되는 정보는 데이타 테이블이 열 특성 및 행 특성이라는 2개의 특성을 갖는다는 것이다. 이러한 2개의 특성은 데이타 테이블 내의 객체들에 관한 충분한 상세를 제공하지 못한다. 확장형 마크 업 언어(XML) 및 다른 객체들에 대해 반사가 사용될 때에도 유사한 문제가 발생한다.

따라서, 본 발명자는 타입의 사용에 집중하는 확장 타입 관리자(412)를 구상했다. 이러한 확장 타입 관리자에 대해, 객체의 타입은 중요하지 않다. 대신에, 확장 타입 관리자는 객체가 요구 정보를 얻는 데 사용될 수 있는지의 여부에 관심이 있다. 위의 데이타 테이블의 예로 계속하면, 본 발명자는 데이타 테이블이 행 특성 및 열 특성을 갖는다는 점을 아는 것은 특히 흥미롭지는 않으나, 하나의 행이 흥미로운 정보를 갖는다는 점을 인식했다. 사용에 집중할 경우, 각각의 행을 하나의 객체에 연관시키고, 각각의 열을 그 객체의 특성에 연관시킬 수 있다. 따라서, 확장 타입 관리자(412)는 임의 타입의 정밀하게 분석할 수 있는 입력으로부터 객체들을 생성할 수 있는 메카니즘을 제공한다. 이를 행함에 있어서, 확장 타입 관리자(412)는 컴포넌트 기반 프레임워크(120)에 의해 제공되는 반사 능력을 보충하며, 임의 타입의 정밀하게 분석할 수 있는 입력으로 반사를 확장한다.

개략적으로, 확장 타입 관리자는 정밀하게 분석할 수 있는 입력(도시되지 않음)에 액세스하여, 이 정밀하게 분석할 수 있는 입력을 요구 데이타 타입과 상관시키도록 구성되어 있다. 이어서, 확장 타입 관리자(412)는 요구 정보를 파이프라인 프로세서(402) 또는 파서(220)와 같은 요구 컴포넌트에 제공한다. 아래의 설명에서, 정밀하게 분석할 수 있는 입력은 특성들 및 값들이 식별될 수 있는 입력으로서 정의된다. 몇몇 예시적인 정밀 분석 가능한 입력은 윈도우 관리 계기(WMI) 입력, ActiveX 데이타 객체(ADO) 입력, 확장형 마크업 언어(XML) 입력, 및 .NET 객체들과 같은 객체 입력을 포함한다. 다른 정밀 분석 가능한 입력은 삼자 데이타 포맷을 포함할 수 있다.

도 18을 참조하면, 관리 도구 프레임워크에서 사용하기 위한 예시적인 확장 타입 관리자의 기능 블록도가 도시되어 있다. 설명을 위해, 확장 타입 관리자에 의해 제공되는 기능(원 내의 번호 3으로 표시)은 통상의 긴밀 결합 시스템(tightly bound system)에 의해 제공되는 기능(원 내의 번호 1로 표시) 및 반사 시스템에 의해 제공되는 기능(원 내의 번호 2로 표시)과 대비되어 있다. 통상의 긴밀 결합 시스템에서, 애플리케이션 내의 호출자(1802)는 객체 A 내의 정보(예를 들어, 특성들 P1 및 P2, 메소드들 M1 및 M2)에 직접 액세스한다. 전술한 바와 같이, 호출자(1802)는 컴파일 시간에 객체 A에 의해 제공되는 특성들(예를 들어, 특성들 P1 및 P2) 및 메소드들(예를 들어, 메소드들 M1 및 M2)을 연역적으로 알고 있어야 한다. 반사 시스템에서, 포괄 코드(1820)(임의의 데이타 타입에 종속되지 않음)는 시스템(1808)에 질의하며, 이 시스템은 요구된 객체 상에 반사(1810)를 수행하고 그 객체(예를 들어, 객체 A)에 대한 정보(예를 들어, 특성들 P1 및 P2, 메소드들 M1 및 M2)를 포괄 코드(1820)로 리턴한다. 객체 A에 도시되지 않았지만, 리턴되는 정보는 벤더, 파일, 날짜 등과 같은 추가 정보를 포함할 수 있다. 따라서, 반사를 통해, 포괄 코드(1820)는 긴밀 결합 시스템이 제공하는 것과 적어도 동일한 정보를 취득한다. 반사 시스템은 또한 호출자(1802)가 시스템에 질의하여, 파라미터들에 대한 어떠한 연역적 지식 없이도 추가 정보를 얻는 것을 허용한다.

긴밀 결합 시스템 및 반사 시스템 양자에서, 새로운 데이타 타입들은 동작 환경 내에 쉽게 포함될 수 없다. 예를 들어, 긴밀 결합 시스템에서, 동작 환경이 일단 전달되면, 동작 환경은 새로운 데이타 타입들을 포함시킬 수 없는데, 이는 이것을 지원하기 위해서는 동작 환경이 재구축되어야 하기 때문이다. 마찬가지로, 반사 시스템에서, 각각의 객체 클래스에 대한 메타데이타는 고정된다. 따라서 새로운 데이타 타입들의 포함은 대개 이루어지지 않는다.

그러나, 본 발명의 확장 타입 관리자에 대해서는 새로운 데이타 타입들이 운영 체제에 포함될 수 있다. 확장 타입 관리자(1822)에 대해, 포괄 코드(1820)는 삼자 객체(예를 들어, 객체 A' 및 B), 시맨틱 웹(1832), 온톨로지(ontology) 서비스(1834) 등과 같은 다양한 외부 소스에 의해 제공되는 확장 데이타 타입들(예를 들어, 객체 A')을 얻기 위해 요구 객체 상에 반사될 수 있다. 도시된 바와 같이, 삼자 객체는 기존의 객체(예를 들어, 객체 A')를 확장하거나, 전혀 새로운 객체(예를 들어, 객체 B)를 생성할 수 있다.

확장 소스들 각각은 그들의 고유 구조를 타입 메타데이타(1840) 내에 등록하고 코드(1842)를 제공할 수 있다. 객체가 질의될 때, 확장 타입 관리자는 객체가 등록되어 있는지를 판정하기 위해 타입 메타데이타(1840)를 검토한다. 객체가 타입 메타데이타(1840) 내에 등록되지 않은 경우, 반사가 수행된다. 등록되어 있는 경우, 확장 반사가 수행된다. 코드(1842)는 반사되고 있는 타입과 관련된 추가적인 특성 및 메소드를 리턴한다. 예를 들어, 입력 타입이 XML인 경우, 코드(1842)는 XML이 XML 문서로부터 객체를 생성하는 데 사용되는 방식을 설명하는 설명 파일을 포함할 수 있다. 따라서, 타입 메타데이타(1840)는 확장 타입 관리자(412)가 특정 입력 타입의 객체를 생성하기 위한 원하는 특성을 얻기 위하여 다양한 타입의 정밀 분석 가능 입력(예를 들어, 삼자 객체들 A' 및 B, 시맨틱 웹 1832)에 어떻게 질의해야 하는지를 설명하며, 코드(1840)는 이러한 원하는 특성을 얻을 수 있는 명령을 제공한다. 결과적으로, 확장 타입 관리자(412)는 모든 타입의 객체들 상에서의 반사를 허용하는 간접 계층을 제공한다.

확장 타입을 제공하는 것 외에, 확장 타입 관리자(412)는 특성 경로 메카니즘, 키 메카니즘, 비교 메카니즘, 변환 메카니즘, 글로벌 메카니즘, 특성 세트 메카니즘, 관계 메카니즘 등과 같은 추가적인 질의 메카니즘들을 제공한다. "예시적인 확장 타입 관리자 처리" 섹션에서 후술되는 이러한 질의 메카니즘들 각각은 명령 스트링을 입력할 때 시스템 관리자들에게 유연성을 제공한다. 확장 타입 관리자에 대한 시맨틱을 구현하기 위해 다양한 기술이 사용될 수 있다. 3가지 기술이 후술된다. 그러나, 특허 청구된 발명의 사상으로부터 벗어나지 않고도 이러한 기술들에 대한 변형들이 사용될 수 있다는 것을 당업자는 이해할 것이다.

하나의 기술에서, 정적 메소드(예를 들어, getproperty())를 가진 일련의 클래스들이 제공될 수 있다. 객체가 정적 메소드(예를 들어, getproperty(object))로 입력되고, 정적 메소드는 한 세트의 결과를 리턴한다. 다른 기술에서, 동작 환경은 어댑터로 객체를 엔빌로프한다. 따라서, 입력이 제공되지 않는다. 어댑터의 각각의 인스턴스는 엔빌로프된 객체 상에서 동작하고 엔빌로프된 객체에 대한 특성을 리턴하는 getproperty 메소드를 갖는다. 다음은 이 기술을 설명하는 의사 코드이다.

Class Adaptor

{

Object X;

getProperties();

}

또 다른 기술에서, 어댑터 클래스는 객체를 서브 클래스화한다. 통상적으로, 서브 클래스화는 컴파일 전에 발생한다. 그러나, 소정의 동작 환경에서는 서브 클래스화가 동적으로 발생할 수 있다. 이러한 타입의 환경에서, 다음은 이 기술을 설명하는 의사 코드이다.

Class Adaptor:A

{

getProperties()

{

return data;

}

따라서, 도 18에 도시된 바와 같이, 확장 타입 관리자는 개발자들이 새로운 데이타 타입을 생성하고, 이 데이타 타입을 등록하고, 다른 애플리케이션들 및 cmdlet들이 이 새로운 데이타 타입을 사용하는 것을 허용하는 것을 가능하게 한다. 대조적으로, 종래의 관리 환경에서는,데이타 타입으로부터 인스턴스화된 객체와 관 련된 특성 또는 메소드가 직접 액세스될 수 있기 위해서 각각의 데이타 타입은 컴파일 시간에 알려져 있어야 했다. 따라서, 과거에는 관리 환경에 의해 지원되는 새로운 데이타 타입의 추가는 좀처럼 행해지지 않았다.

도 2를 다시 참조하면, 개략적으로 관리 도구 프레임워크(200)는 사용자들에 의하여 입력된 명령들의 실행을 조정하기 위해 쉘에 의존하기보다는 기능을 처리부(예를 들어, 호스트 독립 컴포넌트 206) 및 사용자 상호작용부(예를 들어, 호스트 cmdlet를 통해)로 분할한다. 또한, 본 관리 도구 환경은 관리 도구의 프로그래밍을 크게 간략화하는데, 이는 분석 및 데이타 검증에 필요한 코드가 각각의 명령 내에 더 이상 포함되지 않고 오히려 관리 도구 프레임워크 내의 컴포넌트들(예를 들어, 파서 220)에 의해 제공되기 때문이다. 관리 도구 프레임워크 내에서 수행되는 예시적인 처리는 후술된다.

예시적인 동작

도 5-7은 관리 도구 환경에서 사용되는 예시적인 데이타 구조를 나타낸다. 도 8-17은 관리 도구 환경에서의 예시적인 처리 흐름을 나타낸다. 본 발명의 범위를 벗어나지 않고도 후술되는 컴포넌트와 다른 컴포넌트에 의해 소정의 처리가 수행될 수 있다는 것을 당업자는 이해할 것이다. 관리 도구 프레임워크의 컴포넌트들에서 수행되는 처리를 설명하기 전에, 관리 도구 프레임워크에서 사용되는 예시적인 데이타 구조가 설명된다.

cmdlet 객체에 대한 예시적인 데이타 구조

도 5는 도 2에 도시된 관리 도구 프레임워크에서 사용하기에 적합한 cmdlet 를 지정하기 위한 예시적인 데이타 구조이다. 완료시, cmdlet는 관리 cmdlet, 비관리 cmdlet, 호스트 cmdlet, 제공자 cmdlet 등일 수 있다. 다음은 시스템 관리자의 관점에 관련된 cmdlet(즉, 제공자 cmdlet)의 생성을 설명한다. 그러나, 각 타입의 cmdlet는 동일 방식으로 생성되고, 유사한 방식으로 동작한다. cmdlet는 C#과 같은 임의의 언어로 작성될 수 있다. 또한, cmdlet는 스크립팅 언어 등을 이용하여 작성될 수 있다. 관리 도구 환경이 .NET 프레임워크와 함께 동작할 때, cmdlet는 .NET 객체일 수 있다.

제공자 cmdlet(500)(이하, cmdlet 500으로 지칭됨)는 cmdlet 클래스 명칭(예를 들어, StopProcess 504)을 가진 공개 클래스이다. cmdlet(500)는 cmdlet 클래스(506)로부터 도출된다. cmdlet 클래스(506)에 대한 예시적인 데이타 구조가 도 6과 관련하여 후술된다. 각각의 cmdlet(500)는 명칭(예를 들어, Stop/Process)을 cmdlet(500)와 연관시키는 명령 속성(502)와 연관된다. 명칭은 관리 도구 환경 내에 등록된다. 후술하는 바와 같이, 파서는 명칭(예를 들어, Stop/Process)을 가진 명령 스트링이 명령 라인 상에 또는 스크립트 내에 입력으로서 제공될 때 cmdlet(500)를 식별하기 위해 cmdlet 레지스트리를 검사한다.

cmdlet(500)는 cmdlet에 대한 예측 입력 파라미터들에 대한 문법을 정의하는 문법 메카니즘과 연관된다. 문법 메카니즘은 cmdlet와 직접 또는 간접적으로 연관될 수 있다. 예를 들어, cmdlet(500)는 직접적인 문법 연관성을 나타낸다. 이 cmdlet(500)에서, 하나 이상의 공개 파라미터(예를 들어, ProcessName 510 및 PID 512)가 선언된다. 공개 파라미터의 선언은 입력 객체들의 분석을 cmdlet(500)로 구동한다. 대안으로, 파라미터들에 대한 설명은 XML 문서와 같은 외부 소스에 나타날 수 있다. 이 외부 소스의 파라미터 설명은 입력 객체들에 대한 분석을 cmdlet로 구동한다.

각각의 공개 파라미터(510, 512)는 그와 관련된 하나 이상의 속성(즉, 지령)을 가질 수 있다. 지령들은 다음의 카테고리들, 즉 분석 지령(521), 데이타 검증 지령(552), 데이타 생성 지령(523), 처리 지령(524), 인코딩 지령(525) 및 문서화 지령(526) 중 임의의 것일 수 있다. 지령들은 대괄호 안에 표시될 수 있다. 각각의 지령은 다음의 예측 입력 파라미터 상에 수행될 동작을 설명한다. 지령들의 일부는 사용자 인터페이스 타입 지령들과 같이 클래스 레벨에 적용될 수도 있다. 지령들은 cmdlet와 연관된 메타데이타 내에 저장된다. 이러한 속성들의 적용은 도 12와 관련하여 후술한다.

이러한 속성들은 또한 cmdlet 내에 선언된 파라미터들의 팝퓰레이션에 영향을 미칠 수 있다. 이러한 파라미터들을 팝퓰레이트하기 위한 하나의 예시적인 프로세스가 도 16과 관련하여 후술된다. 코어 엔진은 컴플라이언스를 보장하기 위하여 이러한 지령들을 이용할 수 있다. cmdlet(500)는 제1 메소드(530)(이하, StartProcessing 메소드 530으로도 지칭됨) 및 제2 메소드(540)(이하, processRecord 메소드 540으로도 지칭됨)를 포함한다. 코어 엔진은 cmdlet(500)의 처리를 지시하기 위해 제1 및 제2 메소드(530, 540)를 사용한다. 예를 들어, 제1 메소드(530)는 한번 실행되어 셋업 기능을 수행한다. 제2 메소드(540) 내의 코드(542)는 cmdlet(500)에 의해 처리되어야 하는 각 객체(예를 들어, 레코드)에 대해 실행된다. cmdlet(500)는 또한 cmdlet(500) 후에 소거되는 제3 메소드(도시되지 않음)를 포함할 수 있다.

따라서, 도 5에 도시된 바와 같이, 제2 메소드(540) 내의 코드(542)는 일반적으로 아주 간단하며, 분석 코드, 데이타 검증 코드 등과 같이 통상의 관리 도구 환경에서 요구되는 기능을 포함하지 않는다. 따라서, 시스템 관리자들은 복잡한 프로그래밍 언어를 배우지 않고도 복잡한 관리 작업을 개발할 수 있다.

도 6은 도 5에 도시된 cmdlet가 도출되는 cmdlet 기본 클래스(602)를 지정하기 위한 예시적인 데이타 구조(600)이다. cmdlet 기본 클래스(602)는 cmdlet가 후크 명령문을 포함하고 대응 스위치가 명령 라인 상에 또는 스크립트 내에(이들은 함께 명령 입력으로 지칭됨) 입력될 때마다 추가 기능을 제공하는 명령들을 포함한다.

예시적인 데이타 구조(600)는 Boolean parameter vorbose(610), whatif(620) 및 confirm(630)과 같은 파라미터들을 포함한다. 후술하는 바와 같이, 이들 파라미터는 명령 입력 상에 입력될 수 있는 스트링들에 대응한다. 예시적인 데이타 구조(600)는 또한 실행이 요구되고 있는 작업이 허용되는지를 판정하는 보안 메소드(640)를 포함할 수 있다.

도 7은 cmdlet를 지정하기 위한 다른 예시적인 데이타 구조(700)이다. 개략적으로 데이타 구조(700)는 관리 도구 프레임워크와 cmdlet 사이의 약정을 명백히 표현하기 위한 수단을 제공한다. 데이타 구조(500)와 마찬가지로, 데이타 구조(700)는 cmdlet 클래스(704)로부터 도출되는 공개 클래스이다. 소프트웨어 개발자 는 "get/process" 및 "format/table"와 같은 명사/동사 쌍을 cmdlet(700)와 연관시키는 cmdletDeclaration(702)을 지정한다. 명사/동사 쌍은 관리 도구 환경 내에 등록된다. 동사 또는 명사는 cmdlet 명칭에서 암시적일 수 있다. 또한, 데이타 구조(500)와 마찬가지로, 데이타 구조(700)는 데이타 구조(500)와 관련하여 설명된 하나 이상의 지령들(520-526)과 연관될 수 있는 하나 이상의 공개 멤버들(예를 들어, Name 730, Recurse 732)을 포함할 수 있다.

그러나, 이 예시적인 데이타 구조(700)에서, 예측 입력 파라미터들(730, 732) 각각은 입력 속성들(731, 733)과 각각 연관된다. 입력 속성들(731, 733)은 그의 각각의 파라미터(730, 732)에 대한 데이타가 명령 라인으로부터 얻어져야 하는 것으로 지정한다. 따라서, 이 예시적인 데이타 구조(700)에서는, 다른 cmdlet에 의해 발행된 파이프라인 객체로부터 팝퓰레이트되는 어떠한 예측 입력 파라미터도 존재하지 않는다. 따라서, 데이타 구조(700)는 cmdlet 기본 클래스에 의해 제공되는 제1 메소드(예를 들어, StartProcessing) 또는 제2 메소드(예를 들어, ProcessRecord)를 무시하지 못한다.

데이타 구조(700)는 또한 입력 파라미터로서 인식되지 않는 비밀 멤버(740)를 포함할 수 있다. 비밀 멤버(740)는 지령들 중 하나에 기초하여 생성되는 데이타를 저장하는 데 사용될 수 있다.

따라서, 데이타 구조(700)에 도시된 바와 같이, 특정 cmdlet 클래스 내의 공개 특성 및 지령 선언의 이용을 통해, cmdlet 개발자들은 그들의 cmdlet들의 예측 입력 파라미터들에 대한 문법을 쉽게 지정하고, cmdlet 개발자들이 어떠한 기본 논 리를 생성할 것을 요구하지 않고 예측 입력 파라미터들 상에 수행되어야 할 처리를 지정할 수 있다. 데이타 구조(700)는 cmdlet와 문법 메카니즘 사이의 직접 연관을 나타낸다. 전술한 바와 같이, 이러한 연관은 예를 들어 XML 문서와 같은 외부 소스 내의 예측 파라미터 정의를 지정함으로써 간접적이 될 수도 있다.

이제, 관리 도구 환경에서의 예시적인 처리 흐름이 설명된다.

예시적인 호스트 처리 흐름

도 8은 도 2에 도시된 관리 도구 프레임워크에서 수행되는 호스트 처리를 위한 예시적인 프로세스를 나타내는 논리 흐름도이다. 프로세스(800)는 블록 801에서 시작하여, 특정 애플리케이션에 대한 관리 도구 환경을 개시하기 위한 요구가 수신된다. 요구는 애플리케이션 아이콘의 선택과 같이 키보드 입력을 통해 로컬하게 전송되거나, 다른 컴퓨팅 장치의 웹 서비스 인터페이스를 통해 원격적으로 전송될 수 있다. 어느 시나리오에서나 처리 블록 802로 계속된다.

블록 802에서, 타겟 컴퓨팅 장치 상의 특정 애플리케이션(예를 들어, 호스트 프로그램)은 그의 환경을 셋업한다. 이것은 cmdlet들(예를 들어, 관리 cmdlet 232, 비관리 cmdlet 234) 및 호스트 cmdlet 218)의 어떠한 서브세트가 사용자에게 이용될 수 있는지를 판정하는 것을 포함한다. 일반적으로, 호스트 프로그램은 모든 비관리 cmdlet(234) 및 그 자신의 호스트 cmdlet(218)가 이용될 수 있도록 한다. 또한, 호스트 프로그램은 프로세스, 디스크 등을 처리하는 cmdlet들과 같은 관리 cmdlet(234)의 서브세트가 이용될 수 있도록 한다. 따라서, 호스트 프로그램이 cmdlet들 중 서브세트가 이용될 수 있게 하면, 관리 도구 프레임워크는 대응하 는 애플리케이션 내에 효과적으로 삽입된다. 처리는 블록 804로 계속된다.

블록 804에서, 특정 애플리케이션을 통해 입력이 얻어진다. 전술한 바와 같이, 입력은 명령 라인, 스크립트, 음성, GUI 등과 같은 여러 형태를 취할 수 있다. 예를 들어, 입력이 명령 라인을 통해 얻어질 때, 입력은 키보드 상에 입력된 키 스트로크로부터 검색 수취된다. GUI 호스트에 대해, 스트링이 GUI에 기초하여 구성된다. 처리는 블록 806으로 계속된다.

블록 806에서, 입력은 처리를 위해 관리 도구 프레임워크 내의 다른 컴포넌트로 제공된다. 호스트 프로그램은 입력은 파서와 같은 다른 컴포넌트로 직접 전송할 수 있다. 대안으로, 호스트 프로그램은 그의 호스트 cmdlet들 중 하나를 통해 입력을 전송할 수 있다. 호스트 cmdlet는 그의 특정 타입의 입력(예를 들어, 음성)을 관리 도구 프레임워크에 의해 인식되는 입력 타입(예를 들어, 텍스트 스트링, 스크립트)으로 변환할 수 있다. 예를 들어, 음성 입력은 음성 입력의 내용에 따라 스크립트 또는 명령 라인 스트링으로 변환될 수 있다. 각각의 호스트 프로그램은 그들의 입력 타입을 관리 도구 프레임워크에 의해 인식되는 입력으로 변환하는 것을 담당하므로, 관리 도구 프레임워크는 임의 수의 다양한 호스트 컴포넌트로부터 입력을 수신할 수 있다. 또한, 관리 도구 프레임워크는 입력이 그의 cmdlet들 중 하나를 통해 전송될 때 데이타 타입들 사이의 변환을 수행하는 풍부한 유틸리티 세트를 제공한다. 다른 컴포넌트들에 의해 입력 상에 수행되는 처리는 여러 다른 도면들과 관련하여 후술한다. 호스트 처리는 판정 블록 808로 계속된다.

판정 블록 808에서, 추가 입력에 대한 요구가 수신되었는지에 대한 판정이 이루어진다. 이것은 입력의 처리를 담당하는 다른 컴포넌트들 중 하나가 그의 처리를 완료하기 위해 사용자로부터의 추가 정보를 필요로 하는 경우에 발생할 수 있다. 예를 들어, 소정의 데이타에 액세스하기 위한 패스워드가 요구될 수 있고, 특정 액션들의 확인이 필요할 수 있다. 소정 타입의 호스트 프로그램(예를 들어, 음성 메일)에 대해, 이와 같은 요구는 적절하지 않을 수 있다. 따라서, 추가 정보를 위해 사용자에게 질의하는 대신에, 호스트 프로그램은 상태를 일련화하고, 상태를 중지하고, 상태를 전송하여 나중에 상태가 재개되고, 입력의 실행이 계속되도록 할 수 있다. 다른 변형에 있어서, 호스트 프로그램은 소정의 기간 후에 디폴트 값을 제공할 수 있다. 추가 입력에 대한 요구가 수신되는 경우, 처리는 블록 804로 루프백되어, 추가 입력이 얻어진다. 이어서, 처리는 블록 806, 808을 통해 전술한 바와 같이 계속된다. 추가 입력에 대한 요구가 수신되지 않고 입력이 처리된 경우, 처리는 블록 810으로 계속된다.

블록 810에서, 관리 도구 프레임워크 내의 다른 컴포넌트들로부터 결과들이 수신된다. 결과들은 에러 메시지, 상태 등을 포함할 수 있다. 결과들은 관리 도구 프레임워크 내의 호스트 cmdlet에 의해 인식되고 처리되는 객체 형태이다. 후술하는 바와 같이, 각각의 호스트 cmdlet에 대해 작성된 코드는 매우 작다. 따라서, 개발 비용의 막대한 투자를 요구하지 않고도 풍부한 출력 세트가 표시될 수 있다. 처리는 블록 812로 계속된다.

블록 812에서, 결과들이 보여질 수 있다. 호스트 cmdlet는 결과들을 호스트 프로그램에 의해 지원되는 표시 스타일로 변환한다. 예를 들어, 리턴되는 객체는 아이콘, 바킹 독(barking dog) 등과 같은 그래픽 표현을 이용하여 GUI 호스트 프로그램에 의해 표시될 수 있다. 호스트 cmdlet는 데이타에 대한 디폴트 포맷 및 출력을 제공한다. 디폴트 포맷 및 출력은 도 19-23과 관련하여 후술하는 예시적인 출력 처리 cmdlet를 사용할 수 있다. 결과들이 선택적으로 표시된 후, 호스트 처리는 종료된다.

입력 처리를 위한 예시적인 프로세스 흐름

도 9는 도 2에 도시된 관리 도구 프레임워크에서 수행되는 입력 처리를 위한 예시적인 프로세스를 나타내는 논리 흐름도이다. 처리는 블록 901에서 시작하여, 입력이 호스트 프로그램을 통해 입력되고, 관리 도구 프레임워크 내의 다른 컴포넌트들로 전송된다. 처리는 블록 902로 계속된다.

블록 902에서, 입력이 호스트 프로그램으로부터 수신된다. 하나의 예시적인 관리 도구 프레임워크에서, 입력은 파서에 의해 수신되고, 이 파서는 추가 처리를 위해 입력을 해독하고 입력을 감독한다. 처리는 판정 블록 904로 계속된다.

판정 블록 904에서, 입력이 스크립트인지에 대한 판정이 이루어진다. 입력은 스크립트 또는 명령 라인을 나타내는 스트링(이하, 명령 스트링이라고 함)의 행태를 취할 수 있다. 명령 스트링은 함께 파이프라인화된 하나 이상의 cmdlet를 나타낼 수 있다. 관리 도구 프레임워크가 여러 상이한 호스트를 지원하지만, 각 호스트는 입력을 처리를 위해 스크립트 또는 명령 스트링으로서 제공한다. 후술하는 바와 같이, 스크립트와 명령 스트링 사이의 상호작용은 사실상 회귀적이다. 예를 들어, 스크립트는 cmdlet를 호출하는 라인일 수 있다. cmdlet 자체는 스크립트일 수 있다.

따라서, 판정 블록 904에서, 입력이 스크립트의 형태인 경우, 처리는 블록 906으로 계속되어, 스크립트의 처리가 수행된다. 그렇지 않은 경우, 처리는 블록 908로 계속되어, 명령 스트링에 대한 처리가 수행된다. 블록 906 또는 908에서 수행되는 처리가 종료되면, 입력의 처리는 종료된다.

예시적인 스크립트 처리

도 10은 도 9에 도시된 입력 처리를 위한 프로세스에서 사용하기에 적합한 스크립트를 처리하기 위한 프로세스를 나타내는 논리 흐름도이다. 프로세스는 블록 1001에서 시작되어, 입력이 스크립트로서 식별된다. 스크립트 엔진 및 파서는 아래의 기능을 수행하기 위해 서로 통신한다. 처리는 블록 1002로 계속된다.

블록 1002에서, 스크립트 상에 사전 처리가 수행된다. 간략히, 도 11을 참조하면, 스크립트 처리 프로세스(1000)에서 사용하기에 적합한 스크립트 사전 처리 프로세스(1100)를 나타내는 논리 흐름도가 도시되어 있다. 스크립트 사전 처리는 블록 1101에서 시작하고, 판정 블록 1102로 계속된다.

판정 블록 1102에서, 스크립트가 처음으로 실행되고 있는지에 대한 판정이 이루어진다. 이 판정은 레지스트리 또는 다른 저장 메카니즘으로부터 얻어지는 정보에 기초할 수 있다. 스크립트는 저장 메카니즘 내로부터 식별되며, 관련 데이타가 검토된다. 스크립트가 이전에 실행되지 않은 경우, 처리는 블록 1104로 계속된다.

블록 1104에서, 스크립트는 레지스트리에 등록된다. 이것은 스크립트에 대 한 정보가 관리 도구 프레임워크 내의 컴포넌트들에 의한 후속 처리를 위해 저장되는 것을 허용한다. 처리는 블록 1106으로 계속된다.

블록 1106에서, 스크립트로부터 헬프 및 문서가 추출되어 레지스트리에 저장된다. 또한, 이 정보는 관리 도구 프레임워크 내의 컴포넌트들에 의해 나중에 액세스될 수 있다. 스크립트는 이제 처리를 위해 준비되며, 도 10의 블록 1004로 리턴한다.

판정 블록 1102로 돌아가서, 스크립트가 이전에 실행된 것으로 프로세스가 판정하면, 처리는 판정 블록 1108로 계속된다. 판정 블록 1108에서, 처리 동안 스크립트가 실패했는지에 대한 판정이 이루어진다. 이 정보는 레지스트리로부터 얻어질 수 있다. 스크립트가 실패하지 않은 경우, 스크립트는 처리를 위해 준비되며, 도 10의 블록 1004로 리턴한다.

그러나, 스크립트가 실패한 경우, 처리는 블록 1110으로 계속된다. 블록 1110에서, 스크립트 엔진은 호스트 프로그램을 통해 사용자에게 스크립트가 이전에 실패하였다는 것을 통지할 수 있다. 이러한 통지는 사용자가 스크립트를 진행할 것인지 아니면 스크립트로부터 나갈 것인지를 결정하는 것을 허용한다. 도 8과 관련하여 전술한 바와 같이, 호스트 프로그램은 이러한 요구를 입력 스타일(예를 들어, 음성, 명령 라인)에 따라 다양한 방법으로 처리할 수 있다. 사용자로부터 추가 입력이 수신되면, 스크립트는 처리를 위해 도 10의 블록 1004로 리턴하거나 중지된다.

도 10의 블록 1004로 돌아가, 스크립트로부터의 라인이 검색된다. 처리는 판정 블록 1006으로 계속된다. 판정 블록 1006에서, 라인이 임의의 제한을 포함하는지에 대한 판정이 이루어진다. 제한은 소정의 시작 문자(예를 들어, 대괄호 "[") 및 대응 종료 문자(예를 들어, 대괄호 "]")에 의해 검출된다. 라인이 제한을 포함하는 경우, 처리는 블록 1008로 계속된다.

블록 1008에서, 라인 내에 포함된 제한이 적용된다. 일반적으로, 제한은 스크립트에 입력되는 파라미터에 대한 타입을 지정하고 파라미터 상에 수행되어야 하는 검증 논리를 지정하는 메카니즘을 관리 도구 프레임워크 내에 제공한다. 제한은 파라미터에 적용될 수 있을 뿐만 아니라, 변수들과 같은 스크립트 내에 입력되는 임의 타입의 구조에도 적용될 수 있다. 따라서, 제한은 데이타 타입을 지정하고 파라미터를 검증하는 메카니즘을 해석 환경 내에 제공한다. 통상의 환경에서, 시스템 관리자들은 스크립트 내에 입력되는 파라미터를 형식적으로 테스트할 수 없다. 제한을 적용하기 위한 예시적인 프로세스가 도 12에 도시되어 있다.

판정 블록 1010에서, 스크립트로부터의 라인이 내장된 능력들을 포함하는지에 대한 판정이 이루어진다. 내장 능력들은 코어 엔진에 의해 수행되지 않는 능력들이다. 내장 능력들은 cmdlet를 이용하여 처리되거나, 인라인 기능과 같은 다른 메카니즘을 이용하여 처리될 수 있다. 라인이 내장 능력을 갖지 않은 경우, 처리는 블록 1014로 계속된다. 그렇지 않은 경우, 처리는 블록 1012로 계속된다.

블록 1012에서, 스크립트의 라인 상에 제공된 내장 능력들이 처리된다. 내장 능력들의 예는 "If" 명령문, "for" 루프, 스위치 등과 같은 제어 구조의 실행을 포함할 수 있다. 내장 능력들은 또한 할당 타입 문장(예를 들어, a=3)을 포함할 수 있다. 내장 능력들이 처리된 경우, 처리는 판정 블록 1014로 계속된다.

판정 블록 1014에서, 스크립트의 라인이 명령 스트링을 포함하는지에 대한 판정이 이루어진다. 판정은 라인 상의 데이타가 등록된 명령 스트링, 및 잠재적인 cmdlet 호출의 신택스와 연관되어 있는지에 기초한다. 전술한 바와 같이, 명령 스트링 및 스크립트의 처리는 사실상 회귀적일 수 있는데, 이는 스크립트가 명령 스트링을 포함할 수 있고, 명령 스트링이 스크립트 자체인 cmdlet를 실행할 수 있기 때문이다. 라인이 명령 스트링을 포함하지 않는 경우, 처리는 판정 블록 1018로 계속된다. 그렇지 않은 경우, 처리는 블록 1016으로 계속된다.

블록 1016에서, 명령 스트링이 처리된다. 개략적으로, 명령 스트링의 처리는 파서에 의해 cmdlet 클래스를 식별하고 대응하는 cmdlet 객체를 실행을 위해 코어 엔진으로 전달하는 것을 포함한다. 명령 스트링은 또한 여러 개의 개별 cmdlet 객체들로 분해되고 코어 엔진에 의해 개별 처리되는 파이프라인 명령 스트링을 포함할 수 있다. 명령 스트링의 처리를 위한 하나의 예시적인 프로세스는 도 14에 관련하여 후술된다. 명령 스트링이 처리되면, 처리는 판정 블록 1018로 계속된다.

판정 블록 1018에서, 스크립트 내에 다른 라인이 존재하는지에 대한 판정이 이루어진다. 스크립트 내에 다른 라인이 존재하는 경우, 처리는 블록 1004로 루프백하여, 전술한 바와 같이 블록 1004-1016으로 진행한다. 그렇지 않은 경우, 처리는 종료된다.

블록 1008에서 제한을 적용하기 위한 예시적인 프로세스가 도 12에 도시되어 있다. 프로세스는 블록 1201에서 시작하여, 스크립트 내에서 또는 명령 라인 상의 명령 스트링에서 제한이 검출된다. 제한이 스크립트 내에 있는 경우, 제한 및 관련 구조는 동일 라인 상에 또는 개별 라인들 상에 발생할 수 있다. 제한이 명령 스트링 내에 있는 경우, 제한 및 관련 구조는 라인 표시자의 마지막(예를 들어, 엔터 키) 전에 발생한다. 처리는 블록 1202로 계속된다.

블록 1202에서, 제한은 해석 환경으로부터 얻어진다. 하나의 예시적인 관리 도구 환경에서, 파서는 입력을 해독하여, 제한의 발생을 판정한다. 제한은 다음의 카테고리, 즉 술어 지령, 분석 지령, 데이타 검증 지령, 데이타 생성 지령, 처리 지령, 인코딩 지령, 및 문서화 지령 중 하나일 수 있다. 하나의 예시적인 분석 신택스에 대해, 지령들은 대괄호 내에 있으며, 그들을 따르는 구조를 설명한다. 구조는 함수, 변수, 스크립트 등일 수 있다.

후술하는 바와 같이, 지령의 사용을 통해, 스크립트 저자들은 어떠한 기본 논리를 생성할 필요 없이 스크립트 또는 명령 라인(즉, 해석 환경) 내의 파라미터들을 쉽게 타이핑하고 그에 대한 처리를 수행할 수 있다. 처리는 블록 1204로 계속된다.

블록 1204에서, 얻어진 제한은 관련 구조에 대한 메타데이타에 저장된다. 관련 구조는 하나 이상의 속성 토큰(제한을 표시하는 토큰)을 만난 후에 제1 비속성 토큰인 것으로 식별된다. 처리는 블록 1206으로 계속된다.

블록 1206에서, 구조가 스크립트 내에서 또는 명령 스트링 내에서 만나질 때마다, 메타데이타 내에 정의된 제한이 구조에 적용된다. 제한은 데이타 타입, 술어 지령(1210), 문서화 지령(1212), 분석 지령(1214), 데이타 생성 지령(1216), 데 이타 검증 지령(1218) 및 객체 처리 및 인코딩 지령(1220)을 포함할 수 있다. 데이타 타입을 지정하는 제한은 관리 도구 프레임워크가 실행되고 있는 시스템에 의해 지원되는 임의의 데이타 타입을 지정할 수 있다. 술어 지령(1210)은 처리가 발생해야 하는지를 표시하는 지령이다. 따라서, 술어 지령(1210)은 환경이 실행을 위해 올바르다는 것을 보장한다. 예를 들어, 스크립트는 다음의 술어 지령을 포함할 수 있다:

[PredicateScript("isInstalled","ApplicationX"]

술어 지령은 올바른 애플리케이션이 스크립트를 실행하기 전에 컴퓨팅 장치 상에 설치되는 것을 보장한다. 일반적으로, 시스템 환경 변수는 술어 지령으로서 지정될 수 있다. 지령 타입들(1212-1220)로부터의 예시적인 지령들이 표 1-5에 나타나 있다. 이어서, 스크립트의 처리가 종료된다.

따라서, 해석 환경 내에 타입 및 제한을 적용하기 위한 본 프로세스는 시스템 관리자가 이 처리를 위한 기본 논리를 작성하지 않고도 쉽게 타입을 지정하고 검증 요건을 지정하는 것 등을 허용한다. 다음은 아래와 같이 지정된 명령 스트링 상에 수행되는 제한 처리의 예이다.

[Integer][ValidationRange(3,5)]$a=4

"[]"로 표시되는 속성 토큰을 통해 지정되는 2개의 제한이 존재한다. 제1 토큰 속성은 변수가 정수 타입임을 나타내고, 제2 속성 토큰은 변수 $a의 값이 3 내지 5이어야 한다는 것을 지시한다. 이 예시적인 명령 스트링은 변수 $a가 후속 명령 스트링 또는 라인 내에 할당되는 경우, 변수 $a는 2개의 제한에 대해 검사되 는 것을 보장한다. 따라서, 다음의 명령 스트링은 각각 에러를 유발할 것이다.

$a=231

$a="apple"

$a=$(get/location)

제한은 다양한 단계에서 관리 도구 프레임워크에 적용된다. 예를 들어, 적용성 지령, 문서화 지령, 및 분석 지침 지령은 파서 내에서 매우 이른 단계에서 처리된다. 데이타 생성 지령 및 검증 지령은 파서가 모든 입력 파라미터의 분석을 끝낸 경우에 엔진에서 처리된다.

다음 표들은 지령에 응답하여 관리 도구 환경에 의해 수행되는 처리의 설명과 함께 다양한 카테고리에 대한 대표적인 지령들을 나타낸다.

적용성 지령

명칭	설명
PrerequisiteMachineRoleAttribute	요소가 소정의 머신 역할들(예를 들어, 파일 서버, 메일 서버)에서만 사용되어야 하는지를 쉘에게 알린다.
PrerequisiteUserRoleAttribute	요소가 소정의 사용자 역할들(예를 들어, 도메인 관리자, 백업 오퍼레이터)에서만 사용되어야 하는지를 쉘에게 알린다.
PrerequisiteScriptAttribute	이 스크립트가 실제 명령 또는 파라미터를 실행하기 전에 실행된다는 것을 쉘에게 알린다. 파라미터 검증을 위해 사용될 수 있다.
PrerequisiteUITypeAttribute	이것은 실행 전에 사용자 인터페이스가 이용가능한지를 검사하기 위해 사용된다.

분석 지침 지령

명칭	설명
ParsingParameterPositionAttribute	위치에 기초하여 무자격 파라미터를 맵핑한다.
ParsingVariableLengthParameterListAttribute	분석 파라미터 위치 속성을 갖지 않은 파라미터를 맵핑한다.
ParsingDisallowInteractionAttribute	파라미터의 수가 요구된 수보다 적을 때의 액션을 지정한다.
ParsingRequireInteractionAttribute	파라미터들이 상호작용을 통해 얻어진다는 것을 지정한다.
ParsingHiddenElementAttribute	파라미터를 최종 사용자가 볼 수 없게 만든다.
ParsingMandatoryParameterAttribute	파라미터가 요구됨을 지정한다.
ParsingPasswordParameterAttribute	파라미터의 특수 처리를 요구한다.
ParsingPromptStringAttribute	파라미터에 대한 프롬프트를 지정한다.
ParsingDefaultAnswerAttribute	파라미터에 대한 디폴트 대답을 지정한다.
ParsingDefaultAnswerScriptAttribute	파라미터에 대한 디폴트 대압을 얻기 위한 액션을 지정한다.
ParsingDefaultValueAttribute	파라미터에 대한 디폴트 값을 지정한다.
ParsingDefaultValueScriptAttribute	파라미터에 대한 디폴트 값을 얻기 위한 액션을 지정한다.
ParsingParameterMappingAttribute	파라미터들을 그룹화하는 방법을 지정한다.
ParsingParameterDeclarationAttribute	필드가 파라미터임을 정의한다.
ParsingAllowPipelineInputAttribute	파라미터가 파이프라인으로부터 팝퓰레이트될 수 있음을 정의한다.

문서화 지령

명칭	설명
DocumentNameAttribute	상호작용 또는 도움을 위한 요소들을 참조할 수 있는 명칭을 제공한다.
DocumentShortDescriptionAttribute	요소에 대한 간단한 설명을 제공한다.
DocumentLongDescriptionAttribute	요소에 대한 상세한 설명을 제공한다.
DocumentExampleAttribute	요소의 예를 제공한다.
DocumentSeeAlsoAttribute	관련 요소들의 리스트를 제공한다.
DocumentSynopsisAttirbute	요소에 대한 문서화 정보를 제공한다.

데이타 검증 지령

명칭	설명
ValidationRangeAttribute	파라미터가 소정의 범위 내에 있어야 한다는 것을 지정한다.
ValidationSetAttribute	파라미터가 소정의 집합 내에 있어야 한다는 것을 지정한다.
ValidationPatternAttribute	파라미터가 소정의 패턴에 맞아야 한다는 것을 지정한다.
ValiidationLengthAttribute	스트링이 크기 범위 내에 있어야 한다는 것을 지정한다.
ValidationTypeAttribute	파라미터가 소정의 타입이어야 한다는 것을 지정한다.
ValidationCountAttribute	입력 항목들이 소정 수이어야 한다는 것을 지정한다.
ValidationFileAttribute	파일에 대한 소정의 특성을 지정한다.
ValidationFileAttributesAttribute	파일에 대한 소정의 특성을 지정한다.
ValidationFileSizeAttribute	파일들이 지정된 범위 내에 있어야 한다는 것을 지정한다.
ValidationNetworkAttribute	주어진 네트워크 엔티티가 소정의 특성을 지원한다는 것을 지정한다..
ValidationScriptAttribute	요소를 사용하기 전에 평가할 조건을 지정한다.
ValidationMethodAttribute	요소를 사용하기 전에 평가할 조건을 지정한다.

처리 및 인코딩 지령

명칭	설명
ProcessingTrimStringAttribute	스트링들에 대한 크기 제한을 지정한다.
ProcessingTrimCollectionAttribute	집합에 대한 크기 제한을 지정한다.
EncodingTypeCoercionAttribute	객체들이 인코딩될 타입을 지정한다.
ExpansionWildcardsAttribute	글로빙(globbing)을 허용하기 위한 메카니즘을 제공한다.

예시적인 관리 도구 프레임워크가 .NET 프레임워크 내에서 동작하고 있을 때, 각각의 카테고리는 기본 카테고리 클래스(예를 들어, CmdAttribute)로부터 도출되는 기본 클래스를 갖는다. 기본 카테고리 클래스는 System.Attribute 클래스로부터 도출된다. 각각의 카테고리는 카테고리 처리 동안에 파서에 의해 호출되는 사전 정의된 함수(예를 들어, attrib.func())를 갖는다. 스크립트 저자는 고객 카테고리 클래스(예를 들어, CmdCustomAttribute)로부터 도출되는 고객 카테고리를 생성할 수 있다. 스크립트 저자는 또한 지령 클래스를 그 카테고리에 대한 기본 카테고리 클래스로부터 도출함으로써 기존 카테고리 클래스를 확장하고, 이들의 구현과 함께 사전 정의된 함수를 무시할 수 있다. 스크립트 저자는 또한 지령들을 무시하고, 새로운 지령들을 사전 정의된 지령 세트에 추가할 수 있다.

이러한 지령들의 처리 순서는 파서에 의해 액세스될 수 있는 외부 데이타 스토어에 저장될 수 있다. 관리 도구 프레임워크는 등록된 카테고리들을 찾아, 그 카테고리 내의 지령들 각각에 대한 함수(예를 들어, ProcessCustomDirective)를 호출한다. 따라서, 카테고리 처리 순서는 카테고리 실행 정보를 지속적인 스토어에 저장함으로써 동적일 수 있다. 상이한 처리 단계들에서, 파서는 임의의 메타데이타 카테고리가 그 시간에 실행되어야 하는지를 판정하기 위해 지속 스토어 내부를 검사한다. 이것은 카테고리들이 지속 스토어로부터 카테고리 엔트리를 제거함으로써 쉽게 무시되는 것을 허용한다.

예시적인 명령 스트링 처리

명령 스트링 처리를 위한 하나의 예시적인 프로세스가 이제 설명된다. 도 13은 도 2에 도시된 관리 도구 프레임워크 내의 파서(220) 및 코어 엔진(224)을 통한 명령 스트링(1350)의 처리를 나타내는 기능 흐름도이다. 예시적인 명령 스트링(1350)은 여러 개의 명령들(즉, process 명령(1360), where 명령(1362), sort 명령(1364) 및 table 명령(1366))을 파이프라인화한다. 명령 라인(1350)은 입력 파라미터를 명령들 중 어느 하나에 전달할 수 있다(예를 들어, "handlecount>400"은 where 명령(1362)으로 전달된다). process 명령(1360)은 임의의 관련 입력 파라미터를 갖지 않는다는 점에 유의한다.

과거에는, 각각의 명령은 명령과 관련된 입력 파라미터들의 분석, 입력 파라미터들이 유효한지에 대한 판정, 및 입력 파라미터들이 유효하지 않은 경우의 에러 메시지의 발생을 담당하였다. 명령들은 일반적으로 다양한 프로그램들에 의해 작성되므로, 명령 라인 상의 입력 파라미터들에 대한 신택스는 매우 일관되지 않았다. 또한, 에러가 발생하는 경우, 심지어 동일 에러에 대한 에러 메시지도 명령들 사이에서 매우 일관되지 않았다.

예를 들어, UNIX 환경에서, Is 명령 및 ps 명령은 이들 사이에 많은 불일치를 갖는다. 양자가 옵션 "w"를 받을 때, "w" 옵션은 Is 명령에 의해 페이지의 폭을 표시하기 위해 사용되는 반면, ps 명령에 의해서는 프린트 폭 출력(본질적으로 페이지 폭 무시)을 표시하는 데 사용된다. Is 및 ps 명령과 관련된 헬프 페이지들도 하나에서는 옵션들이 볼드체이지만 다른 하나에서는 볼드체가 아니고, 하나에서는 옵션들이 알파벳 순으로 분류되지만 다른 하나에서는 그렇지 않고, 몇몇 옵션은 대쉬(dash)를 가져야 하지만 몇몇은 그렇지 않는 등 여러 불일치를 갖는다.

본 발명의 관리 도구 프레임워크는 보다 일관된 접근법을 제공하며, 각각의 개발자가 작성해야 하는 중복 코드의 양을 최소화한다. 관리 도구 프레임워크(200)은 신택스(예를 들어, 문법), 대응 시맨틱(예를 들어, 사전) 및 개발자들이 관리 도구 프레임워크(200)에 의해 제공되는 공통 기능을 쉽게 이용할 수 있게 하는 참조 모델을 제공한다.

본 발명을 더 설명하기 전에, 본 명세서 전반에 나오는 추가 용어들에 대한 정의가 제공된다. 입력 파라미터는 cmdlet에 대한 입력 필드를 지칭한다. 독립변수는 argv 어레이 내의 단일 스트링의 등가인 cmdlet로 전달되거나, cmdlet 객체 내에 단일 객체로서 전달되는 입력 파라미터를 지칭한다. 후술하는 바와 같이, cmdlet는 문법을 지정하기 위한 메카니즘을 제공한다. 메카니즘은 직접 또는 간접으로 제공될 수 있다. 독립변수는 옵션, 옵션 독립변수 또는 명령 명칭을 따르는 피연산자 중 하나이다. 독립변수의 예는 다음의 명령 라인에 기초하여 주어진다.

findstr/i/d:＼winnt;＼winnt＼system32aa*b*.ini

위의 명령 라인에서, findstr은 독립변수 0이고, /i는 독립변수 0이며, d:＼winnt;＼winnt＼system32는 독립변수 2이고, aa*b는 독립변수 3이며, *.ini는 독립변수 4이다. 옵션("option")은 프로그램의 디폴트 거동에 대한 변경을 지정하는 데 일반적으로 사용되는 cmdlet에 대한 독립변수이다. 위의 명령 라인 예에서 계속하면, /i 및 /d는 옵션들이다. 옵션 독립변수(option-argument)는 소정의 옵션을 따르는 입력 파라미터이다. 몇몇 경우에, option-argument는 동일 독립변수 스트링 내에 옵션으로 포함된다. 다른 경우에, option-argument는 다음 독립변수로서 포함된다. 위의 명령 라인을 다시 참조하면, ＼winnt;＼winnt＼system32는 옵션 독립변수이다. "operand"는 프로그램 처리를 완료하기 위해 필요한 정보를 프로그램에 제공하는 객체로서 일반적으로 사용되는 cmdlet에 대한 독립변수이다. 피연산자(operand)는 일반적으로 명령 라인 내의 옵션을 따른다. 위의 명령 라인 예를 참조하면, aa*b 및 *.ini는 피연산자들이다. "분석 가능한 스트림(parsable stream)"은 독립변수들을 포함한다.

도 13을 참조하면, 파서(220)는 분석 가능한 스트림(예를 들어, 명령 스트링 1350)을 구성 부분들(1320-1326)(예를 들어, where 부분 1322)로 분해한다. 각각의 부분(1320-1326)은 cmdlet들(1330-1336)과 연관된다. 파서(220) 및 엔진(224)은 분석, 파라미터 검증, 데이타 생성, 파라미터 처리, 파라미터 인코딩 및 파라미터 문서화와 같은 다양한 처리를 수행한다. 파서(220) 및 엔진(224)은 명령 라인 상의 입력 파라미터들 상에 공통 기능을 수행하므로, 관리 도구 프레임워크(200)는 사용자들에게 일관된 에러 메시지를 발행할 수 있다.

이해할 수 있듯이, 본 관리 도구 프레임워크에 따라 작성된 실행 가능 cmdlet들(1330-1336)은 종래의 관리 환경에서의 명령보다 작은 코드를 요구한다. 각각의 실행 가능 cmdlet(1330-1336)는 그의 각각의 구성 부분(1320-1326)을 이용하여 식별된다. 또한, 각각의 실행 가능 cmdlet(1330-1336)는 다음 파이프라인 cmdlet에 입력 객체(화살표 1341, 1343 및 1345로 표시됨)로서 입력되는 객체들(화살표 1340, 1342, 1344 및 1346으로 표시됨)을 출력한다. 이 객체들은 객체에 대한 참조(예를 들어, 핸들)를 전달함으로써 입력될 수 있다. 이어서, 실행가능 cmdlet들(1330-1336)은 전달된 객체들에 대한 추가 처리를 수행할 수 있다.

도 14는 도 9에 도시된 입력 처리를 위한 프로세스에서 사용하기에 적합한 명령 스트링들의 처리를 보다 상세히 나타내는 논리 흐름도이다. 명령 스트링 처리는 블록 1401에서 시작하여, 파서 또는 스크립트 엔진이 입력 내의 명령 스트링을 식별한다. 일반적으로, 코어 엔진은 cmdlet들의 데이타 흐름의 셋업 및 시퀀싱을 수행한다. 하나의 cmdlet에 대한 셋업 및 시퀀싱이 후술되지만, 파이프라인 내의 각각의 cmdlet에 대해 적용될 수 있다. 처리는 블록 1404로 계속된다.

블록 1404에서, cmdlet가 식별된다. cmdlet의 식별은 등록을 통해서 이루어질 수 있다. 코어 엔진은 cmdlet가 로컬인지 원격인지를 판정한다. cmdlet는 다음의 위치들, 즉 1) 관리 도구 프레임워크의 애플리케이션 도메인 내, 2) 관리 도구 프레임워크와 동일한 프로세스의 다른 애플리케이션 도메인 내, 3) 동일 컴퓨팅 장치 상의 다른 프로세스 내, 또는 4) 원격 컴퓨팅 장치 내에서 실행될 수 있다. 동일 프로세스 내에서 동작하는 cmdlet들 사이의 통신은 객체들을 통해 이루어진다. 다른 프로세스들 내에서 동작하는 cmdlet들 사이의 통신은 일련화되고 구조화된 데이타 포맷을 통해서 이루어진다. 하나의 예시적인 일련화되고 구조화된 데이타 포맷은 확장형 마크업 언어(XML)에 기초한다. 처리는 블록 1406으로 계속된다.

블록 1406에서, cmdlet 객체의 인스턴스가 생성된다. cmdlet의 인스턴스를 생성하기 위한 예시적인 프로세스가 도 15와 관련하여 후술된다. cmdlet 객체가 생성되면, 처리는 블록 1408로 계속된다.

블록 1408에서, cmdlet 객체와 관련된 특성들이 팝퓰레이트된다. 전술한 바와 같이, 개발자는 cmdlet 클래스 또는 외부 소스 내의 특성들을 선언한다. 간단히 말하면, 관리 도구 프레임워크는 특성에 대해 선언된 명칭 및 타입에 기초하여 cmdlet 클래스로부터 인스턴스화된 cmdlet로의 수신 객체(들)를 해독한다. 타입들이 상이한 경우, 타입은 확장 데이타 타입 관리자를 통해 관리될 수 있다. 전술한 바와 같이, 파이프라인 명령 스트링에서, 각 cmdlet의 출력은 객체들에 대한 핸들들의 리스트일 수 있다. 다음 cmdlet는 이 객체 핸들들의 리스트를 입력하고, 처리를 수행하고, 또 하나의 객체 핸들들의 리스트를 다음 cmdlet로 전달할 수 있다. 또한, 도 7에 도시된 바와 같이, 입력 파라미터들은 명령 라인으로부터 오는 것으로 지정될 수 있다. cmdlet와 관련된 특성들을 팝퓰레이트하기 위한 하나의 예시적인 방법은 도 16과 관련하여 후술된다. cmdlet가 팝퓰레이트되면, 처리는 블록 1410으로 계속된다.

블록 1410에서, cmdlet가 실행된다. 개략적으로, cmdlet에 의해 제공되는 처리는 적어도 한번 수행되는데, 이는 cmdlet로의 각 입력 객체에 대한 처리를 포함한다. 따라서, cmdlet가 파이프라인 명령 스트링 내의 제1 cmdlet인 경우, 처리는 한번 실행된다. 후속 cmdlet들에 대해, 처리는 cmdlet들로 전달되는 각 객체에 대해 실행된다. cmdlet들을 생성하기 위한 하나의 예시적인 방법이 도 5를 참조하여 후술된다. 입력 파라미터들이 명령 라인으로부터만 나오는 경우, cmdlet의 실행은 기본 cmdlet 케이스에 의해 제공되는 디폴트 메소드들을 사용한다. cmdlet의 실행이 종료되면, 처리는 블록 1412로 진행된다.

블록 1412에서, cmdlet가 소거된다. 이것은 메모리 등의 비할당(de-allocating)을 담당하는 관련 cmdlet 객체에 대한 소거자(destructor)를 호출하는 것을 포함한다. 이어서, 명령 스트링의 처리가 종료된다.

예시적인 cmdlet 객체 생성 프로세스

도 15는 도 14에 도시된 명령 스트링의 처리에 사용하기에 적합한 cmdlet 객체를 생성하기 위한 예시적인 프로세스를 나타내는 논리 흐름도이다. 이 시점에서, cmdlet 데이타 구조가 개발되었고, 속성들 및 예측 파라미터들이 지정되었다. cmdlet는 컴파일되었고 등록되었다. 등록 동안, 클래스 명칭(즉, cmdlet 명칭)이 등록 스토어 내에 작성되며, cmdlet와 관련된 메타데이타가 저장되었다. 프로세스(1500)는 블록 1501에서 시작하여, 파서가 cmdlet를 나타내는 입력(예를 들어, 키 스트로크)를 수신한다. 파서는 레지스트리 내로부터 입력을 탐색하고 입력을 등록된 cmdlet들 중 하나와 연관시킴으로써 입력을 cmdlet로서 인식할 수 있다. 처리는 블록 1504로 진행된다.

블록 1504에서, cmdlet 객체와 관련된 메타데이타가 판독된다. 메타데이타는 cmdlet와 관련된 지령들 중 어느 하나를 포함한다. 지령들은 cmdlet 자체에, 또는 파라미터들 중 하나 이상에 적용될 수 있다. cmdlet 등록 동안, 등록 코드는 메타데이타를 지속 스토어에 등록한다. 메타데이타는 일련화된 포맷의 XML 파일, 외부 데이타베이스 등에 저장될 수 있다. 스크립트 처리 동안의 지령들의 처리와 마찬가지로, 각 카테고리의 지령들은 상이한 단계에서 처리된다. 각각의 메타데이타 지령은 그 자신의 에러 핸들링을 행한다. 처리는 블록 1506으로 계속된다.

블록 1506에서, cmdlet 객체는 식별된 cmdlet 클래스에 기초하여 인스턴스화된다. 처리는 블록 1508로 계속된다.

블록 1508에서, cmdlet에 대한 정보가 취득된다. 이것은 반사 또는 다른 수단을 통해 발생할 수 있다. 정보는 예측 입력 파라미터에 대한 것이다. 전술한 바와 같이, 공개로서 선언되는 파라미터들(예를 들어, 공개 스트링 명칭(730))은 명령 라인 상의 명령 스트링에서 지정되거나 입력 스트림에서 제공될 수 있는 예측 입력 파라미터들에 대응한다. 관리 도구 프레임워크는 도 18에서 설명되는 확장 타입 관리자를 통해 정보를 (필요에 따라) 호출자에게 리턴하기 위한 공통 인터페이스를 제공한다. 처리는 블록 1510으로 계속된다.

블록 1510에서, 적용성 지령들(예를 들어, 표 1)이 적용된다. 적용성 지령들은 클래스가 소정의 머신 역할들 및/또는 사용자 역할로 사용되는 것을 보장한다. 예를 들어, 소정의 cmdlet들은 도메인 관리자에 의해서만 사용될 수 있다. 적용성 지령들 중 하나에서 지정되는 제한이 만족되지 않는 경우, 에러가 발생한다. 처리는 블록 1512로 계속된다.

블록 1512에서, 지능을 제공하기 위해 메타데이타가 사용된다. 이 처리 시점에서, 전체 명령 스트링은 아직 입력되지 않았다. 그러나, 관리 도구 프레임워크는 이용가능한 cmdlet들을 알고 있다. cmdlet가 결정된 경우, 관리 도구 프레임워크는 cmdlet 객체 상의 반사에 의해 허용되는 입력 파라미터들을 안다. 따라서, 관리 도구 프레임워크는, cmdlet의 명확한 부분이 제공되면 cmdlet를 자동 완성한 후, 입력 파라미터의 명확한 부분이 명령 라인 상에 타이핑되면 입력 파라미터를 자동 완성할 수 있다. 자동 완성은 상기 입력 파라미터 부분이 입력 파라미터들 중 하나를 명확하게 식별할 수 있게 되자마자 발생할 수 있다. 또한, 자동 완성은 cmdlet 명칭 및 피연산자에 대해서도 발생할 수 있다. 처리는 블록 1514로 계속된다.

블록 1514에서, 프로세스는 cmdlet에 대한 입력 파라미터들이 입력될 때까지 대기한다. 이것은 사용자가 예를 들어 리턴 키를 침으로써 명령 스트링의 끝을 표시한 경우에 발생할 수 있다. 스크립트에서, 새로운 라인은 명령 스트링의 끝을 나타낸다. 이러한 대기는 사용자로부터 파라미터들에 관한 추가 정보를 취득하고 다른 지령들을 적용하는 것을 포함할 수 있다. cmdlet가 파이프라인 파라미터들 중 하나인 경우, 처리는 즉시 시작될 수 있다. 필요한 명령 스트링 및 입력 파라미터들이 제공되면, 처리는 종료된다.

예시적인 cmdlet 팝퓰레이팅 프로세스

cmdlet를 팝퓰레이트하기 위한 예시적인 프로세스가 도 16에 도시되어 있으며, 이제 도 5와 관련하여 설명된다. 하나의 예시적인 관리 도구 프레임워크에서, 코어 엔진은 cmdlet에 대한 파라미터들을 팝퓰레이트하기 위한 처리를 수행한다. 처리는 cmdlet의 인스턴스가 생성된 후에 블록 1601에서 시작된다. 처리는 블록 1602에서 계속된다.

블록 1602에서, cmdlet 내에 선언된 파라미터(예를 들어, ProcessName)가 검색된다. cmdlet에서의 선언에 기초하여, 코어 엔진은 수신 입력 객체들이 "ProcessName"이라고 명명된 특성을 제공한다는 것을 인식한다. 수신 특성의 타입이 파라미터 선언에서 지정된 타입과 다른 경우, 그 타입은 확장 타입 관리자를 통해 관리된다. 데이타 타입을 관리하는 프로세스는 "예시적인 확장 타입 관리자 처리"라는 제목의 섹션에서 후술된다. 처리는 블록 1603으로 계속된다.

블록 1603에서, 파라미터와 관련된 속성이 취득된다. 속성은 파라미터에 대한 입력 소스가 명령 라인인지, 또는 파이프라인으로부터 온 것인지를 식별한다. 처리는 판정 블록 1604에서 계속된다.

판정 블록 1604에서, 속성이 입력 소스를 명령 라인으로서 지정하는지에 대한 판정이 이루어진다. 입력 소스가 명령 라인인 경우, 처리는 블록 1609로 계속된다. 그렇지 않은 경우, 처리는 판정 블록 1605로 계속된다.

판정 블록 1605에서, 선언에서 지정된 특성 명칭이 사용되어야 하는지, 또는 특성 명칭에 대한 맵핑이 사용되어야 하는지에 대한 판정이 이루어진다. 이러한 판정은 명령 입력이 파라미터에 대한 맵핑을 지정하는지의 여부에 기초한다. 다음 라인은 파라미터 "ProcessName"의 수신 객체의 "foo" 멤버로의 예시적인 맵핑을 나타낸다.

$get/process|where han*-gt500|stop/process-ProcessName<-foo

처리는 블록 1606으로 계속된다.

블록 1606에서, 맵핑이 적용된다. 맵핑은 예측 파라미터의 명칭을 "ProcessName"에서 "foo"로 대체하며, 이 명칭은 나중에 코어 엔진에 의해 수신 객체들을 분석하고 올바른 예측 파라미터들을 식별하는 데 사용된다. 처리는 블록 1608로 계속된다.

블록 1608에서, 확장 타입 관리자는 수신 객체 내의 파라미터에 대한 값을 찾기 위해 질의된다. 확장 타입 관리자와 관련하여 설명되는 바와 같이, 확장 타입 관리자는 파라미터 명칭을 취하고, 반사를 이용하여 파라미터 명칭을 가진 수신 객체 내의 파라미터를 식별한다. 확장 타입 관리자는 또한 필요에 따라 파라미터에 대한 다른 처리도 수행할 수 있다. 예를 들어, 확장 타입 관리자는 전술한 변환 메카니즘을 통해 데이타의 타입을 예측 데이타 타입으로 강제할 수 있다. 처리는 판정 블록 1610으로 계속된다.

블록 1609를 다시 참조하면, 속성이 입력 소스가 명령 라인인 것으로 지정하는 경우, 명령 라인으로부터 데이타가 취득된다. 명령 라인으로부터의 데이타 취득은 확장 타입 관리자를 통해 수행될 수 있다. 이후, 처리는 판정 블록 1610으로 계속된다.

판정 블록 1610에서, 다른 확장 파라미터가 존재하는지에 대한 판정이 이루어진다. 다른 예측 파라미터가 존재하는 경우, 처리는 블록 1602로 루프백하여 전술한 바와 같이 진행된다. 그렇지 않은 경우, 처리는 종료되고 리턴된다.

따라서, 도시된 바와 같이, cmdlet들은 예측 파라미터를 취득하기 위해 수신 데이타를 분해하기 위한 템플릿으로서 작용한다. 또한, 예측 파라미터들은 예측 파라미터에 대한 값을 제공하는 수신 객체의 타입을 알지 않고도 얻어진다. 이것은 통상의 관리 환경과 매우 다르다. 통상의 관리 환경들은 긴밀하게 결합되며, 객체의 타입이 컴파일 시에 알려져야 할 것을 요구한다. 또한, 통상의 환경에서, 예측 파라미터는 값에 의해 또는 참조에 의해 함수로 전달된다. 따라서, 본 분석(예를 들어, 분해) 메카니즘은 파라미터들이 이들 파라미터들에 대한 값들이 어떻게 취득되는지에 대해 특별히 알 것을 요구하지 않고 파라미터의 타입을 지정하는 것을 허용한다.

예를 들어, cmdlet Foo에 대한 다음의 선언이 주어진다.

class Foo:Cmdlet

{

stringName

Bool Recurse

}

명령 라인 신택스는 다음 중 어느 하나일 수 있다.

$Foo-Name:(string)-Recurse:True

$Foo-Name<string>-Recurse True

$Foo-Name(string)

규칙들의 세트는 원하는 신택스를 생성하기 위하여 시스템 관리자에 의해 수정될 수 있다. 또한, 파서는 다수의 규칙 세트를 지원하여, 둘 이상의 신택스가 사용자에 의해 사용되게 할 수 있다. 본질적으로, cmdlet 구조와 관련된 문법(예를 들어, stringName 및 Bool Recurse)은 파서를 구동한다.

일반적으로, 분석 지령은 명령 스트링으로서 입력된 파라미터들이 cmdlet 객체에서 식별된 예측 파라미터들로 어떻게 맵핑되어야 하는지를 기술한다. 입력 파라미터 타입들은 올바른지를 판정하기 위해 검사된다. 입력 파라미터 타입들이 올바르지 않은 경우, 입력 파라미터들은 올바르게 되도록 강제될 수 있다. 입력 파라미터 타입들이 올바르지 않고 강제될 수 없는 경우, 사용 에러가 프린트된다. 사용 에러는 사용자가 예측된 올바른 신택스를 인식하게 되는 것을 허용한다. 사용 에러는 문서화 지령들로부터 신택스를 기술하는 정보를 취득할 수 있다. 입력 파라미터 타입들이 맵핑되거나 검증된 경우, cmdlet 객체 내의 대응하는 멤버들이 팝퓰레이트된다. 멤버들이 팝퓰레이트될 때, 확장 타입 관리자는 입력 파라미터 타입들의 처리를 제공한다. 요컨대, 처리는 특성 경로 메카니즘, 키 메카니즘, 비교 메카니즘, 변환 메카니즘, 글로버 메카니즘, 관계 메카니즘 및 특성 세트 메카니즘을 포함할 수 있다. 이들 메카니즘 각각은 실시예들도 포함하는 "확장 타입 관리자 처리"라는 제목의 섹션에서 보다 상세히 설명된다.

예시적인 cmdlet 실행 프로세스

cmdlet를 실행하기 위한 예시적인 프로세스가 도 17에 도시되어 있으며, 이제 설명된다. 하나의 예시적인 관리 도구 환경에서, 코어 엔진은 cmdlet를 실행한다. 전술한 바와 같이, 제2 메소드(1440) 내의 코어(1442)는 각각의 입력 객체에 대해 실행된다. 처리는 1701에서 시작되어, cmdlet는 이미 팝퓰레이트되어 있다. 처리는 블록 1702에서 계속된다.

블록 1702에서, 실행을 위해 코드(542)로부터 명령문이 검색된다. 처리는 판정 블록 1704에서 계속된다.

판정 블록 1704에서, 후크가 명령문 내에 포함되어 있는지에 대한 판정이 이루어진다. 도 5를 다시 참조하면, 후크는 코어 엔진에 의해 제공되는 API의 호출을 포함할 수 있다. 예를 들어, 도 5의 cmdlet(500)의 코드(542) 내의 명령문(550)은 필요한 파라미터들, 제1 스트링(예를 들어, "PID=") 및 파라미터(예를 들어, PID)를 지정하는 confirmprocessing API를 호출한다. 도 17을 다시 참조하면, 명령문이 후크를 포함하는 경우, 처리는 블록 1712에서 계속된다. 따라서, confirmprocessing API를 호출하는 명령이 지정되는 경우, cmdlet는 동작 환경에 의해 제공되는 대체 실행 모드로 동작한다. 그렇지 않은 경우, 처리는 블록 1706에서 계속되며, 실행은 "정상" 모드로 계속된다.

블록 1706에서, 명령문이 처리된다. 이후, 처리는 판정 블록 1708로 진행한다. 블록 1708에서, 코드가 다른 명령문을 포함하는지에 대한 판정이 이루어진다. 다른 명령문이 존재하는 경우, 처리는 블록 1702로 루프백하여, 다음 명령문을 취득하고 전술한 바와 같이 진행한다. 그렇지 않은 경우, 처리는 판정 블록 1714로 계속된다.

판정 블록 1714에서, 처리할 다른 입력 객체가 존재하는지에 대한 판정이 이루어진다. 다른 입력 객체가 존재하는 경우, 처리는 블록 1716에서 계속되어, cmdlet는 다음 객체로부터의 데이타로 팝퓰레이트된다. 도 16에 설명된 팝퓰레이션 처리는 다음 객체에 대해 수행된다. 이후, 처리는 블록 1702로 루프백하여, 전술한 바와 같이 진행한다. 모든 객체들이 처리되었으면, cmdlet를 실행하기 위한 프로세스는 종료되고, 리턴된다.

판정 블록 1704로 다시 돌아가서, 명령문이 후크를 포함하는 경우, 처리는 블록 1712에서 계속된다. 블록 1712에서, 관리 도구 환경에 의해 제공되는 추가 기능들이 처리된다. 처리는 판정 블록 1708에서 전술한 바와 같이 계속된다.

블록 1712에서 수행되는 추가 처리는 이제 도 6에 도시된 예시적인 데이타 구조와 관련하여 설명된다. 전술한 바와 같이, 명령 기본 클래스(600) 내에는 추가적인 예측 입력 파라미터들(예를 들어, 스위치)에 대응하는 선언된 파라미터들이 존재할 수 있다.

스위치는 소정의 스트링을 포함하며, 인식될 때 코어 엔진이 cmdlet에 추가 기능을 제공하도록 지시한다. 파라미터 verbose(610)가 명령 입력 내에 지정되는 경우, verbose 명령문(614)이 실행된다. 다음은 verbose 스위치를 포함하는 명령 라인의 일례이다.

$ get/process|where "han*-gt500"|stop/process-verbose

일반적으로, "-verbose"가 명령 입력 내에 지정될 때, 코어 엔진은 각각의 입력 객체에 대해 명령을 실행하고, 각각의 입력 객체에 대해 실행된 실제 명령을 표시를 위해 호스트 프로그램으로 전송한다. 다음은 위의 명령 라인이 예시적인 관리 도구 환경에서 실행될 때 생성되는 출력의 일례이다.

$ stop/process PID=15

$ stop/process PID=33

파라미터 whatif(620)가 명령 입력 내에 지정될 때, whatif 명령문(624)이 실행된다. 다음은 whatif 스위치를 포함하는 명령 라인의 일례이다.

$ get/process|where "han*-gt500"|stop/process-whatif

일반적으로, "-whatif"가 지정될 때, 코어 엔진은 코드(542)를 실제로 실행하지 않으며, 오히려 실행된 명령들을 표시를 위해 호스트 프로그램으로 전송한다. 다음은 위의 명령 라인이 본 발명의 관리 도구 환경에서 실행될 때 생성되는 출력의 일례이다.

#$ stop/process PID=15

#$ stop/process PID=33

파라미터 confirm(630)이 명령 입력에서 지정되는 경우, confirm 명령문(634)이 실행된다. 다음은 confirm 스위치를 포함하는 명령 라인의 일례이다.

$ get/process|where "han*-gt500"|stop/process-confirm

일반적으로, "-confirm"이 지정될 때, 코어 엔진은 명령을 진행할지의 여부에 대한 추가 사용자 입력을 요구한다. 다음은 위의 명령 라인이 본 발명의 관리 도구 환경에서 실행될 때 생성되는 출력의 일례이다.

$ stop/process PID 15

Y/N Y

$ stop/process PID 33

Y/N N

전술한 바와 같이, 예시적인 데이타 구조(600)는 또한 실행을 위해 요구되고 있는 작업이 허용되어야 하는지를 결정하는 보안 메소드(640)를 포함할 수 있다. 통상의 관리 환경에서, 각 명령은 명령을 실행하는 사람이 명령을 수행할 충분한 특권을 갖는지를 검사해야 한다. 이러한 검사를 수행하기 위하여, 포괄 코드는 여러 소스로부터의 정보에 액세스해야 한다. 이러한 복잡성으로 인해, 많은 명령들은 보안 검사를 수행하지 않는다. 본 관리 도구 환경의 발명자는 작업이 명령 입력에서 지정될 때, 보안 검사를 수행하기 위해 필요한 정보는 관리 도구 환경 내에서 이용가능하다는 것을 인식하였다. 따라서, 관리 도구 프레임워크는 도구 개발자로부터 복잡한 코드를 요구하지 않고도 보안 검사를 수행한다. 보안 검사는 cmdlet 내의 후크를 정의하는 임의의 후크에 대해 수행될 수 있다. 대안으로, 후크는 전술한 verbose 파라미터와 유사하게 명령 입력에서 지정될 수 있는 옵션 입력 파라미터일 수 있다.

보안 검사는 어느 사용자들이 사용자의 역할에 기초하여 자원들에 액세스하는지를 제어하는 시스템으로서 일반적으로 정의되는 역할 기반 인증을 지원하도록 구현된다. 따라서, 각각의 역할은 상이한 자원들에 대한 소정의 액세스 권리를 할당받는다. 이어서, 사용자는 하나 이상의 역할에 할당된다. 일반적으로, 역할 기반 인증은 3개의 항목, 즉 원리, 자원 및 액션에 집중된다. 원리는 자원 상에 수행될 액션을 누가 요구했는지를 식별한다.

본 발명의 발명자는 요구되고 있는 cmdlet가 수행되어야 하는 액션에 대응한다는 것을 인식했다. 또한, 본 발명자는 관리 도구 환경이 실행하고 있는 프로세스의 소유자가 원리에 대응한다는 것을 인식했다. 또한, 본 발명자는 자원이 cmdlet 내에 지정되어 있다는 것을 인식했다. 따라서, 관리 도구 프레임워크는 이들 항목에 액세스하므로, 본 발명자는 도구 개발자들이 보안 검사를 구현하는 것을 요구하지 않고 보안 검사가 관리 도구 프레임워크 내로부터 수행될 수 있다는 것을 인식했다.

보안 검사 동작은 confirmprocessing API와 같이 후크를 사용함으로써 추가 기능이 cmdlet 내에서 요구되는 어느 때에나 수행될 수 있다. 대안으로, 보안 검사는 보안 스위치가 verbose, whatif 및 confirm과 유사하게 명령 라인 상에 입력되었는지를 검사함으로써 수행될 수 있다. 어느 구현을 위해서나, checkSecurity 메소드는 누가 허용되는지를 판정하기 위한 한 세트의 API를 제공하는 보안 프로세스(도시되지 않음)에 의해 제공되는 API를 호출한다. 보안 프로세스는 관리 도구 프레임워크에 의해 제공되는 정보를 취하여, 작업이 완료될 수 있는지를 나타내는 결과를 제공한다. 이어서, 관리 도구 프레임워크는 에러를 제공하거나 작업의 실행을 바로 종료한다.

따라서, cmdlet 내에 후크를 제공함으로써, 개발자들은 관리 도구 프레임워크에 의해 제공되는 추가 처리를 이용할 수 있다.

예시적인 확장 타입 관리자 처리

도 18과 관련하여 간단히 전술한 바와 같이, 확장 타입 관리자는 제공되는 객체 상에 추가 처리를 수행할 수 있다. 추가 처리는 파서(220), 스크립트 엔진(222) 또는 파이프라인 프로세서(402)의 요구로 수행될 수 있다. 추가 처리는 특성 경로 메카니즘, 키 메카니즘, 비교 메카니즘, 변환 메카니즘, 글로버 메카니즘, 관계 메카니즘, 및 특성 세트 메카니즘을 포함한다. 확장 타입 관리자는 또한 청구된 발명의 범위를 벗어나지 않고 다른 처리에도 확장될 수 있다는 것을 당업자는 이해할 것이다. 이제, 추가 처리 메카니즘들 각각이 설명된다.

먼저, 특성 경로 메카니즘은 스트링이 객체들의 특성을 네비게이트하는 것을 허용한다. 현재의 반사 시스템에서, 질의들은 객체의 특성들에 질의할 수 있다. 그러나, 본 확장 타입 관리자에서는, 객체들의 연속적인 특성들에 대한 네비게이션 경로를 제공하는 스트링이 지정될 수 있다. 다음은 특성 경로에 대한 예시적인 신택스이다: P1.P2.P3.P4.

각각의 컴포넌트(예를 들어, P1, P2, P3 및 P4)는 특성, 파라미터를 가진 메소드, 파라미터를 갖지 않는 메소드, 필드, XPATH 등을 나타내는 스트링을 포함한다. XPATH는 요소를 검색하기 위한 질의 스트링(예를 들어, "/FOO@=13")을 지정한다. 이 스트링 내에는, 컴포넌트의 타입을 구체적으로 나타내는 특수 문자가 포함될 수 있다. 스트링이 특수 문자를 포함하지 않는 경우, 확장 타입 관리자는 컴포넌트의 타입을 판정하기 위해 탐색을 수행할 수 있다. 예를 들어, 컴포넌트 P1이 객체인 경우, 확장 타입 관리자는 P2가 객체의 특성인지, 객체 상의 메소드인지, 객체의 필드인지, 또는 특성 세트인지를 질의할 수 있다. 확장 타입 관리자가 P2의 타입을 식별하면, 그 타입에 따른 처리가 수행된다. 컴포넌트가 위 타입들 중 하나가 아닌 경우, 확장 타입 관리자는 또한 P1의 타입을 P2의 타입으로 변환하는 변환 기능이 존재하는지를 판정하기 위해 확장 소스에 질의할 수 있다. 이러한 탐색 및 다른 탐색은 이제 각각의 출력을 보이는 예시적인 명령 스트링들을 이용하여 설명된다.

다음은 특성 경로를 포함하는 예시적인 스트링이다.

$ get/process|/where hand*-gt>500| format/table name.toupper, ws.kb, exe*.ver*.description.tolower.trunc(30).

위의 예시적인 스트링에는 3개의 특성 경로, 즉 (1) "name.toupper", (2) "ws.bk" 및 (3) "exe*.ver*.description.tolower.trunc(30)이 존재한다. 이 특성 경로들을 설명하기 전에, "name", "ws" 및 "exe"는 테이블에 대한 특성을 지정한다는 점에 유의해야 한다. 또한, 이들 특성 각각은 "get/process"에 의해 최초로 생성된 후 다양한 cmdlet를 통해 파이프라인화된 수신 객체의 직접적인 특성이라는 점에도 유의해야 한다. 3개의 특성 경로 각각에 수반되는 처리가 이제 설명된다.

제1 특성 경로(즉, "name.toupper")에서, name은 수신 객체의 직접 특성이며, 또한 객체 그 자체이다. 확장 타입 관리자는 toupper의 타입을 결정하기 위해 전술한 우선순위 탐색을 이용하여 시스템에 질의한다. 확장 타입 관리자는 toupper이 특성이 아니라는 것을 발견한다. 그러나, toupper은 스트링 내의 소문자를 대문자로 변환하기 위해 스트링 타입에 의해 상속되는 메소드일 수 있다. 대안으로, 확장 타입 관리자는 명칭 객체를 대문자로 변환할 수 있는 임의의 삼자 코드가 존재하는지를 판정하기 위해 확장 메타데이타에 질의할 수 있다. 컴포넌트 타입을 발견한 때, 처리는 그 컴포넌트 타입에 따라 수행된다.

제2 특성 경로(즉, "ws.kb")에서, "ws"는 수신 객체의 직접 특성이며, 또한 객체 그 자체이다. 확장 타입 관리자는 "ws"가 정수인지를 판정한다. 이어서, 확장 타입 관리자는 kb가 정수의 특성인지, kb가 정수의 메소드인지를 질의하고, 마지막으로, 어떻게 정수를 취하고 이 정수를 kb 타입으로 변환하는지를 임의의 코드가 알고 있는지의 여부를 질의한다. 삼자 코드가 이러한 변환을 수행하도록 등록되고, 변환이 수행된다.

제3 특성 경로(즉, "exe*.ver*.description.tolower.trunc(30)")에는 여러 컴포넌트가 존재한다. 제1 컴포넌트("exe*")는 수신 객체의 직접 특성이며, 또한 객체이다. 또한, 확장 타입 관리자는 제2 컴포넌트("ver*")를 처리하기 위해 탐색 질의를 진행한다. "exe*" 객체는 "ver*" 특성 또는 메소드를 갖지 않으며, 따라서 확장 타입 관리자는 실행 가능 명칭을 하나의 버젼으로 변환하도록 등록된 임의의 코드가 존재하는지를 판정하기 위해 확장 메타데이타에 질의한다. 이 예에서는 그러한 코드가 존재한다. 이 코드는 실행 가능 명칭 스트링을 취하고, 이것을 사용하여 파일을 연 후, 버젼 블록 객체에 액세스하고, 이 버젼 블록 객체의 설명 특성(삼자 컴포넌트("description"))을 리턴할 수 있다. 이어서, 확장 타입 관리자는 제4 컴포넌트("tolower") 및 제5 컴포넌트("trunc(40)")에 대해 동일한 탐색 메카니즘을 수행한다. 따라서, 설명된 바와 같이, 확장 타입 관리자는 관리자가 임의의 특정 코드를 작성할 필요 없이 명령 스트링 상에 아주 정교한 처리를 수행할 수 있다. 표 6은 예시적인 스트링에 대해 생성된 출력을 나타낸다.

또 하나의 질의 메카니즘(1824)은 키를 포함한다. 키는 데이타 타입의 인스턴스를 고유하게 만드는 하나 이상의 특성을 식별한다. 예를 들어, 데이타베이스에서, 하나의 열은 각각의 행을 고유하게 식별할 수 있는 키로서 식별될 수 있다(예를 들어, 사회 보장 번호). 키는 데이타 타입과 관련된 타입 메타데이타(1840) 내에 저장된다. 이어서, 이 키는 그 데이타 타입의 객체를 처리할 때 확장 타입 관리자에 의해 사용될 수 있다. 데이타 타입은 확장 데이타 타입 또는 기존 데이타 타입일 수 있다.

또 하나의 질의 메카니즘(1824)은 비교 메카니즘을 포함한다. 비교 메카니즘은 2개의 객체를 비교한다. 2개의 객체가 비교 기능을 직접 지원하는 경우, 직접 지원되는 비교 기능이 실행된다. 그러나, 어느 객체도 비교 기능을 지원하지 않는 경우, 확장 타입 관리자는 2개의 객체 사이의 비교를 지원하도록 등록된 코드를 타입 메타데이타에서 찾을 수 있다. 비교 메카니즘을 호출하는 예시적인 일련의 명령 라인 스트링들이 아래의 표 7에 대응 출력과 함께 나타나 있다.

compare/time cmdlet는 2개의 datetime 객체를 비교하도록 작성된다. 이 경우, DateTime 객체는 IComparable 인터페이스를 지원한다.

또 하나의 질의 메카니즘(1824)은 변환 메카니즘을 포함한다. 확장 타입 관리자는 특정 변환을 수행할 수 있는 능력을 표명하는 코드가 등록되는 것을 허용한다. 이어서, 타입 A의 객체가 입력되고, cmdlet가 타입 B의 객체를 지정할 때, 확장 타입 관리자는 등록된 변환들 중 하나를 이용하여 변환을 수행할 수 있다. 확장 타입 관리자는 타입 A를 타입 B로 강제하기 위하여 일련의 변환을 수행할 수 있다. 전술한 특성 경로("ws.kb")는 변환 메카니즘을 설명한다.

또 하나의 질의 메카니즘(1824)은 글로버 메카니즘을 포함한다. 글로버는 스트링 내의 와일드 카드 문자를 말한다. 글로버 메카니즘은 와일드 카드 문자를 가진 스트링을 입력하여, 한 세트의 객체를 생성한다. 확장 타입 관리자는 와일드 카드 처리를 지정하는 코드가 등록되는 것을 허용한다. 전술한 특성 경로("exe*.ver*.description.tolower.trunc(30))는 글로버 메카니즘을 나타낸다. 등록된 프로세스가 파일 명칭, 파일 객체, 수신 객체 등에 대한 글로빙을 제공할 수 있다.

또 하나의 질의 메카니즘(1824)은 특성 세트 메카니즘을 포함한다. 특성 세트 메카니즘은 명칭이 한 세트의 특성에 대해 정의되는 것을 허용한다. 이어서, 관리자는 특성 세트를 취득하기 위해 명령 스트링 내에 명칭을 지정할 수 있다. 특성 세트는 다양한 방법으로 정의될 수 있다. 하나의 방법에서, "?"와 같은 미리 정의된 파라미터가 cmdlet에 대한 입력 파라미터로서 입력될 수 있다. 동작 환경은 미리 정의된 파라미터를 인식한 때 수신 객체의 모든 특성을 리스트화한다. 리스트는 관리자가 원하는 특성들을 쉽게 (예를 들어, "click on") 검사하고 특성 세트를 명명하는 것을 허용하는 GUI일 수 있다. 이어서, 특성 세트 정보는 확장 메타데이타에 저장된다. 특성 세트 메카니즘을 호출하는 예시적인 스트링이 아래의 표 8에 대응 출력과 함께 나타나 있다.

$ get/process|where han*-gt>500|format/table config

이 예시적인 스트링에서, "config"로 명명된 특성 세트는 명칭 특성, 프로세스 id 특성(Pid) 및 우선순위 특성을 포함하도록 정의되어 있다. 표에 대한 출력은 다음과 같다.

또 하나의 질의 메카니즘(1824)은 관계 메카니즘이다. 하나의 관계(즉, 상속)를 지원하는 통상의 타입 시스템과 대조적으로, 본 관계 메카니즘은 타입들 사이의 둘 이상의 관계의 표현을 지원한다. 또한, 이 관계들은 등록된다. 관계는 객체가 소비하는 항목들의 발견, 또는 객체를 소비하는 항목들의 발견을 포함할 수 있다. 확장 타입 관리자는 다양한 관계를 기술하는 온톨로지에 액세스할 수 있다. 확장 메타데이타 및 코드를 사용하여, OWL, DAWL 등과 같은 임의의 온톨로지 서비스에 액세스하기 위한 사양이 기술될 수 있다. 다음은 관계 메카니즘을 사용하는 예시적인 스트링의 일부이다: .OWL:"string".

"OWL" 식별자는 온톨로지 서비스를 식별하며, "string"은 온톨로지 서비스 내의 특정 스트링을 지정한다. 따라서, 확장 타입 관리자는 온톨로지 서비스에 의해 제공되는 타입들에 액세스할 수 있다.

예시적인 명령 라인 데이타 표시 프로세스

본 메카니즘은 데이타 구동형 명령 라인 출력을 제공한다. 데이타의 포맷팅 및 출력은 cmdlet들의 파이프라인 내의 하나 이상의 cmdlet에 의해 제공된다. 일반적으로, 이 cmdlet들은 도 2와 관련하여 전술한 비관리 cmdlet들 내에 포함된다. cmdlet들은 format cmdlet, markup cmdlet, convert cmdlet, transform cmdlet 및 out cmdlet를 포함할 수 있다.

도 19는 파이프라인 내의 cmdlet들의 예시적인 시퀀스(1901-1907)를 나타낸다. 제1 시퀀스(1901)는 out cmdlet(1910)를 파이프라인 내의 최종 cmdlet로서 나타낸다. 다른 cmdlet들에 대해 전술한 것과 동일한 방식으로, out cmdlet(1910)는 파이프라인 내의 다른 cmdlet들에 의해 생성되고 처리된 파이프라인 객체들의 스트림을 수신한다. 그러나, 대부분의 cmdlet들과 달리, out cmdlet(1910)는 다른 cmdlet들에 대한 파이프라인 객체들을 발행하지 않는다. 그 대신, out cmdlet(1910)는 파이프라인에 의해 생성되는 결과들의 렌더링/표시를 담당한다. 각각의 out cmdlet(1910)는 장치, 프로그램 등과 같은 출력 목표와 연관된다. 예를 들어, 콘솔 장치에 대해, out cmdlet(1910)는 out/console로서 지정될 수 있으며, 인터넷 브라우저에 대해, out cmdlet(1910)는 out/browser로서 지정될 수 있고, 윈도우에 대해, out cmdlet(1910)는 out/window로서 지정될 수 있다. 각각의 특정 out cmdlet는 그와 관련된 목표의 능력과 친밀하다. 로케일(locale) 정보(예를 들어, date &currency 포맷들)는 파이프라인에서 convert cmdlet가 out cmdlet에 선행하지 않으면 out cmdlet(1910)에 의해 처리된다. 이 상황에서, convert cmdlet는 로컬 정보를 처리했다.

각각의 호스트는 out/console와 같은 소정의 out cmdlet들의 지원을 담당한다. 호스트는 또한 임의의 목표 특정 호스트 cmdlet(예를 들어, 스프레드시트 애플리케이션에 의해 제공되는 챠트로 출력을 전송하는 out/chart)를 지원한다. 또한, 호스트는 결과들의 디폴트 처리의 제공을 담당한다. 이 시퀀스의 out cmdlet는 다른 출력 처리 cmdlet들(예를 들어, format/markup/convert/transform)을 호출함으로써 그의 거동을 구현하도록 결정할 수 있다. 따라서, out cmdlet는 시퀀스(1901)를 다른 시퀀스들로 암시적으로 수정하거나 그 자신의 추가 format/output cmdlet들을 추가할 수 있다.

제2 시퀀스(1902)는 out cmdlet 전의 format cmdlet(1920)를 나타낸다. 이 시퀀스에 대해, format cmdlet(1920)는 파이프라인 내의 다른 cmdlet들에 의해 생성되고 처리된 파이프라인 객체들의 스트림을 수신한다. 개략적으로, format cmdlet(1920)는 표시 특성을 선택할 수 있는 방법, 및 형상, 열 폭, 헤더, 푸터(footer) 등과 같은 페이지 레이아웃을 지정할 수 있는 방법을 제공한다. 형상은 테이블, 가로 리스트, 세로 리스트 등을 포함할 수 있다. 또한, format cmdlet(1920)는 총계 또는 합계의 연산을 포함할 수 있다. format cmdlet(1920)에 의해 수행되는 예시적인 처리는 도 20과 관련하여 후술된다. 요컨대, format cmdlet는 파이프라인 객체를 발행하는 것 외에 포맷 객체를 발행한다. 포맷 객체는 out cmdlet(예를 들어, 시퀀스(1902) 내의 cmdlet(1920))에 의해 확장 타입 관리자 또는 다른 메카니즘을 통해 하향 인식될 수 있다. out cmdlet(1920)는 발행된 포맷 객체를 사용하도록 선택하거나 이들을 무시하도록 선택할 수 있다. out cmdlet는 표시 정보에서 지정되는 페이지 레이아웃 데이타에 기초하여 페이지 레이아웃을 결정한다. 소정의 예에서, 페이지 레이아웃에 대한 수정은 out cmdlet에 의해 지정될 수 있다. 하나의 예시적인 프로세스에서, out cmdlet는 소정 수의 객체들(예컨대, 50)의 각각의 특성에 대한 최대 길이를 발견하고 열 폭을 최대 길이로 설정함으로써 미지정 열 폭을 결정할 수 있다. 포맷 객체는 포맷팅 정보, 헤더/푸터 정보 등을 포함한다.

제3 시퀀스(1903)는 out cmdlet(1910) 전의 format cmdlet(1920)를 나타낸다. 그러나, 제3 시퀀스(1903)에서는 markup cmdlet(1930)가 format cmdlet(1920)와 out cmdlet(1910) 사이에 파이프라인된다. markup cmdlet(1930)는 특성 주석(예컨대, 폰트, 칼라)을 선택된 파라미터에 추가하기 위한 메카니즘을 제공한다. 따라서, markup cmdlet(1930)는 output cmdlet(1910) 전에 나타난다. 특성 주석은 "쉐도우 특성 백(shadow property bag)"을 사용하거나, 특성 백 내의 고객 명칭 공간에 특성 주석을 추가함으로써 구현될 수 있다. markup cmdlet(1930)는 마크업 주석이 format cmdlet(1920)의 처리 동안 유지될 수 있는 한 format cmdlet(1920) 전에 나타날 수 있다.

제4 시퀀스(1904)는 또한 out cmdlet(1910) 전의 format cmdlet(1920)를 나타낸다. 그러나, 제4 시퀀스(1904)에서는, convert cmdlet(1940)가 format cmdlet(1920)와 out cmdlet(1910) 사이에 파이프라인된다. convert cmdlet(1940)는 또한 format cmdlet(1920)에 의해 발행되는 포맷 객체를 처리하도록 구성된다. convert cmdlet(1940)는 포맷 객체에 기초하여 파이프라인 객체를 특정 인코딩으로 변환한다. convert cmdlet(1940)는 특정 인코딩과 연관된다. 예를 들어, 파이프라인 객체를 액티브 디렉토리 객체(ADO)로 변환하는 convert cmdlet(1940)는 명령 라인 상에 "convert/ADO"로서 선언될 수 있다. 마찬가지로, 파이프라인 객체를 콤마 분리 값들(csv)로 변환하는 convert cmdlet(1940)는 명령 라인 상에 "convert/csv"로서 선언될 수 있다. convert cmdlet들(1940) 중 일부(예를 들어, convert/XML 및 convert/html)는 블록킹 메카니즘일 수 있는데, 이는 모든 파이프라인 객체가 변환을 실행하기 전에 수신된다는 것을 의미한다. 일반적으로, out cmdlet(1920)는 포맷 객체들에 의해 제공되는 포맷팅 정보를 사용할 것인지를 결정할 수 있다. 그러나, convert cmdlet(1940)가 out cmdlet(1920) 전에 나타날 때, out cmdlet가 객체를 수신하기 전에 이미 실제 데이타 변환이 발생하게 된다. 다라서, 이 상황에서, out cmdlet는 변환을 무시할 수 없다.

제5 시퀀스(1905)는 format cmdlet(1920), markup cmdlet(1930), convert cmdlet(1940) 및 out cmdlet(1910)을 이 순서대로 나타낸다. 따라서, 이것은 markup cmdlet(1930)가 convert cmdlet(1940) 전에 발생할 수 있음을 나타낸다.

제6 시퀀스(1906)는 format cmdlet(1920), 특정 convert cmdlet(예를 들어, convert/xml cmdlet 1940'), 특정 transform cmdlet(예를 들어, transform/xslt cmdlet 1950) 및 out cmdlet(1910)를 나타낸다. convert/xml cmdlet(1940')는 파이프라인 객체를 확장형 마크업 언어(XML) 문서로 변환한다. transform/xslt cmdlet(1950)는 XML 문서를 확장성 스타일 언어(XSL) 스타일 시트를 이용하여 다른 XML 문서로 변환한다. 변환 처리는 일반적으로 확장성 스타일 언어 변환(XSLT)으로 지칭되는데, 여기서 XSL 프로세서는 XML 문서를 판독하고, XSL 스타일 시트 내의 명령들에 따라 새로운 XSL 문서를 생성한다.

제7 시퀀스(1907)는 format cmdlet(1920), markup cmdlet(1930), 특정 convert cmdlet(예를 들어, convert/xml cmdlet 1940'), 특정 transform cmdlet(예를 들어, transform/xslt cmdlet 1950) 및 out cmdlet(1910)를 나타낸다. 따라서, 제7 시퀀스(1907)는 convert cmdlet 및 transform cmdlet로부터 상향으로 markup cmdlet(1930)를 갖는다.

도 20은 format cmdlet에 의해 수행되는 예시적인 처리(2000)를 나타낸다. format cmdlet가 전술한 방식으로 파서 및 파이프라인 프로세서에 의해 분석되고 호출된 후에 포맷팅 프로세스가 블록 2001에서 시작된다. 처리는 블록 2002로 계속된다.

블록 2002에서, 파이프라인 객체가 format cmdlet에 대한 입력으로서 수신된다. 처리는 블록 2004로 계속된다.

블록 2004에서, 파이프라인 객체의 타입을 식별하기 위한 질의가 개시된다. 이 질의는 도 18과 관련하여 전술한 바와 같이 확장 타입 관리자에 의해 수행된다. 확장 타입 관리자가 객체의 타입을 식별하면, 처리는 블록 2006으로 계속된다.

블록 2006에서, 식별된 타입이 표시 정보에서 탐색된다. 표시 정보에 대한 예시적인 포맷은 도 21에 도시되며, 후술된다. 처리는 판정 블록 2008로 계속된다.

판정 블록 2008에서, 식별된 타입이 표시 정보 내에 지정되어 있는지에 대한 판정이 이루어진다. 표시 정보 내에 식별된 타입에 대한 엔트리가 없는 경우, 처리는 종료된다. 그렇지 않은 경우, 처리는 블록 2010으로 계속된다.

블록 2010에서, 식별된 타입과 관련된 포맷팅 정보가 표시 정보로부터 취득된다. 처리는 블록 2012로 계속된다.

블록 2012에서, 정보가 파이프라인 상에 발행된다. 정보가 발행되면, 처리는 종료된다.

발행될 수 있는 예시적인 정보가 이제 상세히 설명된다. 정보는 포맷팅 정보, 헤더/푸터 정보 및 그룹 종료/시작 신호 객체를 포함할 수 있다. 포맷팅 정보는 형상 라벨, 넘버링/불렛, 열 폭, 문자 인코딩 타입, 컨텐츠 폰트 특성, 페이지 길이, 그룹 바이 특성(group-by-property) 명칭 등을 포함할 수 있다. 이들 각각은 그와 관련된 추가 사양을 가질 수 있다. 예를 들어, 형상은 형상이 테이블, 리스트 등인지를 지정할 수 있다. 라벨은 열 헤더, 리스트 라벨 등을 사용하는지를 지정할 수 있다. 문자 인코딩은 ASCII, UTF-8, 유니코드 등을 지정할 수 있다. 컨텐츠 폰트 특성은 표시되는 특성 값들에 적용되는 폰트를 지정할 수 있다. 컨텐츠 폰트 특성이 지정되지 않은 경우, 디폴트 폰트 특성(예를 들어, Courier New, 10 point)이 사용될 수 있다.

헤더, 푸터 정보는 헤더/푸터 범위, 폰트 특성, 제목, 부제목, 날짜, 시간, 페이지 넘버링, 분리자 등을 포함할 수 있다. 예를 들어, 범위는 문서, 페이지, 그룹 등을 지정할 수 있다. 추가 특성들이 헤더 또는 푸터에 대해 지정될 수 있다. 예컨대, 그룹 및 문서 푸터들에 대해, 추가 특성은 합계/총계, 객체 카운트, 총계 및 카운트에 대한 라벨 스트링 등을 계산하기 위한 특성 또는 열을 포함할 수 있다.

그룹 종료/시작 신호 객체는 format cmdlet가 그룹 바이 특성이 변경되었음을 검출한 때 발행된다. 이것일 발생할 때, format cmdlet는 파이프라인 객체들의 스트림을 이전에 분류된 것으로 처리하며, 이들을 재분류하지 않는다. 그룹 종료/시작 신호 객체는 파이프라인 객체들에 산재할 수 있다. 다수의 그룹 바이 특성이 중첩 분류를 위해 지정될 수 있다. format cmdlet는 또한 최종 합계 및 총계를 포함하는 포맷 종료 객체를 발행할 수 있다.

도 21을 참조하면, 예시적인 표시정보(2100)는 구조화된 포맷을 가지며, 정의된 각각의 객체와 관련된 정보(예를 들어, 포맷팅 정보, 헤더/푸터 정보, 그룹 바이 특성 또는 메소드)를 포함한다. 예를 들어, 표시 정보(2100)는 XML 기반 정보일 수 있다. 이어서, 전술한 특성들 각각은 표시 정보 내에 지정될 수 있다. 표시 정보(2100) 내의 정보는 입력되고 있는 객체 타입의 소유자에 의해 팝퓰레이트될 수 있다. 동작 환경은 소유자가 엔트리를 생성, 삭제 및 수정함으로써 표시 정보를 갱신하는 것을 허용하는 소정의 API 및 cmdlet를 제공한다.

도 22는 소정의 format cmdlet(예를 들어, format/table, format/list 및 format/wide), markup cmdlet(예를 들어, add/markup), convert cmdlet(예를 들어, convert/text, convert/sv, convert/csv, convert/ADO, convert/XML, convert/html), transform cmdlet(예를 들어, transform/XSLT) 및 out cmdlet(예를 들어, out/console, out/file)에 대한 예시적인 신택스(2201-2213)을 리스트한 테이블이다. 도 23은 출력 처리 cmdlet들(예를 들어, format cmdlet, convert cmdlet, 및 markup cmdlet)의 다양한 파이프라인 시퀀스를 사용하여 out/console cmdlet에 의해 렌더링된 결과를 나타낸다.

본 관리 도구 프레임워크는 작업들이 임의의 호스트(예를 들어, 사용자 인터페이스, 명령 라인, 프로그램적으로)로부터 개시되는 것을 허용하기 때문에, 시스템 관리자 및 제품 개발자들은 양 타입의 사용자들이 보다 효과적이고 효율적이 되게 하는 코드 및 경험을 공유할 수 있다. 또한, 시스템 관리자는 개념들, 명령들 및 문제 해결 기술들 중 한 세트만을 배우면 된다. 마찬가지로, 제품 개발자들은 모든 관리 도구들을 이용하기 위해 하나의 제공자 cmdlet만을 생성하면 된다.

따라서, 전술한 바와 같이, 본 관리 도구 프레임워크는 관리 객체들에 대한 액세스 및 제어를 간략화하고, 투명한 원격화를 제공하므로, 본 관리 도구 프레임워크는 관리 도구를 개발하는 데 필요한 기술 레벨을 저하시킨다. 또한, 본 프레임워크는 개발자들이 프레임워크를 배우는 것을 돕는 GUI 상호작용에 의해 실행되는 스크립트를 보고 그들 자신의 자동화된 스크립트를 생성하는 것을 허용한다. 또한, 프레임워크에 의해 제공되는 기능에 대한 테스트가 이미 수행되었으므로, 제품 레벨 테스트는 프레임워크에 의해 제공되는 기능을 호출하기 위한 GUI 경로를 테스트하는 것으로 축소된다. 또 하나의 이점은 관리 GUI가 개발자들 및 테스터들에게 디버깅/진단/자동화된 테스트를 위한 GUI의 내부 상태 및 제어에 대한 쉬운 액세스를 제공하는 cmdlet들을 통해 그 내부의 작업을 표시할 수 있다는 점이다.

특정 구현 및 실시예들이 상세히 설명되었지만, 이러한 상세한 설명은 아래의 청구범위의 범위를 제한하고자 하는 것이 아니라 법정 공개 의무를 만족시키고자 하는 것이다. 따라서, 청구범위에 정의된 본 발명은 전술한 특정 기능들로 제한되지 않는다. 오히려, 본 발명은 균등론에 따라 적절히 해석되는 첨부된 청구범위의 적정 범위 내에 있는 어떠한 형태 또는 변형으로도 특허 청구된다.

Claims

관리 작업을 자동화하기 위한 프레임워크를 제공하는 컴퓨터 실행 가능 명령들을 구비한 적어도 하나의 컴퓨터 판독 가능 매체에 있어서,

상기 프레임워크는

입력을 분석하고, 상기 입력에 기초하여 적어도 하나의 cmdlet를 식별하도록 구성된 파서(parser) 컴포넌트; 및

입력 소스로부터의 정보를 이용하여 상기 cmdlet와 연관된 파라미터를 팝퓰레이트(populate)하고, 상기 cmdlet를 실행하여 정밀하게 분석할 수 있는 스트림을 생성하도록 구성된 엔진 컴포넌트를 포함하고,

상기 입력 소스는 다른 cmdlet로부터 발행되는 정밀하게 분석할 수 있는 스트림을 포함하는 컴퓨터 판독 가능 매체.
제1항에 있어서, 적어도 하나의 명령에 대한 입력을 제공하도록 구성된 호스트 컴포넌트를 더 포함하는 컴퓨터 판독 가능 매체.
제2항에 있어서, 상기 호스트 컴포넌트는 상기 파서 컴포넌트에 직접 상기 입력을 제공하는 컴퓨터 판독 가능 매체.
제2항에 있어서, 상기 호스트 컴포넌트는 상기 엔진 컴포넌트 내의 cmdlet들 중 하나로서 처리되는 호스트 cmdlet를 이용하여 상기 입력을 제공하는 컴퓨터 판독 가능 매체.
제1항에 있어서, 상기 cmdlet는 복수의 데이타 타입들 상에서 동작하는 공통 유틸리티를 제공하는 기본 cmdlet를 포함하는 컴퓨터 판독 가능 매체.
제1항에 있어서, 상기 cmdlet는 시스템 유틸리티를 제공하는 호스트 cmdlet를 포함하는 컴퓨터 판독 가능 매체.
제1항에 있어서, 상기 cmdlet와 연관되는 상기 파라미터는 상기 cmdlet 내의 파라미터에 대한 파라미터 선언을 포함하는 컴퓨터 판독 가능 매체.
제1항에 있어서, 상기 cmdlet와 연관되는 상기 파라미터는 상기 파라미터를 정의하는 외부 소스에 대한 참조를 포함하는 컴퓨터 판독 가능 매체.
제1항에 있어서, 상기 cmdlet는 애플리케이션과 연관된 기능을 제공하는 제공자 cmdlet를 포함하는 컴퓨터 판독 가능 매체.
하나 이상의 컴퓨터에 의해 실행될 때 다음의 단계들을 수행하는 명령들을 구비한 적어도 하나의 컴퓨터 판독 가능 매체에 있어서,

입력을 수신하는 단계;

적어도 하나의 예측 입력 파라미터를 식별하는 cmdlet를 상기 입력과 연관시키는 단계;

상기 입력으로부터의 데이타 취득을 지정하는 각각의 예측 입력 파라미터에 대해, 상기 입력으로부터의 데이타로 상기 예측 입력 파라미터를 팝퓰레이트하는 단계; 및

입력 스트림에서 상기 cmdlet로의 정보 취득을 지정하는 각각의 예측 입력 파라미터에 대해, 상기 정보로 상기 예측 입력 파라미터를 팝퓰레이트하고, 상기 cmdlet를 실행하여 상기 정보 및 상기 데이타에 기초하여 객체 스트림을 생성하고, 상기 객체 스트림을 발행하는 단계를 포함하고,

상기 입력 스트림은 다른 cmdlet에 의해 발행되는 객체 스트림을 포함하는 컴퓨터 판독 가능 매체.
제10항에 있어서, 상기 입력 객체는 .NET 객체, XML 문서 또는 액티브 디렉토리 객체(Active Directory Object)를 포함하는 컴퓨터 판독 가능 매체.
제10항에 있어서, 상기 cmdlet 및 상기 다른 cmdlet는 동일 프로세스에서 동작하는 컴퓨터 판독 가능 매체.
제10항에 있어서, 상기 cmdlet는 로컬 프로세스에서 동작하고, 상기 다른 cmdlet는 원격 프로세스에서 동작하는 컴퓨터 판독 가능 매체.
제10항에 있어서, 상기 입력은 스트링을 포함하는 컴퓨터 판독 가능 매체.
제10항에 있어서, 상기 입력은 스크립트를 포함하는 컴퓨터 판독 가능 매체.
관리 작업을 자동화하기 위한 관리 도구 프레임워크를 제공하는 시스템에 있어서,

프로세서; 및

메모리 - 상기 메모리는 상기 프로세서에 의한 실행을 위해 상기 메모리 내에 로딩되는 복수의 컴퓨터 실행 가능 명령에 대해 할당됨 - 를 포함하고,

상기 컴퓨터 실행 가능 명령들은 관리 작업을 자동화하기 위한 방법을 제공하며, 상기 방법은

적어도 하나의 명령에 대한 수신 입력을 수신하는 단계;

상기 입력을 분석하여 하나의 cmdlet를 식별하는 단계;

입력 소스로부터의 정보로 상기 cmdlet 내에 정의된 파라미터를 팝퓰레이트하는 단계;

상기 cmdlet를 실행하여 객체 스트림을 생성하는 단계; 및

상기 객체 스트림을 출력하는 단계를 포함하는 시스템.
제16항에 있어서, 상기 입력 소스는 다른 cmdlet에 의해 생성되는 객체 스트림을 포함하는 시스템.
컴퓨팅 장치 상에서 동작하도록 구성된 관리 프레임워크에 있어서,

입력을 수신하기 위한 수단;

상기 입력을 적어도 하나의 cmdlet로 분석하기 위한 수단 - 상기 cmdlet는 입력 소스와 연관된 적어도 하나의 예측 입력 파라미터를 기술하기 위한 수단을 제공함 - ;

각각의 예측 입력 파라미터를 팝퓰레이트하기 위한 수단; 및

상기 입력 소스가 다른 cmdlet에 의해 생성되는 출력 스트림을 포함하는 방식으로 상기 cmdlet를 처리하기 위한 수단을 포함하는 관리 프레임워크.
제18항에 있어서, 상기 하나의 cmdlet 및 상기 다른 cmdlet는 동일 프로세스 내에서 실행되는 관리 프레임워크.
제18항에 있어서, 상기 객체 스트림은 .NET 객체들을 포함하는 관리 프레임워크.
제18항에 있어서, 상기 cmdlet의 처리는 상기 객체 스트림으로부터 얻어지는 정보로 적어도 하나의 예측 입력 특성을 팝퓰레이트하는 것을 포함하는 관리 프레 임워크.
제18항에 있어서, 상기 적어도 하나의 cmdlet는 상기 관리 프레임워크에 의해 제공되는 기본 cmdlet를 포함하는 관리 프레임워크.
제18항에 있어서, 상기 적어도 하나의 cmdlet는 삼자 개발자에 의해 제공되는 삼자 cmdlet를 포함하는 관리 프레임워크.
제18항에 있어서, 원격 컴퓨팅 장치 상의 cmdlet에 액세스하기 위한 수단을 더 제공하는 관리 프레임워크.
컴퓨터에 의해 실행될 때 다음 단계들을 수행하는 명령들을 구비한 컴퓨터 판독 가능 매체에 있어서,

사용자 입력을 수신하는 단계;

사용자 입력을 관리 도구 프레임워크에 의해 인식되는 입력 포맷으로 변환하는 단계; 및

상기 입력 포맷을 상기 관리 도구 프레임워크로 전송하는 단계를 포함하고,

상기 관리 도구 프레임워크는

상기 입력 포맷을 분석하고;

상기 입력에 기초하여, 예측 입력 파라미터를 지정하는 cmdlet를 인스턴스화 하고;

입력 소스로부터의 상기 예측 입력 파라미터를 팝퓰레이트하도록 구성된 컴퓨터 판독 가능 매체.
제25항에 있어서, 상기 입력 소스는 상기 입력 포맷을 포함하는 컴퓨터 판독 가능 매체.
제25항에 있어서, 상기 입력 소스는 다른 cmdlet로부터 발행되는 입력 스트림을 포함하는 컴퓨터 판독 가능 매체.
제25항에 있어서, 호스트 애플리케이션과 상기 관리 도구 프레임워크 사이의 인터페이스를 제공하는 호스트 cmdlet를 제공하는 단계를 더 포함하는 컴퓨터 판독 가능 매체.
제25항에 있어서, 상기 사용자 입력은 음성 입력을 포함하는 컴퓨터 판독 가능 매체.
제25항에 있어서, 상기 사용자 입력은 명령 라인 상에 입력되는 명령 스트링을 포함하는 컴퓨터 판독 가능 매체.