NSY 107 : Intégration des systèmes client-serveur - desvigne.org
Correction de l'examen du 01/07/2006 .... qu'il est possible de faire entre le
modèle OSI et l'utilisation des concepts RPC et XDR (1 pt). Dans ce schéma, vu
du ...
part of the document
NSY 107 : Intégration des systèmes client-serveurCorrection de lexamen du 01/07/2006
Partie I : QCM
1) Il est impossible de concevoir un programme client et un serveur mélangeant le mode « datagramme » et le mode « connecté » (ces deux modes étant incompatibles) Vrai ( Faux (
Commentaire : en effet, il est tout à fait possible de créer un serveur qui :
offre le même service en UDP et en TCP sur le même numéro de port,
ou encore, dinventer un protocole client/serveur qui dialogue en UDP, et qui ouvre de temps en temps des liaisons TCP pour transmettre de longs flux ; ou inversement, qui ouvrent un canal TCP, et qui échangent des informations de signalisation en UDP. Pour conclure : seule votre imagination est une limite
2) Les « web services » sont des mécanismes client/serveur dans lesquels les flux échangés sont du XML ? Vrai ( Faux (
Commentaire : les web services sappuient sur le protocole HTTP ; autrement dit, les données échangées sont encapsulées dans du HTTP. Mais rien nest dit sur la nature de ce qui est échangé : ça peut être du XML, mais aussi tout autre chose (du HTML, un texte en ASCII, etc.).
3) Lors de lévaluation de la sécurité de vos serveurs au niveau physique, les constructeurs fournissent des informations statistiques pouvant vous aider à prendre une décision ? Vrai ( Faux (
Commentaire : cest le rôle du MTBF (Mean Time Between Failure).
4) Dans un réseau Ethernet utilisant le protocole spaning tree (STP v. 1), faire une boucle entre tous les commutateurs augmente la redondance des liens, donc, le niveau de sécurité ? Vrai ( Faux (
Commentaire : cest effectivement ce quon pourrait penser : en faisant une boucle, si un lien se casse, il suffit de passer par lautre chemin de la boucle. Mais en pratique, avec STP, faire une boucle a des conséquences catastrophiques : les commutateurs narrivent plus à cartographier le réseau, les tables dadresses mac « rebondissent » entre tous les commutateurs, et le réseau tombe en quelques instants.
5) Dans larchitecture CORBA, IDL est un langage de description des interfaces des différents objets qui, une fois compilé, génère automatiquement le squelette de certains programmes ? Vrai ( Faux (
Commentaire : cest effectivement un des atouts de CORBA. Il est possible de définir les APIs des différents objets dans ce langage IDL, et un compilateur IDL génère le squelette de la future solution, dans le langage que vous voulez (Cobol (, C, C++, ADA, etc.).
6) Il est possible de compiler du code écrit en JAVA dans lenvironnement de programmation Microsoft .NET ? Vrai ( Faux (
Commentaire : tout à fait exact. Microsoft a sorti le compilateur J# (prononcer « J chart ») à cet effet. Evidement, linverse est impossible (compiler du C# ou du Visual Basic dans lenvironnement de développement Java).
7) Un middleware est un connecteur permettant de rendre un programme utilisant des requêtes SQL indépendant du système de gestion de base de données (SGBD) utilisé ? Vrai ( Faux (
Commentaire : cest justement linverse. La phrase correcte est « Un connecteur est un middleware permettant de rendre un programme utilisant des requêtes SQL indépendant du SGBD utilisé ». Le connecteur est un middleware, mais tous les middleware ne sont pas des connecteurs (de façon générale, un middleware est un adaptateur de protocole entre un client et un serveur).
8) Dans une architecture N-tiers, les composantes suivantes sont indispensables (cochez les réponses vraies) : Firewall ( Navigateur web ( SGBD ( Routeur ( Logiciel client (
Commentaire :
le firewall nest indiqué que si le client est sur un réseau public (Internet par exemple). Il est déjà moins indispensable dans un LAN isolé ;
le navigateur web est un client possible. Mais il y a des architectures ou le client nest pas un navigateur, mais un programme spécifique ;
évidemment, SGBD et logiciel client sont deux couches du modèle 3-tiers ; alors, à fortiori, du N-tiers.
pas besoin de routeur si tous les éléments (clients, serveurs, SGBD) sont sur le même réseau IP. Dailleurs, de façon générale, larchitecture N-tiers nimpose rien du point de vue réseau.
9) Un logiciel antivirus assurant une protection « temps réel » est capable de bloquer toutes les attaques virales dont il possède la signature ? Vrai ( Faux (
Commentaire : malheureusement non, pas *toutes* les attaques. Ils vérifient les accès aux fichiers, les flux réseau, etc. Mais nous avons vu par exemple les attaques par « dépassement de pile ». Les antivirus temps réel ne savent pas détecter les infiltrations de ce type. Tout au plus, ils détectent au bout dun instant que la machine est infectée, ils arrivent parfois même à éradiquer le virus. Mais il sagit alors dun traitement à posteriori, pas dune détection/blocage en temps réel.
10) Lutilisation du protocole XDR permet à des micro-ordinateurs PC ou Macintosh de dialoguer avec des serveurs RS-6000 ? Vrai ( Faux (
Commentaire : pourquoi pas ? En effet, XDR permet les échanges de données entre machines ayant des représentations internes différentes (couche présentation du modèle OSI). Alors pourquoi pas PC/RS6000, ou Macintosh/RS6000. PC, Mac, et RS6000 ne sont que 3 exemples parmi tant dautres possibles.
Partie II : Questions ouvertes (5 points)
1) Faire un schéma illustrant le parallèle quil est possible de faire entre le modèle OSI et lutilisation des concepts RPC et XDR (1 pt). Dans ce schéma, vu du programmeur, quelle est la différence entre lappel aux fonctions de la couche « XDR » et lappel aux fonctions de toutes les autres couches inférieures (1/2 pt) ?
Pour le schéma, la question était simple, la réponse étant fournie dans le tout premier cours (diapo 14). Il y avait juste à faire un peu de filtrage (notez quil fallait bien mettre TCP et UDP en couche transport ; sinon, ½ pt) :
La deuxième question faisait plus appel à votre réflexion : lorsque vous programmez une application, et que vous faites appel aux fonctions de la bibliothèque XDR, ces fonctions font le transcodage des données, puis vous rendent la main. Cest alors à vous dappeler ensuite les fonctions de la couche inférieure (RPC). Alors que tous les autres appels aux fonctions des couches 5 et inférieures font eux même appel à la couche inférieure, et ce, de couche en couche, de façon automatique (RPC appelle UDP ou TCP qui appelle IP qui utilise la carte réseau
). Cest dailleurs une des raisons qui fait que souvent, les couches 5, 6, et 7 sont regroupées en une seule.
2) Vous êtes nommé cadre supérieur dans une grande entreprise de production de produits manufacturés. Après une brève analyse de lexistant, vous vous rendez compte que votre société na pas de politique de sécurité de son système dinformation. Ayant suivi le cours NSY107, vous savez quune telle situation est dangereuse. Aussi, vous décidez de mettre en place une politique de sécurité. Quelles seront les 4 premières étapes de ce projet (2 pts) ?
Etape 1 : faire adhérer cette idée par léquipe de direction, et leur faire inscrire une ligne budgétaire (les décideurs doivent cautionner le projet, et mettre les moyens en face ; sinon, inutile daller plus loin).
Etape 2 : désigner le RSSI (responsable sécurité du système dinformation). Cest lui qui portera le projet.
Etape 3 : évaluer les risques : faire linventaire exhaustif des contraintes réglementaires et législatives entourant votre activité, et voir les conséquences en terme de système dinformation (traçabilité, obligations darchivage, etc.). Faire le même travail avec votre production (en quelle mesure une panne informatique a des effets sur la production de votre usine ? Sur les relations commerciales ? Sur la santé de votre personnel, sur lenvironnement, etc.).
Etape 4 : plusieurs réponses/nuances sont possibles et seront acceptées : bilan de lexistant, définir un schéma cible, définir un calendrier dactions, faire réaliser un audit externe, etc.
3) En général, les progiciels permettent lédition détats prédéfinis. Et souvent, il est possible de faire des requêtes dans le système de gestion de base de données utilisée par ces progiciels, vous permettant ainsi de calculer certains indicateurs. Pourtant, une grande majorité dentreprises met en place des « datawarehouse » et utilise des langages de 4ème génération (L4G) pour faire du « datamining ». Pourquoi quels sont les avantages de cette dernière solution (1,5 pt) ?
Trois bons arguments permettront de faire le plein des 1,5 points. En voici 3 (il y a certainement dautres qui seront aussi acceptés) :
faire des requêtes - qui peuvent être complexes - directement sur un SGBD en production peut savérer gourmand en ressources machines, et pénaliser les utilisateurs. Alors quen recopiant les données sur une base annexe, il est alors possible de faire de gros traitement sur cette base sans perturber le travail des utilisateurs ;
les progiciels ne contiennent que les données de leur domaine de compétences (le logiciel de compta ne contient que les données financières, le logiciel de GRH que les données sur le personnel, etc.). Or, les datawarehouse collectent des données depuis plusieurs applicatifs. Il devient alors possible de croiser des informations de domaines fonctionnels différents ;
les L4G proposent des outils de présentation, de calcul, etc. Il est donc inutile de réinventer la roue à chaque fois que vous souhaitez construire un tableau de bord.
Partie III : Problème technique (5 points)
Des investisseurs souhaitent créer une société de vente par correspondance de billets davions « low cost » sur Internet : « lowcostfly.com ». Au début de lhistoire de cette société, la montée en charge de lactivité risque dêtre chaotique ; en terme informatique, le site aura à sadapter à des augmentations soudaines du nombre de visites et de transactions.
Vous êtes désigné pour proposer une architecture informatique de ce nouveau site. Dans votre cahier des charges, les contraintes qui vous sont imposées sont :
pour anticiper ces futures crises de croissance, et pour rendre les différents développements le plus indépendant possible de solutions commerciales particulières, vous devez vous orienter vers une architecture N-tiers ;
pour connaître les promotions et offres de dernière minute faites par les compagnies aériennes, votre système devra interroger très régulièrement leurs catalogues en ligne (sachant quil nexiste pas un protocole unique pour interroger ces catalogues, chaque entreprise ayant sa propre solution informatique, incompatible avec celle du concurrent). Les commandes enregistrées sur votre site devront immédiatement être transférées auprès de la compagnie concernée ;
enfin, votre commerce étant très lié à la disponibilité de votre site, les investisseurs sont près à supporter les coûts liés à la duplication de la salle machine sur deux sites éloignés.
Lors de létude préliminaire, on vous demande de proposer un schéma de larchitecture cible répondant à ces contraintes et objectifs. Nhésitez pas à compléter ce schéma de quelques mots pour justifier les choix qui ne semblent pas nécessairement évidents, ou pour expliquer le rôle de certains éléments.
Remarque : à ce stade du projet, on vous demande une architecture générale ; on ne vous demande pas encore de faire de choix de langage de développement, de modèle de programmation réseau, etc. Vous devez simplement lister et positionner les grands « services » que vous aurez à mettre en place.
Voici (ci-dessous) un schéma possible. Evidemment, il existe quelques variantes à ce schéma, qui seront elles aussi acceptées. Voici quelques explications :
tout dabord, il faut enregistrer le nom de domaine « lowcostfly.com » auprès dun « registar ». Aussi, il faudra dans votre réseau final un serveur DNS principal, et par sécurité, un serveur DNS secondaire ;
pour gérer les autorisations daccès aux ressources partagées et aux différents applicatifs, la mise en place dun serveur dauthentification (un sur chaque site) est appropriée.
aujourdhui, il serait très risqué de monter un site web commercial sans mettre linfrastructure de sécurité ad hoc (routeur VPN, firewall, etc). Le firewall protègera le réseau interne des attaques pouvant provenir dInternet. Le routeur VPN permet de créer un réseau privé virtuel (lien totalement sécurisé) entre les deux sites permettra :
la synchronisation des DNS,
la synchronisation des serveurs dauthentification,
la synchronisation des SGBD,
les sauvegardes des fichiers dun site sur un autre,
etc.
le cur de larchitecture N-tiers :
le client, qui utilise un navigateur web ;
les serveurs applicatifs, la charge étant répartie par un « front-end » (remarque : il est possible de détailler, en détaillant cette grappe de serveurs applicatifs en deux classes : les applications métier i.e. la gestion du site lowcostfly.com , et les services « standards » ou « communs » comme le serveur demails, le serveur dimpression, etc. ) ;
le serveur de stockage, qui optimise les accès aux objets stockés à laide dun cache, et qui accède au SGBD à travers un connecteur (afin de rendre les applicatifs les plus indépendants du SGBD mis en place).
Un middleware (sur chaque site), dont le rôle sera :
De télécharger régulièrement les tarifs des compagnies aériennes depuis leurs systèmes dinformation, et dy enregistrer les commandes (notion de B2B : business to business),
De permettre le télépaiement avec un système bancaire.
Le résultat final doit ressembler à :
EMBED PowerPoint.Slide.8
Partie IV : Note de synthèse (5 points)
A la lecture de ces trois extrais darticle, et selon vos connaissances, indiquez les points communs/différences, avantages/inconvénients des 2 générations de RPC : XML-RPC et SOAP, versus les RPC de Sun couplé à XDR.
SHAPE \* MERGEFORMAT
La note de synthèse est un exercice de style où souvent, la forme a presque autant dimportance que le fond. Une des difficultés est de savoir sil faut se contenter des informations contenues dans les documents (cest plutôt le cas pour les examens « littéraires »), ou sil est autorisé dutiliser sa culture personnelle (souvent le cas pour les examens plus techniques). Quand aucune règle du jeu nest donnée, force est de constater que la règle est souvent « notateur dépendant ». Heureusement, ici, la règle du jeu était donnée : « [
]et selon vos connaissances[
] ». Pour autant, le sujet étant assez fermé, et les textes donnés pointant sur la quasi-totalité des arguments, il ny a pas beaucoup à aller chercher dans « nos connaissances ».
Pour la forme, la note de synthèse se rédige comme des rédactions ou dissertations classiques : thèse/antithèse/synthèse, ou encore, faire dialoguer les textes entre eux, etc. Une chose est importante : votre texte doit toujours avoir un plan évident. A savoir :
une introduction, qui rappelle la problématique et éventuellement, pose quelques définitions. Le plan de ce qui suit doit être annoncé à lissue de lintroduction. Cest dailleurs une des raisons pour laquelle lintroduction doit souvent être rédigée en dernier ;
un développement (argumenté),
et une conclusion.
Revenons à notre sujet. On nous demande de comparer deux générations de technologies : Sun RPC, et le couple XML-RPC et SOAP. Normalement, les textes doivent pointer sur les sujets que nous avons à reprendre. Lisons-les :
1) le texte « SOAP, XML-RPC, et REST :
» (que nous noterons par la suite [Texte1]) : SOAP et XML-RPC ont des origines communes. Il sagit de service web (autrement dit, il sagit de web services ; nous savons aussi que ces web services échangent du XML ; le texte précise dailleurs quil sagit de protocoles « verbeux » - comprendre bavards -). On apprend que XML-RPC laisse transiter les mots de passe en clair, contrairement à SOAP. Sous-entendu : ce qui nest pas un mot de passe, avec ces deux technologies, transite en clair. Cest plutôt moyen en termes de sécurité.
2) le texte « Portmap et les RPC
» (que nous noterons par la suite [Texte2]) : RPC utilise un mécanisme qui permet de rendre disponible la liste de services proposés, au travers dun serveur : le « portmap » (qui nexiste pas avec SOUP et XML-RPC). Les échanges entre client et serveur se fait via la couche de présentation des données : XDR (qui nest pas du XML, et qui nest pas chiffré non plus).
3) le texte « XML, Soap, WSDL, et UDDI :
» (que nous noterons par la suite [Texte3]) : on a confirmation que XML-RPC et SOAP sont des web services (ils sappuient sur le protocole HTTP). On a confirmation que ces mécanismes ne sont pas sécurisés : pas de chiffrement, ni de mécanisme dauthentification (on nous dit même quil faut ajouter une couche SAML pour sécuriser tout ça). Remarque : les plus cultivés dentre vous savent aussi (information donnée en cours) que les Sun RPC sont de moins en moins activés sur les différents serveurs, ce mécanisme ouvrant souvent de nombreuses failles de sécurité.
Ce travail de lecture terminé, il ne reste plus quà établir un plan détaillé (ce que nous allons faire ci-dessous), et à transformer ce plan en joli français (ce qui nest pas fait dans la présente correction ; les plus courageux des lecteurs peuvent sy coller).
Plan détaillé (dune correction possible) :
Introduction : les RPC de Sun, ainsi que XML-RPC et SOAP sont des mécanismes dappel de procédure à distance. Nous allons voir que les premiers, de conception ancienne, avaient pourtant quelques avantages, qui ne se retrouvent plus dans les seconds. Nous verrons ensuite que les philosophies de ces deux générations de RPC sont assez différentes, ce qui engendre des conséquences en terme de bande passante et de performance. Enfin, nous verrons que tous ces RPC, peut-être pour des raisons parfois différentes, sont peu sécurisés.
Partie 1 : Dans [Texte 2], il est rappelé que les Sun-RPC doivent senregistrer auprès dun service : le portmapper. Il est ainsi possible, en interrogeant ce portmapper, de savoir quels sont les services proposés par un serveur. Ce mécanisme nexiste plus avec XML-RPC et SOAP.
Partie 2 : Lors de lutilisation de Sun-RPC, le client et le serveur dialoguent directement, en échangeant des informations sur des sockets. Or, [Texte 3] nous rappelle que pour XML-RPC et SOAP, le dialogue client-serveur se fait en utilisant le protocole HTTP (les requêtes sont encapsulées dans des requêtes HTTP). Or, nous savons que ces techniques dencapsulation sont moins performantes. De plus, les Sun-RPC utilisent XDR comme format de représentation des données. Ce format est bien plus condensé, alors que XML est plus bavard, comme rappelé dans [Texte 1]. Ce même texte nous indique aussi que cet inconvénient est contrebalancé par le fait que les langages modernes intègrent de base les mécanismes permettant de réaliser les appels à ces RPC. De plus, avec son mécanisme de balises, on sait que XML est plus structuré (il permet une vue en arborescence des données).
Partie 3 : [Texte 3] nous rappelle que XML-RPC et SOAP sont des mécanismes qui, intrinsèquement, se sont pas sécurisés (pas de chiffrement, ni dauthentification). Ce même texte ajoute quil faut intégrer une couche supplémentaire (SAML) pour sécuriser les échanges. Pire : [Texte 1] nous rappelle même que les mots de passe sont transmis en clair avec XML-RPC. Pour autant, nous savons aussi que Sun-RPC est décrié, à cause des problèmes de sécurité induits à sa mise en place.
Conclusion : Les trois technologies permettent dimplémenter des RPC. Sun-RPC, bien quancien, proposait quelques avantages : accessibilité de la liste des services proposés grâce au portmapper, et protocoles peu bavard, plus efficace. Pour autant, parce que les mécanismes implémentés dans les langages modernes simplifient le travail du programmeur, les RPC basés sur les webservices et échangeant du XML (plus structuré quun flux XDR) sont devenus populaires. Il faut néanmoins garder à lesprit que toutes ces techniques ne doivent être utilisées que pour des applications peu critiques, en raison de leur manque de sécurité.
NSY107 intégration client-serveur Correction de lexamen du 01/07/2006 Page PAGE 6/ NUMPAGES 6
SOAP, XML-RPC & REST: différences et intérêts - 05/11/2004
[
] XML-RPC
Le protocole XML-RPC peut donc être pris comme l'ancêtre de SOAP : il a en tous cas évolué d'une première version de SOAP, et modifié pour correspondre à la vision de Dave Winer. [...]
SOAP
Créé sous les hospices de Microsoft et toujours soutenu par ce dernier, le protocole SOAP se montre bien plus populaire et utilisé que son camarade XML-RPC - principalement grâce au soutient du W3C, mainteneur de la spécification depuis la version 1.2 du protocole, publiée en 2003. De fait, aujourd'hui, SOAP est un standard de facto du monde des services Web [
]
Conclusion
[
] Mais aujourd'hui, tous les langages modernes disposent de fonctionnalités leur permettant d'exploiter des services Web type SOAP ou XML-RPC sans se soucier de la verbosité de leurs messages sortants et entrants. C'est d'ailleurs la raison pour laquelle ces deux techniques ont tant de succès vis-à-vis de REST : les outils sont disponibles, tandis que REST nécessite de mettre en place ses propres méthodes (même si le protocole, lui existe déjà).
De SOAP ou XML-RPC, le choix des développeurs tend à se porter sur la première méthode, du fait de certains défauts dans la spécification de la seconde : manque de précisions, confusions sur certains aspects (support Unicode, notamment), mots de passe transmis en clair
[
]
Xavier Borderie, JDN Développeurs.
Portmap et les RPC (Remote Procedure Call)
05/01/2005, D. David (Coredump)
1. Les RPC
Les RPC [
] permettent lexécution de procédures sur une machine distante. [
] Les procédures (ou fonctions) RPC sont regroupées en programmes et identifiées par des numéros. Les programmes se voient aussi attribuer un numéro ainsi quun numéro de version. Cest par le biais de ce triplet quun client peut appeler une procédure particulière. Les numéros sont attribués dune façon stricte (idem ports TCP et UDP). Ainsi mountd se voit attribuer le numéro 100005.
2. XDR
Conjointement aux RPC et au-dessus (dans le modèle OSI), on utilise le protocole XDR (eXternal Data Representation). XDR gère la mise en forme des données[
]. Il définit un standard de représentation des types sur le réseau, afin notamment de palier la multiplicité des représentations utilisées (big endien, little endien, ...).
3. Portmap
[
] Ces appels sont gérés par un standard (le processus portmap) via les numéros vus plus haut. Ces numéros sont recensés dans le fichier /etc/rpc. Ce fichier contient les services constructeurs, ce nest pas un fichier de configuration, il joue le même rôle que /etc/services dans la correspondance nom dapplication/port associé pour la programmation RPC. [
]
XML, Soap, WSDL et UDDI : les composants des services web - 01 Réseaux, le 01/12/2002
[
]En pratique, sur un réseau, un analyseur de trames IP verra la chose suivante : HTTP, qui encapsule Soap, qui encapsule les flux métiers. Mais XML, et Soap n'ont pas de sécurité intégrée. Il faut donc les compléter. La première étape est SAML (Security assertion markup language) , qui fixe un cadre XML pour l'échange des informations de sécurité.[
]