KR101076910B1 - 객체 지향 언어로의 병행 프로그램 구현 - Google Patents

Abstract

본 발명은 주류 객체 지향 언어에 병행성의 지원을 추가한다. 프로그램을 재코딩하지 않고서 하나의 주소 공간에서 실행되거나, 단일 컴퓨터 상에서 몇몇 프로세스에 걸쳐 분산되거나, 또는 근거리 통신망이나 광역 통신망을 거쳐 분산될 수 있는 프로그램 개발을 가능하게 할 수 있는 언어 확장이 제공된다. 이러한 양상의 중심을 이루는 것은 서비스의 개념으로서, 그것은 자신의 알고리즘적 (논리적) 스레드를 실행할 수 있다. 서비스는 메모리를 공유하거나 명시적인 동기화 프리미티브를 사용하여 동기화하지 않는다. 오히려, 데이터 공유 및 동기화 둘다 메시지 전달을 통해 달성되는데, 예를 들어, 일련의 명시적으로 선언된 메시지들이 서비스들간에 전송된다. 메시지는 공유되는 데이터를 포함할 수 있고, 메시지 교환의 패턴은 필수적인 동기화를 제공할 수 있다.

객체 지향 프로그래밍, 서비스, 스레드, 병행성, 병렬성

Description

객체 지향 언어로의 병행 프로그램 구현{IMPLEMENTATION OF CONCURRENT PROGRAMS IN OBJECT-ORIENTED LANGUAGES}

도 1은 본 발명의 양상에 따른 통합 시스템의 일반적인 컴포넌트 블록도.

도 2는 본 발명의 양상에 따른 객체 지향 환경에서의 메시지 전달을 용이하게 하는 절차의 흐름도.

도 3은 본 발명의 양상에 따른 계약 컴포넌트의 일반적인 컴포넌트 블록도.

도 4는 개시된 발명의 양상에 따른 계약의 선언을 용이하게 하는 절차의 흐름도.

도 5는 개시된 발명의 양상에 따른 계약 확장을 용이하게 하는 절차의 흐름도.

도 6은 본 발명의 양상에 따른 통합 컴포넌트의 일반적인 컴포넌트 블록도.

도 7은 개시된 아키텍처를 실행하기 위해 동작가능한 컴퓨터의 블록도.

도 8은 본 발명에 따른 예시적인 컴퓨팅 환경의 개략 블록도.

부록 A는 Stuck-Free Conformance(스턱-프리 적합성)이라는 제목의 논문이다. 이 부록은 본 명세서의 일부를 구성한다.

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

102: 클라이언트

104: 계약 컴포넌트

106: 통합 컴포넌트

108: 서비스

본 발명은 일반적으로 컴퓨터 시스템에 관한 것이다. 보다 상세하게는, 본 발명은 메시지 전달(message passing), 계약(contract) 및 통합(orchestration)을 통한 비동기 프로그래밍을 지원하기 위해 객체 지향 환경에서 언어 확장(language extension)을 이용할 수 있는 시스템 및 방법에 관한 것이다.

대부분의 전문 개발자들은 병행 애플리케이션을 프로그래밍하는 것이 어렵고 오류가 많은 것으로 생각하고 있다. 대부분의 시스템 개발자는 이러한 유형의 프로그래밍과 씨름하고 있으며, 이것은 병행 애플리케이션이 대부분의 비지니스 애플리케이션 개발자들의 손에 닿지 않는 한 이유이다.

병행 알고리즘이 항상 적절한 것은 아니지만, 적합한 문제를 해결하는 데 사용되는 경우에 성능 및 알고리즘 단순성의 관점에서 엄청난 이점을 제공한다. 광역 통신망을 통해 배포되는 프로그램을 개발하는 것에 대한 관심이 증가하면서, 통신 대기 시간(communication latency)이 급격히 늘어나고 순차 실행(sequential execution)의 비용이 급등함에 따라 병행 프로그래밍 툴의 필요성이 증가하고 있다.

그렇지만, 한가지 문제점은 대부분의 프로그래머에게 가용한 병행성을 위한 설비가 저수준이고 사용하기 복잡하다는 것이다. 병행성에 대한 어떤 종류의 지원이라도 제공하는 프로그래밍 언어가 거의 없다. 종래에는, 병행성에 대한 지원을 제공하는 프로그래밍 언어는 특수 목적 언어, 또는 소규모 학문 공동체 내에서만 사용되는 언어이다.

J2EE 및 .NET 브랜드 환경 등의 객체 지향(object-oriented, OO) 프레임워크는 프로그램 설계 주류에 OO 접근을 하였다. 그러나, 그것의 초점이 공유 메모리에 있기 때문에, 그 프레임워크는 병행성을 위해 복잡한 지원을 해야만 하고, 그 지원은 애플리케이션 프로그래밍보다는 시스템 프로그래밍에 더 적합한 것이다. 공유 메모리가 병행성에 대한 간단한 지원에 주요 장애물 중의 하나임을 널리 알려진 바이다.

따라서, 본 분야에서 주류 OO 언어에 병행성에 대한 지원을 추가하는 것과 공존을 구현하는 것에 대한 상당한 필요성이 존재한다. 또한, 하나의 주소 공간에서 실행되거나, 단일 컴퓨터 상에서 몇몇 프로세스에 걸쳐 분산되거나, 또는 근거리 통신망이나 광역 통신망을 거쳐 분산될 수 있는 프로그램(이들 모두 프로그램을 재코딩하지 않음)이 개발될 수 있게 하는 시스템 및/또는 방법이 여전히 필요하다. 이러한 양상의 중심을 이루는 것은 "서비스"의 개념으로서, 그것은 자신의 알고리즘적 (논리적) 스레드를 실행한다. 게다가, 서비스들 간의 메시지 기반 인터페이스를 지정하는 수단도 여전히 필요하다. 즉, 애플리케이션 프로그래밍을 단순화하 기 위해 OO 언어 및 메시지 지향 언어를 통합할 필요가 있다.

메시지 전달을 갖는 종래의 서비스는 특정 하드웨어 프로세서에서만 동작가능하도록 설계된 것으로서 1980년대에 개발된 특수 목적 언어인 OCCAM에 의해 정의된다. 프로그래밍 언어에 내장된 정식 프로그램 규격은 새로운 것이 아니다. 예를 들어, Eiffel은 프로그래밍 언어 자체에서 직접 제한된 형태의 프로그램 규격 지원을 제공한다. Eiffel은 Bertrand Meyer에 의해 창안되고 그의 회사인 Interactive Software Engineering(ISE)에 의해 개발된 진보된 프로그래밍 언어이다.

그러나, 프로토콜 규격과 구현의 분리가 현재 가용하지 않다. 서비스들의 상호 간의 상호작용을 추상화하기 위한 기능에 이 분리가 극히 중요하다. 예를 들어, BizTalk의 바탕이 되는 언어인 XLANG는 전체 서비스 메시지-교환 패턴을 프로토콜로서 노출한다. 그러나, 이 구현은 인터페이스와 분리되어 있지 않으며, 이는 계약 적합성의 정적 확인(static verification of contract conformance)을 어렵게 만든다.

이하는 본 발명의 소정 양상들에 대한 기본적인 이해를 제공하기 위해 본 발명의 단순화된 요약을 제공한다. 이 요약은 본 발명의 전반적인 개요는 아니다. 이 요약은 본 발명의 중요한/결정적인 구성요소들을 식별하거나 본 발명의 범위를 서술하기 위한 것이 아니다. 이 요약의 유일한 목적은 이후에 제공되는 보다 상세한 설명에 대한 도입부로서 본 발명의 소정 개념들을 단순화된 형태로 제공하는 것이다.

본 명세서에 개시되고 청구된 본 발명은 그의 한 양상에서 주류 객체 지향(OO) 언어에서 직접 병행성의 고수준 추상화를 제공한다. 본 발명은 다수의 서비스들 간의 통신을 동시에 관리하기 위한 메커니즘(예를 들어, 통합(orchestration))을 이용하는 비동기 메시지 전달의 도입을 통해 올바른 병행 프로그램을 작성하는 일이 간단하도록 하기 위한 병행성 모델을 제공한다.

한 양상에서, 본 발명은 주류 객체 지향 언어에 병행성에 대한 지원을 추가한다. 프로그램을 재코딩하지 않고 하나의 주소 공간에서 실행되거나, 단일 컴퓨터 상에서 몇몇 프로세스에 걸쳐 분산되거나, 또는 근거리 통신망이나 광역 통신망을 거쳐 분산될 수 있는 프로그램이 개발될 수 있게 할 수 있는 언어 확장이 제공된다. 이러한 양상의 중심을 이루는 것은 "서비스"의 개념으로서, 그것은 자신의 알고리즘적 (논리적) 스레드를 실행할 수 있다. 따라서, 서비스는 메모리를 공유하거나 명시적인 동기화 프리미티브를 사용하여 동기화하지 않는다. 오히려, 데이터 공유 및 동기화 둘다 메시지 전달을 통해 달성되는데, 예를 들어, 일련의 명시적으로 선언된 메시지가 서비스들 간에 전송된다. 메시지는 공유되는 데이터, 및 동기화를 제공하기 위한 메시지 교환의 패턴을 포함할 수 있다.

또다른 양상에서, 서비스들 간의 메시지 기반 인터페이스를 지정하는 방법, 예를 들어, 계약이 제공된다. 인터페이스(예를 들어, 메소드) 및 계약에 부가적인 상세를 추가하는 메커니즘도 제공된다. 이러한 상세는 정식의 프로토콜 정의를 제공할 수 있는 메소드 호출(인터페이스의 경우) 또는 메시지(계약의 경우)의 순서화(ordering)를 기술할 수 있는 기능을 제공한다.

본 발명의 다른 양상들은 개별적인 계약-관련 혁신에 관한 것이다. 계약은 인터페이스의 멤버들의 허용가능한 호출 시퀀스에 대한 정식 규격이다. 계약은 양방향 메시지 기반 인터페이스와 함께 사용될 때 특히 강력하지만, 그의 적용성은 본 명세서에서 기술하는 바와 같이 종래의 OO 인터페이스로 확장된다. 예로서, 본 발명의 한 양상은 동적 확인 알고리즘의 구현에 관한 것이다. 보다 구체적으로는, 이러한 양상은 계약의 시행을 위한 런타임 알고리즘에 관한 것이다. 따라서, 표현의 패턴에 상관없이, 런타임 표현은 모든 법적 계약 상태를 인코딩하는 비결정적 유한 상태 기계일 수 있는 것으로 생각된다. 이 상태 기계는 이어서 계약 명세와 대조하여 메소드 호출 또는 메시지를 확인하는 데 사용될 수 있다.

본 발명의 다른 양상은 OO 언어에서의 명시적으로 선언된 메시지의 도입에 관한 것이다. 메시지 지향 언어를 이용하는 종래의 시스템이 공지되어 있지만, 방향성의 페이로드-운반 메시지(directed, payload-carrying message)의 명시적 선언은 새로운 것으로서, 그것과 OO 개념과의 결합도 마찬가지이다. 특히, 본 명세서에서 논의되는 바와 같이, 메시지 전달의 개념도 OO 언어에는 새로운 것이며, 종래의 개념과는 아주 다른 것이다. 다른 양상에 따르면, 메소드 또는 메시지의 시간 순서화의 방향성 메시지 또는 메소드의 집합으로서 프로토콜을 표현하는 것이 기술된다. 보다 구체적으로는, 이러한 양상의 혁신은 정식 계약(formal contract)을 OO 언어(예를 들어, VB.NET 브랜드 환경)에 추가하는 것에 관한 것이다. 선언된 메시지 또는 메소드를 패턴의 알파벳으로 사용함으로써, 통신 프로토콜의 간단하지만 충분히 형식을 갖춘 프로토콜 정의를 확립할 수 있다.

계약 개념은 객체 지향 언어와 관련한 상속과 동일한 종류의 소프트웨어 재사용을 달성하기 위한 메커니즘을 사용하여 확장될 수 있다. 특히, 한가지 주요 개념은 계약 확장이며, 이에 의해 계약의 생성들 사이의 비대칭 호환성이 달성된다. 예로서, 이 개념은 이전 버전의 계약을 사용하는 클라이언트가 새로운 버전을 사용하기 위해 갱신된 서비스와 통신할 수 있게 한다.

또한, 본 발명은 통합(orchestration)에 관한 것이다. 따라서, 메시지 지향 프로그램의 비동기 요구를 처리하기 위해, 본 발명의 한 양상은 "안전한" 병렬성의 몇가지 개념을 지원하는 언어 구성(language construct)을 추가한다. 이 모델이 느슨하게 결합되어 있기 때문에, 프로그램 컴포넌트의 분산을 지원할 수 있다. 이점들 중 몇가지로는 비동기 애플리케이션의 프로그래밍에서의 프로그래머 생산성, 개발된 애플리케이션의 신뢰성, 및 애플리케이션 소스 코드의 전체적 가독성(readability)이 있다.

이해가 용이하도록, 본 발명의 기술된 양상들은 이하의 키워드들, 즉 Service, Send, Receive, Select Receive, Wait, Split, Timeout, Inner Services, Begin, Catch Receive, Accept, Split Select Receive와 관련한 비쥬얼 베이직(VB) 개념들에 관한 것이다. 결합된 새로운 언어 구성은 서로 병렬로 메시지를 처리하는 모델을 구현할 수 있다. 본 발명은 느슨하게 결합된 병행성(loosely coupled concurrency) 및 밀접하게 결합된 병렬성(tightly coupled parallelism)에 대한 공용 루틴(co-routine)을 지원할 수 있는 것으로 생각된다. 이들 구성은 본 명세서의 이후에서 보다 상세히 논의된다.

본 발명의 양상들에 따르면 컴파일 알고리즘(compilation algorithm)이 이용될 수 있다. 구체적으로는, 스레드 컨텍스트를 차단하지 않고 병렬 대기(parallel wait)가 일어날 수 있도록 하기 위해 컴파일러가 공용 루틴 기반 코드를 여러 조각으로 분해하는 방식은 본 발명의 또다른 새로운 양상이다. 메시지가 도착하기를 기다리는 동안 현재 스레드를 방해할 가능성이 있는 소스 코드 내의 각 위치는 다수의 그러한 지점들이 병렬로 대기할 수 있도록 하기 위해 또는 다른 대안으로서 스레드 컨텍스트가 소정 다른 계산을 계속할 수 있도록 하기 위해 쪼개질 수 있다. 전술한 목적 및 이와 관련된 목적을 달성하기 위해, 본 발명의 소정 예시적인 양상들이 이하의 설명 및 첨부 도면과 연계하여 본 명세서에 기술되어 있다. 그러나, 이들 양상은 본 발명의 원리들이 이용될 수 있는 다양한 방식 중 단지 몇 개만을 나타낸 것이며, 본 발명은 그러한 양상 및 그의 등가물 모두를 포함하도록 의도된다. 도면을 참조하여 고려될 때 본 발명의 다른 이점 및 새로운 특징이 본 발명의 이하의 상세한 설명으로부터 명백하게 될 것이다.

이제부터, 동일한 참조 번호가 곳곳의 동일한 구성 요소를 지칭하는 데 사용되고 있는 도면을 참조하여 본 발명이 기술된다. 이하의 설명에서는, 설명의 목적상 본 발명의 철저한 이해를 제공하기 위해 다수의 구체적인 상세가 기술되어 있다. 그렇지만, 본 발명이 이들 구체적인 상세없이도 실시될 수 있음은 명백하다. 다른 예들에서, 본 발명의 설명을 용이하게 하기 위해 공지의 구조 및 장치가 블록도 형태로 도시되어 있다.

본 출원에서 사용되고 있는 바와 같이, 용어 "컴포넌트", "시스템", 및 "메커니즘"은 하드웨어, 하드웨어와 소프트웨어의 조합, 소프트웨어, 또는 실행 중인 소프트웨어든지 컴퓨터-관련 엔티티를 언급하기 위한 것이다. 예를 들어, 컴포넌트는 프로세서 상에서 실행되는 프로세스, 프로세서, 객체, 실행 파일, 실행 스레드, 프로그램, 및/또는 컴퓨터일 수 있지만, 이에 한정되는 것은 아니다. 예시로서, 서버 상에서 실행되고 있는 애플리케이션 및 그 서버 둘다 컴포넌트일 수 있다. 하나 이상의 컴포넌트가 프로세스 및/또는 실행 스레드 내에 존재할 수 있으며, 컴포넌트는 하나의 컴퓨터 상에 국한되어 있거나 및/또는 2개 이상의 컴퓨터 사이에 분산되어 있을 수 있다.

이하는 본 발명의 여러 가지 양상에 대한 설명이다. 이 개시 내용이 비쥬얼 베이직(VB) 환경에서 본 시스템 및 방법을 이용하는 양상과 관련하여 기술되어 있지만, 본 명세서에 개시된 개념들은 본 발명의 취지, 범위 또는 기능을 벗어나지 않고 임의의 객체 지향(OO) 환경과 연계하여 이용될 수 있음을 잘 알 것임에 유의해야 한다.

일반적으로, 본 발명의 한 양상은 메시지 전달, 계약 및 통합을 통해 비동기 프로그래밍을 지원하기 위해 VB.NET 브랜드 환경에서 언어 확장을 이용할 수 있는 시스템 및 방법에 관한 것이다. 요약하면, 본 발명의 개시된 양상들에 따르면, VB 통합은 프로토콜을 기술하고 그에 따라 서비스 또는 클라이언트를 코딩할 수 있게 한다. 본 발명이 대화 상태를 명시적으로 코딩 및 관리할 필요를 경감시킨다는 것을 잘 알 것이다.

먼저, 도 1을 참조하면, 본 발명의 한 양상에 따른 객체 지향 시스템(100)의 일반적인 블록도가 도시되어 있다. 앞서 언급한 바와 같이, 이해가 용이하도록 하기 위해, VB 애플리케이션에 관한 시스템(100)이 기술될 것이다. VB 환경이 본 발명의 양상들을 논의하기 위해 주로 사용될 것이지만, 시스템(100)이 본 명세서에 기술된 본 발명의 범위를 벗어나지 않고 임의의 공지된 객체 지향 언어에 적용될 수 있음을 잘 알 것이다. 일반적으로, 시스템(100)은 클라이언트(102), 계약 컴포넌트(104), 통합 컴포넌트(106), 및 복수의 타겟 서비스(108₁-108_N)(단, N은 정수임)를 포함하도록 구성될 수 있다. 타겟 서비스(108₁-108_N)가 이후부터 총체적으로 타겟 서비스(108)로서 언급될 것임에 유의해야 한다.

계약 컴포넌트(104)는 페이로드 전달 메시지 또는 일련의 메시지 및 그 메시지(들)에 대한 구현 스케쥴을 확인하는 프로토콜을 포함할 수 있다. 계약 컴포넌트가 다른 대안에서는 메소드 또는 일련의 메소드의 전송에 관한 것일 수 있음을 잘 알 것이다.

