Microsoft Host Integration Server 2000 : présentation du produit

Ce livre blanc présente les composants d'intégration disponibles dans Microsoft® Host Integration Server 2000. Ces composants permettent l'intégration des données, des applications et des réseaux de systèmes hôtes aux applications Microsoft NET. Ce livre blanc ne constitue pas un guide de déploiement ou d'administration pour Host Integration Server 2000. Une connaissance des systèmes hôtes et des stratégies d'intégration constitue un atout pour la compréhension de ce document.

Introduction

Environ 70 pour cent des données d'entreprise sont stockées sur des systèmes hôtes tels que des macro ordinateurs IBM ou AS/400. Les entreprises ont cependant de plus en plus recours à des ordinateurs personnels et à des applications Web et Windows® pour la productivité quotidienne et les solutions sectorielles. Elles ont compris que les solutions Web et Windows s'avèrent souvent plus faciles à apprendre et à mettre en œuvre que des applications comparables hébergées sur un ordinateur hôte. Pour gagner du temps et préserver leurs investissements en technologie d'hôte, les entreprises doivent migrer leurs ressources hébergées sur des ordinateurs hôtes vers des plates-formes Windows, ce qui peut être coûteux et prendre beaucoup de temps, ou les intégrer à des solutions Windows et Web plus efficientes.

L'intégration de données et d'applications hébergées sur des systèmes hôtes avec des applications fonctionnant sur le Web ou sous Windows offre des avantages considérables, notamment :

Qu'il s'agisse pour une société de créer des entrepôts de données pour améliorer la prise de décision, de développer des applications Web exécutant des transactions sur des données hébergées sur un ordinateur hôte, ou de donner aux utilisateurs la possibilité d'inclure des données archivées dans leurs rapports, Microsoft Host Integration Server 2000 dispose des composants d'intégration permettant d'atteindre facilement ces objectifs.

Pour aider ses clients à profiter de ces avantages, Microsoft a proposé dès 1990 une solution d'intégration des ordinateurs hôtes, avec le lancement de Communication Server 1.0 en partenariat avec Digital Communications Associates. Microsoft SNA Server 2.0, qui a pris la relève en 1992, permettait aux administrateurs système d'envoyer le trafic de réseau local (LAN) et le trafic de réseau SNA au travers de la même infrastructure de réseau.

Depuis lors, Microsoft n'a pas cessé d'améliorer le logiciel SNA Server en fonction des besoins de ses clients, jusqu'à en faire un produit complexe et riche en fonctionnalités. Host Integration Server 2000 reprend les points forts de SNA Server 4.0 pour offrir une gamme de technologies éprouvées, capables d'aider les entreprises à résoudre leurs problèmes d'intégration.

Haut de page

Les solutions Web les plus actuelles

Les entreprises sont fréquemment confrontées à la nécessité d'intégrer leurs systèmes hôtes à des applications fonctionnant sur le Web. C'est la raison pour laquelle Microsoft propose aujourd'hui des produits et des technologies permettant aux développeurs d'élaborer et de déployer des applications pour l'Internet d'entreprise, telles que des sites Web de commerce électronique à grand débit, des intranets d'entreprise et des formules d'intégration de la chaîne d'approvisionnement. Ces produits et technologies clés pour la création de solutions sont :

Haut de page

Microsoft .NET

Microsoft pense que le Web ressemble actuellement beaucoup aux macroordinateurs, sur lesquels les données vitales sont verrouillées dans des serveurs centralisés conçus pour publier des informations sur des pages HTML souvent prédéterminées. Les décideurs et les travailleurs du savoir bénéficient d'un accès limité, fréquemment en lecture seule, aux données vitales et n'ont que peu ou pas l'occasion d'interagir ou d'éditer ces informations à l'aide de navigateurs Web.

Microsoft crée une nouvelle génération de logiciels qui fusionne l'informatique et les communications de manière révolutionnaire pour offrir aux développeurs les outils nécessaires pour transformer le Web et l'expérience informatique. Microsoft .NET permettra la création de services Web distribués s'intégrant et collaborant avec une gamme de services complémentaires pour rendre les informations disponibles à tout moment, partout et sur tous les types de périphériques.

L'idée fondamentale de Microsoft .NET est que l'attention se détourne à présent des sites Web individuels ou des périphériques connectés à l'Internet pour se reporter sur des constellations d'ordinateurs, de périphériques et de services travaillant en collaboration afin d'offrir un éventail de solutions plus large et plus riche. Les personnes pourront contrôler les informations qui leur seront fournies ainsi que le moment et la forme de livraison. Les ordinateurs, les périphériques et les services seront en mesure de s'épauler les uns les autres pour fournir des services plus étendus, au lieu de fonctionner comme un archipel dont le seul élément de liaison est l'utilisateur. Les entreprises seront en mesure de proposer leurs produits et services sous une forme qui permettra aux clients de les imbriquer de manière transparente dans leur propre tissu électronique. Cette vision élargit encore l'autonomie déjà offerte aux utilisateurs par l'apparition du PC dans les années 80.

Microsoft .NET participera à une transformation de l'Internet où l'on verra la présentation HTML se doubler d'une information XML programmable. XML est une norme industrielle largement répandue dans le secteur et définie par le consortium W3C, l'organisation qui a défini les normes du navigateur Web. Elle a bénéficié d'un apport considérable de Microsoft Corp. mais ne constitue pas pour autant une technologie exclusive Microsoft. XML permet de séparer les données réelles de leur présentation. La norme XML est au cœur de l'Internet de nouvelle génération grâce à sa faculté de déverrouillage des informations afin de les organiser, les programmer et les modifier, sa faculté de distribution des données sous une forme plus utile à une gamme étendue de périphériques numériques, et sa faculté de permettre aux sites Web de collaborer et de fournir une myriade de services Web capables d'interagir.

Microsoft .NET comprend les éléments suivants :

Grâce à Microsoft .NET, l'informatique et les télécommunications quitteront bientôt un Web à sens unique pour entrer dans un environnement interactif, riche et participatif. Équipé d'un nouveau logiciel et bâti sur les produits actuels de .NET Enterprise Server, Microsoft .NET gérera une myriade d'applications, de services et de périphériques qui seront à l'origine d'une expérience numérique personnalisée s'adaptant constamment et de manière automatique à vos besoins et à ceux de votre famille. Cela signifie qu'une nouvelle génération de logiciels travaillera de manière intégrée pour vous aider à gérer votre vie et votre travail à l'âge de l'Internet.

Pour les consommateurs, cela représente des services intégrés simplifiés, l'unification de la navigation, de l'édition et de la création, l'accès à tous vos fichiers, à vos travaux et aux médias, en ligne ou déconnecté, une expérience holistique incluant tous les périphériques, la personnalisation intégrale et une gestion pratiquement inexistante. Cela signifie, par exemple, que tout changement apporté à vos informations, que ce soit par le biais d'un PC, d'un ordinateur portable ou d'une carte à puce, sera immédiatement et automatiquement mis à disposition partout où ces informations sont nécessaires.

Pour les travailleurs du savoir et les entreprises, cela signifie l'unification de la navigation, de l'édition et de la création, des communications coordonnées plus riches, une utilisation transparente du téléphone mobile, ainsi que des outils puissants pour la gestion des informations et le commerce électronique qui vous permettront de vous déplacer sans même le noter entre les services internes et les services de l'Internet pour inaugurer une nouvelle ère de relations commerciales dynamiques.

Pour les développeurs indépendants, c'est l'occasion de créer de nouveaux services de pointe pour l'âge de l'Internet, des services capables d'accéder automatiquement aux informations, localement ou à distance, de travailler avec n'importe quel périphérique et n'importe quel langage sans avoir à réécrire un code pour chaque environnement. Tout dans l'Internet devient un bloc de construction potentiel pour cette génération de services, et chaque application peut être exposée comme un service sur l'Internet.

La vision Microsoft .NET signifie l'autonomie des consommateurs, des entreprises, des développeurs de logiciels et du secteur dans son ensemble. Cela signifie la libération de tout le potentiel de l'Internet. Et cela signifie le Web tel que vous le voulez.

La plate-forme Microsoft .NET est construite sur la base des produits Microsoft .NET Enterprise Server, notamment Windows 2000, Microsoft SQL Server 2000, et Host Integration Server 2000.

Haut de page

Composants de Host Integration Server 2000

Les projets d'intégration sont aussi variés que les sociétés qui les entreprennent, et Host Integration Server 2000 comporte un large éventail de composants et d'outils d'intégration pour les aider à créer une solution d'intégration efficace.

Host Integration Server 2000 fournit les catégories de composants suivantes :

Figure 1 Couches d'interopérabilité des systèmes hôtes. Host Integration Server 2000 offre un ensemble complet de composants pour les couches d'intégration de réseaux, de données et d'applications. Ces outils permettent d'intégrer Windows et la plate-forme .NET avec les systèmes hôtes.

Couches d'interopérabilité des systèmes hôtes

