Per prima cosa, sto lavorando a un'applicazione che gestisce un equipaggiamento fisico con motori, cose del genere. Quando ho iniziato il progetto, esisteva un'applicazione esistente, creata con Labview e in cattivo stato. La parte del codice che gestisce l'hardware, i "driver" erano in una forma migliore. L'obiettivo era scrivere una nuova app, in .Net, ma riutilizzando il più possibile i driver esistenti.
L'architettura che è stata decisa è stata quella di separare strongmente il lato hardware, scritto in Labview, e il lato gestione / trattamento dati scritto in C # attraverso l'uso di un servizio web REST, dal momento che Labview ha un relativamente buon supporto di essi. La parte hardware di Labview ha il ruolo del server e il lato .Net si connette attraverso di esso, richiede lo stato dell'hardware e invia il comando per spostare l'hardware e così via.
Finora funziona abbastanza bene, l'unica parte fastidiosa è la quantità di polling richiesta dal lato client. Abbiamo alcuni "comandi lunghi", per i quali inviamo un comando che chiede all'hardware di fare una lunga operazione, ma vogliamo avere alcuni aggiornamenti su come va. Per questo, inviamo il PUT per iniziare l'azione e quindi, ogni 500 ms (o più lentamente a seconda dell'azione), inviamo un GET per avere lo stato corrente dell'azione, fino a quando l'azione non viene eseguita (di solito definita da una bandiera ).
Quando ho iniziato il progetto, alcuni mesi fa, avevo visto questo problema e ho fatto delle ricerche per vedere se c'era una soluzione a questo problema, come un modo di usare SignalR per Labview e non trova qualsiasi cosa Ma ora, abbiamo trovato un'implementazione di un server WebSocket in Labview. Ora mi chiedo se e come questo possa essere implementato (o in sostituzione di) la nostra soluzione.
Una delle soluzioni che stavo immaginando era di mantenere il servizio REST per la maggior parte, ma creare al volo un endpoint WebSocket per quei pochi comandi di lunga durata che necessitano di aggiornamento. Ad esempio, inviare un comando PUT per eseguire un'azione, per cui il server avvia l'azione, restituire 200 OK e aggiungere l'indirizzo di un endpoint WebSocket in cui il client potrebbe andare per ottenere lo stato. Non appena il client si connette al WebSocket, il server invierà gli aggiornamenti attraverso questo. Al termine dell'azione, la connessione viene chiusa e l'endpoint WebSocket viene chiuso sul lato server.
Ho cercato un po 'per vedere se qualcuno stava facendo quel tipo di servizio "misto", ma non riesce a trovare nulla, quindi mi chiedo se sia davvero una buona idea. Anche se non sono un grande fan della quantità di polling che avviene ora, mi piace molto anche l'API REST che abbiamo creato e sento che sarebbe un po 'una perdita scartarla e andare completamente in modo WebSocket. Penso che WebSocket non sia ancora universale come REST (anche in .Net 4.5, la classe ClientWebSocket è utilizzabile solo in Windows 8, anche se esistono alternative). Usare WebSocket significa anche definire il nostro protocollo di comunicazione (come definire comandi, ecc.) Che può essere difficile.
In un certo senso, il mixaggio non sembra del tutto "giusto", perché non userò completamente il vantaggio "full-duplex" di WebSocket, principalmente usandolo per comunicare le informazioni di ritorno dal server al client in una sorta di "push", raramente inviando comandi dal client al server attraverso il web socket.