1

Ich habe für ein paar Jahre ziemlich einfache und kleine automatisierte Handelsanwendungen gebaut. Diese Anwendungen sind Multi-Thread-Desktop-Apps, die mit JavaFX erstellt wurden und mit Drittanbieter-Desktop-Handelsanwendungen (Bloomberg EMSX, Interactive Broker's TWS usw.) über Java-APIs kommunizieren, die von Drittanbietern bereitgestellt werden. Im Wesentlichen haben Sie zwei Desktop-Anwendungen, die über Sockets miteinander kommunizieren.Wie gestaltet man eine Trading-App (mit einer QuickFIX/J und JavaFX)?

Auf den Punkt dieses Beitrags ...
diese kleinen Desktop-automatisierten Handels-Apps schneiden nicht mehr und es ist Zeit, ernst zu werden. Ich muss eine Trading-App erstellen, die mit einem Trading-Server eines Drittanbieters (anstelle einer Desktop-App) über FIX-Protokoll kommunizieren muss. Ich plane, QuickFix/J zu verwenden, und ich habe einige grundlegende Funktionen erfolgreich getestet, die dieses Rahmenwerk verwenden.

Meine Frage ist über Design: Ich denke, ich muss ein Client-Server-Server-Design implementieren. Das heißt: ein JavaFX-Client, der auf mehreren Benutzern installiert istdesktops; eine QuickFIX/J-Implementierung zusammen mit anderen Back-End-Diensten, die auf einem Server installiert sind; und der Drittanbieter-Anwendungsserver, mit dem unsere QuickFIX/J-Implementierung kommunizieren wird.

Ich habe kein Problem, die QuickFIX/J-Implementierung zu bauen und es mit dem 3rd Party Server zu sprechen.

Das Bit, über das ich nicht sicher bin, ist, dass der JavaFX-Client mit meiner QuickFIX/J-Implementierung auf dem Server kommuniziert. Ich sehe dieses Client-Server-Designthema weder online im JavaFX-Kontext noch im FIX-Protocol-Systemkontext.

Es gibt nicht viele Community-Unterstützung oder Informationen über JavaFX-Entwicklung, geschweige denn über größere Themen der Best Practice oder Enterprise-Design. Welche Information da ist, scheint veraltet zu sein. Und auch QuickFix/J scheint ein ziemlich spezielles Thema zu sein.

Meine Entwicklungserfahrung besteht hauptsächlich in Single-Thread-JEE-Bahnstapeln.

Hat jemand Erfahrung mit diesen Designproblemen oder dem Aufbau ähnlicher Handelsanwendungen mit JavaFX (oder Swing) und QuickFIX/J (oder einer anderen Java FIX-Protocol Engine)?

Wenn dies der Fall ist, würde ich mich über Ihre Anmerkungen zur Gestaltung Ihrer Trading-App (s), Best-Practice-Design und Implementierung sowie über alle Ressourcen, an die Sie mich verweisen könnten, freuen.

Danke.

+1

Nicht sicher, ob dies hilfreich ist, aber die Go-to-Person auf JavaFX in Enterprise-Anwendungen ist wahrscheinlich Adam Bien. [Dieser Artikel] (http://www.oracle.com/technetwork/articles/java/javafxinteg-2062777.html) ist eine ziemlich gute Zusammenfassung seines Ansatzes. Ich denke, ich würde dies angehen, indem ich Ihre QuickFIX/J-Implementierung als REST-Endpunkt exponiere und die Techniken nutze, die Adam beschreibt, um den JavaFX-Clients zu ermöglichen, damit zu kommunizieren. (Obwohl Sie auch den "mittleren Mann" ausschneiden und Ihre QuickFIX/J-Implementierung vielleicht als Teil des Clients einschließen könnten?) –

+0

Danke James_D. Es ist nicht das, was ich mir erhofft habe, sondern etwas, was ich mir ansehen kann :) – Amy

Antwort

0

Ok, nach etwas Recherche und Herumspielen denke ich, dass ich eine Antwort auf meine eigene Frage habe.

Meine Antwort ist, eine FIX-Brücke (mit QuickFix/J) zu bauen, die mit mehreren Sitzungen konfiguriert ist, zu denen sich die Handels-Apps verbinden können. Die Bridge wird auf einem Server gehostet. Diese Bridge leitet die Nachrichten dann an den FIX-Server von Drittanbietern weiter.

Oder mit anderen Worten ...

1) Der JavaFX Handel Apps verwenden QuickFix/J (Initiator) zu sprechen ...

2) Die QuickFix/J (Akzeptor) Brücke, die übergibt die Meldungen an ...

3) Die QuickFix/J (Initiator) Bridge, die die Meldungen weitergibt an ...

4) Die Drittanbieter-FIX-Server (Akzeptor)

(und natürlich geht der Ablauf zurück zu)

Sie können beliebig viele Sitzungen hinzufügen (z. B. pro Benutzer-algo Kombination) an den FIX Brücke nach Bedarf. Die Bridge stellt jedoch eine Verbindung mit dem FIX-Server eines Drittanbieters her, wobei nur eine Sitzung verwendet wird.

Es ist nicht nötig, eine eigene Client-Server-Kommunikationsschicht für die JavaFX-Handels-Apps zu erstellen ... verwenden Sie einfach auch QuickFix/J dort.

Der Schlüssel mit der Brücke ist, dass sowohl ein Akzeptor als auch ein Initiator erforderlich sind. Der Akzeptor wird zuerst gestartet: Er akzeptiert Verbindungen von den Trading-Apps und vom Initiator der Bridge. Dann wird der Initiator gestartet: Er initiiert eine Verbindung mit dem FIX-Server eines Drittanbieters und mit dem Bridge-Akzeptor. Die Handels-Apps initiieren ihre eigenen FIX-Verbindungen mit dem Bridge-Akzeptor.

Natürlich ist ein wenig Codierung erforderlich, um die Nachrichten innerhalb der Brücke erneut zu senden/weiterzuleiten. Aber dieser Teil ist ziemlich einfach.

Ich habe mir eine einfache Arbeitsdemo mit diesem Design gebaut. Hoffen wir, dass die Umsetzung der Realität reibungslos verläuft.

Hier sind die Links zu dem Arbeits Demo-Projekt (e):

demo-fix-bridge

Verwandte Themen