S'agissant des nombreux services fournis par Host Integration Server 2000, il est utile de les envisager en groupes ou « couches », à l'instar de la pile de protocoles réseau : données de réseau, application et gestion. Dans les sections suivantes de cet article, nous explorerons ces couches plus en détail, en commençant par les données, puis par les applications, et enfin par les réseaux (et la gestion).

Haut de page

La couche d'intégration des données

La couche d'intégration des données de Host Integration Server 2000 donne accès à la fois aux données structurées et non structurées stockées sur des macroordinateurs IBM ou AS/400. Ces données peuvent être stockées dans une base de données ou dans un système de fichiers. Outre l'accès aux données, la couche d'intégration des données est responsable des services de transfert de données entre les ordinateurs fonctionnant sous Windows 2000 et les systèmes hôtes. Elle est constituée par les composants qui utilisent les logiciels des macroordinateurs et AS/400.

La couche d'intégration des données peut encore être subdivisée comme suit :

Tous ces services utilisent des produits hébergés sur des ordinateurs IBM qui implémentent l'architecture de gestion de fichiers distants IBM (DDM, Distributed Data Management). La DDM est un cadre méthodologique pour le partage et l'accès aux données entre les systèmes. La DDM définit la « manière de communiquer » et laisse aux fournisseurs de chaque plate-forme le soin d'implémenter son architecture. IBM prend actuellement en charge la DDM pour la plupart des plates-formes IBM, parmi lesquelles : OS/390 (MVS), AS/400, RS/6000 (AIX), et AS/36. Grâce à la prise en charge de la DDM, les développeurs sont libérés de la nécessité d'écrire des interfaces de communication complexes pour chaque plate-forme à prendre en charge. Au lieu de cela, la DDM traite cette tâche complexe pour le compte de l'application.

Figure 2 Gestion de fichiers distants (DDM). Les composants de la couche d'intégration des données de Host Integration Server 2000 utilisent des modèles répandus de fichiers DDM pour intégrer des sources de données hébergées sur des systèmes hôtes avec des applications Windows et .NET.

Host Integration Server 2000 permet l'accès aux bases de données relationnelles au travers de l'architecture de bases de données relationnelles distribuées (DRDA, Distributed Relational Data Architecture), un sous-ensemble de la DDM, et l'accès non relationnel au travers de l'implémentation du protocole RLIO ( Record Level I/O) d'entrée/sortie au niveau d'enregistrement de la DDM, tandis que le transfert de fichiers et la file d'attente des données AS/400 emploient un sous-ensemble du protocole RLIO.

Accès aux bases de données relationnelles

L'accès à la plupart des données relationnelles stockées sur des ordinateurs OS/390, AS/400 et RS/6000 se fait au travers d'un système de gestion de bases de données relationnelles. La plus répandue des bases de données de ces systèmes hôtes est la DB2 d'IBM. Dans le cas de l'ordinateur AS/400, la DB2 est intégrée au système d'exploitation. Pour les ordinateurs OS/390 et RS/6000, les entreprises déploient en général le système de gestion de bases de données relationnelles DB2 d'IBM.

Tous ces systèmes hôtes ont en commun le fait que les données stockées dans ces bases de données sont accessibles sous forme de tables relationnelles au moyen du langage d'interrogation SQL. Ceci permet un accès efficace et normalisé aux données stockées sur le système DB2 local. Pendant de nombreuses années, cependant, il n'existait aucun moyen commun d'accès sur les systèmes installés sur les ordinateurs DB2 distants. Pour résoudre ce problème, IBM a conçu l'architecture DRDA et l'a transférée à The Open Group en vue de sa publication et de son développement futur.

L'architecture DRDA permet à la fois l'accès aux données de l'hôte au travers des unités de travail distantes (RUW, Remote Unit of Work) et des unités de travail distribuées (DUW, Distributed Unit of Work). Les unités RUW permettent la mise à jour simple et en lecture seule des tables de bases de données à l'aide d'instructions SQL et de procédures stockées. Les unités DUW sont utilisées lorsque les mises à jour portent sur plusieurs instances de DB2 ou de systèmes informatiques et prend en charge le protocole de validation à deux phases (2PC). Le protocole 2PC vous donne l'assurance que les modifications aux bases de données multiples réussissent ou échouent dans leur intégralité. Nous reparlerons plus avant de ce protocole et de la gestion des transactions dans la section de ce livre blanc consacrée à la couche des applications.

Au travers de l'architecture d'accès universel aux données (UDA, Universal Data Access), Microsoft prend en charge deux méthodes répandues d'accès aux bases de données relationnelles distantes : la technologie standard ODBC et la technologie de liaison et d'incorporation d'objets (OLE DB), plus étendue. La technologie ODBC est conçue spécifiquement pour assurer l'interopérabilité avec les systèmes de gestion de bases de données relationnelles (SGBDR) accessibles en langage SQL. Elle est implémentée par des fournisseurs de logiciels indépendants (ISV, Independent Software Vendors) sous la forme d'un pilote dorsal ou d'une application frontale (par exemple un outil de création de rapports ou de requêtes). Microsoft et d'autres fournisseurs proposent des pilotes ODBC pour la plupart des SGBDR connus. Microsoft a défini la technologie OLE DB comme une architecture distribuée à plusieurs niveaux permettant à la fois l'accès aux SGBDR SQL et aux sources de données autres que SQL (par exemple dossiers de messagerie, magasins de serveur sur l'Internet, systèmes de fichiers non hiérarchisés). Dans le cadre de l'architecture OLE DB, les ISV développent des logiciels qui assument partiellement trois rôles différents : (1) FournisseurOLE DB , ou pilote de source de données principale, (2) composant de service OLE DB (par exemple processeur de requête, moteur de curseur), et (3) consommateur OLE DB (par exemple service ou application Web, requête IUG ou outil de création de rapports). La technologie OLE DB s'appuie sur le modèle COM et les fournisseurs OLE DB sont conçus pour exposer un ensemble d'interfaces bien connus. Lorsqu'un fournisseur ne peut exposer une fonctionnalité spécifique, utile ou souvent requise, un composant de service OLE DB est employé pour étendre et normaliser les capacités du fournisseur. De cette manière, les consommateurs OLE DB peuvent être écrits pour accéder à des sources de données multiples sans connaître les caprices ou les limitations d'un fournisseur principal donné.

Host Integration Server 2000 implémente l'accès aux DB2 au travers de deux fonctions :

La première de ces méthodes est le pilote ODBC pour DB2. Elle utilise un demandeur d'application DRDA (DA DRDA) sous-jacent développé par Microsoft. Le DA DRDA connecte le pilote ODBC à la DB2 sur les plates-formes les plus fréquentes, y compris OS/390, OS/400, RS/6000-AIX, Windows NT® et Windows 2000.

Cette méthode fournit aux développeurs un moyen souple de créer à l'aide d'API ODBC des applications capables d'accéder rapidement et efficacement aux enregistrements des DB2. Le pilote prend en charge l'interface standard DRDA de niveau 3 ainsi que l'interface ODBC 3.x, et permet aux développeurs d'écrire des applications en langage C et C++ chargées d'émettre des requêtes SQL dynamiques et d'appeler les procédures stockées dans DB2.

La seconde méthode d'accès à la DB2 passe par un fournisseur OLE DB pour DB2. Ce composant est également implémenté par-dessus le DA DRDA et prend donc en charge les mêmes systèmes DB2 cibles et la plus grande part des fonctionnalités d'accès aux DB2 (par exemple requêtes dynamiques SQL et procédures stockées, connexions réseau sous protocole 2PC, SNA LU6.2 et TCP/IP). les développeurs peuvent utiliser le langage C ou C++ pour intégrer les données de DB2 aux applications fonctionnant sur le Web ou sous Windows. Les développeurs qui programment à l'aide de Visual Basic® et pour le Web (à l'aide de langages de script tel que VBScript) peuvent utiliser le langage de niveau supérieur ActiveX® Data Objects (ADO) pour développer des solutions de commerce électronique. En outre, DB2 est directement accessible à partir des applications de production telles que Microsoft Office 2000 au moyen de Visual Basic for Applications (VBA) et ADO à partir d'Excel.

De nombreuses entreprises souhaitent améliorer la prise de décision en centralisant des données stockées sous divers formats et à des emplacements différents. Les administrateurs de bases de données peuvent utiliser les Services de transformation de données (DTS, Data Transformation Services), une fonction de Microsoft SQL Server 2000 et de Microsoft SQL Server 7 permettant d'importer et d'exporter des données entre plusieurs sources hétérogènes à l'aide du fournisseur OLE DB pour DB2. Au moyen de cet outil, les administrateurs sont en mesure de créer un entrepôt de données utilisant les données DB2, et d'intégrer la plupart des autres sources de données accessibles via un fournisseur OLE DB.

Une autre fonction de Microsoft SQL Server, Distributed Query Processor (DQP), permet aux utilisateurs d'accéder à des données résidant dans plusieurs bases de données sur des serveurs différents. DQP donne la possibilité aux administrateurs et aux développeurs de SQL Server de créer des requêtes liées à des serveurs qui s'exécutent pour de multiples sources de données principales sans modification ou presque. DQP permet aux développeurs d'applications de créer des requêtes hétérogènes qui associent des tables de SQL Server aux tables de DB2. De même, DQP peut être utilisé pour créer des vues SQL Server pour les tables de DB2, de sorte que les développeurs peuvent écrire directement dans SQL Server et intégrer aisément dans leurs applications aussi bien les données Windows que les données du système hôte.

