KR20060132433A - 원격 경계를 가로질러 컴퓨터 판독가능한 객체들을전달하기 위한 시스템 및 방법 - Google Patents

Abstract

원격 경계를 가로질러 컴퓨터 판독가능한 객체들을 안전하게 전달하는 시스템 및 방법이 제공된다. 본 방법은, 알려진 객체 유형들의 리스트에 기초하여, 임의의 유형의 객체를 서브-컴포넌트들의 계층구조로 분해한다. 각 서브-컴포넌트는 알려진 객체 유형에 대응하거나 또는 알려지지 않은 객체 유형에 대응한다. 알려지지 않은 객체 유형들은 계층구조 내의 다른 레벨에서 알려진 객체 유형들로 더 분해될 수 있다. 계층구조 내의 알려진 객체들은 원격 엔티티로 전송되는 패키지로 직렬화된다. 원격 엔티티는 계층구조를 재구성한다. 임의의 알려진 객체 유형들에 대해, 원격 엔티티는 알려진 객체 유형의 객체를 인스턴스화하고 그 객체를 패키지 내에 전송된 정보로 실장한다. 분해 단계는 계층구조에 대한 레벨을 지정하거나, 직렬화되는 알려진 객체들을 제한하는 수를 지정하거나 또는 직렬화될 객체 내의 특성들을 지정함으로써 제한될 수 있다.

원격 경계, 객체, 계층구조, 분해, 직렬화

Description

원격 경계를 가로질러 컴퓨터 판독가능한 객체들을 전달하기 위한 시스템 및 방법{SYSTEM AND METHOD FOR TRANSFERRING COMPUTER-READABLE OBJECTS ACROSS A REMOTE BOUNDARY}

본원에 개시된 발명은, 원격 컴퓨팅 시스템에 관한 것으로, 특히 원격 통신 동안 컴퓨터 판독가능한 객체들을 전달하기 위한 방법에 관한 것이다.

오늘날, 소프트웨어 개발 시, 개발자들은 객체 지향 프로그래밍이라 불리는 프로그래밍 개념을 활용한다. 객체 지향 프로그래밍에서, 컴퓨터 판독가능한 객체들(객체들)이 정의된다. 객체들은 특성(property)들 및 메소드(method)들을 가진다. 특성들은 객체에 연관된 데이터를 저장한다. 메소드들은 객체와 연관된 기능을 실행하고 통상적으로, 객체 내에 정의된 특성들에 인터페이스를 제공한다. 객체들을 사용하여 프로그래밍하는 것이 큰 융통성을 발휘하더라도, 서로 다른 컴퓨터 사이와 같은, 원격 경계들을 가로질러 객체들을 사용하는 것은 소정의 도전에 직면한다.

한가지 도전은, 2개의 컴퓨터들 사이에서 객체들을 전달하는 메카니즘을 결정하는 것이다. 소정의 환경에서, 객체에 대한 실행가능한 코드(메소드들)은, 그의 특성들과 함께, 서버 컴퓨터로부터 요청 컴퓨터로 전달된다. 그러나, 이러한 해결책은, 전달된 실행가능한 코드가 파일들의 삭제와 같은 악의적인 액션을 실행하면 요청 컴퓨터에 보안 리스크를 부과할 수 있다. 따라서, 이러한 잠재적 위험을 최소화하기 위해 다른 해결책들이 개발되었다.

현재 한가지 해결책은, 웹 서비스 기술(Web Service Technology)로 불리우는 기술이다. 이러한 기술을 사용하면, 객체는 XML(extended mark-up language)로 변환되며, 이는 요청 컴퓨터로 전송된다. XML를 수신한 경우, 요청 컴퓨터는 XML을 다시 객체로 변환한다. 그 후, 요청 컴퓨터가 객체의 특성들을 액세스하고 객체의 메소드들을 불러올 수 있다. 이러한 기술을 사용하면, 요청 컴퓨터가, 그로부터 객체가 수신되는 서버를 인지하고 신뢰할 책임을 맡는다. 또한, 요청 컴퓨터와 통신하기를 원하는 임의의 객체에 대해, 객체를 개발한 소프트웨어 개발자는 통신을 처리하기 위한 특별한 인터페이스를 구현하여야 한다. 특별한 인터페이스는 객체가 전송되기 위해 객체를 직렬화(serialize)하고 역직렬화(de-serialize)하기 위한 메카니즘을 제공한다.

이러한 웹 서비스 해결책이 원격 경계들을 가로질러 객체들을 전송하기 위한 강인한 환경을 제공하더라도, 그 기술은 제한적이고 부담스럽다. 시스템 관리 환경에서와 같은, 소정의 환경에서, 시스템 관리 태스크들이 모니터하기를 원하는 객체들에 대한 특별한 인터페이스를 소프트웨어 개발자에게 강제로 구현하게 하는 것은 실행가능한 해결책이 아니다. 예를 들어, 개발자들이 이러한 특별한 인터페이스를 구현하도록 요구하는 것은 간단한 문제가 아니며, 개발자들이 그들의 주요 목적 - 그들 자신의 특별한 애플리케이션에 대해 객체를 구현하는 것 - 으로부터 주 의를 돌리는 것을 필요로 한다. 따라서, 많은 개발자는 그들의 객체들에 대한 특별한 인터페이스를 구현하지 않고, 그 결과 이러한 객체들은 액세스가능하지 않다.

따라서, 안전하고, 제한적이지 않고, 소프트웨어 개발자들에게 부담이 되지 않는, 원격 경계를 가로질러 객체들을 전달하는 방법이 필요하다.

본 발명은, 객체들의 원격 통신을 위한 메카니즘 및 기술에 관한 것이다. 간략히 말하면, 원격 경계를 가로질러 컴퓨터 판독가능한 객체들을 안전하게 전달하기 위한 시스템 및 방법이 제공된다. 본 방법은, 임의의 유형의 객체를 알려진 객체 유형들의 리스트에 기초하여 서브-컴포넌트(sub-component)들의 계층구조(hierarchy)로 분해한다. 각 서브-컴포넌트는 알려진 객체 유형 또는 미지의 객체 유형에 대응한다. 미지의 객체 유형들이 계층구조 내의 다른 레벨에서 알려진 객체 유형들로 더 분해될 수 있다. 계층구조 내의 알려진 객체들은 원격 엔티티(remote entity)로 전송되는 패키지로 직렬화(serialize)된다. 원격 엔티티는 계층구조를 재구성한다. 알려진 객체 유형들중 임의의 것에 대해, 원격 엔티티는 알려진 객체 유형의 객체를 인스턴스화(instantiate)하고 패키지로 전송된 정보로 객체를 실장한다(populate). 계층구조에 대한 레벨을 지정하거나, 직렬화되는 알려진 객체들을 제한하는 수를 지정하거나 또는 직렬화될 객체 내의 특성들을 지정함으로써 분해(decomposition)가 제한될 수 있다.

도 1은 예시적인 관리 도구 프레임워크가 구현될 수 있는 예시적인 컴퓨팅 장치를 나타낸다.

도 2는 예시적인 관리 도구 프레임워크의 개요를 일반적으로 설명하는 블록도이다.

도 3은 도 2에 도시된 관리 도구 프레임워크의 호스트-고유 컴포넌트들 내의 컴포넌트들을 설명하는 블록도이다.

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

도 5는 도 2에 도시된 관리 도구 프레임워크 내에서 사용하는데 적합한 예시적인 확장형 관리기의 기능 블록도이다.

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

도 7은 cmdlets의 원격 프로세싱을 수행하기 위한, 도 2에 도시된 관리 도구 프레임워크 내의 컴포넌트들을 설명하는 기능 블록도이다.

도 8은 cmdlet를 처리하기 위한 예시적인 프로세스를 설명하는 논리적 흐름도이다.

도 9는 도 8에 사용하기에 적절한 직렬화 프로세스 및 역직렬화 프로세스의 개요를 나타내는 블록도이다.

도 10은 도 8에 도시된 cmdlet의 프로세싱 시에 사용하기에 적절한 객체들을 직렬화하기 위한 예시적인 프로세스를 설명하는 논리적 흐름도이다.

도 11은 도 8에 도시된 cmdlet의 프로세싱 시에 사용하기에 적절한 객체들을 역직렬화(de-serialize)하기 위한 예시적인 프로세스를 설명하는 논리적 흐름도이다.

도 12는 도 10에 도시된 직렬화 프로세스 동안에 생성된 특성 백 계층구조(property bag hierarchy)의 그래픽 표현이다.

도 13은 도 10에 도시된 객체들을 직렬화하기 위한 프로세스와 함께 사용하기에 적절한 프로토콜을 절충(negotiate)하기 위한 예시적인 프로세스를 설명하는 논리적 흐름도이다.

간단히 말하면, 원격 경계를 가로질러 객체들을 전달하기 위한 본원의 시스템 및 방법은 안전하게 객체를 전달하는 방법을 제공한다. 또한, 본 시스템 및 방법은, 객체에 대해 임의의 인공적인 요구조건을 부과하지 않는다. 따라서, 소프트웨어 개발자들은 그들의 객체들을 사용하여 원격 오퍼레이션들을 지원하기 위한 어떤 부담도 유발시키지 않는다. 따라서, 기존의 시스템과 달리, 임의의 컴퓨터 상의 임의의 객체 또는 동일한 컴퓨터 상의 다른 프로세스 내의 임의의 객체는 요청 프로세스에 대해 원격 경계를 가로질러 전달될 수 있다. 또한, 객체를 전달하기 위한 본 시스템 및 방법은 양쪽 컴퓨터들이 동일한 버젼의 소프트웨어를 실행하는 것을 요구하지 않는다. 오히려, 본 방법은, 2개의 다른 버젼들 간의 통신을 지원하기 위한 메카니즘을 제공할 뿐만 아니라, 원격 경계를 통해 전달된 데이터량을 최소화시키는 프로토콜 절충 프로세스를 포함한다.

다음의 상세한 설명은 몇개의 섹션들로 나누어진다. 일반적으로, 본 시스템 및 방법은 예시적인 관리 도구 환경의 배경 내에서 설명된다. 그러나, 다음의 설명을 읽은 후에, 본 기술 분야의 당업자는, 본 방법이, 첨부된 청구의 범위의 범주 내에도 포함되는 다른 예시적인 환경들에서 구현될 수 있다는 것을 이해할 것이다.

첫번째 섹션에서는, 예시적인 관리 도구 환경이 동작할 수 있는 예시적인 컴퓨팅 환경을 설명한다. 두번째 섹션에서는 관리 도구 환경에 대한 예시적인 프레임워크를 설명한다. 후속 섹션들에서는 예시적인 프레임워크의 개별적인 컴포넌트들 및 이러한 컴포넌트들의 동작을 설명한다. 예를 들어, "Cmdlet의 예시적인 원격 프로세싱"에 관한 섹션은 도 7-13과 함께 원격 경계를 가로질러 객체들을 전달하는 예시적인 시스템 및 방법을 설명한다.

예시적인 컴퓨팅 환경

도 1은 예시적인 관리 도구 환경에 사용될 수 있는 예시적인 컴퓨팅 장치를 도시한다. 아주 기본적인 구성으로, 컴퓨팅 장치(100)는 통상적으로 적어도 하나의 프로세싱 유닛(102) 및 시스템 메모리(104)를 포함한다. 컴퓨팅 장치의 정확한 구성 및 유형에 따라, 시스템 메모리(104)는 (RAM과 같은) 휘발성, (ROM, 플래시 메모리 등과 같은) 불휘발성 또는 2개의 소정의 조합일 수 있다. 시스템 메모리(104)는 통상적으로 운영 체제(105), 하나 이상의 프로그램 모듈(106)을 포함하고, 프로그램 데이터(107)를 포함할 수 있다. 운영 체제(106)는 (특성들 및 이벤트들을 포함하는) 컴포넌트들, 객체들, 계승(inheritance), 폴리모피즘(polymorphism), 리플렉션(reflection)을 지원하는 컴포넌트 기반 프레임워크(120)을 포함하고, 워 싱턴, 레드몬드의 마이크로소프트사에 의해 제조된 .NET^TM 프레임워크의 것과 같은, 객체 지향 컴포넌트 기반 API(application programming interface)를 제공한다. 운영 체제(105)는 관리 도구(도시 안됨)들의 개발을 지원하기 위해 컴포넌트 기반 프레임워크(120)와 상호작용하는 관리 도구 프레임워크(200)를 포함할 수도 있다. 이러한 기본 구성은 대시 라인(108) 내의 컴포넌트들에 의해 도 1에 도시된다.

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

