KR100546973B1 - 분산 시스템에서의 의존관계 관리 방법 및 장치 - Google Patents

Abstract

본 발명은 컴퓨팅 환경에서 정보를 관리하는 기술에 관한 것이다. 컴퓨팅 환경의 컴포넌트와 관련된 정보가 획득된다. 그 다음에, 획득된 정보의 적어도 일부분으로부터, 그 컴퓨팅 환경의 컴포넌트들의 적어도 일부분과 관련된 하나 이상의 관계의 존재에 관한 판정이 행해진다. 하나 이상의 관계의 존재에 대한 판정이 컴퓨팅 환경의 적어도 하나의 컴포넌트와 관련된 전 라이프사이클(full lifeycycle)(예를 들면, 배치, 설치 및 런타임)을 설명할 수 있다. 따라서, 컴퓨팅 시스템의 여러가지 컴포넌트들 사이의 런타임 의존관계를 관리하는 기술로서, 개개의 시스템에 대한 어떤 레벨의 추상화를 제공하고 또 고객에 의해 인지되는 바와 같은 엔드-투-엔드 서비스에 관계된 서비스/컴포넌트 의존관계(컴포넌트란 컴퓨팅 환경과 관련된, 예를 들면 애플리케이션, 미들웨어, 하드웨어, 장치 드라이버, 운영 체제 및 시스템일 수 있음)의 계산을 가능하게 해주는 기술들이 개시되어 있다. 일례로서, 본 발명의 기술들은 분산 컴퓨팅 환경에 적용될 수 있다. 컴퓨팅 환경은 또한 자율 컴퓨팅 환경도 될 수 있다.

Description

분산 시스템에서의 의존관계 관리 방법 및 장치{METHODS AND APPARATUS FOR MANAGING DEPENDENCIES IN DISTRIBUTED SYSTEMS}

도 1은 정보를 생성하기 위해 본 발명의 특징적 구성들과 상호 작용할 수 있는 클라이언트-서버 애플리케이션 아키텍처의 일례를 나타낸 블록도.

도 2a는 본 발명의 일 실시예에 따른 의존관계 관리를 제공하는 시스템을 나타낸 블록도.

도 2b는 본 발명의 일 실시예에 따라 의존관계 관리를 제공하는 시스템을 구현하는 데 적당한 컴퓨터 시스템의 일반화된 하드웨어 아키텍처를 나타낸 블록도.

도 3은 본 발명의 일 실시예에 따른 서비스들의 기능적 의존관계 모델을 나타낸 블록도.

도 4는 본 발명의 일 실시예에 따른 서비스들의 구조적 의존관계 모델을 나타낸 블록도.

도 5는 본 발명의 일 실시예에 따라 기능적 의존관계 모델, 구조적 의존관계 모델 및 동작적 의존관계 모델에 의해 다루어지는 서비스 라이프사이클을 나타낸 블록도.

도 6은 본 발명의 일 실시예에 따른 기능적 의존관계 모델, 구조적 의존관계 모델 및 동작적 의존관계 모델 사이의 관계를 나타내는 블록도.

도 7은 본 발명의 일 실시예에 따라 엔드-투-엔드 의존관계(end-to-end dependency)를 계산하는 데 관여하는 컴포넌트들을 나타낸 블록도.

도 8은 본 발명의 일 실시예에 따른 의존관계 서비스의 컴포넌트들을 나타낸 블록도.

도 9는 본 발명의 일 실시예에 따라 의존관계 서비스를 호출하기 위한 동작들의 단계를 나타낸 흐름도.

도 10은 본 발명의 일 실시예에 따라 기능적 의존관계 모델을 생성 및 갱신하기 위한 관리자의 작업들을 나타낸 흐름도.

도 11은 본 발명의 일 실시예에 따라 컴퓨터 시스템 상에 하드웨어/소프트웨어 컴포넌트를 설치 또는 그로부터 제거함으로써 구조적 의존관계 모델을 갱신하는 단계들을 나타낸 흐름도.

도 12는 본 발명의 일 실시예에 따른 동작 모델의 계산을 맡고 있는 시스템의 단계들을 나타낸 흐름도.

도 13은 본 발명의 일 실시예에 따라 지정된 호스트 상에 위치하는 서비스의 직접 앤티시던트(direct antecedent)를 검색하는 단계들을 설명하는 흐름도.

도 14는 본 발명의 일 실시예에 따라 지정된 호스트 상에 위치하는 서비스의 앤티시던트들을 반복적으로 검색하는 단계들을 나타낸 흐름도.

도 15는 본 발명의 일 실시예에 따라 지정된 호스트 상에 위치하는 서비스의 직접 디펜던트(direct dependent)를 검색하는 단계들을 나타낸 흐름도.

도 16은 본 발명의 일 실시예에 따라 지정된 호스트 상에 위치하는 서비스의 디펜던트들을 반복적으로 검색하는 단계들을 나타낸 흐름도.

도 17은 본 발명의 일 실시에에 따른 의존관계 서비스 애플리케이션 프로그래밍 인터페이스의 일례들을 나타낸 도면.

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

100 : 관리자

105 : 클라이언트 시스템

110 : 네트워크

115 : 네트워크 억세스

120 : 웹 애플리케이션 서버

125 : 데이터베이스 서버

130 : 데이터베이스

관련 출원에 대한 상호 참조

본 발명은 동시 출원된 미국 특허 출원으로서, 각각 발명의 명칭이 "Methods And Apparatus For Root Cause Identification and Problem Determination in Distributed Systems(분산 시스템에서의 근본 원인 식별 및 문제점 판별을 위한 방법 및 장치)"인 미국 특허 출원 제 호(대리인 문서 번호 : YOR920020096US1), 발명의 명칭이 "Methods And Apparatus For Topology Discovery and Representation of Distributed Applications and Services(분산 애플리케이션 및 서비스의 토폴로지 발견 및 표현을 위한 방법 및 장치)"인 미국 특허 출원 제 호(대리인 문서 번호 : SOM920020003US1), 발명의 명칭이 "Methods And Apparatus For Impact Analysis and Problem Determination(영향 분석 및 문제점 판별을 위한 방법 및 장치)"인 미국 특허 출원 제 호(대리인 문서 번호 : SOM92002004US1), 및 발명의 명칭이 "Methods And Apparatus For Dependency-based Impact Simulation and Vulnerability Analysis(의존관계 기반의 영향 시뮬레이션 및 취약성 분석을 위한 방법 및 장치)"인 미국 특허 출원 제 호(대리인 문서 번호 : SOM920020005US1)와 관련되어 있으며, 이들의 개시 내용은 여기에 인용함으로써 그 전체가 본 명세서에 포함된다.

본 발명은 분산 컴퓨팅 시스템에 관한 것으로서, 보다 상세하게는 이러한 분산 컴퓨팅 시스템의 여러가지 컴포넌트들 사이의 의존관계를 관리하는 방법 및 장치에 관한 것이다.

분산 시스템의 컴포넌트들 사이의 의존관계의 식별 및 추적은 통합 장해 관리를 위해 점점 더 중요해지고 있다. 애플리케이션, 서비스 및 이들의 컴포넌트는 서비스 제공업자에 대해 아웃소싱된 것일 수 있는 각종의 지원 서비스들에 의존하고 있다. 게다가, 새로 등장하고 있는 웹 기반의(월드 와이드 웹 기반의) 사업 구조는 런타임 시에 웹 기반의 e-비지니스(전자 상거래) 애플리케이션의 구축을 할 수 있게 해준다.

용어 "런타임"이란, 일반적으로 한개의 소프트웨어가 컴퓨터의 하드 드라이브 상에서 잠자면서 단지 저장되어 있는 것에 대비되는 것으로서, 그 소프트웨어가 실행되면서 컴퓨터 시스템의 메모리에서 활동 상태에 있는 기간을 말한다는 것을 이해할 것이다. 따라서, 런타임 시에 e-비지니스 애플리케이션을 구축할 수 있다는 것은, 시스템/애플리케이션을 다운시키고 재기동시킬 필요 없이 또 그 애플리케이션을 재컴파일할 필요도 없이 그와 같이 할 수 있다는 것을 의미한다. 전통적으로, 컴퓨터 프로그램의 라이프사이클은 프로그램 코드의 작성 →컴파일(기계 코드로 번역)→실행을 말한다. 따라서, 상기와 같이 할 수 있는 경우, 몇개의 소프트웨어를 조립하여 새로운 애플리케이션을 형성하는 일을 "동작 중에(on-the-fly)", 즉 애플리케이션을 다운시키고/컴파일하여/재기동할 필요없이 행할 수 있게 된다.

그렇지만, 그 결과 한 서비스에서 일어나는 장애는 고객에 제공되고 있는 다른 서비스들에 영향을 미치게 된다. 즉, 서비스들은 다른 서비스들에 의존관계를 갖는다. 단일 시스템 상에 있는 여러가지 서비스들의 컴포넌트들 사이에 또한 다수의 시스템과 도메인에 걸쳐 있는 서비스의 클라이언트 컴포넌트와 서버 컴포넌트 사이에는 의존관계가 존재한다. 본 명세서에서는, 다른 서비스에 의존하는 서비스를 디펜던트라 하고, 다른 서비스가 의존하고 있는 서비스를 앤티시던트라고 한다.

유의해야 할 중요한 점은 한 서비스가 종종 2가지 역할을 다하는 경우가 있다는 것이다[예를 들면, 네임 서비스는 많은 애플리케이션 및 서비스에 의해 요구되는 것이지만 그 자체는 운영 체제와 네트워크 프로토콜 및 인프라와 같은 다른 서비스들의 원만한 동작에 의존하고 있음]. 게다가, 의존관계의 관계는 이행적(transitive)이다. 즉, 주어진 컴포넌트의 디펜던트는 그 컴포넌트 자신 외에도 그 컴포넌트의 앤티시던트(들)을 필요로 한다.

최종 사용자 서비스, 시스템 서비스, 애플리케이션과, 이들의 논리적 및 물리적 컴포넌트들과 같은 분산 시스템의 여러가지 컴포넌트들 사이에는 의존관계가 존재한다. 그렇지만, 서비스 의존관계는 오늘날의 시스템에서는 명확하게 되어 있지 않으며, 따라서 문제점 판별, 격리 및 해결의 작업을 특히 어렵게 만든다.

각 분야에서의 기존의 기술, 즉 소프트웨어의 개발(미국 특허 제4,751,635호 및 미국 특허 제5,960,196호 등), 유지 보수(미국 특허 제5,493,682호) 및 소프트웨어 패키징(미국 특허 제5,835,777호)에서는, 프로그램 패키지의 최소 단위(atomic part)를 형성하는 개개의 소프트웨어 엘리먼트 및 모듈을 다루고 있으며 또 소프트웨어를 작성하여 이를 소프트웨어 제품내에 번들화하기 위해서는 프로그램 소스 코드를 입수할 수 있어야만 한다. 소스 코드는 소프트웨어 개발자는 이용가능하지만 서비스 사용자는 그렇지 못하다.

IEEE(Institute of Electrical and Electronics Engineers) 표준 1387.2 [원제, "POSIX(Portable Operating System Interface) system administration, part 2 : Software Administration," IEEE, 1995]에서는 소프트웨어 분배/배치/설치(distribution/deployment/installation)를 다루고 있다. 이 IEEE 표준은 (설치 예정인) 새로운 소프트웨어 컴포넌트가 이미 존재하는 소프트웨어 설치와 충돌하지 않도록 보장하기 위한 메카니즘을 정의하고 있다. IEEE 표준은 이러한 호환성 검사를 용이하게 해주는 3가지 종류의 관계, 즉 전제 의존관계(prerequisite; 어떤 오브젝트를 인스톨/구성하기 전에 다른 오브젝트를 인스톨/구성할 필요가 있는 것을 나타냄, 전제 의존관계는 처리의 순서에 의미가 있음), 배타 의존관계(exrequisite; 어떤 오브젝트를 인스톨 또는 구성하기 전에 다른 오브젝트가 존재해서는 안된다는 것을 나타냄), 필요 의존관계(corequisite; 어떤 오브젝트가 정상적으로 작동하기 위해 다른 오브젝트가 필요하다는 것을 나타내지만, 로드의 순서에 대해서는 제한이 없음)를 구분하고 있다. 이것은 새로운 소프트웨어를 설치할 필요가 있는 모든 시스템에 대해 개별적으로 행해진다. IEEE 표준에서는, 다른 시스템들에 존재하는 소프트웨어 인벤토리는 고려에 넣지 않고 있다. 게다가, IEEE 표준은 인스턴스화된 애플리케이션 및 서비스에 대해서는 다루고 있지 않으며, 따라서 런타임 시에 컴포넌트들 사이의 의존관계를 판별하는 어떤 수단도 기술하고 있지 않다.

오픈 그룹(Open Group)[Systems Management : Distributed Software Administration, CAE Specification C701(시스템 관리 : 분산 소프트웨어 관리, CAE 규격 C701), 오픈 그룹, 1998년 1월]은 특정 시스템 상의 소프트웨어 설치 툴(software installation tool)에 의해 호출되는 몇가지 커맨드(swinstall, swlist, swmodify, 등)를 정의함으로써 IEEE 1387.2를 확장하고 있다. 오픈 그룹은 또한 전술한 커맨드에 의해 요구되는 정보가 그 커맨드가 호출되고 있는 시스템으로부터 이용가능하도록 하기 위해 소프트웨어 정의 파일 포맷도 정의하고 있다. IEEE 1387.2의 단점(즉, 단 하나의 격리된 시스템에 한정되어 있고 또 런타임 시에 소프트웨어 의존관계를 판별하는 수단이 없다는 점)은 또한 오픈 그룹 규격(Open Group specification)에도 적용된다.

현재의 운영 체제의 인벤토리 구현[IBM AIX 객체 데이터 관리자(Object Data Manager; ODM), 리눅스 레드 헷 패키지 관리자(Red Hat Package Manager; RPM) 또는 마이크로소프트 윈도즈 레지스트리 등]은 오픈 그룹 규격 및 IEEE 1387.2 표준을 따르거나 또는 소프트웨어 인벤토리를 독자적인 포맷으로 기술하거나 한다. 따라서, 전술한 제한 요소들은 또한 이와 같은 현재의 운영 체제 인벤토리 구현에도 적용된다.

전체 프로그램 패키지의 전자적 소프트웨어 분배를 위한 기술(미국 특허 제6,009,525호 및 미국 특허 제5,721,824호 등) 또는 갱신/정정/교정/패치(update/correction/fix/patch)를 위한 기술(미국 특허 제5,999,740호, 미국 특허 제5,805,891호 및 미국 특허 제5,953,533호 등)은, 정의에 의하면 (한번에 하나씩 또는 여러개씩) 물리적인 소프트웨어 패키지의 분산/배치/설치(distribution/deployment/installation)에 한정되어 있고 애플리케이션의 런타임 단계를 고려에 넣고 있지 않다. 게다가, 이들 기술은 한 번에 하나의 시스템을 취급하며, 애플리케이션 및 서비스의 시스템 상호간 측면은 고려하고 있지 않다.

기존의 소프트웨어/하드웨어 설정에 있어서의 충돌을 판별하기 위한 기술(미국 특허 제5,867,714호 등)도 단일 시스템에 한정되어 있으며 런타임 측면을 고려하고 있지 않다.

