(57)【要約】      （修正有）【課題】Proxyの利用を効率よく選択的に行うことのできる情報処理装置、プログラム及び記録媒体の提供。【解決手段】WS Client Aplが呼出処理を開始すると、Proxy Emulatorが受け付け、Java（登録商標） Type用のメソッドが呼び出された場合には、WS Proxyを経由してサービス提供装置へ呼出要求を行う。一方、呼び出されたメソッドがJava（登録商標） Type用のものではない場合には直接リクエスト送信を行う。サービス提供装置から、レスポンスがＸＭＬで記述された形式で格納されて戻ってくると、リクエスト時に呼び出されたメソッドがJava（登録商標） Type用のメソッドであれば、WS Proxyを経由してレスポンスを受信して、Java（登録商標） Typeに変換し、WS Client Aplに渡す。Java（登録商標） Type用のメソッドでなければ、直接Proxy Emulatorが受信して、ＸＭＬ形式のままWS Client Aplに渡す。【選択図】図４
2006260220.tif 000002
【特許請求の範囲】
【請求項１】
上位モジュールから、情報提供手段への呼出要求を受け付ける受付手段と、
前記呼出要求に含まれる前記情報提供手段からの応答の形式を指定するメソッドを解析する解析手段と、
前記応答を前記上位モジュールが指定した形式に変換して前記上位モジュールに返信するインタフェースと、前記応答をＸＭＬ形式のまま前記上位モジュールに返信するインタフェースとを備えたプロキシ手段とを有することを特徴とする情報処理装置。
【請求項２】
前記プロキシ手段は、
前記上位モジュールからの指定される応答の前記形式が開発言語により定義された型の場合には、前記情報提供手段からの前記応答を、指定された前記形式に変換して前記上位モジュールへ返信する第１のプロキシ手段と、
前記上位モジュールからの指定される応答の前記形式がＸＭＬ形式の場合には、前記情報提供手段からの前記応答を、ＸＭＬ形式のまま前記上位モジュールへ返信する第２のプロキシ手段と、
を有することを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記受付手段のインタフェースは、前記第１のプロキシ手段と前記第２のプロキシ手段とが共通して利用可能であることを特徴とする請求項１又は２に記載の情報処理装置。
【請求項４】
前記応答を受信する受信手段は、前記第１のプロキシ手段と前記第２のプロキシ手段とのうち、少なくともいずれか一方を選択して受信することを特徴とする請求項１から３のいずれか１項に記載の情報処理装置。
【請求項５】
上位モジュールから、情報提供手段への呼出要求を受け付ける受付処理と、
前記呼出要求に含まれる前記情報提供手段からの応答の形式を指定するメソッドを解析する解析処理と、
前記応答を前記上位モジュールが指定した形式に変換して前記上位モジュールに返信するインタフェースと、前記応答をＸＭＬ形式のまま前記上位モジュールに返信するインタフェースとを備えたプロキシ処理と、
をコンピュータに実行させることを特徴とするプログラム。
【請求項６】
請求項５に記載のプログラムを記録したコンピュータが読取可能な記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置、プログラム及び記録媒体に関する。
【背景技術】
【０００２】
近年、ネットワーク環境を前提としたアプリケーションソフトの開発がなされているが、その１つとして、Ｗｅｂサービスの技術が挙げられる。Ｗｅｂサービスは、インターネットの標準技術を使ってネットワーク上に分散したアプリケーションを連携させるための技術であり、ＨＴＴＰ（Hyper Text Transfer Protocol）やＦＴＰ（File Transfer Protocol）、ＳＭＴＰ（Simple Mail Transfer Protocol）等のインターネット標準のプロトコル上でＸＭＬ（eXtensible Markup Language）ベースのデータをＳＯＡＰ（Simple Object Access Protocol）というプロトコルで送受信することによりアプリケーションの連携のやり取りを実現することになる。
【０００３】
このやり取りにおいては、ＳＯＡＰメッセージによる要求を行うＷｅｂサービスのクライアント側と、そのＳＯＡＰメッセージの内容を解釈して所定の機能を提供するＷｅｂサービスの提供側とが存在することになる。以下、図５を参照しながら、一般的なＷｅｂサービスのシステムについて説明する。
【０００４】
図５は、一般的なＷｅｂサービスのシステム構成例である。このＷｅｂサービスのシステムは、ネットワーク２を介して、各サービス提供装置３，４，５のうち該当する装置と接続して、ＳＯＡＰメッセージによる所定の機能の提供を要求するＷｅｂサービスクライアント装置（以下、単にクライアント装置という）１と、クライアント装置１からのＳＯＡＰメッセージによる要求を解析し、所定の機能をＷｅｂサービスとして提供するＷｅｂサービス提供装置（以下、単にサービス提供装置という）３，４，５により構成されている。
【０００５】
次に、図５のＷｅｂサービスのシステム構成におけるクライアント装置１とサービス提供装置３，４，５間の情報の授受について、図６を用いて説明する。
【０００６】
図６は、図５におけるクライアント装置１とサービス提供装置３とのソフトウェア構成の概略を表すものである。クライアント装置１にはクライアントモジュールが搭載され、各サービス提供装置にはサービス提供モジュールが搭載されており、ネットワーク２を介したこれらモジュール間のやり取りによって、クライアント装置１とサービス提供装置３，４，５とが、互いに情報の授受を行うことになる。また、ネットワーク２としてはローカルエリアネットワーク（ＬＡＮ）、イントラネット、インターネット等のいかなるネットワークを用いてもよく、また、有線であるか無線であるかを問わない。
【０００７】
以下、図６を参照しながら、クライアント装置１とサービス提供装置３との情報の授受について説明する。
【０００８】
まず、クライアント装置１のＷｅｂサービスクライアントアプリケーション（以下、WS Client Aplと称す）１０１から、サービス提供装置３のコアモジュール（以下、Core Moduleと称す）２０３の呼出要求が発生すると、クライアント装置１側のＷｅｂサービスプロキシ（以下、WS Proxyと称す）１０２は、WS Client Apl１０１からの要求をＸＭＬ形式のコマンドに変換し、ＳＯＡＰエンベロープに格納し、ＳＯＡＰメッセージとしてネットワーク３を介してサービス提供装置３側のＷｅｂサービスリスナ（以下、WS Listenerと称す）２０１に送信する。
【０００９】
サービス提供装置３側のWS Listener２０１は、クライアント装置１側のWS Proxy１０２から受信したＳＯＡＰメッセージをパージングし、Ｗｅｂサービス（以下、Web Serviceと称す）２０２を介して、呼び出すべきCore Module２０３のメソッドを検索する。そして、Core Module２０３のメソッド実行結果をＳＯＡＰメッセージのボディにマッピングして、クライアント装置１のWS Proxy１０２に送信する。
【００１０】
レスポンスとしてのＳＯＡＰメッセージを受信したクライアント装置１側のWS Proxy１０２は、メッセージをパージングし、その内容（Core Module２０３のメソッド実行結果）をWS Client Apl１０１に渡すことになる。このような一連のやり取りによって、クライアント装置１とサービス提供装置３との間でＷｅｂサービスとしての情報の授受が実現されることになる。
【００１１】
また、Ｗｅｂサービスに実装されているあるオペレーションを呼び出すときに、WS Proxyを介さなければ、そのリクエストやレスポンスはＸＭＬ形式で行うことになる。そのため、Ｗｅｂサービスクライアントは、リクエストを送信する前には送信用ＸＭＬデータを構築し、さらに、レスポンス取得後には、何らかの方法でそのＸＭＬデータの内容を解析する必要が生ずる。
【００１２】
一方、WS Proxyを介する場合には、プログラミング言語やProxyの性能によって多少の違いはあるものの、一般的なプログラミング言語でメソッドの呼び出しを行う場合とほとんど同じ方法で、メソッドの呼び出しが実現可能である。
【００１３】
なお、上述のような情報の授受に関する従来技術として、特許文献１の発明が公知である。
【特許文献１】特開２００４−０４６８１７号公報
【発明の開示】
【発明が解決しようとする課題】
【００１４】
上述したように、WS Proxyを介することによって、Web Serviceとの通信は大変容易になる。しかし一方で、アプリケーションサーバの内部で行う処理の内容によっては、WS Proxyを経由しないほうが効率的なケースも考えられる。
【００１５】
例えば、表示用データとしてＨＴＭＬデータを作成する場合を考える。
【００１６】
アプリケーションサーバ内での表示用データ作成をＡＳＰ（Active Server Pages）やＪＳＰ（Java（登録商標） Server Pages）などを用いて行う場合、Web Serviceからのデータの受け取りは、やはりProxyを経由したものであるほうが便利である。なぜなら、Proxyをアプリケーションサーバ内で使用するプログラミング言語に合わせることによって、アプリケーションサーバ内のプログラムから、文字列などのString型や数値などのint型（integer型）としてそのまま簡単に扱うことができるからである。
【００１７】
一方、例えば、アプリケーションサーバがＨＴＭＬデータの作成にＸＳＬ（eXtensible Stylesheet Language）を利用する場合には、Web Serviceからのレスポンスデータは、ＸＭＬ形式のままの方が都合が良いこともある。なぜなら、ProxyによってString型やint型にデシリアライズされたデータを、再度ＸＭＬ形式に構築し直す必要があり、これは、作業工数の面やパフォーマンスの面を考えると、大変非効率的だからである。
【００１８】
しかし、レスポンスの受信時には上述したようにProxyを使わないほうが良くとも、やはりリクエストの送信には、WS Proxyを介する場合のように、メソッドを容易に呼び出せると便利である。
【００１９】
このような課題に鑑み、本発明は、Proxyの利用を選択的に行うことのできる情報処理装置、プログラム及び記録媒体を提供することを目的としている。
【課題を解決するための手段】
【００２０】
上記の目的を達成するため、請求項１に記載の発明は、上位モジュールから、情報提供手段への呼出要求を受け付ける受付手段と、呼出要求に含まれる情報提供手段からの応答の形式を指定するメソッドを解析する解析手段と、応答を上位モジュールが指定した形式に変換して上位モジュールに返信するインタフェースと、応答をＸＭＬ形式のまま上位モジュールに返信するインタフェースとを備えたプロキシ手段とを有することを特徴とする。
【００２１】
請求項２に記載の発明は、請求項１に記載の情報処理装置において、プロキシ手段は、上位モジュールからの指定される応答の形式が開発言語により定義された型の場合には、情報提供手段からの応答を、指定された形式に変換して上位モジュールへ返信する第１のプロキシ手段と、上位モジュールからの指定される応答の形式がＸＭＬ形式の場合には、情報提供手段からの応答を、ＸＭＬ形式のまま上位モジュールへ返信する第２のプロキシ手段と、を有することを特徴とする。
【００２２】
請求項３に記載の発明は、請求項１又は２に記載の情報処理装置において、受付手段のインタフェースは、第１のプロキシ手段と第２のプロキシ手段とが共通して利用可能であることを特徴とする。
【００２３】
請求項４に記載の発明は、請求項１から３のいずれか１項に記載の情報処理装置において、応答を受信する受信手段は、第１のプロキシ手段と第２のプロキシ手段とのうち、少なくともいずれか一方を選択して受信することを特徴とする。
【００２４】
請求項５に記載の発明は、上位モジュールから、情報提供手段への呼出要求を受け付ける受付処理と、呼出要求に含まれる情報提供手段からの応答の形式を指定するメソッドを解析する解析処理と、応答を上位モジュールが指定した形式に変換して上位モジュールに返信するインタフェースと、応答をＸＭＬ形式のまま上位モジュールに返信するインタフェースとを備えたプロキシ処理と、をコンピュータに実行させることを特徴とするプログラムである。
【００２５】
請求項６に記載の発明は、請求項５に記載のプログラムを記録したコンピュータが読取可能な記録媒体であることを特徴とする。
【発明の効果】
【００２６】
このように、本発明の情報処理装置、プログラム及び記録媒体によれば、Proxyの利用を効率よく選択的に行うことができる。
【発明を実施するための最良の形態】
【００２７】
以下に、本実施形態の情報処理装置を、図面を用いて説明する。なお、本実施形態は以下に述べるものに限定されず、その趣旨を逸脱しない範囲において種々変更が可能である。また、本実施形態では、クライアント装置側のモジュール（Proxyも含む）は、基本的にJava（登録商標）で設計されているものとする。
【００２８】
図１は、本実施形態におけるクライアント装置１と、サービス提供装置３，４，５とがネットワーク２を介して接続されているハードウェア構成を示すブロック図である。
【００２９】
クライアント装置１は、ＣＰＵ１１と、ＲＯＭ１２と、ＲＡＭ１３と、ＨＤＤ１４と、ネットワークインタフェース（Ｉ／Ｆ）１５と、ドライブ装置１６とを備えており、これらがシステムバスを介して接続されている。
【００３０】
そして、ＨＤＤ１４に種々のアプリケーションプログラムをインストールして、ＣＰＵ１１に実行させることにより、様々な機能を果たすことが可能となる。なお、ＨＤＤ１４に種々のアプリケーションプログラムをインストールする際には、記憶媒体１７を用いて、ドライブ装置１６経由で行うことも可能である。また、各サービス提供装置３，４，５も、クライアント装置１と同様のハードウェア構成を備えている。
【００３１】
図２は、本実施形態のクライアント装置１と、サービス提供装置３とのソフトウェア構成を示すブロック図である。
【００３２】
まず、クライアント装置１は、WS Client Apl４０１と、Proxy Emulator４０２と、を備えている。WS Client Apl４０１は、サービス提供装置側のCore Module５０３に対して呼出要求を行うＷｅｂサービスのクライアントとして機能し、Core Module５０３の呼び出しに関する判別処理を行う。
【００３３】
Proxy Emulator４０２は、WS Client Apl４０１からの呼出要求に対して、WS Proxyを介さずに、サービス提供装置３とのリクエスト送信・レスポンス受信を行う。これにより、Proxy無しでＷｅｂサービスを利用した際と同じく、ＸＭＬ形式での結果の取得が可能であるが、Ｗｅｂサービスの呼び出し時においてのＸＭＬ構築という煩雑な処理を隠蔽している。
【００３４】
サービス提供装置３は、WS Listener５０１と、Web Service５０２と、Core Module５０３と、を備えている。WS Listener５０１は、ＳＯＡＰメッセージを受信したときパージングを行い、下位モジュールが扱える形に型変換を行う。Web Service５０２は、対応するコアモジュールの機能を外部に公開するための手段として存在する。Core Module５０３は、クライアントモジュールからの呼出要求に対して所定のメソッドを行うメインロジックを実装し、その実行結果を上位モジュールに返すサービス提供手段としての機能を有する。
【００３５】
次に、本実施形態の処理動作について説明する。
【００３６】
クライアント装置１のWS Client Apl４０１は、サービス提供要求のコマンドに基づき、呼出対象となるCore Moduleの呼出処理を開始する。この呼出処理は、Proxy I/FのようなJava（登録商標） Typeを用いたＩ／Ｆを用いる。ここで呼び出されるメソッドは、例えば、get Data( )by javaや、get Data( )by xmlなどであり、このメソッドの( )の中に、例えば、get Data(abc)by javaや、get Data(abc)by xmlなどの、取得したい値が引数として指定されることになる。
【００３７】
ここで、get Data( )by javaのように、Java（登録商標） Type用のメソッドが呼び出された場合には、Proxy Emulator４０２がこのメソッドを受け付けると、サービス提供装置３へ呼出要求（リクエストの送信）を行う。なお、シリアライズはProxy Emulator４０２の内部で行われ、このシリアライズの手順は、通常のプロキシのものと同様である。
【００３８】
リクエストは、Java（登録商標） Type用のメソッドをリクエストＳＯＡＰエンベロープ（以下、SOAP-Envと称す）のbody要素にＸＭＬで記述された形式で格納したものであり、リクエスト自体は通常のＳＯＡＰメッセージである。この呼出要求に対し、サービス提供装置３のCore Module５０３で所定のメソッドが行われ、その結果が、レスポンスSOAP-Envのbody要素にＸＭＬで記述された形式で格納されて戻ってくる。
【００３９】
すると、Proxy Emulator４０２が直接レスポンスSOAP-Envを受信する。そして、レスポンスSOAP-Envに格納されている戻り値を記述したＸＭＬを取り出して、ＸＭＬ形式のままでWS Client Apl４０１に渡され、このデータから、WS Client Apl４０１はＨＴＭＬを生成してＷｅｂブラウザに送信することになる。
【００４０】
このように、本実施形態によれば、Ｗｅｂサービスの呼び出し時においてのＸＭＬ構築という煩雑な処理を隠蔽したまま、Proxy無しでＷｅｂサービスを利用した際と同じく、ＸＭＬ形式での結果の取得が可能となる。
【００４１】
さらに、本実施形態のクライアント装置１とサービス提供装置３とにおいて、クライアント装置１側に、WS Proxyが実装された場合を、図面を用いて説明する。
【００４２】
図３は、クライアント装置１側に、WS Proxy６０３が実装された場合におけるクライアント装置１とサービス提供装置３との構成を示すブロック図である。
【００４３】
クライアント装置１は、WS Client Apl６０１と、Proxy Emulator６０２と、WS Proxy６０３と、を備えている。WS Client Apl６０１は、サービス提供装置側のCore Module７０３に対して呼出要求を行うＷｅｂサービスのクライアントとして機能し、Core Module７０３の呼び出しに関する判別処理を行う。
【００４４】
Proxy Emulator６０２は、WS Client Apl６０１からの呼出要求に対して、Java（登録商標） Type用のメソッドが呼び出されたかどうかの判別を行う。詳しくは後述するが、Java（登録商標） Type用のメソッドが呼び出された場合には、WS Proxy６０３を経由してサービス提供装置３とのリクエスト送信・レスポンス受信を行う。一方、呼び出されたメソッドがJava（登録商標） Type用のものではない場合には、WS Proxy６０３を介さずにサービス提供装置３とのリクエスト送信・レスポンス受信を行う。これにより、Proxy無しでＷｅｂサービスを利用した際と同じく、ＸＭＬ形式での結果の取得が可能であるが、Ｗｅｂサービスの呼び出し時においてのＸＭＬ構築という煩雑な処理を隠蔽している。ちなみに、このProxy Emulator６０２は、WS Proxy６０３と同じＩ／Ｆを持っているので、上位モジュール（ここではWS Client Apl６０１）は、どちらを呼び出しているかの意識はない。そのため、公開されているメソッドをProxy Emulator６０２に対してもそのまま流用することが可能となっている。
【００４５】
WS Proxy６０３は、ＷＳＤＬ（Web Service Description Language）から自動生成されるものであり、クライアントモジュールがコアモジュールを利用するためのＡＰＩ（Application Program Interface）を備えている。また、外部装置となるサービス提供装置３との接続処理を行うときには、WS Client Apl６０１からの呼出要求を、ＳＯＡＰメッセージとしてサービス提供装置３に送信する。
【００４６】
次に、サービス提供装置３は、WS Listener７０１と、Web Service７０２と、Core Module７０３と、を備えている。WS Listener７０１は、ＳＯＡＰメッセージを受信したときパージングを行い、下位モジュールが扱える形に型変換を行う。Web Service７０２は、対応するコアモジュールの機能を外部に公開するための手段として存在する。Core Module７０３は、クライアントモジュールからの呼出要求に対して所定のメソッドを行うメインロジックを実装し、その実行結果を上位モジュールに返すサービス提供手段としての機能を有する。
【００４７】
次に、本実施形態の処理動作について、図３及び図４を参照しながら説明する。図４は、本実施形態の動作を示すフローチャートである。
【００４８】
まず、クライアント装置１のWS Client Apl６０１は、サービス提供要求のコマンドに基づき、呼出対象となるCore Moduleの呼出処理を開始する（ステップＳ１００１）。この呼出処理をProxy Emulator６０２が受け付けると、Java（登録商標） Type用のメソッドが呼び出されたかどうかの判別を行う（ステップＳ１００２）。Proxy Emulator６０２が対応するこのメソッドは、例えば、get Data( )by javaや、get Data( )by xmlなどであり、このメソッドの( )の中に、例えば、get Data(abc)by javaや、get Data(abc)by xmlなどの、取得したい値が引数として指定されることになる。
【００４９】
ここで、get Data( )by javaのように、Java（登録商標） Type用のメソッドが呼び出された場合には（ステップＳ１００２／Ｙｅｓ）、WS Proxy６０３を経由してサービス提供装置３へ、呼出要求（リクエストの送信）を行う（ステップＳ１００３）。この際に行われるシリアライズの手順は、通常のプロキシのものと同様である。
【００５０】
リクエストは、Java（登録商標） Type用のメソッドをリクエストSOAP-Envのbody要素にＸＭＬで記述された形式で格納したものであり、リクエスト自体は通常のＳＯＡＰメッセージである。この呼出要求に対し、サービス提供装置３のCore Module７０３で所定のメソッドが行われ、その結果が、レスポンスSOAP-Envのbody要素にＸＭＬで記述された形式で格納されて戻ってくる（ステップＳ１００５）。
【００５１】
このとき、リクエスト時に呼び出されたメソッドがJava（登録商標） Type用のメソッドであれば（ステップＳ１００６／Ｙｅｓ）、WS Proxy６０３を経由してレスポンスSOAP-Envを受信する。（ステップＳ１００７）そして、レスポンスSOAP-Envに格納されている戻り値を記述したＸＭＬを取り出して、Java（登録商標） Typeに変換する。
【００５２】
このようにして受信したデータは、Java（登録商標） TypeでWS Client Apl６０１に渡され（ステップＳ１００８）、このデータから、WS Client Apl６０１はＨＴＭＬを生成してＷｅｂブラウザに送信することになる。
【００５３】
一方、呼び出されたメソッドがJava（登録商標） Type用のものではない場合には（ステップＳ１００２／Ｎｏ）、Proxy Emulator６０２は、WS Proxy６０３を介さずにサービス提供装置３とのリクエスト送信を行う（ステップＳ１００４）。この場合には、Proxy Emulator６０２内部において、WS Proxy６０３と同様にシリアライズを行うことになる。ちなみに、Proxy Emulator６０２内部でのシリアライズの手順は、通常のプロキシと同様である。
【００５４】
リクエストは、Java（登録商標） Type用のものではないメソッドをリクエストSOAP-Envのbody要素にＸＭＬで記述された形式で格納したものであり、リクエスト自体は通常のＳＯＡＰメッセージである。この呼出要求に対し、サービス提供装置３のCore Module７０３で所定のメソッドが行われ、その結果が、レスポンスSOAP-Envのbody要素にＸＭＬで記述された形式で格納されて戻ってくる（ステップＳ１００５）。
【００５５】
このとき、リクエスト時に呼び出されたメソッドがJava（登録商標） Type用のメソッドでなければ（ステップＳ１００６／Ｎｏ）、Proxy Emulator６０２が直接レスポンスSOAP-Envを受信する（ステップＳ１００９）。そして、レスポンスSOAP-Envに格納されている戻り値を記述したＸＭＬを取り出して、ＸＭＬ形式のままでWS Client Apl６０１に渡され（ステップＳ１０１０）、このデータから、WS Client Apl６０１はＨＴＭＬを生成してＷｅｂブラウザに送信することになる。
【００５６】
このように本実施形態によれば、Ｗｅｂサービスからの戻り値の形式をＸＭＬとJava（登録商標） Typeのいずれかから選択することが可能となる。なお、どちらの形式を使用するかは、予めシステム全体として設定しておいても良いし、WS Client Apl６０１内での使い方を考慮してオペレーションごとに設定してもよい。
【図面の簡単な説明】
【００５７】
【図１】本実施形態におけるクライアント装置１と、サービス提供装置３，４，５とがネットワーク２を介して接続されるハードウェア構成を示すブロック図である。
【図２】本実施形態におけるクライアント装置１と、サービス提供装置３とのソフトウェア構成を示すブロック図である。
【図３】本実施形態におけるクライアント装置１にWS Proxyを実装した場合の、クライアント装置１とサービス提供装置３とのソフトウェア構成を示すブロック図である。
【図４】図５における本実施形態の処理動作を示すフローチャートである。
【図５】従来のＷｅｂサービスのシステム構成を示す図である。
【図６】従来のＷｅｂサービスのシステムにおいての情報の授受を示す図である。
【符号の説明】
【００５８】
１    クライアント装置
２    ネットワーク
３，４，５    サービス提供装置
１１、３１    ＣＰＵ
１２、３２    ＲＯＭ
１３、３３    ＲＡＭ
１４、３４    ＨＤＤ
１５、３５    ネットワークＩ／Ｆ
１６、３６    ドライブ装置
１７、３７    記憶媒体
【図１】
2006260220.tif 000003
【図２】
2006260220.tif 000004
【図３】
2006260220.tif 000005
【図４】
2006260220.tif 000006
【図５】
2006260220.tif 000007
【図６】
2006260220.tif 000008