Je ne pense pas que le cgi était le bon choix (ensuite ayant lu votre question plus tôt). Au mieux, il est l'une des manières possibles, mais votre description de problème n'était pas assez pour conclure que le cgi serait la meilleure option.
Quelques questions :
- Vous avez dit son une application et/ou une bibliothèque. Quel est-il ? Est-ce un DLL ? SI son appeler juste une fonction de DLL alors qui est possible même dans ASP.NET et asp classique (je signifient l'appel directement, avec quelques limitations peut-être).
- Que votre application fait-elle ? Pouvez-vous la modifier ?
>> des exemples dehors là où les gens se sont reliés pour centraliser des demandes de C++ d'un site Web ?
Je ne rappelle pas un exemple, mais il est facile de pensent à un Java applet Se reliant à un certain serveur principal. Il tout dépend de la façon dont votre application est écrite
- Si l'application est un serveur de HTTP (a un serveur de HTTP), alors vous pouvez juste SIGNALER ou des appels d'ajax à lui using le Javascript etc. ajoutant l'appui de serveur de HTTP à l'application de C.A. ++ est facilement accomplis en employant des trousses à outils comme POCO par exemple. Si je n'oublie pas la poussée a également de tels dispositifs.
- Si son juste un DLL/bibliothèque, puis sur IIS, vous peut écrire des filtres de HTTP/traiteur (les dlls ont chargé par IIS qui effectuent le travail spécial, comme celui qui fait la réécriture d'URL). Ceux peuvent porter la demande et le délégué de HTTP à la bibliothèque.
- Vous pouvez même construire un serveur de HTTP simple de substitut qui peut porter les demandes et le délégué au DLL (ce correspond la première option ci-dessus).
- le cgi est également possible, mais plus adapté si votre application est accoutumée pour lire du stdin et pour écrire au stdout. (une application de console)
Noter que dans tous les cas et solutions donnés jusqu'ici, l'idée de ligne de base est l'utilisation du HTTP de parler à la partie postérieure, parce que c'est la manière la plus commune possible.
