Assembler le tout

ou une collection de fonctions utilitaires (comme des routines de traitement de dates) que beaucoup d’applications différentes utiliseront.

On peut utiliser des modules ILE pour packager des procédures, de la même manière qu’on utilise des bibliothèques pour packager des applications. Cela dit, un module ILE ne peut pas être exécuté directement : il faut combiner des modules pour créer des programmes et des programmes de service.

Le code peut être packagé dans un programme ou dans un programme de service. Pour choisir entre les deux, il faut prendre en compte deux critères principaux : comment le code sera utilisé et à quel rythme il sera modifié. On utilisera un programme de service pour grouper des procédures utilisées par de nombreuses applications différentes et qui changent souvent. Comme un module, un programme de service n’est jamais appelé directement ; mais, contrairement à un module, les procédures dans un programme de service peuvent être exécutées. Un programme de service procure une réutilisation de code maximale pour les langages ILE, parce que toutes les applications qui utilisent des procédures dans un programme de service utilisent la même copie du code.

A l’inverse, quand on combine des modules dans un programme, le code est copié dans l’objet *PGM. Un programme peut aussi inclure des appels adressés à des procédures dans des programmes de service. De toutes les composantes ILE évoquées ici, seul un programme peut être exécuté directement (par exemple, appelé depuis une ligne de commande).

La plupart des langages de programmation ont un autre niveau de packaging au-delà des applications exécutables. Des objets de bibliothèque jouent ce rôle sur l’iSeries. Les bibliothèques iSeries peuvent présenter différentes structures : tout le contenu d’une bibliothèque, une bibliothèque par application, toutes les définitions de bases de données dans une bibliothèque, et tous les programmes dans une bibliothèque différente. Les variantes sont pratiquement infinies.

La structure choisie pour les bibliothèques n’aura pas de conséquence majeure sur la conception d’applications dans un environnement de développement iSeries classique. Cependant, dès que l’on commence à incorporer du code qui fonctionne sur d’autres platesformes ou du code écrit à l’aide de langages pour plates-formes hétérogènes, comme SQL et Java, la prise en compte des listes de bibliothèques est limitée. Ainsi, SQL ne peut bénéficier des listes de bibliothèques que si l’on utilise le nommage de systèmes. On le voit, le mode de distribution du code au travers des bibliothèques devient plus important au fur et à mesure que l’horizon applicatif s’élargit.

Enfin, à propos du packaging, bien que les segments de code réutilisables, comme les procédures ILE RPG présentent beaucoup d’avantages, il ne faut pas pour autant négliger les mérites de moyens plus traditionnels comme les sousroutines et /COPY. Par exemple, il faut inclure des prototypes de procédures ILE RPG dans chaque programme qui utilise une procédure, et l’utilisation de /COPY est un bon moyen de maintenir le code de prototype dans un lieu unique. Pour plus de détails sur toutes les techniques de modularisation RPG exposées ici et des indications sur le moment opportun pour utiliser chaque stratégie, voir l’article en deux parties « Maîtriser les modules » (décembre 2004 et février 2005, ou www.itpro.fr Club Abonnés).