KR102663126B1

KR102663126B1 - 멀티테넌트 어플리케이션 서버 환경에서 복수의 파티션 편집 세션들을 지원하는 시스템 및 방법

Info

Publication number: KR102663126B1
Application number: KR1020227038266A
Authority: KR
Inventors: 마틴 마레스; 피터 보워; 페트르 야누흐; 마레크 포토샤; 파벨 부켓; 마이클 가즈도스
Original assignee: 오라클 인터내셔날 코포레이션
Priority date: 2014-06-23
Filing date: 2015-06-23
Publication date: 2024-05-07
Also published as: WO2015200375A1; KR20170020866A; EP3158447B1; US20160020949A1; JP2017519307A; CN106462833A; EP3158447A1; KR20220154243A; CN106462833B; JP6491243B2; US10009225B2

Abstract

하나의 실시예에 따르면, 멀티테넌트 어플리케이션 서버 환경에서 복수의 파티션들 및 편집 세션들을 지원하는 시스템 및 방법이 본 명세서에 기술된다. 하나의 실시예에 따르면, 제1 어드미니스트레이터(administrator) 또는 사용자가 파티션에 사용하기 위한 명명된 편집 세션(named edit sesstion)을 획득하고, 변경을 하고 그리고 이 변경들을 활성화시킬 수 있다. 다른 어드미니스트레이터 또는 사용자가 명명된 편집 세션을 병렬로 생성할 수 있다. 다른 사용자에 의해 이루어지는 동시적인(concurrent) 변경 및 변경들 간의 충돌들(conflicts)이 존재하는 경우, 어드미니스트레이터는 변경들을 활성화시킬 때 에러를 수신할 수 있다. 그러한 포인트에서, 어드미니스트레이터는 상기 갈등들을 해결하고 변경들을 활성화시킬 수 있다. 활성화 시, 편집 세션의 변경들은 글로벌 편집 구성에 적용될 것이다.

Description

멀티테넌트 어플리케이션 서버 환경에서 복수의 파티션 편집 세션들을 지원하는 시스템 및 방법{SYSTEM AND METHOD FOR SUPPORTING MULTIPLE PARTITION EDIT SESSIONS IN A MULTITENANT APPLICATION SERVER ENVIRONMENT}

저작권 공지

기술분야

본 발명의 실시예들은 일반적으로, 어플리케이션 서버들 및 클라우드 환경들에 관한 것이며, 특히 멀티테넌트 어플리케이션 서버 환경에서 복수의 파티션들(partitions) 및 편집 세션들을 지원하는 시스템 및 방법에 관한 것이다.

소프트웨어 어플리케이션 서버들 - 이들의 예들은 오라클 웹로직 서버(WLS) 및 Glassfish를 포함함 - 은 일반적으로, 기업 소프트웨어 어플리케이션들을 실행하기 위한 관리 환경을 제공한다. 최근, 클라우드 환경들에서 이용하기 위한 기술들이 또한 개발되어 왔는 바, 이 기술들은 사용자들 또는 테넌트들이 상기 클라우드 환경 내에서 자신의 어플리케이션들을 개발 및 실행할 수 있게 하고 상기 환경에 의해 제공되는 분산 리소스들의 장점을 취할 수 있게 한다.

1. 미국공개특허공보(US2001/0047276)(공개일: 2001년11월29일)

2. 미국특허(US7,725,559)(등록일: 2010년5월25일)

하나의 실시예에 따르면, 멀티테넌트 어플리케이션 서버 환경에서 편집 세션들을 지원하는 시스템 및 방법이 본 명세서에 기술된다. 하나의 실시예에 따르면, 제1 어드미니스트레이터(administrator) 또는 사용자가 파티션에 사용하기 위한 명명된 편집 세션(named edit sesstion)을 획득하고, 변경을 하고 그리고 이 변경들을 활성화시킬 수 있다. 다른 어드미니스트레이터 또는 사용자가 명명된 편집 세션을 병렬로 생성할 수 있다. 다른 사용자에 의해 이루어지는 동시적인(concurrent) 변경 및 변경들 간의 충돌들(conflicts)이 존재하는 경우, 어드미니스트레이터는 변경들을 활성화시킬 때 에러를 수신할 수 있다. 그러한 포인트에서, 어드미니스트레이터는 상기 갈등들을 해결하고 변경들을 활성화시킬 수 있다. 활성화 시, 편집 세션의 변경들은 글로벌 편집 구성에 적용될 것이다.

