SOA : introduction générale

Mickaël BARON – 2010 (Rév. Janvier 2022)
mailto:[email protected] ou mailto:[email protected]
SOA
@mickaelbaron mickael-baron.fr
Introduction générale

View Slide

SOA - M. Baron - Page
mickael-baron.fr @mickaelbaron
2
Creative Commons
Contrat Paternité
Partage des Conditions Initiales à l'Identique
2.0 France
creativecommons.org/licenses/by-sa/2.0/fr
Licence

View Slide

3
À propos de l’auteur …
Mickaël BARON
Ingénieur de Recherche au LIAS
https://www.lias-lab.fr
Equipe : Ingénierie des Données et des Modèles
Responsable des plateformes logicielles, « coach » technique
Ancien responsable Java de Developpez.com (2011-2021)
Communauté Francophone dédiée au développement informatique
https://java.developpez.com
4 millions de visiteurs uniques et 12 millions de pages vues par mois
750 00 membres, 2000 forums et jusqu'à 5000 messages par jour
@mickaelbaron
mickael-baron.fr

View Slide

4
Plan du cours complet
Introduction SOA (pour introduire les services web)
Service web étendu (non présenté)
WSDL, SOAP, JAX-WS
Service web REST
REST, JAX-RS
Streaming HTTP
WebSocket, SSE, Tyrus, JAX-RS
Architecture microservice (pour l’application)
MicroProfile, Docker, RabbitMQ, Docker Compose, HaProxy

View Slide

Révision : quels changements ?
5
2019-2020
Ajout du Multi-Stage Build au niveau du cours outils Microservices
Création de versions « allégés » des supports de cours
Atelier sur le Streaming + WebSocket + SSE
2018-2019
Support de Java 8 à Java 11
Dépôt de tous les codes exemples sur Github
Dépôt de tous les tutoriels sur Github
Ajout d’un cours sur les technologies de « Streaming »
Ajout d’un cours sur le développement de WebSocket et SSE avec Java
2021-2022
Modification des exemples pour la transition de javax en jarkarta
Support minimum de Java 11

View Slide

6
Déroulement du cours : introduction générale
Pédagogie du cours
Des bulles d’aide tout au long du cours
Comprendre l’usage des services web dans une architecture SOA
Pas de technique pour l’instant
Pré-requis
Ingénierie des données
Langages de description : XML
Architectures multi-couches Jakarta EE (ex Java EE)
Ceci est une alerte
Ceci est une astuce

View Slide

7
Ressources : liens sur le Web
Billets issus de Blog
blog.engineering.publicissapient.fr/tag/soa
jee-bpel-soa.blogspot.com/search/label/web services
Articles
fr.wikipedia.org/wiki/Architecture_orientée_services
fr.wikipedia.org/wiki/Service_Web
www.journaldunet.com/solutions/dsi/article/air-france-klm-donne-
des-ailes-a-son-systeme-d-information-avec-la-soa.shtml
www.innoq.com/resources/ws-standards-poster/
Cours
www.javapassion.com/soaprogramming/SOAbasics.pdf
www.javapassion.com/webservices/WebServicesOverview.pdf

View Slide

8
Ressources : bibliothèque
SOA Principles of Service Design
Auteur : Thomas Erl
Éditeur : Prentice Hall Ptr
Edition : Juillet 2007 - 608 pages - ISBN : 0132344823
Le guide de l’architecte du SI
Auteur : Xavier Fournier-Morel, Pascal Grosjean, …
Éditeur : Dunod
Edition : Octobre 2006 - 302 pages - ISBN : 2100499726
Service-Oriented Architecture (SOA) : Concepts …
Auteur : Thomas Erl
Éditeur : Prentice Hall Ptr
Edition : Août 2005 - 792 pages - ISBN : 0131858580

View Slide

