Intgration des systmes Client-Serveur

Objectifs: Comprendre l'ensemble des concepts qui sous-tendent les architectures client-serveur et rparties. Savoir concevoir, dvelopper, intgrer des architectures de type client-serveur. I. Origines et Historique

Dans un monde o la course la productivit conduit les technologies voluer de plus en plus vite, le client-serveur s'est taill une part de choix depuis le dbut des annes 1990. En effet, il faut pouvoir disposer de systmes d'information volutifs permettant une coopration fructueuse entre les diffrentes entits de l'entreprise. Les systmes des annes 70 et 80 ne rpondaient pas ces exigences. 1.1) Avant 1980 Les architectures taient centralises autour de calculateurs centraux (mainframe) de type IBM ou BULL par exemple. Les terminaux taient passifs interfaces caractres ou pages. Les applications taient dveloppes souvent en Cobol, parfois en PL 1 autour de fichiers ou de grandes bases de donnes rseaux ou hirarchiques, telles IDS2 ou DB2. La productivit des dveloppeurs restait faible. La maintenance des applications tait des plus difficiles. Les utilisateurs restaient prisonniers de systmes propritaires. Aujourd'hui, les applications hrites (Iegacy applications en anglais) dveloppes avec ces vieilles technologies sont encore souvent oprationnelles. Il est difficile de les migrer vers des technologies plus modernes. Beaucoup d'entreprises ou d'administrations pensent cependant au downsizing , c'est--dire remplacer leur calculateur central par un ou plusieurs serveurs dpartementaux interconnects des stations de travail graphiques, type PC par exemple. La figure 1 illustre les architectures centralises aujourd'hui candidates au downsizing.

Figure 1 -Exemple d'architecture centralise. 1.2) Les annes 80 Les annes 80 ont connu le dveloppement du transactionnel et des bases de donnes. Les systmes ont commenc migrer depuis des systmes propritaires vers des systmes plus ouverts type Unix. Les bases de donnes relationnelles ont vu le jour accompagnes de langages de dveloppement construits autour des donnes. SQL s'est impos comme la norme d'accs aux donnes. Les rseaux, notamment les rseaux locaux se sont dvelopps. D'un autre ct, les micro-ordinateurs se sont imposs dans l'entreprise et ont apport des interfaces graphiques conviviales. Le maintien des mainframes, le dveloppement des systmes dpartementaux, la profusion d'ordinateurs personnels ont rendu les communications difficiles. 1.3) Les annes 90 Les rseaux occupent dsormais une place centrale dans l'entreprise. Les vitesses de calcul des micros deviennent impressionnantes. Le graphique est partout au niveau des interfaces. Le besoin de partage des donnes est essentiel aussi bien pour l'accs transactionnel caractris par des mises jour rapides en temps rel que pour l'accs dcisionnel marqu par le besoin de requtes complexes sur de gros volumes de donnes. Il faut dvelopper vite, par exemple pour ne pas rater un mailing cibl suite une campagne de promotion. La concurrence entre les entreprises est exacerbe; la flexibilit et la productivit de l'informatique font souvent la diffrence. Toutes ces raisons expliquent le dveloppement autour des rseaux d'entreprises de serveurs dpartementaux ouverts offrant des interfaces standards pour permettre la connectivit des outils micros. C'est aussi pour faciliter le partage et l'accs simplifi aux donnes que triomphe les bases de donnes relationnelles avec la possibilit de grer des types de donnes tendus (Binary Large OBject BLOB par exemple). Pour amliorer la vitesse de dveloppement et surtout la maintenabilit des applications, on voit s'imposer des mthodes de conception et de dveloppement orientes objets. Ainsi, l'architecture type d'un systme moderne a volu vers celle reprsente figure 2. Il s'agit l d'une architecture client-serveur (en abrg, C/S).

II.

Figure 2 -Exemple d'architecture moderne des annes 90. CARACTERISTIQUES DE L'APPROCHE C/S

Qu'est-ce que le client-serveur ? Voil une question difficile car le mot est souvent trs galvaud. C'est de fait un modle d'architecture la mode et assez large pour recouvrir des ralits distinctes, comme nous allons le voir dans la suite. 2.1) Une rpartition hirarchique des fonctions L'architecture client-serveur s'articule en gnral autour d'un rseau. Deux types d'ordinateurs sont interconnects au rseau. Le serveur assure la gestion des donnes partages entre les utilisateurs. Le client gre l'interface graphique de la station de travail personnelle d'un utilisateur. Les deux communiquent par des protocoles plus ou moins standardiss. Les programmes applicatifs sont idalement distribus sur le client et/ou le serveur afin de minimiser les cots. 2.2) Dfinition En fait, l'architecture client-serveur est plus large. Un rseau n'est pas toujours ncessaire. Il est possible de la raliser sur une mme machine (et pourquoi pas sur un mainframe !) en dgageant deux processus, l'un le client -qui envoie des requtes l'autre -le serveur-, ce dernier traitant les requtes et renvoyant des rponses. Une dfinition trs large peut donc tre propose. Notion 1 : Architecture client-serveur (Client-Server Architecture) Modle d'architecture applicative o les programmes sont rpartis entre processus clients et serveurs communiquant par des requtes avec rponses. Dans ce cours, nous nous concentrerons gnralement sur les architectures client-serveur de donnes et procdures, o clients et serveurs communiquent par un rseau, o les serveurs sont munis d'un SGBD, et o les clients, mais souvent aussi les serveurs, sont capables d'excuter des procdures applicatives. 2.3) Une grande diversit d'outils Le type de client-serveur que nous tudions est celui aujourd'hui mis en oeuvre pour raliser les systmes d'information des entreprises. Il comporte les composants suivants : Un systme ouvert plus ou moins bas sur des standards publis ou de fait pour raliser les fonctions de base du serveur. Un SGBD s'excutant sur le serveur, gnralement bas sur le modle relationnel et le langage SQL. Des stations de travail personnelles avec interface graphique connectes au rseau, par exemple des PC. Des outils de dveloppement d'applications varis de plus en plus frquemment construits autour d'une approche objet. Des logiciels de transport de requtes et rponses associs au SGBD ou indpendants. Des outils de conception, de dploiement et de maintenance pour permettre le suivi du cycle de vie des applications. En clair -et c'est sans doute une force mais aussi une source de complexit tout outil de conception, dveloppement, aide la dcision, gestion de transactions, gestion de donnes, gestion de communications, etc., peut trouver sa place dans une architecture client-serveur. Donc vive le client-serveur ! 2.4) Une approche ouverte Les systmes client-serveur appliquent une stratgie du type systmes ouverts. Ces systmes s'appuient sur des standards plusieurs niveaux. Plus particulirement, les standards importants en matire de clientserveur sont ceux labors par 1'180, l'AN81, l'IEEE, I'X/Open, 1'0 MG et 1'08F .

L'ISO (International Standard Organisation) est l'organisation internationale intgre aux Nations Unies qui entrine les standards internationaux. L'AN81 (American National Standardisation Institute) est l'organisme de normalisation nord amricain qui soumet des propositions 1'180. L'IEEE (Institute of Electrical and Electronic Engineers) se compose de nombreux comits scientifiques et techniques, dont certains laborent des propositions pour l'ANSI. L'X/Open est une association internationale but non lucratif compose de constructeurs (pour l'essentiel amricains) qui dfinit et diffuse les technologies construites partir des standards en matire de systmes ouverts. Ce groupe construit des documents de spcifications qui prcisent et compltent les standards. Il a particulirement propos un ensemble de spcifications pour les environnements applicatifs appel CAE (Common Application Environment) trs utiliss en client-serveur. L'OMG est le pendant de I'X/Open pour les systmes orients objets. Il propose une architecture objets distribus appele OMA (Object Management Architecture). L'08F (Open Software Foundation) est un organisme but non lucratif qui dveloppe un systme d'exploitation rparti bas sur les standards. Il promeut l'architecture distribue DCE (Oistributed Computing Environment). Tous ces organismes se compltent en gnral, mais sont parfois concurrents. Ils sont clairement domins par les grands constructeurs amricains. L'intrt des utilisateurs pour les systmes ouverts bass sur les standards est vident. Ceci devrait en thorie permettre d'une part la portabilit des applications, d'autre part la possibilit de remplacer un composant d'un constructeur par celui d'un autre conforme aux standards. Aujourd'hui, les groupes de standardisation sont parfois trop nombreux et trop dirigs par le marketing, si bien qu'il est permis de se demander si des solutions thoriquement bases sur des standards ne sont pas tout autant propritaires que celles d'un constructeur particulier. Un bon exemple est D80M d'IBM par rapport OLE de Microsoft. III. Pourquoi le C/S ? Outre l'avantage de pouvoir fdrer une panoplie de vendeurs d'outils, le client-serveur rpond aux vrais besoins actuels des entreprises. 3.1) Les contraintes de l'entreprise Les entreprises sont soumises des contraintes de plus en plus fortes, aussi bien du monde extrieur que de l'intrieur de l'entreprise. Les contraintes externes sont imposes par les clients de plus en plus exigeants, la rgulation de plus en plus complexe, la comptition de plus en plus dure qui conduit rduire le temps de passage d'un produit de la conception la vente. Plus prcisment, il s'agit donc de : mieux satisfaire les clients, par exemple en leur prsentant des informations consolides et claires ; respecter les rgulations en vigueur, malgr leur volutivit, par exemple en tant capable de gnrer rapidement de nouvelles dclarations ; produire mieux et plus vite les nouveaux produits, de sorte participer la comptition active vers la nouveaut, et rduire le time ta market. Les contraintes internes se traduisent par des pressions sur les budgets, la difficult absorber les technologies nouvelles, et un manque gnral de temps et de moyens. Les budgets sont de plus en plus serrs, car la compression des dpenses est ncessaire l'quilibre de l'entreprise. De ce fait, les ressources sont limites, et les exprimentations avec des technologies nouvelles, souvent coteuses du fait du poids de plus en plus grand de l'historique, ne peuvent tre menes bien. Les ingnieurs et techniciens au fait des technologies nouvelles manquent cruellement de temps, et la conversion des autres est difficile. Ainsi, on observe dans la plupart des entreprises les problmes suivants : budgets et ressources limits rduisant les capacits d'innovation et de reprise de l'existant ; capacits absorber de nouvelles technologies limites par les moyens humains et matriels, et par le poids de l'existant ; manque de temps des personnels les plus qualifis. 3.2) Mieux matriser le systme d'information Une approche de solution aux problmes mentionns passe par une meilleure organisation du systme d'information qui doit devenir plus intgr, mais aussi plus volutif. Ceci ncessite tout d'abord l'adoption de systmes ouverts, obissant des standards permettant le choix d'un grand nombre de produits sur le march. Il faut donc tout prix viter les solutions s'enfermant sur un constructeur ou des dveloppements maison ignorant les standards, solutions propritaires qui risquent terme de limiter les choix et la

