(57)【要約】【課題】移行前後のトランザクションモニタの環境下において、汎用機上のアプリケーションのロジックを残しつつ、トランザクションモニタのみを汎用機環境からオープン環境に移行する技術を提供する。【解決手段】本発明に係るトランザクション管理プログラムは、トランザクションモニタが通信セッションを管理する前提で構成されているアプリケーションプログラムと、クライアント端末との間の通信セッションを保持する領域を、記憶装置上に確保する。また、通信セッションを継続する場合は、その領域内の通信セッションデータを次のトランザクションに引き継ぐ。【選択図】図２
2015038641.tif 000002
【特許請求の範囲】
【請求項１】
汎用機上の第１トランザクションモニタを介して呼び出すように構成されたアプリケーションプログラムをクライアント端末から呼び出す第１リクエストを受け付けて、前記第１トランザクションモニタとは異なる第２トランザクションモニタを介して前記アプリケーションプログラムを呼び出す第２リクエストに変換する処理を、コンピュータに実行させるプログラムであって、
前記第１トランザクションモニタは、前記クライアント端末と前記汎用機の間の通信セッションを管理するように構成されており、かつ前記第２トランザクションモニタは、前記クライアント端末と前記コンピュータの間の通信セッションを前記アプリケーションプログラムに委譲するように構成されており、
前記コンピュータに、
前記クライアント端末から前記第１リクエストを受け付けるステップと、
前記クライアント端末と前記コンピュータの間の通信セッションデータを格納するセッションデータ記憶領域を記憶装置上に確保するステップと、
前記アプリケーションプログラムを呼び出してその実行結果を前記クライアント端末に送信する応答ステップと、
前記応答ステップの後も前記クライアント端末と前記コンピュータの間の通信セッションが継続する場合はその通信セッションデータを前記セッションデータ記憶領域に格納し、次のリクエストを前記クライアント端末から受け付けると、前記通信セッションデータを読み出して次のトランザクションに通信セッションを引き継ぐステップと、
を実行させることを特徴とするトランザクション管理プログラム。
【請求項２】
前記コンピュータに、
前記クライアント端末が前記第２トランザクションモニタを介して前記アプリケーションプログラムを呼び出す際に指定する第２トランザクションＩＤと、前記アプリケーションプログラムの識別子と、の対応関係を記述した宛先定義データを読み込む宛先定義読込ステップと、
前記クライアント端末から前記第２トランザクションＩＤを指定して前記第２リクエストを受け付けたときは、前記宛先定義データの記述にしたがって、呼び出すべき前記アプリケーションを特定するステップと、
を実行させることを特徴とする請求項１記載のトランザクション管理プログラム。
【請求項３】
前記宛先定義データは、
前記アプリケーションプログラムが前記第１トランザクションモニタを介して指定する第１トランザクションＩＤと、前記アプリケーションプログラムがトランザクションを送信すべき宛先と、の対応関係を記述しており、
前記コンピュータに、
前記アプリケーションプログラムから前記第１トランザクションＩＤを指定して前記実行結果を受け付けたときは、前記宛先定義データの記述にしたがって、前記アプリケーションプログラムがトランザクションを送信すべき宛先を特定するステップを実行させる
ことを特徴とする請求項２記載のトランザクション管理プログラム。
【請求項４】
前記応答ステップでは、前記コンピュータに、
前記アプリケーションプログラムと対応する前記第１トランザクションＩＤが書き込まれた記憶装置上の記憶領域から前記第１トランザクションＩＤを読み込むステップと、
前記第１トランザクションＩＤと前記宛先定義データの記述にしたがって、前記アプリケーションプログラムがトランザクションを送信すべき宛先を特定するステップと、
を実行させることを特徴とする請求項２または３記載のトランザクション管理プログラム。
【請求項５】
前記コンピュータに、
前記応答ステップにおいて呼び出された前記アプリケーションプログラムが新たに起動するトランザクションを、前記第２トランザクションモニタの配下で実行する新たなトランザクションとして受け付けるステップを実行させる
ことを特徴とする請求項１から４のいずれか１項に記載のトランザクション管理プログラム。
【請求項６】
前記第１トランザクションモニタは、前記クライアント端末が用いるパラメータと、前記第１トランザクションモニタが用いるパラメータとの対応関係を記述した第１データマップを用いるように構成されており、
前記第２トランザクションモニタは、前記クライアント端末が用いるパラメータと、前記第２トランザクションモニタが用いるパラメータとの対応関係を、前記第１データマップとは異なる形式で記述した第２データマップを用いるように構成されており、
前記コンピュータに、
前記第１データマップと前記第２データマップを相互変換するデータマップ変換ステップを実行させる
ことを特徴とする請求項１から５のいずれか１項に記載のトランザクション管理プログラム。
【請求項７】
前記アプリケーションプログラムから呼び出され、請求項２から４までのいずれか１項に記載のトランザクション管理プログラムが前記宛先定義読込ステップで読み込む前記宛先定義データを、第２コンピュータに生成させるプログラムであって、
前記第２コンピュータに、
前記アプリケーションプログラム、前記第１トランザクションＩＤ、および前記アプリケーションプログラムがトランザクションを送信すべき宛先の対応関係を定義する資源定義データを読み込むステップと、
前記資源定義データの記述および前記第２トランザクションモニタが用いる第２トランザクションＩＤの仕様にしたがって、前記宛先定義データを生成するステップと、
を実行させることを特徴とする宛先定義生成プログラム。
【請求項８】
請求項６記載のトランザクション管理プログラムから呼び出され、前記データマップ変換ステップを前記コンピュータに実行させるプログラムモジュールを、第３コンピュータに生成させるプログラムであって、
前記第３コンピュータに、
前記第１データマップまたは前記第１データマップのデータ形式を定義するデータを読み込むステップと、
前記第１データマップまたは前記第１データマップのデータ形式を定義するデータの記述にしたがって、前記第１データマップを第２データマップに動的に変換するプログラムモジュールを生成するステップと、
を実行させることを特徴とするデータマップ変換モジュール生成プログラム。
【請求項９】
汎用機上の第１トランザクションモニタを介して呼び出すように構成されたアプリケーションプログラムを、前記第１トランザクションモニタとは異なる第２トランザクションモニタを介して呼び出されるアプリケーションプログラムに変換する処理を、第４コンピュータに実行させるプログラムであって、
前記第４コンピュータに、
前記アプリケーションプログラムのうち前記第１トランザクションモニタを利用するインタフェースを呼び出す処理を、
請求項１から６のいずれか１項に記載のトランザクション管理プログラムを呼び出す処理に書き換えさせる
ことを特徴とするソースコード変換プログラム。
【請求項１０】
汎用機上の第１トランザクションモニタを介して呼び出すように構成されたアプリケーションプログラムを、前記第１トランザクションモニタとは異なる第２トランザクションモニタを介して呼び出されるアプリケーションプログラムに変換する処理を、第４コンピュータに実行させるプログラムであって、
前記第４コンピュータに、
前記アプリケーションプログラムのうち前記第１トランザクションモニタを利用するインタフェースを呼び出す処理を、請求項４記載のトランザクション管理プログラムを呼び出す処理に書き換えさせるとともに、
前記アプリケーションプログラムと対応する前記第１トランザクションＩＤが書き込まれた記憶装置上の記憶領域に前記第１トランザクションＩＤを書き込むプログラムモジュールを呼び出す処理を、前記アプリケーションプログラム内に追加させる
ことを特徴とするソースコード変換プログラム。
【請求項１１】
請求項１から６のいずれか１項に記載のトランザクション管理プログラムと、
請求項７記載の宛先定義生成プログラムと、
請求項８記載のデータマップ変換モジュール生成プログラムと、
請求項９または１０記載のソースコード変換プログラムと、
各前記プログラムを実行するコンピュータと、
を有することを特徴とするトランザクション管理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、汎用機上のトランザクションモニタを介して呼び出すように構成されたアプリケーションプログラムを、他のトランザクションモニタを介して呼び出す技術に関するものである。
【背景技術】
【０００２】
従来、企業の基幹業務システムなどの大規模情報システムでは、汎用機（メインフレーム、ホストなどとも呼ぶ）が用いられてきた。しかし、ダウンサイジングなどの要求が高まるにつれ、汎用機で稼動しているアプリケーションやミドルウェアを、ＵＮＩＸサーバなどのオープンシステムに移行することが求められている。
【０００３】
汎用機のなかには、クライアント端末の画面からアプリケーションにアクセスする際のトランザクション管理機能を提供するトランザクションモニタを備えているものがある。この汎用機上のトランザクションモニタと互換性のあるオープン環境上のトランザクションモニタが存在しない場合、オープン環境上のトランザクションモニタの仕様に合わせてアプリケーションを移行する必要がある。
【０００４】
汎用機アプリケーションをオープンシステムに移行する技術として、汎用機上で稼動するＣＯＢＯＬアプリケーションをＪａｖａなどのオープンシステムで用いられるプログラムに変換する技術がある。
【０００５】
その他、下記特許文献１には、メインフレームのアプリケーションをオープン環境に移行する技術として、画面構成に着目したものが記載されている。同文献では、汎用画面フォームと汎用画面データを用いて、複数のメインフレームに対応可能な画面フォームを構成することが記載されている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００４−３５５４１３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
汎用機上のトランザクションモニタのなかには、クライアント端末と汎用機の間の通信セッションを管理する機能を備えたものが存在する。通信セッションを管理するとは、例えばクライアント端末と汎用機の間で通信が１往復した後も、通信コネクションをそのまま維持しておき、次回の通信は前回の通信から継続しているものとして取り扱う、といったような、通信の継続性を管理することをいう。
【０００８】
しかし、必ずしも全てのトランザクションモニタが上記のような通信セッション管理機能を備えているとは限らず、通信セッションの管理をアプリケーションに委譲しているトランザクションモニタも存在する。
【０００９】
通信セッションを管理する汎用機上のトランザクションモニタから、通信セッションを管理しないオープン環境のトランザクションモニタに移行するためには、移行後のトランザクションモニタにおける通信セッション管理の仕様に合わせてアプリケーションを移行する必要がある。
【００１０】
汎用機上のトランザクションモニタを利用するアプリケーションをオープンシステムに移行するためには、上述の通りアプリケーションを再構築したり、プログラムを変換したりする必要がある。
【００１１】
しかし、アプリケーションを再構築するのは多大なコストと時間がかかる。またプログラムを変換するにしても、トランザクションモニタの仕様の違いに起因して、トランザクションモニタと連携する部分のプログラム上のロジックを書き換える必要が生じ、必ずしも全て自動変換できるとは限らない。プログラマがプログラムを書き換える場合、アプリケーションを再構築するのと同様のコストと時間を要する。
【００１２】
本発明は、上記のような課題を解決するためになされたものであり、上述のような移行前後のトランザクションモニタの環境下において、汎用機上のアプリケーションのロジックを残しつつ、トランザクションモニタのみを汎用機環境からオープン環境に移行する技術を提供することを目的とする。
【課題を解決するための手段】
【００１３】
本発明に係るトランザクション管理プログラムは、トランザクションモニタが通信セッションを管理する前提で構成されているアプリケーションプログラムと、クライアント端末との間の通信セッションを保持する領域を、記憶装置上に確保する。また、通信セッションを継続する場合は、その領域内の通信セッションデータを次のトランザクションに引き継ぐ。
【発明の効果】
【００１４】
本発明に係るトランザクション管理プログラムによれば、アプリケーションプログラムは通信セッションを管理する必要がないので、移行後のトランザクションモニタに合わせてアプリケーションプログラムを書き換える必要はない。これにより、アプリケーションプログラムをほぼ変更することなく、トランザクションモニタ環境のみを、オープン環境に移行することができる。
【図面の簡単な説明】
【００１５】
【図１】汎用機上で動作するトランザクションモニタの動作と、オープン環境で動作するトランザクションモニタの動作とを比較する図である。
【図２】実施の形態１に係るトランザクション管理システム３０００の構成を示す図である。
【図３】実施形態１に係るトランザクション管理システム３０００の動作シーケンスを説明する図である。
【図４】実施の形態２に係るトランザクション管理システム３０００および移行前の汎用機環境におけるトランザクション管理システム１０００の構成を示す図である。
【図５】宛先定義データ３６０の構成例を示す図である。
【図６】実施形態２に係るトランザクション管理システム３０００の動作シーケンスを説明する図である。
【図７】汎用機上で動作するトランザクションモニタの動作と、オープン環境で動作するトランザクションモニタの動作とを比較する図である。
【図８】実施の形態３に係るトランザクション管理システム３０００の構成を示す図である。
【図９】実施形態３に係るトランザクション管理システム３０００の動作シーケンスを説明する図である。
【図１０】実施形態４に係るトランザクション管理システム３０００の動作シーケンスを説明する図である。
【図１１】実施の形態５に係るトランザクション管理システム３０００の構成を示す図である。
【図１２】実施の形態６に係るトランザクション管理システム３０００の周辺環境を示す図である。
【発明を実施するための形態】
【００１６】
＜トランザクションモニタの動作の差異＞
本発明は、トランザクションモニタの動作が個々のトランザクションモニタによって異なり、またその差異に起因してアプリケーションプログラムの構成が異なる環境を想定している。そこでまず初めに、本発明の前提となるトランザクションモニタ毎の動作の違いについて説明する。その後に、本発明に係るトランザクション管理プログラムの構成と動作を説明する。
【００１７】
なお、以下の説明では、記載の都合上、トランザクションモニタやＣＯＢＯＬアプリケーションプログラムなどのソフトウェアを動作主体として記述することがあるが、実際にこれらのソフトウェアを実行するのは、汎用機などのコンピュータであることを付言しておく。
【００１８】
図１は、汎用機上で動作するトランザクションモニタの動作と、オープン環境で動作するトランザクションモニタの動作とを比較する図である。図１（ａ）は汎用機上で動作するトランザクションモニタ、図１（ｂ）はオープン環境で動作するトランザクションモニタを示す。
【００１９】
図１（ａ）において、トランザクション管理システム１０００は、クライアント端末１１０、汎用機１２０を有する。汎用機１２０は、第１ＴＰモニタ（Ｔｒａｎｓａｃｔｉｏｎ  Ｐｒｏｃｅｓｓｉｎｇ  Ｍｏｎｉｔｏｒ）１３０、ＣＯＢＯＬプログラム１５０を実行する。
【００２０】
クライアント端末１１０は、汎用機１２０に対して、ＣＯＢＯＬプログラム１５０を実行するようリクエストする。汎用機１２０上の第１ＴＰモニタ１３０は、そのリクエストを受け付け、トランザクションを起動し、ＣＯＢＯＬプログラム１５０を呼び出す。ＣＯＢＯＬプログラム１５０は、ＴＰモニタインタフェース１６０を介して、第１ＴＰモニタ１３０に実行結果を戻す。第１ＴＰモニタ１３０は、その実行結果をクライアント端末１１０に送信し、トランザクションは終了する。
【００２１】
クライアント端末１１０と汎用機１２０の間の通信セッションが継続する場合、第１ＴＰモニタ１３０は、その通信セッションの内容を通信セッションデータベース１４０に格納する。第１ＴＰモニタ１３０は、クライアント端末１１０から次のリクエストを受け取ると、通信セッションデータベース１４０から以前の通信セッションの内容を読み出し、新たなリクエストに引き継ぐ。
【００２２】
図１（ｂ）において、トランザクション管理システム２０００は、クライアント端末２１０、サーバ２２０を有する。サーバ２２０はＵＮＩＸなどを用いたオープンシステムとして構成されており、第２ＴＰモニタ２３０、ＣＯＢＯＬプログラム２５０を実行する。
【００２３】
ここでは、通信セッションの管理に関し、第１ＴＰモニタ１３０の動作と第２ＴＰモニタ２３０の動作が異なることを想定する。第２ＴＰモニタ２３０は、自身では通信セッションを管理せず、ＣＯＢＯＬプログラム２５０に通信セッションの管理を委譲する。そのためＣＯＢＯＬプログラム２５０は、図１（ａ）におけるＣＯＢＯＬプログラム１５０とは異なる処理を実行しなければならない。
【００２４】
クライアント端末２１０は、サーバ２２０に対して、ＣＯＢＯＬプログラム２５０を実行するようリクエストする。サーバ２２０上の第２ＴＰモニタ２３０は、そのリクエストを受け付け、トランザクションを起動し、ＣＯＢＯＬプログラム２５０を呼び出す。ＣＯＢＯＬプログラム２５０は、第２ＴＰモニタ２３０に実行結果を戻す。第２ＴＰモニタ２３０は、その実行結果をクライアント端末２１０に送信し、トランザクションは終了する。
【００２５】
クライアント端末２１０とサーバ２２０の間の通信セッションが継続する場合、ＣＯＢＯＬプログラム２５０は、その通信セッションの内容を通信セッションデータベース２４０に格納する。ＣＯＢＯＬプログラム２５０は、クライアント端末２１０から次のリクエストを受け取ると、通信セッションデータベース２４０から以前の通信セッションの内容を読み出し、新たなリクエストに引き継ぐ。
【００２６】
以上説明したように、トランザクションモニタの動作が異なると、ＣＯＢＯＬプログラムの動作も異なる場合がある。そのため、トランザクションモニタをオープン環境に移行するとき、ＣＯＢＯＬプログラムを移行後の環境に合わせて書き換えるなどの作業が発生する可能性がある。
【００２７】
本発明では、汎用機環境におけるＣＯＢＯＬプログラム１５０をできる限りそのまま用いて、トランザクションモニタのみをオープン環境に移行することを図る。
【００２８】
＜実施の形態１＞
図２は、本発明の実施の形態１に係るトランザクション管理システム３０００の構成を示す図である。トランザクション管理システム３０００は、クライアント端末２１０、サーバ２２０を有する。サーバ２２０は、第２ＴＰモニタ２３０、トランザクション管理プログラム３１０、ＣＯＢＯＬプログラム１５０を実行する。トランザクション管理プログラム３１０は、通信セッションデータベース３４０を作成および管理する。
【００２９】
通信セッションデータベース３４０は、例えばＨＤＤ（Ｈａｒｄ  Ｄｉｓｋ  Ｄｒｉｖｅ）やメモリ装置などのような書き込み可能な記憶装置上に、通信セッションの内容を保持する通信セッションデータを格納することにより、構成することができる。
【００３０】
クライアント端末２１０と第２ＴＰモニタ２３０は、図１（ｂ）で説明したオープン環境下のものと同じである。すなわちクライアント端末２１０は、第２ＴＰモニタ２３０の配下でＣＯＢＯＬプログラム２５０を実行することを想定している。
【００３１】
一方、ＣＯＢＯＬプログラム１５０は、トランザクション管理プログラム３１０がＣＯＢＯＬプログラム１５０と第２ＴＰモニタの間に仲介する点を除いて、図１（ａ）で説明した汎用機環境下のものと同じである。すなわちＣＯＢＯＬプログラム１５０は、通信セッションの管理についてはトランザクションモニタに委譲し、自身は通信セッションを管理しないことを想定している。
【００３２】
なお、トランザクション管理プログラム３１０を仲介させるため、図１（ａ）においてＣＯＢＯＬプログラム１５０がＴＰモニタインタフェース１６０を呼び出す部分は、トランザクション管理プログラム３１０のインタフェースを呼び出すように、あらかじめ書き換えられているものとする。
【００３３】
先に説明したように、クライアント端末２１０および第２ＴＰモニタ２３０と、ＣＯＢＯＬプログラム１５０とは、通信セッションの管理について仕様が異なっている。そこで本実施形態１では、トランザクション管理プログラム３１０が両者を仲介し、通信セッションを管理する。
【００３４】
図３は、本実施形態１に係るトランザクション管理システム３０００の動作シーケンスを説明する図である。以下、図３の各ステップについて説明する。なお、記載の都合上、一部の構成要素は省略した。
【００３５】
（図３：ステップＳ３０１）
クライアント端末２１０は、サーバ２２０に対して、ＣＯＢＯＬプログラム１５０を実行するようリクエストする。このときクライアント端末２１０は、第２ＴＰモニタ２３０の配下で動作するＣＯＢＯＬプログラムを呼び出すことを想定している。
（図３：ステップＳ３０２）
第２ＴＰモニタ２３０は、クライアント端末２１０からのリクエストを受け付け、新たなトランザクションを起動し、トランザクション管理プログラム３１０にそのリクエストを引き渡す。
【００３６】
（図３：ステップＳ３０３）
トランザクション管理プログラム３１０は、ＣＯＢＯＬプログラム１５０を呼び出す。このとき、クライアント端末２１０から受け取ったリクエストのパラメータ形式を変換するなど、トランザクションモニタの違いに起因する差異を吸収する処理を適宜実行するようにしてもよい。
（図３：ステップＳ３０４）
ＣＯＢＯＬプログラム１５０は、自身が規定するアプリケーション処理を実行し、トランザクション管理プログラム３１０を呼び出すインタフェースを介して、トランザクション管理プログラム３１０に実行結果を戻す。
【００３７】
（図３：ステップＳ３０５）
トランザクション管理プログラム３１０は、ステップＳ３０１でクライアント端末２１０から受け付けたリクエストが、通信セッションを維持すべきものである場合は、通信セッションデータベース３４０にその通信セッションの内容を通信セッションデータとして格納する。ここでいう通信セッションデータとは、例えば通信セッションの識別子、前回画面の入力情報、処理途中結果など、通信セッションの継続に必要なデータである。
（図３：ステップＳ３０５：補足）
図３では、通信セッションの往復双方について、本ステップ内で通信セッションデータベース３４０に通信セッションデータを格納するものとしたが、例えば上りセッションについては、ステップＳ３０２とＳ３０３の間で通信セッションデータベース３４０に通信セッションデータを格納するなどしてもよい。通信セッションの内容を保持することができれば、本ステップに相当する処理の実行タイミングは任意でよい。
【００３８】
（図３：ステップＳ３０６〜Ｓ３０７）
第２ＴＰモニタ２３０は、ＣＯＢＯＬプログラム１５０の実行結果を受け取り、クライアント端末２１０に送信する。第２ＴＰモニタ２３０は、クライアント端末２１０から次のリクエストを受け取ると、ステップＳ３０１以降と同様の処理を実行する。ただし、前回のリクエストにおいて、通信セッションを維持するよう要求されている場合は、通信セッションデータベース３４０から前回までの通信セッションデータを読み出し、新たなリクエストにその通信セッションデータを引き継ぐ。
【００３９】
＜実施の形態１：まとめ＞
以上のように、本実施の形態１に係るトランザクション管理プログラム３１０は、クライアント端末２１０とサーバ２２０の間の通信セッションの内容を、通信セッションデータベースに通信セッションデータとして格納する。これによりＣＯＢＯＬプログラム１５０は、自身で通信セッションを管理する必要がなくなるので、通信セッションを管理しない第２ＴＰモニタ２３０の配下でも、第１ＴＰモニタ１３０が通信セッションを管理する前提で構成されているアプリケーション動作を実行することができる。また、ＣＯＢＯＬプログラム１５０に通信セッション管理機能を追加する必要はない。
【００４０】
また、本実施の形態１に係るトランザクション管理プログラム３１０は、クライアント端末２１０から受け取ったリクエストを前回のリクエストにおける通信セッションに継続させる場合は、通信セッションデータベース３４０から対応する通信セッションデータを読み出して、新たなリクエストに引き継ぐ。これにより、通信セッションを管理する第１ＴＰモニタ１３０と同様の環境を、通信セッションを管理しない第２ＴＰモニタ２３０の配下で実現することができる。
【００４１】
＜実施の形態２＞
本発明の実施の形態２では、第１ＴＰモニタ１３０がアクセスするクライアント端末１１０やＣＯＢＯＬプログラム１５０などの外部リソースが、資源情報として定義されている環境を想定する。
【００４２】
図４は、本実施の形態２に係るトランザクション管理システム３０００および移行前の汎用機環境におけるトランザクション管理システム１０００の構成を示す図である。以下図４に示す各構成について説明する。
【００４３】
図４（ａ）において、資源定義データ１７０は、クライアント端末１１０、ＣＯＢＯＬプログラム１５０などを一意に識別する識別子を記述している。また、例えばＣＯＢＯＬプログラム１５０に関してはそのプログラム名称などを併せて記述している。第１ＴＰモニタ１３０は、資源定義データ１７０を読み込み、クライアント端末１１０、ＣＯＢＯＬプログラム１５０などを一意に識別する。その他の構成は、図１（ａ）と同様である。
【００４４】
図４（ａ）において、ＣＯＢＯＬプログラム１５０は、実行結果を第１ＴＰモニタ１３０に引き渡せばよく、その宛先種別を意識する必要はない。ＣＯＢＯＬプログラム１５０の実行結果を送信すべき宛先の種別は、資源定義データ１７０に定義されている。第１ＴＰモニタ１３０は、資源定義データ１７０の記述にしたがって、ＣＯＢＯＬプログラム１５０の実行結果をクライアント端末１１０に送信する。
【００４５】
これに対し、第２ＴＰモニタ２３０は、第１ＴＰモニタ１３０のような宛先制御機能を備えておらず、宛先制御はＣＯＢＯＬプログラム２５０に委譲する。そのためＣＯＢＯＬプログラム２５０は、図４（ａ）におけるＣＯＢＯＬプログラム１５０とは異なる処理を実行しなければならない。
【００４６】
図４（ｃ）におけるトランザクション管理システム３０００は、図４（ａ）において第１ＴＰモニタ１３０が資源定義データ１７０を用いてトランザクションの宛先を管理する動作を模擬するため、後述する宛先定義データ３６０を用いる。
【００４７】
図４（ｃ）において、トランザクション管理システム３０００は、図２で説明した構成に加え、新たに宛先定義データ３６０、宛先定義生成プログラム４１０を備える。宛先定義生成プログラム４１０は、資源定義データ１７０を読み込んで宛先定義データ３６０を生成するプログラムである。宛先定義データ３６０の構成は、後述の図５で説明する。
【００４８】
図５は、宛先定義データ３６０の構成例を示す図である。宛先定義データ３６０は、第１ＴＰモニタ１３０配下における各外部リソースと、第２ＴＰモニタ２３０配下における各外部リソースとの対応関係を定義するデータである。
【００４９】
宛先定義データ３６０は、第１トランザクションＩＤ３６１、宛先種別３６２、第２トランザクションＩＤ３６３、プログラム名３６４、会話モード３６５、通話セッションバッファサイズ３６６を保持する。
【００５０】
第１トランザクションＩＤ３６１は、ＣＯＢＯＬプログラム１５０が第１ＴＰモニタ１３０の配下で用いるトランザクションＩＤである。第２トランザクションＩＤ３６３は、クライアント端末２１０が第２ＴＰモニタ２３０の配下で用いるトランザクションＩＤである。
【００５１】
宛先種別３６２は、第１トランザクションＩＤ３６１または第２トランザクションＩＤ３６３によって識別されるトランザクションの宛先種別を記述する。例えば、クライアント端末２１０からＣＯＢＯＬプログラム１５０を呼び出すトランザクションの宛先種別３６２は「ＣＯＢＯＬプログラム」となる。同様に、ＣＯＢＯＬプログラム１５０からプリンタに印刷データを送信するトランザクションの宛先種別３６２は「プリンタ」となる。宛先種別とともに、宛先のアドレスなどを記述することもできる。
【００５２】
プログラム名３６４は、ＣＯＢＯＬプログラム１５０を識別するためのプログラム名である。会話モード３６５は、第１トランザクションＩＤ３６１または第２トランザクションＩＤ３６３によって識別されるトランザクションが通信セッションを保持すべきトランザクションであるか否かを示す。通信セッションバッファサイズ３６６は、通信セッションを保持すべきトランザクションについて、通信セッションデータベース３４０上に確保すべきバッファ領域のサイズを示す。
【００５３】
図６は、本実施形態２に係るトランザクション管理システム３０００の動作シーケンスを説明する図である。以下、図６の各ステップについて説明する。なお、記載の都合上、一部の構成要素は省略した。
【００５４】
（図６：ステップＳ６０１）
クライアント端末２１０は、サーバ２２０に対して、ＣＯＢＯＬプログラム１５０を実行するようリクエストする。このときクライアント端末２１０は、第２ＴＰモニタ２３０の配下で動作するＣＯＢＯＬプログラムを呼び出すことを想定しているので、第２ＴＰモニタ２３０の規則にしたがって付与した第２トランザクションＩＤを指定して、リクエストを発行する。
（図６：ステップＳ６０２）
第２ＴＰモニタ２３０は、クライアント端末２１０からのリクエストと第２トランザクションＩＤを受け付け、トランザクション管理プログラム３１０にそのリクエストを引き渡す。
【００５５】
（図６：ステップＳ６０３）
トランザクション管理プログラム３１０は、第２トランザクションＩＤ３６３をキーにして宛先定義データ３６０を照会し、対応する第１トランザクションＩＤ３６１を取得する。また、呼び出すべきＣＯＢＯＬプログラム１５０の名称をプログラム名３６４から取得して特定する。
（図６：ステップＳ６０４）
トランザクション管理プログラム３１０は、新たなトランザクションを起動し、ステップＳ６０３で特定したＣＯＢＯＬプログラム１５０を呼び出す。このとき指定するトランザクションＩＤは、ステップＳ６０３で取得した第１トランザクションＩＤである。
【００５６】
（図６：ステップＳ６０５）
ＣＯＢＯＬプログラム１５０は、自身が規定するアプリケーション処理を実行し、トランザクション管理プログラム３１０を呼び出すインタフェースを介して、トランザクション管理プログラム３１０に実行結果を戻す。このとき指定するトランザクションＩＤは、第１ＴＰモニタ１３０配下で用いられる第１トランザクションＩＤである。
（図６：ステップＳ６０５：補足）
本ステップにおいて、ＣＯＢＯＬプログラム１５０は、クライアント端末２１０へ返信するトランザクションとは別に、新たなトランザクションを平行して起動してもよい。また、新たに起動するトランザクションの宛先は、クライアント端末２１０以外の端末であってもよい。各プログラムが新たなトランザクションを処理するプロセスは、以下のステップと同様である。
【００５７】
（図６：ステップＳ６０６）
トランザクション管理プログラム３１０は、第１トランザクションＩＤをキーにして宛先定義データ３６０を照会し、対応する第２トランザクションＩＤを取得する。また、呼び出すべきクライアント端末２１０の種別と、必要に応じてそのアドレスを、宛先種別３６２から取得して特定する。
（図６：ステップＳ６０７〜Ｓ６０９）
これらのステップは、図３のステップＳ３０５〜Ｓ３０７と同様である。トランザクションＩＤには、第２ＴＰモニタ２３０配下で用いられる第２トランザクションＩＤが指定される。
【００５８】
＜実施の形態２：まとめ＞
以上のように、本実施の形態２において、宛先定義データ３６０は、第１ＴＰモニタ１３０配下で用いられる第１トランザクションＩＤ３６１と、ＣＯＢＯＬプログラム１５０の実行結果を送信すべきクライアント端末２１０の宛先を記述した宛先種別３６２との対応関係を記述している。これにより、ＣＯＢＯＬプログラム１５０は、トランザクションの宛先制御を第１ＴＰモニタ１３０に委譲しているものと同様の動作を実行することができるので、宛先制御機能をＣＯＢＯＬプログラム１５０に追加する必要はない。
【００５９】
また、本実施の形態２において、宛先定義データ３６０は、第２ＴＰモニタ２３０配下で用いられる第２トランザクションＩＤ３６３と、当該第２トランザクションＩＤ３６３によって識別されるトランザクションの下で呼び出すべきＣＯＢＯＬプログラム１５０のプログラム名との対応関係を記述している。これによりクライアント端末２１０は、第２ＴＰモニタ２３０配下で用いられる第２トランザクションＩＤを指定して、ＣＯＢＯＬプログラム１５０を呼び出すことができる。
【００６０】
＜実施の形態３＞
本発明の実施の形態３では、ＣＯＢＯＬプログラム１５０の実行結果をクライアント端末１１０に送信する処理について、第１ＴＰモニタ１３０が責任を持つ環境を想定する。一方、第２ＴＰモニタ２３０はＣＯＢＯＬプログラム２５０の実行結果をクライアント端末２１０に送信する責任を持たず、ＣＯＢＯＬプログラム２５０が自ら実行結果を宛先に送信する環境を想定する。
【００６１】
図７は、上記想定の下、汎用機上で動作するトランザクションモニタの動作と、オープン環境で動作するトランザクションモニタの動作とを比較する図である。図７（ａ）は汎用機上で動作するトランザクションモニタ、図７（ｂ）はオープン環境で動作するトランザクションモニタを示す。
【００６２】
図７（ａ）において、クライアント端末１１０は、第１ＴＰモニタ１３０配下で用いられる第１トランザクションＩＤを指定して、ＣＯＢＯＬプログラム１５０を実行するようリクエストする。第１ＴＰモニタ１３０は、新たなトランザクションを起動し、ＣＯＢＯＬプログラム１５０を呼び出す。ＣＯＢＯＬプログラム１５０は、トランザクションについては関与せず、単に自身の実行結果のみを第１ＴＰモニタ１３０に戻す。第１ＴＰモニタ１３０は、実施形態２で説明した資源定義データ１７０の記述にしたがって、ＣＯＢＯＬプログラム１５０の実行結果をクライアント端末１１０に送信する。
【００６３】
図７（ｂ）において、クライアント端末２１０は、第２ＴＰモニタ２３０配下で用いられる第２トランザクションＩＤを指定して、ＣＯＢＯＬプログラム２５０を実行するようリクエストする。第２ＴＰモニタ２３０は、新たなトランザクションを起動し、ＣＯＢＯＬプログラム２５０を呼び出す。ＣＯＢＯＬプログラム２５０は、実行結果をクライアント端末２１０に送信する処理について、自身が責任を持つ。そのため、ＣＯＢＯＬプログラム２５０から第２ＴＰモニタ２３０に対して、実行結果をクライアント端末２１０に送信する際の手続きなどを指示する必要がある。
【００６４】
図７（ａ）に示す環境下では、ＣＯＢＯＬプログラム１５０は自身の実行結果を第１ＴＰモニタ１３０に戻しさえすればよく、その後の処理については第１ＴＰモニタ１３０に委譲し、関与する必要はない。これに対し図７（ｂ）に示す環境下では、ＣＯＢＯＬプログラム２５０は単に自身のアプリケーションロジックを実行するのみならず、クライアント端末２１０との間の手続きについても関与する必要がある。
【００６５】
したがって、図７（ａ）に示す環境において、トランザクションモニタのみを第１ＴＰモニタ１３０から第２ＴＰモニタ２３０に移行することはできず、ＣＯＢＯＬプログラムについても移行後の第２ＴＰモニタ２３０に合わせて書き換える必要がある。
【００６６】
そこで本実施の形態３では、汎用機環境におけるＣＯＢＯＬプログラム１５０をできる限りそのまま用いながら、ＣＯＢＯＬプログラム１５０と第２ＴＰモニタ２３０の間で受け渡しすべきパラメータを補完する手法を提供する。
【００６７】
図８は、本実施の形態３に係るトランザクション管理システム３０００の構成を示す図である。トランザクション管理システム３０００は、実施の形態２の図４（ｃ）で説明した構成に加え、送信管理領域展開モジュール３７０、送信管理領域３８０を備える。その他の構成は、実施の形態２と同様である。
【００６８】
送信管理領域展開モジュール３７０は、ＣＯＢＯＬプログラム１５０に代わって、ＣＯＢＯＬプログラム１５０の実行結果を送信すべき宛先を、第１トランザクションＩＤの値をもって指定する。送信管理領域展開モジュール３７０は、プログラムモジュールとして構成されており、第１トランザクションＩＤを送信管理領域３８０に書き込む。送信管理領域展開モジュール３７０は、ＣＯＢＯＬプログラム１５０毎にあらかじめ作成しておくものとする。すなわち、第１トランザクションＩＤは、送信管理領域展開モジュール３７０内に固定的に埋め込まれており、送信管理領域展開モジュール３７０を実行するのみで第１トランザクションＩＤが送信管理領域３８０に書き込まれる。
【００６９】
送信管理領域３８０は、送信管理領域展開モジュール３７０によってサーバ２２０のメモリ上に構成される記憶領域である。
【００７０】
なお、ＣＯＢＯＬプログラム１５０がアプリケーションロジックを実行する前に送信管理領域展開モジュール３７０を呼び出すため、トランザクション管理プログラム３１０のインタフェースを呼び出す部分よりも前に、送信管理領域展開モジュール３７０を呼び出す処理を、あらかじめＣＯＢＯＬプログラム１５０内に埋め込んでおくものとする。
【００７１】
図９は、本実施形態３に係るトランザクション管理システム３０００の動作シーケンスを説明する図である。以下、図９の各ステップについて説明する。なお、記載の都合上、一部の構成要素およびステップは省略した。
【００７２】
（図９：ステップＳ９０１〜Ｓ９０２）
これらのステップは、図６のステップＳ６０１〜Ｓ６０２と同様である。
（図９：ステップＳ９０３）
トランザクション管理プログラム３１０は、第２トランザクションＩＤ３６３をキーにして宛先定義データ３６０を照会し、呼び出すべきＣＯＢＯＬプログラム１５０の名称をプログラム名３６４から取得して特定する。
【００７３】
（図９：ステップＳ９０４）
トランザクション管理プログラム３１０は、新たなトランザクションを起動し、ＣＯＢＯＬプログラム１５０を呼び出す。ＣＯＢＯＬプログラム１５０は、自身の実行結果を戻すのみであるため、ＣＯＢＯＬプログラム１５０を呼び出す際に第１トランザクションＩＤを指定する必要はない。
（図９：ステップＳ９０５〜Ｓ９０６）
ＣＯＢＯＬプログラム１５０は、アプリケーションロジックを実行する前に、送信管理領域展開モジュール３７０を呼び出す。送信管理領域展開モジュール３７０は、送信管理領域３８０に第１トランザクションＩＤの値を書き込む。
【００７４】
（図９：ステップＳ９０７）
ＣＯＢＯＬプログラム１５０は、自身が規定するアプリケーション処理を実行し、トランザクション管理プログラム３１０を呼び出すインタフェースを介して、トランザクション管理プログラム３１０に実行結果を戻す。
（図９：ステップＳ９０８）
トランザクション管理プログラム３１０は、送信管理領域３８０に書き込まれている第１トランザクションＩＤの値を取得する。
【００７５】
（図９：ステップＳ９０９）
トランザクション管理プログラム３１０は、送信管理領域３８０から取得した第１トランザクションＩＤをキーにして宛先定義データ３６０を照会し、対応する第２トランザクションＩＤを取得する。また、呼び出すべきクライアント端末２１０の種別と、必要に応じてそのアドレスを、宛先種別３６２から取得して特定する。
（図９：ステップＳ９１０〜Ｓ９１１）
これらのステップは、図３のステップＳ３０５〜Ｓ３０７と同様である。トランザクションＩＤには、第２ＴＰモニタ２３０配下で用いられる第２トランザクションＩＤが指定される。
【００７６】
＜実施の形態３：まとめ＞
以上のように、本実施の形態３によれば、送信管理領域展開モジュール３７０は、個々のＣＯＢＯＬプログラム１５０に対応する第１トランザクションＩＤを送信管理領域３８０に書き込む。トランザクション管理プログラム３１０は、送信管理領域３８０からＣＯＢＯＬプログラム１５０に対応する第１トランザクションＩＤを取得する。これにより、ＣＯＢＯＬプログラム１５０は自身の実行結果のみをトランザクション管理プログラム３１０に戻せばよいので、クライアント端末２１０との間の手続きについて関与する必要はない。したがって、第２ＴＰモニタ２３０に合わせてＣＯＢＯＬプログラム１５０を書き換える必要はない。
【００７７】
＜実施の形態４＞
本発明の実施の形態４では、ＣＯＢＯＬプログラム１５０内で新たなトランザクションを起動する動作例について説明する。その他の構成は、プリンタ２６０が新たに設けられている点を除いて、実施の形態１〜３いずれかと同様である。以下の説明では、実施の形態２の構成を採用した環境を想定する。
【００７８】
図１０は、本実施形態４に係るトランザクション管理システム３０００の動作シーケンスを説明する図である。以下、図１０の各ステップについて説明する。なお、記載の都合上、一部の構成要素およびステップは省略した。
【００７９】
（図１０：ステップＳ１００１〜Ｓ１００４）
これらのステップは、図６のステップＳ６０１〜Ｓ６０４と同様である。
（図１０：ステップＳ１００５）
ＣＯＢＯＬプログラム１５０は、プリンタ２６０に対して印刷ジョブを依頼する新たなトランザクションを起動する。このときＣＯＢＯＬプログラム１５０が指定するトランザクションＩＤを、第３トランザクションＩＤとする。
【００８０】
（図１０：ステップＳ１００６）
トランザクション管理プログラム３１０は、新たなトランザクションを起動し、印刷ジョブを実行するＣＯＢＯＬプログラム１５１を呼び出す。このとき指定するトランザクションＩＤは、ステップＳ１００５で指定された第３トランザクションＩＤである。
（図１０：ステップＳ１００６：補足）
本ステップおよび図１０では、記載の簡易の観点から、トランザクション管理プログラム３１０内で新たなトランザクションの管理を完結することとしたが、第２ＴＰモニタ２３０までいったん処理を戻し、第２ＴＰモニタ２３０の配下で新たなトランザクションを管理するようにしてもよい。
【００８１】
（図１０：ステップＳ１００７）
トランザクション管理プログラム３１０は、第３トランザクションＩＤをキーにして宛先定義データ３６０を照会し、呼び出すべきＣＯＢＯＬプログラム１５１の名称を取得して特定する。
（図１０：ステップＳ１００８〜Ｓ１００９）
トランザクション管理プログラム３１０は、ＣＯＢＯＬプログラム１５１を呼び出して実行する。ＣＯＢＯＬプログラム１５１は、プリンタ２６０に対して印刷ジョブを依頼する。ＣＯＢＯＬプログラム１５１は、印刷ジョブが完了した後、その結果をトランザクション管理プログラム３１０経由でＣＯＢＯＬプログラム１５０に戻してもよい。また、ＣＯＢＯＬプログラム１５１は、プリンタ２６０に対して印刷ジョブを依頼する処理を、トランザクション管理プログラム３１０を介する新たなトランザクションとして実行してもよい。
（図１０：ステップＳ１０１０〜Ｓ１０１３）
これらのステップは、図６のステップＳ６０５〜Ｓ６０９と同様である。
【００８２】
＜実施の形態４：まとめ＞
以上、本実施の形態４では、ＣＯＢＯＬプログラム１５０から新たなトランザクションを起動する例を説明した。この場合でも、トランザクション管理プログラム３１０の配下で各トランザクションを管理することにより、実施の形態１〜３と同様に、第１ＴＰモニタ１３０配下で動作するＣＯＢＯＬプログラムを、第２ＴＰモニタ２３０配下で動作させることができる。
【００８３】
＜実施の形態５＞
本発明の実施の形態５では、第１ＴＰモニタ１３０と第２ＴＰモニタ２３０がそれぞれ内部的に用いるデータマップについて説明する。データマップとは、例えばクライアント端末上の画面の構成要素とトランザクション内部の各パラメータとの対応関係を記述した対応テーブルのことである。
【００８４】
トランザクションモニタが異なると、データマップの形式も異なる場合がある。そこで本実施の形態５では、これらの差異を吸収するデータマップ変換モジュール３９０を新たに導入する。その他の構成は、実施の形態１〜４いずれかと同様である。以下では説明の簡易のため、実施の形態１で説明した構成を前提とする。
【００８５】
図１１は、本実施の形態５に係るトランザクション管理システム３０００の構成を示す図である。トランザクション管理システム３０００は、実施の形態１の図２で説明した構成に加え、データマップ変換モジュール３９０、データマップ変換モジュール生成プログラム４２０を備える。その他の構成は、実施の形態１と同様である。
【００８６】
図１１（ａ）において、移行前の汎用機環境におけるトランザクション管理システム１０００は、第１ＴＰモニタ１３０の配下に第１データマップ１３１を備える。同様に図１１（ｃ）において、移行後の本実施形態５に係るトランザクション管理システム３０００は、第２ＴＰモニタ２３０の配下に第２データマップ２３１を備える。
【００８７】
データマップ変換モジュール３９０は、第１データマップ１３１のデータ形式と第２データマップ２３１のデータ形式を相互に変換するプログラムモジュールである。データマップ変換モジュール生成プログラム４２０は、第１データマップ１３１またはそのデータ形式を定義するデータの記述に基づき、データマップ変換モジュール３９０を生成する。
【００８８】
トランザクション管理プログラム３１０は、第２ＴＰモニタ２３０から第２データマップ２３１のデータ形式を前提としたリクエストを受け取ると、データマップの形式を第１データマップ１３１のデータ形式に変換するよう、データマップ変換モジュール３９０に依頼する。同様に、ＣＯＢＯＬプログラム１５０から第１データマップ１３１のデータ形式を前提としたリクエストを受け取ると、データマップの形式を第２データマップ２３１のデータ形式に変換するよう、データマップ変換モジュール３９０に依頼する。
【００８９】
＜実施の形態５：まとめ＞
以上のように、本実施の形態５によれば、各トランザクションモニタが用いるデータマップの形式が異なっていても、データマップ変換モジュール３９０が都度データ形式を変換するので、移行後の第２ＴＰモニタ２３０が用いる第２データマップ２３１のデータ形式に合わせてＣＯＢＯＬプログラム１５０を書き換える必要はない。
【００９０】
＜実施の形態６＞
図１２は、本発明の実施の形態６に係るトランザクション管理システム３０００の周辺環境を示す図である。本実施形態６では、実施の形態１〜５で説明した構成に加え、ＣＯＢＯＬプログラム１５０を変換するＣＯＢＯＬソースコード変換プログラム４３０を新たに設けた。その他の構成は、実施の形態１〜５と同様であるため、記載を省略した。
【００９１】
図１２の上段に記載しているＣＯＢＯＬプログラム１５０は、変換前のソースコードである。ＣＯＢＯＬソースコード変換プログラム４３０は、ＴＰモニタインタフェース１６０をコールする部分を、ＣＯＢＯＬソーストランザクション管理プログラム３１０をコールするように書き換える。またプログラムの実行開始位置に、送信管理領域展開モジュール３７０をコールする部分を追加する。
【００９２】
図１２の下線部分は、ＣＯＢＯＬソースコード変換プログラム４３０が書き換えた部分である。必ずしもトランザクション管理プログラム３１０や送信管理領域展開モジュール３７０を直接コールする必要はなく、別の外部ＣＯＢＯＬモジュールを介して間接的にこれらプログラムをコールするようにしてもよい。この外部ＣＯＢＯＬモジュールは、いずれかのプログラムが適宜生成すればよい。
【００９３】
なお、トランザクション管理プログラム３１０や送信管理領域展開モジュール３７０が、例えばＣ言語のように関数引数の数が関数作成時に固定されるプログラム言語によって作成されている場合も考えられる。この場合は、トランザクション管理プログラム３１０や送信管理領域展開モジュール３７０に引き渡す引数を任意個数に設定できるように、引数そのものは構造体などのデータ集合体に詰め込み、このデータ集合体のみを引き渡すようにするとよい。これにより、引数の固有による制約を受けることはなくなる。ただし、データ構造体に含まれる引数個数を指定する変数を追加するなど、個別の工夫は必要となる。図１２下段の引数「ＰｒｍＣｏｕｎｔ」は、そのための引数である。
【００９４】
トランザクション管理プログラム３１０と送信管理領域展開モジュール３７０は、変換後のＣＯＢＯＬプログラム１５０または外部ＣＯＢＯＬモジュールから呼び出すためのインタフェースを内部的に備える。サーバ２２０は、ＣＯＢＯＬプログラム１５０を実行する過程で、その内部インタフェースを呼び出すことにより、トランザクション管理プログラム３１０と送信管理領域展開モジュール３７０を呼び出す。
【００９５】
以上、本実施の形態６では、ＴＰモニタインタフェース１６０を呼び出す部分を、トランザクション管理プログラム３１０と送信管理領域展開モジュール３７０を呼び出すように、ＣＯＢＯＬプログラム１５０を自動的に変換する例を説明した。
【符号の説明】
【００９６】
１１０：クライアント端末、１２０：汎用機、１３０：第１ＴＰモニタ、１４０：通信セッションデータベース、１５０および１５１：ＣＯＢＯＬプログラム、１６０：ＴＰモニタインタフェース、１７０：資源定義データ、１０００：トランザクション管理システム、２１０：クライアント端末、２２０：サーバ、２３０：第２ＴＰモニタ、２４０：通信セッションデータベース、２５０：ＣＯＢＯＬプログラム、２６０：プリンタ、２０００：トランザクション管理システム、３１０：トランザクション管理プログラム、３４０：通信セッションデータベース、３６０：宛先定義データ、３７０：送信管理領域展開モジュール、３８０：送信管理領域、３９０：データマップ変換モジュール、４１０：宛先定義生成プログラム、４２０：データマップ変換モジュール生成プログラム、４３０：ＣＯＢＯＬソースコード変換プログラム、３０００：トランザクション管理システム。
【図１】
2015038641.tif 000003
【図２】
2015038641.tif 000004
【図３】
2015038641.tif 000005
【図４】
2015038641.tif 000006
【図５】
2015038641.tif 000007
【図６】
2015038641.tif 000008
【図７】
2015038641.tif 000009
【図８】
2015038641.tif 000010
【図９】
2015038641.tif 000011
【図１０】
2015038641.tif 000012
【図１１】
2015038641.tif 000013
【図１２】
2015038641.tif 000014