Archives pour la catégorie Architecture

Exemple pratique d’application web enrichie par les technos sémantiques

Les technologies nouvelles du Web Sémantique peuvent être couplées aux technologies bien éprouvées des bases de données relationnelles. Par exemple, l’usage des « topic maps » permet d’enrichir une application à base de données relationnelles sans avoir à étendre son schéma de base de données.
Cette approche consiste à stocker certaines des données de l’application non pas dans un schéma ad hoc (avec des champs, des clefs et des jointures conçues spécifiquement pour traiter ces données) mais dans un schéma « générique » en utilisant des concepts plus abstraits introduits par les topic maps (« topics », « associations », « occurences »). Ainsi, on peut y stocker n’importe quelle donnée, y compris des données qui n’étaient pas prévues au moment de la conception de l’application. Cette approche offre une telle souplesse que l’on pourrait être tenté de stocker TOUTES les données de l’application sous la forme d’un schéma relationnel pour topic maps. Cependant, cela introduit une couche d’abstraction supplémentaire qui implique donc des traitements supplémentaires et donc des perfomances qui ne sont pas comparables à celles que l’on peut obtenir avec un schéma relationnel conçu sur mesure.
C’est pourquoi cette approche présente son intérêt dans le cas où l’on a d’une part des spécifications fonctionnelles stables (et donc un schéma relationnel que l’on peut bâtir de manière durable en offrant un maximum de performances) et d’autre part des spécifications plus floues ou instables (que l’on peut implémenter en privilégiant la flexibilité sur les performances, à l’aide d’un schéma générique pour stocker des métadonnées sémantiques). L’approche sémantique permet ainsi de bâtir des applications web combinant performances (du relationnel) et flexibilité (du sémantique).

Que penser de WSRP ?

WSRP est une spécification proposée par le consortium OASIS. Son objectif est d’améliorer l’interopérabilité des services web produisant du contenu directement consommable par un utilisateur, par opposition aux services web « back-end ». WSRP partage une partie de son contenu avec la spécification WSIA de l’OASIS qui, elle, vise l’interopérabilité des services web interactifs. WSRP est un enjeu commercial pour les éditeurs de portails qui voudraient rendre leurs « portlets » réutilisables d’un produit à l’autre, ce qui est intéressant soit dans le cas de grosses entreprises disposant de plusieurs produits de portail distincts soit dans le cas de sociétés différentes souhaitant « échanger » des portlets.
Ce qu’il faut, selon moi, penser de WSRP : il ne faut pas en attendre grand chose. Cette spécification survient dans un climat d’instabilité des processus de standardisation des services Web et, en particulier, de concurrence entre le W3C (l’organisme de standardisation des technologies du Web) et l’OASIS (consortium d’éditeurs de logiciels).
De plus, les services web sur le modèle RPC SOAP/WSDL/UDDI sont très loin d’avoir fait leurs preuves, au contraire. La seule chance de succès de WSRP réside donc peut-être dans l’importance des investissements qu’auraient effectués certains éditeurs logiciels, qui cherchent maintenant un moyen de les rentabiliser.
Il me semble plus raisonnable et économique de concevoir une interopérabilité des services web, y compris pour les portlets, basée sur les caractéristiques de couplage faible défendues par le modèle architectural REST qui, lui, a fait ses preuves avec le Web depuis plus de dix ans.

REST : restons, restez…

On ne le dit jamais assez : vous utilisez sans doute déjà le modèle REST mais sans le savoir ! Alors, sachez le, il faut continuer à RESTer :

Des produits opensource pour l’EAI

Il existe au moins deux produits
opensource conçus pour l’EAI : Proteus et Babeldoc.
Proteus est constitué de :

  • un framework pour développer des applications à base de messages
  • un broker de messages construit sur ce framework
  • des connecteurs pour diverses sources (ou destinations) de données : bases de données,
    files de messages, serveurs FTP, etc. ainsi que, bientôt, serveurs de messagerie
    électronique, fichiers plats, pour Tibco Rendezvous et pour WebMethods.
  • une API documentée

Babeldoc est une application de traitement de documents (similaire à WebMethods mais en
moins avancé) constitué d’une part d’un « pipeline » paramétrable à travers lequel les
documents circulent et d’un système sophistiqué de journalisation. Babeldoc tourne dans un
environnement J2EE (JBoss par exemple) et dispose d’interfaces d’admin via le Web, via un
client lourd ainsi que via ligne de commande. Babeldoc fournit également des connecteurs
pour bases de données, serveurs FTP, serveurs HTTP et services SOAP, ainsi qu’une fonction
de routage basée sur la technologie XPath. La documentation de Babeldoc est en cours
d’amélioration. Babeldoc est actuellement utilisé pour un EAI reliant les banques serbes à
la banque centrale de Serbie.