통합 컴포넌트(106)는 계약을 해석하고 또 서비스(108)의 병렬성 및/또는 병행성을 용이하게 해주도록 구성될 수 있다. 예를 들어, 통합 컴포넌트(106)는 메시지의 다수의 타겟은 물론 다수의 메시지의 처리를 용이하게 해주도록 구성될 수 있다. 본 발명에 새로운 것이지만, 도 1의 통합 컴포넌트가 서비스로의/로부터의 메시지 전달을 통해 객체 지향 환경 및 메시지 지향 환경을 통합하는 것의 기초를 이루는 새로운 개념 및 혁신을 향상시킴을 잘 알 것이다.

도 2는 본 발명의 한 양상에 따라 계약 및 메시지를 교환하는 방법을 나타낸 것이다. 설명의 간단함을 위해 본 명세서에 예를 들어 흐름도 형태로 도시된 하나 이상의 방법들이 일련의 동작으로서 도시되고 설명되어 있지만, 본 발명에 따르면 어떤 동작들이 본 명세서에 도시되고 기술된 다른 동작들과 서로 다른 순서로 및/또는 그와 동시에 일어날 수 있기 때문에, 본 발명이 동작들의 순서에 의해 한정되지 않음을 이해하고 또 잘 알 것이다. 예를 들어, 당업자라면 방법이 다른 대안에서는 상태도에서와 같이 일련의 상호 연관된 상태 또는 이벤트로 표현될 수 있음을 이해하고 잘 알 것이다. 게다가, 예시된 동작들이 모두 본 발명에 따른 방법을 구현해야 하는 것은 아니다.

단계 202에서, 계약이 선언된다. 본 명세서에 기술된 바와 같이, 계약의 선언이 선택적인 배포 패턴 뿐만 아니라 복수의 메시지 또는 메소드를 정의하는 단계를 포함할 수 있음을 잘 알 것이다. 단계 204에서, 계약 내에 구현된 메시지(또는 메소드)는 타겟 서비스로 전송된다. 이어서, 단계 206에서, 메시지(또는 메소드)는 수신되고 전이가 일어난다. 마지막으로, 단계 208에서 메시지가 접수되고, 그 후 단계 210에서 계약을 구현하고 또 계약의 메시지(들) 및/또는 메소드(들) 내에 포함된 코드를 사용하기 위해 역컴파일(decompile)된다.

병행성 모델

다시 도 1을 참조하면, 클라이언트(102)와 서비스들(108) 간의 공유 상태를 사용한 동시 실행은 숙련된 프로그래머들에게조차도 문제가 되는 것으로 밝혀졌음에 유의해야 한다. 여러 집단들이 클라이언트(102)와 서비스(108) 간의 비동기 상 호 작용 및 동시 실행을 위한 소프트웨어와 씨름하고 있지만, 정확성(correctness)을 달성하는 데 있어서의 어려움이 장애가 된다. 본 발명은 정확한 병행 프로그램을 작성함에 있어서의 복잡도의 일부를 완화하는 병행성 모델을 이용하는 시스템 및/또는 방법에 관한 것이다.

종래의 구현과는 달리, 도 1에 예시된 본 발명의 예시적인 VB 통합에서, 인-메모리 상태(in-memory state)를 공유하는 어느 2개의 실행 라인도 동시에 실행되지 않는다. 예시된 바와 같이, 본 발명은 동시 실행을 용이하게 해주기 위해 서비스(108)를 이용한다. 서비스는 개개의 서비스 밖에 있는 어떤 코드와도 상태를 공유하지 않는다. 게다가, 비동기 통신을 달성하기 위해, 도 1에 예시된 본 발명은 계약 컴포넌트(104) 또는 "메시지 전달" 기술을 이용하며, 이 기술은 언어에서 명시적인 Send 및 Receive 동작으로 나타나고 통합 컴포넌트(106) 내에 구현된다.

비동기 메시지 전달의 도입이 다수의 서비스들 간의 통신을 동시에 관리하기 위한 메커니즘을 필요로 한다는 것을 잘 알 것이다. 따라서, 병행 서비스들 간의 통신을 조정하기 위한 메커니즘들의 컬렉션은 "통합(orchestration)"이라고 불리며, 도 1의 통합 컴포넌트에 의해 이용된다.

이하에 보다 상세하게 기술되는 바와 같이, 의사 병렬 실행(pseudo-parallel execution)(예를 들어, Split)을 도입하는 언어 메커니즘들이 제공된다. 그렇지만, 이들 메커니즘은 실제로 동시 실행보다는 동시 대기(concurrent waiting)를 제공한다. 서비스(108)와 통합 컴포넌트(106)의 결합은 경합 조건 및 비동기화된 메모리 액세스의 위험 없이 병행 비동기 거동을 제공한다. 본 발명에 따르면, 2개의 서비스 간의 메시지의 교환은 계약 컴포넌트(104)에 의해 관할되는 대화로서 일어난다. 계약 컴포넌트(104)는 서비스(108)의 메시징 거동의 규격을 제공하며, 그와 상호작용하는 서비스들의 구현에 액세스하지 않고 개개의 서비스(108)가 어떤 형태의 정확성(예를 들어, 메시지 교환의 패턴과의 적합성, 교착 상태 없음)이 있는지 검사할 수 있다. 따라서, 서비스의 거동을 이해함에 있어서의 1차적 산물이 그의 구현된 계약이라는 것을 잘 알 것이다.

계약

도 3을 참조하면, 기본적으로 계약(104)은 보다 광의의 의미에서 비동기 메시지 전달을 위한 인터페이스 선언으로서 정의될 수 있다. 즉, 계약은 일련의 메시지(또는 메소드)를 지정하는 메시지 컴포넌트(302) 및 허용가능한 메시지 교환 시퀀스를 기술하는 선택적인 프로토콜 또는 패턴 컴포넌트(304)를 이용한다. 게다가, 계약 컴포넌트(104)는 기존의 계약 컴포넌트를 확장하는 계약 확장 컴포넌트(306)를 이용할 수 있다.

도 4는 본 발명의 여러가지 양상에 따른 계약을 선언하는 방법(202)을 나타낸 것이다. 본 명세서에 기술되어 있는 바와 같이, 계약의 선언은 선택적인 패턴 뿐만 아니라 복수의 메시지 또는 메소드를 정의하는 단계를 포함할 수 있음을 잘 알 것이다. 도 4를 참조하면, 단계 402로 진행하여, 계약 유형(contract type)이 선언된다. 구체적으로는, VB 예에 따르면, 계약 선언은 계약에 관한 클라이언트 관점 및 서버 관점을 나타내는 2가지 VB 유형을 생성한다. 예를 들어, 선언 "Contract C"는 유형 "C"(클라이언트 관점을 나타냄) 및 유형 "Implements C"(서버 관점을 나타냄)를 생성한다. 예로서, 이하는 알람 시계 서비스에 대한 예시적인 계약이다.

부가적으로, 이하는 스누즈(snooze, 알람 반복) 기능을 추가하기 위해 계약을 확장하는 알람 시계 서비스에 대한 계약이다.

컨텍스트를 제공하기 위해 또한 이해의 편의를 위해, 계약의 문법 및 의미(semantics)에 대한 설명이 이하에 제공된다. 예로서,

도 3을 참조하여 앞서 기술되어 있는 바와 같이, 계약은 일련의 메시지(302)와, 선택적으로는 허용가능한 메시지 교환 시퀀스를 기술하는 패턴(304) 및/또는 도 3에 예시한 바와 같은 계약 확장(306)을 지정할 수 있다. 어떤 패턴(304)도 지정되지 않은 경우, 지정된 메시지의 모든 시퀀스가 허용됨에 유의해야 한다. 계약 확장 메커니즘(306)은 교정된 계약(elaborated contract)을 사용하여 유형이 결정되는 연결자(connector)와 교정 중인 계약(elaborating contract)을 사용하여 유형이 결정되는 연결자 사이의 대화가 가능하도록 계약을 확장하기 위한 것이다.

다시 도 4를 참조하면, 단계 404로 진행하여, 메시지는 선언될 수 있다. 그 다음, 단계 406에서, 선택적으로 패턴이 지정될 수 있다. 단계 406에서 지정된 패턴은 상태 기계로서 지정될 수 있다. 상태들은 StateTransitionStatementGroup 내의 이름들로 명명될 수 있다. 상기의 알람 시계 예에서, 시작 상태는 "시작(start)"으로 명명된다. 메시지 전송 및 수신은 물론 다른 계약들의 실행이 상태 기계에서 전이를 일으킨다. StateTransitionStatementGroup이 2개 이상의 StateTransitionStatement를 포함하는 경우, 패턴은 그룹 내의 전이들 중 임의의 하나를 가능하게 하는 것이 생각된다.

단계 408에서, 패턴과 연계하여 사용되는 트리거가 정의될 수 있다. 구체적으로는, MessageTransitionStatement에서 화살표 왼쪽의 이름이 트리거이며, 그 이 름이 메시지 또는 계약을 지명할 수 있다. 다음에, 단계 410에서, 타겟이 식별된다. 화살표 우측의 식별자가 타겟이며, 상태를 지명할 수 있다. 트리거가 없는 경우, 타겟 상태의 트리거가 발생할 때 전이가 일어난다. 트리거가 계약인 경우, 그 효과는 계약의 패턴의 새로운 인스턴스를 실행하는 것이다. 2개 이상의 트리거가 있는 경우, 타겟들 모두로의 전이가 병렬로 있게 된다. 이 상황은 분할 전이(split transition)라고 한다. 타겟이 Immediate인 경우, 전이는 마지막 트리거가 완료될 때가 아니라 첫번째 트리거가 시작할 때 일어난다. 이것은 트리거가 계약일 때 특히 유용하다는 것에 유의해야 한다.

일례에 따르면, 상태

는

와 동등하다.

마찬가지로, 상태

는

와 동등하다.

부가적으로, 상태

는

와 동등하다.

당업자라면, 표현 구문(expression syntax)에서 "Or", "And" 및 "Then"이 각각 "Or", "And" 및 "AndAlso"와 동일한 우선순위 관계를 가진다는 것을 잘 알 것이다.

한 양상에서, "In Message" 또는 "Out Message"로 주어진 트리거는 해당 방향으로 이동하는 계약에 선언된 임의의 메시지를 표현할 수 있다. 다른 양상에서, "Any In Message" 또는 "Any Out Message"로서 주어진 트리거는 해당 방향으로 이동하는 임의의 메시지를 표현할 수 있고 또한 계약에 선언되지 않은 메시지일 수 있다.

주어진 상태는 주어진 트리거에 대해 최대 한 번의 전이를 할 수 있다. 본 시스템 및 방법에 따르면, 상태가 메시지에 대해 전이를 하는 경우, 그 상태는 메시지를 확장한다. 상태는 2개 이상의 메시지를 확장할 수 있으며, 상태에 의해 확장된 메시지들 모두가 반드시 동일한 방향으로 이동할 필요는 없다. 예를 들어, 모든 메시지가 동일한 방향으로 이동하는 것은 아닌 경우, 반대 방향으로 이동하는 상태 S에 의해 확장된 모든 메시지를 확장하는 것은 아닌 상태 S에 의해 확장된 임의의 메시지에 대한 타겟 상태는 그 메시지들을 무시한다.

End로의 전이는 상태 기계의 현재 라인을 종료시킨다. Stop으로의 전이는 상태 기계의 모든 라인을 종료시킨다. 분할 전이(split transition)가 없는 경우 End 및 Stop은 동등한 것임에 유의해야 한다.

다시 도 4를 참조하면, 본 시스템 및 방법에 따르면, 메시지들은 연결(connection)을 통해 전송 및 수신될 수 있다. 연결은 단계 402에서 선언된 계약 유형인 유형을 갖는 데이터이다. 계약을 지명함으로써 계약 유형이 지정될 수 있음은 잘 알 것이다. 한편, 연결은 계약 실시 유형(contract implements type)인 유형을 갖는 데이터일 수 있다. 계약 실시 유형은 계약의 이름 앞에 명칭 "Implements"가 오게 함으로써 지정될 수 있다. 계약 유형을 갖는 연결은 In message를 전송하고 Out message를 수신할 수 있다. 계약 실시 유형(contract Implements type)을 갖는 연결은 Out message를 전송하고 In message를 수신할 수 있다.

분할 전이

단계 410에서 상태 전이가 2개 이상의 타겟을 갖는 경우, 그 전이는 병렬로 타겟들 모두로 가는 분할 전이라고 한다. 예를 들어, 분할 전이로부터의 일부 경로들이 상태 S에서 수렴하는 경우 분할 전이는 상태 S에서 부분적으로 병합하고 모든 경로가 상태 S에서 수렴하는 경우 분할 전이는 상태 S에서 완전히 병합한다. 상태 T가 분할 전이의 직접 또는 간접 타겟인 경우, 분할 전이가 T에서 또는 T 이전에 완전히 병합하지 않는 한, 분할 전이를 통과하지 않는 T로의 경로가 있을 수 없다. 분할 전이가 상태 S에서 병합하는 경우, 분할 전이로부터의 모든 경로가 상태 S에 도달하지 않는 한, 상태 S로부터의 어떤 전이도 가능하지 않다. 비공식적 으로는, 분할/병합은 적절히 내포(nest)하며, 분할/병합의 중간으로의 어떤 전이도 가능하지 않다.

예로서, 패턴

은 메시지 M1, M1, M2, M4, M3, M3, M5의 시퀀스를 수신한다. S1을 포함하는 각각의 분할 전이는 M3를 병합 상태 S3로 전이하도록 하며, 따라서 동수의 M3 및 M1 메시지가 있을 수 있다.

패턴

은 M1이 Con1의 메시지와 혼합될 수 있게 해주지만, M2는 Con1이 완료된 후에 일어나도록 한다. 이 패턴은 또한 End가 병합 상태일 수 있음을 나타낸다는 것에 유의해야 한다.

계약 확장

본 시스템 및 방법에 따르면, 단계 412에서, 계약 확장 메커니즘(예를 들어, 도 3의 단계 306)은 교정된 계약을 사용하여 유형이 결정되는 연결자와 교정 중인 계약을 사용하여 유형이 결정되는 연결자 사이의 대화가 가능하도록 계약을 확장하는 데 이용될 수 있다. 대화의 한쪽만이 어느 계약을 사용할지에 관한 선택권을 갖는다. 확장의 유형에 의해 판정이 이루어진다.

문법 및 구문의 예는 다음과 같다.

여기서, Extends 문에서의 Name은 포괄 계약(containing contract)이 아닌 계약, 즉 포괄 계약을 확장 또는 교정하는 계약을 명명할 수 있다.

계약 B가 계약 A를 확장하는 경우,

ㆍA의 모든 메시지는 B의 메시지이다.

ㆍA의 모든 상태는 B의 상태이다.

ㆍA에 의해 호스팅되는 모든 계약은 B에 의해 호스팅된다.

ㆍB는 B가 A로부터 상속받은 상태들로부터의 임의의 전이를 제거할 수 있다.

ㆍB는 메시지, 상태 및 호스팅된 계약을 추가할 수 있다.

ㆍB는 B가 A로부터 상속받은 상태들로의 전이를 추가할 수 있다. 추가된 전이들 모두는 동일한 방향으로 이동하는 메시지들에 대한 것일 수 있다. 예를 들어, 추가된 전이가 In message에 대한 것인 경우, 클라이언트는 A나 B 중 어느 하 나를 사용하여 B를 구현하는 서비스에 연결될 수 있다. 추가된 전이가 Out message에 대한 것인 경우, 클라이언트는 A나 B 중 어느 하나를 사용하여 A를 구현하는 서비스에 연결될 수 있다.

프로그램 텍스트에서, B가 A로의 전이를 추가하는 경우에만 A의 상태는 B에서 반복되고, 추가된 전이만이 나타난다. 설계에서 상속된 전이는 볼 수 있지만, 시각적으로는 불변(immutable)으로 표시된다는 것에 유의해야 한다.

연결자(connector)

다시 도 2를 참조하면, 본 시스템 및 방법에 따르면, 단계(204)와 단계(206) 사이의 메시지 교환은 연결을 통해 행해진다. 연결의 양단에서의 코드는 연결자 공장(connector factory)을 통해 생성된 연결자를 통해 메시지를 전송 및 수신한다. 계약 유형 CT에 있어서, 클라이언트측 연결자는 유형 CT를 가지는 반면, 서버측 연결자는 유형 Implements CT를 갖는다.

통합(orchestration)

또한, Split 동작은 다수의 실행 라인을 생성하며, 그 라인들 중 어느 것이라도 그 라인이 양보(yield)할 때까지 실행되며, 양보할 때 다른 라인들 중 임의의 것이 실행될 수 있다. 여러 가지 언어 동작이 실행 라인을 양보하게 할 수 있다. 이들 중에 Receive(예를 들어, 메시지가 도착하기를 기다림) 및 Wait(예를 들어, 특정의 구간 동안 기다림)가 있다.

일련의 메소드 중의 하나에 있는 양보가 다른 메소드 내의 라인이 실행될 수 있게 해줄 수 있는 경우 그 일련의 메소드가 통합 단위를 형성한다, 즉 서로 통합 된다고 말할 수 있다. 이것에 의해 메소드 호출이 반환될 때까지 실행은 그 메소드 호출을 넘어서 진행할 수 없다는 것에 유의해야 한다. (베이스 클래스 및 파생 클래스 내의 메소드를 비롯하여) 통합 클래스의 인스턴스 메소드는 주어진 인스턴스를 위해 서로 통합된다.

통합 클래스는 "orchestration" 수정자(modifier)를 사용하여 선언된다. 통합 클래스는 공유 메소드 또는 속성을 가질 수 없다. 이 양상에 따르면, 통합 동작은 VB 문(statement)이며, 어떤 제약을 받으면서 임의의 메소드에 나타날 수 있다.

다시 도 2를 참조하면, 단계 204에서 Send 문은 다음과 같이 구성될 수 있다.

이 양상에 따르면, Send 문은 선택적인 표현인 특정의 연결자를 통해 메시지를 전송한다. 연결자가 없는 표현(absent connector expression)은 메시지가 1차 연결자를 통해 전송될 것임을 암시하며, 서비스 내에서만 허용된다. 연결자 표현은 계약 유형 또는 계약 실시 유형을 가질 수 있음을 잘 알 것이다.

식별자가 존재하는 경우, 그 식별자는 계약의 메시지를 지명할 수 있으며, 그 메시지는 해당 방향을 가질 수 있다. 메소드 호출과 유사하게, 인수들은 메시지의 파라미터와 대조하여 유형 검사가 행해진다.

Message 키워드가 존재하는 경우, 표현은 System.MessageBus.Message로 변환가능하고, 전송할 메시지 객체를 식별한다.

이와 유사하게, 단계 206에서, Receive 문은 다음과 같이 구성될 수 있다.

