目次


Geronimoへの転向: Apache GeronimoのJMS実装: ActiveMQ

James Strachanとのインタビュー

Comments

メッセージを入手する

J2EE (Java™ 2 Platform, Enterprise Edition)アプリケーション・サーバーは単純なソフトウェアではなく、相互の通信が必要な多数のコンポーネントから構成されます。また、EJB (Enterprise JavaBeans)が相互通信するアプリケーションもサポートする必要があります。しかも、クラスタリング・ソリューションの作成時には、複数の場所に配置された複数のマシンにある複数のインスタンスを考慮に入れる必要があります。Geronimoへの転向コラムでは、これまでにクラスタリングについてさまざまな解説を行いましたが、その際、頻繁に登場したトピックの1つがシステム内で行われるメッセージングです。

アプリケーション・サーバーに何らかのメッセージング・ソリューションが必要なことは明らかです。実際、メッセージング・ソリューションのないJ2EEアプリケーション・サーバーはありません。JMS標準の実装はJ2EE仕様の要件になっています。Apache Geronimo技術では、ActiveMQプロジェクトのソフトウェアを統合することで行われています。

IRC (Internet Relay Chat)クライアントの失敗など、いくつかの失敗の後、ようやくApache GeronimoとActiveMQの共同創設者であるJames Strachanにお会いし、ActiveMQソフトウェアについて話を伺うことができました。ActiveMQとは何であり、何を行うのか、またGeronimoプロジェクトに対してどのような意味を持つのかお訊きしました。その結果、MOM (Message-Oriented Middleware)について学び、SOA (Service-Oriented Architecture)の未来をかいま見ることができました。

ActiveMQの概要

筆者がActiveMQはApache Geronimoプロジェクトから生まれたのではないかと示唆したところ、「ActiveMQはApache Geronimoプロジェクトから生まれたわけではありません」と、Jamesは答えました。「むしろ、Geronimoプロジェクトの開始がきっかけとなってActiveMQプロジェクトが創設されました」。J2EE仕様ではJMS 1.1対応のメッセージング・プロバイダーが必要とされていました。「そこで、ActiveMQプロジェクトの創設を手助けしました」。

JMS 1.1はSun Microsystemsのサイトからダウンロードできますが、これは参照用実装にすぎないことに気付いている方は多くありません。独自のプロジェクト(特にオープン・ソース・プロジェクト)でこのメッセージング・フレームワークの仕様をサポートする場合、通常はJMS 1.1仕様の独自の実装を作成する必要があります。

それこそチームが行ったことです。実際、ActiveMQは、Geronimoとは異なるプロジェクトですが、James、Dain Sundstrom、Geir Magnusson、Hiram R. Chirino、Greg Wilkins、David Jencks、Alan Cabrera、Aaron Mulderなど、多くの人が両方に関わっています。ActiveMQは他のアプリケーション・サーバーと共に使用できるだけでなく、アプリケーション・サーバーなしで使用することもできます。例えば、メッセージのやり取りが必要なアプリケーションを作成する場合、JMSの参照用実装ではなくActiveMQを使用することができます。「たくさんの方がSpringとTomcatと共にActiveMQを使っています」と、Jamesは指摘しました。

今のところ、ActiveMQはApache Incubatorにあります。つまり、Apache Software Foundationに公式には承認されておらず、その途中にあります。「これはApacheへ入る準備段階です」と、Jamesは説明します。「この段階でプロジェクトをApacheインフラストラクチャーに参加、移行させ、Apacheの一部にする方法を学習したりできます」。この段階での作業には、返信プロセスの理解、プロジェクト管理委員会の設立などの活動が含まれます。

Incubatorではプロジェクトの現実的なコミュニティー設立にも関わるため、チームは多様であることが重要です。「Apacheをベンダーのごみ捨て場にはしたくありません」と、Jamesは言います。「活気にあふれ、多様性に満ちたコミュニティーになることを望んでいます」。

コミュニティーも、ActiveMQが実際にはGeronimoプロジェクトの一部であるにも関わらず、Apache Incubatorの一部であることを選んでいる理由です。「それに」と、Jamesは付け加えます。「企業は、明確なソフトウェア許可、寄付者ライセンス契約、およびIPポリシーを持つApacheに寄付した方が多少気楽だろうと思います」。

しかし、ActiveMQの実際の用途は何でしょうか。それまでにJamesへのインタビューはしばらく続きましたが、驚いたことにクラスタリングの話題すら出ませんでした。ですから、この時点で、もう少し何かがあると思うようになりました。実際のところ、ActiveMQはGeronimoのMOMの中心に位置しています。

