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

(c) 2006, Occello Audrey, SAR O3 SOA

- 1 -

Introduction à l’Architecture Orientée Service

Module SAR O3 – SI3


- 2 -

§ 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

BusinessExecutive,

Analyst

Architect

Integrator Developer

Developer

What is Service-Oriented Architecture?


- 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é 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


- 4 -

A quels besoins répond le SOA ?


- 5 -

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


- 6 -

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


- 7 -

Hier : plat de spaghettis

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


- 8 -

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


- 9 -

PresentationLayer

CartControllerAccountController

BusinessLogicLayer

Account CartInventoryItem OrderInsert OrderReadProductProfile

Category

Checkout

CreateAccount

Default

ErrorHelpItemDetails

Items

MyAccount

EditAccount

OrderBilling

OrderProcess

OrderShipping

SignOut ShoppingCart

SearchSignIn

e-store : Couches

DataAccessLayer

IAccount IInventoryIItem IOrderIProductIProfile


- 10 -

DataAccessLayer

IAccount IInventoryIItem IOrderIProductIProfile

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


- 11 -

DataAccessLayer

PresentationLayer

BusinessLogicLayer

e-store : Domaines

Catalog Inventory ShoppingCustomer Billing


- 12 -

e-store : Services

PresentationLayer

BusinessLogicLayer

DataAccessLayer

ServiceLayer

ShowCatalog

MakeInventory

ShopManage

CustomerBill


- 13 -

Quels sont les principes de base du SOA ?


- 14 -

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


- 15 -

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


- 16 -

• Un Service expose un Contrat

• Les services communiquent par messages

Conditions Générales de Vente

Règlement IntérieurVos droits/Vos devoirs

in

out

• Un Service est Autonome

• Les Frontières entre services sont Explicites

4 propriétés du service à retenir


- 17 -

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


- 18 -

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

BPM par l’exemple


- 21 -

Les couches SOA


- 22 -

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


- 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é d’une architecture orientée services ?


- 25 -

Points clés de l’architecture

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


- 26 -

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


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


- 28 -

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


- 29 -

BPEL le chef d’orchestre


- 30 -

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


- 31 -

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


- 32 -

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


- 33 -

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


- 34 -

Quel est le cycle de vie d’un service ?


- 35 -

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


- 36 -

Provider Interfaces Documented

Service/Process Workflow Created

Service Specification CreatedService

Specification Review

Develop Components

Integrate & Test

Create Deployment

Unit

Codein

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 outlines

Servicein

registry

Codein

repository

okok

koko

Cycle de vie des servicesProcess Governance



- 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 l’infrastructure ?– Qui gère les interdépendances entre les

services ?– Comment exposer les services aux

entreprises partenaires ?


- 38 -

• 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

BusinessRequirements

BusinessDesign Model

Business Goalsand Objectives

ServiceDesign Model

SoftwareArchitecture

EnterpriseArchitecture

Service FlowModel

ServiceAssembly Model

ImplementationModel

DeploymentModel

Shared AssetsManagement

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

Identifica

tio

nSpécificatio

n

Développement

Développement

Gestion


- 39 -

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


- 40 -

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


- 41 -

Approche Top Down

Use Cases

Orchestration (business rules and processes)

Requirements

Story Board

WSDL

ServiceSpecification

New Application

Receive

Invoke

Invoke Invoke Reply

ReplyFault

Non-Interruptible

Receive

Invoke

Invoke Invoke Reply

ReplyFault

Non-Interruptible

or process model

New & reusable Services


- 42 -

Approche “Bottom Up”

reusable code

Orchestration (business rules and processes)

WSDL

ServiceSpecification

Change Cases

InterfaceSpecification

New Requirements

Legacyapplication

Receive

Invoke

Invoke Invoke Reply

ReplyFault

Non-Interruptible

Receive

Invoke

Invoke Invoke Reply

ReplyFault

Non-Interruptible

New Application

Story Boardor process model


- 43 -

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


- 44 -

“Meet in the Middle”: exemple du prêt

business processesprocess choreography

services

service components

operational systems

Lending

Loan Origination Loan Closure

Loan Servicing

IMS DB

LOS(Loan Origination System)

ModifyApplication

Receive Application

Check Credit

Negotiate Loan

Receive Application

Adjudicate Loan

Close the Loan

Application Processing

CustomerAccounting

Credit Administration Permissions

Component

LoanProduct

Consolidated Book/Position

Correspondence

Doc Mgmt & Archive

Book the Loan

CollateralHandling

Fair Issac Blaze

Calculate Risk Score

EnterpriseContentMgmt

ImageDocuments

DeclineReasons

Notify Customer of

Decision

Domain Analysis &Decomposition

ProcessDecomposition

Top Down Analysis

Bottom up Analysis

Service Identification Interview Documentation Code Analysis

Services Identified From Top Down and Bottom up Analysis


- 45 -

• 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

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


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

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 d’offres que de méthodologies différentes : de quoi s’y 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 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


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

L’offre IBM


- 53 -

• 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

BusinessRequirements

BusinessDesign Model

Business Goalsand Objectives

ServiceDesign Model

SoftwareArchitecture

EnterpriseArchitecture

Service FlowModel

ServiceAssembly Model

ImplementationModel

DeploymentModel

Shared AssetsManagement

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 -

Comment les outils IBM couvrent le cycle de vie

WebSphere Process ServerWebSphere ESB

WebSphere Business Modeler

WebSphere Integration Developer

Rational Software Architect

WebSphere Business Monitor

WSDLBPEL

KPIs

UML Use cases

WebSphere ServiceRepository & Registry

WebSphere Business Services

Fabric


Service Development

Service Management

Business Analyst

Business Analyst

IntegrationDeveloper

Rational Application Developer

Developer

Service Architect

Service Registrar

GovernanceManager

PerformanceManagerServer Administrator


- 55 -

Déroulement d’un exemple

DEMO


- 56 -

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 -

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 qu’une révolution


- 59 -

Chronique d’une évolution

**

objets

*

servicesservicesservicescomposants

Niveaux d’abstraction grandissant

Ass

emb

leu

rL

ang

ages

mac

hin

e

Langagesprocéduraux

01011101001100001011


- 60 -

Synthèse

• Orienté fonctionnalités

• Conçu pour durer

• Cycle de développement long

Depuis…Depuis… ……Vers…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 -

Avantages et inconvénients

Qualité de service Architecture adaptative Réutilisation du code Utilisation de standards Productivité accrue

Manque de maturité des standardsLenteur d’exécutionDifficile à effectivement implémenterEncore 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 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 technologiquesMAIS les vendeurs nous asservissent

toujours avec leurs suites d’outils


- 63 -

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 - 1 - Introduction à lArchitecture Orientée Service Module...

Documents

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