Plateforme de passages d'ordres boursiersEtienne CharpentierJean-Michael LegaitMichèle ReynierJudicaël Ribault

Plan• Cahier des charges• Architecture– Patterns for e-business– Architecture logique– Solution applicative– Architecture physique

• Prototype

Cahier des chargesCONTEXTE ET CONTRAINTES

ContexteRéseau de la banque

ContexteClients visés• Clients individuels– Clients traditionnels Employés d'agence– Internautes

• Gros clients : cabinet de placement• Courtiers• Agents à la corbeille

Contraintes fonctionnellesDiagramme de cas d'utilisations

Contraintes non fonctionnellesVolumétrie du système

Type de client Nombre de clients Requêtes par jour et par clients

Total (requêtes par jour)

Internaute averti 200 00 50 lectures1 écriture

10M lectures200 000 écritures

Employé d’agence 1 200 10 écritures 12 000 écrituresEmployé de Gros client

200 5 000 lectures100 écritures

1M lectures20 000 écritures

Agent à la corbeille 100 120 000*5 lectures100 écritures

60M lectures10 000 écritures

TOTAL 71M lectures242 000 écritures

• 10 courtiers et chaque courtier a 10 fois moins de clients que la banque

• 400 agences et 3 employés par agence• 20 Gros clients et 10 employés par Gros client• Chaque agent à la corbeille suit 5 valeurs

Contraintes non fonctionnellesQualité de service• Gros client/agent à la corbeille

Délai d'exécution < 400ms• Agents à la corbeille

Débit minimal = 2Mo/s• Taux de disponibilité

99,99% soit 52min et 33s d'indisponibilité par an

ArchitecturePATTERNS FOR E-BUSINESS

Patterns for e-businessDéfinition

• Mis à disposition par IBM

• Manière simple de traduire les besoins de l'entreprise en solutions techniques

• Solutions déduites de milliers de projets e-business

Patterns for e-businessBusiness Patterns• Definition:– Décrivent les interactions

utilisateurs/entreprises/données

• Nos besoins :– Passer un ordre de bourse

Self-Service (User-to-Business)

– Consulter le cours de la bourse Information aggregation (User-to-Data)

Patterns for e-businessIntegration Patterns• Definition :– Intégration de plusieurs modèles métier

• Acces Integration

• Application Integration

Patterns for e-businessComposite Patterns• Definition : Combine les différents

patterns utilisés pour n'en faire qu'un.

• e-Marketplace

ArchitectureARCHITECTURE LOGIQUE

Architecture logique globale

Architecture logiqueLes clients dans le système

Les clients qui vont intéragir avec le systèmes :Les employés d’agenceLes gros clientsL’agent à la corbeille  Le courtier

ArchitectureSOLUTION APPLICATIVE

Solution applicativeServeur d'application• Choix de la plateforme logicielle :

– PHP• Complexité de développement

– La persistance n'est pas gérée automatiquement– Pas de système transactionnel

– .Net et C#• Manque de maturité (Version finale : Janvier 2002)• Lié aux environnements Windows• Serveur Microsoft moins fiable qu'un serveur Unix

– J2EE et EJB sur serveur Unix• Maturité (fin 1999)• Richesse de l'API Java• Indépendance de plate-forme• Performance de Java améliorée

• Tolérance aux pannes :– Les requêtes en cours de traitement et leur état sont stokés en

base de données

Solution applicativeClients lourds• Client lourd :– Eviter les systèmes de session– Mise en place d'une connexion TCP permanente

avec utilisation des clefs et certificats pour l'identification

• Choix d'implémentation :– Java

Serveur également Java, évite une couche de conversionAssurance du fonctionnement du client lourd quelque soit la plateforme utilisée

– RMIMoins complexe que Corba, donc facilité de maintenance

– SWING (Récemment améliorée)

Solution applicativeBases de donnéesLes données stockées en base sont :

Les comptes de boursesL'historique des passages d'ordresLa file de requêtes à traiter

• Données simples– Ne justifie pas l'approche objet

• Base de données Objet et XML n'ont pas encore atteint la maturité et les performances des bases de données relationnelles

ArchitectureARCHITECTURE PHYSIQUE

Architecture physiqueEmplacement des acteurs• Les gros clients• Les internautes• Les agents à la corbeille• Les courtiers

Architecture physiqueRéseau de la banque

Architecture physiqueAgence régionale

Architecture physiqueSite central• A partir des Patterns for E-business d'IBM• Architecture extremement robuste– Disponibilité de 99,99%– Perdre aucun ordre même en cas de panne– Temps de réponse très bas

• Scalabilité importante– Réactivité

Architecture physiqueSite central

Prototype

PrototypeLoad balancing• Scalabilité– Ajout / Suppression de machine

• Tolerance au panne

PrototypePlateforme de test

PrototypeScalabilité• Scalabilité trés importante:– On double les performances en doublant les

serveurs

• Scalabilité facile a mettre en œuvre :– On ajoute un serveur "à chaud"

1 serveur 2 serveurs0

5

10

15

20

25

30

PrototypeTolérance au panne• Création d'une panne du serveur web

– Le traffic est entierement dirigé vers le seul serveur actif– Toutes les requetes sont satisfaites (997 / 1000)

• Les requetes en cours de traitements lorsque est survenu la panne ne peuvent etre traité– Mise en place d'un mecanisme de reprise à l'aide d'une

journalisation

requêtes réussiesrequêtes échouées