Etude analytique des architectures applicatives

(1)

Etude analytique

des architectures applicatives

1 - INTRODUCTION... 2

1.1 - Objectif... 2

1.2 - Périmètre de l’étude ... 2

1.3 - Plan de l’étude... 2

1.4 - Guide de lecture ... 3

2 - TYPOLOGIE APPLICATIVE ET CRITERES ... 4

2.1 - Typologie ... 4

2.2 - Critères d’évaluation ... 5

3 - ARCHITECTURES APPLICATIVES ... 12

3.1 - La technologie J2EE ... 12

3.2 - La technologie .NET ... 16

3.3 - Catégorie Web Interactif ... 17

3.4 - Catégorie Publication... 32

3.5 - Catégorie Décisionnel ... 41

3.6 - Catégorie Collaboratif... 46

3.7 - Catégorie PGIs ... 48

3.8 - Catégorie Intégration applicative ... 52

4 - APPROCHE ARCHITECTURALE ... 55

4.1 - Modèles décrivant une architecture applicative... 55

4.2 - Protocoles et APIs... 61

4.3 - Historique des architectures applicatives ... 65

4.4 - Avantages et inconvénients de l’approche n-tier ... 67

4.5 - Applications et infrastructure... 69

4.6 - Composants et réutilisation... 71

4.7 - Frameworks... 73

5 - APPROCHES COMPLEMENTAIRES ... 76

5.1 - Les bases de données ... 76

5.2 - Décisionnel OLAP ... 77

5.3 - Les Services Web... 82

5.4 - L’interopérabilité applicative... 85

6 - ANNEXES... 88

6.1 - Glossaire... 88

Document de travail et d’information décembre 2002

ATICA

(2)

1 - INTRODUCTION

1.1 - OBJECTIF

Cette étude des architectures applicatives vise à favoriser la connaissance dans ce domaine ; il est perfectible et les lecteurs sont invités à l’enrichir et l’améliorer en écrivant à l’adresse suivante : interoperabilite@atica.pm.gouv.fr.

1.2 - PERIMETRE DE L’ETUDE

Le périmètre de cette étude est l’ensemble des architectures applicatives informatiques ; elle ne se limite pas à celles actuellement utilisées dans l’administration mais à l’ensemble du marché.

Par contre, les architectures des solutions orientées grand public, par exemple les applications personnelles sur PC (bureautique, monétique …), ne seront pas prises en compte.

En plus des architectures éprouvées, une exploration des modèles émergents sera effectuée (par exemple les architectures s’appuyant sur des Services Web*). Dans le même esprit, les architectures patrimoniales qui fonctionneront encore de nombreuses années (transactionnels non Web, Mainframes ...) n’ont pas été exclues du champ de l’étude.

Par contre les architectures pour le temps réel, la conduite de processus ou le calcul scientifique n’en font pas partie.

1.3 - PLAN DE L’ETUDE

Le chapitre 2 - décrit la typologie de classement fonctionnelle des architectures applicatives étudiées, et les critères qui les caractérisent, aussi bien du point de vue général qu’en terme d’interopérabilité.

Le chapitre 3 - décrit chaque architecture et l’évalue par rapport aux critères définis.

Le chapitre 4 - traite la problématique architecturale d’un point de vue plus analytique. Il comprend un rappel historique et une typologie de différents types d’architecture (n-tier), puis aborde la thématique des composants et des frameworks.

Le chapitre 5 - traite des approches complémentaires, autour des bases de données et du décisionnel, et fournit une présentation des Services Web et de l’intégration applicative.

Le document est complété par un glossaire. Les mots du glossaire sont signalés par une * à leur première apparition.

(3)

1.4 - GUIDE DE LECTURE

Ce document vise des audiences diverses et peut sembler volumineux. Voici un guide de lecture selon votre profil :

Si vous êtes expert en architecture, vous pouvez lire seulement les chapitres 2 et 3, et les paragraphes 5.3 et 5.4.

Si vous êtes membre d’une maîtrise d’ouvrage ou d’une équipe projet :

• Si une remise à niveau architecturale vous semble nécessaire, lisez d’abord le chapitre 4, et des éléments du chapitre 5 selon vos sujets d’intérêt, avant de lire les chapitres 2 et 3.

• Si vous chercher une aide pour un projet précis, identifiez son type d’après le chapitre 2 et allez directement au paragraphe approprié dans le chapitre 3.

Si vous souhaitez lire l’ensemble du document, commencez par les chapitres 4 et 5, puis continuez par les chapitres 2 et 3. Cet ordre des chapitres, qui peut paraître paradoxal, a été choisi pour éviter de présenter d’emblée aux lecteurs experts des considérations générales qui risquent de leur sembler trop évidentes.

(4)

2 - TYPOLOGIE APPLICATIVE ET CRITERES

Ce chapitre propose une description de la façon d’organiser les architectures applicatives et une série de critères pour les analyser.

2.1 - TYPOLOGIE

La typologie utilisée est pragmatique, destinée à être pertinente non seulement pour les architectes des systèmes informatiques mais également pour les maîtrises d’ouvrage et les chefs de projet.

Bien sûr, certains projets imposent de mettre en œuvre plusieurs de ces types de façon cohérente (par exemple, un web interactif et une gestion documentaire, éventuellement intégrés dans une architecture de type collaboratif). C’est le travail d’un architecte de projet d’établir cette cohérence.

• Catégorie Web Interactif : il s’agit d’applications où l’utilisateur interagit avec un serveur Web, que ce soit en intranet ou en internet, pour accéder à des données ou des services. L’interaction est personnalisée et ne se limite pas à la recherche d’information classique traitée dans la catégorie publication.

o Web interactif non critique : non critique en matière d’argent, de vies humaines ou de réputation mise en jeu ;

o Web interactif critique : critique d’après les mêmes critères ; se caractérise souvent par la présence de transactions ;

o Mainframes webisé : une application mainframe traditionnelle exportée sur intranet ou internet ;

o Transactionnel 3-tier webisé : une application transactionnelle exportée sur intranet ou internet ;

o Client lourd/serveur webisé : une application client lourd traditionnelle exportée sur intranet ou internet.

Les trois dernières architectures, qualifiées de « wébisées », couvrent les applications patrimoniales (legacy) existantes, hétérogènes et le plus souvent anciennes mais au cœur du dispositif. De plus, il n’est souvent pas souhaitable de les retoucher sauf sous forme de maintenance applicative.

• Catégorie Publication : il s’agit pour l’essentiel de « pousser » de l’information vers l’utilisateur, en le guidant au mieux :

o Web : Intranet & Internet « classique » - les vitrines des organisations ; o Gestion de documents « en grand » : sites de journaux, évènements … ; o Streaming son/vidéo : applications avancées comme par exemple celle de

« La Villette ».

• Catégorie Décisionnel : les applications permettant de prendre des décisions en analysant un historique de données et de services.

• Catégorie Collaboratif : les applications permettant une meilleure efficacité du travail en groupe :

(5)

o Groupware ; o Pair à pair ;

o Workflow documentaire.

• Catégorie PGIs* : une analyse de l’architecture actuelle et de la stratégie technique des principaux acteurs du marché mondial est effectuée.

