JP2002091860A - プログラムを記録したコンピュータ読み取り可能な記録媒体及び計算機システム - Google Patents

Abstract

(57)【要約】 【課題】クライアント種別に応じたサーバアプリケーシ
ョンの重複をなくす。 【解決手段】本発明では、クライアント２の種別に応じ
た形式でこのクライアント２から受信した受信データに
含まれているクライアント種別情報に基づいてクライア
ント種別を判別するクライアント種別判別機能８と、ク
ライアント種別判別機能８によって判別されたクライア
ント種別に基づいて、受信したデータの内容を予め定め
られているデータ構造１０にしたがって記憶するデータ
変換機能９とをコンピュータに実現させるためのプログ
ラムをコンピュータ読み取り可能な記録媒体に記憶して
いる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、多種類のクライア
ントとサーバとの間でデータを送受信するためのプログ
ラムを記録したコンピュータ読み取り可能な記録媒体、
及び計算機システムに関する。

【０００２】

【従来の技術】例えば会計システム、人事給与システ
ム、販売・流通システムなどのビジネスシステム、各種
アプリケーションをサーバに配置してサービスを提供す
るアプリケーション・サービス・プロバイダ（ＡＳＰ）
や企業・個人のホームページサービス、携帯電話におけ
るＷｅｂコンテンツ提供サービスなどを提供する計算機
システムでは、一般的にサーバにデータやビジネスアプ
リケーションが集中して置かれる。そして、クライアン
トは、サーバにアクセスし、サーバアプリケーションを
実行し、データベース（ＤＢ）などの情報蓄積装置から
データを得るというサービスを受ける。

【０００３】クライアントとサーバとの間でやりとりさ
れるデータの最も主流となる形式は文字や数字等のテキ
ストデータである。これらのデータは、基本的に全ての
クライアントとサーバで扱うことが可能である。

【０００４】一方、計算機システムのなかには、クライ
アントとサーバとの間で画像／動画像／音声等のマルチ
メディアデータを送受信するような場合がある。特に、
ホームページサービスを提供するシステム、携帯電話に
おけるコンテンツ提供サービスシステムにおいてマルチ
メディアデータが送受信される。

【０００５】しかし、通常のパーソナルコンピュータ
（以下、「ＰＣ」という）に加え、携帯電話や携帯ＰＣ
などのようにクライアント種別は多種にわたり、画面の
大きさ、スピーカの有無、処理能力など、クライアント
の機能によってはこれらのデータを表示／再生できない
場合がある。

【０００６】このような場合に対応して考え出された技
術に、データ変換装置（特開平１１−１３４２６４号公
報）や、情報交換装置を有する分散ネットワークコンピ
ューティングシステム（特開平１１−２９６４５５号公
報）がある。これらの技術では、接続されたクライアン
トのクライアント種別を判別し、クライアントの機能に
応じて、画像／音声データをクライアントが表示／出力
可能な形式へと変換したり、画像や音声が出力できない
クライアントに対して代わりにテキストデータを送信し
たり、逆に、携帯電話のように音声データを扱えるクラ
イアントに対してテキストデータを音声データに変換し
てサーバからクライアントに送信したりすることが可能
である。

【０００７】また、クライアントとサーバ間の通信イン
フラも多岐にわたる。有線ＬＡＮで結合されている場合
もあるが、電話公衆網、携帯電話では無線ＬＡＮ経由で
クライアントとサーバ間でのデータの送受信が行われる
場合もある。

【０００８】一般的に、電話公衆網や無線ＬＡＮは、有
線ＬＡＮと比較して伝送能力が低い。伝送能力が低い通
信インフラを経由してデータを送受信する場合、伝送能
力の高い送受信を想定したデータがクライアントに供給
されると多大な遅れが生じ、ユーザが十分なサービスを
受けられない場合がある。

【０００９】このような場合に対応して考えられた技術
に、上記の情報交換装置を有する分散ネットワークコン
ピューティングシステム（特開平１１−２９６４５５号
公報）がある。この技術では、通信インフラに応じて、
送受信するデータを一部削減／圧縮し、伝送能力が低い
通信インフラを通じてサーバがクライアントに快適なサ
ービスを提供する手段を提示している。

【００１０】

【発明が解決しようとする課題】上記各技術は、サーバ
から送信されるデータをクライアントの機能／性能、通
信インフラの性能に応じて変換し、提供する技術であ
る。この技術によって、情報量は減少する場合がある
が、通常は表示不可能なデータの内容をクライアントに
提供可能であり、快適にサービスを提供できるようにな
る。

【００１１】しかしながら、ＰＣ／携帯電話／ＰＤＡな
どのようにクライアントハードウェアではなく、クライ
アントアプリケーションに注目すると、伝票金額／商品
在庫などのデータをサーバと送受信するためのビジネス
アプリケーション、ＰＣ上で動作するブラウザ、携帯電
話／ＰＤＡに搭載されているインターネット接続ソフト
などのように、クライアントアプリケーションも多岐に
わたる。

【００１２】これらクライアントアプリケーションで
は、種別が異なると扱うデータの形式も異なるのが現状
である。したがって、クライアントアプリケーションが
同一内容のサーバサービスを受ける場合でも、それぞれ
のクライアントアプリケーションに対応したサーバアプ
リケーションを用意しなくてはならない。

【００１３】例えば、販売管理アプリケーションでは、
オフィス内などに設置されているＰＣからサーバにアク
セスし商品の在庫や原価を確認することもあれば、客先
で携帯電話から商品在庫を確認する場合もある。また、
同じオフィスのＰＣでも、ビジネスアプリケーションか
ら商品の情報にアクセスする場合もあれば、アプリケー
ションをインストールする手間がいらない等の理由から
ブラウザを使って商品の情報を見たいという要望もあ
る。

【００１４】このように、同一のサービス内容を提供す
る場合でも、クライアントアプリケーションの種類に応
じ、それぞれに対応したサーバアプリケーションを実装
することは、生産性の観点から効率的ではない。

【００１５】また、サービスの内容に変更が生じた場
合、それぞれのクライアント種別に対応するサーバアプ
リケーションの全てを変更しなければならず、保守・運
用の観点からも効率的ではない。

【００１６】さらに、人事・会計システム等のビジネス
アプリケーションのようにデータ解釈／データ保持が可
能で特定のＧＵＩ（グラフィカル・ユーザ・インタフェ
ース）等のインタフェースを持つクライアントアプリケ
ーションもあれば、ブラウザに代表されるように基本的
にサーバから送られてきた情報をそのまま表示するだけ
の機能しか持たないクライアントアプリケーションも存
在する。同じ人事情報を提供するサービスでも、データ
処理機能／ＧＵＩを有するクライアントにはデータのみ
を送ればよいのに対し、ブラウザのようなタイプのクラ
イアントには画面構成やユーザインタフェースを含んだ
データを送り返す必要がある。

【００１７】このように、サービスの内容は同一である
が、各クライアントアプリケーションのデータ処理機能
やユーザインタフェース機能などに応じて、提供するサ
ービスに画面構成やユーザインタフェース情報の付加が
必要な場合もある。

【００１８】画面についての情報の有無に応じ、サーバ
アプリケーションを複数実装することも可能であるが、
提供する情報が同一内容のサービスに対して複数のサー
バアプリケーションを実装することは、生産性の効率を
低下させる要因となる。また、サービスの内容に変更が
生じた場合、それぞれのクライアントに対応するサーバ
アプリケーションの全てを変更しなければならず、保守
・運用の効率が低下する。

【００１９】本発明は、以上のような実情に鑑みてなさ
れたもので、サーバにアクセスするクライアントアプリ
ケーションで扱われているデータ形式が異なる場合で
も、またクライアントのデータ処理機能やユーザインタ
フェース機能の有無に関わらず、同一内容のサービスを
提供するサーバアプリケーションを一つにまとめること
を可能にするプログラムを記録したコンピュータ読み取
り可能な記録媒体、及び計算機システムを提供すること
を目的とする。

【００２０】

【課題を解決するための手段】本発明を実現するにあた
って講じた具体的手段について以下に説明する。

【００２１】第１の発明は、コンピュータに、クライア
ントの種別に応じた形式でこのクライアントから受信し
た受信データに含まれているクライアント種別情報に基
づいて、クライアント種別を判別するクライアント種別
判別機能と、クライアント種別判別機能によって判別さ
れたクライアント種別に応じた形式の受信データの内容
を予め定められているデータ構造にしたがって記憶する
データ変換機能とを実現させるためのプログラムを記録
したコンピュータ読み取り可能な記録媒体である。

【００２２】なお、この第１の発明におけるクライアン
ト種別判別機能とデータ変換機能はミドルウェアとして
提供してもよい。

