A quoi sert l'ADAE ?

Dans le domaine de l'administration électronique (le e-Government des anglo-saxons), la France subit un retard astronomique et les choses ne semblent pas s'améliorer.

Alors que le Royaume-Uni en est à participer, au travers de son unité de e-Government, à la normalisation dans le domaine de la fiabilité de la messagerie dans les architectures de services Web (voir ici et là), la France, dont l'Agence pour le Développement de l'Administration Electronique (ADAE) devait représenter l'entité responsable de la mise en place de cette administration modernisée, en est toujours aux balbutiements et n'a toujours rien de concret à proposer à ses citoyens, entreprises et collectivités.

Pendant que le Royaume-Uni propose depuis 2001 une passerelle d'accès aux services gouvernementaux moderne, construite à l'aide des technologies de services Web (SOAP et WS-Security notamment) , et qui offre les services d'infrastructure suivants :

• authentification des utilisateurs et autorisation d'accès aux services ;
• connection par login ou certificat pour l'utilisation des services publics ;
• gestion de messagerie : échanges de documents et messages entre citoyens, entreprises et entités gouvernementales.

... du côté de la France : nada.

Sur le site de l'ADAE, on trouve bien une description de l'EAI et des services Web qui date (référence aux spécifications WSFL, Xlang et WSCI) et dont la distinction entre les deux concepts laisse à désirer.

