KR20140047580A

KR20140047580A - 다중-서버 예약 시스템 상의 동기화 메커니즘 시스템 및 방법

Info

Publication number: KR20140047580A
Application number: KR1020137023248A
Authority: KR
Inventors: 벵상 마시니; 사무엘 뷔르데스; 마르크 빠보; 제롬 다니엘; 디아뜨마 뽀제
Original assignee: 아마데우스 에스.에이.에스.
Priority date: 2011-03-15
Filing date: 2012-01-12
Publication date: 2014-04-22
Also published as: JP2014522513A; EP2500832B1; US20120239620A1; KR101863398B1; CN103443790A; CA2827244A1; AU2012228693A1; ES2689112T3; EP2500832A1; ZA201306241B; WO2012123136A1; SG192783A1; BR112013021987A2; JP5841177B2; AU2012228693B2

Abstract

본 발명의 바람직한 실시예에 따른 방법 및 시스템에 의하면 효율적이고 일관된 메커니즘으로 다중-서버(아마도 멀티-플랫폼) 예약 시스템에 걸쳐 PNR 값을 동기화할 수 있다. 그 메커니즘은 그 버전화 및 그 느릿한 거동(동기화는 필요할 때에만 일어남) 덕분에 일관성 및 성능 문제를 다룬다. 이것은 하나의 시스템으로부터 또 다른 시스템으로의 이주 단계 동안 데이터를 공유하는 애플리케이션이 점진적으로 이주하는 솔루션으로서, 그리고 또한 여러 다른 플랫폼에 걸쳐 분산된 애플리케이션을 위한 영구적 솔루션으로서 사용될 수 있다. 본 발명의 바람직한 실시예에 의하면, 예약 서비스는 2개의 서로 다른 플랫폼(예컨대, 메인프레임과 개방형 플랫폼) 사이에 분산되어 있고, 이들은 이들의 비즈니스 기능을 수행하기 위해 읽기 및 쓰기 모드에서 동일한 여객 예약 기록(PNR) 콘텍스트 데이터를 공유할 것을 필요로 한다. 본 발명의 바람직한 실시예의 방법 및 시스템에 의하면, 시스템이 동일한 최신 PNR 콘텍스트 데이터를 공유할 수 있도록 서로 다른 플랫폼에 걸쳐 그리고 여러 통신 프로토콜에 걸쳐(예컨대, TPF 메인프레임과 개방형 시스템) 읽기 및 쓰기 모드에서 공유되는 데이터(예컨대, PNR 데이터)의 동기화가 가능하다.

Description

다중-서버 예약 시스템 상의 동기화 메커니즘 시스템 및 방법{METHOD AND SYSTEM FOR SYNCHRONIZATION MECHANISM ON MULTI-SERVER RESERVATION SYSTEM}

본 발명은 여행 예약 시스템 분야에 관한 것으로, 더 구체적으로는, 분산된 콘텍스트 동기화 메커니즘을 사용하여 다중 서버 상에서 여행 예약을 취급하기 위한 방법 및 시스템에 관한 것이다.

현대의 여행 회사(예컨대, 항공사)는 고객에 의한 예약 요청을 취급하기 위해 통상 정교한 애플리케이션을 채용하고 있다. 하나 이상의 아키텍처가 회사 시스템 도처에서 사용되는 경우는 점점 더 빈번하게 되고 있다. 그러한 경우에 있어서는, 예약 시스템을 설계 및 계획할 때 호환성 및 동기화 문제가 고려되어야 한다. 예로서 인터넷 기반 애플리케이션 또는 통신 기반구조 상에서 예약 관리의 일부가 수행될 때이다. 또 다른 예로서는 시스템(반드시 예약 시스템인 것은 아님)이 레거시 메인프레임 시스템(예컨대, TPF)으로부터 신규 시스템(예컨대, 개방형 시스템)으로 이주되어야 할 때이다. 우리는 이러한 마지막 예, 즉, 애플리케이션이 예컨대 TPF 메인프레임으로부터 예컨대 개방형 시스템으로 이주되어야 할 때를 퇴역(Decommissioning)이라 지칭한다. 예약 시스템에서 서비스 인터럽트를 회피하기 위해, 기존 시스템을 폐쇄하고 일어날 수 있는 모든 가능한 문제를 갖는 하나의 단일 이동으로 신규 시스템으로 전환하는 대신에, 이러한 이주를 점진적으로 수행할 것을 권한다: 구 시스템과 신규 시스템간 전환 시에 거대한 활성화 절차의 복잡도에 더하여, 우리는 또한, 신규 시스템이 구축 중이고 구 시스템이 계속 진화하는 동안, 둘 다의 플랫폼 상에서 소프트웨어의 이중 유지의 필요성을 고려하여야 한다. 어쩌면 신규 기능이 개발되어야 하고 이것은 이중 노력을 필요로 하지만, 2개의 시스템이 함께 작동할 수 있다면 모든 개발 노력을 신규 플랫폼에 전념할 수 있다. 이러한 이유들 때문에, 점진적 이주가 소위 "빅뱅" 이주 전략에 바람직하지만, 몇몇 어려움이 고려되어야 한다. 구체적으로, 예약 서비스가 2개의 서로 다른 플랫폼(예컨대, 메인프레임과 개방형 플랫폼)간 분산되어 있을 때, 그들은 그들의 비즈니스 기능을 수행하기 위해 읽기 및 쓰기 모드에서 동일한 여객 예약 기록(Passenger Name Record; PNR) 콘텍스트 데이터를 공유할 필요가 있다. 고려되어야 할 문제 중 하나는 시스템이 동일한 최신 PNR 콘텍스트 데이터를 공유할 수 있도록 여러 다른 플랫폼 전체에 걸쳐 그리고 통신 프로토콜 전체에 걸쳐(예컨대, TPF 메인프레임과 개방형 시스템) 읽기 및 쓰기 모드에서 공유되는 데이터(예컨대, PNR 데이터)의 동기화이다. "콘텍스트(context)"라 함은, 활성 (최종) 사용자 세션에 링크되어 있는 쇼핑 세션 콘텍스트를 의미한다. 이것은 요청된 기능을 수행하도록 특정 사용자에 대해 시스템에 의해 사용되는 모든 기능적 및 기술적 정보, 예컨대, 여행 예약 시스템에서는, 활성 최종 사용자 세션에 링크되어 있는 예약 (쇼핑) 세션 콘텍스트를 표현한다.