이벤트 상관 분석[예를 들면, Gruschke 등의 "Integrated Event Management : Event Correlation Using Dependency Graphs(통합 이벤트 관리 : 의존관계 그래프를 사용한 이벤트 상관 분석), DSOM '98, 1998" 및 Katker 등의 "Fault Isolation and Event Correlation for Integrated Fault Management(통합 장해 관리를 위한 장해 격리 및 이벤트 상관 분석), IM '97, 1997"]의 범위 내에 드는 경우가 많은 기존의 연구(미국 특허 제5,917,831호 등)가 서비스 의존관계를 식별하여 이를 독자적인 포맷으로 기술하는 것에 집중되어 왔지만, 장해 관리 프로세스의 서로 다른 엔티티 사이에서 의존관계 정보가 실제로 어떻게 교환되는지는 불명확한 채로 남아 있다. 아웃소싱된 애플리케이션의 장해 관리 프로세스에 관여하는 서로 다른 당사자들이 의존관계의 추적을 위해 동일한 툴 세트를 사용하지 않을 가능성이 있기 때문에, 의존관계 정보를 규정 및 교환하기 위한 공개 포맷을 정의하는 것이 근본적으로 중요하다.

요약하면, 소프트웨어 제품들 사이의 관계를 판별하는 것과 관련한 몇가지 기술들이 종래의 기술 분야에서 설명되고 구현되어 왔었다. 이들 종래의 기술들은 이하의 단점들 중 하나 이상을 가지고 있다.

(a) 종래의 기술들은 단지 소프트웨어 제품의 설치 및 배치 단계만을 다루고 있다. 즉, 설계 및 런타임 측면은 파악하려고 하지 않는다.

(b) 종래의 기술들은 다수의 시스템에 걸쳐 있는 엔드-투-엔드 애플리케이션 및 서비스를 취급하지 않는다. 즉, 단일의 고립된 시스템 상에 존재하는 소프트웨어의 특성들을 다룬다.

(c) 소프트웨어 인벤토리 정보가 이 정보를 여러가지 이기종 시스템 사이에 서 공유하는 것을 극히 어렵게 만드는 독자적인 포맷으로 기술되어 있다.

본 발명은 컴퓨팅 환경의 여러가지 컴포넌트들 사이의 정보, 특히 의존관계 정보를 관리하는 기술들을 제공한다. 일례로서, 본 발명의 기술은 분산 컴퓨팅 환경에 적용될 수 있다. 컴퓨팅 환경은 자율 컴퓨팅 환경(autonomic computing environment)도 될 수 있다.

본 발명의 한 태양에서, 컴퓨팅 환경에서 정보를 관리하는 기술은 이하의 단계/동작을 포함한다. 컴퓨팅 환경의 컴포넌트들과 관련된 정보가 획득된다. 그 다음에, 획득된 정보의 적어도 일부분으로부터, 컴퓨팅 환경의 컴포넌트들의 적어도 일부분과 관련된 하나 이상의 관계의 존재에 관한 판정이 행해진다. 본 발명에 따르면, 하나 이상의 관계의 존재에 대한 판정은 컴퓨팅 환경의 적어도 하나의 컴포넌트와 관련된 전 라이프사이클(full lifecycle)(예를 들면, 배치, 설치 및 런타임을 포함함)을 설명할 수 있다. 일례로서, 컴포넌트는 컴퓨팅 환경과 관련된 서비스, 애플리케이션, 미들웨어, 하드웨어, 장치 드라이버, 운영 체제, 또는 시스템일 수 있다. 그렇지만, 용어 "컴포넌트"는 이들 일례에 한정되는 것은 아니다.

게다가, 이 기술은 또한 컴퓨팅 환경의 적어도 2개의 컴포넌트와 관련된 이질성, 및 컴퓨팅 환경과 관련된 하나 이상의 도메인에 걸쳐 있는 하나 이상의 컴포넌트에 대해서도 설명할 수 있다.

양호한 실시예에서, 본 발명의 기술은 기능적 분류, 구조적 분류 및 동작적 분류를 포함하는 형식으로 컴포넌트 의존관계를 계산함으로써 하나 이상의 관계의 존재를 판정한다. 분류는 하나 이상의 의존관계 모델을 포함할 수 있다.

따라서, 유익하게는 본 발명은 개개의 시스템으로부터 어떤 레벨의 추상화를 제공하고 또 고객에 의해 인지되는 바와 같은 엔드-투-엔드 서비스에 관계된 서비스/애플리케이션 의존관계의 계산을 가능하게 해준다.

전술한 종래의 기술에서의 한계점과는 반대로, 본 발명은 다수의 시스템에 걸쳐 있고 또 관여된 시스템, 애플리케이션 및 서비스의 런타임 거동을 반영하는 보다 상위 레벨의 (엔드-투-엔드 서비스/애플리케이션) 뷰를 고객들에 제공함으로써 이러한 단점들을 극복한다. 수집된 의존관계 정보는 데이터 교환을 용이하게 하기 위해 공개된 확장형 포맷으로 기술된다.

본 발명의 이들 및 다른 목적, 특징 및 이점은 본 발명의 예시적인 실시예에 대한 이하의 상세한 설명을 첨부 도면과 연계하여 읽어보면 명백하게 될 것이다.

이하에서는 본 발명에 대해 예시적인 분산 컴퓨팅 환경과 관련하여 설명하게 된다. 그렇지만, 본 발명은 이러한 특정의 컴퓨팅 환경에 한정되지 않는다는 것을 이해해야 한다. 오히려, 본 발명은 보다 광의로는 문제점 판별, 격리 및 해결의 작업을 상당히 더 용이하게 행하기 위해 의존관계의 관리(예를 들면, 계산, 질의 등)을 행하는 것이 바람직한 어떤 컴퓨팅 환경에도 적용될 수 있다.

본 명세서에 사용되고 있는 바와 같이, 논의의 전후 관계에 따라, 용어 "시스템"은 컴퓨터 시스템, 소프트웨어 시스템 및/또는 이들의 어떤 조합을 말하는 것으로 사용될 수 있다. 용어 "시스템"은 또한 애플리케이션 및/또는 서비스를 지칭 하는 것으로 사용될 수도 있다. 따라서, 문구 "다중 시스템"은 몇개의 시스템의 집합체를 말한다. 또한, 용어 "컴포넌트"는 시스템 그 자체, 또는 시스템의 하나 이상의 일부분을 말할 수 있다.

전술한 바와 같이, 서비스 의존관계는 오늘날의 시스템에서는 명확하게 되어 있지 않으며, 따라서 문제점 판별, 격리 및 해결의 작업을 특히 어렵게 만들고 있다. 이러한 문제점을 해결하려면 서로 다른 시스템 및 도메인에 걸쳐 있는 서비스 및 애플리케이션 사이의 의존관계를 판정 및 계산할 필요가 있다. 즉, "글로벌" 서비스 의존관계 모델을 설정하고 시스템 관리자가 그 결과 얻어지는 방향성 그래프(directed graph)를 통하여 상단으로부터 하단까지 또는 그 역의 순서로 탐방할 수 있어야만 한다. 이러한 메카니즘의 필요성은 이하의 2가지 시나리오에 의해 잘 설명된다.

첫번째 시나리오는 일반적으로 인터넷 또는 애플리케이션 서비스 제공업자(ISP/ASP)에 의해 제공되는 아웃소싱된 서비스의 관리를 다룬다. 서비스의 아웃소싱은 층을 이루는 서비스 계층 구조를 이루게 하며, 이 경우 예를 들면 ASP의 서비스는 ISP에 의해 제공되는 IP-연결 (인터넷 프로토콜 연결)에 의존하고, 이 ISP는 이어서 전기 통신 사업자의 광역 네트워크에 의존하고 있다. 모든 층마다, 서비스는 서비스 액세스 포인트(Service Access Point; SAP)를 통해 접속된다. SAP은 상이한 유기적인 도메인 사이의 경계를 구분지어주는 것으로서, SLA(Service Level Agreement; 서비스 품질 보증 규약)가 정의되고 준수되는 장소이다. 보통, 이것은 제공업자에 의해 공개되는 한 세트의 특정 파라미터를 모니터링함으로서 모 든 층마다 행해진다. 상위계층 서비스에서 작동 정지(outage) 또는 성능 열화가 있는 경우, 그 문제점의 근본 원인을 식별해내기 위해 서비스 계층 구조를 상단에서 하단까지 순회할 필요가 있다.

두번째 시나리오는 "동작 중에는" 행해질 수 없고 따라서 서비스 및 그 고객들에게 영향을 미치게 되는 정규적인 유지보수 작업에 대해 다루고 있다. 즉, 예를 들면, e-메일 서버가 그의 운영 체제의 새로운 개정판으로 갱신되는 경우, 또는 네트워크 장치가 교환되거나 새로운 펌웨어 버전으로 업그레이드되는 경우 등이 있다. 모든 경우에, 얼마나 많은 서비스 및 사용자가, 보다 상세하게는 어떤 서비스 및 사용자가 그 유지 보수에 의해 영향을 받게 되는지를 네트워크 및 서버 관리자가 미리 판별하는 것이 중요하다. 이러한 작업을 영향 분석이라 한다.

전술한 작업들은 이하의 요인들에 의해 더욱 악화된다.

의존관계 모델은 발견된 문제점의 가능한 근본 원인을 식별해내는 간편한 수단을 제공한다. 어떤 시스템에 대한 의존관계 그래프를 알고 있는 경우, 손상된 서비스로부터 (동일한 호스트 상에 공존하거나 또는 서로 다른 시스템 상에 있는) 그의 앤티시던트들쪽으로 그 그래프를 따라가게 되면 어떤 엔티티에 장애가 발생했을지 모른다는 것을 밝혀줄 것이다. 그래프를 그의 루트까지(즉, 위쪽 방향으로) 순회하게 되면, 서비스의 디펜던트, 즉 이 서비스가 동작 정지되는 경우에 장애가 발생할지 모를 컴포넌트가 얻어지게 된다. 이하의 문제들이 해소될 필요가 있다.

(a) 규모(scale) : 많은 관여된 시스템들 사이의 의존관계의 개수는 계산될 수 있지만, 그 수가 아주 많아지게 될 수도 있다. 공학적인 관점에서 볼 때, 완전하고 인스턴스화된 의존관계 모델(complete, instantiated dependency model)을 단일 장소에 저장하는 것은 바람직하지 못한 경우가 많다(또 때로는 불가능하다). 따라서, 인스턴스화된 네트워크 맵을 플랫폼 데이터베이스에 보관하는 등의 네트워크 관리 플랫폼에서 사용되는 전통적인 메카니즘은 연관된 의존관계의 엄청난 개수(sheer number) 및 동적성(dynamics)으로 인해 의존관계에 적용될 수 없다.

이러한 2가지 사실은 애플리케이션, 서비스 및 미들웨어 의존관계 모델의 배치를 위해 "네트워크-관리-스타일" 방법을 따르는 것을 엄두도 못내게 만든다. 일례로서, 서비스 아웃소서(service outsourcer)의 전형적인 데이터 센터는 엄청난 수(수천개)의 웹 애플리케이션 및 데이터베이스 서버를 호스팅한다. 이것은 예를 들면 웹 애플리케이션 및 데이터베이스 서버의 동시 실행 프로그램 인스턴스의 개수가 엄청나다는 것을 의미한다. 의존관계 모델을 구축할 수 있는 시스템은 의존관계의 저장 및 계산을 관리 프로세스에 관여된 시스템들에 걸쳐 분산시킴으로써 적절한 확장성을 가능하게 해주는 특징적 구성을 제공해야만 한다.

(b) 동적성 : (웹 애플리케이션 서버 내에서 실행되고 있는) 호스팅된 애플리케이션은 아주 짧은 수명을 가지며, 종종은 단지 몇초에 불과한 경우도 있다. (보통은 하나 이상의 자바 서블릿으로 구현되어 있는) 웹 애플리케이션의 비지니스 로직은 요청을 수신하면 애플리케이션 서버의 서블릿 엔진에 의해 인스턴스화되고, 그의 작업을 수행한 다음에는 서블릿 엔진에 의해 제거된다. 결과적으로, 이들 동적 엔티티 사이의 의존관계를 계산하는 시스템은 데이터의 정확성과 이 데이터를 검색하기 위해 발생되는 작업 부하 사이의 트레이드오프를 해결해야만 한다.

(c) 이질성(heterogeneity) : 이질성은 3가지 서로 다른 모습으로 나타난다. 첫째, 고객들에 제공되는 서비스는 상당히 서로 다르다. 둘째, 고객에 서비스를 제공하는 데 관여된 다양한 제공업자가 있을 수 있다. 마지막으로, 어떤 서비스를 구현하는 제품들이 다양한 벤더로부터 나온 것일 수 있다. 의존관계를 계산하는 시스템은 특정의 운영 체제, 네트워크 프로토콜, 소프트웨어 제품 및 고객에 제공되는 서비스에 독립적인 언어를 제공해야만 한다.

(d) 의존관계 데이터의 수작업 유지 보수 : 서비스 의존관계 모델의 포착은 단일의 호스트 시스템에 한정되는 것조차도 그 자체로서 어떤 도전인 데, 그 이유는 오늘날의 시스템이 보통은 적절한 관리 도구를 제공하지 않기 때문이다. 용어 "도구"는 관리 애플리케이션이 어떤 (관리) 자원에 접근할 수 있도록 잘 정의된 인터페이스(때로는 표준화되어 있는 것조차 있음)를 통해 그 자원의 관리 특성 및 기능을 노출시키는 프로그램 코드를 지칭한다는 것을 이해해야 한다. 게다가, 의존관계 데이터는 관리 자원으로부터 입수가능한 경우라고 할지라도, 오늘날의 관리 시스템에 의해서는 활용되지 않고 있다. 그 대신에, 의존관계 정보는 수작업으로 뿐만 아니라 독자적인 포맷으로 특정의 관리 컴포넌트에 입력되어야만 한다. 따라서, 의존관계 정보는 (에러가 많은 수작업 처리로 인해) 불완전하고 오래된 것으로, 때로는 일관성이 없는 것조차 있는 데, 그 이유는 각기 다른 오퍼레이터가 독립적으로 룰(rule)을 입력하고 또 자동화된 방식으로 그 룰 베이스(rule base)의 일관성 검사를 하는 방법이 없기 때문이다.

(e) 의존관계의 분류법(taxonomy) : 의존관계의 개념은 그다지 정확하지 않 아 유용하게 되기 위해서는 재정립될 필요가 있다. 이것의 일례로는 의존관계의 세기(어떤 컴포넌트가 그의 앤티시던트에 장애가 발생할 경우 영향을 받게 될 가능성 및 그 정도를 나타냄), 중요도(이 의존관계가 어떤 사업의 목표 및 정책과 관련하여 얼마나 중요한지를 나타냄), 형식화 정도(즉, 의존관계를 획득하는 것이 얼마나 어려운지를 나타냄) 및 그 밖에도 더 많이 있다. 의존관계를 보다 더 적절히 한정시킬 수 있게 해주는 속성을 의존관계에 부가할 필요가 있으며, 따라서 의존관계 표현에서 이들 속성을 반영할 필요가 있다.

(f) 문제점 판별 기능 : 모든 시스템마다 저장되어 있는 로컬 의존관계 그래프를 일관된 의존관계 모델로 결합시키는 추가의 도구들이 요망된다. 게다가, 이들 도구는 관리 애플리케이션이 의존관계 모델에 대해 질의를 낼 수 있게 해주는 API(Application Programming Interface; 애플리케이션 프로그래밍 인터페이스)를 제공해야만 한다. 이들 질의는 특정의 서비스가 직접 의존하고 있는 엔티티를 검색하거나 또는 서브-앤티시던트를 포함한 전체 노드 세트를 반복적 방식으로(recursively) 결정할 수 있게 되어 있을 것이다. 관리 애플리케이션에 의해 수신되는 노드의 리스트를 사용하여 관리 애플리케이션은 이들 서비스가 동작하고 있는지를 체크하기 위해 특정의 문제점 판별 루틴을 수행할 수 있다.

앞서 논의한 바로부터, 서비스 라이프 사이클의 3가지 상이한 단계, 즉

