foutse khomh ©occello, 2007; khomh, 2013 département de génie informatique et de génie logiciel...
Post on 03-Apr-2015
107 Views
Preview:
TRANSCRIPT
Foutse Khomh
©Occello, 2007; Khomh, 2013
Département de génie informatique et de génie logicielÉcole Polytechnique de Montréal
LOG4430 :Architecture logicielle et
conception avancée
Introduction à l’Architecture Orientée Service (SOA)
2/55
Introduction à l’Architecture Orientée Service (SOA)
1. Contexte: Intégration en entreprise.
2. Principes de base du SOA.
3. Points clés de l’architecture SOA.
4. Cycle de vie d’un service.
5. Avantages et inconvénients.
6. Méthodes et outils permettent la mise en œuvre d’une architecture orientée services.
7. Références.
3/55
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
4/55
• Développements coûteux• Interconnexions redondantes (point à point)• Grande complexité• Maintenance difficile• Réutilisation difficile (couplage fort)
1. Contexte: Intégration en entreprise
5/55
1. Contexte: Intégration en entreprise
• Développements coûteux• Interconnexions redondantes (point à point)• Grande complexité• Maintenance difficile• Réutilisation difficile (couplage fort)
6/55
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
7/55
1. Contexte: Intégration en entreprise
8/55
1. Contexte: qu’est ce qu’une SOA?
Chaque rôle s'approprie les SOA différemment…
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
9/55
**
objets
*
servicesservicesservicescomposants
Ass
emb
leu
rL
ang
ages
mac
hin
e
Langagesprocéduraux
01011101001100001011
La SOA est une évolution des paradigmes précédents…
1. Contexte: qu’est ce qu’une SOA?
10/55
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
11/55
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
12/55
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.
2. Principes de base du SOA
13/55
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
Qu’est ce qu’un Service (au sens SOA)?
14/55
Un Service expose un contrat
Conditions Générales de VenteRèglement Intérieur
Vos droits/Vos devoirsin
out
Un Service est autonomeet sans état
Quatre propriétés du service à retenir…
Les frontières entre services sont explicites
Les services communiquent par messages
15/55
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
16/55
Exemple de couplage fort : Gestion de prêts
LoanAgent
calculateRisk
LoanAccount
createLoan
checkCredit
LoanApproval SMSGateway
sendConfirmation
Entités
LoanAgent est lié à LoanApproval et Loan LoanApproval est lié à Account Loan est lié à SMSGateway
17/55
Gestion de prêts en couplage faible
LoanProcess CreateLoanCheckAccountBalance
CalculateLoanRisk
NotifyViaSMS
Services
Qu’est ce que LoanProcess ?
Un processus métier !Il permet d’orchestrer les services => couplage faible
18/55
Au cœur des SOA on a donc: des Services et des processus
=>Comment gérer les processus?
2. Principes de base du SOA
19/55
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
20/55
BPM par l’exemple
21/55
Les couches SOA
**
Coup
lage
fort
Coup
lage
faib
le
au n
ivea
u te
chni
que
ou a
u ni
veau
logi
que
:
vision
com
posa
nts
Coup
lage
faib
le
au n
ivea
u lo
giqu
e
Ces différents modes de couplage sont nécessaires et dépendent du niveau dans l’architecture
Ex:
22/55
PresentationLayer
CartControllerAccountController
BusinessLogicLayer
Account CartInventoryItem OrderInsert OrderReadProductProfile
Category
Checkout
CreateAccount
Default
ErrorHelpItemDetails
Items
MyAccount
EditAccount
OrderBilling
OrderProcess
OrderShipping
SignOut ShoppingCart
SearchSignIn
Exemple d’un e-store : Couches
DataAccessLayer
IAccount IInventoryIItem IOrderIProductIProfile
23/55
DataAccessLayer
IAccount IInventoryIItem IOrderIProductIProfile
Exemple d’un e-store : Domaines
PresentationLayer
BusinessLogicLayer
Account CartInventoryItem OrderInsert OrderReadProductProfile
Category
Checkout
CreateAccount
Default
ErrorHelpItemDetails
Items
MyAccount
EditAccount
OrderBilling
OrderProcess
OrderShipping
SignOut ShoppingCart
SearchSignIn
Catalog Inventory ShoppingCustomer Billing
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
24/55
DataAccessLayer
PresentationLayer
BusinessLogicLayer
Exemple d’un e-store : Domaines
Catalog Inventory ShoppingCustomer Billing
25/55
Exemple d’un e-store : Services
PresentationLayer
BusinessLogicLayer
DataAccessLayer
ServiceLayer
ShowCatalog
MakeInventory
ShopManage
CustomerBill
26/55
SOA :des applications, Vue comme des clients d'autres applications
27/55
3.Points clés de l’architecture SOA
Serviceconsumer
Serviceprovider 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
Businessprocess description
28/55
3. Standards de l’architecture
Les standards sont un élément clé d’une SOA, ils assurent l’interopérabilité
Transporte
SOAPW3C
Simple ObjectAccess Protocol
Spec pour Repository/Registry
UDDIMicrosoft, IBM, HP
Universal DescriptionDiscovery and Integration
WSDLW3C
Web ServicesDescription Language
Décrit le contrat
BPELOasis
Business ProcessExecution Language
Les trois piliers des Services Web
Décrit les processus métier
29/55
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
30/55
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
31/55
BPEL le chef d’orchestre
32/55
flowPartnerLink
PartnerLink
PartnerLink
BPEL par l’exemple<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
33/55
4. Cycle de vie d’un service
4 grandes phases : IdentificationSpécificationDéveloppementGestion
1 aspect tranversal : la gouvernanceLes architectures orientées service impliquent une
vision globaleLa gouvernance permet de casser les silos de
l’entreprise
34/55
Provider Interfaces Documented
Service/Process Workflow Created
Service Specification CreatedService
Specification Review
Service Specification
Develop Components
Integrate & Test
CreateDeployment 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
4. Cycle de vie des services (activités de gouvernance)
Candidate Consumers Identified
Search for Existing
Implementation
Service Identification
Service Owner ApprovalService
IdentifiedService
reusability Commission
yes
no
exists?
35/55
• Définit les services pour les use cases
• Modélise les services
Architecte
• Définit les processus métiers et les KPI associées
• Identification des services métier• Optimise les processus via la
simulation
Analyste métier
• Assemble les services
Intégrateur
• Implémente les services
Développeur
Rôles associés au cycle de vie des services
• Publie les services • Gère le cycle de vie des
services • Contrôle la qualité de service
Gestionnaire
Identifica
tio
nSpécificatio
n
Développement
Développement
Gestion
36/55
Zoom sur la phase d’identification
Un des problèmes centraux pour mettre en œuvre une SOALa 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…
37/55
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
38/55
Approche “Bottom Up”Legacy applications
Décomposition du diagramme de classes
Besoins
Orchestration Specification des services
Diagrammes d'activités
Nouveaux Services + services réutilisables (l'existant)
Nouvelle application
39/55
Approche “Top Down”
Orchestration
Besoins
Décomposition du processus métier
Specification des services
Nouveaux Services + services réutilisables (l'existant)
Nouvelle application
Analyse des domaines métiers
40/55
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
41/55
• 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
Candidate Services
Candidate Services
Services (exposed)Services
(exposed)
Business AlignmentComposability
Externalized Service DescriptionRedundancy Elimination
SLT
Candidate Services
Candidate Services
Services (exposed)Services
(exposed)
Business AlignmentComposability
Externalized Service DescriptionRedundancy Elimination
SLT
Business AlignmentComposability
Externalized Service DescriptionRedundancy Elimination
SLT
Zoom sur la phase de spécification
42/55
• 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, ...)
Quelques critères d' “exposabilité”
43/55
Location de véhicules : services exposés
1.1.1.2Get Date / time
(Pick-up/drop-off)
1.1.1.1Get Location
(Pick-up/drop-off)
1.1.1.3ChooseVehicle
1.1.1.4Get OptionsInformation
1.1.1.5Check Vehicle
Availability
1.1.1.6Offer Rates
For Selection
1.1.1.2Get Date / time
(Pick-up/drop-off)
1.1.1.1Get Location
(Pick-up/drop-off)
1.1.1.3ChooseVehicle
1.1.1.4Get OptionsInformation
1.1.1.5Check Vehicle
Availability
1.1.1.6Offer Rates
For Selection
1.1.1.2Get Date / time
(Pick-up/drop-off)
1.1.1.1Get Location
(Pick-up/drop-off)
1.1.1.3ChooseVehicle
1.1.1.4Get OptionsInformation
1.1.1.5Check Vehicle
Availability
1.1.1.6Offer Rates
For Selection
0.Rent Vehicle
1.1.2Make
Reservation
1.1.1CheckRates
1.2Check-out
Vehicle
1.2.1Locate
Reservation
1.2.2Modify
Reservation
1.2.3Create Rental
Agreement
1.2.4Sign-out
Vehicle from Lot
1.2Check-out
Vehicle
1.2.1Locate
Reservation
1.2.2Modify
Reservation
1.2.3Create Rental
Agreement
1.2.4Sign-out
Vehicle from Lot
1.2.1Locate
Reservation
1.2.2Modify
Reservation
1.2.3Create Rental
Agreement
1.2.4Sign-out
Vehicle from Lot
1.3Check-inVehicle
1.3.1Locate Rental
Agreement
1.3.2Process Return
Information
1.3.3ProcessPayment
1.3.4Return
Vehicle to Lot
1.3Check-inVehicle
1.3.1Locate Rental
Agreement
1.3.2Process Return
Information
1.3.3ProcessPayment
1.3.4Return
Vehicle to Lot
1.3.1Locate Rental
Agreement
1.3.2Process Return
Information
1.3.3ProcessPayment
1.3.4Return
Vehicle to Lot
1.1ReserveVehicle
1.1.2.2Get CustomerInformation
1.1.2.1Confirm Rental
Information
1.1.2.3Get PaymentInformation
1.1.2.4Confirm
Reservation
1.1.2.5Create
Reservation
1.1.2.2Get CustomerInformation
1.1.2.1Confirm Rental
Information
1.1.2.3Get PaymentInformation
1.1.2.4Confirm
Reservation
1.1.2.5Create
Reservation
44/55
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
45/55
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.
46/55
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.
47/55
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.
48/55
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é.
49/55
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.
50/55
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 !
51/55
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
52/55
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)
53/55
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
54/55
Exemple: Gamme d'outils IBM couvrant le cycle de vie complet
WebSphere Process ServerWebSphere ESB
WebSphere Business Modeler
WebSphere Integration Developer
Rational Software Architect
WebSphere Business Monitor
WSDLBPEL
KPIs
WebSphere Service
Repository & Registry
WebSphere Business Services
Fabric
Service Specification
Service Development
Service execution & Management
Business Analyst
Business Analyst
IntegrationDeveloper
Rational Application
Developer
Developer
Service Architect
Service Registrar
GovernanceManager
PerformanceManagerServer Administrator
55/55
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 IBMhttp://www-306.ibm.com/software/fr/soa/
top related