Dans cette figure (exemple non fictif ), les services applicatifs ne se trouvent pas au même endroit que les services et les données Legacy. Il est pourtant vital de distinguer nettement l’architecture et les composants d’intégration d’un côté et l’architecture d’application de l’autre.
Tous les services (qu’ils soient hérités ou développés) doivent être regroupés au même endroit que les données Legacy. On retrouve également souvent une organisation désordonnée dans le cas d’applications composites, comme illustré ci-dessous.
 

 
La partie inférieure de la figure est tout à fait acceptable, mais la partie supérieure semble indiquer que les applications existantes ne peuvent pas implémenter de processus métier, ce qui ne peut pas fonctionner.
Autre sujet de préoccupation, le fait que le flux de travail BPEL4WS (BPEL pour les services Web) soit construit directement à partir d’autres services Web. Cette structure implique un couplage serré entre le BPEL (Business Process Execution Language ) et toute autre application, ce qui va à l’encontre des objectifs de couplage lâche.
Il faut donc intégrer le BPEL en couplage lâche, comme dans le cas de toute autre application. Si les interfaces de services Web BPEL possèdent déjà une granularité forte et sont exécutées sur les protocoles sélectionnés, il suffit d’appliquer une transformation sémantique au bon niveau. Selon qu’un courtier est utilisé ou non, la transformation depuis et vers les services BPEL est exécutée au niveau du courtier ou du domaine BPEL.
Maintenant que nous avons établi la nécessité de maintenir une distinction entre l’architecture d’application et l’architecture d’intégration, nous devons nous pencher sur la question du droit de propriété.

Règle 2 : le service appartient à l’application avec laquelle il interagit

La seconde règle concerne le droit de propriété sur les services. Tout d’abord, l’adaptateur syntaxique (l’adaptateur et le flux spécifique à l’application) appartient toujours à l’application avec laquelle il interagit, comme illustré ci-dessous.
 

 
L’attribution correcte des droits de propriété est un élément clé pour l’application du couplage lâche, quel que soit le type de déploiement de l’intégration.
Les adaptateurs syntaxiques et leurs règles appartiennent aux applications avec lesquelles ils interagissent. Les adaptateurs sémantiques appartiennent à l’entreprise à un niveau plus élevé, ce qui prouve que l’intégration est une question d’ordre organisationnel plus que technique.
C’est la raison pour laquelle l’orientation de services est si importante : elle autorise une attribution correcte des droits de propriété et une plus grande flexibilité.
Cette approche met l’accent sur une meilleure compréhension du système. Cependant, il ne faut pas verser dans l’excès d’analyse.

Règle 3 : seuls les doublons doivent être analysés

La troisième règle met en garde contre le risque d’une « paralysie de l’analyse » lors de la conception et de l’implémentation de l’architecture.
Ce risque est particulièrement visible dans les architectures d’entrepôt de données par exemple. Il n’est pas possible, et pas souhaitable, de connaître tous les besoins d’intégration sans exception avant le lancement du processus d’intégration. Cela signifie que même s’il existe des messages « pivots » associés à des services métier réutilisables, ceux-ci peuvent être « cachés » dans l’architecture et découverts uniquement au fil du temps.
 

 
La figure ci-dessus illustre les résultats d’une enquête réalisée par un fournisseur de données du marché international sur plusieurs années, portant sur les éléments de données définis pour ses rapports de solvabilité dans le monde entier. 64 000 éléments ont été trouvés. 4 000 étaient des éléments uniques (en moyenne, chaque élément a été défini 16 fois) et parmi ces 4 000 éléments, 200 seulement étaient pertinents.
Pourtant, 90 % de l’activité dépendait uniquement de 80 éléments de données. Conclusion de notre exemple : une analyse des doublons ascendante aurait permis de découvrir, et de gérer ces 80 éléments de données, alors qu’une analyse descendante est beaucoup plus coûteuse puisqu’elle induit l’inventaire de 64 000 éléments.
Ce point a des implications directes pour toutes les entreprises ou normes établies, comme illustré ci-dessous. L’exemple proposé porte sur une société d’assurance et la norme ACORD.
L’implémentation d’ACORD comme norme de messagerie interne constituerait une mesure excessive (« overkill »)pour tous les éléments ACORD qui ne sont pas en cours d’utilisation dans l’entreprise. Cela constituerait parallèlement une mesure insuffisante (« underkill ») pour les messages et les éléments de l’entreprise qui ne sont pas définis dans ACORD.
 

 
Une fois que l’analyse des doublons plutôt que de la totalité des éléments a été correctement effectuée, il faut étudier la manière la plus adéquate d’utiliser les services pour intégrer les applications.

Règle 4 : trois flux et deux transformations sont nécessaires

Cette règle va nous permettre d’analyser les caractéristiques dont les services doivent être dotés pour intégrer les applications :

• 1. granularité forte : le service est un événement métier et non technique.
• 2. couplage lâche : la modification d’un service ne doit pas affecter les autres services.
• 3. réutilisabilité : une fois implémenté, un service ne doit pas avoir besoin d’être réimplémenté pour une autre utilisation.

