WO2017148278A1 - Fix协议的业务实现方法、装置及系统 - Google Patents

Fix协议的业务实现方法、装置及系统 Download PDF

Info

Publication number
WO2017148278A1
WO2017148278A1 PCT/CN2017/073919 CN2017073919W WO2017148278A1 WO 2017148278 A1 WO2017148278 A1 WO 2017148278A1 CN 2017073919 W CN2017073919 W CN 2017073919W WO 2017148278 A1 WO2017148278 A1 WO 2017148278A1
Authority
WO
WIPO (PCT)
Prior art keywords
fix
service
message
logic
script
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/CN2017/073919
Other languages
English (en)
French (fr)
Inventor
李旭阳
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Alibaba Group Holding Ltd
Original Assignee
Alibaba Group Holding Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Alibaba Group Holding Ltd filed Critical Alibaba Group Holding Ltd
Priority to EP17759129.4A priority Critical patent/EP3425877A4/en
Priority to JP2018545451A priority patent/JP6861720B2/ja
Priority to MYPI2018703004A priority patent/MY183050A/en
Priority to SG11201807245WA priority patent/SG11201807245WA/en
Priority to KR1020187027850A priority patent/KR102136945B1/ko
Priority to AU2017226398A priority patent/AU2017226398B2/en
Publication of WO2017148278A1 publication Critical patent/WO2017148278A1/zh
Priority to PH12018501824A priority patent/PH12018501824B1/en
Priority to US16/115,313 priority patent/US10791070B2/en
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/06—Notations for structuring of protocol data, e.g. abstract syntax notation one [ASN.1]
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44521—Dynamic linking or loading; Link editing at or after load time, e.g. Java class loading
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/06—Asset management; Financial planning or analysis
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/12—Accounting
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/04—Real-time or near real-time messaging, e.g. instant messaging [IM]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/06—Message adaptation to terminal or network requirements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/56—Unified messaging, e.g. interactions between e-mail, instant messaging or converged IP messaging [CPM]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/327—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the session layer [OSI layer 5]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2212/00—Encapsulation of packets

