KR101150019B1 - 컨텍스트 정책 제어를 통한 애플리케이션간 연관을제어하는 시스템 및 방법 - Google Patents

Abstract

복수의 소프트웨어 애플리케이션 및 리소스의 상호 연동(interoperation)을 제어하는 방법은, 제1 애플리케이션으로부터 제2 애플리케이션 또는 리소스로의 통신을 가로채기(intercept)하는 단계, 상기 통신을 컨텍스트 관리 시스템으로 보내는 단계, 상기 통신에 대한 컨텍스트들의 후보 리스트를 발생하는 단계, 상기 통신에 대한 결과 조치(resultant action) 및 이름 공간(namespace)을 식별하기 위해 이들 컨텍스트에 대해 정의된 적어도 하나의 정책에 따라 상기 후보 리스트를 평가하는 단계, 및 상기 식별된 이름 공간 내의 상기 정책들에 의해 정의된 대로 상기 조치를 수행하는 단계를 포함한다. 이 방법은 상기 제2 애플리케이션의 하나 이상의 버전을 추적하는 단계는 물론, 애플리케이션 및/또는 리소스 이름의 진화(evolution)를 추적하는 단계를 더 포함한다. 이 방법은 상기 후보 리스트 상의 컨텍스트와 연관된 하나 이상의 동작을 식별하는 단계, 및 추가의 통신 이전에 상기 식별된 동작들을 실행하는 단계를 더 포함한다.

컴퓨터 소프트웨어, 운영 체제, 컨텍스트, 운영 체제 가드, 애플리케이션

Description

컨텍스트 정책 제어를 통한 애플리케이션간 연관을 제어하는 시스템 및 방법{SYSTEM AND METHOD FOR CONTROLLING INTER-APPLICATION ASSOCIATION THROUGH CONTEXTUAL POLICY CONTROL}

관련 출원의 상호 참조

본 출원은 2004년 8월 3일자로 출원된 미국 가특허 출원 제60/598,234호를 우선권 주장하며, 이는 여기에 인용함으로써 그 전체 내용이 본 명세서에 포함된다.

본 발명은 컴퓨터 소프트웨어에 관한 것으로서, 보다 상세하게는 운영 체제 소프트웨어에 관한 것이다.

많은 환경에서, 특히 애플리케이션이 네트워크를 통해 전달되는 환경에서, 가장 중요한 특징은 복잡한 설치 없이 동작 중에 애플리케이션을 실행할 수 있는 것이다. 일반적으로, 어떤 종래 기술의 시스템에서, 프로그램이 설치된 것처럼 보이도록 클라이언트 시스템을 수정하거나 또는 그 소프트웨어 자체를 실제로 설치하고 이어서 원래의 구성을 복원하기 위해 이들 수정을 철회(back out)하는 데 상당한 노력을 하였다. 이것을 함에 있어서, 다수의 문제점이 나타난다, 즉 애플리케이션과 컴퓨터의 현재 구성 간의 충돌, 동일한 또는 서로 다른 애플리케이션의 다 수의 인스턴스들, 철회 프로세스의 복잡성은 그 수정들 모두가 고려될 수 있도록 보장하기 위해 애플리케이션이 엄격한 프로세스를 거쳐야만 하며, 다수의 애플리케이션에 의한 공유 파일 및 시스템 컴포넌트의 사용이 철회 및 설치 프로세스를 복잡하게 한다.

많은 애플리케이션 실행 환경 내에서, 호환성(sociability) 및 버저닝(versioning) 문제로 인한 시스템 장애를 방지하기 위해 애플리케이션들을 격리시키는 것이 바람직하다. 그렇지만, 격리는, 이들 프로그램이 상호 운용되도록 구성되어 있지 않은 한, 그렇게 하는 것에 방해가 된다. 이 문제는 소프트웨어 애플리케이션이 운영 체제 내에서 실행되지만 사실은 그 운영 체제(OS)에 설치되지 않거나 또는 어떤 경우에는 동작 중에 설치 및 제거되는 것인 "가상 설치" 환경에서 특히 심각하다.

본 발명에 따른 실시예들은, 그렇게 하도록 설계되어 있지 않거나 디폴트 거동을 통해 부가적인 시스템 구성을 필요로 하는 환경에서, 애플리케이션간 통신 및 연관을 용이하게 해주는 것에 관한 것이다. 이들 실시예는 시스템의 당초의 설정(original premise)을 유지하고 애플리케이션의 런타임 격리(runtime segregation)를 제공하지만, 엄격한 관리 및 운영 정책 하에서 상호 운용성을 가능하게 해준다.

본 발명의 한 측면에 따르면, 복수의 소프트웨어 애플리케이션 및 리소스의 상호 연동(interoperation)을 제어하는 방법은, 제1 애플리케이션으로부터 제2 애플리케이션 또는 리소스로의 통신을 가로채기(intercept)하는 단계, 상기 통신을 컨텍스트 관리 시스템으로 보내는 단계, 상기 통신에 대한 컨텍스트들의 후보 리스트를 발생하는 단계, 상기 통신에 대한 결과 조치(resultant action) 및 이름 공간(namespace)을 식별하기 위해 이들 컨텍스트에 대해 정의된 적어도 하나의 정책에 따라 상기 후보 리스트를 평가하는 단계, 및 상기 식별된 이름 공간 내의 상기 정책들에 의해 정의된 대로 상기 조치를 수행하는 단계를 포함한다. 이 방법은 또한 상기 제2 애플리케이션의 하나 이상의 버전을 추적하는 단계는 물론, 애플리케이션 및/또는 리소스 이름의 진화(evolution)를 추적하는 단계를 포함한다. 이 방법은 또한 상기 후보 리스트 상의 컨텍스트와 연관된 하나 이상의 동작을 식별하는 단계, 및 추가의 통신 이전에 상기 식별된 동작들을 실행하는 단계를 포함한다. 상기 후보 리스트는 하나 이상의 분산 컨텍스트로부터 발생된다. 이들 통신은 프로세스간 통신, 운영 체제 호출, API 호출, 및 라이브러리 호출 중 적어도 하나를 포함한다. 상기 컨텍스트는 글로벌 컨텍스트(global context), 관리 컨텍스트(managed context), 로컬 시스템 컨텍스트(local system context), 시스템 가상 컨텍스트(system virtual context), 벤더 컨텍스트(vendor context), 사용자 컨텍스트, 세션 컨텍스트(session context), 공유 컨텍스트(shared context), 및 격리 컨텍스트(isolated context) 중 적어도 하나를 포함한다. 상기 정책은 상기 정책이 언제 적용되는지를 식별해주는 일치 니모닉(match mnemonic), 상기 정책을 적용하는 복수의 요청 상관 파라미터 및 규칙 중 적어도 하나를 포함한다.

본 발명의 다른 측면에 따르면, 다른 애플리케이션 또는 리소스 내에서 실행될 애플리케이션에 대한 대안적인 이름 공간을 정의하는 방법은, 공통 이름의 리소스에 대한 호출을 가로채기하는 단계, 상기 호출에 대한 타겟 이름 공간(target namespace)을 식별하는 단계, 상기 공통 이름을 그 이름 공간 내의 애플리케이션들에 의해 사용가능한 로컬 이름으로 변환하는 단계, 및 그 로컬 이름에 의해 식별되는 상기 리소스에의 액세스를 제공하는 단계를 포함한다. 이 방법은 또한 애플리케이션의 하나 이상의 버전을 추적하는 단계는 물론, 애플리케이션 또는 리소스 이름의 진화를 추적하는 단계를 포함한다. 상기 로컬 이름은 또한 상기 로컬 이름에 의해 식별되는 리소스에의 액세스가 대안적인 이름 공간에서의 다른 로컬 이름에 의해 식별되는 리소스로 용이하게 행해질 수 있도록 절대 이름(absolute name)으로 변환될 수 있다. 상기 타겟 이름 공간을 식별하는 단계는 하나 이상의 분산 질의를 포함하며, 상기 타겟 이름 공간에 대한 적어도 하나의 질의가 하나 이상의 시스템에 공통인 이름 공간들을 추적하는 관리 시스템에 대해 수행될 수 있다.

본 발명의 다른 측면에 따르면, 복수의 소프트웨어 애플리케이션 및 리소스의 상호 연동을 제어하는 시스템은, 통신에 대한 컨텍스트들의 후보 리스트를 발생하는 컨텍스트 관리 시스템, 상기 컨텍스트들에 대해 정의된 적어도 하나의 정책에 따라 상기 후보 리스트를 평가하는 정책 엔진 - 이 정책 엔진은 또한 상기 통신에 대한 결과 조치 및 이름 공간을 식별해줌 -, 및 제1 애플리케이션으로부터의 통신을 제2 애플리케이션 또는 리소스로 또 상기 컨텍스트 관리 시스템으로 보내는 가상 환경 관리자 - 이 가상 환경 관리자는 상기 식별된 이름 공간 내의 상기 적어도 하나의 정책에 의해 정의된 대로 상기 결과 조치를 나타내는 명령어를 수신함 - 를 포함한다.

본 발명은 클라이언트 컴퓨터의 운영 체제를 변경하지 않고 애플리케이션 소프트웨어 환경을 생성하는 시스템을 제공하며, 이 시스템은 운영 체제 추상화 및 보호 계층을 포함하며, 상기 추상화 및 보호 계층은 실행중인 소프트웨어 애플리케이션과 상기 운영 체제 간에 배치되어 있고, 그에 의해 애플리케이션이 실행될 수 있는 가상 환경이 제공되며 애플리케이션 레벨 상호 작용이 실질적으로 제거된다. 양호하게는, 운영 체제에 직접적인 임의의 변경이 실행 중인 애플리케이션의 컨텍스트 내에서 선택적으로 행해지고, 추상화 및 보호 계층은 관리 설정에 따라 가상 환경을 동적으로 변경한다. 게다가, 어떤 환경에서, 이 시스템은 공유 시스템 자원의 사용을 계속하여 모니터링하고 시스템 컴포넌트에 변경을 적용 및 그 변경을 제거하는 서비스로서 기능한다.

따라서, 예를 들어, Windows-기반 운영 체제에서의 실시예에서, Windows 레지스트리에 대한 모든 동작이 Win32 API를 통하고, 이 시스템은 양호하게는 함수를 후킹(hook)하는 수단을 제공하며, 그에 의해 상기 함수가 호출될 때마다 다른 함수 또는 애플리케이션이 그 호출을 가로채기하고, 이 시스템은 아주 양호하게는 서버로부터 실행되는 애플리케이션에 의해 행해진 요청이든 능동적으로 관리되는 구성 키(configuration key)에 대해 애플리케이션에 의해 행해진 요청이든 그 요청에 서비스하기 위해 각각의 적절한 API 함수를 후킹한다.

본 발명의 상기한 특징 및 이점과 기타의 특징 및 이점은, 유사한 참조 번호가 서로 다른 도면들에 걸쳐 동일한 부분을 지칭하고 있는 첨부 도면에 도시되어 있는, 본 발명의 실시예들에 대한 이하의 보다 상세한 설명으로부터 명백하게 될 것이다.

도 1은 본 발명, 운영 체제 및 소프트웨어 애플리케이션의 상대적 관계를 나타낸 개략 블록도.

도 2는 사적 컨텍스트(private context) 및 서비스를 갖는 실행 중인 2개의 애플리케이션을 나타낸 개략 블록도.

도 3은 운영 체제가 시스템 리소스의 공유 뷰(shared view)를 제공하는 동안 실행 중인 2개의 애플리케이션을 나타낸 개략 블록도.

도 4는 운영 체제 가드(operating system guard) 및 서브시스템을 나타낸 개략 블록도.

도 5는 전체 시스템에 대한 뷰(view)가 글로벌 컨텍스트(global context)에 대응하는 것인, 본 발명의 일 실시예에 따른 하나 이상의 컴퓨팅 장치를 갖는 다수의 시스템을 포함하는 예시적인 호스트 운영 체제를 나타낸 도면.

도 6 및 도 7은 글로벌 컨텍스트, 관리 컨텍스트, 로컬 시스템 컨텍스트, 시스템 가상 컨텍스트, 벤더 컨텍스트, 사용자 컨텍스트, 세션 컨텍스트, 공유 컨텍스트 및 격리 컨텍스트 등의 도 5와 관련하여 예시된 예시적인 시스템에서의 실시예에 따른 서로 다른 컨텍스트를 나타낸 도면.

도 8은 본 발명의 일 실시예에 따른, 서로의 리소스, 운영 체제 및 리소스에 대한 3가지 서로 다른 구성 파일를 이용하는 2개의 애플리케이션의 블록도.

도 9는 본 발명의 실시예에 따른 관련 컨텍스트 및 이용가능한 범위(scope)를 판정하는 데 사용되는 소프트웨어 코어의 블록도.

도 10은 본 발명의 일 실시예에 따른 프로세스 관리자에 의해 사용되는 프로세스 트리를 나타낸 도면.

도 11은 본 발명의 일 실시예에 따른, 시스템의 이용가능한 컨텍스트의 테이블은 물론, 컨텍스트들 간의 연관 관계(association)를 포함하는 컨텍스트 관리자를 나타낸 도면.

도 12는 본 발명의 일 실시예에 따른, 다른 프로그램의 리소스 트리에 부착된 리소스를 나타낸 도면.

이제 도 1을 참조하면, 본 발명, 운영 체제 및 소프트웨어 애플리케이션의 상대적 관계를 나타낸 개략 블록도가 예시되어 있다. 본 발명의 양호한 실시예는 "운영 체제 가드(Operating System Guard)"라고 하는 운영 체제 추상화 및 보호 계층(100)을 제공한다. 많은 운영 체제(10)는 애플리케이션(50)이 실행될 때 서로 영향을 주지 않도록 보호하기 위해 폴트 도메인(fault domain)을 제공한다. 그렇지만, 공유 시스템 리소스 및 많은 다른 운영 체제 특징은 이 보호 도메인(protection domain)이 절충될 수 있게 해준다. 운영 체제 추상화 및 보호 계층(100)은 대부분의 애플리케이션 레벨 상호작용을 제거하기 위해 애플리케이션(50)들 간에 부가적인, 프로그램적으로 제어되는 장벽을 제공하게 된다. 애플리케이션(50)과 운영 체제(10) 사이에 배치되어 있는 경우, 운영 체제 추상화 및 보 호 계층(100)은, 실행 중인 애플리케이션의 컨텍스트 내에서의 변경을 포함하는 것에 대해서, 선택적으로 운영 체제(10)에 대해 직접적으로 변경을 할 수 있게 해준다. 일례로서, Windows-기반 시스템에서, Windows 레지스트리에 대한 모든 동작은 일반적으로 Win32 API를 통해 행해진다. 이하에서 설명하는 바와 같이, QueryRegEx 및 GetProfileString와 같은 시스템 함수는, 이들이 호출될 때마다 다른 함수 또는 애플리케이션이 그 호출을 가로채기하도록, 후킹될 수 있다. 본 발명의 운영 체제 가드(100)는, 요청이 능동적으로 관리되는 애플리케이션에 의해 행해진 경우 또는 요청이 능동적으로 관리되는 구성 항목(configuration item)에 대해 애플리케이션에 의해 행해지는 경우, 그 요청에 서비스하기 위해 각각의 적절한 API 함수를 후킹하게 된다. 이와 같이, 그렇게 하도록 명시적으로 구성되어 있는 경우, 본 발명의 실시예들은 최종 사용자의 시스템에 실제로 어떤 변경도 하지 않고 애플리케이션 환경을 생성할 수 있다. 또한, 애플리케이션에 의해 런타임시에 행해지는 임의의 수정이 용이하게 지속되거나 제거될 수 있다.

본 명세서에서 사용되는 바와 같이, "운영 체제 가드"는 실행 중인 애플리케이션과 애플리케이션이 실행될 수 있는 가상 환경을 제공하는 타겟 컴퓨터 또는 클라이언트 컴퓨터의 운영 체제 사이의 계층을 정의한다. 이 가상 환경은 몇가지 목적을 갖는다. 첫째, 이 가상 환경은 실행 중인 애플리케이션이 클라이언트 컴퓨터에 변경을 행하는 것을 방지한다. 애플리케이션이 클라이언트 컴퓨터의 기본적인 운영 체제 설정을 변경하려고 시도하는 경우, 이러한 설정은 보호되고 가상 환경에서만 "행해진다." 예를 들어, 애플리케이션이 MSVCRT.DLL과 같은 공유 객체의 버 전을 변경하려고 시도하는 경우, 이 변경은 그 애플리케이션에 로컬화되고 클라이언트 컴퓨터 상에 상주하는 코드는 그대로 있다.

둘째, 본 발명의 일 실시예는 설치를 수행함이 없이 설치 환경인 것처럼 보이는 환경을 실행 중인 애플리케이션에 제공하고, 따라서 "의사 설치(pseudo installation)" 또는 유사 설치(installation-like)이다. 모든 설정은 서비스되는 애플리케이션이 실행될 때 또는 애플리케이션이 특정의 설정을 필요로 할 때 적시에(just-in-time) 가상 환경으로 가져와진다. 예를 들어, Adobe Photoshop

등의 컴퓨터 프로그램이 HKEY_LOCAL_MACHINE＼Software＼Adobe 아래에 있는 일련의 Windows 레지스트리 엔트리를 볼 것으로 예상되는데 Photoshop이 설치되어 있지 않기 때문에 이들이 클라이언트 컴퓨터 상에서 그곳에 없는 경우에, 본 발명의 이 측면에 따라 제조된 시스템은 이들 레지스트리 엔트리가 꼭 클라이언트 컴퓨터 상에 상주하는 것처럼 Photoshop 프로그래밍 코드에 그들 레지스트리 엔트리를 "보여준다."

그 다음에, 본 발명의 일 실시예는 클라이언트/사용자 기계 상에 존재할 수 있는 정보가 애플리케이션의 거동을 방해하거나 수정하는 것을 방지한다. 예를 들어, 사용자가 이전 버전의 Photoshop에 대해 HKEY_LOCAL_MACHINE＼Software＼Adobe 아래에 이미 기존의 레지스트리 엔트리를 가지고 있지만, 보다 새로운 버전을 동작시키고자 하는 경우, 이들 엔트리는 충돌을 방지하기 위해 새로운 애플리케이션에 보이지 않게 은폐될 수 있다.

