Introduction lArchitecture Oriente Service

1
Introduction à lArchitecture Orientée Service

• Module SAR O3 SI3

2
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
3
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
A quels besoins répond le SOA ?
5
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
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
Hier plat de spaghettis

• Développements coûteux
• Interconnexions redondantes (point à point)
• Grande complexité
• Maintenance difficile

8
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
e-store Couches
PresentationLayer
10
e-store Domaines
PresentationLayer
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
11
e-store Domaines
PresentationLayer
BusinessLogicLayer
Catalog
Inventory
Shopping
Customer
Billing
12
e-store Services
PresentationLayer
BusinessLogicLayer
ServiceLayer
ShowCatalog
MakeInventory
Shop
ManageCustomer
Bill
13
Quels sont les principes de base du SOA ?
14
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
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
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

17
Exemple de couplage fort Gestion de prêts
LoanAgent
Loan
Account
LoanApproval
SMSGateway
calculateRisk
checkCredit
createLoan
sendConfirmation

• LoanAgent est lié à LoanApproval et Loan
• LoanApproval est lié à Account
• Loan est lié à SMSGateway

18
Gestion de prêts en couplage faible
LoanProcess
CheckAccountBalance
NotifyViaSMS
CreateLoan
CalculateLoanRisk

• Quest ce que LoanProcess ?
• Un processus métier !Il permet dorchestrer les
  services gt couplage lâche

19
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
BPM par lexemple
21
Les couches SOA
22
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
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
Quels sont les éléments clé dune architecture
orientée services ?
25
Points clés de larchitecture
Repository
Serviceconsumer
Contract
Mediation layer/Service bus
Serviceprovider
Registry
Business service orchestrator
26
Standards de larchitecture

• Les standards sont un élément clé dune SOA, ils
  assurent linteropérabilité

SOAP W3C Simple Object Access Protocol
UDDI Microsoft, IBM, HP Universal
Description Discovery and Integration
WSDL W3C Web Services Description Language
BPEL Oasis Business ProcessExecution Language
Transporte
Décrit le contrat
Décrit les processus métier
Spec pour Repository/Registry
Les trois piliers des Services Web
27
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
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
BPEL le chef dorchestre
30
BPEL par lexemple
ltPartnerLinkgt references to the services
participating in the process flow ltinvokegt a
credit rating service synchronously ltfaultHandlers
gt catch and manage exceptions when customer has
a bad credit history ltflowgt initiates
asynchronous loan processors in parallel of
execution ltreceivegt asynchronous
callbacks from longrunning loan
processors ltswitchgt to the lowest loan offer
31
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
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
Exemples darchitecture avec/sans ESB
Avec ESB
Sans ESB

• Plusieurs connecteurs
• Orchestration importante
• Transactions conséquentes

• Communications homogènes
• Pas dorchestration
• Peu de transactions

34
Quel est le cycle de vie dun service ?
35
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
Cycle de vie des services
Solution requirements
Service Owner Approval
ok
Search for Existing Implementation
Service Identified
Process Models
Service outlines
Candidate Consumers Identified
Service reusability Commission
ko
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
Develop Components
Integrate Test
Create Deployment Unit
Acceptance Test
Service Specification
Reusable Service Development
Service in registry
Code in repository
Operational Service in use
Monitor SLA Compliance
Certify Publish Service
Plan New Service Version
Deprecate Service
Decommission Service
Reusable Service Management
37
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
Rôles associés au cycle de vie des services
Business Analyst
Identification
Solution Architect
Spécification

• Defines services for use cases
• Models service implementation

• Defines and models processes and concepts
• Optimizes processes through simulations

ServiceDesign Model
Business Goals and Objectives
Business Design Model
SoftwareArchitecture
EnterpriseArchitecture
Business Requirements
Integration Developer
Developer
Développement
Développement

• Implements processes and composite apps
• Defines services

• Implements services
• Constructs other service artifacts

Service Flow Model
Implementation Model
ServiceAssembly 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 AssetsManagement
39
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
2 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
Approche Top Down
WSDL
New reusable Services
Service Specification
or process model
Orchestration (business rules and processes)
42
Approche Bottom Up
WSDL
Service Specification
Orchestration (business rules and processes)
or process model
43
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
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
Receive Application
Check Credit
Services Identified From Top Down and Bottom up
Analysis
Book the Loan
Adjudicate Loan
Close the Loan
Negotiate Loan
service components
Loan Product
Customer Accounting
Consolidated Book/Position
Correspondence
Application Processing
Doc Mgmt Archive
Credit Administration
Collateral Handling
Permissions Component
Notify Customer of Decision
operational systems
Receive Application
Calculate Risk Score
Decline Reasons
Image Documents
Modify Application

• Service
• Identification
• Interview
• Documentation
• Code Analysis

LOS (Loan Origination System)
Fair Issac Blaze
Enterprise Content Mgmt
IMS DB
Bottom up Analysis
45
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

46
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-specifi
  c 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
Quelles méthodologies et outils permettent de
mettre en oeuvre une architecture orientée
services ?
48
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
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
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
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
Loffre IBM
53
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

ServiceDesign Model
Business Goals and Objectives
Business Design Model
SoftwareArchitecture
EnterpriseArchitecture
Business Requirements
Integration Developer
Developer

• Implements processes and composite apps
• Defines services

• Implements services
• Constructs other service artifacts

Service Flow Model
Implementation Model
ServiceAssembly Model
Deployment Model
Service Registrar, Governance Performance
Managers

• Publish/retrieve services to/from registry
• Manage Business Service Lifecycle
  approval/rejections
• Control quality of service execution

Shared AssetsManagement
54
Comment les outils IBM couvrent le cycle de vie
UML Use cases
WebSphere Business Modeler
Rational Software Architect
Service Specification
WSDL
BPEL
WebSphere Integration Developer
Rational Application Developer
KPIs
Service Development
WebSphere ServiceRepository Registry
WebSphere Process ServerWebSphere ESB
WebSphere Business Monitor
WebSphere Business Services Fabric
Service Management
55
Déroulement dun exemple

• DEMO

56
Temps estimé pour ce processus simple

• Installation de la plate-forme 2 semaines
• Modélisation (flowKPI), 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
Conclusions
58
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
Chronique dune évolution
objets
Langagesprocéduraux
AssembleurLangages machine
services
composants
01011 1010011000 01011

• Niveaux dabstraction grandissant

60
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

61
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
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 ragele 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
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