Architecture n-tiers: Service-Oriented Architecture (SOA)

Software Engineering · notes

Voir tous les documents en génie logiciel

Architecture n-tiers

Chapitre 2: SOA Dr.Ghada Besbes

1

Introduction

• La création d'applications dans l'entreprise est très souvent

pilotée par des besoins à très court terme

• Développement d'une application sous tel délai avec telles

fonctionnalités

• Modélisation et développement dirigé par les

choix/contraintes techniques • Pas de discussion entre maitrise d'ouvrage (le client) et maitrise

d'oeuvre (l’équipe de développement)‏

• Décalage entre besoins métier et leur réalisation (constituants

informatiques)‏

• Pas de place pour la prise en compte de l'évolution des

besoins fonctionnels au niveau de l'application

2

Introduction

• Le découpage présentation/traitement/base de données de

l'architecture 3-tiers sert à découpler au maximum une couche de l'autre mais favorise le cloisonnement en silos applicatifs indépendants (blocs monolithiques)‏

3

Introduction

• Les tiers communiquent via un protocole de transport spécifique qui nécessite une configuration réseau

• Problématique de l’intégration en entreprise

• Entreprises découpées en départements fonctionnels y compris

leurs systèmes d’information‏

• Processus métiers de + en + interdépartementaux • Les processus qui franchissent les frontières des départements

doivent pouvoir prendre en compte les activités et processus des autres départements.

4

Introduction

 Coûts considérables dans la gestion des flux entre départements

et dans l’intégration de leurs SI

5

Introduction

Plat de spaghettis

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

6

1

SOA

7

SOA

• SOA dénote une architecture orientée services (Service

Oriented Architecture)

• Lancée par Gartner Group, elle définit un modèle d’interaction applicative mettant en oeuvre des connexions en couplage faible entre divers composants logiciels.

• « une vision d’un système destinée à traiter toute application comme un fournisseur de service ».

• Architecture logicielle s'appuyant sur un ensemble de

services simples.

• Objectif: Décomposition d’une fonctionnalité en un ensemble de fonctions basiques, appelées services.

8

SOA

Qu’est ce que SOA?

• «

L’architecture orientée

style d’architecture basée sur le principe de séparation de l’activité métier en une série de services. »

constitue un

service

• « Ces services peuvent être assemblés et liés entre eux selon le principe de couplage lâche pour exécuter l’application désirée. »

• «Ces services sont définis à un niveau supérieur de

la

traditionnelle approche composants »

Gartner - Septembre 2005

9

SOA

• La mise en place d'une architecture SOA répond à un besoin

de: • Réutilisation des traitements, • Interopérabilité • Fiabilité, • Hétérogénéité.

• Une architecture orientée services consiste essentiellement

en une collection de services qui interagissent et communiquent entre eux.

10

SOA

• Le paradigme SOA : Chercher, Publier et Consommer

11

SOA

• L’approche à services est un paradigme informatique qui

propose de construire des applications à partir de services. Ces services sont fournis par des organisations tierces et peuvent évoluer dynamiquement .

• Cette approche repose sur trois acteurs (Fournisseur de

service, Annuaire de service et Consommateur de service) et trois interactions (Chercher, Publier et Consommer).

12

SOA

Acteurs • Fournisseur de services:

• Le fournisseur de service a pour rôle de fournir des services qui

implémentent une description de service. Les descriptions de service sont publiées dans un registre de services afin de supporter la découverte de services. • Annuaire/registre de services:

• C’est l’intermédiaire entre les fournisseurs et les consommateurs de services. Il stocke des descriptions de services qui, entre-autres, référencent leurs fournisseurs. Le registre fournit des mécanismes permettant de l’interroger pour obtenir des références vers les fournisseurs.

• Consommateur de services:

• L’acteur consommateur de service est le client qui requiert un

service. Pour pouvoir interagir avec ce dernier, le consommateur doit être lié à un fournisseur après sa découverte dans le registre.

13

SOA

Interactions • La publication : Un fournisseur de service s’enregistre auprès du registre de service pour publier sa description de service. Un fournisseur peut avoir plusieurs types de services. • Recherche/découverte : Le consommateur de service

interroge le registre afin de trouver les services qu’il requiert. • Consommation/invocation et liaison : Une fois que le service est découvert, son invocation consiste à établir une liaison entre le consommateur et le fournisseur pour permettre son utilisation.

14

SOA

15

Un service Web

• Le service est un composant clef de l'Architecture Orientée

Services.

