KR101047278B1

KR101047278B1 - 미들웨어 어플리케이션 메시지/이벤트 모델

Info

Publication number: KR101047278B1
Application number: KR1020057004952A
Authority: KR
Inventors: 죠나스 한손; 브죤 브자레; 치 투 레; 랄스 이스버그
Original assignee: 텔레포나크티에볼라게트 엘엠 에릭슨(피유비엘)
Priority date: 2002-09-23
Filing date: 2003-09-22
Publication date: 2011-07-07
Also published as: EP1550332A1; CN1685693A; WO2004028125A1; CN100525340C; EP1547351A1; JP2006500649A; ATE362270T1; KR20050059185A; JP2006511100A; DE60333768D1; DE60313787D1; EP1547351B1; DE60313787T2; KR20050056214A; JP4589113B2; CN100450122C; EP1550332B1; CN1685751A; WO2004028182A1; AU2003277881A1

Abstract

본 발명은 어플리케이션 소프트웨어 같은 제1 및 제2 소프트웨어 컴포넌트들과 제품에 대한 플랫폼의 소프트웨어 사이의 메시지의 전송에 대한 방법과 시스템을 제공한다. 본 발명의 바람직한 시스템은 소프트웨어 컴포넌트를 갖는 플랫폼, 그리고 소프트웨어 컴포넌트로의 접근과 어플리케이션 또는 어플리케이션 도메인 내의 모듈을 제공하기 위한 인터페이스를 갖는 인터페이스 컴포넌트를 포함한다. 상기 시스템은 어플리케이션 또는 모듈과 어플리케이션 또는 모듈 그리고 플랫폼 사이의 수신된 메시지에 대한 콜백 모드 또는 풀 메시지 모드 중 하나를 선택하는 어플리케이션을 허용하기 위한 메시지 모델을 포함하는 인터페이스를 경유하는 플랫폼 사이의 전송 메시지들을 위한 메시지 전송 메커니즘과 선택된 모드에 따른 정해진 메시지를 위한 메시지 구동기를 더 포함한다.

Description

미들웨어 어플리케이션 메시지/이벤트 모델{Middleware Application Message/Event Model}

발명의 분야

본 발명은 일반적인 무선 통신 분야에 관한 것이다. 보다 구체적으로 본 발명은 예를 들어, 무선 원격통신 시스템의 모바일 터미널 플랫폼의 어플리케이션 소프트웨어 및 소프트웨어 서비스와 같은 제1 및 제2 소프트웨어 컴포넌트 사이에서 메시지를 송신하고 수신하는 시스템 및 방법에 관한 것이다.

발명의 배경

1980년대에 휴대전화 통신 시스템이 처음 선보인 이후로, 이러한 시스템에 사용하는 모바일 터미널(모바일 기지국)은 더욱 더 복잡해지고 있다. 초기에 모바일 터미널은 주로 음성 전화 서비스, 즉 음성 통신의 전송 및 수신을 위해 고안되었다. 수년 뒤에, 모바일 터미널은 음성 전화 신호와 관련이 없는 사용자 데이터를 전송할 수 있도록 발전되었다. 이러한 사용자 데이터는, 예를 들어, 퍼스널 컴퓨터(PC)를 시작되는 다이얼-업 네트워킹 접속을 통해 전송되는 데이터를 포함한다.

최근에, "제3 세대"(3G)라 불리고 있는 시스템은 미래의 모바일 원격통신 시스템으로서 개발되고 있다. 3G 시스템은 고속 인터넷에의 접속을 전통적인 음성 통 신과 함께 결합시킬 것이고, 사용자로 하여금 음성 통신에 부가하여 인터넷 브라우징에의 접속, 오디오/비디오 스트리밍(streaming), 포지셔닝(positioning), 화상회의 및 많은 다른 기능을 음성 통신과 함께 제공할 것이다.

제3 세대 파트너쉽 프로젝트(The Third Generation Partnership Project: 3GPP)는 전 세계에서 개발되는 여러 3G 시스템 사이의 호환성을 결정하기 위해 설립되었다. 전 세계 어디에서나 음성, 데이터 및 멀티미디어를 전파할 수 있는 지상 및 위상 시스템을 포함하는 3G 시스템을 제공하기 위한 범용 이동 통신 시스템(Universal Mobile Telephone System: UMTS)이 3GPP에 의하여 개발되고 있다.

3GPP 표준화를 통해 셀룰러 원격 통신 시스템에 포함되고 급격히 증가된 기능은 상기 시스템에 사용되는 모바일 터미널의 개발자들에게 요구된다. 이러한 요구는 모바일 터미널이 크기, 메모리, 파워에 제한 받는 "리소스 결핍" 환경이라는 점에서 취약해진다.

전통적으로, 모바일 터미널 제조업자들은 그들 제조업자 또는 그들의 시장 수요의 인지를 토대로 한 특정의 사용자가 원하는 특성과 기능을 부여하는데 필요한 하드웨어와 소프트웨어뿐만 아니라 기본적인 터미널 조작에 필요한 모든 하드웨어와 소프트웨어를 포함하는 실질적으로 풀한 모바일 터미널 시스템을 설계, 제조 및 판매하고 있다. 그러한 접근방식은 시장 수요의 급격한 변화에 빠르게 적응하기 위한, 또는 많은 사용자들의 다양한 요구를 만족시키기 위한 유연성을 제공하지 못하고 있다.

모바일 터미널을 설계하고 제조하는 전통적인 과정에서 부족함을 인식하면 서, 지금까지 개발된 모바일 터미널 플랫폼 어셈블리는 복수의 사용자에게 단위로서 출시될 수 있었다. 그 특정 욕구를 만족시키는 모바일 터미널을 위해 제작된 플랫폼 시스템 제공하기 위해 각 사용자는 그들 자신의 어플리케이션 소프트웨어를 상기 어셈블리 내에 설치, 로딩, 및 실행시킬 수 있다. 모바일 터미널 플랫폼 어셈블리 및 플랫폼 시스템은 일반 양도된 미국특허출원 제10/359,911 및 10/359,835호에 자세히 설명되어 있으며, 본 명세서에서는 그 내용 모두가 포함되는 것으로 참조한다.

