client/serveur. partie 1 : présentation du modèle client-serveur client/serveur

CLIENT/SERVEUR

Partie 1 : Prsentation du modle client-serveur CLIENT/SERVEUR

Un peu d'histoire. Le client serveur est l'tat actuel de l'volution des architectures informatiques : Avant les Annes 80 : Systme Centralis (ordinateur central avec des terminaux passifs de type texte). Les Annes 80 : Dveloppement du transactionnel et apparition des SGBD non- propritaires (indpendants des constructeurs) - SGBD relationnel + SQL

Un peu d'histoire. Les Annes 80 : Paralllement dveloppement des micros-ordinateurs avec leur puissance de calcul dcentralise et leurs interfaces graphiques conviviales. Le maintien des gros et moyens systmes avec les micros-ordinateurs ont rendu les communications difficiles et ont cr des dsordres dans les systmes d'informations (redondance,etc.)

Un peu d'histoire. Les Annes 90 : Dveloppement des rseaux. L'efficacit et le partage des systmes d'informations doivent tre optimum (concurrence conomique, etc.). Le client-serveur se situe dans ce besoin de centralisation (information cohrente, non redondante et accessible) et de dcentralisation (conserver la puissance et l'interface des micros-ordinateurs)

Le modle Multi-Utilisateur centralis Serveur = Ordinateur central qui effectue tous les traitements Client = Terminal sans puissance locale de traitement CLIENT ECRANECRAN SERVEUR INTELLIGENCE

Le modle rseau local traditionnel Serveur = Gre le rseau et stocke les bases de donnes sans les gres. Client = Les stations effectuent tous les traitements CLIENT ECRANECRAN SERVEUR INTELLIGENCE

Le modle Client-Serveur Rpartition judicieuse de la puissance de traitement entre le serveur et les diffrentes stations interconnectes. ECRANECRAN SERVEUR CLIENT INTELLIGENCE

Pourquoi le Client-Serveur ? Contraintes sur l'entreprise Contraintes externes : comptitivit, exigence de la clientle, produire mieux et plus vite, etc. Contraintes internes : Compression des budgets (limitation des ressources), manque de temps, absorption des technologies nouvelles Mieux matriser le systme d'information Une architecture ouverte C/S btie autour d'un moteur relationnel amliore cette matrise : prsentation naturelle des donnes, meilleure productivit des dveloppeurs avec le SQL

