(57)【要約】【目的】メインフレームのアプリケーション資産を生かしてオープン環境に移行できるシステムを提供する。【構成】メインフレーム用アプリケーションをクライアントで利用する際にクライアントの画面に表示されるフィールドを定義するメインフレーム毎のメインフレーム用画面定義体に基づいて、クライアントの画面に表示されるフィールドの配置などの画面構成情報を複数のメインフレームに対応可能な汎用画面フォームとして作成する手段と、メインフレーム用画面定義体に基づいて、クライアントの画面に表示されるフィールドの属性を複数のメインフレームに対応可能な汎用画面データとして作成する手段と、汎用画面フォームと汎用画面データとを融合してクライアントの入力画面を作成して汎用的通信規格を介してクライアントに送信する手段と、をサーバに備えたコンピュータネットワークシステムである。【選択図】図２
2004355413.tif 000002
【特許請求の範囲】
【請求項１】
ＴＣＰ／ＩＰなどの汎用的な通信規格でサーバに多数のクライアントが接続されたコンピュータネットワークシステムであるクライアント・サーバ・システムにおいて、
サーバは、
サーバ側で実行される特定のサーバ・アプリケーションをクライアント側で入力操作する際にクライアントの画面に表示されるフィールドの配置などの一連の画面構成情報を複数のメインフレームに対応可能な汎用画面フォームとして保存する記憶手段と、
上記汎用画面フォームをクライアントからの要求に応答してクライアントに送信する汎用画面フォーム送信手段と、
クライアントから特定の処理を要求する画面データを受信したときに、該画面データを対応するサーバ・アプリケーションで処理可能な画面データに変換する第１の画面データ変換手段と、
第１の画面データ変換手段による変換後の画面データをサーバ・アプリケーションで処理させる画面データ処理手段と、
サーバ・アプリケーションで処理した結果としての画面データをクライアントの画面に表示可能な次画面表示用データに変換する第２の画面データ変換手段と、
第２の画面データ変換手段による変換後の次画面表示用データをクライアントに送信する次画面表示用データ送信手段と、を備えてなることを特徴とするコンピュータネットワークシステムにおけるメインフレームのオープン化システム。
【請求項２】
サーバ・アプリケーションで処理した結果としての次画面表示用データには、汎用画面フォームにおいて次画面の画面構成情報を指定する画面フォームＩＤと、該画面フォームにおける各フィールドに表示すべきデータとが含まれることを特徴とする、請求項１に記載のメインフレームのオープン化システム。
【請求項３】
前記記憶手段は、特定のサーバ・アプリケーションについて常に最新の一連の画面構成情報を保存することを特徴とする、請求項１に記載のメインフレームのオープン化システム。
【請求項４】
クライアントからの端末エミュレータ起動要求を受けて、クライアントに保存されている汎用画面フォームがサーバの記憶手段に保存されている最新の汎用画面フォームと同一であるか否かを判断するバージョン判定手段を含み、前記汎用画面フォーム送信手段は、バージョン判定手段が、クライアントに保存されている汎用画面フォームが最新バージョンではないと判定したときに、サーバの記憶手段に保存されている最新の汎用画面フォームをクライアントに送信することを特徴とする、請求項１に記載のメインフレームのオープン化システム。
【請求項５】
ＴＣＰ／ＩＰなどの汎用的な通信規格でサーバに多数のクライアントが接続されたコンピュータネットワークシステムであるクライアント・サーバ・システムにおいて、
クライアントは、
サーバ側で実行される特定のサーバ・アプリケーションをクライアント側で入力操作する際にクライアントの画面に表示されるフィールドの配置などの一連の画面構成情報をサーバからダウンロードして保存する画面フォーム保存手段と、
サーバ・アプリケーションの実行においてクライアント側での入力操作のためにクライアントの次画面として表示すべき次画面表示用データをサーバから取得する次画面表示用データ取得手段と、
上記次画面表示用データ取得手段により取得した次画面表示用データを上記画面フォーム保存手段に保存されている該次画面用の画面構成情報である画面フォームに融合してクライアントの画面に表示させるクライアント画面表示制御手段と、
上記クライアント画面表示制御手段により制御されたクライアントの表示画面において特定の入力操作があったときに、該入力操作によって指定された特定のコマンドをサーバに送信してサーバ・アプリケーション上での処理を要求する処理要求手段と、を備えてなることを特徴とするコンピュータネットワークシステムにおけるメインフレームのオープン化システム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
この発明はコンピュータネットワークシステムに関し、より詳しくは、メインフレームのアプリケーション資産とＤＢ（データベース）機能・ＤＣ（データコミュニケーション）機能を汎用性の高いオープン環境に移行して実行するメインフレームのオープン化システムに関する。
【０００２】
【従来の技術】
企業の基幹業務システムなどに用いられる汎用大型コンピュータであるメインフレームは、図１に模式的に示されるように、データベース１２などの情報資源やそれを操作するアプリケーション１４を集中管理するコンピュータであるサーバ１０に、サーバ１０のアプリケーション１４を操作・利用するコンピュータである多数の端末クライアント３０が接続されて構成されるクライアント・サーバ・システムである。
【０００３】
メインフレームのサーバ１０は、
（Ａ）情報資源の管理において高い信頼性と、
（Ｂ）これまでの長年に渡って蓄積されたビジネス・ロジックを持ち、
（Ｃ）短いレスポンス・タイムによって高速なオンライン処理を実現し、
（Ｄ）高速多重のバッチ処理を実現している。
【０００４】
これらの優位性から、企業の基幹業務システム、例えば、銀行の勘定系システムなどの、ミッション・クリティカルな分野で実績をあげている。
【０００５】
また、端末クライアント３０は、
（Ａ）そのユーザが操作する画面インターフェースは簡素かつ明快であり、
（Ｂ）一連の入力画面が、ストーリー性を持って、順番に表示され、
（Ｃ）マウス等を使用しない、キーボードだけの入力操作が可能であり、
（Ｄ）Ｅｎｔｅｒキー、ファンクション・キーであるＰＦキー、実行キーを使用した効率的な入力操作が可能であるという特長を持っている。
【０００６】
このクライアント・サーバ・システムの優れた機能としては、
（Ａ）データベース処理において、クライアント操作との関連性も考慮した上での、その一貫性を保持するための同期処理と、
（Ｂ）クライアント操作からアプリケーションの実行、データベースへのアクセス、クライアントへの結果表示に至るトランザクションの確立、
（Ｃ）端末監視、
（Ｄ）通信セキュリティ、
（Ｅ）端末毎に一意の識別番号を割り振るＬＵ（Ｌｏｇｉｃａｌ  Ｕｎｉｔ）設定、
（Ｆ）ＤＣ監視機能、
等が挙げられる。
【０００７】
従来のメインフレーム環境では、サーバ１０に設けられた画面処理手段１８がメインフレーム用の画面定義体を備えており、この画面定義体により端末クライアントでのアプリケーション操作（データ入力等）を可能にするための画面処理を実行している。つまり、画面定義体とは、端末クライアントの画面上に表示される複数のフィールドが定義されている定義体のことである。
【０００８】
【発明が解決しようとする課題】
従来のメインフレーム環境では、そのベンダーが独自に調達した、ハードウェアやソフトウェアの一式で構築されるコンピュータ・システムが使われていた。
【０００９】
つまり、メインフレームはシングルベンダー環境であるため、必然的にメーカーへの依存度が高くなるとともに、原則として、直接ワイヤー接続された端末かそれを少し拡張した程度の限られた範囲でしか、サービス提供することができない。
【００１０】
また、メインフレームで扱われる言語はＣＯＢＯＬが主流であるが、既にコンピュータ技術者の汎用言語はＣＯＢＯＬから他の言語、特にＪａｖａ（登録商標、以下同じ）に移行しているため、現在稼働中のメインフレーム資産のメンテナンス要員を確保することが困難である。
【００１１】
また、メインフレームは基本的にはＷｅｂサービスに対応していないため、インターネットを介した既存ビジネス機能の統合や新規ビジネスの創出が原則として不可能であり、各種通信（同期、非同期）方法や他社システムとの連携も困難である。
【００１２】
また、コンピュータハードウェア自体の価格性能比差はかなり縮まってきているが、依然としてメインフレーム上で稼働するメーカー独自提供の基本的なソフトウェア（ＯＳやミドルウエア）のコストは高く、大型の構成であれば数億円またはそれ以上のレベルになる。ハードウェアと基本的なソフトウェアのコストがほぼ同額になってしまうことも珍しくない。
【００１３】
また、コストの問題だけでなく、メインフレーム上で稼働する基本的なソフトウェアが質的に不足しており、主流のＵＮＩＸ（登録商標）サーバやＷｉｎｄｏｗｓ（登録商標）２０００／ＮＴサーバとは大きな格差がある。ソフトのコストは、出荷台数が多く開発コストを多くのライセンスで回収できるＯＳが有利であることから、このようなメインフレームの基本的なソフトウェア上の課題は簡単には解消されず、むしろより顕在化する傾向にあるものと予測される。
【００１４】
すなわち、メインフレームを使ったシステムは信頼性が高いのが長所であるが、反面、柔軟性に欠け、また開発・運用コストが高いという短所を併せ持っている。
【００１５】
【課題を解決するための手段】
そこで本発明は、メインフレームのアプリケーション資産と、データの入力・更新・検索などの手順を提供および情報の集中管理を実現するＤＢ（データベース）機能およびアプリケーションがサーバにあり、クライアントには画面インターフェースがあるだけであるメインフレームの中で多数のクライアントやその画面を管理する仕組であるＤＣ（データコミュニケーション）機能を、様々なメーカーのソフトウェアやハードウェアを組み合わせて構築されているコンピュータ・システムであり、そのメーカー各社がＯＳやアプリケーション・ソフトの外部仕様を公開することで実現されていて、価格や性能を比べてもっとも良い製品を組み合わせることができるというメリットがあるオープン環境に移行するためのソリューションを提供することを目的とする。
【００１６】
この目的を達成するため、本発明では、アプリケーション資産の言語をＪａｖａ化する。Ｊａｖａは、基本的にはどのようなプラットフォームでも動作する汎用性と、プログラムのより進んだモジュール化とモジュールの再利用性を高めるオブジェクト指向性と、強力なセキュリティ機構や豊富なネットワーク関連の機能を標準で搭載した言語であることから、アプリケーションの使用言語を、従来のメインフレームのアプリケーション構築用言語からＪａｖａに置き換える。この使用言語の置き換えの際には、ＤＢとＤＣの機能を構築するための独自の手法を使用して、短期間、低コストで行う。
【００１７】
また、ネットワーク・インタフェースも自動的に、Ｗｅｂサービス化する。つまり、従来のメインフレームのソフトウェアの機能を、インターネットを通じて、Ｗｅｂサービスに準拠しているクライアントからであれば、世界中どこからでも利用できるようにする。
【００１８】
本発明によるメインフレームのオープン化システムは、
（Ａ）メインフレームのＤＣミドル・ウェア上で動作するＤＢ・ＤＣコントローラの機能を、Ｊａｖａアプリケーション・サーバとその上で動作するＤＢ・ＤＣインターフェースで実現可能にし、また、Ｗｅｂサービス・インターフェース機能の提供によりクライアント接続のインターフェースが自動的にＷｅｂサービスのインターフェースを持つようになる手法と、
（Ｂ）メインフレームのＤＢ・ＤＣコントローラと連携動作するメインフレーム・アプリケーションを、上記ＤＢ・ＤＣインターフェースと連携動作するサーバ・アプリケーションに移行する手法と、
の２つの手法を採用する。
【００１９】
これらの手法によって、
（ア）上記手法（Ｂ）により  メインフレーム上で培われたアプリケーションであるビジネス・ロジックを、短期間、低コストで継承することができ、
（イ）メインフレームの端末側の、従来の画面表示と操作性  （インターフェース）  を継承しているため、従来のユーザの負担を増大させることがなく、
（ウ）メインフレームでは、原則直接ワイヤー接続された端末かそれを少し拡張した程度の限られた範囲でしか、サービス提供できなかったが、上記の手法（Ａ）のＷｅｂサービス・インターフェース機能により、場所や端末の種類に関わらず、広範囲にサービス提供ができ、
（エ）通常のオープン環境では困難な、メインフレームの主だった機能である、同期処理、トランザクション、端末監視、通信セキュリティ、ＬＵ設定、ＤＣ監視を実現できる。
【００２０】
すなわち、請求項１に係る本発明は、ＴＣＰ／ＩＰなどの汎用的な通信規格でサーバに多数のクライアントが接続されたコンピュータネットワークシステムであるクライアント・サーバ・システムにおいて、サーバは、サーバ側で実行される特定のサーバ・アプリケーションをクライアント側で入力操作する際にクライアントの画面に表示されるフィールドの配置などの一連の画面構成情報を複数のメインフレームに対応可能な汎用画面フォームとして保存する記憶手段と、上記汎用画面フォームをクライアントからの要求に応答してクライアントに送信する汎用画面フォーム送信手段と、クライアントから特定の処理を要求する画面データを受信したときに、該画面データを対応するサーバ・アプリケーションで処理可能な画面データに変換する第１の画面データ変換手段と、第１の画面データ変換手段による変換後の画面データをサーバ・アプリケーションで処理させる画面データ処理手段と、サーバ・アプリケーションで処理した結果としての画面データをクライアントの画面に表示可能な次画面表示用データに変換する第２の画面データ変換手段と、第２の画面データ変換手段による変換後の次画面表示用データをクライアントに送信する次画面表示用データ送信手段と、を備えてなることを特徴とするメインフレームのオープン化システムである。
【００２１】
請求項２に係る本発明は、請求項１記載のメインフレームのオープン化システムにおいて、サーバ・アプリケーションで処理した結果としての次画面表示用データには、汎用画面フォームにおいて次画面の画面構成情報を指定する画面フォームＩＤと、該画面フォームにおける各フィールドに表示すべきデータとが含まれることを特徴とする。
【００２２】
請求項３に係る本発明は、請求項１記載のメインフレームのオープン化システムにおいて、記憶手段が、特定のサーバ・アプリケーションについて常に最新の一連の画面構成情報を保存することを特徴とする。
【００２３】
請求項４に係る本発明は、請求項１記載のメインフレームのオープン化システムにおいて、クライアントからの端末エミュレータ起動要求を受けて、クライアントに保存されている汎用画面フォームがサーバの記憶手段に保存されている最新の汎用画面フォームと同一であるか否かを判断するバージョン判定手段を含み、前記汎用画面フォーム送信手段は、バージョン判定手段が、クライアントに保存されている汎用画面フォームが最新バージョンではないと判定したときに、サーバの記憶手段に保存されている最新の汎用画面フォームをクライアントに送信することを特徴とする。
【００２４】
請求項５に係る本発明は、ＴＣＰ／ＩＰなどの汎用的な通信規格でサーバに多数のクライアントが接続されたコンピュータネットワークシステムであるクライアント・サーバ・システムにおいて、クライアントは、サーバ側で実行される特定のサーバ・アプリケーションをクライアント側で入力操作する際にクライアントの画面に表示されるフィールドの配置などの一連の画面構成情報をサーバからダウンロードして保存する画面フォーム保存手段と、サーバ・アプリケーションの実行においてクライアント側での入力操作のためにクライアントの次画面として表示すべき次画面表示用データをサーバから取得する次画面表示用データ取得手段と、上記次画面表示用データ取得手段により取得した次画面表示用データを上記画面フォーム保存手段に保存されている該次画面用の画面構成情報である画面フォームに融合してクライアントの画面に表示させるクライアント画面表示制御手段と、上記クライアント画面表示制御手段により制御されたクライアントの表示画面において特定の入力操作があったときに、該入力操作によって指定された特定のコマンドをサーバに送信してサーバ・アプリケーション上での処理を要求する処理要求手段と、を備えてなることを特徴とするメインフレームのオープン化システムである。
【００２５】
本発明システムによって実現されるオープン環境では、様々なメーカーのソフトウェアやハードウェアを組み合わせて構築されているコンピュータ・システムが使われる。
【００２６】
処理システムという観点からみると、オープン環境は、ＴＣＰ／ＩＰなどの汎用的な通信規格でサーバに多数のクライアントが接続されたコンピュータ・ネットワーク・システムである、クライアント・サーバ・システムで構成される。
【００２７】
近年のオープン環境システムでは、アプリケーション・ソフトを構成するための言語としてＪａｖａを使用することが多い。したがって、本発明システムのサーバ側の各機能は、Ｊａｖａを基調としたものになっている。本発明システム全体として、ネットワーク関連の機能を標準で搭載しているＪａｖａと親和性の高い、ＷＷＷ（Ｗｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂ）関連の技術を利用したものになっている。ＷＷＷは、インターネットやイントラネットで標準的に用いられるシステムである。
【００２８】
このことによって、従来のメインフレームではサービス利用可能範囲は小さく限定されていたが、本発明システムでは、インターネットなどのネットワーク環境が整ってさえいれば、サービス利用可能範囲は格段に拡大されることになる。
【００２９】
また、サーバとクライアントの接続形態については、メインフレームでは、基本的には１台のサーバとｎ台のクライアントがｎ本の線で直結して接続されている形態で端末識別設定を行っていたが、新しいオープン環境は、通常のオープン環境のように物理的には入り乱れたネットワークで構成されているにもかかわらず、端末識別設定によって論理的にはサーバ・クライアント間が直結して接続されているかのような形態になっている。
【００３０】
【発明の実施の形態】
本発明によるメインフレームのオープン化システムの好適な実施形態について、以下、図２および図３を参照して説明する。
【００３１】
本システムのクライアント・サーバ・システム上では、主に、
（Ａ）関連する一連のデータの入出力項目を画面上に表示する際の画面構成と、その画面上の各入力項目とその属性を表す画面定義体と、
（Ｂ）ＷＷＷ関連の技術を利用した、クライアントからサーバへデータ処理を要求する場合等の遠隔地へアクセス可能な、プログラマブルなフォーマットと、
が複合的に使われている。
【００３２】
本システムのサーバ１００には、その土台として、Ｊａｖａアプリケーション・サーバ１０２を使用している。このＪａｖａアプリケーション・サーバ１０２は、企業の業務システムや電子商取引などで使われるサーバに必要な機能をまとめたものであり、かつ、標準化されたインターフェース、再利用可能なコンポーネント、最新のＷｅｂテクノロジーなどの機能を持つ。
【００３３】
サーバ１００内の他の機能との関係について言えば、Ｊａｖａアプリケーション・サーバ１０２は、Ｊａｖａウェブ・スタート・サーバ１０４およびＷｅｂサービス・サーバ１１２と協調関係にあり、これらＪａｖａウェブ・スタート・サーバ１０４およびＷｅｂサービス・サーバ１１２のネットワーク層の通信制御処理を担当している。具体的には、クライアント１５０とＪａｖａウェブ・スタート・サーバ１０４およびＷｅｂサービス・サーバ１１２間の通信の際、Ｊａｖａアプリケーション・サーバ１０２は、その間を中継し、その通信の開始から終了までを管理する役割を担っている。
【００３４】
また、サーバ１００内の汎用インターフェース１１４、メインフレームのＤＣインターフェース１２２およびサーバ・アプリケーション１２４は、Ｊａｖａアプリケーション・サーバ１０２の配下で動作する。換言すると、Ｊａｖａアプリケーション・サーバ１０２は、汎用インターフェース１１４、メインフレームのＤＣインターフェース１２２およびサーバ・アプリケーション１２４の実行環境を提供する役割を担っている。
【００３５】
そして、サーバ・アプリケーション１２４が必要とするＤＢ１１８は、このＪａｖａアプリケーション・サーバ１０２を通してやり取りされる。
【００３６】
ＤＢ・ＤＣを管理、監視するマネージャー１２０も、このＪａｖａアプリケーション・サーバ１０２を通してやり取りされる。
【００３７】
なお、図２の「普通のＪａｖａ」１２５は、メインフレームから移植されたサーバ・アプリケーションではなく、新規に作成されたＪａｖａアプリケーションであり、サービスの拡充のために設けられているのが重要な点となっている。この「普通のＪａｖａ」１２５は、Ｊａｖａアプリケーション・サーバ１０２の配下で動作し、汎用画面データを取り扱うため、メインフレームのＤＣインターフェース１２２を介することなく、クライアント１５０に新規のサービスをすることが可能となっている。
【００３８】
また、Ｊａｖａアプリケーション・サーバ１０２とその配下で動作する汎用インターフェース１１４、メインフレームのＤＣインターフェース１２２、サーバ・アプリケーション１２４およびマネージャー１２０間のデータのやり取りは、イベント駆動形式で行われる。イベント駆動形式とは、一般的には、ユーザや他のプログラムが実行した操作（イベント）に対応して逐一処理を行う、プログラムの実行形式のことをいう。本システム上では、サーバ１００上のある機能が、他の機能から受信したデータであるメッセージがあることの通知によって呼び起こされ、そのメッセージを受信し、それに対応した処理を行った後、次のメッセージの通知があるまで待機する形式である。
【００３９】
Ｊａｖａウェブ・スタート・サーバ１０４について更に詳しく説明する。Ｊａｖａウェブ・スタートとは、Ｗｅｂを利用して、Ｊａｖａウェブ・スタート・サーバ１０４の記憶装置１０６に置いている端末エミュレータ実行ファイル１０８をクライアント１５０に配布する仕組みである。しかも、その端末エミュレータ実行ファイル１０８をクライアント１５０上の端末エミュレータ実行ファイル１５７としての保存する処理や端末エミュレータ実行ファイル１５７のバージョン更新等が自動的に行われるようになっている。
【００４０】
本システムのＪａｖａウェブ・スタート・サーバ１０４は、その記憶装置１０６に、端末エミュレータ実行ファイル１０８および端末エミュレータ上で使用される汎用画面フォーム１１０のそれぞれの最新版を保存している。
【００４１】
本システムのクライアント１５０において、端末エミュレータ１５６の初回起動の際には、Ｗｅｂブラウザ１５２上でＪａｖａウェブ・スタート・サーバ１０４へのリンクをクリックすることにより、端末エミュレータ起動要求をＪａｖａウェブ・スタート・サーバ１０４に送信する。これを受けたＪａｖａウェブ・スタート・サーバ１０４は、Ｊａｖａウェブ・スタート・クライアント１５４が端末エミュレータ１５６を起動するために必要な情報を記載したファイル（端末エミュレータ起動用ファイル）をＷｅｂブラウザ１５２に送信する。Ｗｅｂブラウザ１５２は、端末エミュレータ起動用ファイルに関連付けられたＪａｖａウェブ・スタート・クライアント１５４を自動的に起動し、受信した端末エミュレータ起動用ファイルを手渡す。Ｊａｖａウェブ・スタート・クライアント１５４は、手渡された端末エミュレータ起動用ファイルの記載内容に基づいて、端末エミュレータ１５６を起動するために必要となる最新版の端末エミュレータ実行ファイル１０８と汎用画面フォーム１１０のそれぞれのダウンロード要求をＪａｖａウェブ・スタート・サーバ１０４に送信する。そのダウンロード要求を受けたＪａｖａウェブ・スタート・サーバ１０４は、サーバ側の記憶装置１０６に保存されている最新バージョンの端末エミュレータ実行ファイル１０８と汎用画面フォーム１１０のそれぞれをダウンロード要求元のＪａｖａウェブ・スタート・クライアント１５４に配信する。
【００４２】
もしくは、端末エミュレータ１５６の２回目以降の起動の際には、ウェブ・ブラウザ１５２を介する必要はなく、Ｊａｖａウェブ・スタート・クライアント１５４が持つメニュー画面上で端末エミュレータ１５６起動のための項目（この項目は、端末エミュレータ初回起動の際、Ｊａｖａウェブ・スタート・クライアント１５４が自動作成する）を選択することにより、Ｊａｖａウェブ・スタート・クライアント１５４が端末エミュレータ実行ファイル１０８と汎用画面フォーム１１０のそれぞれの更新確認要求をＪａｖａウェブ・スタート・サーバ１０４に送信する。その更新確認要求を受けたＪａｖａウェブ・スタート・サーバ１０４は、クライアント１５０側で保存している端末エミュレータ実行ファイル１５７と汎用画面フォーム１５８のそれぞれが最新バージョンであるか否かを判定する。最新バージョンではないと判断されたとき、Ｊａｖａウェブ・スタート・サーバ１０４は、サーバ側の記憶装置１０６に保存されている最新バージョンの端末エミュレータ実行ファイル１０８、もしくは汎用画面フォーム１１０を、更新確認要求元のＪａｖａウェブ・スタート・クライアント１５４に配信する。
【００４３】
このＪａｖａウェブ・スタートの機能を採用することによって、クライアント１５０は、端末エミュレータ１５６更新のためのメンテナンス作業から解放されるメリットが生まれる。
【００４４】
Ｗｅｂサービス・サーバ１１２について更に詳しく説明する。Ｗｅｂサービス・サーバ１１２は、ＷＷＷ関連の技術を使い、ソフトウェアの機能を、ネットワークを通じて利用できるようにしたものであるＷｅｂサービスを通信手段として、クライアント１５０およびＷｅｂサービス・クライアント１６０と接続可能である。
【００４５】
本システムでは、Ｗｅｂサービスには、ＳＯＡＰと呼ばれる通信規約を採用しているが、その他の通信規約のサポートも前提としている。ＳＯＡＰは、ＷＷＷ関連の技術であるＨＴＴＰ、ＦＴＰ、ＳＭＴＰといったデータ転送のための通信規約を下位通信規約として使用し、ＸＭＬなどをベースとした、他のコンピュータにあるデータやサービスを呼び出すための通信規約である。ＳＯＡＰによって外部から利用可能な、部品化されたＷｅｂベースのアプリケーション・ソフトの実行結果の提供をＷｅｂサービスと呼んでいる。
【００４６】
ＸＭＬ（ｅｘｔｅｎｓｉｂｌｅ  ｍａｒｋｕｐ  ｌａｎｇｕａｇｅ）は、文字列のキャラクタ・コード以外のさまざまな属性情報（文字のタイプ＝イタリックか、ボールドか、など＝）や組版情報、ハイパーリンク情報）などを、あらかじめ定義されたコマンド（＝タグ）として、一定の規則に従って文書中に記述していく方式の言語であり、さらに独自にタグを定義できる（自己拡張可能）という特徴を持っているため、単なる文書を「データ」として処理することを可能にしており、ＸＭＬで構築したデータベースにＷｅｂブラウザ１５２で接続して利用することも可能な言語である。
【００４７】
Ｗｅｂサービス・サーバ１１２は、クライアント１５０からのＷｅｂサービス形式のデータ中の命令を、サーバ内部の、サーバ・アプリケーション１２４などの別の機能に処理を依頼するためのソフトウェアであり、ＸＭＬをベースにしたインターフェースを提供している。
【００４８】
汎用インターフェース１１４について図３を参照して更に詳しく説明する。汎用インターフェース１１４は、Ｗｅｂサービス・インターフェース１１６、メッセンジャー１２８およびコントローラ１２６の３つの手段を総称したものである。
【００４９】
Ｗｅｂサービス・インターフェース１１６は、Ｗｅｂサービス・サーバ１１２と自動的に接続を行う。ここでやり取りされるデータは、汎用画面データ・ジェネレータ１３８が生成した汎用画面データ１５９’（図２２）をＸＭＬ形式に変換した後の汎用画面データ１５９である。
【００５０】
Ｗｅｂサービス・インターフェース１１６は、Ｗｅｂサービス・サーバ１１２／クライアント１５０，１６０が持つＷｅｂサービス・生成／解釈エンジンに読み込ませるために必要な付加情報を、Ｗｅｂサービス・サーバ１１２に手渡す場合には付け加え、Ｗｅｂサービス・サーバ１１２から受け取った場合には取り去る。
【００５１】
Ｗｅｂサービス・インターフェース１１６には、ＷＳＤＬインターフェース１３０およびＳＯＡＰインターフェース１３２が含まれている。
【００５２】
ＷＳＤＬ（Ｗｅｂ  Ｓｅｒｖｉｃｅｓ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｌａｎｇｕａｇｅ）は、Ｗｅｂサービスを記述するための、ＸＭＬをベースとした言語仕様である。それぞれのＷｅｂサービスがどのような機能を持つのか、それを利用するためにはＷｅｂサービス・クライアント機能を持つクライアント１５０、Ｗｅｂサービス・クライアント１６０がＷｅｂサービス・サーバ１１２へどのような要求をすればいいのか、などを記述する方法が定義されている。これによって、Ｗｅｂサービスの紹介をクライアント１５０、Ｗｅｂサービス・クライアント１６０へ伝達することが可能になる。
【００５３】
クライアント１５０があるトランザクション処理を依頼するためには、例えば、あるデータ処理画面（図４）において、
（ＰＦ２）指定のキーを持つデータを参照する
（ＰＦ３）処理を終了する
（ＰＦ４）メインメニューに移る
（ＰＦ７）前エントリー
（ＰＦ８）次エントリー
（ＰＦ９）追加
（ＰＦ１０）変更
（ＰＦ１１）削除
等の、「ＰＦ」というファンクション・キーに関連付けされた一連の処理項目とその処理内容をすべて含むデータを、サーバ１００側に処理を依頼するためのコマンドを伴って、１つのメッセージとしてサーバ１００に送信する。
【００５４】
ただし、その前提として、依頼先となるサーバ１００のＩＰアドレス、サーバがそのコマンドを持っていること、そのコマンドに伴うパラメータ指定方法などの、Ｗｅｂサービスの利用方法を、クライアント１５０が知っておく必要がある。そこで、ＷＳＤＬインターフェース１３０が、事前に、ＷＳＤＬの記述方法に従って、クライアント１５０にそのＷｅｂサービスの利用方法を紹介する。
【００５５】
このＷＳＤＬインターフェース１３０は、  単独の機能として、もしくは後述するメッセンジャー１２８の一部のコンポーネントとしても、動作可能である。本実施例のシステムでは単独の機能として動作している。
【００５６】
ＳＯＡＰインターフェース１３２は、Ｗｅｂサービス・サーバ１１２とクライアント１５０が自動的に接続を行う為の記述であり、クライアント・サーバ間でやり取りされるデータを中継する。
【００５７】
次にメッセンジャー１２８について詳しく説明する。コントローラ１２６側では汎用画面データ１５９’、クライアント１５０側ではＸＭＬ形式の汎用画面データ１５９が扱われるが、メッセンジャー１２８は、概して言えば、クライアント１５０とコントローラ１２６間でやり取りされるメッセージのフォーマット変換を行う。
【００５８】
図５はメッセンジャー１２８の処理の流れを示している。まず、メッセージの送信元がクライアント１５０、コントローラ１２６のどちらであるかを判定し（Ｓ０１−０１）、それぞれの場合に応じて、定義済み処理であるＤｏクライアント（Ｓ０１−０２）およびＤｏコントローラ（Ｓ０１−０３）のうち対応する処理を実行し、終了する。
【００５９】
図６は、上記のＤｏクライアント（Ｓ０１−０２）の処理の流れを示している。まず、ＸＭＬ形式のメッセージを汎用画面データに変換し（Ｓ０２−０１）、次に、変換後の汎用画面データをコントローラに送信し（Ｓ０２−０２）、終了する。
【００６０】
図７は、上記のＤｏコントローラ（Ｓ０１−０３）の処理の流れを示している。まず、汎用画面データをＸＭＬ形式に変換し（Ｓ０３−０１）、次に、これをＷＳＤＬインターフェースに送信し（Ｓ０３−０２）、終了する。
【００６１】
コントローラ１２６は、
（Ａ）メッセンジャー１２８、ＤＣイネーブラー１２２、Ｊａｖａアプリケーション・サーバ１０２間のメッセージのやり取り、
（Ｂ）複数のＤＣ機能の一元管理、
という機能を実現する。
【００６２】
図８は、コントローラ１２６が行う処理の流れを示している。まず、メッセージの送信元がメッセンジャー１２８、ＤＣイネーブラー１２２、Ｊａｖａアプリケーション・サーバ１０２のいずれであるかを判定し（Ｓ０４−０１）、それぞれの場合に応じて、定義済み処理であるＤｏメッセンジャー（Ｓ０４−０２）、ＤｏＤＣイネーブラー（Ｓ０４−０３）、ＤｏＪａｖａアプリケーション・サーバ（Ｓ０４−０４）のうち、対応する処理を実行し、終了する。
【００６３】
図９は、上記のＤｏメッセンジャー（Ｓ０４−０２）の処理の流れを示している。まず、新規のトランザクションか否かを判定し（Ｓ０５−０１）、そうであれば、定義済み処理Ｄｏ新規トランザクションを実行する（Ｓ０５−０２）。
【００６４】
コントローラ１２６は、ＤＣイネーブラー１２２が管理できる作業領域に、サーバ・アプリケーション１２４を実行するための領域を作成する。たとえば、コントローラ１２６は、ＣＩＣＳイネーブラー１２２ａが管理できる作業領域にＣＩＣＳサーバ・アプリケーション１２４ａを実行するための領域を作成する。同様に、ＩＭＳイネーブラー１２２ｂが管理できる作業領域にＩＭＳサーバ・アプリケーション１２４ｂを実行するための領域を作成し、ＤＣＣＭ３イネーブラー１２２ｃが管理できる作業領域にＤＣＣＭ３サーバ・アプリケーション１２４ｃを実行するための領域を作成し、ＡＤＭイネーブラー１２２ｄが管理できる作業領域にＡＤＭサーバ・アプリケーション１２４ｄを実行するための領域を作成し、ＡＩＭイネーブラー１２２ｅが管理できる作業領域にＡＩＭサーバ・アプリケーション１２４ｅを実行するための領域を作成し、ＡＩＭ／ＡＣＳイネーブラー１２２ｆが管理できる作業領域にＡＩＭ／ＡＣＳサーバ・アプリケーション１２４ｆを実行するための領域を作成し、Ｎａｔｕｒａｌイネーブラー１２２ｇが管理できる作業領域にＮａｔｕｒａｌサーバ・アプリケーション１２４ｇを実行するための領域を作成する。つまり、コントローラ１２６は、それぞれのＤＣイネーブラー１２２の管理作業領域内に、対応するサーバ・アプリケーション１２４を実行するための領域を作成する。
【００６５】
最初の新規のトランザクションか否かの判定基準は、クライアント１５０からの接続要求があった場合に、対応するサーバ・アプリケーション１２４がコントローラ１２６によって既にＤＣイネーブラー１２２の作業領域に呼び出されているか否かである。対応するサーバ・アプリケーション１２４がまだ呼び出されていなければ、それが新規のトランザクションになる。
【００６６】
次に、メッセンジャー１２８からの受信メッセージである汎用画面データ１５９’内のＤＣ区分がＣＩＣＳ、ＩＭＳ、ＤＣＣＭ３、ＡＤＭ、ＡＩＭ、ＡＩＭ／ＡＣＳ、Ｎａｔｕｒａｌ（いずれも既存のメインフレーム用アプリケーション・サーバの商品名または登録商標）のいずれであるかを判定し（Ｓ０５−０３）、それぞれの場合に応じて、ＣＩＣＳイネーブラー１２２ａ（Ｓ０５−０４）、ＩＭＳイネーブラー１２２ｂ（Ｓ０５−０５）、ＤＣＣＭ３イネーブラー１２２ｃ（Ｓ０５−０６）、ＡＤＭイネーブラー１２２ｄ（Ｓ０５−０７）、ＡＩＭイネーブラー１２２ｅ（Ｓ０５−０８）、ＡＩＭ／ＡＣＳイネーブラー１２２ｆ（Ｓ０５−０９）、Ｎａｔｕｒａｌイネーブラー１２２ｇ（Ｓ０５−１０）のうち、対応するＤＣイネーブラーに受信メッセージを送信し、終了する。
【００６７】
図１０は、上記のＤｏ新規トランザクション（Ｓ０５−０２）の処理の流れを示している。まず、トランザクションの種類が、会話型か、擬似会話型であるかを判定し（Ｓ０６−０１）、それぞれの場合に応じて、会話型処理領域の確保（Ｓ０６−０２）、擬似会話型処理領域の確保（Ｓ０６−０３）のうち、対応する処理を実行し、終了する。
【００６８】
トランザクションの種類の判定基準はＤＣ区分によっており、例えば、ＤＣがＣＩＣＳであれば会話型トランザクション、ＩＭＳであれば擬似会話型トランザクションと判定される。会話型処理は、一つのアプリケーションで、一連の複数の入出力画面を処理する。一方、擬似会話型処理は、一つのアプリケーションで一つの入出力画面を処理する。
【００６９】
会話型／擬似会話型処理領域の確保というのは、既に説明したように、コントローラが、それぞれのＤＣイネーブラーの管理作業領域内に、対応するサーバ・アプリケーションの動作を可能にする仕組みを有する環境を作成する、ということである。通常のＪａｖａアプリケーション・サーバは擬似会話型処理だけをサポートしているが、本システムでは、会話型／擬似会話型処理のどちらもサポートしている、ということである。
【００７０】
図１１は、ＤｏＤＣイネーブラー（Ｓ０４−０３）の処理の流れを示している。まず、メッセージのリクエストが、汎用画面データなどのメッセージ送信、ＤＢ・ＤＣ用のトランザクション管理系のどちらであるかを判定し（Ｓ０７−０１）、それぞれの場合に応じて、メッセンジャー１２８に渡す（Ｓ０７−０２）、Ｊａｖａアプリケーション・サーバに渡す（Ｓ０７−０３）のうち、対応する処理を行い、終了する。
【００７１】
図１２は、ＤｏＪａｖａアプリケーション・サーバ（Ｓ０４−０４）の処理の流れを示している。まず、メッセージのリクエストがメッセージ送信、サーバ・アプリケーション処理系のどちらであるかを判定し（Ｓ０８−０１）、それぞれの場合に応じて、メッセンジャー１２８に渡す（Ｓ０８−０２）、ＤＣイネーブラー１２２に渡す（Ｓ０８−０３）のうち、対応する処理を行い、終了する。
【００７２】
ＤＣイネーブラー１２２は、メインフレームのＤＣインターフェースを意味している。ＤＣは、既に説明したように、メインフレームにおいて、アプリケーションがサーバ１０にあり、クライアント３０には画面インターフェースがあるだけであるメインフレームの中で、多量のクライアントやその画面を操作・管理する仕組みである。ＤＣイネーブラー１２２は、サーバ・アプリケーション１２４への、
（Ａ）メインフレームＤＣと同様のインターフェースの提供、
（Ｂ）メインフレーム環境下で動いているかのようなサーバ・アプリケーション実行環境の提供、
という機能を実現する。
【００７３】
図１３は、ＤＣイネーブラー１２２が行う処理の流れを示している。まず、（コントローラ１２６経由の）メッセージの送信元がメッセンジャー１２８、マネージャー１２０、Ｊａｖａアプリケーション・サーバ１０２、サーバ・アプリケーション１２４のいずれであるかを判定し（Ｓ０９−０１）、それぞれの場合に応じて、定義済み処理であるＤｏメッセンジャー（Ｓ０９−０２）、Ｄｏマネージャー（Ｓ０９−０３）、ＤｏＪａｖａアプリケーション・サーバ（Ｓ０９−０４）、Ｄｏサーバ・アプリケーション（Ｓ０９−０５）のうち、対応する処理を実行し、終了する。
【００７４】
図１４は、上記のＤｏメッセンジャー（Ｓ０９−０２）の処理の流れを示している。サーバ・アプリケーション１２４は、複数の端末に対して、平行して処理を行っている。そのために、端末ＩＤ毎の処理領域が設けられることになり、それをエリアと呼んでいる。このエリアは、ＤＣイネーブラー１２２が管理している。
【００７５】
まず、端末ＩＤ毎のエリアをサーチした後（Ｓ１０−０１）、メッセンジャーから送信されたメッセージが新規の端末ＩＤに関するものであるか否かを判定し（Ｓ１０−０２）、そうであれば、その端末ＩＤ用のエリアを確保する（Ｓ１０−０３）。
【００７６】
そして、メッセージの中に汎用画面データがあるか否かを判定し（Ｓ１０−０４）、あれば定義済み処理である画面データ・コンバータ（汎用→ＤＣ用）の処理を行う（Ｓ１０−０５）。定義済み処理である画面データ・コンバータ１４１は、単に、対になる汎用画面データ１５９’とＤＣ用画面データ１４２との間の変換処理を行うものである。
【００７７】
続けて、トランザクションが新規であるか否かを判定し（Ｓ１０−０６）、そうであれば、画面データ・コンバータ（汎用→ＤＣ用）の処理（Ｓ１０−０５）の結果であるＤＣ用画面データ１４２がある場合、それを端末ＩＤ用のエリアにセットする（Ｓ１０−０７）。そうでなければ、トランザクションＩＤから目的のサーバ・アプリケーション１２４を決定する（Ｓ１０−０８）。
【００７８】
ここでのトランザクションは、コントローラ１２６で扱われていた前述のトランザクションとは別のものであり、各端末で表示される一連の入力画面の各入力画面で実行されるアプリケーションと関連付けられていて、固有のトランザクションＩＤが割り付けられているものである。
【００７９】
最後に、コントローラ１２６によって用意された作業領域に、目的のサーバ・アプリケーション１２４をロードし（呼出し）、起動し（Ｓ１０−０９）、終了する。
【００８０】
図１５は、上記のＤｏマネージャー（Ｓ０９−０３）の処理の流れを示している。まず、メッセージのリクエストがサーバ・アプリケーション強制終了、サーバ・アプリケーション管理系のいずれであるかを判定し（Ｓ１１−０１）、それぞれの場合に応じて、サーバ・アプリケーション１２４を強制終了する（Ｓ１１−０２）、サーバ・アプリケーション管理系（Ｓ１１−０３）のうち、対応する処理を実行し、終了する。なお、サーバ・アプリケーション管理系とは、サーバ・アプリケーション１２４のログ取得の要求などのことである。
【００８１】
図１６は、上記のＤｏＪａｖａアプリケーション・サーバ（Ｓ０９−０４）の処理の流れを示している。すなわち、ＤＢ１１８の整合性が失われた場合の通知などの情報をそのままサーバ・アプリケーション１２４に渡す処理を行い（Ｓ１２−０１）、終了する。
【００８２】
図１７は、上記のＤｏサーバ・アプリケーション（Ｓ０９−０５）の処理の流れを示している。ここではＣＩＣＳサーバ・アプリケーション１２４ａを例として挙げている。まず、サーバ・アプリケーション１２４ａからの命令であるＥｘｅｃＣＩＣＳの構文を解析し（Ｓ１３−０１）、その解析した結果が構文エラーであるか否かを判定し（Ｓ１３−０２）、そうであれば、マネージャー１２０の監視画面へエラー・メッセージ出力をし（Ｓ１３−０３）、終了する。
【００８３】
次に、ＣＩＣＳの命令が、Ｒｅｃｅｉｖｅ  Ｍａｐ、Ｓｅｎｄ  Ｍａｐ、ＸＣＴＬ、ＳＴＡＲＴ  ＴＲＡＮ、Ｒｅｔｕｒｎ、上記以外のそれぞれの場合に応じて、ＣＩＣＳ用画面データをアプリケーション１２４ａに渡す（Ｓ１３−０５）、（定義済み処理である）画面データ・コンバータ（ＣＩＣＳ用→汎用）（Ｓ１３−０６）による変換後のデータである汎用画面データ１５９’をコントローラ１２６に渡す（Ｓ１３−０７）、アプリケーション終了後に目的のアプリケーション１２４を起動するようコントローラ１２６に伝える（Ｓ１３−０８）、目的のアプリケーション１２４を起動するようコントローラ１２６に伝える（Ｓ１３−０９）、アプリケーション１２４を終了する（Ｓ１３−１０）、それぞれのＣＩＣＳ命令を実行する（Ｓ１３−１１）のうち、対応する処理を実行し、終了する。
【００８４】
なお、Ｄｏサーバ・アプリケーションは、メッセージ毎に１つのＥｘｅｃＣＩＣＳだけ実行する。
【００８５】
次に、サーバ・アプリケーション１２４について説明する。サーバ・アプリケーション１２４は、メインフレーム上で動作するアプリケーション１４、つまりビジネス・ロジックが、専用ツールにより、Ｃｏｂｏｌ言語からＪａｖａ言語にほぼ自動変換されたものである。これによって、処理のための論理構成は保持されるため、メインフレームの資産をそのまま継承することが可能となる。
【００８６】
ただし、メインフレームは、機種の数も少なくなく、その機種毎に処理方式などの違いがある。メインフレーム・アプリケーション内で使用される命令も、処理内容の概要は似ていても、そのメインフレーム機種独自の名前が使われており、かつ、その付属パラメータなどのインターフェースにも違いがある。サーバ・アプリケーション１２４は、そのメインフレーム機種毎の命令などの独自部分も引き継いでいるため、その対応処理を担当するＤＣイネーブラー１２２にサポートされるようになっている。
【００８７】
同時に、メインフレーム・アプリケーションによって扱われる画面データも、メインフレーム機種毎に違いがあり、これもサーバ・アプリケーション１２４に引き継がれる。サーバ・アプリケーション１２４によって扱われる画面データは、ＤＣ用画面データ１４２と呼ばれるものであり、サーバ・アプリケーション１２４毎にその書式は異なっている。
【００８８】
次に、マネージャー１２０について説明する。マネージャーは、ＤＢ・ＤＣ機能を監視・運用するものである。
【００８９】
図１８は、マネージャー１２０が行う処理の流れを示している。まず、定義済み処理であるＤｉｓｐｌａｙＩｎｉｔＳｃｒｅｅｎ（Ｓ１４−０１）を実行する。
【００９０】
次いで、メッセージ・キューにメッセージがあるか否かを判定し（Ｓ１４−０２）、あればログ・ファイルに格納（Ｓ１４−０３）し、定義済み処理であるＤｉｓｐｌａｙＭｅｓｓａｇｅ（Ｓ１４−０４）を実行した後、（Ｓ１４−０１）後の処理位置まで戻る。メッセージ・キューとは、イベント駆動形式において、発生したメッセージを発生順に保存しておく領域である。キューイングされたメッセージは、処理すべきサーバ上の機能によって、順次取り出され、処理される。
【００９１】
または、定義済みの処理であるＤｏＳｃｒｅｅｎ（Ｓ１４−０５）を実行し、マネージャーの終了要求があるか否かを判定し（Ｓ１４−０６）、あればそこで終了する。なければ、（Ｓ１４−０１）後の処理位置まで戻る。
【００９２】
なお、Ｓ１４−０２〜０４とＳ１４−０５〜０６は平行処理されるようになっている。
【００９３】
図１９は、ＤｉｓｐｌａｙＩｎｉｔＳｃｒｅｅｎの処理の流れを示している。まず、同図に「画面の例」として示されるように、監視モニター上に、標準的なログ画面を初期画面として表示し（Ｓ１５−０１）、終了する。
【００９４】
図２０は、ＤｉｓｐｌａｙＭｅｓｓａｇｅの処理の流れを示している。まず、監視モニター上の現在表示されている画面に、指定された条件設定に該当するメッセージのみを表示し（Ｓ１６−０１）、終了する。
【００９５】
図２１は、ＤｏＳｃｒｅｅｎの処理の流れを示している。まず、画面のボタンが押されたか否かを判定し（Ｓ１７−０１）、そうであれば、「端末情報」、「プログラム」、「ディスク」の各ボタン用のログ表示画面を表示し（Ｓ１７−０２）、終了する。
【００９６】
画面のボタンが押されていなければ、リクエストがサーバ・アプリケーション強制終了であるか否かを判定し（Ｓ１７−０３）、そうであればコントローラ１２６にその指示を渡した（Ｓ１７−０４）後に終了し、そうでなければ直ちに終了する。
【００９７】
次に、クライアント１５０の構成について説明する。
【００９８】
ユーザが本システムのサーバ１００の提供するサービスを利用するためのコンピュータであるクライアントには、端末エミュレータ１５６を有するクライアント１５０と、ウェブ・サービス機能のみを有するウェブ・サービス・クライアント１６０の２種類がある。いずれも、基本的にはＷｅｂサービスを利用してサーバ１００にアクセスするようになっている。クライアント１５０，１６０は、サーバ１００と連携することで、
（Ａ）端末からの一回のレスポンス内（通常３秒以内）の処理要求が複数のデータを一挙に更新する場合等の複雑な処理時に、他の多くのクライアントも同様なデータに対し同様の更新をしている中で、当該クライアント分の更新完了と同時に、確実に実行出来た事を当該クライアントに通知する事が出来る「同期処理」、
（Ｂ）端末の実行キー押下後、端末に制御が戻るまでを１トランザクションとして、アプリケーションの異常終了時のオートロールバック等をサポートする「トランザクション処理」、
等を実現する。
【００９９】
クライアント１５０が内蔵する端末エミュレータ１５６は、メインフレームのクライアントの端末を模倣した機能を標準装備している、通常のＪａｖａアプリケーションであり、Ｊａｖａウェブ・スタートによって、バージョンの自動更新の対象となっているものである。メインフレームのクライアントの端末を模倣することによって、良好な操作性と画面表示を継承しているため、従来からのメインフレームユーザに対して全く負担増にならないという特長を持っている。更に、オープンシステムのＷｅｂ系ＧＵＩ画面の利便性をも兼ね備えている。
【０１００】
端末エミュレータ１５６は、その内部にＷｅｂサービス・クライアント機能を持っており、この機能を使って、Ｗｅｂサービス・サーバ１１２に接続し、サーバ１００が提供するサービスを利用することができる。
【０１０１】
クライアント１５０は、Ｊａｖａウェブ・スタート・サーバ１０４の記憶装置１０６に保存されている、最新の端末エミュレータ実行ファイル１０８および汎用画面フォーム１１０をダウンロードし、これらを端末エミュレータ実行ファイル１５７および汎用画面フォーム１５８として、クライアント１５０内の記憶装置（図示せず）に保存する。そして、端末エミュレータ１５６は、Ｗｅｂサービス・サーバ１１２からＸＭＬ形式の汎用画面データ１５９が送信されてきたときに、端末エミュレータ実行ファイル１５７に基づき、これを汎用画面フォーム１５８と融合して、ユーザの操作対象となる画面を生成する。
【０１０２】
Ｗｅｂサービス・クライアント１６０は、上述の端末エミュレータ１５６とは違い、Ｊａｖａウェブ・スタートを利用せず、単に、Ｗｅｂサービス・サーバ１１２と接続するのみであり、汎用画面データ１５９のみを扱う。Ｗｅｂサービス・クライアントとしての機能を持つものであれば、ＰＣ、携帯電話といった種類を問わず、本システムのサービスを利用することが可能であることが特長である。
【０１０３】
次に、画面定義体について図２２を参照して説明する。
【０１０４】
従来技術に関連して既述したように、画面定義体は、もともとメインフレームで使われていて、画面上に表示される複数のフィールドが定義されている定義体（メインフレーム画面定義体２０）である。本システムでは、このメインフレーム画面定義体というインターフェースを継承し、新しいオープン環境で活用するために適宜変換して汎用画面定義体１３５を作成する。
【０１０５】
より詳しくは、システム移行時（およびシステムバージョンアップ時）に、メインフレーム画面定義体２０を画面定義体コンバータ１３４によって汎用画面定義体１３５に変換する。そして、汎用画面定義体１３５の新規作成／変更時には、汎用画面定義体コンパイラ１３６の４つのジェネレータ１３７〜１４０によって、この汎用画面定義体１３５から、汎用画面フォーム１１０、汎用画面データ１５９’、画面データ・コンバータ１４１およびＤＣ用画面データ１４２を自動生成する。
もしくは、汎用画面定義体１３５は、汎用画面定義体用ＧＵＩツールである汎用画面定義体ビルダ１４３によって作成／修正が可能であり、それがなされたときには、自動的に汎用画面定義体コンパイラ１３６の４つのジェネレータ１３７〜１４０を起動し、汎用画面フォーム１１０、汎用画面データ１５９’、画面データ・コンバータ１４１およびＤＣ用画面データ１４２を生成する。
【０１０６】
より詳しく説明すると、汎用画面定義体１３５は、すべてのメインフレームの機種の画面定義体２０に対し、それらの違いを吸収し、一つの画面定義体で対応可能なフォーマットを持つものである。汎用画面定義体１３５そのものは、本システム稼動時に内部で取り扱われることはなく、汎用画面フォーム１１０、汎用画面データ１５９’、画面データ・コンバータ１４１およびＤＣ用画面データ１４２を生成するための材料として用いられる。
【０１０７】
汎用画面定義体１３５により、メインフレームで複数のＤＣを使用していたユーザの場合であっても、本システムの一つのサーバ１００によって一括処理を行うことが可能となる。そして、複数のＤＣ用の画面定義体２０を一つの画面定義体、つまり汎用画面定義体１３５に集約することで、画面定義体の追加・修正などにおいてメンテナンス性を高めている。さらに、通常のＷｅｂインターフェースで扱えるような処理（ユーザへの通知用ポップアップ・ウィンドウの表示や、ドロップダウン・メニューの表示など）が、汎用画面定義体１３５では可能であり、メインフレームと比較して格段に優れた拡張性を持つものとなる。
【０１０８】
汎用画面定義体１３５からコンパイラ１３６の汎用画面フォーム・ジェネレータ１３７によって生成される汎用画面フォーム１１０は、クライアント１５０の端末エミュレータ１５６で使用される、どんなメインフレームの機種の画面定義体２０にも対応できる画面フォームである。ここに、画面フォームとは、汎用画面データ１５９（１５９’）で定義されたフィールドの配置などの画面構成情報を設定するためのものである。
【０１０９】
また、既述のように、汎用画面フォーム１１０は、常に最新バージョンのものとしてＪａｖａウェブ・スタート・サーバ１０４の記憶装置１０６に保存されており、クライアント１５０からの更新要求によって、配信されるようになっている。
【０１１０】
クライアント１５０が、サーバ１００のサービスを利用するにあたり、Ｊａｖａウェブ・スタート・サーバ１０４から取得した汎用画面フォーム１１０（汎用画面フォーム１５８として保存）と、ウェブ・サービス・サーバ１１２から取得した汎用画面データ１５９を融合することで、クライアント１５０の入力画面を生成する。この際、クライアント１５０で扱われるデータはすべて汎用的なものであるので、画面フォームの種類などを意識する必要はなくなり、クライアント側での処理負担は小さい。
【０１１１】
汎用画面定義体１３５からコンパイラ１３６の汎用画面データ・ジェネレータ１３８によって生成される汎用画面データ１５９は、クライアント・サーバ間で毎回の通信で使用されるものであって、あらゆるメインフレームの機種の画面定義体２０にも対応できる汎用性のある画面データである。画面データとは、複数のフィールドの属性を設定できるようになっているフォーマットないし書式である。フィールドとは、画面上に表示される個々の入力項目である。図４に関連して既述したように、クライアント１５０の画面における各ファンクション・キーとそれによって実行される処理項目や処理内容などとの関連付けについても、画面データに含まれている。
【０１１２】
このような汎用画面データ１５９を用いることによって、前述の汎用画面フォーム１１０と同様に、クライアント１５０の入力画面を生成する際にクライアント１５０で扱われるデータはすべて汎用的なものとなるので、画面データの種類などを意識する必要はなくなり、クライアント側での処理負担は小さい。
【０１１３】
汎用画面定義体１３５からコンパイラ１３６の画面データ・コンバータ・ジェネレータ１３９によって生成される画面データ・コンバータ１４１は、ＤＣイネーブラー１２２内部の機能として、クライアント・サーバ間の毎回の通信時に、汎用画面データ１５９’とＤＣ用画面データ１４２とを相互に変換するものである。
【０１１４】
クライアント１５０からサーバ・アプリケーション１２４への画面データの送信時には汎用画面データ１５９’からＤＣ用画面データ１４２への変換を行い、逆に、サーバ・アプリケーション１２４からクライアント１５０への画面データの送信時にはＤＣ用画面データ１４２から汎用画面データ１５９’への変換を行う。
【０１１５】
汎用画面定義体１３５からコンパイラ１３６のＤＣ用画面データ・ジェネレータ１４０によって生成されるＤＣ用画面データ１４２は、クライアント・サーバ間で毎回の通信で使用されるものであり、サーバ・アプリケーション１２４内部で処理されるものである。サーバ・アプリケーション１２４に引き継がれている処理方式の違いのため、そこで扱われるデータの形式にも、サーバ・アプリケーション毎に違いがある。そのために用意されたのが、ＤＣ用画面データ１４２である。
【０１１６】
これまでは、本システムの各機能を中心に、それに付随するような形で各データについて説明をしてきたが、以下において、本システムが処理を実行する際にクライアント・サーバ間およびサーバ間の各手段間でやり取りされるデータの流れについて説明する。
【０１１７】
図２３は、クライアント１５０の端末エミュレータ１５６を起動し、その端末エミュレータ１５６がサーバ１００に対して特定の処理を依頼するため、サーバ１００へデータを送信し、サーバ１００がそのデータを適宜処理後、その結果をクライアント１５０に返送し、クライアント１５０がその結果に応じた画面を表示する過程を説明している。その過程で表示されるクライアント１５０の画面の遷移を、図２４、図２５、図２６および図２７に示している。ここでは、擬似会話型処理を例にしている。
【０１１８】
まず、図２３の各ステップを説明する。
【０１１９】
Ｓ１：クライアント１５０において、端末エミュレータ１５６の初回起動の際には、Ｗｅｂブラウザ１５２からＪａｖａウェブ・スタート・サーバ１０４へのＵＲＬのリンクをクリックすることにより、端末エミュレータ起動要求をＪａｖａウェブ・スタート・サーバ１０４に送信する。これを受けたＪａｖａウェブ・スタート・サーバ１０４は、Ｊａｖａウェブ・スタート・クライアント１５４が端末エミュレータ１５６を起動するために必要な情報を記載したファイル（端末エミュレータ起動用ファイル）をＷｅｂブラウザ１５２に送信する。Ｗｅｂブラウザ１５２は、端末エミュレータ起動用ファイルに関連付けられたＪａｖａウェブ・スタート・クライアント１５４を自動的に起動し、受信した端末エミュレータ起動用ファイルを手渡す。
【０１２０】
Ｓ２：端末エミュレータ１５６の初回起動時には、Ｓ１で自動的に起動したＪａｖａウェブ・スタート・クライアント１５４がＷｅｂブラウザ１５２から手渡された端末エミュレータ起動用ファイルの記載内容に基づいて、端末エミュレータ１５６を起動するために必要となる最新版の端末エミュレータ実行ファイル１０８と汎用画面フォーム１１０のそれぞれのダウンロード要求をＪａｖａウェブ・スタート・サーバ１０４に送信する。そのダウンロード要求を受けたＪａｖａウェブ・スタート・サーバ１０４は、サーバ側の記憶装置１０６に保存されている最新バージョンの端末エミュレータ実行ファイル１０８と汎用画面フォーム１１０のそれぞれをダウンロード要求元のＪａｖａウェブ・スタート・クライアント１５４に配信する。
【０１２１】
もしくは、端末エミュレータ１５６の２回目以降の起動の際には、Ｓ１のステップを経ることなしに、Ｊａｖａウェブ・スタート・クライアント１５４が持つメニュー画面上で端末エミュレータ１５６起動のための項目を選択することにより、Ｊａｖａウェブ・スタート・クライアント１５４が端末エミュレータ実行ファイル１０８と汎用画面フォーム１１０のそれぞれの更新確認要求をＪａｖａウェブ・スタート・サーバ１０４に送信する。その更新確認要求を受けたＪａｖａウェブ・スタート・サーバ１０４は、クライアント１５０側で保存している端末エミュレータ実行ファイル１５７と汎用画面フォーム１５８のそれぞれが最新バージョンであるか否かを判定する。最新バージョンではないと判断されたとき、Ｊａｖａウェブ・スタート・サーバ１０４は、サーバ側の記憶装置１０６に保存されている最新バージョンの端末エミュレータ実行ファイル１０８、もしくは汎用画面フォーム１１０を、更新確認要求元のＪａｖａウェブ・スタート・クライアント１５４に配信する。Ｊａｖａウェブ・スタート・クライアント１５４はそれぞれを端末エミュレータ実行ファイル１５７、汎用画面フォーム１５８として保存し（図２も参照のこと）、その端末エミュレータ実行ファイル１５７を使用して端末エミュレータ１５６を起動する。
【０１２２】
Ｓ３：起動した端末エミュレータ１５６の画面のトランザクションＩＤの欄に、所望のＩＤが入力され、トランザクション処理が開始される。
【０１２３】
Ｓ４：端末エミュレータ１５６の一機能であるＷｅｂサービス・クライアント機能によって、サーバ側のＷｅｂサービス・サーバ１１２に画面データを送信する。この画面データとは、たとえば前述の図４を参照した説明においていずれかのファンクション・キーを押下することによって特定される処理要求コマンドであり、あるいは、画面に表示された各フィールドにデータ入力することによって特定される処理要求コマンドである。これが、クライアント１５０において端末エミュレータ１５６が参照可能なＸＭＬ形式の汎用画面データ１５９（図２）である。
【０１２４】
Ｓ５：受領した汎用画面データ１５９に含まれるコマンドの内容をサーバ・アプリケーションで処理可能なようにより詳細なコマンドに変換するとともに、その変換処理後の画面データをメッセンジャー１２８に送信する。
【０１２５】
Ｓ６：メッセンジャー１２８は、Ｗｅｂサービス・サーバ１１２から受領したＸＭＬ形式の汎用画面データ１５９を汎用画面データ１５９’に変換後、コントローラ１２６に送信する。
【０１２６】
Ｓ７：コントローラ１２６が汎用画面データ１５９’を受領する。
【０１２７】
Ｓ８：その後、受領した汎用画面データ１５９’の処理を担当するサーバ・アプリケーション１２４の種類を判定し、そのサーバ・アプリケーション用の作業領域を対応するＤＣイネーブラー１２２の管理領域に確保する。
【０１２８】
Ｓ９：ＤＣイネーブラー１２２は、受領した汎用画面データ１５９’が新規接続の端末ＩＤのものであることを判定し、新トランザクションとして、端末用（作業用）エリアを確保する。
【０１２９】
Ｓ１０：そして、トランザクションＩＤに関連付けられたサーバ・アプリケーションＩＤを取得する。また、受領した画面データは、汎用画面データ１５９’からＤＣ用画面データ１４２に変換し、確保した端末エリアにセットする。その後、そのサーバ・アプリケーション１２４を呼出し、起動する。
【０１３０】
Ｓ１１：サーバ・アプリケーション１２４は、まず、次トランザクションの準備として、次画面用画面フォームＩＤを指定する。
【０１３１】
Ｓ１２：それとともに、次トランザクションＩＤを指定する。
【０１３２】
Ｓ１３：その後、セットされたＤＣ用画面データ１４２に基づいて所要のデータ処理を行い、その処理結果をクライアント１５０の画面に表示させるために必要な画面データ（ＤＣ用画面データ１４２）を作成する。
【０１３３】
Ｓ１４：ＤＣイネーブラーは、サーバ・アプリケーションから画面フォームＩＤ、トランザクションＩＤ、Ｓ１３でデータ処理後の画面データを受領する。
【０１３４】
Ｓ１５：そして、トランザクションＩＤは、次のトランザクション処理時にそのトランザクションＩＤに関連付けられたサーバ・アプリケーションＩＤを取得するために保存する（保存したサーバ・アプリケーションＩＤは、Ｓ２５において参照される）。画面データは、ＤＣ用画面データ１４２から汎用画面データ１５９’に変換する。そして、変換後の画面フォームＩＤ、汎用画面データ１５９’をコントローラ１２６に送信する。
【０１３５】
Ｓ１６：コントローラ１２６は、ＤＣイネーブラー１２２から画面フォームＩＤ、汎用画面データ１５９’を受信し、メッセンジャー１２８に送信する。
【０１３６】
Ｓ１７：メッセンジャー１２８は、コントローラ１２６から画面フォームＩＤ、汎用画面データ１５９’を受信し、これらをＸＭＬ形式のデータに変換する。そして、変換後の画面フォームＩＤ、汎用画面データ１５９をＷｅｂサービス・サーバ１１２へ送信する。
【０１３７】
Ｓ１８：Ｗｅｂサービス・サーバ１１２は、メッセンジャー１２８から受信した画面フォームＩＤ、汎用画面データ１５９を、Ｗｅｂサービスを可能とするための紹介情報を付加して、クライアント１５０に送信する。これで、クライアント１５０からの画面データに関する処理要求をサーバ１００側で完了したことになる。
【０１３８】
Ｓ１９：クライアント１５０の端末エミュレータ１５６は、Ｗｅｂサービス・サーバ１１２から画面フォームＩＤ、汎用画面データ１５９を受信する。
【０１３９】
Ｓ２０：そして、画面フォームＩＤにより特定される画面フォームを当該アプリケーションについて保存されている最新バージョンの汎用画面フォーム１５８から抽出し、これをＳ１９でＷｅｂサービス・サーバ１１２から受信した汎用画面データ１５９と合成して、画面を出力する。これによって、一つのトランザクション処理が終了する。汎用画面データ１５９，１５９’は、言い換えれば、サーバ・アプリケーションの実行においてクライアント側に入力処理を求める一連の画面データ（フィールドの属性や各ファンクション・キーの割り当て等に関するデータ）のうち、クライアントの次画面として表示すべき事項に係る次画面表示用データである。
【０１４０】
上述のＳ１〜Ｓ２０が一つのトランザクション処理の過程であり、Ｓ２１〜Ｓ３５までの過程も、ほぼ同様な過程になっている。ただし、Ｓ９、Ｓ１０に対応するＳ２５においては、ＤＣイネーブラー１２２が、Ｓ１５で保存したトランザクションＩＤを、Ｓ２１〜Ｓ３５のトランザクション処理時にそのトランザクションＩＤに関連付けられたサーバ・アプリケーションＩＤとして取得し、そのＩＤを持つサーバ・アプリケーションを呼出し、起動する。
【０１４１】
この過程の中で、Ｓ１、Ｓ３、Ｓ２０、Ｓ３５に対応するクライアント１５０の端末エミュレータ１５６の画面の例がそれぞれ図２４、図２５、図２６、図２７である。
【０１４２】
図２６を例に説明する。その図上部の表には、「トランザクションＩＤ」、「このトランザクションで、適用される画面フォームＩＤ」、「このトランザクション中、ＤＣイネーブラーによって呼び出されるサーバ・アプリケーションＩＤ」という項目があり、２、３番目の項目は、それぞれトランザクションＩＤと１対１に関連付けられている。
【０１４３】
同図下部の端末エミュレータ１５６の画面は画面フォームＩＤ「ＡＦＰＭ００Ｘ」の画面フォームが使用されている。そして、機能選択がなされた後、トランザクションＩＤ「Ａ００Ｙ」としてトランザクション処理が開始される。このトランザクション中、サーバ１００内のＤＣイネーブラー１２２によって呼び出されるサーバ・アプリケーションＩＤが「ＡＦＰ００１０Ｘ」である。
【０１４４】
最後に画面データの形式について説明すると、図２３の最下部に示されるように、クライアント１５０、Ｗｅｂサービス・サーバ１１２およびメッセンジャー１２８の間ではＸＭＬ形式の汎用画面データ１５９が扱われ、メッセンジャー１２８、コントローラ１２６およびＤＣイネーブラー１２２の間では汎用画面データ１５９’が扱われ、ＤＣイネーブラー１２２およびサーバ・アプリケーション１２４間ではＤＣ用画面データ１４２が扱われる。つまり、メッセンジャー１２８がＸＭＬ形式の汎用画面データ１５９と汎用画面データ１５９’との間におけるデータ形式の変換ポイントであり、ＤＣイネーブラー１２２が汎用画面データ１５９’とＤＣ用画面データ１４２との間におけるデータ形式の変換ポイントとなっている。
【０１４５】
【発明の効果】
以上に説明したように、本発明によれば、メインフレームのアプリケーション資産と、データの入力・更新・検索などの手順を提供および情報の集中管理を実現するＤＢ（データベース）機能およびアプリケーションがサーバにあり、クライアントには画面インターフェースがあるだけであるメインフレームの中で多数のクライアントやその画面を管理する仕組であるＤＣ（データコミュニケーション）機能を、様々なメーカーのソフトウェアやハードウェアを組み合わせて構築されているコンピュータ・システムであるオープン環境に移行することができる。
【０１４６】
したがって、
（ア）メインフレーム上で培われたアプリケーションであるビジネス・ロジックを、短期間、低コストで継承することができ、
（イ）メインフレームの端末側の、従来の画面表示と操作性  （インターフェース）  を継承しているため、従来のユーザの負担を増大させることがなく、
（ウ）メインフレームでは、原則直接ワイヤー接続された端末かそれを少し拡張した程度の限られた範囲でしか、サービス提供できなかったが、Ｗｅｂサービス・インターフェース機能により、場所や端末の種類に関わらず、広範囲にサービス提供ができ、
（エ）通常のオープン環境では困難な、メインフレームの主だった機能である、同期処理、トランザクション、端末監視、通信セキュリティ、ＬＵ設定、ＤＣ監視を実現できる、
等の効果がある。
【図面の簡単な説明】
【図１】メインフレーム環境によるクライアント・サーバ・システムの概略構成図である。
【図２】本発明によるメインフレームのオープン化システムの概略構成図である。
【図３】図２のシステムにおけるサーバ構成を示す概略図である。
【図４】端末エミュレータによる処理画面の一例を示す図である。
【図５】サーバにおいてメッセンジャーが行う処理を示すフローチャートである。
【図６】図５におけるＤｏクライアント処理を示すフローチャートである。
【図７】図５におけるＤｏコントローラ処理を示すフローチャートである。
【図８】サーバにおいてコントローラが行う処理を示すフローチャートである。
【図９】図８におけるＤｏメッセンジャー処理を示すフローチャートである。
【図１０】図９におけるＤｏ新規トランザクション処理を示すフローチャートである。
【図１１】図８におけるＤｏＤＣイネーブラー処理を示すフローチャートである。
【図１２】図８におけるＤｏＪａｖａアプリケーション・サーバー処理を示すフローチャートである。
【図１３】サーバにおいてＤＣイネーブラーが行う処理を示すフローチャートである。
【図１４】図１３におけるＤｏメッセンジャー処理を示すフローチャートである。
【図１５】図１３におけるＤｏマネージャー処理を示すフローチャートである。
【図１６】図１３におけるＤｏＪａｖａアプリケーション・サーバー処理を示すフローチャートである。
【図１７】図１３におけるＤｏサーバ・アプリケーション処理を示すフローチャートである。
【図１８】サーバにおいてマネージャーが行う処理を示すフローチャートである。
【図１９】図１８におけるＤｉｓｐｌａｙＩｎｉｔＳｃｒｅｅｎ処理を示すフローチャートである。
【図２０】図１８におけるＤｏメッセージ処理を示すフローチャートである。
【図２１】図１８におけるＤｏスクリーン処理を示すフローチャートである。
【図２２】メインフレーム用画面定義体と汎用画面定義体との関係および汎用画面定義体から汎用画面フォーム、汎用画面データ、画面データ・コンバータおよびＤＣ用画面データを生成する過程ならびにこれらのサーバおよびクライアントにおける利用について模式的に示す説明図である。
【図２３】クライアントの端末エミュレータを起動し、その端末エミュレータがサーバに対して特定の処理を依頼するためサーバへデータを送信し、サーバがそのデータを適宜処理後、その結果をクライアントに返送し、クライアントがその結果に応じた画面を表示する過程を説明するフローチャートである。
【図２４】図２３のフローチャート中のＳ１に対応してウェブ・ブラウザにより表示される画面の例を示す図である。
【図２５】図２３のフローチャート中のＳ３に対応してクライアントの端末エミュレータにより表示される画面の例を示す図である。
【図２６】図２３のフローチャート中のＳ２０に対応してクライアントの端末エミュレータにより表示される画面の例を示す図である。
【図２７】図２３のフローチャート中のＳ３５に対応してクライアントの端末エミュレータにより表示される画面の例を示す図である。
【符号の説明】
１００  サーバ
１０２  Ｊａｖａアプリケーション・サーバ
１０４  Ｊａｖａウェブ・スタート・サーバ（汎用画面フォーム送信手段、バージョン判定手段）
１０６  記憶装置（記憶手段）
１０８  端末エミュレータ実行ファイル
１１０  汎用画面フォーム
１１２  ウェブ・サービス・サーバ（次画面表示用データ送信手段）
１１４  汎用インターフェース
１１６  ウェブ・サービス・インターフェース
１２０  マネージャー
１２２  ＤＣインターフェースないしＤＣイネーブラー（第１および第２の画面データ変換手段、画面データ処理手段）
１２４  サーバ・アプリケーション
１２６  コントローラ
１２８  メッセンジャー
１４２  ＤＣ用画面データ（第１の画面データ変換手段による変換後の画面データ）
１５０  クライアント
１５２  ウェブ・ブラウザ
１５４  Ｊａｖａウェブ・スタート・クライアント
１５６  端末エミュレータ（次画面表示用データ取得手段、クライアント画面表示制御手段、処理要求手段）
１５７  端末エミュレータ実行ファイル
１５８  汎用画面フォーム（画面フォーム保存手段）
１５９，１５９’  汎用画面データ（次画面表示用データ、第２の画面データ変換手段による変換後の画面データ）
【図１】
2004355413.tif 000003
【図２】
2004355413.tif 000004
【図３】
2004355413.tif 000005
【図４】
2004355413.tif 000006
【図５】
2004355413.tif 000007
【図６】
2004355413.tif 000008
【図７】
2004355413.tif 000009
【図８】
2004355413.tif 000010
【図９】
2004355413.tif 000011
【図１０】
2004355413.tif 000012
【図１１】
2004355413.tif 000013
【図１２】
2004355413.tif 000014
【図１３】
2004355413.tif 000015
【図１４】
2004355413.tif 000016
【図１５】
2004355413.tif 000017
【図１６】
2004355413.tif 000018
【図１７】
2004355413.tif 000019
【図１８】
2004355413.tif 000020
【図１９】
2004355413.tif 000021
【図２０】
2004355413.tif 000022
【図２１】
2004355413.tif 000023
【図２２】
2004355413.tif 000024
【図２３】
2004355413.tif 000025
【図２４】
2004355413.tif 000026
【図２５】
2004355413.tif 000027
【図２６】
2004355413.tif 000028
【図２７】
2004355413.tif 000029