JPH10232899A - サービス連携方法とサービス連携装置およびそれらの実施に利用できるパーツ生成管理方法 - Google Patents

Abstract

(57)【要約】 【課題】 ＷＷＷなどでサービスを受けるとき、サーバ
間に連携がないため、複数のサービスを利用する定型業
務などの実行が困難であった。 【解決手段】 サービス連携装置２は、クライアント３
と各種基本サービスを提供するサーバ１を中継する。仮
想サービスオブジェクト定義ファイル（ＶＳＯＤＦ）１
４には、ユーザの利用する基本サービスオブジェクト
（ＰＳＯ）１２の利用形態等を定義しておく。ＰＳＯ１
２は基本サービスオブジェクト定義ファイル（ＰＳＯＤ
Ｆ）１６に従って生成される。仮想サービスオブジェク
ト（ＶＳＯ）１０はＶＳＯＤＦ１４に従い、あたかも単
一の基本サービスのごとくに生成される。定型業務を起
動すると、ＶＳＯ１０がＰＳＯ１２を適宜利用してサー
ビスを提供する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】この発明は、サービス連携方
法、サービス連携装置およびパーツ生成管理方法に関す
る。この発明は特に、ネットワーク等を介してサーバか
らクライアントにサービスを提供する際、複数の基本サ
ービスを統合して仮想サービスを提供する方法と装置、
およびそれらに利用可能なパーツを生成管理する方法に
関する。

【０００２】

【従来の技術】周知のごとく、インターネットではＷＷ
Ｗ（World Wide Web）を中心に各種サービスの提供がな
されている。ＷＷＷを利用する場合、ビュアまたはブラ
ウザと呼ばれる専用端末があればサービス毎に専用のア
プリケーションを準備する必要がなく、ユーザの負担が
大幅に軽減される。しかしながら、印刷、ファイルコピ
ー、データベース検索など個別のサービス（以下「基本
サービス」という）は、通常それぞれが個別のサーバか
ら提供されるため、基本サービス間でデータのやりとり
をする仕組みがない。したがって、端末側で必要なデー
タ加工等をしなければならず、定型業務であっても、多
数のサービスを利用するような処理は困難である。とく
に最近では、ＰＤＡ（Personal Digital Assistance）
などの携帯端末が普及しており、そうした端末の限られ
た表示スペースとキー操作性を考えたとき、サービスの
連携に対する要望は極めて強い。

【０００３】この要望に応えるべく、特開平７−１６０
８５１号公報には専用のセンタサーバをもつシステムが
開示されている。このシステムでは、複数サービスの提
供を受ける際、データの処理シーケンスを記述したプロ
セス・スクリプトをセンタサーバに送る。センタサーバ
はプロセス・スクリプトを順次読み込んで解釈し、一連
の処理を実行する。

【０００４】

【発明が解決しようとする課題】このようにセンタサー
バを設けることにより、ユーザは複数のサービスの実行
結果を得ることができる。しかしこのシステムでは、セ
ンタサーバがプロセス・スクリプトをバッチ処理してい
くに過ぎず、一連の処理がユーザとの対話に基づいてな
されるわけではない。すなわち、いったん処理が開始す
れば最終結果が出されるまでユーザはシステムに関与せ
ず、処理の各場面においてユーザが適宜検索条件を入力
するなどの操作が困難であり、システムの融通性で改善
の余地が認められる。問題の本質は、このシステムが複
数サービスの自動実行機能を提供しても、それら複数サ
ービスを統合して、あたかもひとつの基本サービスであ
るかのように提供する形態をとらない点にある。

【０００５】本発明はこの課題に鑑みてなされたもので
あり、その目的は、複数の基本サービスを有機的かつ円
滑に統合して提供するサービス連携方法および装置の提
供にある。また、本発明の他の目的は、基本サービスの
提供順序や画面上でのレイアウトの変更を容易とし、柔
軟なサービスの提供を可能とするサービス連携装置の提
供にある。本発明の別の目的は、サービスの結果をパー
ツ化してサービス連携の際に利用可能とするためのパー
ツ生成管理方法を提供することにある。

【０００６】

【課題を解決するための手段】本発明のサービス連携方
法は、複数の基本サービスの統合形態を規定することに
よってそれら複数の基本サービスの連携に係る仮想サー
ビスを予め定義しておく。サービスを提供するとき、前
記定義に従い、まず基本サービスオブジェクトを適宜利
用する内部形式で仮想サービスオブジェクトを生成す
る。つづいて、生成された仮想サービスオブジェクトの
実行という形で単一の基本サービスに準じた操作形式に
て仮想サービスを提供する。

【０００７】ここで「内部形式で」とは、実際のプログ
ラムでは、の意味である。つまり、外見上はあたかも仮
想サービスオブジェクト自体がひとつの独立した基本サ
ービスとして動作しているように見えても、実際には適
宜複数の基本サービスオブジェクトが起動され、利用さ
れていることを意味する。「単一の基本サービスに準じ
た操作形式」とは、ユーザに対して適度にユーザインタ
フェイス機能等を提供することによって対話的な処理を
可能とする形式をいう。つまり、複数の基本サービスが
単にバッチ処理によって機械的、自動的に処理される場
合と異なり、ユーザから見れば仮想サービスが基本サー
ビスに準じた操作環境を実現することを意味している。

【０００８】この方法によれば、例えばユーザが求める
定型業務を予め仮想オブジェクトとして定義しておくこ
とにより、定型業務で利用する複数の基本サービスが仮
想サービスとして統合され、提供される。このため、ユ
ーザにその定型業務専用のプログラムが与えられたかの
ように、非常に使い勝手のよいサービスが実現する。本
発明のサービス連携方法では、仮想サービスの提供をク
ライアントとサーバの間に設けた中継装置に担当せし
め、クライアントは実際に仮想サービスを構成する各基
本サービスを実行するサーバを目的とする代わりに、こ
の中継装置を目的として仮想サービスの要求を出しても
よい。「目的」とは、ユーザによる明示的な指定の対
象、の意味であり、アドレスによる指定などをいう。こ
の構成の場合、ユーザが個々のサーバを意識してサービ
スを要求する必要がなく、ユーザからは中継装置が仮想
サービスを提供する単一のサーバに見えるため、あたか
もひとつの基本サービスを受けているように見える。

【０００９】一方、本発明のサービス連携装置は、サー
バとの間で必要な情報の授受を行うサーバ連絡部（２
４）と、クライアントとの間で必要な情報の授受を行う
クライアント連絡部（２０）と、各種サービスに関する
オブジェクトを生成して管理するオブジェクト管理部
（２６）とを含む。また、オブジェクト管理部は、基本
サービスオブジェクトに関する定義に従って基本サービ
スオブジェクトを生成する基本サービスオブジェクト生
成部（４４）と、生成された複数の基本サービスオブジ
ェクトの統合に係る仮想サービスオブジェクトに関する
定義に従って仮想サービスオブジェクトを生成する仮想
サービスオブジェクト生成部（４０）とを含む。この構
成において、クライアントからクライアント連絡部に対
して仮想サービスの提供が要求されたとき、オブジェク
ト管理部の管理する仮想サービスオブジェクトによって
サーバ連絡部を介してサーバに適宜基本サービスを実行
させ、その実行結果をもとにクライアントに仮想サービ
スを提供する。

【００１０】この構成によれば、サーバ連絡部とクライ
アント連絡部があるため、サービス連携装置がサーバか
らはクライアントに見え、クライアントからはサーバに
見える。例えば代理サーバにサービス連携装置としての
機能をもたせることでこの構成が可能であり、システム
構築が容易になる。

【００１１】本発明のサービス連携装置のある態様で
は、前記サーバ連絡部は、基本サービスの実行の結果得
られる情報を分割してパーツを生成するパーツ生成部
（５４）と、生成されたパーツを保持するパーツデータ
ベース（５８）とを含み、仮想サービスの提供に当た
り、その仮想サービスを構成する複数の基本サービスの
結果得られる情報がパーツの組合せとしてクライアント
に提供される。ここで「基本サービスの結果得られる情
報」の例に、サーバからインターネットを介して送られ
てくるＨＴＭＬ（Hyper Text Markup Language）によっ
て記述されたテキスト（以下、ＨＴＭＬ文書という）な
どがある。