9
Vers une architecture SOA …
Une application distribuée est définie par un ensemble de
composants
Collaborent pour l’exécution de tâches communes
Distants géographiquement
Interconnectés via un réseau de communication
Hétérogènes
Solutions qui ont fait leur preuve
DCOM, CORBA, EJB, RMI, .Net Remoting…
Faiblesses de ces solutions
Format de représentation données spécifiques
Interopérabilité si les composants utilisent une solution unique
Protocole de transport spécifique nécessite une configuration réseau

View Slide

10
Evolution des applications
Exemple : application de co-voiturage
Architecture dite
« Monolithique »
Architecture
Orientée Service
Clients
Architecture
Microservice
Une grosse application
Clients
Base de
données
Interfaces
web
Connecteur
pour envoie SMS
API REST/SOAP
Connecteur pour
envoie EMAIL
Connecteur pour
paiement (Paypal)
Entreprise Service Bus
Une Application découpée par
des services techniques reliés
par un bus d’intégration
?
Connecteurs
pour SMS, EMAIL
et paiement
Interfaces web
Base de données
API REST/SOAP
Sera vu plus tard… trop
tôt pour un comparison

View Slide

11
SOA : généralités
SOA est l’acronyme de Service Oriented Architecture qui
est traduit comme « Architecture Orientée Service »
Le Service (ou Composant) désigne le fondement de ce
modèle d’interaction entre applications
Le paradigme SOA : Chercher, Publier et Consommer
Annuaire / Entrepôt
Consommateur
du Service
Fournisseur
du Service
Contrat
Publier
Fournisseur du Service
publie son service via le
contrat
1
Consommer
3
Consommateur du Service envoie des
messages (respect du contrat) au
fournisseur du Service
Chercher
Consommateur du
Service cherche un
service répondant à ces
exigences (Un contrat lui
est retourné) 2

View Slide

12
SOA : concepts de Service
Qu’est-ce qu’un service ?
Un Service est un composant logiciel distribué, exposant les fonctionnalités
à forte valeur ajoutée d’un domaine métier » [Publicis Sapient : 2009]
Huit aspects caractérisant un service
Contrat standardisé
Couplage lâche
Abstraction
Réutilisabilité
Autonomie
Sans état
Découvrabilité
Composabilité
Dans la suite nous
détaillons chaque
aspect d’un service

View Slide

13
Service : contrat standardisé
Contrat entre le fournisseur de service et le consommateur
de service
Trois types de contrat sont à distinguer
Lié à la syntaxe du service (opération, messages d’entrée, messages
de sortie…)
Lié à la sémantique du service (définition de règles et de contraintes
d’usage…)
Lié à la qualité de service (temps de réponse attendu, procédures en
cas de panne, temps de reprise après interruption…)
S’appuie sur des standards d’interopérabilité pour faciliter le
dialogue (exemple : WSDL)

View Slide

14
Service : couplage lâche
L’échange entre le fournisseur de service et le consommateur
doit se faire à travers des messages (couplage lâche vis-à-vis
de son environnement)
L’utilisation d’un service BUS/Orchestration évite que les
services aient besoin de connaître les autres services (remis
en cause dans l’architecture Microservice)
Services 1
Services 2
Services 3
Services 4
Services 5
Couplage fort Couplage lâche
Moteur Orchestration
Services 1 Services 2
Services 4
Services 3
1 2
3
4
Etudié dans le
dernier cours

View Slide

15
Service : abstraction
Le contrat du service ne doit contenir que les informations
pertinentes à son invocation
Fonctionnement du service dit en « boîte noire »
Seul le contrat exposé au consommateur du service est connu
Le fonctionnement interne du service ne doit pas être visible
Logique métier
Implémentation
Il est par conséquent important d’assurer la prédictabilité
d’un service
Pas de variation dans le comportement et dans la réponse d’un service
lors de la réception d’une requête

View Slide

