All posts in IoT

AWS IoT Greengrass et NBitcoin au menu du 3ème ApéroTech DocDoku

Le 27 juin dernier avait lieu la 3ème édition des ApéroTech dans nos locaux de Toulouse.

Au programme, présentation de 2 thèmes portés par des collaborateurs passionnés, suivie par un bon moment de convivialité en ce début d’été.

AWS IoT Greengrass

Premier thème abordé : comprendre ce qu’est le Edge Computing et ses applications.
Passionné de nouvelles technologies et persuadé des applications prochaines de l’internet des objets, Pierre a donné aux participants les clés de cette notion et présenté en cas d’usage le fonctionnement de Greengrass ou comment intégrer AWS dans un contexte IoT.

A la découverte de NBitcoin

Benjamin a ensuite guidé les participants dans la découverte de #NBitcoin pour #Csharp : de la construction d’une transaction Bitcoin à son transfert, puis à sa diffusion sur le réseau.  Au delà de l’usage en tant que cryptomonnaie, les perspectives de cette technologie sont très variées et l’assemblée a pu découvrir d’autres applications innovantes du Bitcoin.

Merci à nos deux talentueux orateurs et rendez-vous à la rentrée pour un prochain ApéroTech.

Bel été à toutes et tous !

Retour sur EclipseCon France 2018

En septembre 2017, Oracle annonçait sa décision, en accord avec les autres grands acteurs du marché que sont IBM et RedHat, de transférer les technologies JavaEE à la fondation Eclipse pour «rendre le processus d’évolution de ces standards plus agile» [4].
Cette annonce a provoqué un séisme au sein de la communauté Java et a levé de grandes interrogations sur l’avenir de la plateforme, sur le positionnement du projet Eclipse MicroProfile et sur l’état d’avancement de cette transition.
Comme chaque année DocDoku1 était présent à l’EclipseCon France 2018, rendez-vous annuel de la communauté Eclipse à Toulouse.
Comme à chaque fois un thème est à l’honneur. Cette année il était légitime que ce soit le tour de la plateforme «entreprise» pour Java d’être sous le feu des projecteurs.
Étant moi même à l’affût d’information sur l’avenir de cette plateforme, j’ai profité de l’unique journée à laquelle j’ai pu venir, pour me concentrer sur JakartaEE et MicroProfile.

JakartaEE

JakartaEE

Au début de cette année, la communauté a choisi le nom JakartaEE pour désigner ce qu’Oracle appelait JavaEE. En effet Oracle a souhaité conserver ses droits sur la marque Java, il fallait donc trouver un autre nom.
Pourtant à la fin de l’année 2017 la fondation Eclipse avait annoncé la création du projet Eclipse Enterprise for Java (EE4J).

EE4J ou JakartaEE ?

Eclipse Enterprise for Java [5] est le projet «chapeau» pour tout ce qui concerne les technologies JavaEE, c’est à dire les API mais aussi les implémentations de référence transférées aussi par Oracle.
Eclipse JakartaEE Platform [6] est donc un sous-projet de EE4J qui reprend ce qu’était la spécifiaction de la plate-forme JavaEE : la définition d’un environnement d’exécution résultant de l’agrégation d’un ensemble spécifications d’API.
On trouve naturellement par ailleurs un sous-projet pour chaque API (Servlet, EJB, …) mais aussi les implémentations de références développées au sein de la fondation Eclipse ou par Oracle comme Yasson, EclipseLink, Glassfish, Grizzly, Jersey, …

Où en est la transition ?

Tout d’abord la procédure de transfert est longue car Oracle doit faire des vérifications (propriété intellectuelle, licence, …) pour chaque élément transféré.
En outre, les CTS2/TCK3 d’Oracle ne sont pas libres.
Nous apprenons que la transition se fera en plusieurs étapes :

  • Rendre JakartaEE 8 officiellement compatible avec JavaEE 8.C’est à dire obtenir une implémentation de référence JakartaEE qui passe les CTS/TCK actuels d’Oracle.
  • Fournir des CTS/TCK libres pour JakartaEE et s’assurer que l’implémentation de référence JakartaEE passe avec succès ces tests.
  • Une fois ces deux objectifs atteints JakartaEE pourra évoluer selon le processus normal de la fondation Eclipse.

En regardant l’état d’avancement on peut voir que la migration d’une bonne partie des projets est déjà bien avancée.

Un point sur les licences

Le système actuel de licence d’Oracle (CDDL4 et GPL5v2 des spécifications, API et RI ; TLDA6 pour l’usage des TCK et de la marque JavaEE) vont également changer en Eclipse Public License (EPLv2)

