SOA : pour une interopérabilité intrinsèque du Système d’Information

SOA : pour une interopérabilité intrinsèque du Système d’Information

Khaled BEN DRISS

[email protected]

Tozeur le 25 novembre 2008

Khaled BEN DRISS

� Ingénieur de l'Ecole Centrale de Lyon (ECL’1991)� Docteur de l'Université Paris 6 ( P&MC ‘ 1994)

[email protected]: SOA pour une interopérabilité intrinsèque du SI [email protected] -Tozeur – 25/11/2008

SO

A–

OX

IA –

2008

11

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

� Directeur Technique OXIA � Consultant Senior : Architecte de Système d'Information

� www.oxiasoft.com

Objectif de la séquence


SO

A–

OX

IA –

2008

22

Plan

Plan de la présentation

� Evolution des architectures informatiques : applications & Système d’information

� SI : Problématique de l’intégration en entreprise et intra-entreprises

� Interopérabilité : différents points de vue

� Présentation du concept SOA

� La notion de service (au sens SOA)

� Cycle de vie d’un service

� Approches d’identification des services


SO

A–

OX

IA –

2008

333


� Services Web : les spécifications XML de base� SOAP

� WSDL

� UDDI

� BPEL

� Web service pas forcément interopérable : WS-I et Basic Profiles

� SOA : quelles infrastructures?

� Notion de SLA et les besoins non fonctionnels

� Best Practices : SOA & interopérabilité

Terminal

Ordinateurpersonnel1990

Réseaux globaux

Technologie


SO

A–

OX

IA –

2008

4

Mainframe

Terminal

1970

1980

1990Informatique personnelle

Transactionnel

Travail coopératif

Activités


SO

A–

OX

IA –

2008

5

1970

1980

Batchs

1990

Industrialisation

Informationà la place de travail

Services offerts


SO

A–

OX

IA –

2008

6

1970

1980

Automatisation des processus administratifs

Gestion intégrée

1990

Enjeux

Vivant

Objectif


SO

A–

OX

IA –

2008

7

1970

1980Mécanique

Cahier des charges

Objectif

Prévisible

Réactif

Besoin d’automatisation

1990


SO

A–

OX

IA –

2008

8

1970

1980

Marché

Business Model

• Mondialisation

• Actionnaires

• Fusion/acquisition

• Publicité

Contexte économique

S.I.


SO

A–

OX

IA –

2008

99

Business Model

Eco-système

• Open source

• Compétition

• Compétition

• Compétition

• Compétition

S.I.

MainframeMainframeClient/ServerClient/Server

réseauxréseaux

Environnement d’aujourd’hui Résolument Hétérogène


SO

A–

OX

IA –

2008

10

InternetInternetet Webet Web

OXIA

Net-Progress

Web

ServeurInternet

Architectures informatiquesTypes et contraintes


SO

A–

OX

IA –

2008

11

Partage de fichiers

Client-Serveur

Distribuée

Client-serveurdeux niveaux

Interface utilisateurServices d'entreprise

Client-serveurtrois niveaux

Interface utilisateur

kkwkj aaaawwwwwkkwkj aaaawwwwwkkwkj aaaawwwwwkkwkj aaaawwwwwkkwkj aaaawwwwwkkwkj aaaawwwwwkkwkj aaaawwwww

Centralisé

Evolution de l'architecture des applications :De la centralisation vers la centralisation


SO

A–

OX

IA –

2008

12

Services de données

Services d'entreprise

Services de données

Servicesd'entreprise

Servicesd'entreprise

Interface utilisateurServices d'entrepriseServices de données

Contextearchitectures informatiques


SO

A–

OX

IA –

2008

1313

Plan



� S.I. : Problématiques de l’intégration en entreprise et intra-entreprises







SO

A–

OX

IA –

2008

141414



� WSDL

� UDDI

� BPEL





Objectifs des S.I.récapitulatif.


SO

A–

OX

IA –

2008

1515Introduction

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

Des Silos sans communicationL’information ou les données sont difficiles à trouver et à relier


SO

A–

OX

IA –

2008

16

Division ADivision B Division C

ERP

DB

CRM

difficiles à trouver et à relier

• Problèmes au moment de l’échange des données

Résultat : l’information et les données coûtent cher

L’Intégration doit être le mot d’ordre!

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


SO

A–

OX

IA –

2008

17

Coûts considérables dans la gestion des flux entre départements et dans l’intégration de leurs SI

Problématique de l’intégration inter-entreprises

Compagnie aérienne(plateforme technique1)

Agence de voyages(plateforme technique2)

Application web

Client(plateforme technique6)Réservation

Tozeur)


SO

A–

OX

IA –

2008

18

Location de voitures(plateforme technique3)

Chaîne hôtelière(plateforme technique4)

Assurance voyage(plateforme technique5)

Réservation

Réservation, Tarifs Tarifs, promotion

D’après : J-M Chauvet

Applications distribuées & l’Interopérabilité