【００２３】また、クライアントは、ハードウェアでも
よく、アプリケーションなどのソフトウェアでもよい。

【００２４】この第１の発明においては、クライアント
からの受信データが所定のデータ構造（共通データ構
造）に変換されて記憶されるため、サーバアプリケーシ
ョンは種別の異なるクライアントからデータを受信する
場合であってもこの共通データ構造のデータをアクセス
すればよい。

【００２５】したがって、多種多様なクライアント種別
毎に、同一内容のサービスを提供するサーバアプリケー
ションを備えるのではなく、同一内容のサービスに一つ
のサーバアプリケーションで対応することができる。こ
れにより、アプリケーションの開発・保守・運用の効率
を向上させることができる。

【００２６】第２の発明は、第１の発明と同様のプログ
ラムを記録したコンピュータ読み取り可能な記録媒体で
あるが、新規のクライアント種別を判別するための機能
をクライアント種別判別機能に追加する種別判別追加機
能と、新規のクライアント種別に応じた形式の受信デー
タの内容を共通データ構造にしたがって記憶するデータ
変換機能を追加するデータ変換追加機能とをコンピュー
タに実現させるためのプログラムを記録している。

【００２７】なお、この第２の発明における種別判別追
加機能とデータ変換追加機能をミドルウェアの要素とし
てもよい。

【００２８】これにより、サーバが新規のクライアント
種別に応じた形式のデータを受信することになる場合で
あっても、サーバアプリケーションを修正する必要がな
い。

【００２９】したがって、既存のシステムを多種多様な
クライアントに対応させることができ、アプリケーショ
ンの開発・保守・運用の効率を向上させることができ
る。

【００３０】第３の発明は、第１の発明と同様のプログ
ラムを記録したコンピュータ読み取り可能な記録媒体で
あるが、データ変換機能は、クライアント種別判別機能
によって判別されたクライアント種別に基づいて、共通
データ構造にしたがって記憶されているデータをクライ
アント種別に応じた形式に変換してクライアントへの送
信データとする。

【００３１】これにより、サーバから多種多様のクライ
アントに対して適切な形式のデータを送信することがで
きる。すなわち、多種多様なクライアント種別につい
て、同一内容のサービスを一つのサーバアプリケーショ
ンで対応することができ、アプリケーションの開発・保
守・運用の効率を向上させることができる。

【００３２】第４の発明は、第３の発明と同様のプログ
ラムを記録したコンピュータ読み取り可能な記録媒体で
あるが、新規のクライアント種別を判別するための機能
をクライアント種別判別機能に追加する種別判別追加機
能と、新規のクライアント種別に応じた形式の受信デー
タの内容を共通データ構造にしたがって記憶し、共通デ
ータ構造にしたがって記憶されているデータを新規のク
ライアント種別に応じた形式に変換してクライアントへ
の送信データとするデータ変換機能を追加するデータ変
換追加機能とをコンピュータに実現させるためのプログ
ラムを記録している。

【００３３】これにより、サーバが新規のクライアント
種別に応じた形式のデータを受信あるいは送信すること
になる場合であっても、サーバアプリケーションを修正
する必要がない。

【００３４】したがって、既存のシステムを多種多様な
クライアントに対応させることができ、アプリケーショ
ンの開発・保守。運用の効率を向上させることができ
る。

【００３５】第５の発明は、第３又は第４の発明と同様
のプログラムを記録したコンピュータ読み取り可能な記
録媒体であるが、クライアント種別判別機能によって判
別されたクライアント種別が画面を表示するための情報
を必要とする場合に、このクライアント種別に応じた画
面構成情報と共通データ構造にしたがって記憶されてい
るデータとに基づいて画面表示データを作成し、この画
面表示データをクライアントへの送信データとする画面
表示データ作成機能をコンピュータに実現させるための
プログラムを記憶している。

【００３６】なお、この第５の発明における画面表示デ
ータ作成機能をミドルウェアの要素としてもよい。

【００３７】したがって、クライアントが画面を表示す
るためのデータを必要とするか否か、あるいはクライア
ントが画面を表示するために必要とするデータの種別に
関係なく、同一内容のサービスを提供するために複数の
サーバアプリケーションを用意する必要がなく、一つの
サーバアプリケーションによって対応することができ
る。これにより、アプリケーションの開発・保守・運用
の効率を向上させることができる。

【００３８】第６の発明は、第５の発明と同様のプログ
ラムを記録したコンピュータ読み取り可能な記録媒体で
あるが、新規のクライアント種別に応じた画面構成情報
を追加する画面構成情報追加機能をコンピュータに実現
させるためのプログラムを記録している。

【００３９】なお、この第２の発明における画面構成情
報追加機能をミドルウェアの要素としてもよい。

【００４０】これにより、サーバが新規のクライアント
種別に対してデータを送信する場合であっても、サーバ
アプリケーションを修正する必要がない。

【００４１】したがって、既存のシステムを多種多様な
クライアントに対応させることができ、アプリケーショ
ンの開発・保守・運用の効率を向上させることができ
る。

【００４２】第７の発明は、第１から第６までの発明と
同様のプログラムを記録したコンピュータ読み取り可能
な記録媒体であるが、クライアントから送信されるデー
タに、クライアント種別情報を付加するクライアント種
別付加機能をコンピュータに実現させるためのプログラ
ムを記録している。

【００４３】これにより、例えば、サーバに送信される
データにクライアント種別を自動的に付加しないクライ
アントであっても、上記第１から第６までの発明と同様
の作用効果を実現できる。

【００４４】第８の発明は、クライアントとサーバとの
間でデータを送受信する計算機システムに関する。この
第８の発明は、クライアントの種別に応じた形式でクラ
イアントから受信した受信データに含まれているクライ
アント種別情報に基づいてクライアント種別を判別する
クライアント種別判別手段と、クライアント種別判別手
段によって判別されたクライアント種別に応じた形式の
受信データの内容を共通データ構造にしたがって記憶す
るデータ変換手段と、共通データ構造にしたがって記憶
されているデータをアクセスしつつ、処理を実行するサ
ーバアプリケーションとを具備した計算機システムであ
る。

【００４５】第９の発明は、第８の発明と同様の計算機
システムであるが、新規のクライアント種別を判別する
ための機能をクライアント種別判別手段に追加する種別
判別追加手段と、新規のクライアント種別に応じた形式
の受信データの内容を共通データ構造にしたがって記憶
するデータ変換手段を追加するデータ変換追加手段とを
付加している。

【００４６】第１０の発明は、第８の発明と同様の計算
機システムであるが、データ変換手段は、クライアント
種別判別手段によって判別されたクライアント種別に基
づいて、共通データ構造にしたがって記憶されているデ
ータをクライアント種別に応じた形式に変換してクライ
アントへの送信データとする。

【００４７】上記第８から第１０までの発明は、上記第
１から第３までの発明で説明したプログラムを記録した
コンピュータ読み取り可能な記録媒体で実現される機能
を備えた計算機システムである。

【００４８】このような計算機システムを利用すること
によって、上述したプログラムを記録したコンピュータ
読み取り可能な記録媒体がコンピュータに読み込まれ、
プログラムが動作する場合と同様の作用効果を実現でき
る。

【００４９】

【発明の実施の形態】本発明は、サーバアプリケーショ
ンが利用するデータを共通データ構造とそれにアクセス
するための共通ＡＰＩ（Application Programming Inte
rface）として提供する。この共通データ構造に各クラ
イアントからのデータを格納するために、クライアント
判別部と各クライアント種別に対応するデータ変換部と
を用いる。

【００５０】クライアントからサーバへのデータの流れ
では、クライアントからのリクエストをサーバ送受信部
が受け、クライアント判別部がクライアント種別を判別
し、このクライアント種別に対応した変換モジュールで
あるデータ変換部が起動される。データ変換部は、クラ
イアント種別毎に用意され、クライアント種別特有のデ
ータ構造から共通データ構造へとデータ変換を行う。

【００５１】これにより、サーバアプリケーションは、
共通データ構造のみをクライアントと送受信するデータ
として扱うことになり、クライアントのデータ形式によ
らずにサーバアプリケーションを一つにまとめることが
可能となる。

【００５２】また、本発明では、データ処理機能やイン
タフェース機能を持たないクライアントに対してサーバ
アプリケーションからサービスを提供する場合に、画面
表示データ作成部によって作成された画面表示データを
提供する。すなわち、サーバからクライアントへのデー
タの流れでは、サーバアプリケーションから共通データ
構造を介してデータ変換部にデータを渡し、データ変換
部が共通データ構造からクライアント種別に応じたデー
タ形式にデータを変換してクライアントアプリケーショ
ンに送信する。クライアントからサーバにデータが受信
された時点で、クライアント判別部においてクライアン
ト種別が判別されているため、このクライアント種別に
したがって自動的に対応するデータ変換部が起動され
る。

