Le besoin en solutions intégrées

de données ou une JVM si le logiciel n’est pas implémenté –
au moins partiellement—dans les couches les plus basses du LIC (Licensed Internal
Code).
Si vous doutez de cette affirmation, rappelez-vous qu’aucun autre SGBDR n’a jamais
été porté sur AS/400, et que la JVM initiale, celle qu’IBM avait portée pour qu’elle
tourne au dessus de l’OS/400 fonctionnait très mal.

L’une des raisons essentielles des bonnes performances actuelles de la JVM AS/400
est que les applications Java sont en fait converties en code machine et exécutent
des flots d’instructions similaires aux programmes de service AS/400 standards.
Aucune JVM d’un éditeur tiers n’aurait pu utiliser la même technique sans remettre
en question la propriété essentielle de Java, à  savoir sa faculté à  tourner sur
toutes les plates-formes.

Mais il ne s’agit pas simplement de performances. Les sécurités et l’intégrité
de tout premier ordre fournies par les applications AS/400 utilisant des fichiers
UDB/400 dépendent de l’intégration fonctionnelle de la base de données avec le
reste du système d’exploitation à  différents niveaux, dont beaucoup au dessous
de la TIMI (Technology-Independent Machine Interface).

Oracle, par exemple, ne pourrait pas simplement porter son moteur de base de données
sur l’AS/400 et fournir le même genre de possibilités intégrées. Si l’on tient
compte de l’architecture de l’AS/400 et de l’histoire d’autres logiciels système
AS/400, il paraît raisonnable de conclure que toute portion de logiciel système
critique pour les performances doit être intégrée à  l’OS/400 pour être compétitive.
Par “ intégrée ” je veux dire que le code du logiciel système (WebSphere) et le
code interne de l’AS/400 sont développés de manière étroitement coordonnée, pour
que les différentes voies logicielles résultantes soient optimisées. Ce type de
coordination est également nécessaire pour refléter les fonctionnalités AS/400
au sein du logiciel système, et gagner ainsi des avantages compétitifs.

L’optimiseur de code AS/400 peut par exemple être appliqué aux applications Java,
un avantage unique de la JVM AS/400, qui ne présente aucun des problèmes de comportement
des JVM non-standard. Il est peu vraisemblable que ce type de développement de
code extrêmement étroitement coordonné puisse se faire entre les développeurs
internes d’IBM et l’un quelconque des autres éditeurs travaillant sur un serveur
EJB. Ainsi WebSphere, en tant que produit IBM, constitue-t-il notre seule chance
de connaître un serveur EJB intégré.