상술한 바와 같은 플랫폼 시스템은, 모바일 터미널 플랫폼 어셈블리 소프트웨어 및 어플리케이션 소프트웨어가 따로 개발되고 난 다음에 모바일 터미널 플랫폼 어셈블리 내에서 상기 어플리케이션 소프트웨어를 인스톨, 로딩, 및 실행함으로써 서로 합쳐지는데, 서비스 요청으로부터 생성되고 또한 이벤트 정보의 전달(delivery)을 포함할 수 있는 결과 메시지가 플랫폼 어셈블리 내의 인터페이스를 통해 플랫폼 어셈블리 내의 소프트웨어로부터 어플리케이션으로 전송될 것을 요구한다. 그와 같은 메시지는 스택/프로시저 기반의(stack/procedure-based) 접근 방식(즉, 콜백(callback) 모드), 또는 시리얼 기반의(serial-based) 접근 방식(즉, 풀 메시지 모드)을 사용하여 전송될 수 있다.

상기 콜백 모드는 어플리케이션으로 하여금 어플리케이션 특정 기능성에 초점을 맞추도록 하고, 플랫폼 또는 프레임워크에 대한 기본적이고 복잡한 메커니즘-관련 핸들링(handling)을 맡기도록 하는 단순하고도 인증된 기술이다. 소프트웨어 개발자는 그 결과의 핸들러에게 직접 메시지를 라우팅(route)하 가능성을 가지고 있다(기능/프로시저/방법). 개발자/사용자는 예를 들어, 윈도우 매니저(Windiw Manager)가 잘 정의된 핸들러(handler)에게 사용자 인터랙션 이벤트 또는 메시지를 가지고 있는 메시지를 통과시키는 것과 같은 사용자 인터페이스를 초기화할 수 있다. 사용자 코드를 불러오는 것은 전부 상기 윈도우 매니저에 의하여 결정된다. 상기 가치가 부가된 기능성은 개발자에게 접근 또는 이용 가능한 반면, 사용자는 메시지 루프 및 메시지가 제거되는 것을 볼 수가 없다. 따라서, 상기 개발자는 상기 프로그램의 특정 목적을 위한 부분에 다양한 메시지를 라우팅할 필요가 없으며 개발자는 시스템을 디그레이드(degrade)할 수 없다. 그러므로 콜백 모드에서, 어플리케이션 모드는 특정 메시지가 언제 또는 어떤 순서의 관점에서 제어되지 않는다. 다른 어떤 환경에서, 어플리케이션은 메시지가 프로세스되는 순서 또는 특정 메시지가 프로세스되는 시간(즉, 우선순위 핸들링)의 제어가 필요할 수 있다.

따라서, 풀 메시지 모드로 지칭하는 다른 기술이 상기 콜백 모드의 대안으로서 사용될 수 있다. 상기 순서화된 메시지는 FIFO 기법에서와 같이 순서대로 처리될 수 있거나, 또는 상기 순서화된 메시지는 우선 순위를 매기는 방식으로 병렬적으로 처리될 수 있다. 이 경우, 어플리케이션 코드는 메시지 루프의 풀한 제어를 포함한다.

PalmOS 및 Brew 환경에 통합된 것과 같은 최근의 솔루션은 사용자로 하여금 콜백 모드나 풀 메시지 모드 중 어느 것이라도 사용하도록 하고 있으나, 사용자 또는 어플리케이션 소프트웨어는 전송 메시지를 수신하는 모드를 자유롭게 선택할 수 없다. 상기 콜백 또는 풀 메시지 모드는 상기 어플리케이션에 대하여 미리 결정되 어 있다.

따라서, 사용자(어플리케이션 소프트웨어)에게 콜백 모드 또는 풀 메시지 모드로 메시지를 수신할 수 있는 선택권을 제공해주는 메시지 모델에 대한 요구가 있게 된다. 사용자는 다양한 상황에서 개별적으로 가장 적합한 메시지 모드를 선택할 수 있다.

발명의 요약

본 발명의 구체예에서, 제품의 플랫폼 도메인과 어플리케이션 도메인 사이에서 메시지를 전송하기 위한 시스템은 소프트웨어 컴포넌트와 인터페이스 컴포넌트를 가진 플랫폼 도메인을 포함한다. 인터페이스 컴포넌트는 어플리케이션 도메인 내의 어플리케이션 또는 모듈에게 소프트웨어 컴포넌트로의 액세스를 제공하기 위한 최소한 하나의 인터페이스와 상기 인터페이스를 통해 플랫폼 도메인과 상기 어플리케이션 도메인 사이에서 메시지를 전송하기 위한 메시지 전송 메커니즘을 가진다. 메시지 전송 메커니즘은 상기 플랫폼 도메인으로부터 메시지를 수신하기 위해 상기 어플리케이션 도메인 내의 어플리케이션 또는 다른 모듈로 하여금 콜백 모드 또는 풀메시지 모드 사이에서 선택 또는 스위칭하도록 하기 위한 메시지 모델을 포함한다. 메시지 전송 모델은 또한 상기 선택된 모드에 따라 메시지를 라우팅하기 위한 핸들러를 포함한다.

발명의 또 다른 구체예에서, 플랫폼 도메인은 소프트웨어 컴포넌트, 및 어플리케이션 도메인 내의 어플리케이션 또는 모듈에 소프트웨어 컴포넌트로의 액세스 를 제공하기 위한 최소한 하나의 인터페이스를 포함하는 인터페이스 컴포넌트를 포함한다. 어플리케이션 도메인과 플랫폼 도메인 사이에서 메시지를 전송하는 방법은 상기 어플리케이션 도메인 내의 어플리케이션 또는 모듈은 상기 플랫폼 도메인으로부터의 메시지를 수신하기 위한 콜백 모드 또는 풀 메시지 모드를 선택하거나 상기 플랫폼 도메인으로부터의 메시지를 수신하기 위한 상기 콜백 모드 및 플 메시지 모드를 스위칭하는 단계를 포함한다. 메시지 핸들러는 선택된 모드에 따라 메시지를 라우팅한다.

제1 소프트웨어 및 제2 소프트웨어 사이에서 메시지를 전송하기 위한 메시지 전송 메커니즘은 제1 및 제2 소프트웨어 컴포넌트 중의 하나로 하여금 상기 제1 및 제2 소프트웨어 컴포넌트 사이에서 메시지를 수신하기 위한 콜백 모드나 풀 메시지 모드를 선택하도록 하거나 상기 콜백 모드와 상기 풀 메시지 모드 사이에서 스위칭하도록 하기 위한 메시지 모델을 포함하며, 상기 모드들은 제1 및 제2 소프트웨어 사이에서 메시지를 수신하기 위한 것이다. 메커니즘은 또한 상기 선택된 모드에 따라 메시지를 라우팅하기 위한 메시지 핸들러를 포함한다.