【００５３】また、画面を表示するための情報が必要な
クライアント種別の場合には、データ変換部が画面表示
データ作成部を起動し、画面表示データ作成部が画面構
成情報を参照し、データに加えて画面構成やユーザイン
タフェース情報を含む画面表示データをサーバからクラ
イアントに送信するデータとする。

【００５４】このため、クライアントのデータ処理機能
やユーザインタフェース機能の有無に関わらず、サーバ
アプリケーションを一つにまとめることが可能となる。

【００５５】（第１の実施の形態）本実施の形態におい
ては、ある高級プログラミング言語Ａ（以下、「言語
Ａ」という）でプログラミングされ、データ処理機能や
特定のＧＵＩを持つクライアントからサーバにデータが
送信される場合について説明する。

【００５６】図１は、本実施の形態に係る計算機システ
ムの概略構成を例示するブロック図である。

【００５７】計算機システム１は、主にクライアント
２、サーバ３、クライアント２とサーバ３を接続するネ
ットワーク４から構成されている。

【００５８】クライアント２は、例えば一般会計システ
ムや販売管理システムなどのような特定の用途向けに言
語Ａで作成されたクライアントアプリケーション５と、
クライアントデータをネットワーク４上に載せる電文形
式に変換し、サーバとの間でデータを送受信するクライ
アント送受信部６（言語Ａ用）とを備えている。

【００５９】サーバ３は、クライアント２とのデータの
送受信を担当するサーバ送受信部７、クライアント種別
を判別するクライアント種別判別部８、クライアント種
別に応じたデータ形式からサーバアプリケーション共通
のデータ構造に変換するデータ変換部９、クライアント
から受信したデータを格納し、またサーバから送信する
データを格納する共通データ構造１０とそれにアクセス
するための共通ＡＰＩ１１、そしてサービス毎に作成さ
れたサーバアプリケーションを備えている。なお、サー
バアプリケーションの一例としてサーバアプリケーショ
ン１３があり、データベース１２をアクセスする。

【００６０】ネットワーク４は、有線／無線さまざまな
ネットワークが考えられる。クライアントとサーバとの
間で通信が可能となるあらゆるネットワークを利用でき
る。

【００６１】上記のような構成を持つ計算機システム１
において、クライアント２がサーバ３のサービスを受け
る場合の流れを説明する。

【００６２】ここでは、ユーザが、クライアントアプリ
ケーション５を通じて、サーバ３のあるサービスを受け
る場合を想定する。

【００６３】ユーザは、クライアントアプリケーション
５のＧＵＩ等を操作して、サーバ３にサービスを要求す
る。例えば、販売管理システムでは、このサービス要求
は、商品の在庫情報の要求の場合がある。これらの要求
と要求に必要な情報がクライアント送受信部６に渡され
る（ａ１）。

【００６４】クライアント送受信部６は、クライアント
アプリケーション５のデータをネットワーク４のプロト
コルに従ってデータ変換し、クライアント種別情報を付
加した後、サーバ３へ向けて送信する（ａ２）。商品の
在庫情報を要求する場合であれば、在庫数確認の要求と
在庫を確認する商品名が送られることになる。

【００６５】サーバ３では、クライアント２からの要求
（受信データ）をサーバ送受信部７で受け（ａ３）、受
信処理を行う。受信されたデータは、クライアント種別
判別部８に渡され（ａ４）、クライアント種別判別部８
においてクライアント２で付加されたクライアント種別
情報６を参照し、クライアント種別を判別する。クライ
アント種別を判別したら、クライアント種別判別部８は
データ変換部９における言語Ａによるクライアントに対
応したデータ変換部９を起動し、受信したデータを渡す
（ａ５）。

【００６６】データ変換部９は、受信データを共通デー
タ構造１０へと変換・格納し（ａ６）、サーバアプリケ
ーション１３へと処理を移す（ａ７）。

【００６７】サーバアプリケーション１３は、共通デー
タ構造１０に共通ＡＰＩ１１を通じてアクセスし（ａ
８）、共通データ構造１０に格納されたデータを使用し
て指定されたサービスに対応した処理を行う。先の例と
同じく、商品の在庫情報が要求された場合には、サーバ
アプリケーション１３は、共通データ構造１０から共通
ＡＰＩ１１を通じて商品名を獲得し、その商品名をキー
にデータベース１２を検索し、該当商品の在庫数を獲得
する（ａ９）。

【００６８】そして、サーバアプリケーション１３は、
クライアント２に送信するために、商品の在庫数を共通
ＡＰＩ１１を通じて共通データ構造１０へと格納する。
このように、サーバアプリケーション１３は、各サービ
スに対応した処理を行い、クライアント２へ送信するデ
ータを、共通ＡＰＩ１１を通じて共通データ構造１０に
格納し（ａ１０）、データ変換部９へと処理を移行する
（ａ１１）。

【００６９】データ変換部９は、共通データ構造１０の
データをアクセスし（ａ１２）、このデータをネットワ
ーク４のプロトコルとクライアント２の形式にしたがっ
て送信するデータに変換する。変換したデータはサーバ
送受信部７に渡され（ａ１３）、サーバ送受信部７がク
ライアント２に向けてデータを送信する（ａ１４）。

【００７０】再びクライアント２では、クライアント送
受信部６がサーバ３から送られてきた電文を受信し（ａ
１５）、電文データをクライアントアプリケーション５
内で扱えるデータ形式に変換し、クライアントアプリケ
ーション５に渡す（ａ１６）。

【００７１】クライアントアプリケーション５は、渡さ
れたデータの処理を行い、画面に表示する。例えば、商
品の在庫情報を得た場合には、サーバ送受信部７が電文
を解読し、商品の在庫数をクライアントアプリケーショ
ン５が扱えるデータへと変換する。クライアントアプリ
ケーション５は、所定のＧＵＩの位置に、その商品の在
庫数を表示することになる。

【００７２】このようにして、ユーザは、サーバ３のサ
ービスを利用する。

【００７３】上記のような計算機システム１の各構成要
素で実行される処理を詳細に説明する。

【００７４】図２は、クライアントアプリケーション５
の処理の流れを例示する図である。ただし、クライアン
ト２のクライアントアプリケーション５は、用途に応じ
て自由に開発可能であり、必ずしも全てのクライアント
アプリケーションがこの処理の流れにしたがう必要はな
い。

【００７５】ユーザインタフェースステップ５１では、
主に、ユーザからのアクション待ち、ユーザへの情報表
示の処理を行う。ユーザからのアクションを待っている
場合は、ループが回っている（５ａ）。ユーザからアク
ションがあった場合、その内容を処理するために、次の
イベントハンドラステップ５２に処理を移す（５ｂ）。
また、イベントハンドラステップ５２から情報が上がっ
てきた場合（５ｃ）、ユーザインタフェースステップ５
１はユーザに情報を表示する。例えば、ユーザが商品名
を入力している間はループが回っており（５ａ）、商品
名を入力し終わり在庫数検索キーを押下した場合、イベ
ントハンドラステップ１５へ処理が移り（５ｂ）、サー
バ３から在庫数が返ってくる（５ｃ）。

【００７６】イベントハンドラステップ５２では、ユー
ザからのアクションに対応した処理を行う。処理の中
で、サーバ３へのアクセスが必要ならばクライアント送
受信部６に処理を移す（５ｄ）。サーバ３へのアクセス
が必要ない場合はこのステップ５２内で処理を行ってユ
ーザインタフェースステップ５１に処理を移す（５
ｃ）。サーバ３から応答が返ってきた場合は（５ｅ）、
処理を行った後にユーザインタフェースステップ５１に
処理を移す（５ｃ）。例えば、商品在庫数を問い合わせ
る要求に対する処理は、サーバ３へのアクセスが必要な
ためクライアント送受信部６に処理を移し（５ｄ）、サ
ーバ３からの応答を受け（５ｅ）、ユーザインタフェー
スステップ５１に処理結果を返すことになる（５ｃ）。
各商品の注文数と原価から合計値を求めるような処理
は、サーバ３へのアクセスが必要ないため、ユーザイン
タフェースステップ５１から処理が移った後に（５
ｂ）、イベントハンドラステップ５２内で処理を行って
ユーザインタフェースステップ５１に処理を返す（５
ｃ）。

【００７７】図３は、クライアント送受信部６の処理の
流れを例示する図である。上述したようにクライアント
送受信部６は、サーバ３との間でデータを送受信し、ク
ライアント２のデータと電文データのデータ変換を担当
する。このクライアント送受信部６（言語Ａ用）は、プ
ログラミング言語Ａによるクライアント２に対し共通で
使用できる。

