JP6039446B2 - Ｗｅｂサーバ装置、制御方法、そのプログラム。 - Google Patents

Description

本発明は、ＩＰＰサービスを利用するリクエストを処理するＷｅｂサーバ装置、制御方法、そのプログラムに関する。

従来、単一のＷｅｂサーバ上に複数のＷｅｂサービスを動作させるシステムが増加している。例えば、プリンタでは機器設定・管理サービス（以下ＲｅｍｏｔｅＵＩ）、ＩＰＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｉｎｔｉｎｇ Ｐｒｏｔｏｃｏｌ）、またはＷＳＤ（Ｗｅｂ Ｓｅｒｖｉｃｅｓ ｏｎ Ｄｅｖｉｃｅｓ）といったＷｅｂベースの印刷サービス等を単一のＷｅｂサーバ上で動作させている。

単一のＷｅｂサーバ上で複数のＷｅｂサービスを動作させる場合、それぞれのＷｅｂサービスに対してユニークなＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）を割り当てる必要がある。なぜならば、ＷｅｂサーバはＷｅｂサーバ上で動作するＷｅｂサービスへのリクエストを受信すると、リクエストデータのＨＴＴＰヘッダに含まれるＵＲＬ情報をもとに、そのリクエストをどのＷｅｂサービスに送信し実行させるかを判断する必要があるためである。

よって、ＷｅｂサービスとＵＲＬは１対１で対応づけられなくてはならない。そのため、従来は機器に搭載するＷｅｂサービスにはそれぞれ異なるＵＲＬが割り当てられるようにシステムを構築する必要があった。

また、特許文献１にはＷｅｂサーバの負荷を軽減するために、ＵＲＬのアプリケーションパスのみ登録する技術が開示されている。

特開２００８−１７６７８９号公報

しかしながら、単一のＷｅｂサーバ上で動作するＷｅｂサービスに対して同一のＵＲＬを利用したい場合がある。例えば、ユーザの入力を簡略化させるために、画像形成装置を指定する「ｈｔｔｐ：／／ＩＰアドレス／」のパスと、Ｗｅｂサービスを指定するための単一のＩＰアドレスから構成されるＨＴＴＰパスを規定する。このパスを知っていれば、ルートパス（“／”）でサービスを利用できるようになるので、ユーザはＩＰアドレスさえ覚えていればＷｅｂサービスを利用できるようになり利便性が高い。即ち、異なるＷｅｂサービスのＵＲＬを単一にすることで、ユーザはそれぞれのＷｅｂサービスのＵＲＬを覚える必要がなくなる。

しかし、このような形態をとった場合、ＵＲＬとＷｅｂサービスが１対複数の対応となってしまい、Ｗｅｂサーバは受信したＵＲＬに対して、どのＷｅｂサービスにリクエストを振れば良いのかを特定することができない。

そこで、本願発明の目的の１つは、単一のＷｅｂサーバ上で動作する複数のＷｅｂサービスが同一のＵＲＬで動作する場合、Ｗｅｂサーバは受信したＨＴＴＰリクエストからどのＷｅｂサービスを呼び出すべきかを特定するＷｅｂサーバ装置を提供することにある。

本発明の一実施例に係るウェブサーバ装置は、複数のウェブサービスを有するウェブサーバ装置であって、ネットワークを介して少なくともＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）リクエストを受信する受信手段と、条件テーブルが記憶された記憶手段と、前記受信手段によって受信されたＨＴＴＰリクエストと、前記記憶手段に記憶された条件テーブルに基づいて呼び出すべきウェブサービスを決定する決定手段と、前記決定手段によって決定されたウェブサービスを呼び出す呼び出し手段と、を備え、前記記憶手段が記憶する前記条件テーブルには、前記ウェブサーバ装置が有する少なくとも１つのウェブサービスに対応付けて、ＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）と所定の判断条件が記憶されており、更に、前記条件テーブルは記憶する所定の判断条件を異ならせることで、互いに異なるウェブサービスに同一のＵＲＬを対応付けることが可能であり、前記決定手段は、前記受信手段によって受信されたＨＴＴＰリクエストに含まれるリクエストＵＲＬとＨＴＴＰヘッダー内の情報が、前記条件テーブル内の前記ＵＲＬと前記所定の判断条件の組み合わせに一致する場合、当該一致する前記ＵＲＬと前記所定の判断条件の組み合わせに対応付けられたウェブサービスを呼び出すべきウェブサービスとして決定することを特徴とする。

単一のＷｅｂサーバ上で動作する複数のＷｅｂサービスが同一のＵＲＬで動作する場合でも、Ｗｅｂサーバは受信したＨＴＴＰリクエストからどのＷｅｂサービスを呼び出すべきかを特定することができる。

本発明のシステム構成図 Ｗｅｂサーバ装置１００のハードウェア構成図 Ｗｅｂサーバ１２０の内部モジュール構成図 Ｗｅｂサービス１４０、１５０、１６０、１７０の内部モジュール構成図 Ｗｅｂサービス管理テーブルを示す図 Ｗｅｂサービス登録部１４１により実行されるフロー Ｗｅｂサービス登録処理部１２１により実行されるフロー Ｗｅｂサービス判断処理部１２４により実行されるフロー Ｗｅｂサーバ１２０、または各Ｗｅｂサービスへ送信されるリクエストデータを示す図

以下、本発明を実施するための最良の形態について図面を用いて説明する。

実施例１では、複数のＷｅｂサービスのＵＲＬが重複した場合であっても、Ｗｅｂサーバの機能によりリクエストを処理するＷｅｂサービスを特定することを可能にする発明について説明する。

図１は、本実施形態に係るＷｅｂサーバ装置とＷｅｂサービスクライアント装置の全体構成を示す図である。

