|
JDNet
Solutions. .Net et J2EE sont les principaux environnements
utilisés pour développer et exécuter
des Web Services...
Rémy Poulachon. Il
existe assez peu de différences entre ces plates-formes
et la manière dont elles génèrent
et exécutent de tels composants. Toutes deux
reposent en effet sur une machine virtuelle pour les
délivrer, brique à laquelle s'ajoute diverses
fonctions de gestion des performances (équilibrage
de charge, etc.).
La problématique
principale des solutions d'intégration à
base de messages SOAP réside plutôt dans
la manière d'invoquer ces objets depuis des terminaux
ou des serveurs distants.
Pour
que le Web Service fonctionne, client et serveur doivent
être dotés de la même version de
SOAP ?
Aujourd'hui, SOAP 1.1 est proposé
par l'ensemble des éditeurs. Certes, cette édition
reste limitée. Elle standardise l'envoi d'un
ordre à une application distante (grâce
à WSDL) et la lecture de la réponse XML
qui en découle - par le biais de SOAP justement.
Le tout transitant via un réseau HTTP. C'est
assez simple, SOAP est d'ailleurs l'acronyme de Simple
Object Access Protocol. Cependant, cela n'empêche
pas cette spécification de remplir sa mission
d'intégration !
Qu'en
est-il lors de la mise en oeuvre de services plus évolués ?
Dans
ce cas, les choses se compliquent. L'utilisation de
mécanismes plus complexes que de simples appels de fonctions
(ou méthodes) nécessitera l'implémentation par l'application
cliente de paramètres (SOAP) particuliers qui varieront
au regard de la plate-forme supportant le Web Service
cible (.Net, J2EE, etc.). C'est par exemple vrai si
l'on désire ajoindre des fichiers attachés aux messages
ou encore exploiter plusieurs protocoles réseau.
Aux
côtés d'Essilor, avez-vous pris en charge
d'autres projets sur le terrain des Web Services ?
Nous avons notamment développé
un outil permettant à un personnel nomade d'avoir
accès à des données stockées
sur un système d'entreprise depuis plusieurs
terminaux : un assistant personnel, un téléphone
portable ou encore un poste Web. Pour ce genre d'applications,
les Web Services présentent comme principal avantage
d'être décorrélés des applicatifs serveurs qu'ils
invoquent (bases de données, programmes .Net,
Java, etc.). Mais aussi de l'interface utilisateur -
qui peut par conséquent se décliner selon
différents écrans.
Ce retour d'expérience
met en valeur un autre grand point fort de cette méthode
d'intégration. Sorte de bus EAI standardisé,
elle est aussi un moyen de conserver un système
existant, développé en Java par exemple,
tout en développant parallèlement des
briques basées sur d'autres environnements de
développement et de déploiement (.Net,
etc.)... qui ne poseront aucun problème d'interopérabilité.
La sécurité
demeure le principal obstacle au déploiement
de Web Services ?
Cette question se pose en environnement
BtoB. Sur ce point, on note que les flux SOAP transitent
par le port 80 des pare-feu. Dans ce domaine, les éditeurs
commencent à prendre en compte le contrôle
des Web Services par le biais de dispositif de lecture
des messages XML. Le chiffrement des messages demande
encore l'installation de solutions particulières
(PKI, etc.). Quant à la compression des données,
elle peut être prise en charge par des protocoles
(base 64) intégrés par la plupart des
serveurs d'applications.
Comment
considérez-vous les récentes annonces
du consortium WS-I (Web Services Interoperability Organisation) ?
Les spécifications qui viennent d'être
publiées par cette organisation marquent une nouvelle
étape dans l'histoire des Web Services. Lors des premières
annonces autour de cette technologie, il était à craindre
que celle-ci face l'objet d'implémentations disparates...
et pour finir, ne prenne pas son essor. Là où l'infrastructure
Corba avait échoué, les membres du WS-I, parmi lesquels
on compte les plus grands éditeurs (IBM, Sun, Oracle
et Microsoft), nous prouvent avec cette nouvelle initiative
qu'ils sont capables de se mettre d'accord sur une façon
commune d'implémenter cette nouvelle norme.
Reste
que les Web Services ont encore du chemin à faire
avant de pouvoir faire face aux nombreuses problématiques
des échanges BtoB ?
Les transactions inter-entreprises
se cachent derrière les Web Services. Les premières
spécifications SOAP et WSDL devraient en effet
s'enrichir au fil du temps pour inclure des vocabulaires
de description de processus métier BtoB, comme
BPML ou ebXML, puis des langages spécifiques à
la description de documents techniques relatifs à
des secteurs particuliers - le domaine de l'aviation par
exemple. Ce chantier va demander plusieurs années
avant d'être mené à bout.
|
Le
haut débit par satellite pour la communauté rurale est en pleine
croissance