(a) 고객에 제공되고 있는 (추상적) 서비스, 예를 들면 "웹 호스팅", "스토리지 관리", "IP 연결", "데이터베이스 관리" 등,

(b) 서비스의 구현, 즉 서비스를 제공하는 데 사용되는 제품, 예를 들면 "IBM 유니버셜 데이터베이스 버전 7.1(IBM Universal Database version 7.1)", "웹스피어 애플리케이션 서버 버전 3.2(WebSphere Application Server version 3.2)", 그리고

(c) 어떤 구현의 실행 인스턴스(들)(running instance), 즉 프로세스 또는 태스크, 예를 들어 "db2 대몬(db2 daemon)", "nfs 대몬(nfs daemon)"

사이의 매핑을 설정하는 것이 중요하다는 것을 알았다.

모든 단일 단계에서 이용가능한 정보를 개별적으로 획득하는 작업은 실현가능하지만, 3가지 단계를 일관된 의존관계 모델로 결합시키는 것은 어려운 일이며 이전의 연구에서는 행해진 적이 없었다. 게다가, 사람의 상호 작용 및 의존관계 데이터의 유지를 필요없게 해주면서 기반 환경의 규모, 동적성 및 이질성의 요건을 다루는, 효율적으로 계산이능한 의존관계 모델을 확립할 필요가 있다.

도면들과 관련하여 이하에 설명하게 되는 바와 같이, 본 발명은 이들 및 다른 요구 사항들을 다루고 있다. 즉, 본 발명은 관리 애플리케이션을 대신하여 분산 시스템의 컴포넌트들 사이의 런타임 의존관계("의존관계 모델")을 계산하는 특징적 구성들을 갖는다. 본 발명은 개개의 컴퓨터 시스템들의 설정 정보를 검색하는 메카니즘을 제공하거나 또는 이러한 데이터를 기계 판독가능한 포맷으로 제공하는 컴퓨터 시스템들로부터 의존관계 정보를 검색하기 위한 일반적이고 일관성있는 방법을 제공한다.

전술한 시스템의 한가지 이점은 대량의 애플리케이션/서비스 관리 정보가 개개의 애플리케이션/서비스마다 관리할 필요없이 이들 컴퓨터 시스템으로부터 획득 될 수 있다는 점이다. 그렇지만, 이러한 애플리케이션/서비스 관리가 이용가능한 경우, 본 발명에서는 이를 사용할 수 있다.

본 발명에서 기술된 시스템의 실행은 특정의 (관리) 애플리케이션(영향 분석기, 근본 원인 분석기 등)이나 네트워크 관리 플랫폼(IBM/Tivoli NetView, HP OpenView 또는 Aprisma Spectrum), 또는 전통적인 네트워크 관리 시스템 및 플랫폼에 기반한 관리 애플리케이션에 의해 트리거될 수 있다.

본 발명은 그 중에서도 특히,

(a) 가입한 서비스의 성능 열화 및 동작 정지를 관찰하고,

(b) 의존관계 모델의 서로 다른 계층을 상단으로부터 하단까지 순회함으로써 문제점의 근본 원인의 추적하며(다양한 서비스가 다른 서비스 제공업자에 아웃소싱될 수 있기 때문에, 의존관계 모델의 이러한 (반복적) 순회는 도메인 경계를 넘나들게 됨),

(c) 의존관계 모델을 하단에서 상단까지 순회함으로써 서비스 중지의 영향을 분석하기 위한 특징적 구성들을 제공한다.

본 발명은 애플리케이션 또는 서비스의 라이프사이클 동안(즉, 애플리케이션/서비스의 설계 단계에서부터 배치, 설치 및 런타임 단계까지)에 입수가능한 의존관계 정보를 결합시킨다. 이 정보는 이하의 모델들 내에 보관된다.

(a) 기능 모델 : 양호한 구현에서, 기능 모델은 상이한 일반 서비스(데이터베이스 서비스, 네임 서비스, 웹 애플리케이션 서비스, 연결 서비스 등) 사이의 의존관계를 정의한다. 기능 모델은 특정 서비스 내에서의 클라이언트/서버 관계는 기술하지 않는다. 게다가, 기능 모델은 그 서비스를 구현하는 데 어떤 구체적인 제품이 선택되었는지는 물론 그 제품의 실제 구성에 대해 전혀 고려하고 있지 않다. 기능 모델은 (이하에 기술하는) 다른 모델들이 구속받는 주요 제약 요건들을 설정한다. 즉, 추가의 모델들은 기능 모델에서 정의된 의존관계를 구체적인 시스템 인프라에 관해 더 세밀히 구분할 수 있지만 서비스 카테고리들 사이의 새로운 의존관계를 도입해서는 안된다. 이 모델은 아주 콤팩트하고 포괄적이며, 양호하게는 관리 시스템에 저장된다.

(b) 구조 모델 : 양호한 구현에서, 구조 모델은 기능 모델에서 정의된 서비스들을 실현시키는 소프트웨어 컴포넌트들에 대한 상세한 설명을 포함하고 있다. 구조 모델은 설치/배치 단계 중에 포착되는 세부 사항을 제공하며, 구체적인 시스템의 소프트웨어 인벤토리를 고려에 넣음으로써 기능 모델을 보완한다. 이 구조 모델은 특정 시스템 상에 어떤 서비스가 설치 및 설정되어 있는지, 그리고 모든 서비스마다 그 시스템이 클라이언트 역할로 동작하는지 서버 역할로 동작하는지에 관한 정보를 제공한다. 시스템 및 서비스의 수가 많을 수 있기 때문에 원격 장소로부터 이들 의존관계를 추적하는 것이 어렵다. 따라서, 이 모델은 관리 자원에 또는 그와 가까운 곳에 저장해두는 것이 바람직하다.

(c) 동작 모델 : 양호한 구현에서, 소프트웨어 패키지가 인스턴스화되고 서비스와 애플리케이션 사이의 바인딩(binding)이 확립될 때, 의존관계의 동작 모델이 생성된다. 이 모델의 동적성이 아주 높다는 것과 관여된 시스템의 수가 엄청나다는 점이 완성된 모델이 인스턴스화 및 저장될 수 있는 범위에 제한을 주게 된다. 이러한 모델을 정의 및 저장하는 것은 실용적이지 못하며, 오히려 이 모델은 동적으로 단계마다 계산되어야만 한다. 따라서, 동작 모델은 "요구가 있을 때(on demand)" 계산되며 기능 모델 및 구조 모델에 의존한다.

예상되는 바와 같이, 의존관계 수량 및 그의 동적성은 대규모 분산 시스템에서는 극도로 높다. 본 발명의 특징적 구성은 (자원 및 대역폭 사용량의 관점에서) 분산 시스템에 대한 이들의 영향을 가능한 한 작게 유지하고 또 성능에 영향을 줄 수도 있는 많은 설정 옵션을 사용자에 일임한다. 이것의 일례로는, 갱신된 의존관계 모델을 검색하기 위한 시간 간격, 추적해야만 하는 의존관계를 갖는 시스템의 범위, 의존관계 모델의 깊이[즉각 영향을 받는 서비스만, 주어진 서비스에 대한 이행적 폐포(transtive closure), 전체 서비스 계층 구조]가 있다.

본 발명은 양호하게는 의존관계 정보의 이하의 특성들을 활용한다.

(a) 서로 다른 서비스들 사이의 의존관계는 계층 구조를 이루고 있다. 게다가, 그들의 의존관계 그래프는 방향성(directed)이고 비순환(acyclic)이다. 방향성이고 비순환이라는 것은 또한 DNS(Domain Name System; 도메인 네임 서비스), NFS(Network File System; 네트워크 파일 시스템), DFS(Distributed File System; 분산 파일 시스템), NIS(Network Information System; 네트워크 정보 시스템), 등과 같은 IP-기반의 네트워크화된 서비스에서의 경험도 반영하고 있지만, 일부 시스템에서는 상호 의존관계가 존재할 경우가 있을 수 있다. 이러한 상호 의존관계의 병리학적 일례(pathological example)로는, 원격 시스템으로부터 NFS를 거쳐 그의 DNS 설정이 저장되어 있는 파일 시스템을 탑재하고 있는 DNS 서버가 있다. 이러한 설정이 기술적으로는 실시가능하지만, 그것은 시스템 설계에서의 결함을 반영하고 있는 데, 그 이유는 이것이 부트스트래핑(bootstrapping)이 비결정적일 수 있는 불안정한 시스템을 야기시키며 따라서 이를 피해야만 하기 때문이다. 순환적 의존관계를 발견하는 의존관계 검사 애플리케이션(dependency-checking application)은 관리자에게 경보를 내보내야만 한다.

(b) 모든 의존관계는 고객/제공업자 도메인 경계에서 볼 수 있고 또 SLA에 의해 명확하게 된다. 따라서 관측가능한 의존관계의 수는 유한으로 된다.

(c) 의존관계 모델은 의존관계 체인(dependency chain)의 하향식 순회(top-down traversal)를 가능하게 해준다.

(d) 상이한 시스템들 사이의("시스템간") 의존관계는 동일한 서비스의 클라이언트부와 서버부 사이의 의존관계로서 인식된다. 서비스 A의 클라이언트가 상이한 서비스 B를 제공하는 서버에 요청을 보내는 것은 가능하지 않다.

본 발명의 한 목적은 구체적인 서비스/애플리케이션 도구(instrumentation)로부터 최대 수준의 독립성을 달성하기 위해 정보를 주로 잘 알려진/잘 정의된 몇몇 장소[예를 들면, 시스템 리포지터리(system repository)]로부터 검색하는 데 있다. 이를 달성하기 위해, 본 발명은 최소 충분량의 공동으로 이용가능한 의존관계 정보를 정의한다.

본 발명은 의존관계 모델을 지속적으로 저장해두기 위한 설비를 포함하거나 또는 이 일을 본 발명을 사용하는 다른 서비스나 관리 애플리케이션에 일임하거나 한다.

본 발명은 의존관계 모델에서의 변경을 검출 및 판별하기 위해 이력(history)의 개념을 가질 수 있다. 이러한 경우에, 본 발명은 의존관계 모델 내에서의 변경에 대해 이전에 등록했던 소프트웨어 컴포넌트에 통지하기 위한 게시/구독형 인터페이스(publish/subscribe interface)를 제공한다. 본 발명의 다른 가능한 사용법은 의존관계 모델에 변경이 있었는지를 판별하도록 본 발명에 대한 주기적인 호출을 발하기 위해 의존관계 모델에서의 변경의 검출을 관리 애플리케이션(또는 변경 관리 서비스)에 일임시키는 것이다.

상기 실현예가 본 발명 및 본 발명과 관련된 일반적 특징에 따라 실시된다고 할 때, 상세한 설명의 나머지 부분에서 도 1 내지 도 17과 관련하여 이러한 실현예 및 특징적 구성을 구현하는 기술들의 일례에 대한 설명을 제공할 것이다.

먼저 도 1을 참조하면, 블록도는 정보를 생성하기 위해 본 발명의 특징적 구성과 상호 작용할 수 있는 클라이언트-서버 애플리케이션 아키텍처 형태의 전자 상거래 시스템의 일례를 나타낸 것이다. 이하에서는, 본 발명의 기술들이 없는 경우에 이러한 아키텍처가 트랜잭션을 어떻게 처리할 수 있는지를 설명하기 위해 도 1의 아키텍처에 대해 기술할 것이다.

도시되어 있는 바와 같이, 클라이언트 시스템(105)은 예를 들면 키보드를 통해 요청을 개시하는 데 사용된다. 그렇지만, 요청은 마우스 클릭, 음성 명령, 바코드 긁기(bar code swipe)에 의하는 것과 같은 어떤 종래의 수단에 의해서도 개시될 수 있다. 클라이언트 시스템(105)의 일례로는, 퍼스널 컴퓨터, 키오스크(kiosk), 데이터 입력 단말기, 스캐너, 전화, 페이저, 핸드헬드 또는 웨어 러블 디바이스(handheld or wearable device), 무선 장치, 개인 휴대 단말기, 네트워크 기능을 갖는 시계(network-enabled watch) 등이 있다.

이 요청이 있으면 그 요청은 로컬적으로 형식화되고, 네트워크(110)를 거쳐 또 하나 또는 여러개의 네트워크 액세스(115) 장치를 통과함으로써 웹 애플리케이션 서버(120)로 포워딩된다. 네트워크(110) 및 통신 프로토콜의 일례로는, LAN(local area network; 근거리 통신망)을 통해 TCP/IP(전송 제어 프로토콜/인터넷 프로토콜)의 트랜스포트(transport) 상으로 행해지는 소켓 기반 통신이 있으며, 이 때 LAN은 라우터 및 스위치 등의 네트워크 액세스(115) 장치에 의해 서비스 제공업자, 그리고 궁극적으로는 웹 애플리케이션 서버(120)로의 가상 회선(virtual circuit)을 생성해주는 많은 스위칭 장소를 포함하는 WAN(wide area network; 광역망)에 연결되어 있다. 웹 애플리케이션 서버(120)의 일례로는, 클라이언트로부터의 소프트웨어 필드 테스트 요청(software fielding request)을 실행하고 또 그 요청을 적절할 때 적당한 백-엔드 데이터베이스 서버로 분산시키는, 고성능(high-end)의 퍼스널 컴퓨터, RISC-기반의 Power PC, UNIX 기반의 워크 스테이션, 미니 컴퓨터 또는 메인 프레임 컴퓨터가 있다.

이제부터, 인터넷을 사용하여 물품을 구매하는 데 [클라이언트 시스템(105) 상에서 실행되고 있는] 웹 브라우저 내에서 개시되는 전자 상거래 트랜잭션에 대해 기술할 것이지만, 이는 단지 예시적인 것에 불과한 것이다. 본 발명의 기술들은 어떤 형태의 트랜잭션에 대해서도 작용할 수 있다는 것을 이해해야 한다. 웹 애플리케이션 서버의 일례로는 WEBSPHERE라는 상표로 IBM Corporation으로부터, WEBLOGIC이라는 상표로 BEA Systems, Inc.로부터, 또는 LOTUS DOMINO SERVER라는 상표로 Lotus로부터 입수가능한 것들이 있지만, 이에 한정되는 것은 아니다.

일례의 트랜잭션에서, 웹 애플리케이션 서버(120)의 비지니스 로직은 들어오는 요청을 처리하고 클라이언트 시스템(105)의 인증 및/또는 식별을 제공한다. 웹 애플리케이션 서버(120)에 의해 구현된 비지니스 로직이 일단 그 클라이언트가 구매를 진행해도 된다고 판정한 경우, 그 비지니스 로직은 인벤토리를 축소시키기 위해 다른 요청을 네트워크(123)를 거쳐 데이터베이스 서버(125)로 전달한다. 데이터베이스 서버(125)는 그 요청을 처리하고, 그의 데이터베이스(130)에 액세스하여 웹 애플리케이션 서버(120)에 대한 응답을 준비한다. 데이터베이스 서버의 일례로는, SQL/SERVER 또는 TRANSACTION SERVER라는 상표로 마이크로소프트에 의해, 또 DB2 UNIVERSAL DATABASE SERVER라는 상표로 IBM Corporation에 의해 판매되는 것들이 있지만, 이에 한정되는 것은 아니다.

웹 애플리케이션 서버(120)는 데이터베이스 서버(125)로부터 응답을 수신하고 이를 네트워크(110)를 거쳐 클라이언트 시스템(105)으로 반환한다. 그러면 클라이언트 시스템(105)은 그 응답을 디스플레이하기 위한 포맷으로 만들기 위해 처리하고, 그 응답을 트랜잭션 개시자(transaction initiator)가 검토하도록 제시해준다.

