> 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

État des lieux de la réponse à incident de cybersécurité

État des lieux de la réponse à incident de cybersécurité

Les experts de Palo Alto Networks, Unit 42 et Forrester Research livrent dans ce webinaire exclusif leurs éclairages et stratégies en matière de réponses aux incidents. Bénéficiez d'un panorama complet du paysage actuel de la réponse aux incidents et de sa relation avec la continuité de l'activité, des défis auxquels font face les entreprises et des tendances majeures qui modèlent ce domaine. Un état des lieux précieux pour les décideurs et professionnels IT.

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