KR102313476B1 - 멀티테넌트 어플리케이션 서버 환경에서 단대단 라이프사이클을 제공하기 위한 시스템 및 방법 - Google Patents

Abstract

실시예에 따르면, 멀티테넌트 어플리케이션 서버 환경에서 단대단 라이프사이클을 제공하기 위한 시스템 및 방법이 본 명세서에 기술된다. 라이프사이클 관리자는 서로 다른 컴포넌트들, 예를 들어 고유의 파티션-특정 구성들을 갖는, 어플리케이션 서버들, 트래픽 디렉터들 또는 로드 밸런서들, 그리고 데이터베이스 또는 다른 컴포넌트들,에 걸쳐서 구성 통합을 할 수 있게 한다. 실시예에 따르면, 상기 단대단 라이프사이클 인프라스트럭처는 멀티테넌트 어플리케이션 서버 환경 내 상기 서로 다른 컴포넌트들이 고유의 컴포넌트-특정 라이프사이클 기능을 제공하기 위해 라이프사이클 플러그인을 사용할 수 있게 하는 플러그인-기반 메커니즘을 포함한다. 실시예에 따르면, 상기 시스템은 서비스에 대한 테넌트를 특정 파티션에 온보드하기 위해 사용될 수 있는 테넌트 온보딩 기능에 대한 지원을 포함한다. 실시예에 따르면, 상기 시스템은 상기 멀티테넌트 어플리케이션 서버 환경 내에 글로벌 런타임의 상기 사용을 지원한다.

Description

멀티테넌트 어플리케이션 서버 환경에서 단대단 라이프사이클을 제공하기 위한 시스템 및 방법 {SYSTEM AND METHOD FOR PROVIDING AN END-TO-END LIFECYCLE IN A MULTITENANT APPLICATION SERVER ENVIRONMENT}

[관련된 어플리케이션들에 대한 우선권주장 및 상호-참조]

본 출원은 미국 가출원들: 2014년 9월 25일에 출원된, 출원 번호 62/055,575,“SYSTEM AND METHOD FOR PROVIDING END-TO-END LIFECYCLE IN A MULTITENANT APPLICATION SERVER ENVIRONMENT”2014년 9월 25일에 출원된, 출원 번호 62/055,577, "SYSTEM AND METHOD FOR TENANT ONBOARDING IN A MULTITENANT APPLICATION SERVER ENVIRONMENT" 2014년 9월 26일에 출원된, 출원 번호 62/055,856 "SYSTEM AND METHOD FOR DATABASE AND APPLICATION SERVER LIFECYCLE PLUGINS IN A MULTITENANT APPLICATION SERVER ENVIRONMENT" 및 2014년 9월 26일에 출원된, 출원 번호 62/056,427 "SYSTEM AND METHOD FOR GLOBAL RUNTIME IN A MULTITENANT APPLICATION SERVER ENVIRONMENT" 및 관련된 미국 특허 출원: 2015년 1월 21일에 출원된, 출원 번호 14/601,883 "SYSTEM AND METHOD FOR SUPPORTING MULTI-TENANCY IN AN APPLICATION SERVER, CLOUD, OR OTHER ENVIRONMENT"의 우선권을 주장한다. 이 각각의 출원들은 본 발명에 참조로 포함된다.

[기술분야]

본 발명의 실시예들은 일반적으로 어플리케이션 서버들 및 클라우드 환경들에 관한 것이며, 멀티테넌트 어플리케이션 서버 환경에서 단대단 라이프사이클, 테넌트 온보딩, 또는 글로벌 런타임을 제공하는 시스템들 및 방법들에 관한 것이다.

어플리케이션 서버들은 일반적으로 소프트웨어 어플리케이션들이 배포되고 실행될 수 있는 관리된 컴퓨팅 환경을 제공한다. 클라우드 기반 컴퓨팅 환경들은 어플리케이션들이 그 안에서 실행되게 하고, 클라우드에 의해 제공되는 상기 분산된 리소스들을 사용하게 한다. 이러한 환경들은 다수의 사용자들 또는 테넌트들을 지원할 수 있으며, 그 중 일부는 해당 사용자 또는 테넌트에게 특정한 구체적 요구 사항들을 가질 수 있다. 추가적 테넌트들이 상기 시스템에 추가될 때, 상기 시스템은 필요에 따라 다른 시스템 컴포넌트를 상기 테넌트와 관련시키는 것을 포함하는, 각 테넌트의 요구들을 처리할 수 있어야 한다. 이들은 본 발명의 실시예들이 사용될 수 있는 환경들의 상기 유형의 일부 예들이다.

실시예에 따르면, 멀티테넌트 어플리케이션 서버 환경에서 단대단 라이프사이클을 제공하기 위한 시스템 및 방법이 본 명세서에 기술된다. 라이프사이클 관리자는 서로 다른 컴포넌트들, 예를 들어 고유의 파티션-특정 구성들을 갖는, 어플리케이션 서버들, 트래픽 디렉터들 또는 로드 밸런서들, 그리고 데이터베이스 또는 다른 컴포넌트들, 에 걸쳐서 구성 통합을 할 수 있게 한다. 실시예에 따르면, 상기 단대단 라이프사이클 인프라스트럭처는 멀티테넌트 어플리케이션 서버 환경 내 상기 서로 다른 컴포넌트들이 고유의 컴포넌트-특정 라이프사이클 기능을 제공하기 위해 라이프사이클 플러그인을 사용할 수 있게 하는 플러그인-기반 메커니즘을 포함한다. 실시예에 따르면, 상기 시스템은 서비스에 대한 테넌트를 특정 파티션에 온보드하기 위해 사용될 수 있는 테넌트 온보딩 기능에 대한 지원을 포함한다. 실시예에 따르면, 상기 시스템은 상기 멀티-테넌트 어플리케이션 서버 환경 내에 글로벌 런타임의 상기 사용을 지원한다.

도 1은 실시예에 따르면, 멀티테넌트 어플리케이션 서버 환경을 도시한다.
도 2는 실시예에 따르면, 멀티테넌트 어플리케이션 서버 환경을 더 도시한다.
도 3은 실시예에 따르면, 멀티테넌트 어플리케이션 서버 환경을 더 도시한다.
도 4는 실시예에 따르면, 멀티테넌트 어플리케이션 서버 환경을 더 도시한다.
도 5는 실시예에 따르면, 멀티테넌트 어플리케이션 서버 환경을 더 도시한다.
도 6은 실시예에 따르면, 멀티테넌트 어플리케이션 서버 환경에서 단대단 라이프사이클을 도시한다.
도 7은 실시예에 따르면, 멀티테넌트 어플리케이션 서버 환경에서 단대단 라이프사이클 이벤트 다이어그램을 도시한다.
도 8은 실시예에 따르면, 멀티테넌트 어플리케이션 서버 환경에서 단대단 라이프사이클 토폴로지(topology)를 도시한다.
도 9는 실시예에 따르면, 멀티테넌트 어플리케이션 서버 환경에서 다른 단대단 라이프사이클 토폴로지를 도시한다.
도 10은 실시예에 따르면, 멀티테넌트 어플리케이션 서버 환경에서 단대단 라이프사이클을 제공하는 방법의 흐름도를 도시한다.
도 11은 실시예에 따르면, 멀티테넌트 어플리케이션 서버 환경에서 테넌트 온보딩을 도시한다.
도 12는 실시예에 따르면, 멀티테넌트 어플리케이션 서버 환경에서 테넌트 온보딩을 더 도시한다.
도 13은 실시예에 따르면, 멀티테넌트 어플리케이션 서버 환경에서 테넌트 온보딩을 제공하는 방법의 흐름도를 도시한다.
도 14는 실시예에 따르면, 멀티테넌트 어플리케이션 서버 환경에서 라이프사이클 플러그인들을 도시한다.
도 15는 실시예에 따르면, 멀티테넌트 어플리케이션 서버 환경에서 라이프사이클 플러그인들을 더 도시한다.
도 16은 실시예에 따르면, 멀티테넌트 어플리케이션 서버 환경에서 라이프사이클 플러그인들을 지원하는 방법의 흐름도를 도시한다.
도 17은 실시예에 따르면, 멀티테넌트 어플리케이션 서버 환경에서 글로벌 런타임의 사용을 도시한다.
도 18은 실시예에 따르면, 멀티테넌트 어플리케이션 서버 환경에서 글로벌 런타임의 사용을 더 도시한다.
도 19는 실시예에 따르면, 멀티테넌트 어플리케이션 서버 환경에서 글로벌 런타임을 지원하는 방법의 흐름도를 도시한다.

실시예에 따르면, 멀티테넌트 어플리케이션 서버 환경에서 단대단 라이프사이클을 제공하기 위한 시스템 및 방법이 본 명세서에 기술된다. 라이프사이클 관리자는 서로 다른 컴포넌트들, 예를 들어 고유의 파티션-특정 구성들을 갖는, 어플리케이션 서버들, 트래픽 디렉터들 또는 로드 밸런서들, 그리고 데이터베이스 또는 다른 컴포넌트들, 에 걸쳐서 구성 통합을 할 수 있게 한다.

실시예에 따르면, 상기 단대단 라이프사이클 인프라스트럭처는 멀티테넌트 어플리케이션 서버 환경 내에서 상기 서로 다른 컴포넌트들이 고유의 컴포넌트-특정 라이프사이클 기능을 제공하기 위해 라이프사이클 플러그인을 사용할 수 있게 하는 플러그인-기반 메커니즘을 포함한다.

실시예에 따르면, 상기 시스템은 서비스에 대한 테넌트를 특정 파티션에 온보드하기 위해 사용될 수 있는 테넌트 온보딩 기능에 대한 지원을 포함한다.

실시예에 따르면, 상기 시스템은 상기 멀티-테넌트 어플리케이션 서버 환경 내에 글로벌 런타임의 상기 사용을 지원한다.

어플리케이션 서버(예컨대, 멀티- 테넌트 , MT) 환경

도 1은 실시예에 따르면, 어플리케이션 서버, 클라우드 또는 다른 환경에서 멀티-테넌시를 지원하는 시스템을 도시한다.

도 1에 도시된 바와 같이, 실시예에 따르면, 어플리케이션 서버(예컨대, 멀티-테넌트, MT) 환경(100) 또는 소프트웨어 어플리케이션들의 상기 배포 및 실행을 할 수 있게 하는 다른 컴퓨팅 환경은, 어플리케이션 서버 도메인을 정의하기 위해 런타임 시 사용되는 도메인(102) 구성을 포함하고 이에 따라 동작하도록 구성될 수 있다.

실시예에 따르면, 상기 어플리케이션 서버는 런타임 시 사용하기 위해 정의되는 하나 이상의 파티션들(104)을 포함할 수 있다. 각각의 파티션은 전역 고유 파티션 식별자(ID)(globally unique partition identifier) 및 파티션 구성과 관련될 수 있고, 리소스 그룹 템플릿(126)에 대한 참조 및/또는 파티션-특정 어플리케이션들 또는 리소스들(128)을 포함하는 하나 이상의 리소스 그룹들(124)을 더 포함할 수 있다. 또한, 도메인-레벨 리소스 그룹들, 어플리케이션들 및/또는 리소스들(140)은 도메인 레벨에서 정의될 수 있고, 선택적으로 리소스 그룹 템플릿을 참조하여 도메인 레벨에서 정의될 수 있다.

각각의 리소스 그룹 템플릿(160)은 하나 이상의 어플리케이션들 A(162), B(164), 리소스들 A(166), B(168) 및/또는 다른 배포가능한 어플리케이션들 또는 리소스들(170)을 정의할 수 있고, 리소스 그룹에 의해 참조될 수 있다. 예를 들어, 도 1에 도시된 바와 같이, 파티션(104) 내의 리소스 그룹(124)은 리소스 그룹 템플릿(160)을 참조(190)할 수 있다.

일반적으로, 시스템 관리자는 파티션들, 도메인-레벨 리소스 그룹들 및 리소스 그룹 템플릿들 및 보안 영역들(security realms)을 정의할 수 있으며, 파티션 관리자는 예를 들어, 파티션-레벨 리소스 그룹들을 생성하는 것, 파티션에 어플리케이션들을 배포하는 것 또는 상기 파티션에 대한 특정 영역들을 참조하는 것에 의해, 고유의 파티션의 양상들을 정의할 수 있다.

도 2는 실시예에 따르면, 어플리케이션 서버, 클라우드 또는 다른 환경에서 멀티-테넌시를 지원하는 시스템을 더 도시한다.

도 2에 도시된 바와 같이, 실시예에 따르면, 파티션(202)은 예를 들어, 리소스 그룹 템플릿(210)에 대한 참조(206)를 포함하는 리소스 그룹(205), 가상 타겟(예컨대, 가상 호스트) 정보(207) 및 플러그가능 데이터베이스(pluggable database)(PDB) 정보(208)를 포함할 수 있다. 리소스 그룹 템플릿(예컨대, 210)은 예를 들어, 자바 메시지 서버(JMS) 서버(213), 축적 전송(store-and-forward )(SAF) 에이전트(215), 메일 세션 컴포넌트(216) 또는 자바 데이터베이스 연결(JDBC) 리소스(217)과 같은 리소스들과 함께 복수의 어플리케이션들 A(211) 및 B(212)를 정의할 수 있다.

도 2에 도시된 상기 리소스 그룹 템플릿이 예로서 제공되며, 다른 실시예들에 따르면, 서로 다른 타입들의 리소스 그룹 템플릿들 및 요소들이 제공될 수 있다.

실시예에 따르면, 파티션(예컨대, 202) 내의 리소스 그룹이 특정한 리소스 그룹 템플릿(예컨대, 210)을 참조(220)할 때, 특정한 파티션과 관련된 정보는 파티션-특정 정보(230), 예를 들어 파티션-특정 PDB 정보를 표시하기 위해, 상기 참조된 리소스 그룹 템플릿과 조합하여 사용될 수 있다. 그 다음, 상기 파티션-특정 정보는 상기 파티션에 의해 사용하기 위한 리소스들, 예를 들어 PDB 리소스를 구성하기 위해 상기 어플리케이션 서버에 의해 사용될 수 있다. 예를 들어, 파티션(202)과 관련된 파티션-특정 PDB 정보는 해당 파티션에 의해 사용하기 위한 컨테이너 데이터베이스(CDB)(236)를 적절한 PDB(238)와 함께 구성(232)하기 위해 상기 어플리케이션 서버에 의해 사용될 수 있다.

유사하게, 실시예에 따르면, 특정한 파티션과 관련된 가상 타겟 정보는 상기 파티션에 의해 사용하기 위한 파티션-특정 가상 타겟(240), 예컨대, baylandurgentcare.com, 을 정의(239)하기 위해 사용될 수 있는 바, 이는 그

다음, URL(uniform resource locator), 예컨대, http://baylandurgentcare.com을 통해 액세스가능하게 될 수 있다.

도 3은 실시예에 따르면, 어플리케이션 서버, 클라우드 또는 다른 환경에서 멀티-테넌시를 지원하는 시스템을 더 도시한다.

실시예에 따르면, config.xml 구성 파일과 같은 시스템 구성은 파티션을 정의하는데 사용되며, 이 시스템 구성은 해당 파티션 및/또는 다른 파티션 프로퍼티(property)들과 관련된 리소스 그룹들에 대한 구성 요소들을 포함한다. 값들은 프로퍼티 이름/값 쌍들을 사용하여 파티션 마다 특정될 수 있다.

실시예에 따르면, 복수의 파티션들은 관리 서버/클러스터(242) 내에서 또는 CDB(243)로의 액세스를 제공할 수 있고 웹 티어(web tier)(244)를 통해 액세스가능한 유사한 환경 내에서 실행될 수 있다. 이는, 예를 들어, 도메인 또는 파티션이 (상기 CDB의) 상기 PDB들 중 하나 이상과 관련되도록 한다.

실시예에 따르면, 이 예시 파티션 A(250) 및 파티션 B(260)에서 상기 복수의 파티션들 각각은 그 파티션과 관련된 복수의 리소스들을 포함하도록 구성될 수 있다. 예를 들어, 파티션 A는 어플리케이션 A1(252), 어플리케이션 A2(254) 및 PDB A(259)와 관련된 데이터 소스 A(257)를 포함한 JMS A(256)를 포함하는 리소스 그룹(251)을 포함하도록 구성될 수 있고, 상기 파티션은 가상 타겟 A(258)를 통해 액세스가능하다. 유사하게, 파티션 B(260)는 어플리케이션 B1(262), 어플리케이션 B2(264) 및 PDB B(269)와 관련된 데이터소스 B(266)를 포함한 JMS B(266)를 포함하는 리소스 그룹(261)을 포함하도록 구성될 수 있고, 상기 파티션은 가상 타겟 B(268)을 통해 액세스 가능하다.

상기 여러 예들은 CDB 및 PDB들의 사용을 도시하지만, 다른 실시예들에 따르면, 다른 타입들의 멀티-테넌트 또는 비-멀티테넌트(non-multi-tenant) 데이터베이스들이 지원될 수 있고, 예를 들어 스키마들(schemas)의 상기 사용 또는 서로 다른 데이터베이스들의 상기 사용을 통해 특정한 구성이 각각의 파티션에 대해 제공될 수 있다.

리소스들

실시예에 따르면, 리소스는 상기 환경의 도메인에 대해 배포될 수 있는 시스템 리소스, 어플리케이션 또는 다른 리소스 또는 객체이다. 예를 들어, 실시예에 따르면, 리소스는 서버, 클러스터 또는 다른 어플리케이션 서버 타겟에 대해 배포될 수 있는 어플리케이션, JMS, JDBC, 자바메일, WLDF, 데이터 소스 또는 다른 시스템 리소스 또는 다른 타입의 객체일 수 있다.

파티션들

실시예에 따르면, 파티션은, 파티션 식별자(ID) 및 구성과 관련될 수 있고, 어플리케이션들을 포함할 수 있고 그리고/또는 리소스 그룹들 및 리소스 그룹 템플릿들의 상기 사용을 통해 도메인-와이드 리소스(domain-wide resource)들을 참조할 수 있는 도메인의 런타임 및 관리 서브디비전 또는 슬라이스이다.

일반적으로, 파티션은 고유의 어플리케이션들을 포함하고, 리소스 그룹 템플릿들을 통해 도메인 와이드 어플리케이션들을 참조하며, 고유의 구성을 가질 수 있다. 파티션가능한 엔티티(Partitionable entity)들은 리소스들, 예를 들어 JMS, JDBC, 자바메일, WLDF 리소스들, 및 JNDI 네임스페이스, 네트워크 트래픽, 작업 관리자들 및 보안 정책 및 영역들과 같은 다른 컴포넌트들을 포함할 수 있다. 멀티-테넌트 환경의 맥락에서, 상기 시스템은 테넌트와 관련된 파티션들의 상기 관리 및 런타임 양상들로의 테넌트 액세스를 제공하도록 구성될 수 있다.

실시예에 따르면, 파티션 내의 각각의 리소스 그룹은 리소스 그룹 템플릿을 선택적으로 참조할 수 있다. 파티션은 다수의 리소스 그룹들을 가질 수 있고, 다수의 리소스 그룹들 각각은 리소스 그룹 템플릿을 참조할 수 있다. 각각의 파티션은 상기 파티션의 리소스 그룹들이 참조하는 상기 리소스 그룹 템플릿들에서 특정되지 않는 구성 데이터에 대한 프로퍼티들을 정의할 수 있다. 이는 파티션이 그 파티션에서 사용할 특정값들에 대한 리소스 그룹 템플릿에 정의된 배포가능한 리소스들의 바인딩으로서 역할을 하게 한다. 일부 케이스들에서, 파티션은 리소스 그룹 템플릿에 의해 특정되는 구성 정보를 오버라이드(override)할 수 있다.