• Catégorie intégration applicative : intégrer les applications peut être considéré comme une sorte de méta application. En particulier le programme du BPM*

(Business Process manager) est une application :

o Ad-hoc (spaghetti) : style d’intégration inclus dans les applications, o EAI « classique » : produits d’EAI du marché,

o Web Services / XML : EAI émergente à base de technologies Services Web.

2.2 - CRITERES D’EVALUATION

Chaque architecture est évaluée selon des critères généraux mais aussi par rapport à sa capacité à implémenter facilement les recommandations actuelles ou à venir du Cadre Commun d’Interopérabilité des systèmes d’information publics.

2.2.1 - Critères généraux

Certains critères nécessitant une explication plus longue sont développés dans les paragraphes qui suivent.

• Coûts : une architecture applicative donnée induit des coûts d’achat et des coûts de possession. Elle induit aussi des retours sur investissement et a donc un impact économique. Ce point trop contextuel ne sera pas abordé ici.

Les coûts d’achat comprennent les licences de logiciel et les coûts induits en matériel et formation.

Les coûts de possession comprennent le support logiciel, l’administration et la maintenance de l’application.

• Flexibilité : ces critères caractérisent la facilité avec laquelle l’architecture applicative peut s’adapter à des changements au niveau des besoins, que ce soit sur le plan fonctionnel ou sur le plan non fonctionnel :

o Extensibilité (Scalabilité) en performance (voir 2.2.2 - ), o Evolutivité fonctionnelle,

o Capacité à intégrer de nouveaux standards, o Richesse des environnements de développement ;

• Robustesse : ces critères caractérisent la résistance de l’architecture applicative aux erreurs de toute nature :

o Robustesse intrinsèque du logiciel et des outils associés,

o Robustesse extrinsèque vis à vis des pannes de l’environnement, des fautes des utilisateurs ou des administrateurs,

o Sécurité : capacité à s’intégrer et à étendre le cadre de sécurité global du système,

(6)

o Haute disponibilité : capacité à gérer des réplications pour la tolérance aux pannes ;

• Pérennité : ces critères sont liés au fournisseur et au logiciel : o Présence du fournisseur, éventuellement internationale,

o Parts de marché du logiciel (en effet, la pérennité du fournisseur ne suffit pas, il peut décider d’abandonner un produit);

Ces points induisent naturellement la création d’un écosystème avec des tierces parties (formation, TMA, hébergement) et des compétences disponibles sur le marché du travail.

• Implémentation J2EE / .NET / LAMP : capacité à implémenter l’architecture avec une de ces trois technologies

L’ensemble des critères généraux est repris dans le tableau en 2.2.4 - . 2.2.2 - Critère d’extensibilité (scalabilité) en performance

L’infrastructure matérielle se caractérise sommairement par ses capacités en terme de puissance processeur, mémoire et entrées/sorties. La capacité processeur a une interaction importante avec l’architecture. La capacité mémoire a également un impact, car certaines applications ne savent pas exploiter des capacités mémoire supplémentaires, mais cet impact est moindre. Il y a 3 dimensions possibles de scalabilité en terme de puissance CPU :

• Puissance intrinsèque du CPU, c’est à dire sa fréquence, son architecture et ses caches : cet aspect n’a pas d’interaction avec l’architecture applicative ;

• Multiprocesseur symétrique SMP* : ajout de processeurs qui se partagent la mémoire (NUMA* n’est qu’une variante de SMP) ;

• Grappe (ou cluster, ou MPP*) : ajout des nœuds reliés entre eux par un réseau de communication.

Pour pouvoir exploiter correctement une augmentation de performance dans les dimensions SMP ou cluster, il faut bien sûr que les éléments logiciels sous-jacents soient eux- même scalables dans cette dimension ; ceci est particulièrement vrai pour l’OS, la base de données et le serveur applicatif. C’est également vrai pour l’application elle-même, mais ceci sort du cadre de l’étude puisque maîtrisé par le concepteur de l’application : par exemple, le modèle proposé par le serveur applicatif peut être potentiellement parallèle (multithread*), mais

l’application force un déroulement séquentiel. On n’améliore pas les temps de réponse avec du SMP dans un tel cadre.

Google : un exemple de scalabilité cluster exemplaire : le moteur de recherche Google est implémenté par une gigantesque grappe de plus de 10 000 machines Linux. Ceci est efficace car l’algorithme de recherche de Google est écrit pour ce mode de fonctionnement. Un autre moteur de recherche avec un autre algorithme pourrait être tout a fait inefficace sur la même

architecture. Pourtant le service rendu au client est le même !

Pour chaque architecture sera décrite sa capacité à exploiter les dimensions SMP et cluster. Une règle générale est que la dimension SMP est plus facile à exploiter et

(7)

son rendement relativement indépendant de la programmation de l’application ; par contre, le rendement de la dimension cluster est extrêmement dépendant de la nature de l’application. Malheureusement, la croissance dans la dimension SMP est plus chère car les gros multiprocesseurs (8, 16, 32 processeurs) sont plus chers « au ktpmC* » que les petites machines (typiquement mono, bi ou même quadri processeurs).

2.2.3 - Critères relatifs au CCI

Le CCI Version 1 recommande un certain nombre de standards ; certains sont pertinents vis à vis des architectures applicatives.

Certains standards sont à l’état de candidat dans le CCI Version 1. Ils sont listés en italique. Le CCI Version 2 proposera d’autres standards, listés ici de manière spéculative, également en italique.

Sont listés ci-dessous les standards et leur possible impact applicatif ; « néant » ou « Minime » signifie que l’architecture applicative est pas ou peu concernée par le standard. Soit il s’agit d’un standard d’infrastructure, soit l’impact est lié à la programmation de l’application et pas à son architecture.

Standard Définition Impact applicatif

CCI Version 1

IP V4 V6 Protocole de transport et de réseau Capacité à communiquer sur une socket HTML Langage de présentation des

données sur un navigateur Capacité à produire du HTML DNS Serveur de noms de domaines Néant

SMTP MIME S/MIME

Protocole et formats d’échange de mél

Capacité à échanger du mél MIME et S/MIME

FTP Protocole d’échange de fichiers Minime

LDAP Format et protocole d’annuaire Capacité à consulter l’annuaire SSL Protocole de transfert sécurisé au

niveau du transport Capacité à communiquer sur une socket

« secure »

PKI, X.509 Certificats à clef publique Capacité à utiliser X.509 pour l’autorisation et l’authentification

Accessibilité Faciliter l’accès aux handicapés Minime, c’est la programmation, pas l’architecture qui est impactée

XML, XSL

XMLSchema Langage de description de données

et de meta-données Capacité à manipuler et produire du XML, conformément à des XMLSchemas

SOAP

WSDL Transport applicatif de XML

Langage de description d’interface Capacité à produire et consommer des services Web

UDDI Annuaire pour les services Web Capacité à découvrir et publier des services Web

Formats et SGML, MPEG, GIF … Minime, c’est la programmation, pas

(8)

supports l’architecture applicative qui est impactée

CCI Version 2 (Propositions)

