Essence is Real

ThinkITには、時々、記事を書かせていただいているのですが、アイオナが中心となってObjectWebでホストされているCeltixのバージョン1.0についての紹介記事を3回に分けて掲載していただいています。オープンソースのESBにどの程度の関心がおありになるのかは、正直、よく理解していませんが、ソフトウェアベンダーのほぼすべてがSOAを標榜している中で、ESBはSOAの基盤として必須のものであると考えると関心があってもいいのではないかと思います。いかがでしょうか。

Celtixは、サンプルを23個バンドルしているので、それを中心に記事を書こうと持ったのですが、23個のサンプルを確認しながらREADMEを翻訳するという作業の結構時間がかかってしまいました。また、CeltixがヨーロッパのObjectWebからApacheに移行することが決まっており、CodehausのXfireと合併して、ApacheのインキュベートであるCeltiXfireが開始しているので、サンプルの記載は、まだ、遅れています。

江川

eWeekのApplication Developmentの中の製品レビューのコーナーでアイオナのArtix 4.0を含むESB製品の評価が掲載されています。元来、製品を単純に比べて比較することにどれくらい意味があるのかは疑問ではありますが、eWeekの記事は非常に簡単で大雑把なので、その点では、大まかな比較としてのご参考にはなるかと思います。

現時点で比較対象となっているのが、アイオナのArtix4.0、Cape Clear Software Cape Clear ESB 6.6
、Sonic Software Sonic ESB 7.0です。比較項目毎の評価は次のとおりです。

よく機能を比較して、○×△で評価する場合がありますが、実際には、どんな機能が必要であり、どのようなアーキテクチャがベストであるかを検討されるべきです。その点では、ArtixについてはSCALABILITYはEXCELLENTにしてほしいところです。WebコンテナもEJBコンテナも必要ないし、ブローカも必須ではないですからアーキテクチャ上、SCALABILITYにボトルネックはありません。

もう、一点の着目点は初期費用ですが、これについては詳しくは記事をご覧ください。ただし、記事はUSでの内容ですので日本での費用は異なります。

江川

2006年9月24日の日経新聞に「航空機市場の拡大」という記事が載っていました。ここで、CORBAがボーイング社のシステムで使われているということをお話したいわけではありません。中小型機の売り上げが伸びているという話題です。

航空機の大手2社（米ボーイング社と欧州エアバス社）の2005年の受注数は、2004年の3倍となっています。その中で、中小型機で、たとえば、ボーイングのB787やB737の受注が伸びており、一方、大型機の需要が伸び悩んでいます。この状況のひとつ目の理由は、格安航空会社の伸びです。コストを削減するために小型の同一機種を大量に運行させること、需要に柔軟に対応できるからです。二つ目の理由を引用すると次のようになります。

航空会社のニーズの変化があります。従来は大規模な空港を拠点（ハブ）とし、ハブ空港を経由して他の都市に向かう「ハブ・アンド・スポーク」の運航が中心でした。しかし、最近利便性を求める顧客の声を受けて、できるだけ多くの都市間を直行便で結ぼうとする動きが広がっています。
経済発展に伴って途上国間を移動する旅客数が急速に増大していますが、これまでのように先進国のハブ空港経由では時間がかかりすぎ、客を逃してしまいます。特にインドと中国で旅客需要が急増していまっす。こうしたことが中型機B787の人気を高める要因となっています。

インテグレーションの需要は、トップダウンで発生するものではなく、ボトムアップでエンドポイントから発生します。つまり、ハブではインテグレーションの市場を制御することはできないということです。エンドポイントの重要性を再認識し、いかに、エンドポイント同士を有効に連携するかを決めるのが、ESB（Enterprise Service Bus）のアーキテクチャです。

江川

少し以前（2006年7月10日付け）のSearchWebService.comの記事ですが、原題は、

Analysts see Java EE dying in an SOA world

