Clever Age – Le point sur l’interopérabilité J2EE, .NET et PHP

Clever Age a publié dans sa newsletter une excellente et didactique synthèse sur l’interopérabilité J2EE, .NET et PHP. J’en retiens les leçons suivantes :

  • Pour l’intéropérabilité, le couplage lâche c’est LE principe qu’il faut adopter
  • Les services web basés sur la pile de technologies liées à SOAP, c’est pas mal pour faire du couplage lâche
  • Mais les services web basés sur la technologie XML-RPC ou les services Web de style REST (quelle que soit la techno utilisée), c’est encore mieux car
    1. plus simple
    2. une pratique plus répandue
    3. ça apporte moins de contraintes techniques inutiles (infrastructure, compétences, …)

J’ajouterais que les services Web de style REST offrent un couplage non seulement encore plus lâche (modularité du S.I.) mais également encore plus tardif : inutile, au moment de la conception de vos services Web, de faire des hypothèses sur l’usage qui en sera fait dans le futur, le style REST vous garantit leur intégrabilité future.

La différence essentielle entre le style REST et le style RPC (XML-RPC ou pile SOAP), c’est que le style REST permet l’intégration spontanée (non planifiée centralement) de services alors que la pile SOAP suppose une planification plus centralisée des projets d’intégrations de services à travers la négociation et la spécification de contrats entre fournisseurs et consommateurs de services (et qui dit contrat dit “une certe forme de codification” et donc une certaine perte de flexibilité pour le futur).

Ma conclusion : l’approche REST est plus adaptée aux organisations qui sont elles-mêmes faiblement couplées. Autrement dit : pour faire du SOA sur SOAP, il faut réunir toutes les parties prenantes et établir des contrats de services spécifiques et peu évolutifs ; conséquence : faites du SOAP dans une organisation non centralisée et vous vous retrouverez dans une situation similaire à celle dont se lamentait Reinout Van Rees, une situation qui conduit à l’échec ou au moins au gaspillage d’efforts. Posez-vous plutôt la question :

  • Vous vivez dans une cathédrale ? Alors vous pouvez vous contenter du couplage relativement faible offert par SOAP mais vous vous encombrez toute de même de contraintes inutiles
  • Vous vivez dans un bazar (“bordel organisé” disait Fred ?) ? Alors il vous faut du couplage extrêmement lâche et tardif. Et l’interopérabilité des composants du bazar passe alors par la simplicité et le caractère “future-proof” de REST.

Au bout d’un moment, j’ai l’impression de me répéter à force de ressasser les mêmes choses sur REST. Mais j’espère que d’un billet à l’autre, mes idées sur le sujet gagnent en clarté (au moins dans ma tête). Et les vôtres ?

Réseaux d’entrepreneurs

Ces jours-ci, l’actualité des carnets Web offre de manière involontaire une confrontation amusante : d’une part le point de vue de Dave Pollard sur l’importance des réseaux d’entrepreneurs pour “éviter les champs de mine” que doit traverser toute petite entreprise pour survivre et prospérer et d’autre part la mise à jour 2004 d’un outil de cartographie des relations entre les conseils d’administration des plus grosses sociétés américaines (NB : societe.com offre un service similaire pour parcourir les relations entre dirigeants de sociétés françaises, mais avec une interface moins sympathique à mon goût).

Ma conclusion suite à cette confrontation : à toutes les échelles, les réseaux de dirigeants ont une importance indéniable du point de vue économique. Mais y a-t-il des différences fondamentales entre des réseaux d’entrepreneurs (de PME) et des réseaux d’administrateurs (de multinationales) ? Pourquoi les réseaux d’entrepreneurs paraissent-ils de manière naïve plus “sympathiques” que les réseaux d’administrateurs de grandes entreprises qui inspireraient plutôt la méfiance de l’opinion publique ? Cette différence de perception n’est-elle pas simplement idiote ? Ou bien les réseaux d’entrepreneurs seraient plus ouverts (accessibles et à jeu gagnant-gagnant comme on dit) alors que les réseaux d’administrateurs seraient plus fermés (secrets pour protéger la mise d’un jeu à somme nulle) ?

Management et stratégie des OSBL

Pour faire suite à mon billet de mars sur le management associatif et pour fournir plus d’information sur ce sujet, comme cela me l’a été demandé, voici, ci-après, quelques notes que je retiens de la lecture d’un document de Jean-François Pépin au sujet du management et de la stratégie des organisations sans but lucratif.

Les OSBL devraient être managées comme des entreprises ? Pourtant, elles en diffèrent en trois points, facteurs de complexité (au sens noble du terme) :

  1. l’évaluation de leur performance n’est pas seulement comptable ou financière mais surtout sociale (cf. le concept de développement durable…)
  2. leurs ressources humaines sont salariées mais aussi bénévoles
  3. leur action a une finalité politique ou sociale (“créer du lien”, …)

