82 lines
2.9 KiB
Markdown
82 lines
2.9 KiB
Markdown
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
|