Ajouter un client Java

s’intègre-t-il à  l’application RPG existante
?
On commence par attribuer la
classe à  un package nommé testcase
(en A). Un package est une collection
de classes Java présentant généralement
des points communs. Un package
a une caractéristique importante :
il sert de qualificateur pour les classes
Java. Par exemple, on pourrait avoir de
multiples packages (brian, gary, par
exemple) dont chacun contient une
classe avec le même nom (CustomerService,
par exemple) et chaque
classe serait adressable de façon
unique (brian.CustomerService, gary.
CustomerService, par exemple). En B,
CustomerTest instancie un objet
CustomerService. CustomerTest extrait
les données client en invoquant
des méthodes (en C) que Customer-
Service met en oeuvre. A noter que les
noms de méthodes (isGoldLevel-
Customer, par exemple) correspondent
aux noms de sous-procédures
utilisées dans le programme RPG Cust-
Test à  une petite exception près : ils
commencent par une lettre minuscule
pour respecter les conventions de
noms Java. Après avoir extrait l’information
client, CustomerTest l’affiche
puis se termine.
Une couche d’emballage mince
constituée de la classe Java CustomerService
(figure 7 et figure 7 bis) et du programme
de service RPG JCustSrv (figure 8 et figure 8 bis)
intègre le client Java et l’application
RPG existante dans notre exemple.
L’intégration est également possible
sans cette couche ou avec uniquement
l’un de ces deux composants. Autrement
dit, vous pourriez placer la logique
qui se trouve dans Customer-
Service dans le client Java lui-même ;
vous pourriez aussi modifier le programme
de service CustSrv pour qu’il contienne les sous-procédures validées
JNI qui se trouvent dans le programme
de service JCustSrv. Nous
vous conseillons fortement d’adopter
l’approche la plus modulaire qu’offre
la couche d’emballage mince, pour
simplifier la maintenance de l’application
et atténuer l’impact négatif des
changements applicatifs. La couche
d’emballage mince présente deux
avantages : elle vous permet d’ajouter
plus facilement Java aux applications
existantes, et elle vous aide à  isoler les
développeurs des détails de l’intégration.
Les développeurs Java et les développeurs
RPG peuvent continuer à  travailler
sur l’application comme à 
l’accoutumé et confier l’intégration aux
spécialistes rompus aux arcanes de JNI.
CustomerService effectue deux
tâches importantes pour l’intégration.
Il sert d’interface avec le programme
de service RPG JcustSrv, et il procède à 
la conversion de type pour les éventuels
paramètres et valeurs de renvoi
dont les types de données ne sont pas
des primitives Java (voir figure 2). Les
méthodes invoquées par Customer-
Test ont toutes un seul paramètre numérique,
CustomerID. Comme les paramètres
numériques correspondent
aux primitives Java (int, long, par
exemple), la conversion de type n’est
nécessaire pour aucun paramètre.
Toutefois, considérons les types de valeurs
de renvoi suivants :

• isGoldLevelCustomer – booléen
• getCustomerPhoneNumber – long
• getCustomerName – chaîne
• getLastOrderDate – date

Comme isGoldLevelCustomer et
getCustomerPhoneNumber utilisent
des primitives Java comme types de
renvoi, RPG implémente directement
ces méthodes. En revanche, les méthodes
getCustomerName et getLast-
OrderDate exigent une conversion de
type. Cette conversion peut se faire en
Java ou en RPG, mais il est bien plus
naturel de le faire en Java. Customer-
Service implémente donc les deux dernières
méthodes afin qu’elles convertissent
les types de données si
nécessaire et invoquent les méthodes
natives RPG qui extraient réellement
l’information client. Pour les méthodes
qui requièrent la conversion de type,
nous choisissons une convention qui
construit le nom de méthode natif en
ajoutant le suffixe AsBytes au nom de la
méthode (par exemple, getCustomer-NameAsBytes, getLastOrderDateAsBytes).
Examinons maintenant CustomerService.
La méthode System.loadLibrary (figure
7 en A) identifie JCustSrv comme
le programme de service dans lequel il
faut trouver les méthodes natives (en
B) que CustomerService invoque.
Quand le client Java CustomerTest invoque
isGoldLevelCustomer ou get-
CustomerPhoneNumber, Customer-
Service se comporte simplement
comme un point de passage et invoque
les méthodes natives dans le programme
de service RPG JCustSrv.
Cependant, CustomerTest invoque
getCustomerName et getLastOrder-
Date à  partir de CustomerService (en
C) lequel, à  son tour, extrait l’information
client en invoquant les méthodes
natives getCustomerNameAsBytes et
getLastOrderDateAsBytes, respectivement.
Terminant la couche d’emballage
mince, le programme de service
JCustSrv (figure 8) effectue aussi deux
tâches importantes pour l’intégration.
Il définit l’interface (dans les prototypes
de procédures) à  Java et extrait
l’information client en invoquant des
sous-procédures dans le programme
de service CustSrv à  partir de l’application
RPG existante.
Commençons l’examen de JCust-
Srv en jetant un coup d’oeil à  ses prototypes
de procédures (membre de copie
JCustSrvPr en figure 9) qui
définissent l’interface à  Java. On constate
que les noms de sous-procédures
(IsGoldLevelCustomerForJNI) ne semblent
pas correspondre aux noms de
méthodes Java évoqués précédemment.
Ce sont des noms de sous-procédures
internes de RPG ; ils suivent
une convention de noms particulière
qui ajoute le suffixe ForJNI aux noms
de sous-procédures d’applications
RPG existantes pour signifier leur utilisation
dans un environnement JNI.
Pour comprendre le mécanisme de
l’interface à  Java, examinons le premier
prototype, IsGoldLevelCustomerFor-
JNI. La magie de l’interface se manifeste
grâce au mot-clé ExtProc (en A).
Rappelez-vous que ce mot-clé prend la
forme

ExtProc( *Java: Yourclass: YourMethod )

Dans ce cas, testcase.Customer-
Service est la classe qualifiée (où testcase
est le package) et isGoldLevel-
Customer est la méthode Java. Notez
également que le prototype définit le paramètre Customer ID numérique
comme passé par la valeur et comme
un type supporté par Java, entier, plutôt
que comme son attribut réel zoné à 
8 bits. Une telle définition résulte en
une conversion de type implicite. Les
prototypes restants suivent les mêmes
conventions.
Le programme de service JCustSrv
est on ne peut plus simple, et il en est
de même pour tout programme de service
RPG qui sert d’emballage mince à 
Java. Chaque sous-procédure a une
ligne unique de code exécutable – une
instruction Return qui exécute la sousprocédure
d’accompagnement dans le
programme de service RPG existant
(CustSrv) pour extraire et renvoyer
l’information client appropriée.