すべてを、そのまま受け取ることもできないのですが、私の意見としては、ひとつは、JavaEEはアプリケーションを開発するためのプラットフォームであり、エンタープライズ全体のインフラを支える基盤としては重過ぎるということと二つ目は、SOAは抽象化度を上げていくのが、アーキテクチャの目標となるべき課題であり、抽象化度を上げるためにはLayered構造になっていることが必然であるとするとMVCモデルのようなTiered構造ではアプローチとして無理があるということです。ただし、SCA（Service Component Architecture）などの動向を見極める必要はあります。

江川

Artix 4.1をリリースしました。今年の4月に発表したAmberPointとの連携の実装が進んで実際に利用できるようになったことが一番大きなトピックですが、従来予定していたエンハンスを施してきたことになります。少々、他と比べると対応が遅かったのですが、SOAP 1.2をサポートしましたのでインタオペラビリティーを確保しています。ESBの中に組み込んだBPELエンジンであるArtix Orchestrationでサービスをくみ上げますが、このArtix Orchestrationと従来からあるArtixのQoSの機能を連携することによって、本来のBPELエンジンによるコンポジットサービスの実現が可能となります。

業界に買収風が吹き荒れる中では、地味な発表ですが、インフラを提供するベンダーとして、確実に製品を組み上げていくことは非常に重要なことと考えています。

江川

11月6日（月）の日経産業新聞に、”「悪役」P2P-動画で見直し”という記事がありました。”ナップスター”や”Winny”のために著作権問題やウィルスの温床としての評判の悪さが知られていましたが、P2Pは、従来から注目されているように新しいビジネスモデルとしても、技術上の選択肢としても非常に重要な視点であると言えます。

日経産業の記事では、従来、サーバから一律コンテンツを送信しているのに比べてP2Pを利用すると通信量が減ることになり、100万人向けに配信するのに、4億5千万円の通信費用がかかるのに、P2Pでは5分の1から10分の1にコストを軽減でき、アクセスの集中による動画が見られないということも解消されるということです。

このブログはミドルウェアについて徒然に公開しているので、P2Pそのものの議論ではないのですが…EAIの流れを汲む、ESBは、インハウスのインテグレーションの問題に対応するものであると暗黙に認識されていますが、Webサービスは、インターネット上でIPの上位に搭載されるミドルウェアの層のプラットフォームと考えることができます。Web2.0でもプラットフォームという言葉が出てくるようにインターネット上に高度に抽象化されたプラットフォームが出現するはずです。

Webサービスについては、様々な仕様がOASISで議論されていますが、製品としてはESBによって体系化されます。つまり、OSASISの仕様が決まっていようが、未定であろうが、ESBはプラットフォームとして機能を提供しなければなりません。つまり、インターネット上に新しいプラットフォームはESBが担わなければならないことになると考えられます。

しかし、一般のインターネット上には、インハウスでのアーキテクチャをそのままインプリすることはできません。つまり、インターネット上に全体最適を目指すようなハブ＆スポークのアーキテクチャを実現することはナンセンスです。あるいは、インターネット中にメッセージングのためのブローカを配置することもとても得策とはいえません。つまり、インターネット上には、P2Pのアーキテクチャを配置することが、合理的だということです。

P2PによるESBはエンドポイントにESBの機能を集約している必要があります。また、PCをはじめとするインターネットに接続するすべてのデバイスがエンドポイントとして扱える必要があります。これによって、インターネット上のESBが実現できると考えます。このときには、ESBは、バスではなくネットワークでなければならないわけですからISN（Internet Service Network）という名前がいいかもしれません。Artixは、その可能性を持っていると思います。

江川

2年くらい前の米国のeWeekのサイトに「Move Over, EAI」という記事が、記載されています。Webサービスが広まることで、従来のEAIアダプタによってインテグレーションを行っていたのが、大きく変わるという内容です。記事の中で、主要なEAIベンダーのマネージャもWebサービスが台頭することを肯定していますが、2年経った、今現在、EAIのアダプタがすべてWebサービスに置き換わるという勢いとはいえないと思いますが…

