Sé que esto no responde a su pregunta por completo, pero me gustaría compartir mi experiencia.
Tengo una aplicación de consola de Windows que, cuando está programada, llama a los servicios WCF alojados en IIS. En esta arquitectura, el IIS es completamente innecesario y solo un componente adicional de la solución general. Realmente se incluyó en la solución por razones de marketing, para reforzar el producto, y no por razones técnicas.
Estos son los principales problemas que estoy enfrentando, y por qué habría evitado usar IIS si pudiera por razones técnicas, y esto se aplica a mi experiencia. Tenga en cuenta: no digo que alojar servicios de WCF en IIS sea una mala idea. Solo estoy dando mi opinión sobre el producto en el que estoy trabajando actualmente.
- Tener IIS en el bucle significa tener otro sistema en la solución general. Esto, a su vez, agrega complejidad a su implementación. Algunos clientes tienen otros IIS6 que ejecutan 7. Aunque estas diferencias pueden parecer pequeñas en la superficie. No se equivoque, todavía son diferentes, lo que significa que está agregando más potencial para las diferencias ambientales si está implementando su producto para diferentes clientes.NO subestimes estas diferencias. Incluso tengo clientes tratando de ejecutar mis servicios WCF dentro de una Colección de sitios de SharePoint (¡duh!), El punto es MUCHO más de lo que cree que puede salir mal.
- IIS también tiene una consideración de AppPool, que podría necesitar configurarse según la complejidad de su producto. Esa AppPool necesita una identidad para ejecutarse, agregando más complejidad nuevamente a su solución general.
- Tuve algunos problemas en los que un servicio de subproceso único a veces tiene "interesante": mensajes de aborto de subprocesos. Mientras sigo tratando de descubrir la causa exacta, en el fondo de mi mente espero sinceramente que esto no esté relacionado de alguna manera con IIS. El punto es que no tendría esta consideración si eliminé IIS de la solución general.
- He escuchado discusiones de que IIS es un entorno de alojamiento más robusto para los servicios de WCF frente a uno mismo alojado. No estoy del todo seguro de que esto tenga algún peso. Si sabes lo que estás haciendo, no debería haber ninguna razón para que tu servicio alojado sea poco confiable. Pero supongo que es más trabajo por adelantado implementar algunas de las funciones automáticas que obtienes en IIS, por ejemplo, reciclaje de WP.
- No estoy en general insatisfecho con IIS en el ciclo, pero es una molestia cuando entrego el producto para la implementación, y los consultores sin una sólida formación técnica tienen que configurar la aplicación IIS. Por lo general, algo puede ir y saldrá mal, e involucra a alguien con más experiencia técnica para intervenir y resolver. Si tiene alojamiento propio, puede empaquetar su aplicación mucho más fácilmente para la implementación.
- Perdóneme por reiterar, pero si elige IIS, tendrá 2 aplicaciones en su solución en lugar de 1, aunque la parte comercial de su organización solo verá la aplicación como una unidad de negocio, esencialmente sin comprender la complejidad completa de la solución que estás implementando Por ejemplo: ¿Por qué tenemos 2 archivos de configuración? ¿Por qué tenemos que configurar el correo dos veces? ¿Por qué tenemos que implementar DLL en 2 ubicaciones? Estas preguntas se hacen mucho.
- Por último, pensé que mencionaría si está trabajando de forma remota o por VPN para implementar a clientes, la situación empeora aún más, a veces el consultor tiene acceso a áreas sensibles que usted no conoce. Como desarrollador, intente eliminar tanto equipaje adicional como sea posible de su solución general. También mencionemos que el administrador del sistema podría a veces emitir un conveniente reinicio de IIS. Si su aplicación se aloja junto con otras, restablecerán sus servicios.
Menos sistemas en mi experiencia = menos pueden salir mal. Pero debe decidir si tiene las habilidades para implementar servicios fiables autohospedados. Todo esto, a su vez, se relaciona directamente con el costo de desarrollo, implementación y mantenimiento.
OK ... Así que estoy de acuerdo en que cualquier cuello de botella de verdad vendría del tipo de encuadernación utilizada, ajustes específicos en la configuración. Después de un tiempo usando WCF en ambos estilos de servicio, he llegado a aceptar que el rendimiento se debe a factores distintos al contenido del servicio y mucho más que ver con el estilo de configuración. Gracias Brad. –