JP2010009380A

JP2010009380A - バスシステム

Info

Publication number: JP2010009380A
Application number: JP2008168951A
Authority: JP
Inventors: Mitsuhiko Miwa; 光彦三輪; Masahiko Ohashi; 正彦大橋; Miyuki Sato; 美幸佐藤
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 2008-06-27
Filing date: 2008-06-27
Publication date: 2010-01-14
Anticipated expiration: 2028-06-27
Also published as: CN101616050A; US20090327406A1; CN101616050B; EP2139203A1; US8082296B2; JP5104591B2

Abstract

【課題】バスシステムのスケールアウトを容易に行うことができるとともに、対象となるアプリケーションが決まらなくても通信を行えるようにする。
【解決手段】サーバアプリケーション毎に設けた複数のサーバエージェントと、ユーザアプリケーション毎に設けた複数のユーザエージェントとを備え、前記サーバエージェントは、対応する前記サーバアプリケーションと通信する手段と、前記サーバエージェントもしくは前記ユーザエージェントと通信する手段と、通信先の前記サーバエージェントもしくは前記ユーザエージェントを決定する手段とを有し、前記ユーザエージェントは、対応する前記ユーザアプリケーションと通信する手段と、前記サーバエージェントもしくは前記ユーザエージェントと通信する手段と、通信先の前記サーバエージェントもしくは前記ユーザエージェントを決定する手段とを有する。
【選択図】図５

Description

本発明は、ネットワーク上に構築されるＥＳＢ（Enterprise Service Bus）等のバスシステムに関する。

図１はインターネットで用いられている従来のＷｅｂ版ネットワークシステムの構成例を示す図である。図１において、データベース（データベースサーバ）１を用いた業務アプリケーション群（アプリケーションサーバ群）２に対し、Ｗｅｂブラウザ群（クライアント群）３からリクエストを行い、レスポンスを受け取ることにより、プル（Ｐｕｌｌ）型の通信を実現している。なお、このＷｅｂ版ネットワークシステムでは、Ｗｅｂブラウザ群３からのリクエストを通信の契機とするものであり、サーバ側の業務アプリケーション群２からＷｅｂブラウザ群３に対するプッシュ（Ｐｕｓｈ）型の通信は実現することができない。

サーバ側からのプッシュ型通信の要求に対応するために、例えば、バスシステムが利用されている。

公知のバスの概念の一例として、ＥＳＢがあり、様々な検討がなされている（http://www.atmarkit.co.jp/aig/04biz/esb.html等を参照。）。ＥＳＢは、ＳＯＡ（Service Oriented Architecture）に基づいたアプリケーション統合を“バス”の概念でデザインするアーキテクチャパターン、あるいはそれを実現するための基盤となるソフトウェア製品をいう。ＥＳＢ概念は、サービス（アプリケーションやコンポーネント）へのアクセスを行い、複数のサービスを協調・連携動作するＳＯＡシステムを、論理的なソフトウェアバスに基づいて構成するというソフトウェア設計上の考え方である。従って、具体的な機能や実装は個別の製品やシステムによって異なるが、一般的に標準的なＳＯＡインタフェースを備えたＥＡＩ（Enterprise Application Integration）製品、ないしはマルチプロトコルをサポートする高機能なメッセージバス、それを含む統合型ミドルウェアテクノロジ、ミドルウェア製品などを指す。また、ＷｅｂサービスやＪＣＡ（J2EE Connector Architecture）などのオープンな標準仕様に準拠して開発されたサービスを相互連携させるインテグレーションブローカである。中核となるメッセージバスは、ＨＴＴＰ（Hyper Text Transfer Protocol）、ＳＯＡＰ（Simple Object Access Protocol）、ＪＭＳ（Java（登録商標） Message Service）など標準的プロトコルに対応し、パブリッシュ＆サブスクライブ、ストアフォワードメッセージ、ルーティングなどの機能を提供し、サービス同士を同期／非同期に連携させる。完全なＳＯＡ環境においては分散処理構成とできるが、実際の製品にはレガシー接続、データ変換などの機能を併せ持つものも多く、広義のＥＡＩとして使用できる。更に、セキュリティ、負荷分散、プロセスモデリングなどの機能を提供する製品もある。

図２は従来のバスシステムの構成例を示す図であり、アプリケーションＡＰ１〜ＡＰ６、・・の間にバスシステムＢＳを介在させ、アプリケーション間の通信が必要な場合は全てバスシステムＢＳを通信経路として通信を行うことで、プル型通信およびプッシュ型通信のいずれも自由に行えるようにしている。なお、各アプリケーションＡＰ１〜ＡＰ６、・・とバスシステムＢＳの間は、汎用的なＨＴＴＰ、ＳＯＡＰ、ＪＭＳ等により通信を行うようになっている。

ところで、従来のネットワークにおけるバスシステムは、バスシステムにつながるサーバアプリケーションやユーザアプリケーションを、一度には１対１で通信することにより処理していた。そのため、バスシステムにつながるサーバアプリケーションやユーザアプリケーションが増えるほどバスシステムに負荷が生じ、バスシステムはその負荷に耐える必要があった。

負荷分散を実現する方式の一例として、バスシステムを複数のプロセスにより構成し、プロセス間通信を行うことにより分散させる方式が存在する。負荷分散の具体例として、「ＥＳＢＭｕｌｅモデル」「エンドポイントＥＳＢ」「Ａｒｔｉｘ」「Ｃｅｌｔｉｘ」等がある。「ＥＳＢＭｕｌｅモデル」は、アプリケーション間のコミュニケーションを管理するための分散オブジェクトブローカを有する、軽量のメッセージングフレームワークである（http://www.mulesource.org/display/JPNDOC/Architecture+Overview）。「エンドポイントＥＳＢ」は、エンドポイントにすべてを集約する考え方でエンドポイントを組み合わせることでＥＳＢを構成するものである（http://www.mulesource.org/display/JPNDOC/Mule+Endpoints、http://blogs.iona.com/essence/2006/11/esb_1.html）。エンドポイントＥＳＢの実装の一例として、「Ａｒｔｉｘ」がある。「Ａｒｔｉｘ」は、ＣＯＲＢＡ（Common Object Request Broker Architecture）の文化を引き継いだＥＳＢである。「Ｃｅｌｔｉｘ」はオープンソースＥＳＢである（http://celtix.objectweb.org/）。

図３は複数のプロセスにより負荷分散を実現した従来のバスシステムの構成例を示す図である。図３においては、アプリケーションＡＰ１〜ＡＰ５がアクセスするバスシステムＢＳをプロセスＰ１〜Ｐ５によって構成している。そして、それぞれのプロセスＰ１〜Ｐ５の間をプロセス間通信することにより通信の交通整理を行い、その結果、負荷分散を実現している。これにより、アプリケーションが増えても、バスシステムＢＳのスケールアウト（プロセスを増やすことでバスシステム全体のパフォーマンスを向上させること）を実現することができる。
特開平９−３０７５８３号公報