컴퓨팅 장치(100)는, 네트워크를 통해서와 같이 장치가 다른 컴퓨팅 장치(118)와 통신할 수 있게 하는 통신 접속(116)을 포함할 수도 있다. 통신 접속(116)은 통신 매체들의 하나의 예이다. 통신 매체들은 컴퓨터 판독가능한 명령들, 데이터 구조들, 프로그램 모듈들 또는 반송파 또는 다른 전송 메카니즘과 같은, 변조된 데이터 신호 내의 다른 데이터에 의해 통상적으로 구현될 수 있고 임의의 정보 전달 매체들을 포함할 수 있다. "변조된 데이터 신호"라는 용어는, 정보를 신호로 인코딩하는 방식으로 설정되거나 변경된 하나 이상의 특성을 갖는 신호를 의미한다. 한정이 아닌 예로서, 통신 매체들은 배선된 네트워크 또는 직접 배선된 접속과 같은 배선된 매체, 및 음향, RF, 적외선 및 다른 무선 매체들과 같은 무선 매체들을 포함한다. 본원에서 사용되는 컴퓨터 판독가능한 매체라는 용어는 스토리지 매체 및 통신 매체 모두를 포함한다.

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

도 2는 예시적인 관리 도구 프레임워크(200)의 개요를 일반적으로 도시하는 블록도이다. 관리 도구 프레임워크(200)는 하나 이상의 호스트 컴포넌트들(202), 호스트-고유 컴포넌트들(204), 호스트-독립형 컴포넌트들(206), 및 핸들러(handler) 컴포넌트들(208)을 포함한다. 호스트-독립형 컴포넌트들(206)은 다른 컴포넌트들 각각 (예를 들어, 호스트 컴포넌트들(202), 호스트-고유 컴포넌트들(204) 및 핸들러 컴포넌트들(208))과 통신할 수 있다. 이러한 컴포넌트들 각각은 아래에 간략하게 설명되어 있고 필요할 경우, 후속 섹션들에서 보다 자세하게 기술되고 있다.

호스트 컴포넌트들

호스트 컴포넌트들(202)은, 연관된 애플리케이션에 대한 자동화 특징을 사용자들 또는 다른 프로그램들에게 노출시키는 하나 이상의 호스트 프로그램들(예를 들면, 호스트 프로그램(210-214))을 포함한다. 각 호스트 프로그램(210-214)은, 커맨드 라인, GUI(graphical user interface), 음성 인식 인터페이스, API(application programming interface), 스크립팅 언어(scripting language), 웹 서비스 등을 통하는 것과 같이, 자신의 특정 스타일로 상기 자동화 특징을 노출시킬 수 있다. 그러나, 호스트 프로그램(210-214) 각각은 관리 도구 프레임워크에 의해 제공되는 메카니즘을 통해 하나 이상의 자동화 특징들을 노출시킨다.

상기 예에서, 메카니즘은 cmdlets를 사용하여 관리 도구 기능을 연관된 호스트 프로그램(210-214)의 사용자에게 표면화(surface)시킨다. 이외에도, 메카니즘은, 대응하는 호스트 프로그램(210-214)과 연관된 애플리케이션 내에 관리 도구 환경을 내장하기 위해 호스트에 의해 가용하게 된 인터페이스 세트를 사용한다. 다음의 설명에서, 용어 "cmdlet"는, 예시적인 관리 도구 환경 내에서 사용되는 커맨드들을 나타내는데 사용된다.

Cmdlets는 전통적인 관리 환경들 내의 커맨드들에 대응한다. 그러나, cmdlets는 이러한 전통적인 커맨드와는 상당히 상이하다. 예를 들어, cmdlets는, 구문분석, 데이터 검증, 에러 보고 등과 같은, 관리 도구 프레임워크에 의해 제공되는 일반적인 기능들을 활용할 수 있기 때문에, cmdlets는 통상적으로 그들의 대응 커맨드들보다 크기가 작다. 그러한 일반적인 기능들은 한번 구현되고 한번 테스트될 수 있기 때문에, 관리 도구 프레임워크를 통해 cmdlets를 사용하면 애플리케이션-고유 기능들과 연관된 증가하는 개발 및 테스트 비용을 종래 환경들과 비교할 경우 상당히 낮출 수 있다.

또한, 종래의 환경들과는 대조적으로, cmdlets은 독립형 실행가능한 프로그램들일 필요는 없다. 오히려, cmdlets는 관리 도구 프레임워크 내의 동일한 프로세스들에서 작동할 수 있다. 이로 인해, cmdlets가 서로 간에 "라이브(live)" 객체들을 교환할 수 있다. "라이브" 객체들을 교환하는 이러한 능력으로 인해 cmdlets는 이들 객체들에 대한 메소드들을 직접 불러올 수 있다.

개략적으로, 각 호스트 프로그램(210-214)은 관리 도구 프레임워크 내에서 사용자와 다른 컴포넌트들 간의 상호작용을 관리한다. 이러한 상호작용은 파라미터용 프롬프트들, 에러 보고서 등을 포함할 수 있다. 전형적으로, 각 호스트 프로그램(210-213)은 자신의 특정 호스트 cmdlets(예를 들어, 호스트 cmdlets(218)) 세트를 제공할 수 있다. 예를 들어, 호스트 프로그램이 이메일 프로그램이면, 호스트 프로그램은 메일박스들 및 메시지들과 상호작용하는 호스트 cmdlets를 제공할 수 있다. 도 2가 호스트 프로그램(210-214)를 도시하더라도, 본 기술분야의 당업자는, 호스트 컴포넌트들(202)이 기존의 애플리케이션들 또는 새롭게 생성된 애플 리케이션들과 연관된 다른 호스트 프로그램들을 포함할 수 있다는 것을 이해할 것이다. 이러한 다른 호스트 프로그램들은 또한 그들의 연관된 애플리케이션 내에 관리 도구 환경에 의해 제공된 기능을 내장시킬 수 있다.

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

다른 예에서, 호스트 프로그램은 커맨드 라인 대화형 쉘(command line inteactive shell)(즉, 호스트 프로그램(212))일 수 있다. 커맨드 라인 대화형 쉘은, 커맨드 라인을 처리하기 위해, 쉘 메타데이타(216)가 커맨드 라인으로 입력되게 할 수 있다.

또 다른 예에서, 호스트 프로그램은, 플랫폼들, 프로그래밍 언어들 및 애플리케이션들에 걸친 분산 컴퓨팅 및 상호운용성을 위한 업계 표준 규격들을 사용하는 웹 서비스(즉, 호스트 프로그램(214))일 수 있다. 도 7에 도시된 다른 예에서, 호스트 프로그램은 원격 컴퓨터와 통신하기 위한 원격 인터페이스를 제공할 수 있다.

이러한 예들 이외에, 제3자는, "제3자(third party)" 또는 "제공자(provider)" 인터페이스들을 생성함으로써 그들 자신의 호스트 컴포넌트들을 추가하고, 그들의 호스트 프로그램 또는 다른 호스트 프로그램들과 함께 사용되는 cmdlets를 제공할 수 있다. 제공자 인터페이스는, 애플리케이션 또는 인프라스트럭쳐가 관리 도구 프레임워크에 의해 조작될 수 있도록 애플리케이션 또는 인프라스트럭쳐를 노출시킨다. 제공자 cmdlets는 내비게이션, 진단, 구성, 수명, 오퍼레이션 등을 위해 자동화를 제공한다. 제공자 cmdlets는 데이터 스토어(data store)들의 완전한 이종 세트에 대해 폴리모픽(polymorphic) cmdlets 거동을 나타낸다. 관리 도구 환경은 동일한 우선순위를 갖는 다른 cmdlet 클래스들과 동일한 우선순위를 갖는 제공자 cmdlets에 동작한다. 제공자 cmdlet는 다른 cmdlets와 동일한 메카니즘을 사용하여 생성된다. 제공자 cmdlets는 애플리케이션 또는 인프라스트럭쳐의 특정 기능을 관리 도구 프레임워크에 노출시킨다. 따라서, cmdlets의 사용을 통해, 제품 개발자들은, 그들의 제품이 나중에 많은 관리 도구들과 작동할 수 있게 할 하나의 호스트 컴포넌트를 생성하는 것만을 필요로 한다. 예를 들어, 예시적인 관리 도구 환경에서, 시스템 레벨 그래픽 사용자 인터페이스 도움 메뉴는 기존의 애플리케이션들에 통합되고 포팅(port)될 수 있다.

호스트-고유 컴포넌트들(Host-specific components)