Imaginez le Web Sémantique

Allez, un petit effort, projetez-vous en 2009 : Google a surfé la vague du Web Sémantique et a, du coup, appris à comprendre l’information qu’il crawle sur le Web. Il SAIT désormais que Jim se considère comme l’ami de Paul. Il SAIT que le vendeur A propose un modèle de voiture 10% mois cher que le vendeur B. Il SAIT que tel saxophoniste a joué dans tel orchestre dans les années 70. Il SAIT que les chiens ont des pattes, que votre ordinateur a besoin d’une nouvelle carte mère pour pouvoir passer au Pentium 18. Le Web Sémantique, ce n’est plus un fatras de pages et de liens mais un fatras de choses et des relations logiques qui les articule. Toutes ces informations sémantiques (certains disent « ces métadonnées ») sont publiées sur le SemWeb comme le sont les pages du Web d’aujourd’hui. Chacun peut y puiser mais aussi y publier. Et les logiciels du SemWeb permettent de faire émerger le sens de tous ces liens logiques entre les ressources du SemWeb, de confronter des liens contradictoires, de batir des raisonnements à la demande de l’utilisateur, etc. Par exemple, le Google de 2009 vous permet d’explorer ces liens pour trouver de nouvelles ressources et de nouvelles informations selon vos besoins, ou selon le besoin de vos propres logiciels…
(Je vous laisse deviner dans quelle phase du « hype cycle » du Gartner Group le concept du Web Sémantique serait actuellement positionné.)

Opensourcez vos développements

Les logiciels opensource sont de plus en plus utilisés dans les grandes entreprises. 54% des DSI prévoieraient qu’en 2007, leurs principales plate-formes seront opensource.
Comme l’indique cet article du magazine Computerworld, certaines grandes entreprises adoptent même le modèle économique des développements opensource pour réduire les coûts de leur informatique. Après l' »outsourcing », l’ « opensourcing » consiste donc à publier sous licence opensource les développements menés en interne pour améliorer ou corriger un logiciel libre. Cela évite d’avoir à maintenir, en interne, une version spécifique du logiciel et permet donc de partager les coûts de développement avec d’autres entités. Cela permet également à l’entreprise de gagner en légitimité dans les communauté de développement et de pouvoir ainsi influencer de manière significative leurs stratégies de développement. La contribution des entreprises ne consiste pas seulement en code informatique mais également en documentation ou en graphisme, ressources qui font défaut pour de nombreux logiciels libres.

Propriété intellectuelle ?

The New Economist du 25 janvier publie un article sur les problématiques de propriété intellectuelle dans le cadre de l’Internet. Cet article rappelle que la vocation du droit d’auteur a été d’établir un équilibre entre la garantie d’un accès public aux flux des idées et l’incitation à la création et la distribution de travaux intellectuels par la concession de monopoles économiques temporaires et limités sur l’exploitation de ces travaux. A l’heure de l’Internet, cet équilibre semble être rompu : les industriels du contenu prétendent être spoliés de leur propriété (intellectuelle) et les défenseurs des consommateurs et des libertés individuelles dénoncent l’asphyxie de créativité entraînée par le comportement des dits-industriels.
Pour rétablir le juste équilibre, The New Economist cite plusieurs suggestions de modifications substantielles du droit d’auteur :

  • abandonner toute velléité de contrôle des copies de contenu et accorder, par la loi, aux créateurs de contenu, un droit exclusif pour l’exploitation commerciale de leurs travaux ; mais cette option pourrait entraîner de nombreux litiges portant sur la définition du caractère commercial d’une exploitation de travaux intellectuels et sur le caractère exclusif de ce droit
  • garantir la gratuité de l’accès à tout contenu mais taxer l’accès à l’Internet et aux équipements électroniques, reverser cette taxe aux distributeurs de contenus et ajuster le montant de cette taxe à une évaluation globale de la consommation de ces contenus ; mais cette option impliquerait des mesures gouvernementales très importantes, l’impossibilité d’une différenciation des distributeurs par les prix et, surtout, une taxation importante des équipements qui rendent possibles la révolution numérique
  • l’obligation pour les auteurs de déposer leur demande de droit d’auteur sur un nouveau contenu, de renouveler cette demande tous les cinq ans avec une limite du nombre de renouvellements et l’obligation d’exploiter ce droit par une distribution commerciale (faute de quoi il tombe dans le domaine public) ; cette option semble la plus réaliste, même si elle implique également une forte intervention des Etats, et est émise par un professeur de droit de l’université de Stanford, Mr Lessig.