실시예에 따르면, 예를 들어 config.xml 구성 파일에 의해 정의된 파티션 구성은 복수의 구성 요소들, 예를 들어, 상기 파티션을 정의하는 상기 어트리뷰트(attribute)들 및 차일드 요소들을 포함하는 "파티션", 상기 파티션에 대해 배포되는 상기 어플리케이션들 및 리소스들을 포함하는 "리소스 그룹", 해당 템플릿에 의해 정의되는 어플리케이션들 및 리소스들을 포함하는 "리소스 그룹 템플릿", 데이터베이스-특정 서비스 이름, 사용자 이름 및 패스워드를 포함하는 "jdbc-시스템-리소스-오버라이드" 및 리소스 그룹 템플릿들 내의 매크로 교체(macro replacement)를 위해 사용될 수 있는 프로퍼티 키 값들을 포함하는 "파티션-프로퍼티들"을 포함할 수 있다.

스타트업 시, 상기 시스템은 상기 리소스 그룹 템플릿으로부터 각각의 리소스에 대한 파티션-특정 구성 요소들을 생성하기 위해 상기 구성 파일에 의해 제공되는 상기 정보를 사용할 수 있다.

리소스 그룹들

실시예에 따르면, 리소스 그룹은 도메인 또는 파티션 레벨에서 정의될 수 있고, 리소스 그룹 템플릿을 참조할 수 있는 배포가능한 리소스들의 명명된, 완전히 적격한 집합(named, fully-qualified collection)이다. 리소스 그룹 내의 상기 리소스들은 상기 관리자가 시작 또는 상기 리소스들에 연결하기 위해 필요한 모든 상기 정보, 예를 들어 데이터 소스에 연결하기 위한 상기 크리덴셜(credential)들 또는 어플리케이션에 대한 상기 타겟팅 정보를 제공했다는 점에서 완전히 적격한 것으로 고려된다.

시스템 관리자는 상기 도메인 레벨에서 또는 상기 파티션 레벨에서 리소스 그룹들을 선언할 수 있다. 상기 도메인 레벨에서, 리소스 그룹은 그룹 관련 리소스들에 편리한 방식을 제공한다. 상기 시스템은 비그룹화된 리소스들과 동일하게 도메인-레벨 리소스 그룹에서 선언된 리소스들을 관리할 수 있어서, 상기 리소스들은 시스템 스타트업 동안 시작되고, 시스템 셧-다운 동안 정지될 수 있다. 관리자는 또한, 그룹 내의 리소스를 개별적으로 정지, 시작 또는 제거할 수 있고, 상기 그룹상에서 동작함으로써 묵시적으로 상기 그룹 내의 모든 상기 리소스들에 영향을 줄 수 있다. 예를 들어, 리소스 그룹을 정지시키는 것은 아직 정지되지 않은 상기 그룹 내의 상기 모든 리소스들을 정지시키고, 상기 리소스 그룹을 시작시키는 것은 아직 시작되지 않은 상기 그룹 내의 임의의 리소스들을 시작시키며, 상기 리소스 그룹을 제거하는 것은 상기 그룹에 포함된 상기 모든 리소스들을 제거한다.

상기 파티션 레벨에서, 시스템 또는 파티션 관리자는 임의의 보안 제약들의 대상이 되는 파티션 내의 0개 이상의 리소스 그룹들을 구성할 수 있다. 예를 들어, SaaS 사용 케이스에서, 다양한 파티션-레벨 리소스 그룹들은 도메인-레벨 리소스 그룹 템플릿들을 참조할 수 있고, 반면 PaaS 사용 케이스에서, 리소스 그룹 템플릿을 참조하는 것이 아니라, 대신에 해당 파티션 내에서만 이용가능해지는 이들의 관련 리소드들 및 어플리케이션들을 표시하는 파티션-레벨 리소스 그룹들이 생성될 수 있다.

실시예에 따르면, 리소스 그룹핑은 어플리케이션들 및 이들이 상기 도메인 내에서 별개의 관리 유닛으로서 사용하는 상기 리소스들을 함께 그룹하기 위해 사용될 수 있다. 예를 들어, 하기 기술되는 의료 기록들(MedRec) 어플리케이션에서, 리소스 그룹핑은 상기 MedRec 어플리케이션 및 이의 리소스들을 정의한다. 다수의 파티션들은 각각의 파티션-특정 구성 정보를 사용하여 상기 동일한 MedRec 리소스 그룹을 실행할 수 있어서, 각각의 MedRec 인스턴스의 일부인 상기 어플리케이션들은 각각의 파티션에 특정되게 된다.

리소스 그룹 템플릿들

실시예에 따르면, 리소스 그룹 템플릿은 리소스 그룹으로부터 참조될 수 있는 도메인 레벨에서 정의되는 배포가능한 리소스들의 집합이고, 이의 리소스들을 활성화시키기 위해 요구되는 상기 정보의 일부는 상기 템플릿 자체의 일부로서 저장되지 않을 수 있으면 이것은 파티션 레벨 구성의 상기 사양(specification)을 지원한다. 도메인은 임의의 수의 리소스 그룹 템플릿들을 포함할 수 있고, 이들 각각은 예를 들어, 하나 이상의 관련 자바 어플리케이션들 및 상기 어플리케이션들에 종속되는 상기 리소스들을 포함할 수 있다. 상기 리소스들에 관한 상기 정보의 일부는 모든 파티션들에 걸쳐 동일할 수 있고, 반면 다른 정보는 파티션마다 다양할 수 있다. 모든 구성이 도메인 레벨에서 특정될 필요는 없는바 - 대신 파티션 레벨 구성이 매크로들 또는 프로퍼티 이름/값 쌍들의 상기 사용을 통해 상기 리소스 그룹 템플릿에 특정될 수 있다.

실시예에 따르면, 특정한 리소스 그룹 템플릿은 하나 이상의 리소스 그룹들에 의해 참조될 수 있다. 일반적으로, 어떤 임의의 파티션 내에서, 리소스 그룹 템플릿은 한 번에 하나의 리소스 그룹에 의해 참조될 수 있는바, 즉 상기 동일한 파티션 내에서 다수의 리소스 그룹들에 의해 동시에 참조될 수 없다. 그러나, 이는 서로 다른 파티션 내의 다른 리소스 그룹에 의해 동시에 참조될 수 있다. 상기 리소스 그룹을 포함하는 상기 객체, 예컨대 상기 도메인 또는 파티션은 상기 리소스 그룹 템플릿 내의 임의의 토큰들의 값을 설정하기 위해 프로퍼티 이름/값 할당들을 사용할 수 있다. 상기 시스템이 참조 리소스 그룹을 사용하여 리소스 그룹 템플릿을 활성화시킬 때, 이는 상기 토큰들을 리소스 그룹의 포함 객체에 설정된 값들과 교체할 수 있다. 일부 케이스들에서, 상기 시스템은 또한, 각각의 파티션/템플릿 조합에 대한 런타임 구성을 생성하기 위해 통계적으로 구성된 리소스 그룹 템플릿들 및 파티션들을 사용할 수 있다.

예를 들어, SaaS 사용 케이스에서, 상기 시스템은 상기 동일한 어플리케이션들 및 리소스들을 여러번 활성화시킬 수 있으며, 이는 이 어플리케이션들 및 리소스들을 사용할 각각의 파티션에 대해 한번씩 활성화시키는 것을 포함한다. 관리자가 리소스 그룹 템플릿을 정의할 때, 이들은 다른 곳에 공급될 상기 정보를 표시하기 위해 토큰들을 사용할 수 있다. 예를 들어, CRM-관련 데이터 리소스에 연결할 시 사용하기 위한 상기 사용자이름이 ＼${CRMDataUsername}로서 상기 리소스 그룹 템플릿에 표시될 수 있다.

테넌트들

실시예에 따르면, 멀티-테넌트(MT) 어플리케이션 서버 환경과 같은 멀티-테넌트 환경에서, 테넌트는 하나 이상의 파티션들 및/또는 하나 이상의 테넌트-인지 어플리케이션들에 의해 표현될 수 있거나 또는 이와 달리 하나 이상의 파티션들 및/또는 하나 이상의 테넌트-인지 어플리케이션들과 관련될 수 있는 엔티티이다.

예를 들어, 테넌트들은 서로 다른 외부의 회사들 또는 특정 기업 내의 서로 다른 부서들(예컨대, HR 및 재무 부서들)과 같은 별개의 사용자 조직들을 표현할 수 있고, 이들 각각은 서로 다른 파티션과 관련될 수 있다. 테넌트 전역 고유 신원(tenant globally unique identity)(테넌트 ID)은 특정한 시점에 특정한 테넌트와의 특정한 사용자의 상기 관련성이다. 상기 시스템은 예를 들어, 사용자 신원 스토어를 참조하는 것에 의해 특정한 사용자가 어느 테넌트에 속하는지를 상기 사용자 신원으로부터 도출할 수 있다. 상기 사용자 신원은 상기 시스템으로 하여금, 이들로만 한정되는 것은 아니지만, 상기 사용자가 속할 수 있는 테넌트를 포함하여 사용자가 수행하도록 인가된 상기 동작들을 실시할 수 있게 한다.

실시예에 따르면, 상기 시스템은 서로 다른 테넌트들의 상기 관리 및 런타임이 서로 격리되게 한다. 예를 들어, 테넌트들은 자신의 어플리케이션들 및 이들이 엑세스할 수 있는 리소스들의 일부 행동들을 구성할 수 있다. 상기 시스템은 특정한 테넌트가 다른 테넌트에 속하는 아티팩트(artifact)들을 관리할 수 없게 보장할 수 있고, 런타임 시 특정한 테넌트 대신 작동하는 상기 어플리케이션들이 그 테넌트와 관련된 리소스들만 참조하고 다른 테넌트들과 관련된 리소스들을 참조하지 못하게 할 수 있다.

실시예에 따르면, 테넌트-비인지 어플리케이션은 테넌트들을 명시적으로 다루는 로직을 포함하지 않는 어플리케이션이어서, 상기 어플리케이션이 사용하는 임의의 리소스들은 어떤 사용자가 상기 어플리케이션이 응답하는 요청을 제출했는지에 관계없이 액세스가능할 수 있다. 대조적으로, 테넌트-인지 어플리케이션은 테넌트들을 명시적으로 다루는 로직을 포함한다. 예를 들어, 사용자의 신원에 기초하여, 상기 어플리케이션은 상기 사용자가 속하는 상기 테넌트를 도출할 수 있고, 해당 정보를 테넌트-특정 리소스들에 액세스하기 위해 사용할 수 있다.

실시예에 따르면, 상기 시스템은 사용자들이 테넌트-인지하도록 명시적으로 기록된 어플리케이션들을 배포할 수 있게 하며, 따라서 어플리케이션 개발자들은 현재 테넌트의 상기 테넌트 ID를 획득할 수 있다. 그 다음, 상기 테넌트-인지 어플리케이션은 상기 어플리케이션의 단일 인스턴스를 사용하는 다수의 테넌트들을 처리하기 위해 상기 테넌트 ID를 사용할 수 있다.

예를 들어, 단일 의사의 사무실 또는 병원을 지원하는 상기 MedRec 어플리케이션은 두 개의 서로 다른 파티션들 또는 테넌트들, 예컨대 Bayland Urgent Care 테넌트 및 Valley Health 테넌트에 노출될 수 있으며, 이들 각각은 상기 기초 어플리케이션 코드를 변경함이 없이, 별개의 PDB들과 같은 별개의 테넌트-특정 리소스들에 액세스할 수 있다.

대표적인 도메인 구성 및 멀티-테넌트 환경

실시예에 따르면, 어플리케이션들은 상기 도메인 레벨에서 리소스 그룹 템플릿에 대해 또는 파티션 범위의(scoped to) 또는 상기 도메인 범위의 리소스 그룹에 대해 배포될 수 있다. 어플리케이션 구성은 어플리케이션마다 또는 파티션마다 특정되는 배포 계획들을 사용하여 오버라이드될 수 있다. 배포 계획들은 또한 리소스 그룹의 일부로 특정될 수 있다.

도 4는 실시예에 따르면, 대표적인 멀티-테넌트 환경에서 사용하기 위한 도메인 구성을 도시한다.

실시예에 따르면, 상기 시스템이 파티션을 시작할 때, 이는 상기 제공되는 구성에 따라, 각각의 데이터베이스 인스턴스들에 대해, 가상 타겟들(예컨대, 가상 호스트들) 및 연결 풀들을 각각의 파티션에 대한 것을 포함하여 생성한다.

전형적으로, 각각의 리소스 그룹 템플릿은 하나 이상의 관련 어플리케이션들 및 상기 어플리케이션들이 종속되는 상기 리소스들을 포함할 수 있다. 각각의 파티션은 상기 파티션과 관련된 특정 값들에 리소스 그룹 템플릿들 내의 상기 배포가능한 리소스들의 바인딩을 제공하는 것에 의해 상기 파티션이 참조하는 상기 리소스 그룹 템플릿들에 특정되지 않은 구성 데이터를 제공할 수 있으며, 일부 케이스들에서, 상기 리소스 그룹 템플릿에 의해 특정된 어떤 구성 정보를 오버라이드하는 것을 포함한다. 이는 상기 시스템이 각각의 파티션이 정의한 상기 프로퍼티 값들을 사용하여 각각의 파티션에 대해 서로 다르게 리소스 그룹 템플릿에 의해 표현되는 어플리케이션을 활성화시킬 수 있게 한다.

일부 예들에서, 파티션은 리소스 그룹 템플릿들을 참조하지 않거나 또는 고유의 파티션 범주의 배포가능한 리소스들을 직접적으로 정의하는 리소스 그룹들을 포함할 수 있다. 파티션 내에 정의되는 어플리케이션들 및 데이터 소스들은 일반적으로 해당 파티션에만 이용가능하다. 리소스들은 파티션: <partitionName>/<resource JNDI name>, 또는 domain:<resource JNDI name>를 사용하여 파티션들에 걸쳐 액세스될 수 있도록 배포될 수 있다.

예를 들어, MedRec 어플리케이션은 복수의 자바 어플리케이션들, 데이터 소스, JMS 서버 및 메일 세션을 포함할 수 있다. 다수의 테넌트들에 대한 상기 MedRec 어플리케이션을 실행하기 위해, 상기 시스템 관리자는 단일 MedRec 리소스 그룹 템플릿(286)을 정의할 수 있고, 상기 템플릿에 상기 배포가능한 리소스들을 선언할 수 있다.

도메인 레벨의 배포가능한 리소스들과는 대조적으로, 리소스 그룹 템플릿에 선언된 상기 배포가능한 리소스들은 상기 템플릿에 완전히 구성되지 않을 수 있거나 또는 있는 그대로 활성화되지 못할 수 있는바, 그 이유는 이 리소스들에 일부 구성 정보가 결여되어 있기 때문이다.

예를 들어, 상기 MedRec 리소스 그룹 템플릿은 상기 어플리케이션들에 의해 사용되는 데이터 소스를 선언할 수 있지만, 이는 상기 데이터베이스에 연결하기 위한 URL을 특정하지 않을 수 있다. 서로 다른 테넌트들과 관련된 파티션들, 예를 들어 파티션 BUC-A(290)(Bayland Urgent Care, BUC) 및 파티션 VH-A(292)(Valley Health, VH)는 상기 MedRec 리소스 그룹 템플릿을 참조(296, 297)하는 MedRec 리소스 그룹(293, 294)을 각각 포함하는 것에 의해 하나 이상의 리소스 그룹 템플릿들을 참조할 수 있다. 그 다음, 상기 참조는 상기 Bayland Urgent Care 테넌트가 사용하기 위한 BUC-A 파티션과 관련된 가상 호스트 baylandurgentcare.com(304) 및 상기 Valley Health 테넌트가 사용하기 위한 상기 VH-A 파티션과 관련된 가상 호스트 valleyhealth.com(308)를 포함하는, 각각의 테넌트에 대한 상기 가상 타겟들/가상 호스트들을 생성(302, 306)하기 위해 사용될 수 있다.

도 5는 실시예에 따르면, 대표적인 멀티-테넌트 환경을 더 도시한다. 도 5에 도시된 바와 같이, 그리고 두 파티션들이 상기 MedRec 리소스 그룹 템플릿을 참조하는 상기 예에 이어, 실시예에 따르면, 서블릿 엔진(310)이 복수의 테넌트 환경들, 이 예에서는 Bayland Urgent Care Physician 테넌트 환경(320) 및 Valley Health Physician 테넌트 환경(330)을 지원하기 위해 사용될 수 있다.

실시예에 따르면, 각각의 파티션(321, 331)은 해당 테넌트 환경에 대해 유입 트래픽을 수락하기 위한 서로 다른 가상 타겟, 및 파티션 및 이의 리소스들(324, 334) 에 연결하기 위한 서로 다른 URL(322, 332)를 정의할 수 있으며 이 예에서는 bayland urgent care 데이터베이스 또는 valley health 데이터베이스를 각각 포함한다. 상기 데이터베이스 인스턴스들은 호환가능한 스키마를 사용할 수 있고, 이는 상기 동일한 어플리케이션 코드가 두 데이터베이스들에 대해 실행될 것이기 때문이다. 상기 시스템이 상기 파티션들을 시작할 때, 이는 상기 가상 타겟들, 및 상기 각각의 데이터베이스 인스턴스들로의 연결 풀들을 생성할 수 있다.

단대단 라이프사이클

실시예에 따르면, 멀티-테넌트 어플리케이션 서버 환경에서 단대단 라이프사이클을 제공하기 위한 시스템 및 방법이 본 명세서에 기술된다. 라이프사이클 관리자는 서로 다른 컴포넌트들, 예를 들어 고유의 파티션-특정 구성들을 갖는, 어플리케이션 서버들, 트래픽 디렉터들 또는 로드 밸런서들, 그리고 데이터베이스 또는 다른 컴포넌트들에 걸쳐서 구성 통합을 할 수 있게 한다.

다양한 실시예들에 따라, 본 명세서에서 제공되는 상기 단대단 라이프사이클 프로세스의 일부 설명들은 다음 용어들을 사용한다 :

테넌시 : 테넌트의 제한된 기간 동안 전형적으로 얻어진 상기 시스템의 컴포넌트를 사용하여 테넌트가 그들의 필요들에 어느정도 맞게 상기 시스템의 상기 동작들을 커스터마이즈할 수 있게 한다.

테넌시 컨텍스트 : 상황별 정보, 예를 들어 시스템의 상기 테넌시를 결정하는데 사용되는 보안, 네이밍 또는 클래스 로딩 정보로써, 상기 시스템은 해당 테넌시 컨텍스트를 사용하여 청구서들 생성과 같은 테넌트-특정 동작을 제공할 수 있다.

파티션 컨텍스트 : 플랫폼 테넌시를 결정하기 위해 상기 시스템이 사용할 수 있는 현재 실행 스레드와 관련된 파티션 식별자(ID).

리소스 테넌시 : 오라클 퓨전 미들웨어(FMW) / 퓨전 어플리케이션(FA) 실시예들을 기술할 때 주로 사용되는 "테넌시"와 유사한 프로퍼티.

MT 어드민 코드 : 테넌트 런타임들뿐만 아니라 상기 시스템의 라이프사이클 관리를 담당하는, 임의의 테넌트가 멀티테넌트 시스템에 온보드되기 전 배포되고 활성화되는 코드.

MT 어드민 런타임 : 상기 MT 어드민 코드의 런타임 표현.

테넌트 코드 : 테넌트에 대해 구체적으로 배포된 코드.

테넌트 런타임 : 상기 테넌트 코드의 런타임 표현.

계층화된 제품들 : 예로 FMW 및 FA 제품군들을 포함할 수 있는, 멀티테넌트 어플리케이션 서버 환경과 상호작용하거나 이와 달리 멀티테넌트 어플리케이션 서버 환경을 사용할 수 있는 소프트웨어 제품들.

도 6은 실시예에 따르면, 멀티테넌트 어플리케이션 서버 환경에서 단대단 라이프사이클을 도시한다.

