目次


Javaの理論と実践

次期エンタープライズ・アプリケーションにJMSの採用を

メッセージ・キューイングによって、エンタープライズ・アプリケーションの柔軟性とスケーラビリティ-が向上します

Comments

コンテンツシリーズ

このコンテンツは全#シリーズのパート#です: Javaの理論と実践

このシリーズの続きに乞うご期待。

このコンテンツはシリーズの一部分です:Javaの理論と実践

このシリーズの続きに乞うご期待。

メッセージ・キューイング (MQ) ツールは、リレーショナル (SQL) データベースなどのようなデータベース・ツールほどはよく知られてはいませんし、理解もされていません。データベース・ツールは、ほとんどすべてのエンタープライズ・アプリケーションで、また数多くのシンプルなアプリケーションで、主要なコンポーネントとなっています。簡単なデスクトップ専用データベース (dBaseやMicrosoft Accessなど)からワークグループ・データベース・サーバー (Sybase SQL/Anywhereなど)、またさらにエンタープライズ・データベース・サーバー (DB2やOracleなど) に至るまで、開発者は常に広範なデータベース製品を使うことができます。あらゆるプロジェクトにおいて、必要に応じてさまざまな価格、パフォーマンス、機能を持つデータベース製品が利用されています。

データベースと同様、MQ製品も、時としてメッセージ指向型ミドルウェア (MOM) と呼ばれ、長い間使用されてきました。しかしごく最近まで、高価なハイエンド製品であるMQサーバーを利用できるのは、資金が豊富な企業開発者に限られていたため、メッセージングをアプリケーションに利用できる開発者の数はきわめて限られたものとなっていました。

一般向けのメッセージ・キューイング

幸いなことに、この状況は変わりつつあり、現在、低コストのMQサーバーがいくつか市場に登場しています。1997年にMicrosoftは、トランザクション・メッセージ・キューイング製品であるMSMQを、Windows NT Serverのコンポーネントとして、追加ライセンス料金なしで提供しました。Sunは、初期のJ2EE仕様にJMS APIを盛り込むことによってメッセージングの強化を行い、J2EEバージョン1.3からはさらに、すべてのJ2EEコンテナーにJMSプロバイダーが組み込まれるように要請されています。

JDBCが共通インターフェースによって、プログラムによるさまざまなデータベース・サーバーへのアクセスを可能とするように、JMS - Java Message Serviceは、標準インターフェースによって、幅広いMQサーバー (JMSの用語ではプロバイダーと呼ぶ)に対するJavaアプリケーションのアクセスを可能とするAPIです。現在、ほとんどのJ2EEコンテナーにJMSプロバイダーが組み込まれており、また今後は、すべてのJ2EEコンテナーにJMSプロバイダーが組み込まれるでしょう。JMSはまた、J2EEコンテナーなしでも使用することができ、スタンドアロン型JMSプロバイダーの利用もいくつか見られるようになっています。さらに、EJB 2.0仕様では、新しいタイプのEJB (メッセージ指向型ビーン) が導入され、エンティティーおよびセッション・ビーンを利用するメッセージ指向型コンポーネントの作成をきわめて簡単に行うことができます。

このように、JMSサービスを誰でも利用することができるようになってきました。そこで、いかにしてアプリケーションにおいてメッセージングの機能を生かすかという点について見てみることにしましょう。IBMのe-businessアーキテクトであるWilly Farrell氏は、JMSの利用に関する優れた入門書を著しました(参考文献を参照)。この解説書において彼は、メッセージおよびキューの作成に関する基礎、また、メッセージの優先順位付け、検索、エンコードに関するあらゆる方法について解説しています。

メッセージングおよびデータベースは互い補足する機能を備えているため、多くの場合、メッセージングとリレーショナル・データベースを併用することによって、どちらかを単独で使用する場合よりもはるかに優れたソリューションを得ることができます。

従来、MQサーバーは、金融サービス・アプリケーションなどのイベント指向型アプリケーションにおいて、あるいは異種システム間のインターフェース(異種データベース・アプリケーション間の接続、サプライ・チェーン・ネットワークにおける企業間接続など)において用いられてきました。また、「メッセージ指向型ミドルウェア」という言葉もしばしば用いられて、MQテクノロジーの主な用途は、異種システム間の接続であるという認識がされてきました。しかし現在、MQ製品のコスト低下に伴い、他の多くのアプリケーションでもメッセージ・キューイングの利用が可能となってきています。