Combien coûte l’opensource ?

OK, la licence des logiciels opensource est gratuite. Mais quid des coûts associés (support, services, formation, …) ? Les éditeurs de logiciels commerciaux offrent des coûts de support explicites. Il est plus difficile d’obtenir un service de support auprès des développeurs d’un logiciel opensource. Employer quelqu’un pour qu’il passe son temps à suivre des forums et listes de discussion n’est pas non plus une solution économique. Sur le long terme, les logiciels opensource seraient-ils plus coûteux que les logiciels commerciaux ? Une analyse au cas par cas s’impose. Cette analyse devrait prendre en compte les faits suivants.
Si l’on emploie un expert interne pour participer à la communauté des développeurs et utilisateurs du logiciel opensource choisi, on gagne bien plus qu’un simple niveau de support : un expert interne fournit également la possibilité d’enrichir les fonctionnalités du logiciel, à la demande, et agit en tant qu’évangéliste interne pour favoriser un meilleur usage et un plus grand succès du logiciel sélectionné.
Un bon moyen pour évaluer la pérennité d’un logiciel opensource consiste à s’appuyer sur le travail d’analyse et de sélection des éditeurs de livres informatiques : plus un logiciel opensource à fait l’objet d’ouvrages (chez O’Reilly par exemple), plus il peut être considéré comme pérenne car ayant atteint une masse critique d’utilisateurs tel que l’avenir de son code source est assuré pour de nombreuses années.
De plus, l’adoption d’un logiciel sous licence opensource garantit une indépendance vis-à-vis de ses développeurs et éditeurs de manière à ce que ceux-ci ne puissent imposer de licences limitée dans le temps ni d’obsolescence programmée (« Telle version de notre logiciel ne sera plus supportée à partir de telle date… » ou bien « Telle version de notre logiciel comporte des failles de sécurité trop importantes, vous devriez adopter notre toute dernière version. »).
Il assez probable qu’une société comme Microsoft survive encore de nombreuses années et puisse offrir, à ses conditions, la maintenance du logiciel. Et il n’est pourtant pas si improbable qu’une communauté de développeurs d’un logiciel opensource abandonne un jour ce développement pour une raison ou une autre. N’est-il pas alors préférable de se fier à un éditeur commercial ? Sans doute que non car, même en cas d’abandon du logiciel par ses développeurs initiaux, non seulement la poursuite du développement peut être assurée par des développeurs indépendants ou d’autres sociétés mais le caractère public du code source permet également de s’approprier le maintien et le développement interne du produit. Dans le cas où un éditeur de produit fermé fait faillite, les coûts de possession du logiciel grimpent en flèche car il devient presque impossible d’obtenir support et maintenance à conditions économiquement raisonnables.
Dans le cas d’un logiciel répondant à un besoin précisément et durablement défini (surtout si ce besoin est celui d’un informaticien), il est très probable qu’un produit opensource soit préférable à un produit commercial qui, de par le modèle économique de son éditeur, gagnera probablement en fonctionnalités superflues. On considère souvent qu’un produit opensource est plus stable et contient moins de bugs et de failles de sécurité sur le long terme. On peut également apprécier le caractère prévisible des coûts de maintenance d’un logiciel opensource à long terme. Nul ne sait combien l’éditeur d’un produit fermé facturera la maintenance dans 5 ans.
Pour conclure, on peut dire que la comparaison du coût total de possession d’un produit fermé (propriétaire) et d’un produit ouvert (opensource) doit faire l’objet d’une analyse approfondie, au cas par cas. Et l’un des critères déterminants du TCO d’un produit ouvert et le degré d’activité et de vitalité de sa communauté de développeurs.

Qu’est-ce qu’un weblog ?