도 1은 하나의 실시예에 따른 어플리케이션 서버, 클라우드 또는 다른 환경에서 멀티-테넌시(multi-tenancy)를 지원하는 시스템을 도시한다.
도 2는 하나의 실시예에 따른 어플리케이션 서버, 클라우드 또는 다른 환경에서 멀티-테넌시를 지원하는 시스템을 더 도시한다.
도 3은 하나의 실시예에 따른 어플리케이션 서버, 클라우드 또는 다른 환경에서 멀티-테넌시를 지원하는 시스템을 더 도시한다.
도 4는 하나의 실시예에 따른 예시적인 멀티-테넌트 환경에서 사용하기 위한 도메인 구성을 도시한다.
도 5는 하나의 실시예에 따른 예시적인 멀티-테넌트 환경을 더 도시한다.
도 6은 하나의 실시예에 따른 어플리케이션 서버, 클라우드 또는 다른 환경에서 복수의 편집 세션들을 지원하는 시스템을 도시한다.
도 7은 하나의 실시예에 따른 어플리케이션 서버, 클라우드 또는 다른 환경에서 복수의 편집 세션들을 지원하는 시스템을 더 도시한다.
도 8은 하나의 실시예에 따른 어플리케이션 서버, 클라우드 또는 다른 환경에서 복수의 편집 세션들을 지원하는 시스템을 더 도시한다.
도 9는 하나의 실시예에 따른 어플리케이션 서버, 클라우드 또는 다른 환경에서 복수의 편집 세션들을 지원하는 시스템을 더 도시한다.
도 10은 하나의 실시예에 따른 어플리케이션 서버, 클라우드 또는 다른 환경에서 복수의 편집 세션들을 지원하는 방법을 도시한다.

하나의 실시예에 따르면, 멀티테넌트 어플리케이션 서버 환경에서 편집 세션들을 지원하는 시스템 및 방법이 본 명세서에 기술된다. 하나의 실시예에 따르면, 제1 어드미니스트레이터 또는 사용자가 파티션에 사용하기 위한 명명된 편집 세션을 획득하고, 변경을 하고 그리고 이 변경들을 활성화시킬 수 있다. 다른 어드미니스트레이터 또는 사용자가 명명된 편집 세션을 병렬로 생성할 수 있다. 다른 사용자에 의해 이루어지는 동시적인 변경 및 변경들 간의 충돌들이 존재하는 경우, 어드미니스트레이터는 변경들을 활성화시킬 때 에러를 수신할 수 있다. 그러한 포인트에서, 어드미니스트레이터는 상기 갈등들을 해결하고 변경들을 활성화시킬 수 있다. 활성화 시, 편집 세션의 변경들은 글로벌 편집 구성에 적용될 것이다.

어플리케이션 서버(예컨대, 멀티-테넌트, 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) 및 구성과 관련될 수 있고 어플리케이션들을 포함하고 그리고/또는 리소스 그룹들 및 리소스 그룹 템플릿들의 이용을 통해 도메인-와이드 리소스들을 참조할 수 있는 도메인의 런타임 및 어드미니스트레이티브 서브디비전 또는 슬라이드이다.

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

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

하나의 실시예에 따르면, 예컨대 config.xml 구성 파일에 의해 정의된 파티션 구성은 복수의 구성 요소들, 예컨대, 파티션을 정의하는 속성들 및 차일드 요소들을 포함하는 "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)를 정의할 수 있다. 상기 데이터베이스 인스턴스들은 호환가능한 스키마를 이용할 수 있는 바, 그 이유는 동일한 어플리케이션 코드가 두 데이터베이스들에 대해 실행될 것이기 때문이다. 시스템이 파티션들을 시작할 때, 이는 가상 타겟들, 및 각각의 데이터베이스 인스턴스들에게로의 연결 풀들을 생성할 수 있다.

복수의 편집 세션들에 대한 지원

어플리케이션 서버 환경, 예컨대 멀티테넌트 어플리케이션 서버 환경에서, 어플리케이션 서버 도메인은 복수의 파티션들 및 복수의 구성 파일들을 가질 수 있고, 서로 다른 타입의 어드미니스트레이터들에 의해 관리된다. 구성 파일들의 단일 편집 세션은 이러한 도메인에 불충분하다.

하나의 실시예에 따르면, 멀티테넌트 어플리케이션 서버 환경에서 편집 세션들을 지원하는 시스템 및 방법이 본 명세서에 기술된다. 하나의 실시예에 따르면, 제1 어드미니스트레이터 또는 사용자는 파티션에 이용할 명명된 편집 세션을 획득하고, 변경을 하고, 그 다음 이 변경들을 활성화시킬 수 있다. 다른 어드미니스트레이터 또는 사용자는 명명된 편집 세션을 병렬로 생성할 수 있다. 다른 사용자에 의해 이루어지는 동시적인 변경 및 변경들 간의 충돌들이 존재하는 경우, 어드미니스트레이터는 이 변경들을 활성화시킬 때 에러 알림을 수신할 수 있다. 그러한 포인트에서, 어드미니스트레이터는 충돌들을 해결하고 변경들을 활성화시킬 수 있다. 활성화 시, 편집 세션의 변경들은 글로벌 편집 구성에 적용될 것이다.

하나의 실시예에 따르면, 이 특징은 멀티테넌트 또는 비-멀티테넌트 환경에서 이용될 수 있다. 멀티테넌트 환경에서, 특징은 자동으로 시작될 수 있고, 비-멀티테넌트 환경에서, 특징은 수동으로 시작될 수 있다.