近年、既存の通話サービスや電子メールなどのデータ系サービスを組み合わせ、新しい通信サービスを開発し実行するための基盤が検討されてきている。この新しい基盤では、既存の回線交換サービスをＳＩＰ（Session Initiation Protocol）ベースのパケット網で実現するだけでなく、今までにない機能を新たに追加することも可能になる予定である。一例として、ＮＧＮ（Next Generation Network）上で実現するＳＤＰ（Service Delivery Platform）がある。

このような場面では、多数のユーザがバスシステムを介してサーバアプリケーションにアクセスすることが考えられる。特に、あるサービスに人気が出ると、その１つのサービスに対し多数のユーザのアクセスが一時に集中することがしばしば起こる。このような場面では、前述のバスシステムの各既存技術や実装にてスケールアウトを実現しようとしても限界が生じてくる。すなわち、ユーザ側が急激に増加し、アクセスが特定のアプリケーションに集中してしまうと、やはり限界が生じてしまう。

図４は特定のサーバアプリケーションとプロセスに負荷集中が起こる様子を示す図である。図４においては、複数プロセスＰ１〜Ｐ５でバスシステムＢＳを構成し、その上層側にはサーバアプリケーション群（サーバアプリケーションＡ１、Ａ２、Ｂ１、Ｃ１、・・）が、また、下層側にはユーザアプリケーション群（ユーザアプリケーションＵ１〜Ｕ４、・・）があり、各アプリケーションは、バスシステムＢＳを構成しているいずれかのプロセスＰ１〜Ｐ５とつながっている。また、バスシステムＢＳを構成しているプロセスＰ１〜Ｐ５同士は、プロセス間のルーティングにより負荷分散を実現している。なお、サーバアプリケーションＡ１、Ａ２は同じサービス（アプリケーションＡ）を提供しているものとしている。

今、アプリケーションＡに人気が出ると、ユーザアプリケーション群（ユーザアプリケーションＵ１〜Ｕ４、・・）からのアクセスが人気のあるアプリケーションＡ（サーバアプリケーションＡ１、Ａ２）に一斉に集中し、そのトラヒックが多くなる。また、ユーザアプリケーション群は、アプリケーションＡに人気があるとの噂やトレンドから、ユーザアプリケーション自体が増加していく。その数は、場合により数十万〜数百万オーダにも達する。それらのユーザアプリケーションＵ１〜Ｕ４、・・が一斉にサーバアプリケーションＡ１、Ａ２に向かってアクセスを開始することになる。

これらのトラヒックを、バスシステムＢＳを構成している複数のプロセスＰ１〜Ｐ５が処理することになるが、各プロセスＰ１〜Ｐ５が担う負荷の偏りが生じてくる。特に、サーバアプリケーションＡ１、Ａ２と直接に通信を行う末端のプロセスＰ１に負荷が集中してくる。そして、この負荷集中を回避することができず、結局、バスシステムＢＳ自体のスケールアウトが困難になる。

このように、従来のバスシステムでは、負荷が集中するとバスシステムに限界が生じ、バスシステムのスケールアウトができないという問題があった。

また、特許文献１には、データベースを持つサーバ間において、各々の共通メモリ間でデータ送受信を行うスーパーエージェントが開示されている。しかし、この手法においても、ルータ間の通信やスーパーエージェント自体に負荷が集中し、スケールアウトの実現は困難である。

一方、上述した負荷集中とは異なる観点からの不都合として、各アプリケーションは通信対象となるアプリケーションが決まらないと通信できないという問題があった。例えば、一般にユーザはサーバアプリケーションが提供するサービスを欲するのであり、必ずしも所望のサービスを提供するサーバアプリケーションを特定できているとは限らない。特に、同様なサービス（例：検索サービス）を提供するサーバアプリケーションが頻繁に新設されたり消滅したりする場合には、対象となるサーバアプリケーションを常に特定することを期待することは困難である。

上記の従来の問題点に鑑み、スケールアウトを容易に行うことができるとともに、対象となるアプリケーションが決まらなくても通信を行うことのできるバスシステムを提供することを目的とする。

このバスシステムの一実施態様では、サーバアプリケーション毎に設けた複数のサーバエージェントと、ユーザアプリケーション毎に設けた複数のユーザエージェントとを備え、前記サーバエージェントは、対応する前記サーバアプリケーションと通信する手段と、前記サーバエージェントもしくは前記ユーザエージェントと通信する手段と、通信先の前記サーバエージェントもしくは前記ユーザエージェントを決定する手段とを有し、前記ユーザエージェントは、対応する前記ユーザアプリケーションと通信する手段と、前記サーバエージェントもしくは前記ユーザエージェントと通信する手段と、通信先の前記サーバエージェントもしくは前記ユーザエージェントを決定する手段とを有する。

好ましくは、前記ユーザエージェントにおける通信先の前記サーバエージェントもしくは前記ユーザエージェントを決定する手段は、前記ユーザアプリケーションから受信したサービスＵＲＩから辞書に問い合わせることで、負荷に余裕のある前記サーバエージェントを通信先として決定する。

好ましくは、前記ユーザエージェントにおける通信先の前記サーバエージェントもしくは前記ユーザエージェントを決定する手段は、前記ユーザアプリケーションから受信したサービスＵＲＩに基づいて辞書に問い合わせることで、通信先候補の前記サーバエージェントの中から巡回的に前記サーバエージェントを通信先として決定する。

好ましくは、前記サーバエージェントにおける通信先の前記サーバエージェントもしくは前記ユーザエージェントを決定する手段は、前記サーバアプリケーションから受信したサービスＵＲＩに基づいて辞書に問い合わせることで、配信先となる前記ユーザアプリケーションに対応する前記ユーザエージェントを通信先として決定する。

好ましくは、前記サーバエージェントにおける通信先の前記サーバエージェントもしくは前記ユーザエージェントを決定する手段は、前記サーバアプリケーションから受信したサービスＵＲＩに基づいて辞書に問い合わせることで、同サービスを提供する他のサーバエージェントを通信先として決定し、前記サーバエージェントにおける前記サーバエージェントもしくは前記ユーザエージェントと通信する手段は、決定されたサーバエージェントに配信コンテンツもしくはそのＵＲＩのレプリカを送信することで、当該サーバエージェントから他のユーザエージェントに配信コンテンツもしくはそのＵＲＩを送信させる。

