D’ailleurs, dans le billet indiqué, on trouve : « There are only resources and representations, and it’s the representations of those resources you need to be specific about.  »

Y a-t-il quelque chose que je n’ai pas compris ?

De toutes façons merci pour votre très intéressante revue de presse, continuez, malgré mes critiques que j’espère constructives.

Au passage, ne vous arrive-t-il donc jamais d’utiliser un serveur d’applications full java (qui bien sûr n’est pas une ressource critique…) ?

De fait, l’approche serveur LDAP en Java me semble plus intéressante qu’un serveur C++ relativement équivalent en C ou C++.

Merci pour ces précisions apportant une clarification sur la question du positionnement d’OpenDS. L’opposition à ApacheDS est difficilement évitable mais il est vrai qu’une perspective d’intégration de la technologie OpenDS au sein du prochain Sun Directory Server donne une dimension différente au projet open source de Sun.

Notre formulation « on préfèrera généralement une implémentation native plus mature » mérite quelques précisions :

- Il existe plusieurs serveurs d’annuaire très matures développés en C ou C++, sous licence commerciale ou Open Source, face auxquels on trouve maintenant deux challengers implémentés en Java que sont OpenDS et ApacheDS. Lors du choix d’une technologie destinée au support d’une ressource critique, il est naturel de se tourner vers une solutions mature qui apportera une plus large communauté et des compétences plus courantes. Dans un tel contexte, une solution plus récente devra a priori proposer des apports significatifs de fonctionnalités ou de performances pour devenir compétitive.

- Nous ne souhaitions pas mettre en doute les performances des implémentations qui se basent sur Java. Le garbage collector a longtemps été une source d’inquiétude pour ce type d’applications, mais les récentes améliorations en la matière et plus particulièrement le très prometteur G1 tendent à minimiser cette problématique.

Enfin, notre imprécision sur la réplication multi-master offerte par OpenDS a été corrigée.

Cordialement,
Michael Figuière (Xebia)

Je vous remercie pour avoir diffuser l’information concernant la sortie d’OpenDS 2.0.
Par contre je tiens a preciser quelques details:

- OpenDS n’est pas positionné directement face a Apache Directory Server et n’est pas destiné au poste de developpement. Certes on peut considerer qu’OpenDS n’est pas aussi mature qu’OpenLDAP ou Sun Directory Server, mais il est conçu et réalisé par l’équipe de développement de Sun Directory Server, bénéficiant de plus de 10 ans d’experience dans le domaine. L’objectif du projet OpenDS est de fournir une nouvelle génération de services LDAP plus performants, plus complets et plus faciles a utiliser. Et le produit Sun Directory Server Enterprise Edition 8 s’appuyera sur la technologie OpenDS.

- La notion d’implementation native est ambigue et incorrecte. Elle sousentend que une implementation en Java ne peut avoir les performances ou caracteristiques d’un serveur ecrit en C ou C++. Il suffit de suivre un peu le projet OpenDS pour se rendre compte que le serveur n’est pas un jouet de developpeurs. Les tests de base se font avec des bases de données de 10 millions d’utilisateurs. Les temps de réponse sont de l’ordre de UNE milliseconde. Et certains benchmarks ont produit des résultats difficiles a obtenir avec des serveurs natifs et mature : http://blogs.sun.com/ds/entry/opends_nehalem_benchmark_sunblade_6270

- OpenDS ne vient pas s’aligner avec Apache Directory Server concernant la replication multi-maitre. La replication multi-maitres est present dans OpenDS depuis la version 1.0, sortie il y a un an. Les ameliorations presentes dans la version 2.0 incluent le support jusqu’a 8 servers maitres, un mode de Replcation Assurée qui garantit la disponibilité et la fiabilité des données.

Pour conclure, je dirais qu’avec la version 2.0, OpenDS arrive dans sa phase de maturité et se pose en concurrent sérieux de tous les serveurs d’annuaire LDAP d’entreprises.

Cordialement,
Ludovic Poitou
http://blogs.sun.com/Ludo

Comme toujours votre revue de presse est très intéressante : sujets variés, résumés concis et pertinents. Merci.

Je reviens sur le sujet « REST et les abus de langage » : je vous rejoins totalement car je mène depuis longtemps un combat acharné contre les préjugés et incompréhensions concernant REST

REST n’est pas si facile que cela à appréhender. En complément de votre post, j’invite donc les intéressés à consulter :
– mon blog pro, sur lequel je viens d’entamer une démarche de clarification des concepts REST en une dizaine de points : http://www.aeon-consulting.fr/fr/blog/ (Aeon Consulting)
– mon blog perso, sur lequel j’ai déjà posté plusieurs articles dans le même esprit que le vôtre : http://francois.goldgewicht.com

Je pense en effet qu’échanger est essentiel dans cet objectif de clarification.

François Goldgewicht