Действительно ли там такая вещь как прокси-сервер SOAP, или я оказываюсь перед необходимостью прокручивать свое собственное?

Apache Camel идеально подходит для всех этих требований. Camel - это легкая платформа для выполнения именно такой интеграции приложений. Раньше я использовал его для аналогичного HTTP-проксирования.

Camel использует очень выразительный DSL для определения маршрутов между конечными точками. В вашем случае вы хотите установить сервер, который будет виден всем клиентским машинам на вашем клиентском сайте, и любые запросы, которые он получает, вы хотите направлять «от« этой конечной точки »к« вашей защищенной конечной точке через https ».

Вам нужно будет создать простой класс, определяющий маршрут. Он должен расширить RouteBuilder и переопределить метод configure

public class WebServiceProxy extends RouteBuilder
{
    public void configure()
    {
       from("jetty:http://0.0.0.0:8080/myServicePath")
                  .to("https://mysecureserver/myServicePath");
    }
}

. Добавьте это в контекст Camel, и все будет хорошо.

CamelContext context = new DefaultCamelContext();
context.addRoute(new WebServiceProxy());
context.start();

Этот маршрут создаст веб-сервер, использующий причал, привязанный к 8080 на всех локальных интерфейсах. Любые запросы, отправленные в / myServicePath, будут перенаправлены непосредственно на вашу веб-службу, определенную uri https: // mysecureserver / myServicePath . Вы определяете конечные точки, используя простой uris, а dsl и camel заботятся о тяжелой работе.

Вам может потребоваться настроить хранилище ключей с вашими сертификатами и сделать его доступным для компонента http. Опубликуйте сообщение еще раз, если у вас возникнут проблемы;)

Я бы прочитал документацию camel для http-компонента для получения более подробной информации, также проверьте модульные тесты для проекта, поскольку они полны примеров и лучших практик.

HTH.

К вашему сведению: чтобы компонент http использовал ваше хранилище ключей, вам необходимо установить следующие свойства

System.setProperty("javax.net.ssl.trustStore", "path/to/keystore");
System.setProperty("javax.net.ssl.trustStorePassword", "keystore-password");

Вам следует изучить WCF, который поддерживает протокол WS-Addressing. Мне кажется, я видел статьи (кажется, в MSDN) о написании маршрутизаторов с использованием WCF.

Вам также следует как можно скорее избавиться от WSE 2.0. Он очень устарел (был заменен на WSE 3.0, который также устарел). Все его функции были заменены WCF.

Я считаю, что ESB (Enterprise Service Bus) может быть жизнеспособным и надежным решением вашей проблемы. Существует ESB с открытым исходным кодом под названием Mule , которую я никогда не использовал. Некоторое время назад я возился с ALSB (служебная шина AquaLogic) , но это было бы дорого для того, что вы описываете. В любом случае, в частности, вам стоит обратить внимание на маршрутизацию. Я не уверен, что это будет простой способ подключи и работай, но это действительно другой вариант.

Вы также можете сделать это с помощью Microsoft ISA Server , коммерческого прокси / кэш-сервера. Он сделает многое из того, что вам нужно, из коробки. Для всего, что невозможно из коробки, вы можете написать расширение для сервера, чтобы это было сделано.

ISA Server не является бесплатным.

ISA теперь переименовывается в «Microsoft Forefront Threat Management Gateway».

Это гораздо больше, чем просто веб-прокси-сервер - он поддерживает множество протоколов и множество функций. Может быть, больше, чем вам нужно.

На Codeplex есть инструмент виртуализации сервисов от Microsoft, который называется Managed Service Engine, который предназначен для отделения клиента от реализации веб-сервиса. Это могло бы пополнить счет или дать вам хороший старт. На самом деле я не исследовал это полностью, просто просмотрел статью в MSDN, и ваше описание напомнило мне об этом.

• http://www.codeplex.com/servicesengine
• http://msdn.microsoft.com/ en-us / magazine / dd727511.aspx

Ваш модель безопасности не имеет смысла для меня. Какова цель использования HTTPS? Обычно это делается для аутентификации сервиса для клиентов. В таком случае, зачем серверу хранить сертификаты клиентов? Сертификат X509 сервера должен храниться у клиентов

. Зачем вам нужно использовать VPN? Если вам нужно аутентифицировать клиентов, есть способы сделать это лучше. Вы можете либо включить взаимную аутентификацию в SSL, либо использовать XML-Security и, возможно, WS-Security для защиты службы на уровне SOAP. Даже если вы используете SSL для аутентификации клиентов, вам все равно не следует хранить все сертификаты клиентов на сервере, а лучше использовать PKI и проверять сертификаты клиентов на доверенный корень.

Наконец, конкретно для вашего предлагаемого решения на основе прокси, я не понимаю, зачем вам нужно что-то специфичное для SOAP. Разве вам не нужен просто веб-сервер, который может пересылать любой HTTP-запрос на удаленный HTTPS-сервер? Я не знаю, как это сделать навскидку, но я бы изучил подобные Apache и IIS ...