본 발명의 목적은 종래 기술의 시스템과 연관된 문제 중 적어도 일부를 완화시키는 것이다.

본 발명의 일 태양에 의하면, 다중-서버 시스템 상에서 동작하는 예약 방법에서, 다중-서버 시스템의 적어도 2개의 서버에 걸쳐 사용자 트랜잭션(user transaction) 동안 가장 최신 PNR 레코드가 사용되는 것을 보장하기 위한 동기화 메커니즘 방법이 제공되는데, PNR의 로컬 콘텍스트 버전은 다중 서버 시스템의 각각의 서버 내 유지되고, 서버는 시스템 버스를 통해 상호접속되어 있고, 그 메커니즘은: 다중-서버 시스템의 모든 서버에 의해 액세스가능한 공유 콘텍스트 저장 구역에 PNR의 최후 업데이트 버전 상의 정보를 유지하는 단계; 서버 중 선택된 하나가 PNR의 로컬 콘텍스트 버전을 수정하도록 야기하는 사용자 요청에 응답하여 다음의 액션: 어느 서버가 PNR을 최후에 업데이트하였는지 공유 콘텍스트 저장 구역 상에서 체크하는 액션; PNR을 최후에 업데이트한 서버가 선택된 서버와 다르면 PNR의 최신 버전을 획득하는 액션; 사용자 요청을 충족하도록 PNR의 로컬 콘텍스트 버전을 수정하는 액션; PNR의 최후 업데이트 버전을 반영하도록 공유 콘텍스트 저장 구역을 업데이트하는 액션을 수행하는 단계를 포함한다.

본 발명의 바람직한 실시예에 따른 방법에 의하면 효율적이고 일관된 메커니즘으로 다중-서버(아마도 멀티플랫폼) 시스템에 걸쳐 PNR 값을 동기화할 수 있다. 그 메커니즘은 그 버전화 및 그 느릿한 거동(동기화는 필요할 때에만 일어난다) 덕분에 일관성 및 성능 문제를 다룬다. 이것은 하나의 시스템으로부터 또 다른 시스템으로의 이주 단계 동안 데이터를 공유하는 애플리케이션이 점진적으로 이주하는 솔루션으로서, 그리고 또한 여러 다른 플랫폼에 걸쳐 분산된 애플리케이션을 위한 영구적 솔루션으로서 사용될 수 있다.

본 발명의 두 번째 태양에 의하면, 상기 방법을 수행하도록 적응된 하나 이상의 컴포넌트를 포함하는 시스템이 제공된다.

본 발명의 추가적인 실시예에 의하면, 컴퓨터 프로그램으로서, 상기 컴퓨터 프로그램이 컴퓨터 시스템 상에서 실행될 때 상기 방법을 수행하기 위한 명령어를 포함하는 컴퓨터 프로그램이 제공된다.

이제, 예로써, 수반 도면을 참조할 것이다.
도 1은 본 발명의 일 실시예에 따른 인벤토리 시스템도;
도 2는 본 발명의 바람직한 실시예에서 사용되는 분산된 콘텍스트 상관기의 가능한 구조의 개략도;
도 3은 유스-케이스 형식주의(use-case formalism)를 갖는 공유 콘텍스트에서의 값의 연관된 변경과 여러 다른 플랫폼 상에서의 요청 프로세스도;
시스템 상는 본 발명의 바람직한 실시예의 방법을 지원하도록 적응된 일반적 컴퓨터 시스템도;
도 5 내지 도 9(a 및 b)는 본 발명의 바람직한 실시예에 따라 EDIFACT 구조(a-도면) 및 유스-케이스 도면(b-도면)으로 분산된 콘텍스트 동기화의 5개 서비스를 도시하는 도면;
도 10은 본 발명의 일 실시예에 따라 프로세스의 방법 단계의 흐름도.

본 발명이 기초하고 있는 예는 예약 시스템을 위한 복합 TPF 아키텍처로부터 개방형 시스템 아키텍처로의 이주(migration)이다. 많은 이유로, 상기한 바와 같이, 하나의 단일 이동으로 이주를 행하는 것은 권하지 않는다. 그래서, (수 개월 또는 수 년 지속할 수 있는) 전이 기간 동안, 예약 시스템은 메인프레임, 예컨대, 국제 비즈니스 코포레이션의 TPF 또는 MVS 시스템과 개방형 플랫폼, 예컨대, Unix 또는 Linux 시스템간에 분산된다. 예약 시스템은 예컨대 아마데우스 기반구조 상에 구현될 수 있다. 그렇지만, 본 발명은 여러 다른 플랫폼을 갖는 다수의 서버 전체에 걸쳐 작동하는 어떠한 예약 시스템 구현에라도 적용가능하다.

