Architecture SOA – Module IVa - serveur campus des écoles hes

Transcription

Architecture SOA – Module IVa
Module IVa
Architecture SOA
Peter DAEHNE
Peter DAEHNE
Plan
Module IVa
Introduction.
Évolution des systèmes d’information.
Démarches d’intégration.
L’approche SOA et ses objectifs.
Les concepts.
L’infrastructure.
Standards, normes et protocoles.
Conclusion.
Peter DAEHNE
Connaissance et maîtrise des SI
Cours CTI – Printemps 2009
2
1
Agenda - 1
Module IVa
Introduction.
Introduction
Les concepts.
L’infrastructure.
Conclusion.
Peter DAEHNE
Introduction - 1
3
Module IVa
L’acronyme SOA a été inventé par le
Gartner Group dès 1996.
Objectif: décrire une nouvelle manière de
concevoir et d’organiser les différents
composants du SI de l’entreprise.
SOA est un « buzz » actuel.
Peter DAEHNE
4
2
Introduction - 2
Module IVa
De la vision à la solution:
Enrichissement
Exemple signifiant concret
exprimant un besoin
Raffinements
successifs
Solution
Temps
Peter DAEHNE
Introduction - 3
5
Module IVa
L’organisation du SI a toujours été calquée
sur celle de l’entreprise.
Jusqu’aux années 1970, organisation
compartimentée en silos fonctionnels:
Production, ventes, finances, etc.
Fonctionnement indépendant.
Applications informatiques monolithiques
dédiées à la gestion de ces fonctions.
Peter DAEHNE
6
3
Introduction - 4
Module IVa
Dès la fin des années 1970, organisation
matricielle.
Des strates horizontales dont ajoutées à
l’organisation verticale existante:
CRM, RH, Chaîne logistique (supply chain), etc.
Les applications informatiques sont
adaptées en conséquence.
SI peu agile et rigidifié dans une matrice
organisationnelle et fonctionnelle.
Peter DAEHNE
Introduction - 5
7
Module IVa
Aujourd’hui, organisation en réseau.
Les composants sont couplés de façon
lâche.
Les unités fonctionnelles sont relativement
indépendantes.
Ce sont les besoins liés à ce nouveau type
d’organisation qui sont à l’origine de
l’architecture SOA.
Peter DAEHNE
8
4
Introduction - 6
Module IVa
Objectifs:
Construire un SI flexible et agile;
Au service de l’accomplissement du métier;
Facilitant l’innovation;
Réduisant les coûts.
Peter DAEHNE
Agenda - 2
9
Module IVa
Introduction.
Évolution
des
systèmes
L’approche
SOA et
ses objectifs.
Les concepts.
d’information
L’infrastructure.
Conclusion.
Peter DAEHNE
10
5
Évolution - 1
Module IVa
Jusqu’aux années 70-80: mainframe
Site central;
Applications monolithiques;
Persistance, traitement et présentation forment
un ensemble indissociable.
Haute disponibilité, intégrité des données.
Système cohérent et fiable.
Coûts d’acquisition et d’exploitation élevés.
Peter DAEHNE
Évolution - 2
11
Module IVa
Début des années 90: client / serveur
Persistance gérée par le site central ;
Présentation déportée sur les postes de travail;
La localisation du traitement peut varier.
Système hétéroclite
Développement décentralisé sans gouvernance;
Apparition sauvage d’applications transverses;
Informations et règles de gestion dupliquées;
Problèmes de déploiement des applications.
Peter DAEHNE
12
6
Évolution - 3
Module IVa
Vers 2000: les applications Web
Partenaires et clients peuvent accéder à
certaines applications de l’entreprise;
Intégration de ceux-ci aux processus métiers;
Développement du commerce électronique.
L’entropie globale augmente.
Les coûts (gestion, licences) diminuent.
La sécurité devient un vrai problème.
Peter DAEHNE
Évolution - 4
13
Module IVa
Bilan
Aucune entreprise n’a fait table rase à chaque
changement technologique;
Les parcs informatiques sont morcelés;
Les applications communiquent peu ou pas;
Les systèmes patrimoniaux (legacy) constituent
souvent les fondations du SI.
Il faut organiser cette hétérogénéité pour en
reconquérir la maîtrise.
Peter DAEHNE
14
7
Évolution - 5
Peter DAEHNE
Module IVa
Agenda - 3
15
Module IVa
Introduction.
Démarches
d’intégration
Les
concepts.
L’infrastructure.
Conclusion.
Peter DAEHNE
16
8
Intégration - 1
Module IVa
Aucune démarche méthodologique
sérieuse jusqu’au milieu des années 1990.
Les applications sont organisées comme
l’entreprise: en silos.
Chaque silo est autonome et isolé en
terme de:
Processus;
Interface homme / machine;
Base technique.
Peter DAEHNE
Intégration - 2
17
Module IVa
Problèmes:
Pratiquement impossible de mettre en place
des processus métier transversaux.
Duplication d’objets et de règles métier.
Double saisie.
Évolutions difficiles à mettre en œuvre car:
Complexité de l’architecture;
Variété de technologies (hardware et software).
Réutilisation de composants impossible.
Peter DAEHNE
18
9
Intégration - 3
Module IVa
Développement de connecteurs et de
protocoles ad hoc au fur et à mesure de
l’apparition des besoins.
Développement et maintenance coûteux.
Aucune vision des flux d’information pour
une processus métier donné.
Architecture accidentelle.
Peter DAEHNE
Intégration - 4
19
Module IVa
Intégration: cas de l’architecture accidentelle.
Peter DAEHNE
20
10
Intégration - 5
Module IVa
Une démarche d’intégration efficace devrait
permettre aux applications de se connecter
au système de façon indépendante.
Dès le milieu des années 1990, les outils
d’EAI proposent des solutions de ce type.
EAI = Enterprise Application Integration.
Une outil d’EAI est une sorte de « cœur »
auquel les applications se connectent de
façon indépendante.
Peter DAEHNE
Intégration - 6
21
Module IVa
Intégration: cas de l’EAI.
Peter DAEHNE
22
11
Intégration - 7
Module IVa
Fonctionnalités d’un EAI:
Transport des données;
Connexion entre applications;
Transformation des données;
Orchestration les processus;
Services techniques:
Monitoring des données échangées;
Annuaire des applications connectées.
Peter DAEHNE
Intégration - 8
23
Module IVa
Avantages:
Architecture du SI simplifiée;
Échange d’informations plus facile.
Inconvénients:
Onéreux et paramétrage compliqué;
Logique d’intégration propriétaire;
Ne résout pas la problématique du silo;
Single Point of Failure.
Peter DAEHNE
24
12
Intégration - 9
Module IVa
Autres approches: le tout intégré
Les ERP du début des années 1990;
Plate-forme technologique commune;
Base de données centrale;
Squelettes d’applications pré-implantées à
configurer.
Les processus doivent parfois être adaptés
au logiciel.
Difficulté de prendre en compte l’existant.
Peter DAEHNE
Intégration - 10
25
Module IVa
Autres approches: l’urbanisation du SI
Transformer de façon continue le SI pour le
simplifier durablement.
Il s’agit principalement:
De définir un SI cible idéal en fonction de la
stratégie de l’entreprise (et d’autres facteurs);
De déterminer les étapes de la transformation du
SI actuel pour atteindre la cible fixée.
Cette approche sera traitée en détail dans un
autre module (Ch. Aïdonidis).
Peter DAEHNE
26
13
Agenda - 4
Module IVa
Introduction.
L’approche
L’approche
SOA et ses SOA
objectifs.et
Les concepts.
ses objectifs
L’infrastructure.
Conclusion.
Peter DAEHNE
Approche - 1
27
Module IVa
SOA n’est pas une technologie.
SOA est:
Une philosophie de conception indépendante
de tout produit, technologie ou tendance;
Un paradigme, une approche pour construire
le système d’information informatisé;
Qui s’appuie sur les processus métier de
l’entreprise et sur le concept de service.
SOA définit un modèle d’interaction entre
les composants du SI.
Peter DAEHNE
28
14
Approche - 2
Module IVa
SOA définit un style d’architecture du SI.
L’objectif général est de faire évoluer le SI
en évitant les écueils énoncés plus haut.
Les composants logiciels sont connectés
par un couplage lâche.
Le style d’architecture:
Favorise la réutilisation des composants;
Lutte contre le syndrome des silos.
Peter DAEHNE
Approche - 3
29
Module IVa
Comme déjà mentionné dans l’introduction,
les objectifs de SOA sont donc:
Construire un SI flexible et agile;
Au service de l’accomplissement du métier;
Facilitant l’innovation;
Réduisant les coûts.
Des études ont montré qu’un réel retour sur
investissement pouvait être dégagé à
moyen terme [Ibm06].
Peter DAEHNE
30
15
Agenda - 5
Module IVa
Introduction.
Les concepts
Les concepts.
L’infrastructure.
Conclusion.
Peter DAEHNE
Les concepts - Plan
31
Module IVa
Introduction.
Service.
Message.
Annuaire des services.
Granularité et typologie des services.
Applications composites.
Peter DAEHNE
32
16
Les concepts - 1
Module IVa
Introduction.
Service.
Message.
Annuaire des
services.
Introduction
Peter DAEHNE
Concepts / Introduction - 1
33
Module IVa
État de l’art actuel des réflexions menées
sur la conception et le développement.
L’écriture de logiciel est un problème de
plus en plus complexe.
Évolution de la réutilisation:
Sous-programme;
Programmation modulaire;
Programmation orientée objet;
Programmation orientée composants.
Peter DAEHNE
34
17
Concepts / Introduction - 2
Module IVa
Élévation du niveau d’abstraction:
De la réutilisation de code à celle de
fonctionnalité;
Solutions organisationnelles pour tenter de
conserver la maîtrise du SI.
Le contexte a évolué:
Systèmes distribués;
Plateformes hétérogènes et interopérabilité;
Internet et périphériques mobiles.
Peter DAEHNE
Les concepts - 2
35
Module IVa
Introduction.
Service.
Message.
Service
Peter DAEHNE
36
18
Concepts / Service - 1
Module IVa
Le service est l’entité fondamentale.
Unité fonctionnelle avec les propriétés:
Ensemble de fonctionnalités définies par une
interface indépendante de la plateforme;
Peut être localisé et invoqué dynamiquement;
Est autonome et sans état.
Caractéristiques supplémentaires:
Couplage faible, réutilisable, composable et
performant.
Peter DAEHNE
37
Module IVa
Un service propose une
interface de distribution,
Basée sur un ensemble
de composants métiers,
Constitués d’objets
implantant des méthodes
de bas niveau.
Peter DAEHNE
38
19
Module IVa
Responsabilités
Objet:
Implantation des traitements.
Composant:
Modèle de composants proposé par les
plateformes de développement utilisées.
Service:
Mise à disposition des opérations;
Protocole de communication pour l’accès.
Peter DAEHNE
39
Module IVa
Interface
Contrat que le service s’engage à satisfaire
vis-à-vis de ses clients.
Boîte noire.
L’indépendance de la plateforme garantit …
… qu’un client quelconque …
… écrit dans n’importe quel langage …
… hébergé par n’importe quel système
d’exploitation …
… peut invoquer le service.
Peter DAEHNE
40
20
Module IVa
Localisation et invocation dynamique
Effectués par l’entremise d’un annuaire.
L’annuaire répertorie les services.
Les clients peuvent l’interroger pour obtenir la
référence d’un service sur la base d’un certain
nombre de critères.
D’un jour à l’autre, le service physique
invoqué par une application peut changer.
Peter DAEHNE
41
Module IVa
Autonome et sans état
Le service ne gère donc aucun contexte.
Une unique instance suffit, indépendamment
du nombre de ses clients.
Se distingue donc des composants usuels
dont il existe autant d’instances que de clients
qui consomment leurs fonctionnalités.
Peter DAEHNE
42
21
Module IVa
Couplage faible
Nombre de dépendances et de relations
explicites avec d’autres services minimisé.
En cas de recours à un autre service,
invocation par l’entremise de l’annuaire.
Réutilisable
Fonctionnalité suffisamment primitive
implantée de façon générale.
Brique élémentaire pour la construction
d’applications complexes.
Peter DAEHNE
43
Module IVa
Composable
Caractéristique parente de la réutilisabilité.
On peut construire de nouveaux services
(services composites) en assemblant et
coordonnant des services existants.
Performant
Fondamental, car appelé à fonctionner dans
le cadre d’une infrastructure nécessitant des
ressources importantes.
Peter DAEHNE
44
22
Module IVa
Fonctionnement
Synchrone
Le code du client est interrompu dans l’attente du
résultat fourni par le service.
Asynchrone
Le code du client poursuit son exécution après
l’invocation.
Un protocole est défini pour spécifier comment le
service indique qu’il a terminé sa tâche et
comment se procurer les résultats.
Peter DAEHNE
Les concepts - 3
45
Module IVa
Introduction.
Service.
Message.
Annuaire des Message
services.
Peter DAEHNE
46
23
Concepts / Message - 1
Module IVa
Le message est l’entité de communication
entre les clients et les services.
Emploi
Invocation d’un service par un client.
Retour des résultats au client par le service.
Transmission des informations en entrée et
en sortie.
Coordination des activités de services
composites.
Peter DAEHNE
Concepts / Message - 2
47
Module IVa
Indépendance de la plateforme
L’interface est indépendante de la plateforme.
Elle définit les messages qu’un service
accepte et retourne.
La technologie pour décrire les messages doit
également être indépendante:
Des langages de programmation;
Des systèmes d’exploitation.
Peter DAEHNE
48
24
Les concepts - 4
Module IVa
Introduction.
Service.
Message.
Annuaire
des services.
Annuaire
des services
Peter DAEHNE
Concepts / Annuaire - 1
49
Module IVa
L’intermédiaire entre clients et fournisseurs
de services est l’annuaire des services.
Caractéristiques:
Les fournisseurs publient les services:
Enregistrement auprès de l’annuaire.
Sous la forme d’une interface (contrat).
Les clients interrogent l’annuaire:
Localiser et découvrir un service dont le contrat
satisfait certaines contraintes.
Dans le but de l’invoquer.
Peter DAEHNE
50
25
Module IVa
Pattern publish-find-bind-execute
Peter DAEHNE
51
Module IVa
Informations associées à un service
Version.
Type (voir [Hef05]).
Caractéristiques fonctionnelles.
Nom, paramètres, exceptions, pré-conditions.
Chemin d’accès (URL).
Aspects non fonctionnels.
Sécurité.
Critères qualitatifs (temps de réponse moyen, …).
Informations sémantiques.
Peter DAEHNE
52
26
Module IVa
Autres caractéristiques de l’annuaire:
Adjonction dynamique et incrémentale de
services ainsi que mise à jour en cours
d’exécution du système.
Élément clé du découplage de par son rôle
d’intermédiaire entre fournisseur et client.
Le client accède au service de façon indirecte
et peut choisir ce dernier en fonction de
critères répertoriés dans la description et
connus du client qu’en cours d’exécution.
Peter DAEHNE
Les concepts - 5
53
Module IVa
Introduction.
Service.
Message.
Granularité
et typologie des
services
Granularité et typologie
des services.
Peter DAEHNE
54
27
Concepts / Typologie - 1
Module IVa
Granularité des services
Il faut un bon niveau de granularité.
Ne peut être obtenu qu’en effectuant une
analyse métier.
Les tâches métier identifiées guideront le
découpage en différents services.
Granularité trop faible: peu d’intérêt.
Granularité trop forte: peu réutilisable.
Peter DAEHNE
55
Module IVa
Typologie des services
Peter DAEHNE
56
28
Module IVa
Service technique:
Donne accès à une ressource technique
donnée.
Messagerie, imprimante.
Base de données relationnelle, EAI.
Est générique, c’est-à-dire lié à une catégorie
de ressources.
Granularité moyenne à forte.
Réutilisabilité forte.
Peter DAEHNE
57
Module IVa
Service métier:
Offre un ensemble cohérent de traitements
métier.
Exemple: vision client – un tel service permet
d’obtenir
Les informations de base du client;
L’état de ses comptes;
La liste de ses commandes en attente;
L’historique de ses relations avec l’entreprise;
…
Peter DAEHNE
58
29
Module IVa
Service de persistance:
Créer, rechercher, mettre à jour et supprimer
de l’information des référentiels du SI.
Associé à un objet métier racine (point d’entrée
dans le système d’information).
Pour lire ou écrire un objet métier racine, le
service accèdera en général à plusieurs tables.
Granularité faible.
Réutilisation forte.
Peter DAEHNE
59
Module IVa
Service fonctionnel:
Encapsule tout ou partie des règles de
gestion et des traitements métier.
Implante un ensemble de fonctions métier.
S’appuie en général sur des services de
persistance pour accéder aux informations
métier dont il a besoin.
Granularité moyenne à forte.
Réutilisabilité moyenne à forte.
Peter DAEHNE
60
30
Module IVa
Service applicatif:
Service de façade de haut niveau masquant aux
applications composites concernées les services
de bas niveau.
Coordonne les appels aux services fonctionnels.
Spécifique d’une application composite
interactive (satisfait un besoin métier précis).
Granularité forte.
Réutilisabilité nulle.
Peter DAEHNE
61
Module IVa
Dépendance des services
Peter DAEHNE
62
31
Module IVa
Effectuer un bon découpage
Peter DAEHNE
Les concepts - 6
63
Module IVa
Introduction.
Service.
Message.
Annuaire
des services.
Applications
composites
Peter DAEHNE
64
32
Concepts / App. Composites - 1
Module IVa
Les services étant identifiés et définis, il
faut les consommer.
Dans une approche SOA, on définit un
nouveau type d’applications:
les applications composites
Ce sont des applications construites en
composant des appels de services.
Elles apportent la valeur ajoutée aux
utilisateurs finaux du système.
Peter DAEHNE
65
Module IVa
On identifie principalement trois types
d’applications composites:
Application composite interactive (impliquant
une interaction avec un utilisateur).
Processus métier.
Système traditionnel (batch ou application).
Une application composite peut à son tour
s’exposer sous la forme d’un service.
Peter DAEHNE
66
33
Module IVa
Processus métier
L’ensemble des activités que l’entreprise doit
réaliser pour traiter un événement métier.
SOA: enchaînement automatisé de services.
Appelé orchestration du processus et exécuté
par le moteur BPM.
L’orchestration décrit:
La logique de contrôle.
Le flux de données internes du processus métier.
Peter DAEHNE
67
Module IVa
Topologie de déploiement
Client lourd.
L’application composite réside sur le poste client.
Elle élabore les vues en local.
Elle appelle des services hébergés par des serveurs.
Peter DAEHNE
68
34
Module IVa
Client léger.
L’application composite réside sur le serveur.
Elle élabore les vues et les envoie à un moteur
graphique distant: le browser.
Technologie de pages Web dynamiques.
Peter DAEHNE
69
Module IVa
Client distant.
L’application composite devient un service.
Le client est un portail distant.
Le portail utilise un protocole dédié pour le dialogue
avec ce service.
L’application composite transmet ses vues au portail.
Peter DAEHNE
70
35
Agenda - 6
Module IVa
Introduction.
L’infrastructure
Les concepts.
L’infrastructure.
Conclusion.
Peter DAEHNE
Infrastructure - 1
71
Module IVa
SOA est un concept architectural.
Il définit l’organisation du SI.
Principes généraux:
Les fonctions métier sont encapsulées dans
des services.
Les fonctionnalités de ces services sont
exposées via des interfaces:
Indépendantes de la plate-forme;
Indépendantes du langage d’implémentation.
Peter DAEHNE
72
36
Infrastructure - 2
Module IVa
Principe généraux (suite):
Interaction et interopérabilité des services par
l’intermédiaire de l’échange de messages:
Indépendamment de la localisation des services
dans un environnement distribué;
Indépendamment du protocole de communication
employé.
Implantation au moyen d’une infrastructure
qu’on appelle Enterprise Service Bus.
Description du concept: [Gar02] et [Cha04].
Peter DAEHNE
Infrastructure - 3
73
Module IVa
L’ESB est avant tout un design pattern.
Propose une couche d’abstraction pour
implanter les principes généraux.
Implantations possibles (3):
Message broker existant
Fournit la fonctionnalité d’échange de messages.
Les autres éléments organisationnels sont réalisés
au moyen de solutions ad hoc.
Peter DAEHNE
74
37
Infrastructure - 4
Module IVa
Implantations possibles (suite):
Solution hybride en assemblant
Composants développés en interne.
Composants open source.
Composants commerciaux.
Solution logicielle complète spécifique
Commerciale ou open source.
Critères de choix: [Ful06]
Offres commerciales existantes: [Vol06]
Peter DAEHNE
Infrastructure - 5
75
Module IVa
ESB: épine dorsale de la plateforme SOA
Peter DAEHNE
76
38
Infrastructure - 6
Module IVa
(1) Portails
Représentent une application composite
interactive à l'usage des utilisateurs du SII.
Plusieurs types peuvent être envisagés:
Application en ligne destinée au grand public.
Application métier destinée aux employés.
Portail à l’usage des partenaires commerciaux.
Ligne graphique unifiée.
Single sign-on et personnalisation en fonction
du rôle et du type d’utilisateur.
Peter DAEHNE
Infrastructure - 7
77
Module IVa
(2) Conteneur
Encapsulation des fonctionnalités et des
attributs non fonctionnels d’un service.
Exposés par l’entremise d’une interface.
Chargé de gérer l’échange de messages entre
l’implantation technique du service et l’ESB.
Outils pour gérer les transactions, la sécurité et
la reconfiguration dynamique du service.
Contrôle le fonctionnement et l’état interne du
service.
Peter DAEHNE
78
39
Infrastructure - 8
Module IVa
(3) Annuaire des services
Chargé de la localisation et de l’invocation
dynamique des services.
Une description complète de ses fonctions a
déjà été effectuée plus haut.
Peter DAEHNE
Infrastructure - 9
79
Module IVa
(4) Accès aux données
Service technique distribué.
S’appuie sur un moteur SQL et/ou XQuery.
Permet la création de services de persistance
pour les objets métier.
Son rôle est d’abstraire les caractéristiques
techniques de bas niveau.
Peter DAEHNE
80
40
Infrastructure - 10
Module IVa
(5) Adaptateur
Permet d’exposer les applications existantes
comme un service.
Chargé d’effectuer la connexion entre
l’application et le conteneur.
Peut-être mis en œuvre pour n’importe quel
type d’application écrite dans n’importe quel
langage, moyennant un adaptateur ad hoc.
L’ESB généralise ainsi l’EAI.
Peter DAEHNE
Infrastructure - 11
81
Module IVa
(6) Web-Services
Candidats « naturels » à fonctionner dans le
cadre de cette architecture.
On considère souvent à tort que c’est l’unique
réalisation possible du concept de service.
Permet l’implantation de services ouverts qui
peuvent transiter par le Web (http, ftp, smtp).
Les échanges avec des partenaires externes
(ex: e-commerce) s’en trouvent facilités.
Peter DAEHNE
82
41
Infrastructure - 12
Module IVa
(7) Applications J2EE
Un adaptateur transforme le protocole et les
messages de l’ESB dans le standard JMS.
Souvent proposé en standard dans des
solutions complètes en raison de la très large
diffusion de J2EE et de sa portabilité naturelle.
Peter DAEHNE
Infrastructure - 13
83
Module IVa
(8) Moteur BPM
Responsable de la chorégraphie des
processus métier et de l'orchestration des
services associés.
Modélisation et exécution des processus sans
avoir recours à du développement de code.
What you model is what you run.
Gère le suivi (contrôle, mesures, optimisation du
flux des activités, alertes en cas de problème).
Peter DAEHNE
84
42
Infrastructure - 14
Module IVa
(9) & (10) Communication entre systèmes
L’ESB peut communiquer par le réseau avec
celui d’un autre système:
Les systèmes d’une même entreprise sont
dispersés géographiquement.
Cas de relations B2B.
Objectif: consommer ou fournir des services à
l’autre système.
La communication est assurée par un protocole
standard de l’Internet (ou protocole propriétaire).
Peter DAEHNE
Infrastructure - 15
85
Module IVa
(11) Superviseur SOA
Collecte des informations sur les éléments
matériels et logiciels de la plateforme.
Identification et traitement des problèmes.
Statistiques et reporting (amélioration continue).
SAM (Service Activity Management):
On observe les services.
BAM (Business Activity Management):
On observe les processus.
Peter DAEHNE
86
43
Infrastructure - 16
Module IVa
L’infrastructure est adaptée au support
d’outils de workflow et de messagerie.
Ils sont intégrés au système sous forme de
services ou de portails particuliers.
L’ESB – élément central de l’architecture:
Technologies de tolérance de pannes.
Il est impensable que le défaillance d’un
composant bloque l’ensemble du système.
Peter DAEHNE
Infrastructure - 17
87
Module IVa
Chaîne de fabrication logicielle.
Ensemble d’outils permettant de concevoir,
modéliser, développer, déployer et tester les
différents éléments:
Atelier de modélisation.
Atelier de fabrication.
Atelier d’assemblage et de déploiement.
Atelier d’homolgation.
Etc…
Les composants de cette chaîne sont choisis
parmi les offres du marché les plus adaptées.
Peter DAEHNE
88
44
Agenda - 7
Module IVa
Introduction.
Standards,
normes
L’approche
SOA et ses
objectifs. et
Les concepts.protocoles
L’infrastructure.
Conclusion.
Peter DAEHNE
Standards - 1
89
Module IVa
L'infrastructure décrite est structurée en
différentes couches de normes et de
protocoles.
Ceux-ci peuvent bien sûr être définis de
façon propriétaire.
La plupart d’entre eux sont standardisés:
W3C: World Wide Web Consortium
OASIS: Organization for the Advancement of
Structured Information Standards
Peter DAEHNE
90
45
Standards - 2
Module IVa
Protocoles réseau:
HTTP [Htt99], FTP [Ftp85], SMTP [Smt01].
Représentation des messages:
XML [Xml06].
Description des services et de leurs interfaces:
WSDL [Wsd01].
Invocation des services et transport des messages:
SOAP [Soa07], WS-I [Wsi07].
Découverte des services:
UDDI [Udd04], WSIL [Wsl07].
Chorégraphie / orchestration des services:
WS-BPEL [Wsb05].
Peter DAEHNE
Agenda - 8
91
Module IVa
Introduction.
Conclusion
Les concepts.
L’infrastructure.
Conclusion.
Peter DAEHNE
92
46
Conclusion - 1
Module IVa
La mise en œuvre de SOA dans l’entreprise est
un voyage, une stratégie planifiée sur plusieurs
années (de 2-3 ans à 10 ans).
Cette stratégie
Implique de faire évoluer le SII de l’entreprise.
Implique de bouleverser la structure organisationnelle
de l’entreprise.
Doit reposer sur des objectifs précis et clairs en termes
de gestion d’entreprise.
[Hef04]: 6 approches pour effectuer cette (r)évolution.
Peter DAEHNE
Conclusion - 2
93
Module IVa
La migration vers une architecture SOA ne
peut être que graduelle.
Elle implique des modifications
fondamentales dans l’organisation de
l’entreprise en général …
… et de son département informatique en
particulier !
Peter DAEHNE
94
47
Conclusion - 3
Module IVa
Le chemin vers l'adoption de SOA n'est
pas dépourvu d'embûches. Ce parcours
du combattant est très bien illustré par la
déclaration suivante:
« Après une phase d'adhésion, les entreprises passent
souvent par une phase de désillusions puis un
refondement qui conduit enfin à la sortie du tunnel,
jusqu'à un plateau de productivité »
P. Maliverno, Gartner Group.
Peter DAEHNE
Conclusion - 4
95
Module IVa
Lorsque la décision est prise et que la
conversion philosophique a eu lieu se
pose la question du choix technologique.
Les systèmes installés peuvent-ils évoluer ?
Sont-ils frappés d’obsolescence ?
Les vendeurs de solutions proposent-ils des
produits en adéquation avec la stratégie ?
L’architecture hardware est-elle adaptée au
pas conceptuel envisagé ?
Etc.
Peter DAEHNE
96
48
Conclusion - 5
Module IVa
Aucun vendeur ne propose de solution
magique clés en mains.
La solution idéale est souvent un
assemblage de produits.
[Vol06]: étude de produits du marché.
[Jon07]: une étude plus récente se basant
sur des critères tels que visions business
et IT du produit, standards et maturité.
Peter DAEHNE
97
Module IVa
Merci de votre attention
Peter DAEHNE
98
49
Bibliographie
[Bon08]
Pierre Bonnet, Jean-Michel Detavernier, Dominique Vauquier, Le système d’information
durable – La refonte progressive du SI avec SOA, Lavoisier, 2008, ISBN 978-2-7462-1829-1.
[Cha04]
[Fou08]
David A. Chappel, Enterprise Service Bus, O'Reilly, Juin 2004, ISBN 0-596-00675-6.
Xavier Fournier-Morel, Pascal Grojean, Guillaume Plouin, Cyril Rognon, SOA, Le guide de
l’architecte du SI, 2e édition, Dunod, 2008, ISBN 978-2-10-051708-4.
Larry Fulton, The Case For An Enterprise Service Bus, Forrester Research,
http://www.forrester.com/Research/Document/0,7211,40859,00.html, 12.12.2006.
Gartner Group, Roy W. Schulte, Predicts 2003 : Enterprise Service Bus Emerge, 9.12.2002.
Randy Hefner, Your Paths To Service-Oriented Architecture, Forrester Research,
Randy Hefner, A Taxonomy Of Service Types For SOA, Forrester Research,
IBM Global Business Services : Nicole Baker, Rolando Franco, Maria Stein-Marrison, ServiceOriented Architecture, A practical guide to measuring return on that investment, http://www935.ibm.com/services/us/gbs/bus/pdf/g510-6320-soa-roi.pdf, 2006.
Steve
Jones,
SOA
Vendor
Ratings
Q1
2007,
http://servicearchitecture.blogspot.com/2007/03/soa-vendor-ratings-q1-2007.html, 22 mars 2007.
Tiziana Margaria, Service Is in the Eyes of the Beholder, Computer, pp. 33-37, Novembre
2007, ISSN 0018-9162.
José Rouillard, Thomas Vantroys, Vincent Chevrin, Architecture Orientée Services – Une
approche pragmatique des SOA, Vuibert, 2007, ISBN 978-2-7117-4868-6.
Ken Vollmer, Mike Gilpin, The Forrester Wave™ : Enterprise Service Bus, Q2 2006, Forrester
Research, http://www.forrester.com/Research/Document/0,7211,38696,00.html, 30.06.2006.
[Ful06]
[Gar02]
[Hef04]
[Hef05]
[Ibm06]
[Jon07]
[Mar07]
[Rou07]
[Vol06]
Normes et standards (W3C : http://www.w3.org et OASIS : http://www.oasis-open.org)
[Ftp85]
International Engineering Task Force (IETF), File Transfer Protocol (FTP), RFC 959,
http://www.ietf.org/rfc/rfc959.txt, octobre 1985.
[Htt99]
W3C, Hypertext Transfer Protocol -- HTTP/1.1,
http://www.w3.org/Protocols/rfc2616/rfc2616.html, juin 1999.
[Smt01] International Engineering Task Force (IETF), Simple Mail Transfer Protocol, RFC 2821,
http://www.ietf.org/rfc/rfc2821.txt, avril 2001.
[Soa07] W3C, SOAP Version 1.2, http://www.w3.org/TR/soap, 27.04.2007.
[Udd04] OASIS,
UDDI
Version
3.0.2,
http://www.oasis-open.org/committees/uddispec/doc/spec/v3/uddi-v3.0.2-20041019.htm, 19.10.2004.
[Wsb05] OASIS, Web Services Business Process Execution Language Version 2.0, http://www.oasisopen.org/committees/download.php/14616/wsbpel-specification-draft.htm, 1.09.2005.
[Wsd01] W3C, Web Services Description Language (WSDL) 1.1, http://www.w3.org/TR/wsdl,
15.03.2001.
[Wsi07] Web Services Interoperability Organization, WS-I Basic Profile Version 1.2, http://www.wsi.org/Profiles/BasicProfile-1_2(WGAD).html, 24.10.2007.
[Wsl07] IBM, Web Services Inspection Language,
http://www.ibm.com/developerworks/library/specification/ws-wsilspec, Janvier 2007.
[Xml06] W3C, Extensible Markup Language (XML) 1.0 (Fourth Edition), http://www.w3.org/TR/RECxml/, 29.09.2006.
Peter DAEHNE, Version 1.0, 09.03.2009

Architecture SOA – Module IVa - serveur campus des écoles hes

Transcription

Documents pareils

Consultants EAI/SOA/Urbanisation (H/F)

Ref. LIMPEZA E TRATAMENTO DO ROSTO Cont. Quan dade PU s

Mars - Pages perso de Laurent COLLET

l`essence lumineuse de Naouryz

Avec des extraits de Spiderman

Système d`Information

Télécharger le dossier de presse de Peter sans pan

Gourmandises Du Printemps

paul morrissey la trilogie - Rencontres Internationales du Cinéma

Télécharger la plaquette