Pourquoi le Client-Serveur ? Prise en compte des volutions technologiques Aspect ouvert et modulaire du Client-serveur. Mais. Rduire les cots ? L'architecture C/S cote plus cher qu'une architecture centralise : Postes de travail Rseau local Formation des dveloppeurs (SGBD, Middleware, l'objet et les interfaces graphiques) Techniciens de maintenance rseau et PC

Client/Serveur : dfinition Est conforme au modle client- serveur tout processus utilisant des services offerts par un autre processus, et communiquant avec lui laide de messages.

Client/Serveur : dfinition Approche Puriste SERVEUR CLIENT REQUTE REPONSE Approche Pragmatique ECRANECRAN SERVEUR CLIENT REQUTE REPONSE

Client/Serveur : dfinition La prsence d'un rseau n'est pas obligatoire dans la dfinition. On peut nanmoins considrer qu'une architecture C/S ne se construit qu'autour d'un rseau. Le terme SERVEUR fait rfrence tout processus qui reoit une demande de service (requte) venant d'un client via un rseau, traite cette demande et renvoie le rsultat (rponse) au demandeur (le CLIENT).

CLIENT Processus qui demande l'excution d'une opration par l'envoi d'une demande. SERVEUR Processus qui excute la demande du client et qui transmet la rponse. REQUTE (Request) Message transmis par le client. REPONSE (Reply) Message transmis par le serveur. Client-Serveur : dfinition

Les 4 principes de base du C/S Principe 1 : Rendre l'architecture matrielle transparente vis vis des dveloppeurs et des utilisateurs finals. Principe 2 : Rendre le niveau physique (et logique dans une moindre mesure) des bases de donnes transparent pour les dveloppeurs et les utilisateurs.

Les 4 principes de base du C/S Principe 3 : Utiliser au niveau de chaque station (cliente ou serveur) l'ensemble matriel/logiciel le plus adapt. Chaque machine est adapte des besoins prcis (implique l'htrognit des matriels). Optimisation de l'outil. Diversit des services offerts l'utilisateur. Minimisation des cots (le sophistiqu l o il es ncessaire.

Les 4 principes de base du C/S Principe 4 : Permettre une sparation physique entre les actions d'un programme lies l'interaction avec les utilisateurs et les autres actions. Gestion du dialogue par le client (interface) Gestion des donnes par le serveur Il s'agit d'un modle de traitement coopratif.

Dcoupage des applications client-serveur On reconnat traditionnellement dans une application 3 modules : DONNEES TRAITEMENT PRESENTATION

La rpartition de ces 3 modules variera entre le client et le serveur et sera fonction : Des types darchitecture retenus De la capacit des machines De la capacit du rseau Le Gartner Group a propos les cas de figure suivants : Dcoupage des applications client-serveur

Le schma du Gartner Group

Client/Serveur de prsentation Type 1 : Reprsente un systme Serveur/terminal classique. Ce dernier prsente un cran "calcul" par le serveur. Le type 1 n'est pas un systme client/serveur. Type 2 : L'affichage effectu par le client se fait la suite d'un change de requtes avec le serveur (type de fentre sa taille, son titre, etc.) X-Windows est le systme reprsentatif du type 2 Le schma du Gartner Group

Client/Serveur de Traitements (Type 3) Les donnes restent centralises mais les traitements sont rpartis entre le client et le serveur (cf. Le dialogue RPC). Les applications Web rentrent dans cette catgorie avec : du ct client les scripts intgrs dans les pages HTML, les plug-in et/ou les composants. du ct serveur les divers programmes (accs aux bases de donnes,) qui transmettent leurs rsultats aux clients Le schma du Gartner Group

Client/Serveur de donnes Systme popularis par les SGBDR associs au SQL. Dans ce contexte le serveur gre les donnes, leur intgrit, la scurit, etc. Il envoie seulement les donnes correspondant la requte (opposition avec le serveur de fichiers). Le client traite ces donnes pour ventuellement, en retour, mettre jour la base. Un partie de la base de donnes pour tre sur le client -type 5- (cf. rpartition des bases de donnes) Le schma du Gartner Group

Conclusion (partie 1) Modle client/serveur se caractrise donc par : Des ressources indpendantes, L'importance du dialogue entre le client et le serveur, La place centrale du rseau.

Ressources indpendantes Hbergement Toute plate-forme matrielle peut devenir serveur Tout systme dexploitation peut hberger un service Toutes configurations matrielles ou logicielles envisageables Localisation Les ressources peuvent tre nimporte o sur le rseau Architecture plus modulaire Administration plus complexe

Ressources indpendantes Utilisation Les ressources ne sont pas ddies une utilisation particulire Partage des ressources facilit

Importance du Dialogue Importance accrue des communications Le rseau devient le centre de gravit du SI Le rseau devient la cl de vote du modle client-serveur Complexification du dialogue Dialogue entre systmes htrognes Dialogue distance Ncessit de couches intermdiaires Pour grer la complexit Pour rendre transparent le dialogue

Les protocoles L'importance du rseau les placent au premier plan : Dfinissent le fonctionnement des rseaux Couvrent 3 types de services les services dapplication les services de transport les services de liaison Respectent le modle OSI (interconnexion des systmes ouverts) dfini par lISO

Partie 2 : Le MIDDLEWARE CLIENT/SERVEUR

Dfinition Georges GARDARIN dfinit le middleware comme : "L'ensemble des services logiciels construits au- dessus d'un protocole de transport afin de permettre l'change de requtes et des rponses associes entre client et serveur de manire transparente." D'autres auteurs intgrent les couches rseaux dans le middleware.

Une triple transparence : Transparence aux rseaux. Tous les types de rseaux doivent tre supports. Transparence aux serveurs. Tous le SGBD (avec leur SQL souvent diffrents) doivent tre accessibles. Transparence aux langages. Les fonctions appeles doivent tre aussi indpendantes que possible des langages. Dfinition Application(s)Serveur(s) MIDDLEWARE RESEAU

Pourquoi le Middleware ? La complexit du dialogue client/serveur est l'origine du middleware. Complexit due la prsence : Des Systmes htrognes Des Systmes propritaires Du dialogue distance

Le Middleware : quoi a sert ? Avantages Offre des services de haut niveau aux applications Rend portable les applications (avec certaines limites) Prend en charge les protocoles de conversion de caractres et dtablissement de sessions entre clients et serveurs htrognes Cest la glue qui rend possible le client- serveur Cest la bote outils pour le dveloppement des applications.

L'architecture type du Middleware L'IPC (Inter Processus Communication) est l'autre nom du middleware. L'IPC se compose : L'interface API (Application Programming Interface) - Interface de programmation au niveau applicatif. Interface entre un programme et le systme qui propose un ensemble de fonctions standards pour accder un service local ou distant.

L'interface FAP (Format And Protocols) - Protocoles de communication et format des donnes. Ce module assure : la synchronisation entre client et serveur, la reconnaissance du format des donnes changes l'appel aux fonctions de transport du rseau. L'architecture type du Middleware

Client serveur et modle OSI Couche 6 - Prsentation Couche 7 - Application Couche 5 - Session Couche 4 - Transport Couche 3 - Rseau Couche 2 - Liaison Couche 1 - Physique Par Ex : TCP Par Ex : IP Par Ex : Paire torsade Par Ex : CSMA/CD API FAP

couches Client serveur et modle OSI

Le dialogue avec session Application ServeurRseauClient Demande de connexion Requte Rsultats Synchronisation Requte Rsultats Synchronisation Dconnexion Prise en compte de demande et cration d'un contexte Fin du contexte Excution des requtes et gestion de la synchronisation

Le dialogue avec session Dans les dialogues avec session (ou avec connexion). Les changes dinformations sont subordonns louverture dune session par le client vers le serveur. IPC avec connexion : Protocole APPC de larchitecture rseau SNA dIBM (Application Programm to Progamm Application) Protocole RDA, bas sur SQL dfini par lISO (Remote Data Access)

Si le serveur accepte la connexion, il cre un contexte propre chaque application cliente connecte. Client et serveur s'changent des requtes, des rponses et des points de synchronisation. Le client a la responsabilit de conduire les phases successives de l'change Le serveur a la responsabilit de garantir le contexte peru par le client. Le dialogue avec session

Les ordres SQL "COMMIT" ou "ROLL BACK" sont des exemples de points de synchronisation. A la suite d'une requte le : COMMIT confirmera la transaction, ROLL BACK l'annulera. Le serveur mettra rellement jour la base de donnes qu' la suite de ces ordres de synchronisation (avant cela les transactions s'appliquent dans le "contexte") Le dialogue avec session