Accès aux fichiers d'enregistrement

Une autre source importante d'informations héritées est la grande quantité de données encore stockées dans les fichiers VSAM des macroordinateurs, des jeux de données cloisonnés et des fichiers AS/400. Host Integration Server 2000 prend en charge les services suivants pour assurer l'accès aux données d'hôte non relationnelles :

Le fournisseur OLE DB pour AS/400 prend en charge l'accès au niveau d'enregistrement des fichiers physiques manipulés et non manipulés avec des descriptions d'enregistrement externes, ainsi qu'aux fichiers logiques avec descriptions d'enregistrement externes. De même, le fournisseur peut utiliser un fichier Description de colonne d'hôte (HCD, Host Column Description) pour décrire le format du fichier cible et mapper les types de données AS/400 vers les types de données OLE DB. Il permet ainsi au développeur d'accéder aux fichiers de données non hiérarchisés et aux fichiers source AS/400.

Le fournisseur OLE DB pour VSAM, qui utilise les fichiers HCD pour définir les métadonnées du jeu ou du membre de données cible, fournit l'accès à la plupart des types de fichiers VSAM hébergés sur macroordinateurs.

Jeux de données SAM (Sequential Access Method)

Jeux de données VSAM (Virtual Storage Sequential Access Method)

Jeux de données BPAM (Basic Partitioned Access Method)

Grâce à Visual Studio, les développeurs peuvent élaborer des applications dynamiques sur le Web qui intègrent les sources de données non relationnelles hébergées sur des ordinateurs hôtes avec les données Windows, ce qui permet aux travailleurs du savoir de publier des informations nécessaires aux décideurs de leurs entreprises.

Transfert de fichiers

La plupart des émulateurs 3270 prennent en charge la capacité de transférer des fichiers entre un macroordinateur et une station de travail au moyen du programme utilitaire IND$FILE. Ce programme travaille en association avec un système d'exploitation hôte, tel que TSO, ou avec un logiciel de surveillance de télétraitement, tel que CICS, exécuté sur le macroordinateur. Ce processus est souvent manuel et s'avère peu efficace en raison de la nécessité d'utiliser l'émulation de terminal 3270 sur le client et de faire agir le système d'exploitation hôte comme intermédiaire lors du processus de transfert de données. Host Integration Server 2000 fournit plusieurs méthodes de transferts de fichiers plus efficaces. Ces méthodes sont les suivantes :

L'utilitaire Host File Transfer permet aux développeurs de déplacer des fichiers entre un système hôte et un ordinateur Windows local. Host Integration Server 2000 assure ce service par l'entremise d'un seul contrôle ActiveX. Ceci élargit la capacité de l'application cliente à effectuer des opérations de transfert de fichiers d'un grand nombre d'environnements de développement client. À l'aide des fichiers HCD, l'utilitaire Host File Transfer peut accéder aux mêmes types de jeux de données d'un macroordinateur que le fournisseur OLE DB pour VSAM, mais il est optimisé pour télécharger le contenu intégral du jeu de données ou de l'un de ses membres. Les autres environnements pris en charge sont le AS/400 et le AS/36.

Le protocole de transfert FTP de TCP/IP est fréquemment utilisé pour déplacer des fichiers entre des systèmes informatiques fonctionnant sous UNIX, VMS et autres systèmes d'exploitation. Cette capacité est en général fournie sous la forme d'un programme utilitaire qui implémente un ensemble de commandes pouvant être utilisées pour se relier à un ordinateur distant, se connecter, naviguer vers des emplacements spécifiques au sein des systèmes de fichiers de l'ordinateur local et de l'ordinateur distant, puis transférer un ou plusieurs fichiers vers ou à partir de cet ordinateur. Malheureusement, l'utilisation de ce protocole pour transférer des fichiers vers un ordinateur hôte impliquerait de disposer de TCP/IP sur l'hôte. (La plupart des responsables de centres de données sont hostiles à la prise en charge de TCP/IP sur un ordinateur hôte pour des raisons de sécurité et de performances.) Cependant, en raison de la grande diffusion de ce protocole, IBM a implémenté une fonction SNA similaire, le protocole AFTP (APPC File Transfer Protocol). De cette manière, il est possible de transférer des fichiers entre systèmes SNA à l'aide de commandes semblables à celles de FTP, si bien que toute personne connaissant le protocole FTP peut aisément utiliser AFTP pour ses transferts de fichiers. Sur le plan interne, AFTP transfère les fichiers à l'aide du protocole de programme à programme LU 6.2, très efficace pour cette tâche. Le logiciel AFTP peut être installé sur le serveur ou le client de Host Integration Server 2000 et utilisé pour transférer des fichiers vers un hôte SNA.

La fonction AS/400 Dossiers partagés disponible dans Host Integration Server 2000 permet à un administrateur de Windows NT ou Windows 2000 de partager de nouveau un fichier sur un ordinateur hôte AS/400 comme s'il s'agissait d'un répertoire appartenant à un système de fichiers local. La fonction de dossiers partagés de AS/400 utilisant le partage de fichiers standard du système d'exploitation, elle ne requiert pas l'installation d'un logiciel sur le client. Celui-ci considère le dossier comme un répertoire partagé standard Windows NT ou Windows 2000. Cette fonction est implémentée dans Host Integration Server 2000 à l'aide du même logiciel de support PC AS/400 qui permet aux stations de travail d'accéder aux fichiers AS/400 dans une configuration SNA pure.

Accès à la file d'attente de données AS/400

Les Files d'attente de données AS/400 sont utilisées sur un système AS/400 pour envoyer des enregistrements de données entre des programmes exécutés séparément. Plusieurs programmes clients AS/400 peuvent ainsi envoyer des enregistrements de données à destination d'un seul programme serveur exécuté sur un système AS/400. Un client unique peut aussi envoyer des enregistrements vers la file d'attente de données d'un AS/400, et plusieurs programmes de serveur peuvent extraire les enregistrements pour traiter les données en parallèle. Cette fonction s'est avérée tellement utile dans le développement d'applications AS/400 que IBM a étendu l'utilisation des files d'attente de données AS/400 aux stations de travail PC. Host Integration Server 2000 permet aux applications 32 bits Windows d'accéder aux files d'attente de données par le biais du contrôle d'automation COM de la file d'attente de données du système AS/400. Host Integration Server 2000 permet aux développeurs d'accéder aux files d'attente des données AS/400 à partir d'un PC fonctionnant sous Windows, de sorte qu'ils peuvent déplacer tout ou partie de leurs applications AS/400 d'un ordinateur de ce type vers une plate-forme PC et de continuer à utiliser le programme du PC pour accéder à une file d'attente de données distante sur le système AS/400.

Haut de page

Couche d'intégration des applications

La couche Applications assure les services qui permettent à Windows et aux programmes de macroordinateurs de travailler ensemble. Elle définit la manière dont deux programmes d'application peuvent effectuer des opérations de messagerie et des transactions entre plates-formes, y compris les mises à jour de bases de données utilisant le protocole de base de données de validation en deux phases.

Dans Host Integration Server 2000, la couche Applications s'occupe principalement de programmes d'application distribués dont l'un au moins est exécuté sur un macroordinateur et un AS/400.

L'intégration des données et des applications existantes hébergées sur un ordinateur hôte avec des solutions déployées sur le Web peut présenter de nombreux avantages pour les entreprises. Elle permet notamment de conserver vos investissements technologiques actuels tout en étendant les ressources hébergées sur un ordinateur hôte à des applications évolutives et distribuées, déployées sur le Web et basées sur des composants. Elle contribue également à la réduction des coûts de développement en vous permettant de recourir à un grand réservoir de développeurs qualifiés pour Windows, plutôt qu'à un petit groupe de programmeurs de macroordinateurs hautement spécialisés. Elle tient compte, enfin, des coûts de migration en vous permettant de conserver vos ressources hébergées sur des macroordinateurs et AS/400 ou d'amortir ces coûts en migrant progressivement vers une plate-forme PC.

Traitement des transactions

Dans les applications pour macroordinateurs, les systèmes de gestion de bases de données et les programmes de traitement des transactions ont toujours été étroitement intégrés. Dans les applications développées à l'aide des logiciels CICS ou IMS de IBM, un programme de communication frontal extraie les données d'une base de données principale et/ou la met à jour. Des interactions multiples avec l'utilisateur sont fréquemment requises pour achever une transaction et mettre à jour une base de données. Là où la mise à jour de plusieurs bases de données est requise, les logiciels CICS et IMS prennent en charge le concept de transaction. En cas de mises à jour multiples au sein d'une même base de données, l'étendue d'une transaction garantit que toutes les mises à jour sont effectuées avec succès ou que les mises à jour partiellement exécutées sont renvoyées. Un programme CICS ou IMS peut également indiquer le succès ou l'échec d'une transaction en émettant une commande indiquant la fin d'une transaction ou le renvoi éventuel de mises à jour partielles.