본 발명의 장점과 특별한 세부항목은 하기의 자세한 설명과 이와 연계된 도면으로부터 명백해 질 것이다.

도면의 간단한 설명

도 1은 본 발명의 원리를 설명하는데 도움이 되도록 무선 원격통신 시스템의 모바일 터미널용 플랫폼 시스템을 개략적으로 설명하기 위한 블록도이다.

도 2는 본 발명의 원리를 설명하는데 더욱 도움이 되도록 도 1의 플랫폼 시스템의 모바일 터미널 플랫폼 어셈블리의 상세도를 개략적으로 도시하고 있다.

도 3은 본 발명의 원리를 설명하는데 더욱 도움이 되도록 도 1 및 도 2의 모바일 터미널 플랫폼 어셈블리의 소프트웨어 구조를 개략적으로 도시한 블록도이다.

도 5는 본 발명의 원리에 따라 도 4의 미들웨어 서비스 계층의 OPA 도메인에 대한 상세 사항을 개략적으로 도시한 블록도이다.

도 6은 본 발명의 원리에 따라 풀 메시지 모드 또는 콜백 모드를 제어하는데 사용하는 신호 컴포넌트를 개략적으로 도시한 블록도이다.

도 7은 본 발명의 원리에 따라 풀 메시지 모드 또는 콜백 모드를 호출하는 것을 설명하기 위한 흐름도이다.

발명의 구체예에 대한 상세한 설명

도 1은 본 발명의 원리를 설명하기 위해 무선 원격통신 시스템용 모바일 터미널의 플랫폼 시스템을 개략적으로 도시한 블록도이다. 상기 플랫폼 시스템은 일반적으로 도면 부호 10으로 나타내고 모바일 터미널 플랫폼 어셈블리(12)와 이 모바일 터미널 플랫폼 어셈블리(12) 내에 설치되고, 로딩되고 그리고 실행되는 하나 이상의 어플리케이션(즉, 어플리케이션 소프트웨어)(14)를 포함한다. 플랫폼 시스템(10)은 통상 점선(16)으로 표시된 모바일 터미널 내에 포함되도록 적용되고 있다.

모바일 터미널 플랫폼 어셈블리(12)는 소프트웨어 서비스 컴포넌트(22), 하 드웨어 컴포넌트(24), 및 인터페이스 컴포넌트(26)를 포함한다. 소프트웨어 서비스 컴포넌트(22)는 인터페이스 컴포넌트(26)를 통해 사용자에게 제공되는 서비스를 제공하기 위해 복수의 잘 구축된 기능 소프트웨어를 포함한다. 사용자는 플랫폼 사용자(예로, 전화기 제조업자) 및 최종 사용자(예로, 전화기 사용자)를 포함한다. 도 1에 도시된 바람직한 시스템(10)에서, 복수의 소프트웨어 유닛은 복수의 수직-지향 기능 소프트웨어 스택(30-38)을 포함한다.

하드웨어 컴포넌트(24)는 각각의 기능 소프트웨어 스택(30-38)과 연결되고, 그것에 의해 제어되는 하드웨어 유닛의 집합을 포함한다. 도 1에 도시된 바람직한 시스템(10)에서, 상기 하드웨어 유닛은 소프트웨어 스택(30-38)과 연결된 다양한 하드웨어 블록(40-48)이다.

인터페이스 컴포넌트(26)는 모바일 터미널 플랫폼 어셈블리(12) 내에서 설치, 로딩, 및 실행되는 하나 또는 그 이상의 어플리케이션(14)을 위한 최소한 하나의 어플리케이션 프로그래밍 인터페이스 (API)를 포함하고, 상기 모바일 터미널 플랫폼 어셈블리(12)를 상기 인터페이스를 통해 어셈블리(12)를 사용하여 어플리케이션(14)로부터 분리하고, 그리고 어플리케이션(14)를 위한 다양한 다른 서비스를 제공하는 미들웨어 서비스 계층을 포함한다. 미들웨어 서비스 계층의 상세 사항에 대해 아래에서 설명한다.

모바일 터미널 플랫폼 어셈블리(12)는 추후 플랫폼 시스템(10)의 기능성을 확장하기 위해 사용되며, 어플리케이션 소프트웨어(14)로부터 분리된 풀하고 봉쇄된 유닛으로서 설계, 구현(어셈블) 및 테스트되도록 적용된다(여기서, "어플리케이 션 소프트웨어"라는 용어는 사용하기를 원하고자 하는 기능성을 제공하는 어떠한 소프트웨어일 수 있다). 개발 능력을 가지고 있는 모바일 터미널 제조업자 또는 다른 사용자는, 따라서, 그들 자신의 어플리케이션 소프트웨어(14)를 개발 또는 습득하거나 할 수 있고, 그들의 요구에 따라 플랫폼 시스템(10)을 구축하기 위해 추후에 모바일 터미널 플랫폼 어셈블리(12)에 소프트웨어(14)를 추가할 수 있다. 모바일 터미널 플랫폼 어셈블리(12)는, 따라서, 플랫폼 시스템에 대한 각자의 특정 요구를 만족시키기 위해 어셈블리 내의 어플리케이션 소프트웨어를 설치, 로딩, 및 실행시킴으로써 플랫폼 시스템(10)을 구축할 수 있는 각각 복수의 다양한 사용자에게 판매되거나 전송될 수 있다.

도 2는 본 발명의 원리를 설명하는데 더욱 도움이 되도록 도 1의 플랫폼 시스템(12)의 모바일 터미널 플랫폼 시스템의 상세도를 개략적으로 도시하고 있다. 도 2에 도시한 바와 같이, 모바일 터미널 플랫폼 어셈블리(12)는 메인 CPU(50) 내에서 실행되는 소프트웨어를 통해 제어된다. 이 메인 CPU(50)는 마이크로프로세서, 마이크로 프로그래머블 프로세서 또는 DSP(Digital Signal Processor)와 같은 하나 또는 그 이상의 프로세서를 포함할 수 있다. 소프트웨어 서비스 컴포넌트(22)의 소프트웨어 스택(30-38)은 각 스택과 연결된 하드웨어 유닛을 작동시키기 위한 하드웨어 드라이버 소프트웨어(60-68)를 각각 포함한다. 모바일 터미널 플랫폼 어셈블리(12) 및 플랫폼 시스템(10)의 상세 사항은 위에서 언급한 일반 양도된 미국특허출원 제10/359,835호에 개시되어 있다.

