KR101169086B1

KR101169086B1 - 웹 서비스 환경에서 신뢰성 있는 메시지 전달시 연결지속성을 검증 및 유지하는 방법

Info

Publication number: KR101169086B1
Application number: KR1020050099107A
Authority: KR
Inventors: 마이클 제이. 모로니; 리차드 디. 힐; 로드니 티. 림프레칫; 샤이 코헨; 스테판 알. 배트레스; 마가렛 제이. 라이
Original assignee: 마이크로소프트 코포레이션
Priority date: 2004-12-08
Filing date: 2005-10-20
Publication date: 2012-07-26
Also published as: DE602005005613T2; ATE390793T1; JP4972304B2; KR20060064517A; DE602005005613D1; US20060123119A1; EP1670213A1; CN1787497B; JP2006164252A; US7899921B2; EP1670213B1; CN1787497A

Abstract

본 발명은 웹 서비스용 신뢰성 있는 메시징 프로토콜(RM-WS 프로토콜)에 따라 설정된 시퀀스 세션 동안 양 종단 간 메시지들의 수신을 감시하는 것에 관한 것이다. 수신된 메시지들은 애플리케이션 또는 인프라구조 메시지들(예를 들어, RM-WS 프로토콜에 따르는 수신확인 메시지들)일 수 있다. 또한, 본 발명은 시퀀스 세션 동안 메시지(애플리케이션 또는 인프라구조 중 어느 하나)를 수신하지 않은 채 지날 수 있는 시간에 관한 상한선인 비활동성 타임아웃으로 알려진 타임 주기를 정의한다. 이런 비활동성 타임아웃 주기에 기초하여, 본 발명은 연결 지속성을 검증하고 유지하기 위해 RM-WS 프로토콜에 따라 멱등 인프라구조 메시지들을 전송하는 시간 주기를 계산한다.

RM-WS, 웹 서비스, 프로토콜

Description

웹 서비스 환경에서 신뢰성 있는 메시지 전달시 연결 지속성을 검증 및 유지하는 방법{VERIFYING AND MAINTAINING CONNECTION LIVELINESS IN A RELIABLE MESSAGING FOR WEB SERVICES ENVIRONMENT}

도 1a는 본 발명의 예시적인 실시예에 따라, RM-WS 프로토콜의 특징을 확장시킴으로써 연결 지속성을 검증 및 유지하는 컴퓨팅 시스템을 도시.

도 1b는 본 발명의 예시적인 실시예에 따라, 연결 지속성을 유지하기 위한 RM-WS 프로토콜 하부구조 메시지를 전송하는 경우 간헐성(intermittency) 또는 주기성을 계산하는데 사용될 수 있는 알고리즘을 위한 타임라인을 도시.

도 2는 본 발명에 적합한 동작 환경을 제공하는 예시적인 시스템을 도시.

도 3은 본 발명의 예시적인 실시예에 따라 연결 지속성을 유지하는 방법에 대한 흐름도.

도 4는 본 발명의 예시적인 실시예에 따라 연결 지속성을 검증하는 방법에 대한 흐름도.

<도면의 주요 부분에 대한 부호의 설명>

105: 연결 검증 모듈

120: 발신자

125: 수신자

115: 수신확인 요청

130: 수신확인 응답

135: 애플리케이션 메시지

본 발명은 일반적으로 웹 서비스용 신뢰성 있는 메시징 프로토콜에 관한 것이다. 보다 구체적으로는, 본 발명은 시퀀스 세션에서의 연결 지속성을 검증하고 유지하기 위한 웹 서비스용 신뢰성 있는 메시징 프로토콜(RM-WS)의 특징을 확장시키는(leverage) 메커니즘을 제공한다.

컴퓨터 네트워크는 한 컴퓨터 또는 장치가 네트워크를 통해 전자 메시지를 사용하여 다른 컴퓨팅 시스템과 통신하게 함으로써 정보에 액세스하고 통신하는 능력을 강화해왔다. 컴퓨팅 시스템들 간의 전자 메시지 전송할 때, 전자 메시지는 종종 전자 메시지 내의 데이터에 대해 동작(예컨대, 구문분석(parsing), 라우팅, 흐름 제어 등)을 수행하는 프로토콜 스택을 통과할 것이다. 개방형 시스템 간 상호접속(OSI) 모델은 프로토콜 스택을 구현하기 위한 네트워크 프레임워크의 한 예이다.

OSI 모델은 전자 메시지를 전송하기 위한 동작들을 7개 구별된 계층으로 분류하는데, 각 계층은 데이터 전송 프로세스에서 소정의 동작을 수행하도록 지정된다. 프로토콜 스택들이 잠재적으로 각각의 계층을 구현할 수 있으나, 많은 프로토 콜 스택은 네트워크를 통해 데이터를 전송하는데 사용되기 위한 단지 선택적인 계층만을 구현한다. 데이터가 컴퓨팅 시스템에서부터 송신될 때, 이것은 애플리케이션 계층에서 개시하여, 그 아래 중간 계층으로 전달되고 그 다음 네트워크로 전달된다. 데이터가 네트워크로부터 수신될 때, 이것은 물리 계층으로 들어오고, 그 위 중간 계층으로 전달되고 결국 해당 애플리케이션 계층에 수신된다. 그 애플리케이션 계층, 즉 최상위 계층은 애플리케이션 및 최종 사용자 프로세싱을 지원하는 책임을 진다. 또한, 애플리케이션 계층 내에 여러 다른 계층(예컨대, SOAP(Simple Open Access Protocol) 계층)이 존재할 수 있다. 대부분의 프로토콜 스택에 포함된 또 다른 계층은 전송 계층이다. 전송 계층의 예로서 TCP(Transmission Control Protocol)가 있다.

웹 서비스(WS:Web Services)는 컴퓨팅 시스템들 간의 통신을 발전시키는 원동력이 되어 왔으며, 우리가 소프트웨어를 사용하고 구축하는 방식을 전적으로 바꾸고 있다. 웹 서비스로 인해 애플리케이션이 데이터를 공유하게 되고, 이런 애플리케이션이 어떻게 어디에 구축되어 있든지, 어느 운영 체제 또는 플랫폼에서 실행되고 있든지, 그것들을 액세스하는데 어떤 장치들이 사용될지에 관계없이 더욱 강력하게 다른 애플리케이션으로부터 기능들을 호출하게 된다. 웹 서비스는 인터넷을 통해 SOAP, XML(eXtensible Markup Language), UDDI(Universal, Description, Discovery and Integration), WSDL(Web Service Description Language) 등을 포함하는 산업 표준 프로토콜에 의해서 호출된다. 웹 서비스들은 서로에 대해 독립적이지만, 그들은 특정 작업을 수행하도록 자신들을 협력 그룹에 느슨하게 링크시킬 수 있다.

현재 WS 기술들은 발신자(예컨대, 클라이언트)와 수신자(예컨대, 서비스) 간의 직접 SOAP 메시지 통신을 제공한다. 일반적인 양방향 메시지 전달의 경우, SOAP 요청 메시지는 발신자에게서 수신자로 전송되고, 이에 응답하여 SOAP 응답 메시지가 전송된다. 종단 간의 다른 변형된 통신은 단방향 메시지 교환인데, 이는 발신자 수신자에게 메시지를 전송하되, 수신자는 응답이 없는 경우이다.

신생 WS 아키텍처의 중요한 이점은 통합된, 상호 동작가능한 해결책을 제공하는 기능에 있다. 그러나, 웹 서비스는 인터넷 등의 신뢰할 수 없는 통신 채널을 통해 다른 사업자, 생성기관(originations), 및 다른 서비스 제공자로부터의 다양한 서비스를 제공하기 때문에, WS의 신뢰성은 점점 더 중요한 요소가 되고 있다. WS의 신뢰성은 웹 서비스 종단들(end points)의 신뢰성, 웹 서비스를 액세스하는 통신 채널의 신뢰성 특징, 성능 및 무정지(fault-tolerance) 특징, 및 웹 서비스가 동시성 클라이언트 액세스를 처리할 수 있는 범위까지 포함하여 여러 요인들에 의해 영향받으나 이에만 한정되지 않는다.

종단 간 메시지들(예컨대, SOAP 메시지들)이 교환되는 신뢰성 있는 전송 프로토콜을 선택함으로써 웹 서비스용 신뢰성 있는 메시지 전달을 달성하려고 시도해 왔다. 예를 들어, 메시지-큐 등의 신뢰성 있는 메시징 트랜스포트를 이용하여 발신자와 수신자 간의 메시지를 신뢰성 있게 전달할 수 있다. 메시징-큐잉 통신 기술은 신뢰성을 위해 장애 시에도 유지되는 큐들에 메시지를 전송하고 큐들로부터 메시지를 판독함으로써 다른 시스템에 있는 애플리케이션들이 서로 통신하게 할 수 있다.