【００１２】このサーバ連絡部はさらに、仮想サービス
の提供に当たり、その仮想サービスを構成する複数の基
本サービスに関するパーツをテンプレートなどで決まる
所定枠にはめ込むパーツ合成部（６０）を含んでもよ
い。その場合、所定枠に必要なパーツがはめ込まれた状
態で仮想サービスの結果がクライアントに提供される。
この装置によれば、情報がパーツ化されるため、パーツ
を効果的に組み合わせて効率的に表示することができ
る。

【００１３】他方、本発明のパーツ生成管理方法は、基
本サービスの実行の結果得られる情報のうち、クライア
ント側端末の画面に表示されたとき機能的にひとつのユ
ーザインタフェイスを形成する部分を識別してこの部分
を単位に前記情報をパーツ化して保存する。この方法に
よれば、予めパーツを準備することにより、例えば複数
の基本サービスの実行結果をクライアントに返すとき、
各基本サービスに関連する情報をパーツの形で提供する
ことができる。特に、前記情報のうち重要性の高い部分
などをパーツ化してそれ以外の部分のデータを削減して
おけば、例えばＰＤＡのように限られた画面に多数の基
本サービスの結果を同時に表示することができ、基本サ
ービスの連携に好都合である。

【００１４】また、本発明のサービス連携装置は、複数
の基本サービスオブジェクトの統合に係る仮想サービス
オブジェクトに関する定義を記憶する仮想サービスオブ
ジェクト定義記憶部を含む。この仮想サービスオブジェ
クト定義記憶部には、仮想サービス中での基本サービス
の遷移の順序を定義したシナリオ情報が記憶される。つ
まり、基本サービスの遷移の順序はシナリオ情報に一括
管理され、このシナリオ情報を変更するだけで、サーバ
に実行させる基本サービスの順序をを変更することがで
きる。また、本発明のサービス連携装置はシナリオ実行
部を備えることによって、複数クライアントに対しそれ
ぞれ現在どの基本サービスを提供しているかを把握し、
複数クライアントに対し並行して仮想サービスを提供す
ることができる。

【００１５】一方、本発明のもう一つのサービス連携装
置は、仮想サービスオブジェクト定義記憶部に、仮想サ
ービスオブジェクトを構成する基本サブパーツを定義す
るパーツ情報と、仮想サービスオブジェクトを構成する
基本サブパーツの画面上でのレイアウトを定義するテン
プレート情報とを有する。基本サブパーツは、情報端末
の画面に表示されたとき機能的にひとつのユーザインタ
フェイスを形成する部分に対応する基本パーツをさらに
細分化した部品である。上記パーツ情報とテンプレート
情報とを別個に設けることにより、パーツ情報には仮想
サービスオブジェクトを構成する基本パーツの種類に関
する情報が管理される。それら基本パーツに含まれる基
本サブパーツが画面上でどのような配置とされるかにつ
いての情報はパーツ情報とは別個に、テンプレート情報
にて集中的に管理される。これにより、例えば画面の形
態が異なる情報端末に対しては、テンプレート情報のみ
変更することにより見やすい画面表示を得ることがで
き、このパーツ情報、その他の情報についての変更を不
要とすることができる。

【００１６】

【発明の実施の形態】

［実施の形態１］本発明の好適な実施形態を適宜図面を
参照しながら説明する。

【００１７】図１は実施形態に係るサービス連携装置を
サーバクライアントシステムに用いる場合のシステム構
成図である。同図のごとくこのサービス連携装置２は、
それぞれが個別に基本サービスを提供するサーバ１と、
ＰＤＡやＰＣなどユーザ側の端末に搭載されたクライア
ント３を中継する。その意味でサービス連携装置２は代
理サーバと同じ位置に置かれるが、本システムの場合、
基本サービスの統合に係る仮想サービスをサービス連携
装置２が主体的に行う点で代理サーバと異なる。このた
め、本システムでは仮想サービスを要求するに当たり、
クライアント３から各サーバ１ではなく、サービス連携
装置２を目的として要求を出す。具体的には、サーバ１
のＵＲＬ（Uniform Resource Locator）ではなく、サー
ビス連携装置２のＵＲＬが指定される。したがって、ユ
ーザからはサービス連携装置２がひとつのサーバに見え
る。

【００１８】図２は、あるクライアント３と複数のサー
バ１の関係をサービス連携装置２の内部構成との関係に
おいて示す図である。同図のごとく、サービス連携装置
２内部には、３つの基本サービスを実行するオブジェク
ト（基本サービスオブジェクト：Primitive Service Ob
ject、図中「ＰＳＯ」と略記）１２と、それら３つの基
本サービスオブジェクトを統合、連携して実現する仮想
的なサービスのオブジェクト（仮想サービスオブジェク
ト：Virtual Service Object、図中「ＶＳＯ」と略記）
１０が生成されている。本実施形態では、これらのオブ
ジェクトはＪＡＶＡのインスタンスとして生成されるも
のとする。

【００１９】本実施形態では、これらオブジェクトを生
成するために、予め基本サービスオブジェクトの内容を
定義する基本サービスオブジェクト定義ファイル（PSO
Definition File、図中「ＰＳＯＤＦ」と略記）１６
と、同様に仮想サービスオブジェクト定義ファイル（VS
O Definition File、図中「ＶＳＯＤＦ」と略記）１４
が準備される。これらのファイルは、プレインテキスト
の形で記述してもよいし、ＪＡＶＡのクラスファイルと
して記述してもよい。同図のように、クライアント３か
らは仮想サービスオブジェクト１０がアクセスの対象と
なり、仮想サービスオブジェクト１０は各基本サービス
オブジェクト１２をメソッド実行の形で利用し、基本サ
ービスオブジェクト１２はそれぞれ基本サービスを実現
するサーバ１に関連づけられている。

【００２０】図３は、サービス連携装置２を中心に図２
の構成の詳細を示す図である。同図のごとくサービス連
携装置２は、クライアントとの間で必要な情報の授受を
行うクライアント連絡部２０と、サーバとの間で必要な
情報の授受を行うサーバ連絡部２４と、それら両者の間
に位置するサービスオブジェクト群２２と、各種サービ
スに関するオブジェクトを生成して管理するオブジェク
ト管理部２６を含む。サービスオブジェクト群２２に
は、生成された基本サービスオブジェクト１２と仮想サ
ービスオブジェクト１０が待機状態におかれている。

【００２１】クライアント連絡部２０は、ＷＷＷブラウ
ザなどのクライアント３とＨＴＴＰ（ハイパーテキスト
転送プロトコル）で通信するためのデーモンであるＨＴ
ＴＰＤ３０と、ユーザの認証やクライアント３とのセッ
ションを管理するセッション管理部３２と、クライアン
ト３から送られたＣＧＩパラメータを解析するＣＧＩパ
ラメータ解析部３４をもつ。サーバ連絡部２４の内部構
成は図１３で詳述するが、当面は以下の機能をもつもの
として説明する。

【００２２】１．仮想サービスオブジェクト１０の要求
に対して自己の保有するパーツのうち必要なものを返
す。

【００２３】２．必要なパーツを保有していないとき、
または必要なパーツを保有しているがその内容が古いと
き、実際にサーバに基本サービスを再実行させ、その結
果を得てパーツを生成する。

【００２４】３．２で生成したパーツを仮想サービスオ
ブジェクト１０に返す。

【００２５】４．仮想サービスオブジェクト１０が要求
する場合には、パーツをテンプレートにはめ込んで提供
する。

【００２６】ここでパーツとは、基本サービスの実行の
結果得られる情報、例えばＨＴＭＬ文書を分割して得ら
れる各部分をいう。

【００２７】オブジェクト管理部２６は、まず基本サー
ビスオブジェクト１２に関して、基本サービスオブジェ
クト定義ファイル変換部４６と、基本サービスオブジェ
クト生成部４４を含む。基本サービスオブジェクト定義
ファイル変換部４６は、基本サービスオブジェクト定義
ファイル１６がプレインテキストであるとき、これをＪ
ＡＶＡコードのクラスファイルに変換するインタプリタ
である。基本サービスオブジェクト生成部４４は、変換
によって得られたＪＡＶＡのクラスファイルを読み込ん
で基本サービスオブジェクト１２を生成する。一方、仮
想サービスオブジェクトについては、仮想サービスオブ
ジェクト定義ファイル変換部４２、仮想サービスオブジ
ェクト生成部４０により、同様の処理を経て仮想サービ
スオブジェクト１０が生成される。