모바일 터미널 플랫폼 어셈블리(12)에 통합된 소프트웨어는 바람직하게, 보 다 쉽게 설계되고 쉽게 업그레이드되거나 변경될 수 있도록, 쉽게 이해할 수 있는 소프트웨어 조직을 만드는 방식으로 배열된다. 도 3은 본 발명의 원리를 설명하는데 더욱 도움이 되도록 모바일 터미널 플랫폼 어셈블리(12)의 소프트웨어 구조를 개략적으로 도시한 블록도이다.

도 3에 도시된 바와 같이, 소프트웨어 서비스 컴포넌트(22)는, 위에서 설명한 복수의 수직 기능 소프트웨어 스택 내로 조직되는 것 이외에도, 미들웨어 서비스 계층의 소프트웨어 및 소프트웨어 서비스 컴포넌트(22)의 소프트웨어가 함께 보통 도면 부호 70으로 나타낸 계층형 구조를 정의하기 위해 복수의 수평 계층을 정의하도록 배열되는데, 계층형 구조 내에서 계층은 높은 레벨의 서비스 계층으로부터 낮은 레벨의 서비스 계층으로 내림차순으로 배열된다.

상기 소프트웨어 구조는 복수의 수직 분할된 소프트웨어 계층을 보완하는 복수의 수평 분할된 기능 소프트웨어 유닛을 포함하는 점에서 표준 ISO/OSI(ISO Open Systems Interconnection) 모델과 다르다. 이 수평 분할은 독립 모듈 컴포넌트를 만들어 내는데 있어 매우 중요하다.

계층형 구조의 가장 상위 계층은 미들웨어 서비스 계층이다. 소프트웨어 서비스 컴포넌트(22)의 계층은 어플리케이션 서비스를 제공하기 위한 어플리케이션 서버 계층(80), 어플리케이션에 대한 플랫폼 특정 서비스를 제공하기 위한 플랫폼 서비스 계층(82), 세션 프로토콜 및 어플리케이션 특정 프로토콜을 제공하기 위한 플랫폼 프로토콜 계층(84), 오디오 액세스/컨트롤, 데이터컴 전송 프로토콜, 미시지 전송 프로토콜 등을 제공하기 위한 전송 계층(86), 외부 데이터 IF 액세스, 구 조화 저장 서비스 및 다른 하위 레벨 플랫폼 지원 서비스를 제공하기 위한 데이터 액세스 계층(88), 논리 드라이버 계층(90) 및 하드웨어 의존성과 결부된 물리적 드라이버 계층(92)을 포함한다. 또한, 소프트웨어 서비스 컴포넌트(22)는 플랫폼 어셈블리에 필요한 일반 서비스를 제공하는 기본 시스템 서비스 계층(94)을 포함한다.

하부의 두 계층(90 및 92)은 소프트웨어와 하드웨어 사이의 종속성을 분리하는 하드웨어 추상화 계층(Hardware Abstraction Layer, HAL)으로 구성된다. 단지 물리적 드라이버 계층만이 하드웨어의 상세(예를 들어, ASIC 하드웨어 내의 어느 레지스터가 어드레스되어 있는지)에 관련되어 있다. 논리 드라이버 계층(90)은 하드웨어에 논리 매핑(mapping)을 제공하는데, 즉 이 계층은 모바일 터미널 플랫폼 어셈블리의 하드웨어 및 소프트웨어 부분 사이의 브릿지(bridge)를 제공한다.

소프트웨어 자체는 도 3에 구체적으로 도시한 모듈(102, 104, 106), 즉 복수의 소프트웨어 모듈 내에 편성된다. 소프트웨어 서비스 컴포넌트(22)에서, 단일 모듈은 하나의 수직 기능 스택과, 그 스택 내에서 단 하나의 수평 계층에만 귀속될 수 있다. 각 계층은 하나에서 많은 수의 모듈을 포함할 수 있으며, 특정 스택의 특정 계층 내 모든 모듈은 동일한 추상화 레벨을 갖는다. 다양한 모듈 사이의 통신은 소프트웨어 모듈 대 모듈 액세스의 기분 규칙 집합에 종속된 소프트웨어 백 플레인(Software Back Plane, SwBP)(112)을 통해 이루어진다. 이러한 규칙은 다음과 같이 정리할 수 있다.

- 소프트웨어 모듈은 그 자신의 계층 하위의 모든 계층 인터페이스 내의 기 능성(functionality)을 불러올 수 있다.

- 직렬 데이터 흐름의 방향에 대한 제한은 없다. 이는 어떠한 방향으로도 가능하다.

- 소프트웨어 모듈은 그 자신의 계층 상위의 계층 인터페이스(SwBP(112) 내) 내의 기능성을 그 계층이 포함하는 모듈에 관계없이 불러올 수 없다.

- 소프트웨어 모듈은 동일한 수직 스택 내의 자신의 계층 내에서 계층 인터페이스 내의 기능성을 불러올 수 있다.

- 소프트웨어 모듈은 다른 수직 스택 내의 동일한 계층에서 소프트웨어 모듈 내의 기능성을 불러올 수 있다. (이러한 성능은 수직 스택 내의 계층의 수를 제한하도록 승인된다.)

SwBP(112) 내의 다양한 모듈 및 인터페이스 사이의 강한 연관은 없다. 그 결과, 모듈 및/또는 인터페이스의 구현은 인터페이스의 클라이언트에 어떠한 영향을 주지 않고서도 자유롭게 변경될 수 있다.

모바일 터미널 플랫폼 어셈블리 내에서 모듈 사이의 내부 통신을 가능하게 하는 SwBP 소프트웨어 구조를 포함한 계층형 구조의 상세 사항은 위에 언급한 일반 양도된 미국특허출원 제10/359,911호에 기술되어 있다.

