Différentes questions nous ont été posées sur les kits de démarrage/accélérateurs OGDI et ODAF. La première partie de ce billet nous a permis d’échanger sur une série de questions clé portant sur les thématiques suivantes :

  • Licence des données ouvertes ;
  • Méthodes d’accès aux données ouvertes ;
  • Formats des données ouvertes (formats protocolaires et/ou d’API et formats de fichier).

Cette seconde partie est l’occasion d’aborder ensemble les questions relatives à la dimension « Portail » :

  • Portail de publication des données ouvertes ;
  • Hébergement des données ouvertes et du portail de publication.

Une dernière partie clôturera cet échange avec la mise à disposition d’applications innovantes.

Portail de publication des données ouvertes

Q. Comment puis-je évaluer rapidement les apports de la plateforme OGDI avec quelques ensembles de données de tests ?

R. Microsoft France met à disposition une plateforme de test en ligne de façon à pouvoir tester et évaluer rapidement les apports de la plateforme OGDI avec quelques ensembles de données de tests (et/ou la capacité de développer une application ou un service vis-à-vis d’un (ou de plusieurs) ensemble(s) de données ouvertes.

De façon à ce qu’un (ou de plusieurs) ensemble(s) de données ouvertes soient chargés, il suffit d’envoyer un courriel à l’adresse ogdifrance@live.fr pour en faire la demande.

Q. Est-il possible de proposer un portail de portail sur la fondation du kit de démarrage OGDI ?

R. Oui. La configuration du kit de démarrage OGDI repose sur la notion de catalogues (d’ensembles) de données mis à disposition par l’entrepôt de données. Il est ainsi possible de déclarer simultanément plusieurs catalogues (d’ensembles) de données qui seront ensuite exploités par le service de données et le site Web interactif de la plateforme OGDI. Chaque catalogue ou source/conteneur de données correspond à une collection au sens OData en termes de points de terminaison.

Sur cette base, le site Web interactif par exemple tire parti de cette notion de catalogues vis-à-vis du service de données pour permettre de requêter et visualiser les données souhaitées/ciblées sous forme de tableaux, cartes, graphiques à barres ou diagrammes circulaires...

Le site govdata.eu fondé sur le kit de démarrage OGDI illustre cette fonctionnalité native.

Q. Peut-on faire de la plateforme OGDI une plateforme d’interconnexion de données ?

R. Oui. La prise en charge native de multi-catalogues (d’ensembles) de données et du protocole ouvert de données OData (Open Data Protocol) permettent facilement de publier, d’interconnecter et d’agréger des ensembles de données de façon à proposer sur cette base des applications et des services toujours plus innovants.

Q. Peut-on modifier/étendre la plateforme mise à disposition par le kit de démarrage OGDI ?

R. Oui. La licence libre Microsoft Public License (Ms-PL) sous laquelle est proposé le kit de démarrage OGDI rend possible toute extension.

Elle vise dans le contexte présent à encourager, sur cette fondation, le partage de code, la réutilisation/mutualisation des contributions.

Q. La plateforme OGDI s’adapte-t-elle facilement aux besoins d’une administration ou d’une collectivité territoriale particulière ?

R. Oui. Le kit de démarrage OGDI vise à mettre à disposition une solution ouverte, complète ET évolutive pour publier des ensembles de données ouvertes. C’est l’objectif même de conception.

Il s’agit de permettre aux Administrations et Collectivités Territoriales d’accélérer leur projet de publication de données ouvertes quel qu’il soit, de publier ainsi les informations publiques de leur choix, plus rapidement et efficacement, de les rendre navigables et interrogeables par les citoyens et les applications, et tout cela à moindres coûts de mise en œuvre, d’exploitation et d’usage.

Q. La plateforme OGDI permet-elle de contrôler ou de restreindre l’accès à certains ensembles de données ?

R. Oui si besoin. Il est ainsi possible, de mettre en place, un mécanisme d’authentification et d’autorisation pour accéder au service de données OGDI de façon par exemple, à :

  • Ne rendre le service en ligne dans sa phase de pré-production/mise en production accessible qu’à un certain public, l’équipe projet ou encore une cible d’usagers « pilote » ;
  • Ouvrir, dans un premier temps, la plateforme aux seuls développeurs d’applications, dans le cadre de la mise en œuvre de concours comme expérimentée dans certaines villes, ou l’organisation d’ateliers créatifs (« barcamps, forums créatifs, « coding parties ») pour sortir des usages classiques et faire émerger des projets très innovants ;
  • Accompagner une ouverture et mise à disposition progressive des jeux de données ;
  • Permettre, le cas échéant, une utilisation avec redevance afin de compenser les investissements consentis par les acteurs publics dans la mise à disposition (et la maintenance) de leurs données publiques. Nous vous invitons à ce titre à consulter le guide juridique et pratique sur les données publiques publié par l’agence aquitaine des initiatives numériques. Ce dernier, sorte de vadémécum des données publiques à destination des acteurs publics et privées revient, dans le cadre du mouvement Open Data, sur les enjeux juridiques et pratiques qui y sont liés ;
  • Etc.

Un tel mécanisme peut être très facilement mis en œuvre de façon standard et interopérable via le service de contrôle d’accès (ACS) de Windows Azure.

Ainsi, en termes de principes, le client doit, pour accéder au service de données RESTful OGDI, demander via le protocole d’autorisation OAuth (Open Authorization) 2.0 au service de contrôle d’accès ACS d’émettre un jeton de sécurité de type WST (Simple Web Token) définit dans le profil WRAP (Web Resource Authorization Protocol) qui sert de fondation à OAuth 2.0.

L’obtention d’un tel jeton d’autorisation suppose soit une authentification réussie auprès :

  • De votre instance du contrôle d’accès ACS, et ce via un login et un mot de passe gérés par ACS, ou autrement dit une identité du service ACS. ACS assure dans ce scénario le rôle de fournisseur d’identité ;
  • D’un fournisseur d’identité de confiance de votre instance du contrôle d’accès ACS. Il peut s‘agir i) d’une identité d’entreprise déclarée dans un annuaire d’entreprise comme Active Directory via Active Directory Federation Services (AD FS) 2.0 par exemple, ou ii) d’une identité Web tels que Windows Live ID, Google, Yahoo et Facebook.