concurrence des fournisseurs, et donc d'augmenter les cots. L'intgration et l'volutivit passent par l'architecture client-serveur, qui permet l'intgration des donnes mais aussi des traitements communs de l'entreprise au sein du serveur relationnel, et l'volutivit des applications dveloppes sur les clients de type PC ou station de travail. La rutilisation d'applications existantes ou dveloppes dans l'entreprise, avec possibilit d'adaptation ou de spcialisation, est aussi un lment dterminant pour le choix d'une architecture client-serveur et des outils de dveloppement. Le choix d'un systme d'information articul autour d'une architecture ouverte, client-serveur, btie sur un moteur relationnel, apporte une meilleure matrise de l'information et une plus grande souplesse d'volution. En effet, le modle relationnel permet une prsentation simple et claire des donnes. Il est le standard industriel; il permet une bonne productivit des dveloppeurs grce au langage SQL, normalis ds 86, qui a volu en 89 (SQL 1 complet) et en 92 (SQL2 avec trois niveaux distingus: entre, intermdiaire et complet). Aujourd'hui, les serveurs relationnels, efficaces et robustes, permettent rapidement la conception et le dveloppement d'applications partir d'une modlisation entit-association ou objet supporte par des outils de conception de schma de donnes et de programmes autour d'un dictionnaire de donnes de rfrence partageable (outils CASE ). Des outils de dveloppement riches et varis permettent la programmation classique (L3G) ou avance (L4G), l'aide la dcision partir des donnes de la base (tableurs et SIAD intgrs), le traitement de textes intgrs (textes, courrier lectronique) et le support de documents multimdias. De plus, le relationnel garantit l'volutivit vers une approche objet progressive et vers une rpartition fiable des bases de donnes. Il permet aussi l'interoprabilit ncessaire l'intgration des applications existantes. Un lment cl qui milite pour choisir un SGBD relationnel dans une grande entreprise est la ncessit de rutiliser les applicatifs dvelopps au niveau des diffrentes entits de l'entreprise. Avec un serveur relationnel et des outils clients bien choisis, une entit pourra dvelopper un projet pilote et le proposer aux autres. Les projets pilotes pourront ainsi tre transposs aprs une ventuelle adaptation de succursale en succursale. Grce aux procdures stockes sur le serveur autour d'une base, des infrastructures d'applications communes pourront tre partages et adaptes au niveau des clients. Par les techniques d'ouverture et d'interoprabilit, l'existant sur calculateur central pourra tre rcupr et prsent comme une base intgre un serveur. Autour des grands serveurs relationnels, de nombreux progiciels ont t dvelopps. L'industrie se spcialise par mtiers: finance, assurance, pharmacie, transports, services publics, etc. Des organisations dveloppent des modles standard, par exemple POSC dveloppe le modle des ptroliers. Les fournisseurs de SGBD commencent proposer des modles rutilisables, incluant des modles d'entreprise spcialisables, des vues par domaines, des packages applicatifs spcialisables, et mme du service et du conseil. Les avantages d'une telle approche sont de factoriser les expriences, de permettre la rutilisation de solutions prouves mais adaptables, et finalement de rduire les cots et temps de dveloppement. 3.3) Prendre en compte l'volution technologique Au-del de la matrise du systme d'information qui passe par un serveur relationnel ventuellement tendu l'objet, le client-serveur apporte une modularit des composants matriels et logiciels. Ceci permet d'intgrer plus facilement les volutions technologiques. Par exemple, l'usage de systmes ouverts bass sur les standards apporte des environnements de dveloppement graphiques souples tels X/Motif de l'OSF que l'on peut intgrer progressivement. L'explosion de la puissance des micros (graphique, traitement, disques) permet de supporter efficacement le graphique au niveau de chaque station client. Un autre exemple est l'exploitation du paralllisme rendu possible au niveau des serveurs pour manipuler de grandes masses d'informations. On peut envisager de passer sans problme d'incompatibilit d'une configuration monoprocesseur une configuration multiprocesseurs. Le dveloppement des technologies multimdia peut s'effectuer plus facilement au niveau des PC clients sans remettre en cause l'architecture du systme. En rsum, le client-serveur facilite l'intgration des technologies nouvelles dans le systme d'information de l'entreprise, ce qui est trs important. 3.4) Rduire les cots ? Le client-serveur permet une meilleure ractivit de l'entreprise. Il amliore l'ouverture du systme d'information et la productivit des dveloppeurs. Il permet un dploiement plus rapide sur des architectures rparties htrognes. Oui, mais quel prix ? Les cots du client-serveur sont discuts. Par rapport une architecture centralise autour de terminaux passifs, des surcots sont prvoir : poste de travail local type PC ;

rseau local ; formation des dveloppeurs ; techniciens de maintenance rseaux et PC.

En consquence, le client serveur apparat souvent plus cher qu'une solution centralise, comme illustr figure 3 pour une configuration typique d'environ 50 postes. La diffrence essentielle est sans doute le facteur humain et la formation: pour matriser le client serveur, il faut comprendre les SGBD, le middleware, l'objet et les interfaces graphiques. C'est un peu difficile, surtout lorsque l'on doit recycler des dveloppeurs Cobol.

IV.

Figure 3- Cots compars client-serveur et systme centralis. Les Gnrations de C/S

Le client-serveur n'a pas encore dix ans. Et pourtant, on distingue dj deux gnrations de systmes. La premire gnration ne la fin des annes 80 est base sur des outils clients autour des SGBD relationnels. Le dveloppement s'effectue sur le serveur pour la base de donnes et sur le client pour l'application. La base de donnes est relationnelle et dveloppe avec SQL. L'application est programme sur le client partir d'un L4G intgrant une interface graphique et des requtes SQL au serveur. Autour des requtes, les traitements s'crivent par des constructions procdurales du type assignations, calculs, tests et boucles. Ils grent les affichages d'crans et les saisies. Tout le code applicatif est excut sur le client. Celui-ci envoie des requtes SQL au serveur par un outil de connexion et rcupre les rsultats. En rsum, l'architecture client-serveur de premire gnration est schmatise figure 4.

Le client-serveur de deuxime gnration apparat seulement sur le march. Il se caractrise par une volution des outils dans trois directions . 1. Possibilit de dvelopper des traitements applicatifs au sein du serveur de donnes sous forme de procdures dclenches par l'application ou lors d'vnements survenant dans la base. 2. Utilisation intensive de l'approche oriente objet non seulement pour construire les interfaces graphiques, mais aussi pour modliser les entits de l'entreprise et leurs relations. 3. Facilits de dploiement des applicatifs avec partitionnement automatique du code applicatif entre client et serveur, et avec gestion d'un rfrentiel des objets de l'application vritable dictionnaire contenant la dfinition des fentres, des entits, des associations, des procdures, etc. au niveau du serveur. Ces trois caractristiques sont apparues essentielles pour les applications afin d'optimiser les performances, de faciliter la rutilisation de composants mmoriss dans un rfrentiel partag, d'tre capable de grer des configurations complexes avec un nombre important de clients et une diversit de systmes. Par exemple, la gestion de procdures stockes dans la base de donnes et excutes par le serveur permet de rduire le trafic rseau. La modlisation objet permet de visualiser rapidement les classes d'objets mis en jeu par un support graphique appropri, d'utiliser des mthodologies de conception, de reprendre des bibliothques d'objets existantes en les adaptant aux problmes traiter. La gestion automatique de versions de code au niveau du rfrentiel permet les mises niveau souvent difficiles sur des configurations htrognes ayant quelques centaines de postes clients. Le client-serveur de deuxime gnration illustr figure 5, qui pourrait dans un futur proche, s'appuyer sur des outils d'change de requtes entre objets (Object Request Broker), parat prometteur. Il lui reste cependant faire ses preuves.

Figure 5 - Architecture client-serveur de deuxime gnration. L'ARCHITECTURE CLIENT-SERVEUR V. INTRODUCTION

Ce chapitre propose une vue d'ensemble de l'architecture client-serveur et dfinit les notions de base indispensables la comprhension du modle. Qu'est-ce que le client-serveur? C'est avant tout un mode de dialogue entre deux processus. Le premier appel client demande l'excution de services au second appel serveur. Le serveur accomplit les services et envoie en retour des rponses. En gnral, un serveur est capable de traiter les requtes de plusieurs clients. Un serveur permet donc de partager des ressources entre plusieurs clients qui s'adressent lui par des requtes envoyes sous forme de messages. Le client-serveur tant un mode de dialogue, il peut tre utilis pour raliser de multiples fonctions. Il existe donc diffrents types de client-serveur qui ont t dfinis dans un schma clbre publi pour la premire fois par le Gartner Group. On distingue plus particulirement le client-serveur de prsentation, le client serveur de donnes et le client-serveur de procdures. Avec le client serveur de prsentation, le client assure seulement l'affichage et la saisie des informations. Avec le client-serveur de donnes, le serveur accomplit la gestion des donnes. Dans le cas du serveur de procdures, le serveur excute des procdures pour le compte des clients; ces procdures peuvent accder aux donnes. Ces deux derniers types de clientserveur convergent aujourd'hui vers une architecture client-serveur de donnes et procdures qui est le cur de cet ouvrage. En consquence, ce chapitre est consacr l'tude des principes de base des composants de l'architecture client-serveur de donnes et procdures. Le serveur est aujourd'hui bas sur un SGBD relationnel excutant des requtes SQL et des procdures stockes. Demain peut-tre les serveurs de donnes seront bass sur l'objet. Aujourd'hui, ce sont surtout les outils L4G et AGL qui s'inspirent de l'approche objet. L'objet repose sur trois piliers, encapsulation, hritage et polymorphisme, alors que le relationnel est fond sur une vision tabulaire des donnes accdes par une algbre. Ces modles de donnes et traitements constituent les fondements de l'architecture client-serveur. Nous rappelons les principes essentiels de ces modles cidessous. Le lecteur dsirant en savoir plus sur le relationnel pourra se reporter [Gardarin93] ; celui dsirant en savoir plus sur l'objet pourra se reporter [Bouzeghoub94]. Un des composants cl de l'architecture client-serveur est le middle ware. Que dsigne ce mot barbare venu des tats-Unis ? Il s'agit simplement de logiciels assurant la mdiation entre clients et serveur(s) dans le cadre d'architectures de systmes htrognes. Mais les mdiateurs peuvent assurer de multiples fonctions telles l'homognisation des formats de requtes et de donnes, l'optimisation des accs, la gestion de services distribus, etc. Les fournisseurs de mdiateurs ajoutent progressivement de l'intelligence ces outils qui sont approchs dans ce chapitre et seront dvelopps dans le suivant. Ce chapitre propose donc une architecture de rfrence pour le client-serveur de donnes et procdures. Dans la section 2, nous prsentons le mode de dialogue client-serveur, indpendamment des fonctions accomplies et des matriels ou logiciels supports. Les deux sections qui suivent analysent les diffrents types de client-serveur et dtaillent le client-serveur de donnes et procdures. Nous rappelons les principes des serveurs de donnes et procdures, du relationnel et de SQL dans la section 5. Dans la section 6, les objectifs et fonctions des mdiateurs sont examins. Dans la section 7, les diffrentes classes d'outils sont