하나의 실시예에 따르면, 어드미니스트레이터, 예컨대 시스템 어드미니스트레이터 또는 파티션 어드미니스트레이터는 명명된 편집 세션을 시작하고, 도메인의 구성의 스냅샷을 찍을 수 있으며, 도메인 구성은 하나 이상의 파티션 구성들을 포함한다. 어드미니스트레이터는 상기 어드미니스트레이터가 변경하도록 인가된 도메인 구성의 부분들을 변경하고, 이 변경들을 활성화시킬 수 있다. 시스템은 후속적으로, 변경들과 하나 이상의 이미 활성화된 변경들 간의 어떤 충돌들을 체크할 수 있다.

하나의 실시예에 따르면, 충돌들은 명명된 편집 세션에 의해 이루어지는 변경들이 활성화될 때 동시적인 또는 병렬의 명명된 편집 세션들 간에 발생할 수 있다. 예를 들어, 제1 명명된 편집 세션이 시작된 후, 현재의 도메인 구성이 제2 명명된 편집 세션에 의해 변경되었을 수 있다. 상기 제1 명명된 편집 세션에서 도메인 구성의 스냅샷에 이루어진 변경들이 상기 도메인 구성에 적용되도록 활성화될 때, 잠재적인 충돌들이 발생할 수 있다. 잠재적인 충돌들의 일례는 제1 명명된 편집 세션이 제2 편집 세션에 의해 도메인 구성으로부터 삭제된 구성 빈(configuration bean)을 갱신한 경우이다.

하나의 실시예에 따르면, 충돌들은 둘 이상의 파티션 어드미니스트레이터들에 의해 동일한 파티션에 이루어진 변경들 간에, 도메인 구성의 글로벌 속성들을 수정한 둘 이상의 시스템 어드미니스트레이터들에 의해 이루어진 변경들 간에 또는 시스템 어드미니스트레이터 및 파티션 어드미니스트레이터에 의해 이루어진 변경들 간에 발생할 수 있다.

하나의 명명된 편집 세션으로부터의 변경들이 활성화될 때, 시스템은 충돌들을 검출할 수 있다. 충돌들이 구성가능한 룰들의 세트에 따라 해결될 수 있는 경우, 변경들은 활성화되어 현재의 도메인 구성에 적용된다. 충돌들이 상기 룰들에 기초하여 해결될 수 없는 경우, 활성화 동작은 이루어지지 못하고, 충돌들이 어드미니스트레이터에 의한 수동 해결을 위해 사용자 인터페이스 상에 디스플레이된다.

대안적으로는, 어드미니스트레이터는 관리 어플리케이션 프로그래밍 인터페이스를 통해 해결 메소드(resolve method)를 인보크(invoke)할 수 있고, 해결 메소드는 현재의 명명된 편집 세션에 어떤 동시적으로 적용되는 구성 변경들을 적용하기 위해 이용될 수 있다.

수동 해결 또는 해결 메소드에 의한 해결 후, 현재의 명명된 편집 세션의 변경들이 다시 활성화될 수 있다.

도 6은 하나의 실시예에 따른 어플리케이션 서버, 클라우드 또는 다른 환경에서 복수의 편집 세션들을 지원하는 시스템을 도시한다.

도 6에 도시된 바와 같이, 시스템은 어플리케이션 서버 환경(100)에서 도메인(602)을 포함한다. 도메이 구성(606)은 파티션들에 대한 복수의 구성들(예컨대, 파티션 구성 A(607) 및 파티션 구성 B(609))을 포함할 수 있다. 각각의 파티션 구성은 파티션을 정의할 수 있고, 어드미니스트레이터에 의해 파티션에 대해 편집될 수 있다.

하나의 실시예에 따르면, 시스템 어드미니스트레이터 또는 파티션 어드미니스트레이터는 구성의 스냅샷(예컨대, 구성 스냅샷 A(626a) 또는 구성 스냅샷 B(628b)) 상에서 작업함으로써 도메인 구성을 편집할 수 있다. 구성 스냅샷은 어드미니스트레이터 서버 상에 상주하는 구성 MBeans의 별개의 계층(hierarchy)에 의해 표시될 수 있다.

하나의 실시예에 따르면, 도메인 구성은 복수의 동시적인 세션들(예컨대, 편집 세션 A(623) 및 편집 세션 B(625))을 이용하여 복수의 어드미니스트레이터들(예컨대, 어드미니스트레이터 A(619) 및 어드미니스트레이터 B(621))에 의해 편집될 수 있다. 각각의 편집 세션은 세션 시작 시간에 특정되는 이름으로 고유하게 식별될 수 있고, 자신 만의 구성 파일들 및 자신만의 구성 관리 빈 인스턴스를 가질 수 있다.

도 6에 도시된 바와 같이, 어드미니스트레이터 A는 편집 세션 A에서 구성 스냅샷 A(627)을 편집할 수 있고, 어드미니스트레이터 B는 편집 세션 B에서 구성 스냅샷 B(631)를 편집할 수 있다.