好ましくは、前記ユーザエージェントにおける通信先の前記サーバエージェントもしくは前記ユーザエージェントを決定する手段は、前記ユーザアプリケーションから受信したシナリオの記述に基づいてシナリオ解釈部に問い合わせることで、当該シナリオを処理可能な前記サーバアプリケーションに対応する前記サーバエージェントを通信先として決定する。

開示のバスシステムにあっては、スケールアウトを容易に行うことができるとともに、対象となるアプリケーションが決まらなくても通信を行うことができる。

以下、本発明の好適な実施形態につき説明する。

＜基本構成＞
図５は本発明の一実施形態にかかるバスシステムの構成例を示す図である。

図５において、バスシステム１００の上層にはサーバアプリケーション群（サーバアプリケーションＡ１〜Ａ３、Ｂ１、・・）があり、下層にはユーザアプリケーション群（ユーザアプリケーションＵ１〜Ｕ４、・・）がある。サーバアプリケーションＡ１〜Ａ３は同一のサーバアプリケーションＡを提供しているものとしている。

バスシステム１００は、サーバアプリケーションＡ１〜Ａ３、Ｂ１、・・毎に設けられたサーバエージェントａ１〜ａ３、ｂ１、・・と、ユーザアプリケーションＵ１〜Ｕ４、・・毎に設けられたユーザエージェントｕ１〜ｕ４、・・とを備えている。各エージェント（サーバエージェントａ１〜ａ３、ｂ１、・・、ユーザエージェントｕ１〜ｕ４、・・）は、単一もしくは分散された複数のサーバ上で実行されるコンピュータプログラムにより実現される。

また、バスシステム１００には、各エージェントの生成・消滅等の管理を行うエージェント管理部１１０と、エージェントの通信先等を管理するＮＳ（Network Service）辞書１２０と、シナリオ（サービス内容を表すキーワード等）を解釈してエージェントの通信先等を決定するシナリオ解釈部１３０とを備えている。なお、ＮＳ辞書１２０は各エージェントに同内容を分散して保持することで省略することもできる。

図６はエージェント（サーバエージェントａ１〜ａ３、ｂ１、・・、ユーザエージェントｕ１〜ｕ４、・・）の構成例を示す図である。図６において、エージェントは、アプリケーション向け通信部１１と、エージェント向け通信部１２と、ＮＳ辞書問い合わせ部１３と、ＵＲＩ変換部１４と、保持データ１５とを有している。

アプリケーション向け通信部１１は、サーバアプリケーションやユーザアプリケーションと通信する機能を有している。エージェント向け通信部１２は、他のエージェントと通信する機能を有している。ＮＳ辞書問い合わせ部１３は、ユーザアプリケーションもしくはサーバアプリケーションからＵＲＩ（Uniform Resource Identifier）を受け取ると、対応するエージェント名をＮＳ辞書１２０に問い合わせる機能を有している。ＵＲＩ変換部１４は、ＮＳ辞書問い合わせ部１３から得たエージェント名を用いて、ＵＲＩを読み替える機能を有している。

保持データ１５としては、当該エージェントを識別する名称を保持する「エージェント名」と、参照するＮＳ辞書１２０を特定する名称を保持する「辞書名」と、ＮＳ辞書１２０への問い合わせの結果として得られたエージェントの識別子を保持する「対応エージェント識別子」と、対応するアプリケーションの識別子を保持する「対応アプリケーション識別子」とを有している。図７は保持データ１５の例を示す図であり、（ａ）はサーバエージェントにおける保持データ１５の例、（ｂ）はユーザエージェントにおける保持データ１５の例である。

図５において、サーバエージェントａ１〜ａ３、ｂ１、・・は対応するサーバアプリケーションＡ１〜Ａ３、Ｂ１、・・と通信を行う。サーバエージェントとサーバアプリケーションの間の通信方式インタフェースは、既存のバスシステムに変更を加えることなく、汎用的なインタフェースを用いる。

ユーザエージェントｕ１〜ｕ４、・・は対応するユーザアプリケーションＵ１〜Ｕ４、・・と通信を行う。ユーザエージェントとユーザアプリケーションの間の通信方式インタフェースは、既存のバスシステムに変更を加えることなく、汎用的なインタフェースを用いる。

各エージェントはエージェント同士の通信を行い、通信経路を決めることで負荷分散を行い、特定のサーバアプリケーションおよび対応するサーバエージェントに負荷が集中するのを防止する。通信経路の決定は、ＮＳ辞書１２０を参照することで通信相手となる他のエージェントを決定することで行うほか、直接エージェント同士が通信して行うことができる。

このような基本機能を備えることで、プル型およびプッシュ型のいずれの通信方式にも柔軟に対応することができるとともに、負荷分散を実現することができる。

また、ユーザアプリケーションＵ１〜Ｕ４、・・からの通信においてシナリオを記述することで、シナリオ解釈部１３０により通信経路が決定されるようにすることができ、対象となるアプリケーションが決まらなくても通信を行うことができる。

＜プル型＞
図８はプル型に適用した場合のＮＳ辞書１２０の例を示す図である。図８において、ＮＳ辞書１２０は、ユーザアプリケーションから指定されるサービス提供のＵＲＩを示す「サービスＵＲＩ」と、当該サービスＵＲＩに対応するサーバエージェントを特定する「サーバエージェント名」と、当該サーバエージェントおよび対応するサーバアプリケーションの負荷状態（負荷小、負荷大等）を示す「状態」と、問い合わせに当該サーバエージェントを返答した履歴（タイムスタンプもしくは連番等）を示す「返答履歴」とを含んでいる。

図９はプル型における動作例を示す図であり、図１０はそのシーケンス図である。なお、図９における構成は、ＮＳ辞書１２０が実装されている点とシナリオ解釈部１３０が省略されている点の他は、図５に示した構成と同様である。

ここでは、サーバアプリケーションＡ１〜Ａ３の提供するサービス（アプリケーションＡ）の人気があり、たくさんのユーザアプリケーションＵ１〜Ｕ４、・・からアプリケーションＡが呼び出される場合を想定している。また、その過程で、サーバアプリケーションＡ１およびサーバエージェントａ１の状態が負荷小から負荷大となり、その旨がＮＳ辞書１２０に記録されるものとしている。

