OSGI est une organisation indépendante. Fondée en 1999, on lui attribua la JSR 8 pour la définition d’un système à composants dynamiques pour la plateforme Java : OSGI pour Open Services Gateway Initiative.

Son but principal est de proposer un modèle pour la modularité de composants ainsi qu’un modèle de collaboration inter-composant. Et les avantages que l’on peut en tirer aujourd’hui ne manque pas :

Une meilleure cohabitation

OSGI propose de partager la machine virtuelle Java aux applications dans un une architecture modulaire, en isolant en toute sécurité les applications les unes des elles. En introduisant le bundle comme l’unité de déploiement, OSGI y impose la déclaration explicite des dépendances.

Une collaboration à base de service

OSGI préconise dès 2000 un modèle collaboratif dynamique à base de service. Cette architecture permet un couplage faible entre bundles et un suivi de service à l’exécution grâce aux notifications d’évènements d’apparition ou de disparition de service. C’est un modèle SOA intra JVM.

Du dynamisme dans Java

Dans une optique de qualité de service, la plateforme Java se doit d’être disponible et donc éviter les redémarrages. OSGI spécifie un modèle dynamique. Les bundles ont un cycle de vie indépendant de celui de la plateforme Java. Il est alors possible de les installer, désinstaller, mettre à jour, arrêter, démarrer sans redémarrer la plateforme Java. Il en est de même pour la gestion des configurations et de la sécurité entre autres que l’on peut modifier dynamiquement.

Quelques exemples d’utilisation

Eclipse est un très bel exemple du potentiel qu’offre la spécification OSGI. En effet, Eclipse 2 proposait un modèle de composant propriétaire et il a été décidé en 2003 de basculer sur le modèle OSGI pour Eclipse 3.0. Aujourd’hui, Eclipse compte des milliers de bundles disponibles pour étendre ces fonctionnalités. Et il est très simple de construire une application modulaire grâce à Eclipse PDE.

On peut trouver d’autres exemples dans l’industrie automobile avec BMW et son déploiement de d’application avec la plateforme Prosyst (OSGI R4), dans l’industrie internet avec CISCO et ses routeurs administrable à distance grâce à OSGI, mais aussi avec le projet M@jordom d’EDF pour offrir au consommateur un ensemble de services accessibles par divers sources (Mobile, ordinateur, compteur…).

L’industrie logicielle n’est pas en reste : BEA offre un serveur léger Event-Driven le WebLogic Event Server, IBM à basculer sa plateforme Notes sous OSGI (en se basant sur Eclipse), le serveur GlassFish 3 de Sun, le serveur Jonas 5.0 également…

D’autres projets sont à l’étude et permettent à OSGI d’étendre son rayonnement. On peut citer Spring et son serveur d’application Springsource Application Platform.

Les implémentations OSGI. On dénombre aujourd’hui quatre acteurs majeurs pour les plateformes OSGI R4 open-source :

• Eclipse Equinox
• Apache Felix
• MAKEWAVE Knopflerfish
• Prosyst mBedded Server Editions (Basé sur Eclipse Equinox)

Conclusion

OSGI apporte de l’organisation à l’exécution à la plateforme Java. C’est un transfert de responsabilité du développeur au Framework OSGI. Le développeur est ainsi libérer de certaines tâches non essentielles et peut se consacrer pleinement au cœur de son métier : répondre aux exigences de son client. Il n’est plus dans une intention constante d’écriture de ligne de code, mais de composition et de réutilisation. Cette architecture de haut niveau a pour avantage d’apporter de la discipline et de la lisibilité dans les développements des applications d’entreprise.

Fort de sa présence à SpringOne 2008, SQLI vous a proposé des billets avec les commentaires "à chaud" de ses fidèles représentants. La SpringSource Application Platform, OSGi et les projets du portfolio Spring (Spring Batch, Spring Integration...) recèlent encore peut-être quelques secrets pour vous, mais vous avez pu vous mettre au goût du jour à propos de l'actualité de Spring !

Notre travail ne s'est pas arrêté là et nous vous proposons aujourd'hui une restitution détaillant les sessions auxquelles a assisté Arnaud Cogoluègnes. Cette restitution est un compte-rendu détaillé de 9 sessions ainsi que des 2 keynotes de SpringOne, avec les références de chacun des intervenants.
SpringOne 2008 avait une actualité chargée : 3 sessions se déroulaient en parallèle dans 3 salles différentes, il fallait donc faire un choix ! Les sessions concernent donc principalement la partie middleware de Spring (Spring Core, Spring Integration...) et la SpringSource Application Platform. Toutes nos excuses aux représentants de la partie Web de Spring (Spring MVC et consorts), de l'AOP et de l'Application Management Suite !