図１において、Ｗｅｂサーバ装置１００とＷｅｂクライアント装置３００は、ネットワーク２００を介して接続されている。ネットワーク２００とは、インターネットであっても、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）であってもよい。

Ｗｅｂサーバ装置１００にはネットワーク通信を行う通信部１３０とＷｅｂサーバ機能を提供するＷｅｂサーバ１２０とＷｅｂサーバ上で動作してなんらかのサービスを提供するＷｅｂサービス１４０，１５０，１６０，１７０が存在する。ここで言うサービスとは、例えば、上述したＲｅｍｏｔｅＵＩサービス、ＩＰＰサービスの他にＷｅｂＤＡＶサービス等のＷｅｂサービスが有する機能のことを指す。Ｗｅｂサーバ１２０はＨＴＴＰ通信でＨＴＴＰのリクエストを受信し、リクエストで指定されたＷｅｂサービスにリクエストを割り振り、Ｗｅｂサービスにサービスを提供させる。Ｗｅｂサービス１４０，１５０，１６０，１７０は例えばＣＧＩ（Ｃｏｍｍｏｎ Ｇａｔｅｗａｙ Ｉｎｔｅｒｆａｃｅ）やサーブレットに相当する機能である。これらのＷｅｂサービスはＷｅｂサーバ１２０に対してＷｅｂサービスの判断条件（拡張判断条件）を登録する。そして、Ｗｅｂサーバ１２０がその拡張判断条件に一致するリクエストを受信するとその条件に合致するＷｅｂサービスにリクエストを割り振り、ＷｅｂサービスがＨＴＴＰリクエストで指定された処理を行い、Ｗｅｂサービスを提供する。

Ｗｅｂクライアント装置３００はＷｅｂサービスクライアント３２０，３３０，３４０，３５０を有する。Ｗｅｂサービスクライアントには、受信したＨＴＭＬデータを表示するＷｅｂブラウザ、Ｗｅｂサービスの所有するストレージに対してデータの保存、取得などを行うＷｅｂＤＡＶクライアント、Ｗｅｂサービスが提供する印刷サービスを利用した印刷を行うＷＳＤ Ｐｒｉｎｔ、またはＨＴＴＰクライアントがある。これらはＷｅｂサービスとＨＴＴＰ通信を行い、Ｗｅｂサービスに対して処理の依頼行い、依頼した処理結果を受信し、受信結果をユーザに提供する機能を備えるものである。

Ｗｅｂサービスクライアントは、Ｗｅｂサービスに処理を依頼する場合、Ｗｅｂクライアント装置３００の通信部を利用してＷｅｂサーバ１２０にＨＴＴＰリクエストを送信する。Ｗｅｂサーバ１２０はリクエストを受信するとリクエストのＨＴＴＰヘッダ部を解析し、Ｗｅｂサービスが登録した拡張判断条件に合致したリクエストであるか否かを判断する。判断の結果、リクエストがサービス判断条件に合致していると判断された場合、Ｗｅｂサーバ１２０はＷｅｂサービス処理関数を実行する。Ｗｅｂサービスは、Ｗｅｂサーバ１２０によりＷｅｂサービス処理関数が実行されると、必要に応じてＨＴＴＰのオペレーションや受信したＨＴＴＰボディ部のデータに従ってリクエストの処理を行い、サービスを提供する。

Ｗｅｂサーバ装置１００の通信部１３０、Ｗｅｂサーバ１２０、Ｗｅｂサービス（１４０，１５０，１６０，１７０）は図２のＷｅｂサーバ装置１００のＲＯＭ（１０２）、ＨＤＤ（１０３）に記録されＣＰＵ１０１により実行さる。

図２は本実施例におけるＷｅｂサーバ装置１００のハードウェア構成の一例を示すブロック図である。本図はＷｅｂサーバ装置１００がプリンタ機能を備える場合を代表例として図示する。即ち、Ｗｅｂサーバ装置１００はプリンタであって、スキャナ機能（不図示）を備えている複合機であっても良い。ストレージサーバ機能をそなえる装置１００は、ＣＰＵ（中央処理装置）１０１を備えている。

このＣＰＵ１０１は、ＲＯＭ（リードオンリーメモリ）１０２、またはＨＤＤ（ハードディスクドライブ）１０３に格納されているプログラムを実行し、システムバス１０４に接続される各ユニットを総括的に制御する。１０３はＲＡＭ（ランダムアクセスメモリ）で、ＣＰＵ１０１の主メモリ、ワークエリアとして機能する。１０５はストレージサーバ機能をそなえる装置のコントロールユニットであり、プリントエンジンであるＰｒｉｎｔｅｒ１０６、またはＨＤＤ１０３を制御する装置である。

Ｗｅｂサーバ装置１００のＣＰＵ１０１は、ＲＯＭ１０２、またはハードディスク１０３に記憶されたプログラムを実行することにより本実施形態のソフトウェア構成が実現される。１０７は不揮発性のメモリＮＶＲＡＭであり、Ｗｅｂサーバ装置１００の動作を規定する各種設定値を保存するためのものである。パネル制御部１０８は、オペレーションパネル１０９を制御し、各種情報の表示、使用者からの指示入力を行なう。ネットワークＩ／Ｆ制御部１１０は、ネットワーク２００とのデータの送受信を制御する。

なお、Ｗｅｂクライアント装置３００も図２で示すハードウェア構成であり、図１で示すソフトウェアは、ＣＰＵ１０１がＲＯＭ１０２、またはＨＤＤ１０３に記憶されたプログラムを実行することで実現される機能である。なお、実施例１で想定しているＷｅｂクライアント装置３００は一般的なパーソナルコンピュータ、またはスマートフォンを始めとするモバイル端末と言った情報処理装置を想定しおり、プリント機能を始めとする画像形成機能を有していない。よって、Ｗｅｂクライアント装置３００は、Ｐｒｉｎｔｅｒ１０６、ＣｏｎｔｒｏｌＵｎｉｔ１０５を備えていない情報処理装置である。

