c# - studio - Servidor de servicios IIS WCF vs Servicio de Windows

wcf service c#

Question

Desarrollamos un servicio WCF y estamos buscando implementarlo. Nuestros clientes lo usarán con basicHttpBinding pero nuestro equipo interno lo usará con namedPipesBinding .

Nos preguntamos si es mejor alojarlo en IIS 7 o con un servicio de Windows. Realizamos algunas pruebas y descubrimos que cuando agregamos enlaces en IIS, no actualiza el archivo de configuración de nuestro servicio. Eso significa que tendríamos que mantener la configuración en dos lugares diferentes. No es lógico, ¿verdad?

También leemos en StackOverflow que la dirección base se ignora cuando un servicio WCF es host en IIS (consulte la pregunta del archivo de configuración del servicio WCF con respecto a <baseAddresses> )

Answer 1

Aunque hay una respuesta seleccionada aquí, me permitiré publicar un enlace de hilo Q / A.

¿Cómo configurar el servicio WCF desde el código cuando está alojado en IIS?

Lo que encontrará en mi respuesta allí (y en el enlace) es su control fino sobre el host del servicio, ya sea que lo cargue en WService o en IIS.

Al inicio del servicio, puede interponer IIS con qué enlaces tiene y crear los puntos finales apropiados. Busque la configuración de II a través del espacio de nombres de Microsoft.Web.Administration.

Espero que esto ayude un poco.

Answer 2

El alojamiento en IIS tiene muchos pros y muchos contras.

Sí, IIS le ofrece carga según demanda; esto puede ser un punto a favor o un inconveniente. Cuando entra una solicitud, se construye el ServiceHost, luego se crea una instancia de la clase de servicio alojada y se maneja la solicitud. Nada tiene que estar funcionando todo el día. Pero al mismo tiempo, esta configuración requiere más tiempo y esfuerzo cada vez que aparece un mensaje, y usted, como programador, no tiene mucho control sobre su servidor de servicio, en realidad.

Y sí, con IIS, el directorio virtual donde reside el archivo * .svc define su dirección: no se tienen en cuenta las direcciones base o las direcciones explícitamente definidas en su configuración. Y sin mucho esfuerzo, no puede cambiar el diseño de las direcciones del servicio; siempre serán http://servername/virtualdirectory/YourService.svc (incluida la extensión .svc).

El autohosting es a menudo más rápido, ya que su ServiceHost ya está en funcionamiento, pero depende de usted asegurarse de que realmente esté en funcionamiento, no hay carga "bajo demanda" cada vez que aparece un mensaje, ya sea que esté activo o no. puede atender la solicitud, o no. Pero tiene mucho más control sobre el host del servicio: cuándo y cómo está construido, etc., y puede elegir y definir sus direcciones de servicio como mejor le parezca.

Personalmente, casi siempre elegiría el autohosting, en una aplicación de consola para probar, en un servicio NT para producción. Para mí, parece ser la forma más adecuada de hacerlo, y la forma más controlada, también. Tienes que hacer más trabajo, pero sabes exactamente lo que estás haciendo.

Bagazo

Answer 3

IIS le proporciona muchas características listas para usar, como la recarga del dominio de la aplicación, la supervisión, etc.

Esta es la razón por la que debe responder estas preguntas primero: ¿necesita todas estas características o no? De lo contrario, se puede considerar el servicio de Windows.

Answer 4

No hay una respuesta estándar a esta pregunta. No estoy completamente de acuerdo con la respuesta de Cheeso (el autohospedaje de WCF no es una buena idea).

Consulte los siguientes enlaces: ( http://msdn.microsoft.com/en-us/library/ms730158.aspx , http://msdn.microsoft.com/en-us/library/bb332338.aspx ) y piense en su restricciones:

• sistema operativo
• rendimiento esperado
• HW disponible
• disponibilidad esperada

y verá que en muchas situaciones el "alojamiento propio" es la mejor alternativa.

Answer 5

Para responder a esa pregunta:

Realizamos algunas pruebas y descubrimos que cuando agregamos enlaces en IIS, no actualiza el archivo de configuración de nuestro servicio. Eso significa que tendríamos que mantener la configuración en dos lugares diferentes. No es lógica, ¿verdad?

Cuando utiliza IIS para alojar su servicio, debe configurar su archivo App.config o web.config para permitir que IIS exponga algún enlace, por lo que en su archivo de configuración, pondrá todo su enlace que permita en su servicio wcf. Http, net.tcp, etc ...

En su enlace, no especificará la dirección, porque especificará esas direcciones en IIS directamente.

En IIS debe permitir el enlace disponible en la configuración avanzada de su sitio web. Después de eso, establecerá un nuevo enlace para su sitio web "servicio web" y agregará todos los enlaces que desee escuchar, y especificará la dirección.

Deberá especificar la dirección directamente en IIS.

Hay un ejemplo.

Su archivo de configuración:

<services>
    <service name="ServiceName">                    
        <endpoint address=""
            binding="basicHttpBinding"
            bindingConfiguration="httpMode"
            contract="IContract" />                 
        <endpoint address=""
            binding="netTcpBinding"
            contract="IContract" />
        <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
    </service>
</services>

En su configuración Advisor IIS, pondrá su

http, net.tcp en protocolos habilitados

Después de eso irá en su enlace a IIS. Coloque su enlace para http normalmente y agregue un nuevo enlace net.tcp, en la configuración de enlace ponga el puerto y el directorio virtual como

8001: *

Esta configuración permite todas las conexiones en el puerto 8001 para cualquier directorio virtual.

También debe tener instalada en su servidor la función "Activación de WCF, (Activación de Http y Activación que no es Http)".

Answer 6

Tidbit interesante-> después de leer este hilo encontré estas palabras en MSDN sobre el alojamiento de un servicio WCF usando un servicio de Windows:

Las siguientes son algunas de las desventajas de los servicios de Windows:

• Despliegue: los servicios se deben instalar con la utilidad .NET Framework Installutil.exe o mediante una acción personalizada en un paquete de instalador.
• Funciones limitadas: los servicios de Windows aún tienen un conjunto limitado de características listas para usar para admitir la alta disponibilidad, la facilidad de administración, el control de versiones y los escenarios de implementación. Básicamente, debe cubrir estos requisitos usted mismo a través de un código personalizado, mientras que, por ejemplo, IIS viene con varias de estas características de forma predeterminada. Los servicios de Windows agregan capacidad de recuperación y algunas características de seguridad, pero aún tiene que trabajar un poco.
http://msdn.microsoft.com/en-us/library/bb332338.aspx

... y el siguiente enlace:

Servicios de alojamiento: (buen cuadro de comparación)
http://msdn.microsoft.com/en-us/library/ms730158.aspx

Answer 7

marc_s generalmente da respuestas excelentes con las que estoy completamente de acuerdo, pero en este caso no.
El autohospedaje de WCF no es una buena idea, especialmente con las tecnologías de Dublín lanzadas pronto por Microsoft. La administración y las operaciones de las aplicaciones WCF (y WF) son mucho más simples cuando se alojan dentro de IIS.

Además, obtiene la carga bajo demanda.

Hay una opción de siempre activada para IIS7.5 (WS2008 R2).

Y puede hacer fácilmente la reescritura de URL para omitir .svc si eso le molesta.