ACS permet de représenter une politique de contrôle d’accès en dehors d’un service comme le service de données OGDI sous forme d’un ensemble de règles d’autorisation déclaratives. Ces dernières permettent de transformer, le cas échéant, des jetons de sécurité externes comme SAML (Security Assertion Markup Language) émis par des acteurs et partenaires de confiance en jetons de sécurité reconnus, consommables et compris par ledit service comme WST. Ces règles sont définies en utilisant un modèle XML très simple, ce qui par corollaire permet de bénéficier d’un code plus propre. ACS constitue ce que l’on appelle un service de jetons de sécurité ou STS (Security Token Service). ACS supporte de nombreux protocoles standards comme WS-Trust, WS-Federation, OpenID ou encore OAuth et prend en charge les formats de jeton SAML et WST.

Le tutoriel Contrôle de l’accès au service de données OGDI avec Windows Azure AppFabric (1ère partie, 2nde partie, 3ième partie et 4ième partie) décrit une telle mise en œuvre.

Q. La plateforme OGDI s’inscrit-elle dans les recommandations du RGI (Référentiel Général d’Interopérabilité) de la DGME (Direction Générale de la Modernisation de l’Etat) de façon à offrir un accès au plus grand nombre des citoyens ?

R. Oui pleinement.

Microsoft France comprend et soutient la volonté des pouvoirs publics de construire une administration électronique performante, accessible à l’ensemble des citoyens, et apportant motivation et confort pour les agents publics. L’interopérabilité vise, en effet, à favoriser le dialogue des systèmes d’information en utilisant notamment des protocoles et des formats reposant sur des standards ouverts. Cette dernière :

  • Constitue la clé du succès des initiatives d’administration électronique,
  • Permet la mise en œuvre de solutions importantes sur le plan social et politique : accessibilité, identification des citoyens, vie privée et sécurité,
  • Promeut un accès ouvert à l’information et adresse les problèmes de compatibilité avec le passé (continuité de l’état dans le temps et sur tout le territoire),
  • Entretient la bonne santé de l’écosystème informatique : choix, compétition et innovation,
  • Réduit les coûts, améliore l’efficacité, la flexibilité et la valeur ajoutée du système,
  • Évite aux États d’être l’otage d’un fournisseur.

C’est dans ce sens que Microsoft France comprend le RGI (Référentiel Général d’Interopérabilité) définissant un ensemble de recommandations pour faciliter les échanges et rendre cohérent l’ensemble constitué des systèmes d’information du service public ainsi que prévu par l’article 11 de l’ordonnance 2005-1516 du 8 décembre 2005 relative aux échanges électroniques entre les usagers et les autorités administratives et entre les autorités administratives :

« Le RGI fixe les règles techniques permettant d’assurer l’interopérabilité des systèmes d’information. Il détermine notamment les répertoires de données, les normes et les standards qui doivent être utilisés par les autorités administratives. Les conditions d’élaboration, d’approbation, de modification et de publications de ce référentiel sont fixées par décret. »

Microsoft France se félicite de cette publication.