마지막으로, 본 발명의 일 실시예는 애플리케이션이 현재 기록되어 있는 대 로 존재하지 않을 수 있는 애플리케이션 거동을 언로크(unlock)한다. 본 발명은 관리 설정에 따라 가상 환경을 동적으로 변경하는 기능을 통해 이것을 행한다. 예를 들어, 엔터프라이즈 소프트웨어 애플리케이션의 일반적인 경우에, 클라이언트 애플리케이션이 레지스트리에서의 설정으로부터 사용자가 연결해야만 하는 데이터베이스의 주소에 대한 설정을 판독할 것으로 예상될 수 있다. 이 레지스트리 키가 종종 HKEY_LOCAL_MACHINE에 저장되어 있기 때문에, 이 설정은 전체 클라이언트 컴퓨터에 대해 전역적이다. 사용자는, 클라이언트를 재설치함이 없이 또는 이 레지스트리 키를 어떻게 수정해야 하는지를 모르는 상태에서 또한 사용자가 애플리케이션을 실행하고자 할 때마다 그렇게 하지 않고서는, 하나의 데이터베이스에만 연결할 수 있을 뿐이다. 그렇지만, 본 발명을 실시함으로써, 이제는 애플리케이션의 2개의 인스턴스(각각이 서로 다른 데이터베이스에 연결되어 있음)가 동일한 클라이언트 컴퓨터 상에서 실행될 수 있다.

컨텍스트(context)

이 기능을 제공함에 있어서, 각각의 애플리케이션은 시스템 내에서 사적 컨텍스트(private context)로 실행될 수 있다. 애플리케이션에 대해, 시스템은 시스템이 어떻게 보이는지 및 그의 거동에 대한 그 자신의 사적 뷰(private view)를 갖는다. 본 발명의 실시예들은 그의 본질적인 특성에 의해 이것을 제공한다. 도 2를 참조하면, 2개의 개별적인 애플리케이션(52, 54) 또는 동일한 애플리케이션(도 1에 예시된 50)의 2개의 인스턴스는 이들이 시스템 서비스, 구성 및 데이터의 개별적인 또는 서로 다른 복사본을 가지고 있는 것으로 보이는 사적 컨텍스트를 제공받 을 수 있다. 양호한 실시예에서, 이것은 본 시스템의 디폴트 거동(default behavior)이다.

이 개념을 확장함으로써, 본 발명의 일 실시예의 운영 체제 가드(100)는 또한 2개 이상의 애플리케이션(52, 54)이 그의 가상 설정 중 일부 또는 그 전부를 공유할 수 있는 공유된 제어 컨텍스트(shared, controlled context)를 제공할 수 있다. 이것은 마이크로소프트 오피스(Microsoft Office) 등의 애플리케이션 스위트(application suite)에 대해 또는 다른 애플리케이션의 존재 시에 다르게 동작하는 애플리케이션에 대해 중요하다. 예를 들어, 많은 애플리케이션은 메일 머지(Mail Merge) 또는 문서 생성 기능을 행하기 위한 엔진으로서 마이크로소프트 워드(Microsoft Word)를 사용한다. 애플리케이션은 워드의 설정 또는 존재에 관하여 알고 있어야만 하며 그의 기능들을 활용할 수 있어야만 한다. 양호한 실시예에서, 동일한 애플리케이션의 2개의 인스턴스가 디폴트로 단일의 컨텍스트를 공유하는 반면, 2개의 개별적인 애플리케이션은 사적 컨텍스트를 유지하게 된다. 도 3을 참조하면, 운영 체제 가드(100)가 이용가능한 시스템 리소스의 공유 뷰(shared view)를 제공하는 동안, 2개의 애플리케이션(52, 54)은 실행될 수 있다.

설계

도 4에 예시된 바와 같이, 운영 체제 가드는 이하의 서브시스템, 즉 코어(102), 구성 관리자(104), 파일 관리자(106), 공유 객체 관리자(108), 장치 관리자(110), 폰트 관리자(112), 프로세스 관리자(120), 프로세스 환경 관리자(114), 로더(loader)(116), 및 복구 관리자(118)로 이루어져 있다. 코어(102), 프로세스 관리자(120) 및 로더(116)를 제외하고, 모든 다른 서브시스템은 이하에서 더 상세히 기술되는 가상화 시스템의 구성요소이다. 코어(102)는 구성 파일에 의해 정의된 대로 애플리케이션 및 그의 컨텍스트를 관리하는 일을 주로 맡고 있다.

운영 체제 가드에 의해 제공되는 프로세스 관리자(120)는 코어(102)가 관심있을 수 있는 임의의 프로세스 또는 쓰레드 이벤트를 통보받을 수 있게 해준다. 프로세스 관리자(120)는 또한 프로세스 공간을 관리하고 쓰레드 프로세싱을 처리하기 위해 운영 체제-의존적인 구현에 추상화 계층을 제공한다. 프로세스는 애플리케이션 번들(application bundle)로 그룹화될 수 있다. 애플리케이션 번들은 모두가 그의 가상 리소스를 서로 공유하고 있는 프로세스들의 그룹이다. 예를 들어, 마이크로소프트 워드 및 마이크로소프트 엑셀(Microsoft Excel)은 함께 애플리케이션 스위트로서 동작할 수 있기 위해 가상 레지스트리 및 가상 파일 시스템을 공유하고자 할 수 있다. 프로세스 관리자(120)는 이들 애플리케이션 번들을 "애플리케이션"이라고 부른다. 애플리케이션에 관한 정보는 프로세스 관리자(120)가 애플리케이션을 릴리스(release)하도록 지시받을 때까지 존재한다. 또하나의 프로세스가 애플리케이션 번들 내로 로드될 필요가 있는 경우, 프로세스 관리자는, 그 애플리케이션이 릴리스되지 않은 한, 그렇게 할 수 있다.

본 발명의 일 실시예에 따른 로더 서브시스템(116)은 가상 환경이 실행 시스템(running system) 내로 또한 그 밖으로 전송될 수 있도록 해주는 데 사용된다. 가상화 서브시스템 각각은 로더(116)를 위해 그의 구성을 직렬화하고 역 프로세스(reverse process)를 통해 그것을 검색할 수 있다. 게다가, 로더(116)는 단계별 로딩/언로딩(staged loading/unloading) 및 개별적인 단계(stage)의 결과들을 단 하나의 환경 설명(environment description)으로 결합시키는 일을 할 수 있다.

레지스트리 및 구성

애플리케이션은 적절히 동작하기 위해 다양한 분량의 구성 정보를 필요로 한다. 애플리케이션이 그의 구성을 판독할 수 있는 0개 내지 수천개의 구성 레코드가 존재한다. Windows 상에는, 구성 정보를 위한 2개의 공통 장소, 즉 Windows 레지스트리 및 시스템 레벨 초기화 파일 win.ini 및 system.ini가 있다. 게다가, ＼WINDOWS＼SYSTEM 디렉토리는 애플리케이션이 애플리케이션 관련 구성 또는 초기화 파일을 기록하기 위한 공통 장소이다. 애플리케이션은 또한 부가적인 구성 정보를 저장하기 위해 그의 로컬 애플리케이션 디렉토리 내의 구성 또는 데이터 파일을 사용한다. 종종, 이 정보는 처리하기가 어려운데, 그 이유는 그것이 독점적인 포맷으로 되어 있기 때문이다. Windows 이외의 플랫폼 상에서, 레지스트리에 상응하는 것이 없지만, 구성 정보를 위한 공통 디렉토리는 존재한다. X Windows는 app-defaults 디렉토리를 갖는다. Macintosh는 시스템 폴더(System Folder)를 가지며, 기타의 운영 체제는 대응하는 요소를 가지게 된다. 도 2에서 알 수 있는 바와 같이, 대부분의 UNIX 시스템 상에서, 각각의 개별적인 애플리케이션(52, 54)이 종종 그 자신의 구성(62, 64)을 로컬적으로 저장한다는 것에 유의하는 것이 중요하다.

본 발명의 일 실시예는 완전 기능 레지스트리(full function registry)를 애플리케이션에 제공하지만 기본적인 시스템 레지스트리에 대한 수정을 방지하는 가상 Windows 레지스트리 컴포넌트를 포함한다. 애플리케이션이 액세스할 것으로 예 상되는 모든 키가 존재하지만, 가상 레지스트리에만 존재할 수 있다. 이와 같이, 본 발명의 운영 체제 가드(100) 및 Windows 레지스트리는 레지스트리에 액세스하기 위한 2-단계 프로세스를 형성한다. 애플리케이션이 키에 액세스할 필요가 있는 경우, 그 애플리케이션은 레지스트리에 질의를 한다. 운영 체제 가드는, 키를 알고 있는 경우, 키 및 그의 값으로 응답한다. 그렇지 않은 경우, 운영 체제 가드는 그 요청이 Windows 레지스트리에까지 전달될 수 있도록 해준다. 값을 수정하려는 시도가 행해지는 경우, 운영 체제 가드는 그 자신에 대해서만 수정이 일어날 수 있게 해준다. 애플리케이션이 그 다음에 키에 액세스할 때, 그 키는 운영 체제 가드에 존재하고 그 요청은 실제 레지스트리에까지 가지 않으며, 실제 레지스트리는 그대로 있게 된다.

운영 체제 가드가 사용하는 키는 3개의 개별적인 섹션에 지정되어 있다. 이들 운영 체제 가드 키는 이들 섹션에서 기존의 키를 수정, 키의 존재를 삭제 또는 레지스트리에 새로운 키를 추가하는 명령(command)으로서 지정되어 있다. 이와 같이, 가상 레지스트리는 시스템이 의도하는 그대로 나타날 수 있다. 이것이 중요한 이유는 키의 존재 또는 부존재가 키의 실제값만큼 중요하기 때문이다.

일 실시예에서, 운영 체제 가드는 먼저 애플리케이션에 대한 기본 레지스트리 엔트리를 포함하는 데이터 파일을 로드한다. 이어서, 사용자의 선호도를 포함하는 제2 데이터 파일이 로드된다. 마지막으로, 운영 체제 가드는 선택적으로 사용자가 번복(override)할 수 없게 되어 있는 정책 항목을 포함하는 일련의 키를 로드할 수 있다. 3개의 파일은 서로의 상부에 로드되며, 각각의 파일에서의 중복 항 목은 파일에서 그 이전에 있는 항목을 번복한다. 사용자가 애플리케이션을 처음으로 실행할 때, 제2 데이터 파일은 존재하지 않는데, 그 이유는 사용자 관련 정보가 없고 애플리케이션 디폴트(application default)만 있기 때문이다. 그렇지만, 각각의 세션 이후에, 운영 체제 가드는 사용자의 변경을 저장하게 되고, 장래의 세션에서 사용하기 위해 그 제2 데이터 파일을 생성한다.

구성 파일은 2가지 방식으로 수정될 수 있다. 첫째, 파일은 애플리케이션에 의해 직접 편집될 수 있다. 이 시나리오에서, 이후에서 기술되는 운영 체제 가드 서브시스템은 파일에 대해 행해지는 수정을 담당하고 있다. 둘째, 양호한 실시예에서, 애플리케이션은 이들 파일을 수정하기 위해 Windows API 계열의 호출(call) GetProfileString, WriteProfileString, 또는 기타를 호출할 수 있다. 이 경우에, 본 발명의 일 실시예의 운영 체제 가드는 상기한 바대로 이들 호출을 가로채는 것 및 그 내부로부터 이들에 서비스하는 것을 수행한다.

공유 객체

운영 체제 및 실행 중인 애플리케이션에 의해 사용되는 많은 컴포넌트는 몇개의 애플리케이션 또는 인스턴스에 걸쳐 공유된다. 일반적으로, 이것은 아주 좋은 생각이다. 이는 디스크 공간을 절감하며, 동일한 파일의 많은 복사본을 필요로 하지 않는다. 이는 또한 운영 체제 벤더 및 써드 파티가 공통으로 사용되는 코드의 라이브러리를 작성 및 배포할 수 있게 해준다. Windows 플랫폼 상에서, 동적 링크 라이브러리(Dynamic Link Library, DLL)는 종종 애플리케이션 내에서 및 애플리케이션들에 걸쳐 공유된다. 다른 플랫폼 상에서, 이 문제는 동일하다. 매킨토 시(Macintosh) 상에서, INIT 및 다른 시스템 컴포넌트가 애플리케이션을 위해 로드된다. 이들 컴포넌트는 많은 버전을 가질 수 있으며, 한 번에 이들 중 단지 하나만이 사용된다. UNIX 시스템 상에서, 동적 공유 객체, 예를 들어 ".so" 라이브러리 파일은 로드 시간을 빠르게 하기 위해, 디스크 공간을 절감하기 위해 또한 다른 이유로 애플리케이션에 의해 사용된다. 많은 프로그램은 디폴트 "libc.so"를 사용한다. 그렇지만, 이 라이브러리 파일은 일반적으로 libc.so.3 등의 그 자신의 어떤 버전에의 심볼릭 링크(symbolic link)이다. 실제로, 이 특징은 혼란을 야기한다. 이들 공유된 컴포넌트는 종종 개정을 거치게 되며, 동일한 컴포넌트의 많은 버전이 설치될 수 있다. 애플리케이션 저작자는 그의 소프트웨어가 공유된 컴포넌트의 버전들 중 아마도 단지 하나 또는 몇개와 동작한다는 것을 발견하였다. 따라서, 실제로, 애플리케이션은 일반적으로 그 애플리케이션이 원하는 버전을 설치하며, 다른 현재의 버전을 덮어쓰기한다. 이것은 아마도 시스템 상에서 실행 중인 다른 애플리케이션에서 디폴트(default)를 야기한다.

Windows 98, Windows 2000에서, 마이크로소프트는 시스템 관리자가 XXXX.LOCAL이라고 하는 파일을 애플리케이션의 기본 디렉토리(base directory)에 생성할 수 있도록 해주기 위해 WPFS(Windows Protected File System)를 만들었으며, 여기서 XXXX는 확장자가 없는 실행가능 파일 이름이다. 이것에 의해 Windows 로더는 LoadLibrary 실행 동안에 경로 참조(path reference)를 리졸브(resolve)하는 그의 방법을 변경하게 된다. 그렇지만, 이 문제를 완벽하게 해결하는 데 이것으로 충분하지 않다. 첫째, XXXX 파일을 설정하는 것은 변동 폭이 넓은 시스템 관 리자의 지식에 맡겨져 있다. 둘째, 컴포넌트 버전은 다시 최초 버전으로 되돌아가아만 하며, 이어서 로컬 디렉토리에 이 컴포넌트를 설치한 다음에 ".LOCAL" 파일을 생성한다. 이것은 WINDOWS＼SYSTEM에 배치된 가장 기본적인 컴포넌트를 제외한 어느 것에 대해서도 간단한 프로세스가 아니다. 또한, 이 해결책이 필요한 기능 모두에 해당되는 것은 아니다. LoadLibrary 동안에, Windows는 컴포넌트가 명시적인 또는 암시적인 LoadLibrary의 결과로서 리졸브되었는지 또한 그 컴포넌트가 지명된 또는 공지의 DLL임을 나타내는 레지스트리 키가 존재하는지에 따라 다른 경로 리졸브 시맨틱스(path resolution semantics)를 사용한다. 이 경우에, LoadLibrary 호출은 항상 WINDOWS＼SYSTEM 디렉토리로 리졸브된다.

DLL 및 다른 공유 컴포넌트는 또한 실행 중인 애플리케이션이 그를 참조하는 한, 컴포넌트가 그대로 있도록 보장하기 위해 참조 카운트 시맨틱스(reference count semantics)를 유지한다. 실제로, 운영 체제 벤더로부터의 애플리케이션 및 운영 체제 자체만이 이 프로토콜을 잘 따르고 있다.

일반적인 규칙으로서, 공유 객체가 항상 정확한 컴포넌트로 리졸브되게 하는 것이 요망된다. 이 기능을 제공하기 위해, 애플리케이션이 기능할 수 있는 컴포넌트의 버전 또는 버전의 범위를 알고 있어야만 한다. 그리고, 애플리케이션이 실행되어야만 할 때, 본 발명은 컴포넌트가 정확하게 리졸브(resolve)되도록 보장해야만 한다. 본 발명에서 WPFS 또는 원하는 경우 다른 운영 체제 제공 기능의 사용을 자동화하는 것이 바람직하다. 이 경우에, 필요한 컴포넌트를 검출하고 이들을 로컬 파일 시스템에 배치할 필요가 있다. 이것은 단지 설치를 보고 있는 것보다 복 잡한데, 그 이유는 요구되는 컴포넌트가 이미 그곳에 있는 경우, 설치 프로그램이 종종 컴포넌트를 설치하지 않기 때문이다.

지명된 객체도 또한 정확하게 로드되도록 보장하는 방법을 식별하는 것이 요망된다. Windows 플랫폼에서, MSVCRT.DLL은 이 문제 영역 내에서 중요한 원인이다. 이 객체의 다수의 버전이 유지되는 경우, 상기한 레지스트리 키가 동적으로 변경될 수 있고, LoadLibrary 함수가 정확한 컴포넌트 버전을 리졸브할 수 있게 된다. 정확한 컴포넌트 로딩을 보장해주는 다른 타당한 방법은 유효한 검색 경로를 사용하기 위해 프로세스 환경을 동적으로 편집하는 것이다. 이 검색 경로는 로컬 컴포넌트가 시스템 전반적인 컴포넌트(system wide component)보다 먼저 리졸브되도록 보장해준다. 정확한 공유 객체를 리졸브하는 다른 가능한 방법은 심볼릭 링크의 사용을 통한 것이다. 런타임 시에 컴퓨터의 파일 시스템에 의해 필요한 컴포넌트로 리졸브되는, 공유 컴포넌트에 대해 심볼릭 링크가 만들어질 수 있다. 마지막으로, 공유 객체의 파일로부터의 정보에 대한 실제의 열기/판독/닫기 요청이 본 발명에 의해 가로채기되고 로컬 시스템 상에 또는 본 발명의 서브시스템 내에 존재할 수 있는 파일의 정확한 버전에 대해 동적으로 응답될 수 있다.

몇가지 특수 형태가 존재한다. Windows 플랫폼에서, OLE, ODBC, MDAC, ... 는 물론 다수의 다른 벤더 관련 컴포넌트는 몇개의 또는 모든 실행 중인 프로세스들 간에 전역적으로 공유되도록 작성되어 있다. OLE의 경우에, 개별적인 프로세스들 간에 데이터 및 메모리 공간을 공유하는 것에까지 이른다. OLE는, 이들 컴포넌트의 다수가 그러한 것처럼, 한 번에 그 자신의 2개 이상의 복사본이 실행되는 것 을 방지한다. OLE는 특정의 애플리케이션에 대해 특정 버전이 로드될 것을 요구하는 많은 버그 및 특징을 가지고 있다. 본 발명에서, 애플리케이션은 요구되는 OLE의 버전이 어느 것이든 그 버전을 로드할 수 있으며, 여전히 동일한 버전의 OLE를 사용하는 다른 컴포넌트들과의 시맨틱스 공유를 가능하게 해준다.

