SOA - Architecture Orientée Service : Démystification

SOA - Architecture Orientée Service : Démystification

Khaled BEN DRISS

[email protected] Samedi 05 mai 2007

JCI

[email protected] 22

Un cabinet d'Architecture S.I.

Khaled BEN DRISSConsultant / Formateur

� Ingénieur de l'Ecole Centrale de Lyon (ECL 1991)� Docteur de l'Université Paris 6 ( 1994)


� Ancien Maître Assistant à l'Ecole Polytechnique de Tunisie

�Fondateur Net-Progress�Architecte de Système d'Information

• 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 permettent de mettre en

Plan


• Quelles méthodologies permettent de mettre en oeuvre une architecture orientée services ?

SOA, différents points de vue• Two IT professionals were discussing their respective

environments, when one asked the other, if his team was

building a service-oriented architecture. The individual

responded by saying :

« My architect thinks it’s service-oriented, my developers insist it’s


« My architect thinks it’s service-oriented, my developers insist it’s

object-oriented, and my analysts whish it would be more

business-oriented. All I can tell you is that it isn’t what it was

before we started building Web services."

SOA, différents points de vue

• C’est un signe des temps. SOA est devenu un des

principaux focus de l’industrie informatique.

• Tout le monde en parle, se réclame de cette

mouvance


Objectifs des S.I.

• Accès rapide, intégré et généralisé à l’information pertinente− en interne (Intranet) et en externe (Extranet, Internet)

• Système ouvert réduisant les coûts− capable d'inter-opérer avec les applications existantes− capable d'inter-opérer avec le monde extérieur (Extranet,

Internet)


Internet)

• Développement rapide d’applications (RAD)− utilisation de composants distribués− réduction des coûts de développement

• Administration simplifiée du système− depuis le Web avec des outils d'assistance

Introduction

•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

Problématique de l’intégration en entreprise

Division ADivision B Division C


ERP

DB

CRM

Des Silos sans communicationDes Silos sans communication


•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

• Les entreprises doivent s’adapter en permanence aux variations des marchés (diversification des offres commerciales, fusions, acquisitions, changement technologiques, …)

• Leurs SI ne doivent pas être un frein à ces changements


SOASOA

[email protected] 1010� C’est l’activité qui pilote la technologie et non l’inverse

SOASOA

Hier : plat de spaghettis


• Développements coûteux• Interconnexions redondantes (point à

point)• Grande complexité• Maintenance difficile

Intégration de services

SOAP/HTTP

SOAP/HTTP SOAP/MQ

Service Consumers

Service Consumers

Service Providers

Service Providers

Legacy Systems


• Solution provisoire !

Service Oriented Architecture

Courtier de

Services

Consommateurs

De Service

fournisseurs

de Services


Service Oriented Architecture

Courtier de

Services

Consommateurs

De Service

fournisseurs

de Services


Annuaire

MonitoringSLASécurité

Transformation

SOA, différents points de vue

Businessvirtualization des Services, visibilité,

sécurité


IT Ingénieur Système

Architecte

Développeur

#$%! bugs…I need a Diet Coke…

Point de vue du développeur• Classes ?• Composants ?• Services ?• Marshalling ?• Corba ?• Idl ?


• Idl ?• Spring ?• .net ?• WebServices ?• Interopérabilité ?• Langages Java, C#?• …

Point de vue de l’ingénieur système• Configuration des services ?

− Et s’ils sont déplacés

• Sécurité des services ?

• Intégration dans mon système ?


• Qui a le droit ?

• Interopérabilité ?

• Montée en charge ? Disponibilité ? QOS

• ESB & hardware & software

• Installation ? Migration ?

Point de vue de l’architecte• Spécifications des composants ?

• Savent-ils parler entre eux ?

• Granularité ?

• Contrat ?

• Qualité de service ?


• Qualité de service ?

• Asynchronisme ?

• Indépendance des briques ?

• Réutilisation ?

• Urbanisation ?

Point de vue du responsable IT du projet• Indépendance entre les briques ?

• Assemblage ?

• Orchestration ?

• Intégration ?


