Rechercher

Les Quatre Styles d’architectures d’intégration d’applications

Les systèmes d'entreprise ne sont pas autonomes. Ils s'intègrent à de nombreux autres systèmes d'entreprise pour fournir des services essentiels aux clients. Il existe un certain nombre de styles d'intégration différents, comme



#1 Base de données partagée où plusieurs applications partagent la même base de données. Cette approche est simple mais présente des inconvénients tels que :


1) Plus susceptibles de rencontrer des problèmes de performances, de goulots d'étranglement et d'évolution. Les bases de données SQL ne sont pas vraiment évolutives.


2) Tous les ajustements (par exemple, la mise à niveau de la version) de la base de données pour une application auront des effets secondaires sur d’autres applications. Complique l'indexation et le partitionnement des tables car différentes applications ont des besoins différents.


3) Problèmes de concurrence et de synchronisation car il pourrait exister des dépendances chronologiques entre les processus partageant la base de données. Qu'en est-il des différentes applications travaillant simultanément sur les mêmes tables? Que se passe-t-il si une application modifie d’abord les données qui auraient dû être modifiées par une autre application?



2 # Transfert de fichiers par batches

Les applications disposeront de leurs propres bases de données et les données d’une application seront copiées dans la base de données d’une autre application via des batches nocturnes ou à intervalles réguliers avec un processus ETL (par exemple, Extract Transform & Load). Extraction d’une base de données et transformation en fichiers de flux (délimités au format CSV ou TAB, par exemple). Ces fichiers sont ensuite chargés ou acquis dans la base de données d’une autre application.


Pourquoi faire des copies des données? Une application de commande en ligne nécessite des informations sur le client ou le produit. Une seule application sera la source de la vérité et pourra créer ou modifier les données. Les autres applications utiliseront les données en lecture seule.


Un exemple industriel typique serait une application de commande en ligne basée sur Java & Spring nécessitant des données d'un système mainframe. Vous pouvez également importer des données d'organisations externes.


Les inconvénients de l'ETL sont:

1) Pas idéal pour un accès aux données en temps quasi réel (NRT) ou à la demande qui nécessite une réponse rapide.


2) Non seulement prend beaucoup de considérations et de temps à développer, mais il est également difficile de suivre les demandes de changement.


3 # Invocation de procédures distantes (appels RPC)

RPC est une communication inter-processus qui permet à un programme d'appeler directement des procédures d'un autre programme sur le même ordinateur ou sur un autre ordinateur du réseau. Spring prend en charge la communication inter-processus (ou communication à distance) via les services Web JAX-WS (SOAP) et JAX-RS (RESTful) qui sont les successeurs de JAX-RPC, RMI, Invoker HTTP de Spring, Hessian et Burlap. RESTful est plus populaire et omniprésent.


Par exemple: les données JSON ou XML peuvent être échangées entre App1 et App2. App1 et App2 peuvent être implémentés dans différentes langage en tant que services Web RESTful car ils sont indépendants du langage.


App1 (REST client - consumer) –> JSON –> App2 (REST service provider)


#4 Messaerie via MOMs (Message Oriented Middlewares)

Il s’agit également d’une communication inter-processus (ou communication à distance) par laquelle l’échange de messages de manière asynchrone via un middleware orienté message (MOM). MOM est utile pour la messagerie asynchrone requête-réponse ou publication-abonnement car une demande peut prendre beaucoup de temps à se terminer ou plusieurs parties peuvent être intéressées par le message actuel.


Spring prend en charge JMS et AMQP.


Un exemple concret est celui d’une application Web utilisée pour passer une commande ou une transaction pour un client particulier. Votre application prenant les commandes en ligne l'enregistre dans une base de données et publie un message dans une file d'attente JMS. Une autre application écoutant la file d'attente répondra à l'événement en prenant la commande, puis en plaçant cette commande auprès d'un autre système tiers (par exemple, un système de négociation). La troisième application peut être chargée de prendre la commande et d’envoyer des courriels pour informer sur le statut de la commande tels que la confirmation et l’achèvement. Tous ces événements se déroulent de manière asynchrone.



0 vue

#Suivez-Nous

+213560764957

©2020 by DIGITAL GROWING.