Les systèmes de traitement des transactions des macroordinateurs prennent également en charge la définition d'une transaction pouvant exister dans plusieurs bases de données distribuées. Cette fonction s'appuie sur un standard bien connu appelé Synchronization Level 2 (Sync Level 2), également désigné sous le nom de « protocole de validation en deux phases ».

CICS permet notamment d'écrire des applications distribuées dans lesquelles un seul programme d'application CICS peut établir un lien avec un autre programme CICS situé sur le même ordinateur ou sur un autre. Pour transmettre les données au programme cible, CICS utilise une zone spéciale de données CICS appelée commarea. C'est la commarea de CICS qui joue un rôle primordial dans le passage des données vers ou depuis le programme lié.

Lors de la création d'applications gérant les transactions pour les plates-formes Windows et Web, les développeurs écrivent souvent des composants COM exécutés sous MTS (Microsoft Transaction Server) dans Windows NT ou sa fonction COM+ équivalente dans Windows 2000. MTS associe les fonctions d'un courtier d'objet COM et d'un gestionnaire de transactions. Une application peut être écrite avec des composants COM exécutés sur des ordinateurs différents. Le programmeur peut définir comment chaque composant participe aux transactions dans les composants distribués. Chaque composant COM peut spécifier s'il peut faire partie d'une nouvelle transaction ou d'une transaction existante. La partie de gestion transactionnelle de MTS est fondée sur un composant appelé DTC (Distributed Transaction Coordinator). Dès que l'état transactionnel d'un ensemble de composants est défini, MTS peut utiliser le composant DTC pour assurer la même intégrité des transactions et des mises à jour de données à leur propos qu'un programme CICS ou IMS peut imposer aux transactions des macroordinateurs. Les programmes COM peuvent indiquer le succès ou l'échec d'une transaction entière exactement comme un programme CICS ou IMS.

Afin de permettre aux applications Windows NT et Windows 2000 d'utiliser les programmes de macroordinateurs CICS et IMS existants, Host Integration Server 2000 propose COMTI (COM Transaction Integrator). COMTI permet aux programmes CICS et IMS des macroordinateurs de participer aux transactions COM.

Figure 3 COM Transaction Integrator. COMTI permet aux développeurs de préserver les environnements CICS et IMS existants tout en migrant vers une nouvelle plate-forme Windows et .NET.

COMTI crée un composant d'empaquetage (ou proxy) COM+ ou MTS qui fait ressembler un programme d'application central CICS ou IMS hérité à un composant COM au moment de l'exécution. Les applications Windows 2000 effectuent des appels de méthodes et passent des paramètres à ce programme qui leur apparaît comme un composant COM ordinaire. Cet appel prend la forme d'un appel CICS approprié et est envoyé au programme CICS du macroordinateur via Host Integration Server 2000 et LU 6.2. Dans le cadre de ce processus, le composant COMTI convertit les paramètres entre les formats macroordinateur et COM. Les transactions COMTI peuvent également participer aux transactions entre plates-formes sous le contrôle du DTC.

L'utilisation de COMTI est un processus en trois étapes :

En premier lieu, la description COBOL de la commarea doit être ramenée du macroordinateur à la station de travail à l'aide de Host File Transfer ou d'un émulateur de terminal. Ensuite, l'interface utilisateur graphique de COMTI permet d'importer la description de données COBOL et de convertir les définitions de paramètres COBOL en leurs équivalents COM. Ensuite, COMTI génère le composant COM qui assurera le rôle de proxy pour le programme d'application du macroordinateur. La commarea se convertit en une définition de jeu d'enregistrements COM qui peut servir à passer des paramètres vers et en provenance du programme du macroordinateur. Après la traduction du code, le nom du programme devient la méthode appelable de la transaction MTS et les variables passées au programme COBOL d'origine dans la commarea sont traduites en paramètres de méthode.

Après la création du composant COMTI, ce dernier peut être réuni dans un paquet avec d'autres composants pour définir la transaction complète. Au moment de l'exécution, les appels aux programmes hérités apparaissent comme des appels au composant COMTI. Les paramètres sont convertis de manière transparente et tous les protocoles de validation en deux phases sont appliqués sur les deux systèmes.

À l'heure actuelle, COMTI utilise le protocole DCOM (Distributed COM) pour communiquer entre les composants COM et Host Integration Server 2000. (Host Integration Server 2000 effectue la conversion dans le protocole SNA approprié.)

Mise en file d'attente des messages entre plates-formes

Dans la section consacrée au traitement des transactions, nous avons également expliqué de quelle façon Host Integration Server 2000 prend en charge le maintien d'une stricte synchronisation entre les bases de données distantes à l'aide des transactions distribuées et de COMTI. Lorsque des transactions synchrones sont requises, COM et COMTI fournissent une excellente méthode d'implémentation d'une application distribuée en temps réel.

Il existe un troisième scénario dans lequel les programmes doivent se passer des données, mais où il n'est pas nécessaire pour le programme effectuant l'envoi d'attendre que le programme qui reçoit les données ait traité celles-ci. Dans ce cas, il suffit de savoir que les données seront finalement expédiées et traitées. Le logiciel de passage de messages qui prend cette capacité en charge s'appelle MOM (Message Oriented Middleware). L'offre produit MOM de Microsoft est le MSMQ (Microsoft Message Queuing System).

Ce système est constitué d'agents exécutés sur les systèmes d'envoi et de files d'attente de messages sur les systèmes de réception. Un programme qui cherche à envoyer un message à un système de réception utilise simplement une API pour placer le message dans une file d'attente d'envoi locale. Le moment venu, le message est envoyé. Bien que le programme d'initialisation n'attende pas que le message soit reçu par le destinataire, il peut supposer que le message a bien été délivré. En effet, le système MOM utilise l'intégrité transactionnelle entre l'agent expéditeur local et le programme de réception.

Figure 4 Pont MSMQ-MQSeries. Le pont permet l'intégration des communications asynchrones à base de messages entre des applications hétérogènes.

MSMQ de Microsoft est le produit MOM qui prend en charge les échanges de messages entre plates-formes Windows. Les macroordinateurs et autres plates-formes, en revanche, utilisent normalement un produit développé par IBM, appelé MQSeries. IBM a étendu MQSeries à d'autres plates-formes produites par lui-même et par d'autres fabricants en plus des macroordinateurs et des systèmes AS/400. Bien qu'il existe une version de MQSeries pour Windows NT et Windows 2000, MSMQ est conçu à l'origine pour ces plates-formes. Afin de prendre en charge les messages échangés entre les systèmes de messagerie Windows et ceux des macroordinateurs, Host Integration Server 2000 est équipé d'un pont MSMQ-MQSeries. Ce pont intègre les deux plates-formes de messagerie et permet le transfert de messages dans les deux sens entre les plates-formes.

Haut de page

Couche de gestion

Dans les sections précédentes de ce livre blanc, nous avons indiqué comment les composants client et serveur de Host Integration Server 2000 travaillent ensemble pour assurer l'accès aux ressources des macroordinateurs et des systèmes AS/400. Dans cette section, nous parlerons de la couche de gestion de Host Integration Server 2000. Cette couche s'occupe de l'installation et de la gestion des serveurs et des clients de Host Integration Server 2000. Nous parlerons également de l'intégration de Host Integration Server 2000 avec les systèmes de gestion des réseaux de macroordinateurs tels que IBM NetView.

Installation du serveur Host Integration Server 2000

L'installation du serveur Host Integration Server 2000 permet à l'administrateur de spécifier les composants à installer et les divers rôles du serveur, tels que serveur de configuration primaire ou de sauvegarde. L'installation du serveur peut se faire selon plusieurs méthodes, telles que :

Par défaut, l'installation de Host Integration Server 2000 se fait depuis un CD local. Ce type d'installation s'effectue sur le serveur, et l'installateur doit répondre à toutes les invites.

Figure 5 Installation du serveur. Host Integration Server 2000 propose un programme d'installation de logiciels Microsoft qui permet à l'administrateur de choisir les fonctions les plus appropriées.

Une autre possibilité consiste à localiser les fichiers d'installation sur un point de partage de réseau. L'installateur doit toujours répondre à toutes les questions qui lui sont posées au cours du processus d'installation.

Host Integration Server 2000 prend également en charge une procédure d'installation sans assistance. Cette procédure utilise des fichiers de réponses qui éliminent le besoin pour l'installateur d'être présent pendant toute l'installation. Il doit néanmoins être présent pour lancer la procédure. Ce type d'installation peut s'effectuer à partir d'un point de partage du réseau ou de disquettes car les fichiers d'installation doivent être personnalisés. Dès que la procédure est lancée, l'installateur peut quitter son poste.

Avec Systems Management Server, un installateur ne doit même pas se rendre auprès du serveur pour lancer la procédure d'installation de Host Integration Server 2000. Systems Management Server peut être utilisé pour commander à distance l'installation et la configuration sur un serveur cible.