MOMとは

MOM (Message Oriented Middleware)は、その名前が示すように、直接コマンドを使うのではなく、メッセージを使ってエンタープライズ内のコンポーネントを接続するシステムです。「MOMは元のSOAの1つです」と、Jamesは指摘します。「MOMは、高性能の非同期メッセージ交換を使ってシステムを疎結合する方法としてかなり前に普及しました。例えば、在庫システムは給与計算システムや会計システムとメッセージを交換することがあります。これらのシステムの接続にMOMが使われている場合、ある時点でシステムを停止すると、メッセージはそのシステムを避けて流れますが、システムが作動するまでキューに保持されます。したがって、プラットフォーム、言語、API、そして最も重要な時間に関してシステムを疎結合できます」。

筆者はJamesに、MOMにはメッセージの送受信以外にどのような用途があるか尋ねました。Jamesによれば、MOMはパブリッシュ/サブスクライブ、およびキュー機能の2つの基本サービスを提供します。

パブリッシュ/サブスクライブ・システムで、コンシューマーは特定のトピックに関する情報を調べていることをシステムに知らせます。このトピックは特定の在庫品の価格更新など現実的な場合もあれば、データベースのイベントなど比喩的な場合もあります。そのようなメッセージがプロデューサーによって生成されると、クライアントはメッセージを受け取ります。通常、メッセージはプロデューサーからコンシューマーに直接送信されず、ブローカーが管理して適切にルーティングを行います。

キュー・システムでは、すぐに配信できないメッセージはキューに保存され、適切な時点で配信されます。このようにすると、コンシューマーを利用できない場合でも、メッセージは失われません。「通常、MOMではパーシスタント・メッセージングを使います」と、Jamesは説明します。「一部のメッセージはディスクに書き込まれるため、失われません。例えば、銀行口座fooから$1000を引き出すというメッセージがあるとします。このメッセージを失ったり、誤って2回送信したいとは思わないでしょう」。

この点がMOMの優れたところであり、希望する回数だけ、希望する配信先にメッセージを確実に配信できます。

MOM対Webサービス

これらのシステムは、10年以上にわたり、CORBA (Common Object Request Broker Architecture)、RPC (Remote Procedure Call)、EJBなどの技術を使用して作成されてきました。これらの技術の問題は、単一システムでは非常によく機能するが、通常は同期的であり(つまり、メッセージの送受信中、すべての処理が停止する)、位置に依存するということです。また、通常、システムのコンポーネントは密結合です。

当然ながら、現在では密結合は時代遅れで、SOAがはやっています。SOAはWebサービスと混同されることが多いですが、2つは同義語ではありません。Webサービスは、SOAP (Simple Object Access Protocol)や他のXMLプロトコルに基づいたものなど、組織間の境界を越えるアプリケーションに適しています。「Webサービスはオープン・ワイヤー・プロトコルを目指しています。一方、MOMはワイヤーの各終端を所有しようとしました」と、Jamesは言います。

このオープンネスのため、SOAの使用は拡大しました。MOMは大企業や先進企業でのみ使用される傾向がありましたが、Webサービスは市場を大きく拡大しました。

それに、2つは相互に排他なわけではありません。MOMシステム経由で送信されるSOAP、またはWS-*標準を実装するMOMシステムを見かけることはめずらしくありません。実際、ActiveMQには、パブリッシュ/サブスクライブ・パラダイムのWebサービス版であるWS-Notificationが既に実装されています。

一方、MOMの方が完成度の高い技術であり、信頼性の高いメッセージングなど、他の要件については、Webサービスより優れています。「HTTPには信頼性や正確に1回の配信を保証するセマンティクスがありません」と、Jamesは言います。

JamesはWS-ReliableMessagingとMOMの問題に関するブログを示しました。そこで、Jamesは「JMS/OpenWire/MOMには、各メッセージ交換の正確なQoSを指定する方法があります」と書いています。言い換えれば、保証された配信、重複の除去などに関して、サービス品質(要件)を決定できます。Jamesは続けます。「WS-RMでは、ほとんどの場合、メッセージ肯定応答(および順番、重複が可能かどうか)しか扱いません。ですから、MOM世界で利用可能な他のさまざまなQoSをWS-RMプロバイダーで使うポリシーとして指定できる、ある種のWS-*仕様が必要です」。

