Revue et comparaison des différentes solutions

UNIVERSITÉ DE LAUSANNE
a
ÉCOLE DES HAUTES ÉTUDES COMMERCIALES
Revue et comparaison des différentes solutions
pour la programmation de pages Web dynamiques
Présenté par Giovanni Camponovo
en vue de l’obtention du
Diplôme postgrade en informatique et organisation
Année académique 2000-2001
Sous la direction du Prof. Benoît Garbinato
Institut d'informatique et organisation / BFSH1 / CH - 1015 Lausanne-Dorigny
Tél. (021) 692.34.00 / Fax (021) 692.34.05 / Internet e-mail : [email protected]
-1-
0
Table des matières
0
1
2
3
3.1
3.2
3.3
4
4.1
4.2
4.3
4.4
4.5
5
5.1
5.1.1
5.1.2
5.1.3
5.1.4
5.2
6
6.1
6.1.1
6.1.2
6.1.3
6.2
6.2.1
6.2.2
6.2.3
6.2.4
6.2.5
7
8
8.1
8.2
8.3
8.4
9
9.1
9.2
Table des matières ............................................................................................................... 2
Sujet et objectifs du mémoire ............................................................................................. 3
Résumé.................................................................................................................................. 4
Introduction : les origines du Web..................................................................................... 6
Histoire de l’informatique [1-3] ...................................................................................................... 6
Histoire de l’Internet [4-5] .............................................................................................................. 7
Histoire du World Wide Web.......................................................................................................... 8
Le World Wide Web ......................................................................................................... 10
Architecture du World Wide Web................................................................................................. 11
URL (Uniform Resource Locator) ................................................................................................ 12
HTML (HyperText Markup Language) ........................................................................................ 14
HTTP (HyperText Transfer Protocol). .......................................................................................... 16
L’évolution des besoins................................................................................................................. 18
Les pages statiques ............................................................................................................ 19
Limitations des pages HTML statiques ......................................................................................... 21
Création préalable de chaque page ............................................................................................ 21
Problèmes de mise à jour........................................................................................................... 22
Fusion du contenu et de la présentation .................................................................................... 22
Interactivité................................................................................................................................ 23
Avantages des pages HTML statiques .......................................................................................... 24
Les pages dynamiques ....................................................................................................... 26
Solutions coté client ...................................................................................................................... 27
Applets Java .............................................................................................................................. 28
Active X .................................................................................................................................... 34
Javascript et VBscript................................................................................................................ 38
Solutions coté serveur ................................................................................................................... 43
CGI (Common Gateway Interface) ........................................................................................... 45
PHP (PHP Hypertext Preprocessor) .......................................................................................... 48
ASP (Active Server Pages)........................................................................................................ 55
JSP (Java Server Pages) et Servlets Java................................................................................... 63
ColdFusion ................................................................................................................................ 69
Conclusions ........................................................................................................................ 73
Bibliographie...................................................................................................................... 83
Histoire de l’informatique et de l’Internet............................................ Erreur ! Signet non défini.
PHP................................................................................................................................................ 85
ASP................................................................................................................................................ 86
JSP................................................................................................................................................. 86
Annexes............................................................................................................................... 87
Annexe 1: Evolution de l‘ArpaNet / Internet – nombre de hôtes .................................................. 91
Annexe 1: Evolution du world wide Web ..................................................................................... 92
-2-
1
Sujet et objectifs du mémoire
Ce travail de diplôme a pour objet l’exploration du domaine de la programmation des pages Web
dynamiques, dans le but de passer en revue et de comparer les principales solutions disponibles actuellement.
Ce travail n’a pas pour but d’effectuer une analyse exhaustive des toutes les solutions existantes, mais de
recenser un certain nombre de solutions représentatives en fonction de leurs caractéristiques.
Il doit satisfaire trois objectifs principaux:
•
•
•
un objectif pédagogique qui consiste à définir qu’est-ce qu’une page Web dynamique et quel est son
intérêt;
un objectif de recherche qui réside à analyser différentes solutions existantes pour la création des pages
dynamiques;
un objectif pratique qui se concrétise dans la conception et la réalisation pratique d’un site utilisant des
pages dynamiques avec une des solutions étudiées.
Pour réaliser le premier objectif, il faut bien comprendre qu’est-ce que c’est une page Web dynamique et
quelle est son utilité en regard notamment à l’utilisation exclusive de pages statiques. L’approche choisie
consiste à définir la raison d’être des solutions étudiées en recensant les limitations des pages statiques par
rapport à l’évolution des besoins des différents acteurs impliqués (les utilisateurs, les programmeurs, les
graphistes) et en voyant comment l’utilisation de langages de programmation pour la création de pages
dynamiques peuvent y apporter une solution.
Le deuxième objectif consiste dans l’analyse des solutions existantes pour la création de pages dynamiques.
Le but est celui d’aboutir à une classification ou une cartographie de ces langages afin d’aider celui qui
voudrait mettre en œuvre un site dynamique à choisir la solution qui lui conviendrait le mieux.
Le troisième objectif est la conception et la réalisation pratique d’un site de commerce électronique en
utilisant un des langages faisant objet de l’étude. Le produit concret de cette partie est un site Web qui
construit ses pages de façon dynamique en fonction du contenu d’une base de données. Les fonctionnalités
principales du site sont la navigation à travers d’un catalogue d’articles, la recherche d’articles par mots clé,
la gestion d’un panier des achats, la possibilité de passer des ordres en ligne et la gestion de la base de
données, notamment pour ce qui est le contenu du catalogue et la gestion des ordres passées par les clients.
-3-
2
Résumé
La dernière décennie a été témoin d’une évolution dans les usages des individus avec le développement de
besoins et exigences toujours plus importantes. Parmi les besoins qui se sont le plus développés, on peut citer
les besoins de communication, d’individualisme, de mobilité, d’ubiquité, de rapidité et d’échanges de biens
et d’informations à niveau mondial.
Cette évolution a été à la fois la cause et l’effet de phénomènes tels que la globalisation de l’économie et
l’évolution technologique, en particulier dans le domaine de la communication et de l’informatique. Le
développement et la démocratisation des réseaux informatiques, notamment avec l’apparition du World
Wide Web, a été un des éléments importants de cette évolution.
Avec la croissance du Web et l’arrivée de nouvelles technologies, les attentes de ses utilisateurs, à l’égar des
sites Web se sont développés énormément. Aujourd’hui on s’attend de plus en plus à des sites complets,
interactifs et mis à jour très rapidement, utilisant des technologies de pointe et offrant toujours plus de
fonctionnalités. Dans ce cadre, la technologie initiale basée sur l’utilisation de pages statiques commence à
faire ressentir ses limitations. Pour répondre à ces nouvelles exigences, des programmeurs ont développé des
solutions permettant la création de pages de façon dynamique. Ces solutions ont toutes en commun le fait de
se baser sur des langages de programmation dans lesquels spécifier les instructions pour créer les pages et de
donner la possibilité de séparer le contenu des pages de la façon dont le contenu va être mis en forme et
présenté à l’utilisateur.
Bien que leur apparition soit assez récente, ces dernières solutions ont été rapidement adoptées par un grand
nombre de sites. Même s’il semblerait que la majorité des pages est encore aujourd’hui formée de pages
statiques, leur proportion est toujours en train de diminuer au profit des pages construites à la volée. En effet
ces dernière présentent un certain nombre d’avantages qui en font une solution envisageable, surtout pour les
grands sites et ceux qui veulent offrir des fonctionnalités d’interaction avec leurs utilisateurs. Ces solutions
ont aussi quelques limitations, surtout liées à la plus grande complexité de développement et traitement, qui
en limitent l’adoption, en particulier pour les petits sites.
Ce travail est censé analyser les solutions représentatives disponibles à l’heure actuelle pour générer les
pages de façon dynamique et d’en présenter les avantages et limitations par rapport à l’utilisation de pages
statiques.
Le présent mémoire est structuré de la façon suivante:
La section précédente présente les objectifs du mémoire.
Cette section présente un bref résumé du sujet du mémoire et en présente la structure.
La section 3 de ce travail est consacrée à une introduction historique qui servira à bien définir le contexte
d’apparition et d’évolution du World Wide Web et des pratiques de programmation de pages dynamiques.
Cette introduction doit permettre de comprendre les raisons qui ont porté à son émergence, en montrant
notamment qu’elle constitue une réponse à l’évolution des besoins et des attentes des différents acteurs
concernés et qu’elle permet de surmonter les limitations et les problèmes posés par l’utilisation de pages
Web statiques, qui deviennent de plus en plus contraignantes au fur et mesure de cette évolution.
La section 4 est dédiée à la définition du World Wide Web et à l’explications des mécanismes fondamentaux
qui en caractérisent le fonctionnement et qui sont communs à toute solution pour la création de pages Web,
soit statique ou dynamique.
La section 5 est centrée sur les pages statiques. Leur mode de fonctionnement est expliqué et leurs avantages
et limitations sont passés en revue. L’évolution des besoins est également prise en compte afin de permettre
de mieux comprendre pourquoi les limitations liées à ce type de pages ont porté à la recherche de solutions
alternatives, tels les solutions de programmation de pages dynamiques.
-4-
La section 6 est consacrée à l’étude et à la comparaison des différentes solutions disponibles à ce jour pour la
programmation de pages dynamiques. Après avoir expliqué qu’est-ce qu’une page Web dynamique et avoir
présenté les principes généraux de fonctionnement sous-jacent aux pages dynamiques, les différentes
solutions qui sont l’objet du mémoire sont présentées et analysées.
La section 7 présente les conclusions de l’étude sous forme d’un récapitulatif des éléments trouvés dans la
comparaison des différentes solutions et se concrétise dans un tableau synoptique présentant les différents
langages et les cas-type d’utilisation.
La section 8 est formée par une bibliographie commentée, structurée par sections thématiques, d’ouvrages et
articles auxquels ce document fait référence et auxquels se référer pour en savoir plus sur un thème
particulier.
La section 9 est le glossaire des termes techniques.
La section 10 est consacré à la partie pratique de ce travail, avec la présentation de l’application de
commerce électronique développée.
Ce document utilise les conventions suivantes:
•
•
les renvois aux ouvrages présentés la bibliographie sont faits en utilisant le symbole [x] où x
représente le numéro de la référence dans la bibliographie;
l’explication des termes techniques, dont la première utilisation est formatée en italique et suivie par
un astérisque (mot*), est faite dans le glossaire.
-5-
3
Introduction : les origines du Web
3.1
Brève histoire de l’informatique
Afin de pouvoir placer le Web dans son contexte, il est utile de passer rapidement en revue l’histoire de
l’informatique qui le précède.
Parmi les origines anciennes des ordinateurs et de l’informatique on trouve le besoin d’effectuer des calculs
rapidement et de façon mécanique. Les ancêtres des ordinateurs étaient des machines à calculer mécaniques
capables d’effectuer des calculs biens définis: on peut prendre par exemple la machine à additions de Pascal
en 1642 ou la machine de Leibniz en 1694 capable d’effectuer des multiplications. Au cours du 19ème siècle
apparaissent la première machine programmable construite par Babbage et le travail de Boole « Investigation
of the Laws of Thought » (1854) dans lequel il pose les bases de la logique binaire.
Les premiers véritables ordinateurs (qu’on peut appeler de première génération) apparaissent au cours des
années ’40: sous l’impulsion de la deuxième guerre mondiale et de l’intérêt stratégique des ordinateurs,
surtout dans les domaines de la cryptographie et de la balistique, les gouvernements en financent
massivement les projets de recherche et développement. A cette époque les ordinateurs étaient caractérisés
par le fait d’être construits pour des buts spécifiques et d’avoir des instructions spécifiques programmées en
binaire, souvent à partir de bobines en papier perforées. Ces machines étaient gigantesques et avaient des
capacités très réduites et des temps de réponses assez élevés. A titre d’exemple on peut citer le premier
ordinateur électronique construit par Atanasoff en 1939 afin de résoudre des équations linéaires, le ENIAC1
(‘46) qui pesait 30 tonnes et pouvait effectuer environ 330 multiplications par seconde et l’UNIVAC I2 (‘51),
le premier ordinateur commercial, vendu à un prix de 750’000 $ et capable d'exécuter 8’333 additions ou 555
multiplications par seconde.
Les années ‘50 ont connu une série d’innovations importantes, qui ont contribué au développement fulgurant
des ordinateurs (qu’on peut appeler de deuxième génération) et de l’informatique. Parmi elles on peut citer
l’apparition du transistor et des langages de programmation. Le transistor est inventé en 1948. Le premier
ordinateur construit avec cette technologie est terminé en 1956. L’introduction du transistor et d’autres
innovations hardware a permis de réduire la taille des ordinateurs et d’en augmenter la puissance et la
fiabilité. Les langages de programmation apparaissent en même temps: le premier langage de programmation
est l’assembleur qui apparaît en 1950 et remplace la programmation directe en forme binaire. Par la suite
apparaissent des langages de plus haut niveau, tels que Fortran (‘57) et Cobol (‘60).
Les ordinateurs de troisième génération apparaissent la décennie suivante, grâce à l’apparition des circuits
intégrés, dont la première démonstration a été menée en 1958, et qui permet de réduire ultérieurement la
taille et le coût des machines tout permettant d’entamer une évolution incroyable dans la puissance et
l’accessibilité des ordinateurs. En plus ces ordinateurs étaient caractérisés par la présence d’un système
opératoire. Cette évolution est si spectaculaire que l’affirmation connue comme loi de Moore formulée en
1965, qui prévoit que « la complexité des circuits intégrés doublera tous les ans », se révèle vérifiée par la
suite. C’est dans la même période que se développent les deux concepts principaux qui constituent la base du
Web actuel: le concept de documents hypertexte et l’utilisation d’un réseau d’ordinateurs, qui seront traités
dans la section suivante.
Par la suite, l’évolution des ordinateurs continue et est marquée par la miniaturisation des composant et
l’introduction des puces mémoires (1970), des microprocesseurs (1971). Ces éléments, ainsi que la création
de programmes faciles à utiliser et l’introduction de l’interface graphique, ont permis d’étendre l’utilisation
des ordinateurs aux familles, développant le concept de mini-ordinateur à usage personnel.
1
2
Electronic Numerical Integrator and Computer
UNIVersal Automatic Computer
-6-
3.2
Brève histoire de l’Internet
La première utilisation d’un ordinateur à distance date de 1940. Les premiers réseaux d’ordinateurs
apparaissent au cours des années ’50 et utilisent les infrastructures de communication traditionnelles basés
sur la commutation de circuit. Deux exemples de réseaux de cette époque sont le réseau SABRE (‘55), un
système de réservation en temps réel développé pour la compagnie American Airlines et le réseau SAGE
(’58) utilisé par le département de la défense américaine pour superviser les avions.
L’idée d’un réseau global est exprimée la première fois en 1962 par J. Licklider [6], dans ce qu’il appelle le
« Galactic Network », un réseau d’ordinateurs interconnectés permettant à chacun d’accéder rapidement aux
informations et programmes. Cette vision était proche de l’Internet d’aujourd’hui.
En 1961 Leonard Kleinrock du MIT publie une première théorie sur l'utilisation de la commutation de
paquets pour transférer des données [7] et publiera un livre sur le même sujet en 1964. Des recherches sur la
commutation de paquets sont aussi menées en même temps par RAND Corporation, qui conçoit un réseau
capable de continuer à fonctionner même en cas de destruction partielle [8], et par le National Physical
Laboratory.
Au début des années ‘60 le département de la défense américain, à travers son agence de recherche ARPA*,
finance un projet destiné à la conception d’un réseau d’ordinateurs capable d’être opérationnel même en cas
de guerre nucléaire. Le concept est formulé en 1967 en se basant sur les recherches effectuées sur la
commutation de paquets: il s’agit d’un réseau basé sur la commutation de paquets et un routage dynamique.
Le réseau est appelé ArpaNet* du fait de son bailleur de fonds. En 1969, le réseau est mis en place sur 4
machines et mis en état de marche.
Avec l’implémentation du protocole d’échange (NCP*, 1970), les premières applications ont pu être
développées. Parmi ces premières applications on peut remarquer la messagerie électronique, connue aussi
sous le nom e-mail* (1972), l’émulation de terminal (Telnet*, 1972) et le transfert de fichiers (FTP*, 1973).
Ces applications, dont la plus importante est sans doute l’e-mail, ont permis d’augmenter l’attrait du réseau
qui commençait alors son expansion (voir annexe 1). Les premières connexions au réseau en dehors des
Etats-Unis datent de 1973.
La nécessité de développer des protocoles normalisés de communication communs et de favoriser la
recherche dans des nouvelles technologies appliqués aux réseaux conduit à la création d’un groupe de travail,
le INWG*.
En 1973 l’ARPA lance un projet appelé « Internetting » visant à développer un nouveau protocole
permettant de répondre aux exigences d’une infrastructure de réseaux ouverte, dans laquelle les sous-réseaux
sont indépendants les un des autres, sans aucun contrôle global et interconnectés à travers une interface
unique spécifiée. Le but initial était celui de pouvoir faire fonctionner des réseaux de types différents (réseau
satellite, radio,…) à travers une interface commune. Ce projet donne lieu aux protocoles TCP*/IP*: où IP
fournit les fonctionnalités d’adressage et de routage sans aucune garantie de service et TCP fournit des
services tels que le contrôle de flux, le contrôle d’erreur et la reprise des paquets perdus. Ces protocoles
seront ensuite adoptés en tant que standard pour le département de la défense en 1980 et remplacera le
protocole NCP au sein d’ArpaNet en 1983.
Dans les années ’80 ArpaNet évolue rapidement grâce à l’apparition des réseaux locaux (la technologie
Ethernet a été développée en 1973) et des ordinateurs personnels qui ont augmenté considérablement le parc
de machines connectées. Le développement du réseau est guidé en premier lieu par la NSF* et la
communauté scientifique, financée en grande partie par le pouvoir public. Différents réseaux, dont NSFNet*,
s’ajoutent à ArpaNet et le réseau commence à grandir de façon exponentielle donnant lieu à un réseau
fédérateur composé de sous-réseaux interconnectés et basé sur la suite de protocoles TCP/IP. On
commencera alors à parler d’Internet comme étant un réseau fédérateur de sous-réseaux utilisant les
protocoles TCP/IP.
-7-
Au fur et mesure de la croissance du réseau et de la maturité de la technologie, d’autres communautés de plus
en plus diversifiées, en particulier la communauté commerciale, s’intéressent au réseau. Ce dernier devient
une cible pour de nombreuses entreprises soucieuses d’opportunités nouvelles. Les années ’80 et ’90 ont
donc été caractérisées par la commercialisation et la divulgation de la technologie Internet. Les premières
implémentations commerciales de la suite TCP/IP apparaissent au début des années ’80. Les efforts de la part
des organismes dédiés au management de l’Internet et des fabricants, se concrétisant dans des conférences
sur l’interopérabilité (INTEROP), ont réussi à faire en sorte que les équipements des différentes entreprises
puissent travailler ensemble correctement.
Dans la deuxième moitié des années ’80 et dans la première moitié des années ‘90 les réseaux eux-mêmes
ont été progressivement privatisés: de nombreux fournisseurs de services Internet, qui sont en grande partie
des opérateurs en télécommunications, remplacent les infrastructures qui étaient une fois financées par la
communauté publique. Ce transfert a été favorisé par la décision de la NSF de fragmenter son réseau en
sous-réseaux régionaux et de favoriser pour ceux-ci la recherche de clients commerciaux. ArpaNet cesse
d’exister en 1990 et NSFNet n’est plus financée à partir de ’95.
Dans les mêmes années on a assisté à une croissance exponentielle du réseau, au lancement de nouveaux
services (News* ’78, Serveurs de noms* ’84, Chat* ‘88, World Wide Web* ’91) et au lancement de
nombreuses innovations technologiques permettant de supporter les charges de plus en plus grandes. Il suffit
de penser à l’introduction de la fibre optique et de l’introduction du World Wide Web, sujet de la prochaine
section.
3.3
Brève histoire du World Wide Web
L’histoire de l’hypertexte, fondement de l’actuel Web, commence en 1945, lorsque V. Bush, assistant du
président Roosevelt, propose Memex. L’idée à la base de Memex est celle d’une machine capable
d’emmagasiner des documents textuels et graphiques et de les arranger en sorte que des liens arbitraires
puissent être faits entre des parties de documents afin de pouvoir passer d’une donnée à une autre par
association. L’idée est inspirée du fonctionnement du cerveau humain, qui garde en mémoire de nombreuses
informations et les combine par association et analogie [9].
Le terme hypertexte est inventé en 1965 par Ted Nelson à l’occasion de la publication d’un premier papier
sur le sujet. Un document hypertexte est un document écrit de façon non linéaire (avec des branches) qui
permet au lecteur de décider dans quelle direction poursuivre sa lecture en utilisant des liens vers d’autres
parties du document. Des implémentations de systèmes hypertexte ont été développées dans les années qui
suivent, biens qu’elles se limitaient à des documents textuels, en particulier pour la documentation de gros
projets.
Le concept de documents et liens hypertexte seront par la suite formalisés par le même Ted Neslon dans le
projet Xanadu [10], qui inspirera successivement le développement du World Wide Web. Xanadu est un
modèle basé sur une base de données unique qui contient des documents liés entre eux selon le mécanisme
dit de « transclusion ». Ce mécanisme fonctionne de la façon suivante: chaque document peut librement citer
d’autres documents qui lui sont alors liés. Le lecteur peut ainsi retrouver le document à partir duquel la
citation a été tirée et en voir ainsi le contexte. Un mécanisme de royalties peut être lié à ces liens et permet de
compenser les auteurs des documents pour leur œuvre. Le modèle Xanadu permet de gérer les versions en
gardant trace de chaque modification et permettant de reconstituer les versions précédentes; de cette façon il
devient impossible de tomber sur un lien aboutissant à une document qui n’existe plus.
En novembre 1990, deux chercheurs du CERN (Tim Berners-Lee et R. Cailliau) proposent un projet pour le
management de l’information basé sur la notion d’hypertexte [11], inspirés des travaux effectués sur le projet
Xanadu et des autres travaux antérieurs. Ce projet, qui est à la base de la création du World Wide Web, a été
lancé pour la nécessité de disposer d’un système unique pour accéder à différents types d’informations et par
le souhait d’avoir un programme qui permettait de créer des associations arbitraires entre pièces
d’information.
-8-
Le projet se concrétise en 1991, avec la spécification des mécanismes de base sous-jacents au World Wide
Web et le développement des prototypes du logiciel client et du logiciel serveur. Les mécanismes de base
sont le schéma de nommage des documents URL* qui permet de localiser de façon unique chaque
ressource appartenant au réseau; le langage HTML* qui spécifie la façon dont les documents hypertexte
doivent être écrits et le protocole de transport HTTP* qui régit les échanges entre logiciels client et serveur.
Le logiciel client, appelé aussi « navigateur », qui est conçu pour être portable sur différents systèmes et est
mis à disposition gratuitement auprès du public, connaît un succès immédiat et fulgurant. Ce logiciel permet
d’accéder aux différents documents à travers d’une interface de type graphique et offrait même la possibilité
d’éditer de nouveaux documents. Le logiciel serveur Web est programmé pour stocker les documents et
répondre aux requêtes des clients.
Une fois les briques de bases du Web rendues publiques, différents groupes de programmeurs ont commencé
à apporter leurs amélioration aux logiciels client et serveur. Une de ces équipes, pilotée par Marc
Andreessen, développe en 1993 sa propre version de navigateur, Mosaic. Ce programme est caractérisé par
une interface graphique de type « pointer et cliquer », une convivialité exceptionnelle, un usage intuitif et un
apprentissage facile. Ce programme a permis la démocratisation du Web, permettant l’accès aux différentes
informations à des novices de l’informatique qui devaient auparavant se familiariser avec une multitude de
systèmes et programmes compliqués et incohérents pour accéder aux différents types de données. Mosaic a
joué un rôle important dans le développement spectaculaire de l’Internet (voir annexe 2).
L’évolution des navigateurs se poursuit l’année suivante (1994): les concepteurs de Mosaic créent leur
propre entreprise, Netscape, et réécrivent un nouveau navigateur amélioré, Navigator. Microsoft entre alors
en concurrence avec son propre produit, Explorer, qui est également basé sur le moteur graphique de Mosaic.
Il s’ensuit une véritable guerre commerciale qui conduit à l’amélioration continue des produits.
Gromov [12] décrit cette évolution dans ces termes: “In the Web's first generation, Tim Berners-Lee
launched the Uniform Resource Locator (URL), Hypertext Transfer Protocol (HTTP), and HTML standards
with prototype Unix-based servers and browsers. A few people noticed that the Web might be better than
Gopher*. In the second generation, Marc Andreessen and Eric Bina developed NCSA* Mosaic at the
University of Illinois. Several million then suddenly noticed that the Web might be better than sex. In the
third generation, Andreessen and Bina left NCSA to found Netscape...”.
Avec la démocratisation et la croissance du Web, croît aussi l’attrait commercial de ce nouveau canal de
communication. Les premiers usages commerciaux du World Wide Web se développent autour de 1995 avec
comme objectif principal la diffusion de l’information aux visiteurs. Les sites utilisaient des pages statiques
non interactives de type «brochureware». Dans les années qui suivent, un nombre croissant d’entreprises
réalisent qu’Internet a tout le potentiel de devenir aussi un canal de transaction et de communication
important. Des nombreux sites développent des services payants et apparaissent les sites de commerce
électronique, avec pour but la vente de produits et de services. Dans le même temps le Web devient aussi un
média important dans la stratégie de communication des différentes entreprises, qui affichent des véritables
cartes de visite électronique et intègrent leur site dans leurs stratégie marketing.
Parallèlement à l’évolution technique, à l’explosion du nombre d’utilisateur et de sites et à l’utilisation
croissante d’Internet à des fins commerciaux, le langage HTML, initialement conçu pour répondre aux
besoins de la communauté scientifique et axé sur la structuration du contenu des documents, est enrichi
successivement pour répondre aux besoins de plus en plus forts d’amélioration des possibilités de
présentation, design et interactivité. C’est ainsi que se développent plusieurs versions du langage (la version
1.0 a été développée en 1992, 2.0 en novembre 1995, 3.2 en janvier 1997 et 4.0 en décembre 1997)3.
Pendant sa courte histoire, le Web a connu une croissance exponentielle pour devenir l’immense réseau
qu’on connaît aujourd’hui (voir aussi les annexes 1 et 2). Approximativement le World Wide Web comptait
en 2000 plus d’un milliard de pages et plus que 350 millions d’utilisateurs4.
3
4
Source: World Wide Web Consortium: HyperText Markup Language Home Page, kttp://www.w3.org/MarkUp/
Source : HTTP://www.waller.co.uk/Web.htm
-9-
4
Le World Wide Web
Dans cette section on va définir ce qu’est le World Wide Web* et comment il fonctionne. On va en particulier
passer en revue les mécanismes fondamentaux qui sont à la base du Web* et qui sont valables aussi bien pour
les pages statiques que les solutions pour la génération des pages dynamiques. Les sujets spécifiques à ces
deux familles de pages seront traitées dans les sections respectives.
L’idée à la base du World Wide Web est celle d’associer les réseaux d’ordinateurs et un modèle de
documents basé sur l’hypertexte afin de constituer un système d’information global, puissant et facile à
utiliser. En effet le Web peut être vu comme un réseau de documents5 distribué, dans lequel chaque page
Web peut être librement liée à d’autres pages à travers de liens hypertexte.
Les pages Web sont des fichiers textuels écrit en suivant le formalisme et les règles syntaxiques spécifiées
par le langage HTML, qui définit la façon dont la page doit être présentée à celui qui en fait demande et
permet de spécifier les liens hypertexte avec les autres pages. Chaque page Web possède un nom unique qui
permet de la distinguer des autres pages sur le réseau. Ce nom s’appelle en réalité URL (Uniform Resource
Locator) et il sera défini dans plus de détail dans la section 4.2. Les liens hypertexte sont caractérisés par
l’adresse URL de la page de destination et permettent de passer d’un document à un autre avec un simple
click de la souris.
Les liens entre les différentes pages composent ce qu’on appelle la structure de navigation: l’analogie entre
la représentation graphique de cette structure et une toile d’araignée est à l’origine du nom World Wide Web.
Cette façon de rechercher des informations en passant d’un document à un autre en utilisant les liens
proposés s’appelle en anglais « browsing », qui peut se traduire en français par « butinage » ou
« navigation* ».
Le Web peut être qualifié d’être un réseau distribué dans le sens que la localisation des pages qui le
composent est repartie sur plusieurs machines se trouvant un peu partout dans le monde et interconnectées à
travers Internet. Le Web fonctionne selon une architecture de type client-serveur, qui sera traitée dans plus
de détail dans la section suivante. Pour l’instant on se limite à dire qu’il y a deux familles de machines: les
machines clients, qui formulent des requêtes pour obtenir les pages demandées par les utilisateurs, et les
serveurs Web, sur lesquels sont stockées les pages Web et est installé un logiciel permettant de traiter les
requête soumises par les machines clients et leur fournir les pages demandées. L’échange entre les deux
machines est régi par les règles spécifiés par le protocole HTTP, décrit dans la section 4.4, qui se base sur un
échange de type requête-réponse.
Une caractéristique importante du Web est que le logiciel client, appelé en anglais « browser », terme qui
peut être traduit en français par « butineur » ou « navigateur », constitue une interface unique à l’ensemble
des pages qui contiennent n’importe quel type d’informations. Ce logiciel se charge de formuler les requêtes
pour accéder aux pages souhaitées, d’interpréter les instructions de présentation des informations contenues
dans les pages et de les présenter à l’utilisateur selon les possibilités de sa machine. En effet, une fois
visualisées par le navigateur sur le poste client, les pages Web peuvent contenir des informations dans
plusieurs médias différents, tels que du texte, des images, du son, de la vidéo et des données.
Les pages Web peuvent être créées avec n’importe quel éditeur texte. Il existe toutefois sur le marché une
grande variété d’éditeurs spécialisés pour écrire des pages Web, dont on peut distinguer ceux qui facilitent
l’écriture textuelle des pages, par exemple avec des options tels la coloration syntaxique et l’insertion
automatique de balises HTML, et ceux qui donnent la possibilité de les construire de façon visuelle, qui
permettent de créer des pages avec une interface graphique de type « glisser et poser » même en ne
connaissant pas le langage HTML. Il est toutefois préférable de connaître les bases du HTML, car il est
possible de devoir écrire une page avec des fonctionnalités qui ne sont pas prévues par les éditeurs visuels et
5
Ici document est dans un sens large comme toute ressource informationnelle de n’importe quel type: du texte, des images, du
son, de la vidéo, des fichiers, etc.
- 10 -
car les pages écrites par ces éditeurs ne sont pas toujours faciles à maintenir. A titre d’exemple on peut citer
Emacs et UltraEdit pour les éditeurs textuels, FrontPage et Dreamweaver pour les éditeurs visuels.
Une représentation schématique du Web est donnée à la figure 1. Les différentes pages Web sont
représentées, par analogie avec les pages d’un livre, avec des rectangles blancs contenant des lignes
horizontales. Ces pages sont reliés entre elles par les liens, représentés par les petits rectangles colorés, qui
permettent de passer au document de destination désigné par l’adresse contenue dans le lien par un simple
click de la souris. Ces liens sont uni-directionnels: la présence d’un lien d’une page source vers une page
destination n’implique pas la présence d’un lien de la page destination vers la page source. Le rectangle
tratillé représente une machine particulière, qui contient des pages qui sont liées entre elles et à d’autres
pages (non représentées) sur d’autres serveurs distants. Si on se plaçait à un niveau de visualisation supérieur
on aurait une image similaire où on substituerait aux pages les différents serveurs et aux liens les différentes
pages contenant les liens.
Document hypertexte pouvant
contenir du texte, images, son, …
Lien hypertexte qui renvoie vers un
autre document
Parcours de la navigation
Figure 1: Les composants du World Wide Web
Dans les sections suivantes on va passer en revue les composantes fondamentales du Web, qui sont devenues
incontournables et qui restent valides dans tous les types de solutions qui sont l’objet de ce mémoire. Ces
composants sont l’architecture client-serveur, le mécanisme de nommage des pages (URL), le langage dans
lequel il faut écrire les pages (HTML) et le protocole qui en régit l’échange entre les machines « serveur » et
les machines « client » (HTTP).
4.1
Architecture du World Wide Web
Le fonctionnement du World Wide Web est basé sur une architecture de type client-serveur. Le client est
généralement défini comme étant le demandeur d’un service et le serveur comme étant le fournisseur du
service demandé. Dans le cas du World Wide Web, le service qui est échangé entre les deux entités est la
mise à disposition d’une page Web (ou d’un fichier d’autre type stocké sur un serveur Web, tels des
programmes, des images, du son etc.).
Comme illustré à la figure 2, le processus d’échange se déroule en 3 étapes et est régi par les règles du
protocole HTTP. Ce protocole définit la syntaxe à employer pour effectuer des requêtes et réponses entre
clients et serveurs Web et se charge de leurs transfert à travers à d’autres protocoles de niveau inférieur qui
en assurent le transfert sur le réseau.
L’échange d’une page Web entre le serveur le machine client commence lorsque ce dernier formule une
requête indiquant la ressource demandée, identifiée à travers son URL, ainsi que toutes les données
complémentaires utiles au serveur pour satisfaire la requête, et l’envoie au serveur. Une fois que la requête
est reçue par le serveur, ce dernier effectue un traitement qui commence par l’interprétation de la requête et
la vérification de sa validité. Si la requête est valide, c’est à dire formulée correctement selon les
spécifications du protocole HTTP, le serveur cherche à localiser la ressource demandée en utilisant les
informations contenues dans l’URL passée dans la requête. Si la ressource est localisée et disponible pour le
- 11 -
client, le serveur Web formule une réponse indiquant que la requête a pu être traitée avec succès et qui inclut
une copie de la ressource demandée; dans le cas contraire le serveur formule une réponse indiquant les
1. Requête HTTP
4.
Visualisation
disque
3. Réponse HTTP
Client
2. Traitement
de la requête
et localisation
de la page
Serveur
Figure 2 : Fonctionnement du World Wide Web
raisons pour lesquelles la requête n’a pas pu être satisfaite. La réponse est ensuite envoyée au client qui
s’occupe de l’interprétation de la réponse reçue et de la visualisation du résultat à l’écran (ce qui comporte,
dans le cas où le client a reçu une page Web, l’interprétation des instructions HTML contenues dans la page
reçue).
La démarche présentée est celle qui est mise en oeuvre dans le cas des pages Web statiques. Dans le cas des
pages dynamiques, il y a une étape supplémentaire qui consiste dans l’interprétation des instructions pour la
création de la page Web. Comme on le verra dans la section dédiée aux pages dynamiques, il existe deux
grandes familles de solutions: solutions coté client et solutions coté serveur.
Dans les solutions coté serveur, l’étape supplémentaire est effectuée dans le traitement de la requête par le
serveur Web et se caractérise par un échange entre celui-ci et un programme externe ou un module
d’extension du serveur. Ce dernier reçoit du serveur toutes les informations nécessaires pour créer la page
Web demandée par le client (qui consistent essentiellement du fichier contenant les instructions à utiliser
pour créer la page, des informations contenues dans la requête et des informations sur le serveur lui-même) et
retourne au serveur la page construite pour que celui-ci puisse l’envoyer au client.
Dans les solutions coté serveur, l’étape supplémentaire est effectuée dans le traitement de la réponse par le
client. Dans ce cas la page reçue contient en même temps que des instructions HTML, des instructions d’un
langage de script ou des petits programmes. Le premier cas est celui des langages de script coté client (voir
section 7.1.3): la page Web contient des instruction issues de ces langages et leur interprétation est effectuée
par le navigateur avant de visualiser la page. Le deuxième cas est celui des Applets et des Active X
(présentés dans les sections 7.1.1 et 7.1.2) et le navigateur exécute alors le programme qui est contenu dans
la page.
On a vu que l’architecture du World Wide Web est de type client-serveur et qu’elle se base sur trois
mécanismes principaux: les URL, le langage HTML et le protocole HTTP. Dans les sections suivantes on va
présenter en davantage de détails ces trois composants.
4.2
URL (Uniform Resource Locator)
Les URL ont été conçues par Tim Berners-Lee au cours de son projet qui a donné naissance au Web afin de
pouvoir identifier chaque ressource sur le réseau avec un nom unique, contenant toutes les informations
nécessaires pour pouvoir y accéder. Depuis lors, leur définition a été formalisée principalement dans la RFC
1738 [10], adoptée par l’IETF6 comme standard en 1994. Les URL relatives, qui constituent un mécanisme
6
Internet Engineering Task Force
- 12 -
qui permet au logiciel client de pouvoir constituer une URL complète à partir du contexte dans lequel il se
trouve (l’URL courante) et des indications sur les changements à y apporter, sont définies dans la RFC 1808.
Les URL sont un format de nommage universel utilisé pour désigner de façon unique une ressource non
seulement sur le World Wide Web, mais sur toute l’Internet, indépendamment du mécanisme d’accès utilisé.
Ce mécanisme se base sur l’attribution à une ressource d’un identifiant abstrait qui incorpore la méthode
d’accès à la ressource (le protocole d’accès), la machine sur laquelle se trouve la ressource (identifiée grâce à
son adresse IP* ou grâce au nom logique correspondant, enregistré dans un serveur de noms DNS*), et la
position que la ressource occupe sur cette machine.
La RFC* 1738 qui formalise les URL définit un schéma syntaxique général indépendant de la méthode
d’accès utilisé. Ce schéma est composé de la méthode d’accès suivie d’une partie qui lui est spécifique: la
syntaxe est du type <méthode d’accès>:<partie spécifique à la méthode>. Le même document définit
également les syntaxes spécifiques à un certain nombre de protocoles dont le protocoles http, ftp, wais*,
gopher etc. ainsi que la démarche à suivre pour en créer de nouvelles.
Les URL spécifiques au Web se composent de 5 parties :
•
•
•
•
•
la méthode d’accès, représentée par le protocole utilisé pour communiquer (http://);
l’identifiant de la machine qui possède la ressource (qui peut être soit le nom logique de la machine –
nom DNS– ou son adresse IP sous format décimal);
le numéro de port précédé du signe ″:″ (cette partie est optionnelle: si aucun numéro de port n’est
indiqué, le numéro par défaut du protocole est utilisé, dans le cas du Web ce numéro est 80);
la localisation de la ressource sur le serveur, qui est le nom complet de la ressource comprenant le
chemin où la ressource est stockée, à partir du répertoire racine du serveur (pour l’indication du
répertoire où la ressource est stockée, la syntaxe des systèmes UNIX est utilisée);
une partie optionnelle composée d’un point d’interrogation suivie par les données communiquées au
serveur dans l’en-tête de la requête HTTP (d’autres données peuvent être contenues dans le corps de la
même) formulés avec une syntaxe du type nom=valeur où les différents couples nom=valeur sont
séparés par le signe ″&″.
Le schéma syntaxique d’une URL spécifique au World Wide Web complète est la suivante:
http://<nom_du_serveur>:<numéro_de_port>/<localisation_de_la_ressource>?<données>. Un exemple
d’URL typique, sans ses éléments optionnels qui ne sont pas fréquemment spécifiés, est le suivant :
Protocole
http
Nom du serveur
Chemin
:// Inforge.unil.ch
/ enseignement/dpio/dpio.html
Dans cette URL, « http:// » est la méthode d’accès, « inforge.unil.ch » est le nom du serveur hébergeant la
ressource, « enseignement/dpio/ » est le nom du répertoire dans lequel se trouve la ressource et
« dpio.html » est le nom de la ressource demandée, dans ce cas une page HTML de nom dpio.html.
L’exemple suivant correspond à une URL complète avec toutes ses parties optionnelles: en plus de la
méthode d’accès, du nom de serveur et de la localisation de la ressource, cette URL spécifie le numéro de
port à utiliser pour se connecter au serveur et est utilisée pour transmettre des données sous forme de
paramètres. Dans ce cas la ressource demandée correspond à une page de nom home.php généré
dynamiquement à partir d’un script php.
Protocole
http
Nom du serveur
:// Inforge.unil.ch
Port
:
80
Chemin
/
dpio/home.php
Données
? langage=français
Il est utile de mentionner que les URL ne peuvent contenir que des caractères appartenant au groupe de
caractères imprimables de la codification US-ASCII*, sauf les caractères considérés comme ambigus ou
réservés à d’autres utilisations. Ces caractères sont spécifiés dans la RFC 1738. Si tels caractères doivent être
utilisés dans les URL il faut les codifier d’une façon particulière en utilisant un triplet composé du signe
- 13 -
« % » et de deux nombres hexadécimaux (0-F). Par exemple « %20 » représente un espace. Pour éviter un
fastidieux travail de conversion, les solutions pour la génération de pages dynamiques proposent des
fonctions qui effectuent cette conversion automatiquement.
L’utilisation principale des URL est liée à l’insertion de liens hypertexte dans les pages Web afin de lier
entre elles différentes pages Web ou ressources: pour qu’une page Web contienne un lien vers une autre page
il suffit d’utiliser une instruction du langage HTML et de lui donner comme attribut l’URL de la page
destination. Lorsque la page est visualisée dans le navigateur l’utilisateur peut avec un simple click sur les
mots en évidence passer à la page de destination.
Les URL peuvent aussi être utilisés pour insérer dans une page une ressource non textuelle, telle que un
programme, un image ou un fichier: la balise HTML correspondante est renseigné par un attribut de l’URL
qui identifie la ressource à utiliser.
Enfin les URL sont aussi utilisées pour transmettre des données au serveur, données qui sont directement
codés dans l’URL d’un lient ou proviennent d’un formulaire qui utilise la méthode GET.
Dans une page HTML, les URL peuvent être écrites sous forme absolue ou relative. Le premier cas
correspond à l’écriture de l’URL complète conformément aux spécifications décrites en précédence. Dans le
deuxième cas, qui n’est utilisable que pour les pages hébergées sur le même serveur, le lien spécifie
seulement la position de la ressource destination par rapport à la ressource en cours d’utilisation et le
navigateur se charge de construire l’URL complète. Ces deux possibilités offrent des avantages respectifs: il
est préférable d’utiliser des URL relatives pour les liens entre pages appartenant à un même groupe pour
qu’il soit possible de déplacer le groupe entier sans devoir changer tous les liens; inversement il est
préférable d’utiliser les URL absolues pour des pages indépendantes, afin de le pouvoir déplacer
indépendamment les unes des autres.
4.3
HTML (HyperText Markup Language)
Pour pouvoir publier des documents dans un environnement global, ouvert et hétérogène tel que le Web, il
est nécessaire d’avoir un langage universel commun entre les différents acteurs, compris de la même façon
par les différentes machines et programmes. Ce langage universel pour le World Wide Web est le HTML,
standardisé par le World Wide Web Consortium* (W3C). La specification de HTML 4 [xxx] met en évidence
son caractère d’universalité: “To publish information for global distribution, one needs a universally
understood language, a kind of publishing mother tongue that all computers may potentially understand. The
publishing language used by the World Wide Web is HTML”. [17]
Comme les autres mécanismes de base du Web, le HTML a été introduit par Tim Berners Lee dans son
projet de 1990 [11]. Le but initial était celui d’avoir un langage universel de structuration du contenu des
documents, ce qui répondait aux besoins de la communauté scientifique qui était à cette époque la principale
utilisatrice du Web. Il faut bien mettre en évidence que la version initiale du langage était axée sur la
structuration du document et non pas sur la façon de le formater et présenter à l’utilisateur, car les besoins
ressentis à l’époque étaient d’avoir une façon d’organiser de façon commune le contenu des différents
documents afin d’en faciliter la gestion et d’avoir une interface unique pour pouvoir les consulter.
L’explosion de la croissance du World Wide Web a conduit à la formation d’un organisme international pour
que le langage soit standardisé, afin que l’arrivée des nombreux acteurs actifs dans le développement de
programmes Web clients et serveurs, chacun imposant ses propres particularités liées au langage supporté,
n’aurait pas empêché d’avoir un langage universel compris potentiellement par toutes les machines
indépendamment du logiciel et du système employé. Cet organisme est le W3C, dont la mission est la
définition et de l’évolution des technologies liées au Web dans le but de favoriser l’interopérabilité du Web
par rapport aux plates-formes et aux navigateurs, afin d’éviter que le Web ne devienne un monde de
standards propriétaires et incompatibles, permettant de réduire les coûts de développement (car une seule
- 14 -
version suffit pour tout le réseau) et d’augmenter son potentiel commercial grâce au plus grand nombre de
visiteurs potentiels qui ont accès aux pages crées.
Le développement de la communauté commerciale active sur le Web a conduit à des enrichissements
successifs pour répondre aux besoins de plus en plus forts d’amélioration des possibilités de présentation, de
design et d’interactivité, avec la création de nouvelles balises et attributs permettant de contrôler la façon
dont le texte doit être formaté et présenté à l’écran.
C’est ainsi que se développent plusieurs versions du langage: la version 1.0 a été développée en 1992 ; la
version 2.0 en novembre 1995, la version 3.2 en janvier 1997 et la version 4.0 en décembre 1997)7.
Actuellement la version en cours d’utilisation est la version 4.01 [17].
Dans ses versions récentes, HTML est considéré comme un langage qui permet à la fois de contrôler la
présentation et la structuration de documents hypertexte, qui en formalise l’écriture de telle sorte que des
usagers utilisant des machines et des programmes différents puissent quand même les lire les mêmes
documents d’une façon équivalente. Les documents HTML sont des documents en pur texte, qui utilisent de
courtes chaînes de caractères appelées balises (ou marqueurs) pour distinguer les différents éléments du
document. Ces éléments sont utilisés pour indiquer la façon dont le document doit être présenté, spécifier les
liens hypertexte qu’il établit avec d’autres documents et inclure des objets de nature très disparate comme
des images, des formulaires, des fichiers, des séquences vidéo, des clips audio, des instructions de langages
de scripts et même de petits programmes.
Il semblerait que le W3C n’ait pas l’intention de poursuivre le développement de nouvelles versions de
HTML dans le futur, mais au contraire de passer à des solutions spécifiques qui s’occupent respectivement
de la structuration du contenu et de sa mise en forme. Il existe actuellement deux solutions qui se démarquent
pour le futur: la solution XML*/XSL* et HTML/CSS*. La première solution utilise le langage XML [19]
(Extensible Markup Language) afin de structurer le document en sections en utilisant son propre set de
balises et les feuilles de style XSL (XML Style Sheet) afin d’établir comment les documents XML doivent
être présentés. La deuxième utilise HTML comme langage de structuration du document et les CSS
(Cascading Style Sheets [20]) comme façon de définir comment ces documents doivent être présentés.
Le langage HTML est défini dans un « métalangage » plus général appelé SGML (Standard General Markup
Language [21]), qui en définit les balises et leur syntaxe à travers une définition de type de document
(DTD*), que leur sémantique, ainsi que la structure de ses documents. Dans sa version actuelle, la version
4.01, HTML comporte 91 balises. Le travail du présent mémoire n’est pas celui de décrire HTML dans ses
détails syntaxiques, pour cela il existe de nombreuses guides disponibles sur le réseau qui expliquent le
HTML et comment l’utiliser qui sont, dont un excellent exemple est le guide “A Beginner’s Guide to HTML“
écrite par la NCSA [22]. Il est cependant utile de se pencher un peu sur les différentes possibilités offertes
par le langage pour pouvoir comprendre quelles sont les limitations de ce langage et pourquoi des langages
de programmation sont nécessaires lorsqu’on veut construire des sites Web un peu plus élaborés.
Les éléments de base du HTML sont les balises, qui sont définies dans la spécification du langage HTML.
Ces balises sont en nombre limité et il n’est pas prévu la possibilité d’en créer de nouvelles. Elles sont
délimitées par les signes délimiteurs “<“ et “>“ et peuvent avoir un certain nombre d’attributs spécifiques à
inclure à l’intérieur des délimiteurs selon la syntaxe <nom attribut=valeur…>. Elles sont généralement
utilisées par couples, avec une balise de début et une balise de fin, qui est formée par le même nom précédé
par le signe “/“. Par ex. <P align=center>…texte…</P> définit un paragraphe (balise P) aligné au centre
(attribut align avec valeur center) consistant du texte défini entre la balise de début et celle de fin.
Les balises ont différentes fonctions, qu’on va décrire ci-après en donnant des exemples non exhaustifs de
balises. Pour la définition de toutes les balises, de leur syntaxe et sémantique, il est préférable de consulter la
définition du HTML en cours (actuellement la 4.01) [17].
7
Source: World Wide Web Consortium: HyperText Markup Language Home Page, kttp://www.w3.org/MarkUp/
- 15 -
•
•
•
•
•
•
Définir la structure du document minimale que toute page HTML doit respecter. Cette structure
comprend la définition du début et fin de document (balise HTML), la définition d’un en-tête (HEAD)
avec un titre (TITLE) et d’un corps de page (BODY).
Structurer le texte et définir la composition graphique de la page. Ce groupe de balises comprend entre
autre les en-têtes (H1…H6), les paragraphes (P), les retours à la ligne (BR), les lignes de séparation
horizontale (HR), les listes (OL, UL, DL) et les tableaux (TABLE).
Définir la façon dont le texte doit être présenté. Il existe deux types principaux de balises de formatage
les balises de style logique et les balises de style physique. Les premières décrivent la fonction du texte
inclus et ne spécifient pas le format de présentation, dont le choix est laissé à l’utilisateur (grâce aux
options spécifiées dans son navigateur) ou spécifié dans une feuilles des style (Cascading Style Sheet,
CSS). Ceci permet une meilleure lisibilité de la page et des changements plus faciles. Par exemple les
balises définition (DFN), citation (CITE), code (CODE) et emphase (EM, STRONG) appartiennent à
ce groupe. Le deuxième groupe définit la façon dont le texte doit être présenté et ce sera la même sur
tous les navigateurs offrant ainsi une certaine consistance. Par exemple les balises police (FONT), gras
(B), italique (I) et texte à largeur fixe (TT).
Inclure des liens vers d’autres documents ou à des sections d’un document. Il s’agit de la balise “A“,
qui permet de définir un lien vers un autre document en indiquant son URL comme attribut “HREF“
selon la notation <A HREF=“URL“>…</A>. Il est aussi possible de définir des sections d’un
document (ancrages) pour qu’un lien doit conduire à cette section en utilisant la balise <A
NAME=“nom“>. L’URL utilisée pour conduire à une section ainsi définie contient le nom définit par
l’attribut “NAME“ précédé du signe “#“ (i.e. HTTP//inforge.unil.ch/dpio.HTML#cours)
Inclure des images (IMG), des liens vers des feuilles de style (LINK), d’instructions d’un langage de
script (SCRIPT), des applications et d’autres objets (APPLET, OBJECT) et des méta-données
décrivant la page (META).
Inclure des formulaires permettant de passer des données au serveur (FORM, INPUT, BUTTON,…).
Il est intéressant de noter que le langage HTML ne permet d’effectuer aucun traitement de données ou
d’instructions de type langage de programmation. Ceci n’est pas son but, car il a été défini comme un
langage de présentation et de structuration de documents; il doit s’appuyer sur d’autres mécanismes
complémentaires pour effectuer des traitements et rendre les pages en quelque sorte « dynamiques ». Il faut
noter que des balises ont été prévues pour offrir ces fonctionnalités et inclure des programmes (définies dans
un langage autre que HTML): ce sont les balises SCRIPT, APPLET et OBJECT.
On reviendra sur les limitations inhérentes au langage HTML (mais aussi du protocole HTTP) et les
mécanismes utilisés pour les surmonter dans des la section spécifiques aux pages statiques. Il faut toutefois
noter que même en utilisant ces autres mécanismes, l’utilisation des mécanismes définies dans cette section
(URL, HTML, HTTP) demeure indispensable.
4.4
HTTP (HyperText Transfer Protocol).
HTTP est un protocole qui règle l’échange de fichiers sur le World Wide Web. Selon une définition de
lnternet Society, « le travail principal d'HTTP est de gérer les échanges entre clients et serveurs, permettant
aux premiers d'exprimer des requêtes et au seconds de répondre en retournant les documents demandés,
accompagnés de suffisamment de méta-information pour que le client puisse les interpréter correctement. De
plus, il est souhaitable que les requêtes elle-mêmes puissent contenir de la méta-information, qui sera
interprétée par le serveur de façon à mieux satisfaire les requêtes ».
Il a été défini en 1990 dans l’initiative qui a porté la naissance du Web. La première version (0.9) permettait
un simple échange de données sur Internet. Cette version a été renouvelée à deux reprises dans les RFC 1945
(un document informationnel illustrant version 1.0) et la RFC 2616 [18], qui illustre la version 1.1 et qui est
le standard en vigueur actuellement.
- 16 -
Pour mieux comprendre ce protocole on peut utiliser le cadre du modèle OSI* [23], formalisé par l’ISO dans
son standard 7498. Ce modèle divise la problématique de la communication en 7 sous-problèmes
indépendants qui se traduisent par 7 couches de protocoles organisés de façon hiérarchique. Un
rapprochement exact entre ce modèle et le modèle de protocoles Internet n’est cependant pas possible, car le
développement de ce dernier n’a pas été défini selon le premier, même s’il y a beaucoup de similitudes. La
Modèle
HTTP
HTTP
TCP/UDP
IP
Liaison
Physique
Modèle OSI
Application
Présentation
Session
Transport
Réseau
Liaison
Physique
Description des fonctionnalités de la couche selon le modèle OSI
Fournit un service de communication à une application particulière
Fournit une syntaxe de transfert commune comprise par les deux entités en communication
Définit le dialogue et les modalités d’échange entre les deux entités en communication
Maintien et contrôle la liaison entre les deux entités en communication, garanties de service possibles
S’occupe de l’acheminement des données vers le bon destinataire
Maintien et contrôle la liaison entre deux équipement proches
Se charge de la codification, envoi et réception des données sur le médium de transmission
Figure 3 : Comparaison modèle OSI et modèle TCP/IP
figure 3 rapproche les deux modèles.
En simplifiant, HTTP est généralement classé comme étant un protocole de niveau Application; en réalité les
fonctionnalités couvertes par ce protocole s’étendent au niveau Présentation et se préoccupe essentiellement
de la définition (structure et format) des requêtes et réponses HTTP, mais il ne gère cependant pas les
sessions (on dit aussi qu’il est un protocole sans état). Les autres protocoles TCP et UDP correspondent au
niveau Transport et IP correspond au niveau Réseau. Le modèle IP/TCP ne spécifie pas les deux couches
inférieures et les trois couches supérieures sont généralement prises en charge par les protocoles
d’application.
Pour le transfert de ses données, HTTP doit invoquer les services d’un protocole de niveau inférieur. HTTP a
été conçu pour travailler au-dessus d’un protocole de transport qui fournit une certaine garantie de service et
ne possède pas de mécanismes pouvant garantir cette garantie, c’est pour ce motif qu’il est habituellement
implémenté comme couche supérieure de TCP. Il est toutefois également possible d’utiliser le protocole de
transport UDP ou d’utiliser directement le protocole IP sans passer par un protocole de transport, mais alors
les transferts HTTP ne bénéficient d’aucune garantie de service.
HTTP est un protocole de type requête/réponse. La communication se fait en deux temps (figure 4): un client
formule une requête contenant essentiellement le type de requête (méthode), la localisation de la ressource,
(URL), la version du protocole et des informations complémentaires sur soi-même et la requête. Elle est
ensuite transmise au serveur par le moyen du réseau en utilisant les services offerts par les protocoles
inférieurs. Le serveur examine la requête, effectue les traitements nécessaires et produit une réponse
contenant le statut de la requête (qui permet d’indiquer si la requête a été traitée correctement ou si des
erreurs ont survenu), la version du protocole, des informations optionnelles sur le serveur et possiblement la
ressource demandée. Elle est ensuite envoyée en retour au client pour qu’il puisse extraire la ressource
demandée et la restituer à l’utilisateur qui en a fait demande.
Requête HTTP
Traitement
Réponse HTTP
Serveur
Clie
Figure 4: HTTP: communication en 2 temps
- 17 -
La structure générale de tout type de message HTTP, requête et réponse, est la suivante: une ligne de début,
une ou plusieurs lignes de en-têtes (qui comprennent des informations générales, des informations
spécifiques au messages, à l’entité qui a émis le message et à la ressource demandée), une ligne vide et un
corps de message optionnel.
Une requête HTTP est essentiellement un ensemble de lignes envoyées par le navigateur qui correspondent à
la structure décrite précédemment. Elle commence par une ligne de requête qui précise la méthode à
appliquer, l’URL de la ressource demandée et la version du protocole. Ensuite il peut y avoir une ou
plusieurs lignes d’en-tête permettant d’envoyer des informations supplémentaires, une ligne vide et un corps
de requête optionnel.
La RFC spécifie un certain nombre de méthodes utilisables dans la requête. Dans cet travail on va focaliser
notre attention sur les méthodes GET et POST, car ce sont les deux méthodes disponibles pour envoyer au
serveur les données provenant d’un formulaire. Le premier est utilisé de façon générale pour demander au
serveur le transfert d’une ressource identifiée par l’URL contenue dans la requête. Il offre également la
possibilité d’envoyer des données au serveur incluant dans l’URL. Le deuxième permet d’envoyer des
données à un serveur en les incluant dans le corps de la requête et de demander le transfert d’une ressource
qui indique le résultat du traitement des données.
La réponse a une structure similaire: elle commence par une ligne de statut composée de la version du
protocole, d’un code permettant de communiquer le résultat du traitement de la requête et d’un texte
explicatif associé au code. Cette ligne est suivie d’un certain nombre d’en-têtes, d’une ligne vide et d’un
corps optionnel contenant la ressource demandée.
Les codes de statut sont codifiés sur 3 chiffres et définis en 5 familles: message informatif, traitement réussi
avec succès, redirection (le client devra alors envoyer une deuxième requête au serveur indiqué par la
réponse), erreur de la part du client (qui peut consister entre autre en une requête mal formulé ou qui porte
sur une ressource qui n’existe pas ou dont le client n’est pas autorisé à demander le transfert) et erreur de la
part du serveur (lorsque le serveur ne réussit pas à satisfaire une requête valide).
On dit que HTTP est un protocole sans mémoire d’état, car il traite chaque requête indépendamment les unes
des autres et en particulier sans tenir compte des requêtes précédentes: lorsque un serveur répond à une
requête il ferme aussitôt la connexion et ne garde en mémoire aucune information sur la requête. Ceci offre
l’avantage considérable de pouvoir satisfaire une requête dans un temps très réduit (ce qui revient au même
de dire qu’il est possible de satisfaire plus de requêtes dans le même lapse de temps), cependant cela pose des
limitations lorsqu’on veut développer des applications Web, par exemple des sites de commerce
électronique, où on aimerait pouvoir garder en mémoire les actions de l’utilisateur dans les précédentes
requêtes. Les solutions de pages dynamiques permettent de pallier les limitations du protocole http en
fournissant des mécanismes pour la gestion des sessions.
4.5
L’évolution des besoins
Au début le Web a été conçu comme un moyen de publication d’informations et de structuration de
documents de types différents qui pouvaient être consultées à l’aide d’une interface unique, le navigateur.
Dans ses premières années de vie, le Web est essentiellement utilisé comme outil académique favorisant la
recherche scientifique, son utilisation principale étant la publication des résultats des différents projets de
recherche.
L’architecture du Web des premières années, qu’on peut estimer entre 1990 et 1995, était basée sur
l’utilisation de pages statiques axés davantage sur le contenu des documents que sur la présentation: les
premières versions du langage HTML définissaient en effet essentiellement des balises permettant la
structuration logique du contenu des documents; ce n’est que dans les versions suivantes que sur l’aspect
graphique des documents a commencé à prendre importance. L’utilisation de simples pages statiques ne pose
aucun problèmes à ce stade, car il y a relativement peu de pages à écrire, leur mise à jours est peu fréquente
- 18 -
et il n’y a pas de besoin d’interactivité à travers le Web (d’autres services tel que l’e-mail et les forums de
discussion répondent bien aux besoins d’interaction avec les autres chercheurs).
L’essor de l’activité commerciale sur le Web, qui se développe à partir de 1995, influence la façon dont les
Web est utilisé: d’un simple média de publication de documents structurés, le Web devient un média de
communication utilisé pour véhiculer l’image des entreprises: la mise en page et l’aspect graphique des sites
commencent à prendre plus d’importance. Le langage HTML est retouché pour répondre à ces nouveaux
besoins, incluant un certain nombre de nouvelles balises permettant de mieux contrôler la façon dont les
informations sont présentées.
Les premières pages commerciales étant essentiellement des « brochures » électroniques qui présentent
l’entreprise, l’utilisation de pages statiques au graphisme soigné est plus que suffisante, car le nombre de
pages, la fréquence de mise à jour et l’interactivité requise sont encore faibles.
Avec l’utilisation du Web non plus seulement comme canal de communication, mais aussi comme canal de
transaction, avec l’émergence de sites de commerce électronique et des services interactifs tels que les
portails et les moteurs de recherche, les limitations des pages statiques commencent à devenir des problèmes
importants. En effet sous l’impulsion de la croissance du volume de pages à mettre en ligne, de leur
fréquence de mise à jour et de la volonté de créer des pages réellement interactives, les pages statiques à elles
seules ne permettent plus de répondre de façon économiquement viable aux attentes de plus en plus grandes
de la part du public et à la croissance du volume de travail qu’il faut faire manuellement pour construire et
maintenir ces sites. Les solutions utilisant la programmation de pages dynamiques commencent à apparaître.
L’évolution économique, technologique et sociologique récente a rendu les limitations des pages statiques
encore plus évidentes: les exigences en termes de volume, mise à jour, et interactivité deviennent de plus en
plus grandes. Dans cette situation l’utilisation de pages statiques n’est plus soutenable et le passage à des
solutions dynamiques s’impose.
Parmi les phénomènes qui ont le plus contribué a cet accroissement des exigences des utilisateurs, on peut
mettre en évidence la mondialisation de l’économie, la rapidité croissante du cycle de vie des produits et des
innovations technologiques, l’importance croissante de l’individualisme et de la personnalisation (reflétée
dans des nouvelles orientations de management, comme le CRM8, le one-to-one marketing) et les attentes de
plus en plus exigeantes des navigateurs.
Il faut toutefois noter que les pages statiques restent préférables dans un certain nombre de cas, surtout
lorsqu’il s’agit de petits sites ou de sites de présentation qui ne sont pas souvent mis à jour. On va discuter
des avantages et inconvénients respectifs des pages statiques et dynamiques dans le chapitre suivant.
5
Les pages statiques
Les pages statiques sont la première forme d’utilisation du Web et il semblerait qu’elles constituent encore
aujourd’hui la majorité des pages du Web. Cependant il faut constater que leur proportion est de plus en plus
en diminution par rapport à la percée des pages dynamiques dans le monde du Web.
Ce qui différencie les pages statiques des pages dynamiques est la façon dont le contenu de la page est créé.
Pour les pages statiques, le contenu est figé lors de leur construction et ne peut pas changer automatiquement
sans qu’une personne le modifie explicitement. En d’autres mots si aucune intervention n’est effectuée pour
apporter des modifications sur le document, le contenu présenté aux demandeurs de la page sera toujours le
même (quant à l’apparence, elle est en grande partie influencée par les options des navigateurs et il se peut
qu’elle diffère d’un navigateur à un autre).
8
Customer Relationship Management
- 19 -
Le fonctionnement du Web dans le cas d’une page statique est représenté dans la figure 5. Le développeur de
la page Web écrit sa page en utilisant le formalisme du langage HTML et l’enregistre sur le disque du
serveur. Ensuite les utilisateurs peuvent y accéder en formulant une requête contenant son URL. Le serveur
localise ensuite la page demandée et, s’il la trouve, il la copie telle quelle dans le corps de la réponse
transmise au client. Le traitement coté serveur se limite à la localisation du fichier et à son encapsulation
dans une réponse HTTP (en ajoutant les en-têtes de la réponse HTTP à la page qui en constitue le corps).
3. Traitement de la requête
et localisation de la page
2. Requête HTTP
5.
Vîsualisation
disque
4. Réponse
HTTP
Client
1. Création de la
page HTML et
publication sur le
serveur
Serveur
Figure 5 : Les pages statiques
Normalement la première étape, qui intervient lors de la création et de la modification d’une page Web
statique, est réalisée par une personne en utilise un éditeur de texte (tel que Notepad, Emacs ou Ultraedit), un
logiciel de traitement de texte (tel que Microsoft Word ou Wordperfect) ou un éditeur visuel de type
WYSIWYG* (tel que Dreamweaver ou Frontpage). Ces derniers permettent de développer une page beaucoup
plus vite et avec une meilleure précision, cependant le code qui en résulte peut être difficile à maintenir.
Il existe toutefois une autre possibilité qui consiste à utiliser un langage de programmation pour créer ou
mettre à jour les pages statiques et les publier sur le serveur. En théorie il est possible d’utiliser n’importe
quel langage de programmation, toutefois il est préférable d’utiliser un langage de programmation qui a des
fonctionnalités avancées de traitement des textes comme C, Perl et Java. Même en utilisant un langage de
programmation, ce type de démarche peut néanmoins être classé dans la section liée aux pages statiques, car
même si la page est créée automatiquement, une fois qu’elle est publiée sur le serveur Web sont contenu est
figé, au moins jusqu’à la mise à jour suivante. C’est en quelque sorte une solution intermédiaire entre les
pages statiques édités manuellement et les solutions de création de pages dynamiques.
Cette solution permet de surmonter certains problèmes liés à l’utilisation de pages statiques édités
manuellement (notamment les problèmes liées à la croissance du nombre des page à publier et de leur
fréquence de mise à jour) et offre l’avantage d’une plus grande rapidité de traitement des requêtes par rapport
aux pages dynamiques. Cependant elle est plus complexe par rapport à l’édition manuelle de pages statiques
et à certaines solutions pour la création de pages dynamiques et ne permet pas de surmonter toutes les
limitations tel que l’on peut faire avec ces dernières, en particulier elle ne permet pas de pallier le manque
d’interactivité avec l’utilisateur, de différencier le traitement en fonction de la requête et l’impossibilité de
gérer les sessions.
Cette solution est envisageable dans un certain nombre de cas, par exemple lorsqu’on veut publier les
nouvelles du jour à partir d’un fichier texte qu’on a reçu d’une agence de presse ou qu’on veut mettre à jour
le prix des articles du catalogue d’un site marchand en partant d’un fichier extrait du système d’information
de l’entreprise.
Les sections suivantes passent en revue les limitations inhérentes à l’utilisation des pages statiques et leur
importance en vue des évolutions des besoins et des attentes liées au Web.
- 20 -
5.1
Limitations des pages HTML statiques
5.1.1 Création préalable de chaque page
Cette première limitation vient du fait que dans le cas d’utilisation de pages statiques, chaque page d’un site
doit être créée et publiée sur le serveur préalablement à sa consultation. En plus de devoir rédiger le contenu
de chaque page et veiller à sa cohérence avec les autres pages, les liens vers chaque nouvelle page doivent
être explicitement modifiés dans chaque page qui leur fait référence: pour ajouter effectivement une page à
un site on risque bien de devoir en modifier plusieurs.
Ceci ne pose pas de problèmes lorsque le nombre de pages à écrire est peu élevé. Au contraire, la réalisation
de quelques pages isolées ou des petits sites est beaucoup plus rapide avec l’utilisation d’un éditeur texte ou
visuel pour créer de simples pages HTML statiques. Des exemples d’applications qui correspondent à ces
deux catégories sont la création d’une page personnelle, la publication d’un document de recherche comme
c’était le cas dans les premières utilisations du Web par la communauté scientifique et les sites de
présentation de type brochure informationnelle d’une petite société ou association.
Cependant lorsque le nombre de pages à mettre en ligne devient plus important, le fait de devoir créer et lier
ces pages les unes aux autres de façon manuelle devient une lourde tache qui nécessite bientôt plus de
ressources que les ressources qu’on employerait dans l’utilisation d’une solution de création de pages
dynamiques. Les problèmes liés au volume de pages à créer peuvent être surmontés en utilisant les
possibilités données par la programmation pour automatiser la création de pages dynamiques, au moment de
la requête de l’utilisateur, ou statiques, avant de les publier sur le serveur. Ces solutions permettent de tirer
profit des avantages de l’automatisation des traitements grâce à l’utilisation d’un langage de programmation,
mais demeure cependant plus compliquée à mettre en œuvre.
En effet, bien qu’il soit plus rapide de créer quelques pages statiques que de développer une infrastructure
qui en permet la génération dynamique, une fois écrits que les programmes de génération de pages, l’ajout
d’une nouvelle page ne prends qu’une fraction du temps qu’il faudrait pour la créer manuellement. Lorsque
le nombre de pages est grand, le temps total utilisé pour développer cette infrastructure est plus que
compensé par le temps épargné à ne pas devoir écrire les pages une par une. Pour mieux se rendre compte de
la relation entre temps de développement et nombre de pages, la figure 6 présente un graphique avec les deux
dimensions citées.
Temps de
développement
Pages statiques
édités manuellement
Pages dynamiques générés
par un programme
Nombre de pages
Figure 6 : Temps de développement en fonction du nombre de pages à créer
L’évolution récente du Web a porté à la création de sites beaucoup plus riches en contenu et avec un nombre
beaucoup plus élevé de pages. Il suffit de penser par exemple à l’apparition des sites marchands de vente en
ligne, des sites d’enchères électroniques ou des sites d’informations dans lesquels il faut présenter un
catalogue d’articles ou une collection de nouvelles très vaste.
- 21 -
L’augmentation très forte du nombre de pages explique en partie le recours à des solutions pour la création
automatique des pages Web à partir de programmes. Cependant cela n’explique pas à lui seul l’essor des
solutions de création de pages dynamiques, car la création de pages statiques par programmation avant leur
publication sur le serveur Web lui est supérieure sur le plan des performances et est particulièrement
adéquate lorsqu’il faut générer des pages dont on sait que le contenu reste figé pour un certain lapse de
temps, mais demeure plus difficile à mette en oeuvre. A titre d’exemple des cas d’utilisation de cette
technique, on peut citer la création de pages de façon périodiques à partir d’informations contenues dans un
fichier ou un système d’information, tel qu’un site d’information qui chaque jour doit publier les nouvelles
de la journée qu’il reçoit des différentes agences de presse ou un site d’entreprise qui doit publier le
catalogue pour la saison suivante.
Les autres limitations qu’on recense par la suite expliqueront mieux l’essor les solutions pour la création des
pages dynamiques qui constitue quand même une réponse possible aux problèmes liés au volume de pages à
créer.
5.1.2 Problèmes de mise à jour
Cette deuxième limitation est due au fait que pour mettre à jour une page statique, quant à son contenu ou à
sa présentation, il faut la réécrire en y apportant les modifications voulues. La modification des pages
statiques est un travail fastidieux, long et généralement manuel qui nécessite d’ouvrir chaque fichier qu’il
faut modifier, rechercher l’endroit où on veut apporter les changements nécessaires et l’enregistrer à nouveau
sur le serveur. Il est possible d’automatiser la modification par l’écriture d’un programme qui prend en entrée
la page à modifier, suit les instructions de modifications souhaitées et produit en sortie la nouvelle page.
De nouveau ceci devient un problème lorsque le volume de modification à apporter devient important, parce
que le nombre de pages est élevé ou parce que les modifications à apporter sont fréquentes. Si tel est le cas,
la maintenance du site nécessite beaucoup de temps, ce qui coûte cher en salaires et rallonge les délais
d’introduction de nouvelles fonctionnalités. Si on représentait graphiquement l’évolution du temps de mise à
jour des pages en fonction du nombre de mises à jour à effectuer on obtiendrait une figure similaire à la
figure 6 présentée dans la section précédente.
En plus de ne pas être économiquement souhaitable lorsque le nombre de mises à jour devient grand, dans
les cas où les informations doivent être mises à jour plusieurs fois par jour ou même en temps réel (par
exemple les news et les informations financières) la solution de mise à jour manuelle de pages statiques est
tout simplement irréaliste. Dans le cas d’informations en temps réel, l’utilisation d’un programme de mise à
jour de pages statiques n’est non plus envisageable, d’une part à cause de l’important travail supplémentaire
effectué par le programme de modification, qui doit ouvrir chaque page statique, la parcourir pour chercher
les endroits où il faut la modifier, la modifier et la publier à nouveau sur le serveur, d’autre part par le
mécanisme de mémorisation des pages statiques dans la mémoire tampon (cache) des navigateurs et
équipements intermédiaires, qui empêcherait d’avoir la nouvelle page automatiquement rechargée à chaque
fois et présenterait la page demandée auparavant.
L’utilisation d’un système de génération de pages dynamiques permet de faciliter grandement la maintenance
et la mise à jour du site, permettant de construire dynamiquement le contenu à partir de fichiers ou de bases
de données, effectuer des traitements selon des fonctions réutilisables et de manipuler l’aspect présentation à
travers l’inclusion de modèles de page. Pour mettre à jour les pages il suffit donc de mettre à jour la base de
données ou changer une fonction ou un modèle de page. Ceci permet aussi de faciliter le maintien d’une
cohérence globale du site.
5.1.3 Fusion du contenu et de la présentation
- 22 -
La fusion du contenu et de la présentation implicite dans l’utilisation du langage HTML vient aggraver les
deux problèmes précédents. En effet une page HTML est un simple fichier texte qui mélange des instructions
de présentation (les balises HTML) au contenu de la page.
La fusion entre les deux comporte un certain nombre de problèmes. Lors du développement de nouveau
contenu il faut réécrire dans chaque page les parties concernant la présentation, ce qui prend de temps et
risque d’introduire des incohérences dans la présentation des différents pages créés par des personnes
différentes ou à des moments différents. Lors de la maintenance du site, lorsqu’on veut changer le contenu
ou l’aspect graphique d’un certain nombre de pages, il faut parcourir le texte composant les pages et chercher
les endroits où il faut effectivement apporter les modifications, ce qui comporte une charge de travail
considérable. Par exemple, lorsqu’on veut changer la ligne graphique d’un site, il faut retravailler toutes les
pages concernées en parcourant les page pour identifier les endroits où il faut apporter les modifications.
Un progrès dans le sens de la séparation de la présentation et du contenu a été fait dans la nouvelles
spécification du langage HTML qui permet désormais l’utilisation de feuilles de styles (CSS*) et des cadres
(frames). Les feuilles de styles permettent de spécifier des consignes de présentation qui peuvent être inclues
dans toutes les pages d’un site contribuant ainsi à la cohérence graphique du site et à la facilité de modifier
ces consignes de présentation. Il faut toutefois noter que leurs implémentation dans les navigateurs diffèrent
(les différents navigateurs ne supportent pas de la même manière les feuilles de styles, ne reconnaissant
qu’un sous-ensemble des fonctionnalités offertes et différant ainsi dans la façon dont les pages sont
visualisées) et que les vieilles versions ne les supportent pas. La séparation qui peut être obtenue avec les
cadres est rudimentaire: il est possible de confiner des éléments communs à toutes les pages (i.e. une barre de
menu latérale,…) dans des « sous-fenetre » invisibles et indépendantes. Cette solution pose cependant
d’autres problèmes, telle que la gestion des fenêtres.
En plus, la gestion des contenus et du graphisme ne sont pas séparables et sont typiquement confiés à des
personnes responsables de la maintenance et le développement du site (les webmasters). Si les deux aspect
étaient séparés, leur gestion pourrait être confiée à différentes personnes. En particulier la gestion des
contenus pourrait être confiée à des professionnels du contenu (par exemple à travers l’utilisation d’une
application de gestion de contenu) et ne laisser que la gestion du graphisme et des tâches plus techniques à
des spécialistes tels que les webmasters.
Avec la génération de pages dynamiques les deux aspects peuvent facilement être séparées, notamment avec
la possibilité d’extraire le contenu à partir de sources telles que des fichiers texte ou des bases de données et
de construire des pages à partir de modèles communs.
5.1.4 Interactivité
L’interactivité des sites Web est devenue de plus en plus importante. Les internautes ont pris l’habitude de
visiter des sites interactifs, qui réagissent à leurs actions, fonctionnent de façon similaire à des véritables
applications, sont souvent mis à jour et mettent en œuvre les nouvelles technologies fréquemment. Ces sites
offrent des possibilités avancées telle que la possibilité de personnalisation, les possibilités d’effectuer des
recherches, ont des graphiques et de l’information en temps réel, etc.
Le problème principal des page statiques, est leur total manque de possibilités d’interaction avec l’utilisateur
et avec les autres systèmes informatiques. Même en utilisant un programme qui automatise leur création et
maintenance, l’interaction avec l’utilisateur est toujours régie par les trois mécanismes de base présentés dans
le chapitre précédent. Ces mécanismes ne prévoient aucune possibilité d’interaction avec l’utilisateur si ce
n’est pas la possibilité de collecter des formulaires envoyés sous forme d’e-mail des visiteurs (mais ne
permettent pas de fournir une réponse différente en fonction des données fournis et du résultat de leur
traitement). En effet il n’y a aucun mécanisme dans l’architecture du Web classique qui permette d’effectuer
des traitements sur les données reçus (elles doivent être confiées à des programmes externes), d’effectuer des
traitements différents selon certaines conditions et le fait qu’il faut créer les pages préalablement à leur
utilisation limite l’emploi des pages statiques à des cas déterminés à l’avance.
- 23 -
Ce manque de fonctionnalités d’interaction peut s’expliquer par la façon dont le Web a été conçu: le Web
était essentiellement un mécanisme de publication d’information de différent types, composés au début
surtout des résultats de recherche scientifiques, qui donnait aux utilisateurs la possibilité de consulter ces
informations à travers une interface unique. Dans ce but, la possibilité d’interagir avec les utilisateurs
directement à travers le Web était inutile: l’interaction éventuelle avec les autres utilisateurs du réseau était
confiée à des mécanismes qui avaient été conçu dans ce but et qui fonctionnaient très bien, comme l’e-mail et
les news.
Des fonctionnalités telles que la personnalisation d’un site, la réponse à une requête d’un utilisateur (i.e.
recherche par mots clé), la personnalisation du site en fonction des préférences de l’utilisateur, l’envoi de
pages différentes en fonction des possibilités du navigateur qui en a fait demande, l’intégration avec le
système d’information de l’entreprise, les systèmes de prise de commande sophistiqués (i.e. contrôler la
disponibilité d’un article), les systèmes de payement etc. ne peuvent pas être implémentés à l’aide de pages
statiques et l’utilisation de pages dynamiques s’impose.
5.2
Avantages des pages HTML statiques
Les pages statiques n’offrent pas seulement des inconvénients par rapport à l’utilisation de solutions plus
sophistiquées telles celles présentés dans le chapitre suivant.
Les pages statiques sont plus simples à construire et ne nécessitent pas des connaissances particulières. Leur
construction peut être confiée à des personnes qui ont des simples connaissances dans le HTML ou qui
savent utiliser un éditeur spécialisé, qui, dans les deux cas, sont assez faciles à apprendre. Par contre la
création de pages dynamiques nécessite la disponibilité de personnes qui ont des connaissances en
programmation, qui coûtent plus cher et qui sont beaucoup pas difficiles à trouver.
En particulier, chacun peut construire ses pages HTML, même en ne connaissant pas le langage, en utilisant
un éditeur spécialisé dans la création de pages Web. Sur le marché existent un certain nombre d’éditeurs qui
permettent la création d’une page à travers une interface graphique de type « pointer et cliquer », où on doit
choisir les composants de la page à afficher et les placer à l’endroit voulu. Ces éditeur, qui vont très biens
pour créer des pages avec des fonctionnalités standard, ont aussi quelques désavantages et il est conseillé de
connaître quand même les bases du langage HTML, pour pouvoir créer des pages avec des fonctionnalités
non prévues dans ces éditeurs ou simplement créer des pages qui sont plus faciles à comprendre et maintenir
par la suite.
Il faut toutefois noter que la création des pages Web avec un simple éditeur texte est aussi assez simple, car
le langage HTML est assez facile à comprendre et utilise une syntaxe simple et claire. Ceci est d’autant plus
vrai que l’utilisateur utilise un éditeur spécialisé qui permet de mettre en évidence les balises HTML à
travers une coloration syntaxique et aident l’utilisateur en lui proposant de compléter les balises et en lui
indiquant les attributs supportés. Il existe par ailleurs des outils permettant de vérifier la validité syntaxique
de la page.
Lorsqu’il faut créer seulement quelques pages ou un petit site qui n’a pas besoin de consulter d’autres
systèmes informatiques pour le contenu à présenter et ne nécessite pas d’une réelle interaction avec le client,
l’utilisation de pages statiques offre l’avantage de ne pas nécessiter de la mains d’œuvre hautement
spécialisée et de prendre beaucoup moins de temps.
Un autre grand avantage des pages statiques est que leur traitement effectué par le serveur est extrêmement
simple et rapide. En effet le seul traitement effectué par le serveur est l’interprétation de la requête, la
localisation du fichier et son inclusion dans la réponse envoyée au client. Ceci permet de pouvoir fournir une
quantité de pages beaucoup plus élevée dans un même lapse de temps par rapport à la fourniture de pages
dynamiques. Sous un autre angle, ceci signifie qu’il est possible d’atteindre les mêmes performances en
nombre de pages servies aux utilisateurs en utilisant moins de ressources ou des équipements moins chers.
Pour un certain nombre de sites ou des sections du site où les impératifs de mise à jour en temps réel, de
- 24 -
personnalisation et d’interactivité sont inférieurs aux impératifs de volume trafic et de coût des ressources,
l’utilisation de techniques de programmation pour la création de pages statiques qui sont ensuite publiées sur
le serveur est une meilleure solution que de se lancer dans la création dynamique de chaque page au moment
de chaque requête.
- 25 -
6
Les pages dynamiques
Cette section commence avec la définition du concept de page dynamique et la présentation du
fonctionnement général. Ensuite les différentes solutions disponibles actuellement pour la génération de
pages dynamiques sont passés en revue, en les présentant d’abord et en analysant des points d’intérêt dans
une application Web. Ces points passent en revue les fonctionnalités qu’il est possible d’implémenter à l’aide
de ces solutions, la productivité dans le développement des pages, la portabilité, la sécurité et la séparation
entre contenu, logique de traitement et présentation.
Une page dynamique est une page Web dont le contenu est généré au moment de la requête du client. Elle ne
diffère par rapport aux pages statiques décrites précédemment que par façon dont elle est générée: tandis que
les pages statiques sont crées avant leur utilisation et sont servies telles quelles aux clients qui en font
demande, les pages dynamiques sont crées au moment même de la requête du client en fonction des
instructions contenues dans un programme (on parle aussi de script) qui en définit la génération.
Dans plus de détail le processus de génération des pages dynamiques suit le cycle suivant. En premier lieu il
faut créer les scripts contenant les instructions nécessaires pour créer la page et les publier sur le serveur. Ces
instructions sont issues d’un langage de programmation; pour être plus précis, on parle dans certains cas de
langages de script pour designer des langages de programmation allégés, interprétés et insérés directement à
l’intérieur des pages HMTL. Ces programmes contiennent les instructions à renvoyer au client qui en fait
demande: en particulier les programmes peuvent effectuer des accès à des systèmes de stockage de données
pour rechercher le contenu des pages, effectuer un certain nombre de traitements et écrire la page elle même.
Lorsque la page est demandée par un client, le fichier contenant les instructions nécessaires pour construire
la page HTML est passé, en même temps que tous les données contenues dans la requête, à un moteur
d’interprétation de scripts capable d’exécuter les instructions contenus dans le fichier. Le résultat de
l’exécution du script est une page Web ordinaire. L’exécution des scripts peut être faite soit sur la machine
serveur, soit sur la machine cliente, soit sur les deux (la page généré coté serveur contient en plus que du
HTML, des instructions à interpréter coté client).
On peut donc distinguer deux grandes familles de solutions pour la création de pages dynamiques selon
l’endroit où les fonctionnalités de création de la page de façon dynamique sont placées: les solutions coté
client et les solutions coté serveur. Dans la première famille, le travail de création de la page se fait sur la
machine client: le moteur d’interprétation est souvent installé comme composant du navigateur. Pour des
motifs de sécurité, ce dernier offre à l’utilisateur la possibilité d’autoriser ou pas l’exécution des programmes
contenues dans les page Web sur sa machine. Dans la deuxième, le travail s’effectue sur le serveur en
utilisant un moteur d’interprétation installé comme extension au serveur. Le serveur doit être configuré pour
faire en sorte que les requêtes portant sur des page dynamiques (reconnaissables grâce à leur extension)
soient traités par le bon moteur.
Ces deux familles ont des fonctionnalités assez différentes et peuvent être utilisées en même temps. Le défi
est alors de décider quelles fonctionnalités implémenter du coté client et quelles du coté serveur en se basant
sur des critères d’efficacité, performance, portabilité et sécurité.
En particulier les solutions coté client permettent d’avoir une plus grande proximité avec l’utilisateur, ce qui
leur donne la possibilité de réagir directement et plus rapidement aux actions de l’utilisateur sans devoir
passer à chaque fois par un échange requête-réponse avec le serveur. Ceci est surtout utile pour contrôler des
données dans un formulaire avant de l’envoyer au serveur ou pour implémenter des fonctions tels que des
menus. Une autre utilisation pour laquelle les solutions coté client sont utilisé sont l’insertion de programmes
permettant d’implémenter des effets graphiques. Ces solutions ont cependant les défauts d’être liés à
l’implémentation du navigateur sur la machine cliente et de présenter des risques de sécurité accrus; ceci
limite l’audience qui peut recevoir ces pages soit parce que le programme écrit n’est pas compatible avec le
logiciel installé sur la machine cliente, soit parce que l’utilisateur préfère renoncer à l’exécution des
programmes pour des motifs sécuritaires. Un autre désavantage est que la performance dépend de la machine
- 26 -
cliente et il n’est pas souhaitable d’effectuer des accès à des systèmes de stockage de données à partir de la
machine cliente.
Les solutions coté serveur sont plus éloignés du client et nécessitent d’un échange réseau complet pour
pouvoir répondre aux actions de l’utilisateur. Elles profitent cependant d’autres caractéristiques intéressantes.
En premier lieu, les pages produites par ce genre de solutions est tout à fait similaire aux pages statiques (ou
des pages contenant des programmes à exécuter coté client). Ceci permet d’atteindre la totalité de l’audience
sans se soucier ni de la version particulière du navigateur utilisé par les utilisateurs, car on peut utiliser du
HTML standard ou tailler les pages différemment en fonction du navigateur qui en a fait la requête, ni des
problèmes sécuritaires, car étant du simple HTML, les pages ne peuvent pas faire des dommages aux
machines clientes. Un deuxième grande avantage est le fait que les serveurs peuvent se connecter à une
multitude de systèmes à partir desquels tirer les données et un certain nombre d’autres services. Elles posent
cependant en plus le problème de la scalabilité, c’est à dire de la réaction des performances à la croissance du
volume de trafic.
Dans les sections suivantes on va présenter ces deux grandes familles, leur mode de fonctionnement et les
solutions qui sont actuellement disponibles pour générer des pages dynamiquement.
Une dernière chose qu’il faut toutefois noter est que les solutions pour la génération de pages dynamiques ne
fonctionnent pas bien avec d’autres applications Web, tels les programmes utilisés par les moteurs de
recherche pour parcourir et indexer le Web. Ceci signifie que les moteurs de recherche ne référenceront pas
ou pas bien le contenu des pages dynamiques (qui est en effet supposé changer à chaque requête) et qu’il sera
par conséquent plus difficile pour les utilisateur de trouver des pages dynamiques appropriées à leurs
recherches. Il faudra faire un effort supplémentaire dans la conception du site pour permettre à ces moteurs
de référencer correctement les pages du site.
6.1
Solutions coté client
Le fonctionnement des solutions de génération de pages dynamiques coté client est présenté dans la figure 7.
Le client formule et transmet une requête au serveur et celui-ci localise le fichier correspondant et envoie en
retour une réponse contenant la page demandée. Jusqu’à ce point la démarche est identique à celle utilisé
dans le cas des pages statiques.
Contrairement aux pages statiques, la page reçue par le navigateur contient en plus des instructions HTML,
des instructions dans un langages de programmation à exécuter avant de visualiser la page. Ces instructions
sont reconnaissables du reste de la page, car elles sont délimitées par des balises spéciales (en fonction de la
solution utilisée on utilise les balises <SCRIPT>, <APPLET> ou <OBJET>) permettant au navigateur de
savoir que le code compris à leur intérieur doit être interprété par le moteur approprié. L’exécution des
instructions contenues dans la page peut avoir lieu avant de visualiser la page ou en réponse à certains
événements.
2. Requête HTTP
3. Traitement de la requête
et localisation de la page
6.
Vîsualisation
disque
5. Interprétation
instructions
4. Réponse
HTTP
Client
Serveur
Figure 7 : Les pages dynamiques, coté client
- 27 -
1. Création de la
page HTML et
publication sur le
serveur
Le principal atout des solutions coté client est leur proximité avec l’utilisateur, ce qui leur permet de réagir
directement et plus rapidement aux actions de l’utilisateur sans devoir passer à chaque fois par un échange
requête-réponse avec le serveur. Ceci permet non seulement de donner un feed-back immédiat en fonction de
certaines actions de l’utilisateur, mais aussi de contrôler les données dans un formulaire, de programmer des
actions sur minuterie, de gérer certains éléments graphiques de la page (surtout des menus, des barres de
navigation et des effets graphiques), de gérer les fenêtres et de communique avec le serveur par ldes
protocoles qui ne sont pas supportés par les navigateurs.
Le fait de devoir s’exécuter sur la machine cliente comporte un problème important de sécurité, en effet le
code inséré dans les programmes pourrait être malveillant et effectuer des actions nuisibles au système de
l’utilisateur. C’est pour cela que des modèles de sécurité plus ou moins stricts sont associés à ces solutions.
Un deuxième problème est lié à la portabilité des pages, ce qui est un aspect important dans un
environnement ouvert comme Internet. Le problème est que ces solutions nécessitent que l’utilisateur ait
installé un navigateur capable de traiter les programmes insérés dans les pages; malheureusement les
différents navigateurs ne supportent pas toutes les solutions présentés et il y a quelques différences
d’implémentation qui peuvent poser des problèmes d’incompatibilité entre les différents produits.
Un problème secondaire est celui de la performance, qui est liée à la machine cliente et à l’implémentation
du moteur d’exécution dans le navigateur, qui ne sont pas souvent très performantes. A cela s’ajoutent le fait
de devoir télécharger le code à travers le réseau, ce qui peut impliquer un temps d’attente non négligeable
selon la taille du code.
Les différentes solutions sont affectées par ces problèmes dans des proportions différentes, comme on le
verra dans les sections qui leur sont dédiées. Cependant, de façon générale, l’existence de ces problèmes a
pour effet de limiter l’audience atteignable par l’intermédiaire de ces pages, soit parce que le programme
écrit n’est pas compatible avec le logiciel installé sur la machine cliente, soit parce que l’utilisateur préfère
renoncer à l’exécution des programmes pour des motifs sécuritaires, soit parce que l’utilisateur préfère ne pas
exécuter les programmes à cause de leur lenteur.
Ces problèmes, qui peuvent être importants dans un environnement hétérogène et peu fiable comme
l’Internet, sont toutefois partiellement résolus dans le cas où la page est accessible uniquement via un
IntraNet dont les développeurs peuvent connaître les navigateurs utilisés par les utilisateurs et ces derniers
peuvent avoir confiance dans les premiers. Une autre façon de diminuer le problème de compatibilité est
d’utiliser des solutions coté serveur pour tailler la page sur mesure aux capacités et aux préférences du
navigateur utilisé par le demandeur.
Il existe actuellement un certain nombre de solutions pour la création des pages statiques. On peut
catégoriser ces solutions su la base du type de programmes utilisés.
Un premier type de solutions est basé sur l’insertion de programmes complets qui s’exécutent dans des
containers insérés à l’intérieur des pages. Dans ce travail on va prendre en considération les deux principales
solutions qui appartiennent à cette catégorie: les Applets Java de Sun Microsystems et les Active X de
Microsoft.
Un deuxième type est basé sur l’insertion d’instructions issus d’instructions issus d’un langage de script
directement mélangées avec les instructions HTML. Dans cette catégorie on va analyser JavaScript et
VBScript. Etant donné la grande similitude entre les deux langages on les analysera ensemble dans la même
section.
Enfin on pourrait citer le cas des solutions basées sur des plus-in, qui permettent d’aller au-delà des
possibilités offertes par le langage HTML. Dans cette catégorie, à laquelle appartient par exemple Flash,
développé par Macromedia, on n’analysera aucune solution.
6.1.1 Applets Java
- 28 -
6.1.1.1 Présentation
Les Applets Java sont des petits programmes écrits en Java qui peuvent être insérés dans des pages Web. Ces
programmes sont téléchargés à travers le réseau et exécutés localement sur le système de l’utilisateur par le
biais d’une machine virtuelle Java implémentée dans le navigateur au moment de la réception de la page
Web.
Techniquement les Applets sont des classes qui héritent de la classe Applet définie par le langage Java. Cette
classe prévoit des méthodes permettant de les faire fonctionner au sein d’un navigateur et de traiter les
événements qui lui sont associés (initialisation, démarrage, arrêt) et des méthodes permettant d’utiliser
l’espace qui lui est réservé pour afficher son contenu et son interface utilisateur. Pratiquement la
programmation d’une Applet se fait en redéfinissant les méthodes de cette classe pour accomplir les tâches
souhaitées.
L’origine des Applets est le projet de développement du langage Java, développé entre 1991 et 1995 par Sun
Microsystems dans le but d’obtenir un langage de programmation permettant de contrôler les appareils
ménager du futur. Au cours de ce projet, les Applets sont développés parallèlement à, un navigateur
permettant de les visualiser (HotJava) dans le but de mettre en évidence le potentiel du langage et notamment
ce qu’il pouvait offrir au World Wide Web et le type de programme qu’il était possible de créer avec le
langage.
Bien que Java et HotJava réussissent à capter l’attention de la communauté du Web, le langage ne commence
vraiment s’imposer que lorsque Netscape achète une licence à Sun lui permettant d’implémenter dans son
navigateur une machine virtuelle permettant de faire fonctionner les Applets. Depuis lors le langage Java
connaît une notoriété et une adoption croissants. Dans peu de temps, les principaux navigateurs (dont il faut
noter Internet Explorer de Microsoft) implémentent leur version de la machine virtuelle.
Les Applets profitent des différentes caractéristiques propres au langage Java qui est utilisé pour leur
développement. En particulier le fait que Java est un langage orienté objet, fortement typé, dont les
programmes sont portables sans aucune modification sur n’importe quelle plate-forme disposant d’une
machine virtuelle Java, de l’étendue bibliothèque d’API de l’édition standard du langage, des mécanismes
qui permettent de spécifier le niveau de sécurité souhaité, du faible encombrement du langage qui permet de
réduire les temps de chargement etc.
Elles sont insérées dans des pages Web à l’aide des balises <APPLET> ou <OBJECT>, qui permet de définir
quel est le fichier du programme à exécuter ainsi que la portion de la page qui doit contenir l’Applet. Il est
également possible de passer des paramètres aux Applets en utilisant la balise <PARAM>.
6.1.1.2 Fonctionnalités
Les Applets offrent des possibilités remarquables, pouvant profiter des toutes les possibilités offertes par le
langage Java, pouvant notamment avoir accès à l’importante bibliothèque d’API qui est associée au langage
et qui donne accès à un considérable nombre de classes déjà programmées permettant de gérer une interface
utilisateur et des graphismes, d’exploiter les flux de données et les communications sur le réseau, de
décomposer le flux d’exécution du programme en plusieurs processus légers, d’avoir accès à des bases de
données, d’exploiter différentes structures de données, de programmer des composants logiciels réutilisables
(JavaBeans), des fonctions mathématiques, de manipuler des chaînes de caractères etc.
Bien que Java soit désormais dans sa deuxième version, la plupart des navigateurs actuels implémentent une
machine virtuelle basée sur une vieille version du langage. Il existe cependant un programme disponible
gratuitement, le Java Plug-in, qui permet de mettre à jour la machine virtuelle utilisée par le navigateur. Dans
un environnement hétérogène tel que l’Internet on ne peut pas partir de l’hypothèse que le public ait installé
ce module (ou qu’il ait envie de l’installer); par souci de compatibilité, il vaut mieux d’écrire les Applets
selon la version 1.0.2 du langage Java, celle qui est implémentée sur les principaux navigateurs compatibles
- 29 -
Java. Une certaine partie de la bibliothèque de Java 2 n’est donc pas exploitable. La situation est différente
dans le cas d’un réseau privé (IntraNet) où on connaît et on peut mettre à jour les systèmes clients.
Les applications des Applets sont très vastes et ne sont limitées que par les restrictions sécuritaires et par les
performances de téléchargement et exécution. A l’exception du fait que les Applets ne peuvent être exécutées
que dans un navigateur qui le supporte et qu’ils sont soumis aux restrictions sécuritaires qui leur sont
imposés, les Applets Java sont tout à fait équivalents aux normales applications Java.
Parmi les fonctionnalités les plus exploitées des Applets Java on trouve la possibilité d’insérer des effets
graphiques, des effets textuels, des animations et du son dans un document Web. En effet il existe un certain
nombre de packages Java sont dédiés au graphisme (par exemple awt et swing) et qui sont souvent utilisés
pour programmer des Applets. Ces éléments sont souvent utilisés pour capter l’attention de l’utilisateur (une
animation, une présentation d’images) ou pour gérer des éléments de la page tels des menus, des barres de
navigation et des arborescences.
Les mêmes packages permettent d’insérer dans l’Applet les principaux éléments constitutifs d’une interface
utilisateur graphique, tels des boutons, des champs de saisie, des menus,… Ceci permet de créer des
formulaires dont il est possible ensuite de valider les données des utilisateurs avant leur envoi sur le serveur.
Il est en outre possible de concevoir des véritables applications interactives, parmi lesquelles on peut citer
des jeux, des programmes de messagerie électronique graphique et des programmes de calcul.
La possibilité de communiquer avec le serveur qui abrite le programme permet à l’Applet d’utiliser des
protocoles autres que les protocoles prévus par le navigateur (qui sont habituellement les protocoles HTTP,
FTP et de messagerie électronique). Il est possible d’exploiter cette possibilité pour exploiter des services
mises à disposition par le serveur et pour faire fonctionner des applications reparties.
6.1.1.3 Productivité: bibliothèque d’API, réutilisabilité du code et logiciels de développement
La productivité du développement des Applets Java est influencée par un certain nombre de facteurs.
S’il est vrai que l’écriture du code Java est plus difficile et longue que les solutions de type langage de script,
à cause du fort typage et d’une syntaxe assez cryptique, surtout lorsqu’il faut se familiariser avec le langage
qui n’est guère facile à apprendre, ceci est compensé par toute une série d’aspect qui augmentent la
productivité des développeurs.
Avant tout les fortes contraintes syntaxiques et de typage permettent de faciliter le déboguage en évitant la
possibilité d’avoir des erreurs dues à la mauvaise écriture d’un nom de variable ou de l’utilisation d’une
variable avec un type différent de ce qu’on s’attend: les erreurs de ce type sont détectés au moment de la
compilation. Ceci est particulièrement important pour des projets d’une certaine taille et complexité.
Ensuite l’architecture objet du langage Java favorise à la conception d’un programme comme une collection
de classes qui offrent des fonctionnalités spécifiques, ce qui constitue un très bon départ pour concevoir un
code qui est facilement réutilisable.
La bibliothèque fournie avec la version standard du langage Java et l’excellente documentation qui
l’accompagne permettent aussi de rendre la programmation beaucoup plus rapide et fiable, car il est possible
d’accéder à toute une série de classes prêtes à l’emploi offrant des une grande vastitude de fonctionnalités
couvrant la plupart des besoins de programmation. Il est d’ailleurs assez facile d’étendre le comportement
d’une classe par héritage en incluant des nouvelles fonctionnalités. Ceci permet de concentrer son attention
sur des problèmes de plus haut niveau, en faisant abstraction des mécanismes de bas niveau implémentés par
les classes de la bibliothèque.
Il faut toutefois noter que les différents navigateurs implémentent des machines virtuelles Java basées sur la
première version du langage. Même s’il existe un Plug-in qui permet de mettre à jour la machine virtuelle et
donne la possibilité d’utiliser l’API de la deuxième version, dans un environnement comme l’Internet il vaut
mieux ne pas faire l’hypothèse que tout le monde l’ait installé ou ait envie de l’installer. Si on se soucie de
- 30 -
pouvoir atteindre le plus de monde possible, il vaut donc la peine de se restreindre à l’utilisation de la vieille
API.
Une multitude d’outils de développement et de modélisation permettent de rendre le développement
beaucoup plus rapide. En plus du Java Development Kit (JDK), il existe un grand nombre d’environnements
de programmation Java tels que Forte, Visual Café, Borland Jbuilder, Microsoft Visual J++, CodeWarrior,
SuperCede, Rogue Wave Jfactory, Natural Intelligence Roaster, Java WorkShop. Il existe aussi des outils
tels Togheter qui permettent de modéliser son application et traduisent cette modélisation en termes de code
Java à compléter.
6.1.1.4 Performance et scalabilité
Les Applets Java souffrent de quelques limitations qui affectent négativement leurs performances. Le
reproche est que les Applets nécessitent un temps considérable pour être téléchargés et même plus pour être
exécutés sur le navigateur. Ces problèmes de performances limitent les Applets à des programmes assez
simples.
Coté téléchargement, qui devrait être rapide grâce au faible encombrement du langage Java, le problème qui
se pose est que l’exécution de l’Applet ne commence que lorsque le transfert de l’Applet et de tous les
composants qui le constituent (des classes importées, des images utilisés, des fichiers, …) est terminé dans sa
totalité. Ceci est d’autant plus aggravé que ces différents composants sont téléchargés séparément les uns des
autres et qu’à chaque transfert il est nécessaire d’établir une connexion. Ce problème peut être réduit en
utilisant des archives Java (Jar) qui contiennent tous les composants dans un fichier unique et qui peuvent
même utiliser des techniques de compression.
Coté vitesse d’exécution, les Applets souffrent les maux des implémentations des machines virtuelles dans
les différents navigateurs, qui ne sont souvent pas très performantes et ne supportent qu’une vieille version
de la plate-forme Java. Pour remédier à ce problème, Sun met gratuitement à disposition des utilisateurs une
implémentation de référence, le Java Plug-in de la machine virtuelle qui est installable sur chaque plateforme et prendre en charge l’exécution des programmes Java avec des performances nettement meilleures et
le support de la deuxième version de la version standard du langage.
Etant une solution coté client, la performance est dépendant de la machine sur laquelle le programme est
exécuté, cependant ne souffre pas d’une diminution au fur et mesure que le nombre de requêtes reçues par le
serveur augmente (pour être plus précis, l’augmentation du trafic n’a pas plus d’impact sur les performances
que la même augmentation de trafic dans le cas de pages Web statiques), car le travail de traitement du code
est effectué sur les machines clientes et non pas sur le serveur, qui se limite à chercher la page demandée et
former la réponse HTTP à renvoyer au client. Si l’occupation des ressources du serveur n’est pas
préoccupant avec l’augmentation du trafic, l’occupation de bande passante risque d’être un problème,
d’autant plus que les Applets sont téléchargés à chaque utilisation.
6.1.1.5 Portabilité
Java est un langage indépendant de toute plate-forme, de sorte qu’un même programme peut fonctionner sur
différentes plate-formes sans qu’il faille faire la moindre adaptation, pour autant que ces plate-formes
disposent d’une machine virtuelle Java (Java Virtual Machine).
La portabilité est rendue possible par l’utilisation d’une machine virtuelle Java qui fait l’intermédiaire entre
les programmes Java et la machine sur laquelle le programme est exécuté. Contrairement à d’autres langages
de programmation où les programmes sont traduits à l’aide d’un compilateur en code machine spécifique à
un système particulier (c’est à dire des instructions spécifiques au processeur qui tourne sur la machine
cible), les programmes Java (*.java) sont compilés pour la machine virtuelle définie dans l’architecture Java
qui définit son propre jeu d’instructions, ce qu’on appelle aussi du pseudo-code Java (*.class). La machine
- 31 -
virtuelle installée sur l’ordinateur physique dont se sert l’utilisateur interprète ensuite le pseudo-code et le
traduit en instructions spécifiques au processeur de la machine pour que les programmes soit exécuté.
Ce mécanisme permet donc d’écrire des programmes compilés qui peuvent être immédiatement exécutés sur
n’importe quelle machine disposant d’une machine virtuelle Java. Ceci comporte l’avantage que,
contrairement aux langages de scripts ou à la distribution de code source pour qu’il puisse être compilé sur la
machine cliente, le code source des programmes Java n’est jamais visible, car le fichier qui est distribué est
en fait du pseudo-code Java compilé.
Grâce à la vaste disponibilité d’une machine virtuelle pour tous les principaux systèmes, Java est une
solution très portable, de loin la plus portable des solutions coté client étudiées dans ce travail, qui offre
l’avantage de pouvoir écrire un seul programme pour qu’il soit exécutable sur les différents systèmes.
La seule chose pouvant entraver la portabilité des Applets est le fait que les différents navigateur peuvent
implémenter des versions de la machine virtuelle différentes, ce qui n’est cependant pas un problème lorsque
les programmes sont développés avec la version 1.0.2 de Java, qui est supportée par tous les navigateurs. Les
versions plus avancées peuvent être incompatibles avec certains navigateurs. Il existe toutefois la possibilité
d’installer une machine virtuelle récente à l’aide du Java Plug-in.
6.1.1.6 Securité
Etant donnée le fonctionnent sur la machine de l’utilisateur, il est préférable d’avoir un mécanisme qui limite
les opération que les Applets peuvent effectuer afin de garantir la sécurité du système client. Dans le cas des
Applets, la sécurité est garantie par le fait qu’ils s’exécutent dans un environnement cloisonné (sandbox), qui
limite les interactions avec l’environnement externe selon les instructions du gestionnaire de sécurité installé
dans le navigateur..
Dans le cas des deux principaux navigateurs, Navigator et Explorer, les Applets ne sont pas autorisés à
exécuter des commandes sur le système d’exploitation, à accéder au système de fichiers (ni en lecture, ni en
écriture), ni au navigateur ou aux autres éléments de la page Web, à faire fonctionner des programmes sur le
la machine cliente et à communiquer sur le réseau avec un site différent de celui d’où le programme a été
téléchargé. Il existe par ailleurs d’autres navigateurs qui permettent à l’utilisateur de configurer le niveau de
sécurité à garantir.
Ces limitations empêchent l’écriture de code malveillant et garantissent que les Applets ne peuvent pas nuire
au système client et que la sphère privée des utilisateurs est respectée. Il faut toutefois noter que les
restrictions sécuritaires limitent un peu les fonctionnalités qu’il est possible d’implémenter avec les Applets.
Même si certaines bogues on été trouvés dans l’implémentation des machines virtuelles sur les navigateurs
(voir [xxx]), les Applets constituent la plus sûre des solutions coté client présentés dans ce travail.
La nouvelle version du langage permet aux Applets d’effectuer les mêmes opérations que les applications
Java, sous réserve qu’elles possèdent une signature numérique permettant de vérifier leur authenticité et que
l’utilisateur atteste que le fournisseur de l’Applet est digne de sa confiance. Si l’utilisateur donne son
consentement, l’Applet peut ensuite s’exécuter sans aucune restrictions et il peut notamment avoir accès au
système de fichier et aux connexions réseau. Ce modèle sécuritare est équivalent à celui employé pour les
ActiveX.
Un dernier point à soulever est le fait que le code source des programmes n’est pas visible par l’utilisateur.
En effet les Applets sont distribués après être compilés sous forme de pseudo-code pour la machine virtuelle
Java.
- 32 -
6.1.1.7 Séparation entre contenu, logique de traitement et présentation
Les Applets, au même titre que les autres solutions coté client, ne constituent pas dans la pratique un moyen
privilégié pour séparer contenu, traitements et présentation. En effet elles sont souvent concernées par la
gestion de la présentation et les traitements qui y sont directement associés.
Il faut cependant noter qu’il est possible de scinder les préoccupations, en utilisant par exemple une
conception de classes qui répondent chacune à ses propres préoccupations, en utilisant les technologies
permettant le développement de composants logiciels (JavaBeans), en exploitant les capacités d’accès au
réseau, d’informatique distribuée et la connectivité avec les bases de données (JDBC), qui n’est toutefois pas
efficiente (à cause des nombreux échanges réseau) et doivent subir les limitations du modèle sécuritaire et
des éventuels firewalls coté client ou serveur.
6.1.1.8 Conclusions
Avantages
Les Applets Java sont une solution qui permet d’insérer des véritables programmes dans les page Web. Ces
programmes peuvent profiter des atouts qui lui sont mis à disposition par la plate-forme Java.
Les Applets ont en effet la possibilité d’utiliser toutes les classes de la considérable bibliothèque d’API Java;
il faut cependant noter que par souci de portabilité il vaut mieux n’utiliser que les API de la première version
du langage et qu’à cause des restrictions sécuritaires ils ne peuvent pas effectuer un certain nombre
d’opérations. Il existe aussi un grand nombre d’outils facilitant la conception et le développement de
programmes Java.
Une deuxième caractéristique notable héritée de Java, qui est d’une considérable importance dans un
environnement tels que l’Internet constituée d’une multitude de systèmes différents, est la portabilité des
programmes, qui peuvent fonctionner sans aucune modification sur n’importe quelle machine qui dispose
d’une machine virtuelle Java. Dans le cas des Applets, une machine virtuelle Java est installée dans les
versions récentes des principaux navigateurs et on peut affirmer qu’il est possible d’atteindre presque la
totalité des utilisateurs d’Internet.
Le système de restrictions sécuritaires est aussi un des avantages de l’utilisation de cette technologie. Bien
que cela limite les possibilités de programmation, il permet d’atteindre une plus grande diffusion, car les
utilisateurs sont rassurés que les programmes qu’ils téléchargent ne sont pas nuisibles. Dans sa deuxième
version, Java permet de déroger à ce modèle sécuritaire en utilisant des Applets signés avec un certificat
numérique et en demandant l’autorisation à l’utilisateur.
Inconvénients
Parmi les cotés négatifs de cette solution on peut citer les performances assez douteuses dues à des
problèmes de téléchargement et d’implémentation de la machine virtuelle dans les navigateurs. Ces
problèmes limitent les Applets à des programmes assez simples.
Un autre inconvénient est le fait que les restrictions sécuritaires limitent fortement les possibilités des
programmes créés. Il est toutefois possible d’utiliser des Applets signés.
Cas d’utilisation souhaités
L’utilisation des Applets comme technologie Web est surtout conseillée lorsqu’on veut développer des sites
pour un environnement ouvert comme l’Internet, tout en se prêtant également pour des IntraNet. En effet,
dans un environnement ouvert comme l’Internet les avantages de portabilité et de sécurité permettent
d’atteindre une grande partie des utilisateurs potentiels et compensent les problèmes qu’on pourrait avoir en
termes de fonctionnalités et performances réduites.
- 33 -
Parmi les fonctionnalités qui se prêtent le plus à être implémentées avec des Applets on trouve les effets
graphiques, les animations, l’accès au serveur par des protocoles non supportés par le navigateur, les menus
et les jeux.
6.1.2 Active X
6.1.2.1 Présentation
Les ActiveX sont une solution développée par Microsoft et annoncée au public en mars 1996. A la base,
ActiveX est un modèle objet qui permet de développer des composants avec une interface standardisée qui
permet aux développeurs d’application de pouvoir utiliser facilement les composants et de les faire interagir
ensemble.
D'autres concepts se greffent ensuite sur ce modèle, tels les documents ActiveX, des modules d’application
complets contenant un certain nombre de composants, et les containers ActiveX. Les containers fournissent
un environnement aux composants et aux documents ans lequel ils s’exécutent et qui fait le lien entre ces
derniers et la machine physique sur laquelle elle s’exécute.
Le cadre d’utilisation d’ActiveX dépasse l’utilisation dans le cadre du World Wide Web et permet l’écriture
de véritables applications à partir de composants réutilisables et qui peuvent coopérer ensemble. Ces
composants sont développés conformément au modèle COM (Component Object Model), également
développée par Microsoft, qui définit une interface standardisée permettant d’accéder aux méthodes,
propriétés et événements des composants.
Grâce à cette technologie il est possible de faire interagir des composants développés avec différents
langages, pour autant qu’ils permettent de respecter le modèle de composant. Parmi ces langages on trouve
des langages compilés et puissants comme C++, Java, Delphi et Visual Basic. Il est aussi possible
d’employer des langages de script interprétés tels que VBScript et JavaScript.
Dans le cadre de l’utilisation des ActiveX lié au Web, les composants ActiveX peuvent être utilisés aussi
bien du coté serveur que du coté client. Dans le premier cas, les composants sont exécutés sur le serveur et le
contenu renvoyé au client n’est constitue que de contenu statique, HTML. On reviendra sur les composants
ActiveX utilisés du coté serveur dans la section dédiée à ASP. Dans le deuxième cas, les composants
ActiveX sont insérés dans des pages Web et téléchargés, installés et exécutés automatiquement sur la
machine cliente et qui peuvent être utilisés pour gérer des fonctionnalités non reconnues par le standard
HTML. Cette section est dédiée à ces derniers.
L’insertion des composants ActiveX dans les pages Web s’effectue à l’aide des balises <OBJECT>, prévues
dans la spécification du langage HTML. Le navigateur Web joue le rôle d’objet conteneur, fournissant un
environnement d’exécution aux composants; la page Web joue le rôle de document ActiveX et la
communication entre la page et les composants ActiveX est gérée par un langage de script, normalement
VBScript ou JavaScript. Ce langage permet d’invoquer les différentes méthodes et propriétés mises à
disposition par les composants en fonction des instructions contenues dans le script et en réponse aux
évènements générés par les actions de l’utilisateur ou par les composants eux-mêmes.
Comme pour les Applets Java, les composants ActiveX intégrés dans un document (une page Web) sont
déployés automatiquement sur la machine de l’utilisateur au moment où ce dernier demande le document. En
d’autres termes, le code composant le programme est téléchargé, installé et exécuté automatiquement sur la
machine cliente au moment où la page reçue est interprétée par le navigateur.
Les Applets Java sont certainement la technologie la plus proche de ActiveX (il existe même la possibilité
d’utiliser des Applets Java reconnus comme composants ActiveX), il y a cependant un certain nombre de
différences quant aux restrictions de sécurité, à la portabilité et aux fonctionnalités permises par le langage.
- 34 -
6.1.2.2 Fonctionnalités
Les possibilités offertes par le modèle ActiveX sont très vastes. Pour se rendre compte des possibilités
offertes par cette technologie, il suffit de penser que les composants ActiveX peuvent être développés en
utilisant des langages très puissants tels C++ et Java et que grâce à la technologie COM, il est possible de
créer des applications avec des composants qui interagissent ensemble, même s’ils ont développés dans des
langages différents et se situent sur d’autres machines.
En plus aucune restriction de sécurité ne limite les possibilités offertes par cette technologie, permettant
l’accès au système d’exploitation de la machine et le téléchargement et l’installation automatique de
programmes distants (mais au prix de se voir nier l’autorisation d’exécuter les programmes par les utilisateur
qui n’ont pas suffisamment de confiance).
Parmi les utilisation courantes des composants ActiveX, on trouve l’intégration d’éléments multimédia au
sein d’un même document. Parmi les médias supportés et pouvant être combinés ensemble on peut recenser
les séquences vidéo, les clips audio, les présentations, les images et les animations. Il existe un certain
nombre de contrôles ActiveX prêts à l’emploi pour insérer dans une page des éléments dans différents
médias, dans différents formats et les intégrer ensemble, tels que, pour citer quelques exemples, les contrôles
RealAudio, d’animation PowerPoint ActiveMovie et ShockWave.
D’autres fonctionnalités pour lesquels ActiveX est souvent utilisée est la gestion d’éléments graphiques
fournissant une certaine interactivité avec l’utilisateur. Parmi ces éléments on peut recenser des menus, des
barres de navigation, des banderoles défilantes,…
Etant une technologie développée par Microsoft, ActiveX s’intègre parfaitement avec les autres technologies
et produits créés par la même entreprise. Par exemple, ActiveX supporte la technologie ADO, qui sera
présenté dans la section sur les ASP, permettant de se connecter à différents sources de données (tels que des
bases de données, des tableurs, des archives d’e-mail,…), les systèmes d’exploitation Windows, les
applications construites pour ces systèmes, les applications Microsoft Office et les outils de développement
de la même entreprise. Il existe par ailleurs dans Internet Explorer (qui est une application écrite
principalement avec des composants ActiveX), des composants ActiveX prêts à l’emploi qui gèrent, par
exemple, la génération de graphiques, le préchargement de pages, les événements sur minuterie, les menus
flottants,…
Grâce à l’extension de COM connue sous le nom de DCOM (Distributed COM), il est possible de faire
coopérer des composants déployés sur différentes machines. DCOM se charge des rendre l’accès aux
composants distants strictement égal à celui des composants abrités sur la même machine, une technologie
similaire, mais moins puissante, que CORBA. Les deux présentent une certaine compatibilité et il est
possible de faire travailler ensemble des composants développés selon ces deux technologies.
L’utilisation de ActiveX n’est pas limitée à son insertion dans des pages Web et à l’utilisation par les
navigateurs: les composants ActiveX peuvent être utilisé pour créer n’importe quel type de programme. Des
véritables applications peuvent être écrites à l’aide de composants et scripts pour les lier ensemble. Un
exemple du niveau qu’il est possible d’atteindre avec cette technologie est Internet Explorer de Microsoft.
L’exécution de ce type d’application est cependant confinée à l’environnement Windows.
6.1.2.3 Productivité: bibliothèque d’API, réutilisabilité du code et logiciels de développement
ActiveX est un modèle de composants basé sur la technologie COM. Ce modèle spécifie une façon
standardisée pour développer des composants logiciels réutilisables et comment les différents composants
peuvent interagir ensemble, indépendamment du langage utilisé pour les développer.
Le modèle ActiveX a été développé avec le but explicite de garantir un maximum de possibilités de
réutilisation de code. Le développement d’applications avec cette technologie se résout à réunir et assembler
les différents composants dont on a besoin; c’est un peu comme construire un jouet avec des blocs LEGO.
- 35 -
Cette approche permet non seulement de gagner du temps et de l’effort dans le développement d’applications
à partir de ses propres composants, mais permet aussi d’intégrer facilement dans ses applications des
composants développés par des tierces parties. Ceci est particulièrement utile, car il existe une très vaste
collection de composants ActiveX, disponible sur Internet ou facilement trouvable dans les supports fournis
avec les magazines d’informatique, déjà prêts à l’emploi qu’il est possible d’insérer dans ses propres
applications, obtenables à partir d’applications Windows, par le biais d’Internet ou auprès de vendeurs.
Les outils de développement permettant de créer et utiliser les composants ActiveX sont nombreux et de
haute qualité. Microsoft supporte activement la technologie ActiveX en mettant à disposition un
environnement de développement qui lui est dédié, le ActiveX SDK. Un autre produit permettant de faciliter
la création et l’utilisation des ActiveX est le Active Control Pad. En plus les versions récentes des produits
de la série « Visual » de la même entreprise supportent également le développement de composants ActiveX
et fournissent des assistants qui automatisent un certain nombre de tâches dans leur développement. Parmi
ces produits on peut recenser Visual Interdev, Microsoft Developer Studio, Visual C++, Visual J++ et Visual
Basic
6.1.2.4 Performance et scalabilité
Avec les ActiveX il est possible d’atteindre des performances très bonnes, car les composants ActiveX
peuvent être compilés et optimisés expressément pour la machine sur laquelle ils s’exécutent et il est possible
d’employer des langages puissants dont on dispose de connaissances dans l’optimisation de code. Il faut
cependant noter que les performances sont dépendantes de la machine cliente.
Etant une solution coté client, la performance ne devrait pas diminuer au fur et mesure que le nombre de
requêtes augmente, car le travail de traitement du code est effectué sur les machines clientes et non pas sur le
serveur, qui se limite à chercher la page demandée et former la réponse HTTP à renvoyer au client.
Le véritable goulot d’étranglement dans l’utilisation des ActiveX risquerait le téléchargement des
programmes à travers le réseau. Le modèle ActiveX permet de mémoriser sur la machine cliente les contrôles
téléchargés de façon à ne devoir plus les télécharger par la suite, sauf si une nouvelle version du contrôle est
développée. En effet, au moment de l’utilisation d’un contrôle ActiveX un contrôle de version est
automatiquement effectué: si une nouvelle version du contrôle existe, alors cette nouvelle version est
téléchargée et remplace l’ancienne, sinon le navigateur utilise la version qu’il dispose déjà.
6.1.2.5 Portabilité
Etant un produit Microsoft, ActiveX est très lié aux produits de la maison américaine. La stratégie de
Microsoft, afin de contrecarrer le modèle de composants Javabeans de Sun, est cependant de rendre ActiveX
un standard ouvert afin de pouvoir développer des contrôles ActiveX pour les principales plate-formes :
Windows, Macintosh et Unix. Dans ce but, le Open Group a été chargé de normaliser le modèle.
Il faut cependant noter que bien qu’il soit théoriquement possible de développer des contrôles ActiveX pour
n’importe quel type système et qu’il soit possible de faire collaborer des composants résidant sur différentes
machines, les composants eux-mêmes ne sont pas portables et ne peuvent être exécutés que sur le type de
machine pour laquelle ils ont été développés. Souvent les composants ActiveX sont développés pour les
plate-formes Windows et le navigateur Explorer (ce qui est surtout le cas des nombreux composants
disponibles sur le réseau) et souvent s’appuient sur d’autres composants spécifiques à ces systèmes. Dans ces
cas leur utilisation reste confinée au monde Microsoft. Il est toujours possible de développer différentes
versions des composants pour les différents systèmes, mais il faut alors payer le prix de la gestion de
multiples versions du même composant.
Une autre restriction à l’utilisation des ActiveX est que les utilisateurs doivent posséder une version du
navigateur assez récente (les ActiveX sont supportés par Internet Explorer partir de sa troisième version et
- 36 -
par Netscape si un module additionnel est installé). Ceci pourrait restreindre le public ayant accès aux pages
construites avec cette technologie.
6.1.2.6 Securité
Contrairement aux Applets, les ActiveX ne sont soumis à aucune restriction de sécurité et ils ont libre accès à
toutes les ressources du système hôte et peuvent télécharger et communiquer avec n’importe quel autre
programme. Ce manque de restrictions permet certainement aux ActiveX d’avoir plus de possibilités et de
puissance, mais au prix du risque de pouvoir effectuer des actions nuisibles à la machine de l’utilisateur. Ceci
soulève un point important qu’il faut toujours garder à l’esprit: chaque fois qu’on insère un composant
ActiveX dans une page, on demande à l’utilisateur de nous faire confiance quant au fait que le programme ne
provoquerait aucun dommage sur leur ordinateur et qui ne contient pas de virus.
Il existe par ailleurs des mécanismes de sécurité via lesquels l’utilisateur a le pouvoir d’accepter ou de
refuser le téléchargement et l’exécution de code non résidant sur son ordinateur. Ce système est basé sur la
livraison, avec chaque objet ActiveX, d’un curriculum de son existence permettant de savoir qui a produit le
code et s’il a été modifié par la suite. Une solution plus sûre est de coupler cette identification avec des
certificats numériques émis par une autorité de certification authentifiant la véridicité de l’identité fournie
(c’est ce qu’on appelle des programmes signés).
Ces questions sécuritaires sont définies par Microsoft comme des problèmes absurdes, où les gains tirés des
plus grandes possibilités d’exécution dues à l’accès aux ressources de l’ordinateur client compensent dans
une plus grande mesure les pertes dues aux risques sécuritaires possibles. Il faut toutefois remarquer que
beaucoup d’utilisateurs refusent de laisser exécuter ces programmes sur leurs machines, ce qui est surtout le
cas pour les entreprises qui disposent d’un administrateur réseau, qui bloquent par principe l’accès à ce
gendre de programmes.
Il faut noter aussi que le fait d’utiliser de composants compilés ne permet pas à l’utilisateur de visualiser le
code source par les utilisateurs. Bien que cela ne rafforce pas la sécurité des applications en tant que telle, car
des programmeurs malintentionnés peuvent toujours reconstruire un code source équivalent au composant
binaire en leur possession, cela peut tout de même être utile aux développeurs pour se protéger en partie du
copiage de leur code.
6.1.2.7 Séparation entre contenu, logique de traitement et présentation
Avec ActiveX il est possible d’obtenir une certaine séparation entre contenu, présentation et logique de
traitement.
Une partie de la gestion de la présentation est certainement confiée à la page Web, qui contient au minimum
les instructions de mise en forme de la page et la disposition des éléments qui la composent. Les ActiveX
peuvent aussi être utilisés pour gérer des parties complémentaires de présentation lorsque les limitations du
langage HTML ne permettent pas d’obtenir les effets désirés, notamment en incluant des éléments
multimédias.
Le contenu de la page peut aussi être divisé en contenu statique géré par la page HTML et en contenu
dynamique géré à travers les ActiveX. Grâce à la possibilité de se connecter à d’autres composants et à
d’autres systèmes (tels des bases de données et des archives sous différentes formes), les composants
ActiveX peuvent chercher le contenu à présenter sur différents systèmes et le passer à la page.
Un avantage avec le modèle ActiveX est que la logique de traitement peut être séparée des deux autres
préoccupations en l’insérant dans des composants spécifiques. Ces composants peuvent être ensuite invoqués
par la page ou par les autres composants, rendant ainsi plus facile la maintenance, réutilisation et fiabilité du
code.
- 37 -
6.1.2.8 Conclusions
Avantages
ActiveX est une technologie aux possibilités extraordinaires, certainement la plus puissante des solutions
coté client. En effet la possibilité d’utiliser des langages de programmation puissants tels C++, l’absence de
limitations sécuritaires, la possibilité d’utiliser des composants répartis grâce à la technologie DCOM et la
possibilité d’interagir avec l’utilisateur et son système d’exploitation permettent de développer du code qui
peut implémenter virtuellement n’importe quel type de fonctionnalité tout en obtenant des meilleures
performances par rapport aux concurrents.
Un autre avantage non négligeable de cette technologie est le fait qu’étant développé par Microsoft, elle peut
être intégrée facilement avec les autres produits de la même entreprise, notamment les applications de
bureautique de la ligne Office, Internet Explorer, le système d’exploitation Windows et les outils de
développement de la ligne Visual.
Inconvénients
Cette technologie a cependant deux défauts importants: une portabilité limitée et un modèle sécuritaire
absurde. Le premier défaut dérive du fait que ActiveX est une technologie propriétaire et que malgré les
efforts marketing de Microsoft qui assure que le développement de composants est possible dans les
principaux systèmes, les composants eux-mêmes ne sont pas portables et leur pouvoir ne peut qu’être
pleinement exploité que dans un environnement Windows. En effet les composants ne peuvent être exécutés
que sur le type de système pour lequel ils ont été compilés; pour pouvoir utiliser le même composant sur
d’autres systèmes il faut compiler une version spécifique pour chaque système, ce qui nécessite ensuite la
gestion de différentes versions du composant.
Le deuxième problème lié à cette technologie est l’aspect sécuritaire. Bien que l’absence d’un modèle
sécuritaire qui impose des restrictions permet d’étendre la gamme de fonctionnalités implémentables, ceci
impose aux utilisateurs de faire confiance aux développeurs des composants ou renoncer à lire la page.
Même le modèle avancé utilisant des contrôles signés à l’aide de certificats numériques, ne permet pas
d’atteindre un niveau de sécurité assez élevé. La conséquence des risques sécuritaires liés aux ActiveX ne
permet pas de gagner la confiance d’un certain nombre d’utilisateurs, surtout les utilisateurs travaillant dans
les entreprises, qui préfèrent refuser l’exécution de tout programme ActiveX plutôt que de risquer d’executer
des programmes nuisibles à leur machines.
Cas d’utilisation souhaités
Etant donné le modèle sécuritaire très permissif, en fait l’absence de restrictions sécuritaires en dehors du
mécanisme de signature digitale et autorisation, et la portabilité qui est en pratique limitée aux
environnements Microsoft, ActiveX est une solution qui est davantage exploitable dans un environnement
contrôlé comme celui d’une IntraNet, où l’on peut connaître le parc de machines et les logiciels installés, que
dans un environnement ouvert et hétérogène comme l’Internet.
Parmi les fonctionnalités pour lesquelles on peut convenablement choisir cette solution il y a l’insertion d’un
des nombreux contrôles déjà programmés, d’éléments multimédias, d’éléments graphiques sensibles, des
jeux et de communication avec d’autres composants COM sur le réseau.
6.1.3 Les langages de script: JavaScript et VBScript
6.1.3.1 Présentation
Actuellement il existe deux langages de script principaux qui peuvent être utilisés pour rendre plus
dynamiques et interactives les pages Web. Ces langages sont JavaScript, développé par Netscape, et
VBScript, développé par Microsoft. Il existe aussi une version Microsoft de JavaScript appelée JScript.
- 38 -
Un langage de script est essentiellement un langage de programmation allégé, facile à apprendre et à utiliser.
Par rapport à des langages de programmation plus évolués, les langages de script se passent souvent de
certains formalismes, comme le fait qu’il faille obligatoirement déclarer ses variables et leur assigner un type
avant leur utilisation. Une autre différence est que ces langages sont souvent interprétés, par opposition aux
langages de programmation qui sont compilés.
En effet les deux langage sont faiblement typés et le programmeur ne peut pas assigner de façon explicite le
type de valeurs qu’une variable peut contenir. C’est le moteur d’interprétation qui assigne automatiquement
un type à chaque variable en fonction des données contenues à un moment donné, une variable pouvant
changer de type au cours de sa vie en fonction des données qui lui sont assignés. C’est alors au programmer
de faire en sorte de maîtriser le type des différentes variables en utilisant des conventions de nommage
explicites, en contrôlant les données qui leur sont assignés avec des fonctions pouvant en déterminer le type,
et en utilisant les fonctions de conversions de type.
Le faible typage et la non nécessité de déclarer ses variables avant leur utilisation permet d’écrire son code
plus vite, mais au prix d’avoir davantage de chances d’avoir des erreurs difficiles à déboguer,. Ceci est
partiellement corrigé en VBScript, où une option intéressante de permet d’obliger le programmeur à déclarer
les variables avant leur utilisation, sous peine d’avoir un erreur explicite, ce qui évite les erreurs dus à des
simples fautes de frappe dans le nom des variables.
Les deux langages sont très similaires, la différence principale étant au niveau de la syntaxe employée: tandis
que VBScipt a une syntaxe très proche du Visual Basic, qui est, comme son nom l’indique, assez
« basique », JavaScript a une syntaxe proche du C.
L’insertion d’instructions issues de ces langages de script dans les pages Web s’effectue à l’aide des balises
<SCRIPT>, prévues dans la spécification du langage HTML. Cette balise permet de spécifier comme attribut
le langage utilisé) et le lieu d’exécution (qui peut être coté client ou serveur). Il est possible de combiner
dans un même document des scripts écrits dans les deux langages et exécutés sur les deux machines. Si rien
n’est défini, le langage est celui par défaut du navigateur et les scripts sont interprétés coté client. Pour
différencier les blocs qui doivent être interprétés coté serveur, il faut soit spécifier l’attribut “runat=server“
dans la balise <SCRIPT>, soit employer les balises style ASP <%…%>.
En plus des instructions de base, qui définissent le cœur du langage, le programmeur peut utiliser des
extensions différentes selon le lieu d’exécution, c’est à dire d’interprétation des instructions contenues dans
le script. Ces extensions se concrétisent sous forme d’objets mis à disposition par l’environnement
d’exécution. Tandis que coté serveur ces langages ont accès à d’autres systèmes tels que des bases de
données et des objets tels la requête et la réponse http, des autres fichiers sur le serveur etc., coté client ils
peuvent accéder aux objets mis à disposition par le navigateur et qui comprennent le navigateur lui-même,
les fenêtres, le document Web et ses différents composants. Dans le script il est possible d’accéder aux
propriétés et méthodes mises à disposition par ces objets et réagir aux événements liés aux actions de
l’utilisateur qui les concernent.
Cette section est dédiée à leur utilisation coté client; le coté serveur de ces langages sera traité dans une
section suivante dédiée à l’ASP.
6.1.3.2 Fonctionnalités
VBScript et JavaScript offrent les possibilités classiques d’un langage procédural. Si on divise un
programme dans un algorithmique et une structure de données, on peut mettre en évidence du coté de
l’altorythme la possibilité d’utiliser des instructions d’affectation, d’évaluation d’expressions, des
instructions conditionnelles, des répétitions, de modification du flux d’exécution, les fonctions et les
procédures. Coté structure de données on peut recenser des variables, des tableaux, des objets, etc.
Ces langages manquent cependant d’un certain nombre de fonctionnalités présentes dans d’autres langages
plus évolués, tels la possibilité d’utiliser des fichiers, de scinder l’exécution du programme en plusieurs
- 39 -
processus légers etc. VBScript manque en plus de la possibilité de gérer facilement les erreurs produits au
moment de l’exécution, tandis que JavaScript dispose des commandes try…catch.
Les deux langages offrent aussi la possibilité définir et utiliser ses propres objets ainsi que les objets mis à
disposition par l’environnement dans lesquels ils sont exécutés, notamment par le navigateur. Parmi les
objets prédéfinis des langages on peut citer les objets permettant l’utilisation des expressions régulières et de
codage des URL. Parmi les objets mis à disposition par le navigateur, on peut recenser un objet navigateur
qui donne des informations sur lui-même, un objet fenêtre représentant une fenêtre contenant un document,
un objet document représentant la page Web, les différents objets qui la composent liés aux différentes
balises HTML (comme les images, les formulaires, les liens etc.).
Le but de l’utilisation de ces langages de script coté client est celui de rendre les pages Web plus interactives,
pouvant réagir immédiatement aux actions de l’utilisateur, sans devoir attendre une allée-retour entre client
et serveur Web.
En plus du contrôle des données des formulaires avant leur envoi au serveur, qui est sans doute l’emploi le
plus fréquent pour lequel ces langages sont utilisés, ces langages offrent la possibilité de générer au vol des
nouvelles pages, gérer les différents cadres et fenêtres composant la page Web, implémenter des éléments
graphiques ou multimédias particuliers tels que des menus et des barres de navigation réagissant aux actions
de l’utilisateur, insérer des petits programmes interactifs tels que des jeux et des programmes de calcul.
Pour des raisons sécuritaires, ces langages sont soumis à quelques restrictions. Par exemple ils n’ont pas
d’accès au système de fichiers ni aux objets issus de documents qui ne proviennent pas de la même source.
Ceci empêche que des scripts lisent des informations confidentielles stockés sur la machine client ou sur les
autres pages visités et les transmettent ensuite au serveur.
Une autre possibilité intéressante d’utilisation de ces langages de script est celle de constituer le lien entre la
page Web et les composants qui y sont insérés, en particulier les contrôles ActiveX et les Applets. Les
fonctionnalités offertes par ce type de solution dépassent les buts de cette section et seront discutées dans la
section qui leur sont dédiées respectivement aux Applets et aux ActiveX.
6.1.3.3 Productivité: bibliothèque d’API, réutilisabilité du code et logiciels de développement
Le développement des scripts devrait être rendu plus rapide par le faible typage et les souples contraintes
syntaxiques imposées par ce type de langage. L’écriture du code est certainement plus simple et plus rapide,
cependant il y a un risque plus fort d’encourir dans des erreurs de programmations plus difficilement
prévisibles et détectables au cours d’un déboguage bien plus compliqué.
Le temps total de développement devrait être inférieur dans le cas de petits projets, où le gain en temps de
développement du code est plus que compensé par le plus long temps de deboguage; pour des projets de plus
grande taille, le rapport risque fortement d’être être inversé. Il est toutefois possible de réduire ces risques par
des bonnes pratiques de programmation, avec des conventions de nommage, la déclaration des variables
avant l’utilisation. Ceci réduit cependant la rapidité d’écriture de code.
Les langages de script ne disposent pas d’une bibliothèque d’API étoffé comme celle disponible dans les
principaux langages de programmation. Bien qu’il soit possible de se procurer des nombreuses sources sur le
Web, l’architecture du langage ne permet pas une facile réutilisation du code et le développement en résulte
négativement affecté.
Il est possible d’utiliser n’importe quel éditeur de texte pour créer des scripts, en particulier les éditeurs qui
offrent des fonctionnalités de coloration syntaxique. Il existe aussi un certain nombre d’outils de
développement spécifiques qui supportent ces langages de script, tels Microsoft Interdev, Macromedia
DreamWeaver et Allaire HomeSite.
- 40 -
6.1.3.4 Performance et scalabilité
Les scripts créés avec ces langages sont interprétés par le navigateur, ou mieux par le moteur d’interprétation
de scripts installé avec le navigateur, au moment de la visualisation de la page Web. Les performances sont
donc influencées par la machine cliente et par l’implémentation du moteur de script dans le navigateur. Il
faut cependant noter que les performance ne peuvent qu’être inférieures aux autres deux solutions présentées
qui prévoient l’utilisation de programmes compilés, pour la machine cliente (ActiveX) ou pour une machine
virtuelle (Applets). Ceci limite les scripts À des programmes assez simples, n’ayant pas besoin d’une grande
puissance de computation.
L’augmentation du trafic n’a pas plus d’impact sur les performances que la même augmentation de trafic
dans le cas de pages Web statiques: les scripts sont traités sur les machines clientes, pas sur le serveur, qui se
limite à chercher la page demandée et former la réponse HTTP à renvoyer au client.
6.1.3.5 Portabilité
Le problème principal est que ces langages sont fortement dépendants de l’implémentation du moteur
d’interprétation qui leur est attaché dans le navigateur sur lesquels ils s’exécutent: les différentes versions des
différents navigateurs supportent des langages et des versions de langages différents.
Coté portabilité, VBScript est particulièrement problématique, car il est seulement implémenté par le
navigateur de Microsoft, Internet Explorer. Son utilisation est donc restreinte aux applications qui sont
développés exclusivement pour une audience dont on peut imposer l’utilisation de ce type de navigateur, par
exemple dans le cas d’une IntraNet d’entreprise. L’utilisation dans un environnement hétérogène comme
Internet est très vivement déconseillée.
La portabilité de JavaScript est nettement meilleure, étant supportée par les principaux navigateurs
(Navigator à partir de la version 2.0 et Explorer à partir de la version 3.0). Cependant il faut noter que
Internet Explorer implémentent une version du langage propre à Microsoft, JScript. Les différences
d’implémentation entre les deux versions n’étant pas énormes, la majorité des scripts devrait fonctionner
sans problèmes avec les deux navigateurs. Il faut toutefois se rappeler spécifier «JavaScript» comme attribut
language de la balise script, «JScript» étant reconnu seulement par Explorer.
Il faut ajouter aussi que les différentes versions des navigateurs supportent différentes versions du langage et
qu’il faut vérifier quels navigateurs supportent quelle version avant de démarrer le développement en
utilisant des fonctions ajoutées dans les versions récentes des langages. Ceci limite l’audience qu’on peut
atteindre à travers ce type de solution, bien qu’on peut estimer que la majorité des utilisateurs ayant à
disposition un navigateur capable d’interpréter correctement les scripts (au moins pour JavaScript 1.0).
Il existe aussi la possibilité de spécifier dans les balises SCRIPT des instructions HTML, pour que les
navigateurs qui ne supportent pas les scripts puissent quand même visualiser la page correctement (sans les
fonctionnalités offertes par le script).
6.1.3.6 Sécurité
Les langages de script sont soumis à un certain nombre de restrictions sécuritaires, qui ont le but de limiter
les opérations que ces langages peuvent effectuer afin de garantir l’intégrité du système de la machine cliente
et le respect d’informations confidentielles et des données personnelles de l’utilisateur. En particulier les
scripts sont soumis à une restriction importante qui leur empêche tout accès à des éléments qui ne
proviennent pas de la même origine, c’est à dire le serveur depuis lequel le script a été téléchargé. De cette
façon les scripts ne peuvent pas accéder au système de fichiers de la machine ni aux autres pages Web ou aux
préférences de l’utilisateur.
Un nombre considérable de failles de sécurité ont cependant été découvert dans les implémentations des
moteurs d’interprétation dans les différents navigateurs et il semblerait que la sécurité offerte par les
- 41 -
implémentations actuelles soit inférieure à la sécurité offerte par les Applets Java. Certaines failles de
sécurité découvertes permettaient l’accès à des fichiers ou à des données personnelles sur la machine cliente
et leur envoi sur le réseau ou la surveillance des actions des utilisateurs, pouvant notamment porter à la
construction d’une liste des sites visités ou au captage d’informations sensibles.
Les utilisateurs ont la possibilité de refuser l’exécution de tous les script sur leur machine à travers les
préférences de leur navigateur. Ce dernier offre en effet la possibilité de choisir le niveau de sécurité à
appliquer et ont une option pour interdire l’exécution des scripts. Etant relativement sûres, il y a des chances
que la majorité des utilisateurs n’exploitent pas cette option, au moins lorsque ils se connectent à des sites
connus.
Les nouvelles versions de JavaScript prévoient la possibilité d’utiliser des scripts signés avec une signature
numérique qui peuvent demander au navigateur de soulever un certain nombre de restrictions de sécurité. La
signature numérique permet d’établir l’authenticité de l’identité du fournisseur du script et que le code n’a
pas été modifié successivement à la signature. L’utilisateur est alors averti que le script demande des
dérogations à la politique sécuritaire standard et le navigateur soumet l’exécution du script à une autorisation
explicite de l’utilisateur.
Un autre aspect concernant la sécurité est le fait que le code source est transmis en clair à l’intérieur de la
page HTML, ce qui est normal, car les instructions des scripts doivent être interprétées par le navigateur au
moment de la visualisation de la page. La conséquence est que chaque utilisateur peut facilement voir le code
source des programmes insérés dans la page en utilisant la possibilité offerte par tous les navigateurs récents
de visualiser le code source de la page.
6.1.3.7 Séparation entre contenu, logique de traitement et présentation
Les langages de script sont confinés dans le champs de la logique de présentation et en moindre partie de
gestion du contenu. En effet ils sont souvent concernés avec la gestion d’éléments graphiques, le contrôle de
la mise en page de la page Web, la gestion des fenêtres et le contrôle des données d’un formulaire.
A eux seuls, les langages de script ne permettent pas d’isoler facilement la logique de traitement et la
recherche de contenu, à cause de l’architecture même des langages et leur puissance limitée des langages qui
ne permettent pas de créer des composants réutilisables, des performances limitées et de la visibilité du code
source qui décourage la codification de traitements qui devraient rester confidentiels.
Ces langages de script peuvent toutefois être utilisés en combinaison avec les technologies de composants
qu’on a présenté précédemment (ActiveX et Applets): tandis que la présentation est confiée aux langages de
script, les composants peuvent contenir de la logique de traitement et fournir du contenu dynamiquement.
6.1.3.8 Conclusions
Avantages
Les langages de script permettent un développement rapide de petits programmes qui permettent d’étendre
les possibilités des pages Web, surtout en permettant de les rendre plus interactives. En effet ces langages
sont souvent utilisés pour capter les actions des utilisateurs et y réagir de façon appropriée. Parmi les
fonctionnalités gérées couramment avec les scripts il y a le contrôle des données d’un formulaire et
l’implémentation d’éléments graphiques répondant aux actions des utilisateurs.
Une utilisation très intéressante de ces langages de script est celle de pouvoir communiquer avec des
composants ActiveX et les Applets contenues dans une page Web. Ces langages constituent aussi une
solution complémentaire aux solutions coté serveur et les scripts peuvent aussi être écrits dynamiquement par
les mêmes. Ils peuvent d’ailleurs être aussi utilisés coté serveur et constituent même la base de la technologie
ASP de Microsoft.
Inconvénients
- 42 -
Ce type de solution n’est cependant pas adéquat à des projets de plus grande envergure, à cause de la faible
puissance de ces langages, la faible productivité de développement et les performances limitées. En plus, la
sécurité limitée offerte par ce type de langage, surtout au niveau de la visibilité des sources, en fait une
solution à éviter pour des projets importants ou des programmes qui contiendraient des algorithmes ou
informations confidentielles.
Une grande différence entre les deux langages réside dans leur portabilité: tandis que JavaScript est supporté
par les principaux navigateurs et peut facilement être utilisé dans un environnement hétérogène comme
Internet, VBScript n’est supporté que par le navigateur de Microsoft, ce qui en limite l’utilisation dans le
cadre d’applications qui sont développées pour une audience bien connue, par exemple dans le cas d’une
IntraNet d’entreprise.
Cas d’utilisation souhaités
Ces langages de script peuvent être utilisés convenablement pour capter les événements liés aux actions des
utilisateurs, contrôler les données insérés dans les formulaires, gérer certains effets graphiques, gérer les
fenêtres et contrôler les autres composants insérés dans la page. Leur utilisation devrait toujours être confinée
à des projets de petite taille ou dans des projets de plus grande taille comme technologie d’appoint.
Une distinction est à faire entre les deux langage. En plus des préférences syntaxiques, il est convenable
d’utiliser JavaScript pour les développements Internet et IntraNet et n’utiliser VBScript que pour les
développements IntraNet à cause de sa portabilité limitée.
6.2
Solutions coté serveur
Dans solutions coté serveur la création de la page est dirigée par le serveur, qui au moment de la requête
d’une page dynamique, il délègue la tâche de construction de la page à ce qu’on appelle moteur de
construction de pages dynamiques, qui est en réalité soit un programme externe auquel on passe les données
nécessaires selon la convention CGI (Common Gateway Intarface), soit un module lié au serveur qui est
spécialisé dans la création des pages dynamiques.
La figure 6 schématise le déroulement des événements dans le cas d’utilisation d’une solution de création de
3. Traitement requête
et localisation du
fichier
2. Requête HTTP
disque
6.
Vîsualisation
5. Réponse
HTTP
Page Web
1. Création du fichier
d’instructions et publication sur
4. Interprétation
des
instructions et
création de la
page Web
Base de
données
Systèmes
info.
Moteur de création de
pages dynamiques
Client
Serveur
4.
Figure 8 : Les pages dynamiques, coté serveur
pages dynamiques coté serveur.
L’interaction entre le client et le serveur Web ne change pas par rapport à l’utilisation de pages statiques et
reste soumise aux spécifications du protocole HTTP: le client démarre l’échange en envoyant une requête
pour avoir une ressource et le serveur lui envoie une réponse avec la ressource demandée si elle est
disponible ou une réponse indiquant l’impossibilité de satisfaire la requête. Le client ne peut même pas
- 43 -
s’apercevoir que la page demandée a été construite au moment même de sa requête, car elle est en tout point
identique à une page statique, n’étant constituée que de texte formaté selon le formalisme HTML.
La seule chose qui permet au client de savoir que la page demandée est une page dynamique est l’URL de la
ressource demandée. En effet les URL des pages dynamiques diffèrent de celles des pages statiques soit par
leurs extension, soit par la localisation de la ressource sur le serveur. En effet, soit les fichiers constituant les
pages dynamiques n’ont pas une extension de type .HTML ou .htm, mais une extension identifiant la
solution qu a été choisie pour les créer (tels .php, .asp, .jps et .cfml), soit les pages sont positionnées dans un
répertoire particulier nommé cgi-bin.
La figure 8 décrivant le fonctionnement des pages dynamiques coté serveur est assez similaire à la figure 5
présentant le fonctionnement des pages statiques. Il y a toutefois deux changements principaux. Le premier
est le fait que préalablement à son utilisation, le développeur doit écrire un programme (ou script) contenant
les instructions nécessaires â la construction de la page et non pas la page elle-même. Le deuxième consiste
dans le traitement effectué par le serveur. Sachant qu’il s’agit d’une page dynamique grâce à son extension
utilisée ou à sa localisation, le serveur localise le fichier d’instructions correspondant à la requête et invoque
le programme de génération de pages dynamiques approprié en lui passant comme entrées le fichier demandé
dans la requête contenant les instructions à suivre pour générer la page, les informations contenues dans la
requête et des informations sur lui-même. Le programme invoqué, qui peut être un programme compilé
externe ou un moteur d’interprétation soit externe soit intégré comme module interne au serveur, exécute les
instructions contenues dans le fichier et produit comme résultat une page Web classique qu’il retourne au
serveur. Le serveur s’occupe ensuite d’encapsuler cette page dans la réponse HTTP et de l’envoyer au client
qui l’a demandée.
Le moteur de génération des pages dynamiques peut, selon les instructions contenues dans le fichier, accéder
à un grand nombre de systèmes différents afin de rechercher et générer le contenu de la page. L’architecture
classique prévoit des connexions à une base de données qui contient le contenu des pages à afficher,
cependant il est possible d’insérer des composantes logicielles supplémentaires, tels des moniteurs de
transaction ou de serveurs d’application, ou d’accéder à d’autres systèmes d’informations ou fichiers.
Les solutions qui appartiennent à cette catégorie ont l’avantage d’exécuter les instructions de génération de la
page sur le serveur avant d’être envoyés au client et de n’envoyer vers celui-ci que des pages HTML
standard. Ceci constitue un avantage considérable, surtout dans un environnement hétérogène comme
Internet, garantissant une indépendance et compatibilité complète vis-à-vis des différents navigateurs
(pourvu qu’ils supportent la version de la spécification du langage HTML utilisée). En plus ces solutions
offrent la possibilité intéressante de pouvoir générer la page en fonction des caractéristiques du client qui
sont communiquées dans la requête. Il est donc possible de tailler les pages sur mesure aux capacités des
différents navigateur, pouvant ainsi combiner les possibilités avancées propres à un logiciel client sans pour
autant sacrifier la compatibilité avec les autres (et se garantir ainsi une accessibilité maximale de la part des
utilisateurs).
Le problème de compatibilité peut cependant se poser avec les différents serveurs et avec les différents
systèmes que la page dynamique doit contacter pour extraire les données nécessaires à la constructions des
pages.
Un deuxième avantage est que le code source des programmes qui gênèrent les pages ne sont jamais envoyés
sur le poste client (inversement au code des langages de script coté client dont le source peut être librement
consulté sur chaque navigateur). Ceci contribue à maintenir la sécurité d’un site Web.
Il est également possible d’accéder à de programmes externes, à des bases de données ou au système
d’information de l’entreprise et les utiliser pour construire une partie de la page ou effectuer certains
traitements. Ceci permettrait d’avoir des meilleures performances, une source de données qui est toujours à
jour et évite de dédoubler le travail de mise à jour et facilite la maintenance du site.
- 44 -
Enfin l’utilisation de ce type de solution permet de maintenir sous contrôle l’environnement d’exécution des
programmes écrits: tous les clients ont accès au même type de ressource et il n’y aura pas de clients dont le
temps d’exécution est trop lent ou la page trop lente à charger à cause de leurs configuration.
Les solutions coté serveur ont cependant aussi un certain nombre de problèmes: l’exécution des programmes
de création des pages est plus long et consomme plus de ressources par rapport au traitement d’une page
classique; les ressources du serveur sont partagées entre tous les utilisateurs et il se peut qu’en cas de
surcharge tous les clients soient négativement affectées; le temps de réponse aux entrées saisies par
l’utilisateur nécessite un complet échange entre client et serveur et résulte plus lent que le temps qu’il est
possible d’obtenir avec l’utilisation de solutions coté client où la réponse est immédiate ; enfin les pages
dynamiques ne sont pas correctement référencées dans les moteurs de recherche
6.2.1 CGI (Common Gateway Interface)
6.2.1.1 Présentation
La Common Gateway Interface (CGI) est apparue comme la première solution pour la génération de pages
Web dynamiques au moment de la requête de l’utilisateur grâce à l’utilisation de programmes coté serveur.
Comme son nom le laisse supposer, CGI ne définit pas un langage de programmation, mais une interface qui
permet au serveur Web d’étendre ses possibilités en lui permettant d’invoquer un programme externe pour
que ce dernier lui génère et renvoie une page Web correspondante à la requête du client. Cette interface
désigne la partie du serveur qui peut communiquer avec des autres programmes qui s’exécutent sur la même
machine et spécifie la façon dont le serveur et ces programmes doivent communiquer entre eux. En d’autres
termes, CGI définit une façon standardisée de faire appel à un programme, en formalisant la façon dont les
échanges de données entre le serveur Web et les programmes invoqués, c’est à dire les entrées et sorties du
programme, sont effectuées.
Le fonctionnement CGI est représenté de façon générique dans la figure 8, présentée au début de la section
6.2. La première étape consiste dans l’écriture du programme de génération des pages dynamiques. Il faut
aussi configurer le serveur pour qu’il puisse traiter correctement les requêtes portant sur des programmes
CGI: la plupart des serveurs Web s’attendent, en fonction de leur configuration, que les programmes CGI
soient enregistrés dans un répertoire particulier (souvent cgi-bin) ou qu’ils ont une extension spécifique.
Une fois les programmes enregistrés sur le serveur, les utilisateur ont la possibilité d’effectuer des requêtes
HTTP spécifiant la ressource demandée. Lorsque cette dernière est reconnue comme correspondant à un
programme CGI, le serveur Web invoque ce programme en lui passant en entrée les différentes informations
contenues dans la requête reçue (et qui peuvent être regroupés dans trois catégories: informations sur le
client, information additionnelles sur la requête et données provenant de formulaires). Le programme est
ensuite exécuté et produit en résultat une page Web, qu’il restitue ensuite au serveur pour que celui-ci puisse
l’insérer dans le corps d’une réponse HTTP et l’envoyer au client qui l’a demandée. Une fois reçue par le
client, la page Web est visualisée par le navigateur de la même façon que les pages statiques.
Les programmes CGI peuvent être écrits dans n’importe quel langage. Il est toutefois conseillé de restreindre
son choix aux langages ayant des bonnes fonctionnalités de manipulation de texte, une bonne connectivité
aisée avec d’autres systèmes et de pouvoir travailler avec des variables d’environnement. La capacité de
manipuler du texte est particulièrement importante, car il faut pouvoir décoder l’information contenue dans
la requête et produire en sortie une page Web, qui n’est rien d’autre qu’un document textuel. Il est donc
souhaité d’avoir des fonctionnalités permettant d’effectuer scinder et recomposer des chaînes de caractères et
d’effectuer des recherches et remplacements à l’aide de règles syntaxiques spéciales (i.e. les expressions
régulières du langage Perl). La connectivité avec d’autres systèmes permet d’augmenter les possibilités des
programmes CGI en s’appuyant sur les services d’une base de données ou d’un système d’informations. La
- 45 -
troisième nécessité provient du fait que les variables d’environnement constituent la forme avec laquelle les
informations contenues dans la requête sont passées au programme invoqué.
Parmi les langages qui correspondent à ces critères ont peut recenser, de façon non exhaustive, Perl, C, C++,
Java, Tcl et Visual Basic. Le langage qui est le plus utilisé est certainement Perl, grâce au fait qu’il est assez
simple à apprendre, portable, relativement puissant, surtout dans la manipulation de texte, et aux extensions
disponibles. Parmi les autres langages souvent utilisés on trouve C et C++, qui ont le défaut d’être plus
compliqués à apprendre, mais permettent de créer des programmes compilés qui ont une meilleure
performance.
Un exemple de site mis en œuvre en utilisant cette solution est le moteur de recherche lycos
(www.lycos.com).
6.2.1.2 Fonctionnalités
Les programmes CGI permettent d’effectuer de créer des véritables programmes pour la génération de pages
à la volée. Comme CGI ne spécifie pas un langage de programmation, les fonctionnalités implémentables
grâce à ce mécanisme ne sont à priori limitées que par les capacités des programmeurs et sont comparables
aux possibilités offertes par les autres solutions coté serveur qu’on présentera par la suite.
En particulier les programmes CGI peuvent effectuer n’importe quel type de traitement supporté par le
langage choisi, en exploitant les données envoyées par l’utilisateur à l’aide de formulaires ou insérés par le
navigateur dans la requête HTTP et les services d’autres systèmes tels que des bases de données. Il est donc
possible de développer un large éventail d’applications interactives, dont on peut citer, juste pour donner
quelques exemples, des sites de commerce électronique, des pages personnalisées en fonction des capacités
des navigateurs employés ou des options choisies par l’utilisateur, des moteurs de recherche etc.
Cependant, par rapport aux autres solutions, dans CGI manquent un certain nombre de services qui sont
intégrés aux autres solutions et qui rendent le développement plus facile, tels que la possibilité d’insérer du
code directement dans une page HTML et le support des sessions.
6.2.1.3 Productivité: bibliothèque d’API, réutilisabilité du code et logiciels de développement
Contrairement aux autres solutions qui donnent la possibilité de créer des pages HTML avec des bouts de
code insérés à différents endroits, les programmes CGI sont des véritables programmes complets. Par
conséquent, leur écriture est généralement moins facile et moins rapide.
Le fait qu’aucun langage ne soit spécifié ne permet pas de faire des considérations explicites sur la
bibliothèque d’API, les possibilités réutilisation du code et les logiciels de développement, car elles sont
fortement dépendantes du langage choisi.
On peut toutefois noter que dans les langages utilisables on trouve des langages génériques et puissants
comme C++ et Visual Basic, ainsi que des langages spécifiques au Web comme Perl. Ces langages disposent
généralement d’une libraire de programmation assez évoluée et fournissent des bonnes possibilités de
réutilisation du code et sont supportés par des bons logiciels de développement.
6.2.1.4 Performance et scalabilité
Le fait que les programmes CGI soient des programmes externes au serveur Web implique le fait qu’un
processus système est déclenché à chaque fois que le serveur invoque les services d’un programme CGI.
Ceci limite fortement les performances, même dans le cas où le programme invoqué serait compilé, à cause
du travail supplémentaire et la consommation de ressources système engendrées par le déclenchement du
processus système.
- 46 -
Cette forte consommation de ressources pose aussi un problème de scalabilité, car, avec l’augmentation du
trafic, on arrive assez rapidement à une saturation des ressources du serveur, ce qui allonge fortement les
temps de traitement des requêtes et en diminue par conséquent le nombre qui peuvent être satisfaites dans un
temps donné.
6.2.1.5 Portabilité
CGI en tant qu’interface est extrêmement portable. En effet on peut affirmer que les principaux serveurs
Web sont compatibles avec les programmes CGI. La portabilité de ces derniers est cependant variable en
fonction du langage utilisé. En effet il est tout à fait possible d’utiliser des programmes portables écrits Java
ou Perl, comme des programmes compilés pour des plate-formes spécifiques comme C et Visual Basic.
6.2.1.6 Sécurité
La sécurité des programmes CGI est très controversée. En particulier il semblerait qu’ils soient assez
vulnérables. En utilisant les mots de Gundavaram, « A CGI program is prone to security problems no matter
what language it is written in ! ». En particulier il est dangereux d’utiliser des appels systèmes avec des
expressions évaluées à partir des données insérées par l’utilisateur, qui pourrait exploiter la possibilité
d’insérer dans les champs des commandes systèmes qui seront traités et exécutés sur le serveur.
6.2.1.7 Séparation entre contenu, logique de traitement et présentation
De nouveau la séparation possible dépends des langages, car il est possible d’utiliser différentes techniques
selon les différents langages. A titre d’exemple on peut citer le support du paradygme objet de langages
comme C et Java, l’inclusion de fichiers coté serveur de Perl, les architectures de composants tels que
JavaBeans. En plus les différents langages ont un support variable d’autres systèmes, incluant des serveurs
d’application et des bases de données, qui permettent d’isoler respectivement les données et la logique de
traitement et d’accès aux données de la logique de présentation.
6.2.1.8 Conclusions
Avantages
Les CGI ont l’avantage d’être la première solution apparue pour la génération de pages dynamiques et qu’ils
constituent une interface standardisée et largement supportée. Le fait que la norme CGI ne spécifie pas un
langage de programmation qu’il faut utiliser pour le développement de programmes, laisse une énorme
flexibilité au programmeur, qui peut choisir le langage qui lui convient en fonction de ses préférences et des
besoins de programmation pour chaque programme spécifique.
Inconvénientsnipula tion
L’inconvénient principal lié à cette solution est le fait que les programmes CGI sont des programmes
externes au serveur Web, ce qui implique la nécessité de démarrer un processus système pour chaque
requête. Ceci limite de façon importante les performances et la scalabilité de ces solutions.
Ensuite le fait de devoir écrire des véritables programmes et de devoir utiliser des langages qui ont des
fonctionnalités assez évolués implique l’utilisation de langages tels qu C, C++, Perl ou Java, qui sont
malheureusement assez compliqués à apprendre et utiliser.
Enfin les programmes CGI ne sont pas toujours portables, car il est possible qu’ils soient compilés pour le
type de machine sur laquelle tourne le serveur. Si l’on voulait changer de machine, il faudrait recompiler les
programmes à nouveau en espérant qu’un compilateur pour le langage utilisé existe pour la nouvelle
machine. En tout cas il faudrait gérer à la fois les sources et les équivalents binaires.
- 47 -
Cas d’utilisation souhaités
Les CGI sont la première solution qui permettait la création de sites dynamiques et profite par conséquent du
fait qu’elle est une solution mature et largement adoptée. Il faut toutefois noter qu’elle a quelques défauts de
vieillesse et que les solutions qui sont apparues par la suite ont quelques avantages notables qui les rendent
préférables, permettant notamment des développements plus rapides et facilités. Il existe toutefois un cas
d’utilisation lorsque il est possible de réutiliser une bonne partie des programmes CGI déjà existants.
PHP (PHP Hypertext Preprocessor)
6.2.2.1 Origines
PHP a été créé en 1994 par Rasmus Lerdorf au cours d’un projet ayant pour but d’adopter son site web
personnel d’outils pour l’analyse des connexions établies sur son site. Dans cette conception initiale PHP
était l’acronyme de Personal Home Pages et contenait les couches de base d’un langage de script.
Cette version a été rapidement enrichie l’année suivante d’un moteur d’exécution de commandes SQL et
d’un outil d’interprétation de formulaires. Elle était librement distribuée et connue sous le nom de PHP 2.0
ou PHI-FI (Form Interpereter). Cette version possédait déjà une bonne partie des atouts des versions
récentes, étant déjà un langage de script simple à apprendre et spécifique au Web, interprété coté serveur,
multi plate-forme, directement intégrable au sein de pages HTML et pouvant exploiter une connectivité aisée
avec certaines bases de données.
En 1997 deux autres développeurs, Andi Gutmans et Zeev Zuraski, réécrivent le moteur d’interprétation de
PHP (écrit en C), qui est désormais dans sa version 3.0. Parallèlement à l’introduction du nouveau moteur, la
spécification d’une interface de programmation standard (API) a permis à des développeurs indépendants de
contribuer à la croissance du langage en développant une libraire de modules d’extension considérable. Une
partie de ces modules est intégrée directement dans les distributions successives du moteur PHP, d’autres
sont disponibles sur Internet comme extensions optionnelles. Les performances améliorées du nouveau
moteur d’interprétation, l’accroissement de la productivité des programmeurs grâce à la libraire de modules
d’extension fournie avec le langage et la disponibilité gratuite des sources permet à PHP de devenir un acteur
sérieux sur le marché des solutions pour la génération dynamiques de pages Web.
Parmi les modules qui ont été rattachés au langage au cours de cette troisième version, on peut compter des
modules d’accès au système d’exploitation de la machine hôte, des modules de manipulation de chaînes de
caractères, le support des expressions régulières, les fonctions spécifiques aux tableaux, le support d’un
grand nombre de bases de données9, le support de certains protocoles Internet (messagerie, transfert de
fichier, transmission sécurisée SSL, accès aux annuaires électroniques, xms etc.), des modules de gestion
graphique, donnant la possibilité de créer des images à la volée et d’autres encore.
En 1999, le moteur d’interprétation est une nouvelle fois réécrit et se base sur un langage plus général appelé
Zend (le nom provient de la contraction des noms de ses développeurs, Zeev et Andi), ce qui en augmente
encore une fois les performances. Une couche d’abstraction entre le serveur et le langage a été aussi
développée pour pouvoir supporter un plus grand nombre de serveurs et faciliter la portabilité sur les
différents serveurs. Cette quatrième dernière version de PHP a été aussi enrichi d’autres modules, dont les
plus important est le support des sessions et de l’accès directe à des objets et servlettes Java et des
architectures CORBA et COM [xxx].
Dès son départ, PHP a été un logiciel « open source », c’est à dire un logiciel libre de droit, dont les sources,
la documentation et les évolutions sont disponibles gratuitement sur Internet. La disponibilité en libre accès
des sources d’un programme est souvent un gage de la qualité impeccable du produit (qui sont parfois mieux
9
PHP supporte le standard ODBC, ainsi qu’un accès natif aux principales bases de données disponibles, tels Adabas, dBase,
DB2 (avec ODBC) Interbase, Informix, Ingres, mSql, Microsoft Sql Server, MySql, Oracle, Postres, syBase,…
- 48 -
que leur contreparties payantes ) et permet de rassurer les utilisateurs, car chacun de à la possibilité de
consulter le code source, le comprendre et éventuellement les corriger ou modifier.
Cette disponibilité confère à PHP plusieurs avantages et quelques inconvénients. Un premier avantage est la
gratuité du langage et la facilité de se le procurer, qui contribuent à la diffusion du langage sur le marché. Un
deuxième avantage et le fait d’avoir permis la création d’une communauté de développeurs indépendants très
active qui contribue à l’évolution du langage en développant et implémentant de nouvelles fonctionnalités et
extensions et qui mettent à disposition leurs expérience à l’aide d’autres développeurs à travers des mailinglists et des forums. Ceci permet d’assurer l’évolution du langage et la mise à disposition rapide de nouvelles
fonctionnalités. Un troisième avantage est le fait de pouvoir rassurer les utilisateurs du fait qu’ils ne sont pas
prisonniers d’une technologie propriétaire, car ils peuvent toujours vérifier la qualité du langage, corriger les
éventuels erreurs et même faire évoluer le langage en fonction de ses exigences. Parmi les inconvénients
dues à ce choix on peut citer le fait que l’intégration avec certains systèmes propriétaires (essentiellement les
systèmes Microsoft) a été volontairement rendue difficile et que le support du langage avec des outils de
développement et des entreprises de conseil professionnel est encore peu développé. Selon une étude
Netcraft10 il est estimé que environ 6% des domaines Web utilisent PHP à l’heure actuelle.
6.2.2.2 Présentation
PHP est défini par ses développeurs comme un langage de script interprété coté serveur, pouvant être inséré à
l’intérieur même des pages HTML, simple à apprendre et spécifique au Web.
PHP est un langage dont les instructions peuvent être librement imbriquées à différents endroits et à
plusieurs reprises dans une page HTML ou dans n’importe quel type de fichier textuel. Les instructions PHP
sont identifiées et différenciées du reste de la page HTML à l’aide de balises spéciales, qui indiquent le début
et la fin d’un bloc d’instructions PHP. Ces balises peuvent prendre quatre différents formes:
”<?php instructions ?>”, ”<?” instructions ”?>”, ”<%” instructions ”%>”, ”<script language=”php>”
instructions ”</script>”.
Le travail de conception de PHP a été inspiré par d’autres langages populaires disponibles à l’époque tels
Perl, C, Java et JavaScript. L’influence de ces langages sur la conception de PHP est particulièrement visible
au niveau de sa syntaxe, qui a été rendue très similaire à celle du C pour faciliter l’apprentissage du langage
par des programmeurs qui étaient déjà habitués à ce type de syntaxe.
PHP est un langage interprété, qui peut être vu comme un outil de modification de fichiers, transformant un
script PHP contenant les instructions PHP à interpréter mélangés à des instructions HTML en un fichier de
sortie qui est une page Web qui ne contient que du HTML prête pour être envoyée au client. Son
fonctionnement est le suivant: le moteur d’interprétation passe en revue le script du haut vers le bas de la
façon suivante: les instructions à l’intérieur des blocs php sont interprétées et le texte situé à l’extérieur des
ces blocs est recopié tel quel dans le flux de sortie qui est correspond à la page demandée par l’utilisateur qui
est en cours de construction.
Ce mode de fonctionnement fournit l’avantage que les modifications des programmes sont immédiatement
prises en compte sans devoir reconstruire, recompiler et relivrer les sources à chaque modification et
permettent de se passer de la gestion parallèle des fichiers sources et des leurs équivalents binaires.
PHP ne désigne pas seulement un langage de script, mais une architecture complète, représentée
Pages PHP
Module
obdc
Module
graphique
Module
…
API des extensions
Moteur Zend
10
www.e-soft-inc.com/survey/
Moteur PHP
SAPI
- 49 -
Serveur Web
Figure x, Architecture du langage PHP
schématiquement dans la figure suivante.
Cette figure a été dessinée de façon a ce que toutes les fonctions accessibles par les pages PHP sont
adjacentes à la barre horizontale qui les représente en haut de la figure: on peut remarquer que toutes les
fonctions des différents composants de l’architecture PHP sont disponibles directement pour être utilisées
(dans le cas des modules d’extension pour autant qu’ils aient été installé) et ne sont pas organisées de façon
hiérarchisée. Ceci permet une immédiate utilisation de toutes les fonctions, mais peut résulter déroutant vu le
grand nombre de fonctions à disposition. Les conventions de nommage, l’intuitivité des noms des fonctions
et la bonne documentation facilitent toutefois le repérage des fonctions dont on a besoin.
Dans cette figure on peut distinguer le nouveau moteur d’interprétation Zend, qui est entouré des fonctions
de base de PHP. Ces deux couches constituent le noyau central du langage, ils définissent la syntaxe et la
sémantique des instructions PHP, c’est à dire comment les instructions doivent être écrites et interprétées. Il
faut noter que Zend est d’un niveau plus générique que PHP et que son moteur pourrait alimenter d’autres
langages.
L’interface avec les différents serveurs est assurée par une couche d’abstraction appelée SAPI, qui permet de
standardiser la façon dont PHP communique avec le serveur et en assure l’indépendance. Grâce à cette
interface PHP peut fonctionner sous forme de CGI sur différentes plates-formes. En particulier PHP est
supporté par les principaux serveurs Web, parmi lesquels on peut distinguer les serveurs Apache et Microsoft
IIS, et peux même s’interfacer à des moteurs de servlettes Java. Il faut toutefois remarquer que PHP s’intègre
mieux avec Apache sous Unix, étant disponible comme module Apache et qu’il est donc conseillé d’utiliser
cette plate-forme comme serveur de production.7
Les modules d’extension au langage sont des bibliothèques de fonctions déjà prêtes à l’emploi et qui
prennent en charge un grand nombre de fonctionnalités. Un certain nombre de ces modules est fourni
directement avec les sources de PHP, ce qui facilite grandement le développement et la productivité des
développeurs. Il suffit de parcourir la documentation officielle pour se rendre compte de l’ampleur de la
libraire fournie avec le langage. Il existe aussi d’autres modules disponibles sur le réseau à titre gratuit ou
contre payement qui peuvent être intégrés à PHP. Il est aussi possible de développer ses propres modules en
suivant les spécification de l’interface de programmation (API) proposée par PHP.
Cette dernière a été spécifiée pour que des développeurs indépendants puissent écrire et intégrer ses propres
modules avec PHP, favorisant ainsi le développement de sa libraire de fonctions et l’évolution rapide du
langage. Si PHP est devenu une solution avec une libraire de programmation complète, malgré sa relative
jeunesse, c’est grâce à l’apport de ces personnes. En effet les contributions de ces développeurs permettent à
PHP d’être un langage en continue évolution, ce qui contribue au développement rapide de nouvelles
fonctionnalités, mais au prix d’avoir en résultat une bibliothèque qui manque d’une cohérence globale et qui
est peu standardisée et stable.
En effet il arrive que les modules d’extension fournis avec la distribution officielle diffèrent, parfois
considérablement, selon la version utilisée du langage: certains modules sont enlevés au profit d’autres plus
récents, d’autres encore sont modifiés. Cette instabilité dans la libraire fournie constitue un motif de souci,
car cela entrave la portabilité du code à travers les serveurs et rend plus difficile l’adoption d’une nouvelle
version du langage. Il est toutefois toujours possible d’installer les vieux modules, qu’il suffit de décharger,
inclure au langage et recompiler les sources.
6.2.2.3 Fonctionnalités
PHP est essentiellement un langage de script interprété coté serveur au moment de l’exécution, un langage de
programmation allégé avec beaucoup de facilités syntaxiques, qui est facile à apprendre et utiliser. PHP offre
les fonctionnalités typiques d’un langage procédural. On peut penser à un programme comme étant composé
d’algorithmes et d’une structure de données. Coté algorithmique, PHP implémente des instructions
d’affectation, d’évaluation d’expressions, des instructions conditionnelles, des répétitions, de modification
du flux d’exécution, des fonctions et des procédures. Coté structure de données on recense les variables, les
- 50 -
tableaux, les structures basés sur des références à des variables (pointeurs), les fichiers et les de bases de
données. Par ailleurs PHP supporte les variables « variables » (des variables dont le nom est construit à l’aide
d’une autre variable) et l’expansion des variables à l’intérieur des chaînes de caractères (la substitution de la
valeur de la variable dans la chaîne). Pour un survol de la syntaxe et des commandes PHP, une référence très
conseillée est l’introduction du livre PHP Pocket Reference, disponible gratuitement sur le réseau [xxx], ou
un des nombreux tutoriaux disponibles sur Internet [xxx].
Dans ses versions récentes, PHP supporte également de façon assez rudimentaire le paradigme objet, qui
facilite la réutilisation du code créé. PHP n’est pas un véritable langage orienté objet, ne respectant pas le le
principe d’encapsulation des traitements et des données et ne permettant de définir des méthodes ou
propriétés comme privés ou protégés. En gros PHP permet de travailler avec des objets en offrant la
possibilité de définir des classes à partir desquelles créer des instances des objets et en supportant la notion
d’héritage. C’est loin des implémentations du paradigme objet dans d’autres langages tels Smalltalk, Java et
C++.
PHP est un langage faiblement typé, n’obligeant pas à déclarer des variables préalablement à leur utilisation
et ne permettant pas de leur attribuer un type de données fixé à l’avance. Le typage des variables est effectué
automatiquement au moment de l’affectation des données et la variable peut changer de type si on lui
attribue d’autres données. PHP effectue automatiquement un certain nombre de conversions de type de
données lors de leur utilisation, et le programmeur a aussi la possibilité d’effectuer des conversions
explicites. Bien que le développement est rendu considérablement plus simple et plus rapide, il faut payer le
risque d’encourir dans des erreurs de programmations plus difficilement détectables et à un déboguage bien
plus compliqué.
La bibliothèque d’API fournie en standard avec PHP est considérable et donne accès à un grand nombre de
fonctions utiles à travers ses différents modules. Il est d’ailleurs possible d’ajouter des modules optionnels
développés par différents développeurs et accessibles par Internet. Il faut toutefois noter que les différents
modules étant développés par des développeurs plus ou moins indépendants et le langage étant encore assez
jeune, la libraire de modules est peu cohérente et peu stable. Il se peut qu’un certain nombre de modules
soient ajoutés, modifiés ou éliminés entre deux distributions de PHP.
Etant un langage spécifiquement conçu pour le Web, PHP implémente de nombreuses fonctions spécifiques
à cet environnement. A titre d’exemple PHP permet l’écriture et la lecture de cookies, la gestion des sessions,
l’envoi d’en têtes http, des fonctions de codage et décodage des caractères spéciaux à l’intérieur des URL et
la création automatique de variables contenant toutes les données envoyées par le client dans sa requête au
serveur et qui sont accessibles dans le script. Ces données comprennent les données contenues dans l’URL,
saisies dans un formulaire et les en-têtes optionnels de la requête portant sur les détails de la requête et la
configuration du navigateur. PHP convertit automatiquement chaque couple nom-valeur contenu dans la
requête en des variables de même nom (si par exemple si une page contient un formulaire avec deux champs
nommés « nom » et « prenom », lors du traitement de la requête le moteur PHP crée deux variables nommées
$nom et $prenom et leur attribue les valeurs entrées dans les champs respectifs. PHP ne permet cependant
pas d’utiliser des variables globales de niveau application.
Une autre fonctionnalité qui vaut la peine d’être mentionné est la possibilité d’inclure dans un script le
contenu d’autres fichiers de type textuel, en particulier des autres scripts et des parties de pages HTML. Cette
possibilité favorise la réutilisation du code en permettant de confiner des fonctions génériques ou des paries
de mise en page (i.e. des barres de menu) dans des fichiers et en incluant les fichiers dans laes pages qui en
nécessitent l’usage. Ceci constitue également un moyen simple de créer sa propre bibliothèque de fonctions
et de séparer contenu et présentation, à travers l’utilisation de fichiers spécifiques aux différentes fonctions,
par exemples des fichiers de recherche de contenu et des fichiers de mise ne page.
PHP implémente un nombre considérable de fonctions pour la manipulation du texte, ce qui n’es pas
étonnant étant donné qu’une page Web n’est rien d’autres qu’un fichier texte. Ces fonctions permettent
d’effectuer facilement des recherches et des remplacements d’un mot dans un texte, scinder un texte en mots,
découper, parcourir et reconstruire les chaînes de caractères etc. Parmi les fonctions de manipulation de texte
- 51 -
se trouvent les expressions régulières, empruntés du langage Perl, qui permettent de vérifier si une chaîne de
caractères correspond à un schéma déterminé et effectuer des substitutions le cas échéant, par exemple
vérifier si les données saisies dans un formulaires correspondent à un e-mail valide.
PHP supporte également un grand nombre de protocoles Internet et implémente des fonctions spécifiques au
réseau, comme les fonctions nécessaires à se connecter à d’autres serveurs Web, encoder les chaîne pour être
compatibles avec les URL, transférer des fichiers à travers FTP, contrôler ou envoyer des e-mail, supporter le
protocole XML etc.
Un aspect particulièrement bien développe par de PHP est l’impressionnante connectivité avec les bases de
données et les autres systèmes. En effet PHP supporte le standard de connexions aux bases de données
OBDC en plus d’un support natif des API des principales base de données. Il manque cependant du support
d’une façon universelle d’accéder aux différentes sources de données telles les solutions JDBC de Sun ou
ADO de Microsoft et d’un mécanisme intégré de gestion des transactions ou d’informatique distribuée. PHP
devrait aussi être en mesure de pouvoir être intégré aux architectures de composants Java et COM.
Parmi les autres fonctionnalités notables de PHP on trouve des fonctions spécifiques à la manipulation des
tableaux (qui constituent en effet la principale « architecture de donnée » du programme), des fonctions
graphiques permettant de générer des images à la volée, des fonctions d’accès au système de fichiers du
serveur, différentes fonctions mathématiques, des fonctions de date et temps, la possibilité de manipuler des
fichiers pdf,….
Un point sensible où PHP ne permet pas de bonnes performances est toutefois la gestion des erreurs. En effet
PHP ne prévoit pas de structures pour gérer des erreurs: les erreurs détectés au moment de l’exécution du
script sont simplement insérés dans le flux de sortie, la page Web, et l’exécution du script est interrompue.
Ceci signifie que l’utilisateur voit les messages d’erreur directement générés par le moteur d’interprétation,
ce qui, en plus de ne pas être agréable, peut comporter des risques sécuritaires.
6.2.2.4 Productivité: bibliothèque d’API, réutilisabilité du code et logiciels de développement
PHP favorise la productivité du développement à l’aide de la vaste libraire de modules d’extension fournie
en standard avec le langage et qui peut d’ailleurs être élargie par des modules optionnels disponibles sur le
réseau. Ces modules permettent aux programmeurs de concentrer leurs efforts sur de la logique de plus haut
niveau, les mécanismes de bas niveau étant pris en charge par les fonctions préprogrammées des modules.
La réutilisation du code peut être obtenue en programmant des objets ou fonctions de façon assez générique
pour qu’ils puissent être utilisés et en utilisant la fonction d’inclusion de fichiers dans un script. Aucune
technologie n’est prévue dans PHP pour créer des composants réutilisables standard, c’est au programmeur
de se doter de ses propres conventions.
Pour le développement de scripts PHP il est possible de recourir à des simples éditeurs texte généraux ou à
des logiciels de traitement de texte, bien qu’ils manquent de certaines fonctionnalités qui facilitent le
développement. Des meilleures alternatives sont les éditeurs spécialisés dans l’écriture de code, spécifiques à
PHP (comme PhpEditor) ou généraux, mais personnalisables sur le langage à employer, tels Emacs et
UltraEdit qui offrent des fonctions utiles tels que la coloration syntaxique et l’indentation automatique.
La meilleure solution est cependant l’utilisation de véritables outils de développement. Ces logiciels
permettent un développement plus rapide et plus fiable, offrant souvent des possibilités de débogage,
fournissant des listes de commandes avec leur syntaxe, complétant automatiquement de bouts de code, de
génération de squelettes des programmes en partant de modèles abstraits etc. environnements de
développement disponibles pour ce langage sont cependant assez rares et de qualité assez approximative:
parmi eux on peut compter PHPEd et Zend IDE, et PHP Coder. Il faut cependant noter que leur qualité est
cependant inférieure à ceux disponibles pour d’autres langages.
- 52 -
6.2.2.5 Performance et scalabilité
PHP est un langage interprété, ce qui devrait comporter une plus grande lenteur d’exécution des programmes
par rapport aux langages compilés, car leur exécution se passe de l’étape de traduction des instructions en
commandes compréhensibles par la machine sur laquelle tourne le programme.
Le moteur d’interprétation PHP/Zend est quand même très rapide et Zend fournit aussi des produits
optionnels qui peuvent en augmenter la performance, en particulier Zend Optimizer, un optimisateur de code,
et Zend Cache, un gestionnaire de cache qui permet de garder en mémoire des scripts PHP pré-compilés.
Grâce à ces produits, PHP permet d’atteindre des très bonnes performances par rapport aux solutions
concurrentes. En effet, dans une comparaison effectuée par Jim Rapoza du magazine eWeek, PHP a obtenu
des meilleures performances par rapport à tous ses concurrents excepté ASP.
Parmi les autres facteurs qui permettent à PHP des bonnes performances il faut citer le support natif d’un
grand nombre de bases données, ce qui permet de se passer du travail supplémentaire effectué par des
couches d’abstraction tels que OBDC (qui est également supporté).
Les performances de PHP sont toutefois largement dépendantes de la façon dont PHP est installé. En effet
PHP ne permet des bonnes performances que dans le cas où il est installé comme module intégré à un serveur
(ce qui signifie pour le moment au serveur Apache). Lorsque PHP est installé comme module CGI le serveur
est contraint à démarrer une instance du moteur PHP (c’est à dire à lancer un processus système) à chaque
fois qu’il reçoit une requête. Les performances souffrent donc du travail supplémentaire du lancement du
processus et de la plus grande consommation de ressources. Lorsqu’il est installé comme module intégré, le
serveur a à disposition un certain nombre d’instances du moteur PHP en exécution continue auxquels il peut
attribuer le traitement d’une requête PHP en fonction de leur disponibilité et le nombre d’instances actives en
même temps peut être changé en fonction du nombre de requête reçues. Les performances sont donc
nettement meilleures grâce à l’absence de la nécessite de démarrer un processus à chaque requête et à la
moindre consommation de ressources.
L’augmentation du trafic portant sur les pages PHP conduit à une forte diminution de la performance. Pour
pallier à cet inconvénient, la seule solution supportée par PHP est celle d’insérer des serveurs spécialisés
dans la répartition du trafic en amont des serveurs Web, de façon que la répartition du trafic soit
complètement transparente pour les serveurs Web sur lesquels tournent les moteurs PHP travaillent. PHP
n’est pas une solution scalaire. Il n’existe ni des produits software qui permettent à PHP de travailler dans
une architecture de type « cluster », où le travail est factorisé sur un certain nombre de serveurs, ni des
serveurs d’application compatibles directement avec PHP (bien qu’il soit possible d’utiliser un serveur
d’application à travers les fonctions de communication/traduction entre le script et des objets Java).
6.2.2.6 Portabilité
Comme toutes les solutions coté serveur, la portabilité vis-à-vis du client est absolue, car ce dernier ne reçoit
qu’une page HTML ordinaire, constituée de texte formaté selon le formalisme HTML avec éventuellement
l’insertion de scripts ou composants coté client.
Le problème de la portabilité se pose cependant coté serveur. Grâce à la couche d’abstraction de serveur
ISAPI, PHP devrait pouvoir fonctionner avec n’importe quel type de serveur de la même manière. Parmi les
différents serveurs Web qui supportent PHP on trouve Apache, Roxen, IIS, Xitami et Omni. Cette couche
permet aussi à PHP d’interagir avec des moteurs de servlettes Java.
Cependant l’utilisation de PHP en tant que module couplé au moteur du serveur est restreinte au serveur
Apache, ce qui en diminue grandement la portabilité, qui est alors possible au prix d’une diminution de
performances. Il est aussi connu que PHP s’intègre mieux avec Unix et que le couple Unix/Apache est le seul
qui est vraiment conseillé pour être utilisé en tant que serveur de production.
- 53 -
6.2.2.7 Sécurité
Etant une solution coté serveur, la sécurité du code PHP est obtenue par le fait que le code source est abrité
et exécuté sur le serveur et il ne sera jamais envoyé tel quel au client: ce dernier n’obtiendra que le résultat de
l’exécution des scripts.
Néanmoins, le fait que PHP ne permet pas une bonne gestion des erreurs induit un certain problème
sécuritaire par le fait que lorsque des erreurs inattendus se produisent, un message d’erreur est émis par le
moteur PHP directement dans le flux de sortie, c’est à dire dans la page à envoyée au client, avant que
l’exécution du script soit arrêtée. Ceci peut donner aux utilisateurs malintentionnés des précieuses
indications sur comment fonctionne le site Web et leur faciliter des actions d’attaque au même.
En plus, PHP lui même ne prévoit pas un modèle de sécurité explicite et se base sur les mécanismes de
sécurité du serveur permettant la restrictions d’accès à la suite d’une authentification à ses différents
répertoires ou sur des mécanismes programmés ad hoc par le développeur.
6.2.2.8 Séparation entre contenu, logique de traitement et présentation
PHP permet une séparation approximative entre contenu, logique de traitement et présentation. Cette
séparation est obtenue à des degrés différents en fonction de l’architecture qui est utilisée, cependant le
meilleur niveau de séparation qu’on peut obtenir avec PHP est de loin inférieur à celui qu’on peut obtenir
avec des solutions qui donnent la possibilité de programmer des composants facilement assemblables tels
JSP et ASP.
L’architecture minimale utilisable avec PHP est une architecture client-serveur simple, où le premier
demande les pages et se charge de leur visualisation, le deuxième interprète les requêtes, interagit avec le
moteur PHP auquel il envoie le script à interpréter, reçoit en retour la page Web à renvoyer au client et
envoie la page au client. En plus des mécanismes qui peuvent être utilisés dans une architecture statique tels
que l’utilisation de feuilles de style en cascade (CSS), PHP permet une meilleure séparation entre contenu et
présentation à l’aide des fonctions d’inclusion d’un fichier dans un script au moment de son interprétation.
Ces fichiers peuvent être utilisés pour séparer du reste des pages des briques de présentation, des éléments
graphiques, des fonctions de logique de traitement, des fonctions permettant la recherche de contenu etc. En
plus de la séparation entre les différentes préoccupations, cette technique facilite la réutilisabilité, la
maintenance et la fiabilité du code et favorise la cohérence globale du site.
Une meilleure séparation du contenu peut être obtenue avec l’utilisation d’une base de données. On parle
dans ce cas d’architecture trois-tiers qui comporte en plus des éléments précédents l’utilisation d’une base de
données interrogée par le moteur PHP. Celle-ci permet de stocker le contenu d’une façon structurée, offre de
nombreux services (indexations, contrôles d’intégrité, transactions,…) et peut même contenir des procédures
qui effectuent certains traitement. Dans une architecture trois tiers, le coté client est chargé de la visualisation
de la page, le serveur avec le moteur PHP de la logique de traitement et de présentation et la base de données
du contenu. Sur le serveur, la logique de traitement et de présentation peut être divisée en utilisant les
fonctions d’inclusion de fichiers.
Un pas supplémentaire dans la division du contenu et de la présentation consisterait à utiliser un serveur
d’application qui s’insère entre le serveur et la base de données. Le serveur d’application permet d’offrir un
certain nombre de services et en particulier peut être utilisé pour séparer la logique de traitement de la
logique de présentation. Il devrait aussi être possible d’utiliser PHP dans une architecture de ce type, grâce à
la possibilité d’interagir avec des objets Java et avec les technologies COM de Microsoft et CORBA,
cependant le support de ces systèmes n‘est pas encore mature.
6.2.2.9 Conclusions
Avantages
- 54 -
PHP est une solution très intéressante pour le développement de sites Web dynamiques, car elle combine un
langage de script qui est assez facile à apprendre et utiliser avec une libraire de fonctions assez complète.
Ceci en fait une solution qu’il est possible d’utiliser convenablement pour des développements occasionnels
de sites, grâce à la rapidité avec laquelle il est possible de devenir productif.
La libraire de fonctions fournie avec le langage couvre toutes les fonctions principales dont un
programmateur Web a besoin et la documentation fournie permet de trouver rapidement les fonctions dont
on a besoin. Le point essentiel de cette libraire est la considérable connectivité offerte par le langage, avec
notamment le support d’un grand nombre de bases de données Sont aussi appréciables les fonctionnalités
typiques du Web (création des variables issus de la requête HTTP, sessions, cookies, codage des URL,…), le
support de différents protocoles Internet, la manipulation de chaînes de caractères et les capacités graphiques.
Lorsqu’il est utilisé comme module intégré au serveur Apache, PHP permet de réaliser de très bonnes
performances en termes de pages servies par seconde.
Enfin PHP est une solution open source, gratuite et facilement téléchargeable à partir du réseau. Le fait que
les sources soient libres permet aux utilisateurs d’être rassurés, parce qu’ils peuvent en contrôler la qualité et
les modifier pour faire évoluer leur programme. En plus cela permet à un grand nombre de développeurs de
contribuer à l’évolution du langage, qui peut par ce moyen incorporer rapidement des nouvelles
fonctionnalités, fournir du support aux autres utilisateurs.
Inconvénients
Un inconvénient majeur du langage est qu’étant relativement jeune et développé par une multitude de
développeurs, la bibliothèque de fonction qui est fournie avec le langage est instable et peu cohérente. En
effet il arrive que les modules inclus en standard avec les sources changent d’une version à une autre et que
les modules n’aient pas été développés de la même façon.
Un deuxième point où PHP peut poser certains problèmes est la portabilité. Bien qu’étant une solution open
source et grâce à l’interface SAPI PHP peut être utilisé avec n’importe quel type de serveur et de système
(pourvu qu’il existe un compilateur C pour ce système), la seule implémentation fiable en tant que module
intégré dans un serveur est celle pour le serveur Apache dans un environnement UNIX. La portabilité sur
d’autres systèmes est possible au prix de devoir fonctionner comme module CGI, ce qui limite les
performances.
Enfin, les outils de développement disponibles pour ce langage ne sont pas à l’hauteur des outils disponibles
pour les autres solutions.
Cas d’utilisation souhaité
PHP est certainement une solution qui permet de développer des sites professionnels de très grande qualité et
avec des bonnes performances, de façon assez rapide et économique. La gratuité et la facilité d’apprentissage
rendent PHP idéal pour des projets de petite et moyenne taille ou pour lesquels les ressources humaines,
financières et matérielles à engager sont limitées.
PHP ne réussit cependant pas à se démarquer des solutions concurrentes, par rapport auxquelles elle est
inférieure dans un certain nombre de dimensions. En particulier, le manque d’outils de développement et les
moindres possibilités de séparation et réutilisation de code constituent un point négatif qui limiterait PHP à
des projets de petite et moyenne taille. En particulier le douteux support des architectures COM, Java et des
serveurs d’applications qui y sont associés fait en sorte que PHP n’est pas une solution idéale pour le
développement d’applications de grandes entreprises.
6.2.3 ASP (Active Server Pages)
- 55 -
6.2.3.1 Présentation
ASP est un standard de propriétaire proposé par Microsoft permettant de développer des pages dynamiques.
ASP. Sa première version a été développée et livrée au public à la fin de 1996. L’année suivante, ASP est
intégré dans la distribution de la nouvelle version du principal serveur Web de la même entreprise, Microsoft
IIS11 3.0, dans le but de tirer profit de la position privilégiée de ce produit sur le marché pour lancer sa
nouvelle technologie.
Dès son début, la stratégie marketing de Microsoft a été claire et radicalement opposée à celle de PHP. Dans
le but de gagner rapidement en notoriété et en parts de marché, Microsoft a cherché de tirer profit de son
poids dans l’industrie du software pour imposer sa nouvelle solution auprès du public en l’imposant avec ses
autres produits et faisant en sorte que ce soit la seule technologie qui puisse s’insérer facilement avec ses
autres produits. Cette démarche marketing a donné des résultats encourageants, permettant l’adoption rapide
de ASP par un grand nombre de développeurs liés aux produits Microsoft.
Etant donné le succès de cette stratégie, Microsoft la poursuit en 1998 avec le lancement de la deuxième
version de ASP, livrée avec les nouvelles versions des serveurs Web Microsoft. La troisième version est
développée l’année suivante et est livrée, avec le serveur IIS, directement dans Windows 2000. Dans chaque
nouvelle version, des nombreuses améliorations sont ajoutés par rapport à la précédente, dont on citer le
développement un modèle enrichi pour gérer la communication entre le client et le serveur.
ASP est présenté non pas comme étant un langage, mais comme étant une technologie. En effet ASP définit à
la fois un standard organisé autour d’un modèle d’objets et un moteur d’interprétation de scripts. Le langage
de script n’est pas spécifié dans le standard ASP et son choix est laissé à l’utilisateur pour autant que le
serveur dispose d’un moteur d’interprétation pour le langage choisi.
L’implémentation du moteur ASP dans les serveurs Microsoft (IIS et PWS) est faite sous forme de libraire
dynamique (un fichier DLL*). Ce moteur est capable d’interpréter les instructions écrites avec les langages
VBScript, qui est le langage par défaut de ce serveur, et JScript (l’implémentation Microsoft -et non
compatible à 100%- de JavaScript).
ASP s’intègre parfaitement avec les serveurs de la maison Microsoft, en particulier IIS sur Windows, mais il
existe également des versions développées par des tierces parties pour d’autres serveurs disponibles sur
d’autres plate-formes, tels le serveur Apache et Netscape sur Unix.
Les pages ASP sont des fichiers sont des fichiers textuels où il est possible d’insérer des instructions d’un
langage de script directement à l’intérieur d’une page HTML. L’idée est la même que les solutions PHP et
JSP: les instructions d’un langage de script sont insérées au cœur même des pages HTML grâce à
l’utilisation de balises spéciales qui les distinguent du reste de la page. Dans ce cas les balises prennent la
forme <%…instructions…%> ou la forme <script language=xxx runat=server> …instructions...
</script> (à noter qu’avec la balise script il faut spécifier l’attribut runat, car par défaut les langages de script
s’exécutent coté client).
11
Internet Information Server
- 56 -
ASP est structuré autour d’une architecture d’objets, permettant d’effectuer les principaux traitements liés
aux pages dynamiques et donnant à ASP sa réelle valeur ajoutée par rapport au langage utilisé. Ce modèle
d’objet répartit les fonctionnalités offertes par ASP dans 7 objets distincts: Request, Response, Server,
Application, Session, ObjectContext et ASPError. Ce modèle est représenté dans la figure xxx. Les objet
Request et Response représentent respectivement la requête et la réponse HTTP. Session et Application
permettent de régrouper respectivement les requêtes d’un client et les requêtes à un ensemble le pages.
L’objet Server represente les serveur, ASPError est utilisé pour la gestion des erreurs et ObjectContext pour
gérer les transactions. Ces objets seront repris dans la section suivante.
Application object
Session object
Requête HTTP
Request
object
Réponse
Response
object
Client
Session object
Requête HTTP
Request
object
Réponse
Response
object
Client
Server
object
ASPError
object
Figure… : Le modèle d’objet d’ASP
L’architecture ASP ne se limite pas à ce modèle d’objets, bien que celui-ci en constitue le cœur. En effet ce
modèle est complété par les fonctionnalités propres au langage de script utilisé, par les fonctionnalités
offertes par les composants optionnels et par d’autres technologies développées par Microsoft et qui sont
exploitables à par les pages ASP, tels les technologies d’accès aux données ADO, Active X et COM+.
Les composants optionnels sont des ensembles d’objets packagés ensemble qui répondent à un certain
problème en offrant différent fonctionnalités. Un certain nombre de ces composants sont fournies
directement par Microsoft lui-même dans la distribution de ASP, d’autres composants sont obtenables auprès
de sources tierces et d’autres encore peuvent être développées par soi-même au cours de son propre travail.
ADO est une technologie d’accès aux données stockés sous différentes formes, ActiveX et COM+
permettent de développer des composants logicielles de façon à ce qu’il puissent travailler ensemble. On
discutera des fonctionnalités offertes par les différents composants de la technologie ASP dans la section
suivante.
6.2.3.2 Fonctionnalités
ASP ne précise pas un langage à utiliser. Celui-ci peut être librement choisi à condition d’avoir un moteur
d’interprétation installé sur le serveur capable d’en interpréter les instructions. Parmi les langages qui
peuvent être utilisés avec ASP on trouve notamment VBScript et JavaScript (ou son implémentation maison
Microsoft, JScript.). Ces langages de script sont des langages interprétés qui offrent des possibilités
- 57 -
classiques d’un langage procédural et la possibilité de travailler avec les objets qui lui sont mis à disposition
par l’environnement d’exécution. Leur pouvoir est semblable au noyau de base de PHP. Pour davantage
d’information sur les possibilités offertes par ces langages il est possible de consulter la section qui leur est
dédiée.
Il faut noter que ces langages peuvent être utilisés coté client et coté serveur, la différence principale liée au
lieu d’exécution étant les objets auxquels ils ont accès. Tandis que coté client ces langages ont accès aux
objets mis à disposition par le navigateur, coté serveur, le langage de script peut utiliser les objets mis à
disposition par le cadre ASP et accéder à d’autres systèmes comme les bases de données. Il est possible de
mélanger dans une même page des scripts traités coté serveur et coté client, en précisant dans les balises le
lieu d’exécution: Lorsque le lieu d’exécution est le serveur, le client ne reçoit que le résultat du script et n’a
pas moyen de connaître le code source.
Comme on vient de le voir, les fonctionnalités de ASP sont contenues à différents endroits de l’architecture
ASP : le langage de script utilisé, les objets du modèle d’objets, les composants additionnelles et les autres
technologies compatibles. Le modèle objet constitue la véritable valeur ajoutée d’ASP et contient les
principales fonctionnalités de cette solution. Il répartit les fonctionnalités offertes par ASP dans 7 objets
distincts: Request, Response, Server, Application, Session, ObjectContext et ASPError.
L’objet Request représente la requête HTTP et permet à un script ASP d’accéder facilement aux différentes
informations envoyées par le client à travers sa requête. Ces informations sont organisées par catégorie et
traduits dans des collections de paires nom-valeur L’objet Request de ASP permet l’accès aux données
passés dans l’URL (collection QueryString), aux données envoyés grâce un formulaire dans le corps de la
requête (Form), aux données stockés dans les cookies sur la machine client (Cookies), dans les certificats
digitaux (ClientCertificate) et dans les en-têtes de la requête HTTP ainsi que ceux générés par le serveur sur
la requête ou soi-même (ServerVariables).
L’objet Response représente la réponse http et plus précisément le flux de sortie représentant la page en
cours de construction qui en sera le corps. Il permet à un script ASP de générer la page Web en cours de
construction en permettant au script d’écrire dans ce flux de sortie avec sa méthode Write. D’autres
méthodes du même objet permettent de mieux gérer la façon dont la page est restituée au client, permettant
d’envoyer la page par tranches, effacer ce qui a été écrit dans le flux de sortie, terminer l’exécution du script,
spécifier jusqu’à quand la page doit être gardée dans la mémoire tampon du navigateur (ou si elle ne doit pas
l’être), indiquer au navigateur qu’il doit demander une autre page (redirection) et envoyer des cookies à la
machine cliente.
L’objet Session permet pallier le fait que le protocole HTTP est un protocole sans mémoire d’état, qui traite
chaque requête indépendamment des autres, en gardant trace de l’interaction avec un utilisateur à travers
l’ensemble de ses requêtes. Ceci permet de savoir ce que l’utilisateur a fait dans les requêtes précédentes et
de connaître son comportement et ses intérêts à travers les différents pages qu’il consulte. Le mécanisme
utilisé est celui d’assigner un cookie qui contient un numéro unique pour chaque session à chaque client afin
de permettre son identification dans les interactions successives et accéder aux informations stockés au
niveau de la session. Une session commence au moment de la première page visitée et termine par
terminaison explicite ou au bout d’un certain temps par l’absence d’interaction entre client et serveur (time
out). ASP donne la possibilité d’utiliser des variables de session et d’effectuer des traitements au moment du
démarrage et de la terminaison de la session.
L’objet Application permet de définir une application comme étant un ensemble de pages (à travers la
définition de leur répertoire racine). Il existe une seule instance de l’objet pour chaque application. Les
utilisateurs qui accèdent aux pages de l’application partagent le même objet (en fait ils reçoivent une
référence au même objet) et les changements effectués par les uns affectent les autres. Cet objet permet de
stocker des variables de niveau application et spécifier les traitements à effectuer lorsqu’un client accède ou
quitte l’application.
L’objet Server représente le serveur lui-même et fournit un ensemble de fonctionnalités diverses, telles que la
possibilité d’effectuer la codification de chaînes de caractères pour les rendre compatibles au Web, de
- 58 -
demander l’exécution d’un autres script et la possibilité de créer des instances de composants Active X (dont
on reviendra par la suite).
L’objet ASPError (introduit dans la troisième version du langage) permet de traiter les erreurs qui sont
détectés au moment de l’exécution des scripts ASP. Il existe un certain nombre de débogueurs en commerce,
par exemple le Microsoft Script Debugger, qui permettent de détecter les erreurs avant l’exécution des scripts
et des pratiques de programmation qui devraient en empêcher l’écriture. Toutefois des erreurs peuvent
toujours apparaître au moment de l’exécution des scripts. L’objet ASPError permet d’en garder trace avec
toute une série d’informations, tels un numéro de code, une description et l’emplacement précis de son
apparition et d’établir le message d’information qu’il faut afficher à l’utilisateur.
Enfin, l’objet ObjectContext, qui n’est pas représenté dans la figure, est utilisé pour implémenter les
transactions (des groupes d’actions qui jouissent des garanties d’atomicité, consistance, isolation et
durabilité, qui garantit que soit la totalité du travail est mémé à bien, soit la situation est rétablie comme si la
transaction n’aurait pas eu lieu).
En plus de ces objets qui fournissent les fonctionnalités de base de ASP, il est aussi possible d’employer les
fonctionnalités et les objets prêts à l’emploi qui appartiennent au langage de script utilisé et qui y sont
fournis avec. Parmi ces objets, au moins dans le cas de VBScript, on trouve des objets permettant l’accès au
système de fichiers de la machine, les expressions régulières qui donnent la possibilité de faire des
recherches et remplacements dans une chaîne de caractères, la possibilité d’inclure le contenu d’un fichier
dans un script (le fichier peut par exemple contenir un groupe de fonctions utiles dans différentes pages) et
un dictionnaire qui donne un moyen efficace d’enregistrer et indexer ses données à l’intérieur du script.
En plus de tout cela, il existe la possibilité d’utiliser des composants ActiveX, des portion de code
indépendantes qui fournissent certaines fonctionnalités ou informations et qui peut collaborer avec d’autres
composants grâce à la technologie COM (Component Object Model) de Microsoft. Dans des termes plus
concrets, un composant peut être vu comme un groupe d’objet qui offre des méthodes, propriétés et évents
permettant de répondre à un besoin particulier et pouvant s’intégrer avec d’autres pour former une
application, un peu comme les briques LEGO. Les composants constituent un moyen de conception et
développement d’une application basé sur la division des fonctionnalités en ensembles homogènes plus
petits, plus faciles à développer et maintenir et qui facilitent la réutilisation du code.
Un certain nombre de composants sont fournis par Microsoft dans la distribution d’ASP. Ceux-ci ont été
développés par Microsoft afin de couvrir des fonctionnalités communes à une grande partie de sites et
augmenter la productivité des développeurs ASP par la réutilisation du code prêt à l’emploi .Parmi les
fonctionnalités couvertes par ces composants on trouve la gestion de l’affichage des bannières publicitaire, la
création d’itinéraires à l’intérieur du site, la génération de tables de matières et la possibilité de connaître les
fonctionnalités supportées par les différentes versions des différents navigateurs. D’autres composants
peuvent être obtenus par des tierces parties12 et il est également possible de développer ses propres
composants
Grâce à la technologie COM, il est possible de créer des composants avec différents langages et de les faire
coopérer ensemble, pour autant qu’ils soient compatibles COM. En particulier il est fréquent de rencontrer
des composants développés avec des langages tels que C++, Java et Visual Basic. Ces composants sont
compilés avant d’être employés, ce qui comporte l’avantage d’une plus grande rapidité d’exécution et de la
confidentialité du code source. Il est également possible de créer des composants interprétés en utilisant un
langage de script, tels que VBScript et JavaScript.
La connectivité des Active Server Pages aux autres systèmes est assurée par le support de la stratégie de
Microsoft visant à développer des technologies d’accès universel aux différentes sources de données. Cette
stratégie prend le nom de UDA (Universal Data Access) et les efforts effectués dans le cadre de cette
12
Pour avoir une idée du nombre de composants sur le marché il est possible de consulter des sites spécialisés tels
www.componentsource.com et www.serverobjects.com.
- 59 -
stratégie ont porté au développement de différentes technologies tels OBDC (Open DataBase Connectivity),
Ole-DB et ADO (ActiveX Data Objects).
OBDC a été conçu comme un standard d’accès aux bases de données supporté par les principales bases de
données, qui permet d’accéder aux services d’une quelconque base de données sans avoir à se soucier de
quel type de base il s’agit ni de comment elle fonctionne. C’est une interface standardisée permettant un
accès aux différentes bases de données de façon uniforme, une couche intermédiaire entre le programme et la
base de données qui traduit les requêtes du premier en commandes propres au formalisme employé par la
deuxième et retournant les données en retour au premier. Cette couche à l’avantage de faciliter la
maintenance et la portabilité des programmes –en effet il est possible de changer la base de données utilisée
en modifiant seulement les quelques lignes définissant la connexion OBDC– et de faciliter l’apprentissage
des développeurs en rendant uniformes les commandes d’accès à la base. Par contre il est possible que la
puissance et la performance soient moindres par rapport à l’utilisation des API natives fournies par les
différentes bases de données, à cause du travail supplémentaire de traduction et de l’impossibiliét d’exploiter
des services particuliers à certaines bases de données.
Tandis que OBDC est une interface qui ne supporte que les bases de données, OLE-DB permet un accès
uniforme à un ensemble plus large de systèmes tels que des bases de données, des tableurs, des archives d’email etc. Ce système se charge de dialoguer avec l’application d’une part et les différents systèmes
d’archivage de données de l’autre, grâce à des programmes propres aux différents systèmes qui traduisent les
requêtes dans un formalisme propre au système pour lequel ils ont été écrits et rendent le résultat à OLE-DB.
Ces programmes existent pour un grand nombre de systèmes, dont Excel, Lotus et les principales bases de
données.
L’interface spécifiée par OLE-DB est une interface de trop bas niveau pour être utilisable par des langages
peu puissants comme les langages de script. C’est pour cette raison qu’une couche intermédiaire est rajoutée
entre l’application et OLE-DB: il s’agit de la couche ADO (ActiveX Data Objects), qui est un modèle de
plus haut niveau, basé sur des objets représentant les connections (Connection), les requêtes (Command) et
les différents résultats (Recordset, Record, Stream). Les objets ADO peuvent être utilisés aussi bien dans les
pages ASP que dans les composants.
Enfin la technologie COM+, qui peut être utilisée en plus des autres technologies qu’on vient de voir,
permet, entre autre, de prendre en charge les transactions, avec tous les problèmes liés à l’inversion d’actions
déjà effectués et la reprise en cas de panne du système. Les transactions sont un groupe d’actions liées qui
possède un certain nombre de propriétés connues comme propriété ACID: elles sont Atomiques (elles sont
soit exécutés dans leurs totalité ou pas du tout), Consistantes (qui garantie que l’état du système entre deux
transaction est toujours valide), Isolées (les transactions n’interfèrent jamais les unes avec les autres) et
Durables (les changements effectués par une transaction sont permanents). En plus d’effectuer les tâches
d’un manager de transaction, COM+ peut aussi accomplir des tâches de gestion de composants, de gestion de
la sécurité et fournir d’autres services.
6.2.3.3 Productivité: bibliothèque d’API, réutilisabilité du code et logiciels de développement
ASP est une solution qui permet aux développeurs de devenir rapidement productifs. En effet les langages de
script utilisés sont assez simples à apprendre et permettent un développement rapide grâce au faible typage et
la syntaxe allégée, le modèle d’objets est assez intuitif et simple à utiliser, il existe un certain nombre de
composants disponibles sur le marché et il est possible d’utiliser des composants ActiveX. Dans cette section
restent valables les considérations faites dans les section réservées respectivement aux langages de script coté
client et aux ActiveX.
La bibliothèque de programmation fournie avec ASP permet d’atteindre des bons niveaux de productivité.
D’une part les principales fonctions spécifiques au Web sont fournies par le modèle d’objet, d’autre part il y
a une série de composants livrés par Microsoft en standard avec la distribution d’ASP ou disponibles auprès
de tierces parties qui fournissent un certain nombre de fonctionnalités courantes dans la programmation d’un
- 60 -
site Web. Le programmeur qui utilise ces possibilités peut donc passer plus de temps en programmant sa
logique applicative à un niveau d’abstraction plus élevé sans se soucier des détails d’implémentation des
composants utilisés.
En plus ASP est parfaitement intégrables avec les autres technologies Microsoft, qui peuvent être utilisés
pour augmenter la vitesse de développement; il suffit de penser à des technologies tels que ADO, OBDC et
les composants ActiveX/COM. Il existe de nombreux composants qui sont disponibles sur le marché qui
dispensent les développeurs de réécrire les mêmes choses que d’autres ont déjà fait et qui leur permettent de
se concentrer sur la logique propre à son application.
ASP permet également une bonne réutilisation du code écrit en donnant la possibilité de programmer des
composants facilement réutilisables et donnant la possibilité d’inclure des fonctions très utilisées dans de
fichiers qui sont ensuite inclus dans les pages qui en ont besoin.
Les outils de développement sont aussi nombreux. Il faut surtout citer la série « Visual » développée par
Microsoft, qui fournit des fonctionnalités permettant de diminuer le temps et l’effort de développement, par
exemple la création de squelettes de pages, l’aide syntaxique en cours d’écriture du code, la coloration
syntaxique et le déboguage. Parmi ces produits on peut recenser Visual Interdev, Microsoft Developer
Studio, Visual C++, Visual J++ et Visual Basic.
6.2.3.4 Performance et scalabilité
ASP est une technologie performante, au moins dans un environnement IIS/Windows malgré le fait que les
scripts qui composent ses pages doivent être interprétés au moment de leur exécution. En réalité le moteur
d’interprétation ASP est bien intégré avec le serveur Microsoft IIS, ce qui lui permet de traiter les pages avec
un minimum de travail. L’idée est la même que pour le module PHP intégré à Apache, où un certain nombre
d’instances du moteur d’interprétation sont exécuté en permanence dans la mémoire du serveur et auxquels
sont distribuées les requêtes reçues par le serveur en fonction de leur disponibilité.
En effet ASP résulte avec PHP parmi les solutions les plus performantes pour gérer des applications Web de
petite envergure, selon les résultats de deux tests effectués par e-Week et phpKitchen qui utilisent des.
ASP est une technologie qui permet une certaine scalabilité. En plus des solutions hardware de répartition du
trafic, où un serveur spécialisé dans la répartition du trafic est mis en amont des serveurs Web, pour lesquels
la présence de ce serveur est complètement transparente, il existe des produits logiciels comme « Microsoft
Application Center » qui permettent une répartition du trafic sur un ensemble de serveurs Web classiques qui
travaillent ensemble formant ce qu’on appelle un « cluster » et qui permettent de répartir le trafic sur
plusieurs serveurs, de gérer les pannes et de garantir une plus grandes disponibilité. Ce dernier type de
solution a l’avantage de coûter moins cher et d’avoir une relation coût-volume presque linéaire.
En plus il est possible d’utiliser directement des serveurs d’application conçus directement pour travailler
avec la technologie ASP (comme dans le cas de WebApp Server Product Suite et Chili!Soft ASP) ou utiliser
des serveurs d’application « Java » en passant par des couches d’abstraction.
6.2.3.5 Portabilité
ASP est essentiellement un produit lié aux technologies Microsoft. En particulier ASP s’intègre parfaitement
avec le serveur Microsoft IIS et le système d’exploitation Windows NT et utilise de nombreuses autres
technologies développées par Microsoft tels que VBScript, ActiveX, ADO, COM,…
Grâce à des produits développés par d’autres entreprises. En particulier, grâce à Chili!Soft, ASP peut tourner
sur les serveurs Netscape, Apache et Lotus Web et grâce à Instant ASP, un serveur incluant un moteur ASP
écrit entièrement en Java, ASP peut tourner sur toutes les plate-formes. Il faut cependant mitiger la
portabilité qu’on peut avoir même en utilisant ces produits, car dès qu’on utilise des bibliothèques
spécifiques à l’environnement Windows, les programmes ne fonctionneront plus sur les autres plate-formes.
- 61 -
Un autre aspect qu’il faut mentionner dans cette section est le fait que grâce à des technologies polyvalentes
d’accès aux systèmes de stockage de données tels ADO et OBDC, il est facile de changer la base de données
ou le système de stockage de données utilisé par une application ASP. En fait, il suffit de changer les
quelques lignes responsables de la connexion au système de données.
6.2.3.6 Securité
Comme les autres solutions coté serveur, le code est exécuté coté serveur et au client n’est envoyé que le
résultat de son exécution des scripts. Par conséquent les utilisateurs ne peuvent pas voir le code source. Le
fait que les scripts soient stockés sur le serveur sous forme de code source peut cependant poser le risque
qu’un utilisateur malintentionné réussisse à télécharger le fichier sans passer par son exécution préalable.
ASP permet cependant d’utiliser des composants ActiveX compilés, ce élimine ce risque en protégeant le
code source.
ASP permet de bien gérer les erreurs, ce qui rafforce la sécurité du site, empêchant aux éventuels attaquants
de trouver des indices sur le fonctionnement du site. En effet les erreurs peuvent être gérés à travers l’objet
ASPError et à des pages contenant des consignes sur quoi afficher en cas d’erreur.
6.2.3.7 Séparation entre contenu, logique de traitement et présentation
L’architecture minimale dans laquelle ASP peut fonctionner est une architecture client-serveur simple, Dans
ce cas, le client (le navigateur) émet des requêtes et en visualise le résultat; le serveur intégrant le moteur
ASP s’occupe du contenu, de la logique de traitement de la logique de présentation. Une séparation de ces
trois domaines peut être obtenue grâce à la possibilité d’inclusion du contenu d’un fichier dans le script au
moment de l’exécution. Les fichiers inclus peuvent contenir séparément des briques de présentation, du
contenu et de la logique de traitement, ce qui favorise aussi la réutilisation du code écrit et la cohérence
globale du site.
La possibilité d’utilisation de composants permet d’obtenir une séparation plus efficace, en utilisant les
composants pour séparer surtout la partie liée à la logique de traitement et à l’accès aux donnes de la logique
de présentation qui reste confiée aux scripts ASP interprétés par le serveur.
On peut étendre cette architecture en insérant une base de données, ce qui nous donnerait une architecture
trois tiers. Cette dernière est chargée de stocker le contenu d’une façon structurée qui en permet un accès
rapide et facile. La séparation entre les trois couches peut donc être faite de la façon suivante: les scripts ASP
contiennent la logique de présentation, les composants ActiveX effectuent la logique de traitement et l’accès
aux données et la base de données contient les données (le contenu).
Il est également possible d’insérer entre la base de données et le serveur une couche intermédiaire
(architecture multi-tiers), par exemple des serveurs d’application. Il existe en effet des serveurs d’application
conçus expressément pour ASP et il est possible d’employer des serveurs compatibles Java en utilisant la
possibilité d’utiliser les composants ActiveX pour y accéder.
6.2.3.8 Conclusions
Avantages
L’avantage principal de ASP est son intégration avec les autres technologies Microsoft, ce qui le rend
particulièrement bien adapté à l’utilisation dans un environnement IntraNet basée sur des systèmes
Microsoft. Ceci permet non seulement d’avoir une solution très complète et puissante lorsqu’on reste dans
l’environnement Windows, mais aussi de pouvoir réutiliser les bibliothèques Windows et les éventuels
composants déjà écrits. Par ailleurs le support de Microsoft à cette technologie fait en sorte qu’il y ait un bon
nombre de développeurs et de sociétés tierces auprès desquels il est possible d’acheter des composants déjà
prêts à l’emploi.
- 62 -
ASP est une solution qui permet une certaine rapidité et productivité dans le développement d’applications
Web. En particulier les bases de cette solution sont relativement faciles à apprendre: le modèle d’objets ASP
constitue un cadre structuré et intuitif de développement de pages et l’apprentissage d’un langage de script,
en particulier VBScript, ne comporte pas de difficultés majeures. La productivité du développeur peut être
améliorée en utilisant les bons logiciels de développement disponibles et en exploitant les autres
technologies compatibles avec ASP, notamment les ADO qui fournissent un accès homogène et facile aux
sources de données et les composants ActiveX/COM qui permettent le développement de composants
facilement réutilisables.
L’installation dans l’environnement Windows est assez simple: il suffit d’installer le bon serveur selon la
version de Windows utilisée. L’installation sur d’autres systèmes comporte cependant plus de problèmes et il
faut passer par des logiciels fournis par des tierces parties.
Les performances sont aussi étonnantes. En effet le moteur ASP est rapide et permet de servir un nombre
élevé de pages par seconde. En plus ASP est une solution scalaire, qui permet d’étendre facilement le
nombre de machines sur lesquelles tourne le site (grâce au « Microsoft Application Center »).
Inconvénients
L’inconvénient majeur lié à ASP est son étroite appartenance au monde Microsoft. La portabilité des ASP
risque bien d’être un problème, qui est mitigé par le fait qu’il existe des solutions permettant d’installer un
serveur ASP sur n’importe quelle plate-forme (Instant ASP) ou qui permettent de coupler le moteur
d’interprétation ASP avec d’autres serveurs tels Apache, Netscape Fasttrack et Lotus (Chili! ASP).
Lorsqu’on utilise des plate-formes autres que Windows, il faut faire attention à ne pas employer des libraires
qui sont spécifiques à cet environnement, par exemple la vaste libraire de contrôles ActiveX, ce qui réduit
fortement la disponibilité de composants déjà prêts à l’emploi.
Cas d’utilisation souhaité
ASP est une technologie très intéressante lorsque l’on veut intégrer des technologies Microsoft, tels que les
produits de bureautique, la technologie d’accès aux données ADO et des composants COM. Bien qu’il existe
des produits permettant d’utiliser les ASP sur des plate-formes différentes de IIS/Windows, c’est sur cette
plate-forme que ASP peut donner le mieux de soin en pouvant notamment utiliser la large gamme de
composants ActiveX développées pour ce système d’exploitation.
A coté de l’avantage de pouvoir très bien s’intégrer avec les autres technologies Microsoft, ASP constitue
une solution très complète et performante en matière de génération de pages dynamiques mais qui n’est pas
nettement supérieures aux autres alternatives sur les autres dimensions.
6.2.4 JSP (Java Server Pages) et Servlets Java
6.2.4.1 Présentation
Les JSP sont un standard développé par Sun Microsystems, permettant de développer des pages dynamiques
en utilisant Java comme langage de programmation. Ce standard vient s’ajouter à un autre moyen développé
en précédente par la même entreprise et ayant la même, les Servlets. Ces derniers se différencient des JSP par
le fait qu’ils sont des véritables programmes Java qui ont pour fonction de générer la page Web à transmettre
au client dans leur flux de sortie.
Ces deux moyens appartiennent à la même technologie. En effet les JSP sont une couche supplémentaire
venant se greffer sur le modèle des Servlets et peuvent être vus comme une façon plus amicale d’écrire des
Servlets Java, permettant d’insérer les bouts de code Java à l’intérieur d’une page HTML à la place de devoir
écrire tout le HTML en passant par les méthodes d’écriture dans le flux de sortie.
En effet JSP est un standard qui donne la possibilité d’étendre les possibilités du langage HTML en
permettant d’insérer des instructions JSP à l’intérieur des pages Web. Les instructions JSP sont insérées dans
- 63 -
une page Web à l’aide de balises spéciales définies dans la spécification JSP. Il existe différents types
d’instructions JSP et chacun d’entre eux est inséré avec son propre type de balise. Il existe d’ailleurs deux
versions des balises: une version style XML et une version style ASP. Dans le processus qui porte de la page
JSP à la création de la page Web envoyée au client, la page JSP est interprétée du haut en bas en exécutant
les instructions JSP et copiant le code HTML rencontré en dehors des blocs JSP directement dans la page
sans aucune modification. En réalité le processus de transformation de la page JSP en page Web est un peu
plus compliqué et sera détaillé par la suite.
Un survol des types d’instruction et de la syntaxe de leur balise peut être trouvé dans « Introduction to JSP
technology » [xxx] ou dans d’autres tutoriaux en ligne.
On peut diviser les instructions JSP en trois ensembles: les instructions de programmation, les directives et
les actions. Les premières permettent au programmeur d’insérer des bouts de code Java directement dans la
page Web, ce qui donne accès à la considérable libraire de programmation de la version standard du même
langage, aux technologies (on peut penser aux composnats JavaBeans, de l’accès aux bases de données
JBDC etc.)qui y sont liés et à un certain nombre d’objets prédéfinis qui facilitent l’écriture dans des
domaines liés au Web. Ces objets sont similaires aux objets disponibles dans ASP et comprennent les objets
request, response, session, application, config, page et pageContext. Les deuxièmes qui permettent de
spécifier certaines propriétés de la page, l’inclusion du contenu d’autres fichiers et l’utilisation d’autres
classes et libraires de balises personnalisées. Les troisièmes permettent essentiellement d’utiliser des
composants JavaBeans existants.
Lorsque le serveur Web reçoit pour la première fois une requête portant sur une page JSP, il passe l’ordre
d’exécution de la requête au moteur JSP. Celui-ci interprète d’abord les instructions contenues dans la page
en la traduisant sous forme de code source du Servlet correspondante et compile ensuite le Servlet générée à
travers un compilateur Java pour créer un fichier exécutable sur une machine virtuelle Java. Ensuite le
Servlet est exécuté et la page générée par le programme dans le flux de sortie est renvoyée au serveur pour
qu’elle puisse être retournée au client qui en a fait la requête.
Le fonctionnement pour les requêtes successives est plus simple. Lorsque le serveur reçoit une requête
portant sur une page JSP dont il existe déjà un Servlet correspondant, il effectue un contrôle de version. Si le
code source de la page JSP n’a pas été modifié après la compilation du Servlet, le Servlet est directement
exécuté et la page qu’il produit est renvoyée au client; si par contre la page JSP a été modifiée, il faut
d’abord remplacer le Servlet en mémoire en traduisant et compilant la page JSP à nouveau avant d’exécuter
la nouvelle version du Servlet.
Cette façon de fonctionner peut sembler un travail lourd et peu performant. Ceci n’est pas vrai dans la
mesure où l’étape de traduction et compilation de la page JSP en Servlet n’est effectuée généralement que
lorsque la page JSP est demandée pour la première fois, ce qui peut être fait au cours de la procédure de
démarrage du serveur. Ce n’est que dans le cas où le code source de la page JSP a été modifié depuis la
dernière compilation du Servlet que l’étape de traduction se déroule à nouveau, ce qui est rare une fois que le
site a été finalisé. En plus les serveurs peuvent stocker dans leur mémoire tampon un certain nombre de
Servlets, ce qui permet de réduire ultérieurement le temps de réponse aux requêtes. Cette façon de procéder
comporte un ultérieur avantage en permettant un déploiement rapide des modifications et une maintenance
facilitée, car les modifications du code source sont automatiquement reflétées dans les pages Web produites.
6.2.4.2 Fonctionnalités
Les JSP sont des pages Web étendues grâce aux possibilités offertes par le langage Java, qui sont traduites
par un moteur JSP en Servlets, qui sont des véritables programmes Java qui génèrent dans leur flux de sortie
la page Web à envoyer au client.
Ceci leur confère des possibilités remarquables, pouvant profiter des atouts offerts par le langage employé.
En particulier Java est un langage polyvalent, portable, fortement typé, orienté objet, fourni avec une
bibliothèque de programmation standard considérable et une excellente documentation.
- 64 -
La bibliothèque de classes qui est associée à la deuxième version langage et qui est entièrement exploitable à
partir de ces deux technologies, comprend un grand nombre de classes déjà programmées permettant au
programmeur d’utiliser un certain nombre de classes avec des propriétés et méthodes déjà programmés. Ces
classes couvrent un vaste nombre de fonctionnalités, comportant l’accès aux bases de données à travers une
interface standardisée JDBC, la possibilité de travailler avec des serveurs d’applications et de s’insérer dans
le cadre d’une architecture J2EE, le support de la programmation distribuée avec les RMI et le support
CORBA, la programmation des composants logiciels réutilisables (JavaBeans), l’exploitation de capacités
graphiques, la gestion de la programmation concurrente (threads), la manipulation des chaînes de caractères,
les fonctions mathématiques,…
Grâce à l’apport du langage Java, ces technologies peuvent être employées pour pratiquement tout faire et
constituent de loin la solution coté serveur la plus puissante, disposant de la bibliothèque de programmation
la plus complète. Le revers de la médaille est constitué par le fait que Java est un langage plus difficile à
apprendre et à maîtriser, impliquant une courbe d’apprentissage bien plus raide par rapport aux langages de
script utilisés dans les autres solutions.
Etant donné la difficulté de programmation des Servlets et, en moindre mesure, des pages JSP, leur
développement est une prérogative de programmeurs plutôt expérimentés. Il est fort probable que leur
utilisation reste plutôt orientée dans le cadre de projets de grande taille ou d’importance stratégique, surtout
dans le cadre de grandes sociétés. Bien que ces technologies puissent être utilisées pour créer des sites tout
simples, c’est dans le cadre de projet plus importants qu’elles peuvent être le mieux exploitées. En particulier
elles peuvent s’intégrer comme couche de présentation dans une architecture multi-tiers grâce à l’abondante
connectivité avec les différents serveurs d’application et systèmes d’information. Ceci permet de séparer
logique de traitement et logique de présentation, facilitant la maintenance, permettant de réutiliser des
composants logiciels et permettant d’atteindre des niveaux excellents en termes de fiabilité, indépendance
par rapport à des sociétés tierces et scalabilité.
Il existe toutefois une possibilité très intéressante de démocratisation de ces technologies en passant par
l’utilisation des libraires de balises personnalisés. Ces balises permettent à des développeurs Web d’insérer
des fonctionnalités programmés dans leur page en utilisant des simples balises, sans ne devoir rien connaître
en programmation. Le développement des balises est toutefois toujours confié à des programmeurs.
6.2.4.3 Productivité: bibliothèque d’API, réutilisabilité du code et logiciels de développement
S’il est vrai que le langage Java est le plus compliqué à apprendre et à utiliser, la productivité du
développement une fois que le langage a été maîtrisé peut être spectaculaire.
En effet Java est un langage notoirement difficile à apprendre, certainement le plus difficile parmi les
solutions présentés dans ce travail. La difficulté d’apprentissage est causée par la syntaxe cryptique, par le
fort typage, l’orientation objet du langage et l’étendue de la libraire de programmation.
Ces éléments sont toutefois les mêmes qui permettent une productivité de développement plus élevée une
fois que le programmeur maîtrise le langage. La syntaxe cryptique et le fort typage rendent le développement
un peu plus fastidieux, mais permettent aussi d’avoir un déboguage plus précis qui évite un certain nombre
d’erreurs dues à une mauvaise frappe dans le nom des variables ou aux erreurs de typage. Ceci permet
surtout dans des gros projets d’épargner du temps de développement.
L’architecture objet du langage permet de décomposer facilement une application en plusieurs classes
d’objets qui prennent en charge des fonctionnalités spécifiques. Ceci permet de diviser la complexité de
l’application dans des sous-ensemble plus petits et plus maîtrisables et faciles à développer, ce qui comporte
également l’avantage de permettre le développement en parallèle par plusieurs développeurs qui peuvent
ensuite intégrer leurs objets pour former l’application et de favoriser la réutilisation du code créé. La
possibilité de créer des objets sous former de composants standardisée (JavaBeans, Enterprise JavaBeans),
permet de rendre plus facile la création d’une application en assemblant les objets nécessaires.
- 65 -
Ces mêmes techniques permettent une réutilisation aisée du code. En effet les mêmes classes, si elle sont
développées de façon assez générique, peuvent être réutilisé au cours de plusieurs projets. Ceci est le but
principal des architectures de composants, qui permettent de créer une application en assemblant les
différents composants qu’elle nécessite.
La technologie JSP permet également une réutilisation du code grâce à la possibilité d’inclure dans une page
Web des fichiers textuels pouvant contenir du code, des classes ou des briques de présentation.
En plus de faciliter la production de code, ces techniques permettent également de faciliter la maintenance et
l’évolution des applications, car pour modifier l’application il ne faut modifier que les composants ou
fichiers concernés, sans devoir tout remettre en question.
Le parc d’outils qu’il est possible d’utiliser avec les JSP et les Servlets est vaste et inclut les traditionnels
éditeur de texte généralistes ou spécialisés (Emacs, UltraEdit, Notepad,…), un certain nombre d’éditeurs
HTML visuels tels que HomeSite et DreamWeaver et des véritables outils de développement Java intégrés
incluant Forte, Jbuilder, Visual J++ et JRun Studio.
6.2.4.4 Performance et scalabilité
La performance des solutions JSP et Servlet dépend largement de l’implémentation des moteurs JSP et
Servlet qui sont utilisés. Dans un test de comparaison des performances réalisé par le magazine e-week, la
version de référence de l’implémentation JSP, Tomcat, a résulté être assez lente. Il faut penser que le travail
supplémentaire de traduction et compilation et de gestion des containeurs de Servlets imposé par le modèle
JSP par rapport à d’autres solutions est trop lourd dans le cas d’une petite application, ce qui résulte en des
pires performances. Il faut cependant noter que des serveurs d’applications tels que Weblogic, JRun et
Dynamo application server peuvent permettre des biens meilleurs performances.
Si la performance est un peu douteuse, la scalabilité de ces solutions est par contre excellente. En effet le
modèle JSP prévoit un certain nombre de possibilités qui permettent de bien gérer l’augmentation du trafic.
D’une part le fait de pouvoir lancer un certain nombre d’instances du moteur de Servlet en fonction du
nombre de requêtes reçues et de synchroniser les accès à certains objets par plusieurs clients différents (ce
qui permet d’en réduire le nombre d’instances) permet de contenir l’augmentation du temps d’exécution et
des ressources employées.
En plus il existe un grand nombre de serveurs d’application qui supportent l’architecture Java pour les
entreprises (J2EE) et qui fournissent tout un ensemble de services tels que la possibilité d’offrir des
containeurs permettant d’abriter des composants Enterprise JavaBeans, la distribution de la charge de travail
sur différents serveurs, l’accès à différentes sources de données et des services de transaction.
6.2.4.5 Portabilité
Grâce à la technologie Java, les pages JSP et les Servlets sont extrêmement portables. En effet il existe la
possibilité de les utiliser sur n’importe quel serveur, dont la liste incluse les serveurs Apache, IIS et
Netscape, et sur n’importe quel système opératif (Windows, Unix, Linux, MacOS,…).
En plus de la compatibilité avec pratiquement tous les serveurs Web, les deux technologies Java sont
compatibles avec un nombre incroyable de serveurs d’application, qui implémentent la spécification J2EE et
qui peuvent être insérés dans une architecture multi-tiers où la présentation est confiée à des JSP, la logique
de traitement à des Servlets ou JavaBeans et les données à une base de données ou système d’information.
Parmi les produits compatibles avec les JSP et les Servlets on peut citer Dynamo Application Server, Bea
Weblogic, JRun, JBoss, Juggernaut Application Server, GemStone, IBM Web Sphere, Uniface, iPortal et
Pramati.
- 66 -
6.2.4.6 Securité
Ces deux technologies Java permettent des développements très surs, pouvant s’appuyer sur un mécanisme
d’authentification et autorisation spécifiable au niveau de la méthode. Il est don possible d’attribuer des
niveaux de sécurité différente pour les différentes méthodes et propriétés.
La possibilité d’encapsuler la logique de traitement et les accès à des sources dans des composants séparés et
stockés sur un serveur d’application permet d’obtenir un niveau de sécurité très élevé pour les parties
sensibles de son application.
6.2.4.7 Séparation entre contenu, logique de traitement et présentation
Les possibilités de séparation entre ces trois domaines de préoccupation sont largement dépendantes de
l’architecture utilisée.
En partant de l’architecture minimale, une architecture client-serveur, les trois domaines sont confondus dans
le serveur. Les technologies JSP/Servlet donnent toutefois des remarquables possibilités de séparation entre
ces domaines même en utilisant cette architecture. En effet il existe un certain nombre de mécanismes qui
permettent la séparation entre ces trois domaines.
Un premier moyen à disposition du programmeur est la possibilité d’inclure dans une page Web des fichiers
textuels pouvant contenir des données (il est possible de spécifier que l’inclusion doit intervenir au moment
de la traduction de la page JSP et Servlet ou au moment de l’exécution de la requête, des classes contenant la
logique de traitement ou des briques de présentation.
Ensuite il est possible d’exploiter les avantages de la programmation orienté objet et en particulier des
technologies de création de composants JavaBeans, qui permettent la programmation de composants
permettent de décomposer facilement une application en plusieurs classes d’objets qui prennent en charge
des fonctionnalités spécifiques. Ceci permet de créer des objets ou composants spécifiques pour les taches
d’accès au données, de logique de traitement et de logique de présentation.
Ensuite il est possible de faire ce qu’on appelle un chaînage de requêtes, où la page JSP qui reçoit la requête
effectue ses traitements et passe la requête à une ou plusieurs autres pages JSP ou Servlets, qui peuvent être
programmés pour effectuer des traitements précis.
Enfin une possibilité remarquable de séparation est l’utilisation des libraires de balises personnalisées. Ceci
permet d’associer des fonctions programmées à des balises similaires aux balises HTML, de sorte que des
graphistes puissent incorporer des fonctionnalités de programmation dans leur pages sans avoir à connaître
un langage de programmation. Les fonctions derrière les balises, eux sont toutefois toujours développées par
des programmeurs. Ceci permet de séparer la couche de présentation de la couche de traitement d’une façon
qui permet non seulement leur inclusion dans des fichiers différents, mais qui peuvent aussi être associés à
des personnes différentes.
Si on passe dans une architecture trois-tiers, avec l’inclusion d’une base de données, il est possible de séparer
les données (le contenu) des deux autres domaines. En particulier la base de données se charge de stocker et
organiser les données, le serveur se charge de l’accès aux données et de la logique de traitement (d’habitude
par l’intermédiaire de composants JavaBeans ou Servlets) et de la logique de présentation (d’habitude à
travers une page JSP).
Un dernier affinage de la séparation entre ces domaines comporte l’utilisation d’un serveur d’application,
utiles pour isoler l’accès aux données (base de données ou système d’informations de l’entreprise) et la
logique de traitement (grâce à des JavaBeans ou Enterprise JavaBeans) et pour les autres services qu’ils
offrent. Les solutions Java se prêtent particulièrement bien à ce type d’architecture, car elles peuvent
s’intégrer avec un grand nombre de serveurs d’application.
- 67 -
6.2.4.8 Conclusions
Avantages
Lorsque Java est sorti, il a suscité beaucoup d’intérêt dans la communauté des informaticiens surtout à cause
de la possibilité de créer des Applets, des programmes qui s’exécutent coté client. Maintenant le même
intérêt est généré par les solutions coté serveur… et il y a des raisons!
Un premier avantage des solutions développées par Sun est l’importante libraire de programmation qui est
livrée avec la plate-forme Java édition standard (J2SE) ou entreprise (J2EE). En plus d’un grand nombre de
fonctionnalités déjà prêtes à l’emploi, la plate-forme Java permet de développer des composants facilement
réutilisables. Ces solutions profitent également des atouts du langage Java et des outils de développement qui
y sont associés. Cela permet aux programmeurs expérimentés d’avoir une bonne productivité de
développement.
Un deuxième grand avantage de ces solutions est leur portabilité. En effet les Servlets et les JSP font partie
de la plate-forme Java édition standard et il peuvent être exécutées sur n’importe quel système disposant
d’une machine virtuelle Java. Actuellement tous les principaux serveurs et toutes les principales plate-formes
permettent de travailler avec ces solutions.
La possibilité d’utiliser des composants, le langage orienté objet, l’intégration avec les serveurs
d’applications et différents systèmes de stockage de données et les libraires de balises personnalisées
permettent une division poussée entre contenu, logique de traitement et présentation. Ceci permet de confier
le développement et la maintenance des différentes parties des applications à des personnes avec différentes
compétences, tels que des développeurs, des experts du métier, des graphistes et des administrateurs de bases
de données.
Enfin la scalabilité et la sécurité offertes par ce type de solution sont bien au dessus de la moyenne. En
particulier la possibilité d’utiliser des serveurs d’applications et des composants permettent de bien distribuer
la charge et de développer une architecture où les données et le code sensibles sont bien protégés.
Inconvénients
Le désavantage principal de ces technologies est celui de nécessiter la connaissance d’un véritable langage
de programmation d’orientation générique comme Java, qui n’a pas été conçu expressément pour pouvoir
être utilisé par un développeur Web, mais pour des véritables programmeurs. En effet ce langage est
caractérisé par une courbe d’apprentissage assez raide et le développement avec ce langage nécessite des
solides bases en programmation. Même l’écriture de pages JSP, qui est bien plus simple que celle des
Servlets, peut nécessiter des solides connaissances de programmation.
Bien que le fort typage et contraintes syntaxiques du langage Java soient utiles dans le cas de projets d’une
certaine ampleur, elles peuvent rendre le développement de petites applications bien plus long par rapport
aux autres alternatives. Il est donc conseillé d’utiliser ce type de solution dans le cadre de gros projets.
Enfin les performances testées de ce langage ont été assez décevantes, ce qui peut s’expliquer par
l’utilisation d’une implémentation non optimisée. Il est possible qu’avec des produits de plus haute qualité
les performances soient aussi bonnes que pour les solutions concurrentes.
Cas d’utilisation souhaité
Les deux solutions présentées dans cette section sont idéales pour le développement de sites d’entreprises de
grande taille, surtout s’il y a la possibilité de réutiliser des composants Java déjà existants et comme solution
de développement pour une société spécialisée dans le développement de sites.
Les premières peuvent profiter de l’énormité des produits pour le développement d’applications basés sur la
plate-forme J2EE et par le fait d’investir dans une solution qui laisse une grande flexibilité quant au choix
des solutions futures (les solutions développées par Sun ne lient pas l’entreprise qui les adopte à une
entreprise particulière). JSP et les servlets permettent de développer des applications selon une architecture
multi-tiers où il est possible d’isoler la logique commerciale dans des composants EJB, l’utilisation de
- 68 -
serveurs d’applications, la présentations dans le serveur et le contenu dans les systèmes d’information de
l’entreprise. Ceci permet de créer des solutions fiables, scalables, sûres, faciles à maintenir et garantissant
une réutilisabilité du code maximale.
Les deuxièmes peuvent profiter de l’architecture objet et des composants pour créer des blocs de code
facilement réutilisables et la possibilité de bien subdiviser le travail de dévleoppement entre développeurs,
designers, experts métier et de bases de données pour augmenter la productivité de ses collaborateurs.
6.2.5 ColdFusion
6.2.5.1 Présentation
ColdFusion est une solution qui permet la création d’applications de pages Web dynamiques dont
l’architecture repose sur plusieurs composants principaux: les pages d’application (qui sont les pages
contenant les instructions pour générer les pages Web), le moteur ColdFusion d’extension au serveur et un
composant d’administration.
Ces composants sont distribués par la société Macromedia sous le nom de ColdFusion Server. Ce produit
existe en deux versions: l’édition « Professional » est vendue à un prix d’environ 2000 francs suisses, la
version « Enterprise », qui fournit en plus des fonctionnalités de regroupement de serveurs et de tolérance
aux pannes est vendue à un prix de 8000 francs. La même société vend aussi un outil de développement
spécifique: ColdFusion Studio, disponible à un prix d’environ 800 francs.
Les pages d’application sont des pages Web contenant des instructions de programmation écrite à l’aide d’un
langage propriétaire, le CFML (ColdFusion Markup Language). Le CFML est un langage simple basé sur
des balises dont la syntaxe est similaire à celles du langage HTML. Les environ 70 balises du langage CFML
permettent d’insérer des fonctionnalités de programmation de haut niveau dans une page Web de façon
simple: ces balises encapsulent des processus de plus bas niveau, parfois complexes, nécessaires à
l’accomplissement de leur tache et ils en cachent toute la complexité à l’utilisateur. L’idée de donner la
possibilité de programmer à l’aide des balises, similaire à celle des libraires de balises personnalisées dans
JSP, a été conçue pour que le développement de pages dynamiques soit intuitif et simple à apprendre, même
pour des développeurs de pages Web normales.
En plus de ses propres balises prédéfinies, ColdFusion permet de développer ses propres balises
personnalisées, ses propres extensions (programmées en C++ selon l’API d’extension ColdFusion) d’utiliser
plus de 200 fonctions prédéfinies fournissant un ensemble de fonctionnalités diverses (fonctions
mathématiques, de manipulation de tableaux, listes, chaînes de caractères,…) et d’utiliser une version allégée
du même langage, le CFScript, offrant des fonctionnalités comparables aux autres langages de script
présentés dans ce travail.
Le moteur d’interprétation ColdFusion est un module d’extension de serveur Web et qui est invoqué par le
serveur Web au moment d’une requête d’un client portant sur une page ColdFusion, reconnaissable par
l’extension *.cfm, interprète les instructions contenues dans les pages d’application ColdFusion et retourne
au serveur la page Web à renvoyer au client. Le moteur ColdFusion qui peut s’intégrer avec les principaux
serveurs disponibles et supporte les principales bases de données.
Les sources de données qu’il est possible d’exploiter avec ColdFusion sont nombreuses et ne se limitent pas
aux bases de données. En plus des principales bases de données13, utilisables en utilisant leur interface API
native ou en utilisant un pilote OBDC, il est possible d’utiliser des fichiers textuels délimités, des fichiers
Excel, des serveurs de messagerie et des objets COM, CORBA et Java.
13
Parmi les bases de données exploitables avec ColdFusion on peut compter les bases de données OBDC et l’accès natif aux
serveurs SQL Microsoft, dBase, Paradox, Informix, Progress, Oracl et, Sybase
- 69 -
Le composant d’administration est utilisé pour configurer les diverses options de la plate-forme ColdFusion
et accomplir diverses fonctions de gestion. Ce composant permet en particulier de surveiller l’évolution de la
performance et d’intervenir le cas échéant: il permet de modifier les paramètres du moteur ColdFusion,
planifier l’exécution des pages, leur compilation et stockage dans les mémoires tampon, gérer le groupage
(cluster) des serveurs, l’équilibrage de charge, le recouvrement en cas d’erreurs et les basculements de
secours. Cet outil d’administration intègre aussi des outils de gestion de la sécurité de l’application,
permettant notamment d’implémenter un modèle de sécurité qui permet de restreindre l’accès aux différentes
ressources et de chiffrer le code source des pages, des outils de gestion des erreurs à travers un débogueur et
la consignation des erreurs dans des journaux, d’outils de gestion des sources de données etc.
6.2.5.2 Fonctionnalités
ColdFusion est une solution expressément développée pour la génération de sites dynamiques. Ses environ
70 balises, ses 200 fonctions et des facilités mises à disposition par le moteur ColdFusion permettent de
programmer la plupart des fonctionnalités dont un développeur d’applications Web interactives peut avoir
besoin. On peut diviser les fonctionnalités mises à disposition en plusieurs catégories.
Un premier groupe de fonctionnalités est lié à un certain nombre d’instructions de base de programmation. Il
existe un certain nombre de balises permettent de déclarer des variables, de leur affecter des valeurs,
d’utiliser des tableaux et des structures associatives, de lire ou écrire des fichiers, de modifier le flux
d’exécution du programme en utilisant des instructions conditionnelles, des répétitions, de sauts dans le flux
d’exécution et de gestion des erreurs d’exception. CFML intègre une bibliothèque de fonctions diverses
permettant de manipuler différentes structures de données, des chaînes de caractères et des expressions
régulières, des fonctions mathématiques,…CFML n’est pas un langage fortement typé et permet de déclarer
ses variables de façon implicite en leur assignant une valeur et c’est le moteur d’interprétation qui se charge
de la représentation interne de la variable en fonction du type de données contenues à un certain moment.
Etant développé expressément pour le Web, ColdFusion implémente un grand nombre de fonctionnalités
spécifiques liées à cet environnement et qui permettent de faciliter l’écriture de pages Web. Par exemple, le
moteur ColdFusion se charge automatiquement de la récupération de tous les données transmises par le client
dans sa requête, incluant les formulaires et les données passées dans l’URL, et de leur transformation en
variables. D’autres fonctionnalités aident dans l’écriture des pages, permettant la substitution automatique du
nom de variables dans le flux de sortie par leur contenu, l’écriture facilité de formulaires HTML avec des
options de validation de données et d’insertion d’Applets Java déjà programmés permettent par exemple de
mieux contrôler leur aspect graphique et d’en étendre les possibilités. Il existe aussi un certain nombre de
fonctionnalités spécifiques tels que l’authentification de l’utilisateur, la lecture et écriture de cookies, le
support d’un certain nombre de protocoles Internet de transfert de fichier et de messagerie etc.
Afin de pallier les limitations du protocole HTTP, qui est sans état, ColdFusion permet d’utiliser des
variables qui persistent au delà d’une requête, ce qui est leur longévité par défaut. En particulier il donne la
possibilité de définir des variables de niveau session, propres à un client et une session, des variables de
niveau client, qui persistent sur plusieurs sessions, des variables de niveau application (une application est
définie comme un ensemble de pages liées), partagés entre les clients de l’application, et les variables de
niveau serveur, partagés entre toutes les applications.
Enfin la solution développée par Macromedia dispose d’un certain nombre de possibilités de se connecter à
d’autres systèmes. ColdFusion dispose de sa propre libraire de fonctions pour communiquer avec des bases
de données et supporte le standard OBDC. En plus il peut utiliser d’autres sources de données tels que des
archives de messagerie, des tableurs et des fichiers formatés. En plus de la possibilités de demander aux
bases d’exécuter des requêtes SQL et exploiter les autres services qu’elles offrent, des possibilités
intéressantes permettent d’exécuter des requêtes sur des résultats de requêtes précédentes sans devoir passer
à nouveau par les bases de données et de bénéficier des avantages d’un regroupement de connexions
persistantes.
- 70 -
La connectivité avec d’autres systèmes comprend le support des architectures COM, CORBA et JAVA, avec
notamment la possibilité de réutiliser des composants écrits selon les spécifications de ces architectures et
d’utiliser des produits tels de serveur d’applications pour emmagasiner la logique commerciale de
l’entreprise.
Il existe aussi un certain nombre d’outils fournis avec ColdFusion, tels que un outil pour la génération de
rapports (Crystal Reports) et un moteur de recherche (Verity) permet d’effectuer des recherches et
indexations de texte intégral. Ce moteur permet d’insérer facilement un moteur de recherche dans son site
afin de gérer une documentation, faire des recherches dans son site ou dans des archives de fichiers dans
plusieurs format, parmi lesquels on trouve les format texte, les fichiers des applications Microsoft Office,
Lotus et les fichiers PDF.
Il est possible d’étendre la libraire de programmation de ColdFusion et les fonctionnalités fournies par son
langage CFML en utilisant des balises personnalisés développées pour l’interface de programmation
d’applications de ColdFusion (CFXAPI). Ces balises peuvent être développés en C++, Java ou Delphi et
trouvent leur utilité dans la programmation de tâches qui ne sont pas réalisables en langage CFML ou pour
améliorer les performances de certaines tâches récurrentes.
Il existe d’ailleurs un certain nombre de balises déjà programmées qui sont disponibles gratuitement ou
soumises à une utilisation contre licence sur des sites d’échange sur le réseau.
6.2.5.3 Productivité de développement: réutilisabilité de code et logiciels de développement
La plate-forme ColdFusion a été conçue dans l’esprit d’un outil RAD de développement rapide
d’applications. En effet le langage de marquage CFML utilisé pour créer les pages ColdFusion est un
langage qui a été développé avec une syntaxe similaire au langage HTML pour faciliter l’apprentissage
rapide de la part de développeurs Web et les rendre rapidement productifs. En plus le langage est un langage
de haut niveau d’abstraction, qui prend en charge des procédures compliquées en cachant les détails
d’implémentation aux programmeurs. Ceci permet une écriture très compacte du code et laisse le
développeurs se concentrer sur les tâches à programmer plutôt que les détails de leur programmation.
L’esprit RAD du produit est aussi mis en évidence par l’existence d’outils supportant le développement en
équipe.
ColdFusion prévoit aussi quelques possibilités de réutilisation de code. Essentiellement il permet d’utiliser
deux mécanismes principaux: l’inclusion de fichiers à l’intérieur d’autres fichiers, ce qui permet d’isoler des
bouts de code ou des briques de présentation et d’en faciliter la maintenance, et l’utilisation de balises
personnalisées à la syntaxe similaire aux balises HTML, qui sont en fait des véritables programmes écrits en
C++, Java ou Delphi qui encapsulent un certain nombre de traitements, peuvent reçevoir des paramètres et
retourner des valeurs en retour. Il existe un certain nombre de balises déjà programmées disponibles sur le
réseau à travers des sites d’échanges qu’il est possible d’employer pour rendre le développement plus rapide.
En plus des possibilités offertes par ColdFusion, l’utilisation de composants issus des architectures COM,
CORBA et JAVA permet d’étendre considérablement les possibilités de réutilisation de code et la rapidité de
développement en permettant de capitaliser sur les développements et systèmes existants.
Parmi les outils de développement dédiés à ColdFusion Studio, un excellent outils de développement offrant
des nombreuses fonctions utiles au développement, incluant un débogueur interactif, l’aide syntaxique en
cours de programmation, la gestion de projets et de la documentation ainsi que des nombreuses facilités
d’écriture du code. Il existe aussi une version ColdFusion Ultradev Studio qui intègre l’éditeur visuel
Dreamweaver à l’outil de développement susmentionné.
6.2.5.4 Performance et scalabilité
Le moteur d’interprétation ColdFusion permet d’avoir des bonnes performances grâce au fait qu’il est multiprocessus, configuré de sorte à avoir un certain nombre de processus qui tournent sans arrêt et qui sont en
- 71 -
attente de traiter les requêtes que le serveur leur passe, ce qui évite de devoir lancer un processus à chaque
fois qu’une requête arrive et occupe moins de ressources.
Les performances sont aussi soutenues par un système de compilation juste à temps des pages avant leur
véritable exécution et par un mécanisme de gestion de la mémoire cache, qui peut stocker dans la mémoire
soit des versions compilées des pages, soit des pages déjà complétées.
D’autres facteurs qui permettent d’améliorer la performance du produit sont la possibilité d’utiliser des accès
natifs aux bases de données sans devoir passer par des couches d’abstraction et la possibilité de regrouper
des connexions persistantes aux bases de données dans un groupe accessible en permanence.
ColdFusion permet de prendre explicitement en charge les problèmes de scalabilité en permettant le
regroupement de plusieurs serveurs (clustering) et en permettant un équilibrage de charge dynamique entre
les serveurs. Cette solution permet également de gérer les situations de pannes d’un serveur en répartissant la
charge de travail sur les autres.
6.2.5.5 Portabilité
Le ColdFusion Server, qui comprend un serveur Web, le moteur d’interprétation ColdFusion et le composant
d’administration peut tourner sur les plate-formes Windows, Linux et Unix. Les applications ColdFusion
peuvent être transportés d’un système à un autre sans avoir de grands problèmes.
Sans utilisation de l’option de groupage de serveurs (clustering), ColdFusion peut s’intégrer avec les
principaux serveurs Web pouvant utiliser les interfaces ISAPI, NSAPI, Apache et CGI, ce qui permet de
travailler avec tous les principaux serveurs. Parmi les serveurs compatibles lorsque le groupage de serveur
est utilisé, on peut citer Apache, IIS, Netscape et iPlanet.
6.2.5.6 Securité
L’outil d’administration de ColdFusion permet d’établir des paramètres de sécurité permettant de restreindre
l’accès aux différentes ressources aux seuls utilisateurs autorisés. L’attribution des autorisations peut se faire
de façon individuelle pour chaque page, application, fichier et source de données. Par la suite un utilisateur
pourra accéder à une ressource seulement s’il est identifié (authentifié) comme utilisateur autorisé. Il est
aussi possible de créer son propre mécanisme d’authentification en se basant sur les services du serveur Web
ou sur une base de données.
Afin de rendre plus sure le développement et la distribution d’application ou de balises personnalisées,
ColdFusion donne la possibilité d’exiger la protection par mot de passe ou chiffrement du code source, de
façon à en rendre la distribution plus sûre.
Enfin il est possible de bien gérer les erreurs, pouvant notamment de définir des blocs de code pouvant
générer des exceptions et des structures permettant d’effectuer certains traitements dans le cas où un
exception serait levée. Les messages d’erreur affichés aux utilisateurs peuvent aussi être personnalisés, ainsi
que leur consignation dans des fichiers de journal.
6.2.5.7 Séparation entre contenu, logique de traitement et présentation
La séparation du contenu, de la logique de traitement et de la présentation est obtenu grâce à trois moyens
principaux: l’utilisation d’une source de données pour emmagasiner le contenu, les balises personnalisées et
les inclusions de fichier.
En effet l’architecture typique de ColdFusion est une architecture trois-tiers, où le serveur se charge de la
logique de traitement et de la présentation et la source de données, d’habitude une base de données, se charge
de stocker le contenu de façon structurée.
- 72 -
Grâce au support des architectures COM, Java et CORBA, il est aussi possible d’utiliser une architecture
multi-tiers comportant des serveurs d’application entre le serveur Web et les bases de données. Ces serveurs
d’application peuvent être utilisés pour séparer la logique de traitement et d’accès aux données de la logique
de présentation qui est alors la seule préoccupation du serveur Web.
6.2.5.8 Conclusions
Avantages
L’avantage principal de cette solution est le fait qu’elle est une solution de développement rapide
d’applications très efficace. La productivité des développeurs est favorisée par le fait que CFML est un
langage de très haut niveau, facile à apprendre et qui permet une écriture plus compacte du code, en moins de
lignes, par rapport aux autres solutions. Pour développer rapidement ses Applications ColdFusion,
Macromedia propose son excellent outil de développement, ColdFusion Studio, et un puissant éditeur visuel,
Dreamweaver.
En plus la productivité des développeurs peut être améliorée grâce aux balises et composants déjà
programmés et qui peuvent être obtenus sur des sites d’échange, par les balises et fonctions personnalisées et
par l’intégration avec les architectures de composants COM, CORBA et Java.
Un autre avantage important de cette plate-forme est le fait qu’elle permet des bonnes performances,
scalabilité et fiabilité. En effet elle est multi-processus et peut être configurée pour utiliser des groupages de
serveur avec un équilibrage de charge dynamique et la tolérance aux pannes d’un serveur particulier grâce à
la redondance des machines.
Enfin il faut noter que ColdFusion dispose d’un des meilleurs outils d’administration et surveillance de la
performance, qui permet entre autre le paramétrage du serveur, des politiques de sécurité et des sources de
données.
Inconvénients
L’inconvénient principal est celui d’un langage qui n’est pas autant flexible et puissant que des vrais
langages de programmation, même s’il est possible de profiter d’un langage de script en plus du langage à
balises CFML. S’il est vrai que ColdFusion permet également d’utiliser son API pour écrire des
programmes dans des langages traditionnels tels que Java et C++, il faut toutefois noter que dans ce cas il
faut également apprendre ces langages, ce qui comporte un temps d’apprentissage bien plus long.
Cas d’utilisation souhaité
ColdFusion est un langage de développement rapide, qui permet d’être très productifs dans le développement
d’applications, surtout basées sur des bases de données. Il serait donc conseillé d’utiliser cette technologie
pour le développement de sites dans des délais limités et lorsqu’il faut confier le développement à des
développeurs Web qui n’ont pas déjà acquis les bases d’un langage de programmation.
ColdFusion est une solution polyvalente qui peut être employée pour construire des sites de toute taille, y
compris des sites d’entreprise, grâce aux possibilités de s’intégrer avec des architectures basées sur les
composants EJB et COM, à ses performances et scalabilité et à son modèle de sécurité. Il faut toutefois noter
que les JSP lui sont supérieures pour les très grands projets d’entreprise et que PHP lui serait préférable pour
des sites amateuriaux.
7
Conclusion
Dans cette section on va présenter de façon synthétique les résultats des langages analysés dans le cours de
ce travail sous forme de tableau comparatif. On va en particulier présenter 3 tableaux: le premier analyse les
différences et les avantages respectifs entre les solutions coté serveur et les solutions coté client; le deuxième
- 73 -
présente les résultats de l’analyse des solutions coté client et le troisième présente les résultats de l’analyse
des solutions coté serveur.
- 74 -
7.1
Analyse des différents types de solution
Dans le tableau suivant on compare de façon générale les quatre solutions pour la création de pages Web:
l’utilisation de pages statiques sur un certain nombre de dimensions pertinentes.
Dimension
Pages statiques
Solutions dynamiques
coté client
Langage(s)
HTML
Applets, ActiveX,
analysés
JavaScript, VBScript
Caractéristiques • Structuration et formatage • Extension des possibilités
de documents hypertexte
des pages statiques par
des programmes insérés
• Création et mise à jour
dans les pages Web
souvent manuelle
• Possibilité de régir aux
• Contenu figé dès la
actions de l’utilisateur
création de la page
Interactivité
• Aucune interactivité
• Interactivité immédiate
possible
sans devoir effectuer un
échange avec le serveur
• Capture et réponse aux
évènements générés par
l’utilisateur
Performance et • Très rapides
• Généralement faibles,
scalabilité
• Est peu affectée par
• Liées à l’implémentation
l’augmentation du trafic,
du moteur d’interprétation
car il n’y a pas de
dans le navigateur
traitements compliqués à • Ne sont pas affectées par
faire
l’augmentation du trafic
Séparation
• Faible
• Moyenne
contenu,
• Fusion entre contenu et
• Feuilles de style CSS
traitement et
présentation due au
• Connexion avec d’autres
présentation
HT ML
systèmes (peu efficiente
• Feuilles de style CSS
et soumise aux restrictions
sécuritaires)
• Séparation par
programmation
Portabilité avec • Tous les navigateurs
• Versions des navigateurs
les navigateurs
limités selon la solution
Cas d’utilisation • Petits et moyens sites non • Effets graphiques et
conseillés
interactifs, dont la mise à
multimédias
jour n’est pas trop
• Validation d’un formulaire
fréquente
avant son envoi
• Portabilité maximale
• Réagir aux différentes
actions des utilisateurs
• Soucis de performances
• Pas de développeurs
qualifiés disponibles
• Contenu statique
- 75 -
Solutions dynamiques
coté serveur
CGI, PHP, ASP, JSP,
Coldfusion
• Extension des possibilités
des pages statiques par
des programmes exécutés
sur le serveur créant des
pages Web à la volée
• Interactivité possible après
échange réseau complet
• Variables selon la solution
choisie
• Affectées négativement
par l’augmentation du
trafic
• Elevée
• Feuilles de style CSS
• Connexion aisée avec
d’autres systèmes
• Séparation par
programmation
• Architectures multi-tiers
• Tous les navigateurs
• Sites interactifs, grands ou
mis à jour fréquemment
• Génération de pages à
partir de bases de
données ou systèmes
d’information
• Intégration avec les
systèmes de l’entreprise
• Contenu personnalisé
Commentaires
Ce tableau montre bien que les différentes solutions répondent à des besoins différents. En particulier, les
pages HTML statiques, dont on a recensé les principales limitations et avantages dans la section 5,
continueront à répondre à un certain nombre de besoins et sont particulièrement adaptés pour des sites de
petite et moyenne taille, où le travail de création et mise à jour du site n’est pas si élevé et ne justifie pas la
création de programmes qui les automatisent, surtout lorsqu’il n’y a pas une disponibilité de développeurs
connaissant des langages de programmation. En effet l’utilisation d’outils visuels permet d’obtenir des
bonnes résultats d’une façon simple et intuitive, même en ne connaissant pas le langage HTML.
Par contre le manque total d’interactivité et lorsque les sites commencent à devenir plus grands, mises à jour
plus fréquemment et doivent s’intégrer avec d’autres systèmes, les pages statiques ne constituent plus une
solution envisageable. Dans ce cas il vaut mieux d’entrer dans le monde des solutions pour la génération de
pages dynamiques. Dans ce monde, les solutions coté client sont utiles pour exploiter le fait d’être proches de
l’utilisateur et de pouvoir répondre directement à ses actions, sans devoir effectuer à chaque fois un échange
réseau; les solutions coté serveur sont utiles pour leur connectivité avec d’autres systèmes informatiques de
l’entreprise, en particulier des bases de données et des serveurs d’application, et par leur portabilité sur tous
les navigateurs (en effet elles produisent des pages HTML tout à fait ordinaires).
Ces trois solutions peuvent être combinées efficacement et il n’est pas rare de voir un site comprenant des
pages issues des trois solutions en fonction des besoins de chaque page. En particulier il est fort conseillé
d’utiliser des simples pages statiques chaque fois qu’il est possible, surtout lorsque les pages présentent du
contenu qui ne doit pas être personnalisé ou mis à jour fréquemment, utiliser les solutions coté client pour
pouvoir réagir aux actions de l’utilisateur rapidement et sans surcharger le serveur et les solutions coté
serveur lorsque les pages présentent du contenu personnalisé ou tiré d’autres systèmes informatiques.
- 76 -
7.2
Solutions coté client
Le tableau suivant compare les solutions coté client analysées dans ce travail sur les différentes dimensions
présentées. En plus d’une appréciation quantitative subjective des langages dans les différentes dimensions
selon une échelle de 1 à 5 (où 1 est mauvais et 5 est excellent), des brefs commentaires sont faits pour les
principaux éléments propres à chaque dimension.
Dimension
Langage(s)
Caractéristiques
Type de
programmes
Fonctionnalités
Productivité
Facilité d’écriture
et d’utilisation
Applets Java
Java
• Fortement typé
• Générique
• Orienté objet
• Interprété
Programmes complets
Active X
C++, Visual Basic, Java
• Fortement typé
• Générique
• Orienté objet
• Compilé
Programmes complets
4
• Langage puissant et
complet
• Limitations sécuritaires
strictes par défaut (Applets
non signés)
• Limites de performance et
support de la version 1 de
Java par des navigateurs
(sans Java Plug-in)
• Algorithmique de base
• Variables, tableaux, fichiers,
objets et structures
chaînées
• Moteur graphique, GUI
• Connectivité réseau et
bases de données
• Programmation concurrente
4
• Langage fortement type
• Nécessite des bonnes
bases de programmation
5
2
• Langage puissant et
• Limités par la faible
complet
puissance des langages
• Aucune limitation sécuritaire • Certaines limitations
sécuritaires
• Pas de limitation due aux
performances
• Limités par la performance
des moteurs d’interprétation
installés dans les
navigateurs
Réutilisation du
code
• Architecture objet
• Composants JavaBeans
Libraire d’API
standard et
extensions
disponible
• Libraire complète (J2SE),
limitée à la version 1 pour
une portabilité maximale ou
utilisation du Java Plug-in
• Excellente documentation
• Un certain nombre d’Applets
prêts à l’emploi
• Nombreux outils de développement spécifiques (Forte,
Jbuilder, Visual J++…)
Outils de
développement
- 77 -
• Algorithmique de base
• Variables, tableaux, fichiers,
objets et structures
chaînées
• Moteur graphique, GUI
• Connectivité réseau et
bases de données
• Programmation concurrente
5
• Variable en fonction du
langage utilisé
• Nécessite des bonnes
bases de programmation
• Architecture objet
• Composants COM
• Libraire et documentation
complète selon le langage
• Vaste collection de contrôles
ActiveX prêts à l’emploi
disponibles gratuitement ou
par différentes entreprises
JavaScript et VBScript
JavaScript, VBScript
• Faiblement typé
• Spécifique au Web
• Procédural, support objet
• Interprété
Scripts mélangés à du HTML
• Algorithmique de base
• Variables, tableaux, objets
• Accès au modèle d’objet du
navigateur et à ses services
pour le graphisme,
l’interface utilisateur, les
fichiers,…
3
• Langage faiblement typé
• Insertion dans du HTML
• Accessibles à des
développeurs occasionnels
• Modèle objet limité
• Langages restreints et ciblés
à la création de pages Web
• Libraire limitée
• Sites d’échange de code
Nombreux outils de dévelop- • Outils de développement
pement spécifiques selon le
limités
langage utilisé (ligne Visual de
Portabilité
Performance
• Outils de modélisation
5
• Code indépendant de la
plate-forme grâce à la
machine virtuelle Java
• Java Plug-In
• Principaux navigateurs,
Explorer (>v3), Netscape
(>v2), Opera (>3.5)
2
4 (JavaScript) - 1 (VBScript)
• Code dépendant de la plate- • Code dépendant de la plateforme (souvent Windows)
forme
dans le cas d’une
• Différentes implémentations
compilation ciblée et
dans différents navigateurs
utilisation d’API Windows
• VBScript limité à Explorer
• Microsoft Explorer (>v3) et
(>v3), JavaScript aux
partiellement Netscape
principaux navigateurs
(>v4)
(Explorer >v2.5, Netscape
>v3, Opera >3.5)
3
5
3
• Performances limitées par le • Bonnes performances grâce • Performances limitées par
temps de chargement et
aux possibilités de
l’implémentation des
l’implémentation de la JVM
compilation et optimisation
moteurs d’interprétation
dans les navigateurs
de code
dans les navigateurs
• Améliorable grâce au Plug- • Téléchargement des
• Pas de problèmes de
in
programmes plus efficient
téléchargement grâce au
grâce à la mémorisation du
faible encombrement des
• Téléchargement des
programme
sur
le
client
scripts
programmes peu efficient
Sécurité
•
•
•
•
Séparation
présentationcontenu
Cas d’utilisation
conseillés
Microsoft)
5
2
Modèle de sécurité stricte
• Modèle souple par
par défaut (SandBox)
certification numérique et
demande d’autorisation
Modèle souple par
certification numérique et
• Distribution de code compilé
demande d’autorisation
• Risques élevés
Distribution de code compilé
Risques modérés à élevés
4
5
• Focalisation sur la
présentation
• Séparation possible par
l’architecture de classes,
composants et connectivité
avec d’autres systèmes
• Limitations modèle
sécuritaire
• Projets InterNet
• Projets de taille moyenne à
grande
• Animations, graphismes,
jeux, applications avec
interface utilisateur,
protocoles non supportés
par le navigateur,
applications distribuées,…
- 78 -
• Focalisation sur la
présentation
• Séparation possible par
l’architecture de classes,
composants et connectivité
avec d’autres systèmes
•
•
•
•
3
Certaines restrictions par
défaut
Modèle souple par demande
d’autorisations
Distribution de code source
Risques modérés
2
• Focalisation sur la
présentation
• Séparation possible par les
fonctions
• Projets IntraNet
• Projets IntraNet (VBScript)
• Projets de taille moyenne à et InterNet (JavaScript)
grande
• Projets de petite taille
• Multimédia, graphismes,
• Validation des données de
jeux, applications avec
formulaire, effets
interface utilisateur,
graphiques, gestion de
applications distribuées,…
fenêtres, programmes
simples
• Développeur peu
expérimentés
Commentaires
Les solutions coté client sont généralement utilisés pour exploiter leur caractéristique d’être exécutés sur la
machine cliente et de pouvoir par conséquence réagir immédiatement aux actions de l’utilisateur. Le fait de
s’exécuter sur la machine cliente pose cependant des problèmes de sécurité (code malveillant, non respect
des données privées) et il est possible que des utilisateurs prudents n’acceptent pas d’autoriser l’exécution de
ces programmes sur leur machine.
Grâce à la possibilité d’utiliser le modèle d’objets et événements mis à disposition par le navigateur, les deux
langages de script sont particulièrement adaptés pour capter les événements issus des actions de l’utilisateur
et contrôler les autres éléments inclus dans la page. En particulier on peut citer le contrôle des formulaires
avant leur envoi au serveur, l’insertion d’éléments graphiques non supportés par le HTML et des
programmes issus des deux autres solutions. Etant donnée leur plus grande facilité d’aprentissage et
utilisation, les deux langages de script sont souhaitables même lorsqu’il n’y a pas de développeurs qui
maîtrisent suffisamment les langages de programmation plus évolués, cependant à cause de leur puissance et
performances limitées, il vaut mieux de se restreindre à des programmes très simples. Parmi les deux
langages, le choix est à faire sur deux critères, le langage avec lequel on est plus à l’aise et la portabilité
limité de VBScript, qui le limite souvent à l’utilisation dans des environnements IntraNet.
Les deux autres solutions peuvent être employées pour insérer des véritables programmes dans les pages
Web. Ces programmes peuvent être généralement utilisés pour implémenter des effets graphiques, des
véritables applications avec interface utilisateur, se connecter avec d’autres système et des jeux. Les deux
solutions sont cependant mieux placés pour effectuer un certain nombre de tâches. En particulier les Applets
peuvent être mieux utilisés pour gérer des animations, des effets graphiques sur images et utiliser d’autres
protocoles que ceux permis par le navigateur; les ActiveX peuvent mieux gérer des éléments multimédia et
effectuer différents traitements ayant accès à la machine utilisateur. En plus étant donné le modèle sécuritaire
très permissif et la portabilité douteuse, les ActiveX sont les plus susceptibles d’être réfusés par les
utilisateur et il vaut mieux de les utiliser dans un environnement contrôlé comme les IntraNet où lorsque on
ne se soucie que des utilisateurs orientés Microsoft. Les Applets seraient la solution de choix pour des
développements sur InterNet où on se soucie de pouvoir atteindre le plus de monde.
- 79 -
7.3
Solutions coté serveur
Le tableau suivant compare les solutions coté client analysées dans ce travail sur les différentes dimensions
présentées. En plus d’une appréciation quantitative subjective des langages dans les différentes dimensions
selon une échelle de 1 à 5 (où 1 est mauvais et 5 est excellent), des brefs commentaires sont faits pour les
principaux éléments propres à chaque dimension.
ASP
PHP
JSP
ColdFusion
Langage(s)
VBScript,
JavaScript,
Langages COM
PHP
Java
CFML CFScript
Version étudiée
Disponibilité, prix
PHP4.0.6
Open Source, gratuit
Tomcat 3.2
Open Source, gratuit
• Faible
• Fort
ColdFusion 4.5
ColdFusion Server, 8000
Fr.
• Faible
Type de langage
ASP 3.0
Windows/IIS, intégré
Chili!Soft, n/a
• Scripts: faible
• Composants: selon
langage
• Script
• Script
• Langage de marquage
• Script
Style de syntaxe
Orientation
Exécution
• Basique/C
• Spécifique Web
• Interprété
•
•
•
• HTML
• Spécifique Web
• Interprété
Type de programmes
• Scripts mélangés à du •
HTML, composants
Typage
Fonctionnalités
Programmation
Algorithmique de base
Support objet
Modèle objet implicite
Composants: natif
Composants: supportés
Balises personnalisées
Intégration HTML
Connectivité
Bases de données
Serveurs d’application
Connexions réseau
Programmation distrib.
Protocoles Internet (FTP,
e-mail, …)
Services Web
Traduction requêtes http,
codage URL, cookies…
Sessions
Variables d’applicaiton
Moteur graphique
Productivité
Facilité du langage
Objets et composants
Réutilisation du code
• Langage de
programmation
complet orienté objet
C
• C
Spécifique Web
• Générique
Interprété
• Interprétation de code
compilé
Scripts mélangés à du • Scripts et balises
HTML
mélangées à du HTML,
composants
5
3
• Scripts ou balises
mélangées à du HTML
5
4
•
•
•
•
•
•
•
Oui
Limité
Oui
COM
Java, CORBA
Non
Oui
•
•
•
•
•
•
•
Oui
Limité
Non
Non
Java, CORBA
Non
Oui
•
•
•
•
•
•
•
Oui
Oui
Oui
JavaBeans, EJB
CORBA, COM
Oui
Oui
•
•
•
•
•
•
•
Oui
Non
Non
Non
Java, CORBA
Oui
Oui
•
•
•
•
•
OBDC, ADO
Limités
Oui
Oui, DCOM
Oui
•
•
•
•
•
OBDC, API native
Limités
Non
Non
Oui
•
•
•
•
•
JBDC, OBDC
Nombreux
Oui
Oui,
Oui
•
•
•
•
•
OBDC, API native
Limités
Non
Non
Oui
• Oui
• Oui
• Oui
• Oui
• Non
• Oui (limité)
• Non
• Oui
4
3
• Facile/Moyenne
• Facile
• Oui
• Limité
• Fonctions réutilisables • Fonctions réutilisables
• Inclusion de fichiers
• Inclusion de fichiers
• Composants
• Classes d’objets
(limité)
- 80 -
• Oui
• Oui
• Oui
• Oui
• Oui
• Oui
• Oui
• Oui
•
•
•
•
•
•
4
Difficile
Oui
Classes d’objets
Inclusion de fichiers
Composants
Balises
•
•
•
•
•
5
Facile
Limité
Fonctions réutilisables
Inclusion de fichiers
Balises
personnalisées
Libraire d’API
standard
• Discrète libraire API,
bien organisée
Documentation
• Médiocre
Composants/code prêt • Nombreux
à employer disponible
composants en vente
Outils de développement • Nombreux outils de
bonne qualité (i.e.
ligne Visual de
Microsoft)
• Editeurs visuels
compatibles
• Congrue libraire API
mais instable et peu
cohérente
• Bonne
• Nombreux scripts
• Communauté de
support active
• Peu d’outils de
développement,
médiocre qualité
• Editeurs visuels
compatibles)
Portabilité
3
Dépendance envers une • Oui, Microsoft
entreprise
Serveurs Web supportés •
/ Systèmes d’exploitation •
Serveurs d’application
Performance
Performances (e-week)
Multi-processus
Accès aux bases de
données
Serveurs d’applications
Groupage de serveurs,
équilibrage de charge
Séparation
présentation-contenu
Fonctions,
classes
d’objets composants
Inclusion de fichiers
Architectures
Cas d’utilisation
conseillés
•
•
•
3
• Open source:
• Principaux serveurs
supportés en mode
CGI
• Module serveur
seulement pour
Apache/UNIX
• Apache / UNIX
MS IIS / Windows
Large choix de
• Large choix de
serveurs et systèmes
serveurs et systèmes
grâce à de logiciels de
en mode CGI
tierces parties:
uniquement
Oui, COM
• Non
Limités, J2EE
5
5
Bonne
• Bonne
personnalisées
• Vaste libraire API, bien • Discrète libraire API
organisée
• Excellente
• Bonne
• Scripts et composants • Nombreux scripts et
balises
• Nombreux outils de
bonne qualité (i.e.
Forte, Visual0 Café,
Jbuilder,)
• Outils de modélisation
• Editeurs visuels
compatibles
5
• Open source,
supporté par les
principaux serveurs
• Nombreux serveurs
d’application
• Portabilité du code
grâce à la JVM
• Principaux serveurs et
systèmes
• Oui, J2EE
•
3
Variables en fonction
de l’implémentation
utilisée
Multi-processus
Architectures n-tiers
avec serveurs
d’application
Services de groupage
de serveurs et
équilibrage de charge
logicielle
JBDC, OBDC
• Multi-processus
• Multi-processus ou
CGI
• Certains serveurs
d’application
• Groupage de serveurs
• Equilibrage de charge
logicielle
•
•
• ADO, OBDC
• API natives, OBDC
•
• Limité
• Limité
• Non
• Non
• Oui
• Oui
4
• Fonctions, classes,
composants
• Oui
• 3-tiers, (N-tiers)
• Intégration avec autres
technologies Microsoft
• Réutilisation de
composants COM
2
•
• Outil propirétaire d’
excellente qualité
(ColdFusion Studio)
• Editeurs visuels
compatibles)
4
• Oui, Macromedia
• , disponible pour les
principales plateformes
• Large choix de
serveurs et systèmes
• Oui, propriétaire
• Limités, J2EE
4
• Assez Bonne
• Multi-processus
• Architectures n-tiers
avec serveurs
d’application
• Services de groupage
de serveurs et
équilibrage de charge
logicielle
• API natives, OBDC
• Limité
• Oui, intégrée
5
3
• Fonctions
• Classes, composants
• Fonctions, balises
• Oui
• 3-tiers
• Projets avec un
investissement
financier et humain
limité
• Pas d’intégration avec
• Oui
• 3-tiers, N-tiers
• Projets de grande
taille
• Intégration avec
d’autres systèmes
d’entreprise
• Oui
• 3-tiers, (N-tiers)
• Développement rapide
de sites
• Volonté d’acheter une
solution complète avec
des bons outils de
- 81 -
des systèmes
• Réutilisation de
d’entreprise
composants Java
• Développeurs novices • Disponibilité de
développeurs Java
gestion et
développement
Commentaires
Les quatre solutions présentées dans ce tableau se ressemblent fortement sur un grand nombre de
dimensions. Un des facteurs qui ont le plus d’influence sur le choix de la solution risque d’être la familiarité
des développeurs avec les langages et technologies utilisées dans les différentes solutions. En particulier ASP
risque d’être choisie par des développeurs habitués à travailler avec les systèmes et outils Microsoft, JSP par
des développeurs maîtrisant déjà Java, PHP par des développeurs débutants ou familiers avec C ou Perl, et
ColdFusion par des développeurs débutants ou attirés par la syntaxe particulière de son langage.
Une deuxième caractéristique notable qui influencent le choix de la solution est le fait de devoir intégrer le
site Web avec d’autres systèmes. Les différents langages s’intègrent parfaitement avec les bases de données,
mais lorsque l’on veut utiliser des serveurs d’applications ou des sources de données différentes, il vaut
mieux d’écarter PHP et pointer plutôt vers ASP, JSP ou ColdFusion selon les systèmes à utiliser.
Enfin les différentes solutions ont des caractéristiques particulières qui les rendent particulièrement biens
adaptés, pour certains types de projets (mais non limités à un usage exclusif dans ce type de projets).
PHP et ColdFusion sont particulièrement bien adaptés dans le cas de projets de sites exploitant une
architecture 3-tiers, avec le premier qui a l’avantage d’être une solution gratuite et qui ne nécessite pas de
programmeurs expérimentés et d’être par conséquent très bien adaptée pour des projets de taille limitée où
l’on ne veut pas faire d’investissements importants. La deuxième solution est mieux adaptée pour des
développement où l’on se soucie à acheter une solution complète, (avec serveur Web, outils de gestion et de
développement, groupage de serveurs et équilibrage de charge) qui permet une productivité et rapidité de
développement considérable.
ASP et JSP sont mieux adaptés que les précédents dans le cas de projets de plus grande taille et qui dépassent
le simple fait d’avoir un serveur Web. ASP est une solution idéale lorsque l’on veut intégrer le serveur Web
avec d’autres systèmes utilisant les différentes technologies Microsoft, par exemple lorsque l’on dispose déjà
de composants COM à réutiliser. JSP est idéale dans le cadre de son insertion dans une architecture
d’entreprise n-tiers de type J2EE, où l’on peut isoler la logique commerciale d’une entreprise dans un serveur
d’application et pouvoir ainsi mieux maintenir le site et l’intégrer avec les autres systèmes de l’entreprise.
- 82 -
8
Bibliographie
8.1
Bibliographie de l’introduction historique
[1]
Cette référence est constituée par une ligne du temps incluant les faits principaux de l’histoire de
l’informatique, consultable par ordre chronologique ou thématique
S. Rossi (1996), “Histoire de l’Informatique”
HTTP://histoire.info.online.fr/
[2]
Ce document décrit l’histoire de l’informatique de façon succincte et propose une intéressante
division du développement des ordinateurs en 5 générations.
C. LaMorte, J. Lilly “Computers : history and development”
HTTP://www.digitalcentury.com/encyclo/update/comp_hd.HTML
[3]
Un document qui n’est pas réellement intéressant, mais complète les deux précédents sur quelques
points.
Golden Ink, “A brief History of Computers and Networks”
HTTP://goldenink.com/computersandnetworks.sHTML
[4]
Un intéressant document sur la naissance et l’évolution de l’Internet, écrit par les acteurs qui ont
contribué à sa naissance. Très complet.
B. Leiner et al. (2000), “A brief history of Internet”
HTTP://www.isoc.org/internet/history/brief.HTML
Sur le même site il existe d’autres références sur le même sujet qui peuvent être trouvées à l’adresse
HTTP://www.isoc.org/internet/history/
[5]
Cette référence regroupe les événéments marquants de l’histoire de l’Internet sous forme de ligne du
temps. C’est une collection de faits très détaillée et intègre un certain nombre de statistiques sur son
évolution.
R. Zakon. (2001), “Hobbes’ Internet Timeline v5.4”
HTTP://www.zakon.org/robert/internet/timeline/
[6]
J.C.R. Licklider. (1962), “On-Line Man Computer Communication”
[7]
L. Kleinrock. (1961), “Information Flow in Large Communication Nets”
[8]
P. Baran. (1961), “On Distributed communications networks”
[9]
S. Feizabadi. (2001), “WWW Beyond the Basics”
[10]
Cette référence contient des informations sur le projet Xanadu. Bien que ce projet n’ait jamais été
réalisé, il a le mérite d’avoir introduit la notion d’hypertexte, qui a successivement inspiré les
créateurs du Web. C’est un modèle ambitieux et plus riche que le Web actuel.
“Project Xanadu”
HTTP://www.xanadu.net/
[11]
Cette référence pointe sur la proposition de projet qui est à la naissance du World Wide Web. Sur le
même site il y a aussi d’autres références historiques intéressantes.
T. Berners-Lee (1990), “Information Management: A Proposal“
HTTP://www.w3.org/History/1989/proposal.HTML
[12]
Cette page et les pages qui lui sont liées donnent un apercu de l’histoire du Web et de l’Internet sous
différents angles différents.
G.R. Gromov (1995), “History of Internet and WWW: The Roads and Crossroads of
Internet History”, HTTP://www.netvalley.com/intval2.HTML
- 83 -
[13]
8.2
8.3
Ce site présente une collection intéressante de ressources sur l’histoire du World Wide Web, un bon
point de départ dans des recherches d’approfondissement.
HTTP://www.w3.org/History.HTML
Le World Wide Web
[14]
A. Dufour (1996): “Internet”, collection que sais-je”, PUF
[15]
M. Augier (1999): “HTML le langage du Web”, collection que sais-je”, PUF
[16]
Ce livre présente de façon simple et peu technique les fondements du World Wide Web, notamment son
architecture, protocoles et langages, insérés surtout dans l’idée du Web comme système de
documentation globale et indépendant des plate-formes basés sur l’hypertexte.
A. Salarelli (1997) “World Wide Web”, AIB Roma
[17]
Cette référence contient la spécification officielle du langage HTML
World Wide Web Consortium (1999): “HTML 4.01 Specification”,
HTTP://www.w3.org/TR/1999/REC-HTML401-19991224/HTML40.txt
[18]
Cette référence contient la spécification officielle du protocole HTTP version 1.1
Fielding et al. (1999): “Hypertext Transfer Protocol – HTTP/1.1 ”, RFC 2616,
http://www.ietf.org/rfc/rfc2616.txt
[19]
Cette référence contient la spécification officielle du langage XML
World Wide Web Consortium (1999): “Extensible Markup Language (XML) 1.0 ”, W3C
Recommandation
http://www.w3.org/TR/REC-xml
[20]
Cette référence contient la recommandation du W3C concernant les feuilles de style CSS
World Wide Web Consortium (1996): “Cascading Styke Sheets, level 1”, W3C Recommandation,
http://www.w3.org/TR/REC-CSS1
[21]
Cette référence pointe sur la définition du standard SGML
ISO (1996): “ ISO 8879:1986. International standard -- Information processing -- Text and office
systems -- Standard gen eralized markup language (SGML)”, ISO,
http://www.iso.ch/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=16387
[22]
Cette référence contient une guide particulièrement utile pour apprendre et utiliser le langage HTML.
Il existe aussi beaucoup d’autres tutoriaux qui peuvent être trouvés sur le réseau.
NCSA: “ A Beginner's Guide to HTML”,,
http://archive.ncsa.uiuc.edu/General/Internet/WWW/HTMLPrimerAll.html
[23]
Ce livre est un livre avancé sur les réseaux d’ordinateurs. Très technique et spécifique sa lecture est
conseillée seulement si on veut avoir des approfondissement sur les différents protocoles. Néanmoins
il contient bonne explication du modèle OSI.
G. Pujolle (1997): “Les réseaux”, Editions Eyrolles
[24]
Cette référence contient la spécification officielle des URL version 1.1
Berners-Lee et al. (1994): “Uniform Resource Locators (URL)”, RFC 1738,
http://www.ietf.org/rfc/rfc1738.txt
Solutions Java: Applets, JSP, Servlets
- 84 -
[25]
Ce livre traite de tous les aspects de la programmation Java, y compris la création d’Applets et
d’applications. Un bon livre pour les débutants.
L. Lemay, R. CadenHead (1998), “Java2 Plate-Forme”, Campus Press
[26]
Le site de Sun Microsytems contient des références utiles sur les différentes solutions et est un bon
point de départ pour toute recherche sur ces technologie. La page d’accueil se trouve à l’adresse
http://java.sun.com/applets
D’autres références intéressantes du même site pointent sur les différentes technologies présentées
ainsi que sur des outils de développement et à la documentation Java.
http://java.sun.com/j2se/
Le site contient aussi un tutorial permettant d’apprendre le langage. Utile pour toutes les solutions.
http://java.sun.com/docs/books/tutorial/
La référence pointe sur la page dédiée aux Applets, un bon point de départ pour collecter de
l’information utile à leur développement ainsi que des exemples d’Applets déjà programmés
http://java.sun.com/applets
Les références suivantes pointent sur les pages dédiée aux Servlets et aux JSP. Ils contiennent un
nombre incroyable d’informations ainsi que des références et exemples utiles.
http://java.sun.com/products/servlet/
http://java.sun.com/products/jsp/
8.4
8.5
ASP, ActiveX et COM
[27]
J.M. Herellier, “Pages Web dynamiques”
[28]
C. Ullman, D. Buser et al. (1999), “Beginning Active Server Pages 3.0”, Wrox Press Ltd.
[29]
T. Coombs et al. (1996), “Programmer avec ActiveX”, Sybex.
[30]
R. Sessions. (2000), “COM+ and the Battle for the Middle Tier”, Wiley.
PHP
[31]
J.M. Herellier, “Pages Web dynamiques”
[32]
J.C. Meloni (2000), “PHP Essentials”, Prima Publishing
[33]
L. Lacroix et al. (2000), “Programmation Web avec PHP”, Prima Publishing
[34]
T. Ratschiller, “PHP from an IT manager’s perspective”
[35]
S. Bakken et al. “ PHP 4.0 Manuel de référence”
[36]
R. Lerdorf (2000) “ PHPPocket Reference”, O’reilly
[37]
Des sites intéressants au sujet de PHP sont
www.php.org, le site officiel de PHP, qui donne entre autre la possibilité de télécharger la dernière
version du code source et de la documentation officielle
www.nexen.fr, un site français dédié au PHP, d’où il est possible de télécharger la documentation
française annotée, consulter un forum et consulter des exemples de scripts
www.easyphp.net, qui donne la possibilité de décharger un logiciel complet qui installe su la machine
tout ce qu’il faut pour créer un site avec PHP, notamment le langage PHP, un serveur Apache, une
- 85 -
base de données MySql et un logiciel de gestion de base de données, PhpMyAdmin .Seulement pour
Windows.
8.6
8.7
CGI
[38]
D. Coar, D. Robinson (1999)“ The WWW Common Gateway Interface”,
HTTP://cgi-spec.golux.com/draft-coar-cgi-v11-03-clean.HTML
[39]
S. Gundavaram (1996)“ CGI Programmin on the World Wide Web”, O’reilly & Associates
HTTP://cgi-spec.golux.com/draft-coar-cgi-v11-03-clean.HTML
[40]
R. Schwartz (1993)“ Learning Perl”, O’Reilly & Associates
HTTP://cgi-spec.golux.com/draft-coar-cgi-v11-03-clean.HTML
Autres
[41]
W3C “ The World Wide Web Security FAQ”,
HTTP://www.w3.org/Security/FAQ/index.html
- 86 -
9
Glossaire
ActiveX
Technologie dérivée des spécifications OLE de Microsoft, qui permet d'intégrer aux documents web des
animations et du son. Par comparaison à Java, c'est davantage une plate-forme servant à produire des
composants logiciels pour Windows, qu'un langage de programmation
Apache
c'est le nom d'un serveur HTTP très répandu, performant et libre de droit, fonctionnant principalement
sous UNIX.
API
Application Programming Interface: convention utilisée par une application pour s'interfacer avec le
système d'exploitation.
Applet
Une petite application Java qui est exécutée au sein d'une page HTML.
ARPA:
Advanced Research Projects Agency. Désigne l’organisation de développement de projets du
département de la défense américain.
ArpaNet:
Désigne le réseau basé sur la technologie de la commutation de paquets développé par l’ARPA
au cours d’un projet destiné à la conception d’un réseau d’ordinateurs à usage militaire, fiable
et capable d’être opérationnel même en cas de destruction partielle. C’est sur la base de ce
réseau que Internet voit sa naissance.
ASCII
Standard de codification sur 7 bits d'un jeu de caractère alphanumérique (non accentué) occidental.
ASP
Active Server Pages: technologie de Microsoft analogue à PHP et JSP permettant le développement de
pages dynamiques coté serveur.
CGI
Common Gateway Interface. interface permettant à un serveur web de communiquer avec une
application, dont celui-ci a besoin pour traiter une information ou une requête issue d'une page.
Chat (IRC)
Internet Relay Chat. application et service TCP/IP permettant de s'entretenir en temps réel avec des
personnes connectées au même moment.
Client-Serveur
Architecture visant à répartir une application entre une ou plusieurs unités fonctionnelles qui émettent des
requêtes (côté client) et l'unité fonctionnelle qui traite ces requêtes (côté serveur).
Cookie
Petit fichier texte enregistré sur l'ordinateur client afin d'y stocker des informations sur l'utilisateur, et de
"reconnaître" cet utilisateur lors de sa prochaine visite sur un même site.
CORBA
Common Object Request Broker Architecture: une norme de facto qui permet de recréer,
dans Internet, l'architecture client-serveur distribuée.
ColdFusion
Solution coté serveur développée par Macromedia pour développer des pages dynamiques.
COM
Technologie de Microsoft qui fournit un système d’exécution pour des composants compatibles
COM (par exemple des composants ActiveX) et offre un certain nombre de services.
CSS
Cascading Style Sheet: norme avancée du HTML 4.0, qui facilite la mise en page des documents
HTML.
DTD
Document Type Definition. Document qui définit les règles syntaxiques à respecter pour la
création d’un document avec un langage de marquage.
E-mail:
Electronic Mail. Service géré par ordinateur fournissant aux utilisateurs les fonctions de saisie,
de distribution et de consultation différée de messages, notamment écrits, graphiques ou
sonores.
Ethernet
technologie de réseau local fonctionnant généralement de 10 mégabits/s à 100 mégabits/s pour le récent
Fast Ethernet ou à 1 gigabit/s pour le Gigabit Ethernet.
Firewall
Pare-feu: ordinateur généralement placé entre le réseau d'une entreprise et l'Internet, afin de bloquer
toute connexion d'un utilisateur non autorisé.
Flash
technologie développée par Macromedia pour créé des animations et des pages au graphisme très soigné
dont l'affichage se fait au moyen d'un plug-in adjoint au navigateur.
Frame
système de multifenêtrage mis au point par Netscape, chaque cadre étant géré de façon indépendante
FTP:
File Transfer Protocol. Désigne un protocole de niveau application de transfert de fichiers basé
permettant la copie de fichier d'un ordinateur vers un autre
- 87 -
Gopher
Désigne un service distribué de documentation développé par l'Université du Minnesota
permettant d’effectuer des recherches sur le réseau. Abandonné après l’essor du Web.
GUI
Graphical User Interface: interface utilisateur graphique permettant de construire des
applications utilisables dans un environnement graphique et généralement composée de
différents types de boutons et fenêtre.
Hôte (Host)
Ordinateur sur le réseau TCP/IP, qui héberge une ressource consultable à distance par un client à travers
Internet.
HTML
HyperText Markup Language langage mutiplateforme utilisé pour concevoir des pages sur le World
Wide Web. Il permet de décrire la présentation et la structure d'une page, et surtout les liens avec d'autres
documents hypertexte situés sur le Réseau.
HTTP
HyperText Transfer Protocol protocole et service TCP/IP de type requête réponse sans mémoire
d’état pour transférer des pages Web au travers d'Internet.
Hypertexte
Façon de structurer et présenter de l'information en permet une lecture non linéaire de documents grâce
à la présence de liens sémantiques définis de façon arbitraire.
IETF
Internet Engineering Task Force: organisme chargé de la recherche sur l'évolution d'Internet.
Internet Explorer
Navigateur Internet conçu par Microsoft et automatiquement inclu dans Windows depuis 1998. S'abrège
souvent en MSIE ou IE.
IntraNet
Variante de l'Internet pour les réseaux privés d'entreprise comportant l’utilisation des protocoles et des
outils de l'Internet dans les réseaux d'entreprise et la mise en œuvre d'applications internes au format
HTML (et dérivés).
INWG :
International Network Working Group
IP
Internet Protocol. Désigne le protocole de niveau réseau utilisé dans la suite de protocoles
TCP/IP, qui découpe en paquet les données sur Internet et qui s’occupe de l’adressage et de
l’acheminement des paquets vers la machine de destination sans fournir des garanties de
services.
ISO
Organisation en charge de la Normalisation et à l'origine de nombreux standards techniques utilisés sur
Internet.
Java
Langage multiplateforme, générique et orienté objet créé et développé par Sun Microsystems, largement
utilisé sur Internet.
JavaBean
Technologie de composants Java, permettant la création de code facilement réutilisable.
JavaScript
Langage de programmation de scripts, créé et développé par Netscape. Contrairement à Java, JavaScript
est un langage interprété.
JScript
Langage de programmation de scripts, créé et développé par Microsoft, concurrent de JavaScript, mais
moins utilisé.
JSP
Java Server Pages: solution coté serveur pour la génération de pages dynamiques développée par Sun.
JVM
Java Virtual Machine: surcouche logicielle au système d'exploitation, spécifique à chaque processeur pour
interpréter les instructions Java. Le code ainsi produit est portable sur toutes les machines disposant
d’une machine virtuelle Java. Le code développé pour cette machine virtuelle est aussi appelé bytecode.
Liens hypertexte
Moyen utilisé pour passer d'un page Web à une autre. Qui constitue le mode de navigation géré par le
protocole HTTP.
Linux
Variation du système UNIX très répandu.
Mosaic
Navigateur Internet avec interface graphique très répandu sur Internet et qui a fortement contribué à la
croissance du World Wide Web.
Netscape
Navigateur Internet conçu par la société du même nom, créée par les mêmes développeurs du navigateur
Mosaic.
News :
Nom générique du système de discussion désignant l'ensemble des forums d'Usenet. Elles sont de
formidables réservoirs d'informations fédérés par thèmes.
- 88 -
NCP:
Network Control Protocol. C’est le protocole de communication utilisé sur le réseau ArpaNet
entre 1970 et 1983, date à laquelle il sera remplacé par les protocoles TCP/IP. C’est grâce à ce
protocole que le premières applications réseau ont pu être développés.
NCSA
National Center for SuperComputing Applications. C’est ici que le premier navigateur de
succès, Mosaic, a été développé
NSF :
National Science Foundation
NSFNet
National Science Foundation Net.
OBDC
Interface logicielle qui permet d'effectuer des échanges de données entre une application et une base de
données de façon standardisée.
Opera
Un navigateur Web alternatif à Netscape et Explorer.
Perl
Practical Extraction and Report Language : un langage de script coté serveur, disponible sur la plupart
des OS est fréquemment utilisé pour construire des programmes CGI, utilisés essentiellement pour traiter
et mettre en forme les données d'une application cliente.
PHP
PHP: Hypertext Preprocessor: technologie permettant la création de pages Web au contenu dynamique,
similaire aux solutions ASP de Microsoft et JSP de Sun, mais provenant des environnements UNIXApache et libre de droits.
Plug-in
module logiciel destiné à ajouter des fonctions, dans le but de travailler en collaboration avec un
navigateur, pour lui permettre d'afficher ou d'entendre certains fichiers d'un format non reconnu de façon
native.
RFC
Request For Comment: documentation officielle et publique de l'Internet, TCP/IP et autres standards de
connexion. Les RFC sont le résultat des travaux de IETF.
Script
Petit programme écrit dans un langage interprété.
Serveur de noms:
Une machine qui contient une base de donnée d’adresses IP utilisée pour faire la correspondance entre
un adresse IP de la machine hôte et son nom logique.
Servlet
programme Java qui s'exécute dynamiquement sur un serveur Web, et permet l'extension des fonctions
du serveur.
Session
Désigne un ensemble d’interactions liées entre elles entre un client et un serveur.
SGML
Standard Generalized Markup Language: langage normalisé permettant de décrire les relations entre
le contenu d'un document informatique et sa structure. HTML et XML, par exemple, sont dérivés de la
norme SGML.
TCP
Transport Control Protocol. Désigne le protocole de niveau transport utilisé dans la suite de
protocoles TCP/IP, qui permet de fournir un certain nombre de garanties de services que IP ne
fournit pas. Notamment TCP s’occupe du contrôle de flux, du contrôle d’erreurs et la reprise
sur erreur et de l’ordonnancement des paquets.
Telnet:
Terminal Emulation. Protocole et service TCP/IP permettant d'effectuer une connexion à distance sur
un ordinateur connecté au Réseau.
UDP
User Datagram Protocol : désigne un protocole de niveau transport non connecté, alternatif à TCP, qui
ne garantit aucune qualité de service.
Unix
Système d'exploitation multitâche et multi-utilisateurs généralement employé pour faire
fonctionner les serveurs. Ses origines remontent aux années 60 et il contribue encore beaucoup
à l'expansion d'Internet. Les principaux UNIX sont : Solaris de Sun Microsystems, Linux, Mac
OS X d'Apple, NetBSD et FreeBSD.
URL
Uniform Rseource Locator. Syntaxe permettant de spécifier le moyen aux différents types de
ressources du Réseau et composée par le protocole d’accès, l’adresse de la machine et la localisation de
la ressource sur la machine.
World Wide Web
Désigne le service le plus utilisé d’Internet actuellement, constitué d’un réseau de documents
hypertexte distribué de taille mondiale. Se base sur une architecture client-serveur, sur le
langage HTML, le protocole HTTP et le schéma de nommage URL.
- 89 -
XML
eXtensible Markup Language: successeur du HTML, le XML est, comme l'indique son nom, un
langage destiné à étendre les possibilités de HTML grâce à la possibilité de créer des balises
personnalisées utiles pour préciser la structure et le contenu sémantique de documents.
XSL
eXtensible Style Language: feuilles de style utilisées conjointement avec les documents XML
pour définir la mise en page et la présentation de ces derniers.
- 90 -
10
Annexes
10.1 Annexe 1: Evolution de l‘ArpaNet / Internet – nombre de hôtes
Figure A1.1 : Nombre d’hôtes liés à l’Internet
Figure A1.2 : Nombre d’hôtes liés à l’internet (échelle logarithmique)
En regardant ces graphiques il apparaît évident que le développement de l’Internet a été spectaculaire,
surtout après 1980. En particulier ce développement suit presque parfaitement une courbe logarithmique.
- 91 -
10.2 Annexe 1: Evolution du world wide Web
Figure A2.1 : Nombre de sites Web
Figure A2.1 : Nombre de sites Web
- 92 -
11
Partie pratique: une application Web de commerce électronique
11.1 Présentation du concept
Cette partie est dédiée à la conception et la mise en œuvre pratique d’un site Web utilisant une des solutions
pour la création de pages dynamiques étudiées dans ce travail. L’application choisie est un site de commerce
électronique offrant les fonctionnalités typiques d’un magasin en ligne. Le choix de ce type de site a été
motivé par le fait que les sites de commerce électronique constituent un des plus communs types de sites et
parce qu’il permet de mettre en œuvre un peu tous les fonctionnalités qui sont spécifiques aux sites basés sur
des pages dynamiques, tels que la gestion des sessions et de l’interaction avec l’utilisateur, la création et mise
à jour du site automatique etc.
La conception du site a été basée sur le modèle du Java Pet Store, l’application de démonstration livrée avec
l’implémentation de référence de la plate-forme Java 2 Entreprise Edition. Le choix s’explique par le fait
qu’en utilisant une application de base à la conception il serait plus facile de pouvoir comparer les différentes
solutions utilisées.
Les fonctionnalités exigées par l’application sont les suivantes:
•
•
•
•
•
•
•
•
Navigation à travers un catalogue d’articles, classés par catégorie;
Recherche d’articles par mots clé;
Gestion d’un panier des achats;
Gestion d’un système d’ordination en ligne;
Gestion d’un système d’authentification;
Personnalisation du site;
Gestion du catalogue d’articles à travers une base de données ;
Gestion des ordres passés par les clients;
La solution retenue pour implémenter cette application est PHP. Ceci est du au fait que c’est une solution
gratuite et qui est particulièrement bien adaptée pour la création de sites dynamiques de taille réduite, basés
sur une architecture trois-tiers. Les logiciels composants cette architecture ont été choisis par le fait d’être
fournis dans un package complet de logiciels open source qui s’intègrent bien les uns avec les autres. Ce
package, EasyPHP1.5 comprend les produits suivants:
•
•
•
•
Serveur Web: Apache 1.3.20 sur Windows ‘98
Moteur d’interprétation: PHP 4.0.6, module d’extension du serveur Apache
Base de données: MySQL 3.23.40
Outil d’administration de base de données, PhpMyAdmin 2.2
L’application peut être divisée en deux parties: un module client et un module administration. Dans les
sections qui suivent on va passer en revue les deux modules et on va regarder le schéma de bases de données
qui est utilisé.
- 93 -
11.2 Module utilisateur
La partie utilisateur a été conçue sur le scénario d’utilisation suivant:
•
•
•
•
•
Un utilisateur se connecter à l’application à travers l’URL de sa page d’accueil. Cette page lui donne la
possibilité de naviguer à travers les articles d’une façon hiérarchique et à travers une recherche par
mots clé.
A n’importe quel point de sa navigation, le client peut s’enregistrer dans l’application en utilisant son
nom d’utilisateur et son mot de passe. Ceci lui permet de contrôler et modifier ses données
personnelles. Des utilisateurs non enregistrés peuvent obtenir un compte utilisateur en fournissant un
nom d’utilisateur et un mot de passe
Si l’utilisateur trouve un article qui l’intéresse, il peut le sélectionner pour avoir plus de détails et
l’ajouter à son panier d’achats. Le contenu du panier lui est alors présenté et le client a le choix entre
continuer à naviguer dans le catalogue de produits, modifier les quantités des articles commandés ou
les retire du panier d’achats ou enfin passer un ordre d’achat pour le panier. L’utilisateur peut à tout
moment demander l’affichage du panier d’achats.
Lorsque l’utilisateur choisit de passer un ordre d’achat, s’il ne s’est pas enregistré auparavant, il doit
s’enregistrer et fournir un certain nombre de donnes personnelles. Après que l’utilisateur se soit
enregistré, la procédure d’achat continue avec la demande des renseignements nécessaire à l’envoi de
l’ordre et à sa facturation.
L’utilisateur se voit présenter une page avec toutes les données liées à l’ordre, sauf les données
personnelles sur sa carte de crédit pour des motifs de sécurité. Il est enfin demandé de confirmer une
dernière fois l’ordre. Une fois confirmé, l’ordre est enregistré dans la base et est prêt pour être traité.
L’utilisateur et l’administrateur du site reçoivent un message électronique de confirmation.
La structure des pages, plasmée selon le scénario d’utilisation décrit précedemement de la partie client est
résumé (et simplifiée) dans la figure suivante.
Registration
signin.php
Page d’accueil
home.php
Validation
Création ou consultation
d’un compte
Modification
d’un compte
Validation
Compte utilisateur
account.php
Recherche
search.php
Catalogue
catalog.php
Consultation
Navigation
Ajout produit
Panier d’achats
cart.php
Ordre
checkout.php
Modification quantités,
retrait produit
Registration
signin.php
Infos livraison
placeorder.php
Validation
Infos facturation
billingorder.php
Validation
Confirmation
commitorder.php
Figure : Fonctionnement du World Wide Web
Les différents pages sont représentées par les rectangles arrondis, dans lesquels sont inséré la fonction de la
page et le nom du fichier qui lui est associé. Les pages colorés avec une teinte plus foncée sont accessibles
- 94 -
directement par n’importe quelle autre page grâce aux barres de navigation présentes dans toutes les pages.
Les flèches représentent les autres principaux liens de navigation. Les petits rectangles associés représentent
des pages de validation utilisés pour contrôler les données fournis par l’utilisateur lorsqu’il transmet des
données aptes à effectuer des mises à jour de la base de données: si les données passent le contrôle de
validation, l’action correspondante est effectuée et l’utilisateur est dirigé sur la bonne page de destination, si
le contrôle est échoué, l’utilisateur se voit afficher un message d’erreur et une invitation à retourner en
arrière pour modifier les données envoyés.
En plus des pages présentés dans la figure précédente, il existe un certain nombre de fichiers utilitaires qui
contiennent des fonctions réutilisables et des blocs de présentation. Il s’agit en particulier des fichiers du
répertoire LIB (pour libraire de fonctions réutilisables, contenant les options de configuration du site, les
fonctions d’accès à la base de données et de gestion de la session, la logique de traitement du panier d’achats
etc.) et des fichiers contenant les barres de navigation (topbar.php, leftbar.php et catbar.php).
Page d’accueil
La figure suivante présente la page d’accueil et montre le modèle de page utilisé pour créer les différents
pages de l’application. Cette page est divisée en trois parties: une barre de navigation principale, présente
dans toutes les pages et donnant accès direct à un certain nombre de pages importantes, une barre de
navigation secondaire donnant accès direct aux catégories du catalogue et une partie réservée au véritable
contenu de la page, dans ce cas une image présentant les liens vers les catégories de produits.
La barre de navigation principale (topbar.php) est insérée dans toutes les pages de l’application et est utilisée
pour donner un look cohérent aux différents pages et un accès rapide aux principales fonctionnalités de
l’application, en particulier vers la page d’accueil, la recherche par mots clé, l’enregistrement de l’utilisateur
(si l’utilisateur n’est pas encore enregistré) ou la consultation du compte personnel (si l’utilisateur est
enregistré), le panier d’achats et l’aide en ligne.
La barre de navigation catégorielle (leftbar.php, catbar.php dans les pages autres que la page d’accueil), est
aussi inséré dans toutes les pages pour donner un rapide accès aux différentes catégories du catalogue. Cette
barre est générée au moment de la requête en interrogeant la base de données pour savoir quelles sont les
catégories disponibles et en affichant les images qui leur sont associés (et qui ont été créés automatiquement
au moment de la création de chaque catégorie).
- 95 -
L’espace dédié à la page est ensuite rempli avec les informations pertinentes à chaque page.
Catalogue
La figure suivante vous montre le modèle de page permettant de naviguer à travers le catalogue. Le design de
cette page, ainsi que celui des autres pages de l’application excepté la page d’accueil, est légèrement
différent de celui présenté précédemment à cause du fait que la barre de navigation catégorielle est placée en
haut juste en dessus de la barre de navigation principale afin de laisser plus d’espace pour l’affichage des
tableaux contenant les informations à afficher à l’utilisateur.
Dans cette page on voit la même barre de navigation principale, la barre de navigation catégorielle réduite et
l’écran principal. La page de navigation du catalogue présente la possibilité d’effectuer une recherche
hiérarchique (de type arborescence) à travers le catalogue de l’entreprise. La hiérarchie retenue est formée
par 3 niveaux de détail: catégorie (category), famille de produits (product) et unité de stockage (item). A
chacun de ces niveau sont liées une table dans la base de données qui contiennent les informations
appropriées à afficher ainsi que les informations nécessaires pour pouvoir constituer la hiérarchie.
L’écran principal est composé d’un titre indiquant où l’on se trouve dans la hiérarchie, un tableau contenant
les produits contenus dans la base de données qui correspondent à la catégorie demandée et auxquels sont
associés les liens nécessaires pour avancer de niveau de détail dans la hiérarchie et pour ajouter le produit
sélectionné dans le panier (si on est au niveau unité de stockage) et une troisième partie composée d’un lien
permettant de remonter d’un niveau dans la hiérarchie.
Panier d’achats
Cette page montre à l’utilisateur le contenu de son panier d’achats, c’est à dire les produits qu’il a décidé
d’ajouter à sa liste de courses au cours de ses actions précédentes. Pour chaque produit dans le panier, une
ligne est rajoutée au tableau, indiquant le nom du produit, le coût unitaire, la quantité dans le panier, le coût
total. Chaque ligne contient aussi un champs de formulaire permettant de mettre à jour la quantité du produit
et un lient permettant de l’enlever du panier.
- 96 -
Afin de garder en mémoire la liste des produits commandés au cours des interactions précédentes, il est
indispensable de pouvoir utiliser un mécanisme de gestion de sessions pour surmonter la limitation du
protocole HTTP qui ne les supporte pas. PHP donne deux possibilités principales pour gérer les sessions:
employer des variables de session et gérer ses propres variables à travers une base de données par le moyen
d’un identifiant unique pour chaque utilisateur. La solution choisie cette application est la deuxième, avec
l’enregistrement de la session dans la table orders et des lignes dans la table lineitem.
Recherche
Le moteur de recherche construit dans l’application permet d’effectuer des recherches sur le catalogue des
produits par mot clé. Ce moteur permet d’effectuer des recherches en utilisant plusieurs mots clé et de
spécifier que certains mots ne doivent pas être présents dans les résultats en les précédant su signe « - ». Les
produits trouvés sont ensuite présentés dans un tableau dans lequel des liens permettent d’aller vers les pages
de détail des produits ou d’ajouter le produit au panier d’achats.
Passage d’ordres
L’application prévoit une série d’étapes obligées par lesquelles passer son ordre. En particulier l’utilisateur
doit consulter son panier d’achats et choisir le lien lui permettant de passer son ordre.
L’application contrôle ensuite si l’utilisateur s’est déjà enregistré comme utilisateur connu: si tel est le cas,
l’utilisateur est dirigé directement à l’étape suivante, dans le cas contraire il doit passer par l’étape
d’enregistrement avant de procéder.
L’étape suivante est l’envoi des informations permettant de livrer l’ordre. Le formulaire utilisé pour les
collecter est pré-rempli avec les données que l’utilisateur a enregistrées dans son compte personnel. Si les
données de facturation sont les mêmes, l’utilisateur à la possibilité de le spécifier et sauter ainsi une autre
formulaire à remplir avec les donnes de facturation. Une fois les données envoyées, une page de validation
est appelée pour s’assurer que toutes les données sont remplies et apparemment correctes. Si aucun erreur
n’est détectée, l’utilisateur est prié de confirmer son ordre. Une fois l’ordre confirmé, l’utilisateur et
l’administrateur sont avisés par le biais d’un e-mail qui contient un récapitulatif de l’ordre passé.
11.3 Module Administration
Le module d’administration, qui n’a pas pu être inspirée de l’application de référence Java Pet Store à cause
de problèmes techniques, a pour but de fournir à l’administrateur du site la possibilité de gérer la base de
données. Il comprend notamment 3 fonctionnalités principales : la gestion du catalogue, la gestion des ordres
et la gestion du stock.
Tout le module administration est protégé par mot de passe contre l’accès par des utilisateurs occasionnels:
lorsque l’utilisateur n’est pas identifié, il est immédiatement redirigé vers la page de signature. Une fois
- 97 -
enregistré un utilisateur authentifié comme ayant les privilèges d’administrateur est renvoyé sur la page
d’accueil. Cette page ne contient que les liens vers les trois sections principales : catalogue, ordres, stock.
Enregistrement
Signin.php
Validatio
Page d’accuel
Signin.php
Stock
AdminStock.php
Ordres
AdminOrders.php
Catalogue
Catégorie
Produit
AdminProduct.php
Insert
Update
Delete
Insert
Update
Delete
Insert
Update
Delete
Figure 2 : Structure du module d’administration.
La première est la section la plus grande du module. Elle est constituée d’une série de pages qui permettent
de naviguer à travers la hiérarchie du catalogue et offrent la possibilité à chaque niveau d’insérer, mettre à
jour et effacer des produits.
La deuxième sert à gérer les ordres reçus. Les ordres reçus doivent passer par un ensemble d’étapes avant
d’être complétés: au début les ordres passés dans la partie utilisateur sont mis en attente de décision
l’administrateur peut accepter l’ordre ou le refuser. Dans le premier cas, l’administrateur obtient le payement
et envoie l’ordre et ce dernier est considéré compété. Un message de confirmation est envoyé au client
lorsque l’ordre est envoyé ou si l’ordre est refusé. Les ordres complétés et refusés sont archivés dans la base
de données dans des tables historiques et leur contrepartie dans les tables courantes sont effacées.
La troisième sert à changer le niveau de stock de chaque produit (qui est mis à jour automatiquement lorsque
les ordres sont complétés) et peut être employée suite à des livraisons par les fournisseurs ou à d’autres
évènements qui ont de l’influence sur le niveau de l’inventaire.
11.4 Base de données
La base de données utilisée est MySQL 3.23.40 sur Windows ’98. Cette base de données pour
l’environnement Microsoft a le grand avantage d’être gratuite et pleinement supportée par PHP, cependant
elle manque d’un certain nombre de fonctionnalités qui auraient été utiles, notamment la gestion des
transactions, les règles d’intégrité et le recouvrement en cas de panne.
L’application prend à sa charge un certain nombre des limitations de la base de données, notamment pour ce
qui concerne l’implémentation d’un certain nombre de règles d’intégrité.
La base de données de cette application reprend le schéma de base de données de l’application Java PetStore
et le simplifie ultérieurement. Le schéma de la base a une structure de tables assez simple. Cette structure est
représentée dans la figure suivante.
- 98 -
Les trois tables Item, Product et Category constituent le catalogue de produits de l’entreprise. Ce catalogue
est hiérarchisé en trois niveaux: le niveau le plus général est la catégorie, qui contient des produits, qui à leur
tour contiennent des unités de stockage.
La table Account contient un certain nombre informations sur les comptes des clients, en particulier le nom
utilisateur, le mot de passe et l’adresse e-mail. Cette table contient également les informations utiles pour
pré-remplir le formulaire de demande d’informations pour la livraison des produits.
Enfin, les deux tables Ordres et LineItem contiennent les ordres passés par les clients ainsi que les
informations permettant de construire le panier d’achats.
- 99 -