일반적으로, 그 자체로서 특별히 구성되지 않는 한, 공유 객체는 충돌 방지를 보장하기 위해 사적으로 로드되어야만 한다. 컴포넌트가 사적으로 로드될 수 있게 해주기 위해 사용되는 방법에 관한 어느 것도, 운영 체제 가드에 의해 능동적으로 관리되고 있는지 여부에 상관없이, 그 컴포넌트가 멋지게 언로드되거나 다른 소프트웨어 애플리케이션을 위해 정확하게 로드하는 것을 방해해서는 안된다. 게다가, 시스템이 고장나는 경우, 기본 운영 체제를 덮어쓰기하거나 수정함이 없이, 이 고장(crash)으로부터 고장없는 상태(clean state)로 복구할 필요가 있다.

파일

많은 애플리케이션은 구성 엔트리 또는 다른 애플리케이션 데이터를 저장하기 위해 애플리케이션 내에서 데이터 파일을 사용한다. 본 발명의 실시예들은 본 명세서에서 이전에 기술한 가상 레지스트리와 거의 유사하게 가상 파일 시스템을 제공한다. 애플리케이션이 시작하기 이전에, 본 발명의 일 실시예는, 숨길 파일 및 가상 환경에 추가할 파일 또는 가상 환경 내의 다른 데로 리디렉션할 파일을 비롯한, 파일 시스템 변화의 리스트를 로드할 수 있다. 애플리케이션이 임의의 파일에 액세스하거나 파일을 수정할 때마다, 운영 체제 가드는 그 파일이 리디렉션되어야만 하는지를 검사하고, 그렇게 해야만 하는 경우, 양호한 실시예에서, 그 요청을 운영 체제 가드 구성에서 지정된 장소로 리디렉션한다.

애플리케이션이 사용자의 로컬 드라이브 상에 기록하기 위해 새로운 파일을 생성하거나 기존의 파일을 열려고 시도하는 경우, 운영 체제 가드는 그 파일이 리디렉션된 장소에 실제로 생성되거나 수정되도록 보장해야만 한다. 애플리케이션이 나중에 재로드되는 경우, 이 파일 매핑이 운영 체제 가드 가상 환경에 재로드되어야만 한다. 요청이 사용자의 로컬 드라이브에 존재하는 기존의 파일을 수정하는 것일 때, 운영 체제 가드는, 그 요청을 계속하기 이전에, 문제의 파일을 리디렉션 지점으로 복사해야만 한다. 리디렉션된 파일은 파일 경로의 안전한 매핑을 보장하기 위해 원본 파일과 동일한 이름을 가지지 않을 수 있다. 일 실시예에서, INI 파일은, 최대 애플리케이션 호환성을 가능하게 해주면서 최대 시스템 보안을 제공하기 위해, 이와 같이 처리된다.

본 발명의 일 실시예는 네트워크를 통해 전달되는 애플리케이션에 대해 특히 유용하다. 이러한 구현에서, 소프트웨어 애플리케이션이 몇가지 종류의 데이터로 이루어져 있으며, 이 때 소프트웨어 애플리케이션이 사용하는 파일의 대부분이 가장 양호하게는 별도의 논리 드라이브에 탑재되어 있다는 것을 이해하는 것이 중요하다. 파일 기반 및 레지스트리 기반 둘다를 포함한 구성은 사용자 관련(user specific)되고 시스템 전반적(system wide)일 수 있다. 사용되는 애플리케이션 전달 시스템은 임의의 파일이 이들 유형 중 어느 것에 대한 것인지 각각의 파일에 표시를 해야만 한다. 이 정보는 적절히 동작하도록 운영 체제 가드 시스템에 힌트를 제공한다.

장치 드라이버

많은 애플리케이션이 하드웨어 지원 또는 운영 체제와의 직접적인 로우 레벨 상호작용 등의 그의 기능 중 일부를 구현하기 위해 장치 드라이버 또는 다른 운영 체제 레벨 소프트웨어를 사용한다. 본 발명의 일 실시예에서, 운영 체제 가드는 동적으로 또한 가능한 사적으로 이들 컴포넌트를 애플리케이션의 가상 환경에 추가 및 제거하는 기능을 제공한다.

많은 장치 드라이버는 동적으로 로드가능하도록 작성되어 있다. 가능한 경우, 모든 장치 드라이버를 동적으로 로드하는 것이 양호한 실시예이다. 장치 드라이버가 부팅 시에 정적 로드(static load)를 필요로 하는 경우, 사용자는 애플리케이션을 실행하기 이전에 이러한 정보를 제공받아야만 한다. 시스템이 재부팅된 경우, 애플리케이션은 그만둔 곳으로부터 계속되어야만 한다. 그렇지만, 대부분의 장치 드라이버는 동적으로 언로드가능하지 않다. 드라이버를 동적으로 언로드하는 것이 바람직하지만, 이것이 달성될 수 없는 경우, 그 다음 재부팅 시에 제거하기 위해 드라이버에 표시가 행해지고, 사용자는 이것을 알고 있어야만 한다. 애플리케이션이 그 다음 재부팅 이전에 다시 실행되는 경우, 시스템은 드라이버가 존재한다는 것을 알고 있어야만 하고 다시 설치하려고 시도해서는 안되며, 그 컴포넌트가 그 다음 재부팅 시에 제거가능하다는 것을 나타내는 종료를 기다려야 한다.

본 발명의 실시예들이 정확하게 기능할 수 있도록 보장하기 위해, 각각의 장치 드라이버 부류에 대해 유사점 및 차이점이 존재할 때, 기본적인 유사점 및 차이점의 특징을 기술하는 것이 중요하다. 이것이 프로그래밍 용이성(programming ease)의 관점에서 양호한 실시예는 아니지만 이는 본 발명의 범위 내에 속하며 또 본 발명의 실시예들을 사용하여 전달 및 실행되는 애플리케이션에 대한 라이센싱 합의에서의 제한 등의 특정의 이유로 필요할 수 있다는 것을 잘 알 것이다.

비마이크로소프트 플랫폼에서, 장치 드라이버는 일반적으로 아주 다르게 처리된다. 매킨토시 시스템은 정적 드라이버 및 동적 드라이버 둘다를 지원하지만, 이들 모두는 동일한 방법을 통해 설치 및 제거된다. 매킨토시 시스템 폴더와의 링킹은 필요한 지원을 제공한다. UNIX 시스템의 경우, 장치 드라이버는 일반적으로 실행 중인 UNIX 커널에 대한 수정 및 뒤이어서 재부팅을 필요로 한다. 이 프로세스는 아주 복잡할 수 있다. 일 실시예에서, 애플리케이션이 완료된 경우 커널을 리셋(reset)하는 것을 비롯하여 이 프로세스는 자동화된다. 프로세스의 일반 파라미터는 Windows 애플리케이션에 대해 상기한 것과 동일하며, 컴파일의 실제 프로세스 단계 및 이러한 운영 체제에 친숙한 사람이 재부팅을 수행할 수 있다.

마지막으로, 당업자라면 시스템 고장 전반에 걸쳐 드라이버를 복구 및 제거하는 것이 바람직하다는 것을 잘 알 것이다. 따라서, 시스템 무결성을 유지하는 데 필요한 어느 데이터 또는 프로세스라도 본 발명의 일 실시예에 포함된다. 또한, 당업자라면 모든 유형의 장치 드라이버가 본 발명의 실시예들을 통해 편리하게 또는 효율적으로 제공되지 않을 수 있으며, 영구적인 하드웨어 부속 장치와 연관된 드라이버에 있어서 특히 그렇다는 것을 잘 알 것이다.

기타 항목

본 발명의 실시예들에서, 그의 거동 또는 존재가 대안적인 운영 체제 상에서 서로 다른 몇가지 컴포넌트가 있다는 것을 잘 알 것이다. 이들 컴포넌트는 폰트, 프로세스, 환경 변수 및 기타 등등을 포함한다.

몇몇 애플리케이션은 정확하게 동작하기 위해 폰트의 설치를 필요로 한다. 요구되는 임의의 폰트는 운영 체제 가드의 구성 파일에 지정되어 있다. 운영 체제 가드는 애플리케이션을 실행하기 이전에 이들 폰트를 인에이블시키며 필요한 경우 그 후에 이들을 제거한다. 대부분의 시스템은 폰트를 등록하거나 시스템이 폰트가 존재함을 알도록 해주는 프로세스 이외에 폰트의 저장을 위한 공통 영역을 갖는다. 운영 체제 가드는 이들 이용가능한 방법을 활용한다.

Windows에서, 폰트는 ＼WINDOWS＼FONTS 디렉토리에 복사된다. 그렇지만, 이것은 폰트가 실행 중인 프로그램에 이용가능함을 보장하지 않는다. 양호한 실시예에서, 프로그램이 폰트에 액세스하기 위해 Windows API를 사용하는 경우, 폰트는 CreateScalableFontResource/AddFontResource 등의 Win32 API 호출로 등록될 필요가 있다. 이것은 폰트를 시스템 폰트 테이블에 삽입한다. 완료되면, 운영 체제 가드는 RemoveFontResource와 같은 다른 적절한 API 호출로 폰트를 제거할 수 있고, 이어서 파일을 시스템으로부터 제거할 수 있다. 대체 실시예로서, 운영 체제 가드는 가상 레지스트리 방법에서 기술한 바와 같이 API 함수를 후킹할 수 있다. 게다가, 운영 체제 가드는 실제 폰트 파일을 실행 시스템에 설치하는 것을 회피하기 위해 그의 파일 서브시스템을 사용할 수 있다.

매킨토시에서, 이 프로세스는 극히 유사하며 매킨토시 시스템 폴더 내의 파일 및 등록 활성화에 기초하고 있다. 그렇지만, UNIX에서, 이 프로세스는 애플리 케이션에 의존하고 있다. 가장 일반적으로는, 폰트 리소스가 적절한 위치에 리졸브된 정규의 파일로서 시스템에 추가되며, 따라서 이들은 이름으로 액세스될 수 있다. 많은 Motif 시스템에서, 폰트가 리졸브될 수 있게 해주는 폰트 설명이 폰트 리소스 파일 내에 배치될 필요가 있다. Motif 또는 X 애플리케이션은 리졸브 서브시스템을 통해 또는 직접 호출에 의해 폰트를 호출할 수 있다. 최근에, 많은 Motif 및 CDE 기반 시스템은 Adobe 확장가능 포스트스크립트 폰트(scalable postscript font)를 이용한다. 이들 폰트는 Adobe 타입 관리 시스템을 통해 관리될 필요가 있다. 그렇지만, 예외가 있으며, 상기한 바와 같이, Windows 또는 다른 운영 체제 디폴트 폰트 관리 시스템에 대한 대안이 있다. Adobe 타입 관리자(Type manger)는, 다른 써드 파티 타입 관리 시스템이 하는 것처럼, 이 프로세스를 위한 어떤 대안적인 인터페이스를 제공한다. 대부분의 경우에, 인터페이스를 지원할지 이를 무시할지가 결정되어야만 한다. 운영 체제 가드의 목적은 이들 시스템 전부를 위한 범용 계층을 제공하는 것이 아니라 운영 체제 자신의 서브시스템을 위해서만 그렇게 하는 것이다.

많은 애플리케이션에서 환경 변수가 설정되어야만 한다. 이것은 UNIX 시스템에서 가장 통상적이지만, 처음에 UNIX 상에서 작성되어 Windows 운영 체제로 포팅된 소프트웨어에 의해서도 많이 사용된다. Windows 운영 체제 상의 애플리케이션은 DOS PATH 환경 변수에 크게 의존하며 종종 그 자신의 애플리케이션 관련 엔트리를 설정한다. Windows 9x/Me 환경에서는, 그의 코어에서 DOS 서브시스템처럼 적용가능한 많은 환경 설정이 있다. 애플리케이션이 특정 변수의 존재를 필요로 하 거나 기존의 환경 변수에서 값이 설정될 필요가 있는 경우, 요구되는 환경 변수는 운영 체제 가드의 구성 파일에 지정된다. 운영 체제 가드는 애플리케이션이 기동될 때 애플리케이션의 메인 프로세스에 대한 이들 변수를 설정한다. 애플리케이션이 동작할 때 애플리케이션이 일반적으로 환경 설정을 변경하지 않기 때문에, 가상 환경은 이들 호출을 트랩(trap)하지 않으며 또한 레지스트리 및 구성 서브시스템이 행하는 기능의 완벽한 보완물(full complement)을 제공하지도 않는다.

복구

이전의 섹션에 나타낸 어떤 경우에서, 운영 체제에 실제 수정이 행해져야만 한다. 이것은 장치 드라이버 및 폰트에서 종종 있는 일이다. 게다가, 존속되어 애플리케이션이 그 다음에 실행될 때 이용가능할 필요가 있는 가상 환경에 변경이 행해질 수 있다. 운영 체제 가드 시스템이, 가능한 가장 이른 시기에 시스템으로부터 변경을 제거하여, 시스템에 대한 변경으로부터 복구될 수 있어만 한다. 다른 대안으로서, 시스템이 애플리케이션의 실행 동안에 고장난 경우, 운영 체제 가드는, 재부팅되거나 다른 경우에, 시스템에 대한 임의의 변경을 제거하기에 충분한 정보를 추적해야만 하고 또 가상 환경에 행해진 변경을 추적해야만 한다. 양호한 실시예에서, 이것은 트랜잭션 로그(transaction log)로서 구현되지만, 다른 환경에서 변경이 철회될 수 있도록 시스템 기동 시에 판독될 수 있는 어떤 다른 유사한 컴포넌트로서 행해질 수 있다.

가상화 제어

본 발명의 중요한 특징은 운영 체제 가드가 할 수 있는 가상화의 많은 측면 의 제어에 관한 것이다. 양호한 실시예에서, 제어할 소프트웨어 시스템의 정확한 측면을 확인할 수 있는 계측 프로그램(instrumentation program)이 존재한다. 또한, 관리자 및 최종 사용자로 하여금 시스템에 의해 가상화될 항목들을 보고 수정할 수 있게 해주는 방법도 포함되어 있다.

자동화된 프로그램에서, 제어의 측면들을 측정하기 위해 제어될 애플리케이션이 관찰된다. 자동화된 프로그램은 애플리케이션의 설치 프로세스 동안에, 애플리케이션의 런타임 동안에 또는 이들의 조합 동안에 이 작업을 수행할 수 있다. 양호한 실시예에서, 운영 체제 가드는 래퍼 애플리케이션(wrapper application)에 내장(embed)되어 있다. 설치 후에 또는 소프트웨어의 한번 또는 다수의 사용 이후에, 래퍼 애플리케이션은 그의 동작들 전부의 상세한 리스트를 얻기 위해 운영 체제 가드에 질의를 한다. 동작들의 이 리스트로부터, 래퍼 애플리케이션은 차후의 사용 시에 운영 체제 가드를 로드하여 동작시키는 데 필요한 구성 파일을 생성한다.

설치 프로세스의 일부로서 사용되는 경우, 운영 체제 가드는, 일 실시예에서, 그의 환경에만 설치가 될 수 있게 해주는 가상 계층으로서 기능한다. 이 설치 이후에, 파일, 설정. 기타 등등 모두는 나중에 재로드를 위해 덤프(dump)될 수 있다. 이와 같이, 설치는 원래의 시스템을 그대로 놔두며 필요한 구성 파일을 자동적으로 생성한다. 운영 체제 가드는, 애플리케이션의 사용 동안에 사용될 때, 환경에 대한 특이한 수정을 기록하거나 구성 파일을 재코드화(recodify)한다.

운영 체제 가드는 후처리(post-processing)를 위해 래퍼 애플리케이션에 그 의 정보를 전달한다. 양호한 실시예에서, 시스템이 생성할 수 있는 자동 엔트리 이외에, 래퍼 애플리케이션은 운영 체제 관련 및 애플리케이션 또는 도메인 관련 정보로 프로그램된다. 이 정보는 구성 항목 또는 다른 엔트리의 기지의 사용을 반영하기 위해 프로세스의 출력을 변경하는 데 사용된다. 양호한 실시예에서, 코딩에 대한 변경을 실시하기 위해 관찰된 거동과 기지의 시나리오를 비교하는 데 규칙-기반 시스템이 사용된다.

래퍼 애플리케이션은 또한 프로세스의 구성 출력을 위한 뷰어(viewer) 및/또는 에디터(editor)로서 사용된다. 양호한 실시예에서, 이 에디터는 시스템 관리자로 하여금 항목 또는 항목들의 그룹을 추가, 편집하거나 또는 구성으로부터 삭제할 수 있게 해준다. 에디터를 통해 구성을 관찰할 시에, 관리자는 또한 구성의 복사본을 만들어 애플리케이션 레벨 또는 사용자 맞춤 변경을 실시하기 위해 필요에 따라 특정 항목을 변경할 수 있다.

이제 도 1을 참조하면, 본 발명의 일 실시예가 기능별로 나타내어져 있다. 이 실시예에서, 2 세트의 애플리케이션/사용자 데이터(60)가 도시되어 있다. 운영 체제 가드(100)는 애플리케이션(50)의 2개의 인스턴스가 서로 방해하지 못하도록 한다. 게다가, 상기한 바와 같이, 운영 체제 가드(100)는 추상화 계층으로서 기능하며, 그 자체로서 클라이언트 컴퓨터의 실제 운영 체제(10)와 애플리케이션 소프트웨어(50) 간의 명령 및 통신을 수집한다. 화살표로 나타낸 바와 같이, 어떤 명령은 운영 체제 가드와 소프트웨어 애플리케이션 사이의 것이며, 이것은, 이들 명령이 그 대신에 운영 체제 자체에 의해 작동되고 그 결과 오퍼레이터(operator)가 의도한 것이 아닐 수 있는 클라이언트 컴퓨터에의 변경을 가져오는 일반적인 설치와 구별된다. 반면에, 다른 명령들은 운영 체제 가드를 통과하고 이어서 운영 체제 자체로 전송된다.

많은 소프트웨어 애플리케이션은 하나 이상의 부가적인 애플리케이션과 관련하여 동작하도록 설계되어 있다. 이것은 일련의 애플리케이션이 패키지화되어 단 하나의 유닛으로 판매되고 종종 함께 동작하도록 작성되어 있는 마이크로소프트 오피스 등의 소프트웨어의 경우에 해당될 수 있다. 이것은 또한 다른 애플리케이션에 "플러그 인"하거나 어떤 방식으로 그와 통신하도록 설계되어 있는 많은 소프트웨어 애플리케이션에 의해 입증된다.

이것이 통상적인 기능이지만, 많은 소프트웨어 배포 시스템은 이들 상호-관계가 적절히 기능할 수 있게 해주는 데 어려움이 있다. 이것은 애플리케이션의 패키지화 동안에, 애플리케이션의 최종 사용자 환경 내로의 통합 동안에 또는 런타임 시에 상호 의존 관계의 부적절한 해결에 기인한 것일 수 있다.