• Consiste en une fonction ou fonctionnalité bien définie. • Expose une interface qui définit le traitement offert sous la forme d’un message d’entrée et d’un autre de réponse.

Publicité

• L’avantage essentiel des services web concerne le fait que le client

consommateur n’a pas besoin de connaître l’identité du fournisseur du service

• Le client doit simplement exprimer son besoin • Face à un besoin, plusieurs fournisseurs de services peuvent exister • Chacun ayant des caractéristiques de coût, de performance, de

fiabilité, etc.

• Le client choisit le fournisseur (i.e. le service) correspondant le

16

mieux à ses besoins.

Un service Web

Les services • Ils sont accessibles via le web par des protocoles bien connus • Ils interagissent via XML • Ils sont localisables à partir de registres • Ils sont entièrement transversaux aux plates-formes et très

faiblement couplés

• Un service résout un problème donné, • Les services peuvent être combinés pour résoudre des

problèmes de plus en plus complexes,

Une architecture orientée services se focalise sur une décomposition plus abstraite dans la résolution des problèmes. On parle de résolution dirigée par les services.

17

Un service Web

• Partage les caractéristiques suivantes d’un objet

• Modulaire (ensemble de fonctionnalités qui font sens)‏

• Partage les caractéristiques suivantes d’un composant

• Boite noire (séparation interface/implémentation)‏

• Indépendant de la localisation

• Neutralité vis-à-vis des protocoles de transport • Les services Web sont réutilisables indépendamment de:

• la plate-forme (UNIX, Windows,…) • leur implémentation (Java, C++, Visual Basic,…) • l’architecture sous-jacente (.NET, J2EE,…)

18

Propriétés des services

1. Contrat Standardisé • Contrat entre le fournisseur de service et le consommateur de

service

• Trois types de contrat sont à distinguer

1.

2.

3.

Lié à la syntaxe du service (opération, messages d’entrée, messages de sortie, …) Lié à la sémantique du service (définition de règles et de contraintes d’usage, …) Lié à la qualité de service (temps de réponse attendu, procédures en cas de panne, temps de reprise après interruption, …)

Conditions Générales de Vente Règlement Intérieur Vos droits/Vos devoirs

19

in

out

Propriétés des services

2. Couplage faible • Un service ne peut pas appeler un autre service. Il délègue

cette fonction à un traitement spécialisé dans l’enchaînement (fonction d’orchestration).

• L’utilisation d’une orchestration évite que les services aient

besoin de connaître les autres services

Le couplage fort rend difficile la réutilisation et accroît la complexité des systèmes

20

Propriétés des services

 L’orchestration favorise l’indépendance des services et assure que des services n’appellent pas directement d’autres services

21

Propriétés des services

22

Propriétés des services Exemple de couplage fort : Gestion de prêts

Entités

LoanAgent

LoanApproval

Account

Loan

SMSGateway

calculateRisk

checkCredit

createLoan

 LoanAgent est lié à LoanApproval et Loan  LoanApproval est lié à Account  Loan est lié à SMSGateway

sendConfirmation

23

Propriétés des services Gestion de prêts en couplage faible

LoanProcess

CheckAccount Balance

Services

Calculate LoanRisk

CreateLoan

Notify ViaSMS

Qu’est ce que LoanProcess ?

 Un processus métier !

Il permet d’orchestrer les services => couplage faible

24

- 24 -

Propriétés des services

3. Activation à distance et interopérabilité • Un service doit être activable à distance indépendamment de sa

technologie

• L’activation se fait par l’envoi (et la réception) d’un message XML • Le service doit exposer une interface d’utilisation qui est la même

indépendamment de sa localisation sur le réseau

• L’appel au service fonctionne quelque soit le langage et les

système d’exploitation du consommateur (utilisateur du service)

25

Propriétés des services

• L'objet des Services Web est la communication d'application à

application (A2A) sur Internet.

• Le but est de faciliter l’intégration des applications d'entreprise et le

e-commerce spécialement en "Business To Business" (B2B). • Pour ce faire, l'architecture des Services Web doit supporter les transactions asynchrones ("mode message") aussi bien que les transactions synchrones ("Remote Procedure Call" ou RPC),

• Le codage des données est effectué en XML, ce qui conduit à des

documents que l'homme et la machine peuvent interpréter

• Les systèmes doivent être interopérables.

26

Propriétés des services

4. Abstraction • Fonctionnement du service dit en « boîte noire »

• Seul le contrat exposé au consommateur du service est connue • Le fonctionnement interne du service ne doit pas être

