- 1 -

1章 WebSphere MQとは......

MQSeriesは、1993年4月に最初のバージョンが発表され、翌年1月より出荷が開始された製品です。

2008年11月現在の最新バージョンは7.0で、名前もMQSeriesからWebSphere MQとなりました。

このWebSphere MQ(MQSeries)は、

● キューを介してデータ交換を行うことで、時間や通信状況、相手側アプリケーションが稼働

しているかどうかといった状況に依存しない

● 様々なプラットフォームに対応しているだけでなく、共通のコマンドやプログラミング・

インターフェースを提供している

などの特徴を持つミドルウェアです。

発表以来、ヨーロッパ、アメリカ、日本を始め世界中のお客様でお使い頂いており、その数は今も

増え続けています。

1-1. WebSphere MQ出現の背景

MQSeriesが出てきた当時、ビジネス形態の変化に伴い、そのビジネスを支える情報処理形態も

変わろうとしていました。

それまでのメインフレーム・コンピューターを中心とする世界から、WindowsやLinux、Sun

Solaris、HP-UX、AIXなどのUNIXシステムなど様々なプラットフォームが加わり、多種多様な

システムがインターネットに接続し混在する環境へと変わりつつありました。

また当時、メインフレーム系の基幹システムとUNIXやWindowsで稼働している部門システムなど、

様々なシステムがほとんど独立した運用を行っておりました。しかし、激しい競争と変化の時代に

このように孤立化したシステム群では、コストや保守の面から企業の競争力を削ぐことになり

ます。そのため各システムは、素早く変化に対応できる柔軟性を持たせつつ、お互いに連携する

ことで、企業を支えるインフラへと進化する必要がありました。

- 2 -

また、このように複雑なシステム環境への対応、例えば複数のプラットフォームやマルチ・

プロトコルへの対応は、アプリケーション・プログラム開発の効率を低下させ、コードの移植や

アプリケーションの配置変更の柔軟性を困難にさせていました。

このような状況を解消するためには、

(1) ネットワークの複雑さを、アプリケーションに意識させないこと.

(2) アプリケーション・プログラムは、エラー処理やセッション維持などのネットワーク

制御をできるだけ取り除き、業務処理に集中させること.

(3) アプリケーションの再利用や、そのコードの移植性を容易にするマルチ・プラット

フォーム上での統一性を持っていること.

(4) 各プラットフォーム上でのシステム管理に統一性があり、容易なこと.

といった条件が、分散処理を実現する通信ミドルウェアに必要とされました。

1-2. 分散処理での通信モデル

一般に分散処理というと、

(1) 会話型

(2) リモート・プロシージャー・コール型

の2つが考えられますが、更に

(3)WebSphere MQのようなメッセージ・キューイング型

があります。これら3つの方法を比較することで、メッセージ・キューイング型通信の特徴を

見てみましょう。

(1) 会話型

会話型の通信では、通信を行うアプリケーションが同時に稼働している必要があり

ます。初めに、アプリケーションは相手側アプリケーションとのセッションを確立し、

その準備を行います。セッションが確立したら、ようやくデータの送受信が可能となり

ます。

(例)SNA APPCによるアプリケーション通信

- 3 -

身近な例では、電話による会話がこの方式になります。電話では、

ⅰ. 最初に、相手の電話番号をダイヤルし、相手が出るのを待つ.

ⅱ. 相手が電話に出たら、お互いに相手を確認

ⅲ. 会話を行う

といった流れになります。この流れの中で、何らかの理由で会話が切れた場合には、

どちらかが再度ダイヤルし、会話ができるようにする必要があります。

(2) リモート・プロシージャー・コール型(以下、RPC型と略します)

RPC型通信の場合は、クライアント・アプリケーションが必要な機能(例えばDB検索

など)を呼び出し(call)という形で要求します。この要求された機能は、スタブと呼ば