Dans ce contexte, comme annoncé dans le communiqué de presse Microsoft Windows Azure prêt pour l’e-administration et l’Open Data, la plateforme Windows Azure devient, avec les kits de démarrage PRESTO (PRotocole d’Echanges STandard Ouvert) 2 pour Windows Azure et OGDI (Open Gouvernement Data Initiative) sous licence libre, la première solution de Cloud Computing compatible avec les e-services de l’Administration, et offre un environnement prêt pour la mise à disposition de données publiques, accessibles à tous.

Le kit de démarrage OGDI se présente sous la forme de composants sous licence libre qui permettent de mettre en œuvre immédiatement une approche Open Data. Associé à Windows Azure, ce kit permet aux collectivités et aux organismes publics de disposer d’une solution ouverte et complète pour publier des ensembles de données. Les données sont publiées à l'aide de protocoles ouverts et sont facilement accessibles à partir de n'importe quelle plate-forme et depuis de très nombreux outils de consultation et d’interrogation.

Q. Le RGAA (Référentiel Général d’Accessibilité pour les Administrations) de la DGME (Direction Générale de la Modernisation de l’Etat) s’applique-t-il à la mise en œuvre d’un portail de publication de données ouvertes ?

R. Oui. D’une façon générale, nous avons tout à gagner à faire de l'accessibilité (numérique) un critère explicite de qualité, à la fois parce que cela permet à des personnes handicapées ou à mobilité réduite d’accéder facilement à l’information, mais aussi parce que « madame ou monsieur tout le monde » trouvera des contenus accessibles plus conviviaux et plus faciles d'utilisation. Les données ouvertes doivent en faire naturellement partie.

Nécessité, l’accessibilité numérique garantit non seulement un accès égal à tous à l’information mais contribue également à la qualité, l’ergonomie et à la facilité d’utilisation de cette information. L’accessibilité numérique est également une obligation légale en France pour les Administrations et les Collectivités Territoriales.

Nous pouvons citer à ce titre en particulier :

« Les services de communication publique en ligne des services de l’état, des collectivités territoriales et des établissements publics qui en dépendent doivent être accessibles aux personnes handicapées.

L'accessibilité des services de communication publique en ligne concerne l'accès à tout type d'information sous forme numérique quels que soient le moyen d'accès, les contenus et le mode de consultation. Les recommandations internationales pour l'accessibilité de l'internet doivent être appliquées pour les services de communication publique en ligne. »

