Archives pour la catégorie Web services

Web scraping, web mashing

5 Ways to Mix, Rip, and Mash Your Data introduces promising web and desktop applications that extract structured data feeds from web sites and mix them together into something possibly useful to you. Think of things like getting filtered Monster job ads as a convenient RSS feed, along with job ads from your other favorite job sites. This reminds me my Python hacks for automating web crawling and web scraping. Sometimes, I wish I could find time for working a bit further on that…

Web 2.0 architectures with Java

Here are two things to go beyond Web Services (with ReSTfullness in mind):

Take-away: beyond theory (ReST), there now are concepts (WOA) and tools (restlets) for building composite Web applications without requiring SOAP, WSDL and the whole bunch of overbloated WS-* standards that come with them.

Invention d’un système de coaching automatique sur téléphone mobile

[Ceci est le résumé de l’une de mes réalisations professionnelles. Je m’en sers pour faire ma pub dans l’espoir de séduire de futurs partenaires. Plus d’infos à ce sujet dans le récit de mon parcours professionnel.]

En 2005, le projet de recherche informatique MobiLife, mené conjointement par 22 entreprises et universités européennes, dispose d’un logiciel pour téléphone mobile qui permet à un sportif de visualiser son contexte d’entraînement : rythme cardiaque, lieu, heure… En tant qu’ingénieur de recherche, je suis chargé d’inventer un système exploitant ce type de données pour offrir à l’utilisateur des recommandations personnalisées et dépendant du contexte. Je propose aux partenaires un scénario utilisateur qui est accepté puis j’en supervise l’implémentation. J’implémente une partie du système côté serveur (J2EE) et côté téléphone (J2ME). L’application devient ainsi capable d’apprendre les habitudes d’entraînement du sportif, bonnes ou mauvaises, de prédire ses prochains choix d’exercice, de les comparer à ce que recommenderait un entraîneur expert dans les mêmes conditions et, sur cette base, d’alerter le sportif par des petits clips videos personnalisés sur son téléphone : « Attention, il est tard et après 2 exercices de course sur le tapis roulant, vous avez habituellement tendance à trop forcer sur l’exercice suivant ; vous devriez plutôt passer sur le vélo pour un exercice de difficulté moyenne de 10 minutes« . Le système inventé est transposable dans d’innombrables situations de mobilité : coaching alimentaire, formation continue, gestes pour l’environnement, guides touristiques,… A l’occasion d’une journée portes ouvertes des laboratoires Motorola, j’organise la démonstration de cette application devant 40 journalistes et analystes européens.

How to ReSTfully Ajax

Here are some pointers for learning more about the Ajax programming model and how to properly design your Ajax application :

While I am mentionning the Representational State Transfer (ReST) architecture style, here are some additional and valuable resources on this topic :

Web-SSO : A CAS client for Zope

The Central Authentication Service (aka CAS) is an open source lightweight framework that provides Web Single Sign On to big organizations (universities, agencies, corporations). It seems to be wildly used and seen as as much mature and reliable as the struts framework.

An existing server can benefit CAS WebSSO features if its technology is supported by a CAS client. So, please welcome Zope’s CAS User Folder, that SSOizes Zope within complex SSO infrastructures.

Maturité des technos XML

01 Informatique a publié un état de l’art très synthétique au sujet des technologies XML. Chaque technologie présentée est qualifiée selon son degré de maturité. Et les seules technologies XML à avoir atteint le degré de maturité maximal sont les suivantes :

  • Les techniques de base : DOM, Unicode, XML, XML Namespaces, XLink, SAX, XML Schema/DTD, XLM Encryption, XML Signature, XPath 1.0, XSL et XSLT
  • La publication multicanal : CSS, VoiceXML, SMIL, SVG, XHTML, WML, MathML
  • Les services Web : le style REST, DSML (je ne suis pas sûr que la place de DSML soit vraiment dans la catégorie « services Web » mais enfin bon… pourquoi pas ?) et XML-RPC
  • Les échanges électroniques (B2B) : ICE
  • Le web sémantique : Dublin Core, RSS 1.0, RDF

Autrement dit, si vous envisagez d’appuyer une architecture informatique sur une technologie XML qui n’est pas dans cette liste, sachez que vous faites un choix technologique risqué car non éprouvé ! A vos risques et périls…

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 ?

XML.com: The Beauty of REST [Mar. 17, 2004]

Jon Udell nous raconte par l’exemple comment le style architectural REST permet d’intégrer des catalogues de bibliothèques de manière fluide et peu coûteuse (à l’aide de services Web qui n’impose pas nécessairement l’utilisation de briques logicielles supplémentaires pour gérer les protocoles SOAP, WSDL et UDDI). S’il est encore nécessaire de vous apprendre ce qu’est le style architectural REST, ne retenez qu’une seule adresse, celle du site du très RESTafarian Roger Costello.

Architectures orientées services (SOA) selon l’approche REST

Voici quelques liens intéressants pour celui qui veut comprendre ce que l’approche REST peut apporter aux architectures orientées services (SOA) , que ce soit avec ou sans l’utilisation des protocoles SOAP et/ou WSDL (on peut faire une architecture orientée services de style REST avec SOAP et WSDL, même si j’ai du mal à voir l’intérêt que cela représenterait) :