SO

A–

OX

IA –

2008

1919

Définition générale de l’Interopérabilité

L'interopérabilité connecte

Les personnes : cet aspect de l'interopérabilité concerne les workflows et la collaboration qui ont lieu au sein et entre les entreprises au niveau des

personnes. C'est l'aspect social du travail qui est ici concerné.

Les données : il s'agit là de répondre au besoin d'accéder à différentes sources de


SO

A–

OX

IA –

2008

2020

Les données : il s'agit là de répondre au besoin d'accéder à différentes sources de données, d'optimiser les flux d'informations et d'intégrer des données

structurées (des bases de données par exemple) et des données non-structurées (des fichiers par exemple).

Les systèmes variés : ce point concerne les processus techniques et les processus d'exploitation au sein et entre les entreprises. Les besoins allant d'une simple

connectivité entre des systèmes internes à des cadres de travail de l’industrie qui facilitent la mise en oeuvre de workflows de création de chaîne de valeur.

Architectures d’interopérabilité

Intégration et communication entre

composants applicatifs

avec middleware

Deux modes de communication

Sans connexion (asynchrone,

couplage faible)

Mise en œuvre systématique dans un cadre d’urbanisation

Formats d’échange : XML (eXtended Markup

Language)


SO

A–

OX

IA –

2008

2121

sans middleware)

Avec connexion (synchrone,

couplage fort)

Intégration de systèmes complexes: EAI (Enterprise

Application Integration)

Modèle d’architecture cible: SOA ( Service Oriented

Architecture)

Les types de middleware classiques


SO

A–

OX

IA –

2008

2222

La réalité dans les SI:SOA (Spaghettis Orientée Service)

Développements coûteux

Interconnexions redondantes

(point à point)

Grande Maintenance


SO

A–

OX

IA –

2008

23

Grande complexité

Maintenance difficile

Plan










SO

A–

OX

IA –

2008

242424



� WSDL

� UDDI

� BPEL





Interopérabilité : différents points de vue


SO

A–

OX

IA –

2008

2525

Interopérabilité : différents points de vue

métier

Responsable IT

Indépendance , intégration


SO

A–

OX

IA –

2008

26

virtualization des Services, visibilité,

sécurité

Ingénieur Système

Architecte

Développeur

#$%! , java C#, bugs…I…

Responsable IT

Intégration & interopérabilité , différents points de vue :le « nécessaire changement » de paradigme

on ne peut résoudre, définitivement, un problème en utilisant le mode de pensée

à l’origine de ce problème.


SO

A–

OX

IA –

2008

2727

On a besoin d’une nouvelle approche !

Plan










SO

A–

OX

IA –

2008

282828



� WSDL

� UDDI

� BPEL





Service Oriented ArchitectureSOA, qu’est-ce? (1/3)

SOA est un paradigme abstrait, base de

l’architecture distribuée sans aucune référence à une implémentation


SO

A–

OX

IA –

2008

2929

Une nouvelle plate-forme architecturale pour le développement de solutions distribuées

à une implémentation technique

Service Oriented Architecture SOA, qu’est-ce ? (2/3)


SO

A–

OX

IA –

2008

3030

Service Oriented Architecture SOA, qu’est-ce ? (3/3)

SOA est une évolution des plateformes passées,

tout en préservant les


SO

A–

OX

IA –

2008

3131

tout en préservant les caractéristiques réussies

des architectures traditionnelles, tout en y

ajoutant quelques principes nouveaux.

Une définition de la SOA

La SOA c’est structurer en services contractualisés

une application un bloc applicatif Voire tout le S.I.


SO

A–

OX

IA –

2008

3232

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

Pérennité des applications

"Faire du nouveau avec de l'ancien"

Les Composants


SO

A–

OX

IA –

2008

3333

Service Oriented Architecture :une architecture Consommateur/Fournisseur

Courtier de Services

Consommateurs

De Service

Fournisseurs

de Services


SO

A–

OX

IA –

2008

34

Annuaire

MonitoringSLASécuritéTransformation

Plan










SO

A–

OX

IA –

2008

353535



� WSDL

� UDDI

� BPEL





Dans SOA il y a Service ?

SOA est une histoire de

conception pas de technologie

penser

Avant tout : un service doit

être "abstrait"

Un service n’est pas lié à une

Exemple

Service d'enregistrement d'un abonnée

Service de réservation d'un


SO

A–

OX

IA –

2008

3636

penser Architecture &

Service.

pas lié à une implémentation.

Service de réservation d'un train

Service de diffusion d'information

Service de demande de l'état d'une commande

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)• Modulaire (ensemble de fonctionnalités qui font sens)

Partage les caractéristiques d’un composant


SO

A–

OX

IA –

2008

3737

• Boite noire (séparation interface/implémentation)• 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• Expose un petit nombre d’opérations offrant un traitement de bout en bout

• Est faiblement couplé

• Sans état

Avant l’approche service: couplage fort - Gestion de prêts