현재 패키지화된 소프트웨어 배포(Packaged Software Distribution), 전자 소프트웨어 배포(Electronic Software Distribution, ESD), 주문형 소프트웨어 배포(On-Demand Software Distribution), 및 마이크로소프트의 ClickOnce 시스템 등의 몇가지 차세대 배포 시스템을 비롯한 많은 형태의 소프트웨어 배포가 있다. 이들 배포 시스템 각각은 소프트웨어가 어떻게 배포되는지, 소프트웨어가 어떻게 설치 및 제거되는지, 및 소프트웨어가 호스트 운영 체제 및 다른 애플리케이션 둘다와 어떻게 상호작용하는지에 관한 몇가지 기본적인 패턴을 나타낸다.

소프트웨어 배포

소프트웨어가 여전히 CD-ROM 또는 플로피 디스크 등의 물리 매체로 이용가능하지만, 대부분의 형태의 소프트웨어에 대해 전자 배포 수단이 보편화되었다. 회사 사용을 위해 설계되어 있는 Microsoft, Marimba, Altiris 및 기타 등의 벤더에 의해 제공되는 것 및 인터넷 또는 공중 액세스 네트워크를 위해 설계된 Digital River 및 기타 등등의 다른 것 등의 많은 형태의 ESD 시스템이 있다. ESD 시스템은 얼마간 완전히 또는 비교적 자동화된 방식으로 다운로드되어 설치될 수 있는 설치 패키지의 형태로 애플리케이션 소프트웨어를 최종 사용자 및 회사에 제공한다. 이 소프트웨어의 사용에 있어서, 이는 종종 충돌하는 의존 관계 또는 다른 구성 오류(misconfiguration) 등의 설치 문제를 야기한다.

다른 소프트웨어 벤더는 소프트웨어가 사용될 때, 즉 "주문 시에(On Demand)" 소프트웨어를 배포하는 시스템을 개발하였다. 이들 시스템에서, 애플리케이션 패키지는 소프트웨어를 사용해야만 하는 최종 사용자 시스템으로 필요에 따라 배포된다. 이 소프트웨어는 이어서 설치되고 동작 중에 타겟 시스템으로부터 제거될 수 있거나 어떤 경우에 "가상적으로 설치"(즉, 소프트웨어가 실제로는 설치되지 않았지만 설치된 것처럼 최종 사용자 시스템 상에서 동작)될 수 있다. 가상 설치 기술은 애플리케이션이 설치된 것처럼 실행되도록 보장해주지만, 그 애플리케이션을 운영 환경 및 다른 애플리케이션으로부터 격리시킨다.

마이크로소프트 ClickOnce 또는 Sun의 자바 관리 프레임워크(Java Management Framework) 등의 몇가지 다른 기술들이 시장에 제공되었다. 이들 시스 템 중 다수에서, 소프트웨어를 설치하는 문제는 개념적으로 소프트웨어 설치가 그의 호스트 환경을 수정하지 못하도록 함으로써 방지된다. 이것은 임의의 호환 소프트웨어가 구성 파일 등의 무해한 내부 소스로부터 그의 구성의 전부를 수집하게 하고 또 임의의 시스템 전반적인 레지스트리 또는 다른 애플리케이션 구성 엔티티를 사용하지 않음으로써 행해진다. 이 소프트웨어는 또한 호스트 운영 체제 내에서의 설정을 요구하지 못하도록 또는 어떻게든 그의 호스트를 수정하지 못하도록 제한되어 있다.

일반적으로, 소프트웨어는, 수정을 실제로 수행하지 않고 그 수정을 가장하는 가상 설치를 통해 또는 완비된 소프트웨어(self-contained software)의 생성에 의한 환경 수정의 제한을 통해, 그의 호스트 구성의 수정에 의해 타겟 운영 환경에 설치되도록 할 수 있다. 이들 시스템에서, 소프트웨어의 제거는 소프트웨어가 어떻게 설치되었는지에 연계되어 있다. 정상적으로 설치된 경우, 그 설치는 취소 절차(reversal procedure) 또는 제거 프로그램(uninstallation program)에 의해 철회되어야만 한다. 이들 프로그램은 종종 실패하고 호스트 환경에 손상을 야기한다. 가상 설치 시스템의 경우, 소프트웨어는 결코 설치되지 않으며, 따라서 제거할 필요가 없다. 완비된 환경에서, 역시 비침입적(non-invasive)적으로 행해질 수 있는 간단한 제거 절차(uninstallation procedure)를 보장함으로써 제거가 간단화된다.

통합 문제

기술된 시스템 및 소프트웨어의 실행을 위한 임의의 시스템 전부에서, 하나 이상의 소프트웨어 애플리케이션의 그의 호스트 환경 및/또는 동일한 환경에서 설 치 또는 실행될 하나 이상의 부가적인 애플리케이션과의 있을 수 있는 상호작용의 특성을 어떻게 기술할지 및 그 상호작용을 어떻게 용이하게 해줄지에 관한 문제가 있다. 많은 애플리케이션은 함께 동작하도록, 상호 통신하도록 설계되어 있거나 또는 그의 호스트 환경을 수정함으로써 동작하도록 설계되어 있다. 애플리케이션간 연관의 많은 다른 방식이 있으며, 본 명세서에 기술된 것들은 단지 해결될 문제의 예시적인 경우로서 사용되지만, 이 문제는 모든 또는 대부분의 기지의 방식에 퍼져 있다.

서로 함께 동작하도록 설계되어 있는 애플리케이션들은 일반적으로 몇가지 패턴 중 하나를 따른다. 첫째, 많은 애플리케이션들은 "플러그 인"할 다른 애플리케이션에 대한 호스트이다. 이것의 일례가, 써드 파티 소프트웨어 벤더가 그의 주요 애플리케이션에 대한 확장을 생성할 수 있게 해주는 기능을 제공하는, Adobe Photoshop 또는 Autodesk AutoCAD이다. 이 플러그-인의 존재 시에, Photoshop 사용자 인터페이스는 최종 사용자에게 다르게 보이며, 플러그-인에 의해 제공된 새로운 기능을 포함하고 있다. 최종 사용자 눈에 보이는 변화가 있을 필요는 없다. 이는 통상적인 플러그-인의 단지 하나의 동작 방식이다.

다른 대안으로서, 어떤 프로그램들은, 최초의 벤더가 의도하지 않았지만, 프로그램의 미등록 인터페이스(undocumented interface)를 이용함으로써 또는 그의 런타임 거동을 다른 방식으로 수정함으로써 "플러그-인"의 외관을 가장할 수 있다. 프로그램 및 그의 사용자 인터페이스를 다른 것 내에 내장하는 등의 다른 소프트웨어 프로그램의 래퍼를 제공하는 몇가지 프로그램이 존재한다. 래퍼 내에서 어떤 기능이 선택될 때, 호스트는 어떤 작업을 수행하기 위해 다른 애플리케이션을 구동할 수 있다. 이것은 또한 다른 소프트웨어 애플리케이션을 호스트하지 않고 사용자의 요청 시에 단지 그것만을 기동시키는 "런처(launcher)" 프로그램의 작성을 통하는 등의 느슨한 통합(loose integration)일 수 있다.

몇가지 애플리케이션은 그의 작업의 일부를 수행하기 위해 다른 애플리케이션을 사용한다. PDA 애플리케이션 등의 소프트웨어는 연락처 정보를 동기화시키기 위한 그의 데이터 저장소로서 Microsoft Outlook 등의 연락처 관리자를 사용한다. Outlook은 PDA 애플리케이션의 일부로서 출하되지 않으며, 이 소프트웨어는 그의 동기화 작업을 수행하기 위해 Outlook과 통신할 수 있다. 많은 프로그램들이 메일 머지 기능을 수행하기 위해 Microsoft Word를 이용한다.

프로그램들은 또한 작업을 수행하기 위해 표준의 또는 독점적인 수단을 통해 서로 통신할 수 있다. 이것은 COM/DCOM, MTS, CORBA, SOAP 또는 기타 수단을 통한 RPC(Remote Procedure Call, 원격 절차 호출) 등의 어떤 것일 수 있다. 이것은 원시 TCP/IP 통신 세션 또는 심지어 HTTP 요청 등의 어떤 것일 수 있다. 여기서의 주된 문제는 상호 통신의 이용가능성이 주된 애플리케이션이 거동하는 방식을 변경할 수 있다는 것이다. 예로서, 패킷 덤퍼(packet dumper) 또는 통신 문제 해결 프로그램이 종종 많은 서로 다른 통신 프로토콜을 보고 포맷(format)할 수 있다. 그렇지만, 여러분이 CORBA를 사용하는 환경에 있지 않은 경우, 여러분은 그 프로토콜을 구성할 필요가 없다. 이 구성은 그의 호스트 또는 근방의 호스트(nearby host)가 이 프로토콜을 사용하도록 구성되어 있는지 여부를 검출함으로써 행해질 수 있 다.

프로그램들은 또한 데이터 파일 또는 공통 데이터베이스의 공유를 통해 느슨하게 상호 연동될 수 있다. 이것은 간단한 파일 공유를 통하거나 OLE 또는 OpenDoc 등의 복합 문서 인터페이스(compound document interface)를 통할 수 있다. 복합 문서의 경우, 특정의 복합 문서는 그의 내부 문서 구조의 여러 부분을 호스팅할 수 있는 소프트웨어 애플리케이션의 존재 및 통합에 의존한다. 데이터베이스 시스템의 경우, 결합(coupling)은 종종 아주 느슨하지만, 여전히 통합을 가져오기 위해 어떤 구성이 존재할 것을 요구한다.

마지막으로, 많은 프로그램은 서로 다르게 구성되어 있는 유사한 운영 체제의 존재 시에 서로 다르게 동작할 수 있거나 특정의 호스트 운영 환경 또는 다른 소프트웨어 애플리케이션을 구성하는 목적을 가질 수 있다. 간단한 예시적인 프로그램은, Microsoft Windows 데스크톱 환경의 구성 및 운영 체제의 많은 다른 측면을 변경하는 데 사용되는 프로그램인, TweakUI이다.

상기한 경우들 모두에서, 소프트웨어 애플리케이션은 그의 세계관에서 독보적인 체하거나 의도적으로 다른 애플리케이션 또는 호스트 환경의 존재 시에 다르게 기능한다. 이것은 상기한 소프트웨어 배포 시스템에 대한 문제를 일으킬 수 있다. 가능한 연관 모두가 배포 또는 설치 시에 알려져 있는 것은 아닌 경우가 대부분이다. 따라서, 배포 시스템은 변화에 적응하는 수단을 제공해야만 한다.

애플리케이션이 배포를 위해 구성되면, 그 애플리케이션은 환경이 변화하는 경우 종종 재구성되어야만 한다. 게다가, 구성 동안에, 그의 연관 모두는 알려져 있어야만 하거나 적절히 구성되어 있지 않을 수 있다. 가상 설치 환경의 경우에, 디폴트 거동은 의도적으로 임의의 프로그램 연결을 분리(disassociate)시키는 것이다. 따라서, 이 제한을 극복하는 수단이 제공되어야만 한다. 또는, 완비된 환경의 경우에, 컨테이너 패러다임(container paradigm)을 위반하지 않는 타당한 연관 수단이 발견되어야만 한다.

가시성/발견성(visibility/discoverability)

2개의 애플리케이션이 상호 연동하기 위해, 이들은 어떤 시점에서 서로에게 보여야만 있어야만 한다. 이것은 설치 시 또는 런타임 시에 발견 수단을 통하거나 이들 시기에 상대편에게 보이는 하나의 프로그램의 어떤 발현(manifestation) 또는 인터페이스에 의할 수 있다.

가시성의 문제는 꽤 복잡할 수 있는데 그 이유는 프로그램들이 종종 비결정론적이거나 미등록 수단을 사용하여 서로를 찾기 때문이다. 존재는 예를 들어 통합될 애플리케이션의 존재를 탐색함으로써 판정될 수 있다. 이것은 예를 들어 그의 실행가능 컴포넌트 중 하나 이상을 검색함으로써, Windows 레지스트리 등의 통상의 레지스트리 내에서 그의 구성을 검색함으로써, 실행 단축키 또는 UNIX/var/opt 또는 /etc 파일 시스템 장소 내의 그의 구성 등의 어떤 공통 장소 내의 애플리케이션의 트레이스(trace)를 검색함으로써, 공통 장소에 있는 그의 인터페이스 중 하나 이상을 검색함으로써, 그의 존재에 대해 그의 호스트 운영 환경에 질의함으로써, 또는 많은 대안적인 방법들 중 하나에 의해 행해질 수 있다.

가상 설치 기술 등의 시스템에서, 프로그램이 문제의 호스트 상에서 실행하 도록 구성되어 있을지라도, 이들 검색 수단을 통한 발견이 실패할 수 있다. 가상 설치 기술에 있어서, 호스트 환경 상에서 프로그램의 트레이스가 없다. 그의 이용가능성에 대한 유일한 정보는 애플리케이션을 서버로 전달하도록 구성되어 있는 서버에 존재한다. 또한, 어떤 가상 설치 시스템은 데스크톱 시스템과 같은 것들에 호스트 통합을 제공하며, 따라서 단지 이러한 한 형태의 발견을 실행가능한 것으로 만들어주지만, 애플리케이션은 이와 같이 그의 발견을 행하도록 구성되어 있지 않다. 가상적으로 설치된 소프트웨어 컴포넌트는 디폴트로 어떤 것에도 보이지 않고 실제 소프트웨어 자체에만 보인다. 따라서, 발견이 행해지기 위해서는, 용이하게 해주기 위한 대안적인 수단이 제공되어야만 한다.

완비된 환경의 경우에, 호스트 환경 내에서의 소프트웨어 컴포넌트의 실제의 발현이 상당히 다를 수 있다. 예를 들어, Microsoft ClickOnce 기술은 시스템의 나머지에 은폐되어 있는 또는 그의 존재 동안에 변할 수 있는 장소에 소프트웨어 애플리케이션의 실행가능 컴포넌트를 배치할 수 있다.

발견은 또한 소프트웨어의 중앙 저장소(central repository) 또는 분산된 저장소(decentralized repository)를 통해 행해질 수 있다. UDDI 또는 JNDI 등의 시스템은 인터페이스 계층에서 소프트웨어 애플리케이션의 발견 수단을 제공한다. UDDI 내의 기록의 존재는 미리 정해진 또는 동적 종단점(endpoint)에서 소프트웨어의 이용가능성을 암시한다. 가상 설치 기술에서, 이 환경 내에서의 UDDI 질의가 애플리케이션의 존재를 리졸브하고 이 환경 밖에서는 리졸브하지 않도록, 이 종단점은 종종 가상 설치 환경 내에만 존재할 수 있다. 또는 다른 대안으로서, UDDI 또는 JNDI 질의는 단지 가상 애플리케이션에 대한 프록시인 동적 종단점으로 리졸브된다.

발견의 문제는 또한 설치시 및 설치후의 변화로 악화된다. 다른 것과 통합될 수 있는 한 애플리케이션이 기계 상에 설치되지만 제2 애플리케이션이 설치되지 않는 경우, 그 애플리케이션은 그 자신을 상호 연동하도록 구성하지 않을 수 있다. 제2 애플리케이션이 차후에 설치되는 경우, 상호 연동을 구성하기 위한 로직이 제1 소프트웨어 애플리케이션의 설치 시에만 행해지는 경우가 많다. 따라서, 제1 애플리케이션은 통합을 제공하기 위해 재설치되어야만 한다.

게다가, 애플리케이션이 제2 애플리케이션과 통합하도록 구성되어 있고 제2 애플리케이션이 제거되는 경우, 제1 애플리케이션은 제거 프로세스를 재구성하거나 처리할 수 있어야만 한다. 실제로 알 수 있는 바와 같이, 이러한 경우는 많지 않다. 제2 애플리케이션의 제거는 제1 프로그램이 동작하지 않게 하거나 다른 방식으로 제대로 동작하지 않게 할 수 있다.

애플리케이션의 존재는 또한 런타임시에 판정될 수 있고 애플리케이션에 대한 거동 변화를 야기할 수 있다. 소프트웨어 애플리케이션은 공지의 인터페이스를 통해 그와 대화하려고 시도함으로써, 호스트 상에서 실행 중인 그의 프로세스를 탐색함으로써, 그의 애플리케이션 창들 중 하나 이상을 찾아냄으로써 또는 MTS, CORBA 또는 DCOM 등의 브로커 서비스(broker service)를 사용함으로써 다른 프로그램을 검출할 수 있다.

상호 통신

애플리케이션이 상호 연동하도록 구성되어 있으면, 이들은 여전히 상호 통신하는 수단을 가지고 있어야만 한다. 통상적인 단일 사용자 실행 환경에서, 호스트 구성에서 무언가가 변화하여 실행이 실패하게 하지 않는 한, 이것은 거의 문제가 되지 않는다. 그렇지만, 가상 설치 환경에서, 다중-시스템 환경에서, 또는 다중-사용자 환경에서, 상호 통신은 부가적인 구성이 없으면 적절히 동작하지 않을 수 있다.

운영 체제 가드의 통상의 동작 모드에서, 디폴트 통신 종단점은 어떤 기존의 종단점과의 충돌 가능성을 제거하기 위해 목표 변경(retarget)된다. 따라서, 한 애플리케이션이 다른 것과 통신하려고 시도할 때, 양쪽 애플리케이션이 존재하고 서로에 관하여 알도록 구성되어 있는 경우에도, 통신은 실패하게 된다. 이것은 각각의 통신 종단점이 서로 다르게 목표 변경되도록 시스템이 보장한 결과이다. 따라서, 통신 세션이 연결되고 적절히 동작하도록 보장하기 위해 목표 변경하는 프로세스를 조정하는 시스템이 운영 체제 가드에 의해 제공되어야만 한다.

다중-사용자 환경의 경우, 이 문제가 비슷하다. 프로그램이 동일 호스트 상의 2명 이상의 사용자에 의해 사용되는 경우, 통신 종단점은 사용자별로 변할 수 있어야만 하고 또한 각각의 사용자에 대해 동일하게 목표 변경되어야만 한다. 마이크로소프트 단말기 서비스(Microsoft Terminal Service) 또는 Citrix MetaFrame에서, 세마포어(semaphore) 및 뮤텍스(mutex) 등의 통신 종단점은 이미 단말기 세션 내에서 유일하도록 재작성되어 있지만, 단일의 세션 내의 동일한 프로그램의 다수의 인스턴스가 여전히 이 문제를 나타낼 수 있다. 게다가, 소켓, COM, 명명된 파이프(named pipe) 등의 표준 통신은 항상 기계에 전역적이며 결코 차단(mute)되지 않으며, 따라서 문제가 일어나게 한다.

