WO2000054191A1 - Systeme de connectivite pour multi-courtiers, systeme de commerce en ligne utilisant ce systeme de connectivite, reseau pour systeme multitraitements et procedes connexes - Google Patents

Systeme de connectivite pour multi-courtiers, systeme de commerce en ligne utilisant ce systeme de connectivite, reseau pour systeme multitraitements et procedes connexes Download PDF

Info

Publication number
WO2000054191A1
WO2000054191A1 PCT/CN1999/000031 CN9900031W WO0054191A1 WO 2000054191 A1 WO2000054191 A1 WO 2000054191A1 CN 9900031 W CN9900031 W CN 9900031W WO 0054191 A1 WO0054191 A1 WO 0054191A1
Authority
WO
WIPO (PCT)
Prior art keywords
processing
api
request
broker
format
Prior art date
Application number
PCT/CN1999/000031
Other languages
English (en)
Inventor
Fujun Bi
Alexander Joseph Kolt
William E. Coppens
John Kelbe Babbidge
Gary Zhou
Hong Yan
Shaun Bliss
Original Assignee
Fujun Bi
Alexander Joseph Kolt
Coppens William E
John Kelbe Babbidge
Gary Zhou
Hong Yan
Shaun Bliss
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 Fujun Bi, Alexander Joseph Kolt, Coppens William E, John Kelbe Babbidge, Gary Zhou, Hong Yan, Shaun Bliss filed Critical Fujun Bi
Priority to PCT/CN1999/000031 priority Critical patent/WO2000054191A1/fr
Priority to AU32454/99A priority patent/AU3245499A/en
Publication of WO2000054191A1 publication Critical patent/WO2000054191A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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

