Quelle a été la genèse de votre progiciel d’achat Buyer 7. 0, lancé il y a quatre ans ? La première version d’ORMS supportait dix utilisateurs sur Sun et quinze sur HP ! En partenariat avec ces constructeurs, les capacités de leurs JVM ont été augmentées. ORMS était un précurseur des serveurs d’applications Java d’aujourd’hui. Nous avons ajouté les fonctions multitâches natives – en particulier pour les entrées/sorties. Le modèle de serveur Java compilé a donné un serveur hautement transactionnel. A l’époque, nous étions seuls sur ce segment.Avez-vous rencontré des difficultés pour faire évoluer les classes Java ? Nous avons souffert de notre engagement précoce sur Java. Il y avait beaucoup de bugs dans les classes Java fournies par Sun. Pour les identifiants, les classes Java, utilisées pour l’accès aux catalogues, ne gèrent pas des nombres aléatoires de plus de huit caractères. Nous avons donc dû développer nos propres classes. Mais il était impossible de les porter à chaque nouvelle version de Java. C’est pourquoi nous nous sommes tournés vers BEA pour utiliser ses classes. Sinon, nous risquions de perdre en réactivité et de ne pas disposer d’une pile intégrée. Buyer 7. 0 fait aujourd’hui un emploi gradué du serveur d’applications Web Logic.Pourquoi Buyer 7.0 renonce-t-il à Java sur le client ? Depuis sa version 2. 0, Buyer fonctionne sur un mode dual Java et HTML. Pour optimiser la distribution d’objets Java, nous avons préféré développer notre propre protocole plutôt que prendre IIOP ou RMI. Mais la JVM était trop gourmande en mémoire, et nous éprouvions des difficultés à réduire la taille de l’applet. Par ailleurs, Netscape n’a pas fait évoluer assez rapidement ses classes AWT. La génération de contenu HTML par des pages JSP se fait maintenant en quasi-temps réel.Quel est le niveau d’intégration entre Buyer 7. 0 et vos offres de places de marché ? Buyer gère les échanges en XML depuis la version 4. 0. Les catalogues sont téléchargeables sur l’intranet de l’entreprise. Marketplace est fondé sur les offres de deux sociétés, que nous avons rachetées en fin d’année dernière : Trade’ex pour les places de marché, et Trading Dynamics pour les ventes aux enchères. Elles ne sont ni l’une ni l’autre conformes J2EE. Suppliersmarket, plus orienté vers les achats de matière première, nous apporte des outils de gestion collaborative des appels d’offres.Quel rôle va jouer le standard Uddi, que vous venez de lancer avec IBM et Microsoft ? Comme pour l’annuaire papier, Uddi décrit les pages blanches pour l’identité de l’entreprise, les pages jaunes pour son positionnement et, surtout, des pages vertes pour les services proposés. L’intégration de ces derniers est étroite, mais l’architecture reste souple. Cela s’apparente au modèle eSpeak de HP ou à celui de . NET de Microsoft. Uddi gère non seulement la présentation des données sous XML, mais aussi les couches basses d’initiation des sessions et de traitement de messages d’erreur, comme le fait déjà l’EDI. Uddi s’appuie sur les travaux de Microsoft sur SOAP. Les fournisseurs vont pouvoir homogénéiser leurs interconnexions aux places de marché.
Lanalyse de 01
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
