KR20060050559A

KR20060050559A - 원활한 객체 비교 시스템 및 방법

Info

Publication number: KR20060050559A
Application number: KR1020050077135A
Authority: KR
Inventors: 브할찬드라 에스. 팬디트; 브래드포드 알. 다니엘스; 제임스 더블유. 3세 트러허; 제프리 피. 스노버; 조나단 에스. 뉴맨
Original assignee: 마이크로소프트 코포레이션
Priority date: 2004-08-27
Filing date: 2005-08-23
Publication date: 2006-05-19
Also published as: US7503038B2; CN1740970A; JP5085022B2; CN100592256C; KR101213843B1; US20060047652A1; EP1630667A2; EP1630667A3; JP2006065861A

Abstract

본 발명의 비교 기술은 동일한 유형, 유사한 유형 또는 상이한 유형을 갖는 객체들에 대해 동작한다. 다수의 비교 객체들이 하나 이상의 참조 객체에 대해 비교될 수 있다. 비교 객체는 객체 기반 환경에서 동작하는 cmdlet들의 파이프라인에서의 이전의 cmdlet로부터 획득될 수 있다. 참조 객체 및 비교 객체는 순서 기반 방식으로 또는 키 기반 방식으로 비교될 수 있다. 게다가, 비교 동안에 참조 객체 및 비교 객체의 어느 속성들을 비교할 것인지를 식별해주는 특정의 속성들이 지정될 수 있다. 비교는 차이점 및/또는 유사점을 식별해주는 출력을 생성할 수 있다. 출력은 추가의 처리를 위해 다른 cmdlet로 파이프라이닝될 수 있다.

참조 객체, 비교 객체, cmdlet, 객체 기반 환경,

Description

원활한 객체 비교 시스템 및 방법{SYSTEM AND METHOD FOR SEAMLESSLY COMPARING OBJECTS}

도 1은 본 발명의 비교 기술이 구현될 수 있는 전형적인 컴퓨팅 장치를 나타낸 도면.

도 2는 본 발명의 비교 기술을 포함하는 객체 기반 관리 도구 프레임워크의 개요를 나타낸 블록도.

도 3은 도 2에 도시된 객체 기반 관리 도구 프레임워크의 플랫폼 관련 컴포넌트 내의 컴포넌트들을 나타낸 블록도.

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

도 5는 도 2에 도시된 객체 기반 관리 도구 프레임워크 내에서 사용하기 적합한 cmdlet을 지정하는 한 전형적인 데이터 구조를 나타낸 도면.

도 6은 도 2에 도시된 객체 기반 관리 도구 프레임워크 내에서 사용하기 적합한 cmdlet을 지정하는 한 전형적인 데이터 구조를 나타낸 도면.

도 7은 도 2에 도시된 객체 기반 관리 도구 프레임워크 내에서 수행되는 호스트 프로세싱에 대한 전형적인 프로세스를 나타낸 논리 흐름도.

도 8은 도 2에 도시된 객체 기반 관리 도구 프레임워크에서의 커맨드 스트링 의 프로세싱을 나타낸 기능 흐름도.

도 9는 도 8에 도시된 커맨드 스트링을 처리하는 프로세스를 나타낸 논리 흐름도.

도 10은 도 9에 도시된 커맨드 스트링의 프로세싱 내에서 사용하기 적합한 cmdlet의 인스턴스를 생성하는 전형적인 프로세스를 나타낸 논리 흐름도.

도 11은 도 9에 도시된 커맨드의 프로세싱 내에서 사용하기 적합한 cmdlet의 속성들을 파퓰레이션하는 전형적인 프로세스를 나타낸 논리 흐름도.

도 12는 도 9에 도시된 커맨드의 프로세싱 내에서 사용하기 적합한 cmdlet를 실행하는 전형적인 프로세스를 나타낸 논리 흐름도.

도 13은 도 2에 도시된 객체 기반 관리 도구 프레임워크 내에서 사용하기 적합한 전형적인 확장 유형 관리자의 기능 블록도.

도 14는 도 2에 도시된 객체 기반 관리 도구 프레임워크 내에 구현되는 비교 cmdlet에 대한 전형적인 신택스(syntax)를 나타낸 도면.

도 15는 비교 cmdlet의 호출의 예들을 발생된 결과와 함께 나타낸 도면.

도 16은 키 기반 비교 프로세스를 수행하는 전형적인 프로세스를 나타낸 논리 흐름도.

도 17은 순서 기반 비교 프로세스를 수행하는 전형적인 프로세스를 나타낸 논리 흐름도.

도 18은 도 17에 도시된 순서 기반 비교 프로세스 내에서 사용하기 적합한 순서 기반 객체 비교 프로세스를 나타낸 논리 흐름도.

도 19는 도 17에 도시된 순서 기반 비교 프로세스 내에서 사용하기 적합한 순서 기반 텍스트 비교 프로세스를 나타낸 논리 흐름도.

도 20은 람다 표현식을 구현하기 위한 비교 cmdlet에 대한 다른 전형적인 신택스를 나타낸 도면.

도 21은 도 16에서 사용하기 적합한 각각의 비교 객체와의 키 기반 비교를 수행하는 전형적인 프로세스를 나타낸 흐름도.

도 22는 도 21에서 사용하기 적합한 참조 객체와 비교 객체 간의 속성값을 비교하는 전형적인 프로세스를 나타낸 흐름도.

도 23은 도 21에서 사용하기 적합한 결과를 생성하는 전형적인 프로세스를 나타낸 흐름도.

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

200: 관리 도구 프레임워크

202: 호스트 컴포넌트

204: 플랫폼 관련 컴포넌트

206: 호스트 독립적인 컴포넌트

208: 핸들러 컴포넌트

220: 파서

222: 스크립트 엔진

224: 코어 엔진

본 발명은 컴퓨터 구현 비교 기술에 관한 것으로서, 상세하게는 객체에 대해 동작하는 컴퓨터 구현 비교 기술에 관한 것이다.

관리 업무는 랩톱, 데스크톱 및 기타 등등과 같은 컴퓨팅 장치의 일상적인 운영을 지원한다. 네트워크화된 컴퓨팅 장치를 유지 보수하는 시스템 관리자는 많은 관리 업무를 수행한다. 관리 업무 중 하나는 원하는 대로 동작하지 않는 컴퓨팅 장치에서의 문제점을 알아내는 것이 있다. 이러한 유형의 문제점을 진단하는 한가지 기술로는 당해 컴퓨팅 장치를 제대로 동작하는 컴퓨팅 장치와 비교하는 것이 있다. 이러한 비교는 그래픽 사용자 인터페이스를 사용하여 2개의 장치 간에 설정을 시각적으로 비교 검토하는 것 또는 2개의 장치 상의 유사한 파일들 간의 비교를 수행하는 것을 포함할 수 있다.

비교를 위한 여러가지 유틸리티들이 꽤 오랫동안 이용가능하였다. 그렇지만, 각 유형의 파일은 그 유형의 파일에 특유한 도구를 사용하고 또 그 자신의 신택스(syntax) 및 특이점을 갖는다. 예를 들어, 파일의 유형이 텍스트 파일인 경우, 텍스트 비교 도구가 사용된다. 이와 마찬가지로, 파일의 유형이 바이너리(binary) 파일인 경우, 바이너리 비교 도구가 사용된다. 일반적으로, 이들 비교 유틸리티 각각은 차이점이 발견될 때까지 파일들을 살펴본다. 차이점이 발견될 때, 그 차이점은 시스템 관리자에게 보고된다. 이들 비교 유틸리티가 도움이 되는 반면, 이들 유틸리티는 종종 문제점과 관련이 없는 차이점을 보고한다. 따라서, 더욱 정확한 결과 및 더 많은 기능을 제공하는 비교 기술이 필요하다.

본 발명의 비교 기술은 동일한 유형, 유사한 유형 또는 서로 다른 유형의 객체에 대해 동작한다. 다수의 비교 객체(comparison object)들이 하나 이상의 참조 객체(reference object)에 대해 비교될 수 있다. 비교 객체는 객체 기반 환경에서 동작하는 cmdlet의 파이프라인에서의 이전의 cmdlet로부터 획득될 수 있다. 참조 객체 및 비교 객체는 순서 기반 방식으로 또는 키 기반 방식으로 비교될 수 있다. 게다가, 비교 동안에 참조 객체 및 비교 객체의 어느 속성들을 비교할 것인지를 식별해주는 특정의 속성들(properties)이 지정될 수 있다. 비교는 차이점 및/또는 유사점을 식별해주는 출력을 생성할 수 있다. 출력은 추가의 처리를 위해 다른 cmdlet으로 파이프라이닝될 수 있다.

간략히 기술하면, 본 발명의 비교 기술은 동일한 유형, 유사한 유형 또는 서로 다른 유형의 객체에 대해 동작한다. 이 비교는, 이 비교의 결과가 문제점을 종국적으로 해결할 수 있는 다른 동작에 대한 입력으로서 자동적으로 사용될 수 있게 해준다.

이하의 상세한 설명은 몇개의 섹션으로 나누어진다. 첫번째 섹션은 이 비교 기술이 동작할 수 있는 예시적인 컴퓨팅 환경에 대해 기술한다. 두번째 섹션은 본 발명의 비교 기술이 포함될 수 있는 객체 기반 관리 도구 환경에 대한 전형적인 프레임워크에 대해 기술한다. 이것은 전형적인 프레임워크의 개개의 컴포넌트 및 이 들 컴포넌트의 동작에 대한 상세한 설명을 포함한다. 세번째 섹션은 비교 기술 및 그의 동작에 대해 기술한다.

섹션 1 : 전형적인 컴퓨팅 환경

도 1은 본 발명의 비교 기술을 구현하는 데 사용될 수 있는 전형적인 컴퓨팅 장치를 나타낸 것이다. 아주 기본적인 구성에서, 컴퓨팅 장치(100)는 일반적으로 적어도 하나의 프로세싱 유닛(102) 및 시스템 메모리(104)를 포함한다. 컴퓨팅 장치의 정확한 구성 및 유형에 따라, 시스템 메모리(104)는 휘발성(RAM 등), 비휘발성(ROM, 플래쉬 메모리 등) 또는 이 둘의 어떤 조합일 수 있다. 시스템 메모리(104)는 일반적으로 오퍼레이팅 시스템(105) 및 하나 이상의 프로그램 모듈(106)을 포함하며, 하나 이상의 프로그램 데이터(107)를 포함할 수 있다. 시스템 메모리(104)는 또한 컴포넌트, 객체, 상속, 다형성(polymorphism), 및 리플렉션(reflection)을 지원하고 또 미국 워싱턴주 레드몬드 소재의 마이크로소프트사에 의해 제작된 .NET

프레임워크의 API 등의 객체-지향 컴포넌트-기반 애플리케이션 프로그래밍 인터페이스(API)를 제공하는 컴포넌트-기반 프레임워크(120)를 포함한다. 시스템 메모리(104)는 또한 관리 도구(도시 생략)의 개발을 지원하기 위해 컴포넌트-기반 프레임워크(120)와 상호작용하는 관리 도구 프레임워크(200)를 포함한다. 컴포넌트-기반 프레임워크(120) 및 관리 도구 프레임워크(200)는 (도시된 바와 같이) 오퍼레이팅 시스템(105)의 일부로서 존재하거나 프로그램 모듈(106)의 일부로서 존재할 수 있다. 이러한 기본적인 구성은 도 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: 관리 도구 프레임워크

도 2는 전형적인 관리 도구 프레임워크(200)의 개요를 전체적으로 나타낸 블록도이다. 관리 도구 프레임워크(200)는 하나 이상의 호스트 컴포넌트(202), 플랫폼 관련 컴포넌트(204), 호스트 독립적인 컴포넌트(206) 및 핸들러 컴포넌트(208)를 포함한다. 호스트 독립적인 컴포넌트(206)는 나머지 컴포넌트들(즉, 호스트 컴포넌트(202), 플랫폼 관련 컴포넌트(204) 및 핸들러 컴포넌트(208)) 각각과 통신할 수 있다. 이들 컴포넌트 각각은 이하에 간략하게 기술되며 필요한 경우 후속 섹션들에서 보다 상세히 기술된다.

호스트 컴포넌트

호스트 컴포넌트(202)는 관련 애플리케이션의 자동화 기능들을 사용자 또는 다른 프로그램들에 제시하는 하나 이상의 호스트 프로그램(예를 들어, 호스트 프로그램(210-214))을 포함한다. 자동화 기능들은 내비게이션, 진단, 구성, 라이프사 이클, 운용 등을 자동화할 수 있다. 각각의 호스트 프로그램(210-214)은 이들 자동화 기능들을 커맨드 라인(command line), 그래픽 사용자 인터페이스(GUI), 음성 인식 인터페이스, 애플리케이션 프로그래밍 인터페이스(API), 스크립팅 언어, 웹 서비스 등과 같은 그 자신의 특정 방식으로 제시할 수 있다. 그렇지만, 호스트 프로그램(210-214) 각각은 관리 도구 프레임워크에 의해 제공되는 메커니즘을 통해 하나 이상의 자동화 기능을 제시한다.

이 예에서, 이 메커니즘은 관련된 호스트 프로그램(210-214)의 사용자에게 관리 도구 기능들을 알려주기 위해 cmdlet를 사용한다. 게다가, 이 메커니즘은 관리 도구 환경을 대응하는 호스트 프로그램(21-214)과 연관된 애플리케이션에 내장시키기 위해 호스트에 의해 이용가능하게 되어 있는 일련의 인터페이스를 사용한다.

이하의 설명 전반에 걸쳐, 용어 "cmdlet"은 도 2 내지 도 13을 참조하여 기술되는 전형적인 관리 도구 환경 내에서 사용되는 커맨드(command)를 언급하기 위해 사용된다. 따라서, cmdlet은 종래의 관리 환경에서의 커맨드에 대응하지만, 이들 종래의 커맨드와는 상당히 다르다. 예를 들어, cmdlet은 일반적으로 그에 대응하는 커맨드보다 크기가 더 작은데, 그 이유는 cmdlet이 파싱, 데이터 검증, 에러 보고 등과 같은 관리 도구 프레임워크에 의해 제공되는 공통 기능을 이용할 수 있기 때문이다. 이러한 공통 기능들은 한꺼번에 구현되고 한꺼번에 테스트될 수 있기 때문에, 관리 도구 프레임워크 전반에 걸쳐 cmdlet을 사용하는 것은 애플리케이션 관련 기능들과 연관된 점증적 개발 및 테스트 비용을 종래의 환경에 비해 상당 히 절감시켜 줄 수 있다.

게다가, 종래의 환경과는 달리, cmdlet은 독립형 실행가능 프로그램(stand-alone executable program)일 필요가 없다. 오히려, cmdlet은 관리 도구 프레임워크 내의 동일한 프로세스들에서 실행될 수 있다. 이것은 cmdlet이 "살아 있는(live)" 객체들을 서로 교환할 수 있게 해준다. 이와 같이 "살아 있는" 객체들을 교환할 수 있다는 것은 cmdlet이 이들 객체에 대해 메소드를 직접 호출할 수 있게 해준다. 따라서, 용어 "살아 있는" 객체란 직접 호출가능한 메소드를 갖는 객체를 말한다. 이와 달리, "죽은(dead)" 객체란 직접 호출가능한 메소드를 갖지 않는 객체를 말한다. cmdlet을 생성 및 사용하는 것에 대한 상세는 이하에 보다 상세히 기술된다.

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

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

다른 예에서, 호스트 프로그램은 커맨드 라인 대화형 쉘(command line interactive shell)(즉, 호스트 프로그램(212))일 수 있다. 커맨드 라인 대화형 쉘은 커맨드 라인의 프로세싱에 영향을 주기 위해 쉘 메타데이터(shell metadata)(216)가 커맨드 라인 상에서 입력될 수 있게 해줄 수 있다.

또 다른 예에서, 호스트 프로그램은 여러 플랫폼, 프로그래밍 언어 및 애플리케이션에 걸친 분산 컴퓨팅 및 상호운용성(interoperability)을 위한 산업 표준 규격을 사용하는 웹 서비스(즉, 호스트 프로그램(214))일 수 있다.

이들 예 이외에, 써드 파티(third party)는 그의 호스트 프로그램 또는 다른 호스트 프로그램에서 사용되는 "프로바이더(provider)" 인터페이스 및 프로바이더 cmdlet을 생성함으로써 그 자신의 호스트 컴포넌트를 부가할 수 있다. 프로바이더 인터페이스는 애플리케이션 또는 하부 구조(infrastructure)가 관리 도구 프레임워크에 의해 처리될 수 있도록 애플리케이션 또는 하부 구조를 제시한다. 프로바이더 cmdlet은 내비게이션, 진단, 구성, 라이프 사이클, 운용 등을 위한 자동화를 제공한다. 프로바이더 cmdlet은 완전히 이질적인 일련의 데이터 스토어에 대해 다형적 cmdlet 거동을 나타낸다. 관리 도구 환경은 다른 cmdlet 클래스와 동일한 우선순위로 프로바이더 cmdlet에 대해 동작한다. 프로바이더 cmdlet은 다른 cmdlet과 동일한 메커니즘을 사용하여 생성된다. 프로바이더 cmdlet은 애플리케이션 또는 하부 구조의 특정의 기능을 관리 도구 프레임워크에 제시한다. 따라서, cmdlet의 사용을 통해, 제품 개발자는 그의 제품이 많은 관리 도구와 함께 동작할 수 있게 해주는 하나의 호스트 컴포넌트를 생성하기만 하면 된다. 예를 들어, 전형적인 관리 도구 환경에서, 시스템 레벨 그래픽 사용자 인터페이스 도움말 메뉴는 통합되어 기존의 애플리케이션에 포팅(port)될 수 있다.