Vous pouvez télécharger cette restitution ou la consulter en ligne, bonne lecture !


Un grand merci à Arnaud Cogoluègnes de SQLI Lyon pour cette contribution.

Pour ma part, la première image qui me vient à l’esprit s’apparente au fait de sortir d’un bon repas un peu trop gourmand. Rassasié de l’enchainement de conférences riches, et très variés, la rédaction de cet article nous fait l’effet d’un bon Rennie. Sous forme de récit, Moez nous racontera ces deux jours et ses ressenties. Pour ne pas être redondant, je vous présenterais seulement mes opinions. J'espère que vous êtes bien accroché à vos sièges car l'aventure ne fait que commencer...

Récit de ces deux jours, par Moez

En arrivant dans les lieux, premier constat : SpringSource a su mettre les petits plats dans les grands et réserver un multiplexe où les animateurs présentent dans des salles dignes de l'avant première de Star Wars. Les héros de la saga SpringSource étaient tous là.... Une logistique est organisée à la sauce Parley, avec une caméra braquée sur les intervenants et les slides qui défilent à un bon rythme.

Pour ma première participation à une grande conférence informatique, la bonne ambiance, l’excellent accueil et la magnifique organisation des équipes SpringSource m’ont rapidement plongé dans le bain. En effet, pas le temps de remettre les pieds sur terre, première présentation par Rod Johnson. Durant les 5 premières minutes j’avoue que j’ai eu du mal à me concentrer, bluffé par la présence de ce monsieur. Deux heures durant, il nous a dressé un positionnement clair, simple et rapide des produits Spring et a annoncé les grandes nouveautés.

J’allais enchainer par une présentation sur des cas d’utilisation de Spring. Erreur d’organisation et mauvais titre à la présentation, il s’agissait de Spring batch . Rien de grave, je n’ai pas regretté le fait d’avoir assisté à cette séance car j’ai découvert un super produit. Spring Batch est un framework mis en place pour résoudre les problématiques de batch. Une conception très simple qui se base sur les pratiques actuelles .Je pense que cette solution révolutionnera le monde des batchs comme l’a fait Spring Core dans le monde J2EE.

Beaucoup de suspense, beaucoup d’attente mais cela valait le coup. S2AP le nouveau serveur d’application de Spring est un embryon d’une future solution d’entreprise très modulaire, dynamique et robuste à la fois. Je ne sais pas si c’est l’effet OSGi ou si c’est l’effet d’une très bonne conception, la première version de S2AP apporte des réponses précises à des problèmes épineux. OSGI et S2AP sont à surveiller pendant les prochaines années, voir les prochains mois, car je pense qu’ils vont apporter pas mal de réponse à nos problèmes quotidiens. Prochainement, je vais publier deux billets pour présenter OSGI et S2AP.

J’ai ensuite eu le plaisir d’assister à deux excellentes présentations, l’une sur la gestion des transactions et les choix de performance dans un environnement Spring, une session présentée par Juergen Hoeller. L’autre session qui m'a beaucoup plu concerne les architectures RESTful et la solution à venir dans Spring 3.0, présentée par le spécialiste en la matière Arjen Poutsma.

La présentation sur la combinaison JSF Spring m’a confirmé qu’on avait fait de très bon choix en interne et m’a montré le chemin vers une solution qui semble fort intéressante basée sur JSF- SpringMVC et Spring. Cette formule magique s’appelle Spring Faces.

Si j’avais à choisir quel sujet présenté durant cette conférence est le plus intéressant, j’aurais beaucoup de mal. Ceci dit, j’ai quand même un faible pour Spring Batch.

Pour conclure, je trouve ma première participation à SpringONE très bénéfique et je suis très excité à l’idée de tester les technologies présentées pendant cette conférence afin d’en faire profiter nos clients et je ne manquerais surtout pas de vous en faire un retour !!

Spring Batch et S2AP, une tendance qui ne manquera pas de faire du bruit, par Frédéric

Pas le temps de s'endormir, les présentations de début de journée déclenchent les classiques effets spéciaux qui savent donner l'eau à la bouche de ses participants... Rod Johnson, Adrian Colyer, Rob Harrop ont su donner une dynamique à la journée pour nous tenir en haleine jusqu'à la fin.