Receive 문은 메시지가 도착할 때까지 차단하는 특정의 연결자를 통해 메시지를 수신할 수 있다. 연결자가 없는 표현은 메시지가 1차 연결자를 통해 수신될 것임을 암시하며 서비스 내에서만 허용된다. 연결자 표현은 계약 유형 또는 계약 실시 유형을 가질 수 있으며, 식별자가 존재하는 경우 그 식별자는 계약의 메시지를 지명할 수 있고, 그 메시지는 해당 방향을 식별한다. Receive 문에 선언된 파 라미터는 지역 변수 선언과 유사한 범위를 갖는다. 게다가, Receive 문에 선언되지 않은 파라미터들은 다른 곳에서 지역 변수로서 선언될 수 있다.

Message 키워드가 존재하는 경우, 관련 파라미터들은 System.MessageBus.Message로서 선언될 수 있고, Receive는 수신된 메시지 객체를 지역 변수에 할당할 수 있다. Message 키워드가 존재하고 특정의 메시지 이름이 주어지지 않은 경우, Receive는 필터 표현이 존재하는 경우 그 필터 표현을 만족하는 임의의 메시지를 수신할 수 있다.

마찬가지로, When 표현이 존재하는 경우 Receive 내의 When 표현은 부울 필터로서 기능한다. 필터 표현이 존재하는 경우, 메시지는 그 필터가 True로 평가되는 경우 수신되고, 그렇지 않은 경우 어떤 다른 Receive가 그 필터를 사용할 때까지 그 필터는 무시된다. 필터 표현은 이 표현이 첨부되어 있는 Receive 구절(clause)의 파라미터 및 수신된 메시지 객체의 멤버에 액세스할 수 있지만, 다른 비상수 선언에는 액세스할 수 없다. 필터가 없는 표현은 항상 값 "True"를 갖는 필터 표현과 동등하다.

예를 들어, 다음 형태의 Receive 문

은

과 동등하다.

Wait 문은 다음과 같이 구성될 수 있다.

Wait 문은 유형 System.TimeSpan을 가질 수 있는 표현에 의해 주어진 지정된 구간 동안 실행을 방해한다. Wait 문은 구간이 0인 경우조차도 실행 라인이 양보할 수 있게 해준다.

다음 형태의 Wait 문

은

과 동등하다.

유의할 점: Threading.Thread.Sleep()가 통합 코드 내의 다른 라인이 실행될 수 있게 해주지 않고 스레드를 방해할 수 있기 때문에 Threading.Thread.Sleep()는 통합 코드 내에서 사용되지 않는다는 것이 중요하다.

일단 수신되었으면, 전이가 일어날 수 있다. Begin 문은 다음과 같이 구성될 수 있다.

식별자는 지역 변수로서 선언될 수 있다. 변수의 유형은 계약 유형 또는 계 약 실시 유형일 수 있다. 초기화자(initializer)가 존재할 수 있다.

Begin 문은 지정된 계약에 의해 관할되는 대화의 시작 동안 기다린다. 당업자라면 Begin 문이 일종의 인라인 서비스(in-line service)를 표현한다는 것을 이해할 것이다. 이러한 대화는 다른 코드 본체가 계약 유형의 반대(inverse)의 연결자를 생성하고 이어서 그 연결자를 통해 메시지를 전송할 때 시작한다. 대화가 시작되었을 때, 초기화자는 계산되고, 그의 값이 변수에 할당되며, 실행이 진행된다.

Begin 문은 서브대화들을 관련시키는 메커니즘을 제공한다. 상관된 서브대화에 있어서, 연결자의 초기화는 그의 유일한 인수로서 연결자를 갖는 New 표현이다. 연결의 다른 쪽 단부에 있는 연결자는 그의 유일한 인수로서 연결자를 갖는 New 표현에 의해 생성되었다. 게다가, 인수로서 제공되는 2개의 연결자는 연결될 것이다.

다음 형태의 Begin 문

은

와 동등하다.

마지막으로, 단계 208에서 메시지가 수신될 수 있다. 따라서, Accept State 문은 다음과 같이 구성될 수 있다.

Accept State 문은 연결이 특정의 계약 상태로 전이될 때까지 기다린다. 연결자가 없는 표현은 상태가 1차 연결자를 통해 접수될 것임을 암시하며, 서비스 내에서만 허용된다. 연결자 표현은 계약 유형 또는 계약 실시 유형일 수 있으며, 식별자는 계약의 상태 패턴의 상태를 지명할 수 있다.

accept state 문은 어떤 메시지도 사용하지 않는다. 특히, 상태 전이를 야기하는 메시지는 사용되지 않는다. 차단 해제(unblocking)는 상태 전이를 필요로 한다. accept state 문이 시작될 때 연결이 이미 지명된 상태에 있는 경우, accept state 문은 연결이 그 상태에 다시 들어갈 때까지 기다린다.

accept state 문은 catch accept 문의 일부뿐만 아니라 select receive 문의 일부로서 특히 유용할 수 있음을 이해해야 한다.

다른 형태의 accept state 문

은

와 동등하다.

Select Receive 문은 다음과 같이 구성될 수 있다.

Select Receive 문은 일련의 메시지들 중 하나(또는 그 이상)를 수신할 수 있으며, 및/또는 하나 이상의 대화를 시작하고 및/또는 하나 이상의 연결의 상태 또는 타임아웃을 접수하고, 메시지(들)/대화(들)/상태(들) 또는 타임아웃과 연관된 코드 본체를 실행함을 잘 알 것이다. 타임아웃 표현은 시간 범위(time span)를 표시해야만 한다.

2개 이상의 CaseReceiveClause가 CaseReceiveStatement에 존재하는 경우, 모든 구절은 그 경우와 연관된 코드 본체의 실행을 트리거하도록 만족될 수 있다.

Split 문은 다음과 같이 구성될 수 있다.

Split 문은 실행을 논리적 실행 라인들로 적절히 분할할 수 있다. 라인이 메시지를 기다리는 것을 방해할 때마다 그 다음 미방해된 라인이 실행되는 것을 제외하고는, 그 라인들은 사전적 순서로 순차적으로 실행될 수 있다. Split 문의 어느 2개의 라인도 동시에 실행되지 않음을 잘 알 것이다. Split의 라인 내의 Receive 문은 Split의 다른 라인으로부터 전송된 메시지에 대한 응답을 수신할 수 없다. 당업자라면 이것이 특정 메시지에 대한 응답들을 관련시키는 것을 가능하게 한다는 것을 잘 알 것이다.

Split For Each 문은 다음과 같이 구성될 수 있다.

SplitForEachStatementGroup의 본체는 각각의 반복이 SplitStatementGroup의 개별적인 라인인 것처럼 실행될 수 있다. 컬렉션을 통한 전체 반복은 본체를 실행하기 전에 일어날 수 있다.

Split Select Receive 문은 다음과 같이 구성될 수 있다.

Split Select Receive 문은 수신된 메시지, 개시된 대화, 및 타임아웃을 처리하기 위해 임의의 수의 실행 라인을 자동적으로 생성한다. 다음 형태의 Split Select Receive 문

은

와 유사하지만 이와 미묘하면서도 주목할만하게 다르다.

라인이 종료하기를 기다리기보다는 라인이 양보할 때마다 Split Select Receive 문은 활성화될 수 있다. 임의의 라인에 의해 split select receive 밖의 지점으로의 제어의 이전은 split select receive의 다른 모든 라인을 종료시킬 수 있다.

Catch Receive 문은 다음과 같이 구성될 수 있다. try 문은 메시지를 수신하는 핸들러를 가질 수 있다. 새로운 형태의 catch 문이 이 개념을 구현하는 데 사용될 수 있다.

Catch Accept State 문은 다음과 같이 구성될 수 있다. try 문은 연결의 상태를 수락하는 핸들러를 가질 수 있다. 새로운 형태의 catch 문이 이 개념을 구현하는 데 사용될 수 있다.

New Exit 문이 의도되었다. 예를 들어, new exit 종류는 Line 및 Split일 수 있다. 이들은 Split, Split For Each, 및 Split Select Receive 문 내에서 적용되며, 다른 곳에서는 허용되지 않는다. Exit Line 문은 Split 내의 실행 라인을 종료시킬 수 있다. Exit Split 문은 Split을 빠져 나와 Split의 모든 다른 라인들을 종료시킬 수 있다.

임의의 형태의 Split를 빠져나오는 임의의 다른 제어 이전은 Exit Line 의미(semantics)가 아닌 Exit Split 의미를 가질 수 있다.

서비스

다시, 도 2를 참조하면, 그 다음에 단계 210에서 계약이 실시된다. 본 발명에 따르면, 서비스(예를 들어, 도 1의 서비스(108))는 계약의 실시를 제공한다. 서비스는 서비스의 계약의 개시 메시지를 수신할 때에 자동적으로 인스턴스화된다. 서비스가 그의 계약을 실시하는 수단인 연결자는 자동적으로 초기화되고, 메시지를 전송 및 수신하기 위해 묵시적으로 이용가능하며, 명시적으로 "Primary"라고 언급 될 수 있다. 기술된 양상에 따르면, 서비스는 파라미터를 갖지 않으며 따라서 어떤 결과를 반환하지 않으면서 서비스 호출 Run을 활성화하는 "Run"이라고 하는 인스턴스 메소드를 가질 수 있다.

서비스는 RuntimeService로부터 직접적으로 또는 간접적으로 파생되는 통합 클래스이다. 베이스 클래스가 지정되지 않은 경우, 베이스 클래스는 묵시적으로 RuntimeService이다.

앞서 제시된 알람 시계 예를 다시 참조하면, 전술한 알람 시계 계약을 구현하는 서비스는 다음과 같이 구성될 수 있다.

부가적으로, 이하는 이전의 예의 스누즈 알람 시계 계약을 구현하도록 구성된 예시적인 서비스이다.

이제 서비스의 문법 및 의미에 대해 살펴보자.

상기한 바에 따르면, 서비스는 implements 문 및 임의의 message 문 둘다를 가질 수는 없다. 그렇지만, implements 문이 존재하는 경우, 한 개가 존재하고, 그 문은 단일 타입을 지명할 수 있으며, 그 타입은 계약일 수 있다.

서비스는 계약을 구현하는 암시된 1차 연결자를 가질 수 있다. 실시된 계약은 implements 문에서 지명될 수 있다. 서비스가 implements 문 없이 선언되는 경우, 서비스는 그의 1차 연결자를 통과할 수 있는 메시지를 선언할 수 있으며, 패턴은 그 서비스의 메소드로부터 파생될 수 있다. 즉, 어떤 서비스라도 계약을 실시 한다.

1차 연결자가 서비스 내에서 Primary로서 이용가능할 수 있다. 연결자 표현이 Send 또는 Receive 문에서 생략되어 있는 경우, 연결자는 묵시적으로 Primary일 수 있다.

서비스에 대한 호출은 서비스의 실시된 계약으로서 유형이 결정되는 연결자의 새로운 인스턴스를 반환한다.

이제부터 본 발명의 보다 일반적인 설명으로 들어가면, n-티어 또는 임의의 일반적인 분산 컨텍스트에서 클라이언트 및 서버를 말할 때, 혼란을 피하기 위해 용어를 아주 엄격하게 정의하는 것이 중요하다. 예를 들어, VB 환경에서, "서비스 클라이언트"란 전송되고 있는 메시지에 의해 시작되지 않는 통합 객체를 말한다. 즉, 서비스 클라이언트는 어떤 다른 방식으로 시작될 수 있다. 반면에, "서비스"는 그 서비스로 전송되고 있는 메시지에 의해 생성되는 임의의 객체이다. "서비스"를 시작하는 다른 방법이 없다는 것을 잘 알 것이다. 얼마간 더 애매한 개념으로서, "클라이언트"는 서비스이든지 서비스 클라이언트이든지 상관없이 서비스와의 통신을 개시하는 임의의 코드이다.

계약

계약에 대해 일반적으로 다시 말하면, 계약은 프로토콜 및 그의 메시지를 지정하기 위해 OO 언어(예를 들어, VB)에서 사용될 수 있다. 이 논의는 이하에 나타낸 바와 같이 3 부분, 계약 임포트(contract import) 문, 메시지 선언(message declaration) 문, 및 단일 패턴 정의(single pattern definition) 문에 중점을 두 고 있다.

이상은 String을 함께 전달하는 "Request"라고 하는 인바운드 메시지의 정의이다. 이와 마찬가지로, 역시 String를 함께 전달하는 "Response"라고 하는 아웃바운드 메시지가 정의된다. 메시지 자체가 이름이 되고 데이터 "덩어리(clump)"가 아님에 유의해야 한다. 이점에서, 메시지 자체가 아니라 그 메시지에 대한 식별자가 클래스 이름과 유사하다. 데이터는 메시지의 파라미터로서 정의될 수 있다.

게다가, 프로토콜은 임의의 "세션"에서 2개의 메시지만, 즉 Request 및 Response만을 허용하는 것으로 정의된다. 상호 작용에서의 2개의 메시지의 방향은 개별적인 메시지 선언에서 암시된다. 한 사람의 인바운드 메시지가 다른 사람의 아웃바운드 메시지임을 잘 알 것이다. 본 발명에 따르면, 이러한 관점은 계약을 실시하는 서비스의 관점에서 본 것이다.

프로토콜을 통한 각각의 상호 작용은 두 당사자가 상호작용하거나 메시지를 주고 받음으로써 서로의 내부 상태에 영향을 미치거나 또는 유용한 어떤 외부 효과 를 미치는 것으로 이루어져 있다. 각각의 이러한 두 당사자의 연결에서, 명료함을 위해, 당사자들은 실시측 당사자(implementing party)와 사용측 당사자(using party)로 이름이 붙여져 있다.

개시된 양상의 VB 통합에서, 이것은 계약 관점(contract perspective)이라고 한다. 컴파일러는 인바운드 메시지가 실시측 당사자에 의해 전송되거나 사용측 당사자에 의해 수신되는 것을 허용하지 않으며 또한 아웃바운드 메시지가 실시측 당사자에 의해 수신되거나 사용측 당사자에 의해 전송되는 것을 허용하지 않음을 잘 알 것이다.

상기 계약은 기본적으로 임의의 동기적 메시지 전달 메커니즘이 허용하는 복잡도라는 것을 파악할 수 있다. 한 메시지는 한 방향으로 진행하고 다른 메시지는 응답으로서 되돌아온다. 반환 데이터가 없는 경우, 프로시저 호출에 관한 어떤 파라미터도 없는 경우, 대응하는 메시지는 그에 따라 조정되지만, 동기 패턴에서는 항상 하나의 단일 인바운드 메시지 다음에 하나의 단일 아웃바운드 메시지가 오게 된다. 이하에 기술되는 바와 같이, 프로토콜은 아주 다양한 방식으로 정의될 수 있으며, VB 통합은 이 강력한 기술에 대한 완전히 프로그램적인 액세스를 용이하게 해줄 수 있다.

기본적으로, 계약을 이용하는 것은 메시지 및 패턴을 선언하는 것을 허용한다. 그렇지만, 계약은 엄청난 수준의 보안 및 안전성을 임의의 프로토콜 구현에 추가할 수 있는데, 왜냐하면 계약은 프로토콜이 코드에 의해 첨부되고 있는지를 컴파일러가 검사할 수 있게 해주기 때문이다. 최소한, 계약은 런타임 시에 시행되 고, 종종은 컴파일 시에 시행된다.

본 발명에 따르면, 계약은 개시된 양상의 VB 통합에서 기본적인 언어 추가물 중의 하나이다. 이하에서는 계약 선언과 관련한 상세에 대해 계속 기술한다.

메시지 선언

다시 도 4를 참조하면, 상기 예는 계약을 선언하는 방법을 설명한 것이다. 구체적으로는, 단계 404에, 메시지를 선언하는 단계가 예시되어 있다. 당업자라면 선언은 기본적으로 Sub 선언과 유사한 일반 규칙을 공유하지만 이하의 제약 조건을 가진다는 것을 잘 알 것이다.

1. "ByVal", "Optional", "ByRef", 또는 "ParamArray" 선언인 모든 파라미터가 허용되는 것은 아니다.

2. 원격적으로 사용되는 임의의 프로토콜의 경우, 모든 파라미터는 직렬화가능하다.

3. 모든 메시지는 지정된 방향을 가져야만 한다.

4. 메시지는 오버로드(overload)될 수 없다.

패턴 선언

이제부터 패턴 선언을 살펴보면, 단계 406에서, 임의의 패턴 선언의 가장 기본적인 구성 블록은 메시지 참조이다. 상기 예에서, 패턴에서 메시지를 참조할 때 메시지의 이름을 언급하기만 하면 된다는 것을 잘 알 것이다. 이렇게 하면 되는 이유는 그의 방향이 알려져 있기 때문이다. 게다가, 오버로딩이 허용되지 않으며, 메시지가 일단 선언되었으면 방향 및 파라미터 유형 이외에 메시지에 부가적인 제 한이 가해질 수 없다. 예를 들어, 상기 예에서의 문자열 인수가 널이 되지 않도록(non-null) 하는 것이 요망되는 제한인 경우 이를 지정하는 방법이 없음에 유의해야 한다.

패턴은 프로토콜의 일련의 지명된 "상태", 예를 들어 그에 대해 어떤 의미를 갖는 대화에서 서로 다른 위치를 정의함으로써 선언된다. 임의의 패턴의 첫 번째 상태는 "Begin"이라고 할 수 있다.

상태가 정의되었으면, 프로토콜은 프로토콜 상태가 어떻게 변화할 수 있는지를 나타내기 위한 상태 "전이"를 추가함으로써 완료될 수 있다. 트리거 및 타겟이 단계 408 및 단계 410에 의해 식별될 수 있다는 것을 잘 알 것이다. 한 양상에서, 이러한 전이는 메시지에 의해 트리거된다. 다른 양상에서, 메시지는 메소드 또는 임포트된 계약에 의해 표현될 수 있다.

예로서,

전술한 바와 같이, 구문 "Request Then Response"은 전이 트리거이며, "End" 는 전이의 종료 상태이다. 전이 트리거는 즉 콤포지트(composite)이다. 예를 들어, 콤포지트 전이 트리거는 "Then"을 사용하여 일련의 메시지를 일정 순서로 정렬(sequence)하거나 "And"를 사용하여 그 메시지들을 무순서로 그룹화함으로써 이용될 수 있다. 또한, 메시지 이름 사이에 "Or"를 사용하여 대안적인 일련의 트리거를 지정하는 것도 가능하다. 트리거의 메시지 모두가 전송되거나 수신되자마자 전이가 일어난다.

전이 종료 상태는 2개 이상의 상태일 수 있다. 예를 들어, 전이는 2개 이상의 타겟 상태로 "분할(split)"될 수 있으며, 이는 프로토콜 "포지션(position)"이 한번에 2개 이상의 지명된 상태에 의해 정의됨을 의미한다. 한 양상에서, 타겟 종료 상태는 수정자 "Immediate"가 부착되어 있을 수 있으며, 이는 전체 트리거가 완료하기를 기다리기보다는 특정 트리거와 일치할 때 그 상태로의 전이가 즉각 일어남을 의미한다. 이것은 트리거가 계약 이름을 포함할 때 특히 유용하다.

