Centre de Recherche sur les Matériaux à Haute Température

- Home - News - Conseils - SécuritéMise à jour  -  Liens  -  Accès  -

Centre de Recherche sur les Matériaux à Haute Température

Chapitre 1 du Kit de ressources Application Center 2000 : évolutivité des sites Web professionnels avec Application Center 2000

Les technologies du World Wide Web devenant rapidement la plate-forme choisie pour le support des applications d'entreprise, l'infrastructure nécessaire au développement et à l'hébergement d'applications a augmenté en taille et en complexité. La technologie des serveurs éprouve des difficultés à répondre aux demandes quotidiennes des clients en pages Web. Microsoft® Application Center 2000 (Application Center), l'un des principaux nouveaux produits de la famille Microsoft® .NET Enterprise Servers, a été conçu pour résoudre les problèmes liés à l'évolutivité, à la simplicité de gestion et à la fiabilité des serveurs.

Ce chapitre propose un aperçu de cette couche de serveurs et montre comment Application Center se positionne dans la plate-forme Microsoft®. Nous examinerons ensuite les défis, problèmes et solutions posés par la création d'applications à la fois évolutives et disponibles à l'aide de Application Center.

Sommaire

Blocs de construction

La plate-forme NET est la conséquence directe de la mutation majeure de l'architecture des applications informatiques qui ont eut lieu dans les années 1990. Pour bien apprécier l'importance de la nouvelle plate-forme Microsoft®, il est nécessaire d'examiner cette mutation architecturale, ainsi que ses causes et son impact continu sur la communauté informatique.

La mutation architecturale des applications

Lorsque la technologie de l'Internet, et notamment le Web, pénétra dans le monde de l'informatique grand public au milieu des années 1990, le modèle de l'informatique professionnelle changea considérablement. Cette mutation (Figure 1.1) était centrée sur la notion d'informatique client-serveur, qui était jusqu'alors très complexe, coûteuse et propriétaire.

Mutations de l'architecture des applications depuis 1970

Figure 1.1 Mutations de l'architecture des applications depuis 1970

L'informatique sur le Web

Le modèle du Web se caractérise par des couches plus ou moins connectées de différents groupes d'informations et d'applications résidant sur un large éventail de plates-formes matérielles. Il ne faut pas oublier que l'élément moteur principal de l'Internet depuis sa création a été le désir de fournir une plate-forme commune de distribution des informations, à la fois évolutive, extensible et à hautement disponible. Cette plate-forme est par essence extensible et non limitée à une ou deux couches informatiques. Les seules vraies limites au développement d'applications dans le monde de l'Internet sont la capacité des systèmes informatiques et l'imagination des concepteurs d'applications.

Avec la popularité croissante des navigateurs Web et la multiplication des serveurs Web dans les entreprises, il devint clair, malgré les efforts des éditeurs de logiciels client-serveur pour faciliter l'utilisation de leurs produits sur le Web, qu'un mode de pensée radicalement différent était nécessaire en matière de modèle d'application. La communauté des développeurs fut la première à formuler l'idée d'une approche caractérisée par le « plus petit dénominateur commun » de l'informatique professionnelle. Bien évidemment, de nouveaux outils et techniques étaient nécessaires pour répondre aux mutations technologiques et aux défis faisant face aux développeurs.

Mutations technologiques et défis pour les développeurs

Avec l'emprise de l'Internet sur le monde de l'informatique et l'apparition de nouvelles technologies, les développeurs firent face à de nouveaux défis auxquels les modèles de conception existants ne pouvaient répondre de manière adéquate. Ces défis étaient centrés sur les aspects suivants :

  • Environnements hétérogènes
  • évolutivité
  • Développement et déploiement rapides des applications
  • Administration et gestion des plates-formes
  • Conception d'applications adaptées aux réseaux

Environnements hétérogènes

L'un des premiers défis, et peut-être l'un des plus sérieux, était le besoin de concevoir des applications pouvant s'adapter facilement à des environnements hétérogènes. La plupart des entreprises possédaient un mélange de terminaux, de clients riches et de clients légers (Web). Outre l'adaptation aux différents clients, les nouvelles applications devaient interagir avec les données et applications héritées, hébergées sur de gros ou moyens ordinateurs, fabriqués très souvent par différents constructeurs de matériel.

évolutivité

Avant l'avènement des technologies de l'Internet, l'évolutivité était un aspect relativement facile à gérer. Tout d'abord, l'environnement informatique était essentiellement un système fermé, car l'accès à distance par le personnel, la clientèle et les partenaires professionnels était relativement limité. En conséquence, le volume d'utilisateurs et leurs modèles d'utilisation pour des applications et des services donnés étaient bien connus. Les planificateurs de stratégies disposaient d'une quantité de données historiques amplement suffisante sur lesquelles baser leurs projections en vue de dimensionner l'environnement informatique en fonction de la demande des consommateurs.

La troisième raison était liée au cycle de développement des applications, qui s'étendait généralement sur plusieurs années. Là encore, les planificateurs avaient largement le temps de prévoir l'évolutivité des systèmes et des applications.

Pour finir, les micro-ordinateurs n'avaient pas encore donné toute leur mesure (nombreux étaient ceux qui les considéraient simplement comme un peu plus intelligents que des terminaux) et leur déploiement au sein des entreprises ne faisait que débuter. Au fil du temps, on se rendit compte que le poste de travail deviendrait une partie intégrante de toute application.

Alors que le micro-ordinateur était en train de redéfinir les méthodes de travail, les technologies de l'Internet, et notamment le Web, modifièrent la façon de pensée des entreprises. Au départ, cette nouvelle technologie était perçue comme une méthode peu onéreuse de partage des informations au sein de l'entreprise. Parallèlement à son faible coût, elle permettait aux utilisateurs d'assurer leur propre développement, ce qui provoqua rapidement l'apparition de sites Web internes dans le paysage informatique.

Les principes fondamentaux de la planification de l'évolutivité commencèrent à s'éroder et, lorsque les entreprises ouvrirent leurs portes sur le monde extérieur, ils s'effondrèrent totalement. Le nouveau paradigme de conception stipulait que les systèmes devaient être conçus de manière à accepter un nombre d'utilisateurs variant de moins d'une centaine à plus d'un million.

Développement et déploiement rapides des applications

