Série de documents sur la Stratégie d’architecture axée sur le service - Gouvernement du Canada - Guide d’introduction

4.0 - Les trois couches de l'AAS du GC

L'AAS du GC est composée de trois couches distinctes dans un contexte de conception de programmes/activités (soit la quatrième couche virtuelle). Ces trois couches correspondent à une approche dûment reconnue dans l'industrie, en ce qui a trait à la structuration en couches de toute architecture des TI. La grande différence réside dans le fait qu'on a choisi l'encapsulation et le nommage des couches pour que le nom attribué à chacune corresponde exactement à ce qu'elle offre et représente, et soit le reflet fidèle des motifs qui nous ont poussés à agir de la sorte.

Figure 3 - Les trois couches de l'AAS du GC

4.1 - Les avantages d'une structuration en couches

L'AAS du GC est structurée en couches pour les raisons bien connues énumérées ci-dessous.

• Il est plus facile d'examiner une couche à la fois, en l'envisageant comme un tout, plutôt que d'essayer de comprendre l'architecture au complet, de haut en bas.
• Le lien de dépendance entre les couches est réduit au minimum et les interconnexions entre entités sont présentées sous forme d'un système administrable.
• D'ordinaire, les normes sont intégrées aux interfaces des couches pour qu'un nombre maximum de consommateurs puissent utiliser les services offerts. Le modèle de référence d'interconnexion de systèmes ouverts est souvent cité en exemple.
• À mesure que l'on passe à travers les différentes couches (ou pyramide, si vous préférez), le niveau d'abstraction augmente, les détails et le niveau de complexité s'estompent, ouvrant la voie à la conceptualisation et à la résolution de problèmes de plus haut niveau.
• Une fois les normes bien établies, les couches peuvent être remplacées l'une par l'autre, en collaboration avec d'autres fournisseurs. Par exemple, dans le modèle de référence OSI, il existe une multitude de protocoles de communication TCP/IP parmi lesquels faire un choix.

En dernier lieu, comme c'est le cas pour n'importe quel immeuble, dès qu'un étage est construit, il est normalement plus facile d'y ajouter un autre étage (si cela a du sens, bien entendu).

4.2 - Les différentes couches

On a longuement réfléchi à la question suivante : « Pourquoi faut-il trois couches pour définir l'AAS du GC »? La réponse est multiple, à savoir : 

• Chaque couche assure les services requis par rapport à la couche au-dessus
• Chaque couche se définit par elle-même
• Chaque couche donne corps à un concept architectural ou technologique en particulier

L'AAS du GC comporte donc les trois couches suivantes : 

Couche 1 -  - Architecture à composantes technologiques

Couche 2 -  - Architecture d'échange de services

Couche 3 -  - Architecture d'application de gestion

Chaque couche fera maintenant l'objet d'une discussion.

4.2.1 - Architecture à composantes technologiques - Couche 1

Figure 4 - Architecture à composantes technologiques (ACT) - Couche 1 de l'AAS du GC

L'architecture à composantes technologiques (ACT) englobe des produits et des services, de même que les architectures de soutien respectives, propres à un fournisseur et elle fournit la liste des composantes de plus bas niveau (soit les composantes primaires) pouvant être réutilisées telles quelles dans toute l'administration fédérale. Autrement dit, vous pouvez vous en servir  sans les modifier. Toutefois, il ne s'agit pas d'une utilisation partielle, et il n'est pas question non plus d'en modifier le comportement choisi. À priori, il s'agit donc d'une boîte noire qui fait ce qu'elle doit faire. Cette couche renferme tout le matériel et les logiciels nécessaires à la présentation des composantes des modules (sans égard à la complexité et à la taille) que les fournisseurs ont à offrir. En voice des exemples : le langage Java ou une carte vidéo. Elles sont ce qu'elles sont, ni plus, ni moins. Vous les utilisez telles quelles, et n'avez pas vraiment la possibilité de les modifier, sans demander au préalable l'autorisation du fournisseur. Il s'agit de produits indépendants et sans interaction entre eux. La notion d'interopérabilité au niveau de cette couche n'est pas obligatoire étant donné que chaque fournisseur a le droit d'utiliser des normes appropriées à sa mise en service. Cela ne signifie pas toutefois que les fournisseurs ne pourraient pas et ne devraient pas essayer d'interopérer directement entre eux, et le fait est que certains y parviennent; toutefois, il ne s'agit pas d'une exigence du gouvernement du Canada.