MQサーバーの機能

MQにおいて、メッセージとは、単なるバイトのストリーム(XMLドキュメント、直列化されたJavaオブジェクト、テキスト・ストリング、あるいは空メッセージでさえも)を指します。メッセージの解釈は、アプリケーションにおいて行われ、MQインフラストラクチャーは、メッセージの意味や構造に関与しません。メッセージはキューに格納され、メッセージのキューへの積み上げ、またキューからのメッセージの取り出しをMQサーバーを使って行います。

ここまでのところでは、メッセージ・キューはシンプルなリンク・リストのように聞こえるでしょう。実際に、その最もシンプルな形では、まさにリンク・リストそのものです。しかし、エンタープライズMQサーバーは、このリンク・リスト管理に次のような機能を加えることによって、より高い機能性を提供することができます。

  • キューの書き込み/読み取り権限を管理するセキュリティー機能
  • ネットワーク・インターフェース - メッセージの作成者と利用者が別の場所にいることができる
  • トランザクション・サポート - エンキュー/デキュー・オペレーションにおける「原子性」「一貫性」「独立性」「耐久性」の提供
  • 分散トランザクション・サポート - SQLデータベースなど他のリソース・マネージャーと結合された分散トランザクションにおけるキュー・オペレーション
  • 永続性
  • 負荷分散
  • フェイルオーバー
  • 管理

MQの特長

MQの特長は、メッセージ処理の非同期特性がもたらす独自の疎結合によるものです。あるエンティティーがキューにメッセージをポスティングするプロセスと、別のエンティティーがメッセージを分離してそれを処理するプロセスは、完全に独立しています。この2つのエンティティーは、同時に実行する必要も、同じシステム上に存在する必要もなく、また、相互のIDを認識する必要もありません。独自のスケジュールによるキューとのインタラクションのみでよいのです。相互に受け入れることのできるメッセージ形式のみ認識していれば、他に相互間で認識が必要とされることはありません。

このような疎結合には、多くのメリットがあります。作業単位をより細かい独立したコンポーネントに分割することができます。これによって、要求処理における各段階の間に抽象が暗黙的に作成されます。この細分割によって、コンポーネントの互いの実装を容易に抽象化でき、各コンポーネントのリソース使用状況に対するより効果的な測定/管理が可能となり、また、同等の機能を持つコンポーネント同士の交換を他のコンポーネントに影響を与えずに行うことができるようになります。

JMS仕様では、JMSプロバイダーによるパブリッシュおよびサブスクライブ機能の提供も定められています。これにより、明確なアプリケーション定義のチャネル -トピックの作成や、個々のエンティティーによるトピックへのサブスクライブ(通知を受けるための登録)が可能となります。トピックのキューに入れられたメッセージは、そのトピックにサブスクライブしているエンティティーの専用キューに自動的に置かれます。このトピックを用いることにより、金融サービスやニュース配信アプリケーションにおいて重要とされる仕分け機能が可能となります。たとえば、米国証券取引所において取引される5000を超える株式のうち、個々の投資家が関心を持つ株式はわずか30銘柄である、といった場合があります。そのような場合、ティッカー記号(証券コード)ごとにトピックを作成し、関心のある記号のみを利用者がサブスクライブできるようにすることによって、各投資家の望む相場だけがMQエンジンによって表示され、必要のない相場を繰り返して表示しないようにできます。このようなプロセスをSQLデータベースで行おうとすれば、それははるかに手間のかかるものとなるでしょう。

従来のMQの使用パターン

メッセージ・キューイングの利用にはそれに適した数々の共通する使用パターンがあります。皆さんのアプリケーションの中に以下のようなものがあるなら、おそらく、メッセージングの利用を検討すべきでしょう。

イベント指向型アプリケーション

イベント指向型アプリケーションには、MQテクノロジーが非常に適しています。これには、金融サービス・アプリケーション (株価情報の表示、価格変動や他の注文状況に基づく取引の開始、注文状況の伝達等を行うトレーディング・ステーションを考えてみてください)、ニュース配信アプリケーション、サプライ・チェーン・アプリケーションなどが含まれます。金融市場では、迅速な対応が常に求められます。重要なイベントの発生に伴う迅速な情報伝達が不可欠です。

データベースのポーリング

