JP2015125639A - Data distribution system - Google Patents

Abstract

PROBLEM TO BE SOLVED: To use pubsub type communication and redistribute even about secondary data which is acquired by processing of data distributed by the pubsub type communication.SOLUTION: A data distribution system 1 distributes data by pubsub type communication and comprises: a business server 30 for distributing various kinds of pieces of data by publishing; and the business server 30 or a client terminal 40 for acquiring data whose kind corresponds to a topic which is designated in advance as an object of a subscription. The business server 30 acquires data distributed by other business server 30, and publishes secondary data which is acquired by using the data and whose kind is same or different from the data for distribution.

Description

  The present invention relates to a technique for distributing data to information processing apparatuses, and in particular, a technique effective when applied to a data distribution system that distributes various types of information to a plurality of information processing apparatuses by publish / subscribe communication. It is about.

  In an information processing system consisting of components such as multiple applications, subsystems, and servers, data communication and message exchange are usually performed between components. The peer-to-peer (P2P) type is generally performed by knowing information such as the IP address of the network.

  On the other hand, for example, when an internal system of a securities company distributes a large amount of various types of data to a large number of other parties, such as when distributing the current market price information of each stock acquired from an exchange, etc. May be a so-called publish / subscribe type messaging method (hereinafter sometimes abbreviated as “pub sub type”). In the distribution of pub-sub data, if a user registers in advance (subscribes) for a topic that he / she wants in advance, the data corresponding to the topic issued by the data distribution source (publish) In some cases, the user can acquire only the data.

  As a technology related to pub-sub communication, for example, in Japanese Patent Laid-Open No. 2009-110165 (Patent Document 1), a proxy pub-sub communication node is arranged between a communication node that performs pub-sub communication and a broker that executes message distribution. A technique for issuing a pub sub request to a broker on behalf of a plurality of connected communication nodes is described. Here, when the proxy pub subserver receives a subscribe request on the same topic from multiple nodes, it issues a subscribe request to the broker only when the first request is received, and when a subsequent subscribe request is accepted Just remember which communication node received it, and when you receive a publish message for that topic from the broker, select one of the communication nodes that issued the stored subscribe request. Distribution in the pub sub-communication to realize a load distribution configuration on the subscribe side.

JP 2009-110165 A

  In the pub sub-type communication, the traffic volume as a whole can be compressed when data is distributed to a large number of counterparts, compared to the P2P type communication. That is, in the P2P type, it is necessary to send all the data to be transmitted for each communication session with the other party to be transmitted, whereas in the pub sub type, the issuer (publisher) on the transmission side once transmits the data to be transmitted. Once sent out, each user (subscriber) who wants to acquire the data can acquire and receive it.

  Previously, data distributed by pub-sub communication was targeted for “raw data” that would basically be required by any user, such as the market price in an internal system of a securities company. . However, for example, data obtained by processing business data, such as profit and loss and position information calculated using “raw data” such as market prices, can be shared by multiple users. There is a request to do.

  At this time, for example, the processed data is registered in a shared database or the like, and each target user periodically checks the database for updated information and refers to it, or data is registered and updated in the database. It is conceivable to take a method of notifying the target user individually to the effect. However, with such a method, there is no problem when the number of users and client terminals that desire each processed data is small, but when the number increases, processed data flows on the network as much as the user requests. As a result, traffic as a whole may increase and hinder smooth operation.

  Accordingly, an object of the present invention is to provide a data distribution system that redistributes secondary data obtained by processing or the like from data distributed by pub-sub communication using pub-sub communication.

  The above and other objects and novel features of the present invention will be apparent from the description of this specification and the accompanying drawings.

  Of the inventions disclosed in this application, the outline of typical ones will be briefly described as follows.

  A data distribution system according to a typical embodiment of the present invention is a data distribution system that distributes data by publish / subscribe communication via a network, and distributes data by publishing different types of data 1 One or more first information processing apparatuses and one or more second information for acquiring data of a type corresponding to a topic designated in advance as a subscription target among one or more types of distributed data And the first information processing apparatus is designated in advance as a subscription target among one or more types of data distributed by the other first information processing apparatus. Data of the type corresponding to the topic is acquired, and secondary data of the same type or different from the data obtained by using the data. It is possible to deliver by publishing.

  Among the inventions disclosed in the present application, effects obtained by typical ones will be briefly described as follows.

  In other words, according to the representative embodiment of the present invention, it is possible to redistribute secondary data obtained by processing or the like from data distributed by pub-sub communication using pub-sub communication. Since efficient data distribution is possible, real-time cooperation between a large number of users with respect to a large amount of data becomes possible.