Un des éléments importants au niveau de cette couche est la granularité. Autrement dit, il s'agit de la taille élémentaire des ensembles de données mis au point par le vendeur/fournisseur. Plus le degré de granularité est élevé, plus il y a de possibilités de personnaliser un système, car le nombre d'éléments (objets, informations ou données) parmi lesquels choisir est plus élevé.

Les applications classiques autonomes incorporées directement dans les plateformes des fournisseurs font également partie de l'ACT. Ces applications maison sont sur un pied d'égalité avec les produits du fournisseur car tout ce qui les différencie, finalement, c'est celui ou celle qui est responsable du développement. Bien entendu, les produits d'infrastructure offerts par les fournisseurs s'intègrent normalement plus facilement dans le modèle axé sur le service, mais grâce aux adaptateurs et aux techniques de codage personnalisé disponibles de nos jours, ces applications ne sont pas en reste.

4.2.2  - Architecture d'échange de services - Couche 2

Figure 5 - Architecture d'échange de services (AES)  -  Couche 2 de l'AAS du GC

L'architecture d'échange de services (AES) est la couche intermédiaire qui appuie l'application personnalisée d'un élément de la couche 1 (ACT) à ce que l'on pourrait appeler un service d'infrastructure ou i-service. Par exemple, la gestion des tâches et l'établissement du calendrier sont des éléments du courrier électronique que l'on peut représenter, traiter et utiliser séparément. Habituellement, ce que l'on constate, c'est qu'un modèle de service normalisé est mis de l'avant de manière à « emballer » un service propre à un fournisseur pour le rendre conforme aux normes du GC. Ces services d'infrastructure serviraient alors de bloc fonctionnel sur lequel d'autres services thématiques à valeur ajoutée (p. ex. des services de voyages ou de santé) viendraient se greffer.

Les services administratifs automatisés, connus également sous le nom de services mixtes dans le jargon de l'industrie des TI, sont des services intégrés à d'autres services et ils représentent le volet clé à valeur ajoutée de l'AES. Règle générale, les services mixtes permettent d'exécuter des fonctions ou des processus de gestion clés qui font partie d'une application plus évoluée ou d'un mécanisme de prestation des programmes. Le consommateur typique de ce type de service plus évolué peut être d'autres services internes, des applications ou des services externes à l'intention des citoyens ou des entreprises. 

Peu importe l'utilisation, la nature récurrente des services, c.-à-d. lorsqu'ils peuvent s'appeler eux-mêmes, ouvre la porte à la complexité des programmes, lorsque nécessaire, ou à la simplicité, lorsque souhaitable. La Figure 5 a été réduite à sa plus simple expression : on y voit une seule et unique couche mixte faisant référence aux services administratifs automatisés, quoique un service mixte puisse parfois en englober d'autres, de manière plus ou moins approfondie.

Fait important à signaler, pour cette couche, on y fait la distinction entre les services offerts par le biais d'interfaces exclusives ou d'application industrielle et les services offerts par le biais d'interfaces approuvées dans toute l'administration fédérale. Au nombre des interfaces de l'industrie, mentionnons le langage ebXML, les services Web et l'IAE traditionnelle (Intégration d'application d'entreprise). Un exemple d'interface approuvée à l'échelle de l'administration fédérale pourrait être le langage XML utilisé par le courtier de services de la Voie de communication protégée. Lorsqu'il est inutile d'adapter une norme de l'industrie, la norme approuvée par le GC pourrait bien être la même. Un bon exemple est le fait que le GC a choisi d'adopter l'interface POP3 pour que la clientèle puisse communiquer par courriel avec les nombreux serveurs du GC.