관리자(100)는 서비스 제공업자의 사이트에 위치하는, 비지니스 트랜잭션을 처리하는 데 사용되는 여러가지 소프트웨어 및 하드웨어 컴포넌트가 제대로 기능을 하고 있는지를 판정하기 위해 이들을 관찰한다. 테이블 공간(tablespace)의 손상 또는 데이터베이스 런타임 시스템의 고장과 같은 동작 정지(135)가 데이터베이스(130)에 발생한 경우, 관리자(100)의 작업은 동작 정지의 원인의 위치를 알아내고, 그 문제점을 치유하며, 전체 시스템이 다시 제대로 기능하는지를 확인하는 것이다. 본 발명에서 목적하는 바는 어떤 형태의 동작 정지 또는 성능 열화에도 동작하도록 하는 것이라는 것을 이해해야 한다.

관리자(100)와 소프트웨어 및 하드웨어 컴포넌트와의 상호 작용은, 직접 또는 잘 정의된 관리 인터페이스에 있는 소프트웨어 및 하드웨어 컴포넌트에 의해 드러나는 관리 정보(상태 및 건강 데이터 등)를 처리하는 관리 시스템을 통해 이루어진다. 어느 경우에든지, 유의해야 할 중요한 점은 하드웨어 및 소프트웨어 컴포넌트는 관리자에 의해 격리된 자원으로서 인지되며, 특정의 비지니스 목적에 이용되는 전체 시스템의 일부로서 인지되는 것은 아니라는 것이다.

특히, 어느 한 컴포넌트에서 일어나는 에러를 알아채지 못할 수도 있는 데, 그 이유는 관리자가 연속적인 모니터링의 부족으로 인해 이들을 알지 못하게 되기 때문이다. 게다가, 본 발명의 기술들이 없는 경우, 여러가지 컴포넌트들 간의 상호 의존관계(interdependency)에 관한 명확한 정보를 관리자가 간편한 방법으로 입수할 수 없다. 따라서, 연속적으로 모니터링되지 않은 컴포넌트 내의 에러는 그 장애가 모니터링되는 컴포넌트에 전파될 때까지는 모르는 채로 지나가게 되는 경우도 있을 수 있다.

전술한 데이터베이스 동작 정지(135)의 경우에, 관리자는 종국에 가서 웹 애플리케이션 서버(120)가 더 이상 제대로 기능하지 않는 경우가 되어서야 그 동작 정지를 알게 될 뿐이다 [예를 들어, 웹 애플리케이션 서버에 걸리는 부하는 급격히 증가하는 데, 그 이유는 서버가 계속하여 그 데이터베이스 서버(125)로의 접속을 재시도하지만 클라이언트 시스템(105)이 보낸 요청을 완료할 수 없기 때문이다]. 따라서, 관리자(100)는 먼저 웹 애플리케이션 서버(120)를 검사한 다음에, 네트워크(123) 연결 문제점이 있는지를 판정하고, 마지막으로 데이터베이스 서버(125)가 데이터베이스(130)에서의 내부 에러로 인해 생긴 것일 수 있는 어려움을 겪고 있는지를 확인한다.

전술한 클라이언트-서버 애플리케이션 아키텍처는 새로 부상하는 컴퓨팅 환경의 선구자로서 볼 수 있으며, 이를 IBM Corporation에서는 "자율" 컴퓨팅 환경(autonomic computing environment)이라고 부른다. P. Horn의 "자율 컴퓨팅 : 정보 기술의 현황에 대한 IBM의 시각(원제: Autonomic Computing: IBM's Perspective on the State of Information Technology), 2001년 10월, IBM Research "이란 논문에서는, 자율 컴퓨팅을 사람의 간섭을 최소로 갖는 자가 관리 컴퓨팅 시스템(self-managed computing system)에 대한 포괄적이고 전체적인 방법으로서 정의하고 있다. 이 용어는 의식적인 자각(conscious awareness) 또는 관여없이 주요 기능을 제어하는 인체의 자율 신경계로부터 온 것이다. 보다 구체적으로는, 자율 컴퓨팅의 목표들 중 하나는 관리자(100)가 일반적으로 수행하게 될 작업들의 일부 또는 그 전부를 자동화하는 것이다. 그렇게 하는 동기는 다음과 같다.

컴퓨팅이 발전함에 따라, 중복되는 연결, 의존관계, 및 상호 작용하는 애플 리케이션은 사람이 전달할 수 있는 것보다 더 빠른 관리적 의사 결정 및 응답을 요구한다. 장애의 근본 원인을 정확하게 잡아내는 것이 더욱 어려워지고 있지만, 시스템 효율을 높이는 여러가지 방법을 찾는 것은 사람이 해결할 가망성이 있는 것보다 더욱 많은 변수를 갖는 문제점을 발생시킨다. 자율 컴퓨팅 환경의 서로 다른 시스템들 사이의 의존관계를 식별 및 추적하는 문제는 다음과 같은 특성을 가질 수 있다. 시스템이 많은 레벨에 존재할 수 있기 때문에, 자율 시스템은 자신을 통제하기 위해 그의 컴포넌트, 현재의 상태, 최대 용량(ultimate capacity), 및 다른 시스템들과의 모든 연결에 대해 상세히 알고 있을 필요가 있다. 당업자라면 본 발명이 자율 컴퓨팅 환경에서 수행될 수 있다는 것을 잘 알 것이다.

이제부터 도 2a를 참조하면, 블록도는 본 발명의 일 실시예에 따른 의존관계 관리를 제공하는 시스템을 도시한 것이다. 보다 구체적으로 말하면, 도 2a는 전술한 문제점들을 해소하는 의존관계 관리 시스템을 도시한 것이다. 이 시스템은 4개의 계층[애플리케이션 계층(200), 서비스 계층(205), 미들웨어 계층(210) 및 자원 계층(215)]과 관리자(100)가 시스템과 상호 작용하는 데 사용하는 관리자 GUI(그래픽 유저 인터페이스, 285)를 포함하고 있다.

최하위 계층은 자원 계층(215)이다. 자원 계층(215)은 관리 자원(managed resource, 220), 자원 의존관계 리포지터리(resource dependency repository, 225) 및 리포지터리 에이전트(repository agent, 230)를 포함한다. 관리 자원(220)의 일례로는, 물리적 및 논리적 하드웨어 컴포넌트[물리적 하드웨어 컴포넌트의 일례로는 하드디스크, RAM(Random Access Memory, 랜덤 억세스 메모리), 중앙 처리 장 치, 네트워크 어댑터, 채널 컨트롤러 등이 있고, 논리적 하드웨어 컴포넌트의 일례로는 디스크 파티션, 파일 시스템 등이 있음] 및 소프트웨어 컴포넌트[운영 체제, 프린트 스풀러나 네임 서비스 같은 시스템 서비스, 및 최종 사용자 애플리케이션 등이 있음]가 있지만, 이들에 한정되는 것은 아니다.

자원 의존관계 리포지터리(225)는 모든 관리 자원(220)의 하드웨어 및 소프트웨어 컴포넌트의 인벤토리 및 각 자원별 의존관계 정보[즉, 관리 자원(220) 내의 컴포넌트들 사이의 의존관계]를 포함하고 있다. 자원 의존관계 리포지터리(225)는 모든 개개의 관리 자원(220)과 동일 장소에 위치하거나 또는 집중된 한 장소에 존재할 수도 있다. 자원 의존관계 리포지터리(225)는 리포지터리 에이전트(230)를 통해 질의를 받고, 갱신되며 수정될 수 있으며, 이에 따라 자원 의존관계 리포지터리의 정보(225)는 시스템의 다른 컴포넌트들이 이용할 수 있게 된다.

미들웨어 계층(210)은 시스템의 서로 다른 컴포넌트들이 (관리) 정보를 교환하는 데 사용되는 프로토콜 및 ORB(Object Request Broker; 오브젝트 요청 브로커) 등의 관리 통신 인프라(235)를 포함한다.

서비스 계층(205)은 각종의 관리 애플리케이션들에 의해 사용될 수 있는 정책, 이벤트 및 디렉토리 등의 여러가지 일반 관리 서비스(250)를 포함한다. 특별히 중요한 서비스는 의존관계 서비스(245)로서, 이는 관리 자원(220)으로부터도 리포지터리 에이전트(230)로부터도 정보를 검색하고, 이 정보를 처리하여 전체 자원 환경의 엔드-투-엔드 의존관계 모델을 설정한다. 이 모델(또는 그의 일부)는 의존관계 서비스(245)의 요구 사항(예를 들어, 보다 빠른 검색을 위한 캐싱)에 따라 엔 드-투-엔드 의존관계 리포지터리(240)에 저장된다. 유의할 점은 의존관계 서비스(245)가 전술한 시스템에서 엔드-투-엔드 의존관계 리포지터리(240)와 직접 상호작용하는 유일한 컴포넌트라는 것이다.

애플리케이션 계층(200)은 일반 관리 서비스(250) 및/또는 의존관계 서비스(245)를 사용하는 여러가지 관리 애플리케이션을 포함한다. 이러한 관리 애플리케이션의 일례로는, 장해 관리자(260), 토폴로지 발생기(265), 영향 분석기(270), 및 근본 원인 분석기(280)가 있지만, 이에 한정되는 것은 아니다.

근본 원인 분석기(280)는 동작 정지에 의해 영향을 받은 컴포넌트로부터 그의 앤티시던트쪽으로 [의존관계 서비스(245)에 의해 제공되는] 의존관계 모델를 순회한 것에 기초하여 동작 정지의 근본 원인(즉, 동작 정지를 처음으로 야기시킨 컴포넌트)을 판별한다. 근본 원인 분석기는 발명의 명칭이 "Methods and Apparatus For Root Cause Identification and Problem Determination in Distributed Systems(분산 시스템에서 근본 원인 식별 및 문제점 판별을 위한 방법 및 장치)"인, 상기 인용된 동시 출원된 미국 특허 출원 제 호(대리인 문서 번호 YOR920020096US1)에 개시된 기술들을 사용할 수 있다. 그렇지만, 다른 근본 원인 분석 기술들도 사용될 수 있다.

영향 분석기(270)는 동작 정지를 겪고 있는 컴포넌트로부터 그의 디펜던트쪽으로 [의존관계 서비스(245)에 의해 제공되는] 의존관계 모델을 순회한 것에 기초하여 동작 정지의 영향(즉, 동작 정지에 의해 영향을 받을 가능성이 있는 컴포넌트)을 판별한다. 영향 분석기는 발명의 명칭이 "Methods And Apparatus For Impact Analysis and Problem Determination(영향 분석 및 문제점 판별을 위한 방법 및 장치)"인, 상기 인용한 동시 출원된 미국 특허 출원 제 호(대리인 문서 번호 SOM920020004US1)에 개시된 기술들을 사용할 수 있다. 그렇지만, 다른 영향 분석 기술들이 사용될 수도 있다.

영향 분석기(270)에 바탕을 둔 영향 시뮬레이터(275)는 특정 컴포넌트의 동작 정지가 전체 시스템에 미치는 영향을 시뮬레이션함으로써 관리자(100)가 "what-if" 분석(즉, 가정 분석)을 수행할 수 있게 해준다. 이것은 적절한 페일오버 해결책(failover solution)의 프로비저닝(provisioning)을 가능하게 해준다. 영향 시뮬레이터는 발명의 명칭이 "Methods And Apparatus For Dependency-based Impact Simulation and Vulnerability Analysis(의존관계 기반의 영향 시뮬레이션 및 취약성 분석을 위한 방법 및 장치)"인, 상기 인용한 동시 출원된 미국 특허 출원 제 호(대리인 문서 번호 SOM920020005US1)에 개시되어 있는 기술들을 이용할 수 있다. 그렇지만, 다른 영향 시뮬레이션 기술들도 사용될 수 있다.

장해 관리자(260)는 근본 원인 분석기(280) 또는 영향 분석기에 의해 고장날 후보로서 식별된 컴포넌트들에 대해 적절한 "건전성 검사(sanity check)" 또는 테스트를 수행한다. 즉, 장해 관리자는 근본 원인 분석기(280) 또는 영향 분석기(270)의 지시가 있을 때 이러한 테스트를 수행(즉, 이들 모듈에 대한 인터페이스로서 기능)하여 결과를 다시 그 곳에 보고할 수 있다. 그렇지만, 근본 원인 분석기(280) 또는 영향 분석기(270)는 장해 관리자와는 독립적으로 그 자신의 테스트를 수행할 수 있다.

장해 관리자는 양호하게는 테스트되고 있는 컴포넌트가 올바로 동작하고 있는지 여부에 관한 결정을 할 수 있게 해주는 애플리케이션 고유의 툴 또는 자원 고유의 툴의 집합체로 이루어져 있다. 따라서, 장해 관리자는 관련 툴을 가지고서 컴포넌트를 테스트한 후에, 컴포넌트가 "작동하는지" 또는 "작동하지 않는지"를 나타내는 메시지를 반환할 수 있다. 이들 툴은 자동화되어 있는 것 및/또는 수동인 것일 수 있다. 한 자동화된 일례로서, 소위 "ping" 프로그램은 네트워크 연결을 검사한다. 대상 원격 시스템이 ping에 응답하면, 그 원격 시스템은 온라인 상태에 있고, 그의 네트워크 프로토콜 스택(및 모든 기반 하드웨어, 예를 들어 네트워크 어댑터, 케이블, 중간 네트워크 컴포넌트 등)은 작동한다. 원격 시스템이 응답하지 않는 경우, 적어도 뭔가 잘못되어 있다는 것을 알게 되고 다른 툴 (세트)이 그 문제점을 판별하는 데 사용될 수 있다. 따라서, 장해 관리자는 분산 컴퓨팅 환경(예를 들어 맥박 검출, 상태 표시 등)의 컴포넌트들을 테스트하는 데 필요한 임의의 수 및 유형의 다른 툴 뿐만 아니라 ping 프로그램을 사용할 수 있다.

토폴로지 발생기(265)는 웹 애플리케이션, 데이터베이스 인스턴스(database instance) 및 트랜잭션 등의 엄청나게 많은 고도의 동적 컴포넌트를 포함하는 분산 시스템의 전체 토폴로지(의 부분집합)을 확립한다. 토폴로지 발생기(265)를 사용하는 일례로는 특정의 클라이언트 시스템(105)의 요청을 완수하는 데 관여하는 분산 시스템의 컴포넌트들을 표시하는 것이 있다. 의존관계 모델(또는 그의 일부)은 토폴로지 발생기(265)의 요구 사항(예를 들어, 보다 빠른 검색을 위한 캐싱)에 따라 토폴로지 데이터베이스(255)에 저장된다. 유의할 점은 토폴로지 발생기(265)가 분산 시스템에서 토폴로지 데이터베이스(255)와 직접 상호작용하는 유일한 컴포넌트라는 것이다. 토폴로지 발생기는 발명의 명칭이 "Methods And Apparatus For Topology Discovery and Representation of Distributed Applications and Services"(분산 애플리케이션 및 서비스의 토폴로지 발견 및 표현을 위한 방법 및 장치)인, 상기 인용된 동시 출원된 미국 특허 출원 제 호(대리인 문서 번호 SOM92002003US1)에 개시되어 있는 기술들을 사용할 수 있다. 그렇지만, 다른 토폴로지 발생 기술도 사용될 수 있다.

이제부터 도 2b를 참조하면, 도면들에 도시되고 본 명세서에 상세하게 기술되어 있는 바와 같은, 의존관계 관리를 제공하는 시스템의 여러가지 기능 컴포넌트/모듈을 구현하는 데 적합한 컴퓨터 시스템의 일반화된 하드웨어 아키텍처를 나타낸 블록도가 도시되어 있다. 의존관계 관리 시스템의 개개의 컴포넌트들, 즉 그래픽 유저 인터페이스(285), 애플리케이션 계층(200), 서비스 계층(205), 및 미들웨어 계층(210)(도 2a 참조)과 관련된 컴포넌트들이 도 2b에 도시한 것과 같은 아키텍처를 갖는 하나 이상의 컴퓨터 시스템 상에 구현될 수 있다는 것을 이해해야 한다. 도 2a에 도시한 다른 컴포넌트들, 예를 들어 자원 계층(215)과 관련된 컴포넌트들도 유사한 컴퓨터 시스템 상에 구현될 수 있다.