Ainsi, les Administrations et les Collectivités Territoriales françaises sont désormais obligées de se référer au RGAA (version 2.2 en date du 23 octobre 2009) pour attester de la conformité de leurs services en ligne aux recommandations WCAG (Web Content Accessibility Guidelines) 2.0 du W3C du 11 décembre 2008 (ou règles pour l'accessibilité des contenus Web selon la traduction française agrée disponible depuis le 25 juin 2009 sous la coordination de l’Association BrailleNet), selon les niveaux A et AA. Ces recommandations sont issues des travaux de l'initiative pour l'accessibilité du Web (Web Accessibility Initiative ou WAI en abrégé) du W3C.

La mise en œuvre d’un portail de publication de données ouvertes doit donc veiller à garantir l’accessibilité de celui-ci dans le respect d’une conformité avec le RGAA et à faire en sorte que les données ouvertes mises à disposition en téléchargement soient disponibles dans un format accessible et/ou facilitant leur utilisation dans un contexte d’accessibilité numérique comme le standard DAISY.

Q. La plateforme OGDI permet-elle de répondre aux exigences du RGAA (Référentiel Général d’Accessibilité pour les Administrations) de la DGME (Direction Générale de la Modernisation de l’Etat) de façon à offrir un accès au plus grand nombre des citoyens ?

R. Oui. Microsoft a reconnu très tôt que les technologies informatiques constituaient un outil important et puissant pour les personnes souffrant d’un handicap ou d’une diminution de leurs facultés (Cf. livre blanc L’accessibilité de quoi s’agit-il ?). Microsoft s’est engagé à offrir des innovations continues dans ce domaine. Depuis deux décennies, Microsoft a exploré et fait évoluer les fonctionnalités d’accessibilité qui sont intégrés dans ses produits.

Plus précisément, dans le contexte de la plateforme OGDI, le site Web interactif est réalisé avec la technologie Microsoft ASP.NET MVC 3. La technologie ASP.NET a été conçue à l’origine de façon à répondre aux points de contrôles (respectivement critères de succès) des règles pour l'accessibilité des contenus Web (WCAG) 1.0 (respectivement 2.0) du W3C.

Cette dernière, depuis la version 2.0, et aujourd’hui en version 4.0 (notamment dans son usage avec la plateforme OGDI, apporte des améliorations significatives et continues vis-à-vis de l’accessibilité numérique dans différents domaines : page maître et feuille de style CSS pour la séparation des données et de la présentation, (X)HMTL sémantique, navigation accessible, images accessibles, formulaires accessibles, données accessibles, etc. Tous ces éléments développés et illustrés dans l’article Accessibility in Visual Studio and ASP.NET permettent de préciser comment l’interface homme-machine personnalisable proposée par la plateforme OGDI est à même de s’inscrire dans le cadre du RGAA.

Par ailleurs, la technologie ASP.NET autorise également la prise en charge du standard en cours d’élaboration Accessible Rich Internet Applications (en abrégé WAI-ARIA ou plus simplement ARIA), un travail conduit par l'initiative pour l'accessibilité du Web du W3C pour répondre aux problématiques introduites par l’usage des technologies DHTML, AJAX, SVG, etc. en spécifiant des extensions descriptives pour les applications et portails Web riches. Cette dimension ne fait pas aujourd’hui partie des règles du RGAA.

Vous pouvez également consulter les ressources complémentaires proposées par le Centre de développement MSDN sur l’accessibilité.

Q. La personnalisation et/ou l’extension des fonctionnalités Web impose-t-elle de développer avec la technologie ASP.NET de Microsoft ?

R. Le site Web interactif de la plateforme OGDI correspondant à l’interface homme-machine est réalisé avec la technologie Microsoft ASP.NET MVC 3 et est conforme à l’architecture Modèle-Vue-Contrôleur (MVC). L’architecture MVC est une façon d'organiser une interface graphique, mais également et surtout une façon d’architecturer un code source en respectant le principe de responsabilité unique, le principe de séparation des préoccupations et répondre aux problématiques de testabilité du code. Ce paradigme divise l’interface de l’application en un modèle (modèle de données), une vue (présentation, interface utilisateur) et un contrôleur (logique de contrôle, gestion des événements, synchronisation), chacun ayant un rôle précis dans l'interface.

Le site Web ainsi proposé utilise également la bibliothèque jQuery sous licence libre, qui est une bibliothèque JavaScript rapide et concise qui simplifie les interactions AJAX, offrant également de belles capacités. Cette dernière dite « CSS-Friendly » s’insère bien dans un environnement comme ASP.NET où la présentation est fondée sur CSS ; ce qui revêt une certaine importance en termes de personnalisation.

Les choix de conception initiaux offrent donc une grande souplesse tant en termes de personnalisation que d’extensibilité.

Pour autant, rien n’empêche de développer des extensions avec une autre technologie et de partager une même charte graphique fondée sur des feuilles de style CSS.

A ce propos, la bibliothèque JavaScript eCSStender sous licence libre contribue à établir des feuilles de style CSS allégées et plus propres et ne comportant pas l'utilisation des propriétés spécifiques à des navigateurs. Qualifiée de « JQuery pour CSS », c'est une bibliothèque très flexible et bien documentée qui permet de découvrir l’étendue des capacités de CSS plus facilement.

Au final, des extensions de la plateforme OGDI peuvent être réalisées sans difficultés en HTML5, Ruby, PHP (Drupal, WordPress, Zend, etc.), etc.

Le site Open Data 71 du département de Saône-et-Loire en est une illustration :

  • Le site en lui-même a été développé sous WordPress, un outil PHP de gestion de contenu sous licence libre) ;
  • L’interface pour le citoyen Dataviz développé par Captain Dash est réalisée en HTML5 ;
  • L’interface pour le développeur reprend le site Web interactif de la plateforme OGDI.

Q. Peut-on mutualiser les investissements réalisés et les contributions apportées sur le kit de démarrage OGDI ?

R. Oui. La licence libre Microsoft Public License (Ms-PL) sous laquelle est proposé le kit de démarrage OGDI vise justement dans le contexte présent à encourager, sur cette fondation, le partage de code, la réutilisation/mutualisation des contributions.

Le blog MSDN OGDI France peut constituer à cet effet un vecteur (parmi d’autres) de relai et de partage des contributions. Il suffit pour cela d’envoyer un courriel à l’adresse ogdifrance@live.fr pour en faire la demande.

Hébergement des données ouvertes et du portail de publication

Q. Pourquoi proposer une plateforme ciblant spécifiquement un environnement Cloud ?

R. Les données publiques supposent une plateforme capable d’héberger un nombre croissant de données (et d’applications), totalement sécurisées, accessibles à tous et tout type de plateforme ou environnement et en mesure de supporter de forts pics de trafic.

Dans un tel contexte, l’utilisation d’un environnement ouvert d’exécution et d’hébergement dans le Cloud de type PaaS (Platform as a Service) présente de multiples bénéfices :

  • Une quantité illimitée d’informations publiques peut être hébergée dans le Cloud sans matériel serveur supplémentaire et gestion additionnelle. Les données publiques deviennent encore plus précieuses avec une plus grande pertinence locale. Par exemple, les villes et les collectivités (région, conseil général, communauté urbaine, etc.) génèrent des données riches sur l’espace public (voirie, assainissement), le transport et ses perturbations, les espaces naturels (parcs, arbres), les projets de construction, etc. ;
  • Le nuage est hautement évolutif (scalable) à la demande et en libre-service. Vous avez à tout instant la possibilité d’augmenter ou de réduire votre usage de l’environnement en fonction de vos besoins. Ceci le rend idéal pour l'hébergement de données publiques qui peuvent susciter des volumes de transactions variés en fonction de l’intérêt porté qui peut évoluer dans le temps notamment en fonction de votre actualité ;
  • Vous ne payez généralement seulement que pour ce qui est utilisé (fonction de l’offre PaaS considérée). Compte tenu du facteur d’échelle, un environnement de type PaaS propose généralement une approche économique des plus attractives pour démarrer rapidement et mettre à disposition des informations publiques.

Q. Qu’est-ce que Microsoft Windows Azure ?

R. La plateforme Windows Azure constitue l’offre PaaS (Platform as a Service) de Microsoft, un environnement ouvert d’exécution et d’hébergement dans le Cloud de services, d’applications et de données.

Autrement dit, la plateforme Windows Azure vous permet d'héberger, exécuter et gérer vos applications et données sans avoir à déployer et gérer l'infrastructure associée.

Pour cela, Windows Azure prend en charge une variété de normes et standards, de langages (.NET, PHP, Ruby, Python, Java, etc.) et de protocoles (http, fondés sur SOAP comme WS-*, de style REST comme le protocole ouvert de données OData, etc.) offrant ainsi à la fois une réelle portabilité pour prendre en compte l’hétérogénéité éventuelle résultant de vos investissements, une réelle interopérabilité et la capacité de capitaliser sur les compétences acquises (dans l’environnement Microsoft ou dans d’autres environnements) et les outils (Visual Studio et Eclipse) notamment. (Jean Paoli, en charge de la stratégie en matière d’interopérabilité chez Microsoft, revient sur les éléments d’interopérabilité d’une plateforme Cloud dans le billet Interoperability Elements of a Cloud Platform Outlined at OSCON.)

En outre, la facturation de la plateforme Windows Azure est basée sur l'usage (heure d'exécution, Go stocké par mois et bande passante consommée en particulier). La plateforme Windows Azure propose ainsi une approche économique des plus attractives pour démarrer rapidement et mettre à disposition des informations publiques qui se traduit par des tarifs compétitifs et flexibles dans le cadre d’un paiement à l’usage (sans engagement), d’offres d’abonnement (avec un engagement sur 6 mois), ou dans le cadre d’un accord d’entreprise Microsoft.

