Téléchargé parsatmania
26 vues

Cours SOA - Service Oriented Architecture

600743747-service-oriented-architecture-cours-master-2-isi-esmt-22

Intégrer la présentation

Télécharger pour lire hors ligne
Service Oriented Architecture (SOA) Introduction à l’architecture orientée service
AGENDA Module 1 – SOA Overview  C’est quoi SOA ?  Définitions – concepts généraux  Les avantages à utiliser SOA ?  Insuffisances des solutions actuelles  Quand l’utiliser ?  Comment implémenter SOA ?  Méthodes et outils de mise en œuvre  Quand ne pas utiliser SOA ?  L’ESB – Entreprise Service Bus dans SOA  Les catégories de services SOA  La sécurité dans SOA  L’évolution vers SOA
AGENDA Module 2 – TP – Implémentation de web services SOAP TP – Implémentation de processus BPEL- BPMN  Installation du BPEL Designer 2.0  Installation du moteur d’exécution BPEL Apache ODE  Configuration de l’environnement de travail sous Eclipse  Implémentation des Web Service  Implémentation de business process BPEL – Orchestration
AGENDA Module 3 – Projet d’implementation d’une architecture SOA  Analyse complète du système  Extraction des fonctionnalités et des modules applicatifs  Définition et spécification des services réutilisables  Design de la nouvelle architecture  Présentation de l’architure finale  Squelettes de code et maquettes pour l’implémentation de l’architecture.
Module 1 – SOA Overview C’est quoi SOA ? Définitions – concepts généraux Les avantages à utiliser SOA ? Insuffisances des solutions actuelles Quand l’utiliser ? Comment implémenter SOA ? Méthodes et outils de mise en oeuvre Quand ne pas utiliser SOA ?
 Qu’est ce qu’un service ?  Dans la vie de tous les jours, nous utilisons fréquemment des services pour nous aider.  Ce sont des actions « précieuses » qui aident à répondre à une demande précise (système de lavage automatique, un restaurant et des services de transport sont des exemples de services). C’est quoi SOA ? Définitions – concepts généraux
 Qu’est ce qu’un service ?  Les logiciels utilisent également des services.  Dans l'industrie du logiciel, le déploiement d'un service signifie fournir un outil que d'autres logiciels peuvent utiliser pour réaliser leurs tâches.  Un service est externe au logiciel qui le demande. C’est quoi SOA ? Définitions – concepts généraux
 Qu’est ce qu’un service ?  Les services sont souvent associés à deux rôles :  Le demandeur de services, qui est le logiciel qui demande le service (Client)  Le fournisseur de services (Serveur), qui répond aux demandes. C’est quoi SOA ? Définitions – concepts généraux Client Serveur
 Qu’est ce que SOA ?  L'architecture orientée services examine comment créer, utiliser et combiner des services.  Au lieu de créer de grandes suites logicielles qui font tout, l’approche SOA atteint les objectifs logiciels en créant et en utilisant des services et en concevant une architecture qui prend en charge leur utilisation. C’est quoi SOA ? Définitions – concepts généraux
 Perception de SOA du point de vue des acteurs du système C’est quoi SOA ? Définitions – concepts généraux Dirigeants Analystes métier Un ensemble de services que l'entreprise souhaite exposer à leurs clients et partenaires, ou d'autres parties de l'organisation.
 Perception de SOA du point de vue des acteurs du système C’est quoi SOA ? Définitions – concepts généraux Architectes Un style architectural basé sur un fournisseur, un demandeur et une description de service, et supporte les propriétés de modularité, encapsulation, découplage, réutilisation et composabilité.
 Perception de SOA du point de vue des acteurs du système C’est quoi SOA ? Définitions – concepts généraux Développeurs Un modèle de programmation avec ses standards, paradigmes, outils et technologies associées.
 Perception de SOA du point de vue des acteurs du système C’est quoi SOA ? Définitions – concepts généraux Intégrateurs Un intergiciel offrant des fonctionnalités en terme d’assemblage, d’orchestration, de surveillance et de gestion des services.
 Les problématiques  Hétérogénéité des applications et des données du SI des entreprises due aux différents changements :  Rachat par une autre entreprise (fusion de groupe/Scissions)  Evolutions des technologies  Difficulté dans la diversification des offres commerciales  Spécialisation par métier (entité, service, etc…)  Cloisonnement des différents métiers  Impossibilité pour les décideurs d’avoir une vision d’ensemble et cohérente du SI. C’est quoi SOA ? Définitions – concepts généraux
 Les problématiques  L’activité doit piloter la technologie et non l’inverse. C’est quoi SOA ? Définitions – concepts généraux
 Les problématiques  La création d'applications dans l'entreprise est très souvent pilotée par des besoins à très court terme  Développement d'une application sous tel délai avec telles fonctionnalités.  Modélisation et développement dirigé par les choix/contraintes techniques  Pas de discussion entre maitrise d'ouvrage (MOA) et maitrise d'œuvre (MOE). C’est quoi SOA ? Définitions – concepts généraux
 Les problématiques  Le découpage en architecture 3-tiers classique (Présentation – Métier – Data) facilite le travail de la MOE mais favorise le cloisonnement en silos applicatifs indépendants (blocs monolithiques).  Certaines fonctions sont redondantes : une version pour chaque application.  Pas de mutualisation des développements entre projets et peu de réutilisation possible. C’est quoi SOA ? Définitions – concepts généraux
 Les problématiques (en gros) :  Développement coûteux  Interconnexions redondantes  Complexité de l’architecture  Maintenance difficile voire souvent impossible (swap précoce) C’est quoi SOA ? Définitions – concepts généraux
 La Solution :  L’intégration des applications de l’entreprise devient une nécessité.  L’idée est de développer des middlewares permettant de faire communiquer entre eux les différentes entités du SI. C’est quoi SOA ? Définitions – concepts généraux
 Les Principes de base de SOA C’est quoi SOA ? Définitions – concepts généraux Couplage faible de façon à minimiser les interdépendances Contrat de service Les services adhèrent à un accord de communication tel que défini collectivement par un ou plusieurs documents de description de service Abstraction des services Au-delà de ce qui est décrit dans le contrat de service, les services cachent la logique au monde extérieur
 Les Principes de base de SOA C’est quoi SOA ? Définitions – concepts généraux Réutilisation des services la logique encapsulée est elle- même organisée en services de façon à promouvoir la réutilisation Composabilité La capacité à regrouper plusieurs services de façon à former un nouveau service « composite » Autonomie de service Les services contrôlent la logique qu'ils encapsulent
 Les Principes de base de SOA C’est quoi SOA ? Définitions – concepts généraux Absence de contexte Interdiction formelle de conserver des informations spécifiques à une activité : Zéro contexte [stateless] ! Auto-description [discoverability] Organisation du service de façon à ce que ses capacités puissent être découvertes avec les outils de recherche disponibles
 Les avantages sur le business Les avantages à utiliser SOA ? Insuffisances des solutions actuelles Réduction des côuts • Améliore le retour sur investissement • Accroîssement des opportunités de revenus. • Construction plus rapide de nouveaux systèmes pour moins d'argent (frais d’intégration réduits du fait de sa flexibilité et de son interopérabilité)
 Les avantages sur le business Les avantages à utiliser SOA ? Insuffisances des solutions actuelles Augmentation de la productivité des employés • Offre la capacité à casser les barrières organisationnelles (silos) • Réduction en temps de cycle de développement des produits. • Facilite la gestion des processus métier.
 Les avantages sur le business Les avantages à utiliser SOA ? Insuffisances des solutions actuelles Favorise les partenariats • Basés sur les normes • Les relations commerciales sont exprimées via les interactions de services • L'intégration est motivée par ce qui est nécessaire, pas par ce qui est techniquement possible. Agilité - Construit pour le changement • Aide les applications à évoluer dans le temps et dans la durée • L'approche de mise en œuvre incrémentielle est prise en charge.
