Cet article a pour but de recenser les différentes solutions d'architectures logicielles et matérielles. Le cas des services web étant en constante évolution, il sera traité à part. N'hésitez pas à faire vos commentaires afin d'améliorer cet article sur les parties que vous connaissez bien.

L'ensemble du programme est codé sur un gros système. Cette centralisation a pour avantage une gestion et une sécurité plus faciles mais pour désavantages, une dépendance vis à vis de l'OS propriétaire ainsi que le manque d'outils modernes (bien que l'OS dispose d'un certain nombre d'API).
Architecture encore employée dans le cas d'applications importantes et critiques!

Cette architecture utilise des langages de 3^ème génération (L3G) comme le C/C++ ou Cobol.
En plus de l'utilisation de langages complexes, le protocole entre le client et le serveur est spécifique. En effet, le protocole entre le moniteur TP (Transaction Processing) et le client est non standart : seul une applet peut assurer ce dialogue.

Cette architecture utilise des langages de 4^ème génération (L4G) ce qui est un avantage certain.
Cependant, il est très consommateur de réseau et n'obtient pas une bonne scalabilité (nombre de clients limité).
De plus, nous ne sommes plus dans un contexte client léger. Il faut donc prévoir un déploiement et une exploitation au niveau client (très conséquente si le nombre de clients est grand). Il faut également gérer les configurations des différents clients (problème de versions des DLL...) et développer autant d'applications qu'il y a de canaux d'accès, de plates-formes clients...

Les risques de panne sont réparties entre tous les sites (régionaux et centraux). Une réplication des données est effectuée de façon cyclique.
Cette décentralisation est cependant difficile à gérer.

