LOG4430 : Architecture logicielle et conception avancée Introduction à l’Architecture Orientée Service (SOA)

Introduction à l’Architecture Orientée Service (SOA) Contexte: Intégration en entreprise. Principes de base du SOA. Points clés de l’architecture SOA. Cycle de vie d’un service. Avantages et inconvénients. Méthodes et outils permettent la mise en œuvre d’une architecture orientée services. Références.

1. Contexte: Intégration en entreprise Les systèmes logiciels reflètent très souvent l’organisation de l’entreprise. Processus métiers des entreprises sont de plus en plus multi-départementaux Quels problèmes potentiels? Redondance dans les systèmes logiciels Coûts considérables dans la gestion des flux entre départements et dans l’intégration de leurs systèmes logiciels.

1. Contexte: Intégration en entreprise Développements coûteux Interconnexions redondantes (point à point)‏ Grande complexité Maintenance difficile Réutilisation difficile (couplage fort)

1. Contexte: Intégration en entreprise Développements coûteux Interconnexions redondantes (point à point)‏ Grande complexité Maintenance difficile Réutilisation difficile (couplage fort)

1. Contexte: Intégration en entreprise Les entreprises doivent s’adapter en permanence aux variations des marchés… Leurs systèmes logiciels ne doivent pas être un frein à ces changements l’activité qui pilote la technologie et non l’inverse

1. Contexte: Intégration en entreprise

1. Contexte: qu’est ce qu’une SOA? Un ensemble de services que l'entreprise souhaite exposer à leurs clients et partenaires, ou d'autres parties de l'organisation Dirigeants Analystes métier 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é Architectes Un modèle de programmation avec ses standards, paradigmes, outils et technologies associées Développeurs Un intergiciel offrant des fonctionnalités en terme d'assemblage, d'orchestration, de surveillance et de gestion des services Intégrateurs Chaque rôle s'approprie les SOA différemment…

1. Contexte: qu’est ce qu’une SOA? services * objets * Langages procéduraux Assembleur Langages machine composants services 01011 10100 11000 La SOA est une évolution des paradigmes précédents…

2. Principes de base du SOA SOA est une évolution des plates-formes passées, Elle préserve les caractéristiques réussies des architectures traditionnelles. Tout en y ajoutant quelques principes nouveaux. SOA est un paradigme abstrait, base de l’architecture distribuée sans aucune référence à une implémentation technique Elle est souvent implémentée sous forme de Web Services, mais pas obligatoirement.

2. Principes de base du SOA La SOA représente une architecture ouverte, extensible, fédérée et composable qui promeut une orientation service et qui est composée de services Autonomes Capables de QOS Non liés à des vendeurs Interopérables Potentiellement réutilisables

2. Principes de base du SOA Dans SOA il y a Service => Qu’est ce qu’un service? Un service doit être "abstrait" : il n’est pas lié à une implémentation Exemples de services: − Service d'enregistrement d'un abonné Vidéotron. − Service de réservation d'un billet d’avion. − Service de diffusion d'information.

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

Conditions Générales de Vente Vos droits/Vos devoirs Quatre propriétés du service à retenir… Un Service est autonome et sans état Un Service expose un contrat Conditions Générales de Vente Règlement Intérieur Vos droits/Vos devoirs in out Les frontières entre services sont explicites Les services communiquent par messages

Conséquences de ces propriétés Une SOA véhicule des messages et non des objets Le consommateur (client) est découplé de l’architecture technique du service qu’il invoque Le consommateur et le fournisseur n'ont pas forcément les mêmes technologies

Exemple de couplage fort : Gestion de prêts Entités LoanAgent LoanApproval Account Loan SMSGateway calculateRisk checkCredit createLoan sendConfirmation LoanAgent est lié à LoanApproval et Loan LoanApproval est lié à Account Loan est lié à SMSGateway

Gestion de prêts en couplage faible Services LoanProcess CheckAccount Balance Calculate LoanRisk CreateLoan Notify ViaSMS Qu’est ce que LoanProcess ? Un processus métier ! Il permet d’orchestrer les services => couplage faible

2. Principes de base du SOA Au cœur des SOA on a donc: des Services et des processus =>Comment gérer les processus?