플랫폼 관련 컴포넌트

플랫폼 관련 컴포넌트(204)는 관리 도구 프레임워크를 그 프레임워크가 실행되고 있는 플랫폼의 상세로부터 분리시키기 위해 컴퓨팅 시스템(예를 들어, 도 1의 컴퓨팅 장치(100))이 사용하는 서비스들의 컬렉션을 포함한다. 따라서, 각각의 유형의 플랫폼에 대한 일련의 플랫폼 관련 컴포넌트가 있다. 플랫폼 관련 컴포넌트는 사용자가 서로 다른 오퍼레이팅 시스템 상에서 동일한 관리 도구를 사용할 수 있게 해준다.

간략히 도 3을 참조하면, 플랫폼 관련 컴포넌트(204)는 메타데이터/컨텍스트 의존(metadata/context sensitive) 입력 컴포넌트(302), 도움말 컴포넌트(304), 구성/등록 컴포넌트(306), cmdlet 셋업 컴포넌트(308) 및 출력 인터페이스 컴포넌트(309)를 포함할 수 있다. 컴포넌트(302-308)는 데이터베이스 스토어(314)와 연관된 데이터베이스 스토어 관리자(312)와 통신한다. 파서(220) 및 스크립트 엔진(222)은 메타데이터/컨텍스트 의존 입력 컴포넌트(302)와 통신한다. 코어 엔진(224)은 도움말 cmdlet 컴포넌트(304), 구성/등록 컴포넌트(306), cmdlet 셋업 컴포넌트(308) 및 출력 인터페이스 컴포넌트(309)와 통신한다. 출력 인터페이스 컴포넌트(309)는 cmdlet을 출력하기 위해 호스트에 의해 제공되는 인터페이스를 포함한다. 출력되는 cmdlet은 렌더링을 수행하기 위해 호스트의 출력 객체를 호출할 수 있다. 플랫폼 관련 컴포넌트(204)는 또한 코어 엔진(224)이 로깅 및 감사 기능을 제공하는 호스트 관련(즉, 플랫폼 관련) 서비스와 통신하기 위해 사용하는 로깅/감사 컴포넌트(310)를 포함할 수 있다.

한 전형적인 관리 도구 프레임워크에서, 메타데이터/컨텍스트 의존 입력 컴포넌트(302)는 커맨드, 파라미터 및 파라미터 값의 자동 완성(auto-completion)을 제공한다. 도움말 cmdlet 컴포넌트(304)는 호스트 사용자 인터페이스에 기초하여 커스터마이즈된 도움말 시스템을 제공한다.

핸들러 컴포넌트

다시 도 2를 참조하면, 핸들러 컴포넌트(208)는 레거시 유틸리티(legacy utility)(230), 관리 cmdlet(232), 비관리 cmdlet(234), 리모팅(remoting) cmdlet(236) 및 웹 서비스 인터페이스(238)를 포함한다. 이들 각각은 이하에 더욱 상세히 기술된다. 관리 cmdlet(232)(플랫폼 cmdlet이라고도 함)은 컴퓨팅 장치와 연관된 구성 정보를 질의 또는 처리하는 cmdlet을 포함한다. 관리 cmdlet(232)은 시스템 유형 정보를 처리하기 때문에 특정의 플랫폼에 의존하고 있다. 그렇지만, 각각의 플랫폼은 일반적으로 다른 플랫폼 상에서의 관리 cmdlet(232)과 유사한 동작을 제공하는 관리 cmdlet(232)을 갖는다. 예를 들어, 각각의 플랫폼은 시스템 관리 속성의 가져오기(get) 및 설정하기(set)(예를 들어, get/process, set/IPAddress)를 행하는 관리 cmdlet(232)을 지원한다. 호스트 독립적인 컴포넌트(206)는 public형 API를 통해 관리 cmdlet과 통신한다.

비관리 cmdlet(234)(때로는 베이스 cmdlet이라고도 함)은 관리 cmdlet(232) 및 임의의 다른 cmdlet에 의해 제공되는 객체들에 대한 그룹화, 정렬, 필터링 및 기타 프로세싱을 수행하는 cmdlet을 포함한다. 본 발명의 비교 기술에 따르면, 비관리 cmdlet(234)은 "compare-object(객체 비교)" cmdlet을 포함하며, 이에 대해서는 도 14 내지 도 23과 연계하여 상세히 기술된다. 비관리 cmdlet(234)은 각각의 플랫폼 상에서 동일할 수 있고 또 public형 API를 통해 호스트 독립적인 컴포넌트(206)와 상호작용하는 일련의 유틸리티를 제공할 수 있다. 비관리 cmdlet(234)와 호스트 독립적인 컴포넌트(206) 사이의 상호작용은 객체들에 대한 리플렉션을 가능하게 해주며 또 리플렉션된 객체들에 대한 프로세싱을 그의 (객체) 유형에 관계없이 가능하게 해준다. 따라서, 이들 유틸리티는 개발자가 비관리 cmdlet들을 한꺼번에 작성한 다음에 이들 비관리 cmdlet을 컴퓨팅 시스템 상에서 지원되는 모든 부류의 객체들에 걸쳐 적용할 수 있게 해준다. 과거에는, 개발자가 처리될 데이터의 포맷을 먼저 이해한 다음에 그 데이터만을 처리하기 위한 애플리케이션을 작성해야만 하였다. 그 결과, 종래의 애플리케이션은 아주 한정된 범위의 데이터 밖에 처리할 수 없었다. 객체를 그의 객체 유형에 상관없이 처리하는 한 전형적인 메커니즘이 도 13과 연계하여 이하에 기술된다.

레거시 유틸리티(230)는 win32 커맨드 라인 실행 파일 등의 기존의 실행 파일을 포함한다. 각각의 레거시 유틸리티(230)는 객체 프레임워크 내의 한 유형의 객체인 텍스트 스트림(예를 들어, stdin, stdout 및 stderr)을 사용하여 관리 도구 프레임워크와 통신한다. 레거시 유틸리티(230)가 텍스트 스트림을 이용하기 때문에, 관리 도구 프레임워크에 의해 제공되는 리플렉션 기반 동작은 이용할 수 없다. 레거시 유틸리티(230)는 관리 도구 프레임워크와 다른 프로세스에서 실행된다. 도시되어 있지는 않지만, 다른 cmdlet도 아웃 오브 프로세스(out of process)로 동작할 수 있다.

리모팅 cmdlet(236)은 웹 서비스 인터페이스(238)와 함께 인터넷 또는 인트라넷(예를 들어, 도 2에 도시한 인터넷/인트라넷(240)) 등의 통신 매체를 통해 다른 컴퓨팅 장치 상의 대화형 및 프로그램적 관리 도구 환경에 액세스하기 위한 리모팅 메커니즘을 제공한다. 한 전형적인 관리 도구 프레임워크에서, 리모팅 메커니즘은 다수의 독립적인 제어 도메인에 걸쳐 있는 하부 구조에 의존하는 연합 서비스(federated service)를 지원한다. 리모팅 메커니즘에 의해 스크립트가 원격 컴퓨팅 장치 상에서 실행될 수 있게 된다. 스크립트는 단일 원격 시스템 또는 다중 원격 시스템 상에서 실행될 수 있다. 스크립트의 결과는 각각의 개별적인 스크립 트가 완료될 때 처리될 수 있거나 또는 여러가지 컴퓨팅 장치 상의 모든 스크립트가 완료된 후에 그 결과가 총합되어 모두 함께 처리될 수 있다.

예를 들어, 호스트 컴포넌트(202)의 하나로서 도시되어 있는 웹 서비스(214)는 원격 에이전트일 수 있다. 다른 실시예에서, 웹 서비스(214)는 통신 매체(240)를 통해 엔진과 통신하는 별도의 컴포넌트(도시 생략)일 수 있다. 어느 구성이든지, 웹 서비스(214)는 이어서 cmdlet을 제어하기 위해 다른 호스트 컴포넌트와 통신하도록 구성되어 있는 엔진과 통신한다. 원격 에이전트는 원격 커맨드 요청을 타겟 시스템 상의 파서 및 관리 도구 프레임워크로 전송하는 일을 처리한다. 리모팅 cmdlet은 원격 에이전트로의 액세스를 제공하는 원격 클라이언트로서 기능한다. 원격 에이전트 및 리모팅 cmdlet은 파싱된 스트림을 통해 통신한다. 이 파싱된 스트림은 프로토콜 계층에서 보호될 수 있거나 또는 부가의 cmdlet이 파싱된 스트림을 암호화하고 이어서 복호화하는 데 사용될 수 있다.

호스트 독립적인 컴포넌트

호스트 독립적인 컴포넌트(206)는 파서(220), 스크립트 엔진(222) 및 코어 엔진(224)을 포함한다. 호스트 독립적인 컴포넌트(206)는 다수의 cmdlet의 그룹화, cmdlet의 동작의 조정 및 다른 리소스, 세션 및 작업의 cmdlet와의 상호작용의 조정을 위한 메커니즘 및 서비스를 제공한다.

전형적인 파서

파서(220)는 여러가지 호스트 프로그램으로부터의 입력 요청을 수신하고 그 입력 요청을 코어 엔진(224) 내에서 등의 관리 도구 프레임워크 전반에 걸쳐 사용 되는 일관된 cmdlet 객체로 매핑하는 메커니즘을 제공한다. 게다가, 파서(220)는 수신된 입력에 기초하여 데이터 프로세싱을 수행할 수 있다. 파서(220)는 동일한 기능들을 위해 서로 다른 언어 또는 신택스를 사용자에게 용이하게 제시하는 기능을 제공한다. 예를 들어, 파서(220)가 입력 요청을 해석하는 일을 맡고 있기 때문에, 예상된 입력 신택스에 영향을 주는 파서(220) 내의 코드에 대한 변화는 기본적으로 관리 도구 프레임워크의 각 사용자에게 영향을 주게 된다. 따라서, 시스템 관리자는 다른 신택스를 지원하는 다른 컴퓨팅 장치 상에서는 다른 파서를 제공할 수 있다. 그렇지만, 동일한 파서로 작업하는 각 사용자는 각각의 cmdlet에 대해 일관된 신택스를 경험하게 된다. 이와 달리, 종래의 환경에서는, 각 커맨드는 그 자신의 신택스를 구현하였다. 따라서, 수천개의 커맨드에 있어서, 각 환경은 몇가지 서로 다른 신택스를 지원하였고, 보통 그 중 많은 것이 서로 부합되지 않았다.

전형적인 스크립트 엔진

스크립트 엔진(222)은 스크립트를 사용하여 다수의 cmdlet을 서로 연계시키는 메커니즘 및 서비스를 제공한다. 스크립트는 엄격한 상속 규칙 하에서 세션 상태를 공유하는 커맨드 라인들의 집합이다. 스크립트 내의 다수의 커맨드 라인은 입력 요청에 제공되어 있는 신택스에 따라 동기적으로 또는 비동기적으로 실행될 수 있다. 스크립트 엔진(222)은 루프 및 조건절 등의 제어 구조를 처리하고 또 스크립트 내에서 변수를 처리하는 기능을 갖는다. 스크립트 엔진은 또한 세션 상태를 관리하고 정책(도시 생략)에 기초하여 세션 데이터에 대한 cmdlet 액세스를 제공한다.

전형적인 코어 엔진