큐잉 시스템은 SOAP 메시지를 신뢰성 있게 전달하는데 사용될 수 있는 트랜스포트를 제공하지만, 이런 시스템에는 몇몇 단점이 존재한다. 예를 들어, 이런 시스템은 요청들(및 가능하게는 그것들의 응답들)이 전송되고 격리되어 처리되는 경우 비동기적 동작을 위한 해법을 제공한다. 따라서, 이런 시스템은 전형적으로 내구성 있는 거래용 메시지 저장소를 가진 여러 중간자(intermediaries)를 포함하고, 배치시, 프로그래밍 모델링시, 및 관리시 상당히 복잡하여, 자원에 관점에서 보면 중량급이다. 이런 것 모두가 신뢰성 있는 직접 통신의 경우에는 불필요하며, 대기시간을 최소화하려는 목적도 손상시킨다. 또한, 프로그램 모델은 요청-응답 스타일 프로그래밍 또는 세션을 직접적으로 지원하지 않는다. 따라서, 큐잉된 통신 모델은 현재 "대화형" 웹 서비스 모델과는 구별되며, 중대한 "연결형" 시나리오, 및 "대화형" 애플리케이션을 처리하지 못한다. 예를 들어, 이것은 응답이 시기에 알맞은 방식으로 기대되는 경우, 또는 분산 거래 컨텍스트(distributed-transaction-context)가 발신자와 수신자 간에 공유될 필요가 있는 경우에는 적합하지 못하다.

본질적으로 신뢰할 수 없는 전송 프로토콜에 대해 신뢰성 있는 전송 계층(예를 들어, 신뢰성 있는 HTTP 또는 HTTPR)을 정의하려고 시도해왔다. 그러나, 큐잉 해법과 마찬가지로 이런 해법을 곤란하게 하는 공통의 문제는 단지 특정한 신뢰성 있는 전송 프로토콜이 발신자와 수신자 간의 통신에 사용될 경우에만 신뢰성 있는 메시지 전달이 달성될 수 있다는 점이다. 웹 서비스의 본질적인 특성은 특정한 벤 더(vender) 플랫폼, 구현 언어, 및 특정 전송 프로토콜로부터 독립성을 요구한다. 일반적 경우, 발신자가 특정 프로토콜을 사용하여 수신자에게 직접 메시지를 전송할 수 없거나(예컨대, 수신자가 그 프로토콜을 지원하지 않음), 메시지가 전송 노드를 출발한 후 해당 목적지 노드에 도달하기 전에 복수의 홉을 통과할 필요가 있는 경우들이 있을 수 있다. 특정 홉(hop)에 관련된 2개 노드 간의 연결 특성에 따라, 신뢰성 있는 메시지 전달 특징을 제공하지 않는 적절한 전송 프로토콜이 선택될 필요가 있을 수 있다.

또한, 중간자들이 프로토콜 스택의 여러 레벨들에 존재할 수 있으므로, 전체적인 종단-대-종단 신뢰성을 제공하지는 않는다. 예를 들어, 전송 프로토콜은 저 레벨 중간자(예컨대, IP 레벨 중간자들인, IP 라우터 등)를 통해 신뢰성을 제공할 수 있다. 그러나, 전송 프로토콜은 SOAP 중간자 또는 애플리케이션 계층에서 중단될 수 있다. 따라서, 전송 프로토콜은 해당 중간자를 통한 신뢰성, 즉 애플리케이션 계층을 통한 종단-대-종단 신뢰성을 제공할 수 없을 수 있다.

보다 최근에, 예를 들면, WS-ReliableMessaging 등의, 다양한 웹 서비스용 신뢰성 있는 메시징 프로토콜(이하에서, "RM-WS 프로토콜"로 지칭됨)들이 현재 신뢰성 있는 메시징 시스템의 식별된 결함들에 대해 해결책을 제공한다. 이런 프로토콜은 전송 관용적인 연결형 프로토콜(transport agnostic connected protocols)이며, 이것은 소프트웨어 컴포넌트, 시스템, 또는 네트워크의 장애에 직면하여 종단 애플리케이션 간에 메시지를 신뢰성 있게 전송하게 하게 한다. 따라서, RM-WS 프로토콜은 발신자와 수신자 간의 신뢰성 있는, 종단-대-종단, 세션-지향형 통신을 위한 해법을 제공한다.

이런 RM-WS 프로토콜은 TCP가 IP 라우터들 및 복수의 네트워크들을 통해 TCP 송신자에게서 TCP 수신자로 바이트 흐름의 순서형 전송을 신뢰성 있게, 정확하게 한번 제공하는 점에서 TCP와 유사하다. WS용 신뢰성 있는 메시징 프로토콜들은 복수의 중간자(SOAP 레벨 중간자를 포함함), 트랜스포트, 및 연결을 통해 메시지를 위해 동일한 것 및 그 이상의 것을 제공한다(주목: 전송 단위는 바이트의 크기가 IP 패킷의 이용가능한 페이로드(payload) 공간에 의해 결정되는 TCP의 경우에서와 같이 바이트 또는 바이트 집합이 아닌 메시지임). TCP와 RM-WS 프로토콜은 모두 신뢰성 있는 프로토콜들일지라도, RM-WS는 OSI 모델의 애플리케이션 또는 SOAP 계층에 존재하기 때문에, RM-WS 프로토콜은 데이터 전송에 사용되는 전송 프로토콜에 관계없이 신뢰성 있는 메시지 전달을 제공한다. 따라서, RM-WS 프로토콜은 종단 간 메시지 전송에 사용되는 특정 전송 프로토콜이나 다른 프로토콜에 밀접하게 결합되어 있지 않다.

몇몇 RM-WS 프로토콜들이 잠시 동안 존재해 왔지만, 여전히 이런 프로토콜 사양에 관한 여러 단점 및 결함이 존재한다. 예를 들어, 이런 RM-WS 프로토콜은 설정된 시퀀스 세션의 연결성을 검증하는 방법을 제공하지 못한다. 또한, 그 사양으로는 비활동성 타임아웃 주기 동안 메시지 교환이 없을 경우에 시퀀스 세션을 확장하거나/고 연결의 지속성을 유지하는 방법을 제공하지 못한다. 따라서, RM-WS 프로토콜을 사용하는 시스템의 경우 연결 지속성을 검증 및 유지할 필요가 있다.

현재의 웹 서비스용 신뢰성 있는 메시징 프로토콜의 상기 확인된 결함 및 단점은 본 발명의 예시적인 실시예를 통해 극복된다. 예를 들어, 본 발명은 웹 서비스용 신뢰성 있는 메시징 프로토콜(RM-WS 프로토콜)을 이용함으로써 종단 간 연결 지속성을 유지하고 시퀀스 연결의 실재를 검증하는 메커니즘을 제공한다.

예를 들어, 발신자 종단 측에서 연결 지속성을 유지할 때, 본 발명은 고유한 시퀀스 식별자에 의해 식별된 시퀀스 세션을 RM-WS 프로토콜에 따라 양 종단 간 애플리케이션 계층에 설정하는 것을 제공한다. 시퀀스 세션을 생성하라는 요청에 기초하여, 그 생성된 시퀀스 세션에 대응하는 고유한 시퀀스 식별자가 수신된다. 그 후, 또는 어떤 다른 순간에, 그 시퀀스 세션의 비활동성 타임아웃 주기가 식별되는데, 이 주기는 그 시퀀스 세션 동안 메시지를 수신하지 않은 채 지날 수 있는 시간에 관한 상한선을 나타낸다. 비활동성 타임아웃 주기에 기초하는 알고리즘에 따라, 연결지속(keepalive) 만료 타임아웃이 계산된다. 계산된 연결지속 만료 타임아웃에 기초하여, 고유한 시퀀스 식별자를 포함하는 메시지가 전송된다. 그 후, 고유한 시퀀스 식별자를 포함하는 메시지가 비활동성 타임아웃 주기 이전에 수신되어 연결 지속성이 유지되게 한다. 수신된 메시지에 기초하여, 시퀀스 세션이 지속되도록 비활동성 타임아웃 주기 동안 비활동성 타이머를 리셋한다.