図３はＷｅｂサーバ１２０の内部モジュールを説明する図である。Ｗｅｂサーバ１２０はＷｅｂサービス１４０からＷｅｂサービスの登録要求を受け付けるＷｅｂサービス登録処理部１２１を備える。Ｗｅｂサービスの登録要求とは、Ｗｅｂサーバ１２０にＷｅｂサービスを登録するための要求であり、登録されたＷｅｂサービスは、Ｗｅｂサーバ１２０がＷｅｂサービスクライアントから受信したリクエストを実行することが可能になる。Ｗｅｂサービス登録処理部１２１は、登録要求を送ったＷｅｂサービスのＵＲＬが重複する場合でもＷｅｂサービスを特定することが可能となる拡張判断条件と、Ｗｅｂサービスを呼び出す処理関数をＷｅｂサービス管理テーブル１２２に記録する機能を備える。

Ｗｅｂサービス管理テーブル１２２は、例えば図５（Ａ）〜図５（Ｄ）に示すような構造をもつ。本実施例では、Ｗｅｂサービス管理テーブルはＷｅｂサービスが実行されるポート番号毎にテーブルを作成するものとして説明する。これは、例えばＴＣＰポート８０番号で提供するＷｅｂサービスと、ＴＣＰポート８８番で提供するＷｅｂサービスが存在する場合、管理テーブルはＴＣＰポート８０番用とＴＣＰポート８８番用の２つが作成されることを意味する。ポート番号毎にＷｅｂサービス管理テーブルを作成することで、Ｗｅｂサーバ１２は該当するＷｅｂサービスをより早く見つけることができる。

リクエスト（ＨＴＴＰヘッダ）受信部１２３はネットワークからＷｅｂサーバへのリクエストにおけるＨＴＴＰヘッダ部を受信する機能を備える。Ｗｅｂサービス判断部１２４はリクエスト（ＨＴＴＰヘッダ）受信部１２３が受信したリクエストのＨＴＴＰヘッダ情報を分析し、Ｗｅｂサービス管理テーブル１２２に登録されたＷｅｂサービスの拡張判断条件と一致するＷｅｂサービスを特定する機能を備える。

Ｗｅｂサービス実行部１２５はＷｅｂサービス判断部１２４が特定したＷｅｂサービスを実行し、特定されたＷｅｂサービスに対するＨＴＴＰの通信機能を備える。このＨＴＴＰの通信機能とは、例えばＨＴＴＰ ボディ部の受信で、およびＨＴＴＰプロトコルに従ってＨＴＴＰレスポンスの送信を行う機能である。

図４はＷｅｂサービス１４０の内部モジュールを説明する図である。Ｗｅｂサービス登録部１４１はＷｅｂサービス起動時にＷｅｂサービスが有効か無効かを判断し、有効である場合Ｗｅｂサービス登録処理部１２１に対してＵＲＬと、Ｗｅｂサービスの拡張判断条件と、Ｗｅｂサービスの処理関数を登録する機能を備える。Ｗｅｂサービス処理部１４２はＷｅｂサービスの処理を行う機能を備える。具体的にはＷｅｂサービス実行部１２５から呼ばれるサービス処理関数の処理が相当し、各Ｗｅｂサービス特有の処理を行う機能を備える。

ここでＷｅｂサービス登録部１４１の具体的な処理を図６のフローチャートを用いて説明する。ＲＡＭ，ＲＯＭ，ＨＤＤのいずれかの記憶手段に記憶され、ＣＰＵにより実行されるＷｅｂサービス登録部１４１は、Ｗｅｂサービスが起動すると自身のＷｅｂサービスの設定を確認して（Ｓ１００）Ｗｅｂサービスの有効、無効を判断する。

Ｗｅｂサービスが無効である場合、ＷｅｂサーバにＷｅｂサービス情報を登録する必要が無いため、ＷｅｂサーバにＷｅｂサービス情報を登録することなく処理を終了させる。Ｗｅｂサービスが有効である場合、Ｗｅｂサーバに登録するＷｅｂサービスの実行判断条件を確認し、ＵＲＬ情報のみ登録するか、ＵＲＬ情報以外の拡張判断条件も登録するかを判断する（Ｓ１０１）。このサービスの拡張判断条件はＷｅｂサービス固有の属性であっても、管理者がＷｅｂサービスに対して設定してもどちらでもよい。

ＵＲＬ情報のみを登録する場合、ＵＲＬ情報とＷｅｂサービス処理関数を登録する（Ｓ１０２）。もし、ＵＲＬ情報以外にも拡張判断条件が存在する場合、Ｗｅｂサーバに対してＵＲＬ情報と、拡張判断条件の対応と、Ｗｅｂサービス処理関数とを登録する（Ｓ１０３）。

前述のＷｅｂサービスに登録するＵＲＬ情報について補足する。一般的にＵＲＬとはＲＦＣ １７３８に定められたフォーマットを示す。しかし、ここでのＷｅｂサービスに登録するＵＲＬ情報とはＲＦＣ１７３８で定められた情報ではなく、プロトコル（ＨＴＴＰ／ＨＴＴＰＳ）、サービスを提供するＴＣＰポート番号、ＵＲＬ ＰＡＴＨ情報を意味する。