れるライブラリーが、その機能を提供しているサーバーへ直接接続を開始し、要求を

送信します。

この要求はサーバー側スタブを経由して、そのサーバー上で定義された機能を呼び出し

実行されます。実行して得られた結果は、上とは逆に、サーバー側スタブ - クライアント

側スタブ - クライアント・アプリケーションという流れで戻されます。

ｃ

この場合、クライアント・アプリケーション自体は、callした機能がどのサーバーで

実行されるかを意識する必要はありません。機能要求の宛先解決やセッション管理などは

クライアント側スタブとサーバー側スタブで行われます。

そのため、会話型通信に比べてRPC型通信を使ったアプリケーションは、セッション

管理や宛先(callした機能がどのサーバー上で実行されるか)を意識しないで済む、シン

プルな方法と言えます。ただし、クライアント・アプリケーションは、自分がcallした

機能がサーバー上で実行されその結果が戻るまで、処理が止まってしまう点(「ブロック

される」とも言います)に注意して下さい。

(3) メッセージ・キューイング型

メッセージ・キューイング型通信の場合、

ⅰ. 送信側プログラムは

- 送信されるデータは、「メッセージ」と呼ばれる形で

- 4 -

- 「キュー」と呼ばれる、領域に

書き込みます。

ⅱ. 受信側との通信が確立すると、送信側の「キュー」に蓄えられた「メッセージ」

は、受信側の「キュー」に転送されます。

ⅲ. その後受信側プログラムが、「キュー」から「メッセージ」を取り出し、その

処理を行う

という流れになります。(手紙を利用した通信販売やe-mailなどを考えると、お解りに

なると思います)

この場合、

●コネクション・レス

送信側アプリケーションは相手との通信状態やセッション状況に関わらず、データ

の送信ができる. 受信側は、都合のいいときにキューからメッセージを読み込み、

そのデータの処理を行うことができる.

●ノン・ブロッキング

送信側アプリケーションはキューにメッセージを書き込んだ直後から、受信側から

の返事を待たずに、後続の処理を行うことができる.

●業務処理集中

送信側アプリケーションと受信側アプリケーションが、キューを介して間接的に

接続されているため、それぞれ

- どのようなデータを送るか

- 受け取ったデータをどのように処理するか

という、データ処理に専念できる.

という利点を持ちます。

- 5 -

1-3. WebSphere MQの適用分野

まず、メッセージ・キューイング方式を用いたアプリケーションのパターンを幾つか見てみま

しょう。

(1) 一方通行

次のページのように、送信側アプリケーションから受信側アプリケーションへ、データ

を送るだけのパターンです。

(2) リクエスト- リプライ型

何らかのメッセージを送信側アプリケーションから送り、受信側ではその処理を行い、

結果を戻すパターンになります。

(3) 実際の適用分野

もう少し具体的なケースを上げてみましょう。

ⅰ. 既存アプリケーションの有効活用

既存のアプリケーションを分散処理に対応させる場合、これまでのプログラム

に通信やセッション管理など大幅な変更を加える必要がありました。メッセー

ジ・キューイング方法を使うと、セッション管理などのコードを減らすことが

できるのでプログラムの修正が少なくなり、再開発が容易になります。

また、それぞれのプログラム同士の依存性を低くできるので、プログラム処理

の並列度が高くなり、システム全体のスルー・プットが高くなることもあります。

(次ページの図参照)

- 6 -

ⅱ. オンライン処理とバッチ処理の連携

キューを介することで時間や処理状況に依存しなくなるため、CICSやEncina

など各種トランザクション・マネージャーからバッチ業務に容易にデータを渡す

ことができるようになります。

ⅲ. データの配布や集積

いろいろな支店に存在するデータ・ベースに必要なデータを配布するような

場合、配布先のシステムの稼働状況や通信状態にかかわらず、データを送る

ことができます。

また、次ページの図のように、それぞれの支店から本社にあるマスターの

