KR20170059454A

KR20170059454A - 멀티테넌트 어플리케이션 서버 환경에서 글로벌 런타임의 이용을 위한 시스템 및 방법

Info

Publication number: KR20170059454A
Application number: KR1020177009948A
Authority: KR
Inventors: 라지브 모르다니; 나즈룰 이슬람
Original assignee: 오라클 인터내셔날 코포레이션
Priority date: 2014-09-25
Filing date: 2015-09-25
Publication date: 2017-05-30
Also published as: CN107077389A; US10873624B2; US20190273778A1; JP2017528846A; US10382537B2; US20160094647A1; WO2016049576A1; CN107077389B; KR102436295B1; EP3198435A1; JP6611798B2

Abstract

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

Description

멀티테넌트 어플리케이션 서버 환경에서 글로벌 런타임의 이용을 위한 시스템 및 방법{SYSTEM AND METHOD FOR USE OF A GLOBAL RUNTIME IN A MULTITENANT APPLICATION SERVER ENVIRONMENT}

저작권 공지

우선권 주장 및 관련 출원의 상호 참조

본 출원은 2014년 9월 25일자로 출원된 발명의 명칭이 "SYSTEM AND METHOD FOR PROVIDING END-TO-END LIFECYCLE IN A MULTITENANT APPLICATION SERVER ENVIRONMENT"인 미국 가출원 제62/055,575호, 2014년 9월 25일자로 출원된 발명의 명칭이 "SYSTEM AND METHOD FOR TENANT ONBOARDING IN A MULTITENANT APPLICATION SERVER ENVIRONMENT"인 미국 가출원 제62/055,577호, 2014년 9월 26일자로 출원된 발명의 명칭이 "SYSTEM AND METHOD FOR DATABASE AND APPLICATION SERVER LIFECYCLE PLUGINS IN A MULTITENANT APPLICATION SERVER ENVIRONMENT"인 미국 가출원 제62/055,856호, 2014년 9월 26일자로 출원된 발명의 명칭이 "SYSTEM AND METHOD FOR GLOBAL RUNTIME IN A MULTITENANT APPLICATION SERVER ENVIRONMENT"인 미국 가출원 제62/056,427호의 우선권의 이득을 주장하고, 2015년 1월 21일자로 출원된 발명의 명칭이 "SYSTEM AND METHOD FOR SUPPORTING MULTI-TENANCY IN AN APPLICATION SERVER, CLOUD, OR OTHER ENVIRONMENT"인 미국 특허 출원 제14/601,883호에 관계되며, 상기 출원들 각각은 본 명세서에 참조로서 포함된다.

기술분야

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

어플리케이션 서버들은 일반적으로, 피관리 컴퓨팅 환경(managed computing environment)을 제공하고 이 환경에서 소프트웨어 어플리케이션들이 전개(deploy)되고 실행될 수 있다. 클라우드 기반 컴퓨팅 환경들은 어플리케이션들이 클라우드에 의해 제공되는 분산된 리소스들 내에서 실행되게 하고 이러한 분산된 리소스들의 장점을 취할 수 있게 한다. 이러한 환경들은 다수의 사용자들 또는 테넌트들을 지원할 수 있으며, 그 중 일부는 해당 사용자 또는 테넌트에게 특정적인 특정한 요건들을 가질 수 있다. 추가 테넌트들이 시스템에 추가되면, 시스템은 필요에 따라 다른 시스템 컴포넌트들을 테넌트와 관련시키는 것을 포함하여 각 테넌트의 필요들을 해결할 수 있어야 한다. 이들은 본 발명의 실시예들이 사용될 수 있는 환경들의 타입의 일부 예이다.

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

실시예에 따라, 멀티테넌트 어플리케이션 서버 환경에서 단-대-단 라이프사이클을 제공하는 시스템 및 방법이 기술된다. 라이프사이클 관리자는 서로 다른 컴포넌트들 예컨대, 자신만의 파티션별(partition-specific) 구성들을 가질 수 있는 어플리케이션 서버들, 트래픽 디렉터 또는 로드 밸런서, 및 데이터베이스 또는 다른 컴포넌트들에 걸친 구성 통합을 가능하게 한다.

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

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

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

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

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

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

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

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

일반적으로, 시스템 어드미니스트레이터는 파티션들, 도메인-레벨 리소스 그룹들 및 리소스 그룹 템플릿들 및 보안 영역들(security realms)을 정의할 수 있고, 파티션 어드미니스트레이터는 예컨대, 파티션-레벨 리소스 그룹들을 생성, 파티션에 어플리케이션들을 전개(deploy) 또는 파티션에 대한 특정 영역을 참조함으로써, 자신만의 파티션의 양상들을 정의할 수 있다.

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

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

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

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

마찬가지로, 일 실시예에 따르면, 특정한 파티션과 관련된 가상 타겟 정보는 파티션에 의해 이용하기 위한 파티션별 가상 타겟(240)(예컨대, baylandurgentcare.com)을 정의(239)하기 위해 이용될 수 있는 바, 이는 그 다음, URL(uniform resource locator), 예컨대, http://baylandurgentcare.com을 통해 액세스가능하게될 수 있다.

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

일 실시예에 따르면, config.xml 구성 파일과 같은 시스템 구성이 파티션을 정의하기 위해 이용되는 바, 이 시스템 구성은 그 파티션 및/또는 다른 파티션 속성들과 관련된 리소스 그룹들에 대한 컴포넌트들을 포함한다. 속성 이름/값 쌍들을 이용하여 파티션 당 값들이 특정될 수 있다.

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

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

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

리소스들

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

파티션들

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

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

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

일 실시예에 따르면, 예컨대 config.xml 구성 파일에 의해 정의된 파티션 구성은 복수의 컴포넌트들, 예컨대, 파티션을 정의하는 특질(attribute)들 및 차일드 요소들을 포함하는 "partition", 상기 파티션에 대해 전개되는 어플리케이션들 및 리소스들을 포함하는 "resource-group", 해당 템플릿에 의해 정의되는 어플리케이션들 및 리소스들을 포함하는 "resource-group-template", 데이터베이스별 서비스 이름, 사용자 이름 및 패스워드를 포함하는 "jdbc-system-resource-override" 및 리소스 그룹 템플릿들 내의 매크로 교체(macro replacement)를 위해 이용될 수 있는 속성 키 값들을 포함하는 "partition-properties"을 포함할 수 있다.

시동 시, 시스템은 리소스 그룹 템플릿으로부터 각각의 리소스에 대한 파티션별 컴포넌트들을 생성하기 위해 구성 파일에 의해 제공되는 정보를 이용할 수 있다.

리소스 그룹들

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

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

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

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

리소스 그룹 템플릿들

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

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

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

테넌트들

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

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

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

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

일 실시예에 따르면, 시스템은 사용자들이 테넌트-인지형이도록 명시적으로 작성되는 어플리케이션들을 전개할 수 있게 하여서, 어플리케이션 개발자들은 현재의 테넌트의 테넌트 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)을 정의할 수 있고, 상기 템플릿에 그러한 전개가능한 리소스들을 선언할 수 있다.

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

예를 들어, 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)(이 예에서는 bayland urgent care 데이터베이스 또는 valley health 데이터베이스를 각각 포함)에 연결하기 위한 서로 다른 URL(322, 332)를 정의할 수 있다. 상기 데이터베이스 인스턴스들은 호환가능한 스키마를 이용할 수 있는 바, 그 이유는 동일한 어플리케이션 코드가 두 데이터베이스들에 대해 실행될 것이기 때문이다. 시스템이 파티션들을 시작할 때, 이는 가상 타겟들, 및 각각의 데이터베이스 인스턴스들에게로의 연결 풀들을 생성할 수 있다.

* * * * * * * * * *

단-대-단 라이프사이클(End-to-End Lifecycle)

일 실시예에 따르면, 멀티-테넌트 어플리케이션 서버 환경에서 단-대-단 라이프사이클을 제공하는 시스템 및 방법이 본 명세서에 기술된다. 라이프사이클 관리자는 서로 다른 컴포넌트들 예컨대, 자신만의 파티션별(partition-specific) 구성들을 가질 수 있는 어플리케이션 서버들, 트래픽 디렉터 또는 로드 밸런서, 및 데이터베이스 또는 다른 컴포넌트들에 걸친 구성 통합을 가능하게 한다.

다양한 실시예들에 따르면, 본 명세서에 제공되는 단-대-단 라이프사이클 프로세스의 설명들 중 일부는 다음의 용어들을 이용한다.

테넌시: 테넌트가 자신의 필요들에 알맞은 특정한 정도로 시스템의 거동을 커스토마이징할 수 있게 하기 위해, 전형적으로 테넌트에 의해 제한된 시간 주기 동안 시스템의 컴포넌트를 이용하기 위한 권리(right).

테넌시 컨텍스트: 컨텍스트적 정보, 예컨대 보안, 명명(naming), 또는 클래스 로딩 정보. 이는 시스템의 테넌시를 결정하기 위해 이용되어서, 상기 시스템이 빌(bill)들을 생성하는 것과 같은 테넌트별 거동을 제공하기 위해 해당 테넌트 컨텍스트를 이용할 수 있게 한다.

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

리소스 테턴시: 주로 Oracle Fusion Middleware(FMW)/Fusion Application(FA) 실시예들을 설명할 때 사용되는 "테넌시"와 유사한 속성

MT 어드민 코드(MT admin code): 어떤 테넌트가 멀티테넌트 시스템을 위해 온보딩되기 전에 전개되고 활성화되며, 시스템의 라이프사이클 관리뿐만 아니라 테넌트 런타임을 담당하는 코드.

MT 어드민 런타임: MT 어드민 코드의 런타임 표시.

테넌트 코드: 테넌트에 대해 구체적으로 전개되는 코드.

테넌트 런타임: 테넌트 코드의 런타임 표시.

계층화된 제품 : 멀티테넌트 어플리케이션 서버 환경과 상호운용되거나 또는 그렇지 않으면 이를 활용할 수 있는 소프트웨어 제품. 이의 예들은 FMW 및 FA 제품군들을 포함 할 수 있다.

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

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

예를 들어, 어플리케이션 서버(예컨대, WebLogic, WLS) 컴포넌트가 멀티테넌트-인지(multitenant-aware)를 할 수 있게 하고 어플리케이션 서버 내의 파티션들의 사용을 지원할 수 있게 하는 것에 추가적으로, 상기 시스템은 다른 컴포넌트들 및 제품들이 어플리케이션 서버 파티션들과 상호운용될 수 있게 해야만 하는 바, 예컨대 데이터베이스(예컨대, 오라클 데이터베이스, DB) 및 트래픽 디렉터 또는 로드 밸런서(예컨대, 오라클 트래픽 디렉터, OTD) 인스턴스들이 적절하게 구성될 수 있고, 그 후에 이 파티션들을 마찬가지로 지원할 수 있게 해야만 한다.

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

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

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

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

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

마찬가지로, 일 실시예에 따르면, 라이프사이클 관리자는 파티션에서 사용하기 위한 URI 또는 호스트 이름을 셋업하는 것을 포함하여 파티션에 대한 OTD 라우팅을 셋업하는 데 사용될 수 있어서, 클러스터에서 실행중인 WLS 파티션이 OTD 인스턴스와 함께 프론트-엔드되게하고, 라이프사이클 관리자는 테넌트 환경에서 이용하기 위한, 파티션에 대한 OTD 인스턴스 및 WLS 파티션으로의 연결이 생성될 수 있게 한다.

단-대-단 라이프사이클 관리에 의해 제공되는 추가적인 장점들은 대역외(out-of-band) 변경들을 감지하기 위한 능력을 포함한다.

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

일 실시예에 따르면, 라이프사이클의 오케스트레이션은 런타임의 다양한 컴포넌트들 또는 슬라이스를 생성하기 위해 다양한 방식으로 수행될 수 있다. 예를 들어, 시스템은 라이프사이클 관리자에게 REST 콜로서 파티션, PDB 및 OTD 인스턴스를 개별적으로 생성할 수 있는 바, 이는 라이프사이클 관리자가 예컨대, WLS 파티션을 생성하고, OTD 인스턴스 또는 컴포넌트들의 다른 슬라이스를 생성하도록 지시한다. 오케스트레이션 동안 장애(failure)가 발생하면, 시스템은 예를 들어, 관련(association) 및 아티팩트의 오케스트레이션을 위해 REST 엔드포인트 재시도함으로써 이를 수용할 수 있다.

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

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

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

예를 들어, 콜이 파티션에 대한 PDB 생성에 관한 것인 경우, 라이프사이클 관리자는 데이터베이스 라이프사이클 플러그인을 콜함으로써 응답할 수 있거나 또는 콜출이 파티션에 대한 OTD 인스턴스 생성에 관한 것인 경우, 라이프사이클 관리자는 OTD 라이프사이클 플러그인을 콜함으로써 응답할 수 있으며, 라이프사이클 관리자는 이러한 방식으로 계속 응답할 수 있다.

단일 도메인 다중 파티션 환경에서, 라이프사이클 관리자 기능을 제공한 어드민 서버에 장애가 발생하면(fail), 시스템은 자신의 어드미니스트레이티브 및 관리 기능이 일정 시간 주기 동안 디스에이블될 수 있지만, 전통적인 어플리케이션 서버(예컨대, WLS) 서버 환경처럼 역할을 하는 것을 계속할 수 있다.