Les avantages à utiliser SOA ? Insuffisances des solutions actuelles Evolution des services • Capacité pour les entreprises à développer des applications sans remplacer les applications existantes. • Améliore les performances, la fonctionnalité d'un service => facilite la mise à niveau du système. • Permet de brancher de nouveaux services ou de mettre à niveau des services existants. • SOA a la capacité d'ajuster ou de modifier les différents environnements externes et les grandes applications peuvent être gérées facilement.  Les avantages techniques
 Les avantages techniques Les avantages à utiliser SOA ? Insuffisances des solutions actuelles Gestion des systèmes complexes • Réduction de la complexité de la solution facilitant ainsi sa maintenabilité. • Ne nécessite pas de services centralisés • Donne aux utilisateurs une communication de haut niveau avec les services. • Fournit des applications fiables dans lesquelles il est possible de tester et déboguer facilement et indépendamment les services. • L’intégration est standardisée.
 Les avantages techniques Les avantages à utiliser SOA ? Insuffisances des solutions actuelles Utilisation indépendante de la plateforme Le faible couplage permet la flexibilité • Il autorise ainsi les entreprises à sélectionner le logiciel ou le matériel de leur choix. • Il permet l'interaction de nouveaux canaux avec les clients, partenaires et fournisseurs.
Quand utiliser SOA ? Systèmes d'entreprise à grande échelle Fourniture de services à l'échelle d'Internet Réduction des coûts Abstraction de la mise en œuvre des fonctionnalités Réutilisation des processus métiers (use- cases multiples pour le même processus)
Comment implémenter SOA ? Méthodes et outils de mise en oeuvre Raisonner en termes Services et non en termes Objets Sélectionner les services à exposer Choisir un mécanisme de communication Penser à la sécurité Penser à la réutilisation
 Les éléments de construction  Services :  Une fonction ou un traitement métier bien défini, autonome et ne dépendant pas du contexte ou de l'état d'autres services  Connexions :  Lien reliant ces services distribués autonomes les uns aux autres (HTTP/SOAP par exemple pour les services web). Comment implémenter SOA ? Méthodes et outils de mise en oeuvre
Comment implémenter SOA ? Méthodes et outils de mise en oeuvre Client (Consumer) Recherche du service Serveur hébergeant les applications (Provider) publication du service (en WSDL) Service offert (dans le langage de la plate-forme) Requête Réponse Message XML Message XML Bibliothèque des descriptions des services offerts (au format UDDI) Souscription Publication Logique Métier sur la base des chaînes de valeur métier Logique Applicative sur la base de l’architecture des services offerts par l’application Protocole SOAP Invocation du service Web depuis le poste Client
 Les implémentations de SOA les plus répandues sont les web services :  Les services Web basés sur SOAP : SOAP est actuellement une spécification et un standard dans le monde internet mais REST n’est pas un standard et.  Les services Web basés sur REST : REST correspond à REpresentational State Transfert. Ce n’est pas un standard mais un style d’architecture qui répond à la complexité et aux limites des services basés sur SOAP. Comment implémenter SOA ? Méthodes et outils de mise en oeuvre
 SOA et Web Services (Il ne faut pas les confondre !) Comment implémenter SOA ? Méthodes et outils de mise en oeuvre SOA Web Services SOA est un style architectural et un ensemble de concepts : • Une SOA peut être mise en oeuvre sans Web Services. Les Web Services relèvent de la technologie : • On peut utiliser les Web Services sans faire de la SOA Les WS constituent à l’heure actuelle la meilleure solution standardisée disponible => Un service métier = un WebService
 Points d’attention dans l’adoption de SOA :  Une mauvaise attention accordée à la gestion des services peut entraîner des problèmes de performances et de fiabilité du système global.  Fournir une sécurité appropriée pour les différents rôles.  Assurer l'interopérabilité des services. Comment implémenter SOA ? Méthodes et outils de mise en oeuvre