En effet, le mot « visionnaire » tourne dans ma tête en me remémorant les pointures Rod Johnson, Juergen Holler, Thomas Risberg, j’en passe et des meilleurs. Le Spring que j’ai connu en 2005 avait l’air d’avoir percé les plafonds en secouant la base d’une plateforme J2EE stagnante. 2008 est l’année où Spring aura remué la communauté Java encore une fois en s’attaquant non plus à la partie Framework d’entreprise, mais aussi à la partie infrastructure. Tout d’abord, cette révolution s'adresse aux infrastructures Batch.

Jusqu’à aujourd’hui, aucune architecture batch en Java n’a pu percer, et pour cause, les batchs sont tous des programmes particuliers ne pouvant pas rentrer dans le cadre des applications conventionnels. Les problématiques de performance, volumétrie, encombrement des services, etc. sont le quotidien de ces programmes qui poussent souvent à faire le grand écart, et donner des architectures très hétérogènes. Cela dit, Spring Batch a sû trouver le bon périmètre, lever les bonnes problématiques pour se concentrer sur des fonctionnalités techniques récurrentes. D'ailleurs Dave Syer nous présente sa maxime très convaincante "On ne devrait jamais investir d'argent à développer une fonction, qui ne participe pas à la réalisation de notre métier". Pari réussi, mais n’en dévoilons pas trop, nous entrerons plus en détail dans d'autres articles qui vont suivre.

Autre gros poids lourds qui se profile, Spring propose de s’attaquer au domaine des middlewares, et même directement dans la cour des serveurs JavaEE. SpringSource Application Plateform propose une infrastructure pour déployer des applications Web et surtout des modules OSGi. Plus besoin des EJB, un module OSGi se propose de répondre à la couche de service.

Mon avis est qu’il offre pour l’instant un bon serveur pour le développement, mais pas encore prêt pour la production. Ce qui m'a agréablement surpris, est que ce produit a su reprendre les concepts essentielles des serveurs JavaEE, tout en posant sa pierre à l'édifice. Par exemple, les fichiers de configuration ne sont pas en XML mais en JSON, ce qui donne une bien meilleure lisibilité. Lors de la publication des erreurs, les ClassNotFoundException sont surchargées pour indiquer quel bundle a provoqué l’erreur, et même, propose des suggestions lors de l’apparition de certaines coquilles !! Fidèle à leur habitude, les gens de Spring Source nous proposent un produit original qui saura apporter sa propre touche, et promet de faire du bruit.

D'autres produits sont présentés avec plus ou moins maturité "Spring Integration" qui est encore dans une phase beta mais qui créer ex nihilo une architecture basée sur des évenements (Even Driven Architecture). Spring Security, venant de l'ex-Acegi, a su apporter toute la puissance du produit Acegi, en le mettant à niveau de tout. Plus de besoin de paramétrer 5 pages de configuration; avec la fameuse tendance de Spring à rendre les configurations faciles, Spring Security vous propose remplir les quelques informations indispensables, puis s'occupe du reste !! La sécurité des applications est enfin à la portée de tous.

Ouf, ça y'est, je pense que l'effet du Rennie m'est passé et je suis enfin prêt à dormir :)

Cependant, attendez vous à retrouver d'autres articles sur la plateforme Spring, à qui nous promettons un bel avenir! Prochaine étape, nous vous retrouvererons bientôt pour l'interview du responsable et du lead developer de Spring Batch, Dave Syer. A très bientôt !!

Frédéric TU & Moez LOUATI

Voici le troisième article sur le sujet de la Gestion d'identité (ou IAM).

La gestion d’identité est souvent vue comme un thème technique n’intéressant que les administrateurs du Système d’Information. Concentrons-nous sur la partie visible de l’iceberg, celle qui concerne chaque collaborateur.

Recherche sur un collaborateur.

La construction d’un portail d’identité se fait généralement en deux étapes qui, vous allez le voir, sont nettement insuffisantes.

1. La première étape consiste à récolter les informations sur les collaborateurs de l’entreprise et à les afficher le plus ergonomiquement possible.
   
2. La deuxième étape consiste à créer une page de recherche avec les champs « nom », « prénom », « numéro de téléphone » etc. et un bouton « rechercher ». Si les critères de la recherche sont insuffisants pour obtenir la fiche d’un seul collaborateur, une page intermédiaire permet de sélectionner le collaborateur voulu parmi une liste de choix possibles.