호스트-고유 컴포넌트들(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를 출력하기 위해 호스트에 의해 제공된 인터페이스들을 포함한다. 이러한 출력 cmdlets는 그 후 호스트의 출력 객체를 호출하여 렌더링을 수행한다. 호스트-고유 컴포넌트들(204)은, 로깅 및 감사(logging and auditing) 성능을 제공하는 호스트 고유(즉 플랫폼 고유) 서비스들과 통신하는데 코어 엔진(204)이 사용하는 로깅/감사(logging/auditing) 컴포넌트(310)를 포함할 수도 있다.

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

핸들러 컴포넌트들(Handler components)

도 2를 다시 참조하면, 핸들러 컴포넌트(208)들은, 레거시 유틸리티들(230), 관리 cmdlets(232), 비관리(non-management) cmdlets(234), 원격 cmdlets(236) 및 웹 서비스 인터페이스(238)를 포함한다. 관리 cmdlets(232)(플랫폼 cmdlets로도 불림)은, 컴퓨팅 장치와 연관된 구성 정보를 질의하거나 다루는(manipulate) cmdlets를 포함한다. 관리 cmdlets(232)는 시스템 유형 정보를 다루기 때문에, 특정 플랫폼에 의존적이다. 그러나, 각 플랫폼은 통상적으로 다른 플랫폼들 상에서 관리 cmdlets(232)와 유사한 액션들을 제공하는 관리 cmdlest(232)를 가진다. 예를 들어, 각 플랫폼은 시스템 관리 속성들을 가지고 오고 설정하는 관리 cmdlets(232)(예를 들면, get/process, set/IPAddress)를 지원한다. 호스트-독립형 컴포넌트들(206)은 호스트-독립형 컴포넌트들(206) 내에 생성된 cmdlet 객체들을 통해 관리 cmdlets와 통신한다.

비관리(non-management) cmdlets(234)(종종 기본 cmdlets로 불림)은, 관리 cmdlets(232)에 의해 제공되는 객체들에 대해 다른 프로세싱을 그룹화하고, 소트하고, 필터링하고 수행하는 cmdlets를 포함한다. 비관리 cmdlets(234)는 파이프라인된 객체들과 연관된 데이터를 포맷하고 출력하기 위한 cmdlets를 포함할 수도 있다. 비관리 cmdlets(234)는 각 플랫폼 상에서 동일할 수 있고, cmdlet 객체들을 통해 호스트-독립형 컴포넌트들(206)과 상호작용하는 유틸리티 세트를 제공한다. 비관리 cmdlets(234)와 호스트-독립형 컴포넌트들(206) 간의 상호작용들은, 객체들에 대한 리플렉션(reflection)을 허용하고, 그들의 (객체) 유형에 독립적인, 리플렉션된 객체들에 대한 프로세싱을 허용한다. 따라서, 이러한 유틸리티들은, 개발 자들이 비관리 cmdlets를 한번 기입할 수 있게 하고 그 후 이러한 비관리 cmdlets를 컴퓨팅 시스템에서 지원되는 모든 객체 클래스들에 적용한다. 과거에, 개발자들은 처리될 데이터의 포맷을 먼저 이해하고 그 후 단지 해당 데이터를 처리하기 위해 애플리케이션를 기입하여야만 했다. 결과적으로, 전통적인 애플리케이션들은 매우 제한적인 범위의 데이터만을 처리할 수 있었다.

레거시 유틸리티들(230)은, cmd.exe 하에서 실행가능 win32와 같은, 기존의 실행 가능한 것을 포함한다. 각 레거시 유틸리티들(230)은, 객체 프레임워크 내의 객체의 한 유형인, 텍스트 스트림(즉, stdin 및 stdout)을 사용하여 관리 도구 프레임워크와 통신한다. 레거시 유틸리티들(230)이 텍스트 스트림들을 활용하기 때문에, 관리 도구 프레임워크에 의해 제공된 리플렉션-기반 오퍼레이션들은 이용가능하지 않다. 레거시 유틸리티들(230)은 관리 도구 프레임워크와는 다른 프로세스에서 실행한다. 도시되지 않더라도, 다른 cmdlets도 프로세스 밖에서(out of process) 동작할 수 있다.

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

예를 들어, 호스트 컴포넌트들(202)중 하나로서 도시된 웹 서비스(214)는 원격 에이전트일 수 있다. 원격 에이전트는 목표 시스템 상의 구문분석기 및 관리 도구 프레임워크에 대한 원격 커맨드 요청들의 제출을 처리한다. 원격 cmdlets는 원격 에이전트에 대한 액세스를 제공하는 원격 클라이언트로 기능한다. 원격 에이전트 및 원격 cmdlets는 구문분석된 스트림을 통해 통신한다. 이러한 구문분석된 스트림은 프로토콜 계층에서 보호될 수 있거나 또는 추가 cmdlets가 사용되어 구문분석된 스트림을 암호화하고 그 후 복호화할 수 있다. 원격 cmdlets를 처리하고 원격 프로세스들 사이에서 객체들을 전달하기 위한 예시적인 컴포넌트들이 도 7에 도시되고 "Cmdlets의 예시적인 원격 프로세싱"이란 제목의 섹션에서 후술된다.

호스트-독립형 컴포넌트들(Host-independent components)

호스트-독립형 컴포넌트들(206)은 구문분석기(220), 스크립트 엔진(222) 및 코어 엔진(224)을 포함한다. 호스트-독립형 컴포넌트들(206)은, 다수의 cmdlets를 그룹화하고, cmdlets의 동작을 조정하며, 다른 자원들, 세션들 및 잡(job)들의, cmdlets와의 상호작용들을 조정하기 위한 메카니즘 및 서비스들을 제공한다.

예시적인 구문분석기(Exemplary Parser)

구문분석기(220)는, 다양한 호스트 프로그램들로부터 입력 요청들을 수신하 고, 코어 엔진(224) 내에서와 같이, 관리 도구 프레임워크를 통해 사용되는 균일한 cmdlets 객체들로 입력 요청들을 매핑하기 위한 메카니즘을 제공한다. 또한, 구문분석기(220)는 수신된 입력에 기초하여 데이터 프로세싱을 수행할 수 있다. 본 발명의 관리 도구 프레임워크의 구문분석기(220)는, 동일한 성능을 위해 서로 다른 언어들 또는 신택스를 사용자들에게 용이하게 노출시키는 성능을 제공한다. 예를 들어, 구문분석기(220)는 입력 요청들의 해석을 맡고 있기 때문에, 예상되는 입력 신택스에 영향을 주는 구문분석기(220) 내에서의 코드에 대한 변화는 본질적으로 관리 도구 프레임워크의 각 사용자에게 영향을 줄 것이다. 따라서, 시스템 관리자들은, 서로 다른 신택스를 지원하는 서로 다른 컴퓨터 장치들 상에 서로 다른 구문분석기들을 제공할 수 있다. 그러나, 동일한 구문분석기를 사용하여 동작하는 각 사용자는 각 cmdlet에 대해 일관된 신택스를 경험할 것이다. 대조적으로, 전통적인 환경들에서는, 각 커맨드가 자신의 신택스를 구현하였다. 따라서, 수많은 커맨드들을 사용하면, 각 환경은 수개의 서로 다른 신택스를 지원하고, 일반적으로 그들중 많은 부분은 서로 일관되지 않는다.

예시적인 스크립트 엔진(Exemplary Script Engine)

스크립트 엔진(222)은 스크립트를 사용하여 다수의 cmdlets를 함께 묶는 메카니즘 및 서비스들을 제공한다. 스크립트는 엄격한 계승 규칙들 하에서 세션 상태를 공유하는 커맨드 라인들의 집합이다. 스크립트 내의 다수의 커맨드 라인들은, 입력 요청에 제공된 신택스에 기초하여, 동기적 또는 비동기적으로 실행될 수 있다. 스크립트 엔진(222)는, 루프 및 조건절과 같은 제어 구조들을 처리하고, 스 크립트 내의 변수들을 처리하는 능력을 가진다. 스크립트 엔진은 또한 세션 상태를 관리하고 정책(도시 안됨)에 기초하여 세션에 대한 cmdlets 액세스를 제공한다.

예시적인 코어 엔진(Exemplary Core Engine)

코어 엔진(224)은 구문분석기(220)에 의해 식별된 cmdlets의 프로세싱을 담당한다. 도 4로 잠깐 돌아가면, 관리 도구 프레임워크(200) 내의 예시적인 코어 엔진(224)이 도시되어 있다. 예시적인 코어 엔진(224)은 파이프라인 프로세서(402), 로더(loader)(404), 메타데이타 프로세서(406), 에러 & 이벤트 핸들러(408), 세션 관리기(410) 및 확장형 관리기(412)를 포함한다.

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

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

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

에러 & 이벤트 프로세서(408)는 커맨드 라인의 프로세싱 동안 각 에러 발생에 대한 정보를 저장하도록 에러 객체를 제공한다. 본 관리 톨 프레임워크에 특별히 맞는 하나의 특별한 에러 및 이벤트 프로세서에 관한 추가 정보에 대해서는, "System and Method for Persisting Error Information in a Command Line Environment"라는 제목의 미국 특허 출원 번호 10/413,054를 참조하라. 상기 문헌은 본 발명과 동일한 양수인이 소유하고 있으며, 참조로 본원에 포함된다.

예시적인 세션 관리기

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

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

로더(404)는, 파이프라인 프로세서(402)가 cmdlet를 실행하도록 메모리 내에 각 cmdlet를 로딩하도록 구성된다. 파이프라인 프로세서(402)는 cmdlet 프로세서(420) 및 cmdlet 관리기(422)를 포함한다. cmdlet 프로세서(420)는 개별적인 cmdlets를 배정(dispatch)한다. cmdlet가 원격 또는 원격 머신 세트 상에서의 실행을 필요로 하면, cmdlet 프로세서(420)는 도 2에 도시된 원격 cmdlet(236)의 실행을 조정한다. cmdlet 관리기(422)는 cmdlets 집합의 실행을 처리한다. cmdlet 관리기(422), cmdlet 프로세서(420) 및 스크립트 엔진(222)(도 2)은, 호스트 프로그램(210-214)으로부터 수신된 입력에 대한 프로세싱을 수행하기 위해 서로 통신한다. 통신은 자연적으로 반복적일 수 있다. 예를 들어, 호스트 프로그램이 스크립트를 제공하면, 스크립트는, 그 자체가 스크립트일 수 있는 cmdlet를 실행하기 위해 cmdlet 관리기(422)를 불러올 수 있다. 그 후, 스크립트는 스크립트 엔진(222) 에 의해 실행될 수 있다.

예시적인 확장형 관리기(Exemplary Extended Type Manager)

상술한 바와 같이, 관리 도구 프레임워크는, 객체들에 대한 리플렉션을 허용하고 그들의 (객체) 유형에 독립적인 리플렉션된 객체들에 대한 프로세싱을 허용하는 유틸리티 세트를 제공한다. 관리 도구 프레임워크(200)는 이러한 리플렉션을 수행하기 위해 컴퓨팅 시스템 상의 컴포넌트 프레임워크(도 1의 컴포넌트 프레임워크(120))와 상호작용한다. 본 기술분야의 당업자는, 리플렉션이, 객체를 질의하고 객체에 대한 유형을 얻을 능력을 제공하고, 그 후 다른 객체들 및/또는 원하는 값을 얻기 위해 해당 유형의 객체와 연관된 특성들 및 다양한 객체들에 리플렉션(reflection)시킨다는 것을 이해할 것이다.

리플렉션이 관리 도구 프레임워크(200)에게 객체에 대한 상당한 양의 정보를 제공하더라도, 전통적으로 리플렉션은 객체의 유형에 초점을 맞춘다. 예를 들어, 데이터베이스 데이터테이블(database datatable)이 리플렉션되는 경우, 반환되는 정보는 데이터테이블이 2개의 특성: 컬럼 특성 및 로우(row) 특성을 가진다는 것이다. 이러한 두개의 특성들은 데이터테이블 내의 "객체들"에 대해 충분한 상세를 제공하지 않는다. 리플렉션이 XML(extensible markup language) 및 다른 객체들에 사용되는 경우 유사한 문제점들이 발생한다.

대조적으로, 확장형 관리기(412)는 객체의 유형보다는 유형의 사용에 초점을 둔다. 따라서, 이를 그 초점에 따라 사용하면, 확장형 관리기는 필요한 정보를 얻기 위해 객체가 사용될 수 있는지 여부를 판단한다. 상기 데이터테이블 예를 계속 하면, 데이터테이블이 컬럼 특성 및 로우 특성을 가진다는 것을 아는 것이 특별히 흥미롭지는 않다. 그러나, 사용에 초점을 맞춤으로써, 확장형 관리기는 각 로우를 "객체"와 연관시키고 각 컬럼을 해당 "객체"의 "특성"과 연관시킨다. 따라서, 확장형 관리기(412)는 정확히 구문분석될 수 있는 입력의 임의의 유형으로부터 "객체들"을 생성하는 메카니즘을 제공하다. 이렇게 할 경우, 확장형 관리기(412)는 컴포넌트 기반 프레임워크(120)에 의해 제공된 리플렉션 성능을 보충하고 "리플렉션(reflection)"를 정확하게 구문분석될 수 있는 입력의 임의의 유형으로 확장시킨다.

요약하면, 확장형 관리기는, 정확하게 구문분석될 수 있는 입력(도시 안됨)을 액세스하고 정확하게 구문분석될 수 있는 입력을 요청된 데이터 유형과 상관시키도록 구성된다. 그 후, 확장형 관리기(412)는 파이프라인 프로세서(402) 또는 구문분석기(220)와 같은 요청 컴포넌트에 요청된 정보를 제공한다. 다음의 설명에서, 정확하게 구문분석될 수 있는 입력은, 특성들 및 값들이 구별될 수 있는 입력으로 정의된다. 소정의 예시적인, 정확하게 구분분석될 수 있는 입력은, WMI(Windows Management Instrumentation) 입력, ADO(ActiveX Data Object) 입력, XML 입력, 및 .NET 객체들과 같은 객체 입력을 포함한다. 정확하게 구문분석될 수 있는 다른 입력은 제3자 데이터 포맷(third party data formats)들을 포함할 수 있다.

도 5는 관리 도구 프레임워크 내에서 사용하는 예시적인 확장형 관리기의 기능적 블록도이다. 설명을 위해, 확장형 관리기에 의해 제공되는 (원 내에서 숫자 "3"으로 표시된) 기능은, 전통적으로 단단히 묶인 시스템(tightly bound system)에 의해 제공되는 (원 내에서 숫자 "1"로 표시된) 기능 및 리플렉션 시스템에 의해 제공되는 (원 내의 숫자 "2"로 표현되는) 기능과 대조적이다. 전통적으로 단단히 묶인 시스템에서, 애플리케이션 내의 호출기(502)는 객체 A 내의 정보(예를 들면, 특성 P1 및 P2, 메소드 M1 및 M2)를 직접 액세스한다. 상술한 바와 같이, 호출기(502)는, 연역적으로(a priori), 컴파일 시간에 객체 A에 의해 제공되는 특성들(예를 들면 특성 P1 및 P2) 및 메소드들(예를 들면, 메소드 M1 및 M2)를 알아야 한다. 리플렉션 시스템에서, (임의의 데이터 유형에 의존적이지 않는) 일반 코드(520)는 요청된 객체에 대해 리플렉션(510)을 수행하는 시스템(508)에 질의하고 객체(예를 들면, 객체 A)에 대한 정보(예를 들면, 특성 P1 및 P2, 메소드 M1 및 M2)를 일반 코드(520)에 반환한다. 객체 A에 도시되지 않더라도, 반환된 정보는, 판매자, 파일, 날짜 등과 같은 추가 정보를 포함할 수 있다. 따라서, 리플렉션을 통해, 일반 코드(520)는, 단단히 묶인 시스템이 제공하는 것과 적어도 동일한 정보를 얻는다. 리플렉션 시스템은 또한 호출기(502)가 시스템에 질의하고 파라미터들의 임의의 연역적 지식없이 추가 정보를 갖고 오도록 할 수 있다.

단단히 묶인 시스템과 리플렉션 시스템 모두에서, 새로운 데이터 유형들은 동작 환경 내에 용이하게 포함될 수 없다. 예를 들어, 단단히 묶인 시스템에서, 동작 환경이 전달되면, 그들을 지원하기 위해 재구축되어야 하기 때문에 동작 환경은 새로운 데이터 유형들을 포함할 수 없다. 유사하게, 리플렉션 시스템에서, 각 객체 클래스에 대한 메타데이터는 고정된다. 따라서, 새로운 데이터 유형들을 포 함하는 것은 일반적으로 이루어지지 않는다.

그러나, 본 확장형 관리기를 사용하면 새로운 데이터 유형들이 운영 체제에 포함될 수 있다. 확장형 관리기(522)를 사용할 경우, 일반 코드(520)는 요청된 객체에 대해 리플렉션되어, 제3자 객체들(예를 들면 객체 A' 및 B), 시맨틱 웹(semantic web)(532), 온톨로지 서비스(ontology service)(534) 등과 같은 다양한 외부 소스들에 의해 제공되는 확장형 데이터 유형들(예를 들면, 객체 A')를 얻을 수 있다. 도시된 바와 같이, 제3자 객체는 기존 객체를 확장하거나(예를 들면 객체 A') 또는 완전히 새로운 객체를 생성할 수 있다(예를 들면, 객체 B).

이러한 외부 소스들 각각은 유형 메타데이타(540) 내에 그들의 고유 구조를 등록하고 코드(542)를 제공할 수 있다. 객체가 질의되는 경우, 확장형 관리기는 유형 메타데이타(540)를 리뷰하여 객체가 등록되어 있는지 여부를 판단한다. 객체가 유형 메타데이타(540) 내에 등록되어 있지 않으면, 리플렉션이 실행된다. 다른 경우, 확장형 리플렉션이 실행된다. 코드(542)는 리플렉션되는 유형과 연관된 추가 특성들 및 메소드들을 반환한다. 예를 들어, 입력 유형이 XML이면, 코드(542)는, XML 문서로부터 객체들을 생성하는데 XML이 사용되는 방식을 기술하는 기술 파일을 포함할 수 있다. 따라서, 유형 메타데이타(540)는, 특정 입력 유형 및 코드(542)가 원하는 특성들을 얻기 위한 명령들을 제공하는 객체를 생성하기 위해, 확장형 관리기(412)가 다양한 유형의, 정확하게 구문분석될 수 있는 입력(예를 들면, 제3자 객체 A' 및 B, 시멘틱 웹(532))을 질의하여 이러한 원하는 특성들을 얻는 방법을 기술한다. 결과적으로, 확장형 관리기(412)는, 모든 유형의 객체들에 대해 " 리플렉션(reflection)"을 허용하는 인다이렉션(indirection) 계층을 제공한다. 이러한 인다이렉션 계층에 대한 예시적인 구현은 원격 프로세싱과 함께 아래에서 보다 자세히 설명된다. 이러한 구현에서, 정확하게 구문분석될 수 있는 입력(예를 들면, 직렬화된 객체)가 사용되어, 특정 입력 유형(예를 들면, 특성 백(property bag))에 대해 객체를 생성하기 위해 원하는 특성들을 얻는다. 그 후, 특성 백이 더 분해되어 하나 이상의 기본 유형들의 객체들을 생성한다. 설명될 것과 같이, 확장형 관리기는 일 실시예가 원격 프로세스들 간에 객체들을 전달할 수 있도록 하고 임의의 유형의 임의의 객체가 프로세스들 간에 전달될 수 있게 한다.

확장형들을 제공하는 것 이외에, 확장형 관리기(412)는, 특성 경로 메카니즘, 키 메카니즘, 비교 메카니즘, 변환 메카니즘, 글로버 메카니즘(globber mechanism), 특성 세트 메카니즘, 관계 메카니즘 등과 같은 추가의 질의 메카니즘을 제공한다. 다양한 기술이 사용되어 확장형 관리기를 위한 시멘틱(semantics)을 구현한다. 아래에 3가지 기술들이 설명된다. 그러나, 본 기술분야의 당업자는 이들 기술의 변형들이 사용될 수 있다는 것을 이해할 것이다.

한 기술에서, 스태틱 메소드(예를 들면, getproperty() )들을 갖는 일련의 클래스들이 제공될 수 있다. 객체가 스태틱 메소드(예를 들면, getproperty(object) )로 입력되고 스태틱 메소드들은 결과 세트를 반환한다. 다른 기술의 경우, 동작 환경이 어댑터로 객체를 봉인한다. 따라서, 입력이 공급되지 않는다. 어댑터의 각 인스턴스는, 봉인된 객체(enveloped object)에 작용하는 getproperty 메소드를 가지며, 봉인된 객체에 대한 특성들을 반환한다. 다음은 이 러한 기술을 나타내는 의사 코드이다:

또 다른 기술의 경우, 어댑터 클래스는 객체를 서브클래스(sub-class)화시킨다. 전통적으로, 서브클래스화하는 것은, 컴파일 전에 발생하였다. 그러나, 소정의 동작 환경에서는 서브클래스화는 동적으로 발생할 수 있다. 이러한 유형의 환경에 대해, 다음은 이러한 기술을 나타내는 의사 코드이다:

따라서, 도 5에 도시된 바와 같이, 확장형 관리기는, 개발자들이 새로운 데이터 유형을 생성하고, 데이터 유형을 등록할 수 있게 하고, 다른 애플리케이션들 및 cmdlets가 새로운 데이터 유형을 사용할 수 있게 한다. 대조적으로, 이전의 관리 환경에서는, 각 데이터 유형은 컴파일 시간에 알려져야한 하고, 그 결과 해당 데이터 유형으로부터 인스턴트화된 객체와 연관된 특성 또는 메소드가 직접 액세스될 수 있다. 따라서, 관리 환경에 의해 지원되었던 새로운 데이터 유형을 추가하 는 것은 과거에는 거의 행해지지 않았다.

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

예시적인 동작

도 6은 관리 도구 환경 내에서 사용되는 예시적인 데이터 구조를 그래픽으로 나타낸다. 도 8 ~ 11 및 13은, 관리 도구 환경 내의 예시적인 프로세싱 흐름을 그래픽으로 나타낸다. 본 기술분야의 당업자는, 소정의 프로세싱이, 청구의 범위의 범위로부터 벗어나지 않고 아래에서 설명된 컴포넌트와는 상이한 컴포넌트에 의해 수행될 수 있다는 것을 이해할 것이다. 관리 도구 프레임워크의 컴포넌트들 내에서 실행되는 프로세싱을 설명하기 전에, 관리 도구 프레임워크 내에서 사용되는 cmdlets에 대한 예시적인 데이터 구조를 기술한다.

Cmdlet 객체들을 위한 예시적인 데이터 구조들

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

제공자 cmdlet(600)(이후부터, cmdlet(600)으로 나타냄)는 cmdlet 클래스(602)로부터 유도되는 공개 클래스(public class)이다. cmdlet(600)은 "<command name>"의 자리에 지정된 cmdlet 클래스 명칭을 포함한다. 소프트웨어 개발자는, "get/process", "get/db", "format/table" 등과 같은 동사/명사 쌍(verb/noun pair)(606)을 cmdlet(600)와 연관시키는 cmdletDeclaration(604)을 지정한다. 동사/명사 쌍(606)은 관리 도구 환경 내에 등록된다. 동사 또는 명사는 암시적일 수 있다. 명칭을 갖는 커맨드 스트링(예를 들면, get/db)이 커맨드 라인 또는 스크립트 내의 입력으로서 공급되는 경우, 구문분석기는 cmdlet 레지스트리를 찾아서 cmdlet(600)을 식별한다.

cmdlet(600)는 cmdlet에 대한 예상 입력 파라미터들을 위한 문법을 정의하는 문법 메카니즘과 연관된다. 문법 메카니즘은 cmdlet와 직접적으로 또는 간접적으로 연관될 수 있다. 예를 들어, cmdlet(600)는 직접적인 문법 연관을 나타낸다. cmdlet(600)에서, 하나 이상의 공개 파라미터들(예를 들면, Name(630) 및 State(632))가 선언된다. 각 공개 파라미터(630, 632)는, 입력 속성(631, 633)과 같은 하나 이상의 속성 유형들과 연관될 수 있다. 입력 속성(631, 633)은, 공개 파라미터들(630, 632)가 각각 실장되는 방식을 지정한다. 예를 들어, 공개 파라미터는, 커맨드들의 파이프라인 내의 다른 cmdlet에 의해 발행된 객체, 커맨드 라인 등으로부터 실장될 수 있다. 공개 파라미터들이 다른 객체들로부터 실장되면, cmdlet(600)는 제1 메소드(640)(예를 들면, StartProcessing) 및 제2 메소드(642)(예를 들면, processRecord)를 포함한다. 코어 엔진이 제1 및 제2 메소드들(640, 642)를 사용하여 cmdlet(600)의 프로세싱을 지시한다. 예를 들어, 제1 메소드(640)가 한번 실행될 수 있고 셋업 기능들을 수행할 수 있다. 제2 메소드(642) 내의 코드가, cmdlet(600)에 의해 처리될 필요가 있는 각 객체(예를 들면 record)에 대해 실행될 수 있다. cmdlet(600)은 cmdlet(600) 이후에 깨끗이 하는 제3 메소드(도시 안됨)을 포함할 수도 있다. 대안적으로, 문법 메카니즘은, XML 문서와 같은, 외부 소스에 정의된 공개 파라미터들의 기술을 사용하여 cmdlet와 간접적으로 연관될 수 있다. 그 후, 이러한 외부 소스 내의 파라미터들의 기술은 cmdlet에 대한 입력 객체들의 구문분석을 드라이브한다.

따라서, 도 6에 도시된 바와 같이, 제2 메소드(642) 내의 코드는 통상적으로 상당히 짧고, 구문분석 코드, 데이터 확인 코드 등과 같은 전통적인 관리 도구 환경에 필요한 기능을 포함하지 않는다. 따라서, 시스템 관리자들은 복잡한 프로그래밍 언어를 배우지 않고 복잡한 관리 태스크들을 개발할 수 있다.

데이터 구조(600)는 입력 파라미터로 인식되지 않는 개인 구성요소(650)를 포함할 수도 있다. 개인 구성요소(650)는 cmdlet 내에 생성되는 데이터를 저장하 는데 사용될 수 있다.

관리 도구 환경 내의 예시적인 프로세스 흐름이 지금부터 설명된다.

Cmdlet의 예시적인 원격 프로세싱

도 7은 본 발명과 함께 설명되는 메카니즘들을 활용하는 원격 컴퓨팅 환경(700)을 일반적으로 도시하는 기능 블록도이다. "관리기"(710) 컴퓨팅 시스템 및 원격 컴퓨팅 시스템(이후부터, 원격 서버(720)로 나타냄)이 도시되어 있다. 원격 서버(700)는 물리적으로 임의의 곳에 위치할 수 있고 피고용인 또는 가입자과 같은 최종 사용자에 의해 사용되는 개별 컴퓨팅 시스템일 수 있다. 도 7이 단일 원격 서버(720)를 도시하지만, 원격 컴퓨팅 환경(700)은 임의 개수의 원격 서버를 포함할 수 있다. 각 원격 서버는 원격 서버(720)를 참조하여 아래에 설명되는 프로세싱을 수행한다.

관리기(112) 및 원격 서버(720)는 도 1에 도시된 컴퓨팅 장치(100)와 같은 컴퓨팅 장치들일 수 있다. 관리기(112)는, 원격 서버(720)를 유지하기 위해 시스템 관리자 등에 의해 사용된다. 즉, 관리기(112)는 커맨드들을 작동시키고 원격 서버(720)의 상태 또는 사정을 질의할 수 있는 태스크들을 수행하거나 및/또는 원격 서버(720)를 변경시킨다. 관리기(112)는, 도 2에 도시된 관리 도구 프레임워크(200)의 수개의 컴포넌트들을 포함할 수 있는 실행 환경을 포함한다. 특히, 관리기(112)는 원격 인터페이스(714) 및 기본 유형들의 리스트(712)를 포함한다. 일 실시예에서, 기본 유형들의 리스트(712)는 2개의 컬럼들: 객체의 유형을 목록화하는 제1 컬럼 및 유형과 연관된 특정 직렬화기(serializer)를 참조하는 제2 컬럼을 갖는 표를 포함한다. 관리 도구 프레임워크(200) 내의 다른 컴포넌트들도 cmdlets의 원격 프로세싱을 수행하는데 활용될 수 있지만, 다음의 설명은, "Rcmd machine:RemoteServer Get/DB"와 같은 원격 cmdlet를 처리하기 위해, 관리기(112)와 원격 서버(720) 간의 상호작용에 초점을 맞추고, 이러한 문맥에서, 필요하면, 다른 컴포넌트들의 동작을 설명한다. 또한, 다음의 예는 하나의 cmdlet의 원격 프로세싱을 도시한다. 그러나, cmdlets의 파이프라인이 존재하면, 원격 양상들도 동등하게 작용한다.

원격 서버(720)는 원격 에이전트(724)를 포함한다. 원격 에이전트(724)는 하나 이상의 cmdlets를 실행하기 위해 원격 요청들에 응답하는 컴포넌트이다. 또한, 원격 에이전트(724)는, 하나 이상의 cmdlets의 실행 결과들을 취하고 요청 엔티티(예를 들면, 관리기(112))로 되돌아가는 리턴 패키지(730)을 생성한다. 일 구현에서, 패키지는, 실행 결과뿐만 아니라 결과들이 발원되는 특정 원격 시스템에 대한 정보 및 요청 엔티티에 대한 정보를 식별하는, 호출(invocation) 날짜와 시간과 같은, 메타 정보를 포함하는 직렬화된 객체의 형태를 취한다. 이러한 정보 및 아마도 다른 정보는 리턴 패키지(730)에 포함되고 요청 엔티티(예를 들어, 관리기(112))로 다시 전송된다.

주의할 중요한 부분은, 요청 엔티티는 컴퓨팅 시스템 상에서 실행하는 하나의 프로세스일 수 있고 원격 서버는 동일한 컴퓨팅 시스템 상에서 동작하는 다른 프로세스일 수 있다는 것이다. 이러한 구성에서, 통신 인터페이스(740)는, 본 기술 분야의 당업자에게 잘 알려져 있는 2개의 프로세스들 간의 통신을 위한 시스템 레벨 API(application programming interfaces)를 포함한다. 다른 실시예에서, 통신 인터페이스(740)는 인터넷 또는 인트라넷 네트워크를 포함한다.

도 8은 cmdlets를 실행하기 위한 프로세스(800)에 의해 실행될 수 있는 단계들을 일반적으로 도시하는 논리적 흐름도이다. 프로세스는, cmdlets가 실행을 위해 커맨드 라인 등을 통해서와 같이 입력되는 판정 블록 806에서 시작한다. 예를 들어, cmdlet, "Rcmd machine:RemoteServer Get/DB"가 입력될 수 있다. 판정 블록 806에서, 실행이 원격 경계를 횡단하는지 여부를 결정하기 위해 cmdlet가 실행될 위치가 결정된다. 요약하면, 각 컴퓨팅 시스템(예를 들어, 관리기(720), 원격 서버(720))는 하나 이상의 프로세스를 지원한다. 각 프로세스는 적어도 하나의 프로그램 또는 애플리케이션을 호스트(host)한다. 또한, 한 프로세스는 하나 이상의 애플리케이션 도메인들을 호스트할 수 있다. 애플리케이션 도메인들은, 다수의 애플리케이션들이 동일한 프로세스 내에서 실행될 수 있게 하는 비교적 새로운 메카니즘이며, 여전히 다른 애플리케이션과는 분리되어 있다. 애플리케이션 도메인은 런타임(runtime) 환경에 의해 애플리케이션 주위에 생성되는 논리적 및 물리적 경계이다. 각 애플리케이션 도메인은, 각각의 애플리케이션의 구성, 보안 또는 안정성이 다른 애플리케이션 도메인들 내의 다른 애플리케이션들에 영향을 주는 것을 방지한다. 따라서, cmdlet는 다음과 같은 위치들: 1) 요청 엔티티(예를 들어, 관리기)의 애플리케이션 도메인 내부; 2) 요청 엔티티와 동일한 프로세스의 다른 애플리케이션 도메인 내부; 3) 요청 엔티티 상의 다른 프로세스 내부; 또는 4) 원격 서버 상에서 실행될 수 있다. cmdlet가 다른 프로세스(번호 3) 또는 서버(번호 4) 에서 실행하면, 다음의 설명에서 이러한 것을, 프로세스 경계 외부에서 실행하는 것을 일반적으로 의미하는 "원격 경계(remote boundary)"를 통해 실행하는 것으로 나타낸다.