Le phénomène de l'Internet et des intranets souligna la possibilité et le besoin de déploiement rapide des applications. L'expérience des intranets d'entreprise démontrait clairement qu'il était possible de créer des applications professionnelles très rapidement. La simplicité du déploiement basé sur des URL constituait un plus. Le résultat concret fut que les responsables d'entreprise et les utilisateurs commencèrent à mettre en question l'ensemble des processus et plates-formes de développement traditionnels. Ils n'étaient plus prêts à patienter plusieurs années avant de pouvoir utiliser une application. D'un point de vue financier, la communauté professionnelle mit en doute la validité d'investissements dans des applications qui seraient dépassées au moment de leur achèvement.

à mesure que les entreprises étendirent leur horizon de l'intranet à l'Internet, la notion de déploiement rapide d'applications fut redéfinie encore plus en détail. Pour être compétitives, les applications devaient être créées presque sur demande pour être utilisées immédiatement ; c'est ce que l'on appela le développement JIT (just-in-time, juste à temps). Pour répondre à ces exigences, les développeurs durent entièrement réorganiser et revitaliser leur façon d'aborder le développement d'applications.

Administration et gestion des plates-formes

Comme pour tout aspect de la technologie informatique, les choses ne sont pas parfaites dans le monde de l'Internet et du Web. Les professionnels de l'informatique qui adoptèrent ce nouveau modèle d'application découvrirent que cette liberté et cette flexibilité étaient accompagnées d'un nouvel ensemble de problèmes d'administration et de gestion. Ces problèmes se concentraient autour des clients, des applications et des hôtes.

Le navigateur étant un produit issu de l'informatique « populaire », la plupart des entreprises ne disposaient pas d'un produit standard. Les problèmes quotidiens de prise en charge et de mise à jour eux-mêmes constituaient souvent un cauchemar logistique. Du point de vue du développement, le manque de normalisation faisait que les concepteurs d'applications devaient gérer les capacités de rendu HTML de base et étendues de chaque version de navigateur.

Le déploiement des applications était encore plus difficile à gérer, car les administrateurs de système devaient faire face à un grand nombre d'éditeurs de contenu, plutôt qu'à un groupe unique de développeurs. La gestion de cet aspect de l'informatique basée sur le Web devint de plus en plus ardue à mesure que les entreprises commencèrent à fournir du contenu dynamique, reposant sur des données. La portée du modèle de programmation Web fut élargie par le besoin d'inclure divers magasins de données et de gérer plusieurs langages de script.

Tout administrateur Web ayant travaillé lors des débuts des applications professionnelles basées sur l'Internet attestera sans doute des nombreuses heures de travail manuel nécessaires à la maintenance d'un site de taille moyenne pour un fonctionnement correct et continu, tout ceci étant dû à un autre aspect du phénomène Internet : les attentes des utilisateurs quant à la disponibilité des sites 24 h/24 et 7 jours/7. Les demandes en support technique augmentèrent à fur et à mesure de l'ajout de serveurs pour gérer l'augmentation du trafic sur les sites Web.

Malheureusement, les concepteurs et les partisans du Web négligèrent d'inclure un ensemble d'outils de gestion de plate-forme ; c'est donc à la communauté informatique qu'incomba la recherche d'une solution.

Applications adaptées aux réseaux

L'ultime défi présenté aux développeurs est le résultat des avancées faites dans le secteur de la technologie des ordinateurs portables et de la baisse du coût de ces ordinateurs (portables, notebooks et PC de poche). Grâce entre autres à l'accès généralisé rendu possible par l'Internet, l'informatique portable a subi un taux de croissance apparenté à celui du Web. Des chiffres récents indiquent que les ventes de portables dépassent maintenant celles des ordinateurs de bureau.

L'utilisation hors connexion, ou déconnectée, ne constitue plus une exception. La communauté des utilisateurs souhaite pouvoir utiliser les applications et les services en mode en ligne et hors connexion. Le développeur d'applications doit être capable d'inclure cette fonctionnalité dans ses applications.

Aperçu des applications Web distribuées

L'initiative .NET aborde les défis auxquels font face les entreprises en combinant une vision architecturale avec un ensemble complet de technologies Microsoft. Ces technologies peuvent être utilisées pour développer, déployer et supporter des applications distribuées sur n niveaux. Hautement intégrée mais flexible, cette suite de produits permet aux développeurs de créer des solutions professionnelles de bout en bout : des solutions qui peuvent tirer parti des applications et des architectures existantes. Examinons maintenant la philosophie à la base de cette plate-forme et les principaux éléments qui la composent.

Philosophie et avantages

Le principe clé des applications Web distribuées est le partitionnement logique d'une application en trois niveaux :

  • Présentation
  • Logique professionnelle
  • Stockage et accès aux données

En partitionnant les applications selon ce principe, à l'aide de techniques de programmation s'appuyant sur des composants et en utilisant au mieux les services fournis par le système d'exploitation Windows, les développeurs peuvent créer des applications hautement évolutives et souples. Le tableau 1.1 résume les principaux avantages de l'adoption du modèle d'applications Web distribuées.

 

Tableau 1.1 Les avantages de l'utilisation de la plate-forme Windows pour créer des applications

 
Avantage
Description
Rapidité de développement Utilisation des techniques de programmation déclaratives des composants COM (Component Object Model) et enfichables.
évolutivité Utilisation des services de composants Windows pour gérer les problèmes liés aux threads, aux ressources, à la distribution et à la simultanéité.
Facilité de déploiement et de gestion Utilisation des services du système d'exploitation Windows pour geler ou réduire le coût du déploiement et l'adapter à un schéma de gestion.
Prise en charge des clients déconnectés Création de clients riches qui continueront à fonctionner une fois l'utilisateur déconnecté.
Facilité de personnalisation Utilisation d'outils de programmation standards et d'outils pour utilisateurs finals pour personnaliser les composants.
Prise en charge de plusieurs magasins de données Utilisation des services de données pour permettre à l'application d'accéder aux bases de données, au système de messagerie et au système de fichiers.
Intégration et interopérabilité Utilisation des services Windows pour accéder aux données et communiquer avec des systèmes hétérogènes.

Composants de plate-forme

Un modèle d'application simple consiste en un client qui communique avec la couche intermédiaire, qui est elle-même constituée du serveur d'application et d'une application contenant la logique professionnelle. L'application, à son tour, communique avec une base de données dorsale servant à stocker et à fournir les données.

Examinons plus en détail les éléments de chaque couche, en commençant par la couche de présentation, qui est prise en charge par les services de présentation.

Services de présentation