Quand ne pas utiliser SOA ? Lorsque vous disposez d'un environnement informatique homogène Lorsque les performances en temps réel sont essentielles Lorsque le couplage fort est un avantage et non un inconvénient Quand les choses ne changent pas
ESB – Entreprise Service Bus
SOA – ESB (Entreprise Service Bus)  L'Enterprise Service Bus (ESB) est une architecture logicielle qui relie tous les services sur une infrastructure de type bus.  Il agit comme canal de communication dans la SOA en permettant de connecter plusieurs systèmes, applications et données sans interruption facilitant ainsi leurs interactions.
SOA – ESB (Entreprise Service Bus) Pourquoi utiliser un ESB ?  Rigidité des architectures logicielles  Coût d’exploitation et de maintenance élevé  Plusieurs infrastructures de communication  …
SOA – ESB (Entreprise Service Bus) - Pourquoi utiliser un ESB ? Billing DWH CRM BI Autres.. Web user interface Web user interface
SOA – ESB (Entreprise Service Bus) - Pourquoi utiliser un ESB ? Problèmes soulevés Billing DWH CRM BI Autres.. Web user interface Web user interface Les inconvénients d’une Integration E2E • Complexité accrue • Maintenance impossible (évolution ou correction) • Enormes impacts lors des « change request » • Flexibilité inexistante
SOA – ESB (Entreprise Service Bus) - Pourquoi utiliser un ESB ? Solution apportée Billing DWH CRM BI Autres.. Web user interface Web user interface ESB Services registry Admin Monitoring
 Gestion des services (services web, …)  Gestion de l’intégration basée sur les événements  Propose un socle pour l’orchestration entre différentes applications (services)  Technique (Routage, Médiation (décodage/encodage des données)  Métier (BPM – Business Process management)  L’ESB ne s’interface pas avec les utilisateurs SOA – ESB (Entreprise Service Bus) - Fonctionnalités ?
SOA ESB (Entreprise Service Bus) View Layer Web Clients applications Application Server Données Services Systems Des applications exécutées sur l’ordinateur de l’utilisateur et connectées au serveur. Entreprise Service Bus (ESB) L'ESB est placé entre le fournisseur de services et le demandeur. Les services et systèmes sont rattachés à l'ESB Applications BPEL BAM Business Process Execution Language Business Activity Monitoring BPM Business Process Management
SOA – ESB (Entreprise Service Bus)  Les fonctionnalités couvertes par l’ESB ESB Basics Gère la communication entre les applications logicielles dans une architecture orientée services via ESB (transfert de données, etc …) ESB Transaction Manager Lorsque plusieurs applications distribuées sont impliquées dans une transaction, au lieu de leur demander de se coordonner avec la transaction qu’elles ont initiée, l'ESB peut se synchroniser avec elle et fournir le service attendu.
SOA – ESB (Entreprise Service Bus)  Les fonctionnalités couvertes par l’ESB ESB Security Manager • Les mécanismes d'authentification et d'autorisation sont des éléments très importants du contrôle de sécurité qui sont intégrés dans un ESB. • L'ESB fournit ces mécanismes de sécurité pour interconnecter les applications.
SOA – ESB (Entreprise Service Bus)  Les fonctionnalités couvertes par l’ESB ESB as Service Proxy Le SOA utilise un proxy qui interprète les appels de services entre deux protocoles différents (Par exemple : RMI - Remote Method Invocation de Java) et SOAP).
SOA – ESB (Entreprise Service Bus)  Les fonctionnalités couvertes par l’ESB ESB as Gateway • Il agit comme un point d’entrée vers un autre réseau. • En tant que passerelle, il gère les données acheminées en interne ou en externe du réseau. • Si l'utilisateur souhaite accéder au service d'un réseau externe, il transmet le paquet de données à la passerelle, qui se connecte ensuite à la destination de service demandée.
SOA – ESB (Entreprise Service Bus)  Quelques manières d’implémenter un ESB  Intergiciels de type MOM (Message Oriented Middleware)  Intergiciels de type Bus (CORBA par exemple)  Routeurs Web services tel que WebSphere Web Services Gateway  Selon le type d’implémentation retenu, l’ESB assurera plus ou moins de « services » : le choix dépend des besoins.  L’ESB n’est pas obligatoire : mais il est fortement recommandé pour éviter le couplage entre fournisseur et demandeur.
SOA – ESB (Entreprise Service Bus)  Commercial  Microsoft Azure  IBM app connect  Mule ESB  SAP Process Integration  TIBCO Software  Open source software  Fuse ESB, Apache ServiceMix  JBoss ESB  WSO2 ESB  Spring Integration
BPM Business Process Management
BPM – Business Process Management  BPM donne à l’entreprise les moyens de gérer ses processus métiers de manière informatisée (modélisation, simulation, exécution et audit).  Un processus est le résultat d’une orchestration de services.  Il est composé de sous-processus, de points de décisions (Business rules) et d’activités  Les activités correspondent aux parties du processus métier qui n’incluent pas de décisions et peuvent aussi bien être réalisées par des systèmes ou des intervenants humains.
BPM – Business Process Management create loan app credit check pre- approved ? Loan Officer Approval approved ? Reserve Funds Assess Loan Risk Too Risky ? Send Confirmation Email Send Rejection Email Yes Yes Yes No No No Service (Web) Service (Web) Service (JavaMail) Service (JavaMail) Service (Web) Service (Staff) Human Interaction Business Rules Business Rules Business Rules BPM à l’oeuvre
BPEL Business Process ExecutionLanguage
BPEL – Business Process Execution Language  Standard de l’OASIS (Organization for the Advancement of Structured Information Standards), BPEL est une norme qui permet de décrire (en XML) et d’executer les processus métier (orchestration).  Il propose deux modèles de programmation : • Ce sont les non-programmeurs qui ici implémentant les différents workflow. • Ils combinent les fonctionnalités existantes pour construire les processus métier. Programmation « in the large » • Les programmeurs mettant en œuvre les différentes fonctionnalités. • Ils s’appuient sur des granularité de services fine. Programmation « in the small »
BPEL – Business Process Execution Language Receive Reste en attente de la réception d'un message du partenaire. Reply Activité de réception d’un message d’un partenaire. Invoke Emission d’une demande asynchrone.  Les principales activités intervenant dans l’orchestration :
BPEL – Business Process Execution Language  Orchestration des services : Orchestration (Coordinateur) Web Service 1 Web Service 3 Web Service 2 Web Service n … 1: Receive 5: Reply 3: Invoke 2: Invoke n: Invoke … : Invoke
BPEL – Business Process Execution Language  Les services Web forment, sans nul doute, une « grande technologie » mais, sans un moyen efficace de les gérer, ils ne parviendront pas à atteindre les objectifs d’une SOA.  BPEL offre une norme commune sur la façon de publier plusieurs services, de les orchestrer en processus métier, d'auditer et de gérer les résultats.
Présentation BPMN 2.0 Business Process Model Notation
BPMN - Avènement  Plusieurs langages étaient utilisés pour la gestion des processus métier avec deux tendances :  Les langages de modélisation (UML (diagramme d’activités), BPMN (version antérieure à 2.0), etc…)  Les langages servant à leur exécution (BPEL)  Ainsi, la version BPMN 2.0 a été rendue exécutable, rendant ainsi possible le passage du « process design » au « process implémentation » sans qu’il soit nécessaire de retoucher au modèle.
BPMN - Avènement BPMN 1.x BPEL BPMN 2.0
BPMN - Exemple
BPMN – Principaux constituants  Les événements  Les évènements sont modélisés sous la forme d’un point. Ils peuvent prendre plusieurs formes suivant qu’ils soient :  un évènement de départ (en vert)  un évènement intermédiaire (en violet) ou  un évènement de fin (en rouge)
BPMN – Principaux constituants  Les événements  BPMN permet aussi de spécifier la nature de l’évènement en recensent les différents types.  Un évènement peut être :  abstrait : il sera alors un point vide,  un message  une minuterie  un signal  une correction d’erreur ou  un arrêt
BPMN – Principaux constituants  Les tâches  Les tâches sont les éléments qui nécessitent la mobilisation des fonctions de l’organisation. Les actions peuvent être de différents types :  Il peut soit s’agir de tâches qui sont effectuées par des personnes (tâches humaines)  Si les tâches requièrent l’appel d’une fonction informatique, on parlera alors de tâche de service  Il se peut aussi qu’une tâche soit d’un type indéfini. On parlera alors de tâche abstraite  Enfin, il est possible qu’un tâche soit elle-même composée de tâches. On parlera alors de sous-processus.
BPMN – Principaux constituants  Les branchements  Le chemin que va prendre l’exécution d’un processus n’a pas besoin d’être déterminé à son début. Il peut être soumis à des conditions.  Ceux-ci sont de trois types :  les branchements parallèles,  les branchements exclusifs et  les branchements inclusifs.
BPMN – Exemple  Implémenter sous Modelio, le BPMN du processus décrit au slide 56.
Les catégories de Services dans SOA
ENTITY SERVICE TASK SERVICE UTILITY SERVICE PROXY SERVICE DEVICE SERVICE PROCESS SERVICE BUSINESS SERVICE Description  Le service est une sorte d'opération bien définie, autonome qui effectue une tâche spécifique.  Les Services SOA sont réparties en diverses catégories selon leur usage.
Entity Service  L’Entity Service a en charge la gestion des objets métier (ex. le bon de commande, le produit, la facture de commande, la commande, etc…).  Il permet de réaliser donc les opérations CRUD telles que créer, lire, supprimer et mettre à jour ces entités.  Ce type de services manipulent les informations sur les données métier stockées en base.
Task Service  Les Task Services ajoutent la logique métier aux autres services.  Ils fournissent les fonctionnalités de plusieurs entités, telles que l’établissement du bon de commande client, la création du numéro de bon de commande, la validation des détails du client, etc.  Ils ont la particularité de ne pas être assez réutilisables compte-tenu de leur forte orientation métier.
Utility Service  Les Utility Services (services utilitaires) fournissent des fonctionnalités techniques et transverses telles que la journalisation des événements, la création d'un numéro unique, la gestion des notifications, etc …  Ils ont donc la réputation d’être réutilisable du fait des traitements qu’ils réalisent.  Ces services contiennent de petits services qui sont utilisés comme blocs de construction dans les systèmes orientés services.
Proxy Service  Les Proxy Services sont des services qui servent de connexion entre les membres du système orienté services et les autres systèmes.  Très utiles lorsque ces systèmes utilisent des protocles différents  Ces services sont aussi appelés services de passerelle (Gateway Service).
Business Service  Les Business Service fournissent les fonctionnaliés métier.  Ils sont flexibles et permettent de modifier aisément les offres commerciales.  Ces services implémentent les fonctionnalités qui automatisent les processus métier telles que la gestion du service client, l'expédition du produit client etc...
Le cycle de vie d’un Service dans SOA
Cycle de vie des services dans SOA  Le cycle de vie des services dans SOA est constitué de 4 grandes phases :  Identification  Spécification  Développement  Gestion
Cycle de vie des services dans SOA Service Identified Search for Existing Implementation Service Owner Approval Service Reusability Commission Candidate Customers Identified Exist ? No Yes 1- Service Identification Service Specification Created Provider Interfaces Documented Service/Process Workflow created Service Specification Review 2- Service Specification Develop Components Integrate and Test Create Deployment Unit Acceptance Test Code in repository 3- Service Development Certify Service Service in registry Service in use Monitor Service Plan new Version Decommission Service Deactivate Service 4- Service Management
Analyste métier • Définit les processus métiers et les KPI associées • Identification des services métier et optimise les processus par des simulations Architecte Définit et modélise les services. Intégrateur Assemble les services Développeur Implémente les services Gestionnaire - Publie les services - Gère le cycle de vie des services - Contrôle la qualité de service Cycle de vie des services dans SOA - Rôles
Cycle de vie des services dans SOA La phase d’identification  Un des problèmes centraux pour mettre en œuvre une SOA est l’identification des services.  La granularité des services est fondamentale car elle détermine en grande partie la réutilisabilité des services.  Il faut d’une part, éviter une granularité trop « fine » qui entraîne :  beaucoup d’interactions et de problèmes de performance  D’autre part, éviter également une granularité trop « épaisse » car :  un service qui fait trop de choses risque de ne pas être réutilisable.  Il faut trouver le juste milieu
Cycle de vie des services dans SOA La phase d’identification  Deux méthodes d’identification des services 1. Approche Bottom-up :  On part des briques informatiques, on rassemble les bouts.  Elle est réalisée généralement par la MOE  Elle est plus adéquate pour réutiliser l’existant non encore pris en compte dans une SOA
Cycle de vie des services dans SOA La phase d’identification  Approche « Bottom-up » Besoins Dagrammes d’activités Diagramme de classes Orchestration Spécification des services Nouveaux Services + services réutilisables (existant) Nouvelle Application
Cycle de vie des services dans SOA La phase d’identification  Deux méthodes d’identification des services 2. Approche Top-down :  On part des interactions métier pour aboutir aux interactions techniques  Elle est réalisée généralement par la MOA  Elle est plus adéquate pour démarrer un nouveau projet
Cycle de vie des services dans SOA La phase d’identification  Approche « Top-Down » Besoins Décomposition du processus métier Analyse des domaines métier Orchestration Spécification des services Nouveaux Services + services réutilisables (existant) Nouvelle Application
La sécurité dans SOA Description Attaques dans SOA Approches de solution
Description  La sécurisation de l'architecture orientée services (SOA) est nécessaire pour garantir que les services et les applications fonctionnent en toute sécurité.  Les services exposés ne sont généralement pas protégés contre les attaques.  Leur sécurisation est donc essentielle du fait de l'exposition des services et du faible couplage des composants.
Les attaques dans SOA  Voici une liste d'attaques dans SOA:  Attaques par injection : Cette attaque peut se produire lorsqu'aucune validation sur l'entrée utilisateur n'est effectuée et qu'aucune séparation n'est effectuée entre l'entrée utilisateur et l'application (injection SQL, injection XML, etc).  Attaque par corruption du schéma : Cette attaque, lorsqu’elle se produit, modifie, remplace ou même endommage les schémas XML qui fournissent la structure des documents XML.  Attaques par déni de service (DoS) : Cette attaque, lorsqu'elle se produit, ne modifie pas le service ou son comportement, mais peut bloquer l'utilisation du service.
Approches de solutions  Les principales solutions sont les suivantes :  Définition d’une intégrité pour SOA qui fournit suffisamment de conditions pour sécuriser l'intégrité des données.  Implémentation un système de détection d'intrusion pour les réseaux SOA capables de détecter les intrusions affectant le comportement des services.  Implémentation d’un système de surveillance des messages SOAP.  …
Vers SOA …
SOA, une évolution et non une révolution
Vers SOA … Before SOA After SOA Closed – Monolithic - brittle Shared services – Collaborative – Interoperable Service Scheduling ------------ Check Customer status Order Processing ------------- Check Customer status Verify Customer Credit Account Management ------------- Order Status Check credit Application Dependent Business Functions Marketting Sales CRM Finance Data WareHouse Data Repository Composite Applications Composite Application Service Scheduling Order Processing Account Management Business Process Reusable Business Services Reusable Service Check Customer Status Check Order Status Reusable Service Reusable Service Reusable Service Check Credit Check Inventory Reusable Service Reusable Service Sales CRM Finance Data WareHouse Data Repository Marketting
Module 2 – Implémentations Web services – BPEL – BPMN 2.0 – Orchestration
Travail 1 BPEL Implémentation de processus BPEL avec Eclipse  Installation du plugin eclipse « BPEL Designer 2.0 »  Installation du moteur d’exécution « BPEL Apache ODE »  Configuration de l’environnement de travail sous Eclipse  Implémentation des web services utilisés pour l’orchestration  Implémentation des processus BPEL.
Travail 1 BPEL Implémentation de processus BPEL avec Eclipse
Travail 1 BPEL Implémentation de processus BPEL avec Eclipse
Module 3 – Projet Implémentation d’une architecture SOA
FIN Ghislain AKINOCHO Master SI 2 – Service Oriented Architecture - ESMT