운영 체제 통합

대부분의 최근의 소프트웨어는 어떤 방식으로 그의 호스트 운영 환경과 통합하도록 설계되어 있다. 데스크톱급 소프트웨어는 일반적으로 프로그램 단축키 또는 소프트웨어 제품에 액세스하는 다른 간단한 수단을 제공한다. 이들 단축키는 운영 체제가 제품을 실행하기 위한 사용자 인터페이스를 디스플레이할 수 있게 해준다. 대부분의 경우에, 서버급 소프트웨어는 관리 및 간단한 기동/정지 구성을 위한 인터페이스를 제공한다.

모든 경우에, 호스트 운영 체제는 설치된 소프트웨어에 액세스하기 위한 어떤 수단을 제공해야만 한다. 종종, Windows Shell 또는 UNIX CDE 또는 KDE 등의 데스크톱 쉘(desktop shell)은 소프트웨어에 대한 공통의 룩앤필(look-and-feel) 및 통합 포인트를 제공하는 데 사용된다. 이들 접점(touch point)과 통합하기 위해 그의 소프트웨어를 정확한 수단에 설치하는 것은 소프트웨어 벤더의 책임이다. 이들 인터페이스 중 어떤 것은 단축키와 같이 간단하고 다른 것들은 사용자가 마우스의 우측 버튼을 클릭할 때 사용되는 컨텍스트 메뉴와 같이 보다 복잡하다.

또한, 소프트웨어 및 하드웨어를 관리하기 위해 공통의 명령 또는 사용자 인터페이스가 사용될 수 있게 해주는 관리 인터페이스가 있다. 마이크로소프트 관리 콘솔(Management Console) 또는 마이크로소프트 윈도우 인스톨러(Windows Installer) 또는 Linux rpm 데이터베이스와 같은 것들은 운영 체제 내에서 관리 정 보를 찾기 위한 공통의 장소를 제공한다.

추가 또는 제거될 수 있거나 또는 가상적으로 설치될 수 있거나 또는 주문 시에 다른 방식으로 제공될 수 있는 소프트웨어의 존재 시에, 이들 인터페이스는 또한 동적이거나 동적으로 관리될 수 있어야만 한다. 운영 체제의 동작 거동은 그의 활성 애플리케이션의 속성을 반영하도록 되어 있다.

버저닝

통합 및 상호 연동의 문제는 소프트웨어 프로그램 또는 그의 인터페이스의 2개 이상의 버전의 존재에 의해 더욱 악화된다. 2개의 프로그램이 통신하고 그 프로그램 중 하나가 다수의 버전을 갖는 경우, 그 프로그램의 어느 버전을 사용하는지를 알기 위한 수단이 있어야만 한다. 통상적으로 프로그램의 단지 하나의 버전만이 호출측 프로그램과 정확하게 동작하게 된다. 이와 같이, 2개의 프로그램 간에 의존 관계가 존재하는 것으로 알려져 있다. 그렇지만, 프로그램의 2개의 버전 둘다가 정확하게 동작하는 경우, 버전 독립성을 나타내도록 의존관계가 명확하게 표현되어야만 한다.

마이크로소프트 COM 아키텍처 등의 많은 시스템은 프로그램이 상호 통신하기 위해 버저닝된 인터페이스(versioned interface)를 제공한다. 이 시스템에서, 프로그램 인터페이스는 GUID(Globally Unique Identifier) 및 그 자신을 식별하는 데 사용할 하나 이상의 이름을 부여받는다. 게다가, 프로그램은 버전 독립적인 식별자를 부여받을 수 있다. 이 식별자는 프로그램이 프로그램의 버전과 상관없이 그와 통신할 수 있음을 암시한다.

실제에 있어서, 이들 유형의 식별자는, 실제로 버전 의존관계가 존재할 때, 종종 잘못 사용된다. 대부분의 초보 프로그래머들은, 버전 독립적인 식별자를 사용하는 경우, 그 식별자가 항상 자신들이 찾고 있는 것으로 리졸브되는 것으로 생각한다. 이것은 작성된 프로그램이 의존적인 소프트웨어의 가장 최신의 버전과 항상 정확하게 동작할 것을 요구한다. 의존적인 소프트웨어가 변경되고 버전 독립적인 인터페이스가 존재하더라도 더 이상 호환하지 않는 경우, 문제가 발생하게 된다. 해결될 수 없는 경우가 종종 있는 이들 오류를 해결하는 것은 소프트웨어 배포 시스템에 맡겨져 있다.

다른 대안으로서, 많은 프로그램은 버전 의존적인 또는 독립적인 인터페이스를 갖지 않지만, 그럼에도 불구하고 테스트 또는 통상의 관행을 통해서만 이해되는 버전 의존 관계를 갖는다. 다른 프로그램의 사용자 인터페이스를 구동하는 프로그램은 종종 그의 윈도우 컨트롤이 특정의 물리적 위치에 있거나 특정의 클래스 이름을 갖는 것으로 예상한다. 동일 프로그램의 다른 버전은 이들 기대에 충실하지 않을 수 있다. 이 경우에, 구동 프로그램은 소프트웨어의 제1 버전만을 정확하게 사용할 수 있다.

이 문제의 반대도 역시 존재한다. 다른 프로그램을 구동하거나 그와 통신할 필요가 있는 프로그램이 있고 또한 윈도우 클래스 이름 등의 특정의 종단점을 사용해서만 그렇게 할 수 있는 경우, 구동될 소프트웨어의 2개의 개별적인 버전이 실제로는 동일한 종단점을 사용할 수 있다. 이 경우에, 구동 프로그램이 원하는 종단점에서 소프트웨어의 정확한 버전에 연결되지만 여전히 동일한 종단점을 사용하여 소프트웨어의 다른 버전의 동작을 용이하게 해줄 수 있을 필요가 있다.

네이밍(naming)

상기한 바와 같이 문제의 상당 부분이 이름을 이해하는 기본적인 문제이다. 이름은 많은 형태로 있게 되고 서로 다른 상황 또는 "컨텍스트"에서 많은 아주 서로 다른 것들이 있을 수 있다.

컴퓨터 시스템에서, 명명된 객체는 거의 무엇이든지 될 수 있다. 파일은 이름 "C:＼Windows＼notepad.exe"를 갖는다. 레지스트리 키는 "HKLM＼Software＼Microsoft＼Windows＼CurrentVersion＼Run"이고, 명명된 파이프는 ＼＼PIPE＼ExamplePipe이며, 폰트는 "Tahoma Bold"이고, HTTP 통신을 위한 TCP 포트는 80이며, 데이터베이스에서의 테이블의 이름은 USERS이다. 심지어 GUID(globally unique identifier, 전역적으로 고유한 식별자)도 기본적으로 어떤 객체에 대한 이름이다. 실제 사용에서, 많은 다른 객체는 그의 이름이 의미있게 되도록 명명된다. 뉴스 기사의 제목, 뉴스 기사의 저작자 또는 그의 발행인일 수 있다.

객체가 명명되면, 객체를 찾아내기 위해 제공된 이름을 사용한다는 묵시적인 이해가 있다. 2개의 객체가 동일한 이름을 갖는 경우, 문제의 해당 객체를 리졸브하는 어떤 프로세스가 조절되어야만 한다. 별개의 애플리케이션들이 공통 객체를 이용하려고 시도하는 경우, 통상적으로 애플리케이션들은 그 단일 객체를 리졸브한다. 그렇지만, 하나의 애플리케이션이 그 객체를 수정하는 경우, 그 수정된 객체가 더 이상 제2 애플리케이션에 의해 사용되지 않게 하는 것이 종종 요망된다. 따라서, 각각의 애플리케이션은 동일한 이름을 사용하는 서로 다른 객체를 리졸브하 는 방법 및 변화하는 객체를 추적하는 수단을 가질 필요가 있다.

게다가, 명명된 객체가 존재하고 또한 동일한 객체가 가상적으로 설치된 애플리케이션 내에 존재하는 경우, 가상 애플리케이션은 그의 내부 객체를 리졸브함으로써 동작하지만, 여전히 가상 환경 외부의 프로그램에 대한 가상 객체를 찾아낼 필요가 있다.

따라서, 애플리케이션 및 객체가 가변적인 수명, 그의 수명에 걸쳐 서로 다른 의미, 및 잠재적인 충돌을 갖는 네트워크에서, 이들 객체의 상호작용을 관리하기 위해 통합된 해결책이 필요하다. JNDI 또는 UDDI 등의 현행 기술의 시스템은 이들 특성을 반영하지 않는 절대 정보를 제공하기 위해 정보의 시스템 전반적인 레지스트리에 의존한다. JNDI 질의는 연결 지점(junction point)을 생성함으로써 서로 다른 이름 공간을 통합(unite)할 수 있다. 그렇지만, 시스템의 사용자는 그렇게 하지 않는 것에 의해서만 네이밍 충돌(naming collision)을 처리해야만 한다. 실제로, 이것은 아주 어려운데 그 이유는 많은 시스템이 그의 작업을 수행하기 위해 객체에 대한 공통이지만 서로 다른 정의를 가지고 있어야만 하기 때문이다. JNDI 시스템은 이름 공간을 폴딩(folding) 또는 머징(merging)하는 수단도, 버저닝 또는 충돌 관리를 제어하는 수단도 제공하지 않는다.

컨텍스트

상기한 문제들에 대한 해결책은 현재 시나리오와 관련하여 적절한 구성, 명명된 객체 또는 인터페이스를 제공하는 기능의 존재 시에 해결된다. 본 명세서에 기술된 실시예들은 a) 소프트웨어 프로그램의 상호 의존 관계를 자동적으로 이해하 고, b) 프로그램이 공유할 수 있는 동작 컨텍스트를 생성 및/또는 그의 호스트 운영 환경의 유사한 관점을 수정하며, c) 이들 컨텍스트의 인에이블링(enabling) 또는 속성을 제어하고, d) 그렇지 않으면 실패하게 될 이들 프로그램의 상호 통신 및 상호 연동을 용이하게 해주는 시스템을 나타낸다.

이 실시예들은 호스트 운영 환경에서 하나 이상의 프로그램을 동작시키고 제어된 방식으로 다수의 시스템의 거동을 서로 연결시키는 방법을 제공한다. 도 5에 도시된 예시적인 시스템(150)에서, 하나 이상의 컴퓨팅 장치가 존재할 수 있다. 이들 장치는 운영 체제 및 하나 이상의 애플리케이션이 실행되는 단일 사용자(155) 또는 다중-사용자(156) 장치일 수 있다. 또한, 데이터베이스 서버, 파일 서버 또는 기타의 사업 분야 애플리케이션 서버와 같은 서버 시스템 등의 인프라 서비스(158)는 물론, 네트워크 및 시스템을 관리하는 어떤 인프라(157)가 존재할 수 있다.

소프트웨어 애플리케이션이 장치들의 네트워크 내에서 실행되는 경우, 그 애플리케이션은 따라서 몇가지 레벨에서 다른 소프트웨어와 상호작용할 수 있다. 양호한 실시예에서, 기본적인 레벨은 글로벌(Global), 관리(Managed), 로컬 시스템 컨텍스트(Local System), 시스템 가상(System Virtual), 벤더(Vendor), 사용자, 세션(Session), 공유(Shared), 및 격리(Isolated)를 포함한다. 이들 레벨은 도 6 및 도 7에 도시되어 있다. 이들 그룹은, 환경간 상호작용의 정책 기반 제어를 가능하게 해주기 위해 확장된, 애플리케이션이 실행되는 런타임 환경에 대응하는 컨텍스트라고 한다. 당업자라면 다른 컨텍스트가 간단히 생성될 수 있고 본 명세서에 정 의된 것들이 본 발명의 응용예들이라는 것을 잘 알 것이다.

글로벌 컨텍스트(201)는 도 5에 예시된 실시예에서 전체 시스템의 뷰이다. 글로벌 컨텍스트 내에 존재하는 객체 또는 이름은 보안 정책에 의해 허용된 바에 따라 모든 사용자 및 모든 소프트웨어 프로그램에 의해 볼 수 있고 공유될 수 있다. 대체 실시예에서, 글로벌 컨텍스트는 회사의 모든 기계를 포함하는 회사(Corporate) 컨텍스트(204), 회사들 간의 공유 컴퓨팅을 위한 연합(Federated) 컨텍스트(206), 및 모든 참가하는 개체를 포함하는 글로벌(Global)(201) 또는 분산(Distributed) 컨텍스트를 포괄하도록 변경될 수 있다.

관리 컨텍스트(207)는 어떤 관리 범위 내의 일련의 기계, 사용자, 리소스 및/또는 애플리케이션의 전반적 뷰(wide view)이다. 이 범위는 ESD 솔루션 또는 가상 설치 시스템(214) 중 하나 등의 분산 시스템에 의해 관리되는 일련의 시스템일 수 있다. 이는 구획 내에서 회사 경계를 넘어 확장될 수 있거나, 관리 시스템이 ASP 등의 서비스 제공자(202)에 의해 호스팅되는 경우, 이 컨텍스트는 제공자의 고객 시스템(204, 205)을 넘어 확대될 수 있다. 본 발명의 방법들을 구현하는 임의의 시스템이 다른 관리 시스템 및 그 자신의 다른 인스턴스와 상호 연동하도록 이 컨텍스트가 존재한다.

로컬 시스템 컨텍스트(302)는 특정의 기계(301) 또는 가상 기계(VMWare 파티션 등) 내에서의 모든 동작들의 뷰를 제공한다. 이것은 마이크로소프트 단말기 서비스 "글로벌" 컨텍스트와 동등하다. Citrix 및 마이크로소프트로부터의 종래 기술의 시스템은 기계를 글로벌 및 세션 관련 이름 공간으로 세분함으로써 이들 컨텍 스트 문제 중 일부를 해결하려고 시도하였다.

시스템 가상 컨텍스트(310)는 가상 설치 기술 또는 운영 체제 가드에 의해 전달되는 것 등의 프로그램이 동작 및 객체를 로컬 운영 체제와 공유하여 이들 둘다가 동일한 이름 공간 내에서 동작할 수 있게 해준다. 특정의 시스템 가상 컨텍스트는 운영 체제로 하나 이상의 애플리케이션을 캡슐화한다. 모든 애플리케이션이 동일한 방식으로 OS를 공유할 필요는 없다.

벤더 컨텍스트는 소프트웨어 벤더가 기계 내에 존재하지만 그의 소프트웨어 또는 하드웨어를 사용하는 시스템과 관련되어 있는 모든 동작을 포괄하는 범위를 생성할 수 있게 해준다. 일 실시예에서의 한 예는 동일한 기계 상의 다른 소프트웨어와 공존하게 되는 시스템에 의해 관리되는 소프트웨어이다. 벤더 컨텍스트 내에서 소프트웨어는 무엇이 관리되고 무엇이 관리되지 않는지에 기초하여 그룹화된다.

사용자 컨텍스트(211)는 동작들을 사용자에 의해 행해지는 그 동작으로 그룹화하는 기능을 제공한다. 유의할 점은 이 컨텍스트가 단 하나의 기계 상에 존재하는 것으로 제한되지 않는다는 것이다. 이 컨텍스트는 이 사용자를 위해 동작을 실행하고 있는 다수의 기계 또는 세션에 걸쳐 확장될 수 있다. 이 거동은 네트워크에서 실행 중인 2개 이상의 세션을 갖는 사용자로 하여금 사용자가 실행하고 있는 애플리케이션들 간의 조정을 할 수 있게 해준다.

세션 컨텍스트(212)는 동작을 하나의 기계 상의 한명의 사용자의 동작으로 제한한다. 이것은 단말기 서비스의 로컬 사용자 이름 공간 또는 기계에 로그인되 어 있는 사용자가 식별가능한 범위를 가지게 되는 UNIX telnet/tty 세션에 관련되어 있다.

도 7에 도시되어 있는 공유 컨텍스트(312)는 관리상 정의되는 독자적인 공유 구성 의존적인 범위를 제공한다. 이 범위는 2개 이상의 프로그램이 구성 및 객체를 공유할 수 있게 해주거나 서로에게 보일 수 있게 해준다. 본 발명의 양호한 구현에서, 다수의 공유 컨텍스트가 있다. 각각의 컨텍스트는 이름 및 공유 거동을 정의하는 일련의 정책을 포함한다. 이와 같이, 애플리케이션의 다수의 서로 다른 세그먼트가 중복하는 거동을 공유할 수 있다.

도 7에 도시되어 있는 격리 컨텍스트(311)는 가상 설치된 애플리케이션에 대한 디폴트 거동이다. 이 범위에서, 애플리케이션은 모든 다른 프로그램으로부터 완전히 격리되어 있고 어떤 의미에서 보이지 않으며, 모든 통상의 인터페이스 및 명명된 객체는 컨텍스트를 벗어나 존재하지 않는다.

이들 예시적인 컨텍스트는 본 발명의 실시예들이 설계에 있어서 어떻게 명시적으로 계층적일 필요가 없는지를 보여준다. 운영 체제 가드가 운영 체제와 개개의 애플리케이션 간의 또한 애플리케이션들 간의 계층으로서 동작하지만, 애플리케이션 또는 컨텍스트가 계층적으로 층을 이루고 있어야 한다는 제한은 없다. 이 효과는 용이하게 달성될 수 있지만, 본 발명의 시스템은 네트워크 또는 시스템 아키텍처에 의해 제한되지 않는 1 내지 n개의 환경을 서로 연결시킬 수 있다. 이것에 의해, 나타낸 바와 같이, 다수의 기계에 걸쳐 있을 수 있는 사용자 컨텍스트 등의 컨텍스트가 생각될 수 있다.

동작 특성

일 실시예에서의 시스템은 프로그램과 호스트 운영 체제 간의, 프로그램들 서로 간의, 또는 운영 체제 내에서의 통상적인 통신을 가로채기하는 소프트웨어 계층으로서 설계되어 있다. 대안적인 실시예에서, 시스템은 이 시스템의 기능들을 이용할 수 있도록 특별히 구성된 프로그램으로 컴파일하기 위한 코드 라이브러리로서 구현된다. 각각의 개별적인 애플리케이션 요청은 이어서 그의 특정의 동작 컨텍스트 내에서 평가될 수 있다. 시스템은 파일 시스템 요청, 레지스트리 요청, 공유 객체, 폰트, 코드 라이브러리, 및 기타 등등의 모든 유형의 요청을 살펴본다. 이들 요청은 일반적으로 구성 항목, 명명된 객체 또는 통신 인터페이스(이에 한정되지 않으며, 이들은 일률적으로 리소스라고 함)에 대한 것이다. 리소스는 가변적인 수명을 가지며, 그의 사용의 지속 기간을 넘어서 존속하거나 존속하지 않을 수 있다.

