> Tech > Place aux composants middlewares

Place aux composants middlewares

Tech - Par Renaud ROSSET - Publié le 24 juin 2010
email

Du fait des difficultés de programmation qu'ils présentent, les plus anciens modèles de composants distribués cèdent rapidement le pas aux nouveaux modèles de composants middlewares, qui jouissent d'un large soutien. C'est tout particulièrement le cas pour le standard EJB. Plus de 30 éditeurs projettent de l'incorporer dans leurs serveurs d'applications

Place aux composants middlewares

Web, si ce n’est pas déjà  fait. Sur AS/400, BEA,
Bluestone et Novera supportent les EJB. En ce qui concerne IBM, ce support vient
d’être ajouté à  WebSphere.

En dépit du support qu’ils ont déjà  recueilli, les modèles de composants middleware
continuent d’évoluer. En fait, comme cela a déjà  été signalé précédemment, l’OMG
n’a pas publié la première mouture des spécifications CCM avant l’été. Et pour
sa part, Sun n’a pas encore défini tous les détails permettant d’assurer le bon
fonctionnement des EJB. Gopalan Suresh Raj, de CompuWare, explique que, par exemple,
chaque éditeur de serveur d’applications EJB met en oeuvre sa propre démarche pour
écrire des descripteurs de déploiement, ce qui limite la portabilité des composants
entre serveurs d’applications.

“ Etant donné que la classe Java Identity est une classe abstraite, chaque éditeur
se doit de fournir une mise en oeuvre concrète de cette classe. C’est pourquoi,
un EJB écrit pour le produit d’un éditeur donné qui possédait une mise en oeuvre
spécifique de la classe Identity, peut avoir du mal à  fonctionner sur le serveur
d’un autre éditeur qui disposait d’une mise en oeuvre différente ”, ajoute Mike
Koranda, Consultant en programmation chez IBM.

Toutefois, la prochaine mouture des standards EJB (connus sous le nom de code
“ Moscone ”) publiée par Sun prendra en compte cette question en standardisant
la manière dont les descripteurs de déploiement sont définis, en passant par XML
(eXtensible Markup Language). Sun, avec l’aide de ses partenaires, adressera également
les questions liées aux performances et à  la sécurité des EJB.

Alors u’il était encore dans sa phase conceptuelle, CCM a également déjà  obtenu
le soutien d’éditeurs de serveurs d’applications Web tels que BEA, qui projettent
d’incorporer le support des EJB et de CCM dans des serveurs d’applications où
les deux modèles devraient cohabiter et se compléter l’un l’autre.

Avec CCM, on sera théoriquement capable de prendre une application RPG existante,
un EJB de sa conception, de placer les deux dans un conteneur CORBA 3.0, et les
faire travailler de concert de façon harmonieuse, sans autre forme d’intégration.
En fait, Seagull est déjà  en train de créer des modules qui permettront d’encapsuler
les codes AS/400 traditionnels pour qu’ils puissent être utilisés dans un modèle
EJB.

MTS, qui a précédé EJB de deux ans, est écrit conformément à  un standard complètement
différent. Bien qu’il ne puisse pas fonctionner sur AS/400 de façon native, MTS
peut accéder à  DB2/400 et peut fonctionner sur un INS (Integrated Netfinity Server).
Les éditeurs tels qu’Iona et Visual Edge projettent de lier CCM et MTS dans leurs
serveurs d’applications Web, et permettre ainsi aux deux modèles de coopérer.
En outre, la plupart des fournisseurs de serveurs d’applications Web projettent
de supporter IIOP (Internet Inter-ORB Protocol), une sorte de pipeline qui permet
à  différents modèles de programmation de se parler les uns les autres à  travers
Internet.

Gopalan Suresh Raj, qui a programmé aussi bien avec les EJB qu’avec MTS dans un
environnement Windows, affirme que les deux modèles de composants possèdent des
fonctions équivalentes et peuvent être utilisés de façon similaire. Il suffit
simplement de connaître les subtilités de chacun. La différence la plus significative
est que les composants MTS n’ont pas d’état, alors que les EJB peuvent être persistants
ou transactionnels. Microsoft déclare que maintenir un état consomme trop de précieuses
ressources système et limite l’évolutivité. Pour sa part, le clan Java estime
qu’un bean persistant est un élément incontournable des applications d’entreprises.

Bien entendu, certains développeurs ont un penchant naturel pour l’un ou l’autre
des modèles. BeanStreet par exemple, reste à  l’écart du modèle Microsoft et privilégie
le modèle Java, indépendant des plates-formes. L’entreprise a mis quelques JavaBeans
sur le marché et utilise actuellement VisualAge for Java pour développer des EJB
à  usage interne.

Toutefois, comme l’explique Andrew Watson de l’OMG, la plupart des développeurs
ne peuvent pas se permettre d’être des “ fanatiques qui essayeraient d’exclure
ceux qui utiliseraient cet “ autre modèle ” parce qu’ils ne seraient pas “ purs
” ou un autre argument de ce type. Le fait est que sur le marché, les postes de
travail sont basés sur COM car presque tout le monde utilise Windows.
En revanche, de nos jours, la plupart des systèmes d’entreprises semblent être
basés sur CORBA. Il faut donc faire en sorte que l’un puisse dialoguer avec l’autre.

Téléchargez cette ressource

Préparer l’entreprise aux technologies interconnectées

Préparer l’entreprise aux technologies interconnectées

Avec la « quatrième révolution industrielle », les environnements hyperconnectés entraînent de nouveaux risques en matière de sécurité. Découvrez, dans ce guide Kaspersky, comment faire face à cette nouvelle ère de vulnérabilité.

Tech - Par Renaud ROSSET - Publié le 24 juin 2010