また、上述の拡張判断条件とはＨＴＴＰヘッダに記載された情報であれば何でもよい。例えばＨＴＴＰ Ｏｐｅｒａｔｉｏｎ、ＨＴＴＰヘッダのＣｏｎｔｅｎｔ−Ｔｙｐｅ、ＵｓｅｒＡｇｅｎｔ、ＲＦＣ８２２で定義されるようにアプリケーションが拡張したｘ−で始まるＨＴＴＰ拡張ヘッダ情報などである。仮に、ＷｅｂサービスがＷｅｂサーバに対して拡張判断条件を登録すると、ＷｅｂサーバはＵＲＬ情報が一致した場合であっても、拡張判断条件も一致しない限りそのＷｅｂサービスの処理関数を用いてＷｅｂサービスを呼び出さない。なお、２つ以上の拡張判断条件を基に判断を行う構成であっても良い。例えば、ＵＲＬ Ｐａｔｈが同一であるためＨＴＴＰ Ｏｐｅｒａｔｉｏｎで判断した結果、ＨＴＴＰ Ｏｐｅｒａｔｉｏｎでも同一となってしまう場合は、更にＣｏｎｔｅｎｔ−Ｔｙｐｅで判断する、と言った構成である。これにより、ＷｅｂサービスはＷｅｂサーバに対してＵＲＬ以外の拡張判断条件を登録することができる。

次に、ＷｅｂサーバにおけるＷｅｂサービス登録処理について説明する。

Ｗｅｂサービス登録処理部１２１はＲＡＭ，ＲＯＭ，ＨＤＤのいずれかの記憶手段に記憶され、ＣＰＵにより実行される。ここではＷｅｂサービス登録処理部１２１の処理フロー（図７）を、図５を用いて説明する。

最初に、（図５（Ａ））の説明をする。図５（Ａ）は次の状態を示したものである。

Ｗｅｂサービス管理テーブルのＴＣＰポート８０番のサービスとしてＲｅｍｏｔｅＵＩサービス（１５０）と、ＷｅｂＤＡＶサービス（１７０）が登録されている状態である。ＲｅｍｏｔｅＵＩサービスはＵＲＬ Ｐａｔｈとして”／”で登録されている。一方、ＷｅｂＤＡＶサービスはＵＲＬ Ｐａｔｈのみ”／ｓｈａｒｅ”を登録している。Ｗｅｂサーバは拡張判断条件としてＨＴＴＰ Ｏｐｅｒａｔｉｏｎフィールドを設けているが、ＲｅｍｏｔｅＵＩサービス、ＷｅｂＤＡＶサービスは共に指定されていない。

Ｗｅｂサービス管理テーブルが図５（Ａ）の状態で、Ｗｅｂサービス登録処理部１２１がＨＴＴＰのＷｅｂサービス（１４０）の登録をリクエストしたものとして、図７のフローチャートを説明する。ＨＴＴＰのＷｅｂサービスはＴＣＰポート番号を”８０”で、ＵＲＬ Ｐａｔｈを”／”で指定し、サービス判断条件の１つであるＨＴＴＰ Ｏｐｅｒａｔｉｏｎを”ＰＯＳＴ”でリクエストしたとする。

Ｗｅｂサービス登録処理部（１２１）はＷｅｂサービス（１４０）からＷｅｂサービス登録要求を受け付けると、ＨＴＴＰのＷｅｂサービス登録部（１４１）から指定されたＵＲＬ情報のＴＣＰポート番号を確認する（Ｓ２００）。

Ｗｅｂサービス登録処理部（１２１）は指定されたＴＣＰポート番号に対応するＷｅｂサービス管理テーブルがＷｅｂサービス管理テーブル（１２２）に存在するかどうかを判断する（Ｓ２０１）。Ｗｅｂサービス管理テーブルが存在しない場合、Ｗｅｂサービス登録処理部（１２１）は指定ＴＣＰポート番号用のＷｅｂサービス管理テーブルを新規に作成する（Ｓ２０６）。そしてＷｅｂサービス登録処理部（１２１）は、作成したＷｅｂサービス管理テーブルに対して指定されたサービス名と、ＵＲＬ Ｐａｔｈと、拡張判断条件を登録し（Ｓ２０７）、Ｗｅｂサービス登録受付処理は完了となる。このとき、ＷｅｂサービスからＵＲＬ情報以外の拡張判断条件が指定されていない場合、拡張判断条件のフィールドはブランクフィールドとなり無視される。拡張判断条件のフィールドがブランクフィールドの場合は、ＵＲＬ Ｐａｔｈが一致した時点でそのＷｅｂサービスが、送信されたリクエストを処理するＷｅｂサービスとして特定される。拡張判断条件がブランクフィールドのＷｅｂサービスが登録された場合、仮にリクエストに含まれる拡張判断条件と登録済みの拡張判断条件が一致することがなくとも、何れかのＷｅｂサービスが必ず実行される構成となっている。

ここでは、ＩＰＰサービスはＴＣＰポート８０番を指定しているため、Ｗｅｂサービス管理テーブル（１２２）での存在が確認された結果（Ｓ２０１）、図５（Ａ）のＷｅｂサービス管理テーブルが検索されることになる。Ｗｅｂサービス管理テーブルを発見すると、そこからＷｅｂサービス登録要求と同じＵＲＬ Ｐａｔｈが登録されているか否かが判断される（Ｓ２０２）。即ち、何れかのＷｅｂサービス同士のＵＲＬが重複しているか否かの確認が行われる。この結果、同じＵＲＬ Ｐａｔｈのサービスが存在しない場合はＷｅｂサービス登録テーブルの末尾に今回の登録される新規サービス情報を登録する（Ｓ２０７）。今回、ＩＰＰサービスのＵＲＬ Ｐａｔｈは”／”であるため図５（Ａ）のＮｏ１に登録されたＲｅｍｏｔｅＵＩのＵＲＬ Ｐａｔｈと一致することになり、Ｗｅｂサービス登録要求と同じＵＲＬ Ｐａｔｈが登録されていると判断される（Ｓ２０２）。

