La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

(c) 2006, Occello Audrey, SAR O3 SOA - 1 - Introduction à lArchitecture Orientée Service Module SAR O3 – SI3.

Présentations similaires


Présentation au sujet: "(c) 2006, Occello Audrey, SAR O3 SOA - 1 - Introduction à lArchitecture Orientée Service Module SAR O3 – SI3."— Transcription de la présentation:

1 (c) 2006, Occello Audrey, SAR O3 SOA Introduction à lArchitecture Orientée Service Module SAR O3 – SI3

2 (c) 2006, Occello Audrey, SAR O3 SOA § SOA is different things to different people : –A set of services that a business wants to expose to their customers and partners, or other portions of the organization –An architectural style which requires a service provider, requestor and a service description and which address characteristics such as modularity, encapsulation, loose coupling, reuse, composability –A programming model with standards, tools and technologies such as Web Services –A middleware solution optimized for service assembly, orchestration, monitoring and management Business Executive, Analyst Architect Integrator Developer Developer What is Service-Oriented Architecture?

3 (c) 2006, Occello Audrey, SAR O3 SOA Plan du cours A quels besoins répond le SOA ? Quels sont les principes de base du SOA ? Quels sont les éléments clé dune architecture orientée services ? Quel est le cycle de vie dun service ? Quelles méthodologies et outils permettent de mettre en oeuvre une architecture orientée services ? Loffre IBM

4 (c) 2006, Occello Audrey, SAR O3 SOA A quels besoins répond le SOA ?

5 (c) 2006, Occello Audrey, SAR O3 SOA Problématique de lintégration en entreprise Entreprises découpées en départements fonctionnels y compris le système d'information (SI) Processus métiers des entreprises de + en + multi- départementaux Coûts considérables dans la gestion des flux entre départements et dans lintégration de leurs SI

6 (c) 2006, Occello Audrey, SAR O3 SOA Problématique de lintégration en entreprise Les entreprises doivent sadapter en permanence et être de + en + réactives aux variations des marchés (fusions, acquisitions, scissions, diversification des offres commerciales, changement technologiques, …) Leurs SI ne doivent pas être un frein à ces changements Cest lactivité qui pilote la technologie et non linverse

7 (c) 2006, Occello Audrey, SAR O3 SOA Hier : plat de spaghettis Développements coûteux Interconnexions redondantes (point à point) Grande complexité Maintenance difficile

8 (c) 2006, Occello Audrey, SAR O3 SOA Demain : Architecture urbanisée Lurbanisation informatique définit l'organisation dun SI à limage dune ville découper le SI en modules autonomes (zone, quartier, îlot, bloc) localiser les zones déchange dinformations (routes, ponts, tunels) qui permettent de découpler les différents modules Lurbanisation a pour objectif de faire évoluer le SI et sa composante informatique au même rythme que la stratégie et l'organisation des métiers de l'entreprise

9 (c) 2006, Occello Audrey, SAR O3 SOA Presentation Layer CartControllerAccountController Business Logic Layer AccountCartInventoryItemOrderInsertOrderReadProductProfile Category Check out Create Account Default ErrorHelp Item Details Items My Account Edit Account Order Billing Order Process Order Shipping SignOutShopping Cart SearchSignIn e-store : Couches Data Access Layer IAccountIInventoryIItemIOrderIProductIProfile

10 (c) 2006, Occello Audrey, SAR O3 SOA Data Access Layer IAccountIInventoryIItemIOrderIProductIProfile e-store : Domaines Presentation Layer Business Logic Layer AccountCartInventoryItemOrderInsertOrderReadProductProfile Category Check out Create Account Default ErrorHelp Item Details Items My Account Edit Account Order Billing Order Process Order Shipping SignOutShopping Cart SearchSignIn Catalog Inventory ShoppingCustomer Billing

11 (c) 2006, Occello Audrey, SAR O3 SOA Data Access Layer Presentation Layer Business Logic Layer e-store : Domaines CatalogInventoryShoppingCustomerBilling

12 (c) 2006, Occello Audrey, SAR O3 SOA e-store : Services Presentation Layer Business Logic Layer Data Access Layer Service Layer Show Catalog Make Inventory Shop Manage Customer Bill