Comment la plateforme évoluera-t-elle ?

Les API sortent du giron de JCP7 et des JSR8 pour rejoindre le système des Working Group d’Eclipse et du processus de spécification de la fondation.
Grâce à ce changement, l’Eclipse Foundation espère une plus grande agilité et flexibilité.$
On nous indique que la stratégie d’évolution sera la standardisation a posteriori des bonnes idées qui ont fait leurs preuves à l’instar des exemples célèbres comme Hibernate, Weld, Jersey qui ont donné JPA, CDI et JAX-RS.
Notons que le JCP ne disparaît pas, il continue de fonctionner pour ce qui concerne JavaSE.

JakartaEE vs. MicroProfile

JavaEE 6 a vu l’arrivée de la notion de profil (Web Profile, Full Profile) au sein de la plateforme JavaEE. Le constat de l’époque étant que toutes les applications n’avaient pas besoin de l’ensemble des technologies de la plateforme.
Avec l’arrivée du Cloud Computing et succès des architectures micro-service (comprendre à base de VM), Eclipse MicroProfile propose une spécification de profil encore plus minimal, concurrent direct de Spring Boot [7], basé essentiellement sur les API standard CDI, JAX-RS et JSON-P auxquelles s’ajoutent quelques API nouvelles (Config, Health, Metrics, …).

MicroProfile

Eclipse MicroProfile [8] est donc une spécification alternative d’un ensemble d’API adaptées à la mise en œuvre d’applications architecturées sous forme de micro-service.
D’abord basé sur un nombre très limités d’API, la plateforme évolue comme le montre le tableau [Table:1]

Évolution de Microprofile
API/MicroProfile 1.0 1.1 1.2 1.3 1.4 2.0
CDI 1.2 2.0
JSON-P 1.0 1.1
JAX-RS 2.0 2.1
Config 1.0 1.1 1.2 1.3
Health Check 1.0
Metrics 1.0 1.1
Fault Tolerance 1.0 1.1
JWT Propagation 1.0 1.1
Open Tracing 1.0 1.1
Open API 1.0
Rest Client 1.0 1.1
JSON-B 1.0

Une des forces des spécifications ouvertes, comme pour JEE, est de permettre de fédérer divers éditeurs. Grâce à cela il existe plusieurs implémentations de MicroProfile (voir le tableau ci-dessous).

Implémentations de MicroProfile
Éditeur Implémentation
IBM Open Liberty [9]
RedHat WildFly Swarm [10]
Payara Payara Micro [11]
Apache Tomee [12]
Hammock Hammock [13]
Kumuluz KumuluzEE [14]

Avec les implémentations de MicroProfile, il est possible de déployer une application de plusieurs façons :

  • l’application, les dépendances et le runtime sont packagés dans un seul et même JAR exécutable.Format popularisé par Maven et Spring Boot, la taille de l’archive peut devenir si importante que cela peut poser des problèmes lors de déploiements fréquents (déploiement continu)
  • L’archive JAR contient l’environnement d’exécution, l’archive WAR les ressources métier et les éventuelles dépendances tierces.Avantage, Le WAR est plus léger à déployer car il ne contient que ce qui est spécifique au métier. Cela rappelle le mode de déploiement dans un serveur JavaEE.

12-Factor Application