• Intégration ?

• Interopérabilité ?

• …

Point de vue du responsable métier

• Réactivité ?

• Souplesse ?

• Accès des partenaires ?

• Retour sur investissement ?


• Retour sur investissement ?

• Capacité d'intégrer de nouveaux services ?

• …

Quels sont les principes de base du SOA ?


SOA est une évolution des plate-forme passées

• SOA est une évolution des plate-forme passées, • tout en préservant les caractéristiques réussies des

architectures traditionnelles, • tout en y ajoutant quelques principes nouveaux.

• SOA est un paradigme abstrait, base de


• SOA est un paradigme abstrait, base de l’architecture distribuée sans aucune référence à une implémentation technique (souvent implémentés sous forme de Web Services, mais pas obligatoirement)

SOA & Architecure

• SOA représente une architecture ouverte,

exensible, 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− Intéropérables− Potentiellement réutilisables

Notre définition de la SOA

• La SOA c’est structurer− une application, − un bloc applicatif,− voire le SI,

�en services contractualisés


• Afin d’adresser les enjeux de− Politique d’interopérabilité

• mise en œuvre de services globaux entre blocs applicatifs

− Politique de réutilisation• recherche de la réutilisation à l’intérieur d’un bloc applicatif

− Assurer la pérennité des applications• "Faire du nouveau avec de l'ancien"

Dans SOA il y a Service ?

• SOA est une histoire de conception pas de technologie : penser Architecture et Service.

• Avant tout : un service doit être "abstrait" : il n’est pas lié à une implémentation.


• Exemple− Service d'enregistrement d'un abonnée Carta+ (Tunisiana)− Service de réservation d'un train− Service de diffusion d'information − Service de demande de l'état d'une commande (Tunicommerce : Gs1

Tunisie)

Qu’est ce qu’un Service (au sens SOA) ?

•Partage la caractéristique suivante d’un objet− Modulaire (ensemble de fonctionnalités qui font sens)

•Partage les caractéristiques 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 exposé à des consommateurs (une granularité plus forte qu’un composant)

•Expose un petit nombre d’opérations offrant un traitement de bout en bout

•Est faiblement couplé •Sans état

•Un Service expose un Contrat

Conditions Générales de VenteRèglement Intérieur

Vos droits/Vos devoirsin

out

•Un Service est Autonome

4 propriétés du service à retenir


•Les services communiquent par

messages

out

•Les Frontières entre

services sont Explicites

4 propriétés : conséquences

• 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

• Importance de l'Architecture ++

Découpage du cycle de vie d’un service

• 4 grandes phases :− Identification− Spécification− Développement− Gestion


− 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

SOA


Et les Web Services dans tout cela?


Et les Web Services dans tout cela?

SOA n'est pas Web Services

• SOA est un paradigme abstrait, base de l’architecture distribuée sans aucune référence à une implémentation technique

• L'accent est mis sur • les standards• L'interopéarbilité• Le couplage faible


• Le couplage faible

• Les Web Services offrent une implémentation possible mais pas nécessaire

"Architecture" Web Services

ServiceProvider

ServiceProvider

ServiceProvider

ServiceRegistry

Request

Request

Publish

Publish

Publish

SERVEUR

SERVEUR

SERVEUR

SERVEUR


ServiceRequester

ServiceProvider

Provider

WEB-HTTP

CLIENT

Request

Request

Publish

Publish

Find

SERVEUR

SERVEUR

Les Composants

• Service Provider (Fournisseur de service)− Application s'exécutant sur un serveur et comportant un module

logiciel accessible par IxxNet en XML

• Service Registry (Annuaires de service)− Annuaire des services publiés par les providers (UDDI)


− Géré sur un serveur niveau application, entreprise ou mondial

• Service Requester (Demandeur de service)− Application cliente se liant à un service et invoquant ses fonctions

par des messages XML (SOAP)

Qu'est ce qu'un Web Service ?

• Définition [W3C]− Un Web service est un système logiciel identifié par une URI, dont

les interfaces publiques et les liens sont définis et décrits en XML.− Sa définition peut être découverte par d'autres systèmes logiciels. − Ces systèmes peuvent interagir avec le service Web d'une manière