Le dialogue sans connexion : les RPC Application ServeurRseauClient Appel de la procdure distante Requte Prise en compte de la demande Excution de la procdure Rponse Rception du rsultat poursuite de l'excution

Les dialogues sans connexion avec appels de procdures distantes (RPC - Remote Procedure Call). Le processus client invoque une procdure distante situe sur le serveur. La requte contient tous les lments ncessaires au serveur (nom de la procdure, paramtres, identit du processus). Le message en retour contient toute la rponse. Le dialogue sans connexion : les RPC

Loffre Middleware Les offres Middleware sont varies : Offres propritaires, Offres d'accs universel aux bases, Offres pour des accs multibases Les offres propritaires aux SGBDR : ORACLE avec Sql*Net SYBASE avec Db-lib

Les offres multi-clients, multi-serveurs. Elles permettent aux clients d'accder en toute transparence plusieurs bases htrognes, situes ventuellement sur des serveurs diffrents. SEQUELINK : Techgnosis propose une API sur presque toutes les architectures clientes ou serveurs EDA/SQL : Information Builders propose daccder tout type de bases de donnes partir de plates-formes htrognes Loffre Middleware

DRDA (Distributed Relational Database Architecture) d'IBM pour fdrer les bases IBM (DB2) et non IBM. IDAPI (Integrated Database Application Programming Interface) de Borland en collaboration avec Novell et IBM. Note : videmment l'accs multibases permet galement l'accs monobase. Loffre Middleware

Laccs universel aux donnes pour les clients ODBC de Microsoft : accs standardis aux principales bases de donnes du march (drivers) IDAPI de Borland et Novell Loffre Middleware

ODBC (Open DataBase Connectectivity) est prsent en 1992 par Microsoft comme une interface universelle aux bases de donnes. Il ne s'agit pas d'un middleware proprement parl mais d'une API que l'on utilise en lieu et place des API des diteurs de SGBDR Le Standard ODBC