Cette architecture est connue pour être celle de CORBA. Elle est orientée composant.
Par rapport au L4G utilisé par le modèle client-serveur, cette architecture utilise du L3G ; ceci constituant un frein.
Un client ou objet C++ peut appeler un objet Java.
Ce modèle permet à Java (serveur d'EJB) via IIOP (Internet Inter-ORB Protocol) l'interopérabilité avec le monde non-java des objets distribués.

Common Object Request Broker Architecture. Régi par un consortium (OMG : Objet Management Group) qui réunit 700 entreprises informatiques ou utilisatrices d'informatique.
Le but de CORBA étant de permettre l'interopération entre différents élements hétérogènes c'est à dire écrits avec des langages différents et sur des machines différentes.

IDL : Interface Description Language. Permet aux objets de s'interfacer avec le bus CORBA. On encapsule les objets lors de la compilation IDL afin que chaque objet "préparé" appelé skeleton, puisse évoluer dans un milieu homogène. Le compilateur IDL génère également un stub pour une représentation des méthodes distribuées de l'objet CORBA sur le poste client.
Proxy/stub : objet généré automatiquement, installé chez le client et disposant de la même interface et des mêmes méthodes que celui du serveur afin que le client manipule l'objet via un objet local (qui est dans la même technologie). De ce fait, lorsque l'on veut utiliser une méthode sur le serveur, il suffit d'invoquer la même sur le proxy qui se chargera de la transmettre à l'objet serveur via une trame IIOP et l'ORB au skeleton du serveur.

ORB : Object Request Broker. Bus Logiciel afin que tous les ORB d'éditeurs puissent communiquer entre eux (middleware objet distribué).
CDR : Common Data Representation. Format d'échange de données.
GIOP : protocole commun. IIOP étant sa déclinaison pour TCP/IP.
Annuaire : le service de nommage CosNamming, permet d'enregistrer dans un annuaire tous les objets CORBA (consultable par tous le monde).
Namespace : le client s'exécute dans un espace mémoire local et crée un autre objet dans un espace mémoire distant. Il faut donc faire en sorte que le serveur retourne la référence de l'objet distant (et de l'espace mémoire associé) appelé IOR Interoperable Object Reference. Ce namespace est construit sur un annuaire LDAP via un système de fichier traditionnel ou via JNDI (Java Naming Directory Interface).
(1) Le code client crée le contexte JNDI.
(2) JNDI invoque la méthode lookup avec le nom du service et de l'objet.
(3) Le serveur instancie l'objet et le skeleton par le biais du service.
(4) Il retourne ensuite l'IOR (la référence) au client.
(5) Le client instancie le proxy du service correspondant avec l'objet CORBA du serveur.
(6) Le client associe cette référence au stub (via la méthode narrow).
(7) Le code client peut utiliser l'objet serveur de façon transparente via sa réplique installée localement (le proxy). Le proxy reformatant les appels dans une trame IIOP à destinataire du skeleton.

Les pages sont stockées sur un serveur. Un client (navigateur internet) demande une page que le serveur lui transmet intégralement sans la modifier. Ces pages peuvent contenir des scripts côté client (Javascript, VBScript).
Il est aussi possible d'utiliser des applets.
Le DHTML (Dynamic HTML) est l'ensemble HTML 4, CSS 2 et les API DOM (Document Object Model) Javascript, peuvent également être utilisés. Ces technologies récentes permettent de la réactivité au niveau client comme, par exemple, faire bouger différents éléments sur l'écran...

Les CGI ou Common Get Interface sont des programmes souvent en perl, C ou shell Unix stockés sur le serveur (à une URL propre). Le client demande un traitement au CGI en lui communiquant des données (paire clé/valeur sous la forme URL_du_CGI?cle1=val1&cle2=val2...).
Le plus gros désavantage de ces CGI réside dans le fait qu'ils ne sont pas robustes et qu'ils ne permettent pas de gérer une montée en charge (problème de scalabilité).
Les langages de script comme PHP3, CFML (ColdFusion Makup Language) sont contenus dans les pages HTML stockées sur le serveur. A la différence de HTML statique, le client qui demande une page, va en avoir une élaborée à la volée via les scripts côté serveur. De ce fait, on peut construire des pages qui se basent sur un SGBD et se réactualisent au moindre changement de la base de données. Le développement est rapide et simple. Le développement propriétaire en ColdFusion impose cependant un serveur payant.
Le fait d'envelopper ces scripts joués par le serveur dans les pages pose un problème de réutilisabilité.

Cette architecture permet de décomposer une application en plusieurs tiers :
      Le tiers données souvent confié à un SGBDR (encore trop peu de SGDBO).
      Le tiers métier géré par un serveur d'application.
      Le tiers présentation permettant d'agencer les données. Seul tiers qui changera pour permettre un déploiement multi-plateforme, multi-canaux (PDA, Téléphone...)
L'application est facilement mise à niveau, l'exploitation au niveau client très faible (le butineur étant un client léger).
Pour décomposer plus précisemment l'architecture web, on peut distinguer 5 couches :
      couche 1 - présentation : correspondrait aux JSP dans le modèle J2EE
      couche 2 - logique de contrôle : interaction entre couche présentation et couche métier, ordonnancement des services métiers, récupèration des paramètres, gestion des sessions, des cookies... ; correspondrait aux servlets dans le modèle J2EE
      couche 3 - logique des services métiers : API d'accès aux objets métier, coordonne les objets domaine, transaction, mise en application de règles de gestion et du contrôle de flux des processus ; correspondrait aux EJB Session dans le modèle J2EE
      couche 4 - logique des données ou domaine. Un modèle modélise une abstraction d'un objet élémentaire (lié à la problématique de l'application). Pour une application de force de vente, on aura comme objets domaines : produits, commandes, fournisseurs... Elle fait aussi le mapping-objet-relationnel (créer, lister, mise à jour, suppression) ; correspondrait aux EJB Session et Entité dans le modèle J2EE
      couche 5 - gérant la persistance

Les langages de script (comme PHP, CFML) se distinguent du modèle ASP (Active Server Pages de Microsoft) et JSP (Java Server Pages de Sun Microsystems) par le fait que l'ASP et le JSP ne constituent qu'une partie de l'architecture globale incluant serveur d'application supportant des composants.
Les ASP (Active Server Pages) s'exécutent sur le serveur web (de présentation) IIS (Internet Information System incorporé dans les OS Windows) et possèdent les mêmes possibilités que les langages de script comme le PHP à la différence qu'elles peuvent interopérer avec des composants COM+ (composants métiers réutilisables).
IIS (5.0) peut (mais ce n'est pas obligatoire) s'appuyer sur l'Active Directory afin de bénéficier des processus d'identification et de sécurisation de Windows 2000. Pour utiliser pleinement la sécurité de IIS 5, il faut travailler sur des disques au format NTFS (sécurité au niveau de chaque fichier et répertoire). Il est également préconisé d'utiliser un Windows "server family" car dans l'édition professionnel, il n'est pas possible de gérer plusieurs sites, de restraindre les accès en fonction des adresses IP (moins de puissance, moins de sécurité...).
La présentation est dédiée aux pages JSP et peut être supportée par la majorité des serveurs web (y compris les gratuits).
Des pages particulières appelées servlets permettent de lire et d'écrire dans le flux HTTP. Lors d'une soumission d'un formulaire, c'est à cette page, à ce controleur de récupérer toutes les données et d'instancier les beans (composants métiers) correspondant aux traitements demandés. Ils renvoyent enfin le résultat (via une JSP par exemple). Les JSP et les servlets utilisent du code HTML et du code Java. La grosse différence est que le code HTML prédomine dans une page JSP alors que c'est le code Java qui est plus important dans une servlet.

Les serveurs d'applications supportent des objets métiers (logique applicative). Ils gèrent la persistance, le transactionnel, la sécurité et la distributivité des charges. Ce type de solution permet d'obtenir une bonne scalabilité. Un serveur d'application est au coeur du système d'information : relié aux bases de données, aux serveurs collaboratifs (Lotus Domino ou MS Exchange) et ERP. Il est également sollicité par le serveur web (car il est responsable du traitement métier).
Étude des architectures de Sun Microsystem et Microsoft qui utilisent des serveurs de présentation et d'application.

ASP : langage de script évalué par IIS.
ActiveX : permet de manipuler des composants COM qui peuvent s'utiliser sur le serveur comme sur le client.
COM : composants métiers
DCOM : (Distributed COM) protocole de communication et d'appel
MTS : (Microsoft Transaction Server) serveur d'application lié à l'OS et notamment sous Windows 2000 via Active Directory, DTC (Distributed Transaction Coordinator) service de prise en charge des transactions qui peuvent distribuées, MTA (Multi-Threaded Architecture) et STA (Single Threated Apartment) qui permettent une montée en charge (mais c'est complexe!).

Fonctionnement de Java Côté Serveur
Afin de mettre en place une logique objet qui permet une modularité et des mises à jour importantes, l'architecture java est souvent utilisée.
JSP, Servlet et JavaBean appartiennent à la norme J2EE (Java Enterprise Edition). L'architecture 3 tiers respectera le Modèle Vue Contrôleur (MVC). La figure suivante résume le fonctionnement.
JavaBean (Modèle)
Les beans sont des composants réutilisables. Ces objets permettent d'utiliser la logique métier.
Objets métiers
Les objets métiers ont été définis lors de la représentation UML. Ils peuvent dans certains cas posséder les mêmes attributs que ceux d'une table (modèle de données). Les méthodes associées à ces objets permettent de pouvoir accéder à ces attributs (privés) par d'autres objets (méthode get() et set()), de lister tous les éléments représentant l'objet, de modifier et de créer dans la base de données les enregistrements dans les tables correspondantes. Ces méthodes utilisent souvent des objets techniques.
Objets techniques
Ils sont les seuls composants à avoir le droit de lire, d'écrire et de modifier dans un fichier ou dans une base de données (lorsque la logique métier est bien respectée). Des objets techniques peuvent être créés pour faire des opérations qui reviennent souvent et qui ne sont pas propres à un objet métier afin de faciliter le développement. Par exemple, un objet technique transforme le format de date de SQLServer en format de date Java (et vice versa), un objet qui décode suivant la base 64 bit, ou encore un objet qui se connecte à votre SGBD.
JSP (Vue)
Ces pages aux extensions jsp sont jouées sur le serveur web au moment où le client (navigateur web) les demande. Le code HTML prédomine (implémentation de java, appelé scriplet entre les balises <% %>). Ces pages sont équivalentes aux pages ASP. Il est possible d'utiliser (d'instancier) des objets métiers dans ce type de page.
Servlet (contrôleur)
Les servlets sont du java déjà compilé qui sera exécuté par le serveur web (extension class). Contrairement aux jsp, le code Java prédomine (implémentation du HTML). Une servlet sait lire le flux http, instancie des objets métiers (javaBean) et en retour elle écrit dans le flux http. Le conteneur (moteur de servlet) crée une instance de la servlet, lance init(), service() (si appelée via une requête) puis destroy() pour la supprimer (instance détruite puis éliminée par le garbage collector ou ramasse- miettes). Fonctionnellement, une servlet est utilisée pour traiter un formulaire (en utilisant des objets métiers) puis renvoie une page jsp ou HTML.
Architecture applicative 3 tiers MVC
Usuellement un formulaire est affiché via une jsp. S'il y a des données en provenance de la base de données, la jsp va instancier un objet métier. Par exemple, si on veut lister dans un menu déroulant d'un formulaire tous les types de contrat, la jsp va instancier un objet métier " Contrat " et demander la méthode lister (oContrat.lister()). Cette méthode, lorsqu'elle a été développée, donne à un objet technique une requête SQL (du type SELECT nomContrat FROM contrat). Cet objet technique va retourner la liste des contrats sous forme d'une structure java : un ResultSet que la jsp va pouvoir utiliser (présenter). Après que l'utilisateur ait rempli son formulaire, il appuie sur le bouton "envoyer" qui va soumettre ce formulaire. A ce moment-là, les données vont être transmises à une servlet (en POST ou en GET via le protocole HTPP) qui va les traiter. A son tour, elle va utiliser des objets métiers qui vont s'appuyer sur des objets techniques afin de faire les changements convenables sur la base de données. Enfin, la servlet va rediriger l'utilisateur vers une page HTML ou jsp afin de notifier que la modification a été faite.
Architecture applicative 3 tiers MVC sans EJB

Diagramme de séquence sans EJB
Il est également possible afin de gagner en scalabilité et afin d'avoir des composants réutilisables d'utiliser des EJB (Enterprise Java Bean).
Il existe deux types d'EJB : les EJB Sessions et les EJB Entités.
Les EJB sessions intéragissent avec des EJB entités, instancient ces EJB, peuplent leur état (affectation).
Les EJB Sessions peuvent être avec état (statefull). Leur programmation est alors simplifiée car ils gèrent l'état conversationnel de l'application.
De plus, chaque instance est dédiée à un client unique. Lorsque le client n'en a pas besoin pour un temps suffisamment long l'EJB est mis en passivation. Le Bean est mis en veille et les informations de l'état du Bean stockées dans un SGBD. L'instance est enfin détruite. Dès qu'on en a besoin à nouveau, on passe à l'activation. La nouvelle instance créée, l'état est récupéré dans le SGBD.
Cependant, ce type d'EJB à un coût s'il existe beaucoup d'utilisateurs. Il faut donc les limiter dans ce cas.
Les EJB Sessions sans état (stateless). L'état conversationnel des variables saisies au cours des étapes précédentes est à gérer dans une autre structure ce qui rend ce type d'EJB plus complexe à programmer. L'avantage réside dans le fait qu'un Bean est partagé par beaucoup d'utilisateur. On peut alors mettre en place des pools de beans pour un grand nombre d'utilisateurs (par exemple un demi millier de clients n'aura besoin que d'une demie-dizaine de beans). Ce type de bean a donc une meilleure scalabilité (en cas de montée en charge).
Les EJB Entités. Ils gèrent les données, la persistance avec la base de données. Lorsqu'on modifie l'état d'un EJB Entité, le container se charge de faire l'opération au niveau du SGBD (gérant les roll-back...). Il faut bien réfléchir avant d'instancier des EJB entités. En effet, lorsqu'un utilisateur veut lister tous les noms des 1000 clients d'une base de données et que l'on décide d'instancier pour cela les 1000 EJB Entités, la JVM du serveur d'application va tomber. Dans ce type d'utilisation, il faut utiliser des EJB de facade (Session).

Avantages DNA : les objets COM peuvent être écrits en Java mais aussi en C++, VB, Delphi, PowerBuilder ... (alors que les EJB sont uniquement en Java).
Avantages J2EE : le modèle J2EE hérite naturellement du multithread de Java alors qu'il faut le gérer (et c'est complexe) du côté de MTS.
Les applications J2EE (les beans, les servlets et les fichiers html et jsp) peuvent être packagées dans des JAR (Java ARchive) et WAR (Web ARchive). Ceci permet de déployer une application J2EE très facilement et très rapidement sur la majorité des serveurs. Pour le schéma DNA, il faut utiliser Windows NT/2000, IIS, ASP, MTS y compris côté client pour les ActiveX visibles uniquement dans Internet Explorer.
Enfin, le modèle J2EE est basé sur un standart ouvert ce qui lui assure une pérennité certaine.

Cette nouvelle architecture ressemble plus à J2EE qu'à DNA!
Elle est traitée dans un autre article disponible dans le lien ci-dessous :
Microsoft DotNet.

Ils sont constitués d'un jeu de protocoles standardisés (dont SOAP, WSDL, UDDI) qui assurent une interopérabilité entre différents composants hétérogènes (des composants en Java utilisent des méthodes d'objets en C# et en PHP sans aucun port à ouvrir du côté des firewalls).

• 1990 : Développement object, mais limitation (abcence d'accès distant et de sécurité en natif)
• 1998 : Développement en composant ou super-objet. Les EJB dans le modèle J2EE (problèmes théoriques et techniques qui entraînent une immplémentation difficile), DCOM dans l'architecture DNA (qui va bientôt être abandonné et remplacé par les objets .net) et CORBA qui devait normalement permettre à plusieurs technologies d'interopérer mais qui n'est toujours pas finalisé.
• 2001 : Les services Web sont nés, mixant les données, permettant aux sociétés d'être libres pour développer des offres complètes ou d'externaliser des services en toutes transparences sans se soucier des technologies utilisées par les clients.

Ce modèle très intéressant et très récent sera traité dans un autre article.
Cliquez ici pour le consulter.