prescrite par sa définition, en utilisant des messages XML portés par les protocoles Internet.


• Exposition− Langage WSDL (Web Service Description Language) utilisé pour

décrire le service− Similaire à IDL mais basé sur XML

• Activation− Protocole Web au-dessus de HTTP (RPC XML, SOAP)− Autres protocoles possibles …

Services Web ~ quatre spécifications XML• SOAP : pour le transport des données et

l’infrastructure de communication• WSDL : pour la description des services offerts

• UDDI : annuaire pour le référencement des services par les fournisseurs et leur découverte par les utilisateurs.

• BPEL : décrit le processus métier


• BPEL : décrit le processus métier

SOAP : Simple Object Access Protocol

Procuration TranslateurMessages

SOAPAppel

Port de connexion (URL)

Pare-feu Pare-feu

•Intégration de XML au-dessus de HTTP :•Pour accéder services, objets et serveurs •Indépendant de toute plate-forme


Application Cliente

Parser XML

Procuration

d'interface

Translateur

SOAP

Parser XML Serveur

d'application

SOAPAppel

Réponse

HTTP

RPC

local

XML-RPC et SOAP

Structure d'un message

Protocol Headers

SOAP Envelope

Entête de protocoles (HTTP, SMTP, …)

<Envelope>

<Header>


SOAP Header

SOAP Body

<Header>

<Body>

XML-RPC et SOAP

WSDL (Web Service Description Language)- Proposition jointe IBM, Microsoft, Ariba - septembre 2000.

- Permet de décrire le service Web, en précisant :- Les méthodes qu'il rend disponible;- Les paramètres d'entrée et de sortie;- et comment y accéder.

- Grammaire XML (schéma XML ) : Modulaire


- Offre une interface qui est le point d’entrée du service.

Description des services: WSDL

• Elément Type− Types des paramètres (schéma XML)

• Elément Message− Appel et retour de chaque opération

• Elément Port type


• Elément Port type− Groupe d'opération

• Elément Binding− URL de l'opération− Type de protocole

UDDI : Annuaire des services

•Universal Description,

Discovery and Integration

•Annuaire des services− décrit par un document− WSDL, autre …

Annuaire UDDI

Annuaire UDDI


− WSDL, autre …

•Accessible en SOAP

•Fonctions−Enregistrer votre société−Enregistrer des services−Enregistrer des opérations−Découvrir des services−…

Gérant de requêtes

Enveloppe+

Document

Programme

Service

UDDI : utilité


Scénario classique d'utilisation d'UDDI

Le langage BPEL : Business Process Execution Language

• Standard de l’OASIS

• Norme permettant de décrire des processus en XML

• Propose les fonctions basiques d’un langage de programmation:

[email protected] 4343XML-RPC et SOAP

programmation:− sequence, flow, loop, switch…

• Identification des Instances de Process

• Gestion des transactions longue durée (scope, compensation)

• Gestion des erreurs

BPEL le chef d’orchestre


Services Web au service du SOA• Une technologie "enabling"

− facilite l'interopérabilité et la connaissance

• Capacité d'exposer des programmes existants− Exposer des services écrits en Cobol!!!

• SOAP : Un protocole normalisé par le W3C• XML : "chaîne de caractères" focalisée sur le contenu semi-

structuré, multi - plateforme


structuré, multi - plateforme• Apporte lisibilité, validation, contrôle, interopérabilité

− IBM, Sun, Microsoft supporteront le même protocole

Architecture


SOA s'applique à tout les niveaux ?

Rappel de la définition de la SOA

• La SOA c’est structurer − une application, − un bloc applicatif,− voire le S.I., �en services contractualisés


•

Architecture en couches (simplifiée)

Présentation

Applications


Services métier

Données

Services de base

Services de base

• composants offrant un service générique à

tout service métier qui veut l’utiliser

• valeur ajoutée− permet d’économiser des coûts de développement et

d’exploitation: develop once, use many


d’exploitation: develop once, use many− permet aux développeurs de services métier et

