KR101201140B1

KR101201140B1 - 요구-응답 전송 프로토콜들에 의한 신뢰성 있는 단방향메시징

Info

Publication number: KR101201140B1
Application number: KR1020050107092A
Authority: KR
Inventors: 마이클 티. 다이스; 리차드 디. 힐; 로드니 티. 림프레츠; 샤이 코헨; 스테판 알. 바트레스
Original assignee: 마이크로소프트 코포레이션
Priority date: 2004-12-10
Filing date: 2005-11-09
Publication date: 2012-11-13
Also published as: US7349384B2; CN1812405B; US20060129690A1; EP1670214A1; KR20060065487A; CN1812405A; JP2006178961A

Abstract

예시적인 실시예들은 단방향 메시지 교환 패턴에서 요구-응답 전송 프로토콜들(예를 들어, HTTP)과 RM 프로토콜들 간의 결합(binding) 메커니즘을 제공한다. 본 발명은 새로운 기반구조 서비스들의 재구성 또는 배치 없이 요구-응답 전송 프로토콜들의 기존 네트워크 특성을 이용한다. 요구-응답 전송 모델은 특성이 비대칭적이며, 2가지 데이터 흐름, 즉, 요구 흐름과 응답 흐름을 제공한다. 이니시에이터가 어드레스 가능하지 않은 경우 및/또는 통신이 요구-응답 전송을 요구하는 경우, 본 발명은, 기반구조 및 애플리케이션 메시지들이 요구 흐름에서 전송될 수 있게 하고, 수신확인들 및 다른 기반구조 메시지들이 전송의 응답 흐름을 거쳐서 전송될 수 있다.

신뢰성 있는 메시징 프로토콜(RM 프로토콜), 네트워크, 메시지 교환, 요구, 응답, 요구-응답 전송 프로토콜

Description

요구-응답 전송 프로토콜들에 의한 신뢰성 있는 단방향 메시징{RELIABLE ONE-WAY MESSAGING OVER REQUEST-RESPONSE TRANSPORT PROTOCOLS}

도 1a는 예시적인 실시예들에 따른 요구-응답 전송 프로토콜(request-response transport protocol)에 의한 애플리케이션-레벨 메시지의 신뢰성 있는 단방향 교환 패턴을 위한 프로토콜 스택을 도시한 도면.

도 1b는 예시적인 실시예들에 따른 요구-응답 전송 프로토콜에 의한 가능성 있는 신뢰성 있는 단방향 메시지 시퀀스 교환을 도시한 도면.

도 2는 예시적인 실시예들에 따른 요구-응답 전송 프로토콜에 의해 애플리케이션 레벨 메시지들을 전송할 때 분산형 시스템을 위한 신뢰성 있는 메시징 프로토콜을 제공하는 방법의 흐름도.

도 3은 본 발명을 위한 적절한 운영 환경을 제공하는 예시적인 시스템을 도시한 도면.

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

320: 컴퓨터 321: 프로세싱 유닛

322: 시스템 메모리 323: 시스템 버스

324: ROM 325: RAM

326: BIOS 327: 자기 하드 디스크 드라이브

328: 자기 디스크 드라이브 329: 분리형 자기 디스크

330: 광학 디스크 드라이브 331: 분리형 광학 디스크

332: 하드 디스크 드라이브 인터페이스

333: 자기 디스크 드라이브 인터페이스

334: 광학 드라이브 인터페이스 335: 운영 체계

336: 애플리케이션 프로그램들 337: 프로그램 모듈들

338: 프로그램 데이터 339: 하드 디스크

340: 키보드 342: 포인팅 장치

본 발명은 일반적으로 분산형 시스템들, 예를 들어, 웹 서비스들(Web Services)을 위한 신뢰성 있는 메시징(Reliable Messaging) 프로토콜들에 관한 것이다. 특히, 본 발명은 단방향 메시지 교환 패턴(one-way message exchange pattern) 환경에서 요구-응답 전송 프로토콜들(예를 들어, HTTP)에의 분산형 시스템들을 위한 신뢰성 있는 메시징 프로토콜들의 결합을 제공한다.

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

OSI 모델은, 전자 메시지를 전송하기 위한 연산들을, 각각 데이터 전송 프로세스에서 소정의 연산들을 수행하도록 지정된 7개의 별개의 계층들로 구분한다. 프로토콜 스택들은 계층들 각각을 가능성 있게 구현할 수 있고, 많은 프로토콜 스택들은 네트워크를 거쳐서 데이터를 전송하는데 사용하기 위한 선택적인 계층들만을 구현한다. 데이터가 컴퓨팅 시스템으로부터 전송될 때, 데이터는 애플리케이션 계층에서 시작하고, 중간의 하위 계층들로 전달되고 나서, 네트워크에 전달된다. 데이터가 네트워크로부터 수신될 때, 데이터는 물리 계층에 들어가고, 상위의 중간 계층들로 전달되고 나서, 결국 그 애플리케이션 계층에서 수신된다. 애플리케이션 계층 - 최상위층 - 은, 애플리케이션 지원 및 최종 사용자(end-user) 프로세싱을 담당한다. 또한, 애플리케이션 계층 내에는, 몇 개의 다른 계층들(예를 들어, SOAP(Simple Open Access Protocol) 계층)이 존재할 수 있다. 대부분의 프로토콜 스택들에 의해 통합되는 다른 계층은 전송 계층이다. 전송 계층의 한 예가 TCP(Transmission Control Protocol)이다.

웹 서비스(WS)는, 컴퓨팅 시스템들 간의 통신을 진척시킴에 있어서 추진력(driving force)이 되어 왔고, 소프트웨어의 빌드(build) 및 이용 방법을 변화시키고 있다. 웹 서비스는 애플리케이션들로 하여금 데이터를 공유하게 하고, - 더욱 강력하게는 - 이들 애플리케이션들이 어디에서 어떻게 빌드되는지; 애플리케이션들 이 어떤 운영 체계들 또는 플랫폼에서 실행되는지; 및 애플리케이션들에 액세스하기 위해 어떤 장치들이 이용되는지에 관계없이 다른 애플리케이션들로부터 성능들(capabilities)을 호출하게 한다. 웹 서비스들은 SOAP, XML(eXtensible Markup Language), UDDI(Universal, Description, Discovery and Integration), WSDL(Web Service Description Language) 등을 포함하는 산업-표준(industry standard) 프로토콜들에 의하여 인터넷을 통해 호출된다. 비록 웹 서비스들이 서로 독립적으로 유지되지만, 웹 서비스들은 그들 자신을 특정 태스크를 수행하는 협력 집단에 유연하게(loosely) 링크할 수 있다.

현재의 WS 기술은, 이니시에이터(initiator)(예를 들어, 클라이언트)와 억셉터(acceptor)(예를 들어, 서비스) 간의 직접 SOAP-메시지 통신을 제공한다. 일반적인 양방향 메시징의 경우에, SOAP 요구 메시지가 이니시에이터로부터 억셉터로 전송되고, 그에 응답하여 SOAP 응답 메시지가 전송된다. 종단점(endpoint)들 간에 상이한 다른 통신은 단방향 메시지이고, 여기서, 이니시에이터는 아무런 응답 없이 억셉터로 메시지를 전송한다.

최근에 생겨난 WS 아키텍처의 핵심적인 이점은, 통합된, 공동 이용이 가능한(interoperable) 솔루션들을 전달하는 능력이다. 그러나, 웹 서비스들은 인터넷과 같은 신뢰성이 없는 통신 채널들을 통해 다른 비지니스, 발생지들(originations) 및 다른 서비스 제공자들로부터의 다양한 서비스들을 제공하기 때문에, WS의 신뢰성이 점점더 중요한 요인이 되고 있다. WS의 신뢰성은, 이것들로 한정되지는 않지만, 웹 서비스 종단점들의 신뢰성, 웹 서비스들이 액세스 되는 통신 채널의 신뢰성 특성들(reliability characteristics), 성능 및 장애 허용 특성들, 및 웹 서비스들이 동시 클라이언트 액세스를 조정할 수 있는 정도를 포함하는 여러 요인에 의해 영향을 받는다.

메시지들(예를 들어, SOAP 메시지들)이 종단점들 간에 교환되는 신뢰성 있는 전송 프로토콜을 선택함으로써 웹 서비스들의 신뢰성 있는 메시징을 달성하는 것에 대한 시도들이 있어 왔다. 예를 들어, 이니시에이터들과 억셉터들 간에 신뢰성 있게 메시지들을 전달하기 위해 메시지 큐(message-queue)와 같은 신뢰성 있는 메시징 전송이 이용될 수 있다. 메시지 큐잉(queuing) 통신 기술은, 서로 다른 시스템들 상의 애플리케이션들이, 신뢰성을 위해 실패들(failures)에 대하여 존속되는 큐들에 메시지들을 전송하고 큐들로부터 메시지들을 판독함으로써 서로 통신할 수 있게 한다.