It is the figure which showed the outline | summary about the structural example of the data delivery system which is one embodiment of this invention. It is the figure which showed the outline | summary about the structural example at the time of applying the data delivery system in one embodiment of this invention to the securities front system. (A) (b) is the figure which showed the outline | summary about the example of delivery and acquisition of the data to the messaging bus | bath in one embodiment of this invention.

  Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings. Note that components having the same function are denoted by the same reference symbols throughout the drawings for describing the embodiment, and the repetitive description thereof will be omitted.

  A data distribution system according to an embodiment of the present invention is an information processing system that distributes data to a plurality of users (servers and clients) by pub-sub communication, and performs processing based on the received data. The secondary data obtained by the above is also redistributed by pub-sub communication using a plurality of messaging buses logically configured according to the type of data. As a result, when data is linked between users, traffic is compressed to improve processing efficiency, and a large amount of data can be linked in real time between a large number of users.

<System configuration>
FIG. 1 is a diagram showing an outline of a configuration example of a data distribution system 1 according to an embodiment of the present invention. The data distribution system 1 includes one or more business servers 30 (30a to c in the example of FIG. 1) that can distribute (publish (issue)) and receive (subscribe (subscribe)) data by pub-sub communication. On the other hand, similarly, one or more client terminals 40 that can receive (subscribe) data by pub-sub communication are connected so as to be able to communicate via a network (not shown).

  Each business server 30 and client terminal 40 uses one or more types of messaging buses 10 logically configured on a network (not shown) by software or the like that implements pub-sub communication to distribute or receive data. It can be carried out. As will be described later, the messaging bus 10 is handled as an individual bus that is logically configured according to the type of data to be distributed, independent of the actual configuration of the network.

  Each business server 30 is a server system configured by an information processing apparatus such as a server device or a virtual server built on a cloud computing service, for example, middleware operating on an OS (Operating System) (not shown), or It has a pub sub-unit 31 and a business application (Apl) 32 implemented as software operating on these.

  The pub sub-unit 31 logically configures the messaging bus 10 and also sets a publishing function for distributing data to be distributed on the messaging bus 10 as a message and data distributed on the messaging bus 10 by a user in advance. A subscribing function for reading the data from the messaging bus 10 when the data matches the desired topic. The pub sub unit 31 can be implemented by appropriately using, for example, a general commercial software program that provides a pub sub communication function.

  The business Ap 32 is an application program that processes various business logics, and has a function of acquiring data from the messaging bus 10 via the pub sub unit 31 and using it as necessary. In addition, when secondary data obtained by processing using the acquired data needs to be shared with other components, it is automatically transferred to the messaging bus 10 via the pub sub-unit 31. Or, it has a function to redistribute manually.

  The data that the business server 30 delivers to the messaging bus 10 via the pub sub unit 31 is not limited to the secondary data as described above. Similar to the prior art, for example, primary data originally generated by the business Ap32 or the like may be distributed, or the data acquired from the external data distribution source 20 via the network as a message broker may be used as it is. It may be redistributed. For example, in a securities company system, a server having a function of acquiring information on the market price of each issue from an exchange and distributing it to an in-house system is applicable.

  Accordingly, it is not necessary for the business Ap32 to implement processing corresponding to both the publish function and the subscribe function in the pub / sub communication, and only one of them may be implemented according to the processing content. In the case of having a publish function, every time data to be distributed is generated or updated in the business Ap 32 or the like, the data is distributed on the messaging bus 10 via the pub sub unit 31.

  The client terminal 40 is configured by an information processing apparatus such as a PC (Personal Computer), for example, and has a subscribe function in pub subcommunication (not shown) and can acquire data from the messaging bus 10. That is, when only the data to be distributed is acquired, each client terminal 40 can acquire the data directly from the messaging bus 10 without using the business server 30.

  On the other hand, the client terminal 41 (41c in the example of FIG. 1) connects to the business server 30 (30c in the example of FIG. 1), acquires data through the business Ap32, and also through the business Ap32 and the pub sub unit 31. Data can be distributed. That is, when data is distributed on the messaging bus 10, each client terminal 41 is not directly distributed to the messaging bus 10, but is limited to be distributed via the business server 30. Data can be serialized and distributed by the Ap32 or the pub sub-unit 31 to level the traffic.

  In the example of FIG. 1 described above, the business server 30a acquires data from the data distribution source 20 via the network and distributes the data on the messaging bus 10 (white arrow in the figure). In addition, the business servers 30b and 30c acquire data from the messaging bus 10 and distribute secondary data onto the same or different messaging bus 10. Here, the business server 30c can also serialize the data designated from the plurality of client terminals 41c and distribute it on the messaging bus 10. Also, each client terminal 40 can obtain data directly from one or more messaging buses 10.

