KR20140129042A - 어플리케이션 설치 - Google Patents

Abstract

런타임 인스턴스에서 어플리케이션을 설치하는 방법은 어플리케이션을 설치하기 위한 요청을 수신하는 단계, 상기 어플리케이션에 의해서 요구된 공유 자원들을 정의하는 데이터를 액세스하는 단계, 기존의 런타임 인스턴스들에서 이미 설치된 공유 자원들을 정의하는 데이터를 액세스하는 단계, 상기 어플리케이션에 의해서 요구된 상기 공유 자원들에 대하여 공통인 설치된 공유 자원들이 가장 많은 기존의 런타임 인스턴스를 선택하는 단계, 및 상기 선택된 런타임 인스턴스에 상기 어플리케이션을 설치하는 단계를 포함한다.

Description

어플리케이션 설치{APPLICATION INSTALLATION}

이 발명은 런타임 인스턴스에(at a runtime instance) 어플리케이션(an application)을 설치하기 위한 방법, 및 시스템에 관한 것이다.

"OSGi" 는 Java^TM를 위한 모듈방식 기술(a modularity technology)이다. OSGi 내에서, 번들(a bundle)은 모듈(modularity)의 한 단위이다. 번들의 한 예가 이진 Java jar 파일의 원시 아티팩트(a raw artefact of a binary Java jar file)이고 이는 번들의 실체와 외관들(the identity and externals)을 기술하는 추가의 번들 메타데이터를 갖는다. 여기서, 번들은 "번들 자원(bundle resource)"을 뜻하고, 원시 아티팩트는 "아티팩트 자원"을 말하며, 번들을 위한 메타데이터는 "메타데이터 자원"이라 한다. 자원들은 또한 객체들(objects)로 알려져 있다.

Java 및 모든 Java-기반의 상표들과 로고들은 Oracle 및/또는 그 관계회사들의 상표들 또는 등록 상표들이다.

소프트웨어 어플리케이션들은 개별 모듈들로 구성되는 것이 보통이다. 대부분의 어플리케이션 모듈들, 예를 들어, Java Enterprise Edition (EE) EAR 파일들 또는 OSGi 어플리케이션들은, 재사용 가능 기능성을 제공하는 하나 또는 그 이상의 유틸리티 모듈들(utility modules)을 사용한다. 통상적으로, 유틸리티 모듈들은 어플리케이션 모듈의 일부분으로서 패키지되고 또한 어플리케이션 모듈의 일부분인 메타데이터를 사용하여 어플리케이션 모듈에 의해서 참조된다. 어플리케이션 모듈을 어플리케이션 프레임워크(an application framework) 내에 설치하려면 통상적으로 어플리케이션 모듈 및 유틸리티 모듈 모두를 하드 디스크 상의 단일 디렉토리(a single directory)로 복사해야 한다(involve copying). 따라서, 만일 공통 세트의 유틸리티 모듈들을 이용하는 여러 다른 어플리케이션 모듈들이 설치된다면, 하드 디스크 상에는 동일 유틸리티 모듈들이 다수 복사되어 저장될 것이고, 만일 이 어플리케이션 모듈들이 동일 어플리케이션 프레임워크 런타임 인스턴스에서 실행된다면, 또한 동일 유틸리티 모듈의 여러 버전들이 메모리에 로드될 수도 있을 것이다. 이것은, 유틸리티 모듈을 메모리로 로드하는 데 소비되는 시간의 관점에서뿐만 아니라, 디스크 및 메모리의 이용의 관점에서 명백히 낭비적이다.

이 문제에 대한 알려진 솔루션은 공유 라이브러리들(shared libraries)(Java 플랫폼, Enterprise Edition 또는 Java EE(JEE) 어플리케이션들을 위한) 또는 공동 번들 저장소의 공유 번들들(OSGi 어플리케이션들을 위한)로 알려진 공유 자원들의 개념을 이용하는 것이다. 여러 어플리케이션 모듈들에 공동일 가능성이 있는 유틸리티 모듈들은 어플리케이션 모듈들로부터 추출되어 어플리케이션 프레임워크 런타임 인스턴스에 공유 라이버리리 또는 공동 번들로서 설치된다. 어플리케이션 모듈 설치 시에, 그 어플리케이션 모듈은 요구된 공유 라이브러리들 또는 번들들에 링크된다. 이 프로세스의 결과로, 다수 어플리케이션 모듈들은, 디스크 상에 공유 자원의 사본이 오직 하나만 존재하더라도, 동일 공유 자원을 이용할 수 있다. 어플리케이션 프레임워크에 따라서, 메모리로 로드되는 공유 자원은 또한 오직 하나의 버전만 있을 수 있다.

공유 자원 접근 방식은 어플리케이션 모듈 개발자들과 어플리케이션 프레임워크 관리자들이, 어플리케이션 설치 전에, 어떤 유틸리티 모듈들이 공동 자원들로서 이용 가능하도록 해야 할지를 결정하기 위해 함께 일할 때 잘 작동한다. 그러나, 만일 어플리케이션 모듈이 PAAS(Platform As A Service) 클라우드를 사용하여 제공되는 어플리케이션 프레임워크에 배치되어야 한다면, 공유될 수 있는 이들 자원들을 미리 계획하는 것이 가능하지 않다.

그러므로, 종래 기술에서 전술한 문제를 해결할 필요가 있다.

본 발명의 제1 특징에 따라, 런타임 인스턴스에 어플리케이션을 설치하는 방법이 제공되는데, 상기 방법은 어플리케이션을 설치하기 위한 요청을 수신하는 단계, 상기 어플리케이션에 의해서 요구된 공유 자원들을 정의하는 데이터를 액세스하는 단계, 기존의 런타임 인스턴스들에서 이미 설치된 공유 자원들을 정의하는 데이터를 액세스하는 단계, 상기 어플리케이션에 의해서 요구된 상기 공유 자원들에 대하여 공통인 설치된 공유 자원들이 가장 많은 기존의 런타임 인스턴스를 선택하는 단계, 및 상기 선택된 런타임 인스턴스에 상기 어플리케이션을 설치하는 단계를 포함한다.