13 (c) 2006, Occello Audrey, SAR O3 SOA Quels sont les principes de base du SOA ?

14 (c) 2006, Occello Audrey, SAR O3 SOA Principes fondamentaux de larchitecture SOA Il nexiste pas une recette pour garantir le succès de la mise en place dune 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 lexistant lors dévolutions technologiques –Découplage entre fournisseur et consommateur de services –Indépendance des ressources vis à vis de ceux qui les utilisent

15 (c) 2006, Occello Audrey, SAR O3 SOA Quest ce quun Service (au sens SOA) ? Partage les caractéristiques suivantes dun objet –Modulaire (ensemble de fonctionnalités qui font sens) Partage les caractéristiques suivantes dun 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 lon souhaite exposer à des consommateurs (il a une granularité plus forte quun composant) Est faiblement couplé (indépendant des autres services) Expose un petit nombre dopérations offrant un traitement de bout en bout Sans état

16 (c) 2006, Occello Audrey, SAR O3 SOA 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 Les Frontières entre services sont Explicites 4 propriétés du service à retenir

17 (c) 2006, Occello Audrey, SAR O3 SOA Exemple de couplage fort : Gestion de prêts LoanAgent calculateRisk LoanAccount createLoan checkCredit LoanApprovalSMSGateway sendConfirmation Entités LoanAgent est lié à LoanApproval et Loan LoanApproval est lié à Account Loan est lié à SMSGateway

18 (c) 2006, Occello Audrey, SAR O3 SOA Gestion de prêts en couplage faible LoanProcess CreateLoan CheckAccount Balance Calculate LoanRisk Notify ViaSMS Services Quest ce que LoanProcess ? Un processus métier ! Il permet dorchestrer les services => couplage lâche

19 (c) 2006, Occello Audrey, SAR O3 SOA 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 dactivités Un sous processus a son propre but, entrées et sorties Les activités –correspondent aux parties du processus métier qui nincluent 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 dune orchestration de service Le processus est lui-même accessible en tant que service

20 (c) 2006, Occello Audrey, SAR O3 SOA BPM par lexemple

21 (c) 2006, Occello Audrey, SAR O3 SOA Les couches SOA

22 (c) 2006, Occello Audrey, SAR O3 SOA Bénéfices métier Améliorer lagilité 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

23 (c) 2006, Occello Audrey, SAR O3 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é

24 (c) 2006, Occello Audrey, SAR O3 SOA Quels sont les éléments clé dune architecture orientée services ?

25 (c) 2006, Occello Audrey, SAR O3 SOA Points clés de larchitecture Service consumer Service provider Registry Mediation layer/Service bus Repository 2.c Retrieve service end-point Contract Business service orchestrator 1.a Search for service 1.b Return contract 2.a Create a process instance 2.b Execute process 2.d Send request Business process description

26 (c) 2006, Occello Audrey, SAR O3 SOA Standards de larchitecture Les standards sont un élément clé dune SOA, ils assurent linteropérabilité Transporte SOAP W3C Simple Object Access Protocol Spec pour Repository/Registry UDDI Microsoft, IBM, HP Universal Description Discovery and Integration WSDL W3C Web Services Description Language Décrit le contrat BPEL Oasis Business Process Execution Language Les trois piliers des Services Web Décrit les processus métier

27 (c) 2006, Occello Audrey, SAR O3 SOA SOA et web services Attention à ne pas confondre les 2 ! –SOA est un ensemble de concepts : Une SOA peut se mettre en œuvre sans Web Services –Les WS sont de lordre de la technologie : On peut utiliser les Web Services sans faire de SOA (architecture point à point sans réutilisation) Les WS constituent la meilleure solution standardisée disponible –Un service métier = un webservice

28 (c) 2006, Occello Audrey, SAR O3 SOA Le langage BPEL Standard de lOASIS Norme permettant de décrire des processus en XML Propose les fonctions basiques dun langage de programmation: –sequence, flow, loop, switch… Identification des Instances de Process Gestion des transactions longue durée (scope, compensation) Gestion des fautes

29 (c) 2006, Occello Audrey, SAR O3 SOA BPEL le chef dorchestre