aussi isoles et nous tentons en particulier de diffrencier L4G et AGL. La conclusion rsume le chapitre et discute des volutions prvisibles de l'architecture. VI. Techniques de dialogue Client -Serveur

Le client-serveur est avant tout une technique de dialogue entre deux processus, l'un -le client- sous-traitant l'autre -le serveur -des fonctions raliser. Nous allons dans cette section tudier plus en dtail ce mode de dialogue. 2.1) Notions de base Le modle de communication client-serveur est orient vers la fourniture de services par un processus serveur un processus client. Un change consiste donc en la transmission d'une requte un serveur, qui excute l'opration demande et envoie en retour la rponse. Nous dfinissons ci-dessous plus prcisment ces concepts de base. Notion 1 : Client (Client) Processus demandant l'excution d'une opration un autre processus par envoi d'un message contenant le descriptif de l'opration excuter et attendant la rponse cette opration par un message en retour. Notion 2 : Serveur (Server) Processus accomplissant une opration sur demande d'un client et transmettant la rponse ce client. Notion 3 :Requte (Request) Message transmis par un client un serveur dcrivant l'opration excuter pour le compte du client. Notion 4 :Rponse(Reply) Message transmis par un serveur un client suite l'excution d'une opration contenant les paramtres de retour de l'opration. En rsum, la figure 1 illustre ces notions: un client excute une application et demande l'excution d'une opration un serveur par le biais d'une requte. Il reoit une rponse, lui indiquant par exemple que l'opration a t bien excute. Les appels au service de transport mis en jeu sont au nombre de quatre: SendRequest() permet au client d'mettre le message dcrivant la requte une adresse correspondant la porte d'coute du serveur, ReceiveReply() permet au client de recevoir la rponse en provenance du serveur ; ReceiveRequest() permet au serveur de recevoir la requte sur sa porte d'coute, SendReply() permet au serveur d'envoyer la rponse sur la porte d'coute du client.

Figure 6 -Le dialogue client-serveur. 2.2) Protocoles de type question-rponse Comme vu ci-dessus, le dialogue client-serveur s'appuie sur l'envoi de requtes et de rponses en sens inverse. Des oprations de transport permettant d'envoyer (Send) et de recevoir (Recaive) des messages sont typiquement utilises cette fin. Les protocoles de question-rponse peuvent s'implmenter au-dessuS d'une couche session. Celle-ci doit alors tre tablie entre le client et le serveur par des primitives de connexion (Connact), puis de dconnexion (Oisconnact) en fin de session. Ils peuvent aussi tre implments directement au-dessus d'un service de datagrammes, qui permet d'envoyer des messages des portes associes aux clients et au serveur, ce que nous avions implicitement suppos ci-dessus. L'identification des clients et des serveurs dans un rseau est un problme d'adressage rseau. Une ou plusieurs adresses de porte sont gnralement associes un serveur. Cette adresse peut tre dpendante du site ou indpendante, ce qui permet un changement de localisation des serveurs sans changement d'adresse.

Nous avons vu ci-dessus que quatre appels au service de transport (deux Sand et deux Racaiva ) sont gnralement ncessaires pour effectuer un dialogue client-serveur. Dans des systmes avancs comme Chorus et Mach, trois appels au service de transport sont suffisants: le SandRaquast() et RacaivaRaply() effectus par le client sont groups en une seule opration appele OoOparation(), qui permet donc la fois d'envoyer la requte et de recevoir la rponse [Coulouris94]. Ce mode de dialogue souligne bien le fonctionnement client-serveur, o le client sous-traite finalement l'excution d'une opration au serveur. 2.3) Assemblage-dsassemblage des paramtres En gnral, client et serveur s'excutent sur des machines htrognes qui communiquent par un rseau. Les donnes sont souvent codes de manires diffrentes sur des machines distinctes. Il est donc ncessaire de dfinir un format d'change standard, afin de convertir les noms de fonctions et paramtres dans ce format lors de l'mission, et de les convertir en sens inverse lors de la rception. Plusieurs standards existent, dont X DR propos par SUN, Courrier de Xerox, et ASN .1 (Abstract Syntax Notation) du CCITT . Lors de l'mission d'une requte, les paramtres doivent tre arrangs et cods sous forme de message: c'est l'assemblage. A l'arrive, ils doivent tre remis en format interne de manire symtrique partir du message reu: c'est le dsassemblage. Notion 5: Assemblage (Marshalling) Procd consistant prendre une collection de paramtres et les arranger et coder en format externe pour constituer un message mettre. Notion 6: Dsassemblage (Unmarshallng) Procd consistant prendre un message en format externe et reconstituer la collection de paramtres qu'il reprsente en format interne. 2.4) Appel de procdure distance Dans un systme centralis, l'appel d'opration (fonction ou procdure) s'effectue directement par un dbranchement depuis l'appelant vers l'appel (cf. figure 7). Ceci n'est plus possible dans un environnement distribu. Afin de rendre transparent le dialogue client-serveur, la technique d'appel de procdure distance (RPC) a t introduite [Xerox81 , Birrell84]. Notion 7 : Appel de procdure distance (Remote Procedure CalI RPC) Technique permettant d'appeler une procdure distante comme une procdure locale, en rendant transparents les messages changs et les assemblages/ dsassemblages de paramtres. Le RPC offre les fonctions de l'appel l'appelant sur le site de ce dernier. Il est ralis par introduction d'une souche de procdure (en anglais, stub) pour transformer l'appel de procdure en un envoi de message depuis le site de l'appelant au site de l'appel. L, une souche de procdure symtrique reoit le message et ralise l'appel effectif de l'appel par dbranchement. Les paramtres de retour transitent par un chemin inverse via le rseau d'interconnexion . Notion 8 :Souche (Stub) Reprsentant d'une procdure sur un site client ou serveur capable de recevoir un appel de procdure du client et de le transmettre en format adapt l'implmentation ou son reprsentant.

Figure 7- Illustration du RPC. De manire plus dtaille, la figure 3 reprsente les flots de donnes entre client et serveur. La souche client reoit l'appel de procdure de l'application. Elle assemble les paramtres et envoie la requte par la commande SendRequest() sur le rseau. La souche serveur reoit la requte par la commande ReceiveRequest(), recherche le code de la procdure excuter, dsassemble les paramtres, et lance

l'excution de la procdure. La rponse est transmise en fin d'excution la souche serveur qui l'assemble et l'envoie la souche client par la commande SendReply(). La souche serveur reoit la rponse par la commande ReceiveReply(), la dsassemble, et la transmet l'application. Tout est donc transparent pour

l'application. Figure 8 -Fonctionnement du RPC. Les souches peuvent tre gnres automatiquement partir d'un langage de description d'interface, permettant de spcifier les noms des procdures appeles, les noms, positions, et types des paramtres d'entre et de sortie. Ce langage peut tre dfini comme une extension d'un langage existant (par exemple C), ou comme un langage indpendant de tout langage de programmation (par exemple IDL Interface Definition Language). 2.5) Dialogue synchrone et asynchrone Le dialogue client-serveur ncessite l'mission d'une requte et la rception d'une rponse. Le RPC permet de cacher ces mcanismes de bas niveau pour l'application. Lors de l'mission d'une requte par une commande SendRequest(), celle-ci peut tre mise immdiatement ou mise en file d'attente pour mission ultrieure. Dans ce dernier cas, la commande SendRequest() n'est gnralement pas bloquante, et l'utilisateur peut effectuer une autre tche avant de venir attendre la rponse par une commande ReceiveRequest. Cette dernire commande peut de mme tre bloquante en attente de la rponse, ou non bloquante avec un code retour signalant que la rponse n'est pas arrive. Ceci conduit distinguer les notions de dialogue synchrone et de dialogue asynchrone. Notion 9 : Dialogue synchrone (Synchronous dialog) Type de dialogue gr sans file d'attente, o les commandes d'mission et de rception sont bloquantes. Typiquement, dans le cas synchrone, le client attend le serveur pendant que celui-ci excute une opration pour lui. Notion 10 : Dialogue asynchrone (Asynchronous dialog) Type de dialogue gr avec file d'attente, o l'une au moins des commandes d'mission ou de rception est non bloquante. Le dialogue asynchrone permet au client d'effectuer une autre tche pendant que le serveur excute une opration pour lui. Il permet aussi, par le biais des files d'attente, de demander plusieurs oprations au serveur avant de recevoir les rponses. Fondamentalement, le RPC est synchrone de sorte assurer la transparence de l'appel. Il peut cependant tre gnralis au mode asynchrone. Pour ce faire, au moins deux cas sont possibles: (1) soit la procdure appele est sans rponse; alors l'appelant n'attend pas l'envoi de la requte qui est simplement dpose en file d'attente; (2) soit l'appel de procdure distance provoque un dbranchement chez le client qui peut continuer travailler, jusqu' rception de la rponse qui provoque un moment opportun un retour la sortie de la procdure appele. Comme on le voit, le RPC asynchrone est complexe. Il est cependant trs utile par exemple pour la mise jour asynchrone de copies. Il faut aussi garantir l'mission de la requte

dpose en file d'attente, mme en cas de panne d'un site, si bien que les files doivent tre persistantes et gres sur disques comme des journaux. ,

VII.

