KR101150059B1 - 커맨드 라인 명령에 확장된 기능을 제공하는 메커니즘 - Google Patents

Abstract

본 발명의 메커니즘은 커맨드 라인 운용 환경에서 커맨드 라인 상에 입력되는 커맨드들이 제 1 실행 모드 또는 다른 실행 모드에서 실행될 수 있도록 한다. 커맨드가 다른 실행 모드에서 실행되는 인스트럭션을 포함하는 경우에 커맨드는 다른 실행 모드에서 실행된다. 다른 실행 모드는 운영 환경에 의해서 제공되며, 커맨드에 확장된 기능을 제공한다. 다른 실행 모드는 커맨드 실행 결과를 시각적으로 디스플레이하고, 커맨드 실행의 시뮬레이션된 결과를 시각적으로 디스플레이하고, 커맨드를 실행하기 전에 검증을 촉구하며, 실행을 요청하는 사용자가 커맨드를 실행할 충분한 권한을 가지는지 여부를 판정하는 등을 수행할 수 있다.

커맨드 라인, 확장된 기능, 파이프라인 시퀀스

Description

커맨드 라인 명령에 확장된 기능을 제공하는 메커니즘{MECHANISM FOR PROVIDING EXTENDED FUNCTIONALITY TO COMMAND LINE INSTRUCTIONS}

본 발명은 커맨드 라인 환경에 관한 것으로, 특히 커맨드 라인 환경 내의 커맨드의 처리에 관한 것이다.

커맨드 라인 환경에 있어서, 커맨드 라인 인터페이스는 커맨드를 입력함으로써 사용자가 직접 업무를 수행하는 것을 가능하게 한다. 예컨대, 커맨드 라인 인터페이스가 호출되어 프롬프트(예컨대, "C:\>")를 디스플레이하는 윈도우를 제공할 수 있을 것이다. 사용자는 커맨드를 실행하도록 하기 위하여 프롬프트에, 예컨대 "dir"과 같은 커맨드를 타이핑할 수 있을 것이다. 몇몇 커맨드들은 보다 복잡한 업무를 수행하도록 함께 파이프라이닝될 수 있을 것이다. 이들 파이프라이닝(pipelining)된 커맨드들이 매우 복잡한 커맨드 라인 명령들을 가지는 것은 매우 통상적인 일이다.

커맨드 라인 인터페이스에 있어서의 한가지 단점은 커맨드 라인 인터페이스에 의해서 유용한 정보가 나타나지 않기 때문에 사용자가 입력할 정확한 커맨드 라인 명령들을 알아야만 한다는 것이다. 인쇄상의 오류와 같은 무의식 중에 행한 오류가 커맨드 라인 명령들 중 하나에 대하여 입력되는 경우에는, 그 업무는 사용자 가 예상할 수 없는 방식으로 수행될 수 있을 것이다.

따라서, 커맨드 라인 명령들을 입력하는 사용자를 돕는 메커니즘에 대한 요구가 발생하게 된다.

발명의 요약

본 발명의 메커니즘은 커맨드 라인 운영 환경에서 커맨드 라인 상에 입력된 커맨드들이 제 1 실행 모드 또는 다른 실행 모드에서 실행하는 것을 가능케한다. 커맨드가 다른 실행 모드에서 실행되는 명령을 포함하는 경우에는 커맨드는 다른 실행 모드에서 실행된다. 다른 실행 모드는 운영 환경에 의해서 제공되며, 확장된 기능을 커맨드에 제공한다. 다른 실행 모드는 커맨드의 실행 결과를 시각적으로 디스플레이하고, 시뮬레이션된 커맨드의 실행 결과를 시각적으로 디스플레이하고, 커맨드를 실행하기 전에 인증을 촉구할 수 있으며, 실행을 요청하는 사용자가 커맨드를 실행할 충분한 권한을 가졌는지 여부를 판정하는 보안 검사 등을 수행할 수 있다. 따라서, 운영 환경에 의해서 제공되는 확장된 기능은 커맨드 라인 명령을 입력하는 사용자를 돕지만, 개발자가 확장 코드를 커맨드내에 기록할 것을 요구하지는 않는다.

도 1은 예시적인 관리 도구 환경을 사용할 수 있는 예시적인 컴퓨팅 장치를 나타내는 도면.

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

도 3은 도 2의 관리 도구 프레임워크의 호스트 특정 컴포넌트 내의 컴포넌트를 나타내는 블록도.

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

도 5는 도 2에 도시된 관리 도구 프레임워크 내에서 사용하기 적합한 cmdlet를 규정하는 예시적인 데이터 구조.

도 6은 도 5에 나타낸 cmdlet가 유도되는 커맨드 베이스형을 규정하는 예시적인 데이터 구조.

도 7은 도 2에 도시된 관리 도구 프레임워크 내에 사용하기 적합한 cmdlet를 규정하는 예시적인 데이터 구조.

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

도 9는 도 2에 도시된 관리 도구 프레임워크 내에 수행되는 입력 조작에 대한 예시적인 프로세스를 나타내는 논리 흐름도.

도 10은 도 9에 도시된 입력 조작 프로세스에서 사용하기 적합한 스크립트 처리 프로세스를 나타내는 논리 흐름도.

도 11은 도 10에 도시된 스크립트 선처리 프로세스를 나타내는 논리 흐름도.

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

도 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 섹션은 관리 도구 환경에 대한 예시적인 프레임워크를 나타낸다. 후속 섹션들은 예시적인 프레임워크의 개별 컴포넌트들과 이들 컴포넌트의 동작을 나타낸다. 예를 들어, 도 6과 관련하여, "Cmdlet를 실행하는 예시적인 프로세스"에 대한 섹션은 커맨드 라인 명령에 대한 확장된 기능을 제공하는 예시적인 메커니즘을 설명한다.

예시적인 컴퓨팅 환경

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