AgentDeCrédit

calculerRisque

CréditCompte

vérifierCrédit

ApprobationCrédit SMSGateway

Entités


SO

A–

OX

IA –

2008

38

creerCrédit

EnvoyerConfirmation

� AgentDeCrédit est lié à ApprobationCrédit et Crédit� ApprobationCrédit est lié à Compte� Crédit est lié à SMSGateway

Après l’approche service :Gestion de prêts en couplage faible

ProcessusCrédit créerCréditVérifierBalanceCpt CalculerRisqueCérdit

NotifierViaSMS


SO

A–

OX

IA –

2008

39

� ProcessusCrédit Un processus métier !Il permet d’orchestrer les services => couplage lâche

Les services identifiés ne doivent pas être

tous publiés :

Chaque service a un coût et un

Challenge :

trouver les “bons” services

Un service peut être

synchrone

Zoom sur la phase de spécification


SO

A–

OX

IA –

2008

40

a un coût et un risque

Il faut éviter la prolifération des services

“bons” services à exposer

synchrone

Asynchrone

Un Service expose un Contrat

Conditions Générales de VenteRèglement IntérieurVos droits/Vos devoirs

in

out

Un Service est Autonome

4 propriétés du service à retenir


SO

A–

OX

IA –

2008

41

Les services communiquent par messages

out

Les Frontières entre services sont Explicites

4 propriétés : conséquences

SOA véhicule des Messageset non des objets

Le consommateur (client) est découplé de l’architecture technique du service qu’il invoque


SO

A–

OX

IA –

2008

4242

invoque

Le consommateur et le fournisseur

n'ont pas forcément les

mêmes technologies

Importance de l'Architecture

Importance des standards

4 propriétés : conséquences


SO

A–

OX

IA –

2008

4343

Plan










SO

A–

OX

IA –

2008

444444



� WSDL

� UDDI

� BPEL





Cycle de vie d’un service

4 grandes phases :

Identification

Spécification

1 aspect transversal : la gouvernance

Les architectures orientées service impliquent une vision globale

La gouvernance permet de casser


SO

A–

OX

IA –

2008

4545

Spécification

Développement

Gestion (versionning, …)

La gouvernance permet de casser les silos de l’entreprise

Évolution naturelle et certaine

• Fonction � Composant � Service

Les services gèrent messages, données et composants

• Les données privées sont totalement encapsulées par le service

• Les messages sont le seul moyen d’échanges entre services

ServiceService

Donnéesprivées

Un service n’est pas un composantUn service n’est pas un composant


SO

A–

OX

IA –

2008

46

entre services

Fonctions

ComposantsComposants

Les services permettent des relations faiblement couplées; les composants des relations fortement couplées

privées

exemples de servicesen fonction de la granularité

Granularité Exemple

Service métier applicatif Très forte Génération bulletins de paie

Service métier fonctionnel Moyenne Transaction bancaire

Service métier CRUD Faible Enregistrement nouvel inscrit

Service technique Moyenne/forte Archivage


SO

A–

OX

IA –

2008

4747

Plan










SO

A–

OX

IA –

2008

484848



� WSDL

� UDDI

� BPEL





Deux approches d’identification des services

Approche Top-down

Pour démarrer un nouveau projet

Approche Bottom-up

Pour réutiliser l’existant (non SOA)


SO

A–

OX

IA –

2008

4949

Dans le cadre d’une vision globale très claire

On part des morceaux, on rassemble les bouts

Quelques méthodologies (nouvelles): Praxeme, SOMA (IBM) …

On utilise rarement une unique approche :Approche “Meet in the Middle”

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


SO

A–

OX

IA –

2008

5050

Comparer les services “remontés” avec ceux déduits des Uses case

Penser réutilisation

Penser métier

Penser interopérabilité & standards

Plan










SO

A–

OX

IA –

2008

515151



� WSDL

� UDDI

� BPEL





Implémentations des Services

Maximiser l’interopérabilité par l’usage systématique des


SO

A–

OX

IA –

2008

5252

l’usage systématique des standards?

SOA et web services

Attention à ne pas confondre SOA et web services

SOA est un ensemble de concepts :

Les WS sont de l’ordre de la technologie :

Les WS constituent une bonne solution

standardisée disponible

Un service métier = un webservice


SO

A–

OX

IA –

2008

5353

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

Une SOA peut se mettre en œuvre sans Web Services

On peut utiliser les Web Services sans faire de SOA (architecture point à point sans réutilisation)

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

Points clés de l’architecture

Consommateur Service

Mediation layer/Service bus

Repository

1.a rechrcehr un service

1.b Returner le contract

2.a Creer une intsance du processus


SO

A–

OX

IA –

2008

54

Fournisseur Service Registry

Mediation layer/Service bus

2.c determiner le point de contact du service

2.b Executer processus

2.d enjoyer la requêtte

Description “Businessprocess”

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


SO

A–

OX

IA –

2008

5555

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

XML

Standards de l’architecture WS

