> Tech > Détection automatique de l’environnement runtime

Détection automatique de l’environnement runtime

Tech - Par iTPro.fr - Publié le 24 juin 2010
email

par Bradley D. Kliewer
Si vous utilisez le kit iSeries pour développer des requêtes SQL destinées à  des fichiers iSeries qui s'exécuteront sur un PC et sur l'iSeries, vous avez sûrement remarqué que le programme Java démarre bien plus lentement sur l'iSeries que sur le PC. Ce ralentissement est dû pour beaucoup aux drivers JDBC du kit ...

Les drivers DB2 UDB natifs (aussi appelés drivers DB2) démarrent bien plus rapidement. Cependant, cette rapide initialisation se fait au détriment de la portabilité : on ne peut pas utiliser les drivers DB2 UDB d'un programme s'exécutant sur le PC, où le débogage avec des outils de développement (comme VisualAge) est bien plus commode.

Et si l'on pouvait avoir le meilleur de deux mondes : des drivers DB2 UDB pour exécuter des applications sur l'iSeries, et des drivers Toolkit pour déboguer des applications sur le PC ? Avec une classe d'utilitaires plutôt courte qui s'adapte à  l'environnement runtime, on peut presque directement déplacer un programme d'une plateforme sur l'autre. Examinons une classe raisonnablement simple que vous pouvez facilement mettre en oeuvre en l'état ou adapter facilement à  vos propres besoins.

Détection automatique de l’environnement runtime

  Le code UML (Unified Modeling Language) de la figure 1 présente la structure de la classe DriverSelector. Les six champs sont définis comme privés (indiqués par le préfixe  » –  » dans leurs noms). En interdisant l’accès aux champs, nous bénéficions pleinement de l’encapsulation. La classe DriverSelector est traitée comme une boîte noire qui reste indépendante de sa représentation de données interne. A noter que deux méthodes – demo et setup – sont également définies comme privées parce qu’elles ne sont pas destinées à  une utilisation polyvalente. La méthode principale publique (public main) fournit simplement un point de départ commode pour tester la classe. La méthode clé – getConnection – crée une connexion de base de données appropriée fondée sur le profil de la machine et sur le système d’exploitation accédant à  la base de données iSeries. Les autres méthodes offrent des informations qui seront utiles de temps en temps pour le programme appelant. Elles fournissent aussi des informations importantes pour déterminer le type de connexion renvoyée par getConnection. La classe DriverSelector suit plusieurs étapes pour examiner et s’adapter à  son environnement, en passant du plus générique (disponible dans tout environnement Java de Linux à  l’iSeries), au plus spécifique (utile uniquement sur l’iSeries). Le code source pour la classe DriverSelector est disponible à  www.iseriesnetwork.com/code.

Téléchargez cette ressource

Comment lutter contre le Phishing ?

Comment lutter contre le Phishing ?

Dans un environnement cyber en constante mutation, le phishing évolue vers des attaques toujours plus sophistiquées combinant IA, automatisation et industrialisation. Une réalité complexe qui exige des mesures de sécurité avancées et repensées au-delà de l’authentification multifacteur. Découvrez les réponses technologiques préconisées par les experts Eviden et les perspectives associées à leur mise en œuvre.

Tech - Par iTPro.fr - Publié le 24 juin 2010

A lire aussi sur le site

Revue Smart DSI

La Revue du Décideur IT