CXF: предоставление несвязанной конечной точки через существующий транспорт сервлетов

#jetty #cxf #endpoint #ws-addressing #ws-reliablemessaging

#jetty #cxf #конечная точка #ws-адресация #ws-reliablemessaging

Вопрос:

У меня есть приложение, которое предоставляет услуги с использованием транспорта сервлетов CXF и Jetty 6.1. Этому приложению также необходимо использовать внешние службы. Все службы поддерживают спецификацию WS-адресации (и WS-RM поверх). Чтобы использовать внешнюю службу, я запускаю созданный клиент-службу из приложения.

Проблема в том, что когда я предоставляю несвязанную конечную точку для клиента (WS-RM нуждается в этой конечной точке для приема входящих сообщений через отдельное http-соединение), CXF запускает другой экземпляр сервера Jetty (несмотря на то, что транспорт сервлетов (который предоставляет услуги) и клиент (который потребляет некоторую внешнюю службу) используют одну и ту же шину). Мне не нужны два экземпляра Jetty (не говоря уже о том, что они не могут запускаться на одном HTTP-порту).

Есть ли способ, которым я могу предоставить несвязанную конечную точку, используя существующий сервер Jetty и транспорт сервлетов?

Пока что я включаю развязанную конечную точку, подобную этой:

 Client client = ClientProxy.getClient(port);
HTTPConduit httpConduit = (HTTPConduit) client.getConduit();
httpConduit.getClient().setDecoupledEndpoint(
     "http://domain.com:port/services/dec_endpoints/TestDecEndpoint");
  

Если я указываю относительный путь («/dec_endpoints /TestDecEndpoint», точно так же, как относительные пути используются при предоставлении услуг через транспорт сервлета), HTTP conduit не указывает полный путь в заголовках сообщения SOAP, поэтому это тоже не работает (сервер просто не может отправить сообщение в /dec_endpoints / TestDecEndpoint).

Ответ №1:

Хорошо, я сам нашел решение. Вам необходимо указать относительный путь для несвязанной конечной точки и изменить свойства адресации сообщения вручную (после перехватчика MAPAggregator, потому что он настраивает несвязанное назначение), чтобы сервер мог отправлять ответы на ваш адрес.

Итак, что мы имеем:

  1. несвязанный пункт назначения с использованием относительного пути: /dec_endpoints/SomeDestination
  2. <ReplyTo> заголовок с абсолютным путем: http://addr.com:port/servlet_path/dec_endpoints/SomeDestination

Вот пример, как можно изменить путь:

 public class ReplyToInterceptor extends AbstractPhaseInterceptor<Message>
{
    public ReplyToInterceptor() {
        super(Phase.PRE_LOGICAL);
        addAfter(MAPAggregator.class.getName());
    }

    public void handleMessage(Message message) {
        AddressingProperties maps = ContextUtils.retrieveMAPs(message, false, 
           true);
        EndpointReferenceType replyTo = maps.getReplyTo();
        replyTo.getAddress().setValue(
           "http://address.com:port/servlet_path/dec_endpoints/SomeDestination");
    }
}