С++ и SOAP

Ответ 1

Я проголосую за darkhelmet, так как gSoap также будет моей рекомендацией. Мы в основном магазин Java, но с некоторыми битами С++, и gSoap был нашим предпочтительным способом интеграции SOAP. Это действительно большая работа, чем ваши типичные Java-пакеты, но она кажется твердой.

Ответ 2

Быстрый Google поднял этот для инструментария. Хотя я никогда не использовал его, он кажется довольно популярным и прочным. Не совсем пакет, а не совсем катив, но в середине.

Ответ 3

Мы пошли с gSOAP, а не с Axis, чтобы избежать зависимости от JRE и Axis только для создания проекта на С++. Он работал нормально, что хорошо, так как код gSOAP ужасен и затрудняет исправление ошибок.

Предупреждение о привязке gSOAP: вы никогда не сможете использовать более одного WSDL в одном объекте связи (исполняемый файл, dll, общий объект). Это связано с тем, что некоторые из сгенерированных функций, специфичных для WSDL, имеют общие имена (например, soap_getfault()).

Хуже, с привязкой Unix ELF, эти имена вызовут перекрестную связь между общими объектами, поэтому сбой для модуля FooService может быть обработан soap_getfault() для BarService, повреждая память, если структуры детали ошибки различны.

Обходной путь для этого заключается в том, чтобы убедиться, что ничего связанное с gSOAP не показано вне SO, с которым они связаны. Это можно решить, предоставив gcc эти определения _both при связывании самой библиотеки gSOAP и связывании вашего кода:

#define SOAP_FMAC2  __attribute__ ((visibility ("hidden")))
#define SOAP_FMAC4  __attribute__ ((visibility ("hidden")))
#define SOAP_FMAC6  __attribute__ ((visibility ("hidden")))
#define SOAP_NMAC   __attribute__ ((visibility ("hidden")))

Я решил его, поставив их в файл заголовка и заставляя gcc включать это перед чем-либо еще с -include fixsoaplink.h.

Лучший способ, если вы можете приложить усилия, может изменить видимость ELF по умолчанию для скрытых и экспортировать только символы, которые вы хотите (например, dllimport/dllexport в VC).

Ответ 4

Взгляните на проект Apache Axis. Он хорошо поддерживается на С++ (и Java), и если у вас есть счастье начать с хорошего WSDL для целевой службы, вы будете свободны от дома.

Ответ 5

Когда я увидел сгенерированный код из gSOAP, у меня случился сердечный приступ.

Тот факт, что пользователь должен выполнять все управление памятью для каждого объекта, просто ошеломил мой разум. Итак, я сел и сделал что-то, вероятно, глупое в долгосрочной перспективе, но довольно удовлетворительное в краткосрочной перспективе...

Я написал программу, которая обертывает код gSOAP с моими собственными классами CPP, которые делают интерфейс более похожим на то, что я хотел бы посмотреть.

Я использовал Scoped Guard в каждом методе службы для хранения в памяти, и поскольку я имею дело со всеми типами разных типов, я использовал std::list<boost::any> для этого. У меня есть функции, которые делают каждый тип объекта, который мне нужен, и они помещают фактическую память в мой list<any>. У него было несколько проблем - в основном, только изменения конфигурации. Сейчас я создаю тысячи классов, разговаривая с десятками веб-сервисов.

Я не уверен, что я порекомендую один и тот же путь кому-либо еще... Я, вероятно, должен укусить пулю и начать пытаться внести свой вклад в gSOAP, а не поддерживать собственный инструмент, зависящий от вывода gSOAP...

Ответ 6

Вот еще одна проблема с gSOAP, которую мы только что обнаружили: она использует select() для всех опросов, поэтому, если у вас открыто 1024 дескриптора файлов (64 на Windows?), это приведет к удалению стека. Это приводит к ложным ошибкам, когда он не может отправлять сообщения, чтобы завершить сбои приложения.

Обходной путь, если только вы не готовы исправить gSOAP, заключается в том, чтобы написать свой собственный сетевой код и подключить его с помощью мыла → fconnect, → fsend, → frecv и т.д.