データベースは、データの恒久的保管という点では優れていますが、一時的なデータを保管し、データへの変更があった場合にはそれを通知するという点では、十分な機能を備えていません。

そのようなニーズに対して、効率の点で問題があるとはいえ、データベースのポーリングという方法が一般にきわめて普通に使用されています。空港の表示モニターなどは、データベースに対するポーリングを絶えず行うことによって表示情報の更新を行っています。また、たくさんの窓口を持つ銀行では、電子表示によって空いている窓口を知らせるシステムを持つところも多くあります。e-commerceのオーダー処理システムは、データベースのポーリングによって、処理すべき新規オーダーの有無を確認しています。また、保険請求業務システムでは、精算人に割り当てるべき新規請求の有無をポーリングによって確認することもできるでしょう。

これらのポーリングにはすべて、たくさんの追加作業が必要となります。頻繁にポーリングを行う (データの迅速な更新が必要な場合にはそれが必要) エンティティーが多ければ、データベース・サーバーとネットワークに相当な負荷がかかるでしょう。そしてほとんどの場合、ポーリングによってまったくデータが返されないか、または、(さらに悪いのは) すでに得られているデータを再度返すことによってそのデータの再処理が必要となるかまたはそのデータが処理済みであるということの識別が必要となります。

データベースは、ポーリングやイベント向けには設計されていません。イベント発生やデータ変更の際に迅速な対応が要求される場合、非同期メッセージングの方がはるかに簡単で効率的な方法です。データベースのポーリングによるデータ更新が必要な場合は、常に、JMSの使用を検討してみてください。

ワークフロー

ワークフロー・ポータル (Workflow Management CoalitionおよびWorkflow And Reengineering International Associationの共同作業による)によれば、「ワークフロー」とは、「全体的または部分的なビジネス・プロセスの自動化を指し、そこにおいては、業務上のドキュメント、情報、またはタスクが、ある参加者からそれを処理すべき参加者に、手続き規則の集合体に従って伝達されるもの」を指します。ワークフロー・アプリケーション (文書のルート設定/承認、保険金請求処理など) は、MQソリューションが特に適しています。というのは、MQテクノロジーというものが、各自が「入」のトレイと「出」のトレイを一つずつ持つ書類中心のオフィスにおいて、ワークフローの問題にどのように対応すべきかを、綿密にモデル化したものだからです。

ワークフロー・アプリケーションの特徴は、タスクの一部を実行し、ビジネス・ルールに従ってそれを次のエージェントに渡す多くのエージェント (人間、自動処理ステップ、マシンやプリンターのような物理装置もエージェント) を持つことです。たとえば、電子経費報告書を承認して支払いを行うプロセスについて考えてみましょう。ある従業員が報告書を作成して提出すると、その報告書にはその従業員のマネージャーの承認 (さらに、金額が一定額を超えるとさらに上の管理レベルの承認) が必要となります。次にその報告書はHRに送られ、そこで間違いがないかどうか、経費が有効な営業費であり会社の方針に沿ったものであるかどうかが調べられます。承認されると、支払請求が作成され、小切手の発行がスケジュールに組み込まれます。その後、経理に送られ、そこで個々の請求金額が適切な会計/コスト・センターに伝えられます。これらの各段階において、この報告書が従業員あるいは従業員のマネージャーに戻される場合もあります。

ワークフロー・アプリケーションの構築に際して重要なことは、エージェント間におけるタスクの迅速かつ確実な伝達、タスクの抜けの回避です。MQサーバーとデータベースを連携させることによって、柔軟で、スケーラブルで、拡張可能なワークフロー処理をアプリケーションに容易に組み込むことができます。

MQによって、リスクの大きいオペレーションをクリティカル・パスから排除

e-commerceやサプライ・チェーン・アプリケーションにおける、受注、注文の承認、履行のプロセスは、そのステップのほとんどが人というよりは電子的なものにより処理されるという違いはあるものの、ワークフロー・アプリケーションと多くの点で共通しています。受注および受注後の業務には、以下のステップの一部あるいはすべてが含まれます。

  • データベースへの受注の格納
  • 個人顧客の場合、クレジット・カードの確認
  • 事業法人顧客の場合、信用情報センターや社内の審査部による顧客の信用調査
  • 不正検査分析
  • 在庫確認
  • 複数の業務センターがある場合には、その受注に対応するセンターの決定
  • 顧客に対する確認メールの送信
  • 営業担当者への通知の送付
  • ピッキング・リストの作成および物流センターへの転送
  • 品物の発送
  • 顧客への請求書送付