Q. Le choix de la plateforme PaaS Windows Azure de Microsoft pour la solution OGDI ne présente-t-il pas un risque en termes de sécurité ?

R. Comme fournisseur de services, Microsoft doit se conformer aux exigences réglementaires des entités gouvernementales pour les juridictions où la plateforme Windows Azure est opérée afin d’en assurer la conformité et de gérer les risques en matière de sécurité. Windows Azure fonctionne dans l'infrastructure de Microsoft Global Foundation Services (GFS), hébergeur de l’ensemble des services Microsoft – Windows Live, Office 365, etc. et dont certains des éléments sont certifiés ISO27001. En particulier, Microsoft's Global Foundation Services division has a separate ISO 27001 certification for the data centers in which Windows Azure is hosted.Microsoft Global Foundation Services dispose de sa propre certification ISO 27001 pour les centres de données au sein desquels Windows Azure est hébergé.

De même, le 29 novembre 2011, Windows Azure a obtenu la certification ISO 27001 de certification pour ses services de base à la suite d'un audit effectué par le British Standards Institute (BSI). You can view details of the ISO certificate here , which lists the scope as: “The Information Security Management System for Microsoft Windows Azure including development, operations and support for the compute, storage (XStore), virtual network and virtual machine services, in accordance with Windows Azure ISMS statement of applicability dated September 28, 2011.

La norme ISO/IEC 27001 est reconnue dans le monde entier comme l'une des principales normes internationales en matière de gestion de la sécurité et des exigences associées. Dans le même temps, d’autres certifications de l'industrie sont en cours d’évaluation pour la plateforme. En complément de la norme ISO/IEC 27001 internationalement reconnue, Microsoft Corporation est signataire du Safe Harbor et s'engage à remplir toutes ses obligations en vertu du Framework Safe Harbor.

Q. En terme disponibilité, quels sont les engagements de Microsoft pour la plateforme Windows Azure ?

