WAS虎の巻: 第4回「JMSとメッセージング・サービス接続」

前回はWebSphere Application Server(WAS)のデータベースアクセスについて紹介しました。今回はWASを経由してメッセージング・サービスへアクセスする際の手法についてご紹介します。Webシステムにおいてメッセージング・サービスと連携することで、Webアプリケーションの処理の一部を非同期に実行することが可能となります。

山地 幸子, , 日本アイ・ビー・エム システムズ・エンジニアリング(株)

山地 幸子の肖像IBM Tivoli Security製品の技術サポートを経て、EAを活用したSOAベースのインフラストラクチャー・アーキテクチャー策定するプロジェクトに参画。現在はWebSphereの技術サポートを担当。



2011年 7月 13日

1. メッセージング・サービス

前回はWebSphere Application Server(WAS)のデータベースアクセスについて紹介しました。今回はWASを経由してメッセージング・サービスへアクセスする際の手法についてご紹介します。
Webシステムにおいてメッセージング・サービスと連携することで、Webアプリケーションの処理の一部を非同期に実行することが可能となります。

図 Webシステムの特徴
図 Webシステムの特徴

そもそもWeb環境において非同期処理を行うことで、どのようなメリットがあるのでしょうか。Webシステムでは、情報の閲覧や参照系のアプリケーションに加えて、データの更新を伴う様々な業務処理が行われています。アクセス集中や重い更新処理などで処理に時間がかかる状態が続くと、ブラウザーがタイムアウトしてしまうようなことも考えられます。クライアントはレスポンスが返ってこないと処理の状況を把握することができません。そこで時間のかかる処理を非同期化することで、クライアントに対する見掛け上のレスポンスタイムや全体のスループットを向上させることができます。例えば、複数の時間がかかるデータベース処理やファイルの転送などを行いたい場合に非同期処理が有効です。

図 Webシステムにおける非同期処理
図 Webシステムにおける非同期処理

処理のイメージとしては、アプリケーションはクライアントからのリクエストを受け付け、処理をメッセージという形式でキュー(メッセージを保持する箱のようなもの)に送信します。そしてクライアントには処理を受け付けたというレスポンスを返します。このように非同期処理によって、クライアント側の待ち時間を短縮することが可能になり、同時に時間のかかる処理は別のサブシステムに任せることができます。
また、一般にメッセージング・サービスは複数のプラットフォームや複数の開発言語に対応しているものが多いため、ホストなどで稼働しているレガシーシステムや非Java環境との通信にメッセージング・サービスが利用されることもあります。
メッセージング・サービスでは、キューを活用することで順次処理が可能になりますし、受信側と送信側で同期をとらずに並行に処理を実行することが可能になります。アプリケーションが非同期に稼働することで、それぞれのシステムが同時に稼働していることが必須ではなり、システム間が疎結合の関係となります。そのため相手やネットワークの状況に左右されません。送信側と受信側のアプリケーションは、お互いを知っている必要がなく、メッセージのフォーマットと宛先さえ知っていればよいということになります。
WASと連携して非同期処理を行うメッセージング・サービスの代表的なものとして、IBM WebSphere MQ(WMQ)やSIBus(Service Integration Bus:サービス統合バス)などがあります。WMQはアプリケーション間通信用のミドルウェアであり、メッセージ・キューイング・モデルを用いた非同期通信によって異機種システム間のメッセージ転送を行います。SIBusはWASが提供するメッセージング・サービスで、アプリケーションはSIBusに対してアクセスします。そしてSIBusの構成要素であるメッセージング・エンジン(ME)がメッセージング機能を提供します。
次章以降ではWAS上で稼働するアプリケーションがメッセージング・サービスにアクセスする場合の接続方法について説明していきます。


2.メッセージング・サービスへのアクセス

WAS上で稼働するWebアプリケーションがメッセージング・サービスとの連携を行うために物理的に必要な要素は以下の通りです。

  • メッセージング・サービスに接続するアプリケーション
  • アプリケーションを動作させるアプリケーション・サーバー
  • メッセージング・サービス

さらにそれらは以下のような要素技術やコンポーネントを使い、アプリケーションからメッセージング・サービスへの接続を行います。

  • アプリケーションを記述するためのJMS仕様、EJB(MDB)仕様
  • JMSプロバイダー
  • JMS接続ファクトリーおよびJMS宛先
  • アプリケーションとJMS接続ファクトリー/JMS宛先を結びつけるJNDI

2.1. JMS

