(57)【要約】【課題】  クライアントアプリケーション毎にセッションの管理を可能とする。【解決手段】  クライアントアプリケーションとサーバアプリケーション間で送受信されるセッション情報とクライアント側で取得したセッション管理情報とを関連付けて記憶するセッション管理テーブルを用いて、クライアントアプリケーションとサーバアプリケーション間の論理的な接続関係を示すセッションを管理する際に、クライアントアプリケーションからサーバアプリケーションへのリクエストに付加するセッション情報をセッション管理情報に基づいてセッション管理テーブルから検索して取得し、サーバアプリケーションから受信したセッション情報を記憶する場合、リクエスト時にクライアント側で取得したセッション管理情報とセッション情報とを関連付けてセッション管理テーブルに記憶する。【選択図】      図２
2006244428.tif 000002
【特許請求の範囲】
【請求項１】
クライアントアプリケーションとサーバアプリケーション間で送受信されるセッション情報とクライアント側で取得したセッション管理情報とを関連付けて記憶するセッション管理テーブルを用いて前記クライアントアプリケーションとサーバアプリケーション間の論理的な接続関係を示すセッションを管理するセッション管理方法であって、
前記クライアントアプリケーションからサーバアプリケーションへのリクエストに付加するセッション情報を前記セッション管理情報に基づいて前記セッション管理テーブルから検索して取得するセッション情報検索工程と、
前記サーバアプリケーションから受信したセッション情報を記憶する場合、リクエスト時に前記クライアント側で取得したセッション管理情報と該セッション情報とを関連付けて前記セッション管理テーブルに記憶するセッション情報記憶工程とを有することを特徴とするセッション管理方法。
【請求項２】
前記セッション管理テーブルに、セッション情報、セッション管理情報と共に、接続先サーバ情報も関連付けて記憶し、前記セッション情報検索工程では、前記セッション管理情報と該接続先サーバ情報とに基づいて前記セッション管理テーブルからセッション情報を検索して取得し、前記セッション情報記憶工程では、リクエスト時に前記クライアント側から取得したセッション管理情報とセッション情報と前記接続先サーバ情報とを関連付けて前記セッション管理テーブルに記憶することを特徴とする請求項１記載のセッション管理方法。
【請求項３】
前記セッション管理情報は、前記セッション管理テーブルで一意に管理する情報であることを特徴とする請求項１又は請求項２記載のセッション管理方法。
【請求項４】
前記セッション管理情報として一意な識別子を設定すると共に、セッション管理情報の永続的な管理を指定する情報が設定された場合、前記セッション管理テーブルで前記セッション情報を永続的に管理することを特徴とする請求項３記載のセッション管理方法。
【請求項５】
前記セッション管理テーブルにクライアントアプリケーションを識別するための更なる情報を設定し、当該更なる情報に基づいてクライアントアプリケーション毎にセッションを管理することを特徴とする請求項１乃至請求項４の何れか一項に記載のセッション管理方法。
【請求項６】
前記クライアントアプリケーションを使用するユーザの情報を取得するユーザ情報取得工程を有し、前記取得したユーザ情報毎にセッション管理テーブルを記憶し、
前記セッション情報検索工程及び前記セッション情報記憶工程では、前記ユーザ情報に対応するセッション管理テーブルに対して前記セッション情報の検索、記憶を行うことを特徴とする請求項１乃至請求項５の何れか一項に記載のセッション管理方法。
【請求項７】
指定されたセッション管理情報と接続先サーバ情報に対応するセッション情報を初期化するセッション初期化工程を更に有することを特徴とする請求項１乃至請求項６の何れか一項に記載のセッション管理方法。
【請求項８】
クライアントアプリケーションとサーバアプリケーション間で送受信されるセッション情報とクライアント側で取得したセッション管理情報とを関連付けて記憶するセッション管理テーブルを用いて前記クライアントアプリケーションとサーバアプリケーション間の論理的な接続関係を示すセッションを管理するセッション管理装置であって、
前記クライアントアプリケーションからサーバアプリケーションへのリクエストに付加するセッション情報を前記セッション管理情報に基づいて前記セッション管理テーブルから検索して取得するセッション情報検索手段と、
前記サーバアプリケーションから受信したセッション情報を記憶する場合、リクエスト時に前記クライアント側で取得したセッション管理情報と該セッション情報とを関連付けて前記セッション管理テーブルに記憶するセッション情報記憶手段とを有することを特徴とするセッション管理装置。
【請求項９】
請求項１乃至請求項７の何れか一項に記載のセッション管理方法をコンピュータに実行させるためのプログラム。
【請求項１０】
請求項９記載のプログラムを記録したコンピュータ読み取り可能な記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、分散環境においてクライアントアプリケーションとサーバアプリケーション間の論理的な接続関係を示すセッションを管理する技術に関する。
【背景技術】
【０００２】
近年の著しいインターネットの普及に伴い、従来は独自のインタフェースを使っていたクライアントサーバシステムにおけるクライアントとサーバ間のインタフェースを標準のプロトコルであるHTTP（Hypertext Transfer Protocol）／HTML（Hypertext Markup Language）に準拠させ、特定のクライアントのプラットフォームに依存することなく、クライアントのＷｅｂブラウザからサーバのサービスであるＷｅｂアプリケーションを利用可能にする動きが急速に広がっている。
【０００３】
また、XML（Extensible Markup Language）、SOAP（Simple Object Access Protocol）、HTTPといったインターネット標準技術を利用してクライアントアプリケーションと直接データ交換を行うＷｅｂサービスが普及し始めている。
【０００４】
これらのネットワーク上で行われるデータ交換においては、セッション管理が行われている。上述のHTTPプロトコルでは、クライアントのアプリケーションからＷｅｂサーバへリクエストされる毎に、クライントとサーバとの間でコネクションが成立し、リクエストに対するレスポンスが行われ、通信が終了した後、そのコネクションは切断される。
【０００５】
つまり、「接続、通信、切断」という一連の処理が行われる。この一連の処理を「セッション」と呼ぶ。一つのセッションの間にやり取りされる情報は、そのセッションが終了すると無効になる。そのため、１つのセッションの情報を次のセッションに持ち越すことはできない。
【０００６】
しかしながら、複数のセッション間で情報を共有するために、複数のセッションを一つのセッションとして管理したい場合がある。例えば、ショッピングサイトで商品購入までの一連の処理である「ログイン」、「商品選択」、「清算処理」、「ログアウト」などが別々のセッションとなると、ログインしたユーザの情報、選択した商品の情報、清算情報、ログアウト情報がお互いに関連した情報であることが分からず、ショッピングとしての処理が成立しない。そのため、複数のセッションを一つのセッションとして管理する必要がでてくる。このように、一連の処理を一つのセッションとして管理する仕組みのことをセッション管理という。
【０００７】
このセッション管理を実現する一般的な方法として、例えばセッションを識別する情報としてサーバが発行するセッションIDを利用するものがある。これは、クライアントからサーバへのリクエストに対するレスポンスに付加されるセッションIDをクライアントが保持しておき、次の処理に対するリクエストを送信する際に、保持したセッションIDを付加するものである。
【０００８】
サーバアプリケーションは、このセッションIDに基づいてセッション単位で保持されている情報を用いた処理を行い、レスポンスを行う。通常、クライアントアプリケーションでは、セッションを張るか否かを設定することができ、セッションを張らない設定にして処理を実行した場合は、セッションIDを付加せずにリクエストを送信する。そして、それに対するレスポンスにセッションIDが付加されていたとしても、そのセッションIDを保持せずにセッションを終了する。
【０００９】
また、セッション管理に関して、特にサーバ側がＷｅｂサービスである場合、クライアント側で細かい制御ができることが望まれている。なぜならば、ＷｅｂサービスはＷｅｂアプリケーションのように一連の処理を一つのフローとして提供するというよりも、処理の一部を提供するものとして扱うことができ、クライアントが、単数或いは複数のＷｅｂサービスが提供する様々なサービスを組み合わせて使用するという形態が成立し、クライアント側が主体となってフローを構成するためである。
【００１０】
ところで、従来、マルチプロセス環境でクライアントアプリケーションを実行する場合、アクセス先が同じサーバであったとしても、セッションIDはプロセス毎に保存される。そのため、複数のクライアントアプリケーションが存在しても、それぞれのクライアントアプリケーションで独立したセッションを保持して一連の処理を実行することができる。また、逆にプロセス毎に独立したセッションを扱うのではなく、アプリケーション同士が意図して共通のセッションを扱うための提案がされており（例えば、特許文献１を参照）、セッション管理の単位を制御することが可能になっている。
【特許文献１】特開2004-220318号公報
【発明の開示】
【発明が解決しようとする課題】
【００１１】
組み込み機器には、シングルプロセスで動作するアプリケーションプラットフォーム上に複数のアプリケーションを起動するアーキテクチャを持つものがある。このようなアーキテクチャ上でアプリケーションから共通に利用できる共通ライブラリでセッション管理を行う場合、異なるクライアントアプリケーションから同じサーバに対してアクセス要求されても、共通ライブラリからはどのクライアントアプリケーションからのアクセス要求かを判別することができない。そのため、クライアントアプリケーション間で意図せずに同じセッションIDが利用されてしまう。
【００１２】
即ち、異なるクライアントアプリケーションから同一のＷｅｂサービスにアクセスした場合、それぞれ異なるクライアントアプリケーションであるにも係らず、同じセッションとしてＷｅｂサービスの処理が行われてしまい、独立したクライアントアプリケーションとして動作することができない、という問題がある。
【００１３】
また、従来、クライアントアプリケーションからセッションを柔軟に扱うことが困難であった。クライアントアプリケーションからより柔軟にセッションを管理する際に、クライアントアプリケーションが一旦終了した場合であっても、再起動後に前回のセッションで継続して処理を行うこと、また逆に、再起動時には新たなセッションを開始することをクライアントアプリケーションから選択できる柔軟性が望まれている。
【００１４】
通常、クライアントアプリケーションでは、Ｗｅｂサービスライブラリを介してＷｅｂサービスを利用する。Ｗｅｂサービスライブラリは、クライアントとＷｅｂサービス間で相互にやり取りするSOAPメッセージの生成や解析を行うモジュールである。クライアントアプリケーションはこのモジュールを呼び出すインタフェースとなるオブジェクトを生成してＷｅｂサービスとのデータ交換を行う。
【００１５】
クライアントアプリケーションが一つのサーバアプリケーションに対してセッションを保持しながら複数のセッションを張るような処理を行う場合、張りたいセッションの数だけオブジェクトを生成していた。しかし、リソースの少ない機器上では非効率になる。
【００１６】
更に、クライアントアプリケーションから柔軟にセッションを管理する際に、保持されているセッションIDの初期化をクライアントアプリケーションで行うことが望まれる。
【００１７】
また、組み込み機器のようなリソースの限られている環境では、アプリケーション実行時に、なるべくメモリを消費しないように、オブジェクトの生成数を少なくすることが求められる。しかしながら、同じサーバに対して新たなセッションを開始しようとした場合、サーバにアクセスするためのモジュールを呼び出すオブジェクトを新たに生成し、そのオブジェクトを使用してアクセスする必要があった。
【００１８】
本発明は上述の課題を解決するためになされたもので、クライアントアプリケーション毎にセッションの管理を可能とすることを目的とする。
【００１９】
また、本発明は、クライアント側で持続的にセッションの管理を行えるようにすることを目的とする。
【００２０】
更に、本発明は、クライアント側で管理しているセッションの初期化を可能とすることを目的とする。
【課題を解決するための手段】
【００２１】
本発明は、クライアントアプリケーションとサーバアプリケーション間で送受信されるセッション情報とクライアント側で取得したセッション管理情報とを関連付けて記憶するセッション管理テーブルを用いて前記クライアントアプリケーションとサーバアプリケーション間の論理的な接続関係を示すセッションを管理するセッション管理方法であって、前記クライアントアプリケーションからサーバアプリケーションへのリクエストに付加するセッション情報を前記セッション管理情報に基づいて前記セッション管理テーブルから検索して取得するセッション情報検索工程と、前記サーバアプリケーションから受信したセッション情報を記憶する場合、リクエスト時に前記クライアント側で取得したセッション管理情報と該セッション情報とを関連付けて前記セッション管理テーブルに記憶するセッション情報記憶工程とを有することを特徴とする。
【００２２】
また、本発明は、クライアントアプリケーションとサーバアプリケーション間で送受信されるセッション情報とクライアント側で取得したセッション管理情報とを関連付けて記憶するセッション管理テーブルを用いて前記クライアントアプリケーションとサーバアプリケーション間の論理的な接続関係を示すセッションを管理するセッション管理装置であって、前記クライアントアプリケーションからサーバアプリケーションへのリクエストに付加するセッション情報を前記セッション管理情報に基づいて前記セッション管理テーブルから検索して取得するセッション情報検索手段と、前記サーバアプリケーションから受信したセッション情報を記憶する場合、リクエスト時に前記クライアント側で取得したセッション管理情報と該セッション情報とを関連付けて前記セッション管理テーブルに記憶するセッション情報記憶手段とを有することを特徴とする。
【発明の効果】
【００２３】
本発明によれば、クライアントとサーバとの間の論理的な接続関係を示すセッションをクライアント側で柔軟に管理することが可能となる。
【発明を実施するための最良の形態】
【００２４】
以下、図面を参照しながら発明を実施するための最良の形態について詳細に説明する。
【００２５】
本実施形態を説明する前に、まずＷｅｂサービスにおける処理の概略について説明する。図１は、Ｗｅｂサービスが行われるシステムの構成の一例を示す図である。図１に示すように、Ｗｅｂサービスが行われるシステムは、Ｗｅｂサービスを利用するクライアントアプリケーション１０１、スタブ（Stub）オブジェクト１０２、Ｗｅｂサービスライブラリ１０３、通信ライブラリ１０４、ネットワーク１０５、及びＷｅｂサービスを提供するサーバアプリケーション１０６で構成されている。
【００２６】
尚、クライアント側のアプリケーションやライブラリなどは、パーソナルコンピュータなどのコンピュータや組み込み機器においてオペレーティングシステム（ＯＳ）によって実行されるプログラムである。また、サーバ側の構成については詳細に示していないが、Ｗｅｂサービスを提供する際に必要なライブラリやモジュールはクライアント側と同様に備えられているものとする。
【００２７】
また、クライアントやサーバとして機能するコンピュータは汎用のコンピュータで良く、ここでの説明は省略する。
【００２８】
スタブオブジェクト１０２は、クライアントアプリケーション１０１からはメソッドの呼び出し先となるモジュールであり、更にクライアントアプリケーション１０１とＷｅｂサービスライブラリ１０３との間で引数や返値の型変換を行う。このスタブオブジェクト１０２のクラスは、WSDL（Web Services Description Language）で記述されたサービス仕様からスタブ生成プログラムにより自動的に生成されたものであり、提供するメソッドにより、異なるスタブオブジェクト１０２ａ、１０２ｂが存在する。また同じメソッドを提供する場合でも、クライアントアプリケーション毎に別のスタブオブジェクト１０２、１０２ａが存在する。
【００２９】
上述のWSDLはXMLをベースとするＷｅｂサービス記述言語であり、W3C（World Wide Web Consortium）で策定されている。このWSDLは、Ｗｅｂサービスがどのような機能を持つのか、それを利用するためにはどのような要求をすれば良いのか、などを記述する方法を定義している。
【００３０】
Ｗｅｂサービスライブラリ１０３は、スタブオブジェクト１０２からのメソッド呼び出しとSOAPメッセージとを相互に変換するモジュールである。
【００３１】
通信ライブラリ１０４は、ネットワーク１０５を通じてサーバアプリケーション１０６との通信を行うモジュールであり、HTTPなどを使用して通信を行う。
【００３２】
サーバアプリケーション１０６は、クライアントから送られたSOAPメッセージに基づき実際にサービスを提供するモジュールであり、処理の結果をSOAPメッセージとしてクライアントに返送する。
【００３３】
このＷｅｂサービスの処理では、クライアントアプリケーション１０１からはスタブオブジェクト１０２のみ見え、サーバアプリケーション１０６ではなくスタブオブジェクト１０２が処理の提供者として認識される。
【００３４】
よって、Ｗｅｂサービスを利用するに当たり、クライアントアプリケーション１０１は、まずスタブオブジェクト１０２の取得を行う。一度取得したスタブオブジェクト１０２はＷｅｂサービスで提供されるメソッドの呼び出しに何度でも使用できる。
【００３５】
次に、クライアントアプリケーション１０１はスタブオブジェクト１０２に対して所望のサーバアプリケーション１０６のＵＲＬ（Uniformed Resource Locater）を設定する。尚、同じサービスを提供しＵＲＬが異なるサーバアプリケーション１０６ａを使用しないのであれば，この処理は一度行えば良い。また、ＵＲＬが異なるサーバアプリケーション１０６ａを使用する場合は、この処理を再度行えば良い。
【００３６】
次に、クライアントアプリケーション１０１がＷｅｂサービスを使用するために、スタブオブジェクト１０２のメソッドを呼び出す（処理１１１）。一方、スタブオブジェクト１０２は、呼び出されたメソッドの引数をＷｅｂサービスライブラリ１０３で処理できるオブジェクトに変換し、Ｗｅｂサービスライブラリ１０３を呼び出す（処理１１２）。
【００３７】
ここで、Ｗｅｂサービスライブラリ１０３はスタブオブジェクト１０２からのメソッド呼び出しをSOAPのメッセージに変換し、通信ライブラリ１０４に対して送信を依頼する（処理１１３）。
【００３８】
通信ライブラリ１０４は、HTTPプロトコルを用いてネットワーク１０５を通じてサーバアプリケーション１０６に対してSOAPメッセージを送信する（処理１１４）。
【００３９】
これにより、サーバアプリケーション１０６は受信したSOAPメッセージを解釈し、所定の処理を行い、その結果をSOAPメッセージとしてHTTPプロトコルを用いて通信ライブラリ１０４に送信する（処理１１５）。
【００４０】
通信ライブラリ１０４は、受信したSOAPメッセージをＷｅｂサービスライブラリ１０３に渡す（処理１１６）。そして、通信ライブラリ１０４からSOAPメッセージを受け取ったＷｅｂサービスライブラリ１０３は、SOAPメッセージをメソッド呼び出しに対する応答に変換し、スタブオブジェクト１０２に返す（処理１１７）。
【００４１】
スタブオブジェクト１０２はＷｅｂサービスライブラリ１０３から返ってきたメソッド呼び出しに対する応答の返値をクライアントアプリケーション１０１の求める型に変換し、クライアントアプリケーション１０１に返す（処理１１８）。
【００４２】
以上の処理により、クライアントアプリケーション１０１からは、通常のメソッド呼び出しを行うだけで、ネットワーク１０５上にあるサーバアプリケーション１０６に対して処理を要求し、返答を得ることができる。
【００４３】
また、クライアントアプリケーション１０１は、同じサーバアプリケーション１０６を利用するのであれば、上述した処理１１１を繰り返せば良い。
【００４４】
上述した処理はＷｅｂサービスの実装方法の一例であり、スタブオブジェクト１０２を使用しない実装も存在する。しかしながら、クライアントアプリケーション１０１からのメソッド呼び出しをSOAPメッセージに変換してサーバアプリケーション１０６に送信し、サーバアプリケーション１０６から返送されたSOAPメッセージをメソッドの返値に変換してクライアントアプリケーション１０１に返すという仕組みはＷｅｂサービスの基本的な構造である。
【００４５】
［第１の実施形態］
次に、図２乃至図４を用いて、本発明に係る第１の実施形態について詳細に説明する。第１の実施形態は、図２に示すように、図１の構成に更にセッション管理テーブル２０１を備え、Ｗｅｂサービスライブラリ１０３がセッション管理テーブル２０１に登録されたセッション管理情報に基づいてセッション管理を行うものである。
【００４６】
図３は、第１の実施形態におけるセッション管理テーブルの構成の一例を示す図である。図３に示すように、第１の実施形態では、セッション管理テーブルは、セッション管理情報としてスタブオブジェクト１０２のオブジェクトID３０１を用い、接続先サーバ情報としてサーバアプリケーションのＵＲＬ３０２とセッション情報３０３とを管理するものである。
【００４７】
また、セッション管理情報としてスタブオブジェクト１０２のオブジェクトID３０１の代わりにクライアントアプリケーション１０１のオブジェクトIDや、スタブオブジェクト１０２やクライアントアプリケーション１０１のオブジェクト自体を使用しても良い。更には、Ｗｅｂサービスライブラリ１０３にUUID（Universally Unique Identifier）のような一意な値を生成させ、そのUUIDをセッション管理情報としても良い。
【００４８】
スタブオブジェクト１０２のオブジェクトID３０１は、クライアントアプリケーション１０１とＷｅｂサービスライブラリ１０３との仲立ちをするスタブオブジェクト１０２のオブジェクトIDであり、このIDはスタブオブジェクト１０２毎に異なるIDとなる。また、クライアントアプリケーション１０１やシステムを再起動した後に、スタブオブジェクト１０２を取得すると、その都度異なるIDとなる。
【００４９】
尚、セッション管理テーブルにおいてクライアントアプリケーション１０１で使用するサーバアプリケーション１０６が変更されることがなければ、サーバアプリケーションのＵＲＬ３０２はなくても良い。
【００５０】
図３に示す３０４、３０５は、セッション管理ID３０１がともに「Stub Object1」で、サーバアプリケーションのＵＲＬ３０２が「http://aaa.com/」、「http://aaa1.com/」で異なる場合に、「Session1」、「Session1A」のように、異なるセッション情報を管理している状態を示している。また、図３に示す３０６は、３０４と比べてセッション管理ID３０１が「Stub Object2」で異なるが、サーバアプリケーションのＵＲＬ３０２は同じ「http://aaa.com/」の場合に、３０４と異なるセッション情報「Session2」を管理している状態を示している。
【００５１】
セッション情報３０３はサーバアプリケーション１０６との通信において、複数の通信を一連のものとして管理する、即ちセッション管理のために使用する情報であり、サーバアプリケーション１０６との通信時にHTTPを使用する場合においてはHTTPヘッダのCookie情報として送信されたり、サーバアプリケーション１０６へのリクエストＵＲＬに付加されて送信されたりする一意な情報である。
【００５２】
ここで、図４を用いて、図３に示すセッション管理テーブルによってセッションを管理し、Ｗｅｂサービスを利用するクライアント側の処理について説明する。
【００５３】
図４は、第１の実施形態におけるＷｅｂサービスの全体的な処理を示すフローチャートである。尚、実線で囲んだ部分はクライアントアプリケーション１０１での処理であり、一点鎖線で囲んだ部分はスタブオブジェクト１０２での処理であり、点線で囲んだ部分はＷｅｂサービスライブラリ１０３での処理であり、二点鎖線で囲んだ部分は通信ライブラリ１０４での処理である。
【００５４】
まず、ステップＳ４０１において、クライアントアプリケーション１０１はスタブオブジェクト１０２を取得する。尚、スタブオブジェクトは再利用可能であるため、この取得処理は一度行えば良く、後述する２回目以降のメソッドの呼び出し処理ではこのステップは不要である。
【００５５】
次に、ステップＳ４０２において、クライアントアプリケーション１０１はスタブオブジェクト１０２に対してサーバアプリケーション１０６のＵＲＬを設定する。次に、ステップＳ４０３において、Ｗｅｂサービスを利用するためにクライアントアプリケーション１０１はスタブオブジェクト１０２のメソッドを呼び出す。もし、セッション管理情報としてＷｅｂサービスライブラリ１０３が発行するUUIDを使用する場合、Ｗｅｂサービスライブラリ１０３に設けられたUUID発行メソッドを呼び出し、UUIDを取得する。取得したUUIDをセッション管理情報としてスタブオブジェクト１０２に設定する。
【００５６】
次に、ステップＳ４０４において、スタブオブジェクト１０２で、クライアントアプリケーション１０１から与えられたメソッドの引数の型変換処理が行われ、Ｗｅｂサービスライブラリ１０３が呼び出される、ここで、スタブオブジェクト１０２はメソッドの引数と共に、自身のオブジェクトIDとステップＳ４０２で設定されたサーバアプリケーション１０６のＵＲＬを引数としてＷｅｂサービスライブラリ１０３に渡す。セッション管理情報がオブジェクトIDではなくＷｅｂサービスライブラリ１０３が発行したUUIDを使用する場合は、UUIDをセッション管理情報としてＷｅｂサービスライブラリ１０３に渡す。
【００５７】
これにより、Ｗｅｂサービスライブラリ１０３では、まずステップＳ４０５において、呼び出されたメソッドに対応するSOAPメッセージを生成する。次に、ステップＳ４０６において、スタブオブジェクト１０２から渡されたスタブオブジェクトのオブジェクトIDとサーバアプリケーションのＵＲＬをキーにセッション管理テーブルの検索を行う。そして、ステップＳ４０７において、その検索結果を判定する。
【００５８】
ステップＳ４０７で、セッション管理テーブルにスタブオブジェクトのオブジェクトIDとサーバアプリケーションのＵＲＬが設定されておらず、対応するセッション情報３０３が存在しなければステップＳ４０９へ進み、通信ライブラリ１０４に対して、スタブオブジェクト１０２から渡されたＵＲＬのサーバアプリケーション１０６へのSOAPメッセージの送信を要求する。
【００５９】
また、ステップＳ４０７で、セッション管理テーブルにスタブオブジェクトのオブジェクトIDとサーバアプリケーションのＵＲＬが設定されており、対応するセッション情報が存在した場合はステップＳ４０８へ進み、通信ライブラリ１０４に対してそのセッション情報３０３をリクエストヘッダに追加するように要求する。そして、ステップＳ４０９において、スタブオブジェクト１０２から渡されたＵＲＬのサーバアプリケーション１０６へのSOAPメッセージの送信を要求する。
【００６０】
一方、通信ライブラリ１０４は、まずステップＳ４１０において、ネットワーク１０５を介してサーバアプリケーション１０６に対してリクエストとしてSOAPメッセージを送信し、レスポンスの受信を待つ。次に、ステップＳ４１１において、通信ライブラリ１０４はサーバアプリケーション１０６からレスポンスを受信すると、そのレスポンスのヘッダ情報とサーバアプリケーション１０６から送られてきた処理の結果であるSOAPメッセージとをＷｅｂサービスライブラリ１０３に渡す。
【００６１】
これにより、Ｗｅｂサービスライブラリ１０３では、まずステップＳ４１２において、レスポンスのヘッダ情報からセッション情報を取得する。次に、ステップＳ４１３において、セッション管理テーブルの検索を行い、ステップＳ４１４において、その検索結果を判定する。
【００６２】
ここで、ステップＳ４１２で取得したセッション情報がセッション管理テーブルに登録されていなければステップＳ４１５へ進み、そのセッション情報をスタブオブジェクトのオブジェクトIDとサーバアプリケーションのＵＲＬに対応させてセッション管理テーブルに登録する。
【００６３】
また、取得したセッション情報がセッション管理テーブルに登録されていればステップＳ４１６へ進み、そのセッション情報に対応させてスタブオブジェクトのオブジェクトIDとサーバアプリケーションのＵＲＬをセッション管理テーブルに登録し、セッション情報を更新する。そして、ステップＳ４１７において、受信したSOAPメッセージをメソッドの返答に変換し、スタブオブジェクト１０２に返す。
【００６４】
次に、ステップＳ４１８において、スタブオブジェクト１０２で、Ｗｅｂサービスライブラリ１０３から返ってきた返値をクライアントアプリケーション１０１の要求する型に変換する。そして、ステップＳ４１９において、クライアントアプリケーション１０１に返す。
【００６５】
これにより、ステップＳ４２０において、スタブオブジェクト１０２から返値を返されたクライアントアプリケーション１０１はメソッド呼び出し処理を終了する。
【００６６】
クライアントアプリケーション１０１が２回目以降にＷｅｂサービスを利用する場合に、同じＵＲＬのサーバアプリケーション１０６を利用するならば、ステップＳ４０３から処理を開始する。また、異なるＵＲＬのサーバアプリケーション１０６ｂを利用する場合はステップＳ４０２から処理を開始する。
【００６７】
尚、以上の説明では、ステップＳ４０７で、セッション管理テーブルにスタブオブジェクトのオブジェクトIDとサーバアプリケーションのＵＲＬが設定されていない場合、ステップＳ４１５で、ステップＳ４１２で取得したセッション情報をスタブオブジェクトのオブジェクトIDとサーバアプリケーションのＵＲＬに対応させてセッション管理テーブルに登録した。
【００６８】
しかしながら、以下のように実現することも可能である。即ち、ステップＳ４０７で、セッション管理テーブルにスタブオブジェクトのオブジェクトIDとサーバアプリケーションのＵＲＬが設定されていない場合、スタブオブジェクトのオブジェクトIDとサーバアプリケーションのＵＲＬに対応させてセッション管理テーブルに登録し、ステップＳ４０９へ進む。そして、ステップＳ４１５で、ステップＳ４１２で取得したセッション情報をスタブオブジェクトのオブジェクトIDとサーバアプリケーションのＵＲＬに対応させてセッション管理テーブルに登録する。
【００６９】
第１の実施形態によれば、複数のクライアントアプリケーションがＷｅｂサービスライブラリを介して同じサーバアプリケーションを利用しても、セッション情報を別々に管理できるので、各クライアントアプリケーションで独立してセッションを張ることができ、クライアントアプリケーション毎に異なる処理状態を維持することができる。
【００７０】
［第２の実施形態］
次に、図５及び図６を用いて、本発明に係る第２の実施形態について詳細に説明する。第１の実施形態では、セッション管理テーブルにセッション管理ID（オブジェクトID）を設定しているが、第２の実施形態はアプリケーションIDを設定し、セッション管理を行うものである。ここで、アプリケーションIDとは、個々のクライアントアプリケーションを識別するための識別子である。
【００７１】
図５は、第２の実施形態におけるセッション管理テーブルの構成の一例を示す図である。図５に示すように、第２の実施形態のセッション管理テーブルは、セッション管理情報としてクライアントアプリケーション１０１の識別子であるアプリケーションID５０１を用い、接続先サーバ情報としてサーバアプリケーションのＵＲＬ５０２とセッション情報５０３とを管理するものである。
【００７２】
尚、アプリケーションID５０１は、クライアントアプリケーションやシステムの再起動などで変わることのないクライアントアプリケーションに固有で、かつ、永続的な識別子であり、例えばクライアントアプリケーションの名称やクライアントアプリケーションに設定されたシリアルナンバーなどである。又は、固定的にアプリが本来有する情報ではなく、第１の実施形態で説明したのようにＷｅｂサービスライブラリから発行されたUUIDをクライアントアプリケーションで永続的に記憶し、アプリケーションID５０１として使用しても良い。
【００７３】
また、第１の実施形態と同様に、セッション管理テーブルにおいてクライアントアプリケーション１０１で使用するサーバアプリケーション１０６が変更されることがなければ、サーバアプリケーションのＵＲＬ５０２はなくても良い。
【００７４】
図５に示す５０４、５０５は、アプリケーションID５０１がともに「ApplD1」で、サーバアプリケーションのＵＲＬ５０２が「http://aaa.com/」、「http://aaa1.com/」で異なる場合に、「Session1」、「Session1A」のように、異なるセッション情報を管理している状態を示している。また、図５に示す５０６は、５０４と比べてアプリケーションID５０１が「ApplD2」で異なるが、サーバアプリケーションのＵＲＬ５０２は同じ「http://aaa.com/」の場合に、５０４と異なるセッション情報「Session2」を管理している状態を示している。
【００７５】
尚、セッション情報５０３は、第１の実施形態で説明したセッション情報３０３と同様な情報である。
【００７６】
ここで、図６を用いて、図５に示すセッション管理テーブルによってセッションを管理し、Ｗｅｂサービスを利用するクライアント側の処理について説明する。
【００７７】
図６は、第２の実施形態におけるＷｅｂサービスの全体的な処理を示すフローチャートである。尚、第２の実施形態でも第１の実施形態と同様に、線の種類によりクライアントアプリケーション１０１、スタブオブジェクト１０２、Ｗｅｂサービスライブラリ１０３、通信ライブラリ１０４で行われる処理を分けている。
【００７８】
まず、ステップＳ６０１において、システムが起動されるとＷｅｂサービスライブラリ１０３は、例えばハードディスクなどの永続記憶装置６００からセッション管理テーブルをクライアントのメモリ上にロードする。ここで永続記憶装置６００からセッション管理テーブルを読み込まず、ステップＳ６０８におけるセッション管理テーブルの検索処理で永続記憶装置６００上のセッション管理テーブルを検索しても良い。
【００７９】
次に、クライアントアプリケーション１０１において、ステップＳ６０２、Ｓ６０４、Ｓ６０５の処理は、第１の実施形態における図４に示したステップＳ４０１〜Ｓ４０３での処理と同じであり、その説明は省略する。
【００８０】
第２の実施形態では、ステップＳ６０３において、スタブオブジェクト１０２に対してアプリケーションID５０１を設定する。ここで、スタブオブジェクト１０２に対してアプリケーションID５０１の設定を行わなければ、第１の実施形態と同様に、セッション管理ID３０１であるスタブオブジェクトのオブジェクトIDとサーバアプリケーションのＵＲＬ３０２とをキーにセッション管理テーブルの検索を行い、得られたセッション情報３０３を用いてサーバアプリケーション１０６へのSOAPメッセージの送信を要求する。
【００８１】
但し、第１の実施形態において、Ｗｅｂサービスライブラリ１０３から発行されたUUIDをセッション管理情報として扱う場合は、セッション管理情報のみでセッション情報の永続記憶を行うか判断できないので、別途、セッション情報の永続管理が必要であることをスタブオブジェクト１０２に設定する。スタブオブジェクト１０２はメソッド呼び出しの際に永続管理が必要であることをＷｅｂサービスライブラリ１０３に伝える。
【００８２】
次に、ステップＳ６０６〜Ｓ６１８に示すスタブオブジェクト１０２、Ｗｅｂサービスライブラリ１０３、通信ライブラリ１０４の処理は、第１の実施形態における図４に示したステップＳ４０４〜Ｓ４１６での処理と同じであり、その説明は省略する。
【００８３】
次に、ステップＳ６１７又はＳ６１８の登録処理又は更新処理が終了すると、ステップＳ６１９において、Ｗｅｂサービスライブラリ１０３は、セッション管理テーブルを永続記憶装置６００に記憶する。尚、ステップＳ７１７又はＳ６１８で永続記憶装置６００上のセッション管理テーブルに対して直接登録処理又は更新処理を行っている場合は、このステップは必要ない。
【００８４】
次に、ステップＳ６２０以降の処理は、第１の実施形態における図４に示したステップＳ４１７以降と同じであり、その説明は省略する。
【００８５】
第２の実施形態によれば、クライアントアプリケーションがセッション管理情報としてアプリケーションIDを指定した場合に、セッション管理情報とセッション情報を関連付けて永続的に記憶するため、クライアントアプリケーションを再起動後でも同じセッション管理情報を指定することにより再起動前のセッション情報を用いて処理を継続して行うことができる。
【００８６】
［第３の実施形態］
次に、図７及び図８を用いて、本発明に係る第３の実施形態について詳細に説明する。第３の実施形態は、第１の実施形態で説明したセッション管理テーブルにサブIDの情報を加え、セッション管理を行うものである。ここで、サブIDの情報は、クライアントアプリケーション内で一意なものであれば、どのようなものでも良い。
【００８７】
図７は、第３の実施形態におけるセッション管理テーブルの構成の一例を示す図である。図７に示すように、第３の実施形態では、セッション管理テーブルは、セッション管理情報としてスタブオブジェクト１０２のオブジェクトID７０１を用い、接続先サーバ情報としてサーバアプリケーションのＵＲＬ７０２、サブID７０３、セッション情報７０４を管理するものである。
【００８８】
尚、第１の実施形態と同様に、セッション管理情報としてスタブオブジェクト１０２のオブジェクトID７０１の代わりにクライアントアプリケーション１０１のオブジェクトIDを使用しても良い。
【００８９】
また、セッション管理テーブルにおいてクライアントアプリケーション１０１で使用するサーバアプリケーション１０６が変更されることがなければ、サーバアプリケーションのＵＲＬ７０２はなくても良い。
【００９０】
図７に示す７０５、７０６は、セッション管理ID７０１がともに「Stub Object1」で、サーバアプリケーションのＵＲＬ７０２もともに「http://aaa.com/」で同じであるが、サブID７０３が「SubID1」、「SubID2」で異なる場合に、「Session1」、「Session1_1」のように、異なるセッション情報を管理することができることを示している。
【００９１】
ここで、図８を用いて、図７に示すセッション管理テーブルによってセッションを管理し、Ｗｅｂサービスを利用するクライアント側の処理について説明する。
【００９２】
図８は、第３の実施形態におけるＷｅｂサービスの全体的な処理を示すフローチャートである。尚、第３の実施形態でも第１の実施形態と同様に、線の種類によりクライアントアプリケーション１０１、スタブオブジェクト１０２、Ｗｅｂサービスライブラリ１０３、通信ライブラリ１０４で行われる処理を分けている。
【００９３】
まず、クライアントアプリケーション１０１において、ステップＳ８０１、Ｓ８０２、Ｓ８０４の処理は、第１の実施形態における図４に示したステップＳ４０１〜Ｓ４０３と同じであり、その説明は省略する。
【００９４】
第３の実施形態では、ステップＳ８０３において、スタブオブジェクト１０２に対してサブID７０３を設定する。ここで、サブID７０３が設定されない場合は、第１の実施形態と同様に動作する。
【００９５】
次に、ステップＳ８０５〜Ｓ８２１に示すスタブオブジェクト１０２、Ｗｅｂサービスライブラリ１０３、通信ライブラリ１０４、クライアントアプリケーション１０１の処理は、第１の実施形態における図４に示したステップＳ４０４〜Ｓ４２０でオブジェクトID７０１とサブID７０３を用いる点が異なるだけで他の処理は同じであり、その説明は省略する。
【００９６】
第３の実施形態によれば、第１の実施形態における効果に加え、サブIDを用いることにより、他のセッション情報を保持したまま同じオブジェクトを使用してサーバへアクセスすることができるため、冗長なオブジェクトを生成しないですむ。
【００９７】
［第４の実施形態］
次に、図９及び図１０を用いて、本発明に係る第４の実施形態について詳細に説明する。第４の実施形態は、第２の実施形態で説明したセッション管理テーブルにサブIDの情報を加え、セッション管理を行うものである。尚、このサブIDの情報は、第３の実施形態と同様に、クライアントアプリケーション内で一意なものであれば、どのようなものでも良い。
【００９８】
図９は、第４の実施形態におけるセッション管理テーブルの構成の一例を示す図である。図９に示すように、第４の実施形態のセッション管理テーブルは、セッション管理情報としてクライアントアプリケーション１０１の識別子であるアプリケーションID９０１を用い、接続先サーバ情報としてサーバアプリケーションのＵＲＬ９０２、サブID９０３、セッション情報９０４を管理するものである。
【００９９】
尚、アプリケーションID９０１は、第２の実施形態と同様な情報である。
【０１００】
また、第２の実施形態と同様に、セッション管理テーブルにおいてクライアントアプリケーション１０１で使用するサーバアプリケーション１０６が変更されることがなければ、サーバアプリケーションのＵＲＬ９０２はなくても良い。
【０１０１】
図９に示す９０５、９０６は、アプリケーションID９０１がともに「ApplD1」で、サーバアプリケーションのＵＲＬ９０２もともに「http://aaa.com/」で同じであるが、サブID９０３が「SubID1」、「SubID2」で異なる場合に、「Session1」、「Session1_1」のよういに、異なるセッション情報を管理することができることを示している。
【０１０２】
ここで、図１０を用いて、図９に示すセッション管理テーブルによってセッションを管理し、Ｗｅｂサービスを利用するクライアント側の処理について説明する。
【０１０３】
図１０は、第４の実施形態におけるＷｅｂサービスの全体的な処理を示すフローチャートである。尚、第４の実施形態でも第２の実施形態と同様に、線の種類によりクライアントアプリケーション１０１、スタブオブジェクト１０２、Ｗｅｂサービスライブラリ１０３、通信ライブラリ１０４で行われる処理を分けている。
【０１０４】
まず、ステップＳ１００１において、システムが起動されるとＷｅｂサービスライブラリ１０３は、例えばハードディスクなどの永続記憶装置１０００からセッション管理テーブルをクライアントのメモリ上にロードする。この管理テーブルの読み込み処理は、第２の実施形態における図６に示したステップＳ６０１での処理と同じである。
【０１０５】
次に、クライアントアプリケーション１０１において、ステップＳ１００２〜Ｓ１００４、Ｓ１００６の処理は、第２の実施形態における図６に示したステップＳ６０２〜Ｓ６０５と同じであり、その説明は省略する。
【０１０６】
第４の実施形態では、ステップＳ１００５において、スタブオブジェクト１０２に対してサブID９０３を設定する。ここで、サブID９０３が設定されない場合は、第２の実施形態と同様に動作する。
【０１０７】
次に、ステップＳ１００７〜Ｓ１０２４に示すスタブオブジェクト１０２、Ｗｅｂサービスライブラリ１０３、通信ライブラリ１０４、クライアントアプリケーション１０１の処理は、第２の実施形態における図６に示したステップＳ６０６〜Ｓ６２３でオブジェクトID９０１とサブID９０３を用いる点が異なるだけで他の処理は同じであり、その説明は省略する。
【０１０８】
第４の実施形態によれば、第２の実施形態における効果に加え、サブIDを用いることにより、他のセッション情報を保持したまま同じオブジェクトを使用してサーバへアクセスすることができるため、冗長なオブジェクトを生成しないですむ。
【０１０９】
［第５の実施形態］
次に、図１１を用いて、本発明に係る第５の実施形態について詳細に説明する。第５の実施形態では、複数のユーザがＷｅｂサービスを利用する場合に、ユーザ毎にセッションを管理するものである。
【０１１０】
図１１は、第５の実施形態におけるセッション管理テーブルリストの構成の一例を示す図である。図１１に示すように、第５の実施形態では、第１乃至第４の実施形態で用いたセッション管理テーブルを、クライアントアプリケーション１０１からＷｅｂサービスを利用するユーザ毎に備え、Ｗｅｂサービスライブラリ１０３が各ユーザを識別するためのユーザ識別子に基づいてセッションを管理するものである。尚、ユーザ識別子は、例えば機器にログインしているユーザのユーザ名などである。
【０１１１】
第１乃至第４の実施形態において、セッション情報検索処理（例えば、図４のステップＳ４０６）で、まずユーザ識別子を取得し、取得したユーザ識別子に対応するセッション管理テーブルをセッション管理テーブルリスト１１００から取得する。そして、取得したセッション管理テーブルに対してセッション情報の検索を行う。
【０１１２】
以上の処理を行うことにより、新たにスタブオブジェクトを生成しなくてもユーザ毎にセッションを管理してＷｅｂサービスを利用することができる。
【０１１３】
［第６の実施形態］
次に、図１２を用いて、本発明に係る第６の実施形態について詳細に説明する。第６の実施形態では、個々のクライアントアプリケーションに対してシステムで一意、かつ永続的なIDを設定し、その永続的なIDに基づいてセッションを管理するものである。ここで、永続的なIDとは、クライアントアプリケーションやシステムの再起動などで変わることのないクライアントアプリケーションに固有で、かつ永続的な識別子であり、クライアントアプリケーションの名称やクライアントアプリケーションに設定されたシリアルナンバーなどである。
【０１１４】
図１２は、第６の実施形態におけるＷｅｂサービスを利用するクライアント側システムの構成の一例を示す図である。図１２には、永続的なIDに関係する部分のみ示しているが、全体的な構成は図２に示した構成と同様である。
【０１１５】
ここで、個々のクライアントアプリケーションからＷｅｂサービスを利用する際の処理について説明する。尚、第６の実施形態におけるクライアント側の処理は、図６を用いて説明した第２の実施形態と同様であり、ここでは異なる処理について説明する。
【０１１６】
まず、クライアントアプリケーションＡ１２０１ａは、第２の実施形態と同様に、設定された永続的なIDを指定してアプリケーションＡ用スタブ１２０２ａのメソッドを呼び出す。次に、アプリケーションＡ用スタブ１２０２ａは、クライアントアプリケーションＡ１２０１ａで設定された永続的なIDを引数に追加してＷｅｂサービスライブラリ１２０３を呼び出す。
【０１１７】
これにより、Ｗｅｂサービスライブラリ１２０３では、永続的なIDをキーにしてセッション管理テーブル１２１０からセッション情報を検索し、取得したセッション情報を付加してサーバアプリケーション１２０４に対してSOAPメッセージを送り、Ｗｅｂサービスを利用する。
【０１１８】
また、クライアントアプリケーションＢ１２０１ｂは、第２の実施形態と同様に、設定された永続的なIDを指定してアプリケーションＢ用スタブ１２０２ｂのメソッドを呼び出す。次に、アプリケーションＢ用スタブ１２０２ｂは、クライアントアプリケーションＢ１２０１ｂで設定された永続的なIDを引数に追加してＷｅｂサービスライブラリ１２０３を呼び出す。
【０１１９】
これにより、Ｗｅｂサービスライブラリ１２０３では、永続的なIDをキーにしてセッション管理テーブル１２１０からセッション情報を検索し、取得したセッション情報を付加してサーバアプリケーション１２０４に対してSOAPメッセージを送り、Ｗｅｂサービスを利用する。
【０１２０】
以上の処理を行うことにより、異なるクライアントアプリケーション間で同じ永続的なIDを使用することにより、異なるクライアントアプリケーション間でも同一のセッション情報を使ってＷｅｂサービスを利用することができる。
【０１２１】
［第７の実施形態］
次に、図１３を用いて、本発明に係る第７の実施形態について詳細に説明する。第７の実施形態では、第６の実施形態で設定した永続的なIDだけでなくサブIDも設定し、永続的なIDとサブIDとに基づいてセッションを管理するものである。ここで、サブIDは、個々のクライアントアプリケーションで一意なものであればどのようなものでも良い。
【０１２２】
図１３は、第７の実施形態におけるＷｅｂサービスを利用するクライアント側システムの構成の一例を示す図である。図１３には、永続的なIDに関係する部分のみ示しているが、全体的な構成は図２に示した構成と同様である。
【０１２３】
ここで、個々のクライアントアプリケーションからＷｅｂサービスを利用する際の処理について説明する。尚、第７の実施形態におけるクライアント側の処理は、図１０を用いて説明した第４の実施形態と同様であり、ここでは異なる処理について説明する。
【０１２４】
まず、クライアントアプリケーションＡ１３０１ａは、第４の実施形態と同様に、設定された永続的なIDとサブIDとを指定してアプリケーションＡ用スタブ１３０２ａのメソッドを呼び出す。次に、アプリケーションＡ用スタブ１３０２ａは、クライアントアプリケーションＡ１３０１ａで設定された永続的なIDとサブIDとを引数に追加してＷｅｂサービスライブラリ１３０３を呼び出す。
【０１２５】
これにより、Ｗｅｂサービスライブラリ１３０３では、永続的なIDとサブIDとをキーにしてセッション管理テーブル１３１０からセッション情報を検索し、取得したセッション情報を付加してサーバアプリケーション１３０４に対してSOAPメッセージを送り、Ｗｅｂサービスを利用する。
【０１２６】
また、クライアントアプリケーションＢ１３０１ｂは、第４の実施形態と同様に、設定された永続的なIDとサブIDとを指定してアプリケーションＢ用スタブ１３０２ｂのメソッドを呼び出す。次に、アプリケーションＢ用スタブ１３０２ｂは、クライアントアプリケーションＢ１３０１ｂで設定された永続的なIDとサブIDとを引数に追加してＷｅｂサービスライブラリ１３０３を呼び出す。
【０１２７】
これにより、Ｗｅｂサービスライブラリ１３０３では、永続的なIDとサブIDとをキーにしてセッション管理テーブル１３１０からセッション情報を検索し、取得したセッション情報を付加してサーバアプリケーション１３０４に対してSOAPメッセージを送り、Ｗｅｂサービスを利用する。
【０１２８】
以上の処理を行うことにより、異なるクライアントアプリケーション間で同じ永続的なIDとサブIDとを使用することにより、異なるクライアントアプリケーション間でも同一のセッション情報を使ってＷｅｂサービスを利用することができる。
【０１２９】
［第８の実施形態］
次に、図１４を用いて、本発明に係る第８の実施形態について詳細に説明する。第８の実施形態では、第１及び第３の実施形態での処理に加えてスタブオブジェクト及びＷｅｂサービスライブラリがセッションの初期化を行うものである。
【０１３０】
図１４は、第８の実施形態におけるセッション初期化処理を示すフローチャートである。尚、実線で囲んだ部分はクライアントアプリケーション１０１での処理であり、一点鎖線で囲んだ部分はスタブオブジェクト１０２での処理であり、点線で囲んだ部分はＷｅｂサービスライブラリ１０３での処理である。
【０１３１】
まず、ステップＳ１４０１において、同一のセッションとして行われてきたＷｅｂサービスの利用が終了し、新たなセッションでのＷｅｂサービスの利用を行うために、クライアントアプリケーション１０１はサーバアプリケーションのＵＲＬを設定し、スタブオブジェクト１０２に対してセッションの初期化を依頼する。
【０１３２】
次に、ステップＳ１４０２において、スタブオブジェクト１０２はＷｅｂサービスライブラリ１０３に対してスタブオブジェクトのオブジェクトIDとサーバアプリケーションのＵＲＬを引数としてセッションの初期化を依頼する。
【０１３３】
これにより、Ｗｅｂサービスライブラリ１０３では、まずステップＳ１４０３において、ステップＳ１４０２で渡されたスタブオブジェクトのオブジェクトIDとサーバアプリケーションのＵＲＬをキーにセッション管理テーブルの検索を行う。次に、ステップＳ１４０４において、スタブオブジェクトのオブジェクトIDとサーバアプリケーションのＵＲＬに対応するセッション情報が存在するか否かを判定する。ここで、存在すればステップＳ１４０５へ進み、セッション管理テーブルからセッション情報を削除し、このセッション初期化処理を終了する。また、セッション情報が存在しなければ、このセッション初期化処理を終了する。
【０１３４】
第８の実施形態によれば、第１及び第３の実施形態における効果に加え、クライアントアプリケーションからセッションIDを初期化することで、同じオブジェクトの使い回しが行え、冗長なオブジェクトを生成しないですむ。
【０１３５】
［第９の実施形態］
次に、図１５を用いて、本発明に係る第９の実施形態について詳細に説明する。第９の実施形態では、第２及び第４の実施形態での処理に加えてスタブオブジェクト及びＷｅｂサービスライブラリがセッションの初期化を行うものである。
【０１３６】
図１５は、第９の実施形態におけるセッション初期化処理を示すフローチャートである。尚、第９の実施形態でも第８の実施形態と同様に、線の種類によりクライアントアプリケーション１０１、スタブオブジェクト１０２、Ｗｅｂサービスライブラリ１０３で行われる処理を分けている。
【０１３７】
まず、ステップＳ１５０１において、クライアントアプリケーション１０１は、スタブオブジェクト１０２に対して予めアプリケーションIDの設定を行う。そして、ステップＳ１５０２において、同一のセッションとして行われてきたＷｅｂサービスの利用が終了し、新たなセッションでのＷｅｂサービスの利用を行うために、サーバアプリケーションのＵＲＬを設定し、スタブオブジェクト１０２に対してセッションの初期化を依頼する。
【０１３８】
次に、ステップＳ１５０３において、スタブオブジェクト１０２はＷｅｂサービスライブラリに対してアプリケーションIDとサーバアプリケーションのＵＲＬを引数としてセッションの初期化を依頼する。
【０１３９】
これにより、Ｗｅｂサービスライブラリ１０３では、まずステップＳ１５０４において、ステップＳ１５０３で渡されたアプリケーションIDとサーバアプリケーションのＵＲＬをキーにセッション管理テーブルの検索を行う。次に、ステップＳ１５０５において、アプリケーションIDとサーバアプリケーションのＵＲＬに対応するセッション情報が存在するか否かを判定する。ここで、存在すればステップＳ１５０６へ進み、セッション管理テーブルからセッション情報を削除し、このセッション初期化処理を終了する。また、セッション情報が存在しなければ、このセッション初期化処理を終了する。
【０１４０】
第９の実施形態によれば、第２及び第４の実施形態における効果に加え、クライアントアプリケーションからセッションIDを初期化することで、同じオブジェクトの使い回しが行え、冗長なオブジェクトを生成しないですむ。
【０１４１】
尚、本発明は複数の機器（例えば、ホストコンピュータ，インターフェース機器，リーダ，プリンタなど）から構成されるシステムに適用しても、１つの機器からなる装置（例えば、複写機，ファクシミリ装置など）に適用しても良い。
【０１４２】
また、本発明の目的は、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記録媒体を、システム或いは装置に供給し、そのシステム或いは装置のコンピュータ（ＣＰＵ若しくはＭＰＵ）が記録媒体に格納されたプログラムコードを読出し実行することによっても、達成されることは言うまでもない。
【０１４３】
この場合、記録媒体から読出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記録媒体は本発明を構成することになる。
【０１４４】
このプログラムコードを供給するための記録媒体としては、例えばフロッピー（登録商標）ディスク，ハードディスク，光ディスク，光磁気ディスク，ＣＤ−ＲＯＭ，ＣＤ−Ｒ，磁気テープ，不揮発性のメモリカード，ＲＯＭなどを用いることができる。
【０１４５】
また、コンピュータが読出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）などが実際の処理の一部又は全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１４６】
更に、記録媒体から読出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部又は全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【図面の簡単な説明】
【０１４７】
【図１】Ｗｅｂサービスが行われるシステムの構成の一例を示す図である。
【図２】セッション管理テーブルを用いてＷｅｂサービスが行われるシステムの構成の一例を示す図である。
【図３】第１の実施形態におけるセッション管理テーブルの構成の一例を示す図である。
【図４】第１の実施形態におけるＷｅｂサービスの全体的な処理を示すフローチャートである。
【図５】第２の実施形態におけるセッション管理テーブルの構成の一例を示す図である。
【図６】第２の実施形態におけるＷｅｂサービスの全体的な処理を示すフローチャートである。
【図７】第３の実施形態におけるセッション管理テーブルの構成の一例を示す図である。
【図８】第３の実施形態におけるＷｅｂサービスの全体的な処理を示すフローチャートである。
【図９】第４の実施形態におけるセッション管理テーブルの構成の一例を示す図である。
【図１０】第４の実施形態におけるＷｅｂサービスの全体的な処理を示すフローチャートである。
【図１１】第５の実施形態におけるセッション管理テーブルリストの構成の一例を示す図である。
【図１２】第６の実施形態におけるＷｅｂサービスを利用するクライアント側システムの構成の一例を示す図である。
【図１３】第７の実施形態におけるＷｅｂサービスを利用するクライアント側システムの構成の一例を示す図である。
【図１４】第８の実施形態におけるセッション初期化処理を示すフローチャートである。
【図１５】第９の実施形態におけるセッション初期化処理を示すフローチャートである。
【符号の説明】
【０１４８】
１０１  クライアントアプリケーション
１０２  スタブオブジェクト
１０３  Ｗｅｂサービスライブラリ
１０４  通信ライブラリ
１０５  ネットワーク
１０６  サーバアプリケーション
２０１  セッション管理テーブル
【図１】
2006244428.tif 000003
【図２】
2006244428.tif 000004
【図３】
2006244428.tif 000005
【図４】
2006244428.tif 000006
【図５】
2006244428.tif 000007
【図６】
2006244428.tif 000008
【図７】
2006244428.tif 000009
【図８】
2006244428.tif 000010
【図９】
2006244428.tif 000011
【図１０】
2006244428.tif 000012
【図１１】
2006244428.tif 000013
【図１２】
2006244428.tif 000014
【図１３】
2006244428.tif 000015
【図１４】
2006244428.tif 000016
【図１５】
2006244428.tif 000017