standard

Standards, normes, référentiels

RMLL 2013 - Bruxelles - 6 au 11 Juillet

Les RMLL (Rencontres Mondiales du Logiciel Libre) se tiendront à Bruxelles du 6 au 11 juillet 2013.

Une session Enseignement Supérieur et Recherche aura lieu les 9 et 10 Juillet : plus d'informations ici

OpenSearch : spécification pour standardiser les fonctions de recherche en ligne

Fiche ressource Article, événement, site web...
  • Création ou MAJ importante : 21/05/13
  • Correction mineure : 21/05/13
Mots-clés

OpenSearch : spécification pour standardiser les fonctions de recherche en ligne

  • http://www.opensearch.org
  • Type de ressource : résumé
  • Date de publication du document ou de l'événement : 2005
  • Auteur(s) ou responsable(s) : A9 (filiale d'Amazon.com)

Description courte :

OpenSearch est une spécification qui offre des services de recherche sur un site Internet et ce, indépendamment de la technologie du moteur de recherche utilisé par ce site. L'objectif est de proposer un standard pour la recherche et la publication sur Internet.

Avec cette technologie, il est ainsi possible d'agréger et d'afficher les résultats de plusieurs sites de recherche différents. On peut par exemple effectuer la même requête sur une base de données documentaire, un dictionnaire en ligne et un wiki, et afficher les résultats sur une même page.

Il est également possible de rajouter son moteur de recherche sur n'importe quel client de recherche qui contient un agrégateur OpenSearch (dans lequel on peut configurer son fichier de description OpenSearch). L'un des exemples d'utilisation les plus connus de cette technologie est l'intégration de listes de sites de recherche dans les navigateurs web (champ de recherche situé à droite de la barre d'URL sur Firefox et Internet Explorer).

Documents de standardisation : La dernière spécification se trouve ici : OpenSearch 1.1 (Draft 5)

Description détaillée :

OpenSearch ne remplace pas un moteur de recherche mais propose donc une surcouche afin d'uniformiser les formats de publication. En ce sens, on peut apparenter cette technologie à un « service web » pour la recherche sur Internet.

Techniquement, OpenSearch utilise XML et les flux de syndication (RSS ou Atom).

Pour pouvoir offrir tous les composants nécessaires à la recherche standardisée sur Internet, la spécification OpenSearch est composée de quatre formats complémentaires :

  • OpenSearch description document

    C'est un fichier XML qui identifie et décrit le moteur de recherche. En plus de l'adresse du namespace de la spécification «http://a9.com/-/spec/opensearch/1.1/», ce fichier doit contenir au moins les 3 balises obligatoires suivantes : ShortName pour le nom du service, Description pour sa description et Url qui contient l'adresse du site de recherche.

  • OpenSearch URL template syntax

    Ce format contient différents paramètres qui permettent de décrire la syntaxe de recherche utilisée par le moteur de recherche. Il précise notamment les règles de grammaire de l'attribut template de la balise Url utilisée dans le document de description précédent.

  • Opensearch Query element

    Ce format permet de configurer des requêtes spécifiques par un client de recherche. Il est composé d'un ensemble d'attributs de la balise Query. On peut par exemple proposer un exemple de requête qui peut être effectuée sur le moteur de recherche ou encore afficher des résultats avec des mots proches de celui utilisé par la requête (mais contenant une faute d'orthographe par exemple).

  • OpenSearch response elements

    C'est le format de présentation des résultats de recherche. Les formats possibles nativement sont RSS 2.0 et Atom 1.0. D'autres formats de publication sont possibles comme HTML/XHTML.

En plus de ces formats, il existe plusieurs extensions, parmi lesquelles :

  • Referrer

    Permet de fournir des informations sur la source effectuant la recherche, comme par exemple le logiciel client utilisé

  • Relevance

    Permet d'indiquer le score de chaque résultat d'une recherche donnée

  • Suggestion

    Permet l’auto-complétion de mots dans le champ de recherche.

Pour l'utilisation de chacune de ces extensions, il faudra ajouter l'adresse du namespace XML de la spécification dans le fichier de description.D'autres extensions sont encore à l'état de draft mais offriront des possibilités intéressantes, notamment :

  • Geo extension

    Propose de fournir un mécanisme standard pour effectuer des recherches sur des données géographiques, comme des coordonnées ou des noms d'endroits.

  • Mobile extension

    Propose un mécanisme standard pour adapter les recherches de type OpenSearch aux terminaux mobiles, notamment dans l'affichage des résultats.

Utilisations recommandées :

Tout site utilisant OpenSearch peut être directement intégré au navigateur en utilisant la zone de recherche adaptée.

OpenSearch peut également être utilisé sur des applications hébergeant des moteurs de recherche et fournissant des services en ligne. Cela peut rendre l'application plus générique et permet d'accepter des requêtes à partir d'autres applications. Un exemple d'application en milieu scientifique est le logiciel SITools2 qui intègre nativement un champ de recherche OpenSearch. D'autre part, de nombreux CMS ou wiki implémentent opensearch soit de manière native soit grâce à un plugin: par exemple WordPress, SPIP,Drupal, PLONE, GetNetwork, DokuWiki, MediaWiki

OpenSearch est également très utilisé pour les recherches sur les sites bibliographiques car contenant de multiples bases de données provenant de sources différentes (voir par exemple le site de la revue internationale Nature : http://www.nature.com/opensearch).

Exemple de mise en œuvre :

Pour pouvoir configurer un service OpenSearch sur un moteur de recherche, il faut effectuer les trois étapes suivantes :

  • Configurer le moteur de recherche pour proposer en option une réponse au format RSS ou Atom (cela permettra d'utiliser les paramètres du format OpenSearch response elements)

  • Créer un fichier de description au format OpenSearch description document

    Le fichier minimum doit être de la forme :

    <?xml version="1.0" encoding="UTF-8"?>
    <OpenSearchDescription xmlns="http://a9.com/-/spec/opensearch/1.1/">
      <ShortName>${name}</ShortName>
      <Description>${name}</Description>
      <Url type="application/html" template="${url}/suggest?q={searchTerms}">
      </Url>
    </OpenSearchDescription>

    Où ${name} est le nom du site et ${url} l’adresse du site.

  • Publier le fichier précédent en ajoutant un lien dans le header de la page d'accueil du site de recherche.

    Si par exemple le fichier s'appelle opensearch.xml :

    <link rel="search" type="application/opensearchdescription+xml" title="${name}" href="${url}/opensearch.xml">

Une étape supplémentaire peut être d'envoyer ce fichier de description à l'un des annuaires de moteurs de recherche supportant OpenSearch pour faire connaître le service de recherche.

Il existe en outre de nombreuses bibliothèques qui implémentent les services OpenSearch. Une liste détaillée se trouve ici :
http://www.opensearch.org/Community/OpenSearch_sof...

 

CORBA

Fiche ressource Article, événement, site web...
  • Création ou MAJ importante : 30/10/12
  • Correction mineure : 30/10/12
Mots-clés

CORBA

  • http://www.corba.org/
  • Date de publication du document ou de l'événement : Octobre 1991
  • Auteur(s) ou responsable(s) : OMG
Ce document a été rédigé par David Rousse, puis relu et complété par Riadh Ben Halima (LAAS et Ecole Nationale d'Ingénieurs de Sfax (Tunisie)) et Bechir Zalila (Ecole Nationale d'Ingénieurs de Sfax (Tunisie)).

Vue d'ensemble

Les principes

  • CORBA (Common Object Request Broker Architecture - Architecture de Négociateur de Requêtes sur un Objet Commun) fait parti de la famille des middleware (intergiciels) applicatifs, qui permettent de créer des applications basées sur des objets distribués auto-gérables, interagissant librement et indépendamment de la localisation de leur implantation sur un réseau. Un objet CORBA offre des services (via les algorithmes implantés dans ses méthodes) à des clients distants qui peuvent fonctionner sur différents systèmes d'exploitation tout en utilisant plusieurs langages de programmation.
  • Un objet CORBA est autonome et prêt à être branché sur des réseaux, des applications, des outils. Ainsi, cet objet métier se caractérise par les notions suivantes :
    • élément logiciel binaire et prêt à l’emploi,
    • destiné à exécuter un ensemble limité de tâches dans un domaine particulier,
    • interopérable (objets qui interagissent sans à priori se connaître),
    • disposant d'une interface pour permettre à l’extérieur d’accéder aux services offerts.
  • Les objets métier sont des entités logicielles autonomes rendant des services particuliers pour un métier donné.
  • Le développement d’applications à base d'objets CORBA apporte de multiples avantages :
    • disposer d'objets d’origines diverses qui peuvent interagir facilement,
    • créer ses propres applications avec des scripts et des objets en minimisant le développement dédié.

L'architecture

  • CORBA est une spécification d'un middleware orienté objet spécifié par l’OMG (Object Management Group)
    • CORBA est une architecture distribuée d’objets hétérogènes qui coopèrent via un bus logiciel,
    • CORBA permet à un ensemble d’objets distribués d’inter-opérer.
  • CORBA fournit une vision unique d’une architecture distribuée dans des environnements hétérogènes :
  • CORBA, architecture distribuée
    NB : on pourrait avoir sur le schéma des ORB pour chaque machine qui communiquent entre eux via le réseau.

Les points clés

  • Les points clés de CORBA sont :
    • masquer l’hétérogénéité des langages de programmation, des systèmes d’exploitation, des machines, …,
    • assurer l’interopérabilité entre objets, entre fournisseurs multiples,
    • être basé sur un langage commun pour la description, l’IDL,
    • proposer un bus logiciel, l’ORB,
    • fournir un modèle Client-Serveur orienté objet (dans le sens où le service est demandé par invocation de méthodes sur un objet distant).
  • L’architecture ouverte proposée par l’OMG, l’OMA (Object Management Architecture), peut se résumer ainsi :
  • CORBA, architecture distribuée

L'IDL (Interface Definition Language)

  • La base de l’interopérabilité de la spécification CORBA repose sur des interfaces écrites dans un langage neutre, l’IDL :
  • CORBA, extrait IDL
  • L’IDL est un langage purement déclaratif qui permet de décrire le contrat métier que l'objet offre au monde extérieur :
  • CORBA, architecture IDL

L'ORB (Object Request Broker)

L'ORB, définition

  • L’ORB est le négociateur de requêtes à objets autrement dit le bus à objets, qui fournit un ensemble très riche de services de middleware répartis :
    • il établit les relations entre objets, indépendamment de la localisation de ces derniers,
    • il permet donc aux objets de se découvrir, les uns les autres et d’interagir.
  • La notion de Client-Serveur est relative à une situation donnée. Pour l’ORB, un objet peut être client ou serveur selon les besoins :
  • CORBA, architecture ORB

L'ORB, côté client

  • La structure d’un ORB « coté client » en CORBA 3.0 peut être schématisée ainsi :
  • CORBA, architecture ORB client NB : la souche est déduite (générée) à partir de l'IDL.
  • Les souches (stubs) fournissent les interfaces des services objet du serveur. Pour chaque objet distant, le client doit posséder la souche correspondante à l’objet. Grâce à cette souche, l’encodage (et le décodage) de l’appel d’une méthode (avec ses paramètres) pourra être réalisé (marshalling) et envoyé au serveur.
  • Les appels dynamiques se font grâce aux interfaces à appel dynamique (DII pour Dynamic Invocation Interface), qui permettent donc de découvrir la méthode à exécuter au moment de l’exécution.
  • Le référentiel d’interfaces est une « base de données » qui contient toutes les versions exécutables (versions binaires) des interfaces définies en IDL. Des API de CORBA permettent d’accéder à ces métadonnées (données décrivant un objet).
  • Les interfaces de l’ORB sont des API permettant d’accéder à certains services de l’ORB (transformation d’une référence d’objet en son nom en clair par exemple).

L'ORB, côté serveur

  • La structure d’un ORB « coté serveur » en CORBA 3.0 peut être schématisée ainsi :
  • CORBA, architecture ORB serveur
  • Les squelettes (skeletons) du serveur ont le même rôle que les stubs : ils sont générés à partir de l'IDL et décrivent les services fournis par le serveur.
  • Les appels dynamiques se font via les interfaces de squelettes dynamiques (DSI pour Dynamic Skeleton Interface) : ils permettent l’appel de méthodes pour des objets serveur qui ne possèdent pas de skeletons.
  • Le référentiel d’implantation contient l’ensemble des classes supportées par le serveur, les objets en mémoire et leurs OIDs (Object IDentifier).
  • Les interfaces de l’ORB ont le même rôle que chez le client.
  • L’adaptateur d’objet (BOA, POA, …) se situe au dessus du noyau de l’ORB : c’est lui qui va traiter les demandes d’appels de méthodes. Pour ce faire, il fournit un environnement d’exécution pour créer les instances des objets sur le serveur. L’adaptateur va également enregistrer les objets dans le Référentiel d’implantations :
    • l’adaptateur d’objet (OA, Object Adaptater) fournit un environnement complet pour que les instances d’objets puissent vivre sur le serveur. Son principal rôle est d’associer une requête portant sur un objet référencé au code spécifique qui doit servir la requête,
    • toute machine voulant être un serveur d’objets doit posséder au moins un adaptateur d’objets,
    • plusieurs types d’OA ont été spécifiés (Basic OA avant CORBA 2.2: obsolète et pauvre, Portable OA après CORBA 2.2: riche),
    • un OA réalise principalement les actions présentées dans le schéma ci-dessous.
    • CORBA, architecture OA

L'architecture inter-ORB

  • L’OMG a défini un protocole standard pour faire communiquer deux ORBs (deux implantations différentes de CORBA). La spécification CORBA a baptisé ce protocole GIOP (General Inter-ORB Protocol) :
    • GIOP est situé au dessus de tout protocole de transport : ce protocole spécifie comment deux ORBs peuvent communiquer.
    • IIOP (Internet Inter-ORB Protocol) est une instance de GIOP au dessus de TCP/IP et permet d’acheminer des messages entre 2 ORBs.
  • CORBA, architecture inter-ORB

Les services

  • CORBA fournit un ensemble de services (CORBA Services) au niveau système. Ces services sont proposés sous forme d'objets.
  • Ces services viennent enrichir les services de base de l’ORB. On peut citer comme services :
    • nommage (localisation des objets par leurs noms en clair).
    • cycle de vie (gestion de la création, de la copie, de la suppression des objets sur le bus),
    • persistance (stockage des objets),

Les utilitaires communs

  • Les utilitaires communs (Common Facilities) sont des composants qui fournissent des services directement utilisables par les objets métier.
  • Ces services sont encore appelés canevas applicatifs, par opposition aux services de base, appelés canevas système. On peut citer les services suivants :
    • gestion de l’information avec par exemple la gestion des documents composites,
    • services d’administration avec notamment la gestion des composants répartis.

Les objets métier

  • Les objets métier (Business Objet) sont les briques applicatives que l’on va utiliser pour assembler des applications.
  • Les objets métier sont la partie « utile » d’un point de vue de l’utilisateur final : ces objets métier se servent des services présentés ci-dessous :
  • CORBA, objet métier

Positionnement vis à vis d'autres middllewares applicatifs

 

Services web COM+ CORBA RMI RPC
Description Middleware orienté message permettant l’échange d’informations entre entités logicielles de manière normalisée Middleware orienté objet permettant l’invocation de méthodes sur des objets distants fonctionnant sur des systèmes MS Windows Middleware orienté objet permettant l’invocation de méthodes sur des objets distants fonctionnant sur des systèmes hétérogènes Middleware orienté objet permettant l’invocation de méthodes sur des objets distants fonctionnant sur des machines virtuelles JAVA Middleware orienté application permettant l’invocation de procédures distantes
Mécanisme de découverte UDDI SCM (Service Control Manager), base de registre Naming Service Service RMI Registry ou JNDI Port mapper
Mécanisme de description WSDL API DCOM, TypeLib et MSIDL IDL Interface JAVA IDL
Mécanisme de formatage des communications SOAP ou REST Object RPC (extension de RPC DCE) GIOP Transport Layer de RMI RPC
Encodage XML Binaire DCOM (NDR) Binaire CORBA (CDR) Binaire RMI Binaire RPC (XDR)
Mécanisme de transport HTTP, HTTPS, SMTP Protocole de niveau Transport (niveau 4 OSI) IIOP sur TCP JRMP ou IIOP Socket
Quelques implantations disponibles .net, Apache Axis Plateformes MS Windows Jacord, Orbacus, PolyOrb, OmniOrb Serveurs J2EE du marché Beaucoup de produits en production depuis des années

 

Références

  • Le livre de J. DANIEL, Au Cœur de CORBA, aux éditions Vuibert, est une bonne source pour aborder en détail CORBA.
  • La liste des implantations existantes est donnée ici.
  • Une autre source d'outils CORBA ici.

VNC : prise en main de poste distant

Fiche ressource Article, événement, site web...
  • Création ou MAJ importante : 23/10/12
  • Correction mineure : 04/02/13
  • Auteur : Dirk Hoffmann (Centre de Physique des Particules de Marseille (CPPM-IN2P3))
Mots-clés

VNC : prise en main de poste distant

Introduction

VNC désigne à la fois un protocole de prise en main d'un poste (sous Windows, Linux, MacOS, etc.) et les logiciels qui l'implémentent. Cette fiche ressource se veut générique dans le sens où elle décrit le protocole VNC ainsi que les caractéristiques communes aux logiciels qui l'implémentent.
Cette fiche reprend délibérément le format d'une fiche logiciel, plus exhaustif (et contraignant) qu'une fiche ressource.

Un site générique pour VNC en tant que protocole n'existe pas. Le domaine historique vnc.com renvoie vers le site de la société RealVNC, issue d'une partie de l'équipe initiale des développeurs et détenteur de la marque déposée VNC™. Voir plus loin pour les sites des différentes implémentations, commerciales ou libres, du protocole VNC.

Fonctionnalités générales

Prendre la main (vue de l'écran et contrôle du clavier et de la souris) sur une machine distante, pour faire par exemple de l'administration ou de l'assistance utilisateur. VNC utilise le protocole RFB (remote frame buffer), qui peut s'appliquer à tous les systèmes affichage "en fenêtres" (dont Windows, le protocole X11 et Macintosh). De par sa conception extensible, il a permis aux différentes implémentations (depuis la fin des années 1990) de rester largement compatible entre elles.

Plate-formes et interopérabilité

Fonctionne sur toutes les plate-formes majeures (Windows, Linux, MacOS, etc.), sans problème d'interopérabilité. Cela signifie qu'un client à partir d'un système d'exploitation donné peut se connecter à un serveur tournant sur un autre système d'exploitation. Cependant, l'interopérabilité entre les différents logiciels VNC (saveurs) n'est pas toujours donnée, surtout quand le logiciel serveur et le logiciel client ont des dates de fabrication trop éloignée l'une de l'autre.

Contexte d'utilisation dans mon laboratoire/service

  • serveur VNC sur un serveur Windows pour l'administration à distance,
  • serveur VNC sur des postes clients pour faire de l'assistance à distance,
  • serveur VNC sous Linux, des clients VNC permettent aux utilisateurs d'accéder à cet environnement depuis des PCs Windows.

Limitations, difficultés, fonctionnalités importantes non couvertes

Le protocole est vulnérable à certains types d'attaques, quoique le mot de passe et la transmission des données soient cryptés. Des solutions à base de tunnels SSH ou de VPN sécurisés permettent de pallier cette faiblesse.

Distributions dans lesquelles ce logiciel est intégré

Quasiment toutes les distributions Linux intègrent un client/serveur VNC.

Logiciels implémentant le protocole VNC

  • RealVNC: http://www.realvnc.com/, existe en version gratuite "Free" (licence propriétaire), "Personal" et "Enterprise Edition". La version Free est distribuée pour Windows, Linux x86, Solaris 7, HP-UX 11, code source (Unix) et code source pour le Viewer en Java et pour Windows.
  • TightVNC: http://www.tightvnc.com/, entièrement gratuit (octobre 2011) en licence GPL. Dernière version (2.5) serveur + client disponible pour Windows. Une version précédente (1.3) également en saveur "Unix-like", ainsi que source et "binaire" en Java pour un Viewer en version 2.6.
  • TigerVNC: http://tigervnc.sourceforge.net/, est un fork de TightVNC fondé par un ancien co-développeur de TightVNC pour diverses raisons. Ce dérivé se veut " high performing, stable and generic". Est disponible gratuitement en licence GPL.
    Je n'ai pas pu le tester, mais il est distribué avec Fedora 13 par exemple.
  • UltraVNC: http://www.ultravnc.fr/, gratuit en licence GPL, donations possibles, pour Windows.
  • Vine Server/Client : http://www.testplant.com/support/downloads/vine/, précédemment distribué sous le nom OSXvnc, est un couple serveur/client VNC libre et open-source de TestPlant, Inc., vendu également avec un service support par la même entreprise.

Des fiches logiciels pour ces applications n'existent pas actuellement dans PLUME. Si vous êtes utilisateur régulier d'une de ces "saveurs" de VNC, contactez l'auteur de la fiche pour contribuer à la collection avec votre description du logiciel.

Autres logiciels aux fonctionnalités équivalentes

  • Symantec pcAnywhere (client et serveur payants).
  • Windows Terminal server (payant) et client RDP (intégré à Windows ou rdesktop, FLOSS pour Unix)
  • Nomachine NX, logiciel commercial, mais version gratuite "Free Edition" disponible qui est limitée à deux utilisateurs (comptes) déclarés simultanément sur la machine serveur. (Voir NX-Freenx pour une implémentation gratuite.)

Historique et Éléments de pérennité

Le protocole a été développé à l'origine dans les laboratoires de recherche joints des sociétés Olivetti et Oracle. Les laboratoires ont été vendus en 1999 à la société AT&T, qui ferma les activités de recherche en 2002. Suivant cette fermeture, plusieurs développeurs du projet ont fondé RealVNC, afin de pouvoir continuer à produire le code open source et commercial sous ce nouveau nom. Les sources ont été mises sous licence GPL et réutilisées (forked) par plusieurs autres équipes de développement.
Aujourd'hui, de (trop ?) nombreuses implémentations du client/serveur disponibles sur la majorité des plate-formes existent.
Protocole éprouvé et très répandu.

Références d'utilisateurs institutionnels

  • ATLAS control room management / sysadmins (CERN).
  • Accès à distance local (labo) et international (collaborations) au CPPM (CNRS).
  • Utilisation de VNC pour l'administration et l'intervention à distance sur les postes gérés par les ASR du LAAS (CNRS).

Augmentation de la sécurité du protocole

Le protocole VNC n'était pas un protocole sécurisé à la base, et malgré des progrès récents, surtout dans des versions commerciales de l'implémentation, il convient de donner quelques conseils pour augmenter la sécurité.

Serveur VNC sous Windows

  • Via la base de registre côté serveur, il est possible de n'autoriser que certaines adresses ou plages d'adresses IP à se connecter à un serveur VNC en paramétrant une valeur "AuthHosts" ou "Hosts" selon l'implémentation de VNC utilisée ("AuthHosts" VNC et UltraVNC , "Hosts" pour RealVNC).

  • Le paramétrage d’AuthHosts est une clé de type REG_SZ employée pour indiquer un ensemble de masques d’adresses IP que les connexions entrantes doivent respecter afin d’être acceptées. Par défaut, le masque est vide et les connexions de tous les centres serveurs sont acceptées. Le masque est de la forme :
    +[masque d’IP]
    ?[masque d’IP]
    -[masque d’IP]

Explications :

Le [masque d’IP] représente l'adresse IP ou le masque de sous-réseau qui doit être pris en compte. Il peut être de la forme 192.168.1.10 (et désignera alors une adresse IP précise), ou 192.168 (et désigner l'ensemble du sous-réseau 192.168.x.x et toutes les adresses IP en faisant partie).

    • le symbole "+" indique que le [masque d’IP] correspondant est autorisé.
    • le symbole "-" indique que le [masque d’IP] correspondant est interdit.
    • le symbole "?" indique que le [masque d’IP] correspondant doit être accepté côté serveur par l'intermédiaire d'une fenêtre de dialogue.
    • le symbole ":" (VNC) ou "," (RealVNC) sert de délimiteur, permettant ainsi de définir plusieurs valeurs.

On aura donc par exemple comme valeur de clé :
HKEY_LOCAL_MACHINE\Software\RealVNC\WinVNC4
"AdminPassword"=hex:dc,c6,6b,58,6d,e4,19,7c
"Hosts"="+192.168.82.0/255.255.254.0,?192.168.0.0/255.255.0.0,-255.255.255.255/0.0.0.0"

Serveur VNC sous Linux ou Windows avec SSH

Il est possible de rediriger les ports utilisés par VNC vers la machine locale à travers un tunnel SSH afin d'en sécuriser la connexion : ainsi les mots de passe VNC ne transitent pas en clair sur le réseau.

ssh $SSH_SERVER -L$LOCALPORT:$VNC_SERVER:$VNCPORT

Le cadriciel cygwin peut fournir un serveur SSH pour une machine équipée de Windows.

Conférence FOSSA - Lille - 4 -6 déc 2012

La quatrième conférence FOSSa (Free Open Source Academia Conference), FOSSA2012, se tiendra à Lille du 4 au 6 décembre 2012.

Consultez le site de la conférence pour avoir le programme (Tracks).

L'inscription est gratuite.

Extrait du site Web :

This year, the conference will address:

  • Education (Resp. Ivaylo Ganchez)
  • IRILL (Resp. Roberto Di Cosmo)
  • History of the Free Software/Open Source mouvement (Resp. Christophe Masutti & Alexis Kaufmann)
  • Movie: 'Revolution OS? (wonderful movie! open to a large public)
  • Digital Native Generation (Resp. Stephane Frenot & Stephane Grumbach)
  • Openness: Open Arts and Open Hardware (Resp. Jérome Copin)
  • Licences: No lawers, No councels, only return on experience (Resp. Gabriele Ruffatti)
  • Communities: Community management has never been so easy (Resp. Stephane Ribas)
  • Workshops: Many code developement training sessions are scheduled as for example Gnome, Mozilla, LibreOffice, Pharo, SpagoBI, etc.

Each topic will end up with a debate (What are the issues that faces OSS today, What about data concentration made in the US & China, What are the good practices in Licencing...)

RMLL2012 : Rencontres Mondiales du Logiciel Libre juillet 2012

Fiche ressource Article, événement, site web...
  • Création ou MAJ importante : 03/07/12
  • Correction mineure : 03/07/12

RMLL2012 : Rencontres Mondiales du Logiciel Libre juillet 2012

La prochaine édition des Rencontres Mondiales du Logiciel Libre aura lieu du 7 au 12 juillet 2012 et se déroulera à Genève (Suisse). La participation est gratuite et libre d'accès pour toutes et tous.

Intitulée «Biens Communs ? - Culture, société et logiciel libre», cette édition se donne pour thèmes majeurs : Science et formation, Santé et Technique.

PLUME tient un stand lors de cet événement afin de formaliser le soutien officiel du CNRS à ces Rencontres Mondiales du Logiciel Libre.

L'initiative Blue Obelisk : promouvoir le développement et l'utilisation des données, standards et logiciels ouverts en chimie

Fiche ressource Article, événement, site web...
  • Création ou MAJ importante : 02/01/12
  • Correction mineure : 02/01/12
Mots-clés

L'initiative Blue Obelisk : promouvoir le développement et l'utilisation des données, standards et logiciels ouverts en chimie

L'initiative Blue Obelisk a été lancée en 2005 afin de promouvoir le développement et l'utilisation des données, standards et logiciels ouverts (ODOSOS) en chimie.

Depuis 6 ans, cette initiative a permis à de nombreux développeurs de se rencontrer et de collaborer autour de projets (logiciels, ressources) ouverts, dont voici quelques exemples :

  • Avogadro
  • Bioclipse
  • Chemistry Development Kit
  • JChemPaint
  • JOELib
  • Kalzium
  • Openbabel
  • OpenSMILES
  • UsefulChem

Chaque année, le projet décerne un prix pour récompenser les initiatives marquantes dans la promotion des données, standards et logiciels ouverts.

Un article scientifique a été publié en octobre 2011. Il détaille l'activité et les réalisations de Blue Obelisk au cours des cinq dernières années.

XML (eXtensible Markup Language) : langage de balisage extensible

Fiche ressource Article, événement, site web...
  • Création ou MAJ importante : 28/11/11
  • Correction mineure : 12/06/13
Mots-clés

XML (eXtensible Markup Language) : langage de balisage extensible

Cette fiche ressource à été relue par Maud Ingarao (ENS Lyon, CNRS) et par Florence Petit (IGM).

Introduction

XML est un langage informatique de balisage (enrichissement d'information textuelle).

A noter que le contenu de cette fiche PLUME ne constitue qu'un aperçu global d'XML et des standards associés, et non une formation exhaustive sur ces différents sujets.

Origine

Issu d'une simplification de la norme SGML (Standard Generalized Markup Language), XML (eXtensible Markup Language) est le fruit de travaux communs du World Wide Web Consortium (W3C) et de plusieurs industriels, entre 1996 et 1998.

Vue d'ensemble

Les principes de base d'XML sont donc ceux du SGML :

  • Séparation de la présentation et des données
  • Structuration des données
  • Capacité à valider la structure des données

Ces principes simples et souples donnent à XML la capacité à rendre le partage d'information ouvert, ce qui favorise les échanges informatisés basés sur des formats portables ainsi que l’interopérabilité des applications.

Schéma

Cela peut s'illustrer ainsi :
XML, principes

Structuration et organisation du contenu XML

Principe

XML est un langage de balisage générique qui permet de définir des documents contenant à la fois les données et des indications sur la structure de ces données. Ces balises ne sont pas prédéfinies, d'où la nature extensible du langage. Il convient de respecter des règles de construction syntaxique d'XML : on parle alors d'un document bien formé

Exemple

Un exemple de document XML est le suivant :

<?xml version="1.0" encoding="ISO-8859-1"?>
<?xml-stylesheet type="application/xml" href="personnes.xsl"?>
<personnes>
<personne naissance="1802" mort="1870">
   <nom>
    <prenom>Alexandre</prenom>
    <nom_famille>Dumas</nom_famille>
  </nom>
  <!-- l'abbé Faria a existé -->
  <profession>Ecrivain</profession>
  <informations xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://www.dumaspere.com"/>
</personne>
<personne naissance="1840" mort="1902">
  <nom>
   <prenom>Emile</prenom>
   <nom_famille>Zola</nom_famille>
  </nom>
  <profession>Ecrivain</profession>
</personne>
</personnes>

Ce document XML correspond à l'arbre ci dessous :
XML, exemple de document, vue hierarchique

Validation du contenu XML

Principe

Un document XML contient des données, organisées selon les règles de construction d'XML : c'est la notion de document bien formé déjà mentionnée.

Une grammaire donnée permet de définir des contraintes supplémentaires sur la structure d'un document XML. La définition d'une grammaire donnée se fait via des DTD ou via des schémas XML (extension : .xsd). Les schémas sont à ce jour les plus utilisés, car par rapport aux DTD, ils présentent en effet l'avantage d'être eux-même des documents XML. La syntaxe simplifiée Relax NG est également très utilisée.

Un document valide est un document qui respecte la grammaire définie dans une DTD ou un schéma XML.

Exemple

Soit le document XML suivant :

<?xml version="1.0" encoding="ISO-8859-1"?>
<personnes xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="personnes.xsd">
  <personne>Alexandre Dumas</personne>
  <personne>Emile Zola</personne>
</personnes>

Le contenu de ce document XML peut être validé via le schéma XML suivant :

<?xml version="1.0" encoding="ISO-8859-1"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <!-- Definitions types de donnees -->
  <xsd:simpleType name="personneType">
   <xsd:restriction base="xsd:string"/>
  </xsd:simpleType>
  <xsd:complexType name="personnesType">
   <xsd:sequence>
    <xsd:element name="personne" type="personneType" minOccurs="0" maxOccurs="unbounded"/>
   </xsd:sequence>
  </xsd:complexType>
  <xsd:element name="personnes" type="personnesType"/>
</xsd:schema>

Sur la différence entre document bien formé et document valide, voir par exemple ce récapitulatif sur le site W3schools.

Transformations de contenu XML

Principe

Comme expliqué ci-avant, un document XML contient les données et leur sémantique et ce contenu peut être validé par rapport à une grammaire donnée via des schémas XML (ou une DTD). Pour la présentation et/ou la transformation de contenu en XML, il est possible de passer par :

  • des CSS (Cascading StyleSheets),
  • des feuilles XSL (eXtensible Stylesheet Language), avec principalement XSLT (XSL Transformations) et XSL-FO (XSL-Formatting Objects).

Par ailleurs, le langage de requête XPath est souvent utilisé dans ce contexte de transformations de données car il permet de sélectionner des fragments de contenu XML.

Exemple

On considère le document XML ci-dessous :

<?xml version="1.0"?>
<salutation>
  Bonjour le monde !
</salutation>

La transformation de ce document en une page HTML peut se faire via le code XSLT suivant :

<?xml version="1.0"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method="html"/>
<xsl:template match="/">
  <xsl:apply-templates select="salutation"/>
</xsl:template>
<xsl:template match="salutation">
  <html>
   <body>
    <h1>
     <xsl:value-of select="."/>
    </h1>
   </body>
  </html>
</xsl:template>
</xsl:stylesheet>

Le résultat de la transformation donne :

<html>
<body>
  <h1>Bonjour le monde !</h1>
</body>
</html>

Liaisons de contenu en XML

Principe

Étant donné la structure logique en arbre d’XML, la description de relations autres que parent-enfant(s) entre nœuds n’est pas naturelle. La réponse à cette problématique de liaisons de contenu XML passe par :

  • XLink, qui permet de décrire des graphes dans lesquels les sommets sont des documents (situés à des URI particuliers) et les arêtes sont les liens entre ces documents,
  • XPointer, langage dédié à l’identification de fragments de documents XML, souvent utilisé en liaison avec XLink.

Exemple

Soient trois fichiers zola1.txt, zola2.txt et zola3.txt pour lesquels un lien multidirectionnel de type arc doit être construit, pour avoir :
zola1.txt <--> zola2.txt <--> zola3.txt

Via XLink, cela peut s'exprimer de la sorte :

<series xlink:type="extended" xmlns:xlink="http://www.w3.org/1999/xlink">
<auteur>E. Zola</auteur>
  <roman xlink:type="locator" xlink:label="ez1" xlink:href="ftp://archive.org/zola1.txt">
   <titre>La curée</titre>
  </roman>
  <roman xlink:type="locator" xlink:label="ez2" xlink:href="ftp://archive.org/zola2.txt">
   <titre>La fortune des Rougon</titre>
  </roman>
  <roman xlink:type="locator" xlink:label="ez3" xlink:href="ftp://archive.org/zola3.txt">
   <titre>L'assommoir</titre>
  </roman>
  <!-- arcs -->
  <suivant xlink:type="arc" xlink:from="ez1" xlink:to="ez2"/>
  <suivant xlink:type="arc" xlink:from="ez2" xlink:to="ez3"/>
  <precedent xlink:type="arc" xlink:from="ez2" xlink:to="ez1"/>
  <precedent xlink:type="arc" xlink:from="ez3" xlink:to="ez2"/>
</series>

Manipulations de contenu XML

Principe

La manière de manipuler des documents XML depuis des programmes (lecture, écriture, modification) s’implémente principalement de deux façons différentes :

  • SAX (Simple API for XML), API qui aborde la notion de parsing de manière événementielle,
  • DOM (Document Object Model), API qui traite un document XML avec une approche arborescente.

Exemple

Soit l’extrait de document XML suivant :

<nom>
<prenom>David</prenom>
<nom_famille>Rousse</nom_famille>
</nom>

Un parseur SAX reportera typiquement les événements suivants (dans l’ordre indiqué)

startElement : nom
startElement : prenom
content : David
endElement : prenom
startElement : nom_famille
content : Rousse
endElement : nom_famille
endElement : nom

Un parseur DOM va, lui, représenter la totalité du document XML en mémoire sous la forme d'un arbre, en respectant la recommandation Document Object Model du W3C.

A noter : le parsage DOM est un exemple de "XML data binding", qui signifie le fait de représenter les éléments d'un document XML en tant qu'objets en mémoire. Cf. l'article [en] XML data binding sur Wikipedia.

Conclusion

En guise de conclusion, les différents éléments précités autour de XML s'illustrent de la sorte :
XML, champs d'applications

Références

Le support de cours suivant traite de manière plus approfondie d'XML et des normes et standards liés.

Mots-clés

Ecole informatique IDL 2011

Les inscriptions à l'école informatique IDL 2011 (Ingénierie du Développement Logiciel) sont maintenant ouvertes. Cette école est organisée par le réseau PEPI IDL de l'INRA qui est chargé d'animer les développeurs de l'institut.

Elle se tiendra du 5 au 9 décembre 2011 à La Londes Les Maures (83) et traitera de l'ensemble des aspects liés au développement logiciel, avec deux thèmes plus particulièrement abordés : UML et l'approche agile.

Le public visé est donc les acteurs du développement logiciel à l'INRA, mais quelques places seront ouvertes à l'extérieur.

Pré-programme : http://idl.pepi.inra.fr/attachments/article/12/Pr%...

Pour plus d'informations vous pouvez consulter le site du PEPI IDL ainsi que contacter le bureau du PEPI : pepi-idl-bureau [at] listes [dot] inra [dot] fr

RMLL 2011 - Strasbourg - 9 au 14 juillet

Les RMLL (Rencontres Mondiales du Logiciel Libre) se tiendront à Strasbourg du 9 au 14 juillet 2011 :

Syndiquer le contenu