【００２８】図４、図５は、それぞれ基本サービスオブ
ジェクト定義ファイル１６と仮想サービスオブジェクト
定義ファイル１４の記述例である。この例では、前者は
プレインテキストで、後者は最初からＪＡＶＡコードで
書かれている。ここでは基本サービスとしてプリントサ
ービス、仮想サービスとして商品の見積書作成サービス
を仮定している。これらの図の左端には、説明の便宜上
テキストの行番号をふっている。

【００２９】図４ではまず、第１行に基本サービスの名
称が記述され、第３行に基本サービスのバージョンが記
述されている。基本サービスオブジェクト定義ファイル
１６の内容は基本サービスのバージョンと整合すべきで
あるから、基本サービス側にバージョンアップがあれ
ば、適宜基本サービスオブジェクト定義ファイル１６を
更新してバージョンを合わせておく。

【００３０】つぎに、第５〜１６行にパーツが記述され
ている。これらのパーツがプリントサービスを提供する
際に用いられる。例えば第６〜８行では「ＰｒｉｎｔＯ
ｐｔｉｏｎ」というパーツを用いることが宣言され、そ
のパーツがＨＴＭＬ文書として保持される箇所が「ＵＲ
Ｌ」で示される。また、そのパーツがＨＴＭＬ文書の一
番目のＦＯＲＭタグの部分に相当することがＦｏｒｍ
（１）として示されている。他の２つのパーツについて
も同様に解釈する。つづいて第１８〜３２行には、この
基本サービスを実現するメソッドが示されている。ここ
にはメソッドの名前、利用するパーツ等が記載されてい
る。以上の構成で基本サービスオブジェクトの処理内容
が確定する。なお、プリントサービス以外の基本サービ
スについても図４同様のファイルが準備される。

【００３１】一方、図５は仮想サービスオブジェクトの
内容を確定するもので、ＪＡＶＡのメソッドの羅列で記
述されている。まず第３〜６行において、仮想サービス
オブジェクト１０が利用する基本サービスオブジェクト
１２を宣言している。ここでは、商品情報データベース
サービス（第３行）、文書データベースサービス（第４
行）、プリントサービス（第５行）、文書合成サービス
（第６行）が利用される。すなわち、まず見積書作成の
対象となる商品の単価等のデータを商品情報データベー
スサービスで取得し、見積書のひな型を文書データベー
スサービスで取得する。つづいて文書合成サービスによ
り、得られたひな型に商品情報に流し込み、最終的に得
られた見積書をプリントサービスで印刷する。

【００３２】一連の過程において、第８行の「Ｔａｂｌ
ｅ」には商品の検索結果が入り、第９行の「Ｄｏｃｕｍ
ｅｎｔ」には見積書のひな型が入る。第１２〜１５行は
システムの初期化、第１７〜２１行は商品情報データベ
ースサービス、第２３〜２７行は文書データベースサー
ビス、第２９〜３３行は文書合成サービス、第３５〜３
７行はプリントサービスにおけるオプションの設定、第
３９〜４１行は実際の印刷をそれぞれ記述している。商
品情報を検索する際、ユーザが入力した検索キーがＣＧ
Ｉパラメータとして第１８行の「ｌｉｓｔ」に渡され
る。図５の第３６行の「ｐｒｉｎｔ．Ｏｐｔｉｏｎ」
は、図４の第１９行に対応しており、仮想サービスオブ
ジェクトと基本サービスオブジェクトが関連づけられ
る。なお、第１９行などにある「Ｔｅｍｐｌａｔｅ」
は、サービスの結果得られるパーツをテンプレートには
め込んで提供させるための指示である。

【００３３】以上、このファイルをもとに仮想サービス
オブジェクト生成部４０で、商品情報の検索から見積書
の出力に至る一連の処理が、あたかもひとつの基本サー
ビスであるかのごとく生成される。なお、以降説明の都
合上、テンプレートは最終的に見積書が合成されて出力
される際にのみ利用されるものとする。

【００３４】図６から図１１は仮想サービスである見積
書作成サービスの各段階におけるクライアント３側端末
の画面表示例、図１２は見積書作成サービスを提供する
手順を示すフローチャートである。以下、これらの図お
よび図３を用いて仮想サービスの提供動作を説明する。

【００３５】まず図１２のごとく、基本サービスオブジ
ェクト１２と仮想サービスオブジェクト１０が生成され
る（Ｓ２）。このために、図３の基本サービスオブジェ
クト定義ファイル変換部４６が図４の基本サービスオブ
ジェクト定義ファイル１６を読み込み、これを解釈しな
がらＪＡＶＡのクラスファイルに変換する。つづいて、
このクラスファイルをもとに基本サービスオブジェクト
生成部４４が基本サービスオブジェクト１２を生成す
る。

【００３６】同様に、図５の仮想サービスオブジェクト
定義ファイル１４をもとに、仮想サービスオブジェクト
定義ファイル変換部４２と仮想サービスオブジェクト生
成部４０により、仮想サービスオブジェクト１０が生成
される。この例では、仮想サービスオブジェクト定義フ
ァイル１４が予めＪＡＶＡコードで記述されているた
め、仮想サービスオブジェクト定義ファイル変換部４２
は何もしない。生成されたオブジェクトは図３の矢印Ａ
を通ってサービスオブジェクト群２２の一部を形成し、
システムが待機状態になる。

【００３７】この状態でクライアント３のユーザが図３
の矢印Ｂのごとく、端末を介して「見積書作成サービ
ス」の起動要求をかける（Ｓ４）。この要求はクライア
ント連絡部２０のＨＴＴＰＤ３０を経て、図３の矢印Ｃ
のごとくサービスオブジェクト群２２に到達する。

【００３８】サービスオブジェクト群２２では、要求に
したがい、仮想サービスオブジェクト１０が起動され
る。図５に示すとおり、仮想サービスの最初の動作とし
て、まず商品情報データベースサービスが起動される。
このとき、商品情報の検索初期画面をクライアント３側
の端末に表示すべきであるため、その表示に必要なパー
ツが矢印Ｄのごとくサーバ連絡部２４に要求される。

【００３９】要求されたパーツがサーバ連絡部２４に存
在すれば、これが図３の矢印Ｇをとおって仮想サービス
オブジェクト１０に与えられる。仮想サービスオブジェ
クト１０は、このパーツを自己のサービスの一画面とし
て矢印Ｈ、Ｉによってクライアント３に送る。一方、必
要なパーツがサーバ連絡部２４に存在しなければ、サー
バ連絡部２４は実際に商品情報データベースサービスを
提供するサーバ１に対してサービスを実行するよう矢印
Ｅで要求し、その結果矢印Ｆで与えられるＨＴＭＬ文書
（この時点では商品情報検索の初期画面を表示するため
のＨＴＭＬ文書）をパーツ化し、必要なパーツを仮想サ
ービスオブジェクト１０に与える。サーバ連絡部２４が
サーバ１から入手したＨＴＭＬ文書のいずれの部分に関
するパーツが要求されているかは、本実施形態では図４
の第８行などの「Ｐｏｓｉｔｉｏｎ」に明示されてい
る。ここで仮に、商品情報の検索初期画面として、「商
品名」および「商品コード」の入力インタフェイス部分
のみがパーツとして求められたとき、端末の画面には図
６のような表示がなされる。

【００４０】ユーザは商品名、商品コードの少なくとも
一方を検索キーとして入力し、検索実行ボタンをクリッ
クする。この検索キーはＨＴＴＰＤ３０を経てＣＧＩパ
ラメータ解析部３４で解析され、商品情報の検索という
実際の基本サービスの際に利用される。仮想サービスオ
ブジェクト１０は商品情報の検索、より正確には検索の
結果得られるパーツをサーバ連絡部２４に要求する（矢
印Ｄ）。サーバ連絡部２４は、要求がＣＧＩパラメータ
を伴うことに鑑み、検索サービスを即座にサーバ１に依
頼する（矢印Ｅ）。後述のごとく、ＣＧＩパラメータが
ある場合、一般に基本サービスの実行結果は始終変化す
る。このため、本実施形態のサーバ連絡部２４は、そう
した基本サービスの実行結果は、要求に従ってパーツ化
はしても、自己の内部で保存しない方針だからである。
いずれにせよ、商品情報の検索が実際に行われ（図１２
のＳ６）、図７のごとく結果が表示される。ユーザはこ
の表示の中から所望の商品をクリックして選択する（Ｓ
８）。