ＵＲＬ Ｐａｔｈが一致した場合、さらに拡張判断条件を用いた比較を行う（Ｓ２０３）。今回の例ではＷｅｂサーバは拡張判断条件としてＨＴＴＰ Ｏｐｅｒａｔｉｏｎが存在する。そこでＲｅｍｏｔｅＵＩサービスのＨＴＴＰ ＯｐｅｒａｔｉｏｎとＩＰＰサービスが登録しようとしているＨＴＴＰ Ｏｐｅｒａｔｉｏｎを比較する。ＲｅｍｏｔｅＵＩサービスでは、図５（Ａ）のようにＨＴＴＰ Ｏｐｅｒａｔｉｏｎを指定してない。一方、ＩＰＰサービスは”ＰＯＳＴ”と指定しており、拡張Ｗｅｂサービス判断条件の比較の結果、ＩＰＰサービスとＲｅｍｏｔｅＵＩサービスのＷｅｂサービス判断条件は一致しないためＩＰＰサービスの登録は許可されることになる。このように、受け付けた拡張判断条件がＷｅｂサービス管理テーブル１２２に登録されている拡張判断条件と重複しないことが確認されたことを契機に、ＷｅｂサービスがＷｅｂサービス管理テーブル１２２に登録される。ＷｅｂサービスがＷｅｂサービス管理テーブル１２２に登録されると図５に示すように、ＵＲＬと拡張判断条件の対応と、Ｗｅｂサービス処理関数と、Ｗｅｂサービス名とが関連付けられる。

次に、Ｗｅｂサービスの登録優先度を確認し、実際にＷｅｂサービス管理テーブルにＷｅｂサービスを登録する手順について説明する。Ｗｅｂサービス登録処理部（１２１）は、ＵＲＬ Ｐａｔｈが一致した登録済みのＷｅｂサービスと、今回の登録で追加されるＷｅｂサービスの拡張判断条件の数の比較を行う（Ｓ２０５）。この処理が行われる理由は、Ｗｅｂサービス処理部１４２がリクエストを基に拡張判断条件に一致するＷｅｂサービスを検索する際、管理テーブルの登録番号が小さい方から順番に、リクエストに該当するＷｅｂサービスが有るか否かの検索を行うことに起因する。このため、条件の厳しいＷｅｂサービスは、条件の緩いＷｅｂサービスよりも小さい登録番号としてＷｅｂサービス管理テーブルに登録しなければならない。でなければ、拡張判断条件の数が少ないため条件が緩いＷｅｂサービスが先に検索されてしまい、拡張判断条件の数が多いため条件が厳しいＷｅｂサービスがいつまでも検索されないという状況に陥りかねない。

今回、ＩＰＰサービスとＲｅｍｏｔｅＵＩサービスの拡張判断条件数を比較するとＩＰＰサービスは１つの条件が設定されているが、ＲｅｍｏｔｅＵＩサービスは条件が設定されていない。そこで、ＩＰＰサービスの検索優先度をＲｅｍｏｐｔｅＵＩサービスよりも高くする必要があるため、ＩＰＰサービスを登録番号Ｎｏ１の位置に挿入して登録する（Ｓ２０９）。この結果、ＲｅｍｏｔｅＵＩサービス，およびＷｅｂＤＡＶサービスの登録番号は従来の登録番号よりも１個ずつずれることになり、Ｗｅｂサービス登録テーブルは図５（Ｂ）のようになる。拡張判断条件数が比較された結果、新規に登録するＷｅｂサービスの拡張判断条件数が登録済みＷｅｂサービスの拡張判断条件数と同等、もしくは少ない場合、同じＵＲＬで登録されたＷｅｂサービスの登録番号の次の登録番号としてＷｅｂサービスを登録する（Ｓ２０８）。

ここで、更にＷｅｂサービス管理テーブルが図５（Ｃ）の状態で、ＨＴＴＰサービスを登録する場合の例を説明する。図５（Ｃ）はＷｅｂサービス管理テーブルのＴＣＰポート８０番のサービスとしてＷＳＤ Ｐｒｉｎｔサービス（１６０）、ＲｅｍｏｔｅＵＩサービス（１５０）とＷｅｂＤＡＶサービス（１７０）が登録されている状態である。ＷＳＤ ＰｒｉｎｔサービスとＲｅｍｏｔｅＵＩサービスはＵＲＬ Ｐａｔｈとして”／”で登録されている。一方、ＷｅｂＤＡＶサービスはＵＲＬ Ｐａｔｈのみ”／ｓｈａｒｅ”を登録している。Ｗｅｂサーバは拡張の判断条件としてＨＴＴＰのＯｐｅｒａｔｉｏｎフィールドとＣｏｎｔｅｎｔ−Ｔｙｐｅのフィールドを設けており、ＷＳＤ ＰｒｉｎｔサービスはＯｐｅｒａｔｉｏｎとして”ＰＯＳＴ”、Ｃｏｎｔｅｎｔ−Ｔｙｐｅに”ａｐｐｌｉｃａｔｉｏｎ／ｓｏａｐ＋ｘｍｌ”を指定している。ＲｅｍｏｔｅＵＩサービス、ＷｅｂＤＡＶサービスは共に拡張の判断条件を指定していない。

この状況で、ＨＴＴＰのＷｅｂサービス（ＩＰＰサービス）はＴＣＰポート番号”８０”でＵＲＬ Ｐａｔｈが”／”を指定し、拡張判断条件としてＨＴＴＰ Ｏｐｅｒａｔｉｏｎが”ＰＯＳＴ”、Ｃｏｎｔｅｎｔ−Ｔｙｐｅが”ａｐｐｌｉｃａｔｉｏｎ／ｉｐｐ”であることを要望するとする。この場合に図７のフローチャートによれば、ＵＲＬ Ｐａｔｈが同じである登録済みのＷｅｂサービスと拡張判断条件の比較（Ｓ２０５）を行う。その結果、拡張判断条件として共にＨＴＴＰ ＯｐｅｒａｔｉｏｎとＣｏｎｔｅｎｔ−Ｔｙｐｅが指定されているため、拡張判断条件数は同じとなる。以上の結果、ＷＳＤ Ｐｒｉｎｔサービスの次の登録番号の位置にＩＰＰサービスが登録され、Ｗｅｂサービス登録テーブルは図５（Ｄ）となる。