일 실시예에 따르면, 시스템은 계약들(contracts) 및 이러한 계약들의 서비스들로서의 구현들을 검색(look up)하기 위해 종속성 주입 메카니즘으로서 HK2를 사용할 수 있다. 예를 들어, HK2를 사용하여, 서비스들은 컴포넌트들에 주입가능할 수 있고, 일단 주입되면, 이들의 HK2 객체들은 다른 클래스들의 종속성들을 충족시킬 수 있다. 라이프사이클 플러그인들은 HK2 서비스들로서 구현될 수 있으며, 런타임 시 자신의 계약을 구현할 수 있다. 시스템은 서비스들로서 플러그인된 적절한 플러그인들을 발견하기 위해 계약을 검색할 수 있다.

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

일 실시예에 따르면, 시스템은 콜 동안 요구되는 서비스의 타입(예를 들어, "타입 = 데이터베이스")에 관한 표시를 수신할 수 있고 그 다음, 이용될 적절한(이 경우에서는) 데이터베이스 플러그인을 결정할 수 있다.

마찬가지로, 일 실시예에 따르면, 어플리케이션 서버(예를 들어, WLS) 및 트래픽 디렉터(예를 들어, OTD) 컴포넌트들에 대해, 서비스들로서 구현될 수 있는 컴포넌트들에 대한 플러그인이 제공되고, 후속적으로는 파티션의 생성 또는 구성 동안 이용될 수 있다.

HK2와 같은 메커니즘들은 예컨대, 디폴트 저장소 또는 지속성 타입과 같은 XML에 저장된 구성 모델을 정의하는 데 사용할 수 있는 구성 관리에 대한 지원을 제공한다.

일 실시예에 따르면, 구성 객체들은 파티션과 함께 사용하기 위한 특정한 컴포넌트에 대한 특질들을 정의하는데 사용될 수 있다. 이러한 객체들은 마찬가지로 주입가능한 바, 이는 예컨대, 구성 개체를 주입하고 해당 파티션에 대한 정보를 검색함으로써 소정 파티션의 구성 정보를 검색할 수 있게 한다.

환경

일 실시예에 따르면, 서로 다른 컴포넌트들에 걸친 파티션들의 세트는 테넌트의 필요들을 서빙하는 응집 유닛(cohesive unit)을 형성하기 위해, 환경으로서 서로 링크될 수 있다. 환경은 각각의 타입의 하나보다 많은 파티션을 가질 수 있지만, 전형적으로 이들은 각각의 타입의 파티션 중 하나만을 가질 것이다. 예를 들어, FA 시나리오에서, 다중도메인 토폴로지의 도메인들 각각으로부터 하나보다 많은 WLS 파티션이 존재할 수 있는 바, 이러한 시나리오에서, 지원되어야 하는 WLS와 OTD와 데이터베이스 간의 복수의 관련들이 존재할 수 있다.

컴포넌트/ 런타임

일 실시예에 따르면, 컴포넌트 또는 런타임은 예컨대, OTD, WLS, 코힐런스(Coherence) 또는 데이터베이스 컴포넌트와 같은 소프트웨어 컴포넌트이다. 다른 실시예에 따르면, 추가적인 타입들의 소프트웨어 컴포넌트들이 또한 지원될 수 있다.

라이프사이클 관리자

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

라이프사이클 플러그인

일 실시예에 따르면, 라이프사이클 플러그인은 라이프사이클 관리자와 컴포넌트, 예를 들어, OTD, WLS, 코힐런스 또는 데이터베이스 컴포넌트 사이의 브리지를 제공하는 소프트웨어 모듈이다. 라이프사이클 플러그인들은 런타임 플러그인 및 파티션 플러그인(지원되는 경우) 인터페이스를 HK2 서비스들로서 구현하는 클래스들을 포함 할 수 있는 바, 이 서비스들은 라이프사이클 플러그인이 구성 변경 트랜잭션 및 통지 이벤트들에 참여할 수 있게 하고 컴포넌트에서 그러한 활동을 반영하기 위해 어떤 적절한 조치를 취하게 할 수 있다. 플러그인 API는 일반적으로, 런타임 또는 파티션에 대한 실제 라이프사이클 동작들을 수행하는 데 사용되는 기본 프로토콜에 대해 애그노스틱(agnostic)하다. 플러그인의 구현은 필수적인 동작들을 수행하기 위해 어떻게 런타임에 연결할지를 선정할 수 있다. 예를 들어, 일 실시예에 따르면, 중지(quiesce), 스케일업(scaleUp) 또는 스케일다운(scaleDown)과 같은 동작이 런타임 관리자를 통해 런타임 시 개시될 때, 런타임 타입에 대응하는 런타임 플러그인의 구현이 HK2를 통해 검색될 수 있고, 런타임 플러그인(예컨대, RuntimePlugin) 구현의 대응하는 메소드가 런타임 플러그인이 적절한 조치를 취할 수 있도록 인보크될 수 있다.

클라이언트

일 실시예에 따르면, 클라이언트는 예를 들어 REST API를 통해 또는 자바 API를 통해 임베디드 된 경우에 라이프사이클 관리자와 인터랙션하는 라이프사이클 관리자의 어떤 클라이언트를 지칭한다. 클라이언트들의 예들은 오라클 FMWC(Oracle Fusion Middleware Control) 및 EMCC(Enterprise Manager Cloud Control) 및 컬 기반의 스크립트들(curl-based scripts)을 포함한다. 일 실시예에 따르면, 라이프사이클 관리자 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 파일에 저장될 수 있으며 런타임시 테넌시를 확립하기 위해 피관리 서버들 상에서 이용가능해진다. 라이프사이클 관리자는 일부 어플리케이션 서버 환경들에서 즉시(out-of-the-box) 인에이블될 수 있는 바, 상기 라이프사이클 관리자는 어드민 서버 상에서 실행될 것이며 추가적인 셋업을 요하지 않을 것이다.

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

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

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

이 시나리오에서, 라이프사이클 관리자는 라이프사이클 관리자 클러스터의 피관리 서버들 상에서 실행될 수 있으며, 단-대-단 라이프사이클 구성은 데이터베이스에 유지(persist)될 수 있어서, 정보에 액세스할 필요를 가지는 어떤 도메인 또는 런타임들이 그 정보를 획득하기 위해 데이터베이스에 액세스할 수 있다.

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

라이프사이클 런타임

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

런타임에서 어떤 동작들을 수행하기 위해, 런타임의 인스턴스는 검색되어야 한다. 일 실시예에 따르면, 라이프사이클 런타임의 인스턴스는 후술되는 바와 같이 소정 런타임 타입에 대한 런타임 관리자를 사용하여 검색될 수 있다. 파티션(런타임의 슬라이스)의 사용을 지원하는 피관리 서비스들을 나타내는 라이프사이클 런타임은 라이프사이클 런타임에서 그 파티션에 대한 CRUD 동작들을 할 수 있게 한다.

일 실시예에 따르면, 라이프사이클 런타임을 검색한 후 파티션을 생성하기 위해, 라이프사이클 런타임의 생성 파티션(예를 들어, createPartition) 메소드는 선택된 런타임에서 파티션을 생성하는 데 사용될 수 있다. 파티션이 생성되는 방식은, 라이프사이클 런타임에 대한 파티션 플러그인이 런타임 타입에 대한 HK2 서비스로서 검색되고 파티션 플러그인 상의 대응하는 create 메소드가 인보크되는 것이다.

런타임 관리자

일 실시예에 따르면, 런타임 관리자(예를 들어, RuntimeManager)는 런타임을 관리하는 데 사용되는 단독(singleton) HK2 서비스로서 제공될 수 있다. 그 JVM의 모든 런타임들의 라이프사이클을 관리할 JVM(Java Virtual Machine) 당 런타임 관리자가 제공될 수 있다. 런타임 관리자를 사용하여, 런타임이 생성하거나 등록될 수 있다. 또한, 런타임 관리자는 런타임을 생성, 삭제, 업데이트, 스케일업, 스케일다운 및 중지하기 위한 동작들을 제공한다. 런타임 관리자는 런타임 플러그인을 해당 런타임 타입에 대한 HK2 서비스로서 검색하고 플러그인에서 해당 동작을 인보크할 것이다.

일 실시예에 따르면, 일단 런타임 관리자가 소정 런타임 타입에 대해 검색되면, 그 런타임 관리자에서 스케일업 및 스케일다운 동작들이 특정된 런타임에 대해 콜될 수 있다. 런타임 관리자는 서비스에 대한 대응하는 런타임 플러그인을 검색하고 스케일업 또는 스케일다운 동작을 인보크한다. 이 런타임 지원은 특히, 탄성 사용 경우들을 처리함에 있어 유용하다.

일 실시예에 따르면, 런타임 관리자는 런타임들과 함께 사용하기 위해 다음의 동작들을 제공한다

동작	설명
createRuntime	런타임은 컴포넌트에 대한 런타임 플러그인이 런타임을 생성하는 것을 지원하는 경우 생성될 수 있다.
deleteRuntime	런타임은 컴포넌트에 대한 런타임 플러그인이 런타임을 삭제하는 것을 지원하는 경우 삭제될 수 있다.
updateRuntime	런타임은 컴포넌트에 대한 런타임 플러그인이 런타임을 업데이트하는 것을 지원하는 경우 업데이트될 수 있다.
registerRuntime	미리 생성된 런타임을 LCM에 등록. 최소한, 런타임은 런타임 상에서 후속적인 동작들을 수행하기 위해 LCM에 등록되어야 한다.
unregisterRuntime	런타임을 등록해제. 런타임은 오직 LCM이 런타임을 참조하는 어떤 아티팩트들을 관리하지 않을 때 등록해제될 수 있다. 런타임들 상의 모든 파티션들은 런타임이 등록해제되기 전에 삭제되어야 한다. LCM 아티팩트들로부터 런타임에 대한 참조들이 존재할 때 런타임을 등록해제하기 위한 시도가 이루어는 경우, IllegalStateException가 발생되어야(thrown) 한다.
quiesceRuntime	런타임이 중지(quiescing)를 지원하는 경우, 런타임 관리자 상에서 quiesceRuntime 메소드는 런타임 플러그인 상에서 런타임을 중지하기 위해 대응하는 메소드를 인보크할 것이다. 런타임이 중지를 위해 하나보다 많은 페이즈, 예컨대 start_quiesce 및 end_quiesce를 지원하는 경우, quiesce 메소드는 페이즈에 따라 한번보다 많이 콜될 수 있다. 런타임이 중지를 위한 페이즈들을 가지지 않는 경우, 페이즈에 대한 null 값이 패스되어야 한다. 런타임이 중지를 지원하지 않으면, UnsupportedOperationException이 발생되어야 한다.
scaleUp	런타임이 스케일링 동작들을 지원하는 경우, 런타임 관리자 상의 스케일업 메소드는 런타임을 스케일업하는 동작을 수행하기 위해 대응하는 런타임 플러그인을 인보크함으로써 런타임을 스케일링할 것이다. 런타임이 스케일업을 지원하지 않는 경우, UnsupportedOperationException이 발생되어야 한다.
scaleDown	런타임이 스케일링 동작들을 지원하는 경우, 런타임 관리자 상의 scaleDown 메소드는 런타임을 스케일 다운하는 동작을 수행하기 위해 대응하는 런타임 플러그인을 인보크함으로써 런타임을 스케일 다운시킬 것이다. 런타임이 스케일다운을 지원하지 않는 경우, UnsupportedOperationException이 발생되어야 한다.
getRuntime(runtimeName)	특정된 이름을 갖는 런타임 객체를 린턴. 특정된 이름을 갖는 런타임이 존재하지 않는 경우, null이 리턴될 것이다.
getRuntimes(runtimeType)	특정된 런타임 타입에 대한 런타임들의 리스트를 리턴. 런타임 타입에 대해 등록 또는 생성된 런타임들이 존재하지 않는 경우, null이 리턴될 것이다.
getRuntimes()	LCM이 관리하는 모든 런타임들의 리스트를 리턴. 런타임들이 LCM을 이용하여 등록 또는 생성되지 않은 경우, null이 리턴될 것이다.

일 실시예에 따르면, 다음의 의사 코드(pseudo code)는 미리 생성된 WLS 런타임 및 데이터베이스 런타임이 라이프사이클 관리자에 어떻게 등록되고 그 다음, 후속적으로는 런타임 상에서 파티션들을 생성하기 위해 라이프사이클 관리자에 의해 어떻게 이용되는지를 예시한다.

@Inject

private RuntimeManager rtmMgr;

// Database is the type of the Runtime and DB1 is the actual instance rtmMgr.registerRuntime("Database", "DB1", dbProps);

// WebLogic is the type of Runtime and WLSMTRuntime1 is the actual instance rtmMgr.registerRuntime("WebLogic", "WLSMTRuntime1", wlsProps);

// You can lookup a specific Runtime or have RuntimeManager select

// one based on the type of the Runtime and some internal heuristics to determine

// which one to pick.

LifecycleRuntime wlsRuntime = rtmMgr.getRuntime("WLSRuntime1");

// Create a WLS Partition and a Slice/Partition of a Database LifecyclePartition wlsPartition =

wlsRuntime.createPartition("cokeCRMWLSProdPartition", wlsPartitionProps);

// Get the Database runtime

Runtime dbRuntime = rtmMgr.getRuntime("DB1");

// Create a Database Partition (PDB in 12c Database case)

LifecyclePartition pdb = dbRuntime.createPartition("cokeCRMPDBProd", pdbProps);