<Specific example>
FIG. 2 is a diagram showing an outline of a configuration example when the data distribution system 1 is applied to the securities front system. The securities front system / equity front system accepts inquiries for buying and selling stocks (relative transactions) from customers at securities companies, etc., and accepts purchase orders based on the results of pricing. This is a front-end system that supports operations related to the buying and selling of securities, such as cross-transactions with one's own orders and execution against exchanges.

  In the example of FIG. 2, the messaging bus 10 includes, for example, a production bus 10a, a position bus 10b, a profit / loss bus 10c, a market value bus 10d, and the like. As described above, these multiple buses are handled as individual buses that are logically configured according to the type of data to be distributed, independently of the actual configuration of the network. Examples of the business server 30 include an exchange gateway (GW) 30d, an OMS (Order Management System) server 30e, an unwind server 30f, a position server 30g, a pricing server 30h, a theoretical value server 30i, and It has a profit / loss server 30j and the like, and has an exchange system 51 and a lending system 52 as external systems.

  In the configuration of the example in FIG. 2, the market price data that is “raw data” distributed to the market price bus 10d is acquired by the exchange GW 30d from the exchange system 51 via a network (not shown) and placed on the market price bus 10d. To deliver.

  In order management work performed by the OMS server 30e and the client terminal 41e connected thereto, stock order data input and transmitted from a plurality of client terminals 41e used by traders and the like are serialized on the OMS server 30e. And sent to the exchange system 51 via the exchange GW 30d and executed. On the other hand, the exchange data GW30d acquires the result data including the result information for the order from the exchange system 51, and distributes the result data on the completion bus 10a. Therefore, it can be said that the result data has characteristics close to “raw data”.

  The delivered result data is acquired from the work bus 10a by each business server 30 or system that requires (subscribes to) the OMS server 30e, a position server 30g, and a pricing server 30h described later. In order to obtain the result data by accessing the result bus 10a, each user designates “result data” as the topic of the data to be subscribed. As a result, the result bus 10a to which “result data” is distributed can be logically configured on the network to which various data is distributed. The same applies to the position bus 10b, profit / loss bus 10c, and market value bus 10d.

  In the pricing process performed by the pricing server 30h and the client terminal 41h connected thereto, the position data (balance and book value) of the target brand, which is required when pricing for inquiries from customers, etc., is performed on the position bus 10b. Get from. A trader or the like obtains necessary information from the pricing server 30h by the client terminal 41h and performs pricing processing. When performing a cross transaction within the position of a securities company, a cross order is transmitted to the exchange system 51 via the exchange GW 30d and executed. Further, as described above, the exchange data for the cross order is acquired by the exchange GW 30d from the exchange system 51, distributed on the work bus 10a, and the business server 30 or the like that requires this can be obtained from the bus 10a. get.

  The position management process is mainly performed by the position server 30g and the profit / loss server 30j. The position server 30g calculates and updates position data (balance and book value) as secondary data from the result data acquired from the result bus 10a, and redistributes the position data onto the position bus 10b. When calculating the position data, the lending system 52 may acquire information on its own stock. This lending system 52 is, for example, a system for borrowing shares from an external trust bank or securities company, etc. in the case of selling marginally due to a shortage of its own inventory for a large number of customer purchase orders. is there.

  The profit / loss server 30j also calculates profit / loss data as secondary data from the position data acquired from the position bus 10b and the market price data acquired from the market price bus 10d, and redistributes it on the profit / loss bus 10c. Furthermore, in order to obtain information on the theoretical value of the stock price, the theoretical value is obtained by acquiring the market price data from the market price bus 10d, calculating the theoretical value as secondary data from the market price data, and redistributing it on the market price bus 10d. You may have the server 30i.

  The client terminal 41g for the position server 30g performs a process of updating and maintaining the position data managed on the position server 30g. On the other hand, the client terminal 40 for referring to the position directly acquires the position data from the position bus 10b, directly acquires the profit / loss data from the profit / loss bus 10c, and directly acquires the market price data and the theoretical value from the market price bus 10d. To display each data on the screen.

  For example, in order to reduce the risk of price fluctuations of stocks in order to unwind (rewind) the position when its own position is updated due to a relative transaction with the customer, In some cases, position hedging such as hedging with futures is performed. As a preparation process for the unwind process, for example, based on information such as an instruction input from a trader or the like via the client terminal 41f, the unwind server 30f sends the order data to be netted or merged to the OMS server 30e. And position data is acquired from the position bus 10b. After performing the netting or merging process based on the acquired order data, the data on the OMS server 30e is updated based on the order data. The updated position data is redistributed on the position bus 10b.

  In this way, not only the distribution of “raw data” such as market price data, but also secondary data such as position data and profit / loss data processed and generated on the business server 30 such as the position server 30g and the profit / loss server 30j, Instead of being sent directly to the user who needs it (obtained directly by the user who needs it), it is redistributed on the messaging bus 10 in the same way as “raw data”. As a result, even when there are many types, numbers, and combinations of data to be distributed, distribution sources, and users, data distribution becomes efficient and real-time cooperation becomes possible. .

  Note that the secondary data such as position data and profit / loss data processed and generated on the business server 30 may be very large. In this case, if the secondary data is redistributed directly on the messaging bus 10, the load on the messaging bus 10 may increase.

  In the present embodiment, in order to avoid this, the secondary data is not directly redistributed on the messaging bus 10, but the secondary data itself is held on the database of the business server 30 that generated the secondary data. In addition, it is assumed that only key item data for accessing the database and referring to the secondary data can be distributed on the messaging bus 10. Each user who needs the secondary data can access the target business server 30 based on the value of the key item acquired from the messaging bus 10 and individually acquire the data. With such a mechanism, it is possible to further reduce the load on the messaging bus 10 as much as possible and further improve the efficiency of data distribution.