図９および図１０において、ユーザアプリケーションＵ１から対応するユーザエージェントｕ１に「ＵＲＩ：／／Ａ／」が送信されると（ステップＳ１０１）、ユーザエージェントｕ１はＮＳ辞書１２０に対してサービスＵＲＩ「Ａ」を指定してエージェント名を問い合わせる（ステップＳ１０２）。ＮＳ辞書１２０はサービスＵＲＩ「Ａ」から、図８の対応関係に従い、「サーバエージェントａ１」「サーバエージェントａ２」「サーバエージェントａ３」が該当することを認識するが、更にその状態と返答履歴を参照し、登録順に従い、状態が負荷大でなく、かつラウンドロビン方式に基づいて返答履歴の古いものからサーバエージェントを特定する。ここでは、先頭の「サーバエージェントａ１」の状態が「負荷小」で返答履歴が古いものとすると、ＮＳ辞書１２０は「サーバエージェントａ１」を対応エージェント名として返送する（ステップＳ１０３）。

次いで、ユーザエージェントｕ１はＮＳ辞書１２０から取得した対応エージェント名にＵＲＩを読み替え（ステップＳ１０４）、読み替えたＵＲＩの示すサーバエージェントａ１に通信する（ステップＳ１０５）。そして、サーバエージェントａ１は対応するサーバアプリケーションＡ１に通信を行う（ステップＳ１０６）。これにより、サーバアプリケーションＡ１からの応答として、所望のコンテンツがサーバエージェントａ１およびユーザエージェントｕ１を介してユーザアプリケーションＵ１に返される。

図１１は図１０におけるステップＳ１０１〜Ｓ１０６のエージェント（ユーザエージェントｕ１およびサーバエージェントａ１）内の処理を詳細に示すシーケンス図である。

図１１において、ユーザアプリケーションＵ１から対応するユーザエージェントｕ１にＵＲＩが送信されると（ステップＳ１３１）、アプリケーション向け通信部１１がこれを受信する。アプリケーション向け通信部１１はＮＳ辞書問い合わせ部１３に受信した情報を引き渡し（ステップＳ１３２）、ＮＳ辞書問い合わせ部１３はＮＳ辞書１２０に対してサービスＵＲＩを指定してエージェント名を問い合わせ（ステップＳ１３３）、対応エージェント名の返送を受信する（ステップＳ１３４）。

次いで、ＮＳ辞書問い合わせ部１３は受信した情報をＵＲＩ変換部１４に引き渡し（ステップＳ１３５）、ＵＲＩ変換部１４はＮＳ辞書１２０から取得した対応エージェント名にＵＲＩを読み替え（ステップＳ１３６）、読み替えたＵＲＩをエージェント向け通信部１２に引き渡す（ステップＳ１３７）。そして、エージェント向け通信部１２は読み替えたＵＲＩの示すサーバエージェントａ１に通信し（ステップＳ１３８）、サーバエージェントａ１では、エージェント向け通信部１２がこれを受信する。そして、エージェント向け通信部１２はアプリケーション向け通信部１１に受信した情報を引き渡し（ステップＳ１３９）、アプリケーション向け通信部１１は対応するサーバアプリケーションＡ１に通信を行う（ステップＳ１４０）。

図９および図１０に戻り、同様にユーザアプリケーションＵ２から対応するユーザエージェントｕ２に「ＵＲＩ：／／Ａ／」が送信されると（ステップＳ１０７）、ユーザエージェントｕ２はＮＳ辞書１２０に対してサービスＵＲＩ「Ａ」を指定してエージェント名を問い合わせる（ステップＳ１０８）。ＮＳ辞書１２０はサービスＵＲＩ「Ａ」から、図８の対応関係に従い、「サーバエージェントａ１」「サーバエージェントａ２」「サーバエージェントａ３」が該当することを認識するが、更にその状態と返答履歴を参照し、登録順に従い、状態が負荷大でなく、かつラウンドロビン方式に基づいて返答履歴の古いものからサーバエージェントを特定する。ここでは、先頭の「サーバエージェントａ１」が返答履歴から直前に返答されていることがわかり、ＮＳ辞書１２０は「サーバエージェントａ２」を対応エージェント名として返送する（ステップＳ１０９）。

次いで、ユーザエージェントｕ２はＮＳ辞書１２０から取得した対応エージェント名にＵＲＩを読み替え（ステップＳ１１０）、読み替えたＵＲＩの示すサーバエージェントａ２に通信する（ステップＳ１１１）。そして、サーバエージェントａ２は対応するサーバアプリケーションＡ２に通信を行う（ステップＳ１１２）。これにより、サーバアプリケーションＡ２からの応答として、所望のコンテンツがサーバエージェントａ２およびユーザエージェントｕ２を介してユーザアプリケーションＵ２に返される。

同様にユーザアプリケーションＵ３から対応するユーザエージェントｕ３に「ＵＲＩ：／／Ａ／」が送信されると（ステップＳ１１３）、ユーザエージェントｕ３はＮＳ辞書１２０に対してサービスＵＲＩ「Ａ」を指定してエージェント名を問い合わせる（ステップＳ１１４）。ＮＳ辞書１２０はサービスＵＲＩ「Ａ」から、図８の対応関係に従い、「サーバエージェントａ１」「サーバエージェントａ２」「サーバエージェントａ３」が該当することを認識するが、更にその状態と返答履歴を参照し、登録順に従い、状態が負荷大でなく、かつラウンドロビン方式に基づいて返答履歴の古いものからサーバエージェントを特定する。ここでは、先頭の「サーバエージェントａ１」と次の「サーバエージェントａ２」が返答履歴から順次に返答されていることがわかり、ＮＳ辞書１２０は「サーバエージェントａ３」を対応エージェント名として返送する（ステップＳ１１５）。

次いで、ユーザエージェントｕ３はＮＳ辞書１２０から取得した対応エージェント名にＵＲＩを読み替え（ステップＳ１１６）、読み替えたＵＲＩの示すサーバエージェントａ３に通信する（ステップＳ１１７）。そして、サーバエージェントａ３は対応するサーバアプリケーションＡ３に通信を行う（ステップＳ１１８）。これにより、サーバアプリケーションＡ３からの応答として、所望のコンテンツがサーバエージェントａ３およびユーザエージェントｕ３を介してユーザアプリケーションＵ３に返される。

同様にユーザアプリケーションＵ４から対応するユーザエージェントｕ４に「ＵＲＩ：／／Ａ／」が送信されると（ステップＳ１１９）、ユーザエージェントｕ４はＮＳ辞書１２０に対してサービスＵＲＩ「Ａ」を指定してエージェント名を問い合わせる（ステップＳ１２０）。ＮＳ辞書１２０はサービスＵＲＩ「Ａ」から、図８の対応関係に従い、「サーバエージェントａ１」「サーバエージェントａ２」「サーバエージェントａ３」が該当することを認識するが、更にその状態と返答履歴を参照し、登録順に従い、状態が負荷大でなく、かつラウンドロビン方式に基づいて返答履歴の古いものからサーバエージェントを特定する。ここでは、「サーバエージェントａ１」「サーバエージェントａ２」「サーバエージェントａ３」が返答履歴から順次に返答されていることがわかり、先頭の「サーバエージェントａ１」が候補となるが、この時点でサーバエージェントａ１の状態が負荷大になっていたとすると、ＮＳ辞書１２０は次の「サーバエージェントａ２」を対応エージェント名として返送する（ステップＳ１２１）。