메인프레임으로부터 개방형 플랫폼으로의 이주의 예에 있어서, TPF 메인프레임 상에서 PNR 애플리케이션은 메모리에 동일한 PNR 콘텍스트를 공유하고 읽기 및/또는 쓰기 모드에서 API를 거쳐 직접 데이터에 액세스할 수 있다. TPF 재설계 및 TPF 메인프레임으로부터 PNR 애플리케이션의 이주 때문에, 여러 다른 플랫폼 사이에 PNR 콘텍스트 공유의 문제가 나타난다. 참으로, 우리는 전 플랫폼에 걸쳐 수행되는 비즈니스 기능 액션의 일관성을 보장하기 위해 동일한 PNR 데이터로의 액세스를 갖도록 여러 다른 플랫폼 상에 분산된 애플리케이션을 필요로 하는 이종 플랫폼 전체에 걸쳐 공유된 사용자 콘텍스트를 갖는 단일 시스템의 개념을 갖는다. 도 1의 도면 상에, 하나가 다른 하나에 의해 제공된 PNR 정보에 의존하는 2개의 애플리케이션을 갖는 예가 표현되어 있다. 이것은 비즈니스 기능을 수행할 수 있기 위해 둘 다의 로컬 PNR 콘텍스트가 동기화되어야 함을 나타내고 있다. 2개의 애플리케이션(앱1과 앱2)은 예약 시스템에서 협력한다: 앱1(단지 예를 들어 예약 애플리케이션)은 시스템(101) 상에서 실행되는 한편, 앱2(예컨대, 가격 책정 애플리케이션)는 시스템(103) 상에서 실행된다. 우리의 예에서의 시스템(101)은 TPF 메인프레임인 한편, 시스템(103)은 개방형 시스템 예컨대 유닉스 시스템이다. 더 일반적으로 2개의 시스템(101, 103)은 2개의 서로 다른 플랫폼상의 어떠한 알려져 있는 시스템이라도 될 수 있다. 2개의 시스템(101, 103)은 단말(107)을 통해 사용자에 의해 또한 액세스가능한 엔터프라이즈 서비스 버스(ESB; 105)에 의해 서로 접속되어 있다. 단말(107)과 ESB(105)간 접속은 어떠한 적합한 네트워크 배열(예컨대, TCP/IP)로라도 이루어질 수 있다. 또한, ESB는 구현 예이고, 알려져 있는 다른 구조, 예컨대, 라우터, 포털 또는 요청 브로커가 대신 사용될 수 있다. 각각의 시스템(101, 103)은 PNR 정보가 유지되고 있는 로컬 저장 구역(각자 109, 111)으로의 액세스를 갖는다. 로컬 PNR 정보는 로컬 시스템에 대해서는 가장 최신일 것이지만, 다른 시스템에 관하여는 구식일 수 있다. 본 실시예에 있어서, 우리는 2개의 서로 다른 플랫폼 상에서 작동하는 2개의 시스템(101, 103)을 갖는 예를 사용하였지만, 당업자라면 수 개의 서로 다른 시스템을 갖는 다른 구현이 가능함을 인식할 것이다. 도 1의 예에 있어서, 사용자는, 단말(107) 및 ESB(105)를 통해, PNR의 로컬 버전(109) 상에서 작동하는 앱1에 예약을 요청한다(단계(1)); PNR은 앱1에 의해 이루어진 정교화(elaboration)에 따라 업데이트된다(단계(2)). 제어가 앱2로 넘겨질 때(단계(3)), 애플리케이션은 PNR의 로컬 버전(111) 상에서 작동한다(단계(4)). 이를 행하기 전에 로컬 PNR이 가장 최신 버전인지(본 예에서는 그렇지 않음) 검증할 필요가 있고, 그렇지 않다면 업데이트가 필요하다. 앱2는 그 정교화를 완료하기 위해 외부 시스템(113)(예컨대, 가격 책정 데이터베이스)에 액세스할 수 있다(단계(5)).

본 발명의 바람직한 실시예에 따른 방법 및 시스템에 있어서, PNR 콘텍스트의 로컬 인-메모리(in-memory) 복사본은 각각의 플랫폼 상에서 복제된다; 업데이트는 로컬 수행되고 동기화는 또 다른 플랫폼이 최신 콘텍스트 데이터에 액세스할 필요가 있을 때 일어난다. 이것이 소위 분산된 콘텍스트 동기화이다. 동기화 메커니즘의 복잡도는 로컬 복사본이 구식인지 아닌지 결정하고 가장 최신 PNR 데이터를 입수하기 위해 그것이 어디에 위치하고 있는지 결정하는 것이다. 이러한 메커니즘은 통신 프로토콜이 무엇이든지간에 모든 유형의 사용자 질의 상에서 작동하고 데이터의 표현(예컨대, 빅 또는 리틀 엔디안(big or little endian))과 같은 플랫폼 기술적 특성에 의존하지 않는다.

PNR 콘텍스트 동기화에 대한 현 접근법은 동기화가 필요할 때에만 수행되는 최적화된 방식으로 모든 이들 요구에 응답하고, 로컬 콘텍스트 복사본 상에서 행하여질 업데이트만을 제공한다. 본 발명의 핵심 엘리먼트는 공유 파라미터의 가장 최신 값이 프로세스 동안 어느 때라도 사용되는 것을 보장하는 메커니즘이다. 본 발명의 바람직한 실시예에 따른 방법 및 시스템에 있어서는 분산된 공유 콘텍스트 상관기가 사용된다. 일례로서, 소위 DCX(분산된 콘텍스트 상관기)라는 아마데우스 예약 시스템이 설명된다. DCX는, 여러 다른 플랫폼 및 애플리케이션 상의 응용 콘텍스트의 분산을 표현하는 모든 유형의 통신 프로토콜 상에서, 동일한 사용자 세션으로부터 오는 각각의 메시지의 상부 상에 부가적 정보를 운반한다.

DCX 개체는 ESB 상에서 생성 및 저장되고, 세션 헤더에서 아마데우스 기반구조 내 모든 메시지 상에서 운반된다. 도 2는 본 발명의 바람직한 실시예에 따른 DCX 구조(200)의 예를 도시하고 있다. 이는 여러 다른 플랫폼 상의 콘텍스트에 대한 참조를 포함하는데, 그것이 콘텍스트 데이터 자체를 포함하지는 않음을 의미한다. 그것은 XML로 형식화되고 도 2에 도시된 바와 같이 3개의 파트로 이루어진다: 하나는 라우팅 및 다른 유스-케이스에 사용되는 ESB 콘텍스트 정보를 위해 예약되고(201), 다른 하나의 파트는 보안 및 사용자 인증에 전용이고(203), 마지막으로 제3 파트는 애플리케이션이 그 콘텍스트 참조 및 그와 연관된 상태 지시자를 부가할 수 있는 응용 파트(205)이다. 콘텍스트 동기화 프로세스가 분산된 PNR 콘텍스트와 관련된 정보를 저장하는 것이 응용 파트에서이고, 이것은 없이는 작동하지 않을 메커니즘의 기초이다.

DCX는 동기화 메커니즘에 필요한 2개의 다른 특징을 제안하는데, 친화도(affinity) 및 여러 다른 통신 프로토콜간 콘텍스트 공유이다. 친화도는 동일한 서비스가 호출될 때마다 바로 그 동일한 애플리케이션 서버를 겨냥하도록 필요로 되고 이것은 PNR 콘텍스트가 애플리케이션 서버에 로컬일 때 필요하다. 바람직하게는, 친화도와 관련된 정보는 DCX에 포함되어 있는 "친화도 키"라 지칭될 수 있는 키에 포함되어 있다. 전 프로토콜에 걸친 콘텍스트 정보의 공유는 여러 다른 프로토콜 상에서 PNR 서비스를 사용자 호출하는 것이 여전히 바로 그 동일한 PNR 콘텍스트 상에서 작동하고 있을 것을 보장하도록 필요로 된다.

