FX3K

Le cas :
Oxford Global Network (http://www.fx3k.com) est venu nous voir avec l'idée de créer un site sur les marchés des changes devant avoir un environnement possédant toutes les caractéristiques suivantes :

Simple, logique, informatif et facile à utiliser
Graphiques sophistiqués des différents indicateurs boursiers et des changes, combinés dans une fenêtre unique.
Cours en temps réels afin de faciliter la prise de décisions rapidement.
Affichage des graphiques sur demande
Données automatiquement mises à jour lorsque l'utilisateur se connecte avec son login.
Utilisation du langage Java qui permet d'éviter à l'utilisateur de télécharger des plug-ins et autres logiciels
Analyses et nouvelles des bourses étrangères
Echange d'opinions en temps réel

La Solution:
The Challenges Idea behind the project was to develop a sophisticated mass-service, real-time financial processing system. Back then, client did not have an IT department, nor programmers on stuff. Thus, first challenge was to establish complete and thorough understanding between the customer (professional traders) on the one hand, and the developers (technoheads) on the other hand. The first order of business was to solve the contradiction between the approaches and even lingoes of, on the one hand, the technical people, who would never get the picture of customer's special field of knowledge with all its intricacies, and, on the other hand, the brokers, who couldn’t understand all details of the system.
Customer had a few basic conditions, which had to be abide by:
a) System must be able to process hundreds
   of users in real time
b) User interface should be Java-driven
c) Stability of all system must be rock-solid
d) Budget was extremely limited, which made Octet developers think twice before choosing among possible solutions (be it hardware or software), always keeping price in mind. There was a general understanding among the developers at this time that use of Java as a front-end for a complicated GUI would bring the application to the speed of a turtle. But use of Java in the interface was a requirement, and the task was as challenging as it was intriguing.

The Solutions
Octet embarked upon a search for the solution, which would allow for a satisfactory performance assuming an average ("typical") PC on user's side.

At first, it seemed that Javasoft JDK was such a solution, but soon the developers realized that drawing all the buttons and pop-up windows, etc. will be extremely time-consuming (and we had to keep the low budget requirement in mind!) Developers got back to more research and digging and found another good tool from Javasoft - Swing JDK Classes, then a beta release only. A careful examination of the tool showed that it was reliable, and, after a consultation with the client (Octet needed to solve the contradiction between the request of reliability and that of low budget – so, we had to inform the client) our developers decided to use Swing JDK Classes before its official release. Octet was positive that it was a brilliant tool for hi-tech extra-complex applications with rich user interfaces. As time has shown, we were right in our analysis, and Javasoft made the first release of their official JDK Classes only two month after we started using its beta version.

Next problem faced by Octet developers was to have all interfaces written in Java and, then, that of developing our own transaction server in Java. Several considerations prevented us from using existing transaction servers (Tuxedo, etc.): had we used them, there would have been a need to change servers too much to fit our task, yet modified servers would remain too heavy for our hardware platform, which we intended to base on Intel PII architecture. Octet looked at brand name solutions from Sun. – It seemed that all Java computations and Oracle-driven database demanded very high CPU speed, assuming several hundreds users will be working simultaneously with the system. But the limited budget was making us at Octet think more than twice about the hardware part of the project as well. So, there we were – forced to use the not-so-powerful Intel servers, (OK, at least we got them shipped to us with Dual CPU configuration), and we had to do all the work with Java-server and Oracle there.

As if our challenges were not tough enough – enter the vital question of operating system: what will be the heart of our system? At that time, Octet was in no mood for experimenting with Windows NT, because we needed an instant and proven solution. The answer was obvious – UNIX, and since we decided to use Oracle and Java, the choice was – Sun Solaris. We have had a significant experience with the system, and knew that there would be no operating system related problems and surprises with Solaris.

Before Octet decided to use Oracle, we were also considering Sybase, but direct comparison of feature lists and available configurations demonstrated that at that time Oracle had more to offer, so opted for Oracle.

The most interesting point in project planning was reached when the question of availability and back-up was brought in. For financial reasons Octet couldn’t use commercial cluster solutions in this system, so we had to develop a solution of our own. The plan was simple in writing, but complex to implement. It was decided that maximum allowed downtime of all system could be 5 minutes. The system had to consist of two identical servers, so we felt that there was only one good solution: backup-standby scheme. – At any time, one server is in production mode servicing the users, while the second is "resting" in standby mode, retrieving all real-time information from the first one by an independent full duplex 100Mbps link.

Octet decided that no real load balancing will take place because there wasn’t enough time to implement some of our own, and the only way to go was to use commercial solution – but this was something we couldn't do because it was beyond the budget. When production server experiences a failure of any kind it is substituted by standby server – it all takes 5 minutes and only a very few transactions would be lost (those incomplete during the failure period). Users would receive confirmations for every action, so if no acknowledgment is received from the system, the action is repeated. Octet used SSL for encryption of data transfer between the system and users, in case of substitution of servers all such connections would be closed and users would have to reconnect to the system. – The process of reconnection, while disturbing for users, would, in the one hand, ensure great security and, on the other hand, be merely a matter of clicking the "Reload" button in user's browser.