본 발명의 제2 특징에 따라, 런타임 인스턴스에 어플리케이션을 설치하기 위한 시스템이 제공되는데, 상기 시스템은: 각각이 하나 또는 그 이상의 런타임 인스턴스들을 실행하도록 구성된 복수의 서버들, 및 상기 서버들에 접속된 관리 컴포넌트(28)을 포함하고, 상기 관리 컴포넌트는 어플리케이션을 설치하기 위한 요청을 수신하며, 상기 어플리케이션에 의해서 요구된 공유 자원들을 정의하는 데이터를 액세스하며, 기존의 런타임 인스턴스들에 이미 설치된 공유 자원들을 정의하는 데이터를 액세스하고, 상기 어플리케이션에 의해서 요구된 상기 공유 자원들에 대하여 공통인 설치된 공유 자원들이 가장 많은 기존의 런타임 인스턴스를 선택하며, 그리고 상기 선택된 런타임 인스턴스에 상기 어플리케이션을 설치하도록 구성된다.

본 발명의 제3 특징에 따라, 런타임 인스턴스에 어플리케이션을 설치하기 위해 컴퓨터 읽기가능 매체 상에 컴퓨터 프로그램 제품이 제공되는데, 상기 제품은 어플리케이션을 설치하기 위한 요청을 수신하기 위한 명령, 상기 어플리케이션에 의해서 요구된 공유 자원들을 정의하는 데이터를 액세스하기 위한 명령, 기존의 런타임 인스턴스들에 이미 설치된 공유 자원들을 정의하는 데이터를 액세스하기 위한 명령, 상기 어플리케이션에 의해서 요구된 상기 공유 자원들에 대하여 공통인 설치된 공유 자원들이 가장 많은 기존의 런타임 인스턴스를 선택하기 위한 명령, 및 상기 선택된 런타임 인스턴스에 상기 어플리케이션을 설치하기 위한 명령을 포함한다. 추가의 특징에 따라, 본 발명은 런타임 인스턴스에 어플리케이션을 설치하기 위한 컴퓨터 프로그램 제품을 제공하는데, 상기 컴퓨터 프로그램 제품은 처리 회로에 의해서 읽기 가능하고 본 발명의 상기 단계들을 수행하기 위한 방법을 수행하기 위해 상기 처리 회로에 의한 실행을 위한 명령들을 저장하는 컴퓨터 읽기가능 저장 매체를 포함한다.

추가의 특징에 따라, 본 발명은 컴퓨터 읽기가능 저장 매체 상에 저장되어 디지털 컴퓨터의 내부 메모리로 로드 가능한 컴퓨터 프로그램을 제공하되, 상기 컴퓨터 프로그램은 소프트웨어 코드 부분들을 포함하고, 상기 프로그램이 컴퓨터 상에서 실행될 때, 본 발명의 상기 단계들을 수행한다.

본 발명 덕분에, 어플리케이션 모듈들이 그들이 사용하는 유틸리티 모듈들에 기초한 PAAS 클라우드 내의 개별 머신들 및 어플리케이션 프레임워크 런타임 인스턴스들(application framework runtimes instances)로 자동으로 타겟(target)될 수 있는 메커니즘을 제공하는 것이 가능하다. 이러한 접근 방식은 모든 유틸리티 모듈들에 관하여 자신의 사본을 가지고 있는 각각의 어플리케이션 모듈을 설치하는 것과 비교하여 디스크 공간, 메모리 및 중앙 처리 유닛(CPU) 사이클들을 절약한다. 이러한 절약은 클라우드 내의 개별 머신들 및 클라우드 모두에게 전체적으로 이득이 된다. 이것은 특히, 예를 들어, 많은 다른 어플리케이션들에 의해서 공유될 수 있는 공동 로깅 유틸리티들과 같은, 보통으로 재사용되는 제3자 모듈들(third party modules)의 경우에 이익이 된다.

어플리케이션 모듈이 PAAS 클라우드로 배치될 때, 어플리케이션 모듈은 자신이 보유하는 유틸리티 모듈들을 결정하기 위해, 클라우드 관리 소프트웨어에 의해서 분석된다. 그 다음, 클라우드 내의 기존의 어플리케이션 프레임워크 런타임 인스턴스들을 체크하여 그들 중 어느 것이, 예를 들어, 공유 라이브러리들(shared libraries)로서 또는 OSGi 번들 저장소(an OSGi bundle repository)의 번들들로서 이미 설치된 유틸리티 모듈들과 매치하는 것을 가지고 있는지를 확인한다. 어플리케이션 모듈은 어플리케이션 모듈의 유틸리티 모듈들과 매치하는(match) 설치된 공유 자원들을 이미 가지고 있는 기존의 어플리케이션 프레임워크 런타임 인스턴스들 상에 우선적으로 설치된다.

설치 시에 새로운 어플리케이션 모듈로부터의 모든 유틸리티 모듈은 새로운 공유 자원들로 변환되거나 또는 기존의 공유 자원들로 링크된다. 어플리케이션은 가능한 한 많은 요건들을 제공하는 클라우드 내의 서버에 타겟된다(targeted). 값(value)에 의해 유틸리티들을 포함하는 것으로부터 참조(reference)에 의해 유틸리티들을 포함하는 것으로 어플리케이션을 변환하면 더 융통성 있는 배치를 할 수 있다. 이러한 접근 방식은 어플리케이션 모듈들이 클라우드의 기존의 런타임 능력들 및 구성(the existing runtime capabilities and configuration of the cloud)을 가장 잘 이용하기 위해 자동으로 배치된다는 것을 의미한다. 특히, 디스크 공간 및 프로세스 메모리는 유틸리티 모듈의 다수 사본들이 단일 공유 자원으로 대체될 수 있음에 따라 감소된다.

바람직하게는, 상기 방법은 기존의 런타임 인스턴스에 설치된 각각의 공유 자원을 위한 식별자(an identifier)를 저장하는 테이블을 유지하는 단계를 더 포함하고, 기존의 런타임 인스턴스들에 이미 설치된 공유 자원들을 정의하는 데이터를 액세스하는 단계는 상기 테이블을 액세스하는 단계를 포함한다. 컴퓨팅 네트워크 내의 관리 컴포넌트는 모든 기존의 런타임 인스턴스들에 걸쳐 사용 중인 모든 공유 자원들을 기록하는 룩업 테이블(a lookup table)을 유지할 수 있다. 이것은 새로운 어플리케이션이 클라우드 내에 설치될 필요가 있을 때 클라우드 컴퓨팅 환경 내에 현재 배치된 공유 자원들을 결정하는 단순한 방법을 제공한다. 상기 테이블은 어떤 공유 자원들이 어떤 특정 런타임 인스턴스에 현재 설치되었는지를 알기 위해 액세스될 수 있다.