Configuration du serveur Host Integration Server 2000

Une fois que le serveur est installé, il doit être configuré. La procédure de configuration permet de définir les services de liaison, les types de connexions, les LU et les groupes de LU. Elle permet aussi de définir des groupes d'utilisateurs et des stations de travail clientes pour leur affecter des ressources. Des ressources peuvent être affectées de manière globale à chacun ou de manière spécifique à un utilisateur, à un groupe ou même à une seule station de travail. L'accès aux ressources peut aussi être accordé à différents niveaux de granularité, par exemple à un sous-domaine, un serveur spécifique, des groupes de LU ou même des LU spécifiques.

Installation d'un client Host Integration Server 2000

Le CD Host Integration Server 2000 comporte également des clients installables pour Windows 98, Windows 3.x, Windows NT Workstation et Windows 2000 Professionnel, ainsi que des instructions d'installation ou la source des clients pour d'autres plates-formes.

Un client Host Integration Server 2000 se compose de trois parties, qui ne doivent pas nécessairement être toutes installées. Ces parties sont le client de base, le support API et des fonctions telles que les fournisseurs OLE DB, les clients 3270 et 5250. La plupart des émulateurs d'autres fabricants requièrent uniquement l'installation du support de base.

Lors de l'installation du client Host Integration Server 2000, l'installateur peut spécifier les composants à installer, sélectionner les protocoles client-serveur que le client utilisera pour communiquer avec le serveur, et définir de quelle manière le client localisera un serveur sur le réseau. Les méthodes suivies pour installer un client sont semblables à celles utilisées pour l'installation d'un serveur, avec toutefois un ajout important : l'installation via le Web. Ces méthodes sont les suivantes :

Les trois premières méthodes sont essentiellement les mêmes. Tout comme dans le cas de Host Integration Server 2000, les serveurs et les fichiers de réponses permettent de simplifier la procédure d'installation. Dans le cas de l'installation Systems Management Server, le CD comporte aussi des lots d'installation Systems Management Server pour Windows 3.1, Windows 98, Windows NT Workstation et Windows 2000 Professional.

En ce qui concerne l'installation par l'intermédiaire du Web, un client Host Integration Server 2000 peut être installé en affichant simplement une page Web intranet ou Internet et en cliquant sur un lien hypertexte. Ce type d'installation propose trois options. L'installateur peut demander le téléchargement et l'installation du client 3270 et du client Host Integration Server 2000 complet, du client 5250 et du client complet, ou uniquement du client de base. (Ce dernier est utile pour la mise à niveau d'un ancien client de base fourni avec un émulateur d'un autre fabricant.) Cette procédure peut également être personnalisée pour fournir des capacités supplémentaires.

Configuration d'un client Host Integration Server 2000

Une fois que le client est installé, il doit être configuré. Cette configuration se limite normalement à la définition de la manière dont le client localisera un serveur sponsor lors de la connexion. Le client peut diffuser une requête de sponsor à l'ensemble du sous-domaine ou adresser la requête à un serveur spécifique ou à une liste de serveurs.

Gestion des ressources réseau de Host Integration Server

Les prédécesseurs de Host Integration Server 2000 ont toujours été à la pointe du secteur de l'intégration des réseaux d'hôte dans Windows à l'aide des protocoles de réseau standards. Host Integration Server 2000 poursuit cette tradition en élargissant la prise en charge à un grand nombre de liaisons, de connexions et de types d'unités logiques de SNA. Host Integration Server 2000 comporte des outils permettant de gérer l'installation et l'utilisation de ces ressources d'une façon sécurisée et plus ou moins rigoureusement contrôlée. Les serveurs, les unités logiques ou les groupes d'unités logiques peuvent par exemple être configurés de manière à permettre l'accès à tous les clients qui le souhaitent, ou de manière limitée à certains utilisateurs et/ou stations de travail clientes.

Le mécanisme de sécurité de ce contrôle d'accès est fondé sur les procédures de sécurité de Windows NT et de Windows 2000. Des utilisateurs et des groupes peuvent être définis et des listes de contrôle d'accès peuvent être créées pour les ressources de Host Integration Server 2000, de manière à autoriser ou refuser l'accès à ces utilisateurs, ces groupes ou ces systèmes informatiques.

Outils de gestion de Host Integration Server 2000

Plusieurs interfaces administratives permettent de gérer les ressources de Host Integration Server 2000. Ces outils comprennent :

Microsoft Management Console (MMC) est l'outil Microsoft standard permettant d'assembler des utilitaires de gestion en ensembles d'outils personnalisés destinés à déléguer des tâches et des responsabilités administratives à certains administrateurs. L'installation de Host Integration Server 2000 prévoit des composants logiciels enfichables à ajouter à une console MMC. À noter que plusieurs composants logiciels enfichables de Host Integration Server 2000 peuvent être installés dans une console afin de gérer plusieurs sous-domaines ou serveurs.

Figure 6 Configuration du serveur. Host Integration Server 2000 propose un composant logiciel enfichable sur MMC pour l'administration des configurations de serveurs.

Comme alternative à une MMC à interface graphique, Host Integration Server 2000 propose également des utilitaires de ligne de commande permettant de gérer n'importe quelle ressource de Host Integration Server 2000. Windows Scripting Host est un puissant langage de script disponible en tant que module complémentaire de Windows NT et livré d'origine avec Windows 2000. L'ajout de cet outil à ceux de la ligne de commande de Host Integration Server 2000 permet à l'administrateur de créer et de modifier n'importe quelle ressource de Host Integration Server 2000 à partir d'un script de traitement par lots. Grâce à la combinaison de Windows Scripting Host et de l'utilitaire de ligne de commande SNACFG, toutes les tâches de gestion de Host Integration Server 2000 peuvent être automatisées et exécutées sans avoir recours à l'interface graphique.

Host Integration Server 2000 prend également en charge l'administration par outils déployés sur le Web grâce à la technologie WMI (Windows Management Instrumentation) de Microsoft. Il s'agit d'une mise en œuvre de l'initiative WBEM (Web-Based Enterprise Management) de DMTF (Distributed Management Task Force) pour les plates-formes Microsoft Windows.

Figure 7 Administration par l'intermédiaire du Web. Microsoft Host Integration Server 2000 possède des capacités de gestion améliorées permettant aux administrateurs SNA de visualiser et de contrôler leur environnement SNA Server. Grâce à WMI/COM, les administrateurs peuvent construire leurs propres outils Web pour surveiller, configurer et administrer tous les objets SNA.

Normalement, un administrateur sera capable d'accéder à un serveur ou à un sous-domaine à l'aide des protocoles client-serveur que nous avons discuté dans ce livre blanc. Dans certains cas, cependant, cela risque d'être impossible. SNA Remote Access Services (SNARAS) étend l'action des services RAS de Windows NT et de Windows 2000 sur les liaisons SNA. Cela permet à un administrateur de se connecter à un serveur SNA distant sur une liaison SNA.

Host Integration Server 2000 ne s'intègre pas seulement aux outils de gestion de Windows NT et Windows 2000, mais également à ceux des réseaux de macroordinateurs les plus répandus, tels que IBM NetView. Des alertes de journal d'événements Windows NT et Windows 2000 peuvent être transmises à un système NetView à l'aide du composant NVAlert. Un opérateur NetView peut aussi exécuter les commandes de Host Integration Server 2000 à l'aide de la commande NVRunCmd fournie par Host Integration Server 2000. En outre, NetView Response Time Monitor (RTM) permet de capter des informations sur le temps de réponse du client et de renvoyer ces données à NetView.

Intégration à Active Directory

Host Integration Server 2000 profite également du service Active Directory™ de Windows 2000. Un client cherchant à localiser un serveur sponsor lors de la connexion au réseau peut utiliser Active Directory. Il peut également utiliser Active Directory pour repérer un serveur capable de mettre à sa disposition une ressource spécifique de Host Integration Server 2000, comme une LU ou un groupe de LU.

Host Integration Server 2000 utilise Active Directory grâce à l'enregistrement de ses services et de ses ressources dans le schéma de Active Directory. Les avantages de l'utilisation de Active Directory sont les suivants :

Les ordinateurs clients de Host Integration Server 2000 doivent être configurés pour communiquer avec un ordinateur exécutant Host Integration Server 2000 et utilisant des connexions sponsor ou Active Directory. Un ordinateur client ne peut être configuré pour utiliser simultanément les deux. Host Integration Server 2000 étend le schéma Active Directory pour englober les ressources de Host Integration Server.

Intégration de la sécurité des ordinateurs hôtes

L'un des problèmes soulevés par l'intégration de Windows NT et Windows 2000 avec les macroordinateurs et les ordinateurs AS/400 est que chaque type de système possède sa propre manière d'aborder les questions de sécurité. Il n'est pas rare d'avoir un compte utilisateur et un mot de passe pour accéder à un domaine Windows NT ou Windows 2000 local et un autre compte utilisateur et un autre mot de passe pour accéder au macroordinateur ou au système AS/400. En outre, les applications de macroordinateurs et/ou d'ordinateurs AS/400 peuvent elles aussi posséder leurs propres compte utilisateur et mot de passe. Après quelque temps, les utilisateurs oublient ces mots de passe multiples et finissent par les noter dans des endroits non sécurisés. Ceci nuit à l'utilité même des mots de passe.