注文を出してから予約番号と受取りが届くまでに、顧客を長々と待たせることは避けるべきです。そのため、注文を受けてから実行されるコード・パスはできるだけ短く、予測可能な実行時間にするべきでしょう。こうしたステップの多くはリソースへのアクセスを伴いますが、そのようなリソースは、顧客が注文を出す時点で利用できる場合とできない場合の両方が考えられ、また応答時間が予測できない場合もあります。こうした場合、このようなプロセスをクリティカル・パスから分離することが必要です。注文を受けることによってイベントのチェーンがスタートしますが、受注処理を開始するステップを最小限にすることで、できる限り速くユーザーをループの外に出します。オーダー処理を短い複数のステップに分割することによって、顧客に良い印象を与えることに加え、リソースの使用効率を高め、処理の競合を軽減することができます。つまり、より短いトランザクションによって (ロックがより早く解放され)、1つのステップで使用されるリソース (ネットワークやデータベース接続など) がより早く解放されることになります。

注文処理において最も予測が難しいステップの1つは、確認電子メールの送信です。メール・サーバーが混雑していることも多く、またメッセージの受理に時間がかかったり、接続が完全に拒否される場合もあります。確認メールが顧客のメール・サーバーによって拒否された場合、後で送信を再試行することが望ましいでしょう。このように、確認メールは「リスクを伴い」ます。1回の送信でうまくいかないことも、処理に時間がかかることもありますが、確認メールの送信で顧客 (またその他何でも) を待たせることはぜひとも避けたいことです。また、在庫リストが注文処理とは違うデータベース (注文処理業務を委託した先など) にあり、注文を受けた時点で在庫リストを利用できない場合もあります。あるいは、審査部が金曜日に休みという場合も考えられます。

メッセージ・キューを利用して、確認メール、在庫確認リスト、信用調査リストを保管することによって、「リスクの大きい」オペレーションを他のプロセスから切り離し、オペレーションの失敗や遅延から保護することができます。またこれにより、1つの処理ステップには1つの簡単なタスクのみが割り当てられるため、各タスクのエラー処理がきわめて容易になります。

結論

メッセージ・キューイング (MQ) テクノロジーを適切に用いることによって、タスクをシンプルなサブタスクに分割し、複雑なタスクの処理を大幅に簡略化することができます。そして、アプリケーションの柔軟性とスケーラビリティを向上することができます。J2EEバージョン1.3からは、JMSプロバイダーがすべてのJ2EEコンテナーに組み込まれるようになりますが、これはすなわち、非同期メッセージ・キューイングの機能をすべての人がアプリケーションで利用できるようになるということを意味します。

次回は、Java Transaction Service (JTS) について見てみることにしましょう。JTSは、注目度においてはEJBその他に比べてはるかに低いようですが、信頼性の高い分散アプリケーションを可能にするのはトランザクションであるという点からいえば、JTSこそがJ2EEのおそらく最も重要な部分といえるでしょう。また、その先のコラムで再びMQについて取り上げ、メッセージ・キューイングとリレーショナル・データベースのインタラクションによる効果を実証するための、ワークフロー・アプリケーションの構築を行います。


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


関連トピック

  • JMSに関する仕様、参考資料、事例はSunから入手することができます。
  • Richard Monson-Haefel氏およびDavid Chappell氏共著の「Java Message Service」(O'Reilly and Associates、2000年)は、JMS APIについて詳細に示し、その導入における実践的事例を紹介しています。
  • Richard Monson-Haefel氏の「Enterprise JavaBeans」(O'Reilly and Associates、2000年) は完全アップデート版です。EJB 2.0仕様における変更点を徹底的に検討しています。
  • Workflow Management CoalitionおよびThe Workflow And Reengineering International Associationによる共同ポータル、e-workflowWorkflow Portalは、ワークフロー・アプリケーション開発者のための範広いリソースを提供します。
  • この記事のMQSeries with JSP technologyの使用方法はWebSphere日本語サイト)で参照できます。
  • developerWorksJavaテクノロジー・ゾーンで他のJava参考文献をご覧ください。

コメント

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Java technology
ArticleID=218533
ArticleTitle=Javaの理論と実践: 次期エンタープライズ・アプリケーションにJMSの採用を
publish-date=02012002