Komunikacja między usługą SERVICE a aplikacją internetową/komputerową

Question

Jaki jest zalecany sposób komunikacji między usługą a aplikacją komputerową lub stroną internetową?

Chcę, aby usługa wykonała całą pracę, ale administracja/zarządzanie/raportowanie jest możliwe za pośrednictwem strony internetowej lub pulpitu pod adresem . (Zostanie napisany w języku C# z .Net 4.0)

Czy nazywa się rury? gniazdka? wcf? odpoczynek ? mydło? inny ? Jaka jest najlepsza praktyka?

Wszelkie informacje będą mile widziane.

Usługa musi być efektywna w czasie rzeczywistym, więc wszelkie komunikaty muszą być asynchroniczne.

Dzięki Andrew

UPDATE 1 - sieć monitorów usług REALTIME ruch jako usługa. Klient może być lokalny lub może być zdalny (przy użyciu ASP.NET/MVC lub nawet silverlight). Klient nie potrzebuje danych w czasie rzeczywistym, ale powinien zapytać o ustawienia SETTINGS, statystyki, logi itd.

Answer 1

Jeśli oba końce kodu są kontrolowane, to z wyjątkiem konkretnych wymagań, wybrałbym WCF, ponieważ "To takie proste".

Zobacz Choosing a (WCF) Transport: to łatwo przejść od HTTP TCP Named Pipes (ooo la la!):

Nazwany potok jest obiekt w działającego jądra systemu Windows, takich jak sekcja pamięci współużytkowanej, którą procesy mogą wykorzystać do komunikacji [czytaj: bardzo szybki]. Nazwana potoczka ma nazwę i może być używana do jednokierunkowej lub dwustronnej komunikacji między procesami na jednej maszynie.

Oczywiście, jeśli sam wymóg maszyna jest naruszone, a następnie HTTP/TCP może być używany zamiast w zależności od konfiguracji sieci, etc - różnica na kod? Ustawienie konfiguracji :)

Szczęśliwe kodowanie.

Answer 2

Pytanie jest zadawane jako WCF lub HTTP lub TCP. WCF jest niezwykle elastyczną podstawą komunikacji. Możesz napisać swój kod jeden raz i udekorować swoje klasy danych i przełącznik latania poprzez konfigurację i kod pomiędzy HTTP JSON/POX, TCP, Binary, Binary przez HTTP, niestandardową serializację itp. Pytanie, który mechanizm transportu wybierasz oparte na ograniczeniach routingu/firewalla, klientach itp. ... Osobiście lubię diagnostyczne transporty takie jak HTTP i JSON/XML tylko dlatego, że są uniwersalne, rutowalne i możliwe do rozpoznania (checkout fiddler2).

Z Twojego opisu wydaje się, że trudną częścią problemu jest monitorowanie ruchu w sieci REALTIME, które wykonuje usługa. Kanał między klientem a tą usługą wydaje się być prostszą częścią problemu.

Również z opisu, klient nie musi być PRAWDZIWYM CZASEM i po prostu wysyła zapytanie do statystyk, ustawień i logów. Ponieważ klient może być lokalny lub zdalny (zdalnie sugerując, być może poza intranetem, routing zewnętrzny).

Z tego względu oddzieliłbym proces zbierania statystyk sieciowych REALTIME od części zapytań, co czyni ją asynchroniczną, o której wspomniałeś. W tym momencie usługa otwiera po prostu kanał dla klientów w celu wysyłania zapytań dotyczących prostych statystyk, ustawień i dzienników ... wybierz najbardziej rutowalny i możliwy do rozpoznania kanał, taki jak HTP, REST JSON | XML. Jeśli to jest problem, zachowaj nienaruszony kod serwera WCF i zmień konfigurację powiązań WCF.

Pytanie jest nieco otwarte i niejednoznaczne, ale mam nadzieję, że trochę pomaga.