La couche de présentation est constituée d'une interface de client riche ou client léger vers une application. Le client riche, qui utilise l'API Microsoft® Win32®, fournit une interface de programmation complète aux capacités du système d'exploitation et utilise de manière étendue les composants. Moins robuste et moins apte à offrir des niveaux de performances semblables à ceux d'un client riche, le client léger (navigateur Web) devient rapidement l'interface choisie par de nombreux développeurs. Un développeur est en mesure de tirer parti de plusieurs langages de script simples mais robustes pour créer une logique professionnelle pouvant être exécutée sur n'importe laquelle des trois couches d'application. Avec une prise en charge complète de HTML et des modèles d'objet DHTML et XML, le client léger est à même de fournir une interface utilisateur visuellement riche, flexible et interactive vers les applications. Les clients légers présentent également l'avantage de fournir un plus haut degré d'adaptabilité aux différentes plates-formes.

Logique professionnelle/services d'application

Cette couche est divisée en serveurs d'application (Internet Information Services [IIS], Site Server et SNA Server) et en services, disponibles pour la prise en charge des clients. La logique des applications Web, composée généralement de pages ASP (Active Server Pages) et écrite à l'aide de Microsoft® Virtual Basic® Scripting Edition (VBScript), est traitée dans l'espace de serveur IIS. Il est possible d'écrire des applications ASP ou COM pour tirer parti des services MTS (Microsoft Transaction Server), MSMQ (Message Queuing), d'annuaire et de sécurité. Les services d'application, à leur tour, peuvent interagir avec plusieurs services de données sur la couche dorsale.

Stockage et accès aux données

Les services de données qui prennent en charge le stockage et l'accès aux données sont composés de :

  • ADO, qui fournit un accès par programmation simplifié aux données à l'aide de langages de programmation ou de script ;
  • une base de données OLE, fournisseur de données universel établi, développé par Microsoft ;
  • XML, norme de balisage pour la spécification des structures de données.

XML est une norme récente introduite par la communauté Internet. Alors que HTML est axé sur la manière dont les informations sont rendues par le navigateur et affichées à l'écran, l'objectif de XML est de gérer une structure de données et sa représentation.

Services système

Les éléments de chacun des segments de notre modèle sont entièrement pris en charge par le système d'exploitation Windows qui fournit des services d'annuaire, de sécurité, de gestion et de communication fonctionnant sur les trois couches. Les outils de programmation inclus dans la suite de développement Microsoft® Visual Studio® version 6.0 permettent aux développeurs de créer des composants d'application sur toutes les couches.

Microsoft .NET Enterprise Servers

La couche Microsoft .NET Enterprise Servers étend la vision des applications distribuées. Sa philosophie et ses objectifs de base : fournir un modèle et des outils pour la création de solutions professionnelles distribuées à plusieur niveaux, n'ont pas changé. Le schéma de la Figure 1.2 illustre la couche Enterprise Servers, y compris Application Center, et montre comment la plate-forme .NET s'adapte à la plate-forme Microsoft.

 

Positionnement de Application Center 2000 dans la plate-forme professionnelle Microsoft

Figure 1.2 Positionnement de Application Center 2000 dans la plate-forme professionnelle Microsoft®

Les ajouts les plus remarquables à la plate-forme, et les plus importants de notre point de vue, sont les nouvelles technologies de serveur intégrées dans la couche Enterprise Servers. Il était évident que les clients avaient besoin d'un moyen simple et économique d'échelonner leurs fermes de serveurs Web (également appelées clusters Web) pour gérer l'augmentation du trafic. Des outils étaient également nécessaires au déploiement et à la gestion du contenu et des applications sur ces serveurs. La solution est Application Center 2000, un produit qui :

  • résout les problèmes liés au déploiement des applications Web sur plusieurs serveurs ;
  • gère le déploiement du contenu et des applications sur les clusters ;
  • équilibre les charges et distribue de manière transparente le travail sur un cluster ;
  • fournit une surveillance proactive des mesures de performances et de santé ;
  • prend en charge les tests de performances afin de garantir l'évolutivité des applications des générations suivantes.

Positionnement de Application Center

Application Center est un produit de serveur stratégique de la couche .NET Enterprise Servers. Application Center a été développé en vue de fournir un outil bon marché mais robuste pour faciliter l'évolutivité et la gestion d'un large éventail d'applications professionnelles basées sur le Web. Ses fonctions, qui comprennent l'équilibrage de charge et la synchronisation des serveurs, pour n'en nommer que deux, ne sont pas limitées aux applications Web et peuvent prendre en charge les applications COM+. La version 1 est intégrée aux services Windows 2000 Server de base, tels que l'équilibrage de la charge (NLB, Network Load Balancing) et, grâce à son niveau d'intégration, étend les services de base du système d'exploitation en fournissant des outils tels que la publication d'applications. Application Center se situe dans la couche Enterprise Servers, si bien qu'il est en mesure de s'intégrer à d'autres services et serveurs de la couche intermédiaire, ainsi qu'à la couche d'outils de développement.

à mesure que nous examinerons les différents éléments du modèle informatique Web dans la section suivante, vous comprendrez mieux le rôle de Application Center et apprécierez les fonctionnalités qu'il apporte aux applications basées sur le Web.

Le modèle informatique du Web pour les entreprises

Les entreprises d'aujourd'hui étant des modèles de changements dynamiques, à la croissance rapide et aux changements de direction fréquents, le modèle du Web convient parfaitement à l'informatique professionnelle. Les sites Web peuvent croître de manière exponentielle avec la demande, et fournir une gamme complète de services pouvant être adaptés aux exigences des utilisateurs. Ces services sont souvent très complexes et doivent être intégrés à d'autres services de l'entreprise.

Dans cette section, nous examinerons les objectifs et éléments architecturaux d'un site Web d'entreprise, ainsi que certaines topologies de site typiques. Pour plus d'informations sur la création de sites évolutifs à plusieurs niveaux, consultez le livre blanc intitulé (en anglais) A Blueprint for Building Web Sites Using the Windows DNA Platform, qui se trouve en annexe.

Objectifs architecturaux

Le fondement d'une architecture qui répond de manière adéquate aux besoins informatiques professionnels doit satisfaire aux objectifs suivants :

  • évolutivité : permettre une croissance continue pour répondre aux demandes des utilisateurs et aux besoins professionnels en fournissant une capacité d'évolution rentable presque linéaire.
  • Disponibilité et fiabilité : s'assurer qu'il existe des services continus pour prendre en charge les opérations commerciales en utilisant une redondance et une spécialisation fonctionnelles.
  • Gestion : faciliter la gestion pour garantir que les opérations peuvent suivre le taux de croissance et réduire le coût total de propriété (TCO, Total Cost of Ownership).
  • Sécurité : garantir qu'un système de sécurité adapté est en place afin de protéger les biens de l'entreprise, à savoir son infrastructure et ses données.