비록 큐잉 시스템들이 SOAP 메시지들을 신뢰성 있게 전달하는데 이용될 수 있는 전송(transport)을 제공하지만, 이러한 시스템들에 대하여 여러 단점들이 존재한다. 예를 들어, 이들 시스템들은, 요구들(및 가능하게는 그 응답들)이 분리되어 전송되고 처리되는 비동기 연산을 위한 솔루션들을 제공한다. 따라서, 이들 시스템들은 통상적으로 자원 면에서 거대(heavyweight)하고, 영속성있는 트랜잭션 메시지 저장소들을 가지며 배치(deployment), 프로그래밍 모델 및 관리에 있어서 훨씬 더 복잡한 복수의 중간물들(intermediaries)을 수반한다. 이들 모두는 신뢰성 있는 직접 통신을 위해 불필요하고, 지연시간(latency) 최소화 목적을 저하시킨다. 또한, 프로그램 모델은 요구-응답 스타일 프로그래밍 또는 세션들을 직접적으로 지 원하지 않는다. 따라서, 큐잉된 통신 모델은 현재의 "쌍방향(interactive)" 웹 서비스 모델과 상이하고, 결정적인 "접속되는(connected)" 시나리오들 및 "쌍방향" 애플리케이션들을 처리하지 않는다. 예를 들어, 큐잉된 통신 모델은 응답이 빠른 시간 내에 예측되는 경우들에 대하여, 또는 분산형 트랜잭션 문맥(distributed-transaction-context)이 이니시에이터와 억셉터 간에 공유되어야 할 필요가 있는 경우들에 대하여 적절하지 않다.

근본적으로는 신뢰성이 없는 전송 프로토콜들, 예를 들어, 신뢰성 있는 HTTP 또는 HTTPR에 의해 신뢰성 있는 전송 계층들을 정의하는 것에 대한 시도들이 또한 있어 왔다. 그러나, 이러한 솔루션뿐만 아니라 큐잉 솔루션을 해롭게 하는 공통적인 문제점은, 특정한 신뢰성 있는 전송 프로토콜이 이니시에이터와 억셉터 간의 통신에 이용되는 경우에만 신뢰성 있는 메시징이 달성될 수 있다는 것이다. 웹 서비스의 근본적인 성질은, 특정 벤더 플랫폼, 구현 언어들 및 특정 전송 프로토콜들로부터 독립성을 요구한다. 일반적인 경우, 이니시에이터는 특정 프로토콜을 이용하여 억셉터에 메시지를 직접 전송할 수 없을 수 있거나(예를 들어, 억셉터는 그 프로토콜을 지원하지 않는다) 또는 메시지는 전송 노드를 떠난 후 그 목적지 노드에 도착하기 전, 복수의 홉(hop)을 통과할 필요가 있을 수 있다. 특정 홉에 포함되는 2개의 노드 간의 접속 특성에 따라, 신뢰성 있는 메시징 특성을 제공하지 않는 적절한 전송 프로토콜이 선택되어야 할 수 있다.

중간물들이 또한 프로토콜 스택의 서로 다른 레벨들에 존재할 수 있고, 이에 따라, 완전한 단-대-단 신뢰성(full end-to-end reliability)을 제공하지 않는다. 예를 들어, 전송 프로토콜들은 하위 레벨 중간물들(예를 들어, IP 라우터 등의 IP 레벨 중간물들)에 걸쳐서 신뢰성을 제공할 수 있다. 그러나, 전송 프로토콜은 SOAP 중간물 또는 애플리케이션 계층(예를 들어, HTTP 프록시)에서 끝날 수 있다. 따라서, 전송 프로토콜은 그 중간물에 걸쳐서 신뢰성, 즉, 애플리케이션 계층에 걸쳐서 어떠한 단-대-단 신뢰성도 제공하지 못할 수 있다.

최근에, 분산형 시스템들을 위한 다양한 신뢰성 있는 메시징(Reliable Messaging) 프로토콜들(이하, "RM 프로토콜들"이라 지칭됨)은, 현재의 신뢰성 있는 메시징 시스템들의 상기 식별된 결함들에 대한 솔루션들을 제공한다. 이들 프로토콜들(예를 들어, WS-ReliableMessaging, WS-Reliability 등을 포함하는 WS(Web Service)를 위한 RM 프로토콜들)은, 메시지들이, 소프트웨어 컴포넌트, 시스템 또는 네트워크 실패들(failures)의 존재하에서 종단점 애플리케이션들 간에 신뢰성 있게 전달될 수 있게 하는 전송 불가지론적(agnostic) 접속 프로토콜들이다. 따라서, RM 프로토콜들은 이니시에이터와 억셉터 간의 신뢰성 있는, 단-대-단, 잠재적으로 세션-지향적인(potentially session-oriented) 통신을 위한 솔루션들을 제공한다.

이들 RM 프로토콜들은, TCP가 IP(Internet Protocol) 라우터들 및 복수의 네트워크들을 거쳐서 TCP 송신자로부터 TCP 수신자로 신뢰성 있는, 정확히-한 번의, 바이트 스트림의 정렬된(in-order) 전달을 제공한다는 점에서, TCP와 유사하다. 분산형 시스템들을 위한 신뢰성 있는 메시징 프로토콜들은, 복수의 중간물들(전송 및 SOAP 레벨 중간물들을 포함함), 전송들 및 접속들을 거치는 메시지들(전송 단위 는 바이트가 아닌 메시지임에 주의한다)에 대하여 동일한 것 이상을 제공한다. TCP 및 RM 프로토콜들은 둘다 "신뢰성 있는" 프로토콜들이지만, RM 프로토콜들(및 더욱 일반적으로는, SOAP 계층)은 OSI 모델의 애플리케이션 계층에 존재하기 때문에, RM 프로토콜들은 데이터를 전송하는데 이용되는 전송 프로토콜에 관계없이 신뢰성 있는 메시징을 제공한다. 따라서, RM 프로토콜들은 종단점들 간에 메시지를 전송하기 위해 이용되는 특정한 전송 또는 다른 프로토콜에 얽매이지 않는다.

몇몇 RM 프로토콜들이 소정 기간 동안 존재해 왔지만, 여전히 이들 프로토콜 사양에 대한 여러 가지 결점들 및 결함들이 존재한다. 예를 들어, 분산형 시스템들을 위한 신뢰성 있는 메시징 프로토콜들은 통상적으로 양방향 메시지 교환을 요구한다. 즉, 애플리케이션 메시지들은 한쪽 방향으로 진행하고, 기반구조 수신확인들(infrastructure acknowledgments)은 다른쪽 방향으로 진행한다. 또한, 요구받지 않은 억셉터-이니시에이터 통신이 가능하지 않은 경우들, 예를 들어, 이니시에이터가 방화벽 뒤에 있고 요구-응답 전송 프로토콜(예를 들어, HTTP) 접속(예를 들어, HTTP 프록시를 통한 터널링(tunneling)에 의한)을 이용하여 억셉터와 통신하는 경우가 존재한다. 그러나, 이니시에이터가 통상적으로 어드레스 가능하지 않고 및/또는 통신이 요구-응답 전송 프로토콜로 한정되기 때문에 이니시에이터로 수신확인들 및 다른 기반구조 메시지들을 전송할 수 있는 것에 문제가 발생한다. 따라서, 요구-응답 메시징 패턴을 제공하는 전송을 통해 이니시에이터로부터 억셉터로의 단방향 메시지 교환 패턴의 애플리케이션-레벨 메시지들 - 및 양방향의 RM 기반 구조 메시지들 - 의 신뢰성 있는 전송을 조정하는 것이 요구된다.

분산형 시스템들(예를 들어, 웹 서비스)을 위한 현재의 신뢰성 있는 메시징 프로토콜들의 전술한 결함들 및 결점들은 본 발명의 예시적인 실시예들을 통하여 해결된다. 예시적인 실시예들은, 새로운 기반구조 서비스들의 재구성 또는 배치 없이 요구-응답 전송 프로토콜의 기존 네트워크 특성을 이용함으로써 요구-응답 전송 프로토콜을 통해 애플리케이션-레벨 메시지들을 전송하는 경우에 분산형 시스템들을 위한 신뢰성 있는 메시징 프로토콜(RM 프로토콜, 예를 들어, WS-ReliableMessaging)을 제공한다.

이니시에이터 컴퓨팅 장치에서, 예시적인 실시예들은, 애플리케이션-레벨 메시지의 억셉터 종단점과의 신뢰성 있는 단방향 메시지 교환 패턴을 위해 이니시에이터 종단점에서 애플리케이션-레벨 메시지를 생성하는 것을 제공한다. 애플리케이션-레벨 메시지는 그 다음에 분산형 시스템을 위한 신뢰성 있는 메시징 프로토콜(RM 프로토콜)에 따라 포맷팅된다. 그 후, 애플리케이션-레벨 메시지는 요구-응답 전송 프로토콜의 요구 흐름(request flow)을 통해 전송된다. 대응하는 전송-레벨 응답 메시지가 그 다음에 요구-응답 전송의 응답 흐름(reply flow)을 통해 수신되고, RM 프로토콜에 따르기 위해 RM 프로토콜 기반구조 정보에 링크된다.

억셉터 컴퓨팅 장치로부터, 다른 예시적인 실시예들은 이니시에이터로부터 억셉터로 신뢰성 있는 단방향 메시지 교환 패턴으로 애플리케이션-레벨 메시지를 수신하는 것을 제공한다. 애플리케이션-레벨 메시지는 익명의(anonymous) 요구-응 답 전송 프로토콜의 요구 흐름을 통해 수신된다. 또한, 애플리케이션-레벨 메시지는 분산형 시스템들을 위한 신뢰성 있는 메시징 프로토콜(RM 프로토콜)에 따라 포맷팅된 것으로서 식별된다. RM 프로토콜 기반구조 정보는 그 다음에 전송-레벨 응답에 링크되고, 기반구조 정보는 하나 이상의 애플리케이션-레벨 메시지들의 신뢰성 있는 교환에 대응한다. 그 후, 전송-레벨 응답은 RM 프로토콜에 따르기 위해 요구-응답 전송 프로토콜의 응답 흐름을 통해 전송된다.