도 6에 도시된 바와 같이, 실시예에 따르면, 상기 시스템은, 상기 멀티테넌트 어플리케이션 서버 환경 내에서 사용하기 위해 파티션 및 다른 컴포넌트들, 예를 들어 트래픽 디렉터 컴포넌트(414), 데이터베이스 컴포넌트(415), 또는 다른 유형들의 컴포넌트들(416), 의 라이프사이클의 관리(412)를 가능하게 하는 라이프사이클 관리자(LCM) (410) 및 라이프사이클 인터페이스(411)를 포함하는 라이프사이클 조정 프레임워크(400)를 포함할 수 있다.

예를 들어, 어플리케이션 서버 (예 : WebLogic, WLS) 컴포넌트가 멀티테넌트-인지이도록 상기 어플리케이션 서버 내에서 파티션들의 상기 사용을 지원하는 것에 더하여, 상기 시스템은 다른 컴포넌트들 및 제품들이 어플리케이션 서버 파티션들과 상호동작하는 것, 예를 들어 데이터베이스(예컨대, 오라클 데이터베이스, DB) 및 트래픽 디렉터 또는 로드 밸런서(예컨대, 오라클 트래픽 디렉터, OTD) 인스턴스들이 적절하게 구성될 수 있고, 그에 따라 상기 파티션들을 유사하게 지원할 수 있는 것을 보장할 수 있어야 한다.

이를 해결하기 위해, 실시예에 따르면, 어플리케이션 서버에서 사용하기 위한 파티션을 생성하는 것의 일부로서, 상기 어플리케이션 서버 파티션을 생성하는 것에 더하여 그 다음, 상기 시스템은 궁극적으로 상기 어플리케이션 서버 파티션과 연결된 다른 컴포넌트들에서 런타임의 슬라이스를 생성하게 할 수 있다. 그 결과 어플리케이션이 예컨대, OTD 계층으로부터 자신의 환경 내에서 데이터베이스 계층까지 완전히 실행될 수 있는 시스템이 된다.

실시예에 따르면, 상기 단대단 라이프사이클 인프라스트럭처는 멀티-테넌트 어플리케이션 서버 환경 내 복수의 서로 다른 컴포넌트들이 고유의 컴포넌트-특정 라이프사이클 기능을 제공하기 위해 라이프사이클 플러그인을 사용할 수 있게 하는 플러그인-기반 메커니즘을 포함한다. 파티션에 연결하기 위해 사용할 수 있는 임의의 컴포넌트는 자체 플러그인을 제공할 수 있다. 그 다음, 라이프사이클 동작들은 차례로 상기 컴포넌트의 상기 실제 생성(예를 들어, 트래픽 디렉터 인스턴스의 상기 생성 또는 데이터베이스 인스턴스 상기 생성)을 적절하게 수행하는 상기 플러그인 인터페이스를 호출할 수 있다.

실시예에 따르면, 어플리케이션 서버 및/또는 컴포넌트 파티션들을 생성하는 것에 더하여, 각각의 테넌트는 후술되는바와 같이, 환경과 관련될수 있으며, 상기 환경은 파티션의 상기 테넌트가 고유의 어플리케이션들을 실행할 수 있는 컨테이너 또는 컨테이너 객체로서 동작한다.

예를 들어, 실시예에 따르면, 상기 라이프사이클관리자와 이것의 플러그가능 확장 메커니즘은 상기 미들웨어 또는 데이터베이스 스택 내의 컴포넌트들의 상기 생성을 지원하기 위해, 그리고 또한 데이터소스를 사용하기 위해 어플리케이션 서버(예컨대, WLS) 파티션을 연결하는 것과 같은, 해당 컴포넌트들의 상기 연결을 지원하기 위해 사용될 수 있다. 그 다음 유선 컴포넌트들의 상기 집합은 파티션 또는 테넌트 환경에 제공될 수 있다.

다른 예로서, 실시예에 따르면, 상기 시스템은 어플리케이션 서버 파티션을 데이터베이스와 관련되게 할 수 있고, 라이프사이클 동안 생성되어, 상기 어플리케이션 서버 파티션에서 데이터소스를 생성하고, 그것이 파티션 또는 테넌트 환경에서 이용가능하게 한다.

유사하게, 실시예에 따르면, 상기 라이프사이클 관리자는 상기 파티션과 함께 사용하기 위한 URI 또는 호스트 이름 설정을 포함하는, 파티션에 대한 OTD 라우팅을 설정하는데 사용될 수 있으며, 따라서 클러스터에서 실행되는 WLS 파티션이 OTD 인스턴스와 프론트-엔드되도록하고, 한편 상기 라이프사이클 관리자는 테넌트 환경 내에서 사용하기 위해, 상기 파티션에 대한 OTD 인스턴스의 상기 생성 및 상기 WLS 파티션과의 연결을 가능하게 한다.

상기 단대단 라이프사이클 관리에 의해 제공되는 추가 이점들은 대역 외 변경들을 검출하는 상기 기능을 포함한다.

예를 들어, 어플리케이션 서버 파티션에 대한 업데이트는 해당 파티션에 연결된 다른 컴포넌트들로 송신될 수 있다. 다른 예로서, 새 리소스 그룹이 새 타겟과 관련될 때, 해당 업데이트된 정보는 다른 계층화된 제품들로 송신될 수 있으며, 따라서 상기 파티션의 상기 변경들이 다른 연결된 컴포넌트들로 전파된다.

실시예에 따르면, 상기 라이프사이클의 오케스트레이션은 상기 다양한 컴포넌트들 또는 런타임의 슬라이스들을 생성하기 위한 다양한 방법들로 수행될 수 있다. 예를 들어, 상기 시스템은 상기 라이프사이클 관리자에게 REST 호출들로서 파티션, PDB, 그리고 OTD 인스턴스를 개별적으로 생성할 수 있으며, 상기 라이프사이클 관리자는 예컨대, WLS 파티션을 생성하고, OTD 인스턴스 또는 다른 컴포넌트들의 슬라이스들을 생성하도록 지시한다. 오케스트레이션 중에, 실패가 발생하면, 상기 시스템은, 예를 들어 고유의 아티팩트들을 관련시키고 오케스트레이션하기 위해 상기 REST 엔드포인트를 다시 시도하는 것에 의해, 이를 수용할 수 있다.

대표적인 단대단 라이프사이클 사용 케이스들은 클러스터 내의 어드민 서버상에 라이프사이클 관리자 및/또는 상기 클러스터 내의 관리 서버들상에 다른 라이프사이클 관리자들을 제공하는 것을 포함한다. 예를 들어, 단일 도메인에서, 단일 라이프사이클 관리자는 상기 어드민 서버상 제공될 수 있다. 라이프사이클 관리자가 예컨대, 다수의 서버들상에 다수의 OTD 인스턴스들을 관리할 수 있는, 다수의 도메인들 또는 고-가용성 요구 모델들을 위해, 상기 라이프사이클 관리자는 로드 밸런서에 의해 고유의 프론트-엔드된 클러스터 내에서 실행될 수 있으며, 해당 도메인으로부터 상기 라이프사이클 관리자는 다수의 런타임들을 관리할 수 있다.

실시예에 따르면, 상기 단대단 라이프사이클 구성 정보는, 예를 들어 단일 도메인 모드의 XML 파일 또는 고-가용성 모드의 더 전형적인 데이터베이스에 저장될 수 있다.

실시예에 따르면, 상기 라이프사이클 관리자는 상기 호출 세부사항들에서 의도된 파티션을 결정하고 호출이 생성하려고 시도하는 것에 기초하여, 하나 이상의 적절한 플러그인들을 호출하는, 등록된 런타임과 함께 사용하기 위해, 예컨대 REST를 통한 호출을 수신한 것에 응답하여, 특정 파티션을 대신하여 작동하고 있음을 인식할 수 있다.

예를 들어, 상기 호출이 파티션에 대한 PDB 생성을 지시하는 경우, 그 다음 상기 라이프사이클 관리자는 상기 데이터베이스 라이프사이클 플러그인을 호출하는 것으로 응답할 수 있다. 또는 상기 호출이 파티션에 대한 OTD 인스턴스 생성을 지시하는 경우, 그 다음 상기 라이프사이클 관리자는 상기 OTD 라이프사이클 플러그인 등등을 호출하는 것으로 응답할 수 있다.

단일 도메인 다중 파티션 환경에서, 라이프사이클 관리자 기능을 제공하고 있던 어드민 서버가 장애발생하면(fail), 비록 이것의 관리 및 관리 기능이 일정 기간동안 활성화되지 않을 수 있지만, 상기 시스템은 종래의 어플리케이션 서버(예컨대, WLS) 서버 환경으로서 계속 동작할 수 있다.

실시예에 따르면, 상기 시스템은 계약들 및 상기 계약들의 구현들을 서비스들로서 조회하기 위해 HK2를 종속성 주입 메커니즘(dependency injection mechanism)으로서 사용할 수 있다. 예를 들어, HK2의 사용으로, 서비스들은 컴포넌트들에 주입될 수 있고, 일단 주입되면, 그 HK2 객체들은 다른 클래스들의 상기 종속성들을 만족시킬 수 있다. 라이프사이클 플러그인들은 HK2 서비스들로서 구현될 수 있고 런타임에 그들의 계약을 구현한다. 상기 시스템은 서비스들로서 플러그인된 적절한 플러그인들을 찾기 위해 계약을 조회할 수 있다.

예를 들어, 실시예에 따르면, 상기 시스템은 파티션 플러그인 계약 또는 런타임 플러그인 또는 기타 계약을 인식할 수 있다. 각각의 파티션 또는 다른 플러그인은 해당 컴포넌트 내의 파티션 또는 파티션의 슬라이스를 생성하는 동작을 이해하여 구성할 수 있으며, 예를 들어, 데이터베이스의 슬라이스를 생성하는 동작을 이해하여 데이터베이스 파티션 플러그인을 구성할 수 있다.

실시예에 따르면, 상기 시스템은 호출(예컨대, "타입=데이터베이스") 중에 요구되는 상기 서비스의 타입에 대한 표시를 수신할 수 있고, 그 다음, 이 케이스에서 적절한 사용된 데이터베이스 플러그인을 결정할 수 있다.

유사하게, 실시예에 따르면, 어플리케이션 서버(예컨대, WLS) 및 트래픽 디렉터(예컨대, OTD) 컴포넌트들에 대해, 서비스들로서 구현될 수 있는 해당 컴포넌트들에 대한 플러그인들이 제공될 수 있고, 이후에 파티션의 생성 또는 구성 중에 사용될 수 있다.

HK2와 같은 메커니즘들은 또한, 예를 들어, 기본 스토어 또는 지속성 타입에 의해 XML에 저장된 구성 모델을 정의하는데 사용될 수 있는 구성 관리의 지원을 제공한다.

실시예에 따르면, 구성 객체들은 파티션과 함께 사용하기 위한 특정 컴포넌트의 상기 어트리뷰트들을 정의하는데 사용될 수 있다. 상기 객체는 유사하게 주입가능하며, 예를 들어 상기구성 객체를 주입하는 것 및 해당 파티션에 대한 상기 정보를 조회하는 것에 의해 임의의 파티션의 구성 정보를 조회할 수 있게 한다.

환경

실시예에 따르면, 테넌트의 요구들을 충족시키는 응집력있는 유닛을 형성하여 서로 다른 컴포넌트들에 걸친 파티션들의 세트는 환경으로서 링크될 수 있다. 환경은 각각의 타입의 파티션을 하나보다 더 많이 가질수 있지만, 전형적으로 파티션의 각각의 타입 중 하나만 가질 것이다. 예를 들어, FA 시나리오에서 상기 멀티도메인 토폴로지의 각각의 상기 도메인들로부터 하나보다 많은 WLS 파티션이 있을 수 있다. 이러한 시나리오에서는 지원되어야만 하는 WLS와 OTD와 데이터베이스 사이의 다수의 관련성들이 있을 수 있다.

컴포넌트/ 런타임

실시예에 따르면, 컴포넌트 또는 런타임은 소프트웨어 컴포넌트, 예를 들어 OTD, WLS, 코히런스, 또는 데이터베이스 컴포넌트이다. 다른 실시예들에 따라, 소프트웨어 컴포넌트들의 추가적 타입들은 또한 지원될 수 있다.

라이프사이클 관리자

실시예에 따르면, 상기 라이프사이클 관리자는 서로 다른 컴포넌트들, 예를 들어 고유의 파티션-특정 구성들을 갖는, 어플리케이션 서버들, 트래픽 디렉터들 또는 로드 밸런서들, 그리고 데이터베이스 또는 다른 컴포넌트들, 에 걸쳐서 구성 통합을 할 수 있게 한다. 상기 라이프사이클 관리자는 라이프사이클 구성들을 생성하고, 해당 구성들을 업데이트하고, 해당 구성들을 보고, 그리고 환경에 걸쳐 해당 구성들을 파괴하기 위해 클라이언트들에 로컬 API 및/또는 REST 액세스를 제공하는 라이브러리로서 구현될 수 있다.

라이프사이클 플러그인

실시예에 따르면, 라이프사이클 플러그인은 상기 라이프사이클 관리자와 컴포넌트, 예를 들어 OTD, WLS, 코히런스, 또는 데이터베이스 컴포넌트 사이 브릿지를 제공하는 소프트웨어 모듈이다. 라이프사이클 플러그인들은 상기 런타임 플러그인 및 HK2 서비스들로서, 상기 HK2 서비스들은 상기 라이프사이클 플러그인이 구성 변경 트랜잭션 및 알림 이벤트에 참여할 수 있게 하며 컴포넌트에서 해당 활동을 반영하기 위해 적절한 동작을 취할 수 있도록 하는, 파티션 플러그인(지원되는 때) 인터페이스들을 구현하는 클래스를 포함할 수 있다. 상기 플러그인 API는 일반적으로 런타임 또는 파티션에 대한 상시 실제 라이프사이클 동작들을 수행하는데 사용되는 상기 기본 프로토콜에 구속되지 않는다(agnostic). 상기 플러그인의 상기 구현은 상기 필요한 동작들을 수행하기 위해 상기 런타임에 연결하는 방법을 선택할 수 있다. 예를 들어, 실시예에 따르면, 런타임상에서 상기 런타임 관리자를 통해 quiesce, scaleUp 또는 scaleDown과 같은 동작이 시작될 때, 상기 런타임 타입의 해당하는 상기 런타임 플러그인의 구현이 HK2를 통해 조회될 수 있고, 상기 런타임 플러그인(예컨대, RuntimePlugin)의 상기 대응 방법은 상기 런타임 플러그인에 대해 호출되어 적절한 동작을 취한다.

클라이언트

실시예에 따르면, 클라이언트는 예컨대, REST API들 또는 자바 API들을 통해 임베디드된 케이스를 통해 상기 라이프사이클 관리자와 상호작용하는 라이프사이클 관리자의 임의의 클라이언트를 참조한다. 클라이언트들의 예들은 오라클 퓨전 미들웨어 컨트롤(FMWC) 및 엔터프라이즈 관리자 클라우드 컨트롤(EMCC), 그리고 컬-기반 스크립트들을 포함한다. 실시예에 따르면, 상기 라이프사이클 관리자 REST API들은 컴포넌트들에 걸쳐 파티션 구성들을 프로비저닝하고 업데이트할 때 엔터프라이즈 관리자와 같은 제품들 내에서 사용될 수 있다.

라이프사이클 사용 케이스들

실시예에 따르면, 다음은 라이프사이클 사용 케이스들의 예들이다. 1. 파티션의 상기 생성, 삭제 및 업데이트들을 포함한 컴포넌트에 대한 파티션 CRUD 동작들; 2. 런타임들의 등록, 상기 등록된 런타임들에 대한 업데이트들 및 런타임들의 등록해제를 포함한, 컴포넌트에 대한 런타임 동작들; 그리고, 3. 서로 다른 컴포넌트들에 걸쳐 파티션들의 관련성, 따라서 두 파티션들의 관련을 런타임들(예를 들어, WLS가 있는 데이터베이스 또는 WLS가 있는 OTD)의 상기 두 슬라이스들과 연결하여, 따라서 둘을 함께 사용할 수 있게 한다.

라이프사이클 상호작용들

도 7은 실시예에 따르면, 멀티테넌트 어플리케이션 서버 환경에서 단대단 라이프사이클 이벤트 다이어그램을 도시한다.

도 7에 도시된 바와 같이, 실시예에 따르면, 상기 라이프사이클 관리자는, 어플리케이션 서버(예컨대, WLS) 라이프사이클 플러그인(420), 트래픽 디렉터(예컨대, OTD) 라이프사이클 플러그인(422), 데이터베이스(예컨대, 오라클 데이터베이스) 라이프사이클 플러그인(424), 및/또는 메모리내 데이터 그리드(예컨대, 코히런스) 라이프사이클 플러그인(426)과 같은, 하나 또는 복수의 플러그인들과 관련된 컴포넌트들의 오케스트레이션을 할 수 있게 한다.

실시예에 따르면, (임의의 관련 메타데이터와 함께) 환경(430)을 생성하는 요구를 수신한 것에 응답하여, 상기 라이프사이클 관리자는 상기 다양한 컴포넌트 파티션들의 상기 생성 및 관련성을 오케스트레이트하고, 이후에 상기 테넌트가 사용할 수 있도록 상기 환경(432)을 리턴한다.

도 8은 실시예에 따르면, 멀티테넌트 어플리케이션 서버 환경에서 단대단 라이프사이클 토폴로지를 도시한다.

도 8에 도시된 바와 같이, 실시예에 따르면, 단순 또는 단일 도메인 용도는 클라이언트들(440), 어드민 서버(450), 관리 서버들(452)의 클러스터(여기서는 MS1, MS2 및 MS3으로 표시됨), 데이터베이스(454), 및 트래픽 디렉터 / 로드 밸런서(460) 포함할 수 있으며, 상기 라이프사이클 관리자는 OTD, 데이터베이스 및 코히런스와 같은 상기 다른 컴포넌트들에 따라 관리하는 상기 도메인에서 실행한다.

이 시나리오에서, 상기 단대단 라이프사이클 구성은 XML 파일에 저장될 수 있고 상기 관리 서버들상에서 런타임시 상기 테넌시를 설정(establish) 가능하다. 상기 라이프사이클 관리자는, 상기 어드민 서버에서 실행될 것이고 임의의 추가 설정이 필요없을 일부 어플리케이션 서버 환경들에서 즉시 가능할 수 있다.

도 9는 실시예에 따르면, 멀티테넌트 어플리케이션 서버 환경에서 다른 단대단 라이프사이클 토폴로지를 도시한다.

도 9에 도시된 바와 같이, 실시예에 따라 그리고 엔터프라이즈 배포에서 엔터프라이즈 매니저(EM)을 사용하는 FA 프로비저닝 같은 더 복잡한 시나리오에서, 상기 라이프사이클 관리자는 많은 컴포넌트들을 관리할 수 있고 고-가용성 요구사항들을 또한 가질 수 있으며, 상기 라이프사이클 관리자는 각각의 라이프사이클 관리자 기능(473, 475, 477)을 갖는 복수의 EM/FA 프로비저닝 인스턴스들(472, 474, 476)로서 개별적인 라이프사이클 관리자 클러스터/도메인(471)에서 실행될 수 있다.

실시예에 따르면, 상기 라이프사이클 관리자 도메인은 관리 서버들(여기서는 MS1, MS2 및 MS3으로 표시된)의 클러스터(492)를 갖는 도메인(490)과 같은 다른 도메인들 또는 컴포넌트들을 관리하는데 사용될 수 있다.

이 시나리오에서, 상기 라이프사이클 관리자는 상기 라이프사이클 관리자 클러스터 내 상기 관리 서버들에서 실행될 수 있고, 상기 단대단 라이프사이클 구성은 상기 데이터베이스 내 영구적으로 유지될 수 있으므로, 상기 정보에 액세스할 필요있는 임의의 도메인들 또는 런타임들은 해당 정보를 획득하기 위해 상기 데이터베이스에 액세스할 수 있다.