이전 단락에서 설명한 테이블을 사용하고 나서, 상기 방법은 유리하게도, 선택된 런타임 인스턴스에 어플리케이션을 설치하는 단계 다음에, 선택된 런타임 인스턴스에 어플리케이션을 설치하는 동안 설치된 새로운 공유 자원 각각을 위한 식별자들로 상기 테이블을 갱신하는 단계를 더 포함할 수 있다. 어플리케이션을 설치하기 위한 요청이 있을 때마다 최선의 런타임 인스턴스가 그 어플리케이션을 위해 선택되고, 그 다음 상기 테이블은, 설치의 결과로서, 선택된 런타임 인스턴스에 이용 가능하게 될 모든 새로운 공유 자원들을 반영하기 위해 갱신될 수 있다. 이것은 공유 자원들에 관한 상기 테이블의 계속적인 갱신(ongoing update)을 제공하는데 이는 미래의 어플리케이션 설치들이 상기 갱신된 테이블을 반영하도록 구성되게(adapted) 이끌 수 있다.

이상적으로, 상기 방법은 기존의 런타임 인스턴스들에 이용 가능한 자유 용량(the free capacity)을 결정하는 단계를 더 포함하고 어플리케이션에 의해서 요구된 공유 자원들에 대하여 공통인 설치된 공유 자원들이 가장 많은(with the greatest number of installed shared resources) 기존의 런타임 인스턴스를 선택하는 상기 단계는 어플리케이션을 설치하기 위해 충분한 자유 용량을 갖는 기존의 런타임 인스턴스만을 선택하는 단계를 포함한다. 새로운 어플리케이션을 설치하기 위해 사용할 런타임 인스턴스의 선택은 또한 이용 가능 런타임 인스턴스들의 각각에서 이용 가능한 자유 메모리의 양을 고려할 수 있다. 그 다음 적절한 런타임 인스턴스의 선택은 충분한 자유 메모리를 갖는 것들에 한정될 수 있다.

유리하게도, 선택된 런타임 인스턴스에 어플리케이션을 설치하는 상기 단계는 선택된 런타임 인스턴스에 이미 존재하는 이들 공유 자원들을 어플리케이션으로부터 제거하는 단계와 선택된 런타임 인스턴스에 어플리케이션의 나머지 컴포넌트들(the residual components) 을 설치하는 단계를 포함한다. 어플리케이션의 설치는 선택된 런타임 인스턴스에 이미 존재하는 공유 자원들 외에(over and above) 필요한 모듈들만 설치하는 것에만 한정될 수 있다. 이는 어플리케이션을 설치하는 가장 효율적인 방법이며 프로세서 및 대역폭 사용을 최대로 절약할 것이다.

본 발명의 바람직한 실시 예들이 지금부터 아래의 도면들을 참조하여, 오직 예로서만, 설명될 것이다.
도 1은 본 발명의 바람직한 실시 예에 따라 런타임 인스턴스의 개략도를 도시한다.
도 2는 본 발명의 바람직한 실시 예에 따라, 새로운 어플리케이션을 설치한 다음의, 런타임 인스턴스의 추가의 개략도를 도시한다.
도 3은 본 발명의 바람직한 실시 예에 따라, 어플리케이션 및 클라우드 컴퓨팅 환경의 개략도를 도시한다.
도 4는 본 발명의 바람직한 실시 예에 따라, 공유 자원 룩업 테이블을 도시한다.
도 5, 6 및 7은 본 발명의 바람직한 실시 예에 따라, 클라우드 컴퓨팅 환경의 추가의 개략도들을 도시한다.
도 8은 본 발명의 바람직한 실시 예에 따라, 어플리케이션을 설치하는 방법의 흐름도를 도시한다.

도 1은 런타임 인스턴스(10)의 예를 도시하고, 이는 두 개의 특정 위치들(12 및 14)를 포함한다. 어플리케이션 특정 모듈들(Application specific modules)은 위치(12)에 설치되고 공유 자원들은 위치(14)에 설치된다. 두 개의 어플리케이션들(16)(AM1 및 AM2로 라벨이 붙어있음)이 어플리케이션 영역(12)에 설치된 것으로 도시되어 있다. 각각의 어플리케이션(16)은 하나 또는 그 이상의 어플리케이션 특정 모듈들(18)과 하나 또는 그 이상의 공유 자원들(20)을 포함한다. 어플리케이션(AM1)은 어플리케이션 특정 모듈(M1) 및 공유 자원들(R1 및 R2)를 포함한다. 이와 유사하게 어플리케이션(AM2)는 어플리케이션 특정 모듈(M2) 및 동일 공유 자원들(R1 및 R2)를 포함한다.

어플리케이션(AM1)이 런타임 인스턴스(10) 내에 설치될 때, 어플리케이션 특정 모듈(M1)은 위치(12)에 설치되고 공유 자원들(R1 및 R2)는 위치(14)에 설치된다. 어플리케이션(AM1) 내의 실제 공유 자원들은 공유 자원들(R1 및 R2)에 대한 링크들로 대체된다. 후속으로, 어플리케이션(AM2)가 런타임 인스턴스(10) 내에 설치될 때, 어플리케이션 특정 모듈(M2)만 위치(12)에 설치되고 어플리케이션(AM2) 내의 공유 자원들(R1 및 R2)는 이미 위치(14)에 존재함에 따라 설치되지 않는다. 어플리케이션(AM2)는 이전에 설치된 공유 자원들(20)에 대한 링크들로 설치된다.