次いで、ユーザエージェントｕ４はＮＳ辞書１２０から取得した対応エージェント名にＵＲＩを読み替え（ステップＳ１２２）、読み替えたＵＲＩの示すサーバエージェントａ２に通信する（ステップＳ１２３）。そして、サーバエージェントａ２は対応するサーバアプリケーションＡ２に通信を行う（ステップＳ１２４）。これにより、サーバアプリケーションＡ２からの応答として、所望のコンテンツがサーバエージェントａ２およびユーザエージェントｕ４を介してユーザアプリケーションＵ４に返される。

このように、サーバアプリケーションＡ１〜Ａ３の提供するサービス（アプリケーションＡ）に対してユーザアプリケーションＵ１〜Ｕ４、・・からのアクセスが集中しても、サーバエージェントａ１〜ａ３に負荷分散が行われ、従来のように特定のプロセスに負荷が集中することがないため、サーバアプリケーションＡ１〜Ａ３および対応するサーバエージェントａ１〜ａ３の数を増やすことで容易にバスシステム１００のスケールアウトを実現することができる。

＜プッシュ型＞
図１２はプッシュ型に適用した場合のＮＳ辞書１２０の例を示す図である。図１２において、ＮＳ辞書１２０は、サーバアプリケーションから指定されるサービス提供のＵＲＩを示す「サービスＵＲＩ」と、当該サービスＵＲＩに対応するサーバエージェントを特定する「サーバエージェント名」と、予め当該サービスに加入手続により登録されたユーザアプリケーションを特定する「ユーザアプリケーション名」と、当該ユーザアプリケーションに対応するユーザエージェントを特定する「ユーザエージェント名」とを含んでいる。

図１３はプッシュ型における動作例を示す図であり、図１４はそのシーケンス図である。なお、図１３における構成は、ＮＳ辞書１２０が実装されている点とシナリオ解釈部１３０が省略されている点の他は、図５に示した構成と同様である。

図１３および図１４において、サーバアプリケーションＡ１から対応するサーバエージェントａ１に「ＵＲＩ：／／Ｘ／」が送信されると（ステップＳ２０１）、サーバエージェントａ１のアプリケーション向け通信部１１がこれを受信する。アプリケーション向け通信部１１はＮＳ辞書問い合わせ部１３に受信した情報を引き渡し（ステップＳ２０２）、ＮＳ辞書問い合わせ部１３はＮＳ辞書１２０に対してサービスＵＲＩを指定してエージェント名を問い合わせ（ステップＳ２０３）、対応エージェント名の返送を受信する（ステップＳ２０４）。ここでは、図１２のＮＳ辞書１２０における対応関係に基づき、サービスＵＲＩ「Ｘ」に対して、問い合わせをしたサーバエージェントａ１を除く「サーバエージェントａ２」「サーバエージェントａ３」と、問い合わせをしたサーバエージェントａ１が自ら処理すべきユーザに対応する「ユーザエージェントｕ１」「ユーザエージェントｕ４」（ラウンドロビン方式に従い、先頭のユーザエージェントｕ１を選択し、続くユーザエージェントｕ２、ｕ３はサーバエージェントａ２、ａ３にまかせ、その次のユーザエージェントｕ４を選択）を取得する。

次いで、ＮＳ辞書問い合わせ部１３は受信した情報をＵＲＩ変換部１４に引き渡し（ステップＳ２０５）、ＵＲＩ変換部１４はＮＳ辞書１２０から取得した対応エージェント名にＵＲＩを読み替え（ステップＳ２０６）、読み替えたＵＲＩをエージェント向け通信部１２に引き渡す（ステップＳ２０７）。

次いで、エージェント向け通信部１２はサーバエージェントａ２に対して宛先となるユーザエージェントｕ２を指定してコンテンツのレプリカを配信し（ステップＳ２０８）、同様にサーバエージェントａ３に対して宛先となるユーザエージェントｕ３を指定してコンテンツのレプリカを配信する（ステップＳ２０９）。

また、エージェント向け通信部１２はユーザエージェントｕ１に対して通信を行い（ステップＳ２１０）、ユーザエージェントｕ１ではこれをエージェント向け通信部１２が受信し、アプリケーション向け通信部１１に情報を引き渡し（ステップＳ２１１）、アプリケーション向け通信部１１は対応するユーザアプリケーションＵ１に通信を行う（ステップＳ２１２）。同様に、サーバエージェントａ１のエージェント向け通信部１２はユーザエージェントｕ４に対して通信を行い（ステップＳ２１３）、ユーザエージェントｕ４は対応するユーザアプリケーションＵ４に通信を行う（ステップＳ２１４）。

一方、サーバエージェントａ２はユーザエージェントｕ２に通信を行い（ステップＳ２１５）、ユーザエージェントｕ２は対応するユーザアプリケーションＵ２に通信を行う（ステップＳ２１６）。同様に、サーバエージェントａ３はユーザエージェントｕ３に通信を行い（ステップＳ２１７）、ユーザエージェントｕ３は対応するユーザアプリケーションＵ３に通信を行う（ステップＳ２１８）。

これらの動作により、サーバアプリケーションＡ１からユーザアプリケーションＵ１〜Ｕ４へのプッシュ型通信が実現される。

＜シナリオ対応＞
図１５はシナリオに対応した動作例を示す図である。なお、図１５においては、ユーザ側としてユーザアプリケーションＵ１を、サーバ側としてサーバアプリケーションＡ１、Ｂ１、Ｃ１を示し、バスシステム１００内はユーザアプリケーションＵ１に対応するユーザエージェントｕ１と、サーバアプリケーションＡ１、Ｂ１、Ｃ１にそれぞれ対応するサーバエージェントａ１、ｂ１、ｃ１と、シナリオ解釈部１３０とを示している。

動作にあっては、ユーザアプリケーションＵ１からバスシステム１００のユーザエージェントｕ１にシナリオを送信する。シナリオは、例えば「＜シナリオ＞検索＜／シナリオ＞」という形式で記述する。「＜シナリオ＞」はシナリオの開始位置を示すタグ、「＜／シナリオ＞」はシナリオの終了位置を示すタグであり、ここでのシナリオは「検索」という文字列である。また、検索のキーワードとして併せて「＜Ｋｅｙ＞ＦＪＴ＜／Ｋｅｙ＞」を送信する。ここで、「＜Ｋｅｙ＞」はキーワードの開始位置を示すタグ、「＜／Ｋｅｙ＞」はキーワードの終了位置を示すタグであり、ここでのキーワードは「ＦＪＴ」という文字列である。