런타임들의 중지( Quiescing of Runtimes)

일 실시예에 따르면, 런타임들의 중지/정상적인 셧다운에 대한 지원을 포함할 수 있는 WLS와 같은 컴포넌트들은 런타임 플러그인에서 중지 지원을 구현함으로써 라이프사이클 관리자를 통한 중지 기능들을 지원할 수 있다. 런타임을 중지하는 것은 서로 다른 페이즈들을 가질 수 있다. 이러한 시나리오에서, 런타임 플러그인의 quiesce 메소드는 한번보다 많이 인보크되어, quiesce 메소드의 페이즈 파라미터를 통해 중지 페이즈를 나타낸다.

예를 들어, 서버가 중지 페이즈를 시작하고 있음 - 따라서, 이 중지 페이즈는 중지되고 있는 서버에 새로운 요청들이 포워딩되지 않아야 함을 통지함 - 을 나타내는 "start_quiesce" 페이즈가 존재할 수 있다. quiescing이 완료된 후, 후속적인 콜은 서버가 이제 새 요청들을 다시 받아들이기 시작할 준비가 됨을 나타내는 페이즈인 "end_quiesce" 페이즈를 가질 것이다. 컴포넌트가 추가적인 페이즈를 지원하는 경우, 이 페이즈들은 완전한 기능을 보장하기 위해 런타임 플러그인에 의해 지원될 수 있다.

"start_quiesce", "end_quiesce"는 컴포넌트가 지원할 수 있는 페이즈들의 예들이며 모든 컴포넌트가 지원해야 하는 규범적인 페이즈들의 리스트는 아니다. 컴퍼넌트가 중지를 지원하지 않는 경우, UnsupportedOperationException가 발생되어야 한다. 컴포넌트가 페이즈들을 지원하지 않는 경우, null 값은 quiesce 메소드로 패스될 수 있는 유효한 값이다.

런타임 스케일링

멀티테넌트 환경의 장점들 중 하나는 복수의 어플리케이션들 및 사용자 그룹들에 걸쳐 하드웨어, 리소스 및 서비스를 공유하여, 규모의 경제(economies of scale)를 달성하고, 이러한 사용자들의 필요들이 시간에 걸쳐 다양하기 때문에 관리자가 능력(capacity)을 할당함에 있어서 유연성을 가질 수 있도록 하는 것이다.

실시예에 따르면, 라이프사이클 관리자 API는 다른 탄성 프레임 워크들이 런타임을 스케일 업 및 스케일 다운할 수 있는 능력을 제공한다. 런타임 관리자 및 런타임 플러그인은 사용자가 런타임을 스케일링하기 위해 콜할 scaleUp 및 scaleDown 메소드를 제공한다.

일 실시예에 따라, scaleUp 또는 scaleDown이 런타임 관리자에서 콜될 때, 런타임 타입에 대응하는 런타임 플러그인이 검색되고 런타임 플러그인의 인스턴스 상에서 스케일링 동작이 인보크된다. 컴포넌트가 스케일링 동작을 지원하지 않는 경우, 런타임 플러그인의 구현은 UnsupportedOperationException을 발생시켜야 한다.

런타임 플러그인 구현(Runtime Plugin Implementation)

일 실시예에 따른, 런타임 플러그인을 위한 의사 코드가 아래에 예시된다(가독성을 위해, 이 예는 모든 추상적 메소드들을 구현하지 않는다).

package com.oracle.weblogic.lifecycle.plugin.wls;

import com.oracle.weblogic.lifecycle.core.LifecyclePartitionImpl;

import org.jvnet.hk2.annotations.Service;

import com.oracle.weblogic.lifecycle.*;

@Service(name = "Weblogic")

public class WLSRuntimePlugin extends RuntimePlugin {

public void create(String runtimeName, LifecycleContext ctx) throws LifecycleException

// If a component wants to support creation of Runtimes via LCM,

// then the implementation of create for a Runtime will need to be provided

}

public void delete(String runtimeName, LifecycleContext ctx) throws LifecycleException

// If a component wants to support deleting of Runtimes via LCM,

// then the implementation of delete for a Runtime will need to be provided

}

public void update (String runtimeName, LifecycleContext ctx) throws LifecycleException

// If a component wants to support updating of Runtimes via LCM,

// then the implementation of update for a Runtime will need to be provided

}

public void scaleUp(String runtimeName, int scaleFactor, LifecycleContext ctx) throws LifecycleException

// If a component wants to support scaleUp of Runtimes via LCM,

// then the implementation of scaleUp for a Runtime will need to be provided

}

...

파티션 플러그인

일 실시예에 따르면, 파티션을 지원하는 런타임들(예를 들어, WLS, 12c 데이터베이스 등과 같은 런타임의 슬라이스)은 파티션 플러그인의 구현을 제공해야한다. 런타임에서 createPartition과 같은 동작이 인보크될 때, 런타임 타입에 대응하는 파티션 플러그인의 구현이 HK2 서비스로 검색될 것이고, 대응하는 create 메소드가 파티션 플러그인 구현 클래스 상에서 인보크될 것이다. 이는 런타임에 연결하고 런타임의 슬라이스를 생성하기 위한 구현 클래스에 달려 있다. 일단 생성되면, 파티션은 라이프사이클 관리자에 등록되고 lifecycle-config.xml에서 유지된다. 일 실시예에 따르면, 런타임은 파티션들에 대해 다음의 기능들을 제공한다.

동작	설명
createPartition	런타임의 슬라이스의 생성을 지원하는 런타임 상의 파티션을 생성. 런타임이 런타임을 슬라이싱하는 것을 지원하지 않는 경우, UnsupportedOperationException를 발생시킴.
deletePartition	런타임의 슬라이스의 삭제를 지원하는 런타임 상의 파티션을 삭제. 런타임이 런타임을 슬라이싱하는 것을 지원하지 않는 경우, UnsupportedOperationException를 발생시킴.
updatePartition	런타임의 슬라이스의 업데이트를 지원하는 런타임 상의 파티션을 업데이트. 런타임이 런타임을 슬라이싱하는 것을 지원하지 않는 경우, UnsupportedOperationException를 발생시킴.
registerPartition	파티션은 LCM을 이용하는 것이 아닌 어떤 다른 메커니즘을 이용하여 생성된 경우 파티션을 등록한다. 런타임이 파티션들/런타임을 슬라이싱하는 것을 지원하지 않는 경우 UnsupportedOperationException을 발생시킴.
getPartition	런타임의 슬라이스의 생성을 지원하는 런타임 상에 특정된 이름에 의해 파티션을 획득. 런타임이 특정된 이름을 갖는 파티션을 가지지 않는 파티션들을 지원하는 경우, null 값이 리턴된다. 런타임이 파티션들/런타임의 슬라이싱을 지원하지 않는 경우, 이 메소드는 UnsupportedOperationException를 발생시켜야만 한다.
getPartitions	런타임 상에서 생성된 모든 파티션들의 리스트를 리턴. 런타임이 런타임 상에서 생성되는 어떤 파티션들을 가지지 않는 파티션들을 지원하는 경우, null 값이 리턴된다. 런타임이 파티션들/런타임의 슬라이싱을 지원하지 않는 경우, 이 메소드는 UnsupportedOperationException를 발생시켜야만 한다.

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

package com.oracle.weblogic.lifecycle.plugin.wls;

import com.oracle.weblogic.lifecycle.core.LifecyclePartitionImpl;

import org.jvnet.hk2.annotations.Service;

import com.oracle.weblogic.lifecycle.*;

@Service(name = "Weblogic")

public class WLSPartitionPlugin extends PartitionPlugin {

@Override

public LifecyclePartition create(String partitionName, LifecycleContext ctx, Lifecycle LifecycleException {

// Implementation of creating a WLS partition.

}

@Override

public abstract LifecyclePartition migrate(String partitionName, String phase, LifecycleContext ctx,LifecycleRuntime runtime) throws LifecycleException

{

//Implementation of migration of a WLS Partition / Resource Group.

}

@Override

public abstract LifecyclePartition quiesce(String partitionName, String phase, LifecycleContext ctx, LifecycleRuntime runtime) throws LifecycleException

{

//Implementation of migration of a WLS Partition / Resource Group.

}

@Override

public void delete(String partitionName, LifecycleContext ctx, LifecycleRuntime runtime) throws LifecycleException

//Implementation of delete of a WLS Partition

}

@Override

public LifecyclePartition update(String partitionName, LifecycleContext ctx, Lifecycle LifecycleException {

// Implementation of update of a WLS Partition configuration

}

@Override

public void associate(LifecycleContext ctx, LifecyclePartition wlsPartition, LifecyclePartition otherPartition, LifecycleRuntime runtime) throws LifecycleException

// Associate two partitions (WLS partition with DB for example or WLS with OTD).

}

@Override

public void dissociate(LifecycleContext ctx, LifecyclePartition wlsPartition, LifecyclePartition otherPartition, LifecycleRuntime runtime) throws LifecycleException

//Dissociate previously associated partitions

}

플러그인 등록

전술한 바와 같이, 일 실시예에 따르면, 런타임 플러그인 및 파티션 플러그인은 HK2 서비스들로서의 이들 플러그인들의 구현과 함께 HK2 계약으로서 정의될 수 있다. HK2 서비스 이름은 플러그인이 등록된 서비스의 이름과 매치해야 한다. 플러그인 등록은 두 가지 방식으로 행해질 수 있는 바, 플러그인은 jar 파일로서 패키지되고 REST 커맨드들을 통해 라이프사이클 관리자에 등록되거나, 또는 예를 들어, WLS 시스템 어드미니스트레이터에 의해 구성가능해야 하는 라이프사이클 관리자 구현에 의해 특정된 디렉토리에 플러그인 구현 jar를 드롭한다. 라이프사이클 관리자는 플러그인을 로드하고 라이프사이클 관리자 구현에 등록하기 위해, 시동 시 디렉토리를 스캔한다. 플러그인을 배치하기 위한 디폴트 디렉토리는 oracle_home/wlserver/common/lifecycle/plugins이다.

환경

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

동작	설명
addPartition	환경에 소정 파티션을 추가.
removePartition	환경으로부터 소정 파티션을 제거.
getPartitions(type)	환경 내의 소정 타입의 모든 파티션들의 리스트를 리턴. 환경이 특정된 타입의 어떤 파티션들을 가지지 않는 경우, null이 리턴될 것이다.
getPartitions	환경 내의 모든 파티션들의 리스트를 리턴. 환경이 어떤 파티션들을 가지지 않는 경우, null이 리턴될 것이다.
associate	환경 내의 두 개의 파티션들을 관련시킴(연결함). 세부사항은 하기 섹션 참조.
dissociate	환경 내의 두 개의 파티션들을 관련 해제(dissociate). 세부사항은 하기 섹션 참조.
migrate	파티션의 마이그레이션을 개시. 세부사항은 하기 섹션 참조.

환경들과 파티션들의 관련

일 실시예에 따르면, 일단 파티션이 환경에 추가되면, 그 파티션은 환경에 추가된 다른 파티션들과 관련될 수 있다.

예를 들어, 환경이 WLS 파티션과 데이터베이스를 가진 경우, 이 둘을 관련시키는 것은 결과적으로, 관련된 데이터베이스를 참조하는 WLS에서 DataSource가 생성되게 한다. 두 개의 파티션을 관련시키기 위해, 먼저 파티션들은 환경에 추가될 필요가 있다. 일단 환경에 추가되면, 관련될 필요가 있는 두 개의 파티션들에서 패스하여 환경에서 관련 (예컨대, Associate) 메소드가 콜될 수 있다. 환경에서 associate가 콜될 때, 대응하는 플러그인의 associate 메소드는 라이프사이클 컨텍스트(예컨대, LifecycleContext) 객체와 함께 콜된다. 라이프사이클 컨텍스트는 두 파티션들의 필수 연결을 행할 수 있도록 플러그인에 패스되는 필수 정보를 가져야 한다. 파티션 플러그인들의 associate 메소드는 이들이 환경의 associate 메소드 콜에 패스되는 순서대로 인보크된다.

환경들로부터의 파티션들의 관련 해제(dissociation)

일 실시예에 따르면, 파티션이 더이상 사용되지 않는 경우, 환경 내의 다른 파티션들로부터 그 파티션에 대한 참조들이 삭제(delete)되기 전에 제거(remove)될 필요가 있다. 관련 해제는 한 환경에서 두 개의 파티션을 연결 해제하기 위한 메커니즘을 제공한다. 관련 해제가 콜되면 파티션 플러그인의 대응하는 dissociate 메소드가 인보크되며, 이는 두 파티션들을 함께 연결하는 구성을 제거하기 위한 플러그인의 역할을 한다.

예를 들어, WLS 파티션이 OTD 파티션 구성으로부터 관련 해제된 경우, OTD에 구성된 라우팅 정보가 제거될 것이고, 파티션에 대한 트래픽은 OTD를 통해 라우트되지 않을 것이다. 파티션 플러그인들의 dissociate 메소드는 이들이 메소드 콜에 패스되는 순서대로 인보크된다.

파티션 마이그레이션

