Le métier d'architecte en SI (GNU Linux Mag n°207)
Blockchain: modifier un contrat immuable (GNU Linux Mag n°206)
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)
Auditer une application réactive (GNU Linux Mag n°176)
Java8 est réactif ! (GNU Linux Mag n°174)
Android : Comment consommer un socket ouvert par une autre application ?
Comment évolue Android ? Est-il bon de proposer toutes les API ?
Android: Webkit offline (GNU Linux Mag n°166)
Android : Plugin de layout (GNU Linux Mag n°165)
PKI sur Android ? (GNU Linux Mag n°162)
Ergonomie des systèmes mobiles, partie 1 (GNU Linux Mag n°162)
Les malware sur smartphones, une peur disproportionné ? (Lemonde.fr)
La mort prochaine des ramasse-miettes ? (GNU Linux Mag n°157)
Les architectures de sécurités des OS mobiles (HS GNU Linux Mag n°61)
Sécurité du développement (HS GNU Linux Mag n°61)
Privilèges optionnels (HS GNU Linux Mag°61)
JUnit Android pour les PRO (HS GNU Linux Mag°61)
La sécurité des sites Web mobile (HS GNU Linux Mag°61)
Edito HS Android (HS GNU Linux Mag n°60)
Backup de l'application (HS GNU Linux Mag n°60)
Développement mobile : Web ou Natif ? Clubic pro
La java de Broadway (HS GNU Linux Mag n°56)
Java 64 bits (HS GNU Linux Mag n°56)
Les technologies JavaEE (HS GNU Linux Mag n°56)
Injection de dépendances (HS GNU Linux Mag n°56)
Les briques pour développer une place de marché pour Android (HS GNU Linux Mag n°56)
Bibliothèque partagée sous Android (HS GNU Linux Mag n°56)
C2DM Simulateur (HS GNU Linux Mag n°56)
Developpement Android (HS GNU Linux Mag n°52)
L'avenir des systèmes de fichiers (GNU Linux Mag n°124)
Les technologies clusters (GNU Linux Mag n°123)
Critique du plugin "Correcteur terminologique" dans Numerama
Macaron, une porte dérobée pour les applications JavaEE (MISC n°45 et GNU Linux Mag n°120)
La sécurité Java (MISC n°45)
JSR 269 : L'API de gestion des annotations Java 5 (GNU Linux Mag n°117)
Programmation orienté Aspect avec Java (GNU Linux Mag n°117)
JNDI-Resources : écrit une fois, installé partout (GNU Linux Mag n°110 et 111)
L'épopée du Singleton (GNU Linux Mag n°111)
La mémoire des JVM et serveur JEE (GNU Linux Mag n°104)
XML : Ouverture sur le monde (GNU Linux Mag n°103)
Functor en C, C++ et Java (Programmez n°94)
Développement Web avancé avec AJAX (GNU Linux Mag n°91)
White Paper Atos Origin sur Ajax.
Pourquoi utiliser JNDI ? (GNU Linux Mag n°87)
Functor et haute disponibilité avec JMS (GNU Linux Mag n°83)
Load Balancing et Fail Over pour les services Web (GNU Linux Mag n°78)
UserAgent (Programmez n°76 et 77)
Denis de service par complexité (MISC n°19)
Découvrez et comprenez la technologie GRID (GNU Linux Mag n°70)
Bac à sable (Linux Mag n°68)
Modèle mémoire en Java (GNU Linux Mag n°67)
Check list de sécurité du développeur (Programmez n°70)
Clavier Biométrique (GNU Linux Mag n°66)
La sécurité des applications (Programmez n°65)
Maladresses et bugs en java (GNU Linux Mag n°62)
Cross Site Scripting, les contre-mesures (Programmez n°63 et 64)
Problèmes et solutions de l'authentification par mot de passe (GNU Linux Mag n°61)
Les paramètres en Java (GNU Linux Mag n°53)
Découvrez un couteau suisse pour les grappes de serveurs (GNU Linux Mag n°49,50 et 53)
L'homme du milieu (MISC n°4)
Cross Site Scripting et FTP (MISC n°3)
Management à chaud avec JMX (Développeur référence n°2.14)
Développer sécurisé (Programmez n°43)
Java, Soyez class ! (Programmez n°40 et n°42)
La bibliothéque Rhino (Programmez n°41)
Rendre portables les services en ligne (Programmez n°39)
Prenez Java, en premiére classe (Programmez n°39)
Ne vous prenez plus l'en-tête avec les URL (Programmez n°36)
Optimiser un site (Développeur référence n°2, 3 et 4)
Les pièges du C++ (Programmez n°29,30,31,32,33)
Java techniques d'énumération (Développeur référence n°2)
Java multitâche avec synchronized (Développeur référence n°1)
Les inner-classes vous optimisent la vie (Programmez n°29)
Faites-vous entendre grâce à VoiceXML (Programmez n°29)
La rentrée des classes et effets de langages (Programmez n°25)
Automates confrontés à la routine (Programmez n°20)
Devenez agrégé de C++ et de Java (Programmez n°18 et 19)
Objets métiers toutes options (Programmez n°18)
Accélérez vos progOptimisation de Javarammes (Programmez n°17)
Gagnez du temps avec les méthodes inline (Programmez n°16)
Mettez de l'ordre dans vos constructeurs (Programmez n°16)
Fiabilité à quelques exceptions près (Programmez n°15)
Instances et mutations des objets (Programmez n°15)
Héritage objet en C++ (Programmez n°14)
Fignoler la méthode finalize() (Programmez n°14)
Hacher le code pour mieux l'exploiter (Programmez n°13)
L'art des tests en C++ (Programmez n°13)
De l'égalité des classes (Programmez n°12)
Accédez aux attributs classieux (Programmez n°12)
Comment cloner les objets avec classe (Programmez n°11)
Pointeurs contre sérieuses référence (Programmez n°11)
Les String travaillent à la chaîne (Programmez n°10)
L'art de bâtir des constructeurs sans erreur (Programmez n°10)
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.
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.
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.
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.
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.
Dossier réalisé par Annie Litchtner avec Olivier Bouzereau, Philippe Prados (IBM Global Services) et Véronique Reynier.
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.
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.
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.
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.
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é.
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. "