JP4713189B2 - 情報処理装置、プログラム及び記録媒体 - Google Patents

Description

本発明は、情報処理装置、プログラム及び記録媒体に関する。

近年、ネットワーク環境を前提としたアプリケーションソフトの開発がなされているが、その１つとして、Ｗｅｂサービスの技術が挙げられる。Ｗｅｂサービスは、インターネットの標準技術を使ってネットワーク上に分散したアプリケーションを連携させるための技術であり、ＨＴＴＰ（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を実装した場合の、クライアント装置１とサービス提供装置３とのソフトウェア構成を示すブロック図である。 図５における本実施形態の処理動作を示すフローチャートである。 従来のＷｅｂサービスのシステム構成を示す図である。 従来のＷｅｂサービスのシステムにおいての情報の授受を示す図である。

符号の説明

１ クライアント装置
２ ネットワーク
３，４，５ サービス提供装置
１１、３１ ＣＰＵ
１２、３２ ＲＯＭ
１３、３３ ＲＡＭ
１４、３４ ＨＤＤ
１５、３５ ネットワークＩ／Ｆ
１６、３６ ドライブ装置
１７、３７ 記憶媒体

Claims (5)

1. 上位モジュールから、情報提供手段への呼出要求を受け付ける受付手段と、
   前記呼出要求により、プログラミング言語により定義された形式のメソッドが呼び出されたかどうかの判別を行う判別手段と、
   前記判別の結果、プログラミング言語により定義された形式のメソッドが呼び出された場合には、前記情報提供手段からのレスポンスに格納されている戻り値を記述したマークアップ言語を取り出し、プログラミング言語により定義された形式に変換してから前記上位モジュールに送出する一方で、前記判別の結果、プログラミング言語により定義された形式のメソッドが呼び出されなかった場合には、前記情報提供手段からのレスポンスに格納されている戻り値を記述したマークアップ言語を取り出し、そのまま前記上位モジュールに送出するレスポンス受信手段と、
   を有することを特徴とする情報処理装置。
2. 前記判別の結果、プログラミング言語により定義された形式のメソッドが呼び出された場合、前記情報提供手段へのリクエストは、プログラミング言語により定義された形式のメソッドをリクエストSOAP-Envのbody要素にマークアップ言語で記述された形式で格納したものであり、
   前記判別の結果、プログラミング言語により定義された形式のメソッドが呼び出されなかった場合、前記情報提供手段へのリクエストは、プログラミング言語により定義された形式のものではないメソッドをリクエストSOAP-Envのbody要素にマークアップ言語で記述された形式で格納したものであることを特徴とする請求項１に記載の情報処理装置。
3. 前記レスポンス受信手段により前記上位モジュールに送出された戻り値を基にＨＴＭＬが生成され、当該ＨＴＭＬがウェブブラウザに送信されることを特徴とする請求項１又は２に記載の情報処理装置。
4. 上位モジュールから、情報提供手段への呼出要求を受け付ける受付処理と、
   前記呼出要求により、プログラミング言語により定義された形式のメソッドが呼び出されたかどうかの判別を行う判別処理と、
   前記判別の結果、プログラミング言語により定義された形式のメソッドが呼び出された場合には、前記情報提供手段からのレスポンスに格納されている戻り値を記述したマークアップ言語を取り出し、プログラミング言語により定義された形式に変換してから前記上位モジュールに送出する一方で、前記判別の結果、プログラミング言語により定義された形式のメソッドが呼び出されなかった場合には、前記情報提供手段からのレスポンスに格納されている戻り値を記述したマークアップ言語を取り出し、そのまま前記上位モジュールに送出するレスポンス受信処理と、
   をコンピュータに実行させることを特徴とするプログラム。
5. 請求項４に記載のプログラムを記録したコンピュータが読取可能な記録媒体。

Images