(57)【要約】【課題】  サービスを呼び出すための情報の授受を環境に応じて適切に行うことのできるサービス要求装置、サービス提供装置、サービス要求方法、サービス提供方法、サービス要求プログラム、サービス提供プログラム及び記録媒体の提供を目的とする。【解決手段】  ネットワークを介して接続する他の装置の提供するサービスを利用するアプリケーションを有するサービス要求装置であって、前記アプリケーションからの前記サービスに対するメソッドの呼び出し要求に応じ、前記サービスを呼び出すための通信方法を判断し、判断された通信方法に基づいて前記アプリケーションからの要求に応じたメソッドの遠隔呼び出しを前記他の装置に対して行うことにより上記課題を解決する。【選択図】  図７
2006072978.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２００に渡すことになる。このような上述した一連のやり取りにより、クライアント装置１とサービス提供装置２２間でＷｅｂサービスとしての情報の授受が実現されることになる。
【０００７】
なお、上述のような情報の授受に関する技術文献として、特許文献１がある。
【特許文献１】特開２００４−４６８１７号公報
【発明の開示】
【発明が解決しようとする課題】
【０００８】
ところで、このような一連の情報の授受はネットワークを介したクライアント装置とサービス提供装置間による場合に限らず、クライアント装置の内部でなされる場合もある。
【０００９】
しかしながら、同一装置内での情報の授受を行う場合であっても、上述のようなＳＯＡＰメッセージによる情報の授受がなされていたため、データ変換や通信等における処理の非効率性の問題が生じていた。
【００１０】
また、ＳＯＡＰはトランスポート層にＨＴＴＰを利用しているため、ファイヤウォール（ｆｉｒｅｗａｌｌ）を超えてＲＰＣ（Remote Procedure Call）を実現できるという点において、他の分散オブジェクト技術におけるプロトコルに対して優位性を有する。しかし、ファイヤウォールを超えて通信する必要が無い場合は、ＸＭＬ形式によるテキストベースによるＳＯＡＰメッセージのやりとりによってＲＰＣ等を実現することは通信によるオーバヘッドを増大させ性能の劣化を招きかねないという問題がある。
【００１１】
本発明は、上記の点に鑑みてなされたものであって、サービスを呼び出すための情報の授受を環境に応じて適切に行うことのできるサービス要求装置、サービス提供装置、サービス要求方法、サービス提供方法、サービス要求プログラム、サービス提供プログラム及び記録媒体の提供を目的とする。
【課題を解決するための手段】
【００１２】
そこで上記課題を解決するため、本発明は、ネットワークを介して接続する他の装置の提供するサービスを利用するアプリケーションを有するサービス要求装置であって、前記アプリケーションからの前記サービスに対するメソッドの呼び出し要求に応じ、前記サービスを呼び出すための通信方法を判断し、判断された通信方法に基づいて前記アプリケーションからの要求に応じたメソッドの遠隔呼び出しを前記他の装置に対して行うことを特徴とする。
【００１３】
また、上記課題を解決するため、本発明は、上記サービス要求装置に対し少なくとも二種類の通信方法によってサービスの提供が可能なサービス提供装置であって、前記少なくとも二種類の通信方法のうちのいずれかの通信方法による前記サービスに対するメソッドの呼び出し要求に応じて前記メソッドに定義された処理を実行し、該処理の結果を前記呼び出し要求係る通信方法に基づいて前記サービス要求装置に返信することを特徴とする。
【００１４】
このようなサービス要求装置又はサービス提供装置によれば、サービスを呼び出すための情報の授受を環境に応じて適切に行うことができる。
【発明の効果】
【００１５】
本発明によれば、サービスを呼び出すための情報の授受を環境に応じて適切に行うことのできるサービス要求装置、サービス提供装置、サービス要求方法、サービス提供方法、サービス要求プログラム、サービス提供プログラム及び記録媒体を提供することができる。
【発明を実施するための最良の形態】
【００１６】
以下、添付図面を参照しながら、本発明の好適な実施の形態について説明する。なお、本実施形態におけるクライアント装置１とサービス提供装置２２〜４４とにより構成されるシステム構成自体は上述の図１と同様な構成であるため説明は省略する。
【００１７】
（第１の実施の形態）
図３は、本実施形態におけるクライアント装置１及びサービス提供装置２２〜４４のハードウェア構成を表すものである。クライアント装置１及びサービス提供装置２２〜４４は、ともに、ハードウェアとしては公知のＰＣ（パーソナルコンピュータ）である。即ち、クライアント装置１は、ＣＰＵ１１、ＲＯＭ１２、ＲＡＭ１３、ハードディスクドライブ（ＨＤＤ）１４、ネットワークＩ／Ｆ１５、ドライブ装置１６を備え、これらがシステムバスによって接続され、また、ネットワークＩ／Ｆ１５を介してネットワーク３に接続されている。そして、ＨＤＤ１４に種々のアプリケーションプログラムをインストールしてＣＰＵ１１に実行させることで、様々な機能を果たすことが可能となる。なお、ＨＤＤ１４に種々のアプリケーションプログラムをインストールする際には、記憶媒体１７を用いて、ドライブ装置１６経由で行うことも可能である。なお、本実施形態では、ＰＣ１をクライアント装置１として機能させるためのプログラムである、図４のクライアントモジュールを、ＨＤＤ１４にインストールし、ＣＰＵ１１に実行させ、ＣＰＵ１１を、後述する種々の手段として機能させている。また、ＰＣ２２についても同様に、サービス提供装置２２として機能させるためのプログラムである、図４のサービス提供モジュールを、ＨＤＤ１４０にインストールし、ＣＰＵ１１０に実行させ、ＣＰＵ１１０を、後述する種々の手段として機能させている。なお、ハードウェア構成については、後述する第２及び第３の実施形態においても同様でよい。
【００１８】
図４は、第１の実施形態のクライアント装置とサービス提供装置とのソフトウェア構成を表す図である。クライアント装置１は、ソフトウェアとして、クライアントモジュールと、サービス提供モジュールとにより構成される。以下、各モジュールについての説明を行う。
【００１９】
（クライアントモジュール）
クライアントモジュールは、WS Client Apl４００と、WS Proxy４０１とを有する。WS Client Apl４００は、後述するCore Module４０４、４０７に呼出要求を行うＷｅｂサービスのクライアントとして機能し、Core Module４０４、４０７の呼び出しに関する判別処理を行う。なお、WS Client Apl４００としてはＷｅｂサービスのクライアントとして稼動するものであれば、図示しないＷｅｂブラウザからの入力に基づき、下位モジュールにその内容を渡すＷｅｂアプリケーションや、Ｗｉｎｄｏｗｓ（登録商標）のようなオペレーティングシステム上で稼動する専用アプリケーションでもよい。
【００２０】
WS Proxy４０１は、ＷＳＤＬ（Web Service Description Language）から自動生成されるものであり、クライアントモジュールがコアモジュールを利用するためのＡＰＩ（Application Program Interface）を備えており、また、外部装置となるサービス提供装置２２との接続処理を行うときには、WS Client Apl４００からの呼出要求をＳＯＡＰメッセージとしてサービス提供装置２２に送信する。
【００２１】
（サービス提供モジュール）
サービス提供モジュールは、WS Listener４０２と、Web Service４０３と、Core Module４０４とから構成される。WS Listener４０２は、ＳＯＡＰメッセージを受信したときパージングを行い、下位モジュールが扱える形に型変換を行う。Web Service４０３は、対応するコアモジュールの機能を外部に公開するための手段として存在する。処理のメインロジックは後述するCore Module４０４に実装されており、Web Service４０３自身は、独自のロジックを持たない。これはCore Module４０４の対応メソッドと処理内容とに相違を発生させないようにするためである。Core Module４０４は、クライアントモジュールからの呼出要求に対して所定のメソッドを行うメインロジックを実装し、その実行結果を上位モジュールに返すサービス提供手段としての機能を有する。
【００２２】
本実施形態においては、WS Client Apl４００は、WS Proxy４０１と、WS Listener４０２と、Web Service４０３と、を介さずに、ネイティブコールによりサービスオブジェクトとなるCore Module４０４を呼び出す処理を行うことを特徴としているが、この点については後述する。
【００２３】
図４のサービス提供装置２２は、クライアント装置１のWS Proxy４０１からのＳＯＡＰメッセージに対し、サービス提供モジュールによるメソッド実行処理の結果をクライアント装置１に返す外部装置としてのサービス提供装置のソフトウェア構成を示すものである。
【００２４】
なお、WS Listener４０５と、Web Service４０６と、Core Module４０７と、についてはクライアント装置１におけるサービス提供モジュールと同様の機能であるため、ここでの各モジュールの説明は省略する。
【００２５】
次に、本実施形態におけるクライアント装置１とサービス提供装置２２の処理動作について説明する。クライアント装置１のWS Client Apl４００は、サービス提供要求のコマンドに基づき、呼出対象となるCore Moduleの呼出処理を開始する。このサービス提供要求のコマンドは、呼出対象となるCore Moduleの存在位置を特定するための位置情報を伴っている。WS Client Apl４００は、この位置情報に基づき、Core Moduleを呼び出したWS Client Aplと同居する場合、即ち、自装置内にCore Moduleが存在すると判断した場合は、WS Client Apl４００は、WS Proxy４０１を介さずに、そのCore Module４０４のクラスメソッドを直接呼び出すネイティブコールを行うことになる。コールされたCore Module４０４は、上記コマンドに対する応答として、そのクラスメソッドの実行結果をWS Client Apl４００に返却することになる。
【００２６】
一方、WS Client Apl４００は、上記コマンドに含まれる位置情報から、呼出対象となるCore Moduleが、クライアント装置１に存在しないと判断した場合は、WS Client Apl４００は、WS Proxy４０１を介して通常のＷｅｂサービスと同様の手順で外部装置であるサービス提供装置２２との接続処理を行う。即ちWS Proxy４０１は、WS Client Apl４００からの上記コマンドをＸＭＬ形式のコマンドに変換してＳＯＡＰエンベロープに格納し、サービス提供装置２２にＳＯＡＰメッセージを送信することになる。サービス提供装置２２のWS Listener４０５による型変換の後、Web Service４０６を介してCore Module４０７によるメソッド実行が行われ、その実行結果がWS Listener４０５を介してＳＯＡＰメッセージとしてクライアント装置側１に送信される。クライアント装置１では、WS Proxy４０１によるＳＯＡＰメッセージのパージングを経て、WS Client Apl４００に対してメソッド実行結果が返却される。
【００２７】
ここで、呼出対象となるCore Moduleがクライアント装置１に存在するか否かをWS Client Apl４００が特定する特定情報としては、例えば、該当Core Moduleを特定するＵＲＩ（Uniform Resource Identifier）やこのＵＲＩに含まれるＩＰアドレスなどが挙げられる。これらの特定情報は、WS Client Apl４００がCore Moduleを呼び出す際に生成する上記コマンドに付与されている情報であり、これらの情報から呼出対象のCore Moduleが自装置に存在するものか否かを判断することになる。そしてクライアント装置１のものと判断した際には、上述のようにCore Moduleの呼出処理の切り替え処理を行い、WS Client Apl４００は自装置１のCore Module４０４に対してネイティブコールにより直接アクセスし、所定の機能の提供を受けることになる。
【００２８】
このような形態をとることにより、呼出対象となるCore Moduleがクライアント装置１に存在するときの通信の問題を解決することができ、従来の外部装置との接続処理を行うための機構を変更することも、また新たな呼出処理に応じた実装の変更処理をすることもなく、該当するCore Moduleを呼び出すことが可能となる。
【００２９】
また、Core Moduleにより提供される機能が、何らかの文書データ（アプリケーションデータや画像データを含む情報）に関するものであるときは、従来の外部装置とのCore Moduleの呼び出し処理の手順を用いることで、外部装置でのＳＯＡＰメッセージにアタッチメントするためのデータ変換やクライアント装置でのＳＯＡＰメッセージの解析等で生じる一時ファイルの作成や保存という問題が生じるが、上述の形態をとることにより、この一時ファイルの問題も解決することが可能となる。
【００３０】
ところで第１の実施形態では、呼出対象となるCore Moduleがクライアント装置１に存在するか否かの判断ロジックをWS Client Apl４００が持ってしまうため、WS Client Apl４００に判断ロジックを意識させた実装になってしまう可能性がある。そこで本発明においては、この問題に対して第２の実施形態としての解決も図っている。
【００３１】
（第２の実施形態）
以下、図５及び図６を用いて第２の実施形態を説明する。図４との相違は、クライアント装置１にWeb サービスプロキシラッパ（以下、WS Proxy Wrapper５０１と称す）を介している点にある。このWS Proxy Wrapper５０１は、ＷＳＤＬにより自動生成されるProxyの上位モジュールであり、Proxyと同一のＩ／Ｆを備えているものである。また本実施形態においてWS Proxy Wrapper５０１は判別手段として機能する。なお、第１の実施形態と同様、WS Client Apl５００からのCore Moduleの呼出要求は呼出対象となるCore Moduleの存在位置を特定するための位置情報を伴っている。また図４と共通するモジュールについては、第１の実施形態と同様となる。以下、図６を参照しながら、クライアント装置１におけるWS Proxy Wrapper５０１を介した処理について説明する。
【００３２】
WS Client Apl５００からのCore Moduleの呼出要求のコマンドはWS Proxy Wrapper５０１に入力され（ステップＳ１）、WS Proxy Wrapper５０１によるCore Moduleの存在位置の特定がなされる（ステップＳ２）。WS Proxy Wrapper５０１による判断の結果、クライアント装置１に呼出対象となるCore Moduleがある場合、即ち、Core Moduleの存在位置を表す情報からクライアント装置１にCore Moduleがあると判断された場合は（ステップＳ３／Ｙｅｓ）、WS Proxy Wrapper５０１は、WS Proxy５０２を介さずに上記ネイティブコールを行う（ステップＳ４）。コールされたCore Module５０５は、第１の実施形態の場合と同様な処理を行い、そのメソッド実行結果の返却をWS Proxy Wrapper５０１を介してWS Client Apl５００に行う。
【００３３】
一方、上述の判断処理の結果、クライアント装置１に呼出対象となるCore Moduleがないと判断された場合は（ステップＳ３／Ｎｏ）、WS Proxy Wrapper５０１は、WS Proxy５０２を介した外部装置との接続処理を行う（ステップＳ５）。WS Proxy５０２は、第１の実施形態と同様に、ＳＯＡＰメッセージのパージング等の一般的なＳＯＡＰ処理系の処理を行い、外部装置となるサービス提供装置２２から、呼出対象となるCore Module５０８を呼び出す（ステップＳ６）。そして、Core Module５０８による所定の処理の結果がＳＯＡＰメッセージとして送信され、WS Proxy５０２によるパージングの後、WS Proxy Wrapper５０１を介してWS Client Apl５００に対してメソッド実行結果が返却される。
【００３４】
このように、第２の実施形態は、呼出対象のCore Moduleがクライアント装置１に存在するか否かをWS Proxy Wrapper５０１が判断するため、WS Client Apl５００に判断ロジックを意識させるような実装をする必要がなくなるという利点がある。また、WS Client Apl５００が複数あるときには、その複数のWS Client Apl５００に対して呼出処理を共通的に行うモジュールとして処理をさせることが可能となるため、似たような判断ロジックをWS Client Apl５００毎に持たせる必要がなくなるという利点もある。
【００３５】
上記、第１及び第２の実施の形態においては、WS Client Apl４００又は５００からの呼び出しをネイティブコールとネットワークを介した呼び出し（リモートコール）とに分類し、ネイティブコールにおける処理の効率化を実現する例について説明した。
【００３６】
ところで、分散オブジェクト技術におけるリモートコール（遠隔呼び出し）を実現するためのアーキテクチャはＳＯＡＰを用いたＷｅｂサービスだけに限られず、例えば、Ｊａｖａ（登録商標）によるＥＪＢ（Enterprise JavaBeans）を利用することもできる。ＳＯＡＰを用いる利点の一つとしはファイヤウォール（ｆｉｒｅｗａｌｌ）を超えてリモートコールを実現することができる点にある。したがって、ＳＯＡＰはインターネットをまたがった環境においてリモートコールを実現するのに適しているといえる。しかしながら、ファイヤウォール内においてリモートコールを実現する際にＳＯＡＰを用いることは、ＳＯＡＰメッセージの仕様上、かえって非効率になる場合もある。すなわち、ＳＯＡＰメッセージはＸＭＬといったテキストベースによるメッセージによって構成され、そのデータサイズは大きくなる傾向にあり、通信量を増大させる傾向にあるからである。そこで、かかる課題を解決するための実施形態として第３の実施形態を説明する。
【００３７】
（第３の実施形態）
図７は、第３の実施形態のクライアント装置とサービス提供装置とのソフトウェア構成を表す図である。
【００３８】
図７において、クライアント装置１は、アプリケーション６００、リモートクライアントＷｒａｐｐｅｒ６０１、ＳＯＡＰクライント６０２、ＥＪＢクライアント６０３、通信方法設定ＤＢ６０４等より構成されている。アプリケーション６００、リモートクライアントＷｒａｐｐｅｒ６０１、ＳＯＡＰクライアント６０２は、それぞれ第２の実施の形態（図５）におけるWS Client Apl５００、WS Proxy Wrapper５０１、WS Proxy５０２に対応する。すなわち、アプリケーション６００は、Core Module６０７が提供するサービスを利用することにより当該アプリケーションの機能を実現する。但し、アプリケーション６００は、直接Core Module６０７を呼び出すわけではなく、リモートクライアントＷｒａｐｐｅｒ６０１が提供する通信プロトコルに非依存なインタフェースによって間接的にCore Module６０７を遠隔呼び出しする。
【００３９】
リモートクライアントＷｒａｐｐｅｒ６０１は、アプリケーション６００によるCore Module６０７に対する要求をＳＯＡＰを用いて呼び出すべきか、ＥＪＢを用いて呼び出すべきかを判断し、その判断結果に応じた呼び出し方法（通信方法）によってCore Module６０７に対する呼び出しを行う。
【００４０】
例えば、リモートクライアントＷｒａｐｐｅｒ６０１がアプリケーション６００に対して提供するメソッドの一つとして、
ＵｓｅｒＬｉｓｔ  ｕｓｅｒＬｉｓｔ＝ｇｅｔＵｓｅｒＬｉｓｔ（）；
といったものがあるとする。このメソッドがアプリケーション６００に呼ばれた場合に、ＳＯＡＰによってサービス提供装置２２に呼び出しを行った場合は、図８のようなＸＭＬ形式のレスポンスが返却される。したがって、この場合、リモートクライアントＷｒａｐｐｅｒ６０１は、図８のようなＸＭＬ形式のレスポンスをＵｓｅｒＬｉｓｔ型に変換して、アプリケーション６００に返却する。
【００４１】
また、ＥＪＢによってサービス提供装置２２に呼び出しを行う場合は、リモートクライアントＷｒａｐｐｅｒ６０１は、図９のようなソースコードに基づく処理を実行することで、ＥＪＢによるリモート呼び出しを実現する。
【００４２】
すなわち、リモートクライントＷｒａｐｐｅｒ６０１は、プロトコル又は分散オブジェクトアーキテクチャの差違を吸収し、それらに共通のインタフェースをアプリケーション６００に提供する。したがって、アプリケーション６００は、プロトコル等の違いを意識することなくCore Module６０７に対する要求を行うことができる。
【００４３】
ＳＯＡＰクライアント６０２は、ＳＯＡＰによるリモート呼び出しを行うためのクライアントとして機能し、ＳＯＡＰインタフェース６０５との間でＳＯＡＰメッセージのやりとりを行う。ＥＪＢクライアント６０６は、ＥＪＢによるリモート呼び出しを行うためのクライアントとして機能し、ＥＪＢインタフェース６０６との間でＥＪＢによるリモート呼び出しを行うための通信を行う。
【００４４】
一方、図７においてサービス提供装置２２は、ＳＯＡＰインタフェース６０５、ＥＪＢインタフェース６０６、及びCore Module６０７等より構成される。ＳＯＡＰインタフェース６０５は、第２の実施形態におけるWS Listener５０６及びWeb Service５０６に相当する。すなわち、ＳＯＡＰインタフェース６０５は、クライアント装置１からのＳＯＡＰによるリモート呼び出し（ＳＯＡＰメッセージ）を解釈し、当該リモート呼び出しに対応するCore Module６０７の機能（メソッド）を呼び出す。
【００４５】
ＥＪＢインタフェース６０６は、クライアント装置１からのＥＪＢによるリモート呼び出しを解釈し、当該リモート呼び出しに対応するCore Module６０７のメソッドを呼び出す。すなわち、サービス提供装置２２は、ＳＯＡＰ及びＥＪＢといった２種類の通信方法に基づくリモート呼び出しによってCore Module６０７の機能の提供が可能である。
【００４６】
以下、図７のクライアント装置１及びサービス提供装置２２の処理手順について説明する。
【００４７】
図１０は、第３の実施の形態におけるCore Moduleの呼び出し時のリモートクライアントＷｒａｐｐｅｒの処理手順を説明するためのフローチャートである。
【００４８】
アプリケーション６００より、呼び出しメソッドの識別名（例えば、メソッド名）と呼び出し先のサーバＵＲＩ(Uniform Resource Identifier)との指定を受けてCore Module６０７に対する呼び出し要求を受け付けると（Ｓ１１）、指定されたサーバＵＲＩに対する通信方法（ＳＯＡＰ又はＥＪＢ）を通信方法設定ＤＢ６０４より取得する（Ｓ１２）。
【００４９】
図１１は、通信方法設定ＤＢの登録内容の例を示す図である。図１１に示されるように、通信方法設定ＤＢ６０４には、サーバＵＲＩごとに通信方法が設定されている。例えば、図１１では、サーバＵＲＩが「http://xxx.xxx.xxx.xxx/」である場合の通信方法はＳＯＡＰであり、サーバＵＲＩが「http://yyy.yyy.yyy.yyy/」である場合の通信方法はＥＪＢであることが登録されている。なお、図１１において、サーバＵＲＩに「デフォルト」という値が登録されているレコードは、アプリケーションより指定されたサーバＵＲＩに対して通信方法が設定されていない場合に適用されるレコードである。図１１の場合、デフォルトの通信方法はＥＪＢに設定されている。
【００５０】
したがって、リモートクライアントＷｒａｐｐｅｒ６０１は、通信方法設定ＤＢ６０４を参照することにより、サーバＵＲＩに基づいて呼び出しメソッドの呼び出し先のサーバとの通信方法を判断する（Ｓ１３）。
【００５１】
サーバＵＲＩに対する通信方法がＳＯＡＰに設定されている場合（Ｓ１３でＳＯＡＰ）、呼び出しメソッドをＸＭＬ形式によるＳＯＡＰのリクエスト形式に変換し（Ｓ１４）、ＳＯＡＰクライアント６０２経由でCore Module６０７に対する呼び出しメソッドの呼び出し情報（ＳＯＡＰメッセージ）をサービス提供装置２２に送信する（Ｓ１５）。
【００５２】
また、サーバＵＲＩに対する通信方法がＥＪＢに設定されている場合（Ｓ１３でＥＪＢ）、呼び出しメソッドをＥＪＢのリクエスト形式に変換し（Ｓ１６）、ＥＪＢクライアント６０３経由でCore Module６０７に対する呼び出しメソッドの呼び出し情報をサービス提供装置２２に送信する（Ｓ１７）。
【００５３】
一方、サーバＵＲＩに該当するレコードが無い場合（Ｓ１３で該当無し）、デフォルトの通信方法を通信方法設定ＤＢ６０４より取得し（Ｓ１８）、デフォルトの通信方法で呼び出しメソッドを呼び出す（Ｓ１９）。すなわち、デフォルトの通信方法がＳＯＡＰであった場合、ステップＳ１９ではステップＳ１４及びＳ１５と同様の処理が実行される。また、デフォルトの通信方法がＥＪＢであった場合、ステップＳ１９ではステップＳ１６及びＳ１７と同様の処理が実行される。
【００５４】
続いて、デフォルトの通信方法による呼び出しが成功したか否かを判断する（Ｓ２０）。この判断は、呼び出しメソッドの呼び出しに対して正常に戻り値が取得されたか否かによって行えばよい。デフォルトの通信方法による呼び出しが成功した場合（Ｓ２０でＹｅｓ）、これまで通信方法設定ＤＢ６０４には登録されていなかった当該サーバＵＲＩに関連付けてデフォルトの通信方法を通信方法設定ＤＢ６０４に登録する（Ｓ２１）。したがって、次回からは、当該サーバＵＲＩに対する通信方法は通信方法設定ＤＢ６０４より直接取得されることになる。
【００５５】
一方、デフォルトの通信方法の呼び出しが失敗した場合（Ｓ２０でＮｏ）、デフォルトの通信方法に対して他方の通信方法での呼び出しを試みる（Ｓ２２）。すなわち、デフォルトの通信方法がＥＪＢである場合は、ＳＯＡＰによる呼び出しが行われる。
【００５６】
他方の通信方法による呼び出しが成功した場合（Ｓ２３でＹｅｓ）、当該サーバＵＲＩに関連付けて当該他方の通信方法を通信方法設定ＤＢ６０４に登録する（Ｓ２１）。他方の通信方法による呼び出しが失敗した場合（Ｓ２３でＮｏ）、アプリケーション６００に対してエラーを返却する。
【００５７】
続いて、ＳＯＡＰ又はＥＪＢによって呼び出しメソッドの呼び出し先とされたサービス提供装置２２における処理手順について説明する。図１２は、第３の実施の形態におけるリモート呼び出しを受けたサービス提供装置の処理手順を説明するためのフローチャートである。
【００５８】
通信方法がＳＯＡＰであった場合（すなわち、ＳＯＡＰによって呼び出しメソッドが呼び出された場合）（Ｓ３１でＳＯＡＰ）、ＳＯＡＰインタフェース６０５は、ＳＯＡＰによる呼び出し情報（ＳＯＡＰメッセージ）を受信し（Ｓ３２）、ＳＯＡＰメッセージに基づいてCore Module６０７の呼び出しメソッドを呼び出す（Ｓ３３）。
【００５９】
一方、通信方法がＥＪＢであった場合（すなわち、ＥＪＢによって呼び出しメソッドが呼び出された場合）（Ｓ３１でＥＪＢ）、ＥＪＢインタフェース６０６は、ＥＪＢによる呼び出し情報を受信し（Ｓ３４）、その呼び出し情報に基づいてCore Module６０７の呼び出しメソッドを呼び出す（Ｓ３５）。
【００６０】
呼び出しメソッドを呼び出されたCore Module６０７は、当該メソッドに定義された処理を実行し、その処理結果を呼び出し元（ＳＯＡＰインタフェース６０５又はＥＪＢインタフェース６０６）に返却する（Ｓ３６）。
【００６１】
通信方法がＳＯＡＰであった場合（Ｓ３７でＳＯＡＰ）、ＳＯＡＰインタフェース６０５は、Core Module６０７からの処理結果をＳＯＡＰレスポンスの形式に変換し（Ｓ３８）、そのＳＯＡＰレスポンスをＳＯＡＰクライアント６０２に対して送信する（Ｓ３９）。
【００６２】
一方、通信方法がＥＪＢであった場合（Ｓ３７でＥＪＢ）、ＥＪＢインタフェース６０６は、Core Module６０７からの処理結果をＥＪＢレスポンスの形式に変換し（Ｓ４０）、そのＥＪＢによるレスポンスをＥＪＢクライアント６０３に対して送信する（Ｓ４１）。
【００６３】
続いて、サービス提供装置２２よりレスポンスを受信したクライアント装置１における処理手順について説明する。図１３は、第３の実施の形態におけるサービス提供装置からのレスポンスを受けたクライアント装置の処理手順を説明するためのフローチャートである。
【００６４】
通信方法がＳＯＡＰであった場合（すなわち、ＳＯＡＰによって呼び出した場合）（Ｓ５１でＳＯＡＰ）、ＳＯＡＰクライアント６０２はＳＯＡＰインタフェース６０５からのＳＯＡＰレスポンスを受信し（Ｓ５２）、当該ＳＯＡＰレスポンスをリモートクライアントＷｒａｐｐｅｒ６０１に返却する（Ｓ５３）。ＳＯＡＰレスポンスを受け付けたリモートクライアントＷｒａｐｐｅｒ６０１は、ＳＯＡＰレスポンスをリモートクライアントＷｒａｐｐｅｒ６０１がアプリケーション６００に対して提供するインタフェースの形式（例えば、Ｃ言語による構造対等のアプリケーション６００に解釈可能な形式）に変換し（Ｓ５４）、変換された処理結果をアプリケーション６００に返却する（Ｓ５８）。
【００６５】
一方、通信方法がＥＪＢであった場合（すなわち、ＥＪＢによって呼び出した場合）（Ｓ５１でＥＪＢ）、ＥＪＢクライアント６０３はＥＪＢインタフェース６０６からのＥＪＢによるレスポンスを受信し（Ｓ５５）、当該レスポンスをリモートクライアントＷｒａｐｐｅｒ６０１に返却する（Ｓ５６）。ＥＪＢによるレスポンスを受け付けたリモートクライアントＷｒａｐｐｅｒ６０１は、当該レスポンスをアプリケーション６００に解釈可能な形式に変換し（Ｓ５７）、変換された処理結果をアプリケーション６００に返却する（Ｓ５８）。
【００６６】
上述したように第３の実施形態におけるクライアント装置１によれば、ファイヤウォールを通過可能なＳＯＡＰによるリモート呼び出しと、必ずしもファイヤウォールは通過できないがＳＯＡＰに比べて処理効率の高い（高速な）ＥＪＢによるリモート呼び出しとの双方によって、サービス提供装置２２等の機能を利用することができる。したがって、ファイヤウォール内におけるリモート呼び出しにおいては、ＥＪＢを用いることで効率的にCore Module６０７の機能を利用することができる。
【００６７】
なお、第三の実施の形態では、ＳＯＡＰに対して高速なリモート呼び出しの方法としてＥＪＢを例として説明したが、例えば、ＥＪＢより低レベルなＲＭＩ（Remote Method Invocation）を用いてもよい。また、ＤＣＯＭ（Distributed COM）、又はＣＯＲＢＡ（Common Object Request Broker Architecture）等、他のアーキテクチャ又はプロトコルを用いてもよい。
【００６８】
なお、上述の実施形態は、本発明の好適な実施形態であり本発明の範囲を限定するものではなく、その要旨を逸脱しない範囲において種々の変更を施した形態での実施が可能である。例えば、情報処理装置に組み込まれたコンピュータプログラムや、このプログラムが記憶された各種記憶媒体による同様の処理を実現することも可能である。
【図面の簡単な説明】
【００６９】
【図１】クライアント装置とサービス提供装置とから構成される、従来技術におけるＷｅｂサービスのシステム構成を表す図である。
【図２】図１のシステム構成におけるクライアント装置とサービス提供装置間のＷｅｂサービスとしての情報の授受を表す図である。
【図３】本発明の実施形態におけるクライアント装置とサービス提供装置のハードウェア構成を表す図である。
【図４】第１の実施形態のクライアント装置とサービス提供装置とのソフトウェア構成を表す図である。
【図５】第２の実施形態のクライアント装置とサービス提供装置とのソフトウェア構成を表す図である。
【図６】第２の実施形態におけるCore Moduleの呼び出しを表すフローチャートである。
【図７】第３の実施形態のクライアント装置とサービス提供装置とのソフトウェア構成を表す図である。
【図８】ＳＯＡＰによって呼び出しを行った場合のＳＯＡＰレスポンスの例を示す図である。
【図９】ＥＪＢによって呼び出しを行う場合のソースコードの例を示す図である。
【図１０】第３の実施の形態におけるCore Moduleの呼び出し時のリモートクライアントＷｒａｐｐｅｒの処理手順を説明するためのフローチャートである。
【図１１】通信方法設定ＤＢの登録内容の例を示す図である。
【図１２】第３の実施の形態におけるリモート呼び出しを受けたサービス提供装置の処理手順を説明するためのフローチャートである。
【図１３】第３の実施の形態におけるサービス提供装置からのレスポンスを受けたクライアント装置の処理手順を説明するためのフローチャートである。
【符号の説明】
【００７０】
１    クライアント装置
３    ネットワーク
１１、１１０    ＣＰＵ
１２、１２０    ＲＯＭ
１３、１３０    ＲＡＭ
１４、１４０    ＨＤＤ
１５、１５０    ネットワークＩ／Ｆ
１６、１６０    ドライブ装置
１７、１７０    記憶媒体
２２、３３、４４    サービス提供装置
２００、４００、５００        WS Client Apl
２０１、４０１、５０２        WS Proxy
２０２、４０２、４０５、５０３、５０６    WS Listener
２０３、４０３、４０６、５０４、５０７    Web Service
２０４、４０４、４０７、５０５、５０８    Core Module
５０１          WS Proxy Wrapper
６００          アプリケーション
６０１          リモートクライアントＷｒａｐｐｅｒ
６０２          ＳＯＡＰクライアント
６０３          ＥＪＢクライアント
６０４          通信方法設定ＤＢ
６０５          ＳＯＡＰインタフェース
６０６          ＥＪＢインタフェース
６０７          Core Module
【図１】
2006072978.tif 000003
【図２】
2006072978.tif 000004
【図３】
2006072978.tif 000005
【図４】
2006072978.tif 000006
【図５】
2006072978.tif 000007
【図６】
2006072978.tif 000008
【図７】
2006072978.tif 000009
【図８】
2006072978.tif 000010
【図９】
2006072978.tif 000011
【図１０】
2006072978.tif 000012
【図１１】
2006072978.tif 000013
【図１２】
2006072978.tif 000014
【図１３】
2006072978.tif 000015