위치를 지정하기 위해, 일 실시예에서, cmdlet와 함께 지정된 파라미터는 cmdlet를 실행할 위치를 식별한다. 예를 들어, 관련 노드 명칭과 함께 파라미터 "-node"는 노드 명칭과 연관된 원격 서버 상에서의 cmdlet의 실행을 지시할 수 있다. 파라미터 "-workerprocess"는 요청 엔티티의 다른 프로세스에서의 cmdlet의 실행을 지시할 수 있다. 파라미터 "-appdomain"은 동일한 프로세스의 다른 애플리케이션 도메인 내에서의 cmdlet의 실행을 지시할 수 있다. 동일한 애플리케이션 도메인 내부 또는 동일한 프로세스 내의 다른 애플리케이션 도메인 내부에서 실행되면, 프로세싱은 블록 808로 진행한다. 그렇지 않은 경우 프로세싱은 블록 818로 진행한다. 블록 808-814의 프로세싱은 원격 프로세싱의 이해에 필수적이지 않지만, 이러한 프로세싱을 이해함으로써 cmdlets의 원격 프로세싱을 지원하기 위해 극복되는 제반사항을 이해하는데 도움이 된다.

블록 808에서, cmdlet와 연관된 파일이 식별된다. cmdlet의 식별 및 그의 연관된 파일은 쓰루 등록(thru registration)일 수 있다. 도 6와 함께 상술한 바와 같이, 파일은 cmdlet를 실행하기 위한 코드를 포함하고 또한 cmdlet 클래스와 연관된 특성들 및 메소드들을 포함한다.