Business Process Management (BPM)‏ But : Donner à l'Entreprise les moyens de gérer ses processus métiers de manière informatisée (modélisation, simulation, exécution et audit)‏ Optimisation, adaptation aux besoins en temps réel Un processus est composé de sous processus, de décisions (Business rules) et d’activités Un sous processus a son propre but, entrées et sorties Les activités correspondent aux parties du processus métier qui n’incluent pas de décision et sont associées à des rôles Sont réalisées par des systèmes ou des humains Des mesures (KPI pour Key Performance Indicators) permettent de capturer les performances du processus Un processus est le résultat d’une orchestration de service Le processus est lui-même accessible en tant que service

BPM par l’exemple

Les couches SOA Couplage fort Couplage faible au niveau logique Ces différents modes de couplage sont nécessaires et dépendent du niveau dans l’architecture * Couplage fort Couplage faible au niveau logique Couplage faible au niveau technique ou au niveau logique : vision composants PERIMETRE STABLE ISOLATION DE CHAQUE IMPLEMENTATION DE SERVICE Layer 1: Operational Systems Layer. This layer contains existing systems or applications including existing CRM and ERP packaged applications, legacy applications and “older” object-oriented system implementations as well as business intelligence applications. Layer 2: Components Layer. This is the layer of Service Components that are responsible for realizing the functionality and maintaining the quality of service of the exposed services. They are responsible for ensuring conformance to service level agreements through architectural best practices. high-availability, load-balancing, etc. Layer 3: Services Layer. Exposed services reside in this layer; they can be “discovered” and invoked, or possibly choreographed into a composition. Thus the components provide services through their interfaces. Layer 4: Business Process Composition Layer. Compositions and choreographies of services exposed in layer 3 are defined in this layer. This evolution of service composition into flows, or choreographies of services bundled into a flow, act together as an application. These applications support specific use cases and business processes. Ex:

Exemple d’un e-store : Couches AccountController CartController Presentation Layer Category Check out Create Account Default Error Help Item Details Items My Account Edit Account Order Billing Order Process Order Shipping SignOut Shopping Cart Search SignIn Business Logic Layer Account Cart Inventory Item OrderInsert OrderRead Product Profile Data Access Layer IAccount IInventory IItem IOrder IProduct IProfile

Exemple d’un e-store : Domaines Customer Catalog Shopping Presentation Layer Category Check out Create Account Default Error Help Item Details Items My Account Edit Account Order Billing Order Process Order Shipping SignOut Shopping Cart Search SignIn Billing Inventory Business Logic Layer Account Cart Inventory Item OrderInsert OrderRead Product Profile 1.0 1.1 1.2 1.0 2.0 3.5 10.0 11.2 11.5 5.1 5.2 5.3 1.0 6.0 7.0 Data Access Layer IAccount IInventory IItem IOrder IProduct IProfile

Exemple d’un e-store : Domaines Presentation Layer Business Logic Layer Data Access Layer Customer Catalog Inventory Shopping Billing

Exemple d’un e-store : Services Presentation Layer Business Logic Layer Service Layer Manage Customer Show Catalog Make Inventory Shop Bill Data Access Layer

SOA :des applications, Vue comme des clients d'autres applications

3.Points clés de l’architecture SOA 1.a Search for service 1.b Return contract Repository Service consumer Contract 2.a Create a process instance Mediation layer/Service bus 2.d Send request 2.b Execute process 2.c Retrieve service end-point Service provider Business service orchestrator Registry Business process description

3. Standards de l’architecture Les standards sont un élément clé d’une SOA, ils assurent l’interopérabilité SOAP W3C Simple Object Access Protocol WSDL W3C Web Services Description Language UDDI Microsoft, IBM, HP Universal Description Discovery and Integration BPEL Oasis Business Process Execution Language Transporte Décrit le contrat Spec pour Repository/Registry Décrit les processus métier Les trois piliers des Services Web

SOA et web services Attention à ne pas confondre les deux ! SOA est un ensemble de concepts : Une SOA peut se mettre en œuvre sans Web Services Les WS sont de l’ordre de la technologie : On peut utiliser les Web Services sans faire de SOA Les WS constituent la meilleure solution standardisée disponible Un service métier = un webservice