동일한 방법으로, 새로운 어플리케이션(16')이 설치되려고 할 때, 그 어플리케이션(16') 내의 모듈들은 런타임 인스턴스(10)의 위치(14) 내에 이미 설치된 공유 자원(20)에 대하여 어떻게 비교되는지를 알기 위해 검사된다. 이 경우에, 새로운 어플리케이션 AM3은 어플리케이션 특정 모듈 M3 및 공유 자원 R2(예를 들어 표준 라이브러리)를 포함한다. 이 새로운 어플리케이션(16')이 상기 런타임 인스턴스에 설치되려고 할 때, 오직 어플리케이션 특정 모듈 M3만 위치(12)에 설치될 필요가 있고 어플리케이션 AM3 내의 공유 자원 R2는 위치(14) 내에 존재하는 R2의 이미 설치된 복사본에 대한 링크로 대체될 수 있다.

도 2는, 도면에서 AM3으로 라벨된, 제3의 어플리케이션(16')의 설치 후의 런타임 인스턴스(10)을 도시한다. M3으로 라벨된, 어플리케이션 특정 모듈(18)은 위치(12)에 설치되고, R2로 라벨된, 공유 자원(20)은 설치되지 않을 것인데, 그 이유는 이 특정 공유 자원(20)의 사본이 이미 위치(14)에 설치되어 있기 때문이다. 상기 어플리케이션 내의 공유 자원 R2는 설치 영역(14) 내의 공유 자원 R2의 위치에 대한 링크로 대체된다. 이것은 동일 공유 자원들의 중복 사본들은 동일 런타임 인스턴스(10)에 설치되지 않는다는 것을 의미한다. 오직 새로운 공유 자원들만 위치(14)에서 설치될 것이다.

도 1 및 2와 관련하여 설명한 방법은 런타임 인스턴스(10)에 어플리케이션들을 설치하기 위한 효율적인 프로세스를 제공하고 런타임 인스턴스(10)에 이용 가능한 자원들의 효율적인 사용을 또한 제공한다. 어플리케이션들이 설치될 때 메모리 사용이 감소되고 더 적은 대역폭이 소비된다. 동일 런타임 인스턴스(10)에 설치되는 모든 미래의 어플리케이션들은 위치(14)에서 이미 설치되어 존재하지 않는 공유 자원들(20)만 설치하는 동일 프로세스를 진행할 것이다(go through). 설치되어야 할 새로운 어플리케이션(16)의 각각은 검사되어 어플리케이션 특정(application specific)인 어플리케이션(16) 내의 이들 모듈들과 이미 존재할 수도 있는 공유 자원들을 식별할 것이다.

런타임 인스턴스(10)은 서버 상에 존재하는데, 이 서버는 클라이언트 디바이스에게 런타임 인스턴스(10)에 의해서 호스트되는 어플리케이션(16)에 대한 액세스를 제공한다. 클라이언트 디바이스가 어플리케이션(16)을 실행하도록 요청하면 하나의 복사본이 이용 가능한 서버 상의 런타임 인스턴스(10)에 설치되어 상기 클라이언트 디바이스의 사용자에게 어플리케이션(16)에 대한 액세스를 제공할 것이다. 설치된 어플리케이션(16)은 하나 또는 그 이상의 어플리케이션 특정 모듈(18) 및 하나 또는 그 이상의 공유 자원들(20)을 포함할 것이다. 공유 자원(20)은, 라이브러리 같은, 어떤 점에서 필수적으로 표준화된 컴포넌트이며, 동일 컴퓨팅 환경에서 다른 어플리케이션들에 의해서 사용될 수 있다.

도 3은 더 복잡한 컴퓨팅 환경을 도시하는데, 이는 각각이 하나 또는 그 이상의 런타임 인스턴스들(10)을 제공하는 서버들의 네트워크로 구성된 본질적으로 클라우드(22)이다. 클라우드(22)는 하나의 컴퓨팅 자원이며 프로세싱 및 저장 기능을 클라이언트 디바이스들에게 제공하는데, 통상적으로 이용 가능한 컴퓨팅 기능에 액세스하기 위해 사용자들이 개시하는 세션들을 통해서 제공한다. 관리 컴포넌트(28)은 상기 세션들의 세팅업(setting up) 및 사용자가 자신의 로컬 클라이언트 디바이스를 통해서 액세스하는 어플리케이션들의 설치를 관리한다. 클라우드(22)를 구성하는 하부 하드웨어 자원들은 클라이언트 디바이스들에는 보이지 않으며 따라서 사용자들은 자신의 컴퓨팅 자원들을 제공하는 하부 프로세스들을 알지 못한다.

이 도면에서, 새로운 어플리케이션(16)은 클라우드(22) 내의 어딘가에 설치될 예정이다. 이 어플리케이션(16)은 기존의 런타임 인스턴스(10)에 설치되거나 또는 새로운 인스턴스가 이 새로운 어플리케이션(16)을 위해 특별히 생성되어야 한다. 이 어플리케이션(16)은 어플리케이션 특정 모듈(18) 및 공유 자원들(20)과 같은 모듈들을 포함한다. 어플리케이션(16)으로부터 클라우드(22)로 향하는 화살표 상에 표시된 물음표는 어플리케이션(16)을 어디에 설치해야 최선인지에 관한 열린 질문을 표시한다. 클라우드(22) 내의 관리 컴포넌트(28)은 클라우드(22) 내의 런타임 인스턴스들(10)에 관한 분석을 수행해야 한다.

이 분석은 클라우드(22) 내의 새로운 어플리케이션(16)의 설치를 위한 가장 논리적인 위치(the most logical location)를 결정하고, 이 프로세스는 아래에서 더 상세히 설명한다. 요약하면, 어플리케이션(16)을 설치하기 위한 요청을 수신한 후, 관리 컴포넌트(28)은 어플리케이션(16)에 의해서 요구된 공유 자원들을 정의하는 데이터를 액세스하고 그리고 기존의 런타임 인스턴스(10)에 이미 설치된 공유 자원들(20)을 정의하는 데이터를 액세스한다. 관리 컴포넌트(28)은 어플리케이션(16)에 의해서 요구된 공유 자원들(20)에 대하여 공통인 설치된 공유 자원들이 가장 많은 기존의 런타임 인스턴스를 선택하고 그리고 선택된 런타임 인스턴스(10)에 어플리케이션(16)을 설치한다.

도 4는 공유 자원들 룩업 테이블(LUT)(24)를 도시하며, 이는 기존의 런타임 인스턴스(10)에 설치된 각각의 공유 자원(20)을 위한 식별자(26)을 저장하기 위해 사용될 수 있다. 룩업 테이블(24)는, 필수적으로, 행들(rows)를 포함하는데, 각각의 행은 테이블(24)에서 자신의 식별자(26)에 의해서 표시되는 특정 공유 자원(20)에 전속된다(dedicated). 각각의 행은 또한 그 행의 특정 공유 자원(20)을 보유하는 런타임 인스턴스들(10)의 목록을 보유한다. 도 4의 테이블(24)가 비록 각각의 공유 자원(20)이 단일 런타임(10)에서만 존재하는 것으로 도시되어있을지라도, 실제 구현에서는 각각의 공유 자원(20)은 다수 런타임 인스턴스들(10)에 존재할 가능성이 매우 높다(highly likely).

룩업 테이블(24) 내에서 사용되는 공유 자원 식별자(26)은 특정 기술 환경에서 보통으로 사용되는 파일, 모듈 또는 라이브러리의 이름일 수 있다. 추가로, 또는 대안으로서, 공유 자원 식별자(26)은, 만일 동일 공유 자원(20)을 위해 사용되는 이름이 하나 이상일 가능성이 있다면, 공유 자원(20) 상에 미리 정의된 해싱 펑션(a predefined hashing function)을 사용하여 생성될 수 있을 것이다. 이것은 관리 컴포넌트(28)이 수신된 새로운 어플리케이션(16)의 일부분을 구성하는 모든 공유 자원(20)을 식별할 수 있게 할 것이다. 관리 컴포넌트(28)은 공유 자원 식별자(26)을 획득하기 위해 각각의 새로운 공유 자원 상에 상기 해싱 펑션을 수행할 것이다.

관리 컴포넌트(28)은 테이블(24)를 저장하고 유지하며 새로운 어플리케이션들(16)이 설치되면 항상 테이블(24)를 갱신할 수 있다. 예를 들어, 새로운 어플리케이션(16)이 수신되었다고 할 때, 이것이 네 개의 공유 자원들을 포함하되, 그 중 두 개는 이미 특정 런타임에서 존재하는 것이고, 나머지 두 개는 관리 컴포넌트에 완전히 새로운 것일 수 있다. 이 새로운 어플리케이션(16)은 이미 존재하는 두 개의 공통 공유 자원들을 갖는 특정 런타임 인스턴스(10)에 설치될 것이고 테이블(24)는 이전에 알려지지 않은 두 개의 새로운 공유 자원들(20)이 이제 그 특정 런타임 인스턴스(10)에 설치되는 것을 보여주기 위해 갱신될 것이다.

도 5는 새로운 어플리케이션(16')이 클라우드(22) 내의 어딘가에 설치되려고 할 때 취해질 제1 프로세스 단계들을 도시한다. 사용자는 어플리케이션 모듈을 클라우드(22)에 배치한다. 배치 시에 관리 컴포넌트(28)에 의해서 실행되는 소프트웨어를 컨트롤하는 클라우드(22)는 다음 단계들을 수행하는데, 예를 들어, JEE ear 파일(ear file) 또는 OSGi 어플리케이션 파일 같은, 어플리케이션 모듈의 타입을 검출하는 단계(501)로 시작한다. 파일 확장자들(file extensions)이 사용되거나 또는 프로그래밍 환경의 구조에 관한 지식이 사용될 수 있는데, 이는 클라우드(22) 내에 이미 설치된 런타임 인스턴스(10)에 설치될 새로운 어플리케이션(16') 내에 존재하는 다른 어플리케이션 모듈 타입들을 검출하기 위해서이다.

어플리케이션 모듈 타입들에 관한 지식을 사용하여, 관리 컴포넌트(28)는 유틸리티 모듈들을, 예를 들어, ear 파일 내의 EJB(Enterprise Java Beans) jar 파일들(jar files)의 목록(manifest)으로부터 참조되는 jar 파일들, 또는 OSGi 어플리케이션 내의 값에 의해서 포함되는 번들들 같은, 유틸리티 모듈들을 식별한다(502). 모든 유틸리티 모듈들은 비록 단일 어플리케이션 모듈에 의해서만 사용된다 하더라도 공유 라이브러리 또는 공유 번들이 되도록 변환될 것이다. 이들 모듈들은 공유 자원들(20)로 고려될 수 있다. 본질적으로 일반적이고(generic in nature) 특정 어플리케이션에 특정되지 않는 어플리케이션(16') 내의 모든 모듈은 공유 자원(20)이 될 수 있다. 이들은 동일 런타임 인스턴스(10) 내의 어플리케이션들(16) 사이에서 재사용될 수 있는 모듈들이다.

관리 컴포넌트(28)은, 클라우드(22)를 위해 제어 소프트웨어를 실행하며, 새로운 어플리케이션(16')을 위해 사용된 프로그래밍 언어에 관한 한 중립적이다. 어플리케이션(16')이 어플리케이션들(16) 사이에서 공유될 수 있는 것 중 하나 이상의, 개별 모듈들을 포함하는 경우, 클라우드(22) 내에 설치된 모든 새로운 어플리케이션(16')은 여기서 설명한 방법으로 처리된다. 도 5에 도시한 단계 1및 2에서, 관리 컴포넌트(28)은 새로운 어플리케이션(16')을 구성하는 모듈들을 검사하여 어플리케이션(16') 내의 "유틸리티 모듈들"을 식별하는데, 이는 클라우드(22) 내에서 상기 어플리케이션(16')의 설치를 더 효율적으로 수행하기 위해서이다.

도 6은 프로세스의 다음 단계들을 도시한다. 관리 컴포넌트(28)은 새로운 어플리케이션(16') 내의 각각의 공유 자원(20)을 위한 식별자(26)을 생성한다(603). 이 자원 식별자(26)은 등가성(equality)을 체크하기 위한 다른 공유 자원들(20)과 비교를 위해 사용될 것이다. 이것은 해시 펑션을 통해서 생성되거나 또는 이름 기반이거나(name based) 또는 공유 자원(20)을 구성하는 단순한 바이트들일 수 있다. 관리 컴포넌트(28)은 설치된 공유 자원들(20) 중 적어도 하나를 이미 가지고 있는 클라우드(22) 내의 모든 어플리케이션 프레임워크 런타임(10)에 대해 검색하는데(604), 공유 자원 룩업 테이블(24)를 사용하여 하고, 이 룩업 테이블은 공유 자원 식별자들(26)을 그들이 설치된 런타임들(10)으로 맵(map)하는데, 예를 들어, 룩업 테이블(24)를 검색하여서 한다. 이들 런타임들(10)은 새로운 어플리케이션(16')의 설치를 위한 잠재적 후보들로 고려된다.

그 다음, 관리 컴포넌트(28)은 어플리케이션 모듈(18)을 기준의 다음 세트(the following set of criteria)를 가장 잘 만족시키는 런타임(10) 상에 설치되는데(605), 그 기준은 가능한 한 많은 공통 공유 자원들(20)을 가지고 있고 어플리케이션 모듈(18)의 성능 요건들을 충족시킬 충분한 자유 용량(sufficient free capacity)을 가지고 있는 것이다. 설치 시에, 관리 컴포넌트(28)은, 필요에 따라, 모든 새로운 공유 자원들/어플리케이션 모듈(18)로부터 기존의 공유 자원들(20)로의 링크를 생성한다. 이러한 방식으로, 관리 컴포넌트(28)은 새로운 어플리케이션(16')을 위한 가장 효율적인 위치를 선택한다. 이러한 효율성은 설치되어야 할 데이터의 양을 감소시키고, 관리 컴포넌트(28)에 의한 최소의 추가적인 노력으로, 설치 프로세스의 대역폭 요건을 또한 감소시킨다.

도 5 및 6의 예에서, 새로운 어플리케이션(16')은 두 개의 공유 자원들(20)을 포함하는데, 이들은 R1 및 R2로 라벨이 붙어있다. 룩업 테이블(24)에 따르면, AFR1로 라벨이 붙은 런타임 인스턴스(10)은 이미 존재하는 공유 자원 R1을 가지고 있다. 그러나, AFR2로 라벨이 붙은 런타임 인스턴스(10)은, 룩업 테이블(24)로부터 다시 보는 바와 같이, 존재하는 공유 자원들 R1및 R2 모두를 가지고 있다. 이것은 이 런타임 인스턴스 AFR2가 새로운 어플리케이션(16')의 설치를 위해 더 좋은 위치라는 것을 의미하고 그러므로 관리 컴포넌트(28)은, 도 6의 화살표에 의해서 도시한 바와 같이, 이 런타임 인스턴스(10)에 새로운 어플리케이션(16')을 설치한다.

만일 새로운 어플리케이션(16")의 설치를 위한 매칭 런타임(10)이 발견될 수 없다면, 관리 컴포넌트(28)은 클라우드(22)로부터의 새로운 런타임(10)을 정상으로 제공하고 어플리케이션 모듈(18) 및 새로운 공유 자원들(20)은 그곳에 설치된다. 끝으로, 관리 컴포넌트(28)은 모든 새롭게 생성된 공유 자원 식별자들(26) 및 그들이 설치된 런타임(10)으로 공유 자원 룩업 테이블(24)을 갱신한다. 이것은 새로운 어플리케이션(16')이 설치될 때마다 계속적으로 갱신될 동적 테이블(24)을 제공하고 런타임 설치의 효율은 사용자 요청들이 클라우드(22) 내에 어플리케이션들(16)을 설치하기 위해 수신될 때 각각의 어플리케이션(16')을 위해 계속 될 것이다.

도 7은 클라우드 컴퓨팅 네트워크(22) 내의 서버로서 관리 컴포넌트(28)을 도시한다. 관리 컴포넌트(28)은 클라우드 컴퓨팅 환경(22)를 구성하는 다른 서버들(30)과 통신한다. 클라우드(22) 내의 다수 컴포넌트들에게 서비스를 제공하는 전속 저장 디바이스들과 서버들(30)을 포함하는, 다수의 다른 머신들이 클라우드(22)를 구성할 것이다. 새로운 어플리케이션(16)의 설치와 관련하여, 관리 컴포넌트(28)은 CD-ROM(32)와 같은 컴퓨터 읽기 가능 매체로부터 제공될 수 있는 컴퓨터 프로그램 제품에 의해서 제어될 수 있다. 컴퓨터 프로그램 제품에서 명령들은, 새로운 어플리케이션(16)의 설치를 처리할 때, 관리 컴포넌트(28)의 프로세서를 제어하기 위해 사용된다.

컴퓨터 프로그램 제품 상의 명령들에 의해서 구현되는 프로세스는 도 8의 흐름도에 요약되어 있다. 런타임 인스턴스(10)에 새로운 어플리케이션(16)을 설치하는 방법은 어플리케이션(16)을 설치하기 위한 요청을 수신하는 단계(801), 상기 어플리케이션(16)에 의해서 요구된 공유 자원들(20)을 정의하는 데이터를 액세스하는 단계(802), 기존의 런타임 인스턴스들(10)에 이미 설치된 공유 자원들(20)을 정의하는 데이터(24)를 액세스하는 단계(803), 상기 어플리케이션(16)에 의해서 요구된 상기 공유 자원들(20)에 대하여 공통인 설치된 공유 자원들(20)이 가장 많은 기존의 런타임 인스턴스(10)를 선택하는 단계(804), 및 상기 선택된 런타임 인스턴스(10)에 상기 어플리케이션(16)을 설치하는 단계(805)를 포함한다.

본 발명의 바람직한 실시 예에서, 공유 자원들이 어디에서 발견되었는지에 관한 레코드는 룩업 테이블(24)에 저장된다. 그러한 레코드들은 다수의 다른 아티팩트들 (artefacts)에, 예를 들어 관계형 데이터베이스에 저장되고 이로부터 액세스될 수 있음은 당업자들이 잘 이해할 것이다.

당업자들이 이해할 수 있듯이, 본 발명의 특징들은 시스템, 방법 컴퓨터 프로그램 제품 또는 컴퓨터 프로그램으로서 구현될 수 있다. 따라서, 본 발명의 특징들은 전체가 하드웨어 실시 예로서, 전체가 소프트웨어 실시 예(펌웨어, 상주 소프트웨어, 마이크로-코드, 등을 포함)로서, 또는 소프트웨어 및 일반적으로 여기서 "회로", "모듈" 또는 "시스템"으로 부를 수 있는 하드웨어 특징들을 조합하는 실시 예의 형태를 취할 수 있다. 더 나아가, 본 발명의 특징들은 그 위에 구현된 컴퓨터 읽기 가능 프로그램 코드를 갖는 하나 또는 그 이상의 컴퓨터 읽기 가능 매체(들)에 구현된 컴퓨터 프로그램 제품의 형태를 취할 수 있다.

하나 또는 그 이상의 컴퓨터 읽기 가능 매체(들)의 모든 조합이 이용될 수 있다. 컴퓨터 읽기 가능 매체는 컴퓨터 읽기 가능 신호 매체 또는 컴퓨터 읽기 가능 저장 매체일 수 있다. 컴퓨터 읽기 가능 저장 매체는, 예를 들어, 전자, 자기, 광, 전자기, 적외선, 또는 반도체 시스템, 장치, 또는 디바이스, 또는 전술한 것의 모든 적절한 조합이 될 수 있으나, 이에 한정되지는 않는다. 컴퓨터 읽기 가능 저장 매체의 더 구체적인 예들(비-포괄적인 목록)은 다음을 포함할 수 있다: 하나 또는 그 이상의 배선들을 갖는 전기적 접속, 휴대용 컴퓨터 디스켓, 하드 디스크, 임의 접근 메모리(RAM), 읽기 전용 메모리(ROM), 지울 수 있고 프로그램 가능한 읽기 전용 메모리(EPROM또는 플래시 메모리), 광 파이버, 휴대용 컴팩트 디스크 읽기 전용 메모리(CD-ROM), 광 저장 디바이스, 자기 저장 디바이스, 또는 전술한 것들의 모든 적절한 조합. 이 출원의 맥락에서, 컴퓨터 읽기 가능 저장 매체는 명령 처리 시스템, 장치 또는 디바이스에 의해서 또는 이와 함께 사용하기 위해 프로그램을 보유, 또는 저장할 수 있는 모든-유형의 매체가 될 수 있다.

컴퓨터 읽기 가능 신호 매체는, 예를 들어, 반송파의 베이스밴드에 또는 일부분으로서, 그 안에 구현된 컴퓨터 프로그램 코드를 갖는 전파된 데이터 신호를 포함할 수 있다. 그러한 전파된 신호는 전자기, 광, 또는 그들의 모든 적절한 조합을 포함하지만, 이에 한정되지 않는, 다양한 형태 중의 하나를 취할 수 있다. 컴퓨터 읽기가능 신호 매체는 컴퓨터 읽기가능 저장 매체가 아니고 명령 처리 시스템, 장치 또는 디바이스에 의해서 또는 이와 함께 사용하기 위해 프로그램을 통신, 전파, 또는 전송할 수 있는 모든 컴퓨터 읽기가능 매체가 될 수 있다.

컴퓨터 읽기가능 매체 상에 구현된 프로그램 코드는, 무선, 유선, 광 파이버 케이블, RF, 등, 또는 전술한 것들의 모든 적절한 조합을 포함하나, 이에 한정되지 않는, 모든 적절한 매체를 사용하여 전송될 수 있다.

본 발명의 특징들을 위한 연산들을 실행하기 위한 컴퓨터 프로그램 코드는 Java, Smalltalk, C++ 또는 그와 유사 언어 등의 객체 지향 프로그래밍 언어와 "C" 프로그래밍 언어 또는 유사한 언어들의 종래의 절차적 프로그래밍 언어들을 포함하여, 하나 또는 그 이상의 프로그래밍 언어들의 조합으로 작성될 수 있다. 상기 프로그램 코드는 전적으로 사용자의 컴퓨터상에서, 부분적으로 사용자의 컴퓨터상에서, 독립형(stand-alone) 소프트웨어 패키지로서, 부분적으로 사용자의 컴퓨터상에서 그리고 부분적으로 원격 컴퓨터상에서 또는 전적으로 원격 컴퓨터나 서버상에서 실행될 수 있다. 위에서 후자의 경우에, 원격 컴퓨터는 근거리 통신망(LAN) 또는 광역 통신망(WAN)을 포함한 모든 종류의 네트워크를 통해서 사용자의 컴퓨터에 접속될 수 있고, 또는 이 접속은 (예를 들어, 인터넷 서비스 제공자를 이용한 인터넷을 통해서) 외부 컴퓨터에 이루어질 수도 있다. Java 및 모든 Java-기반의 상표들 및 로고들은 Oracle 및/또는 그의 관계회사들의 상표들 또는 등록 상표들이다.

본 발명의 특징들은 본 발명의 실시 예들에 따른 방법들, 장치들(시스템들) 및 컴퓨터 프로그램 제품들의 흐름 예시도들 및/또는 블록도들을 참조하여 아래에서 기술된다. 흐름 예시도들 및/또는 블록도들의 각 블록과 흐름 예시도들 및/또는 블록도들 내 블록들의 조합들은 컴퓨터 프로그램 명령들에 의해 구현될 수 있다는 것을 이해할 수 있을 것이다. 이 컴퓨터 프로그램 명령들은 범용 컴퓨터, 특수목적용 컴퓨터, 또는 기타 프로그램가능 데이터 처리 장치의 프로세서에 제공되어 머신(machine)을 생성하고, 그렇게 하여 그 명령들은 상기 컴퓨터 또는 기타 프로그램가능 데이터 처리 장치의 프로세서를 통해서 실행되어, 상기 흐름도 및/또는 블록도의 블록 또는 블록들에 명시된 기능들/동작들을 구현하기 위한 수단을 생성하도록 할 수 있다.

상기 컴퓨터 프로그램 명령들은 또한 컴퓨터 읽기 가능 매체에 저장될 수 있으며, 컴퓨터, 기타 프로그램가능 데이터 처리 장치 또는 다른 디바이스들에 지시하여 상기 컴퓨터 읽기 가능 매체에 저장된 명령들이 상기 흐름도 및/또는 블록도의 블록 또는 블록들에 명시된 기능/동작을 구현하는 명령들을 포함하는 제품(an article of manufacture)을 생성하도록 특정한 방식으로 기능하게 할 수 있다.

상기 컴퓨터 프로그램 명령들은 또한 컴퓨터, 기타 프로그램가능 데이터 처리 장치, 또는 다른 디바이스들에 로드되어, 컴퓨터, 기타 프로그램가능 장치 또는 다른 디바이스들에서 일련의 연산 단계들이 수행되게 하여 컴퓨터 구현 프로세스를 생성하며, 그렇게 하여 상기 컴퓨터 또는 기타 프로그램가능 장치상에서 실행되는 명령들이 흐름도 및/또는 블록도의 블록 또는 블록들에 명시된 기능들/동작들을 구현하기 위한 프로세스들을 제공하도록 할 수 있다.

도면들 내 흐름도 및 블록도들은 본 발명의 여러 실시 예들에 따른 시스템들, 방법들 및 컴퓨터 프로그램 제품들의 가능한 구현들의 아키텍처, 기능성, 및 동작을 예시한다. 이와 관련하여, 상기 흐름도 또는 블록도들 내 각 블록은 상기 명시된 논리적 기능(들)을 구현하기 위한 하나 또는 그 이상의 실행 가능한 명령들을 포함하는, 모듈, 세그먼트 또는 코드의 일부분을 나타낼 수 있다. 일부 다른 구현들에서, 상기 블록에 표시된 기능들은 도면들에 표시된 순서와 다르게 일어날 수도 있음도 또한 주목해야 한다. 예를 들면, 연속으로 도시된 두 개의 블록들은 실제로는 사실상 동시에 실행될 수 있고, 또는 이 두 블록들은 때때로 관련된 기능에 따라서는 역순으로 실행될 수도 있다. 블록도들 및/또는 흐름 예시도의 각 블록, 및 블록도들 및/또는 흐름 예시도 내 블록들의 조합들은 특수목적 하드웨어 및 컴퓨터 명령들의 명시된 기능들 또는 동작들, 또는 이들의 조합들을 수행하는 특수목적 하드웨어-기반 시스템들에 의해 구현될 수 있음도 또한 주목해야 한다.

오해를 피하기 위해, 명세서 및 청구항들 전체를 통해서 여기서 사용된 "포함하는(comprising)"이라는 용어는 "~으로만 구성되는(consisting only of)"을 의미하는 것으로 해석되어서는 안됨을 밝혀둔다.

Claims (12)

1. 런타임 인스턴스에(at a runtime instance) 어플리케이션을 설치하는(installing) 방법에 있어서, 상기 방법은:
   어플리케이션을 설치하기 위한 요청을 수신하는 단계,
   상기 어플리케이션에 의해서 요구된 공유 자원들을 정의하는 데이터(data defining shared resources)를 액세스하는 단계,
   기존의 런타임 인스턴스들에 이미 설치된 공유 자원들을 정의하는 데이터를 액세스하는 단계;
   상기 어플리케이션에 의해서 요구된 상기 공유 자원들과 공통인 공유 자원들이 가장 많이 설치된(with the greatest number of installed shared resources) 기존의 런타임 인스턴스를 선택하는 단계, 및
   상기 선택된 런타임 인스턴스에 상기 어플리케이션을 설치하는 단계를 포함하는
   방법.
2. 제1항에 있어서, 상기 방법은 기존의 런타임 인스턴스에 설치된 각각의 공유 자원을 위한 식별자를 저장하는 테이블을 유지하는 단계를 더 포함하고, 기존의 런타임 인스턴스들에 이미 설치된 공유 자원들을 정의하는 데이터를 액세스하는 상기 단계는 상기 테이블을 액세스하는 단계를 포함하는
   방법.
3. 제2항에 있어서, 상기 방법은, 상기 선택된 런타임 인스턴스에 상기 어플리케이션을 설치하는 단계 다음에, 상기 선택된 런타임 인스턴스에 상기 어플리케이션을 설치하는 동안 설치된 각각의 새로운 공유 자원을 위한 식별자들로 상기 테이블을 갱신하는 단계를 더 포함하는
   방법.
4. 제1, 2 또는 3항에 있어서, 상기 방법은 기존의 런타임 인스턴스들에 이용 가능한 자유 용량(the free capacity)을 결정하는 단계를 더 포함하고 상기 어플리케이션에 의해서 요구된 상기 공유 자원들과 공통인 공유 자원들이 가장 많이 설치된 기존의 런타임 인스턴스를 선택하는 상기 단계는 상기 어플리케이션을 설치하기 위해 충분한 자유 용량을 갖는 기존의 런타임 인스턴스만을 선택하는 단계를 포함하는
   방법.
5. 이전 청구항 중 어느 한 항에 있어서, 상기 선택된 런타임 인스턴스에 상기 어플리케이션을 설치하는 상기 단계는 상기 선택된 런타임 인스턴스에 이미 존재하는 이들 공유 자원들을 상기 어플리케이션으로부터 제거하는 단계와 상기 선택된 런타임 인스턴스에 상기 어플리케이션의 나머지 컴포넌트들을 설치하는 단계를 포함하는
   방법.
6. 런타임 인스턴스들에 어플리케이션들을 설치하기 위한 시스템에서, 상기 시스템은:
   각각이 하나 또는 그 이상의 런타임 인스턴스들을 실행하도록 구성된 복수의 서버들, 및
   상기 서버들에 접속된 관리 컴포넌트(28)을 포함하고,
   상기 관리 컴포넌트는:
   어플리케이션을 설치하기 위한 요청을 수신하고, 상기 어플리케이션에 의해서 요구된 공유 자원들을 정의하는 데이터를 액세스하며,
   기존의 런타임 인스턴스들에 이미 설치된 공유 자원들을 정의하는 데이터를 액세스하고, 상기 어플리케이션에 의해서 요구된 상기 공유 자원들과 공통인 공유 자원들이 가장 많이 설치된 기존의 런타임 인스턴스를 선택하며, 그리고
   상기 선택된 런타임 인스턴스에 상기 어플리케이션을 설치하도록 구성되는
   시스템.
7. 제6항에 있어서, 상기 관리 컴포넌트는 기존의 런타임 인스턴스에서 설치된 각각의 공유 자원을 위한 식별자를 저장하는 테이블을 유지하도록 더 구성되고 상기 관리 컴포넌트는, 기존의 런타임 인스턴스들에서 이미 설치된 데이터 정의 공유 자원들을 액세스할 때, 상기 테이블을 액세스하도록 구성되는
   시스템.
8. 제7항에 있어서, 상기 관리 컴포넌트는, 상기 선택된 런타임 인스턴스에 상기 어플리케이션을 설치하는 단계 다음에, 상기 선택된 런타임 인스턴스에 상기 어플리케이션을 설치하는 동안 설치된 각각의 새로운 공유 자원을 위한 식별자들로 상기 테이블을 갱신하도록 더 구성되는
   시스템.
9. 제6, 7 또는 8항에 있어서, 상기 관리 컴포넌트는 기존의 런타임 인스턴스들에 이용 가능한 자유 용량을 결정하도록 더 구성되고, 상기 어플리케이션에 의해서 요구된 상기 공유 자원들에 대하여 공통인 설치된 공유 자원들이 가장 많은 기존의 런타임 인스턴스를 선택할 때, 상기 어플리케이션을 설치하기 위해 충분한 자유 용량을 갖는 기존의 런타임 인스턴스만을 선택하도록 더 구성되는
   시스템.
10. 제 6항 내지 제 9항 중 어느 한 항에 있어서, 상기 관리 컴포넌트는, 상기 선택된 런타임 인스턴스에 상기 어플리케이션을 설치할 때, 상기 선택된 런타임 인스턴스에 이미 존재하는 이들 공유 자원들을 상기 어플리케이션으로부터 제거하고 상기 선택된 런타임 인스턴스에 상기 어플리케이션의 나머지 컴포넌트들을 설치하도록 구성되는
    시스템.
11. 런타임 인스턴스에 어플리케이션을 설치하기 위한 컴퓨터 프로그램 제품에서, 상기 컴퓨터 프로그램 제품은:
    처리 회로에 의해서 읽기 가능하고 제 1항 내지 제5항 중 어느 한 항에서의 방법을 수행하기 위해 상기 처리 회로에 의한 실행을 위한 명령들을 저장하는 컴퓨터 읽기가능 저장 매체를 포함하는
    컴퓨터 프로그램 제품.
12. 컴퓨터 읽기가능 저장 매체 상에 저장되어 디지털 컴퓨터의 내부 메모리로 로드가능한 컴퓨터 프로그램으로서, 소프트웨어 코드 부분들을 포함하고, 상기 프로그램이 컴퓨터 상에서 실행될 때, 제 1항 내지 제5항 중 어느 한 항에서의 방법을 수행하는
    컴퓨터 프로그램.

Images