Afin de simplifier cette situation, Host Integration Server 2000 possède une fonction d'Intégration de sécurité d'hôte.

Cette fonction consiste en un ensemble de procédures exécutées sur les serveurs de réseau pour assurer les services suivants :

Le Cache de compte d'hôte est une base de données qui mappe les noms d'utilisateurs et les mots de passe de l'hôte et de Windows NT/Windows 2000. Il prend en charge deux options : répliqué et mappé.

L'option Répliqué est utilisée lorsque le nom d'utilisateur et/ou le mot de passe sont les mêmes sur les deux plates-formes. L'option Mappé est utilisée lorsqu'ils sont différents. Ces informations permettent de traduire les noms d'utilisateur et les mots de passe entre l'ordinateur local et l'ordinateur distant.

Le Service de synchronisation de compte d'hôte permet d'intercepter les changements de mot de passe Windows NT et Windows 2000 et de les envoyer vers un système de sécurité d'hôte.

Figure 8 Intégration de sécurité d'hôte. Host Integration Server 2000 permet aux administrateurs de synchroniser les informations de compte sur l'hôte avec le domaine Windows 2000. Les comptes synchronisés permettent la signature unique, ce qui signifie pour les utilisateurs la possibilité d'avoir un seul compte utilisateur et un seul mot de passe pour se connecter à Windows et au système hôte.

Dans le cas d'un ordinateur AS/400, la synchronisation des mots de passe fonctionne dans les deux sens. Dans le cas des macroordinateurs, un outil d'un autre fabricant est nécessaire pour permettre la synchronisation bidirectionnelle avec les systèmes de sécurité pour macroordinateurs tels que RACF, ACF/2 et Top Secret.

Haut de page

Couche d'intégration des réseaux

Traditionnellement, les réseaux Windows NT et Windows 2000 utilisaient la mise en réseau Microsoft basée sur NetBIOS. Plus récemment, TCP/IP s'est imposé comme le protocole préféré dans les réseaux Windows NT et Windows 2000. En fait, Windows 2000 favorise le protocole TCP/IP.

La méthode la plus répandue de connexion de réseaux avec des protocoles différents a toujours consisté à interposer entre eux une passerelle pouvant convertir le protocole. Pour passer d'un réseau Windows 2000 à un réseau SNA, une passerelle SNA est nécessaire. Host Integration Server 2000 est la plus répandue des méthodes permettant d'assurer cette fonctionnalité. En effet, elle incorpore les fonctionnalités traditionnelles de passerelle SNA et dépasse la simple conversion de protocoles en proposant un nombre considérable de services d'habilitation pour applications de haut niveau opérant en association avec ses fonctionnalités de base.

La Couche réseau contient tous les protocoles de bas niveau utilisés pour le transport de données entre le client et Host Integration Server 2000 d'une part, et entre Host Integration Server 2000 et les ordinateurs hôtes du réseau SNA d'autre part. Elle inclut également la prise en charge de l'émulation de terminal pour 3270 et 5250 comme indiqué ci-dessous.

La connectivité SNA-Réseau local PC se trouve au cœur de tout projet d'intégration, et Microsoft déploie de grands efforts pour fournir aux entreprises des options de passerelle SNA souples. Host Integration Server 2000 s'appuie sur les fonctions de connectivité très performantes de SNA Server 4.0 pour fournir aux entreprises le plus grand nombre de possibilités de connexion entre les systèmes SNA et les réseaux de PC.

Host Integration Server 2000 connecte les réseaux locaux de PC aux macroordinateurs IBM System/390 et aux systèmes AS/400 de taille intermédiaire. Grâce à Host Integration Server 2000, les utilisateurs disposant de systèmes d'exploitation de bureau tels que Windows 2000 Professional, Windows NT Workstation, Windows 9x, Macintosh, UNIX, MS–DOS et IBM OS/2 peuvent partager des ressources hébergées sur macroordinateurs et systèmes AS/400. Les administrateurs peuvent fournir cette connectivité dans de nombreux cas sans installer les protocoles SNA sur le PC ni déployer de logiciel sur le système hôte. Le schéma suivant illustre les capacités de connectivité réseau de Host Integration Server 2000.

Figure 9 Prise en charge des réseaux par Host Integration Server 2000. Host Integration Server 2000 exploite la puissante plate-forme d'options de protocoles et de connectivité de Microsoft SNA Server. En tant que solution de passerelle SNA, Host Integration Server 2000 s'exécute sous Windows NT Server et Windows 2000 Server pour connecter les réseaux locaux sur PC aux macroordinateurs IBM System/390 et aux systèmes intermédiaires AS/400.

Architecture logicielle Host Integration Server 2000

Host Integration Server 2000 a été conçue sur une architecture client-serveur modulaire.

Architecture du serveur

Le composant serveur de Host Integration Server 2000 s'exécute sous Windows NT 4.0 ou Windows 2000 Server et fournit des services de conversion de passerelles et de protocoles. Il contient la plus grande partie de la pile de protocoles SNA et doit également informer les clients reliés de la configuration des serveurs, des services disponibles, et de l'état du réseau. Il contient les composants suivants :

SNASERVER s'exécute comme un service Windows NT ou Windows 2000. Il s'agit du moteur de conversion de protocoles de Host Integration Server 2000. Il assure l'émulation des nœuds PU 2 1et 2.1. et communique les changements d'état aux autres ordinateurs serveurs, clients et hôtes. Il permet aussi au Gestionnaire SNA d'afficher l'état des liaisons, des connexions et des LU du réseau. Il utilise les composants suivants pour communiquer entre les clients et les autres serveurs.

SNABASE s'exécute sur le serveur comme un service. Il est responsable de l'élaboration et de l'entretien d'une liste de serveurs disponibles, de liens, de LU et de programmes de télécommunication à invoquer. Il envoie également cette liste à d'autres serveurs de Host Integration Server 2000 et reçoit des mises à jour pour ces serveurs. Il conserve ces informations dans un fichier de configuration locale (COM.CFG).

Lorsqu'un client contacte pour la première fois le serveur de Host Integration Server 2000, SNABASE utilise ces informations pour détecter le serveur hébergeant les ressources recherchées par le client. Le serveur envoie ensuite au client la liste des serveurs disponibles possédant la ressource recherchée ; cette connexion initiale est appelée connexion sponsor (voir ci-dessous).

Lorsque la connexion est établie, SNABASE dirige le client vers la LU ou le groupe de LU en mesure de lui fournir la ressource demandée.

SNADMOD est un module de communications qui permet au serveur de communiquer avec des clients et d'autres serveurs. Il s'appuie sur un protocole RPC (Remote Procedure Call) exclusif de Host Integration Server 2000.

Architecture du client

L'architecture du client de Host Integration Server 2000 comprend :

Le client de Host Integration Server 2000 fournit les API requises par les applications SNA, telles que les émulateurs 3270 et les applications APPC.

L'architecture des clients de Host Integration Server 2000 diffère selon que le client est destiné à fonctionner sous Windows NT, Windows 2000 ou sous un autre système d'exploitation. Les clients Windows NT et Windows 2000 utilisent également SNABASE sous la couche des API. D'autres clients ont recours à une DLL appelable en lieu et place d'un service pour exécuter les mêmes fonctions, mais tous font appel à DMOD pour implémenter des communications communes entre les clients et les serveurs.

Au départ, les clients de Host Integration Server 2000 sont configurés de manière à essayer de contacter n'importe quel serveur dans le sous-domaine (voir ci-dessous), ou une liste de serveurs Host Integration Server 2000 spécifiques. Si la configuration définit une liste de serveurs, l'un de ceux-ci sera choisi au hasard chaque fois que le client cherche à se connecter. Cette conception a pour effet de distribuer les requêtes entre les différents serveurs, ce qui équilibre la charge entre eux. Elle autorise aussi un certain degré de tolérance de pannes. Si un serveur ou une ressource n'est pas disponible, le client peut choisir automatiquement une ressource sur un autre serveur. Ce mécanisme d'équilibrage de la charge et de tolérance des pannes est inhérent à la conception de Host Integration Server 2000 et ne doit pas être ajouté par une forme externe de gestion de clusters ou de tolérance de pannes sous Windows NT ou Windows 2000.

Les serveurs Host Integration Server 2000 sont organisés en groupes logiques appelés sous-domaines (afin de les distinguer des domines de Windows NT/2000). Le nombre de sous-domaines n'est pas limité par Host Integration Server 2000. Chaque sous-domaine peut contenir jusqu'à 15 serveurs Host Integration Server 2000 qui peuvent être définis comme primaires , de sauvegarde ou membres selon leur rôle dans le réseau. Ces désignations recouvrent une réalité analogue à celles des serveurs Windows NT et Windows 2000. Dans ce cas, cependant, les rôles des serveurs Host Integration Server 2000 désignent, plutôt que l'appartenance de la base de données des comptes de sécurité, l'appartenance d'une base de données de configuration qui décrit l'état de tous les serveurs, des ressources qu'ils contrôlent et du statut des clients qui y sont connectés.