하나의 실시예에 따르면, 어드미니스트레이터는 명명된 동시적인 편집 세션들을 생성 또는 파괴하기 위해 관리 API(611)(예컨대, 런타임 Mbean API)를 이용할 수 있다. 관리 API는 어드미니스트레이터가 복수의 동작들, 예컨대 편집 세션을 시작하는 것, 변경을 유지하는 것, 변경을 디스플레이하는 것 및 변경을 실행취소(undoing)하는 것을 수행할 수 있게 하는 복수의 인터페이스들(예컨대, 저장(613), 해결(615) 및 활성화(617))을 포함할 수 있다.

하나의 실시예에 따르면, 편집 세션에서 이루어지는 변경들은 도메인 내의 저장소(605)에 저장(637)될 수 있다. 저장된 변경들은 이들이 활성화될 때까지 효과를 발휘하지 않는다. 변경들을 활성화하는 것은 도메인 구성에 변경들을 병합(merging)하는 것과 그리고 도메인 내의 모든 서버 인스턴스들에 변경들을 배포(distributing)하는 것을 포함할 수 있다.

상기 기술된 바와 같이, 각각의 편집 세션은 도메인 구성의 스냅샷에서 작업한다. 각각의 편집 세션에서 이루어진 변경들 간에 충돌들이 발생할 수 있다. 예를 들어, 하나의 편집 세션이 다른 편집 세션에 의해 도메인 구성으로부터 삭제된 구성 빈을 갱신하거나 또는 하나의 편집 세션이 다른 편집 세션에 의해 또한 변경된 속성을 변경한다. 동일한 파티션에 대해 복수의 파티션 어드미니스트레이터에 의해 이루어지는 변경들 간에, 복수의 시스템 어드미니스트레이터들에 의해 이루어지는 변경들 간에 또는 시스템 어드미니스트레이터 및 파티션 어드미니스트레이터에 의해 이루어지는 변경들 간에 충돌들이 발생할 수 있다.

하나의 실시예에 따르면, 어드미니스트레이터가 편집 세션의 구성 변경을 활성화할 때, 동시적인 편집 세션 관리자(639)는 인보크(641)되어, 활성화될 변경들과 편집 세션이 시작된 후 활성화된 변경들 간의 충돌들을 검출할 수 있다. 동시적인 세션 관리자는 편집 세션에 의해 이루어지는 변경들(예컨대, 편집된 구성 스냅샷 A(647) 또는 편집된 구성 스냅샷 B(649)) 및 본래의 스냅샷(예컨대, 본래의 구성 스냅샷 A(626b) 또는 본래의 구성 스냅샷 B(628b))을 수신(653)할 수 있다. 마찬가지로, 동시적인 편집 세션 관리자는 현재의 도메인 구성(즉, 도메인 구성(605)) 또는 이의 일부를 수신(651)할 수 있다. 수신된 정보를 이용하여, 동시적인 편집 세션 관리자는 룰들의 세트에 따라 충돌들을 결정하고, 룰들의 세트에 기초하여 충돌들의 일부 또는 전부를 해결할 수 있다.

도 6에 도시된 바와 같이, 충돌들이 검출되지 않을 때 또는 검출된 충돌들이 성공적으로 해결된 때, 어드미니스트레이터에 의해 이루어지는 변경들이 도메인 구성에 적용(649)될 수 있다. 검출된 충돌들이 해결될 수 없는 경우, 충돌들(645)은 수동 해결을 위해 어드미니스트레이터에 디스플레이(629 또는 635)될 수 있다.

도 7은 하나의 실시예에 따른 어플리케이션 서버, 클라우드 또는 다른 환경에서 복수의 편집 세션들을 지원하는 시스템을 더 도시한다.

하나의 실시예에 따르면, 구성 스냅샷이 구성 파일들의 본래의 버전, 또는 편집 세션 또는 편집 트리가 시작된 구성을 표시할 수 있다.

상기 기술된 바와 같이, 구성 스냅샷들은 동시적인 편집 세션들에 의해 이루어지는 변경들 간의 충돌들을 결정할 시 이용하기 위해 구성 저장소에 유지 또는 카피(655 또는 657)될 필요가 있다.

하나의 실시예에 따르면, 동시적인 편집 세션과 관련된 구성 스냅샷은 상기 동시적인 편집 세션 또는 다른 동시적인 편집 세션이 활성화 동작을 수행할 때 구성 저장소에 유지될 수 있다. 활성화 동작이 검출되지 않으면, 구성 스냅샷은 카피될 필요가 있는 구성 파일들의 수를 감소시키기 위해 구성 저장소에 카피되지 않는다.

하나의 실시예에 따르면, 관리 API는 모든 구성 스냅샷들 또는 오직 충돌 결정에 필요한 구성 스냅샷을 카피하도록 구성될 수 있다. 대안적으로는, 관리 API는 구성 스냅샷 내의 충돌 결정에 필요한 그러한 파일들만을 카피하도록 구성될 수 있다.

예시적인 예로서, 어드미니스트레이터 A가 동시적인 편집 세션에서 작업하는 동안 어드미니스트레이터 B는 활성화 동작을 요청(711)한다. 상기 요청의 결과로서, 관리 API는 구성 스냅샷들 A 및 B 또는 이들 중 하나 또는 각 구성 스냅샷 내의 하나 이상의 파일들을 구성 저장소에 카피할 수 있다.