상기 두 토폴로지들에서, 상기 라이프사이클 내에서 관리될 수 있는 상기 컴포넌트들은 구성 및 생성에 더하여 적절한 런타임들의 스케일링을 위한 탄력성 기능을 지원할 수 있는 상기 라이프사이클 관리자에 등록된 상기 라이프사이클 플러그인들에 의해 결정될 것이다.

라이프사이클 런타임

실시예에 따르면, 라이프사이클 런타임(예컨대, LifecycleRuntime)은 WLS, OTD 또는 데이터베이스와 같은 컴포넌트 또는 관리된 서비스를 표현한다. 상기 런타임 플러그인의 인스턴스가 상기 컴포넌트에 의해 구현되는 경우 라이프사이클 런타임은 상기 라이프사이클 관리자에 의해 관리될 수 있다. 상기 런타임 플러그인은 라이프사이클 관리자를 통해 관리되고 있는 상기 런타임상에서 수행될 수 있는 생성, 삭제, 업데이트, 확장, 축소 및 정지 동작들과 같은 동작들을 할 수 있는 구현들을 제공한다. 런타임은 상기 라이프사이클 관리자를 통해 생성될 수 있거나, 상기 런타임 관리자 내 등록 런타임(예컨대, registerRuntime) 방법을 통해 상기 라이프사이클 관리자에 의해 사용되기 위한 밴드 외로 생성되는 경우 상기 라이프사이클 관리자에 등록될 수 있다.

런타임상 임의의 동작들을 수행하기 위해, 상기 런타임의 인스턴스를 조회해야 한다. 실시예에 따르면, 라이프사이클 런타임의 인스턴스는 후술되는 바와 같이 상기 임의의 런타임 타입에 대한 런타임 관리자를 사용하여 조회될 수 있다. 파티션(상기 런타임의 슬라이스)의 상기 사용을 지원하는 관리된 서비스들을 표현하는 라이프사이클 런타임은 상기 라이프사이클 런타임 상에 해당 파티션에 대한 CRUD 동작들을 할 수 있게 한다.

실시예에 따르면, 라이프사이클 런타임을 조회한 후에 파티션을 생성하기 위해, 상기 라이프사이클 런타임의 생성 파티션(예컨대, createPartition) 방법은 상기 선택된 런타임상에 파티션 생성을 위해 사용될 수 있다. 상기 파티션이 생성되는 상기 방식은 상기 라이프사이클 런타임에 대한 상기 파티션 플러그인이 상기 런타임 타입에 대한 HK2 서비스로서 조회될 것이고, 상기 파티션 플러그인 상에 상기 해당하는 생성 방법이 호출된다.

런타임 관리자

실시예에 따르면, 런타임 관리자(예컨대, RuntimeManager)는 런타임들은 관리하는데 사용되는 싱글톤(singletone) HK2 서비스로서 제공될 수 있다. 런타임 관리자는 해당 JVM상 모든 런타임들의 상기 라이프사이클을 관리할 자바 가상 머신(JVM)마다 제공될 수 있다. 런타임 관리자를 사용하여, 런타임이 생성되거나 등록될 수 있다. 상기 런타임 관리자는 또한 런타임의 생성, 삭제, 업데이트, scaleUp, scaleDown, 및 정지 동작들을 제공한다. 상기 런타임 관리자는 상기 런타임 플러그인을 해당 런타임 타입에 대한 HK2 서비스로서 조회할 것이고 상기 플러그인상에서 상기 해당하는 동작이 호출될 것이다.

실시예에 따르면, 런타임 관리자가 임의의 런타임 타입에 대해 조회되면, 그 다음 해당 런타임 관리자 상에 scaleUp 및 scaleDown 동작들이 상기 임의의 런타임에 호출될 수 있다. 상기 런타임 관리자는 상기 서비스에 대한 상기 해당하는 런타임 플러그인을 조회할 것이고 상기 scaleUp 및 scaleDown 동작을 호출될 것이다. 이 런타임 지원은 탄력성 사용 케이스들을 처리할때 특히 유용하다.

실시예에 따르면, 상기 런타임 관리자는 런타임들과 함께 사용할 다음 동작들을 제공한다.

실시예에 따르면, 다음 수도 코드는 미리 생성된 WLS 런타임 및 데이터베이스 런타임이 라이프사이클 관리자에 등록되고 그 다음 후속적으로 상기 런타임들 상에 파티션들을 생성하기 위해 라이프사이클 관리자에 의해 사용되는 방법을 도시한다.

런타임들의 정지

실시예에 따르면, 런타임들의 정지/정상 셧다운 지원을 포함할 수 있는 WLS와 같은 컴포넌트들은 상기 런타임 플러그인에 상기 정지 지원을 구현하는 것에 의해 상기 라이프사이클 관리자를 통해 상기 정지 기능들을 지원할 수 있다. 런타임을 정지하는 것은 서로 다른 단계들을 가질 수 있다. 이러한 시나리오에서, 런타임 플러그인의 상기 정지 방법은 상기 정지 방법의 상기 단계 파라미터를 통해 상기 정지 단계를 표시하는 것으로, 한 번보다 더 많이 호출될 수 있다.

예를 들어, 상기 서버가 상기 정지 단계를 시작하고 있음을 표시하는 "start_quiesce" 단계가 있으므로, 새로운 요청들이 정지되고 있는 상기 서버로 전달되지 않음을 알린다. 상기 정지가 완료된 후에, 상기 후속 호출은 상기 서버가 이제 새로운 요청들을 다시 수락할 준비가 되었음을 표시하는 "end_quiesce" 단계를 가질 것이다. 컴포넌트가 추가 단계들을 지원하는 경우, 해당 단계들은 완전한 기능을 보장하기 위해 상기 런타임 플러그인에 의해 지원될 수 있다.

상기 "start_quiesce", "end_quiesce"는 컴포넌트가 지원할 수 있는 단계들의 예들이고 모든 컴포넌트가 지원해야하는 단계들의 표준 리스트는 아니다. 컴포넌트가 정지를 지원하지 않는 경우, 그 다음 UnsupportedOperationException가 스로우되어야 한다. 컴포넌트가 단계들을 지원하지 않는 경우, 널값은 상기 정지 방법으로 전달되는 유효한 값이다.

런타임 스케일링

멀티-테넌트 환경의 상기 이점들 중 하나는, 스케일의 이코노미(economy)들을 실현하고 관리자들이 상기 사용자들의 상기 요구들이 시간이 지남에따라 용량을 할당하는 상기 유연성을 확보하도록 하는 다수의 어플리케이션들 및 사용자 그룹들에 걸쳐 하드웨어, 리소스들 및 서비스들을 공유하는 것이다.

실시예에 따르면, 라이프사이클 관리자 API들은 다른 탄력성 프레임워크들이 런타임들을 확장하고 축소할 수 있는 상기 기능을 제공한다. 상기 런타임 관리자 및 런타임 플러그인은 사용자들이 런타임을 스케일하도록 호출할 scaleUp 및 scaleDown 방법들을 제공한다.

실시예에 따르면, 런타임 관리자에서 scaleUp 또는 scaleDown이 호출될 때, 상기 런타임 타입에 해당하는 상기 런타임 플러그인이 조회되고 상기 런타임 플러그인의 상기 인스턴스에서 상기 스케일링 동작이 호출된다. 컴포넌트가 스케일링 동작들을 지원하지 않으면, 상기 런타임 플러그인의 상기 구현은 UnsupportedOperationException을 던져야한다.

런타임 플러그인 구현

실시예에 따르면, 하기 도시된 것은 런타임 플러그인의 수도 코드이다.(가독성을 위해, 이 예는 상기 모든 추상적인 방법들을 구현하지 않는다.)

파티션 플러그인

실시예에 따르면, 파티션들(예를 들어, WLS, 12c 데이터베이스 등과 같은 런타임들의 슬라이스들)을 지원하는 런타임들은 파티션 플러그인의 구현을 제공해야한다. 런타임에서 createPartition과 같은 동작이 호출될 때, 상기 런타임 타입에 해당하는 파티션 플러그인의 상기 구현이 HK2 서비스로서 조회될 것이고, 상기 해당하는 생성 방법이 상기 파티션 플러그인 구현 클래스상에서 호출될 것이다. 상기 런타임에 연결하고 상기 런타임의 상기 슬라이스를 생성하는 것은 상기 구현 클래스에 달려있다. 일단 생성되면, 상기 파티션은 라이프사이클 관리자에 등록되고 상기 라이프사이클 config.xml내에서 지속된다. 실시예에 따르면, 상기 런타임은 파티션들에 대한 다음 기능들을 제공한다.

실시예에 따르면, 하기 도시된 것은 파티션 플러그인의 수도 코드이다. 상기 플러그인의 모든 동작들은 이 예에서 상기 WLS 런타임상 상기 동작들을 수행하기 위해 상기 실제 WLS 런타임에 JMX 연결을 설정한다.

플러그인 등록

상술한바와 같이, 실시예에 따르면, 런타임 플러그인들 및 파티션 플러그인들은 HK2 서비스들로서 상기 플러그인들의 구현과 함께, HK2 계약으로서 정의될 수 있다. 상기 HK2 서비스 이름은 상기 플러그인이 등록된 상기 서비스의 상기 이름과 매치되어야한다. 플러그인 등록은 두 방법들로 수행될 수 있다. 상기 플러그인들은 jar 파일로서 패키지되고 REST 명령들을 통해 라이프사이클 관리자에 등록된다. 또는, 예컨대 상기 WLS 시스템 관리자에 의해서만 구성가능한 라이프사이클 관리자 구현에 의해 특정된 디렉토리에 상기 플러그인 구현 jar들을 드롭(drop)한다. 상기 라이프사이클 관리자는 스타트업시 상기 플러그인들을 로드하고 라이프사이클 관리자 구현에 등록하기 위해 상기 디렉토리를 스캔할 것이다. 상기 플러그인들을 위치시키는 상기 디폴트 디렉토리는 oracle_home/wlserver/common/lifecycle/plugins이다.

환경

전형적 프로덕션 시스템에서, 일반적으로 WLS 파티션, 데이터베이스 파티션 및 어플리케이션을 실행하는데 요구될 다른 것들과 같은 아티팩트가 하나보다 더 있을 것이다. 실시예에 따르면, 환경은 어플리케이션의 모든 상기 관련된 부분들에 대한 그룹핑 구성물을 제공한다. 상기 라이프사이클 관리자는 상기 사용자가, 상기 시스템 관리자가 임의의 테넌트를 위한 파티션들을 그룹화하는데 사용될 수 있는 환경을 생성하게 할 수 있다. 실시예에 따르면, 환경은 파티션들에 대해 다음의 기능들을 제공한다.

파티션들과 환경들의 관련성

실시예에 따르면, 환경에 파티션이 추가되면, 상기 환경에 추가되었던 상기 다른 파티션들과 관련될 수 있다.

예를 들어, 환경에 WLS 파티션 및 데이터베이스가 있는 경우, 상기 둘을 관련시키는 것은 관련되는 상기 데이터베이스를 참조하는 WLS에서 데이터소스가 생성되게 할 것이다. 두 파티션들을 관련시키기 위해, 상기 파티션들은 먼저 환경에 추가될 필요가 있다. 환경에 추가되면, 그 다음 관련될 필요있는 상기 두 파티션들을 통과하는 상기 환경상에서 관련(예컨대, Associate) 방법이 호출될 수 있다. 환경에서 관련이 호출될 때, 상기 해당하는 플러그인들의 관련 방법이 라이프사이클 컨텍스트(예컨대, LifecycleContext) 객체와 마찬가지로 호출된다. 상기 라이프사이클 컨텍스트는 상기 두 파티션들의 상기 필수적 연결을 수행할 수 있도록 상기 플러그인에 전달되는 상기 필수 정보를 가질 수 있다. 파티션 플러그인들의 상기 관련 방법은 상기 환경의 관련 방법 호출로 전달되는 상기 순서대로 호출된다.

파티션들과 환경들의 분리성

실시예에 따르면, 파티션이 더 이상 사용되지 않는 경우, 상기 환경의 다른 파티션들로부터 해당 파티션에 참조들이 삭제될 수 있기 전에 제거할 필요가 있다. 분리성은 환경에서 두 파티션들을 연결해제하는 메커니즘을 제공한다. 분리성이 호출될 때, 상기 파티션 플러그인의 해당하는 분리 방법이 호출되고 상기 두 파티션들을 함께 연결하는 상기 구성을 제거하는 것은 상기 플러그인의 상기 책임이다.

예를 들어, WLS 파티션이 OTD 파티션 구성으로부터 분리된 경우, OTD에 구성되었던 상기 라우팅 정보가 제거될 것이고 상기 파티션에 대한 트래픽은 OTD를 통해 라우트되지 않을 것이다. 상기 파티션 플러그인들의 분리 방법은 상기 방법 호출로 전달되는 순서대로 호출된다.

파티션 마이그레이션

실시예에 따르면, 파티션들의 마이그레이션을 지원하는 런타임들은 파티션 플러그인의 상기 마이그레이션 방법을 구현할 필요가 있다. 파티션을 마이그레이션할 때, 파티션과 관련된 상기 다른 파티션들은 또한 동작을 취할 필요가 있다. 이를 해결하기 위해, 마이그레이션 방법이 상기 환경상에서 동작한다. 상기 라이프사이클 관리자 인프라스트럭처는 먼저 마이그레이션되는 상기 파티션의 상기 마이그레이션 방법을 호출해야만하고, 그 다음 상기 환경내에 있는 상기 다른 파티션들의 상기 마이그레이션 방법을 호출한다.

실시예에 따르면, 파티션의 상기 마이그레이션은 서로 다른 단계들을 가질수 있다. 이러한 시나리오에서, 상기 마이그레이션 방법의 상기 단계 파라미터를 통해 상기 마이그레이션 단계를 표시하는, 파티션 플러그인의 상기 마이그레이션 방법은 한번보다 더 많이 호출될 수 있다.

예를 들어, 상기 파티션 마이그레이션 단계가 시작됨을 표시하는 "start_migration" 단계가 있을 수 있다. 상기 마이그레이션이 완료된 후, 상기 후속 호출은 상기 파티션이 마이그레이션되었음을 표시하는 "end_migration" 단계를 갖게될 것이다. 파티션이 추가 단계들을 지원하는 경우, 상기 단계들은 완전한 기능을 보장하기 위해 상기 파티션 플러그인에 의해 지원될 수 있다.

상기 "start_migration", "end_migration"은 파티션이 지원했을 수 있는 단계들의 예들이며 모든 파티션이 지원해야하는 단계들의 표준 리스트는 아니다. 파티션이 마이그레이션을 지원하지 않는 경우 그 다음 UnsupportedOperationException이 스로우되어야한다. 파티션이 단계들을 지원하지 않는 경우, 널값은 상기 마이그레이션 방법에 전달되는 유효한 값이다.

파티션들의 정지

실시예에 따르면, 파티션들의 정지를 지원하는 런타임들은 파티션 플러그인의 상기 정지 방법 구현을 필요로 할 것이다. 상기 라이프사이클 관리자는 상기 파티션을 정지하려 시도하기 전에 상기 파티션이 호환가능한 상태인지 보장하기 위해 파티션의 상기 상태를 체크할 것이다.

구성 모듈

실시예에 따르면, 상기 라이프사이클 관리자는 상기 동작들을 위해 요구되는 상기 다양한 구성 요소들을 관리하는 구성 모듈을 포함한다. 상기 구성 모듈은 여기에 기술된 다양한 시나리오들을 위한 상기 필수 구성 인프라스트럭처를 제공한다. 상기 구성 모듈은 두 모드들로 동작한다. 상기 라이프사이클이 어드민 서버에서 실행하는 로컬에서, 구성은 상기 WLS config 디렉토리의 XML 파일에 유지된다. 또한, 상기 라이프사이클이 클러스터에서 실행할 수 있는 HA에서, 구성은 데이터베이스에 유지된다. 두 케이스에서, 라이프사이클 구성은 구성들을 관리하기 위해 상기 HK2 프레임워크를 사용한다.

라이프사이클 구성 파일 전파

실시예에 따르면, 상기 어드민 서버상 상기 구성 파일이 변경될 때, 해당 변경들은 모든 관리 서버들에 전파되야한다. 상기 관리 서버들은 상기 관리 서버상에서 실행중인 어플리케이션들에 대한 상기 올바른 테넌트 컨텍스트를 설정하기 위해 상기 라이프사이클 구성을 사용한다. HK2 config 객체들은 상기 XML 구성 파일의 재분석(reparsing)을 할 수 없게 한다. 대신, 새로운 객체는 인스턴스화되고 상기 업데이트된 xml 파일이 새로 분석된다. 구성 변경이 커밋될 때, 상기 XML 파일은 스페셜 디렉토리, 즉 상기 도메인의 상기 펜딩 디렉토리에 저장된다.

관리 서버들로의 파일 전송

실시예에 따르면, LifecycleConfigDocument save() 방법은 변경이 커밋 될때마다 HK2에 의해 호출된다. 이 방법은 또한 상기 파일의 복사본을 상기 펜딩 디렉토리에 저장하고, 그 다음 상기 변경된 파일을 관리 서버로 상기 업로딩하도록 트리거하는 상기 다음 API를 호출한다.

변경들 보기

실시예에 따르면, 상기 구성 파일의 상기 첫번째 분석에서 시작된 FileWatcher daemon은 상기 XML 파일이 변경되었음을 검출할 것이다. 그 다음 새 config 객체를 생성하고 상기 xml 파일을 분석할 것이다. 임의의 호출자들은 상기 분석 도중 정보에 액세스하기 위해 시도하면 차단될 것 이다. 상기 분석이 완료되면, 상기 수정된 데이터는 호출자들이 이용가능하게 될 것이다.

상기 구성된 데이터 액세스

실시예에 따르면, 상기 HK2 구성은 LifecycleConfigFactory 클래스에 의해 노출될 수 있다. 예를 들어:

편집 세션들

실시예에 따르면, WLS 구성에서 변경을 요구하는 REST 요청들의 경우, 각각의 REST 호출은 사용자를 대신하여 편집 세션들을 생성하고 관리한다. 이는 상기 콘솔의 개발 모드에서 상기 '묵시적 변경들'과 유사하다.

라이프사이클태스크

자연적으로 오래 계속된 비동기 작업을 실행하는 라이프사이클 관리자를 통해 수행되는 어떤 동작들이 있다. 상기 동작들의 예들은 다음과 같다 : 서버 정지(runtime manager.quiesce); 또는 서버 시작(runtime manager.quiesce). 이러한 시나리오에서, 라이프사이클 관리자 API의 상기 시맨틱은 상기 API들에서 LifecycleTask 객체를 반환하기 위해 비동기적이 될 수 있다.

라이프사이클태스크관리자

일반적으로, 사용자가 비동기 동작을 수행하고 LifecycleTask 객체를 역으로 수신하면, 해당 객체와 함께 하기 두 동작들 중 하나를 수행할 수 있다: 상기 라이프사이클 태스크에 의해 나타내지는 상기 비동기 동작의 상태를 얻는 것, 또는 상기 라이프사이클 태스크에 의해 나타내지는 상기 비동기 동작을 취소하는 것. 실시예에 따르면, 상기 상술한 동작들은 LifecycleTaskManager에 의해 노출된 상기 인터페이스들에 의해 수행된다.

라이프사이클 API들 또는 클래스들

다양한 실시예들에 따라, 라이프사이클 인터페이스들 및 클래스들의 예들이 후술되어있다. 다른 실시예들에 따라, 인터페이스들 및 클래스들의 다른 타입들이 제공될 수 있다.

라이프사이클 관리자

실시예에 따르면, 대표적인 라이프사이클 관리자 인터페이스가 후술된다.

런타임 관리자.자바

실시예에 따르면, 대표적인 런타임 관리자.자바 인터페이스가 후술된다.

라이프사이클 런타임

실시예에 따르면, 라이프사이클 런타임 인터페이스 예가 후술된다.

라이프사이클 파티션

실시예에 따르면, 대표적인 라이프사이클 파티션 패키지가 후술된다.