Leur fonctionnement s’appuie sur une “économie sociale de marché” : fonctionnement démocratique, volontariat, ni rémunération du capital ni distribution de bénéfices, faculté de délibération, … La logique d’économie de marché augmente la valeur (qualité / coût) des processus métiers (prestations de services…) des OSBL.

La mise au point d’une stratégie pour une OSBL suppose de répondre à des questions essentielles telles que “de quel type de rentabilité sommes-nous redevable et envers qui ?”, “comment prendre en compte tous les points de vue dans nos décisions ?”, … Une telle stratégie suppose de distinguer l’important (l’organisation, la survie économique) de l’essentiel (le projet associatif).

La clef du succès réside dans l’équilibre dynamique entre administrateurs bénévoles et permanents salariés et dans la vision partagée qui doit en résulter.

A noter que, pour le plaisir du lecteur averti, J.-F. Pépin renforce même son exposé d’une citation de Pierre Lévy pour rappeler que la clef de la performance dans un environnement aussi complexe réside dans les processus organisationnels que le philosophe qualifie d’intelligence collective.

Pourquoi Jonas plutôt que JBoss

Voici une liste d’arguments de comparaison entre deux serveurs d’applications J2EE open source : JBoss et Jonas. Je trouve cette liste intéressante car elle pointe les problématiques qui me semblent les plus importantes pour un projet d’entreprise autour d’un produit open source : disponibilité du support, de la documentation, etc. Selon moi, pour le lecteur, cette argumentation devrait être plus importante que le choix lui-même.

Merci, Thomas, de m’avoir indiqué ce lien !

Decentralized organizations centralizing their IT architecture = 0,1% chance of success


Reinout van Rees says

I’ve had enough of all those pictures in powerpoint presentations showing the One Central Database Or Application that would solve all communication problems in a building project.

Is this a coincidence if I feel the same and I work in a similar industry ? It is a hard job to convince this industry of the benefits of spontaneous integration and the adequacy of the open source model to support it ! Come on Reinout, let’s build the Spontaneously Integrated Front of Really Loosely Coupled Architects for the Building Industry ! ;-) Need to find a better name : SIFRLCABI does not sound well enough, even in French or in Dutch.

Ingeniweb réinvente RSS

Le Zope Service Provider Ingeniweb publie RSSSearch, un nouveau composant pour Plone qui tranforsme la fonctionnalité de recherche de Plone en méta-moteur de recherche : les résultats affichés proviennent non seulement du site interrogé mais également de plusieurs sites distants. OK.

Ce qui est amusant, c’est qu’au passage Ingeniweb invente encore une nouvelle signification pour l’acronyme RSS. En effet, à l’origine, RSS signifiait Rich Site Summary puis certains l’ont renommé Really Simple Syndication et d’autres RDF Site Summary. Et voila qu’Ingeniweb ajoute sa sauce : Research Support System ! Décidément, chacun invente son RSS. Mmm… Est-ce une blague ?

Présentation du Web Sémantique

Voici une esquisse de plan de présentation des technologies du Web Sémantique pour un public (francophone) d’informaticiens de grandes entreprises :

Active Directory : mono- ou multi-forêt(s) ?

Cet article évoque

research that shows that early adopters of Active Directory tended to choose fewer forests than was ideal, and their networks suffered for it.

Alors, que faut-il penser des grandes entreprises qui choisissent un modèle centralisateur mono-forêt qui centralise, du même coup, le pouvoir de gestion de l’informatique (est-ce une finalité du projet ?). Mmm… Et vous, mono- ou multi-forêt ?

Pourquoi la ville est chaude ? Parce qu’elle est sombre !

On sait qu’au voisinage des grandes agglomérations, la température moyenne est toujours un peu plus élevée que la moyenne régionale. On impute habituellement ce phénomène à l’excès de gaz carbonique produit en ville, qui crééerait un micro-climat du à un micro effet de serre. Mais ne serait-ce pas plutôt, simplement, parce que les toits de nos maisons ainsi que le goudron de nos routes et trottoirs sont trop sombres et ne reflètent ainsi pas assez la chaleur ?

Experimental programs to build some treemaps from graphs

Here is the zipfile containing the treemap programs I mentioned earlier.
And these are zipped set of screenshots produced by these programs : “typic” screenshots, smoothed “typic” screenshots, the “try” graph screenshots, the smoothed “try” graph screenshots. Each set of screenshots corresponds to a specific graph. The “typic” graph is made with 8 nodes grouped in two tightly linked subsets (A-B-C-D and E-F-G-H). The “smoothed typic” graph is the typic graph once the weights of the arcs have been smoothed by a specific smoothing algorithm (ask if you want to know more). The “try” graph is another simple graph with nodes representing some concepts related to me (“family”, “video”, …) and linked one with another according to their analogy. And the “smoothed try” graph is… guess what.

Treemaps

Here
is some bloggy information about treemaps. Treemaps are cool when you want to visualize a weighted tree such as the tree of folders and files on your hard drive weighted according to their size. An excellent free utility to visualize your disk space occupation is Sequoia View.

