1 / 31

Plateforme de passages d'ordres boursiers

Plateforme de passages d'ordres boursiers. Etienne Charpentier Jean-Michael Legait Michèle R e ynier Judicaël Ribault. Plan. Cahier des charges Architecture Patterns for e-business Architecture logique Solution applicative Architecture physique Prototype. Cahier des charges.

ksena
Download Presentation

Plateforme de passages d'ordres boursiers

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Plateforme de passages d'ordres boursiers Etienne Charpentier Jean-Michael Legait Michèle Reynier Judicaël Ribault

  2. Plan • Cahier des charges • Architecture • Patterns for e-business • Architecture logique • Solution applicative • Architecture physique • Prototype

  3. Cahier des charges Contexte et contraintes

  4. ContexteRéseau de la banque

  5. ContexteClients visés • Clients individuels • Clients traditionnels Employés d'agence • Internautes • Gros clients : cabinet de placement • Courtiers • Agents à la corbeille

  6. Contraintes fonctionnellesDiagramme de cas d'utilisations

  7. Contraintes non fonctionnellesVolumétrie du système • 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

  8. 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

  9. Architecture Patterns for e-business

  10. 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

  11. 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)

  12. Patterns for e-businessIntegration Patterns • Definition : • Intégration de plusieurs modèles métier • Acces Integration • Application Integration

  13. Patterns for e-businessComposite Patterns • Definition : Combine les différents patterns utilisés pour n'en faire qu'un. • e-Marketplace

  14. Architecture Architecture logique

  15. Architecture logique globale

  16. Architecture logiqueLes clients dans le système Les clients qui vont intéragir avec le systèmes : • Les employés d’agence • Les gros clients • L’agent à la corbeille   • Le courtier

  17. Architecture Solution applicative

  18. 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

  19. 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 conversion Assurance du fonctionnement du client lourd quelque soit la plateforme utilisée • RMI Moins complexe que Corba, donc facilité de maintenance • SWING (Récemment améliorée)

  20. Solution applicativeBases de données Les données stockées en base sont : • Les comptes de bourses • L'historique des passages d'ordres • La 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

  21. Architecture Architecture physique

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

  23. Architecture physiqueRéseau de la banque

  24. Architecture physiqueAgence régionale

  25. 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é

  26. Architecture physiqueSite central

  27. Prototype

  28. PrototypeLoad balancing • Scalabilité • Ajout / Suppression de machine • Tolerance au panne

  29. PrototypePlateforme de test

  30. PrototypeScalabilité • Scalabilité trés importante: • On double les performances en doublant les serveurs • Scalabilité facile a mettre en œuvre : • On ajoute un serveur "à chaud"

  31. 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

More Related