2.9 KiB
SOA
Service Oriented Architecture
HistoriqueHistorique
jusqu 90, les trucs étaient sur des gros serveurs (mainframe) en arhci monolothiques
en 90 est apparu le client/serveur avec l'appartition / la démocratisation des PC Puis distribué années 2000
Client / serveur
soit cnetré sur le client, soit centré su rle servur. Schéma sur PDF. Réseau entre es dux, l'un a plus de charge que l'autre. Le problèm : dépendances, biblioth_ques, api à importer...
Application web
Très ouvertes/ fcails à déplyer
cloud computing
Location d'ordi pour que les autres se dédouanent de la gestion
Ca a été très centralisé, puis moins avec client/serveur, puis on es tpassé au distribué
Les architectures de service
Principaux composants
Un service : un composant, une fonctionnalité d'un SI mis à disposition ds clients. Il fonctionne ne boite noire : on se fout de savoir comment il fonctionne. On le vuet performant, robuste, et indépendant de notre contexte (n tant que client)
solution métier
L'utilisateur ne s'intéresse pas au service mais à l'applicatio qui utilise ce service. On en a deux la backend et la frontend. Tout ça compose la "solution métier"
SOA 1.0
né dnas les années 2000. Première génération Né d'un besoin fort de se connecter ua beosin.
avantage : ouverture du SI inconvénient : les dev ont pris le monoplithe tel quel et mis des servics autour : pas de robustesse et de performance
SOA 2.0
architecture microservice
ce qui change, c'est la façon de voir son entreprise : chaque section devient un service. Vision "verticale"
inconvénient : le microservice a une durée de vie courte. Ca change très vite, faut pouvoir suivre la cadence. plein de services dans des technos différentes,
SOA 3.0
devient un truc de mode : tout le monde en veut et veut un truc multi partenaires Avec l'essort des objets connectés on évolue vers des archis plus reactives et besoin de temps réel
on rajoute par rapport à la précédent eune couche IoT, qui communiquera directement avec les obj connectés, et plusieurs gestionnaires, APÏ pour interface rles différents servies entre eux, ainsi qu'un gestionnaire d'PAI.
on a encore deux parties front/back
Archi plus complexe car besoins ont évolué
Idées reçues
SOA liée à techno ou protocole particuliers : ** FAUX** Lié à un outil : FAUX (si on utilise par exemple un esp, un répartisseur de mssage utilisé par quelqu'un d'autre en SOA, il ne sera pas forcément en SOA) SOA n'est pas égal à web service ou micro service Un web service n'est pas non plus un SOA SOA se réfléchi, c'est pas adapté à tout
Conclusion
SOA c'est un esemble de concepts et de pratqiues qui permettent de mettre en place une architecture. Nécessite d eraisonner sur archi de l'application, la méthodologie mise ne oeuvre. Et tout organisation n'est pas adapté au SOA