콘텍스트의 수명 듀레이션은 ESB와 개방형 시스템(또는 메인프레임)간 확립된 대화에 의해 제어된다. DCX는 사용자 활동의 글로벌 뷰를 제안하는데, 사용자가 하나의 특정 대화(예컨대 EDIFACT 대화)를 통해 작업하고 있으면 다른 프로토콜 대화는 전 프로토콜에 걸쳐 일관성을 보장하도록 유지될 것임을 의미한다. 사용자가 (특정 대화 닫음에 의해 또는 휴지 타임아웃에 의해) ESB로부터 접속해제할 때, 개방형 시스템 및 메인프레임으로의 대화 또한 닫힐 것이고 콘텍스트의 클린업을 트리거링할 것이다. DCX의 설명은 또한 본 발명과 동일 출원인에 의해 출원되고 동일 우선일을 갖는 동시 계류중인 출원 "METHOD AND SYSTEM FOR PROVIDING A SESSION INVOLVING A PLURALITY OF SOFTWARE APPLICATIONS" 및 "METHOD AND SYSTEM FOR PROVIDING A SESSION IN A HETEROGENEOUS ENVIRONMENT"에서 이용가능하다. 본 발명의 설명의 예에 있어서, 서버간 접속은 ESB에 의해 실현되지만, 당업자라면 적절한 애플리케이션 서버로 트랜잭션을 라우팅할 수 있는 어떠한 다른 최신 라우팅 수단이라도, 예컨대, 라우터, 포털 또는 요청 브로커가 대신 사용될 수 있음을 인식할 것이다.

분산된 콘텍스트 동기화 메커니즘은 머신 또는 애플리케이션 서버라고도 지칭될 수 있는 여러 다른 플랫폼 상에 로컬 콘텍스트 상태에 대한 정보를 저장하도록 공유 콘텍스트(DCX) 개체의 응용 파트를 사용한다. 각각의 플랫폼은 그 로컬 콘텍스트를 참조하고 콘텍스트의 변경을 내포하는 각각의 트랜잭션에서의 상태를 업데이트할 필요가 있다. 콘텍스트와 관련된 데이터는 다음과 같이 구조화된다:

분산된 PNR 콘텍스트 동기화에 관련된 모든 플랫폼은 동일 애플리케이션 유형(여기서는 "SBR"로 명명) 하에 DCX에 저장된 그들 콘텍스트 키를 가질 것이다.

필드 "Platform"은 TPF 또는 RES 개방형 시스템과 같이 시스템을 설계하는데 흔히 사용되는 3-문자 두문자에 대응한다. 필드 "Context Version"은 연관된 플랫폼 상에 존재하는 콘텍스트의 버전에 대응하고, 이것은 콘텍스트가 수정될 때마다 증가되는 수이다. 응용 콘텍스트 키라고도 지칭되는 필드 "Context Key"는 연관된 플랫폼 상에서 콘텍스트의 검색을 가능하게 하는 고유의 식별자에 대응한다. 필드 "Context State"는 연관된 플랫폼상의 콘텍스트의 상태에 대응한다. 콘텍스트 상태는 콘텍스트가 활성, 휴지, 손상된(corrupted) 사실 및 이것이 최후에 업데이트된 콘텍스트였는지를 표현할 수 있다. TPF 상에서 1 유스-케이스가 프로세싱되고 그 후 RES OBE(OPEN BACK END) 상에서 1 유스-케이스가 프로세싱된 후에, DCX에서의 애플리케이션 키의 예는 다음과 같을 수 있다:

로컬 콘텍스트의 버전화는 알고리즘에 대한 다음 절에서 알게 될 것인 바와 같이 느릿한 동기화 메커니즘(필요시에만 수행됨)을 구현하는데 있어서 핵심이다. "최후 업데이터"의 지시자 또한 어느 플랫폼이 최신 콘텍스트를 갖는지 결정하여 이 플랫폼과 동기화가 이루어지도록 하는데 있어서 핵심이다. 모든 메시지 상의 DCX 개체 내부에 운반되는 분산된 PNR 콘텍스트의 현재 상태에 더하여, 각각의 플랫폼은 그 콘텍스트에 연관되어 저장된 로컬 동기화 상태를 갖는다. 이러한 로컬 동기화 상태는 최후에 수행된 동기화 시에 다른 플랫폼상의 분산된 PNR 콘텍스트의 상태를 표현한다. 이것에 의하면, 로컬 콘텍스트가 다른 플랫폼에 비해 구식이 되어 있어 동기화를 위한 트리거링 조건인지 결정할 수 있다. 참으로, 하나의 바로 그 콘텍스트 상에서 수 개의 연속하는 업데이트가 행하여졌으면, 다른 플랫폼 콘텍스트에 비해 로컬 콘텍스트가 최신일 것이므로, 동기화는 매번 수행되지는 않을 것이다.

상기 데이터 구조는 가능한 대안 중 하나이지만, 동일한 공유 파라미터의 여러 다른 인스턴스의 일관성을 보장하도록 다른 구현이 실현될 수 있다. 그러한 데이터 구조의 요건은 시스템에 의해 사용되는 모든 플랫폼의 전체에 걸쳐 모든 애플리케이션간 PNR의 가장 최신 버전의 위치에 대한 정보가 공유될 수 있는 것이다.

도 3에 도시된 바와 같이, 동기화 파트에 대해 공유 콘텍스트(현재의 예에서는 DCX)에서의 응용 키 상에 행해진 수정의 글로벌 흐름이 2개의 플랫폼 소위 시스템1과 시스템2(하나는 메인프레임 상에서 실행되고 하나는 개방형 시스템 상에서 실행)의 예를 취하여 설명된다. 도 3의 도해에 있어서, 공유 콘텍스트에서 값의 연관된 변경과 여러 다른 플랫폼상의 유스-케이스의 프로세싱이 설명되고 있다. 공유 콘텍스트에서 운반된 현재의 상태 및 여러 다른 플랫폼의 로컬 동기화 상태는 그들 사이의 차이를 보여주도록 도면에서 표현되어 있다.