Contenu connexe

PPT
SOA(Service Oriented Architecture)Architectures Orientées Services
parmohamedwalid38
 
PDF
eServices-Chp2: SOA
parLilia Sfaxi
 
PPTX
Architectures orientés services (SOA)
parHeithem Abbes
 
PPT
Soa
parm.dubucq
 
PDF
cours intoduction Soa_compress_Master.pdf
parmohamedwalid38
 
PPTX
Chp2 - SOA
parLilia Sfaxi
 
PPTX
Chp1- Introduction aux Technologies Web et SOA
parLilia Sfaxi
 
PPT
Introduction a la SOA
parTugdual Grall
 
SOA(Service Oriented Architecture)Architectures Orientées Services
parmohamedwalid38
 
eServices-Chp2: SOA
parLilia Sfaxi
 
Architectures orientés services (SOA)
parHeithem Abbes
 
Soa
parm.dubucq
 
cours intoduction Soa_compress_Master.pdf
parmohamedwalid38
 
Chp2 - SOA
parLilia Sfaxi
 
Chp1- Introduction aux Technologies Web et SOA
parLilia Sfaxi
 
Introduction a la SOA
parTugdual Grall
 

Similaire à Cours SOA - Service Oriented Architecture

PDF
1 - chapitre 1 chapitre 2 SOA.pdf
parhaythem bouzouraa
 
PPTX
Architecture orientée service (SOA)
parKlee Group
 
PDF
cours_SOA_AO+FB_en_informatique_SOA_.pdf
parwaliakeabraham
 
PDF
Cysoa formation-soa-architecture-orientee-services-synthese (1)
parCERTyou Formation
 
PDF
Cysoa formation-soa-architecture-orientee-services-synthese
parCERTyou Formation
 
PDF
Architectures orientées services
parDonia Hammami
 
PPTX
courwebwebewcourwebwebewcourwebwebewcourwebwebew.pptx
parlacinekabre1
 
PDF
SOA - Architecture Orientée Service : Démystification Khaled Ben Driss 17 Avr...
parKhaled Ben Driss
 
PPT
Senejug 240407 V4
parDouglas MBIANDOU
 
PDF
La SOA au sein des systèmes d'information
parFourat Zouari
 
PDF
Présentation du SOA et BPM par Rs2i_AtelierFocusInnovation_06022014
parMarc Bourhis
 
PPTX
ARCHITECTURE MICROSERVICE : TOUR D’HORIZON DU CONCEPT ET BONNES PRATIQUES
parSOAT
 
PDF
SOA - Architecture Orientée Service : Démystification
parKhaled Ben Driss
 
PDF
Interopérabilité des Services Web dans le cadre d’une Architecture SOA
parJean Paul Dongmo Miaffo
 
PDF
Soiré soire soa -logica
parAlahyane Ahmed
 
PPTX
Soa & services web
parGhazouani Mahdi
 
PDF
SOA - Architecture Orientée Service : Démystification Khaled Ben Driss 21 Nov...
parKhaled Ben Driss
 