Les diffrents types de Client/Serveur Selon la nature des services accomplis par le serveur pour un client, diffrents types de client-serveur ont t distingus. La figure 4 illustre diverses possibilits reconnues. Selon la rpartition des fonctions de prsentation graphique (affichage et saisie de donnes partir d'icnes graphiques par exemple), de gestion de donnes (accs aux fichiers ou aux bases de donnes), d'excution de code applicatif (calculs de l'application), on distingue les types de client-serveur dcrits ci-dessous. Tout d'abord, l'architecture client-serveur peut tre mise en uvre afin d'assurer une meilleure qualit du dialogue homme-machine. Un processus serveur, souvent excut sur une machine spare (par exemple un terminal intelligent) excute les fonctions d'entres-sorties graphiques pour un processus client qui excute le code applicatif. Cette organisation est appele client-serveur de prsentation. Elle peut tre utilise pour transformer une interface homme-machine caractres en interface graphique: on parle alors de rhabillage.

Figure 9 -Rpartition des fonctions selon le type de client-serveur. Notion 11 : C/S de prsentation (Presentation CIS) Type de client-serveur dans lequel un processus excute seulement les fonctions de dialogue avec l'utilisateur, l'autre grant les donnes et excutant le code applicatif . Notion 12 : Rhabillage (Revamping) Type de client-serveur dans lequel un processus excute les fonctions de dialogue sophistiques avec l'utilisateur, l'autre grant les donnes, excutant le code applicatif, et assurant des dialogues simplifis avec le client. Ces deux types de client-serveur sont voisins. Cependant, le rhabillage permet de reprendre des applications existantes effectuant par exemple des dialogues mode caractres, et de les connecter une autre machine transformant les dialogues modes caractres en dialogues graphiques, avec fentres, boutons, menus droulants, souris, etc. La machine assurant la prsentation des messages l'utilisateur peut tre un serveur graphique, par exemple X, Motif, ou Windows. Dans ce cas, la machine excutant le code applicatif dialogue avec le serveur graphique, par exemple par RPC. On a donc l un dialogue clientserveur renvers ou la machine grant les donnes est cliente de la machine grant l'interface utilisateur, ce qui est aussi le cas pour le serveur de prsentation. Le client-serveur le plus rpandu aujourd'hui est le client-serveur de donnes. Cette architecture permet par exemple un client type PC d'aller accder des donnes partages gres par un serveur SQL. Notion 13 : C/S de donnes (Data CIS) Type de client-serveur dans lequel un programme applicatif contrl par une interface de prsentation sur une machine cliente accde des donnes sur une machine serveur par des requtes de recherche et mise jour, souvent exprime avec le langage SQL. Le serveur de donnes gre une ou plusieurs base de donnes. La base de donnes est accde par le langage SQL (Structured Query Language). De plus en plus souvent, elle intgre des procdures stockes,

procdures applicatives recevant des paramtres d'entre, accdant la base, et retournant des paramtres de sorties. Ainsi, le client-serveur de donnes devient de plus en souvent, dans sa nouvelle gnration, un client-serveur de procdures dfini comme suit. Notion 14 : C/S de procdures (Procedure CIS) Type de client-serveur dans lequel un programme applicatif contrl par une interface de prsentation sur une machine cliente sous-traite l'excution de procdures applicatives une machine serveur, ces procdures encapsulant souvent une base de donnes. Parfois, les auteurs opposent le client-serveur de donnes, o aucun code applicatif n'est excut par le serveur, au client-serveur de procdures, o une partie du code applicatif est excut par le serveur. Le premier est appel client-serveur de premire gnration, alors que le second constitue le client-serveur de deuxime gnration. Dans le premier cas, les donnes sont dplaces vers le programme applicatif, alors que dans le second du code applicatif est install sur le serveur puis excut sur demande du client. Nous n'opposerons pas client-serveur de donnes et client-serveur de procdures. Dans une architecture de deuxime gnration, le serveur de procdures inclut un serveur de donnes bas sur SQL. Le client peut accder directement aux donnes via SQL, ou appeler des procdures qui manipulent les donnes. Le client-serveur de deuxime gnration implique donc une intgration du client serveur de donnes et de procdures. VIII. LE C/S DE DONNEES ET PROCEDURES

La tendance est donc d'aller vers un systme d'information du type client-serveur de donnes et procdures. De plus en plus souvent, ce type de client-serveur permet de mettre en commun des procdures communes autour de la base de donnes au niveau du serveur, et donc de rpartir les traitements entre client et serveur. Plus prcisment, les composants d'une telle architecture (cf. figure 5) sont les suivants : 1. Les clients. Ils supportent le code de l'application non li directement aux donnes. Ce code est ralis grce un outil de dveloppement d'application. Il implmente les dialogues interactifs avec les utilisateurs, les traitements spcialiss des messages, l'affichage des rsultats. 2. Le serveur. Il assure le stockage, la distribution, la gestion de la disponibilit et de la scurit des donnes. Il permet l'accs transactionnel et dcisionnel aux informations. Classiquement, il regroupe les fonctionnalits du SGBD et sera aujourd'hui bti autour du modle relationnel, qui est simple, clair, et volutif. Il devra aussi autoriser la mise en commun de traitements communs, souvent lis aux donnes de la base, par le moyen de procdures stockes. 3. Le rseau. Avec les protocoles rseau de transport et d'change de requtes, il permet le transfert des demandes et des rsultats. Il assure la connectabilit des outils clients au serveur; l'outil de connectabilit permet l'encodage des requtes en messages sur le client, et le dcodage sur le serveur, et vice versa pour les rponses.

Figure 10 - Les composants de l'architecture client-serveur de donnes.

Les intrts techniques d'une architecture client-serveur de donnes et procdures sont multiples. Parmi ceux-ci nous citerons les suivants : La diminution du codage des applications. L'application ne gre pas la scurit et la cohrence de l'information. Les procdures de gestion et contrle des donnes sont codes une fois pour toute au sein du serveur. L'accs aux informations s'effectue via SQL, langage de haut niveau normalis. La mise en commun des procdures rutilisables. En effet, avec les serveurs modernes, il est possible de dvelopper des bibliothques de procdures accdant intensivement la base sur le serveur. Les donnes peuvent ainsi tre encapsules par les fonctions de service. Mieux, des rgles de gestion dclenches automatiquement lors des mises jour peuvent tre programmes au niveau du serveur. La diminution du trafic rseau. Celui-ci ne vhicule plus que les donnes utiles (requtes, rsultats), aprs slection et transformation des donnes sur le serveur. De plus, grce aux procdures stockes, il est possible de limiter le trafic aux seuls paramtres ncessaires aux transactions. La gestion transactionnelle fiable des donnes. Le serveur fournit tous les clients la gestion de transactions atomiques, cohrentes, mises jour isoles, et effets durables (ACID). Il gre des journaux et sauvegardes pour assurer les reprises. La scurit des accs aux donnes. Le serveur permet d'authentifier les utilisateurs et de contrler les droits d'accs selon les autorisations alloues aux utilisateurs ou aux groupes d'utilisateurs. L'optimisation et l'administration centralise des donnes. L'efficacit des accs disques est gre par le SGBD au niveau du serveur qui maintient une gestion centralise des chemins d'accs et une optimisation sophistique des requtes selon des modles de cots paramtrs. Ceci permet de concentrer le travail important d'administration des donnes sur un lieu unique, au profit de tous. IX. LES FONCTIONS DES SERVEURS DE DONNEES

Le client-serveur de donnes (et souvent de procdures) s'appuie sur un serveur de donnes. Les serveurs de donnes sont bass sur les SGBD relationnels, dont nous rappelons ci-dessous les fonctions essentielles. 5.1) Le modle relationnel Le modle relationnel a t introduit par E.F. Codd [Codd70]. Ce modle est aujourd'hui utilis par la plupart des serveurs de donnes, bien que quelques-uns commencent proposer le modle objet [Atkinson89]. En effet, le modle relationnel prsente plusieurs avantages. 1. Il permet un haut degr d'indpendance des programmes d'applications par rapport la reprsentation interne des donnes -donc des clients au serveur -, les clients ne voyant que des tables logiques et tant affranchis de la gestion des mthodes de stockage et des chemins d'accs (index). 2. Il offre un langage de dfinition et de manipulation de donnes normalis, bas sur des requtes non procdurales qui permettent des transferts d'ensembles de lignes constituant de vritables sous-tables entre clients et serveurs. 3. Il fournit une base solide pour traiter les problmes de cohrence des donnes, en supportant notamment des contraintes d'intgrit bases sur la logique du premier ordre, et la possibilit d'intgrer la base des rgles de gestion complexes. 4. C'est un modle extensible permettant de modliser et manipuler simplement des donnes tabulaires, mais pouvant tre tendu pour grer des objets complexes longs, voire structurs. Le modle relationnel est bas sur le concept mathmatique de relation. Les ensembles de donnes de dpart sont appels domaines. Un domaine est en thorie un ensemble quelconque de valeurs, par exemple un ensemble d'entiers ou un ensemble de figures gomtriques. Les domaines reprsentent par des valeurs atomiques -c'est--dire considre comme un tout indissociable -les objets dont on parle dans la base. Dans les SGBD relationnels, la notion de domaine est souvent confondue avec celle de type, les seuls domaines supports tant les types de base du systme. La notion de domaine est cependant beaucoup plus riche, car un domaine peut tre dfini en extension (en donnant la liste des valeurs composantes) ou en intention ( partir de contraintes dfinies sur un type). Les relations modlisent les ides qui relient les objets (cods par des valeurs) des domaines entre eux. Le concept de relation est dfini partir de celui de produit cartsien, bien connu en mathmatique; rappelons que le produit cartsien de n domaines D1xD2... Dn est l'ensemble des n-uplets ou tuples <d1 , d2, ...dn> que l'on peut constituer en choisissant des valeurs d1 de D1 , d2 de D2, ..., dn de Dn.

Notion 16 : Relation (Relation) Sous-ensemble du produit cartsien d'une liste de domaines caractrise par un nom. tant dfinie comme un sous-ensemble d'un produit cartsien, une relation est compose de tuples. Une reprsentation des relations sous forme de tables a t retenue dans les SGBD relationnels, si bien que l'on confond relation et table. Chaque ligne correspond un tuple. Chaque colonne correspond un domaine du produit cartsien considr; un mme domaine peut bien sr apparatre plusieurs fois. Afin de pouvoir distinguer les colonnes et de rendre leur ordre sans importance tout en permettant plusieurs colonnes de mme domaine, il est ncessaire d'associer un nom chaque colonne. D'o la notion d'attribut. Notion 17 : Attribut (Attribute) Colonne d'une relation caractrise par un nom. Les rgles d'intgrit sont des assertions qui doivent tre vrifies par les donnes contenues dans une base. Le modle relationnel privilgie deux types de rgles d'intgrit, en plus de celles qui sont associes aux domaines: les contraintes d'entit et les contraintes rfrentielles. Une contrainte d'entit impose l'existence d'une cl documente permettant d'identifier tout tuple d'une relation, dfinie comme suit : Notion 18 : Cl (Key) Groupe d'attributs minimum dont la valeur permet de dterminer un tuple unique dans une relation. Une contrainte rfrentielle spcifie un lien hirarchique entre deux tables, l'une devenant dpendante de l'autre par le biais d'une cl trangre. Notion 19 : Cl trangre (Foreign Key) Groupe d'attributs d'une table dpendante dont toute valeur doit apparatre comme valeur de cl dans la table de rfrence. Une telle contrainte d'intgrit permet en particulier de reprer les associations obligatoires entre entits: par exemple, si toute voiture a au moins un propritaire, la table PROPRIETAIRE pourra possder un attribut NVhicule, cl trangre dans la table VOITURE. En rsum, le modle relationnel est donc trs simple du point de vue modlisation de donnes. Il repose sur les concepts rappels figure 6. Sa simplicit fait sa force, notamment pour le dveloppement d'applications client-serveur.
Relation ou table Attribut ou colonne Domaine ou type Cl Cl trangre

Figure 11 -Les concepts du modle relationnel. Les SGBD relationnels permettent donc de grer des tables peuples de tuples dans la base. Afin de permettre une meilleure indpendance des programmes par rapport aux donnes, ils supportent des tables virtuelles appeles vues. Notion 20 : Vue (View) Table virtuelle manipule par un utilisateur comme une table de la base, mais dont les tuples sont calculs par une question partir d'autres tables. Nous introduisons le concept de vue car il est particulirement important en client-serveur. Une vue approprie gre au niveau d'un serveur apporte l'utilisateur des donnes rpondant directement ses besoins, rduisant ainsi les trafics rseaux et les calculs sur le client. 5.2) Le langage SQL Le langage SQL a t initialement dvelopp par IBM San-Jos dans le cadre du projet System R (comme Relationnel). Tout d'abord appel SEOUEL, il est devenu le standard pour dcrire et manipuler les

bases de donnes relationnelles depuis 1986. A cette date, une premire version fut normalise sous le nom SQL. En 1992, une version tendue appele SQL2 [ISO92] a t accepte comme standard international. Une version trs tendue, appele SQL3 [ISO94], intgrant en particulier un langage de programmation de modules et de procdures, mais aussi le modle objet, est en prparation pour 1997-98. Nous prsentons cidessous succinctement ces trois versions de SQL, appeles SQL 1, SQL2, et SQL3 par le groupe de normalisation nord amricain (ANSI). 5.2.1 SQL 1 : le standard de base SQL 1 a donc t accept comme standard international en 1986. Il a t tendu afin de mieux supporter l'intgrit, notamment l'intgrit rfrentielle, en 1989. Les quatre verbes de base du langage sont SELECT, INSERT, UPDATE et DELETE. Il existe de nombreuses oprations additionnelles afin de dfinir et modifier les schmas des tables, dfinir des contraintes d'intgrit, dfinir des vues, accorder ou retirer des autorisations, grer des transactions atomiques. Plus prcisment, le standard comporte quatre parties : .le langage de dfinition de schmas (Tables, Vues) ; le langage de manipulation (Slection et mises jour, contrles) ; la spcification de modules appelables (Procdures) ; l'intgration aux langages de programmation (Curseurs). Le langage de dfinition de schma comporte deux verbes afin de crer les tables et les vues, CREATE TABLE et CREATE VIEW. Le langage de manipulation se compose des verbes de base SELECT, INSERT, UPDATE, DELETE pour respectivement slectionner, insrer, mettre jour, supprimer des tuples dans une base. Les verbes OPEN, FETCH, et CLOSE permettent l'intgration aux langages de programmation de troisime gnration (Cobol, C, Fortran, etc.); FETCH lit chaque appelle tuple suivant du rsultat d'un SELECT, point par un curseur. Le curseur doit tre pralablement ouvert par la commande OPEN CURSOR. Il est ferm en fin d'utilisation par la commande CLOSE CURSOR. Le langage SQL est enrichi par le langage de contrle qui comporte les verbes GRANT et REVOKE pour attribuer et retirer des droits d'accs aux utilisateurs, BEGIN TRANSACTION, END TRANSACTION, COMMIT, et ROLLBACK pour grer des transactions atomiques. Nous donnons ci-dessous quelques exemples typiques de questions et modifications de tables en SQL 1 sur cette base de donnes. La figure 7 spcifie le schma de la base de donnes exemple. Le lecteur dsirant en savoir plus sur la syntaxe et la smantique de SQL pourra se reporter [Gardarin93].
VITICULTEURS (NVT, NOM, PRNOM, VILLE) VINS (NV, CRU, MILLSIME, DEGR, NVT, PRIX) BUVEURS (NB, NOM, PRNOM, VILLE) ABUS (NV, NB, DATE, QT)

Figure 12- Schma d'une base de donnes exemple. (Q1) Crus des vins sans doubles. SELECT DISTINCT CRU FROM VINS (Q2) Noms des buveurs ayant bu des Beaujolais 87 ou 88. SELECT DISTINCT NOM FROM BUVEURS B, VINS V, ABUS WHERE B.NB = ABUS .NB AND ABUS .NV = V.NV AND CRU LIKE "%BEAUJOLAIS%"AND MILLESIME IN (1987, 1988) Q3 : Noms et prnoms des buveurs de vins dont le cru commence par B, de degr inconnu ou compris entre 11 et 13. SELECT NOM, PRENOM FROM BUVEURS B, VINS V, ABUS A WHERE B.NB = A.NB AND A.NV = V.NV AND CRU LIKE "B%" AND (DEGRE BETWEEN 11 AND 13 OR DEGRE IS NULL)

Q4: Noms des crus bus par au moins un buveur. SELECT DISTINCT CRU FROM VINS V WHERE EXISTS ( SELECT * FROM BUVEURS B, ABUS A WHERE B.NB = A.BNB AND A.NV = V.NV) Q5: Calculer le degr moyen pour chaque cru. SELECT CRU, AVG(DEGRE) FROM VINS GROUP BY CRU Q6 : Calculer le degr moyen et le degr minimum pour tous les crus dont le degr minimum est suprieur 12. SELECT CRU, AVG(DEGRE) , MIN(DEGRE) FROM VINS GROUP BY CRU HAVING MIN (DEGRE) > 12 I1 : Insrer le vin 112 qui est un Julinas de millsime inconnu. INSERT INTO VINS (NV, CRU, MILLESIME) VALUES 112, "JULIENAS", NULL I2: Insrer les viticulteurs de Dijon dans la table BUVEURS. INSERT INTO BUVEURS (NB,NOM,PRENOM) SELECT NVT, NOM, PRENOM FROM VITICULTEURS WHERE VILLE LIRE "%DIJON%"

U1 : Augmenter de 10% les quantits bues de Volnay 90. UPDATE ABUS SET QTE = QTE * 1.1 WHERE ABUS. NV IN SELECT NV FROM VINS WHERE CRU = "VOLNAY" AND MILLESIME = 1990 S1 : Supprimer tous les abus de vins de degr inconnu. DELETE FROM ABUS WHERE NV IN SELECT NV FROM VINS WHERE DEGRE IS NULL Le langage SQL 1 a t tendu en 1989 par un addendum proposant une syntaxe pour exprimer les contraintes d'intgrit. Ce document de 40 pages fusionn avec le langage de 86 [ISO89] propose la possibilit de spcifier des valeurs par dfaut comme le prix dans la commande C1 ci-dessous. L'extension propose de plus le support des contraintes de domaines avec la clause BETWEEN permettant de spcifier une plage ou une liste de valeurs, comme pour le degr dans la commande C1 ci-dessous. Enfin, l'extension propose une syntaxe pour dfinir des contraintes rfrentielles. Celle-ci est base sur le mot cl REFERENCES qui permet d'indiquer qu'un attribut (ou un groupe d'attributs) rfrence la cl primaire (PRIMARY KEY) d'une table, comme pour l'attribut NVT (Numro de VITICULTEURS) dans la table VINS cre par la commande C1. C1 : Crer la table VINS avec intgrit rfrentiel et valeur par dfaut. CREATE TABLE VINS (NV INT PRIMARY KEY, CRU CHAR(10) , ANNEE INT ,

DEGRE FIXED (5,2) CHECK BETWEEN 10 AND 15, NVT INT REFERENCES VITICULTEURS , PRIX FIXED(7,2) DEFAULT 40 )

5.2.2 SQL2 : le nouveau standard Depuis 1992, un nouveau standard a t accept; il est appel SQL2. Il s'agit d'une extension compatible de SQL 1. Afin de faciliter les choix d'implmentation, trois niveaux embots, du simple au complexe, sont distingus : SQL2 entr (Entry SQL2), qui reprend SQL 1-89 et ajoute quelques fonctionnalits manquantes ; SQL2 intermdiaire (Intermediate SQL2), qui complte trs utilement le langage d'un point de vue des fondements relationnels, et aussi des types de donnes ; SQL2 complet (Full SQL2), qui comporte l'ensemble des spcifications SQL2.

5.2.2.1 SQL2 entr

SQL2 entr complte SQL 1 en proposant en particulier une standardisation des codes rponses l'aide d'un nouvel tat rcupr en rponse aux requtes, appel SQLCODE. Des classes et valeurs de SQLCODE sont proposes afin de coder les rponses. Ceci est important pour assurer la portabilit des programmes utilisateurs. Des manquements de SQL 1 sont aussi corrigs, tels par exemple la possibilit de donner un nom une colonne d'une table rsultat, ou la possibilit d'utiliser un mot cl rserv (par exemple, SELECT) pour nommer une table ou une colonne. En rsum, SQL2 entr n'apporte que quelques amliorations SQL 1, si bien que les constructeurs ont pu passer facilement de SQL 1-89 SQL2 entr. 5.2.2.2 SQL2 intermdiaire

Au contraire, SQL2 intermdiaire apporte de nombreuses fonctionnalits nouvelles. Le concept de mtabase est notamment intgr au langage. Notion 21 : Mtabase (Information Schema) Base de donnes contenant la description des caractristiques des autres bases de donnes. La mtabase contient donc les schmas des bases de donnes gres par le SGBD. Une mtabase normalise est propose en SQL2 avec des tables dcrivant les tables, les colonnes, les types de donnes, les domaines, les vues, les utilisateurs, etc. Ceci est important pour rendre portable les outils utilisant la description des tables, par exemple les outils de formulation de requtes et d'exploitation des rsultats sur un poste client. SQL2 intermdiaire permet aussi de distinguer la prparation des requtes avec paramtres de l'excution des requtes avec instanciation des paramtres (SQL dynamique). Ceci est important pour le client-serveur, car il faut viter de prparer une requte (donc de l'analyser et la compiler) chaque demande d'excution par un poste client. SQL2 intermdiaire apporte aussi l'utilisateur la possibilit de crer des domaines par une commande nouvelle CREATE DOMAIN. Par exemple, la commande suivante cre un domaine MONNAIE, qui pourra tre utilis pour spcifier le type d'une colonne : CREATE DOMAIN MONNAIE IS DECIMAL ( 5 , 2 ) DEFAULT (-1) CHECK (VALUE = -1 OR VALUE > 0) NOT NULL . Au-del de la mtabase, du SQL dynamique et des domaines, SQL2 intermdiaire apporte les fonctionnalits importantes suivantes : le types de donnes date (par exemple 18-07-95), temps (par exemple 11H44M22S) et estampille (la concatnation d'une date et d'un temps en millisecondes), avec des oprations associes pour les additions, diffrences, et comparaisons de dates, temps et estampilles ;

 un meilleur support de l'intgrit rfrentielle avec possibilit lors d'une suppression d'un tuple rfrenc de cascader la suppression en supprimant les tuples rfrenant, ou de rendre nul l'attribut rfrenant ; le support des jointures externes, qui permettent de conserver lors d'une jointure les tuples sans correspondant de la table droite, gauche, ou des deux tables, avec des valeurs nulles pour les attributs de l'autre table ; le support des expressions de SELECT; des blocs SELECT peuvent dornavant tre composs par les oprateurs d'union externe ([OUTER] UNION) -il s'agit de l'union qui existe dj en SQL 1, mais sur des tables pouvant comporter des attributs diffrents, qui sont alors supposs nuls -, d'intersection (INTERSECT) et de diffrence (EXCEPT). 5.2.2.3 SQL2 complet

SQL2 propose des extensions SQL2 intermdiaire. A noter que les spcifications de SQL2 constituent un document de 500 pages environ. Ce document spcifie tout SQL2 complet, et prcise en annexe ce qui est de niveau entr, intermdiaire, ou complet. On trouve en particulier dans SQL2 complet un support plus pouss des dates et du temps (avec notamment les intervalles de temps), des expressions d'union de blocs SELECT tendues avec correspondances de colonnes, et la possibilit de spcifier des contraintes d'intgrit avec calculs d'agrgats portant sur plusieurs tables. Au-del, SQL2 complet offre la possibilit de dfinir des vues concrtes, c'est--dire dont l'instance est matrialise comme une table sur disque. Il permet aussi de diffrer les contraintes d'intgrit en fin de transactions, ce qui rend possible des optimisations et des passages par des tats intermdiaires non forcment cohrents de la base en cours de mise jour par une transaction. 5.2.3 SQL3 : Le standard du futur SQL3 est une nouvelle extension du standard en prparation pour 97 -98. SQL3 comporte des composants multiples autour d'une base qui intgre les spcifications gnrales. Ces composants permettent de supporter les concepts dfinis ci-dessous. Notion 22 : Interface client (Client interface) Ensemble de fonctions permettant d'envoyer des requtes et de rcuprer les rsultats depuis un processus client vers un serveur SQL. L'interface client est la premire brique du middleware que nous dtaillons dans la section suivante. Le groupe de normalisation se propose de dfinir un standard ce niveau, trs inspir des recommandations du SQL Access Group (SAG). Nous tudierons ces recommandations au chapitre suivant. SQL3, comme la plupart des serveurs relationnels, permet de grer des procdures stockes sur le serveur, et d'en demander l'excution depuis un client. Le serveur devient ainsi un serveur de donnes et procdures, les procdures tant connues au niveau de la base. Notion 23: Procdures stockes (Stored Procedure) Procdure dont la dfinition est stocke dans la base de donnes, excute par le serveur, qui permet de calculer des paramtres de sortie partir de paramtres d'entre et du contenu de la base de donnes. SQL3 propose son propre langage de programmation de procdures. Ce langage comporte des ordres de dclaration de variables, d'assignation, de tests de conditions (CASE, IF), de boucles (LOOP, FOR), de gestion d'erreurs (SIGNAL, RESIGNAL). Il permet aussi d'appeler des procdures et fonctions externes, crites dans un langage traditionnel tel que C. Il s'agit d'un vritable L4G qui peut servir de base au dveloppement d'outils. Au-del des procdures, SQL3 intgre un composant de dfinition et manipulation d'objets. Un objet en SQL3 est dfini comme suit. Notion 24 : Objet SQL(SQL Object) Groupe de donnes structur, manipul par des oprations spcifies lors de la dfinition du type de l'objet et identifi par un identifiant immuable.

Avec SQL3, le groupe de donnes sera gnralement un tuple, mais chaque attribut pourra tre multi-valu. Chaque objet un type. Les oprations qui encapsulent les donnes seront dfinies au niveau du type. Leurs implmentations seront spcifies comme des procdures stockes. Une nouvelle commande est introduite afin de dfinir des types d'objets, mais aussi des types de valeurs complexes : CREATE { VALUE | OBJECT } TYPE . Un type comprend des attributs et des oprations. Certains attributs peuvent tre privs: ils sont alors accds par des oprations qui les manipulent. Tout objet d'un type OBJECT est identifi par un identifiant appel OID. Une table peut possder des attributs d'un type abstrait. Un tuple contient des rfrences des objets (OID) ou des valeurs complexes. SQL3 permet de rutiliser un type en dfinissant un sous-type. Un sous-type hrite des attributs et des oprations de ses sur-types. Par exemple, on peut crer un type Personne avec un sous-type Etudiant l'aide des commandes suivantes : CREATE TYPE Personne (nss int, nom varchar) ; CREATE TYPE Etudiant UNDER Personne (Option VARCHAR, Anne INT) . Un type peut avoir plusieurs sur-types. De plus, afin de grer les attributs multi-valus, SQL3 propose des types paramtrs rutilisables : ensemble (SET<T> ), multi-ensemble (MULTISET<T, et liste (LIST<T. En rsum, la proposition SQL3 est assez complte du point de vue du support des objets. Elle est cependant loin d'tre finalise, et devrait bnficier des apports de la contribution concurrente de l'ODMG [CateI193]. SQL3 intgre en plus des possibilits de rcursion afin de parcourir par exemple des relations reprsentant des graphes. Pour l'instant, SQL3 propose une syntaxe fort complexe pour exprimer les questions rcursives.

Notion 25: Question rcursive (Recursive Query) Question permettant d'effectuer des boucles de jointures rcursivement sur une table, afin de parcourir des hirarchies de type composants-composs. Enfin, un des derniers aspects trs importants de SQL3 pour le client-serveur, est la possibilit de dfinir des dclencheurs (parfois appels rflexes) au niveau du schma des bases. Notion 26 : Dclencheur (Trigger) Action sur la base de donnes excuter suite l'apparition d'un vnement particulier, ventuellement lorsqu'une condition est vrifie par certains tuples de la base. Un dclencheur comporte donc un vnement, une action, et une ventuelle condition. L'vnement spcifie la condition d'excution; avec SQL, l'vnement est une mise jour sur une table, donc une commande INSERT, UPDATE, OU DELETE. L'action peut tre dclenche avant ou aprs l'vnement. L'action est une opration sur une table (INSERT, UPDATE, DELETE) ou une procdure stocke. La condition est un prdicat SQL; elle peut rfrencer les valeurs avant ou aprs mise jour. Afin d'illustrer cette fonctionnalit majeure intgre dans la plupart des serveurs, nous dfinissons un dclencheur sur une table dcrivant des employs pour grer les cumuls d'augmentation. La base comporte les deux tables dfinies figure 8. EMPLOY (ID int, salaire float) CUMUL (ID int, Augmentation float) Figure 13 -La base des employs avec cumuls d'augmentation. La commande permettant de grer automatiquement les cumuls s'exprime comme indiqu ci-dessous. T1 : Crer un dclencheur grant le cumul des augmentations d'un employ.

CREATE TRIGGER AFTER UPDATE OF salaire ON employ REFERENCING OLD AS ancien-salaire, NEW AS nouveau-salaire UPDATE CUMUL SET Augmentation=Augmentation+nouveau-salaire- ancien-salaire WHERE ID = employ.ID

5.3) SQL: Bilan et conclusion SQL est un standard de plus en plus complet et de plus en plus suivi. Tout les aspects des bases de donnes sont pris en compte dans les propositions SQL2 ou SQL3. La norme constitue une rfrence pour implmenter et utiliser chaque aspect des serveurs de bases de donnes. De plus (et c'est essentiel pour le client-serveur) SQL est le langage de manipulation de donnes utiliss par tous les client pour accder aux serveurs de donnes. En consquence, il est la base de la plupart des outils de middleware, qui sont construits partir des propositions normatives du SQL Access Group. Une question se pose cependant pour le futur de SQL et du client-serveur : SQL russira-t-il bien intgrer l'objet ? On peut tre optimiste au vu des derniers dveloppements de SQL3. X. LES MEDIATEURS OU MIDDLEWARE

Bas sur les techniques de communication client-serveur vues ci-dessus, le middleware assure les connexions entre les serveurs de donnes et les outils de dveloppement sur les postes clients. Cette couche de logiciels trs spcifique du client-serveur cache les rseaux et les mcanismes de communication associs. Elle assure une collaboration fructueuse entre clients et serveurs. Middleware n'ayant pas de traduction directe en franais, nous introduiront le concept de mdiateur qui correspond un middleware particulier. 6.1) Dfinition et Objectifs Notion 27 :Mdiateur (Middleware) 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. L'objectif d'un mdiateur est donc d'assurer une liaison transparente, c'est--dire de cacher l'htrognit des composants mis en jeu. Il s'agit en particulier d'assurer la transparence aux rseaux, aux SGBD, et dans une certaine mesure aux langages d'accs. 6.1.1 Transparence aux rseaux Tous les types de rseaux doivent tre supports, qu'ils soient locaux ou nationaux, voire internationaux. Un mdiateur sera construit au dessus de la couche transport du modle OS1 (voir figure 9). Celle-ci pourra tre de type TCP/IP, SNA LU 6.2, DecNet, LAN Manager, etc. Elle pourra permettre l'tablissement de sessions et l'change de messages au travers de la session, ou plus simplement l'envoi de datagrammes isols. Quoiqu'il en soit, le mdiateur cachera l'htrognit des rseaux et protocoles de transports utiliss en offrant une interface standard de dialogue l'application. Couche application Couche prsentation Couche session Couche transport Couche rseau Couche liaison Couche physique
FTAM, X400, X500, Terminal Virtuel ISO 8823, XDR,ASN.1 ISO 8327 ISO 8073, TCP, LU 6.2 ISO 8473, IP, X.25 ISO 8802, ISO 7776, HDLC, CSMA/CD ISO 8802, X.21

Figure 14- Les sept couches du modle 081 de 1'180 et les protocoles associs. 6.1.2 Transparence aux serveurs Les SGBD mis en CEuvre peuvent tre trs divers, bien que gnralement relationnels tels Oracle, Sybase, Informix, DB2, ou Ingres. Ils offrent cependant des moyens de connexions varis, et des dialectes SQL souvent diffrents. Un bon mdiateur se doit donc l encore de cacher la diversit et d'uniformiser le langage SQL en s'appuyant le plus possible sur les standards. 6.1.3 Transparence aux langages Un mdiateur doit permettre l'intgration des fonctions de connexion aux serveurs, d'mission de requtes et de rception de rponse dans tout langage de dveloppement utilis ct client. Les fonctions appeles doivent tre aussi indpendantes que possible du langage. D'autre part, le mdiateur doit assurer les conversions des types de donnes en provenance du serveur dans des types du langage de dveloppement, et rciproquement pour le passage de paramtres. Plus gnralement, le mdiateur doit rsoudre les problmes de mode de travail diffrents, dits d'opposition de phases, qui peuvent survenir entre le langage, souvent squentiel, et le serveur, souvent ensembliste. 6.2) Fonctions d'un Mdiateur Lorsqu'un logiciel client veut consulter ou modifier des donnes sur le serveur, il doit d'abord se connecter. Notion 28: Procdure de connexion (Connection procedure} Opration permettant d'ouvrir un chemin depuis un client vers un serveur dsign par un nom, avec authentification de l'utilisateur associ par nom et mot de passe. La connexion permet de retrouver le serveur et si ncessaire d'ouvrir une session de communication avec lui. L'utilisateur est authentifi (son nom et son mot de passe sont vrifis). Un processus permettant la prise en compte de ses requtes (qui doivent normalement suivre) est dclench sur le serveur, s'il n'est pas dj actif. Dans un contexte serveur de bases de donnes, aprs ou pendant la connexion, il est ncessaire d'identifier la base particulire sur laquelle l'utilisateur va travailler. Gnralement, le nom de la base est celui de l'utilisateur, si bien qu'aucune procdure d'ouverture spcifique n'est ncessaire. Aprs la connexion, l'utilisateur peut directement prparer ou faire excuter des requtes. Notion 29 : Prparation de requte (Request preparation) Opration consistant envoyer une requte avec des paramtres non instancis un serveur afin qu'il prpare son excution. Notion 30: Excution de requte (Request execution) Opration consistant envoyer une demande d'excution de requte prcdemment prpare un serveur, en fournissant les valeurs des paramtres. Dans la plupart des systmes client-serveur, il est efficace de distinguer prparation et excution de requtes. En effet, la prparation dclenche souvent une compilation de la requte qui gnre un plan d'excution paramtr sur le serveur. Lors de la demande d'excution, les paramtres sont instancis et le plan est excut sans recompilation. Pour une seule prparation, il est possible de demander de multiples excutions, ce qui sauve le temps de compilation chaque fois. Cependant, dans des contextes de requtes ad hoc excutes une seule fois, il pourra tre plus efficace de demander la fois la prparation et l'excution de la requte. Une requte gnre en gnral un rsultat. On distingue les rponses immdiates constitues par les paramtres de sortie ventuelles de la requte, incluant en particulier un code erreur, et les rsultats (ou rponses diffres), qui sont gnralement des donnes gnres par la requte sur le serveur pour le client et qu'il faut rapatrier par des commandes spcifiques. Notion 31 : Rcupration de rsultats (Result fetching) Opration permettant de ramener tout ou partie du rsultat d'une requte sur le client. Dans un contexte bases de donnes, les rsultats peuvent tre volumineux. Par exemple, suite une recherche dans une table, plusieurs lignes peuvent tre retrouves. Dans le cas de gestion d'objets binaires

longs (BLOB), les rsultats peuvent tre composs de plusieurs giga-octets. Il faut alors les rcuprer par partie, en les divisant en blocs physiques changs avec efficacit entre le client et le serveur. D'o la ncessit de mettre en place des techniques sophistiques de gestion de caches. Notion 32 : Cache de rsultats (Result caching) Technique permettant de transfrer les rsultats par blocs et de les conserver sur le client ou/et sur le serveur afin de les rutiliser pour rpondre des requtes. Au-del des rsultats, les mdiateurs peuvent aussi mmoriser les requtes avec les plans d'excution prpars sur le serveur, ceci afin d'viter de les prparer nouveau lors d'une nouvelle demande. Notion 33: Cache de requtes (Request caching) Technique permettant de conserver des requtes compiles sur le serveur afin de les rutiliser pour rpondre des requtes similaires. Les requtes et les plans d'excution associs peuvent tre mmoriss simplement en mmoire: ils sont alors perdus la fin de la session de travail. De manire plus sophistique, les plans peuvent tre stocks dans la base ou dans un fichier, et rcuprs lors de la connexion. Ceci permet alors des optimisations importantes. Quoiqu'il en soit, une session de travail se termine toujours par une dconnexion qui permet de relcher les ressources occupes sur le serveur. Notion 34 : Procdure de dconnexion (Deconnection procedure) Opration inverse de la connexion, permettant de fermer le chemin ouvert depuis le client vers le serveur associ. 6.3) Architecture Type La figure 15 illustre l'architecture type d'un mdiateur. L'application dialogue avec un module de connectabilit qui gre l'interface utilisateur (API). Celui-ci reoit les appels de fonctions et les transmet sous forme interne au module de formatage et d'accs (FAP) qui gre le protocole d'change (Format and Access Protocol). Ce dernier transforme les appels en messages conformment au protocole d'accs aux donnes distantes. Il assemble aussi les paramtres dans un format d'change. Le module FAP symtrique sur le serveur reoit les messages et les dsassemble pour les transmettre en format interne l'adaptateur. Ce dernier module transforme les requtes dans le format interne compris par le SGBD. Les rponses suivent un chemin symtrique en sens inverse. Selon les constructeurs du SGBD et du mdiateur, on peut distinguer diffrents types de mdiateurs comme indiqu figure 16. Les mdiateurs propritaires sont construits par le fabriquant du SGBD. Les mdiateurs diteurs sont essentiellement des interfaces applicatives d'mission de requtes et rception de rsultats. Ils s'appuient sur les protocoles d'accs et les formats des constructeurs de SGBD. Ils assurent que les outils fournis par l'diteur sont indpendants du SGBD. Les mdiateurs indpendants sont fournis par un constructeur spcialis, diffrent de celui du SGBD et des outils. Leurs avantages rsident dans l'indpendance qu'ils offrent la fois par rapport au SGBD et aux outils de dveloppement choisis.

Figure 15 - Architecture type d'un mdiateur.

Figure 16 - Diffrents types de mdiateurs. LES CLASSES D'OUTILS DE DEVELOPPEMENT Comme indiqu figure 12, il existe diffrentes classes d'outils de dveloppement utilisables sur le poste client. Les outils s'adressent des utilisateurs plus ou moins chevronns. Ils peuvent tre personnels, ou utilisables en coopration par tous les acteurs de l'entreprise. On a donc l une grande diversit. Les outils de bureautique permettent la gestion de textes, de tableurs, et plus gnralement de documents. Ils s'adressent des utilisateurs souvent dbutants en informatique, mais peuvent bien sr tre utiliss par tous. Au-del, nous distinguerons les SGBD pour micros, les langages de programmation natifs (tels Cet Cobol) ou objets (tels C++ et Smalltalk), les L4G, les AGL, et les outils de conception. Les distinctions entre ces classes dont nous tudions ci-dessous les principes ne sont pas toujours videntes.

Figure 17 - Les classes d'outils clients. Les SGBD micros Les SGBD micros sont pour la plupart bass sur le modle relationnel et le langage SOL. Ils se distinguent des serveurs par leur fonctionnement mono-usager et une interface graphique intgre. L'interface permet facilement de crer une base de donnes avec les tables composantes, de saisir et mettre jour les donnes partir de formulaires, de crer et diter des requtes l'aide d'une interface visuelle, d'excuter les requtes et de parcou rir les rsultats, d'imprimer des tats. Ils s'intgrent au client-serveur par la possibilit d'accder des bases de donnes et des tables externes. L'accs peut tre explicite -l'utilisateur doit mentionner la base distante et mettre ses requtes SOL partir de l'diteur de requtes local -ou implicite -le SGBD se charge alors de dcomposer les requtes en sousrequtes traites localement ou expdies au SGBD distant -.Nous tudierons quelques uns de ces outils de

plus en plus complets, qui s'intgrent souvent dans l'environnement bureautique, au chapitre prsentant les produits SGBD. 7.2 Le dveloppement et l'orientation objet Au-del des SGBD adapts la gestion, les outils de dveloppement deviennent de plus en plus orients objets. En effet, l'orientation objet facilite l'analyse et la programmation. L'analyse est facilite car le modle objet permet une modlisation directe des objets rels du monde rel, le suivi de leur cycle de vie depuis leur cration leur disparition, la cration de modles plus compacts grce aux facilits de rutilisation. Des outils graphiques riches permettent de visualiser directement le modle de l'application. La programmation est facilite car l'orientation objet permet la gnration de squelettes des modules applicatifs partir du modle graphique rsultant de l'analyse, la rutilisation de composants existants, le prototypage rapide permettant de visualiser des scnarios de fonctionnement. Au-del du concept d'objet introduit ci-dessus, quels sont les concepts essentiels de l'approche objet ? Nous les rappelons ci-dessous. Le lecteur dsirant en savoir plus pourra se reporter [Bouzeghoub94]. L'approche objet est caractrise par une notion centrale, celle d'objet. Un objet associe donnes et traitements dans une mme entit en ne laissant visible que l'interface de l'objet, c'est--dire les oprations que l'on peut effectuer dessus. Les objets sont adresss par des identifiants attribus la cration, qui ne changent pas durant la vie de l'objet. Notion 35 : Objet (Object) Entit distinguable du monde rel caractrise par une identit unique et invariante, un tat reprsent par des valeurs simples ou structures, et un comportement reprsent par des verbes avec paramtres permettant d'agir dessus. Notion 36 : Identifiant d'objet (Object Identifier) Proprit immuable d'un objet permettant de le distinguer des autres et de retrouver son tat et son comportement. Un objet comporte un aspect statique reprsentant son tat l'aide de variables d'instances, encore appeles attributs. 'Notion 37 : Attribut d'objet (Object Attribute) Variable d'tat d'un objet permettant de mmoriser une valeur simple ou complexe, ou un ou plusieurs identifiants d'autres objets. Cet aspect statique est cach par un aspect dynamique reprsentant le comportement de l'objet. Ce dernier correspond aux oprations que l'on peut faire sur un objet. Notion 38: Opration d'objet (Object Operation) Action excutable sur un objet qui permet de modifier son tat et/ou de calculer une valeur partir de celui-ci. Il n'est gure possible de penser un objet sans penser son type qui permet de dfinir son comportement, et ventuellement ses attributs. Notion 39: Type d'objet (Object Type) Abstraction d'objets similaires par une interface offerte aux utilisateurs en termes d'oprations et d'attributs visibles. Un type est abstrait s'il ne comporte que des oprations: on ralise alors l'encapsulation totale des donnes. C'est au niveau du type que l'on spcifie les signatures des oprations (c'est--dire les en-ttes d'oprations) que l'on peut effectuer sur un objet qui est donc une instance du type. La notion de classe est beaucoup plus tourne vers l'implmentation, bien que plusieurs choses soient souvent distinguer au niveau de la classe. Notion 40 : Classe d'objet (Object Class) Implmentation d'un type de donne caractrise par des attributs et oprations communs aux objets associs. On peut distinguer: l'en-tte d'une classe qui correspond une spcification concrte des attributs et oprations; l'implmentation d'une classe qui correspond au code des mthodes; l'extension d'une classe qui correspond la liste des objets existants de la classe. Dans beaucoup d'environnements objets, la notion

de type est confondue avec celle d'en-tte de classe, comme historiquement dans Simula. Cependant, une classe est une implmentation d'un type: au-del des attributs, elle permet de spcifier les mthodes. Les types d'objets ou les classes sont gnralement organiss en hirarchies de spcialisation, allant du gnral au particulier. L'inverse d'une spcialisation est une gnralisation : elle permet de spcifier qu'un objet est plus gnral qu'un autre. Un spcifique hrite en gnral des proprits de l'objet dont il drive. Notion 41 : Hritage (Inheritance) Mcanisme de transmission automatique des proprits d'un type ou d'une classe vers un sous-type ou une sous-classe. Il est possible de distinguer l'hritage de type, o seules les signatures d'oprations sont hrites (et parfois les attributs vus comme des oprations), de l'hritage de classe o les implmentations (attributs et mthodes) sont aussi hrites. Les oprations sur objets sont actives grce des messages (ou requtes) envoys aux objets. Notion 42 : Message objet (Object Message) Bloc de donnes, compos d'un nom d'opration (appel slecteur) et de paramtres, envoy un objet (appel rcepteur) afin d'activer une mthode. L'implmentation d'une opration (parfois appele mthode) est retrouve grce au nom de l'opration qui figure dans le message (le slecteur), mais aussi grce au type de l'objet rcepteur, et parfois des paramtres. Ceci permet d'associer des codes diffrents une opration . Notion 43 : Polymorphisme (Polymorphism) Possibilit d'associer plusieurs codes une mme opration, le choix du code tant effectu en fonction du type des paramtres. Le polymorphisme est souvent utilis dans les hirarchies de classes, o il est possible de surcharger une opration dfinie dans une classe au niveau des sous-classes. C'est une fonctionnalit essentielle des systmes objet, car elle permet de raliser des fonctions diffrentes par une mme abstraction. 7.3) Les langages de programmation objet Les langages de programmation orients objets constituent des outils de plus en plus riches pour dvelopper en client-serveur. Construit partir d'une extension objet de C, C++ apporte un modle de classe d'objets trs complet. Les oprations qui encapsulent les objets sont appeles fonctions membres; elles sont crites en langage C enrichi avec quelques constructions pour les objets. Plusieurs environnements trs riches, notamment Visual C++ de Microsoft introduit ci-dessous, sont disponibles. Langage pur objet, Smalltalk est trs adapt au dveloppement d'interfaces graphiques. Il gnralise l'envoi de messages des objets instances de classes dont les dfinitions sont elles-mmes les objets de mtaclasses. De nombreux environnements sont disponibles, dont VisualAge d'IBM et les produits de Digitalk. 7.3.1 Un exemple: Visual G++ Visual G++ de Microsoft est un environnement adapt pour Windows et pour le dveloppement clientserveur. L'environnement se compose des lments dcrits ci-dessous. 1. L'atelier visuel (Visua/ Workbench). Cet ensemble comprend un diteur de texte syntaxique en couleur, un visualisateur graphique, un compilateur, un diteur de liens, un dbaugueur, un assembleur de modules, et un aide en ligne. 2. La librairie des classes de base (Foundation C/ass Library). Elle fournit des classes de base encapsulant les interfaces de Windows et Windows NT. De plus, elle fournit une intgration OLE 2, le systme de gestion de documents composites de Microsoft, et ODBC, le mdiateur bases de donnes de Microsoft. C'est un lment essentiel pour les dveloppements client-serveur qui fournit donc des API pour dialoguer avec des serveurs de documents ou de bases de donnes. 3. L'diteur de ressources App Studio (App Studio Resource Editor). Il permet d'diter l'apparence et le comportement des objets graphiques. 4. La librairie d'excution (Run- Time Library). Cette librairie fournit un ensemble de fonctions accessibles l'excution en C ou C++ pour grer les entres-sorties, l'allocation de mmoire, les formules mathmatiques, le contrle de processus, les graphiques, etc. Elle comporte plus de 550 fonctions.

5. Les exemples et aides en lignes (Sample Source Code et Online Help Files). Il s'agit de programmes exemples et d'aides en lignes, notamment pour l'accs aux serveurs via ODBC ou OLE 2. En plus des lments ci-dessus fournit avec la version 1.5 (pour Windows) et 2 (pour Windows NT) de Visual C++, de nombreux outils sont disponibles sur le march, notamment pour construire des bases de donnes sur le serveur, extraire et analyser des donnes depuis un serveur, grer des objets multimdia (images, graphiques 2D et 3D), supporter des interfaces graphiques sophistiqus (par exemple, avec Views de Ilog), gnrer des rapports, rutiliser des composants dvelopps avec Visual Basic, etc. En rsum, Visual C++ est un outil trs riche pour dvelopper des applications client-serveur. Il est cependant destin des professionnels, de par la complexit du langage C++ proche de la programmation systme. 7.3.2 Un autre exemple: VisualAge d'IBM VisualAge est un outil de programmation visuel orient objet bas sur le langage Smalltalk. Il existe une version personnelle et une version en quipe qui permet de partager et de rutiliser les objets dvelopps. La constitution d'une application consiste assembler dans des fentres l'cran des composants prdfinis. Quand de nouveaux composants sont ncessaires, ils peuvent tre crits dans le langage Smalltalk. Les composants offerts dans VisualAge sont des composants d'interfaces graphiques (grilles, menus, boutons, ascenseurs, etc.) pour Posix, X-Windows et OSF-Motif, l'accs aux bases de donnes, le support d'objets multimdia et des changes dynamiques avec les autres applications (DDE). Au-del des interfaces, VisualAge permet de dvelopper de vritables transactions sur des bases de donnes DB2. Des modules optionnels permettent des liens avec des programmes crits en C ou Cobol, et avec les bases de donnes Oracle ou Sybase. En rsum, VisualAge est un outil construit autour du langage pur objet Smalltalk disponible sur OS/2 et Windows destin aux professionnels du dveloppement client-serveur qui comporte un ensemble de composants prdfinis pour le graphique et l'interconnexion aux serveurs de donnes. Il permet de rutiliser des parties d'applications crites en C ou Cobol. Une version C++ est aussi disponible sur OS/2. 7.4) Les langages de 4e gnration (L4G) Les langages de 4e gnration (L4G) se sont dvelopps partir des architectures d'infocentre, pour traiter et analyser les donnes extraites des bases. Un L4G (4GL en anglais) est un langage spcifique spcialis dans le traitement des donnes intgrant la fois un accs type SOL aux tables, des facilits de contrle, d'affichage, de saisie interactive, et d'dition de rapports. Un L4G est donc indpendant de tout langage natif, type C, Cobol, ou Pascal. Il dispose d'une interface graphique pour composer et diter des fentres d'crans et pour dialoguer avec l'utilisateur. L'interface graphique est aussi utilise pour gnrer des rapports partir notamment des tables relationnelles. Au cur du L4G, un langage de programmation vnementiel permet de dfinir des procdures dclenches suite un vnement, par exemple la slection d'une commande dans un menu. Les constructions du langage supportent la dclaration de variables, les calculs et assignations, les tests du type IF et CASE, les boucles LOOP et FOR EACH, le traitement des erreurs et des exceptions par des ordres du type SIGNAL. Un L4G permet aussi la construction de procdures et l'appel de fonctions externes. De plus en plus souvent, il est orient objet, de sorte permettre la rutilisation de classes, au moins au niveau de l'interface graphique. A partir des programmes vnementiels, un gnrateur de code produit un code cible, qui peut dans les L4G de deuxime gnration, tre partitionn entre client et serveur. Le code cible est souvent du Cou, dans les produits anciens, du Cobol. Ce peut tre aussi un langage intermdiaire excut par un interprteur.

Figure 18 Les fonctions essentielles d'un L4G. En rsum la figure 18 montre les composants typiques d'un L4G. En plus des caractristiques indiques ci-dessus, les L4G offrent de plus en plus souvent : la possibilit de construire des objets par rutilisation et spcialisation d'autres objets; des librairies de classes rutilisables, en particulier des interfaces avec des logiciels graphiques tels Windows, Motif ; des fonctions de service pour effectuer l'accs aux bases de donnes et aux fichiers en assurant la transparence des sources de donnes ; une programmation vnementielle permettant de dclencher des fonctions suite des vnements, tels un clic souris ou la mise jour d'une variable. Nous tudierons plus en dtails les L4G au chapitre consacr aux outils. 7.5) Les ateliers de gnie logiciel (AGL) Les ateliers de gnie logiciel (AGL) reprennent les fonctions des L4G, mais au-del ils grent un rfrentiel des objets de l'application. Le rfrentiel est le dpositaire du modle de l'application. Ceci inclut les schmas de donnes, les dfinitions des signatures et du code des oprations, les dfinitions de fentres et de rgles de gestion, voire les enchanements d'activits. Le rfrentiel est la plaque tournante au centre des dveloppements et des volutions de l'application. Il peut tre partag entre les diffrents dveloppeurs et des versions prives peuvent tre extraites pour des dveloppements nouveaux. Un module essentiel d'un L4G est l'diteur de modles. A partir d'un modle fonctionnel des activits (dialogues, fentres, procdures de calculs, accs aux donnes, etc.), le concepteur est appel dfinir les objets de l'application. Ces dfinitions sont mmorises dans le rfrentiel. Elles sont mises jour au fur et mesure des changements; des versions peuvent tre gres. De plus en plus souvent, l'diteur du modle s'appuie sur un graphe des classes de l'application, allant du gnral au particulier. Il peut intgrer un outil mthodologique afin de faciliter l'laboration du modle des objets de l'application. A partir du rfrentiel, des outils de dveloppement rapide (RAD) facilitent la gnration des fentres de dialogue (par exemple pour la saisie des objets des bases de donnes) et les enchanement de modules sous contrle de dialogues avec l'utilisateur. Les outils de programmation vnementielle permettent d'ajouter le corps des modules afin de complter les activits. Une caractristique importante des AGL de deuxime gnration est de permettre un dploiement de l'application sur des architectures varis, par exemple en fournissant des outils d'assignation de pilotes aux tables support de donnes et aux priphriques. Les modules de l'application peuvent alors tre partition ns automatiquement ou sous contrle d'un administrateur. C'est le rle suppos du configurateur reprsent figure 19. Celui-ci peut d'ailleurs tre intgr au gnrateur de code. Finalement, les AGL essaient de suivre le plus compltement possible le cycle de vie des applications. C'est pourquoi ils intgrent en gnral des outils de maintenance et d'assistance l'exploitation. L'essentiel des composants d'un AGL type est reprsent figure 19.

Figure 19 - Les fonctions essentielles d'un AGL.

XI.

RESUME ET PERSPECTIVES

Dans ce chapitre, nous avons dfini le client-serveur comme un mode de dialogue entre processus, le processus client demandant au processus serveur l'excution de services par l'intermdiaire de requtes transportes par des messages. Un cas particulier intressant est le client-serveur de donnes et procdures. Une architecture de rfrence pour ce type de client-serveur trs en vogue dans l'industrie a t dfinie. Elle se compose d'un SGBD relationnel tendu, d'un mdiateur permettant l'change efficace et robuste de requtes et de rponses, et d'un outil client. L'outil client peut tre un langage de programmation de 3e gnration ou orient objet, un L4G ou un AGL. Un AGL se diffrencie d'un L4G par le fait qu'il gre un rfrentiel contenant le modle des objets de l'application. Autour du rfrentiel s'articule des outils de dveloppement et de dploiement. Le client-serveur de donnes et procdures volue grande vitesse sous les effets conjugus des besoins des applications, de l'accroissement de puissance des calculateurs, et des efforts des vendeurs de produits pour conqurir le march. Le client-serveur facilite la construction des applications en assemblant les pavs serveurs, mdiateurs et clients. Au-del de l'assemblage de pavs complexes, l'objectif devient la capacit des architectures permettre l'assemblage de composants rduits prfabriqus. Il s'agit de gnraliser la dmarche de jeu de cubes des systmes client-serveur aux applications afin de permettre de les construire partir de composants prexistants, en les assemblant sur un rseau. A cet effet, l'approche objet se gnralise au niveau des outils de dveloppement pour faciliter la rutilisation, l'enrichissement et l'assemblage de classes. Quelques problmes difficiles apparaissent, comme la ncessit d'assurer la compatibilit des classes au niveau du binaire pour viter les recompilations fastidieuses et permettre la vente de binaires. L'architecture client-serveur elle-mme volue vers l'architecture distribue, ou un client peut s'adresser diffrents serveurs et un serveur peut son tour devenir client d'un autre serveur. La distribution peut tre vue comme une gnralisation du client serveur. Les outils de la gnration future pourront alors partitionner les applications non plus sur un client et un serveur, mais sur N clients et M serveurs. Le couplage avec l'approche composant voque au paragraphe prcdent conduit aux architectures objets distribues telles Corba et OLE que nous tudierons la fin de cet ouvrage. Ces architectures sont sans doute les prcurseurs des systmes client-serveur de troisime gnration.