블록 810에서, 파일은 현재 애플리케이션 도메인을 위한 프로세스로 로딩된다. 파일이 소정의 알려지지 않고 신뢰되지 않은 원격 서버로부터 로딩된다면, 상 술한 바와 같이, 실행가능한 파일을 요청 엔티티 상의 프로세스로 상기와 같이 블라인드 로딩(blind loading)하는 것은 보안상의 위험을 불러 일으킨다. 블록 820-834와 함께 설명될 것과 같이, 이러한 보안 위험은, 원격 경계들 사이에서 객체들을 전송하는 본원의 방법을 활용하여 극복된다.

블록 812에서, cmdlet가 실행된다. 실행은, cmdlet 객체를 생성하기 위해 cmdlet 클래스를 인스턴스화하는 것, cmdlet 클래스 내에 지정된 방식으로 cmdlet 객체 내에 지정된 특성들을 실장하는 것, cmdlet 클래스의 코드 내에 정의된 객체들을 생성하는 것을 포함한다. (파이프라인화된 커맨드 내의 이전의 cmdlet로부터의 객체들과 같이) 인입 객체들이 현재 cmdlet 클래스에 지정된 유형과 일치하지 않으면, 확장형 관리기가 필요한 유형을 강제시킨다. 프로세싱은 블록 814로 진행한다.

블록 814에서, 프로세스는, 임의의 특성들을 액세스하고 임의의 메소드들을 불러옴으로써 생성된 객체들을 다룰 수 있다. 이렇게 생성된 객체들을, 객체의 메소드들이 가용하고 호출될 수 있기 때문에, "라이브(live)" 또는 "가공되지 않은(raw)" 객체들로 표현된다.

상상할 수 있는 바와 같이, 블록 808-814에서 설명된 프로세싱은, cmdlet가 원격 컴퓨터 상에 위치되는 경우보다 덜 이상적이다. 원격 파일이 실행을 위해 로컬 프로세스로 로딩되었다면, 원격 파일이 부당한 코드를 실행할 가능성이 있고, 이는 요청 엔티티의 보안을 위태롭게 할 수 있다. 또한, 관리 도구 환경에서, 요청 엔티티(예를 들어 관리기)는 일반적으로 원격 컴퓨터에 대한 관리 정보를 얻는 데 관심이 있다. 따라서, cmdlet에 의해 실장된 객체들은 요청 엔티티(예를 들어 관리기)가 아니라 원격 서버에 대한 관련 상태 또는 다른 정보를 포함하여야 한다.

배경 섹션에서 설명된 바와 같이, 전통적인 웹 서비스 환경에서는, 클라이언트가 통신하기를 원하는 원격 서버를 인지하고 신뢰할 책임이 있다. 그러나, 상술한 바와 같이, 특정 인터페이스를 지원하는 객체들만이 요청 엔티티와 통신할 수 있기 때문에, 이는 클라이언트가 통신하기를 원하는 대상을 크게 제한한다. 요청 엔티티(예를 들어 관리기)와 원격 서버 사이에서 객체들을 전달하기 위한 본원의 방법은 이러한 한계를 가지지 않고 지금부터 설명한다. 편리하게, 원격 엔티티(예를 들어 원격 서버 또는 개별 프로세스) 상에서 프로세싱을 실행하는 블록들은 "점선" 백그라운드로 도시된다.

판정 블록 806으로 되돌아가서, cmdlet가 다른 프로세스에서 동작하거나 원격 서버 상에서 동작하면, 프로세스는 블록 818로 진행한다. 블록 818에서 클라이언트는 원격 엔티티와 연관된 원격 에이전트와 통신을 확립한다. 그 다음, 원격 에이전트는, 블록 810-812에 대해 상술한 기능을 수행하는, 블록 820-824를 실행하나, 대신 그들을 원격 엔티티에 대해 실행한다. 그러나, cmdlet가 실행되고 그의 연관된 객체들을 얻으면, 프로세싱은 블록 826으로 계속된다.

블록 826에서, 객체들은, 요청 엔티티(예를 들면, 관리기)의 보안이 손상되지 않는 방식으로 직렬화된다. 직렬화 프로세스는, 도 7에 도시된 리턴 패키지(730)과 같은 리턴 패키지를 생성한다. 요약하면, 객체들을 직렬화하는 것은, 요청 엔티티에 위험이 되지 않을 수 있는 방식으로 정보를 직렬화한다. 직렬화 프로 세스의 개요가 도 9에 도시되어 있고 직렬화 프로세스에 대한 보다 상세한 설명은 도 10과 함께 아래에서 설명된다. 프로세싱은 블록 828로 계속된다.

블록 828에서, 직렬화된 객체들은 클라이언트 컴퓨터로 전송된다. 직렬화된 객체들의 전송은 네트워크 통신에 대해 알려진 종래 방법들을 사용하여 실행될 수 있거나 또는 요청 엔티티 및 원격 서버가 동일한 컴퓨터 상에 있다면, 알려진 프로세스간 통신을 사용할 수 있다. 프로세싱은 블록(830)으로 계속된다.

블록 830에서, 직렬화된 객체들은 요청 엔티티에 수신된다. 직렬화된 객체 유형은 확장형 관리기에 등록된 유형이다. 따라서, 수신 시, 확장형 관리기는 직렬화된 객체 유형을 인식한다. 프로세싱은 블록 832로 계속된다.

블록 832에서, 직렬화된 객체는 서버-컴포넌트 객체들로 역직렬화된다. 간략히 말하면, 역직렬화 프로세스는 직렬화된 객체를 알려진 기본 유형들로 분해한다. 기본 유형이 아닌 임의의 특성에 대해, 역직렬화는 특성을 특성 백에 보관한다. 역직렬화 프로세스의 개요는 도 9에 도시되어 있고 역직렬화 프로세스에 대한 보다 상세한 설명은 도 11과 함께 아래에 설명된다. 프로세싱은 블록 834로 계속된다.

블록 834에서, 기본 유형들중 하나인 역직렬화된 객체들은, 객체와 연관된 메소드들 및 특성들이 가용하다는 것을 의미하는, "가공되지 않은(raw)" 객체로 다루어진다. 기본 유형들중 하나가 아닌 역직렬화된 객체들은, "가공되지 않은" 객체로 다루어지지 않는다. 이러한 객체들은, 객체에 대한 소정의 특성들에 관한 정보를 객체가 포함하나 그들의 메소드들은 가용하지 않은 "역직렬화된" 객체들로 표 현된다.