<Topic settings>
In the pub sub-type communication, it is generally possible to acquire only data having attributes and contents that match a desired topic registered in advance by the user for data distributed on the messaging bus 10. This reduces the total traffic volume by acquiring only necessary data at the subscriber (subscriber) while reducing the burden and burden of specifying the other party at the delivery side (publisher). Is possible.

  FIG. 3 is a diagram showing an outline of an example of distribution and acquisition of data to the messaging bus 10. FIG. 3A shows, as an example, a case where the result data 11 is distributed on the result bus 10a, and a brand code (“brand A” in the example of FIG. 3) is set in the result data 11. Yes. Here, as described above, each user such as a trader (the client terminal 40 in the example of FIG. 3) accesses the completion bus 10a and acquires the completion data 11 as a topic to be subscribed. “Data” is designated, but hereinafter, description of the topic that specifies the messaging bus 10 to be accessed (that is, the topic that specifies the type of data to be subscribed) will be omitted.

  In order for each user (subscriber) to acquire the product data 11 having specific attributes and contents, it is necessary to specify a subtopic 12 for specifying the product data 11. Here, when each user designates only “brand code” as subtopic 12, if “brand A” is a brand with high liquidity, for example, many traders place orders. As shown in FIG. 3 (a), many client terminals 40 obtain the result data 11 of “brand A” including those ordered by other traders from the result bus 10a. Traffic on the entire network will increase.

  Therefore, in the present embodiment, the subtopics 12 to be subscribed designated by each user are hierarchically structured, and the topic having higher effect of narrowing down is set as the topic of the higher hierarchy, thereby identifying the necessary data. It is easy, quick and reliable, prevents unnecessary data from being read, prevents the increase of traffic as a whole, and enables efficient data distribution.

  In FIG. 3B, as an example, in the same manner as in FIG. 3A, each user has a “customer name” as a subtopic 12 (in the example of FIG. 3, “customer a”, “customer”). b), etc., and a topic is designated hierarchically in the format of “brand code” (in the example of FIG. 3, “brand A”, “brand B”, etc.). In this case, in order from the topic specified in the upper hierarchy, it is determined whether or not the result data 11 delivered to the result bus 10a matches, and when all the topics in the lowest layer are matched, the result data 11 is acquired. .

  For example, as shown in FIG. 3B, when the result data 11 (“brand code” is “brand A”) distributed to the work bus 10a is order data for “customer a”, the subtopic 12 Only the client terminal 40 that designates “customer a” as the “customer name” (that is, the trader who performed the ordering process for “customer a”) is the target from which the result data 11 can be obtained. Here, the upper left client terminal 40 in FIG. Further, in the subtopic 12 specified here, since “brand A” is designated as the “brand code”, the client terminal 40 acquires the result data 11 from the result bus 10a. .

  On the other hand, for the other client terminals 40, it is immediately determined that the result data 11 is not subject to acquisition, the subsequent determination processing is skipped, and acquisition of the result data 11 is not performed. Efficiency can be improved without unnecessary processing.

  In this way, when specifying the subtopic 12 to be subscribed, it can be specified in a hierarchical structure, and in the upper hierarchy, for example, the customer name in the result data, the ID of the trader who made the order, etc. An attribute having a higher narrowing effect in relation to the characteristic, that is, an attribute having a smaller number of corresponding data among the target data is designated. This makes it possible for each user (subscriber) to efficiently and reliably identify and specify the data to be subscribed to, and prevent unnecessary data from being read, preventing the increase in traffic as a whole and efficiently. Data can be distributed.

  In the example of FIG. 3B, the hierarchical structure of the subtopic 12 has two layers of “customer name” and “brand code”, but it is natural that the structure of three or more layers may be used. Further, in the case where the efficiency is sufficiently improved, a single-layer structure as shown in FIG.

  As described above, according to the data distribution system 1 which is an embodiment of the present invention, in the information processing system that distributes data to a plurality of users by pub-sub type communication, the received data Secondary data obtained by processing or the like based on the data can be redistributed by pub-sub type communication using a plurality of messaging buses 10 logically configured according to the type (topic) of the data. .

  In addition, when each user specifies a subtopic to be subscribed to, it can be specified in a hierarchical structure, and moreover, by specifying an attribute that is more effective in narrowing down in relation to the characteristics of the target data, It is possible for each user to identify and specify data to be subscribed efficiently and reliably. With these configurations, it is possible to suppress reading unnecessary data, prevent an increase in traffic as a whole, and efficiently distribute data.

  Also, the secondary data obtained by processing in the information processing system can be re-distributed by pub-sub type communication that does not specify the other party, so that the interface of the data to be distributed can be standardized and the user's Extensibility such as addition can be greatly improved.

  As mentioned above, the invention made by the present inventor has been specifically described based on the embodiments. However, the present invention is not limited to the above-described embodiments, and various modifications can be made without departing from the scope of the invention. Needless to say. For example, the above-described embodiment has been described in detail for easy understanding of the present invention, and is not necessarily limited to the one having all the configurations described. In addition, it is possible to add, delete, and replace other configurations for a part of the configuration of the above-described embodiment.

  The present invention is applicable to a data distribution system that distributes various types of information to a plurality of information processing apparatuses through publish / subscribe communication.