도 8에 도시된 시스템에서, 서로의 리소스 및 운영 체제를 이용하는 2개의 애플리케이션이 도시되어 있다. 3가지 서로 다른 시나리오가 도시되어 있다. 한 시나리오에서는, 프로그램, 즉 애플리케이션 A(402)가 그 자신만이 사용하도록 구성되어 있는 리소스, 즉 리소스 세트 1(404)를 사용하려고 시도하고 있다. 다른 시나리오에서는, 애플리케이션 A(402)가 다른 프로그램을 위해 구성된 리소스, 즉 애플리케이션 B(403)를 위해 구성된 리소스 세트 3(406)를 사용하려고 시도하고 있다. 마지막으로, 한 시나리오에서는, 양쪽 프로그램 둘다가, 각각의 프로그램에 의한 액세스를 위해 구성되어 있을 수 있는, 공유 리소스, 즉 리소스 세트 2(405) 에 액세스하려고 시도하고 있다. 유의할 점은 동 도면이 발명의 명칭이 "운영 체제 보호 및 추상화 계층(Operating System Protection and Abstraction Layer)"인 미국 특허 출원 제09/859,209호와 기능상으로 동등하지만 프로세스를 명확히 하도록 도시되어 있다는 것이다.

동 도면은 시스템의 기본적인 전제를 나타낸 것으로서, 하나 이상의 리소스는 애플리케이션에 사적이도록 구성될 수 있거나 그들 리소스는 공유될 수 있다. 공유는 일련의 공유 라이브러리 등의 하나 이상의 프로그램에 이용가능한 일단의 리소스로서 행해질 수 있다. 공유는 또한 하나의 프로그램이 그의 리소스를 다른 프로그램과 공유할 수 있게 해주도록 수행될 수 있다. 역으로, 사적인 상태(privacy)는 하나의 프로그램의 리소스가 다른 프로그램에 이용가능하지 않도록 보장해준다. 모든 경우에, 매개물 계층은 공유 동작을 허용 또는 금지하는 일 또는 다른 방식으로 그 동작을 대안의 컨텍스트로 벡터링하는 일을 맡고 있다.

본 발명의 일 실시예에서, 각각의 세트(404, 405, 406) 내의 리소스는 개별적인 이름 공간 컨테이너 객체에 저장된다. 이들 객체는 이름 공간 유형 및 컨텍스트의 조합에 대한 분리 저장을 가능하게 해준다. 이름 공간 컨테이너의 예는 마이크로소프트 오피스에서의 사용자의 개인 설정(사용자 컨텍스트)에 대한 파일 시스템 컨테이너이다. 이들 컨테이너는 리소스의 저장이, 각각의 조합에 대해 적절한, 로컬화되고 독립적인 방식으로 행해지지만, 본 시스템의 기능들에 의해 정확한 이름 공간에 동적으로 배치될 수 있게 해준다. 리소스는 이름 공간 컨테이너에 존속될 수 있거나 단순히 적절한 리소스 또는 명명된 객체를 재생성하는 데 필요한 메타데이터일 수 있다.

많은 형태의 저장 장치, 데이터 구조, 기타 등등이 이 기능 또는 그에 상응하는 것을 달성하기 위해 이용될 수 있다는 것을 잘 알 것이다. 예를 들어, 이름 공간 컨테이너는 로컬 또는 네트워크 파일 시스템에 저장되어 있는 리소스 세트와 연관된 메타데이터 및 데이터 전부를 포함하는 단일의 파일일 수 있다. 다른 예시적인 실시예에서, 이름 공간 컨테이너는 기본 시스템 또는 원격 시스템으로 요청을 전달하는 프록시 객체일 수 있다.

본 발명의 시스템에서, 상호 연동의 3가지 기본적인 모델이 있다. 생산자/소비자 모델에서 하나의 애플리케이션은 다른 애플리케이션에 리소스 서비스를 제공하고 있을 수 있다. 이 모델의 특성은 상호간의 요구 없이 리소스 또는 서비스를 제공하기 위해 하나 이상의 프로그램이 다른 프로그램에 의존할 수 있는 일방향 연관이다. 이 모델에서, 소비자는 생산자의 필요한 통합 지점에의 액세스에서 제한을 받는다. 따라서, 생산자의 환경 및 이름 공간 컨테이너는 일반적으로 소비자가 액세스가능하지 않지만, 그 대신에 구성된 리소스 또는 프로그램적 인터페이스만이 허용된다. 이 모델의 예는, 그가 가지고 있는 회계 데이터로부터 스프레드쉬트를 생성하기 위해, Great Plains에 의한 마이크로소프트 Excel의 사용 등의 기능을 위해 마이크로소프트 오피스 등의 프로그램의 공통 사용이다. Excel 및 Great Plains은 유용하고 독립적인 프로그램으로서 기능하지만, 이들 모두는 이 기능을 추가할 수 있다. Great Plains은 단순히 Excel을 프로그램적으로 구동하기만 하면 되며, Excel 자체의 내부 구성 또는 상태에 액세스할 필요는 없다.

두번째 모델은 하나 이상의 프로그램이 협동적으로 리소스를 공유할 수 있는 피어(Peer) 모델이다. 이 모델에서, 공유는 허용되지만, 수정은 정책에 의해 정의된 바에 따라 엄격하고 구체적으로 제어된다. 피어의 환경 및 이름 공간은 단일의 이름 공간에서의 하나의 세트처럼 공존하는 것처럼 보이지만, 본 명세서에 정의된 정책에 따라 개별적으로 처리된다. 이 모델의 예는 공유 데이터베이스 드라이버 또는 마이크로소프트 오피스 플러그-인이다. 데이터베이스 드라이버는 기계 상의 많은 프로그램에 의해 공통으로 사용된다. 적절히 동작하기 위해, 이들 다른 프로그램은 드라이버의 구성에 관한 정보에 액세스해야만 한다.

마지막으로, 시스템은, 의존관계나 컨텍스트가 정의되지 않은 디폴트 경우인, 공유가 없는 비상호 연동 모드(non-interoperation mode)를 지원한다. 다른 대안으로서, 상기한 바와 같이, 이 모드와 관련되어 있는 격리 컨텍스트가 생성될 수 있다.

도 8에서 주 프로그램인 애플리케이션 A(402)가 동작하고 있을 때, 이는 리소스에 대한 요청을 한다. 애플리케이션 요청들 각각은 그의 관련 컨텍스트 및 이용가능한 범위를 결정하기 위해 소프트웨어 코어에 의해 평가된다. 이 코어는 도 9에 상세히 도시되어 있다. 요청(510)이 수신될 때, 컨텍스트 관리자(503)는 프로세스 관리자(504)에 의해 식별될 그의 소스를 요청한다.

프로세스 관리자(504)는 그의 호스트 상에서 실행 중인 프로세스들, 및 그들 프로세스(505)에 의해 취해지는 동작들의 뷰를 유지하는 일을 맡고 있다. 이 뷰는 부모 및 자식 프로세스 및 쓰레드의 프로세스 트리와 관련되어 있다. 이것에 의해 시스템은 어느 리소스 풀이 동작 중인 특정의 프로세스 또는 쓰레드에 대해 디폴트인지에 대한 기본적인 이해를 확립할 수 있다.

소스 리졸브(source resolution) 단계는 중요한 단계인데, 그 이유는 많은 요청들이 운영 체제로부터 나오는 것처럼 보이지만, 실제로는 이들이 애플리케이션에 의해 소싱된 것이기 때문이다. 이것의 예는 파일 시스템 호출이다. 파일에의 기록 요청은 운영 체제에 의해 지연되지만 애플리케이션 프로그램에 대해 실행될 수 있다. 나중에, 운영 체제가 그 기록을 디스크로 플러쉬할 때, 그 요청은 운영 체제 자체로부터 나오게 된다. 컨텍스트 관리가 적절히 동작하기 위해서는, 이 요청이 그의 발신지 프로그램에 다시 연계되어야만 한다. 프로그램이 마이크로소프트 윈도우 애플리케이션 관리 서비스 등의 다른 프로그램을 위해 일들을 행하는 다른 예시적인 경우가 도시되어 있다. 이 경우에, 프로그램은 윈도우 애플리케이션 관리 서비스가 그의 컴포넌트를 호스트 시스템에 등록하는 것 등의 어떤 설치 작업을 수행하도록 요청한다. 특정의 요청의 프로세스 소유자만을 보고 있는 시스템은 이 동작이 운영 체제 자체의 일부인지 그 동작을 애플리케이션 관리 서비스에 연계시킬지를 결정한다. 그렇지만, 원하는 결과는 그 동작이 서비스가 수행되도록 요청한 프로그램에 연계되는 것이다.

본 발명의 실시예의 예시적인 구현에서, 운영 환경의 공통 인터페이스 및 통신 경로가 계측된다. 이들 계측 인터페이스는 소스 컨텍스트를 식별하는 데 유용한 정보를 포착하는 데 사용된다. 상기한 바와 같이, 설치 요청의 호출측 프로그램을 식별하기 위해 윈도우 애플리케이션 관리 서비스에 대한 요청 인터페이스가 계측된다. 이 API 호출의 내용은 장래의 사용을 위해 저장하기 위해 프로세스 관리자(504)로 전송된다. 이 API 호출의 유효한 수명 동안에, 프로세스 관리자(504)는 이 정보를 테이블로 유지하고 이를 요청의 소유자를 탐색하는 수단으로 사용할 수 있다.

요청은 시스템을 통해 요청 객체(510)로서 전송된다. 상기한 바와 같이, 이 객체는 이 객체를 발생시킨 API 호출과 연관된 속성을 포함한다. 게다가, 요청은 예를 들어 그의 서브시스템에 관한 데이터, 요청 타입(예를 들어, 생성, 질의, 삭제), 타겟 및 부모 요청을 포함한다. 일 실시예에서, 요청 객체는 요청의 각각의 카테고리/서브시스템과 관련되어 있는 객체 지향 클래스로서 구현된다. 이것에 의해 각각의 서브시스템(511)은 본 발명의 다른 부분의 인터페이스에 영향을 주지 않고 요청 관련 정보를 저장할 수 있다.

리졸브 요청(resolution quest)이 수신될 때, 프로세스 관리자(504)는 후보 소스를 찾아내기 위해 프로세스, 쓰레드 및 동작의 그의 트리를 검색한다. 프로세스 식별자(PID), 쓰레드 식별자(TID) 및 상태 또는 동작 객체 포인터(SPtr)의 리스트를 포함하는, 이 프로세스 테이블(505)은 도 10에 도시되어 있다. 각각의 엔트리는 하나 이상의 프로세스 객체의 부모일 수 있는 프로세스 객체이다. 부모-자식 관계는 호스트 운영 체제의 관계를 반영한다. 각각의 프로세스 객체(603)는 필요한 경우 과거 동작에 대한 참조를 유지하는 상태 객체(604)에 대한 포인터를 포함한다. 양호한 실시예에서, 각각의 동작은 연산, 연산 데이터, 및 연산을 요청한 소스 프로세스 식별자로 이루어질 수 있다. 실제로는, 예를 들어 연산의 결과, 즉 성공 또는 실패, 및 그의 결과 코드, 연산에 관한 타이밍 또는 수명 정보, 및 연산에 대한 보안 기밀 등의 다른 데이터가 저장된다.

프로세스 또는 쓰레드가 동작과 연관되어 있는 경우, 그 동작이 현재의 요청과 일치하는지를 확인하기 위해 프로세스 리스트가 검색된다. 이전의 윈도우 애플리케이션 관리 서비스의 예에서, 시작 프로그램(originating program)에 의한 API 호출은 윈도우 애플리케이션 관리 서비스 프로세스 객체 아래에 상태 객체가 생성되게 한다. 이 상태 객체는 시작 프로그램이 요청된 동작의 소스이었음을 확인해준다. 애플리케이션 관리 서비스가 파일을 생성하거나 수정하는 등의 동작을 취함으로써 API 요청을 실행하려고 시도할 때, 프로세스 관리자는 윈도우 애플리케이션 관리 서비스의 프로세스 객체 아래에서 호출과 연관된 상태 객체를 찾게 되지만, 이 서비스를 사용하여 그 파일이 실제로는 시작 프로그램에 의해 생성되고 있다고 보고한다.

요청 소스를 알게 되면, 프로세스 관리자(504)는 요청 소유자의 프로세스 및 쓰레드 id, 그리고 그의 진짜 소스를 반환하지만, 이들은 컨텍스트 관리자(503)(여기에서 그의 하나 이상의 컨텍스트와 매칭시킴)에게는 동일할 수 있다. 일 실시예에서, 컨텍스트 관리자(503)는, 도 11에 나타낸 바와 같이, 시스템의 이용가능한 컨텍스트의 테이블은 물론, 컨텍스트들 간의 연관을 포함하고 있다. 컨텍스트는 그의 컨텍스트 타입(CType)과 함께 기본 식별자(CID)를 포함한다. 컨텍스트 자체는 이어서 기능상의 상호 관련을 인에이블 또는 디스에이블시키는 하나 이상의 정책 객체(705)에 대한 포인터(PoPtr)를 필요로 한다. 정책 객체는 그 자신의 식별 자 및 기계 서브시스템(들)은 물론 요청 상관 파라미터를 식별해주는 일치 니모닉(match mnemonic) 및 리소스에 대한 소스 이름 공간 컨테이너 및 명명된 객체에 대한 변환 동작 등의 동작을 적용하는 규칙을 포함한다. 예시적인 정책은 로컬 시스템 이름 공간 컨테이너에 행해져야만 하는, 예를 들어 마이크로소프트 워드 파일 타입(*.doc)과 일치하는 파일에 대한 임의의 수정, 예를 들어 기록, 삭제, 기타 등등이다. 당업자라면 이 정책이 여러가지 형태로 코드화될 수 있다는 것을 잘 알 것이다.

이 테이블은 애플리케이션이 시스템에서 사용될 때 통계적으로 및/또는 동적으로 작성될 수 있으며, 해쉬 테이블, 리스트 또는 다른 방식 등의 임의의 기술을 사용하여 작성될 수 있다. 애플리케이션이 기동될 때, 이 테이블은 애플리케이션의 연관된 프로그램, 이름 공간 컨테이너 및 컨텍스트 관계 모두를 나타내기 위해 로드될 수 있다. 본 발명의 시스템의 실시예들은 또한 컨텍스트 관리자(503)로 하여금 관리 인터페이스를 통해 외부에 질의를 하거나, 새로운 컨텍스트를 로드하거나 또는 시스템 구성의 변화에 대응할 수 있게 해준다. 따라서, 실행 중인 프로그램에 피어인 애플리케이션이 추가되는 경우, 그의 컨텍스트 정보가 라이브 시스템(live system)에 로드될 수 있다. 게다가, 컨텍스트 관리자(503)는 그의 실행 중인 또는 로드된 컨텍스트를 이 인터페이스를 통해 외부 관리 시스템에 통지할 수 있으며, 그에 따라 이들은 다른 기계들과 공유될 수 있다. 당업자라면 이것이 또한 다른 기계로 직접 행해질 수 있다는 것을 잘 알 것이다.

컨텍스트 관리자는 컨텍스트의 후보 리스트를 정책 엔진(506)에 피드한다. 특정의 컨텍스트 내에서 요청을 리졸브하고 보안을 시행할 필요성을 판정하기 위해, 사용자, 기계 또는 시스템 관련 정책 이외에, 각각의 컨텍스트에 대한 정책이 적용된다. 이 프로세스는 요청을 평가하기 위해 후보 컨텍스트의 수를 신속하게 제한한다. 정책 엔진(506)에 대해서는 이하의 섹션에서 보다 상세히 기술한다.

요청은 이어서, 파일 시스템, 레지스트리 또는 다른 것인지에 상관없이, 관련 리소스 관리 서브시스템에 의해 각각의 컨텍스트 내에서 1회 이상 평가된다. 각각의 요청의 결과는 이어서 컨텍스트 관리자에 의해 분석되고, 최종적인 결과가 호출측 프로세스로 반환된다. 컨텍스트 관리자는 그의 환경 테이블을 통해 요청을 적절한 서브시스템으로 매핑할 수 있으며, 여기서 이 서브시스템은 가상 애플리케이션 및 관리되고 있지만 그의 호스트 상에 완전히 설치되거나 구성되어 있는 객체 또는 애플리케이션을 추적한다.

실제로는, 이와 같이 관리될 필요가 있는 몇가지 부류의 동작, 즉 판독(read), 기록(write), 질의(query)/탐색(lookup), 생성(create), 이름 변경(rename)/수정(modify), 열거(enumerate) 및 삭제(delete)가 있다. 많은 다른 동작이 처리되되는 양호한 실시예에서, 모든 처리된 동작의 상세 없이 기본적인 시스템 모델을 기술하는 것이 더 간단하다. 각각의 부류의 동작을 개별적으로 처리함으로써, 시스템은 리소스에의 판독 액세스를 가능하게 해주는 정책들이 작성될 수 있게 해주지만, 대안적인 리소스, 이름 공간 컨테이너 또는 다른 것들에의 기록 액세스를 거부 또는 벡터링할 수 있다.

판독 동작에서, 시스템은 판독 요청을 실행하기 위한 많은 옵션을 갖는다. 판독이 파일에 대한 것인 경우, 이 파일은 하나 이상의 컨텍스트 내에 존재할 수 있다. 무엇을 평가할지를 판정하는 것은 컨텍스트 관리자의 일이다. 당업자라면 이것이 몇가지 방식으로 대처될 수 있다는 것을 잘 알 것이다. 요청은 모든 컨텍스트에서 행해질 수 있으며, 이어서 어느 응답을 이용할지 및 응답들을 어떻게 결합할지의 판정은 그의 규칙에 따라 행해질 수 있다. 요청은 이용가능한 컨텍스트에 의해 필터링될 수 있고, 어느 컨텍스트가 우선순위를 갖는지를 판정하고 그 컨텍스트 내에서 요청을 행한다. 또는, 예로서, 어떤 성공 기준이 충족될 때까지, 요청은 각각의 컨텍스트 내에서 연속하여 평가될 수 있다. 판독 동작의 경우에, 성공은 컨텍스트가 판독 동작을 위한 데이터를 지원할 수 있는 것으로 표시된다.

컨텍스트 관리자는 또한 패턴을 따르는 통상의 요청이 전체 리졸브 단계를 필요로 하지 않도록 하기 위해 그의 리졸브 프로세싱의 결과를 캐싱할 수 있다. 게다가, 컨텍스트 관리자는 컨텍스트의 해싱을 통해 질의를 분산시킬 수 있다. 이 해싱 프로세스는 시스템으로 하여금, 전체 동작 질의를 수행함이 없이, 그의 테이블을 신속하게 조회하고 다른 테이블에 질의를 할 수 있게 해준다.