La Figure 6 - Anneau des services communs de l'ACT vers l'AES illustre des fournisseurs qui présentent une interface en tant que composante de l'ACT. Même si de nombreux fournisseurs ont de plus en plus tendance à s'éloigner des interfaces exclusives, ce qui est déjà en soi une bonne nouvelle, pour être considérée comme étant un i-service dans l'AES, toute fonctionnalité composante de l'ACT doit être offerte par le biais d'une interface approuvée à l'échelle du GC.

Dans la couche AES, l'AAS du GC peut simplement intégrer les interfaces de l'industrie suffisamment larges pour permettre à tous les ministères de bénéficier de l'interopérabilité au moment de choisir les services dont ils ont besoin auprès des fournisseurs et des sources. Dans d'autres cas, les composantes et les interfaces de l'AAS du GC seront plutôt « mises en forme » à l'aide de normes définies à l'interne et à la grandeur du GC. Cela aura pour effet d'isoler les ministères des véritables fournisseurs de services au niveau de l'ACT et de rehausser le degré d'autonomie du fournisseur.

Lorsqu'une telle mise en forme se produit, l'en-tête de message (en tant que partie intégrante de l'intervention sur machine) pourrait être potentiellement considéré au même titre que le contenu du message (appelé aussi charge utile). Dans certains cas, l'emballage ou la mise en forme ne servira qu'à isoler l'en-tête. Dans d'autres cas, l'interface visera également la charge utile.

Figure 6 - Anneau des services communs de l'ACT vers l'AES

4.2.3 - Architecture d'application de gestion - Couche 3

Figure 7 - Architecture d'application de gestion (AAG) - Couche 3 de l'AAS du GC

L'architecture d'application de gestion (AAG) est au sommet de la pyramide. Fondamentalement, elle permet aux entrepreneurs de rassembler un ensemble de services du GC (ou non) dans le cadre d'une nouvelle proposition sur la valeur. Règle générale, la portée d'une application est assez large et cette dernière peut être développée de manière à englober un peu plus ou un peu moins de fonctionnalités, selon le temps qu'on a et les ressources disponibles. Des applications peuvent être créées par le biais d'un nouveau code, d'un code acquis ou d'un code existant recyclé. Par exemple, en reciblant des services ministériels et pangouvernementaux existants en matière de santé, on pourrait créer un service consultatif mixte en matière de santé et de voyage en temps réel et universel, y compris les rappels d'aliments, les avis sur la qualité de l'air et les renseignements médicaux à l'intention des voyageurs, le tout dans un guichet unique. Des services publics d'une telle ampleur auraient certainement des répercussions positives sur les services existants ou les nouveaux services envisagés dans les secteurs public et privé, selon les niveaux de service et les contrôles d'accès qui y sont associés.

En raison de leur nature même, les applications de l'AAG ne peuvent être « directement » réutilisées. Les utilisateurs de ces applications sont, en règle générale, des gens qui laissent entendre que l'AAG renferme les éléments qui permettent la prestation de services. Pour soutenir l'interopérabilité entre les applications de cette couche, ces dernières doivent faire appel aux services réunis dans l'Architecture d'échange de services (AES) où l'échange de renseignements est possible. Autrement dit, l'AAG correspond à la couche présentation, au même titre que toute logique d'interaction associée et autres aspects non réutilisables d'une application de gestion.

L'AAG est également décomposée en couches distinctes. Ces couches sont connectées par le biais d'un bus des services d'application (BSA), qui peut être exclusif et/ou local à l'application. Lorsqu'une interaction avec l'AES entre en ligne de compte, une interface des services intégrés (ISI) fournit le modèle normalisé nécessaire pour assurer les services externes.

Pour s'assurer que les composantes de niveau inférieur seront aussi réutilisables que possible, l'AAG conserve dans ses couches internes fonctionnelle et persistance les paramètres et les données spécifiques de ce secteur d'activités. Lorsqu'une fonction de la couche fonctionnelle devient une fonctionnalité commune à plusieurs secteurs d'activités, on peut alors envisager la faire passer vers l'AES et l'offrir à titre de nouveau service.   

Figure 8 - Couches internes et mécanismes de communication de l'AAG

Voici un bref aperçu des couches internes de l'AAG.

Couche présentation - Affichage du contenu, des messages-guides et des résultats dans l'appareil utilisé (p. ex. navigateur, cellulaire, PDA, écran 3270, etc.), y compris les fonctions de transformation pour appuyer les technologies d'accessibilité.

Couche interaction  - Concerne l'aide fournie à l'utilisateur final et la gestion de la saisie de données, des processus, et de l'interopérabilité entre les services (fonction de retour, fonction d'aide, menu des changements, etc.).

