Componenti della distribuzione di ThingWorx Foundation
I componenti di ThingWorx possono essere considerati a tre livelli: client, applicazione e dati. Nell'immagine seguente viene illustrato un punto di partenza di base per qualsiasi soluzione ThingWorx:
 |
Oggetti/dispositivi: contiene oggetti, dispositivi, agenti e altri asset che si connettono a ThingWorx Platform, inviano dati e ricevono contenuto da questa piattaforma.
Utenti/clienti: contiene i prodotti (soprattutto browser Web) che gli utenti utilizzano per accedere a ThingWorx Platform.
|
|
Piattaforma: corrisponde al livello di applicazione, ovvero alla posizione in cui risiede ThingWorx Foundation fungendo da hub di un sistema ThingWorx. Questo livello fornisce connettività al livello client, esegue controlli di autenticazione e di autorizzazione, inserisce/elabora/analizza contenuto e reagisce a condizioni come l'invio di avvisi.
|
|
|
Database: gestisce i metadati del modello di runtime e i dati di sistema ThingWorx.
• I metadati del modello includono le definizioni delle entità e degli oggetti ThingWorx e quelle delle proprietà associate.
• Dati della fase di esecuzione inseriti nel modello ThingWorx. I dati possono essere tabulari o di serie temporali resi persistenti dal modello ThingWorx, come righe di contenuto in blog, wiki, stream, stream di valori e tabelle dati.
|
Con l'aumento delle funzionalità e della complessità della soluzione ThingWorx, aumentano anche le esigenze di architettura all'interno di ogni livello.
Nelle sezioni riportate di seguito viene presentato ogni componente di una soluzione ThingWorx all'interno del livello in cui opera il componente.
Componenti utente/client
L'utente o il client che accede a ThingWorx Platform tramite ThingWorx Composer o i mashup in fase di esecuzione deve disporre di un browser moderno che supporti HTML/HTML5 (ad esempio Microsoft Edge, Firefox, Safari o Chrome).
Componenti oggetto/dispositivo
• ThingWorx Edge MicroServer - ThingWorx Edge MicroServer (EMS) funziona con dispositivi edge o archivi dati che devono connettersi al server ThingWorx su Internet. Attiva i dispositivi e gli archivi dati che si trovano dietro i firewall per comunicare in modo sicuro con il server ThingWorx e partecipare appieno nel panorama della soluzione. ThingWorx EMS non è un semplice connettore. Consente di spostare l'intelligenza e la pre-elaborazione dei dati sull'edge.
• ThingWorx Edge SDK - Sono raccolte di classi, oggetti, funzioni, metodi e variabili che forniscono un framework per la creazione di applicazioni che possono inviare i dati in modo sicuro dai dispositivi edge a ThingWorx Platform. I ThingWorx Edge SDK forniscono gli strumenti per gli sviluppatori esperti nei linguaggi di programmazione C, .NET e Java.
ThingWorx EMS e i ThingWorx Edge SDK supportano le connessioni tramite proxy. Il processo di amministrazione della configurazione del proxy e della relativa gestione delle modifiche varia a seconda del cliente e/o del progetto. I ThingWorx Edge SDK offrono la massima flessibilità perché le librerie SDK possono essere incluse o referenziate da qualsiasi componente edge personalizzato e pertanto possono essere aggiornate in base alla progettazione della soluzione.
Componenti della piattaforma
• ThingWorx Connection Server - È un'applicazione server che agevola la connessione dei dispositivi remoti e gestisce l'instradamento dei messaggi da e verso i dispositivi. ThingWorx Connection Server offre una connettività scalabile su WebSocket utilizzando il protocollo di comunicazione ThingWorx AlwaysOn. PTC consiglia di utilizzare i server connessioni quando vi sono più di 25.000 asset per scaricare la gestione delle connessioni dal server ThingWorx Foundation. I server connessioni sono necessari nelle configurazioni a disponibilità elevata per distribuire le connessioni dei dispositivi nei nodi di cluster attivi. PTC consiglia inoltre almeno un server connessioni per ogni 100.000 connessioni simultanee al server ThingWorx Foundation. Questo rapporto tra i dispositivi e il server connessioni può variare in base a molti fattori, ad esempio:
◦ Numero di dispositivi
◦ Frequenza degli invii di scrittura dai dispositivi
• Tomcat - Apache Tomcat è un contenitore servlet open source sviluppato da Apache Software Foundation (ASF). Implementa le specifiche del servlet Java e di Java Server Pages (JSP) di Oracle Corporation e fornisce un ambiente server Web HTTP Java puro per l'esecuzione del codice Java.
• Server ThingWorx Foundation - ThingWorx Foundation fornisce un ambiente di progettazione, esecuzione e intelligenza completo per le applicazioni machine-to-machine (M2M) e IoT. È progettato per creare, eseguire e sviluppare in modo efficiente le applicazioni che controllano e segnalano i dati da asset remoti, ad esempio i dispositivi connessi, le macchine, i sensori e le apparecchiature industriali.
ThingWorx Foundation funge da hub dell'ambiente di ThingWorx. Comprende insiemi di strumenti che consentono di sviluppare applicazioni per definire il comportamento degli asset remoti (o dispositivi) distribuiti nell'ambiente e le relazioni tra gli asset.
Una volta che gli asset sono stati modellati, possono effettuare la registrazione e comunicare con ThingWorx Foundation, permettendo di monitorare e gestire i dispositivi fisici e di raccoglierne i dati.
Componenti del database
ThingWorx Platform offre un modello di archivio dati collegabile che consente a ciascun cliente di scegliere il database più adatto alle proprie esigenze, dalle piccole implementazioni per gli ambienti dimostrativi o di training ai database con volumi elevati altamente disponibili che supportano migliaia di transazioni al secondo.
Gli stream di valori, gli stream, le tabelle dati, i blog e i wiki vengono definiti come provider di dati per ThingWorx. I provider di dati sono considerati database che memorizzano dati di runtime. I dati di runtime sono dati che sono persistenti dopo che gli oggetti vengono composti e utilizzati dai dispositivi connessi per memorizzare i relativi dati (ad esempio la temperatura, l'umidità o la posizione). I provider di modelli sono utilizzati per memorizzare i metadati per gli oggetti.
I provider di persistenza possono contenere un provider di dati, un provider di modelli o entrambi.
Per informazioni dettagliate sulle opzioni di database, fare riferimento a Provider di persistenza.
Componenti a disponibilità elevata
La disponibilità elevata rappresenta una considerazione critica per la continuità aziendale. Per essere efficaci, i componenti a disponibilità elevata devono essere applicati ai livelli dell'applicazione e del database.
A partire dalla release 9.0, ThingWorx può essere distribuito in una configurazione cluster con più nodi server attivi che elaborano la logica aziendale e le richieste degli utenti. Questa configurazione sostituisce la configurazione di failover attiva-passiva fornita nelle release precedenti.
In una configurazione cluster, i server connessioni sono obbligatori per distribuire le connessioni dei dispositivi nei nodi di cluster attivi.
Il livello dell'applicazione ThingWorx richiede Apache ZooKeeper e Apache Ignite come componenti aggiuntivi. I requisiti dei livelli del database a disponibilità elevata dipendono dalle esigenze dei provider di dati selezionati.
 | La disponibilità elevata non riguarda solo la reale efficacia dello stack software, ma va oltre. È inoltre necessario valutare l'infrastruttura ridondante, ad esempio alimentatori, dischi rigidi e infrastrutture di rete (router, bilanciamenti del carico, firewall e così via). |
• ZooKeeper - Apache ZooKeeper è un servizio centralizzato per il mantenimento delle informazioni di configurazione, la denominazione, la sincronizzazione distribuita e l'erogazione di servizi di gruppo. Si tratta di un servizio di coordinamento per l'applicazione distribuita che consente la sincronizzazione in un cluster. Specifico di ThingWorx, ZooKeeper viene utilizzato per monitorare la disponibilità dei nodi di cluster e, in caso di errore, sceglie un nuovo nodo leader di ThingWorx Foundation.
• Ignite - Apache Ignite è un database distribuito open source, una piattaforma per la memorizzazione nella cache e l'elaborazione progettata per memorizzare e calcolare grandi quantità di dati in un cluster di nodi. In una distribuzione cluster di ThingWorx, Ignite viene utilizzato per memorizzare e mantenere una cache condivisa per i dati del dispositivo in tutti i nodi del cluster.
Distribuzione a disponibilità elevata con impronta minima
Ignite può essere eseguito incorporato all'interno del processo di ThingWorx Foundation, che non richiede un'installazione separata. Ignite incorporato deve essere eseguito solo quando l'impronta dell'ambiente è più importante delle prestazioni. Va utilizzato per ambienti di piccole dimensioni che richiedono solo elevata disponibilità e non scalabilità. Non è scalabile e non è una soluzione appropriata per i problemi di prestazioni.
In uno scenario di Ignite incorporato a due server l'unico vantaggio riguarda la lettura. Ignite contrassegna alcuni dati come principali nel server A, alcuni dati come principali nel server B e l'altro server come backup per i dati. In genere tutte le letture si rivolgono al server principale per i dati. Questa operazione può essere o meno una chiamata remota. In Ignite incorporato la differenza principale è che è possibile impostare su true la lettura da backup. In questo caso le letture non eseguono hop di rete.
Indipendentemente dal fatto che passino o meno allo stesso computer, le scritture determinano la creazione di un backup nell'altro computer. Pertanto per le scritture non vi è alcun vantaggio in termini di prestazioni.
A seconda delle dimensioni della macchina, l'esecuzione di Ignite incorporato può ridurre le prestazioni. Esiste una differenza tra un'impostazione di ThingWorx a server singolo e un'istanza del server Ignite in un cluster a disponibilità elevata:
• La memoria è condivisa con la piattaforma. Ignite aggiunge altre code e altri oggetti, oltre ad archiviare la memoria delle proprietà.
• Il numero di thread che può essere attivo in una JVM in qualsiasi momento è limitato e dipende dal numero di CPU. Ignite richiede molti thread per elaborare le richieste, eseguire il backup dei dati e per alcuni task di eccezione. Un server singolo non prevede questo carico.
• Tutti gli oggetti da e verso la cache vengono serializzati all'interno e all'esterno della cache in un sistema a disponibilità elevata, cosa che non accade con il livello della cache Caffeine in un'impostazione a server singolo.
Funzionalità di disponibilità elevata del database
• PostgreSQL - ThingWorx supporta l'utilizzo di PostgreSQL a disponibilità elevata come soluzione dati. La disponibilità elevata offre la possibilità di configurare server distinti per l'acquisizione di letture e scritture per i dati in caso di errore sul server principale. Per ulteriori informazioni, fare riferimento a PostgreSQL in ambienti a disponibilità elevata.
• SQL Server - In genere, la SQL Standard Edition è adatta agli ambienti di produzione in quanto supporta la maggior parte delle funzionalità richieste. Per le impostazioni di produzione che richiedono funzionalità a disponibilità elevata, OLTP in memoria o il partizionamento di tabelle e indici, la soluzione consigliabile è SQL Enterprise Edition. Per ulteriori informazioni, fare riferimento a Microsoft SQL Server in ambienti a disponibilità elevata.
• InfluxDB Enterprise - Fornisce una versione cluster del database InfluxDB. Il clustering consente la condivisione dei dati nei nodi per supportare sia la disponibilità elevata che la scala orizzontale, permettendo l'esecuzione di letture e interrogazioni in server diversi per aumentare la scalabilità dell'intero sistema. Il numero di nodi di dati può essere facilmente espanso per supportare nuovi carichi di lavoro. Per ulteriori informazioni, fare riferimento a Utilizzo di InfluxDB come provider di persistenza.