OWL-S

Le schéma OWL-S permet de décrire des services Web à l’aide d’ontologies. D’après cette lecture, je crois comprendre que l’on peut

  • soit produire des services Web style RPC (via SOAP et WSDL) et compléter leur description, à plus haut niveau, avec OWL-S (ce qui remplace UDDI dans ce cas),
  • soit produire des services Web style REST (sans SOAP ni WSDL) et faire toute leur description via OWL-S

Ceci signifierait qu’OWL-S serait un standard dans tous les cas concurrents de UDDI, et dans certains cas complémentaire de WSDL (pour le cas des services Web RPC via SOAP) et dans d’autres cas (services REST), concurrents de WSDL. Est-ce vraiment cela ?

Qu’est-ce que le couplage faible ?

Qu’est-ce que le « couplage faible » ? Le couplage faible, c’est « comme la pornographie » : tout le monde en parle, mais c’est bien difficile à définir :

Je n’essaierai pas aujourd’hui de définir ce qu’est la pornographie… mais je sais que c’en est lorsque j’en vois.

Citation du juge Potter Stewart de la Cour Suprême des USA dans l’affaire Jacobellis contre l’Etat d’Ohio, en 1964.

REST vs. RPC ou REST + SOAP ?

Sur Interwingly, on a essayé de réconcilier le style architectural « REST » et les technologies d’appel à des procédures distantes (RPC). Les arguments d’une possible réconciliation sont les suivants :

  • croire que faire du HTTP GET suffit pour faire du REST, c’est une erreur
  • croire qu’avec SOAP, on ne peut faire que du RPC, c’est une erreur
  • si vous êtes un RESTafarien, vous devriez vous demander pourquoi la plupart des systèmes de bases de données relationnelles modernes incluent un mécanisme de procédure stockée (l’équivalent du RPC)
  • tout serait question d’enveloppe : qu’est-ce que je mets dessus (la référence de ce que j’invoque) ? qu’est-ce que je mets dedans (les paramètres…?)
  • si vous êtes dans le cas d’une application pour laquelle il faut privilégier l’évolutivité (« scalabilité ») et pour laquelle les données sont davantage en lecture qu’en écriture (tiens, ça fait penser aux annuaires LDAP, ça), alors l’approche REST s’impose
  • si vous êtes dans le cas d’une application pour laquelle il convient de gérer des écritures/mises à jour non atomiques, alors c’est peut-être dans SOAP que réside votre solution
  • un point fort de REST par rapport à SOAP + WSDL, c’est la facilité avec laquelle on peut lier des ressources entre elles
  • un point fort de SOAP par rapport à REST serait un gain de performance similaire à celui-ci qui résulte de l’emploi de procédures stockées dans le cas d’une base relationnelle

Les services Web ont besoin du Web Sémantique

Suite à une conférence sur les services web, un article de xmlhack.com constate que non seulement la moitié des participants connaissaient plus ou moins la technologie RDF mais aussi que les technologies du Web Sémantique, orientées données ou documents, offrent un potentiel d’intégration des processus d’entreprise bien plus important que la conception « classique » des Services Web, orientée API et appel à des procédures distantes. On retrouve là le classique constat de la supériorité architecturale de REST sur les modèles RPC.
Un commentateur suggère que cette prise de conscience vient du constat que, certes, SOAP n’est pas très compliqué à mettre en oeuvre (quoique pas très utile en soi), mais que WSDL ne servirait finalement pas à grand-chose.

XACML : un pseudo-standard de plus pour les services web

XACML est encore un autre standard pour les services web. Ce vocabulaire XML prétend couvrir la problématique de l’authentification (permettre à un agent de prouver qu’il agit bien au nom d’une personne donnée). En fait, il semble plutôt couvrir la problématique de l’autorisation (donner ou non le droit à un agent d’agir sur une ressource).
Avec XACML, les ressources à protéger sont sous la garde d’un service d’autorisation nommé PEP (Policy Enforcement Point). Le PEP formule en XACML la requête que l’agent adresse à la ressource (« Je, soussigné agent XYZ, désire lire la ressource ABC. ») Le PEP envoie cette requête XACML à un « PDP » (Policy Decision Point). Le PDP compare la requête XACML avec les règles d’autorisation qui ont été définies pour s’appliquer aux requêtes de ce type, sur cette ressource ABC. Le PDP formule sa décision d’autorisation (« Je consens à ce que l’on réponde à cette requête » ou « je refuse ») également en XACML et envoie ainsi sa réponse au PEP qui, lui, agit en conséquence (donne accès à la ressource ou renvoie un message d’erreur).
On peut lire dans une discussion à ce sujet sur Slashdot :

  •  » C’est une erreur fondamentale que de vouloir inclure des expressions logiques (telles que requises pour les décisions de contrôle d’accès) dans un langage (XML) qui ne le supporte pas. « 
  •  » Les standards de ce type ne représentent pas un progrès, ils représentent une masse croissante de redondance qui devra un jour être refondue pour former un tout cohérent. « 

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.