Couche fonctionnelle  Gestion de la logique d'ensemble et de la marche du travail d'une session. Englobe les modèles des processus de gestion qui permettent aux consommateurs et aux fournisseurs d'avoir une idée commune de chaque processus et de sélectionner des processus et des services en fonction des réponses fournies par le partenaire.

Couche objet - - Pour s'occuper de paramètres spécifiques à l'AAG, notamment la validation de données. Englobe des éléments conçus en conformité avec les normes du COI (p. ex. des entités définies selon les spécifications et les lignes directrices du UN\CEFACT - une application ISO 11179).

Couche persistance - Recherche et stockage d'informations pour assurer la continuité de la session, y compris des technologies telles une signature numérique et  le chiffrement, pour protéger l'intégrité des objets et des opérations électroniques entre participants, et conseils sur la façon de les sauvegarder.

L'AAG réunit un éventail d'applications, entre les applications spécialisées et les applications multifonctionnelles ou à usages multiples. L'AAG renferme également des applications uniques dans son sens le plus restreint, c.-à-d. qui concernent un seul secteur d'activités, un seul programme et même un seul ministère. Autrefois, à défaut d'un véritable service à la clientèle et en l'absence de normes bien définies, on avait tendance à privilégier des applications de plus en plus vastes, qui englobaient un large éventail de besoins du service. Ainsi, on s'assurait que tous les volets d'une solution envisagée pourraient interagir entre eux et former un tout.

L'AAS du GC aura pour résultat de favoriser l'émergence de plus petites applications, elles-mêmes mieux ciblées, dès que tous et chacun auront compris que projet (ou programme) et application ne font qu'un. Par exemple, dans la figure ci-dessus, il pourrait s'agir d'un projet consultatif en matière de santé et de voyage dont la principale réalisation se résumerait à l'application comme telle. Mais dans un monde où il est question de service à la clientèle, l'application sera plutôt synonyme de portefeuille ou série de composantes associées à la santé et au voyage, rassemblées dans un but bien précis, soit d'offrir un service de consultation global. Dans l'éventualité où les services sont réutilisés (ou modifiés), les applications de haut niveau pourront alors être recentrées.

Une grande partie de l'AAG est axée sur le temps consacré au développement de l'application, étant donné que les modèles et les schémas applicables peuvent être partagés et réutilisés par de nombreuses autres applications pendant la phase de développement. Ces modèles et ces schémas feront l'objet de discussions dans les documents à venir.

4.3 - Autre point de vue sur les trois (3) couches

L'AAS du GC peut être envisagée d'un autre point de vue, à l'intention de ceux et celles qui sont toujours un peu perplexes à ce sujet.

Figure 9 - Autre façon de voir l'AAS du GC

Même si la Figure 9 est plutôt schématique, cela ne signifie pas pour autant que l'ensemble de la conception et du développement se situe dans la couche supérieure. La conception des services se fait toujours dans la couche 2, mais on se consacre principalement, il est vrai, au temps d'exécution.