visible(logique métier et implémentation)

• Il est par conséquent important d’assurer la prédictibilité d’un

service: Pas de variation dans le comportement et dans la réponse d’un service lors de la réception d’une requête

Publicité

27

Propriétés des services

5. Découvrabilité • Un service doit être accessible depuis un entrepôt ou un

annuaire pour faciliter sa découverte

• Le fournisseur de services a la charge de déposer et de mettre

à jour ses services depuis l’annuaire

• Le service est enrichi par un ensemble de méta-données pour

faciliter la recherche du consommateur de services

28

Propriétés des services

6. Autonomie • Un service doit disposer de l’ensembles des informations

nécessaires à son exécution

• Ne doit dépendre d’aucun service externe (couplage faible) • Garantir l’autonomie d’un service permet de s’assurer de sa

prédictibilité

29

Synthèse

Depuis…

…Vers…

• Orienté fonctionnalités • Conçu pour durer • Cycle de

développement long

• Orienté processus • Conçu pour changer • Développement et

déploiement interactif

• Silos applicatifs • Couplage fort • Orienté Objet

• Orchestration de

Services

• Couplage faible • Orienté message

30

Avantages

 Architecture adaptative  Réutilisation du code (Construire les services une seule fois et

les utiliser fréquemment)

 Améliorer l’agilité et la flexibilité du métier  Faciliter la maintenabilité  Faciliter la gestion des processus métier  Offrir la capacité à casser les barrières organisationnelles

(silos)

 Réduire en temps le cycle de développement des produits  Réduire la complexité de la solution  Garantir une intégration standardisée et le support de clients

hétérogènes

 L’évolutivité, permettant aux applications de greffer de

nouveaux modules afin de répondre aux nouveaux besoins fonctionnels

31

Limitations

 Manque de maturité des standards  Lenteur d’exécution  Difficile à effectivement implémenter  Les contraintes imposées dans la contractualisation

32

2

STANDARDS DES SOA

33

Standards des SOA

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

l’interopérabilité

SOAP W3C Simple Object Access Protocol

WSDL W3C Web Services Description Language

UDDI Microsoft, IBM, HP Universal Description Discovery and Integration

Transport

Décrit le contrat

Annuaire

34

Standards des SOA

• UDDI : Universal Desciption, Discovery and Integration peut être vu

comme les pages blanches (ou jaunes) des services web. • C'est un annuaire permettant à des fournisseurs de présenter leurs

services à des 'clients'.

• WSDL : Web Service Description Langage est un langage reposant

sur XML dont on se sert pour décrire les services web. • Il est indispensable à UDDI pour permettre aux clients de trouver les

méthodes leur permettant d'invoquer les services web.

• SOAP : Simple Object Access Protocol est un protocole basé sur XML et qui définit les mécanismes d'échanges d'information entre les clients et les fournisseurs de service web. • Les messages SOAP sont susceptibles d'être transportés en HTTP,

FTP...

35

Standards des SOA

De nombreuses normes sont utilisés dans cette architecture : • "SOAP" pour l'échange de messages • "XML" langage de base pour décrire tous les documents sur lesquels

les messages sont construits

• "HTTP" pour transporter les messages, "WSDL" pour décrire les

services

• "UDDI" pour les publier. • L’approche "Services Web" constitue un changement fondamental

dans la manière de concevoir et réaliser les applications informatiques et de programmer les ordinateurs.

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

l’interopérabilité

36

Fonctionnement d’un web service

37

Standards des SOA: SOAP

• SOAP (Simple Object Access Protocol)

• Un protocole standard de communication. • C'est l'épine dorsale du système d'interopérabilité. SOAP est un

protocole décrit en XML.

• Il se présente comme une enveloppe pouvant être signée et

pouvant contenir des données ou des pièces jointes.

38

Standards des SOA:WSDL

• WSDL (Web Services Description Language)

• Un langage de description standard. • C'est l'interface présentée aux utilisateurs. • Décrit les interface des services • Il indique comment utiliser le service Web et comment interagir

avec lui.

• WSDL est basé sur XML et permet de décrire de façon précise les détails concernant le service Web tels que les protocoles, les ports utilisés, les opérations pouvant être effectuées, les formats des messages d'entrée et de sortie et les exceptions pouvant être envoyées.

39

Standards des SOA:UDDI

• UDDI (Universal Description, Discovery and Integration)

• Un standard pour la publication et la découverte des informations

sur les services Web

• Il fournit l'infrastructure de base pour la publication et la

découverte des services Web.