最後に、ＲＡＭ，ＲＯＭ，ＨＤＤのいずれかの記憶手段に記憶され、ＣＰＵにより実行されＷｅｂサービス判断処理部（１２４）の処理を図８を用いて説明する。Ｗｅｂサービス判断処理部（１２４）は受信したＷｅｂサービスへのリクエストのＨＴＴＰヘッダを基に、各Ｗｅｂサービスにリクエストを振り分ける機能を備える。

リクエスト受信部（１２３）がＷｅｂサービスへのリクエストを受信すると、Ｗｅｂサービス判断部（１２４）にＷｅｂサービスの判断を依頼する。Ｗｅｂサービス判断部（１２４）はリクエスト受信部（１２３）からＨＴＴＰリクエストを受信した受信ＴＣＰポート番号の取得と、リクエストのＨＴＴＰヘッダ情報を取得し、ヘッダ情報の解析を行う（Ｓ３００）。

Ｗｅｂサービス判断部（１２４）はＷｅｂサービス管理テーブル（１２２）に受信ＴＣＰポート番号に合致するＷｅｂサービスが存在するかを確認する（Ｓ３０１）。対応するＷｅｂサービスが存在しない場合は、該当するＷｅｂサービスは存在しない（Ｓ３０７）ということになる。一方、対応するＷｅｂサービス管理テーブルが存在する場合、サービス検索開始位置を発見したＷｅｂサービス管理テーブルの登録番号の先頭（登録番号Ｎｏ１）に設定する（Ｓ３０２）。

選択したＷｅｂサービス管理テーブルの検索開始位置から受信したリクエストのＨＴＴＰ のＵＲＬ Ｐａｔｈと同じＵＲＬ Ｐａｔｈで登録されたサービスを検索する（Ｓ３０３）。その結果、ＵＲＬ Ｐａｔｈが一致するサービスが存在しない場合はリクエストを処理できるＷｅｂサービスは存在しない（Ｓ３０７）とみなされ処理を終了する。ＵＲＬ Ｐａｔｈが一致する場合、発見したＷｅｂサービスの拡張判断条件とリクエストと共に送信された拡張判断条件が一致するか否かを確認する（Ｓ３０４）。拡張判断条件が一致しない場合、Ｗｅｂサービス管理テーブルの検索開始位置を今回不一致となったＷｅｂサービスの次の登録番号に設定する（Ｓ３０５）。その後、再度ＵＲＬ Ｐａｔｈが一致するサービスの検索処理（Ｓ３０３）、拡張判断条件が一致するＷｅｂサービスの検索を行い（Ｓ３０４）、該当するＷｅｂサービスの検索を継続する。拡張判断条件も一致した場合、該当するＷｅｂサービスの発見（Ｓ３０６）となる。

ここで具体例として、Ｗｅｂサービスクライアント３００がＷｅｂサーバ１２０に対してリクエストを送信し、Ｗｅｂサービス判断部１２４によりＷｅｂサービスが特定されるまでの処理（図８）を説明する。ここでは、Ｗｅｂサービス管理テーブルは図５（Ｂ）の状態と仮定し、図１のシステム構成図と図９のＷｅｂサービスへのリクエストデータ例を用いる。

ユーザがＷｅｂサービス（ＲｅｍｏｔｅＵＩサービス１５０）に対して接続する場合、Ｗｅｂサービスクライアント３５０（以下、Ｗｅｂブラウザ）のＵＲＬ入力フィールドに対してＲｅｍｏｔｅＵＩサービスのＵＲＬ情報を入力する。この入力するＵＲＬ情報は例えばｈｔｔｐ：／／１７２．２４．２９．１６２／という情報である。この入力手段はＷｅｂブラウザの入力フィールドでなくとも、ＷｅｂブラウザのＢｏｏｋｍａｒｋとして登録した情報を選択することで入力する場合もある。なお、「１７２．２４．２９．１６２」は、Ｗｅｂサーバ装置１２０のＩＰアドレスを示しており、ｈｔｔｐ：／／と組み合わせることで各ＷｅｂサービスクライアントはＷｅｂサーバ１２０にアクセスすることができる。Ｗｅｂブラウザ３５０は入力されたＵＲＬ情報に基づいてＷｅｂサーバを特定し、ＨＴＭＬデータの取得を依頼する図９（Ａ）のＨＴＴＰリクエストを送信する。この場合のＨＴＴＰリクエストは、ＨＴＴＰヘッダのみであり、ＨＴＴＰボディは含まれていない。

リクエスト受信部１２２はリクエストデータ図９（Ａ）のＨＴＴＰヘッダを受信すると、Ｗｅｂサービス判断部にＷｅｂサービスの特定を依頼する。Ｗｅｂサービス判断部はＷｅｂサービス判断処理（図８）に基づいてＷｅｂサービスの特定を行う。Ｗｅｂブラウザからのリクエスト（図９（Ａ））はＵＲＬ Ｐａｔｈが”／”であり、ＨＴＴＰ Ｏｐｅｒａｔｉｏｎは”ＧＥＴ”であるため、Ｗｅｂサービス管理テーブル（図５（Ｂ））から検索された結果、Ｎｏ２のＲｅｍｏｔｅＵＩサービスへの処理依頼であると特定される。そして、ＲｅｍｏｔｅＵＩサービスが実行され、その処理結果がＷｅｂブラウザ３５０に応答されることになる。ＷｅｂブラウザはＲｅｍｏｔｅＵＩサービスから処理結果としてのＨＴＭＬファイルを取得し、受信したＨＴＬＭファイルを表示する。
また、別の具体例としてユーザがＩＰＰサービス（１４０）に対して接続する場合を説明する。ＩＰＰサービス（１４０）はＩｎｔｅｒｎｅｔ Ｐｒｉｎｔｉｎｇ Ｐｒｏｔｏｃｏｌを意味し、ＲＦＣでバージョン１．０、１．１、２．０、２．１、２．２が定義されている。ＩＰＰではプリンタの状態、能力の確認、指定したドキュメントの印刷指示、ジョブ状況の確認を行うためのコマンドが定義されており、それらのコマンドはＨＴＴＰボディ部に格納される。すなわち、ＨＴＴＰヘッダなどではＩＰＰのオペレーションを特定することはできない。