データ・ベースへ、データを送る場合も、同様に行うことができます。

- 7 -

1-4. WebSphere MQの機能概説

メッセージ・キューイング方式を使っているWebSphere MQが提供している主な機能には、以下の

ようなものがあります。

(1) 多様なプラットフォームのサポート

次ページの図のように、現在WebSphere MQが稼働するプラットフォームは数多くあり、

主要なプラットフォーム全てで稼働すると言っても過言ではありません。

またTCP/IPを始めとして、SNA・NETBIOS・IPX/SPXといったネットワーク・プロトコルを

サポートしているので、お客様のシステム環境に合わせて利用できる柔軟性があります。

なおこの図で、

ⅰ. 「キュー・マネージャー」とある左側のプラットフォームは、WebSphere MQ

本体が稼働するもの

ⅱ. 「MQIクライアント」とある右側のプラットフォームは、キュー・マネージャーは

稼働しないが、WebSphere MQを使用したアプリケーションを稼働させるための

ライブラリーが提供されているもの

を、それぞれ表します。(「キュー・マネージャー」については、後の章でお話しします)

店 舗 B

支 店 C

支 店 A

本 社

マ ス タ ー D B

- 8 -

図:WebSphere MQのサポートするプラットフォーム

(2) 統一されたプログラミング・インターフェースとコマンド

前述のように、主要なプラットフォームをサポートしていても、お客様やアプリケー

ション・プログラムがそれらの違いを意識しなければならないのでは、

ⅰ. それぞれのプラットフォーム毎にプログラムのコードが異なり、コーディング

作業が複雑になる.

ⅱ. 一つのプラットフォーム上で作成したアプリケーション・プログラムのコード

を、他のプラットフォームで再利用できない

ⅲ. プラットフォーム毎にコマンドが異なるため、システム管理が複雑になる.

などなど、とても大変です。

そのため、WebSphere MQではプログラミング・インターフェース(MQI:Message Queuing

Interfaceと呼ばれる)と管理用コマンドが全てのプラットフォーム共通になっています。

プログラミング・インターフェースの中で基本的な処理を行うものは、次ページの図の

ように13種類となります。これだけのAPIしかないので、アプリケーションからの利用が

容易になります。(機能拡張の結果、V7では26個になりました)

またWebSphere MQの管理コマンドは、

- キューを作成や削除

- 通信相手への経路指定

- キューに対流しているメッセージ数の表示

などの作業を行うものです。各プラットフォームでこれらのコマンドが共通している

ため、開発用システム上で作成した定義情報を、本番システムへ移行することも容易に

できます。

なおWindows版WebSphere MQにのみ、「WebSphere MQ エクスプローラー」や「WebSphere

- 9 -

MQサービス」というGUI(次ページ参照)があります。(補足:WebSphere MQ V6からは、これ

らのGUIはEclipseベースになり、i386版Linux上でも稼働するようになりました)

図:WebSphere MQのAPI

V5.3の「WebSphere MQサービス」と「WebSphere MQエクスプローラー」

MQDISCMQDISC

MQGETMQGET

MQPUTMQPUT

MQINQMQINQ

MQSETMQSET

MQPUT1MQPUT1

MQBEGINMQBEGIN

MQCLOSEMQCLOSE

MQCONN/MQCONNXMQCONN

/MQCONNX

MQCMIT/MQBACKMQCMIT

/MQBACK

MQOPENMQOPEN

MQDISCMQDISC

MQGETMQGET

MQPUTMQPUT

MQINQMQINQ

MQSETMQSET

MQPUT1MQPUT1

MQBEGINMQBEGIN

MQCLOSEMQCLOSE

MQCONN/MQCONNXMQCONN

/MQCONNX

MQCMIT/MQBACKMQCMIT

/MQBACK

MQOPENMQOPEN

- 10 -

V6.0で、EclipseベースとなったWebSphere MQエクスプローラー