【００７８】送信データ作成ステップ６１では、クライ
アントアプリケーション５からデータを受け取り（６
ａ）、そのデータを言語Ａ内のデータ形式からネットワ
ーク電文に合わせてデータ変換を行う。例えば、クライ
アントアプリケーション５のデータ形式が表形式のデー
タであるならば、図４（ａ）の左から右への変換が行わ
れる。キーと値の組み合せ（key=valueのような組み合
せ：以下Hash型とする）のデータの場合は、図４（ｂ）
の左から右への変換が行われる。

【００７９】データ変換後、送信データはエンコードス
テップ６２に送られる（６ｂ）。

【００８０】エンコードステップ６２では、送信データ
の暗号化を行う。クライアント２の処理能力などの理由
から送信データを暗号化しない場合など、このステップ
を省略する場合もある。暗号化されたデータは送信ステ
ップ６３に送られる（６ｃ）。

【００８１】送信ステップ６３では、クライアント種別
情報などのようなクライアント情報やセッションＩＤな
どのヘッダ情報を送信データに付加する。その後、サー
バ３へデータを送信する（６ｄ）。

【００８２】受信ステップ６４では、サーバ３からのデ
ータを受信する（６ｅ）。受信したデータは、デコード
ステップ６５に渡される（６ｆ）。

【００８３】デコードステップ６５では、受信データを
復号する。クライアント２の処理能力などの理由により
受信データが暗号化されていないような場合、このステ
ップは省略される。復号化されたデータは、受信データ
変換ステップ６６に送られる（６ｇ）。

【００８４】受信データ変換ステップ６６では、デコー
ドステップ６５から受け取った受信データを、言語Ａ内
のデータ形式にデータ変換を行う。例えば、受信データ
が表形式のデータならば、図４（ａ）の右から左への変
換が行われる。key=valueのようなHash形式のデータの
場合は、図４（ｂ）の右から左への変換が行われる。デ
ータ変換後、受信データはクライアントアプリケーショ
ン５に送られる（６ｈ）。また、同時にヘッダ情報とし
て送られてきたサーバ情報やセッションＩＤなどを確保
しておく。

【００８５】図５は、サーバ送受信部７の処理の流れを
例示する図である。上述したようにサーバ送受信部７
は、クライアント２との間でデータを送受信する。

【００８６】受信ステップ７１では、クライアント２か
ら送られてきたデータを受信し（７ａ）、クライアント
種別判別部８に受信データを送る（７ｂ）。

【００８７】送信ステップ７２では、クライアント２に
送信するデータがデータ変換部９から送られてくると
（７ｃ）、このデータをクライアント２に送信する（７
ｄ）。

【００８８】図６は、クライアント種別判別部８の処理
の流れを例示する図である。上述したように、クライア
ント種別判別部８はクライアント種別を判別する。

【００８９】種別判別ステップ８１では、サーバ送受信
部７から受信データが送られると（８ａ）、ヘッダ部の
データやクライアント送受信部６で付加されたクライア
ント種別情報を見てクライアント種別を判別する。例え
ば、クライアント／サーバ間の通信プロトコルがHTTPの
場合、ヘッダ部に付加されるUSER-AGENTタグの情報を見
てクライアント種別を判別する。クライアント２がブラ
ウザや携帯端末の場合もUSER-AGENTタグを見れば容易に
クライアント種別を判別することが可能である。プログ
ラミング言語などによりユーザが開発可能なクライアン
トの場合、USER-AGENTタグに情報が入っていない場合が
ある。このような場合は、クライアント送受信部６で付
加したクライアント種別情報を見てクライアント種別を
判別する。種別を判別したら変換部起動ステップ８２に
進む（８ｂ）。

【００９０】変換部起動ステップ８２では、種別判別ス
テップ８１で判別したクライアント種別に対応するデー
タ変換部を起動し、受信データをこのデータ変換部に渡
す（８ｃ）。ここでは、データ変換部９が起動されたと
する。

【００９１】図７は、データ変換部９の処理の流れを例
示する図である。上述したようにデータ変換部９は共通
データ構造１０と送受信データとの間でデータ変換を行
う。一般的にデータ変換部はクライアント種別毎に用意
する必要がある。

【００９２】データ種類判別ステップ９１では、クライ
アント種別判別部８から送られてきた受信データを受け
（９ａ）、そのデータの形式を判別する。例えば、表形
式のデータなのかHash形式のデータなのかなどを判別す
る。その後、データ格納ステップ９２に移行する（９
ｂ）。

【００９３】データ格納ステップ９２では、データ種類
判別ステップ９１から渡された受信データを共通データ
構造１０へと変換・格納する。すなわち、データ格納ス
テップ９２はデータ種類判別ステップ９１で判別したデ
ータ種類に対応したデータを共通データ構造１０に格納
する（９ｃ）。例えば、表形式データの場合、図８
（ａ）の右から左の変換が行われる。またHash形式の場
合、図８（ｂ）の右から左への変換が行われることにな
る。データ変換は、データが存在する限り継続される
（９ｄ）。全てのデータを共通データ構造１０に格納し
たら、サーバアプリケーション１３へ処理を移す（９
ｅ）。

【００９４】一方、データ種類判別ステップ９３では、
サーバアプリケーション１３がクライアント２に送りた
い送信データのデータ形式を判別する。サーバアプリケ
ーション１３からデータ種類判別ステップ９３に処理が
移ると（９ｆ）、共通データ構造１０からデータを取得
し（９ｇ）、データ形式を判別する。判別を終えたら、
取得したデータとともに送信データ作成ステップ９４に
処理を移す（９ｈ）。

【００９５】送信データ作成ステップ９４では、データ
種類判別ステップ９３から送られてきたデータを送信デ
ータに変換し、データ種類判別ステップ９３で判別した
データ種類に対応した送信データを作成する。例えば、
表形式データの場合、図８（ａ）の左から右の変換が行
われる。またHash形式のデータの場合、図８（ｂ）の左
から右への変換が行われることになる。データ変換はデ
ータが存在する限り継続される（９ｉ）。全てのデータ
を変換し、送信データが完成したら、サーバ送受信部７
へ処理を移す（９ｊ）。

【００９６】この例では、データ形式に表形式のデータ
やHash形式のデータなどテキスト中心のデータを送受信
する場合を述べているが、画像・音声等マルチメディア
データを扱うことも可能である。

【００９７】次に、共通データ構造１０と共通ＡＰＩ１
１について説明する。共通データ構造１０とはクライア
ント／サーバ間で送受信するデータを表現可能な汎用的
なデータ構造であり、共通ＡＰＩ１１はこの共通データ
構造１０にアクセスするための汎用的なアクセス手段で
ある。

【００９８】例えば、データを格納する場合、表形式な
ら「SetValue(列指定,行指定,格納するデータ)」などの
ような命令が利用される。図９の例では、「SetValue
(“NAME”,1,”味噌”)」あるいは「SetValue(2,1,”味
噌”)」となる。データを取得したい場合は、「GetValu
e(列指定,行指定)」などのような命令が利用され、図９
の例では、「GetValue(“NAME”,1)」あるいは「GetVal
ue(2,1)」で取得する。

【００９９】Hash形式のデータを格納する場合は、例え
ば「SetValue(key指定,格納するデータ)」などのような
命令が利用される。図９の例では、「SetValue(“名
前”,”山田太郎”)」となる。データを取得する場合
は、「GetValue(key列指定)」となり、図９の例では、
「GetValue(“名前”)」で取得する。

【０１００】この例では、共通データ構造１０で扱って
いるデータはテキストであるが、テキストに限定される
ものではなく、画像、音声等のマルチメディアデータで
あってもよい。

【０１０１】図１０は、サーバアプリケーション１３の
処理の流れを例示する図である。ただし、このサーバア
プリケーション１３は、サービスに応じ自由に開発され
る部分であり、全てのサーバアプリケーションがこの処
理の流れにしたがう必要はない。このサーバアプリケー
ション１３は、クライアント種別が異なっていても共同
利用される。

【０１０２】データ取得ステップ１３１では、データ変
換部９から処理が移されると（１３ａ）、サービスに必
要なデータを共通ＡＰＩ１１を通じて共通データ構造１
０から取得し（１３ｂ）、サービス処理ステップ１３２
に処理を移す（１３ｃ）。

【０１０３】サービス処理ステップ１３２では、サービ
スに必要な処理を行う。場合によっては、データベース
１２へのアクセスが必要な場合もある（１３ｄ）。必要
な処理を行ったら、クライアント２に送信するデータを
格納するため、データ格納ステップ１３３に処理を移す
（１３ｅ）。

