2010-03-18 7 views
7

Zajmuję się projektowaniem oprogramowania, które musi obsługiwać różne elementy sprzętu, głównie w oparciu o harmonogram, ale musi również mieć interfejs sieciowy do konfigurowania ustawień, konfigurowania harmonogramu, a nawet ręcznego sterowania sprzętem. Nie wiem, jak zaprojektować architekturę takiego oprogramowania.Jak zaprojektować .NET (C#) dla programu, który musi działać jako usługa systemu Windows, ale także mieć interfejs sieciowy?

Jedną z moich myśli było stworzenie usługi Windows, która umożliwia komunikację ze sprzętem, a także "publikowanie" usług internetowych za pośrednictwem WCF, a następnie posiadanie aplikacji ASP.NET, która następnie kontroluje usługę Windows poprzez WCF. Takie podejście wydaje się być bardzo pracochłonne dla tego, co próbuję osiągnąć.

Czy ktoś mógłby wskazać mi kierunek, czy jest to dobre podejście, a nawet dać mi lepszy sposób na zrobienie tego, jeśli taki istnieje?

Dzięki! Joel

+0

Ze względów bezpieczeństwa najlepsze rozwiązanie będzie zależeć od konfiguracji sprzętowej. W jaki sposób maszyny akceptują wnioski? Gdzie będzie Twoja strona internetowa w odniesieniu do twojej usługi Windows? Jakie firewalle są w to zaangażowane? Czy zamiast tego możesz uruchomić usługę systemu Windows, która sonduje usługę internetową i ma również interfejs użytkownika? – pdr

+0

Maszyna przyjmuje zamówienia głównie za pośrednictwem jednego lub więcej portów szeregowych (sieci RS485). Strona internetowa może znajdować się na tej samej maszynie, co usługa, ale podoba mi się możliwość ich podziału w razie potrzeby. Zapora prawdopodobnie nie będzie w tym przypadku problemem, ponieważ wszystkie będą znajdować się w tej samej sieci. Czy możesz wyjaśnić, co to znaczy być "usługą Windows, która sonduje usługę internetową i ma również interfejs użytkownika?" Nie wiem, jak usługa Windows może mieć interfejs użytkownika. – hjoelr

+0

Jeśli chcesz hostować interfejs sieciowy na innym komputerze, nie ma alternatywy dla myśli. – SLaks

Odpowiedz

1

Można utworzyć instancję punktu końcowego WCF jako usługę TCP z poziomu usługi systemu Windows, jak wyjaśniono w witrynie MSDN: How to: Host WCF in a Windows Service Using TCP.

Stamtąd relatywnie łatwo jest zająć ten punkt końcowy w aplikacji ASP.NET (to samo, co zużywanie dowolnego innego punktu końcowego WCF).

W przypadku braku jakichkolwiek istotnych powodów, aby postąpić inaczej, jest to prawdopodobnie podejście, które brałbym. Twoją jedyną opcją jest użycie innej formy IPC, na przykład plików mapowanych w pamięci lub nazwanych potoków. WCF jest o wiele łatwiejsze do uruchomienia.

+0

Oto rozwiązanie, do którego zmierzałem. Jednak nie miałem teraz zamiaru umieszczać serwera WWW ASP.Net w usłudze. Jeśli to wymaga, żebym nadal używał WCF do komunikacji, to może być jeszcze droga. – hjoelr

+0

Moje pytanie uzupełniające w odniesieniu do WCF jest: Czy byłby wystarczająco szybki, aby być pośrednikiem między interfejsem WWW a sprzętem?Nie sądzę, że mogę czekać wiele sekund na odpowiedzi WCF. – hjoelr

+1

@hjoelr: WCF jest bardzo szybki, nawet jeśli masz włączone szyfrowanie i inne rozszerzenia. Jestem przyzwyczajony do czasów odpowiedzi rzędu około 1/4 sekundy ze zdalnych serwerów; zwykle jedyne opóźnienie wynika z opóźnienia sieci, a jeśli wszystkie usługi działają na tym samym komputerze lub przynajmniej w tej samej sieci, opóźnienie powinno być prawie zerowe. – Aaronaught

0

Można po prostu użyć wspólnego pliku XML (lub czegoś), który usługa monitoruje dla zmian. Interfejs sieciowy mógłby po prostu odczytać/zapisać ten plik XML. Działa to dobrze tylko wtedy, gdy usługa i witryna są uruchomione na tym samym komputerze (możesz to zrobić także za pomocą udziału, ale to dodatkowa konfiguracja i możesz w takim przypadku po prostu przejść z WCF).

+0

Dobra myśl. Jednak musi istnieć dwukierunkowa komunikacja. Strona zbiera informacje z serwisu, ale strona musi również umożliwiać aktualizację ustawień i takich usług. – hjoelr

0

Można osadzić serwer sieciowy ASP.Net w usłudze za pomocą interfejsu API hostingu ASP.Net, a następnie użyć go do bezpośredniego uruchamiania witryny ASP.Net.

Należy pamiętać, że witryna ASP.Net byłaby uruchamiana w oddzielnym AppDomain.

+0

Nadal musisz jednak rozwijać stronę ASP.NET. To naprawdę nie wyklucza potrzeby wymyślenia środka komunikacji między aplikacją ASP.NET a usługą, pozwala tylko uruchomić cały pakiet bez usług IIS. – Aaronaught

+0

@Aaronaught: Możesz po prostu przekazać 'MarshalByRefObject', który udostępnia usługę' ApplicationHost.CreateApplicationHost' i współdziałać z nią w ASP.Net. (Projekt ASP.Net powinien odwoływać się do zespołu usług). – SLaks

+0

To jest interesująca koncepcja. Nie wiedziałem, że to nawet możliwe. Zobaczę, czy mogę się w to zagłębić, żeby sprawdzić, czy zadziała w mojej sytuacji. – hjoelr

Powiązane problemy