Definitions

  • a multi-broker connectivity system an online trading system utilizing the same, a multi-processing-system networking system, and the methods therefor
  • the present invention relates to e-commerce technology, specifically, an internet-based multi-broker connectivity system, an online trading system utilizing the same, a multi-processing-system networking system, and the methodss therefor.
  • Said multi-broker connectivity system or online trading system can be connected to a plurality of broke systems to enable investors to conduct securities online-trading via internet, and provide an infrastructure that will produce business functionality at the front-end independent of backend technology constraints and have a middle tier completely generic and useful to all functionality.
  • the securities market is always a concern for investors, and there is growing demand for tools to help the investors to conduct remote online trading, without going to the broker offices.
  • electronic securities trading system at the respective broker offices such as LAN online trading system, card trading system, etc.
  • online trading systems based on Internet technology with which a broker's end users can access to the web page of this broker and conduct online securities trading.
  • Fig. 1 illustrates the conventional approach to online trading systems.
  • each broker must have its own online trading system, including its own web server networking to the exchange via leased lines.
  • the end users access to the broker system at the broker's web site and conduct online trading with this broker's system only.
  • the broker must keep its own technical team to develop its online trading system, to maintain the system. It is not only costly to keep such a technical team, but difficult for the broker to provide further value added services on its online trading system, since each broker system has its own separate end users, and the number of end users of each broker system is limited.
  • the object of the present invention is to provide a many(users)-to- many(brokers) solution, which is a sophisticated technical service layer between the end users and the broker systems, to provide online trading services of different broker systems to the end users.
  • This technical service layer is not a broker system, but provides networking service to broker trading systems, and provides online trading functionality and value-added services to all the end users.
  • This many-to-many solution is an infrastructure that will produce business functionality at the front-end independent of backend technology constraints and have a middle tier completely generic and useful to all functionality.
  • one object of the present invention is to provide a multiprocessing-system networking system for networking to a plurality of processing systems, throughwhich a user can be networked to a plurality of different kinds of broke trading processing systems to conduct bi-directional data transmissions and real-time processing on his demands, and the method thereof.
  • Another object of the present invention is to provide a multi-broker networking or universal broker connectivity system, which can be adaptively networked to a plurality of broke trading systems, to provide online trading services of different broker systems to the end users.
  • Still another object of the present invention is to provide an online trading system, which can be networked to a plurality of broker trading systems, so as to provide online trading services of different broker systems to the end users at a same web site.
  • Still another object of the present invention is to provide a method for adapting a common connectivity system to a plurality of processing systems, by which different processing systems can constitute a uniformed processing system with the common connectivity system to work as a whole.
  • the present invention provides a multi- processing-system networking system for networking to a plurality of processing systems, said networking system having a plurality of users, and comprising: a receiving means for receiving users' request and formatting the request into a predetermined format, said format including sender's ID and receiver's ID; a messaging means for transmitting data in said predetermined format to a predetermined receiver according to said receiver's ID; at least one processing/adapting means each adaptively interfaced to a specific processing system, for receiving request for the respective specific processing system so as to perform processing of a certain class on a received request, and returning the processing result in the same format as the corresponding request to said messaging means while roles of the sender and receiver are exchanged; a presenting means for receiving said returned result and de-formatting said result to present the result to the corresponding request sender.
  • the present invention provides a method for networking users to a plurality of processing systems, comprising the steps of: receiving user's request and formatting the request into a predetermined format, said format including sender's ID and receiver's ID; transmitting said request in said predetermined format to a predetermined receiver according to said receiver's ID; receiving said request in said predetermined format for the respective specific processing system and performing processing of a certain class on the received request; transmitting said processing result in the same format as the corresponding request from said receiver to said sender according to said sender's ID; de-formatting said return result to present the result to the corresponding request sender.
  • the present invention also provides a multi-broker connectivity system for networking to a plurality of broker systems, said connectivity system having a plurality of users, and comprising: a receiving means for receiving users' request and formatting the request into a predetermined format, said format including sender's ID and receiver's ID; a messaging means for transmitting data in said predetermined format to a predetermined receiver according to said receiver's ID; at least one processing/adapting means each adaptively interfaced to a specific broker system, for receiving request for the respective specific broker system so as to perform processing of a certain class on a received request, and returning the processing result in the same format as the corresponding request to said messaging means while roles of the sender and receiver are exchanged; a presenting means for receiving said returned result and de-formatting said result to present the result to the corresponding request sender.
  • the present invention further provides an online trading system utilizing the multi-broker-connectivity system described above, wherein said multi-broker-connectivity system is networked to each of the broker systems by means of VPN via internet.
  • the present invention provides a method for adapting a common connectivity system to a plurality of processing systems, each has a native API including a plurality of processing functions, comprising the steps of: providing a uniformed adapting interface, a first API layer, a second API layer in sequence between the common connectivity system and each of the specific processing system; inputting uniformed processing instructions from the common connectivity system and to a specific processing system; calling respective functions of the first API layer according to the instruction's type; calling respective functions of the second API layer according to said respective functions of the first API layer; and calling respective processing functions of said native processing system's API according to said respective functions of the second API layer.
  • Fig. 1 illustrates the conventional online trading systems
  • Fig.2a is an overview of arrangement of the online trading system to which the present invention is applied;
  • Fig.2b illustrates the layer structure of this invention formed between the end users and the brokerage
  • Fig. 3 illustrates multi-layer architecture of an embodiment of the online trading system according to the present invention
  • Fig. 4 illustrates further architecture of a multi-broker networking system that forms a vital part of the online trading system in Fig.3;
  • Fig. 5 illustrates the API architecture at broker side
  • Fig. 6 illustrates the interface to messaging layer at a broker system side
  • Fig. 7 illustrates the related processing involved in the multi-broker networking system
  • Fig. 8 illustrates the processing involved in the servlet at the web server
  • Fig. 9 illustrates physical architecture of an embodiment of the present invention, wherein quote and other news and other service can be provided utilizing the same TIBCO P/S virtual bus;
  • Fig. 10 illustrates a configuration for sending information to one of user predefined facilities, such as pager, fax or e-mail.
  • Fig.2a is an overview of arrangement of the online trading system to which the present invention is applied.
  • the solution of this invention provides a web site, for example, www.99stock.com (or www.99stock.com.cn ), to be accessed by all the investors or end users via internet.
  • the 99stock system is networked to a plurality of broker trading systems by means of universal broker connectivity (multi-broker networking) technology, so that the 99stock system can provide online trading services of different broker systems to all the investors.
  • Fig.2b shows the layer structure between the end users and the brokerage.
  • This invention provides a unique technical service layer, a many-to-many solution, between the end users and the brokerage.
  • the 99stock system provides universal broker connectivity technology to all the possible broker systems; on the other hand, it provides private data provision technology to all the end users, to provide further value added services besides the online trading functionality.
  • Fig 3 shows the multi-layer architecture of the multi-broker networking(or universal broker connectivity) system according to the present invention. As shown in Fig. 3, it has a presentation layer, a messaging layer and a processing and adapter layer.
  • the presentation layer that resides in a Web server is responsible for formatting and presenting data to the user, that was returned from the broker and is Broker specified.
  • the Messaging layer contains a plurality of Messaging Servlets and Servers, in which a TIBCO unit is implemented which will be described later.
  • the messaging servlets pack requests and send them to TIBCO and invoke presentation layer when results are received.
  • the messaging servers receive requests from TIBCO, provide a queuing mechanism to handle over flow of incoming requests, provide a multithreaded processing environment fed by the queue, and invoke the appropriate processing class in the Processing Layer according to the Broker and request type.
  • the Processing and adapter layer is a Broker specific layer designed to perform any broker specific functionality and is implemented on a request type by request type basis. Moreover, it provides access to native broker APIs and performs message translation to appropriate format for native broker API.
  • the Presentation Layer will be described in detail.
  • One function of the Presentation Layer is to create in Web Server many leading set of pages, such as that of an Online Trading section links to by default needs to be changed to a broker directory style page . It also produces an HTML page for the user's Web browser, which enable the Messaging Servlet to call a broker specific Java class to format the data and return an HTML stream. It should be noted that any changes in formatting of the data or HTML presentation require code changes, recompilation of the relevant classes and redeployment of those classes. Moreover, it is preferred to use Java-based server Pages (JSP) for formatting data and call JSP pages with the Messaging Servlet.
  • JSP Java-based server Pages
  • the planned use of JSP requires the servlet to call the appropriate JSP class that produces the required page.
  • the JSP class runs a supplied method to access keys within a Hashtable.
  • the Java Object mechanism is designed to service a Java applet. It would simply pass back the Java Object to the client applet over the
  • TIBCO provides a subject-based key for clients to publish or subscribe to. Essentially a hierarchy of subjects can be created to allow clients to subscribe to information relevant to only them. This segregation is achieved by making the following assumptions: • All brokers have 1 or more branches. • Every Broker / Branch is a separate entity and is assumed completely independent of other branches. To support the messaging structure, a level for each broker and a level for each branch should be created, a request level is then created as Example: TRADING.Brokerl . Branchl . request TRADING.Broker 1 . branch2 . request TRADING.Bro er2 . branchl .
  • the Messaging Servlet performs critical functions.
  • One of the main functions of the Servlet is to receive input data from a user via a HTTP post. This may be created either via a regular web page, JSP page or an applet.
  • the servlet packages the information into a Hashtable. For example, the input Hashtable as the following one will minimally have the following entries, such as Customer ID, Broker ID, Branch ID, and RequestType, etc.
  • RequestType information will not be validated at this level as the servlet is intended to eventually serve a plurality of brokers who may have different request transaction sets.
  • the object Once packaged, the object will be published to TIBCO.
  • the brokerlD and BranchlD keys in the object will be used as the TIBCO subject in the following form:
  • TRADING. ⁇ brokerID>. ⁇ branchID>.request Using TIBCO' s request publishing mechanism, the servlet will publish the broker request and automatically generate a listener or inbox that subscribes to the response for only that request. This mechanism will deliver the result data back to the Messaging Servlet.
  • the broker response will be received in the same Hashtable that was sent as a request.
  • the Hashtable will then pass through the presentation layer.
  • the presentation layer will eventually handle three types of output: HTML, JSP and Java Object.
  • the output Hashtable such as one listed below contains the following entries, such as: Customer ID, BrokerlD, Branch ID, RequestType, Report and Error, etc.
  • the Messaging Server will be explained as below. It is comprised of the TIBCO client connectivity layer and the generic request type classes. All request type classes will implement a Transaction Java interface that takes a Hashtable and a Broker object as input. The broker specific transaction modifies the Hashtable by adding result fields.
  • the server has a set of request object classes to allow it to act in different ways, for example, UBCBrokerRequest for general trading transactions that represents the bulk of the traffic, UBCSystemRequest for general statistics customized to the UBC implementation of the backend server, CommonRequest for common server oriented requests like stopping, starting and restarting the server.
  • the Messaging Servlet and Server also have a file-based configuration to allow flexibility and reuse. Physically, each of the broker systems only need to connect to its own ISP, and access the 99stock system by VPN formed between the broker system via Internet.
  • the TIBCO server is located at the 99stock system side
  • the TIBCO client is located at the broker system side, all the requests and the returned results are transmitted on the virtual TIBCO bus formed between the TIBCO server and TIBCO client.
  • Fig. 4 illustrates further architecture of the Processing and Adapter layer in multi-broker networking system that forms one of the vital parts of the online trading system in Fig.3.
  • the Processing and Adapter layer of fig.4 there are Messaging layer interface, Broker Request Processing method and Java API and Broker API which form a hierarchy channel that conducts the information from/to Messaging layer to/from the end broker.
  • a broker API is a set of function calls provided for programming the brokerage trading system.
  • the API provides the function calls to the broker functionality existing in the broker trading system. Those functionality includes placing an order, requesting an account or portfolio information, and so forth.
  • the functions in a broker API can be grouped into three parts. The first part is login/logout to the SQL Server. This is a pair that should be used at the beginning and at the end of the process inside a program. The second part is for trading activity processing. This part contains all the functions for placing orders, checking pending orders, and etc. The third part is fund related. If the broker API is written in C++ and to make the API available in Java environment, it is needed to convert the API into Java API. In other word, one can access the API in Java. The Java language feature, JNI, will do this.
  • Fig. 5 illustrates the API architecture of the Processing and Adapter layer at broker side.
  • at bottom level is Uniform Processing Functions which process all the requests and returns the results to the Messaging Layer which routes the results based on the return values it gets.
  • Uniform Processing Functions which process all the requests and returns the results to the Messaging Layer which routes the results based on the return values it gets.
  • the following eight basic request categories needed be included in Uniform Processing Functions to meet trading requirements are listed below:
  • a Broker API is at the top layer.
  • a broker API is a set of function calls provided for programming the brokerage trading system.
  • the API provides the function calls to the broker functionality existing in the broker trading system. Those functionality includes placing an order, requesting an account or portfolio information, and so forth.
  • the middle layer is C API and Java API. Owing to the Java language feature, JNI, if the broker API is written in C, C++ and to make the API available in Java environment, it is needed to convert the API into Java API by C API. In other word, one can access the Broker API in Java through Java API and C API.
  • C Layer is a C wrapper of a C++ implementation. Within the C++ implementation the API is called.
  • Java Layer is a standard JNI to C layer, it needs to do works on the data formatting and converting.
  • Fig. 6 illustrates the interface to messaging layer at a broker system side.
  • the interface to messaging layer i.e., Messaging / Processing Layer Interface, functions as the UBC Messaging architecture interface and instructions on how to use it to integrate with individual brokers.
  • the implementation of the interface performs functionality mapping (Broker
  • the interface links the Thread C to the Order function in a Broker API and connects Thread A, B to other corresponding Broker APIs.
  • This interface is the area that talks to the Messaging Layer.
  • the purpose is to provide broker-processing classes to the Messaging Layer through an interface called UBCTransaction.
  • This interface will contain a method called process( ), which will take two parameters. One is a Hashtable and the other is a Broker object.
  • the Broker object is required by the Messaging
  • the Messaging Layer should use Broker object to initiate a processing thread and to clean up a processing thread when it is terminated.
  • the definition of the Broker class is shown as followed.
  • public class Broker ⁇ public void start() ⁇ public void end() ⁇ ⁇
  • the functions start and end will call the corresponding Java functions of loginSqlServer and logoutSqlServer :
  • the Messaging Layer requires that the input hashtable will minimally contain the entries of CustomerlD, Password, BrokerlD, BranchlD and RequestType.
  • the output hashtable will minimally contain the entries of the above plus Report and Error.
  • the input hashtable need to have input data in order to carry out a request.
  • an Order has to be accompanied with order type (buy or sell), number of shares, price and so forth.
  • order type buy or sell
  • Price a new key
  • a new key RequestData will be added into the Hashtable.
  • the Report and Error will be added to input hashtable too.
  • it is able to fix the format of a hashtable.
  • Broker Requests Processing Functions are a part that processes all the requests and returns the results to the Messaging Layer.
  • the Messaging Layer routes the results based on the return values it gets.
  • Integrating with the Messaging Layer may require two activities: implementing the initialization that will span a plurality of transactions, implementing the transaction type functionality.
  • the Initialisation process in the Messaging Server comprises:
  • Each processor Thread will be of class UBCProcessor that extends com.ims.iibco.ProcessorThread class.
  • UBCProcessor should instantiate com.ims.ubc. ⁇ UBCBrokerID>. ⁇ UBCBranchID>.Broker.
  • the broker- specific class "Broker" will perform any one-time initialization and de- initialization that a particular broker requires. It also provides a state vehicle to use across a plurality of uses of a processor Thread. An example of this is establish a broker DBMS connectivity with the broker supplied API. If the instantiation of the Broker class throws an exception then terminate the thread. If instantiation is successful, each Thread should then enter a loop retrieving the next message from the Message Queue and then process it with the broker specific class. The retrieval process should block, waiting for a message to enter the Message Queue.
  • BrokerID CITIC
  • BranchID Branchl . If the structure of all CITIC Branches is the same, the BranchlD value can be considered as a branch type ID.
  • Each transaction class is in the package com.ims.ubc. ⁇ BrokerID>. ⁇ BranchID> according to the BrokerlD and BranchlD in the BrokerRequest. • Each transaction class name is identical to the class name passed across in the RequestType key of the BrokerRequest.
  • the Report Vector will be a Vector of Hashtable where the Hashtable key is the column name and the Hashtable value is the data element.
  • Fig. 7 illustrates the related processing involved in the multi-broker networking system.
  • Fig. 8 illustrates the processing involved in the servlet at the web server.
  • the Web Server receives a request in HTTP form from the Browser of a Web Client, the Server then publish it to brokerX.BranchY.request through the TIBCO server of the UBC Servlet in the Web server(l) into TIBCO Bus.
  • the UBC Server Dispatcher subscribe the request from TIBCO Bus to brokerX.BranchY.request(2), then pass an Object and Reply subject from the RV message to a Thread in the Thread Pool(3).
  • the Thread performs a Broker specific backend processing(4), and then publishes the message to the brokerX.BranchY.request(5) into the TIBCO Bus through TIBCO Connectivity Wrapper.
  • the Server receives the response that UBC servlet automatically subscribed to, and presents it to the Browser in HTTP form.
  • HTTP connectivity Servlet is operative to receive the request from the browser and send it to a Transaction Creator, and to receive the reply from the Presentation Layer and transfer it to the browser.
  • Transaction Creator the Presentation Layer and TIBCO Layer consist of UBC servlet.
  • the Transaction Creator generalizes the request as previously discussed.
  • the Presentation Layer reformats the reply data and
  • the TIBCO layer publishes a Transaction request to and receives a reply of the Transaction request from TIBCO bus.
  • Web Browser connects with Web Server via Messaging Servlet i.e., UBC Servlet such as a TIBCO Server.
  • Messaging Servlet i.e., UBC Servlet such as a TIBCO Server.
  • Messaging Servlet takes name/value pairs and formulates data into a BrokerRequest.
  • the Messaging Servlet establishes a TIBCO connectivity to publish the new request. A new connectivity with the TIB can be established each time.
  • the Messaging Servlet publishes the request to TIBCO using the subject TRADING .
  • ⁇ branchID> request formed from the
  • the Messaging Servlet subscribes to a temporary TIBCO subject, unique to the current publish, and waits for a reply.
  • the Messaging Server i.e., UBC Server such as a TIBCO client, at the broker end listens on the TIB as a client for the subject
  • the Messaging Server receives the message from the TIB and unpacks it.
  • the Messaging Server takes the request information and passes it to a broker specific, custom transaction class for processing (Processing Layer).
  • JNI method implementations will translate the message into a form suitable for handing off to the broker's native API. JNI method implementations will usually be in C (Adapter Layer).
  • the native Broker API performs the business logic and returns the transaction result.
  • JNI methods returns information to Java realm (Processing Layer)
  • the Processing Layer packages the results into a BrokerRequest and passes it back to the Messaging Server Layer.
  • the Messaging Server publishes reply on the temporary subject provided in the original message.
  • the Messaging Servlet receives reply and passes to the message to the Presentation layer.
  • the Presentation layer formats the data and passes it to the client (Browser / applet / other).
  • Fig. 9 illustrates physical architecture of an embodiment of the present invention, wherein quote and other news and other service can be provided utilizing the same TIBCO P/S virtual bus.
  • Such an architecture comprise:
  • IP director for directing each of the messages to a plurality of
  • Web Servers connected thereto and for balancing the load of each of the web servers, Web Servers for receiving and outputting the corresponding message, Java-based server Name Server connected to Web Server for allowing only the Web Server traffic to reach Java-based servers for load balance, Java-based servers connected to Java-based server Name Server for performing different functions such as trading, Quote, News, 8 factors(stock selection) etc, and Broker VPN server networked to Java-based server through VPN via Internet for providing respective services.
  • firewalls there are two firewalls, one is an external firewall which defenses for the IP director, Web Servers, Java-based server Name Server and Java-based server, the other is an internal firewall which protects the Java-based server Name Server and Java-based server.
  • Fig. 10 illustrates a configuration for sending information to a user pre- defined facilities, such as pager, fax or e-mail, according to a user pre-set criteria.
  • a user pre-defined facilities such as pager, fax or e-mail
  • the public paging service server calls the expected user's pager through an airnet.
  • a desired user can be notified the quote information he wants in different ways.
  • the user can receive his trading results by means of the notification function. He can also set his criteria for selecting the information, and the relevant information in the virtual bus will be received according to the topic the user set, and transmitted to the user by the notification service.
  • This invention provides an universal broker connectivity system and an Internet online trading system which can be networked to a plurality of broker systems, therefore provides a many-to-many solution which is an effective tool for end users to do online securities trading via internet at different broker systems.
  • This universal broker connectivity system can be interfaced to the broker systems having different programming and different configurations by means of a uniform messaging/processing interface. It utilizes the publish/subscribe technology in a bi-directional manner, and provides an advantageous hierarchic format of the request and processing results so as to identify the destination receiver of a certain information, thereby realizing online trading between a plurality of investors and end users and a plurality of broker systems. Consequently, this invention provides an infrastructure that will produce business functionality at the front-end independent of backend technology constraints and have a middle tier completely generic and useful to all functionality.
  • the multi- broker networking technology can also be applied to other fields, for example, the different existing credit card systems provided by different banks, and other service systems of a same category but are belonging to different service providers and may have somewhat different hardware or software configurations.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Engineering & Computer Science (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Strategic Management (AREA)
  • Technology Law (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer And Data Communications (AREA)

Abstract

L'invention concerne un système de connectivité pour multi-courtiers permettant de mettre une pluralité de systèmes de courtiers en réseau. Ce système de connectivité comprend une pluralité d'utilisateurs et une unité de réception permettant de recevoir les demandes des utilisateurs et de formater ces demandes selon un format prédéterminé, ce format comprenant un identificateur (ID) émetteur et un ID récepteur ; une unité de messagerie permettant de transmettre les données sous un format prédéterminé à un récepteur prédéterminé selon l'ID récepteur ; au moins une unité de traitement/adaptation couplée de manière adaptative à un système de courtier spécifique afin de recevoir la demande concernant le système de courtier spécifique de manière à traiter un certain type de demande reçue et de renvoyer le résultat du traitement dans le même format que la demande correspondante à l'unité de messagerie alors que les rôles de l'émetteur et du récepteur sont interchangés ; une unité de présentation permettant de recevoir et de renvoyer le résultat et de déformater ce résultat pour le présenter à l'émetteur de la demande concerné. Grâce à ce système, on assure une architecture de messagerie à connectivité pour courtier universelle qui offre la fonctionnalité commerciale en premier plan indépendamment des contraintes technologiques du système principal et qui présente un niveau moyen général multifonctions.
PCT/CN1999/000031 1999-03-08 1999-03-08 Systeme de connectivite pour multi-courtiers, systeme de commerce en ligne utilisant ce systeme de connectivite, reseau pour systeme multitraitements et procedes connexes WO2000054191A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/CN1999/000031 WO2000054191A1 (fr) 1999-03-08 1999-03-08 Systeme de connectivite pour multi-courtiers, systeme de commerce en ligne utilisant ce systeme de connectivite, reseau pour systeme multitraitements et procedes connexes
AU32454/99A AU3245499A (en) 1999-03-08 1999-03-08 A multi-broker connectivity system, an online trading system utilizing the same,a multi-processing-system networking system, and the methods therefor

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN1999/000031 WO2000054191A1 (fr) 1999-03-08 1999-03-08 Systeme de connectivite pour multi-courtiers, systeme de commerce en ligne utilisant ce systeme de connectivite, reseau pour systeme multitraitements et procedes connexes

Publications (1)

Publication Number Publication Date
WO2000054191A1 true WO2000054191A1 (fr) 2000-09-14

Family

ID=4575115

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN1999/000031 WO2000054191A1 (fr) 1999-03-08 1999-03-08 Systeme de connectivite pour multi-courtiers, systeme de commerce en ligne utilisant ce systeme de connectivite, reseau pour systeme multitraitements et procedes connexes

Country Status (2)

Country Link
AU (1) AU3245499A (fr)
WO (1) WO2000054191A1 (fr)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7197484B1 (en) * 1999-10-26 2007-03-27 Goldenchart Co., Ltd. Asset management advice system and recording medium containing program of the system
US7865421B2 (en) 2004-08-13 2011-01-04 Ebs Group Limited Automated trading system
US9727916B1 (en) 1999-12-30 2017-08-08 Chicago Board Options Exchange, Incorporated Automated trading exchange system having integrated quote risk monitoring and integrated quote modification services
US9928550B2 (en) 1999-12-30 2018-03-27 Cboe Exchange, Inc. Automated trading exchange system having integrated quote risk monitoring and integrated quote modification services
US20200226680A1 (en) * 2004-09-21 2020-07-16 Refinitiv Us Organization Llc Financial market trading system

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1991014231A1 (fr) * 1990-03-06 1991-09-19 Chicago Board Of Trade Procede et appareil pour la gestion d'ordres par des agents de change
WO1995018418A1 (fr) * 1993-12-28 1995-07-06 Thomson Financial Networks, Inc. Procede et systeme permettant d'ameliorer la vitesse et la fiabilite de transactions operees sur le marche des valeurs
WO1996021192A1 (fr) * 1995-01-04 1996-07-11 Citibank, N.A. Systeme et procede pour la vente electronique de biens
WO1997003423A1 (fr) * 1995-07-10 1997-01-30 Digital Equipment Corporation Procede et dispositif d'exploitation de commerce informatise
WO1997036253A1 (fr) * 1996-03-28 1997-10-02 Tackline Communications, Inc. Systeme integre pour le traitement d'informations sur des services d'investissements financiers

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1991014231A1 (fr) * 1990-03-06 1991-09-19 Chicago Board Of Trade Procede et appareil pour la gestion d'ordres par des agents de change
WO1995018418A1 (fr) * 1993-12-28 1995-07-06 Thomson Financial Networks, Inc. Procede et systeme permettant d'ameliorer la vitesse et la fiabilite de transactions operees sur le marche des valeurs
WO1996021192A1 (fr) * 1995-01-04 1996-07-11 Citibank, N.A. Systeme et procede pour la vente electronique de biens
WO1997003423A1 (fr) * 1995-07-10 1997-01-30 Digital Equipment Corporation Procede et dispositif d'exploitation de commerce informatise
WO1997036253A1 (fr) * 1996-03-28 1997-10-02 Tackline Communications, Inc. Systeme integre pour le traitement d'informations sur des services d'investissements financiers

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7197484B1 (en) * 1999-10-26 2007-03-27 Goldenchart Co., Ltd. Asset management advice system and recording medium containing program of the system
US9727916B1 (en) 1999-12-30 2017-08-08 Chicago Board Options Exchange, Incorporated Automated trading exchange system having integrated quote risk monitoring and integrated quote modification services
US9928550B2 (en) 1999-12-30 2018-03-27 Cboe Exchange, Inc. Automated trading exchange system having integrated quote risk monitoring and integrated quote modification services
US7865421B2 (en) 2004-08-13 2011-01-04 Ebs Group Limited Automated trading system
US20200226680A1 (en) * 2004-09-21 2020-07-16 Refinitiv Us Organization Llc Financial market trading system

Also Published As

Publication number Publication date
AU3245499A (en) 2000-09-28

Similar Documents

Publication Publication Date Title
EP1559004B1 (fr) Couplage de session
US9742614B2 (en) Data-type definition driven dynamic business component instantiation and execution framework
CN100563260C (zh) 客户机Web服务访问
US8065657B2 (en) Exchange infrastructure system and method
US7426548B2 (en) Enterprise application platform
US7983209B2 (en) System and method for producing notification based web services
US20050182768A1 (en) Web browser as web service server in interaction with business process engine
US8346894B2 (en) Real-time web transactions from web applications
US20040221001A1 (en) Web service architecture and methods
US20040088352A1 (en) Business to business integration via the web
CN100474298C (zh) 访问web服务
CA2543557C (fr) Systeme et methode de production de services web bases sur les notifications
WO2004006059A2 (fr) Architecture et procede permettant de configurer un service web de validation de configuration
US20050198394A1 (en) Data conversion from HTML to XML in a tree structure
US20040006516A1 (en) Architecture and method for order placement web service
WO2000054191A1 (fr) Systeme de connectivite pour multi-courtiers, systeme de commerce en ligne utilisant ce systeme de connectivite, reseau pour systeme multitraitements et procedes connexes
WO2001026004A2 (fr) Procede et appareil pour messagerie interprocessus et leur utilisation pour la production automatique de courrier electronique transactionnel
US20040006571A1 (en) Architecture and method for product catalog web service
KR100915776B1 (ko) 웹 서비스 중개기를 위한 포트 타입 어그노스틱 프록시지원
Vélez et al. Lynx: an open email extension for workflow systems based on web services and its application to digital government
Apshankar et al. Web Services Architectures
WO2005038620A2 (fr) Navigateur web comme serveur de service web
JP2006526189A (ja) ウエブサービスブローカー
Jean-Baptiste A distributed architecture for U-messaging systems
Schnieders Application of web service technologies on a b2b communication platform by means of a pattern and UML based software development process

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AL AM AT AU AZ BA BB BG BR BY CA CH CN CU CZ DE DK EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT UA UG US UZ VN YU ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW SD SL SZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
121 Ep: the epo has been informed by wipo that ep was designated in this application
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase