Middlewares RFID : conduite à droite ou à gauche ?

11 Septembre 2006

Encore un papier signé Patrick Bonneau, suite notamment au dossier middlewares RFID paru sur DataCollection et dû à la plume de votre serviteur

Pour ceux qui veulent avoir une vision globale de ces progiciels, nous conseillons de suivre le lien suivant : http://www.editricetemi.com/ed_temi/dcFr/articolo.jsp?idArt=142

Quelle route faut-il prendre en matière d’architecture et de middleware RFID ?

Premier conseil n’investissez pas trop dans les middleware coûteux, ils le sont pratiquement tous aujourd’hui (sauf quelques produits gratuits et le projet open source libre de SourceForge : ndlr) et ne seront bientôt qu’une boîte noire supplémentaire, pas si incontournable que cela.

Deux sociétés ont montré la route depuis 2003/2004 Seebeyond (achetée par Sun fin 2004) et SAP (seulement en concept pour l’instant, ou tout au moins en labo.)

Seebeyond a pris la route du ‘Service-Oriented Architecture (SOA) pragmatique’, c’est tout du moins comme cela qu’on le nommait aux States il y a encore quelque temps.

En fait cette société a compris avant tout le monde que dans le domaine de l’ «Internet of Things », ainsi qu’il en sera avec la technologie RFID, lorsque différents systèmes ne peuvent partager leurs données effectivement, ceux-ci créent des goulets d’étranglement qui nécessitent l’intervention humaine sous la forme de prise de décision ou de saisie manuelle sur écran.

L’architecture du type Entreprise Application Integration (EAI) prend de plus en plus d’importance parce que l’informatisation des entreprises prend de plus en plus la forme d’îlots d’automation.

Si l’intégration des différentes applications est appliquée sans approche structurée de type EAI, les connexions point-à-point grandissent d’un bord à l’autre de la société.

Les dépendances entre systèmes sont ajoutées de façon improvisée, induisant un désordre total difficile à contenir. Ceci fait communément allusion à ce que l’on appelle une organisation de type spaghetti, référence au ‘spaghetti code’.

L’architecture faisant appel à des middlewares est reliée à des technologies telles que Message-Oriented Middleware (MOM), à des systèmes de données de type XML.

Les modes plus élaborés d’architecture EAI font appel à SOA basée sur les Web Services afin d’encapsuler les données et leurs fonctions à un niveau supérieur.

C’est là qu’entrent en jeu Java et les applications composites (mashups, entre autres).

RFID : J2EE , une évolution incontournable.

Les applications composites ? Disons que tout le travail fait ces dernières années est l’équivalent de ce qui est arrivé à la programmation avant de passer de la programmation structurée à celle orientée objet.

Sun est passé par d’étranges péripéties internes et ceci a malheureusement freiné l’équipe Seebeyond qui s’est ressaisie en créant à partir de leur suite ICAN et leur concept EAI (particulièrement efficace) la nouvelle plateforme d’intégration de systèmes RFID & sensors du nom de Java Composite Application Platform (JCAPS) depuis Juillet 2006* ainsi que du projet SUN-RFID d’ailleurs qui est totalement différent par l’approche ‘classique’ du type middleware -.

Je reparlerais rapidement de SAP en citant les x-Apps, applications composites à la sauce allemande

(concept équivalent, mais les revendeurs SAP mettent du temps à s’y mettre).

Les applications composites et leur réutilisation c’est comme pour la programmation objet et les classes d’objets, plus il y en a, mieux c’est.

Après viennent Oracle avec leurs applications composites en mode Eclipse Java sur la plateforme Project Fusion et IBM qui a compris très tôt les avantages de SOA, mais qui a mis un peu de temps à se rendre compte ce qu’il pouvait en tirer avec les technologies du type RFID ; rassurez-vous IBM recolle allègrement au peloton de ce côté-là ! Il faut dire sans aucune pub que cette société a vraiment compris SOA.

Et puis il y a un quarteron d’ingénieurs de l’IEEE particulièrement brillants qui nous ont inventé l’architecture Service-Oriented Device Architecture (SODA, ça ne s’invente pas…!), sorte de SOA spécialement pour les Mesh networks (mon favori), les Wireless Sensor Networks et systèmes RFID. Ce n’est encore que conceptuel mais toutefois opérationnel…….et puis il y a les ingénieurs qui ont travaillé sur le protocole Simple Lightweight RFID Reader Protocol (SLRRP, après le Soda pourquoi pas…) qui ont rejoint EPCglobal afin de donner plus d’intelligence aux futurs lecteurs standards RFID

; bref, quel intérêt désormais d’acquérir un middleware lourd et cher...........! Car comme disait Piéplu dans les Shadoks : « Pourquoi faire simple, quand on peut faire compliqué ?»

C’est tout pour aujourd’hui !

* Patrick Bonneau fait partie en tant que développeur indépendant du projet JCAPS-RFID