연결 지속성을 검증하기 위한 다른 예시적인 실시예에서, 고유한 시퀀스 식별자에 의해 식별된 시퀀스 세션이 양 종단 간의 애플리케이션 계층에 RM-WS 프로토콜에 따라서 설정된다. 상기에서와 유사하게, 비활동성 타임아웃 주기가 식별되는데, 이 주기는 그 시퀀스 세션 동안 양 종단 간 메시지를 교환하지 않은 채 지날 수 있는 시간에 관한 상한선이다. 비활동성 타임아웃 주기가 만료되기 이전에, 시퀀스 세션에 대응하는 고유한 시퀀스 식별자를 포함하고 있는 연결 검증을 위한 메시지가 수신된다. 수신된 메시지에 기초하여, 시퀀스 세션이 지속되도록 비활동성 타임아웃 주기 동안 비활동성 타이머를 리셋한다.

본 발명의 부가적인 특징 및 장점은 이하의 상세한 설명에 기술될 것이며, 그 상세한 설명으로부터 부분적으로 분명해지거나, 본 발명의 실시를 통해 알게 될 수 있다. 본 발명의 특징 및 장점은 첨부된 청구항에서 구체적으로 지적된 기구 및 조합에 의해 실현되거나 획득될 수 있다. 본 발명의 이런 특징 및 기타 특징은 이하의 상세한 설명 및 첨부된 청구항으로부터 보다 충분히 명확해지거나, 이후에 설명한 바와 같이 본 발명의 실시를 통해 알게 될 수 있다.

본 발명의 상기 인용된 것, 및 다른 장점 및 특징을 획득하기 위한 방법을 기술하기 위해, 상기 간략히 기술한 본 발명에 대한 보다 구체적인 상세가 첨부된 도면에 예시되고 있는 특정 실시예를 참조하여 기술될 것이다. 이런 도면은 단지 본 발명의 전형적인 실시예만을 예시하므로 본 발명의 범위를 한정하는 것으로 간주될 수 없다는 것을 이해하면서, 본 발명은 여기에 첨부된 도면을 이용하여 부가적으로 특수하고 상세하게 기술되고 설명될 것이다.

본 발명은 시퀀스 세션의 연결 지속성을 검증 및 유지하는 웹 서비스용 신뢰성 있는 메시징 프로토콜(RM-WS)을 확장시키는 메커니즘을 위한 방법, 시스템, 및 컴퓨터 프로그램 제품에 관한 것이다. 본 발명의 실시예는 이하에 보다 상세히 논 의한 바와 같이, 다양한 컴퓨터 하드웨어를 포함한 전용 또는 범용 컴퓨터를 포함할 수 있다.

본 발명은 예를 들어, 소프트웨어 컴포넌트, 시스템, 또는 네트워크 장애에 직면하여 메시지가 분산 애플리케이션 간에 신뢰성 있게 전송되게 하는 사양을 기술한 WS-ReliableMessaging(WS-RM) 등의 웹 서비스용 신뢰성 있는 메시징 프로토콜(이하에서 "RM-WS 프로토콜"로서 지칭됨)의 확장에 관한 것이다. 웹 서비스용 신뢰성 있는 메시징 프로토콜은 발원지(이하에서, "발신자")에서 목적지, 예컨대 서비스(이하에서, "수신자")로의 성공적인 메시지 전송을 용이하게 하고, 에러 상태를 확실하게 검출할 수 있다. 이런 프로토콜은 관용적(agnostic) 전송 프로토콜로서, 다른 네트워크 전송 기술을 사용하여 구현가능하다. 또한 신뢰성 있는 메시징 프로토콜의 다양한 구현에 의해 애플리케이션이 간헐적인 통신 장애를 알지 못하게 하며, 시스템 장애 시에 회복력을 제공할 수 있다.

본 발명은 양 종단 간에 설정된 시퀀스 세션으로 활동을 감시하는데, 그 활동은 해당 시퀀스 동안 메시지를 수신하는 동작으로서 정의된다. 수신된 메시지들은 애플리케이션 또는 하부구조 메시지들일 수 있다(예를 들어, RM-WS 프로토콜에 따르는 수신확인 메시지들). 또한, 본 발명은 시퀀스 세션 동안 (애플리케이션 또는 하부구조 중 어느 하나의) 메시지를 수신하지 않은 채 지날 수 있는 시간에 관한 상한선인 비활동성 타임아웃(IT:inactivity timeout) 주기를 정의한다. 해당 상한선에 도달하면, 그 다른 종단이 존재하지 않는 것으로 간주되고, 시퀀스는 사라진 것 또는 버려진 것으로 간주된다. 다른 한편으로 만약 메시지가 IT가 만료되 기 전에 수신되면, IT 타이머는 리셋되고 연결이 검증된다. 또 다른 관련 실시예에서, 식별된 IT에 기초하여, 본 발명은 연결 지속성을 유지하려는 시도에서 종단 간의 RM-WS 멱등(idempotent) 프로토콜 하부구조 메시지들을 전송하기 위한 초기 시간 및 주기성을 계산해 낸다.

도 1a는 상기 기술된 예시적인 실시예 중 일부를 실시하는데 사용될 수 있는 분산 컴퓨팅 시스템(100)을 예시한다. 시퀀스 세션은 RM-WS 프로토콜에 따라서 발신자(120)와 수신자(125) 간에 설정될 수 있다. 그 설정된 시퀀스 세션은 사용되는 트랜스포트에 따라 복수 또는 비 실제적 네트워크 연결들로 확장될 수 있다. 또한, 그 연결들은 시간(예를 들어, 현재 한 연결을 사용하다 나중에 다른 연결을 사용함) 및 형상(예를 들어, 각 홉당 다른 트랜스포트 유형들)에 따라 달라질 수 있다. 예를 들어, 메시지를 플로피 디스크 상에 복사하고 디스크들을 발신자(120)와 수신자(125) 간에 전달함으로써 메시지들을 교환하는 경우에, 컴퓨터 간의 실제 물리적 연결은 존재하지 않으나, 본 발명은 RM-WS 프로토콜의 특징을 확장시킴으로써 통신하는 대상들, 즉 발신자(120)와 수신자(125) 간에 세션을 생성할 수 있다.

플로피 디스크의 예는 예시적인 목적을 위해 제시되었으며 전형적인 용례가 아님을 주의해야 한다. "대화형 애플리케이션"의 경우에 보다 전형적인 용례는 TCP/IP, HTTP(가능하게는 TCP/IP 위에 놓임), UDP/IP, 파이프, 또는 기타 실시간 전송 메커니즘을 사용하는 경우일 것이다.

예시적인 실시예는 발신자(120)가 연결 지속성에 대한 책임을 일차적으로 지고 있는 경우를 제공한다. 따라서, 이 실시예는 HTTP를 이용하여 SOAP(SOAP over HTTP) 등의 요청-응답용 프로토콜을 통해 수신자(125)와 통신하는 방화벽 뒤에 있는 클라이언트와 같은, 주소 참조 불가능한(un-addressable)(즉, 익명의) 발신자(120)를 지원한다. 그러나, 발신자(120)가 주소 참조 가능한 경우(및 어떤 경우 익명이라도)에, 양자 중 어느 한 종단(즉, 발신자(120) 또는 수신자(125))은 하기 기술된 바와 같이 연결 지속성을 검증할 수 있음에 주의해야 한다. 따라서, 이하의 예가 전형적으로 연결 지속성을 유지 및 검증하는 발신자(120)를 참조하고 있으나, 이런 참조는 예시적인 목적으로 사용되는 것이지, 명확히 주장되지 않는 한 본 발명의 범위를 한정하거나 그렇지 않으면 축소하는 것을 의미하지 않는다.

발신자(120)가 익명이든 아니든 상관없이, 발신자(120)는 애플리케이션 메시지(135) 또는 하부구조 메시지들(130)이 존재하지 않을 경우 설정된 시퀀스 세션이 비활동성으로 인해 종료하지 못하도록 타이머(110)를 포함한 연결 검증 모듈(105)을 이용한다. 예를 들어, 확인된 비활동성 타임아웃(IT)에 기초하여, 연결 검증 모듈(105)은 연결된 양측에서 비활동성 타임아웃을 방지하기 위해 RM-WS 하부구조 메시지 교환을 개시하는 알고리즘을 이용한다. 예를 들어, RM-WS 수신확인 요청 메시지인 수신확인 요청(115)을 확장시키고(WS-RM의 경우, 수신확인 요청 메시지인 AckRequested가 사용될 수 있음에 유의해야 함) 구체적으로 작성된 알고리즘을 사용하여, 연결 검증 모듈(105)은 초기 수신확인 요청 메시지(115)(별칭 및 다르게는 본원에서 "연결지속(keep-alive)" 메시지(115)로 참조됨)을 상대 측에 전송할 시간 주기를 결정한다.

