SOA
(Service Oriented Architecture)
Architectures Orientées Services
PRESENTER PAR RESPONSABLES DE FILIERE
Ahmed LAFTIMI Monsieur Bruno Van Moerkercke
CNAM 2008-2009 NFE 107
1
Sommaire
• Partie I -Entropie des systèmes d’Information
• Partie II - Les Architectures orientées services
• Partie III - SOA-Concepts et Composants
• Conclusion, Bilan & Perspectif
Objectif de la présentation => Définir, Identifier
2
Introduction
Problématique
Face au changement quoi faire ?
Évolution des Systèmes d’information
Architecture
Processus Fluides
SOA POUR UNE MEILLEURE AGILITE
3
Sommaire
• Partie I -Entropie des systèmes d’Information
• Partie II - Les Architectures orientées services
• Partie III - SOA-Concepts et Composants
• Conclusion, Bilan & Perspectif
4
Partie I - Entropie des systèmes d’Information
Histoire -> 1ER Génération
Le Mainframe Centralisation et terminaux passifs
• Ordinateur central
• Terminaux
• Serveur unique
Avantage : assure la haute disponibilité et l’intégrité des données et offre à l’entreprise un
système cohérent et fiable.
Inconvénient : Couts d’acquisition et d’exploitation sont élevés
5
Partie I - Entropie des systèmes d’Information
Histoire -> 2éme Génération • Introduction
• Histoire informatique
• Solutions et limits
Application client/Serveur
Applis délocalisées, données centralisées
• Computer Personnel
• Architecture client/serveur
Avantage : faible coût des nouvelles applications plus légères
Inconvénient : duplications d’informations , le poste de travail deviens charge de plusieurs
exécutables
6
Partie I - Entropie des systèmes d’Information
Histoire -> 3éme Génération
Re-centralisation, interfaces client relookées
Application Web
• Pas de logiciel sur le poste de travail
• Accès à distant via un navigateur web
7
Partie I - Entropie des systèmes d’Information
Histoire -> 4éme Génération
Web services et SOA ?
8
Partie I - Entropie des systèmes d’Information
État des lieux des SI
État actuel État cible
Hétérogène Homogène
Redondant Rationnel
Coût de maintenance
Rigide Agile
Divergence Alignement
Besoins métier Besoins métier
SI SI
9
Partie I - Entropie des systèmes d’Information
Réponses actuelles -> Urbanisation -> Modèle de référence
Processus métier
Fonctionnel
Use cases
Applicatif
Applications & logiciels
Physique
Infrastructure
10
Partie I - Entropie des systèmes d’Information
Réponses actuelles -> Urbanisation -> Phénomène vertical
Division A Division B Processus rigides
Processus complexes
Métier Processus non transférables
+
Composants peu réutilisables
Hétérogénéité technologique
Fonctionnel
=
Problématiques des silos applicatifs
Applicatif
Physique
11
Partie I - Entropie des systèmes d’Information
Réponses actuelles -> Urbanisation -> Phénomène horizontal
Métier Redondance
Données
Traitements
Parc applicatif rigide
Fonctionnel
Interdépendance élevée
Difficulté d’évolution
Applicatif
Physique
« Syndrome du plat de spaghettis ???»
12
Partie I - Entropie des systèmes d’Information
Réponses actuelles -> Outillage
silos spaghetti Commentaire
EAI NON OUI Coût d’implémentation élevé
Propriétaire, dépendance envers l’éditeur
Point de passage obligé
Workflow NON NON Coût élevé d’adaptations aux applications
existantes élevé
Propriétaire, dépendance envers l’éditeur
Portail NON NON Paramétrage laborieux
Propriétaire, dépendance envers l’éditeur
Framework OUI OUI Potentiel élevé de réutilisation et de
composition
applicatif
Forte adhérence technologique
Réutilisation non généralisable à
l’ensemble du SI
EAI (Enterprise Application Integration)
13
Workflow est un flux d'informations au sein d'une organisation
Sommaire
• Partie I -Entropie des systèmes d’Information
• Partie II - Les Architectures orientées services
• Partie III - SOA-Concepts et Composants
• Conclusion, Bilan & Perspectif
14
Partie I - Entropie des systèmes d’Information
SOA Concrétise le modèle d’urbanisation
Processus métier
Métier
Fonctionnel
Use cases
Vue logique
Applicatif
Applications & logiciels
Technique
Physique
Infrastructure
15
Partie II - Les Architectures orientées services
Qu’est ce que SOA
SOA est apparu en 1996 dans une note de recherche du Gartner Group.
« L’architecture orientée service constitue un style d’architecture basée sur le principe de
séparation de l’activité métier en une série de services. »
« Ces services peuvent être assemblés et liés entre eux selon le principe de couplage lâche
pour exécuter l’application désirée. »
« Ces services sont définis a un niveau supérieur de la traditionnelle approche composants »
Gartner - Septembre 2005
Selon le Gartner Group, plus de 75% des projets d’entreprise
des années 2008 reposeront sur les SOA (Service Oriented
Architecture).
Gartner, Inc., fondée en1979, est une entreprise américaine de conseil et de recherche dans le domaine de la technologie .
16
Partie II - Les Architectures orientées services
Qu’est ce que SOA-> Définition
Selon l’OASIS « l’architecture orientée service (SOA ):
est un paradigme d’organisation des ressources distribuées,
potentiellement contrôlées par des domaines différents. »
17
OASIS (Organisation for Avancement of Structured Information Standards)
Partie II - Les Architectures orientées services
Qu’est ce que SOA-> Naissance de la notion SOA
Le SI de l'entreprise est généralement constitué d'applications en
silo =
Partenaires = connections -Transversalité
- Vision Globale
La solution à ce problème EAI ?
Elle consiste à développer des connecteurs spécifiques permettant
de faire communiquer entre-eux les différents silos de l'entreprise.
(Enterprise Application Integration, traduisez intégration des applications de l'entreprise) 18
Partie II - Les Architectures orientées services
Qu’est ce que SOA-> Naissance de la notion SOA-> POA ET EDA
EDA( Event Driven Architecture) : Propagation automatisée des nouvelles
informations métiers dans le SI pour éviter la désynchronisation de multiples référentiels. Nécessite
la mise en place l’outils EAI.
POA( Process Oriented Architecture) : application modéliser comme un
processus, ce qui nécessite la mise en place d’un moteur pour automatiser ces processus ( Workflou)
SOA trouve la solutions aux problématique des autres solutions
19
Partie II - Les Architectures orientées services
Qu’est ce que SOA-> Naissance de la notion SOA
Programmation structure = robuste et réutilisable
Langage purement procéduraux -> Code réutilisable? = (fonctions + des procédures) Fichier sépare
Programmation Orientée Objet (POO) -> Code réutilisable? = définition et l'assemblage de
briques logicielles (Objets) ; Envoie des messages grâce aux appels des méthodes
Solutions de transports au delà des frontière des SI --->>> Problèmes de compatibilité entre
plateformes
Besoin de standardisation et la mise en commun des protocoles ( SOAP, XML,….)
La pensé orientée services
20
SOAP (Simple Object Access Protocol) est un protocole d'échange
Partie II - Les Architectures orientées services
Vision POO et SOA ? -> savoir où se situent les différences
Modèle orienté objets
(POO)
Modèle orienté services
(SOA)
Services ?
21
Partie II - Les Architectures orientées services
Qu’est ce que SOA-> Couverture des besoins
SOA apporte au SI : • SOA est un concept qui n’est pas lié à la technologie..
• Une implémentation s’effectue sur la base de normes
• De la réutilisabilité ? et de standards.
• De l’interopérabilité ?
La clé : l’agilité
• De la flexibilité ?
Des services sans état Des services Des services faiblement couplés
interopérables
Les services inscrit dans une Les services sont définis selon Les combinaisons de
urbanisation SOA sont conçus les standards du marché de réarrangement des services
pour être sans-état afin de manière à pouvoir être utilisés métiers selon des préceptes
pouvoir être utilisé en dehors facilement aussi bien en de couplage lâche offrent de
de tout contexte applicatif interne qu’en externe du SI nombreuses possibilité vis à
vis de l’évolution du métier
22
Partie II - Les Architectures orientées services
Qu’est ce que SOA-> Principes
Les 4 grands principes du SOA
• La définition des services
• Les services sont autonomes
• Les clients et les services ne partagent que des contrats
• La compatibilité est basée sur les règles
Service
Application 1 Message à traiter
Application 2 Contrat Implémentation
Message traité
Service 1
Service 2
23
Partie II - Les Architectures orientées services
Qu’est ce que SOA-> Services
Cycle de vie des services
Identifier
Mettre en place
Maintenir
Les services au cœur SOA
Le concept d’application composite
• SOA présent un modèle d’architecture informatique basée sur l’émergence d’une
couche de services. Ces services offrent une vue logique des traitements et
données existant déjà ou à développer.
• Un service, met à disposition d’acteurs(humains ou logiciels) intervenants dans
des processus métiers, un accès vers une ou plusieurs fonctions métiers.
• Un service vise à être simple d’emploie et réutilisable .
• Un service SOA dialogue avec ses consommateurs sous une forme standardisée,
tant sur le plan technique que sur le plan métier
L’approche SOA favorise la construction de nouveaux services par composition de
services existants et cette composition devient son tour un service. De plus la
24
composition de service ne s’arrête pas non plus aux frontières du SI.
Sommaire
• Partie I -Entropie des systèmes d’Information
• Partie II - Les Architectures orientées services
• Partie III - SOA-Concepts et Composants
• Conclusion, Bilan & Perspectif
25
Partie III - SOA-Concepts et Composants
Silos Partagé
Hermétique Collaboratif
Monolithique Interopérable
Fragile
26
http://www.sun.com/products/soa/benefits.jsp
Partie III - SOA-Concepts et Composants
APPLICATIONS COMPOSITES
SERVICES MÉTIER
27
Partie III - SOA-Concepts et Composants
L’infrastructure logicielle
ESB : Entreprise Service Bus
Les Référentiels
Les outils de BPM (Business Process Management
28
Livre Orange ; Urbanisation & Intégration de système « Valtech Technology consulting »
Partie III - SOA-Concepts et Composants
SOA et Web Service ->Protocole et normes
29
Partie III - Les Architectures orientées services
SOA et Web Service ->Infrastructure
30
http://www.softeam.fr/technologies_web_services.php
Partie III - Les Architectures orientées services
SOA et Web Service ->fonctionnement
REST, un style d'architecture, pas un standard
REST est un style d'architecture, pas un
standard. Il n'existe donc pas de spécifications
de REST. Il faut comprendre le style REST et
ensuite concevoir des applications ou des
services Web selon ce style.
Bien que REST ne soit pas un standard, il
utilise des standards.
REST concerne l'architecture globale d'un
système. Il ne définit pas la manière de réaliser
dans les détails. En particulier, des services
REST peuvent être réalisés en .NET, JAVA,
CGI ou COBOL.
Le fonctionnement des services web repose sur un modèle en couches, dont les trois couches fondamentales sont les suivantes :
•Échange , visant à décrire la structure des messages échangés par les applications.
•Découverte, pour permettre de rechercher et de localiser un service web particulier
•Description, dont l'objectif est la description des interfaces des services web
31
Partie III - Les Architectures orientées services
SOA et Web Service ->fonctionnement
32
Bilan, Perspectif et Conclusion,
Bilan et perspectif
•SOA n’est pas une technologie
•SOA ne signifie pas Web Services
•Web service ne signifie pas SOA
•SOA ne résout pas les problèmes existent
dans les implémentations
•SOA nécessite un langage métier commun
(Contrat, grammaire xml )
•SOA est une affaire de compromis
33
Bilan, Perspectif et Conclusion,
Marché SOA
https://www.pac-online.com
34
Bilan, Perspectif et Conclusion,
Marché SOA
(Oracle, IBM, Software AG et Tibco) Oligopolistique de ce marché
35
(Logica, Capgemini, IBM, Atos Origin, Solucom
Bilan, Perspectif et Conclusion,
Marché STANDARD
Distributed Computing:
Grid
(Globus -> OGSA)
Applications:
Web Services
(SOAP, WSDL, UDDI)
Operating System:
Linux
Information:
World-wide Web
(html, http, j2ee, xml)
Communication:
Réseau e-mail
Internet (pop3,SMTP,Mime)
(TCP/IP)
36
Bilan, Perspectif et Conclusion,
Bilan et perspectif
Avantages Inconvénients
- Obligation d'avoir une modélisation poussée -Coûts de conception et de développement
initiaux plus conséquents
- Possibilité de découpler les accès aux traitements
- Nécessité d'appréhender de nouvelles
- Localisation et interfaçage transparents (ouverture technologies
accrue)
- Existant non SOA dans les entreprises
- Possibilité de mise en place facilitée à partir d'une
application objet existante - Performances réduites pour des traitements
simples (couche supplémentaire)
- Réduction des coûts en phase de maintenance et
d'évolution
- Facilité d'amélioration des performances pour des
applications importantes (répartition des traitements
facilitée
37
Bilan, Perspectif et Conclusion,
Conclusion
• Agilité • Beaucoup de pièces
• Réduction(Time to Market )
• Flux Important
• Partage des ressources
applicatives • Coût de recherche d’erreur(Correctif)
• Réutilisation • Mettre en place SLA(Financier)
• Facilité d’intégration faut-il faire ?
Que
Comment le faire ?
• Important de mettre en place une solution de gouvernance SOA. Qui doit le faire ?
Comment est-ce piloté et mesuré ?
• L’architecture orienté service met en œuvre une approche dont le
concept primaire est le service.
• Le processus d’urbanisation manipulant le concept de service sera plus
fluide
• SI moins rigide => alignement par rapport au besoins métier
38
SLA ( Service Level Agreements )
Bibliographie
Site Internationaux :
•http://www.thinmanager.com/buckets/whatarethinclients.shtml
•http://www.generation-nt.com/
•http://fr.wikipedia.org
•http://www.phpboost.com/upload/architecture_application_web.png
•http://www.fujitsu.com
•http://fr.sun.com/practice/software/soa/images/ig_soa_before.gif
•https://www-304.ibm.com/
•http://www.softeam.fr/technologies_web_services.php
Recherche bibliographique :
SOA, Le guide de l’architecte du SI ; de Xavier Fournier-Morel, Pascal Hrojean , Guillaume Plouin, Cyril Rognon
Edition SQLI ISBN 978-2-10-051708-4
Livre blanc :
•SOA : Architecture Logique Principes, structures et bonnes pratiques, Copyright ©
SOFTEAM 2007
•Méthodologie SOA en six domaines Révéler les avantages métiers d’une
Architecture Orientée Services Copyright © 2005 BEA Systems
•SOA et urbanisme Le rôle des Architectures Orientées Services dans
l’alignement métier des Systèmes d’Information Copyright © Unilog Management
•http://soa.sys-con.com/node/403065
•Les Architectures Orientées Services Copyright © www.syntec-informatique.fr
39
Question & Réponse
Merci
© Suzanne Porter
40