도 9는 도 8의 사용에 적합한 직렬화 프로세스 및 역직렬화 프로세스의 일반적인 개요를 나타내는 블록도이다. 일반적으로, 직렬화 프로세스(900)는 원격 엔티티 상에서 실행하는 cmdlet에 의해 생성된 객체(902)를 계층구조 트리(904)로 변환시킨다. 일반적으로, 계층구조 트리(904)는 서브-컴포넌트들로 분해된 객체(902)를 표현하는 객체이다. 서브-컴포넌트들중 일부는 양쪽 엔티티들(예를 들면 요청 엔티티 및 원격 엔티티)에 의해 알려진 객체 유형들이다. 이러한 알려진 유형들은, 요청 엔티티 및 원격 엔티티 상의 기본 유형 리스트(712, 722) 내에서 각각 식별된다(도 7 참조). 기본 유형들(712, 722)이 동일한 기본 유형 리스트를 포함하지 않는 경우, 도 13과 함께 아래에서 설명된 프로토콜 절충 프로세스가 수행되어 기본 유형 리스트중 어느 것을 사용하는지를 결정한다. 따라서, 도 10과 함께 아래에서 보다 자세하게 설명되는 바와 같이, 계층구조 트리 내의 각 엔트리가 직렬화되고 직렬화된 객체(906)에 부가된다. 일 실시예에서, 직렬화된 객체(906)는 XML 문서를 포함한다. 상기 직렬화된 객체는, 다른 정보와 함께, 결합되어, 요청 엔티티로 전송되는 요청 패키지를 형성한다.

요청 패키지를 수신한 경우, 요청 엔티티는 직렬화된 객체(906)를 검색하고 역직렬화 프로세스(910)를 수행한다. 일반적으로, 역직렬화 프로세스(910)는 계층구조 트리(904)를 재구성한다. 계층구조 트리(904)가 확장형 관리기에 의해 인식된 객체 유형들중 하나이기 때문에, 확장형 관리기는 계층구조 트리(904)를 기본 객체들 및/또는 특성 백 객체들(912)로 분해한다. 기본 객체들은, 기능(예를 들 면, 메소드들)을 가지는 "라이브"(즉 "가공되지 않은") 객체들이다. 특성 백 객체들(912)(즉, "역직렬화된" 객체들)은 관련 데이터를 제공하나, 메소드들을 포함하지 않는다. 따라서, 이러한 개요가 설명하는 바와 같이, 원격 엔티티 상에서 본래 생성된 객체(902)는, 요청 엔티티의 보안에 위태롭게 하거나 또는 객체(902)에 대한 임의의 특별한 인터페이스를 요구하지 않고, 다수의 "가공되지 않은" 기본 객체들 및 다른 "역직렬화된" 객체들로서 요청 엔티티로 전송된다. 이러한 역직렬화 프로세스(910)는 도 11과 함께 보다 상세하게 설명된다.

도 10은 객체들을 직렬화하는 예시적인 프로세스(900)를 나타낸다. 상술한 바와 같이, 일반적인 개요로서, 직렬화 프로세스(900)는 객체 및 그의 특성들(특성들은 또한 객체들임)을 알려진 기본 유형들 및 가능한 경우 하나 이상의 특성 백으로 분해한다. 프로세스(900)는 본래 반복적(recursive)이고 객체들(특성들을 포함함)이 기본 유형들중 하나로 분해될 때까지 또는 남은 객체 각각이 알려진 기본 유형들에 목록화되지 않을 때까지 계속된다. 직렬화 프로세스(900)가 반복적이고 관리하기 어려운 계층구조 트리를 생성하기 때문에, 프로세스(900)는 아래에 설명되는 몇몇의 서로 다른 기술들을 사용하여 제한될 수도 있다. 프로세스(900)의 보다 나은 설명을 위해, 다음의 설명은, "get/DB" cmdlet에 의해 가상적으로 생성된 예시적인 객체(예를 들면, SQLInfo 객체)를 사용한다. 일반적으로, SQLInfo 객체는 종래의 방법들중 임의의 방법으로 정의될 수 있다. 다음의 이러한 종래 방식들중 하나이다:

도 12는 프로세스(900) 동안 생성된 계층구조 트리의 일부를 그래픽으로 표현한다. 계층구조 트리는 상기 도시된 SQLInfo 객체의 분해된 부분을 나타내고 직렬화 프로세스를 설명하기 위해 도 9와 함께 사용될 것이다.

프로세스(900)는, 원격 cmdlet에 의해 생성된 객체가 생성되는 블록 1002에서 시작한다. 블록 1002에서, 요청 엔티티 및 원격 엔티티가 통신할 수 있는 레벨을 식별하기 위해 프로토콜 절충 프로세스가 실행된다. 간단히 말해, 도 13과 함께 나중에 상세하게 설명되는 바와 같이, 엔트리들이 통신하는 레벨은, 객체를 전송하기 위해 요청 엔티티로 전송되는 정보량을 결정한다. 설명되는 바와 같이, 프로토콜 절충 프로세스는, 요청 엔티티 및 원격 엔티티 모두 서로에 무관하게 그들의 시스템을 업그레이드시킬 수 있게 하며, 또한 그들이 서로 다른 버젼을 사용하여 서로 통신할 수 있게 한다. 실제로, 이러한 것은, 원격 엔트리 상의 버젼보다 몇년 더 새로운 버젼의 기본 유형들로 동작하는, 요청 엔티티에게 여전히 원격 엔티티와 통신할 수 있게 한다. 그 역도 참이다. 따라서, 여러해 전에 수송된 시스 템들이 보다 새로운 관리기 컴퓨터들에 의해 관리될 수 있다. 절충 프로세스의 출력은, 절충된 기본 유형들 각각을 식별하는 절충된 리스트이다. 통신 레벨이 결정되면, 프로세싱은 블록 1004로 계속된다.

블록 1004에서, 객체에 대한 정보를 보유하기 위해 특성 백이 생성된다. 일 실시예에서, 특성 백은 해시표(hash table)로 구현될 수 있다. 특성 백은 관리 도구 환경에 의해 지원되는 코어 데이터 유형이다. 프로세싱은 블록 1006으로 계속된다.

블록 1006에서, 객체의 유형은 객체를 리플렉션시킴으로써 식별된다. 유형이 식별되면, 프로세싱은 판정 블록 1008로 계속된다. 판정 블록 1008에서, 식별된 객체 유형을 절충된 기본 유형들이 포함하는지 여부가 판정된다. 이러한 판정은 절충된 리스트 내의 룩-업(look-up)으로 구현될 수 있다. 이러한 구현에 있어, 절충된 리스트는 절충된 기본 유형들 각각을 식별한다. 객체가 절충된 기본 유형들중 하나로 식별되면, 프로세싱은 블록 1010으로 계속된다.

블록 1010에서, 식별된 객체에 대해 엔트리가 특성 백 내에 생성된다. 특성 백의 예시적인 구현은 지금부터 설명될 것이다.

도 12로 잠시 돌아가면, 예시적인 계층구조 트리의 일부에 대한 그래픽 표현(예를 들면, 특성 백 트리)가 도시된다. 일부는 계층구조 트리 내의 2개 레벨: 특성 백(1220)을 갖는 제1 레벨; 서브-특성 백(1240)을 갖는 제2 레벨을 나타낸다. 각 특성 백(1220, 1240)은 명칭 필드(1202), 값 필드(1204) 및 유형 필드(1206)를 포함한다. 또한, 각 특성 백(1220, 1240)은 IsType 필드(1208), WasType 필드 (1210) 및 TreatAs 필드(1212)를 포함할 수 있다. 특성 백(1220)은 엔트리들(1222-1230)을 포함하고 서브-특성 백(1240)은 엔트리들(1242-1248)을 포함한다.

도 10으로 돌아가서, 블록 1010에 대해 상술한 바와 같이, 객체에 대한 엔트리가 특성 백(1220)(예를 들면, 엔트리(1222))에 생성된다. 그 후, 엔트리에 대한 각 필드는 객체에 관한 정보로 갱신된다. 예를 들어, 객체에 대한 명칭(예를 들면 "EmployeeName")이 명칭 필드(1202)에 입력된다. 특성에 대한 값(예를 들면 28731)이 값 필드(1204)에 입력된다. 객체의 유형(예를 들면, "Int")이 유형 필드(1206)에 입력된다. 일 실시예에서, 명칭 필드는 해시표에 대한 키일 수 있다. 프로세싱은 블록 1012로 계속된다.

블록 1012에서, 객체는 직렬화된다. 직접 직렬화는 기저의 컴포넌트 프레임워크에 의해 제공된 메카니즘들 또는 기본 유형에 대해 지정된 코드 등에 의해 발생한다. 객체에 대한 직렬화 프로세스는 그의 기본 유형에 의존한다. 각 기본 유형은 자신의 특별한 직렬화 프로세스를 가진다. 일 실시예에서, 특별한 직렬화 프로세스가 절충된 리스트 내에서 식별된다. 상기 실시예에서, 절충된 리스트는 리스트 내의 절충된 기본 유형 각각에 대해 특별한 직렬화 프로세스에 대한 참조를 포함한다. 일 실시예에서, 직접 직렬화는 객체를 XML로 변환시킨다. 그러나, 직접 직렬화는, 첨부된 청구의 범위에서 벗어나지 않고, 객체를 XML 이외의 다른 포맷들로 변환시킬 수 있다. 특별한 직렬화 프로세스의 결과는 직렬화된 객체 내에 저장된다.

판정 블록 1008로 돌아가서, 객체가 절충된 기본 유형들중 하나로서 식별되 지 않는다고 판정되면, 프로세싱은 블록 1014로 계속된다. 블록 1014에서, 특성 백 유형은 유형 필드(1206)에 입력된다. 그 다음, 이러한 특성 백 유형은 블록 1016에서 생성된 서브-특성 백(예를 들면, 서브-특성 백(1240))을 참조한다.

블록 1016에서, 서브-특성 백(예를 들면, 서브-특성 백(1240))이 생성된다. 따라서, 서브-특성 백들의 추가 레벨들을 생성함으로써, 특성 백 트리가 형성된다. 서브-특성 백은 특성 백에 대해 정의된 것과 동일한 필드들을 가진다. 이러한 서브-특성 백은, 특성 백들의 계층구조 트리 내의 다른 레벨을 생성하는 하나 이상의 서브-특성 백들에 대한 엔트리를 가질 수도 있다. 프로세싱은 블록 1020으로 계속된다.

블록 1020에서, 직렬화 프로세스의 반복적인 성질이 그래픽으로 표현된다. 직렬화 프로세스는 객체 내의 원하는 각 특성을 직렬화하는 것에 초점을 맞춘다. 통상적으로, 원하는 특성들은 공개적으로 지정된 특성들이다. 그러나, 소정의 경우, 감춰진 특성들 및 다른 특성들이 원하는 특성들일 수 있고, 직렬화될 수도 있다. 블록들 1022-1032은, 다양한 순서들로 실행될 수 있고, 소정의 경우, 하나 이상의 블록들(예를 들어, 블록 1032)이 선택적으로 실행될 수 있다. 블록 1022-1032 각각이 지금부터 추가로 설명된다.

블록 1022에서, 원하는 특성에 대한 유형이 식별된다. 블록 1006을 참조하여 상술한 바와 같이 리플렉션들 통해 이러한 것이 다시 발생한다.

블록 1024, 현재 특성 백 내의 엔트리(예를 들면, 서브-특성 백)가 특성에 부가된다.

블록 1026에서, 원하는 특성과 연관된 엔트리 내의 필드들이 설정된다. 필드들은 블록 1010에 대해 상술한 바와 같이 설정되나, 특성 백보다는 오히려 서브-특성 백 내에 설정된다. 예를 들어, 도 12에 도시된, 서브-특성 백(1240) 내의 엔트리(1242)에 대한 필드들이 특성(객체)에 연관된 정보로 업데이트된다.

블록 1028에서, 원하는 특성이 절충된 기본 유형들중 하나이면, 특성들은 블록 1012에 대해 상술한 바와 같이 직접적으로 직렬화된다.

블록 1030에서, 원하는 특성이 절충된 기본 유형들중 하나가 아니라면, 블록 1014 및 1020이 반복 형식으로 실행된다.

