2006年6月にAMQP（Advanced Message Queuing Protocol）の標準化のグループの発表がありました。その際に内容を発表していますが、AMQPのサイトに概要の説明がありましたので、翻訳をしました。もちろん、正式な翻訳ではありません。内容については原文を確認してください。AMQPは非常にユニークなアプローチだと思います。また、アイオナでは、AMQPを実装したオプションをCeltix Advanced Messagingとして発表しています。
AMQPとは？
AMQPはメッセージング・ミドルウェアのオーブンな標準です。
ミドルウェアとは、他のソフトウェアに接続するためのソフトウェアです。また、企業内と企業の外部のシステムの両方に対して、システム化された孤島同士を連携するものです。
AMQPの標準に従えば、異なるプラットフォームの異なる言語で書かれたミドルウェア製品は、その他のミドルウェア製品との間でメッセージを送ることができなければなりません。AMQPは、企業内、および、企業間でメッセージとビジネス上の価値を迅速に転送しなければならないという要件に対応するものです。
どうして注目に値するのでしょうか？
メッセージングとインテグレーションはすべての企業システムの一部として必要なものです。
| ・ | ITによるシステム化の著しい努力には、すべて、メッセージングとインテグレーションを伴います。（プロジェクト費用の10％から30％） |
| ・ | ベンダー独自のミドルウェア製品は、ミドルウェアの選択上の品質とコストの両面の競争を阻害するロックインの根本原因となります。 |
| ・ | 相互運用性は必要です。しかし、簡単には実現できません。 |
通常のオープンなビジネス標準は理論的にはベンダー独自のテクノロジーを基にしないで、オープンな情報とビジネスのプロセスモデルとオープンなメッセージのフォーマットを利用しています。しかし、メッセージングのための適切なオープン・テクノロジーは実際には存在しません。
AMQPは、メッセージング・ミドルウェアのデファクトとなるオープン標準になることを目指しています。
AMQPはどのように他のミドルウェアの標準と異なるのでしょうか？
AMQPが他のミドルウェアの標準と異なる点は：
| ・ | 単純明快で、かつ、完成度の高いビジネス・メッセージングのソリューション |
| ・ | 完全にオープン |
| ・ | ユーザとベンダーなどの技術担当者の共同作業の結果 |
| ・ | 現実の要件に対応 |
| ・ | ひとつの仕様で、1対1のメッセージ転送とパブリッシュ／サブスクライブの型の両方を規定 |
AMQPは、ビジネス・アプリケーションが共有することのできる基本的なメッセージング・ミドルウェアを規定することを目指します。
どのようなAMQPの仕様が規定されていますか？
メッセージング・ミドルウェアの完全な相互運用を実現するために、AMQPではネットワーク・プロトコルとブローカーのサービスの動作の両方を規定しています。
AMQPは次のように構成されます。
| ・ | “AMQPモデル”と呼ばれるメッセージング機能を定義。AMQPモデルは、ブローカーのサービス内のメッセージのルーティングや蓄積についての詳細な仕様で定義されたコンポーネントから構成されており、コンポーネント同士を結びつけるシンプルなルールを規定 |
| ・ | ネットワークのワイヤーレベルのフォーマットによりクライントがブローカーと接続し、AMQPモデルにしたがった実装との通信が可能 |
これは、AMQP仕様によってサーバのセマンティクスの一部をそのまま実現することができることを意味しています。ただし、実際には明示的に実装することでプロトコルの理解を進めることができます。
なぜ、AMQPは開発されたのでしょうか？
ほとんどのネットワーク・プロトコルの方式では対応が可能とされていますが、メッセージを保証することが可能な共通に利用できるミドルウェアを考えると現実との隔たりがあります。ミドルウェアは利用価値の高いユーティリティです。中堅企業や大企業でのミッションクリティカルなITシステムをサポートし、ビジネスプロセスの自動化を支えるキーとなる役割を果たしています。
しかし、現在、JMSは解決策として一部しか対応していません。Javaの信頼性に制約があり、ワイヤーレベルの相互運用を規定することができません。どのようなソリューションが、この問題に対応するとしても、プラットフォームや言語に囚われずにオープンな方針の下で実現できることが重要です。
Advanced Message Queuing Protocol（AMQP）は、既存のシステムとのインテグレーションを行う新たな製品の基盤となり、さらに、JMSなどのAPIの相互運用を改善していくために利用できます。
AMQPは、JMS、SOAP、WS-Security、WS-Transactionなどのほとんどの既存のメッセージングやWebサービスの仕様を補完しながらいっしょに利用することができます。AMQPは、ネットワークを最適な状態で使えるため、あるいは、グリッド型の配置を可能とするためにマルチキャストによる双方向のルーティング機能を提供します。
AMQPモデル
相互運用のためには同じセマンティクスが必要であるので、AMQPモデルは、サーバのセマンティクスを明示的に定義します。また、コンポーネントのモジュールを特定し、これらのコンポーネントへの接続のための標準的なルールを規定します。
このモデルは次のような3つの主要なコンポーネントのタイプがあります。これらのコンポーネントは必要な機能を提供するプロセスの連鎖に組み込まれます。
| ・ | “exchange”はパブリッシャであるアプリケーションからのメッセージを受信し、メッセージのプロパティや内容そのものから得られる排他制御の設定にしたがって、それらのメッセージを“message queue”へ転送します。 |
| ・ | “message queue”は、利用者側のクライアント・アプリケーション（あるいは、複数のアプリケーション）が確実に処理できるまでメッセージを蓄積しています。 |
| ・ | “binding”はmessage queueとexchangeとの間の関係を定義し、メッセージをルーティングする基準を規定します。 |
このモデルでは、ストアード／フォワード・キューやトピック購読の従来のミドルウェアの概念をエミュレートします。また、コンテンツ・ベース・ルーティング、メッセージ・キューの生成、随時利用のメッセージ・キューなどのちょっとした概念についても指定します。
大雑把な言い方をするとAMQPサーバはメイルサーバに類似しています。つまり、exchangeはメッセージ転送エイジェント（MTA）に、メッセージ・キューはメイルボックスということになります。bingingは転送エイジェントの中にルーティング・テーブルを定義します。パブリッシャは、それぞれの転送エイジェントにメッセージを転送し、メッセージはメイルボックスへルーティングされます。利用者はメッセージをメイルボックスから取り出します。これによって、強力で柔軟なモデルをシンプルに定義できます。
AMQPワイヤー・フォーマット
AMQPのワイヤー・フォーマットは、最新の特徴を備えたバイナリによるフレームです。これは、マルチ・チャネル対応可能、すでに協議済み、非同期対応、セキュリティ対応、移植可能、中立であり、効率的であるなどの特徴を備えています。
AMQPワイヤー・フォーマットは二つのレイヤに分かれます。機能レイヤとトランスポート・レイヤです。機能レイヤは、アプリケーションに代わって、その役目を果たすコマンド（各機能を論理的なクラスにグループ化したもの）の組み合わせとして定義されます。トランスポート・レイヤは、このようなメソッドをアプリケーションからサーバへ双方向で転送し、多重なチャネルの制御、フレームの構成、内容のエンコード、ハートビート、データ表示やエラーハンドリングなど行います。トランスポート・レイヤと機能レイヤの両方とも、プラグイン構成でプラグインによるカスタマイズが可能です。これによってプロトコルの刷新や新たなテクノロジーの適応に対応できます。
AMQP仕様のダウンロード
仕様はAMQPユーザのページからダウンロードできます。
AMQP製品の検索
AMQP製品のページをご参照ください。