Servidor de servicios IIS WCF vs Servicio de Windows

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 anfitrión en IIS (ver WCF service configuration file question regarding <baseAddresses>)

Answer 1

Para responder a esas preguntas:

nos encontramos con algunas pruebas y nos dimos cuenta de que cuando estamos añadiendo fijaciones en IIS, que no actualiza el archivo de configuración de nuestro servicio. Eso significa que necesitaríamos mantener la configuración en dos lugares diferentes. No es lógica, ¿verdad?

Cuando se utiliza IIS para alojar su servicio, debe configurar el archivo app.config o web.config para permitir que IIS para exponer algunas de unión, por lo que en el archivo de configuración, se le ponga toda su encuadernación que permite a su servicio wcf. Http, net.tcp etc ...

En su encuadernación 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 fichero 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 IIS advenced el establecimiento de su pondrán

http, net.tcp en Protocolos habilitados

Después de que va a ir en su vinculante en IIS. Deja tus vinculante para http normaly y añadir una nueva net.tcp de unión, en la configuración de enlace poner el puerto y el directorio virtual como

8001: Esta configuración *

permitir que todas las conexiones en el puerto 8001 para cualquier directorio virtual.

También debe tener la característica "Activación WCF, (activación Http y Activación No Http)" instalada en su servidor.

Answer 2

IIS le proporciona una gran cantidad de características fuera de la caja, como dominio de aplicación recarga, monitoreo, etc.

Por eso deberías responder a esta pregunta primero: ¿necesitas todas estas funciones o no? En caso negativo, se puede considerar el servicio de Windows.

Answer 3

El alojamiento en IIS tiene muchas ventajas y desventajas.

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 de servicio; siempre van a ser 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 ingresa un mensaje, o bien está activo y 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 preferiría utilizar el alojamiento propio, 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.

Marc

Answer 4

marc_s suele dar grandes respuestas que estoy de acuerdo con todo, pero en este caso yo no lo hacen.
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, obtienes la carga a petición.

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

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

Answer 5

Interesante tidbit-> después de leer este hilo me encontré con estas palabras en el MSDN sobre el recibimiento de un servicio WCF utilizando 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, facilidad de administración, control de versiones y 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: (bonita tabla de comparación)
http://msdn.microsoft.com/en-us/library/ms730158.aspx

Answer 6

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).

Compruebe los siguientes enlaces: (http://msdn.microsoft.com/en-us/library/ms730158.aspx, http://msdn.microsoft.com/en-us/library/bb332338.aspx) y pensar en sus limitaciones:

• sistema operativo
• rendimiento esperado
• disponibles HW
• disponibilidad prevista

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

Answer 7

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

How to configure WCF service from code when hosted in IIS?

lo que encontrará en mi respuesta allí (y el enlace en él) es su fino control sobre el host de servicio si se carga en WService o en IIS.

Al inicio del servicio, puede intercalar 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.