(57)【要約】【課題】パブサブ型通信により配信されたデータから加工等により得られた二次データについてもパブサブ型の通信を利用して再配信する。【解決手段】パブサブ型通信によりデータを配信するデータ配信システム１であって、それぞれ異なる種類のデータをパブリッシュすることにより配信する業務サーバ３０と、配信されたデータのうち、サブスクライブの対象として予め指定されたトピックに該当する種類のデータを取得する業務サーバ３０もしくはクライアント端末４０とを有し、業務サーバ３０は、他の業務サーバ３０により配信されたデータを取得して、当該データを利用して得られた、当該データと同一もしくは異なる種類の二次データをパブリッシュすることにより配信することが可能である。【選択図】図１
2015125639.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを介してパブリッシュ／サブスクライブ型通信によりデータを配信するデータ配信システムであって、
それぞれ異なる種類のデータをパブリッシュすることにより配信する１つ以上の第１の情報処理装置と、
配信された１つ以上の種類のデータのうち、サブスクライブの対象として予め指定されたトピックに該当する種類のデータを取得する１つ以上の第２の情報処理装置と、
を有し、
前記第１の情報処理装置は、他の前記第１の情報処理装置により配信された１つ以上の種類のデータのうち、サブスクライブの対象として予め指定されたトピックに該当する種類のデータを取得して、当該データを利用して得られた、当該データと同一もしくは異なる種類の二次データをパブリッシュすることにより配信することが可能である、データ配信システム。
【請求項２】
請求項１に記載のデータ配信システムにおいて、
前記トピックは、さらに、サブスクライブの対象の種類のデータのうち、サブスクライブの対象とする属性を有するデータを特定するための１つ以上のサブトピックを有し、
前記サブトピックは、該当するデータの数がより少なくなるものを上位とした階層構造を有する、データ配信システム。
【請求項３】
請求項１または２に記載のデータ配信システムにおいて、
配信されるデータの種類は、株式の各銘柄の時価データ、証券会社における株式の発注に対する出来データ、証券会社における株式の売買に関する損益データ、および証券会社における株式の各銘柄のポジションデータのうち、いずれか１つ以上を含む、データ配信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置に対してデータを配信する技術に関し、特に、複数の情報処理装置に対してパブリッシュ／サブスクライブ型の通信により各種情報を配信するデータ配信システムに適用して有効な技術に関するものである。
【背景技術】
【０００２】
複数のアプリケーションやサブシステム、サーバ等のコンポーネントから構成される情報処理システムでは、コンポーネント間でデータの通信やメッセージの授受が行われるのが通常であるが、そこで用いられる通信は、コンポーネント同士が相手方のＩＰアドレス等の情報を知ることで行うピア・ツー・ピア（Ｐ２Ｐ）型が一般的である。
【０００３】
一方で、例えば、証券会社の社内システムが、取引所等から取得した各銘柄の時価の情報を社内に配信する場合など、多種類の多量のデータを、多数の相手方に配信するような場合には、いわゆるパブリッシュ／サブスクライブ型（以下では「パブサブ型」と省略して記載する場合がある）でのメッセージング方法が用いられる場合がある。パブサブ型のデータの配信では、利用者が予め希望するトピックについて申し込みの登録（サブスクライブ（購読））をしておくと、データの配信元が発行（パブリッシュ）するデータについて該当するトピックのものがある場合に、利用者が当該データのみを取得することが可能となる。
【０００４】
パブサブ型の通信に関する技術として、例えば、特開２００９−１１０１６５号公報（特許文献１）には、パブサブ通信を行なう通信ノードとメッセージの配信を実行するブローカとの間に代理のパブサブ通信ノードを配置し、接続されている複数の通信ノードの代理としてブローカに対してパブサブ要求を発行する技術が記載されている。ここでは、代理パブサブサーバが複数ノードから同一のトピックでサブスクライブ要求を受信した場合に、最初の要求を受信した時にのみブローカに対してサブスクライブ要求を発行し、後続のサブスクライブ要求受付時には、どの通信ノードから受信したかを記憶しておくだけにし、ブローカからそのトピックに対するパブリッシュメッセージを受信した場合に、記憶しておいたサブスクライブ要求を発行した複数の通信ノードから一つを選択して配信することで、パブサブ通信において、サブスクライブ側の負荷分散構成を実現する。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００９−１１０１６５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
パブサブ型の通信では、Ｐ２Ｐ型の通信に比べて、データを多数の相手方に配信する際に、全体としてのトラフィック量を圧縮することができる。すなわち、Ｐ２Ｐ型では、送信したい相手方との間の通信セッション毎に、送信したいデータを全て送る必要があるのに対し、パブサブ型では、送信側である発行者（パブリッシャー）が送信したいデータを一度送り出せば、そのデータの取得を希望する利用者（サブスクライバー）がそれぞれこれを取得して受信することができる。
【０００７】
従来は、パブサブ型の通信で配信されるデータは、例えば、証券会社の社内システムにおける時価など、利用者であれば基本的に誰もが必要とするような「生データ」が対象であった。しかし、例えば、時価のような「生データ」に対して、これを利用して算出される損益やポジションの情報など、業務アプリケーション等により加工して得られるデータについても、複数の利用者でシェアしたいという要望がある。
【０００８】
このとき、例えば、加工したデータを共用のデータベース等に登録し、対象の各利用者がそれぞれ当該データベースに対して定期的に更新情報のチェックを行って参照したり、データベースにデータが登録・更新された旨を個別に対象の利用者に対して通知したりする手法をとることが考えられる。しかしながら、このような手法では、それぞれの加工データを希望する利用者やクライアント端末の数が少ない場合は問題は生じないが、多くなってくると利用者の要求分だけネットワーク上に加工データが流れる結果、全体としてのトラフィックが増大してスムーズな運用に支障をきたす可能性がある。
【０００９】
そこで本発明の目的は、パブサブ型通信により配信されたデータから加工等により得られた二次データについてもパブサブ型の通信を利用して再配信するデータ配信システムを提供することにある。
【００１０】
本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。
【課題を解決するための手段】
【００１１】
本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。
【００１２】
本発明の代表的な実施の形態によるデータ配信システムは、ネットワークを介してパブリッシュ／サブスクライブ型通信によりデータを配信するデータ配信システムであって、それぞれ異なる種類のデータをパブリッシュすることにより配信する１つ以上の第１の情報処理装置と、配信された１つ以上の種類のデータのうち、サブスクライブの対象として予め指定されたトピックに該当する種類のデータを取得する１つ以上の第２の情報処理装置と、を有し、前記第１の情報処理装置は、他の前記第１の情報処理装置により配信された１つ以上の種類のデータのうち、サブスクライブの対象として予め指定されたトピックに該当する種類のデータを取得して、当該データを利用して得られた、当該データと同一もしくは異なる種類の二次データをパブリッシュすることにより配信することが可能である。
【発明の効果】
【００１３】
本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。
【００１４】
すなわち、本発明の代表的な実施の形態によれば、パブサブ型通信により配信されたデータから加工等により得られた二次データについてもパブサブ型の通信を利用して再配信することが可能となり、効率的なデータの配信が可能となるため、多種多量なデータについて多数の利用者間でのリアルタイムの連携が可能となる。
【図面の簡単な説明】
【００１５】
【図１】本発明の一実施の形態であるデータ配信システムの構成例について概要を示した図である。
【図２】本発明の一実施の形態におけるデータ配信システムを証券フロントシステムに適用した場合の構成例について概要を示した図である。
【図３】（ａ）（ｂ）は、本発明の一実施の形態におけるメッセージングバスへのデータの配信と取得の例について概要を示した図である。
【発明を実施するための形態】
【００１６】
以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。
【００１７】
本発明の一実施の形態であるデータ配信システムは、パブサブ型の通信によりデータを複数の利用者（サーバおよびクライアント）に対して配信する情報処理システムにおいて、配信を受けたデータに基づいて加工等により得られた二次データについても、データの種類に応じて論理的に構成された複数のメッセージングバスを用いてパブサブ型の通信により再配信するものである。これにより、利用者間でのデータの連携に際してトラフィックを圧縮して処理を効率化し、多種多量なデータについて多数の利用者間でのリアルタイムの連携を可能とする。
【００１８】
＜システム構成＞
図１は、本発明の一実施の形態であるデータ配信システム１の構成例について概要を示した図である。データ配信システム１は、パブサブ型の通信によりデータを配信（パブリッシュ（発行））および受信（サブスクライブ（購読））することができる１つ以上の業務サーバ３０（図１の例では３０ａ〜ｃ）に対して、同様にパブサブ型の通信によりデータを受信（サブスクライブ）することができる１つ以上のクライアント端末４０がそれぞれ図示しないネットワークを介して通信可能なように接続された構成を有する。
【００１９】
各業務サーバ３０やクライアント端末４０は、パブサブ型の通信を実装するソフトウェア等により、図示しないネットワーク上に論理的に構成された１種類以上のメッセージングバス１０を利用して、データの配信もしくは受信を行うことができる。メッセージングバス１０は、ネットワークの実際の構成とは独立して、後述するように、配信されるデータの種類に応じて論理的に構成された個別のバスとして取り扱われるものである。
【００２０】
各業務サーバ３０は、例えば、サーバ機器やクラウドコンピューティングサービス上に構築された仮想サーバなどの情報処理装置により構成されるサーバシステムであり、図示しないＯＳ（Operating System）上で動作するミドルウェア、もしくはこれらの上で動作するソフトウェアとして実装されるパブサブ部３１および業務アプリケーション（Ａｐｌ）３２を有する。
【００２１】
パブサブ部３１は、メッセージングバス１０を論理的に構成するとともに、配信対象のデータをメッセージとしてメッセージングバス１０上に配信するパブリッシュ機能と、メッセージングバス１０上に配信されたデータについて、利用者により予め設定された希望のトピックに合致するデータである場合にこれをメッセージングバス１０から読み出すサブスクライブ機能とを有する。パブサブ部３１は、例えば、パブサブ通信の機能を提供する一般的な商用ソフトウェアプログラムなどを適宜利用して実装することができる。
【００２２】
業務Ａｐｌ３２は、各種のビジネスロジックを処理するアプリケーションプログラムであり、必要に応じてパブサブ部３１を介してメッセージングバス１０からデータを取得してこれを利用する機能を有する。また、取得したデータを利用して加工等により得られた二次データについて、他のコンポーネントとの間で共有する必要がある場合には、これをパブサブ部３１を介してメッセージングバス１０上に自動もしくは手動で再配信する機能を有する。
【００２３】
なお、業務サーバ３０がパブサブ部３１を介してメッセージングバス１０上に配信するデータは、上記のような二次データのみに限られない。従来技術と同様に、例えば、業務Ａｐｌ３２等により原始的に生成した一次データを配信するものであってもよいし、メッセージブローカとして、外部のデータ配信元２０からネットワークを介して取得したデータをそのまま再配信するものであってもよい。例えば、証券会社のシステムにおいて、取引所から各銘柄の時価の情報を取得し、これを社内システムに対して配信する機能を有するサーバなどが該当する。
【００２４】
従って、業務Ａｐｌ３２は、パブサブ通信におけるパブリッシュ機能とサブスクライブ機能の双方に対応する処理を実装している必要はなく、処理内容に応じていずれか一方のみの実装であってもよい。パブリッシュ機能を有する場合は、業務Ａｐｌ３２等において配信対象のデータが生成されたり更新されたりした都度、パブサブ部３１を介してメッセージングバス１０上に配信する。
【００２５】
クライアント端末４０は、例えば、ＰＣ（Personal Computer）などの情報処理装置により構成され、図示しない、パブサブ通信におけるサブスクライブ機能を有して、メッセージングバス１０からデータを取得することができる。すなわち、配信されるデータを取得するのみの場合には、各クライアント端末４０は、それぞれ業務サーバ３０を介さずにメッセージングバス１０から直接データを取得することが可能である。
【００２６】
一方、クライアント端末４１（図１の例では４１ｃ）は、業務サーバ３０（図１の例では３０ｃ）に接続し、業務Ａｐｌ３２を介してデータを取得するとともに、業務Ａｐｌ３２およびパブサブ部３１を介してデータを配信することができる。すなわち、メッセージングバス１０上にデータを配信する場合は、各クライアント端末４１がそれぞれが直接メッセージングバス１０に対して配信するのではなく、業務サーバ３０を介して配信するように制限することで、業務Ａｐｌ３２もしくはパブサブ部３１においてデータをシリアライズして配信し、トラフィックを平準化することができる。
【００２７】
上記の図１の例では、業務サーバ３０ａは、データ配信元２０からネットワーク経由でデータを取得し、これをメッセージングバス１０上に配信することを示している（図中の白色矢印）。また、業務サーバ３０ｂおよび３０ｃは、メッセージングバス１０からデータを取得し、二次データを同一もしくは別のメッセージングバス１０上に配信することを示している。ここで、業務サーバ３０ｃは、複数のクライアント端末４１ｃから指定されたデータをシリアライズしてメッセージングバス１０上に配信することも可能である。また、クライアント端末４０は、それぞれ、１つ以上のメッセージングバス１０から直接データを取得することができる。
【００２８】
＜具体例＞
図２は、データ配信システム１を証券フロントシステムに適用した場合の構成例について概要を示した図である。証券フロントシステム／エクイティフロントシステムは、証券会社等において、顧客からの株式等の売買（相対取引）の引き合いを受け付けてプライシングを行ったり、プライシングの結果に基づいて売買の注文を受け付けて、これを自己の注文との間でクロス取引したり、取引所等に対して執行したりという、有価証券の売買に係る業務を支援するフロントエンドシステムである。
【００２９】
図２の例において、メッセージングバス１０としては、例えば、出来バス１０ａ、ポジションバス１０ｂ、損益バス１０ｃ、時価バス１０ｄなどを有している。これら複数のバスは、上述したように、ネットワークの実際の構成とは独立して、配信されるデータの種類に応じて論理的に構成された個別のバスとして取り扱われるものである。また、業務サーバ３０としては、例えば、取引所ゲートウェイ（ＧＷ）３０ｄ、ＯＭＳ（Order Management System：注文管理システム）サーバ３０ｅ、アンワインドサーバ３０ｆ、ポジションサーバ３０ｇ、プライシングサーバ３０ｈ、理論値サーバ３０ｉ、および損益サーバ３０ｊなどを有し、外部システムとして、取引所システム５１およびレンディングシステム５２などを有する。
【００３０】
図２の例の構成において、時価バス１０ｄに配信する「生データ」である時価データは、例えば、取引所ＧＷ３０ｄが、図示しないネットワークを介して取引所システム５１から取得し、時価バス１０ｄ上に配信する。
【００３１】
ＯＭＳサーバ３０ｅおよびこれに接続されたクライアント端末４１ｅにより行われる注文管理業務では、トレーダー等が利用する複数のクライアント端末４１ｅから入力、送信された株式の発注データは、それぞれＯＭＳサーバ３０ｅ上でシリアライズされ、取引所ＧＷ３０ｄを介して取引所システム５１に送信されて執行される。一方で、発注に対する結果情報を含む出来データは、取引所ＧＷ３０ｄが取引所システム５１から取得し、これを出来バス１０ａ上に配信する。従って、出来データも「生データ」に近い特質を有するといえる。
【００３２】
配信された出来データは、ＯＭＳサーバ３０ｅや、後述するポジションサーバ３０ｇ、プライシングサーバ３０ｈなど、これを必要とする（サブスクライブする）各業務サーバ３０やシステムなどが出来バス１０ａから取得する。出来バス１０ａにアクセスして出来データを取得するには、各利用者が購読対象のデータのトピックとして「出来データ」を指定する。これにより、各種のデータが配信されるネットワーク上で、「出来データ」が配信される出来バス１０ａを論理的に構成することができる。ポジションバス１０ｂ、損益バス１０ｃ、時価バス１０ｄについても同様である。
【００３３】
プライシングサーバ３０ｈおよびこれに接続されたクライアント端末４１ｈにより行われるプライシング処理では、顧客からの引き合い等に対してプライシングする際に必要となる、対象銘柄のポジションデータ（残高および簿価）をポジションバス１０ｂから取得する。トレーダー等は、クライアント端末４１ｈによってプライシングサーバ３０ｈから必要な情報を取得してプライシング処理を行う。証券会社のポジション内でクロス取引を行う場合は、クロス発注が取引所ＧＷ３０ｄを介して取引所システム５１に送信されて執行される。また、クロス発注に対する出来データは、上述のように、取引所ＧＷ３０ｄが取引所システム５１から取得し、これを出来バス１０ａ上に配信し、これを必要とする業務サーバ３０等が出来バス１０ａから取得する。
【００３４】
ポジション管理処理は、主に、ポジションサーバ３０ｇと損益サーバ３０ｊにより行われる。ポジションサーバ３０ｇは、出来バス１０ａから取得した出来データから二次データとしてポジションデータ（残高および簿価）を算出して更新し、ポジションデータをポジションバス１０ｂ上に再配信する。ポジションデータの算出の際には、レンディングシステム５２から、自己の借株の情報を取得するようにしてもよい。このレンディングシステム５２は、例えば、顧客の大量の買い注文に対して、自己の在庫では不足するために信用売りする場合に、外部の信託銀行や証券会社等から借株をするためのシステムである。
【００３５】
また、損益サーバ３０ｊは、ポジションバス１０ｂから取得したポジションデータと、時価バス１０ｄから取得した時価データとから二次データとして損益データを計算して損益バス１０ｃ上に再配信する。さらに、株価の理論値の情報が必要な場合のために、時価バス１０ｄから時価データを取得して、時価データから二次データとして理論値を計算して時価バス１０ｄ上に再配信する理論値サーバ３０ｉを有していてもよい。
【００３６】
ポジションサーバ３０ｇに対するクライアント端末４１ｇは、ポジションサーバ３０ｇ上で管理するポジションデータを更新してメンテナンスする処理を行う。一方、ポジションを参照するためのクライアント端末４０は、ポジションバス１０ｂからポジションデータを直接取得し、また、損益バス１０ｃから損益データを直接取得し、時価バス１０ｄから時価データおよび理論値を直接取得して、それぞれのデータを画面上に表示する。
【００３７】
顧客との相対取引により自己のポジションの更新が行われた場合に、これをアンワインド（巻き戻す）する処理として、例えば、在庫の銘柄の価格変動のリスクを低減するために、現物のポジションの場合は先物でヘッジするなどのポジションヘッジ処理が行われる。このアンワインド処理の準備処理として、例えば、トレーダー等からクライアント端末４１ｆを介して入力された指示等の情報に基づいて、アンワインドサーバ３０ｆは、ネッティングやマージの対象となる注文データをＯＭＳサーバ３０ｅから取得し、さらにポジションデータをポジションバス１０ｂから取得する。取得した注文データに基づいてネッティングやマージ処理を行った後、当該注文データに基づいてＯＭＳサーバ３０ｅ上のデータを更新する。また、更新後のポジションデータをポジションバス１０ｂ上に再配信する。
【００３８】
このように、時価データなどの「生データ」の配信のみに限らず、ポジションサーバ３０ｇや損益サーバ３０ｊなどの業務サーバ３０上で加工や生成されたポジションデータや損益データなどの二次データについて、必要とする利用者に直接送信する（必要とする利用者が直接取得する）のではなく、「生データ」と同様にメッセージングバス１０上に再配信する。これにより、配信されるデータの種類や配信元、利用者についての種類や数、組合せが多数となるような場合であっても、データの配信が効率化され、リアルタイムでの連携が可能となる。
【００３９】
なお、業務サーバ３０上で加工や生成されたポジションデータや損益データなどの二次データについて、これらのデータ自体が非常に大きくなる場合がある。この場合、これらの二次データを直接メッセージングバス１０上に再配信すると、メッセージングバス１０の負荷が高くなってしまう可能性がある。
【００４０】
本実施の形態では、これを回避するため、二次データを直接メッセージングバス１０上に再配信するのではなく、当該二次データ自体は、これを生成した業務サーバ３０のデータベース上に保持しておき、当該データベースにアクセスして二次データを参照するためのキー項目のデータのみをメッセージングバス１０上に配信することができるものとする。当該二次データが必要な利用者は、それぞれ、メッセージングバス１０から取得したキー項目の値に基づいて対象の業務サーバ３０にアクセスして個別にデータを取得することができる。このような仕組みにより、メッセージングバス１０の負荷を可能な限り抑えてデータの配信をより一層効率化することが可能となる。
【００４１】
＜トピックの設定＞
パブサブ型の通信では、一般的に、メッセージングバス１０上に配信されるデータについて、利用者が予め登録しておいた希望のトピックにマッチする属性や内容を有するデータのみを取得可能とする。これにより、配信側（パブリッシャー）において配信時に相手方を指定する等の手間や負荷を低減しつつ、利用者（サブスクライバー）において必要なデータのみを取得することによって全体でのトラフィック量を圧縮することを可能としている。
【００４２】
図３は、メッセージングバス１０へのデータの配信と取得の例について概要を示した図である。図３（ａ）では、例として、出来バス１０ａ上に出来データ１１を配信する場合を示しており、当該出来データ１１には銘柄コード（図３の例では“銘柄Ａ”）が設定されている。ここで、トレーダー等の各利用者（図３の例ではクライアント端末４０）は、上述したように、出来バス１０ａにアクセスして出来データ１１を取得するためには、購読対象のトピックとして「出来データ」を指定することになるが、以下、アクセスするメッセージングバス１０を特定するトピック（すなわち、購読対象のデータの種類を特定するトピック）の指定については説明を省略するものとする。
【００４３】
各利用者（サブスクライバー）が、出来データ１１のうち特定の属性や内容を有するものを取得するためには、さらに出来データ１１を特定するためのサブトピック１２を指定する必要がある。ここで、サブトピック１２として各利用者が「銘柄コード」のみを指定するものとした場合、“銘柄Ａ”が例えば流動性が高い銘柄であるような場合には、多くのトレーダーが発注している可能性が高く、図３（ａ）に示すように、多くのクライアント端末４０が、他のトレーダーが発注したものも含む“銘柄Ａ”の出来データ１１を出来バス１０ａから取得してしまい、ネットワーク全体としてのトラフィックが増加してしまう。
【００４４】
そこで、本実施の形態では、各利用者が指定する購読対象のサブトピック１２を階層構造化し、上位階層のトピックには絞り込みの効果がより高いトピックを設定することで、必要なデータの識別を容易かつ迅速、確実にし、不要なデータの読み取りを抑止して、全体としてのトラフィックの増大防止と効率的なデータの配信を可能とする。
【００４５】
図３（ｂ）では、例として、図３（ａ）と同様の場合に、各利用者がサブトピック１２としてそれぞれ、上位に「顧客名」（図３の例では“顧客ａ”、“顧客ｂ”など）、下位に「銘柄コード」（図３の例では“銘柄Ａ”、“銘柄Ｂ”など）という形式で階層的にトピックを指定した場合を示している。この場合、上位階層に指定されたトピックから順に、出来バス１０ａに配信される出来データ１１がマッチするか否かを判定し、最下層のトピックまで全てマッチした場合に当該出来データ１１を取得する。
【００４６】
例えば、図３（ｂ）に示すように、出来バス１０ａに配信される出来データ１１（「銘柄コード」が“銘柄Ａ”）が“顧客ａ”についての発注データである場合に、サブトピック１２における「顧客名」として“顧客ａ”を指定しているクライアント端末４０（すなわち、“顧客ａ”についての発注処理を行ったトレーダー等）のみが、当該出来データ１１を取得し得る対象となる。ここでは、図３（ｂ）における上段左側のクライアント端末４０が対象となる。さらに、ここで指定されているサブトピック１２において、「銘柄コード」には“銘柄Ａ”が指定されているため、当該クライアント端末４０は、当該出来データ１１を出来バス１０ａから取得することになる。
【００４７】
一方で、他のクライアント端末４０については、当該出来データ１１は取得の対象外であることが即座に判定され、以降の判定処理をスキップするとともに、当該出来データ１１の取得も行わないことから、無用な処理を行わずに効率化することができる。
【００４８】
このように、購読対象のサブトピック１２を指定する際に、階層構造で指定できるようにし、その上位階層で、例えば、出来データにおける顧客名や、発注を行ったトレーダーのＩＤなど、対象データの特性との関連でより絞り込みの効果が高い属性、すなわち、対象データのうち該当する数がより少なくなる属性を指定するようにする。これにより、各利用者（サブスクライバー）が購読対象のデータを効率的かつ確実に識別・特定することが可能となり、不要なデータの読取りを抑止して、全体としてのトラフィックの増大防止と効率的なデータの配信が可能となる。
【００４９】
なお、図３（ｂ）の例では、サブトピック１２の階層構造を「顧客名」と「銘柄コード」の２層としているが、３層以上の構造であってもよいことは当然である。また、効率化が十分に図られている場合には、図３（ａ）に示すような１層の構造とすることも可能である。
【００５０】
以上に説明したように、本発明の一実施の形態であるデータ配信システム１によれば、パブサブ型の通信によりデータを複数の利用者に対して配信する情報処理システムにおいて、配信を受けたデータに基づいて加工等により得られた二次データを、データの種類（トピック）に応じて論理的に構成された複数のメッセージングバス１０を用いてパブサブ型の通信により再配信することが可能である。
【００５１】
また、各利用者が購読対象のサブトピックを指定する際に、階層構造で指定できるようにし、さらに、対象データの特性との関連でより絞り込みの効果が高い属性を上位階層に指定することで、各利用者が購読対象のデータを効率的かつ確実に識別・特定することが可能である。これらの構成により、不要なデータの読取りを抑止し、全体としてのトラフィックの増大防止と効率的なデータの配信が可能である。
【００５２】
また、情報処理システムにおいて加工等により得られた二次データについても、相手方を特定しないパブサブ型の通信により再配信する構成とすることで、配信するデータのインタフェースの標準化が図られ、利用者の追加などの拡張性を大きく向上させることが可能である。
【００５３】
以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は上記の実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。例えば、上記の実施の形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、上記の実施の形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。
【産業上の利用可能性】
【００５４】
本発明は、複数の情報処理装置に対してパブリッシュ／サブスクライブ型の通信により各種情報を配信するデータ配信システムに利用可能である。
【符号の説明】
【００５５】
１…データ配信システム、
１０…メッセージングバス、１１…出来データ、１２…サブトピック、
２０…データ配信元、
３０ａ〜ｃ…業務サーバ、３０ｄ…取引所ゲートウェイ（ＧＷ）、３０ｅ…ＯＭＳサーバ、３０ｆ…アンワインドサーバ、３０ｇ…ポジションサーバ、３０ｈ…プライシングサーバ、３０ｉ…理論値サーバ、３０ｊ…損益サーバ、３１…パブサブ部、３２…業務アプリケーション（Ａｐｌ）、
４０、４１ｃ、４１ｅ〜ｈ…クライアント端末、
５１…取引所システム、５２…レンディングシステム。
【図１】
2015125639.tif 000003
【図２】
2015125639.tif 000004
【図３】
2015125639.tif 000005