Composant Standard Tiers

concernés Vers

ion Etat du

std. Commentaires Typologie et critères

Standards trans-architectures

RPC universel SOAP surtout

métier 1.1 A faire La version 1.2 proposée par le W3C n’est pas stabilisée Langage de description

d’interface WSDL surtout

métier

1.1 " " " "

Annuaire de services UDDI surtout métier

2.03 " Un annuaire UDDI n’est pas indispensable

Meta données XML XML

Schema tous 1.0 " Nécessaire à l’encodage WSDL Sécurité : confidentialité et

authentification mutuelle

SSL TLS X.509

tous 3.0

1.0 " Schémas d’encryption de SOAP

sur https

Authentification service et client Profil d’utilisation des Services

Web Basic

profile tous 1.0 " Emane de ws-i.org, récent (Octobre 2002)

Standards J2EE

Framework J2EE J2EE tous 1.3 "

Composant de présentation JSP présentation 1.2 "

Composant de présentation Servlet présentation 2.3 "

Composant métier EJB métier 2.0 "

Messagerie JMS métier 1.0.2 "

Accès SGBDR JDBC métier

données 2.0 "

Accès mainframes & PGIs J2EE Connector

métier données

1.0 " Abusivement, JCA

Communication entre

composants RMI/IIOP métier 1.0 " A éviter en hétérogène ; préférer les Services Web

RPC entre composants JAX-RPC surtout

métier 1.0 " Pour accéder à SOAP en Java

La liste des standards d’interopérabilité étant longue, une synthèse a été réalisée sous la forme des 7 critères suivants :

1. HTML : capacité de génération du HTML

2. XML : capacité à produire et consommer du XML

(9)

3. Services Web : capacité à produire et consommer des Services Web 4. Composants : capacité à tirer partie de l’approche composants 5. Standards : capacité à intégrer de nouveaux standards

6. J2EE : capacité à interopérer avec le monde J2EE 7. .NET : capacité à interopérer avec le monde .NET

Dans le tableau global ci-après, ils permettront de caractériser les architectures applicatives.

(10)

2.2.4 - Liste synthétique des critères

Critère Définition Critères généraux

Coûts d’achat Coûts de possession Scalabilité performance Evolutivité fonctionnelle

Robustesse intrinsèque … du logiciel

Robustesse extrinsèque vis à vis de l’environnement

Sécurité Capacité à s’intégrer et enrichir le cadre de sécurité Développement Richesse des environnements de développement Présence du fournisseur

Parts de marché … du logiciel

Implémentation J2EE Capacité à implémenter l’architecture avec cette technologie Implémentation .NET Capacité à implémenter l’architecture avec cette technologie Implémentation LAMP Capacité à implémenter l’architecture avec cette technologie

Critères d’interopérabilité

HTML Manipulation du HTML

XML Manipulation du XML

Services Web Capacité à produire et consommer des Services Web Composants Capacité à tirer partie de l’approche composants Standards Capacité à intégrer de nouveaux standards

Interop. .NET Capacité d’interaction avec les architectures .NET Interop. J2EE Capacité d’interaction avec les architectures J2EE

Pour chaque critère et chaque architecture, une cotation sur l’échelle suivante a été attribuée :

++ : très capable + : bon

0 : neutre, ou le critère n’est pas pertinent pour cette architecture - : faible

-- : incapable

(11)

Il ne faut pas attribuer à cette approche plus de valeur qu’elle n’en a, et surtout pas additionner les + et les -. Il est plus instructif de lire la colonne commentaires.

De plus, pour les coûts, il n’a pas été attribué de cotation (qui pourrait être trompeuse), mais seulement un commentaire qualitatif. En effet, seule une analyse projet peut être menée quantitativement.

Certains critères n’ont aucun sens pour certaines architectures, vu que le modèle n’est pas orthogonal, c'est-à-dire par exemple, le critère « interopérabilité .NET » pour l’architecture « Web interactif non critique .NET ». Dans ce cas là, le critère est supprimé du tableau.

(12)

3 - ARCHITECTURES APPLICATIVES

Chaque architecture est décrite, analysée par rapport aux critères définis en 2.2 - puis illustrée par un cas d’utilisation typique, si possible dans le contexte de l’administration.

Pour chaque architecture, les standards à suivre sont définis, quand cela est pertinent.

En préalable, les deux principaux protagonistes en terme de plates-formes d’implémentation J2EE et .NET sont décrits.

3.1 - LA TECHNOLOGIE J2EE

Java 2 Enterprise Edition est le modèle de composants promu par Sun et ses partenaires pour les applications d’entreprise. Il existe d’autres modèles de composants Java plus simples, pour les applications embarquées par exemple (J2ME) ou J2SE pour le poste client, mais elles n’entrent pas dans le champ de cette étude.

J2EE est du point de vue marketing le nom phare autour duquel se structure l’affrontement économique

avec Microsoft .NET.

J2EE au sens strict est une spécification, pas une implémentation. Cette spécification est contrôlée par Sun Microsystems. Il ne s’agit donc nullement d’un standard au sens formel.

L’évolution de J2EE est régie par une charte, le Java Community Process (JCP*), qui a été négociée entre Sun et ses partenaires.

3.1.1 - Description technique La spécification J2EE définit la notion de conteneur, qui est un

objet logiciel implémentant une fonction macroscopique.

J2EE et ouverture

J2EE est généralement considéré comme un cadre plus ouvert que .NET ; néanmoins, il n’est techniquement pas impossible à Sun de reprendre plus de contrôle, puisque le JCP est la loi définie par Sun. L’ouverture de J2EE n’est paradoxalement garantie que par la relative faiblesse de Sun dans le secteur du logiciel. Les vrais poids lourds de J2EE, ceux qui ont des parts de marché et du revenu de produits et de services associé à cette technologie sont pour l’essentiel IBM, Oracle et BEA. Un Sun qui deviendrait dominant sur le marché du logiciel pourrait adopter des pratiques monopolistiques semblables à celles de Microsoft. Cette hypothèse est néanmoins très peu vraisemblable.

La certification est un bon exemple de la politique de contrôle de Sun. La certification J2EE est contrôlée par Sun et demande le passage d’une suite de vérification et le paiement de royalties liées aux interfaces. Par le biais de subtilités juridiques dans la licence Java, qui ont alimenté la querelle entre Java et le monde du libre, Sun a jusqu’à ce jour empêché la certification de produits libres J2EE.

(Néanmoins, il semble que l’évolution de JCP 2.5 rende possible en 2003 la certification J2EE 1.4 de Jonas et Jboss).

Cette certification ne doit donc pas être vue seulement comme un label de qualité technique, ce qu’elle est indubitablement, mais aussi comme un outil politico- industriel.

(13)

Client lourd Application /

Applet

Architecture logique J2EE

Client léger Navigateur

Métier Conteneur EJB o JCA

o ^{JMS …}

Présentation Conteneur Web o Servlet

o ^JSP

Données

RMI

RMI JDBC

Deux conteneurs existent de-facto :

• Le conteneur Web s’occupe de la présentation : o les servlet hébergent le code Java,

o les JSP (Java Server Pages) hébergent du HTML dynamisé par du Java.

