Salve,

a breve dovrò cimentarmi nella relizzazione di un sistema di supevisione per un impianto. Volevo realizzare un Web Service per creare i metodi di interrogazione delle apparecchaiture e la distribuzione dei dati su piattofome eterogenee (PC di supervisione, Palmare o cellulare, PC in Teleassistenza, Sito internet) . Secondo la vostra esperienza quali sono i vantaggi e quali gli svantaggi? Grazie

Ciao,
al momento non ho risposte da darti, ma prossimamente dovro' seguire anche io un progetto simile, se sei d'accordo possiamo fare una "collaborazione" aiutandoci a vicenda.

Buona serata.
Max.

Volentieri...

Con un PC in remoto, tramite un WS puoi evitare le grane dei Firewall in quanto passando attraverso http e la porta 80 non dovresti avere blocchi. Effettivamente tutta la categoria di situazioni che hai elencato si trova a suo agio con i WS. Sono riuscito a passare un datatable costruito in VB.NET ad un programma fatto in VB6 tramite un WS (smanettando con XML ovviamente)
Penso sia una scelta giusta.
Svantaggi, eventualmente, li hai se dovessi cimentarti in oggetti che non supportano la IXmlSerializable e quindi gestirti "a mano" la serializzazione/deserializzazione; ma si supera anche questo.

Saluti

Ciao,
effettivamente la potenza dei WS è entusiasmante . Ho realizzato un servizio per far accedere un Palamare alle info di un DB Access di software realizzato in VB6. Ma lo scenario in cui mi sto avventurando è un pò più complesso :

1) Un Server è colleagto attraverso la seriale alle apparecchiature di processo

2) Il server ospita il WS con i metodi che estraggono i dati processo

3) Sul server è presente anche un software di supervisione (sviluppato in .Net) che, appoggiandosi al WS, mostrerà lo stato del processo e delle macchine.

4) alcuni Clients della rete attraverso una versione "lite" del supervisore avranno accesso ai dati

5) Le informazioni saranno accessibili a Clients di natura diversa (ad es. PDA) che attraverso una versione "Mobile" del supervisore si connetteranno (ad es. in GPRS) al WS per ottenere i dati

6) I dati saranno accessibili anche attraverso una o più pagine ASP.Net (quindi Internet)

Utopia ?

I miei dubbi sono:
A) prestazioni
B) sicurezza
C) necessaità di implemenatre Thread

Avete consigli?
Ciao

possibilissimo, magari costruisci un servizio sul server che effettua un polling per interrogare le apparecchiature



(Correggetemi se sbaglio..) Il WS può essere interrogato dai vari client, quindi accede al servizio ed ottiene i dati necessari per inviarli ai richiedenti



Se intendi che esiste anche la possibilità di un programma desktop che monitorizzi in forma grafica e/o esponendo dati, come sopra, interroghi il servizio et voilà!



come al punto 3) puoi accedere al servizio (che sovrintende alla gestione dei dispositivi) da qualunque client ed avere ciò che vuoi



E qui sta la potenza dei WS, appoggiandosi a IIS puoi interrogarli da chiccessia!!



E qui dipende da come vuoi implementare i vari "servizi" ed a quello non ci sono limiti!!

Comunque, bella sfida! Complimenti e buon lavoro!

Federico

Grazie per l'incoraggiamento...
come mi consigli di implementare i servizi?

Per la gestione dell'apparecchiatura (coloquio seriale?)
realizzi un Servizio Windows che se ne sta in memoria all'avvio di Windows e sovrintende al colloquio.
Per il colloquio tra i vari client, ed anche un WS in questo caso diventa client, utilizzerei il Remoting.

Ma questa è una mia personale opinione. C'è WCF (Windows Comunication Foundation) ma per me è ancora molto oscuro.

Saluti

bhè la connessione avviene attraverso un Gateway Seriale / Ethernet e supporta un max di 4 client collegati.

Pensavo di realizzare il Web Service e attraverso questo accedere ai dati delle apparecchiature. Visto che le risorse HW sono limitate pensavo di accedere ai dati solo attraverso i metodi dello stesso. Ad es. metodo leggi_stato e ottengo il valore. Ma il metodo apre la connessione legge quello che serve, chiude la connesione e restitisce i dati. ma forse è troppo macchinoso... e i dati da estrarre sono molti

Puoi spiegarmi meglio qs. punto?

Idem
Saluti

Ti fornisco un indirizzo da dove partire, e dove sono affrontati vari scenari, sul remoting (WS fa parte di Remoting, solo che sfrutta il protocollo http su una porta 80 e lavora con xml)
http://msdn2.microsoft.com/it-it/library/kwdt6w2k(VS.80).aspx

Una soluzione interessante anche se da studiare da zero... sono proprio bianco in materia

Però non capisco l'utilità del Web Service visto che in tutte le piattaforme software posso implementare la versione client dell'oggetto server e accedere ai dati. Non è un passaggio in più?

La mia idea era quella di interrogare direttamente le apparecchiature con oggetti realizzati lato Web Service:

1)la connessione al web service comporta l'attivazione di una sessione e quindi la connessione ai dispositivi
2) Il polling è a richiesta del client.... se il client è il software di supervisione la letteura dei dati avviene ogni msec., se il client è una pagina asp avviene ogni sec.
3) La chiusura della sessione comporta la chiusura della connessione e la restituzione delle risorse HW impegnate.

Che ne pensi...

Il web service vive alla richiesta di un client. Se dovessi avere due o più richieste di polling non ti sarebbe facile (e qui correggetemi) gestire i conflitti di richieste multiple alle apparecchiature.

