Un hub de centralisation

Grace à la plateforme Constellation vous pouvez connecter aussi bien des applications graphiques que des services, des pages Web ou n’importe quel objet connecté.

Sans une plateforme de “centralisation” vous êtes obligé de créer des liens directs entre les technologies / systèmes favorisant le syndrome du “plat de spaghettis” et monopolisant tous les efforts sur le développement de ces ponts.

L’objectif premier de Constellation est donc de jouer ce rôle de médiateur, afin de centraliser l’ensemble des programmes, services, applications ou objets de votre écosystème, de “votre Constellation”.

Tous vos systèmes peuvent donc s’appeler mutuellement (au sens invocation de méthodes) grâce aux MessageCallbacks et peuvent échanger des données, des variables en temps réel avec les StateObjects.

Mais au delà de facette “développement”, Constellation joue également un rôle de centralisateur du niveau réseau / infrastructure.

Imaginez intégrer dans une page Web les données produites par différents objets connectés développés en Arduino et interagir avec un service Web écrit en .NET et un autre en Python.

Sans Constellation  vous allez décider que chaque objet, script ou service vont exposer un service Web. Vous allez donc réaliser plusieurs fois la même chose : exposer un service en HTTP/S,  en gérant la sécurité, le log, le protocole, le format de donnée, etc. Et à chaque fois en utilisant des technologies différentes : .NET, Arduino et Python.

Vous allez donc passer beaucoup de temps et d’énergie sur des éléments de tuyauterie technique.

Une fois vos services déployés, il faudra renseigner dans votre application Web JavaScript, l’adresse et le port de chaque service ce qui peut devenir rapidement un casse-tête dès que vous commencez à avoir un certain nombre de service.

Vous devrez également gérer les éléments d’ouverture de port / flux réseau.

Pour compliquer encore plus le schéma, imaginez que votre service .NET doit avoir connaissance en temps réel des variables de vos Arduino. Il faut donc que votre service .NET ait également connaissance des adresses/port de vos Arduino ainsi que du contrat de service pour pouvoir interroger vos objets en temps réel sans dégrader leurs performances.

Et que faire si un objet est ajouté dans votre architecture, ou qu’une adresse IP change, qu’un objet est corrompu ?

Dans une architecture avec un centralisateur tel que Constellation, la seule chose que vous devez connaitre c’est l’adresse du serveur Constellation, le centralisateur (et également la clé de sécurité pour pouvoir s’authentifier sur Constellation).

Et d’un point de vue réseau, le seul prérequis est d’exposer le serveur HTTP/S. Tous les systèmes connectées à Constellation, que ce soit une application graphique, un service, un objet connecté, une page Web ou une application mobile sont tous “client” du service, ils n’ont besoin d’aucune configuration particulière.

Vous pouvez déployer vos systèmes sur n’importe quel réseau, du moment qu’ils sont accès au centralisateur Constellation, ils font partie de votre Constellation et peuvent donc “parler” avec tout le monde.

Constellation apporte donc un gain de temps considérable tant sur les phases de développement, de déploiement et d’administration ce qui vous permet de vous consacrez sur l’essentielle.