パッケージベンダーはWebサービス化を進めているのは、もちろんですが、ユーザ側でも次のプロジェクトではWebサービスを使うと普通に考えられるようになっているので、EAIアダプタの適用にも変化が出て繰るのではないかと思います。アダプタと言っても、いくつか種類があります。テクノロジー・アダプタと呼ばれるトランスポートの違いをサポートするもの、アプリケーション・アダプタと呼ばれる、たとえば、ERPと連携するための特別なアダプタ、あるいは、データベースと連携するためのDBアダプタなどです。

このうちのテクノロジー・アダプタは確実にWebサービスに替わっていくものだと思いますが、そのときはESBということになっているかもしれません。アプリケーション・アダプタは、機能として、アプリケーションやデータベースのスキーマを意識したものとなるので、個別の追加機能として提供されるようになるのではないでしょうか。つまり、Webサービス（あるいは、ESB）を基盤として、その上にアプリケーション毎の連携機能が搭載されるというイメージです。

いままでアダプタを介して、異なる言葉が通訳されていたとするとWebサービス（あるいはESB)は、直接、ユーザ同士が直接コミュニケーションする共通言語のようなものとなるのではないでしょうか。ちょうど、英語のようなものです。豊かなコミュニケーションが、通訳を介するか、あるいは、直接話しをすることのどちらで得られるか？私は後者であるべきだと思います。

時として、通訳が必要となることはあるでしょうが、通訳の方はアプリケーションの本質は理解できなし、時間単位でコストがかかります。これは、特別な場合であると思うべきではないでしょうか。多少、勉強しなければならなくても、Webサービスというツールがある以上、カスタマイズを加えて、直接、連携することを考えてもいいのではないでしょうか？

江川

しばらくサボっていました。その後、プロジェクトに引き込まれてしまったので、未だに更新ができていません。CORBAの文化を引き継いだESBであるArtixがCeltixはエンドポイントにすべてを集約する考え方でエンドポイントを組み合わせることでESBを構成します。メディエーション（仲介機能）などのためにスマートブローカと称する軽量で柔軟な構成の組めるブローカも作ることができますが、Java EEなどを前提とせずにエンドポイントにESBの機能を集約していることは構成を組む上で非常に有利となります。エンドポイントESBのロゴを作ろうかと思ってスライドの中から取ってきたものです。

江川

ドラッガーの言葉です。BEA Japan Forum 2006の午前中のパネルで三菱東京UFJ銀行のCIOの根本氏が、お話の中で引用されていました。実は2004年にお話を伺っているのですが、そのときに比べてSOAの導入に対して、他に選択の余地はないというくらい積極的にお話になっておられ、かつ、背景や技術、想定できる結果までも実にクリアにお話になっておられたことが非常に印象的でした。

タイトルの言葉の意味は、文字通りですが、その基礎は、すべてが変化することは必然であるということです。しかも、変化が起きて、周知のことになってからでは遅すぎるということも含んでいます。自らが変化を作り出していくことで変化への対応を実現するという逆説的な意味もあるかもしれません。

ビジネスの変化ということはよく言われますが、テクノロジーの変化やアーキテクチャの変化についてはあまり真剣に話をされていることを聞いたことがありません。ビジネスの変化に対するSOAのソリューションを支えるテクノロジーも変化すると考えるべきです。これまでも新たなテクノロジーやソリューションが出現すると古いテクノロジーは捨てられて、システムの再構築となっていました。

しかし、新しいテクノロジーに乗り換えるために、たとえば、5年に1回、ガラガラ、ポンでアプリケーションからシステム基盤を入れ替えていたなら大変な浪費といえます。つまり、テクノロジーの変化に対しては、特定のテクノロジーに依存しない”テクノロジーに中立”なフレームワークが必要となります。

一方、アーキテクチャの変化については、アーキテクチャが変化してしまっては、その上に乗るアプリケーションは対応できないのではないかという懸念があります。つまり、あるアプリケーションはあるアーキテクチャに依存しているということになりますが、すべてが変化することからアーキテクチャも変化することを前提とすべきです。