도시한 바와 같이, 컴퓨터 시스템은 프로세서(290), 메모리(292) 및 I/O 장치(294)에 따라 구현될 수 있다. 본 명세서에서 사용되는 용어 "프로세서"는 예를 들면 CPU(중앙 처리 장치) 및/또는 다른 처리 회로를 포함하는 것과 같은 임의의 처리 장치를 포함시킬 의도로 사용된 것이라는 것을 잘 알 것이다. 본 명세서에서 사용되는 용어 "메모리"는 예를 들면 RAM, ROM, 고정식 메모리 장치(예를 들어, 하드디스크), 착탈식 메모리 장치(예를 들어, 디스켓), 플래시 메모리 등과 같은, 프로세서 또는 CPU와 관련된 메모리를 포함시킬 의도로 사용된 것이다. 게다가, 본 명세서에 사용된 "입력/출력 장치" 또는 "I/O 장치"는 예를 들어 처리 유닛에 데이터를 입력하기 위한 하나 이상의 입력 장치(예를 들어, 키보드) 및/또는 처리 유닛과 관련된 결과를 제시하기 위한 하나 이상의 출력 장치(예를 들어, CRT 디스플레이 및/또는 프린터)를 포함시킬 의도로 사용된 것이다.

또한 용어 "프로세서"는 하나 이상의 처리 장치를 말한다는 것과 또 하나의 처리 장치와 관련된 여러가지 요소들이 다른 처리 장치들과 공유될 수 있다는 것을 이해할 것이다.

따라서, 본 명세서에 기술되어 있는 바와 같이, 본 발명의 여러 방법들을 수행하는 명령어 또는 코드를 포함한 소프트웨어 컴포넌트들은 관련 메모리 장치들(예를 들어, ROM, 고정식 또는 착탈식 메모리) 중 하나 이상에 저장될 수 있으며, 이용될 준비가 되어 있는 경우 부분적으로 또는 전체적으로 (예를 들어 RAM에) 로드되어 CPU에 의해 실행된다.

이제 도 3을 참조하면, 블록도는 본 발명의 일 실시예에 따른 서비스들의 기능적 의존관계 모델을 나타낸 것이다. 보다 구체적으로 말하면, 도 3은 도 1에 나타낸 것과 같은 전자 상거래 시스템에서 여러가지 컴포넌트들 사이의 기능적 애플리케이션 의존관계 그래프를 나타낸 것이다. 이러한 기능적 의존관계 모델은 분산 시스템의 기능 컴포넌트들과 그들의 의존관계 모두를 표현한 것이다. 따라서, 이 모델은 비지니스 관점에서 볼 때 최소 단위(atomic)로 생각되는 일반 서비스들 사이의 의존관계를 정의한다. 이것은 기능 모델이 비지니스 서비스 내에서 일어나는 의존관계와는 관련이 없다는 것을 암시한다. 이러한 분해는 서비스를 구현하는 데 사용되는 특정 제품의 범위에서 의미가 있으며, 이에 대해서는 도 4를 참조하여 더욱 상세히 설명할 것이다.

컴포넌트들 사이의 의존관계는 화살표로 표시되어 있다. 화살표는 항상 디펜던트로부터 앤티시던트로 향하고 있다. 기능 컴포넌트들은 고객에게 엔드-투-엔드 서비스를 제공하기 위해 서비스 제공업자가 배치할 필요가 있는 (서브) 서비스이며, 엔드-투-엔드 서비스는 SLA(Service Level Agreement; 서비스 품질 보증 규약)에 정의되어 있다. 기능 모델은 엔드-투-엔드 서비스의 설계에 집중되어 있으며, 서비스 제공에 사용되는 제품, 그들의 위치(로컬 또는 원격 시스템), 제공업자 도메인(즉, 제공업자 자신이 고객에 투명한 방식으로 그의 서비스 일부를 다른 서비스 제공업자에 아웃소싱하는지 여부) 등과 같은 엔드-투-엔드 서비스의 기술적 실현의 상세 내용을 요약하고 있다.

도시한 바와 같이, e-비지니스 애플리케이션(300) 서비스는 비지니스 로직을 호스팅하기 위해 웹 애플리케이션 서비스(305)에 의존하고 있다. 웹 애플리케이션 서비스(305)는 제대로 기능하기 위해서 2가지 추가의 서비스를 필요로 한다. 전자 상거래 웹 사이트의 정적 컨텐츠(static content)는 웹 서비스(310)에 의해 제공되는 반면, 백-엔드 데이터베이스 서비스(330)는 고객에 제공되고 있는 e-비지니스 애플리케이션(300)의 (제품 설명, 사용자 및 제조업자 데이터, 쇼핑 카트, 사용자 프로파일 및 기호, 지불 정보 등) 동적 컨텐츠(dynamic content)를 저장한다. 웹 서비스(310)는 그 자체가 2가지 서비스, 즉 호스트 이름(host name)을 IP 어드레스에 매핑하는 네임 서비스(315) 및 네트워크 연결을 위한 IP 서비스(320)에 의존하고 있다.

의존관계 관계는 이행적이라는 것을 상기하기 바란다. 즉, 주어진 컴포넌트의 디펜던트는 그 컴포넌트 자신 이외에도 그 컴포넌트의 앤티시던트(들)도 필요로 한다. 따라서, 모든 기술된 서비스는 IP 서비스(320) 및 데이터베이스 서비스(330) 이외에도, 운영 체제(OS)(325) 서비스의 존재를 필요로 한다. 간결함으로 위해, 하드웨어 컴포넌트 상에서의 OS(325)의 의존관계는 도시하지 않았지만, 기능 모델에는 이들이 존재한다.

이제 도 4를 참조하면, 블록도는 본 발명의 일 실시예에 따른 서비스의 구조적 의존관계 모델을 나타낸 것이다. 보다 구체적으로 말하면, 도 4는 도 1에 도시한 것과 같은 전자 상거래 시스템에서 여러가지 컴포넌트들 사이의 구조적 애플리케이션 의존관계 그래프를 나타낸 것이다.

이러한 구조적 의존관계 모델은 기능 모델(도 3)을 이하의 방식으로 확장시킨다. 구조적 의존관계 모델은 비지니스 서비스의 구현을 다루고 있으며 구체적인 제품 및 이들의 논리적 (모듈, 컴포넌트) 및 물리적 (파일, 공유 라이브러리) 아키텍처에 집중되어 있다. 구조적 의존관계 모델은 소프트웨어 컴포넌트들에 대한 상세한 설명, 즉 시스템 인벤토리를 포착하는 데, 이 시스템 인벤토리는 보통은 여러가지 시스템 리포지터리에 또는 잘 정의된 장소, 예를 들면 관리 자원(220)의 설정 파일(configuration file)에 기록되어 있다.

유의할 점은 구조 모델이 단일 시스템의 컴포넌트들을 다루고 있지만, 이 모델은 다른 시스템들에 의해 호스팅되는 서비스 및 애플리케이션에 대한 참조도 유지할 수 있는 데, 그 이유는 그 시스템 상에 위치하는 설정 파일들이 이러한 정보를 포함하고 있을 수 있기 때문이다. 시스템 리포지터리의 일례로는, IBM AIX 객체 데이터 관리자[Object Data Manager(ODM)], 리눅스 레드헷 패키지 관리자[Linux Red Hat Package Manager(RPM)] 또는 마이크로소프트 윈도즈 레지스트리(Microsoft Windows Registry)가 있지만, 이에 한정되는 것은 아니다. 소프트웨어 컴포넌트에 관련된 정보는 일반적으로 소프트웨어 패키지의 설치 및 배치 중에 포착된다. 그 밖에, 구조 모델은 화살표로 표시된 여러가지 시스템 컴포넌트들 사이의 의존관계를 포함하고 있다. 명확함을 위해, 비지니스 서비스의 이름은 인용 부호 없이 기재되어 있지만, 구조 모델의 엘리먼트들의 이름들은 도 4에서 인용 부호와 함께 기재되어 있다.

FQDN(Fully Qualified Domain Name: 호스트 이름과 도메인을 함께 표기한 것을 의미함) wslab8.watson.ibm.com(400)을 갖는 시스템은 이하의 컴포넌트들, 즉 스토어프런트 서블릿(410)으로서 구현되어 있는 e-비지니스 애플리케이션(기능 모델에 정의되어 있는 비지니스 서비스)을 호스팅하며, 스토어프런트 서블릿(410)은 애플리케이션의 비지니스 로직을 캡슐화하고 있다. 웹 애플리케이션 서비스는 IBM WebSphere 버전 3.5(415)에 의해 구현되어 있는 반면, 웹 서비스는 IBM HTTP 서버 버전 1.3.6(420)에 의해 실현되고 있다. IP 서비스는 디폴트 IP 프로토콜 스택(430)에 의해 구현되어 있고, 운영 체제(OS)는 윈도(즈) NT 버전 4(425)이다.

FQDN rslab2.watson.ibm.com(405)를 갖는 시스템은 이하의 컴포넌트들, 즉 (IBM) DB2 Universal Database(UDB) 버전 5.2(435)에 의해 구현된 데이터베이스 서비스, 및 운영 체제, 여기서는 (IBM) AIX(Advanced Interactive Executive) 버전 4.3.3(440)을 호스팅한다.

이제 도 5를 참조하면, 블록도는 본 발명의 일 실시예에 따라 기능적 의존관계 모델, 구조적 의존관계 모델 및 동작적 의존관계 모델에 의해 다루어지는 서비스 라이프사이클을 도시한 것이다. 보다 구체적으로 설명하면, 도 5는 전술한 기능 모델(500)과 구조 모델(510) 사이의 관계를 나타낸 것으로서, 제3의 의존관계 모델, 즉 동작 모델(520)을 도입한 것이다. 이들 3가지 모델은 본 발명이 이들 서비스의 전 라이프사이클 동안, 즉 설계 단계에서 설치 및 배치 단계를 거쳐 동작 즉 런타임 단계까지 이들 서비스를 추적할 수 있게 해준다.

앞서 설명한 바와 같이, 기능 모델(500)은 비지니스 서비스의 설계에 관계되어 있으며, 따라서 비지니스 시스템의 설계 시에 포착된다. 기능 모델(500)에 의해 기술된 시스템이 일단 인스턴스화되거나 배치되면(단계 505), 구조 모델(510)이 설정된다. 동작 모델(520)은 구조 모델(510)의 여러가지 컴포넌트가 인스턴스화될 때(단계 515)와 이들 컴포넌트들 사이의 런타임 바인딩이 설정될 때 생성된다. 동작 모델은 앞서 기술한 모델의 런타임시의 특성들을 표현한다. 이제부터는 전술한 개념들을 설명하는 몇가지 시나리오에 대해 기술한다.

웹 애플리케이션 서버(305)는 IBM WebSphere(415)에 의해 구현된다. WebSphere의 하나 이상의 인스턴스들을 웹스피어-대몬(545)이라고 한다. 여기에서, 웹(또는 WWW) 서비스(310)는 2개의 제품, 즉 아파치(Apache) 1.3.4(525) 및 로터스 도미노(Lotus Domino)(530)에 의해 구현된다. 이들 제품의 실행 인스턴스(running instance)는 http 대몬 "httpd"(550)에 의해 식별될 수 있다. 데이터베이스 서비스(330)는 2개의 제품, 즉 오라클 v7(535) 및 DB2 UDB(435)에 의해 구현되지만, 오라클 v7(535)의 어떤 인스턴스도 액티브가 아닌 데, 그 이유는 어떤 서버 프로세스도 동작 모델(520)에서는 볼 수 없기 때문이다. 이와 반대로, 동작 모델(520)에 4개의 DB2 대몬 "db2d"(555)이 존재하는 것으로부터 알 수 있는 바와 같이, DB2 UDB(435)의 4개의 인스턴스가 실행되고 있다. 네임 서비스(315)는 BIND 버전 5.6(540)에 의해 구현된다. BIND의 실행 인스턴스는 동작 모델(520)에서 "named"(560)로서 관찰될 수 있다.

유의할 점은 의존관계가 기능 모델에서 구조 모델 및 동작 모델로 전파된다는 것이다. 이것이 필요한 이유는 실행 애플리케이션 인스턴스가 제대로 기능하기 위해 어떤 다른 애플리케이션 인스턴스(들)을 필요로 하는지를 그 실행 애플리케이션 인스턴스로부터는 판별할 수 없기 때문이다.

어떤 애플리케이션 인스턴스의 수명이 짧기 때문에, 동작 모델(520)은 아주 동적이고 또 아주 커질 가능성이 있다. 기능적 의존관계 모델 및 구조적 의존관계 모델과는 달리, 동작 모델(520)은 리포지터리 또는 데이터베이스에 저장되지 않지만, 요구가 있을 시에 필요한 범위까지 계산된다.

이제 도 6을 참조하면, 블록도는 본 발명의 일 실시예에 따른 기능적 의존관계 모델, 구조적 의존관계 모델 및 동작적 의존관계 모델 사이의 관계를 나타낸 것이다. 보다 구체적으로 설명하면, 도 6은 일례로서 3가지 의존관계 모델에 사용되는 데이터 템플릿의 세부 사항 및 이들 모델을 서로 연결시키는 수단을 나타낸 것이다. 이 일례는 네임 서비스의 라이프사이클 동안에 그 네임 서비스를 기술하기 위한 템플릿 및 그와 관련된 값들을 상세히 나타내고 있다.

기능 모델(500)에 사용되는 기능 템플릿(605)은 "호스트 이름(hostName)"(그 서비스를 호스팅하는 컴퓨터 시스템의 고유 이름), "서비스 이름(serviceName)"(서비스의 이름) 및 "컴포넌트 타입(componentType)"(이 서비스가 기능하는 역할, 즉 클라이언트 또는 서버)를 포함하고 있다. 이러한 정보가 있으면, 서비스는 분산 환경 내에서 일의적으로 식별될 수 있다. 그렇지만, 설명 데이터(이 서비스의 목적, 이 서비스에 가입하는 고객에 대한 설명 등)를 갖는 추가의 필드가 본 발명의 정신을 벗어나지 않고 부가될 수 있다. 마지막으로, "앤티시던트(Antecedent)" 필드는 이 서비스가 제대로 기능하기 위해 필요로 하는 서비스(들)을 포함하고 있다.

구조 모델(510)에 사용되는 구조 템플릿(610)은 기능 템플릿(605)의 필드들 모두를 포함하고 있으며, 이에 따라 기능 모델(500)로부터 구조 모델(510)까지 및 그 역으로 순회하기 위해 기능 템플릿(605)을 구조 템플릿(610)에 링크시킬 수 있게 된다. 그 밖에, 구조 템플릿(610)은 "컴포넌트 이름(componentName)"(제품 컴포넌트의 이름), "식별자(identifier)"(그 컴포넌트를 식별하기 위한 글로벌 고유 이름), "버전(version)", "릴리스(release)", 및 "수정(modification)" (예를 들어, 유지 보수 또는 패치/정정 레벨) 번호, "설치 상태(installState)" (컴포넌트 가 성공적으로 또 완전히 설치되었는지를 나타냄) 및 "프로세스 이름(processName)" (런타임시에 이 제품 컴포넌트를 식별하는 프로세스(들)의 이름)을 포함하고 있다. 게다가, "앤티시던트(Antecedent)" 필드는 이 컴포넌트가 동작가능하게 되는 데 필요한 컴포넌트(들)를 열거하고 있다.