본 발명의 추가적인 특징들 및 장점들은 뒤따르는 상세한 설명에서 설명될 것이고, 부분적으로는 그 설명으로부터 명백해지거나, 또는 본 발명의 실행에 의해 습득될 수 있다. 본 발명의 특징들 및 장점들은 첨부된 특허청구범위에서 특정적으로 지적된 기구들(instruments) 및 조합들에 의하여 인식되고 얻어질 수 있다. 본 발명의 이들 및 다른 특징들은, 다음의 상세한 설명 및 첨부된 특허청구범위로부터 더욱 완전하게 명백해 지거나, 또는 이하 설명되는 바와 같이 본 발명의 실행에 의해 습득될 수 있다.

본 발명의 전술한 및 다른 장점들 및 특징들이 얻어질 수 있는 방법을 설명하기 위하여, 상기에서 간단하게 설명된 본 발명의 보다 특정적인 설명이 첨부된 도면들에 예시된 특정 실시예들을 참조하여 묘사된다. 이들 도면들은 본 발명의 전형적인 실시예들만을 도시하고, 이에 따라 그 범위의 한정사항인 것으로 고려되어서는 안 된다는 것을 이해하면, 본 발명은 첨부 도면의 이용을 통하여 보다 특정적으로 상세하게 기술되고 설명될 것이다.

본 발명은, 종단점들 간의 단방향 메시지 교환 패턴에서 요구-응답 전송 프 로토콜(예를 들어, HTTP)과 분산형 시스템(예를 들어, 웹 서비스)을 위한 신뢰성 있는 메시징 프로토콜을 결합하기 위한 방법들, 시스템들 및 컴퓨터 프로그램 제품들로 확장된다. 본 발명의 실시예들은 하기에 보다 상세하게 설명된 바와 같이, 다양한 컴퓨터 하드웨어를 포함하는 특수 목적 또는 범용 컴퓨터를 포함할 수 있다.

본 발명은, 메시지들이, 소프트웨어 컴포넌트, 시스템 또는 네트워크 실패들(failures)의 존재하에서 분산형 애플리케이션들 간에 신뢰성 있게 전달될 수 있게 하는 프로토콜들을 기술하는, 분산형 시스템들을 위한 신뢰성 있는 메시징(Reliable Messaging) 프로토콜들(이하, "RM" 프로토콜들이라고 지칭됨)의 확장에 관한 것이다. 분산형 시스템들(예를 들어, 웹 서비스)을 위한 신뢰성 있는 메시징 프로토콜들은, 소스(이하, "이니시에이터(initiator)")로부터 서비스 등의 목적지(이하, "억셉터(acceptor)")로의 성공적인 메시지 전송을 용이하게 하고, 에러 상태들이 검출가능하다는 것을 보증한다. 이들 프로토콜들은 전송 불가지론적(agnostic)이므로, 이들 프로토콜들이 서로 다른 네트워크 전송 기술들을 이용하여 구현될 수 있게 한다. 또한, 신뢰성 있는 메시징 프로토콜들의 다양한 구현들은, 애플리케이션들로부터 간헐적(intermittent) 통신 실패들을 숨기고, 시스템 실패들의 경우에 복구성(recoverability)을 제공할 수 있다.

전술한 바와 같이, 예시적인 실시예들은 RM 프로토콜들과 요구-응답 전송 프로토콜들(예를 들어, HTTP) 간의 결합 메커니즘을 제공한다. 본 발명은 새로운 기반구조 서비스들의 재구성 또는 배치 없이 요구-응답 전송 프로토콜들의 기존 네트 워크 특성을 이용한다. 요구-응답 전송 모델은 특성이 비대칭적이며, 2가지 데이터 흐름, 즉, 요구 흐름과 응답 흐름을 제공한다. 이러한 요구-응답 모델은, 요구에 의해 제공되는 전송 접속을 이용하여, 응답 메시지가 요구 메시지에 응답하여 그리고 그 뒤를 따라서만 전송될 수 있도록 메시징 패턴을 한정한다. 요구-응답 전송(예를 들어, SOAP 전송) 프로토콜의 특징적인 예가 "익명의(anonymous) HTTP"이고, 여기서, 이니시에이터는 어드레스 가능하지 않고, 오직 HTTP 프로토콜의 응답 흐름을 이용하여 메시지들을 수신할 수 있다.

예시적인 실시예들은, 이러한 응답 흐름들을 이용하여 이니시에이터에 수신확인들 및 다른 기반구조 메시지들을 전송한다. 본원에 기재된 바와 같은 익명의 요구-응답 전송 프로토콜들에 대한 세부사항들은, 이니시에이터가 직접 어드레스 가능하지 않은(즉, 이니시에이터 요구받지 않은 메시지들을 전송하는 방법이 존재하지 않는) 임의의 요구-응답 전송 프로토콜로 확장한다. 그러나, 본 발명은 익명의 요구-응답 전송 프로토콜들에 한정되지 않지만, 요구-응답 전송 프로토콜에 한정되는 임의의 통신에 적용한다는 것을 주목한다. 따라서, 본원에 기재된 바와 같은 요구-응답 전송 프로토콜의 임의의 특정 사용은 단지 예시를 위한 것이고, 명시적으로 청구되지 않는 한 본 발명의 범위를 한정하거나 좁게 하기 위한 것으로 의도되지 않는다.

도 1a는 예시적인 실시예들에 따른 요구-응답 전송 프로토콜에 의한 신뢰성 있는 단방향 교환 패턴을 위한 프로토콜 스택을 예시한다. 애플리케이션-레벨 메시지(도시되지 않음)가 분산형 시스템 프로토콜 예를 들어, 웹 서비스 프로토콜에 따라 애플리케이션 계층(115)에서 이니시에이터 종단점(105)에 의해 생성될 수 있다. 통상적으로 웹 서비스에서, 애플리케이션-레벨 메시지는 적절한 SOAP 헤더들을 갖는 SOAP 메시지일 것이다. 또한, 이 메시지는, 통상적으로 억셉터 종단점(110)에서 처리하기 위한 입력 연산을 포함하지만, 어떠한 출력 애플리케이션 계층(160) 메시지들도 억셉터 종단점(110)으로부터 이니시에이터 종단점(105)으로 되돌아 가지 않는다는 점에서 단방향이라고 고려된다.

애플리케이션-레벨 메시지는 신뢰성 있는 메시징 계층(120)으로 전달될 것이고, 신뢰성 있는 메시징 계층(120)에서, 애플리케이션-레벨 메시지는 RM 프로토콜(예를 들어, WS-ReliableMessaging, WS-Reliability 등)에 따라 포맷팅된다. 신뢰성 있는 메시징 계층(120)에서 수신되는 메시지들(135)은 또한 하기에 설명된 바와 같이, 어떠한 대응하는 수신확인 메시지들도 수신되지 않는 경우에 가능한 재전송을 위해 이니시에이터 버퍼(130)에 저장된다. 애플리케이션-레벨 메시지는 그 다음에 요구-응답 전송 계층(125)(예를 들어, 익명의 HTTP)의 요구 흐름(145)을 통해 전송되고, 억셉터 종단점(110)의 전송 계층(156)에서 수신된다. 애플리케이션-레벨 메시지는, 억셉터 종단점(110)의 애플리케이션 계층(160)에서의 후속 처리를 위해 억셉터 버퍼(165)에 수신된 메시지들(170)을 저장하는 신뢰성 있는 메시징 계층(155)에 전달된다.

단방향 라인은 신뢰성 있는 메시징 계층(155)으로부터 애플리케이션 계층(160)으로 흐름으로써, 이니시에이터 종단점은 통상적으로 어드레스 가능하지 않고 및/또는 통신은 요구-응답 타입 프로토콜을 요구하기 때문에 어떠한 애플리케이션 계층(160) 메시지들도 이니시에이터 종단점(105)으로 흐르지 않음을 나타낸다는 것을 주목한다. 그러나, 전술한 바와 같이, 예시적인 실시예들은 요구-응답 전송 계층(156, 125)을 통해 수신확인 응답들(도시되지 않음) 및 다른 기반구조 메시지들을 전송하기 위해 통상적인 요구-응답 전송 프로토콜들 예를 들어, HTTP의 응답 흐름(140) 특성을 이용한다. 다시 말하면, RM 기반구조 정보는 전송-레벨 응답 메시지에 링크되거나 피기백(piggyback)된다.