À ce niveau de réflexion, il est évident que les informations d’identité du collaborateur sont celles qui sont visibles par tout le monde. Le portail est une simple application « pages jaunes/pages blanches ».

Centraliser l’information

Les informations privées sont, quant à elles, accessibles à partir d’autres progiciels, applications diverses, référentiels de stockage informatique ou dans des listings papier ou encore dans le dossier de chaque collaborateur.

Cela n’encourage pas l’ensemble des collaborateurs à utiliser le nouveau portail d’identité qui vient d’être implémenté, puisqu’il est incomplet.
Une information décentralisée ne fait pas gagner de temps, au contraire, elle en fait perdre.

Pour gagner en productivité, il est nécessaire de centraliser toutes les informations d’identité. Nous ne nous intéressons pas ici aux problématiques liées au provisioning de référentiels.

Adapter l’information

Intéressons-nous à la possibilité de présenter ces informations confidentielles.

Quelle quantité d’informations confidentielles peut être disponible à partir du portail ? Partons du principe de disposer de toute l’information, confidentielle, privée ou publique à partir du portail.

Comment protéger ces informations confidentielles ? Le portail doit être sécurisé. Une page d’identification permet de vérifier que la personne qui se logue est bien connue du SI et qu’ensuite elle est qui elle prétend être, par la saisie de son mot de passe par exemple. Nous ne nous intéressons pas ici à l’art et la manière de sécuriser l’accès à un portail.

Le portail est protégé. Seules les personnes authentifiées ont accès aux informations d’identité. Sécuriser l’accès est nécessaire, mais pas suffisant, dans notre étude, si on ne gère pas l’identité de la personne connectée. En effet, avant d’afficher une information confidentielle, il faut s’assurer que la personne connectée ait le droit de voir cette information. C’est ce qu’on appelle l’habilitation. Sur quels critères l’information confidentielle doit-elle être affichée ? Et inversement, sur quels critères l’information confidentielle ne doit surtout pas être affichée ? Dans l’ensemble des éléments dits confidentiels, certains le restent pour la personne connectée, d’autres ne le sont plus.

Classifier les individus

Une première idée serait de gérer les droits, pour chaque utilisateur, sur chaque champ affiché, au niveau le plus bas, en positionnant des ACL dans l’annuaire LDAP, par exemple. Cette idée est

• Passable si le nombre de profils métier différents ou de collaborateurs dans l’entreprise ne dépasse pas 3
• Compliquée voire même irréalisable si l’entreprise est hétérogène en terme de fonctions et de services.
• Trop technique.
  

Un directeur, un commercial, un architecte, une secrétaire, un employé lambda, n’ont pas les mêmes besoins ni les mêmes droits, sinon tout le monde serait directeur. De plus le directeur de l’agence de Lyon a des contraintes différentes de celui de l’agence de Bordeaux…

Une étude peut être faite pour aboutir à une classification claire et précise des employés, mais attention à la maintenance et à l’évolution d’une telle structure sans le bon outil et les bonnes procédures.

Le bon outil

Plusieurs procédés sont envisageables pour implémenter notre portail.
Certains préféreront le développer de A jusqu’à Z. D’autres choisiront d’utiliser un outil de gestion de contenu d’identité. Pour ma part, je suis partisan de ne pas refaire le monde à chaque fois.
Parfois, investir dans un outil de gestion de contenu d’identité est la bonne solution, en termes de rapidité d’élaboration, d’administration, de maintenance et d’évolutivité.

Le bon référentiel

Nous n’avons pas encore discuté des référentiels de données. Nous avons vu qu’il fallait centraliser l’information. Notre portail présente cette information à partir d’un point d’accès unique. Mais faut-il aller plus loin et la centraliser physiquement en un seul référentiel ? Encore une fois, cela dépend du contexte et n’est pas toujours envisageable.
Dans la majorité des cas, avoir un référentiel central est une bonne solution, cela optimise la recherche d’informations, à partir du moment où un outil permet de gérer la synchronisation avec les autres référentiels.

En profiter pour gérer son SI

Nous avons discuté de l’utilité de présenter l’information d’identité à partir d’un portail, accessible dans l’Intranet par exemple. Ce portail est sécurisé et l’information est pertinente. Nous avons tous les éléments réunis pour étendre ses fonctionnalités et offrir des interfaces de gestion de l’identité.