d’applications de se concentrer sur les services métier− cohérence pour les utilisateurs des différentes

applications− simplifie l’offre et le monitoring de processus et de

chaînes de processus

Services de base• gestion des utilisateurs• signature électronique• transformation de formats• ticketing et accusé de réception• time stamping• routage


• routage• gestion de statut• orchestration• logging• ...

Services métier et applications

• développement de services métier grâce à la coordination

de composants et l’utilisation de services de base

• développement d’applications répondant aux besoins des

différents types d’utilisateurs par une coordination des

services métier


• où les mêmes composants et services de base peuvent être

utilisés pour le développement de différents services

métier, et où les mêmes services métier peuvent être

utilisés pour le développement de différentes applications

SOA : des applications, Vue comme des clients d'autres applications

Application Application Application

OrchestrationOrchestration Enterprise Application Integration

Services Exposés

Enterprise

Clients


OrchestrationOrchestration Enterprise Application Integration

Services Consultés

Application Application Application

Enterprise Service Bus

Fournisseurs

Principes fondamentaux de l’architecture SOAIl 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


− 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

•Quelques méthodologies encours : Praxeme …

Identification des services :2 méthodologies

• 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

Approche Top Down

Requirements

WSDL

ServiceSpecification

New & reusable Services


Use Cases

Orchestration (business rules and processes)

Requirements

Story Board

New Application

Receive

Invoke

Invoke Invoke Reply

ReplyFault

Non-Interruptible

Receive

Invoke

Invoke Invoke Reply

ReplyFault

Non-Interruptible

or process model

Approche “Bottom Up”

reusable code

WSDL

ServiceSpecification

Legacyapplication

New Application


Orchestration (business rules and processes)

Change Cases

InterfaceSpecification

New Requirements

Receive

Invoke

Invoke Invoke Reply

ReplyFault

Non-Interruptible

Receive

Invoke

Invoke Invoke Reply

ReplyFault

Non-Interruptible

Story Boardor process model

Approche “Meet in the Middle”

• On utilise rarement une unique approche

• Dans la pratique :− Faire l’analyse Top-down sans se préoccuper de l’existant

− Faire l’analyse Buttom-up en ne considérant que 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 nécessaires pour réutiliser le maximum de code

Démarche articulée autour de 3 principes

• Une démarche projet centrée sur le Dossier

d’Architecture Générale (DAG)− Fédérateur des visions de tous les acteurs du projet

• Un socle de « référentiels SI »− Référentiel d’architecture (modèles d’architecture, principes


− Référentiel d’architecture (modèles d’architecture, principes organisationnels, outils et méthodes)

− Cartographie générale (services, référentiels, processus)− Schéma directeur SI (cible et trajectoire)

• Une démarche de capitalisation fondée sur les

retours d’expérience des projets− Alimentée par les équipes opérationnelles

Où en est SOA par rapport à ce Cycle


BOSOA : Business Oriented SOA !!

Service Broker(s)

Service Consumers

Service Providers

Business Process Flows

Business Rules


RegistryMonitoringPoliciesSecurity

Transfor-mation

Adaptors

À suivre …

Synthèse

• Orienté fonctionnalités

• Conçu pour durer

• Cycle de développement

Depuis…Depuis… …Vers……Vers…

• Orienté processus

• Conçu pour changer

• Développement et


• Cycle de développement

long

• Développement et

déploiement interactif

• Silos applicatifs

• Couplage fort

• Orienté Objet

• Orchestration de Services

• Couplage faible

• Orienté message

Un dernier conseil : Optimiser les performances de votre S.I. en fonction de vos besoins métiers

SOA : Simple, Opérationnel et Accessible !


votre S.I. en fonction de vos besoins métiers

C’est l’activité qui pilote la technologie et non l’inverse

Khaled BEN DRISS

Net-Progress

Conseil & Ingénierie en Système d'Information

Merci


Conseil & Ingénierie en Système d'Information

GSM : (216) 98 33 46 17

email : [email protected]

SOA - Architecture Orientée Service : Démystification

Business

Transcript of SOA - Architecture Orientée Service : Démystification