이러한 반복 프로세스때문에, 특성 백들의 계층구조 트리는 관리하기 어려워진다. 따라서, 직렬화 프로세스(900)를 제한하는 것이 바람직할 수 있다. 직렬화 프로세스를 제한하는 실시예들은 블록 1032 내에 나타나 있고 선택적으로 실행될 수 있다. 계층구조 트리를 선택하는 몇몇 실시예들이 있다. 일 실시예에서, 계층구조 트리의 소정의 깊이를 지정하는 정책이 설정될 수 있다. 예를 들어, 소정의 깊이가 2로 설정되면, 특성 백으로부터 참조된 하나 이상의 서브-특성 백들을 생성한 후, 직렬화 프로세스의 반복적인 성질이 중단된다. 직렬화 프로세스(900)는 서브-특성 백들 내의 객체들을 더이상 분해하지 않는다. 따라서, 이러한 서브-특성 백들은 특성 백으로 직렬화되고 직렬화된 객체 내에 포함된다.

다른 실시예에서, 직렬화 이전에, 원격 에이전트가, 지정되지 않은 특성들을 벗겨 내는 "픽(pick)" 프로세스를 통해 객체를 동작시킨다. 예시적인 신택스는 다음과 같다: >Rcmd machine:RemoteServer Get/DB | Pick Name, Birthdate. 그 후, 직렬화 동안, 지정된 특성들(예를 들면, 명칭 및 생일)는 원하는 특성들이 되고 상술한 바와 같이 직렬화된다. 픽 프로세스는 모든 시스템에 가용한 다른 cmdlet일 수 있다. 특성들을 픽 프로세스로 명시적으로 지정할 경우의 한가지 단점은, 픽 리스트가 매번 지정되어야 하고 그들을 집어 내기 위해서는 원하는 특성들을 알아야 한다는 것이다.

또 다른 실시예에서, 블록 832는 특성 설정 메카니즘을 사용할 수 있다. 특성 설정 메카니즘은, 특성 세트에 대해 명칭이 정의될 수 있게 한다. 그 후, 원하는 특성 세트를 얻기 위해, 관리자가 특성 설정 명칭을, cmdlet와 함께 지정할 수 있다. 특성 세트는 다양한 방식으로 정의될 수 있다. 한가지 방식은, "?"와 같은 소정의 파라미터가 cmdlet에 대한 입력 파라미터로 정의될 수 있다. 미리 정의된 파라미터를 인식하는 경우, 동작 환경은 객체의 모든 특성들을 목록화할 수 있다. 리스트는, 관리자가, 원하는 특성을 체크하고(예를 들어 "클릭 온(click on)") 특성 세트를 명명할 수 있게 하는 GUI일 수 있다. 그 후, 특성 세트 정보는 확장형 메타데이타에 저장된다. 예를 들어, 특성 세트가 "성능(performance)"으로 명명될 수 있다. 그 다음, 각 객체는 이러한 성능 특성 세트에 특성들중 어느 특성이 포함되어야 하는지를 식별한다. 따라서, 관리자는 특성들의 명칭을 알 필요가 없고, 오히려 원하는 특성 세트의 명칭을 알기만 하면 된다. 객체에 대해 직렬화를 하기 위해 원하는 특성들을 지정하는 "디폴트(default)"로 명명된 특성 세트가 정의될 수 있다. 그 후, 관리자는 직렬화가 필요한 경우 디폴트 특성을 지정할 수 있다.

특성 백 계층구조 트리를 제한하는 다른 방법은, 단지 소정의 유형들을 지원 하고 소정의 유형들로부터 유도된 유형들을 강제로 해당 유형에 맞추는 것이다. 일 구현에서, 객체 계층구조는 그의 부모를 식별하기 위해 각 객체를 리플렉팅함으로써 "워크 다운(walked down)"된다. 소정의 객체들에 대해, 기본 유형으로부터 유도되면, 객체는 강제로 그의 부모 유형이 될 것이다. 예를 들어, 해시표 객체는, 기본 객체로부터 유도되는, IEnumberable 객체인, Idictionary 객체이다. 직렬화 프로세스는 해시표 객체를 IEnumberable 객체로 취급할 수 있다. 이러한 방식으로, 직렬화 프로세스는 객체 계층구조 내의 소정의 레벨들에서 객체들을 완전히 지원할 수 있으나, 객체 계층구조 내의 다른 유형들의 객체들을 선택된 유형으로 강제로 일치시킨다. 실제로, 본래 객체 유형이 전달되지 않더라도, 정보가 수신 컴퓨터에서 얻어지면, 수신 컴퓨터는 필요한 경우 본래 객체를 얻기 위해 (키를 생성하는 것과 같은) 프로세싱을 수행할 수 있다.

직렬화 프로세스(900)가 완료되면, 직렬화된 객체는, 다른 정보와 함께, 결합되어 요청 엔티티로 전송되는 요청 패키지를 형성한다.

특성 백 및 서브-특성 백들은, IsType 필드(1208), WasType 필드(1210) 또는 TreatAs 필드(1212)와 같이, 직렬화 프로세스 동안에 설정된 추가 필드들을 가질 수 있다. 이러한 유형들은 역직렬화 프로세스(910) 동안에 사용된다. IsType 필드(1208)는 객체에 대한 유형을 식별한다. 그러나, 객체가 직렬화되는 경우, 객체에 대한 IsType 필드(1208)는 "널(NULL)"이 된다. WasType 필드(1210)는 변경되기 전에 과거의 특성의 유형을 식별한다. 이러한 정보로부터, 역직렬화 프로세스(900)는, 객체가 발원된 위치를 식별할 수 있으나, 객체가 현재 얼마나 많은 특성 들을 가지고 있는지에 대해서는 알지 못한다. 예를 들어, 객체를 직렬화하는 경우 특성 세트 또는 픽 프로세스가 사용되었다면, 전체가 아닌 단지 특성 특성들만이 직렬화되었다. TreatAs 필드(1210)는 유형을 식별하고 해당 유형과 연관된 특성들이 가용한지를 보장한다. 예를 들어, 상기 특성 세트 예를 사용하면, 새로운 객체 유형을 "SQLInfoPersonal"로 정의할 수 있다. 이러한 새로운 유형은, 집 주소, 집 전화번호 등과 같은, 객체와 연관된 지정된 특성들이 가용하다는 것을 보장한다. TreatAs로 자격을 부여하기 위해 필요한 모든 특성들을 포함하도록 충분한 특성들이 지정된다면, 직렬화 프로세스(900)는 정확한 유형을 TreatAs 필드(1210) 아래에 입력할 것이다.

도 11은 도 8에 도시된 cmdlet의 프로세싱에 사용하는데 적합한, 객체들을 역직렬화하기 위한 예시적인 프로세스를 도시하는 논리적 흐름도이다. 일반적으로, 전송된 객체들을 역직렬화하는 것은, 직렬화 프로세스와 반대 동작들을 수행한다. 프로세싱은, 특성 백 표시자가 전송된 데이터 내에서 식별되는 블록 1102에서 시작한다. 일 실시예에서, 표시자는 XML 문서 내의 엘리먼트일 수 있다. 프로세싱은 블록 1104로 계속된다.

블록 1104에서, 전송된 데이터 내에 포함된 정보로 실장될 특성 백 객체가 생성된다.

블록 1106에서, 특성 백 객체에 대한 유형 특성이 설정된다. 유형 특성은, 확장형 관리기가 필요할 경우 특성 백을 처리할 수 있도록 확장형 관리기에 통지한다.

블록 1108에서, 전송된 데이터 내에 식별되고 특성 백과 연관된 각 엘리먼트가 처리된다. 블록 1110에서, 특성 백 내의 엔트리가 생성된다. 블록 1112에서, 특성 백 내의 필드들이 실장된다. 프로세싱을 판정 블록 1114로 계속된다.

판정 블록 1114에서, 다른 특성 백이 전송된 데이터 내에 정의되는지 여부에 대한 판정이 이루어진다. 전송된 데이터 내에 정의된 다른 특성 백이 존재하면, 프로세싱은, 전송된 데이터가 임의의 더 많은 특성 백들을 포함하지 않을때까지 블록 1102-1108을 통해 다시 반복실행된다.

그러나, 더이상 특성 백들이 존재하지 않으면, 프로세싱은 블록 1120-1140로 계속된다. 특성 백들의 계층구조 트리가 생성되면, 각 특성 백은 추가의 프로세싱을 위해 리뷰된다.

블록 1120에서, 특성 백에 대한 유형 특성이 기본 유형들중 하나이면, 역직열화 프로세스는 식별된 유형의 객체를 인스턴스화하고(블록 1122) 객체의 특성들을 실장한다(블록 1124).

블록 1130에서, 특성 백에 대한 TreatAs 속성이 유형을 지정하면, 지정된 유형의 객체가 인스턴스화되고(블록 1132) 객체의 특성들이 실장된다(블록 1134). TreatAs 속성에 지정된 유형이 기본 유형들중 하나이다.

블록 1140에서, 기본 유형이 아닌 남은 특성 백 각각에 대해, 특성 백 내의 식별된 각 객체가 인스턴스화되고(블록 1142) 실장된다(블록 1144).

따라서, 알 수 있는 바와 같이, 원격 컴퓨터에서 생성된 본래의 객체가 기본 유형이면, 전송된 데이터는 최소한의 정보를 포함한다. 이는, 단지 한 레벨을 갖 는 계층구조 트리에 대응한다. 전송된 데이터는 특성들에 대한 명칭/값 쌍들을 포함하나, 임의의 실행가능한 코드를 포함하지 않는다. 그러나, 요청 컴퓨터가 전송된 데이터를 수신하고 유형을 인식하면, 해당 유형의 객체는 인스턴스화되고 본래 객체에 의해 제공된 메소드들과 기능을 가질 것이다. 이러한 방식으로, 부당한 코드가 요청 컴퓨터에 전송되지 않고 실행되지 않을 것이다. 대신, 객체에 대한, 해가 되지 않는 정보가 요청 컴퓨터에 전송된다.

도 13은 도 9에 도시된 객체를 직렬화하는 프로세스와 함께 사용하는데 적합한 프로토콜을 절충하는 예시적인 프로세스를 나타내는 논리적 흐름도이다. 직렬화할 특정 파라미터들을 제한하거나 또는 계층구조 트리에 대한 깊이를 지정하더라도, 소정의 객체들에 대해, 2개의 컴퓨터들 간에 전송되는 정보량은 상당히 크다. 따라서, 전송이 필요한 정보량을 제한하는 추가의 절충 메카니즘이 제공된다. 상술한 바와 같이, 계층구조 트리의 복잡성은 절충된 기본 유형들의 개수에 의존한다. 많은 개수의 절충된 기본 유형들이 알려져 있는 경우, 계층구조 트리는 보다 덜 복잡해지며, 이는 결국 요청 컴퓨터로 전송되는 정보를 감소시키는 결과를 낳는다. 기본 유형을 지정하는 특성 백 내의 임의의 엔트리들에 대해, 요청 컴퓨터 상에 "가공되지 않은" 객체를 생성하기 위해 단지 최소한의 정보가 전달된다. 따라서, 더 많은 객체들을 수용하기 위해 기본 유형 리스트 내에 지정된 기본 유형들의 개수는 커질 수 있다고 생각된다. 그러나, 본 발명은 여전히 본 발명을 사용하기 위해 소프트웨어 개발자들에게 인공적인 제한이나 요구조건을 두지 않는다. 예를 들어, 소정의 종래 환경에서는, 적절히 동작하기 위해서는 양쪽 컴퓨터들이 동일한 버젼으로 업데이트되어야 한다. 이러한 종래 환경에서, 한 컴퓨터가 어느 컴퓨터가 그와 통신할 수 있는지를 지시하고 통신하기 위해 다른 컴퓨터들 상에서의 적합성(compliance)을 강제한다. 대조적으로, 객체들 전달하기 위한 본 발명은, 컴퓨터들이 서로 독립적으로 업데이트될 수 있게 하고 서로 통신할 수 있게 하는 프로토콜 절충 방법을 제공한다.

프로토콜 절충 프로세스(1300)는 블록 1302에서 시작한다. 블록 1302에서, 클라이언트 버젼 번호가 수신된다. 클라이언트 버젼 번호는, 클라이언트(예를 들어 요청 컴퓨터)가 사용할 수 있는 기본 유형 리스트의 가장 최근 버젼을 식별한다. 프로세싱은 판정 블록 1304로 계속된다.