エンドポイントにESBの機能を集約し、分散アーキテクチャで仮想のバスを構成するArtixは、エンドポイントを組み合わせることでアーキテクチャを柔軟に変化させることができます。エンドポイントでESBの機能が完結することで自由にエンドポイントの構成と新しいアーキテクチャへの移行をサポートすことができます。つまり、分散アーキテクチャは、アーキテクチャを変化させることができる唯一のアーキテクチャであると思います。

江川

Why opensource ? LAMPから次のオープンソースの適用について実践しなければならないときに来たのではないでしょうか？ラインセスの売り上げを生業としているソフトウェアベンダーが、従来の商用製品（ラインセス費用をいただく製品）に加えて、ラインセス費用は発生しないオープンソースの製品を発表しました。昨年からObjectWebでオープンソースによるESBとしてCeltixプロジェクトをリードしてきましたが、オープンソースのメジャーリーグのApache Foundationに移り、性能の高いといわれるSOAP/HTTPのスタックのXfireと統合して、CXFとして再出発するにあたり、SOAインフラの基盤のスィート製品として、Celtix Enterpriseを発表しました。

EclipseのSOA Tool Project（STP）は、まだ、統合されていませんが、このSTPを含めて、JPモーガンなどが提案しているAMQP（Advanced Message Queuing Protocol）を実現するApacheインキュベータのQpidを統合するなど、ユニークな品揃えを計画しています。もちろん、CORBAのスタックについてもApacheインキュベータのYokoを統合する予定でいます。このように、製品の開発と統合、検証といったプロセスもオープンソースのフィールドで効率的に実現できるようになってきており、SCA（Service Component Architecture）の標準化活動のリファレンス・インプリメンテーションが、ApacheインキュベータのTuscanyで実施されているようにオープンソースが、自然とテクノロジーをリードすることになります。

Celtix Enterpriseは、製品だけでなくサービスを含むパッケージ製品となり、SOA導入の敷居を下げることを目的としています。オープンソースではありますが、アイオナの製品としてリリースするものであり、アイオナの15年におよぶインテグレーションのサポートの経験が、オープンソースに付加されることになります。Celtix Enterpriseの発表にあたり同僚のSteve Vinoskiが書いたブログを翻訳して引用しました。ご覧ください。

Stefan Tilkov氏が、Celtix Enterpriseの発表について好感度な記事を書いています。Celtix Enterpriseの発表への反応は、この24時間に数100のダウンロードのリクエストがあるなど、今のところ非常に好調です。

ほんの少しですが、私（Steve Vinoski）の貢献としては、CXFのダイナミック・プログラミング言語のサポートにあります。もともとは、オープンソース・プロジェクトのCeltixために設計したのですが、今回はCXF に移行し、AMQP を実装するApacheのインキュベータのQpid へも移植します。

とりあえずは“ESB”という呼び方に、嫌気がさすようなことはないようにお願いします。多くの人が、ESBという言葉を嫌っているのはわかります。ほとんどのベンダーのESBは、いずれも、JMSの実装を推し進めるか、あるいは、巨大で、脆く、中央集中型なコストのかかるEAIのような怪物ですから仕方がないかもしれません。Celtix Enterpriseの場合は、適用性が高く、真に分散化されたSOAのソリューションを作り、それを、分散コンピューティングの環境へ適用していく拡張性を重んじるアイオナの血統のようなものを発揮しました。理論的には、すべてのSOA環境は、分散化されたものであるにも関わらず、実際には、多くのESBソリューションは、何も考えずに中央集中型のハブを利用することを強いています。特定のあるサイズのソリューションが、すべてのエンタープライズのソリューションには生り得ないことは、明らかであり、Celtix Enterpriseでは、Qpidによる集中型のメッセージング・ブローカーから、たとえば、CXFによるマルチプロトコルかつマルチフォーマットの快適なSOAエンドポイントまでのすべてのレンジを網羅したオプションを提供しています。

