Я не думаю, что есть какие-либо инструменты для создания WSDL-файла из примера SOAP, но ваша схема выглядит настолько простой, что вы сможете создать ее вручную, пройдя какое-нибудь руководство по helloworld wsdl. Другой подход — попытаться создать реализацию Java для службы, и она распечатает wsdl при подключении к конечной точке. Дополнительную информацию об этих два подхода.
Чтобы протестировать и проверить конечную точку wsdl/soap, установите SoapUI и создайте тестовый проект, в котором вы импортируете wsdl, генерируете запрос (работает автоматически), убедитесь, что он соответствует вашему примеру, а затем настройте конечную точку для запроса, чтобы отправить его на входящий Mule.
В Mule у вас есть почти два варианта: вы можете реализовать службу как класс Java, как в приведенных выше примерах, или вы можете реализовать ее как cxf:proxy-service, где вы получаете прямой доступ к полезной нагрузке. В последнем подходе вам не нужны никакие классы Java, вы просто оборачиваете свои потоки внутри SOAP API.
ОБНОВИТЬ:
Запросы SOAP в значительной степени представляют собой просто HTTP-вызовы с XML, как в вашем примере, в виде необработанных данных POST, поэтому вы можете получить доступ к их содержимому во входящих сообщениях Mule, как и к любым данным POST, и проанализировать их с помощью XPath. Если вы определите cxf:proxy-service, вы получите немного более «настоящую» функциональность службы SOAP, но вы можете принимать вызовы SOAP практически с любым прослушивателем HTTP, захватывать их содержимое и отвечать строкой, которую ожидает клиент, и клиент не заметит разницы.
Если ваш поток Mule связывается с другой службой SOAP, вы можете создать прокси-сервер как для сервера, так и для клиента, как в этот пример. Вы также можете получить WSDL для другой службы SOAP, добавив ?wsdl
к URL-адресу службы. Это обычная практика с SOAP.
11.03.2014