제1 단계(도 3에서의 단계 1)에 있어서, 사용자는 ESB를 거쳐 시스템에 로그인할 것이다; 이 스테이지에서는 사용자의 세션에 대해 비어 있는 공유 콘텍스트가 생성되어 ESB 상에 저장될 것이다(단계 2). 그 후, 사용자는 작업을 시작하여, 시스템1 상에 위치하는 서비스에 의해 취급될 비즈니스 질의를 보낸다(단계 3). ESB는 사용자 질의와 공유 콘텍스트를 시스템1에 자동으로 운반할 것이다. 시스템1이 로컬로도 공유 콘텍스트로도 동기화 정보를 찾아내지 못할 때, 이것은 수신된 사용자 질의를 직접 프로세싱한다(단계 4). 예약 콘텍스트가 질의 프로세싱에 의해 생성되었던 경우에, 시스템1이 버전1로 예약 콘텍스트를 입수하였고 그에 대한 최후 업데이터였다는 것인 신규 상태로 로컬 동기화 데이터가 업데이트된다(단계 5). 비즈니스 회답이 동기화 데이터로 업데이트된 공유 콘텍스트와 함께 그 후 사용자에게 되돌려 보내진다; 공유 콘텍스트는 사용자에 의해 수행되는 다음의 질의 상에서 사용될 수 있도록 사용자에게 회답을 포워딩하기 전에 ESB 상에 저장된다(단계 6). 사용자는 시스템2 상에 위치하는 서비스에 의해 취급될 또 다른 비즈니스 질의를 이후에 보낸다(단계 7). ESB는 사용자 질의와 공유 콘텍스트를 시스템2에 자동으로 운반할 것이다. 시스템2 상에는 저장된 로컬 동기화 상태가 없고, 질의와 수신된 공유 콘텍스트에 존재하는 동기화 데이터와의 비교는 시스템1이 신규 예약 콘텍스트를 보유할 때 시스템1과의 동기화가 필요하다는 것을 나타낸다(단계 8). 그래서 시스템2는 시스템1에 그 예약 콘텍스트를 요구하여(단계 9) 이를 로컬 저장하고 사용자 질의 프로세싱을 허용할 것이다(단계 10). 예약 콘텍스트의 저장과 함께, 로컬 동기화 상태는 상황을 표현하는 여러 다른 응용 키로 초기화된다. 그 후 질의 프로세싱이 일어난다(단계 11). 완료되고 나면, 예약 콘텍스트가 업데이트된 경우에, 시스템2가 이제 예약 정보의 최후 업데이터이고 그 콘텍스트가 이제 버전1을 갖는다는 사실을 표현하도록 로컬 동기화가 업데이트된다(단계 12). 비즈니스 회답은 동기화 데이터로 업데이트된 공유 콘텍스트와 함께 사용자에게 되돌려 보내진다; 공유 콘텍스트는 이것이 사용자에 의해 수행된 다음 질의 상에서 사용될 수 있도록 회답을 사용자에게 포워딩하기 전에 ESB 상에 저장된다(단계 13). 이는 차별 없이 시스템1 또는 시스템2 중 어느 것을 겨냥하여 사용자로부터의 후속의 질의와 액션의 동일 시퀀스로 계속할 수 있다. 로컬 동기화 상태 및 공유 콘텍스트의 비교에 의존하여, 시스템은 동기화가 필요한지 아닌지 결정할 것이다.

예를 들어 시스템1 플랫폼 상에서, 읽기 또는 쓰기 모드에서 예약 콘텍스트(예컨대, PNR)을 사용하는 서비스가 호출될 때, 또 다른 시스템과의 동기화가 필요한지 아닌지 결정하도록 다음의 알고리즘이 적용될 것이다.

0 - 요청을 수신

1 - 사용자 요청 상에서 수신된 현재의 공유 콘텍스트에서 애플리케이션 키를 입수(예를 들어 시스템1 v1/시스템2 v2 최후)

2 - 로컬 저장된 이전의 동기화 상태를 입수(예를 들어 시스템1 v1/시스템2 v1 최후)

3 - 일관성 체크 실행:

3a - 현재의 시스템1 버전이 로컬 저장된 이전 것과 동일한가? 키가 동일한가? (예이면 오케이)

3b - 현재의 시스템2 버전이 로컬 저장된 이전 것보다 더 크거나 같은가? (예이면 오케이)

4 - 동기화 체크 실행: 현재의 시스템2 버전이 로컬 저장된 것보다 더 크고 "최후 업데이터" 플래그가 있는가? (예이면 동기화 필요)

5 - 동기화가 필요하면

5a - 동기화를 실행 (시스템2 플랫폼으로부터 콘텍스트를 입수)

5b - 성공적이면, 시스템1은 로컬 저장된 이전 동기화 상태를 값으로 업데이트: 시스템1 v1/시스템2 v2 (이것은 이제 시스템1 상에서 콘텍스트가 시스템2 v2와 동기화된다는 것을 의미한다)

6 - 시스템1 상에서 비즈니스 질의를 프로세싱

7 - 예약(PNR) 콘텍스트 상에 수정이 행해지면 시스템1 버전을 업데이트

7a - 현재의 공유 콘텍스트에서의 시스템1 버전을 업데이트(시스템1 v2 최후/시스템2 v2). 이러한 공유 콘텍스트는 이것을 다음의 사용자 질의를 위해 보관하도록 ESB에 되돌려 보내질 것이다

7b - 로컬 저장된 이전 동기화 상태에서의 시스템1 버전을 값으로 업데이트: 시스템1 v2/시스템2 v2

8 - 응답

