KR102362676B1 - 컴퓨터 시스템 - Google Patents

Abstract

프로세서, 프로세서가 액세스가능한 메모리 및 컴퓨터 스토리지를 포함하는 컴퓨터 시스템에 의해 서비스가 전달된다. 메모리는 서비스 객체 클래스를 정의하는 코드를 유지한다. 서비스 객체 클래스는 서비스 함수를 제공하도록 구성되고, 서비스 객체 클래스는, 서비스 함수를 구현하는 서비스 객체를 생성하도록 인스턴스화된다. 각각의 서비스 객체에 대해, 그 서비스 객체를 임의의 다른 서비스 객체와 구별하는 관련 서비스 객체 식별자가 메모리에서 생성된다. 서비스 객체는 직렬화되어 직렬화된 데이터를 생성하는데, 직렬화된 데이터는 각각의 서비스 객체의 표현을 포함하고, 표현은 서비스 객체의 서비스 객체 식별자, 그 서비스 객체의 관련 상태 데이터 및 그 서비스 객체에 의해 참조되는 임의의 다른 서비스 객체의 서비스 객체 식별자를 포함한다. 비활성화에 후속하여, 서비스 객체는 참조의 체인을 따른 것에 의해 재생성될 수 있다.

Description

컴퓨터 시스템{COMPUTER SYSTEM}

종래의 통신 시스템은, 퍼스널 컴퓨터 또는 모바일 디바이스와 같은 클라이언트 디바이스(엔드포인트)의 유저가 인터넷(Internet)과 같은 패킷 기반 컴퓨터 네트워크를 통해 하나 이상의 다른 엔드포인트와 음성 또는 비디오 호(call)를 행하는 것을 허용한다. 때때로, 엔드포인트에 의한 호 데이터(call data)의 통신은 엔드포인트가 합의된 통신 프로토콜을 준수하는 것에 의해 달성된다. 이것의 한 예는 세션 개시 프로토콜(Session Initiation Protocol; SIP)이다. 넓은 의미에서, SIP는 엔드포인트 대 엔드포인트 요청 응답 기반의 트랜잭션 패러다임에 따라 호가 협상되어야 한다고 지시하며, 이 패러다임에서는, SIP 유저 에이전트가 다른 엔드포인트의 다른 유저 에이전트에게 일련의 요청 메시지를 송신하고 그 응답으로 각각의 응답 메시지를 수신하는 것에 의해, (다른 것들 중에서도) 호가 초기의 비접속 상태로부터 엔드포인트 사이에서 실시간의 미디어가 흐를 수 있는 상태로 진행되고, 호의 유지 및 최종 종료도 유사한 방식으로 달성된다. 각각의 유저 에이전트는 호의 지속 기간 동안 현재 호 상태를 추적하는데 사용되는 상태 머신을 유지할 수도 있다. 상태 머신은 두드러진(salient) 요청의 송신 및 두드러진 응답의 수신시 적절하게 업데이트된다.

이 개요는 하기의 상세한 설명에서 더 설명되는 엄선된 개념을 간소화된 형태로 소개하기 위해 제공된다. 이 개요는 청구된 주제의 주요 피쳐 또는 본질적인 피쳐를 식별하도록 의도된 것이 아니며, 청구된 주제의 범위를 제한하는데 사용되도록 의도된 것도 아니다.

서비스를 전달하기 위한 방법이 개시되는데, 방법은, 프로세서, 프로세서가 액세스가능한 메모리 및 컴퓨터 스토리지를 포함하는 컴퓨터 시스템에 의해 구현된다. 메모리는 서비스 객체 클래스를 정의하는 코드를 유지한다. 서비스 객체 클래스는 서비스 함수를 제공하도록 구성된다. 방법은 다음 단계를 포함한다. 적어도 하나 이상의 서비스 실시 유도 메시지(service instigation message)가 수신된다. 적어도 하나의 서비스 실시 유도 메시지에 응답하여, 서비스 객체 클래스는 서비스 객체를 생성하도록 인스턴스화된다. 서비스 객체는 서비스를 전달하기 위해 서비스 함수를 구현한다. 각각의 서비스 객체는 메모리에 유지되는 관련 상태 데이터(associated state data)를 가지며, 서비스 객체 중 적어도 일부는 다른 서비스 객체를 참조한다. 각각의 서비스 객체에 대해, 그 서비스 객체를 임의의 다른 서비스 객체와 구별하는 관련 서비스 객체 식별자가 메모리에서 생성된다. 서비스 객체는 직렬화되어 직렬화된 데이터를 생성하는데, 직렬화된 데이터는 각각의 서비스 객체의 표현을 포함하고, 표현은 서비스 객체의 서비스 객체 식별자, 그 서비스 객체의 관련 상태 데이터 및 그 서비스 객체에 의해 참조되는 임의의 다른 서비스 객체의 서비스 객체 식별자를 포함한다. 직렬화된 데이터는 컴퓨터 스토리지에 저장된다. 서비스 객체가 비활성화되면, 재활성화될 서비스 객체를 식별하는 서비스 재활성화 메시지가 수신되고, 식별된 서비스 객체에 대해 재활성화 프로세스가 수행된다. 재활성화 프로세스는: 식별된 서비스 객체를 직렬화된 데이터 내에서의 그것의 표현으로부터 재활성화하는 것, 및 식별된 서비스 객체가, 서비스 함수를 구현하는데 필요로 되는 적어도 하나의 서비스 객체를 참조하는 경우, 참조된 적어도 하나의 서비스 객체에 대해 재활성화 프로세스를 반복하고, 그에 의해 비활성화된 서비스 객체의 적어도 일부를 대체하기 위한 서비스 객체의 대체 세트를 생성하는 것을 포함한다.

도 1은 클라우드 플랫폼의 개략적인 개요이다.
도 2는 통신 시스템의 개략적인 예시이다;
도 3은 유저 디바이스의 개략적인 예시이다;
도 4a는 데이터 센터의 개략적인 예시이다;
도 4b는 데이터 센터의 서버의 개략적인 예시이다;
도 5a 및 도 5b는 계층적 통신 시스템 아키텍처의 원리를 개략적으로 예시한다;
도 6은 특정한 구성의 통신 시스템을 도시한다;
도 7은 호 확립 프로시져의 개략적인 개요이다;
도 8a는 호 확립 프로시져를 위한 시그널링 도면이다.
도 8b는 호가 어떻게 종료될 수도 있는지를 나타내는 시그널링 도면이다.
도 8c는 호가 어떻게 지향될(directed) 수도 있는지를 나타내는 시그널링 도면이다.
도 8d는 호출자(caller)에 의해 호가 어떻게 취소될 수도 있는지를 나타내는 시그널링 도면이다.
도 9는 호 컨트롤러 배치(deployment)에 의해 저장된 URI 맵핑 세트의 개략적인 예시이다.
도 10은, URI 재작성 프로시져를 각각 구현하는 호 컨트롤러 배치의 체인의 개략적인 예시이다;
도 11a는 객체(object) 그래프(예를 들면, 호 상태)를 형성하는 서비스 객체의 개략적인 예시이고, 도 11b는 그래프가 메모리에서 어떻게 실현될 수도 있는지의 예이다;
도 12a는 객체 그래프(예를 들면, 호 상태)를 형성하는 지속된 객체(persisted object) 및 참조 객체의 개략적인 예시이고, 도 12b는 그래프가 메모리에서 어떻게 실현될 수도 있는지의 예이다;
도 13은 직렬화(serialization) 프로세스에 대한 플로우차트이다;
도 14는 직렬화 해제(deserialization) 프로세스에 대한 플로우차트이다;
도 15는 호 내(in-call) 서비스 요청을 달성하는 방법에 대한 플로우차트이다;
도 16은 예시적인 활성 호 상태를 개략적으로 예시한다.

네트워크의 엔드포인트 사이에서 호(예를 들면, 오디오 호(audio call), 오디오 및 비디오(AV) 호 등)와 같은 실시간 미디어 통신 이벤트를 설정할 때, 당사자(party)끼리 서로 호출하도록 허용되는지 여부, 사용할 오디오 및 비디오 코덱, 한쪽 당사자로부터 다른 쪽 당사자로 미디어 패킷을 라우팅하는 방법 등을 포함하는 다수의 요인과 변수를 고려하여 다수의 결정이 이루어져야 한다. 하기에 설명되는 실시형태는, "클라우드 플랫폼" 또는 간단히 "클라우드"로 달리 칭해지는 "분산형 플랫폼"내에서부터의 실시간 미디어 통신 이벤트의 중앙 집중형(엔드포인트 기반의 것과 대조적임) 제어를 제공한다. 즉, 호는 클라우드 상에서 실행되는 다양한 중앙 컨트롤러에 의해 제어된다.

클라우드는 네트워크(예를 들면, 인터넷)를 통해 액세스 가능한 컴퓨팅 플랫폼을 의미하는데, 컴퓨팅 플랫폼은 다수의 네트워크화된 컴퓨터 디바이스 및 그 위에서 실행하는 시스템 소프트웨어로 구성되는 분산형 컴퓨터 시스템을 포함하고, 컴퓨터 시스템은 물리적 컴퓨팅 리소스 - 예컨대 물리적 프로세싱 리소스 및 휘발성 및/또는 불휘발성의 물리적 메모리/스토리지 리소스 - 의 (잠재적으로 매우 큰) 풀(pool)을 제공하고, 시스템 소프트웨어는, 다수의 독립적인 가상 머신(virtual machine; VM), 즉, 컴퓨터 시스템의 소프트웨어 시뮬레이션을 구현하는 것에 의해 이 기저의(underlying) 물리적 리소스 풀을 분할하도록 구성된다. 클라우드 공급자의 예는 Windows Azure(TM), Amazon Web Services(TM) 등을 포함한다.

물리적 컴퓨터 리소스의 풀링(pooling) 및 가상화를 통한 그 풀의 분할은, '가상' 리소스 - 즉 각각의 가상 컴퓨터 시스템 내에서 실제로 보이는 리소스로부터의 물리적 컴퓨터 리소스(예를 들면, 이용 가능한 물리적 프로세서 클럭 사이클 및 메모리의 물리적 비트)의 분리를 제공하는 가상화 레이어(플랫폼의 시스템 소프트웨어에 의해 실현됨)로 인해 하드웨어와 소프트웨어 고려 사항을 디커플링하도록 작용한다. 기저의 하드웨어의 물리적 리소스는 신규의 물리적 네트워크 컴퓨터 디바이스의 추가를 통해, 또는 현존하는 물리적 네트워크화된 컴퓨터의 업그레이드를 통해 보강될 수 있고 레거시 호환성 측면에서 고려해야 할 유일한 사항은, 업그레이드된 물리적 컴퓨터 시스템이 동일한 일반적 가상 머신을 여전히 실행할 수 있다는 것을 보장하는 것이다(즉, 이들 가상 머신 상에서 어떤 오퍼레이팅 시스템 또는 애플리케이션 코드가 실행될 것인지의 어떠한 고려도 없다). 마찬가지로, 시스템 설계자는, 물리적인 하드웨어 고려 사항(예컨대 물리적 서버 등의 주문, 배치 및 수용) 없이 클라우드 플랫폼 상에서의 구현을 위해, 시스템(어쩌면 많은 컴포넌트를 갖는 매우 복잡한 시스템)을 설계할 수 있고, 그와 관련하여 코드를 개발할 수 있다 - 시스템 설계자는 (기저의 하드웨어의 리소스 제한이 아닌) 가상 컴퓨터 시스템의 리소스 제한의 측면에서 컴퓨터 리소스의 소비만을 고려하기만 하면 되는데, 이들 가상 시스템의 리소스 제한은 잘 정의되어 있고 알려져 있다. 따라서, 시스템 설계자의 관점에서는, 컴퓨터 리소스 고려 사항은, 예를 들면, 얼마나 많은 클라우드 플랫폼의 가상 컴퓨터 시스템이 배치되어야 하는지의 고려 사항으로 축소되고; (시스템 설계자와는 상이할 수도 있는) 플랫폼 자체의 오퍼레이터의 관점에서는, 컴퓨터 리소스는, 예를 들면, 미리 정의된 리소스 할당을 갖는 필요로 되는 수의 가상 머신을 구현하는데 얼마나 많은 물리적 컴퓨터 시스템이 필요로 되는지의 고려 사항으로 축소된다.

예시적인 분산형 플랫폼(100)의 하이 레벨 개요가 도 1에서 도시된다. 예시적인 플랫폼은 분산형 컴퓨터 시스템(114)을 포함한다. 도 1의 컴퓨터 시스템(114)은 아주 많은 수의(예를 들면, 수만 개의) 네트워크 컴퓨터 디바이스로 구성된다 - 몇몇 상황에서는, 물리적 컴퓨팅 리소스가 유효하게 무제한인 것으로 충분히 풍부하게 간주될 수 있을 정도로 충분히 많다. 이들 컴퓨터 디바이스는 네트워크(201)(이것은 인터넷과 같은 패킷 기반 네트워크이다)와의 통신을 위해 구성되며, 전 세계적으로 분산된다(예를 들면, 다수의 국가 및/또는 대륙에 걸쳐 전개된다). 통상적으로, 이러한 컴퓨터 시스템의(예를 들면, 수천 개의 서버)의 그룹은 상이한 지리적 위치에서(즉, 한 국가의 상이한 지역, 상이한 국가, 상이한 대륙, 등에서) 각각의 데이터 센터(데이터센터)에 수용된다.

시스템 소프트웨어(112)는 분산형 컴퓨터 시스템(114)의 상에서 실행된다. 시스템 소프트웨어(12)는 독립적인 가상 머신(106, 110)의 두 개의 세트(104(런타임 세트) 및 108(스토리지 세트))를 구현하도록 구성된다.

런타임 세트(104)는, 애플리케이션 코드(134)의 실행을 위한 런타임 환경을 제공하는 다수의 VM(106)을 포함하는데, 애플리케이션 코드(134)는 그 가상 컴퓨터 시스템(106) 상에서 실행된다. 시스템 소프트웨어(112)는, 플랫폼(100)을 사용하고자 하는 소프트웨어 개발자가, 플랫폼(100) 상에서의 실행을 위해, 그들의 주문형 코드(bespoke code; 134)를 네트워크(201)를 통해 플랫폼(100)에 업로드하는 것을 가능하게 하도록 구성된다. 응답으로, 시스템 소프트웨어(812)는 이러한 런타임 환경을 생성하고 실행을 위해 신규로 생성된 런타임 환경에 코드(134)를 제공한다. 가상 시스템(106) 상에서의 이 코드(134)의 실행은, 시스템 소프트웨어가 그 환경에 할당되는 기저의 물리적 프로세싱 리소스 및 물리적 메모리 리소스(주로 물리적 휘발성 메모리에 의해 물리적 레벨에서 실현됨)에 대한 액세스를 중재하는 것에 의해 가능하게 된다.

스토리지 세트(108)는 데이터 스토리지를 제공하도록 구성되는 다수의 가상 머신(110)을 포함한다. 각각은, 예를 들면, 코드(134)가 컴퓨터 시스템(110)에 대한 적절한 함수를 호출하는 것에 의해 그 컴퓨터 시스템(110)에 할당되는 물리적 메모리 리소스(주로 물리적 불휘발성 메모리에 의해 물리적 레벨에서 실현됨)로의 또는 그 물리적 메모리 리소스로부터의 데이터 전송을 달성하는데 사용될 수 있는 대응하는 애플리케이션 프로그래밍 인터페이스(Application Programming Interface; API)(111)를 구비한다. 이 전달은 시스템 소프트웨어(112)에 의해 다시 중개된다.

실시형태는 다양한 타입의 컨트롤러를 구현하도록 구성되는 코드를 유지하는 컴퓨터 스토리지를 포함하는 시스템을 제공한다. 이들은 다음의 것을 포함한다:

1. 예를 들면, 2명 이상의 유저 사이에서 통신 이벤트, 예를 들면 호를 확립하기 위한, 그리고 참가자(participant)의 추가/제거, 미디어 모달리티(modality) 등의 추가/제거, 및 확립된 통신 이벤트의 종료와 같은 확립된 통신 이벤트의 하이 레벨 관리를 위한 하이 레벨 시그널링 기능을 핸들링하는 호 컨트롤러;

2. 확립된 통신 이벤트의 미디어 모달리티를 각각 관리하는 하나 이상의 미디어(모달리티) 컨트롤러; 미디어 모달리티 컨트롤러는, 예를 들면, 참가하고 있는 엔드포인트 사이에서 오버레이 네트워크 접속(예를 들면, 피어 투 피어 및/또는 중계식 접속)이 확립되는 방식을 제어하는 것에 의해, 호 컨트롤러의 제어 하에서, 실제 미디어 콘텐츠의 흐름을 제어한다; 미디어 모달리티는 오디오, 비디오, 화면 공유, 공유 화이트 보드 등을 포함한다. 일부 실시형태에서, 미디어 모달리티 서비스는 (3 명 이상의 유저 사이의) 그룹 호에 대해서만 전달된다.

컨트롤러의 인스턴스는 클라우드 플랫폼의 하나 이상의 VM 상에서 실행되는 애플리케이션 코드에 의해 구현된다.

즉, 호 컨트롤러(Call Controller; CC)는, 두 당사자간 호(two-party call)의 호 셋업 및 관리를 담당하는 서버 엔티티이며, 다자간(multi-party) 호 셋업 및 관리도 또한 돕는다.

호 에이전트(Call Agent: CA)는, 호 컨트롤러와 상호 작용하는 클라이언트 엔티티를 가리키기 위해 사용되는 용어이다.

0. 개관:

0.1 기저의 시스템 컴포넌트:

도 2는 통신 시스템(200)을 도시한다. 통신 시스템(200)은 네트워크(201)를 포함한다. 네트워크(200)에는, 제1 유저(302a)("Alice(앨리스)")와 관련되는 유저 디바이스(유저 디바이스 또는 클라이언트 디바이스라고도 칭해짐)(204a) 및 제2 유저(202b)("Bob(밥)")와 관련되는 다른 유저 디바이스(204b)가 접속된다. 유저 디바이스(204a, 204b)는 네트워크(201)의 엔드포인트이다. 유저 디바이스(204a, 204b)는 관련 유저로부터 정보를 수신하고 관련 유저에게 정보를 출력하도록 배치된다. 비록 도 2에서는 2개의 유저 디바이스만이 도시되어 있지만, 더 많은 유저 디바이스가 통신 시스템(200)에 포함될 수도 있다. 각각의 유저는, 다수의 형태, 예를 들면, 데스크톱 또는 랩탑 컴퓨터, 이동 전화(예를 들면, 스마트폰), 태블릿 컴퓨팅 디바이스, 웨어러블 컴퓨팅 디바이스, 텔레비전(예를 들면, 스마트 TV), 셋톱 박스, 게임용 콘솔 등의 형태를 취할 수 있는 컴퓨터 디바이스이다.

또한, 네트워크(301)에는, 복수의 데이터 센터(data centre; DC)(220a, 220b, ..., 220c) 및 트래픽 관리 시스템(230)이 접속된다. 트래픽 관리 시스템(230)은 하나 이상의 메모리 디바이스(234) 및 이하에서 보다 상세하게 설명되는 바와 같이 데이터센터 트래픽을 관리하기 위한 트래픽 관리 코드(232)(트래픽 매니저/트래픽 관리 로직)를 실행하도록 구성되는 하나 이상의 프로세서를 포함한다. 트래픽 관리 시스템(230) 및 데이터센터(220)는 분산형 플랫폼(800)의 일부를 형성한다.

서버(602)는 또한, 프록시 서버인 네트워크(201)에 접속되는데, 그 기능은 적절한 때에 설명될 것이다.

도 3은 유저 디바이스(204)(예컨대 유저 디바이스(204a 및 204b))의 상세도를 예시한다. 유저 디바이스(204)는 중앙 프로세싱 유닛(central processing unit; "CPU")(302)을 포함하는데, 중앙 프로세싱 유닛("CPU")(302)에는 다음의 것이 접속된다: 터치 스크린으로서 구현될 수도 있는 디스플레이(304), 및 오디오 신호를 출력하기 위한 스피커(또는 "라우드스피커")(310)와 같은 출력 디바이스; 오디오 신호를 수신하기 위한 마이크(326), 이미지 데이터를 수신하기 위한 카메라(308) 및 키패드(306)와 같은 입력 디바이스; 데이터를 저장하기 위한 메모리(326); 및 네트워크(201)와 통신하기 위한 모뎀과 같은 네트워크 인터페이스(324). 유저 디바이스(204)는 도 3에 도시되는 것과는 다른 엘리먼트를 포함할 수도 있다. 디스플레이(304), 스피커(310), 마이크(312), 메모리(326), 카메라(308), 키패드(306) 및 네트워크 인터페이스(324)는 유저 디바이스(204)로 통합될 것이다. 대안적으로, 디스플레이(304), 스피커(310), 마이크(312), 메모리(326), 카메라(308), 키패드(306) 및 네트워크 인터페이스(324) 중 하나 이상은 유저 디바이스에 통합되지 않을 수도 있고 각각의 인터페이스를 통해 CPU(302)에 접속될 수도 있다. 이러한 인터페이스의 일 예는 USB 인터페이스이다. 네트워크 인터페이스(324)를 통한 유저 디바이스(204)의 네트워크(201)로의 접속이 무선 접속이면, 네트워크 인터페이스(324)는 네트워크(201)로 신호를 무선으로 송신하고 네트워크(201)로부터 신호를 무선으로 수신하기 위한 안테나를 포함할 수도 있다.

도 3은 CPU(302) 상에서 실행되는 오퍼레이팅 시스템(operating system; "OS")(314)을 또한 예시한다. OS(314)의 상에서는, 통신 시스템(200)의 통신 클라이언트 애플리케이션(클라이언트)(316)의 인스턴스의 소프트웨어 스택이 실행하고 있다. 클라이언트(316)는 오퍼레이팅 시스템(314)과 통신하고 다른 유저 디바이스와의 그리고 데이터센터(220)와의 접속을 비롯한, 통신 시스템(200)을 통한 접속을 관리한다. 클라이언트(316)는 디바이스의 유저에게 정보를 제시하는데, 그리고 디바이스의 유저로부터 정보를 수신하는데 사용되는 클라이언트 유저 인터페이스(User Interface; "UI")를 갖는다. 소프트웨어 스택은 클라이언트 프로토콜 레이어(418), 클라이언트 엔진 레이어(420) 및 클라이언트 유저 인터페이스 레이어(422)를 도시한다. 각각의 레이어는 특정한 기능을 담당한다. 각각의 레이어가 보통은 두 개의 다른 레이어와 통신하기 때문에, 이들은 도 3에서 도시되는 바와 같은 스택으로 정렬되어 있는 것으로 간주된다. 오퍼레이팅 시스템(314)은 디바이스(204)의 하드웨어 리소스를 관리하고 네트워크 인터페이스(324)를 통해 네트워크(201)로 송신되고 있는 그리고 그 네트워크(201)로부터 수신되고 있는 데이터를 핸들링한다. 클라이언트 소프트웨어의 클라이언트 프로토콜 레이어(318)는 오퍼레이팅 시스템(314)과 통신하고 통신 시스템(200)을 통한 접속을 관리한다. 상위 레벨(higher level) 프로세싱을 요구하는 프로세스는 클라이언트 엔진 레이어(320)로 전달된다. 클라이언트 엔진(320)은 또한 클라이언트 유저 인터페이스 레이어(322)와 통신한다. 클라이언트 엔진(320)은, 클라이언트 유저 인터페이스 레이어(322)를 제어하여, 클라이언트의 유저 인터페이스를 통해 유저에게 정보를 제공하도록 그리고 유저 인터페이스를 통해 유저로부터 정보를 수신하도록 정렬된다. 이러한 방식에서, 클라이언트(216)는 유저(예를 들면, Alice, Bob)가 통신 시스템(200)을 통해 통신하는 것을 허용하는데 필요로 되는 프로세싱을 수행한다.

유저 인터페이스는, 예를 들면, 디스플레이(24)를 통해 정보를 출력하는 그래픽 유저 인터페이스(Graphical User Interface; GUI) 및/또는 마우스, 키보드, 원격 컨트롤러, 및 등과 같은 소정의 입력 디바이스에 의해 부과되는 인위적인 제약이 없이, 유저가 "자연스러운" 방식으로 디바이스와 상호 작용하는 것을 가능하게 하는 내추럴 유저 인터페이스(Natural User Interface; NUI)를 포함할 수도 있다. NUI 방법의 예는, 터치 감지 디스플레이, 음성 및 스피치 인식, 의도 및 목표 이해, 깊이 카메라(예를 들면, 입체 또는 비행 시간(time-of-flight) 카메라 시스템, 적외선 카메라 시스템, RGB 카메라 시스템 및 이들의 조합)를 사용한 모션 제스쳐 검출, 가속도계/자이로스코프를 활용한 모션 제스쳐 검출, 얼굴 인식, 3D 디스플레이, 머리, 눈, 및 시선 추적, 몰입형 증강 현실 및 가상 현실 시스템 등을 활용하는 것들을 포함한다.

클라이언트 엔진 레이어는 복수의 서비스 에이전트(512)를 포함한다. 각각의 서비스 에이전트는 실시간 미디어 통신 이벤트(예를 들면, 호)의 독특한 양태(distinct aspect)를 처리한다. 에이전트는 엔드포인트가 특정한 클라우드 서비스와 상호 작용하는 방법을 정의하는 엔드포인트/클라이언트 로직 구현예, 예를 들면, 호 에이전트의 경우, 호 컨트롤러; 미디어 모달리티 에이전트의 경우, 미디어 모달리티 컨트롤러 등을 의미한다. 에이전트는 클라이언트의 소프트웨어 라이브러리에서 구체화될 수도 있다.

