Les architectures n-tiers

Présentation

L'architecture n-tiers a été pensée pour pallier aux limitations des architectures trois tiers et concevoir des applications puissantes et simples à maintenir. Ce type d'architecture permet de distribuer plus librement la logique applicative, ce qui facilite la répartition de la charge entre tous les niveaux.

Cette évolution des architectures trois tiers met en oeuvre une approche objet pour offrir une plus grande souplesse d'implémentation et faciliter la réutilisation des développements.

Théoriquement, ce type d'architecture supprime tous les inconvénients des architectures précédentes :

• elle permet l'utilisation d'interfaces utilisateurs riches,
• elle sépare tement tous les niveaux de l'application,
• elle offre de grandes capacités d'extension,
• elle facilite la gestion des sessions.

Que de niveaux...

L'appellation ``n-tiers'' pourrait faire penser que cette architecture met en oeuvre un nombre indéterminé de niveaux de service, alors que ces derniers sont au maximum trois (les trois niveaux d'une application informatique). En fait, l'architecture n-tiers qualifie la distribution d'application entre de multiples services et non la multiplication des niveaux de service.

Cette distribution est facilitée par l'utilisation de composants ``métier'', spécialisés et indépendants, introduits par les concepts orientés objets (langages de programmation et middleware). Elle permet de tirer pleinement partie de la notion de composants métiers réutilisables.

Ces composants rendent un service si possible générique et clairement identifié. Ils sont capables de communiquer entre eux et peuvent donc coopérer en étant implantés sur des machines distinctes.

La distribution des services applicatifs facilite aussi l'intégration de traitements existants dans les nouvelles applications. On peut ainsi envisager de connecter un programme de prise de commande existant sur le site central de l'entreprise à une application distribuée en utilisant un middleware adapté.

Le rôle de l'approche objet

L'approche objet

Les évolutions successives de l'informatique permettent de masquer la complexité des mécanismes mis en oeuvre derrière une approche de plus en plus conceptuelle.

Ainsi, les langages de programmation ont tout d'abord été très proches de la machine (langage machine de bas niveau), puis procéduraux et, enfin, orientés objets. Le succès du langage Java a véritablement popularisé ce mode de programmation.

Les protocoles réseau ont suivi le même type d'évolution. Ils furent d'abord très proches de la couche physique, avec les mécanismes de sockets orientés octets. Ensuite, la notion de RPC a permis de faire abstraction des protocoles de communication et, ainsi, a facilité la mise en place d'application client-serveur. Aujourd'hui, l'utilisation d'ORB permet une totale transparence des appels distants et permet de manipuler un objet distant comme s'il était local. Le flux d'informations fut donc initialement constitué d'octets, puis de données et, enfin, de messages.

Les méthodes de conception orientées objet telles qu'UML ou OMT permettent une modélisation plus concrète des besoins et facilitent le passage de la conception à la réalisation.

Aucune de ces évolutions ne constitue en soit une révolution, mais elles rendent économiquement réalisables des architectures qui n'étaient jusqu'à présent que techniquement envisageables.

Les objets métier

Les Java Beans

Selon les spécifications de Sun, un Java Beans est un composant logiciel réutilisable qui peut être manipulé par un outil d'assemblage. Cette notion assez large englobe aussi bien un simple bouton qu'une application complète. Concrètement, les Java Beans sont des classes Java utilisant des interfaces particulières.

Un Java Beans peut être utilisé indépendamment, sous la forme d'une simple applet, ou intégré à un développement Java. Il peut dévoiler son comportement à ses futurs utilisateurs à l'aide :

• des propriétés qu'il expose et rend accessible à l'aide d'accesseurs,
• des méthodes qu'il permet d'invoquer, comme tout objet Java,
• des événements qu'il peut générer pour avertir d'autres composants.

Le mécanisme d'introspection permet une analyse automatique du composant qui, ainsi, s'auto-décrit.

Les Java Beans proposent deux modes de fonctionnement :

• le mode de configuration permettant de paramètrer l'intégration du composant à l'aide d'un outil d'assemblage. Dans ce mode, le Java Beans propose un interface graphique de configuration,
• le mode d'exécution utilisé par l'application intégrant le Java Beans.

Les Java Beans sont gérés comme tout objet Java, notamment ce qui concerne son cycle de vie. Ils sont livrés sous forme de fichiers JAR

Les EJB (Entreprise Java Beans)

