Подключите приложение C++ к веб-приложению JAVA с помощью SOAP

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

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

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

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

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

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

Обходной путь для этого - убедиться, что ничего, связанное с gSOAP, не отображается за пределами SO, с которым они связаны. Эту проблему можно решить, задав gcc следующие определения _ как при линковке самой библиотеки 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).

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

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

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

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

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

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

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