1 ... Data distribution system,
10 ... Messaging bus, 11 ... Result data, 12 ... Subtopic,
20 ... data distribution source,
30a-c ... business server, 30d ... exchange gateway (GW), 30e ... OMS server, 30f ... unwind server, 30g ... position server, 30h ... pricing server, 30i ... theoretical value server, 30j ... profit / loss server, 31 ... Pub sub part, 32 ... Business application (Apl),
40, 41c, 41e-h ... client terminal,
51 ... Exchange system, 52 ... Lending system.

Claims (3)

A data distribution system for distributing data by publish / subscribe communication via a network,
One or more first information processing devices that distribute by publishing different types of data,
One or more second information processing apparatuses that acquire data of a type corresponding to a topic designated in advance as a target of subscription among one or more types of distributed data;
Have
The first information processing apparatus acquires data of a type corresponding to a topic designated in advance as a subscription target from one or more types of data distributed by the other first information processing apparatus. A data distribution system capable of distributing by publishing secondary data of the same type or different from the data obtained by using the data. The data distribution system according to claim 1,
The topic further includes one or more subtopics for identifying data having an attribute to be subscribed among types of data to be subscribed.
The data distribution system according to claim 1, wherein the subtopic has a hierarchical structure in which the number of corresponding data is lower. In the data distribution system according to claim 1 or 2,
The types of data to be distributed are: market value data for each stock issue, performance data for stock orders at a securities company, profit / loss data on trading of stocks at a securities company, and position data for each stock issue at a securities company. A data distribution system including any one or more.

Images