a su clase de servicio de añadir el atributo:
<ServiceBehavior(AddressFilterMode:=AddressFilterMode.Any)>
Esto permite que el servicio sea dirigida por el cliente como https: // ... pero el servicio a estar alojada en http: // .. ...
En el web.config del host de servicio, el elemento de extremo debe tener una URL absoluta en el atributo de dirección que es la URL pública que utilizará el cliente. En el mismo elemento de punto final, establezca el atributo listenUri en la URL absoluta en la que el servidor de servicio está escuchando. La forma en que determino cuál es el URI absoluto predeterminado que está escuchando el host es agregar una referencia de servicio en una aplicación cliente que apunta al servidor físico donde se aloja el servicio. El web.config del cliente tendrá una dirección para el servicio. Luego copio eso en el atributo listenUri en los hosts web.config.
En la configuración de su comportamiento en servicio añadir el elemento con el atributo serviceMetaData httpGetEnabled = true
Por lo que usted tiene algo así como:
<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>
No estoy seguro de si esto funciona con la seguridad de los mensajes o la seguridad del transporte . Para esta aplicación en particular, las credenciales se pasaron como parte del DataContract, por lo que tuvimos basicHttpBinding security mode = none. Como el transporte es seguro (para el equilibrador de carga ssl) no hubo problemas de seguridad.
También es posible dejar en blanco el atributo listenUri, sin embargo, debe estar presente.
Desafortunadamente, hay un error en WCF donde la dirección base de los esquemas importados en el WSDL tiene la dirección base listenUri en lugar de la dirección base pública (la configurada usando el atributo de dirección del punto final). Para evitar este problema, debe crear una implementación IWsdlExportExtension que traiga los esquemas importados al documento WSDL directamente y elimine las importaciones. Un ejemplo de esto se proporciona aquí http://winterdom.com/2006/10/inlinexsdinwsdlwithwcf. Además, puede tener la hereda ejemplo de la clase de BehaviorExtensionElement y completar los dos nuevos métodos con:
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
Esto le permitirá añadir un comportamiento de extensión en el archivo .config y agregar el comportamiento mediante la configuración en lugar de tener que crear una fábrica de servicios.
bajo el elemento de configuración System.ServiceModel añadir:
<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>
y luego hacer referencia el nuevo comportamiento de punto final en su configuración de punto final mediante el atributo behaviorConfiguration
<endpoint address="" binding="basicHttpBinding" contract="WCFWsdlFlatten.IService1" behaviorConfiguration="SSLLoadBalancerBehavior">
Yossi, tiene que quizás recibió una respuesta a esta de alguna parte ¿más? - (John Saunders que hizo su tarea de Oslo recientemente). –