Le langage BPEL Standard de l’OASIS Norme permettant de décrire des processus en XML Propose les fonctions basiques d’un langage de programmation: sequence, flow, loop, switch… Identification des Instances de Process Gestion des transactions longue durée (scope, compensation)‏ Gestion des fautes

BPEL le chef d’orchestre

BPEL par l’exemple loan.bpel flow PartnerLink <PartnerLink> references to the services participating in the process flow <invoke> a credit rating service synchronously <faultHandlers> catch and manage exceptions when customer has a bad credit history <flow> initiates asynchronous loan processors in parallel of execution <receive> asynchronous callbacks from longrunning loan processors <switch> to the lowest loan offer loan.bpel

4. Cycle de vie d’un service 4 grandes phases : Identification Spécification Développement Gestion 1 aspect tranversal : la gouvernance Les architectures orientées service impliquent une vision globale La gouvernance permet de casser les silos de l’entreprise

4. Cycle de vie des services (activités de gouvernance)‏ Candidate Consumers Identified Search for Existing Implementation Service Identification Service Owner Approval Service Identified Service reusability Commission yes no exists? Provider Interfaces Documented Service/Process Workflow Created Service Specification Created Service Specification Review Service Specification Develop Components Integrate & Test Create Deployment Unit Code in repository Acceptance Test Service Development Monitor service Certify Service Plan New Version Deprecate Service Decommission Service Service Management Service in use Service in registry

Rôles associés au cycle de vie des services Identification Analyste métier Spécification Architecte Définit les processus métiers et les KPI associées Identification des services métier Optimise les processus via la simulation Définit les services pour les use cases Modélise les services Développement Intégrateur Développement Développeur Assemble les services Implémente les services Gestion Gestionnaire Publie les services Gère le cycle de vie des services Contrôle la qualité de service

Zoom sur la phase d’identification Un des problèmes centraux pour mettre en œuvre une SOA La granularité des services est fondamentale détermine en grande partie la réutilisabilité des services Or succès SOA = % de réutilisation des services Éviter une granularité trop fine qui entraîne : beaucoup d’interactions des problèmes de performance On recommande des services à “gros grain” attention à une granularité trop “épaisse” un service qui fait trop de chose, risque de ne pas être réutilisable Trouver le juste milieu…

2 méthodes d’identification des services Une première phase d'indentification doit être effectuée sur l'ensemble du Système en s'appuyant sur la cartographie des domaines métiers de l'entreprise et sur le code existant. Approche incrémentale : une phase d'identification est nécessaire au démarrage de chaque nouveau projet SOA en s'appuyant sur les processus et services répertoriés précédemment. Approche Bottom-up : On part des briques informatiques, on rassemble les bouts (abstraction)‏ Plus adéquat pour réutiliser l’existant non “SOA-isé”‏ Approche Top-down : On part des interactions métier pour aboutir aux interactions techniques Plus adéquat pour démarrer un nouveau projet

Approche “Bottom Up” Besoins Legacy applications Diagrammes d'activités Décomposition du diagramme de classes Orchestration Specification des services Nouveaux Services + services réutilisables (l'existant)‏ Nouvelle application

