Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

(c) 2007, Occello Audrey, SAR O2/SAR O3 SOA - 1 - Introduction à l’Architecture

(c) 2007, Occello Audrey, SAR O2/SAR O3 SOA - 1 - Introduction à l’Architecture Orientée Service Modules SAR O2/SAR O3 – SI3 Revu par F. Baude, M2 MIAGE NTDP, 2008 (essentiellement simplification, raccourcissements, + quelques details) (c) 2007, Occello Audrey, SAR O2/SAR O3 SOA - 2 - Chaque rôle s'approprie SOA différemment : Vous avez dit SOA? Service Oriented Architecture Un ensemble de services que l'entreprise souhaite exposer à leurs clients et partenaires, ou d'autres parties de l'organisation Un modèle de programmation avec ses standards, paradigmes, outils et technologies associées 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é Un intergiciel offrant des fonctionnalités en terme d'assemblage, d'orchestration, de surveillance et de gestion des services Dirigeants Analystes métier Architectes Développeurs Intégrateurs (c) 2007, Occello Audrey, SAR O2/SAR O3 SOA - 3 - Plan du cours • A quels besoins répond le SOA ? • Pourquoi les solutions actuelles sont insuffisantes ? • Quels sont les principes de base du SOA ? • Quels sont les éléments clé d’une architecture orientée services ? • Quel est le cycle de vie d’un service ? • Quelles méthodes et outils permettent de mettre en oeuvre une architecture orientée services ? (c) 2007, Occello Audrey, SAR O2/SAR O3 SOA - 4 - A quels besoins répond le SOA ? Pourquoi les solutions actuelles sont insuffisantes ? (c) 2007, Occello Audrey, SAR O2/SAR O3 SOA - 5 - Problématique de l’intégration en entreprise • Les entreprises doivent s’adapter en permanence et être de + en + réactives aux variations des marchés • fusions • acquisitions • scissions • diversification des offres commerciales • changement technologiques • … • Ces opérations ont un impact sur le système d'information (SI) des entreprises • L'intégration difficile des SI est un frein à ces changements C’est l’activité qui doit piloter la technologie et non l’inverse (c) 2007, Occello Audrey, SAR O2/SAR O3 SOA - 6 - Problématique de l’intégration en entreprise • 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'oeuvre (MOE) Décalage entre besoins métier et leur réalisation (constituants informatiques) Pas de place pour la prise en compte de l'évolution des besoins fonctionnels au niveau de l'application (c) 2007, Occello Audrey, SAR O2/SAR O3 SOA - 7 - Problématique de l’intégration en entreprise • Le découpage présentation/traitement/base de données de l'architecture 3-tiers 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) 2007, Occello Audrey, SAR O2/SAR O3 SOA - 8 - Problématique de l’intégration en entreprise • Entreprises découpées en départements fonctionnels y compris le SI • Processus métiers de + en + inter-départementaux • Les processus franchissent les fontières de l'entreprise qui doit pouvoir prendre en compte les activités et processus des partenaires pour être reactive Coûts considérables dans la gestion des flux entre départements et dans l’intégration de leurs SI (c) 2007, Occello Audrey, SAR O2/SAR O3 SOA - 9 - Hier : plat de spaghettis • Développements coûteux • Interconnexions redondantes (point à point) • Grande complexité • Maintenance difficile (c) 2007, Occello Audrey, SAR O2/SAR O3 SOA - 10 - • Procédures • Modules • Modèles orientés objets – Packages – Encapsulation • Design pattern • ... Vers toujours plus d'abstraction (c) 2007, Occello Audrey, SAR O2/SAR O3 SOA - 11 - Limites de la programmation orientée Objet • Structure et architecture de l’application peu visibles • Interactions entre objets enfouies dans le code • Évolution / modification difficile • Recherche des bouts de code impliqués source d’erreur • Gestion de la consistance d’un changement délicate (c) 2007, Occello Audrey, SAR O2/SAR O3 SOA - 12 -  Granularité encore trop fine  Mal adaptée à la programmation à grande échelle Couplage fort  Rend difficile la réutilisation  Accroît la complexité des Systèmes OO Objets et encapsulation (c) 2007, Occello Audrey, SAR O2/SAR O3 SOA - 13 - Encore plus de structuration avec les composants logiciels Analogie avec les composants électroniques, legos, puzzles (c) 2007, Occello Audrey, SAR O2/SAR O3 SOA - 14 - Définition usuelle  Une unité regroupant les fonctionnalités concernant une même idée  Un module logiciel autonome pouvant être installé sur différentes plates-formes  qui exporte des attributs et des méthodes  qui peut être configuré (déploiement semi automatique)  capable de s’auto-décrire Intérêt Être des briques de base configurables pour permettre la construction d’une application par composition Un Composant : Qu’est-ce que c’est ? (c) 2007, Occello Audrey, SAR O2/SAR O3 SOA - 15 - Interactions avec un composant  ce qui est fourni par le composant  ce qui est utilisé par le composant  modes de communication Configuration du composant  propriétés (attributs publics)  connexions  cycle de vie (arret, redemarrage, ...)  contraintes techniques (transaction, persistance, sécurité, ...)  … Structure d’un composant Interfaces fournies Interfaces requises Interface de configuration (c) 2007, Occello Audrey, SAR O2/SAR O3 SOA - 16 - Re-configuration dynamique Distributeur de boissons Facturation version 1 Facturation version 2 Facturer: encaisser, rendreMonnaie Facturer: encaisser, rendreMonnaie Facturer: encaisser, rendreMonnaie « Just in time binding » Permet de modifier l'application à chaud sans modification du code en manipulant les assemblages Consommer: payer, selectionner, prendre Gerer: ouvrir, remplir, mettreMonnaie Réparer: ouvrirCapot, fermerCapot (c) 2007, Occello Audrey, SAR O2/SAR O3 SOA - 17 - Les composants dans la nature La modélisation des composants logiciels est intégrée à UML 2.0 Spécification : Composants CORBA (CCM) Spring (JEE beans for Web apps) Fractal (Etendu pour le réparti, voir GridComponentModel – Equipe I3S/INRIA OASIS) SCA (Service component Architecture) => utilisé pour SOA (voir OSOA Tuscany, HydraSCA, IBMWebSphere pack for SOA, etc) Plates-formes d'éxecution OpenCCM (GridCCM, Equipe PARIS IRISA Rennes) Julia (Fractal), ProActive (GCM) Sofa (Fractal) ... (c) 2007, Occello Audrey, SAR O2/SAR O3 SOA Convergence Composants / Services • Exposer les interfaces offertes par les composants selon une technologie au choix; Par exemple – Services web, avec binding SOAP – Interface Java avec binding RMI ou JMS • Principe suivi par la norme SCA : Service Component Architecture – Notion de Composite Service (c) 2007, Occello Audrey, SAR O2/SAR O3 SOA Convergence Composants / Services : Exemple From : (c) 2007, Occello Audrey, SAR O2/SAR O3 SOA - 20 - Demain : Architecture urbanisée • L’urbanisation informatique définit l'organisation d’un SI à l’image d’une ville −découper le SI en modules autonomes (zone, quartier, îlot, bloc) −localiser les zones d’échange d’informations (routes, ponts, tunels) qui permettent de découpler les différents modules • Objectif : faire évoluer le SI au même rythme que la stratégie et l'organisation des métiers de l'entreprise Receive Invoke Invoke Invoke Reply Reply Fault Non- Interruptible Receive Invoke Invoke Invoke Reply Reply Fault Non- Interruptible Canal d'échange données processus partenaires portail services legacy ... ... (c) 2007, Occello Audrey, SAR O2/SAR O3 SOA - 21 - Quels sont les principes de base du SOA ? (c) 2007, Occello Audrey, SAR O2/SAR O3 SOA - 22 - Principes fondamentaux de l’architecture SOA Il n’existe pas une recette pour garantir le succès de la mise en place d’une SOA mais des principes à respecter : – Discussion entre métier et IT – Utilisation des use case métier – Utilisation de standards – Pas de remise en cause de l’existant lors d’évolutions technologiques – Découplage entre fournisseur et consommateur de services – Indépendance des ressources vis à vis de ceux qui les utilisent (c) 2007, Occello Audrey, SAR O2/SAR O3 SOA - 23 - Qu’est ce qu’un Service (au sens SOA) ? • Partage les caractéristiques suivantes d’un objet – Modulaire (ensemble de fonctionnalités qui font sens) • Partage les caractéristiques suivantes d’un composant – Boite noire (séparation interface/implémentation) – Indépendant de la localisation – Neutralité vis-à-vis des protocoles de transport • Correspond à un périmètre fonctionnel que l’on souhaite exposer à des consommateurs • Est faiblement couplé (indépendant des autres services) • Expose un petit nombre d’opérations offrant un traitement de bout en bout • Sans état (c) 2007, Occello Audrey, SAR O2/SAR O3 SOA - 24 - • Un Service expose un Contrat • Les services communiquent par messages Conditions Générales de Vente Règlement Intérieur Vos droits/Vos devoirs in out • Un Service est Autonome et sans état (en général, c.ex WSRF) • Les Frontières entre services sont Explicites 4 propriétés du service à retenir (c) 2007, Occello Audrey, SAR O2/SAR O3 SOA - 25 - Exemple de couplage fort : Gestion de prêts LoanAgent calculateRisk Loan Account createLoan checkCredit LoanApproval SMSGateway sendConfirmation Entités LoanAgent est lié à LoanApproval et Loan LoanApproval est lié à Account Loan est lié à SMSGateway (c) 2007, Occello Audrey, uploads/s1/cours-soa-ao-fb 1 .pdf