メッセージ指向ミドルウェア
[Wikipedia|▼Menu]
.mw-parser-output .ambox{border:1px solid #a2a9b1;border-left:10px solid #36c;background-color:#fbfbfb;box-sizing:border-box}.mw-parser-output .ambox+link+.ambox,.mw-parser-output .ambox+link+style+.ambox,.mw-parser-output .ambox+link+link+.ambox,.mw-parser-output .ambox+.mw-empty-elt+link+.ambox,.mw-parser-output .ambox+.mw-empty-elt+link+style+.ambox,.mw-parser-output .ambox+.mw-empty-elt+link+link+.ambox{margin-top:-1px}html body.mediawiki .mw-parser-output .ambox.mbox-small-left{margin:4px 1em 4px 0;overflow:hidden;width:238px;border-collapse:collapse;font-size:88%;line-height:1.25em}.mw-parser-output .ambox-speedy{border-left:10px solid #b32424;background-color:#fee7e6}.mw-parser-output .ambox-delete{border-left:10px solid #b32424}.mw-parser-output .ambox-content{border-left:10px solid #f28500}.mw-parser-output .ambox-style{border-left:10px solid #fc3}.mw-parser-output .ambox-move{border-left:10px solid #9932cc}.mw-parser-output .ambox-protection{border-left:10px solid #a2a9b1}.mw-parser-output .ambox .mbox-text{border:none;padding:0.25em 0.5em;width:100%;font-size:90%}.mw-parser-output .ambox .mbox-image{border:none;padding:2px 0 2px 0.5em;text-align:center}.mw-parser-output .ambox .mbox-imageright{border:none;padding:2px 0.5em 2px 0;text-align:center}.mw-parser-output .ambox .mbox-empty-cell{border:none;padding:0;width:1px}.mw-parser-output .ambox .mbox-image-div{width:52px}html.client-js body.skin-minerva .mw-parser-output .mbox-text-span{margin-left:23px!important}@media(min-width:720px){.mw-parser-output .ambox{margin:0 10%}}

この記事は検証可能参考文献や出典が全く示されていないか、不十分です。出典を追加して記事の信頼性向上にご協力ください。(このテンプレートの使い方
出典検索?: "メッセージ指向ミドルウェア" ? ニュース ・ 書籍 ・ スカラー ・ CiNii ・ J-STAGE ・ NDL ・ dlib.jp ・ ジャパンサーチ ・ TWL(2021年6月)

メッセージ指向ミドルウェア(メッセージしこうミドルウェア、: Message-oriented middleware、MOM)とは、アプリケーションソフトウェア間のデータ通信ソフトウェアであり、一般に非同期メッセージパッシングに基づいたものを指す。

多くのメッセージ指向ミドルウェアはメッセージキューシステムに基づくが、他にもブロードキャスト型のメッセージシステムやマルチキャスト型のメッセージシステムに基づくものもある。
起源

ミドルウェアという概念が登場したのは比較的遅い。1980年代に古いシステムと新しいアプリケーションをどう接続するかという問題の解決策として登場した。それはまた、分散コンピューティングを助長することになった。すなわち、コンピュータネットワーク上で複数のアプリケーションを接続して、全体として大きなアプリケーションを形成するようになったのである。
寓話的解説

大手の銀行の場合を例として考えると、ミドルウェアがビジネスの要求としていかに成長してきたかがわかる。銀行は1960年代から、顧客に関する全ての情報を大規模なメインフレームに格納していた。このメインフレームは何度かの更新を経て、今も現役で使われ続けている。その後、パーソナルコンピュータ (PC) ベースの独立したアプリケーションで顧客にメインフレームには不可能な新たなサービスを提供するようになると、メインフレームの有用性は減少していった。理想としては、PCベースのアプリケーションとメインフレームのアプリケーションが接続され、メインフレームとPCがデータを共有するのが望ましい。メインフレームのデータにアクセスできれば、次の2つの利点が生じる。
新たなフロントエンドとしてのPCアプリケーションは、古くて使いにくいメインフレーム端末を置換できる。

PCベースのシステムは、メインフレームのデータを従来のシステムでは不可能だった新たな方法で活用できる。

1980年代末まで、これらアプリケーションを相互に接続する容易な方法は存在しなかった。開発者はいくつかの問題に直面した。
ソフトウェア開発者は、2つのシステムを接続するに当たって、送信側から送られてきたデータを受信側で扱える形式に変換するためのソフトウェア「アダプタ」を開発しなければならない(双方向通信なら双方のシステムにアダプタが必要)。

一方のシステムの処理速度がもう一方のシステムを制限する。例えば、メインフレームが遅ければ、PCベースのアプリケーションはメインフレームが追いつくまで待つ必要があり、結果としてPCのアプリケーションの速度が低下する。

通信プログラマは、メインフレームのネットワークとPCのネットワークのプロトコルが異なる場合、ゲートウェイシステムを実装する必要がある。このゲートウェイはパケットの中身を変換して双方のシステム間で通信ができるようにする。

このような問題によってアプリケーションの統合は困難となっていた。また、個々のシステムで状況が異なるため、このような統合は個々のシステム毎に設計が必要である。異機種上のアプリケーション間の連結には、オリジナルのシステム開発以上のコスト(場合によっては10倍)がかかった。

複数のアプリケーションの中間に位置して、それらの間の「配管」をする新たな独立したソフトウェアが必要なのは明らかだった。そのようなソフトウェアは、異なるプラットフォーム、異なるプログラミング言語、各種通信プロトコル、様々なハードウェアを扱える必要があった。すなわち、基盤となるインフラストラクチャーの複雑さを切り離すことで、開発者が個々のアプリケーションの機能開発に注力できるようになる。

1980年代末までにミドルウェアがこれら問題への対策として登場した。初期のミドルウェアはサポートするプラットフォームや言語が限られており、有用性は限定的だった。しかし時間とともにミドルウェア製品は複数のプラットフォーム、言語、プロトコルをサポートするようになり、高度化していった。

異機種混合のネットワーク環境で各システムを連結するというミドルウェアの能力は、この技術の利点のほんの一例に過ぎない。2006年現在、ミドルウェアは相互接続可能な既存アプリケーションを増やし、強化する新たな機能を提供している。
利点

メッセージベースの通信プロトコルの利点は、メッセージを送達する過程で保管したり、ルーティングし、変換することが可能な点にある。
格納

多くのメッセージ指向ミドルウェアは、転送されるメッセージのバックアップを保持することで永続性を提供する。すなわち、送信側と受信側は同時にネットワークに接続されている必要はない。これは、ネットワークの品質が低いとか、ユーザーが不定期に接続してくる場合とか、接続に時間制限がある場合など、接続が断続的な場合に特に便利である。また、受信側で問題が生じてアプリケーションが停止してしまっても、送信側はそれに影響されることなく送信を続け、メッセージを格納しておいて、後で受信側アプリケーションが再開したときに処理が行われる。
ルーティング


次ページ
記事の検索
おまかせリスト
▼オプションを表示
ブックマーク登録
mixiチェック!
Twitterに投稿
オプション/リンク一覧
話題のニュース
列車運行情報
暇つぶしWikipedia

Size:13 KB
出典: フリー百科事典『ウィキペディア(Wikipedia)
担当:undef