В вашем вопросе есть некоторая путаница, которую мне нужно сначала уточнить.
Похоже, вам нужна возможность проверки WSDL (синтаксис + WS-I) и XSD, встроенных или на которые ссылается WSDL.С другой стороны, вы вводите @SchemaValidation, который фактически используется для проверки документов экземпляра.
В традиционном подходе к разработке можно сказать, что вы хотите хотя бы возможность проверять артефакты времени разработки (WSDL + XSDs).).
Тогда для этого сценария я бы порекомендовал следующее:
WSDL: для тестирования соответствия WS-I ознакомьтесь с разделом Инструменты тестирования WS-.Я сайт .Непонятно, как лицензирование, которое они имеют с помощью своего тестового инструментария, будет работать с вашим, но, по крайней мере, оно должно дать вам представление о том, что искать, если оно не работает для вас.
ОБНОВЛЕНИЕ: Дополнительные WSDLресурсы для проверки: - на основе Eclipse , как использовать вне Eclipse.
XSD: если вам действительно требуется отдельная проверка для файлов XSD, для продукта производственного качества может возникнуть сложность; WSDL4J здесь не сильно поможет, и я считаю, что XSOM - это способ пойти на такую работу.Вы должны извлечь содержимое из раздела типов как один или несколько файлов XSD (это может быть несколько файлов XSD, посмотрите на некоторые примеры, WSDL от Microsoft, как мне кажется, хороший тестовый пример), назначьте базовый URI длякаждый извлеченный XSD, который соответствует расположению WSDL, затем используйте XSOM для их проверки.
Поскольку вы генерируете клиент, вам, скорее всего, не нужно проверять, скажем, заголовки HTTP (SOAP 1.1 / HTTP, SOAPAction, если оно соответствует определению операции WSDL).Если в конечном итоге вы также проявите интерес к этому, который я называю проверкой во время выполнения, я бы порекомендовал другой макет в вашем подходе (т.е. я бы не полагался на @SchemaValidation, а скорее делал бы это через прозрачный и универсальный прокси-сервис).).