전술한 바와 같이, 어떤 패턴도 갖지 않는 계약이 어떤 메시지 교환 패턴이라도 허용하며, 비어있는 패턴을 갖는 계약은 어떤 메시지도 교환될 수 없게 한다는 것을 잘 알 것이다.

계약 확장

부가적으로, 본 발명의 양상들은 도 4의 단계 412에 예시한 바와 같이 계약 확장을 이용한다. 도 5는 계약 확장을 용이하게 하는 방법을 예시한 것이다. 이 방법에 따라 계약을 확장함으로써, 이전 버전과 비대칭으로 호환되는 새로운 버전이 생성될 수 있다. 구체적으로는, 계약을 확장할 때, 단계 502에서 새로운 메시 지가 추가될 수 있다. 게다가, 단계 504에서, 새로운 상태가 기존의 패턴에 추가될 수 있다. 게다가, 단계 506에서, 이하의 어떤 제약 요건의 구속을 받으면서 새로운 트리거가 기존의 상태에 추가될 수 있다.

1. 어떤 모호함도 도입되어서는 안 된다.

2. 어떤 기존의 트리거도 변경되어서는 안 된다.

3. 기존의 상태에 추가된 트리거는 첫 번째 가능한 메시지로서 "In" 메시지 및 "Out" 메시지 둘다를 가질 수는 없다. 메시지 방향은 동일해야 한다.

4. 트리거가 기존의 상태에 추가되는 경우, 및 트리거가 "In" 메시지인 경우, 임의의 기존의 상태에 추가된 모든 트리거는 "In" 메시지만을 포함한다.

5. 이와 반대로, 트리거가 기존의 상태에 추가되는 경우, 및 트리거가 "Out" 메시지인 경우, 임의의 기존의 상태에 추가된 모든 트리거는 "Out" 메시지만을 포함할 수 있다.

이들 제약요건에 따르면, 계약 재사용에 대한 모델은 클래스에 대한 상속과 유사할 수 있다. 한 양상에서, (예를 들어, "In" 메시지만이 기존의 상태에 추가된다.) 새로운 계약은 클라이언트-호환(client-compatible)이며, 다른 경우에 새로운 계약은 서비스-호환(service-compatible)이다.

클라이언트-호환 계약은 클라이언트가 알 필요가 없이 서비스들이 이전의 계약으로부터 새로운 계약으로 업그레이드될 수 있음을 의미한다. 즉, 이전의 계약을 사용하는 클라이언트는 새로운 상태로의 전이를 트리 거하는 메시지를 결코 전송하지 않는다. 한편, 더 새로운 계약을 알고 있는 클라이언트는 서비스가 그 계 약을 지원하는 경우에만 그 계약을 이용할 수 있다. 따라서, 이 관계는 비대칭 호환임을 잘 알 것이다.

반면에, 계약이 서비스 호환인 경우, 클라이언트는 새로운 계약을 사용하기 위해 업그레이드될 수 있으며 이전의 계약 또는 새로운 계약 중 어느 하나를 지원하는 서비스와 계속하여 대화한다.

이하는 앞서 제시한 요청/응답 예의 수정된 버전을 이용하는 예이다.

클라이언트 호환 예:

위의 예시적인 코드에 기술한 바와 같이, 클라이언트만이 이전의 계약을 알고 있는 경우, 클라이언트는 여전히 새로운 계약을 지원하는 서비스에 연결될 수 있는데, 그 이유는 새로운 메시지가 결코 전송되지 않는 한, 계약은 교환가능하기 때문이다. 전술한 바와 같이, 서비스는 이전의 계약을 사용하는 클라이언트와 단지 새로운 특징을 이용하지 않는 클라이언트 간의 차이를 분간할 수 없다.

서비스 호환 예:

여기서, 서비스는 기존의 계약을 벗어났는지 여부를 결정할 수 있다. 따라서, 업그레이드된 클라이언트는 서비스가 이전의 계약을 사용하는지 새로운 계약을 사용하는지를 알 수 없게 된다. 확장된 패턴에는 새로운 정보, 즉 새로운 상태 및 기존의 상태에 대한 새로운 트리거만이 열거되어 있음에 유의해야 한다. 이것은 에러의 소스를 피하며, 명료함이 필요한 경우, 이전의 계약 패턴은 설명으로서 포 함될 수 있다.

호스팅된 계약을 추가하고 메시지를 추가하지 않음으로써 계약 A가 계약 B를 확장할 수 있음을 이해해야 한다. 이 경우, A는 B와 대칭적으로 호환된다. 계약을 호스팅하는 것에 대해서는 본 명세서에서 이후에 보다 상세히 논의될 것이다.

연결자

계약은 그 계약을 참조하는 어떤 것을 선언하기 위해 이용될 수 있다. 예시적인 양상에 따르면, VBM 통합 기반 코드가 다른 코드와 통신하기 위해 사용하는 객체를 "연결자(connector)"라고 한다.

유형에 관한 한, 연결자는 계약 참조 유형(contract reference type)이다. 연결자에 관한 특색이 있다. 예를 들어, 연결자는 그의 유형의 일부인 잘 정의된 계약 관점을 갖는다. 연결자는 계약의 실시 측이나 사용 측 중 어느 하나를 표현한다. 실시 측 연결자는 사용 측 연결자에 할당될 수 없고 그 역도 마찬가지이다. 이들 규칙에 따르면, 연결자를 어떻게 생성하는지 및 연결자가 실시 측인지 사용 측인지를 어떻게 정의하는지가 궁금한 것은 당연하다.

연결자는 의해 정의될 수 있는 연결자 공장을 사용하여 생성될 수 있다. 대부분의 연결자 공장은 서비스 URL 또는 다른 연결자로부터 생성된다.

여기서 URL은 서비스 참조라고 한다. URL은 구성 파일에 보관된 어떤 기지의 URL일 수 있거나 어떤 다른 브로커 서비스에 의해 시에 구성될 수 있다. 예를 들어, 최상의 거래 장소를 결정하고 URL을 대리점으로, 다시 요청자로 전송하는 도매 대리점 입찰 서비스가 있을 수 있다.

연결자 공장이 있는 경우, 연결자는 연결자 공장 클래스에 내장된 변환 연산자(conversion operator)를 사용하여 용이하게 생성될 수 있다.

이 예시적인 문은 연결자 공장에 의해 그의 1차 연결자 상에 "Croquettes"를 구현할 수 있는 서비스를 참조하는 사용 측 연결자를 생성한다. 연결자 공장의 이러한 사용이 사용 측 연결자를 생성할 수 있다.

연결자 공장은 또한 다음과 같이 실시 측 연결자에 직접 연계되어 있을 수 있다는 것을 이해할 것이다.

이 양상은 양측이 동일한 애플리케이션 도메인 내에 있고 분할될 필요가 없음을 알고 있는 환경에서 유용할 수 있다. 이 양상은 애플리케이션이 분산되지 않도록 하는 코드를 애플리케이션에 추가할 필요가 있기 때문에, 일반적으로 실망스럽지만 특수한 경우 성능에 유용하다. 이전의 예들은 사용 측 연결자이다.

반면에, 실시 측 연결자는 2가지 상이한 방식으로 선언될 수 있다. 구체적으로는, 계약 이름은 키워드 "Implements"에 의해 수정될 수 있고, 초기화자 표현을 다음과 같이 인수를 갖지 않는 계약 호출(contract invocation)이어야만 한다.

사용 측 연결자가 초기화될 때, 그 연결자는 대응하는 실시 측 연결자에 바인딩되지만, 실시 측 연결자는 바인딩을 개시하지 않으며, 따라서 실시 측 연결자는 파라미터로서 서비스 참조를 필요로 하지 않는다. 따라서, 그 결과 얻어지는 연결자는 생성된 후에 바인딩되지 않으며, 어떤 사용 측 연결자가 새로운 연결자에 바인딩될 때까지 메시지를 전송하기 위해 사용될 수 없다.

이전에 정의된 바와 같이 서비스는 그의 "1차" 연결자라고 하는 묵시적인 실시 측 연결자를 가짐에 유의해야 한다. 1차 연결자는 서비스가 시작되기 전에 알고리즘에 의해 생성되고 "Primary" 필드로서 스케줄에 이용가능하다. 메시지를 전송 및 수신할 때, 다른 연결자가 참조되지 않을 때 1차 연결자가 암시될 수 있으며, 따라서 실제로 1차 연결자를 명시적으로 참조하는 어떤 코드도 거의 볼 수 없다. 이하에 상세히 기술하는 바와 같이, 1차 연결자는 멀티플렉싱을 위한 서비스 참조를 생성하는 데 사용될 수 있다.

참조 유형의 변수가 선언될 수 있는 곳이면 어디라도 연결자가 선언될 수 있다. 예를 들어, 연결자는 VBM 모듈 등에서 로컬(local)로서, 파라미터로서, 및/또는 필드로서 선언될 수 있다. 연결자는 참조로 전달될 수 있고 임의의 객체 참조와 유사하게 다른 변수에 복사될 수 있다. 본 발명의 한 양상에 따르면, 연결자의 관점은 변경될 수 없다. 게다가, 컴파일러는 그의 엄격한 유형 검사(strong typing)를 통해 이것을 보장할 수 있다. 이 양상에서는, 따라서 연결자 또는 일반 서비스를 정의하거나 사용하는 어떤 소스 파일에도 "Option Strict Off"를 사용할 수 없다.

세션

본 발명의 통합에 관한 한가지 새로운 양상은 본 발명이 확장가능한 멀티스레드 애플리케이션(scalable multi-threaded application)에서 일반적인 문제인 스레드, 프로세스, 또는 다른 양상에 관한 관심을 줄일 수 있다는 것이다. 적당한 관심과 통찰력을 가지고 보면, 스레딩 및 프로세스 분리는 애플리케이션 개발 문제가 아니라 애플리케이션 분산 및 관리 문제가 될 수 있다.

그렇지만, 일반적으로 비분산 애플리케이션에 관련한 문제는 아니지만 VB 통합에 필수적인 한가지 개념은 세션의 개념이다.

이하의 예는 이해의 편의를 위해 제공된 것이다. 쇼핑하거나 또는 계정 정보에 액세스하거나 요금을 지불하기 위해 금융 기관 사이트에 액세스하기 위해 인터넷을 사용하는 사용자는 분산 애플리케이션 의미에서 세션에 익숙해야만 한다. 특히, 전자 상거래 사이트에 액세스하고 쇼핑 카트에 물품을 추가하거나 "내 계정" 페이지에 액세스할 때, 웹 사이트 소프트웨어는 그 방문자 및 로그인 이후에 무엇이 행해졌는지를 기억할 수 있도록 하기 위해 메모리 내의 어떤 객체들을 할당해야만 한다. 이 데이터는 일시적인 것으로서 일반적으로 데이터베이스에 저장되어 있는 장시간 지속되는 주문 정보 또는 계정 정보와 다를 수 있다.

이 일시적인 데이터의 수명을 세션이라고 한다. 비분산 애플리케이션에서, 데이터는 쓰레기가 될 때까지 메모리에 유지될 수 있다. 반면에, 분산 애플리케이션에서는 상황이 완전히 달라진다. 분산 애플리케이션과 관련하여, 2가지 주요 문제가 있다. 첫째, 애플리케이션 노드를 통한 객체 참조가 없다. 둘째, 세션이 종 료될 때 통지받을 것이라고 기대해서는 안 된다.

첫 번째 문제는 객체를 청소하기 위해 가비지(garbage) 컬렉션에 의존하는 경우 모든 일시적인 데이터는 아주 신속하게 쓰레기처럼 보여 제거된다는 것을 암시한다. 이어서, 애플리케이션 노드는 이전에 거기에 있었던 방문자에 관한 모든 것을 잊어버리며, 이는 골치 아픈 문제가 된다. 따라서, 이러한 소프트웨어는 일반적으로 어떤 종류의 글로벌 컬렉션에 세션별 데이터 구조를 할당하고 동일한 세션에 대한 새로운 요청이 들어올 때 그 데이터 구조를 검색할 수 있다.

이제 두 번째 문제를 살펴보면, 언제 세션이 끝나는지 모르는 경우, 세션 데이터는 결코 쓰레기가 되지 않는데, 왜냐하면 글로벌 컬렉션은 자신이 일으키는 메모리 누설 문제로 유명하기 때문이다.

이 문제를 해소하기 위해, 일반적으로 세션의 시간이 기록된다. 세션이 처음으로 생성될 때 타이머가 설정될 수 있고, 모든 들어오는 메시지 또는 요청에 대해 리셋된다. 웹 사용자 로그 아웃 등과 같이 세션이 종료된 것으로 결정될 수 있는 경우, 데이터는 그 시점에서 제거된다. 그렇게 결정될 수 없는 경우, 타이머가 꺼질 때, 세션 데이터는 글로벌 해쉬 테이블로부터 제거되고 데이터는 쓰레기가 된다.

타당한 타임아웃 구간이 완전히 애플리케이션 의존적이라는 것을 이해할 것이다. 웹 사이트는 일반적으로 타임아웃 구간을 10분 내지 30분으로 설정하지만, 그것이 보편적으로 유효한 설정은 아니다. 어떤 애플리케이션에 있어서, 2초가 적당할 수 있으며, 다른 애플리케이션의 경우 수시간이 적당할 수 있다.

예시적인 VB 통합에 따르면, 이 모든 것이 자동적으로 지원된다. 한 양상에서, 디폴트 타임아웃 값은 10분이다. 10분이 적절하지 않은 경우, App.config 파일에서 타임아웃을 재구성할 수 있다. 이 재구성에 대해서는 "App.config 설정"과 관련하여 이하에서 보다 상세히 기술한다.

스케쥴이 처음으로 시작될 때는, 그 스케쥴이 서비스인지 서비스 클라이언트인지 관계없이, 다른 어떤 것이 일어나기 이전에 그의 세션이 생성될 수 있다. 세션은 효과적으로 서비스 클래스의 인스턴스를 생성한다. 그렇지만, 세션은 클라이언트가 그 세션을 참조할 수 있게 하는 전역적으로 고유한 식별자를 할당받는다. 따라서, 세션은 또한 서비스 인스턴스라고도 한다. 메모리 내의 특정 객체를 참조하고 있음을 나타낼 필요가 있을 때 후자가 특히 유용할 수 있지만, 분산 애플리케이션 관점으로부터 그것을 보고자 할 때는 전자가 특히 유용할 수 있다는 것을 잘 알 것이다.

서비스 인스턴스는 일반적으로 그와 연관된 다수의 연결자를 갖는다. 처음에, 연결자는 연결자를 생성한 스케쥴에만 연결될 수 있지만, 다른 스케쥴에 메시지를 전송하기 위해, 연결자는 항상 동일한 계약의 반대 관점을 갖는 다른 연결자에 바인딩될 수 있다. 일단 바인딩되면, 연결자는 재바인딩될 수 없다.

상기 예들을 참조하면, 생성된 처음 3개의 연결자 모두는 서비스 또는 계약 호출이 반환될 때 바인딩된다. 4번째 경우는 그렇지 않다. 이러한 이유는 어떤 다른 연결자가 바인딩하기 위해 사용하는 서비스 참조를 생성하는 데만 그 연결자가 사용될 수 있기 때문이다. 일단 그렇게 되면, 통신이 시작할 수 있다.

상기한 웹 서비스 예에서, 세션을 처리하는 소프트웨어가 세션 그 자신의 외부에 있는 세션 고유의 객체에 대한 참조를 저장하지 않는 것이 중요하다. 그렇게 한다는 것은 세션이 제거될 때 그 객체들이 쓰레기가 되지 않고 분산 애플리케이션에서의 객체들의 수명을 제어하기 위한 세션들의 주된 목적 중 하나가 위반된다는 것을 의미한다.

전체 애플리케이션이 처음에는 동일한 애플리케이션 도메인 내에 있는 경우에도 VB 통합을 프로그램할 때 이것이 행해진다는 것이 똑같이 중요하다. 세션 동안에 생성된 참조가 스케쥴 밖에 저장될 수 있게 하는 것이 애플리케이션이 일정 축척으로 작성될 수 있는지 여부를 궁극적으로 결정하는 글로벌 시스템 자원의 자동 관리를 가능하게 하지 않는다.

규칙은 간단하다. 서비스 또는 스케쥴의 본체 내에 선언되어 있는 참조들에 데이터 상태에 대한 참조들을 저장할 뿐이다. 즉, 임의의 종류의 전역 변수 또는 컬렉션에 참조를 저장하지 않는다. 이 규칙은 따르기 쉬우며 아주 타당하다. 또한, 이 규칙은 다른 소프트웨어의 기본적인 재입력 규칙과 속성이 아주 유사하다. 예를 들어, 전역 상태를 피하고 그 대신에 항상 데이터를 파라미터로서 전달한다.

데이터가 애플리케이션 레벨 데이터, 즉 애플리케이션 도메인 내의 세션들 간에 공유되는 데이터로서 속하는 경우에만, 그 데이터는 세션 외부에서 선언되고 저장된다. 그렇다 해도, 데이터는 애플리케이션의 설계에 관하여 재고할 필요가 있는 무언가가 있을 수 있다는 레드 플래그(red flag)로서 기능한다.

스케쥴(통합)

이제 도 6을 참조하면, 통합 컴포넌트의 일반적인 블록도가 도시되어 있다. 도시된 바와 같이, 통합 컴포넌트는 구현 또는 스케쥴 컴포넌트(602) 및 컴파일러 컴포넌트(604)를 포함하는 것으로 도시될 수 있다. 본 발명에 따르면, 스케쥴 컴포넌트(602)는 소스 코드에 나타나지 않지만 그럼에도 불구하고 이하의 섹션의 이해에 중요한 런타임 개념이다. 간략히 말하면, 스케쥴 컴포넌트(602)는 메시지 지향 코드가 2개 이상의 메시지를 병렬로 기다릴 수 있게 하는 데 사용되는 런타임 객체이다.

추상적으로 말하면, 예시적인 VB 환경에 관하여, 모든 메소드는 스케쥴을 가지며, 이에 의해 메소드는 스케쥴이 완료될 때 반환된다. 구체적으로는, 이하에 기술하는 바와 같이 message receives 또는 wait 문을 포함하는 메소드만이 스케쥴을 필요로 한다. VB 컴파일러는 스케쥴이 없는 구현에서처럼 가장 효율적인 구현이 사용되도록 보장하게 된다.

이 런타임 정의가 주어지면, 스케쥴은 광의적으로 메시지 관련 코드의 본체로서 기술되거나, 몇 개의 메소드들 간에 분할되거나, 또는 하나의 단일 메소드 내에 포함될 수 있다. 후자의 경우가 디폴트이다, 예를 들어 메시징 코드를 갖는 각각의 메소드가 그 자신의 스케쥴을 정의한다.

반면에, 전자는 통합 클래스를 사용하여 구현되며, 이 통합 클래스는 모두가 클래스 System.Orchestration.RuntimeOrchestration으로부터 직접적으로 또는 간접적으로 파생된 클래스이다. 통합 클래스는 인스턴스에 관한 모든 메소드에 대해 하나의 단일 스케쥴을 공유한다. 스케쥴은 임의의 인스턴스 메소드에 대한 (예를 들면, "Me"를 사용하지 않는) 외부 호출에 의해 시작될 수 있으며, 최초 메소드가 반환될 때까지 그 동일한 인스턴스에 관한 모든 내부 메소드 호출에 걸쳐 확장된다.