o JDBC permet d’accéder aux données rangées dans un SGBDR

• Le conteneur EJB héberge la partie métier. Sa vertu principale est de permettre une gestion déclarative de notions complexes à programmer :

o Les sessions : le conteneur gère des beans session, avec ou sans état, qui représentent l’interaction courante du client avec le système (par exemple son caddy sur un site de e-commerce).

o Les transactions

o La persistance des objets : le conteneur gère des beans entité qui représentent les objets persistants, soit en laissant l’initiative au bean (Bean Managed Persistence, BMP) soit via un système automatique appelé CMP (Container Managed Persistence)

o Un modèle de sécurité basé sur les rôles

o Le cycle de vie des composants (activation, passivation)

o Un modèle de communication asynchrone avec les Message Driven Beans et l’API JMS

• Le protocole de communication entre beans est RMI, et plus précisément RMI/IIOP pour les interactions hétérogènes (Note : en réalité, il n’y a jamais de communication hétérogène, par exemple entre WebLogic et WebSphere, au niveau RMI).

Un point important est que le conteneur EJB n’est pas indispensable. On peut implémenter la partie métier avec le conteneur Web, JDBC pour accéder aux données et des beans Java classiques.

Ce point est un sujet de polémiques interminables dans la communauté Java :

(14)

Une école de pensée trouve que le modèle EJB est « trop compliqué » pour les choses simples, ou même trop compliqué tout court et préfère se limiter au conteneur Web agrémenté d’un pattern d’accès aux données.

L’autre école de pensée considère que le conteneur EJB fait un meilleur travail que le programmeur moyen, s’améliore dans le temps et est donc un cadre sécurisant et rentable à moyen terme, même si la courbe d’apprentissage est reconnue comme importante. En résumé, ce n’est pas le modèle EJB qui est complexe, c’est le problème des applications transactionnelles d’entreprise.

Logiquement, le conteneur EJB ne peut être utilisé que si le programmeur profite des valeurs qu’il apporte autour des transactions, de la persistance et de l’asynchronisme. Ce point doit être jugé application par application, et non pas dans l’absolu. Il est par contre regrettable de ne pas utiliser le conteneur EJB par manque de formation.

J2EE est une architecture mono langage (Java) et multi plate-formes (Windows, Linux, UNIX, OS/390).

3.1.2 - Le « standard » J2EE 1.3

J2EE n’est pas un standard en soi, mais un ensemble de standards ayant leur cycle de vie propre. A un instant donné, un ensemble cohérent est baptisé

« J2EE version x.y » :

La dernière version publiée est J2EE 1.3 (Automne 2001) qui contient l’ensemble d’APIs suivants (par ordre alphabétique) :

• EJB (Enterprise JavaBeans) 2.0

• JAAS (Java Authentication and Authorization Service) 1.0

• JavaMail 1.1

• Java RMI (Remote Method Invocation) 1.0

• JAXP (the Java API for XML Processing) 1.1

• JDBC (Java Database Connectivity) 2.0

• JMS (Java Message Service) 1.0.2

• JNDI (Java Naming and Directory Interface) 1.2

• JSP (JavaServer Pages) 1.2

• JTA (Java Transaction API) 1.0.1

• J2EE Connector Architecture 1.0

• RMI/IIOP (Internet Inter-ORB Protocol) 1.0

• Servlets 2.3

La prochaine version, J2EE 1.4, est depuis Août 2002 à l’état de « final draft ». Les évolutions sont centrées autour des points suivants :

• Support des Services Web : JAX-RPC, JAXR, SAAJ

• Support de XML : JAXP

• Management : JMX

• EJB 2.1

• JCA 1.5

(15)

La spécification J2EE est implémentée par de nombreux acteurs dans le monde commercial et dans le monde du libre.

3.1.3 - Produits commerciaux certifiés J2EE

Il y a 11 vendeurs certifiés J2EE 1.3 en Novembre 2002 : 1. BEA, WebLogic : le leader du marché

2. Borland, Enterprise Server 3. Fujitsu, Interstage

4. IBM, WebSphere : le challenger, pas loin derrière BEA 5. Macromedia, Jrun server

6. Oracle, 9iAS

7. Pramati, Pramati Server 8. Silverstream eXtend

9. SunOne Application Server 7

10. Sybase, Enterprise Application Server 11. Trifork, Enterprise Application Server

Certains produits sont « en avance » sur J2EE, par exemple implémentent déjà la spécification EJB 2.1.

Une synthèse souvent bien à jour est disponible sur Internet : http://www.flashline.com/components/appservermatrix.jsp

3.1.4 - Produits commerciaux non certifiés J2EE 1.3 Cette liste n’est pas exhaustive:

• Caucho, Resin-EJB

• HP, HP-AS

• Hitachi, Cosminexus

• Iona, J2EE Technology

• Ironflare, Orion

• Sun, SunOne Application Server 3.1.5 - Produits libres

• Apache + Tomcat 4.1 : cet ensemble ne gère que le conteneur Web, donc les standards suivants : servlet 2.3, JSP 1.2, JDBC 2.0

• Jboss (+Apache + Tomcat) : Jboss est le conteneur EJB le plus répandu dans le monde du libre. Il implémente les standards suivants : EJB 2.0, servlet 2.3, JSP 1.2, JDBC 2.0

• Objectweb Jonas (+Apache + Tomcat) : Jonas est une technologie d’origine Bull, donnée au consortium objectweb. JonAS 2.6 supporte J2EE 1.3 y compris EJB 2.0 (sauf CMP), JTA 1.0.1, JDBC 2.0, JCA 1.0, JMX 1.0, JNDI 1.2.1, JMS 1.1, JavaMail 1.3, Servlet 2.3, JSP 1.2.

(16)

3.2 - LA TECHNOLOGIE .NET

.NET est une marque de Microsoft, un qualificatif pour les produits Windows et Visual Studio, Visual Basic, ASP, ADO …, mais ni une spécification, ni un standard formel. C’est néanmoins un facteur majeur sur le marché pour l’architecture applicative.

Du fait de la polysémie de .NET, il est important de préciser ce dont il est question.

.NET n’est pas le nouveau nom de DCOM ou de MTS. C’est un nouveau modèle de programmation, sensiblement différent du modèle traditionnel de Microsoft, avec des stratégies et des outils de migration.

Dans ce document, .NET désigne donc les applications écrites nativement avec VisualStudio.NET en C# ou en VisualBasic.NET. C# est un langage objet très similaire à Java. VB.NET est une évolution très significative de Visual Basic vers l’objet.

Ces applications sont ensuite exécutées sur Windows 2000 avec un certains nombre de compléments (.NET SDK), et prochainement sur Windows .NET, la nouvelle version serveur de Windows.

3.2.1 - Description technique