컴퓨팅 장치(100)는 추가의 특성 또는 기능을 가질 수 있다. 예를 들어, 컴퓨팅 장치(100)는 예를 들면 자기 디스크, 광 디스크, 또는 테이프 등의 추가 데이터 저장 장치(분리형 및/또는 비분리형)을 포함할 수 있다. 이러한 추가 저장 장치는 분리형 저장 장치(109)와 비분리형 저장 장치(110)로 도 1에 도시되어 있다. 컴퓨터 저장 매체는 컴퓨터 판독가능 명령, 데이터 구조, 프로그램 모듈, 또는 기타 데이터 등의 정보의 저장을 위한 임의의 방법 또는 기술로 구현되는 휘발성 및 비휘발성, 분리형 및 비분리형 매체를 포함할 수 있다. 시스템 메모리(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)는 관련 애플리케이션에 대한 자동 특성(automation feature)을 사용자 또는 다른 프로그램에 노출시키는 하나 이상의 호스트 프로그램[예를 들어, 호스트 프로그램(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 내지 214)은 자기 자신의 특정 호스트 cmdlet 세트[예를 들어, 호스트 cmdlet(218)]를 제공할 수 있다. 예를 들어, 호스트 프로그램이 이메일 프로그램인 경우, 호스트 프로그램은 메일박스 및 메시지와 인터랙션하는 호스트 cmdlet를 제공할 수 있다. 도 2가 호스트 프로그램(210 내지 214)을 나타내고 있지만, 당업자는 호스트 컴포넌트(202)가 기존의 또는 새롭게 작성된 애플리케이션에 관련된 다른 호스트 프로그램들을 포함할 수 있음을 알 것이다. 또한, 이러한 다른 호스트 프로그램들은 관리 도구 환경에 의해 제공되는 기능을 그들의 관련 애플리케이션 내에 내장한다. 호스트 프로그램에 의해 제공되는 처리는 이하에서 도 8을 참조하여 보다 상세하게 설명한다.

도 2에 도시된 예에서, 호스트 프로그램은 간단하고 지속적인 관리 사용자 인터페이스를 제공하여, 사용자가 컴퓨팅 장치의 하드웨어, 소프트웨어 및 네트워크 컴포넌트를 관리하는 관리 도구를 생성하고 저장하고 열게 하는 관리 컨솔[즉, 호스트 프로그램(210)]일 수 있다. 이러한 펑션들을 달성하기 위해서, 호스트 프로그램(210)은 관리 GUI를 구축하는 일련의 서비스를 관리 도구 프레임워크 상부에 제공한다. GUI 인터랙션은 관리 도구 환경에 의해 제공되는 스크립팅 기능들을 사용자에게 알려주는 것을 돕는 사용자 가시성 스크립트로서 노출될 수 있다.

다른 예에서, 호스트 프로그램은 커맨드 라인 인터랙션 쉘[즉, 호스트 프로그램(212)]일 수 있다. 커맨드 라인 인터랙션 쉘은 쉘 메타데이터(216)가 커맨드 라인 상에 입력되어 커맨드 라인의 처리에 영향을 미칠 수 있게 해 준다.

또다른 예에서, 호스트 프로그램은 플랫폼, 프로그램 언어 및 애플리케이션들 간의 분산 컴퓨팅 및 상호 호환성에 대한 산업 표준 규격을 사용하는 웹 서비스[즉, 호스트 프로그램(214)]일 수 있다.

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

호스트 특정 컴포넌트

호스트 특정 컴포넌트(204)는 프레임워크가 실행 중인 플랫폼의 특성으로부터 관리 도구 프레임워크를 분리하기 위하여 컴퓨팅 시스템[예를 들어, 도 1의 컴퓨팅 장치(100)]이 사용하는 서비스들의 컬렉션을 포함한다. 따라서, 각 플랫폼 유형에 대하여 호스트 특정 컴포넌트들의 세트가 존재한다. 호스트 특정 컴포넌트는 사용자가 상이한 운영 체계들에서 동일 관리 도구를 사용할 수 있게 한다.

도 3을 간단히 참조하면, 호스트 특정 컴포넌트(204)는 인텔리센스(intellisense)/메타데이터 액세스 컴포넌트(302), 도움말 cmdlet 컴포넌트(304), 구성/등록 컴포넌트(306), cmdlet 설정 컴포넌트(308), 및 출력 인터페이스 컴포넌트(309)를 포함할 수 있다. 컴포넌트들(302 내지 308)은 데이터베이스 저장소(314)에 관련된 데이터베이스 저장소 관리자(312)와 통신한다. 파서(220)와 스크립트 엔진(222)은 인텔리센스/메타데이터 액세스 컴포넌트(302)와 통신할 수 있다. 코어 엔진(224)은 도움말 cmdlet 컴포넌트(304), 구성/등록 컴포넌트(306), cmdlet 설정 컴포넌트(308), 및 출력 인터페이스 컴포넌트(309)와 통신한다. 출력 인터페이스 컴포넌트(309)는 호스트에 의해 제공되는 아웃 cmdlet로의 인터페이스를 포함한다. 이들 아웃 cmdlet는 그 후 호스트의 출력 객체를 호출하여 렌더링을 수행할 수 있다. 호스트 특정 컴포넌트(204)는 코어 엔진(224)이 사용하는 로깅(logging)/감사(auditing) 컴포넌트(310)를 포함하여 로깅 및 감사 특성을 제공하는 호스트 특정(즉, 플랫폼 특정) 서비스와 통신할 수 있다.

예시적인 관리 도구 프레임워크에서, 인텔리센스/메타데이터 액세스 컴포넌트(302)는 커맨드, 파라미터 및 파라미터 값의 자동 완성을 제공한다. 도움말 cmdlet 컴포넌트(304)는 호스트 사용자 인터페이스에 기초하여 개별화된 도움말 시스템을 제공한다.

핸들러 컴포넌트

도 2를 다시 참조하면, 핸들러 컴포넌트(208)는 레거시 유틸리티(2330), 관리 cmdlet(232), 비관리(non-management) cmdlet(234), 원격 cmdlet(236), 및 웹 서비스 인터페이스(238)를 포함한다. 관리 cmdlet(232; 플랫폼 cmdlet로도 불림)는 컴퓨팅 장치에 관련된 구성 정보를 쿼리 또는 조작하는 cmdlet를 포함한다. 관리 cmdlet(232)는 시스템 유형 정보를 다루기 때문에, 이들은 특정 플랫폼에 의존한다. 그러나, 각 플랫폼은 통상적으로 다른 플랫폼 상의 관리 cmdlet(232)와 유사한 동작을 제공하는 관리 cmdlet(232)를 갖는다. 예를 들어, 각 플랫폼은 시스템 관리 도구 속성을 얻고 설정하는 관리 cmdlet(232)(예를 들어, get/process, set/IPAddress)를 지원한다. 호스트 독립 컴포넌트(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는 프로세스 밖에서(out of process) 동작할 수 있다.

원격 cmdlet(236)는 서비스 인터페이스(238)와 함께 인터넷 또는 인트라넷[예를 들어, 도 2에 도시된 인터넷/인트라넷(240)] 등의 통신 매체를 통해 다른 컴퓨팅 장치 상에 있는 인터랙티브 프로그램 관리 도구 환경에 액세스하기 위한 원격 메커니즘을 제공한다. 예시적인 관리 도구 프레임워크에서, 원격 메커니즘은 여러 독립 제어 영역에 걸친 기반구조에 의존하는 연합 서비스를 지원한다. 원격 메커니즘은 스크립트가 원격 컴퓨팅 장치 상에서 실행할 수 있게 한다. 스크립트는 단일 또는 복수의 원격 시스템 상에서 실행될 수 있다. 다양한 컴퓨팅 장치 상의 모든 스크립트가 완료된 후에 각 개별 스크립트가 완료된 때에 스크립트의 결과가 처리될 수도 있고, 또는 그 결과들이 수집되어 한꺼번에 처리될 수도 있다.

예를 들어, 호스트 컴포넌트(202) 중 하나로서 도시된 웹 서비스(214)는 원격 에이전트일 수 있다. 원격 에이전트는 타겟 시스템 상의 파서 및 관리 도구 프레임 워크에 대한 원격 커맨드 요청의 제출을 다룬다. 원격 cmdlet는 원격 에이전트에 액세스를 제공하는 원격 클라이언트로서 동작한다. 원격 에이전트와 원격 cmdlet는 파싱된 스트림을 통해 통신한다. 이 파싱된 스트림은 프로토콜 계층에서 보호될 수 있으며, 또는 추가 cmdlet가 파싱된 스트림을 암호화 후 복호화하는데 사용될 수 있다.

호스트 독립 컴포넌트

호스트 독립 컴포넌트(206)는 파서(220), 스크립트 엔진(222) 및 코어 엔진(224)을 포함한다. 호스트 독립 컴포넌트(206)는 다수의 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)는 커맨드 라인의 처리 동안 각 에러의 발생에 대한 정보를 저장하기 위한 에러 객체를 제공한다. 본 발명의 관리 도구 프레임워크에 특히 적합한 하나의 특정 에러 및 이벤트 프로세서에 대한 추가 정보에 대하여, 본 발명과 동일한 양수인이 소유하는 미국 특허출원번호 제10/413,054호 "System and Method for Persisting Error Information in a Command Line Environment"에 나타나 있으며, 여기서 참조로서 포함된다.

예시적인 세션 관리자

세션 관리자(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)으로부터 수신된 입력에 대한 처리를 수행하기 위해서 서로 통신한다. 통신은 본질적으로 재귀적(recursive)일 수 있다. 예를 들어, 호스트 프로그램이 스크립트를 제공하는 경우, 스크립트는 cmdlet 관리자(422)를 호출하여 그 자체가 스크립트인 cmdlet를 실행할 수 있다. 그 후, 스크립트는 스크립트 엔진(222)에 의해 실행될 수 있다. 코어 엔진에 대한 하나의 예시적인 프로세스 흐름을 도 4를 참조하여 이하 설명한다.

예시적인 확장된 유형 관리자

상술한 바와 같이, 관리 도구 프레임워크는 객체에 대한 리플렉션과, 리플렉션된 객체에 대하여 (객체) 유형에 독립적인 처리를 허용하는 일련의 유틸리티를 제공한다. 관리 도구 프레임워크(200)는 컴퓨팅 시스템 상의 컴포넌트 프레임워크[도 1의 컴포넌트 프레임워크(120)]와 인터랙션하여 이러한 리플렉션을 수행한다. 당업자가 이해할 수 있는 바와 같이, 리플렉션은 객체에 쿼리를 행하고, 그 객체에 대한 유형을 획득하며, 그 후, 그러한 객체 유형에 관련된 다양한 객체와 속성을 리플렉션하여 다른 객체 및/또는 원하는 값을 획득할 수 있는 성능을 제공한다.

리플렉션이 객체에 대한 상당한 양의 정보를 관리 도구 프레임워크(200)에 제공하긴 하지만, 본 발명자들은 리플렉션이 객체의 유형에 집중한다는 것을 확인하였다. 예를 들어, 데이터베이스 데이터테이블이 리플렉션되는 경우, 리턴되는 정보는 테이터표이 두가지 속성, 즉 열 속성과 행 속성을 갖는다는 것이다. 이들 두 속성은 데이터테이블 내의 "객체"에 대한 충분한 세부사항을 제공하지 않는다. 리플렉션이 확장된 유형 마크업 언어(XML) 및 다른 객체에 대하여 사용되는 경우에도 마찬가지의 문제점이 발생한다.

따라서, 본 발명자들은 유형의 사용에 대하여 집중하는 확장된 유형 관리자(412)를 생각해냈다. 이러한 확장된 유형 관리자에 있어서, 객체의 유형은 중요하지 않다. 그 대신, 확장된 유형 관리자는 객체가 요구되는 정보를 획득하는 데에 사용될 수 있는지에 관심이 있다. 상기 데이터테이블 예를 계속하면, 본 발명자들은 데이터테이블이 열 속성과 행 속성을 갖는다고 인지하는 것은 특별하게 흥미로운 사실은 아님을 확인하였지만, 하나의 열은 관심 정보를 포함한다는 것을 알 수 있었다. 이러한 사용에 집중하여, 각각의 행을 "객체"에 관련시키고, 각각의 열을 그 "객체"의 "속성"에 관련시킬 수 있다. 따라서, 확장된 유형 관리자(412)는 정확하게 파싱가능한 입력의 임의의 유형으로부터 "객체"를 생성하는 메커니즘을 제공한다. 이렇게 함으로써, 확장된 유형 관리자(412)는 컴포넌트 기반 프레임워크(120)에 의해 제공되는 리플렉션 성능을 보충하여 정확하게 파싱가능한 입력의 임의 유형으로 "리플렉션"을 확장한다.

요컨대, 확장된 유형 관리자는 정확하게 파싱가능한 입력(미도시)에 액세스하고, 그러한 정확하게 파싱가능한 입력을 요청되는 데이터 유형과 상관시키도록 구성된다. 확장된 유형 관리자(412)는 그 후 파이프라인 프로세서(402) 또는 파서(220) 등의 요청 컴포넌트에 요청된 정보를 제공한다. 이하의 설명에서, 정확하게 파싱가능한 입력은 속성과 값이 인지될 수 있는 입력으로서 정의된다. 정확하게 파싱가능한 입력의 몇몇 예로는, 윈도우즈 관리 계측(WMI) 입력, ActiveX 데이터 객체(ADO) 입력, 확장된 마크업 언어(XML) 입력, 및 .NET 객체와 같은 객체 입력이 포함된다. 다른 정확하게 파싱가능한 입력은 제3자 데이터 포맷을 포함할 수 있다.

도 18을 간단히 참조하면, 관리 도구 프레임워크 내에서 사용되는 예시적인 확장된 유형 관리자의 기능 블록도가 도시되어 있다. 설명의 목적을 위해, 확장된 유형 관리자에 의해 제공되는 기능(③으로 표시됨)은, 종래의 강하게 결합된 시스템(tightly bound system)에 의해 제공되는 기능(①로 표시됨) 및 리플렉션 시스템(②로 표시됨)에 대비된다. 종래 강하게 결합된 시스템에서, 애플리케이션 내의 호출자(1802)는 객체 A 내의 정보(예를 들어, 속성 P1 및 P2, 메소드 M1 및 M2)에 직접 액세스한다. 상술한 바와 같이, 호출자(1802)는 컴파일 시에 객체 A에 의해 제공되는 속성(예를 들어, 속성 P1 및 P2)과 메소드(예를 들어, 메소드 M1 및 M2)를 미리 알아야만 한다. 리플렉션 시스템에서, 일반 코드(1820; 임의의 데이터 유형에 독립)는, 요청된 객체에 대하여 리플렉션(1810)을 수행하고 객체(예를 들어, 객체 A)에 대한 정보(예를 들어, 속성 P1 및 P2, 메소드 M1 및 M2)를 일반 코드(1820)에 리턴하는 시스템(1808)에 쿼리를 행한다. 객체 A에는 도시하지 않지만, 리턴되는 정보는 벤더, 파일, 날짜 등과 같은 추가 정보를 포함할 수 있다. 따라서, 리플렉션을 통해, 일반 코드(1820)는 적어도 강하게 결합한 시스템이 제공하는 것과 동일한 정보를 획득한다. 리플렉션 시스템은 또한 호출자(1802)가 시스템에 쿼리를 행하여, 파라미터에 관한 임의의 사전 지식없이도 추가 정보를 획득할 수 있게 한다.

강하게 결합된 시스템과 리플렉션 시스템에서, 새로운 데이터 유형은 운영 환경 내에서 용이하게 통합될 수 없다. 예를 들어, 강하게 결합된 시스템에서, 일단 운영 환경이 전달되고 나면, 새로운 데이터 유형을 지지하기 위해서는 운영 환경이 재구축되어야 하기 때문에, 운영 환경은 새로운 데이터 유형을 포함할 수 없다. 마찬가지로, 리플렉션 시스템에서, 각 객체 클래스의 메타데이터는 고정된다. 따라서, 새로운 데이터 유형의 포함은 통상적으로 행해지지 않는다.

그러나, 본 발명의 확장된 유형 관리자에 있어서는, 새로운 데이터 유형이 운영 체계 내에 포함될 수 있다. 확장된 유형 관리자(1822)를 사용하여, 일반 코드(1820)는 요청된 객체를 반영하여 제3자 객체(예를 들어, 객체 A' 및 B), 시맨틱 웹(1832), 온톨로지(ontology) 서비스(1834) 등과 같이 여러 외부 소스에 의해 제공되는 확장 데이터 유형(예를 들어, 객체 A')을 획득한다. 도시한 바와 같이, 제3자 객체는 기본 객체(예를 들어, 객체 A')를 확장할 수 있거나, 완전히 새로운 객체(예를 들어, 객체 B)를 생성할 수 있다.

이들 외부 소스 각각은 유형 메타데이터(1840) 내의 고유 구조를 등록할 수 있으며 코드(1842)를 제공할 수 있다. 객체가 쿼리되는 경우, 확장된 유형 관리자는 유형 메타데이터(1840)를 검토하여 객체가 등록되었는지를 판정한다. 객체가 유형 메타데이터(1840) 내에 등록되어 있지 않으면, 리플렉션이 수행된다. 그렇지 않으면, 확장된 리플렉션이 수행된다. 코드(1842)는 리플렉션되는 유형에 관련된 추가 속성 및 메소드를 리턴한다. 예를 들어, 입력 유형이 XML인 경우, 코드(1842)는 XML이 XML 문서로부터 객체를 생성하는 데에 사용되는 방식을 나타내는 디스크립션 파일을 포함한다. 따라서, 유형 메타데이터(1840)는, 확장된 유형 관리자(412)가 특정 입력 유형에 대한 객체를 생성하기 위해 원하는 속성을 획득하기 위하여, 여러 유형의 정확하게 파싱가능한 입력[예를 들어, 제3자 객체 A' 및 B, 시맨틱 웹(1832)]을 어떻게 쿼리하는지를 기술하고, 코드(1842)는 이러한 원하는 속성을 획득하기 위한 명령어들을 제공한다. 그 결과, 확장된 유형 관리자(412)는 모든 객체의 유형에 대한 "리플렉션"을 가능하게 하는 간접의 계층을 제공한다.

확장된 유형의 제공에 더하여, 확장된 유형 관리자(412)는 속성 경로 메커니즘, 키 메커니즘, 비교 메커니즘, 전환 메커니즘, 글로버(globber) 메커니즘, 속성 설정 메커니즘, 관계 메커니즘 등과 같은 추가의 쿼리 메커니즘을 제공한다. "예시적인 확장된 유형 관리자 처리" 섹션 내의 후술하는 이들 쿼리 메커니즘 각각은 커맨드 스트링을 입력할 때에 시스템 관리자에게 유연성을 제공한다. 다양한 기술이 확장된 유형 관리자에 대한 시멘틱을 구현하는 데 사용될 수 있다. 3개의 기술이 이하 설명된다. 그러나, 당업자는 이들 기술의 변형이 본 발명의 범위로부터 벗어나지 않으면서 사용될 수 있음을 알 것이다.

한 기술에서, 정적 메소드[예를 들어, getproperty()]를 갖는 일련의 클래스가 제공될 수 있다. 객체는 정적 메소드[예를 들어, getproperty(객체)]로 입력되고, 정적 메소드는 일련의 결과를 리턴한다. 다른 기술에서, 운영 환경은 어댑터를 사용하여 객체를 엔벨로프(envelope)한다. 따라서, 어떤 입력도 제공되지 않는다. 어댑터의 각 인스턴스는 엔벨로프된 객체에 대하여 적용되는 getproperty 메소드를 가지며 엔벨로프된 객체에 대한 속성을 리턴한다. 다음은 이 기술을 나타내는 의사 코드이다:

Class Adaptor

{

Object X;

getProperties();

}

또 다른 기술에서, 어댑터 클래스는 객체를 세분화(subclass)한다. 통상적으로, 세분화는 컴파일 전에 발생한다. 그러나, 특정 운영 환경에서, 세분화가 동적으로 발생할 수 있다. 이러한 유형의 환경에 대하여, 다음은 이 기술을 나타내는 의사 코드이다:

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 클래스 이름[예를 들어, StopPreocess(504)]을 갖는 공개 클래스이다. cmdlet(500)는 cmdlet 클래스(506)로부터 유도한다. cmdlet 클래스(506)에 대한 예시적인 데이터 구조는 도 6을 참조하여 이하 설명한다. 각 cmdlet(500)는 cmdlet(500)와 이름(예를 들어, Stop/Process)을 연관시키는 커맨드 속성(502)과 관련된다. 이 이름은 관리 도구 환경 내에서 등록된다. 이하 설명되는 바와 같이, 파서는 cmdlet 레지스트리를 조사하여 이름(예를 들어, 정지/처리)을 갖는 커맨드 스트링이 스크립 내에 또는 커맨드 라인 상의 입력으로서 제공되는 경우에 cmdlet(500)를 식별한다.

cmdlet(500)는 cmdlet로의 예측 입력 파라미터에 대한 문법을 정의하는 문법 메커니즘과 관련된다. 문법 메커니즘은 cmdlet와 직접 또는 간접적으로 관련될 수 있다. 예를 들어, cmdlet(500)는 직접 문법 연관을 나타낸다. 이러한 cmdlet(500)에서, 하나 이상의 공개 파라미터[예를 들어, ProcessName(510)과 PID(512)]가 선언된다. 공개 파라미터의 선언은 cmdlet(500)에 입력 객체의 파싱을 구동한다. 다르게는, 파라미터의 디스크립션은 XML 문서 등의 외부 소스에 나타날 수 있다. 이러한 외부 소스에서 파라미터의 디스크립션은 cmdlet로의 입력 객체들의 파싱을 구동한다.

각각의 공개 파라미터(510, 512)는 그에 관련된 하나 이상의 속성[즉, 지시어(directive)]을 가질 수 있다. 이 지시어는 다음 카테고리들, 즉 파싱 지시어(521), 데이터 검증 지시어(522), 데이터 생성 지시어(523), 처리 지시어(524), 인코딩 지시어(525), 및 문서화 지시어(526) 중 임의의 것일 수 있다. 이 지시어는 대괄호(square bracket) 내에 포함될 수 있다. 각 지시어는 다음 예측 입력 파라미터에 대하여 수행될 동작을 나타낸다. 일부 지시어는 사용자 인터랙션 유형 지시어 등의 클래스 레벨에서 적용될 수 있다. 이 지시어들은 cmdlet와 관련되어 메타데이터에 저장된다. 이들 속성의 적용은 도 12를 참조하여 나중에 설명한다.

이들 속성은 cmdlet 내에 선언된 파라미터들의 채우기에 영향을 미칠 수 있다. 이들 파라미터를 채우는 하나의 예시적인 프로세스는 도 16을 참조하여 나중에 설명한다. 코어 엔진은 순응성을 보장하기 위하여 이들 지시어를 적용할 수 있다. cmdlet(500)는 제1 메소드(530)[이하, StartProcessing 메소드(530)로도 불림]와 제2 메소드(540)[이하, ProcessRecord 메소드(540)로도 불림]를 포함한다. 코어 엔진은 제1 및 제2 메소드(530, 540)를 사용하여 cmdlet(500)의 처리를 유도한다. 예를 들어, 제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가 후크 문장(hook statement)을 포함하고, 대응 스위치가 커맨드 라인 상에 또는 스크립트 내에(커맨드 입력으로도 불림) 입력될 때마다, 추가 기능을 제공하는 명령어들을 포함한다.

예시적인 데이터 구조(600)는 부울 파라미터 verbose(610), whatif(620) 및 Confirm(630) 등의 파라미터를 포함한다. 이하 설명되는 바와 같이, 이들 파라미터는 커맨드 입력 상에 입력될 수 있는 스트링에 대응한다. 예시적인 데이터 구조(600)는 실행 요청된 작업이 허용되는지를 판정하는 보안 메소드(640)도 포함할 수 있다.

도 7은 cmdlet를 규정하는 다른 예시적인 데이터 구조(700)이다. 요컨대, 데이터 구조(700)는 관리 도구 프레임워크와 cmdlet 사이의 계약(contract)을 명확하게 표현하는 수단을 제공한다. 데이터 구조(500)와 마찬가지로, 데이터 구조(700)는 cmdlet 클래스(704)로부터 유도하는 공개 클래스이다. 소프트웨어 개발자는 "얻기/처리" 및 "포맷/표" 등의 명사/동사 쌍을 cmdlet(700)에 관련시키는 cmdletDeclaration(702)을 규정한다. 명사/동사 쌍은 관리 도구 환경 내에 등록된다. 동사 또는 명사는 cmdlet 이름 내에 암시될 수 있다. 또한, 데이터 구조(500)와 마찬가지로, 데이터 구조(700)는 하나 이상의 공개 멤버[예를 들어, Name(730) 및 Recurse(732)]를 포함하며, 이들은 데이터 구조(500)와 관련하여 설명된 하나 이상의 지시어(520 내지 526)와 관련될 수 있다.

그러나, 이 예시적인 데이터 구조(700)에서, 각각의 예측된 입력 파라미터(730 및 732)는 입력 속성(731 및 733)과 각각 관련된다. 각각의 파라미터(730 및 732)에 대한 데이터를 규정하는 입력 속성(731 및 733)은 커맨드 라인으로부터 획득될 수 있다. 따라서, 예시적인 데이터 구조(700)에서, 다른 cmdlet에 의해 발행된 파이프라인된 객체로부터 채워진 임의의 예측된 입력 파라미터가 존재하지 않을 수 있다. 따라서, 데이터 구조(700)는 cmdlet 베이스 클래스에 의해 제공되는 제1 메소드(예를 들어, StartProcessing) 또는 제2 메소드(예를 들어, ProcessRecord)를 무효화하지는 않는다.

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

따라서, 데이터 구조(700)에 나타낸 바와 같이, 특정 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는 그 결과를 호스트 프로그램에 의해 지원되는 디스플레이 스타일로 전환한다. 예를 들어, 리턴된 객체는 아이콘, 짖는 개 등의 그래픽 묘사를 사용하여 GUI 호스트 프로그램에 의해 디스플레이될 수 있다. 호스트 cmdlet는 데이터에 대한 출력 및 디폴트 포맷을 제공한다. 디폴트 포맷과 출력은 도 19 내지 도 23을 참조하여 후술하는 예시적인 출력 처리 cmdlet를 사용할 수 있다. 그 결과가 선택적으로 디스플레이된 후에, 호스트 처리가 완료된다.

입력을 처리하는 예시적인 프로세스 흐름

도 9는 도 2에 도시된 관리 도구 프레임워크 내에서 수행되는 입력을 처리하는 예시적인 프로세스를 나타내는 논리 흐름도이다. 처리는 블록(910)에서 시작하며, 입력은 호스트 프로그램을 통해 입력되고 관리 도구 프레임워크 내의 다른 컴포넌트에 전송된다. 처리는 블록(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)에서, 획득된 제약은 관련 구성에 대한 메타데이터 내에 저장된다. 관련 구성은 하나 이상의 특성 토큰(attribution token; 제약을 표시하는 토큰)을 만난 후의 최초의 비특성 토큰(non-attribution token)으로서 식별된다. 처리는 블록(1206)으로 진행한다.

블록(1206)에서, 스크립트 또는 커맨드 스트링 내에서 구성을 만날 때마다, 메타데이터 내에 정의된 제약이 그 구성에 적용된다. 제약은 데이터 유형, 술어 지시어(1201), 문서화 지시어(1212), 파싱 지시어(1214), 데이터 생성 지시어(126), 데이터 검증 지시어(1218), 및 객체 처리 및 인코딩 지시어(1220)를 포함할 수 있다. 데이터 유형을 규정하는 제약은 관리 도구 프레임워크가 동작 중인 시스템에 의해 지원되는 임의의 데이터 유형을 규정할 수 있다. 술어 지시어(1210)는 처리가 발생해야 하는지를 나타내는 지시어이다. 따라서, 술어 지시어(1210)는 환경이 실행을 위해 정정될 것을 보장한다. 예를 들어, 스크립트는 다음 술어 지시어를 포함할 수 있다:

[PredicateScript("isInstalled", "ApplicationZ")]

이러한 술어 지시어는 스크립트를 실행하기 전에 올바른 애플리케이션이 컴퓨팅 장치 상에 설치될 것을 보장한다. 통상적으로, 시스템 환경 변수는 술어 지시어로서 규정될 수 있다. 지시어 유형(1212 내지 1220)의 예시적인 지시어들이 표 1 내지 표 5에 나타나 있다. 그러면, 스크립트의 처리가 완료된다.

따라서, 해석 환경 내에서 유형 및 제약을 적용하는 본 발명의 프로세스는, 시스템 관리자가 해당 처리를 수행하기 위한 하부 논리를 작성할 필요없이 유형을 용이하게 규정하고 검증 요건을 규정하는 것 등을 용이하게 행할 수 있게 한다. 이하에서는, 다음과 같이 규정되는 커맨드 스트링 상에 수행되는 제약 처리의 예가 나타나 있다.

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

"[]"으로 표시되는 특성 토큰을 통해 규정된 두개의 제약이 있다. 제1 특성 토큰은 변수가 유형 정수(type integer)임을 나타내고, 제2 특성 토큰은 변수 $a의 값이 반드시 3 내지 5 사이에 있어야만 한다는 것을 나타낸다. 예시적인 커맨드 스트링은, 변수 $a가 후속하는 커맨드 스트링 또는 라인 내에 할당되는 경우, 그 변수 $a가 두개의 제약에 대하여 검사될 것을 보장한다. 따라서, 다음과 같은 커맨드 스트링은 각각 에러가 된다.

$a=231

$a="apple"

$a=$(get/location).

제약은 관리 도구 프레임워크 내에서 여러 단계에서 적용된다. 예를 들어, 적용가능성 지시어, 문서화 지시어, 및 파싱 가이드라인 지시어는 파서 내에서 매우 초기의 단계에서 처리된다. 데이터 생성 지시어 및 검증 지시어는 파서가 모든 입력 파라미터의 파싱을 완료한 후에 엔진에서 처리된다.

다음 표는 다양한 카테고리에 대한 대표 지시어와 함께, 그 지시어에 응답하여 관리 도구 환경에 의해 수행되는 처리의 디스크립션을 나타낸 것이다.

이름	디스크립션
PrerequisiteMachineRoleAttribute	요소가 특정 머신 역할(예를 들어, 파일 서버, 메일 서버)에서만 사용되는지를 쉘에 알림
PrerequisiteUserRoleAttribute	요소가 특정 사용자 역할(예를 들어, 도메인 관리자, 백업 운영자)에서만 사용되는지를 쉘에 알림
PrerequisiteScriptAttribute	실재 커맨드 또는 파라미터를 실행하기 전에 이 스크립트가 실행될 수 있음을 쉘에 알림. 파라미터 검증을 위해 사용될 수 있음.
PrerequisiteUITypeAttribute	실행 전에 이용가능한 사용자 인터페이스를 검사하는 데 사용됨.

<적용가능성 지시어>

이름	디스크립션
ParsingParameterPositionAttribute	위치에 기초하여 비적격 파라미터를 매핑
ParsingVariableLengthParameterListAttribute	Parsing ParameterPosition 속성을 갖지 않는 파라미터를 매핑
ParsingDisallowInteractionAttribute	파라미터 개수가 필요한 개수보다 적은 경우 동작을 규정
ParsingRequireInteractionAttribute	파라미터가 인터랙션을 통해 획득됨을 규정
ParsingHiddenElementAttribute	파라미터가 최종 사용자에 보이지 않게 함
ParsingMandatoryParameterAttribute	파라미터가 요구됨을 규정
ParsingPasswordParameterAttribute	파라미터의 특별한 처리를 요구
ParsingPromptStringAttribute	파라미터에 대한 프롬프트를 규정
ParsingDefaultAnswerAttribute	파라미터에 대한 디폴트 응답을 규정
ParsingDefaultAnswerScriptAttribute	파라미터에 대한 디폴트 응답을 획득하는 동작을 규정
ParsingDefaultValueAttribute	파라미터에 대한 디폴트값을 규정
ParsingDefaultValueScriptAttribute	파라미터에 대한 디폴트값을 획득하는 동작을 규정
ParsingParameterMappingAttribute	파라미터를 그룹화하는 방식을 규정
ParsingParameterDeclarationAttribute	필드가 파라미터임을 정의
ParsingAllowPipelineInputAttribute	파라미터가 파이프라인으로부터 채워질 수 있음을 정의

<파싱 가이드라인 지시어>

이름	디스크립션
DocumentNameAttribute	인터랙션 또는 도움말에 대한 요소를 나타내는 임을 제공
DocumentShortDescriptionAttribute	요소의 간단한 디스크립션을 제공
DocumentLongDescriptionAttribute	요소의 상세한 디스크립션을 제공
DocumentExampleAttribute	요소의 예를 제공
DocumentSeeAlsoAttribute	관련 요소의 리스트를 제공
DocumentSynopsisAttribute	요소에 대한 문서화 정보를 제공

<문서화 지시어>

이름	디스크립션
ValidationRangeAttribute	파라미터가 특정 범위 내에 있어야 함을 규정
ValidationSetAttribute	파라미터가 특정 컬렉션 내에 있어야 함을 규정
ValidationPatternAttribute	파라미터가 특정 패턴에 맞아야 함을 규정
ValidationLengthAttribute	스트링이 크기 범위 내에 있어야 함을 규정
ValidationTypeAttribute	파라미터가 특정 유형이어야 함을 규정
ValidationCountAttribute	입력 항목이 특정 수이어야 함을 규정
ValidationFileAttribute	파일에 대한 특정 속성을 규정
ValidationFileAttributesAtribute	파일에 대한 특정 속성을 규정
ValidationFileSizeAttribute	파일이 규정된 범위 내에 있어야 함을 규정
ValidationNetworkAttribute	주어진 네트워크 엔티티가 특정 속성을 지원함을 규정
ValidationScriptAttribute	요소 사용 전에 평가할 조건을 규정
ValidationMethodAttribute	요소 사용 전에 평가할 조건을 규정

<데이터 검증 지시어>

이름	디스크립션
ProcessingTrimStringAttribute	스트링에 대한 크기 한도를 규정
ProcessingTrimCollectionAttribute	모음에 대한 크기 한도를 규정
EncodingTypeCoercionAttribute	객체가 인코딩되어야 하는 유형을 규정
ExpansionWildcardsAttribute	글로빙(globbing)이 가능한 메커니즘을 제공

<처리 및 인코딩 지시어>

예시적인 관리 도구 프레임워크가 .NET^TM 프레임워크 내에서 동작하는 경우, 각 카테고리는 기본 카테고리 클래스(예를 들어, CmdAttribute)로부터 유도되는 베이스 클래스를 갖는다. 기본 카테고리 클래스는 System.Attribute 클래스로부터 유도한다. 각 카테고리는 카테고리 처리 동안 파서에 의해 호출되는 소정의 펑션[예를 들어, attrib.func()]을 갖는다. 스크립트 작성자는 커스텀 카테고리 클래스(예를 들어, CmdCustomAttribute)로부터 유도되는 커스텀 카테고리를 생성할 수 있다. 스크립트 작성자는 또한 해당 카테고리에 대한 베이스 카테고리 클래스로부터 지시어 클래스를 유도함으로써 기존 카테고리 클래스를 확장하고, 그 구현으로 소정의 펑션을 무효화(override)할 수 있다. 스크립트 작성자는 지시어를 무효화하고 새로운 지시어를 소정의 지시어 세트에 추가할 수 있다.

이들 지시어의 처리 순서는 파서에 의해 액세스가능한 외부 데이터 저장소 내에 저장될 수 있다. 관리 도구 프레임워크는 등록된 카테고리들을 찾고, 해당 카테고리 내의 각 지시어에 대한 펑션(예를 들어, ProcessCustomDirective)을 호출한다. 따라서, 영구 저장소 내에 카테고리 실행 정보를 저장함으로써, 카테고리 처리의 순서가 동적으로 될 수 있다. 상이한 처리 단계들에서, 파서는 영구 저장소를 검사하여 해당 시점에서 임의의 메타데이터가 실행될 필요가 있는지를 판정한다. 이에 의하여, 영구 저장소로부터 카테고리 엔트리를 제거함으로써, 카테고리가 쉽게 무시될 수 있다.

커맨드 스트링의 예시적인 처리

이하에서는, 커맨드 스트링을 처리하는 예시적인 프로세스를 설명한다. 도 13은 도 2에 도시된 관리 도구 프레임워크 내에서 파서(220) 및 코어 엔진(224)을 통한 커맨드 스트링(1350)의 처리를 도시하는 기능 흐름도이다. 예시적인 커맨드 스트링(1350)은 여러 커맨드[즉, 프로세스 커맨드(1360), 위치 커맨드(1362), 소팅 커맨드(1364), 및 표 커맨드(1366)]를 파이프라인한다. 커맨드 라인(1350)은 임의의 커맨드에 입력 파라미터를 전달할 수 있다[예를 들어, "handlecount>400"이 위치 커맨드(1362)에 전달됨]. 프로세스 커맨드(1360)는 어떠한 관련 입력 파라미터도 갖지 않는다는 점을 알 것이다.

종래에는, 각 커맨드는 커맨드에 관련된 입력 파라미터를 파싱하고, 입력 파라미터가 유효한지를 판정하며, 입력 파라미터가 유효하지 않은 경우 에러 메시지를 발행하는 역할을 한다. 커맨드는 통상적으로 여러 프로그래머들에 의해 작성되었기 때문에, 커맨드 라인 상의 입력 파라미터에 대한 구문은 매우 일관되지 않았다. 또한, 에러가 발생한 경우에, 심지어 동일한 에러에 대한 에러 메시지들도 커맨드들 간에 매우 일관되지 않았다.

예를 들어, UNIX 환경에서, "ls" 커맨드 및 "ps" 커맨드는 불일치하는 점이 많다. 둘 모두 옵션 "-w"를 수용하지만, "ls" 커맨드에 의해 사용되는 "-w" 옵션은 페이지의 폭을 나타내는 반면, "ps" 커맨드에 의해 사용되는 "-w" 옵션은 인쇄 폭 출력을 의미한다(기본적으로, 페이지 폭을 무시). 또한, "ls" 및 "ps" 커맨드에 관련된 도움말 페이지는, 어떤 것은 굵기 옵션을 갖지만 다른 것에서는 그렇지 않고, 어떤 것은 알파벳으로 옵션을 정렬하고 다른 것은 그렇지 않으며, 어떤 옵션을 대시를 갖지만 다른 것은 그렇지 않은 것과 같이, 수가지의 불일치점을 갖는다.

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

본 발명을 더 설명하기 전에, 본 명세서 전반에서 나타나는 추가 용어에 대한 정의가 제공된다. 입력 파라미터는 cmdlet에 대한 입력 필드를 나타낸다. 인수(argument)는 argv 어레이 내의 단일 스트링의 등가인 cmdlet에 전달되거나 cmdlet 객체 내의 단일 요소로서 전달되는 입력 파라미터를 나타낸다. 후술하는 바와 같이, cmdlet는 문법을 규정하는 메커니즘을 제공한다. 메커니즘은 직접 또는 간접적으로 제공될 수 있다. 인수는 커맨드 이름 다음의 옵션, 옵션 인수, 피연산자 중의 하나이다. 인수의 예는 다음 커맨드 라인에 기초하여 주어진다.

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

상기 커맨드 라인에서, "findstr"는 인수 0이고, "/i"는 인수 1, "/d:＼winnt;＼winnt＼system32"는 인수 2, "aa*b"는 인수 3, "*.ini"는 인수 4이다. "옵션"은 프로그램의 디폴트 거동에 대한 변화를 규정하는 데에 일반적으로 사용되는 cmdlet에 대한 인수이다. 상기 예시적인 커맨드 라인을 계속 설명하면, "/i" 및 "/d"는 옵션이다. "옵션-인수"는 특정 옵션을 따르는 입력 파라미터이다. 일부 경우, 옵션 인수는 옵션과 동일한 인수 스트링 내에 포함된다. 다른 경우, 옵션 인수는 다음 인수로서 포함된다. 상기 커맨드 라인을 다시 참조하면, "winnt;＼winnt＼system32"는 옵션 인수이다. 피연산자는 통상적으로 프로그램 처리를 완료하는 데 필요한 정보를 프로그램에 제공하는 객체로서 사용되는 cmdlet에 대한 인수이다. 피연산자는 통상적으로 커맨드 라인 내의 옵션에 뒤따른다. 상기의 예시적인 커맨드 라인을 다시 참조하면, "aa*b" 및 "*.ini"는 피연산자이다. "파싱가능 스트림"은 인수를 포함한다.

도 13을 참조하면, 파서(220)는 파싱가능 스트링[예를 들어, 커맨드 스트링(1350)]을 구성 부분(1320 내지 1326)[예를 들어, 위치 부분(1322)]들로 파싱한다. 각 부분(1320 내지 1326)은 cmdlet(1330 내지 1336) 중 하나에 관련된다. 파서(220) 및 엔진(224)은 파싱, 파라미터 검증, 데이터 생성, 파라미터 처리, 파라미터 인코딩 및 파라미터 문서화 등의 여러 처리를 수행한다. 파서(220) 및 엔진(224)은 커맨드 라인의 입력 파라미터에 대해 공통의 기능을 수행하기 때문에, 관리 도구 프레임워크(200)는 일관된 에러 메지시를 사용자에게 발행할 수 있다.

인지할 수 있는 바와 같이, 본 발명의 관리 도구 프레임워크에 따라 작성되는 실행가능 cmdlet(1330 내지 1336)는 이전 관리 환경에서의 커맨드보다 더 적은 코드를 필요로 한다. 각각의 실행가능 cmdlet(1330 내지 1336)는 각각의 구성 부분(1320 내지 1326)을 사용하여 식별된다. 또한, 각 실행가능 cmdlet(1330 내지 1336)는 입력 객체[화살표(1341, 1343, 및 1345)로 표시됨]로서 다음 파이프라인된 cmdlet에 입력되는 객체[화살표(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가 제거된다. 이는 메모리 할당해제 등을 담당하는 관련 cmdlet 객체에 대한 디스트럭처의 호출을 포함한다. 그러면, 커맨드 스트링의 처리가 완료된다.

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에 대한 정보가 획득된다. 이는 리플렉션 또는 다른 수단을 통해 발생할 수 있다. 이 정보는 예측된 입력 파라미터에 관한 것이다. 상술한 바와 같이, 공개로 선언된 파라미터[예를 들어, publicstring Name(730)]는 입력 스트림 내에 제공되거나 커맨드 라인 상의 커맨드 스트링에 규정될 수 있는 예측된 입력 파라미터에 대응한다. 도 18에 설명된 확장된 유형 관리자를 통한 관리 도구 프레임워크는 (요구 기반으로) 호출자에 정보를 리턴하는 공통 인터페이스를 제공한다. 처리는 블록(1510)으로 진행한다.

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

블록(1512)에서, 메타데이터는 인텔리센스를 제공하는 데 사용된다. 처리의 시점에서는, 전체 커맨드 스트링이 아직 입력되지 않았다. 그러나, 관리 도구 프레임워크는 이용가능한 cmdlet를 인지한다. cmdlet가 결정되고 나면, 관리 도구 프레임워크는 그 cmdlet 객체 상에 리플렉션함으로써 허용되는 입력 파라미터를 인식한다. 따라서, 관리 도구 프레임워크는 cmdlet 이름의 비모호한 부분(disambiguating portion)이 제공되고 나면, 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는 인입 데이터를 단편화(shredding)하여 예측 파라미터를 획득하는 템플릿으로서 동작한다. 또한, 예측된 파라미터에 대한 값을 제공하는 인입 객체의 유형을 인식하지 못하고서, 예측된 파라미터가 획득된다. 이는 종래의 관리 환경과 매우 상이하다. 종래의 관리 환경은 강하게 결합되며, 컴파일 시에 객체의 유형이 알려질 것을 요구한다. 또한, 종래 환경에서, 예측 파라미터는 값에 의해 또는 참조에 의해 펑션에 전달되었다. 따라서, 본 발명의 파싱(예를 들어, 단편화) 메커니즘은 프로그래머가 이들 파라미터에 대한 값이 어떻게 획득되는지를 구체적으로 알 필요없이 파라미터 유형을 규정할 수 있게 한다.

예를 들어, cmdlet Foo에 대한 다음 선언이 주어지면:

class Foo: Cmdlet

{

string Name;

Bool Recurse;

}

커맨드 라인 구문은 다음 중 임의의 것일 수 있다:

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

$Foo -Name<string> -Recurse True

$Foo -Name(string)

규칙 세트는 원하는 구문을 산출하기 위해 시스템 관리자에 의해 변형될 수 있다. 또한, 파서는 다수의 규칙 세트를 지원하여, 2개 이상의 구문이 사용자에 의해 사용될 수 있게 한다. 본질적으로, cmdlet 구조(예를 들어, StringName 및 Bool Recurse)에 관련된 문법이 파서를 구동한다.

통상적으로, 파싱 지시어는 커맨드 스트링으로서 입력된 파라미터가 cmdlet 객체에서 식별되는 예측 파라미터에 매핑하는 방식을 나타낸다. 입력 파라미터 유형이 검사되어 올바른지의 여부가 판정된다. 입력 파라미터 유형이 올바르지 않은 경우, 그 입력 파라미터는 올바르게 되도록 강요될 수 있다. 입력 파라미터 유형이 올바르지도 않고 강요될 수도 없는 경우, 사용 에러가 인쇄된다. 사용 에러는 사용자가 예측되는 올바른 구문을 인지하게 할 수 있다. 사용 에러는 문서화 지시어로부터 구문을 나타내는 정보를 획득할 수 있다. 입력 파라미터 유형이 매핑되거나 검증되고 나면, cmdlet 객체 인스턴스에서 대응하는 멤버가 채워질 수 있다. 멤버들이 채워짐에 따라, 확장된 유형 관리자는 입력 파라미터 유형의 처리를 제공한다. 간단하게, 이 처리는 속성 경로 메커니즘, 키 메커니즘, 비교 메커니즘, 전환 메커니즘, 글로버 메커니즘, 관계 메커니즘, 및 속성 설정 메커니즘을 포함할 수 있다. 이들 메커니즘 각각은 예들을 포함하는 "확장된 유형 관리자 처리"라는 제목의 섹션에서 나중에 설명된다.

cmdlet를 실행하는 예시적인 프로세스

cmdlet를 실행하는 예시적인 프로세스는 도 17에 도시되어 있으며 이하 설명된다. 예시적인 관리 도구 환경에서, 코어 엔진은 cmdlet를 실행한다. 상술한 바와 같이, 제2 메소드(1440) 내의 코드(1442)는 각 입력 객체에 대하여 실행된다. 처리는 블록(1710)에서 개시하며, 여기서, cmdlet는 이미 채워져 있다. 처리는 블록(1702)으로 진행한다.

블록(1702)에서, 실행을 위해 코드(542)로부터의 문장이 검색된다. 처리는 판정 블록(1704)으로 진행한다.

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

블록(1706)에서, 문장이 처리된다. 그 후, 처리는 판정 블록(1708)으로 진행한다. 블록(1708)에서, 코드가 다른 문장을 포함하는지를 판정한다. 다른 문장이 있는 경우, 처리는 블록(1702)으로 루프백하여 다음 문장을 획득하고 상술한 바와 같이 진행한다. 그렇지 않으면, 처리는 판정 블록(1714)으로 진행한다.

판정 블록(1714)에서, 처리할 다른 입력 객체가 있는지를 판정한다. 다른 입력 객체가 있는 경우, 처리는 블록(1716)으로 진행하고, cmdlet는 다음 객체로부터의 데이터로 채워진다. 도 16에서 설명된 채우기(population) 프로세스는 다음 객체에서 수행된다. 처리는 그 후 블록(1702)으로 루프백하여 상술한 바와 같이 진행한다. 모든 객체가 처리되고 나면, cmdlet를 실행하는 프로세스가 완료되어 리턴한다.

판정 블록(1704)으로 다시 되돌아가면, 문장이 후크를 포함하는 경우, 처리는 블록(1712)으로 진행한다. 블록(1712)에서, 관리 도구 환경에 의해 제공되는 추가 특성이 처리된다. 처리는 판정 블록(1708)으로 진행하며 상술한 바와 같이 계속된다.

이하에서는, 블록(1712)에서 수행되는 추가 처리가 도 6에 나타낸 예시적인 데이터 구조(600)를 참조하여 설명된다. 상술한 바와 같이, 커맨드 베이스 클래스(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 내에 후크를 정의하는 임의의 cmdlet에 대하여 수행될 수 있다. 다르게는, 후크는 상술한 verbose 파라미터와 마찬가지로, 커맨드 입력에 규정될 수 있는 옵션 입력 파라미터일 수 있다.

보안 점검은 역할 기반 인증을 지원하도록 구현되며, 이는 통상적으로 사용자의 역할에 따라 어느 사용자가 자원에 액세스할지를 제어하는 시스템으로서 정의된다. 따라서, 각 역할은 상이한 자원들에 대하여 특정 액세스 권한을 할당받는다. 그 후, 사용자는 하나 이상의 역할에 할당된다. 통상적으로, 규칙 기반 인증은 3개의 항목, 즉 원리, 자원 및 동작에 대하여 집중한다. 원리(principle)는, 동작이 자원 상에서 수행될 것을 누가 요청했는지를 식별한다.

본 발명의 발명자는 요청되고 있는 cmdlet가 이전에 수행되었던 동작에 대응함을 인식하였다. 또한, 본 발명자들은 관리 도구 프레임워크가 실행되고 있는 프로세스의 소유자는 원리에 대응함을 인식하였다. 또한, 본 발명자들은 자원이 cmdlet 내에 규정됨을 알 수 있었다. 따라서, 관리 도구 프레임워크가 이들 항목에 대한 액세스를 갖기 때문에, 본 발명자들은 도구 개발자들이 보안 점검을 구현할 필요없이 관리 도구 프레임워크 내에서 보안 점검이 수행될 수 있음을 인식하였다.

보안 점검의 동작은 확인처리 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.kb"; 및 (3) "exe*.ver*.description.tolower.trunc(30)"이 있다. 이들 속성 경로를 설명하기 전에, "name", "ws", 및 "exe"는 표에 대한 속성을 규정한다는 점을 인식하여야 한다. 또한, 이들 각 속성은 본래 "get/process"에 의해 원래 생성된 후 여러 cmdlet를 통해 파이프라인된 인입 객체의 직접 속성임을 알아야 한다. 세개의 속성 경로 각각에 포함된 처리를 이하 설명한다.

제1 속성 경로(즉, "name.toupper")에서, name은 인입 객체의 직접 속성이고 그 자체가 또한 객체이다. 확장된 유형 관리자는 상술한 우선순위 룩업을 사용하는 시스템에 쿼리하여 toupper에 대한 유형을 판정한다. 확장된 유형 관리자는 toupper가 속성이 아님을 발견한다. 그러나, toupper는 스트링 유형에 의해 상속되어 스트링 내의 소문자를 대문자로 전환하는 메소드일 수 있다. 다르게는, 확장된 유형 관리자는 확장된 메타데이터에 쿼리하여, name 객체를 대문자로 전환할 수 있는 제3자 코드가 있는지를 판정할 수 있다. 컴포넌트 유형을 발견하는 경우, 처리는 컴포넌트 유형에 따라 수행된다.

제2 속성 경로(즉, "ws.kb")에서, "ws"는 인입 객체의 직접 속성이고 그 자체가 객체이다. 확장된 유형 관리자는 "ws"가 정수라고 결정한다. 그 후, 확장된 유형 관리자는 kb가 정수의 속성인지, kb가 정수의 메소드인지를 쿼리하고, 최종적으로, 임의의 코드가 정수를 취하여 이 정수를 kb 유형으로 전환하는 방식을 아는지를 쿼리한다. 제3자 코드는 이러한 전환을 수행하도록 등록되어 전환이 수행된다.

제3 속성 경로(즉, "exe*.ver*.description.tolower.trunc(30)")에는, 여러 컴포넌트가 있다. 제1 컴포넌트("exe*")는 인입 객체의 직접 속성이고 또한 객체이다. 또한, 확장된 유형 관리자는 제2 컴포넌트("ver*")를 처리하기 위해서 룩업 쿼리를 진행한다. "exe*" 객체는 "ver*" 속성 또는 메소드를 갖지 않기 때문에, 확장된 유형 관리자는 확장된 메타데이터를 쿼리하여 실행가능한 이름을 버전으로 전환하도록 등록된 임의의 코드가 있는지를 판정한다. 이 예에서는, 그러한 코드가 존재한다. 이 코드는 실행가능한 이름 스트링을 취하여 이를 사용하여 파일을 열고 그 후 버전 블록 객체에 액세스하여, 버전 블록 객체의 디스크립션 속성[제3 컴포넌트("description")]을 리턴할 수 있다. 확장된 유형 관리자는 그 후 제4 컴포넌트("tolower")와 제5 컴포넌트("trunc(40)")에 대하여 동일한 룩업 메커니즘을 수행한다. 따라서, 설명하는 바와 같이, 확장된 유형 관리자는 관리자가 임의의 특정 코드를 작성할 필요없이 커맨드 스트링에 대한 매우 정교한 처리를 수행할 수 있다. 표 1은 예시적인 스트링에 대하여 생성된 출력을 나타낸다.

Name.toupper ws.kb exe*.ver*.description.tolower.trunc(30)

ETCLIENT 29,964 클라이언트

CSRSS 6,944

SVCHOST win32에 대한 28,944 일반 호스트 프로세스

OUTLOOK 18,556 오피스 아웃룩

MSMSGS 13,248 메신저

표 1

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

다른 쿼리 메커니즘(1824)은 비교 메커니즘을 포함한다. 비교 메커니즘은 두개의 객체를 비교한다. 두개의 객체가 비교 펑션을 직접 지원하면, 직접 지원된 비교 펑션이 실행된다. 그러나, 어떠한 객체도 비교 펑션을 지원하지 않는다면, 확장된 유형 관리자는 유형 메타데이터 내에서 두 객체 간의 비교를 지원하도록 등록된 코드를 볼 수 있다. 비교 메커니즘을 인보크하는 일련의 예시적인 스트링은 표 2에서 대응 출력과 함께 나타낸다.

$ $a=$(get/date)

$ start/sleep 5

$ $b = $( get/date

비교/시간 $a $b

틱 :51196579

일 :0

시 :0

밀리초 :119

분 :0

초 :5

전체 일 :5.92552997685185E-05

전체 시간 :0.0142212719444444

전체 밀리초 :5119.6579

전체 분 :0.0853276316666667

전체 초 :5.1196579

표 2

비교/시간 cmdlet는 두개의 날짜시간 객체를 비교하기 위해 작성된다. 이 경우, DateTime 객체는 IComparable 인터페이스를 지원한다.

다른 쿼리 메커니즘(1824)은 전환 메커니즘을 포함한다. 확장된 유형 관리자는 코드가 등록되어 특정 전환을 수행하는 자신의 능력을 기술할 수 있게 한다. 그 후, 유형 A의 객체가 이력이고 cmdlet가 유형 B의 객체를 규정하는 경우, 확장된 유형 관리자는 등록된 전환 중 하나를 사용하여 전환을 수행할 수 있다. 확장된 유형 관리자는 유형 A를 유형 B로 강요하기 위해서 일련의 전환을 수행할 수 있다. 상술한 속성 경로("ws.kb")는 전환 메커니즘을 나타낸다.

다른 쿼리 메커니즘(1824)은 글로버 메커니즘을 포함한다. 글로버는 스트링 내의 와일드 카드 문자를 나타낸다. 글로버 메커니즘은 와일드 카드 문자를 갖는 스트링을 입력하여 일련의 객체를 생성한다. 확장된 유형 관리자는 와일드카드 처리를 규정하는 코드가 등록될 수 있게 한다. 상술한 속성 경로("exe*.ver*. description.tolower.trunc(30)")는 글로버 메커니즘을 나타낸다. 등록된 프로세스는 파일명, 파일 객체, 인입 속성 등에 대한 글로빙을 제공할 수 있다.

다른 쿼리 메커니즘(1824)은 속성 세트 메커니즘을 포함한다. 속성 세트 메커니즘은 이름이 일련의 속성에 대하여 정의될 수 있게 한다. 그 후, 관리자는 커맨드 스트링 내에 이름을 규정하여 일련의 속성을 획득할 수 있다. 속성 세트는 다양한 방식으로 정의될 수 있다. 하나의 방식에서, "?"와 같이 미리 정의된 파라미터가 cmdlet에 대한 입력 파라미터로서 입력될 수 있다. 운영 환경은 미리 정의된 파라미터를 인식할 때 인입 객체의 모든 속성을 열거한다. 리스트는 관리자가 원하는 속성을 용이하게 체크(예를 들어, "클릭 온")하고 속성 세트를 명명할 수 있게 하는 GUI일 수 있다. 그 후, 속성 세트 정보는 확장된 메타데이터 내에 저장된다. 속성 세트 메커니즘을 인보크하는 예시적인 스트링은 표 3에서의 대응하는 출력과 함께 이하 나타난다.

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

이 예시적인 스트링에서, "config"로 명명된 속성 세트는 이름 속성, 프로세시 id 속성(Pid) 및 우선순위 속성을 포함하도록 정의되었다. 표의 출력이 아래 나타낸다.

이름 Pid 속성

ETClient 3528 정상

csrss 528 정상

svchost 848 정상

OUTLOOK 2,772 정상

msmsgs 2,584 정상

표 3

다른 쿼리 메커니즘(1824)은 관계 메커니즘을 포함한다. 하나의 관계(즉, 상속)를 지원하는 종래 유형 시스템과 달리, 관계 메커니즘은 유형들 간의 2 이상의 관계 표현을 지원한다. 또한, 이들 관계는 등록된다. 관계는 객체가 소비하는 항목을 발견하거나 객체를 소비하는 항목을 발견하는 것을 포함한다. 확장된 유형 관리자는 여러 관계를 나타내는 온톨로지에 액세스할 수 있다. 확장된 유형 메타데이터와 코드를 사용하여, OWL, DAWL 등의 임의의 온톨로지 서비스에 액세스하는 사양이 설명될 수 있다. 다음은 관계 메커니즘 .OWL:"string"을 사용하는 예시적인 스트링의 일부이다.

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

커맨드 라인 데이터를 디스플레이하는 예시적인 프로세스

본 메커니즘은 데이터 구동 커맨드 라인 출력을 제공한다. 데이터의 포맷화와 출력은 cmdlet의 파이프라인 내의 하나 이상의 cmdlet에 의해 제공된다. 통상적으로, 이들 cmdlet는 도 2를 참조하여 설명한 비관리 cmdlet 내에 포함된다. cmdlet는 포맷 cmdlet, 마크업 cmdlet, 전환 cmdlet, 변환 cmdlet, 및 아웃 cmdlet를 포함할 수 있다.

도 19는 파이프라인 내의 이들 cmdlet의 예시적인 시퀀스 1901 내지 1907을 나타낸다. 제1 시퀀스(1901)는 파이프라인 내의 최종 cmdlet로서 아웃 cmdlet(1910)를 나타내다. 다른 cmdlet에 대하여 상술한 것과 동일한 방식으로, 아웃 cmdlet(1910)는 파이프라인 내의 다른 cmdlet에 의해 생성되어 처리된 파이프라인 객체의 스트림을 수용한다. 그러나, 대부분의 cmdlet와는 달리, 아웃 cmdlet(1910)는 다른 cmdlet에 대한 파이프라인 객체를 내놓지 않는다. 그 대신, 아웃 cmdlet(1910)는 파이프라인에 의해 생성된 결과를 렌더링/디스플레이할 책임이 있다. 각각의 아웃 cmdlet(1910)는 장치, 프로그램 등과 같은 출력 목적지에 관련되어 있다. 예를 들어, 콘솔 장치에 있어서, 아웃 cmdlet(1910)는 아웃/콘솔로서 규정될 수 있으며; 인터넷 브라우저에 있어서, 아웃 cmdlet(1910)는 아웃/브라우저로서 규정될 수 있으며; 윈도우에 있어서, 아웃 cmdlet(1910)는 아웃/윈도우로서 규정될 수 있다. 각각의 특정 아웃 cmdlet는 관련 목적지의 성능에 친숙하다. 전환 cmdlet가 파이프라인 내의 아웃 cmdlet에 선행하지 않는다면, 로컬 정보(예를 들어, 날짜 및 통화 포맷)는 아웃 cmdlet(1910)에 의해 처리된다. 이 상황에서, 전환 cmdlet는 로컬 정보를 처리했다.

각 호스트는 아웃/콘솔 등의 특정 아웃 cmdlet를 지원한다. 또한, 호스트는 임의의 목적지 특정 호스트 cmdlet(예를 들어, 출력을 스프레드시트 애플리케이션에 의해 제공되는 차트로 보내는 아웃/차트)를 지원한다. 또한, 호스트는 결과의 디폴트 처리를 제공한다. 이 시퀀스 내의 아웃 cmdlet는 다른 출력 처리 cmdlet(예를 들어, 포맷/마크업/전환/변환)를 호출하여 자신의 거동을 구현하기로 결정할 수 있다. 따라서, 아웃 cmdlet는 시퀀스(1901)를 임의의 다른 시퀀스로 암시적으로 수정하거나 자신의 추가 포맷/출력 cmdlet를 추가할 수 있다.

제2 시퀀스(1902)는 아웃 cmdlet(1910) 이전에 포맷 cmdlet(1920)를 나타낸다. 이 시퀀스에서, 포맷 cmdlet(1920)는 파이프라인 내의 다른 cmdlet에 의해 생성되고 처리된 파이프라인 객체의 스트림을 수용한다. 요컨대, 포맷 cmdlet(1920)는 디스플레이 속성을 선택하는 방법, 및 형상, 열의 폭, 헤더, 풋터 등과 같은 페이지 레이아웃을 규정하는 방법을 제공한다. 형상은 표, 와이드 리스트, 열 리스트 등을 포함할 수 있다. 또한, 포맷 cmdlet(1920)는 전체 또는 합의 계산을 포함할 수 있다. 포맷 cmdlet(1920)에 의해 수행되는 예시적인 처리는 도 20을 참조하여 아래 설명한다. 간략하게, 포맷 cmdlet는 파이프라인 객체를 출력하는 것에 더하여, 포맷 객체를 출력한다. 포맷 객체는 확장된 유형 관리자 또는 다른 메커니즘을 통해 아웃 cmdlet[예를 들어, 시퀀스(1902) 내의 아웃 cmdlet(1920)]에 의한 인식된 다운스트림일 수 있다. 아웃 cmdlet(1920)는 출력된 포맷 객체의 사용을 선택하거나 이들을 무시하는 선택을 할 수 있다. 아웃 cmdlet는 디스플레이 정보에 규정된 페이지 레이아웃 데이터에 기초하여 페이지 레이아웃을 결정한다. 특정 상황에서, 페이지 레이아웃에 대한 변형이 아웃 cmdlet에 의해 규정될 수 있다. 예시적인 프로세스에서, 아웃 cmdlet는 소정 개수의 객체의 각 속성에 대한 최대 길이(예를 들어, 50)를 검색하여 열의 폭을 그 최대 길이로 설정하여, 미지정된 열의 폭을 결정할 수 있다. 포맷 객체는 포맷화 정보, 헤더/풋터 정보 등을 포함한다.

제3 시퀀스(1903)는 아웃 cmdlet(1910) 전에 포맷 cmdlet(1920)를 나타낸다. 그러나, 제3 시퀀스(1903)에서, 마크업 cmdlet(1930)는 포맷 cmdlet(1920)와 아웃 cmdlet(1910) 사이에 파이프라인된다. 마크업 cmdlet(1930)는 속성 주석(예를 들어, 폰트, 색)을 선택된 파라미터에 추가하는 메커니즘을 제공한다. 따라서, 마크업 cmdlet(1930)는 출력 cmdlet(1910) 전에 나타난다. 속성 주석은 "쉐도우 속성 백(shadow property bag)"을 사용하여, 또는 속성 백 내의 커스텀 네임스페이스에 속성 주석을 추가하여 구현될 수 있다. 마크업 cmdlet(1930)는 마크업 주석이 포맷 cmdlet(1920)의 처리 동안 유지될 수 있는 한, 포맷 cmdlet(1920) 이전에 나타날 수 있다.

제4 시퀀스(1904)는 아웃 cmdlet(1910) 이전에 포맷 cmdlet(1920)을 다시 나타낸다. 그러나, 제4 시퀀스(1094)에서, 전환 cmdlet(1940)는 포맷 cmdlet(1920)와 아웃 cmdlet(1910) 사이에 파이프라인된다. 전환 cmdlet(1940)는 또한 포맷 cmdlet(1920)에 의해 출력되는 포맷 객체를 처리하도록 구성된다. 전환 cmdlet(1940)는 포맷 객체에 따라 파이프라인 객체를 특정 인코딩으로 전환한다. 전환 cmdlet(1940)는 특정 인코딩에 관련된다. 예를 들어, 파이프라인된 객체를 액티브 디렉토리 객체(active directory object; ADO)로 전환하는 전환 cmdlet(1940)는 커맨드 라인 상에 "전환/ADO"로서 선언될 수 있다. 마찬가지로, 파이프라인된 객체를 콤마 분리값(comma separated value, csv)으로 전환하는 전환 cmdlet(1940)는 커맨드 라인 상에서 "전환/csv"로서 선언될 수 있다. 전환 cmdlet(1940) 중 몇몇(예를 들어, 전환/XML 및 전환/html)은 블로킹 커맨드일 수 있으며, 이는 모든 파이프라인된 객체가 전환 실행 전에 수신됨을 의미한다. 통상적으로, 아웃 cmdlet(1920)는 포맷 객체에 의해 제공되는 포맷화 정보를 사용할 지를 결정할 수 있다. 그러나, 전환 cmdlet(1920)가 아웃 cmdlet(1920) 전에 나타나는 경우, 실제 데이터 전환은 아웃 cmdlet가 객체를 수신하기 전에 발생한다. 따라서, 이러한 경우, 아웃 cmdlet는 전환을 무시할 수 없다.

제5 시퀀스(1905)는 포맷 cmdlet(1920), 마크업 cmdlet(1930), 전환 cmdlet(1940), 및 출력 cmdlet(1910) 순서대로 나타낸다. 따라서, 이는 마크업 cmdlet(1930)가 전환 cmdlet(1940) 전에 발생할 수 있음을 나타낸다.

제6 시퀀스(1906)는 포맷 cmdlet(1920), 특정 전환 cmdlet[예를 들어, 전환/xml cmdlet(1940)], 특정 변환 cmdlet[예를 들어, 변환/xslt cmdlet(1950)] 및 출력 cmdlet(1910)를 나타낸다. 전환/xml cmdlet(1940)는 파이프라인된 객체를 확장된 유형 마크업 언어(XML) 문서로 전환한다. 변환/xslt cmdlet(1950)는 확장된 유형 스타일 언어(XSL) 스타일 시트를 사용하여 XML 문서를 다른 XML 문서로 변환한다. 변환 프로세스는 통상적으로 확장된 유형 스타일 언어 변환(XSLT)을 지칭하며, 여기서 XSL 프로세서는 XML 문서를 판독하고 XSL 스타일 시트 내의 커맨드에 따라 새로운 XML 문서를 생성한다.

제7 시퀀스(1907)는 포맷 cmdlet(1920), 마크업 cmdlet(1930), 특정 전환 cmdlet(예를 들어, 전환/xml cmdlet(1940)], 특정 변환 cmdlet[예를 들어, 변환/xslt cmdlet(1950)] 및 출력 cmdlet(1910)를 나타낸다. 따라서, 제7 시퀀스(1907)는 전환 cmdlet와 변환 cmdlet로부터 업스트림의 마크업 cmdlet(1930)를 갖는 것으로 나타낸다.

도 20은 포맷 cmdlet에 의해 수행되는 예시적인 처리(2000)를 나타낸다. 포맷 cmdlet가 상술한 바와 같은 방식으로 파서와 파이프라인 프로세서에 의해 파싱되고 인보크된 후에, 포맷 프로세스는 블록(2001)에서 개시한다. 처리는 블록(2002)으로 진행한다.

블록(2002)에서, 파이프라인 객체는 포맷 cmdlet에 입력으로 수신된다. 처리는 블록(2004)으로 진행한다.

블록(2004)에서, 쿼리는 파이프라인된 객체에 대한 유형을 식별하도록 개시된다. 이러한 쿼리는 도 18을 참조하여 상술한 확장된 유형 관리자에 의해 수행된다. 확장된 유형 관리자가 객체에 대한 유형을 식별하고 나면, 처리는 블록(2006)으로 진행한다.

블록(2006)에서, 식별된 유형은 디스플레이 정보에서 검색된다. 디스플레이 정보에 대한 예시적인 포맷이 도 21에 도시되어 있으며, 이하 설명된다. 처리는 판정 블록(2008)으로 진행한다.

판정 블록(2008)에서, 식별된 유형이 디스플레이 정보 내에 규정되는지를 판정한다. 식별된 유형에 대한 디스플레이 정보 내에 입력이 없는 경우, 처리가 완료된다. 그렇지 않으면, 처리는 블록(2010)으로 진행한다.

블록(2010)에서, 식별된 유형에 관련된 포맷화 정보는 디스플레이 정보로부터 획득된다. 처리는 블록(2012)으로 진행한다.

블록(2012)에서, 정보가 파이프라인 상에 출력된다. 정보가 출력되고 나면, 처리가 완료된다.

출력될 수 있는 예시적인 정보는 이하 보다 상세히 설명한다. 이 정보는 포맷화 정보, 헤더/풋터 정보, 및 그룹 종료/개시 신호 객체를 포함할 수 있다. 포맷화 정보는 형상, 라벨, 넘버링/불릿(bullet), 열의 폭, 문자 인코딩 유형, 내용 폰트 속성, 페이지 길이, 그룹에 대한 속성명(group-by-property name) 등을 포함할 수 있다. 이들 각각은 이에 관련된 추가 사양을 가질 수 있다. 예를 들어, 형상은 표, 리스트 등인지를 규정할 수 있다. 라벨은 열의 헤더, 리스트 라벨 등을 사용할지를 규정할 수 있다. 문자 인코딩은 ASCII, UTF-8, 유니코드 등을 규정할 수 있다. 내용 폰트 속성은 디스플레이인 속성 값에 인가되는 폰트를 규정할 수 있다. 디폴트 폰트 속성(예를 들어, Courier New, 10 포인트)은 내용 폰트 속성이 규정되지 않는 경우 사용될 수 있다.

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

그룹 종료/개시 신호 객체는 포맷 cmdlet가 그룹별 속성이 변경됨을 검출한 경우에 출력된다. 이것이 발생하면, 포맷 cmdlet는 파이프라인 객체의 스트림을 이전에 소팅된 바대로 처리하며 이들을 다시 소팅하지는 않는다. 그룹 종료/개시 신호 객체는 파이프라인 객체에 삽입될 수 있다. 다수의 그룹별 속성은 네스트된 소팅에 대하여 규정될 수 있다. 포맷 cmdlet는 최종 합 및 총합을 포함하는 포맷 종료 객체를 출력할 수 있다.

도 21을 간단히 참조하면, 예시적인 디스플레이 정보(2100)는 구조화된 포맷에 있고, 정의되어 있는 각 객체에 관련된 정보(예를 들어, 포맷화 정보, 헤더/풋터 정보, 그룹별 속성 또는 메소드)를 포함한다. 예를 들어, 디스플레이 정보(2100)는 XML 기반일 수 있다. 상술한 속성 각각은 디스플레이 정보 내에 규정될 수 있다. 디스플레이 정보(2100) 내의 정보는 입력된 객체 유형의 소유자에 의해 채워질 수 있다. 운영 환경은 소유자가 입력의 생성, 삭제 및 변형을 통해 디스플레이 정보를 갱신할 수 있게 하는 특정 API 및 cmdlet를 제공한다.

도 22는 특정 포맷 cmdlet(예를 들어, 포맷/표, 포맷/리스트 및 포맷/와이드), 마크업 cmdlet(예를 들어, 추가/마크업), 전환 cmdlet(예를 들어, 전환/텍스트, 전환/sv, 전환/csv, 전환/ADO, 전환/XML, 전환/html), 변환 cmdlet(예를 들어, 변환/XSLT) 및 아웃 cmdlet(예를 들어, 아웃/콘솔, 아웃/파일)에 대한 예시적인 구문(2201 내지 2213)을 열거하는 표이다. 도 23은 출력 처리 cmdlet(예를 들어, 포맷 cmdlet, 전환 cmdlet 및 마크업 cmdlet)의 여러 파이프라인 시퀀스를 사용하여 아웃/콘솔 cmdlet에 의해 렌더링되는 결과를 나타낸다.

상술한 바와 같이, 커맨드 라인 명령에 확장된 기능을 제공하는 메커니즘이 관리 도구 환경에서 사용될 수 있다. 그러나, 당업자는 이러한 메커니즘이 커맨드 라인 명령을 입력하는 다양한 환경에서 사용될 수 있음을 알 것이다. 예를 들어, "whatif" 파라미터에 대한 커맨드라인을 파싱하고 시뮬레이션 모드 처리를 수행하도록 필요한 명령을 삽입함으로써 "whatif" 기능이 단독의 커맨드에 포함될 수 있다. 커맨드 라인 명령에 확장된 기능을 제공하는 이러한 메커니즘은 기능을 확장하는 통상적인 메커니즘과는 상당히 상이하다. 예를 들어, 통상적인 매커니즘에서, 확장된 기능을 원하는 각각의 커맨드는 코드를 커맨드에 포함시켜야 하였다. 그 후에 커맨드 자체는 커맨드 스트링을 파싱하여 스위치(예를 들면, verbose, whatif)가 제공되었는지 여부를 판정하여 이에 따라 확장 기능을 수행하여야 한다. 이와 달리, 본 발명의 메커니즘은 cmdlet가 후크를 확장된 기능에 포함시키는 경우에는 특정 cmdlet에 대한 확장된 기능을 실행하기 위하여 사용자가 커맨드 스트링내에 변수를 특정하는 것을 가능하게 한다. 따라서, 본 발명의 메커니즘은 기록되어야 할 코드 시스템 관리량을 최소화한다. 이에 부가하여, 본 발명의 메커니즘을 이용하여 확장된 기능이 일정한 방식으로 실시된다.

특정 구현예 및 실시예의 세부사항이 상기 설명되었지만, 이러한 세부사항은 본 발명의 범위를 한정하려기 보다 법적 개시 의무를 충족시키려는 것이다. 따라서, 청구항으로 한정되는 본 발명은 상술한 특정한 특징으로 국한되지 않는다. 대신, 본 발명은, 균등론에 따라 적절하게 해석하여, 첨부된 청구항의 적절한 범위 내에 해당하는 임의의 형태 또는 변형을 주장한다.

Claims (20)

1. 커맨드 라인 운영 환경에서의 컴퓨터 실행가능 방법으로서,

   제1 실행 모드 또는 다른 실행 모드(alternate execution mode)에서 커맨드 라인 상의 각각의 커맨드(command)를 실행하는 단계 - 상기 커맨드를 상기 다른 실행 모드에서 실행하는 것은 상기 커맨드 라인 상의 커맨드가 명령어(instruction)를 포함하는 경우에 발생하고, 상기 명령어는 상기 다른 실행 모드에서 실행하라는, 상기 커맨드 라인 운영 환경에 의해 제공되는 메소드에 대한 호출을 포함하고, 상기 커맨드 라인 운영 환경에 의해 제공되는 상기 다른 실행 모드에서, 상기 커맨드 라인 운영 환경은 상기 커맨드를 실행하기 위한 확장된 기능을 제공하되, 상기 커맨드 라인 상에서 실행되는 상기 커맨드는 상기 커맨드를 실행하기 위한 기능을 확장하기 위한 코드를 포함하지 않음 -

   를 포함하고,

   상기 다른 실행 모드에서 실행하라는 명령어는 또한 상기 다른 실행 모드를 지시하는 스위치를 포함하고, 상기 스위치는 커맨드들이 유도되는 cmdlet 베이스 클래스 내의 대응하는 후크 문장(hook statement)을 활성화하며, 상기 후크 문장은 상기 다른 실행 모드에서 실행하라는, 상기 커맨드 라인 운영 환경에 의해 제공되는 상기 메소드를 호출하며, 상기 다른 실행 모드는 상기 커맨드의 시뮬레이트된 실행 결과들을 시각적으로 디스플레이하는 컴퓨터 실행가능 방법.
2. 제1항에 있어서,

   상기 스위치는 "whatif"를 포함하는 컴퓨터 실행가능 방법.
3. 커맨드라인 운영 환경을 제공하는 시스템으로서,

   프로세서; 및

   메모리 - 상기 메모리는 상기 프로세서에 의한 실행을 위하여 상기 메모리에 로딩되는 복수의 컴퓨터 실행가능 명령어들을 위하여 할당되고,

   상기 컴퓨터 실행가능 명령어들은,

   제1 실행 모드 또는 다른 실행 모드(alternate execution mode)에서

   커맨드 라인 상의 각각의 커맨드를 실행하는 단계 - 상기 커맨드를 상

   기 다른 실행 모드에서 실행하는 것은 상기 커맨드 라인 상의 커맨드

   가 명령어를 포함하는 경우에 발생하고, 상기 명령어는 상기 다른 실

   행 모드에서 실행하라는, 상기 커맨드 라인 운영 환경에 의해 제공되

   는 메소드에 대한 호출을 포함하고, 상기 커맨드 라인 운영 환경에 의

   해 제공되는 상기 다른 실행 모드에서, 상기 커맨드 라인 운영 환경은

   상기 커맨드를 실행하기 위한 확장된 기능을 제공하되, 상기 커맨드

   라인 상에서 실행되는 상기 커맨드는 상기 커맨드를 실행하기 위한 기

   능을 확장하기 위한 코드를 포함하지 않음 -

   를 포함하는 메소드를 수행함 -

   를 포함하고,

   상기 다른 실행 모드에서 실행하라는 명령어는 또한 상기 다른 실행 모드를 지시하는 스위치를 포함하고, 상기 스위치는 커맨드들이 유도되는 cmdlet 베이스 클래스 내의 대응하는 후크 문장을 활성화하며, 상기 후크 문장은 상기 다른 실행 모드에서 실행하라는, 상기 커맨드 라인 운영 환경에 의해 제공되는 상기 메소드를 호출하는 시스템.
4. 제3항에 있어서,

   상기 스위치는 "whatif"를 포함하는 시스템.
5. 제3항에 있어서,

   상기 다른 실행 모드는 상기 커맨드의 시뮬레이트된 실행 결과들을 시각적으로 디스플레이하는 시스템.
6. 실행되는 경우, 디바이스로 하여금 액션들을 수행하도록 명령하는 프로세서-실행가능 명령어들을 포함하는 하나 이상의 컴퓨터 판독 가능한 저장 매체로서, 상기 액션들은,

   제1 실행 모드 또는 다른 실행 모드에서(alternate execution mode) 커맨드 라인 상의 각각의 커맨드를 실행하는 단계 - 상기 커맨드를 상기 다른 실행 모드에서 실행하는 것은 상기 커맨드 라인 상의 커맨드가 명령어를 포함하는 경우에 발생하고, 상기 명령어는 상기 다른 실행 모드에서 실행하라는, 상기 커맨드 라인 운영 환경에 의해 제공되는 메소드에 대한 호출을 포함하고, 상기 커맨드 라인 운영 환경에 의해 제공되는 상기 다른 실행 모드에서, 상기 커맨드 라인 운영 환경은 상기 커맨드를 실행하기 위한 확장된 기능을 제공하되, 상기 커맨드 라인 상에서 실행되는 상기 커맨드는 상기 커맨드를 실행하기 위한 기능을 확장하기 위한 코드를 포함하지 않음 -

   를 포함하고,

   상기 다른 실행 모드에서 실행하라는 명령어는 또한 상기 다른 실행 모드를 지시하는 스위치를 포함하고, 상기 스위치는 커맨드들이 유도되는 cmdlet 베이스 클래스 내의 대응하는 후크 문장(hook statement)을 활성화하며, 상기 후크 문장은 상기 다른 실행 모드에서 실행하라는, 상기 커맨드 라인 운영 환경에 의해 제공되는 상기 메소드를 호출하는 하나 이상의 컴퓨터 판독 가능한 저장 매체.
7. 제6항에 있어서,

   상기 스위치는 "whatif"를 포함하는 하나 이상의 컴퓨터 판독 가능한 저장 매체.
8. 제6항에 있어서,

   상기 다른 실행 모드는 상기 커맨드의 시뮬레이트된 실행 결과들을 시각적으로 디스플레이하는 하나 이상의 컴퓨터 판독 가능한 저장 매체.
9. 삭제
10. 삭제
11. 삭제
12. 삭제
13. 삭제
14. 삭제
15. 삭제
16. 삭제
17. 삭제
18. 삭제
19. 삭제
20. 삭제

Images