JP2007041702A - カプセル化文書構造及びウェブサーバ機能を有する文書の作成方法 - Google Patents
カプセル化文書構造及びウェブサーバ機能を有する文書の作成方法 Download PDFInfo
- Publication number
- JP2007041702A JP2007041702A JP2005223083A JP2005223083A JP2007041702A JP 2007041702 A JP2007041702 A JP 2007041702A JP 2005223083 A JP2005223083 A JP 2005223083A JP 2005223083 A JP2005223083 A JP 2005223083A JP 2007041702 A JP2007041702 A JP 2007041702A
- Authority
- JP
- Japan
- Prior art keywords
- file
- web server
- document
- program
- encapsulated
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/567—Integrating service provisioning from a plurality of service providers
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Information Transfer Between Computers (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Stored Programmes (AREA)
Abstract
【課題】簡単な手段でインターネットサービスプロバイダを介することなく、ユーザが自分のマシンをウェブサーバ化、ブログサーバ化して、個人が所有する情報の公開を容易に行うことができるようにする。
【解決手段】例えばJarファイルの構造において、META-INFフォルダ１には、マニフェストファイルが格納されており、起動されたときに最初にロードするclassファイル情報が記述されている。コンテンツフォルダ２には、テキストファイルや画像、音声ファイルなどが格納される。プログラムフォルダ３には、Javaのプログラムファイル群が格納され、ここに通信機能、加筆機能、記録機能などが格納される。そしてこれらを単一の文書としてカプセル化された文書構造とする。
【選択図】図１
【解決手段】例えばJarファイルの構造において、META-INFフォルダ１には、マニフェストファイルが格納されており、起動されたときに最初にロードするclassファイル情報が記述されている。コンテンツフォルダ２には、テキストファイルや画像、音声ファイルなどが格納される。プログラムフォルダ３には、Javaのプログラムファイル群が格納され、ここに通信機能、加筆機能、記録機能などが格納される。そしてこれらを単一の文書としてカプセル化された文書構造とする。
【選択図】図１
Description
本発明は、例えば個人からの情報の発信に使用して好適なカプセル化文書構造及びウェブサーバ機能を有する文書の作成方法に関する。詳しくは、インターネットサービスプロバイダを介することなく、ユーザが自分のマシンをウェブサーバ化、ブログサーバ化して情報を公開することができるようにしたものである。
カプセル化文書作成の手段として、本願出願人は先に文書のデータ構造、記憶媒体及び情報処理装置の発明を出願している（例えば、特許文献１、２参照。）。
また、ウェブサーバとしては、ＩＩＳ（Internet Information Service）やApache等が実用化されているものである（例えば、非特許文献１参照。）。
すなわち、任意の電子データとその処理に用いるプログラムをカプセル化する技術は公知である。また、ウェブサーバを用いて、個人が所有する情報を発信する技術も一般的に知られているものである。
特開２００３−１５９４１号公報
特開２００３−９９４２４号公報
http://www.atmarkit.co.jp/flinux/rensai/apache01/apache01.html
インターネット関連技術の発展により、誰もが自分の文書を簡単に公開できるようになってきている。特に最近ではブログ(ウェブログ)が、文書の投稿の簡便さから急速に普及してきている。これら、現在ウェブ上にあるコンテンは、インターネットサービスプロバイダが提供しているサービスを利用したものが多く、ユーザが自分のマシンをウェブサーバ化、ブログサーバ化して情報を公開するのは現状ではそれほど多くないと言える。
しかしながら、一ユーザが個人で自分のマシンをウェブサーバ化して情報を公開する環境は徐々に整ってきている。サービスとして、ブロードバンドサービス、定額の常時接続サービス、固定ＩＰアドレス配布サービスなどがあり、またユーザが個人で所有するマシンもハイスペック化してきており、インターネット上の一サーバとして十分成り立つ。このような環境下において、個人でウェブサーバなどを立てているユーザもいることはいるが、インターネットユーザの数の多さに対して、非常に少ないのが現状である。
その原因としては、料金などの問題やセキュリティ面での脅威も考えられるが、ウェブサーバを立てることの敷居の高さの問題も一因であると考える。例えば、現状においてはユーザがウェブサーバを立てるとなると、マイクロソフトが提供しているＩＩＳ（Internet Information Service）か、オープンソースのApacheを利用するのが一般的であると思われるが、どちらも一ユーザが設定するのは大変である（実際にはそれほど大変ではないが、一般ユーザは大変であるとの印象を抱いてしまっている）。
さらにブロードバンド化が進み、ＩＰｖ６が普及してすべての機器がネットワークにつながってグローバルアドレスを持つような環境が予想される。そのような環境においては、個人や個々の機器による情報発信がますます重要になっていくであろう。
そういった環境においては、現状のように、文書を公開するのにわざわざインターネットサービスプロバイダのサービスを利用するのではなく、自分のマシン上で公開するのも一つの手段になるのではないかと考えられる。例えばブログを例にとると、現在の形態では、インターネットサービスプロバイダなどがサービスの一つとしてブログができるスペースをユーザに対して提供しており、ユーザは簡単な登録のみで自分専用のブログを開設できるようになっている。
この場合にユーザは手軽に、ほとんどコストをかけずにブログを開設できるというメリットがある一方、インターネットサービスプロバイダによるサービスであるため、ユーザの都合で仕様の変更を行ったりすることはほとんどできず、また、サービス自体が突然終了してしまう可能性もある。画像の登録容量に制限があるなど、使い勝手が必ずしも良いとは言えない。したがって、簡単に自分で文書を公開する手段さえあれば、他者のサービスに頼る必要がなくなるのではないかと考えられる。
また、オフィスでの用途を考えた場合、現状では個人でウェブサーバを立てるようなことはせず、情報部門もしくは部門のＩＴ関連技術に強いユーザがウェブサーバを構築し、サーバやコンテンツの管理を行っている。このシステムの問題点は、ユーザ数が多くなればなるほど管理がしにくく管理者およびサーバなどの機器に負担がかかる点と、ユーザが自分の管理下でコンテンツの公開および更新がしにくい点にある。
これに対して、ユーザが個人でコンテンツを管理してくれれば、サーバを用意する必要もなければ、バックアップなどの手間もユーザ側に委ねることができる。また、ユーザそれぞれが簡単に文書を公開、更新できるようになれば社内での情報共有やコミュニケーションも円滑になることが予想される。
この発明はこのような問題点に鑑みて成されたものであって、本発明の目的は、簡単な手段でインターネットサービスプロバイダを介することなく、ユーザが自分のマシンをウェブサーバ化、ブログサーバ化して、個人が所有する情報の公開を容易に行うことができるようにするものである。
上記の課題を解決し、本発明の目的を達成するため、請求項１に記載された発明は、表現実体となる１又は２以上のデジタル情報ファイルと、デジタル情報ファイルの構造及び表示状態を特定する表示情報ファイルと、コンピュータによって共に解釈、実行され、デジタル情報を参照せずに特有の機能を実行するための機能動作プログラムを含む動作プログラムファイルとを具備し、ウェブブラウザの要求に応じてデジタル情報ファイル内のコンテンツをブラウザに送信するウェブサーバ機能を有するプログラムファイルがデジタル情報ファイルとともに単一の文書としてカプセル化されていることを特徴とするカプセル化文書構造である。
また、請求項２に記載のカプセル化文書構造においては、表示情報ファイルに基づいて特定される表示状態で１又は２以上のデジタル情報ファイルをコンピュータのディスプレイ上に表示させるデジタル情報表示プログラムが単一の文書としてカプセル化されていることを特徴とするものである。
請求項３に記載のカプセル化文書構造においては、表示情報ファイル内のコンテンツを編集するコンテンツ編集機能を有するプログラムファイルが単一の文書としてカプセル化されていることを特徴とするものである。
請求項４に記載のカプセル化文書構造においては、表示情報ファイル内のコンテンツの更新情報を送信する更新情報送信機能を有するプログラムファイルが単一の文書としてカプセル化されていることを特徴とするものである。
請求項５に記載のカプセル化文書構造においては、ウェブサーバ機能を有するプログラムファイルは、既に他のウェブサーバプログラムが起動している場合には、そのウェブサーバプログラムにウェブサーバ機能を委託することを特徴とするものである。
請求項６に記載のカプセル化文書構造においては、委託を受ける機能を含むウェブサーバ機能を有するプログラムファイルが単一の文書としてカプセル化されていることを特徴とするものである。
請求項７に記載のカプセル化文書構造においては、保持しているコンテンツに関するメタ情報を公開するメタ情報公開機能を有するプログラムファイルが単一の文書としてカプセル化されていることを特徴とするものである。
請求項８に記載のカプセル化文書構造においては、マシン上で起動している文書のメタ情報を統合するメタ情報統合機能を有するプログラムファイルが単一の文書としてカプセル化されていることを特徴とするものである。
さらに、本発明の目的を達成するため、請求項９に記載された発明は、マニュフェストファイルを記述し、マニュフェストファイル中のクラスファイルを指定し、マニュフェストファイルとコンテンツと、クラスファイルとしてのウェブサーバ機能を有するプログラムファイルを単一の文書としてカプセル化することを特徴とするウェブサーバ機能を有する文書の作成方法である。
また、請求項１０に記載のウェブサーバ機能を有する文書の作成方法においては、ウェブサーバ機能を有するプログラムファイルは、既に他のウェブサーバプログラムが起動している場合には、そのウェブサーバプログラムにウェブサーバ機能を委託することを特徴とするものである。
請求項１１に記載のウェブサーバ機能を有する文書の作成方法においては、委託を受ける機能を含むウェブサーバ機能を有するプログラムファイルが単一の文書としてカプセル化されていることを特徴とするものである。
本発明のカプセル化文書構造及びウェブサーバ機能を有する文書の作成方法によれば、簡単な手段でインターネットサービスプロバイダを介することなく、ユーザが自分のマシンをウェブサーバ化、ブログサーバ化して、個人が所有する情報の公開を容易に行うことができる。
以下、図面を参照して本発明を説明するに、図１には、本発明によるカプセル化文書構造及びウェブサーバ機能を有する文書の作成方法を、Jar（Java ARchive）ファイルに適用した場合のファイルの構造を示す。
図１において、Jarファイルは、現在広く普及しているZIPファイル形式に基づくファイル形式で、複数のファイルを一つにまとめた書庫ファイルである。Jarファイルには、Javaのプログラムモジュールであるclassファイルおよびテキスト、画像、音声ファイルなどを含めることができる。
〔Jarファイルの構造〕
Jarファイルの構造は図１に示した通りである。図１において、META-INFフォルダ１には、マニフェストファイルが格納されており、起動されたときに最初にロードするclassファイル情報が記述されている。コンテンツフォルダ２には、テキストファイルや画像、音声ファイルなどが格納される。フォルダ自体はここではなくてもよいが、他のファイル群（プログラムファイルなど）と区別するためにここでは設けた。またフォルダ自体は複数あっても構わない。
Jarファイルの構造は図１に示した通りである。図１において、META-INFフォルダ１には、マニフェストファイルが格納されており、起動されたときに最初にロードするclassファイル情報が記述されている。コンテンツフォルダ２には、テキストファイルや画像、音声ファイルなどが格納される。フォルダ自体はここではなくてもよいが、他のファイル群（プログラムファイルなど）と区別するためにここでは設けた。またフォルダ自体は複数あっても構わない。
プログラムフォルダ３には、Javaのプログラムファイル群が格納される。通常、Javaのプログラムはパッケージ名に応じた階層で管理される。すなわち、例えばパッケージ名をjp.co.ricoh.project とした場合、そのパッケージ内で作成されるclassファイルは、図２に示したような階層の位置になる。従って、プログラムフォルダ３の名前は、この場合はjpになる。
〔実行可能Jarファイル〕
実行可能Jarファイルとは、例えばWindows上でファイルを開くときにダブルクリックするように、ダブルクリックすることによってマニフェストファイルに記述されたclassファイルがロードされ、実行されるファイルである。Jarファイルは、Javaの実行環境のインストール時に、Jarファイル（拡張子jar）と関連付けられる。またコマンドラインで
java -jar sample.jar
とすることによって起動することもできる。
実行可能Jarファイルとは、例えばWindows上でファイルを開くときにダブルクリックするように、ダブルクリックすることによってマニフェストファイルに記述されたclassファイルがロードされ、実行されるファイルである。Jarファイルは、Javaの実行環境のインストール時に、Jarファイル（拡張子jar）と関連付けられる。またコマンドラインで
java -jar sample.jar
とすることによって起動することもできる。
〔機能を有する文書の起動〕
機能を有する文書の起動までの流れを図３に示す。この流れは基本的には実行可能Jarファイルの起動と同じである。
機能を有する文書の起動までの流れを図３に示す。この流れは基本的には実行可能Jarファイルの起動と同じである。
ここで、機能を有する文書の構造は以下の通りである。
・マニフェストファイル（文書を起動する際に最初にロードするプログラム（classファイル）の名前が記述されている。）
・コンテンツ（ここでは、プログラムによってロード、表示されるコンテンツを指す。テキスト、画像、動画、音声ファイルなど。プログラムが解釈、処理できればフォーマットは問わない。）
・マニフェストファイル（文書を起動する際に最初にロードするプログラム（classファイル）の名前が記述されている。）
・コンテンツ（ここでは、プログラムによってロード、表示されるコンテンツを指す。テキスト、画像、動画、音声ファイルなど。プログラムが解釈、処理できればフォーマットは問わない。）
・プログラム（コンテンツフォルダに含まれる文書（テキスト、画像など）をロード、表示するプログラムを格納する。文書を表示するだけでなく、文書に様々な機能を追加するプログラムもここに格納する。機能の例としては、例えば、通信機能、加筆機能、記録機能などがある。）
〔動作〕
ステップＳ１におけるダブルクリックもしくはコマンドラインからの命令によって、ステップＳ２でマニフェストファイルが取得され、ステップＳ３でメインクラスの情報が取得されると、ステップＳ４でメインクラスに記述されているclassファイルがロードされて、それぞれロードされたclassファイルが実行される。すなわち、ステップＳ５でウェブサーバプログラムが実行され、ステップＳ６でコンテンツ表示プログラムが十呼応され、ステップＳ７でその他の機能が実行される。これによって、コンテンツフォルダ内のテキストや画像が表示される。
ステップＳ１におけるダブルクリックもしくはコマンドラインからの命令によって、ステップＳ２でマニフェストファイルが取得され、ステップＳ３でメインクラスの情報が取得されると、ステップＳ４でメインクラスに記述されているclassファイルがロードされて、それぞれロードされたclassファイルが実行される。すなわち、ステップＳ５でウェブサーバプログラムが実行され、ステップＳ６でコンテンツ表示プログラムが十呼応され、ステップＳ７でその他の機能が実行される。これによって、コンテンツフォルダ内のテキストや画像が表示される。
このようにして、コンテンツが表示されるとともに、各種機能を実現するプログラムも同様にロードされ、使用準備が整う。これにより、例えばユーザのマウス操作に応じて、文中に下線を引くような機能が実現できる。
さらにウェブサーバ機能を有する文書について説明する。ここで、ウェブサーバ機能を有する文書とは、コンテンツにあたる部分にHTMLやJPEGなどのウェブブラウザで閲覧できるフォーマットを格納し、プログラムにあたる部分に、コンテンツを表示するプログラムと、ウェブブラウザからのアクセスに応じてコンテンツファイルをウェブブラウザに送信するウェブサーバプログラムとを格納したものである。
〔ウェブサーバプログラムの処理（一般）〕
ここでは、ウェブサーバプログラムの基本的な動作について述べる。まず、ウェブサーバプログラムはウェブブラウザからの要求に応じてテキストや画像を送信するのが基本機能である。ウェブブラウザからの要求とウェブサーバプログラムの応答の概要を以下に述べる。
ここでは、ウェブサーバプログラムの基本的な動作について述べる。まず、ウェブサーバプログラムはウェブブラウザからの要求に応じてテキストや画像を送信するのが基本機能である。ウェブブラウザからの要求とウェブサーバプログラムの応答の概要を以下に述べる。
ウェブブラウザとウェブサーバの関係は典型的なクライアント／サーバシステムであると言える。ウェブブラウザの要求に対してウェブサーバが応答するという形で処理がなされる。ウェブブラウザとウェブサーバプログラムとの通信はHTTP（Hyper Text Transfer Protocol）を用いて行われる。HTTPの仕様はRFC1945(HTTP/1.0)、RFC2068(HTTP/1.1)にて定められている（RFC: Request For Comments）。
ウェブブラウザとウェブサーバプログラム間の通信は、このHTTPというプロトコルを通じて、ウェブブラウザがHTML（Hyper Text Markup Language）ファイルをウェブサーバプログラムに対して要求し、ウェブサーバはその要求を解釈してHTMLファイルを送信することによって実現されている。ウェブブラウザは、受信したHTMLファイルのタグを解釈しコンテンツをレンダリングするなどの機能が必要であるが、ウェブサーバプログラムは、基本的にはウェブブラウザからのコマンドを解釈し、対応ファイルを送信するだけである。
〔ウェブブラウザからのファイルの要求（GETコマンド）〕
ウェブブラウザから要求されるコマンドはいくつかあるが、ここでは、もっとも基本的なGETコマンドについてのみ述べることにする。ウェブサーバプログラムの起動しているマシン名をウェブserverとすると、ウェブブラウザがウェブserver上のindex.htmlファイルにアクセスするには、
http://ウェブserver:6000/index.html
をopenすればよい（6000はポート番号）。
ウェブブラウザから要求されるコマンドはいくつかあるが、ここでは、もっとも基本的なGETコマンドについてのみ述べることにする。ウェブサーバプログラムの起動しているマシン名をウェブserverとすると、ウェブブラウザがウェブserver上のindex.htmlファイルにアクセスするには、
http://ウェブserver:6000/index.html
をopenすればよい（6000はポート番号）。
このときウェブブラウザは、ソケットを使って、マシンウェブserver上でポート6000を使用しているサーバとの間にコネクションをはり、
GET /index.html HTTP/1.0[CR LF(改行)]
のような命令をウェブサーバプログラムに対して送信する（行の末尾は開業コード）。また、GETコマンドの後には様々な付加情報が続くが、ここでは、触れない。
GET /index.html HTTP/1.0[CR LF(改行)]
のような命令をウェブサーバプログラムに対して送信する（行の末尾は開業コード）。また、GETコマンドの後には様々な付加情報が続くが、ここでは、触れない。
最後に空行(改行コード以外に文字を一切含まない行)を付加することによって、命令の最後であることをウェブサーバプログラムに通知する。因みにウェブブラウザがproxyサーバ経由でウェブserverにアクセスする場合には、GETコマンドは以下のようになり、proxyサーバが代理でウェブserverにアクセスする。
GET http://ウェブserver:6000/index.html HTTP/1.0[CR LF]
GET http://ウェブserver:6000/index.html HTTP/1.0[CR LF]
〔ＧＥＴコマンドの処理（ウェブサーバプログラム）〕
ウェブサーバプログラムはGETコマンドを受信したら、コマンドから要求されているファイルを特定し、対象ファイルを送信する。ファイルを送信するのに先立って、以下のヘッダ情報を送信する必要がある。
HTTP/1.0 200 OK[CR LF]
[CR LF]
ウェブサーバプログラムはGETコマンドを受信したら、コマンドから要求されているファイルを特定し、対象ファイルを送信する。ファイルを送信するのに先立って、以下のヘッダ情報を送信する必要がある。
HTTP/1.0 200 OK[CR LF]
[CR LF]
なお、最初の行は、GET命令が正しく受理され、要求されたファイルを送信することを意味する。２行目は空行であり、ヘッダ情報の終了を意味する。これに続けて要求されたファイルを送信し、送信し終わったところでコネクションを張っていたソケットをクローズする。
また、要求されたファイルが存在しないなどの原因で、ウェブブラウザに何らかのエラー情報を返す場合には、以下のようなコマンドをHTTPの仕様に従って送信する。
HTTP/1.0 404 ファイル未検出[CR LF]
[CR LF]
<h2>要求されたファイルは見つかりませんでした。</h2>
なお、３行目はウェブブラウザに表示させるエラーメッセージである。
HTTP/1.0 404 ファイル未検出[CR LF]
[CR LF]
<h2>要求されたファイルは見つかりませんでした。</h2>
なお、３行目はウェブブラウザに表示させるエラーメッセージである。
以上が、ウェブサーバプログラムの処理の流れである。HTTPには、他にも多くの取り決めがあるが、基本的には、ウェブブラウザがGETコマンドを発行することによってファイルを要求し、その要求をウェブサーバプログラムが解釈して、対象のファイルをウェブブラウザに対して送信することで成り立っている。
〔ウェブサーバプログラム（カプセル化文書内）の処理〕
さらに、文書内のウェブサーバプログラムの処理の流れについて、図４を参照して以下に述べる。基本的には先に述べたのと同様にウェブブラウザからの要求に応じて文書内のファイルをウェブブラウザに送信する。図４では、ウェブブラウザからの要求を受けた時点でスレッドを生成し、ウェブブラウザの要求に応じる動作について示した。
さらに、文書内のウェブサーバプログラムの処理の流れについて、図４を参照して以下に述べる。基本的には先に述べたのと同様にウェブブラウザからの要求に応じて文書内のファイルをウェブブラウザに送信する。図４では、ウェブブラウザからの要求を受けた時点でスレッドを生成し、ウェブブラウザの要求に応じる動作について示した。
すなわち図４において、ステップＳ１１ではウェブブラウザからの要求が待ち受けられる。そして要求があるとステップＳ１２で処理スレッドが生成され、ステップＳ１３で要求情報が解析され、ステップＳ１４で要求ファイルが解析される。さらにステップＳ１５で要求されたファイルがあるか否か判断され、ある時（Ｙｅｓ）はステップＳ１６でヘッダ情報が送信され、ステップＳ１７でファイルが送信される。またステップＳ１５で要求されたファイルがない時（Ｎｏ）はステップＳ１８でエラーメッセージが送信される。
このようにして、一般的なウェブサーバプログラムにおいて、ウェブブラウザからのファイルの要求があった時の要求されたファイルの送信、及び要求されたファイルが無かった場合のエラーメッセージ送信の処理が行われる。
さらに、複数のウェブサーバ機能を有する文書を起動したときの処理について以下に説明する。まず、複数のウェブサーバ機能を有する文書を起動する場合について述べる。
〔複数のソケットの生成〕
ここで、複数のウェブサーバプログラムを起動するということは、複数のソケットを生成するということである。この場合に問題となるのは、同じポート番号で複数のソケットは生成できないということである。先に述べたように、ウェブサーバプログラムは、ＩＰアドレスとポート番号のセットでソケットを作成し、ウェブブラウザからの接続を待ち受ける。従ってウェブサーバプログラムを複数起動するには、ポート番号を変更して起動する必要がある。そうしなければ通常バインドエラーになってソケットを生成できない。
ここで、複数のウェブサーバプログラムを起動するということは、複数のソケットを生成するということである。この場合に問題となるのは、同じポート番号で複数のソケットは生成できないということである。先に述べたように、ウェブサーバプログラムは、ＩＰアドレスとポート番号のセットでソケットを作成し、ウェブブラウザからの接続を待ち受ける。従ってウェブサーバプログラムを複数起動するには、ポート番号を変更して起動する必要がある。そうしなければ通常バインドエラーになってソケットを生成できない。
そこで、例えばすて図５に示すように、ソケットを生成する際にポート番号を変えてやることにより、複数のウェブサーバプログラムそれぞれがソケットを生成することが可能になる。すなわち図５においては、ステップＳ２１で起動が行われると、ステップＳ２２でソケットが生成される。そしてステップＳ２３でＯＫか否か判断され、ＯＫの時（Ｙｅｓ）はステップＳ２４で接続待ちとなる。
また、ステップＳ２３でＯＫでない時（Ｎｏ）はステップＳ２５でポート番号を変えてソケットが制裁され、さらにステップＳ２６でＯＫか否か判断され、ＯＫの時（Ｙｅｓ）はステップＳ２４で接続待ちとなる。さらにステップＳ２６でＯＫでない時（Ｎｏ）はステップＳ２５、Ｓ２６が繰り返し実行される。このようにして、複数のウェブサーバプログラムそれぞれがソケットを生成することが可能になる。
しかしながらこの方法の問題点としては、ウェブサーバプログラムに接続するウェブブラウザは、ポート番号を文書ごとに変更してアドレスを指定しなければならなくなるという点があげられる。ウェブサーバプログラムがどのポート番号でソケットを生成したかはウェブブラウザでは知ることはできないので、ポート番号は固定するのが望ましいのである。そこで、さらに複数の文書を起動した場合も一つのソケットで処理する方法について以下に説明する。
すなわち、複数のソケットを生成してしまう方法はあまり現実的ではないので、一つのマシンで複数のウェブサーバ機能を有する文書を起動しても、ソケットの生成は一つで済む方法について図６を参照して説明する。まず、この図６において、ステップＳ２１で起動が行われると、ステップＳ２２でソケットが生成される。そしてステップＳ２３でＯＫか否か判断され、ＯＫの時（Ｙｅｓ）はステップＳ２４で接続待ちとなる。ここまでの処理は図５の場合と同じである。
従ってこの場合に、マシン上で最初に起動するウェブサーバ機能を有する文書は、他にそのポートを使用している文書がないためにウェブサーバプログラムにおいてソケットを生成することができる。これに対して、マシン上において２番目以降に起動するウェブサーバ機能を有する文書は、作成しようとするソケットのポート番号がすでに最初の文書において使用されているために、ソケットを生成することができず、エラーを発生する。
そこで、このエラーを発生した場合の処理として、すでに起動しているウェブサーバプログラムに対して委託要求を発信する。この要求を受信したウェブサーバプログラムは、応答を返し、委託を受ける旨を要求してきたウェブサーバプログラムに対して通知する。このため上述のステップＳ２３でＯＫでない時（Ｎｏ）は、ステップＳ２７で最初に起動したウェブサーバプログラムに委託を行って、ステップＳ２８でこの処理は終了される。
このようにして、２番目以降に起動するウェブサーバ機能を有する文書は、すでに起動しているウェブサーバプログラムに対してウェブサーバ機能を委託することによって、一つのマシンで複数のウェブサーバ機能を有する文書を起動しても、ソケットの生成は一つで済ませることができる。さらに、委託を受けたウェブサーバプログラムでの処理は以下のように行われる。
〔委託を受けたウェブサーバプログラム〕
委託を受けたウェブサーバプログラムは、自文書内のコンテンツのみならず、委託を受けた文書(Jarファイル)の文書内コンテンツをウェブブラウザに対して送信する処理も受け持つ。委託を受けた際には、図７に示したような文書の一覧を示すHTML文書を生成する。図７は二つの文書から委託された場合を示している。図７中のdocument1などは、任意である。一意になる名前をつける。文書中からタイトルを抜き出して表示しても良いが、リンクは同じ文書を指し示すことがないようにする必要がある。
委託を受けたウェブサーバプログラムは、自文書内のコンテンツのみならず、委託を受けた文書(Jarファイル)の文書内コンテンツをウェブブラウザに対して送信する処理も受け持つ。委託を受けた際には、図７に示したような文書の一覧を示すHTML文書を生成する。図７は二つの文書から委託された場合を示している。図７中のdocument1などは、任意である。一意になる名前をつける。文書中からタイトルを抜き出して表示しても良いが、リンクは同じ文書を指し示すことがないようにする必要がある。
従って図７において、複数の文書が起動している場合には、例えば、ウェブブラウザでマシン名をmachineとすると
http://machine:8080/
をopenすることにより、起動している文書の一覧が記述されたHTML文書を表示する。
http://machine:8080/
をopenすることにより、起動している文書の一覧が記述されたHTML文書を表示する。
ここで、一覧のリンクは、例えば、
http://machine:8080/document1/index.html
http://machine:8080/document2/index.html
http://machine:8080/document3/index.html
などとなり、閲覧したい文書をクリックすることにより、ユーザは異なる文書のコンテンツを閲覧することができる。
http://machine:8080/document1/index.html
http://machine:8080/document2/index.html
http://machine:8080/document3/index.html
などとなり、閲覧したい文書をクリックすることにより、ユーザは異なる文書のコンテンツを閲覧することができる。
さらに、委託を受けているウェブサーバプログラムの処理としては、図８に示すようにユーザのクリックイベントにより、ウェブブラウザが
http://machine:8080/document3/index.html
をopenするので、ウェブサーバプログラムは、コマンドとして、
GET /document3/index.html HTTP/1.1
を取得することができる。
http://machine:8080/document3/index.html
をopenするので、ウェブサーバプログラムは、コマンドとして、
GET /document3/index.html HTTP/1.1
を取得することができる。
すなわち図８において、ステップＳ３１ではウェブブラウザからの要求が待ち受けられる。そして要求があるとステップＳ３２で処理スレッドが生成され、ステップＳ３３で要求情報が解析される。ここまでは図４のステップＳ１１〜Ｓ１３と同じである。そこで、さらにステップＳ３４で自文書内のファイルか否か判断され、自文書内のファイルである時（Ｙｅｓ）はステップＳ３５で要求ファイルが解析される。
また、ステップＳ３６で要求されたファイルがあるか否か判断され、ある時（Ｙｅｓ）はステップＳ３７でヘッダ情報が送信され、ステップＳ３８でファイルが送信される。またステップＳ３６で要求されたファイルがない時（Ｎｏ）はステップＳ３９でエラーメッセージが送信される。このようにして、要求されたファイルが自文書内であった時の要求されたファイルの送信、及び要求されたファイルが無かった場合のエラーメッセージ送信の処理が行われる。以上の処理は、図４のステップＳ１５〜Ｓ１８と同じである。
これに対して、ステップＳ３４で要求されたファイルが自文書内でなかった時（Ｎｏ）は、ステップＳ４０で他文書にファイルの要求を行い、ステップＳ４１でファイルがＯＫか否か判断される。そしてファイルがＯＫの時（Ｙｅｓ）はステップＳ４２でファイルが受信され、ステップＳ３７でヘッダ情報が送信され、ステップＳ３８でファイルが送信される。またステップＳ４１で要求されたファイルＯＫでない時（Ｎｏ）はステップＳ４３でエラーメッセージが送信される。
このようにして、ステップＳ３４で要求されたファイルが自文書内でなかった時に、他文書からのファイルを受信して、要求されたファイルの送信、及び要求されたファイルが無かった場合のエラーメッセージ送信の処理が行われる。すなわち、上記コマンド中のdocument3により、どの文書の要求を受けているかが判断できるので、対応する文書（document3）にアクセスし、document3からindex.html を受け取って、それをウェブブラウザに送信することで、複数の文書のコンテンツ処理を一つのウェブサーバプログラムが請け負うことが可能になる。
つまり、委託を受けているウェブサーバプログラムは、GETコマンドを解析した結果、自文書内のコンテンツ要求であれば、図４に示した通常とほぼ同じ動作を行い、GETコマンドを解析した結果、他文書内のコンテンツであった場合には、その文書に対してコンテンツの要求を行い、ファイルをその文書から受信し、受信したファイルをウェブブラウザに対して送信する。さらに、委託しているウェブサーバプログラムの処理の流れについては図９に示す。
すなわち図９において、ステップＳ５１では他のプログラムからのコンテンツ要求が待ち受けられる。そして要求があるとステップＳ５２で処理スレッドが生成され、ステップＳ５３で要求情報が解析され、ステップＳ５４で要求ファイルが解析される。さらに、ステップＳ５５で要求されたファイルがあるか否か判断され、ある時（Ｙｅｓ）はステップＳ５６でファイルが送信される。またステップＳ５５で要求されたファイルがない時（Ｎｏ）はステップＳ５７でエラーメッセージが送信される。
このようにして、自分でソケットを生成できない場合は、他のウェブサーバプログラムからコンテンツ要求を受け付けることのできるソケットを生成し待ち受ける。そして、他のウェブサーバプログラムからコンテンツの要求があった場合に要求を解析し、要求に応じたファイルを取得して送信する。また、要求されたファイルが存在しない場合にはエラーメッセージを送信する。
さらに、委託を受けているウェブサーバ機能を有する文書が閉じた場合の処理を以下に説明する。すなわち、委託を受けているウェブサーバ機能を有する文書中のプログラムがクローズイベントを取得した場合は、ソケットをクローズするとともに他に起動している文書があればその文書に委託し、ソケットを作成させる。この様子を図１０に示す。なおこの場合には、先に述べたような起動文書の情報もあわせて送信して終了する。
また、ウェブサーバ機能を委託している文書が閉じたときの処理は以下に説明する。すなわち、ウェブサーバ機能を他の文書に委託している場合は、その委託先のプログラムに終了することを通知する。この様子を図１１に示す。ここで、終了情報を受けたウェブサーバ機能を委託されているサーバは、図７に示した文書リンク情報から該当する文書を削除し、リンクから外す。
従って、上述した本発明の実施形態において、簡単な手段でインターネットサービスプロバイダを介することなく、ユーザが自分のマシンをウェブサーバ化、ブログサーバ化して、個人が所有する情報の公開を容易に行うことができる。
さらに以下には、ウェブサーバ機能を有する文書の作成方法を説明する。ここでは最初に、マニフェストファイルの記述例を以下に示す。
Manifest-Version: 1.0
Main-Class: jp.co.ricoh.project.AppMain
Created-By: 1.3.1 (Sun Microsystems Inc.)
Manifest-Version: 1.0
Main-Class: jp.co.ricoh.project.AppMain
Created-By: 1.3.1 (Sun Microsystems Inc.)
ここで２行目はmain関数のあるclassファイル名である。これを指定しておくことによって起動時に最初にロードされるclassファイルを決定することができる。３行目はJavaのバージョンおよびサプライヤである。また、マニフェストファイルと、コンテンツ、およびプログラムファイル群（classファイル群）をZIP化して一つにする。ファイル拡張子はjarとする。
ZIP化の方法を以下に示す。
ZIP化するファイルの読み込みおよびバイト配列への格納
↓
ファイル書き出しストリーム生成
↓
ZIPの書き出しストリームを生成してファイル書き出しストリームを渡す
↓
ZIPエントリを生成しZIPの書き出しストリームに登録
↓
ZIPの書き出しストリームに先のバイト配列を書き込み
↓
ZIPエントリのクローズ
↓
終了処理
ZIP化するファイルの読み込みおよびバイト配列への格納
↓
ファイル書き出しストリーム生成
↓
ZIPの書き出しストリームを生成してファイル書き出しストリームを渡す
↓
ZIPエントリを生成しZIPの書き出しストリームに登録
↓
ZIPの書き出しストリームに先のバイト配列を書き込み
↓
ZIPエントリのクローズ
↓
終了処理
この処理は一つのファイルをZIP化する際の基本的な処理の流れであるが、複数ファイルに渡っても基本的な処理は同じである。以上のようにして、マニフェストファイル、コンテンツ、ウェブサーバ機能を提供するプログラム群を一つの書庫ファイルとして扱うことができる。
さらに、JavaのSDK（Software DevelopementKit）をインストールしてある環境であれば、
jar cvfm sample.jar manifest.mf *.*
などとコマンドを打つことにより、容易にJarファイルの生成が可能である。つまり、Javaプログラミングで言えば、Runtimeの外部プログラム呼び出しの文字列に
jar cvfm sample.jar manifest.mf *.*
としてやることによってJarファイルの作成が可能である。
jar cvfm sample.jar manifest.mf *.*
などとコマンドを打つことにより、容易にJarファイルの生成が可能である。つまり、Javaプログラミングで言えば、Runtimeの外部プログラム呼び出しの文字列に
jar cvfm sample.jar manifest.mf *.*
としてやることによってJarファイルの作成が可能である。
さらに、本発明における内部コンテンツの作成方法及び編集方法について説明する。すなわち、ウェブブラウザを使って編集できれば、文書さえ起動しておけば、ネットワークにつながっていればどこからでも作成、編集ができて便利である。ここでは一番基本的なPOST（Power On Self Test）コマンドを利用した編集方法について述べる。これまでは、GETコマンドでウェブサーバプログラムにファイルを送ってもらっていたが、編集するにはウェブサーバプログラムがPOSTコマンドの処理能力が必要である。ただし、実際にはGETでも投稿可である。
そこで、POSTコマンドの処理は、ＣＧＩ（Common Gateway Interface）が行う場合が多い。ＣＧＩはデータ処理用のプログラムで掲示板やカウンタの機能を提供していることが多い。Perl（Practical Extraction and Report Language）で記述されることが多いが、要はPOSTコマンドを処理できれば良いのでプログラム言語は何でも構わない。またスクリプトとして埋め込んでしまう方法もある。
POSTコマンドは主に記事を投稿する際にウェブブラウザが発行するコマンドである。つまり、サーバプログラムに対してデータを送信するためのコマンドである。POSTコマンドを利用したウェブサーバプログラムとウェブブラウザプログラムのデータのやり取りを以下に示す。
まず、ウェブブラウザがGETコマンドで編集用ページを取得する。ここでは、例えば文書中「作成」などと書いたリンクをクリックするとサーバプログラムが送信してくるHTMLである(実際にはログイン認証を経る)。このような取得を行うHTMLの例を以下に示す。
<html>
<head>
</head>
<body>
<form action = "http://machine:8080/programs/post" method = "post">
<p>
<textarea name="textarea" rows=5 cols=50></textarea><br>
<input type = "submit" value = "send"> <input type = "reset" value = "reset"><br>
</p>
</form>
</body>
</html>
<head>
</head>
<body>
<form action = "http://machine:8080/programs/post" method = "post">
<p>
<textarea name="textarea" rows=5 cols=50></textarea><br>
<input type = "submit" value = "send"> <input type = "reset" value = "reset"><br>
</p>
</form>
</body>
</html>
従って、ウェブブラウザがこのHTMLを受信し、ユーザがテキストエリアに文字を入力し、[send］ボタンを押すことによって、ウェブサーバプログラムに対してテキストエリア内に記述された情報が渡される。ウェブサーバプログラムはそれを解釈することでコンテンツに反映することができる。
なお、直接HTMLを編集する方法もあるが、その場合はHTML編集プログラムを呼び出して編集する。例えばJavaであれば、外部プログラムを呼び出すプロセスを生成可能である。この際にどの外部プログラムを呼び出すかは、ユーザによる指定が必要である。
ただし、編集及びファイル新規作成時の問題点としては、Zipファイルにはヘッダファイルがあり、そのファイルにはZip化されているファイル名とサイズなどが記載されている。このファイルと実際のファイルの整合性が取れないと単に編集したものをそのまま詰め込むだけではエラーになってしまう。これに対応するには、編集後のファイルサイズを取得してヘッダファイルの書き換えを行うか、Jarファイル自体を作り直す必要がある。新しいファイルを挿入する場合も同様である。
〔ＲＳＳの生成〕
RSS（RDF Site Summary または Rich Site Summary）は、ウェブサイトの概要をメタデータとして簡潔に記述するXMLフォーマットである。最近は、ウェブサイトにおいて新しい情報をRSSとして提供するところが増えてきている。多くのブログでもこの機能を提供している。RSSリーダなるものがあり、各サイトやブログのRSSを登録しておくと、各サイトの記事の一覧を取得することができる。Jarファイル内のコンテンツに変更があった場合にRSSを書き出す。なお、RSSは簡単なスクリプトで自動生成することが可能である。
RSS（RDF Site Summary または Rich Site Summary）は、ウェブサイトの概要をメタデータとして簡潔に記述するXMLフォーマットである。最近は、ウェブサイトにおいて新しい情報をRSSとして提供するところが増えてきている。多くのブログでもこの機能を提供している。RSSリーダなるものがあり、各サイトやブログのRSSを登録しておくと、各サイトの記事の一覧を取得することができる。Jarファイル内のコンテンツに変更があった場合にRSSを書き出す。なお、RSSは簡単なスクリプトで自動生成することが可能である。
〔ＲＳＳの例〕
<?xml version="1.0" encoding="utf-8" ?>
<rdf:RDF
xmlns="http://purl.org/rss/1.0/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xml:lang="ja">
<channel rdf:about="http://machine.ricoh.co.jp/rss.rdf">
<title>Ricohカメラ</title>
<link>http://machine.ricoh.co.jp</link>
<description>Ricoh製のカメラについての情報を提供しています。</description>
<items>
<rdf:Seq>
<rdf:lirdf:resource="http://machine.ricoh.co.jp/camera/"/>
<rdf:lirdf:resource="http://machine.ricoh.co.jp/docs/manual.html"/>
</rdf:Seq>
</items>
</channel>
<item rdf:about="http://machine.ricoh.co.jp/camera/">
<title>歴代カメラ</title>
<link>http://machine.ricoh.co.jp/camera/</link>
<description>歴代のカメラの一覧です。</description>
</item>
<item rdf:about="http://machine.ricoh.co.jp/docs/manual.html">
<title>各カメラのマニュアル類</title>
<link>http://machine.ricoh.co.jp/docs/manual.html</link>
<description>歴代の製品のマニュアルの一覧です。</description>
</item>
</rdf:RDF>
<?xml version="1.0" encoding="utf-8" ?>
<rdf:RDF
xmlns="http://purl.org/rss/1.0/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xml:lang="ja">
<channel rdf:about="http://machine.ricoh.co.jp/rss.rdf">
<title>Ricohカメラ</title>
<link>http://machine.ricoh.co.jp</link>
<description>Ricoh製のカメラについての情報を提供しています。</description>
<items>
<rdf:Seq>
<rdf:lirdf:resource="http://machine.ricoh.co.jp/camera/"/>
<rdf:lirdf:resource="http://machine.ricoh.co.jp/docs/manual.html"/>
</rdf:Seq>
</items>
</channel>
<item rdf:about="http://machine.ricoh.co.jp/camera/">
<title>歴代カメラ</title>
<link>http://machine.ricoh.co.jp/camera/</link>
<description>歴代のカメラの一覧です。</description>
</item>
<item rdf:about="http://machine.ricoh.co.jp/docs/manual.html">
<title>各カメラのマニュアル類</title>
<link>http://machine.ricoh.co.jp/docs/manual.html</link>
<description>歴代の製品のマニュアルの一覧です。</description>
</item>
</rdf:RDF>
これによるRSS生成の主な流れは以下の通りである。
HTMLのソースを読み込み
↓
タイトルや日付、説明文などの必要な情報の取り込み
↓
RSSの構文にしたがって出力
HTMLのソースを読み込み
↓
タイトルや日付、説明文などの必要な情報の取り込み
↓
RSSの構文にしたがって出力
上記例にあげた形式でRSSのXMLファイルを出力してやることにより、RSSリーダで更新情報を把握することが可能になる。ウェブサーバプログラムとしては、RSSを書き出す機能を追加するのみでよく、GETコマンドでこのファイルを要求してきたプログラムに対して、ファイルを送信すればよい。つまり、通常のGETコマンドの処理と全く同じである。
〔複数文書のＲＳＳの統合〕
一つのマシン上で複数の文書が起動している場合、複数のRSSファイルが存在する。この場合はそれぞれのRSSを統合した新しいRSSファイルを提供する。つまり、RSSリーダなどがそのひとつのRSSファイルを読み込むことにより、複数の文書の更新情報がわかるようにする。
一つのマシン上で複数の文書が起動している場合、複数のRSSファイルが存在する。この場合はそれぞれのRSSを統合した新しいRSSファイルを提供する。つまり、RSSリーダなどがそのひとつのRSSファイルを読み込むことにより、複数の文書の更新情報がわかるようにする。
〔方法〕
先に述べたように、複数文書が起動する際には、最初に起動した文書にあるウェブサーバプログラムが複数文書分のコンテンツを提供する。RSSファイルの提供も同様である。ウェブサーバ機能を委託している文書は、文書の更新が行われたことを検知すると、RSSを生成し、委託先のプログラムに対してRSSファイル自体あるいは内容を通知する。通知するファイルの内容は例えば以下の通りである（上記と同様）。
先に述べたように、複数文書が起動する際には、最初に起動した文書にあるウェブサーバプログラムが複数文書分のコンテンツを提供する。RSSファイルの提供も同様である。ウェブサーバ機能を委託している文書は、文書の更新が行われたことを検知すると、RSSを生成し、委託先のプログラムに対してRSSファイル自体あるいは内容を通知する。通知するファイルの内容は例えば以下の通りである（上記と同様）。
<?xml version="1.0" encoding="utf-8" ?>
<rdf:RDF
xmlns="http://purl.org/rss/1.0/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xml:lang="ja">
<channel rdf:about="http://machine.ricoh.co.jp/rss.rdf">
<title>Ricoh複写機</title>
<link>http://machine.ricoh.co.jp</link>
<description>Ricoh製の複写機についての情報を提供しています。</description>
<items>
<rdf:Seq>
<rdf:lirdf:resource="http://machine.ricoh.co.jp/copier/"/>
</rdf:Seq>
</items>
</channel>
<item rdf:about="http://machine.ricoh.co.jp/copier/">
<title>歴代複写機</title>
<link>http://machine.ricoh.co.jp/copier/</link>
<description>歴代の複写機の一覧です。</description>
</item>
</rdf:RDF>
<rdf:RDF
xmlns="http://purl.org/rss/1.0/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xml:lang="ja">
<channel rdf:about="http://machine.ricoh.co.jp/rss.rdf">
<title>Ricoh複写機</title>
<link>http://machine.ricoh.co.jp</link>
<description>Ricoh製の複写機についての情報を提供しています。</description>
<items>
<rdf:Seq>
<rdf:lirdf:resource="http://machine.ricoh.co.jp/copier/"/>
</rdf:Seq>
</items>
</channel>
<item rdf:about="http://machine.ricoh.co.jp/copier/">
<title>歴代複写機</title>
<link>http://machine.ricoh.co.jp/copier/</link>
<description>歴代の複写機の一覧です。</description>
</item>
</rdf:RDF>
ファイルもしくは情報を受信すると、委託を受けているプログラムは、自身のRSSファイル（最初の例）とマージして以下のようなRSSファイルを生成する。
<?xml version="1.0" encoding="utf-8" ?>
<rdf:RDF
xmlns="http://purl.org/rss/1.0/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xml:lang="ja">
<channel rdf:about="http://machine.ricoh.co.jp/rss.rdf">
<title>文書更新情報</title>
<link>http://machine.ricoh.co.jp</link>
<description>machine上の文書の情報を提供しています。</description>
<items>
<rdf:Seq>
<rdf:lirdf:resource="http://machine.ricoh.co.jp/document1/camera/"/>
<rdf:lirdf:resource="http://machine.ricoh.co.jp/document1/docs/manual.html"/>
<rdf:lirdf:resource="http://machine.ricoh.co.jp/document2/copier/"/>
</rdf:Seq>
</items>
</channel>
<item rdf:about="http://machine.ricoh.co.jp/document1/camera/">
<title>歴代カメラ</title>
<link>http://machine.ricoh.co.jp/document1/camera/</link>
<description>歴代のカメラの一覧です。</description>
</item>
<item rdf:about="http://machine.ricoh.co.jp/document1/docs/manual.html">
<title>各カメラのマニュアル類</title>
<link>http://machine.ricoh.co.jp/document1/docs/manual.html</link>
<description>歴代の製品のマニュアルの一覧です。</description>
</item>
<item rdf:about="http://machine.ricoh.co.jp/document2/copier/">
<title>歴代複写機</title>
<link>http://machine.ricoh.co.jp/document2/copier/</link>
<description>歴代の複写機の一覧です。</description>
</item>
</rdf:RDF>
<rdf:RDF
xmlns="http://purl.org/rss/1.0/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xml:lang="ja">
<channel rdf:about="http://machine.ricoh.co.jp/rss.rdf">
<title>文書更新情報</title>
<link>http://machine.ricoh.co.jp</link>
<description>machine上の文書の情報を提供しています。</description>
<items>
<rdf:Seq>
<rdf:lirdf:resource="http://machine.ricoh.co.jp/document1/camera/"/>
<rdf:lirdf:resource="http://machine.ricoh.co.jp/document1/docs/manual.html"/>
<rdf:lirdf:resource="http://machine.ricoh.co.jp/document2/copier/"/>
</rdf:Seq>
</items>
</channel>
<item rdf:about="http://machine.ricoh.co.jp/document1/camera/">
<title>歴代カメラ</title>
<link>http://machine.ricoh.co.jp/document1/camera/</link>
<description>歴代のカメラの一覧です。</description>
</item>
<item rdf:about="http://machine.ricoh.co.jp/document1/docs/manual.html">
<title>各カメラのマニュアル類</title>
<link>http://machine.ricoh.co.jp/document1/docs/manual.html</link>
<description>歴代の製品のマニュアルの一覧です。</description>
</item>
<item rdf:about="http://machine.ricoh.co.jp/document2/copier/">
<title>歴代複写機</title>
<link>http://machine.ricoh.co.jp/document2/copier/</link>
<description>歴代の複写機の一覧です。</description>
</item>
</rdf:RDF>
生成されるファイルのポイントは、リソースの指定で
http://machine.ricoh.co.jp/camera/
だったものが、統合の結果
http://machine.ricoh.co.jp/document1/camera/
のようにマシン名の下に仮想的に階層を作って文書ごとにＵＲＬを変えるところである。
http://machine.ricoh.co.jp/camera/
だったものが、統合の結果
http://machine.ricoh.co.jp/document1/camera/
のようにマシン名の下に仮想的に階層を作って文書ごとにＵＲＬを変えるところである。
このようにして文書同士でコンテンツ名が同じ場合でも対応できるようにする。ウェブサーバプログラムの委譲のところで述べたように、GETコマンドでdocument1以下がわかるので、対応するファイルを要求元に返すことができる。また、上記document1などの仮想的な階層名と文書とのテーブルはサーバプログラムがRSS受信時に関係を保持しておけばよい。
〔更新の通知〕
上記は、更新時のRSSの生成であるが、RSSファイルを生成する変わりに、サーバなどの指定のマシンに通知したり、メールを送信したりすることも可能である。ただしメールを送信する場合は、ユーザにメールサーバなどの設定を促す必要が生じる。
メールサーバの設定項目（文書保持ユーザへの入力促し)
・SMTPサーバ（送信用）
・POPもしくはIMAP4などの受信用サーバ（なしでもよい）
・ユーザID、パスワード
・その他詳細設定
以上の項目をユーザに予め設定させておく。
上記は、更新時のRSSの生成であるが、RSSファイルを生成する変わりに、サーバなどの指定のマシンに通知したり、メールを送信したりすることも可能である。ただしメールを送信する場合は、ユーザにメールサーバなどの設定を促す必要が生じる。
メールサーバの設定項目（文書保持ユーザへの入力促し)
・SMTPサーバ（送信用）
・POPもしくはIMAP4などの受信用サーバ（なしでもよい）
・ユーザID、パスワード
・その他詳細設定
以上の項目をユーザに予め設定させておく。
以上の設定が済んでいれば、RSSファイル記述と同様に、テキストで更新された情報に関してメールで通知することができる。なお、以上の設定は、このウェブサーバ機能付文書の所有者が設定する。他の、この文書の編集情報をメールで送信してもらいたいユーザは、メールアドレスのみを登録する。これによりサーバプログラムは、登録されたメールアドレスに対して、更新内容を送信する。
こうして本発明のカプセル化文書構造によれば、表現実体となる１又は２以上のデジタル情報ファイルと、デジタル情報ファイルの構造及び表示状態を特定する表示情報ファイルと、コンピュータによって共に解釈、実行され、デジタル情報を参照せずに特有の機能を実行するための機能動作プログラムを含む動作プログラムファイルとを具備し、ウェブブラウザの要求に応じてデジタル情報ファイル内のコンテンツをブラウザに送信するウェブサーバ機能を有するプログラムファイルがデジタル情報ファイルとともに単一の文書としてカプセル化されることにより、簡単な手段でインターネットサービスプロバイダを介することなく、ユーザが自分のマシンをウェブサーバ化、ブログサーバ化して、個人が所有する情報の公開を容易に行うことができるものである。
また、本発明のウェブサーバ機能を有する文書の作成方法によれば、マニュフェストファイルを記述し、マニュフェストファイル中のクラスファイルを指定し、マニュフェストファイルとコンテンツと、クラスファイルとしてのウェブサーバ機能を有するプログラムファイルを単一の文書としてカプセル化することにより、簡単な手段でインターネットサービスプロバイダを介することなく、ユーザが自分のマシンをウェブサーバ化、ブログサーバ化して、個人が所有する情報の公開を容易に行うことのできる文書を作成することができるものである。
なお本発明は、上述の説明した実施形態に限定されるものではなく、特許請求の範囲の記載を逸脱しない範囲において、種々の変形が可能とされるものである。
１…META-INFフォルダ、２…コンテンツフォルダ、３…プログラムフォルダ
Claims (11)
- 表現実体となる１又は２以上のデジタル情報ファイルと、前記デジタル情報ファイルの構造及び表示状態を特定する表示情報ファイルと、コンピュータによって共に解釈、実行され、前記デジタル情報を参照せずに特有の機能を実行するための機能動作プログラムを含む動作プログラムファイルとを具備し、
ウェブブラウザの要求に応じて前記デジタル情報ファイル内のコンテンツをブラウザに送信するウェブサーバ機能を有するプログラムファイルが前記デジタル情報ファイルとともに単一の文書としてカプセル化されている
ことを特徴とするカプセル化文書構造。 - 前記表示情報ファイルに基づいて特定される表示状態で前記１又は２以上のデジタル情報ファイルを前記コンピュータのディスプレイ上に表示させるデジタル情報表示プログラムが単一の文書としてカプセル化されている
ことを特徴とする請求項１に記載のカプセル化文書構造。 - 前記表示情報ファイル内のコンテンツを編集するコンテンツ編集機能を有するプログラムファイルが単一の文書としてカプセル化されている
ことを特徴とする請求項１に記載のカプセル化文書構造。 - 前記表示情報ファイル内のコンテンツの更新情報を送信する更新情報送信機能を有するプログラムファイルが単一の文書としてカプセル化されている
ことを特徴とする請求項３に記載のカプセル化文書構造。 - 前記ウェブサーバ機能を有するプログラムファイルは、既に他のウェブサーバプログラムが起動している場合には、そのウェブサーバプログラムに前記ウェブサーバ機能を委託する
ことを特徴とする請求項１に記載のカプセル化文書構造。 - 前記委託を受ける機能を含む前記ウェブサーバ機能を有するプログラムファイルが単一の文書としてカプセル化されている
ことを特徴とする請求項５に記載のカプセル化文書構造。 - 保持しているコンテンツに関するメタ情報を公開するメタ情報公開機能を有するプログラムファイルが単一の文書としてカプセル化されている
ことを特徴とする請求項１に記載のカプセル化文書構造。 - マシン上で起動している文書のメタ情報を統合するメタ情報統合機能を有するプログラムファイルが単一の文書としてカプセル化されている
ことを特徴とする請求項７に記載のカプセル化文書構造。 - マニュフェストファイルを記述し、
前記マニュフェストファイル中のクラスファイルを指定し、
前記マニュフェストファイルとコンテンツと、前記クラスファイルとしてのウェブサーバ機能を有するプログラムファイルを単一の文書としてカプセル化する
ことを特徴とするウェブサーバ機能を有する文書の作成方法。 - 前記ウェブサーバ機能を有するプログラムファイルは、既に他のウェブサーバプログラムが起動している場合には、そのウェブサーバプログラムに前記ウェブサーバ機能を委託する
ことを特徴とする請求項９に記載のウェブサーバ機能を有する文書の作成方法。 - 前記委託を受ける機能を含む前記ウェブサーバ機能を有するプログラムファイルが単一の文書としてカプセル化されている
ことを特徴とする請求項１０に記載のウェブサーバ機能を有する文書の作成方法。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2005223083A JP2007041702A (ja) | 2005-08-01 | 2005-08-01 | カプセル化文書構造及びウェブサーバ機能を有する文書の作成方法 |
| US11/495,669 US20070027950A1 (en) | 2005-08-01 | 2006-07-31 | Encapsulated document structure, method of creating document having web server functions, and computer-readable program |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2005223083A JP2007041702A (ja) | 2005-08-01 | 2005-08-01 | カプセル化文書構造及びウェブサーバ機能を有する文書の作成方法 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2007041702A true JP2007041702A (ja) | 2007-02-15 |
Family
ID=37695648
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2005223083A Pending JP2007041702A (ja) | 2005-08-01 | 2005-08-01 | カプセル化文書構造及びウェブサーバ機能を有する文書の作成方法 |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US20070027950A1 (ja) |
| JP (1) | JP2007041702A (ja) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2013012225A (ja) * | 2012-08-30 | 2013-01-17 | Hitachi Ltd | 名称特定プログラム、構成管理サーバおよび情報処理システム |
| WO2018110352A1 (ja) | 2016-12-14 | 2018-06-21 | 特定非営利活動法人サイバー・キャンパス・コンソーシアムＴｉｅｓ | コンテンツのカプセル化構造ならびにそれを用いるコンテンツ提供方法およびシステム |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9092538B2 (en) * | 2008-09-30 | 2015-07-28 | Disney Enterprises, Inc. | System and method for determining the data model used to create a web page |
| US20110265058A1 (en) * | 2010-04-26 | 2011-10-27 | Microsoft Corporation | Embeddable project data |
| JP6736943B2 (ja) * | 2016-03-29 | 2020-08-05 | 富士通株式会社 | 情報処理装置、情報処理方法、情報処理プログラム及び情報配信システム |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2004102821A (ja) * | 2002-09-11 | 2004-04-02 | Ricoh Co Ltd | 文書のデータ構造、記憶媒体、データ処理装置及び文書閲覧システム |
| JP2004110733A (ja) * | 2002-09-20 | 2004-04-08 | Ricoh Co Ltd | 情報処理装置、情報処理方法、及び情報処理プログラム |
| JP2005182595A (ja) * | 2003-12-22 | 2005-07-07 | Ricoh Co Ltd | 文書ファイルのデータ構造、記録媒体、文書ファイル転送方法、文書ファイル受信プログラム、文書ファイル受信方法および情報処理装置 |
Family Cites Families (21)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6963920B1 (en) * | 1993-11-19 | 2005-11-08 | Rose Blush Software Llc | Intellectual asset protocol for defining data exchange rules and formats for universal intellectual asset documents, and systems, methods, and computer program products related to same |
| US5877765A (en) * | 1995-09-11 | 1999-03-02 | Microsoft Corporation | Method and system for displaying internet shortcut icons on the desktop |
| US6055522A (en) * | 1996-01-29 | 2000-04-25 | Futuretense, Inc. | Automatic page converter for dynamic content distributed publishing system |
| JPH11514769A (ja) * | 1996-08-08 | 1999-12-14 | アグラナット・システムス・インコーポレーテッド | 埋め込み形ウェブサーバ |
| US6807559B1 (en) * | 2000-04-06 | 2004-10-19 | Attachmate Corporation | System and method for applet management |
| US7131108B1 (en) * | 2000-04-17 | 2006-10-31 | Ncr Corporation | Software development system having particular adaptability to financial payment switches |
| US6918106B1 (en) * | 2000-07-31 | 2005-07-12 | Sun Microsystems, Inc. | Method and apparatus for collocating dynamically loaded program files |
| US20030014441A1 (en) * | 2001-06-29 | 2003-01-16 | Akira Suzuki | Document data structure, information recording medium, information processing apparatus, information processing system and information processing method |
| US20030058271A1 (en) * | 2001-09-27 | 2003-03-27 | Koninklijke Philips Electronics N.V. | Method and system and article of manufacture for internet slide show |
| US7152222B2 (en) * | 2002-01-08 | 2006-12-19 | International Business Machines Corporation | Method and system for localizing Java™ JAR files |
| JP2003208343A (ja) * | 2002-01-10 | 2003-07-25 | Ricoh Co Ltd | ファイル作成・閲覧方法、ファイル作成方法、ファイル閲覧方法、ファイル構造及びプログラム |
| JP3920675B2 (ja) * | 2002-03-22 | 2007-05-30 | 株式会社リコー | データ通信方法、コンピュータ、プログラム及び記憶媒体 |
| US20030191823A1 (en) * | 2002-04-03 | 2003-10-09 | Aplion Networks, Inc. | System and method for providing customizable device capabilities to network equipment in a non-service affecting manner |
| JP2004110573A (ja) * | 2002-09-19 | 2004-04-08 | Ricoh Co Ltd | データ通信方法、データ通信装置、データ通信システム及びデータ通信プログラム |
| US20040194027A1 (en) * | 2002-12-27 | 2004-09-30 | Akira Suzuki | Computerized electronic document producing, editing and accessing system for maintaining high-security |
| US8209680B1 (en) * | 2003-04-11 | 2012-06-26 | Vmware, Inc. | System and method for disk imaging on diverse computers |
| US7451392B1 (en) * | 2003-06-30 | 2008-11-11 | Microsoft Corporation | Rendering an HTML electronic form by applying XSLT to XML using a solution |
| US7523116B2 (en) * | 2003-10-30 | 2009-04-21 | International Business Machines Corporation | Selection of optimal execution environment for software applications |
| JP2005267021A (ja) * | 2004-03-17 | 2005-09-29 | Ricoh Co Ltd | 文書作成方法、文書作成装置、プログラム、記憶媒体および文書のデータ構造 |
| JP2006018430A (ja) * | 2004-06-30 | 2006-01-19 | Ricoh Co Ltd | 情報処理装置、ネットワークシステム、プログラム、データ構造及び記憶媒体 |
| JP2006059319A (ja) * | 2004-07-21 | 2006-03-02 | Ricoh Co Ltd | 情報処理装置、プログラムおよび記憶媒体 |
-
2005
- 2005-08-01 JP JP2005223083A patent/JP2007041702A/ja active Pending
-
2006
- 2006-07-31 US US11/495,669 patent/US20070027950A1/en not_active Abandoned
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2004102821A (ja) * | 2002-09-11 | 2004-04-02 | Ricoh Co Ltd | 文書のデータ構造、記憶媒体、データ処理装置及び文書閲覧システム |
| JP2004110733A (ja) * | 2002-09-20 | 2004-04-08 | Ricoh Co Ltd | 情報処理装置、情報処理方法、及び情報処理プログラム |
| JP2005182595A (ja) * | 2003-12-22 | 2005-07-07 | Ricoh Co Ltd | 文書ファイルのデータ構造、記録媒体、文書ファイル転送方法、文書ファイル受信プログラム、文書ファイル受信方法および情報処理装置 |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2013012225A (ja) * | 2012-08-30 | 2013-01-17 | Hitachi Ltd | 名称特定プログラム、構成管理サーバおよび情報処理システム |
| WO2018110352A1 (ja) | 2016-12-14 | 2018-06-21 | 特定非営利活動法人サイバー・キャンパス・コンソーシアムＴｉｅｓ | コンテンツのカプセル化構造ならびにそれを用いるコンテンツ提供方法およびシステム |
Also Published As
| Publication number | Publication date |
|---|---|
| US20070027950A1 (en) | 2007-02-01 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4594621B2 (ja) | 分散コンピューティング環境における集約サービスの供給 | |
| US10223335B2 (en) | Client-side web service provider | |
| US20090100321A1 (en) | Universal contextual actions menu across windows applications | |
| EP1370951A2 (en) | Messaging infrastructure for identity-centric data access | |
| US20140298154A1 (en) | Method and framework for content viewer integrations | |
| JP2007041702A (ja) | カプセル化文書構造及びウェブサーバ機能を有する文書の作成方法 | |
| Kanjilal | ASP. NET Web API | |
| Balachandar | RESTful Java Web Services: A pragmatic guide to designing and building RESTful APIs using Java | |
| Jackson | Building Microservices with Go | |
| Juneau et al. | RESTful Web Services | |
| Web | Programmable web | |
| Laznik | BPEL and Java Cookbook | |
| Paul et al. | CRUD and REST APIs–Pillars of Efficient Data Exchange | |
| DiLeo et al. | Ruby and the Internet | |
| Goncalves et al. | RESTful web services | |
| Standard | Web Services for Remote Portlets Specification v2. 0 | |
| Andersson | Microsoft Exchange Server 2013 PowerShell Cookbook | |
| Layka et al. | Building Web Applications Using Servlets and JSP | |
| Graham et al. | VOSpace service specification, Version 1.01 | |
| WSDL | UDDI and beyond | |
| Graham et al. | IVOA Recommendation: VOSpace specification Version 1.15 | |
| Simanta et al. | T-Check for Technologies for Interoperability: Open Grid Services Architecture (OGSA): Part 1 | |
| Kanalakis | Integrating. NET Applications | |
| Deinum et al. | Spring Java Enterprise Services and Remoting Technologies | |
| Bruggeman et al. | Reusing Presentation Layers via Web Services for Remote Portlets |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060726 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20080620 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20080620 |
|
| RD02 | Notification of acceptance of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7422 Effective date: 20100302 |
|
| RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20100311 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20110428 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20110913 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20120124 |