Les technologies clés

Technologies de l'information et de la communication

Connexion de machines et/ou d'applications différentes ("middleware")

Fiche Technologie-clé n : 45

VERSION 3

• Présentation de la technologie
• Objectifs de la technologie
• Environnement technologique

Présentation de la technologie

Définitions

Le middleware est en général une couche logicielle (un API) qui joue le rôle d'interface entre le client et le serveur ou entre serveur et serveur. Il est indépendant des logiciels de communication et de gestion de réseaux.

Techniques mises en oeuvre

La définition du middleware varie néanmoins, certains y incluant les SGBDR. Dans une récente étude, le cabinet anglais Ovum évalue ce marché en le décomposant en six familles de produits :

1. les logiciels d'accès aux données : il s'agit de l'application du middleware aux bases de données (relationnelles). La plupart des applications en client-seveur nécessitent que l'application cliente puisse accéder aux données d'une bases relationnelle sur un serveur. Ces middleware sont dédiés à une base de données particulière (ex : Oracle Corp. avec le produit Oracle SQL Net middleware)

2. les logiciels gérant les procédures d'appel à distance (Remote Procedure Call, ou RPC) (ex : DCE de l'OSF (Open Software Foundation) et Open Network Computing (ONC) de SunSoft Inc.) : il s'agit de l'accès distant de client à serveur, mais non dédié à une base de données particulière. Ceci permet la mise en oeuvre d'environnement client-serveur plus évolués, avec un accès possible aussi bien à des bases relationnelles ou non relationnelles. Les développement sont dédiés à des applications spécifiques. La limite essentielle de cette approche tient au fait que lorsque la transaction est lancée par le client, ce dernier doit attendre la réponse du serveur. Il est inactif pendant ce temps de réponse. Dans ce cas de figure, le client et le serveur doivent utiliser le même protocole de communication, ce qui n'est pas évident dans des environnements distribués.

3. les produits de messagerie applicative : ils permettent de désynchroniser les communications entre client et serveur. En d'autres termes, on supprime la phase d'inactivité du client. Les messages peuvent être traités en temps réel ou stockés et envoyés en temps voulu.(Ex : Integrator de Covia Technologies Inc.'s Communications). Alors que les RPC sont dédiés à des serveurs spécifiques, les messageries middleware permettent les échanges dans des environnements distribués plus hétérogènes.

4. les service d'échange entre objets : les ORB (pour Object Request Broker) organisent la circulation des messages entre objets (applicatifs). L'avantage de cette approche sur le RPC et les messageries est que les objets peuvent contenir des informations plus complexes et peuvent être utilisés sur des bases d'informations non structurées (non relationnelles). L'approche objet s'appuie sur le standard CORBA (de l'Object Management Group) et sur le langage IDL (Interface Definition Language), un API (Application Program Interface) qui permet l'envoi et la réception des objets sur le réseau. Mais les ORB n'optimisent les échanges interapplicatifs qu'entre des solutions totalement orientées objet.

5. Les outils de contrôle de transactions, les Transaction Processing Monitors (Ex : Tuxedo de Novell, Top End d'AT&T) : ils sont utilisés pour la gestion et le contrôle d'environnements distribués complexes. Les intervenant de ce domaine sont des acteurs très importants jouissant d'une grande expérience. En outre, l'approche TPM est la plus souple dans l'implémentation. Mais l'utilisation de ces environnements nécessite souvent une formation poussée.

6. Les middleware propriétaires (Ex : R/3 BASIS de SAP America Inc.) : il s'agit de développements sur-mesure optimisés pour une application ou des outils particuliers. L'utilisateur opte pour cette approche dans la mesure où l'ouverture de son système sur l'extérieur et son évolutivité n'apparaissent pas comme des contraintes.

Objectifs de la technologie

Contexte concurrentiel et économique

Le développement de l'informatique distribuée entraîne la connexion sur les réseaux de machines, d'applications et de systèmes d'exploitation différents. Il faut pouvoir faire appel, à distance, aux fonctions et aux données de n'importe quelles applications, sur n'importe quelle machine : c'est l'objet du "middleware". Autrefois, les constructeurs de matériels développaient ces fonctions pour proposer un environnement d'exploitation et de développement des applications cohérent. Avec l'avènement des systèmes ouverts et du client-serveur, le middleware devient une pièce maîtresse pour gérer la complexité et l'hétérogénéité des logiciels. Les utilisateurs ont découvert le middleware avec le client-serveur. Ces logiciels intermédiaires fournissent des interfaces ou des services de base, qui assemblent et donnent une unité aux différents composants d'une architecture de ce type.

Fonctions remplies :

Les logiciels de middleware servent à la fois d'intermédiaires entre les applications logicielles différentes et de tampon entre le logiciel d'application et l'architecture du réseau qu'ils essaient de rendre transparente. Le middleware doit également permettre de rajouter de nouveaux services (applications, logiciels...) sans remettre en cause l'existant, tant au niveau matériel que logiciel. Il doit permettre de garantir l'évolutivité du système d'information. Le mode de fonctionnement, sur le plan théorique, est le suivant : l'application sur le poste client nécessite des données ou des services qui sont hébergés sur le réseau, souvent sur des serveurs qui fonctionnent sous des systèmes d'exploitation différents et des bases de données avec des langages spécifiques. L'application client a besoin d'un système middleware qui cherche ces données ou ces services, et les retransmet à l'application client après les avoir reconfigurées.

Environnement technologique

Technologies concurrentes :

Les développements sur-mesure d'API, permettant de faire communiquer des applications pour exécuter des tâches précises, remplissent le même rôle dans certains cas.

Evolutions technologiques :

Plutôt que de reléguer leurs anciennes applications, souvent bien rodées, de nombreuses entreprises s'attachent à les rendre compatibles avec les nouveaux logiciels. L'organisation des échanges interapplicatifs dans le nouveau système d'information doit donc tenir compte de développements effectués il y a parfois plus de 15 ans, à une époque où les interfaces et autres traducteurs de messages restaient exceptionnels. Cette situation va durer au moins cinq ans

A plus long terme, le middleware devra éviter de se lier à des architectures trop spécifiques pour privilégier les interfaces standards. Le modèle optimal rendrait le middleware indépendant des SGBD (Système de Gestion de Bases de Données). Les techniques de réplication ou de distribution dépendent par ailleurs fortement de l'environnement proposé par les éditeurs.

Un axe d'évolution probable concerne le développement d'architectures client/serveur de deuxième génération (séparation de la couche présentation et de la couche applicative). Dans ce cas, il est possible d'intercaler entre les postes clients et serveurs l'outils middleware, dont le rôle sera de réaliser les traitements et l'accès aux données. Une telle configuration permet d'isoler de la partie client les modules de traitements, permettant ainsi d'effectuer des modifications sur ces modules sans affecter les postes clients. Les éditeurs et les constructeurs devront pour se faire adopter des normes de type Corba qui précise la structure des messages et les modalités des échanges entre objets.

Un autre axe d'évolution est Intranet, qui consiste à utiliser les outils d'Internet pour développer des applications au sein de l'entreprise. Certains experts parlent de client-serveur universel. Ils estiment que cette solution est très souple et facile à mettre en oeuvre, tout en répondant à la majorité des besoins.