【０１０４】データ格納ステップ１３３では、クライア
ント２に送信したいデータを、共通ＡＰＩ１１を通じて
共通データ構造１０に格納する（１３ｆ）。その後、デ
ータ変換部９に処理を移す（１３ｇ）。

【０１０５】例えば、商品の在庫数を取得するサービス
の場合、データ取得ステップ１３１で共通データ構造１
０から商品名を取得し（１３ｂ）、サービス処理ステッ
プ１３２でデータベース１２より該当する商品の在庫数
を取得する（１３ｄ）。そして、データ格納ステップ１
３３で共通データ構造１０に商品の在庫数を格納する
（１３ｆ）。

【０１０６】以上のような本実施の形態に係る計算機シ
ステム１においては、多種多様のクライアントからサー
バに対してサービスが要求される場合であっても、同一
内容のサービスを提供するためのサーバアプリケーショ
ンは一つでよい。すなわち、クライアントアプリケーシ
ョンで扱われているデータ形式が異なる場合でも、サー
ビスを提供するサーバアプリケーションを一つにまとめ
ることができる。

【０１０７】したがって、サーバアプリケーションの開
発効率を向上させることができる。また、このサービス
の内容を変更する場合であっても、このサービスを提供
するサーバアプリケーションは一つであるため変更作業
が容易であり、サーバアプリケーションの保守・運用効
率も向上させることができる。

【０１０８】なお、本実施の形態においては、クライア
ント送受信部６の送信ステップ６３においてデータにク
ライアント種別情報が付加されているが、クライアント
種別情報はクライアント２のどの段階で付加されてもよ
い。例えば、クライアント送受信部６の送信データ作成
ステップ６１でデータにクライアント種別情報が付加さ
れてもよい。また、クライアントアプリケーション５が
データにクライアント種別情報を付加してもよい （第２の実施の形態）本実施の形態においては、ブラウ
ザからサーバにデータが送信される場合について説明す
る。すなわち、ここでは、ブラウザのようにそれ自体に
アプリケーション特定のデータ処理機能やＧＵＩを持っ
ていないいわゆるHTMLクライアントからサーバへ接続す
る場合を例に説明する。

【０１０９】図１１は、本実施の形態に係る計算機シス
テムの概略構成を例示するブロック図であり、上記第１
の実施の形態における図１の計算機システム１と同一の
部分については同一の符号を付してその説明を省略する
かあるいは簡単に説明し、ここでは異なる部分について
のみ詳しく説明する。

【０１１０】本実施の形態に係る計算機システム１４
は、上記第１の実施の形態に係る計算機システム１と比
較して以下のような点で異なる。

【０１１１】（ａ）画面構成情報１５をアクセスする画
面表示データ作成部１６がサーバ１７に追加されてい
る。

【０１１２】（ｂ）クライアント１８がブラウザ１９で
あり、クライアント１８の処理の流れが異なる。

【０１１３】（ｃ）サーバ１７のデータ変換部２０が異
なる（ブラウザ用のデータ変換部が起動される）。

【０１１４】上記第１の実施の形態ではクライアント２
がクライアントアプリケーション５とクライアント送受
信部６とから構成されているが、本実施の形態において
はクライアント１８がブラウザ１９である。

【０１１５】したがって、クライアント２とクライアン
ト１８とではクライアント種別が異なっているが、上記
（ａ），（ｃ）によりクライアント種別の違いを吸収す
ることができ、サーバアプリケーション１３を変更する
必要がない。

【０１１６】上記のような構成を持つ計算機システム１
４において、ユーザがブラウザ１９を通じてサーバ１７
のサービスを受ける場合の処理の流れを説明する。

【０１１７】ユーザは、ブラウザ１９に表示されたＧＵ
Ｉを操作して必要なデータをサーバ１７に送信し（ｂ
１）、サーバ１７から提供されるサービスを受ける。例
えば、上記第１の実施の形態の場合と同様に、ある商品
の在庫数をサーバ１７に問い合わせる場合などが考えら
れる。HTMLのFORM文の場合、ブラウザ１９に表示された
エリアに商品名を入力し、submitボタンを押すことによ
り、GET or POSTメソッドでサーバ１７に商品名が送ら
れる。

【０１１８】サーバ１７では、サーバ送受信部７がデー
タを受け（ｂ２），受信データをクライアント種別判別
部８に送る（ｂ３）。クライアント種別判別部８は、ク
ライアント１８のクライアント種別がブラウザであるこ
とを判別し、ブラウザ用のデータ変換部２０を起動する
（ｂ４）。データ変換部２０は、ブラウザ１９からGET
メソッドやPOSTメソッドで送られてきたデータを共通デ
ータ構造１０に格納し（ｂ５）、処理をサーバアプリケ
ーション１３に移す（ｂ６）。サーバアプリケーション
１３では、共通ＡＰＩ１１を通じて共通データ構造１０
からデータを取得し（ｂ７）、取得したデータに基づく
サービスに応じた処理を行う。必要があればデータベー
ス１２へアクセスする（ｂ８）。そして、サーバアプリ
ケーション１３は、サービス終了後にクライアント１８
に送信するデータを共通ＡＰＩ１１を通じて共通データ
構造１０へ格納し（ｂ９）、データ変換部２０へ処理を
移す（ｂ１０）。

【０１１９】データ変換部２０は、クライアント１８が
ブラウザ１９であるため、そのまま画面表示データ作成
部１６へ処理を移す（ｂ１１）。画面表示データ作成部
１６は、クライアント毎に用意されている画面構成情報
１５を参照しながら（ｂ１２）、共通データ構造１０か
らデータを取得し（ｂ１３）、この取得したデータに基
づいてブラウザ１９へ送信する画面表示データ（ＧＵＩ
データ）を作成する。そして、画面表示データ作成部１
６は、作成した画面表示データをサーバ送受信部７に送
り（ｂ１４）、サーバ送受信部７がこの画面表示データ
をブラウザ１８へと送信する（ｂ１５）。

【０１２０】サーバ１７からのデータをブラウザ１９が
受信すると（ｂ１６）、ブラウザ１９はそのデータをそ
のまま表示し、ユーザはブラウザ１９に表示されたＧＵ
Ｉを通じてサーバ１７のサービスを受ける。

【０１２１】このようにして、ブラウザ１９を通じてユ
ーザはサービスを受けるが、サービスを提供するサーバ
アプリケーション１３のインタフェースは、上記第１の
実施の形態におけるクライアント２の場合と同一であ
り、サーバアプリケーション１３を用いてクライアント
種別の異なるクライアントにサービスを提供することが
可能となる。

【０１２２】上記のような計算機システム１４の構成要
素で実行される処理を以下に詳細に説明する。

【０１２３】図１２は、ブラウザ１９の処理の流れを例
示する図である。ただし、この処理の流れは、代表的な
ブラウザの処理の流れを示したものであり、ブラウザの
種類によっては処理が異なる場合もある。

【０１２４】ユーザインタフェースステップ１９１で
は、ユーザからのアクションを受け付ける。アクション
待ちのときはループしている（１９ａ）。ユーザからア
クションが来た場合は、送受信ステップ１９２へ処理を
移す（１９ｂ）。また、ユーザインタフェースステップ
１９１は、サーバ１７からのデータがＧＵＩとともに送
受信ステップ１９２を経由して帰ってきた場合（１９
ｃ）、そのデータを解釈してユーザに情報を表示する。
基本的に、サーバ１７から送られてくる画面表示データ
は、HTMLなどで記述され、ＧＵＩとデータとを含む形で
送られてくる。ブラウザ１９自体がデータを解釈し、そ
れを表示するためのＧＵＩを用意することはない。

【０１２５】送受信ステップ１９２は、データをネット
ワーク４のプロトコルにしたがった形にエンコードし、
サーバ１７へ送信する（１９ｄ）。また、サーバ１７か
らデータを受信し（１９ｅ）、ユーザインタフェースス
テップ１９１に送る（１９ｃ）。

【０１２６】HTMLのFormでデータを送る場合、GETとPOS
Tの２つのメソッドが存在するが、いずれも「key=valu
e」の形でデータが送られる。このため、サーバ１７
は、通常、共通データ構造１０にデータを格納する場
合、Hash形式で格納する。HTMLのFormで表形式のデータ
を送りたい場合は、「key=value」のkeyの部分にある規
則をもたせてネーミングすることによって、サーバ１７
の共通データ構造１０に表形式データとして格納すると
いう方法がある。例えば図１３に示すように、inputタ
グのname部分を、「DATE.0001」「NAME.0002」などとす
ることにより、サーバ１７でDATE列の１行目のデータ、
NAME列の２行目のデータと扱うことができるようになっ
ている。