Beyond Sequoia View, why such an interest from me for treemaps ? Well… Because I just realized I sort of reinvented and explored this concept several years ago without knowing the proper term. Treemaps… My experiments dealt with the use of treemaps for the visualization of graphs of information (networks composed with nodes and arcs).

For instance, let’s take the following graph composed with 8 nodes labelled from A to H. a typic graph with 8 nodes

When you “sit” on node A and try to look through the arcs to the rest of the graph, what can you see ? Answer : the treemap below. (each node is associated to a specific color)
the classic treemap of the typic graph

What if you consider that the whole space (rectangle) of a given node should be separated in subrectangles for the associated nodes ? Then your treemap becomes somewhat fractal and you get this kind of visualization for the same 8 nodes graph seen from node A :
the treemap of the typic graph

Or maybe you prefer the circle version of this treemap which may look more readable. Here it is with a limited depth (exploring no more than 3 arcs from the starting node) :
circle version of the treemap for the typic graph
But it looks even nicer if you explore a high number of arcs :
hi-depth version of the circle treemap

I will soon post the programs that produce these treemaps and some more screenshots.

Des carnets Web au web sémantique

Sebastien Paquet évoque l’évolution future des carnets Web et l’émergence du “structured blogging”. L’idée est la suivante : plus l’activité des carnettiers va gagner en maturité, plus le format habituel des carnets et de RSS (titre + URL + texte) paraîtra limité et insuffisant, plus les outils de la chaîne de carnettage (weblog + aggrégateurs) vont prendre en compte des types de contenu structurés plus complexes. Et il n’y a qu’un pas (voire aucun) entre le “structured blogging” et le web sémantique. Dans ce contexte, les moteurs de gestion de schéma de contenu tels que Archetypes de Plone (ou CPSSchema de CPS ou encore des moteurs de gestion d’ontologie tels que Mondeca et autres AM2 Systems) auront un rôle clef à jouer puisque des plate-formes équipées de tels moteurs pourront servir au carnettage structuré sous toutes ses formes !

Miam, miam, les années qui viennent nous promettent des inventions fichtrement intéressantes ! Et la vision du Web Sémantique commence à prendre forme.

Instantanée de la presse grâce à Google

Via Constellation W3 : cette superbe interface cartographique permet de visualiser en un seul coup d’oeil les grands thèmes de l’actualité selon Google et notamment leur importance relative (d’après leur citation dans un nombre plus ou moins grand de sources de presse). L’utilisateur peut sélectionner les pays surveillés ainsi que les thèmes et le moment de la surveillance (maintenant en temps réel ou bien hier matin ou bien jeudi dernier vers midi, etc.). L’utilisateur peut ensuite garder un permalien vers sa sélection pour y revenir à l’avenir. Exemple : le lien ci-dessus pointe vers les actualités présentes pour la France dans les thèmes “Monde”, “Nation”, “Entreprises” et “Technologie”.

Carnets Web d’entreprise : l’exemple R.H.

Ce carnet Web tenu à jour par deux responsables R.H. en recrutement, de chez Microsoft, est un très bon exemple de carnet Web d’entreprise. Ce qu’apportent ces carnets à Microsoft : un lien d’animation avec la communautés des candidats à l’embauche chez Microsoft, une manière d’optimiser le processus de recrutement (les candidats postulent en étant tous mieux préparés), une meilleure lisibilité de la politique d’embauche de Microsoft, l’image d’une entreprise à visage humain. Il y a sans doute d’autres avantages fournis par les carnets Web pour soutenir la fonction R.H. de recrutement des grandes entreprises. Je vous laisse imaginer (et laisser vos idées éventuelles ici pour que tout le monde en profite !).

La différence entre “knowledge management” et “content management”

CMSWatch signale un excellent article qui parvient en quelques lignes non seulement à définir la différence entre gestion des connaissances et gestion de contenu mais également à résumer de manière très juste les pratiques actuelles dans ces deux domaines.

Mon intérêt personnel réside certes dans le domaine de la gestion des connaissances au sens large présenté dans cet article, mais le vrai potentiel de ce domaine me semble résider dans les pratiques (méthodes) et outils (émergents) d’ingénierie des connaissances. D’où mon intérêt pour le Web Sémantique…

Wiio’s laws : “Communication usually fails, except by accident.”

Les lois de Wiio ressemblent à une application des lois de Murpy au domaine de la communication. La morale qui en est proposée est qu’il est impossible de communiquer de manière efficace : la seule chose à faire, c’est d’essayer tant bien que mal d’augmenter la probabilité d’une réussite accidentelle de cette communication.

Retours d’expérience sur les CMS

Un groupe d’une soixantaine d’ “architectes en information” a partagé, début 2003, ses retours d’expérience sur l’implémentation de systèmes de gestion de contenu. Leurs principales conclusions, à l’époque : les CMS sont trop chers, trop long à personnaliser, et ne sont trop fermés (difficulté pour reprendre du contenu existant par exemple).