Un cadre commun d'interopérabilité des SI publics qui date de septembre 2003 est également disponible. Celui-ci est truffé d'erreurs : on y apprend par exemple que UDDI est un annuaire mondial (et l'UBR alors ? Et les annuaires privés ?) , que "J2EE n'est pas un standard en soi, mais un ensemble de standards ayant leur cycle de vie propre" (EJB, JAXP sont donc des standards : W3C ? OASIS ?). Par ailleurs, il présente entre autres les plates-formes logicielles qui supportent les services Web : J2EE (1 page), .NET (1 page) et ZOPE (4 pages ...). Enfin, pas un mot sur le contrôle de l'interopérabilité et le rôle du WS-I dont la création remonte pourtant à février 2002 : pour un document dont le sujet se veut l'interopérabilité, cela laisse rêveur.

Même l'Europe est en avance dans ce domaine à travers le projet eLink de l'agence Interoperable Delivery of European eGovernment Services to public Administrations, Businesses and Citizens (IDABC) de la Communauté Européenne, lancé en 2003 et terminé en septembre 2004. Celui-ci s'appuie sur l'utilisation des standards SOAP, WSDL, UDDI et WS-Security (XML-Encryption et XML-Signature). Il est issu des projets Government eLink (GeL) developpé en Suède et Online Services Computer Interface (OSCI) développé par l'Allemagne. Les technologies Java et des composants Open Source ont été mis en oeuvre par eLink.

Par ailleurs, où en est l'ADAE dans la prise en compte des recommandations publiées dans l'European Interoperability Framework (EIF), document de référence dans la mise en place de services pan-européens ? Qu'en est-il de la prise en compte de la dimension européenne dans le cadre commun d'interopérabilité de l'ADAE (recommandation n°1) et plus généralement du respect des recommandations en matière d'interopérabilité organisationnelle, sémantique et technique ?

Bref, à part quelques avancées, notamment dans le domaine de l'accessibilité aux sites Web, on peut légitimement s'interroger sur le rôle actuel et l'utilité de l'ADAE. Rappelons tout de même que le budget de cette organisation représente 1,8 milliards d'euros pour la période 2004-2007 ...

Création du comité technique Web Services Reliable Exchange à l'OASIS

Suite à la soumission de la spécification WS-ReliableMessaging, l'OASIS a décidé de mettre en place un nouveau comité technique dont l'appel à participation précise que la première réunion de travail se tiendra le 23 juin 2005.

Le nouveau comité technique, intitulé Web Services Reliable Exchange (WS-RX) TC, sera complémentaire aux comités Web Services Reliable Messaging (WSRM) et ebXML Messaging Services de l'OASIS et les auteurs de l'appel à participation souhaitent notamment une participation des membres du comité WSRM.

Parmi les spécialistes qui appellent à la mise en place de ce nouveau comité de normalisation WS-RX, on trouve des membres des sociétés ou organisations suivantes : ACORD, Adobe, Actional, Arjuna, BEA, Blue Titan, Choreology, Entrust, Ericsson, Hitachi, IBM, IONA, Microsoft, Nec, Nortel, Novell, OAGI, Oracle, Reactivity, SAP, SeeBeyond, Sonic Software, Sun Microsystems, Systinet, TIBCO, l'unité e-Government de Grande-Bretagne, l'université de Caroline du Nord - Chapel Hill et webMethods. Bref, rien que du beau monde ...

Rapprochement dans le domaine de la gestion des identités

Le premier anniversaire de la paix entre les anciens frères ennemis Microsoft et Sun Microsystems a donné lieu à une conférence de presse commune de Steve Ballmer et Scott McNealy hier.

Cette conférence a été l'occasion d'annoncer deux nouvelles spécifications (j'en connais qui vont hurler ...) destinées à assurer l'interopérabilité Web SSO entre des systèmes qui mettent en oeuvre les deux frameworks Liberty Alliance et WS-Security :

• le protocole d'échange de méta-données Web SSO (Web Single Sign-On Metadata Exchange Protocol - Web SSO MEX) ;
• le profil d'interopérabilité Web SSO (Web Single Sign-On Interoperability Profile - Web SSO Interop Profile).

Le protocole d'échange de méta-données permet à un service Web d'échanger les méta-données qui décrivent les suites de protocoles d'identification supportées par le fournisseur d'identité du client afin de déterminer le protocole d'identification qui sera utilisé pour la suite de la conversation. Le protocole décrit notamment comment est localisé le fournisseur d'identité du client, puis comment lui est adressée la requête pour obtenir les méta-données. Le protocole s'appuie sur les spécifications WS-Addressing et WS-MetadataExchange. Evidemment, ces échanges doivent être sécurisés via l'utilisation de la spécification WS-Security entre les endpoints.

Le profil d'interopérabilité qui s'applique au protocole d'échange de méta-données définit comment le service Web choisit le protocole d'identification supporté par le fournisseur d'identité du client, que celui-ci appartienne à une fédération Liberty Alliance ou à une fédération WS-Federation. L'interopérabilité s'appuie sur la mise en oeuvre d'assertions SAML pour échanger les informations relatives à l'identité.

Les spécifications sont publiées ici et là.

Ces deux spécifications sont publiées pour révision. Les prochains développements seront réalisés dans le cadre habituel des ateliers interop et feedback et feront in fine l'objet d'une soumission à un organisme de standardisation (OASIS ?).

Intégration communications - processus

BPEL donne des idées à Avaya : les processus métier communicants sont en route.

Apache Axis 1.2 is alive and well

En tout cas pour Sforce.

Comment faire du neuf avec du vieux ... ou les ravages du marketing viral

Le nouveau concept à la mode depuis quelque temps parmi les développeurs Internet porte le nom d'une lessive : Ajax. Depuis le 18 février 2005, l'acronyme se répand comme une trainée de poudre (!), notamment dans les blogs, forme de marketing viral que ne renierait pas Colgate-Palmolive ... Même les vénérables Wall Street Journal et New York Times se sont fendus d'un article consacré à cette "nouvelle" technique, c'est tout dire.

Le terme a été forgé par Jesse James Garrett, co-fondateur d'une jeune société de conseil, dont le principe a été décrit dans un article intitulé "Ajax: A New Approach to Web Applications" publié récemment.

Cependant, comme le dit aimablement Jean Paoli, l'un des trois auteurs du standard W3C XML :

"I've been doing Ajax for years but it's got a name now.".

En effet, ce modèle de programmation repose sur l'utilisation du composant ActiveX XMLHttpRequest disponible depuis la sortie du navigateur Internet Explorer 5.0 (depuis peu donc ...). Une implémentation équivalente a été réalisée ensuite dans les navigateurs Mozilla (et Netscape) et plus récemment dans Safari, Konqueror et Opera. Bref, cela fait plusieurs années que cette technique est utilisable et a été utilisée.

Plus généralement, ce modèle découle directement de l'approche DHTML initiée par les travaux de l'équipe de Adam Bosworth (Scott Isaacs, Chris Lovett, ...) autour du navigateur Internet Explorer 4.0 comme le rappelle Scott Isaacs, avant l'apparition de XML (le X de Ajax).

Alors, pourquoi en parle-t-on autant aujourd'hui ? Parce que Googlemania (entre autres) : Suggests (voir dissection du code ici), GMail, Maps (voir dissection du code ici), ... Faut-il sentir la patte de Adam Bosworth, ex-BEA, ex-Microsoft, derrière ce choix technologique récent de Google ?

Pour finir, ce qui se cache en réalité derrière cette soudaine éruption marketing, c'est la question du concept de client riche comme le rappelle Mary Jo Foley. Chez Microsoft, celle-ci passe par les smart-clients et l'utilisation du framework .NET (en phase de diffusion rapide sur les postes utilisateurs via windows XP). Le modèle Ajax constitue l'une des approches possibles pour développer un framework de client riche, mais n'est pas la seule.

Il faut noter enfin qu'il est également possible de réaliser des invocations asynchrones de services Web depuis longtemps via un autre composant d'origine Microsoft, utilisable aussi depuis l'apparition du navigateur Internet Explorer 5.0 : il s'agit du behavior WebService capable de fonctionner au choix en mode synchrone ou asynchrone (ce dernier par callback de méthodes Javascript).

Cependant, ce composant n'est pas supporté en production car cette approche, pas plus que l'approche Ajax, ne va dans le sens de l'évolution souhaitée par Microsoft.