(3) メッセージのタイプ ～パーシスタントとノン・パーシスタント～

WebSphere MQで取り扱うメッセージには、大きく分けて2つのタイプがあります。

ⅰ. 持続性メッセージ (「パーシスタント・メッセージ」と言います)

ⅱ. 非持続性メッセージ (「ノン・パーシスタント・メッセージ」と言います)

持続性メッセージの場合、キューへの書き出し時などには、ログ・ファイルに記録して

からキューへ追加されます。そのため、もし

●ハードウェア障害などでシステムが再始動したような場合

●メッセージ転送中に、ネットワーク障害などが生じた場合

でも、メッセージが復元されます。

これに対して、非持続性メッセージの場合、基本的にログに記録されず、メモリー上に

取られたバッファーで処理されるため、その処理が高速になります。しかし、ログに記録

されないために、ハードウェア障害などの場合にはメッセージが失われる事もあります。

(4) メッセージ転送の保証

メッセージの転送時にも、そのメッセージを「確実に」かつ「重複しない」ように転送

するため、WebSphere MQは工夫をしています。

下の図のように2つのWebSphere MQが接続されている場合、

●ユーザー・アプリケーションがキューにメッセージを書き込むタイミング

- 11 -

●実際にメッセージが転送されるタイミング

とが、必ずしも一致するわけではありません。そのためアプリケーションから渡された

メッセージを紛失しないようにするように、メッセージ転送にも、隣接するWebSphere

MQ同士で、メッセージ送達確認を行っています。この送達確認が取れると、送信側の

キューからメッセージが削除されます。もし送達確認に失敗したときには、パーシス

タント・メッセージメッセージは送信側のキューにロールバックされ、再度転送を待つ

ことになります。

では、相手側のキューが一杯になっていて、せっかく送られてきたメッセージを格納

できなかったような場合にはどうでしょうか。

WebSphere MQでは、デッドレター・キューと呼ばれるキュー(マニュアルによっては、

配達不能キューと記述しています)を用意しています。このデッドレター・キューを使う

と、宛先のキューが満杯になって、新たに届いたメッセージを格納できないような場合、

そのメッセージをデッドレター・キューに転送し、残りのメッセージ転送を継続できる

ようにします。

アプリケーション・プログラムA

アプリケーション・プログラムA

WebSphere MQWebSphere MQ

メッセージの読込み

メッセージの読込み

メッセージの読込みメッセージの書込

み

メッセージの書込み

メッセージの書込み

受け取ったよ

OK!

3つ受け取った?

WebSphere MQWebSphere MQ

デ ッ ドレ タ ー ・キ ュ ー

宛 先 の キ ュ ー が満 杯 の た め 、受 け 取 ったメッセ ー ジ を

格 納 で き な い !

受 け 取 った メッ セ ー ジ をデ ッドレ タ ー ・キ ュー へ 転 送

- 12 -

もしデッドレター・キューが使用できない場合は、メッセージ転送は中断し、メッセー

ジ自体は送信側へロールバックされます。(なお非持続メッセージの場合、ロールバック

されない事もあります)

(5) レポート機能

WebSphere MQは、受け取ったメッセージを相手側に確実に転送するように機能します。

しかし

ⅰ. 相手側のキューへ届いたか、どうか.

ⅱ. 相手側のアプリケーションがメッセージを受け取ったか、どうか.

といった確認や、

ⅲ. 相手側にメッセージは届いたものの、送信時に設定した有効期限内に相手側アプ

リケーションが、そのメッセージを処理しなかった.

ⅳ. 何らかの理由で、相手側のキューにメッセージを書き込めず、デッドレター・

キューへ転送された.

といったエラー情報を、アプリケーションが再送処理やメッセージの破棄といった処理の

ために、必要となる場合があります。

WebSphere MQでは、上記のような状況を送信側アプリケーションへ報告するレポート

機能があります。

例えば、「ⅱ.相手側のアプリケーションがメッセージを受け取ったか、どうか」を