【００４１】つづいてユーザは、図７の画面下部に表示
された「文書検索ボタン」をクリックする。この時点
で、最初の基本サービスである商品情報データベースサ
ービスは終了し、つぎの基本サービスである文書データ
ベースサービスが起動される。このとき、文書の検索初
期画面をクライアント３側端末に表示すべきであるた
め、表示に必要なパーツが矢印Ｄのごとくサーバ連絡部
２４に要求される。以降、商品情報の検索初期画面のと
きと同様の過程を経て、必要なパーツがクライアント３
に送られる。ここでは図８に示すとおり、初期画面とし
て、「文書ひな型名」および「文書ひな型コード」の入
力インタフェイス部分のパーツが表示されている。

【００４２】ここでユーザは文書ひな型名、文書ひな型
コードの少なくとも一方を検索キーとして入力し、検索
実行ボタンをクリックする。この検索キーは文書検索と
いう実際の基本サービスの際に利用される。以下、商品
情報のときと同様の過程を経て文書ひな型の検索が行わ
れ（Ｓ１０）、結果が図９のごとく表示される。ユーザ
は適宜詳細表示ボタンをクリックして各文書ひな型の内
容を確認し、所望の文書ひな型を選択する（Ｓ１２）。
選択された文書ひな型は図１０のように画面に表示され
る。

【００４３】つづいてユーザは、図１０の画面下部に表
示された「文書合成ボタン」をクリックする（Ｓ１
４）。この時点で文書データベースサービスが終了し、
別の基本サービスである文書合成サービスが起動され
る。ユーザのクリックに伴い、商品情報データベースサ
ービスで選択された商品情報と文書データベースサービ
スで選択された文書ひな型が文書合成サービスに引き渡
される。

【００４４】文書合成サービスでは、文書ひな型に対し
て商品情報を流し込むが、このとき最終結果の表示のた
めにテンプレートの指定があるか否かが確認される（Ｓ
１６）。前述のごとく本実施形態では、文書合成サービ
スについてのみテンプレートの指定があると仮定してい
る。図１８はそのテンプレートを示す図で、パーツをは
め込むべき穴である２つのウインドウａ、ｂが設けられ
ている。ここではウインドウａに見積書、ウインドウｂ
に見積書掲載商品に関する商品説明がそれぞれリンクさ
れているとする。商品説明自体もパーツであり、商品情
報データベースサービスが実際に行われたときにサーバ
連絡部２４に返されたＨＴＭＬ文書の中からパーツ化さ
れ、サーバ連絡部２４に保持されている。

【００４５】文書合成サービスでは、まず商品情報を文
書ひな型に流し込んで見積書を完成させ、これをパーツ
としてサーバ連絡部２４で保持する。つづいてこの見積
書をウインドウａの箇所に貼り付け、商品説明をウイン
ドウｂに貼り付け、テンプレートへのパーツの合成を終
える（Ｓ１８）。こうして、最終的に図１１の画面表示
がなされる（Ｓ２０）。同図のごとく、ウインドウａに
対応する領域７０に見積書が表示され、ウインドウｂに
対応する領域７２に商品説明が表示されている。この状
態でユーザが図１１の下部に設けられた「プリントボタ
ン」をクリックすれば、最後の基本サービスであるプリ
ントサービスが起動され、見積書が印刷される。以上が
仮想サービス提供の全容である。

【００４６】つづいて、サーバ連絡部２４におけるパー
ツの生成と管理を説明する。

【００４７】図１３はサーバ連絡部２４の内部構成図で
ある。同図のごとくサーバ連絡部２４は、仮想サービス
オブジェクト１０からパーツ要求を受ける要求受付部５
０と、要求に従って必要なパーツを生成するパーツ生成
部５４と、パーツを生成する際にサーバに実際に基本サ
ービスを実行させ、その結果をＨＴＭＬ文書の形で得る
サーバアクセス部５６と、パーツを保持するパーツデー
タベース５８と、パーツ管理全般を行うパーツ管理部５
２と、テンプレート保持部６４と、テンプレート保持部
６４から仮想サービスオブジェクト１０の指定するテン
プレートが読み出されたとき、これに必要なパーツを合
成するパーツ合成部６０と、合成の結果を仮想サービス
オブジェクト１０に返す要求応答部６２をもつ。

【００４８】図１４は、サーバ連絡部におけるパーツの
生成および管理の手順を示すフローチャートである。同
図のごとく、仮想サービスオブジェクト１０からパーツ
の要求が出されたとき（Ｓ３０）、これが要求受付部５
０で受け付けられる。つづいてパーツ管理部５２によ
り、要求されたパーツがパーツデータベース５８に存在
するか否かが確認される（Ｓ３２）。存在する場合（Ｓ
３２のＹ）は、ひきつづきそのパーツが有効であるか否
かが確認される（Ｓ３４）。パーツの有効性には以下の
ような判断基準がある。

【００４９】１．パーツの生成日時が古いかどうか ２．パーツのもとになるＨＴＭＬ文書を提供したサーバ
側にバージョンアップがあったかどうか このうち、２を採用する場合、仮想サービスオブジェク
ト定義ファイル１４に、その仮想サービスオブジェクト
１０が利用を予定する基本サービスのバージョンを記述
しておく。例えば、プリントサービスとしてバージョン
２．１の利用を予定する場合、その旨を仮想サービスオ
ブジェクト定義ファイル１４のプリントサービスに関連
する箇所に記述する。一方、プリントサービスはその基
本サービスオブジェクト定義ファイル１６にバージョン
の記述をもっていたため、これら２つのバージョンが一
致すればパーツは有効、不一致であれば無効と判断す
る。バージョンが異なるとパーツの大きさなどが変化
し、テンプレートへのパーツの合成に支障をきたすなど
の問題が生じうるためである。

【００５０】パーツが有効であると判断された場合（Ｓ
３４のＹ）、パーツデータベース５８から該当するパー
ツが読み出され（Ｓ３６）、パーツ合成部６０に送られ
る。ここで、図１２のＳ１６とＳ１８と同様に、仮想サ
ービスオブジェクト１０がそのパーツを要求するに当た
り、テンプレートの指定があるか否かが判定され（Ｓ１
６）、指定があればテンプレート保持部６４から該当す
るテンプレートを読み出してパーツを合成し（Ｓ１
８）、これを要求応答部６２を介して仮想サービスオブ
ジェクト１０に提供する（Ｓ３８）。テンプレートの指
定がなければ（Ｓ１６のＮ）、パーツをそのまま仮想サ
ービスオブジェクト１０に提供する（Ｓ３８）。

【００５１】一方、Ｓ３２でパーツデータベース５８に
必要なパーツがないか、Ｓ３４でパーツが有効でないと
判断された場合、サーバアクセス部５６が、求められた
パーツを生成するためにサーバにアクセスし（Ｓ４
０）、基本サービスを実行させる。サーバは基本サービ
スを実行した結果ＨＴＭＬ文書の形でサーバアクセス部
５６に応答を返す。サーバアクセス部５６は入手したＨ
ＴＭＬ文書をパーツ生成部５４に渡す。

【００５２】パーツ生成部５４は後述の方法によってＨ
ＴＭＬ文書を分解してパーツを生成し（Ｓ４２）、これ
らのパーツをパーツ管理部５２に与えてパーツデータベ
ース５８に登録させる（Ｓ４４）とともに、要求の対象
となったパーツをパーツ合成部６０に渡す。ただし前に
触れたとおり、パーツの要求に当たってＣＧＩパラメー
タが参照された場合は、そのパーツをパーツデータベー
ス５８に登録しない。以下、Ｓ１６に進んでテンプレー
ト関連処理を行い、最終的に要求応答部６２を経てパー
ツを仮想サービスオブジェクト１０に返す（Ｓ３８）。