런타임 플러그인

실시예에 따르면, 대표적인 런타임 플러그인 클래스가 후술된다.

파티션 플러그인

실시예에 따르면, 대표적인 파티션 플러그인 클래스가 후술된다.

환경

실시예에 따르면, 대표적인 환경 인터페이스가 후술된다.

라이프사이클 컨텍스트

실시예에 따르면, 대표적인 라이프사이클 컨텍스트 인터페이스가 후술된다.

라이프사이클 동작 타입

실시예에 따르면, 라이프사이클 동작 타입 계산자(enumerator) 예가 후술된다.

라이프사이클 태스크

실시예에 따르면, 라이프사이클 태스크 인터페이스 예가 후술된다.

라이프사이클 태스크 관리자

실시예에 따르면, 대표적인 라이프사이클 태스크 관리자 인터페이스가 후술된다.

도 10은 실시예에 따르면, 멀티테넌트 어플리케이션 서버 환경에서 단대단 라이프사이클을 제공하는 방법의 흐름도를 도시한다.

도 10에 도시된 바와 같이, 단계 510에서, 어플리케이션 서버 환경은 하나 이상의 파티션들을 지원하는 소프트웨어 어플리케이션들의 실행을 위한 도메인을 포함하는 하나 이상의 컴퓨터들에서 제공되며, 각 파티션은 상기 도메인의 관리 및 런타임 서브디비전을 제공하고 파티션은 배포가능한 어플리케이션들 또는 리소스들의 컬렉션을 갖는 및/또는 리소스 그룹 템플릿을 참조하는 하나 이상의 리소스 그룹들을 선택적으로 포함할 수 있다.

단계 512에서, 예를 들어 어플리케이션 서버들, 트래픽 디렉터들 또는 로드 밸런스들, 및 데이터베이스 또는 자신의 파티션-특정 구성들을 가질 수 있는 다른 컴포넌트들과 같은 서로 다른 컴포넌트들에 걸쳐서 구성 통합을 가능하게 하는 라이프사이클 관리자가 제공된다.

단계 514에서, 복수의 컴포넌트들이 제공되며, 각각의 컴포넌트는 상기 라이프사이클 관리자 및 해당 컴포넌트 사이의 브릿지를 제공하는 라이프사이클 플러그인을 포함한다.

단계 516에서, 파티션의 생성 또는 구성 동안, 상기 라이프사이클 관리자는 플러그인 인터페이스를 호출할 수 있는 라이프사이클 동작들을 수행하며, 상기 라이프사이클 관리자는 상기 파티션과 함께 사용하기 위해 컴포넌트의 상기 실제 생성 또는 구성, 예를 들어, 트래픽 디렉터 인스턴스 또는 데이터베이스 인스턴스의 상기 생성을 차례대로 수행한다.

테넌트 온보딩

실시예에 따르면, 상기 시스템은 서비스에 대한 테넌트를 특정 파티션에 온보드하는데 사용될 수 있는, 테넌트 온보딩 기능을 위한 지원을 포함한다.

예를 들어, 퓨전 어플리케이션들(FA)을 포함하는 실시예에 따르면, 상기 시스템은 서비스에 대한 FA 테넌트를 임의의 파티션에 온보드하는 메커니즘을 제공할 수 있다. 실시예에 따르면, 각 환경은 상기 상위 스택의 서비스와 관련될 수 있다. 상기 테넌트을 온보딩하는 때, 상기 FA 서비스를 사용하는 파티션과 같은 정보, 상기 서비스와 관련된 상기 테넌트의 데이터베이스에 더하여 상기 탑-레벨 테넌트 디렉토리가 특정될 수 있다.

실시예에 따르면, 상기 시스템은 테넌트를 임의의 파티션에 매핑(map)하는 API를 제공한다. 들어오는 요청들에서, 상기 시스템은 상기 구성으로부터 상기 테넌트를 결정할 수 있고 런타임에서 테넌시 컨텍스트를 설정하기 위해 해당 정보를 사용할 수 있다. 예컨대, JRF(Java Required Files) API를 사용하여 쿼리될 때, 그 다음 상기 적절한 테넌시 컨텍스트가 상기 어플리케이션에 이용가능하게 될 수 있다.

예를 들어, 상술한 바와 같이, 상기 시스템은 환경을 생성하는데 사용될 수 있으며, 따라서 예컨대 FA 테넌트가 온보드될 수 있으며, 그리고 따라서 그 다음 오라클 플랫폼 시큐리티 서비스들(OPSS) 또는 서비스 지향 아키텍처(SOA)와 같은 상기 상위 스택 컴포넌트들이 해당 환경을 프로비전하는 액세스를 획득할 수 있으며, 상기 최종-구성된 환경이 상기 테넌트가 필요로 할 모든 상기 컴포넌트들을 가질 수 있다.

실시예에 따르면, 테넌트는 하나 이상의 서로 다른 서비스들을 가질 수 있다. 예를 들어, 테넌트는 고객 관계 관리(CRM) 서비스 및/또는 SOA 서비스를 가질 수 있다. 일반적으로, 상기 상위 스택의 각 서비스는 상기 어플리케이션 서버의 하나 이상의 환경과 관련될 수 있고, 이는 상기 상위 스택내의 두 서비스들을 등록하는 테넌트는 상기 테넌트 레벨에서 상기 환경들이 연결될 두 환경들을 일반적으로 수신할 것을 의미한다.

예를 들어, 테넌트가 SOA 및 비지니스 프로세스 관리(BPM) 서비스들에 등록하면, 그 다음 상기 테넌트는 SOA 환경과 BPM 환경을 수신할 것이고, 이러한 환경들은 해당 테넌트와 모두 연결될 것이다. 환경 내의 각각의 어플리케이션은 필요할 경우, 예컨대 HTTP 또는 T3 호출과 같은 원격 호출을 해당 테넌트와 관련된 다른 환경으로 사용할 수 있다.

상술한 바와 같이, 실시예에 따르면, 상기 시스템은 테넌시 컨텍스트 및 파티션 컨텍스트의 상기 컨셉들을 인식하며, 상기 이전 컨텍스트는 일반적으로 더 많은 정보를 포함한다. 특정 서비스는 다양한 컴포넌트들, 예를 들어 어플리케이션 서버(예컨대, WebLogic, WLS), 데이터베이스(예컨대, Database) 및 트래픽 디렉터 또는 다른 로드 밸런서(예컨대, 오라클 트래픽 디렉터, OTD)의 여러 슬라이스들 또는 파티션들을 포함할 수 있다. 테넌트 컨텍스트는 서비스를 표시하는 방식으로 그리고 해당 서비스가 상기 파티션 컨텍스트에 매핑되는 방식으로, 특정 테넌트에 대한 파티션 컨텍스트에 매핑한다.

도 11은 실시예에 따르면, 멀티테넌트 어플리케이션 서버 환경에서 테넌트 온보딩을 도시한다.

도 11에 도시된 바와 같이, 실시예에 따르면, 테넌트 온보딩 API(550) 및 구성 인터페이스(560)는 관리자(562)가 테넌트 구성(564)를 제공하도록 한다. 상기 테넌트 온보딩 프로세스는 UUID 및 환경(566)을 갖는 테넌트(565)를 생성하기 위해 해당 정보를 사용할 수 있고, 테넌트의 환경(570)을 상기 적절한 파티션 또는 도메인 레벨 리소스들에 매핑할 수 있다.

실시예에 따르면, 각각의 테넌트는 전역 고유 ID (UUID)와 관련될 수 있고, 각각의 서비스는 UUID와 유사하게 관련될 수 있다. 이는 상기 시스템이 상기 테넌트 컨텍스트를 조회하기 위해 호출되고 있는 서비스의 상기 컨텍스트에서 동작할 수 있게 한다. 상기 시스템은 또한 본 명세서에 다양한 실시 예들에서 ExecuteAs 기능으로서 일반적으로 참조되는, 특정 태스크를 실행하기 위해 서로 다른 테넌트 컨텍스트들 사이에서 스위치하는 상기 기능을 제공한다.

예를 들어, 어플리케이션 서버(예컨대, WLS) 환경에서, 글로벌 또는 도메인 레벨 런타임이 후술되는 바와 같이 제공될 수 있다. 상기 상위 스택(예컨대, FA, SOA 또는 BPM)의 제품 또는 컴포넌트는, 예를 들어 특정 서비스에 대한 특정 테넌트를 온보딩하기 위해 임의의 테넌트 컨텍스트로 스위치하려고 할 수 있다. 해당 테넌트가 온보드될 때, 상기 글로벌 또는 도메인 레벨에서 실행되는 상기 상위 스택 소프트웨어는 일시적으로 해당 테넌트로 스위치할 수 있으며, 예컨대 상기 트래픽 디렉터 또는 상기 데이터베이스와 함께 임의의 필요한 작업들을 수행할 수 있다.

일반적으로, 상기 시스템은 글로벌 레벨 컨텍스트로부터 테넌트 컨텍스트로만 스위치할 수 있고, 그 반대는 아니며, 따라서 executeAs 동작은 글로벌 컨텍스트들에서 테넌트 컨텍스트들로만 실행될 수 있지만, 테넌트에서 테넌트 컨텍스트로는 실행될 수 없다.

테넌시 컨텍스트의 스위칭

실시예에 따르면, 상기 시스템은 상기 요청을 현재 처리할 수 있는 타겟 컴포넌트와 같은 요청 어트리뷰트들에 기초하여 자동적으로 파티션 컨텍스트를 결정할 수 있다. 상기 스레드의 상기 파티션 컨텍스트는 상기 요청이 서로 다른 파티션에 배포된 컴포넌트를 입력할 때마다 일반적으로 변경한다.

예를 들어, 한 파티션에서 실행중인 서블릿이 엔터프라이즈 자바 빈(EJB) 또는 서블릿 또는 다른 파티션에 배포된 웹 서비스와 같은 원격 컴포넌트를 호출할 때, 상기 원격 호출은 상기 타겟 컴포넌트를 호스팅하는 상기 파티션에서 실행된다.

이 케이스에서, 상기 기초 플랫폼은 상기 타겟 컴포넌트의 상기 비즈니스 방법을 호출하기 전에 상기 적절한 파티션 컨텍스트를 설정하는 것을 처리한다. 어플리케이션 개발자는 서로 다른 파티션 컨텍스트 하에서 코드를 실행하려고 할 때, 이 기능을 사용할 수 있다.

실시예에 따르면, 또한 테넌시 컨텍스트 스위칭은 예를 들어 상기 호출자의 상기 컴포넌트 컨텍스트를 공유하는 상기 동일 스레드에서 실행될 수 있는 공유 서비스를 호출하기 전에 어플리케이션이 상기 컨텍스트를 설정하는 경우와 같은 간단한 사용 케이스들 또지원한다. 이런 케이스들의 경우 파티션 컨텍스트 스위칭은 요구되지도 않고 바람직하지도 않다.

권한있는 동작으로서 테넌시 컨텍스트 스위칭

실시예에 따르면, 상기 글로벌 런타임과 같은 권한있는 어플리케이션 코드만테넌스 컨텍스트를 스위치할 수 있다. 그러므로, 상기 API는 액세스를 허용하기 전에 적절한 보안 권한 검사를 실시해야 한다. 권한들이 상기 타겟 테넌시가 설정되는 것을 포함하여 허가될 수 있다.

불법 테넌시 스위칭 방지

실시예에 따르면, 아래 표는 상기 코드의 보안 권한들에 따라 허용되는 컨텍스트 스위치를 기술한다.

실시예에 따르면, 예를 들어 FA 시나리오에서, 테넌트 온보딩의 상기 프로세스는 상기 프로비저닝 시스템과 통신하는 것에 의해 시작될 수 있다. WLS 서버와 같은 멀티테넌트 어플리케이션 서버에서 실행중인 FA의 상기 케이스와 같은 일부 상황들에서, 테넌트 온보딩의 상기 프로세스는 상기 프로비저닝 서브-시스템에 의해 셋업된 런타임들상 파티션들의 생성을 요구한다.

실시예에 따르면, 테넌트를 온보딩하기 전에, 상기 테넌트가 등록하는 상기 서비스를 표현하는 환경이 생성되어야 한다. 상기 FA 프로비저닝 서브-시스템은 먼저 환경을 생성하기 위해 상기 라이프사이클 관리자 API를 호출할 수 있다. 환경이 생성되면, 후술되는 예와 같이, 테넌트 어드민(예컨대, TenantAdmin) 클래스를 통해 테넌트는 온보드될 수 있다. 그 다음 상기 테넌트 어드민은 테넌트를 등록하기 위해 API(예컨대, registerTenant)를 노출할 수 있다.

테넌트가 등록되면, 상기 프로비저닝 인프라스트럭처에 의해 생성된 데이터베이스는 임의의 테넌트에 대해 상기 테넌트 어드민에 등록될 수 있다. 이 때, 상기 시스템은 상기 환경에 테넌트를 온보드할 수 있다. 테넌트를 온보딩하는 것은 상기 테넌트가 환경에 매핑되는 것을 유지하기 위해, 상기 서비스 이름과 서비스 타입(FA에서 이용가능)이 전달되는 것을 요구한다. 상기 테넌트 매핑은 lifecycleconfig.xml에 저장될 수 있다.

실시예에 따르면, 아래는 상기 라이프사이클 config.xml에 저장된 테넌트 매핑의 대표적인 코드이다.

실시예에 따르면, 런타임시, 상기 테넌트 컨텍스트(예컨대, TenantContext)는 TenantContext/TenantContextFactory를 통해 이용가능하다. 임의의 파티션 또는 테넌트 데이터베이스에 대한 TenantContext를 가져오는 API는 아래에 정의된 TenantManager 클래스에 정의된다. 테넌트를 등록하기 위한 모든 상기 테넌트 어드민 API들 및 상기 해당되는 테넌트 데이터베이스 및 환경은 WLS에서 실행중일 때 REST API를 통해 노출될 수 있다. 자바 SE에서 실행중일 때 상기 자바 API들은 직접적으로 사용될 수 있다. 대표적인 수도 코드가 WLS 환경상 테넌트를 온보드하는 상기 위 프로세스의 설명 아래에 보여진다.

상기 코드에서, 상기 DB 파티션이 라이프사이클 관리자을 사용하여 생성되지 않고 대신 프로비저닝에 의해 수행된 경우, 그 다음 프로비저닝은 상기 DB1 런타임 객체상 createPartition과 반대로서 registerDatabase를 호출할 것이다.

테넌트 컨텍스트

실시예에 따르면, FA / SaaS 및 상기 어플리케이션들 자체가 멀티-테넌트 인지될 것으로 기대될 수 있는 유사한 시나리오들에서, 그 다음 상기 파티션 ID와 파티션 이름에 더하여, 어떤 동작이 수행되고 있는 것을 대신하여 상기 테넌트를 알아야할 필요가 있다. 테넌트 컨텍스트(예컨대, TenantContext) API는 상기 적절한 테넌트 컨텍스트를 얻는데 사용할 상위 스택 FMW / FA에 대해 상기 JRF 레이어에서 이용가능할 수 있다.

테넌트 컨텍스트가 결정되면, 컴포넌트는 임의의 서비스에 대한 상기 환경과 관련된 상기 파티션(들)을 조회할 수 있다.

테넌트 매핑을 위한 자바 SE 지원

실시예에 따르면, 다음은 SE에서 테넌트 컨텍스트를 검색하는데 사용될 수 있는 대표적인 코드이다.

자바 SE의 경우, 방법이 테넌트 ID, 서비스 이름 및 서비스 타입에 기초하여 테넌트 컨텍스트를 페치(fetch)할 TenantManager에서 노출될 수 있다. getTenantContext()가 처음으로 호출될 때, 테넌트 컨텍스트의 상기 셋업이 상기 TenantContextFactory에 의해 묵시적으로 완료될 수 있다.

SE의 Config 파일 부트스트랩

실시예에 따르면, 이전 섹션에서 언급된바와 같이 상기 테넌트 매핑은 lifecycleconfig.xml에 저장될 수 있다. SE에서, 상기 시스템은 (a) 환경 변수 lifecycle.configDir에 의해 가리켜지는 위치에서 이 파일을 조회할 수 있다; 또는 (b) lifecycle.configDir 변수가 설정되지 않은 경우, 다음을 사용하여 읽을 수 있는 사용자 작업 디렉토리에서 조회할 수 있다.

SE에서 테넌트 정보 특정

실시예에 따르면, 자바 SE 모드에서 실행중일 때, 상기 테넌트를 식별하는 정보는 다음 시스템 프로퍼티들을 사용하여 읽어질 수 있다. lifecycle.tenantId lifecycle.serviceName lifecycle.serviceType; 또는 시스템 프로퍼티 lifecycle.serviceId를 통해 상기 서비스 UUID를 특정하여.

상기 위 정보는 테넌트를 고유하게 식별하고, 상기 라이프사이클 구성내에 고유한 테넌트에 더해 서비스 조합 표현을 식별하는데 사용될 수 있다. 상기 SE 어플리케이션은 TenantContextFcatory.getTenantContext가 호출될 때 표현되는 상기 식별을 가정한다.

SE에서 테넌트 컨텍스트

실시예에 따르면, SE에서 상기 테넌트 컨텍스트는 InheritableThreadLocal에 저장된다. 처음으로 getTenantContext()가 호출될 때, 상기 테넌트 컨텍스트를 계산하고 또한 이를 InheritableThreadLocal에 또한 저장하기 위해 상기 시스템 프로퍼티들을 사용한다.

동일한 방법을 더 호출하면, 상기 시스템은 테넌트 컨텍스트가 Inheritable ThreadLocal에 저장되었는지 여부를 체크하고 저장된 것을 리턴할 것이다. 상기 프로그램 실행 중간에, 상기 시스템 프로퍼티들이 변경되는 경우, 상기 변경들은 검출되어서 상기 Inheritable Thread Local상에서 테넌트 컨텍스트를 리프레시하는데 사용되거나 검출되지 않을 수 있다.

switchTenantContext로 스위칭 (일명 executeAs )

도 12는 실시예에 따르면, 멀티테넌트 어플리케이션 서버 환경에서 테넌트 온보딩을 더 도시한다.

도 12에 도시된 바와 같이, 실시예에 따르면, FA-MT의 상기 런타임 뷰는 하나 이상의 글로벌 데이터 소스들(582) 또는 프록시 데이터 소스들(584), 복수의 테넌트 런타임들(590, 600), 각각의 고유의 글로벌 데이터 소스들(592, 602)에 대한 액세스를 순서대로 제공하는 어드민 런타임(580) 및 테넌트 데이터 소스(594, 604), 글로벌 PDB(610) 및 여러 테넌트 PDB들(612, 614)을 포함한다. 상기 컴포넌트 각각은 복수의 URI들, 예를 들어 http://tenant1.opc, http://tenant2.opc 및 http://internal.opc, 을 통해 상위 스택 컴포넌트들에 액세스가능하게할 수 있다.

다양한 실시예들에 따라, FAMT 런타임에서 여러 서로 다른 용도들이 있으며, 그 중 몇 예들이 아래에 설명되어있다. 일부 메타데이터의 테넌트-특정 커스터마이제이션을 고르는데 사용할 테넌트 데이터베이스 파티션을 선택하기 위해 MetaDataService에 의해 사용된다.

예를 들어, 이는 실시될 필요가 있는 보안 정책들을 고르기 위해 상기 테넌트 데이터베이스를 선택하기 위해 OPSS에 의해 사용될 수 있다. 또한 테넌트를 위한 상기 감사 정책을 결정하고 상기 감사 로그를 저장하는 상기 테넌트 데이터베이스 파티션을 선택하기 위해 감사 서비스에 의해 사용될 수 있다.

