Tâche: Exécuter une exploration de la faisabilité technique détaillée
Cette tâche explique comment développer le bien-fondé de la conception architecturale, pour une solution SOA, en fonction des exigences architecturales et du profil de risque existants.
Objet

Afin de synthétiser une solution exemple répondant aux exigences architecturales essentielles, cet exemple doit être limité, comme par exemple :

  • la solution obtenue peut simplement être conceptuelle,
  • la solution obtenue peut uniquement illustrer des aspects critiques de l'ensemble des exigences.
Relations
RôlesPrincipal: Complémentaire: Auxiliaire:
EntréesObligatoire: Facultatif:
  • Aucun
Externe:
  • Aucun
Sorties
Description principale

Le bien-fondé de la conception architecturale extrait ses entrées principalement de la Tâche : Analyse d'actifs existants et prend en compte le Concept : Portefeuille de services défini par l'Activité : Effectuer la spécification de service.

En outre, pendant la gestion d'applications existantes, les éléments suivants doivent être examinés et pris en compte :

  • Traitement des exceptions : Il faut comprendre le fonctionnement actuel du traitement des exceptions. Dans un traitement par lots, lorsqu'une exception se produit, le programme est interrompu (se termine anormalement) et produit un cliché du processus core. Le programmeur doit examiner le cliché du processus core et déterminer les mesures à prendre. Cela peut ne pas être acceptable. On peut envisager les mesures à prendre, par exemple, pour intégrer ces mesures à une infrastructure préfabriquée de traitement des exceptions.
  • Distribution des processus et des données : Il convient d'examiner où les données et les processus sont exécutés. Une application CICS s'exécutant sur une machine peut envoyer une requête vers une autre machine (mécanisme également appelé accès aux ressources éloignées sous CICS) ou des données d'appel distantes sur une autre machine. Il est possible d'envisager d'aller directement (JDBC vers BD) sur la machine distante où s'exécutent les processus ou les données, plutôt que d'utiliser le connecteur allant de JDBC à la base de données.
  • Disponibilité des données : Si un fichier client dans VSAM requiert, par exemple, une fenêtre de maintenance pendant 4 heures, il est impossible de prendre en charge un service client 24 heures sur 24 et 7 jours sur 7. Il convient alors d'envisager une nouvelle solution de stockage.
  • Autorisation/Authentification : De nombreuses applications existantes contiennent les mécanismes d'authentification et d'autorisation dans leur code d'application. Cela requiert la migration de la gestion des accès utilisateur vers un environnement géré fédéré, pris en charge par les meilleures pratiques.
  • Délais de transfert : Généralement des programmes de traitement par lots s'exécutant une fois par jour, pendant la nuit. Si le programme doit être exécuté plus fréquemment, il convient alors de modifier la planification afin d'agir sur la fréquence.

La liste ci-dessus n'est pas exhaustive ; elle n'est fournie qu'à titre indicatif.

Exemple

Dans l'exemple de location de véhicules, la réalisation des services devra tenir compte des exigences suivantes :

  • Liaison transparente entre le client-serveur distant, les applications de poste de travail et les applications IMS grand système.
  • Eliminer la "capture de données d'écran" du point de vue de l'application distante. Il s'agit d'éliminer le besoin de modifier le traitement d'application à distance, simplement parce qu'un message est ajouté sur un écran ou qu'une zone est déplacée sur l'écran.
  • Support des messages entrants et sortants des applications IMS qui sont dans un format fixe et prédéfini.
  • Le traitement lié au formatage de messages doit être transparent pour l'application IMS afin que le temps nécessaire au développement et au test de nouvelles applications distantes soit réduit considérablement.
  • Prendre en charge l'intégration de nouvelles fonctions d'application IMS et de nouvelles zones de données sur des systèmes distants au moment opportun, c'est-à-dire réduire la durée d'optimisation des systèmes existants.

Les éléments de ces décisions et considérations liées à la faisabilité technique se rapportent aux aspects fonctionnels et opérationnels de l'architecture. Pour répondre aux exigences ci-dessus, l'approche suivante a été appliquée :

  • Courtier de messages/courtier d'intégration pour gérer le formatage des messages depuis et vers les applications IMS. Le courtier de messages effectue les fonctions suivantes :
    • Reformater les messages entrants (du code XML au format de longueur fixe) en un format prédéfini, acceptable par les applications IMS grand système.
    • Reformater (du format à longueur fixe vers le code XML) des réponses en sortie IMS grand système vers un format de mot clé IMF devant être traité par l'application émettrice initiale.
    • Interroger un message entrant afin de déterminer s'il est au format IMF en vérifiant l'en-tête de message qui précède la charge de données. L'en-tête est dans un format positionnel et contient plusieurs informations clés, nécessaires au traitement correct par IMF.
    • Effectue le routage et la transformation en fonction du contenu de l'en-tête de message et du code de transaction IMS. Ce code de transaction IMS est requis pour exécuter la transaction appropriée dans le système IMS Mainframe.
  • Pont IMS-MQ jouant le rôle d'un programme de synchronisation entre le courtier de messages et le système IMS.

L'utilisation du courtier de messages/d'intégration réduit fortement ou élimine la nécessité de personnaliser chaque application IMS afin de gérer des requêtes de transaction provenant de divers systèmes distants. Etant donné que la majeur partie du traitement liée au formatage de message est transparente pour l'application IMS, le temps nécessaire au développement et au test de nouvelles applications distantes est considérablement réduit. En outre, de nouvelles fonctions d'application IMS et de nouvelles zones de données deviennent disponibles sur des systèmes distants au moment opportun, ce qui réduit la durée d'optimisation des systèmes existants. On obtient ainsi un couplage souple des applications, qui est l'un des principes de base de SOA.

Etapes
Choix d'une approche d'élaboration

Choisissez les techniques à utiliser pour construire le bien-fondé de la conception architecturale, par exemple :

  • Modélisation conceptuelle
  • Prototypage "rapide"
  • Simulation
  • Traduction automatique des spécifications en code
  • Spécifications "exécutables"
  • Construction de "tranches" comme prototypes (coupes verticales dans les couches)

L'architecte logiciel doit pouvoir raisonner sur ces modèles, lui permettant ainsi d'identifier des éléments à la fois en termes de problèmes et de solutions.

Choix des actifs et des technologies pour le bien-fondé de la conception architecturale

L'architecte du logiciel doit choisir, parmi les actifs et technologies identifiés dans la tâche Analyse architecturale, ceux qui devront être utilisés pour l'élaboration du bien-fondé de la conception architecturale.

Construire le bien-fondé de la conception architecturale

A l'aide des techniques sélectionnées pour l'élaboration, l'architecte du logiciel construit le bien-fondé de la conception architecturale à partir des actifs et technologies choisis pour répondre - en fonction du profil de risque du projet - aux exigences importantes pour l'architecture telles qu'elles ont été enregistrées dans les réalisations de cas d'utilisation standard, les modèles de déploiement et de conception de la vue d'ensemble, ainsi que le document d'architecture logicielle.



Propriétés
Prédécesseur
Plusieurs occurrences
Commandé par les événements
En cours
Facultatif
Planifié
Réitérable
Plus d'informations
Concepts