確認したい場合、以下のようになります。

a. 送信側アプリケーションがメッセージ生成時に、以下の属性を指定する.

- 「相手側のアプリケーションがメッセージを受け取った」際にレポートを

生成することを要求するオプション

- レポートが送信される宛先(キュー・マネージャーとキュー)

b. メッセージの送信

c. メッセージが宛先のキューへ転送される.

d. 受信側アプリケーションが、メッセージを読み出す.

e. アプリケーションがキューからメッセージを読み出すと、キュー・マネージャーは

レポート・メッセージを生成し、送信側が設定した宛先へ、送信する.

f. 送信側アプリケーションは、戻ってきたレポートを受け取り、必要な処理を行う.

この例ではキュー・マネージャーがレポートを生成しましたが、受信側アプリケー

ションが独自にレポートを生成し、送信元へ戻すこともできます。例えば、受け取った

メッセージに含まれるデータが不正なものであった場合、受信側アプリケーションは

レポート機能を使って、送信側アプリケーションへその旨を通知し、再度正しいデータ

の送信を要求することができます。(これらのレポート・メッセージを処理するのは、

あくまでもアプリケーションになりますので、ご注意下さい)

- 13 -

(6) トリガー機能

先にお話ししたように、メッセージ・キューイング型通信を使う利点の一つとして、

「コネクション・レス」があります。これは、送信側アプリケーションと受信側アプリ

ケーションが同時に稼働していなくとも構わない、つまり時間依存性がないということ

を意味します。

でも、もし送信側アプリケーションからのメッセージが宛先のキューに届いたら、

その処理を行う受信側アプリケーションを自動的に起動できれば、

●メッセージに対する処理が必要な時だけ、アプリケーションを起動することに

なり、システム資源を節約できる.

●人の介在を必要としない.

といった点で、より便利になります。

WebSphere MQではトリガー機能と呼ばれる仕組みを使って、このような機能をサポー

トしています。

トリガー機能では、指定されたキューに

ⅰ. 初めてメッセージが届いた時

ⅱ. メッセージが届く毎

ⅲ. メッセージが予め設定された件数に達した時

のいずれかの場合に、指定されたアプリケーションの起動ができます。

アプリケーション・プログラムA

アプリケーション・プログラムA

キュー・マネージャーキュー・マネージャー

必要な処理

メッセージの読込み

レポートの生成

f

a

bc dメッセージの書込み

e

- 14 -

例えばトリガー機能を使って、キューに初めてメッセージが書き込まれた時にアプリ

ケーションが起動させるためには、

ⅰ. キューの「トリガー属性」を設定

ⅱ. 「初めてメッセージが書き込まれた」というイベントを通知するためのキューを

定義

ⅲ. メッセージ処理を行うアプリケーションの情報を登録

ⅳ. ⅱで定義したキューを監視するためのモニター・プログラムを実行

(このモニター・プログラムが、ⅲで登録したアプリケーションを起動します)

する必要があります。

このトリガー機能を応用すると、送信側でメッセージをキューへ書き込んだ時点に

メッセージ転送を自動開始するようなこともできます。

1-5. まとめ

この章では、

●WebSphere MQが採用しているメッセージ・キューイングの概念

●WebSphere MQが持っている機能

●WebSphere MQを使ったシステム

に関する概要をお話ししました。

特に分散処理の3つの方法については、次ページの表のように整理することができます。もう一度

それぞれの特徴を思い出して下さい。

- 15 -

会話型 RPC型 メッセージ・キューイング型

コネクション/コネクション・レス

コネクション型 コネクション型 コネクション・レス型

プログラム内でのネットワーク制御

必要 不要 不要

通信の相手となるターゲット

相手側プログラム 相手側プログラム キュー

依存性 相手側プログラムが稼働している必要あり

相手側プログラムが稼働している必要あり

相手側プログラムとは独立