Le déploiement de programmes
critiques, sur le terrain des services en ligne ou de
la gestion de la production par exemple, implique souvent
la mise en oeuvre de plusieurs serveurs d'applications
ou autres systèmes serveurs, notamment en vue de
garantir la capacité de traitement informatique
adéquate (montée en charge, etc.). A cela
s'ajoute la plus part du temps la nécessité
de faire intervenir des briques reposant sur d'autres
plates-formes (bases de données par exemple).
Ce type de projet passe par le choix d'une technologie
d'architecture dite "distribuée". Entendez
par là une méthode dessinée pour
orchestrer les interactions entre éléments
applicatifs multienvironnement. Dans ce domaine, deux
modèles transactionnels cohabitent : l'invocation
directe entre composants logiciels (ou objets) d'une part,
l'implémentation de Web Services additionnels pour
exécuter ce dialogue d'autre part.
SOAP/HTTP
contre remoting
Les avantages
du mode objet (remoting) ? Il offre en premier
lieu certaines fonctions que les Web Services ne proposent
pas. Parmi elles, on compte notamment la possibilité
d'ouvrir des liens natifs entre composants distants
par le biais de flux de données dans différents
formats de communication (notamment un formatage binaire
utilisant directement la couche réseau TCP -
pour Transfer Control Protocol).
Forte
de ce premier avantage, cette solution brillerait également
par ses performances d'exécution. Et là encore, elle
afficherait une longueur d'avance sur les Web Services...
Ces derniers auraient encore beaucoup d'efforts à
faire pour arriver au même niveau de qualité.
Pour l'heure, ils se limitent par nature au protocole
HTTP et utilisent le format de message SOAP, basé
sur XML, qui contribue à alourdir les paquets
transmis par ajout d'information...
Attention
à la somme de développements nécessaire
Revers de la
médaille : le mode objet se révèlerait
plus complexe à développer et à
déployer. Pour fonctionner, il nécessite
en outre de disposer du même environnement objet
sur l'ensemble des serveurs et système cibles.
Sur ce segment, on distingue principalement deux grandes
catégories de technologies propriétaires:
Corba (J2EE) et .Net Remoting (Windows Server).
De leurs côtés, les Web Services ne seraient
pas aussi difficiles à programmer. Aisée
à mettre en oeuvre, l'ouverture de connexions sous cette
forme s'effectuerait de façon quasi automatique, pour
peu qu'un module de lecture SOAP soit installé sur les
plates-formes utilisées. Reste le principal point fort
des Web Services : le standard SOAP (/WSDL) leur permet
de s'immiscer potentiellement dans la quasi totalité
des serveurs d'applications du marché (IBM WebSphere,
BEA WebLogic, Windows Server, Sun One Applications Server,
Oracle AS, etc.).
Au regard de ces facteurs
de différentiation, il est conseillé d'opter
pour la première option (c'est-à-dire
le mode objet) en cas de maîtrise complète
des briques à intégrer. En revanche, si
le projet demande de faire appel à des composants
hétérogènes - des logiciels de
partenaires par exemple -, il peut être plus judicieux
d'implémenter des Web Services.
|
[