일 실시예에 따르면, 파티션들의 마이그레이션을 지원하는 런타임들은 파티션 플러그인의 migrate 메소드를 구현할 필요가 있다. 파티션을 마이그레이션 할 때, 파티션과 관련된 다른 파티션들 역시 조치를 취해야 할 수 있다. 이를 해결하기 위해, migrate 메소드는 환경에 따라 조치를 취한다. 라이프사이클 관리자 인프라스트럭쳐는 먼저 마이그레이션되는 파티션의 migrate 메소드를 인보크해야하며 그 다음, 환경에 있는 다른 파티션들의 migrate 메소드를 콜해야 한다.

일 실시예에 따르면, 파티션의 마이그레이션은 상이한 페이즈들을 가질 수 있다. 이러한 시나리오에서, 파티션 플러그인의 migrate 메소드는 한 번보다 많이 인보크되어, migrate 메소드의 페이즈 파라미터를 통해 마이그레이션 페이즈를 나타낼 수 있다.

예를 들어, 파티션 마이그레이션 페이즈가 시작됨을 나타내는 "start_migration" 페이즈가 존재할 수 있다. 마이그레이션이 행해진 후, 후속적인 콜은 파티션이 마이그레이션되었음을 나타내는 페이즈인 "end_migration" 페이즈를 가질 것이다. 파티션이 추가적인 페이즈들을 지원하는 경우, 이러한 페이즈들은 완전한 기능을 보장하기 파티션 플러그인에 의해 지원될 수 있다.

"start_migration", "end_migration"은 파티션이 지원할 수 있는 페이즈들의 예들이며 모든 파티션이 지원해야 하는 정규적인 페이즈들의 리스트는 아니다. 파티션이 마이그레이션을 지원하지 않는 경우, UnsupportedOperationException이 발생되어야 한다. 파티션이 페이즈들을 지원하지 않는 경우, null 값은 migrate 메소드에 패스되는 유효한 값이다.

파티션들의 중지

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

구성 모듈

일 실시예에 따르면, 라이프사이클 관리자는 자신의 동작에 필요한 다양한 구성 요소들을 관리하는 구성 모듈을 포함한다. 구성 모듈은 여기에 설명되는 다양한 시나리오를 위해 필수적인 구성 인프라스트럭쳐를 제공한다. 구성 모듈은 두 가지 모드로 작동하는 바, 이 모드들은 로컬 모드(local) - 이 모드에서 라이프사이클은 어드민 서버에서 실행되고, 구성은 WLS config 디렉토리의 XML 파일에 유지됨 - 그리고 HA 모드(HA) - 이 모드에서 라이프사이클은 클러스터에서 실행될 수 있고, 구성은 데이터베이스에 유지됨 - 이다. 각 경우, 라이프사이클 구성은 구성들을 관리하기 위해 HK2 프레임 워크를 사용한다.

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

일 실시예에 따르면, 어드민 서버 상의 구성 파일에 변경들이 이루어지면, 그러한 변경들은 모든 피관리 서버들에 전파되어야 한다. 피관리 서버들은 피관리 서버 상에서 실행되는 어플리케이션들에 대한 올바른 테넌트 컨텍스트를 확립하기 위해 라이프사이클 구성을 이용한다. HK2 config 객체들은 xml 구성 파일의 리파싱(reparsing)을 허용하지 않는다. 대신, 새로운 객체는 인스턴스화되어야 하고 업데이트된 xml 파일은 신선하게(fresh) 파싱되어야 한다. 구성 변경이 커밋될 때, XML 파일은 특수 디렉토리, 즉 도메인에 대한 계류 디렉토리(pending directory)에 저장된다.

피관리 서버들에 대한 파일 전달

일 실시예에 따르면, 변경이 커밋될 때마다 LifecycleConfigDocument save () 메소드가 HK2에 의해 콜된다. 또한, 이 메소드는 파일의 복사본을 계류 디렉토리에 저장하고 그 다음, 피관리 서버들에의 변경된 파일의 업로드를 트리거하는 다음의 API를 콜한다.

ConfigurationManagerMBean.startEdit(...) ConfigurationManagerMBean.activate(...)

변경들을 주시(Watching for changes)

일 실시예에 따르면, 구성 파일의 제1 파싱에서 시작된 FileWatcher 데몬은 XML 파일이 변경되었음을 검출할 것이다. 그 다음, 이는 새로운 config 객체를 생성하고 xml 파일을 파싱할 것이다. 어떤 콜러들은 파싱 동안 정보에 액세스하는 것을 시도하는 것이 차단될 것이다. 파싱이 완료되는 대로, 수정된 데이터는 콜러들에게 이용가능해질 것이다.

구성된 데이터에 액세스

일 실시예에 따르면, HK2 구성은 LifecycleConfigFactory 클래스와 함께 노출될 수 있는 바, 예를 들자면 다음과 같다.

@Service

public class LifecycleConfigFactory implements PostConstruct {

public LifecycleConfig getLifecycleConfig();

public synchronized void reloadLifecycleConfig();

}

편집 세션들

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

라이프사이클태스크

라이프사이클 관리자를 통해 수행되는 특정한 동작들이 존재하는 바, 이 동작들은 선천적으로(naturally) 장기간의 비동기 동작들이다. 이러한 동작들의 예들은, 서버를 중지하는 것(runtime manager.quiesce) 또는 서버를 시작하는 것(runtime manager.quiesce)이다. 이러한 시나리오들에서, 라이프사이클 관리자 API의 시멘틱은 이러한 API들로부터 LifecycleTask 객체를 리턴하기 위해 비동기 적으로 만들어질 수 있다.

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

일반적으로, 사용자가 비동기 동작을 수행하고 LifecycleTask 객체를 다시 수신할 때, 이들은 그 객체로 다음의 두 가지 작업, 라이프사이클 태스크에 의해 표시된 비동기 동작의 상태를 획득하는 것 또는 라이프사이클 태스크에 의해 표시되는 비동기 동작을 취소하는 것 중 하나를 수행할 수 있다. 일 실시예에 따르면, 상기 동작들은 LifecycleTaskManager에 의해 노출된 인터페이스들에 의해 수행된다

동작	설명
getTaskStatus	LifecycleTask에 의해 표시되는 async 동작의 상태를 획득
cancelTask	LifecycleTask에 의해 표시되는 async 동작을 취소

라이프사이클 API들 및 클래스들

다양한 실시예들에 따라, 라이프사이클 인터페이스들 및 클래스들의 예들이 하기에 설명된다. 다른 실시예에 따르면, 다른 타입의 인터페이스들 및 클래스들이 제공될 수 있다.

라이프사이클 관리자

일 실시예에 따른, 예시적인 라이프사이클 관리자 인터페이스가 하기에 설명된다.

package com.oracle.weblogic.lifecycle;

import java.util.List;

import org.jvnet.hk2.annotations.Contract;

@Contract

public interface LifecycleManager {

/**

* @param environmentName

* @return object Environment

* This interface for creating a named logical Entity called Environment

*/

public Environment createEnvironment(String environmentName);

/**

* @param environmentName

* This interface for deleting a named logical Entity called * Environment

*/

public void deleteEnvironment(String environmentName);

/**

* @param environmentName

* @return object Environment

* This interface for getting Environment object given its name

*/

public Environment getEnvironment(String environmentName);

/**

* @param partitionId

* @param runtimeName

* @return object Environment

* This interface for getting Environment object partition Id and

*/

public Environment getEnvironment(String partitionId, String runtimeName);

/**

* @return List of Environment

* This interface has responsibility for getting all Environments.

*/

public List<Environment> getEnvironments();

/**

* This interface has responsibility for syncing all Environments.

* This call force sync partitions in an environment for all Environments

*/

public void syncEnvironments();

/**

* This interface has responsibility for syncing a named Environment.

* This call force sync partitions in an environment for given named Environment

*/

public void syncEnvironment(String environmentName);

}

런타임 관리자.자바 (Runtime Manager.Java)

일 실시예에 따른, 예시적인 런타임 관리자.자바 인터페이스가 하기에 설명된다.

package com.oracle.weblogic.lifecycle;

import java.util.List;

import java.util.Map;

import org.jvnet.hk2.annotations.Contract;

@Contract