Una volta dovetti affrontare una situazione in cui dovevo interrogare un microscopio computerizzato per distribuire le immagini a più client, questo dispositivo tra l'altro aveva web server, ftp server e telnet server a disposizione. Il problema era che se arrivavano più richieste contemporaneamente il server ftp andava letteralmente in blocco. Realizzai quindi un "servizio" che si occupava di accentrare le richieste ed effettuare una sola interrogazione al microscopio così da limitarne gli accessi.

Se hai esigenze particolari di gestire le risorse HW i punti 1, 2 e 3 non fanno una piega, sono corretti. A volte però la continua richiesta di aperture e chiusure di potrebbero avere effetti più pesanti di una connessione persistente alle apparecchiature.

Saluti

In teoria potrebbero esserci problemi solo se la risorsa HW. fosse unica. Anche se interrogassi da n client il Web Service con una sola risorsa HW (es. 1 com seriale) il problema sarebbe proprio quello da tè descritto.

Ma, sempre in teoria , per la connessione ai dispositivi sto utlizzando un Gateway Seriale / Ethernet che mi assicura un certo numero di client collegati. In qs. modo potrei collegarmi ai dispositivi con max. n client attraverso un indirizzo IP. e un numero di porta.


qs. è una delle mie paure...

Nonostante tutto la soluzione alternativa potrebbe essere quella da te suggerita del gestore di comunicazione (qui dovrei utilizzare i Threading per sincoronizzare il dialogo seriale e la comunicazione coi clients). Per la comunicazione potrei utilizzare anche i sockets.

Saluti

Rispondo al primo messaggio perché quotare tutto il thread, interessantissimo sarebbe proibitivo, ti do quindi solo un opinione.

Come Fededi ha specificato, il Webservice Risponde quando chiamato, non lavora da solo, pertanto, se tu hai delle apparecchiature che devono fornire dati, magari collegate ciascuna ad un PC che riceve dati via seriale con un programma dedicato, io opterei per una soluzione di questo genere:

1) Tutti i PC che ricevono dati, in qualsivoglia forma essi siano li memorizzano su un supporto fisico, quindi un database access, un file di testo, un database SQL Server o qualsiasi altro tipo di file binario.
2) Che i dati siano omogenei (tutti Access, tutti file di testo, tutti DB Sql) oppure eterogenei (Uno in Access, uno in Testo csv, uno in testo XML, uno in file binario) Tramite un Job schedulato su ciascuna macchina singola fai "concentrare" tutti i dati su un PC che sarà il tuo Server primario.
3) Sul server primario costruisci un servizio che si occupa di rendere i dati omogenei, ad esempio inserendoli su un database SQL Server che conterrà varie tabelle che rappresentano i dati delle singole apparecchiature oppure degli aggregati dei dati ricevuti che possano poi fornire a chi interroga il database i dati che servono.
4) Un Webservice espone i metodi di interrogazione più opportuni al tuo database per fornire i dati necessari alle varie apparecchiature che devono gestire i vari aspetti del funzionamento dell'impianto, quindi il Gestionale o il programma di Magazzino che raccolgono dati di produzione, piuttosto che il capo del servizio manutenzione che legge i dati funzionali e le checklist delle macchine da remoto.
5) Se hai bisogno di poter "Chiamare" tu dal server per segnalare problemi oppure semplicemente che una macchina ha bisogno di essere rifornita o altri tipi di messaggi, allora direi che puoi utilizzare i servizi di E-mail, usualmente un buon server di e-mail può trasmettere non solo posta ma anche SMS oppure puoi realizzare un programmino per palmare oppure per laptop o desktop oppure per smartphone dotato di internet faccia una interrogazione temporizzata al webservice per sapere come và dal server stesso.

Direi che è un bel progetto, e se ti serve maggiore consulenza, soprattutto sui webservices, sono certa che Rudy se stuzzicato un pochino risponderà con tutti i consigli pratici che ti possono servire... quanto me, se si tratta di rimestare dati, chiedi pure e anche con i servizi me la cavicchio

saluti
Sabrina

Innnzitutto grazie a tutti per i contributi



Certo.... ma si tratta di un sistema di supervisione di un processo automatizzato con dei PLC. Non ho la necessità di immagazzinare informazioni ma solo di visualizzare / comandare in tempo reale. Pensavo di realizzare il software di supervisione principale è installarlo nello stesso PC che ospita il Web Service (che poi è lo stesso che è collegato al processo). Il software di supervisione , anzichè essere un servizio windows, è un software, a tutti gli effetti, di gestione dell'impianto solo che, per estrarre le informazioni dal processo (ad esempio temperatura olio), anzichè interrogare la seriale, chiede al Servizio Web di passargli il dato formattato e completo. Come ribadito, il web service passa solo i dati istantanei e solo quando vengono richiesti... quindi sta al software principale rimanere attivo 24/24h e richiedere le info ogni x ms. Tutta la gestione avenzata dei dati (storici, Database, Comunicazioni via SMS, etc.) è delegata al software pricipale. I clients estraggono i dati istantanei interrogando ogni x*1000 ms il web service e gli storici con query al database, etc.

vorrei seguire qs. ipotesi di lavoro per semplificare l'architettura del sistema. Si potrebbe realizzare un sistema a socket (il PC collegato alla rete rimane in ascolto e trasmette i dati ai client che ne fanno rischiesta) ma dovrei implementare i protocolli di comunicazione e variarli ogni volta che si attuano ampliamenti all'impianto... per la tipologia di impianto da gestire (tempi di reazione dello stesso abbastanza lenti) ho preferito il WS.



A tal proposito... come faccio ad aumentare le stelline del Thread?

Ciao a tutti