16
Service : réutilisabilité / découvrabilité
Un service doit être accessible depuis un entrepôt ou un
annuaire pour faciliter sa découverte
Le fournisseur de services a la charge de déposer et de
mettre à jour ses services depuis l’annuaire
Le service est enrichi par un ensemble de métadonnées
pour faciliter la recherche du consommateur de services
S’appuie sur des standards (UDDI, ebXML)
D’après la gouvernance SOA
Un service est défini avec l’intention d’être réutilisé

View Slide

17
Service : autonomie / sans état
Un service doit disposer
de l’ensembles des informations nécessaires à son exécution
ne doit dépendre d’aucun service externe (couplage lâche)
Garantir l’autonomie d’un service permet de s’assurer de sa
prédictabilité
Un service doit être sans état de façon à minimiser la
consommation de ressources
Maintenance : rend complexe la composition de services
Performance : gourmand en ressources systèmes

View Slide

18
Service : composabilité
Un service doit fonctionner de manière modulaire et non pas
intégrée
Assurer la décomposition d’un service complexe en sous
services plus simples entre eux (garantie l’autonomie)
S’inscrire dans une logique de composition de services à
travers l’utilisation de l’orchestration (couplage lâche)
L’orchestration favorise l’indépendance des services et assure
que des services n’appellent pas directement d’autres
services

View Slide

19
Architecture Monolithique Versus SOA
q Intra-entreprise
q Limitée à un sous
ensemble de langages de
programmation
q Procédurale
q Protocole de transport
propriétaire
q Fortement couplé
q Traitement efficace
q Déploiement de l’ensemble
Architecture Monolithique
VS
Architecture Orientée Service
q Entre Entreprises
q Indépendance du langage
de programmation
q Pilotée par les messages
q Possibilité de choisir le
protocole de transport
q Faiblement couplé
q Traitement plus lourd
q Déploiement par partie

View Slide

20
Solutions pour une SOA
Plusieurs solutions technologiques sont adaptées pour
développer des architectures orientées services
Services web (SOAP et REST) et gRPC
Technologies « Push » (WebSocket et SSE)
Technologies Publish-Subscribe (RabbitMQ...)
Framework asynchrones (Vert.x, RxJava, Node.js…)
Des technologies spécifiques à des domaines
Internet of Things (MQTT)
OSGi (Equinox, Felix…)
Robotique (ROS)
Les technologies ne sont pas exclusives et peuvent être
utilisées conjointement

View Slide

21
Solutions pour une SOA : OSGi
Un point sur OSGi (Open Service Gateway Initiative)
Spécification définie par l’OSGi Alliance (www.osgi.org)
Longtemps exploité dans le monde de l’embarqué, utilisé dans les
serveurs (GlassFish, Spring DM) et application (Eclipse)
Concepts …
Dynamique : installé, arrêté, mise à jour, désinstallé
Découvrabilité : registre des services
Abstraction : gestion détaillée des classes à exposer
Pour aller plus loin : mickael-baron.fr/eclipse/intro-extensions

View Slide

22
Services web : réponses au SOA
Les services web sont basés sur les protocoles et les
langages du Web
HTTP, XML, TCP/IP pour la couche réseau
Ne nécessite pas une configuration réseau particulière
Les services web sont auto-suffisants puisqu’ils contiennent
toutes les informations à leurs utilisations
Chercher, publier et consommer
Annuaire, contrat de fonctionnement et un client pour les consommer
Les services web sont modulaires
Une application doit être décomposée en un ensemble de services
Utilisation d’une orchestration
Les services web peuvent être définis par des standards
OASIS, W3C, WS-I et IETF

View Slide

23
Services web : réponses au SOA
www.innoq.com/resources/ws-standards-poster

View Slide

24
Services web : technologies disponibles
Deux familles de services web se distinguent actuellement
Services web « étendus » ou « SOAP »
S’appuie sur des standards UDDI / WSDL / SOAP
Annuaire de services web : UDDI
Contrat : WSDL
Consommer : SOAP
Services web REST (Representational State Transfer)
Défini par la thèse de Roy Fielding en 2000
Utilise directement HTTP au lieu d’utiliser une enveloppe SOAP
URI est utilisée pour nommer et identifier une ressource
Méthodes HTTP (POST, GET, PUT et DELETE) sont utilisées pour
effectuer les opérations de base CRUD