Les trois types de serveurs peuvent héberger des ressources à l'usage des clients. Un nouveau client à la recherche de ressources peut contacter les trois types de serveurs. Les serveurs primaires peuvent aussi mettre à jour la base de données de configuration. Les serveurs de sauvegarde, en revanche, ne disposent que d'une copie en lecture seule de la base de données pour usage local. Les serveurs membres ne peuvent fournir des informations à un client sur des ressources du réseau car ils ne disposent pas d'une copie de la base de données de configuration. Ils peuvent néanmoins héberger des ressources spécifiques, telles que des LU, à l'usage des clients.

Les informations de statut sont répliquées entre les serveurs Host Integration Server 2000 pour permettre à chacun d'entre eux de posséder un fichier de configuration décrivant le statut complet de tous les serveurs et autres ressources gérées sur le réseau par Host Integration Server 2000.

Lorsqu'un ordinateur client se connecte au réseau, il contacte un serveur proche, en fonction de son propre fichier de configuration. Cette connexion est appelée connexion sponsor. Le serveur sponsor peut fournir au client une liste de ressources disponibles sur le réseau ou l'orienter vers un autre serveur du réseau. Au départ de cette connexion, le client obtient le statut des serveurs existants et d'autres ressources du réseau telles que les unités logiques ou les groupes d'unités logiques requis par le client.

Le composant client de Host Integration Server 2000 est un composant logiciel peu encombrant, puisque la plus grande partie de la conversion de protocoles et de l'habilitation des services a lieu sur le serveur. Un large éventail de clients est pris en charge : Windows 2000, Windows NT, Windows 98/95, Windows 3.X, MS–DOS, OS/2. En outre, le logiciel client de Host Integration Server 2000 est disponible auprès d'autres fabricants pour les clients Macintosh, UNIX et VMS.

Modèles de déploiement des serveurs

Un autre aspect important de l'architecture réseau de Host Integration Server 2000 réside dans la forme de déploiement des serveurs et des clients sur le réseau. À l'aide de Host Integration Server 2000, il est possible de déployer des passerelles SNA sur un réseau d'entreprise selon l'un des trois modèles suivants :

Modèle de déploiement centralize

Figure 10 Modèle de déploiement centralisé. Dans un déploiement centralisé, les ordinateurs Host Integration Server 2000 prennent en charge les clients SNA locaux et distants à pile fractionnée, les applications serveur et les émulateurs TN3270.

Le modèle de déploiement centralisé localise les serveurs Host Integration Server 2000 du centre de données proche de l'ordinateur hôte sur le réseau. Dans ce modèle, les passerelles SNA sont situées dans le centre de données et se connectent à l'hôte à l'aide des protocoles SNA natifs, tels qu'un attachement de canal ou token-ring ultra-rapide. Dans le modèle de déploiement centralisé, les administrateurs peuvent isoler le trafic SNA destiné au centre de données pour éviter de prendre en charge le trafic SNA sur un réseau étendu. Les passerelles SNA centralisées procurent un service de pile fractionnée ou TN3270 pour ordinateurs de bureau locaux ou distants qui se connectent aux passerelles à l'aide des protocoles standards pour réseaux locaux.

Le principal avantage de ce modèle est que le serveur de Host Integration Server 2000 dispose d'un accès rapide à l'ordinateur hôte par l'entremise d'un réseau local commun et d'un processeur frontal, ou même d'un attachement de canal direct. Cette localisation présente de nombreux avantages. Les serveurs étant réunis dans un seul emplacement, les clients peuvent tirer profit de l'équilibrage de charges intégré et des capacités de sauvegarde des serveurs Host Integration Server 2000 multiples. En outre, les serveurs centralisés peuvent être entretenus et administrés par du personnel MIS local.

Dans le cas d'une organisation ayant des clients situés dans des succursales distantes, certains inconvénients doivent être pris en considération. L'essentiel de la conversion de protocoles s'effectuant sur le serveur, une quantité importante de données de bas niveau fera l'aller-retour entre les clients et les serveurs. L'un des deux autres modèles peut s'avérer plus approprié dans ces cas.

Figure 11 Modèle de déploiement par succursales. Host Integration Server 2000 prend en charge la méthode traditionnelle de déploiement de passerelles SNA dans les succursales, par le biais de lignes louées SDLC et de connexions X.25 avec l'hôte.

Modèle de déploiement par succursale

Le modèle de déploiement par succursale place les passerelles SNA à proximité des clients des succursales. L'avantage de cette disposition est que le trafic de données le plus lourd se concentrera entre les clients et les serveurs sur la connexion du réseau local de la succursale. Seul un trafic SNA compressé et relativement efficient occupera le réseau étendu entre la succursale et le site central.

Un autre avantage de cette organisation est que le personnel de la succursale peut administrer les serveurs situés dans la succursale. (Bien entendu, ceci peut être considéré comme un avantage ou un inconvénient selon que vous vouliez administrer les serveurs à distance ou de manière centralisée.) L'un des progrès de Host Integration Server 2000 par rapport à son prédécesseur, SNA Server 4.0, réside dans la possibilité d'administrer les serveurs à distance. Cela simplifie la question de l'administration décentralisée des serveurs.

Un inconvénient de cette organisation est l'absence de connexion à haute vitesse entre le serveur et l'hôte. Dans ce type de disposition, les connexions et les routeurs de réseau étendu devront être dimensionnés pour pouvoir supporter le trafic entre les serveurs et les hôtes. Les serveurs n'étant pas centralisés en un seul endroit, il n'est pas non plus possible de tirer profit de l'équilibrage de charge et des capacités de sauvegarde de Host Integration Server 2000.

Modèle de déploiement distribué

Le modèle de déploiement distribué associe les meilleurs aspects des deux modèles de déploiement précédents moyennant une installation et une administration légèrement plus complexe. Dans ce modèle, les administrateurs peuvent déployer Host Integration Server 2000 simultanément sur le site central et dans les succursales. Les ordinateurs Host Integration Server 2000 des succursales gèrent les relations client-serveur et se connectent aux ordinateurs centralisés sur lesquels est exécuté Host Integration Server 2000 au moyen du protocole natif TCP/IP, ou du protocole IPX/SPX. Les serveurs centralisés gèrent les relations serveur-hôte et se connectent à l'hôte par le biais d'un attachement de canal direct ou token ring rapide utilisant les protocoles SNA natifs.

Figure 12 Modèle de déploiement distribué. Host Integration Server 2000 propose un modèle de déploiement distribué qui exploite mieux la bande passante du réseau étendu que les configurations centralisées ou en succursales.

Dans cette configuration, les liaisons entre le serveur central (ou le groupe de serveurs) et l'ordinateur hôte est un attachement de canal direct ou de réseau local rapide vers processeur frontal. Les liaisons entre les clients et leur(s) serveur(s) local(aux) peuvent également consister en une connexion de réseau local (LAN) rapide. Seul un trafic SNA relativement compact circule entre les serveurs distants et centraux. Ceci présente l'avantage de grouper les serveurs de Host Integration Server 2000 sur le site central tout en procurant aux clients distants une connexion sponsor locale et des groupes de LU locales.

Le seul inconvénient de cette approche est le nombre plus important de serveurs à déployer, administrer et entretenir. Ce n'est cependant pas un handicap sérieux, car ils peuvent être administrés si nécessaire à partir d'un site central grâce aux capacités d'administration distante de Host Integration Server 2000. Ce modèle est un peu plus coûteux parce qu'un plus grand nombre de serveurs doit être déployé. Cela ne constitue pas vraiment un empêchement, car les serveurs Host Integration Server 2000 ne réclament pas un matériel onéreux.

En général, le modèle de déploiement distribué est plus souple et plus économique que les modèles en succursales ou centralisé. Comparée à un déploiement en succursales, l'approche distribuée élimine les délais liés à l'utilisation de routeurs pour le passage de ponts et de tunnels 802.2, améliore les temps de réponse de l'hôte et simplifie la gestion du réseau. Comparée au déploiement centralisé, l'approche distribuée réduit l'utilisation du réseau étendu (WAN) et prend en charge la gestion de NetView des serveurs de succursales.

Bien entendu, la discussion précédente sur les modèles de déploiement suppose que l'hôte est un seul macroordinateur ou un ordinateur AS/400 situé sur un site central. Il est également possible que le réseau comporte plusieurs ordinateurs hôtes et/ou que les ordinateurs hôtes et les clients soient distribués sur plusieurs sites. Ici aussi, le modèle de déploiement distribué permet de réunir les avantages des organisations centralisée et en succursales en plaçant certains des serveurs Host Integration Server 2000 à proximité de leurs hôtes pour un accès rapide, et d'autres à proximité des clients qu'ils desservent. Par exemple, supposons que deux entreprises fusionnent et que chacune d'elles possède une communauté d'utilisateurs et leur propre ordinateur hôte. Chacune des deux sociétés aura à un moment donné besoin d'accéder à son propre ordinateur et à celui de son partenaire. Dans ce cas, le modèle de déploiement distribué permet aux deux sociétés de donner un accès symétrique aux deux hôtes à partir des clients de chacune elles.