Selon Meg Hourihan, le point commun essentiel entre tous les weblogs, c’est le format de présentation : anté-chronologique et daté, il laisse le lecteur apprécier la fraîcheur du contenu et la fréquence des mises à jour. De plus, le lecteur peut réagir par email (avec un lien vers la boîte aux lettres du carnetier) ou, souvent, par un lien « commentaire » par lequel chaque item s’accompagne un forum. Contrairement à un « site perso » classique, le weblog amalgame en une seule page de multiples éléments aux sujets variés. Chaque message publié sur un weblog s’accompagne d’une date de publication et d’un « permalink » c’est-à-dire d’une adresse URL qui ne variera jamais et permet de lier ce message depuis des sites extérieurs sans crainte que le lien ne casse. Le permalink permet à d’autres auteurs de weblogs de signaler le message que vous avez publié et de le commenter directement depuis leur site. Ainsi, d’un weblog à l’autre, les carnetiers font référence à leurs messages respectifs de manière précise et entretiennent une conversation en réseau, sans lieu unique de rencontre. Parfois, des communautés étroites de webloggers se forment et organisent des rencontres « in real life » sous la forme de dîners ou autre, pour pouvoir faire plus ample connaissance et échanger face à face.

Pourquoi passer de l’ASP à PHP ?

Pour une entreprise qui a adopté ASP, pourquoi faudrait-il passer à PHP ? Pour profiter de la grande quantité de code opensource disponible, parce que le modèle de développement PHP est proche du modèle ASP, parce que PHP est désormais disponible sur Windows, parce que PHP est suffisament performant pour l’entreprise comparativement à ASP. Le point de vue de l’auteur de cet article sur les autres langages opensources pour le Web : la laideur de perl ne convient pas pour les gros projets ; le modèle de développement de python et zope est bien mais trop éloigné de celui d’ASP ; JSP n’est pas un bon choix car les langages de scripting sont plus adaptés au Web que ne l’est Java.

Ca émerge ou pas ?

De la présentation d’un symposium sur « le Web Sémantique qui émerge » (trouvez-moi une meilleure traduction SVP), je retiens les points suivants :

  • le WS permet aux machines d’automatiser, d’intégrer et de réutiliser des données entre applications
  • le WS requiert un langage de formalisation des connaissances
  • ces connaissances permettent, en s’appuyant sur des ontologies, de décrire le contenu de sources d’information et les conditions de fonctionnement de services Web
  • le modèle UML, les langages de description d’ontologies pour le web, le modèle et la syntaxe RDF, le dialecte XDD (tiens, je ne le connaissais pas, celui-là) sont des outils proposés pour le réalisateur d’applications web sémantiques
  • les services web trouvent dans le WS des dialectes XML de description, des solutions de découverte de nouveaux services appuyés sur des ontologies.
  • les ontologies permettent l’indexation sémantique de site web et peuvent s’appuyer sur des des framework d’annotation sémantique et des offres de solutions aux performances adéquates pour une utilisation à grande échelle
  • plusieurs ateliers logiciels sont proposés par les chercheurs pour l’intégration d’ontologies ; ces frameworks offrent une forte évolutivité (« scalabilité »), la résolution des contradictions entre ontologies et le support de formalisation hétérogènes d’ontologies

Autrement dit, la promesse du WS pour l’entreprise (notamment), selon ce symposium, c’est de permettre l’intégration des données de l’entreprise grâce à une formalisation des connaissances appuyée sur 1/ des spécifications techniques (langages, modèles) dédiée à l’expression de connaissances, 2/ des outils logiciels d’intégration de référentiels (ontologies).

Passé et avenir des services Web