Les standards sont un élément clé d’une SOA, ils assurent l’interopérabilité

SOAP UDDIWSDL BPEL


SO

A–

OX

IA –

2008

56

Transporte

SOAPSimple ObjectAccess Protocol

Spec pour Repository/Registry

UDDIUniversal DescriptionDiscovery and Integration

WSDLWeb ServicesDescription Language

Décrit le contrat

BPELBusiness ProcessExecution Language

Les trois piliers des Services Web

Décrit les processus métier

Lien avec BPMN

W3C W3C Microsoft, IBM, HP, …

Plan










SO

A–

OX

IA –

2008

575757



� WSDL

� UDDI

� BPEL





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.

Exposition

Langage WSDL (Web Service Description Language) utilisé pour décrire le service

Activation

Protocole Web au-dessus de HTTP (RPC XML, SOAP)


SO

A–

OX

IA –

2008

5858

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.

Similaire à IDL mais basé sur XML

Autres protocoles possibles …

ContentsPlan du workshop

� Quels sont les éléments clé d’une architecture orientée services ?


� WSDL

� UDDI

� BPEL

� Besoins d'interopérabilités : WS-I et Basic Profiles


� ESB : un bus au service de SOA



SO

A–

OX

IA –

2008

5959


� Le besoin de supervision dans une architecture SOA

� De nouvelles notions s'ajoutent à SOA: � le BAM

� Le MDM

� La notion de maturité SOA

� La relation entre SOA & EDA

� Les 8 péchés capitaux de la SOA (anti-patterns SOA)

� SOA : 7 bonnes pratiques

SOAP : Simple Object Access Protocol

ProcurationTranslateur

Messages Appel

Port de connexion (URL)

Pare-feu Pare-feu

• Pour accéder services, objets et serveurs

• Indépendant de toute plate-formeIntégration de XML au-

dessus de HTTP :


SO

A–

OX

IA –

2008

6060

Application Cliente

Parseur XML

Procuration

d'interfaceTranslateur

SOAP

Parseur XML Application

Serveur

SOAPAppel

Réponse

HTTP

RPC

local

Structure d'un message

Protocol Headers

SOAP Envelope

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

<Envelope>

<Header>


SO

A–

OX

IA –

2008

6161

SOAP Header

SOAP Body

<Header>

<Body>

XML-RPC et SOAP

SOAP : implémentation

.Net Web Services

Axis 1.x & Axis2

Xfire 1.2.2

SpringWS

WebSphere ...


SO

A–

OX

IA –

2008

6262

WebSphere ...

Plan










SO

A–

OX

IA –

2008

636363



� WSDL

� UDDI

� BPEL





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


SO

A–

OX

IA –

2008

6464

- Grammaire XML (schéma XML ) : Modulaire

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

WSDLÉléments d’une définition

<types>

•Contient les définitions de types utilisant un système de typage (comme XSD).

<message>

•Décrit les noms et types d’un ensemble de champs à transmettre

•Paramètres d’une invocation, valeur du retour, …

<porttype>

•Décrit un ensemble d’opérations. Chaque opération a zéro ou un message en entrée, zéro ou plusieurs messages de sortie ou de fautes


SO

A–

OX

IA –

2008

6565

plusieurs messages de sortie ou de fautes

<binding>

•Spécifie une liaison d’un <porttype> à un protocole concret (SOAP1.1, HTTP1.1, MIME, …). Un <porttype> peut avoir plusieurs liaisons !

<port>

•Spécifie un point d’entrée (endpoint) comme la combinaison d’un <binding> et d’une adresse réseau.

<service>

•Une collection de points d’entrée (endpoint) relatifs.

Contrat dans les web services :Contract -First pour une meilleure interopérabilité

Web Service deux approches


SO

A–

OX

IA –

2008

6666

Contract-Last