【００５３】つづいて、パーツ生成ステップＳ４２にお
けるパーツ生成方法を説明する。パーツの生成方法はい
ろいろ考えられるが、例えば以下のような方法がある。

【００５４】（１）タグを手がかりとする形式的なパー
ツ生成 通常ＨＴＭＬ文書では、タグで囲まれた部分がひとかた
まりの処理単位になる。例えばＦＯＲＭタグの場合、＜
ＦＯＲＭ＞が開始タグ、＜／ＦＯＲＭ＞が終了タグであ
り、この間に処理内容が記述される。したがって、パー
ツ生成部５４の最も単純な処理は、ＨＴＭＬ文書をパー
スし、任意の開始タグ＜ｘｘｘ＞を見つけたらその開始
タグに対応する終了タグ＜／ｘｘｘ＞までをひとつのパ
ーツとして切り出すことにある。

【００５５】この方法の場合の問題は、タグによっては
終了タグをもたないものや、入れ子の構造をとるものが
あることである。図１５（ａ）（ｂ）はそうしたＨＴＭ
Ｌの記述例と実際の表示状態をそれぞれ示しており、こ
こではＬＩタグが終了タグをもたず、ＵＬタグが入れ子
になっている。ＵＬタグは、異なる先頭記号（同図の
◎、□など）を付してＬＩタグの内容を表示する機能を
もつ。同図（ａ）では、ＵＬタグが３つの階層８０、８
２、８４の入れ子になっている。

【００５６】こうした場合、パーツ生成部５４は、ＵＬ
タグについては開始タグ＜ＵＬ＞が連続して現れる箇所
を記録しておき、終了タグ＜／ＵＬ＞が現れたら、もっ
とも近い＜ＵＬ＞と組にしてパーツを構成していけばよ
い。一方、ＬＩタグについては、＜ＬＩ＞が現れた後、
再度＜ＬＩ＞が現れるか、または＜ＵＬ＞など異なる種
類のタグが現れたら、先のＬＩタグが終了したとみな
す。この規則により、ＬＩタグについてもパーツ化が可
能になる。終了タグをもたないタグとして、他にＩＮＰ
ＵＴタグがあるが、これも同様の規則でパーツ化でき
る。

【００５７】なお、ＴＡＢＬＥタグのように、行列構造
をもつタグもある。その場合、＜ＴＡＢＬＥ＞〜＜／Ｔ
ＡＢＬＥ＞の部分を切り出してＴＡＢＬＥ全体をひとつ
のパーツにする他、行ごと、列ごと、または行と列の交
点ごとにパーツ化することもできる。

【００５８】以上、いずれの方法であっても、生成され
たパーツにはそのパーツを識別するパーツ名称やＩＤが
与えられる。基本サービスオブジェクト定義ファイル１
６には、その基本サービスのいずれの場面でいずれのパ
ーツが必要であるかをパーツ名称やＩＤで記述しておけ
ばよい。この後、実際に仮想サービスが提供されるとき
には、その仮想サービスオブジェクト１０から基本サー
ビスオブジェクト１２が呼び出され、この基本サービス
オブジェクト１２が基本サービスオブジェクト定義ファ
イル１６に従って動作するため、そのファイル内に記述
されたパーツ名称等によって特定されたパーツがサーバ
連絡部２４に要求される。

【００５９】（２）ユーザインタフェイスを考慮した実
質的なパーツ生成 （１）の方法で生成されたパーツで仮想サービスオブジ
ェクト１０の要求に応えられる場合もあるが、ひとつの
ユーザインタフェイスを構成する部分をひとつのパーツ
にしたい場合、（１）の方法にはさらに改善の余地があ
る。

【００６０】図１６はプリントサービスで利用されるユ
ーザインタフェイスの例を示している。図１７はこの表
示を実現するＨＴＭＬの記述例である。図１６のユーザ
インタフェイスは、図１７のごとく、ＦＯＲＭタグによ
って記述されている。（１）の方法であれば、図１７の
記述全体をひとつのパーツにすることができるし、ラジ
オボタンのひとつ、すなわちあるＩＮＰＵＴタグの行を
ひとつのパーツにすることもできる。しかしこれらの場
合、図１７のＩＮＰＵＴタグに伴う「Ｂ４」「Ａ３」
等、ラジオボタンのラベルをパーツの一部に含めること
ができなくなる。これらのラベルはＩＮＰＵＴタグの外
に置かれており、ＨＴＭＬ上ではＩＮＰＵＴタグとの論
理的関係が判明しないためである。

【００６１】そこでパーツ生成部５４は、＜ＩＮＰＵＴ
＞等のタグの直後に記述されている内容（ここではラベ
ル）がそのタグにユーザインタフェイスレベルで関連す
るものとみなし、これらをリンクしてパーツデータベー
ス５８に登録する。それ以外の方法として、＜ＩＮＰＵ
Ｔ＞等のタグと同一の行に記述されている内容全部をリ
ンクさせてもよい。通常、ＨＴＭＬで記述する場合、論
理的に関連するものはある程度同一行にまとめたり、逆
に関連のないものは改行してから記述するという経験則
に基づいている。

【００６２】以上、（２）によれば、パーツが実際に表
示されたときに一定の関係をもつもの、例えばひとつの
ユーザインタフェイスを構成する複数のオブジェクトな
どを予めひとつのパーツとして保持することができる。
この場合も（１）同様パーツ名やパーツＩＤで基本サー
ビスオブジェクト定義ファイル１６から呼び出すことが
できる。

【００６３】（３）基本サービスオブジェクト定義ファ
イルに従うパーツ生成 その他の方法として、基本サービスオブジェクト定義フ
ァイル１６に、パーツして切り出すべき部分を明示的に
記述する方法がある。すでに説明した図４はその例であ
り、例えば第８行の「Ｐｏｓｉｔｉｏｎ」には「Ｆｏｒ
ｍ（１）」と記述されている。これはＨＴＭＬ文書を上
からパースしたときに、一番目に現れるＦＯＲＭタグの
部分をパーツ化するよう指示している。こうした明示的
な指示がある場合、パーツ生成部５４はその指示にした
がってパーツの切り出しを行えばよい。

【００６４】［実施の形態２］図１９は本発明の他の実
施形態に係るサービス連携装置をサーバクライアントシ
ステムに用いる場合のシステム構成図である。同図にお
いて、図１と同様の機能を有する構成要素には図１と同
じ符号を付し説明を省略する。本装置は、仮想サービス
オブジェクト定義ファイル１４として、パーツ情報を記
憶するパーツ定義ファイル１００、テンプレート定義フ
ァイル１０２、シナリオ定義ファイル１０４、及びメソ
ッド定義ファイル１０６という４種類の定義ファイルを
含んでいる。これら定義ファイルは定義ファイル解析部
１０８にて解析され、オブジェクト管理部２６に渡され
る。また、クライアント連絡部２０に続いてサービスオ
ブジェクト群２２における各仮想サービスの進捗を把握
し制御するシナリオ実行部１１０が設けられる。

【００６５】まず、シナリオ定義ファイル１０４を設け
ることにより実現される機能について説明する。図２０
は、シナリオの概念、機能を説明する模式図である。図
２０（ａ）は文書検索サービスと印刷サービスを連携さ
せた仮想サービスにおける各基本サービスの実行順序関
係を示す。図において、検索条件設定１２０と検索結果
表示１２２は文書検索サービスを構成する基本サービス
のページを示し、印刷プロパティ１２４と印刷結果表示
１２６は印刷サービスを構成する基本サービスのページ
を示す。仮想サービスは、これらページを矢印で示す順
序に従って遷移し、処理を実行することにより提供され
る。すなわち検索条件設定１２０で設定された条件に従
って文書の検索を行い、検索結果表示１２２にて所望の
結果が得られなかったことが確認されると、再び検索条
件設定１２０に戻って条件を設定し直し検索を行う。一
方、所望の結果が得られた場合には、印刷プロパティ１
２４に遷移して印刷処理を行い、印刷結果表示１２６に
てその印刷結果を表示し検索結果表示１２２に戻る。