開発者はJMS(Java Messaging Service) APIを用いて、メッセージング・サービスに接続するアプリケーションをコーディングします。JMSはJava EE標準のプログラミング・インターフェースです。第3回で紹介したJDBC APIがデータベースへの接続を行うのに対して、JMS APIはメッセージング・サービスへの接続を行うということになります。標準のインターフェースでコーディングすることにより、メッセージング・サービスに依存しない可搬性の高いアプリケーションを開発できます。JMSはインターフェース定義が中心で、メッセージング・サービスの実装については触れていません。その為、メッセージング・サービスの機能実装は、各ベンダーに任されています。

図 メッセージの送受信
図 メッセージの送受信

JMSにおいては、JMS宛先があり、1つの送信アプリケーションが宛先に対して、メッセージをPUTします。もう一方の受信アプリケーションは、処理可能なタイミング、つまり非同期にそのメッセージを宛先からGETし、処理を実行します。また、送信アプリケーションをメッセージ・プロデューサーと呼び、受信アプリケーションをメッセージ・コンシューマーと呼びます。宛先の実体はメッセージング・サービス上に存在するキューやトピックとなります。キューやトピックはメッセージを保管するために使用されます。
キューとトピックはメッセージング方式によって使い分けられており、PTP(Point To Point)型通信の場合はキューを使用し、Pub/Sub(Publish/Subscribe)型通信の場合はトピックを使用します。PTP型通信は、メールに例えられる1対1の通信形態です。メッセージのやり取りはキューを介して行われます。送信者(Sender)は、キューに対してメッセージを送信します。受信者(Receiver)は、必要なときにキューからメッセージを受け取り、処理を行います。Pub/Sub(Publish and Subscribe)型通信は、メーリング・リストに例えられる1対多の通信形態です。発行者(Publisher)は、トピックに対してメッセージを送信します。全ての購読者(Subscriber)は、前もってトピックに購読依頼を出しておくことで、メッセージを受け取り、処理を行います。

図 2種類のメッセージング方式
図 2種類のメッセージング方式

2.2. JMSプロバイダー

前節ではJMSの仕様のお話をしました。本節以降ではWAS上で必要となるリソース定義の話をしたいと思います。まずはここで一旦JMSアプリケーションの基本構成を確認しましょう。下記の図がJMSの基本構成図となります。

図 JMS基本構成図
図 JMS基本構成図

JMSクライアントとはJMSインターフェースを利用してメッセージング・サービスを利用するアプリケーションのことです。JMSプロバイダーとはJMSのインターフェースを提供するJava EE側のコンポーネントを指していて、アプリケーションがどのメッセージング・サービス上の宛先に対して送受信を行うかという接続機能を提供します。具体的には後述のJMS接続ファクトリーを提供し、JMS宛先に対する接続を作成します。JMSプロバイダーの例としてDefault messaging provider(SIBus用)やWebSphere MQ Messaging Provider(WMQ用)などがあります。データベースアクセスに対応付けて考えると、JMSプロバイダーはJDBCプロバイダーに相当すると言えばイメージが沸きやすいでしょうか。また、WMQやSIBusなどのメッセージング・サービスそのものをJMSプロバイダーと呼ぶ場合もあります。

2.3. JMS接続ファクトリーおよびJMS宛先

JMSクライアントであるWebアプリケーションはWAS上で定義されたJMS接続ファクトリーとJMS宛先を参照してメッセージング・サービスへアクセスすることができます。

図 JMS接続ファクトリーとJMS宛先
図 JMS接続ファクトリーとJMS宛先

JMS接続ファクトリーはJMSプロバイダーの接続を管理しており、接続するメッセージング・サービスのキュー・マネージャー名やホスト名などの接続情報を保持しています。アプリケーションから接続要求がきた場合には、接続情報を元に接続オブジェクトを生成します。JMS接続ファクトリーを定義する場合は、アクセスするメッセージング・サービスに対応したJMSプロバイダーに対して定義を行います。仮に接続先のメッセージング・サービスの情報(ホスト名等)が変更になった場合には、接続ファクトリーを変更することで対応できます。アプリケーションを変更する必要はありません。
JMS宛先とはJMSクライアントがメッセージの送受信を行う宛先を表すリソースです。アプリケーションでは先に紹介したJMS接続ファクトリーとセットで指定します。
宛先には実際のメッセージング・サービス上に存在するキューやトピックが定義されています。アプリケーションはJMS宛先へメッセージを送り、宛先に紐付けられたキューやトピックにメッセージが届けられます。上記より、アプリケーションは直接メッセージング・サービスに接続してメッセージの送受信を行うのではなく、JMS接続ファクトリーやJMS宛先というWAS上に定義されたリソース定義を経由して接続することがわかります。データベースアクセスの場合と同様にアプリケーション開発者は接続先の情報を把握する必要がありません。したがって、アプリケーションの可搬性が高まり、メッセージング・サービス側の構成変更の影響も受けません。

