К вашему классу обслуживания добавить атрибут:
<ServiceBehavior(AddressFilterMode:=AddressFilterMode.Any)>
Это позволяет службе быть рассмотрены клиентом как https: // ... но сервис будет размещен на HTTP : // ..... См. this answer о том, как создать расширение, позволяющее задать AddressFilterMode.Any через конфигурацию без атрибутов кода.
В web.config хоста службы элемент конечной точки должен иметь абсолютный URL-адрес в атрибуте адреса, который является общедоступным URL-адресом, который будет использоваться клиентом. В том же элементе endpoint установите атрибут listenUri на абсолютный URL, на котором прослушивается хост службы. То, как я определяю, что абсолютный URI по умолчанию, который прослушивает хост, - это добавить ссылку на службу в клиентское приложение, которое указывает на физический сервер, на котором размещается служба. Web.config клиента будет иметь адрес для службы. Затем я копирую это в атрибут listenUri в хоста web.config.
В конфигурации поведения службы добавить элемент serviceMetaData с атрибутом httpGetEnabled = истина
Таким образом, вы будете иметь что-то вроде:
<serviceBehaviors>
<behavior name="myBehavior">
<serviceMetadata httpGetEnabled="true" />
</behavior
</serviceBehaviors>
...
<services>
<service name="NamespaceQualifiedServiceClass" behavior="myBehavior" >
<endpoint address="https://www.sslloadbalancer.com" binding="someBinding" contract="IMyServiceInterface" listenUri="http://www.servicehost.com" ... />
</service>
</services>
Я не уверен, если это работает с безопасностью сообщений или транспортной безопасности , Для этого конкретного приложения учетные данные были переданы как часть DataContract, поэтому у нас был режим безопасности basicHttpBinding = none. Поскольку транспорт является безопасным (для балансировки нагрузки ssl), проблем с безопасностью не было.
Также возможно оставить атрибут listenUri пустым, однако он должен присутствовать.
К сожалению, в WCF есть ошибка, в которой базовый адрес импортированных схем в WSDL имеет базовый адрес listenUri, а не общедоступный базовый адрес (тот, который настроен с использованием атрибута адреса конечной точки). Чтобы обойти эту проблему, вам необходимо создать реализацию IWsdlExportExtension, которая напрямую импортирует импортированные схемы в документ WSDL и удаляет импорт. Примером этого является здесь http://winterdom.com/2006/10/inlinexsdinwsdlwithwcf.Кроме того, вы можете иметь пример класса унаследованы от BehaviorExtensionElement и завершить два новых метода с:
Public Overrides ReadOnly Property BehaviorType() As System.Type
Get
Return GetType(InlineXsdInWsdlBehavior)
End Get
End Property
Protected Overrides Function CreateBehavior() As Object
Return New InlineXsdInWsdlBehavior()
End Function
Это позволит добавить поведение расширения в файле .config и добавить поведение, используя конфигурацию, вместо того, чтобы создать сервисной фабрики.
под элементом конфигурации system.serviceModel добавить:
<endpointBehaviors>
<behavior name="SSLLoadBalancerBehavior">
<flattenXsdImports/>
</behavior>
</endpointBehaviors>
</behaviors>
<extensions>
<behaviorExtensions>
<!--The full assembly name must be specified in the type attribute as of WCF 3.5sp1-->
<add name="flattenXsdImports" type="Org.ServiceModel.Description.FlattenXsdImportsEndpointBehavior, Org.ServiceModel, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"/>
</behaviorExtensions>
</extensions>
А затем ссылаться на новое поведение конечной точки в конфигурации конечных точек с помощью атрибута behaviorConfiguration
<endpoint address="" binding="basicHttpBinding" contract="WCFWsdlFlatten.IService1" behaviorConfiguration="SSLLoadBalancerBehavior">
Это содержание, как представляется, переместились в HTTP: //msdn.microsoft.com/en-us/magazine/cc163412.aspx. – JohnW 2009-12-09 02:59:26