私自身としては、ESBとは、アイオナのArtixやCeltix Enterpriseであると定義してはほしくないのですが、お分かりのように私はマーケティング担当ではないので、この先、どうなるかはわかりません。しかし、われわれが提供している特徴や機能を考えると、良くも悪くも、マーケットのカテゴリの分類からESBがもっとも近いです。ただし、そのようにカテゴリに分類したしても、Celtix Enterpriseは、皆さんが手に入れることのできる通常の商用の形態のソリューションとは異なるものとなります。でも、私の言葉をそのまま利用しないでください。どうか、ご自分で確かめてください。

アイオナにとって、今は、とても“cool”な時ということだけ言っておきます。あと3週間ほどで、私は、アイオナで10年を越えることになりますが、このCeltix Enterpriseのリリースは、これまで経験した中でも、本当に、もっとも、興奮する出来事です。このことは、お客様にとっても、われわれにとっても、技術的にも、ビジネス的にも、新しい道を示していることを意味します。けれども、実際は、単に冷静に前進し続けることこそが必要になるのです。

江川

2006年6月にAMQP（Advanced Message Queuing Protocol）の標準化のグループの発表がありました。その際に内容を発表していますが、AMQPのサイトに概要の説明がありましたので、翻訳をしました。もちろん、正式な翻訳ではありません。内容については原文を確認してください。AMQPは非常にユニークなアプローチだと思います。また、アイオナでは、AMQPを実装したオプションをCeltix Advanced Messagingとして発表しています。

AMQPとは？

AMQPはメッセージング・ミドルウェアのオーブンな標準です。
ミドルウェアとは、他のソフトウェアに接続するためのソフトウェアです。また、企業内と企業の外部のシステムの両方に対して、システム化された孤島同士を連携するものです。
AMQPの標準に従えば、異なるプラットフォームの異なる言語で書かれたミドルウェア製品は、その他のミドルウェア製品との間でメッセージを送ることができなければなりません。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つの主要なコンポーネントのタイプがあります。これらのコンポーネントは必要な機能を提供するプロセスの連鎖に組み込まれます。

このモデルでは、ストアード／フォワード・キューやトピック購読の従来のミドルウェアの概念をエミュレートします。また、コンテンツ・ベース・ルーティング、メッセージ・キューの生成、随時利用のメッセージ・キューなどのちょっとした概念についても指定します。

大雑把な言い方をするとAMQPサーバはメイルサーバに類似しています。つまり、exchangeはメッセージ転送エイジェント（MTA）に、メッセージ・キューはメイルボックスということになります。bingingは転送エイジェントの中にルーティング・テーブルを定義します。パブリッシャは、それぞれの転送エイジェントにメッセージを転送し、メッセージはメイルボックスへルーティングされます。利用者はメッセージをメイルボックスから取り出します。これによって、強力で柔軟なモデルをシンプルに定義できます。

AMQPワイヤー・フォーマット

AMQPのワイヤー・フォーマットは、最新の特徴を備えたバイナリによるフレームです。これは、マルチ・チャネル対応可能、すでに協議済み、非同期対応、セキュリティ対応、移植可能、中立であり、効率的であるなどの特徴を備えています。

AMQPワイヤー・フォーマットは二つのレイヤに分かれます。機能レイヤとトランスポート・レイヤです。機能レイヤは、アプリケーションに代わって、その役目を果たすコマンド（各機能を論理的なクラスにグループ化したもの）の組み合わせとして定義されます。トランスポート・レイヤは、このようなメソッドをアプリケーションからサーバへ双方向で転送し、多重なチャネルの制御、フレームの構成、内容のエンコード、ハートビート、データ表示やエラーハンドリングなど行います。トランスポート・レイヤと機能レイヤの両方とも、プラグイン構成でプラグインによるカスタマイズが可能です。これによってプロトコルの刷新や新たなテクノロジーの適応に対応できます。

AMQP仕様のダウンロード

仕様はAMQPユーザのページからダウンロードできます。

AMQP製品の検索

AMQP製品のページをご参照ください。

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はサポートしますか？

ストアード/フォワード・トランザクションのメッセージングと高性能なパブリッシュ/サブスクライブによるイベント通知、バッチによるファイル転送型のメッセージングの基本的な機能と利用方法を統合しました。

標準的なユースケースは次のとおりです。

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:仕様（あるいは、メイリングリストのアーカイブ）はどこにありますか？