また、パフォーマンスの問題もあります。「ワイヤーの両端を制御した場合、通常、JMS/MOM/MSMQ [Microsoft Message Queuing]プロバイダーを使うと、さまざまな理由で常にWS-RMより高速です。例えば、MOMは接続ベースである、不等号括弧解析がない、メッセージングはベンダーが長年にわたり実装しているためによく理解されているなどの理由です。もう1つの利点として、MOMは組織にあるWS以外のレガシー・アプリケーションでも正しく動作します(今日、ほとんどの組織では多数のMOMアプリケーションが実行されています)」と、Jamesは説明します。

「しかし、WS-RMの主な目的は、WCF (Windows Communication Foundation)、その他のJMS/WS/ESB [Enterprise Service Bus]スタックなどのさまざまなメッセージング・システム間を橋渡しできるようにすることです。ですから、必ずしも定評のあるMOMより優れていなくても、役に立ちます。設計目標が違うからです。最高のメッセージング・システムではなく、メッセージング・システム間の相互運用性が問題なのです」。

それでも、ActiveMQはGeronimoでこうした相互運用性の問題を解決する場合に役立ちます。

ActiveMQとGeronimo

ActiveMQはApache Geronimoアプリケーション・サーバーのさまざまな場所で明示的、暗黙的に使用されています。メッセージングとクラスタリングについては既に詳しく説明したので、この点についてこれ以上は論じません。

ActiveMQはJCA (Java Connector Architecture)を使用してGeronimoに統合されています。「JCAはJ2EE用の接続とスレッド・プーリング・アーキテクチャーであり、JMS、JDBC [Java Database Connectivity]などのプロトコルと共に動作します」と、Jamesは説明しました。「また、JCAでは例外処理、トランザクションなども扱います。この方法で、JMSプロバイダーなどはアプリケーション・サーバーと円滑に統合されます」。そのため、ActiveMQはリソース・アダプターに包まれています。このリソース・アダプターによって、すべてのアプリケーション・サーバーはActiveMQとの間で情報を送受信できます。

Geronimoではこの方法でいくつかの目的にActiveMQを使用できます。ActiveMQはクラスタリングのほかに、JMSブローカーとしての役割を果たすこともできます。ブローカーはルーティング、パーシスタンス、リカバリーなどを受け持つJMSソリューションのサーバー側部分です。また、JMSクライアントも含まれています。ユーザーはメッセージ駆動型Bean (MDB)を使用してアプリケーションを作成できます。MDBはこうしたメッセージの処理専用のEJBのタイプです。

「例えば」と、Jamesは続けます。「サイトに登録するHTTP要求を受信します。多くの場合、サーブレットで電子メール・アドレスを検証するのではなく、別サービスのキューにメッセージを送り、登録を行います。同様に、EJBは処理をオフロードし、JMSを使って処理を行う要求を送信することがあります」。

「一般に、JMSの用途は、(1)ロード・バランシング、フェイルオーバー、およびクラスタリングを使った信頼性の高い非同期処理、(2)キャッシング/状態の分散、(3)リアルタイムでの価格変更表示などのリアルタイムGUIです」。

Java技術を使用せずにGeronimoでJMSにアクセスする

言い換えれば、GeronimoのActiveMQ実装を使用すれば、JMSクライアントを使用してアプリケーション・サーバーとやり取りするGUIアプリケーションを作成できるため、Webページは必要ありません。また、ActiveMQではStompプロジェクトもサポートしています。StompプロジェクトはJMSブローカーと対話する、言語に依存しない非常に単純な方法です。telnetなどを使用してソケットを開くだけでよいため、どの言語を使用するクライアントもJMSブローカーとやり取りできます。「会話」はリスト1に示すようになります。

リスト1. JMSブローカーとの「会話」
CONNECT
login: myUsername
passcode: myPassword

^@

CONNECTED
session:<someuniquevalue>

^@

SEND
destination:/queue/thingsIllDoToday

Make sure to receive any changes to the weather in Toledo.
^@

SUBSCRIBE
destination:/topic/weatherChanges

^@

MESSAGE
destination:/topic/weatherChanges
message-id:<someuniqueidentifier>

Temp: 62
^@

MESSAGE
destination:/topic/weatherChanges
message-id:<someuniqueidentifier>

RainChance: 60
^@

MESSAGE
destination:/topic/weatherChanges
message-id:<someuniqueidentifier>

Temp: 60
^@

各メッセージ(フレーム)は、コマンドで始まり、NULL文字を表すASCII記号で終わります。この場合、サーバーからクライアントへのメッセージは区別のためにイタリックで示しています。ここでは、クライアントがシステムに接続し、thingsI'llDoTodayキューにメッセージを送信し、weatherChangesキューにサブスクライブしています。ブローカーはそのキューへのメッセージを受信するごとに、クライアントにメッセージを送信します。

