> Tech > Développement AS/400 et Web comparés

Développement AS/400 et Web comparés

Tech - Par iTPro - Publié le 24 juin 2010
email

Comme l'AS/400 a amplement démontré sa capacité à  traiter des applications de gestion critiques de manière sûre et fiable, il n'est pas étonnant que de nombreuses entreprises se tournent vers lui pour leurs applications Web importantes. Mais, pour bien bâtir une application Web sur AS/400, les programmeurs AS/400 doivent d'abord

Développement AS/400 et Web comparés

comprendre la différence entre des projets de développement AS/400 traditionnels
d’un côté, et sur le Web de l’autre.

Intervenants. En développement AS/400 traditionnel, les utilisateurs finaux soumettent
leurs besoins et desiderata aux programmeurs. Ceux-ci écrivent ou modifient le
code nécessaire et le livrent aux utilisateurs. Pour ces derniers, le développement
se résume généralement à  créer et exécuter des requêtes à  l’aide d’outils appropriés.

Dans le cas d’un développement Web, il est fréquent que des non-informaticiens
modifient les pages Web, qui font partie intégrante d’une application. Les Webmasters,
les gestionnaires de contenu, les responsables marketing et autres collaborateurs
peuvent tous mettre à  jour une application. La communication entre les départements
et la simplicité d’administration sont indispensables pour que les utilisateurs
d’un application Web travaillent dans de bonnes conditions.

Les développeurs Web sont souvent étonnés d’apprendre que beaucoup de sites réalisent
tous leurs développements AS/400 avec cinq programmeurs ou moins

Les développeurs en mode client/serveur et Web sont souvent étonnés d’apprendre
que beaucoup de grands comptes réalisent tous leurs développements AS/400 avec
cinq programmeurs ou moins. Et même les grands sites AS/400 dépassent rarement
les 25 personnes. Les sites client/serveur comptent souvent des centaines ou des
milliers de développeurs. Si on y ajoute les non informaticiens intervenant dans
les processus de développement, on voit que cela augmente considérablement les
problèmes de communication et d’organisation dans l’environnement de développement
et de maintenance des applications.

Complexité de l’environnement. Pour apprécier pleinement la belle homogénéité
de l’AS/400, il faut se lancer dans l’écriture d’une application basée Web. Dans
le monde AS/400, tout le monde utilise la même base de données et le même système
de sécurité. Les erreurs applicatives sont traitées de manière homogène, indépendamment
de l’auteur de l’application ou de ses techniques de programmation. Et comme l’OS/400
contrôle les interfaces applicatives, aucune application ne risque d’en détruire
une autre.

Pour bien comprendre la différence entre le développement AS/400 et Web, faisons
une analogie avec les différences existant entre un consommateur commandant un
café aujourd’hui et il y a 15 ans. A cette époque, on commandait simplement du
café, et c’est ce qu’on obtenait, parfois avec du lait et de sucre. Aujourd’hui,
il faut choisir : petit, moyen ou grand, normal ou décaféiné, expresso, cappuccino,
ou au lait, et ainsi de suite. Tous ces choix sont fort agréables, mais il devient
bien plus difficile de commander une tasse de café.

Dans l’environnement applicatif Web, la variété de choix des développeurs est
également stupéfiante : une plate-forme serveur d’application (OS/400, Unix, Windows
NT par exemple), un serveur d’application, un langage et des outils de développement,
comment traiter les requêtes adressées à  la base de données, comment gérer les
communications client et serveur, sans oublier le middleware.

Types d’objets. Dans le monde Web, le nombre de types d’objets requis dépasse
de loin celui des applications de gestion AS/400 traditionnelles. Les applications
Web peuvent comporter de multiples types d’images, vidéos, fichiers audio, tableurs
et documents. Et les développeurs Web doivent être capables de modifier, déplacer,
construire et gérer tous ces objets. De plus, on peut développer une application
Web avec un ou plusieurs langages, comme HTML et XML (Extensible Markup Language)
et des langages macro comme Net.Data.

Interdépendance des objets. La seule variété des langages de développement Web
complique le suivi des dépendances entre les objets Web. Sans parler du fait que
les applications Web peuvent utiliser des objets composites, c’est-à -dire des
objets contenant de nombreux composants. On peut par exemple trouver du HTML,
des images, des documents traitement de texte, tableur, des formulaires et des
applets Java dans une page Web. Et le développeur Web, avant de mettre à  jour
une page ou de tester une application, doit d’abord s’assurer qu’il possède tous
les composants appropriés.

Culture de développement. L’environnement de développement AS/400 repose sur un
modèle « serveur rapide », dans lequel la totalité, ou presque, du code d’une application
réside sur le serveur (l’AS/400). En cas de défaillance de l’application, des
départements entiers sont immobilisés. Les sociétés ne peuvent plus commander,
fabriquer, facturer ou payer le personnel. Dans le monde AS/400, la fiabilité
prend le pas sur la rapidité et la technologie. Il n’est donc pas étonnant que
les utilisateurs aient tendance à  se moquer du manque de fiabilité des systèmes
Windows, tandis que les utilisateurs Windows raillent la technologie AS/400, et
en particulier son interface utilisateur.

A l’inverse, en environnement Windows, les développeurs sont habitués à  une architecture
 » client lourd « , où la totalité, ou presque, du code d’une application réside
sur chacun des PC. En cas de défaillance de l’application, un seul utilisateur
est en principe touché, et peut généralement résoudre le problème en réinitialisant
le système. C’est pourquoi les développeurs d’applications Windows sont moins
préoccupés que les développeurs AS/400 par les défauts susceptibles de se glisser
jusqu’au stade de la production.

L’environnement de développement Web combine ces deux cultures. Bien que le développement
Web évolue rapidement pour offrir la toute dernière technologie aux utilisateurs,
c’est aussi un environnement serveur  » lourd  » dans lequel une défaillance peut
affecter des centaines, des milliers, parfois des millions d’utilisateurs. Pour
gérer les changements dans un tel environnement, il faut prendre en compte les
besoins des deux cultures.

Téléchargez gratuitement cette ressource

Les 7 étapes d’un projet de dématérialisation RH

Les 7 étapes d’un projet de dématérialisation RH

Dans ce livre blanc, nous vous donnons les clés pour concevoir votre projet de dématérialisation RH. Vous découvrirez chacune des étapes qui vous permettront d’apporter de nouveaux services aux collaborateurs, de vous adapter aux nouvelles pratiques et de renforcer la marque employeur.

Tech - Par iTPro - Publié le 24 juin 2010