Добавете следния атрибут към вашия клас на обслужване:
<ServiceBehavior(AddressFilterMode:=AddressFilterMode.Any)>
Това позволява услугата да бъде адресирана от клиента като https://..., но услугата все още може да бъде хоствана на http://.....
Вижте моя отговор на Как да укажа AddressFilterMode.Any декларативно за това как да създадете разширение, за да позволите AddressFilterMode.Any да бъде указано чрез конфигурация, без да се изисква кодови атрибути.
В web.config на хоста на услугата елементът на крайната точка трябва да има абсолютен URL адрес в атрибута адрес, който е публичният URL адрес, който ще се използва от клиента. В същия елемент на крайна точка задайте атрибута listenUri на абсолютния URL адрес, на който хостът на услугата слуша.
Начинът, по който определям какъв е абсолютният URI по подразбиране, който хостът слуша, е да добавя препратка към услуга в клиентско приложение, което насочва физическия сървър, където се хоства услугата. Web.config на клиента ще има адрес за услугата. След това копирам това в атрибута listenUri в hosts web.config.
В конфигурацията на поведението на услугата добавете елемента serviceMetaData с атрибут httpGetEnabled=true
Така че ще имате нещо като това:
<serviceBehaviors>
<behavior name="myBehavior">
<serviceMetadata httpGetEnabled="true" />
</behavior>
</serviceBehaviors>
<!-- ... -->
<services>
<service name="NamespaceQualifiedServiceClass" behavior="myBehavior" >
<endpoint listenUri="http://www.servicehost.com"
address="https://www.sslloadbalancer.com"
binding="someBinding"
contract="IMyServiceInterface" ... />
</service>
</services>
Не съм сигурен дали това работи със сигурността на съобщенията или сигурността на транспорта. За това конкретно приложение идентификационните данни бяха предадени като част от DataContract, така че имахме basicHttpBinding › security › mode=none. Тъй като транспортът е защитен (към ssl load balancer), няма проблеми със сигурността.
Възможно е също да оставите атрибута listenUri празен, но той трябва да присъства.
За съжаление има грешка в WCF, при която основният адрес на импортираните схеми в WSDL има основния адрес listenUri, а не публичния основен адрес (този, който е конфигуриран с помощта на адресния атрибут на крайната точка). За да заобиколите този проблем, трябва да създадете реализация на IWsdlExportExtension, която пренася импортираните схеми директно в WSDL документа и премахва импортиранията.
Пример за това е даден в тази статия на Вграден XSD в WSDL с WCF. Освен това можете да наследите примерния клас от 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 добавете:
<behaviors>
<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">
person
Richard Collette
schedule
03.06.2009