Exemple : De Sybase ODBC Le Standard ODBC Application API : db-lib (li au SE - db-lib pour OS2, pour Windows, etc) FAP : net-lib (li au SE et au rseau) Rseau Application FAP : net-lib (li au SE et au rseau) Rseau API : ODBC DataBase Driver

Le Standard ODBC

Partie 3 : La Rpartition des Bases de donnes CLIENT/SERVEUR

Dfinitions Base de donnes rpartie Ensemble de bases de donnes gres par des sites diffrents et apparaissant l'utilisateur comme une base unique. SGBD Rparti (ambigut de SGBDR) Systme qui gre des collections de BD logiquement relies, distribues sur un rseau, en fournissant un mcanisme d'accs qui rend la rpartition transparente aux utilisateurs

Dfinitions On parlera ainsi de : Client de SGBD Rpartie Application qui accde aux informations distribues par les interfaces du SGBD Rparti. Serveur de SGBD Rpartie SGBD grant une base de donnes locale intgre dans une base de donnes rpartie D'une faon gnrale on parlera de SITE (client ou serveur) Dfinitions de G. GARDARIN

Pourquoi rpartir les donnes ? La performance daccs aux bases est limite Par le nombre daccs disques ncessaires Par le volume de donnes transmis (dbit du rseau) Par le nombre daccs concurrents Les performances peuvent se dgrader rapidement Au-del de 30 postes clients Pour des consultations trs frquentes ou trs importantes Dans le cadre daccs distance (rseau tendu)

Conception des BdD Rparties Il existe deux types de conception : Conception descendante Conception d'un schma global Distribution des objets de ce schma sur les diffrents sites pour obtenir des schma locaux Base de donnes Globale Base de donnes locale 1 Base de donnes locale 2 Base de donnes locale 3

Conception ascendante Dans ce cas une base de donnes globale fdre des base de donnes locales afin de crer un ou plusieurs schmas globaux. (Le plus souvent il y refonte des schmas locaux) Conception des BdD Rparties Base de donnes Globale Base de donnes locale 1 Base de donnes locale 2 Base de donnes locale 3

Les deux cas reviennent partager, fragmenter la base de donnes globale entre plusieurs sites. Fragment Un fragment est une sous-table obtenue par slection de lignes et de colonnes partir d'une table globale, localise sur un site unique. (peut correspondre galement la table entire) Conception des BdD Rparties

2 Types de fragmentation : Fragmentation Horizontale Dcoupage d'une table en slectionnant des lignes (Il s'agit d'une slection SQL ). Exemple : Table VENDEUR fragmente selon les rgions d'affectation des reprsentants Conception des BdD Rparties Lignes de la rgion 1 Autres rgions

Fragmentation Verticale Dcoupage d'une table en slectionnant des colonnes (Il s'agit d'une projection SQL ). Exemple : Table PRODUIT fragmente selon les fonctions commerciale et production ( Pour la production projection sur : Ref, Desig et cout (Pour le commercial projection sur : Ref, Desig, Prix et Conditionnement ) Conception des BdD Rparties CommercialProduction

Fragmentation Mixte Rsultat d'un fragmentation horizontale et verticale. La recomposition de la table originale doit toujours tre possible par : L'union des fragments horizontaux, La jointure des fragments verticaux. Conception des BdD Rparties

Allocation des fragments (*) Les fragments peuvent tre : Dupliqus sur les sites Les fragments apparaissent plusieurs fois. Placs (rpartis) sur les sites Les fragments n'apparaissent que sur un seul site. (*) Rappel : Le fragment peut correspondre une table. Conception des BdD Rparties

La Gestion des Transactions Proprits des transactions ATOMICITE : Une transaction doit effectuer toutes ses mises jour ou ne rien faire. COHERENCE : La transaction doit faire passer la base de donnes d'un tat cohrent un autre. ISOLATION : Les rsultats d'une transaction ne doivent tre visibles aux autres transactions qu'une fois la transaction valide. DURABILITE : Ds qu'une transaction valide ses modifications, le systme doit garantir que ces modifications seront conserves en cas de panne.

La Gestion des Transactions Validation en deux phases Cette validation est base sur un principe centralis. L'excution de la transaction est contrle par un site coordinateur, rle jou par le client. Les autres sites intresss par la transaction sont des participants, rle jou par les sites serveurs.

