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

Khaled BEN DRISS

Khaled.bendriss@oxiasoft.com

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)

khaled.bendriss@oxiasoft.comWIA: SOA pour une interopérabilité intrinsèque du SI khaled.bendriss@oxiasoft.comTunisie -Tozeur – 25/11/2008

IA –

� 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

IA –

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

IA –

� 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

IA –

Mainframe

Terminal

1990Informatique personnelle

Transactionnel

Travail coopératif

Activités

IA –

Batchs

Industrialisation

Informationà la place de travail

Services offerts

IA –

Automatisation des processus administratifs

Gestion intégrée

Enjeux

Vivant

Objectif

IA –

1980Mécanique

Cahier des charges

Objectif

Prévisible

Réactif

Besoin d’automatisation

IA –

Marché

Business Model

• Mondialisation

• Actionnaires

• Fusion/acquisition

• Publicité

Contexte économique

IA –

Business Model

Eco-système

• Open source

• Compétition

MainframeMainframeClient/ServerClient/Server

réseauxréseaux

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

IA –

InternetInternetet Webet Web

Net-Progress

ServeurInternet

Architectures informatiquesTypes et contraintes

IA –

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

IA –

Services de données

Services d'entreprise

Services de données

Servicesd'entreprise

Interface utilisateurServices d'entrepriseServices de données

Contextearchitectures informatiques

IA –

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

IA –

141414

� WSDL

� UDDI

� BPEL

Objectifs des S.I.récapitulatif.

IA –

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

IA –

Division ADivision B Division C

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

IA –

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)

IA –

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é

IA –

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

IA –

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)

IA –

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

IA –

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

Développements coûteux

Interconnexions redondantes

(point à point)

Grande Maintenance

IA –

Grande complexité

Maintenance difficile

IA –

242424

� WSDL

� UDDI

� BPEL

Interopérabilité : différents points de vue

IA –

Interopérabilité : différents points de vue

métier

Responsable IT

Indépendance , intégration

IA –

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.

IA –

On a besoin d’une nouvelle approche !

IA –

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

IA –

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)

IA –

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

SOA est une évolution des plateformes passées,

tout en préservant les

IA –

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.

IA –

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

IA –

Service Oriented Architecture :une architecture Consommateur/Fournisseur

Courtier de Services

Consommateurs

De Service

Fournisseurs

de Services

IA –

Annuaire

MonitoringSLASécuritéTransformation

IA –

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

IA –

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

IA –

• 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

IA –

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

IA –

� 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

IA –

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

Un Service est Autonome

4 propriétés du service à retenir

IA –

Les services communiquent par messages

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

IA –

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

IA –

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

IA –

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

IA –

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

IA –

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)

IA –

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

IA –

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

Penser réutilisation

Penser métier

Penser interopérabilité & standards

IA –

515151

� WSDL

� UDDI

� BPEL

Implémentations des Services

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

IA –

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

IA –

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

IA –

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

IA –

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

Standards de l’architecture WS

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

SOAP UDDIWSDL BPEL

IA –

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

IA –

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)

IA –

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

IA –

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

IA –

Application Cliente

Parseur XML

Procuration

d'interfaceTranslateur

Parseur XML Application

Serveur

SOAPAppel

Réponse

Structure d'un message

Protocol Headers

SOAP Envelope

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

IA –

SOAP Header

SOAP Body

<Body>

XML-RPC et SOAP

SOAP : implémentation

.Net Web Services

Axis 1.x & Axis2

Xfire 1.2.2

SpringWS

WebSphere ...

IA –

WebSphere ...

IA –

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

IA –

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

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

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

•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

IA –

plusieurs messages de sortie ou de fautes

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

•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

IA –

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

IA –

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

IA –

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

IA –

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

IA –

Scénario classique d'utilisation d'UDDI

UDDI : implémentation

Microsoft, IBM, Oracle ( et aussi BEA )…

open source : jUDDI

IA –

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

IA –

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

IA –

Biztalk

ERPSAP, Oracle, etc.

User Tasks

Biztalk, .Net

IA –

757575

� WSDL

� UDDI

� BPEL

Fournisseur du Service : Serveur

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

Consommateur du Service : Client

IA –

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

IA –

� 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

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)

IA –

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

IA –

� 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

IA –

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 :

IA –

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 :

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)

IA –

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, …)

IA –

� 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) :

IA –

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

IA –

Style : RPC vs. Document

Encodage : Encoded vs. Literal

IA –

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