30 (c) 2006, Occello Audrey, SAR O3 SOA flow PartnerLink BPEL par lexemple references to the services participating in the process flow a credit rating service synchronously catch and manage exceptions when customer has a bad credit history initiates asynchronous loan processors in parallel of execution asynchronous callbacks from longrunning loan processors to the lowest loan offer loan.bpel

31 (c) 2006, Occello Audrey, SAR O3 SOA ESB : couche de médiation Cest le point dentrée vers un service Il doit être normalisé mais on ne sait pas qui fourni le service et comment il le fourni (implémentation). Infrastructure qui optimise les échanges entre consommateurs et fournisseurs de services. Il peut prendre en charge : –Routage –transformation des données –transactions, –sécurité, –qualité de service, –… Le but dun ESB est de permettre de communiquer de manière simple et standardisée entre des applications hétérogènes

32 (c) 2006, Occello Audrey, SAR O3 SOA Quelques manières dimplémenter un ESB Intergiciels de type EAI (Message Broker avec connecteurs propriétaires liés au moteur dintégration) Intergiciels de type Bus (CORBA par exemple) Routeurs Web services tel que WebSphere Web Services Gateway Intergiciels de type MOM (Message Oriented Middleware) Selon le type dimplémentation retenu, lESB assurera plus ou moins de services : le choix dépend des besoins LESB nest pas obligatoire : mais il est fortement recommandé pour éviter le couplage entre fournisseur et consommateur

33 (c) 2006, Occello Audrey, SAR O3 SOA Exemples darchitecture avec/sans ESB Avec ESBSans ESB Plusieurs connecteurs Orchestration importante Transactions conséquentes Communications homogènes Pas dorchestration Peu de transactions

34 (c) 2006, Occello Audrey, SAR O3 SOA Quel est le cycle de vie dun service ?

35 (c) 2006, Occello Audrey, SAR O3 SOA Découpage du cycle de vie dun service 4 grandes phases : –Identification –Spécification –Développement –Gestion 1 aspect traversal : la gouvernance –Les architectures orientées service impliquent une vision globale –La gouvernance permet de casser les silos de lentreprise

36 (c) 2006, Occello Audrey, SAR O3 SOA Provider Interfaces Documented Service/Process Workflow Created Service Specification Created Service Specification Review Develop Components Integrate & Test Create Deployment Unit Code in repository Acceptance Test Monitor SLA Compliance Certify & Publish Service Plan New Service Version Deprecate Service Decommission Service Reusable Service Specification Reusable Service Development Reusable Service Management Legacy Systems Candidate Consumers Identified Search for Existing Implementation Solution requirements Process Models Service Identification Service Specification Service Owner Approval Operational Service in use Service Identified Service reusability Commission Service outlines Service in registry Code in repository ok ko Cycle de vie des services Process Governance Service Specification

37 (c) 2006, Occello Audrey, SAR O3 SOA La gouvernance en quelques questions –Qui définit et modifie les services ? –Qui peut y accéder ? –Quelle est la qualité que les services doivent offrir ? –Qui paie pour ces services ? –Qui est responsable de linfrastructure ? –Qui gère les interdépendances entre les services ? –Comment exposer les services aux entreprises partenaires ?

38 (c) 2006, Occello Audrey, SAR O3 SOA Defines services for use cases Models service implementation Solution Architect Defines and models processes and concepts Optimizes processes through simulations Business Analyst Implements processes and composite apps Defines services Integration Developer Implements services Constructs other service artifacts Developer Business Requirements Business Design Model Business Goals and Objectives Service Design Model Software Architecture Enterprise Architecture Service Flow Model Service Assembly Model Implementation Model Deployment Model Shared Assets Management Rôles associés au cycle de vie des services Publish/retrieve services to/from registry Manage Business Service Lifecycle approval/rejections Control quality of service execution Service Registrar, Governance & Performance Managers Identification Spécification Développement Gestion

39 (c) 2006, Occello Audrey, SAR O3 SOA Zoom sur la phase didentification 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 dinteractions –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

40 (c) 2006, Occello Audrey, SAR O3 SOA méthodologies didentification des services Approche Top-down : –Pour démarrer un nouveau projet –Dans le cadre dun SI urbanisé Approche Bottom-up : –Pour réutiliser lexistant (non SOA) –On part des morceaux, on rassemble les bouts