【００６６】このような処理の流れ、すなわちシナリオ
は、ユーザの要求に応じて容易に変更できることが望ま
しい。例えば、図２０（ｂ）は、同図（ａ）に示すシナ
リオを修正し、印刷サービスをＦＡＸサービスに差し替
えた場合を表している。ここで、ＦＡＸプロパティ１２
８とＦＡＸ結果表示１３０はＦＡＸサービスを構成する
基本サービスのページである。この場合の処理は、検索
の結果所望の結果が得られた場合には検索条件設定１２
０からＦＡＸプロパティ１２８に遷移してＦＡＸ送信を
行い、ＦＡＸ結果表示１３０を表示した後、検索条件設
定１２０に戻るという一連の流れに変更される。従来
は、これら各ページで当該ページの処理の各場合に応じ
て次に遷移すべきページのアドレスが定義されていた。
つまり、処理の流れは各ページを追っていかないと把握
できず、修正作業が煩雑になるという問題があった。

【００６７】これを解決するために本装置では、シナリ
オ定義ファイルを設けている。まず、仮想サービスで用
いられる基本サービスの部品がパーツ定義ファイルに定
義される。図２１は、図２０（ｂ）に対応するパーツ定
義ファイルの記述例を示す図である。図の左端には、説
明の便宜上テキストの行番号をふっている。

【００６８】パーツ定義ファイルでは、第４行の〈ＰＡ
ＲＴＳＤＥＦＳ〉と第１１行の〈／ＰＡＲＴＳＤＥＦ
Ｓ〉の間に挟まれる各〈ＰＡＲＴＳ〉タグが、それぞれ
部品に相当する。部品の種類は、「ＩＤ」に続くパラメ
ータにより指定される。図に示す例では、第５〜１０行
はそれぞれ検索条件設定１２０、検索結果表示１２２、
印刷プロパティ１２４、印刷結果表示１２６、ＦＡＸプ
ロパティ１２８、ＦＡＸ結果表示１３０に対応する。こ
のパーツ定義ファイルには、これら部品間の処理の順序
に関する情報は含まれていない。この部品間の処理順序
に係わる情報を定義するのがシナリオ定義ファイルであ
る。

【００６９】図２２、２３は、それぞれ図２０（ａ）、
（ｂ）に対応するシナリオ定義ファイルである。図２２
を用いて説明すると、第１行の〈ＳＣＥＮＡＲＩＯ〉と
第２３行の〈／ＳＣＥＮＡＲＩＯ〉の間に挟まれる部分
がシナリオの実体を定義する部分である。基本サービス
の各ページは〈ＳＣＥＮＥ〉タグから〈／ＳＣＥＮＥ〉
タグまでの記述に対応付けられる。例えば、第１９行の
“〈ＳＣＥＮＥ ＮＡＭＥ＝thumbnailResult ＰＡＲＴ
Ｓ＝thumbnailPrint〉”は図２１の第８行に記述された
“ＩＤ＝thumbnailPrint”を有する部品を用いた処理印
刷結果表示１２６の記述開始を意味する。このシナリオ
中の場面の識別子として「ＮＡＭＥ」に続くパラメータ
が指定される。

【００７０】〈ＳＣＥＮＥ〉タグと〈／ＳＣＥＮＥ〉タ
グの間には〈ＡＣＴＩＯＮ〉タグが記述され、「ＴＲＡ
ＮＳＩＴＩＯＮ」パラメータの値に応じて、現在の画面
表示から次にどのサービスの画面表示に遷移するかが定
義される。例えば、第２０行の定義には、パラメータの
値としてデフォルト（default）が指定されている。こ
れは、現在のサービスに続いて無条件に「ＮＡＭＥ」識
別子として“result”を有する画面表示に遷移すること
を指定するものである。これにより、処理は、印刷結果
表示１２６のサービス提供から、第８〜１１行に定義さ
れる検索結果表示１２２のサービス提供に移行すること
になる。

【００７１】また、第７〜１１行に定義される検索結果
表示１２２の画面表示からは、図２０（ａ）に示される
ように、検索条件設定１２０または印刷プロパティ１２
４に遷移する。これは検索結果表示１２２のサービスに
おいてユーザ指定等により「ＴＲＡＮＳＩＴＩＯＮ」パ
ラメータの値に“Back”または“ThumbPrint”のいずれ
かの値がセットされ、“Back”の場合には第９行の定義
により、「ＮＡＭＥ」識別子として“condition”を有
する検索条件設定１２０の画面表示に遷移する。一方、
“ThumbPrint”の場合には、第１０行の定義により印刷
プロパティ１２４に遷移する。

【００７２】このように、図２２に示すシナリオ定義フ
ァイルには図２０（ａ）に示す処理の流れの定義が集約
されている。ユーザは、この処理の流れを図２０（ｂ）
に示す流れに変更したい場合には、このシナリオ定義フ
ァイルのみを図２３に示すように変更すればよい。ここ
で行われる変更は、第一にＦＡＸプロパティ１２８とＦ
ＡＸ結果表示１３０にそれぞれ対応する定義として、新
たに第２３〜２７行、第２９〜３２行の記述を追加する
ことである。第二に、検索条件設定１２０に関する第１
０行の記述において、遷移先をＦＡＸプロパティ１２８
とする変更が行われる。シナリオ定義ファイルは、各ペ
ージの処理を定義したファイルに比べると遥かに小さな
サイズになる。つまり、変更を要する部分が小さな範囲
に限定されることにより、例えばエディタ等を用いた変
更作業において、変更箇所間の移動の手間が低減され、
また、シナリオ定義ファイルに基づいて画面の遷移の流
れを把握することが容易となる。

【００７３】本装置では、シナリオ定義ファイル等の定
義ファイルは定義ファイル解析部１０８により解析され
る。この解析結果を基にオブジェクト管理部にて、各サ
ービスオブジェクトが生成される。例えば、基本サービ
スとして文書検索サービスや印刷サービス等の基本サー
ビスオブジェクト１２とこれらを組み合わせた仮想サー
ビスオブジェクト１０がサービスオブジェクト群２２と
して生成される。例えば、クライアント３から文書検索
要求が発せられると、シナリオ実行部１１０はシナリオ
の解釈を行って、サーバ連絡部２４を介してサーバ１に
要求を渡す。また、このとき、シナリオ実行部１１０は
シナリオの進行状態を次のページに進める。サーバ連絡
部２４は、サーバ１から受け取った文書検索結果等を解
析しパーツ化する。そして、仮想サービスの定義に従っ
て部品を合成し、クライアント３に仮想ページを返す。

【００７４】ここでシナリオ実行部１１０は、複数のク
ライアント３が本装置に接続され、サービスの提供を受
ける場合において、各クライアント３に対してどの仮想
サービスのどのページを提供しているか、つまりどの画
面表示を提供しているかをシナリオ定義ファイルに基づ
いて制御、管理する機能を有する。

【００７５】次に、テンプレート定義ファイル１０２に
より実現される本発明について説明する。部品化された
基本サービス（基本パーツ）は、情報端末の画面に表示
されたときに機能的に一つのユーザインターフェイスを
形成する部分を単位として定義される。本装置では、基
本パーツは基本サブパーツという部品にさらに細分化さ
れる。図２４は基本サービスのパーツ定義の記述例を示
す図である。この例は、検索条件設定１２０に対応する
ページを定義したものである。

【００７６】基本パーツの一つの定義範囲は、〈ＢＡＳ
ＩＣＰＡＲＴＳ〉タグと〈／ＢＡＳＩＣＰＡＲＴＳ〉タ
グに挟まれる範囲である。基本サブパーツは、〈ＳＵＢ
ＰＡＲＴＳ〉タグにより定義される。図において第４〜
２９行で定義されるこのページには第９〜１１行と第１
３行と第１５〜２９行とにそれぞれ定義される３つの基
本パーツが含まれている。この基本パーツは必要に応じ
てさらに細かい基本サブパーツに部品化され、各基本サ
ブパーツは上記基本パーツの範囲内に〈ＳＵＢＰＡＲＴ
Ｓ〉タグを用いて定義される。例えば第１６〜２６行の
各〈ＳＵＢＰＡＲＴＳ〉タグがそれぞれ一つの基本サブ
パーツに対応する。各基本パーツ内での基本サブパーツ
は相互に、「ＩＤ」に続くパラメータにより識別され
る。