Definitions

  • the present invention relates to the field of Internet technologies, and in particular, to a service implementation method, apparatus, and system for a FIX protocol.
  • the Financial Information eXchange (FIX) protocol is an open message standard that is not controlled by a single entity and can be adapted to suit the business needs of any enterprise to facilitate the exchange of information related to secure transactions.
  • the FIX protocol was first used to support securities transactions in the United States based on direct information flow. With the development of the times, the FIX agreement has further increased the business areas of derivatives and other products, including integrated investment, financial derivatives and foreign exchange transactions. Wait.
  • both parties to the transaction can conduct transactions directly, or they can conduct transactions through a financial service platform (hereinafter referred to as a business platform) built by a third party.
  • a financial service platform hereinafter referred to as a business platform
  • the organization and the business platform should use the same version of the FIX protocol.
  • the FIX protocol version has been developed from FIX 1.0 to FIX 5.0.
  • the FIX 5.0 version protocol separates the session layer protocol from the earlier version from the application layer protocol, and further produces two versions of FIXT X.Y and FIX X.Y.
  • the service platform cannot require or limit the version of the protocol used by the organization.
  • the service platform needs to set up a service environment of all protocol versions, and separately develop the business logic of the transaction for different protocol versions. .
  • the cost of environmental deployment on the service platform side will become higher and higher.
  • the invention provides a service implementation method, device and system for the FIX protocol, which can solve the problem that the cost of deploying the FIX service environment on the service platform side is too high.
  • the present invention provides a service implementation method of the FIX protocol, where the method includes:
  • the service platform receives the FIX message sent by the sending end, and the FIX message is composed of different types of service data, and the service data is in the form of a string;
  • the service script corresponding to the FIX message is searched in the script list according to the service type information in the service data, and the service script corresponding to different FIX protocol versions is saved in the script list, and the business script includes the business logic;
  • the present invention further provides a service implementation method of the FIX protocol, where the method includes:
  • the FIX packet is encapsulated into a FIX message, and the FIX message is composed of different types of service data, and does not include the service logic corresponding to the specific FIX protocol version, and the service data is in the form of a string;
  • the encapsulated FIX message is sent to the service platform, so that the service platform processes the service data according to the business script containing the business logic.
  • the present invention further provides a service implementation apparatus for the FIX protocol, where the apparatus includes:
  • the receiving unit is configured to receive a FIX message sent by the sending end, where the FIX message is composed of different types of service data, and the service data is in a string form;
  • the search unit is configured to search for a service script corresponding to the FIX message in the script list according to the service type information in the service data, where the service script corresponding to different FIX protocol versions is saved in the script list, and the service script includes the service logic;
  • An execution unit that executes a business script to process business data according to business logic.
  • the present invention further provides a service implementation apparatus for the FIX protocol, where the apparatus includes:
  • the processing unit is configured to encapsulate the FIX message into a FIX message, where the FIX message is composed of different types of service data, and does not include the service logic corresponding to the specific FIX protocol version, and the service data is in the form of a string;
  • the sending unit is configured to send the encapsulated FIX message to the service platform, so that the service platform processes the service data according to the service script that includes the business logic.
  • the present invention further provides a service implementation system of a FIX protocol, where the system includes a service platform and a sending end;
  • the service platform includes the apparatus of the above third aspect
  • the transmitting end includes the apparatus of the above fourth aspect.
  • the FIX protocol service implementation method, device, and system provided by the present invention can perform upper layer abstract encapsulation on FIX packets, and obtain a general-purpose FIX message that retains only service data but does not include specific service logic.
  • the strong type of the service in the FIX packet is weakened, so that the FIX message can be applied to any version of the FIX protocol.
  • the business is adopted.
  • the form of the script is configured independently of the FIX protocol code. Different business scripts are developed for different FIX protocol versions, and the FIX transaction service is implemented by using the features of the script language "dynamic configuration" and "dynamic loading".
  • the invention realizes complete decoupling between the business logic and the FIX protocol code, so that the implementation of the business logic no longer depends on the protocol code itself, so the service platform can only deploy one version of the FIX protocol.
  • Implementing all FIX protocol version transactions can greatly reduce the deployment cost of the FIX service environment.
  • FIG. 1 is a flowchart of a service implementation method of a first FIX protocol according to an embodiment of the present invention
  • FIG. 2 is a flowchart of a second FIX protocol service implementation method according to an embodiment of the present invention
  • FIG. 3 is a flowchart of a service implementation method of a third FIX protocol according to an embodiment of the present invention
  • FIG. 4 is a flowchart of a method for parsing a non-standard FIX protocol according to an embodiment of the present invention
  • FIG. 5 is a diagram showing an interaction diagram of a first type of processing FIX message according to an embodiment of the present invention
  • FIG. 6 is a cross-sectional view showing a second processing FIX message according to an embodiment of the present invention.
  • FIG. 7 is a block diagram showing the composition of a service implementation apparatus of a first FIX protocol according to an embodiment of the present invention.
  • FIG. 8 is a block diagram showing the composition of a service implementation apparatus of a second FIX protocol according to an embodiment of the present invention.
  • FIG. 9 is a block diagram showing the composition of a service implementation apparatus of a third FIX protocol according to an embodiment of the present invention.
  • FIG. 10 is a schematic diagram of a service implementation system of the FIX protocol provided by an embodiment of the present invention.
  • the embodiment of the invention discloses a service implementation method of the FIX protocol. As shown in FIG. 1 , the method includes:
  • the service platform receives the FIX message sent by the sending end.
  • the sender is generally an organization, such as a stock exchange, a client of a futures exchange, etc., and the sender sends a packaged FIX message to the service platform.
  • the content of the FIX message is in the form of a string, and involves different types of service data, for example, Transaction amount, transaction time, buyer and seller ID, business type, message length, etc.
  • all data fields (or fields) in the existing FIX protocol can be used as the service data in this embodiment, and within the scope allowed by the existing FIX protocol, the data fields of the transaction parties are customized. It can also be used as the service data. This embodiment does not limit the type and quantity of service data.
  • the FIX message received in this step is a message that is encapsulated by the upper layer and is encapsulated by the upper layer.
  • the existing FIX packet carries the data field in addition to various data fields.
  • the business logic of the transaction business which is essentially constraint control information for various data domains. For example, for the business "buy stock", the specific constraint control information includes at least: determining the purchase target (which stock), determining whether the stock price reaches the preset price, buying several stocks, and how to initiate the purchase operation. Wait. Because the business logic in the FIX message covers the specific constraint control conditions for implementing the transaction service, the FIX message in the prior art is called a strong type of message.
  • the service logic is decoupled from the FIX message and configured separately on the service platform side in the form of a script language.
  • the sender abstracts the data field (service data) into a common class and obtains the service data in the form of a string. This generic type of business data can be applied to any FIX protocol version.
  • the service platform searches for a service script corresponding to the FIX message in the script list according to the service type information in the service data.
  • Each business script records a specific business logic corresponding to a specific FIX version.
  • the script list is an index file for finding business scripts, and records the mapping relationship between the service type and the business script.
  • the service platform After receiving the FIX message, the service platform searches for the corresponding service script in the script list according to the service type information, so as to implement the corresponding business logic.
  • the service platform may also extract protocol version information from the service data, and combine the protocol version information with the service type information to find a service. script.
  • a dimension information that is, protocol version information, should be added to the script list to record the mapping relationship between the service type, the protocol version, and the service script.
  • the developer needs to pre-write various business scripts, and the business platform can allow the developer to pin.
  • Developing different business scripts for various versions of the FIX protocol for various business logics may also allow developers to develop different business scripts for each FIX protocol version for a specific business logic.
  • the service platform may also open an Application Programming Interface (API) for developing business scripts to the organization to receive business scripts developed by the organization.
  • API Application Programming Interface
  • the scripting language is a lightweight dynamic language.
  • the time cost and computer resources consumed in developing a scripting language are far less than the consumption of developing business logic in the FIX protocol code. Therefore, in addition to the prior art, in this embodiment, in addition to reducing the number of deployment protocol versions, the deployment cost of the FIX protocol can be further reduced by configuring a scripting language.
  • the service platform executes a business script, and processes the business data according to the business logic.
  • the business script can be saved in the database server. After the required business script is found in the database, the service platform puts it into the cache and dynamically loads the business script by refreshing the cache.
  • business logic uses different business data. For example, in the commodity transaction process, at least business data such as buyer and seller ID, product ID, and commodity price are required. Which kind of business data is selected for processing, which is determined by the business logic in the business script, or is determined by the constraint control information in the business logic. This embodiment does not regard the type of business data used for executing the business script and The number is limited.
  • some transaction services are completed on the service platform side, and some transaction services need to be transmitted to the organization as the receiving end through the service platform (for example, bargaining). In the latter case, the service platform needs to send the processed FIX message to the receiving end after performing step 103.
  • the embodiment of the present invention further discloses a service implementation method of the FIX protocol, as shown in FIG. 2, the method includes:
  • the sender encapsulates the FIX packet into a FIX message.
  • the method shown in Figure 2 is mainly applied to the sender side, and the traditional FIX message is encapsulated in the upper layer to obtain a general class FIX message. Since the FIX message contains only the service data in the form of a string and does not include the business logic corresponding to the specific FIX protocol version, the FIX message can be commonly used for any version of the FIX protocol.
  • the business logic is written into the business script developed in advance and configured to the service platform side, so that the service platform processes the business data according to the business script containing the business logic.
  • the sending end sends the encapsulated FIX message to the service platform.
  • the method provided by the embodiment of the present invention can decouple the service logic in the FIX packet to the service script on the service platform side. Since the constraint control information in the business logic differs in form and content depending on the version of the FIX protocol, there is a general type of service data remaining in the FIX message and no specific business logic is included. FIX messages are no longer subject to the FIX protocol version and can be applied to any version of the FIX protocol. Compared with the prior art, this embodiment can improve the compatibility of the FIX protocol version, reduce the number of FIX protocol versions deployed, and thereby reduce the deployment cost of the FIX service environment.
  • the embodiment of the present invention further provides a service implementation method of the FIX protocol. As shown in FIG. 3, the method includes:
  • the sender encapsulates the FIX packet into a FIX message.
  • the sender encapsulates the FIX message into a generic FIX message. Specifically, the sender extracts a string from the packet header and the packet body of the FIX packet, and assembles the FIX message into a general class. The sender intercepts the packet header according to the preset packet header length, and then parses the packet body length according to the content of the packet header, and intercepts the string of the packet body according to the length of the packet body, and finally assembles the intercepted string into a FIX message.
  • the sender may, but is not limited to, encapsulating the FIX message into a Message class FIX message.
  • the sending end sends the encapsulated FIX message to the service platform.
  • both the sender and the receiver of the FIX message should communicate in one session (Session). After the session is established, the sender sends an existing sending method to send the FIX message to the service platform, for example, using the static method sendToTarget.
  • the service platform searches for a service script corresponding to the FIX message in the script list according to the service type information in the service data.
  • both parties need to communicate based on the same session.
  • the sender sends the FIX message together with the session ID of the session.
  • the service platform finds the corresponding session in the session list according to the session ID, and then performs subsequent processes in the session.
  • the service data in the FIX message in the prior art exists in the form of a data field, that is, in the form of a key-value pair.
  • the service data in this embodiment is also in the form of a key-value pair.
  • the following table shows some of the key-value pairs (Tag-Value) specified by the FIX protocol:
  • a key value pair corresponds to one type of business data.
  • the service platform searches for the key-value pair of the service type, obtains the service type information of the transaction service, and then searches the script list for the service script corresponding to the FIX message according to the service type information.
  • the service platform can also find the service script together with the sender ID, the message type (application layer message or session layer message), and even the session ID.
  • the service platform executes a business script, and processes the business data according to the business logic.
  • the service platform puts the found business script into the cache, loads the business script by refreshing the cache, and implements the corresponding business logic.
  • the business logic involved in the FIX protocol can be divided into two categories: one is the specific business logic for a specific transaction object/specific transaction scenario, and the versatility of such business logic in different transaction objects or different transaction scenarios is more common. Poor, need to be developed separately for specific situations, including but not limited to packet content analysis (involving different parsing rules), message field verification (whether non-empty, amount format, amount of money, etc.), message field conversion (date Format conversion, amount format conversion, currency identification conversion, etc.), signature verification, return code conversion, idempotent control, flow control, etc.
  • the other type is the business logic that all organizations can use.
  • This kind of business logic is mainly used to establish, guarantee, and cancel the underlying communication process between the two parties. It also includes the business logic of the more general transaction business.
  • Business logic for any business type includes heartbeat management, network test, message retransmission, message rejection, sequence number reset, logout, login verification, etc. at the session layer, as well as application layer withdrawal request, rejection of withdrawal order, execution report, status request, Status check, next order, etc.
  • a specific business logic it is configured in the form of a business script to the service platform, and is implemented by performing step 304.
  • general business logic there is no need to repeatedly configure business scripts for different organizations.
  • the general business logic is directly written into the protocol code on the service platform side. The implementation is performed by the following steps 305 to 307. Since the general business logic is applicable to all types of services, no modification is required during use, so the maintenance cost of the FIX service environment is not increased.
  • the service platform determines, according to message type information in the service data, a message type of the FIX message.
  • the service platform obtains the message type of the FIX message according to the key value pair whose Key is “MsgType”, and the message type includes “application layer message” and “session layer message”. For different message types, the service platform chooses to perform subsequent step 306 or step 307.
  • the service platform invokes an application layer method to execute general business logic of the application layer.
  • the business platform calls the toApp method or the fromApp method in the Application class to execute the general business logic of the application layer.
  • the difference between the toApp method or the fromApp method is that if the FIX message to be sent to the receiving end is processed, the toApp method is called, and if the received FIX message is processed, the fromApp method is called.
  • the service platform invokes the session layer method to execute the general business logic of the session layer.
  • the business platform calls the toAdmin method or the fromAdmin method in the Application class to execute the general business logic of the application layer.
  • the difference between the toAdmin method or the fromAdmin method is that if the FIX message to be sent to the receiving end is processed, the toAdmin method is called, and if the received FIX message is processed, the fromAdmin method is called.
  • the session numbers of sending and receiving FIX messages are separately maintained.
  • the message queues for managing the messages to be sent and received are also independent of each other. Therefore, the service platform can select toApp/toAdmin or fromApp according to the session number of the FIX message. /fromAdmin.
  • step 305 to step 307 are placed in step 304, it is only for convenience of description.
  • the service platform may first perform step 305 to step 307 and then perform step 303 to step 304, or Steps 305 to 307 and steps 303 to 304 are simultaneously performed.
  • a general check service such as field check and session number-based leak check can be written into the FIX protocol code, and implemented by calling the session layer method.
  • the service platform can also write the following new general business logic into the FIX protocol code, and execute through the session layer method:
  • the existing FIX protocol standard has a sequence number protection mechanism, and the message sender adds a session sequence number to the sent message. For the message receiver, if the sequence number of the currently received message is not continuous with the sequence number of the previous received message, There is a missed message between the two messages, and the message retransmission mechanism needs to be triggered. If the serial number is continuous, the sender will send the message again and will increment the sequence number of the previous message by 1 as the session number of the next message.
  • this embodiment provides a general service logic for resetting the serial number and implemented by the session layer method.
  • the service platform sets a preset sequence number maximum value according to the maximum upper limit value supported by the system.
  • the sequence number maximum value is smaller than the maximum upper limit value of the system.
  • the maximum value of the sequence number can be set to be the maximum on the system. 70% to 95% of the limit. For example, when the maximum system limit is 990,000, the maximum number can be set to 900,000.
  • the service platform determines whether the session sequence number of the current message reaches the preset sequence number maximum value. If the sequence number is reached, the session number is reset to 0, so that the subsequent accumulation continues from 0; if the sequence number is not reached, no processing is performed.
  • the session sequence number of the session layer can prevent the session number of the message from exceeding the maximum limit supported by the system or the database, and can effectively avoid system abnormality caused by the overflow of the session sequence number.
  • the reset may fail because the organization does not accept the system or the abnormality of the system itself.
  • the service platform can pass the session layer.
  • the method implements the reject transaction logic and refuses to process the current FIX message, thereby eliminating the possibility that the session sequence number is further accumulated.
  • the service platform can monitor the size of the message queue by clearing the queue logic. If the cache occupied by the message queue exceeds the preset cache threshold, the FIX message cached in the message queue is cleared to ensure stable and high availability of the system. .
  • the cache threshold may be set according to the memory size of the system. The specific values are not limited in this embodiment.
  • the service platform when the organization adds a FIX service, the service platform can also acquire the new Add the business script of the FIX business logic, and add the obtained business script to the script list, thereby completing the addition of new business logic.
  • the service logic is configured on the service platform side in the form of a script language.
  • the newly developed service script needs to be configured on the service platform side without modifying the FIX protocol code. Compared with the prior art, the flexibility and convenience of increasing business logic are greatly improved, and the organization can customize the personalized transaction business.
  • the service platform in this embodiment can also pre-develop different packet parsers for different non-FIX protocol packet encapsulation rules.
  • the service platform selects the corresponding packet parser based on the encapsulation rule, and parses the data stream of the non-FIX protocol packet through the packet parser to obtain the service data.
  • the securities company's asset inquiry transaction is realized by using non-standard FIX protocol messages.
  • the non-standard FIX protocol is mainly to reduce the growth rate of the serial number, because the frequency of users querying assets will be significantly higher than the transaction frequency. Therefore, asset query will inevitably lead to a rapid increase in the serial number of the session, resulting in frequent resets.
  • the general parsing method cannot parse the underlying binary data stream correctly into parsed data.
  • the packet parser developed by the user can implement correct parsing of non-standard FIX protocol packets, thereby ensuring the implementation of the service logic. Specifically, the process of parsing non-standard FIX protocol packets by the message parser is as shown in FIG. 4:
  • the service platform intercepts the packet header from the data stream of the non-standard FIX protocol packet according to the packet header length specified in the encapsulation rule.
  • the length of the packet header can be obtained by the service platform in advance with the organization (sender).
  • the field information such as the packet type and the length of the packet body can be obtained.
  • the service platform performs step 403 according to the packet body length information to intercept the packet body.
  • the service platform needs to determine whether the intercepted packet body is long enough, that is, whether the intercepted packet body reaches the length of the packet body. If the length is reached, the interception is stopped, otherwise the data stream continues to be read until The length of the message body or the data stream is read.
  • the assembled message header and the message body are returned to the upper layer as a string.
  • the data stream After intercepting the data stream corresponding to the packet header and the packet body, the data stream is assembled into a string of data and returned to the upper layer.
  • the upper layer splits the string into a single key-value pair, and completes the extraction of the business data after the field verification.
  • the service platform may further send the processed FIX message to the receiving end.
  • the service platform needs to process the FIX message sent by one party (the sender) and then send it to the other party (receiver).
  • the embodiment of the present invention will separately introduce the process of receiving a message and sending a message for the platform, and introduce the implementation process of the FIX service.
  • the service platform may also adopt a distributed network architecture, and perform distributed processing on the received FIX messages by using multiple computing nodes, where each computing node processes at least one session.
  • FIX message In the initial phase of the session, the session may be load balanced by a hash algorithm based on the session ID, such that each compute node is responsible for the same or approximately the same number of sessions.
  • the computing node with the smallest number of sessions can be selected for allocation.
  • a new session is allocated for the computing node that has recently performed the session logout. This embodiment is not in the distributed structure.
  • the number of compute nodes, the way the session is allocated, and the number of sessions loaded on the node are specifically limited.
  • the distributed network structure can improve the computational efficiency and reduce the load of a single computing node, and can also enable each computing node to independently manage the respective session serial numbers, thereby supporting the horizontal expansion of the session serial number. Solve the performance bottleneck caused by sequential sequence sending.
  • the service platform sends FIX messages to the outside.
  • the service platform receives the FIX message sent by the sending end, and processes the FIX message and sends it to the receiving end.
  • the scenario process includes:
  • the sender encapsulates the FIX message and calls the static method SendToTarget to send the FIX message to the service platform.
  • the service platform searches for the corresponding session according to the session ID carried in the message.
  • the service platform searches for and executes the corresponding groovy script according to the service type information carried in the message.
  • the FIX message is processed by the groovy script to implement the business logic in the script.
  • the service platform determines the type of the FIX message according to the message type information carried in the message.
  • the toAdmin method of the session layer is called to process the FIX protocol, and the general business logic of the session layer is implemented;
  • the application layer's toApp method is called to process the FIX protocol to implement the general business logic of the application layer.
  • the service platform invokes the object IoSessionResponder to send the processed FIX message to the receiving end.
  • the object IoSessionResponder object is initialized by the InitiatorIOHandler.
  • the service platform receives externally sent FIX messages.
  • the service platform receives the FIX message sent by the sender and processes the FIX message.
  • the scenario process includes:
  • the service platform performs asynchronous non-blocking monitoring on the socket socket of the sender through the object InitiatorIoHandler.
  • the service platform calls the class EventHandlingStrategy to add the message to the message queue blockingQueue.
  • the service platform calls the class EventHandlingStrategy to read the FIX message from the blockingQueue repeatedly.
  • the service platform searches for the corresponding session according to the session ID carried in the message.
  • the service platform checks whether the session serial number is continuous.
  • the sender is required to resend the FIX message within the normal sequence number range.
  • the service platform searches for and executes the corresponding groovy script according to the service type information carried in the message.
  • the FIX message is processed by the groovy script to implement the business logic in the script.
  • the service platform determines the type of the FIX message according to the message type information carried in the message.
  • the session layer's fromAdmin method is called to process the FIX protocol to implement the general business logic of the session layer;
  • the application layer's fromApp method is called to process the FIX protocol to implement the general business logic of the application layer.
  • Groovy is a Java virtual machine based Agile dynamic language can seamlessly integrate all existing Java objects and class libraries, and it is more convenient to use groovy language combined with java environment for development.
  • the business script can also be implemented by using a Java virtual machine-based language such as JPython or JRuby, which is not limited in this embodiment.
  • an embodiment of the present invention further provides a service implementation apparatus for the FIX protocol.
  • the device is mainly located on the service platform side, as shown in FIG. 7, the device includes: a receiving unit 71, a searching unit 72, and an executing unit 73;
  • the receiving unit 71 is configured to receive a FIX message sent by the sending end, where the FIX message is composed of different types of service data, and the service data is in a string form;
  • the search unit 72 is configured to search for a service script corresponding to the FIX message in the script list according to the service type information in the service data, where the service script corresponding to different FIX protocol versions is saved in the script list, and the service script includes the service logic;
  • the executing unit 73 is configured to execute a business script, and process the business data according to the business logic.
  • the FIX message received by the receiving unit 71 is a FIX message encapsulated into a general class.
  • the device further includes:
  • the writing unit 74 is configured to write general business logic into the protocol code on the service platform side, and the general business logic is business logic applicable to any service type.
  • the apparatus further includes a determining unit 75, configured to determine, according to the message type information in the service data, a message type of the FIX message after receiving the FIX message sent by the sending end;
  • the executing unit 73 is configured to: when the message type is an application layer message, invoke an application layer method to execute general business logic of the application layer;
  • the execution unit 73 is further configured to invoke the session layer method to execute the general business logic of the session layer when the message type is a session layer message.
  • execution unit 73 is configured to:
  • the general service logic is the reset sequence number logic of the session layer, if the session sequence number reaches the preset sequence number maximum value, the session sequence number is reset to 0;
  • the general business logic is the session layer's reject transaction logic, if the session sequence number fails to be reset, the FIX message is refused to be processed;
  • the general service logic is the clearing queue logic of the session layer, if the cache occupied by the message queue exceeds the preset cache threshold, the FIX message cached in the message queue is cleared.
  • the device further includes:
  • the obtaining unit 76 is configured to acquire a service script that includes a new FIX service logic when the FIX service is added.
  • the adding unit 77 is configured to add the obtained business script to the script list.
  • the device further includes:
  • the selecting unit 78 is configured to: when receiving the non-FIX protocol packet, select the packet parser according to the encapsulation rule of the non-FIX protocol packet;
  • the parsing unit 79 is configured to parse the data stream of the non-FIX protocol packet by using the packet parser to obtain the service data.
  • the device further includes:
  • the sending unit 710 is configured to send the processed FIX message to the receiving end.
  • the apparatus is configured to perform distributed processing on the received FIX messages by a plurality of computing nodes, wherein each computing node processes the FIX messages of the at least one session.
  • an embodiment of the present invention further provides a service implementation apparatus for the FIX protocol.
  • the device is mainly located at the transmitting end side, as shown in FIG. 9, the device includes: a processing unit 91 and a sending unit 92;
  • the processing unit 91 is configured to encapsulate the FIX message into a FIX message, where the FIX message is composed of different types of service data, and does not include the service logic corresponding to the specific FIX protocol version, and the service data is in the form of a string;
  • the sending unit 92 is configured to send the encapsulated FIX message to the service platform, so that the service platform processes the service data according to the service script that includes the service logic.
  • processing unit 91 is configured to encapsulate the FIX message into a generic class FIX message.
  • processing unit 91 is configured to extract a character string from the packet header and the message body of the FIX message, and assemble the FIX message into a general class.
  • the embodiment of the present invention further provides a service implementation system of the FIX protocol.
  • the system includes a service platform 101 and a transmitting end 102, wherein:
  • the service platform 101 includes the apparatus as shown in FIG. 7 or FIG. 8;
  • the transmitting end 102 includes the apparatus as shown in FIG.
  • the FIX protocol service implementation apparatus and system can perform upper layer abstract encapsulation on FIX packets, and obtain a general class FIX message that retains only service data but does not include specific service logic. By eliminating the specific service logic from the FIX packet, the strong type of the service in the FIX packet is weakened, so that the FIX message can be applied to any version of the FIX protocol.
  • business logic it is configured in the form of a business script independently of the FIX protocol code, and different business scripts are developed for different FIX protocol versions, using the foot. The characteristics of "dynamic configuration" and “dynamic loading" of the language are implemented for the FIX transaction business.
  • the embodiment of the present invention implements complete decoupling between the business logic and the FIX protocol code, so that the implementation of the business logic no longer depends on the protocol code itself, so the service platform only deploys one version of the FIX protocol. All FIX protocol versions of the transaction business can be realized, which can greatly reduce the deployment cost of the FIX service environment.
  • modules in the devices of the embodiments can be adaptively changed and placed in one or more devices different from the embodiment.
  • the modules or units or components of the embodiments may be combined into one module or unit or component, and further they may be divided into a plurality of sub-modules or sub-units or sub-components.
  • any combination of the features disclosed in the specification, including the accompanying claims, the abstract and the drawings, and so on All processes or units of any method or device disclosed are combined.
  • Each feature disclosed in this specification (including the accompanying claims, the abstract and the drawings) may be replaced by alternative features that provide the same, equivalent or similar purpose.
  • the various component embodiments of the present invention may be implemented in hardware, or in a software module running on one or more processors, or in a combination thereof.
  • a microprocessor or digital signal processor may be used in practice to implement some or all of the components of the inventive name (e.g., means for determining the level of link within a website) in accordance with embodiments of the present invention.
  • the invention can also be implemented as a device or device program (e.g., a computer program and a computer program product) for performing some or all of the methods described herein.
  • Such a program implementing the invention may be stored on a computer readable medium or may be in the form of one or more signals. Such signals may be downloaded from an Internet website, provided on a carrier signal, or provided in any other form.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Finance (AREA)
  • Accounting & Taxation (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • General Business, Economics & Management (AREA)
  • Marketing (AREA)
  • Strategic Management (AREA)
  • Technology Law (AREA)
  • Software Systems (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Game Theory and Decision Science (AREA)
  • Human Resources & Organizations (AREA)
  • Operations Research (AREA)
  • Computer And Data Communications (AREA)
  • Communication Control (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本发明公开了一种FIX协议的业务实现方法、装置及系统，涉及互联网技术领域，为解决业务平台侧部署FIX业务环境成本过高的问题而发明。本发明的方法包括：发送端将FIX报文封装为FIX消息并发送给业务平台；业务平台接收发送端发送的FIX消息，FIX消息由不同类型的业务数据组成，业务数据为字符串形式；根据业务数据中的业务类型信息在脚本列表中查找与FIX消息对应的业务脚本，脚本列表中保存有对应不同FIX协议版本的业务脚本，业务脚本包含业务逻辑；执行业务脚本，按照业务逻辑对业务数据进行处理。本发明主要应用于实现FIX协议会话层业务逻辑的过程中。

Description

FIX协议的业务实现方法、装置及系统
本申请要求2016年02月29日递交的申请号为201610112705.1、发明名称为“金融信息交换FIX协议的业务实现方法、装置及系统”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本发明涉及互联网技术领域，尤其涉及一种FIX协议的业务实现方法、装置及系统。
背景技术
金融信息交换(Financial Information eXchange，简称FIX)协议是一种不受单一实体控制的开放消息标准，能够被调整组建适应任何一个企业的商务需求，用于促进与安全交易相关的信息交换。FIX协议最早用于支持美国国内的委托人间基于直接信息流转的证券交易，随着时代的发展，FIX协议还进一步增加了衍生工具及其它产品的业务领域，包括集成投资、金融衍生产品及外汇交易等。
基于FIX协议标准，交易双方可以直接进行交易，也可以通过第三方搭建的金融业务平台(后续简称为业务平台)进行交易。随着金融市场的不断开放，大量的小微机构不断涌现，基于业务平台的交易方式越来越受到这些机构的关注和青睐。
对于基于业务平台的交易方式，机构方与业务平台应当使用相同版本的FIX协议。目前，FIX协议版本已经从FIX 1.0发展到FIX 5.0，其中，FIX 5.0版本协议又将早先版本中的会话层协议从应用层协议中分离出来，进一步产生了FIXT X.Y及FIX X.Y两个协议版本。现有技术中，业务平台无法要求或限制机构方使用的协议版本，为保证FIX协议的版本兼容，业务平台就需要搭建所有协议版本的业务环境，并针对不同的协议版本单独开发交易的业务逻辑。随着FIX协议版本的不断升级以及业务种类的持续增长，业务平台侧的环境部署成本将会越来越高。
发明内容
本发明提供了一种FIX协议的业务实现方法、装置及系统，能够解决业务平台侧部署FIX业务环境成本过高的问题。
为解决上述问题，第一方面，本发明提供了一种FIX协议的业务实现方法，该方法包括：
业务平台接收发送端发送的FIX消息，FIX消息由不同类型的业务数据组成，业务数据为字符串形式；
根据业务数据中的业务类型信息在脚本列表中查找与FIX消息对应的业务脚本，脚本列表中保存有对应不同FIX协议版本的业务脚本，业务脚本包含业务逻辑；
执行业务脚本，按照业务逻辑对业务数据进行处理。
第二方面，本发明还提供了一种FIX协议的业务实现方法，该方法包括：
发送端将FIX报文封装为FIX消息，FIX消息由不同类型的业务数据组成，不包含对应具体FIX协议版本的业务逻辑，业务数据为字符串形式；
将封装后的FIX消息发送给业务平台，以使得业务平台根据包含业务逻辑的业务脚本对业务数据进行处理。
第三方面，本发明还提供了一种FIX协议的业务实现装置，该装置包括：
接收单元，用于接收发送端发送的FIX消息，FIX消息由不同类型的业务数据组成，业务数据为字符串形式；
查找单元，用于根据业务数据中的业务类型信息在脚本列表中查找与FIX消息对应的业务脚本，脚本列表中保存有对应不同FIX协议版本的业务脚本，业务脚本包含业务逻辑；
执行单元，用于执行业务脚本，按照业务逻辑对业务数据进行处理。
第四方面，本发明还提供了一种FIX协议的业务实现装置，该装置包括：
处理单元，用于将FIX报文封装为FIX消息，FIX消息由不同类型的业务数据组成，不包含对应具体FIX协议版本的业务逻辑，业务数据为字符串形式；
发送单元，用于将封装后的FIX消息发送给业务平台，以使得业务平台根据包含业务逻辑的业务脚本对业务数据进行处理。
第五方面，本发明还提供了一种FIX协议的业务实现系统，该系统包括业务平台及发送端；
业务平台包括上述第三方面的装置；
发送端包括上述第四方面的装置。
借由上述方案，本发明提供的FIX协议的业务实现方法、装置及系统，能够对FIX报文进行上层抽象封装，获得仅保留业务数据但不包含具体业务逻辑的通用类FIX消息。通过从FIX报文中“剔除”具体业务逻辑的方式，弱化了FIX报文中业务的强类型特点，使得FIX消息能够通用于任何一种版本的FIX协议。而对于业务逻辑而言，则采用业务 脚本的形式独立于FIX协议代码进行配置，针对不同的FIX协议版本开发不同的业务脚本，利用脚本语言“动态配置”、“动态加载”的特点对FIX交易业务予以实现。与现有技术相比，本发明实现了业务逻辑与FIX协议代码之间的彻底解耦，使得业务逻辑的实现不再依赖于协议代码本身，因此业务平台仅部署一种版本的FIX协议就可以实现所有FIX协议版本的交易业务，能够大大降低FIX业务环境的部署成本。
上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。
附图说明
通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：
图1示出了本发明实施例提供的第一种FIX协议的业务实现方法的流程图；
图2示出了本发明实施例提供的第二种FIX协议的业务实现方法的流程图；
图3示出了本发明实施例提供的第三种FIX协议的业务实现方法的流程图；
图4示出了本发明实施例提供的对非标准FIX协议进行解析的方法流程图；
图5示出了本发明实施例提供的第一种处理FIX消息的交互图；
图6示出了本发明实施例提供的第二种处理FIX消息的交互图；
图7示出了本发明实施例提供的第一种FIX协议的业务实现装置的组成框图；
图8示出了本发明实施例提供的第二种FIX协议的业务实现装置的组成框图；
图9示出了本发明实施例提供的第三种FIX协议的业务实现装置的组成框图；
图10示出了本发明实施例提供的FIX协议的业务实现系统的示意图。
具体实施方式
下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。
本发明实施例公开了一种FIX协议的业务实现方法，如图1所示，该方法包括：
101、业务平台接收发送端发送的FIX消息。
发送端一般为机构方，例如证券交易所、期货交易所的客户端等，发送端向业务平台发送封装好的FIX消息，该FIX消息的内容为字符串形式，涉及不同类型的业务数据，例如交易金额、交易时间、买卖双方ID、业务类型、消息长度等。实际应用中，现有FIX协议中的所有数据域(或称为字段)均可作为本实施例中的业务数据使用，并且，在现有FIX协议允许的范围内，交易双方自定义的数据域也可以作为所述业务数据使用，本实施例不对业务数据的种类和数量进行限制。
本步骤中接收的FIX消息是经过发送端进行上层抽象封装后的消息，与现有实现方式不同的是，现有FIX报文中除了携带有各种数据域之外，还会携带有针对具体交易业务的业务逻辑，这些业务逻辑本质上是对各种数据域的约束控制信息。例如对于业务“买进股票”而言，其具体的约束控制信息至少包括：确定买入对象(哪只股票)、判断股票价格是否达到预设价位、买入几手股票、如何发起买进操作等。由于FIX报文中的业务逻辑涵盖了实现交易业务的具体约束控制条件，因此现有技术中的FIX报文被称为是一种强类型的报文。与此同时，正是由于FIX报文中存在具体的业务逻辑，而受FIX协议版本差异影响，即使是同一个交易业务，不同FIX协议版本对应的业务逻辑也会有所不同，因此现有技术需要针对不同FIX协议版本单独开发业务逻辑。而在本实施例中，业务逻辑被从FIX报文中解耦出去，以脚本语言的形式单独配置在业务平台侧。对于FIX报文而言，发送端将其中的数据域(业务数据)抽象成一个通用的类，获得字符串形式的业务数据。这种通用类型的业务数据可以适用于任何FIX协议版本。
102、业务平台根据业务数据中的业务类型信息在脚本列表中查找与FIX消息对应的业务脚本。
每一个业务脚本都记录有一个对应具体FIX版本的具体业务逻辑，脚本列表是一种用于查找业务脚本的索引性文件，其中记录有业务类型与业务脚本之间的映射关系。当接收到FIX消息后，业务平台根据其中的业务类型信息在脚本列表中查找对应的业务脚本，以实现相应的业务逻辑。
进一步的，考虑到同一个业务逻辑会存在对应不同FIX协议版本的业务脚本，为进行精确查找，业务平台还可以从业务数据中提取协议版本信息，将协议版本信息与业务类型信息相结合查找业务脚本。与此对应的，脚本列表中应当增加一个维度信息，即协议版本信息，从而记录业务类型、协议版本以及业务脚本三者之间的映射关系。
本实施例中，需要开发人员预先编写各种业务脚本，业务平台可以允许开发人员针 对某个版本的FIX协议开发对应各种业务逻辑的不同业务脚本，也可以允许开发人员针对某个具体的业务逻辑开发对应各个FIX协议版本的不同业务脚本。实际应用中，为实现业务逻辑的按需定制，业务平台还可以向机构方开放用于开发业务脚本的应用程序接口(Application Programming Interface，简称API)，以接收机构方开发的业务脚本。
需要说明的是，脚本语言是一种轻量化的动态语言，开发脚本语言所消耗的时间成本及计算机资源远远小于在FIX协议代码中开发业务逻辑的消耗。因此相对现有技术而言，本实施例除了可以减少部署协议版本数量以外，还能够通过配置脚本语言的方式进一步降低FIX协议的部署成本。
103、业务平台执行业务脚本，按照业务逻辑对业务数据进行处理。
通常情况下，业务脚本可以保存在数据库服务器中，当在数据库中查找到需要的业务脚本后，业务平台将其放入到缓存中，通过刷新缓存的方式对业务脚本进行动态加载。
通常，业务逻辑的实现会使用到不同的业务数据，例如在商品交易过程中，至少需要买卖方ID、商品ID、商品价格等业务数据。选择何种业务数据做何种方式的处理，这是由业务脚本中的业务逻辑决定，或者说是由业务逻辑中的约束控制信息决定，本实施例不对执行业务脚本使用的业务数据的种类和数量进行限制。
实际应用中，某些交易业务是在业务平台侧完成的，而有些交易业务则需要通过业务平台传递给作为接收端的机构方进行实现(例如议价)。对于后者情况，业务平台在执行完步骤103之后还需要将处理后的FIX消息发送给接收端。
进一步的，本发明实施例还公开了一种FIX协议的业务实现方法，如图2所示，该方法包括：
201、发送端将FIX报文封装为FIX消息。
图2所示方法主要应用于发送端一侧，将传统的FIX报文进行上层抽象封装，获得一个通用类的FIX消息。由于FIX消息中只包含字符串形式的业务数据，而不包含对应具体FIX协议版本的业务逻辑，因此该FIX消息可以通用于任何版本的FIX协议。
同时，业务逻辑被写入到提前开发的业务脚本中，并配置到业务平台侧，以使得业务平台根据包含业务逻辑的业务脚本对业务数据进行处理。
202、发送端将封装后的FIX消息发送给业务平台。
本发明实施例提供的方法，能够将FIX报文中的业务逻辑解耦到业务平台侧的业务脚本中实现。由于业务逻辑中的约束控制信息在形式和内容上，因FIX协议版本的不同而有所差异，因此当FIX消息中剩余有通用类型的业务数据而不再包含具体的业务逻辑 时，FIX消息就不会再受FIX协议版本的限制，可以适用于任何版本的FIX协议中。相对现有技术而言，本实施例能够提高FIX协议版本的兼容性减少部署的FIX协议版本数量，并由此降低FIX业务环境的部署成本。
进一步的，作为对上述图1和图2所示方法的细化，本发明实施例还提供了一种FIX协议的业务实现方法，如图3所示，该方法包括：
301、发送端将FIX报文封装为FIX消息。
发送端将FIX报文封装成通用类的FIX消息。具体的，发送端从FIX报文的报文头及报文体中提取字符串，组装成通用类的FIX消息。发送端根据预设的报文头长度截取报文头，然后根据报文头内容解析出报文体长度，并根据报文体长度截取报文体的字符串，最后将截取的字符串组装成FIX消息。
实际应用中，发送端可以但不限于将FIX报文封装为Message类FIX消息。
302、发送端将封装后的FIX消息发送给业务平台。
根据现有的FIX协议规定，FIX报文的收发双方应当在一个会话(Session)中进行通信。在建立好会话后，发送端调用已有的发送方法将FIX消息发送给业务平台，例如使用静态方法sendToTarget进行发送。
303、业务平台根据业务数据中的业务类型信息在脚本列表中查找与FIX消息对应的业务脚本。
如前所述，消息收发双方需要基于同一个会话进行通信。发送端在发送FIX消息的同时还会将本次会话的会话ID一同进行发送，由业务平台根据该会话ID在会话列表中找出对应的会话，然后在该会话中进行后续流程。
现有技术中FIX报文中的业务数据是以数据域的形式存在的，即以键值对的形式存在。本实施例中的业务数据同样是以键值对的形式存在，下表示出了FIX协议规定的部分键值对(Tag-Value)：
Figure PCTCN2017073919-appb-000001
Figure PCTCN2017073919-appb-000002
发送端在对FIX消息进行解析后，获得其携带的业务数据。其中，一个键值对对应一个类型的业务数据。
在解析出键值对后，业务平台查找业务类型的键值对，从中获取交易业务的业务类型信息，然后根据该业务类型信息在脚本列表中查找与FIX消息对应的业务脚本。
进一步的，由于业务平台涉及交易业务众多，为避免重复或混淆，业务平台还可以结合发送者ID、消息类型(应用层消息或会话层消息)甚至会话ID一同查找业务脚本。
304、业务平台执行业务脚本，按照业务逻辑对业务数据进行处理。
业务平台将查找到的业务脚本放入缓存，通过刷新缓存的方式加载业务脚本，实现相应的业务逻辑。
实际应用中，FIX协议涉及的业务逻辑可以分为两大类：一类是针对具体交易对象/具体交易场景的特定业务逻辑，这类业务逻辑在不同交易对象或不同交易场景中的通用性较差，需要针对具体情况单独开发，包括但不限于是报文内容解析(涉及不同的解析规则)、报文字段校验(是否非空、金额格式、金额大小等)、报文字段转换(日期格式转换、金额格式转换、币种标识转换等)、签名验签、返回码转换、幂等控制、流量控制等。
另一类是所有机构方均可以使用的业务逻辑，这一类业务逻辑主要用于建立、保障、注销通信双方之间的底层通信过程，当然也包括较为通用的交易业务的业务逻辑，其适用于任何业务类型的业务逻辑。较为典型的业务逻辑包括会话层的心跳管理、网路测试、消息重传、消息驳回、序号复位、注销、登录验证等，以及应用层的撤单请求、驳回撤单、执行报告、状态请求、状态检查、下新单等。
对于特定的业务逻辑，将其以业务脚本的形式配置到业务平台，通过执行步骤304予以实现。而对于通用的业务逻辑而言，则无需针对不同的机构方重复配置业务脚本， 在开发FIX业务环境时，直接将通用业务逻辑写入业务平台侧的协议代码中。通过后续步骤305至步骤307进行实现。由于通用业务逻辑适用于所有的业务类型，使用过程中无需修改，因此不会增加FIX业务环境的维护成本。
305、业务平台根据业务数据中的消息类型信息判断FIX消息的消息类型。
业务平台根据Key为“MsgType”的键值对获得FIX消息的消息类型，该消息类型包括“应用层消息”及“会话层消息”两种。针对不同的消息类型，业务平台选择执行后续步骤306或步骤307。
306、若消息类型为应用层消息，则业务平台调用应用层方法执行应用层的通用业务逻辑。
业务平台调用Application类中的toApp方法或fromApp方法执行应用层的通用业务逻辑。toApp方法或fromApp方法的区别在于，如果是对待发送给接收端的FIX消息进行处理，则调用toApp方法，如果是对接收到的FIX消息进行处理，则调用fromApp方法。
307、若消息类型为会话层消息，则业务平台调用会话层方法执行会话层的通用业务逻辑。
业务平台调用Application类中的toAdmin方法或fromAdmin方法执行应用层的通用业务逻辑。toAdmin方法或fromAdmin方法的区别在于，如果是对待发送给接收端的FIX消息进行处理，则调用toAdmin方法，如果是对接收到的FIX消息进行处理，则调用fromAdmin方法。
实际应用中，发送和接收FIX消息的会话序号是各自分别维护的，管理待发送和已接收消息的消息队列也是相互独立的，因此业务平台可以根据FIX消息的会话序号选择调用toApp/toAdmin还是fromApp/fromAdmin。
本实施例将步骤305至步骤307置于步骤304之后仅为便于表述，实际应用中业务平台在接收到FIX消息后，也可以首先执行步骤305至步骤307然后再执行步骤303至步骤304，或者，同时执行步骤305至步骤307以及步骤303至步骤304。
在本实施例的一种实现方式中，可以将字段校验、基于会话序号的漏传校验等通用的校验业务写入到FIX协议代码中，通过会话层方法的调用予以实现。
进一步的，业务平台还可以将下述几种新的通用业务逻辑写入到FIX协议代码中，通过会话层方法执行：
1、重置序号逻辑
现有FIX协议标准中存在序号保护机制，消息发送方会在发送的消息中添加一个会话序号，对于消息接收方而言，如果当前接收消息的序号与前一个接收消息的序号不连续，则说明两消息之间存在漏传的消息，需要触发消息重传机制。而如果序号连续，则发送方再次发送消息时会将上一个消息的序号加1，作为下一个消息的会话序号使用。
由此可见，随着通信过程的不断深入，通信双方使用的会话序号将不断递增，当会话序号的数值超过系统或数据库支持的最大上限时，系统因无法识别该会话序号而容易出现错误重传等问题。为防止会话序号超过系统上限，本实施例给出了一种重置序号的通用业务逻辑并通过会话层方法予以实现。具体的，业务平台根据系统支持的最大上限值设定一个预设的序号最大值，通常该序号最大值小于系统的最大上限值，实际应用中可以将序号最大值设定为系统最大上限值的70％到95％。例如当系统最大上限值为99万时，可以将序号最大值设置为90万。
在执行重置序号逻辑时，业务平台判断当前消息的会话序号是否到达预设的序号最大值。如果到达序号最大值则会话序号重置为0，以使得后续从0开始继续累加；如果未到达序号最大值则不作任何处理。
本实施例中，通过会话层的重置序号逻辑可以防止消息的会话序号超出系统或数据库支持的最大上限，能够有效避免因会话序号溢出导致的系统异常。
2、拒绝交易逻辑
当对会话序号进行重置时，可能因为机构方不受理，或者系统自身的异常原因导致重置失败，此时为避免会话序号超出系统或数据库支持的最大上限值，业务平台可以通过会话层方法实现拒绝交易逻辑，拒绝对当前的FIX消息进行处理，由此消除会话序号进一步累加的可能性。
3、清除队列逻辑
在现有FIX协议的重传机制中，如果会话序号不连续，则会将当前消息放在一个消息队列中进行缓存，并通知发送端重新发送漏传序号对应的消息。此时发送端后续发送的当前消息之后的所有消息都需要缓存在消息队列中，因此消息队列存在内存溢出风险。本实施例中，业务平台可以通过清除队列逻辑对消息队列的大小进行监控，若消息队列占用的缓存超过预设的缓存阈值，则清除消息队列中缓存的FIX消息，以保证系统的稳定高可用。实际应用中，缓存阈值可以根据系统的内存大小按照比例设置，本实施例对其具体数值不作限制。
进一步的，在本实施例中，当机构方新增FIX业务时，业务平台还可以获取包含新 增FIX业务逻辑的业务脚本，并将获取的业务脚本添加到脚本列表中，由此完成新增业务逻辑的添加。本实施例将业务逻辑以脚本语言的形式配置在业务平台侧，当需要新增业务逻辑时，只需要将新开发的业务脚本配置在业务平台侧即可，无需对FIX协议代码进行修改。与现有技术相比，大大提高了增加业务逻辑的灵活性和便捷性，更加便于机构方自定义个性化的交易业务。
与此类似的，当需要从业务平台中删除某些业务逻辑时，只需要更加业务类型查找到对应的业务脚本，然后将该业务脚本从脚本列表中删除即可，同样无需改动FIX协议代码，使用起来方便灵活。
进一步的，考虑到实际应用中，部分机构方因不愿频繁重置会话序号等原因并未使用标准的FIX协议报文进行通信。对于使用非标准FIX协议报文的机构方，为保证其交易业务的实现，本实施例中业务平台还可以针对不同非FIX协议报文的封装规则预先开发不同的报文解析器，当接收到非FIX协议报文时，业务平台根据其封装规则选择对应的报文解析器，并通过报文解析器对非FIX协议报文的数据流进行解析，获得业务数据。
实际应用中，证券公司的资产查询交易就是使用非标准FIX协议报文实现的，采用非标准FIX协议主要是考虑到降低序号的增长速度，因为用户查询资产的频率会明显高于交易的频率，因此资产查询必然会导致会话序号的快速增长，从而导致频繁重置的情况发生。对于非标准FIX协议报文，由于其封装规则与通用类FIX消息的封装规则不同，因此使用通用的解析手段并不能将底层的二进制数据流解析正确解析为字符串形式的数据。本实施例中，通过定制开发的报文解析器可以实现非标准FIX协议报文的正确解析，从而保证业务逻辑的实现。具体的，通过报文解析器解析非标准FIX协议报文的流程如图4所示：
401、按照约定好的报文头长度截取报文头。
业务平台按照封装规则中规定的报文头长度，从非标准FIX协议报文的数据流中截取报文头。该报文头长度可以由业务平台预先与机构方(发送端)约定获得。
402、根据报文头获得报文类型以及报文体长度信息。
获得报文头后，就可以从中获得报文类型、报文体长度等字段信息。业务平台根据报文体长度信息执行步骤403，截取报文体。
403、根据报文体长度截取报文体。
在截取报文体的过程中，业务平台需要多次判断截取的报文体是否足够长，即截取的报文体是否达到报文体长度。如果达到该长度则停止截取，否则继续读取数据流直至 达到报文体长度或数据流读取完毕。
404、组装报文头及报文体，以字符串形式返回给上层。
在对对应报文头、报文体的数据流进行截取后，将数据流组装成字符串形式的数据，并返回给上层。由上层将字符串拆分成一个个键值对，在进行字段校验后完成业务数据的提取。
进一步的，在本实施例的另一种实现方式中，业务平台在对接收的FIX消息进行处理后，还可以将处理后的FIX消息发送给接收端。通常，除了能够在业务平台侧实现的交易业务外，还有一部分交易业务需要基于机构双方共同完成，例如价格询盘/还盘等。这种情况下，业务平台需要将一方机构(发送端)发送的FIX消息进行处理后，发送给另一方机构(接收端)。本发明实施例后续将分别针对平台接收消息及发送消息两个过程，对FIX业务的实现过程进行介绍。
进一步的，在本实施例的最后一种实现方式中，业务平台还可以采用分布式网络架构，通过多个计算节点对接收的FIX消息进行分布式处理，其中，每个计算节点处理至少一个会话的FIX消息。在会话初始阶段，可以以会话ID为依据，通过哈希算法对会话进行负载均衡，以使得每个计算节点负责数量相同或近似相同的会话。当新增会话时，可以选择会话数量最少的计算节点进行分配，也可以在会话数量相同的情况下，为最近进行过会话注销的计算节点分配新增会话，本实施例不对分布式结构中的计算节点数量、会话分配方式以及节点上负载的会话数量进行具体限制。
在上述实现方式中，采用分布式网络结构除了可以提高计算效率、减轻单台计算节点负荷之外，还可以使每个计算节点独立管理各自的会话序号，从而支持会话序号的横向扩展，由此解决序号顺序发送带来的性能瓶颈。
下面给出本发明实施例的两种应用场景：
第一，业务平台向外部发送FIX消息
本场景中，业务平台接收发送端发送的FIX消息，对FIX消息进行处理后发送给接收端。具体的，如图5所示，该场景流程包括：
1、发送端封装FIX消息，并调用静态方法SendToTarget将FIX消息发送给业务平台。
2、业务平台根据消息中携带的会话ID查找对应的会话。
3、业务平台根据消息中携带的业务类型信息查找并执行对应的groovy脚本。
通过groovy脚本对FIX消息进行处理，实现脚本中的业务逻辑。
4、业务平台根据消息中携带的消息类型信息判断FIX消息的类型。
若为会话层消息，则调用会话层的toAdmin方法对FIX协议进行处理，实现会话层的通用业务逻辑；
若为应用层消息，则调用应用层的toApp方法对FIX协议进行处理，实现应用层的通用业务逻辑。
5、业务平台调用对象IoSessionResponder将处理后的FIX消息发送给接收端。
对象IoSessionResponder对象是由InitiatorIOHandler初始化得到的。
6、业务平台与发送端将自身保存的会话序号加1。
第二，业务平台接收外部发送的FIX消息
本场景中，业务平台接收发送端发送的FIX消息，并对FIX消息进行处理。具体的，如图6所示，该场景流程包括：
1、业务平台通过对象InitiatorIoHandler对发送端的socket套接字进行异步非阻塞式监听。
2、当接收到发送端发送的FIX消息时，业务平台调用类EventHandlingStrategy将消息加入到消息队列blockingQueue中。
3、业务平台调用类EventHandlingStrategy重复性的从blockingQueue中读取FIX消息。
4、业务平台根据消息中携带的会话ID查找对应的会话。
5、业务平台检查会话序号是否连续。
如果会话序号连续则执行后续步骤，否则要求发送端重新发送正常序号范围内的FIX消息。
6、业务平台根据消息中携带的业务类型信息查找并执行对应的groovy脚本。
通过groovy脚本对FIX消息进行处理，实现脚本中的业务逻辑。
7、业务平台根据消息中携带的消息类型信息判断FIX消息的类型。
若为会话层消息，则调用会话层的fromAdmin方法对FIX协议进行处理，实现会话层的通用业务逻辑；
若为应用层消息，则调用应用层的fromApp方法对FIX协议进行处理，实现应用层的通用业务逻辑。
8、业务平台与发送端将自身保存的会话序号加1。
在上述场景中，业务脚本采用groovy语言开发。groovy是一种基于Java虚拟机的 敏捷动态语言，可以无缝集成所有已经存在的Java对象和类库，采用groovy语言结合java环境进行开发更为方便。实际应用中，业务脚本还可以但不限于使用JPython、JRuby等同样基于Java虚拟机的语言进行实现，本实施例对此不作限制。
进一步的，作为对上述图1及图3所示方法的实现，本发明实施例还提供了一种FIX协议的业务实现装置。该装置主要位于业务平台侧，如图7所示，该装置包括：接收单元71、查找单元72以及执行单元73；其中，
接收单元71，用于接收发送端发送的FIX消息，FIX消息由不同类型的业务数据组成，业务数据为字符串形式；
查找单元72，用于根据业务数据中的业务类型信息在脚本列表中查找与FIX消息对应的业务脚本，脚本列表中保存有对应不同FIX协议版本的业务脚本，业务脚本包含业务逻辑；
执行单元73，用于执行业务脚本，按照业务逻辑对业务数据进行处理。
进一步的，接收单元71接收的FIX消息为封装成通用类的FIX消息。
进一步的，如图8所示，该装置还包括：
写入单元74，用于将通用业务逻辑写入业务平台侧的协议代码中，通用业务逻辑为适用于任何业务类型的业务逻辑。
进一步的，如图8所示，该装置还包括判断单元75，用于在接收发送端发送的FIX消息之后，根据业务数据中的消息类型信息判断FIX消息的消息类型；
执行单元73，用于当消息类型为应用层消息时，调用应用层方法执行应用层的通用业务逻辑；
执行单元73还用于当消息类型为会话层消息时，调用会话层方法执行会话层的通用业务逻辑。
进一步的，执行单元73用于：
当通用业务逻辑为会话层的重置序号逻辑时，若会话序号到达预设的序号最大值，则将会话序号重置为0；
当通用业务逻辑为会话层的拒绝交易逻辑时，若会话序号重置失败，则拒绝处理FIX消息；
当通用业务逻辑为会话层的清除队列逻辑时，若消息队列占用的缓存超过预设的缓存阈值，则清除消息队列中缓存的FIX消息。
进一步的，如图8所示，该装置还包括：
获取单元76，用于当新增FIX业务时，获取包含新增FIX业务逻辑的业务脚本；
添加单元77，用于将获取的业务脚本添加到脚本列表中。
进一步的，如图8所示，该装置还包括：
选择单元78，用于当接收到非FIX协议报文时，根据非FIX协议报文的封装规则选择报文解析器；
解析单元79，用于通过报文解析器对非FIX协议报文的数据流进行解析，获得业务数据。
进一步的，如图8所示，该装置还包括：
发送单元710，用于将处理后的FIX消息发送给接收端。
进一步的，该装置用于通过多个计算节点对接收的FIX消息进行分布式处理，其中，每个计算节点处理至少一个会话的FIX消息。
进一步的，作为对上述图2及图3所示方法的实现，本发明实施例还提供了一种FIX协议的业务实现装置。该装置主要位于发送端侧，如图9所示，该装置包括：处理单元91及发送单元92；其中，
处理单元91，用于将FIX报文封装为FIX消息，FIX消息由不同类型的业务数据组成，不包含对应具体FIX协议版本的业务逻辑，业务数据为字符串形式；
发送单元92，用于将封装后的FIX消息发送给业务平台，以使得业务平台根据包含业务逻辑的业务脚本对业务数据进行处理。
进一步的，处理单元91用于将FIX报文封装成通用类的FIX消息。
进一步的，处理单元91用于从FIX报文的报文头及报文体中提取字符串，组装成通用类的FIX消息。
进一步的，作为对上述图3所示方法的实现，本发明实施例还提供了一种FIX协议的业务实现系统。如图10所示，该系统包括业务平台101及发送端102，其中：
业务平台101包括如图7或图8所示的装置；
发送端102包括如图9所示的装置。
本发明实施例提供的FIX协议的业务实现装置及系统，能够对FIX报文进行上层抽象封装，获得仅保留业务数据但不包含具体业务逻辑的通用类FIX消息。通过从FIX报文中“剔除”具体业务逻辑的方式，弱化了FIX报文中业务的强类型特点，使得FIX消息能够通用于任何一种版本的FIX协议。而对于业务逻辑而言，则采用业务脚本的形式独立于FIX协议代码进行配置，针对不同的FIX协议版本开发不同的业务脚本，利用脚 本语言“动态配置”、“动态加载”的特点对FIX交易业务予以实现。与现有技术相比，本发明实施例实现了业务逻辑与FIX协议代码之间的彻底解耦，使得业务逻辑的实现不再依赖于协议代码本身，因此业务平台仅部署一种版本的FIX协议就可以实现所有FIX协议版本的交易业务，能够大大降低FIX业务环境的部署成本。
在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。
可以理解的是，上述方法及装置中的相关特征可以相互参考。另外，上述实施例中的“第一”、“第二”等是用于区分各实施例，而并不代表各实施例的优劣。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
在此提供的算法和显示不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述，构造这类系统所要求的结构是显而易见的。此外，本发明也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本发明的内容，并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。
在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。
类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本发明的单独实施例。
本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此 公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。
此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。
本发明的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本发明实施例的发明名称(如确定网站内链接等级的装置)中的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如，计算机程序和计算机程序产品)。这样的实现本发明的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。
应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。

Claims (25)

  1. 一种金融信息交换FIX协议的业务实现方法，其特征在于，所述方法包括：
    业务平台接收发送端发送的FIX消息，所述FIX消息由不同类型的业务数据组成，所述业务数据为字符串形式；
    根据业务数据中的业务类型信息在脚本列表中查找与所述FIX消息对应的业务脚本，所述脚本列表中保存有对应不同FIX协议版本的业务脚本，所述业务脚本包含业务逻辑；
    执行所述业务脚本，按照所述业务逻辑对所述业务数据进行处理。
  2. 根据权利要求1所述的方法，其特征在于，所述FIX消息为封装成通用类的FIX消息。
  3. 根据权利要求1所述的方法，其特征在于，所述方法进一步包括：
    将通用业务逻辑写入业务平台侧的协议代码中，所述通用业务逻辑为适用于任何业务类型的业务逻辑。
  4. 根据权利要求3所述的方法，其特征在于，在所述接收发送端发送的FIX消息之后，所述方法进一步包括：
    根据业务数据中的消息类型信息判断所述FIX消息的消息类型；
    若所述消息类型为应用层消息，则调用应用层方法执行应用层的通用业务逻辑；
    若所述消息类型为会话层消息，则调用会话层方法执行会话层的通用业务逻辑。
  5. 根据权利要求4所述的方法，其特征在于，所述调用会话层方法执行会话层的通用业务逻辑，包括：
    当所述通用业务逻辑为会话层的重置序号逻辑时，若会话序号到达预设的序号最大值，则将所述会话序号重置为0；或者，
    当所述通用业务逻辑为会话层的拒绝交易逻辑时，若会话序号重置失败，则拒绝处理所述FIX消息；或者，
    当所述通用业务逻辑为会话层的清除队列逻辑时，若消息队列占用的缓存超过预设的缓存阈值，则清除所述消息队列中缓存的FIX消息。
  6. 根据权利要求1所述的方法，其特征在于，所述方法进一步包括：
    当新增FIX业务时，获取包含新增FIX业务逻辑的业务脚本；
    将获取的业务脚本添加到所述脚本列表中。
  7. 根据权利要求1所述的方法，其特征在于，所述方法进一步包括：
    当接收到非FIX协议报文时，根据非FIX协议报文的封装规则选择报文解析器；
    通过所述报文解析器对所述非FIX协议报文的数据流进行解析，获得业务数据。
  8. 根据权利要求1所述的方法，其特征在于，所述方法进一步包括：
    将处理后的FIX消息发送给接收端。
  9. 根据权利要求1至8中任一项所述的方法，其特征在于，所述方法进一步包括：
    通过多个计算节点对接收的FIX消息进行分布式处理，其中，每个计算节点处理至少一个会话的FIX消息。
  10. 一种金融信息交换FIX协议的业务实现方法，其特征在于，所述方法包括：
    发送端将FIX报文封装为FIX消息，所述FIX消息由不同类型的业务数据组成，不包含对应具体FIX协议版本的业务逻辑，所述业务数据为字符串形式；
    将封装后的FIX消息发送给业务平台，以使得所述业务平台根据包含业务逻辑的业务脚本对所述业务数据进行处理。
  11. 根据权利要求10所述的方法，其特征在于，所述将FIX报文封装为FIX消息，包括：
    将所述FIX报文封装成通用类的FIX消息。
  12. 根据权利要求11所述的方法，其特征在于，所述将所述FIX报文封装成通用类的FIX消息，包括：
    从所述FIX报文的报文头及报文体中提取字符串，组装成通用类的FIX消息。
  13. 一种金融信息交换FIX协议的业务实现装置，其特征在于，所述装置包括：
    接收单元，用于接收发送端发送的FIX消息，所述FIX消息由不同类型的业务数据组成，所述业务数据为字符串形式；
    查找单元，用于根据业务数据中的业务类型信息在脚本列表中查找与所述FIX消息对应的业务脚本，所述脚本列表中保存有对应不同FIX协议版本的业务脚本，所述业务脚本包含业务逻辑；
    执行单元，用于执行所述业务脚本，按照所述业务逻辑对所述业务数据进行处理。
  14. 根据权利要求13所述的装置，其特征在于，所述接收单元接收的所述FIX消息为封装成通用类的FIX消息。
  15. 根据权利要求13所述的装置，其特征在于，所述装置还包括：
    写入单元，用于将通用业务逻辑写入业务平台侧的协议代码中，所述通用业务逻辑为适用于任何业务类型的业务逻辑。
  16. 根据权利要求15所述的装置，其特征在于，所述装置还包括判断单元，用于在接收发送端发送的FIX消息之后，根据业务数据中的消息类型信息判断所述FIX消息的消息类型；
    所述执行单元，用于当所述消息类型为应用层消息时，调用应用层方法执行应用层的通用业务逻辑；
    所述执行单元还用于当所述消息类型为会话层消息时，调用会话层方法执行会话层的通用业务逻辑。
  17. 根据权利要求16所述的装置，其特征在于，所述执行单元用于：
    当所述通用业务逻辑为会话层的重置序号逻辑时，若会话序号到达预设的序号最大值，则将所述会话序号重置为0；
    当所述通用业务逻辑为会话层的拒绝交易逻辑时，若会话序号重置失败，则拒绝处理所述FIX消息；
    当所述通用业务逻辑为会话层的清除队列逻辑时，若消息队列占用的缓存超过预设的缓存阈值，则清除所述消息队列中缓存的FIX消息。
  18. 根据权利要求13所述的装置，其特征在于，所述装置还包括：
    获取单元，用于当新增FIX业务时，获取包含新增FIX业务逻辑的业务脚本；
    添加单元，用于将获取的业务脚本添加到所述脚本列表中。
  19. 根据权利要求13所述的装置，其特征在于，所述装置还包括：
    选择单元，用于当接收到非FIX协议报文时，根据非FIX协议报文的封装规则选择报文解析器；
    解析单元，用于通过所述报文解析器对所述非FIX协议报文的数据流进行解析，获得业务数据。
  20. 根据权利要求13所述的装置，其特征在于，所述装置还包括：
    发送单元，用于将处理后的FIX消息发送给接收端。
  21. 根据权利要求13至20中任一项所述的装置，其特征在于，所述装置用于通过多个计算节点对接收的FIX消息进行分布式处理，其中，每个计算节点处理至少一个会话的FIX消息。
  22. 一种金融信息交换FIX协议的业务实现装置，其特征在于，所述装置包括：
    处理单元，用于将FIX报文封装为FIX消息，所述FIX消息由不同类型的业务数据组成，不包含对应具体FIX协议版本的业务逻辑，所述业务数据为字符串形式；
    发送单元，用于将封装后的FIX消息发送给业务平台，以使得所述业务平台根据包含业务逻辑的业务脚本对所述业务数据进行处理。
  23. 根据权利要求22所述的装置，其特征在于，所述处理单元用于将所述FIX报文封装成通用类的FIX消息。
  24. 根据权利要求23所述的装置，其特征在于，所述处理单元用于从所述FIX报文的报文头及报文体中提取字符串，组装成通用类的FIX消息。
  25. 一种金融信息交换FIX协议的业务实现系统，其特征在于，所述系统包括业务平台及发送端；
    所述业务平台包括如权利要求13至权利要求21中任一项所述的装置；
    所述发送端包括如权利要求22至权利要求24中任一项所述的装置。
PCT/CN2017/073919 2016-02-29 2017-02-17 Fix协议的业务实现方法、装置及系统 Ceased WO2017148278A1 (zh)

Priority Applications (8)

Application Number Priority Date Filing Date Title
EP17759129.4A EP3425877A4 (en) 2016-02-29 2017-02-17 SERVICE IMPLEMENTATION PROCESS, DEVICE AND SYSTEM BASED ON A FIRM PROTOCOL
JP2018545451A JP6861720B2 (ja) 2016-02-29 2017-02-17 Ｆｉｘプロトコルに基づくサービス実施方法、装置、及びシステム
MYPI2018703004A MY183050A (en) 2016-02-29 2017-02-17 Service implementation method, apparatus, and system based on fix protocol
SG11201807245WA SG11201807245WA (en) 2016-02-29 2017-02-17 Service implementation method, apparatus, and system based on fix protocol
KR1020187027850A KR102136945B1 (ko) 2016-02-29 2017-02-17 Fix 프로토콜에 기반한 서비스 구현 방법, 장치 및 시스템
AU2017226398A AU2017226398B2 (en) 2016-02-29 2017-02-17 Service implementation method, apparatus and system based on fix protocol
PH12018501824A PH12018501824B1 (en) 2016-02-29 2018-08-28 Service implementation method, apparatus, and system based on fix protocol
US16/115,313 US10791070B2 (en) 2016-02-29 2018-08-28 Service implementation method, apparatus, and system based on fix protocol

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201610112705.1 2016-02-29
CN201610112705.1A CN107135188B (zh) 2016-02-29 2016-02-29 金融信息交换fix协议的业务实现方法、装置及系统

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US16/115,313 Continuation US10791070B2 (en) 2016-02-29 2018-08-28 Service implementation method, apparatus, and system based on fix protocol

Publications (1)

Publication Number Publication Date
WO2017148278A1 true WO2017148278A1 (zh) 2017-09-08

Family

ID=59720749

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2017/073919 Ceased WO2017148278A1 (zh) 2016-02-29 2017-02-17 Fix协议的业务实现方法、装置及系统

Country Status (11)

Country Link
US (1) US10791070B2 (zh)
EP (1) EP3425877A4 (zh)
JP (1) JP6861720B2 (zh)
KR (1) KR102136945B1 (zh)
CN (1) CN107135188B (zh)
AU (1) AU2017226398B2 (zh)
MY (1) MY183050A (zh)
PH (1) PH12018501824B1 (zh)
SG (1) SG11201807245WA (zh)
TW (1) TWI658418B (zh)
WO (1) WO2017148278A1 (zh)

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108427599A (zh) * 2017-09-30 2018-08-21 平安科技（深圳）有限公司 异步任务统一处理方法、装置及存储介质
CN110659247A (zh) * 2018-06-13 2020-01-07 中国移动通信集团江西有限公司 话单文件连续性检测方法、装置、设备及介质
CN108833446A (zh) * 2018-08-01 2018-11-16 广发证券股份有限公司 一种基于Fix协议请求包的协议转换方法及装置
CN110473101A (zh) * 2019-08-15 2019-11-19 中国银行股份有限公司 模拟交易所的报文处理方法及装置
CN111212056A (zh) * 2019-12-30 2020-05-29 中电工业互联网有限公司 一种基于809协议的数据解析与分发系统及方法
CN111368512B (zh) * 2020-03-04 2023-08-22 北京软通智慧科技有限公司 一种业务数据的转换方法、装置、设备及存储介质
CN112134915B (zh) * 2020-06-29 2022-10-14 上海金融期货信息技术有限公司 一种应用层协议解耦合的通用网络处理系统
CN112532619B (zh) * 2020-11-26 2022-01-25 深圳前海景佑科技有限公司 Defix协议的生成、解析方法、客户端、服务器及系统
CN114040008B (zh) * 2021-11-05 2024-07-30 光大科技有限公司 一种报文处理方法及装置
CN116137589B (zh) * 2021-11-17 2025-03-25 湖南微步信息科技有限责任公司 单点故障处理方法、装置、计算机设备及存储介质
CN114282984A (zh) * 2021-12-16 2022-04-05 中国农业银行股份有限公司上海市分行 一种基于canvas的银行经营数据图形展示方法及系统
CN115103041B (zh) * 2022-07-18 2024-07-12 深圳市雁联计算系统有限公司 一种基于fix协议实现业务的方法及系统
CN116232885A (zh) * 2022-12-23 2023-06-06 中国联合网络通信集团有限公司 信息的配置方法、装置及存储介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080306856A1 (en) * 2007-06-07 2008-12-11 Nyfix, Inc. Aged Transactions in a Trading System
CN102255786A (zh) * 2010-05-20 2011-11-23 中国移动通信集团广西有限公司 业务报文处理方法及装置
CN102681854A (zh) * 2012-05-18 2012-09-19 华为技术有限公司 业务执行方法、服务器和计算机系统
CN103020861A (zh) * 2012-11-06 2013-04-03 苏州工业园区凌志软件股份有限公司 用于金融证券行业的中间业务平台系统
US20140189161A1 (en) * 2012-12-31 2014-07-03 Trading Technologies International, Inc. In-Line FIX Packet Translator

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020083213A1 (en) * 2000-09-18 2002-06-27 Oberstein Brien M. Method and system for simulating and certifying complex business applications
KR100831985B1 (ko) * 2001-07-10 2008-05-23 삼성전자주식회사 휴대통신단말기에서의 비용결제 문자메시지 관리장치 및그 방법
WO2003017175A1 (en) * 2001-08-14 2003-02-27 Bloomberg Lp Distribution and mapping of financial records from data stream
US7433842B2 (en) * 2003-03-25 2008-10-07 Tradeweb Markets Llc Method and system for effecting straight-through-processing of trades of various financial instruments
JP2008503794A (ja) * 2003-11-26 2008-02-07 エフエックス アライアンス，エルエルシー プロトコル独立型資産トレーディングシステム及び方法
CA2615052C (en) * 2005-07-11 2014-06-10 Sanjoy Roy Choudhury Systems and methods for delivering parameters to automated security order execution systems
US20080285438A1 (en) * 2007-04-20 2008-11-20 Rohini Marathe Methods, systems, and computer program products for providing fault-tolerant service interaction and mediation function in a communications network
CN101267645B (zh) * 2008-02-29 2011-03-02 中兴通讯股份有限公司 用于w基站业务流程软件开发的自动化测试方法和系统
JP4722195B2 (ja) * 2009-04-13 2011-07-13 富士通株式会社 データベース・メッセージ分析支援プログラム、方法及び装置
US9009351B2 (en) * 2009-07-09 2015-04-14 Lime Brokerage Llc Brokerage transaction server and method using encapsulated messages
JP5533536B2 (ja) * 2010-10-08 2014-06-25 富士通株式会社 情報処理プログラム、装置及び方法
US8719795B2 (en) * 2011-04-12 2014-05-06 Miami International Security Exchange, Llc System and method for automating testing of computers
CN102546599A (zh) * 2011-12-16 2012-07-04 深圳中兴网信科技有限公司 一种实现不同协议数据等价互转的方法
US9076182B2 (en) * 2013-03-11 2015-07-07 Yodlee, Inc. Automated financial data aggregation
CN104239803B (zh) * 2013-06-06 2017-08-25 中国银联股份有限公司 用于电子资源转移的安全性信息交互方法
US10032219B2 (en) * 2013-09-24 2018-07-24 Chicago Mercantile Exchange Inc. Secure exchange feed market data embargo
US10296973B2 (en) * 2014-07-23 2019-05-21 Fortinet, Inc. Financial information exchange (FIX) protocol based load balancing
CN104506380B (zh) * 2014-12-16 2018-07-13 北京星河亮点技术股份有限公司 基于协议分析仪的移动终端数据业务性能测试方法及系统

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080306856A1 (en) * 2007-06-07 2008-12-11 Nyfix, Inc. Aged Transactions in a Trading System
CN102255786A (zh) * 2010-05-20 2011-11-23 中国移动通信集团广西有限公司 业务报文处理方法及装置
CN102681854A (zh) * 2012-05-18 2012-09-19 华为技术有限公司 业务执行方法、服务器和计算机系统
CN103020861A (zh) * 2012-11-06 2013-04-03 苏州工业园区凌志软件股份有限公司 用于金融证券行业的中间业务平台系统
US20140189161A1 (en) * 2012-12-31 2014-07-03 Trading Technologies International, Inc. In-Line FIX Packet Translator

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP3425877A4 *

Also Published As

Publication number Publication date
EP3425877A1 (en) 2019-01-09
AU2017226398A1 (en) 2018-09-13
TW201732704A (zh) 2017-09-16
PH12018501824A1 (en) 2019-01-28
CN107135188A (zh) 2017-09-05
US20180367482A1 (en) 2018-12-20
KR20180118168A (ko) 2018-10-30
KR102136945B1 (ko) 2020-07-23
PH12018501824B1 (en) 2022-02-23
EP3425877A4 (en) 2019-11-27
TWI658418B (zh) 2019-05-01
AU2017226398B2 (en) 2020-07-16
CN107135188B (zh) 2020-09-25
US10791070B2 (en) 2020-09-29
JP6861720B2 (ja) 2021-04-21
JP2019512138A (ja) 2019-05-09
SG11201807245WA (en) 2018-09-27
MY183050A (en) 2021-02-09

Similar Documents

Publication Publication Date Title
TWI658418B (zh) 金融資訊交換（ｆｉｘ）協議的業務實現方法、裝置及系統
US11356282B2 (en) Sending cross-chain authenticatable messages
US11336465B2 (en) Sending cross-chain authenticatable messages
WO2021109735A1 (zh) 一种基于跨链网络的资源处理方法及装置
CN108848092A (zh) 基于调用链的微服务灰度发布的处理方法及装置
CN109635019B (zh) 请求处理方法、装置、设备及存储介质
CN102087615B (zh) 消息队列中消息的合并的方法和系统
CN110443704A (zh) 一种跨链发送资源的方法和装置
CN113055492A (zh) 服务灰度链路的控制方法、装置、计算机设备和存储介质
CN111447170B (zh) 数据处理方法及其系统、计算机系统及计算机可读介质
CN103248670A (zh) 计算机网络环境下的连接管理
WO2020248383A1 (zh) 基于跨平台的数据处理方法、装置及计算机设备
CN113742235A (zh) 一种校验代码的方法和装置
CN106484603B (zh) 一种业务测试方法及装置
CN108496157B (zh) 使用扩展接口提供运行时跟踪的系统和方法
US7571236B2 (en) System and method for managing connections
CN117176565A (zh) 业务请求的处理方法、系统、设备、介质及产品
CN108804555A (zh) 协议展示方法、装置和电子设备
CN116560712A (zh) 微服务构建方法、装置、设备以及计算机存储介质
CN114971552B (zh) 一种对公信贷数据处理系统、方法、设备、介质及产品
CN113077241A (zh) 审批处理方法、装置、设备及存储介质
CN107436899A (zh) 活体识别页面的实现方法和装置
US12099998B2 (en) Configurable, reactive architecture framework for data stream manipulation at scale
US20240104524A1 (en) Methods and systems for pre-verification of cryptocurrency transactions on blockchain networks
CN113760467B (zh) 事务处理方法、装置、计算机系统及存储介质

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 11201807245W

Country of ref document: SG

ENP Entry into the national phase

Ref document number: 2018545451

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2017226398

Country of ref document: AU

Date of ref document: 20170217

Kind code of ref document: A

ENP Entry into the national phase

Ref document number: 20187027850

Country of ref document: KR

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 2017759129

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 2017759129

Country of ref document: EP

Effective date: 20181001

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17759129

Country of ref document: EP

Kind code of ref document: A1