La Gestion des Transactions Validation en deux phases Le client coordinateur demande aux autres sites (serveurs) s'ils sont prts mettre jour leur base (ordre PREPARE). Si tous les participants rpondent positivement (ordre OK) alors le site coordinateur envoie l'ordre COMMIT. Les serveurs envoient un acquittement au coordinateur (ordre ACK). Si l'un des participant rpond ngativement (ordre KO) alors le site coordinateur envoie l'ordre d'annulation (ordre ABORT).

La Gestion des Transactions Client CoordinateurServeur 1Serveur 2 PREPARE OK COMMIT ACK Validation en deux tapes avec succs

La Gestion des Transactions Validation en deux tapes avec panne totale d'un participant Client CoordinateurServeur 1Serveur 2 PREPARE OKKO ABORT ACK

Commentaires : Une non-rponse est assimile un refus (time out). Le serveur 2 annule la transaction car il ne l'a pas accept (PREPARE mais pas de OK). La Gestion des Transactions

Validation en deux tapes avec panne partielle d'un participant Client CoordinateurServeur 1Serveur 2 PREPARE OK COMMIT ACK STATUS COMMIT

Commentaires : Le serveur 2 a accept la transaction (OK) puis tombe en panne. COMMIT n'est pas reu. A la reprise, le serveur qui a effectu la sauvegarde sur disque analyse son journal et demande l'tat de la transaction qui entre temps a pu tre annule (ordre STATUS). Dans cet exemple la reprise est faite avec un ordre COMMIT. La Gestion des Transactions

Validation en deux phases distribu Dans le cadre d'un rseau local, le message OK est en fait reu par toutes les stations. Chacune peut donc compter le nombre de OK et valider la transaction La Gestion des Transactions PREPARE OK

Les Base de donnes Dupliques La rplication entrane la cration de copies multiples d'une base de donnes sur plusieurs sites. La duplication peut concerner la base entire, une ou plusieurs tables ou des fragments. A la suite de transactions les copies peuvent diverger un instant donn mais doivent converger vers un tat identique et cohrent terme.

Les Base de donnes Dupliques Les bases de donnes dupliques (ou rpliques) posent donc un problme particulier celui de la MISE A JOUR des bases pour obtenir cette convergence. Les avantages de la duplication Amliorer les performances : L'utilisation de la base la plus proche permet de limiter les transferts et de rpartir la charge de travail.

Les Base de donnes Dupliques Augmenter la disponibilit :En cas de panne en particulier. Utiliser des serveurs plus petits et moins chers. Les inconvnients de la duplication Il faut assurer la convergence des copies. Il faut assurer la transparence aux utilisateurs qui ne doivent percevoir qu'une seule copie.

Les Base de donnes Dupliques Deux types de mise jour : Mise jour SYNCHRONE Toute transaction entrane la mise jour en temps rel de toutes les copies de la base. Avantage : convergence immdiate Inconvnient : Coteux en ressources et complexit du systme (gestion des reprises sur panne) Technique parfois obligatoire : Base des taux de change par exemple.

Les Base de donnes Dupliques Mise jour ASYNCHRONE On prfre le plus souvent le mode asynchrone (ou mode diffr). Les mises jour sont effectues ds que possible ou des instants fixs.

Les Base de donnes Dupliques Le synchronisme se combine au concept de symtrie qui permet de crer une hirarchie dans les bases. Dans la rplication SYMETRIQE toutes les bases ont le mme degr hirarchique. Dans la rplication ASYMETRIQUE on distingue un site primaire charg de centraliser les mises jour.

Les Base de donnes Dupliques Exemple de mise jour asymtrique asynchrone (Consolidation dinformations) Les donnes comptables tenues jour dans les agences sont dupliques en lecture seulement vers le sige pour consolidation. Sige Social Agence Dpts & Retraits Mise jour en fin de journe par exemple

Exemple de mise jour asymtrique synchrone (Diffusion dinformations centralises) Les informations appartiennent au site primaire, qui a le monopole des mises jour Les donnes sont diffuses automatiquement vers les sites qui ont un droit de lecture seulement Les Base de donnes Dupliques Sige Social Agence Cours des devises Copie PRIMAIRE Copies SECONDAIRES

Exemple de mise jour symtrique asynchrone Chaque dpartement met rgulirement jour les donnes des autres dpartements. Les Base de donnes Dupliques Commercial FinancierStocks Copie Matre Temps diffr

