(57)【要約】  【課題】  ＥＡＩにおける所定のシステム間でやり取りされるデータ量の変化に応じて、通信トラフィックの自動最適化を実現する。  【解決手段】  複数のアプリケーションサーバ１０と統合サーバ２０とがネットワークで接続されたシステムにおいて、第一アプリケーションサーバ１０は、アプリケーション実行部１１からデータを取得し、このデータの量に関する情報を付加して統合サーバ２０へ送信する第一アダプタ１２を備える。統合サーバ２０は、複数のアプリケーションサーバ１０によって連携して行われる作業に応じて受信したデータの送信先アプリケーションサーバ１０を決定し送信する。第二アプリケーションサーバ１０は、統合サーバ２０から受信したデータをアプリケーション実行部１１に渡す第二アダプタ１２を備える。そして、第二アプリケーションサーバ１０は、受信したデータに付加されているデータの量に関する情報に基づいて、自身の処理能力を変更する。  【選択図】  図３
2006092212.tif 000002
【特許請求の範囲】
【請求項１】
少なくとも第一及び第二のアプリケーションサーバを含む複数のアプリケーションサーバと統合サーバとがネットワークで接続されたシステムにおいて、
前記第一アプリケーションサーバは、
第一アプリケーションに基づき第一処理を実行する第一アプリケーション実行部と、
前記第一アプリケーション実行部から第一処理済のデータを取得し、当該データの量に関する情報を付加して前記統合サーバへ送信する第一アダプタとを備え、
前記統合サーバは、
前記複数のアプリケーションサーバとの間でデータの送受信を行う送受信部と、
前記複数のアプリケーションサーバによって連携して行われる作業に応じて受信したデータの送信先アプリケーションサーバを決定する統合処理部とを備え、
前記第二アプリケーションサーバは、
第二アプリケーションに基づき第二処理を実行する第二アプリケーション実行部と、
前記統合サーバから受信したデータを前記第二アプリケーション実行部に渡す第二アダプタとを備え、
当該データに付加されている当該データの量に関する情報に基づいて、第二アプリケーションサーバの処理能力を変更するデータ処理システム。
【請求項２】
前記第一アダプタは、前記第一処理済のデータをパケットに変換し、当該パケットに、前記データの量に関する情報として後続するパケットの数を示す後続パケット数を付加する請求項１に記載のデータ処理システム。
【請求項３】
前記第二アプリケーションサーバは、受信したパケットに付加されている前記後続パケット数の値が一定以上である場合に、自身の処理能力を高い状態に変更する請求項２に記載のデータ処理システム。
【請求項４】
前記第二アプリケーションサーバは、前記後続パケット数の値が一定以下であるパケットを、一定個数だけ連続して受信した場合に、自身の処理能力を低い状態に変更する請求項２に記載のデータ処理システム。
【請求項５】
前記第二アプリケーションサーバは、予め規定された受信サイクル数分の受信パケットのうち、前記後続パケット数の値が一定以上であるパケットの数、または前記後続パケット数の値が一定以下であるパケットの数に応じて、自身の処理能力を変更する請求項２に記載のデータ処理システム。
【請求項６】
前記第二アダプタ及び／又は前記第二アプリケーション実行部は、前記データに付加されている前記データの量に関する情報に基づいて、自身の処理能力を変更する請求項１に記載のデータ処理システム。
【請求項７】
前記第二アダプタは、受信エージェントであり、前記データに付加されている前記データの量に関する情報に基づいて、自身の処理能力を自律的に変更する請求項１に記載のデータ処理システム。
【請求項８】
前記第一アダプタは、付加するデータの量に関する情報に基づいて、自身の処理能力を変更する請求項１に記載のデータ処理システム。
【請求項９】
前記第一アダプタは、送信エージェントであり、付加するデータの量に関する情報に基づいて、自身の処理能力を自律的に変更する請求項１に記載のデータ処理システム。
【請求項１０】
前記統合サーバは、前記データに付加されている当該データの量に関する情報に基づいて、統合サーバの処理能力を変更する請求項１に記載のデータ処理システム。
【請求項１１】
前記第二アダプタは、前記第二アプリケーション実行部から第二処理済のデータを取得し、当該データの量に関する情報を付加して前記統合サーバへ送信し、
前記第一アダプタは、前記統合サーバから受信したデータを前記第二アプリケーション実行部に渡し、
前記第一アプリケーションサーバは、当該データに付加されている当該データの量に関する情報に基づいて、第一アプリケーションサーバの処理能力を変更する請求項１に記載のデータ処理システム。
【請求項１２】
前記複数のアプリケーションサーバは、前記統合サーバをハブとし、各アプリケーションサーバをスポークとするハブ・アンド・スポーク型ネットワークで接続される請求項１に記載のデータ処理システム。
【請求項１３】
前記第一アプリケーションに基づいて第一処理可能なデータの第一データ形式と、前記第二アプリケーションに基づいて第二処理可能なデータの第二データ形式とが異なり、
前記統合サーバは、受信したデータの形式を第一データ形式から中間データ形式へ変換して前記統合処理部へ渡し、前記統合処理部から受け取ったデータの形式を中間データ形式から第二データ形式に変換して前記送受信部へ渡すデータ変換部を備える
請求項１に記載のデータ処理システム。
【請求項１４】
前記複数のアプリケーションサーバは第三アプリケーションサーバを含み、
当該第三アプリケーションサーバは、
第三アプリケーションに基づき第三処理を実行する第三アプリケーション実行部と、
前記第三アプリケーション実行部から第三処理済のデータを取得し、当該データの量に関する情報を付加して前記統合サーバへ送信する第三アダプタとを備え、
前記第二アプリケーションサーバは、第一アプリケーションサーバから送信されたデータに付加されている当該データの量に関する情報と第三アプリケーションサーバから送信されたデータに付加されている当該データの量に関する情報とに基づいて、第二アプリケーションサーバの処理能力を変更する請求項１に記載のデータ処理システム。
【請求項１５】
少なくとも第一及び第二のアプリケーションサーバを含む複数のアプリケーションサーバがネットワークで接続されたシステムにおいて、
前記第一アプリケーションサーバは、
第一アプリケーションに基づき第一処理を実行する第一アプリケーション実行部と、
前記第一アプリケーション実行部から第一処理済のデータを取得し、当該データの量に関する情報を付加して前記第二アプリケーションサーバへ送信する第一アダプタとを備え、
前記第二アプリケーションサーバは、
第二アプリケーションに基づき第二処理を実行する第二アプリケーション実行部と、
前記第一アプリケーションサーバから受信したデータを前記第二アプリケーション実行部に渡す第二アダプタとを備え、当該データに付加されている当該データの量に関する情報に基づいて、第二アプリケーションサーバの処理能力を変更する
データ処理システム。
【請求項１６】
少なくとも第一及び第二のアプリケーションサーバを含む複数のアプリケーションサーバと統合サーバとがネットワークで接続されたシステムに適用されるデータ処理方法であり、
前記第一アプリケーションサーバで実行される、
第一アプリケーションに基づき第一処理を実行する第一アプリケーション実行ステップと、
前記第一処理済のデータを取得し、当該データの量に関する情報を付加して前記統合サーバへ送信する第一送信ステップと、
前記統合サーバで実行される、
前記第一アプリケーションサーバからのデータを受信する第一受信ステップと、
前記複数のアプリケーションサーバによって連携して行われる作業に応じて受信したデータの送信先アプリケーションサーバを決定する統合処理ステップと、
送信先アプリケーションサーバへデータを送信する第二送信ステップと、
前記第二アプリケーションサーバで実行される、
前記統合サーバからのデータを受信する第二受信ステップと、
受信したデータに付加されている当該データの量に関する情報に基づいて、第二アプリケーションサーバの処理能力を変更する第二能力変更ステップと、
第二アプリケーションに基づき第二処理を実行する第二アプリケーション実行ステップと、
を備えるデータ処理方法。
【請求項１７】
前記第一送信ステップは、
前記第一処理済のデータをパケットに変換するサブステップと、
当該パケットに、前記データの量に関する情報として後続するパケットの数を示す後続パケット数を付加するサブステップと
を備える請求項１６に記載のデータ処理方法。
【請求項１８】
前記第二能力変更ステップは、受信したパケットに付加されている前記後続パケット数の値が一定以上である場合に、第二アプリケーションサーバの処理能力を高い状態に変更する請求項１７に記載のデータ処理方法。
【請求項１９】
前記第二能力変更ステップは、前記後続パケット数の値が一定以下であるパケットを、一定個数だけ連続して受信した場合に、第二アプリケーションサーバの処理能力を低い状態に変更する請求項１７に記載のデータ処理方法。
【請求項２０】
前記第二能力変更ステップは、予め規定された受信サイクル数分の受信パケットのうち、前記後続パケット数の値が一定以上であるパケットの数、または前記後続パケット数の値が一定以下であるパケットの数に応じて、第二アプリケーションサーバの処理能力を変更する請求項１７に記載のデータ処理方法。
【請求項２１】
前記第二能力変更ステップは、前記データに付加されている前記データの量に関する情報に基づいて、前記第二受信ステップ及び／又は前記第二アプリケーション実行ステップの処理能力を変更する請求項１６に記載のデータ処理方法。
【請求項２２】
付加するデータの量に関する情報に基づいて第一送信ステップの処理能力を変更する第一能力変更ステップを
さらに備える請求項１６に記載のデータ処理方法。
【請求項２３】
前記データに付加されている前記データの量に関する情報に基づいて、前記第一受信ステップ、前記統合処理ステップ、前記第二送信ステップのうち少なくとも一つの処理能力を変更する統合能力変更ステップを
さらに備える請求項１６に記載のデータ処理方法。
【請求項２４】
前記複数のアプリケーションサーバは、前記統合サーバをハブとし、各アプリケーションサーバをスポークとするハブ・アンド・スポーク型ネットワークで接続される請求項１６に記載のデータ処理方法。
【請求項２５】
前記第一アプリケーションに基づいて第一データ処理可能なデータの第一データ形式と、前記第二アプリケーションに基づいて第二データ処理可能なデータの第二データ形式とが異なり、
前記統合サーバで実行される、
前記第一受信ステップの後、かつ前記統合処理ステップの前に、受信したデータの形式を第一データ形式から中間データ形式へ変換する第一変換ステップと、
前記統合処理ステップの後、かつ前記第二送信ステップの前に、送信先が決定されたデータの形式を中間データ形式から第二データ形式に変換する第二変換ステップと
を備える請求項１６に記載のデータ処理方法。
【請求項２６】
前記複数のアプリケーションサーバは第三アプリケーションサーバを含み、
当該第三アプリケーションサーバで実行される、
第三アプリケーションに基づき第三処理を実行する第三アプリケーション実行ステップと、
前記第三処理済のデータを取得し、当該データの量に関する情報を付加して前記統合サーバへ送信する第三送信ステップとを備え、
前記第二能力変更ステップは、第一アプリケーションサーバから送信されたデータに付加されている当該データの量に関する情報と第三アプリケーションサーバから送信されたデータに付加されている当該データの量に関する情報とに基づいて、第二アプリケーションサーバの処理能力を変更する請求項１６に記載のデータ処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＥＡＩを実現するネットワークシステムに関し、特にネットワークにおける通信トラフィックの変化に対応するための通信制御方法に関する。
【背景技術】
【０００２】
種々のコンピュータシステムを連携させ、統合的に利用可能とするＥＡＩ（Enterprise Application Integration）では、統合サーバを中心に、各コンピュータシステムがハブ・アンド・スポーク型の接続関係を構築する（例えば、特許文献１、非特許文献１参照）。図９に示すように、ＥＡＩで統合されるコンピュータシステムである各アプリケーションサーバ９１０は、統合サーバ９２０（ハブ）に接続するためのアダプタ（インターフェイス）９１１を備える。そして、このアダプタ９１１を介して統合サーバ９２０に接続するだけで、同様に統合サーバ９２０に接続された他のアプリケーションサーバ９１０との連携が可能となる。
【０００３】
ＥＡＩでは、所定のアプリケーションサーバ９１０から統合サーバ９２０へデータ（制御信号や実データを含む）が送信されると、統合サーバ９２０において、連携して行われる業務の内容等に応じて送信先のアプリケーションサーバ９１０が特定され、特定された送信先のアプリケーションサーバ９１０に、このデータが送信される（以下、この統合サーバによるデータの送信制御の処理を統合処理と呼ぶ）。業務の内容によっては、１つのデータが、複数のアプリケーションサーバ９１０に振り分けられて配信される場合もあるし、また反対に、複数のアプリケーションサーバ９１０から送信されたデータが、これらのデータを用いた業務処理が実行される単一のアプリケーションサーバ９１０に送信される場合もある。
【０００４】
このようなＥＡＩを構成する各アプリケーションサーバ９１０では、通常、データを送信するためのアダプタ９１１は、データ送受信の処理速度が固定的である。したがって、所定のアプリケーションサーバ９１０間でやり取りされるデータ量が不規則あるいは単発的に増加した場合、各アプリケーションサーバ９１０のアダプタ９１１による送受信処理や統合サーバ９２０による統合処理がこの通信トラフィックの変化に追随できず、処理に長時間を要することとなる。ＥＡＩを構成する各アプリケーションサーバ９１０間のどの経路でどの程度のトラフィックの変化が生じるかを知るため、従来は、実稼働状態のＥＡＩシステムを監視することが行われる。そして、得られた監視情報が、別のＥＡＩシステムの設計時に反映されることとなる。
【０００５】
また従来、所定のアプリケーションサーバ９１０間に統合サーバ９２０を介さないバイパスとなる回線を設けておき、このアプリケーションサーバ９１０間でやり取りされるデータ量が増大した場合、統合サーバ９２０を介して制御信号のみを送信し、実データはバイパスにより統合サーバ９２０を介さないで送信するといったシステムが提案されている（例えば、特許文献２参照）。
【０００６】
【特許文献１】特表２００２−５０７０１７号公報
【特許文献２】特開２００３−６７３５６号公報
【非特許文献１】“テクニカル入門”IBM CrossWorlds  コア・トピック  CrossWorlds概要、[online]、２００２年６月、日本アイ・ビー・エム株式会社、［平成１６年７月２８日検索］、インターネット＜ＵＲＬ：http://www-306.ibm.com/software/websphere/crossworlds/library/doc/v411_ja_JP/welcome.html＞
【発明の開示】
【発明が解決しようとする課題】
【０００７】
上述したように、ＥＡＩでは、所定のシステム間でやり取りされるデータ量が増大した場合に、そのデータ送受信を含む処理の実行に長時間を要し、作業効率の低下を招いてしまう。ＥＡＩを構成する各アプリケーションサーバ間のどの経路でどの程度のトラフィックの変化が生じるかを知るためには、実際にシステムを運用して動作状態を監視することが必要である。そのため、トラフィックが増大する経路を事前に予測して処理能力を十分に高く取るような設計を行うことは困難である。また、不規則に発生するトラフィックの変化に対して柔軟に対応することも難しい。予めトラフィックの増大を想定してＥＡＩの全てのシステムやネットワークの処理能力を高くとっておくことも考えられるが、この方策は、データ通信のために常に多くのリソースを割り当てることになるため、リソース管理の観点からは好ましくない。
【０００８】
システム間でやり取りされるデータ量が増大した場合に実データをバイパスさせる従来技術は、ＥＡＩのシステム群全体の大がかりな設計変更を要し、導入が容易ではなく、またコストも増大する。さらに、特定のシステム間に対して予めバイパスを設けるため、トラフィックの変化が増大されるルートに対してしか対応できず、不特定のシステム間のデータ送受信におけるトラフィックの変化に対して柔軟に対応することができない。
【０００９】
そこで本発明は、ＥＡＩにおける所定のシステム間でやり取りされるデータ量が変化する場合に、このデータ送受信に関わる各システムの処理能力を動的に調整して対応し、通信トラフィックの自動最適化することが可能なシステムおよびその方法を提供することを目的とする。
また本発明は、上記のシステムを、ＥＡＩを構成する各システムにおいて容易に導入可能な仕組みにより実現することを他の目的とする。
【課題を解決するための手段】
【００１０】
上記の目的を達成するため、本発明は、次のようなシステムとして実現される。このシステムは、少なくとも第一及び第二のアプリケーションサーバを含む複数のアプリケーションサーバと統合サーバとがネットワークで接続されて構成される。そして、送信側端末である第一アプリケーションサーバは、第一アプリケーションに基づき第一処理を実行する第一アプリケーション実行部と、この第一アプリケーション実行部から第一処理済のデータを取得し、このデータの量に関する情報を付加して統合サーバへ送信する第一アダプタとを備える。統合サーバは、複数のアプリケーションサーバとの間でデータの送受信を行う送受信部と、複数のアプリケーションサーバによって連携して行われる作業に応じて受信したデータの送信先アプリケーションサーバを決定する統合処理部とを備える。受信側端末である第二アプリケーションサーバは、第二アプリケーションに基づき第二処理を実行する第二アプリケーション実行部と、統合サーバから受信したデータを第二アプリケーション実行部に渡す第二アダプタとを備える。そして、第二アプリケーションサーバは、受信したデータに付加されている当該データの量に関する情報に基づいて、自身の処理能力を変更する。
【００１１】
ここで、第一アダプタは、より詳細には、第一処理済のデータをパケットであるビジネスオブジェクトに変換し、このパケット（ビジネスオブジェクト）に、データの量に関する情報として後続するパケットの数を示す後続パケット数を付加する。また、第一アダプタは、送信エージェントであり、パケットに付加する後続パケット数の値が一定以上である場合に、データ送信に関する自身の処理能力を自立的に高い状態に変更する。
【００１２】
一方、第二アプリケーションサーバは、より詳細には、受信したパケットに付加されている後続パケット数の値が一定以上である場合に、自身の処理能力を高い状態に変更する。また、後続パケット数の値が一定以下であるパケットを、一定個数だけ連続して受信した場合に、自身の処理能力を低い状態に変更する。あるいは、受信エージェントとして機能するこのアダプタは、予め規定された受信サイクル数分の受信パケットのうち、後続パケット数の値が一定以上であるパケットの数、または後続パケット数の値が一定以下であるパケットの数に応じて、自身の処理能力を変更する。
【００１３】
さらに、第二アダプタ及び／又は第二アプリケーション実行部は、受信したデータに付加されている当該データの量に関する情報に基づいて、自身の処理能力を変更する。また、第二アダプタは、受信エージェントであり、データに付加されているデータの量に関する情報に基づいて、自身の処理能力を自律的に変更する。
また、統合サーバは、データに付加されている当該データの量に関する情報に基づいて、統合サーバの処理能力を変更する。
【００１４】
なお、第一アプリケーションサーバを送信側とし、第二アプリケーションサーバを受信側としたのは、システムにおける役割を示したものであり、連携して行われる作業の内容等によっては、第二アプリケーションサーバが送信側、第一アプリケーションサーバが受信側となり得る。この場合、第二アダプタは、第二アプリケーション実行部から第二処理済のデータを取得し、このデータの量に関する情報を付加して統合サーバへ送信し、第一アダプタは、統合サーバから受信したデータを第二アプリケーション実行部に渡し、第一アプリケーションサーバは、受信したデータに付加されている当該データの量に関する情報に基づいて、第一アプリケーションサーバの処理能力を変更する。
【００１５】
このシステムにおいて、第一アプリケーションに基づいて第一処理可能なデータの第一データ形式と、第二アプリケーションに基づいて第二処理可能なデータの第二データ形式とが異なっていても良い。この場合、統合サーバは、受信したデータの形式を第一データ形式から中間データ形式へ変換して統合処理部へ渡し、統合処理部から受け取ったデータの形式を中間データ形式から第二データ形式に変換して送受信部へ渡すデータ変換部を備える。
【００１６】
また、このシステムは、上記の第一、第二のアプリケーションサーバに加えて、第三アプリケーションサーバを含む構成とすることもできる。この第三アプリケーションサーバは、第三アプリケーションに基づき第三処理を実行する第三アプリケーション実行部と、第三アプリケーション実行部から第三処理済のデータを取得し、このデータの量に関する情報を付加して統合サーバへ送信する第三アダプタとを備える。そして、第二アプリケーションサーバは、第一アプリケーションサーバから送信されたデータに付加されている当該データの量に関する情報と第三アプリケーションサーバから送信されたデータに付加されている当該データの量に関する情報とに基づいて、第二アプリケーションサーバの処理能力を変更する。
【００１７】
また、上記の目的を達成する他の本発明は、少なくとも第一及び第二のアプリケーションサーバを含む複数のアプリケーションサーバと統合サーバとがネットワークで接続されたシステムに適用されるデータ処理方法としても実現される。この方法において、第一アプリケーションサーバは、第一アプリケーションに基づき第一処理を実行する第一アプリケーション実行ステップと、第一処理済のデータを取得し、このデータの量に関する情報を付加して統合サーバへ送信する第一送信ステップとを実行する。統合サーバは、第一アプリケーションサーバからのデータを受信する第一受信ステップと、複数のアプリケーションサーバによって連携して行われる作業に応じて受信したデータの送信先アプリケーションサーバを決定する統合処理ステップと、送信先アプリケーションサーバへデータを送信する第二送信ステップとを実行する。第二アプリケーションサーバは、統合サーバからのデータを受信する第二受信ステップと、受信したデータに付加されている当該データの量に関する情報に基づいて、第二アプリケーションサーバの処理能力を変更する第二能力変更ステップと、第二アプリケーションに基づき第二処理を実行する第二アプリケーション実行ステップとを実行する。
【発明の効果】
【００１８】
以上のように構成された本発明によれば、ＥＡＩにおける所定のアプリケーションサーバ間で送受信されるデータの量に基づき、必要に応じて各アプリケーションサーバにおけるアダプタ（受信エージェント）の処理能力を動的に調整することにより、ＥＡＩにおける通信トラフィックの自動最適化を行うことが可能となる。
【００１９】
また、本発明は、バイパスとなる回線を設けるといったハードウェア的な設計に影響を与えず、ソフトウェア的な設計のみで実現可能であるため、新規のＥＡＩシステムへの導入のみならず、既存のＥＡＩシステムに対しても導入が容易である。
【発明を実施するための最良の形態】
【００２０】
以下、添付図面を参照して、本発明を実施するための最良の形態（以下、実施形態）について詳細に説明する。
図１は、ＥＡＩの全体構成を概略的に示す図である。
図１に示すように、ＥＡＩは、複数のアプリケーションサーバ１０が統合サーバ２０を中心としてハブ・アンド・スポーク型に接続されて構成される。アプリケーションサーバ１０は、データの送受信手段であるアダプタを介して、統合サーバ２０にそれぞれ接続されている。そして、所定のアプリケーションサーバ１０から統合サーバ２０へ送信されたデータが、統合サーバ２０において特定される送信先へ転送されることにより、各アプリケーションサーバ１０の処理を連携させた作業を実行することができる。
【００２１】
図２は、図１のアプリケーションサーバ１０や統合サーバ２０として好適なコンピュータ装置のハードウェア構成の例を模式的に示した図である。
図２に示すコンピュータ装置は、演算手段であるＣＰＵ（Central Processing Unit：中央処理装置）１０１と、Ｍ／Ｂ（マザーボード）チップセット１０２およびＣＰＵバスを介してＣＰＵ１０１に接続されたメインメモリ１０３と、同じくＭ／Ｂチップセット１０２およびＡＧＰ（Accelerated Graphics Port）を介してＣＰＵ１０１に接続されたビデオカード１０４と、ＰＣＩ（Peripheral Component Interconnect）バスを介してＭ／Ｂチップセット１０２に接続された磁気ディスク装置（ＨＤＤ）１０５、ネットワークインターフェイス１０６と、さらにこのＰＣＩバスからブリッジ回路１０７およびＩＳＡ（Industry Standard Architecture）バスなどの低速なバスを介してＭ／Ｂチップセット１０２に接続されたフレキシブルディスクドライブ１０８およびキーボード／マウス１０９とを備える。
【００２２】
なお、図２は本実施形態を実現するコンピュータ装置のハードウェア構成を例示するに過ぎず、本実施形態を適用可能であれば、他の種々の構成を取ることができる。例えば、ビデオカード１０４を設ける代わりに、ビデオメモリのみを搭載し、ＣＰＵ１０１にてイメージデータを処理する構成としても良いし、外部記憶装置として、ＡＴＡ（AT Attachment）やＳＣＳＩ（Small Computer System Interface）などのインターフェイスを介してＣＤ−Ｒ（Compact Disc Recordable）やＤＶＤ−ＲＡＭ（Digital Versatile Disc Random Access Memory）のドライブを設けても良い。
【００２３】
図３は、アプリケーションサーバ１０と統合サーバ２０の機能構成を示す図である。
図３を参照すると、アプリケーションサーバ１０は、業務に関する各種の処理を実行するアプリケーション実行部１１と、統合サーバ２０に接続するためのアダプタ１２と、送信用データ蓄積部（キュー）１３および受信用データ蓄積部（キュー）１４とを備える。ここで、図３には、データを送信する送信側端末としてのアプリケーションサーバ１０と、統合サーバ２０から転送されたデータを受信する受信側端末としてのアプリケーションサーバ１０が記載されている。これら送信側と受信側のアプリケーションサーバ１０は同じ構成を備えており、送信側のアプリケーションサーバ１０ではアダプタ１２の送信機能が使用され、受信側のアプリケーションサーバ１０ではアダプタ１２の受信機能が使用されるに過ぎない。また図３において、送信側のアプリケーションサーバ１０に送信用データ蓄積部１３が記載され、受信側のアプリケーションサーバ１０に受信用データ蓄積部１４が記載されているが、これも送信側と受信側の立場に基づいて記載されたものであり、実際には各アプリケーションサーバ１０が送信用データ蓄積部１３と受信用データ蓄積部１４の両方を備える。したがって、ＥＡＩを構成する各アプリケーションサーバ１０が、連携して実行される作業に応じて、送信側端末としても受信側端末としても動作する。
【００２４】
アプリケーションサーバ１０のアプリケーション実行部１１は、例えば図２に示したコンピュータ装置にてアプリケーションサーバ１０が構成される場合、プログラム制御されたＣＰＵ１０１とメインメモリ１０３や磁気ディスク装置１０５等の記憶装置により実現される。このアプリケーション実行部１１は、アプリケーションプログラムの制御にしたがって、目的とする業務に応じた各種の処理機能やデータベース機能を備える。
【００２５】
アダプタ１２は、例えば図２のプログラム制御されたＣＰＵ１０１とメインメモリ１０３等の記憶装置、およびネットワークインターフェイス１０６により実現される。上述したように、このアダプタ１２は、データをアプリケーション実行部１１から取得して統合サーバ２０へ送信する送信機能と、統合サーバ２０からデータを受信してアプリケーション実行部１１に受け渡す受信機能とを備える。これらの機能を実現するため、アダプタ１２には、送信エージェント１２１と、受信エージェント１２２とが設けられる。図３の例では、送信側のアプリケーションサーバ１０に送信エージェント１２１が記載され、受信側のアプリケーションサーバ１０に受信エージェント１２２が記載されているが、上述した送信用データ蓄積部１３および受信用データ蓄積部１４の場合と同様に、実際にはいずれのアプリケーションサーバ１０のアダプタ１２にも、送信エージェント１２１および受信エージェント１２２の両方の機能が設けられる。
【００２６】
送信用データ蓄積部１３および受信用データ蓄積部１４は、たとえば図２のメインメモリ１０３やＣＰＵ１０１のキャッシュメモリ等で実現され、送受信されるデータを一時的に保持する。これにより、本実施形態では、ＭＱ（Message Queueing）による非同期な通信が可能となる。
【００２７】
送信エージェント１２１は、アプリケーション実行部１１から送信すべきデータを取得して、ビジネスオブジェクト（ＢＯ）の形式で送信用データ蓄積部１３に格納する。すなわち、本実施形態では、ビジネスオブジェクトをメッセージパケットとして、アプリケーションサーバ１０と統合サーバ２０との間のデータ通信が行われる。また、詳しくは後述するが、本実施形態の送信エージェント１２１は、送信すべきデータの量に応じて、処理能力を動的に調整する。ここで、送信エージェント１２１が生成するビジネスオブジェクトは、アプリケーションに特化したビジネスオブジェクトである。エージェントのタイプは、ポーリング型とトリガー型のいずれでも良い。ポーリング型のエージェントである場合、送信エージェント１２１は、一定期間ごとにアプリケーション実行部１１を監視し、送信すべきデータがあればこれを収集してビジネスオブジェクトを生成する。また、トリガー型のエージェントである場合、送信エージェント１２１は、アプリケーション実行部１１から送出されたデータを受け付けると、そのデータからビジネスオブジェクトを生成する。送信エージェント１２１により生成されたビジネスオブジェクトは、一旦、送信用データ蓄積部１３に格納された後、統合サーバ２０へ送信される。
【００２８】
受信エージェント１２２は、統合サーバ２０から受信して受信用データ蓄積部１４に格納されたビジネスオブジェクト（データ）を読み出し、アプリケーション実行部１１が使用するデータ形式に変換して、当該アプリケーション実行部１１に受け渡す。詳しくは後述するが、本実施形態の受信エージェント１２２は、受信されるデータの量に応じて、処理能力を動的に調整する。エージェントのタイプは、ポーリング型とトリガー型のいずれでも良い。ポーリング型のエージェントである場合、受信エージェント１２２は、一定期間ごとに受信用データ蓄積部１４を監視し、受信されたデータがあればこれを取り出してアプリケーション実行部１１に渡す。また、トリガー型のエージェントである場合、受信エージェント１２２は、受信用データ蓄積部１４にデータが格納されるたびにこれを取り出し、アプリケーション実行部１１に渡す。
【００２９】
また、図３を参照すると、統合サーバ２０は、送受信部２１と、データ変換部２２と、統合処理部２３とを備える。
送受信部２１は、例えば図２に示したコンピュータ装置にて統合サーバ２０が構成される場合、メインメモリ１０３等の記憶装置とネットワークインターフェイス１０６とで実現される。送受信部２１は、アプリケーションサーバ１０から受信したビジネスオブジェクト、およびアプリケーションサーバ１０に送信されるビジネスオブジェクトを、メインメモリ１０３等で実現されるキューに一時的に保持する。
【００３０】
データ変換部２２は、例えば図２のプログラム制御されたＣＰＵ１０１により実現される。このデータ変換部２２は、アプリケーションサーバ１０から受信されたビジネスオブジェクトを送受信部２１から読み出して、データマッピングにより、アプリケーションに特化した当該ビジネスオブジェクトから一般化されたビジネスオブジェクト（General Business Object、またはCanonical Data Modelとも呼ばれる。以下、ＧＢＯ）に変換し、統合処理部２３に渡す。また、統合処理部２３から送信すべきＧＢＯを受け付けて、データマッピングにより、送信先のアプリケーションサーバ１０におけるアプリケーションに特化したビジネスオブジェクトに変換し、送受信部２１に渡す。
【００３１】
統合処理部２３は、例えば図２のプログラム制御されたＣＰＵ１０１により実現される。この統合処理部２３は、アプリケーションサーバ１０から受信したデータのＧＢＯをデータ変換部２２から受け取り、このデータを用いた業務の内容等に応じてデータの送信先のアプリケーションサーバ１０を決定する。そして、このデータを、データ変換部２２および送受信部２１を介して送信先のアプリケーションサーバ１０へ送信する。上述したように、各アプリケーションサーバ１０のアプリケーション実行部１１は外部システムとのデータのやり取りをビジネスオブジェクトの形式で行うが、このビジネスオブジェクトは、各アプリケーション実行部１１におけるアプリケーションに特化した形式である。したがって、統合処理部２３では、これを統合的に処理するために、ＧＢＯという中間形式のデータフォーマットを用いる。
【００３２】
次に、上述したアダプタ１２の送信エージェント１２１および受信エージェント１２２における処理能力の動的な調整について説明する。
この処理能力の動的調整を実現するために、本実施形態では、所定のプロセスにおいてアプリケーション実行部１１からデータが送信される際に、送信されるデータ量の情報を送信データに付加する。具体的には、送信データはビジネスオブジェクト単位で送信されるので、送信される各ビジネスオブジェクトに、後続する未処理のビジネスオブジェクトの数（以下、未処理ＢＯ数と称す）を付加する。未処理ＢＯ数の付加は、ビジネスオブジェクトのＸＭＬファイルに付加情報用のフィールドを追加するだけで可能である。
【００３３】
本実施形態では、各アプリケーションサーバ１０が、ビジネスオブジェクトに付加された未処理ＢＯ数の情報から送受信されるデータの全体量を認識し、認識されたデータ量に応じて自身の処理能力を動的に調整する。以下、アダプタ１２の送信エージェント１２１および受信エージェント１２２による処理能力の動的調整の動作を説明する。
【００３４】
送信エージェント１２１は、アプリケーション実行部１１から送信データを取得してビジネスオブジェクトを生成する際に、そのプロセスにおける送信すべきデータの全体量に基づいて未処理ＢＯ数を計算し、生成したビジネスオブジェクトに付加して送信用データ蓄積部１３に格納する。また、未処理ＢＯ数が多い場合は、送信エージェント１２１自身の処理能力を上げて対応する。
【００３５】
図４は、送信エージェント１２１の動作を説明するフローチャートである。
図４を参照すると、送信エージェント１２１は、アプリケーション実行部１１から送信データを取得する際、まずアプリケーション実行部１１で実行されているプロセスからＳＱＬ（Structured Query Language）の「select count *」等を用いて未処理のデータ数を確認する（ステップ４０１）。当然ながら初期的には、未処理のデータ数は送信データの全体量に相当する。そして送信エージェント１２１は、未処理のデータ数が予め定められた閾値以下である場合、単に、送信データから未処理ＢＯ数が付加されたビジネスオブジェクトを生成して（ステップ４０２、４０５）、送信用データ蓄積部１３にエンキューする（ステップ４０６）。さらに送信エージェント１２１は、未処理の全てのデータに対して、ビジネスオブジェクトの生成および送信用データ蓄積部１３へのエンキューを繰り返して実行する（ステップ４０７）。未処理のデータがなくなったならば、送信用データ蓄積部１３は、アダプタ１２を初期化して処理を終了し（ステップ４０８）、次の送信データの発生を待つ。
【００３６】
一方、未処理のデータ数が予め定められた閾値よりも多い場合、送信エージェント１２１は、自身の処理能力を高い状態に変更し（ステップ４０２、４０３）、アダプタ１２のリブートを行う（ステップ４０４）。これによって、ステップ４０５以降の動作において、送信エージェント１２１は、通常状態よりも高い処理能力で動作することが可能となる。ここで、処理能力を高める方法としては、一度に扱うデータ量（処理単位）を増加する方法や、送信エージェント１２１がポーリング型のエージェントであればポーリング間隔を短くする方法などが考えられる。送信データを全て送信用データ蓄積部１３にエンキューした後は、アダプタ１２が初期化されるので（ステップ４０８）、送信エージェント１２１の処理能力は通常のレベルに戻る。送信すべきデータの量が多くない場合に送信エージェント１２１の処理能力を下げる（通常状態に戻す）ことにより、データ通信のために必要以上にリソースを割り当ててしまうことを防止することができる。
【００３７】
次に、受信エージェント１２２の動作について説明する。受信エージェント１２２は、受信されたビジネスオブジェクトをアプリケーション実行部１１に渡す際に、このビジネスオブジェクトに付加された未処理ＢＯ数を参照する。そして、未処理ＢＯ数の値が大きい場合（すなわち受信するデータ量が多い場合）は、受信エージェント１２２自身の処理能力を上げて対応する。
【００３８】
図５は、受信エージェント１２２の動作を説明するフローチャートである。
図５を参照すると、受信エージェント１２２は、統合サーバ２０からの受信データ（ビジネスオブジェクト）が受信用データ蓄積部１４に格納されると、先頭のビジネスオブジェクトを取り出して読み込み（ステップ５０１）、このビジネスオブジェクトに含まれる未処理ＢＯ数を調べる（ステップ５０２）。そして受信エージェント１２２は、未処理ＢＯ数が予め定められた閾値以下である場合に、単に、このビジネスオブジェクトを、アプリケーション実行部１１が使用するデータ形式に変換して、当該アプリケーション実行部１１に渡す（ステップ５０３、５０６）。
【００３９】
一方、ビジネスオブジェクトに記述された未処理ＢＯ数が予め定められた閾値よりも多い場合、受信エージェント１２２は、自身の処理能力を高い状態に変更し（ステップ５０３、５０４）、アダプタ１２のリブートを行う（ステップ５０５）。これにより、ステップ５０６におけるアプリケーション実行部１１へのデータの受け渡しにおいて、受信エージェント１２２は、通常状態よりも高い処理能力で動作することが可能となる。ここで、処理能力を高める方法としては、送信エージェント１２１の場合と同様に、一度に扱うデータ量（処理単位）を増加する方法や、受信エージェント１２２がポーリング型のエージェントであればポーリング間隔を短くする方法などが考えられる。
【００４０】
なお、図５に示す動作は、受信エージェント１２２の処理能力が通常状態である所定の時点での動作を示している。一度、通常状態よりも高い処理能力で動作する状態になった後は、その処理能力の高い状態でビジネスオブジェクトの取り出し、変換およびアプリケーション実行部１１への送信が行われるのであり、ステップ５０３の判定やステップ５０４、５０５の動作は行われない。
【００４１】
また、未処理ＢＯ数の値が小さい場合（受信するデータ量が少ない場合）に受信エージェント１２２の処理能力を下げる（通常状態に戻す）ことがリソース管理の観点から好ましいことは送信エージェント１２１の場合と同様である。しかし図５には、処理能力の高い状態に変更された後、通常状態に復帰する動作が記載されていない。受信エージェント１２２が処理能力の高い状態から通常状態に戻る条件としては、ビジネスオブジェクトから得られた未処理ＢＯ数が閾値以下であることだけでは足りない。
【００４２】
図６は、受信側のアプリケーションサーバ１０が、複数の送信側のアプリケーションサーバ１０から送信されたデータを同時に受信する様子を示している。図６において、送信側のアプリケーションサーバ１０ａは少量のデータを送信（低負荷状態）し、送信側のアプリケーションサーバ１０ｂは多量のデータを送信（高負荷状態）するものとする。すなわち、アプリケーションサーバ１０ａから送信されたビジネスオブジェクトの未処理ＢＯ数は小さく（閾値以下）、アプリケーションサーバ１０ｂから送信されたビジネスオブジェクトの未処理ＢＯ数は大きい（閾値を超える）。データはビジネスオブジェクト単位で送られてくるため、図６に示すように、アプリケーションサーバ１０ｂから送信されたビジネスオブジェクトの間にアプリケーションサーバ１０ａから送信されたビジネスオブジェクトが挿入された状態で受信側のアプリケーションサーバ１０ｃに届く場合がある。この場合、受信用データ蓄積部１４から取り出したビジネスオブジェクトごとに処理能力の切換を行うと、動作コストが大きくなり、かえって効率が悪くなる可能性がある。
【００４３】
そこで、本実施形態では、受信エージェント１２２の処理能力の切り換えにおける追従性を緩慢にし、例えば、未処理ＢＯ数が閾値以下であるビジネスオブジェクトを数個連続して受信した場合に、受信エージェント１２２の処理能力が高い状態から通常状態へ復帰するように設定する。このようにすれば、図６に示したように、未処理ＢＯ数が大きいビジネスオブジェクトと未処理ＢＯ数が小さいビジネスオブジェクトとが交互に受信された場合でも、頻繁に処理能力の切換を行って動作効率を低下させることを防止することができる。
【００４４】
図７は、上記の考え方に基づいた、処理能力を高い状態から通常状態へ復帰させる際の受信エージェント１２２の動作を説明するフローチャートである。
図７に示すように、受信エージェント１２２は、受信用データ蓄積部１４から取り出したビジネスオブジェクトの未処理ＢＯ数を調べ（ステップ７０１、７０２）、未処理ＢＯ数が閾値以下であれば、そのようなビジネスオブジェクトが予め規定された回数連続したか否かを判断する（ステップ７０３）。未処理ＢＯ数が閾値以下であるビジネスオブジェクトが規定回数連続したならば、受信エージェント１２２は、アダプタ１２を初期化する（ステップ７０４）。これにより、受信エージェント１２２の動作状態は通常状態に復帰する。
【００４５】
以上の動作のうち、ステップ７０２、７０３の判断は、受信用データ蓄積部１４から取り出されたビジネスオブジェクトの変換およびアプリケーション実行部１１への送信の動作と並列に行われ、ステップ７０４の動作は、ステップ７０３でＹｅｓと判断された際のビジネスオブジェクトの変換前に実施される。
【００４６】
なお、上記の動作において、送信エージェント１２１においても、受信エージェント１２２においても、処理能力を高い状態に変更する際には、アダプタ１２において設定可能な最も高い状態に変更する。これは、処理能力を切り換える際には、アダプタ１２のリブートを行う等、多大な動作コストを要するので、段階的に何度も処理能力を高めるような制御を行うと、かえって効率が悪くなる可能性があり好ましくないためである。
【００４７】
また、送信エージェント１２１における処理能力の変更条件である未処理ＢＯ数の閾値と受信エージェント１２２における処理能力の変更条件である未処理ＢＯ数の閾値とは、各アプリケーションサーバ１０の能力等に応じて独立して設定される。すなわち、送信側のアプリケーションサーバ１０において、未処理のデータ数が閾値を超えて送信エージェント１２１の処理能力を高い状態に変更した場合でも、そのデータのビジネスオブジェクトを受信した受信側のアプリケーションサーバ１０において、未処理ＢＯ数が閾値を超えずに受信エージェント１２２の処理能力を通常状態のままで動作させる場合もある。反対に、送信側のアプリケーションサーバ１０において、未処理のデータ数が閾値を超えず送信エージェント１２１の処理能力を通常状態のままで動作させた場合でも、そのデータのビジネスオブジェクトを受信した受信側のアプリケーションサーバ１０において、未処理ＢＯ数が閾値を超えて受信エージェント１２２の処理能力を高い状態に変更する場合もある。
【００４８】
以上説明した動作では、受信したビジネスオブジェクトの未処理ＢＯ数が閾値を超えていた場合には直ちに受信エージェント１２２の処理能力を高い状態に変更し、未処理ＢＯ数が閾値以下であるビジネスオブジェクトが数個連続した場合に受信エージェント１２２の処理能力を通常状態に復帰させた。この他、受信エージェント１２２の処理能力の切り換え条件として、ビジネスオブジェクトの受信サイクルに対して規定サイクル数を設定し、その規定サイクル数分のビジネスオブジェクトのうち、未処理ＢＯ数が閾値を超えるもの（あるいは閾値以下であるもの）がいくつあるかに応じて処理能力の切換を行っても良い。
【００４９】
例えば、規定サイクル数を５回とし、その規定サイクル数、すなわち連続して受信された５つのビジネスオブジェクトのうち、１つでも未処理ＢＯ数が閾値を超えるものがあったならば、受信エージェント１２２の処理能力を高い状態に変更する。そして、連続して受信された５つの受信ビジネスオブジェクトにおける未処理ＢＯ数が全て閾値以下であれば、受信エージェント１２２の処理能力を通常状態に復帰させる、といった制御を行うことができる。
【００５０】
一方、本実施形態が適用されるＥＡＩにおいて、所定の受信側のアプリケーションサーバ１０に対して複数の送信側のアプリケーションサーバ１０から送信されたビジネスオブジェクトが同時に送られてくることがない場合、送信側のアプリケーションサーバ１０において、送信するビジネスオブジェクトのうち最初の１つにだけ未処理ＢＯ数を付加することも可能である。この形態では、一定期間に受信された複数のビジネスオブジェクトの中に複数のアプリケーションサーバ１０から送信されたビジネスオブジェクトが混在しないので、最初のビジネスオブジェクトから得られた未処理ＢＯ数に基づいて受信エージェント１２２の処理能力を切り換える制御を行えば良い。
【００５１】
また、本実施形態では、各アプリケーションサーバ１０と統合サーバ２０との間でＭＱ（Message Queueing）による非同期型通信を行うこととしたが、本実施形態による通信制御の手法は、各アプリケーションサーバ１０と統合サーバ２０との間でＩＤＬ（Interface Definition Language）等による同期型通信が行われるシステムにおいても、問題なくそのまま適用することができる。
【００５２】
図８は、アプリケーションサーバ１０と統合サーバ２０との間で同期型通信が行われる場合の各サーバの機能構成を示す図である。
図８を参照すると、アプリケーションサーバ１０は、図３に示したアプリケーションサーバ１０と同様に、アプリケーション実行部１１と、アダプタ１２とを備える。ただし、送信用データ蓄積部１３および受信用データ蓄積部１４は備えていない。
また、統合サーバ２０は、図３に示した統合サーバ２０と同様に、送受信部２１と、データ変換部２２と、統合処理部２３とを備える。ただし、送受信部２１は、図２のメインメモリ１０３等で実現されるキューを備えておらず、アプリケーションサーバ１０から受信したビジネスオブジェクトを直ちにデータ変換部２２に渡す。また、データ変換部２２から受け取った送信すべきビジネスオブジェクトを直ちに送信先のアプリケーションサーバ１０へ送信する。
【００５３】
このような構成とした場合、各アプリケーションサーバ１０のアダプタ１２において、送信エージェント１２１は、アプリケーション実行部１１から取得される送信すべきデータの量に基づいて未処理ＢＯ数を計算し、生成したビジネスオブジェクトに付加して統合サーバ２０へ送信する。また、未処理ＢＯ数が多い場合は、送信エージェント１２１自身の処理能力を上げて対応することができる。また、受信エージェント１２２は、統合サーバ２０から受信したビジネスオブジェクトに付加された未処理ＢＯ数を参照し、未処理ＢＯ数の値が大きい場合は、受信エージェント１２２自身の処理能力を上げて対応する。
【００５４】
以上説明したように、本実施形態によれば、送信側のアプリケーションサーバ１０において、送信するデータの量の情報を送信データ自身に付加することにより、受信側のアプリケーションサーバ１０において、最初のビジネスオブジェクトを受信した時点で受信するデータの全体量を把握することができる。そして、この情報に基づき、アダプタ１２の処理能力を動的に調整することにより、所定のアプリケーションサーバ間で送受信されるデータ量の変化に対して柔軟に対応でき、ＥＡＩにおける通信トラフィックを自動的に最適化することが可能となる。
【００５５】
また、本実施形態では、各アプリケーションサーバ１０のアダプタ１２において送信エージェント１２１と受信エージェント１２２の処理能力を変更可能な設計とする他、ビジネスオブジェクトのＸＭＬファイルにフィールドを追加するだけで実現できる。したがって、特定のアプリケーションサーバ１０の間にバイパスとなる回線を設けるといったハードウェア的な設計に影響を与えず、ソフトウェア的な設計のみで実現可能である。したがって、新規のＥＡＩシステムへの導入のみならず、既存のＥＡＩシステムに対しても導入が容易である。
【００５６】
なお、本実施態様では、アプリケーションサーバ１０のアダプタ１２において受信エージェント１２２の処理能力を変更可能としている。他の実施形態としては、受信側のアプリケーション実行部１１の処理能力を変更可能とすることもできる。また他の実施態様としては、受信エージェント１２２の処理能力と（受信側の）アプリケーション実行部１１の処理能力との両方を変更可能とすることもできる。また、これらはいずれも受信側のアプリケーションサーバ１０の処理能力を変更するものであるが、送信側のアプリケーションサーバ１０や統合サーバ２０の処理能力を変更することもできる。ここで、アプリケーション実行部１１や統合処理部２３の処理能力を変更する具体的な方法としては、例えば、当該アプリケーション実行プロセスや当該統合処理プロセスに割当てられるスレッド数を増減させる方法や、当該アプリケーション実行プロセスや当該統合処理プロセスのスケジューリング優先度を変更する方法などにより、実現することができる。
【図面の簡単な説明】
【００５７】
【図１】本実施形態が適用されるＥＡＩの全体構成を概略的に示す図である。
【図２】図１のアプリケーションサーバや統合サーバとして好適なコンピュータ装置のハードウェア構成の例を模式的に示した図である。
【図３】本実施形態におけるアプリケーションサーバと統合サーバの機能構成を示す図である。
【図４】本実施形態の送信エージェントの動作を説明するフローチャートである。
【図５】本実施形態の受信エージェントの動作を説明するフローチャートである。
【図６】本実施形態において、受信側のアプリケーションサーバが、複数の送信側のアプリケーションサーバから送信されたデータを同時に受信する様子を示す図である。
【図７】本実施形態において、処理能力を高い状態から通常状態へ復帰させる際の受信エージェントの動作を説明するフローチャートである。
【図８】アプリケーションサーバと統合サーバとの間で同期型通信が行われる場合の各サーバの機能構成を示す図である。
【図９】従来のＥＡＩの全体構成を概略的に示す図である。
【符号の説明】
【００５８】
１０…アプリケーションサーバ、１１…アプリケーション実行部、１２…アダプタ、１３…送信用データ蓄積部、１４…受信用データ蓄積部、２０…統合サーバ、２１…送受信部、２２…データ変換部、２３…統合処理部、１０１…ＣＰＵ（Central Processing Unit：中央処理装置）、１０３…メインメモリ、１０５…磁気ディスク装置（ＨＤＤ）、１０６…ネットワークインターフェイス、１２１…送信エージェント、１２２…受信エージェント
【図１】
2006092212.tif 000003
【図２】
2006092212.tif 000004
【図３】
2006092212.tif 000005
【図４】
2006092212.tif 000006
【図５】
2006092212.tif 000007
【図６】
2006092212.tif 000008
【図７】
2006092212.tif 000009
【図８】
2006092212.tif 000010
【図９】
2006092212.tif 000011