또한, 전송-레벨 응답 메시지에 링크되는 기반구조 정보는 여러 서로 다른 방법으로 특징 지워질 수 있다는 것을 주목한다. 예를 들면, 기반구조 정보(예를 들어, Ack 응답)는 전송-레벨 응답으로 생성 및 캡슐화될 수 있고, 그 다음에 요구-응답 전송 프로토콜의 응답 흐름(140)을 통해 전달된다. 이것은 기반구조 정보 내에서 포맷팅되는 바와 같이 전송-레벨 응답 메시지를 특징 지우는 것과 유사하다. 물론, 기반구조 정보가 어떻게 전송-레벨 응답 메시지에 링크되는지를 특징 지우기 위한 다른 방법들이 존재한다. 또한, 기반구조 정보와 전송-레벨 응답 메시지를 캡슐화하거나 포맷팅하기 위한 많은 잘 알려진 방법들이 존재한다. 따라서, 본 발명에 적용되는 바와 같이 전송-레벨 응답 메시지에 기반구조 정보를 링크하는 것은, 대체로 전송-레벨 응답 메시지에 기반구조 정보를 포맷팅하거나 피기백하는 임의의 처리 타입을 포함하는 것으로 해석되어야 한다.

기반구조 정보가 어떻게 전송-레벨 응답에 링크되고, 응답 흐름(140)을 통해 이니시에이터 종단점(105)에서 수신되는지에 관계없이, 기반구조 정보가 수신확인 응답(예를 들어, WS-ReliableMessaging에 의해 정의되는 Ack 메시지)인 경우, 신뢰 성 있는 메시징 계층(120)은 이니시에이터 버퍼(130)로부터 적절한 애플리케이션 메시지(135)를 제거할 것이다. 그러나, 메시지들에 대하여 수신확인들이 수신되지 않는 경우, 이니시에이터 종단점(105)은 전술한 바와 유사한 방식으로(즉, RM 프로토콜에 따라 요구-응답 전송을 이용하여 새로운 요구를 개시함으로써) 메시지들(135)의 전송을 재시도할 수 있다는 것을 주목한다. 어떠한 수신확인들도 소정 시간 한계, 소정의 재시도 횟수, 또는 임의의 다른 재시도-정책 관리(retry-policy governing) 메커니즘 후에 수신되지 않는 경우, 실패 통지(failure notice)가 애플리케이션 계층(115)에 전달될 수 있다.

신뢰성 있는 메시징 계층(120, 155)으로부터의 기반구조 메시지들(예를 들어, 생성 시퀀스 또는 종료 시퀀스 요구)은 어느 한쪽 방향으로 전송될 수 있지만, 요구-응답 전송의 제한들을 거친다. 특히, 억셉터 종단점(110)으로부터의 기반구조 메시지는 이니시에이터 요구들을 뒤따르는 전송-레벨 응답들에서만 발생할 수 있다. 또한, 전송 요구 메시지는 (예를 들어, SOAP 헤더 내의 필드들(fields)로서) 기반구조(RM 프로토콜) 정보뿐만 아니라 애플리케이션-레벨 메시지를 포함할 수 있다는 것을 주 목한다.

전술한 바와 같이, 수신확인 메시지들 및 다른 기반구조 메시지들은 요구-응답 전송 응답 흐름(140)에서 전송될 필요가 있다. 그러나, 억셉터 종단점(110)이 애플리케이션-레벨 메시지를 수신하지만 수신확인의 전송을 결정하지 않는 경우, 억셉터 종단점(110)은 여전히 요구-응답 전송 프로토콜에 따르기 위해 표준 전송-레벨 응답(예를 들어, Null 응답)을 전송해야 한다. 이니시에이터 종단점(105)은, 전송 레벨 요구가 완료되었다는 것과 이 응답 흐름이 더 이상 기반구조 메시지를 전송하기 위해 억셉터 종단점(110)에 이용가능하지 않다는 것 이외에, 이러한 Null 응답으로부터 임의의 특별한 의미를 추론하지 않는다. 예를 들어, HTTP의 경우에, 억셉터 종단점(110)은 HTTP 202 OK, 204 No Content, 또는 다른 유사한 HTTP-레벨 응답 메시지로 응답할 수 있다. 이 응답은 RM 기반구조에 의해 처리되지 않지만, RM 기반구조는 RM 기반구조 응답 메시지를 기다려서는 안 된다는 것을 알 필요가 있는 경우에 전송-레벨 응답이 수신되었다는 것을 알아차릴 수 있다는 것을 주목한다.

다른 예시적인 실시예들은 RM 프로토콜들에 따라 단방향 메시지 교환 패턴으로 하나 이상의 메시지들을 신뢰성 있게 전송하기 위해 RM 시퀀스 세션의 생성 및 이용을 지원한다. 시퀀스 세션을 생성하기 위한 요구가 (예를 들어, 애플리케이션-레벨 메시지에 링크된) 접속의 요구 흐름(145)을 통해 수신될 수 있고, 고유 시퀀스 식별자(unique sequence identifier)가 통상적으로 동일한 전송 접속의 응답 흐름(140)을 통해 즉시 전송될 것이다. 그러나, 본 발명에 이용가능한 시퀀스 세션을 생성하는 다른 방법들이 존재한다는 것을 주목한다. 예를 들어, 이니시에이터 종단점(105)은 고유 시퀀스 식별자를 생성하여 그 고유 시퀀스 식별자를 요구로 전송할 수 있거나, 또는 고유 시퀀스 식별자는 대역외로(out-of-band) 전송될 수 있다. 따라서, 시퀀스 세션을 확립하는 임의의 잘 알려진 방법이 본 발명에 이용가능하고, 시퀀스 세션이 어떻게 확립되는지에 대한 임의의 특정 참조가 단지 예시를 위해 이용되고, 명시적으로 청구되지 않는 한 본 발명의 범위를 한정하거나 좁게 하기 위한 것으로 의도되지 않는다.

통상적으로, 시퀀스 수신확인들은 대응하는 애플리케이션 메시지들을 수신할 때 전송되어야 한다. 다시 말하면, 시퀀스에 대한 수신확인들을 지연시키고 일괄처리(batching)하기보다는, 예시적인 실시예들은 메시지와 그 수신확인 간에 일대일 대응이 이용되어야 한다는 것, 즉, 메시지들은 요구 흐름(145)을 거쳐서 흐르고, 대응하는 수신확인들은 응답 흐름(140)에서 수신된다는 것을 제공한다. 그러나, 일괄 처리가 또한 본 발명에 이용가능하다는 것을 주목한다. 예를 들어, 최종 메시지 표시를 수신하기 전에 - 또는 심지어 최종 메시지 표시를 수신한 때에 - 일괄 수신확인(batch acknowledgment)이 응답 흐름(140)을 거쳐서 이니시에이터(105)로 전송될 수 있다. 그러나, 전술한 바와 같이, 수신확인들이 즉시 전송되지 않는 경우, 요구-응답 전송 프로토콜의 요건에 따르기 위해 표준 전송-레벨 응답들이 여전히 이니시에이터(105)로 전송되어야 한다.

수신확인의 유형(즉, 일괄 또는 개별)에 관계없이, 수신확인들은 유입(incoming) 접속들의 응답 흐름들(140)에서, 그리고 시퀀스 세션에 대한 응답 흐름들(140s)에서만, 이니시에이터 종단점(105)으로 전송되어야 한다. 그럼에도 불구하고, 이니시에이터 종단점(105)은 이전에 전송된 메시지들에 대한 수신확인 메시지들을 기다리지 않고 새로운 요구-응답 접속에서 메시지들(기반구조 또는 애플리케이션-레벨 메시지들)을 전송할 수 있다. 이니시에이터 종단점(105)은 여러 가지 이유로 수신확인들을 수신하지 않고 메시지들을 전송하기를 원할 수 있다. 예를 들어, 이니시에이터 종단점(105)은 수신확인되지 않은 애플리케이션-레벨 메시지 (135)의 전송을 재시도할 필요가 있을 수 있다. 대안적으로, 또는 결합하여, 이니시에이터 종단점(105)은 억셉터 종단점(110)이 수신확인들을 일괄처리한다는 가정하에서 생성되었던 새로운 메시지들을 전송하기를 원할 수 있다. 또한, 이니시에이터 종단점(105)은 억셉터 종단점(110)으로 기반구조 메시지들을 전송하고, 그 다음에, 예를 들어, 일괄처리되었거나 실패된 전송 응답으로 손실되었을 수 있는 통신 수신확인들에 대한 전송 응답을 이용할 기회를 억셉터 종단점(110)에 제공하는 것을 원할 수 있다.

다른 예시적인 실시예들은, 억셉터 종단점(110)은, 그것이 수신하고 수신확인하지 않는, 애플리케이션 메시지를 드롭할 수 있다는 것을 제공한다. 억셉터 종단점(110)은, 시퀀스가 정렬되어 있고 메시지가 정렬되지 않게(out of order) 수신된 경우, 또는 메시지(예를 들어, 흐름 제어)를 저장하기 위한 버퍼 공간의 부족으로 인해, 또는 임의의 수의 다른 이유로, 이렇게 하는 것을 선택할 수 있다. 그러나, 억셉터 종단점(110)은 전송 프로토콜의 요건들에 따르기 위해 응답 흐름(140)에서 적어도 표준 전송-레벨 응답으로 임의의 이벤트에서 응답해야 한다는 것을 주목한다.

