Aplicación web HTML5: elegir la tecnología del servidor

Question

En este momento, elijo tecnologías para una aplicación móvil crossplatform simple. Los sistemas de destino son básicamente iOS, Windows Phone 7.5 y Windows 8. En el primer paso, se tratará de una aplicación LAN inalámbrica local.

Existen servidores (que usan .net/WCF) que tienen todos los datos que quiero mostrar. La aplicación sondeará cada pocos segundos y ofrecerá una vista en vivo de los datos. No accederé directamente al servidor de datos, pero tengo que crear mi propio servidor de aplicaciones en el medio.

Para el cliente elegí el enfoque HTML5, CSS, JavaScript (JQuery) para que funcione en cualquier navegador moderno. Entonces tendré que comunicarme vía http.

Mi pregunta es qué tecnología usar para el servidor de mi aplicación. Tengo que recibir solicitudes http, obtener datos (en el mejor de los casos vía WCF) de otro servidor y enviarlos al cliente como xml o html. (No estoy muy seguro de si el servidor o el cliente tiene que convertir datos XML en HTML)

Buscando en la web me di cuenta de dos enfoques posibles:

• ASP.net
• Construyendo mi propio servidor HTTP sencilla utilizando WCF

Buscando en algunas documentación y ejemplos ASP.net me dio la impresión de que simplemente funciona de la forma que conozco desde PHP, etc ... (el cliente envía la solicitud, el servidor ejecuta un script/programm, servidor envía la respuesta , el programa termina) No puedo guardar objetos en memoria y ejecutar código independiente de las solicitudes del cliente. O al menos no está diseñado para funcionar así. ¿Es eso correcto?

Eso me obligaría a construir mi propio servidor muy simple que puede responder algunas solicitudes http específicas.

Así que mis preguntas son:

• son mis suposiciones sobre ASP.net correcta? ¿O me salió algo mal?
• ¿Sería un servidor http propio el camino a seguir?
• ¿Puede recomendar algún otro enfoque (en el mundo de Microsoft/.net)?

Gracias de antemano ...

Answer 1

Hay un sinnúmero de tecnologías web que podría hacerlo, pero lo que se destaca para mí es la siguiente:

servidores

Hay existentes (utilizando .net/WCF) que tienen todos los datos que quiero mostrar.

Ya tienes .net pateando y no puedo evitar pensar que la forma más rápida de obtener datos de un servidor .net/WCF es con un cliente .net/WCF.

Por esa sola razón, iría con asp.net MVC. Le brinda una ruta rápida y fácil para acceder a sus datos y le deja mucha flexibilidad con la forma de manejar la parte "V" (páginas HTML directas, ajax con datos xml o json, etc.)

Solo el último mes asp .net mvc fue lanzado bajo la licencia de código abierto Apache 2.0.

Para su uso-caso, me gustaría mantener bien lejos de formularios web ASP.NET y asp.net ajax

edición:

no puedo guardar objetos en la memoria y ejecutar código independiente del cliente peticiones. O al menos no está diseñado para funcionar así. ¿Es eso correcto?

ASP.net (como muchos de los servidores de aplicaciones) tiene tanto sesión y ámbitos de aplicación puede almacenar datos en. También puede crear subprocesos en segundo plano para realizar trabajos fuera de la norma request-> lifycycle respuesta.

Answer 2

Lo que puedo decir es:

Utilizar las tecnologías de código siempre abierto :-). Hay docenas de bibliotecas/frameworks para escribir muy buenos servidores web, pero si necesita un cuncurrency alto, puedo sugerir el uso de frameworks basados ​​en eventos y no basados ​​en thread/process.

Node.js (como dijo @withadot) pero también Python Tornado son una buena opción.

Answer 3

Puede echar un vistazo a APE (Ajax push Engine), ya que su aplicación requiere sondeo. Se basa en javascript y actúa como un servidor Comet.

Alternativamente, también puede utilizar uno de los servicios de pago por empujar (por lo que no debe preocuparse mucho acerca de las tecnologías de servidor)

1) Pusher

(Desde la página principal impulsor: Pusher es una API para alojada de forma rápida, fácil y segura de añadir funcionalidad en tiempo real escalable para web y aplicaciones para móviles.)

2) UrbanAirship

Como @Fabio mencionó Python Tornado se puede utilizar alternativamente para sondeo. Es un servidor COMET, y muchas aplicaciones web en tiempo real se basan en esto. Hay muchos tutoriales disponibles en el sondeo con NodeJs. Una simple búsqueda en Google me llevó a este article.

Answer 4

Los datos cuando se accede a través de un dispositivo móvil van a ser costosos. Por lo tanto, preferiría usar JSON/XML para enviar los datos por cable. Iría con un enfoque RESTful para recuperar los datos con WCF Restful services/ASP.NET Web API en .NET stack. Además, si considera el uso de la batería, debe evitar el sondeo y debe usar los marcos de señalización. En .NET stack tenemos SignalR que hace esto. Esto notificaría a los clientes cuando los nuevos datos estén disponibles y el cliente iniciará una nueva solicitud para recuperar los datos.

Si desea experimentar con las nuevas tecnologías, sugiero usar node.js en el lado del servidor y socket.io para comunicarse con los clientes para la lógica de señalización.Además, preferiría escribir la aplicación cliente utilizando el espacio de teléfono & javascript para que pueda ser fácilmente portado a varias plataformas.