Pouvez-vous donner des exemples de la manière dont vous avez utilisé gSOAP et de son intégration dans votre architecture existante? Avez-vous trouvé des goulots d'étranglement de développement avec gSOAP?Où avez-vous utilisé gSOAP?
Répondre
Nous avons utilisé gSOAP dans un serveur Web basé sur C++ il y a environ 4 ans. Globalement, cela a bien fonctionné. Le seul problème majeur était que l'interface était en C et procédurale (je comprends qu'il est difficile de concevoir une bonne interface non procédurale). Il peut y avoir beaucoup de code répété lors de l'implémentation de l'interface, pour lequel vous devrez peut-être utiliser des macros (nous n'avons pas exploré l'option templates trop loin).
Nous utilisons gSoap pour déployer un service Web sur un périphérique linux embarqué exécutant un processeur ARM MX.
Nous utilisons gSOAP pour consommer un service Web basé sur WCF à partir d'une application déployée sur un périphérique Linux fonctionnant sur un processeur ARM. L'expérience est bonne dans une large mesure.
Nous avons utilisé gSOAP pour qu'un groupe de clients ARM communique avec un serveur AXIS Web Service. Pour de gSOAP:
- très puissant, prend en charge la quasi-totalité des constructions Web Service
- facile à utiliser, son abstraction de WS remet en fonctions supprime toute la complexité du service Web au programmeur
- interfaces élégantes dans les deux C et C++
Cependant, nous avons rencontré plusieurs goulots d'étranglement de développement:
- lors de l'utilisation les types de données personnalisés comme les cartes ou les ensembles, il faut un peu de piratage pour que le compilateur gSOAP les gère (marshal/unmarshalling). Particulièrement mauvais avec les structures de données dynamiques.
- Le débogage est difficile en raison de son réseau complexe intrinsèque, de l'analyse et des parties d'allocation de mémoire. Faire tout son possible pour rester avec l'allocation de mémoire statique.
- la liste de diffusion est en vie, mais les développeurs n'y sont pas très actifs. Les questions simples peuvent obtenir une réponse rapide, mais les problèmes les plus difficiles restent souvent sans réponse
- oublier l'optimisation. La liaison dans gSOAP consomme environ 1 Mo de mémoire lors de l'exécution (-Os). Les performances d'exécution sont excellentes sur notre carte ARM 32 Mo basée sur linux, mais il y a vraiment peu de choses à faire sur l'optimisation si vous en avez besoin.
Nous avons utilisé gSOAP dans un serveur Web sur un périphérique ARM9 ARM9 400 MHz. Démon gSOAP connecté à un démon de base de données via la bibliothèque zeromq, exécutée sur le même périphérique.
Il prend en charge plus de 1000 requêtes de base qui ne requièrent pas de connexion à la base de données.
La désactivation de la prise en charge de l'option SOAP à références multiples par le paramètre WITH_NOIDREF a permis de réduire le temps de sérialisation environ 4 fois plus vite sur les grosses requêtes comportant un grand nombre de nœuds de sérialisation.