또 다른 예시적인 실시예들은, 익명의 요구-응답 전송 프로토콜을 거쳐서 확립된 단방향 시퀀스를 종료하기 위한 능력을 제공한다. 전술한 시퀀스 세션 생성 처리와 유사하게, 죵료 시퀀스 기반구조 메시지는 접속의 요구 흐름(145)을 거쳐서 전송될 수 있다. 종료 시퀀스 메시지는 기반구조 프로토콜(예를 들어, 헤더 필드로서)에 의해서 또는 기반구조 메시지로서 애플리케이션-레벨 메시지에 링크될 수 있다. 임의의 이벤트에서, 억셉터 종단점(110)은 통상적으로 RM 프로토콜에 따르기 위해 시퀀스 세션에 대해 전송된 최종 메시지(시퀀스 세션에 대해 메시지들 모두가 수신되었다고 가정함)에 대한 시퀀스 수신확인으로 응답해야 한다. 그럼에도 불구하고, 어떠한 이유로도 수신확인 또는 다른 기반구조 메시지가 억셉터(110)에 의해 전송되지 않는 경우, 전송 프로토콜에 따르기 위해 응답 흐름(140)에서의 표준 전송-응답이 적어도 전송되어야 한다.

도 1b는 예시적인 실시예들에 따른 요구-응답 전송 프로토콜에 의한 가능성 있는 RM 프로토콜 메시지 시퀀스 교환의 도면을 예시한다. 도시된 바와 같이, 이니시에이터 종단점(105)은, 요구가, 단방향 시퀀스 세션(102)을 생성하게 하고 그것을 익명의 요구-응답 전송의 요구 흐름에서 전송하게 한다. 이니시에이터 종단점(105)으로부터 억셉터 종단점(110)으로 흐르는 화살표들은 전송 프로토콜의 요구 흐름을 나타내고, 억셉터 종단점(110)으로부터 이니시에이터 종단점(105)으로 순환하는 화살표는 요구-응답 전송의 응답 흐름을 나타낸다는 것을 주목한다. 또한, 단방향 시퀀스 세션을 생성하기 위한 요구(102)는 애플리케이션-레벨 메시지 내에 포함될 수 있다는 것을 주목한다.

단방향 RM 프로토콜 시퀀스 세션을 생성하기 위한 요구(102)에 응답하여, 억셉터 종단점(110)은 전송의 응답 흐름에서 이니시에이터(105)로 다시 전송-레벨 응답(104)을 전송할 것이다. 이 예에 도시된 바와 같이, 이 전송-레벨 응답(104)은 단방향 RM 시퀀스 세션에 대한 시퀀스 식별자(108)와 같은 RM 기반구조 정보를 포함한다. 다시 말하면, 기반구조 정보는 전송-레벨 응답 흐름에서 응답을 전송하기 전에 전송-레벨 응답에 링크된다.

그 후, 이니시에이터 종단점(105)은 요구-응답 전송을 위한 후속 접속들의 요구 흐름에서 애플리케이션-레벨 메시지들(106)을 전송하기 위해 시퀀스 식별자(108)를 이용할 수 있다. 각각의 메시지는 정렬 및 다른 신뢰성 있는 메시징 목적들을 위해 메시지 번호(114)에 의해 식별되어야 한다. 억셉터 종단점(110)이 애플리케이션-레벨 메시지(106)를 수신하면, 억셉터 종단점(110)은 통상적으로 RM 정보(112)를 포함하는 전송-레벨 응답(104)으로 응답할 것이다. 더욱 특정하게는, RM 기반구조 정보(112)는 하나 이상의 애플리케이션-레벨 메시지들에 대한 시퀀스 식별자(108) 및 수신확인(128)을 포함할 수 있다.

전송-레벨 응답(104)은 RM 정보를 포함할 필요가 없지만, 간단하게 표준 전송-레벨 응답일 수 있다는 것을 주목한다. 예를 들어, 후속 교환에 도시된 바와 같이, 시퀀스 식별자(108) 및 최종 메시지(116) 헤더를 포함하는(통상적으로, 도시되지 않은 메시지 번호를 또한 포함함) 애플리케이션-레벨 단방향 메시지(118)가 전송된다. 이니시에이터 종단점(105)이 전송의 요구 흐름을 거쳐서 메시지를 전송한 후에, 이 경우의 억셉터 종단점(110)은 응답 흐름에서 표준 전송-레벨 Null 응답(122)으로 응답한다. 전술한 바와 같이, 이러한 응답들은 요구-응답 전송 프로토콜에 따르기 위해 전송될 수 있다. 그러나, 이 경우, RM 프로토콜에 따르기 위해, 억셉터 종단점(110)은 메시지에 대한 수신확인(128)을 결국 전송해야 한다는 것을 주목한다. 전술한 바와 같이, 어떠한 수신확인들도 소정 시간 한계, 소정의 재시도 횟수, 또는 임의의 다른 재시도-정책 관리 메커니즘 후에 수신되지 않는 경 우, 실패 통지가 애플리케이션 계층에 전달될 수 있다.

최종 메시지에 대한 수신확인이 이니시에이터 종단점(105)에 의해 수신된다고 가정하면, 그 후, 시퀀스 식별자(108)를 포함하는 종료 시퀀스(126)가 요구-응답 전송 프로토콜의 다른 요구 흐름을 통해 전송된다. 마지막으로, 이 예에서, 억셉터 종단점(110)은 다른 전송-레벨 Null 응답(124)으로 응답한다. 이러한 경우, 양쪽은 종료된 시퀀스 세션을 고려할 수 있다. 또한, Null 응답(124)을 전송하기보다는, 억셉터 종단점(110)은 종료 시퀀스 메시지(126)에 대한 수신확인으로 응답하였을 수 있다는 것을 주목한다.

본 발명은 또한 기능 단계들 및/또는 비-기능(non-functional) 작용들을 포함하는 방법에 의하여 설명될 수 있다. 다음은, 본 발명을 실행함에 있어서 수행될 수 있는 단계들 및/또는 작용들에 대한 설명이다. 보통, 기능 단계들은 달성되는 결과들에 관하여 본 발명을 기술하는 반면, 비-기능 작용들은 특정 결과를 달성하기 위한 보다 특정적인 작용들을 기술한다. 비록 기능 단계들 및/또는 비-기능 작용들이 특정 순서로 기술되거나 주장될 수 있지만, 본 발명은 반드시 단계들 및/또는 작용들의 임의의 특정 순서 또는 조합으로 한정될 필요는 없다. 또한, 특허청구범위의 기재에서의 - 및 다음의 도 2의 흐름도에 대한 설명에서의 - 단계들 및/또는 작용들의 이용은, 이러한 관계(terms)의 원하는 특정 이용을 나타내는데 이용된다.

도 2는 본 발명의 다양한 예시적인 실시예들에 대한 흐름도를 예시한다. 도 2에 대한 다음의 설명은 때때로 도 1a 및 도 1b로부터 대응하는 요소들을 가리킬 것이다. 비록 이들 도면들로부터의 특정 요소에 대하여 참조가 이루어질 수 있지만, 이러한 요소들은 단지 예시의 목적으로 이용되고, 명시적으로 청구되지 않는 한 본 발명의 범위를 한정하거나 좁게 하기 위한 것으로 의도되지 않는다.

도 2는 요구-응답 전송 프로토콜에 의해 애플리케이션-레벨 메시지들을 전송할 때 RM 프로토콜을 제공하는 방법(200)의 예시적인 흐름도를 도시한다. 이니시에이터 측에서, 방법(200)은 애플리케이션-레벨 메시지를 생성하는 작용(205)을 포함한다. 예를 들어, 이니시에이터 종단점(105)은 신뢰성 있는 단방향 메시지 교환 패턴으로 억셉터 종단점(110)에 전송하기 위한 애플리케이션-레벨 메시지를 생성할 수 있다. 통상적으로, 이니시에이터 종단점(105)은 어드레스 가능하지 않을 것이고, 즉, 애플리케이션-레벨 메시지(115)는 통상적으로 억셉터 종단점(110)으로부터 이니시에이터 종단점(105)으로 되돌아가는 애플리케이션 레벨 출력(160) 정보 없이, 억셉터 종단점(110)에서 처리하기 위한 입력 정보를 포함할 것이다. 물론, 전술한 바와 같이, 기반구조 메시지들(예를 들어, 수신확인 요구, 생성 시퀀스, 종료 시퀀스 등)은 또한 애플리케이션-레벨 메시지(115)에 링크될 수 있다.

그러나, 통상적으로 시퀀스 세션의 개시를 요구하는 기반구조 메시지(뿐만 아니라 종료 기반구조 메시지)는 애플리케이션-레벨 메시지들에 링크되지 않는다는 것을 주목한다. 사실상, 보통, 생성 시퀀스 세션은, 예를 들어, 애플리케이션 계층(115)으로부터의 CreateSession 또는 SessionOpen과 같은 로컬 API 호출에 응답하여 RM 계층(120)에 의해 생성된다. 따라서, 전술한 바와 같이, 시퀀스 세션을 확립 또는 개시(및/또는 시퀀스 세션의 종료)하기 위한 임의의 특정 처리는 단지 예시를 위해 이용되고, 명시적으로 청구되지 않는 한 본 발명의 범위를 한정하거나 좁게 하지 않는 것으로 의도된다.