éléments architecturaux

Les éléments architecturaux clés d'un site Web professionnel à plusieurs niveaux, illustrés en Figure 1.4, sont les suivants :

  • Clients
  • Systèmes frontaux
  • Systèmes dorsaux

Pour l'architecte du site et le développeur d'applications, tous ces éléments doivent être pris en compte dans le contexte de l'évolutivité, de la fiabilité, de la sécurité et des opérations de gestion.

 

éléments architecturaux d'un site Web professionnel à plusieurs niveaux

 

Figure 1.3 éléments architecturaux d'un site Web professionnel à plusieurs niveaux

La Figure 1.3 montre la division entre les systèmes frontaux et dorsaux, ainsi que la segmentation du pare-feu et du réseau, qui constituent des éléments clés de la sécurité dans les architectures des sites. Examinons maintenant plus en détail les éléments de ce modèle, en commençant par les clients.

Clients

Les clients émettent des demandes de service au serveur hébergeant l'application à laquelle le client accède. Du point de vue de l'utilisateur, les seules choses visibles sont une URL qui identifie la page d'un site, des liens hypertextes pour la navigation une fois la page extraite, ou des formulaires à remplir. Ni le client, ni l'utilisateur ne sont informés des opérations effectuées par le serveur répondant à la demande.

Systèmes frontaux

Les systèmes frontaux sont constitués des groupes de serveurs qui fournissent les services de base, tels que HTTP/HTTPS et FTP, aux clients. Ces serveurs hébergent les pages Web demandées et exécutent généralement tous les mêmes logiciels. Par souci d'efficacité, il n'est pas rare que ces groupes de serveurs (fermes ou clusters Web) aient accès à des partages de fichiers communs, des composants de la logique professionnelle ou des systèmes de base de données situés sur les systèmes dorsaux de notre modèle (ou sur la couche intermédiaire dans les modèles plus étendus).

Les systèmes frontaux sont généralement qualifiés de « sans état », car ils ne stockent pas d'informations sur les clients d'une session à une autre. Si vous souhaitez conserver les informations sur les clients d'une session à une autre, vous pouvez procéder de plusieurs manières. La plus courante implique l'utilisation de cookies. Une autre technique consiste à écrire des informations sur les clients dans la chaîne d'en-tête HTTP d'une page Web que le client doit extraire. La dernière méthode consiste à stocker les informations sur les clients dans un serveur de base de données dorsal. Cette dernière technique, bien qu'elle améliore grandement la fiabilité, peut avoir un sérieux impact sur les performances et doit donc être employée avec prudence. Dans les chapitres suivants nous aborderons les thèmes de l'état et de la persistance, des concepts centraux à une bonne conception d'application.

L'évolutivité des systèmes frontaux s'obtient en augmentant la capacité d'un serveur donné ou en ajoutant d'autres serveurs. Nous examinerons les options et problèmes liés à la disponibilité et à l'évolutivité plus loin dans ce chapitre.

Systèmes dorsaux

Les systèmes dorsaux sont les serveurs hébergeant les magasins de données utilisés par les systèmes frontaux. Dans certains cas, un serveur dorsal ne stocke aucune donnée mais accède à une source de données située à un autre endroit du réseau d'entreprise. Les données peuvent être stockées dans des fichiers non hiérarchisés, dans d'autres applications ou sur des serveurs de base de données tels que Microsoft SQL Server. Le tableau suivant résume les zones de données et de stockage.

 

Tableau 1.2 Différent types de magasins de données

 

Systèmes de fichiers
Bases de données
Applications
Exemple Partages de fichiers SQL Server Insertion de publicités, SAP, Siebel
Données Pages HTML, images, fichiers exécutables, scripts, objets COM Catalogues, informations sur les clients, journaux, informations de facturation, tarifs Bannières publicitaires, informations de comptabilité, informations sur les stocks/d'inventaire

Parce qu'ils doivent conserver des données et un certain état, les systèmes dorsaux sont qualifiés de systèmes « à état ». En tant que tels, ils présentent un plus grand défi du point de vue de l'évolutivité et de la disponibilité. Ces aspects sont discutés plus en détail dans une autre section de ce chapitre.

Infrastructure de sécurité

La sécurisation des biens d'une entreprise, avec ses travailleurs mobiles, ses connexions informatiques directes avec des partenaires et une porte ouverte sur l'Internet, est une tâche complexe et coûteuse. Les conséquences d'une sécurité informatique mise en œuvre de manière incorrecte peuvent même se révéler désastreuses pour une entreprise.

