2006年6月にAMQP（Advanced Message Queuing Protocol）の標準化のグループの発表がありました。その際に内容を発表していますが、AMQPのサイトにFAQがありましたので、翻訳をしました。もちろん、正式な翻訳ではありません。内容については原文を確認してください。
Q:AMQPとは、どのようなことをやられているのでしょうか？
トランザクションの自動化のために各企業ではオープンな標準を規定しようとしますが、時として、プロトコルスタックの中のメッセージング・レイヤでの独自のソリューションとの連携が必要となり、そのような努力が妨げられてしまうということがあります。このような機能不全やオープンなトランスポートがないことは、標準化への意欲を崩してしまい、Eコマース、分散化システム、電子マーケットプレースや究極には自由な取引自身にも不必要な障害を負わなければならないものとなります。
未だに統一された標準メッセージング・ミドルウェアの提供に成功していない市場の中でもメッセージング・ミドルウェアは、多くのアプリケーションのコンポーネントの中で重要な位置に居続けています。
この問題を解決するソリューションを開発しようとワーキンググループのメンバーは、ビジネス上のメッセージングへの共通の要件に対応しようとするどのようなソースからの実装でも可能なようにAMQPをラインセスフリーなプロトコルの仕様として設計することを決めました。
Q:AMQPはどのようにラインセスされていますでしょうか？
AMQPワーキンググループは、正式にリリースするバージョンの仕様を効率的に利用し、実装してもらうために、ただちに、そして、無条件に、使用許可を出します。AMQPは、関連する権利関係は一切発生しません。詳しくはラインセスについての記述をご覧ください。
最初のバージョン（0.8）は、公開仕様としてグループからリリースされました。2006年12月には、V0-9を公開仕様としてリリースしました。（注：このバージョンは0-9のようにダッシュを伴っていますので、次のリリースは0-10となります。）
ラインセス項目にしたがって、このグループから許可をもらわなくても、誰でも自由にソフトウェアやハードウェアの公開仕様バージョンを実装することができます。ただし、その実装がどのバージョンをサポートしているかを明示しなければなりません。
AMQPバージョン1-0の前にも、更改を続けますが、バージョン間の互換性は保証しません。ただし、互換性をあっさり諦めることがないようにすることも目標のひとつとしてあります。
注意：仕様が変更作業中で、実装の間に重大な非互換の問題を発生させるような未熟な実装には未完成のドラフトの仕様のラインセスを供与しません。
Q:どのアプリケーションのユースケースをAMQPはサポートしますか？
ストアード/フォワード・トランザクションのメッセージングと高性能なパブリッシュ/サブスクライブによるイベント通知、バッチによるファイル転送型のメッセージングの基本的な機能と利用方法を統合しました。
標準的なユースケースは次のとおりです。
| ・ | 価値の高いメッセージを転送する高い信頼性（fire and forgetではなく、一旦、トランスポートでACKを受信したら確実にメッセージが転送されていると完全に信頼することができます） |
| ・ | 規模の大きなコミュニティでの高い性能の状態イベントの通知（パブリシュ/サブスクライブ・イベント通知） |
| ・ | ファイル転送（セキュアで、割り込みが可能で、ファイアウォールに親和性が高く、そして、安心して使える） |
多くのビジネス・アプリケーションは、次のような特徴に大きく依存しています。AMQPは、それらをひとつにして提供します。AMQPベースのミドルウェア・ソリューションについては、典型的なエンタープライズ・ビジネス・システムでのメッセージングだけのミドルウェアをイメージされるかもしれません。
| i) | グローバルなネットワークを通じて、価格や在庫の情報を数百のクライアントへ配信 |
| ii) | これらのクライアントやプロセスからの要求を冗長化したトランザクション処理エンジンを通じて受付 |
| iii) | 内部の台帳、刷り合わせなどのためにバッチファイルを作成し、転送 |
| iv) | バックオフィース処理で必要な情報を転送するためにインターネットを通じて取引先のパートナと接続 |
| v) | 監査にパスするように、これらのすべての機能はセキュアに実行、運用者がシステムをモニタし、制御し、さらに、既存のバックアップ体制との統合を実施 |
| vi) | ビジネス活動のリアルタイムな状況を表示するためにアプリケーション・トラヒックをモニタ |
AMQPのソリューションは、高性能なクラスタリングやグリッド・コンピューティングの課題に対応することができます。ただし、AMQPの本来のゴールはビジネスプロセスでのコミュニケーションの実現にあります。
Q:“ワイヤーレベル”のプロトコルはなんでしょうか？
ワイヤーレベルのプロトコルは、あるAPIを補完するものと考えられます。機能を定義して、ライブラリを作る代わりに、何かを起こすためにネットワーク上を転送するバイトのシーケンスを定義します。
ワイヤーレベルのプロトコルが定義され、公開されると、ほとんどのテクノロジーでそれらを利用することが可能であり、また、ときには、これらを利用することが要件となります。この方法とAPIと比べるとプラットフォームを特定した実際の実装が明らかになります。
JMSはAPIです。HTTPはプロトコルです。AMQPはHTTPに相当するミドルウェアを提供しますが、別の実装を適用することも可能です。
Q:“標準プロトコル”とはどのような意味でしょうか？
AMQPを正式な標準化団体によって準拠できる標準とするようにしたいと考えています。
これについては、AMQPワーキンググループが実際の作業を通じてAMQPを開発することで対応していきます。たとえば、IETF RFCでは、相互運用可能であると実証されている仕様に基づいて最低2つの独立した実装が検証のために必要となります。
ワーキンググループの多くのメンバーが、AMQPの実装に参加しており、このグループの方針として仕様を標準化団体へ委譲することを目標としています。
Q:Java Messaging Service（JMS）とはどのように違うのでしょうか？
JMSはJavaにおけるストアード/フォワードとパブリッシュ/サブスクライブのデファクトAPIの標準です。
JMSは、実装やワイヤーレベルのプロトコルを規定していません。JMSは、テクノロジー中立ではなく、ラインセスの規定によってJavaプラットフォームのみをサポートするのが正規のものです。
AMQPは、JMSを実装するための必要な要件のスーパーセットであり、Linux、Solaris、Windows、Z/OSなどの上のC、C++、Python、C#、あるいは、他の言語のAPIも提供可能です。
Q:APIも規定されますか？
AMQPワーキンググループは、基本的にはAMQPの実装のためのAPIを標準化することは考えていません。
プログラミング環境が、スムースに適合できるようなAMQPのAPIを作り出すことが自然なことです。Java用のAPIはJMSのようになりますが、PythonやCOBOLは、まったく違うものになります。
異なるAPIを定義することにもまして、AMQPに従った実装はシームレスに相互運用可能となります。たとえば、Javaのプログラムは、異なるAPIを使っている.NETプログラムと通信するのにAMQP準拠のJMSを使うことができます。これが、ワイヤーレベル・プロトコルの利点です。
Q:IBM MQSerieseやTibco Rendezvousとはどのような関係になりますか？
MQSeriesやTibco Rendezvousは、その独自のプロトコルと機能で商用のミドルウェア製品をリードしています。しかし、MQSeriesとRVは、お互いに、あるいは、他のミドルウェアとの間でネイティブに相互運用することはできません。
AMQPは、異なるインテグレーション・ブローカの実装の間でも相互運用が可能な仕様です（製品ではありません）。AMQPは、もっとも一般的に使われるミドルウェアの機能を完全に仕様化したプロトコルであり、公平な仕様です。
AMQPベースのソリューションによって、うまく運用されているその他のテクノロジーの利用を止めてしまうことは期待していません。しかし、企業の皆さんが、AMQPを、高い可能性を持つミドルウェアの戦略であると捉えていただきたいと思っています。
どのベンダーでも、もし、そのようにしたければ、それぞれのテクノロジーで自由にAMQP互換の実装を行うことができます。詳しくはラインセス関する記述をご覧ください。
Q:Webサービスとはどのように関係していくのでしょうか？
AMQPは、Webサービスの到達保証のあるトランスポートとして利用できます。AMQPは、ペイロードを定義せずにトランスポート・レイヤーを定義します。つまり、SOAP、WS-Security、WS-Transactions、WS-MetaData Exchangeなど、それ以降の仕様も、すべて、JMSで利用するのと同様にAMQPで実装することが可能です。ただし、AMQPは、トランスポート・リンクの最下位のレベルのベンダー中立な相互運用性を提供します。
Q:AMQPの実装はどこで参照できますか？
AMQPは、製品ではなく仕様です。製品は、ワーキンググループのメンバーか、メンバーでなくても3rdパーティがどこかで開発します。
AMQP製品の記述をご参照ください。
Q:AMQPは実証されていますか？AMQPの利用事例はありますか？
異なるプログラミング言語、複数のプラットフォーム、さらに、仕様が最初にリリースされる以前からある既存のシステムとの相互運用可能な実装を開発するためにプロトコルを規定することはワーキンググループが意識している目的です。
異なる関係者がいっしょに検討を行いながら実際の要件に対して仕様をテストし、改訂していくことだけが、仕様を迅速に成熟させていきます。AMQPは、いくつかの企業の多くの人々からインプットをいただきながら2年間以上開発を続けてきました。
JPMorganでは、ワーキンググループのほかのメンバーと緊密な関係を保つことで、AMQPの異なる実装を利用してアプリケーションを構築することができています。
ひとつは、Javaと.NETクライアントで実現しています。もうひとつは、C/C++クライアントとメッセージ・ブローカー機能をLinux、SolarisとWindows上に実現しています。JPMorganのアプリケーションは、世界の3つの地域データセンターに配置したクラスター化したAMQPブローカーを通じて、数百の同時利用ユーザが情報の参照とトランザクション処理のために利用します。
このAMQPの実装は、移行をスムーズにするために、いくつかのレガシーな独自のミドルウェア製品とのブリッジ機能を提供しています。
注意：JPMorganは、AMQPを実装しているどの製品の性能についてもクレームを表明していません。詳しくは、ラインセス同意規定をご参照ください。
Q:AMQPを自社でどのように適用すればいいでしょうか？
既存の稼動中のミドルウェアをビジネス上の判断もなしにAMQPベースのソリューションへ移行するということは期待していません。仮にビジネス上の判断に反しないとしても満足の行くものとはなりません。
標準ベースのミドルウェアへ移行するという熟慮の末の戦略の一部として機会があるたびに、ビジネス上の通常の手順として、自然な方法で企業がAMQPを適用することを期待しています。このアプローチでは、競合力のある価格やオープンソースの利点を享受することができ、それらを実現する共通の規約や製品の経験を積むことができます。2から3年の経過とともに多くの要求は、このようなアプローチからAMQPとして実現していきます。また、既存のミドルウェアの供給元がAMQPを実装することも可能であり、標準ベースのモデルへの移行することができます。結果的にAMQPがネットワーク・インフラの中核となるサービスとなることを希望します。
一方、企業がサービス指向アーキテクチャ（あるいは、バス・ベース・アーキテクチャ）へ投資するならば、SOAのバックボーンとしてAMQPを一括して配置することを勧めます。そのようにするとAMQP互換のミドルウェアのサプライヤー同士の競争から利点を得ることができるでしょう。そのために、適切なサプライヤーから要件にあったサポートのレベルやサービスの品質を達成することができるかもしれません。AMQPの適用によって、企業のSOAで重要なバス・コンポーネントへの長期投資に対するベンダー・ロックインやサプライヤーの倒産などの心配事に対応することができます。同様のことが、インターネットや専用線を介した取引パートナとの間で適用しているeビジネスのオープンなプロトコルについても当てはまります。
注意：AMQPワーキンググループは、AMQPを実装しているどの製品の性能についてもクレームを表明しません。詳しくは、ラインセス同意規定をご参照ください。
Q:どのプラットフォームがサポートされますか？
このプロトコルは、プラットフォームとプロトコルに中立であるように設計されています。
ワーキンググループのいくつかの企業が、様々なプラットフォーム上にAMQPベースの製品をリリースすることを期待しています。
Q:某社はなぜAMQPのワーキンググループに参加していないのでしょうか？
ほとんどのミドルウェア・サプライヤーはAMQPプロジェクトを意識しています。さらに、いくつかは、この活動に参加していただいています。しかし、すべての関係者にアプローチすることができません。そして、すべての企業が今参加する必要があると思えるわけでもありません。
もし、あなたが、ベンダーの方であり、この活動に参加したいと思われるのであれば、ご連絡を御願いします。さらに、ミドルウェアのエンドユーザの方で、もっとも、気に入っている製品がAMQPをサポートしてほしいのであれば、そのサプライヤーに要求をあげてください。
Q:マルチキャストはAMQPでどのように扱われますか？
クラスタやグリッドで分散化したサブネットの最適化のためにマルチキャストを仕様化する作業を進めています。
AMQPは、サブネット間の信頼性の高いマルチキャスト・メッセージ転送の明確な方法を定義しています。PGMのようなトランスポートでは、サブネット内のパブ/サブのAMQPメッセージの最適化を実現するでしょう。
検討の完成を目指して作業中ですが、できれば、PGMからAMQPへ、および、AMQPからPGMへの双方向で適正な相互運用性が得られることを期待している。
Q:AMQPはメイルとどのように違いますか？
裸の王様の話のように考えるとミドルウェアとメイルは同じことです。
AMQPはメイルに似ていますが、サービス品質（QoS）の実現を明示的に制御します。
メイルでは不明確なこともAMQPは定義します。たとえば、メッセージのサイズ、信頼性、セキュリティ、廃棄するためのポリシー、TTL、高速なグループ配信、1対Nの配信など。
重要なのは、メイルにはない、メッセージを転送する先のAMQPシステムの認証を行うことです。それによって、ビジネス上のメッセージングで重要な迷惑メッセージを無くすことができます。
Q:Spread、ICE、Elvin、TAO、Muscleなどとはどう違うのでしょうか？
多くのミドルウェア・ソフトウェア・パッケージがあり、それぞれ、異なる用件に対応しています。
しかし、AMQPはソフトウェア製品ではありません。メッセージング・ミドルウェアのための文書化したプロトコルの定義です。
プロトコルとしてのAMQPは、このFAQの中にもあるように、ビジネス上の信頼性の高いメッセージングに必要なメッセージ交換機能に重点的にフォーカスした大変ユニークなものです。
Q:CORBA/IIOP、DCEやONC RPCとはどのように違いますか？
CORBA/IIOPは、リモートのオブジェクトを引用するワイヤーレベルのプロトコルです。オブジェクトを操作して、メソッドを呼び出します。これは、“インタフェース”（繊細な）を操作するDCOMやプロセスを操作するONC/RPC、DCEとも異なります。
すべてがネットワーク上の呼び出しで同期されて、メッセージの保証やキューイングの考え方はありませんが、QoSについて若干考慮しています。このようなプロトコルは、それぞれの位置づけをもっていますが、完成はしていません。IIOPも、実際のアプリケーションのシナリオで問題となっているファイアウォールへの対応はよくありません。
AMQPは、概念的にはCORBA Notification ServiceとCORBA Event Serviceと似ています。しかし、実際には仕様の複雑さや完全なORBが必要となることからNotificationとEvent Serviceの部分的な実装でも多くは存在しません。このような複雑さによって適用を広げる際に敏感に反応することができなくなります。
結局、メッセージングは、オブジェクトのトランスポートレイヤーの上ではなく下に組み込まなければなりません。つまり、メッセージングは、オブジェクト・メソッドの呼び出しより一般的な位置づけです。
Q:仕様（あるいは、メイリングリストのアーカイブ）はどこにありますか？
開発のためのアーカイブや開発者のメイリングリストへのリンクは、まもなく公開されます。