동작 모델(520)에 사용되는 동작 템플릿(615)은 필드 "호스트 이름(hostName)" (그 서비스를 호스팅하는 컴퓨터 시스템의 고유 이름) 및 "프로세스 이름(processName)" (런타임 시에 제품 컴포넌트를 식별하는 프로세스(들)의 이름)을 포함하고 있다. 이들 2개의 필드는 구조 모델(510)로부터 동작 모델(520)까지 및 그 역으로 순회하기 위해 구조 템플릿(610)을 동작 템플릿(615)과 링크시킨다. 그 밖에, 동작 템플릿(615)은 필드 "동작 상태(operState)" (프로세스의 동작 상태, 즉 실행, 인터럽트, 좀비(zombie) 등), "포트 번호(portNumber)" (애플리케이션이 그를 통해 프로세서에 연결될 수 있는 TCP/UDP 포트의 번호) 및 "인스턴스 ID(instanceID)" (컴퓨터 시스템의 범위 내에 있는 여러가지 애플리케이션 인스턴스들을 구별하기 위한 것임)을 포함한다.

3가지 의존관계 모델은 최대의 효율성을 달성하기 위해 서로 다른 장소에 저장 및 계산된다. 기능 모델(500)은 수집되어, 관리 시스템(620), 즉 관리자(100)가 분산 환경과 상호작용하는 데 사용하는 중앙 제어점에 저장된다. 이러한 선택을 한 이유의 몇가지는 다음과 같다. 도 3 및 도 5의 설명에서 알 수 있는 바와 같이, 기능 모델(500)은 꽤 콤팩트한 데, 그 이유는 가능한 비지니스 서비스량이 제한되어 있기 때문이다. 게다가, 기능 모델은 그다지 빈번히 변경되지도 않는다. 기능 모델은 고객에 비지니스 서비스가 제공되는 때에 정의되고, 서비스 제공 기간이 종료될 때까지 변하지 않은 채 있다. 관리자(100)는 기능 모델(500)의 설정 및 갱신을 맡고 있기 때문에, 그것을 관리 시스템(620)에 가까운 곳에 있게 하는 것은 자연스런 선택이다.

도 4 및 도 5의 설명에서 언급한 바와 같이, 이와 달리 구조 모델(510)은 보통은 여러가지 시스템 리포지터리 또는 잘 정의된 장소, 예를 들면 관리 자원(220)의 설정 파일에 기록되어 있는 소프트웨어 컴포넌트에 대한 상세한 설명, 시스템 인벤토리를 포착한다. 그 결과, 구조 모델은 크기가 클 뿐만 아니라(시스템 리포지터리의 내용은 몇백 킬로바이트 내지 최대 수 기가바이트까지 되는 경향이 있음) 변경도 빈번하게 일어난다. 따라서, 시스템의 구조 모델(510)을 관리 자원(220) 자체에 유지시키게 되면 모델을 갱신하기 위한 통신 오버헤드가 없어질 뿐만 아니라 모든 관리 자원(220)의 구조 모델(510)이 집중된 한 장소에 저장되는 경우에 일어나게 되는 엄청난 분량의 스토리지의 필요성도 없어지게 된다.

동작 모델(520)이 도 5에서는 아주 동적이며, 또한 분산 환경의 컴퓨터 시스템들에 존재하는 모든 애플리케이션의 다수일 가능성이 있는 인스턴스들 및 이들 사이의 의존관계 관계를 커버하기 때문에 극히 큰 것으로 설명하였다. 인터넷/애플리케이션/스토리지 서비스 제공업자 및 아웃소서(outsourcer)의 오늘날의 데이터 센터가 수천개의 컴퓨터 시스템으로 이루어져 있고 그 각각이 100개에 가까운 애플리케이션 및 시스템 서비스를 호스팅한다고 할 때, 현재 인스턴스화된 애플리케이션 및 그들의 의존관계 모두로 이루어진 동작 모델은 실현불가능하다. 따라서, 실현가능한 방법은 요구가 있을 시에 동작 모델의 관련 일부를 계산하는 것이다(단계 625). 이것이 도 7에서 그 기능에 대해 상세히 설명하는 의존관계 서비스(245)의 목적이다.

이제 도 7을 참조하면, 블록도는 본 발명의 일 실시예에 따른 엔드-투-엔드 의존관계를 계산하는 데 관여하는 컴포넌트들을 설명하는 것이다. 보다 구체적으로 설명하면, 도 7은 질의를 하고 엔드-투-엔드 의존관계를 계산하는 데 사용되는 여러가지 컴포넌트들 사이의 데이터 흐름을 나타낸 것이다. 관리 자원(220)은 그의 시스템 인벤토리의 XML(Extensible Markup Language; 확장형 마크업 언어) 기술, 설정 파일 및 그의 여러가지 의존관계를 제공할 수 있는 것으로 가정한다. 그렇지만, 유의해야 할 점은 본 발명에 따라 어떤 데이터 기술 포맷(data description format)도 사용될 수 있다는 것이다. 이 정보를 획득할 수 있는 방법에 대한 세부 사항은 다음과 같다.

한가지 간편한 방법은 시스템과 그의 애플리케이션 및 서비스 내에 적절한 도구화를 제공하는 것이다. 이러한 정보는 플랫 XML 파일(flat XML file)(740)에 기술되어, 웹 서버(725)를 통해 시스템의 다른 컴포넌트들이 이용가능하게 되어 있다.

다른 대안에서는, 의존관계 서비스(245)는 적절한 서비스 의존관계 정보를 발생하기 위해 시스템 리포지터리(745)에 저장되어 있는 정보를 이용한다. 이 정보는 웹 서버(730)를 통해 시스템의 다른 컴포넌트들에도 이용가능하게 된다.

셋째, 관리 자원(220)은 DMTF(Distrubuted Management Task Force)에 의해 제안된 CIM 객체 관리자(CIM Object Manager, CIMOM)(735)와 상호 작용하는 CIM 제공자(750)라고 하는 도구화 에이전트(instrumentation agent)를 사용하여 그의 정보를 노출시킨다. 그러면, CIMOM은 필요한 정보를 관심 컴포넌트들에 공개시킨다.

도 7의 중앙부에는, 서비스 계층(205)의 일부인 여러가지 관리 서비스가 도시되어 있다. 이들에는, 네임 서비스(700), 트레이더 서비스(710), 이벤트 서비스(715) 및 의존관계 서비스(245)가 있다. 의존관계 서비스(245)는 통신 프로토콜[예를 들어, 자바 RMI(Remote Method Invocation)]을 사용하여 그의 관리 시스템 또는 애플리케이션 계층(200)에 위치하는 임의의 관리 애플리케이션을 통한 관리자(100)의 질의에 의해 트리거되어, 그 질의를 처리하고 그 결과를 다시 관리자(100)에게 보낸다. 의존관계 서비스(245)의 주요 임무는 다음과 같다.

(a) 관리 시스템 또는 애플리케이션 계층(200)에 위치하는 임의의 관리 애플리케이션과의 상호 작용하는 것. 관리 시스템은 의존관계 서비스(245)의 API(애플리케이션 프로그래밍 인터페이스)에 질의를 내보낸다.

(b) 서비스의 식별자를 수신할 때,

(i) 그의 직접 앤티시던트, 즉 그 서비스를 대표하는 노드 아래 첫번째 레벨에 대한 설명, 또는

(ii) 그 서비스를 대표하는 노드 아래의 전체 서브그래프, 또는

(iii) 의존관계 그래프의 임의의 서브세트(주어진 노드 아래의 레벨 m 내지 레벨 n)을 반환하는 "드릴-다운"(drill-down) 방법을 공개하는 것.

(c) 그 서비스의 디펜던트를 목표로 향해가는, 동일한 도구를 갖는 "드릴-업(drill-up)" 방법을 제공하는 것.

(d) 관리되는 객체들의 클래스 및 프로퍼티(property)에 대한 정보를 수집 및 필터링하는 부가의 방법이 존재하는 것.

(e) http(HyperText Transport Protocol; 하이퍼텍스트 전송 프로토콜)을 통해 질의를 발함으로써 관리되는 자원(220)으로부터 의존관계 정보를 획득하여 그것에 [관리자(100)에 의해 규정된] 필터링 룰을 적용하는 것.

(f) XML 문서로서 관리 시스템으로 다시 보내온 정보를 데이터 구조에 결합시키는 것.

전술한 바와 같이, 본 발명은 그의 완전 분산 특성(fully distributed nature)으로 인해 모든 관여된 시스템에 걸리는 부하를 가능한 한 낮게 유지시키는 것을 목적으로 한다. 본 발명은 관리 시스템을 관리 자원(220)과 분리시켜, 시간 소비적인 필터링 및 결합 동작(filter and join operation)을 의존관계 서비스(245)에 캡슐화시키고, 이는 여러가지 시스템 상에 복제될 수 있게 된다. 따라서, 질의 동작에 대해 최대 수준의 병렬성을 달성하는 것이 가능한 데, 그 이유는 의존관계 서비스(245)의 인스턴스의 선택이 관리 시스템에 의해 유연하게 행해질 수 있기 때문이다.

다른 중요한 이점은 (아주 크고 또 고도로 동적인) 동작 모델(520)이 특정의 장소에 저장되어 있지 않고 단계별로 요구가 있을 때 계산된다는 것이다. 구조 모델(510)의 서로 다른 부분이 관리 자원(220)에 저장되어 있다. 따라서, 관리 시스템은 항상 가장 최근의 정보를 수신하지만, 정교한 캐싱 정책에 따라 여전히 자유롭게 그를 저장하게 된다.

이제 도 8을 참조하면, 블록도는 본 발명의 일 실시예에 따른 의존관계 서비스의 컴포넌트들을 나타낸 것이다. 보다 구체적으로 설명하면, 도 8은 의존관계 서비스(245)를 구현하는 컴포넌트들을 나타낸 것이다. 도시한 바와 같이, 정보 제공업자(810)는 애플리케이션 계층(200)의 관리 애플리케이션과 상호작용한다. 정보 제공업자(810)는 자바 RMI를 통해 질의(840)를 수신하고, 그 결과를 XML 문서(835)로서 다시 보낸다. 질의(840)는 (서비스 및 컴포넌트의 설명 또는 특정의 속성의 값의 검색 등) 기본적인 정보에 관계된 것이거나 또는 (의존관계 모델에 대한 드릴-업 또는 드릴-다운 동작 등) 보다 복잡한 문제를 처리하거나 할 수 있다.

자원 프록시(800)는 자원 웹 서버(725)와 인터페이싱하여 관리 자원의 XML 설명(830)을 획득하는 일을 맡고 있다. 자원 프록시(800)는 http를 통해 자원 웹 서버(725)에 질의를 보냄으로써 그 일을 행한다. 자원 프록시(800)는 XML 설명(830)의 수신 시에 그 설명을 파싱하고 (선택 및 필터링 룰 등) 질의 표현식을 그 설명에 적용하여 그 결과를 질의 리졸버(805)로 보낸다.

질의 리졸버(805)의 임무는 주어진 호스트 이름에 대해 어느 자원 프록시(800)가 그 요청에 서비스할 수 있는지를 찾아내기 위한 맵을 보유하여 이 요청을 적절한 자원 프록시(800)로 보내는 것이다.

엘리먼트 URI 리졸버(815)는 주어진 호스트 이름에 대한 URI(Uniform Resource Identifier)를 작성하여 그 결과를 다시 정보 제공업자(810) 또는 질의 리졸버(805) 중 어느 하나일 수 있는 호출자(invoker)에게 전달하는 일을 맡고 있다.

XML 서브클래스 리졸버(820)는 XML 스키마(825) 내에 정의되어 있는 타입 체계에 따라 특정 타입의 엘리먼트의 위치를 찾아내는 일을 맡고 있는 헬퍼 모듈이다. 이것의 일례로는, (웹 애플리케이션 서비스, 웹 서비스, 또는 네임 서비스 등) "서비스" 타입을 가지거나 (서비스 및 의존관계가 위치하고 있는 호스트) "호스트" 타입을 가지거나 또는 "의존관계" 타입을 갖는 하나 이상의 XML 문서 내의 모든 엘리먼트에 질의를 하는 것이 있다.

이제 도 9를 참조하면, 흐름도는 본 발명의 일 실시예에 따라 의존관계 서비스[예를 들면, 의존관계 서비스(245)]를 호출하고 그 결과를 수집하는 동작 단계들을 나타낸 것이다. 이 방법은 관리자(100)에 의하거나 또는 도 2a에 도시한 바와 같이 애플리케이션 계층(200)의 일부인 관리 애플리케이션에 의해 개시된다.

이 방법은 블록(900)에서 시작하여 다음과 같이 진행한다. 먼저, 비지니스 서비스가 일반적으로는 기능 모델로부터 선택되는 데(단계 905), 그 이유는 관리자는 분산 시스템에 의해 제공되는 비지니스 서비스에 관심이 있기 때문이다. 구조 모델은 비지니스 서비스의 선택 시에 비지니스 서비스의 프로비저닝에 관여하고 있는 선정된 호스트들을 제공하도록 질의를 받는다. 이것은 분산 시스템의 모든 호스트에 존재하는 구조 모델의 위치를 알아내거나 또는 (효율의 목적상) 관리 시스템에 저장되어 있고 또 분산 시스템에 존재하는 서비스들과 호스트들 사이의 매핑을 포함하고 있는 (주기적으로 갱신되는) 서비스/호스트 룩업 테이블에 질의를 함 으로써 행해질 수 있다. 그러면 관리자는 그의 임의대로 하나의 호스트를 선택한다(단계 910).

그 밖에, 관리자는 질의를 작성한다(단계 915). 질의 파라미터의 일례로는, 순회의 방향(서비스 디펜던트쪽으로나 또는 그의 앤티시던트쪽으로), 순회의 깊이(예를 들어, 단지 중간의 앤티시던트/디펜던트; 가능한 전체적인 앤티시던트/디펜던트, 즉 동작 모델의 완전 이행적 폐포(complete transtive closure); 동작 모델의 m-번째 계층과 n-번째 계층 사이에서만), 속성의 존재나 그들의 값에 관계된 필터링 조건이 있지만, 이에 한정되는 것은 아니다.

서비스를 선택하는 단계(단계 905), 호스트를 선택하는 단계(910) 및 질의를 작성하기 위한 옵션을 선택하는 단계의 순서가 여기서는 지정되어 있다는 사실이 [종래 기술의 "호스트-중심적인(host-centric)" 방법에 대해] 본 발명의 "서비스 중심적인(service-centric)" 방법을 강조하고 있다. 그렇지만, 당업자라면 본 발명의 정신 및 범위를 벗어나지 않고 단계들(단계 905, 단계 910 및 단계 915)의 순서를 변경할 수 있다는 것을 잘 알 것이다.

이러한 변형례의 일례로는, 사용자에게 (예를 들면, 그래픽 유저 인터페이스를 통해) 선택 프로세스의 3가지 단계를 임의의 순서로 수행할 선택권을 제공하는 것과, 먼저 호스트를 선택하고 그 다음에 그 호스트에 존재하는 서비스를 탐색할 수 있게 함으로써 선택에 가능한 서비스 후보를 제한하는 것이 있다.

서비스 및 호스트 선택과 질의의 작성이 있은 후에, 이들 파라미터를 사용하여 의존관계 서비스가 호출된다(단계 920). 유의할 점은 호출의 모드가 동기식(즉, 의존관계 서비스에 의해 그 결과가 반환될 때까지 호출자를 차단함)이거나 비동기식(따라서 호출자는 계산 도중에 부가의 작업들을 수행할 수 있음)일 수 있다는 것이다.