【０１２７】サーバ１７に処理が移った場合のサーバ送
受信部７とクライアント種別判別部８の処理は、上記第
１の実施の形態の場合と同様である。クライアント種別
判別部８が、クライアント種別をブラウザと判定し、ブ
ラウザ用のデータ変換部２０を起動する。

【０１２８】図１４は、ブラウザ用のデータ変換部２０
の処理の流れを例示する図である。

【０１２９】データ種類判別ステップ２０１では、クラ
イアント種別判別部８からの受信データを受け（２０
ａ）、データ形式を判定する。ブラウザ１９から送られ
てくるデータは、「key=value」のHash形式のデータで
ある。例えば、GETなどの場合URLの後部分が「?key=val
ue1&key2=value2・・・」などのようになっている。このた
め、通常、ブラウザ１９から送られてくるデータはHash
形式と判別される。しかし、図１３に示すように、key
にあたる部分を特定の規則にしたがった方法でネーミン
グすることにより、表形式のデータとして扱うことも可
能である。この例では、「CTX-TYPE=TABLE」というデー
タ種別判別のためのデータを入れ込んでいるためデータ
形式を表形式と判定できる。データ形式を判定した後、
データ格納ステップ２０２に移行する（２０ｂ）。

【０１３０】データ格納ステップ２０２では、データ種
類判別ステップ２０１から渡された受信データを共通デ
ータ構造１０へと変換・格納する。データ種類判別ステ
ップ２０１で判別したデータ種類に対応したデータを共
通データ構造１０へと格納する（２０ｃ）。例えば、デ
ータの種類を判別するためのデータが埋め込まれていな
かった場合は、Hash形式のデータとして格納される。図
１３のように表形式と判別した場合は、各データのkey
の部分を解析しデータを格納する。「NAME.0001=味噌」
の場合は、NAME列の１行目に「味噌」を格納し、「NUM.
0001=10」の場合は、NUM列の１行目に「10」を格納す
る。データ変換は、データが存在する限り継続される
（２０ｄ）。全てのデータを共通データ構造１０に格納
したら、サーバアプリケーション１３に処理を移す（２
０ｅ）。

【０１３１】画面表示データ作成部起動ステップ２０３
では、サーバアプリケーション１３から処理が移ると
（２０ｆ）、サーバアプリケーション１３に対応した画
面表示データ作成部１６を起動し、処理を画面表示デー
タ作成部１６へ移す（２０ｇ）。ここでは、送信データ
の作成などは行わず、画面表示データ作成部１６にまか
せる。

【０１３２】図１５は、画面表示データ作成部１６の処
理の流れを例示する図である。

【０１３３】画面表示データ作成部１６は、サーバアプ
リケーション１３毎に用意される。そして、画面構成情
報１５がクライアント毎に用意される。サーバアプリケ
ーション１３がユーザに送り返すデータ（情報／サービ
ス）は、サーバアプリケーション毎に決まっている。画
面表示データ作成部１６は、そのデータを、クライアン
ト毎にどのような形で提供するか、どのような画面構成
／ＧＵＩを用意するかなどを画面構成情報１５を参照し
て決定する。

【０１３４】ここでは、画面表示データ作成部１６と画
面構成情報１５とを分けているが、画面構成情報１５を
画面表示データ作成部１５に含めてもよい。この場合、
画面表示データ作成部１６は、１つのサーバアプリケー
ションに対し、クライアント種別分用意されることにな
る。

【０１３５】データ読み込みステップ１６１では、デー
タ変換部２０から処理を受け（１６ａ）、共通データ構
造１０からデータを取り出す（１６ｂ）。その後、画面
構成情報読み込みステップ１６２に処理を移す（１６
ｃ）。

【０１３６】画面構成情報読み込みステップ１６２で
は、クライアントに応じた画面構成情報１５を取得する
（１６ｄ）。画面構成情報１５には、共通データのデー
タをどのように配置したらよいか、どのようなＧＵＩを
用意するかが記されている。例えば、クライアントがブ
ラウザ１９の場合、データを６列で表示するが、クライ
アントが携帯電話等の画面のように制約が多い場合、デ
ータを２列で表示するかあるいは何ページかに分割す
る。画面構成情報１５を取得したら画面表示データ作成
ステップ１６３に処理を移す（１６ｅ）。

【０１３７】画面表示データ作成ステップ１６３では、
データ読み込みステップ１６１で取得したデータと、画
面構成情報読み込みステップ１６２で取得した画面構成
情報１５とを参照し、クライアント１８に送信する画面
表示データを作成する。そして、作成した画面表示デー
タを送信データとしてサーバ送受信部７へ送る（１６
ｆ）。

【０１３８】以上のような本実施の形態に係る計算機シ
ステム１４においては、クライアントが画面を表示する
ためのデータを必要とするブラウザ１９や携帯端末など
によって構成されていても、同一内容のサービスを提供
するサーバアプリケーション１３は一つでよい。したが
って、同一内容のサービスを提供するサーバアプリケー
ションを一つにまとめることができ、サーバアプリケー
ションの開発効率を向上させることができる。

【０１３９】また、このサービスの内容を変更する場合
であっても、このサービスを提供するサーバアプリケー
ションは一つであるため、サーバアプリケーションの保
守・運用効率を向上させることができる。

【０１４０】（第３の実施の形態）本実施の形態におい
ては、複数のクライアントのクライアント種別が多種多
様な場合について説明する。

【０１４１】図１６は、本実施の形態に係る計算機シス
テムの概略構成を例示するブロック図であり、上記図１
及び図１１と同一の部分については同一の符号を付して
その説明を省略するかあるいは簡単に説明し、ここでは
異なる部分について詳しく説明する。

【０１４２】計算機システム２１には、言語Ａによるク
ライアント２がネットワーク４に接続されていたが、こ
れに加えてＷｅｂブラウザクライアント１８、携帯端末
用ブラウザ２２を含む携帯端末２３がネットワーク４に
接続され、各クライアント２、１８、２３からサーバ１
７のサービスにアクセス可能となったとする。

【０１４３】この場合、アクセスするクライアントのク
ライアント種別が増えたにもかかわらず、同一内容のサ
ービスを提供するサーバアプリケーションは一つでよ
い。

【０１４４】サーバ１７の通信ミドルウェア２４では、
クライアント種別毎にデータ変換部９、２０、２５を用
意すること、クライアント２、１８、２３とサーバアプ
リケーション１３間のデータ交換を共通データ構造１０
とそれにアクセスする共通ＡＰＩ１１を通じて行うこと
とすることにより、クライアント種別の違いを吸収して
いる。

【０１４５】これにより、サーバアプリケーション１３
をクライアント種別毎に設ける必要はなく、各クライア
ント２、１８、２３に対応するように修正する必要もな
い。

【０１４６】また、ブラウザ１９や携帯端末用ブラウザ
２２は、一般的にデータ処理機能やＧＵＩを提供する機
能を持っておらず、サーバ１７から送られてきた情報を
そのまま画面に表示する。したがって、ブラウザ１９や
携帯端末用ブラウザ２２に対してはサーバ１７から画面
の情報を含んだサービスを提供する必要がある。

【０１４７】通信ミドルウェア２４では、画面表示デー
タ作成部１６と画面構成情報１５を用意することによ
り、これを可能としている。これにより、データ処理機
能やＧＵＩを提供する機能を持っていないクライアント
１８、２３に対してもサービスを提供することができ
る。

【０１４８】以下に、上記本実施の形態に係る計算機シ
ステム２１の動作について説明する。

【０１４９】ユーザは、この計算機システム２１の各ク
ライアントを操作して、サーバ１７のサービスを受ける
ことができる。ユーザが受けられるサービスの内容は、
クライアントのクライアント種別に関係なく同一であ
る。しかし、提供されるサービスあるいはデータの形態
や見た目や量などは、クライアント毎に異なる可能性が
ある。

【０１５０】ユーザは言語Ａによるクライアント２を操
作して、サーバ１７のサービスを受けることができる。
例えば、自社で扱っているＰＣの卸値が知りたいとす
る。ユーザは、言語Ａによるクライアント２のＧＵＩを
操作して販売管理システムを選択し、自社で扱っている
ＰＣの情報を得るため、サーバ１７にアクセスする。ユ
ーザの操作を受け付けるのが、言語Ａによるクライアン
トアプリケーション５である。クライアントアプリケー
ション５からＰＣの卸値を得るために必要なデータがク
ライアント送受信部６へ送られ（２１ａ）、クライアン
ト送受信部６が送信データを作成し、ネットワーク４を
通じてサーバのサービスへとアクセスする（２１ｂ）。