상기 예에서의 파일이 하나의 애플리케이션 프로그램의 컨텍스트로부터 판독될 수 있지만 그에 기록될 때는 실제의 기록 동작이 다른 프로그램의 컨텍스트 내에서 행해지는 경우에 컨텍스트 방법의 중요성을 알게 된다. 시스템의 이 거동은 2개의 시스템으로 하여금 서로 상호 연동하지만 여전히 서로 격리되어 있거나 서로에 독립적일 수 있게 해줄 수 있다. 운영 체제 가드 명세에서 기술된 바와 같이, 운영 체제의 일부인 파일은 실행 중인 프로그램의 컨텍스트 내에서 볼 수 있지만, 프로그램이 파일을 수정하려고 시도하는 경우, 그 수정은 프로그램의 컨텍스트 내에서 유지될 수 있고 운영 체제에까지 갈 수 없다.

이름 변경 및 삭제 동작에 대해서도 동일하다. 한 컨텍스트에서 삭제되는 파일이 다른 컨텍스트에서 필요할 수 있다. 따라서, 본 발명의 시스템은 존재 정보 및 구성 뿐만 아니라 예를 들어 삭제 및 이름 변경에 관한 추적 정보도 유지한다.

질의 프로세스는 아주 간단하다. 판독 동작에서와 같이, 질의 프로세스는 그룹 우선순위 또는 시스템이 선택하는 임의의 수단을 통해 계층화된 방식으로 실행될 수 있다. 그렇지만, 이 동작의 목적은 정확한 컨텍스트 내에서 명명된 객체의 존재를 검증하거나 그 객체에 대한 핸들을 반환하는 것이다. 본 발명의 시스템은 무엇이 정확한 객체인지, 현재의 컨텍스트에서 그 객체가 보이는지 여부, 및 내부적으로 그의 범위를 어떻게 관리할지를 결정하기 위해 컨텍스트 정책을 적용한다.

본 발명의 일 실시예에서, 이 시스템은 또한 컨텍스트 열거(contextual enumeration) 및 인터리빙된 질의(interleaved query)를 처리할 수 있다. 운영 체제 또는 그의 애플리케이션 내의 많은 데이터 구조 또는 리소스는 트리 구조를 순회함으로써 또는 시스템에 어떤 리소스의 내용의 리스트를 요구함으로써 액세스된다. 실제로는, 이들 동작은 컨텍스트 및 리소스의 인터리빙을 필요로 한다. 예로서, 애플리케이션은 그와 연관된 리소스를 갖는다. 그렇지만, 이 리소스는 다른 프로그램이 그 자신과 연관되어 있고 활성인 경우에만 유효하다.

도 12에 도시한 바와 같이, 리소스가 다른 프로그램의 리소스 트리에 부착될 수 있다. 따라서, 이 리소스에 대한 질의 동안에, 이 시스템은 2개의 개별적인 구성의 이름 공간을 인터리빙할 수 있어야만 한다. 그렇지만, 정책이 합집합 연산(union operation)을 허용하지 않는 경우, 명명된 객체에의 직접 액세스도 그 객체에 대한 열거(enumeration)도 행해지지 않는다. 동 도면에 도시된 예에서, 애플리케이션(애플리케이션 A)은 윈도우 레지스트리 키 객체를 나타내는 3개의 항목을 갖는 구성으로 되어 있다. 객체 HKLM＼Software＼Drawing Vendor＼Photo Editor＼Pinhead Software＼Inline Plugins＼Snapshot(805)는 제2 애플리케이션(애플리케이션 B)이 애플리케이션 A와 공유되는 컨텍스트 내에 구성되어 있는 경우에만 존재하게 된다.

객체가 실제로 애플리케이션 A에 존재하더라고 이렇다. 항목 "Pinhead Software"(802)가 애플리케이션 A의 컨텍스트에 존재하지 않는 경우, 궁지에 몰리게 될 수 있다. 이 시스템은, 제2 애플리케이션이 존재하지 않는 한, 이 리소스에 대한 열거를 하지 못하게(그 이유는 그 리소스까지 따라갈 경로가 없기 때문임) 또한 그 리소스에의 직접 액세스를 하지 못하게 설계되어 있다. 게다가, 애플리케이션 B가 단독으로 인스턴스화되어 있는 경우, 다른 것들(802, 803) 아래에 부착되어 있는(subjunct) 그의 리소스들은 동일한 이유로 존재하지 않게 된다.

이름 공간 관리

그의 가장 기본적인 형태에서, 컨텍스트는 애플리케이션의 리소스를 노출시키는 별도의 이름 공간 및 이들 항목에 대해 행해진 동작을 지속시키는 방법이다. 이름 공간은 고유의 이름을 어떤 식별가능 리소스에 매핑하는 영역 또는 범위이다. 운영 체제 가드 계층은 이 대안의 이름 공간을 생성 및 관리하는 매개물이다. 애플리케이션은 이 매개물을 알지 못한다. 애플리케이션은 단지 주어진 이름을 갖는 객체를 생성하고 나중에 동일한 이름으로 그 객체를 참조할 수 있을 것으로 기대한다. 이 계층은 다수의 이름 공간을 관리하지만, 이들을 실행 중인 애플리케이션 또는 시스템의 나머지에 단일의 이름 공간인 것처럼 보이게 할 수 있다. 이와 같이, 운영 네트워크(150)에 제공된 단일의 리소스는 실제로는 여러가지 서로 다른 이름 공간으로부터의 다수의 리소스에 의해 뒷받침될 수 있다.

디폴트로, 매개물 계층은 로드되는 각각의 프로그램 인스턴스가 사적 이름 공간을 갖게 되는 격리 컨텍스트를 생성한다. 애플리케이션이 리소스를 생성하고 사용할 때, 객체 이름은 로컬화되어 특정의 애플리케이션 인스턴스 내에서만 존재하게 된다. 이것은 일반적으로 객체가 프로그램의 범위 내에서만 존재하도록 보장함으로써 행해지만, 더 큰 이름 공간 내에서 객체 이름을 해싱하고 역 프로세스(reverse process)를 통해 그것을 검색할 수 있음으로써도 행해질 수 있다. 이와 같이, 다른 프로그램은 매개물의 기능을 리버스 엔지니어링(reverse engineering)함이 없이 그의 이름 공간 내에 존재하지 않는 객체를 요청할 수 없다.

객체를 참조하기 위해 애플리케이션이 사용하는 이름은 공통 이름(common name)이라고 한다. 시스템 상의 2개의 개별적인 애플리케이션은 동일한 공통 이름을 사용하지만 서로 다른 객체를 참조할 수 있다. 매개물은 정확한 객체에 대응하 는 인스턴스 관련 이름을 생성하는 일을 맡고 있다. 이것은 로컬 이름(local name)이라고 한다. 각각의 로컬 이름에 대해, 전체 시스템에 걸쳐 고유한 부가의 절대 이름(absolute name)이 있다. 그의 절대 이름을 사용하여 하는 객체에 대한 모든 참조는 동일한 객체를 참조한다.

공통 이름은 애플리케이션에 의해 지정된다. 로컬 이름은 그의 컨텍스트 내에서 공통 이름을 평가함으로써 런타임 시에 매개물에 의해 동적으로 생성된다. 이 시스템은 절대 이름을 생성할 필요가 없고 프로그램의 의존 관계 및 그의 컨텍스트 관계에 기초하여 선택할 수 있다. 애플리케이션은 절대 이름을 결코 통지받지 않는다. 로컬 이름을 절대 이름으로 매핑하는 일은 물론 정확한 공통 이름을 로컬 이름으로 또 그 역으로 매핑하는 일은 매개물이 맡고 있다.

컨텍스트의 존재 시에, 동일한 컨텍스트 내의 2개의 애플리케이션은, 객체를 생성 및 액세스하는 데 동일한 공통 이름을 사용하는 경우, 동일한 객체를 참조할 수 있다. 객체 요청을 연결하는 일은 매개물의 책임이다. 이들 요청을 연결하는 몇가지 방법이 있다. 양호한 실시예에서, 매개물 계층은 종종 동일한 컨텍스트에서 동일한 방식으로 객체 이름을 해싱하려고 한다. 어떤 다른 동작은 단순히 요청을 다른 이름의 객체로 리디렉션함으로써 수행될 수 있다. 느슨하게 연결된 컨텍스트에서의 애플리케이션의 경우, 시스템에 의해 사용되는 기능은 시스템으로 하여금 객체를 찾아내고 객체들 간을 연관시키는 데 고속 검색 방법을 사용할 수 있게 해준다. 양호한 실시예에서, 이름을 신속하게 리졸브하기 위해 로컬 결과 캐싱을 갖는 분산 탐색이 사용된다.

이 시스템의 예에서, 프로그램은 3개의 장소에서 이용가능한 리소스를 이용하려고 시도할 수 있다. 첫째, 리소스는 프로그램의 1차 구성은 물론 2차 종속 구성에서도 이용가능하다. 이는 또한 운영 체제의 일부로서 이용가능하다. 우리 예에서, 우리는 파일 MSCOMCTL.OCX를 선택한다. 통상적으로, 이 리소스는 C:＼＼Windows＼System32＼MSCOMCTL.OCX의 공통 이름을 갖는다. 운영 체제 가드를 사용하여, 매개물 계층은 이 이름이 3가지 구성 모두에 존재할 수 있게 해준다. 모든 구성에 대해, 객체의 공통 이름은 동일하다.

매개물 계층은 문제의 프로그램이 동일한 이름을 갖는 객체의 복사본을 가질 수 있게 해준다. 게다가, 2차 구성은 다른 이름을 갖는 객체를 가질 수 있지만, 그의 구성에서 객체의 공통 이름이 C:＼＼Windows＼System32＼MSCOMCTL.OCX임을 시스템에 알려주는 가상화 명령을 지정할 수 있다. 이것에 의해 운영 체제 가드는 객체가 실제로 사용되는 곳과 다른 이름 공간 또는 저장 장소에 객체를 저장할 수 있으며, 그에 따라 그의 거동을 드러내기 위해 런타임 시에 이들 이름 공간을 매핑할 수 있다.

이 예에서, 3개의 객체 모두는 동일한 공통 이름을 갖는다. 컨텍스트 리졸브 프로세스는 어느 객체가 실제적인 우선순위를 갖는지를 선택한다. 이어서, 시스템은 적당하게 로컬화된 이름을 생성 또는 사용한다. 이 경우에, 시스템은 1차 구성에서 객체를 선택할 수 있으며, 그 프로그램 인스턴스의 컨텍스트 내에서 로컬 이름을 매핑하려고 할 수 있다.

컨텍스트의 범위가 더 커지고 더 넓어짐에 따라, 시스템도 또한 이름 공간 매핑을 생성, 질의 및 검색하기 위해 이름 공간 관리자(508) 기능을 제공할 수 있다. 프로그램이 통상적으로 공통 이름을 갖는 리소스를 이용하려고 시도할 때, 이 관리자는 이 공통 이름을 갖는 리소스를 사용하여 다른 프로그램들의 리스트를 질의할 수 있다. 이것은 이어서, 부가의 프로그램 중 임의의 것이 컨텍스트를 공유하는 경우, 컨텍스트 관리자에 의해 사용될 수 있다. 그러한 경우, 공유 프로그램이 동일한 리소스를 사용하도록 보장하기 위해 매핑이 행해질 수 있다. 이것은 동일한 로컬 이름을 사용함으로써 또는 시스템 절대 이름을 사용함으로써 행해질 수 있다. 이것은 기계 경계를 넘어 확장하는 컨텍스트에 대해 특히 유용하다.

유의할 점은 이 동작의 결과 로더(509)가 이름 공간 컨테이너를 검색하고 그 안에 포함된 리소스의 메타데이터를 로드하는 부작용이 생길 수 있다는 것이다. 리소스가 가변적인 수명을 가질 수 있기 때문에, 이름 공간 관리자(508)는 참조 카운팅/추적(reference counting/tracking), 컨테이너의 로딩 및 완성(finalization), 및 어떤 경우에 투기적 가상화(speculative virtualization)를 비롯한 리소스 관리 동작을 구현한다.

투기적 가상화는 파일, 레지스트리 키, 또는 다른 리소스에 대한 판독 및 기록 동작 등의 동작 동안에 사용되는 프로세스이다. 리소스가 열리거나 질의될 때, 시스템은 리소스가 나중에 변경될 것으로 가정할 수 있고 또 기록 등의 부가의 동작이 시스템에서 무엇을 달성할 수 있는지를 판정하기 위해 부가의 정책을 실행할 수 있다. 시스템은 이어서 이들 동작이 실제로 수행되는 경우에 추가의 비용 또는 대기 시간을 회피하기 위해 미리 또는 백그라운드에서 이들 동작을 실행할 수 있 다. 모든 투기적 동작에서와 같이, 시스템은, 차후의 동작이 수행되지 않은 경우에, 행동을 취소할 수 있어야만 한다. 본 발명의 일 실시예에서, 시스템은 고비용의 COW(copy-on-write, 기록시 복사) 동작이 될 수 있는 것을 피하는 데 도움을 주기 위해 기적 가상화를 사용한다. 파일이 변경될 때, 파일이 크거나 원격지에 있거나 그 둘다인 경우에, COW 시맨틱스는 고비용을 초래할 수 있다. 이 절차는, 동작의 런타임 비용을 피하기 위해, COW 동작이 일찍, 백그라운드에서 시작될 수 있게 해준다.

이 이름 공간 관리자는 또한 시스템의 관리 계층 내에서 동작할 수 있고 운영 체제 가드 내에서 동작하는 동일한 실제 관리자일 수 있지만 시스템-전반적인 질의에 응답하도록 구성될 수 있다. 또는, 다른 대안으로서, 이는 전용 목적 애플리케이션일 수 있다. 이 관리 기능은 구성된 절대 이름의 저장소를 제공하고 그들을 대규모 컨텍스트에 매핑하는 역할을 한다.

이 이름 공간 관리자는 또한 각각의 이름 공간 내에서의 이름의 시간 진화(time evolution)를 관리할 수 있다. 이것은, 표준 해싱 알고리즘이 시간 변수를 포함할 수 있더라도, 특정의 객체 이름이 매번마다 동일한 방식으로 해싱되도록 보장하기 위해 사용될 수 있다. 이것을 행함으로써, 시간에 민감한 컨텍스트 또는 시맨틱스를 동작에 제공할 수 있다. 게다가, 이것은 용법 및 매핑 정보를 시스템 내에 저장함으로써 행해질 수 있다.

객체가 과거에 한 인터페이스에서 프로그램에 의해 요청되고 동일한 이름의 새 인터페이스가 이용가능한 경우, 이 시간에 민감한 거동은 시스템이 이전의 인터 페이스에 매핑하도록 보장할 수 있다. 이것은 이 시스템에서 디폴트로 행해진다. 새 인터페이스에 매핑하는 것이 요망되는 경우, 새 버전의 사용을 선언적으로 단언할 수 있다. 다수의 버전을 갖는 소프트웨어 시스템, 및 본 명세서에서 고려되고 있는 것 등의 시스템의 존재 시에, 소프트웨어 시스템의 저작자 또는 관리자에 의해 그렇게 하도록 구성된 바로 그 방식으로 리소스를 생성 및 사용하는 것을 보장해줄 수 있다.

관련 예로서, 많은 시스템은 DCOM 또는 CORBA 또는 심지어 HTTP RPC 등의 분산 함수 호출(distributed function call)을 사용한다. 2개의 프로그램이 서로 의존하도록 하여 통신이 행해질 수 있도록 구성될 수 있다. 프로그램들을 연결하는 데 사용되는 공통 이름은 주소 및 인터페이스를 포함한다. DCOM의 경우에, 분산 질의 및 그의 인터페이스를 광고하기 위한 그의 COM UID를 호스팅하는 기계가 있다. 이 호스트는 로컬 이름에 이미 매핑되어 있는 그의 공통 이름을 가질 수 있다. 원격 프로그램이 호스트 및 UID를 어드레싱하려고 시도할 때, 시스템은 주소 및 UID 둘다를 그 로컬 이름에 대응하도록 매핑할 수 있거나, 또는 적당한 버전의 인터페이스가 제공되도록 보장하기 위해 대안의 호스트를 활성화할 수 있다. 상기한 바와 같이, 원격 프로그램에 의해 사용되는 공통 이름을 호스트에 의해 사용되는 로컬 이름으로 매핑하는 일은, 이름 공간 관리자 내에서 리소스의 절대 이름을 탐색함으로써 또는 그의 공통 이름 대 로컬 이름 매핑을 위해 호스트 시스템의 이름 공간 관리자에 질의를 함으로써, 시스템에 의해 내부적으로 행해질 수 있다. 인터페이스의 2차 버전이 존재하는 경우, 이름 공간 관리자는 원격 활성화에 대한 적절한 버전을 반영하는 대안의 매핑으로 대응할 수 있다.

컨텍스트 정책

상기한 바와 같이 동작이 다수의 컨텍스트에 걸쳐 있을 수 있는 경우를 관리하기 위해 적당한 메카니즘이 필요하다. 이들 상호 연동의 속성은 네이밍 충돌을 일으킬 수 있거나, 우선순위의 순서를 결정하는 것이 필요한 경우를 야기할 수 있거나, 변경 동작의 효과를 해결하기 위한 상황에 이르게 할 수 있다. 시스템 관리자 또는, 요망되는 경우, 최종 사용자 또는 소프트웨어 벤더가 동작을 제어하기 위한 정책을 수립할 수 있는 능력은 상기한 컨텍스트의 존재와 직교한다. 고속 구성 및 미세 제어(fine-grained control)를 가능하게 해주는 컨텍스트의 매크로(macro) 및 마이크로(micro) 조정 둘다를 위한 기능을 제공하는 것이 바람직하다.

본 발명의 시스템의 일 실시예는 XML 기반 구성 파일을 통해 애플리케이션과 운영 체제 간의 상호 의존 관계를 기술하는 수단을 제공한다. 당업자라면 이 프로세스가 여러 방식으로 대처될 수 있으며, 단지 하나가 여기에 기술되어 있다는 것을 잘 알 것이다.

도 8의 시스템에서, 애플리케이션 A는 구성 파일 a.config(408)을 갖는 반면, 애플리케이션 B는 구성 파일 b.config(409) 및 c.config(410)에 기술된 공유 리소스 세트를 갖는다. 프로그램들 간에 상호 의존 관계를 확립하기 위해, <CONTEXT> 명령이 a.config(408) 파일에 배치되어, 이 2개의 프로그램이 공유 컨텍스트 내에서 공존하고 있어야만 함을 나타낸다. 이 예에서, 이 컨텍스트는 EXAMPLE의 이름 및 Peer의 컨텍스트 범위를 갖는 공유 컨텍스트이다.