테넌시 컨텍스트가 명시적으로 설정되지 않은 때, 이는 다음과 같이 상기 스레드의 상기 현재 파티션 컨텍스트로부터 얻어진다. 요청이 WLS에 들어간 때, 적절한 컨테이너는 상기 요청의 타겟 컴포넌트의 다양한 디테일들을 결정하고 상기 호출(invocation)을 표현하기 위해 ComponentInvocationContext 객체를 생성한다. 유사하게, WLS가 타이머 만료와 같은 몇몇 비동기 동작의 일부로 콜백 객체를 호출하면 상기 스레드에 상기 올바른 호출 컨텍스트가 설정된다. ComponentInvocationContext의 일부로서, 파티션 정보도 또한 유지된다. 상술한 상기 온보딩 프로세스는 상기 현재 파티션에 대한 상기 필요한 매핑을 상기 테넌시 컨텍스트를 통해 이용가능한 상기 현재 테넌트 값으로 제공한다.

글로벌 테넌시

전형적으로, 상기 시스템의 관리 코드는 보통 모든 테넌츠들을 표현하는 MT 관리자의 상기 컨텍스트에서 실행될 필요가 있다. 실시예에 따르면, 이 특별 상태는 상기 현재 요청과 관련된 테넌트 컨텍스트가 없음을 표시하는 상기 널 테넌트 ID와 다른, "GLOBAL"로 불리는 특별 테넌트 ID로 표현된다.

GLOBAL 데이터베이스를 사용하려고 하는 임의의 소프트웨어 코드는 GLOBAL 데이터베이스에 항상 연결하는 데이터소스에 대한 고정 참조를 유지해야한다. 상기 GLOBAL 런타임에서 실행되는 코드에는 특정 테넌트 DB에 대한 고정 바인딩이 없지만, 대신 상기 동작상 컨텍스트에 종속된 테넌트 DB로부터 상기 데이터를 액세스한다. 테넌트 DB들이 상기 시스템에 미리 프로비저닝되어 있지 않으므로 프록시 데이터 소스(예컨대, ProxyDataSource)가 사용될 수 있으며, 상기 코드는 상기 현재 테넌트 컨텍스트에 기초한 특정 기초 DB를 선택하는 상기 프록시 데이터 소스에 대한 고정 JNDI 참조를 계속 진행할 수 있다.

FMW/FA 코드가 아래 기술된 바와 같이 WLS 외부에서 실행되는 것을 요구하는 두 개의 별개의 사용 케이스들이 있다. 어떤 라이프사이클 동작들 및 관리 동작들은 자바 SE 환경에서 발생한다. 비지니스 프로세스 관리의 일부로, 상기 서버 코드가 가끔 특정 테넌트의 컨텍스트에서 작동하는 장기 실행중인 자바 프로세스를 포크화(fork)한다.

JNDI와 상기 프록시 데이터 소스를 통해 이용가능하게 된 프록시 데이터 소스에 대한 단일 참조를 가지는 것은 테넌시 컨텍스트를 사용하여 적절한 기초 데이터베이스로의 상기 호출들의 위임을 처리한다. 상기 작업을 처리하기 위해, 상기 테넌시 컨텍스트가 자바 SE 프로세스의 상기 스레드에서 올바르게 세팅되야한다. 테넌트 이름 및 테넌트 id에 대한 상기 시스템 프로퍼티들을 사용하여 상기 GLOBAL 테넌트 컨텍스트를 전달하는 것에 의해 상기 자바 SE 프로세스가 시작되어야한다. 상기 포크화된 자바 프로세스는 이 정보를 사용하고 상기 실행 스레드에 상기 테넌시 컨텍스트를 설정하기 위해 switchTenantContext를 호출한다.

자바 SE에서 글로벌 테넌시 체크

실시예에 따르면, executeAs를 할 수 있기 위해서, 상기 시스템은 상기 현재 테넌트 컨텍스트가 글로벌인지 보장해야한다. 이는 현재 테넌트 컨텍스트에서 상기 테넌트 ID가 0과 동일한지 체크하는 것에 의해 완료될 수 있다.

도 13은 실시예에 따르면, 멀티테넌트 어플리케이션 서버 환경에서 테넌트 온보딩을 제공하는 방법의 흐름도를 도시한다.

도 13에 도시된 바와 같이, 단계 630에서, 하나 이상의 파티션들을 지원하는 소프트웨어 어플리케이션들의 실행을 위한 도메인을 포함하는 하나 이상의 컴퓨터에 어플리케이션 서버 환경이 제공되며, 각 파티션은 상기 도메인의 관리 및 런타임 서브디비전을 제공하고 파티션은 배포가능한 어플리케이션들 또는 리소스들의 컬렉션을 갖는 및/또는 리소스 그룹 템플릿을 참조하는 하나 이상의 리소스 그룹들을 선택적으로 포함할 수 있다.

단계 632에서, 예를 들어 어플리케이션 서버들, 트래픽 디렉터들 또는 로드 밸런서들, 및 데이터베이스 또는 고유의 파티션-특정 구성들을 가질 수 있는 다른 컴포넌트들과 같은 서로 다른 컴포넌트에 걸쳐서 구성 통합을 가능하게 하는 라이프사이클 관리자가 제공된다.

단계 634에서, 테넌트 온보딩 및/또는 구성 인터페이스가 제공되며, 테넌트가 상기 시스템에 온보드되는 것에 대한 테넌트 구성을 정의하게 한다.

단계 636에서, 테넌트 온보딩 동안, 상기 시스템은 고유 식별자, 환경 및 특정 테넌트에 대한 파티션 컨텍스트를 매핑하는 테넌트 컨텍스트를 갖는 테넌트를 생성하기 위해 상기 테넌트 구성 정보를 사용한다.

단계 638에서, 상기 시스템은 선택적으로 테넌트 스위칭 인터페이스를 통해 상기 테넌트의 상기 컨텍스트를 스위치할 수 있고, 상기 테넌트 온보딩 동안, 테넌트로서 또는 테넌트를 대신하여 기능들을 실행할 수 있다.

컴포넌트 라이프사이클 플러그인들

실시예에 따르면, 상기 단대단 라이프사이클 인프라스트럭처는 멀티-테넌트 어플리케이션 서버 환경 내의 상기 서로 다른 컴포넌트들이 고유의 컴포넌트-특정 라이프사이클 기능을 제공하기 위해 라이프사이클 플러그인을 사용하게 하는 플러그인-기반 메커니즘이 포함된다.

도 14는 실시예에 따르면, 멀티테넌트 어플리케이션 서버 환경에서 라이프사이클 플러그인들을 도시한다.

상술한 바와 같이, 실시예에 따르면, 상기 시스템은 상기 파티션 및 트래픽 디렉터 컴포넌트, 데이터베이스 컴포넌트, 또는 다른 컴포넌트들과 같은 다른 컴포넌트들의 라이프사이클 관리를 가능하게하는 라이프사이클 관리자(LCM) 및 라이프사이클 인터페이스를 포함하는 라이프사이클 조정 프레임워크를 포함할 수 있다.

예를 들어, 도 14에 도시된 바와 같이, 상기 라이프사이클 인터페이스는 파티션 라이프사이클 플러그인(650), 어플리케이션 서버 라이프사이클 플러그인(652), 트래픽 디렉터 라이프사이클 플러그인(654) 및 데이터베이스 라이프사이클 플러그인(656), 또는 다른 타입들의 플러그인의 사용을 지원할 수 있다.

각각의 라이프사이클 플러그인은 예를 들어, 어플리케이션 서버, 예컨대, WebLogic, WLS 또는 트래픽 디렉터 또는 다른 로드 밸런서, 예컨대, 오라클 트랙픽 디렉터, OTD 인스턴스 라이프사이클과 같은 상기 라이프사이클 요구들을 요약(encapsulate) 할 수 있다. 상기 라이프사이클 인터페이스는 임의의 컴포넌트의 상기 라이프사이클을 관리하기 위한 각각의 플러그인에 대한 공통 또는 일반적 프로세스를 제공한다.

도 15는 실시예에 따르면, 멀티테넌트 어플리케이션 서버 환경에서 라이프사이클 플러그인들을 더 도시한다.

도 15에 도시된 바와 같이, 상기 라이프사이클 플러그인들은 파티션 라이프사이클 관리(660), 또는 데이터베이스 라이프사이클 관리(662)에 기여할 수 있다.

예를 들어, OTD 인스터스는 특정 도메인상의 파티션을 생성하는데 사용하기 위해, 상기 라이프사이클 관리자에게 WLS 런타임을 생성하도록 요청할 수 있다. 상기 라이프사이클 관리자는 사실상 상기 도메인의 표시를 제공하는 것과 상기 플러그인이 해당 도메인에서 파티션을 생성하는 것을 요청하는 것을 각각의 플러그인들 생성 방법에 위임한다.

다양한 실시예들에 따라, 유사한 플러그인 기능은, 예컨대, 다른 데이터베이스, 트래픽 디렉터, 또는 다른 컴포넌트들을 지원하고, 이용가능한 때에 서버들을 생성, 삭제, 중지, 시작, 정지, 마이그레이션 할 수 있도록 제공될 수 있다. 각각의 플러그인은 상기 라이프사이클 관리자를 통해 지원되는 각각의 컴포넌트에 대해 구현될 수 있다.

A. 어플리케이션 서버 플러그인

실시예에 따르면, 상기 시스템은 상기 라이프사이클 API들을 구현하고 어플리케이션 서버(예컨대, WLS) 파티션들의 상기 생성 또는 구성을 관리하기 위해 어플리케이션 서버(예컨대, WebLogic, WLS) 라이프사이클 플러그인을 포함할 수 있다.

라이프사이클 관리자와의 상호작용

실시예에 따르면, 상기 어플리케이션 서버 플러그인은 등록-플러그인 동작을 사용하여 상기 라이프사이클 관리자에 등록될 수 있다. 후속적으로, 상기 라이프사이클 관리자에 어플리케이션 서버(예컨대, WLS) 런타임을 등록하면, 라이프사이클 관리자와 상호작용하는 상기 클라이언트는 라이프사이클 관리자에 등록된 상기 특정 런타임상에서 파티션을 생성/업데이트/삭제하기 위해 상기 라이프사이클 관리자를 REST 호출할 수 있다.

상기 어플리케이션 서버와의 통신

실시예에 따르면, 상기 어플리케이션 서버 플러그인은 상기 서버와 상호작용하기 위해 상기 어플리케이션 서버(예컨대, WLS)에 의해 노출되는 JMX/REST API들을 사용할 수 있다. 상기 플러그인은 타겟된 어플리케이션 서버 런타임들에서 라이프사이클 동작들을 수행하여 어플리케이션 서버 파티션들에서 CRUD 동작을 수행할 수 있도록 라이프사이클 관리자로부터의 상기 파티션 플러그인 계약을 구현할 수 있다.

실시예에 따르면, 상기 어플리케이션 서버 플러그인은 타겟된 어플리케이션 서버(예컨대, WLS) 런타임들 상에서 라이프사이클 동작들을 할 수 있게 하기 위해 상기 라이프사이클 관리자로부터 상기 런타임 플러그인 계약을 구현할 수 있다. 예를 들어:

파티션들 상의 라이프사이클 동작들에 대한 런타임 프로퍼티들

실시예에 따르면, 상기 어플리케이션 서버 플러그인은 어플리케이션 서버, 예컨대 WLS, 런타임에 연결하기 위해 다음 프로퍼티들을 사용한다. 상기 프로퍼티들은 상술한 계약에서 특정된 것으로서 라이프사이클 런타임 객체를 통해 상기 라이프사이클 동작으로 전달된다.

WLS 플러그인에 대한 라이프사이클 컨텍스트

실시예에 따르면, 어플리케이션 서버 플러그인을 사용하여 완료된 임의의 CRUD 동작은 상기 라이프사이클 컨텍스트에서 상기 플러그인에 제공된 상기 정보/데이터에 기초하여 커스터마이즈되게 할 수 있다. 상기 클라이언트는 REST 호출의 일부로서 상기 프로퍼티들을 특정할 수 있다. 상기 라이프사이클 관리자는 상기 데이터를 상기 라이프사이클 컨텍스트에 채우고(populate) 상기 프로퍼티를 다시 상기 플러그인에 전달한다. 예를 들어, 클라이언트가 WLS 파티션에 대한 createPartition을 REST 호출할 때, 파티션의 상기 어트리뷰트들을 특정하는 상기 프로퍼티들을 특정할 수 있다.

파티션 생성/ 업데이트를 위한 라이프사이클 컨텍스트

실시예에 따르면, 다음은 파티션 동작을 생성/업데이트하는 동안 상기 클라이언트에 의해 특정될 수 있는 일부 대표적인 프로퍼티들이다. 상기 구성들은 파티션 생성/업데이트의 일부로 생성되고 상기 파티션에 따라 특정된다.

실시예에 따르면, 다음은 파티션을 생성/업데이트하는 동안 상기 클라이언트에 의해 특정될 수 있는 일부 대표적인 프로퍼티들이다. 상기 어플리케이션 서버(예컨대, WLS) 서버에서 이러한 엔티티들을 찾는데 실패하면 상기 어플리케이션 서버 플러그인에서 예외가 발생하는 결과가 발생한다.

삭제 파티션에 대한 라이프사이클 컨텍스트

실시예에 따르면, 어플리케이션 서버(예컨대, WLS) 파티션을 삭제하기 위해 파티션 이름 외 다른 추가 프로퍼티들이 요구되지 않는다.

관련 파티션에 대한 라이프사이클 컨텍스트

실시예에 따르면, 어플리케이션 서버 인스턴스와 또 다른 컴포넌트를 관련시키는 것은 일부 새로운 프로퍼티들로 상기 어플리케이션 서버(예컨대, WLS)를 업데이트하는 것을 포함할 수 있거나, 또는 관련을 위해 상기 다른 컴포넌트에 상기 필수 프로퍼티들을 제공하는 것을 포함할 수 있다.

관련에 참여하려는 임의의 컴포넌트는 상기 특정된 포맷으로 라이프사이클 컨텍스트에서 상기 정확한 프로퍼티들의 세트를 전달할 필요가 있다.

WLS-OTD 관련의 경우, 이 케이스에서, 상기 OTD 파티션은 상기 클러스터-이름, 클러스터-멤버들 또는 타겟 정보가 상기 관련을 수행할 것으로 기대한다. 상기 어플리케이션 서버 플러그인은 상기 파티션 이름에 기초하여 상기 올바른 타겟팅 정보를 페치하기 위해 상기 어플리케이션 서버 런타임에 대한 JMX/REST 호출을 한다. 상기 프로퍼티들은 associatePartition 구현의 일부로서 상기 어플리케이션 서버의 lifecycleContext에 추가된다. 상기 플러그인에 대한 관련 호출의 일부로서, 타겟 구성의 완전한 스냅샷이 상기 라이프사이클 컨텍스트에 추가될 것이다. 그 다음, 상기 라이프사이클 관리자는 원래 서버 풀과 상기 어플리케이션 서버 파티션의 상기 연결을 수행하기 위해 상기 라이프사이클 컨텍스트(WLS 타겟들의 상기 프로퍼티들을 가진)를 사용하여 OTD 플러그인의 상기 associatePartition 구현을 호출한다.

실시예에 따르면, 어플리케이션 서버(예컨대, WLS) 파티션이 OTD 파티션과 관련되어있고, 상기 파티션이 구성된 클러스터를 타겟으로 하는 때, 서버가 실행되고 있지 않은 경우, 상기 라이프사이클 관리자는 서버의 ListenAddress 및 포트에 이용가능한 구성 정보를 얻을 것이고 이를 OTD에 전송할 것이다. 서버들이 실행중인 경우, RuntimeMBean에서 이용가능한 서버에 대한 상기 런타임 정보를 얻을 것이고 컨텍스트 정보를 통해 이를 OTD로 전달할 것이다.

동적 클러스터에서, 비록 상기 구성 시간 정보는 동적 서버들의 포트들에서 이용가능하지만, ListenAddress에 이용가능한 구성 정보는 없다. 관련 호출이 발생할 때 동적 서버들이 실행중이지 않은 경우 상기 라이프사이클 관리자는 상기 구성된 포트와 상기 노드 관리자들의 ListenAddress(동적 서버들이 머신과 관련된 경우)를 가져올 것이고 이를 다른 플러그인들에 보낼 것이다. 관련 호출이 발생할 때 동적 서버들이 실행중인 경우 상기 라이프사이클 관리자는 런타임 Mbean에서 상기 서버 수신 주소와 포트를 가져올 것이고 이를 상기 OTD 플러그인들에 보낼 것이다.

WLS-DB 관련 케이스의 경우, 이 케이스에서, 상기 어플리케이션 서버(예컨대, WLS) 플러그인의 associatePartition 방법은 상기 DB 파티션의 lifecycleContext를 사용하여 PDB Info를 채우고 상기 PDB info로 상기 WLS 파티션을 업데이트한다.

분리 파티션에 대한 라이프사이클 컨텍스트

실시예에 따르면, 상기 어플리케이션 서버(예컨대, WLS)와 다른 컴포넌트와의 분리는 djEJs WLS 파티션 구성을 제거/업데이트하는 것을 포함할 수 있다. 분리에 참여하기 원하는 임의의 컴포넌트는 상기 특정된 포맷의 라이프사이클 컨텍스트에서 상기 정확한 프로퍼티들의 세트를 전달할 필요가 있다. 다음은 WLS와 DB 파티션들간의 분리를 설명하는 예이다.

WLS-DB 분리 : 이 케이스에서, 상기 WLS 플러그인의 dissociatePartition 방법은 상기 PDB info를 제거하는 것에 의해 PDB Info name에 채우고 상기 WLS 파티션을 업데이트하기 위해 상기 DB 파티션의 lifecycleContext를 사용한다. 상기 WLS 플러그인은 상기 lifecycleContext에서 상기 PDB Info 이름을 기대한다.

WLS-OTD 분리 : 이 케이스에서, 상기 OTD 파티션은 상기 OTD 파티션은 상기 클러스터-이름, 클러스터-멤버들 또는 타겟 정보가 상기 분리를 수행할 것으로 기대한다. WLS 플러그인은 상기 파티션 이름에 기초하여 상기 올바른 타겟팅 정보를 페치하기 위해 상기 WLS 런타임에 대한 JMX/REST 호출을 한다. 상기 프로퍼티들은 dissociatePartition 구현의 일부로 상기 WLS의 lifecycleContext에 추가된다.

LCM 환경에서 WLS 파티션 구성 발견 및 관련

실시예에 따르면, 상기 파티션 구성은 상기 라이프사이클 관리자 환경/범위의 외부에서 생성/업데이트/삭제될 수 있다. 예를 들어, 관리자가 WLST 명령을 호출하여 파티션을 생성하거나, WLS 어드민 콘솔을 사용하여 파티션을 업데이트할 수 있다. 어떠한 경우라도, 상기 라이프사이클 관리자에 있는 상기 파티션 정보가 최근에 가장 업데이트되었는지 확인될 것을 요구한다.

어플리케이션 서버 구성들상에 라이프사이클 관리자 런타임 스케일링의 영향

실시예에 따르면, 상기 어플리케이션 서버(예컨대, WLS) 플러그인의 ScaleUp 및 scaleDown 동작은 상기 동적 클러스터의 일부인 상기 서버 인스턴스들을 시작 또는 중지하는 상기 기능을 제공하기 위해 사용될 수 있다. 상기 WLS 플러그인은 상기 서버들을 시작/중지하기 위해 상기 머신들/서버들과 상호작용하는 노드 관리자를 사용할 수 있다.

탄력성 프레임워크들은 상기 클러스터 정보, 스케일 팩터, 런타임 타입(즉, WLS) 인터셉터들과 함께 라이프사이클 관리자에 대한 확장 또는 축소 호출을 할 수 있으며, 상기 scaleUp / scaleDown에 등록된 인터셉터들은 상기 클러스터를 확장하는데 필요로 하는 상기 필수 인프라스트럭처를 확인하고 수행하기 위해 확장/축소 동작 전에 호출된다.