이러한 알고리즘에 있어서는, 동기화 관점으로부터 무엇이 행해져야 하는지 결정할 수 있도록 콘텍스트 키의 2세트를 비교할 필요가 있음을 알 수 있다. 콘텍스트의 최신 버전을 갖는 것을 결정하기 위해, 2개보다 많은 플랫폼이 PNR 콘텍스트를 가질 때 "최후 업데이터" 플래그가 필요하다. 2개의 플랫폼에 대해서는, 메커니즘은 그것 없이 작동할 수 있다. 이러한 메커니즘의 하나의 부가적 이점은 다음 동기화 단계에서 공유 콘텍스트 송신 에러를 검출할 수 있다는 것이다. 참으로, 일관성 체크 및 로컬 저장된 동기화 정보 덕분에, 에러가 발생했는지 결정하는 것이 가능하다. 로컬 플랫폼의 버전이 매칭하지 않거나 콘텍스트 키가 서로 다르다는 사실은 공유 콘텍스트 컨텐트의 손상을 나타내고 이것은 에러의 결과로 될 가능성이 있다. 통신 및 부대 교환 때문에 에러 취급은 꽤 복잡할 수 있고, 그래서 여기에서는 상술하지 않을 것이지만, 당업자라면 이러한 태스크를 구현하도록 수 개의 최첨단 방법이 사용될 수 있음을 인식할 것이다.

도 4를 참조하면, 시스템의 범용 컴퓨터(예컨대, 어느 컴퓨터, 예약 서버, TPF 메인프레임, 개방형 시스템 서버, 데이터베이스 관리 서브시스템, 라우터, 네트워크 서버)가 (450)으로 표시되어 있다. 컴퓨터(450)는 시스템 버스(453)에 병렬로 접속되어 있는 수 개의 유닛에 의해 형성되어 있다. 상세하게는, 하나 이상의 마이크로프로세서(456)는 컴퓨터(450)의 동작을 제어한다; RAM(459)은 마이크로프로세서(456)에 의해 작업 메모리로 직접 사용되고, ROM(462)은 컴퓨터(450)의 부트스트랩을 위한 기본 코드를 저장한다. 주변 유닛은 (각자의 인터페이스에 의해) 로컬 버스(465) 주위로 클러스터링되어 있다. 구체적으로, 대용량 메모리는 CD-ROM(474)을 읽기 위한 드라이브(471) 및 하드-디스크(468)로 이루어진다. 게다가, 컴퓨터(450)는 입력 디바이스(477)(예컨대, 키보드 및 마우스), 및 출력 디바이스(480)(예컨대, 모니터 및 프린터)를 포함한다. 네트워크 인터페이스 카드(483)는 컴퓨터(450)를 네트워크에 접속하도록 사용된다. 브리지 유닛(486)은 로컬 버스(465)와 시스템 버스(453)를 인터페이싱한다. 각각의 마이크로프로세서(456) 및 브리지 유닛(486)은 정보 송신을 위해 시스템 버스(453)로의 액세스를 요청하는 마스터 에이전트로서 동작할 수 있다. 아비터(arbiter)(489)는 시스템 버스(453)로의 상호 배타와 액세스의 승인을 관리한다. 시스템이 다른 토폴로지를 갖거나 다른 네트워크에 기반하면, 유사한 고려가 적용된다. 대안으로, 컴퓨터는 여러 다른 구조를 갖거나, 균등한 유닛을 포함하거나, (PDA, 모바일 폰 등과 같이) 다른 데이터 프로세싱 개체로 이루어진다.

PNR 콘텍스트 동기화 메커니즘 및 PNR 데이터 수송에 있어서 사용되는 EDIFACT 서비스는 다음의 정보로 이루어진다.

- PNR 콘텍스트 데이터를 요청 또는 제공하는 플랫폼의 로컬 동기화 상태. 이러한 정보는 로컬 콘텍스트 상에서 검색 및 적용되어야 하는 사용자 트랜잭션의 수를 결정하는데 필요하다. 이것은 또한 최적화가 플랫폼 사이에 교환되는 데이터량을 줄일 수 있게 한다.

- 첫 동기화의 경우에 완전할 수 있거나 또는 콘텍스트의 최신 버전을 요청하는 플랫폼이 이미 로컬 콘텍스트 복사본을 가졌을 때 콘텍스트 업데이트로 이루어질 수 있는 직렬화된 PNR 콘텍스트. 직렬화된 콘텍스트는 EDI 메시지 자체인 PASBCQ이다.

콘텍스트가 EDI 메시지로 직렬화된다는 사실은 이를 제공하는 플랫폼의 데이터 표현 특수성을 제거할 수 있게 한다. 참으로, 데이터 컨텐트는 표준화되고 플랫폼 데이터 표현으로부터 독립적이다.

분산된 콘텍스트 동기화는 플랫폼 TPF 및 OBE 둘 다에서 구현되거나 마스터/슬레이브 플랫폼에 특정될 수 있는 5개의 서로 다른 서비스에 기반한다. 각각의 서비스는, 특히 DCX는 일관성 체크가 콘텍스트 동기화의 상태 상에서 실행될 수 있게 할 것이기 때문에, 메시지와 함께 DCX를 운반할 것이다. 각각의 서비스는 여기에서는 교환된 데이터를 보여주도록 유스 케이스 도해 및 EDIFACT 구조(요청 및 응답)를 참조하여 설명된다.

GET context : PCSGRQ /R

도 5a 및 도 5b에 도시된 바와 같이 이 서비스는 원격 플랫폼으로부터 그 콘텍스트의 최신 버전을 검색하는데 사용된다. 이는 콘텍스트가 읽혀질 수 있는 모든 플랫폼 상에서 구현되어야 한다.

데이터 교환

질의 상에서, 클라이언트는 그 동기화 상태를 부여해야 한다. 이것은 3개 값의 리스트<Platform, Context Key, Version>로 이루어진다.

회답 상에서, 서버는 그 버전과 직렬화된 콘텍스트에 연관된 그 동기화 상태를 부여해야 한다. 에러와 마주칠 수 있으므로, 회답은 문제를 기술하는 에러 그룹을 포함하여야 한다.

GET context serialization versions PCSVRQ /R

도 6a 및 도 6b에 도시된 이 서비스는 콘텍스트의 직렬화에 관련된 모든 버전을 검색하는데 사용된다. 이 서비스는 OBE 상에서 구현되어야 한다. OBE 상에서, 콘텍스트는 소위 PASBCQ라는 EDIFACT 메시지로 직렬화되는 SBR 모델에 기반한다. PASBCQ는 연관된 버전을 갖는 수 개의 블롭(blob)으로 이루어진다. TPF는 PASBCQ의 버전의 마스터이므로, OBE는, 일관된 메시지를 쓸 수 있기 위해, 현재의 직렬화 버전을 이미 알고 있지 않을 때 그들을 TPF로부터 검색해야 한다. 이러한 상황은 외부 시스템이 청하지 않은 업데이트를 OBE 상에 직접 요청하고 있을 때 일어난다.

