Servicio windows con formulario accesible

Muchas gracias Alberto.

¿Podrías orientarme en las diferentes posibilidades existentes de
comunicación entre la aplicación y el servicio y dónde puedo obtener recursos
(links, documentación,etc)?

Jesús.

"Alberto Poblacion" wrote:

"Jesús" wrote in message
news:
> Mi intención es que esa aplicación se esté ejecutando siempre y que se
> inicie automáticamente ante un reinicio del servidor que la alberga y que
> se
> recupere automáticamente ante un fallo en la misma (tal y como se puede
> configurar en un servicio de windows).
>
> Se trata de una aplicación que "escucha" en un puerto y realiza acciones
> contra un SQL Server dependiendo de lo que reciba. Lo que pasa es que
> necesito un formulario para ajuste de diversos parámetros de la
> aplicación,
> de ahí que tenga que poder interactuar con ella.

Justo. Es lo que yo digo. La aplicación que escucha en el puerto y
realiza acciones contra un sql server es un servicio windows, y siempre
arranca al arrancar el servidor.
En cambio, el formulario para ajustar parámetros de la aplicación NO es
parte del servicio. Es un simple programa windows que el usuario arranca
cuando quiere configurar algo del servicio. Este programa usa algún
mecanismo de ipc, como por ejemplo Remoting, para transmitirle al servicio
los cambios deseados en los parámetros de la aplicación.

"Jesús" wrote in message
news:

¿Podrías orientarme en las diferentes posibilidades existentes de
comunicación entre la aplicación y el servicio y dónde puedo obtener
recursos
(links, documentación,etc)?

Posibilidades que se me ocurren:
1) Usar un Socket, con lo cual tienes que procesar las comunicaciones a
un nivel muy bajo. No creo que valga la pena, pero si quieres estudiarlo,
busca en el manual en linea la clase "TcpClient" y sigue los enlaces a
partir de ahi.
2) Usar .Net Remoting (o WCF si tienes el Framework 3.0). Es un
procedimiento de más alto nivel. Con este, declaras en el servicio cuál es
la clase que quieres publicar por remoting y qué puerto TCP quieres usar
para la escucha, y en el cliente configuras lo necesario para que se cree
una instancia remota de esa clase, y puedas llamar desde él a los métodos de
la clase (que se ejecutan en el servicio). Busca en el manual en línea un
artículo que se titula ".NET Framework Remoting Overview".
3) Usar otros mecanismos disponibles en el sistema operativo, tal como
colas de mensajes, memoria compartida o canalizaciones con nombre. Para usar
las colas, el problema es que no vienen instaladas en el sistema de forma
predeterminada. Y para los otros dos mecanismos, el problema es que habría
que "tirar" de P/Invoke porque (que yo sepa) no están encapsulados en las
librerías de .Net.
4) Para comunicaciones muy sencillas (un int a cada llamada), se puede
usar el método ExecuteCommand de la clase ServiceController.
5) Para pasarle un bloque de datos al servicio, o del servicio al
programa cliente, podrías usar un fichero en disco, y detectar los cambios
con un FileSystemWatcher, o bien señalizar una orden de lectura del archivo
con el ExecuteCommand. También podrías usar de forma similar una clave en el
registro de windows en lugar de un archivo en disco.

Lo más sencillo es usar el método 4 si basta para tu aplicación. Si
tienes que pasar datos más complejos, el 5 (posiblemente de forma conjunta
con el 4). Y si necesitas una comunicación bidireccional y muy interactiva
entre el servicio y el programa de configuración, el 2.

Excelente explicación.

Muchas gracias Alberto por tu ayuda y tu tiempo.

Seguro que volveré por aquí ya que soy bastante profano en la materia.

Un saludo.

Jesús.

"Alberto Poblacion" wrote:

"Jesús" wrote in message
news:
> ¿Podrías orientarme en las diferentes posibilidades existentes de
> comunicación entre la aplicación y el servicio y dónde puedo obtener
> recursos
> (links, documentación,etc)?

Posibilidades que se me ocurren:
1) Usar un Socket, con lo cual tienes que procesar las comunicaciones a
un nivel muy bajo. No creo que valga la pena, pero si quieres estudiarlo,
busca en el manual en linea la clase "TcpClient" y sigue los enlaces a
partir de ahi.
2) Usar .Net Remoting (o WCF si tienes el Framework 3.0). Es un
procedimiento de más alto nivel. Con este, declaras en el servicio cuál es
la clase que quieres publicar por remoting y qué puerto TCP quieres usar
para la escucha, y en el cliente configuras lo necesario para que se cree
una instancia remota de esa clase, y puedas llamar desde él a los métodos de
la clase (que se ejecutan en el servicio). Busca en el manual en línea un
artículo que se titula ".NET Framework Remoting Overview".
3) Usar otros mecanismos disponibles en el sistema operativo, tal como
colas de mensajes, memoria compartida o canalizaciones con nombre. Para usar
las colas, el problema es que no vienen instaladas en el sistema de forma
predeterminada. Y para los otros dos mecanismos, el problema es que habría
que "tirar" de P/Invoke porque (que yo sepa) no están encapsulados en las
librerías de .Net.
4) Para comunicaciones muy sencillas (un int a cada llamada), se puede
usar el método ExecuteCommand de la clase ServiceController.
5) Para pasarle un bloque de datos al servicio, o del servicio al
programa cliente, podrías usar un fichero en disco, y detectar los cambios
con un FileSystemWatcher, o bien señalizar una orden de lectura del archivo
con el ExecuteCommand. También podrías usar de forma similar una clave en el
registro de windows en lugar de un archivo en disco.

Lo más sencillo es usar el método 4 si basta para tu aplicación. Si
tienes que pasar datos más complejos, el 5 (posiblemente de forma conjunta
con el 4). Y si necesitas una comunicación bidireccional y muy interactiva
entre el servicio y el programa de configuración, el 2.