미들웨어 서비스 계층은 모바일 터미널 플랫폼 어셈블리(12) 내의 소프트웨어와 그 플랫폼 어셈블리 내에 설치, 로딩, 및 실행되는 어플리케이션 소프트웨어(14) 사이의 잘 정의된 인터페이스를 제공하는 기능을 수행한다. 또한, 상기 미들웨어 서비스 계층은 모바일 터미널 플랫폼 어셈블리(12)를 요약하고 미들웨어 서비 스 계층을 통해 어플리케이션(14)으로부터 어셈블리(12)를 분리하고, 그리고 그 어플리케이션(14)을 위한 다양한 다른 서비스를 제공한다.

도 4는 미들웨어 서비스 계층에 대한 상세 사항을 설명하기 위해 개략적으로 도시한 블록도이다. 도 4에 도시한 바와 같이, 미들웨어 서비스 계층은 넌네이티브 환경(예를 들어, 자바 실행(Java ExE) 환경) API 도메인(202), 오픈 어플리케이션 프레임워크(OAF) AIP 도메인(204), 오픈 플랫폼 API (OPA) 도메인(206), 및 UI 툴 키트 API 도메인(208)을 포함하는 복수의 API 도메인을 포함한다.

미들웨어 서비스 계층의 API(202-208)를 통해, 모바일 터미널 플랫폼 어셈블리(12)는 복수의 어플리케이션 환경을 지원한다. 도 4에서, 미들웨어 서비스 계층은 네이티브 어플리케이션(즉, 특정 프로세서 및 그것의 명령어 집합과 함께 실행되도록 컴파일되는 어플리케이션) 및 넌네이티브 어플리케이션(예를 들어, 자바 J2ME CLDC/MIDP(Java 2 Micro Edition Connected Limited Device Configuration/Mobile Information Device Profile))에 대한 환경을 지원한다. 각 어플리케이션 환경은 다음의 관점에서 네이티브의 특성을 갖는다:

- 어플리케이션이 개발되는 방식(프로그래밍 언어 지원, 컴파일레이션(compilation) 및 링키지(linkage))

- 어플리케이션이 실행되는 방식(예를 들어, 해독(interpretation) 또는 네이티브 코드 실행)

- 제공되는 기능 서비스.

- 사용에 있어 잠재적인 제한.

다중 어플리케이션 환경 대안을 제시함으로써, 비용, 사용의 용이성, 판매 시간, 기능성 집합, 크기, 휴대성 등과 같은 다양한 요구가 있는 넓은 범위의 제품을 촉진시킬 수 있다.

미들웨어 서비스 계층의 좀 더 상세한 기술은 U. S. Patent Application Serial No. 10/359,772에 자세히 설명되어 있으며, 본 명세서에서는 그 내용 모두가 포함되는 것으로 참조한다.

도 5는 본 발명의 이론과 일치하는 오픈 플랫폼(OPA) 도메인(206)의 주요 소프트웨어 모듈들을 도식적으로 도해한 블록 다이어그램이다. 도해한 바와 같이, OPA 도메인(206)은 네이티브 환경 관리(a Native Environment Management(NEM))모듈(230), 네이티브 어플리케이션 코어(a Native Application Core(NAC))모듈(232), OPA 인터페이스와 핸들러(OPA Interface and Handler)모듈(234), 미들웨어 지원 서비스 모듈(236) 그리고 네이티브 확장 플러그인 모듈(들)(238)의 다섯 개의 모듈을 포함한다.

네이티브 환경 관리 모듈(230)은 플랫폼 시스템(10)내의 네이티브 어플리케이션을 조절하는 책임을 가지며 어플리케이션 핸들러로부터 관계되는 네이티브 어플리케이션들을 명령하고 시스템 내에서 현재 실행되고 있는 네이티브 어플리케이션의 추적을 유지하는 조절의 수취인이다. 미들웨어 지원 서비스 모듈(236)은 다른 핸들러를 위해 공통되거나 또는 예를 들어, 대상의 관리와 공급원 관리 같은 집중화 되는 것을 필요로 하는 OPA 도메인으로의 서비스를 제공한다.

네이티브 확장 플러그인 모듈(들)(238)은 OPA 인터페이스와 핸들러 모듈 (234)을 통하여 플랫폼 어셈블리 기능성의 임의적 확장 같이 보여질 수 있다. NE 플러그인 모듈(들)(238)은 동일한 인터페이스 가이드라인들, 패러다임들 그리고 OPA 인터페이스와 핸들러 모듈(234)을 지배하고, 적용하는 메커니즘들을 필요로 한다. OPA 네이티브 확장 플러그인 모듈(들)(238)은 OPA 인터페이스와 핸들러 모듈(234)을 통하여 플랫폼 기능성에 접근한다.

네이티브 어플리케이션 코어 모듈(232)은 어플리케이션들이 그들 자신을 다르게 핸들하는 스레딩과 메시지-관리 복잡성을 관리하고 유의하여 다룬다. 그것은 또한 메시지 라우팅(routing)/필터링(filtering)과 메시지에 관련되는 공급원 핸들링을 포함하는 실행 시간의 복잡성으로부터 어플리케이션을 완화하기 위해 OS의 기구의 상세한 설명을 숨기는 것에 의해 OS 독립의 달성의 목적을 제공한다. 네이티브 어플리케이션 코어 모듈(232)의 중요한 책임은 메시지 핸들링 내에서 시동의 상세한 기술을 숨기고 어플리케이션(14)의 위상을 중지하는 것이다.

도 6은 본 발명의 이론과 일치하는, 미들웨어 서비스를 경유하여 플랫폼 어셈블리(12)의 소프트웨어 서비스 컴포넌트(22)로부터 메시지를 받기 위한 콜백 모드 또는 풀 메시지 모드 둘 중 하나를 이용하는 어플리케이션(14)내에 포함되는 컴포넌트와 신호(signaling)를 도해한 것이다. 메시지 모델(250)은 어플리케이션(14)이 어플리케이션(14)의 현재의 수행과 상황에 대하여 가장 이익이 되는 것에 의존하여 콜백 모드(252) 또는 풀 메시지 모드(254) 둘 사이에서 선택하는 것을 허용한다. 한 번 어플리케이션(14)이 원하는 모드, 다시 말하면 콜백 모드(252) 또는 풀 메시지 모드(254)에 들어오면, 메시지 모델(250)은 신호 컨벤션을 선택된 모드와 결합시키는 것을 개시한다. NAC 모듈(232)은 선택된 모드를 알고, 필요한 신호 컨벤션을 따라 메시지를 핸들링한다.