IA –

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

IA –

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

IA –

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

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

IA –

Application Server

BSCS IN

Engine Control Management

VoMS / VAD DMC

Service

s provid

SOA Plate-fo

JavaSQLCORBA

ApplicationsApplicationsApplications

IA –

919191

� WSDL

� UDDI

� BPEL

Besoin d'infrastructure ?

IA –

Standards Importants pour SOA

ERP/Legacy Apps

Custom Apps

Portal

Web ApplicationSecurityReliability

IA –

WSDL/WSIF

XML/XML Schema

SOAP JCA JMS

BUSINESS SERVICES

XSLT/XQuery

ORCHESTRATE

PORTAL JSR-168

INTERACT/ACCESS

Struts/JSF

WS-Security

GATEWAY

WS-Policy, SAML

Web Services Mgmt

MONITOR & OPTIMIZE

Custom Apps& Services

Web services

Process FlowLogic

Web Application

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.

IA –

Application Server

J2EE / Windows .Net

ActiveMQ, Mqseries, MSMQ

DATA SERVICES & CONNECTIVITY

Adapters

Partners

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

IA –

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

IA –

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

IA –

• 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

IBM Websphere ESB

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

Standards

IA –

BEA Weblogic Acqualogic

Oracle fusion

SAP “Netweaver”

Sonic ESB

Petals de ObjectWeb

OpenESB (Sun)

serviceMix

IA –

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

IA –

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

IA –

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.

IA –

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

IA –

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

IA –

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

IA –

105105

Opérations d'annulation (Undo/Cancel)

Versioning

WS-I, Wrapped Document Style

Penser à SCA

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

IA –

106106

Orchestrer les processus

Bonnes pratiques

BPEL & BPMN

XSLT Transformation

Service Workflow humain

Service Moteur de règles

IA –

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

IA –

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

IA –

Coder la configuration

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

Cadre commun d’interopérabilité

Cadres architecturaux

Encadrement en

contexteUsine logicielle

IA –

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

IA –

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

IA –

112112

Where do youwant to go?

Objectifs

Pratiques

Ressources requises

Gains obtenus

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

IA –

113113

WSDL,UDDI Standards

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

Question : Where we are ?

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

IA –

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

La suite …

SaaS(Software

as a Service

IA –

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

khaled.bendriss@oxiasoft.com

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)

IA –

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)

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

Business

Spin Moment angulaire intrinsèque: propriété purement quantique d’une particule

Normes, standards et interopérabilité pour les environnements … › documents › ENA_et_Normes.pdf · 2007-09-27 · Normes, standards et interopérabilité pour les environnements

Modélisation et interopérabilité : Semaine 43, cours 6 · 1 Modélisation et interopérabilité : Semaine 43, cours 6 Benoît Valiron

Webinar Conceptos SOA & Oracle SOA Suite

3 - Interopérabilité des systèmes d’information de santé

MESSAGE DRIVEN DISTRIBUTED SYSTEMS M ESSAGE – D RIVEN SOA? M ESSAGE – D RIVEN SOA? M ESSAGE – D RIVEN SOA? M ESSAGE – D RIVEN SOA? M ESSAGE – D RIVEN SOA?

To SOA or not to SOA

Oracle SOA Suite 11g - Oracle | Integrated Cloud ... White Paper—Oracle SOA Suite 11g Oracle SOA Suite 11g - 市場をリードするSOA プラットフォーム 3 SOA でのOracle

Symétrique de l’ Interopérabilité PHP .NET

1 Programmation Approche composants Ing5 SI. 2 Plan du module Approche composants et interopérabilité des SI sur.net. Approche composants et interopérabilité

Sécurité, sûreté et interopérabilité Safety, security and

SOA Gerando Valor e Como Vender SOA na Crise

Un semiconducteur non dopé est dit intrinsèque

Interopérabilité et échanges de données pour les archives

Évolutivité, interopérabilité, flexibilité, efficacité · interopérabilité, flexibilité, efficacité ... logicielle évolutive qui offre de multiples possibilités 10 L’environnement

interopérabilité en informatique

Lean SOA Abspecken senkt das Infarktrisiko › vortrag › lean-soa › lean-soa-vortrag.pdf · Lean SOA - Abspecken senkt das Infarktrisiko SOA Manifest Geschäftswert über technische

Interopérabilité cao cad interop 2012

Interopérabilité avec les architectures voix existantes Pascal PLESSISNET

Caractérisation intrinsèque de sources complexes de