Использование веб-службы Spring (SOAP) в сервлете Java - PullRequest
1 голос
/ 01 октября 2011

Есть ли способ использовать веб-сервис Spring на основе SOAP без создания заглушек на клиенте (как предлагают многочисленные потоки, указывающие на JAX-WS)?

Вот мой полный сценарий:

У меня есть 2 веб-приложения, скажем, APP1 и APP2, оба из которых имеют поддержку Spring.APP2 предоставляет свои API-интерфейсы в виде Spring-WS, которые принимают POJO (объекты Reqeust и Response) через.МЫЛО.Теперь я хочу вызвать эти веб-сервисы из APP1, но не хочу создавать заглушки с использованием WSDL frmo APP2.Это возможно?

Более подробно, вот одна из операций моего веб-сервиса:

@PayloadRoot(localPart = "CreateNewRequest", namespace = "myNameSpace")
public CreateNewReqResponse createNewRequest( CreateNewReqRequest requestObj ) throws Exception
{
    NewCase newCase = this.localSpringService.createNewCase( requestObj.getParam1(), requestObj.getParam2() );
    CreateNewReqResponse response = this.objectFactory.createCreateNewReqResponse();
    CreateNewReqResponseObject responseObject = this.objectFactory
            .createCreateNewReqResponseObject();
    if( null != newCase )
    {
        responseObject.setParam1( newCase.getParam1() );
        responseObject.setParam2( newCase.setParam2() );
        }
        responseObject.setCaseRequestedDate( caseRequestedDate );
    }
    response.setResponseObject( responseObject );
    return response;
}

Теперь, как вы можете видеть, метод веб-сервиса принимает CreateNewReqRequest и возвращает CreateNewReqResponse.Я пытаюсь выяснить, как я могу вызвать этот веб-сервис из APP1, который не имеет никакого представления об этих классах - CreateNewReqRequest и CreateNewReqResponse?Нет ли другого способа, кроме создания заглушек в APP1 (из WSDL) с использованием JAX-WS?

Оба рассматриваемых приложения являются нашими собственными (то есть мы их разработали), но выполняются на разных серверах, посколькуиз которых APP1 не может вызывать веб-сервис напрямую - междоменная политика.Поэтому я напишу сервлет в APP1, который будет использовать веб-сервис, предоставляемый APP2.

Ответы [ 2 ]

1 голос
/ 01 октября 2011

В конце дня SOAP - это простой протокол поверх HTTP. Поэтому, если вы хотите отказаться от использования JAX-WS, вы можете начать использовать необработанные http-соединения, вручную кодировать запросы SOAP и вручную анализировать ответ SOAP. Это просто означает, что вы заново изобретаете колесо, которое является заглушками клиента JAX-WS.

Итак, если вы абсолютно хотите избежать создания заглушки, отправьте его по HTTP-сообщению и получите сообщения по URL-адресу конечной точки WSDL.

То, что делает клиентская заглушка, просто абстрагирует эту реализацию для вас. т. е. вам не придется иметь дело с мелочью SOAP / WSDL и http-соединением, вы будете иметь дело с SOAP на более высоком уровне, т. е. через объекты Java.

Вы также можете посмотреть другие библиотеки, такие как Apache CXF или Axis, но даже там вам придется генерировать клиентские заглушки.

Таким образом, вопрос, который вы хотите задать, заключается в следующем: хотите ли вы по-настоящему заняться и вручную обшаривать HTTP-соединения и SOAP XML или позволить инфраструктуре взять на себя эту тяжелую работу за вас.

Ответ на комментарий Нитина следует ниже

Чтобы ответить на ваши вопросы: 1. Да, вам придется заново создавать заглушки, если WSDL меняется, если вы не используете заглушки, а анализируете все вручную, вам придется изменить этот код. Таким образом, между ними нет никакой разницы. Ваша программа должна будет измениться, если WSDL (то есть контракт между клиентом и сервисом) изменится. Это будет то же самое даже для REST, т. Е. Если контракт, опубликованный службой, изменится (возможно, параметры или действие и т. Д.), Вам придется изменить свой код клиента. Этого не избежать. Надеемся, что общедоступные веб-сервисы были бы разработаны таким образом, чтобы обеспечить возможность будущих изменений, и такие изменения не произошли бы в одночасье, что дало бы вам достаточно времени для изменения кода. Эта проблема не имеет отношения к тому, как реализован веб-сервис, т.е. Spring Web Service не имеет ничего общего с.

Похоже, вы упускаете из виду заглушки клиента, которые генерирует для вас SOAP-инфраструктура, такая как JAX-WS, Axis, CXF. Клиентская заглушка - это один из способов общения с веб-сервисом. Это не единственный способ. Клиентская заглушка является предпочтительным методом, поскольку она абстрагируется от мелочей обработки SOAP-вызовов вручную. Таким образом, вместо того, чтобы изобретать колесо и реализовывать библиотеку синтаксического анализа SOAP (XML), вы можете сосредоточить свои усилия на реальном приложении, которое вы пишете. В вашей реальной программе вам придется иметь дело только с POJO, и вам никогда не придется беспокоиться о том, как происходит волшебство SOAP, например, как преобразовать ваши данные и упаковать их в сообщение SOAP, отправить это сообщение SOAP в службу с помощью HTTP-соединения, обработайте ответ, проанализируйте ответное SOAP-сообщение и получите данные, которые вас интересуют. Всего этого вы избегаете, используя POJO. Вы задаете свойства для запроса, вызываете метод для клиентского метода-заглушки и получаете объект, все остальное - вам не о чем беспокоиться (в идеале).

Надеюсь, это немного прояснится.

0 голосов
/ 01 октября 2011

Взгляните на WebServiceTemplate класс.

...