기반구조 정보가 애플리케이션-레벨 메시지와 링크되는지에 관계없이, 방법(200)은 또한 RM 프로토콜에 따라 애플리케이션-레벨 메시지를 포맷팅하는 작용(210)을 포함한다. 예를 들어, 이니시에이터 종단점(105)에서의 신뢰성 있는 메시징 레벨(120)은 애플리케이션-레벨 메시지를 포맷팅할 수 있고, 재도전 목적을 위해 이니시에이터 버퍼(130)에 애플리케이션-레벨 메시지(135)의 사본을 저장할 수 있다. 다음으로, 방법(200)은 전송 요구 흐름을 통해 애플리케이션-레벨 메시지를 전송하는 작용(215)을 포함한다. 즉, 예를 들어, 그 메시지는 신뢰성 있는 메시징 계층(120)으로부터 요구-응답 전송 계층(125)으로 하향 전달된다. 그 메시지는 그 다음에 억셉터 종단점(110)으로 요구 흐름(145)에서 전송된다. 요구-응답 전송 프로토콜은 익명의 전송, 예를 들어, 익명의 HTTP 또는 다른 유사한 요구-응답 전송 프로토콜일 수 있다.

임의의 이벤트에서, 억셉터 측에서, 방법(200)은 요구 흐름을 통해 애플리케이션-레벨 메시지를 수신하는 작용(225)을 더 포함한다. 예를 들어, 억셉터 종단점(110)은 요구-응답 전송 계층(156)에서 요구 흐름(145)을 통해 애플리케이션-레벨 메시지를 수신할 수 있다. 그 후, 방법(200)은 애플리케이션-레벨 메시지가 RM 프로토콜에 따라 포맷팅되어 있다는 것을 식별하는 작용(230)을 또한 포함한다. 또한, 방법(200)은 전송-레벨 응답에 RM 프로토콜 기반구조 정보를 링크하는 작용(235)을 포함한다. 예를 들어, 신뢰성 있는 메시징 계층(155)은 억셉터 종단점 (110)의 애플리케이션 계층(160)에 의한 후속 처리를 위해 억셉터 버퍼(165)에 애플리케이션-레벨 메시지(170)를 저장할 수 있다. 그 후, 신뢰성 있는 메시징 계층(155)은 이니시에이터(105)로부터 억셉터(110)로 전송된 하나 이상의 애플리케이션-레벨 메시지들의 신뢰성 있는 교환에 대응하는 RM 기반구조 정보(112)에 전송-레벨 응답을 링크할 수 있다.

전송-레벨 응답에 링크된 기반구조 정보는, 억셉터가 하나 이상의 애플리케이션-레벨 메시지들을 신뢰성 있게 수신하였음을 나타내는 수신확인 응답일 수 있다. 수신확인 응답은 요구 흐름에서 전송된 애플리케이션-레벨 메시지에 대한 수신확인 응답을 포함할 수 있다. 또한, 포맷팅된 애플리케이션-레벨 메시지는 RM 프로토콜에 따라 수신확인 요구에 링크될 수 있다. 이러한 경우, 수신확인 응답은 수신확인 요구에 대한 응답이다. 대안적으로, RM 정보는, 애플리케이션-레벨 메시지가 단방향 시퀀스 세션을 생성하기 위한 요구에 링크되는 경우의 시퀀스 식별자(108)일 수 있다.

전송-레벨 응답을 포맷팅한 후, 방법(200)은 응답 흐름을 통해 전송-레벨 응답을 전송하는 작용(240)을 포함한다. 마찬가지로, 이니시에이터 측에서, 방법(200)은 응답 흐름을 통해 대응하는 전송-레벨 응답을 수신하는 작용(220)을 또한 포함한다. 예를 들어, 억셉터 종단점(110)은 응답 흐름(140)을 통해 전송-레벨 응답 예를 들어, 104, 114를 전송하고, 전송-레벨 응답은 그 다음에 이니시에이터 종단점(105)에서 수신된다. RM 또는 기반구조-레벨 응답은 그 다음에 전송-레벨 응답으로부터 추출되고 RM 계층(120)으로 제공된다. RM 계층(120)은 그 다음에 이니 시에이터 버퍼(130)로부터 메시지(135)의 사본을 삭제한다.

다른 예시적인 실시예들은, 애플리케이션-레벨 메시지를 전송하기 전에, 고유 시퀀스 식별자에 의해 식별된 단방향 시퀀스 세션이 이니시에이터(105)와 억셉터(110) 간에 확립된다는 것을 제공한다. 따라서, 애플리케이션-레벨 메시지는 고유 시퀀스 식별자를 포함할 것이다. 그 후, 고유 시퀀스 식별자를 포함하는 후속 메시지가 RM 프로토콜에 따라 포맷팅되고 요구-응답 전송의 요구 흐름(145)을 통해 전송될 수 있다. 이러한 후속 메시지는 원래의 애플리케이션-레벨 메시지에 대응하는 수신확인 응답을 수신하기 전에 전송될 수 있다. 그 후, 후속 전송-레벨 응답이 요구-응답 전송의 응답 흐름(140)을 통해 이니시에이터(105)에서 수신된다.

또 다른 실시예들은, 후속 메시지가 이니시에이터 종단점으로 되돌아가는 애플리케이션-레벨 출력 정보 없이 억셉터 종단점(110)에서 처리하기 위한 입력 정보를 포함하는 애플리케이션-레벨 메시지인 것을 제공한다. 이 실시예에서, 후속 전송-레벨 응답은 RM 프로토콜 기반구조 정보(112)에 링크될 수 있고, 이것은 억셉터 종단점(110)이 적어도 후속 애플리케이션-레벨 메시지를 수신하였음을 나타내는 수신확인 응답(128)을 포함한다.

후속 메시지가 종료 시퀀스 요소(126)를 포함하는 RM 프로토콜 기반구조 메시지인 경우에, 후속 전송 레벨 응답은 요구-응답 전송 프로토콜 예를 들어, Null 응답(124)에 따르기 위해 전송될 수 있다. 대안적으로, 전송-레벨 응답은 RM 프로토콜 기반구조 정보를 포함할 수 있고, 이것은 억셉터(110)가 시퀀스 세션에서 최종 애플리케이션-레벨 메시지를 수신하였음을 나타내는 수신확인 응답(128)이다.

또 다른 실시예는, 전송 프로토콜이 HTTP일 수 있고, 여기서, 후속 전송-레벨 응답은 요구-응답 전송 프로토콜에 따르기 위해 전송된 HTTP 메시지(예를 들어, 202 OK 메시지)임을 제공한다. 또 다른 예시적인 실시예들은, 다른 애플리케이션-레벨 메시지가 후속 세션을 위해 수신되지만, 정렬되지 않게 도달하고, 억셉터 종단점은 수신확인을 드롭하고 전송하지 않지만, 전송-레벨 응답이 요구-응답 전송 프로토콜에 따르기 위해 전송된다는 것을 제공한다.

본 발명의 범위 내의 실시예들은 또한, 거기에 저장된 컴퓨터 실행가능한 명령들 또는 데이터 구조들을 실행하거나 갖는 컴퓨터 판독가능한 매체를 포함한다. 이러한 컴퓨터 판독가능한 매체는 범용 또는 특수 목적 컴퓨터에 의해 액세스될 수 있는 임의의 이용가능한 매체일 수 있다. 예시적으로, 이러한 컴퓨터 판독가능한 매체는 RAM, ROM, EEPROM, CD-ROM 또는 기타 광학 디스크 저장장치, 자기 디스크 저장장치 또는 기타 자기 저장장치, 또는 범용이거나 특수 목적 컴퓨터에 의해 액세스될 수 있고 컴퓨터 실행가능한 명령들 또는 데이터 구조들의 형태로 원하는 프로그램 코드 수단을 실행 또는 저장하는데 이용될 수 있는 임의의 기타 매체를 포함할 수 있으며, 이에 한정되지 않는다. 정보가 네트워크 또는 다른 통신 접속(유선(hardwired), 무선 또는 유선 또는 무선의 조합)을 통해 컴퓨터에 전송되거나 제공되는 경우에, 컴퓨터는 그 접속을 적절하게 컴퓨터 판독가능한 매체로서 본다. 따라서, 임의의 이러한 접속은 적절하게 컴퓨터 판독가능한 매체라고 불린다. 상기한 것의 조합들은 또한 컴퓨터 판독가능한 매체의 범위 내에 포함되어야 한다. 컴퓨터 실행가능한 명령들은, 예를 들어, 범용 컴퓨터, 특수 목적 컴퓨터, 또는 특 수 목적 처리 장치로 하여금, 소정 기능 또는 기능군을 수행하게 하는 명령들 및 데이터를 포함한다.

도 3 및 다음의 설명은, 본 발명이 구현될 수 있는 적절한 컴퓨팅 환경의 간단한 일반적인 설명을 제공하기 위한 것으로 의도된다. 비록 요구되지 않지만, 본 발명은 네트워크 환경들의 컴퓨터들에 의해 실행되는 프로그램 모듈들과 같은 컴퓨터-실행가능한 명령들의 일반적인 문맥(context)에서 설명될 것이다. 일반적으로, 프로그램 모듈은 특정 태스크를 수행하거나 특정 추상 데이터 유형을 구현하는 루틴, 프로그램, 오브젝트, 컴포넌트, 데이터 구조 등을 포함한다. 컴퓨터 실행가능한 명령들, 연관된 데이터 구조들, 및 프로그램 모듈들은 본원에 개시된 방법의 단계들을 실행하기 위한 프로그램 코드 수단의 예들을 나타낸다. 이러한 실행가능한 명령들의 특정 시퀀스 또는 연관된 데이터 구조들은 이러한 단계들로 설명된 기능들을 구현하기 위한 대응하는 작용들의 예들을 나타낸다.