41 (c) 2006, Occello Audrey, SAR O3 SOA Approche Top Down Use Cases Orchestration (business rules and processes) Requirements Story Board WSDL Service Specification New Application or process model New & reusable Services

42 (c) 2006, Occello Audrey, SAR O3 SOA Approche Bottom Up reusable code Orchestration (business rules and processes) WSDL Service Specification Change Cases Interface Specification New Requirements Legacy application New Application Story Board or process model

43 (c) 2006, Occello Audrey, SAR O3 SOA Approche Meet in the Middle On utilise rarement une unique approche Dans la pratique : –Faire lanalyse Top-down sans se préoccupper de lexistant –Faire lanalyse Buttom-up en ne considérant que lexistant –Comparer les services remontés avec ceux déduits des Uses case –Faire les compromis necessaires pour réutiliser le maximum de code

44 (c) 2006, Occello Audrey, SAR O3 SOA Meet in the Middle: exemple du prêt business processes process choreography services service components operational systems Lending Loan Origination Loan Closure Loan Servicing IMS DB LOS (Loan Origination System) Modify Application Receive Application Check Credit Negotiate Loan Receive Application Adjudicate Loan Close the Loan Application Processing Customer Accounting Credit Administration Permissions Component Loan Product Consolidated Book/Position Correspondence Doc Mgmt & Archive Book the Loan Collateral Handling Fair Issac Blaze Calculate Risk Score Enterprise Content Mgmt Image Documents Decline Reasons Notify Customer of Decision Domain Analysis & Decomposition Process Decomposition Top Down Analysis Bottom up Analysis Service Identification Interview Documentation Code Analysis Services Identified From Top Down and Bottom up Analysis

45 (c) 2006, Occello Audrey, SAR O3 SOA 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 aide à trouver les bons services à exposer Zoom sur la phase de spécification

46 (c) 2006, Occello Audrey, SAR O3 SOA Exemple : quels sont les services exposables ? A basic calculator for performing simple arithmetic operations (+, -, *, /) –Not a good candidate because the operations performed ate too trivial to justify the overhead of services invocation. A batch printing application, shared by multiple applications, running in multiple environments –An excellent candidate because it supplies useful function that is needed by applications running in different environments, operating systems etc A credit card authorization application –An excellent candidate because of the value of authentication, authorization and non-repudiation (very useful for financial Business to Business transactions) A Database lookup that returns application-specific data –A poor candidate because it introduces unnecessary latency. However if OTHER remote applications or business need to access the data too, then it might make sense for them to use a service call to do so A composite database lookup for customer information, searching across multiple databases –If multiple applications need to access the same lookup, this is an excellent candidate since it abstracts function from an application into a common resource

47 (c) 2006, Occello Audrey, SAR O3 SOA Quelles méthodologies et outils permettent de mettre en oeuvre une architecture orientée services ?

48 (c) 2006, Occello Audrey, SAR O3 SOA Méthodes de conception des services SOMA (IBM) SODA (De Gamma) Praxeme (Unilog Management et Orchestra Networks) … Autant doffres que de méthodologies différentes : de quoi sy perdre !

49 (c) 2006, Occello Audrey, SAR O3 SOA Modeleurs de processus Outils de cartographie, modélisation des processus métier IBM WebSphere Business Modeler/Monitor –Bull Bonita –MEGA –Aris –Corporate Modeler –WinDesign –Power AMC –Popkin System Architecture

50 (c) 2006, Occello Audrey, SAR O3 SOA Moteurs dexécution de processus Plate-forme dintégration –IBM Websphere Process Server –BEA Weblogic Integrator/Acqualogic –Microsoft Biztalk –Oracle BPEL PM –Bull Orchestra –SAP Netweaver ESB –IBM Websphere ESB –Celtix hosted on ObjectWeb/IONA Technologies –OpenESB (java.net) –Mule (codehaus.org) –Sonic ESB

51 (c) 2006, Occello Audrey, SAR O3 SOA Contrôleurs 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

52 (c) 2006, Occello Audrey, SAR O3 SOA Loffre IBM

