I. Bus logiciel ? D’après Raphael.Marvie@lifl.fr et Sacha Krakowiak Et (cf. références en bas des pages) 22/11/2018

Mireille Blay-Fornarino Objectifs de ce cours Sensibilisation au besoin d’intégration des applications logicielles réparties en contexte industriel Etudier l’approche Intergiciel Principes directeurs, organisation, usage Fonctionnement interne (“ au coeur de …”) Construction d’un intergiciel simple 22/11/2018 Mireille Blay-Fornarino

Entreprise virtuelle : illustration Thermique Ventilation Calcul ( ) r ¶ cr u t div Kgrad F = + Faster networks Growth of network bandwidth vs growth of memory/storage: cheapest data exchanges Cheap PCs Successful development of cluster computing Some degree of standardization of hardware and software Standardization bodies W3C http://www.w3c.org/ (*ML, HTTP, SOAP, WS...) OASIS http://www.oasis-open.org/ (WS, security...) Global Grid Forum http://www.ggf.org/ (OGSA, WS-RF...) ... Grid marketing Industry adoption I . Les grandes organisations telles que les compagnies de l’automobile, de l’aérospatiale, des télécom .. de la finance ont besoin de larges systèmes à grande échelle pour supporter leurs complexes activités. La majorité de ces applications sont elles aussi distribuées sur de multiples machines fortement réparties géographiquement et très hétérogènes. II. Les utilisateurs coopèrent à la réalisation des différentes activités de leur organisation. III. complexité et diversité des compétences IV. Besoin de composer les éleéments et aussi d ’interopérable V. La plupart des application incluent un composant interface, une logique métier et un systeme de gestion des données. VI Ce activités évoluent fortement dans le temps pour suivre les chgmts de législations, les nouvelles opportunités du marché… les concepteurs doivent dont pouvoir répondre rapidement à ces chgments en créant de nvelles fonctionnalités ou en recombinant celles existantes. Aujourd’hui, un des défis les plus importants de l’info est de maîtriser la conception et le déploiement des applications distribuées pour offrir un large éventail de services évolutifs accessibles aussi bien par le grand public que par des utilisateurs experts. Faire face aux tours de Babel : langage, plateforme, OS, ….. Un service distribué est composé de différents éléments logiciels et matériels mis en œuvre dans sa réalisation : les interfaces d’interactions pour les utilisateurs, les logiciels de services (ou serveurs), les machines, les espaces de stockage, les réseaux, les protocoles de communications entre les machines mais aussi entre les logiciels. Nouvelles Technologies pour l’Information et la Communication Exemples de NTIC : le multimédia, le courrier électronique, les réseaux informatiques, la visioconférence, le collecticiel (groupware), la visualisation 3D, Internet. Assemblage de ressources de Stockage, Calculs, réseaux 22/11/2018 Mireille Blay-Fornarino