의존관계 서비스는 동작 모델의 적절한 부분을 계산하고, 호출의 모드에 따라 그 결과를 다시 호출자에게 보내거나 또는 호출자에게 그 결과가 이용가능하다고 통지하거나 한다. 그러면 호출자는 그 결과를 수집하여(단계 925) 이들을 추가적으로 처리한다. 이 방법은 블록(930)에서 종료한다.

이제 도 10을 참조하면, 흐름도는 본 발명의 일 실시예에 따라 기능 의존관계 모델의 생성 및 갱신을 위한 관리자의 작업을 나타낸 것이다. 이것은 새로운 (비지니스) 서비스가 배치되고 제공되는 경우나 또는 기존의 모델에 변경이 가해지는 경우나 또는 기존의 (비지니스) 서비스가 그 제공을 중단하는 경우에 필요한 것이다.

이 방법은 블록(1000)에서 시작하고 다음과 같이 진행한다. 관리자 또는 관리 애플리케이션은 새로운 비지니스 서비스가 부가되어야 하는지 또는 기존의 서비스가 삭제되어야 하는지를 평가한다(단계 1005). 이것이 필요하지 않은 경우, 이 방법은 블록(1025)으로 바로 진행한다. 그렇지 않은 경우, 단계(1010)에서, 서비스 및 그의 설명이 도 6에서 설명되었던 기능 모델의 템플릿(605)에 입력된다(또는 그로부터 제거된다).

그 다음에, 단계(1015)에서, 서비스 의존관계, 즉 그의 앤티시던트에 관한 그의 관계가 기능 모델의 템플릿(605)에 부가될 필요가 있다(또는 그로부터 제거될 필요가 있다). 삭제의 경우에, 유의할 점은 서비스 디펜던트로부터의 의존관계는 제거될 서비스의 앤티시던트를 가리키도록 조정될 필요가 있다는 것이다. 이것은 앤티시던트의 의존관계 내에 종국적으로 중복된 설명에 대한 검사를 수반할 수 있다. 마지막으로, 갱신된 기능 모델은 관리 시스템의 리포지터리에 저장된다(단계 1020). 이 방법은 블록(1025)에서 종료한다.

이제 도 11을 참조하면, 흐름도는 본 발명의 일 실시예에 따라 컴퓨터 시스템 상의 하드웨어/소프트웨어 컴포넌트를 설치 또는 제거함으로써 구조 의존관계 모델을 갱신하는 단계들을 나타낸 것이다. 이것은 새로운 컴포넌트가 배치되어 호스트 상에 설치되는 경우나 또는 기존의 컴포넌트가 그 호스트로부터 제거되는 경우에 필요한 것이다.

이 방법은 블록(1100)에서 시작하고 다음과 같이 진행한다. 새로운 하드웨어 컴포넌트가 설치/제거되는 경우, 그의 의존관계의 확인 및 조정은 보통은 운영 체제에 의해 수행되며 따라서 여기에서는 더 이상 설명하지는 않는다. 그 대신에, 이하의 설명에서는 소프트웨어 컴포넌트를 부가/제거하는 작업에 대해 집중하기로 한다. 소프트웨어 분배 및 설치를 수행하는 관리자 또는 관리 애플리케이션은 새로운 소프트웨어 컴포넌트가 부가되어야 하는지 기존의 소프트웨어 컴포넌트가 삭제되어야 하는지를 평가한다(단계 1105). 이것이 필요하지 않은 경우, 이 방법은 블록(1125)으로 바로 진행한다. 그렇지 않은 경우, 단계(1110)에서, 소프트웨어 컴포넌트의 설명이 도 6에서 설명하였던 구조 모델의 템플릿(610)에 입력된다(또는 그로부터 제거된다). 그 다음에, 단계(1115)에서, 소프트웨어 컴포넌트의 의존관 계, 즉 그의 앤티시던트에 관한 그의 관계가 구조 모델의 템플릿(610)에 부가될 필요가 있다(또는 그로부터 제거될 필요가 있다).

삭제의 경우에, 유의할 점은 소프트웨어 컴포넌트의 디펜던트로부터의 의존관계는 제거될 소프트웨어 컴포넌트의 앤티시던트를 가리키도록 조정될 필요가 있다. 이것은 앤티시던트의 의존관계 내의 종국적으로 중복되는 설명에 대한 검사를 수반할 수 있다. 마지막으로, 갱신된 구조 모델은 호스트의 자원 의존관계 리포지터리에 저장된다(단계 1120). 이 방법은 블록(1125)에서 종료한다.

이제 도 12를 참조하면, 흐름도는 본 발명의 일 실시예에 따른 동작 모델의 계산을 맡고 있는 시스템의 단계들을 나타낸 것이다. 이 방법은 블록(1200)에서 시작하고 다음과 같이 진행한다.

동작 의존관계 모델의 계산을 수행하는 시스템은 그 시스템이 실행되고 있는 호스트의 특정 포트에서 계속하여 요청이 있는지 귀를 기울이고 있으며, 이는 블록(1205)을 그 자신과 연결시키는 루프에 의해 표시되어 있다. 이것은 애플리케이션에 의해 언제라도 호출될 수 있는 서비스를 구현하는 서버 프로세스("대몬")의 표준적인 거동이다.

시스템은 요청의 수신 시에 그 요청으로부터 입력 파라미터를 추출한다(단계 1210). 도 9의 설명에서 언급한 바와 같이, 입력 파라미터의 일례로는 문제의 서비스 및 호스트의 이름, 순회의 방향, 순회의 깊이, 속성의 존재나 또는 그의 값에 관련된 필터링 조건이 있지만, 이에 한정되는 것은 아니다. 그 다음에, 이들 입력 파라미터는 동작 모델의 실제 계산을 수행하는 데 사용된다(단계 1215).

그 다음에, 계산의 결과, 즉 동작 모델은 호출 시에 규정된 호출의 모드에 따라 호출을 한 애플리케이션에 전달된다(단계 1220). 이 단계 이후에, 시스템이 실행되고 있는 호스트의 임의의 할당된 자원은 해제(release)된다(단계 1225). 호스트 자원의 일례로는, 메모리, 디스크 공간 또는 CPU 레지스터가 있지만, 이에 한정되는 것은 아니다. 마지막으로, 시스템은 그의 초기 단계로 다시 돌아와서 후속하여 들어오는 요청들이 있는지 귀를 기울이게 된다(단계 1205).

이제 도 13을 참조하면, 흐름도는 본 발명의 일 실시예에 따른 지정된 호스트 상에 위치하는 서비스의 직접 앤티시던트(direct antecedent)를 검색하는 단계들을 나타낸 것이다. 이 방법은 블록(1300)에서 시작하며, 다음과 같이 진행된다.

먼저, 목표로 삼은 서비스 및 호스트의 이름이 얻어진다(단계 1305). 이들 파라미터는 호출을 한 관리 애플리케이션에 의해 제공되며, 이들 파라미터는 관리자로부터 직접 또는 관리 콘솔에 도착하는 이벤트 메시지로부터 얻어진다. 그 다음에, 서비스 설명을 포함하는 엘리먼트는 지정된 호스트의 구조 모델에 위치한다(단계 1310).

그 다음에, 도 6에 도시한 바와 같은, 주어진 서비스의 구조 템플릿(610)의 앤티시던트 프로퍼티(antecedent property)의 평가(단계 1315)는 이 서비스가 어떤 앤티시던트를 갖는지 여부를 밝혀준다. 앤티시던트 프로퍼티가 비어있는 경우, 즉 그 엘리먼트가 앤티시던트를 갖지 않는 경우, 서비스 엘리먼트 자체가 동작 모델에 부가된다(단계 1320). 호출을 한 관리 애플리케이션은 이것을 서비스가 그 자신에게만 의존하고 있는 것으로 해석한다. 이 방법은 그 다음에 바로 블록(1340)으로 진행한다.

그렇지만, 앤티시던트 프로퍼티가 하나 이상의 엘리먼트를 포함하고 있는 경우, 그 서비스는 앤티시던트를 갖는다. 따라서, 이 방법은 블록(1325)으로 진행하여, 그 서비스 엘리먼트를 동작 모델에 부가한다. 그 밖에, 의존관계 엘리먼트는 동작 모델에 부가된다(단계 1330). 의존관계 엘리먼트의 범위 내에서, 구조 템플릿(610)의 앤티시던트 프로퍼티의 내용을 동작 모델 내로 의존관계 엘리먼트 바로 다음에 복사함으로써 (하나 이상의) 앤티시던트 엘리먼트의 리스트가 부가된다(단계 1335). 이러한 구현의 일반적인 일례는 의존관계 엘리먼트를 XML 태그로서 정의하고, 앤티시던트의 리스트를 부가한 다음에 XML 태그를 닫는 것이다. 이 방법은 동작 모델의 내용을 호출자에게 보냄으로써 블록(1340)에서 종료한다.

이제 도 14를 참조하면, 흐름도는 본 발명의 일 실시예에 따른 지정된 호스트 상에 위치하는 서비스의 앤티시던트를 반복적으로 검색하는 단계들을 나타낸 것이다. 보다 구체적으로 설명하면, 도 14는 지정된 호스트 상에 위치하는 서비스의 모든 (즉, 직접 또는 간접) 앤티시던트를 반복적으로 검색함에 있어서 깊이-우선 전략(depth-first strategy)의 사용을 나타낸 것이다. 유의할 점은 예를 들어 클라이언트/서버 바인딩(client/server binding)이 다른 시스템을 가리키고 있는 경우에, 반복적인 질의가 시스템 또는 심지어는 제공업자 경계를 확장시킬 수 있다는 것이다.

이 방법은 블록(1400)에 시작하여 다음과 같이 진행한다. 먼저, 목표로 삼은 서비스 및 호스트의 이름이 얻어진다(단계 1405). 이들 파라미터는 호출을 한 관리 애플리케이션, 즉 API 함수에 의해 제공되며, 이에 따라 이들 파라미터를 관리자로부터 직접 또는 관리 콘솔에 도착하는 이벤트 메시지로부터 얻게 된다.

그 다음에, 서비스 설명을 포함하는 엘리먼트는 지정된 호스트의 구조 모델에 위치하게 되고 서비스 리스트에 입력된다(단계 1410). 이 단계를 완료한 후에, 서비스 리스트가 비었는지 여부가 평가된다(단계 1415). 서비스 리스트가 엘리먼트를 포함하고 있는 경우, 그 리스트의 첫번째 엘리먼트가 선택되어, 그 모델에 부가되고(단계 1420) 그 리스트로부터 삭제된다.

도 6에 도시한 바와 같은 주어진 서비스의 구조 템플릿(610)의 앤티시던트 프로퍼티의 평가는 이 서비스가 어떤 앤티시던트라도 갖는지 여부를 밝혀준다. 그 다음에, 앤티시던트 프로퍼티에 열거된 엘리먼트들은 비어 있을 수 있는 별도의 리스트, 즉 앤티시던트 리스트에 집어넣게 된다(단계 1425).

그 다음에 이 방법은 블록(1430)으로 바로 진행하여, 앤티시던트 리스트가 어떤 엘리먼트라도 포함하고 있는지 여부를 평가한다. 앤티시던트 리스트가 비어있는 경우(즉, 서비스가 어떤 추가의 앤티시던트도 갖지 않는 경우), 이 방법은 다시 블록(1415)으로 진행하여 서비스 리스트가 존재하는 경우 그 리스트 내의 그 다음 엔트리부터 계속한다.

그렇지만, 앤티시던트 리스트가 하나 이상의 엘리먼트를 포함하고 있는 경우, 서비스는 앤티시던트를 갖는다. 이와 같이, 이 방법은 블록(1435)으로 진행하여, 앤티시던트 리스트로부터 앤티시던트 서비스를 제거하고 그래프 구조의 깊이-우선 순회(depth-first traversal)가 가능하도록 하기 위해 이를 그 서비스 리스트 의 시작 부분에 삽입시킨다. 게다가, 앤티시던트 (및 실제 의존관계를 나타내는 링크)가 동작 모델에 부가된다(단계 1440). 본 방법의 이 부분은 앤티시던트 리스트가 비게 될 때까지 실행된다. 리스트가 비게 되면, 본 방법은 블록(1415)으로 진행하여 (궁극적으로 확장된) 서비스 리스트로 시작하게 된다. 본 방법은 동작 모델의 내용을 호출자에게 보냄으로써 서비스 리스트가 비게 되면 종료한다(단계 1445).

이제 도 15를 참조하면, 흐름도는 본 발명의 일 실시예에 따른 지정된 호스트상에 위치한 서비스의 직접 디펜던트를 검색하는 단계들을 나타낸 것이다. 본 방법은 블록(1500)에서 시작하여 다음과 같이 진행한다.

먼저, 목표로 삼은 서비스 이름과 호스트 이름이 얻어진다(단계 1505). 이들 파라미터는 호출을 한 관리 애플리케이션에 의해 제공되며, 이 관리 애플리케이션은 이들 파라미터를 관리자로부터 직접 또는 관리 콘솔에 도착하는 이벤트 메시지로부터 얻게 된다. 그 다음에, 서비스 설명을 포함하는 엘리먼트는 지정된 호스트의 구조 모델에 위치시킨다(단계 1510).

그 다음에, 그의 앤티시던트가 타겟 서비스 엘리먼트인 엘리먼트들 모두를 검색해보면 이 서비스가 어떤 디펜던트를 갖는지 여부가 밝혀진다. 그 결과 비어 있는 경우(단계 1515), 즉 그 엘리먼트가 디펜던트를 갖지 않는 경우, 그 서비스 엘리먼트 자체는 동작 모델에 부가된다(단계 1520). 호출을 한 관리 애플리케이션은 이것을 어떤 서비스가 자신에만 의존하고 있는 것으로 해석한다. 그러면, 본 방법은 블록(1540)으로 바로 진행한다.

그렇지만, 그의 앤티시던트가 타겟 서비스 엘리먼트인 엘리먼트들을 모두 검색해보니 하나 이상의 엘리먼트가 나오는 경우, 그 서비스는 디펜던트를 갖는다. 따라서, 본 방법은 블록(1525)으로 진행하여, 그 서비스 엘리먼트를 동작 모델에 부가시킨다. 그 밖에도, 의존관계 엘리먼트가 동작 모델에 부가된다(단계 1530). 의존관계 엘리먼트의 범위 내에, (하나 이상의) 의존관계 엘리먼트가 동작 모델에서 의존관계 엘리먼트 바로 다음에 부가된다(단계 1535). 이러한 구현예의 전형적인 일례가 의존관계 엘리먼트를 XML 태그로서 정의하고, 디펜던트의 리스트를 부가한 다음에 XML 태그를 닫는 것이다. 본 방법은 동작 모델의 내용을 호출자에게 보냄으로써 블록(1540)에서 종료한다.

이제 도 16을 참조하면, 흐름도는 본 발명의 일 실시예에 따라 지정된 호스트 상에 위치하는 서비스의 디펜던트를 반복적으로 검색하는 단계들을 나타낸 것이다. 보다 구체적으로 설명하면, 도 16은 지정된 호스트 상에 위치하는 서비스의 모든 (즉, 직접 또는 간접) 디펜던트를 반복적으로 검색함에 있어서 깊이-우선 전략을 사용하는 것을 나타낸 것이다. 유의할 점은 예를 들면 클라이언트/서버 바인딩이 다른 시스템을 가리키고 있는 경우, 반복적인 질의가 시스템 또는 심지어 제공업자 경계를 확장시킬 수 있다는 것이다.