판정 블록 1304에서, 클라이언트 버젼 번호가 원격 버젼 번호와 비교되어, 원격 버젼 번호가 보다 더 최신의 것인지를 판정한다. 원격 버젼 번호가 원격 서버가 사용할 수 있는 가장 최근 버젼의 기본 유형 리스트를 식별한다. 원격 버젼 번호가 보다 최근의 것이라면, 프로세싱은 블록 1306으로 계속된다.

블록 1306에서, 클라이언트 버젼 번호와 연관된 기본 유형 리스트가 직렬화 프로세스에 사용된다. 따라서, 클라이언트 버젼 번호는 직렬화 프로세스 동안 사용되는 절충된 리스트가 된다.

다른 한편, 원격 버젼 번호가 클라이언트 버젼 번호와 같은 최신의 것이 아니라면, 프로세싱은 블록 1308로 계속된다. 블록 1308에서, 원격 컴퓨터 상에서 가용한 가장 최신의 기본 유형 리스트가 직렬화 프로세스에 사용된다. 따라서, 원격 버젼은, 직렬화 프로세스 동안 사용되는 절충된 리스트가 된다.

절충 프로세스의 다른 실시예에서, 요청 컴퓨터는 원격 컴퓨터를 지원하는 기본 유형들을 송신할 수 있다. 그 다음, 원격 컴퓨터는 표를 검토(walk through)하고 표 내의 항목들을 수용하거나 거부함으로써 어느 유형들이 지원될 것인지를 결정한다. 그 다음 수용된 유형들이 절충된 리스트를 형성한다.

절충 프로세스의 다른 실시예에서, 요청 컴퓨터는 참조 세트를 송신할 수 있다. 참조 세트는 파일 명칭을 지정할 수 있다. 따라서, 지정된 파일 명칭 내의 임의의 유형의 객체가 지원되고 절충된 기본 유형들중 하나가 될 수 있다.

특정 구현들 및 실시예들의 상세가 상술한 바와 같이 설명되었지만, 그러한 상세들은 다음의 청구의 범위의 범주를 제한하기보다는 합법적인 개시 의무를 만족시키기 위한 것이다. 따라서, 상술한 시스템들 및 방법들은 청구의 범위에 의해 정의되며, 상술한 특정한 특징들로 한정되지 않는다. 오히려, 본 시스템 및 방법은, 등가물 원칙에 따라 적절히 해석되는 경우, 첨부된 청구의 범위의 적절한 범위 내에 해당하는 임의의 형태 또는 수정을 청구한다.

Claims (28)

1. 원격 경계를 가로질러 컴퓨터 판독가능한 객체들을 전달하기 위한 방법을 제공하는 컴퓨터 실행가능한 명령들을 갖는 적어도 하나의 컴퓨터 판독가능한 매체로서,

   상기 방법은,

   알려진 객체 유형들의 리스트에 기초하여 제1 유형의 객체를 적어도 하나의 서브-컴포넌트(sub-component)의 계층구조로 분해하는 단계 - 서브-컴포넌트 각각은 상기 알려진 객체 유형들 중 하나와 연관된 알려진 객체를 포함함 - ;

   상기 알려진 객체들을 직렬화된 패키지(serialized package)로 직렬화하는 단계; 및

   상기 직렬화된 패키지를 원격 엔티티(remote entity)로 전송하는 단계

   를 포함하는 컴퓨터 판독가능한 매체.
2. 제1항에 있어서,

   상기 리스트는 상기 제1 유형을 상기 알려진 객체 유형들 중 하나로 식별하는 컴퓨터 판독가능한 매체.
3. 제1항에 있어서,

   적어도 하나의 서브-컴포넌트는 상기 리스트 내의 식별되지 않은 유형을 갖 는 알려지지 않은 객체를 포함하는 컴퓨터 판독가능한 매체.
4. 제3항에 있어서,

   객체를 분해하는 단계는, 상기 리스트에 기초하여 상기 알려지지 않은 객체를 서브-컴포넌트들의 다른 레벨로 분해하는 단계를 더 포함하는 컴퓨터 판독가능한 매체.
5. 제1항에 있어서,

   시스템 상의 제1 프로세스는 상기 직렬화된 패키지를 전송하고 상기 원격 엔티티는 상기 시스템 상의 다른 프로세스를 포함하는 컴퓨터 판독가능한 매체.
6. 제1항에 있어서,

   시스템 상의 제1 프로세스는 상기 직렬화된 패키지를 전송하고 상기 원격 엔티티는 다른 시스템 상의 다른 프로세스를 포함하는 컴퓨터 판독가능한 매체.
7. 제1항에 있어서,

   프로세스 내에서 실행하는 제1 애플리케이션 도메인은 상기 직렬화된 패키지를 전송하고, 상기 원격 엔티티는 상기 프로세스 내의 다른 애플리케이션 도메인을 포함하는 컴퓨터 판독가능한 매체.
8. 제1항에 있어서,

   상기 계층구조(hierarchy)는 특성 백(property bag)을 포함하는 컴퓨터 판독가능한 매체.
9. 제8항에 있어서,

   상기 특성 백은 해시표(hash table)를 포함하는 컴퓨터 판독가능한 매체.
10. 제9항에 있어서,

    상기 해시표 내의 각 엔트리에 대한 키는 상기 엔트리와 연관된 상기 서브-컴포넌트에 대한 명칭을 포함하는 컴퓨터 판독가능한 매체.
11. 제8항에 있어서,

    상기 특성 백은 복수의 엔트리를 포함하고, 각 엔트리는 상기 서브-컴포넌트들중 하나와 연관되고 상기 서브-컴포넌트와 연관된 명칭을 저장하기 위한 제1 필드, 상기 서브-컴포넌트와 연관된 값을 저장하기 위한 제2 필드 및 상기 서브-컴포넌트와 연관된 유형을 저장하기 위한 제3 필드를 가지는 컴퓨터 판독가능한 매체.
12. 제1항에 있어서,

    제1 프로세스에 가용한 제1 리스트의 버젼 번호를 수신함으로써 리스트 내의 식별된 상기 알려진 객체 유형들을 절충(negotiating)하는 단계, 상기 버젼 번호 를, 상기 원격 엔티티에 가용한 제2 리스트의 다른 버젼 번호와 비교하는 단계, 및 상기 비교에 기초하여 상기 리스트를 결정하는 단계를 더 포함하는 컴퓨터 판독가능한 매체.
13. 제1항에 있어서,

    제1 프로세스로부터 수신된 복수의 객체 유형을 수용함으로써 상기 리스트를 절충하는 단계를 더 포함하고, 상기 수용된 객체 유형들은 상기 리스트 내의 식별된 알려진 객체 유형들이 되는 컴퓨터 판독가능한 매체.
14. 제1항에 있어서,

    파일에 대한 식별자를 수신함으로써 상기 리스트를 절충하는 단계 및 상기 파일 내의 식별된 객체 유형들을 포함하는 상기 리스트를 갖는 단계를 포함하는 컴퓨터 판독가능한 매체.
15. 제1항에 있어서,

    상기 계층구조에 대한 미리 결정된 깊이를 지정함으로써 서브-컴포넌트들의 상기 계층구조를 제한하는 단계를 더 포함하고, 상기 객체를 분해하는 단계는 상기 객체를 상기 미리 결정된 깊이로 분해하는 단계를 포함하는 컴퓨터 판독가능한 매체.
16. 제1항에 있어서,

    상기 객체의 개별적인 특성들을 식별하는 특성 세트를 정의함으로써 서브-컴포넌트들의 상기 계층구조를 제한하는 단계를 더 포함하고, 상기 객체를 분해하는 단계는 상기 객체의 상기 식별된 개별 특성들을 분해하는 단계를 포함하는 컴퓨터 판독가능한 매체.
17. 제1항에 있어서,

    상기 객체 내의 지정된 특성을 식별함으로써 서브-컴포넌트들의 상기 계층구조를 제한하는 단계를 더 포함하고, 상기 객체를 분해하는 단계는 상기 지정된 특성을 분해하는 단계를 포함하는 컴퓨터 판독가능한 매체.
18. 제1항에 있어서,

    미리 결정된 수를 지정함으로써 서브-컴포넌트들의 상기 계층구조를 제한하는 단계 - 상기 수에 의해, 상기 직렬화된 패키지로 직렬화되는 상기 알려진 객체들을 제한함 - 를 더 포함하는 컴퓨터 판독가능한 매체.
19. 원격 경계를 가로질러 전송된 컴퓨터 판독가능한 객체들을 표현하는 패키지를 수신하는 방법을 제공하는 컴퓨터 실행가능한 명령들을 갖는 적어도 하나의 컴퓨터 판독가능한 매체로서,

    상기 방법은,

    원격 엔티티로부터 직렬화된 패키지를 수신하는 단계;

    서브-컴포넌트들의 계층구조를 식별하는 단계 - 상기 계층구조는 제1 유형의 객체를 표현함 - ;

    각 서브-컴포넌트에 대해:

    상기 서브 컴포넌트와 연관된 유형을 식별하는 단계;

    상기 유형이 알려진 객체 유형 리스트 내에서 식별되면, 상기 유형의 객체를 인스턴스화(instantiating)하고 상기 객체의 적어도 하나의 특성을 상기 직렬화된 패키지 내에서 얻어진 정보로 실장(populating)하는 단계

    를 포함하는 컴퓨터 판독가능한 매체.
20. 제19항에 있어서,

    상기 리스트는 상기 제1 유형을 상기 알려진 객체 유형들중 하나로서 포함하는 컴퓨터 판독가능한 매체.
21. 제19항에 있어서,

    상기 적어도 하나의 서브-컴포넌트는 상기 리스트 내의 식별되지 않는 유형을 갖는 알려지지 않은 객체를 포함하는 컴퓨터 판독가능한 매체.
22. 제19항에 있어서,

    시스템 상의 제1 프로세스는 상기 직렬화된 패키지를 수신하고 상기 원격 엔 티티는 상기 시스템 상의 다른 프로세스를 포함하는 컴퓨터 판독가능한 매체.
23. 제19항에 있어서,

    시스템 상의 제1 프로세스는 상기 직렬화된 패키지를 수신하고, 상기 원격 엔티티는 다른 시스템 상의 다른 프로세스를 포함하는 컴퓨터 판독가능한 매체.
24. 제19항에 있어서,

    프로세스 내에서 실행하는 제1 애플리케이션 도메인은 상기 직렬화된 패키지를 수신하고, 상기 원격 엔티티는 상기 프로세스 내의 다른 애플리케이션 도메인을 포함하는 컴퓨터 판독가능한 매체.
25. 제19항에 있어서,

    상기 직렬화된 패키지는 XML 문서를 포함하는 컴퓨터 판독가능한 매체.
26. 원격 경계를 가로질러 객체들과 통신하는 시스템에 있어서,

    프로세서;

    메모리 - 상기 메모리는 프로세서에 의한 실행을 위해 메모리로 로딩되는 복수의 컴퓨터 실행가능한 명령들에 대해 할당되며, 상기 컴퓨터 실행가능한 명령들은 상기 원격 경계를 가로질러 객체들과 통신하는 방법을 제공함 -

    을 포함하고,

    상기 방법은,

    알려진 객체 유형들의 리스트에 기초하여 제1 유형의 객체를 적어도 하나의 서브-컴포넌트의 계층구조로 분해하는 단계 - 서브-컴포넌트 각각은 상기 알려진 객체 유형들중 하나와 연관된 알려진 객체를 포함함 - ;

    상기 알려진 객체들을 직렬화된 패키지로 직렬화하는 단계; 및

    상기 직렬화된 패키지를 원격 엔티티로 전송하는 단계

    를 포함하는 시스템.
27. 제26항에 있어서,

    시스템 상의 제1 프로세스는 상기 직렬화된 패키지를 전송하고, 상기 원격 엔티티는 상기 시스템 상의 다른 프로세스를 포함하는 시스템.
28. 제26항에 있어서,

    상기 원격 엔티티로부터 상기 직렬화된 패키지를 수신하는 단계;

    서브-컴포넌트들의 상기 계층구조를 식별하는 단계 - 상기 계층구조는 상기 제1 유형의 객체를 표현함 - ; 및

    식별된 서브-컴포넌트 각각에 대해:

    상기 서브-컴포넌트와 연관된 유형을 식별하는 단계; 및

    상기 유형이 알려진 객체 유형들의 상기 리스트 내에서 식별되면, 상기 유형의 객체를 인스턴스화하고 상기 직렬화된 패키지 내에서 얻어진 정보로 상 기 객체의 적어도 하나의 특성을 실장하는 단계

    를 더 포함하는 시스템.

Images