통합 클래스는 통합 클래스가 요구되는 베이스 클래스를 가지며 공유 메소드 또는 속성을 선언할 수 없다는 것을 제외한 모든 점에서 정규 클래스와 유사하다.

서비스

게다가, 본 발명에 따르면, 서비스는 클래스 System.Orchestration.RuntimeService로부터 직접적으로 또는 간접적으로(예를 들어, 다른 서비스로부터) 파생될 수 있는 통합 클래스를 참조한다. 또한, 서비스는 런타임에 의해 자동 인스턴스화된다.

컨텍스트를 제공하기 위해, 이하의 논의는 서비스에 관련된 2가지 개념을 분류한다. 즉, 1) 서비스의 1차 연결자가 구현하는 계약과 2) 그의 시작 방법을 분류한다.

첫째, 계약은 2가지 방식으로, 즉 1) implements 문에서 계약을 이름으로 언급하는 것에 의해, 또는 2) 스케쥴 본체로부터의 파생에 의해 정의될 수 있다. 전자의 예는 다음과 같다.

여기서 계약은 이전에 논의된 요청/응답이다. 예를 들어, 서비스는 문자열 로서 증권 시세 표시기(stock ticker symbol)를 수신하고 마지막 거래에서 가격의 문자열 표시로 응답한다. 물론, 응답에 대해 상이한 데이터 유형을 사용하는 것은 보다 나은 아이디어일 수 있지만, 여기서 중요한 점은 양호한 계약을 어떻게 설계하느냐가 아니라 서비스에서 계약을 어떻게 사용하느냐이다.

서비스는 항상 그 서비스가 시작되기 바로 전에 생성된 실시측 연결자에 사용측 연결자를 바인딩하는 메시지를 그 서비스로 전송함으로써 그 서비스를 호출하는 클라이언트에 의해 개시된다.

계약 및 스케쥴을 지정하고 또 다수의 서버 상의 다수의 프로세스에서 이용가능하게 될 수 있는 서비스 정의, 및 서비스의 특정 세션을 나타내는 서비스 인스턴스를 따로 보관하는 것이 중요하다.

서비스는 유형 정의이고 서비스 인스턴스가 객체임을 이해해야 한다. 그렇지만, 우리는 실제로 서비스 인스턴스에 대한 참조를 갖지 않기 때문에(또는 사용할 수 없기 때문에), 때때로 이러한 관계를 보기가 어렵다. 서비스들은 연결자를 통해서만 상호 작용한다. 메시징이 서비스와 상호작용하는 유일한 방법인 경우에만, 서비스들은 시스템이 확장가능한 애플리케이션 설계를 지원하는 데 필요한 방식으로 재배치 또는 복제될 수 있다. 따라서, 서비스들은 생성자를 정의할 수 없고 "New" 표현을 사용하여 할당될 수도 없다.

서비스가 구현하는 계약을 지정하는 두 번째 방법은 컴파일러를 이용하여 스케쥴에 포함된 코드로부터 서비스를 파생하는 것이다. 여기서, 컴파일러는 코드를 해석하기 위해 그 코드를 분석한다. 즉, 우리가 계약 정의를 작성할 필요가 없다. 이 메커니즘을 사용하기 위해, 우리는 1차 연결자 상에서 사용되는 메시지를 선언하기만 하면 된다. 이러한 서비스의 계약을 사용하여 연결자를 생성할 수 있기 위해서는, 서비스에 대해 파생된 계약이 예측가능한 이름, 예를 들어 "<service-name>.Contract"을 가질 수 있다.

그렇지만, 모든 그의 편의를 위해 계약을 파생하는 것은 추상화의 결여를 가져온다.

잘 알고 있는 바와 같이, 계약은 프로토콜에 무엇이 있는지를 정확하게 설명하는 역할을 한다. 파생된 계약은 (서비스 구현이 정확한 한) 항상 정확하긴 하지만 판독성 또는 사용 용이성을 보장하지는 않는다. 파생된 계약은 서비스의 내부 구조를 직접 반영하며, 이 내부 구조는 클라이언트를 작성하려고 하는 프로그래머가 이해하기 어려울 수 있다. 또한, 컴파일러가 처리하는 데 어려움을 겪고 또 그다지 엄격하지 못한 계약이 얻어지게 되는 어떤 상황이 있다.

서비스는 일단 시작되면 서비스가 동일한 애플리케이션 도메인 내에 있는지 여부에 관계없이 호출 코드와 병렬로 실행될 수 있다. 병행성에 관하여 기술된 것은 아무것도 없고 병렬성만 있는 것에 유의해야 한다. 이 둘은 메시징을 통해서만 동기화하고 데이터를 공유하는 한, 서로의 제어 흐름에 독립적인 것처럼 작성되고 구현될 수 있다. 유의할 점은 상이한 서비스 인스턴스가 (예를 들어, 개별적인 스레드 또는 프로세스에서) 동시에 실행되거나 동시에 실행되지 않을 필요는 없다는 것이다.

메시징

이전의 설명을 고려하면서, 이제부터 클라이언트측 또는 서버측 중 어느 한쪽 상에 프롤토콜을 구현하는 코드의 본체로서 정의될 수 있는 스케쥴의 개념을 살펴본다. 스케쥴을 보는 2가지 방법이 있다. 즉, 1) 스케쥴을 메시지를 전송하고 그에 대해 폴링하는 프로시저로서 보거나, 2) 프로시저의 모델과 근본적으로 다른 그의 실행 모델을 상세히 살펴본다.

본 명세서에서 전술한 바와 같이, 프로토콜 핸들러의 미숙한 구현은 어떤 메시지 전송 API를 통해 메시지를 전송하고 다른 API를 사용하여 메시지에 대해 폴링하는 메소드로서 구현된다. 이 종래의 모델에서 각각의 서비스 인스턴스는 그 자신의 실행 스레드를 가져야만 하며, 이는 확장성도 없고 환경의 런타임 조정도 할 수 없는 상황이다. 종래에, 각각의 서비스 인스턴스는 개별적인 스레드를 필요로 하며, 그에 대해 더 이상 아무것도 없다. 운영 시스템(OS)은 어느 스레드가 언제 실행되는지를 결정하고, 애플리케이션 오퍼레이터가 이용가능한 조정 컨트롤은 없다.

이 종래의 방법에서의 초기 문제점은 너무 많은 할당된 스레드를 필요로 하며, 따라서 메모리 풋프린트를 상당히 증가시킬 뿐만 아니라 OS(예를 들어, 커널) 자원에 부담을 준다는 것이다. 서비스 인스턴스가 들락달락하기 때문에, OS 스레 드가 생성되고 파괴되어야만 하며, 이는 비경제적이고, 한번에 단지 동수의 스레드만을 활성 상태로 유지할 수 있는 "조절판"이 없다(예를 들어, 서비스 당 하나의 인스턴스가 필요하다).

문제를 더 복잡하게 만드는 것은, 이진 코드 내의 저레벨 위치가 대화 상태를 포함한다는 것이다. 따라서, 서비스 인스턴스를 다른 기계로 이동시키거나 대화 상태를 단지 조사만 하는 것이 어렵게 된다.

따라서, 본 시스템 및 방법에 따르면, 프로토콜 핸들러(예를 들어, 서비스)의 임의의 타당한 구현에 관한 2가지 기본적인 양상이 있다. 첫째, 프로토콜 핸들러의 실행 환경에 관한 가정이 있을 수 없다. 핸들러마다 스레드가 있을 수 있거나, 스레드는 서비스 인스턴스들 간에 공유될 수 있으며, 심지어 중복하는 수명을 갖는 서비스 인스턴스들 간에도 공유될 수 있다. 둘째, 대화 상태는 코드가 아니라 데이터로 표현될 수 있다.

두 번째 문장이 데이터로 구현하기보다는 대화 상태의 흐름을 선언하는 것에 관한 앞서의 논의와 모순되는 것으로 생각할 수 있지만, 개발자가 대화 흐름을 선언적인 것으로 볼 수 있어야만 한다는 것을 말하는 것이다. 대화 상태가 데이터로 표현되는 경우, 런타임 모델은 여전히 하나일 필요가 있다. 즉, "미숙한" 모델이 프로토콜 핸들러의 소스(예를 들어, 프로그래머) 관점으로서 적절하지만, 런타임 모델이 아주 다를 수 있음을 잘 알 것이다. 당업자라면 VB 통합이 이 차이를 극복함으로써 고수준의 생산성 및 판독성 향상을 그럭저럭 달성한다는 것을 잘 알 것이다.

그 다음에, 스케쥴 코드는 소스 스케쥴의 모든 로직을 포함하는 개별적인 클래스로 컴파일되지만, 상이한 병행성 모델을 지원하기 위해 재정렬된다. 스케쥴의 시작 시에, 중지 이벤트(pausing event)(별칭은 "양보점(yield point)")가 일어날 때까지 코드가 실행된다.

중지 이벤트가 일어나면, 스케쥴은 실행을 중지하고 스케쥴을 시작한 스케쥴링 런타임에서 사이트로 또는 마지막 재개 이벤트의 사이트로 제어를 반환한다. 현재, 유일한 재개 이벤트는 메시지 도착, 메시지 타임아웃 및 wait 문 완료이다.

스케쥴을 중지시킨 후에, 그의 스레드는 스케쥴이 원하는 무엇에라도 사용하기 위해 런타임으로 다시 주어지거나 파괴되며, 이 모두는 기반을 이루는 런타임의 스레드 모델에 좌우된다. 더 복잡한 호스팅 프레임워크는 모든 그의 동작에 대한 스레드 풀에 좌우될 수 있지만 보다 기초적인 호스팅 프레임워크는 새로운 스레드가 필요할 때마다 그를 생성할 수 있음을 잘 알 것이다. 스케쥴의 코드는 그럭저럭 아무런 추정도 할 수 없다. 유의할 점은 비서비스 컨텍스트(예를 들어, 메소드에 대한 호출)에서의 첫 번째 중지 이벤트가 스케쥴이 행해질 때까지 사용되고 있는 스레드를 차단할 수 있다는 것이다.

메시지가 도달하여 특정 서비스로 보내지고 그 메시지를 기다리는 중지 수신(pausing receive)이 있는 것으로 밝혀진 경우, receive 문 이후의 본체를 보유하는 메소드가 런타임에 의해 호출될 수 있다. 이 호출 지점은 이제 새로운 재개 사이트(별칭은 "연속점(continuation point)")가 되며, 호출은 스케쥴이 다시 중지할 때까지 반환되지 않는다.

즉, 스케쥴은 데이터로서 노출된 대화 상태를 갖는 콜백으로서 구현되지만, 코드는 여전히 폴링 코드처럼 보이고, 이 때 대화의 흐름은 예시적인 VB.Net의 친숙한 언어 구문을 사용하여 선언된다.

본 발명에 따르면, 스케쥴 내에서의 메시지 처리 및 병렬성을 위해 적절한 언어 추가가 행해질 수 있지만, 대체로 스케쥴 코드는 통상의 VB 문으로 이루어져 있다. 루프 및 if문으로부터 예외 블록 및 변수 선언에 이르기까지 모든 것이 통상의 VB 문으로 이루어져 있다.

메시지 전송 및 수신

임의의 프로토콜 코드에서 가장 기초적인 동작은, 클라이언트 상에서인지 서버측 상에서 인지에 상관없이, 연결의 한쪽 단부에서 메시지를 전송하고 다른 쪽 단부에서 메시지를 수신하는 것이다.

처음부터의 동작을 살펴보면, 메시지가 수신될 수 있기 전에, 메시지가 전송되어야만 하고, 그렇게 하기 위한 구문은 아주 쉽다.

요청/응답 계약에 대해서는 앞서 기술하였다. send 문은 어떤 종류의 연결자를 가질 수 있다. 스케쥴이 서비스인 경우 연결자는 암시적이며, send는 1차 연결자를 통해 동작한다. 이 예에서, 클라이언트는 처음으로 서비스에 연결하고 있다.

유의할 점은 이전의 서비스 클라이언트 호출에서의 경우와 달리, send 문은 값을 반환하지 않는다는 것이다. 비동기 메시지 전달의 중요한 점은 모든 데이터 전달이 명시적으로 되어 있고, 따라서 어떤 양방향 통신도 각 단부에서 전송 및 수신을 필요로 한다는 것을 잘 알 것이다.

서비스측, 즉 실시측에서는, 메시지가 이렇게 처리된다.

유의할 점은 이 문에 연결자 참조가 없다는 것이다. 서비스는 그의 1차 연결자를 통해 메시지를 수신하게 된다. 응답하기 위해, 서비스는 계약 정의에 따라 결과를 다시 문자열 값으로 전송하게 된다.

주식 시세 서비스가 전적으로 믿을 수 없고 오히려 그의 데이터 획득 전략이 정적이라는 사실은 차치하고, 이것이 전부다. 이제, 메시지는 다른 쪽 단부에서 수신되어야만 한다. 예시한 바와 같이, 메시지 파라미터가 receive 문 밖에 있는 경우의 변수가 선언된다.

상기 예는 완전한 스케쥴 기반 애플리케이션을 나타낸 것이다. 전체 코드를 한 곳에 모은 것이 이하에 있다.

파일의 상단에 "Option Strict On" 등의 문을 추가함으로써(예를 들어, VB 통합은 현재 엄격한 방식의 컴파일(strict-mode compilation)을 요구함) 또는 서비스 클라이언트를 호출하기 위해 어떤 애플리케이션 코드를 추가함으로써, 어떤 추가의 구성없이 코드가 실행될 수 있음을 잘 알 것이다. 이 코드는 "sample-i" 디렉토리 밑에서 찾을 수 있다.

이들 문의 실행 모델에 따르면, receive 문이 실행되고 그에 일치하는 메시 지가 아직 이용가능하지 않을 때, 스케쥴은 중지된다, 예를 들어, 스케쥴이 사용하고 있는 스레드를 포기한다. 메시지가 이용가능한 경우, 스케쥴은 중지하지 않지만 실행은 즉각적으로 그 다음 라인에 대해 계속된다. send 문은 결코 중지하지 않는다. 메시지가 하부 시스템에 의해 접수되자마자, 그 문은 종료된다.

메시지가 스케쥴에 도달할 때, 런타임이 그 종류의 메시지를 기다리면서 스케쥴이 중지되어 있는 것을 발견하는 경우, 스케쥴은 즉각적으로, 일반적으로 런타임이 사용하고 있는 동일한 스레드 상에서 재개된다.

우리는 계약 언어로 표현될 수 있는 모든 강력한 프로토콜에 대해 이것이 충분하지 않은 것으로 잘못 생각할 수 있다. 예를 들어, 시스템이 동시에 들어오는 다양한 메시지, 예를 들어 동일한 상태로부터의 2개의 전이, 또는 다수의 무순서 메시지에 의한 트리거, 또는 분할 계약 정의를 기다리는 상황이 있다.

이들 대안적인 전이 상황을 해소하기 위해, VB 통합은 일련의 메시지 중에 하나를 수신하는 일을 처리하기 위해 "select" 문의 변형을 정의한다.

이 예시적인 코드에 따라, 2개의 메시지 "Request" 및 "ItsOverl" 중 단지 하나만이 이 문에서 수신된다. 그렇지만, 이하에 나타낸 바와 같이 A 및 B를 (임의의 순서로) 수신하거나 단지 C만을 수신하고자 하는 경우,

이하의 코드는 이 목적을 달성할 수 있다.

구체적으로는, receive 문을 동일한 라인 상에, 예를 들어 "select Receive" 내의 동일한 "Case" 문에 배치함으로써, 우리는 receive 문이 진행하기에 앞서 어떤 미정의된 순서로 메시지들 전부를 수신하도록 지정할 수 있다. 그의 들어오는 메시징 요구 사항 모두를 먼저 충족시키기 위한 경우가 궁극적으로 선택되는 경우이다. select-문에 관한 한, C가 A 뒤에 그렇지만 B 앞에 들어오는 경우, A는 장래의 어떤 다른 지점에서 수신가능하게 된다.

이제 CtRepeatedRequestResponse 계약을 구현하는 것을 살펴보자.

여기에서 주목할 만한 몇 가지 양상이 있다. 첫째, 동작 중인 "select Receive" 문이 예시되어 있지만, 그것은 또한 정규의 "Do" 루프 문 내에 내포되어 있다. 스케쥴의 포함에 관한 제한이 아주 적지만(예를 들어, "언어 제한"에 대해 이하에 기술함), 루프는 그에 속하지 않는다. 서비스 클라이언트에서, send/receives 근방에서 루프가 사용되며, 이 루프가 주식 시세에 대해 반복하여 질문하는 것이 허용된 사용자와 시스템이 상호작용하는 곳이다. 이 코드는 DVS 샘플 중에 샘플-2로서 이용가능하다.

이 예에 따르면, 서비스 클라이언트는 운에 맡긴 채 해보고 있다. 예를 들어, 서비스는 예를 들어 꼭 1분 동안 클라이언트로부터 아무것도 듣지 못한 후에 "ItsOver2()" 메시지가 적절한 것으로 생각할 때 그 메시지를 전송하는 것으로 가정하자. 여기서, 서비스 클라이언트는 또한 이 가능성을 처리하기 위해 "select Receive" 문을 사용할 수 있다.

서비스는 꼭 1 분 동안 메시지가 없었음을 검출할 수 있다. 예를 들어, 서비스는 이것이 클라이언트가 ItsOver1 메시지를 전송하지 않고 가버렸을 수도 있다는 나쁜 신호인지를 결정할 수 있다. 이러한 상황을 처리하는 어떤 방법이 필요하다. 전술한 바와 같이 세션 타임아웃이 유용하지만, 종종 너무 극단적이다.

오히려, 메시지가 도달하지 않는 상황에 대한 보다 미세한 제어를 달성하기 위해 타임아웃 구간이 "select Receive" 문에 배치될 수 있다.

구간의 유형은 System.TimeSpan일 수 있다. 상기 "FromMinutes" 메소드 호출은 그 유형에 대한 공유 메소드 중 하나이며, 이는 TimeSpan이 특정의 시간 단위(예를 들어, 초, 분, 시간)로부터 구성될 수 있게 해준다. System.TimeSpan에 대한 추가의 상세에 대해서는 .NET 프레임워크 문서를 참조하기 바란다.

"select Receive" 문의 정의는 TimeSpan이 0인 경우, 브랜치가 이미 도달된 메시지로부터 즉각적으로 만족될 수 없다면 타임아웃 브랜치를 택하고 기다린다는 것이다. 즉, 그것은 select-receive 문이 중지되지 않도록 하는 방법이다. 그에 의해 스케쥴은 어떤 메시지가 있는 경우 즉각적으로 처리되어야만 하는 그 메시지가 있는지 신속한 검사를 할 수 있다. 없는 경우, 스케쥴이 할 일은 더 많다.