충돌 결정

도 8은 하나의 실시예에 따른 어플리케이션 서버, 클라우드 또는 다른 환경에서 복수의 편집 세션들을 지원하는 시스템을 더 도시한다.

하나의 실시예에 따르면, 동시적인 편집 세션들에 의해 이루어지는 변경들 간의 충돌들은 편집 세션이 활성화 동작을 수행할 때 결정된다.

예를 들어, 편집 세션에서 작업하는 어드미니스트레이터 B는 활성화 동작을 요청(811)하고, 규칙들의 세트에 따라 잠재적인 충돌들을 결정하기 위해 동시적인 세션 관리자를 인보크할 수 있다.

하나의 실시예에 따르면, 충돌들이 발견되고, 옵션에 따라서는 규칙 기반의 접근법을 이용하여 해결될 수 있다. 예를 들어, 편집 세션이 시작된 이래로 도메인 구성(예컨대, 웹로직 런타임 도메인 구성)에 대해 변경들이 이루어지지 않은 경우, 편집 세션 변경들은 활성화될 수 있다. 도메인 구성에 대해 변경들이 이루어진 경우, 동시적인 편집 세션 관리자는 편집 세션이 작업하는 본래의 구성 스냅샷과 도메인 구성 간의 차이들(853)을 결정할 수 있다. 동시적인 편집 세션 관리자는 또한, 편집 세션에서 이루어진 변경들을 포함하는 편집된 구성 스냅샷과 편집 세션이 작업하는 본래의 스냅샷 구성 간의 차이들(855)을 결정할 수 있다. 상기 결정된 차이들의 두 세트들은 잠재적인 충돌들(861)을 식별(857 또는 859)하기 위해 비교될 수 있다.

도 9는 하나의 실시예에 따른 어플리케이션 서버, 클라우드 또는 다른 환경에서 복수의 편집 세션들을 지원하는 시스템을 더 도시한다.

하나의 실시예에 따르면, 충돌들이 동시적인 세션 관리자에 의해 식별될 때, 관리 API 내의 해결 메소드가 이 충돌들을 해결하기 위해 어드미니스트레이터 B의 요청(911)으로 인보크될 수 있다.

하나의 실시예에 따르면, 해결 메소드는 파라미터(예컨대, stopOnConflict=false)로 실행되어, 변경들이 편집 세션 B에서 이루어진 변경들과 충돌하지 않는 경우 도메인 구성에 동시적으로 적용되는 어떤 변경들을 편집 세션 B에 적용(947)할 수 있다.

예를 들어, 변경들(945)은 본래의 구성 스냅샷 B와 도메인 구성 간의 차이들일 수 있다.

하나의 실시예에 따르면, 다음 룰들이 편집 세션에 변경들을 적용하기 위해 이용될 수 있는 바, 여기서 EDIT는 편집 세션을 나타내고, CURRENT는 도메인 구성을 나타내고, 빈은 도메인 내의 구성 빈일 수 있다.

1) EDIT는 CURRENT에서 삭제된 빈을 갱신했다. 빈에 대한 갱신은 속성을 변경하는 것 또는 차일드 빈을 추가하는 것을 포함한다.

RESOLVE METHOD: 빈은 EDIT에서 삭제될 수 있다.

2) EDIT는 CURRENT에서 변경된 빈을 삭제했다.

RESOLVE METHOD: 빈은 EDIT에서 삭제된 채로 유지될 것이다.

3) EDIT는 CURRENT에서 또한 변경된 속성을 변경했다. 이는 단순한 데이터타입 속성들 및 단순한 데이터타입 속성들의 어레이를 포함한다. 추가적으로, 순서에 민감한 MBean들의 어레이들이 존재한다.

RESOLVE METHOD: EDIT로부터의 값은 변경되지 않은 채로 유지될 수 있다.

4) EDIT는 CURRENT에 동일한 적격한 키(qualified key)를 갖는 새로운 빈을 추가된 빈으로서 추가한다. 이는 속성 변경 충돌과는 다른 충돌로서 검출되는 바, 그 이유는 WLS에서 기존 diff 및 merge 툴들(diff and merge tools)을 가능한 많이 이용하는 사용된 충돌 검출 및 해결 메소드에 더욱 적합하기 때문이다.

RESOLVE METHOD: 빈은 EDIT에서 변경되지 않을 것이다.

5) EDIT는 CURRENT에서 제거된 빈을 포인팅하는 참조를 (일부 속성의 값으로서) 설정한다.

RESOLVE METHOD: 참조가 비설정(un-set)된다.

6) CURRENT는 EDIT에서 제거된 빔을 포인팅하는 참조를 (일부 속성의 값으로서) 설정한다.

RESOLVE METHOD: EDIT는 변경되지 않을 것인 바, 즉 빈은 삭제된 채로 유지될 것이다.

