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.
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
Les 10 tendances clés de l’Expérience Client (CX) pour 2025
Dans le contexte actuel, l'expérience client est un levier clé de réussite. Pour rester compétitives, les entreprises doivent adopter des stratégies CX audacieuses, en s'appuyant sur le cloud, le digital et l'IA. Alors quelles stratégies mettre en place pour garder une longueur d’avance ?