ユーザエージェントｕ１はシナリオを受信すると、シナリオ（上記の例では「検索」）を指定してシナリオ解釈部１３０に問い合わせを行い、返答を得る。シナリオ解釈部１３０は図１６に示すような対応テーブルを有しており、サービス名「検索」に対し、同様な検索サービスを提供するサーバアプリケーションＡ１、Ｂ１、Ｃ１に対応するサーバエージェントａ１、ｂ１、ｃ１が、サーバアプリケーションＡ１、Ｂ１、Ｃ１からサーバエージェントａ１、ｂ１、ｃ１を介した要求に基づいて登録されている。従って、シナリオ解釈部１３０はシナリオ「検索」につき問い合わせを受けると、検索サービスを提供するサーバアプリケーションＡ１、Ｂ１、Ｃ１に対応するサーバエージェントａ１、ｂ１、ｃ１をユーザエージェントｕ１に返答する。

ユーザエージェントｕ１はシナリオ解釈部１３０から取得したサーバエージェントａ１、ｂ１、ｃ１に対してキーワード「ＦＪＴ」を指定した検索依頼を送信し、これを受信したサーバエージェントａ１、ｂ１、ｃ１は対応するサーバアプリケーションＡ１、Ｂ１、Ｃ１にキーワード「ＦＪＴ」を指定した検索依頼を送信する。そして、サーバエージェントａ１、ｂ１、ｃ１は対応するサーバアプリケーションＡ１、Ｂ１、Ｃ１から検索結果を受信すると、ユーザエージェントｕ１に検索結果を送信する。ユーザエージェントｕ１は検索結果をまとめ、ユーザアプリケーションＵ１に返送する。

これにより、ユーザアプリケーションＵ１を操作するユーザは「検索」というシナリオを特定することにより、それが処理されるサーバアプリケーションＡ１、Ｂ１、Ｃ１を意識することなく、たとえ検索サービスを提供するアプリケーションが増減しても、サービスの提供を受けることができる。

＜総括＞
上述した実施形態によれば、次のような利点がある。
（１）プル型通信、プッシュ型通信のいずれにも対応することができる。
（２）バスシステムの負荷分散を実現することができる。
（３）ユーザアプリケーションが増加（数十万、数百万オーダレベルでの増加）しても、それに対応したバスシステムのスケールアウトの実現が可能となる。特に、スケーラビリティを要求されるＮＧＮ等のネットワークシステムに適する。
（４）シナリオを用いることによって、サービスを抽象化した形で記述することができ、対象サーバアプリケーションが決まらなくても通信を開始することができる。また、アプリケーションの造りをシンプルにすることができる。