7) EDIT는 CURRENT에서 삭제된 빈을 포인팅하는 참조를 (일부 속성의 값으로서) 포함하는 빈을 추가한다.

RESOLVE METHOD: 추가된 빈의 참조가 비설정(unset)될 것이다.

8) CURRENT는 EDIT에서 삭제된 빈을 포인팅하는 참조를 (일부 속성의 값으로서) 포함하는 빈을 추가한다.

RESOLVE METHOD: 새로운 빈은 EDIT에 또한 추가될 것이고, 참조는 비설정될 것이다.

리스팅 2

리스팅 2에 예시된 바와 같이, 인식된 구성 충돌들의 리스트 및 각각의 충돌에 대한 해결 메소드가 식별된다.

하나의 실시예에 따르면, 해결 메소드가 호출(call)된 후, 어드미니스트레이터는 편집 세션의 계류 변경들(pending changes)의 활성화를 다시 진행할 수 있다. 해결 동작은 그동안 다른 편집 세션이 어떤 새로운 변경들을 활성화시키지 않는 한, 충돌들이 더 존재하지 않음을 보장할 수 있다.

하나의 실시예에 따르면, 해결 프로세스는 구성 검증 단계에서 수락되지 않는 불일치 구성(inconsistent configuration)으로 이어질 수 있다. 어드미니스트레이터는 사용자 인터페이스 상에 디스플레이되는 정보를 이용하여, 해결된 세션을 일치되는 유효한 그리고 의미있는 상태로 수정할 수 있다. 디스플레이되는 정보는 충돌들을 포함할 수 있고, 각각의 충돌은 충돌의 설명, 예컨대 충돌에 있어서의 빈들/속성들의 식별 및 그 충돌에서 무엇이 해결되었는지를 기술하는 하나 이상의 메시지들을 포함할 수 있다.

어드미니스트레이터에 의해 이용될 수 있는 추가적인 정보는 각각의 해결 및 병합 단계의 짧은 설명을 포함할 수 있는 로그 메시지들을 포함한다. 로그 메시지들은 어느 변경들이 이루어졌는지 그리고 특정 편집 세션에서 어떻게 변경들이 이루어졌는지를 식별하기 위해 이용될 수 있다.

하나의 실시예에 따르면, 상기 기술된 정보는 사용자 인터페이스 상의 해결 태스크로부터 액세스가능하거나 또는 해결 메소드가 호출될 때 스크립팅 툴(예컨대, 웹로직 스크립팅 툴) 상에 프린트될 수 있다.

도 10은 하나의 실시예에 따른 어플리케이션 서버, 클라우드 또는 다른 환경에서 복수의 편집 세션들을 지원하는 시스템을 더 도시한다.

도 10에 도시된 바와 같이, 단계(1011)에서 어플리케이션 서버(예컨대, 멀티-테넌트) 환경은 하나 이상의 컴퓨터들 상에 제공될 수 있고, 어플리케이션 서버 환경은 하나 이사으이 파티션들을 갖는 도메인, 상기 도메인 및 파티션들을 구성하는 도메인 구성, 도메인 구성을 변경함에 있어서 어드미니스트레이터가 이용하는 관리 API를 포함한다.

단계(1013)에서, 복수의 동시적인 편집 세션들로부터의 변경들이 관리 API를 통해 수신되고, 각각의 동시적인 편집 세션은 도메인 구성의 스냅샷을 편집하기 위해 확립된다.

단계(1015)에서, 수신된 변경들의 충돌들이 도메인에서 동시적인 세션 관리자에 의해 검출될 수 있다.

단계(1017)에서, 충돌들은 해결을 위해 어드미니스트레이터에 디스플레이될 수 있다.

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

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

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

Claims

