Servicio stateful de larga ejecución en .NET

Question

Necesito crear un servicio en .NET que mantenga el estado (interno) en memoria, genera múltiples hilos y generalmente es de larga ejecución. Hay opciones mucho -

• Buena de edad, de servicios de Windows
• Servicios de Comunicación de Windows
• Windows Workflow Foundation

Realmente no sé cuál escoger. La mayor parte de la funcionalidad está en una biblioteca utilizada por este servicio, por lo que el servicio en sí es bastante simple.

Por un lado, es importante que el host del servicio esté lo más cerca posible de "simplemente trabajar", lo que excluye el Servicio de Windows. Por otro lado, es importante que el servidor no elimine el servicio solo porque no hay actividad externa, lo que hace que WCF sea demasiado "aterrador". En cuanto a WF, su punto de venta más fuerte es la capacidad de crear procesos como, um ..., flujos de trabajo, que es algo que no necesito ni quiero.

En resumen, la plétora de tecnologías de Microsoft me confundió un poco.

lo agradecería ayuda con respecto a los pros y los contras de cada solución (o de otro tipo es que he dejado de mencionar) para el problema de un servicio de larga ejecución con estado en .NET

, gracias,
Asaf

PS,
estoy usando .NET 4.

EDIT:

• Lo que quiero decir con el host "simplemente funciona" es, por ejemplo, que el servicio que creo se reactive si se bloquea.
• Supongo que el motivo de esta pregunta es que he creado Servicios de Windows en el pasado (creo que fue en C++ con Win32 API), y no quiero perderme algo más sencillo si los hay como una cosa

¡Gracias por todas las respuestas hasta el momento!
Asaf.

EDIT 2:

voy a utilizar un servicio de Windows, y podría albergar un servicio WCF en su interior para permitir que otros procesos para comunicarse con él.

Gracias,
Asaf

Answer 1

Sobre la base de su descripción, su mejor apuesta es # 1, un servicio de Windows buen viejo. Puede asignarle trabajo, puede ejecutarse todo el tiempo que desee y puede engendrar hilos. No estoy seguro de lo que quiere decir con "simplemente trabajar" o por qué eso pone fuera de funcionamiento a un Servicio de Windows.

Podría, alternativamente, hacer una aplicación de consola simple, pero tendría que manejar la administración (reinicia, etc.) usted mismo.

WCF es esencialmente.NET remota en la web, no maneja procesos de larga ejecución por sí mismo. Workflow Foundation puede manejar flujos de trabajo de larga ejecución, pero solo eso.

Answer 2

1. como "simplemente trabajando" como sea posible - que excluye los servicios de Windows ...
2. no desactivado debido a la inactividad ... miedo - WCF ...
3. hay necesidad de un flujo de trabajo, ni quieren - Fundación Workflow ...

¡Parece que no hay tantas opciones como te gustaría creer! ; P

• ¿Qué tal un simple EXE que hace el trabajo, y que está programado a través del Programador de tareas de Windows? Usted administra el multihilo desde su aplicación. Esto sería tan simple como una aplicación de consola.

EDITAR Mi primera opción sería un servicio de Windows también, pero es más simple a través del planificador.

Answer 3

De acuerdo a sus requerimientos "estado (interior) en memoria, desova múltiples hilos y es generalmente de larga duración" en realidad hay dos opciones:

1. aplicación de consola
2. servicio de Windows

Otros dos mencionados son derivados de estos. El primero es demasiado primitivo y olvidemos esto. Pero para facilitar la depuración lo recomiendo en Main, marque Environment.UserInteractive y si es verdadero, ejecute como aplicación de la consola, sino como servicio. Entonces tu elección debería ser 2nd.

WCF es el marco de comunicación y no tiene nada sobre el servicio de larga ejecución. IIS puede alojar aplicaciones WCF, pero no hay datos multihilo y de memoria interna, es una sola llamada como servicio web. WF es un marco de flujo de trabajo y nuevamente no tiene nada acerca de los servicios. Puede ayudar a implementar lógica de flujo compleja.

Tanto WCF como WF se pueden usar en el servicio de Windows.

Answer 4

Como parece que no necesita ninguna función relacionada con el flujo de trabajo, mi voto se dirige a Durable Services en WCF. Esto es nuevo en .NET 3.5, y permite que los servicios WCF persistan en un "almacén de persistencia" basado en proveedores, típicamente una base de datos SQL Server (pero también hay un proveedor basado en sistemas de archivos, y es extensible; puede escribir el tuyo si es necesario).

Salida excelentes entradas de blog sobre este tema:

• Durable Services in WCF
• Durable Services (Screencast with Mike Taulty)
• Orcas Durable Services
• Creating Durable Services in WCF 3.5
• Durable Services in WCF (screencast)

WCF es una gran y poderosa biblioteca de comunicación que te libera de muchos problemas y detalles con los que tendrás que lidiar cuando crees todo esto desde cero.

WCF se puede alojar en IIS (con todas sus deficiencias), o puede incluir su servicio WCF en un servicio de Windows NT y hacer que se inicie y se ejecute cuando la máquina arranque, sin que nadie inicie sesión.

Answer 5

¿Has estado en Quartz.Net? Es más un programador pero puede iniciar trabajos, etc. en múltiples hilos. Utilicé esto en lugar de un servicio de Windows con gran éxito.

Answer 6

Sugeriría el buen servicio de Windows. He escrito muchos servicios usando C# para estos mismos propósitos. Pueden engendrar hilos, correr por una eternidad, y están bien diseñados para hacer lo que quieras. Puede crear un servicio de Windows .net directamente en Visual Studio. Es uno de los tipos de proyectos .net.

WCS y WCF harán lo que quieran pero requieren un trabajo adicional y realmente no fueron diseñados para lo que parece que desean hacer.