Веб-служба ASP.NET меняет порт в Invoke - PullRequest
Новая
       28

Веб-служба ASP.NET меняет порт в Invoke

5 голосов
/ 07 октября 2009

У меня есть веб-служба ASP.NET на IIS, которая работает на порте 8080. На порте 80 у меня есть Apache, который перенаправляет некоторые веб-сайты на IIS.

В этом случае я могу получить доступ к странице веб-службы (http://example.com/service/),, которая предоставляет мне все доступные методы. Однако, когда я пытаюсь вызвать метод, он переходит на веб-страницу, подобную этой: http://example.com:8080/service/Service1.asmx/Method. Конечно, из-за открытого доступа не видно результатов, порт 8080 заблокирован и не может быть открыт.

Внутренне, веб-служба работает на порту 8080, но публичный запрос должен быть сделан на порт 80.

Кто-нибудь знает, как я могу решить мою проблему?

P.S .: Использование IIS 7 и Apache 2.2 под Windows Server 2008

1 Ответ

3 голосов
/ 07 октября 2009

Наиболее вероятной причиной этого является то, что ваш веб-сервис, сгенерированный WSDL, будет определять адрес конечной точки сервиса как:

http://example.com:8080/service/service1.asmx

Вы можете предоставить отдельное статическое определение WSDL и изменить следующий раздел для использования порта 80: 

<wsdl:service name="Service1"> 
    <wsdl:port name="Service1Soap" binding="tns:Service1Soap"> 
        <soap:address location="http://example.com:8080/service/service1.asmxx" /> 
    </wsdl:port> 
    <wsdl:port name="Service1Soap12" binding="tns:Service1Soap12"> 
        <soap12:address location="http://example.com:8080/service/service1.asmx" /> 
    </wsdl:port> 
</wsdl:service>

Это должно заставить клиента использовать WSDL и генерировать код заглушки для привязки к правильному порту (то есть серверу Apache, действующему в качестве прокси).

Другой альтернативный способ заставить правильный адрес появляться в сгенерированном WDSL - это использовать SoapExtensionReflector для изменения адреса location на лету:

Изменение WSDL веб-службы с помощью SoapExtensionReflector

В прошлом я успешно использовал вышеуказанный метод.

В качестве альтернативы вы можете, если клиент работает на основе .NET, переопределить базовый URL-адрес службы:

Свойство WebClientProtocol.Url (библиотека MSDN)

...