만약 어플리케이션(14)이 콜백 모드(252)로 들어가는 것을 선택한다면, NAC 모듈(232)은 OPA 인터페이스와 핸들러 모듈(234)내의 적절한 핸들러로 메시지를 이끌고, 다음에 콜백 모드를 따라서 메시지를 포맷한다. 콜백 모드(252)에서 소프트웨어 개발자는 일반적인 기능 또는 바쳐지는 기능과 같이 바로 기능/프로시저/방법으로 그 결과를 받을 가능성이 있다. 콜백 모드(252)는 어플리케이션(14)이 콜백의 수행 후에 수행 조절을 미들웨어 서비스 계층으로 되돌려준다. 한 번 어플리케이션(14)이 조절을 미들웨어 서비스 계층으로 되돌려준다면, 그것은 다른 콜백 기능을 자극할 가능성이 있다. 그러나 콜백 기능의 수행 동안에 다른 메시지들은 풀 메시지 모드(254)를 사용하는 것에 의한 어플리케이션에 의해 프로세스될 것이다.

만약 어플리케이션(14)이 풀 메시지 모드(254)로 들어가는 것을 선택한다면, NAC 모듈(232)은 풀 메시지 모드(254)에 따라서 적절한 어플리케이션 메시지 대시 행렬로 메시지를 이끈다. 소프트웨어 개발자는 즉각 메시지 루프(loop)의 완전한 조절을 가진다. 풀 메시지 모드(254)는 어플리케이션(14)이 그 자신의 스레드(thread)의 조절이 될 때 디폴트(default)모드 그리고 활성 모드이다. 이러한 예에서 어플리케이션(14)은 언제라도 미들웨어 서비스 계층에 명백하게 요구되는 것을 경유하여 메시지 대기 행렬을 폴(poll)하는 선택을 할 수 있다. 여러 가지의 임의 선택이 풀 메시지 모드(254)내에서 유용해진다. 예를 들어 사용자 또는 소프트웨어 개발자는 상기 스레드의 블록킹 없이 메시지가 유용해지거나 또는 메시지를 체크하 는 동안 콜링 스레드(calling thread)가 블록되고, 임의적인 중단과 같은 요구를 선택할 수 있다. 또한 필터 파라미터가 사용될 수 있으며, 그 때문에 어떤 오더(order)에서는 메시지에 반응할 가능성이 있으며, 나중의 프로세스를 위해 덜 중요한 것을 필터해 낸다. 풀 메시지 모드(254)에서 메시지가 프리(freeing)한 것은 어플리케이션 모드가 원인이다. 수행을 개선하는 어플리케이션은 따라서 프리에 대한 필요와 메시지를 다시 배치함이 없이 어떤 상황에서 또 다른 어플리케이션에 대해 받아들여진 메시지를 향하여 선택할 수 있다.

풀 메시지 모드(254)로부터 콜백 모드(252)로 스위칭(switching)할 때, 소프트웨어 개발자는 적절한 콜백 기능을 일깨우는 미들웨어 서비스 계층의 소프트웨어를 허용한다. 게다가 어플리케이션(14)은 어떤 시간, 심지어 실제 시간이라도 콜백 모드(252)와 풀 메시지 모드(254)사이에서 변화한다. 그러므로 어플리케이션(14)은 어떤 시간에서 각각 개개의 문제에 가장 잘 맞는 메시지 수용 모드를 선택하는 능력을 가진다. 콜백 모드(252)와 풀 메시지 모드(254)는 어플리케이션 소프트웨어 도메인 내의 소프트웨어 존재의 어떤 컴비네이션(combination)에서 공존할 수 있다.

도 7은 본 발명의 이론과 일치하는 풀 메시지 모드 또는 콜백 모드의 일깨움을 도시한 플로우 다이어그램이다. 단계(300)에서 어플리케이션(14)은 시스템의 개시 때문에 처음 시간에서 그것의 메인 스레드에 대한 조절을 얻는다. 어플리케이션(14)는 단계(302)에서 나타내어지듯이 어플리케이션(14)이 미들웨어 서비스 계층으로부터 메시지를 기다리는 결정을 하는 동안 이 조절을 유지할 것이다. 어플리케이션(14)은 다음에 콜백 모드 또는 풀 메시지 모드에서 메시지를 기다릴지 여부를 결정(304)할 것이다. 만약 결정이 콜백 모드이면, 307에 나타내듯이, NAC 모듈(232)에 대한 어플리케이션 스레드의 조절을 옮기는 어플리케이션(14)은 리턴 스테이트먼트(statement)를 수행할 것이다. NAC 모듈(232)은 다음에 309에 의해 나타내듯이 현존하는 메시지를 위한 이 스레드의 메시지 대기 행렬을 폴한다. NAC 모듈(232)은 메시지가 발견되는(311,313) 동안 대기 행렬을 폴링(polling)하는 것을 유지하며, 그것은 콜백 포맷(314)에 대한 상기 메시지를 변환하고 상기 메시지를 핸들하기 위한 어플리케이션(14)에 의해 이전에 특화된 콜백 방법을 일깨울 것이다. 이것은 루프를 완성하고 그리고 어플리케이션(14)은 304에 의해 나타내어지는 것과 같이 어플리케이션(14)이 콜백 또는 풀 메시지 모드로 들어갈지 여부에 따라 다시 결과를 만든다.

만약 풀 메시지 모드가 선택되면, 어플리케이션(14)은 306에 나타낸 것과 같이 블록킹 또는 넌블록킹 모드로 들어갈지 여부에 따라 결정해야만 한다. 어플리케이션(14)은 미들웨어 서비스 계층 내의 OPA 인터페이스와 핸들러 모듈(234)로부터 메시지를 요구하는 것에 의해 행동할 것이다. 요구의 타입은 또한 상기 요구가 넌블록킹 또는 블록킹이 되어야 하는지의 여부에 따라 나타날 것이다. 만약 넌블록킹 요구가 문제되면, 상기 요구는 308에 의해 나타내어지듯이, NAC 모듈(232)에 대한 어플리케이션 스레드의 조절을 옮긴다. NAC 모듈(232)은 다음에 요구(310)의 특화에 따라서 메시지의 현존에 대한 이 스레드의 메시지 대기 행렬을 폴할 수 있다. 만약 매칭(matching)메시지가 발견되면, 그다음 이 메시지는 메시지 대기 행렬(312)로부터 제거 될 것이고 어플리케이션(14)으로 되돌아 올 것이다. 만약 노 메시지가 발견되면 NAC 모듈(232)은 어떤 메시지의 통과 없이 어플리케이션(14)에 대해 스레드의 조절은 리턴될 것이다. 이것은 루프를 완성하고 그리고 어플리케이션(14)은 304에 나타내어지듯이 상기 어플리케이션(14)이 콜백 또는 풀 메시지 모드로 들어갈 것인지 여부에 의해 다시 결정을 내린다.