PDF
Ouvrir son SI avec la trilogie Portail, SOA, BPM (Solutions Linux 2010 - cycl...
parMarc Dutoo
 
PDF
SOA facile en 10 pratiques avec EasySOA - Alpes JUG
parMarc Dutoo
 
PDF
PZ_Microservices101_20150210
parGregory Boissinot
 
1 - chapitre 1 chapitre 2 SOA.pdf
parhaythem bouzouraa
 
Architecture orientée service (SOA)
parKlee Group
 
cours_SOA_AO+FB_en_informatique_SOA_.pdf
parwaliakeabraham
 
Cysoa formation-soa-architecture-orientee-services-synthese (1)
parCERTyou Formation
 
Cysoa formation-soa-architecture-orientee-services-synthese
parCERTyou Formation
 
Architectures orientées services
parDonia Hammami
 
courwebwebewcourwebwebewcourwebwebewcourwebwebew.pptx
parlacinekabre1
 
SOA - Architecture Orientée Service : Démystification Khaled Ben Driss 17 Avr...
parKhaled Ben Driss
 
Senejug 240407 V4
parDouglas MBIANDOU
 
La SOA au sein des systèmes d'information
parFourat Zouari
 
Présentation du SOA et BPM par Rs2i_AtelierFocusInnovation_06022014
parMarc Bourhis
 
ARCHITECTURE MICROSERVICE : TOUR D’HORIZON DU CONCEPT ET BONNES PRATIQUES
parSOAT
 
SOA - Architecture Orientée Service : Démystification
parKhaled Ben Driss
 
Interopérabilité des Services Web dans le cadre d’une Architecture SOA
parJean Paul Dongmo Miaffo
 
Soiré soire soa -logica
parAlahyane Ahmed
 
Soa & services web
parGhazouani Mahdi
 
SOA - Architecture Orientée Service : Démystification Khaled Ben Driss 21 Nov...
parKhaled Ben Driss
 
Ouvrir son SI avec la trilogie Portail, SOA, BPM (Solutions Linux 2010 - cycl...
parMarc Dutoo
 
SOA facile en 10 pratiques avec EasySOA - Alpes JUG
parMarc Dutoo
 
PZ_Microservices101_20150210
parGregory Boissinot
 

Plus de satmania

PDF
introduction-aux-systemes-distribues.pdf
parsatmania
 
PDF
Python Parallel Programming Cookbook.pdf
parsatmania
 
PDF
Introduction to scala programming language
parsatmania
 
PDF
Introduction to scala programming language
parsatmania
 
PDF
Pages from 2024-07-eb-big-book-of-data-engineering-3rd-edition.pdf
parsatmania
 
PDF
Rappel sur OpenStack. GGMD remise à niveau
parsatmania
 
PDF
Schema XML - Langage de description et modélisation
parsatmania
 
PDF
devops _ 9 _version_numbering conventions
parsatmania
 
PDF
501284603- Cours-Maven outils de build
parsatmania
 
PDF
73897021456-Maven-Presenation-Part-1.pdf
parsatmania
 
PDF
696318550-5-Apache-Maven outils de build
parsatmania
 
PDF
GIT commands version control system and collaboration
parsatmania
 
PDF
627494168-Introduction-Aux-Outils-DevOps.pdf
parsatmania
 
introduction-aux-systemes-distribues.pdf
parsatmania
 
Python Parallel Programming Cookbook.pdf
parsatmania
 
Introduction to scala programming language
parsatmania
 
Introduction to scala programming language
parsatmania
 
Pages from 2024-07-eb-big-book-of-data-engineering-3rd-edition.pdf
parsatmania
 
Rappel sur OpenStack. GGMD remise à niveau
parsatmania
 
Schema XML - Langage de description et modélisation
parsatmania
 
devops _ 9 _version_numbering conventions
parsatmania
 
501284603- Cours-Maven outils de build
parsatmania
 
73897021456-Maven-Presenation-Part-1.pdf
parsatmania
 
696318550-5-Apache-Maven outils de build
parsatmania
 
GIT commands version control system and collaboration
parsatmania
 
627494168-Introduction-Aux-Outils-DevOps.pdf
parsatmania
 

Cours SOA - Service Oriented Architecture

  • 1.
    Service Oriented Architecture (SOA) Introductionà l’architecture orientée service
  • 2.
    AGENDA Module 1 – SOAOverview  C’est quoi SOA ?  Définitions – concepts généraux  Les avantages à utiliser SOA ?  Insuffisances des solutions actuelles  Quand l’utiliser ?  Comment implémenter SOA ?  Méthodes et outils de mise en œuvre  Quand ne pas utiliser SOA ?  L’ESB – Entreprise Service Bus dans SOA  Les catégories de services SOA  La sécurité dans SOA  L’évolution vers SOA
  • 3.
    AGENDA Module 2 – TP– Implémentation de web services SOAP TP – Implémentation de processus BPEL- BPMN  Installation du BPEL Designer 2.0  Installation du moteur d’exécution BPEL Apache ODE  Configuration de l’environnement de travail sous Eclipse  Implémentation des Web Service  Implémentation de business process BPEL – Orchestration
  • 4.
    AGENDA Module 3 – Projet d’implementation d’unearchitecture SOA  Analyse complète du système  Extraction des fonctionnalités et des modules applicatifs  Définition et spécification des services réutilisables  Design de la nouvelle architecture  Présentation de l’architure finale  Squelettes de code et maquettes pour l’implémentation de l’architecture.
  • 5.
    Module 1 – SOAOverview C’est quoi SOA ? Définitions – concepts généraux Les avantages à utiliser SOA ? Insuffisances des solutions actuelles Quand l’utiliser ? Comment implémenter SOA ? Méthodes et outils de mise en oeuvre Quand ne pas utiliser SOA ?
  • 6.
     Qu’est cequ’un service ?  Dans la vie de tous les jours, nous utilisons fréquemment des services pour nous aider.  Ce sont des actions « précieuses » qui aident à répondre à une demande précise (système de lavage automatique, un restaurant et des services de transport sont des exemples de services). C’est quoi SOA ? Définitions – concepts généraux
  • 7.
     Qu’est cequ’un service ?  Les logiciels utilisent également des services.  Dans l'industrie du logiciel, le déploiement d'un service signifie fournir un outil que d'autres logiciels peuvent utiliser pour réaliser leurs tâches.  Un service est externe au logiciel qui le demande. C’est quoi SOA ? Définitions – concepts généraux
  • 8.
     Qu’est cequ’un service ?  Les services sont souvent associés à deux rôles :  Le demandeur de services, qui est le logiciel qui demande le service (Client)  Le fournisseur de services (Serveur), qui répond aux demandes. C’est quoi SOA ? Définitions – concepts généraux Client Serveur
  • 9.
     Qu’est ceque SOA ?  L'architecture orientée services examine comment créer, utiliser et combiner des services.  Au lieu de créer de grandes suites logicielles qui font tout, l’approche SOA atteint les objectifs logiciels en créant et en utilisant des services et en concevant une architecture qui prend en charge leur utilisation. C’est quoi SOA ? Définitions – concepts généraux
  • 10.
     Perception deSOA du point de vue des acteurs du système C’est quoi SOA ? Définitions – concepts généraux Dirigeants Analystes métier Un ensemble de services que l'entreprise souhaite exposer à leurs clients et partenaires, ou d'autres parties de l'organisation.
  • 11.
     Perception deSOA du point de vue des acteurs du système C’est quoi SOA ? Définitions – concepts généraux Architectes Un style architectural basé sur un fournisseur, un demandeur et une description de service, et supporte les propriétés de modularité, encapsulation, découplage, réutilisation et composabilité.
  • 12.
     Perception deSOA du point de vue des acteurs du système C’est quoi SOA ? Définitions – concepts généraux Développeurs Un modèle de programmation avec ses standards, paradigmes, outils et technologies associées.
  • 13.
     Perception deSOA du point de vue des acteurs du système C’est quoi SOA ? Définitions – concepts généraux Intégrateurs Un intergiciel offrant des fonctionnalités en terme d’assemblage, d’orchestration, de surveillance et de gestion des services.
  • 14.
     Les problématiques Hétérogénéité des applications et des données du SI des entreprises due aux différents changements :  Rachat par une autre entreprise (fusion de groupe/Scissions)  Evolutions des technologies  Difficulté dans la diversification des offres commerciales  Spécialisation par métier (entité, service, etc…)  Cloisonnement des différents métiers  Impossibilité pour les décideurs d’avoir une vision d’ensemble et cohérente du SI. C’est quoi SOA ? Définitions – concepts généraux
  • 15.
     Les problématiques L’activité doit piloter la technologie et non l’inverse. C’est quoi SOA ? Définitions – concepts généraux
  • 16.
     Les problématiques La création d'applications dans l'entreprise est très souvent pilotée par des besoins à très court terme  Développement d'une application sous tel délai avec telles fonctionnalités.  Modélisation et développement dirigé par les choix/contraintes techniques  Pas de discussion entre maitrise d'ouvrage (MOA) et maitrise d'œuvre (MOE). C’est quoi SOA ? Définitions – concepts généraux
  • 17.
     Les problématiques Le découpage en architecture 3-tiers classique (Présentation – Métier – Data) facilite le travail de la MOE mais favorise le cloisonnement en silos applicatifs indépendants (blocs monolithiques).  Certaines fonctions sont redondantes : une version pour chaque application.  Pas de mutualisation des développements entre projets et peu de réutilisation possible. C’est quoi SOA ? Définitions – concepts généraux
  • 18.
     Les problématiques(en gros) :  Développement coûteux  Interconnexions redondantes  Complexité de l’architecture  Maintenance difficile voire souvent impossible (swap précoce) C’est quoi SOA ? Définitions – concepts généraux
  • 19.
     La Solution:  L’intégration des applications de l’entreprise devient une nécessité.  L’idée est de développer des middlewares permettant de faire communiquer entre eux les différentes entités du SI. C’est quoi SOA ? Définitions – concepts généraux
  • 20.
     Les Principesde base de SOA C’est quoi SOA ? Définitions – concepts généraux Couplage faible de façon à minimiser les interdépendances Contrat de service Les services adhèrent à un accord de communication tel que défini collectivement par un ou plusieurs documents de description de service Abstraction des services Au-delà de ce qui est décrit dans le contrat de service, les services cachent la logique au monde extérieur
  • 21.
     Les Principesde base de SOA C’est quoi SOA ? Définitions – concepts généraux Réutilisation des services la logique encapsulée est elle- même organisée en services de façon à promouvoir la réutilisation Composabilité La capacité à regrouper plusieurs services de façon à former un nouveau service « composite » Autonomie de service Les services contrôlent la logique qu'ils encapsulent
  • 22.
     Les Principesde base de SOA C’est quoi SOA ? Définitions – concepts généraux Absence de contexte Interdiction formelle de conserver des informations spécifiques à une activité : Zéro contexte [stateless] ! Auto-description [discoverability] Organisation du service de façon à ce que ses capacités puissent être découvertes avec les outils de recherche disponibles
  • 23.
     Les avantagessur le business Les avantages à utiliser SOA ? Insuffisances des solutions actuelles Réduction des côuts • Améliore le retour sur investissement • Accroîssement des opportunités de revenus. • Construction plus rapide de nouveaux systèmes pour moins d'argent (frais d’intégration réduits du fait de sa flexibilité et de son interopérabilité)
  • 24.
     Les avantagessur le business Les avantages à utiliser SOA ? Insuffisances des solutions actuelles Augmentation de la productivité des employés • Offre la capacité à casser les barrières organisationnelles (silos) • Réduction en temps de cycle de développement des produits. • Facilite la gestion des processus métier.
  • 25.
     Les avantagessur le business Les avantages à utiliser SOA ? Insuffisances des solutions actuelles Favorise les partenariats • Basés sur les normes • Les relations commerciales sont exprimées via les interactions de services • L'intégration est motivée par ce qui est nécessaire, pas par ce qui est techniquement possible. Agilité - Construit pour le changement • Aide les applications à évoluer dans le temps et dans la durée • L'approche de mise en œuvre incrémentielle est prise en charge.
  • 26.
    Les avantages àutiliser SOA ? Insuffisances des solutions actuelles Evolution des services • Capacité pour les entreprises à développer des applications sans remplacer les applications existantes. • Améliore les performances, la fonctionnalité d'un service => facilite la mise à niveau du système. • Permet de brancher de nouveaux services ou de mettre à niveau des services existants. • SOA a la capacité d'ajuster ou de modifier les différents environnements externes et les grandes applications peuvent être gérées facilement.  Les avantages techniques
  • 27.
     Les avantagestechniques Les avantages à utiliser SOA ? Insuffisances des solutions actuelles Gestion des systèmes complexes • Réduction de la complexité de la solution facilitant ainsi sa maintenabilité. • Ne nécessite pas de services centralisés • Donne aux utilisateurs une communication de haut niveau avec les services. • Fournit des applications fiables dans lesquelles il est possible de tester et déboguer facilement et indépendamment les services. • L’intégration est standardisée.
  • 28.
     Les avantagestechniques Les avantages à utiliser SOA ? Insuffisances des solutions actuelles Utilisation indépendante de la plateforme Le faible couplage permet la flexibilité • Il autorise ainsi les entreprises à sélectionner le logiciel ou le matériel de leur choix. • Il permet l'interaction de nouveaux canaux avec les clients, partenaires et fournisseurs.
  • 29.
    Quand utiliser SOA? Systèmes d'entreprise à grande échelle Fourniture de services à l'échelle d'Internet Réduction des coûts Abstraction de la mise en œuvre des fonctionnalités Réutilisation des processus métiers (use- cases multiples pour le même processus)
  • 30.
    Comment implémenter SOA ? Méthodeset outils de mise en oeuvre Raisonner en termes Services et non en termes Objets Sélectionner les services à exposer Choisir un mécanisme de communication Penser à la sécurité Penser à la réutilisation
  • 31.
     Les élémentsde construction  Services :  Une fonction ou un traitement métier bien défini, autonome et ne dépendant pas du contexte ou de l'état d'autres services  Connexions :  Lien reliant ces services distribués autonomes les uns aux autres (HTTP/SOAP par exemple pour les services web). Comment implémenter SOA ? Méthodes et outils de mise en oeuvre
  • 32.
    Comment implémenter SOA ? Méthodeset outils de mise en oeuvre Client (Consumer) Recherche du service Serveur hébergeant les applications (Provider) publication du service (en WSDL) Service offert (dans le langage de la plate-forme) Requête Réponse Message XML Message XML Bibliothèque des descriptions des services offerts (au format UDDI) Souscription Publication Logique Métier sur la base des chaînes de valeur métier Logique Applicative sur la base de l’architecture des services offerts par l’application Protocole SOAP Invocation du service Web depuis le poste Client
  • 33.
     Les implémentationsde SOA les plus répandues sont les web services :  Les services Web basés sur SOAP : SOAP est actuellement une spécification et un standard dans le monde internet mais REST n’est pas un standard et.  Les services Web basés sur REST : REST correspond à REpresentational State Transfert. Ce n’est pas un standard mais un style d’architecture qui répond à la complexité et aux limites des services basés sur SOAP. Comment implémenter SOA ? Méthodes et outils de mise en oeuvre
  • 34.
     SOA etWeb Services (Il ne faut pas les confondre !) Comment implémenter SOA ? Méthodes et outils de mise en oeuvre SOA Web Services SOA est un style architectural et un ensemble de concepts : • Une SOA peut être mise en oeuvre sans Web Services. Les Web Services relèvent de la technologie : • On peut utiliser les Web Services sans faire de la SOA Les WS constituent à l’heure actuelle la meilleure solution standardisée disponible => Un service métier = un WebService
  • 35.
     Points d’attentiondans l’adoption de SOA :  Une mauvaise attention accordée à la gestion des services peut entraîner des problèmes de performances et de fiabilité du système global.  Fournir une sécurité appropriée pour les différents rôles.  Assurer l'interopérabilité des services. Comment implémenter SOA ? Méthodes et outils de mise en oeuvre
  • 36.
    Quand ne pasutiliser SOA ? Lorsque vous disposez d'un environnement informatique homogène Lorsque les performances en temps réel sont essentielles Lorsque le couplage fort est un avantage et non un inconvénient Quand les choses ne changent pas
  • 37.
  • 38.
    SOA – ESB(Entreprise Service Bus)  L'Enterprise Service Bus (ESB) est une architecture logicielle qui relie tous les services sur une infrastructure de type bus.  Il agit comme canal de communication dans la SOA en permettant de connecter plusieurs systèmes, applications et données sans interruption facilitant ainsi leurs interactions.
  • 39.
    SOA – ESB(Entreprise Service Bus) Pourquoi utiliser un ESB ?  Rigidité des architectures logicielles  Coût d’exploitation et de maintenance élevé  Plusieurs infrastructures de communication  …
  • 40.
    SOA – ESB(Entreprise Service Bus) - Pourquoi utiliser un ESB ? Billing DWH CRM BI Autres.. Web user interface Web user interface
  • 41.
    SOA – ESB(Entreprise Service Bus) - Pourquoi utiliser un ESB ? Problèmes soulevés Billing DWH CRM BI Autres.. Web user interface Web user interface Les inconvénients d’une Integration E2E • Complexité accrue • Maintenance impossible (évolution ou correction) • Enormes impacts lors des « change request » • Flexibilité inexistante
  • 42.
    SOA – ESB(Entreprise Service Bus) - Pourquoi utiliser un ESB ? Solution apportée Billing DWH CRM BI Autres.. Web user interface Web user interface ESB Services registry Admin Monitoring
  • 43.
     Gestion desservices (services web, …)  Gestion de l’intégration basée sur les événements  Propose un socle pour l’orchestration entre différentes applications (services)  Technique (Routage, Médiation (décodage/encodage des données)  Métier (BPM – Business Process management)  L’ESB ne s’interface pas avec les utilisateurs SOA – ESB (Entreprise Service Bus) - Fonctionnalités ?
  • 44.
    SOA ESB (Entreprise ServiceBus) View Layer Web Clients applications Application Server Données Services Systems Des applications exécutées sur l’ordinateur de l’utilisateur et connectées au serveur. Entreprise Service Bus (ESB) L'ESB est placé entre le fournisseur de services et le demandeur. Les services et systèmes sont rattachés à l'ESB Applications BPEL BAM Business Process Execution Language Business Activity Monitoring BPM Business Process Management
  • 45.
    SOA – ESB(Entreprise Service Bus)  Les fonctionnalités couvertes par l’ESB ESB Basics Gère la communication entre les applications logicielles dans une architecture orientée services via ESB (transfert de données, etc …) ESB Transaction Manager Lorsque plusieurs applications distribuées sont impliquées dans une transaction, au lieu de leur demander de se coordonner avec la transaction qu’elles ont initiée, l'ESB peut se synchroniser avec elle et fournir le service attendu.
  • 46.
    SOA – ESB(Entreprise Service Bus)  Les fonctionnalités couvertes par l’ESB ESB Security Manager • Les mécanismes d'authentification et d'autorisation sont des éléments très importants du contrôle de sécurité qui sont intégrés dans un ESB. • L'ESB fournit ces mécanismes de sécurité pour interconnecter les applications.
  • 47.
    SOA – ESB(Entreprise Service Bus)  Les fonctionnalités couvertes par l’ESB ESB as Service Proxy Le SOA utilise un proxy qui interprète les appels de services entre deux protocoles différents (Par exemple : RMI - Remote Method Invocation de Java) et SOAP).
  • 48.
    SOA – ESB(Entreprise Service Bus)  Les fonctionnalités couvertes par l’ESB ESB as Gateway • Il agit comme un point d’entrée vers un autre réseau. • En tant que passerelle, il gère les données acheminées en interne ou en externe du réseau. • Si l'utilisateur souhaite accéder au service d'un réseau externe, il transmet le paquet de données à la passerelle, qui se connecte ensuite à la destination de service demandée.
  • 49.
    SOA – ESB(Entreprise Service Bus)  Quelques manières d’implémenter un ESB  Intergiciels de type MOM (Message Oriented Middleware)  Intergiciels de type Bus (CORBA par exemple)  Routeurs Web services tel que WebSphere Web Services Gateway  Selon le type d’implémentation retenu, l’ESB assurera plus ou moins de « services » : le choix dépend des besoins.  L’ESB n’est pas obligatoire : mais il est fortement recommandé pour éviter le couplage entre fournisseur et demandeur.
  • 50.
    SOA – ESB(Entreprise Service Bus)  Commercial  Microsoft Azure  IBM app connect  Mule ESB  SAP Process Integration  TIBCO Software  Open source software  Fuse ESB, Apache ServiceMix  JBoss ESB  WSO2 ESB  Spring Integration
  • 51.
  • 52.
    BPM – BusinessProcess Management  BPM donne à l’entreprise les moyens de gérer ses processus métiers de manière informatisée (modélisation, simulation, exécution et audit).  Un processus est le résultat d’une orchestration de services.  Il est composé de sous-processus, de points de décisions (Business rules) et d’activités  Les activités correspondent aux parties du processus métier qui n’incluent pas de décisions et peuvent aussi bien être réalisées par des systèmes ou des intervenants humains.
  • 53.
    BPM – Business Process Management create loan appcredit check pre- approved ? Loan Officer Approval approved ? Reserve Funds Assess Loan Risk Too Risky ? Send Confirmation Email Send Rejection Email Yes Yes Yes No No No Service (Web) Service (Web) Service (JavaMail) Service (JavaMail) Service (Web) Service (Staff) Human Interaction Business Rules Business Rules Business Rules BPM à l’oeuvre
  • 54.
  • 55.
    BPEL – BusinessProcess Execution Language  Standard de l’OASIS (Organization for the Advancement of Structured Information Standards), BPEL est une norme qui permet de décrire (en XML) et d’executer les processus métier (orchestration).  Il propose deux modèles de programmation : • Ce sont les non-programmeurs qui ici implémentant les différents workflow. • Ils combinent les fonctionnalités existantes pour construire les processus métier. Programmation « in the large » • Les programmeurs mettant en œuvre les différentes fonctionnalités. • Ils s’appuient sur des granularité de services fine. Programmation « in the small »
  • 56.
    BPEL – BusinessProcess Execution Language Receive Reste en attente de la réception d'un message du partenaire. Reply Activité de réception d’un message d’un partenaire. Invoke Emission d’une demande asynchrone.  Les principales activités intervenant dans l’orchestration :
  • 57.
    BPEL – BusinessProcess Execution Language  Orchestration des services : Orchestration (Coordinateur) Web Service 1 Web Service 3 Web Service 2 Web Service n … 1: Receive 5: Reply 3: Invoke 2: Invoke n: Invoke … : Invoke
  • 58.
    BPEL – BusinessProcess Execution Language  Les services Web forment, sans nul doute, une « grande technologie » mais, sans un moyen efficace de les gérer, ils ne parviendront pas à atteindre les objectifs d’une SOA.  BPEL offre une norme commune sur la façon de publier plusieurs services, de les orchestrer en processus métier, d'auditer et de gérer les résultats.
  • 59.
  • 60.
    BPMN - Avènement Plusieurs langages étaient utilisés pour la gestion des processus métier avec deux tendances :  Les langages de modélisation (UML (diagramme d’activités), BPMN (version antérieure à 2.0), etc…)  Les langages servant à leur exécution (BPEL)  Ainsi, la version BPMN 2.0 a été rendue exécutable, rendant ainsi possible le passage du « process design » au « process implémentation » sans qu’il soit nécessaire de retoucher au modèle.
  • 61.
    BPMN - Avènement BPMN1.x BPEL BPMN 2.0
  • 62.
  • 63.
    BPMN – Principauxconstituants  Les événements  Les évènements sont modélisés sous la forme d’un point. Ils peuvent prendre plusieurs formes suivant qu’ils soient :  un évènement de départ (en vert)  un évènement intermédiaire (en violet) ou  un évènement de fin (en rouge)
  • 64.
    BPMN – Principauxconstituants  Les événements  BPMN permet aussi de spécifier la nature de l’évènement en recensent les différents types.  Un évènement peut être :  abstrait : il sera alors un point vide,  un message  une minuterie  un signal  une correction d’erreur ou  un arrêt
  • 65.
    BPMN – Principauxconstituants  Les tâches  Les tâches sont les éléments qui nécessitent la mobilisation des fonctions de l’organisation. Les actions peuvent être de différents types :  Il peut soit s’agir de tâches qui sont effectuées par des personnes (tâches humaines)  Si les tâches requièrent l’appel d’une fonction informatique, on parlera alors de tâche de service  Il se peut aussi qu’une tâche soit d’un type indéfini. On parlera alors de tâche abstraite  Enfin, il est possible qu’un tâche soit elle-même composée de tâches. On parlera alors de sous-processus.
  • 66.
    BPMN – Principauxconstituants  Les branchements  Le chemin que va prendre l’exécution d’un processus n’a pas besoin d’être déterminé à son début. Il peut être soumis à des conditions.  Ceux-ci sont de trois types :  les branchements parallèles,  les branchements exclusifs et  les branchements inclusifs.
  • 67.
    BPMN – Exemple Implémenter sous Modelio, le BPMN du processus décrit au slide 56.
  • 68.
  • 69.
    ENTITY SERVICE TASK SERVICE UTILITY SERVICE PROXY SERVICE DEVICE SERVICE PROCESS SERVICE BUSINESS SERVICE Description Le service est une sorte d'opération bien définie, autonome qui effectue une tâche spécifique.  Les Services SOA sont réparties en diverses catégories selon leur usage.
  • 70.
    Entity Service  L’EntityService a en charge la gestion des objets métier (ex. le bon de commande, le produit, la facture de commande, la commande, etc…).  Il permet de réaliser donc les opérations CRUD telles que créer, lire, supprimer et mettre à jour ces entités.  Ce type de services manipulent les informations sur les données métier stockées en base.
  • 71.
    Task Service  LesTask Services ajoutent la logique métier aux autres services.  Ils fournissent les fonctionnalités de plusieurs entités, telles que l’établissement du bon de commande client, la création du numéro de bon de commande, la validation des détails du client, etc.  Ils ont la particularité de ne pas être assez réutilisables compte-tenu de leur forte orientation métier.
  • 72.
    Utility Service  LesUtility Services (services utilitaires) fournissent des fonctionnalités techniques et transverses telles que la journalisation des événements, la création d'un numéro unique, la gestion des notifications, etc …  Ils ont donc la réputation d’être réutilisable du fait des traitements qu’ils réalisent.  Ces services contiennent de petits services qui sont utilisés comme blocs de construction dans les systèmes orientés services.
  • 73.
    Proxy Service  LesProxy Services sont des services qui servent de connexion entre les membres du système orienté services et les autres systèmes.  Très utiles lorsque ces systèmes utilisent des protocles différents  Ces services sont aussi appelés services de passerelle (Gateway Service).
  • 74.
    Business Service  LesBusiness Service fournissent les fonctionnaliés métier.  Ils sont flexibles et permettent de modifier aisément les offres commerciales.  Ces services implémentent les fonctionnalités qui automatisent les processus métier telles que la gestion du service client, l'expédition du produit client etc...
  • 75.
    Le cycle devie d’un Service dans SOA
  • 76.
    Cycle de viedes services dans SOA  Le cycle de vie des services dans SOA est constitué de 4 grandes phases :  Identification  Spécification  Développement  Gestion
  • 77.
    Cycle de vie des services dans SOA Service Identified Search for Existing Implementation ServiceOwner Approval Service Reusability Commission Candidate Customers Identified Exist ? No Yes 1- Service Identification Service Specification Created Provider Interfaces Documented Service/Process Workflow created Service Specification Review 2- Service Specification Develop Components Integrate and Test Create Deployment Unit Acceptance Test Code in repository 3- Service Development Certify Service Service in registry Service in use Monitor Service Plan new Version Decommission Service Deactivate Service 4- Service Management
  • 78.
    Analyste métier • Définitles processus métiers et les KPI associées • Identification des services métier et optimise les processus par des simulations Architecte Définit et modélise les services. Intégrateur Assemble les services Développeur Implémente les services Gestionnaire - Publie les services - Gère le cycle de vie des services - Contrôle la qualité de service Cycle de vie des services dans SOA - Rôles
  • 79.
    Cycle de viedes services dans SOA La phase d’identification  Un des problèmes centraux pour mettre en œuvre une SOA est l’identification des services.  La granularité des services est fondamentale car elle détermine en grande partie la réutilisabilité des services.  Il faut d’une part, éviter une granularité trop « fine » qui entraîne :  beaucoup d’interactions et de problèmes de performance  D’autre part, éviter également une granularité trop « épaisse » car :  un service qui fait trop de choses risque de ne pas être réutilisable.  Il faut trouver le juste milieu
  • 80.
    Cycle de viedes services dans SOA La phase d’identification  Deux méthodes d’identification des services 1. Approche Bottom-up :  On part des briques informatiques, on rassemble les bouts.  Elle est réalisée généralement par la MOE  Elle est plus adéquate pour réutiliser l’existant non encore pris en compte dans une SOA
  • 81.
    Cycle de viedes services dans SOA La phase d’identification  Approche « Bottom-up » Besoins Dagrammes d’activités Diagramme de classes Orchestration Spécification des services Nouveaux Services + services réutilisables (existant) Nouvelle Application
  • 82.
    Cycle de viedes services dans SOA La phase d’identification  Deux méthodes d’identification des services 2. Approche Top-down :  On part des interactions métier pour aboutir aux interactions techniques  Elle est réalisée généralement par la MOA  Elle est plus adéquate pour démarrer un nouveau projet
  • 83.
    Cycle de viedes services dans SOA La phase d’identification  Approche « Top-Down » Besoins Décomposition du processus métier Analyse des domaines métier Orchestration Spécification des services Nouveaux Services + services réutilisables (existant) Nouvelle Application
  • 84.
    La sécurité dans SOA Description Attaquesdans SOA Approches de solution
  • 85.
    Description  La sécurisationde l'architecture orientée services (SOA) est nécessaire pour garantir que les services et les applications fonctionnent en toute sécurité.  Les services exposés ne sont généralement pas protégés contre les attaques.  Leur sécurisation est donc essentielle du fait de l'exposition des services et du faible couplage des composants.
  • 86.
    Les attaques dansSOA  Voici une liste d'attaques dans SOA:  Attaques par injection : Cette attaque peut se produire lorsqu'aucune validation sur l'entrée utilisateur n'est effectuée et qu'aucune séparation n'est effectuée entre l'entrée utilisateur et l'application (injection SQL, injection XML, etc).  Attaque par corruption du schéma : Cette attaque, lorsqu’elle se produit, modifie, remplace ou même endommage les schémas XML qui fournissent la structure des documents XML.  Attaques par déni de service (DoS) : Cette attaque, lorsqu'elle se produit, ne modifie pas le service ou son comportement, mais peut bloquer l'utilisation du service.
  • 87.
    Approches de solutions Les principales solutions sont les suivantes :  Définition d’une intégrité pour SOA qui fournit suffisamment de conditions pour sécuriser l'intégrité des données.  Implémentation un système de détection d'intrusion pour les réseaux SOA capables de détecter les intrusions affectant le comportement des services.  Implémentation d’un système de surveillance des messages SOAP.  …
  • 88.
  • 89.
    SOA, une évolutionet non une révolution
  • 90.
    Vers SOA … Before SOA AfterSOA Closed – Monolithic - brittle Shared services – Collaborative – Interoperable Service Scheduling ------------ Check Customer status Order Processing ------------- Check Customer status Verify Customer Credit Account Management ------------- Order Status Check credit Application Dependent Business Functions Marketting Sales CRM Finance Data WareHouse Data Repository Composite Applications Composite Application Service Scheduling Order Processing Account Management Business Process Reusable Business Services Reusable Service Check Customer Status Check Order Status Reusable Service Reusable Service Reusable Service Check Credit Check Inventory Reusable Service Reusable Service Sales CRM Finance Data WareHouse Data Repository Marketting
  • 91.
    Module 2 –Implémentations Web services – BPEL – BPMN 2.0 – Orchestration
  • 92.
    Travail 1 BPEL Implémentation de processusBPEL avec Eclipse  Installation du plugin eclipse « BPEL Designer 2.0 »  Installation du moteur d’exécution « BPEL Apache ODE »  Configuration de l’environnement de travail sous Eclipse  Implémentation des web services utilisés pour l’orchestration  Implémentation des processus BPEL.
  • 93.
  • 94.
  • 95.
    Module 3 –Projet Implémentation d’une architecture SOA
  • 96.
    FIN Ghislain AKINOCHO Master SI2 – Service Oriented Architecture - ESMT