유의할 점은 상기 예가 단지 세션이 타임아웃되게 하지 않으며 또 서비스 인스턴스가 없어지게 하지 않는다는 것이며, 오히려 상기 예는 "ItsOver2()" 메시지 를 클라이언트로 전송하여 클라이언트에 통지할 기회를 가지며, 느린 사용자를 기다리면 좋아지는 것은 당연하다. 이것은 훌륭한 "서비스 시민"이 되는 것(예를 들어, 그의 파트너들에게 그것이 사라지게 될 거라고 통지하는 것)의 일부이다.

분할 라인

"select Receive"이 단일 상태 전이를 트리거하는 대안들 및 무순서 메시지 그룹을 지원하기에 충분하였지만, 계약에서 분할을 지원할 때는 불편하다. 이 예에서, 계약 패턴이 다음과 같다고 가정하자.

수신측에서, 이것은 다음과 같이 코딩될 수 있다.

어느 메시지가 이미 수신되었는지(따라서 다시 보아서는 안 되는지)를 추적하기 위해 이러한 부기 모두가 어떻게 완료되어야만 하는지에 주목하기 바란다. 예시적인 VB 통합은 이러한 유형의 상황을 처리한다. 예를 들어,

여기에는 어떤 경우에도 부기 코드가 없다. 즉, 각각의 메시지 수신은 다른 것들에 독립적으로 처리될 수 있다.

"split" 문은 병행성의 복잡도에 신경쓰지 않고 VB 통합에 병렬성을 제공할 수 있다. 상기 문이 무엇을 의미하는지는 분할 라인이라고 하는 "split" 내의 3개의 내포된 블록이 서로 독립적으로, 예를 들어 병렬로 실행될 수 있다는 것이다.

그렇지만, 그 블록들은 동시에 실행되지 않으며, 앞서 기술한 중지 및 재개 프로세스를 통해 이의 관리에 주의를 기울인다. 분할 라인은 스케쥴 내의 모든 다른 라인들이 중지될 때까지 재개될 수 없다.

"split"가 실행될 때, 그의 분할 라인들 모두는 처음에 중지되었다가 이어서 분할 라인들은 선언의 순서로 재개된다. 이것은 첫 번째 분할 라인이 중지하지 않는 한, 스케쥴 내의 유일한 분할 라인이 실행된다는 것을 의미한다. 즉, 분할 라인들의 동기화는 암시적이며 중지를 통해 제어된다. 객체를 잠그거나 분할 라인들 사이에 버퍼를 도입하는 것에 관해 걱정할 필요가 없다. 오히려, 중지 이벤트 사이에서 현재의 분할 라인이 실행되고 있는 유일한 것이라는 것을 잘 알 것이다.

실제로, 임의의 형태의 그 자신의 스레드 관리를 스케쥴 내에 도입하는 것을 절대적으로 피할 수 있다. 그렇게 하는 것은 본 발명에 따른 스케쥴에 대한 기반으로서 기능하는 모델을 손상시키게 된다.

이제 분할 라인을 사용하여 상기의 반복하는 주식 시세 클라이언트를 어떻게 구현할 수 있는지에 대해 기술하는 양상을 살펴본다.

유의할 점은 첫 번째 분할 라인이 이전에 기술한 구현과 동일하다는 것이다. 유의할 점은 "Exit Split"가 추가된 것이 행해진 전부라는 것이다. 이것은 둘러싸 고 있는 "split" 문의 모든 분할 라인들을 종료하는 일반적인 "Exit" 문의 다른 변형이다. 두 번째 분할 라인은 "ItsOver2" 메시지를 기다리며, 이 메시지는 결코 도달하지 않을 수도 있다. 그 메시지가 도달하지 않은 경우, 첫 번째 라인은 그 문을 종료시킨다.

통합 클래스

다시 정규 스케쥴과 통합 클래스가 존재하는 경우 통합 클래스에 나타나는 스케쥴 간의 차이를 참조하면,

다음과 같이 이를 분해할 수 있다.

문제는 각각의 메소드가 그 자신의 스케쥴을 가지고 있기 때문에 완료될 때까지 "GetSingle" 호출이 차단된다는 것이다. 즉, 첫 번째 분할 라인 내에서, 호출은 응답 메시지를 기다리는 동안 양보하지 않으며, 두 번째 라인은 실행하게 되지 않는다. 근본적으로, 호출은 굶어죽게 된다. "GetSingle" 내의 Receive 문이 두 번째 라인 내의 것으로 조정되는 경우, 이 문제는 완화될 수 있다. 그것이 정확히 통합 클래스가 달성하는 것이다.

간단히 클래스 선언을 다음과 같이 변경함으로써,

원하는 거동이 달성될 수 있다. 즉, GetSingle 내의 Receive 문이 양보한다는 것은 분할 라인이 양보하고 두 번째 라인이 실행될 수 있다는 것을 의미한다.

대기

스케쥴 내에서의 또하나의 기본적인 동작은 설정된 기간 동안 기다리는 것이다. 그 시간의 상당 부분이 지연하면서 소비되는 모든 부류의 장기간 실행되는 서비스가 있다(통상 "후발 주자(procrastinator)" 패턴이라 함). 이들은 종종 모니터링 서비스이며, 이는 일반적으로 명령(예를 들어, 종료, 모니터 추가 등)이 있는지 리스닝하고 동시에 맥박 신호 또는 맥박 폴링 요청을 다른 서비스로 전송할 수 있다. 이제 다른 이유가 없다면 통상의 용어를 설정하기 위해 이들 개념을 참조한다.

장기간 동안 실행될 것으로 예상되는 어떤 서비스 또는 어떤 부류의 서비스들을 설계할 때, 우리는 일반적으로 다른 서비스들이 그 서비스가 여전히 이용가능한지 여부를 자동적으로 알아낼 수 있게 하는 어떤 종류의 인터페이스를 설계해야만 하고, 예방적 차원에서 그렇게 해야만 한다. 한 방법은 서비스에 도달하는 데 문제가 있는 모든 클라이언트가 어떤 중심 서비스에 정보를 전송하도록 하는 것이지만, 그렇게 하는 것은 클라이언트의 설계에 사용 경우(use case), 즉 클라이언트의 최초 목적과는 관계가 없는 사용 경우를 추가함으로써 클라이언트를 필요 이상으로 복잡하게 만들게 된다.

오히려, 그의 맥박, 즉 어떤 주파수로 모니터링 서비스로 전송되는 메시지가 있는지 리스닝함으로써 첫 번째 서비스가 이용가능한지 여부를 추적하는 모니터링 서비스가 생성된다.

일반적인 설계에서는 모니터링 서비스가 모니터링된 서비스에 그의 맥박을 한번 전송하도록 요청하거나 매 N초마다 그 맥박을 전송하기 시작하거나 또는 모니 터에게 얼마나 자주 맥박을 전송하려고 준비하는지를 말할 수 있다. 모니터링 서비스는 이어서 얼마동안 기다리는 루프를 사용하여 단발 맥박 요청(single-shot-heart-beat request)을 전송하거나 모니터링된 서비스에 맥박을 정규적으로 전송하도록 요청할 수 있다.

후자의 경우에, 모니터링 서비스는 "select Receive"를 사용하여 타임아웃 구간을 합의된 구간보다 약간 더 길게 설정한다. 맥박이 도달하면, 만사가 제대로이지만, 그 문이 타임아웃되면, 그것은 무언가 잘못되고 있다는 것을 나타내는 것이며, 모니터링 서비스는 어떤 형태의 경보를 송출할 수 있다.

보다 복잡한 구현이 맥박 메시지 상에 다른 정보를 피기백할 수 있고 이에 의해 오퍼레이터는 장기간 실행되는 서비스에 관한 통계를 얻을 수 있음을 잘 알 것이다.

통합에서 Wait가 문으로서 명시적으로 지원되지 않는 경우, 고정 시간 지연을 도입하는 것은 애플리케이션의 확장성에 파국적인 결과를 가져올 수 있다. 우리는 .NET 프레임워크 내의 API이지만 서비스의 실행 모델에 완전히 부적절한 Thread.Sleep()에 의존해야만 하며, 이럴 경우 병행성이 호스팅 환경의 런타임에 의해 관리되어야만 한다. Thread.Sleep()를 호출하는 것은 대기 동안 현재의 스레드를 묶어두게 된다. Wait를 호출하는 루프를 도는 서비스의 경우, 이것은 무기한으로 될 수 있다.

즉, 이러한 서비스는 스레드를 모두 그 자신에게 할당하게 된다. 이것은 대부분의 시간 미사용 상태로 있는 스레드와 관련된 것임을 이해할 것이다(예를 들 어, 일반적인 모니터링 스레드는 작업을 하는 데 100 마이크로초 걸릴 수 있으며 이어서 2분 동안의 슬립(sleep) 상태로 들어간다. 1분 동안 슬립 상태에 있고 100 마이크로초 동안 동작하는 스레드는 그의 시간의 99.9998%를 슬립 상태로 보낸다).

따라서, 이 모델에서는 지연의 필요성을 고려하는 것이 중요하다. 이것은 "Wait" 문으로 행해진다.

(명령이 있는지 리스닝하지 않는) 모니터링 서비스에서의 그의 사용을 예시하기 위해, 적당한 스케쥴이 이하에 있다.

유의할 점은 시스템이 루프의 본체를 실행하는 데 걸린 시간을 보상할 수 있다는 것이다. 이것은 대기 기간이 가능한 한 지정된 시간에 가깝도록 하기 위한 것이다.

Wait 문의 피연산자는 유형 System.TimeSpan일 수 있다.

동적 병렬성

Split 문에 의해 코드의 본체를 정의할 수 있는 반면, 코드의 n개의 라인을 병렬로 실행하기 위해 그것을 사용하는 방법이 없다. 이러한 동적 거동에 대한 경우는 엄격하며, 2가지 상이한 방식으로 지원된다.

1. Split-For-Each 문

2. Split-Select-Receive 문.

전자는 루프의 각각의 반복을 모든 다른 반복과 병렬로 수행한다는 점을 제외하고는 For-Each 문과 동일한 기본적인 의미를 갖는다. 즉, 반복되는 컬렉션에 있는 항목과 동수의 병렬 실행 라인이 있다. 이 횟수가 결정되면, 병렬 문(parallel statement)에 부가적인 라인이 추가될 수 없다. Split-For-Each는 Split와 동일한 "join" 규칙을 가지며, 모든 반복이 끝났을 때, Split-For-Each 문이 끝난다.

예로서,

이러한 문을 포함하는 통상의 For-Each에 비해 이것의 이점은 모든 Receive 문이 병렬로 대기한다는 것이다. send와 receive 사이의 지연이 클수록, 이것을 할 수 있는 것이 더 중요하게 된다.

"Split-Select-Receive"는 들어오는 메시지에 응답하여 병렬 실행의 새로운 라인을 동적으로 시작하는 데 사용될 수 있다. 한가지 변형은 멀티플렉싱된 대화에 대한 우리의 이해에 좌우되지만, 더 간단한 변형은 우리가 이러한 계약을 구현하는 일에 도움이 되는 것이다(A, B 및 C 모두 들어오는 메시지이다).

여기서, 계약에 의해 C를 받을 때까지 임의의 수의 인터리브된 <A, B> 시퀀스를 얻을 수 있으며, 그때 계약은 모든 B가 들어오기를 기다린다. 루프에서 Select-Receive 문을 사용하여 이것을 구현하는 것이 어려운데 왜냐하면 각각의 <A, B> 시퀀스가 모든 다른 것들과 독립적으로 처리되기 때문이다. 그렇지만, Split-Select-Receive는 사용할 수 있다.

문 내의 라인이 양보할 때마다, 새로운 라인이 생성되고, select 문이 그 새로운 라인에 대해 실행될 수 있다. 이것은 그 문이 결코 독립적으로 끝나지 않는다는 것을 의미한다(예를 들어, 항상 그 다음 메시지를 처리하기 위한 새로 들어온 실행 라인이 있다). 그 문에서 빠져나와서도 여전히 모든 이미 시작된 라인들이 실행될 수 있도록 하기 위해, 그 문 내의 어떤 코드가 "Finish Split" 문을 실행할 수 있다.

유의: 전술한 바를 고려하면, 실행 라인의 아이디어는 소스 코드 라인들을 참조하지 않으며 오히려 "실행 라인", 예를 들어 병렬 프로그램 내의 일련의 문을 참조한다.

종료(exit)

새로운 버전의 "Exit" 중 몇 개는 위에서 이미 설명하였지만, 이해를 돕기 위해 Exit가 무엇이고 Exit가 무엇을 하는지에 대한 요약이 이하에 제공되어 있다.

Exit Split

이것은 둘러싸고 있는 "split", "split-For-Each" 또는 "split-Select-Receive"의 모든 양보 라인들을 종료시키고 대응하는 "End" 또는 "Next" 문으로 넘어간다.

Exit Line

이것은 현재 라인(정적이든 동적이든 상관없음)을 종료시키지만 다른 어떤 것에도 영향을 주지 않는다.

필터

앞서 "Receive" 문에 대해 이야기할 때 메시지 필터에 대해서는 언급하지 않았다. 핸들러 매치를 단지 예외의 유형 이상의 것에 기초하기 위한 구절을 예외 핸들러에 배치하는 것과 유사하게, 그의 내용 또는 전역 상태 등의 어떤 특수 인자에 기초하여 메시지를 접수 또는 거부할 수 있게 하는 구절을 receive 문에 추가할 수 있다.

유의할 점은 계약 언어가 대응하는 조건을 지정하는 수단을 갖지 않기 때문에 메시지를 거부하기 위해 필터 표현을 사용하는 스케쥴은 프로세스에서 계약이 위반되지 않도록 할 수 있다는 것이다.

필터를 이용하는 것이 편리하며, 어떤 경우에 많은 메시지를 수신할 수 있지만 다른 경우에 그렇지 않을 때 특히 그렇다. 예를 들어,

이 문은 메시지 파라미터가 값 "OK"를 갖는 경우에만 메시지 A를 접수하고, 그렇지 않고 A 메시지 파라미터가 값 "ACK"를 갖는 경우에는 A 및 B를 수신한다. 이들 상황 중 어느 것도 참(true)이 아닌 경우, 이 문은 참이 될 때까지 기다린다. 따라서, 메시지가 사용되기 전에 필터는 여러 번 호출될 수 있으며, 따라서 그 문이 부작용없는 참 표현이 되는 것이 중요하다.

2차 연결자

전술한 바와 같이 서비스가 처음 시작될 때, 그 서비스는 명시적으로 언급하지 않아도 메시지를 전송 및 수신하는 데 사용될 수 있는 연결자를 할당받는다. 이 연결자는 서비스의 "1차" 연결자라고 한다. 1차 연결자는 클라이언트 연결자에 바인딩되어 있으며, 이 클라이언트 연결자를 통해 첫 번째 메시지가 서비스로 전송되었다. 1차 연결자는 그의 계약 상에서 항상 실시측 관점을 가질 수 있다.

임의의 다른 클라이언트와 마찬가지로, 활성화된 서비스가 클라이언트로서 다른 서비스와 통신하기를 원하는 경우, 그 서비스는 어떤 서비스 주소와 바인딩된 연결자 공장을 사용하여 그 공장으로부터 연결자를 생성하고 메시지를 전송하기 시작할 수 있다. 전술한 바와 같이, 연결자 공장에 의해 생성된 모든 연결자는 사용측 관점을 갖는다.

1차 연결자와 동일한 계약 상에 있든지 또는 어떤 다른 계약 상에 있는지 간에, 서비스가 다른 클라이언트들이 그와 대화를 개시할 수 있게 해주고 싶으면 어떻게 될까? 1차 연결자는 이미 바인딩되어 있고, 따라서 1차 연결자를 공유하는 것은 옵션이 아니다. 게다가, 어떤 다른 계약을 구현하고자 하는 경우, 어쨋든 1차 연결자는 아마도 쓸모없을 것이다.

대답은 실시측 관점을 갖는 2차 연결자가 생성되어야만 한다는 것이다. 서비스들에서의 모든 실시측 관점 연결자는 2차 연결자라고 한다. 서비스 밖에서는 모든 연결자들이 동등하며 1차도 2차도 아니다는 것을 잘 알 것이다. 새로운 2차 실시측 연결자를 생성하는 것에 대해서는 이하에서 설명한다.

여기서 주목할만한 것이 2가지 있다.

1. 변수 선언에서 유형 수정자로서 "Implements" 키워드를 사용할 수 있다. 이것은 선언된 변수에 실시측 관점을 부여한다.

2. 실제 연결자 객체는 어떤 서비스 참조도 갖지 않는 원하는 계약을 호출함으로써 생성될 수 있다. 이것은 오히려 유형 이름을 이상하게 사용한 것이지만, 그것이 2차 연결자를 생성하는 유일한 방법이다.

"Implements" 계약 유형 수정자는 연결자 변수가 클래스 또는 모듈 멤버로서 또는 메소드에 대한 파라미터로서 생성될 수 있을 때마다 사용될 수 있다. 한쪽 관점의 객체를 반대쪽 관점의 변수에 할당하려고 시도하는 것이 컴파일 시에는 실패할 수 있다. 유의할 점은 연결자-변수 할당의 규칙이 연결자-연결자 바인딩의 규칙의 정반대일 수 있다는 것이다. 즉, 연결자는 동일한 관점의 연결자를 할당받을 수 있을 뿐이지만, 연결자는 반대쪽 관점의 연결자에 바인딩되어야만 한다.

발견된 서비스 없음

이용가능한 서비스가 없음을 발견하는 방법에는 2가지가 있다. 첫째, TCP 주소가 유효하지 않을 수 있다. 즉, 포트가 열려있지 않고 서비스가 실제로 거기에 없다. 이 문제는 첫 번째 메시지를 그 서비스로 전송하려고 시도할 때 검출되며, 즉각 예외가 야기될 수 있다.

둘째, 메시지가 목적지에 도달할 수 있지만, 호스팅 환경이 서비스 이름 또 는 서비스 인스턴스를 알아보지 못한다. 이 경우, 메시지를 전송하는 스케쥴은 계속 살아있고 예외 던짐은 의미가 없다.

문제는 그 대신에 통합 클래스 내의 메소드를 오버라이드(override)함으로써 처리된다.

타임아웃

비동기 메시지를 한 스케쥴로부터 다른 스케쥴로 전송할 때, 응답이 수신될 거라는 보장이 없다. 이것이 일어날 수 있는 여러 가지 이유로서 하위 레벨 통신 실패 또는 예상된 것에 관한 클라이언트와 서버 간의 의견 불일치 등이 있지만 이에 한정되는 것은 아니다. 계약은 2개의 메시지 간의 최대 지연을 지정할 수 없으며, 따라서 계약이 2주 동안 요구하는 요청에 대해 응답하지 않는 서비스는 기술적으로는 그 계약을 파기하지 않은 것이다. 그의 스케쥴이 메시지를 먼저 전송하지 않고 종료된 경우에만 계약이 위반된 것이다.