데이터 교환

질의 상에서, 클라이언트는 어떠한 데이터도 제공할 필요가 없어야 한다.

회답 상에서, 서버는 PASBCQ EDIFACT 메시지를 직렬화하는데 사용된 그 버전을 부여해야 한다. 이것은, 블롭 버전과 함께, 직렬화하는데 사용된 모든 버전을 포함하는 블롭으로 이루어져야 한다. 에러와 마주칠 수 있으므로, 회답은 문제를 기술하는 에러 그룹을 포함하여야 한다.

PUSH context : PCSPUQ /R

이 서비스(도 7a 및 도 7b 참조)는 후자 상에서 콘텍스트를 업데이트하기 위해 로컬 콘텍스트의 최신 버전을 원격 플랫폼에 푸싱하는데 사용된다. 이것은 콘텍스트의 마스터가 아닌 플랫폼 상에서 구현되어야 한다. 이 서비스는 콘텍스트의 마스터가 최신이게 하는 동기화 메커니즘의 최적화이다. 이 경우에 있어서, 마스터는 GET context 서비스를 사용하지 않을 것이다. TPF 상에서 클라이언트 호출은 비용이 들기 때문에, 이것은 그에 대한 자원 소비를 줄이도록 도울 수 있다.

데이터 교환

질의 상에서, 클라이언트는 그 버전과 직렬화된 콘텍스트에 연관된 그 동기화 상태를 제공하여야 한다.

회답 상에서, 서버는 확인응답만을 제공하여야 한다. 에러와 마주칠 수 있으므로, 회답은 문제를 기술하는 에러 그룹을 포함하여야 한다.

PUSH & EOT context : PCSEUQ /R

이 서비스(도 8a 및 도 8b)는 후자 상에서 콘텍스트를 업데이트하기 위해 로컬 콘텍스트의 최신 버전을 원격 플랫폼에 푸싱하고 이 콘텍스트 상에서 엔드 오브 트랜잭션 프로세스를 호출하는데 사용된다. 이것은 PNR 콘텍스트를 업데이트하는 것 및 이들 수정 상에서 엔드 오브 트랜잭션 프로세스를 호출하는 것을 필요로 하는 모든 플랫폼 상에서 구현되어야 한다. 이 서비스는 외부 시스템으로부터 오는 티켓 확인응답 또는 티켓 프린트 요청(TTP)과 같은 프로세싱 엔트리를 관리하는데 필요하다.

데이터 교환

질의 상에서, 클라이언트는 그 버전과 함께 직렬화된 콘텍스트에 연관된 그 동기화 상태를 제공하여야 한다.

IGNORE context propagation : PCSINQ /R

이 서비스는 플로우에 관련된 여러 다른 플랫폼에 걸쳐 SBR 상에서 이루어졌던 모든 수정을 무시하는데 사용된다. TPF는 "IG" 엔트리를 수신할 것이고, 그 후 DCX에서 등록된 SBR 콘텍스트를 갖는 OBE들에 질의를 전파할 것이므로, 그들은 그들의 콘텍스트를 클리닝할 수 있다. 이것은 도 9a 및 도 9b에 도시되어 있다.

데이터 교환

위에서 설명된 방법은 또한 도 10에 도시된 도해에 표현되어 있다. 그 방법은, 다중-서버 시스템의 적어도 2개의 서버에 걸쳐 사용자 트랜잭션 동안 가장 최신 PNR 레코드가 사용되는 것을 보장하도록, 다중-서버 시스템 상에서 동작하는 예약 방법에 있어서 동기화 메커니즘을 실현하는데, PNR의 로컬 콘텍스트 버전은 다중 서버 시스템의 각각의 서버 내에 유지되고, 서버는 시스템 버스를 통해 상호접속되어 있다. 그 방법은 흑색원(1001)에서 시작하고 그 후 트랜잭션에 관련된 모든 서버에 의해 액세스가능한 저장 구역에서 PNR의 가장 최신 버전이 유지되는 박스(1003)로 진행한다. PNR의 업데이트 액션을 필요로 하는 사용자 요청이 다중-서버 예약 시스템에 의해 예컨대 서버 "A"에서 수신된다(단계(1005)). 시스템 버스(예컨대, ESB, 그러나 더 일반적으로는 어느 라우팅 수단)는 요청을 프로세싱하기 위해 어느 서버가 관련될 필요가 있는지 결정 및 선택한다. 단계(1007) 및 단계(1009)에서는 ESB상의 공유 콘텍스트 PNR 상에서 이용가능한 정보와 로컬 콘텍스트 PNR을 비교함으로써 로컬 콘텍스트 PNR이 가장 최신인지를 선택된 서버가 체크한다: 로컬 콘텍스트 PNR이 가장 최신이 아니면(즉, (있다면) 선택된 서버에 의한 최후 업데이트 이후 또 다른 서버가 PNR을 수정하였다) 선택된 서버는 PNR의 최신 버전을 획득한다(단계(1011)). 그 후 선택된 서버는 요청된 활동을 수행하고 로컬 콘텍스트 PNR을 수정하여(단계(1013)) 또한 최신 버전으로 된다: 그 후 그러한 정보는 다중-서버 시스템의 모든 다른 서버에 이용가능하게 되도록 ESB상의 공유 콘텍스트 PNR에 넘겨진다(단계(1015)). 서버, ESB 및 사용자 사이의 정보가 송신되는 방식의 상세는 이전의 문단에서 논의되었다.

개시의 범위로부터 벗어남이 없이 개조 및 수정이 상기한 것에 대해 이루어질 수 있음을 인식할 것이다. 당연히, 로컬 및 특정 요건을 만족시키기 위해, 당업자라면 위에서 설명된 솔루션에 많은 수정 및 개조를 적용할 수 있다. 특히, 본 발명이 바람직한 실시예를 참조하여 어느 정도 구체적으로 설명되었지만, 형태 및 상세에 있어서 다양한 생략, 대체 및 변경과 더불어 다른 실시예도 가능함을 이해하여야 한다; 더욱, 명시적으로, 본 발명의 어느 개시된 실시예와 연결하여 설명된 특정 엘리먼트 및/또는 방법 단계는 설계 선택의 일반적 사항으로서 어느 다른 실시예에 편입될 수도 있음이 의도된다.