créer le code source (classes java ou c#) puis

définir (ou générer) le web service, wsdl, les types …

Contract-First :

créer les types de données, le messages envoyés puis associer le code source

Contrat dans les web services

Privilégier l'approche

contract-first

et Définir vos schéma XML (et gérer vos XSD )

Les clients se


SO

A–

OX

IA –

2008

6767

Définir les interfaces XML des messages

Commencer par les types (XSD) et WSDL

Anticipe les problèmes d'interopérabilités

Les clients se concentrent sur le

message XML

Plan










SO

A–

OX

IA –

2008

686868



� WSDL

� UDDI

� BPEL





UDDI : Annuaire des servicesUniversal Description, Discovery and Integration

Annuaire des services

décrit par un document

WSDL, autre …

Fonctions

Enregistrer votre société

Enregistrer des

Annuaire UDDI

Annuaire UDDI


SO

A–

OX

IA –

2008

69

WSDL, autre …

Accessible en SOAP

Enregistrer des services

Enregistrer des opérations

Découvrir des services

Gérant de requêtes

Enveloppe+Document

Programme

Service

UDDI : utilité d’un annuaire de service


SO

A–

OX

IA –

2008

7070

Scénario classique d'utilisation d'UDDI

UDDI : implémentation

Microsoft, IBM, Oracle ( et aussi BEA )…

open source : jUDDI


SO

A–

OX

IA –

2008

7171

Plan










SO

A–

OX

IA –

2008

727272



� WSDL

� UDDI

� BPEL





Standard de l’OASIS (10+ ans de recherche Microsoft (XLANG) et IBM (WSFL, FDML) )

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

Le langage BPEL Business Process Execution Language


SO

A–

OX

IA –

2008

7373

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

Gestion des erreurs

XML-RPC et SOAP

Gartner believes that BPEL will emerge as the

leading industry standard for Web service

orchestration and coordination of business

processes.

- David Smith, Research Vice President and fellow, Gartner

BPEL is the future of the integration space in my view…Why?

Because the value is so much higher when you provide not only

a way to integrate applications, but also a way to create services

from them and put them into business processes

- John Rymer, Vice President, Forrester Research, Inc.

?

BPEL le chef d’orchestre :créer de nouveaux services par composition de services existants

PORTAL Web Service

Java Service

Biztalk, .Net


SO

A–

OX

IA –

2008

74

?

BPEL

J2EE

Biztalk

ERPSAP, Oracle, etc.

User Tasks

Biztalk, .Net

Plan










SO

A–

OX

IA –

2008

757575



� WSDL

� UDDI

� BPEL





Fournisseur du Service : Serveur

Se conformer aux standards WS-I BP :Privilégier le couplage faible

Consommateur du Service : Client


SO

A–

OX

IA –

2008

7676

Profiles WS-I

Ensemble de spécifications ou standards à des niveaux de versions spécifiques

Directives et conventions pour pouvoir connecter ces spécifications ensemble

Web Services-Interoperability Organization Group (www.ws-i.org)

Profiles: Basic, Attachments et Basic Security


SO

A–

OX

IA –

2008

7777

� SOAP 1.1

� WSDL 1.1

� UDDI 2.0

� XML Schema

� XML 1.0 (Second Edition)

� HTTP 1.1

� SSL 3.0

• Restrictions,• Integration Guidance• Best Practices

Basic

Profile 1.1+ =

WS-I Basic Profile

La WS-I Organisation a été créée pour promouvoir des schémas d’utilisation interopérable des WS

Plus de 200 problèmes d'interopérabilité résolus avec WS-I Basic Profile 1.0

Conventions autour du messaging, description et découverte (discovery)


SO

A–

OX

IA –

2008

7878

Exemple de conditions pour la conformité WS-Basic:

• “Un message doit être arrangé en série avec UTF-8 ou UTF-16”

• “Un message doit être envoyé avec HTTP/1.1 ou HTTP/1.0”

• “Un message ne doit pas contenir d'élément enfant de soap:Envelope après l'élément soap:Body”

• “Le service doit utiliser le code HTTP “500 Internal Server Error” si la réponse est un message SOAP fault”

• “Une description [WSDL] peux utiliser tous les composants de XML Schema 1.0”

� WS-Addressing

� SOAP 1.1

� WSDL 1.1

WS-I Profiles

• WS-S 1.1• SAML

• WS-ReliableMessaging1.1• WS-SecureConv

ReliableSecure

Profiles WS-I


SO

A–

OX

IA –

2008

7979

79

� WSDL 1.1

� UDDI 2.0

� XML Schema

� XML 1.0

� HTTP 1.1

� SSL 3.0 Basic Profile 1.1, 1.2

Basic SecurityProfile 1.1

SecureProfile 1.0

WS-I et Basic Profiles


SO

A–

OX

IA –

2008

8080

WSDL et format des messages

Styles s'applique au mécanisme de traduction d'un binding WSDL

lors de la construction d'un message SOAP

Deux styles d’encodage :


SO

A–

OX

IA –

2008

8181

Format RPC

Structure imposée (nom de méthode contenant

les paramètres)

Format Document

Structure libre (n’importe quel arbre est transporté

dans l’enveloppe)

WSDL et format des messages

Deux styles d’encodage :

Format RPC

Structure imposée (nom de

Format Document

Structure libre (n’importe quel

Avantages et inconvénients :

RPC

Facile à valider : respecte le schéma imposé par SOAP

Document (celui que je recommande

Plus difficile à valider (schéma non vérifiable un niveau SOAP)


SO

A–

OX

IA –

2008

8282

imposée (nom de méthode

contenant les paramètres)

Structure libre (n’importe quel

arbre est transporté dans

l’enveloppe)

imposé par SOAP

Uniquement appel de méthode (nom de

méthode + paramètres)

Optimisations possibles (évite de passer la nom de la méthode par exp)

Passage de messages purs (un arbre)

Bien sûr utilisable pour faire de l’appel de méthode!!!!

Modes des Services Web

Un message SOAP contient des données typées (paramètres des services)

Il faut définir un moyen d’encoder et de décoder ces données

Vocabulaire SOAP :� Value (valeur d’une donnée)

� Simple value (primtifs : string, integers, etc..)

� Compound value (composées à partir des primitifs : array, struct, …)


SO

A–

OX

IA –

2008

8383

� Compound value (composées à partir des primitifs : array, struct, …)

� • Type (d’une value) (Simple Type/Compond type)

� Encodage : représentation de valeurs sous forme XML.

� Décodage : construction de valeurs à partir d’XML

� L’arbre XML représentant des valeurs a une structure qui dépend du type des valeurs…


Deux façon d’encoder les données

Les types sont placés dans le message

(encoding)

Les types sont définis par un schéma via wsdl

(literal)

Avantages et inconvénients

Encoding :Literal (celui que je

recommande) :


SO

A–

OX

IA –

2008

8484

Messages courts

Client et serveur doivent posséder le

schéma pour valider le message

Messages longs

Client ou serveur n’ont pas besoin de connaître le schéma i.e. messages

auto-validants


Style : RPC vs. Document

Encodage : Encoded vs. Literal


SO

A–

OX

IA –

2008

8585


Style : RPC vs. Document

Encodage : Encoded vs. Literal


SO

A–

OX

IA –

2008

8686

SOAP Fault

Balise permettant de signaler

des cas d’erreur.

La balise Fault contient les balises suivantes

faultcode : un code permettant d’identifier le type d’erreur

• Client, Server, VersionMismatch, MustUnderstand


SO

A–

OX

IA –

2008

8787

faultstring : une explication en langage naturel

faultactor : une information identifiant l’initiateur de l’erreur

detail : définition précise de l’erreur.

Conseil pour une meilleur interopérabilitéUtiliser les Schémas XML

Utiliser l’approche Contract-First

• garantit une interopérabilité dès la conception• garantit une interopérabilité dès la conception

Toujours utiliser des schémas XML

• Obligatoire pour les WS Document/Literal• Obligatoire pour les WS Document/Literal

Tout type de message défini dans le WSDL devrait être défini dans un Schéma

• – Messages In/Out des opérations• – Messages In/Out des opérations


SO

A–

OX

IA –

2008

8888

• – Messages In/Out des opérations

• – Fautes

Découple la sémantique de la signature des WS

• – Les opérations peuvent être stables au cours du temps• – Les opérations peuvent être stables au cours du temps

• – Seuls les schémas évoluent

Créer votre grammaire propre via XML Schema (s'inspirer de GS1, ebXML, …), fixer les espaces de nomages

Possibilité d'utiliser les framework de mapping objet/XML (JAXB, …)

Penser à concevoir des services web asynchrones

Selon les uses cases, identifier les besoins aux web service asynchrone

• Les WS asynchrones sont adaptés aux processus longs et • Les WS asynchrones sont adaptés aux processus longs et coûteux

Les meilleurs résultats sont obtenus en les


SO

A–

OX

IA –

2008

8989

Les meilleurs résultats sont obtenus en les couplant avec des MOM (JMS en Java EE)

Penser à mettre en place un mécanisme de notification

SOA-plateofrme

CRM SMS/MMS

PolicyEngine

AccessControl

applicationManagement

notification

Portal

PortletContent Personal

WSDL Java

Monitoring

consumers

SOA Plate

ApplicationsApplicationsApplicationsIVR USSD Xpert

.Net

Exemple de projet réalisé dans le monde des télecomTunisiana (Tunisie) & Nedjma (Algérie) : approche contract First


SO

A–

OX

IA –

2008

9090

Application Server

BSCS IN

KHAS© (OXIA-Service-Framework)

CMS

Engine Control Management

VoMS / VAD DMC

Service

s provid

ers

SOA Plate-fo

rm

JavaSQLCORBA

ApplicationsApplicationsApplications

Plan










SO

A–

OX

IA –

2008

919191



� WSDL

� UDDI

� BPEL





Besoin d'infrastructure ?


SO

A–

OX

IA –

2008

9292

Standards Importants pour SOA

ERP/Legacy Apps

Custom Apps

Portal

Web ApplicationSecurityReliability


SO

A–

OX

IA –

2008

93

WSDL/WSIF

XML/XML Schema

SOAP JCA JMS

BUSINESS SERVICES

XSLT/XQuery

BPEL

ORCHESTRATE

PORTAL JSR-168

INTERACT/ACCESS

Struts/JSF

WS-Security

GATEWAY

WS-Policy, SAML

Web Services Mgmt

BAM

MONITOR & OPTIMIZE

JMX

SCA

Custom Apps& Services

Web services

Process FlowLogic

Web Application

API

WS

ReliabilityLoggingFailoverDynamic Routing

MonitoringOptimization

Besoin d'infrastructure ?

BPELEngine

Business Rules

Human Workflow

BPEL Process

ROUTING & ORCHESTRATION

Management

Web Services Manager

GOVERNANCEEvents AnalyticsBusinessMonitoring

System Monitoring

Enterprise Manager

BAM BIBI

MANAGEMENT&

MONITORING

Framework

EclipseV.S.

IDE

Rules


SO

A–

OX

IA –

2008

94

Application Server

J2EE / Windows .Net

ActiveMQ, Mqseries, MSMQ

MOM

DATA SERVICES & CONNECTIVITY

Apps

Adapters

Partners

B2B

Partners

B2B

DB

D I

ETL

Multi Protocol

RoutingXSLT

Transform

Enterprise Service Bus (ESB)

DiscoveryPolicies

Security

Registry

App DevFramework

ContentsPlan du workshop

� Quels sont les éléments clé d’une architecture orientée services ?


� WSDL

� UDDI

� BPEL

� Besoins d'interopérabilités : WS-I et Basic Profiles




SO

A–

OX

IA –

2008

9595



� Le besoin de supervision dans une architecture SOA

� De nouvelles notions s'ajoutent à SOA: � le BAM

� Le MDM

� La notion de maturité SOA

� La relation entre SOA & EDA

� Les 8 péchés capitaux de la SOA (anti-patterns SOA)

� SOA : 7 bonnes pratiques

ESB (Enterprise Service Bus)infrastructure SOA au service de l’interopérabilité

Middleware d’intégration fournissant des fonctionnalités comme

l’acheminement

le routage des messages,


SO

A–

OX

IA –

2008

9696

la connexion des applications/progiciels (via des adaptateurs dédiés ou des technologies standards – services web,..),

la transformation des données,

et au-delà l’ensemble des médiations nécessaires aux échanges dynamiques entre consommateurs et fournisseurs de services

L'ESB (bus de service d’entreprise) :composant d’infrastructure central d’une SOA

Le but d’un ESB est de permettre de communiquer de manière simple et standardisée entre des applications hétérogènes

Services de médiation

• Acheminement

• Transformation

Services d’événement


SO

A–

OX

IA –

2008

97

• Publier et abonner

Services de transport

• Synchrone / asynchrone

• Constant / non constant

• Couplage lâche / couplage étroit

Axé sur les normes

• HTTP/HTTPS avec possibilité de messagerie fiable SW

• MOM, JMS, JAX-RPC, SOAP

• Sécurité Web, politique Web, adressage WebC’est le point d’entrée vers un

service

ESB une maturité croissante de l’offre

Plate-forme d’intégration

IBM Websphere Process Server

Microsoft Biztalk

ESB

Microsoft Biztalk

IBM Websphere ESB

Infrastructure qui optimise les échanges entre consommateurs et fournisseurs de services

Standards


SO

A–

OX

IA –

2008

9898

BEA Weblogic Acqualogic

Oracle fusion

SAP “Netweaver”

Mule

Sonic ESB

Petals de ObjectWeb

OpenESB (Sun)

serviceMix

Plan










SO

A–

OX

IA –

2008

999999



� WSDL

� UDDI

� BPEL





SLA : Service Level Agreement

Une architecture orientée service (SOA) repose sur la définition et la publication de services

Définit de manière explicite l’interface du service sans préjuger de la technologie utilisée par le consommateur ni de l’implémentation de ce service par le fournisseur

Imposer l’interopérabilité dans le SLA


SO

A–

OX

IA –

2008

100100

Les contrats de services définissent les exigences opérationnelles d’exploitation des services exposés

Producteurs et consommateurs définissent de objectifs de niveaux de services (SLO)

•Par exemple:

•Temps de réponse <2s

•Disponibilité de 99,9%

•Trafic maximum de 100 requêtes/h

Un engagement de services (SLA) est défini par

•Le ou les consommateurs pour lesquels il s’applique


SO

A–

OX

IA –

2008

101101

•Le ou les consommateurs pour lesquels il s’applique

•Le ou les services sur lesquels il s’applique

•Un ensemble de SLO

•La période de temps sur laquelle il s’applique

Des indicateurs de performances (KPI) seront utilisés pour gérer la qualité du service rendu

•Ils sont associé à un services

•Ils correspondent à un critère de finalité ou de performance du service

• Ils peuvent être mesurés de façon quantitative ou qualitative, afin d’être comparés au résultat attendu.

•Leur étude doit permettre l’optimisation de la qualité de service.

Plan










SO

A–

OX

IA –

2008

102102102



� WSDL

� UDDI

� BPEL





Inter-opérabilité & SOA

Méta-information

Architecture

Services d'infrastructure

réutilisables

Services métier technologiques

Services métier

Services métier réutilisables


SO

A–

OX

IA –

2008

103103

InteropérabilitéArchitecture

orientée services

Services métier

Modélisation métier

Bon niveau d'isolation vis-à-

vis des API

Gestion des versions

Protocole de communication à

faible couplage

Best Practices : SOA & interopérabilité

Gestion du portefeuille de

service

Cadre Commun d’interopérabilité

Modèle de maturité : Benchmarking


SO

A–

OX

IA –

2008

104104

Orchestration de Processus,

Workflow et Règles métiers

l'Industrialisation du développement des

logiciels

Sécurité et gestion

montée en charge à la demande

gérer le portefeuille de services

Bonnes pratiques

Contract- First & Interface-First

Documents à gros Grain

Interactions Asynchrones


SO

A–

OX

IA –

2008

105105

Opérations d'annulation (Undo/Cancel)

Versioning

WS-I, Wrapped Document Style

Penser à SCA

Cadre Commun d’interopérabilité :Connectivité et Message


SO

A–

OX

IA –

2008

106106

Orchestrer les processus

Bonnes pratiques

BPEL & BPMN

XSLT Transformation

Service Workflow humain

Service Moteur de règles


SO

A–

OX

IA –

2008

107107

Service de Notification

Service de gestion des Erreurs

Lien vers l'ESB

Trace et débogage

Développement Itératif

Test Unitaire

Etablir une politique de sécurité

Bonnes pratiques

WS-Policy, WS-Security


SO

A–

OX

IA –

2008

108108

Capacité à changer la politique de sécurité sans changer les services

Intégration avec un ESB (Multi-bindingSupport)

IndustrialiserAvant l'Industrialisation du développement des logiciels

Activité du développeur

Concevoir le contrat & service

Coder l’interface du contrat

Coder le contrat des classes

Coder le « Endpoint » du service

Coder la configuration


SO

A–

OX

IA –

2008

109

109

Coder la configuration

Industrialiser Après l'Industrialisation du développement des logiciels

Cadre commun d’interopérabilité

Cadres architecturaux

Encadrement en

contexteUsine logicielle


SO

A–

OX

IA –

2008

110

110

Développement selon un modèle

Générer le contrat & service

Générer l’interface du contrat

Générer le contrat des classes

Générer le « Endpoint » du service

Générer la configuration

montée en charge à la demande

Bonnes pratiques

Prévoir des Interactions Asynchrones

Traiter judicieusement le cas des documents XML de grande taille


SO

A–

OX

IA –

2008

111111

“Stateless Architecture”

JCA and Java Binding

Prévoir le mode Batch (API batch)

Réaliser des “POC performance” pour valider tous les choix techniques

Pourquoi un modèle de maturité: Benchmarking

Pour se positionner dans le chemin

d'adoption d'une démarche SOA

Where do you

Pour planifier les étapes à suivre pour améliorer la maturité

de la pratique SOA

Définir une vision SOA

Ressources


SO

A–

OX

IA –

2008

112112

Where do youwant to go?

Objectifs

Pratiques

Ressources requises

Gains obtenus

(ROI)

Technology OrganizationStandards Process

BAM, SCAWS-* Standards

BAM ToolEPM Standard

Dashboard

BusinessServiceDepts

CapacityPlanning,

Ent. Ref. Arch.

BP ModelingStandards

Bus. ProcessModeling Tools

ContinuousImprovement

SOAOrganizational

Structure

The Hartford’s SOA Maturity Model

4

5


SO

A–

OX

IA –

2008

113113

WSDL,UDDI Standards

JMS

EA Dept.,Tech. Service Dept.

App. Ref.Architecture

Web Services

Governance,Operational Model

SOM, UDDIRegistry, Rules ,Message Bus

SOA BestPractices,

Int. Ref. Arch

BPEL, BPMNWS-Security,

JSR 168

EnterpriseSOA Education

SOAP, XMLArchitect’sCollective

BPEL Engine, Portal/Portlets

RO

IM

atur

ityA

utom

ated

Too

ls

Question : Where we are ?

1

2

3

Modèle de référence de SOA de l’OASIS :des sujets de recherche, toujours d’actualité


SO

A–

OX

IA –

2008

114

Source : Norme du modèle de référence de SOA de l’OASIS, 12 octobre 2006

La suite …

SaaS(Software

as a Service


SO

A–

OX

IA –

2008

115115

as a Service

11 rue Claude Bernard1002 Le BelvédèreTunis, TunisiaTél : +216 71 28 27 00

Khaled BEN DRISSDirecteur TechniqueTel : +216 71 28 27 00Mob.: +216 25 23 45 30

Tél : +216 71 28 27 00Fax : +216 71 28 27 05

www.oxiasoft.com

Mob.: +216 25 23 45 30

[email protected]

L’organisation du SI en couches & Urbanisation une couche service à inventer

Description du métier compréhensible

par les acteurs du métier

Description et structuration

fonctionnelle du système

d’information

Métier

Fonctionnelle

Services métiersDéfinition de services contractualisés

(contrat de Services)


SO

A–

OX

IA –

2008

117117

Description et structuration du système

informatique en composants logiciels

(Implémentation des Services)

Infrastructure de fonctionnement du

système d'information et des

composants logiciels et applicatifs

Applicative

Technique

:: : : : :

Exemple d’une représentation adaptée : source CIGREF

Services métiers(contrat de Services)