이것은 우리가 서비스 및 서비스 클라이언트에 대한 스케쥴을 작성할 때 고려해야 하는 문제를 제공한다. 서비스가 수신을 기대할 수 있는 유일한 메시지는 첫 번째 메시지인데, 그 이유는 그 메시지 도착이 서비스가 처음으로 시작된 이유였기 때문이다. 서비스 클라이언트는 그 정도도 기대할 수 없다. 다행히, VB 통 합은 적당한 구현 도구를 제공한다.

개별적인 처리를 필요로 하는 2가지 상황이 있다.

1. 주어진 메시지가 도착하지 않은 경우, 스케쥴이 구현하는 계산 프로세스는 완전히 포기될 수 있다. 세션 타임아웃은 이 상황에 적합하고 추천되는데 왜냐하면 세션 타임아웃이 스케쥴 코드가 비대화되지 않도록 해주기 때문이다.

2. 주어진 메시지가 도착하지 않은 경우, 스케쥴은 그로부터 복구되어 디폴트 정보로 계속하거나 요청을 재전송하려고 시도하거나 또는 정보를 얻기 위해 어떤 다른 서비스와 접촉할 수 있다. 타임아웃 구간을 갖는 Select/Receive 문은 이 상황에 추천된다. 이들 상황에 대해서는 앞서 기술하였다.

유의할 점은 앞서 설명한 바와 같이 Select/Receive 문이 다수의 경우를 가질 필요가 없다는 것이다. Receive 문은 실제로 단일 경우를 갖는 보다 효율적으로 구현된(그렇지만 기능은 동등함) 버전의 Select/Receive이다.

즉,

은

와 동등하다.

이것을 알았으면, 메시지가 예상되었으나 도착하지 않을 때마다 receive 문에 타임아웃 구간을 추가함으로써 그것을 처리할 수 있음을 명백하다.

본 발명에 따르면, 이것이 발생할 경우 상황에 따라 2가지 대안이 이용가능하다. 그렇지만, 어떤 일반적인 가이드라인을 정의할 수 없다는 것에 유의해야 한다. 모든 것이 해결 중인 문제에 전적으로 달려 있다. 예를 들어,

ㆍ약간 더 오래 기다린다.

ㆍ응답이 파라미터가 없는 "확인 응답 스타일(acknowledgement-style)" 메시지인 경우, 확인 응답이 부정(또는 어떤 상황에서는 긍정)이라는 가정 하에 진행하기로 결정할 수 있다.

ㆍ응답 메시지가 그것 없이도 진행할 수 있는 것인 어떤 중요하지 않은 데이터를 다시 전송하는 경우, 아마도 도착하지 않은 데이터에 대한 어떤 디폴트 값을 사용하여 그렇게 한다. 아마도 웹 서비스는 패스포트 유사 서비스로부터 개인화 데이터를 찾고 있지만, 아무것도 없는 경우 웹 서비스는 제한된 개인화를 사용하여 진행한다.

ㆍ기다리고 있었던 메시지를 서비스로 재전송하려고 시도한다.

ㆍ정보를 얻기 위해 연결할 수 있는 어떤 다른 서비스 또는 동일한 서비스의 또하나의 인스턴스를 찾는다.

이것을 하기 위한 방법들은 물론 상황에 따라 변한다. 계약 자체가 어떤 메시지가 도착하지 않을 수 있다는 사실에 대처하지 않은 경우, 그 경우에 큰 문제가 있다는 것은 상기 첫 번째 전송을 제외하고는 모두에게 공통된 것이다. 스케쥴이 존재할 때, 그의 수명 동안에 생성된 각각의 연결자는 그 연결자를 통해 행해진 메시지 교환이 완료되었는지 여부를 확인하기 위해 검사된다. "끝나지 않은" 어떤 연결자도 그의 계약을 위반한 것으로 생각되고 예외가 던져진다. 수신했어야 하는 메시지를 수신하지 않은 경우, 어딘가에 에러가 있으며 런타임은 그것을 단순히 무시할 수 없는데, 그 이유는 그것이 스케쥴에 얼마나 중요한지를 알아낼 방법이 없기 때문이다. 그렇지만, 그를 통해 메시지가 도착하지 않은 연결자를 폐기시킴으로써, 스케쥴은 런타임이 그 특정 연결자에 관한 계약을 유효화해서는 안된다고 런타임에 통지한다.

그렇지만, 연결자를 폐기하는 것은 또한 그 연결자에 대해 다른 어떤 조치도 취할 수 없음을 의미한다. 그 연결자에 메시지를 전송할 수도 없고 그로부터 메시지를 수신할 수도 없다. 시도하면, 에러가 발생한다.

유의할 점은 select 문 상의 타임아웃 구간은 일군의 문을 실행하는 데 걸리 는 총 시간에 대한 상한을 설정하지 않고 하나의 문이 메시지를 기다리는 시간만을 설정한다는 것이다. 전자를 행하기 위해, split 및 wait 문을 이용할 수 있다.

VB 통합이 실시간 거동을 요구하지 않기 때문에, 이것이 지정된 2분보다 더 걸리지는 않을 거라는 보장이 없다. 두 번째 라인이 중지 이벤트에 도달할 때만 split 문이 실제로 종료하고 "End Split" 다음에 오는 문이 실행된다.

비스케쥴 코드와의 상호작용

비동기 프로그래밍을 위해 send 및 receive 문을 사용하는 것이 옳은 해결책이 아닐 수도 있는 상황들이 있다. 어떤 상황에서는, 스케쥴의 단일 스레드 차단 특성이 멋진 해결책에 방해가 되거나, 특성상 스케쥴 구동이 아닌 어떤 UI 코드를 가질 필요가 있을 수 있다.

좋은 소식은 이들 상황에서조차도 버튼 누름 이벤트 등의 무언가를 서비스 또는 서비스 클라이언트로의 메시지로 변환하는 얇은 코드 레이어(thin layer of code)를 작성하는 것이 용이하다는 것이다. 요약하면, 비동기 프로그래밍은 이벤트-기반 그래픽 UI 프로그래밍과 잘 어울린다.

2개의 패러다임, 이벤트 기반과 스케쥴 기반 사이의 이러한 가교를 실현하기 위해, VB 통합은 비스케쥴 코드가 들어오는 메시지를 전송하고 이를 이벤트에 매핑할 수 있게 해준다. 따라서, 메시지는 스케쥴 및 그의 차단 의미 없이도 앞뒤로 교환될 수 있다.

계약 내의 각 메시지의 결과 이벤트가 그 유형에 추가된다. .NET에서는 메소드 및 이벤트가 오버로드될 수 없기 때문에, 이벤트 이름은 문자열 "Event"가 그에 직접 첨부되어 있는 메시지의 이름이다. 메소드는 메시지와 정확히 동일한 이름을 갖는다.

예로서,

이하에 검사되는 샘플 애플리케이션에서, 메시지 교환은 그래픽 UI 상호작용과 특히 관련이 있는 이러한 방식으로 이용된다.

그래픽 사용자 인터페이스

Win32 기반 그래픽 사용자 인터페이스는 디스플레이할 새로운 데이터에 컨트롤을 제공하는 것과 같은 어떤 일을 하는 데 무슨 스레드가 사용되는지에 관한 것일 때 특별한 요구 사항을 갖는다. 모든 컨트롤이 이러한 필요성을 갖는 것은 아니지만, 어떤 컨트롤은 그럴 필요가 있으며, 우리는 그것에 대처해야 한다. 스케쥴 및 개개의 연결자 둘다는 스레드에서 또는 연결자를 통해 수신되는 모든 메시지가 특정 UI 스레드의 컨텍스트에서 수신되도록 UI 스레드에 부착될 수 있다.

이 특징은 사용하지 쉽지만 그 특징이 실제로 요구되는 상황에만 한정되어야 한다. 스케쥴 코드를 단일 스레드에 강제로 집어넣는 것은 병행성의 기회를 제한하며 따라서 잠재적인 성능 병목 현상이 된다는 것을 잘 알 것이다.

두 번째 문은 그 문이 반환되면 그 연결자를 통해 수신된 모든 메시지가 그 폼의 소유 스레드를 통해 도착하도록 한다. 유의할 점은 서비스의 1차 연결자를 통해서도 이렇게 할 수 있다는 것이다(이것은 1차 연결자를 명시적으로 참조하는 몇 가지 적당한 경우 중 하나이다).

그렇지만, 아마도 서비스 및 서비스 클라이언트가 UI 코드를 직접 호출하지 않지만 메시지를 포함하는 폼으로 메시지를 전송할 것이며, 이는 아마도 비스케쥴 연결자에 대해서는 제어 스레드를 설정하는 것이 타당하다는 것을 의미한다.

이하는 "SetControl()"을 사용할 때의 예이다.

connector1 및 connector2 둘 모두 동일한 소유 스레드에 바인딩되어 있지 않은 한, 이 경우에 메시지 수신은 (스레드에 관하여) 비결정적이다. 그 경우에 스레드 정보는 어느 한 연결자로부터 풀링될 수 있다는 것을 잘 알 것이다. 따라서, 케이스 내의 모든 연결자가 동일한 소유 스레드에 바인딩되도록 하거나 스케쥴이 그 소유 스레드에 바인딩되도록 하는 것이 중요하다.

동작 가능 컴퓨팅 환경

이제 도 7을 참조하면, 개시된 아키텍처를 실행하는 동작을 하는 컴퓨터의 블록도가 예시되어 있다. 본 발명의 여러 가지 양상들에 대한 부가적인 컨텍스트를 제공하기 위해, 도 7 및 이하의 설명은 본 발명의 여러가지 양상들이 구현될 수 있는 적당한 컴퓨팅 환경(700)에 대한 간단하고 일반적인 설명을 제공하기 위한 것이다. 본 발명이 하나 이상의 컴퓨터 상에서 실행될 수 있는 컴퓨터 실행가능 명령어의 일반적인 관점에서 전술되어 있지만, 당업자라면 본 발명이 기타 프로그램 모듈과 결합하여 및/또는 하드웨어와 소프트웨어의 조합으로서 구현될 수도 있음을 잘 알 것이다.

일반적으로, 프로그램 모듈은 특정의 작업을 수행하거나 특정의 추상 데이터 유형을 구현하는 루틴, 프로그램, 컴포넌트, 데이터 구조, 기타 등등을 포함한다. 게다가, 당업자라면 본 발명의 방법이 퍼스널 컴퓨터, 핸드헬드 컴퓨팅 장치, 마이크로프로세서기반 또는 프로그램가능 가전 기기 뿐만 아니라 단일-프로세서 또는 멀티프로세서 컴퓨터 시스템, 미니컴퓨터, 메인프레임 컴퓨터, 및 기타 등등을 비롯한 다른 컴퓨터 시스템 구성으로 실시될 수 있고, 이들 각각이 하나 이상의 관련 장치와 연결되어 동작될 수 있음을 잘 알 것이다.

본 발명의 예시된 양상들은 또한 어떤 작업들이 통신 네트워크를 통해 연결되어 있는 원격 프로세싱 장치들에 의해 수행되는 분산 컴퓨팅 환경에서 실시될 수 있다. 분산 컴퓨팅 환경에서, 프로그램 모듈은 로컬 및 원격 메모리 저장 장치 둘다에 위치될 수 있다.

컴퓨터는 일반적으로 다양한 컴퓨터 판독가능 매체를 포함한다. 컴퓨터 판독가능 매체는 컴퓨터에 의해 액세스될 수 있는 임의의 이용가능한 매체일 수 있으며, 휘발성 및 비휘발성 매체, 분리형 및 비분리형 매체 둘다를 포함한다. 제한이 아닌 예로서, 컴퓨터 판독가능 매체는 컴퓨터 저장 매체 및 통신 매체를 포함할 수 있다. 컴퓨터 저장 매체는 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈 또는 기타 데이터 등의 정보의 저장을 위한 임의의 방법 또는 기술로 구현된 휘발성 및 비휘발성, 분리형 및 비분리형 매체 둘다를 포함한다. 컴퓨터 저장 매체는 RAM, ROM, EEPROM, 플래쉬 메모리나 기타 메모리 기술, CD-ROM, DVD(digital video disk)나 기타 광학 디스크 저장 장치, 자기 카세트, 자기 테이프, 자기 디스크 저장 장치나 기타 자기 저장 장치, 또는 원하는 정보를 저장하는 데 사용될 수 있고 또 컴퓨터에 의해 액세스될 수 있는 임의의 다른 매체를 포함하지만 이에 한정되는 것은 아니다.

통신 매체는 일반적으로 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈 또는 기타 데이터를 반송파 또는 기타 전송 메커니즘 등의 변조된 데이터 신호에 구현하며, 임의의 정보 전달 매체를 포함한다. 용어 "변조된 데이터 신호"는 신호에 정보를 인코딩하는 방식으로 신호의 특성 중 하나 이상이 설정 또는 변경된 신호를 의미한다. 제한이 아닌 예로서, 통신 매체는 유선 네트워크 또는 직접 유선 연결 등의 유선 매체, 및 음향, RF, 적외선 및 기타 무선 매체 등의 무선 매체를 포함한다. 상기한 것 중 임의의 것의 조합도 컴퓨터 판독가능 매체의 범위 내에 포함되어야 한다.

다시 도 7을 참조하면, 컴퓨터(702)를 포함하는 본 발명의 여러 가지 양상들을 구현하는 예시적인 환경(700)이 예시되어 있으며, 컴퓨터(702)는 프로세싱 유닛(704), 시스템 메모리(706) 및 시스템 버스(708)를 포함한다. 시스템 버스(708)는 시스템 메모리(706)(이에 한정되는 것은 아님)를 비롯한 시스템 컴포넌트들을 프로세싱 유닛(704)에 연결한다. 프로세싱 유닛(704)은 여러 가지 상용 프로세서 중 임의의 것일 수 있다. 듀얼 마이크로프로세서 및 기타 멀티프로세서 아키텍처도 프로세싱 유닛(704)으로서 이용될 수 있다.

시스템 버스(708)는 추가로 메모리 버스(메모리 컨트롤러를 갖거나 갖지 않음), 주변 버스, 및 다양한 상용 버스 아키텍처 중 임의의 것을 사용하는 로컬 버스에 상호 연결될 수 있는 몇 가지 유형의 버스 구조 중 임의의 것일 수 있다. 시 스템 메모리(706)는 판독 전용 메모리(ROM)(710) 및 랜덤 액세스 메모리(RAM)(712)를 포함한다. 기본 입/출력 시스템(BIOS)은 ROM, EPROM, EEPROM 등의 비휘발성 메모리(710)에 저장되어 있으며, 이 BIOS는 시동 중과 같은 때에 컴퓨터(702) 내의 구성요소들 간의 정보 전송을 돕는 기본적인 루틴을 포함한다. RAM(712)은 또한 데이터를 캐싱하기 위한 정적 RAM 등의 고속 RAM을 포함할 수 있다.

컴퓨터(702)는 내장형 하드 디스크 드라이브(HDD)(714)(예를 들어, EIDE, SATA)(이 내장형 하드 디스크 드라이브(714)는 또한 적당한 새시(도시 생략)에서 외장형으로 사용하도록 구성될 수도 있음), 자기 플로피 디스크 드라이브(FDD)(716)(예를 들어, 분리형 디스켓(718)으로부터 판독하거나 그에 기록하기 위한 것임), 및 광학 디스크 드라이브(720)(예를 들면, CD-ROM 디스크(722)를 판독하거나 DVD 등의 다른 고용량 광학 매체로부터 판독하거나 그에 기록하기 위한 것임)를 더 포함한다. 하드 디스크 드라이브(714), 자기 디스크 드라이브(716) 및 광학 디스크 드라이브(720)는 각각 하드 디스크 드라이브 인터페이스(724), 자기 디스크 드라이브 인터페이스(726) 및 광학 드라이브 인터페이스(728)에 의해 시스템 버스(708)에 연결될 수 있다. 외장형 드라이브 구현을 위한 인터페이스(724)는 USB(유니버설 직렬 버스) 및 IEEE 1394 인터페이스 기술 중 적어도 하나 또는 그 둘 다를 포함한다.

드라이브 및 그와 관련된 컴퓨터 판독가능 매체는 데이터, 데이터 구조, 컴퓨터 실행가능 명령어, 및 기타 등등의 비휘발성 저장을 제공한다. 컴퓨터(702)의 경우, 드라이브 및 매체는 적당한 디지털 포맷으로 임의의 데이터를 저장하는 것을 제공한다. 이상에서 컴퓨터 판독가능 매체에 대한 설명이 HDD, 분리형 자기 디스켓, 및 CD나 DVD 등의 분리형 광학 매체를 언급하고 있지만, 당업자라면 집(zip) 드라이브, 자기 카세트, 플래쉬 메모리 카드, 카트리지, 및 기타 등등과 같은 컴퓨터에 의해 판독가능한 다른 유형의 매체도 역시 예시적인 운영 환경에서 사용될 수 있으며 또한 임의의 이러한 매체가 본 발명의 방법을 수행하기 위한 컴퓨터 실행가능 명령어를 포함할 수 있음을 잘 알 것이다.

운영 시스템(730), 하나 이상의 애플리케이션 프로그램(732), 기타 프로그램 모듈(734), 및 프로그램 데이터(736)를 비롯한 다수의 프로그램 모듈이 드라이브 및 RAM(712)에 저장될 수 있다. 운영 시스템, 애플리케이션, 모듈, 및/또는 데이터의 전부 또는 일부분도 역시 RAM(712)에 캐싱될 수 있다.

본 발명이 여러 가지 상용 운영 시스템 또는 운영 시스템들의 조합으로 구현될 수 있음을 잘 알 것이다.

사용자는 하나 이상의 유선/무선 입력 장치, 예를 들어 키보드(738) 및 마우스(740) 등의 포인팅 장치를 통해 명령 및 정보를 컴퓨터(702)에 입력할 수 있다. 다른 입력 장치(도시 생략)는 마이크로폰, IR 리모콘, 조이스틱, 게임 패드, 스타일러스 펜, 터치 스크린 또는 기타 등등을 포함할 수 있다. 이들 및 다른 입력 장치는 종종 시스템 버스(708)에 연결된 입력 장치 인터페이스(742)를 통해 프로세싱 유닛(704)에 연결되지만, 병렬 포트, IEEE 1394 직렬 포트, 게임 포트, USB 포트, IR 인터페이스 등등과 같은 다른 인터페이스에 의해 연결될 수 있다.

모니터(744) 또는 다른 유형의 디스플레이 장치도 역시 비디오 어댑터(746) 등의 인터페이스를 통해 시스템 버스(708)에 연결된다. 모니터(744) 이외에, 컴퓨터는 일반적으로 스피커, 프린터 등과 같은 다른 주변 출력 장치(도시 생략)를 포함한다.