【００７７】仮想サービスオブジェクト定義ファイル１
４には、図２１に例示したようなパーツ定義ファイルが
用意される。しかし、このパーツ定義ファイルは、仮想
サービスで提供される基本サービスの種類を定義する
が、そのレイアウトの情報は含んでいない。本発明で
は、ページの遷移は上述したシナリオ定義ファイルに従
って定義し、各ページ内のレイアウトはテンプレート定
義ファイルにより定義する。

【００７８】図２５は、基本サービスにて提供されるペ
ージの一例を示す模式図である。また図２６は、図２５
に示すページにおける基本サブパーツの定義例を示す模
式図である。基本サブパーツ１４０〜１５４は、それぞ
れ基本サービスオブジェクト生成部４４において〈ＳＵ
ＢＰＡＲＴＳ〉タグを用いて定義される。例えばこの基
本サブパーツへの細分化の対象となるのは、フォームや
テーブルである。つまり、基本サービスオブジェクト生
成部４４は基本パーツを解釈して例えば、〈ＦＯＲＭ〉
タグや〈ＴＡＢＬＥ〉タグを見出すと、その部分を自動
的にまたはユーザにより指定された条件に従って細分化
して基本サブパーツを生成する。

【００７９】図２７は、図２５に対応するテンプレート
定義ファイルの一例を示す図である。この図において、
基本サブパーツは〈ＤＡＬ_ＰＡＲＴＳ〉タグを用いて
引用される。具体的に引用される基本サブパーツは、
「ＶＡＬＵＥ」に続くパラメータにその識別子を記述す
ることにより特定される。テンプレート定義ファイル中
で引用される基本サブパーツの識別子は、例えば、“サ
ービス名．ページ名．基本パーツ名．基本サブパーツ
名”というように管理の階層構造を反映するように定義
することができる。これによりたとえ異なるページや基
本パーツ間にて〈ＳＵＢＰＡＲＴＳ〉タグ中のＩＤパラ
メータが重複しても、それらを相互に識別することがで
きる。

【００８０】このように基本サブパーツを定義すること
により、これら基本サブパーツの相互の配置関係を自由
に定義できるようになる。テンプレート定義ファイルの
役割はこの配置を定義することにある。例えば、図に示
す例では、〈ＰＤＸＴＡＢ〉タグを用いてレイアウトの
調整を行っている。〈ＰＤＸＴＡＢ〉を基本サブパーツ
の前に置くことにより、定義ファイル解析部１０８は、
基本サブパーツをタブ位置に整列して表示させることが
できる。

【００８１】このようなテンプレート定義ファイルを画
面の形態の異なる情報端末のそれぞれに対して用意する
ことによって、各情報端末において見やすい最適の表示
を実現することができる。例えば、情報端末の画面が小
さい場合、図２５に示すような画面をそのまま表示させ
ようとすると、横方向に並んだ２つの基本サブパーツの
位置関係が乱れるおそれがある。このように２つの基本
サブパーツを横方向に並べることが困難な場合には、基
本サブパーツを１つずつ行を改めて配列し表示するよう
なテンプレート定義ファイルを用意すれば、乱れのない
画面表示を得ることができる。

【００８２】これに対し、従来は基本パーツ内の配置は
固定であった。つまり画面上で配置を変えて表示しよう
とすると、基本パーツ自身の配置を変える作業と別に基
本パーツ内の構成要素の相互の位置関係を変えた他の基
本パーツを定義する作業が必要となり、ユーザの負担と
なっていた。しかし、本装置では各基本パーツに内蔵さ
れていたレイアウトに関する情報を基本パーツから分離
し、基本パーツ単位でのレイアウトとその中の詳細なレ
イアウトとの双方の情報を一括して管理、定義するテン
プレート定義ファイルを用意したので、ユーザによるレ
イアウト変更作業が容易となり、様々な形態の情報端末
への対応が容易となる。

【００８３】なお、従来はユーザがデータを入力可能な
フォームは一つの部品として扱われていたため、ＣＧＩ
パラメータは一つのフォーム内で管理していた。これに
対して、本装置では基本サブパーツによってフォームを
それを構成するインプットテキストごと等の要素にまで
細分化し部品化することとした。つまり、一つの仮想サ
ービスオブジェクト中に複数の基本サービスオブジェク
トの要素を含むことが可能となる。このため、仮想サー
ビスオブジェクト中において、ユーザの入力により変更
された項目を何らかの方法で基本サービスオブジェクト
に反映する仕組みを用意する必要がある。そのため本装
置では、仮想サービスオブジェクト、基本サービスオブ
ジェクトのそれぞれのフォームに対応したパラメータテ
ーブルを用意している。図２８は、この仮想サービスオ
ブジェクトのパラメータテーブルと基本サービスオブジ
ェクトのパラメータテーブルの関係を説明する模式図で
ある。サービス連携装置２には、仮想サービスオブジェ
クトのパラメータテーブル１７０と各基本サービスオブ
ジェクトのパラメータテーブル１７２〜１７６が用意さ
れる。ユーザがクライアント３から仮想サービスを利用
し、その中でフォームに入力等を行うと、その入力内容
は仮想サービスオブジェクトのパラメータテーブル１７
０の所定の欄に格納されるとともに、この所定欄に対応
付けられる基本サービスオブジェクトのパラメータテー
ブル１７２〜１７６の所定の欄の内容も変更される。こ
れにより、仮想サービスオブジェクトと基本サービスオ
ブジェクトとの相互の内容の整合性が確保される。

【００８４】また、メソッド定義ファイル１０６は、上
述したようなパーツ定義ファイル１００、テンプレート
定義ファイル１０２、シナリオ定義ファイル１０４によ
って定義しきれない例えば例外的な手続き等を定義する
ために用いられる。そのような手続き的処理をこのメソ
ッド定義ファイル１０６に集中させ、他の３つの定義フ
ァイルからは取り除く。これにより、パーツ定義ファイ
ル１００、テンプレート定義ファイル１０２、シナリオ
定義ファイル１０４それぞれの構成の簡潔さを保つこと
ができ、ユーザによるレイアウト変更やシナリオの変更
といった作業の容易性を担保することができる。

【図面の簡単な説明】

【図１】 実施形態に係るサービス連携装置をサーバク
ライアントシステムに用いる場合のシステム構成図であ
る。

【図２】 あるクライアントと複数のサーバの関係をサ
ービス連携装置の内部構成との関係において示す図であ
る。

【図３】 サービス連携装置を中心に図２の構成の詳細
を示す図である。

【図４】 基本サービスオブジェクト定義ファイルの例
を示す図である。

【図５】 仮想サービスオブジェクト定義ファイルの例
を示す図である。

【図６】 見積書作成サービスの各段階におけるクライ
アント側端末の画面表示例を示す図である。

【図７】 見積書作成サービスの各段階におけるクライ
アント側端末の画面表示例を示す図である。

【図８】 見積書作成サービスの各段階におけるクライ
アント側端末の画面表示例を示す図である。

【図９】 見積書作成サービスの各段階におけるクライ
アント側端末の画面表示例を示す図である。

【図１０】 見積書作成サービスの各段階におけるクラ
イアント側端末の画面表示例を示す図である。

【図１１】 見積書作成サービスの各段階におけるクラ
イアント側端末の画面表示例を示す図である。

【図１２】 見積書作成サービスを提供する手順を示す
フローチャートである。

【図１３】 実施形態のサーバ連絡部の内部構成図であ
る。

【図１４】 サーバ連絡部におけるパーツの生成および
管理の手順を示すフローチャートである。

【図１５】 （ａ）（ｂ）は終了タグをもたないタグや
入れ子の構造をもつタグを含むＨＴＭＬの記述例と実際
の表示状態をそれぞれ示す図である。

【図１６】 プリントサービスで利用されるユーザイン
タフェイスの例を示す図である。

【図１７】 図１６の表示を実現するＨＴＭＬの記述例
である。

【図１８】 実施形態で利用するテンプレートを示す図
である。

【図１９】 第二の実施形態に係るサービス連携装置を
サーバクライアントシステムに用いる場合のシステム構
成図である。

【図２０】 シナリオの概念、機能を説明する模式図で
ある。

【図２１】 図２０（ｂ）に対応するパーツ定義ファイ
ルの記述例を示す図である。

【図２２】 図２０（ａ）に対応するシナリオ定義ファ
イルである。

【図２３】 図２０（ｂ）に対応するシナリオ定義ファ
イルである。