Exemple de mise jour symtrique synchrone Chaque site modifie la donne PRIX puis diffuse immdiatement la modification. Les Base de donnes Dupliques Produit Copie Matre Modification du PRIX Temps rel

client/serveur. partie 1 : présentation du modèle client-serveur client/serveur

Documents

Optimisation Client-Serveur

Couche application H. Fauconnier M2-Internet 1 r Présentation générale: Modèle des services de la couche transport Modèle client- serveur et Modèle pair-à-pair

3 Std CS Donnees - Université de La Réunionlim.univ-reunion.fr/staff/courdier/old/cours/... · Client/Serveur de procédures : RPC Protocole de Communication Client/Serveur de procClient/Serveur

Systèmes de gestion de code source - projet PLUME3 Logiciels pour la gestion de version Modèle local Modèle client-serveur Modèle distribué 4 Conclusion Agenda 1 Introduction

Le Modèle Client-seveur

Environnement Client/Serveur Présentation de l ...jjipditchanou.free.fr/architecture_reseau_securite.pdf · Le modèle client/serveur est particulièrement recommandé pour des réseaux

Partie 1 : Architecture et communications Client/Serveur

Traitement géospatial hybride : client et serveur

RMI Remote Method Invocation - LIG Membreslig-membres.imag.fr/donsez/cours/rmi.pdf · • modèle client/serveur • appel de procédures à distances entre un client et un serveur

Systemes Client Serveur 1

INTRODUCTIONdata.over-blog-kiwi.com/.../ob_422d7e_architecture-client-serveur.pdf · L'architecture client-serveur L'architecture client-serveur est un modèle de fonctionnement logiciel

Développement d’une application mobile client/serveur

Cours 8 Modèle client-serveur · 2018. 1. 11. · Introduction Modèle client-serveur Un serveur écoute les demandes des clients sur un port particulier. Un client se connecte au

Le modèle client-serveur - imss- · Le modèle client-serveur – Master IC2A/DCISS – Christian Bulfone. Les applications réseau • Les applications sont la raison d’être

NSY107 -Intégration des systèmes client-serveur

Modèle client-serveur - bde.enseeiht.frlatombf/content/N7/i3.pdf · 2 Plan Principes généraux Modèle client-serveur Appel de procédure à distance (Remote Procedure Call) Application

module I6 Sockets - users.polytech.unice.frusers.polytech.unice.fr/~karima/teaching/courses/I6/cours/module_I... · Karima Boudaoud IUT GTR-Sophia Antipolis 4 Le modèle client-serveur

Description du modèle client-serveur

ARCHITECTURE CLIENT / SERVEUR - taz.newffr.comtaz.newffr.com/TAZ/Computer/client_serveur.pdf · Documents de Formation CARIP Version 2.0.0 Architecture Client / Serveur .....Page

Chapitre1 Le modèle client/serveur

La programmation client-serveur - Olivier Aubert · Le modèle client-serveur I Communication entre processus : un client, l’autre serveur, qui coopèrent. I Cette coopération

Programmation Client Serveur

client serveur

Architectures client/serveur

Chap 2 b ds client-serveur

Architecture Client-Serveur Ouverte pour Travaux Pratiques

Le modèle client-serveur

Services Réseaux - Couche Applicationsen.arbezcarme.free.fr/_techno/2.22-TR-Services-dedies-aux-reseaux... · FTP obéit à un modèle client-serveur, c’est-à-dire qu’une des

00 Integration Client Serveur

Agents mobiles et client/serveur : évaluation de ...riveill/mes-cours/autres-modeles/agents-tsi-00.pdf · Le modèle client/serveur est certainement le modèle le plus utilisé pour

Dynamic Host Configuration Protocol - univ-reims.frlsteffenel/cours/Master1/...Dynamic Host Configuration Protocol Extension du protocole BOOTP Bâti sur un modèle client-serveur

Développement d'une application Client/serveur avec Java RMI

transparents client-serveur dciss1213 - gipsa … · Le modèle client/serveur – Mas ter IC2A/DCISS – Christian Bulfone Les applications réseau • Les applications sont la raison

Architecture logicielle et construction d'applications client-serveur

Installation Client/Serveur Cegidv9 · Installation Cegid WebApp Installation Client/Serveur Cegidv9 Les sources sont disponibles à l’emplacement suivant : \\srv-compta\pgi01$