Les Enterprise Java Beans sont des Java Beans destinés à s'exécuter côté serveur :

• ils ne comportent pas forcément de partie visible,
• ils prennent en charge des fonctions de sécurité, de gestion des transactions et d'état,
• ils peuvent communiquer avec des Java Beans côté client de façon indépendante du protocole (IIOP, RMI, DCOM),
• ils s'exécutent dans un environnement ``Beanstalk'' s'appuyant sur l'API Java Server et offrant des fonctionnalités de gestion de la charge d'exécution, de la sécurité d'accès, de communication, d'accès aux services transactionnels.

Microsoft OLE-COM-ActiveX

Le modèle de communication COM permet de mettre en place une communication orientée objet entre des applications s'exécutant sur une même machine.

DCOM est une extension de ce modèle pour les architectures distribuées. Il repose sur le modèle DCE défini par l'OSF et met en oeuvre un serveur d'objets situé sur chaque machine.

Les contrôles ActiveX, anciennement dénommés OCX, sont des composants logiciels basés sur le modèles COM. Ils peuvent être intégrés à des applications où à des documents sous Windows.

La communication entre objets

Principes

Pour permettre la répartition d'objets entre machines et l'intégration des systèmes non objets, il doit être possible d'instaurer une communication entre tous ces éléments. Ainsi est né le concept de middleware objet qui a donné naissance à plusieurs spécifications, dont l'architecture CORBA préconisée par l'OMG et DCOM développée par Microsoft.

Ces middlewares sont constitués d'une série de mécanismes permettant à un ensemble de programmes d'interopérer de façon transparente. Les services offerts par les applications serveurs sont présentés aux clients sous la forme d'objets. La localisation et les mécanismes mis en oeuvre pour cette interaction sont cachés par le middleware.

La communication entre objets gomme la différence entre ce qui est local ou distant. Les appels de méthodes d'objet à objet sont traités par un ORB se chargeant d'aiguiller les messages vers les objets (locaux ou distants).

Il est possible d'encapsuler des applications ``non objet'' existantes pour les rendre accessibles via le middleware objet. Ainsi, on préserve l'existant sans alourdir les nouveaux développements, qui ne voient que l'interface de l'application encapsulée. La vision du système s'effectue ainsi de manière unifiée, chaque composant étant accessible via le middleware. Un client peut désormais accéder de la même façon à un EJB ou à une transaction sur mainframe.

L'appel de procédure distantes (RMI)

RMI permet à une application Java, s'exécutant sur une machine virtuelle, d'invoquer les méthodes d'un objet hébergé par une machine distante. Pour cela, le client utilise une représentation locale de l'interface de l'objet serveur. Cette représentation locale est appelée stub et représente l'interface de l'objet serveur, appelée skeleton.

Un objet distribué se caractérise par son interface et son adresse (URL). La mise en relation des objets est assurée par un serveur de noms.

Le modèle CORBA

Le système CORBA permet, au travers du protocole IIOP, l'utilisation d'objets structurés dans un environnement hétérogène. Cette communication, orchestrée par l'ORB, est indépendante des contraintes systèmes des différentes plates-formes matérielles.

Une application accède à un objet distant en utilisant une télécommande locale, appelée proxy. Ce proxy lui permet de déclencher les méthodes de l'objet distant à l'aide de primitives décrites avec le langage IDL.

L'OMG effectue toute une série de recommandations connues sous le nom de CORBA services visant à proposer des interfaces génériques pour chaque type de service usuel (nommage, transaction, cycle de vie, ...).

Enfin une vision cohérente du système d'information

Avec les applications n-tiers, on dispose enfin d'une vision cohérente du système d'information. Tous les services sont représentés sous la forme d'objets interchangeables qu'il est possible d'implanter librement, en fonction des besoins.

Le potentiel de ce type d'application est très important et permettrait enfin l'utilisation d'objets métiers réutilisables.

Serions-nous en présence de l'architecture parfaite, nous permettant de mettre en oeuvre les applications les plus ambitieuses au moindre coût et de les faire évoluer librement en fonction des besoins ?

Si, sur le papier, on pourrait répondre par l'affirmative, l'expérience des précédentes ``révolutions'' de l'informatique nous pousse à plus de modération. L'architecture n-tiers propose effectivement un potentiel énorme, reste à voir comment il sera utilisé, à quel coût et, surtout, comment sera gérée la transition depuis les environnements actuels.