Comments
Description
Transcript
WebSphere MQの歴史と原理 概説
WebSphere MQの歴史と原理 概説 WebSphere MQ(旧 MQSeries)は1993年4月に最初のバージョンが発表され、翌年1月に利用可能 になりました。 WebSphere MQはキューを介した時間に依存しない、基幹業務での使用に耐えうる、通信のインフ ラを提供するユニークなソフトウェアです。発表以来、そのユーザーはヨーロッパ、米国、日本をは じめ世界中で増加し続けています。WebSphere MQのサポートするプラットフォームは、 OS/390、VSE/ESA、OS/400、AIX、Sun Solaris、HP-UX、Windows XP、Linux等、３５以上のプラッ トフォームにもなります。一部のプラットフォームを除くと、現在ではV7が最新バージョンとなってい ます。 WebSphere MQはその特長として、各プラットフォーム共通のAPI(アプリケーション・プログラミング・ インターフェース)と共通の基幹機能を提供しています。 WebSphere MQ出現の背景 WebSphere MQが出てきた当時、ITの世界ではビジネス形態の変化に伴いそのビジネスを支える 情報処理形態も変化しつつありました。メインフレーム・コンピューター中心の世界から、Windows やSun Solaris、HP-UX、LinuxなどのUnixシステムが加わり、多種多様なシステムが存在する環境 になりました。それとともに、独自に開発運用されてきた情報システムの孤立が問題になっていま した。その当時、ＩＴシステムはメインフレーム系の基幹システム、Unix系や、Windows系で稼動して いる部門システムなど、さまざまなシステムがほとんど独立した運用形態で存在していました。激 しい競争の時代に、このような孤立したシステムでは企業は生き残れません。各ITシステムは、お 互いに連携して、ビジネスを支える企業のＩＴシステム・インフラとなる必要がありました。また、ア プリケーション開発の観点からは、システム環境の複雑化によるマルチプラットフォームやマルチ プロトコルへの対応がアプリケーション・プログラムの開発の効率を低下させ、移植や柔軟なアプ リケーションのロケーションの変更を困難にしていました。このような変化し続けるシステム環境で のシステム開発には、以下のような事柄を可能にする、強力なミドルウェアが必要になります。 ● ネットワークの複雑さをアプリケーションに意識させない ● アプリケーションの再利用や、移植を容易にするマルチプラットフォーム上での統一性 ● 現在アプリケーションに入り込んでいる通信にかかわる部分(通信のためのセッションの確立 や維持のための処理、通信相手やネットワークの状態を考慮したプログラミング)を不要にする これらを実現するのが、メッセージ・キューイング型の通信形態です。 アプリケーション間通信のモデル IBMでは、分散処理におけるアプリケーション間の通信の方法として3つの型を定義しています。 会話型(conversation)、リモート・プロシジャー・コール型(RPC)、そしてメッセージ・キューイング型 です。それでは、これら3つの方法を比較しメッセージ・キューイング型の特徴をみてみましょう。 会話型の通信の方法では、通信相手(アプリケーション)が同時に稼働している必要があります。 アプリケーションは通信したい相手のアプリケーションとセッションを確立して、会話のための準備 をします。うまくセッションが確立されたら、いよいよ相手との通信、つまりデータを送受します。 これはいうならば、『電話』方式と言えます。まず相手方の電話番号をダイヤルし、相手が出るの を待ちます。相手が出たらお互いに相手を確認して(セッションの確立)会話が始まります。この間 にもし、なんらかの理由でセッションが切れたら、どちらかが再度ダイヤルしセッションの確立を行 います。つまり障害がおきた場合は会話をしている者が自ら回復処理をするということになります。 さて、RPC型ではどうでしょうか。RPC型ではアプリケーションは、CALLという形である機能の実行 (DBの検索など)を要求します。アプリケーション(クライアント)自体は、その機能がどこで実行され るかは知る必要はありません。スタブと呼ばれるルーチン(クライアント・スタブ、サーバー・スタブ) がセッションを確立して、その機能を実行されるサーバーへ要求を転送し、その返答を要求したア プリケーションへ返します。この型もコネクションが前提となる一方、会話型に比べ要求を出すクラ イアントは要求を実行してくれる相手のプログラムがどこにあるかは意識しないですむ、シンプル な方法です。 それでは、メッセージ・キューイング型ではどうでしょうか。この型では送るべきデータは『メッセー ジ』という形で、いったんキューに書き込まれます。その後、システムがキューからメッセージを取 り出して、相手のキューに届けます。このように、キューを介するためアプリケーション間の「直接 的な」セッションは必要ありません。つまり、コネクションレスです。また送信側アプリケーションがメ ッセージを書き込む時点では、そのメッセージを受け取るべき受信側アプリケーションは稼働して いる必要がありません。その相手のアプリケーションはスタートされた後で、自分のキューの中か らメッセージを取り出して処理します。 これは、たとえば『郵便』方式であると言えます。手紙(つまりメッセージ)をポストに投函したら、そ の手紙がどういうルートで宛先に配達されるかは出した人は知る必要はありません。その手紙は 宛先に間違いがなければ、ある時間の後に確実に相手に届けられます。届けられた手紙は宛先 の郵便受けに入れられて取り出されるのを待ちます。また、キューにメッセージを書き込んだ後、 アプリケーションはすぐに次の仕事をすることができるようになります。つまりノンブロッキングとい う特徴をもちます。 図１ 以上の特徴をまとめたものが表1です。 表1 通信方式の比較 IBM WebSphere MQのMQI IBM WebSphere MQは、このメッセージ・キューイング型の通信を実現した通信のインフラを提供 する製品です。ここではその機能をみる前にWebSphere MQのAPIであるMQI(メッセージ・キューイ ング インターフェース)をみてみましょう。 MQIはWebSphere MQにすべて共通のAPIです。このことはアプリケーションを作成する言語を統 一すれば(例えばC、COBOL)、そしてWebSphere MQのサポートするプラットプフォームであれば、 容易なアプリケーションの移行が可能であるということを意味します。 MQIは、従来からの13種類のコールに、WebSphere MQ V7.0でさらに13種類のコールが追加され、 合計26のインターフェースが提供されています。 従来からのMQI • MQBEGIN Unit of Workの開始(RDBMSとのXA連携を行う場合) • MQCONN キュー・マネージャーに接続する • MQCONNX MQCONNの機能強化版. WebSphere MQクライアントから動的にキュ ー・マネージャーに接続する。サーバー側のアプリケーションを”Trusted”アプリケーショ ンとして稼動させるためにキュー・マネージャーに接続する • MQOPEN キューなど各種オブジェクトのオープン • MQPUT メッセージをキューに書く • MQPUT1 メッセージをキューに書く(ただし１メッセージのみ ＭＱＯＰＥＮＭＱＣｌ ｏｓｅを含む) • MQGET キューよりメッセージを取り出す • MQINQ オブジェクト(キュー・マネージャー、キュー、プロセスｅｔｃ)の属性の照 会 • MQSET オブジェクトの属性の変更 • MQCLOSE MQOPENでオープンしたキューなど各種オブジェクトのクローズ • MQBACK 同期点処理対象メッセージをロールバックする • MQCMIT 同期点処理対象メッセージをコミットする • MQDISC キュー・マネージャーとの接続をきる WebSphere MQ V7.0で追加されたMQI • MQSUB サブスクリプションを登録する • MQSUBRQ サブスクリプションをリクエストする • MQSETMP メッセージ・プロパティを1つセットする • MQINQMP メッセージ・プロパティを1つ読む • MQDLTMP メッセージ・プロパティを消去する • MQCRTMH MQPMO、MQGMOにわたすMSGハンドルを作成する • MQDLTMH メッセージ・ハンドルを消去する • MQBUFMH バッファーをメッセージ・ハンドルに変換する • MQMHBUF メッセージ・ハンドルをバッファーに変換する • MQSTAT MQCONNまたは前のMQSTATからの非同期PUTの結果を返す • MQCB キュー・オブジェクトに対する処理ルーチンの登録 • MQCB_FUNCTION CICSでのキュー・オブジェクトに対する処理ルーチンの登録 • MQCTL 処理ルーチンの制御 それでは、あるアプリケーション・プログラムが他のアプリケーション・プログラムへメッセージを送 るケースを考えてみましょう。キュー・マネージャーは、1つのシステム内に複数存在(*1)することが できます。たとえば、本番用とテスト用もしくは、アプリケーションのシステム別に人事システム、経 理システムというような具合です。このような使い分けはシステムのデザインで決まります。 このアプリーション・プログラムはテストでメッセージの送信を行うとすると、 (1) まずテスト用のキュー・マネージャーに対して、MQCONNで接続します。 (2) 次にメッセージを送りたい相手のキューにMQOPENでオープンし、 (3) MQPUTでメッセージをキューに書き出します。 WebSphere Mq上のアプリケーション・プログラムは相手をキューで識別します。必要なメッセージ の送信(キューへの書き出し)が終わったら (4) MQCLOSEでキューをクローズし (5) MQDISCでテスト用キュー・マネージャーとの接続を切ります。 ここでメッセージを１つしか送信しないのであればMQPUT1が使えます。これは MQOPEN/MQPUT/MQCLOSEを１つのコールにまとめたもので、１つのみのメッセージの送信に は便利なものです。メッセージを受け取る場合も同様でこの場合メッセージが入っているキューを MQOPENしてMQGETで受け取ります。メッセージ・キューイング型はノンブロッキングのインターフ ェースを持つと述べましたがこれはMQPUTをした後に、メッセージが相手に届くのを待つのではな くメッセ－ジがキューに成功裡に書き出された時点で、アプリケーション・プログラムに制御がもど り、すぐに次の仕事が始められることを意味します。この特長により後で述べるプログラムの並行 処理が可能となります。 （*1) 1システム上に複数キュー・マネージャーを作成し、同時実行することは可能ですが、管理や パフォーマンスを考えた場合、お勧めしません。 WebSphere MQの機能 WebSphere MQを通信インフラとして利用することにより、アプリケーション・プログラムは WebSphere MQのもつさまざまな機能を利用することができます。 ここではその中から主なものをみてみましょう。 • リプライ • デッド・レター・キュー • トリガリング • ユーザー・エグジット • システム管理機能 ○ リプライ WebSphere MQには以下のような種類のメッセージがあります。その中の1つがリプライ・メッセー ジです。 • リクエスト • リプライ • レポート • データグラム リクエスト・メッセージは返事を要求するメッセージで、アプリケーション・プログラムが何らかの理 由で受け取り側の返事が必要とする場合に使います。そのリクエスト・メッセージの返事にあたる ものがリプライ・メッセージです。 ちなみにレポートメッセージは、メッセージの処理中になんらかのエラーが起こった時にその旨を 知らせるためのメッセージです。データグラムは返事を必要としない、送るだけのメッセージです。 ○ デッド・レター・キュー キュー・マネージャーがなんらかの理由で、メッセージを配送できなかった場合、そのメッセージを 入れておくキューです。キュー・マネージャーはメッセージ が配送できなかった理由を付加してそ のメッセージをデッド・レター・キューに入れます。アプリケーション・プログラムはこのキューをモニ ターすることにより配達されなかったメッセージとその理由というフィードバックを得ることができま す。 ○ トリガリング メッセージを受け取る時の方法として、そのメッセージを処理するアプリケーション・プログラムが 常にキューをモニターして、キュー内にメッセージが入ったらそれをMQGETして処理する方法があ ります。この方法だとメッセージを処理するアプリケーションは常に稼働している必要があります。 メインフレームなど大きなシステムでシステムの資源(メインストレージ)に余裕のある所であれば よいのですが、小さなシステムではこのようなことが許されないケースもあります。そのような時に 使える機能がトリガリングです。キューに対してトリガーである旨指定し、そのメッセージを処理す るプロセス(アプリケーション・プログラム)を定義しておくと、1つのメッセージがキューに入った時 (つまりキュー内のメッセージが0個から1個になった時)や、指定された数のメッセージがたまった 時に定義されたプログラムを起動してメッセージを処理させるというものです。 ○ ユーザー・エグジット WebSphere MQはデータ交換やセキュリティーのためにユーザーが独自の処理を付加するような ケースがあります。このような場合のためにWebSphere MQにはユーザー・エグジットが用意され ています。このエグジットを利用することにより、ユーザー独自のデータ変換や暗号化というような 要求に対処できるようになっています。 ○ 管理機能 キュー・マネージャーはユーザーの指定に基づいて、WebSphere MQの管理する資源(キュー、チ ャネル等)に関してイベント・メッセージを発生させてシステム管理者に通知します。たとえば、ある キューに指定した数以上のメッセージが入った時や定義されてないキューにメッセージを書き込も うとした時などイベント・メッセージを発生させます。これによりシステム管理者はシステムの情報 を自動的な収集が可能になり、システム管理に役立てることができます。 WebSphere MQの特長 前章ではWebSphere MQの持つ主な機能についてみてきましたが、ここではWebSphere MQの特 長のうち、以下にあげる重要な特長をみてみましょう。 • 作業単位(Unit of Work) • メッセージ配送の保証 • 並行処理の実現 ○作業単位(Unit of Work) WebSphere MQを使って相手にメッセージを送る場合、メッセージをMQPUTしてから相手が MQGETでメッセージを受け取るまでの間は、3つの論理的な作業単位にわかれます。 図2 作業単位の考え方 メッセージを配送する時に万が一障害が起こった場合、障害が起こった作業単位の中でリカバリ ーが実施されます。アプリケーション・プログラムAが相手先のキューに対してMQPUTを出しキュ ー・マネージャーが該当のキュー(キューb)にメッセージを書きます。ここまでが1つの作業単位で す。アプリケーション・プログラムAがなんらかの理由で処理を中断して、バックアウト(元の状態に もどす)する必要がでた場合、キューbにすでに書かれたメッセージは削除され、アプリケーション・ プログラムAがMQPUTを出す前の状態に戻ります。 いったん作業単位1がコミット(確定)されると、次にキュー・マネージャーがキューbよりメッセージを 取り出してキューBに送信します。もしこの間に(作業単位2)でなんらかの障害が起こってもキュー・ マネージャーが責任をもってリカバリーし、メッセージが消失したり、二重に送られたりというような ことを防いでいます(メッセージ配送の保証)。 さて､ いったん相手先のキュー(キューB)にメッセージが届けられるとメッセージはアプリケーション・ プログラムBに対してGET可能な状態になり、MQGETを出すことで受け取ることができます。キュ ー・マネージャーは通常アプリケーション・プログラムがメッセージを取り出すとキューよりメッセー ジを削除しますが、作業単位3の中でアプリケーション・プログラムBからのバックアウト要求があ ると、メッセージは削除されずにキューに戻されます。 このようにキューを介した通信と作業単位の分割によりネットワークの複雑をアプリケーション・プ ログラムから見えなくし、かつ確実なメッセージの配送を達成しています。 ○メッセージ配送の保証 WebSphere MQは製品としてメッセージの確実な、1回限りの配送を保証しています。 “論理作業単位”のところで見たように、作業単位ごとにリカバリーを確実に行い、かつWebSphere MQの資源(キュー、メッセージ等)への操作はすべてログが取られ障害時に備えています。ただし、 WebSphere MQのメッセージは2種類あり、リカバリーの対象となるパーシステント・メッセージとリ カバリーの対象にならないノンパーシステント・メッセージがあります。 ノンパーシステント・メッセージは、ハードウェアの障害等でキュー・マネージャー自体がダウンす るようなケースではリカバリーの対象とはなりません。 ○並行処理の実現 これは、WebSphere MQの機能ではありませんがWebSphere MQが提供する機能を使うことで実 現可能になる、アプリケーション・プログラムのデザイン・スタイルです。これにより､ 複雑なメッセ ージ・フローにも柔軟に対応することができるようになります。 図３をごらんください。プログラムA、B、C、Dがあり各プログラムはWebSphere MQのキューを介し てメッセージをやり取りするとします。 図3 プログラムの実行パターン 前にMQI(メッセージ・キューイング インターフェース)のところで述べたように、MQPUTはノンブロッ キングなAPIです。図3の複合パターンのプログラムAのように同時にプログラムB、Cにメッセージ を渡すことができます。メッージが渡されたプログラムB、Cは同時並行的に処理を実行し、結果を プログラムDに渡します。 このようにWebSphere MQをベースにしてアプリケーション・プログラムを 作るとこのような並行処理が実現でき、その結果として全体としてスループットの向上が可能とな ります。 さらに、このようなデザインの利点として、各プログラムは小さくでき、かつ再利用可能な アプリケーションとすることができます。これは、オブジェクト指向の考え方と同じものです。 図4はこのデザインによる銀行におけるローン審査アプリケーションの例です。 図4 ローン審査アプリケーションの例 WebSphere MQの適用分野 WebSphere MQをインフラとして利用することで可能になるアプリケーションの例をあげてみましょ う。 ● 既存アプリケーション・プログラムの有効活用 前述のように、WebSphere MQのＡＰＩであるMQI(メッセージ・キューイング・インターフェース)を追 加することで既存のアプリケーションも容易にWebSphere MQのアプリケーション・プログラムに変 更することができます。また、MQIがネットワークの複雑さを隠してしまうためアプリケーション・プロ グラム自体がシンプルになります。 ● オンラインとバッチの連携処理 CICS/IMS等のトランザクション・マネージャーよりMQIを介してWebSphere MQの機能を利用するこ とが可能になります。これにより、オンライン・トランザクションよりキューを介してバッチプログラム に容易にデータを渡すことができます。 ● データの配布 分散システム環境において分散されたデータ・ベースにデータを配布するというようなケースでも WebSphere MQを利用すれば配布先のシステムの状態にかかわらずデータを配信することができ ます。つまり、配布先のシステムが稼働していない場合でも、立ち上がった時点でメッセージ(デー タ)を受け取ることができます。 ● データ・エントリー データを先に入力しておき、処理が可能になった時に処理することができる(ディファード処理)。 ● メ－ル・システムのインフラ WebSphere MQの機能はE-メール・システムと非常に高い親和性があります。今まで述べてきた ようにWebSphere MQは、メール・システムの基盤そのものとも言えます。ただし、通常のE-メール と違うところは、メッセージの配送が保証されていて、基幹業務の使用に十分耐えうるという点で す。 ● 異機種システム間の通信 WebSphere MQは前述の通りメインフレームからPCまで幅広いプラットフォームをサポートしてい るため、さまざまなプラットフォームに依存するシステム間のメッセージやり取りには最適です。 まとめ 今まで述べてきたWebSphere MQの特長をまとめると、以下のようになります。 ● アプリケーションの通信プロトコルからの独立 ● アプリケーションの稼働環境からの独立(共通のAPI) ● 異なるプラットフォーム/異なるサブシステム間のインターオペラビリティー ● 並行処理による応答時間の短縮 ● プロセスの細分化と再利用(アプリケーションをオブジェクトとして管理) ● メッセージ・デリバリーとリカバリーの保証 ● ワークフロー管理とアプリケーションの分離 このように、WebSphere MQは、数々の優れた機能を持ち、アプリケーション統合などの基幹業務 の使用に耐える通信のインフラを提供する製品です。