예시적인 실시예에서, IT는 대기시간 문제, 네트워크의 신뢰성, 및 기타 고 려사항 등에 기초하여 애플리케이션 계층에서 조정될 수 있음에 유의한다. 예를 들어, 상기 플로피 디스크의 예에서, 비활동성 타임아웃 주기는 통신 매체에 의해 부과되는 대기시간을 고려한 상대적으로 긴 지속 시간일 필요가 있는 반면, 다른 시스템들은 수신자(125)로부터 메시지를 수신하지 않은 채 그 세션을 개방된 채로 지속시키기 위해 상대적으로 짧은 지속 시간을 필요로 할 수 있다. 따라서, IT는 연결마다 조정될 수 있고, 시퀀스 세션을 설정하기 이전에 발신자(120) 및 수신자(125) 간에 타협이 이뤄지고/거나 세션이 설정된 이후에 동적으로 수정될 수 있다.

IT 값에 상관없이, 수신자(125)가 수신확인 요청 메시지(115)를 수신할 때, 수신자(125)는 그 비활동성 타이머(도시 생략)를 리셋한다. 수신자(125)가 인프라구조(130)(예를 들어, 수신확인 요청(115)) 또는 애플리케이션-레벨(135) 메시지를 수신하는 것에 상관없이, 비활동성 타이머는 리셋될 것임에 유의해야 한다. 이 시점에, 수신자(125)는 연결 지속성을 검증할 수 있다.

마찬가지로, 발신자(120) 측에서 연결 지속성을 검증하기 위해서, 발신자(120)는 시퀀스 세션용(애플리케이션(135) 또는 인프라구조(130) 중 어느 하나임) 메시지들을 수신할 필요가 있을 것이다. 따라서, 수신자(125)가 수신확인 요청 메시지(115)를 수신할 때, 수신자는 전형적으로 RM-WS 수신확인 응답 메시지인 수신확인 응답(130)을 전송함으로써 응답한다(예를 들어, WS-RM의 경우, 수신자(125)는 수신확인(Ack) 메시지를 전송함). 수신확인 응답(130) 또는 수신확인(Ack)을 수신하면, 발신자(120)는 연결 지속을 검증하고, 발신자(120) 측의 비활동성 타이머(110)를 리셋하고, 그 연결 지속은 유지된다. 상기 언급한 바와 같이, 비활동성 타임아웃이 만료되기 이전에 발신자(120)에게 수신된 애플리케이션 메시지(135)가 타이머(110)를 리셋할 것임에 유의해야 한다. 이런 경우에, 연결 검증 모듈(105)은 리셋되고, 수신확인 요청 메시지(115)를 전송하기 위한 초기 주기를 재계산한다.

메시지(애플리케이션(135) 또는 인프라구조 메시지(130) 중 어느 한 가지)가 발신자(120)에게 수신되든 되지 않든 상관없이, 시퀀스 세션이 적어도 수신자(125) 측으로 확장됨에 유의해야 한다. 따라서, 발신자(120)가 익명인 경우(또는 발신자(120)가 주소 참조가능한 경우의 일부 경우에서), 발신자(120)에 대한 비활동성 타임아웃이 존재하지 않을 수 있다. 따라서, 수신확인 요청 메시지(115)를 주기적으로 전송하여 메시지들이 발신자(120)에게 수신되든 되지 않든 상관없이, 수신자(125) 측에서 연결 지속을 검증할 수 있다. 실제로, 이것과는 반대의 경우도 성립되는데, 여기서는 수신자(125)가 비활동성 타임아웃을 시행하지 않으나, 메시지들이 수신될 때 발신자 측에서 연결이 확장된다.

인프라구조 메시지들이 신뢰성 있게 전송되지 않고 교환 도중 어느 순간에 사라질 수 있음에 유의하는 것이 또한 중요하다. 따라서, 발신자(120)에게서 수신자(125)로의 수신확인 요청 메시지(115)는 사라질 수 있다. 마찬가지로, 수신확인 응답(130) 메시지도 수신자(125)에게서 발신자(120)로의 전송시에 사라질 수 있다. 이런 경우에, 예시적인 실시예가 수신확인 요청(115)을 수신자(125)에게 주기적으로 전송하기 위해, 비활동성 타임아웃 주기에 기초하여 특별히 조정된 알고리즘을 제공한다. 인프라구조 메시지들(115 및 135)은 멱등 관계이어서, 어떤 복제 검출 도 필요하지 않고 순서도 중요하지 않다.

연결 검증 모듈(105)은 상기 기술된 바와 같이, 교환을 개시하려는 초기 시도 및 후속하는 주기적 시도를 행하는 시각들을 선택하기 위해 상기 참조된 특별히 작성된 알고리즘을 이용한다. 도 1b는 연결지속 또는 수신확인 요청 메시지(115)를 전송하는데 사용되는 가능한 알고리즘의 예시적인 타임라인(timeline) 표현을 예시한다. 도 1b에 도시된 바와 같이, 이 알고리즘 타임라인은 적어도 3가지 성질 중 하나 이상에 기초한다. 먼저, 상기 언급된 비활동성 타임아웃(IT)(140)은 발신자(120)가 시퀀스 세션을 실패하거나 포기하기 전에 얼마나 오랫동안 수신자(125)로부터 메시지들을 수신하지 않은 채 대기할 것인지를 정의한다. 그 다음에, 최대 재시도 계수(155:MRC)는 발신자(120)가 포기하기 이전에 메시지를 재전송하려고 시도할 횟수이다. 이는 애플리케이션 및 인프라구조 메시지들(예를 들어, 연결지속 메시지(115)) 양자 모두에 적용된다. 세 번째로, 연결지속 만료 타임아웃(150:KAET)은 발신자(120)가 연결지속 메시지들(115)을 전송하기 시작하기 이전에 수신자(125)로부터 메시지들을 수신하지 않은 채 대기하게 될 간격으로서 정의되는데, 즉 KAET(150)는 연결지속 메시지(115)를 전송하기 위한 초기 시간을 정의하는 IT(140)의 일부분(N)이다. 이후의 실시예에서, N은 디폴트값 0.5로 설정된다. 따라서, 발신자(120)는 수신자(125)로부터의 활동 없이 IT(140)의 1/2이 지난 후에 연결지속 메시지들(115)을 전송하기 시작할 것이다.

이런 3가지 성질에 기초하여, 연결지속 간격(145:KAI), 즉 연결지속 메시지들(115)이 연속적으로 또는 주기적으로 전송되는 간격이 계산될 수 있다. 예를 들 어, 연결지속 간격(145)은 알고리즘 KAI = IT*(1-N)/MRC을 사용하여 계산될 수 있다. IT(140), KAET(150), MRC(155), 및 KAI(145) 사이의 관련성이 도 1b에 도시된 바와 같이 예시된다. 특정한 알고리즘이 KAET(150)과 KAI(145)를 정의하는데 사용되었으나, 기타 알고리즘들, 및 수신확인 요청 메시지 또는 연결지속 메시지들(115)을 언제 전송할지를 결정하는 방법도 본 발명에 이용가능하다. 예를 들어, 연결지속 메시지들(115)을 전송하는 주기성(즉, KAI(145))은 임의로 선택될 수 있다. 따라서, 이런 값들을 결정하는 상기 특정한 알고리즘의 사용은 단지 예시적인 목적을 위해서이고, 명시적으로 주장되지 않는 한 본 발명의 범위를 한정하거나 그렇지 않으면 축소하는 것을 의미하지 않는다.

그럼에도 불구하고, 전형적으로 발신자(120)는 주기적인 타이머 간격에 의해서 IT(140), KAET(150), 및 KAI(145)를 계산할 것이다. 예를 들어, IT(140)가 2시간, MRC(155)가 5시간, 주기적인 타이머 간격이 2초인 경우, 방정식과 상기 가정(즉, N = 0.5)을 이용하면, KAET(150)는 1시간이고, KAI는 12분이 될 것이다. 그 값들을 초로 바꾸고, 타이머 간격으로 나누면 다음과 같이, IT/(타이머 간격) = 7200/2 = 3600 타이머 틱(timer ticks), KAET/(타이머 틱) = 3600/2 = 1800 타이머 틱, KAI/(타이머 간격) = 720/2 = 360 타이머 틱이 된다. 따라서, 이런 경우에 발신자(120)는 1800 타이머 틱 이후에 연결지속 메시지들(115)을 전송하기 시작할 것이다. 발신자(120)는 또한 3600 틱이 전부 지날 때까지 360 타이머 틱 마다 연결지속 메시지를 전송할 것이다. 발신자(120)가 이런 지속 시간 동안(즉, IT 간격 동안) 수신자(125)로부터 메시지를 수신하지 못한 경우, 그 발신자(120)는 시퀀스 세션에 잘못이 있다고 탓할 것이다.

