AMQPは真のビジネス相互運用性をもたらすのか？

作者 Steven Robbins , 翻訳者 編集部 投稿日 2008年8月18日

セクション

運用/インフラ,

設計/アーキテクチャ,

デベロップメント,

エンタープライズ・アーキテクチャ

トピック

メッセージング ,

仕様 ,

インターロップ ,

Architecture ,

オープンソース

タグ

Iona ,

AMQP ,

Middleware management ,

XMPP ,

ビジネスアーキテクチャ ,

CohesiveFT

AMQP (Advanced Message Queuing Protocol)(参考記事・英語) はJohn O'Hara氏によって(リンク)JPモルガン社内で生まれた。だが、彼のビジョンは単なる新しい社内向けのものに留まるものではなかった。AMQPの標準的かつ(リンク) オープンソースのテクノロジー(リンク)は、機運に乗っている。Jeff Gould氏(リンク)とその仲間達はAMQPの成り立ち、AMQPを動かしている人物、そして今後についてヒントを与えた。

IONA Technologies(リンク)はAMQP仕様の貢献者であり、AMQPがどのようなものであり、なぜ注目すべきなのかを説明する短い文章(リンク)を発表した。AMQPとは以下のようなものである。

• 「AMQPモデル（Advanced Message Queuing Protocol Model）」と呼ばれる明確なメッセージング能力セットである。AMQPモデルはメッセージをブローカーサービス内のルーティング、蓄積についての細かく規定された一連のコンポーネントおよびこれらのコンポーネントをまとめるシンプルなルールセットから成る。
• ネットワークワイヤーレベルのプロトコルであるAMQPは、クライアントアプリケーションに、ブローカーに接続させ、実装したAMQPモデルと相互交信させる。

3回にわたるシリーズ(リンク)において、Jeff Gould氏はAMQPの歴史とまた、John O'Hara氏のオープンソースにするという決定について語った。2003年、JPMorganChase用のAMQPプロジェクトの実装にiMatix(リンク)を採用した後、ベータ版が2006年に実用化され、1日あたり3億件前後のメッセージを処理した。

O’Hara氏のAMQP計画はさらに野心的なものでした。彼は始めから、ハイエンドな独自MOMに合わせた新しいプロトコルを実現しようとしていたのです。それはキューを用いたストア・アンド・フォワード方式のメッセージング、Tibco社風のパブリッシュ-サブスクライブ、信頼できるファイルのトランスファーなど、すべての主要なユースケースをハンドルできるものでなければなりませんでした。どんな種類のメッセージでも扱うことができるプロトコルでなくてはならず、それでいて重視されたのはテキストよりも効率的なバイナリーフォーマットでした。これはアプリケーション間メッセージングにおいて、人間の可読性は重要な問題ではないからです。

Gould氏はさらに、AMQPを安全なところから荒野に送り出したのはO'Hara氏のオープンスタンダード化しようとする取り組みであると指摘した。オープンスタンダードにしたことで、Red Hat、Apache、WSO2、IONA、Ciscoなどという企業が呼び込まれた。Red HatのMRGイニシアチブ(リンク)の内部にあるMRG MessagingはApache Qpidプロジェクト(リンク)の実装であり、そのコア・コントリビューターである。LShiftおよびCohesiveFTは「完全かつ高信頼性な企業用メッセージングシステム」であるRabbitMQ(リンク)を共同開発している。RabbitMQはAMQPネットワークの構築または既存ネットワークの強化に利用できる。iMatixのOpenAMQ(リンク)もまた、入手可能なAMQP実装製品である。OpenAMQ は「メッセージによって通信可能な分散型ビジネスアプリケーションの構築基盤となるフレームワークを提供する」製品であるとされている。

このように勢いのあるAMQPと言えど、万人に受け容れられているわけではない。IBMで長年の経験を積んだ人々が率いるLustratus Researchは、2007年時点で、AMQPを採用する心積もりはできていなかった(リンク)。彼らは以下のように述べている。

保証されたメッセージングというのは、その定義から、企業の基幹業務のバックボーンと言っていいでしょう。もし、重要なものでなければ、配信保証がそれほど重要な意味を持つことはありません。では、AMQP の弱点となるのは？もし重要なオンラインシステムを不通にするようなエラーがあったら、誰に助けを求めるのでしょうか？そして、テストの問題に立ち返れば、要求を満たすことを保証するためのストレステストやパフォーマンス調整に掛かる膨大な費用は誰が投じるのでしょう？

Jean-Louis Seguineau氏はAMQPがXMPP pubsub(リンク)によって既に行われていることをやろうとしているに過ぎないと言っている。

XMPP pubsubの拡張によって、既にこれらの機能の多くは対処されています。持続的ノードがAMQPストア・アンド・フォワードキューの役割を担っており、オンデマンドのAMQPキューについては即時ノードが利用できます。しかし、AMQPは明示的にメッセージ属性を利用するコンテンツベース・ルーティングの道を切り開くものでもあります。XMPPではコンテンツベース・ルーティングを定義する、このように明示的な方法を提供していません。それは、pubsubの拡張はこの決定を実装に委ねているからです。

CohesiveFT社のAlexis Richardson氏(リンク)およびRedHat社のCarl Trieloff氏(リンク)はAMQPについて異なる意見を持っている。Gould氏とのインタビューにおいて二人はAMQPの未来についての予想を話した。Richardson氏はAMQPが「現在HTTPとSMTPがうまくできないことすべて」をハンドルするインターネットプロトコルになるのではないかと述べた。彼の予想では、AMQPはビジネス上必要なものを処理するだろう、という。

ビジネスネットワークで必要なものは信頼性であり、トランザクションの整合性です。入力と出力は同じものでなくてはなりません。スマートなルーティングと複数のトポロジーが必要ですし、トラフィックフローを制御し、サーバ同士の連合化を行えなければならないのです。そしてベンダー間および実装間の相互運用性を完全なものにしなくてはなりません。これらすべてが、トランザクション上のビジネスメッセージングを行う上で必要なものであり、AMQPが提供するものなのです。

Trieloff氏はAMQP相互運用性の進捗について触れ、「経験上、実装間の相互運用性は良くなる一方です。これはスペックが向上し、曖昧さが排除されていくからであり、また、開発者が必死でトラックしているからです。相互運用性に対しては、非常に実際的なアプローチが必要だと私は思います」と語った。

AMQPは、現在使用されているようなメッセージ志向のミドルウェアの代替としてはまだ完成されていないかもしれない。しかし、それに近づいていることは確かであり、自前でミドルウェアを構築している、もしくは強化している人なら一見の価値はあるだろう。

原文はこちらです：http://www.infoq.com/news/2008/08/amqp-progress

• 次へ >