2.4. JNDI

アプリケーションからメッセージング・サービスへ接続を行う際には、データベースと同様にJNDI(Java Naming and Directory Interface)を使用してアクセスします。JDBCの場合、データーソースのJNDIを参照するのに対して、JMSの場合はJMS接続ファクトリーとJMS宛先のJNDIを参照してアクセスを行います。WAS側のJMS接続ファクトリーやJMS宛先にはJNDI名が定義されており、アプリケーション側でも仮のJNDI名が定義されています。データベースと同様にリソース参照の仕組みを利用して、アプリケーションのインストール時にアプリケーション側とWAS側のJNDIを紐付けることで、アプリケーションとメッセージング・サービスの接続が実現します。第3回データベースアクセスでJNDIについて紹介していますので、そちらも参照してみてください。

図 JNDIによるリソース参照
図 JNDIによるリソース参照

3. メッセージング・サービス接続構成

3章では、JMSアプリケーションがどのようなクラスを使用してどのような流れで接続・送受信を行うのかを確認します。そして、効率的なJMSアクセスを行うための機能についても紹介します。

3.1. アプリケーションの流れ

まず、はじめにJMSアプリケーションについて見ていきましょう。JMS 1.1で定義されたJMS Common Interfaceを利用することで、PTPであるか、Pub/Subであるかに依存しないアプリケーションを開発できます。JMS Common Interfaceを使用したアプリケーションの流れは以下のとおりです。

  1. JNDI名を指定して接続ファクトリー(ConnectionFactory)オブジェクトをlookup
  2. JNDI名を指定して宛先(Destination)オブジェクトをlookup
  3. 接続ファクトリー・オブジェクトから接続(Connection)オブジェクトを生成
  4. 接続オブジェクトからSessionオブジェクトを生成
  5. Sessionオブジェクトから宛先オブジェクトを指定してMessageProducer/MessageConsumerオブジェクトを生成
  6. SessionオブジェクトからMessageオブジェクトを生成
  7. MessageProducer/MessageConsumerオブジェクトにMessageオブジェクトを指定してメッセージを送受信
  8. メッセージの送受信に成功したらSessionオブジェクトをコミット、失敗したらロールバック
  9. 各オブジェクトをクローズ
図 JMSアプリケーションの流れ
図 JMSアプリケーションの流れ

まず、接続ファクトリーのオブジェクトはJNDI名を指定してlookupすることで取得します。前章で紹介したリソース参照の仕組みを利用して、アプリケーション・サーバー側の接続ファクトリーとマッピングが行われ、その先にあるメッセージング・サービスが指定されます。宛先についてもJNDI名を引数に指定してlookupして、宛先オブジェクトを取得しておきます。そして接続ファクトリー・オブジェクトから接続オブジェクトを生成して、メッセージング・サービスへ接続を行います。次に接続オブジェクトからSessionオブジェクトを取得しておきます。Sessionオブジェクトはメッセージング・サービスとのやり取りを管理するクラスであり、トランザクションのコミット/ロールバックなども管理します。尚、JMS1.1では1接続オブジェクトに対してSessionオブジェクトを1つだけ作成するルールになっています。ここまでがメッセージング送受信のための準備作業となります。
次にメッセージの送受信を行います。アプリケーションがメッセージを送信する場合は宛先オブジェクトを引数にしてMessageProducerオブジェクトを生成します。SessionオブジェクトからMessageオブジェクトを生成して、メッセージを作成します。Messageオブジェクトを引数にしてMessageProducerオブジェクトのsend()メソッドによってメッセージを送信します。アプリケーションがメッセージを受信する場合はMessageConsumerオブジェクトを利用します。MessageConsumerオブジェクトのreceive()メソッドによってメッセージを受信します。メッセージの送受信が成功すればSessionオブジェクトをコミットして、失敗した場合はロールバック処理を行い、最後に各オブジェクトをクローズして処理を終了します。

3.2. 接続プールとセッション・プール

アプリケーションの流れの中で、メッセージング・サービスへのアクセスには接続オブジェクトを利用することを説明しました。この接続オブジェクトの生成と消滅はメッセージング・サービスへの接続と切断を意味します。メッセージの送受信の度に接続を繰り返すことでアプリケーション・サーバーやメッセージング・サービスに余分な負荷がかかることになります。この接続処理のオーバーヘッドを緩和するために、一度作成した接続オブジェクトを接続プールに保持して、その後の接続要求に対して再利用することができます。また、JMSアプリケーションでは接続プールに加えてセッション・プールも利用され、Sessionオブジェクトを使いまわすことができます。
接続プールおよびセッション・プールではJ2EE Connector Architecture (JCAまたはJ2C)の仕様に基づいたコネクション・プーリング機能が利用可能です。以下のようなパラメーター設定を行うことができ、各パラメーターについてはデータベースと同様です。

  • 接続タイムアウト
  • 最大接続数
  • 最小接続数
  • リープ時間
  • 未使用タイムアウト
  • 経過時間タイムアウト