53 (c) 2006, Occello Audrey, SAR O3 SOA Defines services for use cases Models service implementation Solution Architect Defines and models processes and concepts Optimizes processes through simulations Business Analyst Implements processes and composite apps Defines services Integration Developer Implements services Constructs other service artifacts Developer Business Requirements Business Design Model Business Goals and Objectives Service Design Model Software Architecture Enterprise Architecture Service Flow Model Service Assembly Model Implementation Model Deployment Model Shared Assets Management Rôles associés au cycle de vie des services Publish/retrieve services to/from registry Manage Business Service Lifecycle approval/rejections Control quality of service execution Service Registrar, Governance & Performance Managers WebSphere Business Modeler/Monitor Rational Software Architect WebSphere Integration Developer Rational Application Developer WebSphere Service Repository & Registry WebSphere Business Services Fabric

54 (c) 2006, Occello Audrey, SAR O3 SOA Comment les outils IBM couvrent le cycle de vie WebSphere Process Server WebSphere ESB WebSphere Business Modeler WebSphere Integration Developer Rational Software Architect WebSphere Business Monitor WSDLBPEL KPIs UML Use cases WebSphere Service Repository & Registry WebSphere Business Services Fabric Service Specification Service Development Service Management Business Analyst Integration Developer Rational Application Developer DeveloperService Architect Service RegistrarGovernance Manager Performance Manager Server Administrator

55 (c) 2006, Occello Audrey, SAR O3 SOA Déroulement dun exemple DEMO

56 (c) 2006, Occello Audrey, SAR O3 SOA Temps estimé pour ce processus simple Installation de la plate-forme: 2 semaines Modélisation (flow+KPI), simulation dans le Modeler: 1 semaine Développement in WID: 3 semaines –Spécification dans WID de business rules, Human Tasks, code java, web services, … Configuration du Monitor server pour ce processus : ½ jour Configuration des portlets dans le Monitor client: 2 jours –simple web interface –simple human task interface

57 (c) 2006, Occello Audrey, SAR O3 SOA Conclusions

58 (c) 2006, Occello Audrey, SAR O3 SOA Du déjà vu ? SOA est une évolution des plate-forme passées, tout en préservant les caractéristiques réussies des architectures traditionnelles –Contractualisation des services Design by Contract (Meyer) –Découplage Interface/Implémentation, interopérabilité, transparence des communications, … Middlewares à la CORBA –Couplage faible Message Oriented Middleware (MOM) –Orchestration des services Travaux autour des workflows, langages de coordination SOA est une évolution plutôt quune révolution

59 (c) 2006, Occello Audrey, SAR O3 SOA Chronique dune évolution * * objets * services composants Niveaux dabstraction grandissant Assembleur Langages machine Langages procéduraux

60 (c) 2006, Occello Audrey, SAR O3 SOA Synthèse Orienté fonctionnalités Conçu pour durer Cycle de développement long Depuis……Vers… Orienté processus Conçu pour changer Développement et déploiement interactif Silos applicatifs Couplage fort Orienté Objet Orchestration de Services Couplage faible Orienté message

61 (c) 2006, Occello Audrey, SAR O3 SOA Avantages et inconvénients Qualité de service Architecture adaptative Réutilisation du code Utilisation de standards Productivité accrue Manque de maturité des standards Lenteur dexécution Difficile à effectivement implémenter Encore peu de chose sur la contractualisation

62 (c) 2006, Occello Audrey, SAR O3 SOA Paradoxe des principes fondamentaux Utilisation de standards MAIS un standard reste un standard tant que tout le monde lutilise (cf CORBA) La course à la spécification fait rage le W3C et lOASIS se font la guerre Spec des processus Spec sur la sécurité … Pas de remise en cause de lexistant lors dévolutions technologiques MAIS les vendeurs nous asservissent toujours avec leurs suites doutils

63 (c) 2006, Occello Audrey, SAR O3 SOA Paradoxe des principes fondamentaux Découplage entre fournisseur et consommateur de services MAIS certains composants de services sappellent : Couplage fort réintroduit par la couche IT Indépendance des ressources vis à vis de ceux qui les utilisent MAIS la gestion des données est lenfant pauvre du SOA


Télécharger ppt "(c) 2006, Occello Audrey, SAR O3 SOA - 1 - Introduction à lArchitecture Orientée Service Module SAR O3 – SI3."

Présentations similaires


Annonces Google