Uche Ogbuji retrace l’historique des services web. En voici un résumé très schématique. IBM MQSeries était l’un des précurseurs de la tendance. En leur temps, vinrent CORBA et leurs pendants Microsoftesques COM et DCOM. Le protocole RMI pour Java naquit et les succès de niche de MQSeries donnèrent le jour à des technologies équivalentes chez Sun et Microsoft. Les services distribués prirent ensuite la forme de services Web (HTTP + XML) tout d’abord avec l’offre visionnaire e-Speak de HP (un peu trop en avance sur son temps ?) puis avec l’émergence du rustique mais simple et robuste XML-RPC au sein de la communauté opensource. Du côté des grosses entreprises, leurs besoins de transactions inter-organisations les menèrent de l’EDI façon Internet à l’ebXML (sponsorisé par Sun). C’est fin 1999 que SOAP (sponsorisé par Microsoft) fit son apparition. Une partie de la communauté opensource constituée autour de XML-RPC adopta peu à peu SOAP car cette spécification technique, pour une fois, semblait très ouverte. Plusieurs standards furent proposer pour décrire les services Web et c’est WSDL qui, sous le sponsorship d’IBM et de Microsoft s’affirma comme candidat le plus sérieux puis UDDI fut proposé en complément, pour constituer des annuaires de services Web. Aujourd’hui, c’est le trio SOAP + WSDL + UDDI qui est présenté comme la spécification moderne des services Web. SOAP connaît un certain succès « de terrain » auprès des développeurs notamment, malgré les problèmes d’interopérabilité qui subsistent lors des implémentations, tandis qu’à l’autre extrémité, UDDI, qui est sensé être un support pour des politiques « corporate » de gestion des services Web, à encore plus de mal à trouver ses marques.
D’après Uche Ogbuji, deux visions s’affrontent aujourd’hui parmi les promoteurs des technologies pour services Web : les uns pensent que les équipes amenées à implémenter des services Web devraient se composer d’experts en technologies XML (approche adéquate pour traiter des problématiques de communication inter-entreprises) ou de développeurs s’appuyant uniquements sur des boîtes à outils hermétiques (approche fréquente pour des périmètres spécifiquement internes aux entreprises). Microsoft (avec .Net) et IBM offrent de telles boîtes à outils. BEA, Iona et Apache offrent des fonctionnalités similaires. Etant donné le manque de maturité des technologies des services Web, les éditeurs de boîtes à outils risquent d’être l’objet d’importantes contraintes d’évolution lorsque des normes consensuelles émergeront et que leurs boîtes à outil devront tenter de s’y conformer. OASIS souhaite définir un modèle universel de composants pour services Web (WSCM) qui couvriraient des besoins tels que ceux aussi bien ciblés par CORBA ou COM que ceux ciblés par les composants visuels à la JavaBeans ou à la Delphi. De plus, l’avenir des services web pourrait être fortement influencé par l’évolution des bases d’objets et des technologies telles que le Web Sémantique. Pour l’instant, seul SOAP a fait l’objet d’implémentations fréquentes. Des spécifications technologiques complémentaires telles que UDDI, bien qu’émises depuis longtemps, n’ont toujours par pris forme en pratique et on peut s’interroger sur leur avenir.
Personnellement, je doute même de la pérennité, et surtout du bien-fondé, de SOAP qui, malgré sa séduisante et trompeuse simplicité d’implémentation auprès des développeurs, repose sur des principes architecturaux très éloignés du principe de « couplage faible » (loose coupling) qui a fait le succès des technologies Web. Le modèle REST semble bien plus satisfaisant à cet égard (chercher « REST » dans ce blog pour plus d’infos à ce sujet) bien que nécessitant un mode de conception d’applications + services Web inhabituel pour les développeurs, plus familiers du « j’ai une fonction/méthode, je lui passe des paramètres et j’obtiens un résultat en sortie » à la RPC.

L’amateurisation de la publication

Sur son weblog, Clay Shirky discourt au sujet… des weblogs et
de l’amateurisation de masse de la publication. Naguère, au temps jadis d’avant, le processus de publication créait une
valeur non seulement parce que ce processus était coûteux (d’où une barrière à l’entrée et des opportunités d’échelle sur un
marché sans cesse plus concentré) mais aussi, du même coup, parce que l’éditeur devait sélectionner le contenu pour ne
publier que celui qui représenterait le plus de valeur sur le marché. Le développement de l’Internet et, aujourd’hui, des
weblogs, change la donne : le coût de publication est considérablement amoindri, les barrières à l’entrée se sont effacées,
et les auteurs n’ont plus à passer au travers du scepticisme professionnel de l’éditeur pour atteindre son public. Quels
modèles économiques peuvent se révéler intéressants dans ce contexte ? Créer une pénurie artificielle, en ne donnant accès au
contenu qu’aux seuls abonnés ayant payé est une solution envisageable. Mais l’abaissement des barrières à l’entrée rend très
probable l’apparition de « nouveaux entrants » sur le marché susceptibles de publier à coût plus bas voire nul. Restent les
revenus indirects : publicité, sponsorship et marketing direct. Le webloggeur (ou carnetier) peut également envisager de
demander des donations à ses lecteurs, éventuellement via une coopérative de webloggeurs. Enfin, il reste… la publication
sur papier. En effet, les rares personnes à gagner aujourd’hui de l’argent dans le monde des weblogs sont ceux qui ont publié
des livres décrivant le phénomène ! Mais la plus grande récompense pour le weblogueur n’est-elle pas simplement de participer
à la conversation ?