L’architecture de .NET se caractérise par rapport à J2EE, entre autre, par son aspect multi langages (C#, VB, …) et mono plate-forme (Windows).

SOAP

Client mi-léger WinForms

Architecture logique .NET

Client léger Navigateur

Métier

o COM o COM+

(MTS)

Présentation Web

o ASP.NET o WebForms

Données

SOAP

ADO.NET

Les services sont très similaires à ceux de J2EE, sauf que .NET n’a pas de beans entité.

.NET utilise intensivement les protocoles Services Web (SOAP et WSDL) pour la communication entre les composants .NET, que ce soit en distribué ou en local. Des optimisations de performance sont faites en homogène .NET et en local, par rapport à une communication vers d’autres univers.

L’essentiel de l’innovation .NET porte sur la partie frontale et le modèle global de communication et de distribution. Pour la partie métier (l’équivalent du conteneur EJB), .NET s’appuie fortement sur le moniteur transactionnel MTS et sur la persistance ADO.NET pour l’accès aux données relationnelles.

(17)

3.2.2 - Implémentation

Il n’existe bien sûr qu’un seul .NET, celui de Microsoft, actuellement disponible sur Windows 2000 et en natif sur Windows .NET. La date de GA (General Availability) de Windows .NET est prévue en début 2003. Ceci montre la relative jeunesse de la plate-forme .NET, bien qu’il soit puisse de faire du .NET soit avec Windows 2000 soit avec les pre-releases de Windows .NET.

Il existe un projet d’émulation de .NET en libre, MONO. L’opinion des auteurs de ce projet est assez partagée. Certains experts disent qu’il est quasiment impossible de faire le « reverse engineering » d’une architecture aussi évoluée que .NET sans la complicité de Microsoft et d’autres pensent que ce projet est prometteur et qu’il commence à donner des résultats. Il ne faut pas comparer cela à SAMBA par exemple qui a réussi sur le segment très bien défini d’un système de fichiers distribué.

3.2.3 - Microsoft et les standards

Avec l’apparition du Web et les conséquences du procès anti-trust, l’attitude de Microsoft face aux standards a beaucoup évolué. La compagnie contribue maintenant très valablement à l’émergence d’un certain nombres de standards importants, soit en les implémentant dans Windows, soit en les proposant pro- activement à la communauté informatique :

o HTML, XML, LDAP,

o Services Web : SOAP, WSDL …

3.3 - CATEGORIE WEB INTERACTIF

3.3.1 - Web interactif non critique 3.3.1.1 - Le besoin

Il s’agit de fournir un accès Web en Intranet ou en mode Internet à une application interactive. L’application n’est pas critique au sens que ni des sommes considérables ni la réputation de l’organisation ne sont en jeu si l’exploitation s’arrête quelques heures. De plus les performances exigées ne sont pas aux limites de la technologie en terme de débit ou de temps de réponse.

Un besoin similaire existe quand l’approche peut être qualifiée d’opportuniste ; il s’agit de tester rapidement la validité d’un concept avant de le déployer de manière systématique et pérenne.

3.3.1.2 - L’architecture

C’est une architecture 3-tier classique avec un client Web léger.

3.3.1.3 - Les implémentations et leurs parts de marché Trois variantes sont possibles : LAMP, J2EE/libre et .NET.

(18)

• LAMP : c’est un acronyme désignant de manière synthétique un système tout en logiciel libre, avec Linux comme OS, Apache comme serveur Web, MySQL comme SGBDR et PHP, Perl ou Python comme langage de programmation. Les serveurs sont des machines Intel mono ou bi- processeurs.

Il existe des variantes où Oracle est utilisé comme SGBD, souvent dans des grands comptes avec des licences site Oracle au niveau du groupe. On trouve aussi parfois, mais très rarement, PostgreSQL comme SGBD en libre. Il est généralement admis que PostgreSQL est plus proche d’un

« vrai » SGBDR que MySQL en termes de propriétés ACID*.

Très rarement, on observe une sous-espèce « AMP sur UNIX », souvent en réutilisation de serveurs UNIX un peu anciens.

• J2EE/libre : variante Java de la précédente, tout en logiciel libre, avec Linux comme OS, Apache + Tomcat comme serveur Web, MySQL comme SGBDR et Java comme langage de programmation. Les serveurs sont des machines Intel. Il peut parfois être utile d’ajouter un conteneur EJB comme Jonas ou Jboss.

• .NET : architecture tout Microsoft avec Windows 2000 ou .NET comme OS, IIS comme serveur Web, VisualBasic, C++, VisualBasic.NET ou C#

comme langage et SQLserver comme SGBDR. Les serveurs sont des machines Intel.

En se basant sur les analyses de Netcraft (www.netcraft.com) LAMP+J2EE/libre possède 2/3 du marché et .NET 1/4. Microsoft est plus avantagé à l’intérieur des entreprises. Il est difficile de départager LAMP et J2EE/libre, sans doute autour de 45% pour LAMP et 20% pour J2EE/libre. Le J2EE commercial est minoritaire sur ce segment.

3.3.1.4 - Standards associés

Dans tous les cas : HTML, DHTML

• LAMP : à la mode du libre

• J2EE/libre : servlet, JSP, JDBC, parfois EJB et JMS

• .NET : à la mode Microsoft 3.3.1.5 - Analyse multi critères

Elle est différente dans les trois cas :

(19)

LAMP

Critère Commentaires

Critères généraux

Coûts d’achat logiciel gratuit, matériel peu coûteux Coûts de possession variables selon compétences du client Scalabilité performance 0 Faible en SMP (2-CPU), bonne en cluster Evolutivité fonctionnelle 0 Ad-hoc

Robustesse intrinsèque + OK pour .coms

Développement 0 Faible (évaluation sujette à polémiques) Robustesse extrinsèque 0 raisonnable

Sécurité + raisonnable

Présence du fournisseur ++ partout et nulle part

Parts de marché ++ les .com, autour de 50% sur Internet Critères d’interopérabilité

HTML ++ C’est fait pour ça

XML ++ Xerces, Xalan, expat

Services Web ++ Axis

Composants 0 Peu structuré

Standards + Souple

Interop. J2EE + Services Web Interop. .NET + Services Web

(20)

J2EE Libre

Critère Commentaires Critères généraux

Coûts d’achat logiciel gratuit, matériel peu coûteux Coûts de possession variables selon compétences client Scalabilité performance + Faible en SMP (2-CPU), bonne en

cluster Evolutivité fonctionnelle ++ composants Robustesse intrinsèque + raisonnable Robustesse extrinsèque 0 raisonnable

Sécurité + raisonnable

Développement + Ateliers Java Présence du fournisseur ++ partout et nulle part Parts de marché + Autour de 15% sur Internet

Critères d’interopérabilité HTML ++ C’est fait pour ça

XML ++ Xerces, Xalan

Composants ++

Standards + Processus JCP Services Web ++ Axis

Interop. J2EE ++ Conteneur Web Interop. .NET + Services Web

(21)

.NET

Critère Note Commentaires Critères généraux

Coûts d’achat logiciel peu cher, matériel peu cher Coûts de possession facile à développer et opérer Scalabilité performance + Raisonnable, SMP, grappe Evolutivité fonctionnelle +

Robustesse intrinsèque - Attendons les preuves avec Windows .NET Robustesse extrinsèque 0

Sécurité -- Attendons les preuves avec Windows .NET Développement ++ Reconnu comme un des meilleurs

Présence du fournisseur ++ Incontournable

Parts de marché ++ Elevées, 50% globalement Critères d’interopérabilité

HTML ++ Natif

XML ++ Natif

Composants ++ Architecture composants Standards - Selon la stratégie business de Microsoft Services Web ++ Natif

Interop J2EE 0 Services Web Interop .NET ++ Natif

3.3.1.6 - Outils et méthodes associés

Il est rare que des méthodes très formelles soient mises en œuvre. XP (eXtreme Programming) est parfois utilisé pour « aller vite ». Pour la gestion de configuration, CVS est presque toujours présent en libre, Visual SourceSafe avec .NET.

• LAMP : Pour la programmation en PHP ou Perl, l’éditeur emacs est très populaire ; les programmeurs du libre utilisent peu les outils enveloppants.

Beaucoup sont des experts et peuvent s’en passer ; ceci induit une approche élitiste qu’il faut prendre en compte en adoptant ces outils.

ZEND développe un ensemble d'outils autour du langage PHP, comprenant notamment un environnement de développement, un optimiser, un cache logiciel ainsi qu'une solution de protection contre l'utilisation abusive du code de l'application.

L’utilisation de modélisations UML dépend de la culture des groupes de

(22)

développeurs (Mozilla, KDE modélisés en UML) plutôt que de la culture générale du monde du libre.

Même si la partie Web est codée en PHP ou Perl, la logique métier reste souvent codée en C ou en C++ avec des outils libres comme Kdevelop (C/C++), QtDesigner (C/C++) ou Glade ( C ).

• J2EE/libre : Sun Forte for Java (version gratuite) ou Borland Jbuilder. En amélioration, encore plus complexe que .NET

• .NET : Visual Studio.NET, de l’avis général un des meilleurs environnements de programmation, surtout pour les programmeurs moyens.

3.3.1.7 - Cas d’utilisation

Gestion des résidences de vacances d’un ministère, accessible soit par des agents en Intranet, soit par les fonctionnaires et retraités via Internet. Le choix d’architecture est approprié du fait des propriétés ci-dessous liées à l’application et à l’environnement hypothétique :

• Enjeux financiers faibles

• Base de données en lecture principalement

• Scalabilité en mode grappe facile

• Compétences sur le libre disponibles sur site (sinon hébergement) 3.3.2 - Web interactif critique

3.3.2.1 - Le besoin

Une application Web est critique quand une panne entraîne des pertes considérables en argent ou en image pour l’organisation qui la met à la disposition de ses clients ou de ses usagers. Un autre critère est le débit exigé.

Plus techniquement, un très grand nombre de transactions par minute, des impératifs forts d’intégrité transactionelle ou de disponibilité (Xx24 Yx7) sont des indicateurs de criticité.

Ces applications peuvent être qualifiées aussi de « systématiques » (par opposition à « opportunistes »), dans la mesure où l’organisation investit pour plusieurs années dans une architecture applicative : la pérennité et l’évolutivité à long terme sont cruciaux.

Les impératifs de performance et de transaction limitent le choix à des architectures n-tier avec frontal Web.

3.3.2.3 - Les implémentations et leurs parts de marché

L’architecture J2EE répond bien à l’ensemble de ces besoins. (Voir 3.1 - ).

Les architectures de type LAMP sont a priori peu crédibles sur ce segment, par manque de robustesse et de scalabilité SMP.

Il y a alors quelques questions critiques à analyser :

• J2EE est il une technologie assez mûre pour ce segment ?

(23)

• J2EE en libre est il crédible sur ce segment ?

• .NET est il une alternative crédible ?

• Si J2EE est choisi, sur quelle infrastructure ? Ces différents points sont abordé ci-dessous :

Maturité de J2EE

Les facteurs positifs sont la réputation et la compétence des acteurs engagés derrière ce standard (BEA, IBM, Oracle …), le fait d’avoir un historique de 2 ans à peu près, et les références existantes.

Les facteurs négatifs sont une relative rareté de très grands sites transactionnels en « pur J2EE ». (Souvent, J2EE sert de frontal à un transactionnel plus ancien comme Tuxedo ou CICS) et une réputation de complexité du standard.

Devant l’absence de challenger crédible à court terme, J2EE est le choix le plus réaliste, et relativement peu risqué si on s’entoure des compétences nécessaires.

Il semble d’une prudence excessive de lancer en 2003 un projet nouveau sur CICS ou Tuxedo.

Crédibilité de J2EE en libre

Plus précisément, il s’agit de savoir si le frontal Tomcat et le dorsal EJB Jonas ou Jboss a les qualités de scalabilité, de robustesse et de sécurité requises.

Certaines applications récentes avec plusieurs milliers d’utilisateurs donnent à penser que cette offre évolue dans la bonne direction.

Crédibilité de .NET

.NET est une architecture très attrayante sur le papier, beaucoup plus que ses prédécesseurs DNA ou DCOM. Mais cette architecture est très nouvelle, Microsoft n’a pas un historique très convaincant sur les applications critiques, son modèle économique n’est pas centré sur ce segment et enfin ses produits n’ont pas démontré de scalabilité sur les grands SMP indispensables aux bases de données à fort débit transactionnel.

Tous ces facteurs militent pour la prudence. Les sondages plus ou moins formels faits par les analystes tendent à montrer que la majorité des clients penche pour J2EE pour le serment concerné

J2EE sur quelle plate-forme ?

Le choix s’articule autour d’UNIX, Windows de Microsoft et zOS (ex OS/390 ex MVS) d’IBM. UNIX est le choix le plus « naturel » car les OS UNIX sont robustes, les machines scalables et le rapport prix-performance raisonnable.

Windows, permet d’améliorer en apparence le prix performance grâce au prix des serveurs Intel. La robustesse en souffrant, il n’est pas démontré que le coût de possession soit meilleur.

IBM promeut le concept de J2EE sur zOS avec le produit WebSphere. Cette approche présente un intérêt pour les clients ayant un fort investissement opérationnel sur les zSeries. Le rapport prix-performance est moins bon, le coût de possession dans l’absolu est supérieur, mais dépend de l’environnement. Il ne

(24)

faut pas oublier que les SMP UNIX sont plus puissants actuellement (puissance transactionelle en tpmC) que les SMPs zSeries.

Une fois donc J2EE identifié comme architecture, reste à choisir une implémentation. Les 2 leaders du marché, pratiquement à égalité sont IBM et BEA, avec plus de 30% de parts de marché :

• BEA WebLogic est numéro 1, très prisé par les développeurs. Très souvent associé à Oracle, parfois avec DB2 ou Sybase pour le tier données,

• IBM WebSphere est numéro 2 juste derrière, très souvent avec DB2, parfois avec Oracle ou Sybase. (Toujours avec DB2 sur zOS),

• Oracle iAS, avec moins de 10%, est tiré par la domination d’Oracle sur le tier bases de données,

• SunOne, avec moins de 10%,.

• Les autres acteurs sont petits et très menacés car le segment des serveurs d’application J2EE est en forte consolidation.

Le point clef est de respecter le standard J2EE et de ne pas utiliser les extensions propriétaires des différents vendeurs. Les standards J2EE sont définis en 3.1.2 - L’aspect Java Connector Architecture est particulièrement important car la connexion avec des systèmes patrimoniaux ou des PGIs est presque indispensable.

3.3.2.5 - Analyse multi critères

(25)

Coûts d’achat Moins cher que le TP 3-tier propriétaire, souvent associé à UNIX qui est relativement coûteux

Coûts de possession Compétences maintenant largement disponibles ; plus cher que .NET néanmoins

Scalabilité

performance ++ Fonctionne sur les plus gros SMP et possède des modes cluster sophistiqués Evolutivité

fonctionnelle ++ Approche composant Robustesse

intrinsèque + J2EE n’est pas encore aussi robuste que les transactionnels classiques qui ont 10 ans de maturité

Robustesse

extrinsèque ++ Modes haute disponibilité évolués

Sécurité + Conforme aux standards du monde « culturel » UNIX Développement ++ Vaste gamme d’ateliers Java

Présence du

fournisseur ++ Les vendeurs sont des poids lourds de l’industrie ; les prestataires de service nombreux

Parts de marché ++ BEA + IBM + Oracle … Implément. J2EE ++ Etudié pour

Implément LAMP -- Inapproprié Implément. .NET 0 Selon les cas

Critères d’interopérabilité

HTML ++ OK

XML ++ OK

Services Web ++ Encapsulation automatique des objets Java en SOAP/WSDL Composants ++ Architecture composants

Standards ++ Processus JCP très ouvert Interop. .NET 0 Via les services Web

Interop. J2EE + Natif ; mais l’interopérabilité entre implémentations est mauvaise (RMI/IIOP).

Préférer les Services Web.

La « verbosité » du modèle J2EE augmente l’intérêt des ateliers logiciels spécifiques. Les ateliers logiciels J2EE les plus répandus sont :

• Borland Jbuilder : cible aussi bien WebLogic que WebSphere ; c’est le favori des développeurs en France,

• IBM WSAD (WebSphere Studio Application Developer),

(26)

• Oracle Jdeveloper : pour iAS,

• SunOne Forte for Java (ex Netbeans).

Pour la modélisation en amont, UML est populaire avec des méthodes itératives de type UP (Universal Process) comme RUP de Rational. En France, certains utilisent aussi Merise qui est assez peu adapté à l’approche objet.

Il existe par ailleurs une problématique générale de mapping objet - relationnel pour les données persistantes. Selon les écoles de pensée, on peut s’en remettre aux outils automatiques, en particulier avec le CMP* de EJB 2.0, ou il vaut mieux le contrôler « à la main » en mode BMP.

3.3.3 - Mainframes wébisés 3.3.3.1 - Le besoin

Les applications mainframe rendent des services critiques et hébergent une source très importante de règles métier et de bonnes pratiques. Il est souvent pas rentable de les porter à iso-fonctionalités sur des environnements différents. Il est plus opportun de les frontaliser par des serveurs dédiés aux fonctions de type Web, pour la présentation et parfois pour de nouvelles règles métier.

Historiquement on eut lieu une phase de simple émulation de terminaux mainframes dans un navigateur, puis de rhabillage HTML ; ces approches ont rencontré des limites et il est apparu plus avantageux pour les applications mainframes correctement architecturées, c’est à dire où présentation synchrone et transactions étaient correctement séparées, de situer l’interface avec le mainframe au niveau de la visibilité métier.

Les mainframes exposent très rarement leurs données en direct. Le plus souvent, ces données sont encapsulées dans des transactions métiers, comme « créer un nouveau client ». Il s’agit donc de donner accès à ces transactions à partir de l’univers du Web. Les deux principaux fournisseurs de mainframe du marché (IBM et Bull) ont choisi J2EE comme frontal privilégié, tout en fournissant aussi des adaptateurs pour .NET mais sans les pousser.

La norme de connexion est Java Connector Architecture (souvent raccourcie par erreur en JCA).

Protocole J2EE

Serveur

J2EE ^Java

Connector Protocole propriétaire

Mainframe

(27)

En France, mainframe veut dire IBM ou Bull. Les stratégies des deux constructeurs sont fondamentalement différentes :

Bull GCOS8 et GCOS7

Bull recommande de ne plus toucher aux applications sur GCOS sauf pour la maintenance et de ne pas développer de nouveaux modules dans cet environnement. Des environnements capables de traiter Java, HTML ou XML n’existent donc pas en natif sous GCOS (sauf marginalement sur GCOS7).

La stratégie recommandée est de frontaliser la machine GCOS par un serveur Escala avec WebLogic. Tous les traitements HTML, XML, Java sont faits dans cet environnement avec les outils J2EE. La connexion à GCOS 7 (TDS) ou GCOS 8 (TP8) se fait par un connecteur au standard JCA ; Bull a été en avance sur cette norme et participe à la définition de la norme, encore en progression.

JCA étant une norme, il est possible techniquement (mais pas commercialement) de disposer des connecteurs GCOS sur d’autres serveurs J2EE.

IBM zOS

IBM recommande également de ne plus toucher aux applications sur CICS ou IMS sauf pour la maintenance et de ne pas développer de nouveaux modules dans cet environnement. Il est recommandé de traiter HTML, XML et java sur WebSphere. La connexion se fait via JCA et des connecteurs JCA pour CICS et IMS sont disponibles chez IBM.

Pour faire fonctionner WebSphere, le choix est possible : soit sur un frontal pSeries sous AIX, soit sur zOS dans l’environnement d’émulation UNIX de ce système d’exploitation. Le client choisit selon sa stratégie HW et ses compétences.

Comme pour « Web interactif critique », voir 3.3.2.4 - en insistant particulièrement sur Java Connector Architecture.

(28)

Coûts d’achat modèles de prix Mainframe Coûts de possession modèles de prix Mainframe Scalabilité performance +

Evolutivité fonctionnelle - Difficile , accès aux compétences Robustesse intrinsèque ++ qualité mainframe

Robustesse extrinsèque ++ qualité mainframe

Sécurité ++ qualité mainframe

Développement 0 via Java, sinon assez anciens Présence du fournisseur 0 selon le constructeur Parts de marché + selon le constructeur Implément. J2EE ++ c’est le choix favori

Critères d’interopérabilité

HTML 0 indirectement via Java XML 0 indirectement via Java Services Web 0 indirectement via Java Composants - indirectement via Java

Standards -- Réactivité moyenne

Interop. .NET + des produits existent Interop. J2EE ++

Les mêmes que pour « Web interactif critique », voir 3.3.2.6 - .

3.3.4 - Transactionnel 3-tier webisé 3.3.4.1 - Le besoin

Un système de production en transactionnel 3-tier nécessite un accès Web avec une présentation remodelée et des fonctions supplémentaires. En dehors des mainframes traités en 3.3.3 - , ces environnements ont presque exclusivement sur UNIX et en pratique avec BEA Tuxedo, IBM CICS ou compatible CICS comme Unikix (racheté par Sun), ou TopEnd de NCR (racheté par BEA). Il existe aussi un modèle CORBA ou des modèles de serveurs d’application 3-tier non J2EE.

(29)

Le choix des vendeurs ci-dessous repose sur une frontalisation J2EE. On est donc ramené à un problème très similaire à celui du Mainframe, avec un connecteur Java Connector dédié au transactionnel patrimonial.

BEA propose une connexion WebLogic – Tuxedo. Les « services » Tuxedo apparaissent comme des composants J2EE et il est donc possible de les utiliser dans une application WebLogic sans connaître Tuxedo.

IBM propose un connecteur Java qui fonctionne de manière similaire avec CICS sur UNIX.

CORBA

Ce modèle d’architecture n’a pas connu le succès escompté dans les années 90.

Il est de-facto remplacé par J2EE pour le gros du marché. Il existe néanmoins des niches CORBA relativement vastes, en particulier dans l’industrie de Télécoms. Les vendeurs de technologie CORBA, comme IONA, prennent en douceur le virage J2EE et proposent donc une communication inter ORB* via IIOP* entre les composants CORBA et les composants J2EE.

Serveurs d’application non J2EE

Avant l’apparition du standard J2EE pour le n-tier, un certain nombre de modèles propriétaires ont vu le jour, avec des langages de type 4GL et des services d’exécution proches de ceux fournis par J2EE, même si le concept de serveur d’application n’existait pas encore. Citons par exemple Prolifics ou Forte. Les vendeurs de ces produits ont disparu, ou été rachetés ou se sont reconfigurés. Il existe en général pour les clients des solutions de migration plus ou moins facile vers J2EE. Il est certain en tout cas que continuer des développements sur ces produits ne doit pas être fait sans une analyse approfondie de la stratégie future de sortie de ces modèles applicatifs qui n’ont pas d’avenir à long terme.

Identiques au cas « mainframe wébisé », voir 3.3.3.4 - 3.3.4.5 - Analyse multi critères

(30)

Coûts d’achat Elevé Coûts de possession Elevé Scalabilité performance ++

Evolutivité fonctionnelle + Robustesse intrinsèque ++

Robustesse extrinsèque ++

Sécurité ++

Développement 0 figé

Présence du fournisseur + Parts de marché +

Implément. J2EE ++ Choix préféré des fournisseurs Implément. .NET 0 possible

Critères d’interopérabilité HTML +

XML + via Java

Services Web + via Java ou natif

Composants 0 indirectement

Standards 0 figé

Interop. .NET 0 des outils COM+ existent Interop. J2EE +

Les mêmes que pour « Web interactif critique », voir 3.3.2.6 - .

3.3.5 - Client lourd/serveur webisé 3.3.5.1 - Le besoin

Les nombreuses applications à base de clients lourds rendent des services inestimables et il est parfois irréaliste économiquement parlant d’envisager une refonte en n-tier. Comment faire pour rendre ces applications disponibles via un navigateur à moindre coût ?

Le client peut être lourd ou mi-léger.

Le modèle lourd typique est une application VisualBasic mêlant présentation et métier et accédant en ODBC à un serveur SGBDR.

(31)

Le modèle mi-léger typique est un client Oracle Forms gérant pour l’essentiel de la présentation et accédant en SQL une base de données Oracle qui gère le métier en procédures stockées.

Dans les deux cas, on ne peut ou ne veut toucher à l’application client.

La meilleure solution est alors d’exporter sur le navigateur uniquement la présentation Windows. Cette approche a été inventée par Citrix avec le protocole ICA et reprise par Microsoft avec le protocole RDP. C’est le mode client ultra- léger (pratiquement du 3270 !).

Client lourd

inchangé Serveur SGBD inchangé

Serveur existant Nouveau

Serveur Windows 2000 Client natif

ICA/RDP Navigateur + applet

ICA/RDP ICA / RDP

PCs

Le client lourd s’exécute maintenant sur un serveur Windows.

Ce modèle présente l’avantage du faible coût de mise en œuvre mais garde des contraintes importantes :

o Il est nécessaire de « valider » le fonctionnement en mode ultra-léger.

Beaucoup d’éditeurs n’autorisent pas ce mode. D’autres le promeuvent (par exemple Siebel et SAP).

o La charge réseau est fortement dépendante du style d’interface de l’application.

Citrix Metaframe a réussi à garder plus de 70% (Giga) de ce marché, en parti grâce à des fonctions supérieures à celles présentes nativement dans Windows.

Les protocoles propriétaires ICA (Citrix) et RDP (Microsoft).

(32)

Critère Note Commentaires Critères généraux

Coûts d’achat faible à modéré

Coûts de possession le principal argument de vente Scalabilité performance 0

Evolutivité fonctionnelle -- Néant Robustesse intrinsèque 0

Robustesse extrinsèque 0

Sécurité 0

Développement + besoins minimes

Présence du fournisseur + Parts de marché ++

Implément. J2EE -- Inadéquat Implément. .NET ++ Etudié pour

Implément LAMP - Tentatives inabouties Critères d’interopérabilité

HTML +

XML 0 Hors sujet

Services Web 0 Hors sujet

Composants 0 Hors sujet

Standards 0 Hors sujet

Interop. .NET 0 Hors sujet Interop. J2EE 0 Hors sujet

Ces solutions sont sans programmation. Les seuls outils sont des outils de déploiement et d’administration.

La méthode la plus pertinente est une analyse économique de coûts de possession comparés avec les solutions client lourd.

3.4 - CATEGORIE PUBLICATION

3.4.1 - Web : Intranet & Internet « classique »

(33)

3.4.1.1 - Le besoin

Les sites Web centrés sur la publication existent et continueront à exister, aussi bien sur Internet que sur Intranet. Toutes les organisations n’ont pas besoin ou ne souhaitent pas mettre en oeuvre de l’interactivité.

Il est parfois nécessaire d’avoir un niveau de personnalisation dans la présentation des informations, et quasi indispensable de proposer un moteur de recherche local.

Une architecture Web 3-tier convient parfaitement. La logique métier est inexistante et il n’est pas indispensable d’utiliser un SGBD, un système de fichiers est souvent suffisant.

Présentation HTML WML

Navigateurs Données

XML

Architecture Web de publication

Si la diffusion d’information est multi-canaux, en particulier vers des tablettes Web ou des téléphones mobiles WML, ce besoin est pris en compte par le serveur Web.

Il est recommandé mais pas toujours possible de stocker les données au format XML. Un framework de type Cocoon (pour Java) ou une librairie comme expat (pour PHP) est dans ce cas recommandée.

Selon les besoins de performance, les documents HTML et/ou WML sont générés dynamiquement à la demande ou statiquement, par exemple au moment de la publication ou chaque nuit.

Un portail peut être utile pour apporter la personnalisation si elle est nécessaire.

Le marché est partagé entre LAMP (voir 3.3.1.3 - ) pour 2/3 et Microsoft IIS pour 1/3 à peu près.

Le marché des portails commerciaux est complexe et non stabilisé. En logiciel libre, PHP-Nuke, construit sur LAMP, peut être cité.

Voir aussi Zope en 3.4.2.3 -

3.4.1.4 - Standards associés HTML, XML, http.

Il n’existe malheureusement pas encore de standard pour les portails, en particulier les modèles de portlet* sont propriétaires.