다른 예시적인 실시예에서, 상기 구현은 2개의 타이머를 사용하여 달성될 수 있다. 제1 타이머는 IT(140)에 일치한 타이머 간격으로 설정된다. 이런 제1 타이머는 메시지가 수신자(125)로부터 수신될 때마다 리셋된다. 제1 타이머가 수신자(125)로부터의 활동 없이 만료되는 경우, 발신자(120)는 그 시퀀스 세션을 종료할 것이다. 제2 타이머는 KAET(150)에 일치한 타이머 간격으로 설정된다. 제2 타이머가 만료될 때, 발신자(120)는 연결지속 메시지(115)를 수신자(125)에게 전송할 것이며, 제2 타이머를 KAI(145)의 타이머 간격으로 리셋할 것이다. 또한, 제2 타이머를 후속하는 제2 타이머 만료 시점에(즉, 메시지를 수신하지 않은 채 KAI(145) 시간 간격이 지날 때마다) KAI(145)의 타이머 간격으로 리셋할 것이다. 메시지(130 및 135)가 수신자(125)로부터 수신될 때마다, 발신자(120)는 제2 타이머를 KAET(150)에 일치한 타이머 간격으로 리셋할 것이며, 이 프로세스가 반복된다.

연결지속 메시지(115)를 전송하기 위해 대기하면서, 애플리케이션 메시지가 이용가능하게 되어 발신자가 전송하게 될 수 있음에 유의해야 한다. 이는 발신자(120) 애플리케이션이 메시지를 전송했기 때문에 또는 발신자(120) 재시도 알고리즘이 그 시점이 버퍼링 된 애플리케이션 메시지를 재전송할 시간이라고 판단했기 때문에 발생할 수 있다. 이런 일이 발생하면, 발신자(120)가 그 KAI(145)(또는 가능하게는 KAET(150)) 간격을 재시작하는 경우를 제공한다. 환언하면, 발신자(120)는 애플리케이션 메시지가 전송된 이후 KAI(145)(또는 KAET(150))의 간격이 지날 때까지 또 다른 연결지속 메시지(115)를 전송하지 않을 것이다. 따라서, 발신자 (120)는 애플리케이션 또는 인프라구조 중 어느 하나인 일부 형태의 메시지를 적어도 KAI(145) 간격마다 전송할 것이다. 또한, 연결지속 메시지들(115)은 전송된 애플리케이션 메시지들이 네트워크 혼잡 등의 어떤 이유로 인해 중단될 경우에도, 전형적으로 전송될 것이다.

다른 실시예에서는 전송된 애플리케이션 메시지에 수신확인 요청 메시지(115)를 첨부할 수 있는 것에 유의해야 한다. 이런 실시예는 예를 들어, IT(140)가 한 묶음의 메시지들에 대한 수신확인을 기다리기보다는 수신자(125)가 수신확인 응답 또는 수신확인(130)을 전송할 것을 촉진하기 위해 만료되려고 할 경우에 사용될 수 있다. 이런 경우에, 수신확인 요청 메시지(115)는 일반적으로 애플리케이션 메시지(135)에 포함되는 프로토콜 구성요소(예를 들어, WS-RM 등의 RM-WS 프로토콜에 의해 정의된 헤더 또는 기타 지시자)로서 표현될 것이다. 이처럼, "수신확인 요청 메시지(115)"는 수신확인 요청(115)이 상기 기술된 프로토콜 구성요소인 경우를 포함하여 광범위하게 해석되어야 한다.

다른 실시예는 RM-WS 프로토콜에 따르는 단일 메시지의 복수의 시퀀스 세션 각각에 대한 수신확인 요청(115)(예들 들어, 애플리케이션 또는 인프라구조, 예컨대, 수신확인 요청(115) 메시지들 등)을 포함하는 것을 고려한다. 마찬가지로, 다른 실시예는 RM-WS 프로토콜에 따르는 단일 메시지의 복수의 시퀀스 세션 각각에 대한 수신확인 응답(130)(예를 들어, 애플리케이션(135) 또는 인프라구조, 예컨대 수신확인(130) 메시지들 등)을 포함하는 것을 고려한다. 이는 단일 메시지의 수신 시에 복수의 시퀀스의 지속성을 검증하는 것을 고려함으로써, 같은 종단(120 및 125) 간의 복수의 시퀀스들에 대한 지속성을 유지하는데 필요한 메시지 개수를 감소시킨다.

본 발명은 또한 기능적인 단계 및/또는 비기능적인 동작을 포함하는 방법에 의해서 기술될 수 있다. 하기에 본 발명을 실행하는데 수행될 수 있는 단계 및/또는 동작에 대해 기술하고 있다. 일반적으로, 비기능적인 동작은 특정 결과를 달성하기 위한 보다 특정한 동작들을 기술하는 반면, 기능적인 단계는 달성된 결과에 의해서 본 발명을 기술한다. 기능적인 단계 및/또는 비기능적인 동작이 특정 순서로 기술되거나 주장될 수 있으나, 본 발명은 필수적으로 단계 및/또는 동작의 특정 순서 또는 조합에 한정되지 않는다. 또한, 단계 및/또는 조합을 도 3 및 4의 흐름도에 대한 하기의 상세한 설명 및 청구항의 인용에 사용하는 것은 이런 용어에 대한 원하는 특정한 사용을 나타내기 위함이다.

도 3 및 도 4는 본 발명의 다양한 예시적인 실시예의 예시적인 흐름도를 예시한다. 도 3 및 도 4의 대한 하기의 기술은 가끔 도 1a 및 도 1b로부터 대응하는 구성요소를 참조할 것이다. 이 참조가 이런 도면들로부터의 특정 구성요소에 행해질 수 있으나, 이런 구성요소는 단지 예시적인 목적으로만 사용되고, 명시적으로 주장되지 않는 한 본 발명의 범위를 한정하거나 그렇지 않으면 축소하는 것을 의미하지 않는다.

도 3은 RM-WS 프로토콜을 이용하여 종단 애플리케이션들 간의 시퀀스 세션에 대한 연결 지속을 검증하는 방법에 관한 예시적인 흐름도를 예시한다. 본 방법(300)은 양 종단 간 시퀀스 세션을 설정하는 동작을 포함한다. 예를 들어, 시퀀스 세션은 RM-WS 프로토콜(예컨대, WS-ReliableMessaging)에 따라 발신자(120)와 수신자(125) 간에 설정될 수 있다. 본 방법(300)은 비활동성 타임아웃을 식별하는 동작(310)을 더 포함할 수 있다. 예를 들어, 연결 검증 모듈(105)은 비활동성 타임아웃(140:IT)를 식별하는 데 사용될 수 있고, 그 비활동성 타임아웃 주기는 시퀀스 세션 동안 발신자(120)와 수신자(125) 간의 메시지를 교환하지 않은 채 지날 수 있는 시간에 관한 상한선을 나타낸다. 이런 IT(140)는 통신 매체에 의해 부여된 대기시간 또는 기본 네트워크의 신뢰성에 관한 지식 등을 고려하여 조정가능할 수 있다.

비활동성 타임아웃 주기가 만료되기 이전에, 본 방법(300)은 고유한 시퀀스 식별자를 포함하는 메시지를 수신하는 단계(315)를 더 포함한다. 예를 들어, 발신자(120)와 수신자(125) 중 어느 하나는 연결 지속을 검증하기 위한 메시지를 수신할 수 있는데, 그 메시지는 시퀀스 세션에 대응하는 고유한 시퀀스 식별자를 포함한다. 고유한 시퀀스 식별자를 포함하는 수신된 메시지는 애플리케이션 메시지(135)일 수 있다. 대안으로서, 그 수신된 메시지는 인프라구조 메시지(115 및 130)일 수 있다. 예를 들어, 메시지가 발신자(120)에게 수신되면, 수신된 메시지는 이전에 발신자에 의해 전송됐던 수신확인 요청(115)에 응답하는 수신확인(130)일 수 있다. 메시지가 수신자(125)에게 수신되면, 메시지는 시퀀스 수신확인 요청(115)일 수 있다. 메시지들이 애플리케이션 레벨 또는 인프라구조 메시지들인지에 상관없이, 다른 실시예는 복수의 시퀀스 세션에 대한 수신확인 요청들(예를 들어, 수신확인 요청(115)) 또는 수신확인들(예를 들어, 수신확인(130))을 포함하는 단일 메시지를 고려한다. 그에 더하여, 수신확인 요청(115)이 애플리케이션 레벨 메시지에 포함되는 경우에, 수신확인 요청(115)은 전형적으로 프로토콜 구성요소(예를 들어, 메시지의 헤더 또는 기타 필드)에 포함될 것이다.