【０１５１】ユーザは、同じくブラウザ１９を操作して
サーバ１７のサービスを受けることも可能である。例え
ば、ユーザはブラウザ１９やブラウザ１９に表示されて
いるＧＵＩを操作してＰＣの卸値を要求する。この場
合、ユーザの操作を受け付けたブラウザ１９が送信デー
タを作成し、サーバ１７へとアクセスする（２１ｃ）。

【０１５２】ユーザは、携帯端末２３を操作して同様の
サービスを受けることも可能である。例えば、携帯端末
２３に表示されている画面にしたがってＰＣの卸値を要
求する場合、ユーザの操作を受け付けた携帯端末用ブラ
ウザ２２が送信データを作成し、サーバ１７へとアクセ
スする（２１ｄ）。

【０１５３】サーバ送受信部７はクライアントからのデ
ータを受け（２１ｅ）、受信データをクライアント種別
判別部８へと送る（２１ｅ）。クライアント種別判別部
８では、受信データのヘッダ部分や特定のタグの情報を
見てクライアント種別を判別し、それぞれクライアント
種別に対応したデータ変換部を起動する（２１ｆ）。ク
ライアント種別毎に用意されているデータ変換部９、２
０、２５における処理の内容はほぼ同じであり、受信デ
ータを解析し、共通データ構造１０に格納する（２１
ｇ）。データの格納が終わったら、サーバアプリケーシ
ョン１３へ処理を移す（２１ｈ）。サーバアプリケーシ
ョン１３では、共通ＡＰＩ１１を通じて共通データ構造
１０にアクセスし、処理に必要なデータを獲得する（２
１ｉ）。そして、必要に応じデータベース１２へアクセ
スする（２１ｊ）。そして、処理の結果、クライアント
に返す情報サービスを共通ＡＰＩ１１を通じて共通デー
タ構造１０へと格納し（２１ｋ）、データ変換部７へと
処理を戻す（２１ｌ）。例えば、ＰＣの卸値を得る場合
では、共通データ構造１０からＰＣの機種名等を獲得し
（２１ｉ）、データベース１２へアクセスしてデータベ
ース１２より各ＰＣの卸値を取得し（２１ｊ）、共通デ
ータ構造１０へと格納した後（２１ｋ）、データ変換部
に処理を移動する（２１ｌ）。

【０１５４】サーバアプリケーション１３での処理が終
了した後のデータ変換部９、２０、２５では、それぞれ
クライアント２、１８、２３へ送信するデータが作成さ
れる。言語Ａ対応のデータ変換部９は、共通データ構造
１０より送信するデータを獲得し（２１ｍ）、送信デー
タを作成後、サーバ送受信部７へと送信データを送る
（２１ｎ）。しかし、ブラウザ用のデータ変換部２０や
携帯端末用のデータ変換部２５は、クライアントに提供
する情報に加えて画面を構成する情報なども送らなけれ
ばならない。このため、これらのデータ変換部２０、２
５は、画面表示データ作成部１６へと処理を移す（２１
ｏ）。

【０１５５】画面表示データ作成部１６では、サーバア
プリケーション毎、クライアント種別毎に、クライアン
ト側で画面を構成する情報を含む画面表示データを作成
する。具体的には、画面表示データ作成部１６は、画面
構成情報１５へとアクセスし、サーバ１７が提供するサ
ービスとクライアント種別に対応した画面構成情報１５
を持ってくる（２１ｐ）。また、画面表示データ作成部
１６は、クライアントへ送信するサービス結果／データ
を共通データ構造１０より獲得する（２１ｑ）。画面構
成情報１５を参照しながら、適切な位置にサービス結果
であるデータを配置し、ボタンや入力エリアなどのＧＵ
Ｉ情報も付加する。例えば、通常ＰＣなどで使われてい
るブラウザ１９は、表示エリアを大きく取れる（調整す
ることができる）。このため、各ＰＣの卸値を１ページ
に全て表示するような画面構成にすることができる。ま
た、横スクロールも可能なため、データを横長の方向に
並べて表示するような画面構成をとることも可能であ
る。一方、携帯端末用ブラウザ２２の場合、画面の表示
エリアが限定されているのが普通である。また、横スク
ロールができない場合も多い。このため、データを縦に
並べて表示するように画面を構成してもよく、あるいは
一定のデータ量でページを区切り、複数のページに分け
て表示する画面を構成してもよい。こうして完成した画
面表示データをサーバ送受信部７へと送る（２１ｒ）。
サーバ送受信部７は、言語Ａ用データ変換部９や、画面
表示データ作成部１６から送られてきた画面表示データ
をクライアントへと送り出す（２１ｓ）。

【０１５６】クライアントでは、サーバ１７より返って
きたサービス内容（受信データ）を処理し、ユーザへと
提供する。

【０１５７】言語Ａによるクライアント２の場合は、ク
ライアント送受信部６がサーバ１７からのデータを受信
し（２１ｔ）、受信したデータをクライアントアプリケ
ーション５が利用できる形に変換した後、クライアント
アプリケーション５へと送信する（２１ｕ）。クライア
ントアプリケーション５は、そのデータを、ＧＵＩの適
切な位置に表示、ユーザはその情報を見てサービスを受
ける。

【０１５８】例えば、サーバ１７より卸値データを受け
付け、それを言語Ａで利用できるデータ形式に変換し、
クライアントアプリケーション５に提供するのが、クラ
イアント送受信部６である。また、受け取ったデータを
画面に配置し、ＧＵＩを表示するのがクライアントアプ
リケーション５である。この言語Ａによるクライアント
２の場合、受け取ったデータをどのように表示する／提
供するかは、クライアント２で決定する。受け取った卸
値を表形式で表示してもよいし、タグを用いて１画面毎
に表示してもよい。

【０１５９】一方、Ｗｅｂブラウザクライアント１８や
携帯端末２３の場合は、サーバ１７からデータを受信し
た後は（２１ｖ、２１ｗ）、そのデータをそのまま表示
することになる。ユーザは、表示された内容を見てサー
ビスを受ける。

【０１６０】本実施の形態に係る計算機システム２１の
各構成要素の処理の流れは、上記第１及び第２の実施の
形態の場合と同様である。また、ブラウザ１９と携帯端
末用ブラウザ２２、及びそれぞれのデータ変換部２０、
２５の処理の流れは同様である。上記第１の実施の形態
と上記第２の実施の形態との構成を組み合わせたものが
本実施の形態であり、このように容易に組み合わせるこ
とが可能であるため、計算機システム２１に他のクライ
アントが追加されたような場合に容易に対応できる。

【０１６１】図１７は、新規のクライアント種別に応じ
た処理を可能にするために、種別判別追加部２６と、デ
ータ変換追加部２７と、画面構成情報追加部２８とを通
信ミドルウェア２４に付加した場合を例示するブロック
図である。

【０１６２】種別判別追加部２６は、新規のクライアン
ト種別を判別するための機能をクライアント種別判別部
８に追加する。

【０１６３】データ変換追加部２７は、新規のクライア
ント種別で採用されている形式の受信データの内容を共
通データ構造１０にしたがって記憶し、共通データ構造
１０にしたがって記憶されているデータを新規のクライ
アント種別で採用されている形式に変換するデータ変換
部２９を追加する画面構成情報追加部２８は、新規のク
ライアント種別に応じた画面構成情報を追加する。

【０１６４】なお、この図１７では省略しているが、新
規のサーバアプリケーションに対応する画面表示データ
作成部を追加する部分を備え、画面構成情報追加部２８
はこの新規の画面表示データ作成部についての画面構成
情報を追加する機能も備えるとしてもよい。

【０１６５】なお、上記各実施の形態に係る計算機シス
テム１、１４、２１においては、同様の作用・機能を実
現可能であれば各構成要素の配置を変更させてもよく、
また各構成要素を自由に組み合わせてもよい。

【０１６６】また、上記各実施の形態に係る計算機シス
テム１、１４、２１の各機能、各要素は、コンピュータ
に実行させることのできるプログラムとして、例えば磁
気ディスク（フロッピー（登録商標）ディスク、ハード
ディスク等）、光ディスク（ＣＤ−ＲＯＭ、ＤＶＤ
等）、半導体メモリなどの記録媒体に書き込んで適用し
てもよく、通信媒体により伝送して、計算機、計算機シ
ステムに適用することも可能である。

【０１６７】上記各機能を実現するコンピュータは、記
録媒体に記録されたプログラムを読み込み、プログラム
によって動作が制御されることにより、上述した処理を
実行する。

【０１６８】

【発明の効果】以上詳記したように本発明においては、
クライアントからのデータを共通のデータ構造に変換し
て保存し、この共通のデータ構造のデータをサーバアプ
リケーションがアクセスすることになる。