예를 들어, 상기 클러스터에 상기 새 서버들을 가져오는데 필요로 하는 상기 데이터소스들의 수를 결정/생성하기 위해 WLS 런타임에 상기 필수 호출을 한다. 상기 클러스터 확장/축소에 대한 상기 전제조건들이 충족되면(즉, 상기 인터셉터의 어느 사전-호출이 충족되면), 상기 실제 확장 또는 축소가 발생한다. 상기 인터셉터들은 상기 후속-호출 요구사항들을 충족하기 위해 상기 플러그인에서 상기 동작이 완료된 후 다시 호출된다.

예를 들어, 다수의 인터셉터들이 WLS 클러스터를 스케일하기 위해 사용될 것이라고 가정하면, 후술되는 하나의 시퀀스가 설명된다.

탄력성 모듈로부터 WLSScaleDownAction이 lcm.scaleDown(clusterName, factor, payload)를 호출할 때 다음 인터셉터들 : WLS 인터셉터, OTD 인터셉터, JMS 인터셉터, 데이터소스 인터셉터이 추가되었다고 가정한다. 1. WLS 인터셉터는 스케일링이 클러스터 한계들내에 있을지 체크한다. 그 다음 ctx.proceed();를 호출한다. 2. OTD 인터셉터는 상기 선택된 타겟들이 소모되도록(drain) 표시(mark)하기 위한 상기 필수 OTD config 변화들이 있게 할 것이다. OTD 인터셉터는 OTD 메트릭들이 상기 요청들이 소모되었음을 표시할 때까지 기다릴 것이다. 그 다음 ctx.proceed();를 호출한다. 3. JMS 인터셉터는 상기 JMS 백로그들이 소모될때까지 기다릴 것이다. 그 다음 ctx.proceed();를 호출한다. 4. 데이터소스 인터셉터는 모든 JDBC 연결들이 상기 풀로 리턴되었는지 보장할 것이다. 그 다음 ctx.proceed();를 호출한다. 5. 상기 서비스는 축소된다(상기 마지막 인터셉터 후에 ElasticServiceManager에 의해 호출됨)

인터셉터 호출 체인의 상기 리턴 경로상에서: 1. DataSourceInterceptor는 상기 나머지 활성 관리 서버들에 대해 상기 maxconnectionpoolsize를 적절히 증가시킬 것이다. 2. JMS 인터셉터는 아무것도 하지 않는다. 3. OTD 인터셉터는 아무것도 하지 않는다. 4. WLS 인터셉터는 아무것도 하지 않는다.

REST 요청들을 사용한 어플리케이션 서버 플러그인 호출

실시예에 따르면, 라이프사이클 관리자 클라이언트들은 다음 예를 포함한 상기 WLS 상 동작들을 수행하기 위해 REST 요청들을 사용할 수 있다. 1. WLS 런타임 및 상기 REST 요청이 전달될 상기 프로퍼티들 등록 2. 빈 WLS 파티션 생성 3. 리소스 그룹 및 타겟팅이 있는 WLS 파티션 생성 4. 환경에 WLS 파티션 추가(환경 테스트1이 이미 생성되었다고 가정) 5. WLS 파티션을 다른 파티션과 관련 6. WLS 파티션을 다른 파티션과 분리 6. WLS 파티션 삭제 7. WLS 파티션 업데이트.

B. 데이터베이스 플러그인

실시예에 따르면, 상기 시스템은 상기 라이프사이클 API들을 구현하고 데이터베이스(예컨대, Database) 파티션들의 상기 생성 또는 구성을 관리하는 데이터베이스(예컨대, 오라클 Database) 라이프사이클 플러그인을 포함할 수 있다.

실시예에 따르면, 상기 오라클 데이터베이스와 같은 데이터베이스 컴포넌트의 상기 멀티테넌트-인식 아키텍처는 고객-생성 플러그가능 데이터베이스들(PDB들)을 포함한 멀티테넌트 컨테이너 데이터베이스(CDB)로서 기능할 수 있다. 각 PDB는 스키마들, 스키마 객체들 및 비스키마 객체들의 포터블 집합으로 동작한다. 상기 라이프사이클 관리자 모듈의 상기 관점에서, 상기 데이터베이스 컴포넌트는 상기 데이터베이스 머시너리에 내장된 상기 PDB 기능들을 사용하여 고유의 파티션 구성을 관리한다. 상기 데이터베이스 라이프사이클 플러그인은 상기 라이프사이클 관리자에 의해 요청될 때 PDB 관리 동작들을 수행하기 위해 이 기능을 활용할 수 있다.

라이프사이클 관리자와의 상호작용

실시예에 따르면, 상기 데이터베이스 플러그인은 상기 라이프사이클 관리자 파티션 플러그인 인터페이스의 구현이고, 어떤 동작들을 수행할 수 있기 전에 라이프사이클 관라지에 등록된다. 후속적으로, 상기 라이프사이클 관리자에 데이터베이스 런타임을 등록하면, 라이프사이클 관리자와 상호작용하는 상기 클라이언트는 라이프사이클 관리자에 등록된 상기 특정 런타임상에 PDB 동작들을 수행하기 위해 상기 라이프사이클 관리자에게 REST 호출을 요청한다.

런타임 등록

실시예에 따르면, 데이터베이스상에서 동작이 수행될 수 있기 전에, 상기 라이프사이클 관리자에 등록되어야 한다. 상기 등록 프로세스는 상기 데이터베이스에 연결하는데 사용되는 정보를 요구한다. 예를 들어, 데이터베이스 런타임은 다음 프로퍼티들로 등록될 수 있다.

상기 데이터베이스 상 라이프사이클 동작들

실시예에 따르면, 상기 데이터베이스 라이프사이클 플러그인은 JDBC를 통해 원격 SQL 연결을 사용하여 상기 데이터베이스와 통신한다. 상기 런타임 등록동안 특정된 프로퍼티들은 상기 데이터베이스에 연결하기 위해 사용된다. 다수의 라이프사이클 동작들이 상기 라이프사이클 컨텍스트 객체에서 전달된 상기 프로퍼티들로부터 결정되고 상기 플러그인에 전달되는 다양한 절, 해당 SQL 명령들에 매핑된다.

실시예에 따르면, 다음은 예들과 함께 상기 동작들의 세부사항들이다.

생성

실시예에 따르면, 상기 생성 동작은 다음 태스크들을 수행한다. (1) 상기 특정된 데이터베이스 런타임 상에 플러그가능 데이터베이스를 생성한다. 상기 새로 생성된 PDB의 상기 파티션 ID는 상기 V$PDBS 테이블로부터 획득된다. 상기 파티션 이름은 상기 PDB 이름과 동일하다. (2) 선택적으로, 데이터베이스 사용자를 생성한다. (3) 선택적으로, 존재하는 CDB 계획을 사용하여 상기 PDB에 대한 CDB 계획 지시를 생성한다. 상기 태스크들에는 다수의 옵션들이 이용가능하다. 이러한 옵션들은 상기 라이프사이클 컨텍스트 객체의 프로퍼티들로서 상기 플러그인에 전달된다.

삭제

실시예에 따르면, 상기 삭제 동작은 다음 태스크들을 수행할 수 있다. (1) 상기 PDB 이름을 사용하여 상기 플러그가능 데이터베이스를 드랍한다. PDB 사용자는 또한 자동적으로 드랍될 것이다. (2) 선택적으로, 위 태스크들을 위해 상기 플러그인에 의해 실행되는 상기 PDB 샘플 SQL에 대한 CDB 계획 지시를 드랍한다.

업데이트

실시예에 따르면, 상기 업데이트 동작은 상기 PDB에 대한 상기 업데이트들을 수행하기 위한 ALTER PLUGGABLE DATABASE 명령 실행에 의해, 플러그가능 데이터베이스의 상기 어트리뷰트들을 수정한다.

관련

실시예에 따르면, 상기 관련 동작은 WLS 파티션이 PDB와 관련될 때 연관된다. 관련 동안, 상기 데이터베이스 플러그인이 상기 데이터베이스 연결 URL을 상기 WLS 플러그인에 전달한다. 라이프사이클 관리자에 의해 상기 PDB를 생성하는 동안 사용자가 생성되었던 경우, 상기 사용자 이름과 비밀번호는 또한 상기 WLS 파티션 플러그인에 전달된다.

정지

실시예에 따르면, 상기 정지 동작은 상기 ALTER PLUGGABLE DATABASE 명령을 사용하여 상기 특정된 PDB를 닫는다.

시작

실시예에 따르면, 상기 시작 동작은 상기 ALTER PLUGGABLE DATABASE 명령을 사용하여 상기 특정된 PDB를 시작한다.

라이프사이클 컨텍스트 스키마

실시예에 따르면, 라이프사이클 컨텍스트 객체를 통해 상기 플러그인에 전달되는 프로퍼티들로부터 다양한 SQL 절들이 형성된다. 상기 일반적인 프로퍼티들 중 일부는 다음을 포함한다.

실시예에 따르면, 상기 SQL 명령들과 다양한 절들은 라이프사이클 컨텍스트 프로퍼티들로서 특정될 수 있다. 상기 데이터베이스 지원에 종속하여, 상기 PDB를 변경할 때 마찬가지로 상기 대부분 프로퍼티들이 사용될 수 있다.

리소스 관리자 프로퍼티들

실시예에 따르면, PDB를 생성할 때, CDB 계획 지시는 또한 생성될 수 있다. 이것과 관련된 프로퍼티들은 상기 키 "resourceManager" 아래에 특정되어야 한다. 다음은 상기 "resourceManager"의 대표적인 프로퍼티들이다.

사용자 프로퍼티들

실시예에 따르면, PDB를 생성할 때, 사용자 또한 생성될 수 있다. 상기 사용자와 관련된 상기 프로퍼티들은 상기 키 "databaseUser" 아래에 특정되어야 한다.

도 16은 실시예에 따르면, 멀티테넌트 어플리케이션 서버 환경에서 라이프사이클 플러그인들을 지원하는 방법의 흐름도를 도시한다.

도 16에 도시된 바와 같이, 단계 680에서, 어플리케이션 서버 환경은 하나 이상의 파티션들을 지원하는 소프트웨어 어플리케이션들의 실행을 위한 도메인을 포함하는 하나 이상의 컴퓨터들에서 제공되며, 각 파티션은 상기 도메인의 관리 및 런타임 서브디비전을 제공하고 파티션은 배포가능한 어플리케이션들 또는 리소스들의 컬렉션을 갖는 및/또는 리소스 그룹 템플릿을 참조하는 하나 이상의 리소스 그룹들을 선택적으로 포함할 수 있다.

단계 682에서, 예를 들어 어플리케이션 서버들, 트래픽 디렉터들 또는 로드 밸런스들, 및 데이터베이스 또는 자신의 파티션-특정 구성들을 가질 수 있는 다른 컴포넌트들과 같은 서로 다른 컴포넌트들에 걸쳐서 구성 통합을 가능하게 하는 라이프사이클 관리자가 제공된다.

단계 684에서, 각 상기 라이프사이클 관리자 및 그 컴포넌트 사이에 브릿지를 제공하는 라이프사이클 플러그인을 포함하는 복수의 컴포넌트들이 제공된다.

단계 686에서, 파티션의 생성 또는 구성 동안, 상기 복수의 라이프사이클 플러그인들은 상기 라이프사이클 관리자가 플러그인을 호출할 수 있는 라이프사이클 동작들을 수행할 수 있게 하는 인터페이스를 구현하며, 따라서 상기 플러그인은 상기 컴포넌트의 실제 생성 또는 구성을 수행하기 위해 관련된 컴포넌트와 함께 동작할 수 있다.

글로벌 런타임

실시예에 따르면, 상기 시스템은 상기 멀티-테넌트 어플리케이션 서버 환경 내에서 글로벌 런타임의 상기 사용을 지원한다.

상술한 바와 같이, 퓨전 앱들 또는 퓨전 미들웨어를 사용하는 것과 같은, 다양한 실시예들에 따라, 모든 파티션들에 대한 글로벌 컨텍스트에서 실행되는 것들을 위한 요구사항들이 있을 수 있다.

예를 들어 퓨전 미들웨어(FMW)의 일부로서 제공되는 메타데이터 서비스들(MDS) 컴포넌트에는, 모든 상기 공유된 문서들에 대한 하나의 글로벌 캐시와 그 다음 상기 테넌트에 특정하는 상기 커스터마이제이션들을 위한 파티션 특정 캐시들이 있어야 한다. 이와 같은 글로벌 캐시가 있는 것에 더하여, 상기 캐시가 제거(purge)되거나 업데이트될 때, 상기 모든 파티션들에 알리는 상기 요구사항 또한 있으며, 따라서 상기 파티션에서 실행중인 상기 MDS 인스턴스는 상기 업데이트된 캐시 상에 상기 커스터마이제이션들을 적용할 수 있다.

게다가, 멀티-테넌트 환경의 높은 레벨에서 글로벌 아티팩트들로서 여기서 참조되는 임의의 파티션들을 포함하여, 상기 전체 도메인에서 공유될 것이 요구되는 아티팩트들 또는 다른 컴포넌트들이 있을 수 있다. 상기 아티팩트들은 상기 글로벌 런타임으로서 참조되는 멀티테넌트 컨테이너에서 상기 글로벌 또는 도메인 레벨에 상주하거나 실행된다. 상기 파티션 특정 아티팩트들 또는 컴포넌트들은 파티션의 상기 컨텍스트에서 상주하거나 실행되는 것이다.

실시예에 따르면, 상기 글로벌 런타임은 임의의 파티션에서 실행되지 않고, 대신 도메인으로 범위지정된다. 예를 들어, 퓨전 어플리케이션들(FA) 및 멀티-테넌시 플래그가 활성화된 상기 테넌트 매핑과 함께, 자바 요구되는 파일들(JRF) 도메인에서 실행될 때, 상기 글로벌 런타임 내 실행되는 코드는 테넌트의 상기 컨텍스트로 스위치할 수 있고 테넌트 스위칭(예컨대, switchTenant) API를 통해 테넌트 대신 무언가를 실행할 수 있다.

실시예에 따르면, 또한 상기 글로벌 런타임에서 사용하기 위해 하나 이상의 리소스 그룹들이 상기 도메인 레벨에서 또한 특정될 수 있다. 도메인 레벨 리소스 그룹들의 타겟팅은 상기 리소스 그룹 내에 상기 개별 리소스들이 아니며, 상기 리소스 그룹에서 세팅된다. 상기 그룹 내 모든 리소스들은 상기 리소스 그룹에서 특정된 모든 타겟들을 타겟되게 할 것이다. 클러스터로 타겟될 때, 상기 어플리케이션들은 상기 클러스터내의 상기 모든 관리 서버들 상에서 실행된다.

실시예에 따르면, 상기 도메인 레벨 상기 리소스 그룹은 관련된 리소스들을 그룹화하는 편리한 방법이다. 상기 시스템은 그룹화되지 않은 리소스들과 같이 도메인 레벨 리소스 그룹에서 선언된 상기 리소스들을 관리한다: 예를 들어, 시스템 스타트업 중에 시작되고 또는 시스템 셧다운 중에 정지되는 경우이다. 또한, 관리자는 그룹의 단일 리소스를 개별적으로 중지, 시작 또는 제거할 수 있으며 또한 상기 그룹에서 동작하여 그룹의 모든 상기 리소스들에 대해 묵시적으로 동작할 수 있다.

예를 들어, 상기 그룹을 중지하면 아직 중지되지 않은 상기 그룹의 모든 상기 리소스들이 중지된다. 상기 그룹을 시작하면 아직 시작되지 않은 상기 그룹의 임의의 리소스들이 시작된다. 상기 그룹을 제거하면 상기 그룹에 포함된 모든 상기 리소스들이 제거된다.

실시예에 따르면, 상기 글로벌 런타임 리소스 그룹(들)은 파티션(들)에 정의된 모든 상기 다른 리소스 그룹들보다 먼저 시작되어야 한다. 이는 상기 글로벌 런타임이 상기 어떤 파티션들 전에 초기화되도록하며, 필요한 경우 상기 파티션들을 초기화하기 전에 상기 공유된 클래스 로더를 사용하여 공유된 클래스들을 로드하여 파티션들이나 다들 어플리케이션들/리소스 그룹들간에 공유할 수 있다.

실시예에 따르면, 상기 글로벌 런타임이 실행될 때, 상기 파티션 이름은 GLOBAL을 리턴할 것이고, 상기 아이디는 0이 될 것이다.

상기 멀티테넌시 플래그가 활성화된 JRF 도메인에서 실행중일 때, 상기 테넌트 컨텍스트는 GLOBAL로서 설정된 테넌시를 가질 것이며, 상기 테넌트 아이디 또한 0이 될 것이다.

실시예에 따르면, 상기 글로벌 런타임에서 정의된 리소스 그룹들은 상기 글로벌 런타임에서 실행중인 어플리케이션들이 클래스들을 동작하거나 공유하려고하는 파티션들로서 상기 동일한 관리 서버들/클러스터들을 타겟으로 해야한다.

도 17은 실시예에 따르면, 멀티테넌트 어플리케이션 서버 환경에서 글로벌 런타임의 사용을 도시한다.

실시예에 따르면, 상기 글로벌 런타임은 상기 도메인 레벨에서 실행하려고 의도되는 상기 어플리케이션들에 사용될 수 있다. 특정 컴포넌트 또는 어플리케이션이 executeAs를 사용하기 원하는 경우, 상기 글로벌 런타임 내 상기 도메인 레벨에서 실행해야만하고, 상기 글로벌 런타임은 상기 도메인 런타임과 동일하거나 또는 상기 도메인 런타임으로서 동작한다.

실시예에 따르면, 상기 ExecuteAs 및 테넌트 온보딩은 상위 스택 사용을 위해 JRF 타입 기능으로서 제공된다. 상기 글로벌 런타임에서 어플리케이션 실행은 해당 파티션들에서 제공되는 상기 보안 설정들에 따라 상기 다양한 파티션들에서 볼 수 있다. 유사하게, 상기 도메인(글로벌) 레벨에서 고유의 UUID로 실행되는 어플리케이션은 상기 파티션들에서 이용가능할 수 있다.

예를 들어, 글로벌 PDB는 테넌트들에 걸쳐서 공유될 수 있으며, 상기 글로벌 PDB는 SaaS 유스케이스(usecase)들과 함께 사용되는 일반적인 구성 셋업인 상기 상위 스택에 의해 설정되고, 통합(consolidation) 또는 PaaS 유스케이스들과는 보통 다르다.

도 17에 도시된 바와 같이, 실시예에 따르면, 상기 글로벌 런타임(700)은 하나 이상의 어플리케이션들을 포함할 수 있고, 하나 이상의 파티션들(710, 712, 714)을 대신하여 액세스 또는 동작하기 위해, 테넌트를 대신하여 executeAs 동작(704, 705)을 수행하기 위한 테넌트 스위칭 API(702)를 사용할 수 있다.

퓨전 앱들 또는 퓨전 미들웨어 시나리오들에서 모든 파티션들의 상기 글로벌 컨텍스트에서 실행중인 것을 위한 요구사항들이 있다. 예를 들어, 메타데이터 서비스들(MDS)의 상기 컨텍스트에서 상술한바와 같이, 모든 상기 공유된 문서들에 대한 하나의 글로벌 캐시와 그 다음 상기 테넌트들에 특정하는 상기 커스터마이제이션들에 대한 파티션-특정 캐시들이 있어야 한다는 요구사항이 있다. 그리고 또한 상기 모든 파티션들은 상기 캐시가 제거되거나 업데이트될 때 알려져야하며, 따라서 상기 파티션들에서 실행중인 상기 MDS 인스턴스는 상기 업데이트된 캐시 상에 상기 커스터마이제이션들을 적용할 수 있다.

파티션 및 테넌트 이름 및 ID

상술한바와 같이, 실시예에 따르면, 상기 글로벌 런타임에서 실행중일 때, 상기 파티션 이름은 GLOBAL을 리턴할 것이고, 상기 아이디는 0이 될 것이다. 상기 멀티테넌시 플래그가 활성화된 JRF 도메인에서 실행중일 때, 상기 테넌트 컨텍스트는 GLOBAL로 설정된 테넌시를 가질 것이며, 상기 테넌트 아이디 또한 0이 될 것이다.

