des applications dynamiques pour Internet et Intranet

WebObjects :
des applications dynamiques
pour Internet et Intranet
Approche technologique
Apple Entreprise Software & Services
Juin 1998
Sommaire
Synthèse
4
WebObjects, des besoins aux solutions
6
Cahier de charges pour un environnement adapté
au développement de serveurs applicatifs sur le Web. . . . . . . . . . . . . . . . . . . . 6
WebObjects face aux besoins.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Introduction technique à WebObjects
11
Points forts de WebObjects pour le développeur.. . . . . . . . . . . . . . . . . . . . . . .
Structure d’une application WebObjects . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Exemple d’une application WebObjects . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
13
14
16
Sommaire
Synthèse
Le besoin d’un outil de développement destiné à construire des applications Web dynamiques provient de la convergence de deux phénomènes. D’une part, l’audience croissante d’Internet ouvre aux entreprises un marché potentiel colossal qui nécessite cependant des outils de communication ad hoc. D’autre part, la banalisation (et le faible coût)
des protocoles et logiciels, destinés initialement à Internet, fait des solutions de type
intranet un choix économiquement et fonctionnellement bien plus avantageux que ne le
sont les applications client/serveur traditionnelles.
Cependant, autant la construction d’un site Web statique est simple et requiert seulement un bon logiciel de création de pages et un bon graphiste, autant celle d’une
“application Web” dynamique est complexe et demande un travail de développement
logiciel stricto sensu.
Les interrogations les plus fréquemment soulevées lors de tels projets sont :
• Faut-il remettre en cause l’équipement ou la politique d’équipement informatique ?
• Est-il possible de réutiliser les investissements déjà consentis en développement
de solutions client/serveur traditionnelles ? En constitution de bases de données ?
• Est-il possible d’utiliser les services d’un logiciel spécialisé déjà acquis par l’entreprise ou faut-il tout réinventer ?
• Faut-il acheter dès le départ un serveur Web puissant (et cher !) pour prévoir une
éventuelle montée en charge dans le futur ? Faudra-t-il le jeter et le remplacer par
un serveur encore plus puissant si un grand nombre de clients utilise le service ?
Apple répond à ces besoins en proposant WebObjects, un outil conçu pour permettre
aux entreprises de développer des applications serveur dynamiques robustes pour le
Web. Ces applications dynamiques peuvent être utilisées tant sur les réseaux Intranet que
sur le réseau Internet.
WebObjects est conçu de manière à protéger et réutiliser les investissements en ressources informatiques déjà effectués. Les applications WebObjects utilisent les technologies et données préexistantes, de l’ordinateur de bureau au système central.
WebObjects est une architecture ouverte, gérant les principaux outils du Web (navigateurs, serveurs HTTP, langages de programmation par scripts tels que Java et Perl, etc.)
et capable de s’adapter à l’émergence de nouvelles technologies.
Une application Web robuste doit pouvoir traiter l’information de façon fiable et
sécurisée. WebObjects permet de satisfaire à ces exigences grâce à une technologie
éprouvée et au support des principales normes de sécurité.
4
Introduction
Un service basé sur une application WebObjects peut monter en charge progressivement ; l’augmentation de la puissance du serveur n’implique pas le remplacement du
serveur mais simplement l’ajout de postes supplémentaires.
WebObjects offre un environnement de développement modulaire et structurant,
doté de fonctionnalités primitives de très haut niveau. Le développement est rapide,
centré sur la seule logique propre à l’entreprise et produit du code réutilisable.
Cette approche technologique explique comment WebObjects répond aux besoins
des développeurs et des administrateurs de solutions Web dynamiques. Il montre
en particulier comment WebObjects aide les entreprises à transformer un service
client/serveur en service intranet, extranet ou Internet sans induire de complexité ou
de coûts inutiles.
Introduction
5
WebObjects, des besoins
aux solutions
WebObjects est conçu pour permettre aux entreprises de créer des serveurs dynamiques
pour le World Wide Web. Ces applications peuvent être exploitées tant sur le réseau
interne d’une entreprise (“intranet”) que sur Internet. WebObjects est particulièrement
adapté aux applications complexes destinées à être utilisées par un grand nombre de
clients. WebObjects est également conçu pour préserver les investissements des entreprises dans le matériel et les technologies informatiques, les données et la formation.
Cahier de charges pour un environnement adapté au
développement de serveurs applicatifs sur le Web.
Nombreuses sont les entreprises qui souhaitent créer des applications Web élaborées
afin d’améliorer leur productivité, de mieux répondre aux besoins de leurs clients et augmenter le périmètre de leur clientèle. Cependant, ces objectifs sont difficiles à atteindre ;
le développement et l’exploitation d’applications Web robustes sont souvent difficiles et
coûteux car les outils de développement actuels ne permettent pas :
• de réutiliser les investissements déjà effectués dans les applications et données ;
• d’ajouter aisément une logique ou une algorithmique à une application Web, en
particulier lorsque la logique est créée à l’aide d’outils externes ;
• de prototyper et mettre en ligne rapidement une solution afin de la tester et la
faire évoluer en temps réel ;
• un passage simple du prototype au serveur en exploitation car la plupart des
solutions ne peuvent pas monter en charge progressivement.
Préserver les investissements en développement
Une bonne solution doit être capable de réutiliser la logique déjà développée (par
exemple sous forme de logiciel sur un système central), autant pour des raisons économiques que fonctionnelles (le test et le perfectionnement de l’application ayant déjà été
faits, la fiabilité de l’application Web en tirera profit).
Pour prendre un exemple, une application Web peut être créée pour rendre un
système de traitement des commandes sur système central accessible via le Web. Ainsi,
les clients peuvent placer et suivre leurs commandes directement via Internet, les
employés traitant ces mêmes commandes à l’aide du logiciel préexistant (auquel ils ont
déjà été formés).
Préserver les investissements en matériel et logiciel serveur
L’application Web doit être indépendante à la fois du système informatique et du
logiciel serveur HTTP de sorte que l’entreprise ait toute latitude de choisir ces éléments.
Ce point est en particulier important pour une entreprise ayant déjà investi dans un
site serveur Web.
6
WebObjects, des besoins aux solutions
Quant à l’application Web elle-même, elle doit fonctionner sur un échantillonnage raisonnablement large de systèmes d’exploitation du marché afin de permettre à l’entreprise
de réutiliser du matériel existant et/ou d’avoir libre choix de sa politique d’équipement.
Préserver les investissements en bases de données
L’application Web doit être indépendante du choix du serveur de base de données afin
de préserver le cas échéant un investissement déjà fait (en solution, en formation et/ou
en structuration et création de données) et de laisser l’entreprise libre de sa politique
d’équipement en ce domaine. De plus, le développement de l’application Web ne
devrait pas nécessiter un développement dans le système de gestion de la base de
données afin
a - d’éviter que les performances du site Web dépendent des performances d’un programme écrit dans le gestionnaire de base de données ;
b - de ne pas créer de dépendance forte entre l’application Web et le choix du logiciel
serveur de base de données (si l’entreprise souhaite changer de logiciel serveur et si
seules les données sont gérées par ce logiciel, un export/import des tables de données est suffisant ; si un développement avait été fait sur le SGBD, un portage logiciel au sens strict aurait été nécessaire).
Minimiser le temps de développement
Une application Web se compose de plusieurs parties qui sont conceptuellement très
indépendantes :
• les pages HTML et/ou les applets Java et/ou les contrôles ActiveX (“l’interface”) ;
• la logique de contrôle de l’interface ;
• l’accès à une (ou plusieurs) base(s) de données ;
• la logique des données (valeurs calculées, validation, contrôle de cohérence…) ;
• les mécanismes relevant strictement du protocole HTTP (relations avec le serveur
HTTP, protocoles de sécurité, mécanisme de gestion de “sessions” identifiées …).
Un bon outil de développement doit d’une part fournir le plus grand nombre possible d’éléments déjà construits afin d’éviter au développeur de les réinventer, d’autre
part séparer explicitement les parties indépendantes de sorte à maximiser la réutilisation
de code et permettre le développement efficace en équipe.
Monter incrémentalement en charge
Afin de simplifier d’une part la passage du prototype à un site de test puis de production, d’autre part la maintenance d’un site déjà en production (en particulier lorsque le
nombre d’usagers augmente), un bon environnement doit permettre la construction
d’un “serveur incrémental”. Idéalement, un tel serveur peut monter en charge autant
que nécessaire par l’ajoût chaque fois que nécessaire d’une machine supplémentaire.
WebObjects face aux besoins.
WebObjects a été conçu pour être utilisé par tous les développeurs d’applications Web,
notamment les services d’informatique interne, les Webmasters d’entreprise ou indépendants et les fournisseurs de services Internet.
Schématiquement, WebObjects permet aux développeurs :
• de bâtir des applications Web interopérables avec les logiciels et architectures logicielles existants ;
WebObjects, des besoins aux solutions
7
• de créer des applications Web robustes, destinées tant aux réseaux intranet qu’au
réseau Internet ;
• de créer rapidement des applications Web élaborées procurant un avantage
concurrentiel à l’entreprise ;
• de déployer l’application Web progressivement en réutilisant les investissements
consentis en serveurs.
Dans la suite de cette section, nous présentons point par point les principaux avantages
de WebObjects.
Une technologie ouverte
WebObjects est une technologie ouverte fonctionnant avec les produits de nombreux
éditeurs et fabricants, procurant ainsi aux développeurs un vaste choix d’outils pour la
création d’applications Web. En comparaison, les outils de développement Web existants
offrent peu de flexibilité vis-à-vis de produits de tierces parties. Ce point est essentiel car
il préserve les choix et les investissements informatiques des entreprises.
WebObjects est ouvert dans les domaines suivants :
Navigateurs
WebObjects fonctionne quels que soient les navigateurs utilisés sur les postes clients
(e.g. les produits Netscape, Spry, Microsoft, NCSA et SpyGlass). Une telle indépendance
est primordiale pour les entreprises désirant toucher la plus large clientèle possible sur
Internet tout en minimisant les coûts de diffusion.
En outre, WebObjects permet d’exploiter les fonctionnalités avancées des outils
de navigation telles que les applets Java, les versions actuelles et futures de HTML,
ActiveX, les SSL etc.
Serveurs HTTP
WebObjects permet d’utiliser la plupart des serveurs HTTP. En effet, le lien entre les
applications WebObjects et le serveur HTTP repose sur l’interface CGI (norme supportée par l’immense majorité des logiciels serveur HTTP du commerce). Il est également
possible, sans aucune programmation additionnelle, d’utiliser à la place de l’interface
CGI une des interfaces NSAPI (Netscape) ou ISAPI (Microsoft) (ces dernières présentent
de meilleures performances).
Bases de données
Les applications WebObjects peuvent accéder de manière transparente à de multiples
sources de données ; par exemple, elles accèdent de manière native aux bases Oracle,
Sybase et Informix. Une entreprise peut ainsi exploiter ses bases préexistantes depuis
l’application WebObjects, quelles que soient les machines utilisées comme serveurs de
bases de données. De plus, les applications WebObjects peuvent combiner des informations provenant de diverses bases de données. Par exemple, un catalogue virtuel pourrait afficher la liste des articles disponibles, répertoriés dans une base de données
Oracle, ainsi que les prix de ces articles, stockés dans une base de données Sybase.
L’accès à des bases de données moins courantes - telles que DB/2 - est également
possible au moyen de produits tiers. Enfin, le support de ODBC permet d’utiliser de
nombreux autres serveurs du commerce (e.g. Microsoft Access).
8
WebObjects, des besoins aux solutions
Systèmes d’exploitation
WebObjects fonctionne à l’identique sur n’importe lequel des systèmes d’exploitation
supportés ; à ce jour, il s’agit de
• Windows NT
• Solaris
• HP/UX
• OpenStep pour Mach.
Ainsi, les applications WebObjects peuvent être déployées sur des serveurs existants ou
être portées ultérieurement sur d’autres plate-formes pour répondre à de nouveaux besoins.
Technologies objet tierces
WebObjects est interopérable avec plusieurs technologies objet classiques. En particulier,
les applications WebObjects peuvent coopérer avec des applications Windows basées sur
OLE. De plus, les serveurs WebObjects peuvent communiquer avec les objets CORBA
2.0, permettant ainsi l’usage de services de tels objets dans une page Web, ainsi qu’avec
les Objets Java via RMI.
Réutilisation des applications existantes
WebObjects est conçu pour tirer parti des investissements déjà effectués en applications.
Les entreprises peuvent concevoir et déployer des applications Web dynamiques tout en
continuant à utiliser leurs systèmes administratifs existants.
WebObjects est notamment interopérable avec les logiciels suivants :
Applications Windows
Les applications WebObjects peuvent communiquer avec toute application fondée sur
OLE gérant OLE Automation (e.g. les applications de Microsoft Office) permettant ainsi
aux applications Windows de partager des informations avec des applications Web. Par
exemple, les applications WebObjects peuvent utiliser des données existantes saisies ou
calculées dans des feuilles de calcul Microsoft Excel.
Applications sur systèmes centraux
Grâce à WebObjects et aux partenaires de Apple tels que Yrrid, les développeurs peuvent
utiliser depuis les applications Web les services (ou les données) d’une (ou plusieurs !)
application(s) sur site central (par exemple en simulant une connexion type 3270, 5250
ou VT, donc sans toucher à l’application elle-même) .
Création d’applications Web robustes
Une application Web robuste doit pouvoir traiter l’information de façon fiable, sécurisée
et indépendante de la charge. WebObjects le permet grâce à une technologie éprouvée,
à la gestion de normes de sécurité et à une architecture de déploiement modulaire.
Utilisation de technologies éprouvées
WebObjects est fondé sur des technologies ayant fait leurs preuves : les architectures et
bibliothèques objet créées par NeXT et utilisés dans le monde entier depuis treize ans
pour la construction d’applicatifs et d’outils de type client/serveur.
Sécurité
WebObjects gère des normes de sécurité telles que SSL et SHTTP. De plus, puisque
WebObjects fonctionne avec les serveurs HTTP existants, les applications WebObjects
peuvent également utiliser tout système de sécurité géré par ces serveurs.
L’authentification des requêtes et les pare-feux (firewall) sont également supportés, vous
permettant ainsi de faire des affaires en toute sécurité via le Web.
WebObjects, des besoins aux solutions
9
Machines clientes
(équipées d’un navigateur Web)
I n t e r n e t
Serveur(s) HTTP
n
tio
ibu
r
t
s
Di
App
Weblication
Obje s
cts
hes
tac
s
de
App
Weblication
Obje s
cts
App
Weblication
Obje s
cts
App
Weblication
Obje s
cts
ées
onnices
d
aux erv
ès aux s
c
c
A /ou
Serv
et
ic
de es
de dbases
onn
ées
Ap
s plic
cenur sit atio
tra e n
l
Modularité et montée en charge incrémentale
WebObjects permet aux entreprises de créer des serveurs Web répartis. Ainsi, les
requêtes à traiter peuvent être distribuées entre plusieurs instances de l’application
WebObjects (situées si nécessaire sur des machines différentes), ce qui entraîne la possibilité de traiter un nombre quelconque de requêtes provenant du Web, modulo le
déploiement d’autant de machines que nécessaire.
De plus, un tel serveur réparti présente une meilleure tolérance aux pannes puisque
le dysfonctionnement d’une instance ne provoque pas l’arrêt du service.
Développement rapide d’applications
Avec WebObjects, il est possible de développer rapidement des applications Web complexes pour les entreprises. En effet :
a - WebObjects fournit immédiatement les services qui sont en général complexes à
implémenter (accès aux bases de données, relations avec le serveur HTTP, gestion
de sessions) ;
b - l’interface (les pages HTML avec éventuellement des applets Java) est bâtie à l’aide
d’un outil graphique qui permet également d’établir par clic de souris les liens entre
l’interface et sa logique de contrôle ;
c - la logique (logique de contrôle et logique des données) est construite par programmation objet ce qui offre les avantages de modularité, de réutilisabilité du code et
de maintenance simplifiée.
Conclusion
Internet est un environnement en perpétuel changement et les entreprises s’efforcent de
tirer le maximum de cet outil de communication révolutionnaire. Apple leur propose un
moyen de créer des applications Web dynamiques qui préservent les investissements déjà
effectués. Grâce à WebObjects, les Webmasters et professionnels de l’informatique peuvent tirer parti de la puissance du Web afin d’améliorer la productivité. Le caractère dynamique et la réactivité de WebObjects ouvrent ainsi un champs de services innovants et
permettent aux entreprises de mieux répondre à la clientèle et d’augmenter leur volume
d’affaires.
10
WebObjects, des besoins aux solutions
Introduction technique
à WebObjects
Points forts de WebObjects pour le développeur.
La création d’applications Web dynamiques présente, par rapport aux solutions
client/serveur traditionnelles, trois difficultés majeures :
• La charge supportée par le serveur ;
• La création “à la volée” de pages HTML calculées ;
• La notion de “session” liée à un usager.
De ces trois points, le dernier est à la fois le plus important et le plus difficile à
résoudre ; en effet, le protocole HTTP travaille dans un mode “non connecté” : chaque
transaction est indépendante des autres et il n’y a même aucune méthode simple pour
identifier, depuis le serveur, les transactions d’un usager particulier.
Or, aucune application de type “client/serveur” un tant soit peu complexe ne peut
se passer d’une notion de “session” pendant laquelle des informations perdurent (par
exemple, l’identification du client, la liste des achats déjà effectués, une récapitulation de
son compte etc.).
Diverses solutions techniques ont été proposées dont aucune n’est simple à implémenter si l’outil de développement ne la propose pas toute faite.
Dans les pages qui suivent, vous constaterez comment WebObjects résout ces difficultés et aurez une vue d’ensemble du processus de développement d’une application
Web à l’aide de WebObjects.
Montée en charge d’un serveur Web
Un serveur Web est analogue à un site central entouré de terminaux passifs.
Pratiquement toutes les opérations de traitement sont effectuées sur le serveur, qui doit
répondre à toutes les requêtes. La charge (nombre de requêtes et/ou complexité des
traitements demandés) qu’il peut supporter est donc limitée par l’ordinateur et le système d’exploitation choisi. Lorsque cette charge maximale est atteinte, le serveur ralentit
et/ou refuse les requêtes additionnelles, voire s’effondre. Pour que l’exploitation d’applications Web efficaces soit possible, ce problème doit être résolu.
Pour les sites relativement peu chargés, l’application WebObjects peut être installée
sur le même système que le serveur HTTP. Cependant, si le nombre de requêtes croît, l’application WebObjects peut être installée sur un serveur distinct (un “serveur applicatif ”).
Au fur et à mesure que la charge croît, il est possible d’ajouter d’autres serveurs applicatifs.
WebObjects contient en effet un module logiciel (un “répartiteur”) qui distribue les
requêtes entre les serveurs applicatifs disponibles. Le répartiteur est installé sur la même
Introduction technique à WebObjects
11
machine que le serveur HTTP ; il est entièrement portable et peut fonctionner sous de
nombreux systèmes d’exploitation. Le produit WebObjects contient ce module logiciel
compilé pour les systèmes Solaris, HP-UX, OpenStep pour Mach et Windows NT (les
sources sont livrées pour recompilation sur d’autres systèmes si nécessaire).
SGB
API
du
D
SGB
D
Serveur de
base de données
Grâce à ce répartiteur, les administrateurs d’applications Web peuvent augmenter à
volonté la tenue en charge du “site serveur” en ajoutant de nouvelles machines au fur et à
mesure des besoins, sans même avoir à interrompre le fonctionnement des autres serveurs. Ce mode de fonctionnement simplifie également la maintenance : si un des serveurs
d’application Web cesse de fonctionner ou doit être éteint pour subir des réparations, les
autres n’en seront aucunement affectés et le service continuera à être disponible.
Logic
serv iel
e
HTTur
P
CGI
so Logi
de sus formque
crip e
t
Serveur HTTP
Le schéma montre trois exemples d’architecture de serveur Web. L’architecture en
trois couches de WebObjects permet d’isoler la logique de traitement du service HTTP et
du service de données - et donc d’augmenter incrémentalement la tenue en charge du serveur - ce qui devient très difficile, voire impossible, dans les autres cas.
Architecture traditionnelle en deux couches,
basées sur une CGI programmable
SGB
D
API
du
Log
SGB
i
q
D
pro formeue so
sto cédu de us
cké res
es
Serveur de
base de données
Logic
serv iel
e
HTTur
P
C
gén GI
ériq
ue
L’utilisation de serveurs d’application Web indépendants procure l’avantage supplémentaire de libérer le serveur HTTP de toutes les tâches autres que le service de requêtes
proprement dit. En utilisant un serveur HTTP solide sur un système présentant une bonne
tenue en charge, il est en général possible d’éviter d’avoir à déployer des serveurs HTTP
supplémentaires. Si cela devient nécessaire, le mécanisme de distribution de charge entre
les serveurs d’application Web continue à fonctionner : on a plusieurs “répartiteurs” (un
sur chaque poste serveur HTTP) dont chacun distribue les requêtes vers les applications
WebObjects disponibles.
Serveur HTTP
Création de pages Web dynamiques
Architecture traditionnelle en deux couches, reposant sur une base de données disposant d’un frontal HTML
SGB
D
Serveur de
base de données
d Lo
en évelo gique
lan pp
(Jav
a ou obje gage ée
t
O
bjec
tice
C)
Serveur
applicatif
Logic
serv iel
e
HTTur
P
C
gén GI
ériq
ue
Serveur HTTP
Architecture WebObjects en trois couches
L’interface utilisateur des applications Web est constituée de divers éléments HTML. Par
conséquent, un logiciel qui souhaite créer ses pages d’interface dynamiquement doit
engendrer du code source HTML ; les outils traditionnellement utilisés à cet effet (e.g.
CGI programmables) prennent ce parti : le programmeur écrit le code qui produit du
code HTML.
Sous WebObjects, les éléments de l’interface sont des objets (au sens de la programmation objet) que l’on appelle des “composants”. Par exemple, un “composant-page”
contient des composants secondaires tels qu’une image ou un formulaire. Ces composants, analogues en cela à des éléments d’interface (e.g. contrôles) dans un environnement
de construction d’interface plus traditionnel, sont capables de “se dessiner”, c’est à dire
engendrer le code HTML nécessaire. Le programmeur peut les manipuler en ignorant totalement la génération du code HTML, il peut également les sous-classer pour modifier radicalement leur comportement si besoin est.
Le “composant-page” se dessine en forçant le dessin de tous les composants qu’il
contient (récursivement si nécessaire). L’application WebObjects renvoie au serveur HTTP
le source HTML qui en résulte et qui est totalement banal (qui ne contient en particulier ni
balise exotique ni code d’accès à des bases de données). Par cette approche, WebObjects
sépare clairement l’interface et le traitement ; la maintenabilité et l’évolutivité de l’application en sont grandement améliorées.
12
Introduction technique à WebObjects
Suivi des sessions
Pour être utile, une application Web doit être en mesure de suivre un utilisateur donné
parmi toutes les requêtes qu’elle reçoit. Par exemple, une application permettant d’effectuer des achats sur le Web doit pouvoir garder en mémoire les articles sélectionnés
par l’utilisateur. À mesure que l’utilisateur explore différents emplacements du site Web
et sélectionne des articles, l’application doit garder en mémoire les éléments sélectionnés. En d’autres mots, l’application Web doit posséder une notion de session allant de la
première requête à la “fin de connexion” de l’usager.
Ainsi que nous l’avons précisé plus haut, le suivi des sessions constitue l’une des plus
grandes difficultés du développement d’applications Web.
WebObjects offre un système de suivi des sessions complet permettant aux développeurs de manipuler des données accessibles à toute l’application, des données propres à
un client en particulier ou propres à une transaction HTTP spécifique. Le développeur
peut déclarer des variables comme dans tout environnement de programmation (il s’agira
donc de variables “de transaction”, “de session” ou “d’application”). WebObjects gère automatiquement ces variables, de façon transparente pour le développeur.
La méthode retenue est celle des “URL longs” car l’URL est la seule information dont
on garantie l’échange entre le navigateur et le serveur.
Structure d’une application WebObjects
Le protocole HTTP est basé sur le modèle “requête-réponse”, où l’utilisateur clique sur
un élément qui envoie une requête au serveur pour obtenir la page suivante. Le serveur
envoie alors la page demandée à l’utilisateur. WebObjects fonctionne selon le même
modèle - les applications créées avec WebObjects sont structurées en pages. Une application WebObjects typique se compose des ingrédients suivants :
Source HTML prototypique.
Les pages prototypiques sont écrites en langage HTML et elles définissent la structure et
la disposition des pages qui seront engendrées. Bien qu’elles puissent être totalement
statiques, en général elles contiennent des balises <WEBOBJECT> qui définissent les
points d’insertion des objets dynamiques et qui seront remplacées par du code HTML
calculé lors de l’exécution de l’application.
Les pages prototypiques peuvent être écrites à l’aide d’un simple éditeur de texte
mais sont le plus souvent engendrées automatiquement par un éditeur WYSIWYG livré
avec WebObjects, WebObjectsBuilder.
Fichiers de déclaration.
Les fichiers de déclarations établissent les liens entre les balises <WEBOBJECT> du
source HTML prototypique et les composants. Ces fichiers sont créés automatiquement
par WebObjectsBuilder (mais peuvent être écrits ou retouchés directement par le
programmeur dans Project Builder, le gestionnaire de projet livré avec WebObjects).
Scripts et/ou classes.
La programmation de la logique (de contrôle ou de traitement) est faite par le programmeur soit en langage interprété (WOScript), soit en langage compilé (Java ou Objective C).
Il est d’ailleurs possible de mélanger librement les trois langages de programmation à
Introduction technique à WebObjects
13
l’intérieur d’une même application. Selon les cas, l’application contiendra donc le source
WOScript destiné à être interprété à l’exécution et/ou du code binaire natif ou exécutable dans une machine virtuelle Java.
Exemple d’une application WebObjects
L’application de simulation d’emprunt décrite ci-dessous illustre les bases du développement WebObjects. Les pages dynamiques créées par le développeur pour cette application sont des exemples de pages typiques d’une application WebObjects.
Figure 1
La copie d’écran ci-contre montre la page d’accueil de l’application de simulation d’emprunt.
Cette page présente trois champs de saisie où l’utilisateur va entrer le montant à
emprunter, le taux et le nombre de mensualités pour le remboursement. Un clic sur le
bouton “Calculer” va alors déclencher la simulation du remboursement de l’emprunt en
fonction des paramètres saisis et une nouvelle page présentant l’échéancier va alors être
générée.
Figure 1
Figure 2
Par exemple si l’utilisateur saisit un montant de 14 000,00 F, un taux de 6 % et un remboursement sur 12 mensualités, voici la page qui va être renvoyée au navigateur.
Afin de réaliser toutes les étapes nécessaires, l’application de simulation d’emprunt
nécessite :
• la définition des variables de sessions (montant, taux, nombre de mensualités) ;
• une page de saisie des informations ;
• une page pour l’affichage et le calcul de l’échéancier.
Une description plus détaillée de ces étapes est donnée dans la suite de cet
exemple. Le langage de programmation choisi pour ce projet est Java.
Définition des variables de session
Les trois variables de sessions sont définies dans la classe Session comme suit :
public class Session extends WebSession {
double montant;
int
nombreDeMois;
double taux;
}
Figure 2
Page de saisie des informations
Cette page est créée en utilisant l’outil WebObjects Builder (figure 3) :
WebObjects Builder prend en charge la génération du source HTML prototypique ainsi
que du fichier de déclaration. À la figure 4 nous voyons la même page sous forme de
code source :
Figure 3
14
Introduction technique à WebObjects
Lorsque l’utilisateur clique sur le bouton “Calculer”, les valeurs entrées sont automatiquement associées aux variables de sessions puis la méthode calculerEmprunt est exécutée ; celle-ci se contente d’indiquer la page suivante à afficher. Le code de cette méthode
est le suivant :
public Component caculerEmprunt()
{
Component nextPage = application().pageWithName("Echeancier");
return nextPage;
}
Calcul de l’échéancier
Le calcul de l’échéancier relève stricto sensu de la “logique métier”. Il est implémenté
comme suit :
private double valeurEcheancePourEmprunt() {
double valeurEcheance = 0;
double tegReel;
double duree, somme;
long intermediaire;
Figure 4
duree = ((Session) session()).nombreDeMois;
somme = ((Session) session()).montant;
tegReel = 1.0 + ((Session) session()).taux / 1200;
valeurEcheance = Math.pow(tegReel, duree) * somme * ((tegReel-1)
/ (Math.pow(tegReel, duree)-1));
intermediaire = Math.round(valeurEcheance * 100);
valeurEcheance = ((double) intermediaire) / 100.0;
return valeurEcheance;
}
La création de la page d’affichage de l’échéancier se fait avec WebObjects Builder
(voir figure 5)
Cette page montre différents types de composants de WebObjects :
• des chaînes de caractères dynamiques : numéro d’échéance, le montant emprunté,
le taux, les intérêts remboursés, etc.
• une répétition d’une ligne du tableau pour permettre l’affichage dynamique du
nombre correct de lignes pour l’échéancier ;
• un lien hypertexte pour permettre le retour sur la page de saisie des informations.
Figure 5
Le développeur utilise l’outil ProjectBuilder (figure 6) pour saisir le code de l’application WebObjects, gérer ses sources et construire son application.
Cet outil coopère finement avec WebObjects Builder. ProjectBuilder permet de centraliser l’ensemble des ressources d’un projet, notamment
- les pages web prototypiques ;
- les classes propres à l’application ;
- les ressources statiques de l’application (images, son, …).
Figure 6
Introduction technique à WebObjects
15
Conclusion
WebObjects est le type même de l’outil nécessaire pour porter sur le Web des applications d’entreprise. Il permet d’une part de réutiliser une partie importante du travail déjà
effectué dans un éventuel développement client/serveur traditionnel, d’autre part de
programmer efficacement et rapidement de nouveaux algorithmes si besoin est. Il laisse
toute liberté à l’entreprise quant à ses choix informatiques (en particulier dans le domaine des bases de données et serveurs Web) et ces choix peuvent à tout moment être révisés sans mettre en péril les développements déjà effectués. Il pousse à une conception
modulaire et réutilisable du logiciel. Enfin, étant donnée la modularité d’un serveur
WebObjects déployé, le passage de l’intranet à un extranet ou à l’Internet est possible à
tout moment sans qu’il soit nécessaire de changer l’équipement informatique.
16
Introduction technique à WebObjects
Contact
Pour toute information technique ou commerciale, visitez notre site Web
http://www.euro.apple.com/webobjects
ou rendez-vous à l’adresse suivante
France et Europe du Sud
Apple Computer France
Apple Enterprise Software & Services
ZA de Courtabœuf 3
12, Avenue d’Océanie
F-91956 Les Ulis cedex
France
Tel : (+33) 1 69 86 34 00 • Fax : (+33) 1 69 86 90 94
Email : [email protected]
Suisse
Apple Computer Suisse SA
Centre du Bief
1110 Morges
Switzerland
Tel : (+00) 41 21 803 15 55 • Fax : (+00) 41 21 803 16 18
Royaume-Uni et Europe du Nord
Apple Computer UK Ltd
Apple Enterprise Software & Services
2, Furzeground Way
Stockley Park
Middlesex, UB11 1BB
UK
Tel : (+44) 181 218 10 01 • Fax : (+44) 181 218 10 71
Email : [email protected]
Apple Computer France
Z.A. de Courtabœuf - 12, avenue d'Océanie
91956 Les Ulis Cedex
©1998 Apple Computer France. Tous droits réservés. Apple, le logo Apple, Macintosh, Enterprise Objects, Objective-C, OPENSTEP, PDO, WebObjects et WebScript sont des marques d'Apple Computer Inc.,
déposées aux États-Unis et dans les autres pays. Les autres noms de produits et de sociétés mentionnés dans ce document sont des marques de leurs sociétés respectives.
Les références à des produits ou services non Apple ne sont là qu'à titre d'informations et ne constituent d'aucune façon une recommandation. Apple n'assume aucune responsabilité au regard de la sélection,
de la performance, ou l'utilisation de ces produits. Tout accord, agréments ou garanties, s'ils existent, doivent être pris directement entre les vendeurs et les utilisateurs.
SARL au capital de 20.000.000 F - RCS Corbeil Essonnes B 322 120 916
DFM2053
Allemagne et Europe Centrale
Apple Computer GmbH
Apple Enterprise Software & Services
Dornacher Str 3 D
D-85622 Feldkirchen
Germany
Tel : (+49) 89 99640-0 • Fax : (+49) 89 99640-24
Email : [email protected]