R. La plateforme Windows Azure propose des contrats de niveau de service (Service Level Agreement ou SLA en abrégé) (distincts) pour le service de calcul et le service de stockage sur lesquels s’appuie la plateforme OGDI.

Ainsi, le contrat de niveau de service (SLA) lié au service de calcul Microsoft Windows Azure garantit que, lorsque vous déployez deux ou plusieurs instances de rôle dans différents domaines de mise à jour, vos rôles directement liés à Internet auront une connectivité externe d'au moins 99,95%. En outre, l'ensemble de vos instances de rôle individuelles sont surveillées avec la garantie que, dans 99,9% du temps, la supervision assurée détectera sous 2 minutes un processus d’une instance de rôle qui n'est pas en cours d'exécution et prendra alors des mesures correctives. Vous pouvez vous référez au lien précédent pour consulter les différentes clauses du contrat de niveau de service.

Enfin, le stockage, le contrat de niveau de service (SLA) lié au service de stockage Microsoft Windows Azure garantit que, dans 99,9% des cas, les requêtes correctement formatées reçues sont traitées avec succès afin d’ajouter, mettre à jour, lire et/ou supprimer des données. Le contrat garantit également que vos comptes de stockage disposent d’une connectivité à la passerelle Internet. Vous pouvez vous référez au lien précédent pour consulter les différentes clauses du contrat de niveau de service.

Q. Suis-je toujours propriétaire de mes ensembles de données publiés dans l’environnement Microsoft Windows Azure ?

R. Oui absolument. Vous demeurez le propriétaire de vos ensembles de données publiques stockés dans l’environnement ouvert d’exécution et d’hébergement Windows Azure.

D’un point de vue juridique et technique, les différents services proposés par l’environnement Windows Azure constituent simplement (sur la base de vos comptes associés) une extension évolutive à la demande (en libre-service) de votre système d’information en fonction de vos besoins et souhaits.

En particulier, vis-à-vis des ressources de stockage allouées et de leur utilisation, vous pouvez, par exemple, à tout instant ajouter ou/et retirer en libre-service des ensembles de données de l’environnement Windows Azure sans intervention externe. Enfin, les ensembles de données courantes ainsi publiés le sont sous le contrat de licence que vous avez défini/choisi.

Q. Est-il facile d’exporter mes ensembles de données publiés dans l’environnement Microsoft Windows Azure ?

R. Oui. Au-delà des interfaces programmatiques (API) proposées pour (le service de stockage de) Windows Azure, et des utilitaires de la plateforme OGDI, de nombreux projets libres, outils et solutions partenaires sont disponibles pour faciliter la gestion (import, export, modification, etc.) du ou des catalogues (d’ensembles) de données publiées au niveau service de stockage de Windows Azure.

On peut ainsi citer Windows Azure Storage Explorer, Celebrata Cloud Storage Studio, CloudBerry Explorer for Azure Blob Storage, etc.

Vous pouvez ainsi établir sur ces bases des procédures de sauvegarde/restauration, d’importation/exportation de vos ensembles de données publiés avec votre compte du service de stockage de Windows Azure. Vous disposez d’une portabilité complète de vos données.

Q. Peut-on reposer sur une forme de Cloud hybride de façon à mieux opérer l’environnement d’exécution de la plateforme OGDI ?

R. Oui. Il est possible d’utiliser pour cela notamment la fonctionnalité Windows Azure Connect de la plateforme Windows Azure pour configurer des connexions IPsec protégées entre les ordinateurs physiques ou virtuels de votre réseau d'entreprise, et les rôles relatifs à la plateforme OGDI s'exécutant dans Windows Azure dans le Cloud.

Après la configuration de ces connexions, les instances de rôle dans Windows Azure utilisent un adressage IP semblable à celui de vos autres ressources en réseau au lieu d'avoir à utiliser une forme d'adressage IP virtuel externe.

Q. Peut-on utiliser des identités d’entreprise pour l’accès à certaines parties de la plateforme OGDI et/ou à certains ensembles de données mis à disposition par la plateforme ?

R. Oui notamment au travers des classes WIF (Windows Identity Foundation) 1.0 du Microsoft Framework .NET et/ou du service de contrôle d’accès (ACS) de Windows Azure.

WIF 1.0 constitue un ensemble d'API, ou une bibliothèque d’identité, et d’outils à destination des développeurs ASP.NET pour i) établir un cadre de confiance dans un contexte de fédération avec le fournisseur d’identité de l’entreprise et ii) consommer directement des jetons de sécurité émis par celui après une authentification réussie de l’utilisateur en entreprise. Le jeton de sécurité contient des attributs (claims) sur l’identité d’entreprise de l’utilisateur.

