Introduction à l’Architecture Orientée Service Module SAR O3 – SI3 (c) 2006, Occello Audrey, SAR O3 SOA

What is Service-Oriented Architecture? 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 Developer Integrator Developer (c) 2006, Occello Audrey, SAR O3 SOA

(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é d’une architecture orientée services ? Quel est le cycle de vie d’un service ? Quelles méthodologies et outils permettent de mettre en oeuvre une architecture orientée services ? L’offre IBM (c) 2006, Occello Audrey, SAR O3 SOA

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

Problématique de l’inté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 l’intégration de leurs SI (c) 2006, Occello Audrey, SAR O3 SOA

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, …) Leurs SI ne doivent pas être un frein à ces changements C’est l’activité qui pilote la technologie et non l’inverse (c) 2006, Occello Audrey, SAR O3 SOA

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

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 L‘urbanisation 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 (c) 2006, Occello Audrey, SAR O3 SOA

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

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

(c) 2006, Occello Audrey, SAR O3 SOA e-store : Domaines Presentation Layer Business Logic Layer Data Access Layer Customer Catalog Inventory Shopping Billing (c) 2006, Occello Audrey, SAR O3 SOA

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

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

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) 2006, Occello Audrey, SAR O3 SOA

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 (il a une granularité plus forte qu’un composant) 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) 2006, Occello Audrey, SAR O3 SOA

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

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

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 lâche (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 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 (c) 2006, Occello Audrey, SAR O3 SOA

(c) 2006, Occello Audrey, SAR O3 SOA BPM par l’exemple (c) 2006, Occello Audrey, SAR O3 SOA

(c) 2006, Occello Audrey, SAR O3 SOA Les couches SOA 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. Layer 5: Consumers. The presentation layer is usually out of scope for a SOA. However, it is depicted because some recent standards such as Web Services for Remote Portlets version 2.0 may indeed leverage Web services at the application interface or presentation level. It is also important to note that SOA decouples the user Interface from the components. Examples includes JService, Portlets, WSRP and B2B. Layer 6: Integration (Enterprise Service Bus). This layer enables the integration of services through the introduction of a reliable set of capabilities such as intelligent routing, protocol mediation, and other transformation mechanisms. (c) 2006, Occello Audrey, SAR O3 SOA

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

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

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

Points clés de l’architecture 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 (c) 2006, Occello Audrey, SAR O3 SOA

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

(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 l’ordre 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 (c) 2006, Occello Audrey, SAR O3 SOA

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

BPEL le chef d’orchestre (c) 2006, Occello Audrey, SAR O3 SOA

(c) 2006, Occello Audrey, SAR O3 SOA BPEL par l’exemple 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 (c) 2006, Occello Audrey, SAR O3 SOA

ESB : couche de médiation C’est le point d’entré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 d’un ESB est de permettre de communiquer de manière simple et standardisée entre des applications hétérogènes (c) 2006, Occello Audrey, SAR O3 SOA

Quelques manières d’implémenter un ESB Intergiciels de type EAI (Message Broker avec connecteurs propriétaires liés au moteur d’inté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 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 consommateur (c) 2006, Occello Audrey, SAR O3 SOA

Exemples d’architecture avec/sans ESB Avec ESB Sans ESB Plusieurs connecteurs Orchestration importante Transactions conséquentes Communications homogènes Pas d‘orchestration Peu de transactions (c) 2006, Occello Audrey, SAR O3 SOA

Quel est le cycle de vie d’un service ? (c) 2006, Occello Audrey, SAR O3 SOA

Découpage du cycle de vie d’un 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 l’entreprise (c) 2006, Occello Audrey, SAR O3 SOA

Cycle de vie des services Process Governance Solution requirements ok Service Owner Approval Process Models Service Identified Search for Existing Implementation Candidate Consumers Identified Service outlines ko Service reusability Commission Legacy Systems Service Identification Service Specification Created Service outlines Service Specification Review Service Specification Provider Interfaces Documented Service/Process Workflow Created Reusable Service Specification Code in repository Service Specification Develop Components Integrate & Test Create Deployment Unit Acceptance Test Reusable Service Development Code in repository Service in registry Certify & Publish Service Operational Service in use Monitor SLA Compliance Plan New Service Version Decommission Service Deprecate Service Reusable Service Management (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 l’infrastructure ? Qui gère les interdépendances entre les services ? Comment exposer les services aux entreprises partenaires ? (c) 2006, Occello Audrey, SAR O3 SOA

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

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

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

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

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

Approche “Meet in the Middle” On utilise rarement une unique approche Dans la pratique : Faire l’analyse Top-down sans se préoccupper 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 Uses case Faire les compromis necessaires pour réutiliser le maximum de code (c) 2006, Occello Audrey, SAR O3 SOA

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

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” aide à trouver les “bons” services à exposer (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 (c) 2006, Occello Audrey, SAR O3 SOA

(c) 2006, Occello Audrey, SAR O3 SOA Quelles méthodologies et outils permettent de mettre en oeuvre une architecture orientée services ? (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 d’offres que de méthodologies différentes : de quoi s’y perdre ! (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 (c) 2006, Occello Audrey, SAR O3 SOA

Moteurs d’exécution de processus Plate-forme d’inté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 (c) 2006, Occello Audrey, SAR O3 SOA

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

(c) 2006, Occello Audrey, SAR O3 SOA L’offre IBM (c) 2006, Occello Audrey, SAR O3 SOA

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

Comment les outils IBM couvrent le cycle de vie Business Analyst Service Architect UML Use cases WebSphere Business Modeler Rational Software Architect Service Specification BPEL WSDL Integration Developer WebSphere Integration Developer Rational Application Developer KPIs Service Development Developer 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 Management (c) 2006, Occello Audrey, SAR O3 SOA

Déroulement d’un exemple DEMO (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 (c) 2006, Occello Audrey, SAR O3 SOA

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

(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 qu’une révolution (c) 2006, Occello Audrey, SAR O3 SOA

Chronique d’une évolution services * objets * Langages procéduraux Assembleur Langages machine composants services 01011 10100 11000 Niveaux d’abstraction grandissant (c) 2006, Occello Audrey, SAR O3 SOA

(c) 2006, Occello Audrey, SAR O3 SOA Synthèse Depuis… …Vers… Orienté processus Conçu pour changer Développement et déploiement interactif Orienté fonctionnalités Conçu pour durer Cycle de développement long Silos applicatifs Couplage fort Orienté Objet Orchestration de Services Couplage faible Orienté message (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 d’exécution Difficile à effectivement implémenter Encore peu de chose sur la contractualisation (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 l’utilise (cf CORBA) La course à la spécification fait rage le W3C et l’OASIS se font la guerre Spec des processus Spec sur la sécurité … Pas de remise en cause de l’existant lors d’évolutions technologiques MAIS les vendeurs nous asservissent toujours avec leurs suites d’outils (c) 2006, Occello Audrey, SAR O3 SOA

Paradoxe des principes fondamentaux Découplage entre fournisseur et consommateur de services MAIS certains composants de services s’appellent : 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 l’enfant pauvre du SOA (c) 2006, Occello Audrey, SAR O3 SOA