Foutse Khomh ©Occello, 2007; Khomh, 2013 Département de génie informatique et de génie logiciel...

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)


5/55


• 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


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


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.


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?


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)



SLT



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


(Pick-up/drop-off)

1.1.1.1Get Location

(Pick-up/drop-off)




Availability

1.1.1.6Offer Rates

For Selection


(Pick-up/drop-off)

1.1.1.1Get Location

(Pick-up/drop-off)




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/

Foutse Khomh ©Occello, 2007; Khomh, 2013 Département de génie informatique et de génie logiciel...

Documents

Transcript of Foutse Khomh ©Occello, 2007; Khomh, 2013 Département de génie informatique et de génie logiciel...