à un haut niveau, les domaines de sécurité (qu'il ne faut pas confondre avec les domaines Internet ou Microsoft Windows NT®/Windows 2000) permettent de bénéficier de zones de sécurité constante, reliées par des interfaces bien définies et protégées. Les grandes entreprises peuvent partitionner leur environnement informatique en domaines multiples, en fonction de divisions départementales, de la géographie ou des réseaux physiques, pour ne citer que quelques exemples. Les domaines de sécurité peuvent être imbriqués les uns dans les autres, ou même se chevaucher. Il existe autant d'architectures de sécurité que de mécanismes de sécurité.

à un niveau moins élevé, le modèle de base de sécurisation d'un site implique la mise en place d'un ou plusieurs périmètres pour surveiller et, si nécessaire, bloquer le trafic réseau entrant ou sortant. Ce périmètre de défense (pare-feu) peut être composé de routeurs ou de serveurs sécurisés spécialisés. La plupart des entreprises utilisent un second pare-feu, tel qu'illustré à la Figure 1.4. Cette zone comprise entre les pare-feu est nommée zone démilitarisée (DMZ, demilitarized zone) par les experts en sécurité.

 

Utilisation de pare-feu pour l'établissement d'une zone sécurisée

Figure 1.4 Utilisation de pare-feu pour l'établissement d'une zone sécurisée

N'oublions pas que ceci n'est qu'un modèle ; chaque entreprise construit son architecture de sécurité en fonction de ses propres besoins. En fait, certaines entreprises placent leurs serveurs Web du côté Internet du pare-feu, ayant déterminé que le risque ou le coût de reconstruction d'un serveur Web endommagé n'est pas suffisamment élevé pour justifier une protection supplémentaire. Cette décision peut également être influencée par le coût d'une protection supplémentaire au niveau des performances.

Nous discuterons de la sécurité en détail plus loin dans cet ouvrage, en nous concentrant sur son application à l'environnement Application Center, ses serveurs agrégés et leurs applications.

Infrastructure de gestion

Les systèmes de gestion de site sont souvent créés sur des réseaux séparés, afin de garantir une grande disponibilité et d'éviter tout impact négatif sur l'infrastructure d'applications. Les éléments architecturaux de base d'un système de gestion sont les suivants :

  • Consoles de gestion servant de portails et permettant aux administrateurs d'accéder aux serveurs gérés et de les manipuler
  • Serveurs de gestion (également appelés serveurs d'analyse) qui analysent en permanence les serveurs gérés, reçoivent des alertes et des notifications, enregistrent les événements et les données de performances dans des journaux, et jouent le rôle de première ligne de réponse aux événements prédéterminés
  • Agents de gestion, qui sont des programmes exécutant des fonctions de gestion à l'intérieur du périphérique sur lequel ils résident

Lorsque des systèmes évoluent en taille ou que leur taux de modification augmente rapidement, la gestion d'un site Web professionnel devient un facteur critique en termes de fiabilité, de disponibilité, d'évolutivité et de coût total de propriété. La simplicité d'administration, la facilité de configuration et la surveillance continue de l'état de santé et des performances prennent le pas sur les services et les fonctionnalités des applications.

Services d'application hautement évolutifs et disponibles

Maintenant que nous avons traité des objectifs et des éléments architecturaux d'un site Web professionnel, envisageons le modèle de site de la Figure 1.3 et développons-le (Figure 1.5).

 

Un site Web à plusieurs niveaux type

Figure 1.5 Un site Web à plusieurs niveaux type

Avant de voir comment les technologies Microsoft permettent de développer ce site et de répondre à nos objectifs architecturaux, examinons les différents aspects de la disponibilité et de l'évolutivité, ainsi que les solutions disponibles actuellement.

Approche traditionnelle : l'augmentation de la capacité des serveurs

Les problèmes de disponibilité et d'évolutivité ne sont pas nouveaux dans le monde de l'informatique ; ils existent depuis que les ordinateurs sont utilisés dans le milieu des affaires. Les manières traditionnelles d'aborder ces problèmes n'ont vraiment été remises en question que lorsque le micro-ordinateur est devenu une plate-forme d'hébergement d'applications professionnelles crédible.

Disponibilité

Plusieurs architectures permettent d'augmenter la disponibilité des systèmes informatiques. Ces architectures peuvent aller des ordinateurs avec composants redondants, tels que les lecteurs permutables à chaud, à des systèmes entièrement dupliqués. Dans le cas d'un système informatique entièrement dupliqué, le modèle logiciel d'utilisation du matériel est un modèle dans lequel l'ordinateur principal exécute l'application pendant que l'autre ordinateur est inactif et prêt à intervenir en cas de défaillance du système principal. Les inconvénients majeurs sont l'augmentation des coûts matériels (sans aucune amélioration du rendement du système) et l'absence de protection contre la défaillance des applications.

Pourquoi la disponibilité est-elle importante ?

En 1992, une étude a estimé que les temps d'arrêt système coûtaient aux entreprises américaines 4 milliards de dollars par an.1 Le temps d'arrêt moyen entraîne une perte de 140 000 dollars dans l'industrie de la vente au détail et 450 000 dollars dans le secteur du placement. Ces chiffres sont basés sur des entreprises informatisées AVANT le phénomène Internet.

évolutivité

L'approche traditionnelle de l'évolutivité est l'augmentation de capacité des serveurs. Ceci implique l'ajout de mémoire et l'augmentation de la taille ou du nombre de disques utilisés pour le stockage. L'étape suivante est l'ajout d'UC afin de créer un système multiprocesseur symétrique (SMP, Symmetric Multiprocessing). Dans un système SMP, plusieurs UC partagent une mémoire globale et un sous-système d'E/S. Le modèle de mémoire partagée, comme son nom l'indique, exécute une seule copie du système d'exploitation et les applications sont exécutées comme si elles se trouvaient sur un ordinateur à UC unique. Ces systèmes SMP sont très évolutifs lorsque les applications ne doivent pas stocker de données. Les inconvénients majeurs sont les limitations physiques du matériel, notamment la vitesse de bus et de mémoire, qui sont coûteuses à surmonter. Le passage d'un à deux, de deux à quatre, et de quatre à huit microprocesseurs entraîne une hausse considérable du prix. Il est évident qu'à un certain moment, un ordinateur donné ne peut plus être mis à niveau et il est nécessaire d'acheter un système plus important ; c'est un point que quiconque ayant possédé un micro-ordinateur saura apprécier.

En terme de disponibilité, l'approche SMP présente un avantage par rapport aux systèmes à UC unique : si une UC tombe en panne, il en reste plusieurs pour exécuter les applications.

Les systèmes à multitraitement avec composants redondants

Une étude rapide menée en février 2000 auprès des principaux fabricants de serveurs haut de gamme a démontré qu'un système Intel avec certains composants redondants (par exemple alimentation et disques permutables à chaud) et quatre microprocesseurs coûtait aux environs de 60 000 dollars pour un serveur de base.

Une alternative : l'ajout de serveurs

Une autre solution consiste à ajouter des serveurs, principalement sur la couche frontale, pour distribuer et gérer la charge de travail. Pour que cette méthode soit efficace, au lieu d'augmenter la capacité d'un serveur, un équilibrage de la charge est nécessaire pour distribuer cette dernière sur les serveurs frontaux. Il existe trois principaux mécanismes d'équilibrage de la charge : les adresses IP multiples (installation DNS cyclique), le mappage d'adresses IP virtuelles sur des adresses réelles basé sur le matériel, et le mappage d'adresses IP virtuelles sur des adresses réelles basé sur logiciel.

Adresses IP multiples (installation DNS cyclique)

La répartition cyclique est une technique employée par les serveurs DNS pour distribuer la charge pour les ressources réseau. Cette technique fait tourner l'ordre des données d'enregistrement de ressources renvoyées dans la réponse à une requête lorsque plusieurs enregistrements de ressources du même type existent pour le nom de domaine DNS interrogé.

En guise d'exemple, prenons une requête effectuée sur un ordinateur utilisant trois adresses IP (10.0.0.1, 10.0.0.2, 10.0.0.3), chaque adresse étant spécifiée dans son propre enregistrement de ressources de type A. Le tableau suivant illustre comment sont gérées ces requêtes de clients.

 

Tableau 1.3 Renvois d'adresses IP avec une installation DNS cyclique

 
Demande du client
Séquence de renvoi d'adresses IP
Première 10.0.0.1, 10.0.0.2, 10.0.0.3
Deuxième 10.0.0.2, 10.0.0.3, 10.0.0.1
Troisième 10.0.0.3, 10.0.0.1, 10.0.0.2

Le processus de rotation continue jusqu'à ce que les données de tous les enregistrements de ressources du même type aient effectué un cycle complet dans la liste renvoyée dans les réponses à la requête du client.

Bien que la répartition cyclique DNS fournisse un équilibrage de charge simple parmi les serveurs Web, ainsi que l'évolutivité et une redondance, elle ne fournit pas d'ensemble de fonctionnalités étendu pour la gestion de serveur unifiée, le déploiement et la gestion de contenu, ni la surveillance des performances et de l'état de santé.

Solutions matérielles

Les solutions matérielles utilisent un pont ou un commutateur spécial, et des logiciels supplémentaires destinés à gérer le routage des demandes. Pour que l'équilibrage de la charge puisse se faire, le commutateur doit tout d'abord découvrir les adresses IP de tous les serveurs auxquels il est relié. IL analyse tous les paquets entrants dirigés vers son adresse IP et les réécrit de manière à ce qu'ils contiennent l'adresse IP d'un serveur donné. Le choix du serveur dépend de la disponibilité des serveurs et de l'algorithme d'équilibrage de charge utilisé. La configuration illustrée à la Figure 1.6 utilise des concentrateurs ou des commutateurs associés à LocalDirector de Cisco Systems pour distribuer la charge entre trois serveurs.

 

LocalDirector utilisé conjointement à des concentrateurs ou des commutateurs

Figure 1.6 LocalDirector utilisé conjointement à des concentrateurs ou des commutateurs

LocalDirector et les autres produits tiers de même type fournissent des mécanismes d'équilibrage de charge performants, plus sophistiqués que la répartition cyclique DNS. Ces produits sont intelligents et incluent de nombreuses fonctionnalités d'équilibrage de charge ; ils sont par exemple capables de supprimer de manière transparente un serveur lorsqu'il tombe en panne. Cependant, ils ne fournissent pas d'outil de gestion des fermes Web large et robuste.

Solutions logicielles

La solution initiale d'équilibrage de charge basée sur logiciel proposée par Microsoft était le service d'équilibrage de charge Windows NT WLBS (Windows NT Load Balancing Service), également connu sous le nom de Convoy.

Remarque Dans la série Windows 2000 Server, le service WLBS a été amélioré et renommé service NLB (Network Load Balancing). Le service NLB n'est disponible que dans les versions Advanced et Data Center du système d'exploitation.

Par nature, le service WLBS effectue un mappage d'une adresse IP virtuelle (VIP, Virtual IP address) partagée sur les adresses IP réelles des serveurs qui font partie du schéma d'équilibrage de charge. Le service NLB est un pilote de filtrage de paquets NDIS qui réside au-dessus du pilote NDIS de la carte réseau et au-dessous de la pile TCP/IP. Chaque serveur reçoit tous les paquets pour la VIP, et le service NLB décide paquet par paquet lesquels doivent être traités par un serveur donné. Si le paquet doit être traité par un autre serveur, le serveur exécutant NLB rejette le paquet. S'il détermine que le paquet doit être traité localement, celui-ci est transmis à la pile TCP/IP.

L'équilibrage de la charge est l'un des aspects propres au concept informatique appelé « Gestion de clusters ».

Gestion de clusters

La mise en clusters est une architecture informatique qui aborde plusieurs problèmes, parmi lesquels les performances, la disponibilité et l'évolutivité. Comme c'est le cas pour les autres architectures dont nous avons parlé, la gestion de clusters n'est pas un concept nouveau. Les nouveaux aspects sont sa mise en œuvre et les plates-formes qui peuvent tirer parti de cette architecture.

Présentation des clusters

Un cluster est un ensemble de serveurs indépendants et plus ou moins connectés entre eux, qui se comportent comme un système unique. Les membres d'un cluster, ou nœuds, peuvent être des systèmes SMP si ce niveau de puissance de calcul est nécessaire. Toutefois, la plupart des clusters peuvent se créer à l'aide d'une technologie informatique standard et peu onéreuse. Les clusters possèdent trois caractéristiques majeures :

  • La possibilité de traiter tous les ordinateurs du cluster en tant que serveur unique. Les clients des applications se comportent avec un cluster comme s'il s'agissait d'un serveur unique, et les administrateurs de système visualisent le cluster de la même manière : comme l'image d'un système unique. La facilité de gestion du cluster dépend de la manière dont la technologie de cluster est mise en œuvre, ainsi que des outils fournis par le fabricant.
  • La possibilité de partager la charge de travail. Dans un cluster, une forme de mécanisme d'équilibrage de charge permet de distribuer la charge entre les serveurs.
  • La possibilité de faire évoluer le cluster. Que la gestion de clusters soit mise en œuvre en utilisant un groupe de serveurs standards ou des serveurs SMP à hautes performances, les capacités de traitement d'un cluster peuvent être augmentées progressivement par l'ajout de serveurs.
  • La capacité de fournir un haut niveau de disponibilité. Parmi les techniques employées, on peut citer la tolérance de pannes, le basculement/la restauration automatique et l'isolement. Ces techniques sont fréquemment utilisées de manière interchangeable et de manière incorrecte.

Tolérance de pannes

Pour les clusters de serveurs, un système à tolérance de pannes est un système disponible en permanence. Les systèmes à tolérance de pannes sont généralement mis en œuvre en configurant une sauvegarde du serveur principal qui demeure inactive jusqu'à ce qu'une défaillance se produise. à ce moment-là, le serveur de secours devient serveur principal.

Basculement/Restauration automatique

Le basculement décrit le processus de mise hors connexion des ressources sur un nœud, soit individuellement, soit dans un groupe, et leur remise en ligne sur un autre nœud. Les transactions hors connexion et en ligne ont lieu dans un ordre prédéfini. Les ressources qui dépendent d'autres ressources étant mises hors connexion avant et remises en ligne après les ressources dont elles dépendent. La restauration automatique est le processus de restauration des ressources sur leur nœud préféré après la défaillance et la remise en ligne de ce nœud.

Isolement

L'isolement est une technique qui permet simplement d'isoler un serveur défaillant au sein d'un cluster. Les autres nœuds du cluster continuent de répondre aux demandes des clients.

Les différentes techniques utilisées pour fournir un niveau élevé de disponibilité sont ce qui distingue deux des technologies de gestion de clusters de Microsoft : Windows Clustering (anciennement Wolfpack ou Cluster Server), qui met en œuvre le basculement/la restauration rapide, et Application Center, qui utilise l'isolement.

Ces deux technologies mettent en œuvre certains aspects du modèle d'architecture de clusters appelé « Aucun partage ». (L'autre modèle principal de gestion de clusters est appelé « Disque partagé ».)

Modèle de gestion de clusters Windows « Aucun partage »

Comme son nom l'indique, le modèle « aucun partage » signifie que chaque membre du cluster possède ses propres ressources. Bien qu'un seul serveur puisse posséder et accéder à une ressource particulière à un moment donné, un autre serveur peut se l'approprier en cas de panne. Ce changement de propriété et ce réacheminement des demandes des clients pour une ressource a lieu de manière dynamique.

En guise d'exemple, prenons une situation dans laquelle un client a besoin d'accéder à des ressources possédées par plusieurs serveurs. Le serveur hôte analyse la demande initiale et génère ses propres demandes, destinées aux serveurs correspondants. Chaque serveur gère sa partie de la demande et renvoie les informations à l'hôte. L'hôte recueille toutes les réponses aux sous-requêtes et les regroupe en une réponse unique, qui est ensuite envoyée au client.

La demande de serveur unique sur l'hôte décrit généralement une fonction de haut niveau ; l'extraction de plusieurs enregistrements de données, par exemple, qui génère une part importante d'activité système, telle que des lectures sur plusieurs disques. Cette activité et le trafic associé n'apparaissent sur les interconnexions du cluster que lorsque les données requises sont trouvées. Grâce à l'utilisation d'applications, telles qu'une base de données, distribuées sur plusieurs serveurs mis en cluster, les performances globales du système ne sont pas limitées par les ressources d'un seul membre du cluster. Les services exigeant beaucoup d'écritures peuvent poser problème, car tous les membres du cluster doivent effectuer toutes les écritures et l'exécution de mises à jour simultanées est délicate. Le modèle « aucun partage » est plus simple à mettre en œuvre que le modèle « disque partagé » et la bande passante d'E/S évolue à mesure que le site croît. Ce modèle convient particulièrement aux applications qui sont principalement en lecture seule et ne nécessitent que peu d'espace de stockage.

Cette approche est cependant coûteuse lorsqu'il y a des magasins de données importants et à écritures fréquentes, car les données doivent être répliquées sur chaque membre du cluster.

Partitions et paquets

Les concepts de « aucun partage » et de « disque partagé » peuvent également être appliqués aux partitions de données qui sont mises en œuvre comme paquets de deux nœuds ou plus ayant accès au stockage des données. Transparente pour l'application, cette technique permet d'augmenter les performances et la disponibilité des serveurs de base de données.

Modèle « Aucun partage » de Application Center 2000

Application Center pousse le concept de « aucun partage » encore un peu plus loin ; en effet, il n'existe absolument aucun partage. Chaque membre du cluster utilise ses propres ressources (par exemple, UC, mémoire et disque) et conserve sa propre copie du contenu Web et des applications. Chaque membre est en tous points une réplique exacte (parfois appelée réplica ou clone) du contrôleur de cluster. L'avantage de cette mise en œuvre du modèle « aucun partage » est que si un nœud quelconque, y compris le contrôleur, tombe en panne, l'ensemble du système, ses paramètres, son contenu et ses applications restent disponibles lorsque le serveur défaillant est isolé.

Vous comprenez sans doute maintenant que, malgré les progrès offerts par les outils de développement, la création d'applications distribuées performantes, disponibles et évolutives n'est pas une tâche aisée. Lorsque l'équilibrage de la charge et la gestion de clusters sont ajoutés au modèle d'application à plusieurs niveaux, il faut commencer à penser en termes d'applications prenant en charge les clusters.

Conseil Il vous faudra sans doute ajouter l'adaptabilité au réseau à votre liste de critères de conception d'applications.

Prise en charge des clusters par les applications

Bien que la technologie des clusters puisse garantir disponibilité et évolutivité, il ne faut pas oublier que les applications doivent être conçues et écrites de manière à tirer pleinement parti de ces avantages. Dans les applications de base de données, par exemple, le logiciel de serveur doit être amélioré afin de coordonner l'accès aux données partagées dans un cluster à disque partagé, ou de partitionner les requêtes SQL en sous-requêtes dans un cluster de type « aucun partage ». Toujours dans le cas d'un cluster « aucun partage », le serveur de base de données souhaitera peut-être effectuer des requêtes parallèles dans le cluster afin de tirer au mieux parti des données répliquées ou partitionnées.

Comme vous pouvez le voir, un certain degré de prévoyance et de planification est nécessaire pour concevoir une application performante qui utilisera au mieux la puissance de la technologie des clusters.

Augmentation de la capacité des serveurs ou ajout de serveurs

L'augmentation de la capacité des serveurs ou l'ajout de serveurs supplémentaires constituent deux solutions viables au problème de l'évolutivité. Ces deux solutions possèdent des avantages et des inconvénients. Nous examinerons à présent le problème de la disponibilité et de la tolérance de pannes, puis nous étudierons l'aspect économique de l'évolutivité.

Grande disponibilité

Tout le monde s'accorde sur le fait que la haute disponibilité et la tolérance de pannes représentent des avantages importants. Pour déterminer quelle approche constitue la meilleure solution, il faut aborder le problème dans le contexte de l'application, du risque et du coût des temps d'arrêt, et du coût nécessaire à la satisfaction des exigences en disponibilité de l'entreprise. (Il ne faut pas confondre le maintien en service et la disponibilité. Selon mon expérience et celle d'autres professionnels de l'industrie, la plupart des systèmes professionnels peuvent se vanter d'un pourcentage de maintien en service de l'ordre de 99,9 %. Le problème, c'est qu'ils ne sont pas toujours disponibles lorsqu'il le faut.)

Le concept de la disponibilité 24 heures/24, 7 jours/7 est relativement nouveau, et est l'une des conséquences intéressantes du phénomène Internet. Il semble que les utilisateurs du monde entier aient besoin d'accéder aux données ou de faire leurs achats 24 heures sur 24, 7 jours sur 7. Le modèle de l'augmentation de la capacité des serveurs étant basé sur un système haut de gamme unique (et par conséquent un point de défaillance unique), il est impératif de disposer d'une certaine forme de tolérance de pannes pour garantir la disponibilité. Comme nous l'avons vu dans un exemple précédent, la plupart des plates-formes de serveur Intel haut de gamme sont dotées d'alimentations électriques redondantes, de mécanismes de vérification des erreurs de mémoire et de composants permutables à chaud, tels que des disques.

Dans le modèle d'ajout de serveurs basé sur le matériel et utilisé par LocalDirector, il y a également un point de défaillance unique, le périphérique d'équilibrage de charge lui-même. La Figure 1.7 montre une configuration LocalDirector à tolérance de pannes Ce type de résolution du problème du point de défaillance unique est complexe et coûteux à mettre en œuvre et à maintenir.

 

Configuration LocalDirector à tolérance de pannes

Figure 1.7 Configuration LocalDirector à tolérance de pannes

Le modèle d'ajout de serveurs basé sur logiciel proposé par Application Center n'a pas de point de panne unique. La haute disponibilité est assurée par la mise à la disposition des demandes des clients de plusieurs serveurs identiques. Ces serveurs étant peu onéreux, cette manière d'aborder la redondance est très rentable. En outre, plus il y a de serveurs dans un cluster, moins il y a de risques que tous se retrouvent déconnectés simultanément. Les performances seront peut-être diminuées si plusieurs serveurs sont hors connexion, mais les applications et les services du cluster resteront disponibles à l'utilisation. Parmi les différentes solutions, c'est Application Center qui fournit le plus haut niveau de disponibilité pour le coût le plus attractif.

économie de l'évolutivité

Avant la sortie de Application Center, le côté économique de l'évolutivité était relativement simple.

Si vous aviez un seul serveur haut de gamme, il vous suffisait de le mettre à niveau en ajoutant de la mémoire, des UC, etc. Une fois atteinte la limite de mise à niveau du serveur, il vous fallait opter pour un plus grand modèle. De ce point de vue, l'évolutivité avait un coût élevé. Cependant, les frais d'exploitation demeuraient en grande partie les mêmes en raison de la simplicité du processus d'évolution.

La construction de fermes Web utilisant la répartition cyclique DNS ou des outils d'équilibrage de charge tiers était très économique du point de vue de l'équipement. Des serveurs simples à microprocesseur unique pouvaient assurer le rôle de serveur Web. Du point de vue du fonctionnement, les choses n'étaient pas aussi roses.

à mesure que l'on ajoutait des serveurs à la ferme Web, l'environnement devenait de plus en plus complexe et difficile à gérer. Seul un nombre restreint d'options était disponible pour la gestion des serveurs ou de leur contenu et des applications en tant que groupe. Une augmentation de la capacité s'accompagnait fréquemment d'une augmentation exponentielle des frais d'exploitation.

Application Center fournit quant à lui une évolutivité de la capacité quasiment linéaire tout en limitant les frais d'exploitation. La Figure 1.8 compare le modèle traditionnel d'augmentation de la capacité au modèle d'évolutivité de Application Center. L'axe Y représente la capacité et l'axe X montre l'évolution des frais d'exploitation lorsque la capacité augmente. Ceci permet également de démontrer que l'ajout de serveurs offre un niveau d'évolutivité plus élevé que l'augmentation de la capacité des serveurs existants.

 

Comparaison de la capacité et des frais d'exploitation entre les modèles d'augmentation de la capacité des serveurs et d'ajout de nouveaux serveurs

Figure 1.8 Comparaison de la capacité et des frais d'exploitation entre les modèles d'augmentation de la capacité des serveurs et d'ajout de nouveaux serveurs

évolutivité avec Application Center

L'un des principaux objectifs de Application Center est la réduction des frais d'exploitation grâce à l'utilisation d'outils permettant de gérer les groupes de serveurs et leur contenu. Le principe est d'automatiser le plus d'activités possible et d'offrir une interface permettant à un administrateur système de gérer un cluster à charge équilibrée en tant qu'image d'un système unique. Le résultat final est une solution qui offre une disponibilité et une évolutivité à faible coût tout en réduisant les frais d'exploitation.

évolutivité de sites à plusieurs niveaux à l'aide de la technologie de gestion de clusters de Microsoft

Examinons à nouveau le modèle de site à plusieurs niveaux de base (Figure 1.5) et voyons comment les technologies de gestion de clusters de Microsoft peuvent être employées pour fournir une infrastructure hautement disponible et évolutive pour la prise en charge de services et d'applications d'entreprise. La Figure 1.9 utilise la même topologie et le même partitionnement que la Figure 1.5, mais des clusters de base de données et des clusters à charge équilibrée ont été ajoutés pour fournir un niveau de disponibilité plus élevé et augmenter la capacité du site à gérer les requêtes des clients.

 

Un site à plusieurs niveaux développé

Figure 1.9 Un site à plusieurs niveaux développés

Comme vous pouvez le constater, il est possible de créer des clusters à tout endroit de l'infrastructure informatique où disponibilité et évolutivité sont nécessaires. Ces clusters peuvent être gérés localement ou à distance (à l'aide d'une connexion VPN sécurisée à un contrôleur de cluster).

Notez qu'une couche intermédiaire de serveurs de composants à charge équilibrée est incluse dans le site pris comme exemple. Application Center prend en charge l'équilibrage de charge de composant (CLB, Component Load Balancing) ainsi que NLB. Si la conception des applications le demande, des composants peuvent donc être hébergés sur un cluster à charge équilibrée séparé. Dans certains cas, il se peut qu'une plus grande granularité dans le partitionnement de la logique professionnelle soit nécessaire (par exemple, pour des raisons de performances ou de sécurité). La prise en charge de CLB permet au développeur d'exploiter pleinement la technologie des objets et de concevoir des applications robustes à tolérance de pannes.

Dernière mise à jour le mardi 23 janvier 2001

Pour en savoir plus
Page Up Updated 24 septembre, 2003 Hervé Chaudret
C.N.R.S.

-   Home   -  News   -   Conseils   -   Sécurité   -   Mise à jour   -   Liens   -   Accès   -

C.N.R.S.