도 4a는 데이터센터(220)(예를 들면, 데이터센터(220a, 220b, 220c ...) 중 하나)의 개략적인 예시이다. 데이터센터는, 복수의 서버(444, 404a, 404b, 404c); 데이터센터(220) 내의 네트워크 디바이스 사이에서 그리고 네트워크(201)를 통해 데이터센터 외부의 디바이스와 데이터 패킷을 교환하기 위한, 네트워크(210)에 접속되는, 네트워크 인프라(infrastructure)(480); 및 데이터센터의 디바이스에 전력을 제공하기 위한 전력 인프라(490)를 포함한다. 서버(404a, 404b) 및 서버(404c)는, 파워 서플라이(power supply)(492) 및 파워 서플라이(492')에 의해 각각 전력을 제공받는데, 이들 자체는 전력 인프라(490)로부터 전력을 제공받는다. 데이터센터는 또한, 데이터 센터(220)로 지향되는 네트워크(201)로부터의 유입하는(inbound) 트래픽을 수신하고 서버(404a, 404b, 404c)에 걸쳐 그 트래픽을 분산시키기 위한, 그리고 데이터센터(220)의 하나의 서버(예를 들면, 404)로부터의 내부 트래픽을 데이터센터(220)의 다른 서버(예를 들면, 404b, 404c)에 걸쳐 분산시키기 위한, 네트워크 인프라(480)에 접속된 데이터 센터 트래픽 관리 시스템(488)을 포함한다. DC 트래픽 관리 시스템은, 하드웨어 부하 밸런서(hardware load balancer), 적절한 컴퓨터 시스템 상에서 실행되는 소프트웨어, 또는 이들의 조합과 같은 컴포넌트를 포함할 수도 있다.

서버(404a, 404b, 404c)의 각각은, 다른 네트워크화된 디바이스와 데이터를 교환하기 위한 각각의 네트워크 인터페이스(484a, 484b, 484c)에 대한 각각의 프로세서(406a, 406b, 406c)를 포함한다. 각각의 프로세서는 각각의 메모리(414a, 414b, 414c)에 대한 직접적인 액세스를 구비하며; 컴퓨터 스토리지에 보관된 데이터에 대한 액세스를 프로세서에게 제공한다.

네트워크 인터페이스(484a 및 484b)는 네트워크 스위치(482)에 접속되는데, 네트워크 스위치(482)는, 서버(404a 및 404b)가 서로 그리고 그 스위치(482)에 접속된 임의의 다른 서버(도시되지 않음)와 그 스위치(482)를 통해 직접적으로 데이터를 송수신하는 것을 가능하게 한다. 네트워크 인터페이스(484c)는 네트워크 스위치(482')에 접속되는데, 네트워크 스위치(482')는, 서버(404c)가 서로 그리고 그 스위치(482')에 접속된 임의의 다른 서버(도시되지 않음)와 그 스위치(482')를 통해 직접적으로 데이터를 송수신하는 것을 가능하게 한다. 스위치(482)는 네트워크 인프라(480)에 접속되는데, 네트워크 인프라(480)도 또한, 서버(404a, 404b) 및 스위치(482)에 접속된 임의의 다른 서버가, 네트워크 인프라에 접속된 다른 디바이스(예를 들면, 스위치(582')와 같은 다른 스위치를 통해 이렇게 접속된 디바이스)와 그리고 네트워크(201)에 접속된 다른 디바이스와 데이터를 송수신하는 것을 가능하게 한다. 스위치(482')는 등가의 기능성(functionality)을 제공하도록 유사하게 접속된다.

서버(444)는 데이터센터(220)에 대한 제어 서버이다; 그것은 데이터센터 내의 다른 서버의 제어 및 모니터링을 담당한다. 제어 서버(444)는 파워 서플라이(494)로부터의 전력을 공급 받는데, 파워 서플라이(494) 그 자체는 전력 인프라(490)로부터 전력을 공급 받는다. 제어 서버(444)는, 메모리(454)에 접속되는 프로세서(446) 및 다른 네트워크 디바이스와 데이터를 교환하기 위한 네트워크 인터페이스(486)를 포함한다. 네트워크 인터페이스(486)는 네트워크 인프라(480)에 접속되는데, 네트워크 인프라(480)는, 제어 서버(444)가, 서버(404a, 404b, 404c)를 포함하는 네트워크 인프라에 접속된 다른 디바이스와 그리고 네트워크(201)에 접속된 추가 디바이스(예를 들면, 도 3의 204a, 204b)와 데이터를 교환하는 것을 가능하게 한다.

서버(404a, 404b, 404c)는 각각의 장애 도메인(fault domain)(402, 402')으로 그룹화되는데, 장애 도메인은, 공통 실패 지점(point of failure)을 공유하는 서버(즉, 동작을 위해 동일한 물리적 전자 컴포넌트에 의존하는 서버, 따라서 그 동일한 물리적 전자 컴포넌트의 실패는 모든 이들 서버의 동작을 차단한다)의 그룹이다. 예를 들면, 서버(404a 및 404b)는 서버(408a, 408b) 둘 다에 공통인 네트워크 스위치(482)를 통해 네트워크 인프라(580)에 접속되고; 이 스위치(482)의 실패는, 모든 이러한 서버가 네트워크 인프라(480)로부터 분리되게 되고 따라서 그 이벤트에서 네트워크(201)로부터 분리된다는 점에서, 서버(404a, 404b) 각각, 및 그 스위치에 접속된 임의의 다른 서버의 실패를 야기한다. 따라서, 네트워크 스위치(482)는 그 스위치(482)에 접속된 모든 서버의 그룹인 장애 도메인을 정의한다고 한다. 마찬가지로, 서버(404a 및 404b) 둘 다는, 전력 인프라(409)에 의해 그 자신의 전력을 공급 받는 파워 서플라이(492)로부터 전력을 공급 받고; 이 파워 서플라이(492)의 고장은 서버(404a, 404b) 각각, 및 그 파워 서플라이(492)에 의해 전력을 공급 받는 임의의 다른 서버의 고장을 야기한다. 따라서, 파워 서플라이(492)는 그 파워 서플라이(492)에 의해 전력을 공급 받는 모든 서버의 그룹인 장애 도메인을 정의한다. 도 4a에서, 스위치(482)에 접속된 것으로 도시되는 각각의 서버는 파워 서플라이(492)에 의해 전력을 공급 받는 것으로 또한 도시되고, 따라서 스위치(482) 및 도 5a의 파워 서플라이(492)는 공통의 장애 도메인(402)을 정의하며; 일반적으로, 동일한 파워 서플라이에 의해 전력을 공급 받는 서버는 상이한 네트워크 스위치에 접속될 수도 있고 그 반대로 될 수도 있다. 마찬가지로, 도 4a는 네트워크 스위치(482); 및 파워 서플라이(492') 둘 다를 특징으로 하는 제2 장애 도메인(402')을 도시한다. 장애 도메인(402')의 서버(404c)는 스위치(482') 및 파워 서플라이(492')에 접속되어 도시된다. 데이터센터(220)는 장애 도메인(202, 202') 및 추가적인 네트워크 스위치, 파워 서플라이 및 다른 물리적 컴포넌트(도시되지 않음)를 특징으로 하는 다른 장애 도메인 둘 다에서 추가적인 서버(어쩌면 수천 개)를 포함한다.

도 4b는 서버(303)(404a, 404b, 404c)의 추가 세부 사항을 도시한다. 프로세서(406)(예를 들면, 406a, 406b, 406c)는 하이퍼바이저를 실행한다. 하이퍼바이저는 가상 머신(410i, 410ii)을 생성, 실행 및 관리하는 컴퓨터 소프트웨어의 일부이다. 각각의 오퍼레이팅 시스템(420i, 420ii)(예를 들면, Windows Server(TM))은 각각의 VM(410i, 410ii) 상에서 실행하고, 결국에는, 각각의 애플리케이션 코드(434i, 434ii)가 각각의 오퍼레이팅 시스템(420i, 420ii) 상에서 실행한다. 애플리케이션 코드는 컨트롤러, 예를 들면, 호 컨트롤러, 미디어 모달리티 컨트롤러를 구현할 수 있다.

프로세서(406)는, 프로세서(406)에 의해 직접적으로 액세스 가능한 메모리(414)(예를 들면, 414a, 414b, 414c)를 갖는다. 프로세서 상에서 애플리케이션의 인스턴스를 실행하기 위해, 애플리케이션 코드(434i/434ii)는, 프로세서(406a, 406b, 406c)가 메모리(414)의 애플리케이션 코드에 직접 액세스하도록, 외부 컴퓨터 스토리지(즉, 프로세서 외부에 있고 프로세서가 간접적으로 액세스할 수 있음)로부터 메모리(414a, 414b, 414c) 안으로 로딩된다. 인스턴스가 진행됨에 따라, 예를 들면 인스턴스가 네트워크(301)로부터 수신되는 메시지를 처리함에 따라 업데이트되는 대응하는 런타임 상태 데이터도 또한 메모리(414)에서 유지된다.

동일한 컨트롤러(예를 들면, 호 컨트롤러, 미디어 모달리티 컨트롤러)의 두 인스턴스는 동일한 서비스(예를 들면, 호 제어, 미디어 모달리티 제어)를 전달할 수도 있으며, 특정한 제어의 상이한 인스턴스가 상이한 시점에서 동일한 통신 이벤트의 관련 양태를 제어하는 것을 종료할 수도 있도록 어느 정도 상호 교환 가능하다. 통신 시스템(300)은, 예를 들면 클라이언트(316)의 대응하는 에이전트(512)(예를 들면, 호 에이전트, 미디어 에이전트)에 의해, 특정한 컨트롤러(예를 들면, 호 컨트롤러, 미디어 모달리티 컨트롤러)로 개시되는 메시지에 응답한다. 특히, 응답으로 통신 시스템(300)은 그 컨트롤러의 인스턴스에게 메시지를 핸들링할 것을 할당한다. 어느 정도까지는, 인스턴스는 직접적인 부하 밸런싱을 통해 할당받지만, 하기에서 설명되는 바와 같이 항상 그런 것은 아니다.

이하, 용어 "서비스 로직"(등가적으로 "배치")은, 동일한 서비스, 예를 들면, 호 제어, 미디어 모달리티 제어를 전달할 수 있는 인스턴스의 특정한 그룹을 지칭하기 위해 사용된다. 이들 인스턴스 중 임의의 두 인스턴스는 상이한 프로세서 상에서 실행 중일 수도 있거나, 또는 그들은 공교롭게도 동일한 프로세서 상에서 실행 중일 수도 있다. 각각의 서비스 로직은 도 6a 및 도 6b를 참조로 설명될 계층적 구조를 갖는다. 통상적으로, 컨트롤러는 다수의, 그리고 어쩌면 수많은 호 등을, 자신의 리소스를 이들 다양한 호 사이에 공유하면서, 동시에 핸들링할 것이다.

도 5a에서 도시되는 바와 같이, 클라우드(100)는, 적어도, 제1 타입(즉, 제1 서비스를 전달할 수 있음)의 제1 서비스 로직(523[1])의 제1 그룹(502[1]) 및 제2 타입(즉, 제2 서비스를 전달할 수 있음)의 제2 서비스 로직(523[2])의 그룹(502[2])을 실행하도록 적응된다. 유저 디바이스(204)의 클라이언트(216)는 각각의 타입의 서비스에 대한 서비스 에이전트(512[1](제1 타입), 512[2](제2 타입))를 포함한다. 서비스 에이전트(512[1])는 네트워크(201)를 통해 제1 타입의 서비스 로직(523[1])과 통신할 수 있고 서비스 에이전트(523[2])는 네트워크(201)를 통해 제2 타입의 서비스 로직(523[2])과 통신할 수 있다.

각각의 서비스 에이전트(512) 및 각각의 서비스 로직(523)은 트래픽 매니저(230)와 통신할 수 있다. 서비스 로직과 그들의 각각의 에이전트 사이의 통신은 트래픽 매니저(330)에 의해 어느 정도 중재된다. 예를 들면, 호 에이전트 또는 미디어 에이전트가 호 제어 또는 미디어 모달리티 제어 서비스를 먼저 요청하면, 에이전트는, 대응하는데이터 센터, 지리적 위치 등에서의 리소스 가용성과 같은 적절한 기준에 기초하여 특정한 호 제어 또는 미디어 모달리티 제어 로직을 선택하는 요청을 트래픽 매니저에게 보낸다. 그 후, 호/미디어 모달리티 에이전트는 특정한 통신 이벤트에 대한 관련 메시지를, 선택된 호/미디어 모달리티 서비스 로직으로 향하게 할 수 있다.

도 5b에서 도시되는 바와 같이, 특정한 서비스를 전달하기 위한 서비스 로직은, 그 서비스를 전달하기 위해 협력하는 하나 이상의 클러스터(522, 552)를 포함한다. 클러스터의 예는 Windows Azure(TM) 클라우드 플랫폼 상에서 구현되는 웹 및 작업자(worker) 역할을 포함한다. 이 실시형태에서, 각각의 서비스 로직은 단일의 각각의 데이터센터(예를 들면, 220a, 220b, 220c 중 하나)에서 구현된다. 서비스 로직의 각각의 클러스터는, 부하 밸런서(548, 558) 및 애플리케이션 코드(434)의 각각의 인스턴스를 실행하는 하나 이상의 가상 머신(410)을 포함한다. 클러스터의 부하 밸런서는 네트워크(201)로부터 메시지를 수신할 수 있고, 이들 요청을 그 클러스터의 VM 중 임의의 것으로, 예를 들면, 라운드 로빈 방식으로 또는 이들 VM의 모니터링된 리소스 가용성에 기초하여, 향하게 할 수 있다(예를 들면, 유입하는 요청을 현재 가장 이용 가능한 리소스를 갖는 VM으로 향하게 한다). 클러스터의 부하 밸런서는, 그 클러스터의 각각의 VM이 그 부하 밸런서에 의해 수신되는 임의의 메시지를 프로세싱할 수 있도록 등가적으로 구성된다고 가정한다.

도 5b는 각각의 부하 밸런서(548, 558)를 갖는 적어도 두 개의 클러스터(522 및 552)를 포함하는 서비스 로직(542)을 도시한다. 클러스터(522)는 적어도 두 개의 VM(410A, 410B)을 포함한다. VM(510A)은 제1 애플리케이션 코드의 인스턴스(434A)를 실행하고 VM(410B)은 제1 애플리케이션 코드의 다른 인스턴스(434B)를 실행한다. 마찬가지로, 클러스터(452)는 적어도 두 개의 VM(410A', 410B')을 포함한다. VM(410A')은 제2 애플리케이션 코드의 인스턴스(434A)를 실행하고 VM(510B')은 제2 애플리케이션 코드의 인스턴스(434B')를 실행한다. 서비스 로직의 클러스터는 하나 이상의 외부적으로 주소 지정 가능한 인터페이스(524) 및/또는 그 클러스터와의 데이터 교환을 위한 논리적 접속을 확립하기 위해 호출될 수 있는 하나 이상의 내부 주소 지정 가능한 인터페이스(556)를 노출하도록 구성될 수 있다. 내부 인터페이스(556)는 동일한 서비스 로직의 다른 클러스터만이 액세스가능한 반면, 외부 인터페이스는, 예를 들면 대응하는 클라이언트 측 서비스 에이전트(512)에 의해 클러스터의 외부로부터 액세스 가능하다. 클러스터의 인터페이스는, 그 인터페이스를 사용하여 그 클러스터로 향하는 임의의 요청이 그 클러스터의 VM으로 포워딩하기 위해 그 부하 밸런서에 의해 수신되도록(이 포워딩은 그 클러스터 외부에서 보이지 않음), 그 클러스터의 부하 밸런서에 커플링된다. 도 5b는, 그 클러스터의 부하 밸런서(548)에 커플링되는 외부 인터페이스(524)를 노출시키는 클러스터(552) 및 그 클러스터의 부하 밸런서(558)에 커플링되는 내부 인터페이스(556)를 노출시키는 클러스터(552)를 도시한다.

임의의 타입의 서비스(예를 들면, 호 제어, 미디어 모달리티 제어)에 대한 리소스 할당은, 다음 방법 중 하나 이상으로 증가(감소)될 수 있다:

- 그 타입의 추가적인 서비스 로직을 배치하는(현존하는 서비스 로직을 종료하는) 것에 의해, 즉, 물리적 컴퓨터 리소스를 제1 타입의 신규의 서비스 로직에 할당하는(그 타입의 현존하는 서비스 로직에 대한 컴퓨터 리소스를 할당 해제하는) 것에 의해 - 이것의 하나 예는 Windows Azure™ 클라우드 플랫폼 상에 신규의 웹 애플리케이션을 배치하는 것일 것이다;

- 제1 타입의 하나 이상의 현존하는 서비스 로직의 컴포넌트(들) 내에서 가상 머신의 수를 증가(감소)시키는 것에 의해, 즉 그 컴포넌트에 대한 컴퓨터 리소스 할당을 증가(감소)시키는 것에 의해 - 이것의 하나의 예는 Windows Azure™ 클라우드 플랫폼 상의 웹 애플리케이션의 웹 역할 또는 작업자 역할 내에서 인스턴스의 수를 변경하는 것일 것이다;

- 제1 타입의 하나 이상의 현존하는 서비스 로직의 컴포넌트(들) 내에서 중복 가상 머신의 "사이즈"(즉, 중복 가상 머신에 할당되는 물리적 리소스의 각각의 양)를 증가(감소)시키는 것에 의해, 즉, 특정한 컴포넌트의 이러한 중복 가상 시스템에 할당되는 각각의 컴퓨터 리소스를 증가(감소)시키는 것에 의해, - 이것의 하나의 예는 Windows Azure™ 클라우드 플랫폼 상에서 웹 애플리케이션의 웹 역할 또는 작업자 역할을 리사이징하는 것일 것이다.

후자의 두 기술을 사용하여, 리소스는 하나의 서비스 로직에, 동일한 타입 및 상이한 타입 둘 다의 다른 서비스 로직과는 독립적으로 할당될 수 있다(즉, 하나의 배치). 예를 들면, 더 많은 VM이 제1 타입의 제1 서비스 로직의 컴포넌트(들)에 추가될 수 있을 것이고, 및/또는 이들 컴포넌트(들)의 VM은, 그 타입의 다른 서비스 로직의 컴포넌트(들)를 변경하지 않고도 그리고 상이한 타입의 다른 서비스 로직의 컴포넌트(들)를 변경하지 않고도, 리사이징될 수 있을 것이다.

또한, 후자의 두 기술을 사용하여, 리소스는 동일한 서비스 로직의 상이한 컴포넌트에 서로 독립적으로 할당될 수 있다(예를 들면, 다른 서비스 로직을 변경하지 않으면서 하나의 서비스 로직에 VM을 추가하거나, 또는 하나의 서비스 로직의 VM을 리사이징한다).

0.2 시스템 아키텍처 개요

본원에서, 용어 "트랜잭션(transaction)"은, 통신 이벤트를 확립하는 것, 확립된 통신 이벤트를 종료하는 것, 또는 다음과 같은 호 내 기능을 수행하는 것과 같은 하이 레벨 제어 동작을 집합적으로(collectively) 구현하는 로우 레벨 동작의 시퀀스를 지칭한다: 확립된 통신 이벤트 동안 확립된 통신 이벤트에/로부터 참가자를 추가하거나 또는 제거하는 것, 확립된 통신 이벤트를 보류 상태로 두는 것, 확립된 통신 동안 확립된 통신 이벤트에/로부터 미디어 모달리티(예를 들면, 오디오, 비디오)를 추가하거나 또는 제거하는 것 등. 트랜잭션은, 트랜잭션을 달성하도록 할당되는 인스턴스와 클라이언트 상의 관련 에이전트(512) 사이에서의 네트워크(201)를 통한 하나 이상의 메시지의 송신 및/또는 수신을 수반한다.

하기에 설명되는 실시형태에서, 임의의 하나의 트랜잭션은 컨트롤러의 동일한 인스턴스에 의해 수행된다. 이것은 필수적인 것은 아니다: 그것은, 트랜잭션의 초기에 생성되는 리소스와 컨텍스트를 재사용하는 것에 의해 트랜잭션 프로세싱 시간을 더 빠르게 만드는 최적화이다. 이것은, 트랜잭션이 상당히 짧고 진행 중인 트랜잭션을 시스템이 핸들링하고 있는 동안 프로세싱 인스턴스가 죽을 확률이 매우 낮기 때문에, 시스템의 높은 가용성을 크게 손상시키지 않는다.

그럼에도 불구하고, (높은 가용성을 위해) 그 최적화를 중단하는 것, 및 임의의 인스턴스가 중간 트랜잭션 메시지를 핸들링하는 것을 허용하는 것이 가능하다 - 이것을 달성하기 위해, 각각의 메시지를 프로세싱한 이후, 호 컨트롤러 인스턴스는 호 상태를 외부 저장소에 플러싱하고(flush); 신규의 메시지를 프로세싱하기 이전에, 신규의 메시지를 수신하는 프로세싱 인스턴스는 외부 저장소로부터 상태를 가져 오고(fetch), 호 상태를 다시 생성하고, 필요로 될 수도 있는 임의의 다른 리소스를 다시 초기화한다(예를 들면, 클라이언트에 대한 TLS/TCP 접속).

다음의 것이 제시된다:

1. 클라이언트 에이전트와 컨트롤러 사이의 통신을 가능하게 하는 시그널링 프로토콜(섹션 1);

2. 컨트롤러의 상이한 인스턴스가 상이한 트랜잭션을 핸들링할 수 있도록 통신 이벤트의 상태 데이터를 직렬화하기 위한 메커니즘(섹션 2)

3. 각각의 단일 트랜잭션이 가능한 경우 컨트롤러의 동일한 인스턴스에 의해 핸들링되는 것을 보장하기 위한 메커니즘(섹션 3).

상기 메커니즘 "2."는, 다수의 인스턴스가 동일한 트랜잭션을 처리하는 실시형태에서, 상이한 인스턴스가 동일한 트랜잭션에 관한 메시지를 프로세싱하는 것을 허용하기 위해 사용될 수 있다는 것을 유의한다.

예를 들면, 도 5b에서, 서비스 로직(523)의 제1 클러스터(522)는 주(primary) 제어 서비스(예를 들면, 호 제어, 미디어 모달리티 제어)를 구현할 수도 있다. 그 다음, 제2 클러스터(552)는, 클러스터의 각각의 VM 상에서 실행하는 제2 코드가 클러스터 사이에서 공유되는 컴퓨터 스토리지에 액세스하기 위한 인터페이스를 제공하도록 구성되는 것에 의해 구현되는 데이터 저장 서비스와 같은, 주 제어 서비스를 지원하는 제2 서비스를 구현할 수 있다. 그 다음, 호/미디어 모달리티 컨트롤러 인스턴스(434A, 434B)는, 제1 클러스터(522)의 다른 인스턴스가 특정한 통신 이벤트에 대한 미래의 트랜잭션을 핸들링할 수 있도록, 특정한 통신 이벤트에 대한 트랜잭션의 종료 시에, 제1 클러스터(522)의 다른 인스턴스가 액세스가능한 제2 클러스터(552)에 직렬화된 상태 데이터를 기록할 수 있다.

도 6은 통신 시스템(200)의 예시적인 구성을 도시한다. 클라이언트(316)는 호 에이전트(512C) 및 미디어 에이전트(512M)를 포함한다.

호 에이전트(512C)는 호 제어 서비스 로직(523C)의 호 컨트롤러 클러스터(522C)의 외부 인터페이스(524C)에 네트워크(201)를 통해 실시 유발 메시지를 보낼 수 있다. 호 컨트롤러 클러스터는 호 컨트롤러의 다수의 인스턴스(434C1, 434C2)를 포함한다. 호 컨트롤러 클러스터(522C)의 부하 밸런서(548C)는, 각각의 메시지에 대해, 호 컨트롤러 인스턴스 중 하나를 선택하고 선택된 인스턴스로 메시지를 보낸다. 선택된 인스턴스는 하기에 설명되는 방식으로 메시지를 핸들링한다.

호 제어 서비스 로직(523C)은 또한, 데이터 스토리지 소프트웨어, 예를 들면 Azure Table Store 등의 하나 이상의 인스턴스(434S1, 434S2)를 포함하는 스토리지 클러스터(552C)를 포함한다. 데이터 저장 소프트웨어 인스턴스(434S1, 434S2)는 컴퓨터 스토리지(608)에 대한 액세스를 제공한다. 스토리지 클러스터(552C)는 전자(former)의 내부 인터페이스(도 6에서 도시되지는 않지만, 그러나 전술한 바와 같음)를 통해 호 컨트롤러 클러스터(522C)에 액세스 가능하다.

미디어 에이전트(512M)는 네트워크(201M)를 통해 실시 유발 메시지를 미디어 모달리티 제어 서비스 로직(523M)의 미디어 모달리티 컨트롤러 클러스터(522M)의 외부 인터페이스(524M)로 보낼 수 있는데, 메시지는 클러스터(522M) 내의 선택된 미디어 모달리티 인스턴스(434M1, 434M2)로 마찬가지로 보내진다.

개방형, 즉 진행 중인 접속(604)이 클라이언트(31)와 프록시 서버(604) 사이에서 확립된다. 접속은, 프록시 서버(602)와 클라이언트 디바이스(204) 사이에서 전이중 통신을 제공하는 웹소켓(WebSocket) 접속이다. 웹소켓 접속은 기술 분야에서 공지되어 있다. 호 컨트롤러(434C, 434C2) 및 미디어 모달리티 컨트롤러(434M1, 434M2)의 인스턴스는, 각각 프록시 서버(602)를 통해 호 에이전트(512C) 및 매체 에이전트(512M)에 시그널링할 수 있다. 이것은, 클라이언트 디바이스(204)가 네트워크 어드레스 변환기(Network Address Translator; NAT) 또는 방화벽 뒤에 있는 경우에도, 컨트롤러 인스턴스가 그들의 대응하는 에이전트로 메시지를 보내는 것을 가능하게 한다.

호 컨트롤러는 통신 이벤트(대화) 예를 들면 호를 확립할 수도 있고, 확립된 대화를 관리할 수 있다: 그것은 다음의 것을 달성하기 위해 시그널링을 담당한다:

1. 호 셋업;

2. 재협상, 예를 들면:

a. 보류 /보류 해제;

b. 화면 공유 또는 공유된 화이트 보드와 같은 비디오 또는 다른 미디어 모달리티의 추가/제거;

3. 호 해체(tear down);

4. 호 관련 명단(roster) 업데이트. 명단은 호에 참가하는 다양한 엔드포인트에 대한 정보를 의미한다. 이 정보를 사용하여, 클라이언트는, 예를 들면 호 참가자 목록을 갖는 UI를 제공할 수 있고, 예를 들면, 호 참가자 제거("참가자 제거"), 호 참가자 음소거("참가자 음 소거") 등의 동작을 허용할 수 있다.

호 컨트롤러는 또한, 부트스트랩 방식으로 구동할(bootstrap) 수도 있고 미디어 모달리티 컨트롤러 인스턴스에 의한 미디어 모달리티 서비스를 제어할 수도 있지만, 일부 실시형태에서는 미디어 모달리티 컨트롤러는 그룹 호에 대해서만 사용된다.

1. 시그널링 프로토콜:

이하에서는, 호 에이전트와 호 컨트롤러 인스턴스 사이의 시그널링을 위한 메커니즘이 제시된다. 이들은 호 컨트롤러의 컨텍스트에서 설명되지만, 그러나 기저의 원리 중 일부는 다른 타입의 클라우드 서비스에(예를 들면, 미디어 모달리티 컨트롤러에) 적용될 수 있다.

프로토콜은 다음을 제공한다:

1. 클라이언트와 서버(예를 들면, 호 컨트롤러) 둘 다 상에서 상태 머신을 구동하는 메시지를 전송하기 위한 메커니즘으로서의 콜백 링크의 사용;

2. (수반된 당사자의 라우팅 세부 사항을 서로 간에 숨기는 것에 의해) 보안을 제공할 수 있는, 그리고 호가 일관된 상태 그대로 인 것을 보장할 수 있는 가로채기 서버(intercepting server)를 생성하기 위한 (호 컨트롤러에 의한) url 재작성의 사용;

3. url을 추가하거나 업데이트는 것에 의해 신규의 기능성을 추가할 수 있는 프록시의 생성을 허용하기 위한 url 재작성의 사용(하기의 섹션 1.4 참조);

4. 높은 가용성을 투명하게 제공하기 위한 url 재작성의 사용. 상이한 콜백 링크는, 클라이언트가 콜백 링크를 불투명한 것으로 처리할 때 클라이언트를 중지시키지 않으면서 독립적으로 확장할 수 있는 상이한 엔티티를 가리킬 수 있다. 마찬가지로, (호 컨트롤러와 같은) 콜백 링크를 제공하는 엔티티는, 자신의 로직에 기초하여, 데이터센터, 또는 특정한 인스턴스를 다시 가리키게 될 수 있고, 따라서 임의의 특수한 로직을 갖는 클라이언트 없이 높은 가용성을 투명하게 달성할 수 있다. 이것은, 모든 메시지가 고정된 엔티티로 전송되는 것을 필요로 하며, 따라서 확장성 및 가용성을 저하시키는 SIP와 같은 다른 기술과는 상이하다.

SIP와는 대조적으로, 현재의 프로토콜은 모든 클라이언트 플랫폼에 대한 광범위한 지원을 갖는 HTTP를 사용하며, 클라이언트의 개발을 가능하게 하는 커스텀 클라이언트 측 스택의 생성을 요구하지 않는다. 이것은 더 용이한 제3자 개발을 허용하며, 다른 솔루션과 손쉽게 통합할 수 있는 길을 열어준다.

다음을 허용하는 프로토콜 정의 메시지:

1. 호 셋업

2. 호 해체

3. 다수의 엔드포인트로의 분기(forking)

4. 호 리디렉션(redirection)

5. 미디어 재협상(renegotiation)

6. 호 전달(기본적인 및 자문적인(consultative) 것 둘 다)

7. 신규 참가자의 추가

8. 참가자의 진행 중인 호에 대한 전화 연결(Dial-In)

9. 로스터(roster) 관리

통신 네트워크를 통해 제1 클라이언트 디바이스의 제1 유저(호출자(caller), 예를 들면, Alice)와 제2 클라이언트 디바이스의 제2 유저(피호출자(callee), 예를 들면 Bob) 사이에 실시간 통신 이벤트를 확립하기 위한 방법이 제공된다. 이 방법은 제1 클라이언트 디바이스 상에서 실행하는 제1 클라이언트에 의해 구현된다.

통신 이벤트(예컨대, 호) 확립 프로시져의 제1 단계는, 클라이언트가 네트워크를 통해 다른 클라이언트 디바이스로 메시지를 송신하는 것에 수행된다. 메시지는 아직 수행되지 않은 통신 이벤트 확립 프로세스의 제2 단계에 관련이 있는 다수의 옵션을 포함한다.

예를 들면, 제1 단계는, 제2 클라이언트에 대한 호를 개시하기 위해 제1 유저가 제1 클라이언트의 유저 인터페이스를 통해 옵션을 선택하는 것에 응답하여 실시되는 최초 단계일 수도 있다. 제2 단계는, 예를 들면, 호가 확립되는 것(Bob이 호를 수락하는 경우), 또는 프로시져가 종료되는 것(Bob이 호를 거부하는 경우) 중 어느 하나일 수도 있다.

메시지는, 다수의 옵션의 각각에 대한, 그 옵션을 선택하기 위해 액세스될 수 있는 그 옵션에 고유한 상이한 네트워크 어드레스를 포함하고, 제2 단계가 진행하는 방식은 상이한 네트워크 어드레스 중 어느 것이 액세스되는지에 의해 결정된다. 즉, 방법은, 제1 클라이언트가 다수의 옵션 중 하나에 고유한 네트워크 어드레스가 액세스되었다는 것을 검출하는 것, 및 다수의 옵션 중 상기 하나에 따라 통신 이벤트 확립 프로시져의 제2 단계를 실시하는 것을 포함한다.

하기에서, 네트워크 어드레스는 URI(Uniform Resource Indicators; 유니폼 리소스 인디케이터)이며, 이로 인해, 각각의 옵션은 그 옵션에 고유한 상이한 URI와 관련된다. 즉, Alice의 클라이언트는 프로시져의 제2 단계에 관련이 있는 각각의 옵션에 대해 상이한 URI를 제공한다. URI는, Alice의 클라이언트가 전이중 웹소켓 접속을 갖는 프록시 서버를 가리키며, 서버는, 어떤 옵션이 선택되었는지를 Alice의 클라이언트가 알도록, 관련 네트워크 어드레스에 액세스될 때 Alice의 클라이언트에게 시그널링한다. 프록시의 사용은, 예를 들면 Alice의 클라이언트가 NAT 또는 방화벽 뒤에 있고 따라서, 비록 몇몇 경우에서는 URI가 Alice의 클라이언트 디바이스를 직접적으로 가리키는 것이 여전히 가능하지만, 그 자체가 직접적으로 주소 지정 불가능할 때 유용하다.

네트워크 어드레스, 예를 들면, URL이 옵션에 대해 고유한 것은, URL이 옵션 중 하나에 관련되고 다른 옵션의 어느 것에는 관련되지 않는다는 것을 의미한다(예를 들면, 그 결과 end_Alice_url URL은 호의 시도 및 수락 또는 리디렉션 등에 절대 사용되지 않을 것이다).

예를 들면, URI는, 달리 웹 어드레스 또는 링크로 알려져 있는 URL(Uniform Resource Locator; 유니폼 리소스 로케이터)일 수도 있다.

메시지는 Bob에게 직접 전송되지 않지만, 그러나 호 컨트롤러의 인스턴스를 통해 전송된다. 호 컨트롤러 인스턴스는, 메시지의 URI를 Bob에 송신하기 이전에, 메시지의 URI를 재작성한다(rewrite). 재작성된 URI는, Alice의 프록시 서버(또는 디바이스) 대신, 호 컨트롤러 인스턴스의 클러스터를 가리키는데, 이렇게 하는, Alice의 프록시(또는 클라이언트)는 Bob의 클라이언트에 직접적으로 가시적으로 되지 않기 때문에, 추가된 보안성을 제공한다.

Alice의 프록시(또는 디바이스) 또는 호 컨트롤러 클러스터를 가리킬 수도 있는 URI는, URI에 콘텐츠를 게시하는 것에 의해, 또는 URI에서 콘텐츠를 삭제하는 것에 의해 액세스될 수도 있다. 콘텐츠는 소위 POST 요청 메소드를 사용하여 게시되고, 잘 확립된 HTTP 프로토콜의 일부인 소위 DELETE 요청 메소드를 사용하여 삭제된다. POST 요청은, 웹 서버가 요청 메시지 본문에 포함된 데이터를 저장을 위해 수락해야 한다는 것을 요청하고, URL에 실시 유도된 DELETE 요청은 그 URL에서의 콘텐츠의 삭제를 요청한다. 즉, 옵션은, 그 옵션에 고유하게 대응하는 URI에 특정한 요청(예를 들면, 게시, 삭제)을 실시 유도하는 것에 의해 선택된다. 호 컨트롤러 인스턴스에 의해 URI가 재작성된 경우, Bob의 응답은 재작성된 URI(호 컨트롤러 인스턴스의 클러스터를 가리킴)에 게시될 것이고, 원래의 인스턴스 또는 호 컨트롤러 클러스터의 다른 인스턴스는 Bob의 응답을 Alice의 클라이언트에 의해 제공되는 원래의 URI로 재작성할 것이다. Bob의 응답은 또한, Bob의 클라이언트가 유사한 접속을 갖는 프록시 서버를(또는 Bob의 디바이스를 직접적으로) 가리키는 URI(들)를 포함할 수도 있다. 이 경우, 원래 인스턴스 또는 다른 호 컨트롤러 인스턴스는, 호 컨트롤러 클러스터를 비슷한 방식으로 대신 가리키도록 Bob의 URI를 재작성한다.

호 컨트롤러 인스턴스는 또한, 호 컨트롤러 인스턴스가 생성하는, 즉 호 컨트롤러 인스턴스와 함께 발생하는 메시지에서 URL을 제공할 수 있다. 이들은, Alice/Bob의 프록시를 가리키는 Alice/Bob의 클라이언트에 의해 제공되는 URI에 적절하게 게시될 수도 있다.

Alice의 클라이언트는 초기 호 초대 요청 메시지(CallInvitationRequest)를 게시할 트래픽 매니저의 URI를 트래픽 매니저로부터 먼저 획득할 수도 있는데, 트래픽 매니저는 호 컨트롤러 클러스터를 상기에서 설명되는 방식으로 할당한다. 그런 다음, 메시지가 Alice/Bob의 클라이언트에 의해 클러스터의 URI에 게시될 수도 있는데, 이렇게 하는 것은 클러스터의 부하 밸런서로 하여금 클러스터에서 호 컨트롤러 인스턴스를 선택하게 하고, 메시지를 선택한 인스턴스로 전달하게 할 것이다.

현재 진행 중인 트랜잭션과 관련이 있는 호 컨트롤러 클러스터에 게시되는 메시지에 대하여, 메시지가 최초 클러스터의 상이한 인스턴스에 도달하더라도, 진행 중인 트랜잭션을 핸들링하는 특정한 호 컨트롤러 인스턴스가 메시지를 수신하는 것을 보장하기 위한 메커니즘이 섹션 3에서 제공된다. 동일한 호에 대해 다수의 트랜잭션이 동시에 발생하는 경우, 메시지 중 하나가 상이한 인스턴스에 도달하더라도, 이들 트랜잭션 중 양자가 동일한 인스턴스에 의해 핸들링되는 것을 보장하기 위해 동일한 메커니즘이 사용된다. 이것은 호 상태를 수정하는 엔티티가 하나만 존재하는 것을 보장하고, 따라서 다수의 작성자로부터 달리 유래할 수 있는 상태의 불일치 또는 손상의 기회가 존재하지 않는다.

그럼에도 불구하고 (예를 들면, 참가자를 추가하기 위해, 통신 이벤트를 종료하기 위해 등을 위해) 현존하는(즉, 이미 확립된) 통신 이벤트와 관련하는 신규의 트랜잭션을 개시하는 호 컨트롤러 클러스터에 게시되는 메시지에 대해서, 클러스터의 임의의 호 컨트롤러 인스턴스가 신규의 트랜잭션을 핸들링하는 것을 가능하게 하는 메커니즘이 섹션 2에서 제공된다. 요약하면, 호 컨트롤러 인스턴스는, 이전 트랜잭션(들)을 핸들링할 때, "팩토리 객체 식별자(factory object identifier)" 및 "지속된 객체 식별자(persisted object identifier)"를 포함하는 콜백 URL을 클라이언트로 제공한다. 식별자는, 클러스터 중에서 공유되는 컴퓨터 스토리지에 (직렬화된 형식으로) 기록된 통신 이벤트의 호 상태에 관련이 있다. 콜백 URL은 클러스터를 가리킨다. 클라이언트가 콜백 URL에 메시지를 게시하여 신규의 트랜잭션을 시작하는 경우, URL에서의 이 두 식별자의 존재는, 직렬화된 데이터를 사용하여 현존하는 통신 이벤트에 관련이 있는 신규의 트랜잭션을 핸들링할 수 있는 충분한 정보를 클러스터의 임의의 인스턴스에 대해 제공한다. 이것은, 섹션 2에서 상세히 설명될 것이다.

각각의 호는, 호 컨트롤러 클러스터를 가리키는 콜백 URL에 포함되는 호 고유 ID와 관련된다. 이것은, 프로세싱 인스턴스가 섹션 2에서 상세히 설명되는 바와 같이 외부 저장소로부터/로 판독하거나 또는 기록하는 방식으로 일부 최적화를 수행하는 것을 가능하게 한다. (단지, 선택된 URL에 게시되는 메시지의 임의의 콘텐츠가 아닌) URL 자체의 선택은, URL의 원래 공급자에게 정보를 제공한다. 예를 들면, 간단한 예제에서, 호 컨트롤러는, Bob이 호 초대를 수락했다는 것을 나타내기 위해 https://proxy.io/Alice/CallID/Accept에 빈 메시지를, 그리고 Bob이 호 초대를 거부했다는 것을 나타내기 위해 https://proxy.io/Alice/CallID/Reject에 빈 메시지를 게시할 수도 있을 것이다. 이들 URL은 Alice의 프록시를 가리키며, 호 초대 요청 메시지를 보낼 때 Alice의 클라이언트에 의해 제공되었을 것이다. 그러나, 아래의 예에서는, 메시지의 콘텐츠에 보충 정보가 제공된다.

도 7은, 본 실시형태에서 Alice(302a)에 의해 실시 유도된, Alice(호출자)(202a)와 Bob(피호출자)(202b) 사이의 호에 대한 성공적인 호 확립 프로시져의 개요를 도시한다.

다음의 예에서, Alice 및 Bob의 클라이언트는 동일한 프록시(602)에 대한 접속을 갖는다. 실제로는, 이들은 상이한 프록시를 사용할 수도 있다.

Alice의 클라이언트(320a)의 호 에이전트(512Ca)는, 예를 들면, 트래픽 매니저(232)를 사용하여 발견된 호 제어 서비스를 호 제어 서비스 로직(523C)(이하 "CC"라 함)에게 요청하는 호 생성 요청 메시지(CallInvitationRequest)를 실시 유도한다(S1). 호 컨트롤러 인스턴스(434C)는 부하 밸런싱에 의해 요청을 핸들링하도록 할당된다. 요청은 Bob을 소망하는 호 참가자로 식별하고, 할당된 호 제어 서비스 로직(434C)은 호 통지 메시지를 Bob의 클라이언트(320b)의 Bob의 호 에이전트(512C)로 보낸다. 통지는 프록시(602)를 통해 Bob의 디바이스로 송신되었다(S2). Bob은 자신의 클라이언트 UI를 통해, 예를 들면 UI가 호출음 모드(ringing mode)로 진입하는 것에 의해 통지 받고, Bob이 호에 참가하기로 선택하는 것에 응답하여, Bob의 호 에이전트는 CC로 접속(attach) 요청을 보내고(S3), 이것에 응답하여 Bob은 호에 접속된다. S4에서, 다른 것들 중에서도, 호에 대한 매체 파라미터를 협상하기 위해 허브/프록시를 통해 Bob 및 Alice의 호 에이전트(512Ca, 512Cb) 사이에서 호 진행 요청, 미디어 응답 요청 및 미디어 수신확인 응답(media acknowledgement response), 그리고 마지막으로 호 수락 요청 및 호 수락 수신확인 응답이 송수신되고, 그 결과, 미디어가 클라이언트의 매체 에이전트(512Ma, 512Mb) 사이에서 흐를 수 있게 되는데(S5), 이렇게 하는 것은 이 예에서는 미디어 모달리티 컨트롤러를 수반하지 않는다. 호 미디어는 호 컨트롤러를 통해 흐르지 않으며, 클라우드를 통해 흐를 필요가 전혀 없다; 그것은 예를 들면 피어투피어(peer-to-peer) 접속, 미디어 중계 접속, 또는 일부 다른 오버레이 네트워크 접속을 통해 흐를 수도 있다. 미디어 중계(Media Relay)는 NAT 및 방화벽 뒤의 클라이언트가 다른 엔티티와 미디어 패킷을 교환하는 것을 허용하는 엔티티이다. 그것은, 공개적으로 액세스가능한 IP 주소를 가지며, 그 주소를 통해 숨겨진 클라이언트로/로부터 모든 미디어 패킷을 중계하는 것에 의해, 그렇게 한다. 이것은 NAT/방화벽 뒤의 클라이언트가 시그널링을 수행하는 것을 프록시(602)가 허용하는 방식과 유사하다(미디어 중계와 미디어의 관계는 프록시(602)와 시그널링의 관계와 같다).

미디어 응답 및 미디어 응답 수신확인은, 임시 미디어 흐름으로 칭해지는 것을 생성하는 것을 돕는다. 호출자 엔드포인트와 모든 피호출자 엔드포인트 사이에서 임시 미디어 흐름이 생성된다. 예를 들면, 피호출자가 다수의 유저 디바이스에 로그온 한 경우, 다수의 피호출자 엔드포인트가 있을 수도 있다. 이것은 피호출자에게 "호출음(ringing)" UI를 묘사(출력)하기 이전에 발생하며, 따라서 피호출자가 호를 받는(pick up) 즉시, 그녀는 미디어 셋업을 기다리지 않고도 대화를 시작할 수도 있다. 미디어 수신확인은, 피호출자 엔드포인트가 보낸 미디어 응답이 실제로 호출자 클라이언트에서 확인되고(seen) 및 프로세싱되었다는 것을 피호출자 엔드포인트가 알게 되는 것을 보장하며, 따라서 미디어 흐름이 시작되었다는 것이 확실해질 수 있다. 추가적으로, 클라이언트는, mediaAnswer가 호출자 엔드포인트에서 실제로 확인되었는다는 것을 보장하기 위한 트리거로서 mediaAcknowledgement를 사용한다. 클라이언트는, 합리적인 시간(예를 들면, 15 초) 내에 mediaAcknowledgement가 확인하지 못하면 mediaAnswer를 재전송할 수 있다.

호 수락(Call Acceptance)은 (다른 것들 중에서도) 호를 받지 않은 임의의 엔드포인트의 호출음을 소거하기 위한, 그리고 이들과의 미디어 흐름을 종료시키기 위한 신호로서 사용된다.

CallAcceptance는 또한 다음을 위한 메커니즘으로서 기능을 한다:

1. 피호출자 클라이언트의 중간 호 콜백(mid-call callback) URL을 CC로 전송하기 위한 피호출자 클라이언트

2. 중간 호 액션 URL을 호출자에게 전송하기 위한 호 컨트롤러

CallAcceptanceAcknowledgement는 다음을 위해 사용된다:

1. 중간 호 콜백 URL을 CC로 전송하기 위한 호출자 엔드포인트

2. 중간 호 액션 링크를 피호출자 엔드포인트로 전송하기 위한 CC

추가적으로, 클라이언트는 또한, CallAcceptance가 실제로 호출자 엔드포인트에 의해 확인되었다는 것을 보장하기 위한 트리거로서 CallAcceptanceAcknowledgement를 사용한다. 클라이언트가 합리적인 시간(예를 들면, 15초) 내에 CallAcceptanceAcknowledgement를 확인하지 못하면, 클라이언트는 CallAcceptance를 재전송할 수 있다.

S1 내지 S4는 단일 트랜잭션, 즉 통신 이벤트를 확립하기 위한 단일 트랜잭션을 구성한다. 초기 CallInvitationRequest에 응답하여, 호 컨트롤러(510C)의 단일 인스턴스가 전체 트랜잭션 S1-S4를 제어하도록 할당된다. 중간 트랜잭션 메시지가 호 컨트롤러의 동일한 인스턴스 상에 도달하는 것을 보장하기 위해, 그 트랜잭션과 관련이 있는 URL은, 클러스터 부하 밸런서 대신, 클러스터의 특정한 인스턴스를 다시 가리킨다. 상이한 트랜잭션에 관련이 있는 URL은 부하 밸런서를 가리킨다.

이것은 통신 이벤트에 대한 호 상태를 생성하는 것, 및 프로시져가 진행함에 따라 호 상태를 업데이트하는 것을 수반한다. 일단 호가 확립되면, 호 상태는 상기에서 설명되는 방식으로 컴퓨터 스토리지(608)에 저장되는데, 이 경우 호 컨트롤러 클러스터 내의 다른 호 컨트롤러 인스턴스가 컴퓨터 스토리지(608)에 액세스할 수 있다. 하기(섹션 2)에서 설명되는 바와 같이, 호 상태가 호 확립 프로시져의 종료 시 이 방식으로 저장될 수 있도록, 호 상태는 직렬화된다. 호 컨트롤러 인스턴스(510C)는 이 할당으로부터 해방된다. 즉, 통신 이벤트를 제어하는 것으로부터 해방된다. 여기서, "해방된다(released)"는, S1-S4를 달성하기 위해 이전에 점유되었던, 인스턴스(434C)가 실행 중인 프로세서의 물리적 리소스(프로세싱 리소스, 메모리 리소스)가 다시 이용 가능하게 된다는 것을 의미한다. 하기의 예에서, 이것은, 인스턴스의 런타임 상태가 직렬화되어 저장되면, 발생하고, 그 결과 다른 인스턴스는 런타임 상태를 다시 생성할 수도 있고 따라서 관련 서비스의 전달을 재개할 수 있다(섹션 2 참조).

본 교시의 근간을 이루는 원리 중 일부의 이해를 돕기 위해, 이제, 다양한 예시적인 신호 흐름이 설명될 것이다.

1A. URL:

URL을 나타내기 위해 다음의 표기법(notation)이 사용된다는 것을 유의한다:

- <동작>_<pointsTo>_url

여기서 "operation"은 URL과 관련이 있는 동작을 나타내며, "pointsTo"는 URL이 어떤 엔티티를 가리키고 있는지를 나타낸다, 즉, 그 url에 대한 액세스가 궁극적으로 어떤 엔티티를 검출하며 어떤 엔티티에 대해 동작하는지를 나타낸다. 하기에서, <pointsTo>는

- Alice(즉, Alice의 프록시 또는 디바이스)를 가리키는 URL의 경우 "Alice"이고;

- Bob의 프록시(즉, Bob의 프록시 또는 디바이스)를 가리키는 URL의 경우 "Bob"이고;

- 호 제어 서비스 로직을 가리키는 - 특정한 인스턴스 또는 부하 밸런서 중 어느 하나를 가리키는 - URL의 경우 "CC"이다.

아래의 예는 두 당사자간 호에 관련이 있다. 두 당사자간 호의 맥락에서, <pointsTo>는, 호 제어 서비스 로직(CC)을 가리키지만, 그러나 호 제어 서비스 로직에 의해 <유저> 예를 들면 Alice, Bob(다음 섹션 참조)를 가리키는 URL로 매핑되는 URL의 경우, 형태 "CC<유저>"를 갖는다.

1B. URL "재작성":

상기에서 언급되는 바와 같이, CC는 엔드포인트를 가리키는, 메시지에서의 URL을, 자신을 가리키는 URL로 재작성한다. CC가 <유저>를 가리키는 원래의 URL - 즉, <동작>_<유저>_url - 을, 자신을 가리키는 신규의 URL - 즉 <동작>_CC<유저> - 로 대체하는 경우, CC는, 원래의 URL과 신규의 URL 사이의 매핑을 클라이언트가 볼 수 없는 방식으로 저장한다. 따라서, 신규의 URL <동작>_CC<유저>에 대해 액세스 동작(예를 들면, 게시 또는 삭제)이 수행될 때마다, 이것은 CC에 의해 검출되고, 응답으로, CC는 원래의 URL <동작>_<유저>_url을 스토리지로부터 검색하고(retrieve), 원래의 URL <동작>_<유저>_url에 대해 적절한 동작을 수행한다.

따라서, 예를 들면:

- Alice로부터 Bob으로의 메시지가:

○ 제1 URL <동작1>_Alice_url(즉 Alice를 가리킴)을 포함하고, 그리고

○ 제2 URL <동작2>_CCBob_url(즉, CC를 가리킴)에 게시되지만 CC에서 제4 URL <동작2>_Bob_url(즉, Alice에게는 보이지 않는 방식으로 Bob을 가리킴)로 매핑되면;

- 그러면:

○ CC는 제1 URL을 제3 URL <동작1>_CCAlice_url(이제 CC(Alice가 아님)를 가리킴)로 대체하는 것에 의해 메시지를 수정하고, 그리고

○ 수정된 메시지를 제4(제2가 아님) URL <동작2>_Bob_url(Bob을 가리킴)에 게시한다.

이 방식에서, Bob이 Alice를 가리키는 임의의 URL의 직접적인 가시성을 절대 갖지 않는 것이 보장될 수 있고, 반대로도 보장될 수 있다, 즉, Alice 및 Bob의 에이전트가 통신 중개자로서 CC를 항상 사용하는 것을 보장하기 위해 필요로 되는 것은 재작성이 전부이다.

프로토콜은, 클라이언트와 호 컨트롤러 사이의 모든 통신이 요청-응답 기반으로 동작하는 것을 가능하게 한다 - 따라서, 프로토콜에 따라, 클라이언트는, 예를 들면, 그들이 프록시 서버(들)에게 하는 방식으로, 호 컨트롤러에 대한 임의의 종류의 개방형 접속을 유지할 필요가 없다.

이들 특정한 예에서, 게시(삭제)는 HTTP POST(DELETE) 방법을 사용하는 것을 의미한다.

본원에서 개시되는 프로토콜은 클라이언트들에게 유연성을 제공한다. 클라이언트는 다양한 메시지에서 사용하고자 하는 URL을 그것이 무엇이든 자유롭게 선택한다 - 단, 클라이언트가 이전에 자체적으로 제공되는 임의의 주어진 URL이 액세스될 때 어떤 동작이 요청되는지 알도록, 각각의 URL은 다른 관련 엔티티(클라이언트(들), 컨트롤러 등)에 의해 액세스될 수도 있어야 하고, 그 URL이 나타내는 동작에 고유해야 한다(즉, 단, URL이 모호하지 않도록 충분한 컨텍스트를 인코딩해 한다). 다시 말하면, URL이 액세스될 때 나중에 모호성을 유발하지 않도록 URL을 선택하는 것은 클라이언트 자신의 책임이다. 언급된 바와 같이, URL 재작성은, 호출자 URL이 호출자에게 직접적으로 보이지 않는 것 및 그 반대로 되는 것을 보장하는 것에 의해, 호출자와 피호출자 사이에 보안성의 레이어를 제공한다. 이것은, 클라이언트의 URL이 신뢰된 엔티티(즉, 호 컨트롤러)에게만 매번 공개된다는 그들의 URL에 대한 보안을 클라이언트가 유지해야 하는 부담을 덜어준다.

1.1. 예시적인 신호 흐름:

1.2.1 호 셋업 신호 흐름(피호출자에 의해 호가 수락되는 경우):

도 7의 성공적인 호 셋업 프로시져에 대한 시그널링 흐름은 도 8a에서 보다 상세히 도시된다. 두 개의 호 에이전트 사이의 성공적인 호 셋업은 다음 단계를 수반한다.

단계 S802에서, Alice의 호 에이전트(512Ca)(CA1)는 호 초대 요청 메시지(CallInvitationRequest)를 CC로 전송한다. 구체적으로는, CallInvitationRequest가 CC의 호 URL(call_url)에 게시되는데(즉, HTTP POST와 같은 게시 요청을 사용하여 전송되는데), CC의 호 URL(call_url)는, 예를 들면, 트래픽 매니저(232)를 사용하여, 어쩌면, 예를 들면, Alice의 클라이언트와 호환되는 호 컨트롤러 버전을 발견하기 위한 추가 협상을 통해 발견될 수도 있다. 메시지가 그 특정한 URL에 게시되었다는 사실은, 비록 메시지의 콘텐츠가 호를 확립하기 위한 추가 정보를 포함하지만, 메시지 콘텐츠에 관계없이 신규의 호가 소망된다는 것을 CC에게 말한다.

특히, 호 초대 요청은 피호출자(Bob)의 식별자(예를 들면, 유저명)를 포함하고, 피호출자가 소망하는 참가자이다는 것을 표시한다. 메시지는 그룹 호에 대한 다른 소망하는 참가자(들)의 식별자를 포함할 수도 있다. 이 메시지는 또한, Alice의 클라이언트가 지원할 수 있는 미디어 모달리티를 식별하는데, 예를 들면, 그것은 Alice의 클라이언트가 오디오 및 비디오를, 오디오만을 등을 지원할 수 있다는 것을 나타낼 수도 있다.

호 초대 요청은 다음의 링크(콜백 링크), 즉 URL을 포함한다:

- progress_Alice_url: Alice에 대한 호 진행 URL - 호 확립을 계속하는데 사용됨(S814 참조);

- mediaAnswer_Alice_url: 호 확립을 계속하는데 사용되는, Alice에 대한 미디어 응답 URL(S818 참조);

- acceptance_Alice_url: Alice에 대한 호 수락 URL - 호 미디어가 흐를 수도 있도록 호를 최종적으로 수락하기 위해 사용됨, 예를 들면 Bob이 수락할 것을, 즉, 호를 "받을 것을" 선택하는 것에 응답하여 액세스 됨(S828 참조);

- redirection_Alice_url: Alice에 대한 호 리디렉션 URL - 자동으로 또는 Bob에 의한 선택에 응답하여, 호를 재지향하기(redirect) 위해 사용됨(도 8c의 S842 참조);

- endNotification_Alice_url: Alice에 대한 호 종료 통지(end call notification) URL - Bob에 의해 수락되지 않았기 때문에, 또는 밥이 호를 받은 이후 끊었기 때문에, 호의 종료에 관해 Alice의 엔드포인트에게 통지하기 위해 사용됨(도 8d의 S836 참조).

이들 URL은 모두 서로 상이하지만, 그러나 모두 Alice의 프록시 서버를 가리킨다. 예를 들면, 이들은 형식 https://proxy.io/<Alice의 유저명>/<*>을 가질 수도 있는데, 여기서 <*>는 상이한 동작을 식별하는 상이한 컨텍스트 식별자를 나타낸다.

단계 S802는, CA1의 관점에서, 호 확립 프로시져의 제1 단계를 구성한다.

메시지는 또한, 미디어 협상, 예를 들면, Alice의 클라이언트/디바이스의 미디어 성능에 관한 정보와 같은 코덱 협상에 필요로 되는 임의의 데이터를 반송할(carry) 수도 있다. 메시지는, 참가자 업데이트 콜백 링크(update_Alice_url)와 같은 다른 유용한 정보를 포함할 수도 있다. 이것은 Alice의 프록시의 URL인데, CC는, 이 정보가 변경되면, 호 참가자의 업데이트된 목록을 Alice의 프록시의 URL로 게시할 수 있다.

S804에서, CC는 호 초대 응답 메시지(Call1nvitationResponse)로 CA1'의 호 초대에 응답하는데, 호 초대 응답 메시지(Call1nvitationResponse)는 CA1에 의한 사용을 위해 다음과 같은 콜백 링크를 포함한다:

- call_CC_url: 전체 호를 나타내는 호 URL - 호를 완전히 종료하는데 사용될 수 있음

- callLegAlice_CC_url: Alice와 CC 사이의 호의 레그(leg)를 나타내는 호 종료 레그 URL - Alice를 호 참가자로 제거하는데 사용할 수도 있음;

- participantInvitation_CC_url: CA1이 더 많은 참가자를 추가할 URL.

이들 URL은 CC를 가리킨다.

응답은, S802에서 CA1에 의한 성공적인 POST를 나타내는 "201 생성됨" 상태 코드를 갖는 HTTP 응답이다.

단계 S806에서, CC는 피호출자의 호 에이전트(512Cb)(CA2)로 호 통지 메시지(CallNotification)를 송신한다. 호 통지는 다음을 포함한다:

- 호에 접속하기 위해 CA2가 사용할 수 있는 접속 URL(attachBob_CC_url): S808에서 사용됨.

메시지는, S802의 호 초대 요청에 포함되는 식별자를 사용하여 송신되고, Bob의 프록시를 통해 진행한다.

다양한 모바일 시나리오에서, 엔드포인트는 착신 호 통지를 수신하기 위한 임의의 등록된 프록시 콜백을 갖지 않을 수도 있다. 그러나, 이들은 통지 받는 다른 방법을 가질 수도 있다 - 예를 들면 최신 윈도우/윈도우폰(windows modern/phone)용의 WNS, 안드로이드(Anroid)용의 구글 푸시 통지(Google Push Notification), iOS용의 APNS. CallNotification은 적절하게 재포맷될 수도 있고 Bob의 엔드포인트가 등록한 다양한 PUSH 채널을 통해 전송될 수도 있다. 일단 엔드포인트가 PUSH 통지를 수신하면, 엔드포인트는, 통지 블롭(Blob)이 주어지면, 자신이 해석할 수 있는 적절한 OS에 의해 기상될 것이고, 상응하게 작동할 것인데, 이렇게 하는 것은 이 경우에서는 다음을 의미한다:

1. 접속이 아직 존재하지 않으면, 프록시에 대한 접속을 확립한다;

2. attach_CC_URL 상에서 접속 요청을 전송한다.

응답으로, 단계 S808에서, CA2는 S806의 CallNotification 포함되는 attachBob_CC_url로 접속 요청 메시지(AttachRequest)를 게시한다 - 이것은 자동적이며, 예를 들면 Bob이 호를 수락할 것을 선택하는 것에 의존하지 않는다는 것을 유의한다. 접속 요청은 다음을 포함한다:

- Alice가 호를 종료하면 CC가 통지를 게시할 수 있는 Bob의 프록시 서버를 가리키는 URL(callNotification_Bob_url) - S848 참조.

단계 S810에서, CC는, 호 협상을 더 취하는데 필요로 되는 모든 데이터를 포함하는 접속 응답 메시지(AttachResponse)로 응답한다.

접속 응답 메시지는 "200 OK"상태 코드를 갖는 HTTP 응답이다.

접속 응답은 다음의 URL을 포함한다:

- progress_CCAlice_url

- mediaAnswer_CCAlice_url

- acceptance_CCAlice_url

- redirection_CCAlice_uri

상기의 모든 것에서 "CC"의 존재를 유의한다 - 이들 URL은 섹션 1B에 설명되는 URL "재작성" 프로시져에 따라 CC에 의해 생성되고, 다음의 URL에 대응하는데:

- progress_Alice_url

- mediaAnswer_Alice_url

- acceptance_Alice_url

- redirection_Alice_url

이들 URL은, 상기 섹션 1B에서 상세히 설명되는 CallInvitationRequest 메시지에서 S802에서 CA1에 의해 CC에 제공된다. CC는 Alice의 원래의 URL과 CC에 의해 상응하게 생성되는 대체 URL 사이의 매핑(900)을 저장하는데, 이렇게 하는 것은 도 9에서 예시된다.

S810의 AttachResponse 메시지는 S802의 CallInvitationRequest 메시지의 수정된 버전을 구성한다.

상기에서 언급되는 바와 같이, CC url은 두 당사자간 호에서만 Alice의 URL로 매핑될 것이다. 다자간 호의 경우, CC는, 협상을 핸들링하기 위해, 미디어 컨트롤러를 사용한다.

그것은 또한 다음을 포함한다:

- call_CC_url - (S804에서 Alice로 제공되는 바와 같은) 전체 호를 나타냄;

- callLegBob_CC_url - CC와 CA2 사이의 호의 레그(S804에서 Alice에게 제공되는 callLegAlice_CC_url에 상당함)를 나타냄.

단계 S812에서, CA2는, 그 다음, CC를 통해 CA1로 호 진행 업데이트 메시지(CallProgress)를 전송하기 시작한다. 메시지는 예를 들면 Bob의 클라이언트가 이제 호출음 상태에 진입했다는 것을 나타낼 수도 있다.

호 진행 업데이트는 progress_CCAlice_url에 게시되고 따라서 CC에 의해 수신된다. 이 예에서 호 진행 메시지는 어떠한 URL도 포함하지 않으며, 따라서, 호 진행 메시지의 콘텐츠는 CC에 의해 재작성되지 않는다. CC는 맵핑(900)에 액세스하여 progress_Alice_url을 검색하고, 메시지를, 그것이 Alice에 의해 수신되도록, 수정되지 않은 그 URL에 게시한다(S814).

단계 S816에서, CA2는, CallNotification 또는 AttachResponse에서 수신되는 미디어 공급(offer)에 응답하여 자신이 생성한 미디어 응답 메시지(MediaAnswer)를 전송한다. 미디어 응답 메시지는 mediaAnswer_CCAlice_url에 게시되며, Bob을 가리키는 다음의 콜백 URL을 포함한다:

- mediaAck_Bob_url, 하기의 S822에서 사용됨

mediaAnswer_CCAlice_url이 CC를 가리키기 때문에, 그것은 CC에 의해 수신된다. MediaAnswer에 포함되는 mediaAck_Bob_url이 Bob을 가리키기 때문에, CC는 CC를 가리키는 신규의 URL mediaAck_CCBob_url을 생성하고, mediaAck_Bob_url을 mediaAck_CCBob_url로 대체하기 위해 MediaAnswer를 수정한다. CC는 관련 매핑(900)에 액세스하여 mediaAnswer_Alice_url(CC 없음)을 검색하고, 수정된 All_alice_url에 수정된 MediaAnswer를 게시한다(S818). 이제, CA1은 URL mediaAck_CCBob_url을 갖는다. CC는 S822에서 사용하기 위한 신규의 맵핑(902)을 생성하는데, 신규의 맵핑(902)은 mediaAck_CCBob_url을 mediaAck_Bob_url(no CC)로 매핑한다.

단계 S820에서, 미디어 응답을 프로세싱한 이후, CA1은 CA2로 미디어 수신확인 메시지(MediaAcknowledgement)를 전송한다(S820). MediaAcknowledgement는 S818에서 수신되는 mediaAck_CCBob_url에 게시되고, 따라서 CC에 의해 수신된다.

이 예에서 MediaAcknowledgement는 Alice를 가리키는 어떠한 URL도 포함하지 않으며, 따라서 S822에서, CC는 mediaAck_Bob_url(CC 없음)로 수정되지 않은 MediaAcknowledgement를 게시한다(S822) - mediaAck_Bob_url(CC 없음)은 매핑(902)으로부터 검색됨.

MediaAcknowledgment는 Bob의 엔드포인트에게, Alice가 MediaAnswer를 수신했다는 것을 알려주고, 따라서 미디어 셋업은 성공적인 것으로 간주되고, 유저에게 호를 받기 위한 기회를 주기 위해 "호출음" UI가 묘사될 수 있다. 그것은 또한, Bob의 엔드포인트에게, MediaAnswer가 Alice의 엔드포인트로 성공적으로 전달되었다는 것, 그렇지 않다면, Bob의 엔드포인트가 (적절한 타임아웃, 예를 들면 15초 이후에) MediaAnswer를 재전송할 수 있다는 것을 알려준다.

이 시점에서, 미디어는 엔드포인트의 미디어 에이전트(512Ma1(MA1), 512Mb(MA2)) 사이를 흐를 수도 있고, 따라서 피호출자가 호를 받을 때, 미디어 셋업 지연은 없다.

피호출자가 호를 수락하는 것, 즉 호를 받는 것에 응답하여, 최종 호 수락 메시지(CallAcceptance)가 호 컨트롤러를 통해 CA1로 전송되는데, 최종 호 수락 메시지(CallAcceptance)는 CA2에 의해 acceptance_CCAlice_url에 먼저 게시되고(S826), 그 다음, CC에 의해 acceptance_Alice_url에 게시된다(S828).

CallAcceptance는 다음을 포함한다:

- callAccAck_Bob_url

이것은 동일한 방식으로 callAccAck_CCBob_url로 대체된다.

호 수락 페이로드를 프로세싱한 이후, CA1은 호 수락 수신확인을 callAccAck_CCBob_url에 게시하는데(S830), CC는 호 수락 수신확인을 callAccAck_Bob_url에 재게시한다. 응답으로, MA1과 MA2 사이에서 호 미디어(오디오/비디오)가 흐르기 시작한다(S823).

호를 받지 않은 임의의 엔드포인트의 호출음을 소거하기 위한 그리고 이들과의 미디어 흐름을 종료시키기 위한 신호로서 (다른 것들 중에서도) CallAcceptance가 사용된다.

CallAcceptance는 또한 다음에 의한 메커니즘으로 기능한다:

1. 중간 호 콜백 URL을 CC에 전송하기 위한 피호출자 클라이언트;

2. 중간 호 액션 URL을 호출자에게 전송하기 위한 호 컨트롤러.

CallAcceptanceAcknowledgement는 다음에 의해 사용된다:

1. 자신의 중간 호 콜백 URL을 CC로 전송하기 위한 호출자 엔드포인트;

2. 중간 호 액션 링크를 피호출자 엔드포인트로 전송하기 위한 CC.

추가적으로, 클라이언트는 또한, CallAcceptance가 실제로 호출자 엔드포인트에 의해 확인되었다는 것을 보장하기 위한 트리거로서 CallAcceptanceAcknowledgement를 사용한다. 클라이언트가 합리적인 시간(예를 들면, 15초) 내에 CallAcceptanceAcknowledgement를 확인하지 못하면, 클라이언트는 CallAcceptance를 재전송할 수 있다.

1.2.2 피호출자 호를 받지 않음:

피호출자가 착신 호를 거부하는 시나리오가 도 8b에 예시된다. 이 시나리오에서, 프로시져는 상기에서와 같이 S802로부터 S810으로 진행한다. 그러나, CA2가 호에 접속한 이후, S806에서 제공되는 URL callLegBob_CC_url에 대한 삭제 요청을 사용하여 호 종료 레그 메시지를 전송하는 것에 의해 착신 호는 (호 셋업 이전에) 피호출자에 의해 거부된다(S834). 거부는, S802에서 Alice에 의해 제공되는 endNotification_Alice_url에 CC가 거부 통지 메시지를 게시하는 것에 의해 Alice에게 통지된다(S836).

이것은 단지 예에 불과하다는 것을 유의한다 - 피호출자는, 예를 들면, 도 8a의 S832 이후, 또는 attachReponse와 CallAcceptance 사이의 임의의 시간에 S834가 발생할 수 있도록, (도 8a에서와 같이) 피호출자를 수락했던 호로부터 자신을 제거할 수 있다. 이렇게 하는 것은, 두 당사자간 호를 종료할 것이지만, 다자간 호는 종료하지 않을 것이다.

S834는, 피호출자가 그들의 클라이언트 UI를 통해 거부 옵션을 선택하는 것에 응답하는 것일 수도 있거나, 또는, 예를 들면 Bob이 착신 호를 자동적으로 거부하도록 자신의 클라이언트를 구성했다면, 그것은 자동일 수도 있다.

1.2.3 피호출자 요청 리디렉션:

도 8c는 피호출자의 클라이언트(CA2)가 호를 상이한 타겟 유저에게로 재지향하는 시나리오를 예시한다. 상기 프로시져는 상기에서와 같이 S802로부터 S810으로 진행한다. 착신 호는 CA2가 redirection_CCAlice_uri에 재지향 메시지를 게시하는 것에 의해 재지향된다(S838) - 이 URL은 CC에 의해 S810에서 제공되었음. 재지향 메시지는 상이한 타겟 유저를 (예를 들면, 유저명에 의해) 식별한다. 이것은 CC에 의해 수신되고 redirection_Alice_uri에 게시된다(S840) - 이것은 S802에서 CA1에 의해 제공됨. 이렇게 하는 것은, 호출자가 제공된 타겟과 신규의 호를 생성하는 것으로 귀결된다(S842). S842는 S802에 상당하지만 그러나 신규의 타겟 유저에 대한 것이고, 이후에는 프로세스는 동일한 방식으로 진행한다. 신규의 호 초대 메시지는, 상이한 호 컨트롤러(523C)로 지향되는 것으로 도시되지만, 다른 예에서는 이것은 그렇지 않을 수도 있다.

S838은, 피호출자가 자신의 클라이언트 UI를 통해 호 재지향 옵션을 선택하는 것에 응답하는 것일 수도 있거나, 또는 자동일 수도 있다.

S838로 시작하는 호 리디렉션 프로시져는, AttachResponse를 수신하는 것(S810)과 호 수락 또는 CallEnd를 전송하는 것(또는 CallEnd 통지를 수신하는 것) 사이의 임의의 시간에 행해질 수도 있다.

1.2.4 호출자가 호를 취소함:

도 8d는, 예를 들면, 호출자가 그들의 클라이언트 UI를 통해 호 종료 옵션을 선택하는 것에 응답하여, 호출자의 클라이언트(CA1)가 호를 종료하는 시나리오를 예시한다.

호출자는 임의의 시간에 - (이 예에서와 같이) 발신 호가 셋업되기 이전이라도 - 발신 호를 종료할 수도 있다. 이 예에서, 프로세스는 상기에서와 같이 S802로부터 S822로 진행한다.

호를 종료하는 것은, 전체 호를 나타내는 URI call_CC_url에 대한 삭제(예를 들면, HTTP DELETE) 요청을 사용하여 CA1이 호 종료 메시지를 전송하는 것에 의해 달성되고, 단계 S804에서 제공된다(S846). CA2는 S808에서 CA2에 의해 제공되는 URL callNotification_Bob_url에 CC가 호 종료 통지를 게시하는 것에 의해 통지된다(S848).

다자간 호의 경우, CC는 명단을 업데이트할 것이고(Alice를 제거함), 나머지 참가자에게 POST participantUpdate 메시지를 전송할 것이다.

(피호출자에 의한) 호 종료와 (호출자에 의한) 호 취소 사이의 구별은 예를 들면 SIP와는 상이하다. SIP에서는, 두 가지 방법이 있다:

1. 취소 - 아직 수락되지 않은 호를 종료하기 위해 호출자에 의해 전송됨

2. BYE - 수락된 호를 종료하기 위해 임의의 참가자에 의해 전송됨

이들 두 가지 방법을 갖는 것은, 상태 머신 구현에서 모호성을 야기하고, SIP가 경쟁 조건에 취약해지게 만든다(취소(Cancel)가 프로세싱되고 있는 동안 호가 수락될 수도 있고, 그 시점에서 일부 엔티티는 취소를 BYE로 변환해야 하기 때문임).

현재의 프로토콜은, 호를 종료하는(DELETE callLeg_CC_URL), 그리고 호 종료에 대한 통지를 얻는(POST endNotification_<유저>_URL) 단지 하나의 모호하지 않은 방법을 갖는 것에 의해 이 문제를 완전히 방지한다. 이들은, 접속되지 않은 상태이든 또는 접속된 상태이든 호의 상태가 무엇이든 간에, 사실이다.

상기에서는 두 당사자간 호를 고려한다는 것을 유의한다. 다자간 호의 경우, Alice에 의해 수행되는 동작은 다른 측의 임의의 특정한 유저에게 전달되지 않지만, 그러나 호 컨트롤러에 의해 직접적으로 핸들링된다. 예를 들면, Alice가 다자간 호에서 미디어 재협상을 수행하면, 미디어 응답이 미디어 컨트롤러(Media Controller)에 의해 생성되고, 다른 참가자는 (비록 이들이 명단 업데이트를 통해 간접적으로 알 수도 있지만) 어떠한 변경도 직접적으로 인식하지 못하게 된다.

다중 당사자 호의 경우, 호 컨트롤러를 가리키는 링크는 다른 참가자의 URL에 직접적으로 매핑될 수 없다. 호 컨트롤러는 "미디어 컨트롤러"와 같은 다른 서버와 상호 작용하여 자신의 링크 상에서 얻는 요청에 대해 동작할 수도 있다.

1.3 확립된 호에 대한 신규의 트랜잭션:

도 8a의 시그널링 흐름은, 용어가 상기에서 정의된 바와 같은 단일 트랜잭션을 구성한다. 거기에서 수행되는 모든 CC 기능성은 동일한 호 컨트롤러 인스턴스에 의해 수행된다(이것이 필수는 아니다 - 상기 참조). 단계 S832에서 호 수락 수신확인을 관련시킨 이후, 호에 대한 직렬화된 상태 데이터가 관련 호 컨트롤러 클러스터(섹션 2 참조)의 공유 스토리지에 저장되고, 그 인스턴스는 해제된다(released). 도 8b(호 종료)의 경우, 이것이 발생한 이후 - 즉, 호 컨트롤러 인스턴스가 해제된 이후 - 호를 종료하기 위한 단계 S834가 개시될 수도 있다. 도 8c의 S838 및 도 8d의 S846에 대해서도 마찬가지이다.

또한, 도 8a의 시그널링 프로시져에서는, 단계 S804에서, CA1은 Call1nvitationResponse에서 URL participantInvitation_CC_url을 제공받는다. CA1은, 예를 들면, 호 동안의 임의의 시간에 participantInvitation_CC_url에 참가자 추가 메시지를 게시하여 신규의 참가자를 추가할 수 있다. 이것은, 신규로 초대된 참가자에 대한 것을 제외하면, S806-S826과 유사한 시그널링의 흐름을 트리거한다. 결국, CC는 신규의 참가자가 추가되었다는 것을 나타내기 위해 S802에서 제공되는 URL update_Alice_url에 대한 업데이트 메시지를 CA1에 게시할 것이다.

호의 확립을 핸들링하는 원래의 인스턴스가 해제되어 호 상태를 직렬화한 이들과 같은 호 내 동작의 경우, 클러스터 내의 임의의 호 컨트롤러 인스턴스는 호 내 프로세싱을 핸들링하도록 할당될 수 있을 것이다. 섹션 2는 이것을 가능하게 하는 메커니즘을 제시한다.

1.3 투명한/독립적으로 확장 가능한 프록싱(Scalable Proxying):

이 프로토콜에 의해 제공되는 유연성은 (예를 들면, 상기 프록시 서버(602)에 의해 제공되는 바와 같은) 프록시 서비스와의 클라이언트의 원활한(seamless) 통합을 제공한다. 예를 들면, 클라이언트는, 단순히, 프록시 향해 가리키도록 자신이 제공하는 URL을 변경하는 것 - 메시지 콘텐츠에 대한 변경은 없음 - 에 의해 프록싱(즉, 프록시를 통해 메시지를 수신하는 것)과 직접적인 메시지 수신 사이를 전환할 수 있거나, 또는 기저의 시그널링 프로토콜이 필요로 된다. 또 다른 예로서, 클라이언트는 비슷한 용이성으로 프록시 사이를 전환할 수 있다.

프로토콜은, 예를 들면, 호 컨트롤러로부터 프록시 서비스를 분리하는(decoupling) 것에 의해, 독립적인 확장성(scalability)을 제공한다.

예를 들면, 하나의 실시형태에서, 프록시 서버(602)가 프록시 서비스를 제공하고 있는 클라이언트에 필요한 수의 개방(예를 들면, 웹 소켓) 접속을 유지할 수 있기 위해서는 프록시 서버(602) 상에서 리소스가 필요로 된다; 그러나 프로토콜은 클라이언트와 호 컨트롤러 사이의 통신이 요청-응답(예를 들면, HTTP) 기반으로 동작하는 것을 허용하기 때문에 호 컨트롤러는 이러한 리소스를 필요로 하지 않는다.

따라서, 통신 시스템(200) 내에서 추가적인 프록시 서버 리소스가 요구되는 경우, 예를 들면 유저 기반(user base)이 성장하고 그 결과 증가하는 유저 기반(user base)에 프록시 서비스를 제공하기 위해 더 많은 수의 예를 들면 웹소켓 접속이 통신 시스템 내에서 동시에 유지될 필요가 있음에 따라, 프록시 서비스는 이 목적을 위해 호 컨트롤러와는 독립적으로 확장될 수 있다.

일반적으로, 통신 시스템(200) 내에서, 물리적 리소스는, 이들 클라이언트에 제공되고 있는 프록시 서비스와 독립적으로, 클라이언트에게 서비스를 제공하는 컨트롤러(예를 들면, 호/미디어 컨트롤러)에 할당될 수도 있다.

하나의 예에서, 프록시 서비스(예를 들면, 프록시 서버(602))는, 클라우드 플랫폼(100), 및 컨트롤러 및 프록시 서비스에 할당되는 리소스 상에서 (예를 들면, 클러스터 내의 VM의 수를 스케일링하는 것에 의해, 신규의 서비스 배치를 생성하는 것에 의해, 등에 의해) 동일한 방식으로, 그러나 컨트롤러에 대한 물리적 리소스의 허여가 독립적이고 프록시 서버(들)에 대한 물리적 리소스의 허여와는 상이하도록 독립적으로 애플리케이션으로서 구현될 수 있을 것이다.

1.4 상이한 성능을 제공하는 프록시 서버의 체인의 투명한 생성:

1.4.1 호 컨트롤러 프록시의 투명한 추가:

상기 섹션 1B에서 설명되는 URL 재작성 메커니즘은, 예를 들면 높은 가용성을 투명하게 제공하기 위해, 메시지가 하나의 엔드포인트에서 다른 엔드포인트로 이동함에 따라 연속적인 URL 재작성 동작이 발생하는 일련의 컨트롤러에 적용될 수 있다.

도 10은 CA1과 CA2 사이의 메시지가 3 개의 호 컨트롤러 배치(523C1(CC1), 523C2(CC2) 및 523C1(CC3))를 가로지르는 예를 도시한다. CA1은 Alice를 가리키는 콜백 URL <옵션>_Alice_url을 포함하는 메시지를 CC1로 지향시킨다. CC1은 이것을 대신 자신을 가리키도록 재작성하고, 재작성된 URL <옵션>_CC1Alice_url을 메시지의 제1 수정된 버전에서 CC2로 제공한다. CC1은 <옵션>_Alice_url과 <옵션>_CC1Alice_url 사이의 매핑(900.1)을 저장하였다.

CC2는 자신을 가리키도록 이 URL <옵션>_CC1_Alice_url을 재작성하고, 수정된 URL <옵션>_CC2Alice_url을 메시지의 제2 수정된 버전에서 CC3으로 제공한다. CC2는 URL <옵션>_CC2Alice_url과 URL <옵션>_CC1Alice_url 사이의 매핑(900.2)을 저장하였다.

CC3은 자신을 가리키도록 이 URL <옵션>_CC2_Alice_url을 재작성하고, 수정된 URL <옵션>_CC3Alice_url을 메시지의 제3 수정된 버전에서 CA2로 제공한다. CC3은 URL <옵션>_CC2Alice_url과 URL <옵션>_CC1Alice_url 사이의 매핑(900.3)을 저장하였다.

따라서, 메시지는 3 개의 호 컨트롤러(CC1, CC2 및 CC3)의 체인을 가로 지르고, 통신 시스템을 CA1에서부터 CA2로 가로 지름에 따라 3 개의 별개의 URL 재작성 동작을 받는다.

CA2가, 예를 들면, 응답을 <옵션>_CC3Alice_url에 게재하는 것에 의해, Alice의 메시지에 응답하는 경우, 응답은 먼저 CC3으로 이동하고, (매핑(900.3)에 의해) 거기에서부터 CC2로, (맵핑(900.2)에 의해) 거기에서부터 CC1로, 그리고 최종적으로 (맵핑(900.1)에 의해) CA1로 이동한다.

CC2는 이 체인의 중간에 위치하며, 따라서 CA1 및 CA2에게는 완전히 보이지 않는다 - CA1 및 CA2가 언제나 보는 모든 것은, CC1 및 CC3을 각각 가리키는 URL이다; 그들은 CC2를 가리키는 어떠한 URL도 보지 못한다.

이것은, 도 10의 하반부에서 도시되는 바와 같이, 호 컨트롤러 배치(CC2)가 신규의 호 컨트롤러 배치(CC4)로 대체될 수 있다는 것을 의미한다. 필요로 되는 모든 것은 다음과 같다:

- <옵션>_CC2Alice_URL을, CC4를 대신 가리킨다는 것을 제외하면 등가인 URL <옵션>_CC4Alice_URL로 대체하기 위해 자신의 매핑(900.3)을 수정하는 CC3, 및

- 메시지를 CC2 대신 CC4로 재지향시키기 시작하는 CC1.

이들 변경을 통해, 이후에 (CA1에 의해) <옵션>_CC1Alice_URL로 또는 (CA2에 의해) <옵션>_CC3Alice_URL로 지향되는 모든 메시지는 CA2 대신 CA4를 통해 이동한다. 따라서, 배치 CA2는, 엔드포인트(CA1과 CA2)에게 완전히 보이지 않는 방식으로 CA4로 교환되었다 - 즉, CA1과 CA2는 그들 파트에서 아무런 액션도 필요하지 않으며, 이것이 발생했다는 것을 그들은 알 필요가 없다.

1.4.2 높은 가용성의 투명한 제공:

콜백은 클러스터 부하 밸런서를 가리킬 수 있거나 또는 특정한 인스턴스를 가리킬 수 있거나 또는 심지어 프로토콜을 변경하지 않고 다수의 데이터센터에 걸쳐 있는 트래픽 매니저를 가리킬 수도 있어서, 호 컨트롤러가 높은 가용성을 적절히 투명하게 제공하는 것을 허용한다. 호 전체에 걸쳐, 예를 들면, 개별 인스턴스, 클러스터 부하 밸런서 및 트래픽 매니저를 가리키는 콜 백 사이에 자유 스위치(freedom switch)가 존재한다.

예를 들면, 호 컨트롤러 배치가 시스템 사용량이 많은 시간에 과부하 상태가 되면, 신규의 배치가 생성될 수 있으며, 이들 호 중 일부는 클라이언트에게는 완전히 투명한 방식으로 신규의 배치로 전환된다.

예를 들면, 도 10의 예에서, 호 확립, 호 내 트랜잭션의 핸들링, 등과 같은 모든 주요 호 제어 기능은 CA2 또는 CA4에 의해 핸들링된다 - CC1 및 CC2는 단지 투명 인터페이스로서 작동한다. 즉, CC1과 CC3은, 각각 Alice와 Bob의 클라이언트에게, 그들이 실제 호 컨트롤러인처럼 '가장한다'(즉, 핵심적인 호 제어 기능을 수행한다). 다른 예에서, 호 제어 기능성은 상이한 호 컨트롤러 배치 사이에서 공유될 수 있을 것이다.

CC1과 CC3은 예시를 보조하기 위해 별개의 배치로서 도시되지만, 그러나 실제로는 동일한 배치가 CC1과 CC3 둘 다의 기능을 수행할 수 있을 것이다, 즉, CC2/CC4가 단일의 배치 뒤에서 클라이언트에게 숨겨질 수 있을 것이다.

인식될 수 있는 바와 같이, 이러한 연속적인 URL 재작성 메커니즘은 임의 길이의 컨트롤러 체인에 적용될 수 있다.

본원에서, "클라이언트로 메시지를 송신하는 것"(또는 등)은 메시지의 콘텐츠를 수정할 수도 있는 서버(들)를 통해 메시지를 송신하는 것을 포함한다는 것을 유의한다.

1.4.3 프록시 체인화의 추가적인 용도:

프록시의 체인은 다른 기능성을 구현하는데 사용될 수 있다; 몇몇 예는 다음과 같다.

메시지 기록 솔루션(message logging solution)(호 에이전트와 호 컨트롤러 사이에서 전송되고 수신되는 모든 메시지를 기록함)을 생성하기 위해, 호 컨트롤러인 것처럼 '가장하는', 그리고 클라이언트로부터 임의의 메시지의 수신시 다음의 동작을 행하는 프록시 서버가 생성된다:

a. 메시지를 기록한다(log);

b. 클라이언트가 제공한 콜백 URL을, 프록시 서버를 가리키는 콜백 URL에 매핑하는 사전(dictionary)을 만든다;

c. 프록시 서버를 가리키도록 메시지 본문의 콜백 URL을 업데이트한다;

d. 업데이트된 메시지를 "실제"호 컨트롤러로 전송한다.

마찬가지로, 클라이언트와 호 컨트롤러 사이에 프록시를 삽입하고 그것이 호 수명 및 업데이트를 추적하게 하는 것에 의해 과금 솔루션이 생성될 수도 있다.

각각의 액션을 검증하는 프록시를 클라이언트와 호 컨트롤러 사이에 삽입하는 것에 의해 인증 솔루션이 생성될 수도 있다.

추가적으로, "실제" 호 컨트롤러가 아니라 클라이언트에 의해서만 이해될 필요가 있는 신규의 성능을 추가하는 신규의 프록시 서버가 생성될 수도 있다. 이것은, (호 컨트롤러가 이해하는 기본 세트를 넘어서는) 추가적인 링크 및 메시지 컨텐츠를 이해할 수 있고 추가할 수 있는 신규의 성능을 클라이언트가 프록시 서버에게 말하게 하는 것에 의해 달성될 수 있다.

2. 컨트롤러 인스턴스의 높은 가용성:

2.1 서론:

시스템 실패의 경우에도, 클라우드 컨트롤러의 높은 가용성을 제공하는 메커니즘이 하기에서 제시된다. 이들은 호 컨트롤러의 맥락에서 설명되지만, 그러나 본 기술은 다른 타입의 클라우드 서비스에(예를 들면, 미디어 모달리티 컨트롤러에) 적용될 수 있다.

호 컨트롤러는, 예를 들면, 네트워크/전력 인프라에서의 실패, 또는 소프트웨어 실패로 인해, 대형 데이터센터에서 꽤 일반적인 머신 고장에도 불구하고 눈에 띄는 서비스 중단을 유저가 인지하지 못하는 것을 보장하기 위해, 높은 신뢰성 및 가용성을 필요로 하는 클라우드 기반 서비스이다.

높은 가용성 뒤에 있는 기본 아이디어 중 하나는, 유저에게 서비스를 제공하는 머신의 클러스터(상기 참조)를 갖는 것, 및 몇몇 인스턴스가 다운될 때, 유저의 요청이 살아있는 다른 인스턴스에 의해 서비스되는 것을 보장하는 것이다.

(호 컨트롤러의 관점에서) 이 문제점에는 두 가지 측면이 있다.

1. 클러스터에서의 인스턴스의 서브세트의 실패는, 유저가 신규의 호를 신청을 할 수 없게 되는 것으로 귀결되어선 안된다:

2. 클러스터에서의 인스턴스의 서브세트의 실패는, 진행 중인 호 실패로 귀결되어선 안된다.

첫 번째 문제점은, (Azure와 같은) 클라우드의 PaaS(Platform as a Service; 서비스로서의 플랫폼) 성능을 사용하는 것에 의해, 그리고 신규의 요청이 살아있는 인스턴스로 진행하는 것을 보장하는 부하 밸런서(상기 참조)가 앞장서는 클러스터를 생성하는 것에 의해 해결될 수 있다. 즉, 해결할 첫 번째 문제점은, 머신 오류가 전체적인 운전 중지로 귀결되지 않는다는 것을 보장하는 것이다. 이 문제점은 클러스터링을 사용하여 해결될 수 있다. 호 컨트롤러 배치는, 트래픽이 살아있는 인스턴스로 라우팅되는 것을 보장하는 부하 밸런서가 앞장서는 많은 인스턴스를 포함한다. 클라이언트는 부하 밸런서와 대화하고, 따라서 개별 인스턴스의 실패에 의해 거의 영향을 받지 않는다. 접속에서 약간의 일시적인 오류는, 일시적인 오류를 담당하는 클라이언트 측 재시도에 의해 핸들링된다.

이것은, 호 생성 요청이 살아있는 인스턴스에 자동적으로 도달하기 때문에, "신규의 호"에 대해 높은 가용성을 제공하기에 충분하다. 그러나, 그것은 진행 중인 호에 대해서는 충분하지 않은데, 그 이유는 (오디오 전용 호에 비디오를 추가하는 것, 또는 호를 보류 상태로 두는 것과 같은) 중간 호 커맨드가 살아있는 인스턴스에 도달하는 것을 보장하기에는 그것이 충분하지 않기 때문이다. 또한, 호의 런타임 상태가 적절히 복구되어, 중간 호 커맨드가 적절히 실행될 수 있어야 하는 것을 보장하는 것도 필요하다.

이 문제점을 해결하기 위한 하나의 방식은, 섹션 1에 제시되는 것들과 같은 모든 콜백 링크(진행중인 호에 대해 호 컨트롤러에서 호출될 수 있는 명령에 대응함)를 특정한 인스턴스에 결부하고(tie), 그에 따라, 모든 런타임 상태가 이미 존재하고(즉, 활성 상태이고), 그 결과 중간 호 커맨드가 적절히 실행될 수 있다는 것을 보장하는 것이다. 그러나, 이것은 높은 가용성을 손상시키는데, 그 이유는, 그 인스턴스의 실패가 호의 실패로 이어질 것이기 때문이다.

다른 솔루션은 다음의 것일 것이다:

1. 중간 호 액션에 대한 콜백 URL이, 임의의 특정한 인스턴스 대신, 클러스터부하 밸런서를 가리킨다는 것을 보장한다.

2. Azure Table Store와 같은 가용성이 높은 외부 저장소에 서비스의 런타임 상태를 저장한다. 그러나, 다음과 같은 이유 때문에 이것만으로는 충분하지 않다.

a. 서비스의 런타임 상태는 복잡하고, 매우 복잡한 객체 그래프 중에 분산된다. 그러한 만큼, 외부 저장을 위해 이 그래프를 쉽게 직렬화하는 것은 쉽지 않으며, 외부 데이터를 기반으로 이 그래프를 재구성하는 것도 쉽지 않다;

b. 다수의 머신이 동일한 런타임 상태에서 동시에 작동할 수도 있고, 데이터의 일관된 뷰에 쉽게 동의할 수 없을 수도 있다. 예를 들면, 호출 서비스의 경우, 참가자 추가 요청(add participant request)은 하나의 인스턴스에 도달할 수도 있지만, 반면 참가자 삭제 요청(delete participant request)은 다른 인스턴스에 도달할 수도 있으므로, 양 인스턴스가 최종 결과에 동의하는 것을 필요로 한다. 이 문제점은, 널리 공지된 동기화 프리미티브를 사용하는 것에 의해 전통적인 프로그래밍에서 해결될 수 있지만, 이들은 더 이상 분산 환경에서는 작동하지 않는다.

다음 섹션은, 클러스터 내의 임의의 인스턴스가 중간 호 커맨드를 핸들링할 수 있다는 것을 보장하기 위해 사용될 수 있는 방법론을 다룰 것이다. 먼저, 예시를 보조하기 위해, 런타임 상태의 개념을 둘러싼 몇몇 상황이 설명될 것이다.

2.2 런타임 상태:

객체 지향 프로그래밍(Object Oriented Programming; OOP)의 맥락에서, 컴퓨터 프로그램(즉, 코드)은 객체 클래스를 정의할 수 있다. 클래스는 특정한 타입의 객체에 대한 템플릿이며, 클래스는 프로세서 상에서 인스턴스화되어 프로세서 상에서 (논리적인) 객체를 생성한다. 객체는 상태, 즉 프로세서의 메모리의 일부 위치(들)에서 유지는 상태 데이터, 및 거동, 즉 실행가능 코드와 관련되는 거동을 갖는다. 객체는 클래스의 구체적인 인스턴스로 볼 수 있다. 동일한 타입의 다수의 객체를 생성하기 위해, 템플릿은 여러 번 인스턴스화될 수 있다.

런타임 객체 그래프는 임의의 동작을 프로세싱하는 결과로서 생성되고, 많은 방식으로 서로를 참조하는 다양한 논리 객체로 형성된다.

예를 들면, 간단한 예시적인 컴퓨터 프로그램은 다음과 같이 객체 클래스를 정의할 수도 있을 것이다:

여기서 A는 B를 참조하고(그것이 타입 B의 멤버를 가지기 때문임), B는 C를 참조하는데, C는 다시 A를 참조한다. 이들 모든 객체 타입은 또한, 그들의 상태에서 약간의 간단한 일반적이고 오래된 데이터타입, 즉 클래스 A의 정수 변수 x, 클래스 B의 경우 문자 스트링 변수 y, 및 클래스 C의 경우 부울 변수 z를 갖는다.

이하에서, 표기 InstanceOf(<클래스>)는 프로세서 상에서 객체 클래스 <클래스>를 인스턴스화하는 것에 의해 생성되는 활성 객체를 의미하는데, 프로세서가 직접 액세스하는 프로세서의 메모리(414)에서 그것이 실현된다는 점에서 활성이다.

이들 클래스의 인스턴스화는 도 11a에서 개략적으로 표현되는 객체 그래프 G를 생성한다. 즉, 각각 클래스 A, B 및 C의 인스턴스인 객체 ObA, ObB, ObC는 객체 그래프 G를 형성한다. 클래스가 서로를 참조하는 방식 때문에, 객체 그래프 G는 ObA로부터 ObB로의, ObB로부터 ObC로의, ObC로부터 ObA로의 에지를 갖는 것으로 보일 수 있다.

순전히 예로서, 도 11b는 상기에서 정의된 클래스를 인스턴스화하는 것에 의해 생성되는 객체 그래프 G가 프로세서 메모리(414)에서 어떻게 구현될 수도 있을 것인지를 도시한다. 물론, 객체 인스턴스가 구현되는 정확한 방식은 컴파일러 및 플랫폼 구현 세부 사항에 의존할 것이다.

이 예에서:

- ObA는 메모리(114)의 위치 addrO에서 유지되는 메모리 포인터(참조) p4, 및addrO+4(이 예에서는 각각의 메모리 위치는 4 바이트를 가짐)에서의 변수 x의 값으로 실현된다;

- ObB는 addrP에서 유지되는 메모리 포인터 p4, 및 addrP+4에서의 y의 값으로 실현된다

- ObC는 addrQ에서 포인터 p3, 및 addrQ+4에서의 z의 값으로 실현된다.

addrO+4, addrP+4, addrQ+4에서의 x, y 및 z의 값은, 각각, 객체 ObA, ObB 및 ObC의 상태 데이터를 구성한다.

포인터 p1, p2, p3은 객체 사이의 참조가 실현되는 메커니즘이다: p1은, 메모리(114)에서 ObB가 실현되는 addrP를 가리키고; p2는, 메모리(114)에서 ObC가 실현되는 addrQ를 가리키고; p3은, 메모리(114)에서 ObA가 실현되는 addrO를 다시 가리킨다.

클래스 정의의 복잡성 및 다른 클래스를 참조하는 더 많은 클래스가 더 정의됨에 따라, 결과적으로 나타나는 객체 그래프는, 더 많은 객체가 생성됨에 따라 길이가 길어질 가능성이 있는 포인터의 길고 복잡할 수 있는 체인을 가지기 쉽다는 것을 알 수 있다.

참조가 본질적으로 메모리 내(in-memory) 포인터로서 실현된다는 사실은, 그들을 직렬화하는 것을 본질적으로 어렵게 만든다. "직렬화"는, 프로세서의 메모리에서 실현되는 객체 그래프(예를 들면, R')를, 외부 스토리지에, 예를 들면 파일 또는 메모리 버퍼에 저장될 수 있는 또는 네트워크 접속 링크를 통해 송신될 수 있는, 그리고, 동일한 또는 다른 컴퓨터 환경에서 나중에 재구성될 수 있는 포맷으로 변환하는 프로세스이다. 결과적으로 나타나는 일련의 비트가 직렬화 포맷에 따라 다시 읽혀지는 경우, 그것은, 동일한 프로세서의 또는 다른 프로세서의 메모리에 있는 원래 객체의 의미상 동일한 복제본(clone)을 생성하는데 사용될 수 있다.

2.3 객체 그래프 부활(resurrection):

본 개시는, 매우 복잡한 컴퓨터 프로그램에 대해서도 직렬화 가능하게 유지되는 런타임 상태를 생성하기 위한 일반적인 프레임워크를 제공한다. 프레임워크는 객체 클래스가 컴퓨터 프로그램 내에서 정의되는 방법, 특히 객체 클래스가 서로를 참조해야 하는 방법을 지시한다. 참조의 이 시스템이 준수되면, 이들 클래스가 인스턴스화될 때 생성되는 결과적으로 나타나는 객체 그래프는, 그들이 얼마나 복잡한지에 관계없이, 쉽게 직렬화 가능하게 유지된다.

섹션 2에서, 다음의 것이 제시된다:

1. 전체 런타임 객체 그래프를 직렬화 가능한 방식으로 표현하기 위한 기술;

2. 직렬화된 상태가 주어지면 객체 그래프를 재생성하기 위한 기술;

3. 그래프의 필수 부분이 다시 생성될 수 있는, 객체를 가리키는 (섹션 1에서 사용되는 바와 같은) 콜백 링크를 생성하기 위한 기술;

4. 부활이 스택 오버플로우를 야기하지 않는다는 것을 보장하기 위한 기술.

섹션 3에서, 다음의 것이 개시된다:

5. 일관성을 보장하기 위해 객체 그래프의 단일 부활을 보장하기 위한 기술

6. 전체 클러스터에서의 모든 인스턴스의 상태에 대한 최신 지식을 유지하기 위한 기술;

7. 직렬화된 상태 데이터에 대한 가상 저장소를 생성하는 것에 의해 직렬화된 상태 데이터의 판독/기록을 최적화하기 위한 기술.

통상적인 서비스의 런타임 상태는 서로를 참조하는 다수의 객체를 포함한다. 이들 객체는 함께 활성 객체 그래프를 형성하고, 서비스 기능성 - 예를 들면, 호 컨트롤러 기능성 - 을 수행하기 위해 서로 조정한다. 호가 수립되면, 호 확립 프로시져가 진행함에 따라 객체 그래프가 생성되고 수정된다. 객체 그래프는, 객체 그래프가 호의 현재 상태에 관한 모든 정보를 구체화한다는 점에서, 호에 대한 호 상태를 구성한다. 하기에서 더 상세히 설명되는 바와 같이, 일단 호가 확립되면, 객체 그래프는 직렬화되어 컴퓨터 스토리지에 저장되는 직렬화된 상태 데이터를 생성하는데, 객체 그래프는, 직렬화된 상태 데이터로부터, 나중의 시간에(재활성화시) 그 프로세서 또는 다른 프로세서 상에서 재구성될 수 있다.

서비스, 예를 들면, 호 제어 서비스, 매체 제어 서비스는, 각각이 각각의 서비스 함수(service function)(들)를 구현하고 어떤 형태의 상태 데이터(서비스 객체)를 갖는 다수의 협력 객체에 의해 전달된다. 서비스 클래스는 서비스 객체에 대한 템플릿을 정의하는 클래스를 의미한다. 서비스 클래스는, 예를 들면, 서비스 객체를 생성하기 위해 서비스 클래스가 인스턴스화될 때 값이 할당되는 하나 이상의 변수를 정의하는 것에 의해, 각각의 서비스 함수(들) 및 상태 데이터의 구조를 제공(정의)한다(값은 상태 데이터를 구성한다). 서비스 함수는 상태 데이터에 기초하여 구현되며, 상태 데이터를 또한 수정할 수도 있다.

높은 가용성을 요구하는 분산 시스템의 경우, 이 객체 그래프는, 진행 중인 호에 대한 유저 요구를 핸들링하는 것을 필요로 하는 임의의 인스턴스에 대해 부활될 필요가 있다.

임의의 일반적인 객체는 두 가지 형태의 상태를 포함한다:

1. 문자열, int(정수), bool(불)과 같은 간단한 직렬화 가능한 상태(또는 이들 간단한 엔티티로 구성되는 임의의 다른 복잡한 구조)

2. 다른 객체에 대한 참조

임의의 외부 저장소에 객체 상태의 제1 부분을 저장하는 것은 매우 쉽지만, 그러나 제2 부분(참조)은 그렇게 쉽지 않다.

본 개시의 일반적인 부활 프레임워크는 다음의 개념(클래스의 타입)을 기초로 한다:

1. PersistedObject - 간단한 직렬화 가능한 상태, 및 다른 PersistedObjects(지속된 객체)에 대한 "직렬화 가능한 참조"(다음을 참조)를 포함하는 임의의 객체:

a. 각각의 지속된 객체는, 그 객체에 PersistedObjectReference를 리턴하는 GetReference() 함수를 구현한다; 모든 서비스 객체는 지속된 객체이다;

2. PersistedObjectReference - PersistedObject에 대한 직렬화 가능한 참조. 직렬화된 PersistedObjectReference는 두 부분의 데이터만을 포함한다:

a. PersistedObject의 고유 식별자(identifier; ID);

b. PersistedObjectFactory의 고유 ID(팩토리 객체 식별자) - 하기 참조;

3. 각각의 PersistedObjectReference는, PersistedObjectReference 객체가 가리키는 로컬하게 활성화된/부활된 PersistedObject의 위치에 대한 포인터를 리턴하는 GetObject()로 칭해지는 함수를 구현한다;

4. PersistedObjectFactory - 외부 저장소로부터의 데이터에 기초하여 특정한 타입의 PersistedObject를 생성하는 방법을 알고 있는 객체. 각각의 팩토리는 CreateObject() 함수를 구현하는데, CreateObject() 함수는 PersistedObjectReference에 의해 호출되어 객체를 실제로 생성한다(또는 객체의 위치를 결정한다 - 하기의 섹션 2.2 참조);

5. PersistedObjectFactoryLocator - 모든 팩토리가 등록하는 객체, 그 결과, 누구나 필요한 팩토리에 액세스할 수 있고; 팩토리 식별자에 대해 구현되어 식별된 팩토리를 리턴하는 GetFactory() 함수를 제공한다;

6. PersistedObjectStore - 부활 인프라가 임의의 특정한 외부 저장소에 종속되지 않도록 외부 저장소의 구현을 숨기는 추상화; 객체 ID에 대해 호출되어 스토리지로부터 식별된 객체의 직렬화된 상태 데이터를 검색하는 GetState() 함수를 제공하도록 구성됨(예를 들면, GetState(ObjectID)는 식별자 ObjectID를 갖는 서비스 객체의 상태 데이터를 리턴한다).

각각의 PersistedObject 클래스는 또한 Initialize() 함수를 제공하도록 구성되는데, Initialize() 함수는, GetState()에 의해 검색되는 상태 데이터로 신규로 생성된 객체를 초기화하는데 사용될 수 있다.

"클래스[대문자 C] 객체"(또는 등)는 클래스 "Class"를 인스턴스화하는 것에 의해 생성되는 객체를 의미한다. 예를 들면, "PersistedObjectA 객체"는 클래스 PersistedObjectA를 인스턴스화하는 것에 의해 생성되는 객체를 의미한다.

다시 말하면, PersistedObjectReferences는, 명확하게 PersistedObject를 가리키는 직렬화 가능한 객체이다. 또한, PersistedObjectReference가 주어진 객체를 위치 결정하거나 생성하기 위해, PersistedObjectFactory 및 PersistedObjectFactoryLocator 개념을 생성하였다.

각각의 PersistedObjectReference 객체(참조 객체)는 다음 상태 데이터를 갖는다:

1. ObjectId - 임의의 외부 저장소로부터 임의의 상태를 가져오기 위해 PersistedObjectFactory에 의해 사용될 수 있는 PersistedObject 객체에 대한 고유 ID;

2. Factory Id - ObjectId에 의해 식별되는 지속된 객체를 생성할 수 있는 PersistedObjectFactory 객체의 고유 ID. 이 ID는, PersistedObjectFactoryLocator.GetFactory(<FactoryId>)를 호출하는 것에 의해, 팩토리 객체의 위치를 결정하는데 사용된다.

"<지속된 객체>에 대한 PersistedObjectReference"는, 자신의 상태 데이터가 <지속된 객체>의 지속된 객체 식별자를 포함하는 참조 객체를 의미하는 약칭으로 사용된다.

임의의 PersistedObject 객체(지속된 객체)는 적어도 하나의 메소드(함수): GetReference()를 갖는데, GetReference()는 그 PersistedObject 객체에 대한 PersistedObjectReference를 리턴한다.

모든 PersistedObjectReference 객체는 메소드: GetObject()를 갖는데, GetObject()는, 참조 객체가 가리키는 PersistedObject의 인스턴스, 즉 참조 객체에서의 ObjectID에 의해 식별되는 PersistedObject 객체를 리턴한다.

모든 PersistedObjectFactory 객체(팩토리 객체)는 메소드: CreateObject()를 갖는데, CreateObject()는, 지속된 객체를 입력으로서 식별하는 ObjectID를 취하고, 대응하는 직렬화된 상태 데이터로부터 식별된 지속된 객체를 생성하거나, 또는 그것이 이미 생성되었다면 식별된 지속된 객체의 위치를 결정한다.

PersistedObjectFactoryLocator는, 프로세스 시작시에, 예를 들면 컴퓨터 프로그램이 프로세서 상에서 최초로 인스턴스화되는 때의 기동시에 모든 PersistedObjectFactory 객체가 등록하는 단일 개체의(singleton) 인스턴스(팩토리 로케이터 객체)이다. 즉, 기동시에, 모든 지속된 객체 팩토리는 PersistedObjectFactoryLocator의 단일 개체의 인스턴스에 등록하고, 그 결과 주어진 임의의 PersistedObjectReference는 실제 PersistedObject 인스턴스를 생성하는데 사용될 수 있다.

PersistedObjectReferences가 직렬화 가능하기 때문에, 각각의 객체의 상태를 외부 저장소에 저장하는 것이 가능하며, 각각의 객체 참조에 대응하는 모호하지 않은 팩토리가 있기 때문에, 직렬화된 상태로부터 PersistedObject의 인스턴스를 생성하는 것은 항상 가능하다.

모든 호 컨트롤러 객체는 PersistedObjects인데, 이들은 자신의 상태를 직렬화하고 그들의 수명의 잘 정의된 지점에서 PersistedObjectStore에 기록한다. 임의의 다른 인스턴스는 단지 루트 객체에서 시작하는 것에 의해 전체 객체 그래프를 부활시킬 수 있을 것이다.

PersistedObjectStore는 또한, 스토리지 객체를 생성하기 위해 기동시에 인스턴스화된다.

호 컨트롤러는, URL의 다음의 스킴(scheme)을 사용하여 중간 호 콜백 링크를 생성한다:

따라서, 임의의 중간 호 커맨드가 수신되면, 호 컨트롤러는 팩토리 Id 및 객체 Id를 파싱하는 것에 의해 PersistedObjectReference를 생성할 수 있고, 그 다음, 참조 객체 상에서 GetObject()를 호출하여 실제 PersistedObject를 핸들링할 수 있다.

호 커맨드가 하나의 PersistedObject를 핸들링하면, 객체 그래프의 서브그래프는 참조의 체인을 따르는 것에 의해 점진적으로 구성될 수 있는데, 식별된 지속된 객체는 서브그래프에 대한 루트이다. 즉, 식별된 지속된 객체로부터 아래쪽으로의 모든 것이 생성된다 - 이것은 그래프의 모든 객체를 포함하지 않을 수도 있다.

따라서, 프레임워크를 따르는 컴퓨터 프로그램은 다음을 할 수도 있다:

- 하나 이상의 PersistedObject 클래스, 즉, 다음을 제공하도록 각각 구성되는, 지속된 객체에 대한 하나 이상의 템플릿을 정의함:

○ GetReference() 함수;

- 하나 이상의 PersistedObject 클래스 각각에 대한 PersistedObjectFactory 클래스, 각각의 클래스는 다음을 제공하도록 구성된다:

○ 자신의 직렬화된 표현으로부터 그 타입의 지속된 객체를 생성하는 CreateObject() 함수;

- 다음을 제공하도록 구성되는 PersistedObjectReference 클래스:

○ 지속된 객체 ID;

○ 식별된 지속된 객체를 생성할 수 있는(또는 위치 결정할 수 있는) 팩토리의 ID;

○ 식별된 지속된 객체를 리턴하는 GetObject() 함수;

- PersistedObjectFactorLocator 클래스; 및

- PersistedObjectStore Class.

따라서, 클래스가 정의되면, 상기에서 정의된 클래스 A, B 및 C는 다음과 같이 현재 프레임워크에 따라 재정의될 수 있을 것이다:

PersistedObjectReference PersistedA, PersistedB, PersistedC는 다른 PersistentObject 클래스를 직접적으로 참조하지 않는다는 것, 즉 어떠한 PersistentObject 클래스도 PersistedObject 타입의 멤버를 가지지 않는다는 것을 유의한다 - PersistedObject 클래스는 PersistedObjectReference 타입의 멤버만을 가지며, 따라서 다른 PersistedObject 클래스를 간접적으로만 참조한다.

각각의 타입의 PersistedObject에 대해, 대응하는 PersistedObjectFactory 클래스가 또한 존재할 것이다:

팩토리 클래스는 기동시에 인스턴스화되어 각각 타입 PersistedA, PersistedB 및 PersistedC의 객체를 생성하기 위한 팩토리 객체 POFA, POFB 및 POFC를 생성할 것이다. POFA, POFB 및 POFC는 직렬화된 상태 데이터로부터 타입 PersistedA, PersistedB 및 PersistedC의 객체를 각각 재생성할 수 있다.

그 다음, 상기에서 정의된 바와 같은 PersistedA 내지 PersistedC 클래스는, 대응하는 지속된 객체를 생성할 PersistedObjectReference 클래스가 다음을 참조하는 것처럼, 지속된 객체 PObA, PObB, PObC를 각각 생성하기 위해 프로그램의 일부 단계에서 인스턴스화될 것이다:

- PORA: PObA의 지속된 객체 식별자 및 POFA의 팩토리 식별자를 포함함;

- PORA: PObB의 지속된 객체 식별자 및 POFB의 팩토리 식별자를 포함함;

- PORA: PObC의 지속된 객체 식별자 및 POFC의 팩토리 식별자를 포함함;

지속된 객체 POA, POB 및 POC 및 참조 객체 PORA, PORB, PORC는 객체 그래프 PG로서 구조화되는데, 그 개념도는 도 12a에서 도시된다.

객체 그래프 PG는, 다양한 클래스이 서로를 참조하는 방식으로 인해, 에지(화살표로 도시됨)를 갖는 것으로서 보일 수 있다.

도 12b는 객체 및 에지가 프로세서의 메모리(414)에서 어떻게 구현될 수도 있는지의 하나의 예를 도시한다. 다시 말하지만, 이것은 예시를 돕기 위한 예에 불과하다 - 실제로는 이것은 컴파일러/프로세서 플랫폼의 구현 세부 사항에 의존할 것이다.

도 11a와 유사하게, 각각의 서비스 PObA, PObB, PObC는 메모리에서 - 각각 addrO 내지 addrO+4, addrP 내지 addrP+4 그리고 addrQ 내지 addrQ+4에서 - 다음으로서 실현된다:

- 각각의 메모리 포인터(addrO에서의 p1, addrP에서의 p2, addrR에서의 p3); 및

- addrO+4에서의 x의 값, addrP+4에서의 y의 값, addrQ+4에서의 z의 값.

그러나, 도 11a와는 대조적으로, 포인터(p1, p2, p3)는 다른 지속된 객체의 메모리 위치를 가리키지 않는다; 대신, 그들은 관련 참조 객체의 위치 addrR, addrS, addrT를 가리킨다. 이것은, Persisted Object 클래스가 PersistedObjectReference 멤버 타입만을 구비하기 때문이다.

addrR 내지 addrR+4는 PORB가 실현되는 곳이다(그리고 클래스 PersistedA가 PersistedB를 간접적으로 참조하기 때문에 p1은 여기를 가리킨다): addrR은 POFB<POFB의 ID>의 팩토리 객체 식별자를 유지하고, addrR+4는 PObB<PObB의 ID>의 지속된 객체 식별자를 유지한다.

addrS 내지 addrS+4는 PORC가 실현되는 곳이다(그리고 클래스 PersistedB가 PersistedC를 간접적으로 참조하기 때문에 p2는 여기를 가리킨다): addrS는 POFC<POFC의 ID>의 팩토리 객체 식별자를 유지하고, addrR+4는 PObC<PObC의 ID>의 지속된 객체 식별자를 유지한다.

addrT 내지 addrT+4는 PORA가 실현되는 곳이다(그리고 클래스 PersistedC는 PersistedA를 간접적으로 참조하기 때문에 p3는 여기를 가리킨다): addrS는 POFA<POFA의 ID>의 팩토리 객체 식별자를 유지하고, addrR+4는 PObA<PObA의 ID>의 지속된 객체 식별자를 유지한다.

또한, 메모리(114)에는, 각각의 활성의 지속된 객체에 대해, 식별된 지속된 객체가 실현되는 위치(즉, 자신의 상태 데이터가 유지도는 곳)를 식별하는 대응하는 메모리 포인터에 그 지속된 객체의 식별자를 매핑하는 맵핑의 세트(M)가 유지된다 - 이 에서, M은 다음을 포함한다:

- 제1 매핑(m1): <PObA의 ID> -> <addrO에 대한 포인터>

- 제2 매핑(m2): <PObB의 ID> -> <addrP에 대한 포인터>

- 제3 매핑(m3): <PObC의 ID> -> <addrQ에 대한 포인터>

매핑은 로컬 활성화 캐시에 유지된다(하기의 섹션 2.2 참조).

또한, 메모리에는, 관련 팩토리 객체 POFA, POFB, POFC가 실현되는 메모리 내의 위치로 팩토리 식별자를 매핑하는 팩토리 매핑(factory mapping; FM)의 세트가 유지된다. FM에서의 각각의 매핑은, 대응하는 팩토리 객체가 FactoryObjectLocator에 등록할 때 생성된다.

객체 그래프가 얼마나 복잡하게 되든, 즉, 다른 클래스를 참조하는 더 많은 클래스가 정의되고 더 많은 객체가 생성됨에 따라, 프레임워크는, 긴 체인의 포인터(즉, 포인터를 가리키고, 그 포인터는 다른 포인터를 가리키고, 그 다른 포인터는 추가 포인터를 가리키고, 그 추가 포인터는 또 다른 추가 포인터를 가리키는 식의 포인트)가 생성되는 것을 방지한다. 다시 말하면, PersistedObjectReference 객체의 존재는, 직렬화될 구조가 그 복잡성에도 불구하고 다루기 쉽게 유지되도록, 객체 간의 참조 체인을 효과적으로 분리한다. 즉, 객체 그래프가 아무리 복잡해도, 지속된 객체에 직렬화 함수를 적용하는 것은, 개개의 지속된 객체의 직렬화가, 지속된 객체가 가리키는 참조 객체(들)로 종료하도록 보장되기 때문에, 상대적으로 짧은 시간에 다루기 쉬운 출력을 생성하도록 보장된다.

2 A. 직렬화:

이 구조 및 직렬화 함수(예를 들면, 알려진 JSON 직렬화 함수)가 주어지면:

1. Serialize(InstanceOf(PersistedA))는 (JSON 직렬화기를 사용하여 직렬화되는 경우) 다음을 리턴할 것이다:

2. Serialize(InstanceOf(PersistedB))는 (JSON 직렬화기를 사용하여 직렬화되는 경우) 다음을 리턴할 것이다:

3. Serialize(InstanceOf(PersistedC))는 (JSON 직렬화기를 사용하여 직렬화되는 경우) 다음을 리턴할 것이다:

이 예에서, 직렬화된 상태 데이터는 일반 텍스트 포맷이다.

컴퓨터 프로그램이 호 컨트롤러를 구현하는 경우, 각각의 객체 그래프는, 호 컨트롤러의 인스턴스에 의해 확립되는 각각의 호에 대해 생성될 수도 있다. 호가 확립됨에 따라, 호를 확립하는 기능을 구현하는 신규의 서비스 객체가 프로세서의 메모리에서 생성된다 - 이들은, 호의 활성 호 상태를 구성하는 객체 그래프를 형성한다(하기의 예 참조). 그런 다음, (예를 들면) 호가 확립되면, 활성 호 상태는 직렬화되고, 외부 저장소에 저장되며, 활성 호 상태가 비활성화되고, 그에 의해 프로세서에 대한 리소스를 해제하게 된다. 호에서의 나중의 시간에, 예를 들면, 신규의 참가자를 호에 추가하기 위한 요청과 같은 몇몇 중간 호 요청 메시지에 응답하여, 객체 그래프의 적어도 일부는(즉, 서비스 객체 중 적어도 일부는), 트랜잭션이 수행되어 요청을 달성할 수 있도록 한다. 트랜잭션을 수행하는 것은, 부활된 활성 호 상태를 수정할 수도 있다. 트랜잭션이 완료되면, 수정된 활성 호 상태는 동일한 방식으로 직렬화되어 외부 스토리지에 유지되는 호 상태의 직렬화된 버전을 업데이트할 수 있다.

도 13은 지속된 객체를 직렬화하는 방법에 대한 플로우차트이다. 이 예에서, 각각의 지속된 객체는 자신의 상태가 변할 때마다 직렬화된다 - 이것은 예시의 목적을 위한 하나의 예에 불과하다.

플로우차트의 우측에서, 관련 방법 단계에서 수행되는 동작의 이해를 돕기 위해 도해적 예시가 제공된다.

단계 S1304에서, POb에 대한 개별적인 직렬화된 상태(1302) 데이터를 생성하기 위해, 지속된 객체 POb 중 제1의 것(예를 들면, PObA)이, 예를 들면 JSON 직렬화 함수를 사용하여, 직렬화된다. 개별 상태 데이터(1302)는 다음을 포함한다:

- PO에 의해 참조되는 임의의 지속된 객체(들)의 지속된 객체 식별자(1306) - 예를 들면, PObA의 경우, PObA가 PObB를 참조하기 때문에 <PObB의 ID> - ; 및

- 객체 참조된 지속된 객체(들)를 재생성하기 위한 팩토리 객체의 팩토리 객체 식별자(들)(1304) - 예를 들면, PObA의 경우, PObA가 PObB를 참조하기 때문에 <POFB의 ID>;

- POb의 상태 데이터(예를 들면, PObA의 경우, x의 값).

임의의 다른 적절한 직렬화 기술이 또한 사용될 수도 있다: 예를 들면, BOND 직렬화, 이진 직렬화 등.

단계 S1306에서, 개별 상태 데이터(1302)는 전체 객체 그래프 PG를 나타내는 직렬화된 상태 데이터(1300)에 포함된다. 개별 데이터(1302)는, i) 지속된 객체 POb 자체의 지속된 객체 식별자(1308)(예를 들면, <PObA의 ID>), 및 ii) POb를 재생성하기 위한 팩토리의 팩토리 객체 식별자(1310)(예를 들면, <POFA의 ID>)에 의해 직렬화된 데이터(1300)에서 라벨링된다.

단계 S1308에서, 팩토리 객체 식별자(1308) 및 지속된 객체 식별자(1310)를 포함하는 콜백 URL(1312)이 생성된다.

팩토리 객체 식별자(1310)에 의해 식별되는 팩토리 객체는, POb의 지속된 객체 식별자(1308)가 팩토리 객체의 CreateObject() 함수에 입력될 때, 직렬화된 데이터(1300)로부터 지속된 객체 POb를 재생성하도록 구성된다.

예를 들면, S1306에서 직렬화된 지속된 객체는, 예를 들면 호에 참가자를 추가하기 위한 일부 호 제어 서비스 함수를 구현할 수도 있다; S1308에서 생성되는 콜백 URL은 호에 참가하는 클라이언트(들)로 송신된다; 참가자를 호에 추가하기 위해, 클라이언트(들)는 그 링크에 액세스한다. 링크가 액세스되면:

- URL이 팩토리 객체 식별자(1308)를 포함하기 때문에, POb를 재생성하는데 필요로 되는 팩토리 객체는 URL 자체로부터 식별될 수 있고; 그리고

- URL 자체에 포함되는 지속된 객체 식별자(1310)는 식별된 팩토리 객체에 입력되어 지속된 객체 POb를 재생성할 수 있다.

그때, 클라이언트(들)는, 신규의 호 참가자의 추가를 요청하고 하는 경우에, 이 링크에 액세스하는 것을 알고 있다.

프로세스(S1304 내지 S1308)는 임의의 나머지 PersistedObejct 객체, 예를 들면 PObB, PObC에 대해 반복된다(S1310).

직렬화된 상태(1300)를 최신으로 유지하기 위해, 예를 들면, 신규의 지속된 객체가 생성되거나, 또는 현존하는 지속된 객체가 업데이트되는 경우, 이 프로세스는 다시 수행될 수 있다.

2B. 객체 재생성(비직렬화):

이제 직렬화된 데이터가 주어지면, 직렬화된 데이터는 직렬화 해제될(de-serialized) 수 있고(이것은 직렬화된 데이터의 직렬화된 표현으로부터 객체를 생성하는 것을 의미함), 그로부터, 필요로 될 수도 있는 임의의 다른 객체를 생성하도록 그것의 참조 체인이 후속될 수 있다.

상기의 예에서, InstanceOf(PersistedC)에 대한 직렬화된 데이터는 직렬화 해제되어 InstanceOf(PersistedC), 즉 PObC를 복원할 수 있다.

다음으로, PObC의 직렬화된 상태 데이터가 서비스 객체 식별자 <PObA의 ID> 및 <POFA의 ID>를 포함하기 때문에, PORA에 대한 PersistedObjectReference가 복원될 수 있다 - 이들 두 식별자는, 이들이 참조 객체 PORA의 상태 데이터의 총합을 나타내기 때문에, 참조 객체 PORA를 재생성하는데 필요로 되는 전부이다.

다음으로, InstanceOf(PersistedC)PORA.GetObject()가 호출된다. 거기에서부터, PORB 및 따라서 PObB는 동일한 방식으로 복원될 수 있다.

PersistedObjectReference.GetObject()는 다음과 같이 간단히 구현된다:

1. 팩토리 =

PersistedObjectFactoryLocator.GetFactory(PersistedObjectReference.FactoryId)

2. 객체 = Factory.CreateObject(PersistedObjectReference.ObjectId)

여기서, "POb.f()"는, 서비스 객체 POb에 의해 구현되는 함수 f()를 호출하는(즉, 함수 f()에 대한 함수 호출을 행하는) 것을 의미한다.

PersistedObject.GetReference()의 구현은, 임의의 PersistedObject 타입의 인스턴스를 구성하고, 생성된 식별자를 인스턴스의 구성자(constructor)에 입력하는 동안, 적절한 FactoryId 및 ObjectId를 생성하는 것에 의해 실행 가능하게 된다.

예를 들면, PersistedA의 구성자는 두 개의 파라미터 FactoryId 및 ObjectId를 입력으로 취할 수 있다.

도 14는 직렬화된 상태 데이터로부터 서비스 객체를 재생성하는 방법에 대한 플로우차트이다. 다시, 대응하는 방법 단계에서 수행될 수도 있는 예시적인 동작을 예시하기 위해 도해적 표현이 위치된다. 이들은 예시의 목적을 위한 예에 불과하다.

단계 S1402에서, 서비스 재활성화 메시지가 수신된다. 예를 들면, 서비스 활성화 메시지는 확립된 호에 관련이 있을 수도 있고, 신규의 참가자가 추가되어야 한다는 것을 요청할 수도 있다. 서비스 요청 메시지는, 예를 들면, 도 13의 S1308에서 이미 생성된 바와 같은 콜백 URL(1312)로 게시되고, 섹션 1의 시그널링 프로토콜에 따라 클라이언트(들)로 제공된다.

도 14의 단계 S1404 내지 S1410은, 직렬화된 상태 데이터(1300)에서 표현되는 객체 그래프의 적어도 일부 - 구체적으로는, S1302의 서비스 요청 메시지에서 식별되는 지속된 객체가 루트인, 즉, 식별된 객체에 의해 참조되는 모든 지속된 객체, 및 결국에는 이들 객체에 의해 참조되는 임의의 추가 지속된 객체, 및 결국에는 그 추가 지속된 객체에 의해 참조되는 임의의 또 다른 추가지속된 객체 등인 객체 그래프의 서브 그래프 - 를 재활성화하도록 반복적으로 수행되는 서브루틴을 구성한다.

콜백 링크(1312)는 파싱되어 지속된 객체 식별자(1310) 및 그 타입의 지속된 객체를 재생성하기 위한 팩토리를 식별하는 팩토리 객체 식별자(1308)를 획득하고, 이들 지속된 객체 및 팩토리 객체에 대해 서브루틴이 최초 수행된다:

이 예에서, 링크는 <PObA의 ID> 및 < POFA의 ID>, 즉, 지속된 객체 PObA의 지속된 객체 식별자, 및 관련 직렬화된 상태 데이터로부터 PObA를 재생성하기 위한 팩토리 객체 POF의 팩토리 객체 식별자를 포함한다.

단계 S1404에서, 팩토리 객체 ID(1308) 및 서비스 객체 ID(1310)는, 서비스 객체 식별자(1310)에 의해 식별되는 지속된 객체 POb의 PersistedObjectReference 객체 POR을 복원하는데 사용된다 - 상기에서 나타낸 바와 같이, 이들 두 식별자는, 참조 객체를 재구성하는데 필요로 되는 전부이다.

단계 S1406에서, 도 13에 따라 생성되는 직렬화된 상태 데이터(1300)는, 콜백 링크(1312)로부터 획득되는 팩토리 객체 식별자(1308) 및 지속된 객체 식별자(1310)와 일치하는 라벨을 갖는 엔트리를 찾기 위해 검색된다.

단계 S1408에서, 그 엔트리 내의 개별적인 직렬화된 상태 데이터(1302)는 팩토리 객체 식별자(1308)에 의해 식별되는 팩토리 객체에 입력되어 지속된 객체 POb를 복원한다 - 이것은 POR.GetObject()를 호출하는 것에 의해 달성된다.

이 예에서, 문제가 되고 있는 서비스 객체는 PObA이고, 재작성된 PObA는 메모리 내의 addrD 내지 addrD+4에서 실현된다. 변수 x의 값은 직렬화된 상태 데이터로부터 addrD+4로 로딩된다; PObA가 PORB를 참조하기 때문에(상기 참조), 메모리 위치는 PORB에 대한 포인터를 유지하기 위해 예약된다 - 그러나 이 단계에서 PORB는 재작성되지 않았고 따라서 addrD는 처음에는 비어 있다.

<PObA의 ID>를, 메모리(414) 내에서 PObA가 실현되는 곳, 즉, 이 예에서 addrD에 대한 포인터를 식별하는 메모리 포인터에 매핑하는 매핑(m1')이 메모리(414)에서 또한 생성된다.

단계 S1410에서, 그것은, 방금 재작성된 지속된 객체가 임의의 다른 지속된 객체를 참조하는지 또는 그렇지 않은지 여부에 따른 서브루틴 분기이다: 만약 아니라면, 서브 루틴은 종료한다. 만약 그렇다면, 서브 루틴 S1404 내지 S1410이 반복되지만, 그러나 이번에는 참조된 서비스 객체(들), 즉, 방금 재작성된 지속된 객체에 의해 간접적으로 참조되는 객체(들)에 대해 반복된다. 도 14의 우측은, PORB 및 PObB(PObA에 의해 참조됨)가 어떻게 재생성되는지 예로서 도시된다. PORB가 addrH 내지 addrH+4에서 재생성되면, PObA의 재구성을 파이널라이징하기 위해 addrH에서 포인터 p1'가 메모리(414)에서 생성된다.

서브 루틴의 반복을 위해, POR.GetObject()는, 참조 객체 POR에 대응하는 서비스 객체가 일부 서비스 함수를 구현하는데 실제로 필요로 되는 경우에만 호출될 수도 있다. 예를 들면, PObB가 서비스 함수 fB()를 구현하는 경우, PObA는, PObB가 재활성화되게 하고 그 다음 재활성화된 PObB 상에서 fB()가 호출되게 하는 PORB.GetObject().fB()를 호출할 수도 있다.

그 후, PORC 및 PObC를 동일한 방식으로 재구성하기 위해 서브 루틴은 다시 수행된다.

2.2 객체 부활 및 가져 오기:

명백한 바와 같이, 비순환적(acyclic) 객체 그래프의 경우, 프로세스는 어떠한 다른 서비스 객체도 참조하지 않는 서비스 객체로 결국 종료될 것이다.

순환 객체 그래프의 경우, 추가적인 메커니즘이 제공된다. 순환 객체 그래프는, 참조의 폐 루프를 갖는 그래프이다 - 도 12a의 객체 그래프는 순환 객체 그래프의 하나의 예이다.

다음 시나리오를 고려한다: 2 개의 지속된 객체 A 및 B가 존재한다. A는 B를 참조하고, B는 A를 참조한다. A가 B를 부활시키면, 그리고 부활 동안 B가 A를 부활시키려고 시도하면, 무한 루프가 발생하여 결국 스택 오버플로우 및 충돌로 이어진다.

이 시나리오를 처리하기 위해, 서비스 객체의 부활시, 매핑(예를 들면, 도 12b의 m1, m2, m3) - 서비스 객체의 식별자와 서비스 객체가 실현되는 메모리(414) 내의 위치에 대한 메모리 포인터 사이의 매핑 - 이 로컬 활성화 캐시에서 생성된다. (대응하는 참조 객체 상에서 GetObject()를 호출하는 것에 의한) 그 객체를 부활시키려는 추가적인 시도는, 단지, 캐싱된 값이 리턴되는 것으로 귀결되고, 따라서, 순환 체인을 파괴한다.

지속된 객체가 인스턴스 상에서 "부활되는" 경우, (PersistedObjectFactory가 따르는) 알고리즘은 다음의 것이다:

1. 외부 저장소로부터 지속된 상태 가져오기:

상태 = PersistedObjectStore.GetState(ObjectId)

2. 로컬 메모리에 객체 생성하기:

X = 신규의 PersistedObject()

3. 생성된 객체를 외부 저장소로부터 검색되는 상태로 초기화하기,

X.Initialize(State);

4. 생성된 인스턴스를 로컬 활성화 캐시에 넣기, 로컬 활성화 캐시는 객체 id로부터 로컬하게 부활된 객체에 대한 참조까지 이르는 사전임.

이 시점에서, X는 로컬 메모리에서 살아있는 완전히 부활된(재수화된(re-hydrated)) PersistedObject 객체(즉, 서비스 객체)이다. 따라서, 인스턴스 X는 메모리에 있는 실제 객체에 대한 참조이다.

따라서, 몇몇 다른 객체(Y)가 X에 대한 PersistedObjectReference를 가지며, 그 상에서 메소드를 호출하기를 소망하는 경우, 다음의 것이 발생할 것이다:

1. Y는 PersistedObjectRereference(X).GetObject()를 호출할 것이다 - 이것은 결국에는 PersistedObjectFactory().CreateObject()로 이동할 것인데, PersistedObjectFactory().CreateObject()는, 먼저 로컬 활성화 캐시를 살펴볼 것이고, objectid에 대한 엔트리가 이미 있으면, 이미 생성된 객체에 대한 참조를 리턴할 것이다. 엔트리가 존재하지 않는 경우, 그것은, 엔트리를 생성하여 로컬 활성화 캐시에 넣기 위해 상기의 알고리즘을 따를 것이다.

2. Y는 이제 X의 로컬 인스턴스화에 대한 참조를 가지며, X 상에서 임의의 메소드를 호출하여 그것을 임의의 다른 객체로 취급할 수 있다.

즉, 캐싱된 객체가 리턴되고 캐싱된 객체의 다른 버전은 생성되지 않는다. 이 메커니즘을 사용하는 것은, 모든 PersistedObjectReference(X) 객체가 PersistedObject(X)의 동일한 인스턴스를 참조하는 것을 보장한다. 이 속성은, Persisted 객체 그래프가, 객체가 서로의 메모리 위치를 직접적으로 참조하는(따라서 객체의 동일한 인스턴스를 '자동적으로' 참조하는) 도 11a에서 도시되는 타입의 그래프와 정확히 동일하게 거동하는 것을 보장한다.

3. 단일의 부활 보장하기:

하기에서는, 동일한 호에 대한 다수의 트랜잭션이 동시에 발생하는 경우, 호 상태의 일관성을 보장하기 위해 이들 모두가 동일한 인스턴스에 의해 프로세싱되는 것을 보장하기 위한 메커니즘이 제공된다.

상이한 중간 호 요청이 호 컨트롤러의 상이한 인스턴스로 진행 수도 있기 때문에, 이것은, 호에 대한 객체 그래프가 다수의 호 컨트롤러 인스턴스 상에서 동시적으로 부활되는 상황으로 이어질 수 있을 것이다.

이것은, 동일한 객체의 상이한 부활이 그들의 (상이한) 상태를 외부 저장소에 기록하려고 시도할 때, 데이터 불일치로 이어질 수 있을 것이다.

정교한 낙관적(optimistic) 동시성, 재시도 및 롤백의 정교한 스킴을 사용하여 데이터를 조정하고 일관된 값에 도달하는 것이 가능하지만, 이것은 복잡하고 예측 불가능하다.

이러한 이유 때문에, 호 컨트롤러 배치는 데이터 일관성을 상이하고 보다 예측 가능한 방식으로 보장한다. 메커니즘은 객체 그래프의 단일의 부활이 존재하는 것을 보장하고, 그 결과 동일한 객체 그래프는 동시 요청을 핸들링할 기회를 얻는다. 이렇게 하면, 객체는 전통적인 동기화 기술 - 예컨대 잠금, 모니터 및 세마포어 - 을 사용하여 데이터 일관성을 쉽게 보장할 수 있다.

통신 네트워크의 엔드포인트 사이에서 통신 이벤트를 달성하기 위한 통신 시스템이 개시된다. 상기 시스템은 다음을 포함한다: 데이터베이스; 메시지를 수신하기 위한 입력; 코드를 유지하도록 구성된 컴퓨터 스토리지; 및 하나 이상의 프로세서. 코드는 확립된 통신 이벤트를 관리하기 위한 컨트롤러를 구현하도록 구성된다. 프로세서(들)는 컨트롤러의 다수의 인스턴스를 실행하도록 구성된다. 컨트롤러의 각각의 인스턴스의 경우, 확립된 통신 이벤트에 관련이 있는 액션을 요청하는 메시지를 인스턴스가 수신하는 것에 응답하여, 인스턴스는 데이터베이스에 액세스하여, 통신 이벤트를 현재 소유하고 있는 것으로서 컨트롤러의 다른 인스턴스를 식별하는 유효한 소유권(ownership) 엔트리를 데이터베이스가 포함하고 있는지 여부를 결정한다. 만약 그렇다면, 인스턴스는 메시지를 다른 인스턴스로 포워딩한다; 만약 아니라면, 인스턴스는, 통신 이벤트를 현재 소유하고 있는 것으로서 인스턴스를 식별하는 유효한 소유권 엔트리를 데이터베이스에서 생성하고, 컴퓨터 스토리지에서 유지되는 통신 이벤트의 상태를 수정하는 것을 포함하는 요청된 액션을 수행한다.

이하, Fdqn은 정규화된 도메인 네임(Fully Qualified Domain Name)을 의미한다. "<호 컨트롤러 Fqdn>"는 호 컨트롤러 클러스터의 도메인 네임을 의미한다. 클러스터 내의 개별 인스턴스는 서로 상이한 IP 주소를 가지며 관련 인스턴스 ID에 의해 구별된다.

이것은 다음 스킴을 사용하는 것에 의해 달성된다:

1. 각각의 호는, 자신을 임의의 다른 컨텍스트와 구별하는 고유 ID(컨텍스트 식별자) <컨텍스트 ID>를 갖는 고유 컨텍스트와 관련된다; 또한, 배치의 호 제어 클러스터에 있는 각각의 호 컨트롤러 인스턴스는, 자신을 클러스터의 임의의 다른 인스턴스와 구별하는 고유의 인스턴스 ID를 갖는다.

2. Call Controller를 가리키는 각각의 콜백 URL은, URL에서 이 컨텍스트 id를 갖는데, 다음과 같은 형식으로 이루어진다: https://<호 컨트롤러 Fqdn>/<컨텍스트 Id>/<PersistedObjectFactoryId>/PersistedObjectId>.

3. Call Controller 인스턴스 상에서 임의의 액션이 호출되는 경우, 그것은 다음의 알고리즘("ProxyOrTakeOver")을 수행한다:

a. 호 생성 요청의 경우, 외부 저장소의 데이터베이스(도 15의 1502)에서 다음의 엔트리를 생성한다: 처음에는 유효한 <ContextId, 프로세싱 인스턴스 ID>. "프로세싱 인스턴스 ID"는 엔트리를 생성하는 인스턴스의 인스턴스 ID이다. 따라서, 엔트리는, 엔트리가 유효하게 유지되는 한, 이 인스턴스를, 호를 현재 소유하는 것으로서 식별한다. 엔트리는 어떤 시간 이후 만료된다(무효하게 된다). 이 엔트리에 대한 만료 시간은, 임의의 단일 트랜잭션(예를 들면, 호 확립)이 완료하는데 걸리는 최대 시간이다.

i. 이 엔트리는 객체 그래프의 상태(이것은 호가 살아있는 한 살아 있다)와는 상이하다는 것을 유의한다.

ii. 호 컨트롤러의 경우, 최대 시간은 (프로토콜 기초한) 90초이다.

iii. 소유권 엔트리는, 다음과 같은 두 가지 이유 때문에, 호에 대한 어떠한 호 제어 동작도 수행되지 않는 비활성의 간격 이후에 만료(무효화)된다.

1. 신규의 요청이 임의의 인스턴스 상에 도달하는 경우, 이 인스턴스는, 항상 원래 인스턴스로 요청을 프록싱해야 하기 보다는, 단지 신규의 소유자가 될 수 있어야 한다. 이것은 불필요한 프록싱을 방지하는 것에 의해 보다 최적의 프로세싱을 제공하며, 그것은 또한 더 나은 부하 분산을 보장한다;

2. 소유권 엔트리가 더 오래 유효하게 남아 있을수록, 호가 활성인 동안 소유자가 실패할 확률이 높아지고, 따라서 다른 서버가 소유자를 시도하고, 그것의 실패를 검출하고 인수를 시도하는 것을 필요로 하게 된다.

4. 상기 두 가지 문제는, 아무 일도 일어나지 않으면 소유권이 만료되도록 허용하는 것에 의해 방지될 수 있다.

a. 인스턴스(1504, 그림 15)에 도달하는 중간 호 요청의 경우, 만료되지 않은 <ContextId, 프로세싱 인스턴스 ID>가 존재하는지를 검사한다.

b. 이러한 엔트리가 없으면, 엔트리 <ContextId, 현재 인스턴스 ID>(1506, 도 15)를 생성하고, 요청의 프로세싱을 시작한다; "현재 인스턴스 ID"는, 중간 호 요청이 도달한 인스턴스의 식별자이고, 따라서 엔트리가 유효하게 남아 있는 한, 그 인스턴스를, 현재 소유자로서 식별한다.

c. 이러한 엔트리가 있고, 인스턴스의 인스턴스 ID를 프로세싱하는 값이 현재 인스턴스의 인스턴스 ID와 같으면, 엔트리의 수명을 연장하고, 요청 프로세싱을 시작한다.

d. 엔트리의 인스턴스 ID가 현재 인스턴스의 인스턴스 ID와 상이하면, (하기에서 제시되는 알고리즘을 사용하여) 프로세싱 인스턴스가 살아있는지를 확인하고, 만약 그렇다면, 요청을 그 인스턴스로 프록싱한다. 그 인스턴스는 동일한 알고리즘을 다시 실행할 것이다

e. 프로세싱 인스턴스가 죽었으면(dead), 현재 인스턴스를 신규의 프로세싱 인스턴스로 표시하는 엔트리가 업데이트되고, 요청 프로세싱을 시작한다.

i. 다수의 동시적 기록은 낙관적 동시성을 사용하여 핸들링된다. 따라서, 인스턴스1과 인스턴스 2가 동시에 소유자가 되려고 하는 경우, 하나는 이길 것이고 다른 하나는 그것에 관해 알 것이고 승자에게 프록싱할 것이다.

호에 대한 호 상태가 직렬화되면, 정확한 호 상태가 나중에 복원될 수 있도록, 그것은 호의 컨텍스트 ID와 관련하여 저장된다.

도 15는 (예를 들면, 신규의 참가자를 확립된 호에 추가하도록, 확립된 호를 종료하도록, 등을 하도록) 중간 호 요청 메시지를 프로세싱하기 위한 플로우차트이다. 방법 단계의 도해적 표현이 오른쪽에 도시되어 있다.

단계 S1502에서, (하나 이상의 동작을 수반하는) 트랜잭션을 요청하는 중간 호 요청 메시지, 즉 이미 확립된 호에 관한 중간 호 요청 메시지가 URL에 게시된다. URL은 호 컨트롤러 클러스터(522C)를 가리키며, 따라서 메시지는 클러스터의 부하 밸런서(548)에 의해 수신되고 상응하게 호 컨트롤러의 인스턴스 - 이 예에서는 434C2 - 로 포워딩된다. 메시지가 게시되는 URL은 확립된 호에 고유한 "contextID"를 포함한다(상기 참조).

응답으로, 인스턴스(434C2)는 데이터베이스(1502)에 액세스하여, 호를 현재 소유하고 있는 것으로 호 컨트롤러의 다른 인스턴스를 식별하는 유효한 소유권 엔트리가 존재하는지 또는 그렇지 않은지 여부를 결정한다(S1204). 이러한 엔트리는 소유 인스턴스의 인스턴스 식별자(예를 들면, 도 15의 "ID1")를 포함할 것이다.

만약 그렇다면, 인스턴스(434C2)는 다른 인스턴스가 여전히 기능하는지(살아있는지)의 여부를 검사한다(S1507) - 하기 참조. 살아 있다면, 인스턴스(432C)는 유효 엔트리에서 식별되는 다른 인스턴스(예를 들면, 434C1)로 메시지를 포워딩한다(S1506). 이것은 "프록시 동작"으로 칭해진다.

유효한 소유권 엔트리가 존재하지 않거나 또는 다른 인스턴스가 살아 있지 않은 경우, 인스턴스는 유효한 소유권 엔트리를 생성하는데, 생성된 엔트리는 인스턴스의 인스턴스 식별자("ID2") 및 컨텍스트 ID를 포함하고, 그에 의해, 그 자신을 호의 현재 소유자로서 식별한다(S1508). 이것은 "컨텍스트 인수 동작(context takeover operation)"으로 칭해진다.

그 후, 인스턴스는 요청된 트랜잭션을 수행하도록 진행하는데, 요청된 트랜잭션은, 외부 스토리지(606) 내의 관련 직렬화된 상태 데이터(호의 컨텍스트 ID에 의해 스토리지에서 식별됨)로부터 호에 대한 객체 그래프(즉, 호 상태)를 재생성하는 것, 트랜잭션을 달성하는데 필요로 되는 액션을 수행하는 것 - 이것은 부활된 상태를 수정하는 것을 본질적으로 수반할 것이다 - , 및 수정된 호 상태의 직렬화된 버전을 외부 스토리지(606)에 다시 저장하는 것을 수반한다.

컨텍스트를 사용한 판독/기록 최적화:

컨텍스트의 상기 정의된 개념을 활용하는 것에 의해, 외부 객체 캐시에 대한 판독/기록이 최적화될 수 있다.

이것은, 컨텍스트마다, 모든 기록을 축적하고 모든 판독을 제공하는 가상 외부 저장소를 생성하는 것에 의해 달성될 수 있고, 그 다음, 모든 기록을 - 예를 들면, 메모리의 직렬화된 그래프의 스냅샷을 찍는 것에 의해 - "실제" 외부 저장소에 일괄적으로(in a batch) 푸시한다.

각각의 개별 PersistedObject는, 그들의 데이터를 외부 스토리지에 기록하고 있다고 계속 "생각"할 것이지만, 그러나, 실제로는 그들은 로컬 메모리에 기록하고 있다; 모든 판독에 대해서도 마찬가지이다.

호 컨트롤러의 경우, 가상 저장소는 호의 단계에 기초하여 자신의 데이터를 실제 외부 저장소에 기록한다. 예를 들면, 1: 1 호의 경우, 데이터는 호가 확립되면 플러싱되고, 호가 종료하면 삭제된다.

단일의 객체 그래프 부활을 보장하는 것에 의해, 모든 판독 및 기록이 일관성이 있도록 보장된다.

가상 컨텍스트 저장소 자체는, 로컬 인스턴스가 프로세싱 인스턴스가 되는 컨텍스트 인수 동작의 일부로서, 채워질 수 있다. 이것은, 컨텍스트의 성공적으로 인수 이후, 판독 실패에 기인하여 어떠한 부활도 실패하지 않을 것이라는 것을 보장하는 이점을 갖는데, 이렇게 하는 것은 예측 가능성을 보장한다.

인스턴스 가용성 검사:

(프록시 또는 인수 동작 알고리즘의 목적을 위해) 인스턴스가 살아있는지를 검사하기 위해, 호 컨트롤러는 간단한 기술을 따른다:

1. 매 4 초마다 각각의 인스턴스는 10초(10초 = 2 * 4+2 초의 안전 한도)의 만료 시간을 가지고 외부 저장소의 데이터베이스(608)에 하트비트(heartbeat) 메시지를 기록한다. 이 만료 시간은 일시적인 실패에 대한 약간의 회복력을 엔트리에게 준다 - 특정한 인스턴스가 죽었다고 다른 인스턴스가 생각하기 위해서는, 하트비트는 두 번 연속 실패하는 것을 필요로 한다.

2. 4초마다, 각각의 인스턴스는 또한, 다른 모든 인스턴스에 의해 작성된 엔트리를 판독한다.

3. 엔트리가 발견된 인스턴스는 살아있는 것으로 간주되는 반면, 다른 엔트리는 죽은 것으로 간주된다

4. 이 방식에서, 특정한 인스턴스의 실패의 14초(최악의 경우) 내에, 다른 인스턴스가 실패를 알게 되고, 현재 작동하지 않는 인스턴스에 의해 이전에 서비스되고 있었던 호의 적절한 "인수"를 행한다.

호 프로세싱을 사용한 예:

예시를 돕기 위해, 호 컨트롤러 인스턴스가 호를 프로세싱할 때 객체 그래프가 생성되고, 그 다음, 일단 호가 확립되면 호 자체 동안 객체 그래프가 적어도 부분적으로 재생성되는 예시적이고 단순화된 상황이 제시된다.

호 제어 서비스를 전달하기 위해 협력하는 모든 객체는 지속된 객체로서 생성되고, (다른 본질적으로 직렬화 가능한 상태에 더하여) 그들의 상태에서 PersistedObjectReference만을 포함한다. 그들이 참조하는 임의의 객체에 대해 그들이 동작해야 할 필요가 있을 때, 그들은 단지 다음을 호출한다

PersistedObjectReference.GetObject().<MethodToBeInvoked>.

이하, 다른 서비스 객체(object2)를 참조하는 서비스 객체(object1)에 대한 참조는, 대응하는 참조 객체(reference2)를 사용하는 간접 참조로 칭해진다. object2가 서비스 함수(f2())를 구현하는 경우, object2는 reference2.GetObject().f2()를 호출하는 것에 의해 객체 상에서 f2()를 호출한다(reference2.GetObject()는 object2를 리턴하는데, 그 다음, f2()가 호출된다).

시퀀스는 다음과 같다:

1. UserA(Alice)가 UserB(Bob)를 호출한다

a. CallInvitationRequest는, 통지를 계속해서 전송하기 위해 호 컨트롤러에 의해 사용되는 콜백 URL의 세트를 포함한다

2. Call Controller는 요청을 수신하고, 그것을 파싱한 후, 다음의 서비스 객체를 생성한다:

a. UserAFacingCallbackHandler - 상태로서 UserA로부터 수신되는 다양한 URL을 갖는다. 이 객체는 다음과 같은 메소드를 노출한다

i. 수락 url을 사용하여 호 수락 메시지를 호출자에게 전송하는 Accept()

ii. 거부 url을 사용하여 호출자에게 호 종료 메시지를 전송하는 Reject()

b. Call0 - 이것은 비즈니스 로직 레이어가 작동할 수 있는 추상화이다. 그것의 특성은 다음과 같다:

i. 상태:

1. 호출자, 피호출자 및 호 모달리티(오디오/비디오)와 같은 호 콘텐츠

2. UserAFacingCallbackHandler에 대한 참조

3. 분기(Forks) - CreateFork 메소드를 호출하는 것에 의해 생성되는 호 객체(Call object)에 대한 참조의 어레이(분기는 아래 지점 중 하나에서 설명되며, 다수의 엔드포인트에 하나의 호를 전송하는 프로세스를 가리킨다)

ii. 메소드:

1. 수락 - 피호출자가 호를 수락하면 호출됨

2. 거부 - 피호출자가 호를 거부하면 호출됨

3. 취소 - 호출자가 호를 취소하면 호출됨

4. CreateFork - 호에 대한 분기를 생성하기 위해 백-투-백 컨트롤러(하기에서 설명됨)에 의해 사용됨

iii. 그것이 작동하는 방식 - 만약 로직 레이어가 Call0.Accept를 호출하면, UserAFacingCallbackHandler의 AcceptUrl이 판독될 것이고, CallAcceptance 메시지가 그 URL로 전송될 것이다

3. 그런 다음 Call Controller는 이 Call0 객체를 비즈니스 로직 레이어로 제공한다

4. 비즈니스 로직은 백투백 라우팅 컨트롤러(Routing Controller)로 칭해지는 객체의 체인을 포함한다;

a. 이들 객체는 호의 라우팅에 참가할 수 있다;

b. 호 객체 상에서 메소드를 사용하면, 메소드는 전체 메시지 흐름에 영향을 줄 수도 있고, 일시적 또는 영구적으로 메시지 플로우 체인에 남아있을 수 있다;

c. 백투백 라우터의 몇몇 예는 다음과 같다:

i. 과금 컨트롤러(Billing Controller) - 이것은 호의 시작에서부터 체인에 남아 있으며, 유저에 대한 과금을 계속 추적하고, 유저가 시간을 다 쓰면, 호를 차단할 수도 있다;

ii. 퍼미션 시행 컨트롤러(Permission Enforcement Controller) - 이 컨트롤러는, UserA가 정책에 따라 허용되는 호출 동작만을 수행할 수 있는 것을 보장한다(예를 들면, UserB가 UserA를 차단했을 수도 있다);

iii. 엔드포인트 라우팅 컨트롤러 -이 컨트롤러는 호출된 유저(UserB)의 엔드포인트의 위치를 결정하고, 호를 적절한 목적지로 라우팅한다;

d. 각각의 백투백 라우터는 호 객체를 획득하고, (CreateFork를 호출하는 것에 의해) 하나 이상의 호 객체를 생성한다 - 생성된 객체의 각각은 원래 호의 분기를 나타낸다. 예를 들면, UserB가 2 개의 엔드포인트를 가지면, Endpoint Routing Controller는 2 개의 호 객체를 작성할 것인데, 객체의 각각은 적절하게 (각각의 엔드포인트로) 라우팅될 것이다

e. 컨트롤러 체인이 다음과 같다고 가정한다: 퍼미션 시행 -> 과금 -> 엔드포인트 라우팅:

5. 퍼미션 시행 컨트롤러는 Call0 객체를 가져오고, 다른 호 객체인 ForkedCall1을 생성하는데, ForkedCall1은 다음과 같은 특징을 갖는다

a. 상태:

i. 부모 호 객체에 대한 참조 - 작동 방식은 다음과 같다:

ForkedCall1.Accept이 호를 획득하면, Call0.Accept가 호출될 것이다.

ii. 분기 - 임의의 것이 생성되는 경우

b. 메소드:

i. 호 객체와 동일

c. 퍼미션 시행 컨트롤러가 원래 Call 객체 상에서 CreateFork()를 호출하는 것의 결과로서, 부모 객체의 분기 어레이에 ForkedCall1 -> Call0.Forks = {ForkedCall1}이 추가되었을 것이다.

6. 그런 다음 과금 컨트롤러는 ForkedCall1을 얻고 ForkedCall2를 생성한다

a. ForkedCall2는 부모 ForkedCall1에 대한 참조를 가지며, ForkedCall 객체와 동일한 타입을 갖는다

b. ForkedCall1.Forks = {ForkedCall2}

7. 엔드포인트 라우팅 컨트롤러가 ForkedCall2를 얻고 ForkedCall31 및 ForkedCall32를 생성한다

a. 이들 분기 둘 다는 호(Call)와 동일한 타입을 가지며 부모 객체 ForkedCall2에 대한 참조를 포함한다

b. ForkedCall2.Forks = {ForkedCall31, ForkedCall32}

8. 이제 호 컨트롤러는, FokedCall31 및 ForkedCall32에 대해 각각 하나씩의 두 개의 호 통지 요청을 생성한다

a. 호 통지 요청의 각각은, 적절한 호 객체를 가리키는 접속 URL(Attach URL)을 포함한다

b. CallNotification(ForkedCall31).AttachUrl = https://<호 컨트롤러 프로세싱 인스턴스>/<ForkedCall31을 나타내는 Id>/Attach

c. ForkedCall32에 대해서 유사함

9. (CallNotification에서 수신되는 접속 URL로 접속 요청을 전송하는 것에 의해) UserB의 엔드포인트 중 임의의 것이 접속하는 경우, AttachRequest의 일부로서 수신되는 종료 URL(End URL)이 ForkedCall31/32의 호 상태에 추가될 것이다.

10. AttachResponse의 일부로, 엔드포인트는 그들의 ForkedCall에 대응하는 링크를 얻을 것이다. 예를 들면, ForkedCall31에 대한 수락 URL(Accept URL)은 다음과 같을 수 있을 것이다

a. https://<호 컨트롤러 프로세싱 인스턴스>/<ForkedCall31을 나타내는 Id>/Accept

11. (CallAcceptance 메시지를, ForkedCall31에 대응하는 수락 URL로 전송하는 것에 의해) ForkedCall31이 수락된다고 가정한다:

a. 수락 메시지는 (미디어 재협상, 전송 등과 같은) 중간 호 링크에 대한 콜백 URL을 포함한다;

b. CallAcceptance 메시지의 수신시, 호 컨트롤러는 객체 UserBFacingAcceptedCallCallbackHandler을 생성할 것인데, 이것은 UserB의 엔드포인트가 제공하는 URL을 자신의 상태로서 갖는다. 이 객체는 다음과 같은 메소드를 노출한다:

i. 미디어 재협상 url을 사용하여 mediaRengotiation 메시지를 userB에게 되전송하는(send back) RenegotiateMedia();

ii. 전송 url을 사용하여 전송 메시지를 UserB에게 되전송하는 Transfer();

12. ForkedCall31.Accept()는 다음의 특성을 갖는 UserBFacingAcceptedCall을 생성한다:

a. 상태:

i. UserBFacingAcceptedCallCallbackHandler에 대한 참조;

ii. ForkedCall2.Accept()가 ForkedCall31.Accept()의 일부로서 호출될 때 생성되는 AcceptedCall2 객체에 대한 참조.

b. 메소드:

i. HandleMediaRenegotiation() - 이것은 콜백 핸들러의 RenegotiateMedia()를 호출한다;

ii. HandleTransfer() - 이것은 콜백 핸들러의 Transfer()를 호출한다;

iii. RenegotiateMedia() - 이것은 AcceptedCall2.RenegotiateMedia()를 호출한다. 이것은, UserBFacingAcceptedCall 객체를 목표로 하는 미디어 재협상 메시지를 전송하는 것에 의해 UserB가 미디어 재협상을 시작할 때 호출되는 메소드이다;

iv. Transfer() - 이것은 AcceptedCall2.Transfer()를 호출한다. 이것은 UserBFacingAcceptedCall 객체를 목표로 하는 전송 메시지를 전송하는 것에 의해 UserB가 전송을 시작할 때 호출되는 메소드이다;

13. 상기에서 언급되는 바와 같이, ForkedCall31.Accept()는 또한, 다음의 특성을 갖는 AcceptedCall2를 생성하는 ForkedCall2.Accept()를 호출한다:

a. 상태:

i. UserBFacingAcceptedCall에 대한 참조;

ii. ForkedCall1.Accept()가 ForkedCall1.Accept()의 일부로서 호출될 때 생성되는 AcceptedCall1 객체에 대한 참조.

b. 메소드:

i. UserBFacingAcceptedCall과 동일;

14. 마찬가지로 ForkedCall2.Accept()는 또한, 다음의 특성을 갖는 AcceptedCall1을 생성하는 ForkedCall1.Accept()을 호출한다:

a. 상태:

i. AcceptedCall2에 대한 참조;

ii. Call0.Accept()가 Call0.Accept()의 일부로서 호출될 때 생성되는 UserAFacingAcceptedCall 객체에 대한 참조;

b. 메소드:

i. 다른 AcceptedCall 객체와 동일.

15. ForkedCall1.Accept()는 또한, 다음 특성을 갖는 UserAFacingAcceptedCall을 생성하는 Call0.Accept()를 호출한다:

a. 상태:

i. AcceptedCall1에 대한 참조;

ii. UserA가 자신의 중간 호 콜백 URL을 갖는 CallAcceptanceAcknowlegement 메시지를 전송할 때 생성되는 UserAFacingAcceptedCallCallbackHandler에 대한 참조;

b. 메소드:

i. 다른 AcceptedCall 객체와 동일.

16. Call0.Accept()는 또한, 수락 URL 상에서 CallAcceptance 메시지를 전송하는 UserAFacingCallbackHandler.Accept()를 호출한다

17. CallAcceptance의 수신시, UserA의 엔드포인트는 중간 호 콜백 URL을 갖는 CallAcceptanceAcknowledgement 메시지를 전송한다.

18. 호 컨트롤러는, 상태로서 이들 콜백 URL을 갖는, 그리고 다음의 메소드를 갖는 UserAFacingAcceptedCallCallbackHandler 객체를 생성한다:

a. 미디어 재협상 url을 사용하여 mediaRengotiation 메시지를 UserA에게 되전송하는 RenegotiateMedia();

b. 전송 url을 사용하여 UserA에게 전송 메시지를 되전송하는 Transfer().

활성 호에 대해 생성되는 런타임 그래프(1600)가 도 16에서 예시된다. 런타임 그래프(1600)는 호에 대한 활성 호 상태이며, 프로세서가 직접 액세스하는 메모리에서 그것이 실현된다는 점에서 활성이다.

UserA가 수행하는 임의의 중간 호 동작은 UserAFacingAcceptedCall 상에서의 적절한 메소드의 호출로 귀결된다.

예를 들면, UserA에 의해 트리거되는 미디어 재협상은, 다음의 객체 호출의 시퀀스로 귀결될 것이다:

UserAFacingAcceptedCall.RenegotiateMedia() ->

AcceptedCall1.HandleMediaRenegotiation() ->

AcceptedCall2.HandleMediaRenegotiation() ->

UserBFacingAcceptedCall.HandleMediaRengotiation() ->

UserBFacingAcceptedCallCallbackHandler.RegegotiateMedia() ->

UserB에 의해 전송되는 mediaRenegotiation 콜백 URL 상에서 전송되는 미디어 재협상 메시지.

마찬가지로, UserB가 수행하는 임의의 중간 호 동작은 UserBFacingAcceptedCall 상에서의 적절한 메소드의 호출로 귀결된다.

예를 들면, UserB에 의해 트리거되는 미디어 재협상은 다음과 같이 귀결될 것이다:

UserBFacingAcceptedCall.RegegotiateMedia() ->

AcceptedCall2.HandleMediaRenegotiation() ->

AcceptedCall1.HandleMediaRenegotiation() ->

UserAFacingAcceptedCall.HandleMediaRengotiation() ->

UserAFacingAcceptedCallCallbackHandler.RegegotiateMedia() ->

UserA에 의해 전송되는 mediaRenegotiation 콜백 URL 상에서 전송되는 미디어 재협상 메시지.

임의의 중간 호 동작이 임의의 인스턴스 상에서 수행될 수 있다는 것을 보장하기 위해, 전체 런타임 객체 그래프가 임의의 인스턴스 상에서 부활될 수 있다는 것을 보장할 필요가 있다.

이것은, 호 수락에 대한 객체 그래프가 직렬화되어야 하고 상기에서 설명되는 방식으로 높은 가용성의 외부 저장소에 저장되어야 한다는 것을 의미한다.

일단 적절한 형태로 변환되면, 그래프의 적절한 부분은, 임의의 객체로부터 시작하는(상기 예에서, UserAFacingAcceptedCall 또는 UserBFacingAcceptedCall로부터 시작할 수 있다) 참조의 체인을 따르는 것에 의해 부활될 수 있다.

일반적으로, 본원에서 설명되는 기능 중 임의의 것은, 소프트웨어, 펌웨어, 하드웨어(예를 들면, 고정식 로직 회로부), 또는 이들 구현예의 조합을 사용하여 구현될 수 있다. 본원에서 사용되는 바와 같은 용어 "모듈", "기능성", "컴포넌트" 및 "로직"은 소프트웨어, 펌웨어, 하드웨어, 또는 이들의 조합을 일반적으로 나타낸다. 소프트웨어 구현예의 경우, 모듈, 기능성, 또는 로직은, 프로세서(예를 들면, CPU 또는 CPU들) 상에서의 실행시 명시된 태스크를 수행하는 프로그램 코드를 나타낸다. 프로그램 코드는 하나 이상의 컴퓨터 판독가능 메모리 디바이스에 저장될 수 있다. 하기에서 설명되는 기술의 특징은 플랫폼 독립적인데, 그 기술이 다양한 프로세서를 구비하는 다양한 상업적 컴퓨팅 플랫폼 상에서 구현될 수도 있다는 것을 의미한다.

예를 들면, 유저 디바이스(유저 단말)은, 유저 단말의 하드웨어로 하여금 동작, 예를 들면, 프로세서 기능 블록, 및 등을 수행하게 하는 엔티티(예를 들면 소프트웨어)를 또한 포함할 수도 있다. 예를 들면, 유저 단말은, 유저 단말, 특히 유저 단말의 오퍼레이팅 시스템 및 관련 하드웨어로 하여금 동작을 수행하게 하는 명령어를 유지하도록 구성될 수도 있는 컴퓨터 판독가능 매체를 포함할 수도 있다. 따라서, 명령어는, 동작을 수행하게끔 오퍼레이팅 시스템 및 관련 하드웨어를 구성시키도록 기능하고 이 방식에서는 기능을 수행하는 오퍼레이팅 시스템 및 관련 하드웨어의 변환으로 나타나게 된다. 명령어는 컴퓨터 판독가능 매체에 의해 다양하고 상이한 구성을 통해 유저 단말로 제공될 수도 있다.

컴퓨터 판독가능 매체의 하나의 이러한 구성은 신호 베어링 매체(signal bearing medium)이며 따라서, 예컨대 네트워크를 통해, 명령어를 (예를 들면, 반송파로서) 컴퓨팅 디바이스로 송신하도록 구성된다. 컴퓨터 판독가능 매체는 컴퓨터 판독가능 저장 매체로서 또한 구성될 수도 있으며 따라서 신호 베어링 매체가 아니다. 컴퓨터 판독가능 저장 매체의 예는 랜덤 액세스 메모리(random-access memory; RAM), 리드 온리 메모리(read-only memory; ROM), 광학 디스크, 플래시 메모리, 하드 디스크 메모리, 및 명령어 및 다른 데이터를 저장하기 위해 자기, 광학 및 다른 기술을 사용할 수도 있는 다른 메모리 디바이스를 포함한다.

제1 양태에 따르면, 방법은, 통신 네트워크를 통해 클라이언트 디바이스의 유저와 다른 클라이언트 디바이스의 다른 유저 사이에서 실시간 통신 이벤트를 확립하기 위한 것이다. 그 방법은 클라이언트 디바이스 상에서 실행하는 클라이언트가, 네트워크를 통해 다른 클라이언트 디바이스로 또는 네트워크에 접속된 서버로 메시지를 송신하는 것에 의해 통신 이벤트 확립 프로시져의 제1 단계를 수행하는 것을 포함한다. 메시지는 아직 수행되지 않은 통신 이벤트 확립 프로세스의 제2 단계에 관련이 있는 다수의 옵션을 포함한다. 메시지는, 다수의 옵션의 각각에 대해, 그 옵션을 선택하기 위해 액세스될 수 있는 그 옵션에 고유한 상이한 네트워크 어드레스를 포함한다. 그 방법은: 다수의 옵션 중 하나에 고유한 네트워크 어드레스가 액세스되었다는 것을 검출하는 것; 및 응답으로, 다수의 옵션 중 상기 하나에 따라 통신 이벤트 확립 프로시져의 제2 단계를 실시 유도하는 것을 더 포함한다.

제1 실시형태에서, 메시지는 서버로 전송될 수도 있고, 방법은 서버가: 다수의 옵션 중 상기 하나에 고유한 네트워크 어드레스와 서버 네트워크 어드레스 사이의 매핑을 저장하는 것; 서버 네트워크 어드레스를 다른 클라이언트 디바이스로 또는 네트워크에 접속된 추가 서버로 송신하는 것; 서버 네트워크 어드레스가 액세스되었는다는 것을 검출하는 것; 및 응답으로, 제1 양태의 실시 유도 단계를 트리거하기 위해 클라이언트에 의해 검출되는 다수의 옵션 중 상기 하나에 고유한 네트워크 어드레스에 액세스하는 것을 포함한다. 제2 실시형태에서, 방법은 추가 서버가: 서버 네트워크 어드레스와 추가 서버 네트워크 어드레스 사이의 다른 매핑을 저장하는 것; 추가 서버 네트워크 어드레스를 다른 클라이언트 디바이스로 또는 또 다른 추가 서버(yet further server)로 송신하는 것; 추가 서버 네트워크 어드레스가 액세스되었다는 것을 검출하는 것; 및 응답으로, 제1 실시형태의 액세스 단계를 트리거하기 위해 서버에 의해 검출되는 서버 네트워크 어드레스에 액세스하는 것을 더 포함할 수도 있다.

제3 실시형태에서, 메시지는 서버로 송신될 수도 있고, 방법은: 각각의 네트워크 어드레스에 대해, 서버가, 네트워크 어드레스와 대응하는 서버 네트워크 어드레스 사이의 맵핑을 저장하는 것, 그 네트워크 어드레스를 대응하는 서버 네트워크 어드레스로 대체하도록 메시지를 수정하는 것, 및 수정된 메시지를 다른 클라이언트 디바이스로 또는 네트워크에 접속된 추가 서버로 송신하는 것; 서버가, 다수의 옵션 중 상기 하나에 고유한 네트워크 어드레스에 대응하는 서버 네트워크 어드레스가 액세스되었다는 것을 검출하는 것; 및 응답으로, 서버가, 제1 양태의 실시 유도 단계를 트리거하기 위해 클라이언트에 의해 검출되는, 다수의 옵션 중 상기 하나에 고유한 네트워크 어드레스에 액세스하는 것을 포함할 수도 있다. 제4 실시형태에서, 대응하는 네트워크 어드레스는 추가 서버로 송신될 수도 있고, 방법은: 추가 서버가, 대응하는 네트워크 어드레스와 추가 대응하는 서버 네트워크 어드레스(further corresponding server network address) 사이의 다른 매핑을 저장하는 것, 대응하는 서버 네트워크 어드레스를 추가적으로 대응하는 네트워크 어드레스로 대체하도록 메시지를 추가로 수정하는 것, 및 추가 수정된 메시지를 다른 클라이언트 디바이스로 또는 네트워크에 접속된 또 다른 추가 서버로 송신하는 것; 추가 서버가, 다수의 옵션 중 상기 하나에 고유한 네트워크 어드레스에 대응하는 서버 네트워크 어드레스에 대응하는 추가 서버 네트워크 어드레스가 액세스되었다는 것을 검출하는 것; 및 응답으로, 추가 서버가, 제3 실시형태의 액세스 단계를 트리거하기 위해 서버에 의해 검출되는, 다수의 옵션 중 상기 하나에 고유한 네트워크 어드레스에 대응하는 서버 네트워크 어드레스에 액세스하는 것을 포함한다.

클라이언트 디바이스와 프록시 서버 - 네트워크 어드레스는 프록시 서버의 것임 - 사이에서 접속이 확립될 수도 있고; 제1 양태의 검출 단계는, 클라이언트가, 접속을 통해 수신되는 신호 - 신호는 다수의 옵션 중 상기 하나에 고유한 네트워크 어드레스가 액세스되었다는 것을 나타냄 - 를 검출하는 것을 포함할 수도 있다. 접속은 웹소켓 접속일 수도 있다.

네트워크 어드레스는 URI, 예컨대 URL일 수도 있다. 다수의 옵션 중 상기 하나에 고유한 네트워크 어드레스는, 예를 들면 POST 또는 DELETE 요청 메소드를 사용하여 HTTP 프로토콜에 따라 액세스될 수도 있다.

제2 양태에 따르면, 서버는, 통신 네트워크를 통해 클라이언트 디바이스의 유저와 다른 클라이언트 디바이스의 다른 유저 사이에서 실시간 통신 이벤트를 달성하기 위한 것이다. 상기 서버는 다음을 포함한다: 컴퓨터 스토리지; 네트워크로부터 메시지를 수신하도록 구성되는 네트워크 인터페이스; 및 프로세서. 프로세서는 메시지를 수신하도록 구성된다. 메시지는 통신 이벤트에 관련이 있는 다수의 옵션, 및, 다수의 옵션의 각각에 대해, 그 옵션을 선택하기 위해 액세스될 수 있는 그 옵션에 고유한 상이한 네트워크 어드레스를 포함한다. 프로세서는 또한, 다수의 네트워크 어드레스 각각에 대해, 네트워크 어드레스와 대응하는 서버 네트워크 어드레스 사이의 매핑을 컴퓨터 스토리지에 저장하도록, 서버 네트워크 어드레스를 다른 클라이언트 디바이스로 또는 네트워크에 접속된 추가 서버(further server)로 송신하도록 구성된다. 프로세서는 또한, 다수의 옵션 중 하나에 고유한 네트워크 어드레스에 대응하는 서버 네트워크 어드레스가 액세스되었는다는 것을 검출하도록, 그리고 응답으로, 그 옵션을 선택하기 위해 그 옵션에 고유한 네트워크 어드레스에 액세스하도록 구성된다.

프로세서는 컴퓨터 스토리지에 메시지를 기록하도록 구성될 수도 있다. 프로세서는 컴퓨터 스토리지에 통신 이벤트의 지속 기간을 기록하도록 구성될 수도 있다.

추가 서버로 하여금 응답으로 통신 이벤트에 관련이 있는 액션을 수행하게 하기 위해, 메시지는 추가 서버로 송신될 수도 있다. 프로세서는: 상기 통신 이벤트에 관련이 있는 다른 메시지 - 메시지는 통신 이벤트에 관련이 있는 다른 옵션 및 다른 옵션을 선택하기 위해 액세스될 수 있는 다른 옵션에 고유한 다른 네트워크 어드레스를 포함함 - 를 수신하도록; 다른 네트워크 어드레스와 다른 대응하는 서버 네트워크 어드레스 사이의 다른 매핑을 컴퓨터 스토리지에 저장하도록; 그리고 통신 이벤트에 관련이 있는 다른 액션을 수행하기 위해, 다른 대응하는 네트워크 어드레스를, 추가 서버와는 상이한 네트워크의 다른 서버로 송신하도록 구성될 수도 있다.

네트워크 어드레스 및 (추가) 서버 네트워크 어드레스는 URI, 예컨대 URL일 수도 있다. 다수의 옵션 중 상기 하나에 고유한 네트워크 어드레스는 HTTP 프로토콜에 따라 액세스될 수도 있다.

제3 양태에 따르면, 방법은 서비스를 전달하기 위한 것이며, 방법은, 프로세서, 프로세서가 액세스가능한 메모리 및 컴퓨터 스토리지를 포함하는 컴퓨터 시스템에 의해 구현된다. 메모리는 서비스 객체 클래스를 정의하는 코드를 유지한다. 서비스 객체 클래스는 서비스 함수를 제공하도록 구성된다. 방법은 다음 단계를 포함한다. 적어도 하나 이상의 서비스 실시 유도 메시지(service instigation message)가 수신된다. 적어도 하나의 서비스 실시 유도 메시지에 응답하여, 서비스 객체 클래스는 서비스 객체를 생성하도록 인스턴스화된다. 서비스 객체는 서비스를 전달하기 위해 서비스 함수를 구현한다. 각각의 서비스 객체는 메모리에 유지되는 관련 상태 데이터(associated state data)를 가지며, 서비스 객체 중 적어도 일부는 다른 서비스 객체를 참조한다. 각각의 서비스 객체에 대해, 그 서비스 객체를 임의의 다른 서비스 객체와 구별하는 관련 서비스 객체 식별자가 메모리에서 생성된다. 서비스 객체는 직렬화되어 직렬화된 데이터를 생성하는데, 직렬화된 데이터는 각각의 서비스 객체의 표현을 포함하고, 표현은 서비스 객체의 서비스 객체 식별자, 그 서비스 객체의 관련 상태 데이터 및 그 서비스 객체에 의해 참조되는 임의의 다른 서비스 객체의 서비스 객체 식별자를 포함한다. 직렬화된 데이터는 컴퓨터 스토리지에 저장된다. 서비스 객체가 비활성화되면, 재활성화될 서비스 객체를 식별하는 서비스 재활성화 메시지가 수신되고, 식별된 서비스 객체에 대해 재활성화 프로세스가 수행된다. 재활성화 프로세스는: 식별된 서비스 객체를 직렬화된 데이터 내에서의 그것의 표현으로부터 재활성화하는 것, 식별된 서비스 객체가, 서비스 함수를 구현하는데 필요로 되는 적어도 하나의 서비스 객체를 참조하는 경우, 참조된 적어도 하나의 서비스 객체에 대해 재활성화 프로세스를 반복하고, 그에 의해 비활성화된 서비스 객체의 적어도 일부를 대체하기 위한 서비스 객체의 대체 세트를 생성하는 것을 포함한다.

실시형태에서, 방법은, 통신 네트워크의 엔드포인트 사이에서 통신 이벤트를 확립하기 위한 그리고 확립된 통신 이벤트를 관리하기 위한 것일 수도 있다; 서비스 요청 메시지는 통신 이벤트 확립 요청일 수도 있고, 서비스 객체는 통신 이벤트를 확립하기 위해 생성될 수도 있다; 서비스 재활성화 메시지는 확립된 통신 이벤트에 관련이 있는 액션을 요청할 수도 있으며, 서비스 객체의 대체 세트는 요청된 액션을 달성할 수도 있다.

액션은, 예를 들면, 다음의 것일 수도 있다:

- 통신 이벤트를 종료하는 것;

- 통신 이벤트에/로부터 참가자를 추가 또는 제거하는 것;

- 통신 이벤트의 참가자의 음소거 또는 음소거 해제;

- 통신 이벤트를 보류 상태로 두는 것; 또는

- 통신 이벤트에/로부터 미디어 모달리티를 추가 또는 제거하는 것.

통신 이벤트는 호일 수도 있다.

코드는 각각의 서비스 객체 클래스에 대한 대응하는 팩토리 객체 클래스를 정의할 수도 있는데, 각각의 팩토리 객체 클래스는 직렬화된 데이터 내에서의 표현으로부터 그 서비스 객체 클래스의 서비스 객체를 생성하기 위한 서비스 객체 재활성화 함수를 제공하도록 구성되며, 방법은 다음을 포함할 수도 있다:

● 각각의 서비스 객체 클래스에 대해, 대응하는 팩토리 객체 클래스를 인스턴스화하여, 그 팩토리 객체 클래스에 의해 제공되는 서비스 객체 재활성화 함수를 구현하도록 구성되는 대응하는 팩토리 객체를 생성하는 것;

● 각각의 팩토리 객체에 대해, 그 팩토리 객체를 임의의 다른 팩토리 객체와 구별하는 관련 팩토리 객체 식별자를 메모리에서 생성하는 것;

● 각각의 서비스 객체의 표현은, 그 서비스 객체의 서비스 객체 클래스에 대응하는 팩토리 객체의 팩토리 객체 식별자를 더 포함할 수도 있다;

● 서비스 재활성화 메시지는, 식별된 서비스 객체의 서비스 객체 클래스에 대응하는 팩토리 객체를 식별할 수도 있고, 식별된 서비스 객체에 대한 재활성화 프로세스를 수행하는 것은 다음을 포함할 수도 있다:

● 식별된 서비스 객체를 재활성화하기 위해 직렬화된 데이터에서의 식별된 서비스 객체의 표현에 대해 자신의 서비스 객체 재활성화 함수를 구현하는 식별된 대응하는 팩토리 객체.

코드는 객체 획득 함수(get object function)를 제공하도록 구성되는 참조 객체 클래스를 정의할 수도 있으며, 방법은: 각각의 서비스 객체에 대해, 대응하는 참조 객체 - 대응하는 참조 객체는 메모리 내의 임의의 위치에 대한 어떠한 메모리 포인터도 포함하지 않는 그러나 그 서비스 객체의 서비스 객체 식별자를 포함하는, 메모리에 유지되는 관련 상태 데이터를 구비함 - 를 생성하기 위해 지속된 객체 참조 클래스를 인스턴스화하는 것을 포함할 수도 있고; 적어도 하나의 서비스 객체에 대한 재활성화 프로세스는, 참조 객체가 비활성화된 경우에 수행될 수도 있고, 적어도 하나의 서비스 객체의 표현에서의 서비스 객체 식별자를 사용하여 적어도 하나의 서비스 객체에 대응하는 참조 객체를 재활성화하는 것을 포함할 수도 있고; 객체 획득 함수는, 재활성화된 참조 객체 상에서 호출될 때, 적어도 하나의 서비스 객체의 표현으로부터 적어도 하나의 서비스 객체를 재활성화하도록 구성되고, 적어도 하나의 서비스 객체는 재활성화된 참조 객체 상에서 객체 획득 함수를 호출하는 것에 의해 재활성화된다.

객체 획득 함수는, 적어도 하나의 서비스 객체가 비활성화되기 전에 재활성화된 참조 객체 상에서 다시 호출될 때, 재활성화된 적어도 하나의 서비스 객체로 메모리 포인터를 리턴하도록 구성될 수도 있고, 그에 따라 단지 하나의 대체 서비스 객체가 생성되어 적어도 하나의 서비스 객체를 대체한다.

서비스 객체 중 적어도 일부의 각각에 대해, 그 서비스 객체의 관련 서비스 객체 식별자를 포함하는 관련 네트워크 어드레스가 생성될 수도 있고, 서비스 재활성화 메시지는, 재활성화될 서비스 객체와 관련되는 네트워크 어드레스에서 수신될 수도 있는데, 재활성화될 서비스 객체는 네트워크 어드레스로부터 식별된다.

각각의 네트워크 어드레스는 URI(예를 들면, URL)일 수도 있고, 방법은 재활성화될 서비스를 식별하기 위해 재활성화될 서비스 객체와 관련되는 URI를 파싱하는 것을 포함할 수도 있다.

방법은 각각의 재활성화된 서비스 객체에 대한 각각의 메모리 포인터를 캐싱하는 것을 포함할 수도 있으며, 재활성화 프로세스가, 이미 재활성화된 서비스 객체에 대해 그리고 이미 재활성화된 서비스 객체가 비활성화되기 전에 수행되면, 재활성화 프로세스는 메모리 포인터를 이미 재활성화된 서비스 객체로 리턴하고, 그에 따라, 단지 하나의 각각의 대체 서비스 객체가 생성되어 각각의 재활성화된 서비스 객체를 대체한다.

서비스 실시 유도 메시지는 코드의 인스턴스에 의해 수신될 수도 있는데, 인스턴스는 수신, 인스턴스화, 생성, 직렬화 및 저장의 단계를 수행하고; 서비스 재활성화 메시지는 코드의 다른 인스턴스에 의해 수신될 수도 있고, 그 인스턴스는 재활성화 프로세스를 수행할 수도 있다.

서비스 재활성화 메시지는 코드의 인스턴스에 의해 수신될 수도 있고, 인스턴스는 데이터베이스에 액세스하여, 직렬화된 데이터를 현재 소유하고 있는 것으로서 코드의 다른 인스턴스를 식별하는 유효한 소유권 엔트리를 데이터베이스가 포함하는지 여부를 결정하고:

● 만약 그렇다면, 인스턴스는, 다른 인스턴스가 재활성화 프로세스를 수행하도록, 서비스 재활성화 메시지를 다른 인스턴스로 포워딩하고,

● 만약 그렇지 않다면, 인스턴스는, 직렬화된 상태 데이터를 현재 소유하고 있는 것으로서 인스턴스를 식별하는 유효한 소유권 엔트리를 데이터베이스에서 생성하고, 인스턴스는 재활성화 프로세스를 수행한다.

각각의 소유권 엔트리는, 그 소유권 엔트리가 생성된 이후, 미리 결정된 양의 시간이 경과하면, 무효화될 수도 있다. 각각의 인스턴스는, 그 인스턴스를 현재 살아있는 것으로 식별하는 유효한 하트비트 메시지를 데이터베이스에 주기적으로 기록하도록 구성될 수도 있는데, 각각의 하트비트 메시지는, 그 하트비트 메시지가 생성된 이후 다른 미리 결정된 양의 시간이 경과하면 무효화되고, 다른 인스턴스가 유효한 하트비트 메시지에 의해 살아있는 것으로 식별되는 경우에만 서비스 재활성화 메시지가 다른 인스턴스로 포워딩되도록, 각각의 소유권 엔트리는 자신이 식별하는 인스턴스가 유효한 하트비트 메시지에 의해 살아있는 것으로 또한 식별되는 경우에만 유효하다.

직렬화된 데이터는 메모리에서 생성될 수도 있고, 모든 서비스 객체가 직렬화될 때 단일의 기록 동작을 수행하는 것에 의해 메모리로부터 컴퓨터 스토리지에 기록될 수도 있다.

재활성화 메시지를 수신하는 것에 응답하여, 서비스 객체의 대체 세트를 생성하는데 필요로 되는 모든 상태 데이터는, 단일 기록 동작을 수행하는 것에 의해 컴퓨터 스토리지로부터, 메모리 또는 컴퓨터 시스템의 다른 프로세서가 액세스가능한 다른 메모리에 로딩될 수도 있고, 대체 세트는 그 또는 다른 메모리에 로딩된 직렬화된 데이터로부터 생성될 수도 있다.

제4 양태에 따르면, 컴퓨터 시스템은: 메시지를 수신하도록 구성되는 입력부(input); 컴퓨터 스토리지; 프로세서; 프로세서가 액세스가능한 메모리를 포함한다. 메모리는 서비스 객체 클래스를 정의하는 코드를 유지하는데, 각각의 서비스 객체 클래스는 서비스 함수를 제공하도록 구성된다. 프로세서는, 적어도 하나의 서비스 실시 유도 메시지에 응답하여, 다음을 하도록 구성된다:

● 서비스 객체 클래스를 인스턴스화하여 서비스 객체를 생성하는 것 - 서비스 객체는 서비스를 전달하는 서비스 함수를 구현하고, 각각의 서비스 객체는 메모리에 유지되는 관련 상태 데이터를 구비하고, 서비스 객체 중 적어도 일부는 다른 서비스 객체를 참조함 - ;

● 각각의 서비스 객체에 대해, 그 서비스 객체를 임의의 다른 서비스 객체와 구별하는 관련 서비스 객체 식별자를 메모리에서 생성하는 것;

● 서비스 객체를 직렬화하여 직렬화된 데이터를 생성하는 것 - 직렬화된 데이터는 각각의 서비스 객체의 표현을 포함하고, 표현은 서비스 객체의 서비스 객체 식별자, 그 서비스 객체의 관련 상태 데이터 및 그 서비스 객체에 의해 참조되는 임의의 다른 서비스 객체의 서비스 객체 식별자를 포함함 - ; 및

● 직렬화된 데이터를 컴퓨터 스토리지에 저장하는 것.

컴퓨터 시스템의 그 또는 다른 프로세서는, 서비스 객체가 비활성화되고 서비스 재활성화 메시지가 재활성화될 서비스 객체를 식별하는 것에 응답하여, 다음을 포함하는, 식별된 서비스 객체 재활성화 프로세스에 대한 재활성화 프로세스를 수행하도록 구성된다:

● 식별된 서비스 객체를 직렬화된 데이터에서의 그것의 표현으로부터 재활성화하는 것, 및

● 식별된 서비스 객체가 서비스 함수를 구현하는데 필요로 되는 적어도 하나의 서비스 객체를 참조하는 경우, 참조된 적어도 하나의 서비스 객체에 대한 재활성화 프로세스를 반복하고, 그에 의해 비활성화된 서비스 객체의 적어도 일부를 대체할 서비스 객체의 대체 세트를 생성하는 것.

상기 컴퓨터 시스템은 클라우드 플랫폼일 수도 있고, 그에 의해, 그 및 다른 프로세서 각각은 복수의 가상 머신을 실행하도록 구성되는데, 코드의 인스턴스는 복수의 가상 머신의 각각에서 실행된다.

코드는 통신 네트워크의 엔드포인트 사이에서 통신 이벤트를 확립하기 위한 그리고 확립된 통신 이벤트를 관리하기 위한 호 컨트롤러를 구현하도록 구성될 수도 있는데, 서비스 요청 메시지는 통신 이벤트 확립 요청이고 서비스 객체는 통신 이벤트를 확립하기 위해 호 컨트롤러의 인스턴스에 의해 생성되고; 예를 들면:

서비스 활성화 메시지는 호 컨트롤러의 그 또는 다른 호 인스턴스에 의해 수신되거나;

또는 코드는 확립된 통신 이벤트의 미디어 모달리티를 관리하기 위한 미디어 컨트롤러를 구현하도록 구성되고, 서비스 재활성화 메시지는 미디어 컨트롤러의 인스턴스에 의해 수신되고;

어느 경우든, 서비스 재활성화 메시지는 확립된 통신 이벤트에 관련이 있는 액션을 요청하고, 서비스 객체의 대체 세트는 요청된 액션을 달성한다.

제5 양태에 따르면, 컴퓨터 프로그램 제품은, 컴퓨터 판독가능 저장 매체 상에 저장되며, 실행시, 제1 및 제3 양태의 방법, 제2 양태의 서버의 기능성, 및 제4 양태의 컴퓨터 시스템을 비롯한, 본원에서 개시되는 방법 또는 시스템 중 임의의 것을 구현하도록 구성되는 코드를 포함한다.

비록 본 주제가 구조적 피쳐 및/또는 방법론적 액트(act)에 고유한 언어로 설명되었지만, 첨부의 청구범위에서 정의되는 주제는 상기에서 설명되는 특정한 피쳐 또는 액트로 반드시 제한되는 것은 아니다는 것이 이해되어야 한다. 오히려, 상기에서 설명되는 특정 피쳐 및 액트는 청구범위를 구현하는 예시적인 형태로서 개시된다.

Claims (20)

1. 컴퓨터 구현 방법에 있어서,
   적어도 하나의 서비스 실시 유도 메시지(service instigation message)를 수신하는 단계;
   상기 적어도 하나의 서비스 실시 유도 메시지를 수신하는 것에 응답하여, 서비스 함수(service function)들을 제공하도록 구성되는 서비스 객체들을 생성하기 위하여 하나 이상의 서비스 객체 클래스를 인스턴스화하는 단계 ― 상기 서비스 객체들 중 적어도 일부는 다른 서비스 객체들을 참조함 ― ;
   각각의 서비스 객체에 대해, 해당 서비스 객체를 임의의 다른 서비스 객체와 구별하는 연관된 서비스 객체 식별자를 발생시키는 단계;
   각각의 개별적인 서비스 객체에 대해, 상기 서비스 객체 식별자, 연관된 상태 데이터, 참조된 임의의 다른 서비스 객체의 서비스 객체 식별자를 포함하는 직렬화된 데이터를 발생시키기 위하여 상기 서비스 객체를 직렬화하는 단계;
   상기 직렬화된 데이터를 저장하는 단계;
   재활성화될 비활성화된 서비스 객체를 식별하는 서비스 재활성화 메시지를 수신하는 단계; 및
   상기 식별된 서비스 객체에 대한 재활성화 프로세스를 수행하는 단계
   를 포함하고, 상기 재활성화 프로세스는:
   상기 직렬화된 데이터로부터 상기 식별된 서비스 객체를 재활성화하는 단계;
   상기 식별된 서비스 객체의 서비스 함수에 필요한 각각의 연관된 서비스 객체에 대해 상기 재활성화 프로세스를 반복하여, 재활성화된 서비스 객체들의 대체 세트를 생성하는 단계; 및
   상기 대체 세트가 상기 재활성화된 서비스 객체들 각각의 단 하나의 인스턴스만을 포함하는 것을 보장하게 하기 위해, 이미 재활성화된 연관된 서비스 객체에 대한 상기 재활성화 프로세스의 수행이 캐싱된 메모리 포인터로 하여금 상기 연관된 서비스 객체로 리턴되게 하도록, 상기 재활성화된 서비스 객체들 각각에 각각의 메모리 포인터를 캐싱하는 단계
   를 포함하는, 컴퓨터 구현 방법.
2. 제1항에 있어서,
   상기 서비스 실시 유도 메시지는 통신 이벤트 확립 요청이고, 상기 서비스 객체들은 통신 이벤트를 확립하기 위해 생성되며, 상기 서비스 재활성화 메시지는 상기 확립된 통신 이벤트에 관련되는 액션을 요청하고, 상기 재활성화된 서비스 객체들의 대체 세트는 상기 확립된 통신 이벤트에 관련되는 상기 요청된 액션을 실시하는 것인, 컴퓨터 구현 방법.
3. 제2항에 있어서,
   상기 확립된 통신 이벤트에 관련되는 액션은:
   - 상기 확립된 통신 이벤트를 종료하는 것;
   - 상기 확립된 통신 이벤트에 참가자를 추가하거나 또는 상기 확립된 통신 이벤트로부터 참가자를 제거하는 것;
   - 상기 확립된 통신 이벤트의 참가자의 음소거화(muting) 또는 음소거화 해제(unmuting);
   - 상기 확립된 통신 이벤트를 보류 상태로 두는 것; 또는
   - 상기 확립된 통신 이벤트에 미디어 모달리티(media modality)를 추가하거나 또는 상기 확립된 통신 이벤트로부터 미디어 모달리티를 제거하는 것인, 컴퓨터 구현 방법.
4. 제3항에 있어서,
   상기 확립된 통신 이벤트는 호(call)인 것인, 컴퓨터 구현 방법.
5. 제1항에 있어서,
   상기 하나 이상의 서비스 객체 클래스는 팩토리 객체 클래스(factory object class)들이고, 각각의 팩토리 객체 클래스는 상기 직렬화된 데이터로부터 서비스 객체들을 생성하기 위한 서비스 객체 재활성화 함수를 제공하도록 구성되고,
   상기 방법은:
   해당 팩토리 객체 클래스에 의해 제공되는 상기 서비스 객체 재활성화 함수를 구현하도록 구성되는 대응 팩토리 객체를 발생시키기 위하여 각각의 팩토리 객체 클래스를 인스턴스화하는 단계; 및
   각각의 팩토리 객체에 대해, 해당 팩토리 객체를 임의의 다른 팩토리 객체와 구별하는 연관된 팩토리 객체 식별자를 발생시키는 단계
   를 포함하고,
   각각의 서비스 객체는 대응 서비스 객체 클래스에 대한 상기 팩토리 객체 식별자를 더 포함하고;
   상기 서비스 재활성화 메시지는, 상기 대응 서비스 객체 클래스에 대한 상기 팩토리 객체를 식별하고, 상기 식별된 서비스 객체에 대한 상기 재활성화 프로세스를 수행하는 단계는;
   상기 식별된 대응 팩토리 객체가, 상기 식별된 서비스 객체를 재활성화하기 위해 상기 직렬화된 데이터에 대해 상기 서비스 객체 재활성화 함수를 구현하는 단계
   를 포함하는 것인, 컴퓨터 구현 방법.
6. 제1항에 있어서,
   하나 이상의 서비스 객체 클래스는 객체 획득 함수(get object function)를 제공하도록 구성되는 참조 객체 클래스(reference object class)들이고, 상기 방법은:
   참조 객체 클래스에 대응하는 각각의 서비스 객체에 대해: 대응 참조 객체를 발생시키기 위해 상기 참조 객체 클래스를 인스턴스화하는 단계 ― 상기 대응 참조 객체는, 메모리 포인터를 포함하지 않지만 해당 서비스 객체의 상기 서비스 객체 식별자는 포함하는, 연관된 상태 데이터를 가짐 ― 를 포함하고;
   상기 식별된 서비스 객체에 대한 상기 재활성화 프로세스는, 상기 대응 참조 객체가 비활성화된 경우에 수행되고, 상기 서비스 객체 식별자를 사용하여 상기 식별된 서비스 객체에 대응하는 상기 참조 객체를 재활성화하는 단계를 포함하고;
   상기 객체 획득 함수는, 상기 재활성화된 참조 객체 상에서 인보크될(invoked) 때, 상기 재활성화된 참조 객체 상에서 상기 객체 획득 함수를 인보크하는 것에 의해 상기 식별된 서비스 객체를 재활성화하도록 구성되는 것인, 컴퓨터 구현 방법.
7. 제6항에 있어서,
   상기 객체 획득 함수는, 상기 식별된 서비스 객체가 비활성화되기 전에 상기 재활성화된 참조 객체 상에서 다시 인보크될 때, 상기 식별된 서비스 객체를 대체하기 위해 단일의 대체 서비스 객체만이 생성되게끔, 상기 재활성화된 서비스 객체에 메모리 포인터를 리턴시키도록 구성되는 것인, 컴퓨터 구현 방법.
8. 제1항에 있어서,
   상기 서비스 객체들 중 적어도 일부 각각에 대해, 각각의 서비스 객체의 연관된 서비스 객체 식별자를 포함하는 연관된 네트워크 어드레스가 발생되고, 상기 서비스 재활성화 메시지는, 재활성화될 상기 서비스 객체와 연관되는 상기 네트워크 어드레스에서 수신되고, 재활성화될 상기 서비스 객체는 상기 네트워크 어드레스로부터 식별되는 것인, 컴퓨터 구현 방법.
9. 제8항에 있어서,
   각각의 네트워크 어드레스는 URI이고, 상기 방법은 재활성화될 상기 서비스를 식별하기 위하여 재활성화될 상기 서비스 객체와 연관되는 상기 URI를 파싱(parsing)하는 단계를 포함하는 것인, 컴퓨터 구현 방법.
10. 제1항에 있어서,
    상기 재활성화 프로세스가, 이미 재활성화된 서비스 객체에 대해 그리고 상기 이미 재활성화된 서비스 객체가 비활성화되기 전에 수행되는 경우, 상기 재활성화 프로세스는 상기 메모리 포인터를 상기 이미 재활성화된 서비스 객체로 리턴시켜, 단 하나의 개별적 대체 서비스 객체만이 생성되어 각각의 재활성화된 서비스 객체를 대체하는 것인, 컴퓨터 구현 방법.
11. 제1항에 있어서,
    상기 서비스 실시 유도 메시지는 가상 머신의 제1 인스턴스에 의해 수신되고, 상기 제1 인스턴스는 상기 수신하는 단계, 상기 인스턴스화하는 단계, 상기 발생시키는 단계, 상기 직렬화하는 단계, 및 상기 저장하는 단계를 수행하며;
    상기 서비스 재활성화 메시지는 상기 가상 머신의 제2 인스턴스에 의해 수신되고, 상기 제2 인스턴스는 상기 재활성화 프로세스를 수행하는 것인, 컴퓨터 구현 방법.
12. 제1항에 있어서,
    상기 서비스 재활성화 메시지는 가상 머신의 제1 인스턴스에 의해 수신되고, 상기 제1 인스턴스는 데이터베이스에 액세스하여, 상기 가상 머신의 제2 인스턴스를 상기 직렬화된 데이터를 현재 소유하고 있는 것으로서 식별하는 유효한 소유권 엔트리(valid ownership entry)를 상기 데이터베이스가 포함하고 있는지 여부를 결정하고,
    상기 데이터베이스가 상기 유효한 소유권 엔트리를 포함하고 있는 경우, 상기 제1 인스턴스는 상기 제2 인스턴스가 상기 재활성화 프로세스를 수행하도록 상기 제2 인스턴스에 상기 서비스 재활성화 메시지를 포워딩하며,
    상기 데이터베이스가 상기 유효한 소유권 엔트리를 포함하고 있지 않은 경우, 상기 제1 인스턴스는 상기 제1 인스턴스를 상기 직렬화된 데이터를 현재 소유하고 있는 것으로서 식별하는 유효한 소유권 엔트리를 상기 데이터베이스에서 생성하고, 상기 제1 인스턴스는 상기 재활성화 프로세스를 수행하는 것인, 컴퓨터 구현 방법.
13. 제12항에 있어서,
    각각의 소유권 엔트리는 해당 소유권 엔트리가 생성된 이후 미리 결정된 양의 시간이 경과했을 때 무효화되는 것인, 컴퓨터 구현 방법.
14. 제13항에 있어서,
    상기 가상 머신의 상기 제1 및 제2 인스턴스는 각각 상기 가상 머신의 해당 인스턴스를 현재 살아있는(alive) 것으로 식별하는 유효한 하트비트 메시지를 상기 데이터베이스에 주기적으로 기록하도록 구성되고, 각각의 하트비트 메시지는 해당 하트비트 메시지가 생성된 이후 다른 미리 결정된 양의 시간이 경과했을 때 무효화되고, 상기 가상 머신의 상기 제1 및 제2 인스턴스 중 나머지 다른 인스턴스가 유효한 하트비트 메시지에 의해 살아있는 것으로 식별되는 경우에만 상기 서비스 재활성화 메시지가 상기 가상 머신의 상기 제1 및 제2 인스턴스 중 나머지 다른 인스턴스로 포워딩되도록, 각각의 소유권 엔트리는 식별된 상기 가상 머신의 인스턴스가 유효한 하트 비트 메시지에 의해 살아있는 것으로 또한 식별되는 경우에만 유효한 것인, 컴퓨터 구현 방법.
15. 제1항에 있어서,
    상기 직렬화된 데이터를 저장하는 단계는, 상기 서비스 객체들 모두가 직렬화되었을 때의 단일 기록 동작을 포함하는 것인, 컴퓨터 구현 방법.
16. 제1항에 있어서,
    상기 재활성화 메시지를 수신하는 것에 응답하여, 단일 기록 동작을 수행함으로써 상기 재활성화된 서비스 객체들의 대체 세트를 생성하는데 필요한 상기 연관된 상태 데이터 모두를 로딩하는 단계를 더 포함하는, 컴퓨터 구현 방법.
17. 시스템에 있어서,
    입력 디바이스;
    컴퓨터 스토리지;
    프로세서; 및
    서비스 함수들을 제공하도록 구성되는 서비스 객체 클래스들을 정의하는 코드를 보유하는, 상기 프로세서가 액세스가능한 메모리
    를 포함하며,
    상기 프로세서는, 적어도 하나의 서비스 실시 유도 메시지를 수신하는 것에 응답하여:
    서비스를 전달하는 상기 서비스 함수들을 구현하는 서비스 객체들을 생성하기 위해 상기 서비스 객체 클래스들을 인스턴스화하도록 ― 각각의 서비스 객체는 상기 메모리에 보유되는 연관된 상태 데이터를 갖고, 상기 서비스 객체들 중 적어도 일부는 다른 서비스 객체들을 참조함 ― ;
    각각의 서비스 객체에 대해, 해당 서비스 객체를 임의의 다른 서비스 객체와 구별하는 연관된 서비스 객체 식별자를 발생시키도록;
    직렬화된 데이터를 발생시키기 위해 상기 서비스 객체들을 직렬화하도록 ― 상기 직렬화된 데이터는 각각의 개별적 서비스 객체에 대해, 상기 서비스 객체 식별자, 상기 연관된 상태 데이터, 및 해당 서비스 객체에 의해 참조되는 임의의 다른 서비스 객체의 서비스 객체 식별자를 포함함 ― ; 그리고
    상기 직렬화된 데이터를 상기 컴퓨터 스토리지에 저장하도록
    구성되고,
    상기 시스템의 상기 프로세서 또는 추가적인 프로세서는:
    재활성화될 비활성화된 서비스 객체를 식별하는 서비스 재활성화 메시지를 수신하고; 그리고
    상기 식별된 서비스 객체에 대한 재활성화 프로세스를 수행하도록
    구성되며, 상기 재활성화 프로세스는:
    상기 직렬화된 데이터로부터 상기 식별된 서비스 객체를 재활성화시키고, 상기 식별된 서비스 객체의 서비스 함수에 필요한 각각의 연관된 서비스 객체에 대해 상기 재활성화 프로세스를 반복하여, 재활성화된 서비스 객체들의 대체 세트를 생성하는 것; 및
    상기 대체 세트가 상기 재활성화된 서비스 객체들 각각의 단 하나의 인스턴스만을 포함하는 것을 보장하기 위해, 이미 재활성화된 연관된 서비스 객체에 대한 상기 재활성화 프로세스의 수행이 캐싱된 메모리 포인터로 하여금 상기 연관된 서비스 객체로 리턴되게 하도록, 상기 재활성화된 서비스 객체들 각각에 개별적 메모리 포인터를 캐싱하는 것
    을 포함하는 것인, 시스템.
18. 제17항에 있어서,
    상기 시스템은 클라우드 플랫폼이고, 상기 프로세서 및 상기 추가적인 프로세서는 각각 복수의 가상 머신들을 구동시키도록 구성되고, 상기 코드의 인스턴스는 상기 복수의 가상 머신들 각각 상에서 구동하는 것인, 시스템.
19. 제18항에 있어서,
    상기 코드는 통신 네트워크의 엔드포인트들 간의 통신 이벤트들을 확립하기 위한 그리고 확립된 통신 이벤트들을 관리하기 위한 호 컨트롤러를 구현하도록 구성되고, 상기 서비스 실시 유도 메시지는 통신 이벤트 확립 요청이고, 상기 서비스 객체들은 통신 이벤트를 확립하기 위하여 상기 호 컨트롤러의 인스턴스에 의해 생성되며;
    상기 서비스 재활성화 메시지는 상기 호 컨트롤러의 상기 인스턴스에 의해 또는 상기 호 컨트롤러의 다른 인스턴스에 의해 수신되거나, 또는 상기 코드는 또한 상기 확립된 통신 이벤트의 미디어 모달리티를 관리하기 위한 미디어 컨트롤러를 구현하도록 구성되고, 상기 서비스 재활성화 메시지는 상기 미디어 컨트롤러의 인스턴스에 의해 수신되고;
    상기 서비스 재활성화 메시지는 상기 확립된 통신 이벤트에 관련되는 액션을 요청하고, 상기 서비스 객체들의 대체 세트는 상기 요청된 액션을 실시하는 것인, 시스템.
20. 서비스 함수들을 제공하도록 구성되는 서비스 객체 클래스들을 정의하는 컴퓨터 실행가능 코드를 저장한 컴퓨터 판독가능 저장 매체에 있어서,
    상기 코드는 실행될 때 동작들을 수행하도록 구성되고, 상기 동작들은:
    적어도 하나의 서비스 실시 유도 메시지를 수신하는 동작;
    상기 적어도 하나의 서비스 실시 유도 메시지를 수신하는 것에 응답하여, 서비스 객체들을 생성하기 위해 상기 서비스 객체 클래스들을 인스턴스화하는 동작 ― 상기 서비스 객체들은 서비스를 전달하기 위해 상기 서비스 함수들을 구현하고, 각각의 서비스 객체는 연관된 상태 데이터를 가지며, 상기 서비스 객체들의 적어도 일부는 다른 서비스 객체들을 참조함 ― ;
    각각의 서비스 객체에 대해, 해당 서비스 객체를 임의의 다른 서비스 객체와 구별하는 연관된 서비스 객체 식별자를 발생시키는 동작;
    각각의 개별적 서비스 객체에 대해, 상기 서비스 객체 식별자, 상기 연관된 상태 데이터, 및 해당 서비스 객체에 의해 참조된 임의의 다른 서비스 객체의 서비스 객체 식별자를 포함하는 직렬화된 데이터를 발생시키기 위하여 상기 서비스 객체들을 직렬화하는 동작;
    상기 직렬화된 데이터를 저장하는 동작;
    재활성화될 비활성화된 서비스 객체를 식별하는 서비스 재활성화 메시지를 수신하는 동작; 및
    상기 식별된 서비스 객체에 대한 재활성화 프로세스를 수행하는 동작
    을 포함하고, 상기 재활성화 프로세스는:
    상기 직렬화된 데이터로부터 상기 식별된 서비스 객체를 재활성화시키고, 상기 식별된 서비스 객체의 서비스 함수에 필요한 각각의 연관된 서비스 객체에 대해 상기 재활성화 프로세스를 반복하여, 재활성화된 서비스 객체들의 대체 세트를 생성하는 것; 및
    상기 대체 세트가 상기 재활성화된 서비스 객체들 각각의 단 하나의 인스턴스만을 포함하는 것을 보장하기 위해, 이미 재활성화된 연관된 서비스 객체에 대한 상기 재활성화 프로세스의 수행이 캐싱된 메모리 포인터로 하여금 상기 연관된 서비스 객체로 리턴되게 하도록, 상기 재활성화된 서비스 객체들 각각에 개별적 메모리 포인터를 캐싱하는 것
    을 포함하는 것인, 컴퓨터 판독가능 저장 매체.

Images