以上、本発明の好適な実施の形態により本発明を説明した。ここでは特定の具体例を示して本発明を説明したが、特許請求の範囲に定義された本発明の広範な趣旨および範囲から逸脱することなく、これら具体例に様々な修正および変更を加えることができることは明らかである。すなわち、具体例の詳細および添付の図面により本発明が限定されるものと解釈してはならない。
（付記１）
サーバアプリケーション毎に設けた複数のサーバエージェントと、ユーザアプリケーション毎に設けた複数のユーザエージェントとを備え、
前記サーバエージェントは、対応する前記サーバアプリケーションと通信する手段と、前記サーバエージェントもしくは前記ユーザエージェントと通信する手段と、通信先の前記サーバエージェントもしくは前記ユーザエージェントを決定する手段とを有し、
前記ユーザエージェントは、対応する前記ユーザアプリケーションと通信する手段と、前記サーバエージェントもしくは前記ユーザエージェントと通信する手段と、通信先の前記サーバエージェントもしくは前記ユーザエージェントを決定する手段とを有することを特徴とするバスシステム。
（付記２）
前記ユーザエージェントにおける通信先の前記サーバエージェントもしくは前記ユーザエージェントを決定する手段は、前記ユーザアプリケーションから受信したサービスＵＲＩから辞書に問い合わせることで、負荷に余裕のある前記サーバエージェントを通信先として決定することを特徴とする付記１に記載のバスシステム。
（付記３）
前記ユーザエージェントにおける通信先の前記サーバエージェントもしくは前記ユーザエージェントを決定する手段は、前記ユーザアプリケーションから受信したサービスＵＲＩに基づいて辞書に問い合わせることで、通信先候補の前記サーバエージェントの中から巡回的に前記サーバエージェントを通信先として決定することを特徴とする付記２に記載のバスシステム。
（付記４）
前記サーバエージェントにおける通信先の前記サーバエージェントもしくは前記ユーザエージェントを決定する手段は、前記サーバアプリケーションから受信したサービスＵＲＩに基づいて辞書に問い合わせることで、配信先となる前記ユーザアプリケーションに対応する前記ユーザエージェントを通信先として決定することを特徴とする付記１に記載のバスシステム。
（付記５）
前記サーバエージェントにおける通信先の前記サーバエージェントもしくは前記ユーザエージェントを決定する手段は、前記サーバアプリケーションから受信したサービスＵＲＩに基づいて辞書に問い合わせることで、同サービスを提供する他のサーバエージェントを通信先として決定し、
前記サーバエージェントにおける前記サーバエージェントもしくは前記ユーザエージェントと通信する手段は、決定されたサーバエージェントに配信コンテンツもしくはそのＵＲＩのレプリカを送信することで、当該サーバエージェントから他のユーザエージェントに配信コンテンツもしくはそのＵＲＩを送信させることを特徴とする付記４に記載のバスシステム。
（付記６）
前記ユーザエージェントにおける通信先の前記サーバエージェントもしくは前記ユーザエージェントを決定する手段は、前記ユーザアプリケーションから受信したシナリオの記述に基づいてシナリオ解釈部に問い合わせることで、当該シナリオを処理可能な前記サーバアプリケーションに対応する前記サーバエージェントを通信先として決定することを特徴とする付記１に記載のバスシステム。
（付記７）
サーバアプリケーション毎に設けた複数のサーバエージェントと、ユーザアプリケーション毎に設けた複数のユーザエージェントとを備えたバスシステムの制御方法であって、
前記ユーザエージェントが、対応する前記ユーザアプリケーションと通信する工程と、通信先の前記サーバエージェントもしくは前記ユーザエージェントを決定する工程と、決定された前記サーバエージェントもしくは前記ユーザエージェントと通信する工程と、
前記サーバエージェントが、対応する前記サーバアプリケーションと通信する工程とを備えたことを特徴とするバス制御方法。
（付記８）
前記ユーザエージェントにおける通信先の前記サーバエージェントもしくは前記ユーザエージェントを決定する工程は、前記ユーザアプリケーションから受信したサービスＵＲＩから辞書に問い合わせることで、負荷に余裕のある前記サーバエージェントを通信先として決定することを特徴とする付記７に記載のバス制御方法。
（付記９）
前記ユーザエージェントにおける通信先の前記サーバエージェントもしくは前記ユーザエージェントを決定する工程は、前記ユーザアプリケーションから受信したサービスＵＲＩに基づいて辞書に問い合わせることで、通信先候補の前記サーバエージェントの中から巡回的に前記サーバエージェントを通信先として決定することを特徴とする付記８に記載のバス制御方法。
（付記１０）
サーバアプリケーション毎に設けた複数のサーバエージェントと、ユーザアプリケーション毎に設けた複数のユーザエージェントとを備えたバスシステムの制御方法であって、
前記サーバエージェントが、対応する前記サーバアプリケーションと通信する工程と、通信先の前記サーバエージェントもしくは前記ユーザエージェントを決定する工程と、決定された前記サーバエージェントもしくは前記ユーザエージェントと通信する工程と、
前記ユーザエージェントが、対応する前記ユーザアプリケーションと通信する工程とを備えたことを特徴とするバス制御方法。
（付記１１）
前記サーバエージェントにおける通信先の前記サーバエージェントもしくは前記ユーザエージェントを決定する工程は、前記サーバアプリケーションから受信したサービスＵＲＩに基づいて辞書に問い合わせることで、配信先となる前記ユーザアプリケーションに対応する前記ユーザエージェントを通信先として決定することを特徴とする付記１０に記載のバス制御方法。
（付記１２）
前記サーバエージェントにおける通信先の前記サーバエージェントもしくは前記ユーザエージェントを決定する工程は、前記サーバアプリケーションから受信したサービスＵＲＩに基づいて辞書に問い合わせることで、同サービスを提供する他のサーバエージェントを通信先として決定し、
前記サーバエージェントにおける前記サーバエージェントもしくは前記ユーザエージェントと通信する工程は、決定されたサーバエージェントに配信コンテンツもしくはそのＵＲＩのレプリカを送信することで、当該サーバエージェントから他のユーザエージェントに配信コンテンツもしくはそのＵＲＩを送信させることを特徴とする付記１１に記載のバス制御方法。
（付記１３）
前記ユーザエージェントにおける通信先の前記サーバエージェントもしくは前記ユーザエージェントを決定する工程は、前記ユーザアプリケーションから受信したシナリオの記述に基づいてシナリオ解釈部に問い合わせることで、当該シナリオを処理可能な前記サーバアプリケーションに対応する前記サーバエージェントを通信先として決定することを特徴とする付記７に記載のバス制御方法。
（付記１４）
サーバアプリケーション毎に設けた複数のサーバエージェントと、ユーザアプリケーション毎に設けた複数のユーザエージェントとを備えたバスシステムの制御プログラムであって、
前記バスシステムを構成するコンピュータを、
前記サーバエージェントにつき、対応する前記サーバアプリケーションと通信する手段、前記サーバエージェントもしくは前記ユーザエージェントと通信する手段、および、通信先の前記サーバエージェントもしくは前記ユーザエージェントを決定する手段として機能させ、
前記ユーザエージェントにつき、対応する前記ユーザアプリケーションと通信する手段、前記サーバエージェントもしくは前記ユーザエージェントと通信する手段、および、通信先の前記サーバエージェントもしくは前記ユーザエージェントを決定する手段として機能させるバス制御プログラム。
（付記１５）
前記ユーザエージェントにおける通信先の前記サーバエージェントもしくは前記ユーザエージェントを決定する手段は、前記ユーザアプリケーションから受信したサービスＵＲＩから辞書に問い合わせることで、負荷に余裕のある前記サーバエージェントを通信先として決定する付記１４に記載のバス制御プログラム。
（付記１６）
前記ユーザエージェントにおける通信先の前記サーバエージェントもしくは前記ユーザエージェントを決定する手段は、前記ユーザアプリケーションから受信したサービスＵＲＩに基づいて辞書に問い合わせることで、通信先候補の前記サーバエージェントの中から巡回的に前記サーバエージェントを通信先として決定する付記１５に記載のバス制御プログラム。
（付記１７）
前記サーバエージェントにおける通信先の前記サーバエージェントもしくは前記ユーザエージェントを決定する手段は、前記サーバアプリケーションから受信したサービスＵＲＩに基づいて辞書に問い合わせることで、配信先となる前記ユーザアプリケーションに対応する前記ユーザエージェントを通信先として決定する付記１４に記載のバス制御プログラム。
（付記１８）
前記サーバエージェントにおける通信先の前記サーバエージェントもしくは前記ユーザエージェントを決定する手段は、前記サーバアプリケーションから受信したサービスＵＲＩに基づいて辞書に問い合わせることで、同サービスを提供する他のサーバエージェントを通信先として決定し、
前記サーバエージェントにおける前記サーバエージェントもしくは前記ユーザエージェントと通信する手段は、決定されたサーバエージェントに配信コンテンツもしくはそのＵＲＩのレプリカを送信することで、当該サーバエージェントから他のユーザエージェントに配信コンテンツもしくはそのＵＲＩを送信させる付記１７に記載のバス制御プログラム。
（付記１９）
前記ユーザエージェントにおける通信先の前記サーバエージェントもしくは前記ユーザエージェントを決定する手段は、前記ユーザアプリケーションから受信したシナリオの記述に基づいてシナリオ解釈部に問い合わせることで、当該シナリオを処理可能な前記サーバアプリケーションに対応する前記サーバエージェントを通信先として決定する付記１４に記載のバス制御プログラム。

従来のＷｅｂ版ネットワークシステムの構成例を示す図である。従来のバスシステムの構成例を示す図（その１）である。従来のバスシステムの構成例を示す図（その２）である。従来のバスシステムの構成例を示す図（その３）である。本発明の一実施形態にかかるバスシステムの構成例を示す図である。エージェントの構成例を示す図である。保持データの例を示す図である。プル型に適用した場合のＮＳ辞書の例を示す図である。プル型における動作例を示す図である。プル型の処理例を示すシーケンス図である。エージェント内の処理を詳細に示すシーケンス図である。プッシュ型に適用した場合のＮＳ辞書の例を示す図である。プッシュ型における動作例を示す図である。プッシュ型の処理例を示すシーケンス図である。シナリオに対応した動作例を示す図である。シナリオ解釈部内部の対応テーブルの例を示す図である。

符号の説明