En plus de ces modèles de déploiement, Host Integration Server 2000 peut aussi agir en tant que proxy pour d'autres périphériques SNA reliés au réseau ayant besoin d'accéder à un ordinateur hôte par l'entremise de Host Integration Server 2000. Cette possibilité est prise en charge dans Host Integration Server 2000 par la prise en charge de la connexion Downstreamet par les connexions directes PU. Ces capacités particulières peuvent s'avérer utiles dans certains cas particuliers.

Protocoles réseau

Host Integration Server 2000 prend en charge une grande variété de protocoles pour la communication entre les clients, le serveur et les ordinateurs hôtes. Cela lui permet de s'intégrer à l'architecture dont vous disposez, quelle qu'elle soit.

Protocoles entre serveur et hôte

Host Integration Server 2000 prend en charge plusieurs protocoles pour assurer la communication entre le serveur et l'ordinateur hôte. Ces protocoles sont mis en œuvre par les services de liaison installés sur le serveur. Microsoft, IBM et d'autres fabricants fournissent ces services de liaison. Pour l'accès aux macroordinateurs hôtes, les protocoles les plus répandus sont :

L'attachement de canal direct permet de connecter des serveurs centralisés Host Integration Server 2000 à un hôte grâce à des méthodes de connexion de canal Escon ou par bus et étiquette. L'attachement à un réseau local (LAN) par DLC 8.21.2 permet de connecter les serveurs aux hôtes sur des réseaux locaux (LAN) Ethernet, Token Ring ou FDDI (Fiber Distributed Data). La procédure SDLC permet de les connecter par l'intermédiaire des réseaux étendus commutés ou au travers de lignes directes louées. X.25 permet de connecter un serveur Host Integration Server 2000 et un macroordinateur au travers d'un réseau X.25.

Dans certains cas, l'entreprise dispose déjà d'une installation en câble coaxial pour la prise en charge de terminaux 3270 reliés à des unités de contrôle en cluster, comme IBM 3741. Dans ce cas, le protocole de liaison DFT permet de connecter des clients à Host Integration Server 2000 en empruntant ces câbles. La plupart des entreprises ayant remplacé leurs câbles coaxiaux par des réseaux locaux (LAN), cette méthode est devenue d'un usage moins fréquent.

Pour l'accès du serveur à un système AS/400, Host Integration Server 2000 prend en charge les protocoles discutés plus haut. Au lieu de DFT, cependant, Host Integration Server 2000 prend en charge la méthode de connexion par câble coaxial Twinax, utilisée à l'origine pour relier directement des terminaux IBM 5250 à un ordinateur AS/500.

Protocoles de communication client-serveur

Afin de permettre aux clients Host Integration Server 2000 de communiquer avec les serveurs Host Integration Server 2000, Host Integration Server 2000 prend en charge les protocoles suivants :

Nous avons déjà parlé plus haut des protocoles TCP/IP et DLC 802.2. Le protocole IPX/SPX est surtout utilisé dans un réseau NetWare, tandis qu'AppleTalk sert à connecter des clients Macintosh à Host Integration Server 2000.

Protocoles entre serveurs

Outre les communications serveur-hôte et client-serveur que nous avons vues plus haut, les serveurs Host Integration Server 2000 doivent également communiquer directement entre eux. Ils doivent échanger des informations sur les modifications de ressources de réseau et pour assurer d'autres fonctions de Host Integration Server 2000 qui n'intéressent que les serveurs, telles que le service de liaison distribuée, la gestion des connexions aval et l'habilitation de PU. Dans ce but, Host Integration Server 2000 gère un sous-ensemble de ses protocoles client-serveur. Normalement, les serveurs de Host Integration Server 2000 utilisent TCP/IP à cet effet. IPX/SPX peut être utilisé dans un réseau NetWare pour assurer la compatibilité ascendante lorsque Host Integration Server est exécuté sous Windows NT.

Services d'émulation de terminal

Outre le fait qu'elle fournisse les protocoles de réseau, la couche réseau contient les services d'émulation de terminal.

Dès le début des années 1970, IBM a produit la famille 3270 de claviers-écrans, d'imprimantes et d'unités de contrôle de clusters de terminaux. Les périphériques terminaux tels que les écrans et les imprimantes étaient normalement reliés à une unité de contrôle de clusters par le biais de câbles coaxiaux, reliés ensuite directement au macroordinateur ou au processeur principal. La prise en charge de ces périphériques se faisait via la LU type 2 dont nous avons parlé plus tôt dans cet article. Quelque temps après, IBM a également lancé le AS/400, son système informatique de capacité intermédiaire. Ces systèmes prennent en charge la famille de terminaux IBM 5250. Les terminaux 5250 remplissaient le même rôle que les 3270 dans les applications pour macroordinateurs. Ils utilisaient cependant LU 6.2 comme protocole de communications, au lieu de LU2.

Avec le temps, ces terminaux relativement peu évolués ont été remplacés par des ordinateurs personnels. Pour permettre l'exécution des mêmes applications, un logiciel client a été développé pour émuler les fonctions des terminaux 3270 et 5250 d'origine. IBM et d'autres fabricants ont ensuite fourni des émulateurs de terminaux clients tels que Attachmate Extra! et Rumba. Ces émulateurs de terminaux clients s'exécutent complètement sur l'ordinateur client et effectue localement toute la conversion de protocoles et les services d'affichage et d'impression.

Figure 13 Sessions d'émulation 3270. Host Integration Server 2000 vous propose un client 3270 multisessions simple, qui prend en charge les programmes clients 3270 d'autres fabricants.

D'autres émulateurs ont recours à une approche de passerelle pour placer une partie de la pile de protocoles sur le client et une autre sur un serveur. Host Integration Server 2000 et les émulateurs qui travaillent avec lui ont choisi cette approche. La pile de protocoles est ainsi fractionnée, ce qui réduit l'empreinte de l'émulateur sur le client. Host Integration Server 2000 est équipé d'émulateurs de base 3270 et 5250 qui permettent de vérifier l'installation et la configuration de Host Integration Server 2000. En général, ces émulateurs ne conviennent pas pour la production, de sorte qu'un produit tiers doit être acheté à cet effet. Les émulateurs de Host Integration Server 2000 prennent également en charge le transfert de fichiers et l'exécution de sessions de terminaux multiples sur le même ordinateur

Les émulateurs Host Integration Server 2000 (de même que les émulateurs d'autres fabricants) prennent aussi en charge la possibilité d'automatiser la signature pour macroordinateurs à l'aide d'un langage de script. De cette manière, l'émulateur peut travailler avec les fonctions Mainframe Security Integrationde Host Integration Server 2000 telles que la fonction de signature unique présentée dans la section Gestion de cet article.

Pour pouvoir accueillir des clients encore plus légers, Host Integration Server 2000 prend également en charge une version d'émulation de terminaux 3270 et 5250 qui fonctionne directement avec TCP/IP. Puisque le protocole TCP/IP est la seule exigence du côté client et qu'il existe normalement sur le client, il n'est pas nécessaire qu'une partie de la pile SNA du client Host Integration Server 2000 soit située sur la station de travail. TN3270E et TN520 permettent à un utilisateur d'accéder au réseau TCP/IP de l'ordinateur hôte à l'aide d'une variante du protocole TRCP/IP Telnet.

La plupart des émulateurs 3270 prennent en charge la capacité de transférer des fichiers entre un ordinateur hôte et une station de travail au moyen du programme utilitaire IND$FILE. Ce programme travaille en association avec un système d'exploitation, tel que TSO, ou avec le logiciel de surveillance de télétraitement, tel que CICS, exécuté sur l'ordinateur hôte. Il permet au client de demander manuellement un transfert de fichiers et de surveiller les résultats.

En outre, Host Integration Server 2000 prend en charge la plupart des protocoles d'impression 3270 et 5250 tels que ceux gérés par les périphériques LU de type 1, 3 et 6.2 (APPC).

Host Integration Server 2000 étend et améliore les interconnexions de réseau dominantes assurées par les versions précédentes de SNA Server.

Résumé

Host Integration Server 2000 représente l'évolution la plus récente sur la voie d'une solution complète d'interopérabilité entre les macroordinateurs hôtes et leurs homologues. Dorénavant, Microsoft fera porter ses efforts sur l'interopérabilité bidirectionnelle avec les ordinateurs AS/400 et les macroordinateurs IBM au niveau des couches principales. Microsoft collaborera également avec d'autres fabricants pour ajouter à Host Integration Server 2000 des modules complémentaires permettant d'améliorer l'interopérabilité entre plates-formes. De toute évidence, Host Integration Server 2000 est un produit qui permet d'élaborer dès aujourd'hui des solutions Web, en utilisant une plate-forme robuste qui, demain, pourra prendre en charge Microsoft .NET.

Haut de page