De même, le service de contrôle d’accès met à disposition des composants de la plateforme OGDI (site Web interactif et service de données) une authentification fédérée des utilisateurs d’entreprise et un contrôle d’accès, tout en délocalisant/externalisant ces mécanismes d’authentification et d’autorisation en dehors du code métier. Au lieu d’implémenter un système d’authentification au niveau de la plateforme OGDI avec des comptes utilisateurs spécifiques, vous pouvez laisser ainsi ACS s’occuper de l’authentification et des autorisations de vos utilisateurs d’entreprise. Il s’intègre, pour cela, nativement avec des annuaires d’entreprise comme Active Directory via Active Directory Federation Services (AD FS) 2.0.

Dans ce contexte, ACS permet de représenter une politique de contrôle d’accès en dehors de la plateforme OGDI sous forme d’un ensemble de règles d’autorisation déclaratives. Ces dernières permettent de transformer, le cas échéant, les jetons de sécurité externes émis par le fournisseur d’identité d’entreprise en jetons de sécurité reconnus, consommables et compris par la plateforme OGDI. Ces règles sont définies en utilisant un modèle XML très simple, ce qui par corollaire permet de bénéficier d’un code plus propre. ACS constitue ce que l’on appelle un service de jetons de sécurité ou STS (Security Token Service).

Pour de plus amples informations, nous vous invitons à consulter le livre blanc Méta-système et mash-up d'identités avec les produits et technologies Microsoft ainsi que le guide Patterns & Practices A Guide to Claims-Based Identity and Access Control - 2nd Edition.

Q. Peut-on utiliser des identités sociales (Web) pour l’accès à certaines parties de la plateforme OGDI et/ou à certains ensembles de données mis à disposition par la plateforme ?

R. Oui notamment via le service de contrôle d’accès (ACS) de Windows Azure.

Le service de contrôle d’accès met à disposition des composants de la plateforme OGDI (site Web interactif et service de données) une authentification fédérée des utilisateurs Web et un contrôle d’accès, tout en délocalisant/externalisant ces mécanismes d’authentification et d’autorisation en dehors du code métier. Au lieu d’implémenter un système d’authentification au niveau de la plateforme OGDI avec des comptes utilisateurs spécifiques, vous pouvez laisser ainsi ACS s’occuper de l’authentification et des autorisations de vos utilisateurs Web. Il s’intègre, pour cela, nativement avec différents fournisseurs d’identité Web tels que Windows Live ID, Google, Yahoo et Facebook.

Dans ce contexte, ACS permet de représenter une politique de contrôle d’accès en dehors de la plateforme OGDI sous forme d’un ensemble de règles d’autorisation déclaratives. Ces dernières permettent de transformer, le cas échéant, des jetons de sécurité externes émis par les fournisseurs d’identité Web de confiance en jetons de sécurité reconnus, consommables et compris par la plateforme OGDI. Ces règles sont définies en utilisant un modèle XML très simple, ce qui par corollaire permet de bénéficier d’un code plus propre. ACS constitue ce que l’on appelle un service de jetons de sécurité ou STS (Security Token Service).

Pour de plus amples informations, nous vous invitons à consulter le livre blanc Méta-système et mash-up d'identités avec les produits et technologies Microsoft ainsi que le guide Patterns & Practices A Guide to Claims-Based Identity and Access Control - 2nd Edition.

Q. La plateforme OGDI supporte-elle les standards de fédération d’identité ?

R. Oui notamment au travers des classes WIF (Windows Identity Foundation) 1.0 du Microsoft Framework .NET et/ou du service de contrôle d’accès (ACS) de Windows Azure.

WIF propose nativement le support des standards OASIS WS-Federation et WS-Trust. L’extension WIF pour SAML 2.0 prend en charge le standard OASIS SAML 2.0. L’extension WIF pour OAuth apporte enfin, comme son nom le suggère, le support du protocole d’autorisation OAuth (Open Authorization) 2.0.

Quant au service de contrôle d’accès ACS, ce dernier supporte de nombreux protocoles standards comme WS-Trust, WS-Federation, OpenID ou encore OAuth 2.0.

Q. Le choix de la plateforme PaaS Windows Azure de Microsoft ne constitue-t-elle un facteur limitant quant à l’utilisation de technologies non-Microsoft pour étendre et/ou personnaliser la plateforme OGDI ?

R. Non absolument pas. La plateforme Windows Azure prend en charge une variété de normes et standards, de langages et de protocoles offrant ainsi à la fois une réelle interopérabilité et la capacité de capitaliser sur les compétences acquises et les outils.

Vous pouvez consulter le site Interoperability Bridges and Lab Centers pour les différents runtimes et services (Java, MySQL, Ruby, PHP, Python, etc.), bibliothèques et kits de développement langages (Java, Ruby et PHP), environnements de développement (Eclipse, etc.) et outils (en ligne de commande) pris en charge par Windows Azure.