View Slide

25
Services web étendus
Annuaire UDDI
Consommateur
du Service
Fournisseur
du Service
Chercher Publier
Consommer
Document WSDL est
utilisé comme contrat du
service web
WSDL
xmlns:hel="http://helloworldwebservice.lisi.ensma.fr/">

Messages SOAP est
envoyé pour consommer
(invoquer) un service web
Interrogation de l’annuaire
UDDI pour rechercher des
contrats WSDL suivant des
critères spécifiques
WSDL

View Slide

26
Services web étendus
Pile des standards pour les services web étendus
HTTP, SMTP, FTP, BEEP Transport
Message
SOAP 1.1 et 1.2
Découverte &
Description
WSDL, UDDI
Qualité de Service
Sécurité
WS-Security
Fiabilité
WS-RM
Transaction
WS-Transactions
Orchestration
Langages de Processus Métier (BPL)
BPEL

View Slide

27
Services web REST
Exploités pour les Architectures Orientées Données (DOA)
REST n’est pas un standard, il n’existe pas de spécification
W3C définissant une spécification
REST est un style d’architecture basé sur un mode de
compréhension du Web
REST s’appuie sur des standards du Web
Protocole HTTP
URLs
Formats de fichiers
Sécurisation via SSL

View Slide

28
Services web REST
Pile des protocoles et langages pour les services web REST
HTTP, FTP… Transport
Message
MIME Types (Text, JSON, XML…)
Découverte &
Description
WADL, ATOM, RAML, Swagger…
Qualité de Service /
Sécurité
Orchestration
Langages de Processus Métier (BPL)
BPEL
HTTP Basic, SSL / TLS

View Slide

29
Les fournisseurs de services web ?
Deux types de fournisseurs sont à distinguer
Fournisseurs de services web « Orientés Web » (public)
Fournisseurs de services web « Entreprise » (privé)
Les grands noms du Web sont présents et leurs services
sont accessibles
Amazon, eBay, Facebook, Flickr, Google, Instagram, Twitter,
Meteo France, Microsoft…
Oui mais …
Pratiquement tous les fournisseurs de services web exploitent
l’architecture REST (besoins de performance)
Certains (comme Google) ont arrêtés les services web étendus
eBay propose encore des services web étendus

View Slide

30
Plateformes de développement
La grande majorité des plateformes de développements
fournissent le support de services web (outils et APIs)
Plateforme .NET
Plateforme Java
Plateforme PHP, C++, Python…
Les outils permettent de
Manipuler des messages SOAP
Manipuler des données au format XML
Mapping XML / Classe (Marshall, Unmarshall)
Accéder à la couche HTTP
Dans ce cours, nous utiliserons la plateforme Java
Outillée, gratuite, accessible, légère, respect des standards

View Slide

Métaphore de l’auto-école / coding-school
31
Code = Concepts SOA Conduite = Développement
q Connaître les normes, standards et
techniques
q Spécifier le contrat d’un service web
q Appeler un service web
q Identifier les phases de programmation
serveur/client et de déploiement
q Connaître les bonnes pratiques avec les
Architectures Microservice
q Programmer un service web depuis un
contrat ou depuis une classe Java
q Déployer un service web
q Programmer un client
q Mettre en application une architecture
Microservice
Technologies Java basées sur
Jakarta EE. Les principes
restes les mêmes si vous
utilisez Spring, .NET…

View Slide

Liste des outils
32
Java 11 (Minimum)
Maven 3
SoapUI pour tester services web étendus
Docker et Docker-Compose (nécessite droits administrateur)
Eclipse ou Intellij ou VSCode
cURL ou Postman pour tester services web REST

View Slide

SOA : introduction générale

SOA : introduction générale

Mickael BARON

More Decks by Mickael BARON

Other Decks in Programming

Featured

Transcript