【０１６９】したがって、クライアント種別に応じて同
様の処理を実行するサーバアプリケーションを用意する
必要がなく、サーバアプリケーションを統合できる。

【０１７０】また、共通のデータ構造のデータとクライ
アント種別に応じた画面構成情報とに基づいて、そのク
ライアント種別に応じた画面表示データが作成される。

【０１７１】したがって、クライアント種別が画面を構
成するための情報を必要とするものであり、また各クラ
イアント種別でその画面の構成を切り替える場合であっ
ても、クライアント種別に応じてサーバアプリケーショ
ンを用意する必要がなく、サーバアプリケーションを統
合できる。

【０１７２】これにより、サーバアプリケーションの開
発を効率化でき、サーバアプリケーションの保守・運用
も効率化できる。

【図面の簡単な説明】

【図１】本発明の第１の実施の形態に係る計算機システ
ムの概略構成を例示するブロック図。

【図２】同実施の形態に係る計算機システムにおけるク
ライアントアプリケーションの処理の流れを例示する
図。

【図３】同実施の形態に係る計算機システムにおけるク
ライアント送受信部の処理の流れを例示する図。

【図４】同実施の形態に係る計算機システムにおけるク
ライアント送受信部のデータ変換例を示す図。

【図５】同実施の形態に係る計算機システムにおけるサ
ーバ送受信部の処理の流れを例示する図。

【図６】同実施の形態に係る計算機システムにおけるク
ライアント種別判別部の処理の流れを例示する図。

【図７】同実施の形態に係る計算機システムにおけるデ
ータ変換部の処理の流れを例示する図。

【図８】同実施の形態に係る計算機システムにおけるデ
ータ変換部のデータ変換例を示す図。

【図９】同実施の形態に係る計算機システムにおける共
通データ構造を例示する図。

【図１０】同実施の形態に係る計算機システムにおける
サーバアプリケーションの処理の流れを例示する図。

【図１１】本発明の第２の実施の形態に係る計算機シス
テムの概略構成を例示するブロック図。

【図１２】同実施の形態に係る計算機システムにおける
ブラウザの処理の流れを例示する図。

【図１３】同実施の形態に係る計算機システムにおける
ブラウザのデータ変換例を示す図。

【図１４】同実施の形態に係る計算機システムにおける
データ変換部の処理の流れを例示する図。

【図１５】同実施の形態に係る計算機システムにおける
画面表示データ作成部の処理の流れを例示する図。

【図１６】本発明の第３の実施の形態に係る計算機シス
テムの概略構成を例示するブロック図。

【図１７】同実施の形態に係る計算機システムにおける
通信ミドルウェアの概略構成を例示するブロック図。

【符号の説明】

１、１４、２１…計算機システム ２、１８、２３…クライアント ３、１７…サーバ ４…ネットワーク ５…クライアントアプリケーション ６…クライアント送受信部 ７…サーバ送受信部 ８…クライアント種別判別部 ９、２０、２５、２９…データ変換部 １０…共通データ構造 １１…共通ＡＰＩ １２…データベース １３…サーバアプリケーション １５…画面構成情報 １６…画面表示データ作成部 ２２…携帯端末用ブラウザ ２４…通信ミドルウェア ２６…種別判別追加部 ２７…データ変換追加部 ２８…画面構成情報追加部

───────────────────────────────────────────────────── フロントページの続き (72)発明者 小山 徳章 東京都港区芝浦一丁目１番１号 株式会社 東芝本社事務所内 (72)発明者 山口 文雄 東京都港区芝浦一丁目１番１号 株式会社 東芝本社事務所内 Ｆターム(参考） 5B075 NR02 PQ02 5B082 GA02

Claims (10)

【特許請求の範囲】
1. 【請求項１】 コンピュータに、 クライアントの種別に応じた形式でこのクライアントか
   ら受信した受信データに含まれているクライアント種別
   情報に基づいて、クライアント種別を判別するクライア
   ント種別判別機能と、 前記クライアント種別判別機能によって判別されたクラ
   イアント種別に応じた形式の受信データの内容を予め定
   められているデータ構造にしたがって記憶するデータ変
   換機能とを実現させるためのプログラムを記録したコン
   ピュータ読み取り可能な記録媒体。
2. 【請求項２】 請求項１記載のプログラムを記録したコ
   ンピュータ読み取り可能な記録媒体において、 コンピュータに、 新規のクライアント種別を判別するための機能を前記ク
   ライアント種別判別機能に追加する種別判別追加機能
   と、 前記新規のクライアント種別に応じた形式の受信データ
   の内容を前記データ構造にしたがって記憶するデータ変
   換機能を追加するデータ変換追加機能とを実現させるた
   めのプログラムを記録したコンピュータ読み取り可能な
   記録媒体。
3. 【請求項３】 請求項１記載のプログラムを記録したコ
   ンピュータ読み取り可能な記録媒体において、 前記データ変換機能は、前記クライアント種別判別機能
   によって判別されたクライアント種別に基づいて、前記
   データ構造にしたがって記憶されているデータを前記ク
   ライアント種別に応じた形式に変換して前記クライアン
   トへの送信データとすることを特徴とするプログラムを
   記録したコンピュータ読み取り可能な記録媒体。
4. 【請求項４】 請求項３記載のプログラムを記録したコ
   ンピュータ読み取り可能な記録媒体において、 コンピュータに、 新規のクライアント種別を判別するための機能を前記ク
   ライアント種別判別機能に追加する種別判別追加機能
   と、 前記新規のクライアント種別に応じた形式の受信データ
   の内容を前記データ構造にしたがって記憶し、前記デー
   タ構造にしたがって記憶されているデータを前記新規の
   クライアント種別に応じた形式に変換して前記クライア
   ントへの送信データとするデータ変換機能を追加するデ
   ータ変換追加機能とを実現させるためのプログラムを記
   録したコンピュータ読み取り可能な記録媒体。
5. 【請求項５】 請求項３又は請求項４記載のプログラム
   を記録したコンピュータ読み取り可能な記録媒体におい
   て、 コンピュータに、 前記クライアント種別判別機能によって判別されたクラ
   イアント種別が画面を表示するための情報を必要とする
   場合に、このクライアント種別に応じた画面構成情報と
   前記データ構造にしたがって記憶されているデータとに
   基づいて画面表示データを作成し、この画面表示データ
   を前記クライアントへの送信データとする画面表示デー
   タ作成機能を実現させるためのプログラムを記憶したコ
   ンピュータ読み取り可能な記録媒体。
6. 【請求項６】 請求項５記載のプログラムを記録したコ
   ンピュータ読み取り可能な記録媒体において、 コンピュータに、 新規のクライアント種別に応じた画面構成情報を追加す
   る画面構成情報追加機能を実現させるためのプログラム
   を記録したコンピュータ読み取り可能な記録媒体。
7. 【請求項７】 請求項１乃至請求項６のいずれか１項に
   記載したプログラムを記録したコンピュータ読み取り可
   能な記録媒体において、 コンピュータに、 クライアントから送信されるデータに、クライアント種
   別情報を付加するクライアント種別付加機能を実現させ
   るためのプログラムを記録したコンピュータ読み取り可
   能な記録媒体。
8. 【請求項８】 クライアントとサーバとの間でデータを
   送受信する計算機システムにおいて、 前記クライアントの種別に応じた形式で前記クライアン
   トから受信した受信データに含まれているクライアント
   種別情報に基づいてクライアント種別を判別するクライ
   アント種別判別手段と、 前記クライアント種別判別手段によって判別されたクラ
   イアント種別に応じた形式の受信データの内容を予め定
   められているデータ構造にしたがって記憶するデータ変
   換手段と、 前記データ構造にしたがって記憶されているデータをア
   クセスしつつ、処理を実行するサーバアプリケーション
   とを具備したことを特徴とする計算機システム。
9. 【請求項９】 請求項８記載の計算機システムにおい
   て、 新規のクライアント種別を判別するための機能を前記ク
   ライアント種別判別手段に追加する種別判別追加手段
   と、 前記新規のクライアント種別に応じた形式の受信データ
   の内容を前記データ構造にしたがって記憶するデータ変
   換手段を追加するデータ変換追加手段とを付加したこと
   を特徴とする計算機システム。
10. 【請求項１０】 請求項８記載の計算機システムにおい
    て、 前記データ変換手段は、前記クライアント種別判別手段
    によって判別されたクライアント種別に基づいて、前記
    データ構造にしたがって記憶されているデータを前記ク
    ライアント種別に応じた形式に変換して前記クライアン
    トへの送信データとすることを特徴とする計算機システ
    ム。