図 接続プールおよびセッション・プール
図 接続プールおよびセッション・プール

接続プールに関して、以下のような資料がありますのでご紹介します。


4. MDB

Webシステムがメッセージング・サービスと連携する際には、前述のJMSに加えてMDBを利用した非同期処理が可能です。

4.1. MDB

MDB(Message-Driven Bean)はJMS APIを利用したメッセージ駆動型処理を行うEJBです。Web環境において、業務ロジックを非同期に処理する際によく利用されます。MDBはメッセージを受信した時にEJBコンテナーによって呼び出され、メッセージをEJBアプリケーションで処理することができます。また、並列にメッセージ受信およびビジネスロジックの実行が可能です。

図 MDBのしくみ
図 MDBのしくみ

MDBでは、どのサーバーに接続して、どの宛先を監視するかといった設定をアクティベーション・スペック(Activation Specification:活動化仕様)に記述します。そしてEJBのデプロイメント時には、どのアクティベーション・スペックを利用するかを指定します。

図 アクティベーション・スペックによる監視設定
図 アクティベーション・スペックによる監視設定

4.2. MDBの同時並行数

ここでMDBの処理を効率的に行う方法について少しお話しておきます。MDBは複数のインスタンスを起動することができ、並行してメッセージを処理することができるため、パフォーマンス向上が期待できます。一度作成されたMDBインスタンスは、EJBコンテナーがプーリングするので、次回起動時の初期化処理が短縮されます。アクティベーション・スペックの最大並行エンドポイント数の値でMDBインスタンスの同時稼働数を制限します。


5. メッセージング・トポロジー

これまでの章では、WebアプリケーションがJMSやMDBを利用してメッセージング・サービスへアクセスする方法を紹介しました。JMS APIによるアプリケーションの流れやJMS接続ファクトリーとJMS宛先を経由したメッセージング・リソースへのアクセス方法についてご理解いただけたでしょうか。
最後の章で、WASとWMQを使用したシステムの代表的なトポロジー構成について紹介します。WAS上のJMSアプリケーションがWMQにアクセスする場合のトポロジーはローカル構成とリモート構成に分けることができます。また、接続方式としてバインディング接続とクライアント接続があり、ローカル構成ではバインディング接続、リモート構成ではクライアント接続を利用します。
ローカル構成は最もシンプルなトポロジーであり、各コンポーネントを同一筐体に配置する構成です。WMQへの接続にはバインディング接続を使用します。バインディング接続では、WASが同一筐体上に存在するキュー・マネージャーに直接(Java Class経由)接続します。このトポロジーではJVMとメッセージング・サービスが1つずつ稼働しており、障害時にはSPOF(Single Point of Failure)に陥ってしまうため、テスト環境や開発環境で主に採用されます。

図 ローカル構成
図 ローカル構成

リモート構成はWASとWMQを別筐体に配置します。WMQへの接続にはクライアント接続を使用します。クライアント接続はMQクライアント経由(TCP層を経由する)で接続を行います。MQクライアント(Java/JMS Library)はWASが提供しているJMSプロバイダー(WebSphere MQ messaging provider)に含まれていますので、別途MQクライアントを導入する必要はありません。ただし接続するキュー・マネージャーのバージョンによっては、WMQ側で提供されているMQクライアントが必要になるケースもあります。

図 リモート構成
図 リモート構成

また、高可用性や拡張性を確保する必要がある場合には、サーバーを複数台用意して冗長化構成をとるようにします。アプリケーション・サーバーは、JVMを複数稼働させてクラスター構成をとり、処理の負荷分散を行うようにします。メッセージング・サービスにおいては、キュー・マネージャーを2重化(HA構成)するなどの方法で冗長構成をとります。

図 リモート構成(冗長構成)
図 リモート構成(冗長構成)

WAS虎の巻第4回では、WASからのリソースアクセスとして、JMSとメッセージング・サービス接続についてご紹介しました。次回は、リクエストの処理の流れについてご紹介します。

参考文献

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=WebSphere
ArticleID=710814
ArticleTitle=WAS虎の巻: 第4回「JMSとメッセージング・サービス接続」
publish-date=07132011