ユーザがＩＰＰサービス（１４０）に対してプリンタの能力情報を確認する場合、ＩＰＰクライアント（３４０）に対してＩＰＰサービス（１４０）のＵＲＬを指定する必要がある。ＩＰＰサービス（１４０）のＵＲＬはユーザがＩＰＰサービス（１４０）のＵＲＬを直接指定することが可能である。さらに、ｍＤＮＳ（Ｍｕｌｔｉｃａｓｔ ＤＮＳ）、またはＳＬＰ（Ｓｅｒｖｉｃｅ Ｌｏｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）」などのサービス検索技術を利用してＩＰＰサービス（１４０）のＵＲＬをネットワークから検索する。そして、その検索結果を受けて、利用するＩＰＰサービス（１４０）のＵＲＬを入手してもよい。

ユーザがＩＰＰクライアント（３４０）に対してＩＰＰサービス（１４０）のＵＲＬ情報を検索で入手、もしくは直接入力すると指定されたＵＲＬに対して接続を行う。このときのＵＲＬは例えばｈｔｔｐ：／／１７２．２４．２９．１６２／とする。これは、上述したＲｅｍｏｔｅ ＵＩサービスと同一のＵＲＬであり、この状態でＷｅｂサービスの登録が行われるとＵＲＬが重複することになる。そしてＩＰＰクライアント（３４０）はＨＴＴＰヘッダ情報と、ＩＰＰサービスに対するリクエスト内容を示すコマンドが含まれたＨＴＴＰボディ部のリクエスト（図９（Ｂ））を送付する。

リクエスト受信部１２２はリクエストデータ図９（Ｂ）のＨＴＴＰヘッダを受信すると、Ｗｅｂサービス判断部１２４にＷｅｂサービスの特定を依頼する。Ｗｅｂサービス判断部１２４はＷｅｂサービス判断処理（図８）に基づいてＷｅｂサービスの特定を行う。Ｗｅｂブラウザからのリクエスト（図９（Ｂ））はＵＲＬ Ｐａｔｈが”／”であり、ＨＴＴＰ Ｏｐｅｒａｔｉｏｎは”ＰＯＳＴ”であるため、Ｗｅｂサービス管理テーブル（図５（Ｂ））から検索した結果、Ｎｏ１のＩＰＰサービスへの処理依頼であると特定される。そして、ＩＰＰサービス（１４０）が実行される。ＩＰＰサービス（１４０）はＨＴＴＰボディ部に含まれるＩＰＰリクエストデータを受信することで、ＩＰＰサービスに対する具体的なリクエストを確認する。

図９（Ｃ）は図９（Ｂ）のＩＰＰリクエストデータのデータフォーマットを示す図である。

ＩＰＰリクエストはＲＦＣ ２９１０で定義されており、ｏｐｅｒａｔｉｏｎ−ｉｄフィールドにＩＰＰサービスに対する指示が設定される。ＩＰＰサービスに対する指示は例えばｏｐｅｒａｔｉｏｎ−ｉｄフィールドに０ｘ０００２が設定された場合は印刷を要求するＰｒｉｎｔ−ＪＯＢリクエストであり、０ｘ０００Ｂが指定される場合はプリンタの属性を取得するＧｅｔ−Ｐｒｉｎｔｅｒ−Ａｔｔｒｉｂｕｔｅｓリクエストであることを示す。

ＩＰＰサービス（１４０）は図９（Ｃ）のフォーマットのリクエスデータを受信すると、ｏｐｅｒａｔｉｏｎ−ｉｄフィールドに含まれるコマンドから指定された指示を実行する。例えば、プリンタの属性を取得するＧｅｔ−Ｐｒｉｎｔｅｒ−Ａｔｔｒｉｂｕｔｅｓリクエストである場合、ＩＰＰサービス１４０はプリンタの能力情報をＩＰＰクライアント３４０へ応答する。一方、Ｐｒｉｎｔ−ＪＯＢリクエストである場合、ＩＰＰサービス１４０は同じくリクエストのｄａｔａ部分に設定された印刷データを受信し、その印刷データに基づきＰｒｉｎｔｅｒ１０６を介して印刷を行う。

ＩＰＰサービス（１４０）が図９（Ｂ）のＩＰＰリクエストデータに指定された処理を完了すると、ＩＰＰクライアント（３４０）に対して要望された処理に対する応答をＩＰＰの規格に則ったフォーマットでＨＴＴＰＢｏｄｙ部に格納して送信する。

ＩＰＰクライアント（３４０）は受信したレスポンスのＨＴＴＰＢｏｄｙ部に格納されたデータから依頼の結果を取得することで、ＩＰＰサービス（１４０）との通信は完了となる。

以上、実施例１により、単一のＷｅｂサーバ上で動作する複数のＷｅｂサービスが同一のＵＲＬで動作する場合でも、Ｗｅｂサーバは受信したＨＴＴＰリクエストからどのＷｅｂサービスを呼び出すべきかを特定することができる。そのＨＴＴＰリクエストが、リクエストを送信するＷｅｂサービスクライアント毎に異なる可能性があるためＵＲＬが同一であってもＷｅｂサービスが特定可能なのである。結果、ユーザは、例えば１つのＵＲＬのみを記憶するだけで良いので、利便性が保たれつつも多様なＷｅｂサービスが実行される。