Il est ainsi possible, par exemple, de mettre en œuvre un portail de données en PHP, la plupart des Frameworks/CMS/CMF étant « Windows Azure-ready » : Drupal 7, Joomla 1.7, Symfony 2, Wordpress, Zend Framework 1.11. Le portail Open Data 71 développé en WordPress est hébergé dans Windows Azure. Le site Windows Azure pour PHP regroupe l’ensemble des ressources liées à PHP.

De la même façon, le site Windows Azure pour Java regroupe l’ensemble des ressources liées à l’environnement Java.

Q. Comment peut-on évaluer les coûts de mise en œuvre et de fonctionnement dans Windows Azure ?

R. Le kit de démarrage OGDI s’exécute par défaut sur la plateforme Microsoft Azure, l’offre de PaaS (Platform as a Service) de Microsoft, un environnement ouvert d’exécution et d’hébergement dans le Cloud de services, d’applications, et de données. Ainsi, en tant que fournisseur à un large nombre d’entités, Microsoft bénéficie d’effets d’échelles qui lui permettent en retour de diminuer les coûts d’usage individuels. Ainsi, les organisations ne payent que ce qu’elles consomment et ont la possibilité d’augmenter ou de réduire leur usage en fonction de leurs besoins.

La plateforme Windows Azure propose pour cela des tarifs compétitifs et flexibles dans le cadre d’un paiement à l’usage (sans engagement) ou d’offres d’abonnement (avec un engagement sur 6 mois) qui permettent de bénéficier d’une réduction par rapport au tarif standard. Pour permettre aux clients d’anticiper les coûts d’exploitation, Microsoft met à disposition un outil de calcul en ligne.

Cet outil permet d’évaluer les coûts d’exploitation afférents au kit de démarrage OGDI dans le cadre d’une exploitation classique dudit kit sur la base du tarif standard.

Comme décrit dans la documentation du kit de démarrage OGDI, la solution OGDI nécessite pour s’exécuter correctement les ressources suivantes :

  • 3 instances de machines virtuelles (1 pour le service de donnée RESTful OData et 2 pour le site Web interactif) ;
  • 2 comptes de stockage (1 pour les données et 1 pour la configuration et les statistiques).

Ainsi, pour la mise en place d’une politique Open Data ambitieuse, on peut estimer la consommation mensuelle suivante :

  • 6 instances de machines virtuelles de taille Extra Small (pour assurer la redondance et la répartition de charge) ;
  • 100 giga-octets de stockage de données ;
  • 2,25 millions de transactions ;
  • 100 Giga-octets de transfert de données.

Le coût d’exploitation mensuel estimé résultant est de 149,99 €/mois.

Q. Peut-t-on modifier la plateforme OGDI de façon à pouvoir être mise en œuvre dans le cadre d’un environnement Cloud autre que le service PaaS Windows Azure de Microsoft ?

R. Oui. La plateforme OGDI offre une architecture modulaire en couches de façon à pouvoir être adaptée le cas échéant à d’autres environnements d’exécution et de stockage, tout en limitant l’impact au niveau du code.

L’utilisation d’un autre environnement Cloud PaaS en termes de service d’exécution suppose néanmoins que le Microsoft Framework .NET, et dans ce contexte, la technologie ASP.NET MVC 3, soient pris en charge.

Par ailleurs, d’un point de vue stockage (et éléments de configuration associés), il est nécessaire, dans ce contexte, de modifier la solution et, en particulier, les projets StorageInterface, WindowsAzure, Ogdi.Azure et OgdiConfig pour reposer sur le stockage cible en lieu et place du service de stockage Azure. Il conviendra d’opter pour un stockage pris en charge par le service PaaS cible et avec lequel le Microsoft Framework .NET est à même d’interagir, par exemple au travers de la technologie LINQ (NET Language Integrated Query).

Q. Peut-t-on modifier la plateforme OGDI de façon à pouvoir être mise en œuvre dans le cadre d’un hébergement classique ?

R. Oui. La plateforme OGDI offre une architecture modulaire en couches de façon à pouvoir être adaptée le cas échéant à d’autres environnements d’exécution et de stockage, tout en limitant l’impact au niveau du code.

D’un point de vue stockage (et éléments de configuration associés), il est nécessaire, dans ce contexte, de modifier la solution et, en particulier, les projets StorageInterface, WindowsAzure, Ogdi.Azure et OgdiConfig pour reposer, par exemple, sur une base de données relationnelles en lieu et place du service de stockage Azure. C’est par exemple, l’objet de la branche (fork) Open Data Publisher disponible sur la forge Codeplex qui permet d’utiliser une base Microsoft SQL Server.