１００バスシステム
１１０エージェント管理部
１２０ＮＳ辞書
１３０シナリオ解釈部
Ａ１〜Ａ３、Ｂ１、Ｃ１サーバアプリケーション
Ｕ１〜Ｕ４ユーザアプリケーション
ａ１〜ａ３、ｂ１、ｃ１サーバエージェント
ｕ１〜ｕ４ユーザエージェント
１１アプリケーション向け通信部
１２エージェント向け通信部
１３ＮＳ辞書問い合わせ部
１４ＵＲＩ変換部
１５保持データ

Claims

サーバアプリケーション毎に設けた複数のサーバエージェントと、ユーザアプリケーション毎に設けた複数のユーザエージェントとを備え、
前記サーバエージェントは、対応する前記サーバアプリケーションと通信する手段と、前記サーバエージェントもしくは前記ユーザエージェントと通信する手段と、通信先の前記サーバエージェントもしくは前記ユーザエージェントを決定する手段とを有し、
前記ユーザエージェントは、対応する前記ユーザアプリケーションと通信する手段と、前記サーバエージェントもしくは前記ユーザエージェントと通信する手段と、通信先の前記サーバエージェントもしくは前記ユーザエージェントを決定する手段とを有することを特徴とするバスシステム。
前記ユーザエージェントにおける通信先の前記サーバエージェントもしくは前記ユーザエージェントを決定する手段は、前記ユーザアプリケーションから受信したサービスＵＲＩから辞書に問い合わせることで、負荷に余裕のある前記サーバエージェントを通信先として決定することを特徴とする請求項１に記載のバスシステム。
前記ユーザエージェントにおける通信先の前記サーバエージェントもしくは前記ユーザエージェントを決定する手段は、前記ユーザアプリケーションから受信したサービスＵＲＩに基づいて辞書に問い合わせることで、通信先候補の前記サーバエージェントの中から巡回的に前記サーバエージェントを通信先として決定することを特徴とする請求項２に記載のバスシステム。
前記サーバエージェントにおける通信先の前記サーバエージェントもしくは前記ユーザエージェントを決定する手段は、前記サーバアプリケーションから受信したサービスＵＲＩに基づいて辞書に問い合わせることで、配信先となる前記ユーザアプリケーションに対応する前記ユーザエージェントを通信先として決定することを特徴とする請求項１に記載のバスシステム。
前記サーバエージェントにおける通信先の前記サーバエージェントもしくは前記ユーザエージェントを決定する手段は、前記サーバアプリケーションから受信したサービスＵＲＩに基づいて辞書に問い合わせることで、同サービスを提供する他のサーバエージェントを通信先として決定し、
前記サーバエージェントにおける前記サーバエージェントもしくは前記ユーザエージェントと通信する手段は、決定されたサーバエージェントに配信コンテンツもしくはそのＵＲＩのレプリカを送信することで、当該サーバエージェントから他のユーザエージェントに配信コンテンツもしくはそのＵＲＩを送信させることを特徴とする請求項４に記載のバスシステム。
前記ユーザエージェントにおける通信先の前記サーバエージェントもしくは前記ユーザエージェントを決定する手段は、前記ユーザアプリケーションから受信したシナリオの記述に基づいてシナリオ解釈部に問い合わせることで、当該シナリオを処理可能な前記サーバアプリケーションに対応する前記サーバエージェントを通信先として決定することを特徴とする請求項１に記載のバスシステム。
サーバアプリケーション毎に設けた複数のサーバエージェントと、ユーザアプリケーション毎に設けた複数のユーザエージェントとを備えたバスシステムの制御方法であって、
前記ユーザエージェントが、対応する前記ユーザアプリケーションと通信する工程と、通信先の前記サーバエージェントもしくは前記ユーザエージェントを決定する工程と、決定された前記サーバエージェントもしくは前記ユーザエージェントと通信する工程と、
前記サーバエージェントが、対応する前記サーバアプリケーションと通信する工程とを備えたことを特徴とするバス制御方法。
前記ユーザエージェントにおける通信先の前記サーバエージェントもしくは前記ユーザエージェントを決定する工程は、前記ユーザアプリケーションから受信したサービスＵＲＩから辞書に問い合わせることで、負荷に余裕のある前記サーバエージェントを通信先として決定することを特徴とする請求項７に記載のバス制御方法。
前記ユーザエージェントにおける通信先の前記サーバエージェントもしくは前記ユーザエージェントを決定する工程は、前記ユーザアプリケーションから受信したサービスＵＲＩに基づいて辞書に問い合わせることで、通信先候補の前記サーバエージェントの中から巡回的に前記サーバエージェントを通信先として決定することを特徴とする請求項８に記載のバス制御方法。
サーバアプリケーション毎に設けた複数のサーバエージェントと、ユーザアプリケーション毎に設けた複数のユーザエージェントとを備えたバスシステムの制御方法であって、
前記サーバエージェントが、対応する前記サーバアプリケーションと通信する工程と、通信先の前記サーバエージェントもしくは前記ユーザエージェントを決定する工程と、決定された前記サーバエージェントもしくは前記ユーザエージェントと通信する工程と、
前記ユーザエージェントが、対応する前記ユーザアプリケーションと通信する工程とを備えたことを特徴とするバス制御方法。
前記サーバエージェントにおける通信先の前記サーバエージェントもしくは前記ユーザエージェントを決定する工程は、前記サーバアプリケーションから受信したサービスＵＲＩに基づいて辞書に問い合わせることで、配信先となる前記ユーザアプリケーションに対応する前記ユーザエージェントを通信先として決定することを特徴とする請求項１０に記載のバス制御方法。
前記サーバエージェントにおける通信先の前記サーバエージェントもしくは前記ユーザエージェントを決定する工程は、前記サーバアプリケーションから受信したサービスＵＲＩに基づいて辞書に問い合わせることで、同サービスを提供する他のサーバエージェントを通信先として決定し、
前記サーバエージェントにおける前記サーバエージェントもしくは前記ユーザエージェントと通信する工程は、決定されたサーバエージェントに配信コンテンツもしくはそのＵＲＩのレプリカを送信することで、当該サーバエージェントから他のユーザエージェントに配信コンテンツもしくはそのＵＲＩを送信させることを特徴とする請求項１１に記載のバス制御方法。
前記ユーザエージェントにおける通信先の前記サーバエージェントもしくは前記ユーザエージェントを決定する工程は、前記ユーザアプリケーションから受信したシナリオの記述に基づいてシナリオ解釈部に問い合わせることで、当該シナリオを処理可能な前記サーバアプリケーションに対応する前記サーバエージェントを通信先として決定することを特徴とする請求項７に記載のバス制御方法。