Propriétés à prendre en compte Hétérogénéité Hardware Langages Ressources Contexte d’usage Désignation/localisation Migration Mobilité Ubiquité Distribution Equilibrage de charge Parallelisation Decentralisation Prise de décision Contrôle de l’accès concurrent Clients simultanés Serveurs parallèles Données réparties synchronisation de l'accès aux ressources, Gestion des transactions Les problèmes liés à la réalisation d'applications réparties sont nombreux, on peut cependant citer les principaux. Dans la communication entre les différentes entités composant l'application, l'aspect passage d'information entre deux processus est simple (envoi de message par exemple : sockets), les difficultés sont liées d'une par à la désignation et à la localisation de ces entités, d'autre part à leurs différences : • désignation, localisation d'une ressource, d'un serveur, • hétérogénéité : différence de représentation des données donnant lieu à des interprétations différentes du contenu d'un message. La prise de décision, et tous les problèmes proches (synchronisation, contrôle d'accès concurrents), est rendue difficile dans les systèmes répartis du fait que les différents acteurs ont une perception différente de l'état de l'application : en effet chacun perçoit l'état de tous les autres par le biais des messages échangés, il a donc au mieux une vision retardée de celui-ci. L'ensemble de ces problèmes sera abordé ultérieurement, les différents outils et paradigmes permettant de solutionner le problème de la communication sont présentés ci-après, le problème de la prise de décision et ses solutions sont abordés ensuite. Lors de la mise en place d'un déplacement, un client passe par une agence qui effectue diverses actions : en particulier, elle réserve d'une part le transport (avion par exemple) et d'autre part l'hôtel. Lorsque plusieurs clients effectuent des demandes similaires, leurs actions auprès des compagnies aériennes et des chaînes d'hôtel peuvent être perçues différemment. Ces différences peuvent affecter le bon fonctionnement du système. Une application répartie pour répondre aux motivations énoncées doit posséder différentes propriétés, ces propriétés peuvent sembler inhérentes à l'aspect distribué de l'application, il n'en est rien : • Parallélisme : l'application est réalisée par de multiples processus (clients et serveurs) parallèles ; cependant son bon fonctionnement nécessite une synchronisation entre ces processus, une synchronisation trop forte peut conduire à la sérialisation de l'application. • Dimensionnement (scalabilité) : cette propriété est proche de la précédente, elle exprime surtout le surcoût lié à l'ajout d'un client ou d'un serveur : par exemple le coût lié à la synchronisation ou à l'accès des données distantes peut devenir prohibitif à partir d'un certain nombre de processus. • Tolérance aux fautes (fiabilité) : cette propriété exprime la capacité de l'application à s'exécuter dans un environnement dégradé (composants en panne, liens de communication absents, etc.). Il faut être vigilant et éviter d'isoler des fonctions vitales. 22/11/2018 Mireille Blay-Fornarino

Propriétés à prendre en compte Sécurité authentification (certificats) sécurisation des communications (cryptage) contrôle d’accès (autorisation) Dimensionnement croissance du nombre de clients « duplication des serveurs », « gestion de caches » gigantesque quantité de données Tolérance aux fautes site en panne ou inaccessible « redondance des serveurs » « fonctionnement en mode dégradé » Les problèmes liés à la réalisation d'applications réparties sont nombreux, on peut cependant citer les principaux. Dans la communication entre les différentes entités composant l'application, l'aspect passage d'information entre deux processus est simple (envoi de message par exemple : sockets), les difficultés sont liées d'une par à la désignation et à la localisation de ces entités, d'autre part à leurs différences : • désignation, localisation d'une ressource, d'un serveur, • hétérogénéité : différence de représentation des données donnant lieu à des interprétations différentes du contenu d'un message. La prise de décision, et tous les problèmes proches (synchronisation, contrôle d'accès concurrents), est rendue difficile dans les systèmes répartis du fait que les différents acteurs ont une perception différente de l'état de l'application : en effet chacun perçoit l'état de tous les autres par le biais des messages échangés, il a donc au mieux une vision retardée de celui-ci. L'ensemble de ces problèmes sera abordé ultérieurement, les différents outils et paradigmes permettant de solutionner le problème de la communication sont présentés ci-après, le problème de la prise de décision et ses solutions sont abordés ensuite. Une application répartie pour répondre aux motivations énoncées doit posséder différentes propriétés, ces propriétés peuvent sembler inhérentes à l'aspect distribué de l'application, il n'en est rien : • Parallélisme : l'application est réalisée par de multiples processus (clients et serveurs) parallèles ; cependant son bon fonctionnement nécessite une synchronisation entre ces processus, une synchronisation trop forte peut conduire à la sérialisation de l'application. • Dimensionnement (scalabilité) : cette propriété est proche de la précédente, elle exprime surtout le surcoût lié à l'ajout d'un client ou d'un serveur : par exemple le coût lié à la synchronisation ou à l'accès des données distantes peut devenir prohibitif à partir d'un certain nombre de processus. • Tolérance aux fautes (fiabilité) : cette propriété exprime la capacité de l'application à s'exécuter dans un environnement dégradé (composants en panne, liens de communication absents, etc.). Il faut être vigilant et éviter d'isoler des fonctions vitales. ! Sauvegarde/restauration • Centralisé: • Sauvegarde régulière de l'état du système • Restauration du dernier état en cas de défaillance • Réparti: • Sauvegarde des états des différents sites • Restauration d'un ensemble d'état cohérents 22/11/2018 Mireille Blay-Fornarino

Objectifs de ce cours Introduire les principes de base de l’architecture des intergiciels … … via une démarche systématique basée sur le besoin. 22/11/2018

Méthodologie suivie pour ce cours Découvrir la structuration d’un bus logiciel réparti, en concevant un petit bus simple « from scratch ». Construire un bus logiciel en 10 étapes : Chaque étape est un raffinement de la précédente Etape i + 1 = meilleure structuration de l’étape i A chaque étape, s’il y a lieu, Identification des principaux schémas d’architecture 22/11/2018 Raphael.Marvie@lifl.fr