(본 발명의 각각의 실시예를 구현하는데 사용될 수 있는) 프로그램이 여러 다른 방식으로 구조화되면, 또는 부가적 모듈 또는 기능이 제공되면 유사한 고려가 적용된다; 마찬가지로, 메모리 구조는 다른 유형일 수도 있고, 또는 균등한 개체(반드시 물리적 저장 매체로 구성되는 것은 아님)로 대체될 수도 있다. 더욱, 제안된 솔루션은 (다른 순서로라도, 유사한 또는 부가적 단계를 갖는) 균등한 방법으로 구현되는데 적합하다. 어떠한 경우에라도, 프로그램은 외부 또는 거주 소프트웨어, 펌웨어 또는 마이크로코드(객체 코드로든 소스 코드로든)와 같이 어떠한 데이터 프로세싱 시스템과도 연결되어 또는 그에 의해 사용되기에 적합한 어떠한 형태라도 취할 수 있다. 더욱, 프로그램은 어떠한 컴퓨터-사용가능한 매체 상에라도 제공될 수 있다; 매체는 프로그램을 포함하거나, 저장하거나, 통신하거나, 전파하거나, 또는 전송하기에 적합한 어떠한 엘리먼트라도 될 수 있다. 그러한 매체의 예는 (프로그램이 사전-로딩될 수 있는) 고정 디스크, 제거가능한 디스크, 테이프, 카드, 와이어, 파이버, 무선 접속, 네트워크, 브로드캐스트 웨이브 등이다; 예컨대, 매체는 전자, 자기, 광학, 전자기, 적외선, 또는 반도체 유형일 수 있다.

어떠한 경우라도, 본 발명에 따른 솔루션은 (예컨대, 반도체 재료의 칩에 집적된) 하드웨어 구조로 또는 소프트웨어와 하드웨어의 조합으로 수행되는데 적합하다.

Claims

다중-서버 시스템 상에서 동작하는 예약 방법에서, 상기 다중-서버 시스템의 적어도 2개의 서버에 걸쳐 사용자 트랜잭션(user transaction) 동안 가장 최신 PNR 레코드가 사용되는 것을 보장하기 위한 동기화 메커니즘으로서, PNR의 로컬 콘텍스트 버전은 상기 다중-서버 시스템의 각각의 서버 내에 유지되고, 상기 서버는 라우팅 수단을 통해 상호접속되어 있고, 상기 메커니즘은
- 상기 다중-서버 시스템의 모든 서버에 의해 액세스가능한 공유 콘텍스트 저장 구역에, PNR의 최후 수정 버전 상의 정보를 유지하는 단계; 및
- 서버들 중 선택된 하나가 상기 PNR의 로컬 콘텍스트 버전을 수정시키도록 하는 사용자 요청에 응답하여, 다음의 액션들:
- 어느 서버가 상기 PNR을 최후에 수정하였는지 상기 공유 콘텍스트 저장 구역 상에서 체크하는 액션;
- 상기 PNR을 최후에 수정한 서버가 상기 선택된 서버와 다르면, 상기 PNR의 최신 버전을 획득하는 액션;
- 상기 사용자 요청을 충족하도록 상기 PNR의 로컬 콘텍스트 버전을 수정하는 액션; 및
- 상기 PNR의 최후 수정 버전을 반영하도록 상기 공유 콘텍스트 저장 구역을 업데이트하는 액션을 수행하는 단계를 포함하는 것인 동기화 메커니즘.
제1항에 있어서, 상기 다중-서버 시스템의 상기 서버는 서비스 지향 아키텍처(Service Oriented Architecture: SOA) 시스템에 의해 상기 라우팅 수단 및 사용자와 정보를 교환하는 것인 동기화 메커니즘.
제2항에 있어서, 메시지는 상기 PNR의 최후 수정 버전 상의 정보를 포함하는 메시지 헤더를 포함하는 것인 동기화 메커니즘.
제1항 내지 제3항 중 어느 한 항에 있어서, 상기 PNR의 최후 수정 버전 상의 정보는 상기 PNR의 최후 수정 버전의 위치를 포함하는 것인 동기화 메커니즘.
제1항 내지 제4항 중 어느 한 항에 있어서, 상기 PNR의 최후 수정 버전 상의 정보는 상기 PNR의 최후 수정 버전으로의 포인터를 포함하는 것인 동기화 메커니즘.
제1항 내지 제5항 중 어느 한 항에 있어서, 상기 라우팅 수단은 시스템 버스, 예컨대, 엔터프라이즈 서비스 버스(Enterprise Service Bus: ESB)를 포함하는 것인 동기화 메커니즘.
컴퓨터 프로그램으로서, 상기 컴퓨터 프로그램이 컴퓨터 상에서 실행될 때, 제1항 내지 제6항 중 어느 한 항에 따른 방법의 단계를 수행하기 위한 명령어를 포함하는 컴퓨터 프로그램.
제7항의 상기 컴퓨터 프로그램을 구체화하는 컴퓨터로 읽을 수 있는 수단을 포함하는 컴퓨터 프로그램 제품.
예약 다중-서버 데이터 프로세싱 시스템으로서, 상기 다중-서버 시스템의 적어도 2개의 서버에 걸쳐 사용자 트랜잭션 동안 가장 최신 PNR 레코드가 사용되는 것을 보장하기 위한 동기화 메커니즘을 포함하되, 상기 PNR의 로컬 콘텍스트 버전은 상기 다중-서버 시스템의 각각의 서버 내에 유지되고, 상기 서버는 라우팅 수단을 통해 상호접속되어 있으며, 상기 시스템은 제1항 내지 제6항 중 어느 한 항의 방법을 수행하도록 적응된 하나 이상의 컴포넌트를 포함하는 것인 예약 다중-서버 데이터 프로세싱 시스템.
제1항 내지 제6항 중 어느 한 항의 방법을 구현하기 위해 데이터 프로세싱 시스템에 배치된 서비스.