이 기술분야의 당업자들은, 본 발명이 개인용 컴퓨터, 핸드-헬드(hand-held) 장치, 멀티프로세서 시스템, 마이크로프로세서-기반 또는 프로그램가능한 가전제품(programmable consumer electronics), 네트워크 PC, 미니컴퓨터, 메인프레임 컴퓨터 등을 포함하는 많은 유형의 컴퓨터 시스템 구성과 함께 네트워크 컴퓨팅 환경에서 실행될 수 있다는 것을 알 것이다. 본 발명은 또한 통신 네트워크를 통해 (유선 링크, 무선 링크, 또는 유선 또는 무선 링크의 조합에 의해) 링크되는 로컬 및 원격 프로세싱 장치들에 의해 태스크들이 수행되는 분산형 컴퓨팅 환경들에서 실행될 수 있다. 분산형 컴퓨팅 환경에서, 프로그램 모듈은 로컬 및 원격 메모리 저장 장치들 모두에 위치시킬 수 있다.

도 3을 참조하면, 본 발명을 구현하기 위한 예시적인 시스템은, 프로세싱 유닛(321), 시스템 메모리(322), 및 시스템 메모리(322)를 포함하는 다양한 시스템 컴포넌트를 프로세싱 유닛(321)에 연결하는 시스템 버스(323)를 포함하는 통상적인 컴퓨터(320)의 형태의 범용 컴퓨팅 장치를 포함한다. 시스템 버스(323)는 다양한 버스 아키텍처 중의 임의의 것을 사용하는 로컬 버스, 주변 버스, 및 메모리 버스 또는 메모리 컨트롤러를 포함하는 몇 가지 유형의 버스 구조 중의 임의의 것일 수 있다. 시스템 메모리는 ROM(read only memory)(324) 및 RAM(random access memory)(325)을 포함한다. 시동중과 같은 때에 컴퓨터(320) 내의 구성요소들 간에 정보를 전송하는 것을 돕는 기본 루틴을 포함하는 BIOS(basic input/output system)(326)은 ROM(324)에 저장될 수 있다.

컴퓨터(110)는 또한 자기 하드 디스크(339)로부터 판독하거나 그 자기 하드 디스크(339)에 기록하는 자기 하드 디스크 드라이브(327), 분리형 자기 디스크(329)로부터 판독하거나 그 분리형 자기 디스크(329)에 기록하는 자기 디스크 드라이브(328), 및 CD-ROM 또는 기타 광학 매체 등의 분리형 광학 디스크(331)로부터 판독하거나 그 분리형 광학 디스크(331)에 기록하는 광학 디스크 드라이브(330)를 포함할 수 있다. 자기 하드 디스크 드라이브(327), 자기 디스크 드라이브(328) 및 광학 디스크 드라이브(330)는 하드 디스크 드라이브 인터페이스(332), 자기 디스크 드라이브 인터페이스(333) 및 광학 드라이브 인터페이스(334)에 의해 각각 시스템 버스(323)에 접속된다. 드라이브 및 연관된 컴퓨터 판독가능한 매체는 컴퓨터 실 행가능한 명령들, 데이터 구조들, 프로그램 모듈들 및 컴퓨터(320)를 위한 다른 데이터의 비휘발성 저장장치를 제공한다. 비록 본원에 기재된 예시적인 환경은 자기 하드 디스크(339), 분리형 자기 디스크(329) 및 분리형 광학 디스크(331)를 이용하고 있지만, 자기 카세트, 플래시 메모리 카드, DVD(digital versatile disk),베르누이(Bernoulli) 카트리지, RAM, ROM 등을 포함하는, 정보를 저장하기 위한 다른 유형의 컴퓨터 판독가능한 매체가 이용될 수 있다.

하나 이상의 프로그램 모듈들을 포함하는 프로그램 코드 수단은, 운영 체계(335), 하나 이상의 애플리케이션 프로그램(336), 기타 프로그램 모듈들(337), 및 프로그램 데이터(338)를 포함하는, 하드 디스크(339), 자기 디스크(329) 및 광학 디스크(331), ROM(324) 또는 RAM(325)에 저장될 수 있다. 사용자는 키보드(340), 포인팅 장치(pointing device)(342), 또는 마이크로폰, 조이스틱, 게임 패드, 위성 안테나, 스캐너 등과 같은 다른 입력 장치들(도시되지 않음)을 통해 컴퓨터(320)에 커맨드(command) 및 정보를 입력할 수 있다. 이들 입력 장치 및 그외의 입력 장치는 시스템 버스(323)에 연결된 시리얼 포트 인터페이스(346)를 통해 종종 프로세싱 유닛(321)에 접속된다. 대안적으로, 입력 장치들은 병렬 포트, 게임 포트 또는 USB(universal serial bus)와 같은 기타 인터페이스들에 의해 접속될 수 있다. 모니터(347) 또는 다른 유형의 디스플레이 장치는 또한 비디오 어댑터(348) 등의 인터페이스를 통해 시스템 버스(323)에 접속된다. 모니터 외에도, 개인용 컴퓨터들은 통상적으로 스피커 및 프린터 등의 기타 주변 출력 장치들(도시되지 않음)을 포함한다.

컴퓨터(320)는, 원격 컴퓨터들(349a 및 349b)과 같은 하나 이상의 원격 컴퓨터들과의 논리적 접속을 이용한 네트워크 환경에서 동작할 수 있다. 원격 컴퓨터들(349a 및 349b)은 각각 다른 개인용 컴퓨터, 서버, 라우터, 네트워크 PC, 피어(peer) 장치, 또는 기타 공통 네트워크 노드일 수 있으며, 비록 도 3에는 메모리 저장 장치들(350a 및 350b) 및 그의 연관된 애플리케이션 프로그램들(336a 및 336b)만이 도시되어 있지만, 컴퓨터(320)에 관하여 전술한 구성요소들 중 다수 또는 모든 구성요소를 통상적으로 포함한다. 도 3에 도시된 논리적 접속들은 LAN(local area network)(351) 및 WAN(wide area network)(352)을 포함하지만, 이것으로 한정하는 것이 아니라 예시를 위해 본원에 도시한 것이다. 이러한 네트워크 환경은 사무실, 기업 광역 컴퓨터 네트워크(enterprise-wide computer network), 인트라넷, 및 인터넷에서 일반적인 것이다.

LAN 네트워크 환경에서 사용되는 경우, 컴퓨터(320)는 네트워크 인터페이스 또는 어댑터(353)를 통해 LAN(351)에 접속된다. WAN 네트워크 환경에서 사용되는 경우, 컴퓨터(320)는 모뎀(354), 무선 링크, 또는 인터넷 등의 WAN(352)을 통해 통신을 확립하기 위한 기타 수단을 포함할 수 있다. 내장형 또는 외장형일 수 있는 모뎀(354)은 시리얼 포트 인터페이스(346)를 통해 시스템 버스(323)에 접속된다. 네트워크 환경에서, 컴퓨터(320)에 관하여 도시된 프로그램 모듈들, 또는 그 일부분은 원격 메모리 저장 장치에 저장될 수 있다. 도시된 네트워크 접속은 예시적인 것이며, WAN(352)을 통해 통신을 확립하는 그 외의 수단이 사용될 수 있다는 것을 알 수 있을 것이다.

본 발명은 그 기술 사상 또는 필수적인 특징으로부터 벗어남이 없이 다른 특정 형태로 구현될 수 있다. 전술한 실시예들은 모든 면에서 한정적인 것이 아니라 예시적인 것으로서 고려되어야 한다. 따라서, 본 발명의 범위는 전술한 설명에 의해서라기보다는 첨부된 특허청구범위에 의해 정의된다. 특허청구범위의 등가의 의미 및 범위 내에 있는 모든 변형들은 본 발명의 범위 내에 포함된다.

본 발명은, 새로운 기반구조 서비스들의 재구성 또는 배치 없이 요구-응답 전송 프로토콜의 기존 네트워크 특성을 이용함으로써 요구-응답 전송 프로토콜을 통해 애플리케이션-레벨 메시지들을 전송하는 경우에 분산형 시스템을 위한 신뢰성 있는 메시징 프로토콜(RM 프로토콜)을 제공할 수 있다.

Claims

새로운 기반구조 서비스들의 재구성 또는 배치 없이 요구-응답 전송 프로토콜(request-response transport protocol)의 기존 네트워크 특성을 활용(leveraging)함으로써 요구-응답 전송 프로토콜을 통해 애플리케이션-레벨(application-level) 메시지들을 전송하는 경우에 분산형 시스템을 위한 신뢰성 있는 메시징(Reliable Messaging) 프로토콜(RM 프로토콜)을 제공하는 방법으로서, 상기 방법은 분산형 시스템의 이니시에이터(initiator) 컴퓨팅 장치에 의해 수행되며,

상기 방법은,

신뢰성 있는 단방향 메시지 교환 패턴으로 억셉터(acceptor) 종단점에 애플리케이션-레벨 메시지를 전송하기 위하여 이니시에이터 종단점(endpoint)에서 애플리케이션-레벨 메시지를 생성하는 단계;

