Aplikacja internetowa HTML5 - wybór technologii serwerów

Question

Teraz wybieram technologie dla prostej, mobilnej aplikacji typu crossplatform. Systemy docelowe to w zasadzie iOS, Windows Phone 7.5 i Windows 8. W pierwszym kroku będzie to lokalna aplikacja bezprzewodowa LAN.

Istnieją istniejące serwery (używając .net/WCF), które mają wszystkie dane, które chcę wyświetlić. Aplikacja będzie odpytywać co kilka sekund i da podgląd na żywo danych. Nie będę mieć bezpośredniego dostępu do serwera danych, ale muszę utworzyć swój własny serwer aplikacji.

Dla klienta wybrałem podejście HTML5, CSS, JavaScript (JQuery), aby działało w dowolnej nowoczesnej przeglądarce. Więc będę musiał komunikować się przez http.

Moje pytanie dotyczy technologii, która ma być używana po stronie serwera mojej aplikacji. Muszę odbierać żądania http, pobierać dane (w najlepszym wypadku przez WCF) z innego serwera i wysyłać je do klienta jako xml lub html. (Nie jestem pewien, czy serwer lub klient ma do konwertowania danych XML do HTML)

przeszukiwania sieci zorientowali się dwa możliwe podejścia:

• ASP.net
• budowy mój własny prosty serwer HTTP za pomocą WCF

Patrząc na niektóre dokumenty ASP.net i przykłady mam wrażenie, że działa to tak, jak wiem z PHP itp ... (Klient wysyła żądanie, serwer uruchamia skrypt/program, serwer wysyła odpowiedź program kończy) Nie mogę zatrzymać obiektów w pamięci i uruchom kod niezależny od żądań klienta. Lub przynajmniej nie jest zaprojektowany do takiego działania. Czy to jest poprawne?

To zmusiłoby mnie do zbudowania mojego bardzo prostego serwera, który może odpowiedzieć na kilka konkretnych żądań http.

Więc moje pytania to:

• Czy moje założenia dotyczące ASP.net prawidłowe? A może coś złego?
• Czy byłby to własny serwer http?
• Czy możesz polecić inne metody (w świecie Microsoft/.net)?

góry dzięki ...

Answer 1

Istnieją niezliczone technologie internetowe, które mogłybyrobią to jednak rzecz, która wyróżnia się dla mnie jest to:

Są istniejące serwery (przy użyciu .NET/WCF), które mają wszystkie dane, które chcę wyświetlić.

A więc już masz .net dookoła i nie mogę przestać myśleć, że najszybszym sposobem pobrania danych z serwera .net/WCF jest klient .net/WCF.

Z tego powodu sam bym poszedł z asp.net MVC. Zapewnia szybką i łatwą ścieżkę dostępu do danych, pozostawiając użytkownikowi dużą elastyczność w sposobie obsługi części "V" (proste strony HTML, ajax z danymi xml lub json itp.)

Zaledwie w zeszłym miesiącu asp .net mvc został wydany na licencji open source Apache 2.0.

do użytku przypadku, będę trzymać się z dala od asp.net webforms i ASP.NET AJAX

edit:

nie mogę zachować w pamięci i obiektów kodu prowadzony niezależnie od klienta upraszanie. Lub przynajmniej nie jest zaprojektowany do takiego działania. Czy to jest poprawne?

ASP.net (jak wiele serwerów aplikacji) posiada zarówno sesji i zakresy zastosowań można przechowywać dane. Można również tworzyć wątki w tle do wykonywania pracy poza standardem request-> lifycycle odpowiedzi.

Answer 2

Co mogę powiedzieć to:

eksploatacji ZAWSZE technologii open source :-). Istnieją dziesiątki bibliotek/frameworków do pisania bardzo dobrych webserverów, ale jeśli potrzebujesz wysokiej cuncurrency, mogę zasugerować użycie frameworków opartych na zdarzeniach, a nie opartych na wątkach/procesowych.

Node.js (jak powiedział @withadot), ale także Python Tornado to dobry wybór.

Answer 3

Możesz zajrzeć do APE (Ajax push Engine), ponieważ twoja aplikacja wymaga odpytywania. Jest zbudowany na javascript i działa jak serwer komet.

Alternatywnie można również użyć jednego z płatnych usług do pchania (tak, że nie należy niepokoić się o wiele technologii serwerowych)

1) Pusher

(Z głównej popychacza: Pusher jest API dla gospodarzem szybko, łatwo i bezpiecznie dodawanie skalowalną funkcjonalność w czasie rzeczywistym do stron internetowych i aplikacji mobilnych.)

2) UrbanAirship

Jako że @Fabio wspomniany jako Python Tornado może być alternatywnie używany do odpytywania. Jest to serwer COMET i wiele aplikacji internetowych działających w czasie rzeczywistym. Istnieje wiele samouczków dostępnych podczas pobierania z NodeJs. Proste wyszukiwanie google doprowadzić mnie do tego article.

Answer 4

Dane dostępne po użyciu urządzenia mobilnego będą kosztowne. Tak więc wolałbym używać JSON/XML do przesyłania danych przez przewód. Zostałby z RESTful podejście do pobierania danych z WCF Restful services/ASP.NET Web API w stosie .NET. Ponadto, jeśli rozważasz użycie baterii, powinieneś unikać odpytywania i używać ram sygnalizacji. W stosie .NET mamy SignalR, który to robi. Powiadomiłoby to klientów, gdy nowe dane będą dostępne, a klient zainicjuje nowe żądanie pobrania danych.

Jeśli chcesz poeksperymentować z nowymi technologiami, proponuję użyć node.js po stronie serwera i socket.io do komunikowania się z klientami w celu uzyskania logiki sygnalizacji.Ponadto wolałbym napisać aplikację kliencką przy użyciu luki telefonicznej & javascript, aby można ją było łatwo przenieść na różne platformy.