만약, 풀 메시지 모드가 션택되면, 어플리케이션(14)은 306에 나타내듯이 블록킹 또는 넌블록킹 모드로 들어가는지의 여부에 의하여 다시 결정되어야만 한다. 넌블록킹 모드에 대하여 이전에 언급하였듯이, 어플리케이션(14)은 미들웨어 서비스 계층 내의 OPA 인터페이스와 핸들러 모듈(234)로부터 메시지를 요구하는 것에 의해 행동할 것이다. 요구의 타입은 또한 상기 요구가 넌블록킹 또는 블록킹이 되어야 하는지의 여부에 따라 나타날 것이다. 만약 블록킹 요구가 문제되면, 상기 요구는 305에 의해 나타내어지듯이, NAC에 대한 어플리케이션 스레드의 조절을 옮긴다. NAC 모듈(232)은 다음에 요구(310)의 특화에 따라서 메시지의 현존에 대한 이 스레드의 메시지 대기 행렬(315)을 폴할 수 있다. 만약 노 메시지가 발견되면 NAC 모듈(232)은 하나가 발견되고 또는 잠재적 특화된 중지 기간이 초과하는 동안 요구되는 메시지에 대하여 메시지 대기 행렬을 폴하는 것을 유지할 것이다. 매칭(matching)메시지가 발견되자마자, 그다음 이 메시지는 메시지 대기 행렬(312)로부터 제거 될 것이고 어플리케이션(14)으로 되돌아 올 것이다. 이것은 루프를 완성하고 그리고 어플리케이션(14)은 304에 나타내어지듯이 상기 어플리케이션(14)이 콜백 또는 풀 메시지 모드로 들어갈 것인지 여부에 의해 다시 결정을 내린다.

본 발명의 구성된 전형적인 구체예가 묘사되는 동안에, 상기 발명은 그 자신 의 영역으로부터 떨어짐이 없이 많은 방법으로 다양해질 수 있다는 점을 이해해야 한다. 예를 들어, 비록 본 발명이 기본적으로 특별한 모바일 터미널 플랫폼 어셈블리와 관련되어 묘사되었다 할지라도, 그것은 본 발명이 모바일 터미널과 다른 제품들을 위한 다른 플랫폼이 또한 사용되는 만큼 본 발명을 제한하는 것은 아니다.

Claims

소프트웨어 컴포넌트, 및 어플리케이션 도메인 내의 어플리케이션 또는 모듈에게 소프트웨어 컴포넌트로의 액세스를 제공하기 위한 최소한 하나의 인터페이스와, 상기 인터페이스를 통해 플랫폼 도메인과 상기 어플리케이션 도메인 사이에서 메시지를 전송하기 위한 메시지 전송 메커니즘을 포함하는 인터페이스 컴포넌트를 포함하는 플랫폼 도메인;

을 포함하고, 상기 메시지 전송 메커니즘은

상기 플랫폼 도메인으로부터 메시지를 수신하기 위해 상기 어플리케이션 도메인 내의 어플리케이션 또는 다른 모듈로 하여금 콜백 모드 또는 풀메시지 모드 사이에서 선택 또는 스위칭하는 역할을 하는 메시지 모델; 및

상기 선택된 모드에 따라 메시지를 라우팅하기 위한 메시지 핸들러;

로 이루어지고,

상기 어플리케이션 도메인 내의 상기 어플리케이션 또는 상기 모듈은 상기 콜백 모드 및 상기 풀 메시지 모드 사이에서 어느 때에나 스위칭할 수 있는 것을 특징으로 하는 제품의 플랫폼 도메인과 어플리케이션 도메인 사이에서 메시지를 전송하기 위한 장치.
제1항에 있어서, 상기 메시지 핸들러는 상기 플랫폼 도메인 내에 포함되는 것을 특징으로 하는 제품의 플랫폼 도메인과 어플리케이션 도메인 사이에서 메시지를 전송하기 위한 장치.
제2항에 있어서,

상기 인터페이스는 미들웨어 서비스 계층을 포함하고; 그리고

상기 메시지 핸들러는 상기 미들웨어 서비스 계층 내에 포함된 라우터로서 작동하기 위한 네이티브 어플리케이션 코어(Native Application Core) 모듈을 포함하는;

것을 특징으로 하는 제품의 플랫폼 도메인과 어플리케이션 도메인 사이에서 메시지를 전송하기 위한 장치.
제3항에 있어서, 상기 네이티브 어플리케이션 코어 모듈은 상기 미들웨어 서비스 계층의 오픈 플랫폼 API(open platform API: OPA) 도메인 내에 포함되는 것을 특징으로 하는 제품의 플랫폼 도메인과 어플리케이션 도메인 사이에서 메시지를 전송하기 위한 장치.
제1항에 있어서, 상기 메시지 모델에 대한 지원이 상기 플랫폼 도메인 내에 포함되고, 상기 어플리케이션 도메인 내의 상기 모듈에 의해 제어되는 것을 특징으로 하는 제품의 플랫폼 도메인과 어플리케이션 도메인 사이에서 메시지를 전송하기 위한 장치.
제1항에 있어서, 상기 콜백 모드가 선택되면, 상기 콜백 모드는 콜백 기능/프로시저/방법의 호출 이후에 상기 메시지 핸들러에게 실행 제어를 돌려보내는 상기 어플리케이션에 의해 진입되는 것을 특징으로 하는 제품의 플랫폼 도메인과 어플리케이션 도메인 사이에서 메시지를 전송하기 위한 장치.
제1항에 있어서, 상기 풀 메시지 모드가 선택되면, 상기 풀 메시지 모드는 콜백 기능/프로시저/방법의 호출 이후에 실행 제어를 유지하고 순서화된 메시지에 대한 메시지 핸들러를 폴링(polling)하는 상기 어플리케이션에 의해 진입되는 것을 특징으로 하는 제품의 플랫폼 도메인과 어플리케이션 도메인 사이에서 메시지를 전송하기 위한 장치.
삭제
제1항에 있어서, 상기 플랫폼 도메인은 무선 원격통신 시스템의 모바일 터미널용 플랫폼으로 이루어지는 것을 특징으로 하는 제품의 플랫폼 도메인과 어플리케이션 도메인 사이에서 메시지를 전송하기 위한 장치.
플랫폼 도메인은 소프트웨어 컴포넌트, 및 어플리케이션 도메인 내의 어플리케이션 또는 모듈에 소프트웨어 컴포넌트로의 액세스를 제공하기 위한 최소한 하나의 인터페이스를 포함하는 인터페이스 컴포넌트를 포함하고, 어플리케이션 도메인과 상기 플랫폼 도메인 사이에서 메시지를 전송하는 방법에서 있어서,