【図２４】 基本サービスのパーツ定義の記述例を示す
図である。

【図２５】 基本サービスにて提供されるページの一例
を示す模式図である。

【図２６】 図２５に示すページにおける基本サブパー
ツの定義例を示す模式図である。

【図２７】 図２５に対応するテンプレート定義ファイ
ルの一例を示す図である。

【図２８】 仮想サービスオブジェクトのパラメータテ
ーブルと基本サービスオブジェクトのパラメータテーブ
ルの関係を説明する模式図である。

【符号の説明】

１ サーバ、２ サービス連携装置、３ クライアン
ト、１０ 仮想サービスオブジェクト、１２ 基本サー
ビスオブジェクト、１４ 仮想サービスオブジェクト定
義ファイル、１６ 基本サービスオブジェクト定義ファ
イル、２０ クライアント連絡部、２２ サービスオブ
ジェクト群、２４ サーバ連絡部、２６オブジェクト管
理部、３０ ＨＴＴＰＤ、３２ セッション管理部、３
４ ＣＧＩパラメータ解析部、４０ 仮想サービスオブ
ジェクト生成部、４２ 仮想サービスオブジェクト定義
ファイル変換部、４４ 基本サービスオブジェクト生成
部、４６ 基本サービスオブジェクト定義ファイル変換
部、５０ 要求受付部、５２ パーツ管理部、５４ パ
ーツ生成部、５６ サーバアクセス部、５８ パーツデ
ータベース、６０ パーツ合成部、６２ 要求応答部、
６４ テンプレート保持部、１００ パーツ定義ファイ
ル、１０２ テンプレート定義ファイル、１０４ シナ
リオ定義ファイル、１０６ メソッド定義ファイル、１
０８ 定義ファイル解析部、１１０ シナリオ実行部。

Claims (12)

【特許請求の範囲】
1. 【請求項１】 複数の基本サービスの統合形態を規定す
   ることによってそれら複数の基本サービスの連携に係る
   仮想サービスを予め定義しておき、 サービスの提供に当たり、その定義に従い、基本サービ
   スオブジェクトを適宜利用する内部形式で仮想サービス
   オブジェクトを生成し、 生成された仮想サービスオブジェクトの実行という形で
   単一の基本サービスに準じた操作形式にて仮想サービス
   を提供することを特徴とするサービス連携方法。
2. 【請求項２】 前記仮想サービスの提供をクライアント
   とサーバの間に設けた中継装置に担当せしめ、クライア
   ントは実際に仮想サービスを構成する各基本サービスを
   実行するサーバを目的とする代わりに、この中継装置を
   目的として仮想サービスの要求を出すことを特徴とする
   請求項１に記載のサービス連携方法。
3. 【請求項３】 サーバとクライアントを中継するサービ
   ス連携装置であって、 サーバとの間で必要な情報の授受を行うサーバ連絡部
   と、 クライアントとの間で必要な情報の授受を行うクライア
   ント連絡部と、 各種サービスに関するオブジェクトを生成して管理する
   オブジェクト管理部と、 を含み、 前記オブジェクト管理部は、 基本サービスオブジェクトに関する定義に従って基本サ
   ービスオブジェクトを生成する基本サービスオブジェク
   ト生成部と、 生成された複数の基本サービスオブジェクトの統合に係
   る仮想サービスオブジェクトに関する定義に従って仮想
   サービスオブジェクトを生成する仮想サービスオブジェ
   クト生成部と、 を含み、クライアントからクライアント連絡部に対して
   仮想サービスの提供が要求されたとき、オブジェクト管
   理部の管理する仮想サービスオブジェクトによってサー
   バ連絡部を介してサーバに適宜基本サービスを実行さ
   せ、その実行結果をもとにクライアントに仮想サービス
   を提供することを特徴とするサービス連携装置。
4. 【請求項４】 前記サーバ連絡部は、 基本サービスの実行の結果得られる情報を分割してパー
   ツを生成するパーツ生成部と、 生成されたパーツを保持するパーツデータベースと、 を含み、仮想サービスの提供に当たり、その仮想サービ
   スを構成する複数の基本サービスの結果得られる情報が
   パーツの組合せとしてクライアントに提供される請求項
   ３に記載のサービス連携装置。
5. 【請求項５】 前記サーバ連絡部は、 基本サービスの実行の結果得られる情報を分割してパー
   ツを生成するパーツ生成部と、 生成されたパーツを保持するパーツデータベースと、 仮想サービスの提供に当たり、その仮想サービスを構成
   する複数の基本サービスに関するパーツを所定枠にはめ
   込むパーツ合成部と、 を含み、所定枠に必要なパーツがはめ込まれた状態で仮
   想サービスの結果がクライアントに提供される請求項３
   に記載のサービス連携装置。
6. 【請求項６】 基本サービスの実行の結果得られる情報
   のうち、情報端末の画面に表示されたとき機能的にひと
   つのユーザインタフェイスを形成する部分を識別してこ
   の部分を単位に前記情報をパーツ化して保存することを
   特徴とするパーツ生成管理方法。
7. 【請求項７】 基本サービスの統合に係る仮想サービス
   の提供に当たり、仮想サービスオブジェクトから要求さ
   れたパーツをその仮想サービスオブジェクトに提供する
   請求項６に記載のパーツ生成管理方法。
8. 【請求項８】 前記情報が画面構造記述言語で書かれた
   プログラムの形式をとるとき、このプログラム中の処理
   単位を示す記述をもとにユーザインタフェイスを形成す
   る部分を識別する請求項６、７のいずれかに記載のパー
   ツ生成管理方法。
9. 【請求項９】 仮想サービスオブジェクトからパーツが
   要求されたとき、生成済みのパーツまたは新たに生成す
   べきパーツのいずれが要求されているかを判定し、 新たに生成すべきパーツが要求されているときには、サ
   ーバに基本サービスを実行させてパーツ生成に必要な情
   報を入手し、その情報をパーツ化したうえでこれを仮想
   サービスオブジェクトに送付する請求項７、８のいずれ
   かに記載のパーツ生成管理方法。
10. 【請求項１０】 さらに複数の基本サービスオブジェク
    トの統合に係る仮想サービスオブジェクトに関する定義
    を記憶する仮想サービスオブジェクト定義記憶部を含
    み、 前記仮想サービスオブジェクト生成部は、前記仮想サー
    ビスオブジェクト定義記憶部中の定義に従い、前記基本
    サービスオブジェクトを統合して前記仮想サービスオブ
    ジェクトを生成し、 前記仮想サービスオブジェクト定義記憶部は、仮想サー
    ビス中での基本サービスの遷移の順序を定義したシナリ
    オ情報を含み、 クライアントからの仮想サービスの提供の要求に対し、
    前記シナリオ情報に従ってサーバに前記基本サービスを
    実行させ、その実行結果をもとにクライアントに仮想サ
    ービスを提供することを特徴とする請求項３に記載のサ
    ービス連携装置。
11. 【請求項１１】 複数の前記クライアントそれぞれに対
    して個別に前記シナリオ情報に基づいて前記基本サービ
    スの遷移の実行制御を行うシナリオ実行部を含み、複数
    のクライアントに対し並列して前記仮想サービスを提供
    することを特徴とする請求項１０に記載のサービス連携
    装置。
12. 【請求項１２】 さらに複数の基本サービスオブジェク
    トの統合に係る仮想サービスオブジェクトに関する定義
    を記憶する仮想サービスオブジェクト定義記憶部を含
    み、 前記基本サービスオブジェクト生成部は、 基本サービスの実行の結果得られる情報のうち、情報端
    末の画面に表示されたとき機能的にひとつのユーザイン
    タフェイスを形成する部分を識別してこの部分を基本パ
    ーツとし、前記基本パーツに含まれる前記情報をさらに
    構成要素である基本サブパーツに部品化し、 前記仮想サービスオブジェクト定義記憶部は、 前記仮想サービスオブジェクトを構成する前記基本パー
    ツの種類を定義するパーツ情報と、 前記仮想サービスオブジェクトを構成する前記基本パー
    ツに含まれる前記基本サブパーツの前記画面上でのレイ
    アウトを定義するテンプレート情報と、 を含むことを特徴とする請求項３に記載のサービス連携
    装置。