Évaluation de l'accès aux services Web

String serviceEndPoint=services[0].getServiceEP(); }

Enfin, la dernière étape consiste à accéder au service souhaité :

java.net.URL serviceURL= new java.net.URL(serviceEndPoint);

ServiceInterface service=new Service.ServiceBindingStub(serviceURL,null);

5.4 Évaluation

Nous présentons dans cette section une série d'expérimentations effectuées afin d'évaluer les performances de l'intergiciel Ariadne et aussi de les comparer avec celles des intergiciels existants. Plus précisément, nous avons concentré notre évaluation sur les performances de CSOAP (§ 5.4.6) et sur celles du service de localisation (§5.4.7). Cela s'explique par le fait que les performances associées aux opérations fournies par le service Web découlent directement de celles de la plate-forme d'exécution Java.

5.4.1 Évaluation de l'accès aux services Web

Afin d'évaluer les performances du protocole CSOAP, nous avons développé un service Web. Ce service offre comme fonctionnalité une opération qui prend en entrée un tableau d’entiers et fournit en retour une chaîne de caractères. Du fait de la simplicité de l'opération exécutée, le temps de réponse suite à l'invocation de l'opération correspond au temps nécessaire pour transporter le message SOAP, l’encoder et le décoder, en extraire les paramètre d'entrée et de sortie et l’exécuter. Lors de ces expérimentations nous avons utilisé des PDAs et des ordinateurs portables. Nous présentons ci-dessous leurs caractéristiques. Les PDAS correspondent à des Compaq IPAQ 3600 disposant de 206 MHz de CPU et de 32 MB de

RAM et ayant comme système d'exploitation Linux et la distribution Familiar 0.6 et comme environnement d'exécution J2ME CDC 1.0.1 JVM. Les ordinateurs portables sont des Compaq PC ayant 500 MHz de CPU et 192 MB de RAM. Ils disposent du système d'exploitation Linux et de la distribution Redhat 7.3 et comme environnement d'exécution de la J2ME CDC JVM.

Figure 5-7 Temps de réponse CSOAP pour un tableau de grande taille

Les figures 5-7 et 5-8 présentent le temps d’attente perçu par le client entre le début de l’invocation et l’obtention du résultat, ainsi que le délai entre le début de l’invocation par le client et l'exécution de l'opération au niveau du serveur, en fonction de la taille du tableau fourni en entrée, variant de 10 à 100 (figure 5-8) voir 1000 éléments (figure 5-7).

Ces deux figures comparent aussi ces temps d’attente lorsque le serveur CSOAP est déployé sur un PDA ou sur un ordinateur portable et cela afin de montrer l'impact qu'ont les capacités des terminaux sur le traitement des messages lors de l’invocation d’une opération au niveau du serveur. Ainsi, le traitement d’un message comprenant 100 paramètres dans le tableau nécessite environ trois fois plus de temps de traitement sur un PDA que sur un ordinateur portable (figure 5-8). Lors de nos expérimentations, nous avons remarqué que 80 % du temps utilisé par un serveur pour traiter une invocation (incluant le temps entre la réception du message et l'exécution de l'opération) était utilisé pour filtrer le message XML. Notons que la figure 5-7 illustre particulièrement bien l’impact du traitement XML sur le temps de traitement pour le client lorsque la taille du tableau augmente.

La figure 5-9 compare quant à elle les performances de CSOAP avec celles d’AXIS en évaluant le délai entre le début de l’invocation d’une opération et l’obtention de la réponse au niveau du client. Le serveur et le client, pour CSOAP et AXIS, sont déployés sur un ordinateur équipé d’un processeur Intel PIII de 800 MH et de 384 MB de RAM, et ayant comme système d’exploitation Linux-Redhat 7.3 ainsi que la JVM J2SE 1.3.1. Le temps d’attente induit par CSOAP est environ 10 % inférieur à celui d'AXIS. Toutefois, nous envisageons de réduire cette différence en développent un analyseur syntaxique d’XML plus efficace.

Enfin, la figure 5-10 compare les performances de CSOAP avec celles de Java RMI. Java RMI fait partie des intergiciels utilisés traditionnellement pour accéder aux fonctionnalités offertes par des terminaux distants dans un environnement mobile. Pour cette expérimentation, nous utilisons pour le client Java RMI les paquetages optionnels de Sun et

pour le serveur l’implémentation pour les plateformes Intel du répertoire RMI³⁰. Le client et le

serveur CSOAP et Java RMI sont exécutés sur des ordinateurs portables interagissant via un réseau ad hoc WLAN d’un débit de 11MBps.

Figure 5-10 CSOAP versus Java RMI

La figure fournit le temps de réponse induit par un appel à une procédure, et perçu par le client. Les résultats obtenus montrent que CSOAP offre de meilleures performances pour un tableau dont la taille est inférieure à 60 éléments, alors que Java RMI est plus efficace pour un tableau de plus de 60 éléments. Toutefois, si nous considérons l’intelligence ambiante en tant que contexte d’application, il semble plausible que la plupart des opérations distantes invoquées demandent comme paramètre moins de 60 éléments. En effet, si nous considérons

un service Web particulièrement complexe d’achat en ligne tel que celui de ebay³¹, la

description WSDL du service Web correspondant contient 30 opérations. Si nous considérons

le service Web de recherche mis à disposition par le moteur de recherche Google³², l’interface

correspondante est constituée de trois opérations (GetCachePagem, doSpellingSuggestion, et

doGoogleSearch). Nous pouvons donc conclure qu’au niveau de l’invocation des opérations

distants, les performances d’Ariadne comparée à celles d’intergiciels Java RMI sont meilleures et donc que le fait d’offrir une solution basée sur les services Web est préférable du

30 http://java.sun.com/rmi/

point de vue des performances mais aussi pour supporter des services ubiquitaires qui nécessitent des interactions à peu de paramètres.