Implémenter des traitements asynchrones dans une application ?

Bonjour,

Je souhaite développer un ATS ( automatique trading system ) en utilisant les API d'Interactive Brokers :
http://www.interactivebrokers.com

Java API Quick Reference
Java API Quick Reference

Ces API sont asynchrones.
Si je souhaite connaitre toutes les 5 secondes l'évolution des cours d'une action, mon programme doit faire une requette, et ensuite il reçoit les cours toutes les 5 secondes.
Je fais une requette par reqRealTimeBars().
Et je suis informé de l'évolution des cours par realtimeBar()

Il existe un programme écrit en Java qui a implémenté un tel ATS.
C'est JSystemtrader :
JSystemTrader

Sauf erreur de ma part, ce programme lance autant de thread, qu'il souhaite traiter de valeur avec une certaine stratégie.
les requettes vers l'API d'IB sont lancées depuis le programme principal.
Les réponses à ces requettes sont reçues par le programme principal, puis sont diffusées par le programme principal vers les différents threads concernés.
Je souhaite pouvoir disposer de fonctionnalités que n'a pas JSystemTrader, le multi time frame, etc.
Je pense que pour bénéficier de telles fonctionnalités le mieux est de repartir de zéro.

Mon idée d'implémentation :
L'application principale ne fait que lancer deux threads.
Le thread A qui est une instance d'une classe façade autour de l'API d'IB.
Le thread B qui gère les instances des stratégies de trading.

Le thread A reçoit les demandes de types reqRealTimeBars() faites pas le thread B, et exécute ces demandes.
Puis place les réponses faites par realtimeBar() dans une queue de type FIFO.
Signale au thread B que des données sont à traiter.
Le thread B traite séquentiellement les données de la piles FIFO tant qu'il y a des données à traiter.

Que pensez-vous de mon projet d'implantation ?

Pour faire un nouveau programme, il faut apporter de nouvelles fonctions, ou bien bénéficier d'une meilleure technologique qui permet de mieux écrire des choses déjà faites, ou changer de licence, ou...

J'ai l'impression que tu te situerais dans le deuxième cas. Mais es-tu sûr que le fait de n'écrire que 2 threads au lieu de 36 apportera quelque chose ?

Citation:

---

Envoyé par gifffftane

Pour faire un nouveau programme, il faut apporter de nouvelles fonctions, ou bien bénéficier d'une meilleure technologique qui permet de mieux écrire des choses déjà faites, ou changer de licence, ou...

J'ai l'impression que tu te situerais dans le deuxième cas. Mais es-tu sûr que le fait de n'écrire que 2 threads au lieu de 36 apportera quelque chose ?

---

Réduire le nombre de threads n'est pas la motivation première.
La motivation première de refaire ce programme, c'est de le comprendre mieux.
La motivation première de comprendre mieux ce programme, c'est de pouvoir ensuite apporter des modifications sans ajouter des bugs.

Je me demande même si je ne vais pas utiliser un seul thread.
En fait je me suis mis dans la tête d'utiliser plusieurs threads pour bien séparer le traitement de la communication du socket, de la logique des stratégies.
Mais il est possible que cela complique au lieu de simplifier ?

Le nombre de threads n'est pas à lui seul suffisant pour savoir si cela complique ou simplifie ; c'est l'adéquation, par rapport aux propriétés de ce que l'on veut informatiser, et à celles de l'outil informatique que tu utilises, qui te dira si ça simplifie ou pas. D'où ma première question.

Par exemple, si tu programmes en swing, une contrainte forte est que tu devras faire les traitements graphiques dans l'EDT ; comme si j'ai bien compris tu reçois des données extérieures, tu seras obligé d'avoir au moins deux threads.

Si ton autre souhait est de comprendre un autre programme (c'est à dire je suppose les traitements qu'il fait), utilise le système papier/crayon/pomme de terre, matiné d'un peu d'UML, en programmant au fur et à mesure tes trouvailles, et en élaborant au fur et à mesure des tests.

Bonne continuation.