Это, кажется, популярный вопрос, поэтому я дам обзор того, что мы сделали в нашей ситуации.
Похоже, что сервисы, встроенные в .NET, следуют более старому стандарту ws-адресации (http://schemas.xmlsoap.org/ws/2004/03/addressing/), а axis2 понимает только новый стандарт (http://schemas.xmlsoap.org/ws/2004/08/addressing/).
).
Кроме того, предоставленный файл policyCache.config находится в форме, которую модуль rampart оси2 не может понять.
Итак, шаги, которые мы должны были сделать, в двух словах:
- Прочитайте policyCache.config и попытайтесь понять его. Затем перепишите это в политику, которую мог понять вал. (Некоторые обновленные документы помогли.)
- Настройте вал с помощью этой политики.
- Возьмите ключи, которые были предоставлены в файле .pfx, и преобразуйте их в хранилище ключей Java. В Jetty есть утилита, которая может это сделать.
- Сконфигурировать вал с этим хранилищем ключей.
- Напишите собственный обработчик axis2, который преобразует в обратном направлении новые вещи с ws-адресацией, которые выходят из axis2, в более старые вещи, ожидаемые службой.
- Настройте axis2 для использования обработчика в исходящих сообщениях.
В итоге было много настроек и кода для чего-то, что должно было быть открытым стандартом, поддерживаемым поставщиками.
Хотя я не уверен, что является альтернативой ... можете ли вы подождать, пока поставщики (или в данном случае один поставщик) убедятся, что все будет взаимодействовать?
В качестве постскриптума я добавлю, что я не закончил работу, это был кто-то другой в моей команде, но я думаю, что я понял правильные детали. Другой вариант, который я рассматривал (до того, как мой товарищ по команде вступил во владение), заключался в том, чтобы напрямую вызывать API-интерфейс WSS4J для создания конверта SOAP, как того ожидала служба .NET. Я думаю, это тоже сработало бы.