Вы определенно должны использовать SoapUI.Особенно в смешанной среде.т.е. в смешанной среде (Java, Delphi, WCF и т. д.). SoapUI будет вашим общим инструментом, который может подтвердить, что работает, а что нет.Его также можно использовать для настройки фиктивных сервисов, чтобы вы могли проверить сервис, который еще не создан.то есть из WSDL вы можете за считанные минуты создать что-то, что будет регистрировать запросы и давать ответы.Это очень полезно.В будущем вы сможете проверить, что работает, а что нет, используя общий инструмент, вместо того, чтобы бороться за «работает здесь в технологии x, так что это должно быть проблемой в ВАШЕМ конце».
Посмотрите демонстрацию mockservices, где они показывают, как делать простые постоянные ответы на основе xpath.Очень просто и эффективно.Вы можете отправить ответ и вернуть множество предсказуемых ответов.например, вы отправляете обновления для emps Tom, Dick, Harry.Сконфигурируйте свой mockservice SoapUI, чтобы он возвращал успех для Тома, мягкую ошибку для Дика, катастрофическую ошибку для Гарри.
IMO. Лучше всего начать с создания веб-службы до создания mockservice в SoapUI.Затем вы можете протестировать образцы полезных нагрузок и посмотреть, все ли видят то, что ожидают.т.е. HR отправляет нового сотрудника в Payroll, используя WSDL, на который все согласились.Разработчик Payroll еще даже не кодировал свою часть, но, глядя на транзакцию в SoapUI, он видит, что формат EmpID «совершенно не будет работать с нашей стороны».Теперь HR может внести изменения.Девелопер Payroll также видит, что даты увольнения - 31.12.1889 для сотрудников, которые еще не уволены.Он ожидал ».Теперь между разработчиками и аналитиками может начаться дискуссия, а не позднее, во время интеграции или запуска, когда обсуждение, вероятно, будет включать несколько уровней PM, «ситуационных ориентиров» и т. Д.