Mes publications presse et blog

2015

    • Les secrets des algos à haute fréquence (GNU Linux Mag n°184)
    • Architecture des processeurs (GNU Linux Mag n°183)
    • Architecture all in memory (GNU Linux Mag n°183)
    • La sécurité sous Android (HS Sécurité & Linux n°76)

    2014

      2013

      2012

      2011

      2010

      2009


      2008


      2007


      2006


      2005


      2004


      2003


      2002


      2001

      2000


      1999

      Extrait de GNU Linux Mag - N°120, page 12

      Macaron, une porte dérobée pour toutes les applications JavaEE - Philippe Prados

      Philippe Prados présente une backdoor qui est disponible sous la forme d'une archive jar intégrable dans une application J2EE. Le nom vient juste de la pâtisserie qu'il apprécie.

      En plus de cette porte dérobée, la suite Macaron regroupe des outils complémentaires d'audit, de scellement et de définition de politique. La définition de politique est d'ailleurs à peu près la seule solution fiable de protection en combinaison avec le scellement, mais c'est loin d'être trivial à mettre en oeuvre.

      La démonstration d'intégration du jar, du déploiement et son exploitation est spectaculaire.

      Parmi les fonctionnalités de la porte dérobée, on a l'exploration et la modification des ressources JMX, JDBC, JNDI, et un interpréteur de commandes. Ce dernier n'est pas très rapide, mais pleinement fonctionnel.

      C'est typiquement le genre d'outils que l'on aimerait avoir sous la main quand on administre un serveur d'applications.

      Extrait du journal du téléphone - N°34, page 50

      Nouvelles images : le grand trafic

      Tout autour de la planète, des alliances sont en train de se nouer pour transporter les nouveaux signaux et surtout pour vendre les futures fruits du multimédia. Ces accords sont facilités par la grande lucidité de quelques informaticiens : Tout se mélange. L'informatique atteint un niveau de maturité tel qu'elle peut maîtriser tout type de communication : la photo, la télévision, les télécopies, les images animées. Les principaux intervenants ont, bien sûr, intérêt à se réunir. Sinon d'autre le feront à leur place. Les partenariats naissent de la concurrence, explique Philippe Prados, ingénieur informatique.

      Logiciel et systèmes - N°25

      Assurer la continuité de l'approche objet

      Nous avons rencontré Philippe Prados, ingénieur expert du département Technologie Objet et Client/Serveur d'IBM Global Services, qui nous a donné son point de vue sur l'intérêt des SGBDO. L'une des solutions permettant de rendre persistants les objets traités dans une application consiste à les stocker dans une base donnée relationnelle. C'est la solution utilisée généralement. Elle rassure les directions informatiques car elle ne provoque pas de remise en cause des choix antérieurs.

      Mais la traduction d'un modèle objet en modèle relationnel est difficile, alors que l'inverse est aisée. Le problème essentiel consiste à représenter l'héritage entre classes ; différentes techniques sont utilisées, mais elles ne donnent pas entièrement satisfactions. Pour faciliter la transformation vers le relationnel, on utilise parfois un modèle objet appauvri. On peut aussi chercher à automatiser cette conversion ; c'est ce que propose IBM avec son framework de persistance.

      D'où l'intérêt des SGBDO permettant d'assurer directement la persistance du modèle de conception et de réalisation. Souvent, on confronte leurs capacités à celles des SGBDR, mais le débat est biaisé. On prend une application exploitant une base relationnelle et on la transpose telle quelle en utilisant une base objet ; on effectue aussi la transformation opposée.

      De telles comparaisons n'ont pas de signification. Les concepts et les principes de modélisation sont complètement différents et donnent lieu à des architectures distinctes : on peut ainsi être amené à naviguer dans une base relationnelle ou à faire des opérations ensemblistes dans une base objet.

      On a bien deux mondes disjoints et il faut éviter de les mélanger. Si l'on utilise un SGBDR, il faut faire une conception selon le modèle entité-relation ou accepter de dégrader le modèle objet, alors qu'une approche objet aura sa continuité naturelle dans un SGBDO. Dans ce cas, les objets sont utilisés dans leur langage natif : il suffit lors de leur construction d'indiquer s'ils sont persistants ou temporaires.

      Une voie douce vers l'objet : le relationnel-objet

      L'aura de Java renforce l'expansion de la technologie objet. On la retrouve même dans les bases relationnelles-objet Oracle 8 d'Oracle, Universal Server d'Informix, Adaptive Server de Sybase et DB2 Universal Database d'IBM. De tels produits facilitent la prise en compte des modèles objet. A l'inverse, l'utilisation de telles bases ou de bases objet dans le cadre d'une programmation non objet permet de bénéficier de la sémantique plus complète du modèle objet. La richesse d'expression du modèle objet est bien plus importante que celle du relationnel précise Philippe Prados. La création de vus objets de tables permet d'ailleurs de réintroduire des aspects sémantiques que la modélisation tabulaire n'exprime pas.

      Le relationnel objet supprime la contrainte de la limitation du nombre de types de données manipulés par le rationnel. Il introduit aussi l'héritage, l'agrégation, la navigation... En résumé, il permet de gérer un véritable modèle objet. Le relationnel-objet va permettre d'intégrer des bases de données objet dans des environnements actuellement relationnels. Il est plus facile de changer de version de SGBDR et de se retrouver ainsi avec du relationnel-objet que de faire un saut direct vers une base objet. Certaines activités telles que la CAS, le trading, les télécommunications se prêtent bien à la mise en oeuvre de SGBDO. Le besoin d'une forte réactivité favorise le développement objet associé à une base objet.

      Par contre le relationnel-objet est politiquement correct précise notre interlocuteur. Une fois que l'on a été confronté à la difficulté de traduction entre le monde objet et le monde relationnel, on rêve de ne plus avoir à le gérer. La solution évidente, c'est la base objet. La grande difficulté est de la faire accepter. C'est essentiellement un problème culturel et c'est pour cela que le relationnel-objet est un bon palliatif. Bien entendu, ces changements demandent du temps : si Java est jeune, le relationnel-objet l'est encore plus. En outre, il va être difficile d'apprécier dans quelle mesure il est utilisé pour ses capacités objet. Ceci ne facilitera pas la visibilité des parts de marché respectives des technologies relationnelles et objet.

      Java va assurer une cohérence complète entre le développement et base de données, les traitements pouvant s'exécuter aussi bien sur le serveur que sur un client, quelles que soient les plates-formes. En outre il favorise la diffusion des langages objets et de la culture associée : il va permettre de ramener l'objet dans les entreprises.

      Internet met en oeuvre des technologies nécessitant une adaptation permanente, les applications y évoluent rapidement dans un univers concurrentiel, gèrent des données multimédias... Ces facteurs poussent vers l'objet et les SGBDO. En résumé, le monde objet est tiré par Java, bien que ce dernier soit encore très peu utilisé en production.

      01 Informatique n°1519

      Quelques réflexions sur la programmation objet

      Spécialiste de la programmation objet (il est l'auteur de deux ouvrages traitant de C++, Java et Smalltalk), Philippe Prados a consacré l'essentiel de ses pages personnelles à sa passion. Ce site regroupe ainsi (hormis quelques réflexions et thèmes personnels) des informations sur le paradigme objet (patterns, bibliothèques C++ et Java...) à destination de ceux qui cherchent à en savoir un peu plus sur le sujet ou à échanger quelques idées et astuces avec l'auteur.

      Le site comprend également d'autres articles liés à l'informatique, mais ne traitant pas spécificauement de la programmation objet. Un exemple : un mini-cours sur la transparence des fichiers Gif. Les explications sont claires et appuyées par des schémas très explicites. Cependant, le site dans son ensemble gagnerait à être étoffé, et le sommaire devrait fournir des liens plus directs pour accéder aux articles.

      Extrait de Informatique magazine du 4 décembre 1998

      Dossier réalisé par Annie Litchtner avec Olivier Bouzereau, Philippe Prados (IBM Global Services) et Véronique Reynier.

      Comprendre la plate-forme Java

      Les technologie Java ne cesse d'évoluer pour répondre aux besoins des utilisateurs. Les applications client-serveur Java obéissent à une logique objet et à un mode de répartition des traitements dont la plate-forme de déploiement de Sun fournit les éléments clés.

      Dès la fin 1995, le langage Java de Sun s'est propagé sur le poste client par l'intermédiaire de l'outil de navigation Web de Netscape, lequel intègre une machine virtuelle Java. Ensuite, le langage a atteint les serveurs avant de s'immiscer au sein des services intermédiaires pour devenir une plate-forme de déploiement agissant à chaque niveau d'une application distribuée. L'appui de grands fournisseurs informatiques (IBM, Netscape, Oracle, Sun) crédibilise cette approche globale. L'installation d'un application Java s'articule donc autour de deux axes, la mise en place du poste-client et les échanges entres plates formes et composants.

      La mise en place du poste client

      Depuis un simple navigateur Web, toute requête d'accès à une page HTML s'adresse à un serveur Web par le biais du protocole HTTP. Certaines requêtes téléchargent vers le poste client une petite application Java : l'applet. Il accompagne la page HTML et se trouve aussitôt exécuté par la machine virtuelle Java du browser Web. L'applet s'occupe des contrôles de saisie d'un formulaire et de l'interaction avec l'utilisateur. Il agit principalement sur l'interface utilisateur.

      Les échanges entre plates-formes et composants

      Connectés à un réseau TCP/IP, les postes clients accèdent aux services distribués sur plusieurs plates-formes serveurs. Le serveur applicatif épaule l'applet en exécutant l'essentiel des traitements demandés par l'utilisateur : calculs, tris ou synthèses. Le serveur applicatif dialogue avec un deuxième serveur métier, qui détient les règles de gestion de l'entreprise. Ce dernier serveur - hébergé par un PC ou un grand système - contient les informations stratégiques de l'entreprise. Il assure les contrôles de sécurité liés au partage de données et de traitements.

      L'applet, côté client, agrège des composants logiciels orientés utilisateur, les Java Beans, ou JB. L'applet dialogue avec le serveur applicatif par l'intermédiaire d'un courtier de requêtes objets de type RMI ou via le protocole IIOP, ce dernier étant conforme à l'architecture Corba de l'OMG (Object Management Group). Le serveur dispose, lui aussi d'applications Java, les serveur EJB (Entreprise Java Beans). Ce sont des composants encadrés par une couche transactionnelle telle que MQ Series, Tuxedo de BEA ou Jaguar de Sybase. Les EJB obéissent éventuellement à une répartition de la charge entre plusieurs serveurs. Par conception, les traitements du serveur d'application pilotent des EJB métier via les mêmes interfaces standard (RMI ou IIOP). A son tour, l'EJB métier gère la persistance des objets métier par l'intermédiaire du driver d'accès aux bases de données JDBC. Cette faculté permet de conserver un contexte pour un même objet partagé simultanément par plusieurs applications.

      La plate-forme Java s'enrichit au fil des besoins. Par exemple, la dernière version des EJB complète la persistance des objets répartis sur les serveurs. Les EJB peuvent ainsi gérer leur propre contexte ou bien déléguer cette tâche au conteneur d'EJB.

      Extrait de Informatique magazine du 15 novembre 1997

      Dossier : L'entreprise Java

      Le succès de la Java dans l’entreprise dépend de Windows, mais, en même temps, Java gêne Microsoft. Les procès actuels révèlent bien l’enjeu : Microsoft adapte Java, mais tente d’empêcher son succès en l’entourant pour mieux l’étouffer, note Philippe Prados, ingénieur chez IBM Global Services, avant de poursuivre : Le choix politique de Microsoft consiste à rallier l’architecture COM aux dépens de RMI (Remote Method Invocation) et de Corba (Common Objet Request Broker Architecture). Aussi, Sun reproche-t’il à Microsoft de ne pas respecter les règles du jeu, ce qui déplace le débat sur le terrain juridique.

      L'Express multimédia n°2489

      Le monde des nombrils

      Rien de plus facile que de se lancer sur Internet : vous prenez en photo les nombrils de votre femme, de vos enfants et de vos amis, en plus du vôtre, bien sûr. Vous en faites le décor exclusif de chacune de vos pages et vous ajoutez, sans secouer, les sites qui traitent du même thème. En termes spécialisés, vous venez de créer une communauté.

      Le monde informatique

      Java : un debogage multifacette

      Choisir le degré de portabilité
      Parmi les fonctionnalités disponibles dans les principaux débogueurs : la pose de points d'arrêts, les exécutions pas à pas, l'affichage du contenu des variables. Une fonction de débogage dynamique peut également être disponible : la modification d'une ligne recompile automatiquement la classe et la recharge dans la machine virtuelle. Des produits complémentaires peuvent ici être utilisés. Par exemple, " 100 % Purecheck " de Sun, qui s'assure de la portabilité totale à partir du code compilé. Reste le problème du compilateur qui peut boguer. " Dans ce cas, on ne sait pas d'où ça vient ", constate Philippe Prados, architecte Java chez IBM. Il y a alors la possibilité " d'écrire directement en p-code Java [pseudo langage proche du code machine, NDLR] ce qui permet d'optimiser et d'aller 250 fois plus vite lors de la première exécution. Mais cela oblige à écrire pour une machine virtuelle donnée. "

      Comments