코어 엔진(224)은 파서(220)에 의해 식별되는 cmdlet을 처리하는 일을 맡고 있다. 간략히 도 4를 참조하면, 관리 도구 프레임워크(220) 내의 전형적인 코어 엔진(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을 전달(dispatch)한다. 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가지 속성, 컬럼 속성(column property)과 로우 속성(row property)를 갖는다는 것이다. 이들 2가지 속성은 데이터테이블 내의 "객체들"에 관한 충분한 상세를 제공하지 않는다. 리플렉션이 확장가능 마크업 언어(XML) 및 다른 객체들에 대해 사용될 때 유사한 문제가 일어난다.

따라서, 객체의 유형에 초점을 두지 않고, 확장 유형 관리자(412)는 객체가 요구되는 정보를 획득하는 데 사용될 수 있는지 여부를 판정하기 위해 그 유형의 용법에 초점을 둔다. 계속하여 상기 데이터테이블 예에서, 데이터테이블이 컬럼 속성 및 로우 속성을 갖는다는 사실은 특별히 관심을 끌지 않는다. 오히려, 관심을 끄는 것은 한 컬럼이 관심이 있는 정보를 포함하고 있다는 것이다. 따라서, 용법에 초점을 맞추면, 확장 유형 관리자(412)는 각각의 로우를 "객체"와 연관시키고 각각의 컬럼을 그 "객체"의 "속성"와 연관시킨다. 이와 같이, 확장 유형 관리자(412)는 임의의 유형의 정밀 파싱가능 입력(precisely parse-able input)으로부터 "객체"를 생성하는 메커니즘을 제공한다. 그렇게 함에 있어서, 확장 유형 관리자(412)는 컴포넌트 기반 프레임워크(120)에 의해 제공되는 리플렉션 기능을 보충하며 "리플렉션"을 임의의 유형의 정밀 파싱가능 입력으로 확장시킨다.

요약하면, 확장 유형 관리자는 정밀 파싱가능 입력(도시 생략)에 액세스하고 그 정밀 파싱가능 입력을 요청된 데이터 유형과 상관시키도록 구성되어 있다. 확장 유형 관리자(412)는 이어서 요청된 정보를 파이프라인 프로세서(402) 또는 파서(220) 등의 요청측 컴포넌트에 제공한다. 이하의 설명에서, 정밀 파싱가능 입력은 속성 및 값이 구별될 수 있는 입력으로서 정의된다. 어떤 전형적인 정밀 파싱가능 입력은 WMI(Windows Management Instrumentation) 입력, ADO(ActiveX Data Object) 입력, XML(eXtensible Markup Language) 입력 및 .NET 객체 등의 객체 입력을 포함한다. 다른 정밀 파싱가능 입력은 써드 파티 데이터 포맷을 포함할 수 있다.

간략히 도 13을 참조하면, 관리 도구 프레임워크 내에서 사용하기 위한 전형적인 확장 유형 관리자의 기능 블록도가 도시되어 있다. 설명 목적상, 확장 유형 관리자에 의해 제공된 기능(원 내에 번호 "3"으로 표시됨)은 종래의 밀접하게 바인딩된 시스템(tightly bound system)(원 내에 번호 "1"로 표시됨)에 의해 제공되는 기능 및 리플렉션 시스템(원 내에 번호 "2"로 표시됨)에 의해 제공되는 기능과 대조를 이룬다. 종래의 밀접하게 바인딩된 시스템에서, 애플리케이션 내의 호출자(caller)(1302)는 객체 A 내의 정보(예를 들어, 속성(A, B), 메소드(M1, M2))에 직접 액세스한다. 전술한 바와 같이, 호출자(1302)는 컴파일 시에 객체 A에 의해 제공되는 속성(예를 들어, 속성(A, B)) 및 메소드(예를 들어, 메소드(M1, M2))를 사 전에 알고 있어야만 한다. 리플렉션 시스템에서, 일반 코드(generic code)(1320)(임의의 데이터 유형에 종속되지 않음)는 요청된 객체에 대해 리플렉션(1310)을 수행하고 그 객체(예를 들어, 객체 A)에 관한 정보(예를 들어, 속성(A, B), 메소드(M1, M2))를 일반 코드(1320)에 반환하는 시스템(1308)에 질의를 한다. 객체 A에 도시되어 있지는 않지만, 반환된 정보는 벤더(vendor), 파일, 날짜, 기타 등등의 부가의 정보를 포함할 수 있다. 따라서, 리플렉션을 통해, 일반 코드(1320)는 밀접하게 바인딩된 시스템이 제공하는 적어도 동일한 정보를 획득한다. 리플렉션 시스템은 또한 호출자(1302)가 파라미터에 대한 어떤 사전 지식도 없이 시스템에 질의하여 부가의 정보를 가져오는 것을 가능하게 해준다.

밀접하게 바인딩된 시스템 및 리플렉션 시스템 둘다에서, 새로운 데이터 유형이 오퍼레이팅 환경 내에 용이하게 포함될 수 없다. 예를 들어, 밀접하게 바인딩된 시스템에서, 오퍼레이팅 환경이 인도(deliver)되었으면, 오퍼레이팅 환경은 새로운 데이터 유형을 포함할 수 없는데 그 이유는 그 오퍼레이팅 환경이 새로운 데이터 유형을 지원하도록 재구축되어야만 하기 때문이다. 이와 마찬가지로, 리플렉션 시스템에서, 각각의 객체 클래스에 대한 메타데이터가 고정되어 있다. 따라서, 새로운 데이터 유형을 포함시키는 것은 보통 행해지지 않는다.

그렇지만, 본 발명의 확장 유형 관리자에서는, 새로운 데이터 유형이 오퍼레이팅 시스템에 포함될 수 있다. 확장 유형 관리자(1322)에서, 일반 코드(1320)는 써드 파티 객체(예를 들어, 객체 A' 및 B), 시맨틱 웹(semantic web)(1332), 분류체계 서비스(ontology service)(1334), 기타 등등의 여러가지 외부 소스에 의해 제 공되는 확장 데이터 유형(예를 들어, 객체 A')을 획득하기 위해 요청된 객체를 고려할 수 있다. 도시한 바와 같이, 써드 파티 객체는 기존의 객체를 확장시킬 수 있거나(예를 들어, 객체 A'), 완전히 새로운 객체를 생성할 수 있다(예를 들어, 객체 B).

이들 외부 소스 각각은 그 고유의 구조를 유형 메타데이터(1340) 내에 등록할 수 있고 또 코드(1342)를 제공할 수 있다. 객체가 조사될 때, 확장 유형 관리자는 그 객체가 등록되어 있는지 여부를 판정하기 위해 유형 메타데이터(1340)를 검토한다. 그 객체가 유형 메타데이터(1340) 내에 등록되어 있지 않은 경우, 리플렉션이 수행된다. 그렇지 않은 경우, 확장 리플렉션(extended reflection)이 수행된다. 코드(1342)는 검토되고 있는 유형과 연관된 부가의 속성 및 메소드를 반환한다. 예를 들어, 입력 유형이 XML인 경우, 코드(1342)는 XML 문서로부터 객체를 생성하기 위해 XML이 사용되는 방식을 기술하는 설명 파일을 포함할 수 있다. 따라서, 유형 메타데이터(1340)는 확장 유형 관리자(412)가 그 특정 입력 유형에 대한 객체를 생성하는 데 요망되는 속성을 획득하기 위해 여러가지 유형의 정밀 파싱가능 입력(예를 들어, 써드 파티 객체(A', B), 시맨틱 웹(1332))을 어떻게 조사해야 하는지를 기술하고, 코드(1342)는 이들 요망되는 속성을 획득하기 위한 명령어를 제공한다. 그 결과, 확장 유형 관리자(412)는 모든 유형의 객체에 대한 "리플렉션"을 가능하게 해주는 인디렉션 계층(a layer of indirection)을 제공한다.

확장 유형을 제공하는 것 이외에, 확장 유형 관리자(412)는 속성 경로(property path) 메커니즘, 키(key) 메커니즘, 비교(compare) 메커니즘, 변환 (conversion) 메커니즘, 글로버(globber) 메커니즘, 속성 세트(property set) 메커니즘, 관계(relationship) 메커니즘 및 기타 등등의 부가의 질의 메커니즘을 제공한다. 이하의 섹션 "전형적인 확장 유형 관리자 프로세싱"에 기술되는 이들 질의 메커니즘 각각은 커맨드 스트링을 입력할 때 시스템 관리자들에게 유연성을 제공한다. 확장 유형 관리자에 대한 시맨틱스(semantics)를 구현하기 위해 여러가지 기술들이 사용될 수 있다. 이들 기술에 대해서는 이하에 기술된다. 그렇지만, 당업자라면 이들 기술의 변형들이 청구된 발명의 범위를 벗어나지 않고 사용될 수 있음을 잘 알 것이다.

한 기술에서, 정적 메소드(예를 들어, getproperty())를 갖는 일련의 클래스가 제공될 수 있다. 객체는 정적 메소드에 입력되고(예를 들어, getproperty(object)), 정적 메소드는 일련의 결과를 반환한다. 다른 기술에서, 오퍼레이팅 환경은 객체를 어댑터(adapter)로 포장한다. 따라서, 아무런 입력도 제공되지 않는다. 어댑터의 각각의 인스턴스는 포장된 객체에 대해 작용하여 포장된 객체의 속성을 반환하는 getproperty 메소드를 갖는다. 이하는 이 기술을 설명하는 의사 코드이다.

Class Adaptor

{

Object X;

getProperties();

}.

또다른 기술에서, 어댑터 클래스는 객체를 서브클래스화한다. 종래에, 서브클래스화(subclassing)는 컴파일 이전에 있었다. 그렇지만, 어떤 오퍼레이팅 환경에서, 서브클래스화는 동적으로 일어날 수 있다. 이러한 유형의 환경에 있어서, 이하는 이 기술을 예시하는 의사 코드이다.

Class A: Adaptor

{

getProperties()

{

return data;

}

}.

따라서, 도 13에 도시한 바와 같이, 확장 유형 관리자는 개발자가 새로운 데이터 유형을 생성할 수 있게 해주고 또 다른 애플리케이션 및 cmdlet이 그 새로운 데이터 유형을 사용할 수 있게 해준다. 이와 달리, 종래의 관리 환경에서, 각각의 데이터 유형은 그 데이터 유형으로부터 인스턴스화된 객체와 연관된 속성 또는 메소드가 직접 액세스될 수 있도록 컴파일 시에 알려져 있어야만 한다. 따라서, 과거에는 관리 환경에 의해 지원된 새로운 데이터 유형을 부가하는 것이 극히 드물었다.

다시 도 2를 참조하면, 요약하면, 관리 도구 프레임워크(200)는 사용자에 의해 입력된 커맨드의 실행을 조정하기 위해 쉘에 의존하지 않으며, 오히려 그 기능 을 프로세싱 부분(예를 들어, 호스트 독립적인 컴포넌트(206)) 및 사용자 상호작용 부분으로 (예를 들어, 호스트 cmdlet를 통해) 분할한다. 게다가, 관리 도구 환경은 관리 도구의 프로그래밍을 크게 단순화시키는데 그 이유는 파싱 및 데이터 검증을 위해 요구되는 코드가 각 커맨드에 더 이상 포함되지 않고 오히려 관리 도구 프레임워크 내의 컴포넌트(예를 들어, 파서(220))에 의해 제공되기 때문이다. 관리 도구 프레임워크 내에서 수행되는 전형적인 프로세싱이 이하에 기술된다.

전형적인 동작

도 5 및 도 6은 관리 도구 환경 내에서 사용되는 전형적인 데이터 구조를 도식적으로 나타낸 것이다. 도 7 내지 도 12는 관리 도구 환경 내에서의 전형적인 프로세싱 흐름을 도식적으로 나타낸 것이다. 당업자라면 어떤 프로세싱은 본 발명의 범위를 벗어나지 않고 이하에 기술된 프로세싱과 다른 컴포넌트에 의해 수행될 수 있음을 잘 알 것이다. 관리 도구 프레임워크의 컴포넌트 내에서 수행되는 프로세싱을 기술하기 전에, 관리 도구 프레임워크 내에서 사용되는 전형적인 데이터 구조에 대해 기술한다.

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))을 갖는 public형 클래스이다. cmdlet(500)은 cmdlet 클래스(506)로부터 파생된다. cmdlet 클래스(504)의 전형적인 데이터 구조는 도 6과 관련하여 이하에 기술된다. 각각의 cmdlet(500)은 이름(예를 들어, Stop/Process)을 cmdlet(500)과 연관시키는 커맨드 속성(command attribute)(502)과 연관되어 있다. 그 이름은 관리 도구 환경 내에 등록된다. 이하에 기술되는 바와 같이, 파서는 그 이름(예를 들어, Stop/Process)을 갖는 커맨드 스트링이 커맨드 라인 상에서 또는 스크립트 내에서 입력으로서 제공될 때 cmdlet(500)을 식별하기 위해 cmdlet 레지스트리를 살펴본다.

cmdlet(500)은 cmdlet으로의 예상된 입력 파라미터에 대한 문법을 정의하는 문법 메커니즘과 연관되어 있다. 문법 메커니즘은 직접적으로 또는 간접적으로 cmdlet과 연관되어 있을 수 있다. 예를 들어, cmdlet(500)은 직접적 문법 연관(direct grammar association)을 나타낸다. 이 cmdlet(500)에서, 하나 이상의 public형 파라미터(예를 들어, ProcessName(510) 및 PID(512))가 선언된다. public형 파라미터의 선언은 입력 객체의 cmdlet(510)으로 파싱을 주도한다. 다른 대안으로서, 파라미터의 설명이 XML 문서 등의 외부 소스에 나타날 수 있다. 이 외부 소스에 있는 파라미터의 설명은 입력 객체의 cmdlet으로 파싱을 주도한다.

각각의 public형 파라미터(510, 512)는 그와 연관된 하나 이상의 속성(즉, 디렉티브)을 가질 수 있다. 디렉티브(directive)는 이하의 카테고리, 즉 파싱 디렉티브(520), 데이터 검증 디렉티브(521), 데이터 생성 디렉티브(522), 프로세싱 디렉티브(523), 인코딩 디렉티브(524) 및 문서화 디렉티브(525) 중 임의의 것으로부터 온 것일 수 있다. 디렉티브는 대괄호([])로 둘러싸여 있을 수 있다. 각각의 디렉티브는 그 다음의 예상 입력 파라미터에 대해 수행될 동작을 기술한다. 사용자-상호작용형 디렉티브(user-interaction type directive) 등의 디렉티브 중 일부는 또한 클래스 레벨에서 적용될 수 있다. 디렉티브는 cmdlet와 연관된 메타데이터에 저장된다.

이들 속성은 또한 cmdlet 내에서 선언된 파라미터의 파퓰레이션(population)에 영향을 줄 수 있다. 이들 파라미터를 설정하기 위한 한 프로세스가 도 11을 참조하여 기술된다. 코어 엔진은 컴플라이언스(compliance)를 보장하기 위해 이들 디렉티브를 적용할 수 있다. cmdlet(500)은 제1 메소드(530)(이후, 상호교환적으로 BeginProcessing 메소드(530)이라고 함) 및 제2 메소드(540)(이후, 상호교환적으로 ProcessRecord 메소드(540)이라고 함)를 포함한다. 코어 엔진은 cmdlet(500)의 프로세싱을 지시하기 위해 제1 및 제2 메소드(530, 540)를 사용한다. 예를 들어, 제1 메소드(530)는 한번 실행되고 셋업 함수를 수행한다. 제2 메소드(540) 내의 코드(542)는 cmdlet(500)에 의해 처리될 필요가 있는 각 객체(예를 들어, 레코드)에 대해 실행된다. cmdlet(500)은 또한 cmdlet(500) 후에 마무리를 하는 써드 파티 메소드(도시 생략)를 포함할 수 있다.

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

도 6은 cmdlet를 지정하기 위한 전형적인 데이터 구조(600)이다. 요약하면, 데이터 구조(600)는 관리 도구 프레임워크와 cmdlet 간의 계약을 명확히 표현하는 수단을 제공한다. 데이터 구조(600)는 cmdlet 클래스(604)로부터 파생되는 public형 클래스이다. 소프트웨어 개발자는 "get/process" 및 "format/table" 등의 명사/동사 쌍을 cmdlet(600)과 연관시키는 cmdletDeclaration(602)을 지정할 수 있다. 명사/동사 쌍은 관리 도구 환경 내에 등록된다. 동사 또는 명사는 cmdlet 이름에서 암시적일 수 있다. 또한, 데이터 구조(500)와 유사하게, 데이터 구조(600)는 데이터 구조(500)와 관련하여 기술된 하나 이상의 디렉티브(520-525)와 연관될 수 있는 하나 이상의 public형 멤버(예를 들어, Name(630), Recurse(632))를 포함할 수 있다.

그렇지만, 이 전형적인 데이터 구조(600)에서, 각각의 예상 입력 파라미터(630, 632)는 입력 속성(631, 633)과 각각 연관되어 있다. 입력 속성(631, 633)은 그의 개별적인 파라미터(630, 632)에 대한 데이터가 커맨드 라인으로부터 획득되어야만 하는 것으로 지정한다. 따라서, 이 전형적인 데이터 구조(600)에서는, 다른 cmdlet에 의해 생성(emit)된 파이프라인 객체로부터 파퓰레이션되는 어떤 예상 입력 파라미터도 없다. 따라서, 데이터 구조(600)는 cmdlet 베이스 클래스에 의해 제공되는 제1 메소드(예를 들어, BeginProcessing) 또는 제2 메소드(예를 들어, ProcessRecord)를 오버라이드(override)하지 않는다.

데이터 구조(600)는 또한 입력 파라미터로서 인식되지 않는 다른 멤버(640)를 포함할 수 있다. 다른 멤버(640)는 디렉티브 중 하나에 기초하여 발생된 데이터를 저장하는 데 사용될 수 있으며 또 private형이거나 public형일 수 있다.

따라서, 데이터 구조(600)에 예시한 바와 같이, 특정의 cmdlet 클래스 내에 public형 속성 및 디렉티브를 선언함으로써, cmdlet 개발자는 기반이 되는 로직을 전혀 생성할 필요없이 그의 cmdlet로의 예상 입력 파라미터에 대한 문법을 용이하게 지정할 수 있고 예상 입력 파라미터에대해 수행되어야만 하는 프로세싱을 지정할 수 있다. 데이터 구조(600)는 cmdlet과 문법 메커니즘 간의 직접적인 연관 관계를 나타낸 것이다. 전술한 바와 같이, 이 연관 관계는 XML 문서 등의 외부 소스 내에 예상 파라미터 정의를 지정하는 것에 의하는 등 간접적일 수 있다.

이제부터, 관리 도구 환경 내에서의 전형적인 프로세스 흐름에 대해 기술한다.

전형적인 호스트 프로세싱 흐름

도 7은 도 2에 도시된 관리 도구 프레임워크 내에서 수행되는 호스트 프로세싱에 대한 전형적인 프로세스를 나타내는 논리 흐름도이다. 프로세스(700)는 특정의 애플리케이션을 위해 관리 도구 환경을 개시하라는 요청이 수신되는 블록(701)에서 시작한다. 그 요청은 애플리케이션 아이콘을 선택하는 등 키보드 입력을 통해 로컬적으로 또는 다른 컴퓨팅 장치의 웹 서비스 인터페이스를 통해 원격적으로 전송된 것일 수 있다. 어느 경우든지, 프로세싱은 블록(702)으로 진행한다.

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

블록(704)에서, 특정의 애플리케이션을 통해 입력이 획득된다. 전술한 바와 같이, 입력은 커맨드 라인, 스크립트, 음성, GUI 등과 같은 몇가지 형태를 취할 수 있다. 예를 들어, 커맨드 라인을 통해 입력이 획득되는 경우, 그 입력은 키보드 상에서 입력된 키스트로크(keystroke)로부터 검색된다. GUI 호스트의 경우, 스트링은 GUI와 연관된 입력 메커니즘에 기초하여 작성된다. 프로세싱은 블록(706)에서 계속된다.

블록(706)에서, 입력은 프로세싱을 위해 관리 도구 프레임워크 내의 다른 컴포넌트로 제공된다. 호스트 프로그램은 그 입력을 파서 등의 다른 컴포넌트로 직접 포워드(forward)할 수 있다. 다른 대안으로서, 호스트 프로그램은 그 입력을 그의 호스트 cmdlet를 통해 포워드할 수 있다. 호스트 cmdlet은 그의 특정 유형의 입력(예를 들어, 음성)을 관리 도구 프레임워크에 의해 인식되는 유형의 입력(예를 들어, 텍스트 스트링, 스크립트)으로 변환할 수 있다. 예를 들어, 음성 입력은 음성 입력의 내용에 따라 스크립트 또는 커맨드 라인 스트링으로 변환될 수 있다. 각각의 호스트 프로그램이 그의 유형의 입력을 관리 도구 프레임워크에 의해 인식되는 입력으로 변환하는 일을 맡고 있기 때문에, 관리 도구 프레임워크는 임의의 수의 여러가지 호스트 컴포넌트로부터 입력을 받을 수 있다. 게다가, 관리 도구 프레임워크는 입력이 그의 cmdlet 중 하나를 통해 포워드될 때 데이터 유형들 간의 변환을 수행하는 풍부한 일련의 유틸리티를 제공한다. 다른 컴포넌트에 의해 그 입력에 대해 수행되는 프로세싱은 몇개의 다른 도면을 참조하여 이하에 기술된다. 호스트 프로세싱은 판정 블록(708)에서 계속된다.

판정 블록(708)에서, 부가의 입력에 대한 요청이 수신되었는지 여부의 판정이 행해진다. 이것은 입력을 처리하는 일을 맡고 있는 다른 컴포넌트들 중 하나가 그의 프로세싱을 완료하기 위해 사용자로부터 부가의 정보를 필요로 하는 경우 일어날 수 있다. 예를 들어, 어떤 데이터에 액세스하기 위해 패스워드가 요구될 수 있고, 특정 동작의 확인이 필요할 수 있으며, 기타 등등이 있을 수 있다. 어떤 유형의 호스트 프로그램(예를 들어, 음성 메일)의 경우, 이것과 같은 요청은 적절하지 않을 수 있다. 따라서, 추가의 정보를 위해 사용자에게 질의를 하는 대신에, 호스트 프로그램은 상태를 직렬화하고, 상태를 일시 중단시키며, 나중에 상태가 재개될 수 있고 입력의 실행이 계속될 수 있도록 통지를 전송한다. 다른 변형예에 서, 호스트 프로그램은 소정의 기간 후에 디폴트 값을 제공할 수 있다. 부가의 입력에 대한 요청이 수신되면, 프로세싱은 부가의 입력이 획득되는 블록(704)으로 루프백된다. 프로세싱은 이어서 전술한 바와 같이 블록(706, 708)을 계속 통과한다. 부가의 입력에 대한 요청이 수신되지 않고 입력이 처리된 경우, 프로세싱은 블록(710)으로 계속된다.

블록(710)에서, 관리 도구 프레임워크 내의 다른 컴포넌트들로부터 결과가 수신된다. 이 결과는 에러 메시지, 상태, 경과 등을 포함할 수 있다. 결과는 관리 도구 프레임워크 내의 호스트 cmdlet에 의해 인식되고 처리되는 객체 형태로 되어 있다. 이하에 기술하는 바와 같이, 각각의 호스트 cmdlet에 대해 작성된 코드는 아주 최소한의 것이다. 따라서, 개발 비용에 엄청난 투자를 필요로 하지 않고 풍부한 일련의 출력이 디스플레이될 수 있다. 프로세싱은 블록(712)에서 계속된다.

블록(712)에서, 결과를 볼 수 있다. 호스트 cmdlet은 결과를 호스트 프로그램에 의해 지원되는 디스플레이 스타일로 변환한다. 예를 들어, 반환된 객체는 아이콘, 짖는 개 등과 같은 그래픽 표현을 사용하여 GUI 호스트 프로그램에 의해 디스플레이될 수 있다. 호스트 cmdlet은 그 데이터에 대한 디폴트 포맷 및 출력을 제공한다. 그 결과가 선택적으로 디스플레이된 후에, 호스트 프로세싱은 종료된다.

입력을 처리하기 위한 전형적인 프로세스 흐름

이제부터, 커맨드 스트링을 처리하기 위한 한 전형적인 프로세스에 대해 기 술한다. 도 8은 도 2에 도시된 관리 도구 프레임워크 내의 파서(220) 및 코어 엔진(224)을 통한 커맨드 스트링의 프로세싱을 도식적으로 나타낸 기능 흐름도이다. 전형적인 커맨드 스트링(850)은 몇개의 커맨드(즉, process 커맨드(860), where 커맨드(862), sort 커맨드(864) 및 table 커맨드(866))를 파이프라이닝한다. 커맨드 라인(850)은 입력 파라미터를 커맨드 중 임의의 것에 전달할 수 있다(예를 들어, "handlecount>400"은 where 커맨드(862)로 전달된다). process 커맨드(860)는 어떤 연관된 입력 파라미터도 갖지 않음에 유의해야 한다.

파서(220)는 파싱가능 스트림(예를 들어, 커맨드 스트링(850))을 구성 부분들(820-826)(예를 들어, where 부분(822))로 파싱한다. 각 부분(820-826)은 cmdlet(830-836) 중 하나와 연관되어 있다. 파서(220) 및 엔진(224)은 파싱, 파라미터 검증, 데이터 생성, 파라미터 프로세싱, 파라미터 인코딩 및 파라미터 문서화 등의 여러가지 프로세싱을 수행한다. 파서(220) 및 엔진(224)이 커맨드 라인 상의 입력 파라미터에 대해 공통 기능을 수행하기 때문에, 관리 도구 프레임워크(200)는 일관된 에러 메시지를 사용자에게 발행할 수 있다.

잘 알고 있는 바와 같이, 실행가능 cmdlet(830-836)은 종래의 관리 환경에서의 커맨드보다 더 적은 코드를 필요로 한다. 각각의 실행가능 cmdlet(830-836)은 그의 개별적인 구성 부분(820-826)을 사용하여 식별된다. 게다가, 각각의 실행가능 cmdlet(830-836)은 입력 객체(화살표(841, 843, 845)로 표시됨)로서 입력되는 객체(화살표(840, 842, 844, 846)로 표시됨)를 그 다음 파이프라이닝된 cmdlet으로 출력한다. 이들 객체는 참조(예를 들어, 핸들)를 객체로 전달함으로써 입력될 수 있다. 실행가능 cmdlet(830-836)은 이어서 전달된 객체에 대한 부가의 프로세싱을 수행할 수 있다.

도 9는 커맨드 스트링의 프로세싱을 보다 상세히 나타내는 논리 흐름도이다. 커맨드 스트링 프로세싱은 파서나 스크립트 엔진이 입력 내에서 커맨드 스트링을 식별하는 블록(901)에서 시작한다. 일반적으로, 코어 엔진은 cmdlet의 데이터 흐름의 셋업 및 시퀀싱을 수행한다. 한 cmdlet에 대한 셋업 및 시퀀싱이 이하에 기술되어 있지만, 파이프라인 내의 각 cmdlet에 적용가능하다. 프로세싱은 블록(904)에서 계속된다.

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

블록(906)에서, cmdlet 객체의 인스턴스가 생성된다. cmdlet의 인스턴스를 생성하는 전형적인 프로세스가 도 10을 참조하여 이하에 기술된다. cmdlet 객체가 생성되면, 프로세싱은 블록(908)에서 계속된다.

블록(908)에서, cmdlet 객체와 연관된 속성이 파퓰레이션(populate)된다. 전술한 바와 같이, 개발자는 cmdlet 클래스 내에 또는 외부 소스 내에 속성을 선언한다. 간략히 말하면, 관리 도구 프레임워크는 그 속성에 대해 선언된 이름 및 유형에 기초하여 들어오는 객체(들)를 cmdlet 클래스로부터 인스턴스화된 cmdlet으로 해독한다. 유형이 서로 다른 경우, 그 유형은 강제로 확장 데이터 유형 관리자를 거치도록 할 수 있다. 앞서 언급한 바와 같이, 파이프라이닝된 커맨드 스트링에서, 각 cmdlet의 출력은 객체에 대한 핸들의 리스트일 수 있다. 그 다음 cmdlet은 이 객체 핸들 리스트를 입력하고, 프로세싱을 수행하며, 다른 객체 핸들 리스트를 그 다음 cmdlet으로 전달할 수 있다. 게다가, 도 6에 도시한 바와 같이, 입력 파라미터는 커맨드 라인으로부터 오는 것으로 지정될 수 있다. cmdlet과 연관된 속성을 파퓰레이션하는 한 전형적인 방법은 도 11을 참조하여 이하에 기술된다. cmdlet이 파퓰레이션되면, 프로세싱은 블록(910)에서 계속된다.

블록(910)에서, cmdlet이 실행된다. 요약하면, cmdlet으로의 각각의 입력 객체에 대한 프로세싱을 비롯한 cmdlet에 의해 제공되는 프로세싱은 적어도 한번 수행된다. 따라서, cmdlet이 파이프라이닝된 커맨드 스트링 내의 첫번째 cmdlet인 경우, 프로세싱은 한 번 실행된다. 후속의 cmdlet에 대해, 프로세싱은 cmdlet으로 전달되는 각 객체에 대해 실행된다. cmdlet을 실행하는 한 방법은 도 5를 참조하여 이하에 기술된다. 입력 파라미터가 커맨드 라인으로부터만 오는 경우, cmdlet의 실행은 베이스 cmdlet 케이스(base cmdlet case)에 의해 제공되는 디폴트 메소 드를 사용한다. cmdlet이 실행을 마치면, 프로세싱은 블록(912)으로 진행한다.

블록(912)에서, cmdlet은 마무리된다. 이것은 메모리를 할당 해제(de-allocate)시키는 일 등을 맡고 있는 관련 cmdlet 객체에 대한 소멸자(destructor)를 호출하는 단계를 포함한다. 이어서, 커맨드 스트링의 프로세싱이 완료된다.

전형적인 cmdlet 객체 생성 프로세스

도 10은 도 9에 도시된 커맨드 스트링의 프로세싱 내에서 사용하기에 적합한 cmdlet 객체를 생성하는 전형적인 프로세스를 나타낸 논리 흐름도이다. 현재, cmdlet 데이터 구조가 개발되었고 속성 및 예상 입력 파라미터가 지정되었다. cmdlet은 컴파일되어 등록되어 있다. 등록하는 동안, 클래스 이름(즉, cmdlet 이름)이 등록 스토어에 기입되고, cmdlet와 연관된 메타데이터가 저장되어 있다. 프로세스(1000)는 파서가 cmdlet을 가리키는 입력(예를 들어, 키스트로크)을 수신하는 블록(1001)에서 시작한다. 파서는 레지스트리 내로부터 입력을 검색하고 입력을 등록된 cmdlet 중 하나와 연관시킴으로써 입력을 cmdlet으로서 인식할 수 있다. 프로세싱은 블록(1006)으로 진행한다.

블록(1006)으로 진행하기 전에, cmdlet 객체와 연관된 메타데이터가 판독될 수 있다. 메타데이터는 cmdlet와 연관된 디렉티브 중 임의의 것을 포함한다. 디렉티브는 cmdlet 자체에 또는 파라미터 중 하나 이상에 적용될 수 있다. cmdlet 등록 동안에, 등록 코드는 메타데이터를 영속적 스토어(persistent store)에 등록한다. 메타데이터는 직렬화된 포맷의 XML 파일, 외부 데이터베이스 및 기타 등등에 저장될 수 있다. 각 카테고리의 디렉티브는 서로 다른 단계에서 처리된다. 각 각의 메타데이터 디렉티브는 그 자신의 에러 핸들링을 처리한다.

블록(1006)에서, cmdlet 객체는 식별된 cmdlet 클래스에 기초하여 인스턴스화된다. 프로세싱은 블록(1008)에서 계속된다.

블록(1008)에서, cmdlet에 관한 정보가 획득된다. 이것은 리플렉션 또는 다른 수단을 통해 행해질 수 있다. 그 정보는 예상되는 입력 파라미터들에 관한 것이다. 전술한 바와 같이, public으로 선언된 파라미터들(예를 들어, public string Name(630))은 커맨드 라인 상의 커맨드 스트링에 지정될 수 있거나 입력 스트림으로 제공될 수 있는 예상되는 입력 파라미터들에 대응한다. 관리 도구 프레임워크는 도 13에 나타낸 확장 유형 관리자를 통해 정보를 (필요에 따라) 호출자로 반환하기 위한 공통 인터페이스를 제공한다. 프로세싱은 블록(1010)에서 계속된다.

블록(1010)에서, 적용성 디렉티브(applicability directive)가 적용된다. 적용성 디렉티브는 클래스가 어떤 머신 역할 및/또는 사용자 역할에서 사용되도록 보장한다. 예를 들어, 어떤 cmdlet은 도메인 관리자에 의해서만 사용될 수 있다. 적용성 디렉티브 중 하나에 지정된 제약 요건이 충족되지 않은 경우, 에러가 발생한다. 프로세싱은 블록(1012)에서 계속된다.

블록(1012)에서, 메타데이터가 사용된다. 프로세싱의 이 시점에서, 전체 커맨드 스트링이 아직 입력되지 않았다. 그렇지만, 관리 도구 프레임워크는 이용가능한 cmdlet을 알고 있다. cmdlet이 결정되었으면, 관리 도구 프레임워크는 cmdlet 객체를 살펴봄으로써 허용되는 입력 파라미터를 알게 된다. 따라서, 관리 도구 프레임워크는 cmdlet 이름의 확실한 부분(disambiguating portion)이 제공되면 cmdlet을 자동 완성할 수 있고 이어서 입력 파라미터의 확실한 부분이 커맨드 라인 상에 타이핑되었으면 입력 파라미터를 자동 완성할 수 있다. 입력 파라미터의 일부분이 입력 파라미터들 중 하나를 확실하게 식별할 수 있자마자 자동 완성은 일어날 수 있다. 게다가, 자동 완성은 cmdlet 이름 및 피연산자에 대해서도 역시 일어날 수 있다. 프로세싱은 블록(1014)에서 계속된다.

블록(1014)에서, 프로세스는 cmdlet에 대한 입력 파라미터가 입력될 때까지 기다린다. 이것은 사용자가 리턴 키를 치는 등에 의해 커맨드 스트링의 끝을 표시하면 일어난다. 스크립트에서는, 개행 문자(new line)가 커맨드 스트링의 끝을 나타낸다. 이 대기 단계는 파라미터에 관하여 사용자로부터 부가의 정보를 획득하는 단계 및 다른 디렉티브를 적용하는 단계를 포함할 수 있다. cmdlet가 파이프라이닝된 파라미터들 중 하나일 때, 프로세싱은 즉각 시작할 수 있다. 필요한 커맨드 스트링 및 입력 파라미터가 제공되었으면, 프로세싱은 완료된다.

cmdlet를 파퓰레이션하는 전형적인 프로세스

cmdlet를 파퓰레이션하는 전형적인 프로세스가 도 11에 예시되어 있으며 이제부터 도 5를 참조하여 기술된다. 한 관리 도구 프레임워크에서, 코어 엔진은 cmdlet에 대한 파라미터를 파퓰레이션하기 위해 이 프로세싱을 수행한다. 프로세싱은 cmdlet의 인스턴스가 생성된 후에 블록(1101)에서 시작한다. 프로세싱은 블록(1102)으로 계속된다.

블록(1102)에서, cmdlet 내에서 선언된 파라미터(예를 들어, ProcessName)가 검색된다. cmdlet에서의 선언에 기초하여, 코어 엔진은 들어오는 입력 객체가 "ProcessName"라는 이름의 속성을 제공할 것임을 알고 있다. 들어오는 속성의 유형이 파라미터 선언에 지정된 유형과 다른 경우, 그 유형은 확장 유형 관리자를 강제로 통과하게 된다. 데이터 유형을 강제로 변환하는 프로세스는 이하에서 "전형적인 확장 유형 관리자 프로세싱"이란 제목의 서브섹션에서 설명된다. 프로세싱은 블록(1103)으로 계속된다.

블록(1103)에서, 파라미터와 연관된 속성이 획득된다. 속성은 파라미터에 대한 입력 소스가 커맨드 라인인지 파이프라인으로부터 온 것인지를 식별해준다. 프로세싱은 판정 블록(1104)으로 계속된다.

판정 블록(1104)에서, 속성이 입력 소스를 커맨드 라인으로 지정하고 있는지 여부의 판정이 행해진다. 입력 소스가 커맨드 라인인 경우, 프로세싱은 블록(1109)에서 계속된다. 그렇지 않은 경우, 프로세싱은 판정 블록(1105)에서 계속된다.

판정 블록(1105)에서, 선언에서 지정된 속성 이름이 사용되어야 하는지 속성 이름에 대한 매핑이 사용되어야 하는지의 판정이 행해진다. 이 판정은 커맨드 입력이 파라미터에 대한 매핑을 지정하였는지 여부에 기초한다. 이하의 라인은 파라미터 "ProcessName"를 들어오는 객체의 "foo" 멤버로 매핑하는 것의 전형적인 예를 나타낸 것이다.

$get-process|where{$_.hcount -gt 500}|stop-process-ProcessName<-foo.

프로세싱은 블록(1106)에서 계속된다.

블록(1106)에서, 그 매핑이 적용된다. 매핑은 예상 파라미터의 이름을 "ProcessName"에서 "foo"로 대체시키며, 이 "foo"는 이어서 코어 엔진이 들어오는 객체를 파싱하고 정확한 예상 파라미터를 식별하는 데 사용된다. 프로세싱은 블록(1108)에서 계속된다.

블록(1108)에서, 확장 유형 관리자는 들어오는 객체 내의 파라미터에 대한 값을 찾아내도록 질의를 받는다. 확장 유형 관리자와 연계하여 설명하는 바와 같이, 확장 유형 관리자는 파라미터 이름을 받아서 파라미터 이름으로 들어오는 객체 내의 파라미터를 확인하기 위해 리플렉션을 사용한다. 확장 유형 관리자는 또한 필요한 경우 그 파라미터에 대해 다른 프로세싱을 수행할 수 있다. 예를 들어, 확장 유형 관리자는 전술한 변환 메커니즘을 통해 데이터의 유형을 예상된 데이터 유형으로 강제로 변환할 수 있다. 프로세싱은 판정 블록(1110)으로 계속된다.

다시 블록(1109)을 참조하면, 입력 소스가 커맨드 라인인 것으로 속성이 지정하고 있는 경우, 커맨드 라인으로부터 데이터가 획득된다. 커맨드 라인으로부터 데이터를 획득하는 것은 확장 유형 관리자를 통해 수행될 수 있다. 이어서, 프로세싱은 판정 블록(1110)으로 계속된다.

판정 블록(1110)에서, 또다른 예상 파라미터가 있는지 여부의 판정이 행해진다. 또다른 예상 파라미터가 있는 경우, 프로세싱은 블록(1102)으로 루프백하고 전술한 바와 같이 진행된다. 그렇지 않은 경우, 프로세싱은 완료되고 복귀한다.

따라서, 도시한 바와 같이, cmdlet은 예상 파라미터를 획득하기 위해 들어오는 데이터를 쉬레딩(shredding)하는 템플릿으로서 기능한다. 게다가, 예상 파라미 터는 예상 파라미터에 대한 값을 제공하는 들어오는 객체의 유형을 모른 상태에서 획득된다. 이것은 종래의 관리 환경과 아주 다르다. 종래의 관리 환경들은 밀접하게 바인딩되어 있고 객체의 유형을 컴파일 시에 알고 있어야만 한다. 게다가, 종래의 환경에서는, 예상 파라미터가 함수에 값(value)으로서 또는 참조(reference)로서 전달되었다. 따라서, 본 발명의 파싱(예를 들어, "쉬레딩") 메커니즘은 프로그래머가 이들 파라미터에 대한 값들을 어떻게 획득할지 구체적으로 알 필요없이 파라미터의 유형을 지정할 수 있게 해준다.

예를 들어, cmdlet Foo에 대한 이하의 선언이 주어진 경우,

class Foo: Cmdlet

{

string Name;

Bool Recurse;

}

커맨드 라인 신택스는 이하의 것 중 임의의 것일 수 있다.

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

$ Foo -Name <string> -Recurse: True

$ Foo -Name(string).

일련의 규칙들이 원하는 신택스를 생성하기 위해 시스템 관리자에 의해 수정될 수 있다. 게다가, 파서는 다수의 규칙 세트를 지원할 수 있으며, 따라서 2개 이상의 신택스가 사용자에 의해 사용될 수 있다. 기본적으로, cmdlet 구조(예를 들어, string Name 및 Bool Recurse)와 연관된 문법이 파서를 작동시킨다.

일반적으로, 파싱 디렉티브는 커맨드 스트링으로서 입력된 파라미터가 어떻게 cmdlet 객체 내의 식별된 예상 파라미터로 매핑되어야 하는지를 기술한다. 입력 파라미터 유형이 올바른지 여부를 판정하기 위해 검사된다. 입력 파라미터 유형이 올바르지 않은 경우, 입력 파라미터는 올바른 것으로 강제로 변환될 수 있다. 입력 파라미터 유형이 올바르지 않고 또 강제로 변환될 수도 없는 경우, 사용법 에러(usage error)가 인쇄된다. 사용법 에러는 사용자가 예상되는 올바른 신택스를 알 수 있도록 해준다. 사용법 에러는 문서화 디렉티브로부터 신택스를 기술하는 정보를 획득할 수 있다. 입력 파라미터 유형이 매핑되었거나 검증되었으면, cmdlet 객체 인스턴스 내의 대응하는 멤버가 파퓰레이션 된다. 멤버가 파퓰레이션 될 때, 확장 유형 관리자는 입력 파라미터 유형의 프로세싱을 제공한다. 간략히 말하면, 프로세싱은 속성 경로(property path) 메커니즘, 키(key) 메커니즘, 비교(compare) 메커니즘, 변환(conversion) 메커니즘, 글로버(globber) 메커니즘, 관계(relationship) 메커니즘 및 속성 세트(property set) 메커니즘을 포함할 수 있다. 이들 메커니즘 각각은 이하에서 예시적인 예들을 역시 포함하고 있는 "확장 유형 관리자 프로세싱"이라는 제목의 섹션에서 상세히 기술된다.

cmdlet을 실행하는 전형적인 프로세스

cmdlet을 실행하는 전형적인 프로세스가 도 12에 예시되어 있으며, 이제부터 기술된다. 한 전형적인 관리 도구 환경에서, 코어 엔진은 cmdlet을 실행한다. 전술한 바와 같이, 제2 메소드(540) 내의 코드(542)는 각각의 입력 객체에 대해 실행 된다. 프로세싱은 cmdlet이 이미 파퓰레이션되어 있는 블록(1201)에서 시작한다. 프로세싱은 블록(1202)에서 계속된다.

블록(1202)에서, 실행을 위해 코드(542)로부터의 문장(statement)이 검색된다. 프로세싱은 블록(1206)에서 계속된다.

블록(1206)에서, 그 문장이 처리된다. 이어서, 프로세싱은 판정 블록(1208)으로 진행한다. 블록(1208)에서, 그 코드가 또다른 문장을 포함하는지 여부의 판정이 행해진다. 또다른 문장이 있는 경우, 프로세싱은 그 다음 문장을 가져오기 위해 블록(1202)으로 루프백하고, 전술한 바와 같이 진행된다. 그렇지 않은 경우, 프로세싱은 판정 블록(1214)으로 계속된다.

판정 블록(1214)에서, 처리할 또다른 입력 객체가 있는지 여부의 판정이 행해진다. 또다른 입력 객체가 있는 경우, 프로세싱은 cmdlet이 그 다음 객체로부터의 데이터로 파퓰레이션되는 블록(1216)으로 계속된다. 도 10에서 설명된 파퓰레이션 프로세스는 그 다음 객체에 대해 수행된다. 이어서, 프로세싱은 블록(1202)으로 루프백하고 전술한 바와 같이 진행된다. 모든 객체들이 처리되었으면, cmdlet을 실행하기 위한 프로세스가 완료되고 복귀한다.

전형적인 확장 유형 관리자 프로세싱

도 13과 연계하여 간략히 전술한 바와 같이, 확장 유형 관리자는 제공되는 객체들에 대해 부가의 프로세싱을 수행할 수 있다. 부가의 프로세싱은 파서(220), 스크립트 엔진(222) 또는 파이프라인 프로세서(402)의 요청으로 수행될 수 있다. 부가의 프로세싱은 속성 경로 메커니즘, 키 메커니즘, 비교 메커니즘, 변환 메커니 즘, 글로버 메커니즘, 관계 메커니즘 및 속성 세트 메커니즘을 포함한다. 당업자라면 확장 유형 관리자도 역시 청구된 발명의 범위를 벗어나지 않고 다른 프로세싱으로 확장될 수 있음을 잘 알 것이다. 이제부터, 부가의 프로세싱 메커니즘 각각에 대해 기술한다.

먼저, 속성 경로 메커니즘은 스트링이 객체의 속성들을 내비게이션할 수 있게 해준다. 현재의 리플렉션 시스템에서, 질의는 객체의 속성들을 조사할 수 있다. 그렇지만, 본 발명의 확장 유형 관리자에서, 객체의 연속적인 속성로의 내비게이션 경로를 제공하는 스트링이 지정될 수 있다. 이하는 속성 경로에 대한 예시적인 신택스이다.

A.B.C.D.

각 컴포넌트(예를 들어, A, B, C, D)는 속성, 파라미터를 갖는 메소드, 파라미터를 갖지 않는 메소드, 필드, XPATH, 기타 등등을 나타낼 수 있는 스트링을 포함한다. XPATH는 엘리먼트를 검색하는 질의 스트링을 지정한다(예를 들어, "/FOO@=13"). 스트링 내에, 컴포넌트의 유형을 구체적으로 나타내기 위해 특수 문자가 포함될 수 있다. 스트링이 특수 문자를 포함하지 않는 경우, 확장 유형 관리자는 컴포넌트의 유형을 판정하기 위해 검색을 수행할 수 있다. 예를 들어, 컴포넌트 A가 객체인 경우, 확장 유형 관리자는 B가 객체의 속성인지, 객체에 대한 메소드인지, 객체의 필드인지 또는 속성 세트인지를 조사할 수 있다. 확장 유형 관리자가 B에 대한 유형을 식별하면, 그 유형에 따른 프로세싱이 수행된다. 컴포넌트가 상기 유형 중 하나가 아닌 경우, 확장 유형 관리자는 유형 A를 유형 B로 변환 하기 위한 변환 함수가 있는지 여부를 판정하기 위해 확장 소스를 추가로 조사할 수 있다. 이제부터, 예시적인 커맨드 스트링을 사용하여 개별적인 출력을 보여주면서 이들 및 다른 검색에 대해 기술할 것이다.

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

$ get-process | where {$_.handlecount -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를 통해 파이프라이닝된 들어오는 객체의 직접 속성(direct property)라는 것이다. 3개의 속성 경로 각각에 대해 관여된 프로세싱에 대해 이제부터 기술한다.

첫번째 속성 경로(즉, "name.toupper")에서, name은 들어오는 객체의 직접 속성이고 또한 객체 그 자체이다. 확장 유형 관리자는 toupper에 대한 유형을 결정하기 위해 상기한 우선순위 검색을 사용하여 시스템에 질의한다. 확장 유형 관리자는 toupper가 속성가 아님을 발견한다. 그렇지만, toupper는 스트링 유형이 스트링 내에서 소문자를 대문자로 변환하기 위해 상속받은 메소드일 수 있다. 다른 대안으로서, 확장 유형 관리자는 name 객체를 대문자로 변환할 수 있는 써드 파티 코드가 있는지 여부를 판정하기 위해 확장 메타데이터를 조사할 수 있다. 컴포 넌트 유형을 찾으면, 그 컴포넌트 유형에 따라 프로세싱이 수행된다.

두번째 속성 경로(즉, "ws.kb")에서, "ws"는 들어오는 객체의 직접 속성이고 역시 객체 그 자체이다. 확장 유형 관리자는 "ws"가 정수인지를 판정한다. 그 다음에, 확장 유형 관리자는 kb가 정수의 속성인지, kb가 정수의 메소드인지를 조사하고, 마지막으로 임의의 코드가 어떻게 정수를 받아서 그 정수를 정수에서 kb 유형으로 변환하는지를 알고 있는지를 조사한다. 써드 파티 코드는 이러한 변환을 수행하기 위해 등록되고, 그 변환이 수행된다.

세번째 속성 경로(즉, "exe*.ver*.description.tolower.trunc(30)")에, 몇개의 컴포넌트가 있다. 첫번째 컴포넌트("exe*")는 들어오는 객체의 직접 속성이고, 역시 객체이다. 다시 말하면, 확장 유형 관리자는 두번째 컴포넌트("ver*")를 처리하기 위해 검색 쿼리를 따라 아래로 진행한다. "exe*" 객체는 "ver*" 속성 또는 메소드를 갖지 않으며, 따라서 확장 유형 관리자는 실행가능 이름을 버전으로 변환하기 위해 등록되어 있는 어떤 코드가 있는지를 판정하기 위해 확장 메타데이터를 조사한다. 이 예에서, 이러한 코드가 존재한다. 이 코드는 실행가능 이름 스트링을 받고 이를 사용하여 파일을 연 다음에, 버전 블록 객체에 액세스하고 버전 블록 객체의 설명 속성(세번째 컴포넌트("description"))를 반환한다. 확장 유형 관리자는 이어서 네번째 컴포넌트("toupper") 및 다섯번째 컴포넌트("trunc(40)")에 대해 이 동일한 검색 메커니즘을 수행한다. 따라서, 예시된 바와 같이, 시스템 관리자가 임의의 특정 코드를 작성할 필요없이, 확장 유형 관리자는 커맨드 스트링에 대해 아주 정교한 프로세싱을 수행할 수 있다. 표 1은 예시적인 스트링에 대해 생 성된 출력을 나타낸 것이다.

Name.toupper	ws.kb	exe.ver.description.tolower.trunc(30)
ETCLIENT CSRSS SVCHOST OUTLOOK MSMSGS	29,964 6,944 28,944 18,556 13,248	etclient generic host process for win32 office outlook messenger

또하나의 질의 메커니즘(1324)은 키를 포함한다. 이 키는 그 데이터 유형의 인스턴스를 고유한 것으로 만들어주는 하나 이상의 속성을 식별해준다. 예를 들어, 데이터베이스에서, 각 컬럼(column)은 각 로우(row)를 일의적으로 식별해줄 수 있는 키로서 식별될 수 있다(예를 들어, 사회 보장 번호). 이 키는 그 데이터 유형과 연관된 유형 메타데이터(1340) 내에 저장될 수 있다. 이 키는 이어서 그 데이터 유형의 객체들을 처리할 때 확장 유형 관리자에 의해 사용될 수 있다. 데이터 유형은 확장 데이터 유형 또는 기존의 데이터 유형일 수 있다.

또하나의 질의 메커니즘(1324)은 비교 메커니즘을 포함한다. 간략히 말하면, 도 14 내지 도 23와 연계하여 이하에 상세히 기술되어 있는 바와 같이, 비교 메커니즘은 2개의 객체를 비교한다. 2개의 객체가 비교 함수를 직접 지원하는 경우, 직접 지원되는 비교 함수가 실행된다. 그렇지만, 어느 객체도 비교 함수를 지원하지 않는 경우, 확장 유형 관리자는 2개의 객체 간의 비교를 지원하기 위해 등록된 코드의 유형 메타데이터를 살펴볼 수 있다. 비교 메커니즘을 호출하는 예시적인 일련의 커맨드 라인 스트링이 이하에 나타내어져 있으며, 대응하는 출력은 표 2에 있다.

$ $a = $( get-date )

$ start-sleep 5

$ $b = $( get-date )

$ compare-time $a $b

Ticks Days Hours Miliseconds Minutes Seconds TotalDays TotalHours TotalMiliseconds TotalMinutes TotalSeconds

51196579 0 0 119 0 5 5.92552997685185E-05 0.00142212719444444 5119.6579 0.0853276316666667 5.1196579

compare-time cmdlet은 2개의 datetime 객체를 비교하기 위해 작성된 것이다. 이 경우, DateTime 객체는 IComparable 인터페이스를 지원한다.

또하나의 질의 메커니즘(1324)은 변환 메커니즘을 포함한다. 확장 유형 관리자는 특정 변환을 수행할 수 있음을 나타내는 코드가 등록될 수 있게 해준다. 그러면, 유형 A의 객체가 입력되고 cmdlet이 유형 B의 객체를 지정하고 있는 경우, 확장 유형 관리자는 등록된 변환들 중 하나를 사용하여 그 변환을 수행할 수 있다. 확장 유형 관리자는 유형 A를 강제로 유형 B로 만들기 위해 일련의 변환을 수행할 수 있다. 전술한 속성 경로("ws.kb")는 변환 메커니즘을 나타낸다.

또하나의 질의 메커니즘(1324)은 글로버 메커니즘을 포함한다. 글로버(globber)란 스트링 내의 와일드 카드 문자를 말한다. 글로버 메커니즘은 와일드 카드 문자를 갖는 스트링을 입력하고 일단의 객체를 생성한다. 확장 유형 관리자는 와일드카드 프로세싱을 지정하는 코드가 등록될 수 있게 해준다. 상기한 속성 경로("exe*.ver*.description.tolower.trunc(30)")는 글로버 메커니즘을 나타낸다. 등록된 프로세스는 파일 이름, 파일 객체, 들어오는 속성 등에 대한 글로빙(globbing)을 제공할 수 있다.

또하나의 질의 메커니즘(1324)은 속성 세트 메커니즘을 포함한다. 속성 세트 메커니즘은 일련의 속성에 대한 이름이 정의될 수 있게 해준다. 그러면, 관리자는 일련의 속성을 획득하기 위해 커맨드 스트링 내에 그 이름을 지정할 수 있다. 속성 세트는 여러가지 방식으로 정의될 수 있다. 한 방식에서, "?" 등의 소정의 파라미터가 cmdlet에 대한 입력 파라미터로서 입력될 수 있다. 오퍼레이팅 환경은 이 소정의 파라미터를 인식할 때 들어오는 객체의 모든 속성을 열거한다. 리스트는 관리자가 원하는 속성을 용이하게 검사(예를 들어 "클릭 온(click on)")하고 속성 세트를 지명할 수 있게 해주는 GUI일 수 있다. 속성 세트 정보는 이어서 확장 메타데이터에 저장된다. 속성 세트 메커니즘을 호출하는 예시적인 스트링이 이하에 나타내어져 있으며, 대응하는 출력은 표 3에 있다.

$ get-process | where {$_.handlecount -gt 500} | format-table config.

이 예시적인 스트링에서, "config"라는 이름의 속성 세트는 이름 속성, 프로세스 id 속성(Pid) 및 우선순위 속성을 포함하도록 정의되어 있다. 그 테이블에 대한 출력은 이하에 나타내었다.

이름	Pid	우선순위
ETClient csrss svchost OUTLOOK msmsgs	3528 528 848 2,722 2,584	보통 보통 보통 보통 보통

또하나의 질의 메커니즘(1324)은 관계 메커니즘을 포함한다. 하나의 관계(즉, 상속)를 지원하는 종래의 유형 시스템과는 달리, 관계 메커니즘은 유형들 간에 2개 이상의 관계를 표현하는 것을 지원한다. 다시 말하면, 이들 관계는 등록된다. 관계는 객체가 사용하는 항목을 찾아내는 것 또는 그 객체를 사용하는 항목을 찾아내는 것을 포함할 수 있다. 확장 유형 관리자는 여러가지 관계를 기술하는 분류 체계(ontology)에 액세스할 수 있다. 확장 메타데이터 및 코드를 사용하여, OWL, DAWL 등과 같은 임의의 분류 체계 서비스에 액세스하기 위한 규격이 기술될 수 있다. 이하는 관계 메커니즘 .OWL:"string"을 이용하는 예시적인 스트링의 일부분이다.

"OWL" 식별자는 분류 체계 서비스를 식별해주고, "string"은 분류 체계 서비스 내의 특정의 스트링을 식별해준다. 따라서, 확장 유형 관리자는 분류 체계 서비스에 의해 제공된 유형들에 액세스할 수 있다.

섹션 3: 전형적인 비교 기술

도 14 내지 도 23은 상기 섹션 2에서 기술한 객체 기반 관리 도구 프레임워크 내에서 동작하는 본 발명의 비교 기술의 전형적인 실시예들을 나타낸 것이다. 본 발명의 비교 기술은 현재의 비교 기술보다 몇가지 이점을 제공한다. 예를 들어, 본 발명의 비교 기술은 서로 다른 데이터 유형의 객체가 서로 비교될 수 있게 해준다. 게다가, 이 비교 기술의 결과는 문제를 궁극적으로 해결할 수 있는 다른 동작으로의 입력으로서 자동적으로 사용될 수 있다. 이들 및 다른 이점은 이하의 상세한 설명을 읽어보면 명백하게 될 것이다.

도 14는 도 2에 도시한 객체 기반 관리 프레임워크 내에 구현된 비교 cmdlet에 대한 전형적인 신택스의 실시예를 나타낸 것이다. 첫번째 신택스(1400)는 도 16에 도시한 흐름도에 예시되고 동 도면과 관련하여 기술된 키 기반 비교에 대응한다. 두번째 신택스(1401)은 도 17에 도시한 흐름도에 예시되고 동 도면을 참조하여 기술된 순서 기반 비교에 대응한다. 이 2가지 비교 기술을 구분하기 위해, compare-object cmdlet이 호출될 때 KeyBased 파라미터(1406) 또는 OrderBased 파라미터(1408) 중 어느 하나가 커맨드 스트링에 포함된다. KeyBased 파라미터(1406)는 스위치(예를 들어, "-KeyBased") 및 키 이름(key-name)을 포함한다. 키 이름은 어느 객체가 비교되는지를 식별해준다. 그러면, 그 키 이름과 연관된 속성을 갖는 객체만이 그 비교에 포함된다. 키 이름은 단일 속성 또는 속성 세트일 수 있다.

첫번째 신택스(1400) 및 두번째 신택스(1401) 둘다는 다른 파라미터들을 포함한다. 일반적으로, 그 파라미터들 대부분은 스위치 및 데이터를 포함한다. 스위치란 compare-object cmdlet를 호출할 때 커맨드 스트링 내에 나타나는 소정의 텍스트를 말한다. 데이터는 스위치에 의존한다. 예를 들어, 어떤 스위치들은 부울 데이터와 연관될 수 있다. 다른 스위치들은 속성와 연관될 수 있다. 그 스위치들 중 일부는 그와 연관된 데이터를 갖는 커맨드 스트링에 포함되지 않을 수 있다. 이러한 일이 있는 경우, 커맨드 스트링에 입력된 데이터는 순서 의존적이거나 비교 cmdlet의 정의 내의 입력 파라미터들에 대해 지정된 임의의 속성에 적어도 의존할 수 있다. 이제부터, 이들 다른 파라미터들 각각에 대해 개별적으로 기술한다.

ReferenceObject 파라미터(1402)는 "-ReferenceObject" 스위치 및 참조 객체를 포함한다. 참조 객체는 다른 객체들과 비교되어질 하나 이상의 객체를 식별해준다.

ComparisonObject 파라미터(1404)는 "-ComparisonObject" 스위치 및 비교 객체를 포함한다. 비교 객체는 참조 객체와 비교되는 하나 이상의 객체를 식별해준다. 곧이어 기술되는 바와 같이, 비교 객체는 객체 기반 파이프라인으로부터 제공될 수 있다.

따라서, 참조 객체는 표준으로서 사용되어 임의의 수의 비교 객체들과 비교될 수 있다. 예를 들어, 참조 객체는 컴퓨팅 장치의 표준 구성일 수 있으며, 각각의 비교 객체는 시스템 관리자가 표준 구성과 유사하게 구성하고자 할 수 있는 다른 컴퓨팅 장치에 대응할 수 있다.

Property 파라미터(1410)는 "-Property" 스위치 및 속성 이름을 포함한다. 속성 이름은 하나 이상의 속성을 열거할 수 있거나 속성 세트를 열거할 수 있다. Property 파라미터(1410)는 객체 내의 모든 속성을 비교하는 것이 아니라 특정 속성들이 비교될 수 있게 해준다. 이와 같이 특정 속성을 지정할 수 있는 것은 보고되는 사소한 차이점의 수를 최소화시킨다. 예를 들어, 프로세스 A가 현재 동작하고 있지 않지만(이후부터, 오늘 프로세스 A라고 함) 어제는 동작하고 있었던 경우(이후부터, 어제 프로세스 A라고 함), Property 파라미터(1410)는 오늘 프로세스(Today Process) A와 어제 프로세스(Yesterday Process) A 간에 서로 다른 것으로 알고 있는 속성들(예를 들어, CPU 시간, 작업 세트)이 비교에 포함되지 않도록 할 수 있다. 따라서, 본 발명의 비교 기술의 출력은 실패한 이유를 판정하는 데 도움이 되는 유익한 정보를 더 많이 제공한다.

CaseSensitive 파라미터(1412)는 "-CaseSensitive" 스위치 및 "False" 또는 "True"를 가리키기 위한 선택적인 부울 값을 포함한다. "-CaseSentive" 스위치가 "False" 값과 함께 포함되어 있는 경우, 참조 객체 및 비교 객체 내의 스트링의 대소문자를 구별하지 않는다. 이와 반대로, "True" 값이 지정되어 있는 경우, 차이점을 판정함에 있어서 스트링의 대소문자를 구별한다. CaseSensitive 파라미터(1412)는 참조 객체 및 비교 객체가 스트링 유형일 경우 이용될 수 있다. 다른 데이터 유형에 대해서는, CaseSensitive 파라미터(1412)는 무시될 수 있다.

Culture 파라미터(1414)는 "-Culture" 스위치 및 culture-setting 값을 포함한다. 지정되어 있는 culture-setting 값은 현재의 culture setting을 오버라이드한다. 참조 객체 및 비교 객체 둘다는 동일한 컬처를 갖는 것으로 취급된다. Culture 파라미터(1414)는 참조 객체 및 비교 객체가 스트링 유형일 때 이용될 수 있으며 동일한 언어를 사용하여 텍스트의 비교가 수행되도록 보장한다. 다른 데이터 유형에 대해서는, Culture 파라미터(1414)는 무시될 수 있다.

IgnoreWhiteSpace 파라미터(1416)는 "-IgnoreWhiteSpace" 스위치 및 선택적인 부울 값을 포함한다. 부울 값이 "false"일 때, 비교 동안 공백은 텍스트의 일부로서 간주된다. 이와 반대로, 부울 값이 "true"인 경우, 비교 동안 텍스트 내의 공백은 무시된다. IgnoreWhiteSpace 파라미터(1416)는 참조 객체 및 비교 객체가 스트링 유형일 때 이용될 수 있다. 다른 데이터 유형에 대해서는, IgnoreWhiteSpace 파라미터(1416)는 무시될 수 있다.

RecordDifference 파라미터(1418)는 "-RecordDifference" 스위치 및 선택적인 부울 값을 포함한다. 부울 값이 "false"인 경우, 참조 객체와 비교 객체 간의 차이점은 출력으로 보내지지 않는다. 이와 반대로, 부울 값이 "true"인 경우, 차이점이 출력으로 보내진다.

RecordEqual 파라미터(1420)는 "-RecordEqual" 스위치 및 선택적인 부울 값을 포함한다. 부울 값이 "false"인 경우, 동일한 값을 갖는 참조 객체 및 비교 객체의 속성들은 출력으로 보내지지 않는다. 부울 값이 "true"인 경우, 동일한 값을 갖는 참조 객체 및 비교 객체의 속성들이 출력으로 보내진다.

PassThru 파라미터(1422)는 "-PassThru" 스위치 및 선택적인 부울 값을 포함한다. 부울 값이 "false"인 경우, 비교는 키 이름, 속성 값, 동등 표시자 및 방향 표시자(sideindicator)를 출력한다. 방향 표시자는 출력이 참조 객체와 연관되어 있는지 출력이 비교 객체와 연관되어 있는지를 도식적으로 표시한다. 예를 들어, 좌측 방향 표시자 "<="는 그 다음에 오는 정보가 참조 객체로부터 온 것임을 나타낸다. 우측 방향 표시자 "=>"는 그 다음에 오는 정보가 비교 객체로부터 온 것임을 나타낸다. 동등 표시자 "=="는 비교 객체와 참조 객체가 동일한 값을 가짐을 나타낸다. 부울 값이 "true"인 경우, 참조 객체 및 비교 객체 둘다는 주석이 붙여져 출력된다. 유의할 점은 본 발명의 비교 기술의 범위를 벗어나지 않고 여러가지 문자 및/또는 그래픽이 방향 표시자에 사용될 수 있다는 것이다.

도 15는 비교 cmdlet를 호출하는 커맨드 스트링을 예시하고 또 생성된 출력을 예시하는 어떤 예들을 제공한다. 이들 예(1510, 1520) 둘다는 테이블 1502 및 테이블 1504에 나타낸 예시적인 정보에 기초한다. 테이블(1502, 1504) 둘다는 2개의 로우와 2개의 컬럼, Process Name 및 Handlecount를 갖는다. 첫번째 로우는 Process Name에 대해 "MSH"를 갖는 프로세스에 대응하고, 두번째 로우는 Process Name에 대해 "Calc"를 갖는 프로세스에 대응한다. 테이블(1502)에서, MSH에 대한 Handlecount는 100이고 Calc에 대한 Handlecount는 100이다. 테이블(1504)에서, MSH에 대한 Handlecount는 여전히 100이고 Calc에 대한 Handlecount는 500이다. 예로서, 테이블(1504) 내의 정보는 테이블(1502) 내의 정보보다 10초 후에 생성된 것으로 가정한다.

첫번째 예(1510)에서, 커맨드 "$a = get-process"가 커맨드 라인 상에 입력된다. 앞서 설명한 바와 같이, 객체 기반 관리 프레임워크가 이 커맨드를 만날 때, get-process cmdlet로부터 생성된 정보(예를 들어, 테이블(1502))는 객체 a에 할당된다. 10초 후에, 이하의 커맨드가 입력된다.

compare-object -ReferenceObject $a

-ComparisonObject $(get-process)

-KeyBased Name

-Property Handlecount.

객체 기반 관리 프레임워크가 상기 커맨드를 만날 때, 참조 객체는 테이블(1502) 내의 정보와 연관된 객체 "a"이다. 비교 객체는 테이블(1504) 내의 정보를생성한 get-process cmdlet로부터 생성된 객체이다. KeyBased 파라미터(1406)는 커맨드 스트링에 포함되어 "ProcessName"라는 이름의 속성을 갖는 객체에 대해 KeyBased 비교를 수행하도록 신호한다. 커맨드 스트링은 또한 "Handlecount"를 비교할 속성로서 식별하는 Property 파라미터(1410)를 포함한다. 따라서, ProcessName 속성을 갖는 각각의 비교 객체에 대해, Handlecount 속성은 참조 객체 내의 Handlecount 속성와 비교된다. 그러면, 출력(1512)은 MSH 프로세스 이름이 참조 객체 내에 동일한 정보를 가짐을 나타낸다. 출력(1512)은 또한 Calc 프로세스 이름이 참조 객체 및 비교 객체 내에 서로 다른 정보를 가짐을 나타낸다.

예(1520)에서, 첫번째 커맨드는 예(1510)에서와 동일하지만, 두번째 커맨드는 다음과 같다.

compare-object -ReferenceObject $a

-ComparisonObject $(get-process)

-KeyBased Name

-Property Handlecount

-RecordDifference:false

-RecordEqual

따라서, 예(1520)는 RecordDifference 스위치 및 RecordEqual 스위치를 포함한다. RecordDifference 스위치는 false로 설정될 수 있고 RecordEqual 스위치는 true로 설정될 수 있다. 앞서 설명한 바와 같이, 이들 스위치의 경우, 출력(1522)은 참조 객체나 비교 객체 중 어느 하나와 연관된 Calc 프로세스에 대한 handlecount를 열거하지 않는데, 그 이유는 RecordEqual 파라미터가 동일한 속성만을 출력하도록 지정하기 때문이다.

예(1510, 1520)는 compare-object cmdlet의 동작을 예시하고 있지만, 당업자라면 유용한 정보를 획득하기 위해 여러가지 스위치 및 다른 cmdlet을 사용하여 임의의 수의 커맨드 스트링이 작성될 수 있음을 잘 알 것이다. 게다가, 섹션 2에서 전술한 바와 같이, 한 cmdlet의 결과는 다른 cmdlet들로 파이프라이닝될 수 있다. 따라서, compare-object cmdlet이 각각의 객체 및 그의 차이점을 식별해주는 차이점 레코드를 생성하고, 이 차이점 레코드는 다른 cmdlet에 의해 추가로 처리될 수 있다. 이들 다른 cmdlet은 필터링, 보고, 데이터베이스 채우기(filling a database) 또는 차이점 레코드에 열거된 차이점들을 해결하는 제어 루프 등의 프로세싱을 제공할 수 있다. 차이점 레코드를 제어 루프로 파이프라이닝할 수 있는 것이 본 발명의 비교 기술의 유용성을 크게 향상시킨다.

게다가, 이 비교 기술은 최초의 참조 객체 및 최초의 비교 객체의 전체 시맨틱스가 출력 객체에서 이용가능하게 되도록 이들 객체를 캡슐화하는 하나 이상의 출력 객체를 생성할 수 있다. 이 실시예에서, 차이점 레코드에 기록된 정보는 최초의 참조 객체에 주석으로서 부가될 수 있다. 확장 유형 관리자는 이 주석 첨부를 수행할 수 있다. 출력 객체는 참조 객체 및 비교 객체, 차이점을 갖는 객체들, 일치하는 객체들, 기타 등등의 각각을 포함하도록 구성될 수 있다. 본 발명의 비교 기술이 출력 객체를 생성하고 또 최초의 객체의 일부분을 캡슐화할 수 있기 때문에, 최초의 객체들은 한 일련의 속성에 기초하여 먼저 비교될 수 있으며, 이어서 나중에 첫번째 일련의 속성로부터의 속성 어느 것도 포함하지 않을 수 있는 또는 그의 일부분을 포함할 수 있는 다른 일련의 속성에 기초하여 처리될 수 있다. 게다가, 차이점 표시자 주석 첨부는 후속 프로세싱이 그 자신의 필요에 기초하여 그 자신의 일련의 속성을 선택할 수 있게 해준다. 최초의 객체를 캡슐화하는 객체를 출력함으로써 제공되는 다른 이점은 최초의 객체에 의해 제시되는 질의 및 제어 메소드가 출력 객체에 대해 호출될 수 있다는 것이다. 이제부터, 도 16 내지 도 23의 흐름도와 연계하여 비교 기술의 동작에 대해 기술한다.

도 16은 키 기반 비교 프로세스를 수행하는 전형적인 프로세스를 예시한 논리 흐름도이다. 이 프로세스는 블록(1601)에서 시작하여 블록(1602)으로 계속된다.

블록(1602)에서, 참조 객체가 검색된다. 참조 객체란 비교 프로세스 동안 다른 객체들과 비교되는 객체를 말한다. 프로세싱은 판정 블록(1604)에서 계속된다.

판정 블록(1604)에서, 참조 객체가 KeyBased 파라미터로 지정된 key-name과 연관된 속성을 포함하는지 여부의 판정이 행해진다. 다수의 키가 있는 경우, 참조 객체는 다수의 키들 각각과 연관된 속성을 포함한다. 참조 객체가 지정된 속성을 포함하지 않는 경우, 프로세싱은 판정 블록(1610)에서 계속된다. 추가적인 세분에서, 블록(1610)으로 진행하기 전에, 참조 객체는 커맨드로 지정된 파라미터들에 기초하여 생성되어질 리스트에 부가될 수 있다. 그렇지 않은 경우, 프로세싱은 판정 블록(1606)에서 계속된다.

판정 블록(1606)에서, 참조 객체가 키에 대해 동일한 값을 갖는 참조 세트 내에 이미 존재하는지 여부를 판정하기 위해 참조 세트(reference set)가 검토된다. 이러한 참조 객체가 존재하는 경우, 프로세싱은 판정 블록(1610)에서 계속된다. 그렇지 않은 경우, 프로세싱은 블록(1608)에서 계속된다.

블록(1608)에서, 참조 객체는 참조 세트에 부가된다. 이어서, 프로세싱은 판정 블록(1610)에서 계속된다.

판정 블록(1610)에서, 비교 프로세스에서 사용할 또다른 참조 객체가 있는지 여부의 판정이 행해진다. 또다른 참조 객체가 있는 경우, 프로세싱은 블록(1602)으로 루프백하고, 전술한 바와 같이 계속된다. 그렇지 않은 경우, 지정된 키 또는 키들을 포함하는 모든 참조 객체들은 참조 세트에 부가된다. 프로세싱은 블록(1612)에서 계속된다.

블록(1612)에서, 참조 세트 내의 각각의 참조 객체 및 각각의 이용가능한 비교 객체를 사용하여 비교가 수행된다. 간략히 말하면, 도 21과 연계하여 이하에 상세히 기술되는 바와 같이, Property 파라미터로 지정된 각각의 속성가 참조 객체와 각각의 비교 객체 간에 비교된다. 이 비교가 수행된 후에, 프로세싱은 완료된다.

도 21은 도 16의 블록(1612)에서 사용하기에 적합한 참조 객체와 각각의 비교 객체를 비교하는 전형적인 프로세스를 예시하는 흐름도이다. 프로세스(2100)는 블록(2101)에서 시작하여 블록(2102)으로 진행한다.

블록(2102)에서, 비교 객체가 획득된다. 전술한 바와 같이, 다수의 비교 객체가 있을 수 있다. 따라서, 각각의 비교 객체는 참조 객체에 대해 비교되어야만 하는지를 알아보기 위해 검사된다. 프로세싱은 판정 블록(2104)에서 계속된다.

판정 블록(2104)에서, 비교 객체가 key-name와 연관된 속성을 갖는지 여부의 판정이 행해진다. 다수의 키가 사용될 수 있음에 유의하는 것이 중요하다. 다수의 키가 있는 경우, 참조 객체 및 비교 객체 둘다는 다수의 키와 연관된 속성들을 가지고 있어야만 한다. 비교 객체가 key-name과 연관된 속성을 갖지 않는 경우, 프로세싱은 비교 객체가 분실 리스트에 부가되는 판정 블록(2116)으로 계속되고, 프로세싱은 이하에 기술되는 판정 블록(2118)에서 계속된다. 블록(2104)에서의 판정 결과 비교 객체가 key-name과 연관된 속성을 갖는 경우, 프로세싱은 판정 블록(2106)에서 계속된다.

판정 블록(2106)에서, 비교 객체가 키 값을 갖는 첫번째 비교 객체인지 여부의 판정이 행해진다. 첫번째 비교 객체가 아닌 경우, 프로세싱은 또한 판정 블록(2118)에서 계속된다. 그렇지 않은 경우, 프로세싱은 판정 블록(2108)에서 계속된다.

판정 블록(2108)에서, 참조 객체가 동일한 키 값을 갖는 참조 세트 내에 존재하는지 여부의 판정이 행해진다. 이러한 참조 객체가 존재하지 않는 경우, 프로세싱은 비교 전용(comparison only) 레코드가 생성되는 블록(2114)에서 계속된다. 비교 전용 레코드는 특정 키를 갖는 비교 객체가 존재하지만 유사한 참조 객체는 존재하지 않음을 나타낸다. 전술한 바와 같이, 컴퓨팅 장치를 표준 구성에 비교할 때, 이 정보는 잠재적인 구성 문제를 알려주기 위해 유용하다. 비교 전용 레코드가 생성된 후에, 프로세싱은 다시 판정 블록(2118)에서 계속된다. 그렇지만, 판정 블록(2108)의 결과가 참조 객체가 존재하는 것으로 결론내린 경우, 프로세싱은 블록(2110)에서 계속된다.

블록(2110)에서, 참조 객체 및 비교 객체의 속성 값이 비교된다. 간략히 말하면, 도 22와 관련하여 이하에 상세히 기술하는 바와 같이, 이 비교는 지정된 각각의 속성을 비교한다. 따라서, 앞서 설명한 바와 같이, 각각의 속성을 비교할 필요없이 관심있는 속성만이 비교된다. 속성 값이 비교된 후에, 프로세싱은 블록(2112)에서 계속된다.

블록(2112)에서, 참조 객체는 참조 세트로부터 제거된다. 참조 객체는 이 시점에서 제거될 수 있는 이유는 블록(2106)이 비교 객체가 이미 처리된 다른 비교 객체와 중복되는지 여부를 검사하기 때문이다. 참조 객체를 제거하는 것은 나중에 결과를 생성할 때 열거(enumeration)를 용이하게 해준다. 따라서, 모든 비교 객체가 검색되고 비교된 후에, 참조 세트에 여전히 어떤 참조 객체라도 존재하는 경우, 이것은 차이점을 나타낸다. 프로세싱은 판정 블록(2118)에서 계속된다.

판정 블록(2118)에서, 또다른 비교가 프로세싱을 위해 이용가능한지 여부의 판정이 행해진다. 또다른 비교 객체가 있는 경우, 프로세싱은 블록(2102)으로 루프백하고 상기한 바와 같이 계속된다. 그렇지만, 모든 비교 객체가 처리되었으면, 프로세싱은 블록(2120)에서 계속된다.

블록(2120)에서, 비교의 나머지 결과가 생성된다. 간략히 말하면, 도 23과 관련하여 이하에 상세히 기술하는 바와 같이, 생성된 결과는 비교 명령과 연계하여 지정된 스위치들에 기초한다. 이어서, 프로세싱이 완료된다.

도 22는 도 21에 사용하기 적합한 참조 객체와 비교 객체 간에 속성을 비교하는 전형적인 프로세스를 예시한 흐름도이다. 프로세스는 블록(2201)에서 시작하여 블록(2202)으로 진행한다.

블록(2202)에서, 비교 객체 내의 지정된 속성 중 하나가 참조 객체 내의 대응하는 속성와 비교된다. 참조 객체 및 비교 객체의 데이터 유형이 반드시 동일할 필요가 없다는 것에 유의하는 것이 중요하다. 데이터 유형이 서로 다른 경우, 객체 기반 관리 프레임워크의 확장 데이터 관리자는 서로 다른 데이터 유형을 인식하고 유사한 데이터 유형이 비교되도록 이들을 변환한다. 따라서, 비교 객체는 참조 객체의 데이터 유형으로 변환될 수 있다. 이와 반대로, 참조 객체가 비교 객체의 데이터 유형으로 변환될 수 있다. 게다가, 각각의 지정된 속성은 비교를 수행하기 위해 개별적으로 변환될 수 있다. 따라서, 본 발명의 비교 기술은 서로 다른 유형의 객체들을 비교할 수 있다. 이 비교 기술은 참조 객체를 역시 가상 객체로서 취급되는 것인 비교 객체와 비교될 수 있는 가상 객체로서 취급한다.

또한, 참조 객체 및 비교 객체 내의 속성들에 대한 "값들"이 에러를 보고하기 전에 에러 허용 범위(margin of error) 내에 있을 수 있도록 비교가 퍼지 비교(fuzzy comparison)를 포함할 수 있음에 유의하는 것이 중요하다. 예를 들어, 에러 허용 범위가 1M 바이트로 설정되어 있는 경우, 10MB 및 12MB의 값은 차이점이 있다. 그렇지만, 10.5MB와 11MB의 값들은 차이점이 없다. 이 퍼지 비교는 신호 대 잡음비를 향상시킨다. 따라서, 퍼지 비교를 구현하는 비교 기술은 보다 양호하고 더욱 적절한 차이점 검출을 제공한다.

퍼지 비교는 "-compare-object colorCompare -ReferenceObject $a -ComparisonObject $b" 등의 커맨드 스트링의 일부로서 제공되는 커스텀 비교기(custom comparer)를 사용하여 구현될 수 있다. 이 특정의 예에서, colorCompare는 "이끼색(moss green)"과 "세이지색(sage)"이 동일하게 보고되도록 서로 다른 색상을 저장하는 텍스트 스트링을 비교할 수 있다. 따라서, 커스텀 비교기는 서로 다른 객체들 간의 비교를 수행하기 위해 많은 유연성을 허용한다. 지정된 속성가 비교되면, 프로세싱은 판정 블록(2204)에서 계속된다. 판정 블록(2204)에서, 비교 객체 내의 속성의 값이 참조 객체 내의 속성의 값과 같은지 여부의 판정이 행해진다. 값들이 똑같지 않은 경우, 프로세싱은 지정된 속성와 관련하여 비교 객체와 참조 객체 간의 차이점을 나타내는 차이점 레코드가 생성될 수 있는 블록(2210)에서 계속된다. 이 차이점 레코드는 비교 커맨드에서 지정된 파라미터에 의존한다. 프로세싱은 판정 블록(2212)에서 계속된다. 그렇지만, 비교 객체 및 참조 객체 내의 속성의 값이 같은 경우, 프로세싱은 판정 블록(2206)에서 계속된다.

판정 블록(2206)에서, 비교 커맨드의 호출이 똑같은 객체를 출력하도록 지정하였는지 여부의 판정이 행해진다. 전술한 바와 같이, 이것이 달성될 수 있는 한가지 방식은 도 14에 도시한 RecordEqual 파라미터(1420)를 이용하는 것이다. 똑같은 객체가 출력에 포함되지 않은 경우, 프로세싱은 판정 블록(2212)에서 계속된다. 그렇지 않은 경우, 프로세싱은 블록(2208)에서 계속된다.

블록(2208)에서, 비교 객체에 대한 동등 레코드(equality record)가 생성된다. 동등 레코드는 비교 객체에 대한 값 및 속성을 나타낸다. 프로세싱은 판정 블록(2212)에서 계속된다.

판정 블록(2212)에서, 비교될 필요가 있는 또다른 지정된 속성가 있는지 여부의 판정이 행해진다. 또다른 속성가 있는 경우, 프로세싱은 블록(2202)으로 루프백되어 전술한 바와 같이 계속된다. 그렇지 않은 경우, 프로세싱은 완료되어 종료된다.

도 23은 도 21에서 사용하기에 적합한 결과를 생성하는 전형적인 프로세스를 예시한 흐름도이다. 프로세싱(2300)은 블록(2301)에서 시작하여 블록(2302)으로 진행한다.

블록(2302)에서, 참조 세트 내의 객체들은 열거(enumerate)되고, "참조 전용" 레코드(reference only record)가 생성된다. 따라서, 이것은 대응하는 비교 객체를 갖지 않은 참조 객체를 출력한다. 프로세싱은 판정 블록(2304)에서 계속된다.

판정 블록(2304)에서, 분실 리스트(missing list) 내에서 식별된 객체들이 출력되어야만 하는지 여부의 판정이 행해진다. 분실 키 객체(missing key object)가 출력되어서는 안되는 경우, 프로세싱이 완료된다. 그렇지 않은 경우, 프로세싱은 블록(2306)에서 계속된다.

블록(2306)에서, 분실 리스트 내에서 식별된 참조 객체들이 생성된다. 이어서, 프로세싱은 완료되어 복귀된다.

도 17은 순서 기반 비교 프로세스를 수행하는 전형적인 프로세스르르 예시한 논리 흐름도이다. 어떤 관리 업무의 경우, 순서 기반 비교가 키 기반 비교보다 선호된다. 예를 들어, 액세스 제어 리스트(access control list, ACL)를 비교할 때 순서 기반 비교가 선호된다. ACL이 사용자의 퍼미션 및 액세스 권리를 나타내기 때문에, 이들 권리를 분석하는 순서가 중요하다. 프로세싱은 블록(1701)에서 시작하여 블록(1702)으로 계속된다.

블록(1702)에서, 참조 객체가 획득된다. 프로세싱은 비교 객체가 획득되는 블록(1704)에서 계속된다. 전술한 바와 같이, 참조 객체 및 비교 객체에 대한 데이터 유형은 동일할 필요가 없다. 확장 유형 관리자는 비교가 행해질 수 있기 전에 수행될 필요가 있는 임의의 변환을 처리한다. 프로세싱은 판정 블록(1706)에서 계속된다.

판정 블록(1706)에서, 참조 객체 및 비교 객체의 데이터 유형이 텍스트인지 여부의 판정이 행해진다. 데이터 유형이 텍스트(예를 들어, 스트링, 파일)가 아닌 경우, 프로세싱은 블록(1708)에서 계속된다.

블록(1708)에서, 참조 객체 및 비교 객체의 속성들에 대해 비교가 수행된다. 간략히 말하면, 도 18과 연계하여 이하에 상세히 기술하는 바와 같이, 참조객체 및 비교 객체의 속성들이 값 및/또는 순서에서 서로 다를 때, 객체의 비교는 차이점을 보고한다. 프로세싱은 판정 블록(1706)에서 계속된다.

판정 블록(1706)에서, 또다른 비교 객체가 있는지 여부의 판정이 행해진다. 있는 경우, 프로세싱은 블록(1704)으로 루프백하여 전술한 바와 같이 진행한다. 그렇지 않은 경우, 프로세싱은 완료된다.

판정 블록(1706)으로 되돌아가서, 참조 객체 및 비교 객체의 데이터 유형이 텍스트인 경우, 프로세싱은 블록(1708)으로 계속된다.

블록(1708)에서, 참조 객체와 비교 객체 간에 텍스트 비교가 수행된다. 간략히 말하면, 도 19와 관련하여 이하에 상세히 기술하는 바와 같이, 텍스트 비교는 현재 이용가능한 표준 텍스트 기반 비교 기술과 유사하게 동작한다. 프로세싱은 또한 판정 블록(1706)으로 계속되어 전술한 바와 같이 진행한다. 도 17이 다수의 참조 객체를 예시하고 있지 않지만, 당업자라면 다수의 참조 객체에 대처하기 위해 또다른 판정 블록이 구현될 수 있음을 잘 알 것이다.

도 18은 도 17에 도시한 순서 기반 비교 프로세스 내에서 사용하기 적합한 순서 기반 객체 비교 프로세스를 예시한 논리 흐름도이다. 프로세싱은 블록(1801)에서 시작하여 블록(1802)으로 진행한다.

블록(1802)에서, 참조 객체로부터의 속성가 획득된다. 이 비교는 순서 의존적이기 때문에, 일반적으로 속성들은 순차적으로 획득된다. 프로세싱은 블록(1804)에서 계속된다.

블록(1804)에서, 비교 객체로부터의 속성가 획득된다. 비교 객체 내의 속성들이 획득되는 순서는 참조 객체 내의 속성을 획득하는 순서와 동일한 순서로 일어난다. 프로세싱은 판정 블록(1806)으로 계속된다.

판정 블록(1806)에서, 참조 속성 및 비교 속성가 비교가능한지 여부의 판정이 행해진다. 먼저, 프로세스는 참조 속성의 이름이 비교 속성의 이름과 동일한지를 확인한다. 이것은 리플렉션을 사용하여 수행될 수 있다. 리플렉션 이외에, 본 발명의 비교 기술은 도 13에 예시한 확장 유형 시스템과 관련하여 앞서 설명한 속성 엘리어싱(property aliasing)을 제공한다. 따라서, 속성 엘리어싱을 사용함으로써, 참조 객체 및 비교 객체 내의 서로 다른 속성 이름들은 비교 동안 동등한 것으로 취급될 수 있다.

예를 들어, 어떤 객체들은 프로세스의 이름과 연관된 속성을 식별하기 위해 속성 이름 "ProcessName"을 사용할 수 있다. 다른 객체들은 프로세스의 이름과 연관된 속성을 식별하기 위해 속성 이름 "Name"을 사용할 수 있다. "Name"과 "ProcessName"을 엘리어싱함으로써, 이들 2개의 서로 다른 객체의 속성은 비교 동안 동일한 것으로 취급된다.

확장 유형 시스템이 속성들 중 하나에 대한 데이터 유형을 강제로 다른 속성에 대한 데이터 유형과 동일하게 되도록 할 수 있음에 유의하는 것이 중요하다. 예를 들어, 참조 속성가 정수 데이터 유형이고 비교 속성가 스트링 데이터 유형인 경우, 도 13과 관련하여 전술한 바와 같이, 확장 유형 관리자는 스트링을 강제로 정수가 되게 할 수 있다. 이것은 서로 다른 데이터 유형으로 인한 차이점이 에러를 발생하게 되는 엄격한 객체 비교와 대조적이다. 속성들이 서로 즉각 비교가능하지 않은 경우, 프로세싱은 블록(1808)에서 계속된다.

블록(1808)에서, 2개의 속성가 비교될 수 있게 하기 위해 필요한 변환이 수행된다. 전술한 바와 같이, 이것은 데이터 유형을 강제로 변환하는 것 등을 포함할 수 있다. 속성가 비교가능하게 되면, 프로세싱은 블록(1810)으로 계속된다.

블록(1810)에서, 2개의 속성가 비교된다. 전술한 바와 같이, 비교는 커스텀 비교 메커니즘을 이용하여 퍼지 비교 등을 수행할 수 있다. 2개의 속성가 비교되면, 프로세싱은 블록(1812)으로 계속된다.

블록(1812)에서, 커맨드 스트링에 제공된 스위치에 기초하여 차이점이 보고된다. 차이점은 값 및/또는 속성의 순서에서의 차이점을 포함할 수 있다. 프로세싱은 판정 블록(1814)에서 계속된다.

판정 블록(1814)에서, 비교한 또다른 속성가 있는지 여부의 판정이 행해진다. 객체의 순서 기반 비교의 경우, 속성의 값 및/또는 속성의순서 간의 어떤 차이점이라도 식별해내는 것이 중요하다. 또다른 속성가 있는 경우, 프로세싱은 블록(1802)으로 루프백하여 전술한 바와 같이 진행한다. 그렇지 않은 경우, 프로세싱은 완료된다.

도 19는 도 17에 도시한 순서 기반 비교 프로세스 내에서 사용하기 적합한 텍스트 비교 프로세스를 예시한 논리 흐름도이다. 프로세싱은 블록(1901)에서 시작하여 블록(1908)으로 진행한다.

블록(1908)에서, 차이점이 식별될 때까지 또는 텍스트의 끝에 도달할 때까지 텍스트가 비교된다. 텍스트 비교는 블록(1908) 동안 공지의 텍스트 비교 기술을 이용할 수 있다. 차이점이 검출되거나 끝이 검출되면, 프로세싱은 판정 블록(1910)으로 계속된다.

블록(1910)에서, 텍스트의 끝에 도달되었는지 여부의 판정이 행해진다. 끝에 도달된 경우, 프로세싱은 블록(1918)으로 계속된다. 그렇지 않은 경우, 프로세싱은 블록(1912)로 계속된다.

블록(1912)에서, 차이점을 가져오는 텍스트를 찾는 검색이 수행된다. 이 검색은 참조 객체 또는 비교 객체와 연관된 텍스트에서 수행될 수 있다. 검색은 텍스트가 발견될 때까지 또는 지정된 싱크 윈도우(sync window)가 완료될 때까지 수행된다. 싱크 윈도우의 사용은 당업자에게는 공지된 것으로서 추가로 설명할 필요가 없다. 프로세싱은 판정 블록(1914)로 계속된다.

판정 블록(1914)에서, 검색 동안에 텍스트가 발견되었는지 여부의 판정이 행해진다. 텍스트가 발견된 경우, 프로세싱은 참조 객체 또는 비교 객체 내의 부가된 텍스트를 주석을 첨부하는 등에 의해 차이점 레코드가 갱신되는 블록(1916)으로 계속된다. 이어서, 프로세싱은 블록(1908)으로 루프백되어 전술한 바와 같이 진행한다.

판정 블록(1914)에서 텍스트가 발견되지 않은 경우, 프로세싱은 차이점 레코드가 비교로부터의 결과로 갱신되는 블록(1918)으로 계속된다. 이어서, 프로세싱이 완료된다.

도 20은 compare cmdlet에 대한 또다른 전형적인 신택스를 예시한 것이다. 신택스(2000)는 람다식(lambda expression)을 지원한다. 개요로서, 람다식은 본 발명의 비교 기술이 참조 객체 및/또는 비교 객체의 속성로부터 도출되지만 객체 자체 상에 존재하지는 않는 키 및 값에 기초하여 2개의 객체 세트를 비교할 수 있게 해준다. 따라서, 확장 유형 시스템은 단순히 값을 반환하는 것이 아니라 오히려 필요한 값을 획득하기 위해 프로세싱이 수행될 수 있게 해준다.

신택스(2000)는 도 14와 관련하여 상기한 파라미터들 대부분을 포함한다. 게다가, 신택스(2000)는 이하의 파라미터들, ReferenceKey 파라미터(2002), ComparisonKey 파라미터(2004), ReferenceValue 파라미터(2006) 및 ComparisonValue 파라미터(2008) 중 하나 이상을 포함할 수 있다. 다시 말하면, 이들 파라미터는 스위치를 포함하고, 또 그 스위치와 연관된 값을 포함할 수 있다.

ReferenceKey 파라미터(2002)는 "-ReferenceValue" 스위치 및 reference-key 객체를 포함한다. reference-key 객체는 각각의 참조 객체에 대한 키를 계산하는 임의의 함수, 스크립트, 람다식, 등(이후부터 총괄하여 람다식이라 함)일 수 있다. 이와 유사하게, ComparisonKey 파라미터(2004)는 "-ComparisonKey" 스위치 및 comparison-key 객체를 포함하며, 여기서 comparison-key 객체는 각각의 비교 객체에 대한 키를 계산하는 람다식일 수 있다.

ReferenceValue 파라미터(2006)는 "-ReferenceValue" 스위치 및 reference-value 객체를 포함한다. reference-value 객체는 각각의 참조 객체에 대한 값을 계산하는 람다식일 수 있다. 이와 유사하게, ComparisonValue 파라미터(2008)는 "-ComparisonValue" 스위치 및 comparison-value 객체를 포함한다. comparison-value 객체는 각각의 참조 객체에 대한 값을 계산하는 람다식일 수 있다.

람다식의 사용은 예에 의해 가장 잘 이해될 수 있다. 따라서, 커맨드 스트링이 상기 속성(2002-2008)에 대한 람다식을 포함하는 것으로 가정하자. 게다가, 각각의 람다식이 대응하는 객체의 속성에 기초하여 데이터베이스 검색을 수행하는 것으로 가정하자. 예를 들어, ReferenceKey 파라미터(2002)와 연관된 reference-key 람다식은 속성 A에 대한 데이터베이스 검색의 결과를 반환할 수 있다. ComparisonKey 파라미터(2004)와 연관된 comparison-key 람다식은 속성 B에 대한 데이터베이스 검색의 결과를 반환할 수 있다. 의사 코드에서, reference-key 람다식은 "{$db.fetch($_.A)}"와 같이 나타날 수 있으며, 여기서 $db는 데이터베이스 객체를 말하고, .fetch($_.A)는 확장 유형 관리자를 사용하여 입력 세트 내의 단일 참조 객체로부터 fetch 메소드를 통해 속성 A를 검색하는 것을 말한다. 이와 유사하게, comparison-key 람다식에 대한 의사 코드는 "{$db.fetch($_.B)}"와 같이 나타날 수 있다.

따라서, 도 16 내지 도 19 및 도 23과 관련하여 전술한 프로세싱 동안에, 키가 획득되고 평가될 때마다, 대응하는 키 람다식이 적용된다. 키 동일에 대한 테스트는 전술한 것과 동일한 규칙을 이용한다. 그렇지만, 키들간의 실제 비교를 수행하는 또다른 람다식이 지정될 수 있다.

이어서, 일치하는 키를 갖는 각각의 참조 객체 및 비교 객체에 대해, compare cmdlet은 대응하는 값 람다 표현식을 적용한다. 예를 들어, reference-value 람다식이 "{$db.fetch($_.C)}"이고, comparison-value 람다식이 "{$db.fetch($_.D)}"인 경우, compare-cmdlet은 "{$db.fetch($R.C)}"의 결과를 "{$db.fetch($C.D)}"의 결과와 비교하며, 여기서 $R은 참조 객체이고 $C는 비교 객체이다. 다시 말하면, 비교는 선택적인 값 비교 람다식을 수행하는 단계를 포함하는 전술한 비교 프로세스를 이용할 수 있다.

람다식을 지원하는 또다른 실시예에서, 참조 객체 및 비교 객체는 람다식으로부터의 계산된 키 및 값이 출력 객체 상에 주석으로서 부가되도록 필터링될 수 있다. 본 발명의 비교 기술을 지원하는 람다식을 지정하기 위한 이들 및 다른 변형예는 에러를 식별할 때 많은 융통성을 제공한다.

따라서, 각각의 참조 객체에 대한 키 함수가 호환가능한 결과를 생성하고 각각의 참조 객체에 대한 값 함수가 호환가능한 결과를 생성하는 한, 람다식을 사용함으로써, 서로 다른 객체 유형을 갖지만 공통 속성은 갖지 않는 참조 객체가 비교될 수 있다. 게다가, 외부 시스템 기능들(예를 들어, 데이터베이스 검색)을 호출할 수 있는 각각의 객체에 대해 사용된 키 또는 값 함수는 아주 복잡한 계산일 수 있으며 원격 시스템으로부터 데이터를 검색하기 위해 네트워크 동작을 수행할 수 있다. 추가의 기술 혁신에서, 키 또는 값 함수는 서로 다른 이름을 사용하는 시맨틱적으로 동일한 속성의 비교를 가능하게 해주는 엘리어싱 기능을 제공할 수 있다.

람다식이 지정될 때 생성되는 출력 객체는 계산된 키 및 계산된 값을 생성된 객체의 일부로서 또는 패스-쓰루 모드(pass-through mode)에서 최초의 객체에 대한 주석으로서 포함할 수 있다. 이것은 생성된 출력이 계산된 값을 사용하여 추가로 처리될 수 있게 해준다. 또다른 기술 혁신에서, 키 함수는 입력 데이터로부터 배제되어야만 하는 데이터에 대해서는 널(null)을 반환하도록 동작할 수 있다.

람다식을 적용함으로써, 비교는 패스-쓰루 모드에서 수행되는 한 비교의 출력을 다른 비교로의 입력으로서 사용하여 다수의 입력 세트에 걸쳐 행해질 수 있다. 이것이 행해질 때, 객체의 소스를 나타내는 속성의 이름 또는 값이 변화될 수 있다. 이것은 임의의 그룹의 입력 세트들 간의 차이점을 추적할 수 있게 해준다. 다른 변형예에서, 비교는 다수의 입력 세트를 단일 스트림으로 결합함으로써 다수의 입력 세트에 걸쳐 행해질 수 있다.

특정의 구현예 및 실시예의 상세에 대해 지금까지 기술하였지만, 이러한 상세는 이하의 청구항들의 범위를 제한하려는 것이 아니라 법적 개시 요건을 충족시키기 위한 것이다. 따라서, 청구항들에 의해 정의된 본 발명은 상기 기술된 구체적인 특징으로 한정되는 것이 아니다. 오히려, 첨부된 청구항들의 해당 범위 내에 속하는 임의의 형태 또는 변형례도 본 발명의 청구 대상이며, 균등론에 따라 적절히 해석되어야만 한다.

Claims

참조 객체를 획득하는 단계;

적어도 하나의 비교 객체를 획득하는 단계; 및

객체 기반 환경에서 커맨드 스트링 내에 지정된 적어도 하나의 파라미터에 기초하여 상기 참조 객체와 상기 적어도 하나의 비교 객체 간의 비교를 수행하는 단계를 포함하는 방법을 수행하는 컴퓨터 실행가능 명령어들을 갖는 적어도 하나의 컴퓨터 판독가능 매체.
제1항에 있어서, 상기 적어도 하나의 비교 객체는 상기 객체 기반 환경에서 실행되는 cmdlet로부터 생성되는 것인 컴퓨터 판독가능 매체.
제1항에 있어서, 상기 적어도 하나의 파라미터는 키 기반 스위치(key-based switch) 및 키 워드(key-word)를 포함하고,

상기 비교는 상기 참조 객체 및 상기 비교 객체가 상기 키 워드와 연관된 속성을 포함하는 것을 확인한 후에 수행되는 것인 컴퓨터 판독가능 매체.
제3항에 있어서, 상기 적어도 하나의 파라미터는 키 기반 스위치 및 키 워드를 포함하고,

상기 키 워드는 상기 커맨드 스트링 상의 표현식을 지정하고, 상기 표현식은 상기 참조 객체와 연관된 참조 키를 생성하며,

상기 비교는 상기 비교 객체와 연관된 비교 키와 상기 참조 키가 일치하는 것을 확인한 후에 수행되는 것인 컴퓨터 판독가능 매체.
제1항에 있어서, 상기 적어도 하나의 파라미터는 속성 스위치 및 적어도 하나의 속성을 포함하고,

상기 비교는 상기 적어도 하나의 속성에 대해서만 수행되는 것인 컴퓨터 판독가능 매체.
제1항에 있어서, 상기 적어도 하나의 파라미터는 순서 스위치(order switch)를 포함하고,

상기 비교는 순서 기반 방식으로 수행되는 것인 컴퓨터 판독가능 매체.
제6항에 있어서, 상기 참조 객체 및 상기 적어도 하나의 비교 객체는 텍스트 데이터 유형을 포함하고,

상기 비교는 텍스트 비교를 포함하는 것인 컴퓨터 판독가능 매체.
제7항에 있어서, 상기 적어도 하나의 파라미터는 대소문자 구별 스위치(case-sensitive switch)를 더 포함하고,

상기 텍스트 비교는 대소문자를 구별하는 것인 컴퓨터 판독가능 매체.
제7항에 있어서, 상기 적어도 하나의 파라미터는 공백 스위치(white space switch)를 더 포함하고,

상기 텍스트 비교는 상기 참조 객체와 상기 비교 객체를 비교할 때 공백을 배제시키는 것인 컴퓨터 판독가능 매체.
제6항에 있어서, 상기 참조 객체 및 상기 적어도 하나의 비교 객체는 비텍스트 데이터 유형(non-textual data type)을 포함하며,

상기 비교는 상기 참조 객체의 속성의 참조값을 상기 비교 객체의 대응하는 속성의 비교값과 비교하는 것인 컴퓨터 판독가능 매체.
제1항에 있어서, 상기 방법은 상기 적어도 하나의 파라미터 및 상기 비교에 기초하여 출력 레코드를 생성하는 단계를 더 포함하는 것인 컴퓨터 판독가능 매체.
제11항에 있어서, 상기 출력 레코드는 상기 참조 객체와 상기 비교 객체 간의 차이점을 포함하는 것인 컴퓨터 판독가능 매체.
제11항에 있어서, 상기 출력 레코드는 상기 참조 객체를 캡슐화하고,

상기 비교 동안에 식별된 차이점은 상기 출력 레코드에 주석으로서 부가되는 것인 컴퓨터 판독가능 매체.
제11항에 있어서, 상기 출력 레코드는 상기 비교 객체를 캡슐화하고,

상기 비교 동안에 식별된 차이점은 상기 출력 레코드에 주석으로서 부가되는 것인 컴퓨터 판독가능 매체.
제1항에 있어서, 상기 비교는 상기 커맨드 스트링 내에 표현식으로서 지정되어 있는 커스텀 비교(custom comparison)를 포함하는 것인 컴퓨터 판독가능 매체.
제1항에 있어서, 상기 참조 객체의 참조값은 상기 커맨드 스트링에 지정된 표현식에 의해 생성되고, 상기 참조값은 상기 비교 동안에 상기 비교 객체와 연관된 비교값과 비교되는 것인 컴퓨터 판독가능 매체.
제1항에 있어서, 상기 비교 객체의 비교값은 상기 커맨드 스트링에 지정된 표현식에 의해 생성되고, 상기 비교값은 상기 비교 동안에 상기 참조 객체와 연관된 참조값과 비교되는 것인 컴퓨터 판독가능 매체.
제1항에 있어서, 상기 참조 객체는 제1 데이터 유형이고 상기 비교 객체는 제2 데이터 유형이며,

상기 데이터 유형들 중 적어도 하나는 상기 비교를 수행하기 전에 상기 참조 객체 및 상기 비교 객체가 동일한 데이터 유형을 갖도록 강제로 변환되는 것인 컴 퓨터 판독가능 매체.
컴퓨터 실행가능 명령어들을 갖는 컴퓨터 판독가능 매체로서,

상기 명령어들은,

객체 기반 환경에서 커맨드 스트링 내의 비교 cmdlet를 식별하는 단계;

상기 커맨드 스트링 내의 참조 객체 규격에 기초하여 참조 객체를 획득하는 단계;

상기 커맨드 스트링 내의 비교 객체 규격에 기초하여 비교 객체를 획득하는 단계; 및

상기 참조 객체와 상기 비교 객체 간의 비교를 수행하는 단계

를 포함하는 것인 컴퓨터 판독가능 매체.
제19항에 있어서, 상기 비교의 결과로서 차이점 레코드(difference record)를 생성하는 단계를 더 포함하는 컴퓨터 판독가능 매체.
제20항에 있어서, 상기 차이점 레코드는 상기 비교 cmdlet으로부터 파이프라이닝되는 다른 cmdlet으로의 입력으로서 제공되는 것인 컴퓨터 판독가능 매체.
제19항에 있어서, 상기 커맨드 스트링 내의 표현식을 획득하는 단계를 더 포함하며, 상기 표현식은 상기 참조 객체와 상기 비교 객체 간에 수행할 비교를 식별 해주는 것인 컴퓨터 판독가능 매체.
제19항에 있어서, 상기 커맨드 스트링 내의 표현식을 획득하는 단계를 더 포함하며, 상기 표현식은 상기 비교가 수행되기 위해 필요한 상기 참조 객체의 속성을 식별해주는 키 워드를 생성하는 것인 컴퓨터 판독가능 매체.
제19항에 있어서, 상기 커맨드 스트링 내의 표현식을 획득하는 단계를 더 포함하며, 상기 표현식은 상기 참조 객체에 대한 참조값을 생성하고, 상기 참조값은 상기 비교 동안에 상기 비교 객체와 연관된 비교값과 비교되는 것인 컴퓨터 판독가능 매체.
제19항에 있어서, 지정된 속성들을 획득하는 단계를 더 포함하고, 상기 지정된 속성들은 상기 비교를 수행할 때 비교되는 상기 참조 객체 및 상기 비교 객체의 특정의 속성들을 식별해주는 것인 컴퓨터 판독가능 매체.
제19항에 있어서, 상기 비교는 순서 기반 방식으로 수행되는 것인 컴퓨터 판독가능 매체.
제19항에 있어서, 상기 참조 객체는 제1 데이터 유형이고 상기 비교 객체는 제2 데이터 유형이며,

상기 참조 객체는 상기 비교 전에 상기 제2 데이터 유형으로 강제로 변환되는 것인 컴퓨터 판독가능 매체.
제19항에 있어서, 상기 참조 객체는 제1 데이터 유형이고 상기 비교 객체는 제2 데이터 유형이며,

상기 비교 객체는 상기 비교 전에 상기 제1 데이터 유형으로 강제로 변환되는 것인 컴퓨터 판독가능 매체.
제19항에 있어서, 상기 참조 객체는 제1 데이터 유형이고 상기 비교 객체는 제2 데이터 유형이며,

상기 참조 객체 및 상기 비교 객체는 상기 비교 전에 동일한 데이터 유형을 갖도록 강제로 변환되는 것인 컴퓨터 판독가능 매체.
프로세서; 및

복수의 명령어가 로드되는 메모리를 포함하며,

상기 복수의 명령어는,

참조 객체를 획득하는 단계;

적어도 하나의 비교 객체를 획득하는 단계; 및

객체 기반 환경에서 커맨드 스트링 내에 지정된 적어도 하나의 파라미터에 기초하여 상기 참조 객체와 상기 적어도 하나의 비교 객체 간의 비교를 수행하는 단계를 포함하는 방법을 수행하는 것인 시스템.
제30항에 있어서, 상기 적어도 하나의 비교 객체는 상기 객체 기반 환경에서 실행되는 cmdlet으로부터 생성되는 것인 시스템.
제30항에 있어서, 상기 비교는, 상기 참조 객체 및 상기 비교 객체가 상기 커맨드 스트링 상에 지정된 키 워드와 연관된 속성을 포함하는 것을 확인한 후에 수행되는 것인 시스템.
제30항에 있어서, 상기 적어도 하나의 파라미터는 속성 스위치 및 적어도 하나의 속성을 포함하고,

상기 비교는 상기 참조 객체 및 상기 비교 객체 내의 적어도 하나의 속성에 대해서만 수행되는 것인 시스템.
제30항에 있어서, 상기 적어도 하나의 파라미터는 순서 스위치를 포함하고,

상기 비교는 순서 기반 방식으로 수행되는 것인 시스템.
제30항에 있어서, 상기 방법은 상기 적어도 하나의 파라미터 및 상기 비교에 기초하여 출력 레코드를 생성하는 단계를 더 포함하는 시스템.
제34항에 있어서, 상기 출력 레코드는 상기 참조 객체와 상기 비교 객체 간의 차이점을 포함하는 것인 시스템.
제35항에 있어서, 상기 출력 레코드는 상기 참조 객체를 캡슐화하고,

상기 비교 동안에 식별된 차이점은 상기 출력 레코드에 주석으로서 부가되는 것인 시스템.
제30항에 있어서, 상기 비교는 상기 커맨드 스트링 내에 표현식으로서 지정되어 있는 커스텀 비교를 포함하는 것인 시스템.
제30항에 있어서, 상기 참조 객체의 참조값은 상기 커맨드 스트링 내에 지정되어 있는 표현식에 의해 생성되고, 상기 참조값은 상기 비교 동안에 상기 비교 객체와 연관된 비교값과 비교되는 것인 시스템.
제30항에 있어서, 상기 참조 객체는 제1 데이터 유형이고 상기 비교 객체는 제2 데이터 유형이며,

상기 데이터 유형들 중 적어도 하나는 상기 비교를 수행하기 전에 상기 참조 객체 및 상기 비교 객체가 동일한 데이터 유형을 갖도록 강제로 변환되는 것인 시스템.