Les Services Service 1 : Hello world Service 2 : Nombres premiers Une méthode hello avec un paramètre de type chaîne et retourne une chaîne : ”hello, ” + paramètre Deux méthodes lower et upper qui retournent le paramètre de type chaîne en minuscule ou majuscules Service 2 : Nombres premiers Calcule si un nombre est premier et retourne un booléen Calcule le carré d’un nombre passé en paramètre Calcule la division de deux nombres passés en paramètre 22/11/2018

1. Au début était la socket 22/11/2018

Principe Deux programmes écrits en deux classes Java Une pour le serveur Server.java Une pour le client Client.java Dans chaque classe est implémenté Le code fonctionnel : manipulation des chaînes Le code technique : construction / analyse des messages réseau 22/11/2018

Architecture version « socket » Client Serveur Réseau 22/11/2018

Modélisation des Interactions 22/11/2018

Côté serveur Initialisation du réseau Gestion des requêtes Instanciation d’une socket serveur Gestion des requêtes Attente de connexion (accept) Initialisation des flux d’entrée et de sortie Evaluation des requêtes Lecture de la requête sur le flux d’entrée Création de la chaîne à retourner Ecriture de la réponse sur le flux de sortie 22/11/2018

Code serveur (i) package step1 ; import java.io.* ; import java.net.* ; public class Server { private ServerSocket asock ; public Server () throws Exception { this.asock = new ServerSocket (12345) ; } public static void main (String args[]) { Server s = new Server () ; s.run () ; 22/11/2018

Code serveur (ii) public void run () throws Exception { while (true) { Socket sock = this.asock.accept () ; BufferedReader in = new BufferedReader (new InputStreamReader(sock.getInputStream ())); DataOutputStream out = new DataOutputStream (sock.getOutputStream ()); String msg = in.readLine () ; String res = "Hello, " + msg + "\n" ; // fonctionnel out.writeBytes (res) ; } 22/11/2018

Côté client Initialisation du réseau Gestion de l’échange réseau Instanciation d’une socket de communication (connexion implicite) Gestion de l’échange réseau Initialisation des flux d’entrée et de sortie Demande de service Ecriture de la requête sur le flux de sortie Lecture de la réponse sur le flux entrée Affichage de la chaîne retournée Fermeture de la connexion 22/11/2018

Code client (i) package step1 ; import java.io.* ; import java.net.* ; public class Client { private Socket sock ; public Client () throws Exception { this.sock = new Socket ("localhost", 12345) ; } public static void main (String args[]) throws Exception { Client c = new Client () ; c.run (args[0]) ; 22/11/2018

Code client (ii) public void run (String msg) throws Exception { BufferedReader in = new BufferedReader (new InputStreamReader(this.sock.getInputStream ())); DataOutputStream out = new DataOutputStream (this.sock.getOutputStream ()); out.writeBytes (msg + "\n") ; String res = in.readLine () ; System.out.println ("Server replied: " + res) ; this.sock.close(); } 22/11/2018

Bénéfices et limitations Invocation d’un service distant (hello world) Permet de réaliser des applications client/serveur Limitations Une seule connexion cliente à la fois Beaucoup de code très technique / peu de code métier (40 lignes de code technique pour une ligne de code métier) Un beau plat de spaghettis, difficilement évolutif 22/11/2018

2. Gestionnaire de connexions 22/11/2018

Principe Du côté serveur Du côté client Etablissement de la connexion par le serveur (accept) La gestion de la connexion est déléguée à un objet Manager qui gère une connexion Du côté client Rien ne change pour le moment Réutilisation du client de l’étape 1 22/11/2018

Architecture version 2 Client Manager Réseau 22/11/2018

Interactions version 2 22/11/2018

Côté serveur (Serveur) Initialisation De la socket d’administration / serveur Création d’un manager de connexions Gestion des requêtes Attente de connexion Délégation au manager 22/11/2018

Côté serveur (Manager) Initialisation Rien de spécial Gestion des requêtes Initialisation du flux d’entrée et de sortie Evaluation de la requête Lecture de la requête sur le flux entrée Création de la chaîne à retourner Ecriture de la réponse sur le flux de sortie 22/11/2018

Code Serveur (i) package step2 ; import java.io.*; import java.net.*; public class Server { private ServerSocket asock ; private Manager mgr ; public Server () throws Exception { this.asock = new ServerSocket (12345) ; this.mgr = new Manager () ; } 22/11/2018

Code Serveur (ii) public void run () throws Exception { while (true) { Socket sock = this.asock.accept () ; this.mgr.process (sock) ; } public static void main(String argv[]) throws Exception { Server s = new Server () ; s.run () ; 22/11/2018

Code Manager package step2 ; import java.io.* ; import java.net.* ; public class Manager { public Manager () throws Exception {} public void process (Socket sock) throws Exception { BufferedReader in = ... DataOutputStream out = ... String msg = in.readLine () ; String res = "Hello, " + msg + "\n" ; out.writeBytes (res) ; } 22/11/2018

Bénéfices et limitations Ebauche de structuration Distinction entre établir une connexion et la gérer Limitations Le manager ne sait répondre qu’à une invocation Le code n’est pas encore objet (i.e. le service) 22/11/2018

3. Décodage des requêtes 22/11/2018

Principe Côté serveur Côté client Le manager propose plusieurs services Le manager gère plusieurs requêtes par connexion Côté client Utilise les services séquentiellement Réalise plusieurs invocations avec la même connexion 22/11/2018

Architecture version 3 Client Manager Réseau 22/11/2018

Interactions version 3 22/11/2018

Côté serveur Gestion des requêtes par le Manager Initialisation des flux d’entrée et de sortie Evaluation de la requête Lecture de la requête sur flux d’entrée Décodage de la requête (quel service ?) requête = numéro de service + arguments Evaluation du service demandé Ecriture de la réponse sur flux de sortie 22/11/2018

Code Manager (i) public void process (Socket sock) throws Exception { BufferedReader in = ... DataOutputStream out = ... while (true) { String msg = in.readLine () ; if (msg == null) // end of client connexion break ; String res ; switch (msg.charAt (0)) { 22/11/2018

Code Manager (ii) case ’0’: res = "hello, " + msg.substring (1) + "\n" ; break ; case ’1’: Res = msg.substring (1) .toLowerCase () + "\n" ; case ’2’: res = msg.substring (1) .toUpperCase () + "\n" ; default: res = "Unknow operation requested" ; } out.writeBytes (res) ; } } 22/11/2018

Côté client Initialisation du réseau Gestion des échanges réseaux Instanciation de la socket de communication Gestion des échanges réseaux Initialisation des flux d’entrée et de sortie Demande de service (x3) Requête réseau = numéro de service + arguments Ecriture requête, lecture réponse et affichage Fermeture de la connexion 22/11/2018

Code Client (i) public void run (String msg) throws Exception { BufferedReader in = ... DataOutputStream out = ... String res ; out.writeBytes ("0" + msg + "\n") ; res = in.readLine () ; System.out.println ("Server replied (hello): " + res) ; 22/11/2018

Code Client (ii) out.writeBytes ("1" + msg + "\n") ; res = in.readLine () ; System.out.println ("Server replied (lower): " + res) ; out.writeBytes ("2" + msg + "\n") ; System.out.println ("Server replied (upper): " + res) ; this.sock.close(); } 22/11/2018

Bénéfices et limitations Un seul serveur propose plusieurs services Utilisation d’une seule connexion par client Limitations Le code du service n’est toujours pas objet Le code client est toujours un plat de spaghetti 22/11/2018

4. Passage à un service objet 22/11/2018

Principe Côté serveur Côté client Le service est implémenté comme un objet : le Servant Le manager est dédié au réseau décode les requêtes invoque le Servant Côté client Rien ne change 22/11/2018

Architecture version 4 Servant Client Manager Réseau 22/11/2018

Interactions version 4 22/11/2018

Côté serveur Initialisation du Manager dans le serveur Passage du Servant comme paramètre Gestion des requêtes par le Manager Initialisation des flux Evaluation des requêtes lecture et décodage de la requête invocation du Servant écriture de la réponse 22/11/2018

Code Server public class Server { private ServerSocket asock ; private Manager mgr ; public Server () throws Exception { this.asock = new ServerSocket (12345) ; this.mgr = new Manager (new Servant ()) ; } // unchanged 22/11/2018

Code Servant public class Servant { public String hello (String msg) { return "hello, " + msg ; } public String lower (String msg) { return msg.toLowerCase () ; public String upper (String msg) { return msg.toUpperCase () ; 22/11/2018

Code Manager (i) public class Manager { private Servant ref ; public Manager (Servant s) throws Exception { this.ref = s ; } public void process (Socket sock) throws Exception { BufferedReader in = ... DataOutputStream out = ... while (true) { String msg = in.readLine () ; if (msg == null) // no more to be read break ; String res ; switch (msg.charAt (0)) { 22/11/2018

Code Manager (i) case ’0’: res = this.ref.hello (msg.substring (1)) + "\n" ; break ; case ’1’: res = this.ref.lower (msg.substring (1)) + "\n" ; case ’2’: res = this.ref.upper (msg.substring (1)) + "\n" ; default: res = "Unknow operation requested" ; } out.writeBytes (res) ; 22/11/2018

Bénéfices et limitations Découplage complet entre code technique et code métier (côté serveur) Les services sont implantés comme des objets (Servant) Limitations L’interface du service n’est pas connue comme telle du client Le code client n’est toujours pas objet 22/11/2018

5. Passage à l’objet du côté client 22/11/2018

Principe Côté serveur Côté client Définition d’un contrat à partager avec le client Le servant implémente le contrat commun Côté client Utilisation d’un objet représentant le service : Proxy Même interface que le service Encapsule le code technique de gestion du réseau 22/11/2018

Architecture version 5 Client Servant Contrat Proxy Manager Réseau 22/11/2018

Interactions version 5 22/11/2018

Côté serveur Modifications Contrat de service Définition d’un contrat de service Le servant implémente le contrat de service Contrat de service Définit toutes les méthodes accessibles à distance Chaque méthode peut lever une exception liée au réseau 22/11/2018

Contrat de service package step5 ; interface Service { public String hello (String msg) throws Exception ; public String lower (String msg) throws Exception ; public String upper (String msg) throws Exception ; } 22/11/2018

Modification du Servant public class Servant implements Service { public String hello (String msg) throws Exception { return "hello, " + msg ; } public String lower (String msg) throws Exception { return msg.toLowerCase () ; public String upper (String msg) throws Exception { return msg.toUpperCase () ; 22/11/2018

Côté client Programme client Mise en oeuvre du Proxy Instancie un proxy Invocation des méthodes du proxy Mise en oeuvre du Proxy Implémente l’interface de contrat Initialise la connexion au serveur Gère toute la partie échanges réseaux 22/11/2018

Code du Client public class Client { private Socket sock ; private Service ref ; public Client () throws Exception { this.ref = (Service) new Proxy () ; } public void run (String msg) throws Exception { System.out.println (this.ref.hello (msg)) ; System.out.println (this.ref.lower (msg)) ; System.out.println (this.ref.upper (msg)) ; 22/11/2018

Code du Proxy (i) public class Proxy implements Service { private Socket sock ; private BufferedReader in ; private DataOutputStream out ; public Proxy () throws Exception { this.sock = new Socket ("localhost", 12345) ; this.in = ... this.out = ... } public String hello (String msg) throws Exception { this.out.writeBytes ("0" + msg + "\n") ; String res = this.in.readLine () ; return res ; 22/11/2018

Code du Proxy (ii) public String lower (String msg) throws Exception { this.out.writeBytes ("1" + msg + "\n") ; String res = this.in.readLine () ; return res ; } public String upper (String msg) throws Exception { this.out.writeBytes ("2" + msg + "\n") ; protected void finalize () throws Throwable { this.sock.close () ; 22/11/2018

Proxy : Bilan Contexte Problème Solutions Applications constituées d’un ensemble d’objets répartis ; un client accède à des services fournis par un objet pouvant être distant (le “servant”) Problème Définir un mécanisme d’accès qui évite au client Le codage “en dur” de l’emplacement du servant dans son code Une connaissance détaillée des protocoles de communication Propriétés souhaitables Accès efficace et sûr Programmation simple pour le client ; idéalement, pas de différence entre accès local et distant Contraintes Environnement réparti (pas d’espace unique d’adressage) Solutions Utiliser un représentant local du servant sur le site client (isole le client du servant et du système de communication) Garder la même interface pour le représentant et le servant Définir une structure uniforme de représentant pour faciliter sa génération automatique 22/11/2018 C 2003 - Sacha Krakowiak

Usage de Proxy 22/11/2018 C 2003 - Sacha Krakowiak

Définitions d’interfaces Partie “opérationnelle” Interface Definition Language (IDL) Pas de standard indépendant IDL CORBA Java et C# définissent leur propre IDL WSDL … Partie “contractuelle” Plusieurs niveaux de contrats Sur la forme : spécification de types -> conformité syntaxique Sur le comportement (1 méthode) : assertions -> conformité sémantique Sur les interactions entre méthodes : synchronisation Sur les aspects non fonctionnels (performances, etc.) : contrats de QoS 22/11/2018 C 2003 - Sacha Krakowiak

Bénéfices et limitations Du point de vue du client la répartition est masquée Le service est vu et manipulé comme un objet local Limitations Comment utiliser des paramètres autres que de type String ? Comment désigner un service distant (sans le coder en dur) ? 22/11/2018

6. Encodage et décodage des données 22/11/2018

Principe Traduction des paramètres Empaquetage : application vers les messages réseau type de base vers représentation chaîne Dépaquetage : messages réseau vers application représentation chaîne vers type de base Opérations de traduction symétriques Serveur : dépaquetage des paramètres, empaquetages des valeurs de retour Client : empaquetage des paramètres, dépaquetages des valeurs de retour 22/11/2018

Architecture version 6 Client Servant Contrat Proxy Manager Réseau 22/11/2018

Interactions version 6 22/11/2018

Côté serveur Modification du contrat de service Offre une opération supplémentaire Calcul du carré d’un entier (retourne un entier) Modification de la mise en oeuvre Manager : message réseau supplémentaire et décodage entier Servant : implémentation de la nouvelle méthode 22/11/2018

Contrat Service interface Service { } public String hello (String msg) throws Exception ; public String lower (String msg) throws Exception ; public String upper (String msg) throws Exception ; public int sqr (int a) throws Exception ; } 22/11/2018

Code Manager public void process (Socket sock) throws Exception { // unchanged switch (msg.charAt (0)) { // unchanged for 0-2 case ’3’: int val = Integer.parseInt (msg.substring (1)) ; res = "" + this.ref.sqr (val) + "\n" ; break ; default: res = "Unknow operation requested" ; } out.writeBytes (res) ; 22/11/2018

Code Servant public class Servant implements Service { // unchanged public int sqr (int val) throws Exception { return val * val ; } 22/11/2018

Côté client Modification de la mise en oeuvre Mise en oeuvre du Proxy Le proxy implémente la nouvelle opération Le programme client utilise la nouvelle opération Mise en oeuvre du Proxy Empaquetage de l’entier paramètre dans une chaîne Dépaquetage de l’entier contenu dans la chaîne retour 22/11/2018

Code Proxy public class Proxy implements Service { // unchanged public int sqr (int val) throws Exception { this.out.writeBytes ("3" + val + "\n") ; String res = this.in.readLine () ; return Integer.parseInt (res) ; } 22/11/2018

Code Client public class Client { // unchanged public void run (String msg) throws Exception { System.out.println (this.ref.hello (msg)) ; System.out.println (this.ref.lower (msg)) ; System.out.println (this.ref.upper (msg)) ; int res = this.ref.sqr (123) ; System.out.println (res) ; } 22/11/2018

Bénéfices et limitations Utilisation transparente des types de base autres que String Vision objet d’une application répartie Limitations Comment désigner un service distant sans le coder en dur ? (this.sock = new Socket ("localhost", 12345)) Comment écrire un client pouvant utiliser plusieurs services ? 22/11/2018

7. Notion de référence distante 22/11/2018

Principe Désignation d’un service distant Equivalent à une référence Java mais en réparti Permet d’établir une connexion avec un service Définition d’une référence (base) Hôte distant : adresse IP Serveur distant : port IP 22/11/2018

Architecture version 7 Client Servant Contrat Proxy Manager Réseau 22/11/2018

Interactions version 7 22/11/2018

Côté client Fourniture de la référence du serveur Propriété java contenant la référence Référence donnée sous la forme machine:port Ajout d’une méthode de gestion des références Analyse la référence Instancie et initialise le Proxy d’accès au service # utilisation avec une référence > java –D «service.reference=localhost:12345» step7.Client «Tout le Monde » 22/11/2018

Code Client public class Client { private Service ref ; public Client () throws Exception { this.ref = (Service) this.ref2proxy () ; } // other methods unchanged 22/11/2018

Code Client public Proxy ref2proxy () throws Exception { Properties props = System.getProperties () ; String ref = props.getProperty ("service.reference") ; if (ref == null) throw new Exception ("no server reference given") ; String parts[] = ref.split (":") ; if (parts.length < 2) throw new Exception ("malformed reference") ; String host = parts [0] ; int port = Integer.parseInt (parts [1]) ; return new Proxy (host, port) ; } 22/11/2018

Bénéfices et limitations Le code client n’est pas lié à une instance de serveur Possibilité d’utiliser différents serveurs Limitations Un seul objet service par serveur Un client ne peut utiliser qu’un objet à la fois Le client doit connaître le type de la référence à la compilation 22/11/2018