상기 어플리케이션 도메인 내의 상기 어플리케이션 또는 상기 모듈은 상기 플랫폼 도메인으로부터의 메시지를 수신하기 위한 콜백 모드 또는 풀 메시지 모드를 선택하거나 상기 콜백 모드 및 풀(full) 메시지 모드를 스위칭하고;

메시지 핸들러는 상기 선택된 모드에 따라 메시지를 라우팅하는; 그리고

상기 어플리케이션 도메인 내의 상기 어플리케이션 또는 상기 모듈은 어느 때라도 상기 콜백 모드와 풀(full) 메시지 모드를 스위칭하는;

단계로 이루어지는 것을 특징으로 하는 어플리케이션 도메인과 플랫폼 도메인 사이에서 메시지를 전송하는 방법.
제10항에 있어서, 상기 콜백 모드가 선택되는 경우에, 콜백 기능/프로시저/방법의 호출 이후에 실행 제어를 상기 메시지 핸들러로 돌려보내는 상기 어플리케이션에 의하여 상기 콜백 모드로 진입하는 단계를 더 포함하는 것을 특징으로 하는 어플리케이션 도메인과 상기 플랫폼 도메인 사이에서 메시지를 전송하는 방법.
제10항에 있어서, 상기 풀 메시지 모드가 선택되는 경우에, 콜백 기능/프로시저/방법의 호출 이후에 실행 제어를 유지하고 순서화된 메시지에 대한 상기 메시지 핸들러를 폴링하는 상기 어플리케이션에 의해 상기 풀 메시지 모드로 진입되는 단계를 더 포함하는 것을 특징으로 하는 어플리케이션 도메인과 상기 플랫폼 도메인 사이에서 메시지를 전송하는 방법.
삭제
제10항에 있어서, 상기 플랫폼 도메인은 무선 원격통신 시스템의 모바일 터미널용 플랫폼으로 이루어지는 것을 특징으로 하는 어플리케이션 도메인과 상기 플랫폼 도메인 사이에서 메시지를 전송하는 방법.
제1 및 제2 소프트웨어 컴포넌트 중의 하나로 하여금 상기 제1 및 제2 소프트웨어 컴포넌트 사이에서 메시지를 수신하기 위한 콜백 모드나 풀 메시지 모드를 선택하도록 하거나 상기 콜백 모드와 상기 풀 메시지 모드 사이에서 스위칭하도록 하기 위한 메시지 모델; 및

상기 선택된 모드에 따라 메시지를 라우팅하기 위한 메시지 핸들러;

로 이루어지고,

상기 제1 및 제2 소프트웨어 컴포넌트 중의 하나는 어느 때라도 상기 콜백 모드와 플 메시지 모드사이에서 스위칭할 수 있는 것을 특징으로 하는 제1 소프트웨어 및 제2 소프트웨어 사이에서 메시지를 전송하기 위한 장치.
제15항에 있어서, 상기 제2 소프트웨어 컴포넌트는 상기 제1 소프트웨어에게 상기 제2 소프트웨어 컴포넌트로의 액세스를 제공하는 인터페이스로 이루어지는 인터페이스를 포함하는 플랫폼 도메인 내에 있고, 상기 메시지 핸들러는 상기 인터페이스 컴포넌트 내에 포함되어 있는 것을 특징으로 하는 제1 소프트웨어 및 제2 소프트웨어 사이에서 메시지를 전송하기 위한 장치.
제16항에 있어서,

상기 인터페이스 컴포넌트는 미들웨어 서비스 계층으로 이루어지고;

상기 메시지 핸들러는 상기 미들웨어 서비스 계층 내에 포함된 네이티브 어플리케이션 코어로 이루어지고; 그리고

상기 네이티브 어플리케이션 코어는 라우터로서 작동되도록 구비되는;

것을 특징으로 하는 제1 소프트웨어 및 제2 소프트웨어 사이에서 메시지를 전송하기 위한 장치.
제17항에 있어서, 상기 네이티브 어플리케이션 코어 모듈은 상기 미들웨어 서비스 계층의 오픈 플랫폼 API(OPA) 도메인 내에 포함되는 것을 특징으로 하는 제1 소프트웨어 및 제2 소프트웨어 사이에서 메시지를 전송하기 위한 장치.
제15항에 있어서, 상기 메시지 모델에 대한 지원은 플랫폼 도메인 내에 포함되고, 어플리케이션 도메인 내의 모듈에 의해 제어되는 것을 특징으로 하는 제1 소프트웨어 및 제2 소프트웨어 사이에서 메시지를 전송하기 위한 장치.
제15항에 있어서, 상기 콜백 모드가 선택되면, 상기 콜백 모드는 콜백 기능/프로시저/방법의 호출 이후에 실행 제어를 상기 메시지 핸들러로 돌려보내는 어플리케이션에 의해 진입되는 것을 특징으로 하는 제1 소프트웨어 및 제2 소프트웨어 사이에서 메시지를 전송하기 위한 장치.
제15항에 있어서, 상기 풀 메시지 모드가 선택되면, 상기 풀 메시지 모드는 콜백 기능/프로시저/방법의 호출 이후에 실행 제어를 유지하고 순서화된 메시지에 대한 상기 메시지 핸들러를 폴링하는 어플리케이션에 의하여 진입되는 것을 특징으로 하는 제1 소프트웨어 및 제2 소프트웨어 사이에서 메시지를 전송하기 위한 장치.
삭제
제16항에 있어서, 상기 플랫폼 도메인은 무선 원격통신 시스템의 모바일 터미널용 플랫폼으로 이루어지는 것을 특징으로 하는 제1 소프트웨어 및 제2 소프트웨어 사이에서 메시지를 전송하기 위한 장치.