Stompプロジェクトでは、Ruby、Python、Perl、PHP、C、C#、およびJava言語用のクライアントを作成しています。また、バイナリー・ワイヤー形式OpenWireを使用することもできます。これは、実際にはActiveMQのデフォルト・ワイヤー・プロトコルです。OpenWireは高速ですが、実装は難しくなります。

コンシューマー側でのロード・バランシング

Jamesは、ActiveMQで気に入っている機能の1つはコンシューマー側のロード・バランシングに関するものだとも言っています。メッセージ・グループは、JMSであまり知られていないオプション機能です。「Webアプリケーションの目立たないロード・バランシングに似ていますが、メッセージングに適用されます」と、Jamesは言います。例えば、Amazonサイトからの注文をキューに入れますが、この処理をできるだけ高速にしたいとします。JMSプロバイダーはコンシューマー間の注文をロード・バランシングします。しかし、メッセージを順番に処理したい場合、問題が生じます。順序を保つには、メッセージの処理に1つのコンシューマーしか使用できませんが、スレッドが完了すると、順番は変わってしまいます。

「1,000個のコンシューマーの集合がある場合でも、各メッセージにJMSXGroupID文字列を追加し、所属するグループを示すことで、メッセージの順番を保つことができます。例えば、IDとしてBooksを使うことができます。そうすれば、エレクトロニクスなどの他のカテゴリーはロード・バランシングしながら、すべての本は1つのコンシューマーにより順番に処理されます。あるいは、個々の本のISBNを使うこともできます。例えば、『Getting Things Done』は1つのコンシューマーが処理し、『JMS Essentials』は別のコンシューマーが処理します。これは、フェイルオーバーのあるカスタム・スティッキー・ロード・バランシングのようなものです。1つのコンシューマーが停止すると、別のコンシューマーが引き継ぎます。現在コンシューマーにある本の数をキャッシュすることもできます。クラスタ全体でその本の注文を見ているのはあなたのスレッドだけであるため、誰もデータベースを変更しません。ですから、とても効率的にキャッシングを行い、ロックと競合の問題を避けることができます。これは、アプリケーションを分割してスループットを最大化する優れた方法です」。

Geronimoとメッセージングの未来

現在、メッセージングの共通基盤を見つけるのは簡単なように思えますが、それは正しいとも正しくないともいえます。Webサービスの世界でも、メッセージングを行う方法の数は毎月増え続けているようです。JMS、CORBA、SOAP、RMI (Remote Method Invocation)、EJBなど、いくらでも挙げることができます。開発者として、このような複雑さには不安を感じますが、Jamesによれば、あまり心配する必要はないようです。

「重要な点は、JMS、EJBなどは少し複雑であると思われることが多いことです」と、Jamesは言います。「現在実際に起こっているのは、ミドルウェアがすべてPOJO (Plain Old Java Object)の背後に隠れているということです。これについては、Apache Tuscanyで見ることができるEJB 3、Spring Remoting、Service Component Architectureなど、さまざまな試みが行われています。ですから、次第にJMS API、EJB API、RMI、CORBA、SOAPのどれを使うか選ぶ必要はなくなり、POJOをデプロイし、コンテナーでミドルウェアを有効にすればよくなります」。

「言い換えれば、ミドルウェアは表から見えないようになり、アプリケーション開発者はビジネス・ロジックを書くだけで、ミドルウェアの細かいところはコンテナーに任せることができるようになります」。

Apache Geronimoには、ServiceMixというActiveMQに関するもう1つの便利な機能があります。ServiceMixはActiveMQに大きく依存するESBですが、あらゆる種類の環境からのメッセージを統合できます。考え方としては、ServiceMix内のJBI (Java Business Integration)を有効にし、システムがフラット・ファイル、電子メール、Jabber、SOAP、他のJCA対応コンポーネントのメッセージなどを受け付け、すべて一緒に動作できるようにします。ServiceMixはGeronimo 1.2リリースに含まれます。

まとめ

われわれはサービス指向の世界に生きています。この世界では、メッセージングは単なる贅沢品ではなく、必需品となっています。Geronimoでメッセージング・サービスに使用されるActiveMQ実装は、Geronimo内およびその外側で、それ自体便利なプロジェクトです。最後に、インタビューのため時間を取っていただいたJames Strachanに感謝したいと思います。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Open source, Java technology, SOA and web services, WebSphere
ArticleID=236420
ArticleTitle=Geronimoへの転向: Apache GeronimoのJMS実装: ActiveMQ
publish-date=04252006