Ajouter, modifier, supprimer sont des actions qui se font régulièrement et plusieurs fois par jour si l’entreprise est importante. Elles sont souvent réservées à une élite technique du SI qui finit par faire de la saisie administrative pour faire vivre le portail.

L’administration centralisée d’un portail est une fonctionnalité intéressante qui fera l’objet d’un autre article dans notre blog.

En résumé

Aujourd’hui il est parfaitement envisageable d’avoir une information et une administration centralisée de son SI. La productivité des collaborateurs sera nettement améliorée. L’administration du SI sera grandement facilitée et rapidement apparaîtra une réduction de coût de production et d’exploitation.

Dans certains cas, centraliser l’information correspond à la réunir physiquement, dans d’autres cas cela signifie la présenter en une unique interface IHM. La règle absolue n’existe pas, mais seule une étude approfondie permettra d’être certain de choisir la bonne solution.

Centraliser l’information est nécessaire mais pas suffisant. Nous l’avons vu, il faut présenter une information utile et pertinente en fonction de l’utilisateur connecté. L’idée qu’il y a derrière une gestion des identités et des accès, n’est pas de sécuriser pour interdire mais sécuriser pour présenter l’information utile sur l’identité d’une personne.
De plus, outre la sécurité, le besoin d’information est différent selon le profil de l’utilisateur qui fait la recherche. Ce qui est important c’est que l’information soit trouvée rapidement.

Implémenter un portail d’identité efficient permet de gagner

• en sécurité
  • Toutes les recherches passent par une interface centralisée dont l’accès est sécurise.
  • Le demandeur est bien identifié, authentifier et habilité. Il est connu par son profil métier.
• en productivité
  • Les recherches d’identité passent par une IHM unique.
  • Les recherches sont plus performantes car seule l’information utile au profil métier de la personne qui fait la recherche est présentée.
• en retour sur investissement
  • Le temps perdu à rechercher l’information dans plusieurs référentiels est supprimé.
  • Toute l’information utile est présente à un seul endroit et donc accessible.

Voici le deuxième article sur le sujet de la Gestion d'identité (ou IAM).

Nous allons aujourd’hui aborder le thème des processus en entreprise.
Toute entreprise a une série de processus internes, plus ou moins sécurisés, qui permettent à ses collaborateurs de progresser, mais pas toujours efficacement.

Une journée de travail comme les autres

Les processus métier pour aider les collaborateurs

Beaucoup de processus métier existent dans l’entreprise. Peu sont bien définis. Le résultat est que ces processus mettent parfois tellement de temps à s’accomplir que nous avons l’impression qu’il faudrait faire le travail soi-même pour être satisfait en temps et en heure. J’entends par là, s’assurer personnellement du bon déroulement des opérations, faire les demandes soi-même, aller parfois jusqu’à relancer les différents intervenants.

L’entreprise évolue, mais les processus sont oubliés parce que « personne » ne sait précisément quelles en sont les différentes étapes.

Des processus performants en 4 étapes.

Pour obtenir des processus performants, il est nécessaire de suivre 4 étapes essentielles.

1. La première étape est la plus difficile et la plus fastidieuse. Il est important de connaître les processus sur lesquels nous allons travailler. Chaque processus doit être identifié et disséqué pour en faire ressortir les intervenants, les services impactés et les relations entre eux.
2. La deuxième étape se fait en général conjointement avec la première. Les processus, maintenant connus en détail, peuvent être modélisés.
3. La troisième étape est la plus intéressante car elle permet de les étudier pour en améliorer leur performance. Si l’entreprise a évolué, certaines étapes du processus peuvent être modifiées, certaines même supprimées ou au contraire il faut en rajouter pour améliorer le fonctionnement global. Il faudra, sans doute, repasser par une étape de modélisation de ces processus optimisés.
4. La dernière étape, très technique mais essentielle pour garder le contrôle de l’évolution future de ces processus va permettre de les implémenter dans des outils efficaces et performants.

Ce travail peut être long et insipide. Il est important de bien le cadrer et de s’entourer d’experts en gestion d’identité et des processus métier. Certains outils informatiques, de gestion d’identité, permettent d’implémenter ces processus, à moindre coût, sans passer par les gros BPM (Business Process Management).

Modéliser et implémenter les processus métier permet de gagner :

