Projet Enchères

INF4402 – Systèmes répartis sur Internet
06/11/09
Laboratoire 2
Développement d'un marché d'enchères électronique
Équipe : GENTIL Adrien 1499297
KIRCHNER Dimitri 1502458
KRANTZ Xavier 1495708
1
INF4402 – Systèmes répartis sur Internet
06/11/09
Introduction
La réalisation de ce deuxième laboratoire nous permet de mettre en évidence quelques problèmes intrinsèques à la notion de systèmes répartis. En effet, durant ce travail pratique, nous avons du abordé des notions nouvelles, telles que la concurrence ou le temps universel. Ce laboratoire nous a donc permis de nous poser de nombreuses questions quand à la bonne réalisation qu'il fallait entreprendre.
I. Un diagramme de classes
Diagramme de classes de l'application
2
INF4402 – Systèmes répartis sur Internet
06/11/09
Diagramme de séquence
Description : Sur notre diagramme de classe, nous observons bien les 4 classes minimales de notre applications que sont le client et les 3 serveurs Ebay, Paypal et CreditCheck. Nous pouvons noter la référence croisée entre les serveurs Paypal et Ebay afin de traiter la connexion du client. Comme spécifié dans l'énoncé, le client effectue une demande de connexion à Paypal qui, si autorisée, transmettra la référence du client à Ebay pour que ce dernier puisse lui transmettre les informations des enchères par processus de callback. Afin de permettre à un client de se connecter avec deux instances différentes du programme, nous avons crée un objet "Session". Ce dernier est nécessaire car lors de la connexion, Paypal doit retourner le montant du compte au client. Il doit également lui retourner un identifiant de session afin de reconnaitre l'instance du client lors de la déconnexion. Cet objet session est transmit dans pratiquement tous les échanges avec une instance du client. Puisque que le client, en tant que personne, est identifiée de manière unique par son pseudo sur CreditCheck, cet attribut fait également parti de l'objet session. L'objet comporte donc le pseudo unique du client, son identifiant de session et le montant de son compte à la connexion.
Nous pouvons également soulever la présence de l'objet "Bid" qui représente une enchère sur un livre. Cet objet est référencé dans un vecteur de Ebay qui doit les gérer et est accessible par le client pour qu'il puisse réaliser une mise.
3
INF4402 – Systèmes répartis sur Internet
06/11/09
II. Questions
A. Identification des problèmes de concurrence et de temps universel reliés au système.
Les systèmes répartis possèdent comme caractéristiques principales des composantes autonomes et concurrentes ainsi qu'une absence de notion commune de temps entre ces composantes.
Dans notre application d'enchère, nous faisons face à un problème de concurrence lorsque plusieurs clients désirent déposer une enchère en même temps sur un même objet et lors de l'accès au compte d'un client (lecture du montant, modification lors de payement, de pénalité ou par un autre service future). Pour éviter que les données d'un client A ne soit écrasée par celle d'un autre client B, nous devons préserver l'ordre d'accès à la valeur de ces éléments. Pour cela, nous avons utilisé des sémaphores, qui agissent comme des verrous grâce aux instructions acquire() et release(). Dans ce type de pratique (enchères) il est de rigueur d'accorder la priorité au client qui a initialisé la requête le premier. Dans notre cas, et pour des raisons de simplicité, nous accordons la priorité à la première requête arrivée au serveur PolyEbay. Lorsqu'une requête est traitée par le serveur, le sémaphore est acquis et empêche l'accès à la valeur par une autre requête concurrente. Lorsque la modification de la valeur de cette enchère est achevée, le verrous est relâché et une autre enchère peut être soumise. Ce mécanisme permet de gérer les problèmes de synchronisation et de concurrence. Un second aspect important dans les systèmes répartis est celle de temps universel. En effet, comment faire pour conserver un système cohérent alors que notre application est répartie sur plusieurs machines physiquement séparées, qui effectuent des actions différentes et souvent asynchrones. Étant donné que nous ne pouvions utiliser la notion synchronised de JAVA, la solution que nous proposons est de baser notre système uniquement sur le temps d'une machine de référence. Dans notre cas, la machine qui se doit de maintenir une notion de temporalité envers les client est PolyEbay. Ainsi, à chaque fois que quelqu'un veut indiquer l'heure d'une transaction, il effectue un getTime() sur Ebay afin de satisfaire sa demande. Cette solution convient parfaitement dans le cas de notre laboratoire, cependant, si les serveurs Paypal ou CreditCheck peuvent être accédés par d'autres services (en effet, dans la vie réelle, le service PayPal est utilisé par beaucoup d'autres serveurs que Ebay), cela ne fonctionnerai plus.
B. Environnement et procédure de test.
Pour tester les problèmes de concurrence au niveau des enchères, nous avons lancé plusieurs instances de clients différents et effectué des enchères de façon simultanées. On a pu alors constater que l'utilisation des sémaphores nous permettait de conserver des valeurs cohérentes.
En ce qui concerne la concurrence sur le montant du compte d'un client, nous avons cette fois ci lancé plusieurs instances différentes d'un même client, et réalisé des enchères sur des livres différents. Identiquement, les sémaphores permettent que le compte se fasse bien débiter des deux enchères, qu'un client ne puisse pas acheter deux livres si la somme totale est supérieure au montant présent sur son compte et qu'une deuxième instance d'un client ne puisse pas se connecter si après un achat réalisée par la première instance rend son compte invalide (<0).
Un troisième problème de concurrence a été mis en évidence dans le cas de la gestion des références des clients dans le vecteur du serveur Ebay (enregistrement d'une instance d'un client en même temps que le déconnexion d'une autre). Comme précédemment, les sémaphores nous ont permis de résoudre ce problème découvert.
4
INF4402 – Systèmes répartis sur Internet
06/11/09
Au niveau du temps universel, nous avons testé notre application sur des ordinateurs différents, n'ayant pas la même horloge interne. Le fait de prendre le serveur Ebay comme référence temporelle résout nos problèmes.
C. RMI est une spécialisation du protocole RPC. Expliquez les différences et similarités entre les deux technologies.
Le protocole RPC, Remote Procedure Call, est une technologie de communication inter­processus qui permet à un programme exécuté sur un ordinateur d'appeler une fonction qui sera exécutée sur un autre ordinateur présent généralement sur le réseau. Ce modèle de programmation permet l'utilisation de fonctions distantes sans que le programmeur n'ai à se soucier du code qu'il serait nécessaire de développer pour assurer les transmissions des informations sur le réseau. L'appel des fonctions est transparent et se fait de la même manière qu'un appel locale. Concrètement, le programmeur perçoit les fonctions distantes à l'image d'une interface. RPC se charge intégralement de l'échange de l'information sur le réseau (sérialisation) et peut utiliser UDP ou TCP. Il transmet ainsi les données à la fonction de la machine distante qui traite la requête. Cette dernière renvoie le résultat et RPC le transmet à la fonction appelante. L'implémentation la plus importante du principe de RPC fût réalisé par SUN avec son modèle ONC, utilisé comme base de son système de fichier NFS. Cependant, le système RPC ne permet que de faire des appels de fonctions de manière procédurale en spécifiant les paramètres d'entrées et en ne pouvant obtenir que des données de types primitifs en retour.
Le langage RMI, développé comme extension au langage Java, est très semblable à RPC dans son principe de fonctionnement. De la même manière, les machines distantes ne sont accessibles qu'à partir d'un interface (ensemble de méthodes et d'objet accessibles) et le programmeur qui souhaite utiliser ces fonctions n'a pas à se préoccuper de leur fonctionnement. Ainsi, un changement dans le code de la fonction distante ne vient pas perturber son utilisation dans les programmes clients. La principal différence entre le modèle RPC classique comme ONC et l'API RMI est la notion de programmation orientée objet. Il est possible de transmettre un objet complet ou une référence à un objet et ainsi de développer la complexité des données. Cependant, l'utilisation de RMI se fait uniquement entre machines virtuelles Java et est donc contraignante au niveau du langage utilisé. sources : ­ http://en.wikipedia.org/wiki/Remote_procedure_call
­ http://en.wikipedia.org/wiki/ONC_RPC
­ http://en.wikipedia.org/wiki/Java_remote_method_invocation
­ http://www.cs.cf.ac.uk/Dave/C/node33.html
5
INF4402 – Systèmes répartis sur Internet
06/11/09
D. XML­RPC est une nouvelle technologie qui est semblable à celui de RMI. Décrire les avantages et désavantages de l’utilisation de XML­RPC pour la construction d’applications réparties comme celui de ce TP.
Le XML­RPC est une technologie basée sur le langage XML pour l'encodage et le format des données et utilise le protocole HTTP comme vecteur de transmission. Le XML­RPC est à la base des nouvelles technologie et standards de l'internet qui sont SOAP et JSON­RPC. Le XML, eXtensible Markup Layer, est un langage de formatage de données qui est en pleine explosion puisque sa syntaxe est à la fois strict et structurée mais également souple dans ses définitions. Le SOAP est déjà utilisé par très nombreux et importants acteurs de l'internet tel que Microsoft dans sa messagerie internet "hotmail".
XML­RPC est vraiment un protocole d'appel et de transmission de l'information. A chaque extrémité doit se trouver sur les machines clientes et serveurs des programmes qui doivent décoder / encoder les données XML et les transmettre via HTTP. L'avantage de cette technologie est qu'elle est basée sur deux standard de l'internet et qu'elle garantie ainsi la transmission sur des systèmes hétérogènes, à travers les serveurs mandataires et les pare­feux. De plus, puisque XML­RPC se cantonne à son rôle de Protocole de relai, les applications serveur et clientes peuvent être codées dans des langages totalement différents. Dans le cas de notre TP, RMI semble plus adapté car il : • permet d'utiliser la notion de "socket" et donc d'envoyer des messages à une application dédiée,;
• permet de réutiliser des systèmes existants, registry et autres servers JAVA existants; • est très simple à programmer et à déployer;
• propose un environnement complet avec le contrôle de connexion via le Registry, les bibliothèques Java, les mécanismes de sécurité qui protège le système et le réseau; • est portable avec l'environnement de la machine virtuelle Java
Sources: ­ http://www.abrillant.com/doc/soap/index.htm
­ http://www.xmlrpc.com/
- http://cfs.tistory.com/ Tata Consultancy services RMI vs RPC
6
INF4402 – Systèmes répartis sur Internet
06/11/09
III. Exécution
Conclusion
La réalisation de ce TP nous a permis de comprendre les concepts de synchronisation reliés au systèmes distribués, de développer nos connaissances sur les contrôles de concurrence, afin de pouvoir développer des systèmes de transactions réparties. 7