• UDDI permet aux fournisseurs de présenter leurs services Web

Publicité

aux clients.

• Afin d’être découvert, un service doit être publié

40

Fonctionnement d’un web service

41

Fonctionnement d’un web service

Le scenario complet 1. Définition, description du service • On doit décrire d’un point de vue informatique ce que fait le service,

la solution qu’il propose, ...

• La définition est faite en WSDL au sein du fournisseur de services

(i.e. le serveur d’applications)

Publication du service

2. • Une fois le service définit et décrit en termes de mise en œuvre, il

peut être déclaré dans un annuaire, on parle alors de publication du service afin de le rendre accessible aux clients.

• La publication sera effectuée au sein d’un annuaire dédié UDDI. 3. Recherche du service • Le client se connecte sur un annuaire (UDDI) pour effectuer une

recherche de service.

42

Fonctionnement d’un web service

6. Enregistrement au service web • Une fois le service trouvé par le client, ce dernier doit

s’enregistrer auprès du fournisseur associé au service. Cet enregistrement indique au fournisseur l’intention du client d’utiliser le service suivant les conditions décrites dans la publication.

7. Mise en œuvre du service • Le client peut invoquer le service suivant les conditions

inscrites au sein de l’annuaire lors de la publication du service web (étape 2)

43

2

ORCHESTRATION

44

Introduction

• Les Services Web sont la nouvelle vague des applications web. Ce

sont des applications modulaires, auto-contenues et auto- descriptives qui peuvent être publiées, localisées et invoquées depuis le web. Les services web effectuent des actions allant de simples requêtes à des processus métiers complexes. Une fois qu’un service web est déployé, d’autres applications (y compris des services web) peuvent le découvrir et l’invoquer.

• Une plate-forme d'orchestration s'avère nécessaire pour chaîner l’appel à plusieurs services. La solution serait d’orchestrer les services web simplement en les combinant suivant certaines spécifications afin d’assurer leurs bonnes exécutions.

45

Problématique

• Des processus business de plus en plus complexes

• Plusieurs applications

• Exécution en parallèle

• Partenaires multiples

• Faisant intervenir des systèmes différents

• J2EE/.NET

• Besoin d’évolution

• Changement de partenaires

• Changement de processus

46

Définition

• Le mot « orchestration » est pris du contexte de la symphonie

musicale où les différents instruments musicaux devraient

travailler ensemble en harmonie.

• L’orchestration revient à faire correspondre à chaque

processus métier un ensemble de scénarios d'enchaînement

de services Web, en fonction de la logique applicative à

mettre en œuvre tout en assurant:

• La succession des tâches

• Le contrôle de la bonne exécution

• Les reprises en cas d’incident…

47

Définition

• Un processus métier décrit des interactions entre des agents

(personnes, services, organisations) et des systèmes d’information (logiciels, sous-systèmes). Les différentes entités qui interagissent dans un processus donné sont les participants de ce processus. Le processus métier est déterminé par un objectif précis : produire une facture d’achat de fournitures, éditer un catalogue électronique, etc.

• Un processus métier, dans le domaine des services web :

• Repose sur la coopération entre applications participantes

• Peut être de courte ou de longue durée

• Peut échouer partiellement et déclencher des situations

48

d’exception

Fonctionnalités

• Orchestrer: Invoquer, contrôler et coordonner un ensemble

d’activités afin d’en restituer une liste ordonnée d’appels de services web.

• Correspondre à chaque processus métier un ensemble de scénarios

d’enchaînement de services Web

• Prendre en charge l’assemblage des services, la conservation des enchaînement des services web découverts, leur synchronisation

• Processus intra entreprise : • Processus inter services • Processus inter systèmes • Etc.…

• Processus inter entreprise : • Relations fournisseurs • Grande distribution • Administrations • Etc.…

49

Exemple

50

Avantages

• Interopérabilité • Séparer la logique processus de la logique application

• Applications Business changent très peu • Possibilité de changer le processus sans impact sur les

applications

• Agilité de l’entreprise

• Présenter le processus comme un service

• Invisible pour l’utilisateur

• Gestion de la sécurité

51

Conclusion

• Les outils d'orchestration agissent comme des tours de contrôle qui

appellent successivement différents services Web selon un scénario

donné.

• Les outils de développement de scénario et d'orchestration sont

donc indissociables pour le moment.

• La mise en oeuvre, l'exécution et la gestion de la logique

d'orchestration se révèlent complexes et impliquent un ensemble de besoin en terme d'infrastructure

52