• en sécurité
  • Pas de contournement possible. Obligation de passer par le processus implémenté.
  • Le demandeur est bien identifié.
  • Les approbateurs sont bien identifiés.
  • Les contournements possibles sont définis à l’avance.
  • Dans le cas où aucun contournement n’est prévu, les intervenants ne peuvent être écartés intentionnellement du processus de validation.
• en productivité
  • L’activité de chaque intervenant est parfaitement décrite et connue.
  • Les processus sont optimisés et accessibles à partir d’un point d’accès unique.
  • Les relances et escalades automatiques sont définies et déclenchées au bon moment.
  • Visibilité absolue sur le déroulement du processus.
• en retour sur investissement
  • Le temps perdu à rechercher le bon interlocuteur est supprimé.
  • Les absences ne sont plus un frein au bon déroulement du processus.
  • Le processus ne prendra pas plus de temps que sa durée maximale du déroulement.
    

Cette dernière journée a été marquée par une perturbation originale : une épidémie de méga gastro, qui semble d'ailleurs avoir touché Antonio du Paris JUG et a vu un présentateur s'évanouir et être évacué ! Sinon, la session générale de James Gosling a permis de passer en revue un certain nombre de projets ou produits :

• VisualVM, qui s'avère très efficace pour le monitoring de JVM mais aussi de serveur d'application (avec évidemment comme premier plugin Glassfish)
• Le support complet du JavaScript dans Netbeans : autocompletion, validation syaxique, débugging dans Firefox (avec breakpoints etc.) et contrôle de la qualité du code (pas de return inconsistants, avec un exemple sur Prototype...)
• Les jeux : à la fois dans l'interface graphique, et le support de la puce NVidia APX 2500 pour téléphone, et le projet Darkstar pour créer une infrastructure de serveurs destinés au jeux massivement parallèles (pour être le JavaEE du jeu !)
• Un drole de stylo qui reconnaît et stocke ce que vous écrivez
• Les java cards, maintenant en V3 et permettant de coder de la logique (avec un jeu de bataille de robots pour illustration)
• Sentilla, une société qui commercialise des petits boitiers sur lesquels connecter des capteurs (démo sympa de ballons équipés jetés dans le public, et suivis en temps réel)
• Java temps réel et industriel, avec entre autre une voiture robotisée autonome pour le Darpa Urban Challenge, et un automate industriel embarqué
• Java comme moyen d'aider la recherche sur Mars et au CERN de Genêve.

Bref, une liste plus ou moins intéressante, mais qui montre l'étendue des applications de Java.

Après une autre session assez claire des mécanismes "classiques" de web services en Java, complétée d'une revue plus complète des possibilité de Metro (encore, je sais c'est une obsession), j'ai assisté à la démonstration des outils de développement de JBoss, et notamment elui destiné à son ESB couplé à jBPM. Intéressant, mais moins que la dernière session consacrée aux problématiques non encore résolues du massivement multi coeur pour Java : au delà de l'utilisation pour les tâches de GC, en hardware notamment avec Azul, quels sont les démarches à inventer pour le massivement transactionnel concurrent ? La démarche Software Transactional Memory, vendu comme l'équivalent pour les locks du GC pour la mémoire, ne semble pas se concrétiser

A suivre l'année prochaine...

Cameron Purdy nous a fait une présentation enlevée, ponctué de bons mots pour faire passer 10 principes à prendre en compte pour bien faire monter en charge une application Java. Certes, le principe n°0 est justement de ne pas appliquer les autres religieusement, mais cette liste frappée au coin du bon sens rappelle certains points importants : le partitionnement, la coordination, la prédictibilité de la latence de l'application, le fait que ce soit les applications avec état qui posent problème, mais aussi l'importance de prévoir dès le départ ce qui se passe en en surcharge (car elle va arriver...) et ce qu'il faudra faire après une panne (car elle va aussi arriver...). Rien de révolutionnaire, mais un petit rafraîchissement bienvenu.

Rien de révolutionnaire non plus dans la conférence suivante, et pourtant la queue de 1100 personnes pour y accéder s'étalait jusque sur le trottoir !

Le sujet était il est vrai attirant : Advanced Web Application Security. On a parlé des techniques en vogue (cross site request forgery, XSS, JavaScript Hijacking...) et les demos sur un twitter-like ont fait leur petit effet. Enfin, quelques recommandations ont été présentées : utiliser le servlet Filter OWASP et faire un double submit du cookie de session, faire son JSON propre, et éviter de se reposer sur la souplesse de certains navigateur...