〔その他の実施例〕
本願発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

１００ Ｗｅｂサーバ装置
１２０ Ｗｅｂサーバ
１３０ 通信部
１４０、１５０、１６０，１７０ Ｗｅｂサービス
２００ ネットワーク
３００ Ｗｅｂクライアント装置
３１０ 通信部
３２０、３３０，３４０，３５０ Ｗｅｂサービスクライアント

Claims (11)

1. 複数のウェブサービスを有するウェブサーバ装置であって、
   ネットワークを介して少なくともＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）リクエストを受信する受信手段と、
   条件テーブルが記憶された記憶手段と、
   前記受信手段によって受信されたＨＴＴＰリクエストと、前記記憶手段に記憶された条件テーブルに基づいて呼び出すべきウェブサービスを決定する決定手段と、
   前記決定手段によって決定されたウェブサービスを呼び出す呼び出し手段と、
   を備え、
   前記記憶手段が記憶する前記条件テーブルには、前記ウェブサーバ装置が有する少なくとも１つのウェブサービスに対応付けて、ＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）と所定の判断条件が記憶されており、更に、前記条件テーブルは記憶する所定の判断条件を異ならせることで、互いに異なるウェブサービスに同一のＵＲＬを対応付けることが可能であり、
   前記決定手段は、前記受信手段によって受信されたＨＴＴＰリクエストに含まれるリクエストＵＲＬとＨＴＴＰヘッダー内の情報が、前記条件テーブル内の前記ＵＲＬと前記所定の判断条件の組み合わせに一致する場合、当該一致する前記ＵＲＬと前記所定の判断条件の組み合わせに対応付けられたウェブサービスを呼び出すべきウェブサービスとして決定することを特徴とするウェブサーバ装置。
2. 前記決定手段は、前記受信手段によって受信されたＨＴＴＰリクエストに含まれる前記リクエストＵＲＬと前記ＨＴＴＰヘッダー内の情報の組み合わせが、前記条件テーブル内の前記ＵＲＬと前記所定の判断条件の組み合わせのいずれにも一致しない場合であって、前記リクエストＵＲＬと同一のＵＲＬ且つ、前記所定の判断条件が記されていない組み合わせが前記条件テーブルに記憶されている場合は、当該組み合わせに対応付けられたウェブサービスを呼び出すべきウェブサービスとして決定することを特徴とする請求項１に記載のウェブサーバ装置。
3. 前記条件テーブルに記憶される前記所定の判断条件は、前記ウェブサービスが受け付け可能な前記ＨＴＴＰリクエストの種類に関する条件であることを特徴とする請求項１又は２に記載のウェブサーバ装置。
4. 前記条件テーブルにウェブサービスを登録する登録手段を更に備えることを特徴とする請求項１乃至３のいずれか１項に記載のウェブサーバ装置。
5. 前記登録手段は、ウェブサービスからの登録要求を受け付けたことに応じて、当該ウェブサービスと、前記登録要求に含まれるＵＲＬと所定の判断条件を対応付けて、前記条件テーブルに登録することを特徴とする請求項４に記載のウェブサーバ装置。
6. 前記記憶手段はポート番号ごとに前記条件テーブルを記憶し、
   前記決定手段は、前記リクエストＵＲＬに基づいてポート番号を特定し、当該特定されたポート番号に対応する条件テーブルを用いて、呼び出すべきウェブサービスを決定することを特徴とする請求項１乃至５のいずれか１項に記載のウェブサーバ装置。
7. 前記条件テーブルに記憶されたウェブサービスはＩＰＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｉｎｔｉｎｇ Ｐｒｏｔｏｃｏｌ）サービスを含むことを特徴とする請求項１乃至６のいずれか１項に記載のウェブサーバ装置。
8. 前記条件テーブルに記憶されたウェブサービスは、リモートＵＩサービスを含むことを特徴とする請求項１乃至７のいずれか１項に記載のウェブサーバ装置。
9. 前記ウェブサーバ装置はプリンタであることを特徴とする請求項１乃至８のいずれか１項に記載のウェブサーバ装置。
10. 条件テーブルが記憶された記憶手段を備え、複数のウェブサービスを有するウェブサーバ装置の制御方法であって、
    ネットワークを介して少なくともＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）リクエストを受信する受信工程と、
    前記受信工程で受信したＨＴＴＰリクエストと、前記記憶手段に記憶された条件テーブルに基づいて呼び出すべきウェブサービスを決定する決定工程と、
    前記決定工程で決定されたウェブサービスを呼び出す呼び出し工程と、
    を有し、
    前記記憶手段が記憶する前記条件テーブルには、前記ウェブサーバ装置が有する少なくとも１つのウェブサービスに対応付けて、ＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）と所定の判断条件が記憶されており、更に、前記条件テーブルは記憶する所定の判断条件を異ならせることで、互いに異なるウェブサービスに同一のＵＲＬを対応付けることが可能であり、
    前記決定工程は、前記受信工程で受信したＨＴＴＰリクエストに含まれるリクエストＵＲＬとＨＴＴＰヘッダー内の情報が、前記条件テーブル内の前記ＵＲＬと前記所定の判断条件の組み合わせに一致する場合、当該一致する前記ＵＲＬと前記所定の判断条件の組み合わせに対応付けられたウェブサービスを呼び出すべきウェブサービスとして決定することを特徴とするウェブサーバ装置の制御方法。
11. 請求項１０に記載のウェブサーバ装置の制御方法をコンピュータに実行させるためのプログラム。

Images