2009-06-08 4 views
0

Nous avons une application écrite en langage C qui interagit avec la base de données Oracle. Cette application est un exécutable et fonctionne sur la plate-forme Unix. Nous devons exposer cette application sur http comme service web pour que d'autres puissent en consommer.Activer l'application C en tant que Webservice

J'ai pensé utiliser JNI et CXF pour le service web et lancer l'application dans tomcat.

Est-ce une bonne solution ou existe-t-il d'autres possibilités?

J'ai trouvé Axis2 supportant le langage C pour écrire le webservice. Je n'ai aucune expérience du langage C. Est-ce que Axis2 en C est bon? Quel serveur http je peux utiliser pour déployer l'application? Apache webserver siffice dans ce cas?

EDIT: La ligne de commande n'est pas une option comme si je l'ai mentionné un exe mais la partie que je dois exposer n'a aucune ligne de commande disponible et son bit dur car il a besoin de structure de données compliquée comme entrée.

Répondre

1

Cela dépend de quelques facteurs. La méthode de Vinko nécessite que l'application dispose d'une bonne interface de ligne de commande. En outre, la création d'un nouveau processus pour chaque requête de service Web limitera le nombre de demandes pouvant être traitées. Cela peut ou peut ne pas être correct en fonction de la taille attendue du public.

Si l'interface de ligne de commande n'est pas géniale et que vous souhaitez optimiser le nombre de requêtes que vous pouvez traiter, cela vous laisse deux choix principaux. Ecrivez le service Web en Java et appelez en C avec JNI ou JNA. Ou, écrivez-le en C ou C++ pur. Le dernier n'est probablement pas conseillé si les développeurs responsables ne connaissent pas C.

EDIT: Étant donné que la ligne de commande n'est pas une option, je recommande Java avec JNI ou JNA. En cas d'utilisation du package Apache Foundation Axis2/C, vous pouvez utiliser le package Apache Foundation.

+0

Ne sachant pas que C ne sera pas un problème, je peux gérer cela, j'ai seulement besoin de quelle est la meilleure solution? –

1

C'est une interface assez solide, même si elle a encore une portabilité légèrement limitée (fonctionne sur Linux, mais pas sur Solaris, par exemple) a besoin de quelques ajustements. Cependant, puisque vous dites que vous n'avez pas l'expérience en C, cela peut vous rendre la tâche trop ardue. D'un autre côté, vous dites que le code que vous essayez de convertir en un service Web est en C (plus peut-être Oracle OCI); cela signifie que vous allez avoir du mal à éviter d'apprendre du C pour que ça fonctionne.

0

Après avoir utilisé Axis2/C sur le côté serveur depuis plus de deux ans, je vous recommande fortement de NE PAS utiliser Axis2/C pour tout code côté serveur pour les raisons suivantes:

  1. Il est plein de fuites de mémoire. À savoir, code de service généré à partir de fuites WSDL, fuites de serveur HTTP simples, fuites de module CGI (ce qui n'est pas un problème si vous l'utilisez comme CGI de base, mais un problème majeur si vous l'utilisez depuis FastCGI ou similaire) . La seule partie du code du serveur HTTP dans Axis2/C que je n'ai pas encore vérifié est le module mod_axis2 pour Apache2. Peut-être que c'est mieux. Axis2/C ne dispose d'aucune implémentation de serveur HTTP que vous pouvez facilement intégrer dans votre application C: le "simple serveur HTTP" fuit et ne supporte pas les keep-alives HTTP (ferme la connexion après chaque requête) . J'ai dû implémenter moi-même un serveur basé sur les exemples de serveur boost :: asio HTTP et le module CGI Axis2/C. Passé 1 jour sur la mise en œuvre et 4 jours pour éliminer toutes les fuites de mémoire. Cette proportion semble standard pour tout travail lié à Axis2/C. Voulez-vous passer des jours et des nuits avec valgrind, déboguer des fuites de mémoire et des doubles-libres?Le plus important, c'est que le projet n'est PAS maintenu activement: il y a beaucoup de problèmes avec les correctifs dans leur JIRA, mais il faut des mois et des années pour réviser et appliquer les correctifs. Je doute que tout projet sérieux l'utilise pour le côté serveur. Mon plan à long terme est de le cloner en GIT et de maintenir la version corrigée sur github (je dois supporter le code déjà implémenté avec Axis2/C depuis des années).

P.S. Dans mon prochain sous-projet lié aux services Web, j'utiliserai JNI pour intégrer Jetty + CXF.

+0

Axis2/C-1.7.0 (tronc) a de nombreuses nouvelles fonctionnalités et complètement instable. Nous utilisons donc 1.6.0. C'est plus stable mais il y a aussi beaucoup de bugs. Nous avons créé un projet sur googlecode (https://code.google.com/p/axis2c-unofficial/) avec des correctifs rétroportés du tronc actuel. Si vous avez des patches qui peuvent améliorer la stabilité et que vous êtes prêt à contribuer à ce projet, écrivez-moi ( [at] gmail.com). – loentar