開発のためのアーカイブや開発者のメイリングリストへのリンクは、まもなく公開されます。

Javaテクノロジーに関する話題として、IDGのITアーキテクトサミット 2007 Summerのセッションの中で出してしまったのですが、ArtixはVersion5をリリースして、Javaインタフェースの作り方が大幅に変わりました。

Artixは、C++をベースに製造されており、JavaのAPIからC++で作られたコアの機能を利用することになります。以前であればJava自体が重くて遅いので、このJavaとC++の間のオーバヘッドも気にならなかったのですが、Javaのコンパイラの技術やCPU自体が向上することでJavaの性能が上がってきて、オーバヘッドが目立つようになってきました。

以下の図にあるようにArtix5_jaxwsは、Artix5であらたにCXFをベースにして、JAX_WS（JSR224)でのアノテーションを利用したAPIに替わったのですが、その変化のひとつの要因が性能です。下図のArix5_JNIは従来のJava APIであるJAX_RPC（JSR101）をサポートし、HTTPやSOAPなどのエンジンはC++側の機能を呼び出すためにJNI（Java Native Interface）を経由して実現しているものです。

ご覧のように性能上の違いは明らかであり、PureなJavaで実現するようにJAX_WSへ移行したものです。もちろん、従来のJAX_RPCのAPIも互換性を提供するために残りますが、コアの製造が、JavaとC++に分かれていくことは明らかになったことになります。

これは”テクノロジーの格差”を意味しています。以前のエントリにあるようにJavaのテクノロジーは決してSOAインフラを構築するにも適した技術ではないにも関わらずアプリケーション開発のプラットフォームとして広まってきたというだけでマジョリティとなり、そこにメガベンダーの思惑が重なってJava技術へ偏重していると思います。

JVMの上と外とでは世界がまったく異なってしまいます。JVMの上ではネイティブなC++のWebサービスさえも提供できないのです。このテクノロジーの格差をなんとか平準化する必要があります。Artix5は従来のC++で構築したアーキテクチャを踏襲してJavaによるコンテナを同時に実現することで利用者に対しては正しいインフラの姿を提供することができる製品です。

TMFのTokyo Symposium 2007が東大の工学部の講義室で行われたので資料としてのカタログ詰めとともに参加してきました。

学部の講堂としては立派なものですが、資料を袋に詰めるのは人海戦術で各社のカタログを一枚ずつ束ねていく作業をやっていました。200名弱くらいは参加されたのでしょうか。TMFというテレコムのOSS開発に特化した内容ですので中身は濃いものとなります。展示も数社あったのですが、狭いところ活発なコミュニケーションができていたようです。

その中で、ソフトバンクテレコム株式会社の研究所の米田　進様の講演でオーバーレイ・ネットワークという話題がありました。Web2.0の発想を元にして、XMLのメッセージのネットワークのプラットフォームを構築しようというもので、実験を行っておられるようです。インターネット上を検索してみると、NGN+S 2007での講演やソフトバンクテレコムの広報サイトでも同様のお話しをされています。

アプローチの仕方が違うので、同じものであるとは言えないのですが、以前のエントリのインターネット上のESBの考え方と位置は同じです。

米田様はRFIDに代表されるようなID管理をこのプラットフォーム上で実現することを想定されていますが、同様にこのプラットフォームを利用して実現するアプリケーションを考えていくことはなかなかおもしろうそうではないでしょうか。そこにはアーキテクチャの重要性が含まれていると思います。

2007年9月25日付けでアイオナのオープンソースSOAスイートのFUSEの新しいリリースが発表されました。FUSEの元になっているApache Software FoundationのServiceMixプロジェクトがインキュベータから30余りのトッププロジェクトのひとつに昇格したことをお知らせしました。その中でご説明したようにアイオナはLogicBlazeを買収して、アイオナのオープンソースESBのCeltixが、LogicBlazeのFUSE製品群と統合されました。

今回のリリースの目的は、このCeltix系のESBとFUSEのスウイートをより強固に統合することです。