Pour répondre à ces trois exigences, vous devez utiliser trois flux et deux transformations.
Les services sont créés dans la couche externe (voir la règle 2), comme illustré ci-dessous.
 

 
Les services sont créés dans la couche externe. Qui que soit l’auteur des services, ceux-ci appartiennent toujours à l’application.
L’association d’un jeu d’adaptateurs et d’un flux assure l’implémentation de la granularité adéquate. Il s’agit là du premier des trois flux nécessaires. Les deux autres sont illustrés dans les parties sur le couplage lâche et la réutilisabilité ci-dessous.
La couche suivante implémente le couplage lâche, comme indiqué ci-dessous.
 

 
Il s’agit de la première couche appartenant au domaine (ou à l’architecture). Cette deuxième étape implique deux transformations sémantiques, depuis et vers un format canonique pour chaque cible.
Vous obtenez ainsi un couplage lâche, puisque les changements apportés aux applications sont absorbés par les transformations.
Dernière étape, la réutilisabilité est garantie par le flux central (le troisième flux) comme illustré ci-dessous.
 

 
Le flux central est écrit dans l’espace de nom canonique et permet le routage et l’enrichissement des messages si nécessaire. Cette couche sera par la suite en mesure de mapper les identifiants d’une application à ceux d’une autre application. Pour cela, un niveau raisonnable d’intégration de données est requis.
Grâce à cette approche passant par l’utilisation de trois flux et de deux transformations, nous pouvons maintenant examiner la meilleure utilisation possible des transactions dans le contexte de l’intégration.

Règle 5 : l’exécution d’une opération nécessite trois transactions

L’objet de cette règle est de démontrer que, contrairement à l’idée communément admise, l’intégration n’est pas une simple variante de; l’appel de procédure à distance. Il existe des solutions basées sur un middleware orienté message (MOM) pour la gestion de cet aspect.
Si une requête QUEUEPUT est lancée dans une transaction, le message n’est réellement envoyé que lorsque la transaction est validée. Ainsi, il n’est pas possible de lancer une requête QUEUEPUT dans une transaction et d’attendre une réponse.
L’envoi d’un message vers une autre application, puis la gestion de la réponse nécessitent trois transactions :

• 1. pour générer le message à envoyer ;
• 2. pour traiter le message réceptionné ;
• 3. pour gérer le message transmis à la cible.

Il s’agit du modèle à trois transactions, comme illustré ci-dessous.
 

 
La première transaction permet de lire et de retirer le message d’une file d’attente et de l’écrire dans une autre.
 

 
La seconde transaction est alors exécutée dans l’autre application.
Celle-ci lit le message envoyé et écrit un nouveau message. Ce nouveau message n’est pas lié à celui qui a été lu.
 

 
Enfin, la première application lit le message envoyé par la deuxième application et l’associe à sa base de données afin de terminer le traitement. Cette méthode est utilisée par exemple par les modules de gestion du mode de transfert asynchrone.

Recommandations

Les recommandations suivantes reposent sur les règles que nous venons d’étudier :

• considérez les flux de travail des processus métier comme des applications, non comme une méthode d’intégration.
  Lorsqu’un nombre important de services est disponible via des canaux et des concentrateurs, de nouvelles applications peuvent être créées, capitalisant sur ces services. Une approche par flux de travail est adaptée pour de telles applications. Notons toutefois que les applications sont nouvelles et connectées en couplage lâche aux applications existantes comme c’est le cas pour toute autre application. L’intégration porte non pas sur la création de nouvelles applications, mais sur la connexion des applications existantes.
• les adaptateurs doivent appartenir aux instances applicatives avec lesquelles ils interagissent. Même si les premiers adaptateurs sont créés de manière centrale, chaque composant syntaxique doit être attribué à l’application avec laquelle il interagit, de façon à définir une appartenance.
  Ainsi, les changements applicatifs seront répercutés sur les adaptateurs.
• l’intégration doit toujours être effectuée en couplage lâche.
• les applications doivent être connectées en couplage lâche pour que l’intégration soit évolutive. Si certains services et canaux sont connectés en couplage serré, les coûts d’intégration se révéleront exorbitants avec le temps.
• adoptez un jeu standard d’en-têtes SOAP pour les messages internes. Un accord sur les en-têtes sera par la suite défini, mais dans un premier temps, nous recommandons l’usage d’en-têtes WS-RM (Web Services Reliable Messaging) en interne. L’interopérabilité des services Web est l’élément clé pour le suivi des en-têtes standard.
• utilisez les normes externes comme bibliothèque type plutôt que comme messages pour une utilisation interne. Il se peut que cette recommandation aille à l’encontre de l’approche établie par nombre d’entreprises. La normalisation d’un jeu de messages est une approche trop stricte pour un usage interne. De manière générale, une norme externe couvrira plus que les seules tâches d’une entreprise (mesure excessive) ou ne couvrira que certaines tâches (mesure inadéquate).
• utilisez des messages standard pour les communications externes, mais pas internes. Les messages standard sont toutefois appropriés pour les communications B2B s’il n’existe aucun niveau supérieur de concentrateur. Cela peut être le cas entre les domaines d’une entreprise, ou entre une entreprise et ses clients, ses fournisseurs et ses partenaires.
• chaque intégration doit comprendre trois flux : un pour la source, un pour la cible et le dernier pour le message intermédiaire. Ce modèle permet d’assurer couplage lâche et évolutivité, car le routage, la sémantique et les règles non spécifiques à une application sont traités hors de l’application, alors que l’enrichissement et les types de données spécifiques à l’application sont traités dans l’application.
• utilisez des flux d’intégration pour les adaptateurs (source et cible) ainsi que pour le concentrateur (intermédiaire). Les flux sont conçus à cette fin.
• utilisez une panoplie de modèles de déploiement (multilatéral, bilatéral et monolithique) au fur et à mesure du développement de l’intégration. La rentabilité de l’intégration sera ainsi assurée.
• associez chaque domaine à une « face » sur laquelle les canaux sont implémentés. Chaque domaine peut ainsi configurer tout service sur n’importe quel canal de manière souple.