public interface RuntimeManager {

/**

* @param runtimeType The type of runtime for which the runtime is being created

* @param runtimeName The name of the runtime for the runtime being created

* @param properties Properties to be passed to the runtime plugin

* @return

* @throws LifecycleException is thrown if the operation fails.

*/

public LifecycleRuntime createRuntime(String runtimeType, String runtimeName,

Map<String, PropertyValue> properties) throws LifecycleException

/**

* @param runtimeType The type of runtime being deleted (not sure if we

* need this - if we can determine the type from the runtime)

* @param runtimeName The name of the Runtime being deleted

* @throws LifecycleException thrown if the operation fails.

*/

public void deleteRuntime(String runtimeType, String runtimeName)

throws LifecycleException;

/**

* @param runtimeType The type of runtime being updated (not sure if we

* need this - if we can determine the type from the runtime)

* @param name The name of the Runtime being updated

* @param properties Properties to be passed to the runtime plugin

* @return

* @throws LifecycleException thrown if the operation fails.

*/

public LifecycleRuntime updateRuntime(String runtimeType, String name,

Map<String, PropertyValue> properties) throws LifecycleException

/**

* @param runtimeType The type of runtime being operated on

* @param name The name of the Runtime being operated on

* @param phase Phase for operation

* @param properties Properties to be passed to the runtime plugin

* @return

* @throws LifecycleException thrown if the operation fails.

*/

public LifecycleTask quiesceRuntime(String runtTimeType, String name, String phase, M

/**

* @param runtimeType The type of runtime being operated on

* @param name The name of the Runtime being operated on

* @param phase Phase for operation

* @param properties Properties to be passed to the runtime plugin

* @return

* @throws LifecycleException thrown if the operation fails.

*/

public LifecycleTask startRuntime(String runtTimeType, String name, String phase, Map

/**

* @param runtimeType The type of runtime being registered

* @param runtimeName The name of the runtime being registered

* @param properties Properties to be passed to the runtime plugin

* @throws LifecycleException if the register operation fails

*/

public void registerRuntime(String runtimeType, String runtimeName,

Map<String, PropertyValue> properties) throws LifecycleException

/**

* @param runtimeType The type of runtime being unregistered

* @param runtimeName The name of the runtime being unregistered

* @throws LifecycleException if the register operation fails

*/

public void unregisterRuntime(String runtimeType, String runtimeName)

throws LifecycleException;

/**

* @param runtimeType The type of runtime being scaled up

* (not sure if we need this - if we can determine

* the type from the runtime)

* @param runtimeName The name of the Runtime being scaled up

* @param scaleFactor The factor by which it is being scaled up.

* @param properties Properties to be passed to the runtime plugin

* @throws LifecycleException thrown if the operation fails.

* @throws UnsupportedOperationException if the operation isn't supported

* by the runtime type

*/

public LifecycleTask scaleUp(String runtimeType, String runtimeName, int scaleFactor,

Map properties) throws LifecycleException;

/**

* @param runtimeType The type of runtime being scaled down

* (not sure if we need this - if we can determine

* the type from the runtime)

* @param runtimeName The name of the Runtime being scaled down

* @param scaleFactor The factor by which it is being scaled down.

* @param properties Properties to be passed to the runtime plugin

* @throws LifecycleException thrown if the operation fails.

* @throws UnsupportedOperationException if the operation isn't supported

* by the runtime type

*/

public LifecycleTask scaleDown(String runtimeType, String runtimeName, int scaleFactor

Map properties) throws LifecycleException;

/**

* Get the specified Runtime

*

* @param runtimeName Get the specific runtime by name.

* @return

*/

public LifecycleRuntime getRuntime(String runtimeName);

/**

* Get a List of runtimes for the specified runtime type.

*

* @param runtimeType Get all the runtimes for the given runtime type

* @return List of LifecycleRuntimes

*/

public List<LifecycleRuntime> getRuntimes(String runtimeType);

/**

* Get a list of all the runtimes.

*

* @return List of Runtimes.

*/

public List<LifecycleRuntime> getRuntimes();

}

라이프사이클 런타임

일 실시예에 따른, 예시적인 라이프사이클 런타임 인터페이스가 하기에 기술된다.

package com.oracle.weblogic.lifecycle;

import java.io.File; import java.util.List; import java.util.Map;

import java.util.Properties;

public interface LifecycleRuntime {

/**

* Get the name of the Runtime

* @return the name of the runtime

*/

public String getRuntimeName();

/**

* The type of service of the runtime

* @return the type of the runtime

*/

public String getRuntimeType();

public void applyPartitionTemplate(File partitonTemplate);

/**

* The properties that represent the runtime

* @return the type of the runtime

*/

public Properties getRuntimeProperties();

/**

* Create a partition on this Runtime

* @param partitionName The name of the partition

* @param properties Properties passed to the plugin.

* @return

*/

public LifecyclePartition createPartition(String partitionName, Map properties) throws

/**

* Delete the specified Partition

* @param partitionName The specified named Partition to be deleted

*/

public void deletePartition(String partitionName, Map properties) throws LifecycleException

/**

* Update the specified Partition

* @param partitionName The specified named Partition being updated

* @param properties Properties passed to the plugin.

* @return

*/

public LifecyclePartition updatePartition(String partitionName, Map properties) throws

/**

* @return List of Partitions on this Runtime

*/

public List<LifecyclePartition> getPartitions();

/**

* Get the specific named Partition.

* @param partitionName The name of the Partition to get.

* @return

*/

public LifecyclePartition getPartition(String partitionName);

/**

* Register a partition on this Runtime with LCM

* @param partitionName The name of the partition

* @param partitionId The ID of the partition

* @return

* @throws com.oracle.weblogic.lifecycle.LifecycleException

*/

public void registerPartition(String partitionName, String partitionId);

/**

* UnRegister a partition on this Runtime with LCM

* @param partitionName The name of the partition

* @return

* @throws com.oracle.weblogic.lifecycle.LifecycleException

*/

public void unregisterPartition(LifecyclePartition partition);

}

라이프사이클 파티션

하나의 실시예에 따른, 예시적인 라이프사이클 파티션 패키지가 하기에 기술된다.

package com.oracle.weblogic.lifecycle;

public interface LifecyclePartition {

public String getName(); public String getType(); public String getId();

public String getRuntimeName();

}

런타임 플러그인

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

package com.oracle.weblogic.lifecycle;

import org.jvnet.hk2.annotations.Contract;

@Contract

public abstract class RuntimePlugin {

/**

* @param runtimeName

* @param ctx

* @throws com.oracle.weblogic.lifecycle.LifecycleException

* Implementation of method should facilitate creation of runtimes using runtime

*/

public abstract void create(String runtimeName, LifecycleContext ctx) throws LifecycleException

/**

* @param runtimeName

* @param ctx

* @throws com.oracle.weblogic.lifecycle.LifecycleException

* Implementation of method should facilitate deletion of runtimes using runtime

*/

public abstract void delete(String runtimeName, LifecycleContext ctx) throws LifecycleException

/**

* @param runtimeName

* @param ctx

* @throws com.oracle.weblogic.lifecycle.LifecycleException

* Implementation of method should facilitate updates of runtimes using runtimeN

*/

public abstract void update (String runtimeName, LifecycleContext ctx) throws LifecycleException

/**

* @param runtimeName

* @param scaleFactor

* @param ctx

* @throws com.oracle.weblogic.lifecycle.LifecycleException

* Implementation of this method should facilitate scaleUp of runtime

*/

public abstract LifecycleTask scaleUp(String runtimeName, int scaleFactor, Lifecycle

/**

* @param runtimeName

* @param scaleFactor

* @param ctx

* @throws com.oracle.weblogic.lifecycle.LifecycleException

* Implementation of this method should facilitate scaleDown of runtime

*/

public abstract LifecycleTask scaleDown(String runtimeName, int scaleFactor, LifecycleContext

/**

* @param runtimeName

* @param ctx

* @throws com.oracle.weblogic.lifecycle.LifecycleException

* Implementation of this method should facilitate quiesce of runtime

*/

public abstract LifecycleTask quiesce(String runtimeName, String phase, LifecycleContext

/**

* @param runtimeName

* @param ctx

* @throws com.oracle.weblogic.lifecycle.LifecycleException

* Implementation of this method should facilitate start of runtime

*/

public abstract LifecycleTask start(String runtimeName, String phase, LifecycleContext

}

파티션 플러그인

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

package com.oracle.weblogic.lifecycle;

import org.jvnet.hk2.annotations.Contract;

@Contract

public abstract class PartitionPlugin {

/**

* @param partitionName

* @param ctx

* @param runtime

* @return

* @throws com.oracle.weblogic.lifecycle.LifecycleException

* Implementation of method should facilitate creation of a Partition for a specific

* Component that the Plugin represents.

*/

public abstract LifecyclePartition create(String partitionName,

LifecycleContext ctx, LifecycleRuntime runtime)

/**

throws LifecycleException;

* @param partitionName

* @param phase

* @param ctx

* @param runtime

* @return

* @throws com.oracle.weblogic.lifecycle.LifecycleException

* Implementation of method should facilitate migration of a Partition for a specific

* Component that the Plugin represents.

*/

public abstract LifecyclePartition migrate(String partitionName,

String phase, LifecycleContext ctx, LifecycleRuntime runtime)

/**

throws LifecycleException;

* @param partitionName

* @param ctx

* @param runtime

* @throws com.oracle.weblogic.lifecycle.LifecycleException

* Implementation of method should facilitate deletion of a Partition for a specific

* Component that the Plugin represents.

*/

public abstract void delete(String partitionName,

LifecycleContext ctx, LifecycleRuntime runtime)

throws LifecycleException;

/**

* @param partitionName

* @param ctx

* @param runtime

* @return

* @throws com.oracle.weblogic.lifecycle.LifecycleException

* Implementation of method should facilitate update of a Partition for a specific

* Component that the Plugin represents.

*/

public abstract LifecyclePartition update(String partitionName,

LifecycleContext ctx, LifecycleRuntime runtime)

/**

throws LifecycleException;

* @param partitionName

* @param ctx

* @param runtime

* @return List<LifecycleTask>

* @throws com.oracle.weblogic.lifecycle.LifecycleException

* Implementation of method should facilitate quiesce of a Partition.

*/

public abstract List<LifecycleTask> quiesce(String partitionName,

String phase, LifecycleContext ctx, LifecycleRuntime runtime)

/**

throws LifecycleException;

* @param partitionName

* @param ctx

* @param runtime

* @return List<LifecycleTask>

* @throws com.oracle.weblogic.lifecycle.LifecycleException

* Implementation of method should facilitate start of a Partition.

*/

public abstract List<LifecycleTask> start(String partitionName,

String phase, LifecycleContext ctx, LifecycleRuntime runtime)

throws LifecycleException;

/**

* @param ctx

* @param partition1

* @param partition2

* @param runtime

* @throws com.oracle.weblogic.lifecycle.LifecycleException

* Implementation of this method should facilitate association of two Partitions.

*/

public abstract void associate(LifecycleContext ctx,

LifecyclePartition partition1, LifecyclePartition partition2,

/**

throws LifecycleException;

LifecycleRuntime runtime)

* @param ctx

* @param partition1

* @param partition2

* @param runtime

* @throws com.oracle.weblogic.lifecycle.LifecycleException

* Implementation of method should facilitate disassociation of two Partitions.

*/

public abstract void dissociate(LifecycleContext ctx,

LifecyclePartition partition1, LifecyclePartition partition2, LifecycleRuntime runtime)

throws LifecycleException;

}

환경

하나의 실시예에 따른, 예시적인 환경 인터페이스가 하기에 기술된다:

package com.oracle.weblogic.lifecycle;

import java.util.List;

import java.util.Map;

public interface Environment {

/**

*

* @return Name of environment

*/

public String getName();

/**

*

* @param partition

*/

public void addPartition(LifecyclePartition partition);

/**

*

* @param partitionType

* @param partitionName

*/

public void removePartition(String partitionType,

String partitionName);

/**

*

* @return

*/

public List<LifecyclePartition> getPartitions();

/**

*

* @param partitionType

* @return

*/

public List<LifecyclePartition> getPartitions(String partitionType);

/**

* Migrate the specified Partition

* @param partition The specified named Partition being updated

* @param runtime - the runtime on which the partition exists

* @param properties Properties passed to the plugin.

*/

public void migratePartition(LifecyclePartition lifecyclePartition,

LifecycleRuntime runtime, String phase, Map properties) throws LifecycleException;

/**

*

* @param partition1

* @param partition2

*/

public void associate(LifecyclePartition partition1, LifecyclePartition partition2, Map partitionProperties) throws LifecycleException;

/**

*

* @param partition1

* @param partition2

*/

public void dissociate(LifecyclePartition partition1, LifecyclePartition partition2, Map partitionProperties) throws LifecycleException;

/**

*

* @param lifecyclePartition

* @param phase

* @param properties

*/

public Map<String, List<LifecycleTask>> quiesce(LifecyclePartition lifecyclePartition, String phase, Map properties) throws LifecycleException ;

/**

*

* @param lifecyclePartition

* @param phase

* @param properties

*/

public Map<String, List<LifecycleTask>> start(LifecyclePartition lifecyclePartition,String phase, Map properties)

throws LifecycleException ;

}

라이프사이클 컨텍스트

일 실시예에 따른, 예시적인 라이프사이클 컨텍스트 인터페이스가 하기에 기술된다.

package com.oracle.weblogic.lifecycle;

import java.util.Map;

public interface LifecycleContext {

/**

* Map of properties that are passed from the client to the plugin

* @return

*/

public Map getProperties();

}

라이프사이클 동작 타입

하나의 실시예에 따른, 예시적인 라이프사이클 동작 타입 계산자(enumerator)가 하기에 기술된다.

package com.oracle.weblogic.lifecycle;

public enum LifecycleOperationType { CREATE_RUNTIME,DELETE_RUNTIME, UPDATE_RUNTIME, SCALE_UP_RUNTIME, SCALE_DOWN_RUNTIME, CREATE_PARTITION, DELETE_PARTITION, UPDATE_PARTITION, MIGRATE_PARTITION

}

라이프사이클 태스크

하나의 실시예에 따른, 예시적인 라이프사이클 태스크 인터페이스가 하기에 기술된다.

import java.util.Map;

public interface LifecycleTask

{

/**

* Get the type of component the task represents

*

* @return the type of the task (ex:wls)

* @include-api for-public-api

*/

public String getComponentType();

/**

* The properties that represent the task

*

* @return the Properties of the task

* Example: used to store things like servername in case of server operation

*/

public Map getProperties();

}

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

하나의 실시예에 따른, 예시적인 라이프사이클 태스크 관리자 인터페이스가 하기에 기술된다.

import org.jvnet.hk2.annotations.Contract;

import java.util.Map;

@Contract

public interface LifecycleTaskManager {

public String getTaskStatus(String runtimeName, String taskType, Map properties ) throw public void cancelTask(String runtimeName, String taskType, Map properties ) throws LifecycleException

}

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

도 10에 도시된 바와 같이, 단계(510)에서, 어플리케이션 서버 환경은 하나 이상의 파티션을 지원하는 소프트웨어 어플리케이션들의 실행을 위한 도메인을 포함하여 하나 이상의 컴퓨터들에서 제공되며, 각각의 파티션은 도메인의 어드미니스트레이티브 및 런타임 서브디비전을 제공하고, 파티션은 옵션에 따라서는, 전개가능한 어플리케이션들 또는 리소스들의 집합을 갖고 그리고/또는 리소스 그룹 템플릿을 참조하는 하나 이상의 리소스 그룹들을 포함할 수 있다.

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

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

단계(516)에서, 파티션의 생성 또는 구성 동안, 라이프사이클 관리자는 플러그인 인터페이스를 콜할 수 있는 라이프사이클 동작들을 수행하는 바, 이는 또한, 파티션으로 사용하기 위한 컴포넌트의 실제 생성 또는 구성, 예를 들어 트래픽 디렉터 인스턴스의 생성 또는 데이터베이스 인스턴스의 생성을 수행한다.

* * * * * * * * * *

텐넌트 온보딩

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

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

예를 들어, 상기 기술된 바와 같이, 시스템은 환경을 생성하기 위해 이용될 수 있어서, 예를 들어 FA 테넌트는 온보딩될 수 있고, 그 다음, OPSS(Oracle Platform Security Services) 및 SOA(Service Oriented Architecture)와 같은 상위 스택 컴포넌트는 그 환경 제공을 프로비전하기 위해 액세스를 얻을 수 있어서, 최종적으로 구성된 환경은 테넌트가 필요로할 모든 컴포넌트를 가질 것이다.

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

예를 들어, 테넌트가 SOA 및 BPM(Business Process Management) 서비스들에 가입하는 경우, 테넌트는 SOA 환경 및 BPM 환경을 수신할 것이며, 이러한 환경들은 모두 그 테넌트에 의해 링크될 것이다. 환경 내의 각 어플리케이션은 필요할 경우, 그 테넌트와 관련된 다른 환경에 대한 예컨대, HTTP 또는 T3 콜로서 원격 콜을 사용할 수 있다.

전술한 바와 같이, 일 실시예에 따르면, 시스템은 테넌시 컨텍스트 및 파티션 컨텍스트의 개념을 인식하며, 테넌시 컨텍스트는 일반적으로 더 많은 정보를 포함한다. 특정한 서비스는 예커내ㄷ, 어플리케이션 서버(예컨대, WebLogic, WLS), 데이터베이스(예컨대, 데이터베이스), 트래픽 디렉터 또는 다른 로드 밸런서(예컨대, Oracle Traffic Director, OTD)와 같은 다양한 컴포넌트의 여러 슬라이스들 또는 파티션들을 포함할 수 있다. 테넌트 컨텍스트는 서비스 및 그 서비스가 파티션 컨텍스트에 어떻게 매핑되는지를 나타내는 방식으로 특정한 테넌트에 대한 파티션 컨텍스트에 매핑된다.

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

도 11에 도시된 바와 같이, 일 실시예에 따르면, 테넌트 온보딩 API(550) 및 구성 인터페이스(560)는 어드미니스트레이터(562)가 테넌트 구성(564)을 제공할 수 있게 한다. 그 다음, 테넌트 온보딩 프로세스는 그 정보를 사용하여 UUID를 갖는 테넌트(565) 및 환경(566)을 식별하고, 그 테넌트의 환경(570)을 적절한 파티션 또는 도메인 레벨 리소스들에 매핑한다.

일 실시예에 따르면, 각 테넌트는 글로벌하게 고유한 ID(UUID)와 관련될 수 있고, 각각의 서비스는 마찬가지로, UUID와 관련될 수 있다. 이는, 시스템이 어느 서비스이든 테넌트 컨텍스트를 검색하기 위해 콜되는 컨텍스트에서 동작할 수 있게 한다. 상기 시스템은 또한, 특정한 태스크를 실행하기 위해 서로 다른 테넌트 컨텍스트들 사이에서 스위칭하기 위한 능력을 제공하는 바, 이는 일반적으로, 본 명세서의 다양한 실시예들에서 ExecuteAs 기능으로서 참조된다.

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

일반적으로, 시스템은 오직 글로벌 레벨 컨텍스트로부터 테넌트 컨텍스트로 스위칭될 수 있으며, 반대로 전환될 수 없어서, executeAs 동작은 오직, 글로벌 컨텍스트로부터 테넌트 컨텍스트로 실행될 수 있되, 테넌트로부터 테넌트 컨텍스트로는 실행될 수 없다.

터넌시 컨텍스트의 스위칭

일 실시예에 따르면, 시스템은 현재 요청을 처리할 수 있는 타겟 컴포넌트와 같은 요청 특질들에 기초하여 파티션 컨텍스트를 자동으로 결정할 수 있다. 스레드의 파티션 컨텍스트는 일반적으로 요청이 다른 파티션에 전개되는 컴포넌트에들어갈(enter) 때마다 변경된다.

예를 들어, 한 파티션에서 실행중인 서블릿이 EJB(Enterprise Java Bean) 또는 다른 파티션에서 전개되는 서블릿 또는 웹 서비스와 같은 원격 컴포넌트를 콜할 때, 타겟 컴포넌트를 호스트하는 파티션에서 원격 콜이 실행된다.

이 경우, 기저 플랫폼은 타겟 컴포넌트의 비즈니스 메소드를 콜하기 전에 적절한 파티션 컨텍스트를 설정하는 것을 처리한다. 어플리케이션 개발자는 이들이 다른 파티션 컨텍스트 하에서 코드를 실행하길 원할 때 이 기능을 사용할 수 있다.

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

특권화된 동작(privileged operation)으로서의 테넌시 컨텍스트 스위칭

일 실시예에 따르면, 글로벌 런타임과 같은 특권화된 어플리케이션 코드만이 테넌시 컨텍스트를 스위칭할 수 있다. 따라서, API는 액세스를 허용하기 전에 적절한 보안 수락 체크들을 시행해야 한다. 설정된 타겟 테넌시를 포함하는 수락(permission)이 허여될 수 있다.

불법적인 테넌시 스위칭으로부터의 보호

일 실시예에 따르면, 아래 표는 어떤 컨텍스트 스위치들이 코드의 보안 특권들에 대해 허용되는지를 설명한다.

현재의 어플리케이션 테넌시	새로운 어플리케이션 테넌시	가능 또는 불가능
글로벌	어떤 유효한 테넌시 컨텍스트	가능
글로벌	글로벌	가능
테넌트	글로벌	불가능
테넌트-i	테넌트-i	불가능
테넌트-i	테넌트-j	불가능
null	어떤 테넌시 컨텍스트	불가능

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

일 실시예에 따르면, 테넌트를 온보딩하기 전에, 테넌트가 가입한 서비스를 나타내는 환경이 생성되어야 한다. FA 프로비저닝 서브시스템은 먼저 환경을 생성하기 위해 라이프사이클 관리자 API에 콜할 수 있다. 일단 환경이 생성되면, 테넌트는 테넌트 어드민(예컨대, TenantAdmin) 클래스를 통해 온보딩될 수 있는 바, 이의 예가 하기에 예시된다. 그 다음, 테넌트 어드민은 테넌트를 등록하기 위해 API (예컨대, registerTenant)를 노출할 수 있다.

일단 테넌트가 등록되면, 인프라스트럭쳐를 프로비저닝함으로써 생성된 데이터베이스가 소정 테넌트을 위해 테넌트 어드민에 등록될 수 있다. 이 포인트에서 시스템은 테넌트를 그 환경에 온보딩할 수 있다. 테넌트를 온보딩시키는 것은 환경에 대한 테넌트에 대한 매핑을 유지하기 위해 패스될 (FA로부터 이용가능한) 서비스 이름 및 서비스 타입을 요한다. 테넌트 맵핑은 lifecycle-config.xml에 저장될 수 있다.

일 실시예에 따르면, lifecycle-config.xml에 저장된 테넌트 맵핑을 위한 예시적인 코드는 다음과 같다.

name="HCMProd" <service type="CRMService environment-ref="coke-hcmenv-prod"/>

</tenant>

</tenant>

</tenants>

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

@Inject

TenantAdmin tenantAdmin

@Inject

RuntimeManager rtmMgr;

@Inject

LifecycleManager lcmMgr;

// Database is the type of the Runtime and DB1 is the actual instance rtmMgr.registerRuntime("Database", "DB1", props); rtmMgr.registerRuntime("WebLogic", "WLSMTRuntime1", props);

// You can lookup a specific Runtime or have RuntimeManager select one based on type

// and some internal heuristics to determine which one to pick.

Runtime wlsRuntime = rtmMgr.getRuntime("WLSRuntime1");

or

Runtime wlsRuntime = rtmMgr.selectRuntime("WebLogic");

//Create a WLS Partition and a PDB

LifecyclePartition wlsPartition = wlsRuntime.createPartition("cokeCRMWLSProdPartition", Runtime dbRuntime = rtmMgr.getRuntime("DB1");

LifecyclePartition pdb = dbRuntime.createPartition("cokeCRMPDBProd", props);

Environment cokeEnv = lcmMgr.createEnvironment("coke-crmenv-prod"); cokeEnv.addPartition(wlsPartition);

cokeEnv.addPartition(pdb);

//Tenant ID and name are provided by Provisioning to LCM Tenant tenant = tenantAdmin.registerTenant("111", "coke"); tenantAdmin.onBoard(tenant, "CRMService","CRMProd", cokeEnv);

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

LifecycleRuntime runtime = rtmMgr.getRuntime("DB1"); runtime.registerDatabase("111", "cokeCRMPDBProd");

테넌트 컨텍스트

일 실시예에 따르면, FA/SaaS 및 어플리케이션 자체가 멀티테넌트를 인지하는 것으로 예상될 수 있는 유사한 시나리오들에서, 파티션 ID 및 파티션 이름에 추가적으로, 이들은 테넌트 대신 특정한 동작이 수행되게 하는 이 테넌트를 알 필요가 있다. 테넌트 컨텍스트(예컨대, TenantContext) API는 상부 스택 FMW/FA가 적절한 테넌트 컨텍스트를 획득하기 위해 사용할 JRF 계층에서 이용가능해질 수 있다.

TenantContextFactory tcFactory = TenantContextFactory.getTenantContextFactory(); TenantContext tenantContext = tcFactory.getTenantContext();

일단, 테넌트 컨텍스트가 결정되면, 컴포넌트는 소정 서비스에 대한 환경과 관련된 파티션(들)을 검색할 수 있다.

Environment env = tenantContext.getEnvironment();

List<Partitions> partitions = env.getPartitions(); Iterator iterator = partitions.iterator();

while (iterator.hasNext()) {

LifecyclePartition partition = iterator.next();

if (partition.getType.equals("WebLogic")) {

String partitionId = partition.getId(); String partitionName = partition.getName();

}

테넌트 매핑을 위한 JAVA SE에 대한 지원

하나의 실시예에 따른, 테넌트 컨텍스트를 검색하기 위해 SE에서 이용될 수 있는 예시적인 코드는 다음과 같다.

Java SE의 경우, 메소드가 TenantManager에서 노출될 수 있는 바, 상기 TenantManager는 테넌트 ID, 서비스 이름 및 서비스 타입에 기초하여 테넌트 컨텍스트를 패치할 것이다. getTenantContext ()가 처음 콜될 때, 테넌트 컨텍스트에 대한 셋업은 TenantContextFactory에 의해 암시적으로 행해질 수 있다.

SE 내의 Config 파일 부스트트랩들

일 실시예에 따르면, 이전 섹션에서 언급된 바와 같이, 테넌트 맵핑은 lifecycle-config.xml에 저장될 수 있다. SE에서, 시스템은 (a) 환경 변수 lifecycle.configDir에 의해 포인팅되는 위치에서 또는 (b) lifecycle.configDir 변수가 설정되지 않은 경우, System.getProperty("user.dir");를 이용하여 판독될 수 있는 사용자 작업 디렉토리에서 이 파일을 검색할 수 있다.

SE에서 테넌트 정보를 특정

일 실시예에 따르면, JAVA SE 모드에서 실행될 때, 테넌트를 식별하는 정보는 다음의 시스템 속성들, lifecycle.tenantId lifecycle.serviceName lifecycle.serviceType을 이용하여 또는 시스템 속성 lifecycle.serviceId를 통해 서비스 UUID를 특정함으로써 판독될 수 있다.

상기 정보는 테넌트를 고유하게 식별하며 라이프 사이클 구성에 존재하는 고유한 테넌트 플러스 서비스 조합을 식별하는 데 사용될 수 있다. SE 어플리케이션은 신원을 추정하며, 이는 TenantContextFcatory.getTenantContext가 콜될 때 표시된다.

SE에서의 테넌트 컨텍스트

일 실시예에 따르면, SE의 테넌트 컨텍스트는 InheritableThreadLocal에 저장된다. 처음 getTenantContext () 메소드가 콜될 때, 이는 테넌트 컨텍스트를 계산하기 위해 시스템 속성들을 이용하고, 이를 InheritableThreadLocal에 또한 저장한다.

동일한 메소드를 더 콜할 시, 시스템은 테넌트 컨텍스트가 Inheritable ThreadLocal에 저장되어 있는지를 체크하고, 저장된 것을 반환할 것이다. 프로그램 실행 중간에 시스템 속성들이 변경되면, 이러한 변경들은 Inheritable Thread Local 상의 테넌트 컨텍스트를 리프레쉬하기 위해 검출 및 사용될 수 있거나 혹은 검출 및 사용되지 않을 수 있다.

switchTenantContext로 스위칭(aka executeAs )

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

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

다양한 실시예에 따르면, 일부 메타데이터의 테넌트별 커스토마이제이션을 택하는 데 사용할 테넌트 데이터베이스 파티션을 선택하기 위해 MetaDataService에 의해 이용되는, FAMT 런타임에서의 테넌시의 여러 가지 서로 다른 이용이 존재하며, 이의 몇 가지 예들이 하기에 기술된다.

예를 들어, 이는 집행되어야 할 필요가 있는 보안 정책들을 택하기 위해 테넌트 데이터베이스 파티션을 선택하기 위하여 OPSS에 의해 이용될 수 있다. 또한, 이는 테넌트에 대한 감사 정책(audit policy)를 결정하고 감사 로그를 저장할 테넌트 데이터베이스 파티션을 선택하기 위해 감사 서비스에 의해 이용될 수 있다. 이러한 모든 경우에, 공유 서비스가 인보크되기 전에 정확한 테넌시가 실행의 스레드와 관련되도록 할 필요가 있다.

테넌시 컨텍스트가 명시적으로 설정되지 않은 경우, 이는 아래에 기술된 바와 같이 스레드의 현재 파티션 컨텍스트로부터 파생된다. 요청이 WLS에 들어가면, 적절한 컨테이너가 요청의 타겟 컴포넌트의 다양한 세부사항을 결정하고, 인보케이션을 나타내기 위해 ComponentInvocationContext 객체를 생성한다. 마찬가지로, WLS가 타이머 만료와 같은 일부 비동기 작업의 일부로서 콜백 객체를 인보크하면, 이는 스레드에 정확한 인보케이션 컨텍스트를 설정한다. ComponentInvocationContext의 일부로서, 파티션 정보가 또한 유지된다. 상기 설명된 온보딩 프로세스는 테넌트 컨텍스트를 통해 이용가능한 현재의 테넌트 값에 대한 현재의 파티션에 대한 필수적인 매핑을 제공한다.

글로벌 테넌시

전형적으로, 시스템의 어드미니스트레이션 코드는 일반적으로 모든 테넌트들을 대표하는 MT 어드미니스트레이터의 컨텍스트에서 실행될 필요를 가진다. 일 실시예에 따르면, 이 특별한 상태는 현재 요청과 관련된 테넌트 컨텍스트가 없음을 나타내는 null 테넌트 ID와는 다른 "GLOBAL"이라는 특별한 테넌트 ID로 표시된다.

GLOBAL Database를 사용하길 원하는 어떤 소프트웨어 코드는 항상 GLOBAL Database에 연결되는 DataSource에 대한 고정된 참조를 유지해야 한다. GLOBAL 런타임에서 실행되는 코드는 특정한 테넌트 DB에 대한 고정 바인딩을 가지는 것이 아니라, 대신 동작적 컨텍스트에 좌우되는 테넌트 DB로부터의 데이터에 액세스한다. 테넌트 DB들이 시스템에 미리 프로비저닝되어 있지 않기 때문에, 프록시 데이터 소스(예컨대, ProxyDataSource)가 이용될 수 있는 바, 여기서 코드는 프록시 데이터 소스에 대한 고정 JNDI 참조를 계속 가질 수 있고 이러한 참조는 현재의 테넌트 컨텍스트에 기초하여 특정한 기저 DB를 선택한다.

아래에 기술된 바와 같이, FMW/FA 코드가 WLS 외부에서 실행되어야 하는 두 가지 별개의 사용 경우들이 존재하는 바, 즉 특정한 라이프 사이클 동작들 및 어드미니스트레이티브 동작들이 Java SE 환경에서 발생한다. 비즈니스 프로세스 관리의 일부로서, 서버 코드는 때때로, 특정한 테넌트의 컨텍스트에서 작동하는 장기 실행 Java 프로세스를 포크(fork)한다.

JNDI 및 프록시 데이터 소스를 통해 이용가능한 프록시 데이터 소스에 대한 단일 참조를 가지는 것은, 테넌시 컨텍스트를 사용하여 적절한 기저 데이터베이스에게 콜을 위임하는 것을 처리한다. 이를 작업하기 위해, 테넌시 컨텍스트는 Java SE 프로세스에서 스레드에 정확하게 설정되어야 한다. Java SE 프로세스는 테넌트 이름 및 테넌트 id에 대한 시스템 속성들을 사용하여 GLOBAL 테넌트 컨텍스트에서 패스함으로써 런칭되어야 한다. 포크된 Java 프로세스는 실행의 스레드에 테넌시 컨텍스트를 확립하기 위해 이 정보를 사용하고 switchTenantContext를 콜한다.

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

일 실시예에 따르면, executeAs를 실행할 수 있게 하기 위해, 시스템은 현재의 테넌트 컨텍스트가 글로벌(Global)이도록 해야 한다. 이는 현재의 테넌트 컨텍스트에 대해, 해당 테넌트 ID가 0과 동일함을 체크함으로써 행해질 수 있다.

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

도 13에 도시된 바와 같이, 단계(630)에서, 하나 이상의 파티션들을 지원하는 소프트웨어 어플리케이션들의 실행을 위한 도메인을 포함하여 하나 이상의 컴퓨터에서 어플리케이션 서버 환경이 제공되며, 여기서 각 파티션은 도메인의 어드미니스트레이티브 및 런타임 서브디비전을 제공하고, 파티션은 옵션에 따라서는, 전개가능한 어플리케이션들 또는 리소스들의 집합을 갖고 그리고/또는 리소스 그룹 템플릿을 참조하는 하나 이상의 리소스 그룹들을 포함할 수 있다.

단계(632)에서, 서로 다른 컴포넌트들, 예컨대 어플리케이션 서버, 트래픽 디렉터들 또는 로드 밸런서들, 및 자신만의 파티션별 구성을 가질 수 있는 데이터베이스 또는 다른 컴포넌트들에 걸친 통합을 할 수 있게 하는 라이프 사이클 관리자가 제공된다.

단계(634)에서, 테넌트가 시스템에 온보딩되도록 하기 위한 테넌트 구성의 정의를 할 수 있게 하는 테넌트 온보딩 및/또는 구성 인터페이스가 제공된다.

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

단계(638)에서, 시스템은 옵션에 따라서는, 테넌트 스위치 인터페이스를 통해 테넌트의 컨텍스트에 스위치하고, 테넌트 온보딩 동안 그 테넌트로서 또는 그 테넌트 대신에 기능들을 실행할 수 있다.

* * * * * * * * * *

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

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

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

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

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

각각의 라이프 사이클 플러그인은 예를 들어, 어플리케이션 서버, 예컨대 WebLogic, WLS 또는 트래픽 디렉터 또는 다른 로드 밸런서, 예컨대 오라클 트래픽 디렉터, OTD 인스턴스 라이프 사이클에 대한 라이프 사이클 필요들을 캡슐화할 수 있다. 라이프 사이클 인터페이스는 각각의 플러그인에게 자신의 소정 컴포넌트의 라이프 사이클을 관리하기 위한 공통 또는 일반적인 프로세스를 제공한다.

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

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

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

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

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

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

라이프 사이클 관리자와의 인터랙션

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

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

일 실시예에 따르면, 어플리케이션 서버 플러그인은 서버와 인터랙션하기 위해 어플리케이션 서버(예를 들어, WLS)에 의해 노출된 JMX/REST API를 사용할 수 있다. 플러그인은 타겟화된 어플리케이션 서버 런타임들 상의 라이프 사이클 동작들이 어플리케이션 서버 파티션들 상에서 CRUD 동작을 행할 수 있게 하기 위해 라이프 사이클 관리자로부터 파티션 플러그인 계약을 구현한다. 파티션들에 대한 예를 들어, WLS 런타임 상에서 행해질 수 있는 몇몇 예시적인 동작들이 아래에 제공된다.

라이프사이클 동작	설명	앱 서버 플러그인에 의해 구현되는 계약
createPartition	라이프사이클 컨텍스트에 제공되는 정보에 기초하여 WLS 파티션을 생성	public abstract LifecyclePartition create(String partitionName, LifecycleContext ctx, LifecycleRuntime runtime) throws LifecycleException;
updatePartition	라이프사이클 컨텍스트에 제공되는 정보에 기초하여 WLS 파티션을 업데이트	public abstract LifecyclePartition update (String partitionName, LifecycleContext ctx, LifecycleRuntime runtime) throws LifecycleException;
deletePartition	라이프사이클 컨텍스트에 제공되는 정보에 기초하여 WLS 파티션을 삭제	public abstract void delete(String partitionName, LifecycleContext ctx, LifecycleRuntime runtime) throws LifecycleException;
associatePartition	WLS 파티션을 다른 타입의 파티션과 관련시킴(다른 타입의 예들은 OTD, 데이터베이스, 등등임)	public abstract void associate(LifecycleContext partition1Ctx ,LifecycleContext partition2Ctx, LifecyclePartition partition1, LifecyclePartition partition2,LifecycleRuntime runtime) throws LifecycleException;
dissociatePartition	WLS 파티션을 다른 타입의 파티션과 관련해제시킴	public abstract void dissociate(LifecycleContext partition1Ctx ,LifecycleContext partition2Ctx, LifecyclePartition partition1, LifecyclePartition partition2,LifecycleRuntime runtime) throws LifecycleException;
migratePartition	WLS 파티션을 새롭게 이용가능한 타겟들에 마이그레이션	public abstract LifecyclePartition migrate (String partitionName, LifecycleContext ctx, LifecycleRuntime runtime) throws LifecycleException;

일 실시예에 따르면, 어플리케이션 서버 플러그인은 타겟화된 어플리케이션 서버(예를 들어, WLS) 런타임 상에서 라이프 사이클 동작을 할 수 있도록 라이프 사이클 관리자로부터 런타임 플러그인 계약을 구현할 수 있는 바, 그 예는 다음과 같다.

런타임 동작	설명	앱 서버 플러그인에 의해 구현되는 계약
scaleup	이 웹로직 도메인 내의 미리 구성된 동적 클러스터에 존재하는 웹로직 서버 인스턴스를 스케일업	public abstract void scaleUp(String runtimeName, int scaleFactor, LifecycleContext ctx) throws LifecycleException;
scaledown	이 웹로직 도메인 내의 미리 구성된 동적 클러스터에 존재하는 웹로직 서버 인스턴스를 스케일다운	public abstract void scaleDown(String runtimeName, int scaleFactor, LifecycleContext ctx) throws LifecycleException;
quiesce	웹로직 서버 인스턴스를 중지	public abstract void quiesce(String runtimeName, LifecycleContext ctx) throws LifecycleException;

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

일 실시예에 따르면, 어플리케이션 서버 플러그인은 어플리케이션 서버, 예를 들어 WLS 런타임에 연결하기 위해 다음의 속성들을 사용한다. 이러한 속성들은 상기 계약에서 특정된 바와 같이 라이프 사이클 런타임 객체를 통해 라이프 사이클 동작에 패스된다.

Properties runtimeProperties = runtime.getRuntimeProperties();

속성	설명	속성 키
Host	웹로직 호스트	runtimeProperties.getProperty("hostname")
Port	웹로직 포트	runtimeProperties.getProperty("port")
username	어드민 사용자이름	runtimeProperties.getProperty("username")
password	어드민 패스워드	runtimeProperties.getProperty("password")

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

일 실시예에 따르면, 어플리케이션 서버 플러그인을 사용하여 행해지는 어떤 CRUD 동작은 라이프 사이클 컨텍스트 내의 플러그 인에 제공된 정보/데이터에 기초하여 커스터마이징될 수 있다. 클라이언트는 REST 콜의 일부로서 속성들을 특정할 수 있다. 라이프 사이클 관리자는 데이터를 라이프 사이클 컨텍스트에 채우고(populate), 속성을 다시 플러그인에 패스한다. 예를 들어, 클라이언트가 WLS 파티션에 대한 createPartition에 대해 REST 콜을 하면, 이들은 파티션의 특질들을 특정하기 위해 속성들을 특정할 수 있다.

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

일 실시예에 따르면, 파티션 생성/업데이트 동작 동안 클라이언트에 의해 특정될 수 있는 몇 가지 예시적인 특성들은 다음과 같다. 이러한 구성들은 파티션 생성/업데이트의 일부로 생성되며 파티션에 특정적이다.

속성	설명
resourcegroup	리소스 그룹 이름.
resourcegrouptemplate	리소스 그룹 템플릿. 특정된 리소스 그룹 템플릿이 도메인에 존재해야 하는 것으로 추정됨.
partitionPDBinfo	이 파티션에 대한 플러그가능한 데이터베이스 이름.
datasource	이 특정한 PDB에 대한 데이터소스 이름.
url	이 특정한 PDB에 대한 URL.
username	이 특정한 PDB에 대한 사용자이름.
password	이 특정한 PDB에 대한 패스워드.
partitionproperty	파티션 속성 키/이름.
partitionpropertyvalue	파티션 속성 값.

일 실시예에 따르면, 파티션을 생성/갱신하는 동안 클라이언트에 의해 특정될 수 있는 몇 가지 예시적인 속성들은 다음과 같다. 어플리케이션 서버(예컨대, WLS) 서버에서 이러한 엔티티를 발견하지 못하는 것은 결과적으로, 어플리케이션 서버 플러그인으로부터 예외(exception)가 발생하게 한다.

속성	설명
resourcegroup:target	이 리소스그룹과 관련될 타겟(타겟들의 쉼표 구분 리스트)
securityrealm	이 파티션과 관련될 보안 영역(realm)
partition:defaulttarget	타겟들의 쉼표 구분 리스트
partition:availabletarge	이용가능한 타겟들(타겟들의 쉼표 구분 리스트)

파티션 삭제를 위한 라이프 사이클 컨텍스트

일 실시예에 따르면, 어플리케이션 서버(예를 들어, WLS) 파티션을 삭제하기 위해 파티션 이름이 아닌 추가적인 속성은 필요하지 않다.

파티션 관련을 위한 라이프 사이클 컨텍스트

일 실시예에 따르면, 어플리케이션 서버 인스턴스를 다른 컴포넌트와 관련시키는 것은 몇몇 새로운 속성들로 어플리케이션 서버(예를 들어, WLS) 파티션을 업데이트하는 것을 수반할 수 있거나, 또는 관련을 위해 다른 컴포넌트에 필요한 속성들을 제공하는 것을 수반할 수 있다.

관련에 참여하길 원하는 어떤 컴포넌트는 상기 특정된 포맷으로 라이프 사이클 컨텍스트에서 정확한 속성들의 세트를 패스해야 한다.

WLS-OTD 관련의 경우, 이 경우 OTD 파티션은 관련을 행하기 위해 클러스터-이름, 클러스터-멤버 및 타겟 정보를 기대한다. 어플리케이션 서버 플러그인은 파티션 이름에 기초하여 정확한 타겟 정보를 패치하기 위해 어플리케이션 서버 런타임에 대한 JMX/REST 콜을 한다. 이러한 속성들은 associatePartition 구현의 일부로서 어플리케이션 서버의 lifecycleContext에 추가된다. 플러그인에 대한 관련 콜의 일부로서, 타겟 구성의 완전한 스냅샷이 라이프 사이클 컨텍스트에 추가될 것이다. 그 다음, 라이프 사이클 관리자는 본래의 서버 풀 및 어플리케이션 서버 파티션의 연결을 행하기 위해 (WLS 타겟들의 속성들을 갖는) 라이프 사이클 컨텍스트 를사용하는 OTD 플러그인의 associatePartition 구현을 콜한다.

일 실시예에 따르면, 어플리케이션 서버(예를 들어, WLS) 파티션이 OTD 파티션과 관련될 때 그리고 파티션이 구성된 클러스터에 타겟화되는 경우, 서버가 실행 중이 아니면, 라이프 사이클 관리자는 서버의 ListenAddress 및 Port에 이용가능한 구성 정보를 획득하고 이를 OTD로 전송할 것이다. 서버가 실행되고 있으면 RuntimeMBean으로부터 이용가능한 서버에 대한 런타임 정보를 획득하고 이를 컨텍스트 정보를 통해 OTD에 패스할 것이다.

동적 클러스터에서, 비록 구성 시간 정보가 동적 서버들을 위한 포트들에 이용가능하지만, ListenAddress에 이용가능한 구성 정보는 존재하지 않는다. 관련 콜이 발생할 때 동적 서버가 실행되지 않으면, 라이프 사이클 관리자는 구성된 포트 및 노드 관리자의 ListenAddress를 (동적 서버들이 머신과 관련된 경우) 획득하고 이를 다른 플러그인들에 전송할 것이다. 관련 콜이 발생할 때 동적 서버가 실행 중이면, 라이프 사이클 관리자는 런타임 Mbean으로부터 서버 청취 어드레스 및 포트를 획득하고 이를 OTD 플러그인들에 전송할 것이다.

WLS-DB 관련의 경우, 이 경우 어플리케이션 서버(예컨대, WLS) 플러그인의 associatePartition 메소드는, PDB Info를 채우고 PDB Info로 WLS 파티션을 업데이트하기 위해 DB 파티션의 lifecycleContext를 사용한다.

파티션 관련해제를 위한 라이프 사이클 컨텍스트

일 실시예에 따르면, 다른 컴포넌트와의 어플리케이션 서버(예를 들어, WLS)의 관련 해제는 특정 WLS 파티션 구성을 제거/업데이트하는 것을 수반할 수 있다. 관련 해제에 참여하길 원하는 어떤 컴포넌트는 상기 특정된 포맷으로 라이프 사이클 컨텍스트에서 정확한 속성들의 세트를 패스해야 한다. WLS와 DB 파티션 간의 관련 해제를 설명하는 예시가 아래에 제공된다.

WLS-DB 관련 해제: 이 경우, WLS 플러그인의 dissociatePartition 메소드는 PDB Info를 채우고 PDB Info를 제거함으로써 WLS 파티션을 업데이트하기 위해 DB 파티션의 lifecycleContext를 사용한다. WLS 플러그인은 lifecycleContext에서 PDB Info 이름을 기대한다.

WLS-OTD 관련 해제: 이 경우, OTD 파티션은 관련 해제를 행하기 위해 클러스터-이름, 클러스터-멤버들 및 타겟 정보를 기대한다. WLS 플러그인은 파티션 이름에 기초하여 정확한 타겟 정보를 패치하기 위해 WLS 런타임에 대한 JMX/REST 콜을 한다. 이러한 속성들은 WLS 플러그인의 dissociatePartition 구현의 일부로서 WLS의 lifecycleContext에 추가된다.

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

일 실시예에 따르면, 파티션 구성은 라이프 사이클 관리자 환경/범위의 밖에서 생성/업데이트/삭제될 수 있다. 예를 들어, 어드미니스트레이터는 파티션을 생성하기 위해 WLST 커맨드를 인보크하거나 또는 파티션을 업데이트하기 위해 WLS 어드민 콘솔을 사용할 수 있다. 어떠한 상황에서, 라이프 사이클 관리자에 존재하는 파티션 정보가 최신이고 최신으로 업데이트된 것이 되도록 해야 한다.

어플리케이션 서버 구성들에서 Lifecycle Manager 런타임 스케일링의 영향

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

탄성 프레임워크들은 클러스터 정보, 스케일 인자, 런타임 타입(예컨대, WLS)로 라이프 사이클 관리자에 대한 스케일업 또는 스케일 다운 콜을 할 수 있다. scaleUp/scaleDown에 등록되는 터셉터들은 클러스터가 스케일업하기 위해 필요로 하는 필수적인 인프라스트럭쳐를 검증 및 수행하기 위해 스케일업/스케일다운 동작 전에 인보크된다.

예를 들어, 데이터소스들의 수를 결정/생성하기 위해 WLS 런타임에 필수적인 콜을 하는 것이 클러스터에서 새로운 서버들을 가져오기 위해 필요로 되었다. 일단, 클러스터를 스케일 업/스케일 다운하기 위한 사전 요건이 만족되면(즉, 인터셉터의 어떤 사전 인보크가 만족되면), 실제 스케일 업 또는 스케일 다운이 발생한다. 인터셉터들은 후-인보크 요건들(post-invoke requirements)을 만족하기 위해 플러그인에서 동작이 완료된 후 다시 콜된다.

예를 들어, WLS 클러스터를 스케일링하기 위해 다수의 인터셉터들이 사용됨을 가정하여, 하나의 이러한 시퀀스가 하기에 기술된다.

탄성 모듈로부터의 WLSScaleDownAction이 lcm.scaleDown(clusterName, factor, payload)를 콜할 때 다음의 인터셉터들, WLS 인터셉터, OTD 인터셉터, JMS 인터셉터, DataSource 인터셉터가 추가되었음을 가정한다. 1. WLS 인터셉터는 스케일링이 클러스터 경계들 내에 있는지를 체크한다. 그 다음, 이는 ctx.proceed ()를 콜한다. 2. OTD 인터셉터는 소진(drain)될 선택된 타겟들을 마킹하기 위해 필요한 OTD config를 변경한다. OTD 인터셉터는 OTD 메트릭이 요청이 소진되었음을 나타낼 때까지 대기할 것이다. 그 다음, 이는 ctx.proceed()를 콜한다. 3. JMS 인터셉터는 JMS 백 로그들이 소진되도록 대기한다. 그 다음, 이는 ctx.proceed()를 콜한다. 4. DataSource 인터셉터는 모든 JDBC 연결들이 풀에 리턴되도록 할 것이다. 그 다음, 이는 ctx.proceed()를 콜한다. 5. (마지막 인터셉터 후 ElasticServiceManager에 의해 콜된) 서비스가 스케일다운된다.

인터셉터 콜 체인의 리턴 경로에서: 1. DataSourceInterceptor는 나머지 살아있는(alive) 피관리 서버들에 대해 max-connection-pool-size를 적절하게 증가시킬 것이다. 2. JMS 인터셉터는 아무것도 행하지 않는다. 3. OTD 인터셉터는 아무것도 행하지 않는다. 4. WLS 인터셉터는 아무것도 행하지 않는다.

REST 요청들을 이용한 어플리케이션 서버 플러그인의 인보케이션

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

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

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

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

라이프 사이클 관리자와의 인터랙션

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

런타임 등록

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

이름	설명
connectionURL	데이터베이스에 연결할 URL
username	데이터베이스 상에서 PDB 관리 동작들을 수행하기 위해 어드미니스트레이티브 특권들을 가지는 사용자
password	데이터베이스 사용자에 대한 패스워드

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

일 실시예에 따르면, 데이터베이스 라이프 사이클 플러그인은 JDBC를 통한 원격 SQL 연결을 사용하여 데이터베이스와 통신한다. 런타임 등록 동안 특정된 속성들은 데이터베이스에 연결하기 위해 이용된다. 다수의 라이프사이클 동작들은 예컨대, 라이프 사이클 컨텍스트 객체에서 패스된 그리고 플러그인에 패스된 속성들로부터 결정되는 다양한 절(clause)들을 대응하는 SQL 커맨드들에 매핑시킨다.

라이프 사이클 파티션 동작	플러그인 동작
create	CREATE PLUGGABLE DATABASE SQL 커맨드 실행
delete	DROP PLUGGABLE DATABASE SQL 커맨드 실행
update	ALTER PLUGGABLE DATABASE SQL 커맨드 실행
associate	데이터베이스 파티션을 WLS 파티션과 관련시킴
quiesce	ALTER PLUGGABLE DATABASE CLOSE 커맨드 실행
start	ALTER PLUGGABLE DATABASE OPEN 커맨드 실행

일 실시예에 따르면, 예들과 함께 상기 동작들의 세부 사항들이 아래에 제공된다.

생성(create)

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

삭제(delete)

일 실시예에 따르면, 삭제 동작은 다음 태스크들을 수행할 수 있다. (1) PDB 이름을 사용하여 플러그가능한 데이터베이스를 드롭한다. PDB 사용자들 역시 자동으로 드롭될 것이다. (2) 옵션에 따라서는, 상기 태스크들을 위해 플러그인에 의해 실행되는 PDB Sample SQL에 대한 CDB 계획 디렉티브를 디롭한다.

업데이트 (update)

일 실시예에 따르면, 업데이트 동작은 PDB에 대한 업데이트를 수행하기 위해 ALTER PLUGGABLE DATABASE 커맨드를 실행함으로써 플러그가능한 데이터베이스의 속성들을 수정한다.

Claims

멀티테넌트 어플리케이션 서버 환경에서 글로벌 런타임을 지원하는 시스템으로서,
상기 시스템은 하나 이상의 컴퓨터들을 포함하고, 상기 하나 이상의 컴퓨터들은, 복수의 리소스들과, 하나 이상의 파티션들과 그리고 글로벌 런타임과 함께, 상기 하나 이상의 컴퓨터들 상에서 실행되는 어플리케이션 서버 환경을 포함하며,
상기 복수의 리소스들은 상기 어플리케이션 서버 환경 내에서 이용될 수 있고,
각각의 파티션은 테넌트와 관련될 수 있는 도메인의 서브디비전을 제공하며,
상기 글로벌 런타임은 하나 이상의 리소스들 또는 리소스 그룹들이 상기 글로벌 런타임에서 사용하기 위해 도메인 레벨에서 특정될 수 있도록 상기 도메인의 범위에 있는 것을 특징으로 하는 시스템.
제1항에 있어서,
하나 이상의 리소스 그룹 템플릿들은 상기 도메인 내의 전개가능한 리소스들(deployable resources)의 그룹화들(groupings)을 정의하기 위해 이용되는 것을 특징으로 하는 시스템.
제1항 또는 제2항에 있어서,
도메인 레벨 리소스 그룹들의 타겟화가 리소스 그룹에서 설정될 수 있어서, 해당 리소스 그룹 내의 모든 리소스들이 해당 리소스 그룹에 대해 특정된 모든 타겟들에 타겟화되는 것을 특징으로 하는 시스템.
제1항 내지 제3항 중 어느 한 항에 있어서,
리소스 그룹이 클러스터에 타겟화될 때, 그 리소스 그룹 내의 어플리케이션들은 그 클러스터 내의 모든 피관리 서버(managed server)들 상에서 실행되는 것을 특징으로 하는 시스템.
멀티테넌트 어플리케이션 서버 환경에서 글로벌 런타임을 지원하는 방법으로서,
하나 이상의 컴퓨터들 상에서 실행되는 어플리케이션 서버 환경을 포함하는 상기 하나 이상의 컴퓨터들에서, 상기 어플리케이션 서버 환경 내에서 이용될 수 있는 복수의 리소스들과, 하나 이상의 파티션들을 제공하는 단계 - 각각의 파티션은 테넌트와 관련될 수 있는 상기 도메인의 서브디비전을 제공함 - 와; 그리고
하나 이상의 리소스들 또는 리소스 그룹들이 글로벌 런타임에서 사용하기 위해 도메인 레벨에서 특정될 수 있도록 상기 도메인의 범위에 있는 상기 글로벌 런타임을 제공하는 단계를 포함하는 것을 특징으로 하는 방법.
제5항에 있어서,
하나 이상의 리소스 그룹 템플릿들이 상기 도메인 내에서 전개가능한 리소스들의 그룹화를 정의하기 위해 이용되는 것을 특징으로 하는 방법.
제5항 또는 제6항에 있어서,
도메인 레벨 리소스 그룹들의 타겟화가 리소스 그룹에서 설정될 수 있어서, 해당 리소스 그룹 내의 모든 리소스들이 해당 리소스 그룹에 대해 특정된 모든 타겟들에 타겟화되는 것을 특징으로 하는 방법.
제5항 내지 제7항 중 어느 한 항에 있어서,
리소스 그룹이 클러스터에 타겟화될 때, 그 리소스 그룹 내의 어플리케이션들은 그 클러스터 내의 모든 피관리 서버들 상에서 실행되는 것을 특징으로 하는 방법.
명령어들이 저장된 비일시적 컴퓨터 판독가능 저장 매체로서, 상기 명령어들은 하나 이상의 컴퓨터들에 의해 판독 및 실행될 때, 상기 하나 이상의 컴퓨터들로 하여금 방법을 수행하게 하며, 상기 방법은:
어플리케이션 서버 환경과, 상기 어플리케이션 서버 환경 내에서 이용될 수 있는 복수의 리소스들과 그리고 하나 이상의 파티션들을 제공하는 단계 - 각각의 파티션은 테넌트와 관련될 수 있는 도메인의 서브디비전을 제공함 - 와; 그리고
하나 이상의 리소스들 또는 리소스 그룹들이 글로벌 런타임에서 사용하기 위해 도메인 레벨에서 특정될 수 있도록 상기 도메인의 범위에 있는 상기 글로벌 런타임을 제공하는 단계를 포함하는 것을 특징으로 하는 비일시적 컴퓨터 판독가능 저장 매체.
제9항에 있어서,
하나 이상의 리소스 그룹 템플릿들은 상기 도메인 내의 전개가능한 리소스들의 그룹화들을 정의하기 위해 이용되는 것을 특징으로 하는 비일시적 컴퓨터 판독가능 저장 매체.
제9항 또는 제10항에 있어서,
도메인 레벨 리소스 그룹들의 타겟화가 리소스 그룹에서 설정될 수 있어서, 해당 리소스 그룹 내의 모든 리소스들이 해당 리소스 그룹에 대해 특정된 모든 타겟들에 타겟화되는 것을 특징으로 하는 비일시적 컴퓨터 판독가능 저장 매체.
제9항 내지 제11항 중 어느 한 항에 있어서,
리소스 그룹이 클러스터에 타겟화될 때, 그 리소스 그룹 내의 어플리케이션들은 그 클러스터 내의 모든 피관리 서버들 상에서 실행되는 것을 특징으로 하는 비일시적 컴퓨터 판독가능 저장 매체.
하나 이상의 컴퓨터 시스템들 상에서 실행되기 위한 프로그램 명령어들을 포함하는 컴퓨터 프로그램으로서, 상기 프로그램 명령어들은 실행될 때, 상기 하나 이상의 컴퓨터 시스템들이 청구항 제5항 내지 제8항 중 어느 한 항의 방법을 수행하도록 하는 것을 특징으로 하는 컴퓨터 프로그램.
비일시적 머신 판독가능 데이터 저장 매체에 저장된 청구항 제13항의 컴퓨터 프로그램을 포함하는 컴퓨터 프로그램 물.