Pour rappel, «Application à 12 facteurs» est une méthodologie pour construire des applications SAAS9.
Les 12 facteurs en question sont:

  1. Une seule base de code, versionnée (Codebase)
  2. Déclarer explicitement et isoler les dépendances (Dependencies)
  3. Ne pas stocker la configuration dans le code (Config)
  4. Tous les services sont vus comme des ressources «tierces» (Backing services)
  5. Stricte séparation entre la construction, la livraison et l’exécution d’une application (Build, release,run
  6. Les processus d’une application sont sans-étatProcesses
  7. Les services (Web) sont exposés via un port réseau (Port Binding)
  8. L’application se décompose en processus parallèles (Concurrency)
  9. L’application doit pouvoir être démarrée et arrêtée à la demande (Disposability)
  10. Garder les environnements (développement ,recette, production) aussi similaires que possible(Dev/Prod parity)
  11. Les logs sont un flux d’événements indépendant de la manière dont ils sont stockés (Logs)
  12. Les processus d’administration doivent s’exécuter dans le même environnement que l’application (Admin Process)

La présentation d’Emily Jiang [2] nous montre comment l’association de la plateforme MicroProfile et Kubernetes permettent de mettre en œuvre une application selon ces principes.

Codebase
Le code source de l’application est géré par Git (sur GitHub).
Dependencies
La construction et la gestion des dépendances est gérée par Maven.
Config
Les configmaps Kubernetes et l’API Config servent à injecter les propriétés de configuration dans l’application.
Build-Release-Run
Une plateforme d’intégration continue prend en charge le packaging pour chaque environnement.
Processes
L’API REST permet de mettre en œuvre les processus sans-état
Port Binding
Kubernetes et l’API Config sont responsable de l’affection des ports
Concurrency
Le découpage en micro-services et Kubernetes permettent de gérer la mise à l’échelle
Disposable
L’API Fault Tolerance permet de rendre l’application résiliente aux arrêts des processus.
Dev/Prod Parity
Kubernetes Helm permet de s’assurer que les différents environnements sont similaires
Logs
ELK10 permet d’indexer et de gérer les journaux.
Admin Process
L’outillage standard de Kubernetes (kubectl exec) permet des déclencher les processus d’administration.

Sécurité sans-état avec JWT

La sécurité est un aspect fondamental pour les applications d’entreprise, celui-ci est d’ailleurs pris en compte dans JavaEE (avec plus ou moins de souplesse) depuis les tous débuts de la plateforme.
Les architectures micro-service («SOA avec un nom sexy» dit Jean-Louis Monteiro [3]) ne font pas exception, mais l’aspect sans-état nécessaire pour faciliter la gestion de la charge change la donne.
Jean-Louis discute des inconvénients des différentes options d’authentification et de propagation des identités:

Basic Auth
présente plusieurs risques car :
– le couple login/motdepasse est envoyé à chaque requête,
– risque d’attaque DOS du référentiel de sécurité.
OAuth 2.0
basé sur une paire de jetons (access/refresh) recrée au final une session HTTP côté serveur pour garder une trace des jetons générés (et confiés au client) : cela consomme de la mémoire et du temps de calcul car chaque micro-service activé doit vérifier les tokens
JWT
est un format de jeton similaire à SAML mais codé en JSON. Ils contiennent des informations signées et potentiellement chiffrées. Dans ce cas de figure les informations signées, donc non altérables, sont stockées côté client.

L’association JWT + OAuth 2.0 permet de réduire considérablement les ressources nécessaires côté serveur : seules des références de jeton sont conservées (pour la révocation) et chaque service peut vérifier la signature du jeton de manière autonome.
Une présentation de la mise en œuvre de se mécanisme avec l’API JWT propagation de la plateforme MicroProfile vient enfin compléter la brillante démonstration.

JakartaEE + IOT

Une démonstration concrète de la mise en œuvre de technologies JavaEE et de l’Internet des Objets.
Payara Micro [11] est une déclinaison du serveur d’application Payara Server (basé sur Glassfish), pensée pour les micro-services «conteneurisés».
Ce micro-serveur d’application est compatible MicroProfile, mais malgré sa taille (moins de 70Mo),il supporte la mise en cluster, les connecteurs JCA, le Clustering, JCache, les EJB Timer, les événements CDI distribués.
Comment obtenir un serveur d’application si léger ? En faisant l’impasse sur les API historiques les moins pertinentes pour ce genre d’application m’a-t-on indiqué.
Grâce à sa légèreté, sans trop de compromis quant aux fonctionnalités, nous assistons à la démonstration d’une application capable d’agréger des données en provenance de capteurs (d’humidité dans le cas présent) à travers des applications JavaEE déployées sur des nano-ordinateur de type RaspberryPi.
Événements CDI distribués, connecteur JCA pour des échanges de messages asynchrone (MQTT), services REST sont au rendez-vous pour démontrer que les technologies JavaEE ont aussi leur place dans le monde des ressources contraintes de l’IOT.

Kubernetes : retour d’expérience

La fondation Eclipse est en cours de migration de sa plateforme d’intégration continue depuis Cloodbees Jenkins Enterprise vers une solution basée sur un cluster Kubernetes (OpenShift).
À partir de sa propre expérience de migration, Mikaël Barbero nous présente une excellente introduction à Kubernetes [1]
Kubernetes [15] est un système Open Source d’orchestration de conteneurs (VM) permettant d’automatiser le déploiement, la configuration, la gestion et la montée en charge d’applications ou de micro-service «conteneurisés».
Contrairement à la plateforme JavaEE où le conteneur – la machine virtuelle Java – est limitée à l’exécution de bytecode, les conteneurs (machines virtuelles) gérés par Kubernetes sont plus génériques car indépendants d’un OS, d’un langage et d’une plateforme pré-définis.
Là ou les serveurs d’application JavaEE permettaient d’orchestrer des machines virtuelles Java au sein d’un cluster, des outils comme Kubernetes réalisent sensiblement le même travail avec des conteneurs Docker dans le cas présent.
On perçoit comment ont évolués les usages ces dernières années: plutôt que de dépendre des capacités d’un serveur d’application JavaEE, limitées plus ou moins au monde Java, on préfère utiliser un outillage tiers pour gérer un cluster de machines virtuelles plus générales

Conclusion

Que ne lit-on pas ici et là sur la nature «monolithique» de la plateforme JavaEE, que l’on oppose à une architecture fragmentaire des micro-services.
Pourtant JavaEE/JakartaEE ne décrit pas comment doit être implémenté l’environnement d’exécution mais défini seulement un ensemble d’API qui doit être disponible et un format de packaging. Chaque type de composant est d’ores et déjà distribuable, alors pourquoi ne pourrait-on pas voir JEE comme la définition d’une PAAS11 tout à fait capable de construire des applications à base de micro-services ?
Est-ce la difficulté de morceler la plateforme comme ce qui a été réalisé lors des premiers profils (Web et Full) ? Est-ce la nécessité de conserver une compatibilité ascendante ?
Le succès des solutions MicroProfile (ou dans une certaine mesure Springboot ou Dropwizard) nous apprend que:

  • On doit pouvoir choisir les technologies strictement nécessaires à la mise en œuvre d’une application ou d’un composant applicatif.L’intégration de systèmes de modules dynamiques comme OSGI dans les implémentations des serveurs d’applications permet d’ores et déjà de ne charger en mémoire que les composants nécessaires, reste la configuration parfois complexe d’un domaine que l’on voudrait déléguer à des systèmes moins spécifiques.
  • Micro-service ou pas, le contexte des applications d’entreprise nécessite de disposer de solutions pour simplifier la mise en œuvre des aspects transverses (sécurité, transaction, distribution, tolérance aux pannes, métrologie, surveillance, journalisation, …).Il suffit, pour s’en convaincre, de regarder l’évolution des API de MicroProfile. Si les nouvelles API répondent à de nouveaux usages, elles peuvent également profiter à JakartaEE, mais à ce rythme MicroProfile restera-t-il «micro» ?
  • Le choix de la standardisation adoptée par Sun/Oracle ou la fondation Eclipse permet de fédérer les efforts des différents éditeurs et de favoriser la portabilité et l’interopérabilité.

Maintenant que JavaEE est en passe d’être libéré de la tutelle – soit-elle symbolique – d’Oracle, l’enthousiasme des participants à la conférence était au rendez-vous.
Grâce à la disponibilité de systèmes de virtualisation par conteneurs capables d’exécuter des composants (Java ou non); d’outils permettant la gestion d’infrastructures complexes de type Cluster ou Cloud; la modularité sera à mon avis le défi auquel devra répondre la plateforme JakartaEE, soit en intégrant ou définissant de nouveaux profils comme MicroProfile, soit plutôt en proposant une plateforme totalement modularisé pouvant être composée à la carte, à l’instar du travail réalisé sur JavaSE.
Demain, déployer une application JakartaEE consistera-t-il à découvrir à partir d’un paquetage les API utilisées, de provisionner un conteneur contenant le strict nécessaire et d’exécuter le tout ?
Merci enfin à toute l’équipe de la fondation Eclipse qui ont encore une fois réussi à organiser un événement fantastique.
Bravo à tous les conférenciers pour la variété et la qualité des présentations.

Références

1. Mikaël Barbero. 2018. Kubernetes 101. Retrieved from https://www.slideshare.net/mikaelbarbero/kubernetes-101-a-cluster-operating-system/
2. Emily Jiang. 2018. Build a 12-Factor Microservice in Half an Hour. Retrieved from https://www.eclipsecon.org/france2018/sites/default/files/slides/Build12FactorAppUsingMP.pptx
3. Jean-Louis Monteiro. 2018. Stateless Microservice Security via JWT, TomEE and MicroProfile. Retrieved from https://www.eclipsecon.org/france2018/sites/default/files/slides/2018_EclipseConEU_StatelessRESTSecurityWithMP-JWT.pdf
4. 2017. Opening Up Java EE – An Update. Retrieved from https://blogs.oracle.com/theaquarium/opening-up-ee-update
5. Eclipse Enterprise for Java. Retrieved from https://projects.eclipse.org/projects/ee4j
6. JakartaEE. Retrieved from http://microprofile.io/
7. Spring Boot. Retrieved from https://spring.io/projects/spring-boot
8. Eclipse MicroProfile. Retrieved from http://microprofile.io/
9. Open Liberty. Retrieved from https://openliberty.io/
10. WildFly Swarm. Retrieved from http://wildfly-swarm.io/
11. Payara. Retrieved from https://www.payara.fish/
12. Apache TomEE. Retrieved from http://tomee.apache.org/
13. Hammock. Retrieved from https://hammock-project.github.io/
14. KumuluzEE. Retrieved from https://ee.kumuluz.com/
15. Kubernetes. Retrieved from https://kubernetes.io/

  1. DocDoku est membre solution de la fondation Eclipse
  2. Compatibility Test Suite
  3. Tehnology Compatibility Kit
  4. Common Development and Distribution License
  5. Gnu Public License
  6. Technology License and Distribution Agreement
  7. Java Community Process
  8. Java Specification Request
  9. Software As A Service
  10. Elasticsearch, Logstash, Kibana
  11. Platform As A Service

Les enjeux de la sécurité des données – Episode 2/3

Sécuriser l’Internet des Objets

Dans l’IoT, les standards se mettent peu à peu à intégrer les problématiques de sécurité mais ce mouvement est cependant encore trop peu avancé. Le potentiel de calcul sur les données collectées peut être détourné pour un usage malveillant.

Dans ce contexte, quelle solution pour sécuriser ?

L’idée est d’abord de sortir de l’approche périmétrique en sécurisant la passerelle, et permettre ainsi la supervision des communications entre les objets.

De plus, au niveau de la plateforme de gestion des données IoT choisies, si bien sûr plusieurs critères doivent être évalués, il y en est un de crucial  : la capacité de celle-ci à gérer l’identité des dispositifs et individus s’y connectant.

Pour aller plus loin…

10 bonnes pratiques pour sécuriser l’IoT dans votre entreprise expliquées ici

  • Comprenez vos points de terminaison
  • Suivez et gérez vos appareils
  • Identifiez ce que la sécurité informatique ne peut pas traiter
  • Envisagez l’application de correctifs et de résolutions
  • Utilisez une stratégie pilotée par le risque
  • Procédez à des tests et des évaluations
  • Changez les références d’identité et les mots de passe par défaut
  • Observez les données
  • Appuyez-vous sur des protocoles de chiffrage à jour
  • Passez du contrôle au niveau des appareils au contrôle au niveau des identités

Comment l’IoT va transformer votre business

1 pile AAA : c’est l’unique source d’énergie requise pour alimenter pendant 13 ans un dispositif IoT qui générerait un message toutes les heures. Pour relayer l’information, un réseau LPWA (Low-Power Wide-Area) peut être mis en place. De longue portée même en zone très dense, ce réseau permet de transmettre des données au travers d’une configuration en étoile. Il est simple à déployer avec un nombre de stations radio réduit, consomme peu et ses coûts de souscription sont faibles.
Cela vous donne peut-être des idées pour vous développer dans l’IoT ?
Quelques points clés à retenir avant de vous lancer.

Trouver le lien entre objet et usage

Se lancer dans l’IoT, c’est rechercher de nouvelles sources de valeur dans la résolution de problèmes « basiques » ou dans des usages inédits, comme par exemple :

  • La bouche à incendie connectée : l’objet alerte la plateforme en cas de fuite. Il est ensuite possible de couper en direct l’arrivée d’eau depuis la plateforme
  • Le compteur d’eau connecté : pour alerter lorsqu’aucune consommation n’est relevée pendant une période donnée dans le cadre de la surveillance de personnes âgées restées à domicile ; dans l’hôtellerie pour vérifier le « point mort » quotidien (son absence démontre la présence d’une fuite)

Intégrer le bon support pour gérer vos données IoT

Vous aurez besoin d’une plateforme de stockage IoT. Elle a pour rôle de :

  • Piloter les objets (marche/arrêt, surveillance batterie, gestion des messages) et de provisionner les objets
  • Collecter les données produites par l’objet
  • Analyser les données

En effet, l’objet connecté en lui-même ou le réseau n’a aucune valeur : c’est bien la data produite qui en a.

Créer de la valeur pour votre business

L’IoT vous permettra d’enrichir votre offre ou de passer à la « next generation » de vos produits.
Une chaudière connectée permet aujourd’hui à son constructeur de créer une relation digitale avec son client final. Il peut assurer une maintenance en direct et donner des conseils personnalisés, en fonction de l’usage de son client.
De nouveaux services voient le jour. Avec l’amélioration de la précision des capteurs, il devient aujourd’hui possible de communiquer au client que sa livraison est à « X minutes de chez lui ».

Alors, quels usages avez-vous décidé de développer ?

Source : article rédigé suite à notre participation à Cloud Expo Paris.

Equipe-DocDoku

DocDokuHackathon 2017

DocDokuHackathon : Code et bonne ambiance


Comme chaque année, l’équipe DocDoku organise un hackathon après les fêtes de fin d’année. L’objectif de la journée : coder intensément pour obtenir un résultat le soir-même. L’occasion de se tester dans un esprit amical et d’émulation. Cette année, l’IoT, l’OpenData, les Chatbots, ainsi que le Machine Learning étaient les technologies à l’honneur !

 

9h : l’équipe entière prend place dans les bureau. Les mines sont concentrés et les équipes se forment :

Equipe 1
L'équipe numéro 1

Elle se compose de Charles, Hugues et Lucas. Leur projet est d’établir une connexion entre une smartwatch et un ordinateur de manière à ce que le porteur de la montre déclenche le démarrage de son ordinateur simplement en arrivant dans la pièce où il se trouve.

 

Equipe 2
Equipe2

Romain, Arnaud, Julien et Elisabel forment l’équipe 2 et ont choisi d’explorer la technologie des Chatbots en se servant de Slack comme client. L’objectif est de permettre à deux individus ou plus de jouer à Pokemon. L’idée leur est venue du buzz sur deux bots communiquant entre eux (article ici) et du phénomène Pokemon GO. Au niveau technique ils ont trouvé une « Open API » de type REST (REST est le mode de communication le plus en vogue de nos jours) : https://pokeapi.co/

 

Equipe 3
L’équipe 3 est composé d’Anass, Clément et Bertrand, ils ont quant à eux opté pour l’Open Data, en créant une application où tous les bars et toilettes publiques de Toulouse sont référencés. Les données sont récoltées sur Opendata Toulouse.

 

Equipe 4

Hoby-whan, Fabrice et Olivier se sont intéressés au machine learning.

Equipe 5

L’équipe 5 a elle choisi de travailler sur l’IoT et elle se compose de Guilhem, Sébastien, Frédéric et Yacine.

18h30 : L’heure des présentation a sonné. Chaque équipe expose et défend son projet. Après une journée de code et de recherches intensives, ainsi que de longues délibérations, l’équipe 1 composée de Charles, Lucas et Hugues est déclarée vainqueur.

20h30 : Fin de journée, la Team DocDoku se réunit autour du repas de début d’année avec au menu mojitos et tapas.

Retour sur l’EclipseCon France 2016 (partie 2)

eclipsecon

Cet article fait suite à celui de Bertrand, afin de détailler certains sujets et présenter d’autres sessions auxquelles j’ai eu l’opportunité d’assister.

iotConnecting low power IoT devices with LoRa, MQTT, and The Things Network

De mon point de vue, l’IoT était vraiment à l’honneur cette année à Toulouse, notamment par la présence de The Things Network, ayant été invité par la Fondation Eclipse à donner un workshop et à tenir la première Keynote de la conférence.

Comme l’a mentionné Bertrand, cette équipe venue tout droit d’Amsterdam est en train de fédérer des communautés du monde entier autour de leur réseau dédié aux objets connectés, basé sur la technologie LoRa.

Alors qu’est-ce que LoRa ? Et qu’est-ce que The Things Network ?

LoRalora

D’après le site de la LoRa Alliance (traduit par mes soins) :

LoRa est un diminutif pour LoRaWAN™: Low Power Wide Area Network (LPWAN).

LoRa est donc une spécification de communication sans fil basée sur les fréquences radio ISM (https://en.wikipedia.org/wiki/ISM_band).

Cette technologie est tout particulièrement adaptée comme couche de communication pour les objets connectés en ce qu’elle permet la localisation et la mobilité des appareils, à basse consommation, sans grosse installation de départ, ainsi qu’une communication bi-directionnelle.

Avec une simple antenne disposée en haut d’un immeuble en milieu urbain, ou dans un environnement plus dégagé, LoRa permet de connecter un nombre impressionnant d’appareils sans dégradation, bien plus qu’un routeur sans fil (WiFi, Bluetooth) et en consommant bien moins d’énergie et en étant moins onéreuse qu’un routeur 3G par exemple.

Quelques exemples d’utilisation:

  • Réseaux électriques : prédire la consommation et produire de l’électricité en fonction des besoins réels
  • Logistique : livraison avec une localisation plus précise
  • Transport : appels d’urgence automatisés
  • Santé : appareils de mesure de constantes
  • Et tellement plus…

LoRa est en concurrence avec la technologie SigFox, que nous connaissons bien à Toulouse. Cependant son approche est différente, puisqu’à la différence de la technologie SigFox qui est propriétaire et induit des coûts de license, la spécification LoRa est libre.

Quelques relevés ayant été effectués par l’équipe de The Things Network, et autres caractéristiques :

  • Environnement urbain dense : 500m à 3km
  • Environnement rural : 10-50km (jusqu’à 92km lorsque très dégagé)
  • Jusqu’à 10.000 appareils par routeur
  • Jusqu’à 3 ans d’autonomie (à prendre avec des pincettes)
  • Très basse consommation (et pas de « handshake »)
  • License libre, en envoi et réception
  • Pas de pré-requis à l’installation d’un tel réseau
  • Couverture multiple (plusieurs routeurs peuvent relayer l’information).

Les appareils se connectant au réseau LoRa peuvent être classés en trois catégories :

  1. Liaison montante uniquement, l’appareil initie la communication et le serveur peut y répondre.
  2. L’appareil et le réseau se synchronisent sur une « fenêtre de tir » afin d’échanger des données.
  3. L’appareil est en écoute constante du réseau.

Evidemment les classes d’appareils influent sur leur consommation.

The Things Networkttn

The Things Network est une initiative née à Amsterdam, pour construire un réseau mondial et libre permettant la communication entre objets connectés.

Après une campagne de crowfounding, les membres de l’équipe ont commencé la création d’une plateforme Web afin de permettre la connection d’appareils via des brokers.

Tout le code source applicatif de The Things Network est open source et disponible sur Github, pour aller de pair avec leur engagement pour permettre une vaste adoption de ces technologies.

En parallèle, une entité commerciale propose des Starter kits à visée éducative ainsi que des routeurs afin de permettre aux gens d’équiper leurs quartiers, leurs villes et d’initier le mouvement pour une couverture mondiale.

Des communautés existent déja de part le monde, principalement en Europe pour le moment. Ces communautés sont parfois à l’origine des membres de l’équipe de The Things Network, qui voyagent beaucoup afin de faire connaitre la technologie LoRa et leur projet, et parfois il s’agit d’initiatives spontanées.

A titre personnel, j’espère qu’une communauté verra le jour prochainement à Toulouse.

What every Java developer should know about AngularJS

angular

Tout est dans le titre.

Cette session était dédiée aux développeurs plus habitués aux technologies backend et qui voulaient avoir une introduction au framework le plus en vogue actuellement côté frontend: AngularJS.

Ce workshop fut l’occasion de présenter succintement les controlleurs, les scopes, les services et autres directives, sous la forme d’un mini TP.

En tant que développeur fullstack ayant des bases d’AngularJS, je trouve que ce workshop a été bien mené, en plusieurs étapes afin d’itérer et d’introduire successivement de nouveaux concepts sur le petit cas concret présenté.

Les speakers ont même fait le choix de baser le code d’exemple sur TypeScript, afin de ne pas trop perturber leur audience plus habituée aux constructions objets classiques qu’à la spécification ECMAScript. Mes co-équipiers ont pu retrouver leurs petits dans un projet architecturé sur une base d’interfaces et d’implémentations, agrémenté de types génériques et autres héritages. Ils ont cependant eu affaire à la pauvreté du tooling Eclipse pour ce qui est du développement front.

Le tooling, parlons-en justement.

Tooling

Cette année les visiteurs ont pu assister à plusieurs sessions sur l’état des outils de développement intégrés à Eclipse. Voici un petit tour d’horizon des outils dont j’ai pu avoir un aperçu lors des sessions.

JSDT 2.0

Ce talk était dédié à la présentation du la nouvelle version des JavaScript Development Tools (JSDT), actuellement en cours de développement.

Les objectifs de JSDT 2.0 sont de supporter les méthodes et outils de l’état de l’art actuel du développement JavaScript moderne.

Actuellement, JSDT 2.0 profite d’un nouveau parseur bien plus efficace que le précédent, notamment capable de supporter la spécification ECMAScript 6.

Le reste des objectifs s’axent autour de l’intégration de gestionnaires de paquets (npm / bower), des « task builders » (grunt, gulp) ainsi que le support de Node.js et l’ajout d’outils de débugging et d’intégration avec les navigateurs, notamment Chrome.

The State of Docker and Vagrant Tooling in Eclipse

Chez DocDoku nous expérimentons déjà les outils Vagrant et Docker, notamment pour nos environnements de développement et d’intégration, afin de fournir à nos équipes une infrastructure immutable et des processus de déploiement répétables.

Dans cette présentation, j’ai pu avoir un aperçu de deux plugins, l’un pour l’intégration de Docker, et l’autre pour celle de Vagrant.

En l’état actuel, ces deux plugins présentent de nouvelles « perspectives » dans l’IDE Eclipse, qui permettent de faire tout (ou presque) ce qu’il est possible de faire en ligne de commande:

  • Créer et gérer ses « box » Vagrant.
  • Configurer son Vagrantfile.
  • Créer et configurer ses machines virtuelles.
  • Créer et gérer ses images Docker.
  • Lister et manager ses containers Docker.
  • Editer son Dockerfile.

Continuous Delivery: Pipeline As Code With Jenkinsjenkins

Pour ma part, j’étais très curieux de voir ce qui allait être présenté dans ce talk. La perspective de pouvoir gérer ses builds sous forme de « pipelines » de traitements et la notion de « Continuous Delivery » (ainsi que le « Continuous Deployment » mais c’est un autre sujet) m’intéressent beaucoup.

Alors de quoi s’agit-t-il ? Principalement de ce que l’on pourrait décrire par la capacité d’orchestration, d’interruptibilité et de résilience de vos jobs de build. Rien que ça…

Comme décrit dans les slides de la présentation, que ce passe-t-il lorsque vous avez des jobs de build assez complexes, inter-dépendants, nécessitant des inputs d’opérateurs et éventuellement nécessitant de tourner en parallèle ?

Hormis le fait de créer de multiples jobs individuels que vous lierez par la suite en une cascade de builds à la chaîne, il n’y a pas de solution clé.

C’est ce problème que propose de résoudre le « Jenkins Pipeline Plugins », qui est en réalité un regroupement de plugins permettant d’orchestrer vos builds de manière plus fine. A la base de ce plugin se trouve un DSL, le « Pipeline DSL », qui permet de décrire l’enchainement des builds, sous forme d’étapes, et d’y attacher des options de configuration, comme le parallélisme pour n’en citer qu’une.

Il devient alors possible, par exemple, de configurer plusieurs dizaines de jobs similaires (à quelques variables près) formant de briques de bases (les dépendances d’un job de build suivant) et d’ordonner l’exécution de tous ces builds en parallèle, avant l’exécution du build suivant qui en dépend. Tout en spécifiant que la séquence de build complète doit stopper en cas d’échec d’un seul de ces builds de base (fail-fast).

Pour l’anecdote, le speaker a présenté exactement cet exemple, sur un cluster de build mis à sa disposition par un fournisseur « cloud » :

  • 336 CPUs
  • 1.032 TiB RAM.

Evidemment on a tous le même dans notre garage…

Quoiqu’il en soit, j’étais assez intrigué par le choix d’un DSL, en opposition à une description déclarative via des fichiers de configuration.
Il est assez facile d’imaginer comment décrire via des structures de données simples telles que des maps et des collections, l’orchestration d’un job, et la description de chacune de ses étapes.

Je n’ai pas eu de réponse claire à ce sujet, si ce n’est le poids de l’histoire : la plupart des contributeurs étant des développeurs Java, un DSL (très proche de Java d’ailleurs) semblait un choix logique.

Conclusion

Pour ma première participation à un évènement comme celui-ci, je dois dire que je suis conquis. L’organisation était parfaite et la qualité des intervenants largement satisfaisante.

J’aurai plaisir à participer de nouveau à l’EclipseCon, et je recommande à tout développeur ayant la possibilité de s’y rendre, d’y aller sans hésiter.

L’ensemble des vidéos des Keynotes et des sessions est à retrouver sur la chaine Youtube de la Fondation Eclipse, ici.

EDIT 26/07/2016:

Un nouvel article est apparu sur le site de Fondation au sujet du tooling Docker, le voici: http://www.eclipse.org/community/eclipse_newsletter/2016/july/article2.php

2016 sera consacrée à coupler l’IoT avec notre plateforme DocDokuPLM

2016 sera consacrée à l’Internet of Things (IoT)

Comme nous l’avions en effet évoqué lors du SIANE 2015, salon des partenaires de l’Industrie du grand sud, sur lequel nous exposions au sein de l’espace de l’Usine du Futur, 2016 sera en effet consacrée à l’IoT pour DocDoku.

La problématique : comment compléter les données théoriques avec les données terrain ?

Notre équipe R&D continue en effet d’innover en travaillant sur une nouvelle brique de notre pateforme capable de rapprocher et d’analyser avec pertinence les données théoriques issues du PLM et les données captées en situation réelle (capteurs physiques restituant au travers d’un IoT gateway les données au PLM).

La demande des industriels pour l’usine du future nous conforte en effet dans notre effort pour compléter notre plateforme DocDokuPLM avec une brique dédiée notamment à la maintenance prédictive permettant ainsi d’améliorer la prédiction des pannes et d’anticiper les défaillances des équipements / produits. Mon prochain billet sera spécialement dédié à ce sujet.