컴퓨터(702)는 원격 컴퓨터(들)(748) 등의 하나 이상의 원격 컴퓨터로의 유선 및/또는 무선 통신을 통한 논리적 연결을 사용하여 네트워크화된 환경에서 동작할 수 있다. 원격 컴퓨터(들)(748)는 워크스테이션, 서버 컴퓨터, 라우터, 퍼스널 컴퓨터, 휴대용 컴퓨터, 마이크로프로세서 기반 오락 가전기기, 피어 장치 또는 다른 통상의 네트워크 노드일 수 있으며, 일반적으로 컴퓨터(702)와 관련하여 기술된 구성요소들의 대부분 또는 그 전부를 포함하지만, 간략함을 위해 단지 메모리 저장 장치(750)만이 예시되어 있다. 도시된 논리적 연결은 근거리 통신망(LAN)(752) 및/또는 보다 대규모의 네트워크, 예를 들어 광역 통신망(WAN)(754)으로의 유선/무선 연결을 포함한다. 이러한 LAN 및 WAN 네트워킹 환경은 사무실 및 회사에서 통상적인 것이며, 인트라넷 등의 기업 규모 컴퓨터 네트워크를 용이하게 해주고, 이들 모두는 글로벌 통신 네트워크, 예를 들어 인터넷에 연결될 수 있다.

LAN 네트워킹 환경에서 사용될 때, 컴퓨터(702)는 유선 및/또는 무선 통신 네트워크 인터페이스 또는 어댑터(756)를 통해 로컬 네트워크(752)에 연결된다. 어댑터(756)는 LAN(752)으로의 유선 또는 무선 통신을 용이하게 해줄 수 있으며, 이는 또한 무선 어댑터(756)와 통신하기 위해 배치되어 있는 무선 액세스 포인트를 포함할 수 있다. WAN 네트워킹 환경에서 사용될 때, 컴퓨터(702)는 모뎀(758)을 포함할 수 있거나, LAN 상의 통신 서버에 연결되거나, 인터넷을 통하는 등의 WAN(754)을 통한 통신을 설정하기 위한 다른 수단을 갖는다. 내장형 또는 외장형이고 유선 또는 무선 장치일 수 있는 모뎀(758)은 직렬 포트 인터페이스(742)를 통해 시스템 버스(708)에 연결된다. 네트워크화된 환경에서, 컴퓨터(702)와 관련하여 도시된 프로그램 모듈 또는 그의 일부분은 원격 메모리/저장 장치(750)에 저장될 수 있다. 도시된 네트워크 연결이 예시적인 것이고 또 컴퓨터들 간의 통신 링크를 설정하는 다른 수단이 사용될 수 있음을 잘 알 것이다.

컴퓨터(702)는 무선 통신에 배치되어 동작하는 임의의 무선 장치 또는 엔티티, 예를 들어 프린터, 스캐너, 데스크톱 및/또는 휴대용 컴퓨터, 개인 휴대 단말기, 통신 위성, 무선 검출가능 태그와 관련된 임의의 장비 또는 장소(예를 들어, 키오스크, 뉴스 스탠드, 휴게실), 및 전화와 통신하는 동작을 한다. 이것은 적어도 Wi-Fi 및 블루투스

무선 기술을 포함한다. 따라서, 통신은 종래의 네트워크 또는 단순히 적어도 2개의 장치 간의 애드 혹 통신(ad hoc communication)에서와 같이 소정의 구조일 수 있다.

Wi-Fi(Wireless Fidelity)는 유선없이 가정의 소파, 호텔방의 침대 또는 회사의 회의실로부터 인터넷으로의 연결을 가능하게 해준다. Wi-Fi는 이러한 장치, 예를 들어 컴퓨터가 실내 및 실외에서, 기지국 통화권 내의 어느 곳에서라도 데이터를 전송 및 수신할 수 있게 하는 셀 전화와 같은 무선 기술이다. Wi-Fi 네트워크는 안전하고 신뢰성있으며 고속의 무선 연결을 제공하기 위해 IEEE 802.11(a, b, g 등)이라고 하는 무선 기술을 사용한다. Wi-Fi 네트워크는 컴퓨터를 서로 연결, 인터넷에 연결 및 (IEEE 802.3 또는 이더넷을 사용하는) 유선 네트워크에 연결하는 데 사용될 수 있다. Wi-Fi 네트워크는 비허가 2.4 및 5GHz 무선 대역에서 동작하며, 11Mbps(802.11b) 또는 54Mbps(802.11a) 데이터 레이트를 가지거나 두 대역(듀얼 밴드) 모두를 포함하는 제품이 있다. 따라서, 이 네트워크는 많은 사무실에서 사용되는 기본적인 10BaseT 유선 이더넷 네트워크와 유사한 실세계 성능을 제공할 수 있다.

이제 도 8을 참조하면, 본 발명에 따른 예시적인 컴퓨팅 환경(800)의 개략 블록도가 도시되어 있다. 시스템(800)은 하나 이상의 클라이언트(들)(802)를 포함한다. 클라이언트(들)(802)는 하드웨어 및/또는 소프트웨어(예를 들어, 스레드, 프로세스, 컴퓨팅 장치)일 수 있다. 클라이언트(들)(802)는 예를 들어 본 발명을 이용함으로써 쿠키(들) 및/또는 관련 컨텍스트 정보를 보관할 수 있다. 시스템(800)은 또한 하나 이상의 서버(들)(804)를 포함한다. 서버(들)(804)도 역시 하드웨어 및/또는 소프트웨어(예를 들어, 스레드, 프로세스, 컴퓨팅 장치)일 수 있다. 서버(804)는 예를 들어 본 발명을 이용함으로써 변환을 수행하기 위해 스레드를 보관할 수 있다. 클라이언트(802)와 서버(804) 사이의 한가지 가능한 통신은 2개 이상의 컴퓨터 프로세스 간에 전송되도록 구성된 데이터 패킷의 형태일 수 있다. 데이터 패킷은 예를 들어 쿠키 및/또는 관련 컨텍스트 정보를 포함할 수 있다. 시스템(800)은 클라이언트(들)(802)와 서버(들)(804) 사이의 통신을 용이하게 해주기 위해 이용될 수 있는 통신 프레임워크(806)(예를 들어, 인터넷 등의 글로벌 통신 네트워크)를 포함한다.

통신은 유선(광섬유 포함) 및/또는 무선 기술을 통해 용이하게 행해질 수 있 다. 클라이언트(들)(802)는 클라이언트(들)(802)에 로컬인 정보(예를 들어, 쿠키(들) 및/또는 관련 컨텍스트 정보)를 저장하는 데 하나 이상의 클라이언트 데이터 스토어(들)(808)에 연결되어 동작한다. 이와 유사하게, 서버(들)(804)는 서버(804)에 로컬인 정보를 저장하는 데 이용될 수 있는 하나 이상의 서버 데이터 스토어(들)(810)에 연결되어 동작한다.

부록 A는 본 발명의 여러 가지 양상을 기술한 것이며, 이 부록은 본 출원의 상세한 설명의 일부로서 간주되어야 한다.

이상에서 기술한 바가 본 발명의 예들을 포함한다. 물론, 본 발명의 설명을 위해 컴포넌트 또는 방법의 모든 가능한 조합을 기술할 수는 없지만, 당업자라면 본 발명의 많은 추가의 조합 및 대체가 가능함을 잘 알 것이다. 따라서, 본 발명은 첨부된 청구항들의 정신 및 범위 내에 속하는 모든 이러한 변경, 수정 및 변형을 포괄하는 것이다. 게다가, 상세한 설명이나 청구항에서 용어 "포함한다"가 사용되는 한, 이러한 용어는 용어 "포함한다"가 청구항에서 이행구로서 이용될 때 해석되는 것과 마찬가지로 포괄적으로 보아야 한다.

본 발명에 의하면, 주류 객체 지향(OO) 언어에서 직접 병행성의 고수준 추상화를 제공하며, 다수의 서비스들 간의 통신을 동시에 관리하기 위한 메커니즘(예를 들어, 통합(orchestration))을 이용하는 비동기 메시지 전달의 도입을 통해 올바른 병행 프로그램을 작성하는 일이 간단하도록 하기 위한 병행성 모델을 제공할 수 있다.

Claims (30)

1. 메시지 지향 언어로 언어 확장들을 이용함으로써 - 상기 언어 확장들은, 복수의 서비스들 간의 메시지 전달을 통해 객체 지향 언어와 메시지 지향 언어를 통합하기 위해 객체 지향 환경에서 실행하는 서비스들의 기능을 확장시킴 - 객체 지향 언어를 이용하여 구성된 서비스들에 대하여 서비스 병행성(concurrency) 모델을 구현하기 위한 시스템으로서,

   메모리; 및

   컴퓨터 실행가능 컴포넌트들을 실행시키는, 상기 메모리에 연동된 프로세서

   를 포함하고,

   상기 컴퓨터 실행가능 컴포넌트들은,

   상기 객체 지향 언어를 이용하여 구성된 복수의 서비스들;

   상기 복수의 서비스들 간의 통신을 용이하게 하는 계약 컴포넌트(contract component); 및

   상기 계약 컴포넌트를 해석하고 상기 복수의 서비스들에서 복수의 메시지들 및 복수의 메시지 타겟들의 처리를 용이하게 하도록 구성된 통합 컴포넌트(orchestration component)

   를 포함하고,

   상기 계약 컴포넌트는 상기 복수의 서비스들 간의 비동기 메시지 전달에 대한 인터페이스 선언들로서 정의되고, 상기 복수의 서비스들 각각의 소스 코드 내에서 익스프레스(express) 전송 및 수신 동작들로서 나타나며, 상기 계약 컴포넌트는,

   통신 프로토콜에 대한 형식을 갖춘(formal) 프로토콜 정의들을 확립하는 데에 이용되는 패턴들에 대한 알파벳으로서 사용될 수 있는 메시지들의 집합을 선언하는 메시지 컴포넌트; 및

   통신 프로토콜에 대한 형식을 갖춘 프로토콜 정의들에 따라 허용가능한 메시지 교환 시퀀스를 기술하는 프로토콜 컴포넌트

   를 포함하고,

   상기 통합 컴포넌트는,

   상기 복수의 서비스들의 스레드 컨텍스트(thread context)를 차단하지 않고 병렬 대기(parallel wait)가 일어날 수 있도록 하기 위해 상기 서비스들의 소스 코드를 조각들로 분해하는 컴파일 알고리즘(compilation algorithm)을 구현하도록 구성된 컴파일러 컴포넌트(compiler component)

   를 포함하고,

   상기 컴파일 알고리즘은, 스레드를 차단할 수 있는 소스 코드를 분리(breaking apart)하여, 상기 소스 코드 내의 다수의 지점들이 병렬로 대기할 수 있거나 스레드 컨텍스트가 다른 계산을 계속할 수 있게 하고,

   상기 통합 컴포넌트는, 상기 컴파일러 컴포넌트가 상기 계약 컴포넌트에 따라 상기 복수의 서비스들의 적어도 부분집합에 대해 스케쥴을 생성하도록 지시하고,

   상기 스케쥴은, 상기 부분집합 내의 서비스들이 상기 부분집합 내의 다른 서비스들과 병렬로 대기하게 함으로써 서비스들의 상기 부분집합의 병렬성(parallelism)을 용이하게 하는 시스템.
2. 제1항에 있어서,

   상기 프로토콜 컴포넌트는, 비동기 메시지 컴포넌트의 유효 시퀀스를 지정하는 순서를 식별하는 패턴 컴포넌트를 포함하는 시스템.
3. 제1항에 있어서,

   상기 계약 컴포넌트는, 적어도 하나의 메소드 호출 컴포넌트 및 상기 적어도 하나의 메소드 호출 컴포넌트의 유효 시퀀스를 지정하는 순서를 식별하는 패턴 컴포넌트를 포함하는 시스템.
4. 제3항에 있어서,

   상기 유효 시퀀스는, 상기 적어도 하나의 메소드 호출 컴포넌트에서의 메소드 호출의 적어도 하나의 실행 시에 양보점(yield point)을 식별하고, 양보된 메소드 호출을 지나서 메소드 호출의 적어도 하나의 다른 것의 실행이 진행하도록 허용하는 시스템.
5. 제1항에 있어서,

   상기 계약 컴포넌트에 적어도 하나의 부가적인 메시지를 추가하기 위해 상기 계약 컴포넌트를 확장하는 계약 확장 컴포넌트(contract extension component)를 더 포함하는 시스템.
6. 제5항에 있어서,

   상기 계약 확장 컴포넌트는 상기 계약 컴포넌트에 적어도 하나의 부가적인 상태를 추가하기 위해 상기 계약 컴포넌트를 확장하는 시스템.
7. 제5항에 있어서,

   상기 계약 확장 컴포넌트는 상기 계약 컴포넌트에 적어도 하나의 부가적인 트리거를 추가하기 위해 상기 계약 컴포넌트를 확장하는 시스템.
8. 제1항에 있어서,

   상기 서비스들의 부분집합으로부터의 서비스는, 다른 서비스들의 실행의 차단을 방지하기 위해 다른 서비스들과 독립적으로 병렬로 대기하는 시스템.
9. 프로세서 및 시스템 메모리를 포함하는 컴퓨터 시스템에서, 객체 지향 코드에서 나타나는 복수의 서비스들 간의 병행성을 구현하기 위해 상기 컴퓨터 시스템에 의해 실행되는 방법으로서,

   상기 복수의 서비스들 중의 타겟 서비스들 간에 전송되는 정보를 동기화하여 상기 타겟 서비스들의 병행성을 구현하기 위한, 상기 복수의 서비스들에 외부적인 계약을 선언하는 단계 - 상기 계약은,

   타겟 서비스들 간의 정보의 동기화를 위한 복수의 메시지들, 및

   상기 타겟 서비스들의 부분집합 간의 메시지 순서화

   를 선언함 - ; 및

   상기 타겟 서비스들의 부분집합 간의 상기 외부적인 계약에 따라 메시지 순서화를 시행하는 단계

   를 포함하고,

   상기 메시지 순서화를 시행하는 단계는, 상기 타겟 서비스들의 부분집합 간의 비동기 정보를 통합하여 타겟 서비스들의 병행성을 용이하게 하고,

   상기 메시지 순서화를 시행하는 단계는,

   상기 타겟 서비스들의 부분집합 내의 제1 서비스가 상기 타겟 서비스들의 부분집합 내의 제2 서비스에 메시지를 전송하는 단계 - 상기 메시지는 상기 외부적인 계약에 대한 데이터의 공유 및 동기화를 성취하기 위해 병렬 방식으로 상기 복수의 서비스들을 조직하는 구현 스케쥴을 식별하는 페이로드(payload)를 포함하고, 상기 스케쥴은 둘 이상의 비동기 메시지를 병렬로 대기하는 것을 허용함으로써 서비스들의 스레드 컨텍스트의 차단을 방지하고, 상기 페이로드는 상기 제1 서비스 및 상기 제2 서비스가 다른 서비스들을 차단하지 않고 대기해야 할 때를 나타냄 - ,

   상기 제2 서비스가 상기 제1 서비스로부터 상기 메시지를 수신하는 단계, 및

   상기 제2 서비스가 상기 페이로드를 채용하기 위해 상기 메시지를 역컴파일(decompiling)하고 상기 계약에 대해 상기 스케쥴을 구현하는 단계

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

    상기 계약을 선언하는 단계는, 적어도 하나의 비동기 메시지를 선언하는 단계를 포함하는 방법.
11. 제10항에 있어서,

    상기 계약을 선언하는 단계는, 적어도 하나의 비동기 메시지의 실행을 위한 패턴을 지정하는 단계를 포함하는 방법.
12. 제10항에 있어서,

    상기 계약을 시행하는 것은 적어도 하나의 비동기 메시지의 실행을 위한 트리거를 지정하는 것을 포함하는 방법.
13. 제10항에 있어서,

    상기 계약을 시행하는 것은,

    스케쥴의 생성을 용이하게 하기 위해 상기 계약을 분석(dissect)하는 것;

    상기 스케쥴을 생성하기 위해 분석된 상기 계약을 분할(partition)하는 것; 및

    상기 스케쥴을 런타임 알고리즘에 전달(communicate)하는 것

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

    상기 계약을 시행하는 것은 메소드 호출을 선언하고 상기 메소드 호출의 인보케이션(invocation)을 위해 패턴을 지정하는 것을 포함하는 방법.
15. 제9항에 있어서,

    상기 계약을 시행하는 것은 기존 계약을 확대하는 계약 확장을 식별하는 것을 포함하는 방법.
16. 제15항에 있어서,

    상기 계약 확장을 식별하는 것은 상기 계약에 적어도 하나의 부가적인 메시지를 추가하는 것을 포함하는 방법.
17. 제15항에 있어서,

    상기 계약 확장을 식별하는 것은 상기 계약에 적어도 하나의 부가적인 상태를 추가하는 것을 포함하는 방법.
18. 제15항에 있어서,

    상기 계약 확장을 식별하는 것은 상기 계약에 적어도 하나의 부가적인 트리거를 추가하는 것을 포함하는 방법.
19. 프로세서 및 시스템 메모리를 포함하는 컴퓨터 시스템에서, 통합 컴포넌트를 채용하여 복수의 서비스들 간의 통신을 관리하기 위해 상기 컴퓨터 시스템에 의해 실행되는 방법으로서,

    상기 복수의 서비스들에 외부적인 계약을 선언하는 단계 - 상기 외부적인 계약을 선언하는 단계는, 복수의 메시지들을 정의하는 단계 및 상기 복수의 서비스들 간의 병행성을 구현하기 위한 상기 외부적인 계약의 프로토콜을 정의하는 단계를 포함하고, 상기 복수의 메시지들은 데이터를 갖는 비동기 메시지를 둘 이상 포함함 - ;

    스레드 컨텍스트를 각각 포함하는 복수의 서비스들 간의 통신을 위해 상기 외부적인 계약을 구현하는 단계;

    상기 복수의 서비스들 간의 병행성을 구현하기 위한 상기 계약의 프로토콜 및 비동기 메시징의 기능(function)으로서 스케쥴을 생성하기 위해 상기 외부적인 계약을 컴파일하는 단계; 및

    생성된 상기 스케쥴을 이용하여, 상기 데이터의 공유 및 동기화를 성취하기 위해 상기 복수의 서비스들을 병렬 방식으로 조직하는 단계

    를 포함하고,

    상기 스케쥴은 둘 이상의 비동기 메시지에 대한 병렬 대기를 허용함으로써 서비스들의 스레드 컨텍스트의 차단을 방지하고,

    상기 조직하는 단계는,

    상기 복수의 서비스들 내의 서비스에, 상기 스케쥴을 식별하는 페이로드를 포함하는 메시지를 전송하는 단계 - 상기 페이로드는 상기 서비스가 다른 서비스들을 차단하지 않고 대기해야 하는 때를 나타냄 - , 및

    상기 서비스가, 다른 서비스들을 차단하지 않고 대기하도록 상기 페이로드를 채용하고 상기 스케쥴을 구현하기 위해 상기 메시지를 역컴파일하는 단계

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

    상기 스케쥴을 런타임 알고리즘에 전달하는 단계를 더 포함하는 방법.
21. 삭제
22. 삭제
23. 삭제
24. 삭제
25. 삭제
26. 삭제
27. 삭제
28. 삭제
29. 삭제
30. 삭제

Images