멀티테넌트 어플리케이션 서버 환경에서 복수의 편집 세션들을 지원하는 시스템으로서,
하나 이상의 컴퓨터들 -상기 컴퓨터들 각각은 하나 이상의 마이크로프로세서들을 포함함-;
상기 하나 이상의 컴퓨터들 상의 어플리케이션 서버 환경 -상기 어플리케이션 서버 환경은,
하나 이상의 파티션들(partitions)을 갖는 도메인,
상기 하나 이상의 파티션들 및 상기 도메인을 구성하는 도메인 구성,
구성 변경(configuration change)을 적용하는 데 이용하기 위한 복수의 메소드들(methods)을 포함하는 관리 API, 그리고
편집 세션들과 관련된 구성 스냅샷(configuration snapshot)들을 유지(persist)하는 구성 저장소를 포함함-; 그리고
상기 어플리케이션 서버 환경 내의 동시적인 편집 세션 관리 하드웨어 컴포넌트를 포함하고,
상기 동시적인 편집 세션 관리 하드웨어 컴포넌트(639)는, 상기 관리 API에 의해 인보크(invoke)될 때, 복수의 동시적인 편집 세션들(concurrent edit sessions)에 의해 이루어지는 변경들의 충돌들(conflicts)을 검출하고, 상기 충돌들의 해결을 위해 어드미니스트레이터(administrator)에 알림(alert)을 제공하고, 상기 복수의 동시적인 편집 세션들 각각은 상기 도메인 구성의 스냅샷(snapshot)을 편집하기 위해 설정되는(established) 것을 특징으로 하는 멀티테넌트 어플리케이션 서버 환경에서 복수의 편집 세션들을 지원하는 시스템.
제1항에 있어서,
상기 동시적인 편집 세션 관리 하드웨어 컴포넌트는:
상기 도메인 구성과 상기 도메인 구성의 스냅샷에 대한 어드미니스트레이터에 의한 변경들 간의 제1 차이를 결정하는 단계와;
상기 도메인 구성의 스냅샷과 상기 도메인 구성 간의 제2 차이를 결정하는 단계와;
상기 제1 차이와 상기 제2 차이를 비교하는 단계를 수행함으로써 상기 충돌들을 검출하는 것을 특징으로 하는 멀티테넌트 어플리케이션 서버 환경에서 복수의 편집 세션들을 지원하는 시스템.
제1항에 있어서,
상기 어드미니스트레이터는 시스템 어드미니스트레이터이고, 상기 복수의 동시적인 편집 세션들 각각은 다른 시스템 어드미니스트레이터에 의해 시작되는 것을 특징으로 하는 멀티테넌트 어플리케이션 서버 환경에서 복수의 편집 세션들을 지원하는 시스템.
제1항에 있어서,
상기 복수의 동시적인 편집 세션들 각각은 다른 파티션 어드미니스트레이터에 의해 시작되는 것을 특징으로 하는 멀티테넌트 어플리케이션 서버 환경에서 복수의 편집 세션들을 지원하는 시스템.
제1항에 있어서,
상기 복수의 동시적인 편집 세션들 각각은 시스템 어드미니스트레이터 및 파티션 어드미니스트레이터에 의해 시작되는 것을 특징으로 하는 멀티테넌트 어플리케이션 서버 환경에서 복수의 편집 세션들을 지원하는 시스템.
제1항에 있어서,
상기 동시적인 편집 세션 관리 하드웨어 컴포넌트는 상기 어드미니스트레이터에 의해 상기 도메인 구성에 대해 이루어진 변경들을 병합(merge)하기 위해 상기 어드미니스트레이터가 상기 관리 API를 이용하여 활성화 동작(activate action)을 수행할 때 인보크(invoke)되는 것을 특징으로 하는 멀티테넌트 어플리케이션 서버 환경에서 복수의 편집 세션들을 지원하는 시스템.
제1항에 있어서,
상기 어드미니스트레이터는 디스플레이되는 상기 충돌들을 본 후 상기 관리 API를 이용하여 해결 동작(resolve action)을 수행하며, 상기 관리 API를 이용하여 활성화 동작을 수행하는 것을 특징으로 하는 멀티테넌트 어플리케이션 서버 환경에서 복수의 편집 세션들을 지원하는 시스템.
제6항에 있어서,
상기 어드미니스트레이터에 의해 이루어진 변경들은 충돌들이 검출되지 않으면 상기 도메인 구성에 병합되는 것을 특징으로 하는 멀티테넌트 어플리케이션 서버 환경에서 복수의 편집 세션들을 지원하는 시스템.
제1항에 있어서,
상기 스냅샷은 상기 동시적인 편집 세션 관리 하드웨어 컴포넌트에 의해 상기 충돌들을 검출할 시 이용하기 위해 저장소에 유지(persist)되는 것을 특징으로 하는 멀티테넌트 어플리케이션 서버 환경에서 복수의 편집 세션들을 지원하는 시스템.
제9항에 있어서,
상기 스냅샷과 관련된 어드미니스트레이터가 활성화 동작을 수행할 때 상기 스냅샷의 유지가 발생되는 것을 특징으로 하는 멀티테넌트 어플리케이션 서버 환경에서 복수의 편집 세션들을 지원하는 시스템.
멀티테넌트 어플리케이션 서버 환경에서 복수의 파티션들 및 편집 세션들을 지원하고, 각 단계가 시스템에 의해 수행되는 방법으로서,
하나 이상의 컴퓨터들 상에 어플리케이션 서버 환경을 제공하는 단계 -상기 어플리케이션 서버 환경은,
하나 이상의 파티션들(partitions)을 갖는 도메인,
상기 하나 이상의 파티션들 및 상기 도메인을 구성하는 도메인 구성,
구성 변경(configuration change)을 적용하는 데 이용하기 위한 관리 API, 그리고
편집 세션들과 관련된 구성 스냅샷(configuration snapshot)들을 유지(persist)하는 구성 저장소를 포함함-; 그리고
상기 관리 API를 통해, 복수의 동시적인 편집 세션들(concurrent edit sessions)에 의해 이루어지는 변경들을 수신하는 단계 -상기 복수의 동시적인 편집 세션들 각각은 상기 도메인 구성의 스냅샷(snapshot)을 편집하기 위해 설정됨(established)-;
상기 어플리케이션 서버 환경 내의 동시적인 편집 세션 관리 하드웨어 컴포넌트(639)를 통해, 상기 관리 API에 의해 인보크(invoke)될 때, 상기 수신된 변경들의 충돌들을 검출하는 단계; 그리고
상기 동시적인 편집 세션 관리 하드웨어 컴포넌트를 통해, 상기 충돌들의 해결을 위해 어드미니스트레이터에 알림을 보내는(alerting) 단계를 포함하는 것을 특징으로 하는 멀티테넌트 어플리케이션 서버 환경에서 복수의 파티션들 및 편집 세션들을 지원하는 방법.
제11항에 있어서,
상기 동시적인 편집 세션 관리 하드웨어 컴포넌트는:
상기 도메인 구성과 상기 도메인 구성의 스냅샷에 대해 어드미니스트레이터에 의해 이루어진 변경들 간의 제1 차이를 결정하는 단계;
상기 도메인 구성의 스냅샷과 상기 도메인 구성 간의 제2 차이를 결정하는 단계; 그리고
상기 제1 차이와 상기 제2 차이를 비교하는 단계를 수행함으로써, 상기 충돌들을 검출하는 것을 특징으로 하는 멀티테넌트 어플리케이션 서버 환경에서 복수의 파티션들 및 편집 세션들을 지원하는 방법.
제11항에 있어서,
상기 어드미니스트레이터는 시스템 어드미니스트레이터 및 파티션 어드미니스트레이터로 구성된 그룹으로부터 선택되는 것을 특징으로 하는 멀티테넌트 어플리케이션 서버 환경에서 복수의 파티션들 및 편집 세션들을 지원하는 방법.
제11항에 있어서,
상기 복수의 동시적인 편집 세션들 각각은 다른 파티션 어드미니스트레이터 또는 다른 시스템 어드미니스트레이터에 의해 시작되는 것을 특징으로 하는 멀티테넌트 어플리케이션 서버 환경에서 복수의 파티션들 및 편집 세션들을 지원하는 방법.
제11항에 있어서,
상기 복수의 동시적인 편집 세션들 각각은 시스템 어드미니스트레이터 및 파티션 어드미니스트레이터에 의해 시작되는 것을 특징으로 하는 멀티테넌트 어플리케이션 서버 환경에서 복수의 파티션들 및 편집 세션들을 지원하는 방법.
제11항에 있어서,
상기 동시적인 편집 세션 관리 하드웨어 컴포넌트는 상기 어드미니스트레이터에 의해 상기 도메인 구성에 이루어진 변경들을 병합하기 위해 상기 어드미니스트레이터가 상기 관리 API를 이용하여 활성화 동작을 수행할 때 인보크되는 것을 특징으로 하는 멀티테넌트 어플리케이션 서버 환경에서 복수의 파티션들 및 편집 세션들을 지원하는 방법.
제11항에 있어서,
상기 어드미니스트레이터는 디스플레이된 상기 충돌들을 본 후 상기 관리 API를 이용하여 해결 동작을 수행하며, 상기 관리 API를 이용하여 활성화 동작을 다시 수행하는 것을 특징으로 하는 멀티테넌트 어플리케이션 서버 환경에서 복수의 파티션들 및 편집 세션들을 지원하는 방법.
제16항에 있어서,
상기 어드미니스트레이터에 의해 이루어진 변경들은 충돌들이 검출되지 않으면 상기 도메인 구성에 병합되는 것을 특징으로 하는 멀티테넌트 어플리케이션 서버 환경에서 복수의 파티션들 및 편집 세션들을 지원하는 방법.
제11항에 있어서,
상기 스냅샷은 상기 동시적인 편집 세션 관리 하드웨어 컴포넌트에 의해 상기 충돌들을 검출할 시 이용하기 위해 저장소에 유지되는 것을 특징으로 하는 멀티테넌트 어플리케이션 서버 환경에서 복수의 파티션들 및 편집 세션들을 지원하는 방법.
명령어들이 저장된 비일시적 컴퓨터 판독가능 저장 매체로서, 상기 명령어들은 하나 이상의 컴퓨터들에 의해 판독 및 실행될 때, 상기 하나 이상의 컴퓨터들로 하여금 단계들을 수행하게 하며, 상기 단계들은:
i) 하나 이상의 파티션들(partitions)을 갖는 도메인, ii) 상기 하나 이상의 파티션들 및 상기 도메인을 구성하는 도메인 구성, 그리고 iii) 구성 변경(configuration change)을 적용하는 데 이용하기 위한 관리 API를 포함하도록 하나 이상의 컴퓨터들 상에 어플리케이션 서버 환경을 구성하는 단계;
상기 관리 API를 통해, 복수의 동시적인 편집 세션들에 의해 이루어지는 변경들을 수신하는 단계 -상기 복수의 동시적인 편집 세션들 각각은 상기 도메인 구성의 스냅샷을 편집하기 위해 설정됨(established)-;
상기 수신된 변경들의 충돌들을 검출하는 단계; 그리고
상기 충돌들의 해결을 위해 어드미니스트레이터에 알림을 보내는 단계를 포함하는 것을 특징으로 하는 비일시적 컴퓨터 판독가능 저장 매체.