OpenSSO : support de cours disponible
J’avoue, sur ce coup-là Sun me surprend. Je viens de découvrir en effet qu’ils commencent à mettre à disposition leurs matériels de training concernant OpenSSO. Actuellement, seul le cours sur le déploiement est disponible, mais c’est déjà une très bonne chose !
Au programme :
- Déploiement multi instances
- Failover des sessions
- Installation d’un agent Web
- Installation d’un agent J2EE
Un document de 128 pages ! Cela se passe ici.
Une nouvelle valve Tomcat et un plugin Dokuwiki pour LemonLDAP::NG
Début juillet ont été publiées deux contributions pour le produit de WebSSO LemonLDAP::NG : une nouvelle version de la valve Tomcat (par Pascal Pejac) et un plugin Dokuwiki (par Erwan Legall).
Le plugin Dokuwiki permet de configurer un nouveau mode d'authentification, nommé "lemonldap". Il ne fonctionne qui si l'agent (Handler) est sur le même serveur Apache que Dokuwiki (pas de reverse proxy, utilisation de la variable système REMOTE_USER). Une fois en place, l'authentification à votre wiki sera gérée par LemonLDAP::NG.
La valve Tomcat s'adresse à toutes les applications J2EE utilisant le conteneur de servlets pour leur gestion d'authentification et d'autorisation (identifiant et rôles des utilisateurs). Ainsi, vous pouvez gérer l'ensemble de vos rôles dans un annuaire LDAP central, et ces rôles seront fournis aux applications par LemonLDAP::NG. Vos applications n'ont pas à être modifiées, car c'est la valve qui sera chargée de communiquer avec le WebSSO. Cela garantit donc une intégration sans modification de code.
Liens :
- Plugin Dokuwiki : Fichier | Documentation
- Valve Tomcat : Fichier | Documentation
Principe 8 : La règle du 80/20
La loi de Pareto est plus communément connue sous la règle du 80/20. Cette distribution des probabilités suit une loi des puissances. L’idée qui est régie par cette loi est que la majorité de vos résultats peuvent être réalisés avec un minimum d’effort.
Cette loi est un outil fondamental en gestion de la qualité. Elle est aussi utilisée en réassurance. Cette loi dit que « généralement » 80 % de résultat peuvent provenir de seulement 20% d’efforts !
Par exemple : En fiscalité : 20% des citoyens imposables génèrent 80% de la trésorerie publique, En sport: 20 % de l'effort à l'entraînement permet d'atteindre 80% de la performance, en service après-vente: 80% des réclamations proviennent de 20% des clients.
Cette loi est bien connue des managers :
En préparant leurs ambitions, les managers expérimentés savent que seuls quelques éléments majeurs sont décisifs. Le reste sera traité par la même occasion en tant que parties de ces éléments
— Juran, 1964
Ainsi, un bon directeur de produits est une personne qui peut voir (à l'avance sans l’avantage du travail déjà accompli) les 20% sur lesquelles se concentrer. En développement Agile, nous devons essayer d'appliquer la règle des 80/20, qui cherche à se concentrer sur l'importance des 20% qui engendre la majorité des résultats.
Si la qualité de votre application n’est pas la première exigence, si vous avez le contrôle sur son périmètre et si la mise à disposition de votre application est votre première priorité, pourquoi ne pas fournir 80 % de votre produit en seulement 20% du temps. En fait, dans ce scénario particulier, vous pourriez vous demander pourquoi faire les derniers 20% restant.
Maintenant, cela ne signifie pas que votre produit doit être fondamentalement bugé, laisser une mauvaise expérience à l'utilisateur, etc. Cela signifie simplement que le développement de certaines fonctionnalités, ou la richesse de certaines caractéristiques, va plus loin et a une diminution de rendement pourrait ne servir à rien.
Cette affirmation n'est elle pas en conflit avec le précédent billet: "terminer" signifie "TERMINER!". Pas réellement, parce qu’à l'intérieur de chaque itération ou Sprint, ce que vous décidez ou ne décidez pas de « de développer » peut ne pas être réalisé à 100%.
Pour exemple, sur la règle des 80/20, Microsoft lui-même a montré que l'utilisateur moyen de Word utilise seulement 8% des fonctionnalités. 8% Et nous pouvons penser que moins de 80% d'entre eux n’utilisent même pas 8%. Si Microsoft n’avait développé que les 8% importante de Word, pourraient ils encore avoir pris la même part de marché? Peut-être, peut-être pas, malheureusement nous ne le saurons jamais.
Il est également utile d'examiner l'impact sur l'expérience de l'utilisateur. Google nous a montré que les utilisateurs préfèrent souvent des applications qui font au plus près du besoin. Seulement ce que vous voulez. Et pas plus. Le reste est sans doute encombrant et en fait, interfère avec l'expérience de l'utilisateur et apporte seulement un intérêt réduit pour un nombre limité d'utilisateurs.
Nous pouvons donc inverser le 80/20, pour dire que seulement 20% des fonctions d’une application seront nécessaires à 80% des utilisateurs. Dans un développement agile, lorsque vous développez un nouveau produit, concentrez-vous sur ce que votre logiciel doit faire avant tous. Pourriez-vous prendre le marché avec toutes les caractéristiques importantes, ou seulement avec des fonctions qui sont moins riches fonctionnellement, en seulement peu de temps ?
En dehors de la réduction des coûts, réduction des risques et des prestations plus élevées en étant plus rapide sur le marché, vous pouvez également vous appuyer sur la première version du produit basé sur le retour du client réel.
Donc, tout cela est réellement du bon sens (cf. MMM notre DGA).
A la finalité, ce n'est pas aussi simple, car il faut être un très bon visionnaire pour découvrir les 20% qui fourniront 80% des résultats. Par expérience et dans de très nombreux cas, les responsables n'ont pas cette vision.
Principe 7 - Terminer une fonction avant de commencer une autre
En développement agile, "terminer" doit réellement signifier "TERMINER!".
Une caractéristique développée dans une itération (Sprint dans Scrum) doit être terminée à 100% à la fin du Sprint.
Trop souvent dans le développement de logiciels, "terminé" ne signifie pas vraiment "TERMINE !". Cela signifie non tester. Cela ne signifie pas forcément que l’aspect graphique est terminé. La plupart du temps, il n'a pas encore été validé par le directeur de produit et encore moins par le client. Cela signifie simplement développer.
Dans une situation idéale, chaque itération ou Sprint devrait conduire à une version du produit. Certes c'est le cas pour la BAU (business as usual) les changements apportés aux produits existants. Dans les projets ou il n'est pas possible de faire une release après chaque Sprint, réaliser chaque caractéristique à la suite, permet d’obtenir une vue très précise des progrès et dans quelle mesure elles correspondent à la cible du projet ou au contraire s’en éloigne.
En développement agile, il faut s’assurer que chaque caractéristique est pleinement développée, testée, l’aspect graphique stabilisé, et accepté par le directeur de produit et le client avant de la considérer comme "TERMINÉE !". S'il y a le moindre doute sur ce qui devrait ou ne devait pas être achevé dans le Sprint pour chaque fonction, "TERMINER!" devrait signifier être livrées.
Une caractéristique peut nécessiter d'autres caractéristiques en voie d'achèvement avant que le produit puisse être réellement expédié. Mais une caractéristique propre peut mériter d’être livrée. Donc, si vous êtes n’est pas sur qu’une caractéristique ce "suffit", posez-vous une simple question: "Est-ce que cette fonctionnalité est prête à être livrée ? ".
Il est également important de bien compléter chaque caractéristique avant de passer à la prochaine ...
Bien sûr, plusieurs caractéristiques peuvent être développées en parallèle dans une équipe. Le travail de chaque développeur est de ne pas passer à une nouvelle fonction jusqu'à ce que la dernière soit livrée. Ceci est important pour s’assurer que l'ensemble des produits est dans un état "prêt à être livré" à la fin du Sprint, et non dans un état où plusieurs caractéristiques sont à 90% ou non testé. Ce qui est une habitude dans les projets de développement traditionnels.
En développement agile, "terminer" signifie "TERMINER!".
Présentation (rapide) de SPML
Et oui, encore un sigle (barbare ?) en *ML. Pour commencer, sa définition : Simple Provisioning Markup Language, plus concrètement il s’agit d’un standard OASIS basé sur XML décrivant des opérations d’approvisionnement (provisionning) comme son nom l’indique. En pratique, il est surtout très utilisé pour la gestion des identités, entre différents produits plus ou moins pas ouvert. Même si ce standard n’est (malheureusement) pas trop utilisé, ou du moins ses utilisations restent discrètes, il reste un des rares (seul à ma connaissance) standards pouvant traduire le cycle de vie d’une identité (création, modification, suppression, et également recherche), et avec une grande souplesse. Pour commencer, attardons nous sur les différentes opérations décrites par le schéma SPML :
- addRequest (création d’une entité)
- lookupRequest (recherche d’une entité à partir de son identifiant unique)
- modifyRequest (modification d’une entité)
- deleteRequest (suppression d’une entité)
- searchRequest (recherche d’une entité à partir d’un attribut)
Remarquer que je parle bien d’entité, en effet, SPML ne décris pas de manière forte le contenu des opérations, on peut donc l’utiliser par exemple pour des identités, mais tout autre chose.
L’ensemble des opérations peuvent être appelées aussi bien dans un mode synchrone qu’en mode asynchrone (chaque requête doit être alors identifiée de manière unique par le client). Bref, assez de blablah, voici un exemple très simple (le plus simple en fait) de requête SPML :
<lookupRequest requestID='125'>
<psoID ID='asyd' />
</lookupRequest>
Je crois que cela se passe de commentaire, je fais une recherche en utilisant l’identifiant unique (ici de mon compte asyd, sur un Sun Identity Manager). Si IDM est bien configuré pour accepter les requêtes SPML (je ferais un petit post dans un avenir proche à ce sujet), le retour aura la forme suivante :
pour des raisons de lisibilité (merci wordpress) la réponse se trouve en pièce jointe
Comme on le voit, les attributs réels de l’utilisateur sont fournis en contenu du tag data, et les connaisseurs aurons reconnus l’utilisation de l’espace de nommage DSML, qui - pour faire court - est une représentation XML d’une entrée LDAP. Bref, pour ceux qui n’auraient pas suivis (en même temps ce n’est pas évident), le schéma SPML ne s’occupe pas de la représentation de l’attribut SPML data, comme le montre le schéma core.
En fait, seul l’attribut psoID (où PSO signifie Provisioning Service Objects) est défini par le schéma SPML, le reste n’étant lié qu’à la définition des opérations. Il permet de déterminer de manière unique une entité (dans notre cas une identité, donc l’accountId au niveau d’IDM).
Pour résumer : SPML est un standard OASIS (sous forme d’un schéma XML) d’approvisionnement, surtout utilisé pour la gestion d’identité, afin de faire communiquer entre elle différentes couches logiciels (brique métier de gestion d’identité, une PKI, etc.). Tout ceci en décrivant des opérations, mais en laissant à chacun le soin de représenter ses données. Cela à l’avantage d’être très souple, mais il reste donc la problématique du contenu (charge utile) à traiter, sauf si on l’utilise un autre standard, comme le DSML, dans le cas d’une gestion d’identité.
Voilà, à plus tard pour des nouvelles aventures dans le monde merveilleux (ou pas) de SPML.
