Ce billet est écrit dans le but de faire l'éloge des nouvelles architectures dites « orientées services » des nouveaux systèmes d'informations. A la différence des architectures qui
consistait finalement simplement à proposer en « interne » les données de l'entreprise afin que celles ci puissent être traitées et gérées par les employées, les architectures
« orientées services » « ouvrent » dans un certain sens les bases de données des entreprises à leur client afin de leur proposer de participer eux mêmes à la gestion,
l'organisation, la récupération de leurs données et informations.
Bien entendu, les bases de données des entreprises ne font pas l'objet d'une ouverture totale et incontrôlée de leurs systèmes d'informations et données. Les entreprises délimitent très
clairement en « interne » les données qui peuvent être diffusées, avec quelles possibilités d'accès (propriétaire, ami, personne lambda) ce qui permet de garantir d'une la sécurité des
informations pour le client, et deux la fiabilité, respectabilité du système d'informations pour les entreprises.
Prenons un exemple simple pour terminer ces premières explications sur les « architectures orientées services » en nous intéressant à une entreprise (ndr : déjà cité dans un autre
billet de ce blog), Flickr.com . Cette entreprise propose à ses clients (ndr : gratuits ou payants) de stocker en ligne des photos numériques et de les présenter aux mondes, en tenant compte des
restrictions d'accès citées plus haut dans ce billet. Jusque là rien de très extraordinaire me direz vous, un simple site de partage et stockage en ligne de photos. C'est vrai, tout du moins
jusqu'à ce qu'on présente l'aspect « orienté services » de Flickr.com .
Cet aspect « orienté services », qui se matérialise en l'API Flickr, permet à tout utilisateur de Flickr.com de pouvoir accéder à des données de la base de données de Flickr.com, que
ces données soient les siennes, celles de ses amis (ndr : au sens et sur Flickr.com), ou des données d'utilisateurs Flickr.com .
Cette API permet donc de créer une économie de services, indépendants de Flick.com, autour de la base de données de photos, économie qui se matérialise par plusieurs types d'intiatives
indépendantes :
-
dans un premier temps, on peut noter la voie ouverte aux entreprises de développement de logiciels qui à travers l'API peuve constituer de nouveaux programmes de gestion optimisée des
photos Flickr.com, programmes qui sans faire l'objet de paiements directs à priori, peuvent faire l'objet de dons (ndr : Wikipédia) qui sont là pour signifier l'intérêt des logiciels
édités, pour des photographes professionnels de Flickr.com par exemple. En dehors des logiciels purement de gestion, on peut citer aussi les logiciels permettant de créer des diaporamas
de photos duplicables sur le net à partir d'un compte Flickr.com et utilisant l'API Flickr. Les exemples d'applications sont nombreux et nous vous laissons les découvrir avant de passer au
second type d'initiative.
-
dans un second temps, on peut aussi évoquer les intiatives professionnelles qui visent à proposer des impressions des photos présentes sur Flickr.com, qui visent à l'impression de cartes
de visites avec des photos de Flickr.com ou encore d'entreprises proposant la création de t-shirts personnalisés avec des photos de Flickr.com . Ces services « indépendants »
sont bien entendus soumis au respect des conditions d'utilisation de chaque photo qui sont fixées par les utilisateurs (ndr : les photos uploadées sur Flickr.com sont par défaut
accessibles publiquement c'est à dire par tous).
Pour ceux à qui « API » évoque en fait la phonétique « happy » ou « joyeux » en français (ndr : je sais qu'il y en a ;-) ) on pourrait finalement commencer, en leur
disant que, oui, dans la plupart des cas, les API ont pour effet de rendre joyeux, les porteurs de projets, développeurs qui « s'attaqueront » à elles afin de proposer de nouvelles
fonctionnalités, de nouveaux services, de nouveaux produits/machines etc...
Cependant « API » n'a rien à voir avec le terme « happy » et signifie « Application Programming Interface » soit en français, une interface permettant de programmer
des applications à partir d'un modèle de fonctionnalités fixé. Concrètement cela signifie qu'une base de code est déjà présente derrière l'API et que des outils (ndr : les objets et méthodes)
vous permettent d'utiliser la dite base de code à travers des fonctionnalités, procédures définies pour vous permettre de réaliser rapidement, d'une façon propre et formalisée des actions permis
par la toujours dite base de code.
Pour prendre un exemple simple, toujours en relation avec Flickr.com, on peut constater que l'API Flickr.com a subdivisé toutes les fonctionnalités, tous les schémas de données présents dans sa
base de données globale. Parmi ces subdivisions on peut par exemple remarquer le schéma « photos » qui permet d'accéder à l'ensemble des données sur les photos (ndr : en tenant compte
des restrictions d'accès) et que ce schéma « photos » comprend un outil « search » qui correspond à l'outil proposé dans l'API Flickr.com pour vous permettre d'effectuer de
façon programmatique une recherche de photos depuis la base de données Flickr.com .
Comme on a pu le voir, une architecture « orientée services » convient souvent très bien aux projets ayant pied sur internet, comme Flickr.com, mais il est de rigueur de se poser la
question d'un déploiement au sein de sociétés « concrètes » ayant pied dans le monde « réel ».
L'auteur pense avoir trouvé à travers l'exemple ci après décrit un exemple permettant de démontrer l'intérêt de disposer d'API au sein de structures comme la SNCF qui doit faire face à la gestion
de nombreuses machines dites « embarquées », en l'occurence dans l'exemple les panneaux d'affichage précisant les horaires et trajets/destinations prochaines des trains qui passent à
quai.
En effet il est impressionnant de voir au sein des gares le dispositif d'affichage global des informations (ndr : quand celui ci n'est pas en panne, certes...) et d'imaginer derrière la gestion
qui doit en être faite par les employés de la SNCF.
Posons le problème en terme clairs, compréhensibles par tous :
-
on constate dans les gares une différence au niveau des machines d'affichage utilisées. On peut constater d'abord des panneaux d'affichage rotatif, plutôt old school qui doivent demandée
pas mal de manipulation manuelle, mais qui sont au moins reliés à une base de données pour permettre de charger correctement les bandeaux à afficher. On peut apercevoir aussi, dans les
gares souterraines du RER notamment, des panneaux d'affichage avec « cases lumineuses », cases à côté desquelles sont posés des adhésifs représentant le nom des gares
concernées. On peut aussi noter l'existence d'écrans sur fond bleu qui affichent les prochains trains à venir ainsi que leur direction.
Toutes ces machines, aussi différentes soient-elles doivent être synchronisées (ndr : au moins en partie) avec les impératifs de la diffusion d'informations, en clair que soient affichées sur les
quais des gares des informations actualisées (ndr : quel serait l'intérêt de voir l'heure et la direction d'un train déjà passé ?).
Les dites machines doivent donc se référer d'une façon ou d'une autre à un système central d'informations, système accessible via (probablement) via une API générique permettant à chaque type de
machine de pouvoir lire et récupérer les informations qui lui sont nécessaires dans le(s) format(s) qu'elles comprennent.
L'API permet donc, dans le cas des gares SNCF, d'apporter une interface générique d'interrogation de la base de données (ndr : l'auteur ne peut préciser s'il s'agit d'une base de données par gare
ou si un lien vers une base de données plus étendue (re-ndr : par ligne, par réseau, etc) est établi pour la lecture des données et des horaires) qui diffuse donc les informations aux différents
types de machines en prenant en compte le type d'interrogation et le(s) format(s) à renvoyer.
L'auteur de ce billet ne peux affirmer avec assurance que le système prédécrit est bien implémenté dans les gares SNCF, mais dans tous les cas précise, que ce système est clairement celui qui
permet une gestion optimale des flux de données informatifs devant être diffusés par la centralisation de ces données qui garantit que toutes les machines d'affichage se réfèrent aux mêmes
données.
De façon supplémentaire, l'utilisation d'une API pour la diffusion de ce type de données permettrait aux constructeurs de machines de ce type de pouvoir travailler sur des bases solides de
fonctionnement et de possibilités afin d'être en mesure, d'une de proposer des nouvelles machines gérant peut-être mieux ou autrement la diffusion des informations, de deux d'être force de
proposition pour l'évolution des API déployées dans les gares afin de permettre à celles-ci de s'adapter à de nouvelles machines, nouveaux formats de flux.
L'auteur a tenté de formaliser au sein d'un document pdf téléchargeable depuis un lien présent en bas de ce billet, une représentation présentant l'intérêt de la mise en place d'une API afin de
pouvoir diffuser de façon sécurisée et adaptée des informations vers, dans l'exemple des machines, concrètement vers des « gadgets » dédiés à l'affichage spécialisé d'informations.
Si vous souhaitez en savoir plus sur la mise en place des API, des « architectures orientées services », vous pouvez contacter l'auteur de ce billet via son site officiel accessible via
le lien ci-après http://www.nicoweb.fr/
Lien vers Flickr.com : http://www.flickr.com
Lien vers le site SNCF : http://www.sncf.com/
Définition « API » par Wikipédia : http://fr.wikipedia.org/wiki/Interface_de_programmation
Lien de téléchargement du document Nicoweb sur les API : http://www.nicoweb.fr/files/getFile.php?idf=3
