メッセージ (コンピュータ)
 | 原文と比べた結果、この記事には多数の（または内容の大部分に影響ある）誤訳があることが判明しています。情報の利用には注意してください。 (2019年8月) |
計算機科学におけるメッセージ (英: message) とは、情報の伝達を目的とする、順序付けられた文字列である。JISでは、情報理論および通信理論におけるmessageの訳語として通報[1]という用語が割り当てられている[注釈 1]。
メッセージパッシング (英: message passing) とは、並行計算・並列計算、オブジェクト指向、プロセス間通信で使われる通信方式である。プロセスもしくはオブジェクトといったモデルではメッセージ（ゼロ以上のバイト、複雑なデータ構造、プログラムコードも含む）を送ったり受けたりできる。メッセージを待つことによって同期することもできる。メッセージパッシングに基づく主なモデルとしてアクターモデルやプロセス代数がある。
概要
[編集]メッセージパッシングは、ひとつもしくは多くの受信者 (receiver) に対して送信者 (sender) がデータを配送できる通信方法である。通報の形として遠隔メソッド呼び出し（英: remote method invocation; RMI）、シグナル、データパケットなどがある。メッセージパッシング機構を設計するとき、下記のような方針から設計方針を選択する。
- 個々のメッセージの送受信を確実に行うかどうか
- メッセージが送信した順序通りに受信されることを保証するかどうか
- メッセージのやりとりは一対一、一対多(マルチキャストもしくはブロードキャスト)、多対一(クライアントサーバモデル)か
- 通信の同期が必要か
重要な理論上の基礎であるアクターモデル、プロセス計算といった並行計算はメッセージパッシングを基礎としている。メッセージパッシングを使った並行システムは、言語内の機能としてメッセージパッシングする場合と言語からの一連のライブラリ呼び出しで実現する場合がある。 前者の例は多くの分散オブジェクトシステムが含まれる。後者の例としては、カーネルとサーバブロック間でメッセージをやりとりするマイクロカーネルオペレーティングシステムや、高性能計算における Message Passing Interface がある。メッセージパッシングの概念は、グラフモデル上のベイズ推定などでも使われている。
オペレーティングシステムにおけるメッセージ
[編集]Microsoft Windowsなどのオペレーティングシステムにおいて、メッセージとは、オペレーティングシステム上で動くアプリケーションに対して、オペレーティングシステムが管理しているデバイスあるいは別のプロセスやスレッドからの入力を伝えるために送られる、ひとかたまりのデータ集合のことである。メッセージを送受信することを通知とも呼ぶ。
オペレーティングシステムはメッセージをメッセージキューに保管し、アプリケーションはメッセージキューに保管されていたメッセージを受け取り、それを元に処理を行う。例えば「画面座標 (10, 20) の位置をマウスで左クリック」という情報をオペレーティングシステムが感知した場合、オペレーティングシステムはその情報をメッセージキューに保管する。アプリケーションはそのメッセージを受け取って対応した処理を行う。
アプリケーションは常にオペレーティングシステムからのメッセージを待機するようなイベント駆動方式のプログラムになっており、この一連のプログラムの機構をメッセージループという。メッセージキューを定期的に監視・確認するポーリング方式でメッセージループが実装されることもある。
メッセージパッシングシステムとモデル
[編集]分散オブジェクトや ONC RPC、CORBA、Java RMI、DCOM、SOAP、.NET Remoting、WCF、CTOS[要説明]、QNX Neutrino RTOS、OpenBinder、D-Bus のような遠隔メソッド呼び出しあるいはそれに類するものはメッセージパッシングシステムである。メッセージパッシングシステムは共有のないシステムと呼ばれている。なぜならば、メッセージパッシング型のシステムは、メッセージという抽象化によってその下位に存在する状態変化や実装などを隠蔽するものだからである。
メッセージパッシングモデルはデータを端末（アクター、プロセス、スレッドなど）に送信するような通達方式で、プログラミング言語で典型的に定義されている。そのようなメッセージングはSOAPによってWebサービスの中で使われている。この考え方はパケットより大きく、任意に信頼性や耐久性や安全性やトランザクションを追加したものを除く高いレベルのメッセージデータグラムである。メッセージもまた一般的に同じ向きのプロセス間通信に使われる。また別の一般的に使われる技術はストリームもしくはパイプで、そのようなデータは初歩的なデータアイテムの一連として送信される（仮想回線の高等レベルでは）。
同期通信と非同期通信
[編集]同期メッセージパッシングシステムでは送信者と受信者がお互いにメッセージの転送を待つ。つまり、送信者は受信者がメッセージを受信するまでプログラムを再開できない。
同期通信は二つの利点がある。利点の一つ目はメッセージ転送において送信者と受信者で同期をとるため、プログラムを単純化できることである。利点の二つ目はバッファを必要としないことである。メッセージはいつでも受信側に保存される。なぜならば、送信者は受信者の準備が完了するまで送信を待つためである。
非同期メッセージパッシングシステムは受信者から送信者に準備ができる時間を待たずにメッセージを送る。非同期通信の利点はお互いに待つことがないので、お互いの計算処理をオーバーラップして行える。
同期通信は送信者がいつも受信者が続ける前にメッセージを応答したことを確実にする非同期通信をベースに築かれている。
非同期通信はバッファを必要とするが、そのバッファが満杯になると問題の原因になる。送信者をブロックするか今後のメッセージを切り捨てるか判断をしなければならない。送信者をブロックすれば、予期しないデッドロックを引き起こすかもしれない。メッセージを捨てた場合通信の信頼性は無くなる。
メッセージパッシングと関数呼び出しの比較
[編集]メッセージパッシングはプログラム間で情報を受け渡すためのもうひとつの通信方法、つまりCallと対比されるべきである。伝統的なCallにおいては、引数は典型的には一つ以上の汎用レジスタまたは引数のアドレスを内包しているパラメータリストを通じて、"callee" すなわち「呼び出し先」（receiver: 受信者）に渡される。この通信形式はメッセージパッシングと比較して少なくとも三つの大きな違いがある。
- 合計メモリ使用量
- 通信速度
- ローカリティ
メッセージパッシングではどの引数も、新しいメッセージの中にコピーするのに十分なメモリを余計に必要とする。これはオリジナルの引数のサイズの大小によらない。したがって、もし引数のうちのひとつがwebページを記述する10,000オクテットのHTML文字列だとすると、受信プログラム（ローカルプログラムでないならば）に完全にコピーされなければならない（そしてさらに送信されなければならないだろう）。 対照的に、callの手法ならば、それぞれの引数に対して4から8バイト分のアドレスしか必要としない。さらに汎用レジスタならば追加の記憶領域はゼロであり、送信時間もゼロである。これはもちろん分散システムでは不可能である。というのも、呼び出し元 (caller) のアドレス空間における（絶対）アドレスは、リモートプログラムでは通常意味をなさないからである。ただし、もしcalleeが前もってcallerのメモリの正確な（少なくとも一部の）コピーを有していたならば、相対アドレスが利用できるかもしれない。
メッセージパッシングスタイルの例
[編集]他のプログラミングモデルへの影響
[編集]オブジェクト指向の幾つかの専門用語の中にメッセージはオブジェクトにコントロールを渡すという意味で使われる。もしオブジェクトがそのメッセージに応答したならばそれはそのメッセージに対するメソッドを持っている。詳しくはオブジェクト指向プログラミングを参照すること。
純粋なオブジェクト指向ではメッセージパッシングは排他的にダイナミックディスパッチに投げられる様に機能する。
同じメッセージを二回同じオブジェクトに送信した場合、普通そのメソッドを二回請求する結果となる。もし、名前と引数が同じならば二つのメッセージは同じメッセージタイプと考えられている。
オブジェクトは自分のメソッド本体から他のオブジェクトにメッセージを送信できる。メッセージパッシングシステムの中で、究極遅延束縛 (英: extreme late binding) が可能である。
アラン・ケイ は彼の視点のオブジェクト指向プログラミングの中ではオブジェクトよりも重要なコンセプトだが、人々はよくそのポイントと場所を見逃し、オブジェクト自体に重点をおきすぎ、十分メッセージをその間に送ってないと主張した[3]。ライブ分散オブジェクトのプログラミングモデルはこの所見を踏まえて作られた。それは分散型データフローのコンセプトを使い複雑な分散型システムの振る舞いをメッセージパターンの（高レベル）機能スタイル仕様書とみなした。
幾つかの言語では、あるオブジェクトがメッセージを処理するメソッドを持っていなくとも、それを持っているであろう他のオブジェクトを知っている場合に、メソッド呼び出しを1つのオブジェクトから他のオブジェクトに転送、もしく委譲することをサポートしている。メッセージ転送を参照。
1977年、カール・ヒューイットは、計算制御構造は「メッセージパッシングのパターン」と見ることができると主張した[4]。
Smalltalk系統の言語におけるメッセージ
[編集]Smalltalk及びSelfやObjective-CなどSmalltalk系統のオブジェクト指向言語においてメッセージは、メソッドを起動するセレクターと引数の組み合わせ、およびセレクターと引数を合わせたオブジェクトを示す[5]。
result := receiver + 1.
result := receiver selector.
result := receiver selector: 0 and: 2.
例えば上記の式であれば、+ 1とselectorとselector: 0 and: 2が前者のメッセージとなる。C++系統の言語におけるメンバー関数の呼び出しに類似しているが、Smalltalk系統の言語はメンバー関数の実装部分にあたるメソッドとメッセージは独立した存在であり、メッセージはクラスに紐づかない。また、必ずしもセレクターとメソッドは一対一ではなく一つのメソッドに複数のセレクターを取り付けることができ、セレクターが異なるメッセージを同じメソッドで処理することができる[注釈 2]。また、メッセージと対応したメソッドが一切存在しないオブジェクトでもメッセージを受信することが可能になっている[注釈 3]。
脚注
[編集]注釈
[編集]出典
[編集]関連項目
[編集]- イベント駆動型プログラミング
- メッセージループ
- メッセージ指向ミドルウェア
- IoC
- en:Active message
- en:Database-centric architecture
- en:Dynamic dispatch
- en:Message loop in Microsoft Windows
参考文献
[編集]- “GNU Smalltalk Library Reference: Behavior-method dictionary”. www.gnu.org. 2018年9月20日閲覧。
- “Pharo source documentation” (英語). magaloma.seasidehosting.st. 2018年9月3日閲覧。
- JIS X 0016:1997「情報処理用語（情報理論）」（日本産業標準調査会、経済産業省）
- JIS X 3003:1993「電子計算機プログラミングFull BASIC」（日本産業標準調査会、経済産業省）
- Hewitt, Carl (6 1977). “Viewing Control Structures as Patterns of Passing Messages” (pdf). Journal of Artificial Intelligence.
- Ramachandran, U.; M. Solomon, M. Vernon （1987年）"Hardware support for interprocess communication." Proceedings of the 14th annual international symposium on Computer architecture, ACM Press
- McQuillan, John M.; David C. Walden （1975年）"Some considerations for a high performance message-based interprocess communication system." Proceedings of the 1975 ACM SIGCOMM/SIGOPS workshop on Interprocess communications, ACM Press
- Shimizu, Toshiyuki; Takeshi Horie, Hiroaki Ishihata （1992年）"Low-latency message communication support for the AP1000." Proceedings of the 19th annual international symposium on Computer architecture, ACM Press
