2012-10-12 81 views
5

Tenemos una herramienta heredada de terceros (desarrollada en C/C++). La herramienta tiene un componente de servidor que ejecuta un servidor de Windows que ejecuta trabajos (consultas complejas de bases de datos encadenadas). También tiene un módulo de cliente que está instalado en todos los escritorios de los usuarios y los usuarios podrán agregar trabajos, ver trabajos en ejecución y su progreso, eliminar trabajos, es decir, administrar básicamente los trabajos. Queremos desarrollar tal herramienta internamente utilizando tecnologías .NET.¿Cómo se puede diseñar esta aplicación cliente/servidor en .NET?

Actualmente estamos pensando en cómo diseñar una herramienta así y parece que nos faltan algunas piezas críticas del rompecabezas.

Cliente: Decidimos que la aplicación cliente de escritorio que se desarrollarán en WPF

Servidor: Actualmente estamos pensando desarrollarlo como aplicación de consola, pero no muy seguro de cómo diseñar la misma.

Las principales preguntas que tenemos son

¿Cómo puede una aplicación de consola de servidor exponer ASMX o servicios web WCF (WPF para que los clientes obtienen el estado de los trabajos) sin dejar de ejecutar los trabajos?

Cómo enviar actualizaciones de progreso del servidor a los clientes de WPF cuando hay un cambio?

Estamos tratando de investigar cómo hacer esto pero no encontramos nada relevante al tema. Cualquier sugerencia sobre artículos/orientación será de gran ayuda.

+0

Posible duplicado: http://stackoverflow.com/questions/11170457/discussion-client-server-application-architecture –

+0

@MikeMcCaughan El enlace que mencionas parece ser similar pero NO es, en mi caso, mi servidor tiene un largo trabajo que hacer además de servir a los clientes. – Aron

+0

Pruebe esto: http://dasunhegoda.com/architecture-products/1180/ – Techie

Respuesta

3

La confusión que está teniendo es en asumir que la ejecución del trabajo y el punto final WCF son la misma cosa. Lo dividiría en tres elementos principales:

  1. Cliente Aplicación que tiene los elementos de la interfaz de usuario para la administración del trabajo.
  2. Punto final del servicio WCF para recuperar información del trabajo y enviar solicitudes de creación/eliminación de trabajos.
  3. Aplicación que ejecuta los trabajos.

aplicación de cliente de aplicación

El cliente debe recuperar los datos de los trabajos a través del servicio de WCF.Se podría suministrar pantallas para visualizar los trabajos de Ejecución/crear puestos de trabajo/eliminar trabajos/etc

WCF Servicio

El servicio WCF expondría a los puntos finales que necesita la aplicación cliente. Esto podría incluir elementos tales como: CreateJob, ViewJobs, DeleteJob, etc. El servicio debería leer/escribir en el back-end de su base de datos.

solicitud de empleo solicitud

El trabajo sería sondear en busca de empleos/eliminados y llevar a cabo lo que sea necesario para el trabajo se complete. Actualizaría el estado del trabajo en el back-end de la base de datos desde el que lee el servicio WCF. Esto podría ser un trabajo SQL, servicio de Windows, aplicación de consola, etc. (probablemente lo convertiría en un servicio de Windows ya que probablemente desee algo que se ejecute todo el tiempo para procesar trabajos).

Preguntas

How can a server console application expose ASMX or WCF web services(so that WPF clients get the status of the jobs) WHILE CONTINUING TO RUN THE JOBS?

Al separar el servicio de WCF de la aplicación que se ejecuta los trabajos este es negado. Nota: Puede tener una aplicación de consola que aloje WCF y el ejecutor de trabajos, pero conceptualmente piense en ellos como cosas separadas (el alojamiento en la misma aplicación de consola es solo un detalle de implementación).

How to push progress updates from server to the WPF clients when there is a change?

yo no haría esto. Haría que la IU sondeara de vez en cuando o proporcionase un botón de actualización para recuperar el estado a través del punto final WCF.

Si necesita hacerlo, necesita que el ejecutador de trabajos publique los mensajes mientras ejecuta los trabajos y la aplicación del cliente debería recibir estos mensajes (tal vez MSMQ, Implementación del bus de servicio, BizTalk, etc.).

¿Por qué prefiero sondeo para server push

Ahora que lo pienso es probable que haya casos en los que haría estilo de empuje, y algunos donde sondeo.

Si tengo muchos clientes que se encuentran fuera del sitio (conectando a través de VPN o de Internet en general), los clientes tendrían que hacer sondeos como el ancho de banda y la latencia de la red son prohibitivos. Si la cantidad de clientes es alta, cada mensaje de actualización debe enviarse a cada cliente suscriptor. En este caso, yo tendería a ir a un modelo de preguntar y no contar.

Si los clientes están en casa y necesita información en tiempo real transmitida a ellos, entonces el modelo de inserción tendría más sentido. En este caso, los clientes pueden conectarse a la aplicación del servidor y pueden enviar mensajes de ida y vuelta por la conexión (no he hecho esto personalmente, así que no tengo ninguna recomendación sobre cómo configurar, con suerte algo más alto que un socket).

Si se trata de una situación en la que desea los mensajes a medida que se producen las actualizaciones, pero los clientes se encuentran en muchos lugares diferentes, entonces un modelo de pub/sub podría ser el mejor. En pub/sub, la aplicación enviaría mensajes de actualización a medida que ocurran. El sistema de mensajería verificaría si hay clientes que se suscriben a los mensajes, y para todos los clientes que se suscriben el sistema de mensajes les envía una copia del mensaje. En su ejemplo, un cliente llamaría subscribe a los mensajes de trabajo y el sistema de mensajes enviaría las actualizaciones a la ubicación especificada por el cliente (el cliente necesita una forma de aceptar mensajes).NServiceBus, BizTalk son ejemplos de este tipo de comunicación.

+0

Gracias por la explicación detallada. Muy cerca de lo que estoy buscando. ¿Puede explicar por qué prefiere las encuestas que el servidor push? – Aron

+0

Expandí mi respuesta con más pensamientos. Desde un nivel alto, tiendo a hacer encuestas debido a la comodidad y la familiaridad. Principalmente trabajo en aplicaciones web que se prestan al modelo de respuesta de solicitud. –

1

Parece que está preguntando sobre las opciones de alojamiento para los servicios de WCF. Hay cuatro opciones:

  1. autoalojamiento en una aplicación administrada - es decir, crear una aplicación de consola, otra aplicación WPF, etc., que a continuación, crea un servicio y lo mantiene con vida mientras ella (la aplicación de consola) está vivo.
  2. Managed servicios de Windows - crea un servicio de Windows que se puede iniciar automáticamente por Windows cuando se inicia
  3. Servicios de Internet Information Server (IIS) - huésped de manera similar a un servicio de ASP.NET
  4. Servicio de activación de procesos de Windows (WAS) - nuevo servicio de activación, no lo he usado personalmente.

Detalles completos here.

Para responder completamente a su pregunta, no utilizaría los servicios de ASMX. Para una buena lista de razones, vea this question.

Cuestiones relacionadas