이 시스템에서, 컨텍스트가 사용되기 위해 이 태그가 양쪽 프로그램 설명 둘다에서 필요하지는 않다. 컨텍스트가 평가되기 위해 컨텍스트는 특정의 보안 영역 내에서 관련성을 갖기만 하면 된다. 따라서, 다른 프로그램과 공유할 수 있는 프로그램은, 사용자가 이들 프로그램 둘다에 대한 권한을 가지고 있지 않는 한, 컨텍스트를 확립하지 않는다.

게다가, 컨텍스트의 이해 및 평가를 지원하는 시스템이 제공될 수 있다. 예로서, 관리 컨텍스트가 요망되는 경우, 시스템은 어느 시스템이 컨텍스트에 참가하는지를 알아야만 한다. 이것은 컨텍스트의 각각의 멤버에 의해 또는 전역적으로는 시스템 전반적인 서비스에 의해 평가될 수 있고 또 이 컨텍스트를 평가할 때 각각의 기계에 제공될 수 있다. 이것에 대해서는 컨텍스트 관리자 시스템 및 그의 관리 인터페이스의 일부로서 앞서 기술하였다. 본 발명의 시스템은 소프트웨어 패키지에 대한 설명과 별도로 컨텍스트 관계를 기술하는 정책 파일이 생성될 수 있게 해줌으로써 그의 거동을 용이하게 해준다.

정책 파일은 시스템의 디폴트 거동을 생성하는 데 또는 시스템이 사용하기 위한 기본적인 컨텍스트를 확립하는 데 사용될 수 있다. 언제라도, 시스템은 그의 서브시스템이 사용하도록 정책을 그의 정책 엔진으로 로드 또는 재로드할 수 있다. 정책이 특정의 사용자, 그룹, 기계 또는 다른 관련 구성에만 적용될 수 있게 해주는 부가의 수정자(modifier) 및 변수가 적용될 수 있다. 이들 정책의 적용을 제어하기 위해 임의의 수의 변형이 이 기술에 적용될 수 있지만 기본적인 제어는 컨텍스트가 적용되는지 여부 및 그의 런타임 거동은 어떠한지를 판정하는 것임을 잘 알 수 있다. 정책은 또한 시스템 전체에 걸쳐 그의 무결정을 보장하기 위해 또한 컨텍스트 거동을 바꾸기 위해 사용자가 정책을 입안하는 것을 방지하기 위해 디지털적으로 서명될 수 있다.

개별적인 구성 항목 레벨에서, 시스템은 또한 특정의 리소스만이 컨텍스트 제어에 노출되도록 지정할 수 있다. 이 유틸리티는, 2개의 프로그램이 통신할 필요가 있고 그의 통신 인터페이스에 연결할 수 있기만 하면 되며 임의의 구성 상세를 이해할 필요가 없는 경우에, 아주 유용하다. 또한, 이것은 한 프로그램이 다른 프로그램을 전체 구성의 작은 서브셋으로 수정하는 기능들을 수집하는 데 유용하다. 이 예에서, 공유 리소스 세트는 이 리소스 세트가 리소스 ＼＼pipe＼testresource에 대한 호스트로서 역할하는 세션 컨텍스트가 존재하는 것으로 c.config에서 선언하였다. 이 리소스 세트와 동일한 세션에서 실행되는 임의의 애플리케이션은 이 명명된 리소스를 이용할 수 있음은 물론 HKLM＼Software＼Test＼Value에 있는 그의 다른 구성 데이터를 볼 수 있다. 이 시스템의 일 실시예에서, 임의의 특정의 리소스가 명명되면, 그 리소스만이 공유된다. 그렇지 않고, 아무것도 지정되지 않은 경우, 컨텍스트 디렉티브(context directive)에 따라 모든 리소스가 공유되는 것으로 암시된다.

정책 디렉티브도 역시 여러 부류의 동작의 결과를 정의하는 데 유용하다. 이러한 유형의 디렉티브의 한가지 간단한 예는 윈도우 레지스트리에 대한 임의의 수정이 사용자의 개인 설정 이름 공간 컨테이너에 들어가야만 하는 것으로 선언하는 정책이다. 이러한 유형의 정책은 특정의 애플리케이션 뿐만 아니라 다수의 컨 텍스트 및 다수의 이름 공간 및 컨테이너에도 적용되는 교차 정의(cross-cutting definition)를 가능하게 해준다.

수정자(modifier)도 역시 각각의 지정이 판독 전용 또는 판독-기록될 수 있게 해주는 모든 컨텍스트 구성에 허용된다. 디폴트 거동은 컨텍스트와 관련되어 있다. 게다가, 컨텍스트 인식 연관(context aware association)에의 기록을 허용하는 경우에, 어느 컨텍스트 내에서 기록이 행해지는지를 식별하는 것이 중요하다. 이것에 대해서는 나중에 보다 상세히 기술한다. 그렇지만, 구성 파일은 특정의 목표를 지정하기 위해 시스템의 통상의 거동을 번복할 수 있다.

본 발명의 시스템에 의해 제공되는 다른 수정자는 확립된 컨텍스트의 우선순위의 순서를 번복시킬 수 있는 것이다. 피어들 간에 임의의 특정의 관계가 있는 것으로 판정될 수 있다. 이 경우에, 정보의 소유자가 그의 수명을 책임지고 있는 것이 당연할 수 있다. 그렇지만, 수정을 한 프로그램만이 그 자체 내에서 수정을 보는 것이 요망될 수 있다. 2개의 프로그램이 공유 컨텍스트 내에 있는 경우, 이 수정은 이와같이 지속되지 않는다. 수정자는 이 대안의 거동을 강제할 수 있다.

컨텍스트의 판정 및 제어

시스템이 실행가능하기 위해서는, 시스템은 최상의 거동을 판정하는 어떤 자동화된 수단을 제공해야만 한다. 디폴트로, 운영 체제 가드는, 프로그램이 명시적으로 동일한 컨텍스트에 있도록 패키징되어 있지 않은 한, 격리 컨텍스트에 존재하도록 프로그램을 구성한다. 동일한 애플리케이션 환경 하에 패키징된 모든 프로그램은 그 하나의 컨텍스트를 공유한다. 그렇지만, 앞서 기술한 바와 같이 상호 연 동가능한 컨텍스트의 생성을 추가적으로 자동화하는 것이 요망된다. 본 발명의 시스템은 거동을 제어하기 위해 이들 컨텍스트 및 정책을 검출 및 구성하는 몇가지 수단을 제공한다.

애플리케이션의 설치 동안에, 시스템은 그 설치가 그의 목표 컨텍스트를 직접 구성할 수 있게 해준다. 가상 설치 소프트웨어 또는 운영 체제 가드의 경우에, 이것은 특정의 프로그램에 대한 격리 컨텍스트이다. 특히 설치되는 애플리케이션 또는 일련의 애플리케이션에 대해 새로운 구성 환경이 생성된다. 기존의 애플리케이션의 컨텍스트 내에서 설치 프로그램을 실행하는 것 등 기존의 구성을 확장하고자 함을 시스템에 알려줌으로써, 부가적인 방식으로 환경 내에서 설치가 행해질 수 있다.

ESD 시스템을 통하는 등의 표준적인 수단으로 배포 및 설치되는 소프트웨어의 경우, 이 소프트웨어는 통상적으로 로컬 시스템 컨텍스트로 설치된다. 운영 체제 가드의 시스템과 반대로, 통상적으로 애플리케이션 레벨 소프트웨어 및 운영 체제는 기계 내에서 동일한 위치에 존재한다. 양호한 실시예의 시스템에서, 소프트웨어는 설치 시에 선택된 별개의 컨텍스트로 설치되도록 구성될 수 있다. 이것은 통상적으로 원하는 거동에 따라 벤더 컨텍스트, 사용자 컨텍스트 또는 세션 컨텍스트 중 하나이지만, 이용가능한 컨텍스트 중 하나일 수 있다. 예로서, 벤더 Microsoft로부터의 모든 소프트웨어는 Microsoft 애플리케이션에 대한 컨텍스트 내에서 설치될 수 있다.

이 방법을 사용하여, 시스템은 설치된 객체를 대안의 저장 장소로 리디렉션 하고 런타임 시에 매핑하기 위해 공통 이름을 생성할 수 있다. 이것에 의해 애플리케이션은 기계 또는 그의 암시된 객체 이름 공간에 손상을 주지 않고 기계 상에 설치될 수 있다. 이 시스템은 또한 목표 시스템 상에 실제로 설치하기 이전에 구성을 생성하기 위해 목표 변경된 시스템(retargeted system), 가상 기계, 시뮬레이션 환경, 또는 목적지 호스트에의 소프트웨어 설치를 가능하게 해준다. 이것에 의해 가상 환경이 동작 중에 생성될 수 있으며, 가상 설치를 위한 소프트웨어를 준비하는 사전 단계를 필요로 하지 않는다.

이전의 응용에서 기술한 바와 같이, 설치가 완료되면, 운영 체제 가드는 그의 구성을 다운로드한다. 이 다운로드 동안에, 어떤 패턴에 대해 이 구성이 분석될 수 있다. 이들 패턴은 프로그램을 계측하기 위해서는 물론 통상적인 네이밍 문제로부터 프로그램을 추상화시키기 위해 사용된다. 예로서, 많은 프로그램은, 이들이 설치될 때, 그 자신을 "개인화(personalize)"하며 설치하는 사용자 또는 그 프로그램이 실행된 기계에 관한 정보를 그의 구성에 기록한다. 이 시스템은 이들 로컬 이름을 제거하고 이들을 공통 이름으로 대체한다. 또는, 프로그램이, 그의 설치 동안에, ODBC DSN을 생성한 경우, 이는 ODBC 서브시스템의 해당 버전에 대한 의존 관계를 생성하기 위해 시스템이 알게 된다.

이들 패턴은 또한 인에이블되어 설치 동안에 활성일 수 있다. 이 패턴은 애플리케이션 관련 템플릿 또는 일반적인 근사 법칙(rule of thumb)일 수 있다. 일례는 마이크로소프트 오피스에 설치되는 프로그램이 HKEY_LOCAL_MACHINE＼Software＼Microsoft＼Office 레지스트리 키를 검색하는 것이다. 이들 방법을 구현하는 시 스템은 이들 템플릿 또는 구성가능한 일련의 설치가능 템플릿을 구현하는 내부적인 규칙을 제공할 수 있다.

본 발명의 일 실시예에서, 마이크로소프트 오피스를 검색하고 있는 프로그램은 상기 명명한 레지스트리 키가 있는지 질의한다. 그 질의 동안에, 마이크로소프트 오피스 소프트웨어가 로컬 기계 상에 설치되어 있는 경우, 그 프로그램이 동작하도록 오피스가 존재한다는 것을 보장하기 위해 새로운 소프트웨어 패키지 내에 의존 관계가 생성될 수 있고, 그 프로그램이 로컬 기계 상에서 서로에게 보이도록 보장해주기 위해 컨텍스트가 생성될 수 있다. 마이크로소프트 오피스 소프트웨어가 가상 설치 패키지의 일부인 경우, 이 시스템은 그의 이름 공간 관리자 내에서 이 레지스트리 키를 찾으며 또 이 새로운 소프트웨어 패키지가 상호 연동할 필요가 있을 수 있는 컨텍스트의 리스트를 찾는다. 이어서, 이 시스템은 가상 패키지에 대한 의존 관계를 생성하고 상호 연동을 위한 공유 컨텍스트를 생성할 수 있다.

본 시스템의 일 실시예에서, 이용가능한 소프트웨어 패키지는 하나 이상의 저장소에 저장된다. 구성 및 컨텍스트 정보는 시스템의 컨텍스트 관리자에 의해 즉각 질의된다. 요청이 행해질 때, 그 요청은 전체 저장소에 대해 후보 컨텍스트 및 의존 관계가 있는지 매칭될 수 있다. 마이크로소프트 오피스 예의 경우에, 이 시스템은 템플릿을 필요로 하지 않지만, 그 대신에 마이크로소프트 오피스에 대한 질의를 저장소 내의 애플리케이션으로부터 온 것으로 리졸브한다. 시스템은 이어서 오피스 애플리케이션 및 그의 구성을 인스턴스화하고 설치되고 있는 프로그램에 대한 컨텍스트 및 의존관계를 생성할 수 있다.

디폴트로, 시스템은 가능한 한 제한적이도록 하며, 공유하도록 요구되는 리소스만으로 가능한 한 가장 적게 공개된 또는 공유된 컨텍스트를 구성하려고 한다. 컨텍스트 정책 및 구성을 변경하는 것은 물론 리소스 레벨 명령을 신속하게 제거하고 패키지 전반적인 공유를 설정 또는 컨텍스트를 변경하기 위해 인터페이스가 제공된다.

본 발명의 원리들이 적용될 수 있는 광범위한 실시예들을 살펴보면, 예시된 실시예들이 단지 예시적인 것이며 본 발명의 범위를 제한하는 것으로 보아서는 안된다는 것을 잘 알 것이다. 예를 들어, 흐름도의 단계들은 기술된 순서와 다른 순서로 행해질 수 있으며, 도면들에서 더 많은 또는 더 적은 요소가 사용될 수 있다. 실시예들의 여러가지 요소가 소프트웨어로 구현되는 것으로 기술되어 있지만, 다른 대안으로서 펌웨어 구현의 하드웨어로 된 다른 실시예들이 사용될 수 있고 그 역도 마찬가지이다.

상기 시스템에 관여된 방법들 및 컨텍스트 정책 제어를 통해 애플리케이션간 연관을 제어하는 방법이 컴퓨터 사용가능 매체를 포함하는 컴퓨터 프로그램 제품으로 구현될 수 있다는 것이 당업자에게는 명백할 것이다. 예를 들어, 이러한 컴퓨터 사용가능 매체는, 컴퓨터 판독가능 프로그램 코드 세그먼트가 저장되어 있는, 하드 드라이브 장치, CD-ROM, DVD-ROM, 또는 컴퓨터 디스켓 등의 판독가능 메모리 장치를 포함할 수 있다. 컴퓨터 판독가능 매체는 또한 광학, 유선 또는 무선의 버스 또는 통신 링크 등의 통신 또는 전송 매체(프로그램 코드 세그먼트가 이를 통해 디지털 또는 아날로그 데이터 신호로서 전달됨)를 포함할 수 있다.

기타의 측면, 수정 및 실시예들이 이하의 청구항의 범위 내에 속한다.

Claims (15)

1. 복수의 소프트웨어 애플리케이션 및 리소스의 상호 연동(interoperation)을 제어하는 방법으로서,

   제1 애플리케이션으로부터 제2 애플리케이션 또는 리소스로의 통신을 가로채기(intercept)하는 단계 - 상기 제1 애플리케이션, 상기 제2 애플리케이션 또는 상기 리소스는 동일한 운영 시스템(operating system)상에 인스턴스화(instantiated)됨 -,

   상기 통신을 컨텍스트 관리 시스템(context management system)으로 보내는(direct) 단계 - 상기 컨텍스트 관리 시스템은 상기 제1 애플리케이션에 대한 가상 컨텍스트를 생성함 -,

   상기 통신에 대한 컨텍스트들의 후보 리스트를 생성하는 단계,

   상기 통신에 대한 결과 조치(resultant action) 및 이름 공간(namespace)을 식별하기 위해 이들 컨텍스트에 대해 정의된 적어도 하나의 정책에 따라 상기 후보 리스트를 평가하는 단계, 및

   식별된 상기 이름 공간 내의 상기 적어도 하나의 정책에 의해 정의된 대로 상기 결과 조치를 수행하는 단계를 포함하는 방법.
2. 제1항에 있어서, 상기 제2 애플리케이션의 하나 이상의 버전을 추적하는 단계를 더 포함하는 방법.
3. 제1항에 있어서, 애플리케이션 및 리소스 이름 중 적어도 하나의 진화(evolution)를 추적하는 단계를 더 포함하는 방법.
4. 제1항에 있어서, 상기 후보 리스트 상의 컨텍스트와 연관된 하나 이상의 동작을 식별하는 단계, 및

   추가의 통신 이전에 상기 식별된 하나 이상의 동작을 실행하는 단계를 더 포함하는 방법.
5. 제1항에 있어서, 상기 후보 리스트를 생성하는 단계는 하나 이상의 분산된 컨텍스트로부터 컨텍스트들을 생성하는 단계를 포함하는 것인 방법.
6. 제1항에 있어서, 상기 통신은 프로세스간 통신, 운영 체제 호출, API 호출, 및 라이브러리 호출 중 적어도 하나를 포함하는 것인 방법.
7. 제1항에 있어서, 컨텍스트는 글로벌 컨텍스트(global context), 관리 컨텍스트(managed context), 로컬 시스템 컨텍스트(local system context), 시스템 가상 컨텍스트(system virtual context), 벤더 컨텍스트(vendor context), 사용자 컨텍스트, 세션 컨텍스트(session context), 공유 컨텍스트(shared context), 및 격리 컨텍스트(isolated context) 중 적어도 하나를 포함하는 것인 방법.
8. 제1항에 있어서, 상기 적어도 하나의 정책은 상기 정책을 적용하는 규칙들, 복수의 요청 상관 파라미터 및 상기 정책이 언제 적용되는지를 식별해주는 일치 니모닉(match mnemonic) 중 적어도 하나를 포함하는 것인 방법.
9. 삭제
10. 삭제
11. 삭제
12. 삭제
13. 삭제
14. 삭제
15. 동일한 운영 시스템상에서 동작하는 복수의 소프트웨어 애플리케이션 및 리소스의 상호 연동을 제어하는 시스템으로서,

    프로세서,

    상기 프로세서에 결합되고, 내부에 컴퓨터 실행가능 인스트럭션을 포함하는 메모리를 포함하되,

    상기 인스트럭션은 상기 프로세서에 의해 실행될 때,

    통신에 대한 컨텍스트들의 후보 리스트를 생성하는 컨텍스트 관리 시스템 - 상기 컨텍스트들의 후보 리스트는 시스템 컨텍스트들과는 상이함 -,

    상기 컨텍스트들의 후보 리스트에 대해 정의된 적어도 하나의 정책에 따라 상기 컨텍스트들의 후보 리스트를 평가하는 정책 엔진 - 상기 정책 엔진은 또한 상기 통신에 대한 결과 조치 및 이름 공간을 식별해줌 -, 및

    제1 애플리케이션으로부터의 상기 통신을 제2 애플리케이션 또는 리소스로 보내는(direct) 가상 환경 관리자 - 상기 제1 애플리케이션, 상기 제2 애플리케이션 또는 상기 리소스는 동일한 운영 시스템상에 인스턴스화되며, 상기 가상 환경 관리자는 식별된 상기 이름 공간 내의 상기 적어도 하나의 정책에 의해 정의된 대로 상기 결과 조치를 나타내는 인스트럭션을 수신함 - 를 제공하는

    시스템.

Images