마이그레이션 및 글로벌 런타임

상술한바와 같이, 실시예에 따르면, 상기 글로벌 런타임에서 정의된 리소스 그룹들은 상기 글로벌 런타임에서 실행중인 어플리케이션들이 클래스들을 동작하거나 공유하려고하는 파티션들 때문에 상기 관리 서버들/클러스터들을 타겟으로 해야한다.

실시예에 따르면, 한 클러스터로부터 다른 클러스터로 파티션(또는 해당 리소스 그룹들)을 마이그레이션할 때, 상기 글로벌 런타임은 상기 파티션이 마이그레이션되는 상기 클러스터 상에서 실행중이어야만 하거나 또는, 상기 마이그레이션 기능은 파티션의 상기 리소스 그룹을 마이그레이션 하기 전에 상기 글로벌 런타임에 정의된 상기 리소스 그룹들이 마이그레이션 되었는지 보장해야만 한다.

SaaS 시나리오 예

아래 예는 고객 관계 관리(CRM) 어플리케이션이 상기 글로벌 런타임에 배포되는 상기 SaaS 시나리오의 상기 도메인 레벨에서 리소스 그룹의 사용을 보여준다. 상기 도메인 레벨에서 정의된 상기 리소스 그룹 템플릿은 상기 글로벌 런타임과 마찬가지로 파티션들에 의해서도 사용될 수 있다. 가독성을 위해, 아래 예는 상기 도메인 레벨에서 상기 리소스 그룹만을 보여준다.

실시예에 따르면, 어플리케이션들 및 공유된 라이브러리들은 마찬가지로 상기 도메인 레벨의 리소스 그룹에 배포될 수 있다.

글로벌 PDB 및 테넌트 -특정 PDB

실시예에 따르면, 예컨대 오라클 12c 데이터베이스를 실행할 때, 많은 PDB들은 하나의 컨테이너 데이터베이스(CDB)에서 실행될 수 있다. 테넌트에 대한 파티션의 상기 생성으로, PDB가 생성될 것이고 사용하기 위해 상기 파티션에 대해 상기 데이터 소스가 구성될 것이다.

실시예에 따르면, 상기 테넌트-특정 PDB에 더하여, 모든 테넌트들에 걸쳐서 공유된 글로벌 PDB가 선택적으로 있을 수 있다. 예를 들어, 상기 MDS의 메타데이터(문서들)은 글로벌 PDB 및 상기 테넌트-특정 PDB들의 상기 테넌트-특정 커스터마이제이션들에 저장될 수 있다.

실시예에 따르면, 상기 글로벌 PDB로부터 상기 공유된 데이터를 사용하기 위해, 상기 파티션들이 상기 PDB들(글로벌 및 테넌트-특정) 모두에 액세스할 필요가 있다. 각 파티션은 상기 공유 데이터에 액세스할 수 있도록 상기 글로벌 PDB에 대한 추가, 읽기전용 데이터 소스, 그리고 또한 테넌트-특정 데이터를 저장하는데 사용될 것인 상기 테넌트-특정 PDB에 대한 데이터 소스로 구성될 수 있다. 상기 글로벌 런타임에서 실행중인 상기 공유된 어플리케이션 코드는 상기 글로벌 PDB에 쓸 수 있으며 읽기/쓰기 데이터 소스로 상기 글로벌 PDB에 구성될 것이다.

도 18은 실시예에 따르면, 멀티테넌트 어플리케이션 서버 환경에서 글로벌 런타임의 사용을 더 도시한다.

도 18에 도시된 바와 같이, 실시예에 따르면, 각 파티션은, 예를 들어 상기 글로벌 런타임이 데이터 소스 DS2를 통해 상기 글로벌 PDB(702)에 액세스된 것을 포함하는 하나 이상의 데이터 소스들(701, 711, 721)로 구성될 수 있다.

도 18에 더 도시된 바와 같이, 파티션 1(710) 및 파티션 2(720)에서 실행되는 상기 테넌트들은 DS1를 통해 상기 특정 PDB들(각기 712, 722) 및 상기 글로벌 PDB내의 상기 읽기전용 데이터를 액세스하는 읽기전용 DS2(모든 파티션들에서 공유되는 같은 데이터 소스)에 대한 읽기/쓰기 액세스를 가진다.

데이터소스들

실시예에 따르면, 각 파티션은 테넌트-특성 데이터를 작성하기 위한 상기 PDB 인스턴스를 가리키는 데이터소소들을 가질 것이다. 어플리케이션 서버, 예컨대, WLS의 파티션에서 실행할 때, 상기 데이터 소스의 상기 이름을 각 파티션마다 변경할 필요가 없다. 대신, 상기 어플리케이션 서버는 파티션 기초 별로 상기 JNDI 트리의 상기 데이터 소스를 격리한다. 상기 데이터소스들은 각 테넌트의 파티션에 대한 상기 리소스 그룹으로부터 참조될 상기 리소스 그룹 템플릿에 정의될 수 있다.

글로벌 런타임 및 파티션에서 실행

실시예에 따르면, 상기 글로벌 런타임에 재배포되는 어플리케이션들 또는 공유된 라이브러리들은 파티션에서 실행중인 모든 테넌트-특정 어플리케이션들과 공유될 수 있다. 상기 파티션에 걸쳐서 공유되는 것에 더하여, 상기 글로벌 런타임에서 또한 실행중인 어플리케이션들은 특정된 테넌트의 컨텍스트에서 실행중인 파티션의 상기 컨텍스트에서 또한 실행할 수 있다. 하지만 그 반대는 사실이 아니다. 파티션에서 실행중인 테넌트-특정 어플리케이션은 상기 글로벌 런타임의 상기 컨텍스트에서 실행할 수 없다. 아래 표는 어떤 컨텍스트 스위칭이 허용되는지 보여준다.

도 19는 실시예에 따르면, 멀티테넌트 어플리케이션 서버 환경에서 글로벌 런타임을 지원하는 방법의 흐름도를 도시한다.

도 19에 도시된 바와 같이, 단계 740에서, 어플리케이션 서버 환경이 하나 이상의 파티션들을 지원하는 소프트웨어 어플리케이션들의 실행을 위한 도메인을 포함하는 하나 이상의 컴퓨터들에서 제공되며, 각 파티션은 상기 도메인의 관리 및 런타임 서브디비전을 제공하고 파티션은 배포가능한 어플리케이션들 또는 리소스들의 컬렉션을 갖는 및/또는 리소스 그룹 템플릿을 참조하는 하나 이상의 리소스 그룹들을 선택적으로 포함할 수 있다.

단계 742에서, 임의의 특정 파티션에서 실행되지 않고, 대신 도메인으로 범위지정된 글로벌 런타임이 제공되며, 하나 이상의 리소스 그룹들은 상기 글로벌 런타임에서 사용하기 위해 상기 도메인 레벨에서 선택적으로 특정될 수 있다.

단계 744에서, 테넌트를 대신하여 상기 글로벌 런타임에 의해 기능을 실행하는 요청을 받으면, 상기 글로벌 런타임은 테넌트 스위칭 인터페이스를 통해 상기 테넌트의 상기 컨텍스트를 스위치할 수 있고, 테넌트로서 또는 테넌트를 대신하여 상기 기능을 실행할 수 있다.

본 발명은 본 발명의 상기 교시들에 따라 프로그램된 하나 이상의 프로세서들, 메모리 및/또는 컴퓨터 판독가능 저장 매체들을 포함하여 하나 이상의 종래의 범용 또는 특수용 디지털 컴퓨터, 컴퓨팅 디바이스, 머신 또는 마이크로프로세서를 사용하여 편리하게 구현될 수 있다. 적절한 소프트웨어 코딩이 소프트웨어 분야의 숙련자들에게 분명할 바와 같이 본 발명의 상기 교시들에 기초하여 숙련된 프로그래머들에 의해 쉽게 준비될 수 있다.

일부 실시예들에 따라, 본 발명은 컴퓨터 프로그램 제품을 포함하는바, 상기 컴퓨터 프로그램 제품은 명령어들이 저장된/본 발명의 상기 프로세스들 중 어느 것을 수행하도록 컴퓨터를 프로그래밍하기 위해 사용될 수 있는 저장 매체 또는 컴퓨터 판독가능 매체(매체들)이다. 저장 매체는 이들로만 한정되는 것은 아니지만, 플로피 디스크(disk)들, 광학 디스크(disc)들, DVD, CD-ROM들, 마이크로드라이브 및 자기-광학 디스크(disk)들을 포함하는 어떤 타입의 디스크, ROM들, RAM들, EPROM들, EEPROM들, DRAM들, VRAM들, 플래시 메모리 디바이스들, 자기 또는 광학 카드들, 나노시스템들(분자 메모리 IC들을 포함하는) 또는, 명령어들 및/또는 데이터를 저장하기에 적절한 어떤 타입의 매체 또는 디바이스를 포함할 수 있다.

본 발명의 상기 설명은 예시 및 설명을 목적으로 제공되었다. 본 설명은 완전한 것(exhaustive)으로 의도되거나 정확히 개시된 형태들로만 본 발명을 제한하고자 의도된 것이 아니다. 많은 수정들 및 변형들이 이 기술분야의 숙련자에게 분명할 것이다. 위 실시예들은 본 발명의 원리 및 이의 실용적 응용을 가장 잘 설명하기 위해 선택 및 기술되었으며, 그럼으로써 이 기술분야의 숙련자들은 본 발명에 대한 다양한 실시예들 및 고려되는 특별한 사용에 적합한 다양한 수정들을 이해할 수 있다. 본 발명의 범위는 다음의 특허 청구 범위 및 이의 균등물에 의해 한정되어야 함이 의도된다.

Claims (14)

1. 멀티테넌트 어플리케이션 서버 환경에서 단대단 라이프사이클(end-to-end lifecycle)을 지원하는 시스템으로서,
   소프트웨어 어플리케이션의 배포 및 실행을 가능하게 하는 어플리케이션 서버 환경을 포함하는 하나 이상의 컴퓨터들, -상기 어플리케이션 서버 환경은:
   소프트웨어 어플리케이션의 실행을 위한 어플리케이션 서버 도메인을 정의하는 도메인 구성;
   상기 어플리케이션 서버 환경 내에서 사용될 수 있는 복수의 리소스들; 그리고
   테넌트와 관련될 수 있는, 도메인의 복수의 파티션들을 포함하며, 각 파티션은 파티션 구성과 연관되고, 소프트웨어 어플리케이션의 실행을 위한 상기 도메인의 서브디비전을 제공함-; 그리고
   복수의 파티션들과 함께 사용하기 위해, 파티션-특정 구성들(partition-specific configuration)을 가질 수 있는 상기 어플리케이션 서버 환경의 복수의 컴포넌트들에 대한 구성 통합(configuration integration)을 제공하는 라이프사이클 관리자를 포함하는 라이프사이클 인프라스트럭처(lifecycle infrastructure)를 포함하며,
   복수의 컴포넌트들 중 각각의 특정 컴포넌트는 컴포넌트-특정 라이프사이클 및 인터페이스와 연관되며, 인터페이스는 라이프사이클 동작들이 특정 컴포넌트와 함께 수행될 수 있도록 하여 복수의 파티션들의 특정 파티션과 함께 사용하기 위해 특정 컴포넌트의 인스턴스를 구성하고, 그리고
   하나 이상의 컴포넌트들을 포함하도록 특정 파티션을 구성하는 동안, 라이프사이클 관리자는 컴포넌트-특정 라이프사이클에 의해 결정된 하나 이상의 컴포넌트들의 구성과 관련된 상기 라이프사이클 동작들을 수행하여 특정 파티션과 함께 사용하기 위해 하나 이상의 컴포넌트들을 구성하는 것을 특징으로 하는 멀티테넌트 어플리케이션 서버 환경에서 단대단 라이프사이클을 지원하는 시스템.
2. 청구항 1에 있어서,
   하나 이상의 리소스 그룹 템플릿들은 상기 도메인 내에서 배포가능한 리소스들의 그룹핑들을 정의하는데 사용되는 것을 특징으로 하는 멀티테넌트 어플리케이션 서버 환경에서 단대단 라이프사이클을 지원하는 시스템.
3. 청구항 1 내지 2 중 어느 한 항에 있어서,
   상기 라이프사이클 관리자를 포함하는 상기 라이프사이클 인프라스트럭처는,플러그인들의 상기 사용을 지원하며, 따라서 파티션들과 관련되도록 이용가능하게 될 컴포넌트가 컴포넌트 자체의 플러그인과 관련될 수 있게되는 것을 특징으로 하는 멀티테넌트 어플리케이션 서버 환경에서 단대단 라이프사이클을 지원하는 시스템.
4. 청구항 1에 있어서,
   상기 라이프사이클 관리자를 포함하는 상기 라이프사이클 인프라스트럭처는 테넌트 온보딩(tenant onboarding) 동안 서비스에 대한 테넌트를 파티션에 온보드(onboard)하도록 사용되는 것을 특징으로 하는 멀티테넌트 어플리케이션 서버 환경에서 단대단 라이프사이클을 지원하는 시스템.
5. 멀티테넌트 어플리케이션 서버 환경에서 단대단 라이프사이클을 지원하는 방법으로서,
   소프트웨어 어플리케이션의 배포 및 실행을 가능하게 하는 어플리케이션 서버 환경을 하나 이상의 컴퓨터들에서 제공하는 단계 -상기 어플리케이션 서버 환경은:
   소프트웨어 어플리케이션의 실행을 위한 어플리케이션 서버 도메인을 정의하는 도메인 구성;
   상기 어플리케이션 서버 환경 내에서 사용될 수 있는 복수의 리소스들; 그리고
   테넌트와 관련될 수 있는, 도메인의 복수의 파티션들을 포함하며, 각 파티션은 파티션 구성과 연관되고, 소프트웨어 어플리케이션의 실행을 위한 상기 도메인의 서브디비전을 제공함-; 그리고
   복수의 파티션들과 함께 사용하기 위해, 파티션-특정 구성들(partition-specific configuration)을 가질 수 있는 상기 어플리케이션 서버 환경의 복수의 컴포넌트들에 대한 구성 통합(configuration integration)을 제공하는 라이프사이클 관리자를 포함하는 라이프사이클 인프라스트럭처(lifecycle infrastructure)를 제공하는 단계를 포함하며,
   복수의 컴포넌트들 중 각각의 특정 컴포넌트는 컴포넌트-특정 라이프사이클 및 인터페이스와 연관되며, 인터페이스는 라이프사이클 동작들이 특정 컴포넌트와 함께 수행될 수 있도록 하여 복수의 파티션들의 특정 파티션과 함께 사용하기 위해 특정 컴포넌트의 인스턴스를 구성하고, 그리고
   하나 이상의 컴포넌트들을 포함하도록 특정 파티션을 구성하는 동안, 라이프사이클 관리자는 컴포넌트-특정 라이프사이클에 의해 결정된 하나 이상의 컴포넌트들의 구성과 관련된 상기 라이프사이클 동작들을 수행하여 특정 파티션과 함께 사용하기 위해 하나 이상의 컴포넌트들을 구성하는 것을 특징으로 하는 멀티테넌트 어플리케이션 서버 환경에서 단대단 라이프사이클을 지원하는 방법.
6. 청구항 5에 있어서,
   하나 이상의 리소스 그룹 템플릿들은 상기 도메인 내에서 배포가능한 리소스들의 그룹핑들을 정의하는데 사용되는 것을 특징으로 하는 멀티테넌트 어플리케이션 서버 환경에서 단대단 라이프사이클을 지원하는 방법.
7. 청구항 5 내지 6 중 어느 한 항에 있어서,
   상기 라이프사이클 관리자를 포함하는 상기 라이프사이클 인프라스트럭처는,플러그인들의 상기 사용을 지원하며, 따라서 파티션들과 관련되도록 이용가능하게 될 컴포넌트가 컴포넌트 자체의 플러그인과 관련될 수 있게되는 것을 특징으로 하는 멀티테넌트 어플리케이션 서버 환경에서 단대단 라이프사이클을 지원하는 방법.
8. 청구항 5에 있어서,
   상기 라이프사이클 관리자를 포함하는 상기 라이프사이클 인프라스트럭처는 테넌트 온보딩(tenant onboarding) 동안 서비스에 대한 테넌트를 파티션에 온보드(onboard)하도록 사용되는 것을 특징으로 하는 멀티테넌트 어플리케이션 서버 환경에서 단대단 라이프사이클을 지원하는 방법.
9. 저장된 명령어들을 포함하는 비-일시적 컴퓨터 판독가능 저장 매체로서, 상기 명령어들은 하나 이상의 컴퓨터들에 의해 판독되고 실행될 때 상기 하나 이상의 컴퓨터들로 하여금 방법을 수행하게 하며, 상기 방법은:
   소프트웨어 어플리케이션의 배포 및 실행을 가능하게 하는 어플리케이션 서버 환경을 제공하는 단계 -상기 어플리케이션 서버 환경은:
   소프트웨어 어플리케이션의 실행을 위한 어플리케이션 서버 도메인을 정의하는 도메인 구성;
   상기 어플리케이션 서버 환경 내에서 사용될 수 있는 복수의 리소스들; 그리고
   테넌트와 관련될 수 있는, 도메인의 복수의 파티션들을 포함하며, 각 파티션은 파티션 구성과 연관되고, 소프트웨어 어플리케이션의 실행을 위한 상기 도메인의 서브디비전을 제공함-; 그리고
   복수의 파티션들과 함께 사용하기 위해, 파티션-특정 구성들(partition-specific configuration)을 가질 수 있는 상기 어플리케이션 서버 환경의 복수의 컴포넌트들에 대한 구성 통합(configuration integration)을 제공하는 라이프사이클 관리자를 포함하는 라이프사이클 인프라스트럭처(lifecycle infrastructure)를 제공하는 단계를 포함하며,
   복수의 컴포넌트들 중 각각의 특정 컴포넌트는 컴포넌트-특정 라이프사이클 및 인터페이스와 연관되며, 인터페이스는 라이프사이클 동작들이 특정 컴포넌트와 함께 수행될 수 있도록 하여 복수의 파티션들의 특정 파티션과 함께 사용하기 위해 특정 컴포넌트의 인스턴스를 구성하고, 그리고
   하나 이상의 컴포넌트들을 포함하도록 특정 파티션을 구성하는 동안, 라이프사이클 관리자는 컴포넌트-특정 라이프사이클에 의해 결정된 하나 이상의 컴포넌트들의 구성과 관련된 상기 라이프사이클 동작들을 수행하여 특정 파티션과 함께 사용하기 위해 하나 이상의 컴포넌트들을 구성하는 것을 특징으로 하는 비-일시적 컴퓨터 판독가능 저장 매체.
10. 청구항 9에 있어서,
    하나 이상의 리소스 그룹 템플릿들은 상기 도메인 내에서 배포가능한 리소스들의 그룹핑들을 정의하는데 사용되는 것을 특징으로 하는 비-일시적 컴퓨터 판독가능 저장 매체.
11. 청구항 9 내지 10 중 어느 한 항에 있어서,
    상기 라이프사이클 관리자를 포함하는 상기 라이프사이클 인프라스트럭처는,플러그인들의 상기 사용을 지원하며, 따라서 파티션들과 관련되도록 이용가능하게 될 컴포넌트가 컴포넌트 자체의 플러그인과 관련될 수 있게되는 것을 특징으로 하는 비-일시적 컴퓨터 판독가능 저장 매체.
12. 청구항 9에 있어서,
    상기 라이프사이클 관리자를 포함하는 상기 라이프사이클 인프라스트럭처는 테넌트 온보딩(tenant onboarding) 동안 서비스에 대한 테넌트를 파티션에 온보드(onboard)하도록 사용되는 것을 특징으로 하는 비-일시적 컴퓨터 판독가능 저장 매체.
13. 삭제
14. 삭제

Images