수신된 메시지에 기초하여, 본 방법(300)은 비활동성 타이머를 리셋하는 단계(320)를 더 포함한다. 예를 들어, 메시지가 발신자(120)에게 수신되면, 발신자(120)는 연결 검증 모듈(105) 내의 타이머(110)를 리셋할 수 있다. 그러면, 비활동성 타임아웃 주기는 재계산되고 프로세스는 반복될 수 있다. 비활동성 타이머를 리셋한 후에, 애플리케이션 또는 인프라구조 메시지들이 수신되지 않고, 그 비활동성 타임아웃 주기(14)가 만료되는 경우, 그 시퀀스 세션은 버려질 수 있다.

도 4는 RM-WS 프로토콜을 이용함으로써 발신자에 의해 종단 간 시퀀스 세션에 대한 연결 지속을 유지하는 방법(400)에 관한 흐름도를 예시한다. 본 방법(400)은 양 종단 간 시퀀스 세션을 설정하는 단계(405)를 포함한다. 예를 들어, 고유한 시퀀스 식별자에 의해 정의된 시퀀스 세션은 RM-WS 프로토콜(예컨대, WS-ReliableMessaging)에 따라 발신자(120)와 수신자(125) 간에 설정될 수 있다. 시퀀스 세션을 설정하기 위해, 발신자(120)는 전형적으로 RM-WS 프로토콜에 따라 하나 이상의 시퀀스 세션을 생성하기 위한 요청을 수신자(125)에게 전송한다. 그 요청에 기초하여, 수신자(125)는 고유한 시퀀스 식별자(들)(예를 들어, 전역적으로 고유한 식별자(GUID:global unique identifier)를 생성할 수 있으며, 이 식별자(들)는 생성된 시퀀스 세션(들)을 식별하는데 사용될 것이다.

또한, 시퀀스 세션을 설정하는 기타 방법도 본 발명에 이용될 수 있음에 유 의해야 한다. 예를 들어, 발신자(120)는 고유한 시퀀스 식별자(들)를 생성하고 그 식별자들을 시퀀스 세션(들)을 생성하기 위한 요청으로 수신자(125)에 전송할 수 있다. 실제, 본 발명에 이용가능한 시퀀스 세션을 설정하는 여러 기타 공지된 방법이 존재한다. 따라서, 시퀀스 세션이 설정되는 방법에 관한 어떤 특정한 참조가 단지 예시적인 목적으로만 사용되고 있으며, 명시적으로 주장되지 않는 한 본 발명의 범위를 한정하거나 그렇지 않으면 축소하는 것을 의미하지 않는다.

시퀀스 세션이 설정되는 방법에 상관없이, 본 방법(400)은 그 시퀀스 세션에 대한 비활동성 타임아웃 주기를 식별하는(415) 단계를 더 포함한다. 예를 들어, 연결 검증 모듈(105)은 비활동성 타임아웃(140:IT)을 식별할 수 있는데, IT는 시퀀스 세션 동안 메시지를 수신하지 않은 채 지날 수 있는 시간에 관한 상한선을 나타낸다. 이런 IT(140)는 전송 네트워크의 신뢰성 또는 수신확인을 수신하는데 예상되는 최소 대기시간 등의 기타 고려사항에 기초하여 조정될 수 있다.

본 방법(400)은 연결지속 만료 타임아웃을 계산하는 단계(417)를 더 포함한다. 예를 들어, 연결 검증 모듈(105)은 비활동성 타임아웃 주기(140)에 기초하여, 전형적으로 간격 타임아웃(140)의 일부분인 연결지속 만료 시간(150:KAET)을 계산하기 위한 알고리즘을 사용할 수 있다. 계산된 연결지속 만료 타임아웃에 기초하여, 본 방법(400)은 고유한 시퀀스 식별자를 포함하는 메시지를 전송하는 단계를 더 포함한다. 메시지는 인프라구조 메시지(예를 들어, 수신확인 요청(115)) 또는 애플리케이션 메시지(135)일 수 있다. 예를 들어, 발신자(120)는 KAET(150)의 만료시에 RM-WS 프로토콜에 의해 정의된 인프라구조 멱등 메시지인 수신확인 요청 메 시지(115)를 송신할 수 있다. 전송된 메시지가 애플리케이션 레벨 또는 인프라구조 메시지인지에 상관없이, 다른 실시예들에서는 복수의 시퀀스 세션에 대한 수신확인 요청들(예를 들어, 수신확인 요청(115))을 메시지에 포함시킬 수 있다.

다음에 본 방법(400)은 고유한 시퀀스 식별자를 포함하는 메시지를 수신하는(422) 단계를 포함한다. 즉, 발신자(120)는 고유한 시퀀스 식별자를 포함하는 수신확인 요청(115) 또는 애플리케이션 메시지(135)를 수신자(125)로부터 수신할 수 있다. 메시지(예를 들어, 메시지(130 및 135) 등의 인프라구조 또는 애플리케이션 메시지)가 비활동성 타임아웃 주기(140) 이전에 수신되면, 시퀀스 세션의 연결 지속이 유지된다. 또한, 수신된 메시지에 기초하여, 본 방법(400)은 또한 비활동성 타이머를 리셋하는 단계(425)를 포함한다. 즉, 수신된 수신확인 요청(130) 또는 애플리케이션 메시지(135)에 기초하여, 연결 검증 모듈(105) 내의 비활동성 타이머(110)는 그 시퀀스 세션이 지속되도록 비활동성 타임아웃(140)을 리셋할 수 있다.

또한 수신된 메시지가 애플리케이션 레벨 메시지일 수 있음에 유의해야 한다. 이런 경우에, 수신확인 응답(130)은 애플리케이션 레벨 메시지에 포함될 수 있다. 수신된 메시지가 애플리케이션 레벨 또는 인프라구조 메시지인지에 상관없이, 다른 실시예에서는 복수의 시퀀스 세션에 대한 수신확인들(예를 들어, 수신확인(130))을 메시지에 포함시킬 수 있다.

또한 수신확인 요청 메시지(115)들은, 수신자(125)로부터 수신될 때 이미 수신확인되었던 메시지들에 대응할 수 있음에 유의해야 한다. 환언하면, 수신확인 요청 메시지(115)는 모든 메시지들이 수신될 때 수신확인되었을 경우일지라도 전송 될 수 있다. 또한, 수신자에게 전송될 애플리케이션 메시지는 중단될 수 있지만, 수신확인 요청 메시지(115)들은 어쨌든 전송되어야 한다.

또한 KAET(150)를 계산하는 알고리즘이 비활동성 타임아웃(140)의 일부분(N)에 기초하는 것임에 유의해야 한다. 예를 들어, KAET(150)을 계산하는데 사용되는 비활동성 타임아웃(140)의 일부분은 비활동성 타임아웃(140)의 1/2이므로 비활동성 타이머(110)가 IT(140)의 1/2에 도달할 때 초기 수신확인 요청(115) 또는 연결지속 메시지가 전송된다. 또한, 예시적인 실시예는 애플리케이션 및 인프라구조 메시지들(115)이 전송될 최대 횟수인 최대 재시도 계수(155:MRC)를 식별하는 것을 제공한다. 최대 재시도 계수(155)에 기초하여, 연결지속 간격(145:KAI)이 계산될 수 있는데, 이것은 메시지들을 전송하는 시간 주기를 나타낸다. 따라서, 하나 이상의 메시지들이 계산된 KAI(145)에 기초하여 전송되고, 그 전송된 메시지들은 수신확인 요청 메시지(115)를 포함해야 한다. 물론, 상기 기술한 바대로, KAI(145)에 기초하여 전송된 메시지들은 애플리케이션 메시지들일 수 있다. 또한, 비활동성 타임아웃(140)은 판정된 전송 네트워크의 신뢰성 또는 기타 고려사항에 기초하여 조정될 수 있다.

본 발명의 범위 내의 실시예들은 또한 컴퓨터 명령어들 또는 데이터 구조들이 저장되고 전송되는 컴퓨터 판독가능 매체를 포함한다. 이런 컴퓨터 판독가능 매체는 범용 또는 전용 컴퓨터에 의해 액세스될 수 있는 임의 이용가능한 매체일 수 있다. 예로서, 이런 컴퓨터 판독가능 매체는 RAM, ROM, EEPROM, CD-ROM, 또는 기타 광 디스크 저장장치, 자기 디스크 저장장치 또는 기타 자기 저장 장치들, 또 는 원하는 프로그램 코드 수단을 컴퓨터 실행가능 명령어 또는 데이터 구조의 형태로 전달하거나 저장하는데 사용될 수 있고, 범용 또는 전용 컴퓨터에 의해 실행될 수 있는 기타 매체를 포함할 수 있다.

정보가 네트워크 또는 다른 통신 연결을 통해(하드웨어적으로, 무선으로, 또는 하드웨어 또는 무선의 결합에 의해서) 컴퓨터로 전송되거나 제공될 경우, 컴퓨터는 그 연결을 컴퓨터 판독가능 매체로서 적절하게 간주한다. 그러므로, 임의 이런 연결을 적절하게 컴퓨터 판독가능 매체라 한다. 상기 것의 조합도 컴퓨터 판독가능 매체에 포함되어야 한다. 컴퓨터 실행가능 명령어들은 예를 들어, 범용 컴퓨터, 전용 컴퓨터, 또는 전용 프로세싱 장치가 정해진 함수 또는 함수 그룹을 수행하게 하는 명령어들 및 데이터를 포함한다.

도 2 및 하기의 설명은 본 발명이 구현될 수 있는 적합한 컴퓨팅 환경에 대한 간략하고 일반적인 기술을 제공하기 위한 것이다. 요구되진 않았지만, 본 발명은 네트워크 환경의 컴퓨터들에 의해 실행되는 프로그램 모듈 등의 컴퓨터 실행가능 명령어들의 일반적인 문맥에서 기술될 것이다. 일반적으로, 프로그램 모듈들은 특정 태스크를 수행하거나 특정 추상화 데이터 타입을 구현하는 루틴, 프로그램, 객체, 컴포넌트, 및 데이터 구조 등을 포함한다. 컴퓨터 실행가능 명령어들, 관련 데이터 구조들, 및 프로그램 모듈들은 본원에 개시된 발명의 단계를 실행하는 프로그램 코드 수단의 예를 나타낸다. 이런 실행가능 명령어들 또는 관련 데이터 구조들의 특정 순서는 이런 단계에 기술된 함수를 구현하기 위한 대응하는 단계들의 예를 나타낸다.

당업자는 본 발명이 개인용 컴퓨터, 휴대형 장치, 멀티프로세서 시스템, 마이크로프로세서 기반의 또는 프로그램가능한 가전 제품, 네트워크 PC, 미니컴퓨터, 메인프레임 컴퓨터 등을 포함하여 여러 유형의 컴퓨터 시스템 구성으로 네트워크 컴퓨팅 환경에서 실시될 수 있음을 인식할 것이다. 본 발명은 또한 통신 네트워크를 통해(하드웨어적인 링크, 무선 링크, 또는 하드웨어 또는 무선 링크들의 조합 중 어느 하나에 의해) 링크된 로컬 또는 원격 프로세싱 장치에 의해 태스크들이 수행되는 분산 컴퓨팅 환경에서 실시될 수 있다. 분산 컴퓨팅 환경에서, 프로그램 모듈은 로컬 및 원격 메모리 저장 장치들 모두에 위치할 수 있다.

도 2를 참조하면, 본 발명을 구현한 예시적인 시스템은 프로세싱 유닛(221), 시스템 메모리(222), 및 다양한 시스템 컴포넌트들을 프로세싱 유닛(221)에 결합시키는 시스템 버스(223)를 포함하는 종래의 컴퓨터(220) 형태인 범용 컴퓨팅 장치를 포함한다. 시스템 버스(223)는 메모리 버스 또는 메모리 컨트롤러, 주변 장치 버스, 및 다양한 버스 아키텍처 중 임의 것을 사용하는 로컬 버스를 포함하여 여러 유형의 버스 구조들 중 하나일 수 있다. 시스템 메모리는 판독 전용 메모리(ROM:224) 및 임의 접근 메모리(RAM:225)를 포함한다. 시작할 때 등에 컴퓨터(220) 내의 구성 요소들 사이의 정보 전달을 돕는 기본 루틴들을 포함하는 기본 입력/출력 시스템(226:BIOS)이 전형적으로 ROM(224)에 저장된다.

컴퓨터(220)는 또한 자기 하드 디스크(239)를 판독하거나 이에 기록하는 자기 하드 디스크 드라이브(227), 분리형 자기 디스크(229)를 판독하거나 이에 기록하는 자기 디스크 드라이브(228), 및 CD-ROM 또는 기타 광 매체 등의 분리형 광 디 스크(231)를 판독하거나 이에 기록하는 광 디스크 드라이브(230)를 포함한다. 자기 하드 디스크 드라이브(227), 자기 디스크 드라이브(228), 및 광 디스크 드라이브(230)는 하드 디스크 드라이브 인터페이스(232), 자기 디스크 드라이브 인터페이스(233), 및 광 드라이브 인터페이스(234)에 의해 각각 시스템 버스(223)에 연결된다. 드라이브들 및 그 관련 컴퓨터 판독가능 매체는 컴퓨터 실행가능 명령어들, 데이터 구조들, 프로그램 모듈들, 및 기타 데이터의 비휘발성 저장 장소를 컴퓨터(220)에 제공한다. 본원에 기술된 예시적인 환경이 자기 하드 디스크(239), 분리형 자기 디스크(229), 및 분리형 광 디스크(231)를 이용하였으나, 자기 카세트, 플래시 메모리 카드, DVD, 베르누이 카트리지, RAM, ROM 등을 포함하여 데이터를 저장하기 위한 기타 유형의 컴퓨터 판독가능 매체가 사용될 수 있다.

하나 이상의 프로그램 모듈을 포함하는 프로그램 코드 수단이 운영 체제(235), 하나 이상의 애플리케이션 프로그램들(236), 기타 프로그램 모듈들(237), 및 프로그램 데이터(238)를 포함하고 있는 하드 디스크(239), 자기 디스크(229), 광 디스크(231), ROM(224), 또는 RAM(225)에 저장될 수 있다. 사용자는 키보드(240), 포인팅 장치(242), 및 마이크로폰, 조이스틱, 게임 패드, 위성 접시형 안테나, 스캐너 등의 기타 입력 장치(도시 생략)를 통해 명령어와 정보를 컴퓨터(220)에 입력할 수 있다. 이런 장치들과 기타 입력 장치들은 종종 시스템 버스(223)에 결합된 직렬 포트 인터페이스(246)를 통해 프로세싱 유닛(221)에 연결되어 있다. 대안으로서, 입력 장치는 병렬 포트, 게임 포트, 또는 범용 직렬 버스(USB) 등의 기타 인터페이스에 의해 연결될 수 있다. 모니터(247) 또는 다른 디스플레이 장치 도 비디오 어댑터(248) 등의 인터페이스를 통해 시스템 버스(223)에 연결될 수 있다. 모니터 이외에 개인용 컴퓨터는 전형적으로 스피커와 프린터 등의 기타 주변 출력 장치들(도시 생략)도 포함한다.

컴퓨터(220)는 원격 컴퓨터(249a 및 249b) 등의 하나 이상의 원격 컴퓨터들로의 논리적 연결을 사용하는 네트워크화된 환경에서 동작할 수 있다. 원격 컴퓨터(249a 및 249b)는 각각 다른 개인용 컴퓨터, 서버, 라우터, 네트워크 PC, 피어 장치 또는 기타 공통 네트워크 노드일 수 있으며, 비록 메모리 저장 장치(250a 및 250b) 및 그 관련 애플리케이션 프로그램들(236a 및 236b)만이 도 2에 예시되었으나, 전형적으로 컴퓨터(220)에 관련하여 상기에 기술된 구성요소들 중 다수 혹은 모두를 포함한다. 도 2에 도시된 논리적 연결들은 예로서 본원에 제시된 근거리 통신망(LAN:251)과 광역 통신망(WAN:252)을 포함하나, 이에만 한정되지 않는다. 이런 네트워킹 환경은 사무실 규모 또는 기업 규모 컴퓨터 네트워크, 인트라넷, 및 인터넷에서 흔한 것이다.

LAN 네트워킹 환경에서 사용될 때, 컴퓨터(220)는 네트워크 인터페이스(253)나 어댑터를 통해 LAN(251)으로 연결된다. WAN 네트워킹 환경에서 사용될 때, 컴퓨터(220)는 전형적으로 인터넷 등의 WAN(252)을 거쳐 통신을 설정하기 위한 모뎀(254), 무선 링크 또는 기타 수단을 포함할 수 있다. 내장 또는 외장 될 수 있는 모뎀(254)이 직렬 포트 인터페이스(246)를 통해 시스템 버스(223)로 연결될 수 있다. 네트워크화된 환경에서, 컴퓨터(220)에 관련하여 도시된 프로그램 모듈이나 그의 일부는 원격 메모리 저장 장치에 저장될 수 있다. 도시된 네트워크 연결들은 예시적인 것이며, WAN(252)을 통해 통신을 설정하기 위한 기타 수단들이 사용될 수 있다는 것을 인식할 것이다.

본 발명은 그 정신 또는 본질적 특징 내에서 기타 특정 형태로 구현될 수 있다. 상기 기술된 실시예들은 모든 면에서 예시적인 것이지 한정하는 것은 아니다. 그러므로, 본 발명의 범위는 상기의 상세에 의해서 보다는 첨부된 청구항에 의해 나타난다. 청구항에 필적하는 의미와 범주 내에서 나온 모든 변경들이 범위 내에 포함될 것이다.

본 발명은 웹 서비스용 신뢰성 있는 메시징 프로토콜(RM-WS 프로토콜)에 따라 설정된 시퀀스 세션 동안 양 종단 간 메시지들의 송수신을 감시하는 방법을 제공하는 효과가 있다.

Claims

웹 서비스(web services; WS) 환경의 발신자 컴퓨터 시스템(initiator computer system)에 의해 수행되고, 웹서비스용 신뢰성 있는 메시징 프로토콜(이하, RM-WS 프로토콜로 칭함)을 이용함으로써 종단 간 시퀀스 세션 동안 연결 지속성을 유지하는 방법으로서,

고유한 시퀀스 식별자에 의해 식별된 시퀀스 세션을 RM-WS 프로토콜에 따라 양 종단 애플리케이션들 사이의 애플리케이션 계층에 설정하는 단계,

상기 시퀀스 세션 동안 비활동성 타임아웃 주기(inactivity timeout period)를 식별하는 단계-상기 비활동성 타임아웃 주기는 상기 시퀀스 세션 동안 메시지를 수신하지 않은 채 지날 수 있는 시간에 관한 상한선을 나타냄-,

상기 연결 지속성을 유지하도록, 상기 비활동성 타임아웃 주기 이전에 상기 고유한 시퀀스 식별자를 포함하는 메시지를 수신하는 단계,

상기 수신된 메시지에 기초하여, 상기 시퀀스 세션이 지속되도록 상기 비활동성 타임아웃 주기 동안 비활동성 타이머를 리셋하는 단계,

상기 비활동성 타임아웃 주기에 기초하는 알고리즘에 따라 연결지속 만료 타임아웃(keep-alive expiration timeout)을 계산하는 단계, 및

상기 계산된 연결지속 만료 타임아웃에 기초하여, 상기 고유한 시퀀스 식별자를 포함하는 메시지를 전송하는 단계

를 포함하는 방법.
제1항에 있어서,

상기 고유한 시퀀스 식별자를 포함하는 상기 수신된 메시지는 애플리케이션 레벨 메시지인 방법.
제1항에 있어서,

상기 고유한 시퀀스 식별자를 포함하는 전송된 메시지는 RM-WS 프로토콜에 의해 정의된 인프라구조 멱등(infrastructure idempotent) 메시지인 수신확인 요청 메시지이며, 상기 수신된 메시지는 상기 수신확인 요청 메시지에 응답하는 인프라구조 수신확인 메시지인 방법.
제1항에 있어서,

상기 발신자 컴퓨터 시스템은 주소참조 불가능하며, 상기 발신자 컴퓨터 시스템은 HTTP를 이용하여 SOAP(SOAP over HTTP)를 통해 수신자와 통신하는 방법.
제1항에 있어서,

상기 고유한 시퀀스 식별자를 포함하는 전송된 메시지는 상기 RM-WS 프로토콜에 의해 정의된 인프라구조 멱등 메시지인 수신확인 요청 메시지이며, 수신자 컴퓨터 시스템에 전송될 애플리케이션 메시지들은 중단되지만, 상기 수신확인 요청 메시지는 전송되는 방법.
제1항에 있어서,

상기 연결지속 만료 타임아웃을 계산하는 알고리즘은 또한 상기 비활동성 타임아웃 주기의 일부분에 기초하는 것인 방법.
제6항에 있어서,

상기 고유한 시퀀스 식별자를 포함하는 전송된 메시지는 상기 RM-WS 프로토콜에 의해 정의된 인프라구조 멱등 메시지인 수신확인 요청 메시지이며, 상기 연결지속 만료 타임아웃을 계산하는데 사용되는 상기 비활동성 타임아웃 주기의 일부는 비활동성 타임아웃 주기의 1/2이어서, 상기 비활동성 타이머가 상기 비활동성 타임아웃 주기의 1/2에 도달할 때 상기 수신확인 요청 메시지가 전송되는 방법.
제6항에 있어서,

상기 발신자 컴퓨터 시스템에 의해 수행되는,

애플리케이션 및 인프라구조 메시지들이 전송될 최대 횟수인 최대 재시도 계수를 식별하는 단계,

상기 최대 재시도 계수에 기초하여 연결지속 간격을 계산하는 단계-상기 연결지속 간격은 메시지들을 전송하는 시간 주기를 나타냄-, 및

상기 계산된 연결지속 간격에 기초하여 상기 고유한 시퀀스 식별자를 포함하는 하나 이상의 메시지들을 전송하는 단계-상기 전송된 하나 이상의 메시지들은 애플리케이션 레벨 메시지 또는 수신확인 요청 메시지 중 적어도 하나를 포함함-

를 더 포함하는 방법.
웹 서비스(WS) 환경의 컴퓨터 시스템에 의해 수행되고, WS용 신뢰성 있는 메시징 프로토콜(이하 RM-WS 프로토콜로 칭함)을 이용함으로써 종단 애플리케이션들 사이의 시퀀스 세션 동안 연결 지속성을 검증하는 방법으로서,

고유한 시퀀스 식별자에 의해 식별된 시퀀스 세션을 RM-WS 프로토콜에 따라 양 종단 애플리케이션들 사이의 애플리케이션 계층에 설정하는 단계,

상기 시퀀스 세션 동안 상기 양 종단 간 메시지를 교환하지 않은 채 지날 수 있는 시간에 관한 상한선을 나타내는 비활동성 타임아웃 주기를 식별하는 단계,

상기 비활동성 타임아웃 주기가 만료하기 이전에, 상기 연결 지속성을 검증하기 위해 상기 시퀀스 세션에 대응하는 고유한 시퀀스 식별자를 포함하는 메시지를 수신하는 단계, 및

상기 수신된 메시지에 기초하여, 상기 시퀀스 세션이 지속되도록 상기 비활동성 타임아웃 주기 동안 비활동성 타이머를 리셋하는 단계

를 포함하는 방법.
제9항에 있어서,

상기 수신된 메시지는 상기 시퀀스 세션의 발신자 컴퓨터 시스템에 의해 수신되며, 상기 수신된 메시지는 이전에 상기 발신자 컴퓨터 시스템에 의해 전송된 수신확인 요청 메시지에 응답하는 인프라구조 수신확인 메시지인 방법.
제9항에 있어서,

상기 수신된 메시지는 상기 시퀀스 세션의 수신자 컴퓨터 시스템에 의해 수신되며, 상기 수신된 메시지는 시퀀스 수신확인 요청인 방법.
제9항에 있어서,

상기 비활동성 타임아웃 주기는 통신 매체에 의해 부과된 대기시간을 고려하여 조정될 수 있는 방법.
제9항에 있어서,

상기 비활동성 타이머를 리셋한 이후에, 애플리케이션 또는 인프라구조 메시지들이 상기 비활동성 타임아웃 주기의 만료 이후에 수신되지 않고, 상기 시퀀스 세션은 버려지는 것인 방법.
프로세서에 의해 실행될 때, 메시징 시스템이 제1항 내지 제8항 중 어느 한 항에 따른 방법을 수행하게 하는 컴퓨터 실행가능 명령어들이 저장되어 있는 하나 이상의 컴퓨터 판독가능 기록 매체.
프로세서에 의해 실행될 때, 메시징 시스템이 제9항 내지 제13항 중 어느 한 항에 따른 방법을 수행하게 하는 컴퓨터 실행가능 명령어들이 저장되어 있는 하나 이상의 컴퓨터 판독가능 기록 매체.
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제