분산형 시스템을 위한 신뢰성 있는 메시징 프로토콜(RM 프로토콜)에 따라 상기 애플리케이션-레벨 메시지를 포맷팅하는 단계;

요구-응답 전송의 요구 흐름(request flow)을 통해 상기 애플리케이션-레벨 메시지를 전송하는 단계; 및

상기 요구-응답 전송의 응답 흐름(reply flow)을 통해 대응하는 전송-레벨(transport-level) 응답을 수신하는 단계 - 상기 전송-레벨 응답은 상기 RM 프로토콜에 따르기 위해 RM 프로토콜 기반구조 정보에 링크됨 -

를 포함하는, 메시징 프로토콜 제공 방법.
제1항에 있어서,

상기 전송-레벨 응답에 링크된 상기 기반구조 정보는, 상기 억셉터가 하나 이상의 애플리케이션-레벨 메시지를 수신하였음을 나타내는 수신확인 응답(acknowledgment response)인, 메시징 프로토콜 제공 방법.
제2항에 있어서,

상기 수신확인 응답은 상기 요구 흐름에서 전송된 상기 애플리케이션-레벨 메시지에 대한 수신확인 응답을 포함하는, 메시징 프로토콜 제공 방법.
제1항에 있어서,

상기 애플리케이션-레벨 메시지를 전송하기 전에, 고유 시퀀스 식별자(unique sequence identifier)에 의해 식별된 단방향 시퀀스 세션이 상기 이니시에이터와 상기 억셉터 간에 확립되고, 상기 애플리케이션-레벨 메시지는 상기 고유 시퀀스 식별자를 포함하는, 메시징 프로토콜 제공 방법.
제4항에 있어서,

상기 RM 프로토콜에 따라 후속 메시지를 포맷팅하는 단계 - 상기 후속 메시지는 상기 고유 시퀀스 식별자를 포함함 -; 및

요구-응답 전송의 요구 흐름을 통해 상기 후속 메시지를 전송하는 단계

를 더 포함하는, 메시징 프로토콜 제공 방법.
새로운 기반구조 서비스들의 재구성 또는 배치 없이 요구-응답 전송 프로토콜의 기존 네트워크 특성을 활용함으로써 요구-응답 전송 프로토콜을 통해 애플리케이션-레벨 메시지들을 전송하는 경우에 분산형 시스템을 위한 신뢰성 있는 메시징 프로토콜(RM 프로토콜)을 제공하는 방법으로서, 상기 방법은 분산형 시스템의 억셉터 컴퓨팅 장치에 의해 수행되며,

상기 방법은,

요구-응답 전송 프로토콜의 요구 흐름을 통해 수신되는 애플리케이션-레벨 메시지를 신뢰성 있는 단방향 메시지 교환 패턴으로 이니시에이터로부터 억셉터로 수신하는 단계;

상기 애플리케이션-레벨 메시지는 분산형 시스템을 위한 신뢰성 있는 메시징 프로토콜(RM 프로토콜)에 따라 포맷팅되어 있다고 식별하는 단계;

RM 프로토콜 기반구조 정보를 전송-레벨 응답에 링크하는 단계 - 상기 기반구조 정보는 상기 이니시에이터로부터 상기 억셉터로 전송되는 하나 이상의 애플리케이션-레벨 메시지의 신뢰성 있는 교환에 대응함 -; 및

상기 RM 프로토콜에 따르기 위해 상기 요구-응답 전송 프로토콜의 응답 흐름을 통해 상기 전송-레벨 응답을 전송하는 단계

를 포함하는, 메시징 프로토콜 제공 방법.
제6항에 있어서,

상기 전송-레벨 응답에 링크된 상기 기반구조 정보는, 상기 억셉터가 하나 이상의 애플리케이션-레벨 메시지를 수신하였음을 나타내는 수신확인 응답인, 메시징 프로토콜 제공 방법.
제6항에 있어서,

상기 애플리케이션-레벨 메시지를 수신하기 전에, 고유 시퀀스 식별자에 의해 식별된 단방향 시퀀스 세션이 상기 이니시에이터와 상기 억셉터 간에 확립되고, 상기 애플리케이션-레벨 메시지는 상기 고유 시퀀스 식별자를 포함하는, 메시징 프로토콜 제공 방법.
제8항에 있어서,

요구-응답 전송의 요구 흐름을 통해 상기 고유 시퀀스 식별자를 포함하는 후속 메시지를 수신하는 단계; 및

상기 후속 메시지는 상기 RM 프로토콜에 따라 포맷팅되어 있다고 식별하는 단계

를 더 포함하는, 메시징 프로토콜 제공 방법.
분산형 시스템의 이니시에이터 컴퓨팅 장치에서, 새로운 기반구조 서비스들의 재구성 또는 배치 없이 요구-응답 전송 프로토콜의 기존 네트워크 특성을 활용함으로써 요구-응답 전송 프로토콜을 통해 애플리케이션-레벨 메시지들을 전송하는 경우에 분산형 시스템을 위한 신뢰성 있는 메시징 프로토콜(RM 프로토콜)을 제공하는 방법을 구현하기 위한 컴퓨터 프로그램이 인코딩된 컴퓨터 판독가능 기록 매체로서,

상기 컴퓨터 판독가능 기록 매체는, 프로세서에 의해 실행될 때, 상기 분산형 컴퓨팅 시스템으로 하여금,

신뢰성 있는 단방향 메시지 교환 패턴으로 억셉터 종단점에 애플리케이션-레벨 메시지를 전송하기 위하여 이니시에이터 종단점에서 애플리케이션-레벨 메시지를 생성하는 단계;

분산형 시스템을 위한 신뢰성 있는 메시징 프로토콜(RM 프로토콜)에 따라 상기 애플리케이션-레벨 메시지를 포맷팅하는 단계;

요구-응답 전송의 요구 흐름을 통해 상기 애플리케이션-레벨 메시지를 전송하는 단계; 및

상기 요구-응답 전송의 응답 흐름을 통해 대응하는 전송-레벨 응답을 수신하는 단계 - 상기 전송-레벨 응답은 상기 RM 프로토콜에 따르기 위해 RM 프로토콜 기반구조 정보에 링크됨 -

를 수행하게 할 수 있는 컴퓨터 실행 가능한 명령어들이 저장되어 있는 컴퓨터 판독가능 기록 매체.
제10항에 있어서,

상기 애플리케이션-레벨 메시지를 전송하기 전에, 고유 시퀀스 식별자에 의해 식별된 단방향 시퀀스 세션이 상기 이니시에이터와 상기 억셉터 간에 확립되고, 상기 애플리케이션-레벨 메시지는 상기 고유 시퀀스 식별자를 포함하는 컴퓨터 판독가능 기록 매체.
제10항에 있어서,

상기 전송-레벨 응답은 상기 요구-응답 전송 프로토콜에 따르기 위해 수신되는 컴퓨터 판독가능 기록 매체.
제10항에 있어서,

상기 전송-레벨 응답에 링크된 상기 기반구조 정보는, 상기 억셉터가 하나 이상의 애플리케이션-레벨 메시지들을 수신하였음을 나타내는 수신확인 응답인 컴퓨터 판독가능 기록 매체.
분산형 시스템의 억셉터 컴퓨팅 장치에서, 새로운 기반구조 서비스들의 재구성 또는 배치 없이 요구-응답 전송 프로토콜의 기존 네트워크 특성을 활용함으로써 요구-응답 전송 프로토콜을 통해 애플리케이션-레벨 메시지들을 전송하는 경우에 분산형 시스템을 위한 신뢰성 있는 메시징 프로토콜(RM 프로토콜)을 제공하는 방법을 구현하기 위한 컴퓨터 프로그램이 인코딩된 컴퓨터 판독가능 기록 매체로서,

상기 컴퓨터 판독가능 기록 매체는, 프로세서에 의해 실행될 때, 상기 분산형 컴퓨팅 시스템으로 하여금,

요구-응답 전송 프로토콜의 요구 흐름을 통해 수신되는 애플리케이션-레벨 메시지를 신뢰성 있는 단방향 메시지 교환 패턴으로 이니시에이터로부터 억셉터로 수신하는 단계;

상기 애플리케이션-레벨 메시지는 분산형 시스템을 위한 신뢰성 있는 메시징 프로토콜(RM 프로토콜)에 따라 포맷팅되어 있다고 식별하는 단계;

RM 프로토콜 기반구조 정보를 전송-레벨 응답에 링크하는 단계 - 상기 기반구조 정보는 상기 이니시에이터로부터 상기 억셉터로 전송되는 하나 이상의 애플리케이션-레벨 메시지들의 신뢰성 있는 교환에 대응함 -; 및

상기 RM 프로토콜에 따르기 위해 상기 요구-응답 전송 프로토콜의 응답 흐름을 통해 상기 전송-레벨 응답을 전송하는 단계

를 수행하게 할 수 있는 컴퓨터 실행 가능한 명령어들이 저장되어 있는 컴퓨터 판독가능 기록 매체.
제14항에 있어서,

상기 애플리케이션-레벨 메시지를 수신하기 전에, 고유 시퀀스 식별자에 의해 식별된 단방향 시퀀스 세션이 상기 이니시에이터와 상기 억셉터 간에 확립되고, 상기 애플리케이션-레벨 메시지는 상기 고유 시퀀스 식별자를 포함하는 컴퓨터 판독가능 기록 매체.
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제