본 방법은 블록(1600)에서 시작하여 다음과 같이 진행된다. 먼저, 목표로 삼은 서비스 이름과 호스트 이름이 얻어진다(단계 1605). 이들 파라미터는 호출을 한 관리 애플리케이션 또는 API 함수에 의해 제공되며, 이 애플리케이션 또는 함수는 이들 파라미터를 관리자로부터 직접 또는 관리 콘솔에 도착하는 이벤트 메시지 로부터 획득한다. 그 다음에, 서비스 설명을 포함하는 엘리먼트는 지정된 호스트의 구조 모델에 위치시키고 서비스 리스트에 입력된다(단계 1610).

단계(1610)의 완료 후에, 서비스 리스트가 비어 있는지가 평가된다(단계 1615). 서비스 리스트가 엘리먼트를 포함하고 있는 경우, 그 리스트의 첫번째 엘리먼트가 선택되어 모델에 부가되고(단계 1620) 리스트로부터는 삭제된다. 도 6에서 설명한 바와 같이 서비스 리스트의 현재의 엘리먼트의 존재에 대하여 앤티시던트 프로퍼티를 평가해보면 이 서비스가 어떤 디펜던트를 갖는지가 밝혀지게 된다.

그 다음에, 문제의 서비스가 앤티시던트 프로퍼티에 나타나는 엘리먼트의 서비스 이름이 비어 있을 수 있는 별도의 리스트, 즉 디펜던트 리스트에 넣어진다(단계 1625). 다른 대안에서는, 구조 템플릿(610)이 디펜던트 프로퍼티를 포함하고 있는 경우(즉, 의존관계가 양방향 링크로 표현되는 경우), 디펜던트 프로퍼티의 내용이 디펜던트 리스트에 복사된다.

그 다음에, 본 방법은 바로 블록(1630)으로 진행하여, 디펜던트 리스트가 어떤 엘리먼트를 포함하고 있는지를 평가한다. 디펜던트 리스트가 비어 있는 경우(즉, 서비스가 어떤 추가의 디펜던트도 가지고 있지 않은 경우), 본 방법은 다시 블록(1615)으로 진행하고, 서비스 리스트에 그 다음 엔트리가 존재하는 경우 그 엔트리부터 계속한다.

그렇지만, 디펜던트 리스트가 하나 이상의 엘리먼트를 포함하고 있는 경우, 그 서비스는 디펜던트를 갖는다. 따라서, 본 방법은 블록(1635)으로 진행하여, 그래프 구조의 깊이-우선 순회가 가능하도록 하기 위해 디펜던트 서비스를 디펜던트 리스트로부터 제거하고 그 서비스를 서비스 리스트의 시작 부분에 삽입시킨다. 게다가, 디펜던트(및 실제의 의존관계를 나타내는 링크)가 동작 모델에 부가된다(단계 1640). 본 방법의 이 부분은 디펜던트 리스트가 비게 될 때까지 실행된다. 비게 되는 경우, 본 방법은 블록(1615)으로 진행하여 (궁극적으로는 확장된) 서비스 리스트로 시작한다. 본 방법은 동작 모델의 내용을 호출자로 보냄으로써 서비스 리스트가 비게 되면 종료한다(블록 1645).

이제 도 17을 참조하면, 본 발명의 일 실시예에 따른 의존관계 서비스 API(애플리케이션 프로그래밍 인터페이스)의 일례들이 도시되어 있다. 이 표는 주어진 서비스 및 호스트 이름에 대해 적절한 동작 모델을 생성, 전송 및 그의 수신을 요청할 수 있는 기본적인 API를 포함하고 있다. 당업자라면, API가 API에 의해 사용되는 특성들(함수 설명에 열거되어 있음)을 식별하기 위해 하나 이상의 파라미터(도시 생략)를 사용할 수 있다는 것을 잘 알 것이다.

특히, "getAntecedents(파라미터)" API는 특정 호스트 상에 위치하는 서비스의 직접 앤티시던트를 검색한다. "getAntecedentsRecursive(파라미터)" API는 반복적인 "드릴-다운"을 수행한다, 즉 특정의 호스트 상에 위치하는 주어진 서비스의 앤티시던트 모두를 검색한다. "getDependents(파라미터)" API는 특정 호스트 상에 위치하는 주어진 서비스의 직접 디펜던트를 검색한다. "getDependentsRecursive(파라미터)" API는 반복적인 "드릴-업"을 수행한다, 즉 특정의 호스트 상에 위치하는 주어진 서비스의 디펜던트 모두를 검색한다. "getServiceDependencies(파라미터)" API는 특정 서비스(즉, 앤티시던트와 디펜던트 모두)에 대한 반복적인 의존관 계 모두의 리스트를 생성한다.

"getTransactionDependencies(파라미터)" API는 특정의 트랜잭션에 참가하는 하드웨어 및 소프트웨어 컴포넌트와 이들의 의존관계의 리스트를 검색한다. "getTransactionComponents(파라미터)" API는 특정의 트랜잭션에 참가하는 하드웨어 및 소프트웨어 컴포넌트의 리스트를 생성한다. "getHostDependencies(파라미터)" API는 특정의 호스트 상에 위치하고 있는 모든 서비스에 대한 모든 반복적 의존관계의 리스트를 생성한다. "getHostComponents(파라미터)" API는 특정의 호스트 상에 설치되어 있는 하드웨어 및 소프트웨어 컴포넌트의 리스트를 검색한다. "getExternalServiceDependencies(파라미터)" API는 도메인 경계를 넘어서는, 즉 다른 서비스 제공업자의 제어하에 있는 특정의 서비스(즉, 앤티시던트와 디펜던트 모두)에 대한 모든 반복적인 의존관계의 리스트를 생성한다. 마지막으로, "getReferencingDependencies(파라미터)" API는 호스트 상의 주어진 서비스에 대해 상향쪽 또 하향쪽 모두에서의 의존관계의 참조를 반환한다.

본 발명의 컴퓨팅 환경에서 정보를 관리하는 기술에 따르면, 컴퓨팅 환경의 컴포넌트와 관련된 정보가 획득된 다음에, 획득된 정보의 적어도 일부분으로부터, 그 컴퓨팅 환경의 컴포넌트들의 적어도 일부분과 관련된 하나 이상의 관계의 존재에 관한 판정이 행해짐으로써, 하나 이상의 관계의 존재에 대한 판정이 컴퓨팅 환경의 적어도 하나의 컴포넌트와 관련된 전 라이프사이클(full lifeycycle)(예를 들면, 배치, 설치 및 런타임)을 설명할 수 있다.

본 명세서에서 첨부 도면을 참조하여 본 발명의 예시적인 실시예들에 대해 설명하였지만, 본 발명이 이들 구체적인 실시예에 한정되지 않는다는 것과 당업자라면 본 발명의 범위 또는 정신을 벗어나지 않고 여러가지 다른 변경 및 변형들이 실시될 수 있다는 것을 이해해야 한다.

Claims (41)

1. 컴퓨팅 환경에서 정보를 관리하는, 컴퓨터에 기반한 방법에 있어서,

   상기 컴퓨팅 환경의 컴포넌트들과 관련된 정보를 획득하는 단계 및

   상기 획득된 정보의 적어도 일부로부터, 상기 컴퓨팅 환경의 컴포넌트들의 적어도 일부와 관련된 하나 이상의 관계의 존재를 판정하는 단계를 포함하며,

   상기 하나 이상의 관계의 존재를 판정하는 단계는 상기 컴퓨팅 환경의 적어도 하나의 컴포넌트와 관련된 전체 라이프사이클을 설명할 수 있는 것인 정보 관리 방법.
2. 제1항에 있어서, 상기 컴퓨팅 환경은 분산 컴퓨팅 환경을 포함하는 것인 정보 관리 방법.
3. 제1항에 있어서, 상기 컴퓨팅 환경은 자율 컴퓨팅 환경을 포함하는 것인 정보 관리 방법.
4. 제1항에 있어서, 상기 컴퓨팅 환경의 컴포넌트들의 적어도 일부와 관련된 하나 이상의 관계의 존재를 판정하는 단계는, 또한 상기 컴퓨팅 환경의 적어도 2개의 컴포넌트들과 관련된 이질성(heterogeneity)을 설명할 수 있는 것인 정보 관리 방법.
5. 제1항에 있어서, 상기 컴퓨팅 환경의 컴포넌트들의 적어도 일부와 관련된 하나 이상의 관계의 존재를 판정하는 단계는, 또한 상기 컴퓨팅 환경과 관련된 하나 이상의 도메인에 걸쳐 있는 하나 이상의 컴포넌트들을 설명할 수 있는 것인 정보 관리 방법.
6. 제1항에 있어서, 상기 컴퓨팅 환경의 컴포넌트들의 적어도 일부와 관련된 하나 이상의 관계의 존재를 판정하는 단계는, 기능적(functional) 분류, 구조적(structural) 분류 및 동작적(operational) 분류를 포함하는 형태로 컴포넌트 의존성을 계산하는 단계를 더 포함하는 것인 정보 관리 방법.
7. 제6항에 있어서, 컴포넌트 의존성의 기능적 분류는 노드들의 그래프로서 모델링되는 기능적 엘리먼트들을 포함하며,

   하나 이상의 제1 노드들은 이 하나 이상의 제1 노드들이 의존하고 있는 하나 이상의 제2 노드들 및 이 하나 이상의 제1 노드들에 의존하고 있는 하나 이상의 제3 노드들에 링크되어 있는 것인 정보 관리 방법.
8. 제7항에 있어서, 상기 노드들은 상기 컴퓨팅 환경에서의 컴포넌트들을 나타내는 것인 정보 관리 방법.
9. 제8항에 있어서, 상기 컴포넌트들은 디펜던트(dependent)와 앤티시던트(antecedent) 중 적어도 어느 하나로서 정의되는 것인 정보 관리 방법.
10. 제9항에 있어서, 상기 노드들의 그래프는 노드들 사이의 링크들을 포함하며, 이 링크들은 의존성을 나타내는 것인 정보 관리 방법.
11. 제10항에 있어서, 상기 의존성은 디펜던트와 앤티시던트를 포함하는 일대일 관계인 것인 정보 관리 방법.
12. 제7항에 있어서, 상기 기능적 엘리먼트들은 상기 구조적 분류에서의 구조적 엘리먼트들과 링크되거나 상호참조되는 것인 정보 관리 방법.
13. 제6항에 있어서, 상기 컴포넌트 의존성의 구조적 분류는 노드들의 그래프로서 모델링되는 구조적 엘리먼트들을 포함하고,

    하나 이상의 제1 노드들은 이 하나 이상의 제1 노드들이 의존하고 있는 하나 이상의 제2 노드들 및 이 하나 이상의 제1 노드들에 의존하고 있는 하나 이상의 제3 노드들에 링크되어 있는 것인 정보 관리 방법.
14. 제13항에 있어서, 상기 구조적 엘리먼트들은 상기 컴퓨팅 환경의 컴포넌트들의 배치 양상(deployment aspect)을 정의하는 정보를 제공하는 것인 정보 관리 방법.
15. 제14항에 있어서, 상기 구조적 분류의 구조적 엘리먼트들에 관한 정보는 시스템 관리자들 및 오퍼레이터들 중 적어도 하나에 의한 배치 동작(deployment action) 동안에 하나 이상의 리포지터리(repository)에 저장되는 것인 정보 관리 방법.
16. 제15항에 있어서, 상기 구조 엘리먼트들에 관한 정보는 하나 이상의 애플리케이션 프로그래밍 인터페이스에 의해 상기 하나 이상의 시스템 리포지터리로부터 입수가능하게 되어 있는 것인 정보 관리 방법.
17. 제6항에 있어서, 상기 컴포넌트 의존성의 동작적 분류는 노드들의 그래프로서 모델링되는 동작적 엘리먼트들을 포함하며,

    하나 이상의 제1 노드들은 이 하나 이상의 제1 노드들이 의존하고 있는 하나 이상의 제2 노드들 및 이 하나 이상의 제1 노드들에 의존하고 있는 하나 이상의 제3 노드들에 링크되어 있는 것인 정보 관리 방법.
18. 제17항에 있어서, 상기 동작적 엘리먼트들은 상기 구조적 분류에서의 구조 엘리먼트들과 링크되거나 상호참조되는 것인 정보 관리 방법.
19. 제6항에 있어서, 상기 동작적 분류는 상기 구조적 분류 및 상기 기능적 분류 중 적어도 어느 하나로부터 계산되는 것인 정보 관리 방법.
20. 제6항에 있어서, 상기 컴포넌트 의존성의 분류는 그래픽 표현들로서 나타내어지는 것인 정보 관리 방법.
21. 제20항에 있어서, 상기 그래픽 표현들의 엣지들의 적어도 일부는 부가적인 자격 정보(qualifying information)가 주석으로 부가되어 있는 것인 정보 관리 방법.
22. 제20항에 있어서, 상기 그래픽 표현들은 단방향 및 양방향 중 어느 하나인 것인 정보 관리 방법.
23. 제20항에 있어서, 상기 그래픽 표현들은 방향성 비순환 그래프(directed acyclic graph) 및 방향성 순환 그래프(directed cyclic graph) 중 어느 하나인 것인 정보 관리 방법.
24. 제20항에 있어서, 그래픽 표현은 상향, 하향 및 측방 중 적어도 어느 하나로 순회(traverse) 가능하게 되어 있는 것인 정보 관리 방법.
25. 제20항에 있어서, 그래픽 표현에 의해 나타내어진 의존성 정보는 하나 이상의 애플리케이션 프로그래밍 인터페이스에 따라 액세스가능한 것인 정보 관리 방법.
26. 제6항에 있어서, 상기 분류 중 하나 이상은 계산된 이후에 지속적으로 저장되어 있는 것인 정보 관리 방법.
27. 제6항에 있어서, 상기 분류 중 하나 이상은 계산된 이후에 지속적으로 저장되어 있는 것이 아닌 정보 관리 방법.
28. 제1항에 있어서, 컴포넌트는 상기 컴퓨팅 환경과 관련이 있는 서비스, 애플리케이션, 미들웨어, 하드웨어, 장치 드라이버, 운영 체제 및 시스템 중 어느 하나인 것인 정보 관리 방법.
29. 제1항에 있어서, 상기 정보를 획득하는 단계는 하나 이상의 직접 관여된 시스템 및 하나 이상의 프록시 시스템 중 적어도 하나를 통해 정보를 입수하는 단계를 더 포함하는 것인 정보 관리 방법.
30. 제1항에 있어서, 상기 하나 이상의 관계 중 적어도 일부와 관련된 변화들의 이력(history)을 유지하는 단계를 더 포함하는 정보 관리 방법.
31. 제1항 내지 제6항 및 제28항 내지 제30항 중 어느 한 항에 의한 컴퓨팅 환경에서의 정보 관리 방법을 실행하는 적어도 하나의 프로세서와,

    상기 적어도 하나의 프로세서에 연결되어 상기 하나 이상의 판정된 관계와 관련된 정보를 저장하는 동작을 하는 메모리

    를 포함하는 정보 관리 장치.
32. 제1항 내지 제6항 및 제28항 내지 제30항 중 어느 한 항에 의한 컴퓨팅 환경에서의 정보 관리 방법을 실행하는 적어도 하나의 프로세서와,

    상기 적어도 하나의 프로세서에 연결되어 상기 하나 이상의 판정된 관계와 관련된 정보를 저장하는 동작을 하는 메모리를 포함하고,

    상기 적어도 하나의 프로세서는 또한 상기 저장된 정보의 적어도 일부를 검색하는 동작을 하는 것인 정보 관리 장치.
33. 제1항 내지 제30항 중 어느 한 항에 의한 컴퓨팅 환경에서의 정보 관리 방법을 컴퓨터에서 구현가능하게 하는 프로그램을 포함한 컴퓨터로 판독가능한 기록매체.
34. 삭제
35. 삭제
36. 삭제
37. 삭제
38. 삭제
39. 삭제
40. 삭제
41. 삭제

Images