Approche “Top Down” Besoins Analyse des domaines métiers Décomposition du processus métier Orchestration Specification des services Nouveaux Services + services réutilisables (l'existant)‏ Nouvelle application

Approche “Outside in” Dans la pratique on utilise rarement une seule approche Pour obtenir une granularité pertinente des services, il est nécessaire de concilier les 2 Faire l’analyse Top-down sans se préoccuper de l’existant Faire l’analyse Buttom-up en ne considérant que l’existant Comparer les services “remontés” avec ceux déduits des processus Faire les compromis nécessaires pour réutiliser le maximum de code

Zoom sur la phase de spécification Les services identifiés ne doivent pas être tous publiés: Chaque service a un coût et un risque Il faut éviter la prolifération des services Le “Service Litmus Test” d'IBM aide à trouver les “bons” services à exposer

Quelques critères d' “exposabilité” Le potentiel d'un service est d'autant plus important qu'il : permet d'automatiser un processus métier critique est réutilisable par plusieurs domaines métiers remplace une application désuette supporte des besoins non fonctionnels (sécurité, logging, monitoring, ...)‏

Location de véhicules : services exposés

Exemple : quels sont les services exposables ? A basic calculator for performing simple arithmetic operations (+, -, *, /) A printing application, shared by multiple applications, running in multiple environments A credit card authorization application A Database lookup that returns application-specific data A composite database lookup for customer information, searching across multiple databases

8 principes de bases d’une SOA Standardized service contract: le contrat de service adhérent à un accord de communication, collectivement défini avec un ou plusieurs documents de description. Service loose coupling: faible couplage des services avec la maintenance d’une relation réduisant les dépendances. Service abstraction: l’abstraction des services dois dissimuler la logique du service à l’extérieur. Service reusability: réutilisation des services partageant la logique entre plusieurs services avec l’intention de promouvoir la réutilisation.

8 principes de bases d’une SOA Service autonomy: Services have control over the logic they encapsulate. Service statelessness: Services minimize resource consumption by deferring the management of state information when necessary. Service discoverability: Services are supplemented with communicative meta data by which they can be effectively discovered and interpreted. Service composability: Services are effective composition participants, regardless of the size and complexity of the composition.

5. Avantages des SOA: Bénéfices métier Améliorer l’agilité et la flexibilité du métier. Faciliter la gestion des processus métier. Offrir la capacité à casser les barrières organisationnelles (silos). Réduire en temps le cycle de développement des produits. Améliorer le retour sur investissement. Accroître les opportunités de revenu.

5. Avantages des SOA: Bénéfices techniques Réduire la complexité de la solution. Construire les services une seule fois et les utiliser fréquemment. Garantir une intégration standardisée et le support de clients hétérogènes. Faciliter la maintenabilité.

5. Inconvénients des SOA Difficile à tester. Risque de prolifération des messages (entre services). Risque liés à la sécurité des messages provenant de sources diverses.

6. Méthodes de conception des services SOMA (IBM)‏ SODA (De Gamma)‏ Praxeme (Unilog Management et Orchestra Networks)‏ + toutes les formations proposées par les éditeurs tels que Softeam (SEA), DreamSoft, etc sur leur “savoir-faire” Autant d’offres que de méthodes différentes : de quoi s’y perdre !

Modeleurs de processus Outils de modélisation des processus métier IBM WebSphere Business Modeler Bull Bonita De Gamma BPM MEGA Aris Corporate Modeler WinDesign Power AMC Popkin System Architecture 51

Moteurs d’exécution de processus Plate-forme d’intégration IBM Websphere Process Server BEA Weblogic Integrator/Acqualogic Microsoft Biztalk De Gamma Workflow Oracle BPEL PM Bull Orchestra SAP “Netweaver” Apache ODE ESB IBM Websphere ESB Celtix hosted on ObjectWeb/IONA Technologies OpenESB (java.net)‏ Mule (codehaus.org)‏ Sonic ESB EBM Web Sourcing Distributed Petals Bus (on OW2)

Contrôleurs/moniteurs BAM (Business Activity Monitoring)‏ IBM WebSphere Business Monitor Oracle BAM Systar Business Bridge BMC Service Impact Manager Composants de sécurité Oracle Web Service Manager Oblix 53

Exemple: Gamme d'outils IBM couvrant le cycle de vie complet Business Analyst Service Architect WebSphere Business Modeler Rational Software Architect Service Specification Developer BPEL WSDL Integration Developer WebSphere Integration Developer Rational Application Developer KPIs Service Development WebSphere Service Repository & Registry Service Registrar Governance Manager Performance Manager Business Analyst Server Administrator WebSphere Business Monitor WebSphere Process Server WebSphere ESB WebSphere Business Services Fabric Service execution & Management

7. Références Robert Daigneau, Service Design Patterns: Fundamental Design Solutions for SOAP/WSDL and RESTful Web Services Occello Audrey, Introduction à l’Architecture Orientée Service, SAR O2/SAR O3 SOA, 2007. Gilbert Raymond, SOA : Architecture Logique :Principes, structures et bonnes pratiques SOA à la sauce IBM http://www-306.ibm.com/software/fr/soa/