SOA : Architecture Logique

Principes, structures et bonnes pratiques

Gilbert RAYMOND, consultant SOA

gilbert.raymond@softeam.fr

Version 1.0 fvrier 2007 copyright SOFTEAM 2007, www.softeam.fr Relecteur : Alain Delfin, consultant Softeam.

www.softeam.fr

SOA : Architecture Logique. V1.0

fvrier 2007

Page 1 sur 30

Table des matires Introduction ............................................................................................................................................. 3 Principes et motivation............................................................................................................................ 4 Les lments de base de larchitecture .................................................................................................... 6 Composant de service ......................................................................................................................... 6 Bus dentreprise .................................................................................................................................. 7 Contrat de service................................................................................................................................ 7 Donnes dchanges et donnes persistantes ...................................................................................... 9 Typologie et modle en couches logiques............................................................................................. 11 Composant Entit.............................................................................................................................. 13 SOA et Processus .............................................................................................................................. 14 Composant Processus........................................................................................................................ 15 Composant Fonction ......................................................................................................................... 16 Composant Utilitaire et public .......................................................................................................... 17 Composant Prsentation.................................................................................................................... 17 Dmarche et identification .................................................................................................................... 18 Dmarche orient processus.............................................................................................................. 18 Dmarche oriente donne................................................................................................................ 19 Dmarche oriente application.......................................................................................................... 20 Gestion des versions.......................................................................................................................... 20 Spcification tendue et tests ............................................................................................................ 21 Cartographie et modles........................................................................................................................ 23 Cartographie des services.................................................................................................................. 23 Structure gnrale du systme........................................................................................................... 23 Dpendance dinterfaces ................................................................................................................... 24 Structuration du SI et application.......................................................................................................... 25 Application composite ...................................................................................................................... 25 Visibilit et structuration du SI ......................................................................................................... 26 SEA (Service Enterprise Architecture) ................................................................................................. 27 Glossaire................................................................................................................................................ 28

www.softeam.fr

SOA : Architecture Logique. V1.0

fvrier 2007

Page 2 sur 30

Introduction
En quelques annes, larchitecture oriente service (SOA) est devenue un thme majeur pour les systmes dinformation dentreprise. Plus quune nouvelle technologie ou mthode, cest la convergence de plusieurs approches existantes, et lmergence dune forte adhsion des directions informatique et mtier un mme objectif : une meilleure agilit des systmes face aux transformations ncessaires.
Approches Approches Orientes Objets Orientes Objets

Approche par Approche par Composant Composant (Herzum & Sims) (Herzum & Sims)

Distribution Distribution (Corba, DCOM) (Corba, DCOM)

changes orient changes orient document (XML) document (XML)

EAI EAI

BPM BPM

Urbanisation, Urbanisation, cartographie cartographie

SOA

Web services Web services

Figure 1 - SOA : la convergence de solutions

Cependant, il ne sagit pas dune simple juxtaposition de techniques disparates. SOA intgre ces diffrentes pratiques dans un cadre organis : larchitecture des systmes, fortement guide par le mtier. En effet, les expriences prcdentes ont montr que les constructions trop focalises sur une approche unique ou guides par la technique nont pas apport de rponses satisfaisantes. Dans cette optique, larchitecture logique occupe une place centrale. Instrument privilgi pour la construction et la maintenance du systme, pivot sur lequel sarticulent le mtier et sa traduction logicielle, elle constitue la rfrence pour lorganisation des projets, la construction technique et le plan de progression. Toutefois, larchitecture logique nest pas un modle abstrait, ni une cartographie fonctionnelle cible lointaine. Il sagit plus pragmatiquement de la description des constituants du systme et de leurs relations. Ce document prsente larchitecture logique dans le cadre de notre approche SEA (Service Entreprise Architecture).

www.softeam.fr

SOA : Architecture Logique. V1.0

fvrier 2007

Page 3 sur 30

Principes et motivation
SOA (Service Oriented Architecture) est un style darchitecture organis partir de services mtiers communs mutualiss pour un ensemble de lignes mtiers ou dapplications.
SOA is an approach to designing software that dissolves business applications into separate services that can be used independent of the applications of which theyre a part and computing platforms on which they run.
Jay DiMare, IBM Global Services, 2006

La motivation fondamentale vient du constat suivant : Le cloisonnement en silos applicatifs indpendants (blocs monolithiques) est une des sources majeures des difficults rencontres pour le traitement des volutions et la maintenance des systmes.

Figure 2 - Architecture oriente application vs architecture oriente service

A la recherche de lagilit. Cette notion nest pas nouvelle: Les Systmes dInformation sont en constante volution et les obstacles rencontrs sont largement dbattus depuis des annes, mais ces questions acquirent aujourdhui une acuit particulire. Les organisations sont confrontes des demandes de changement toujours plus tendues et plus frquentes. Ces changements sont lis la fois aux rorganisations (fusion, acquisitions), louverture des processus et la multiplication des volutions des marchs: On lobserve par exemple dans le secteur des services de telecom, dans les banques assurances, le transport et lnergie, ou dans le commerce en ligne. Les applications construites et structures pour rpondre des besoins particuliers dans un contexte donn ne sont plus adaptes aux ralits prsentes. Les changements technologiques des dernires annes (nouvelles technologies) ajoutent encore des contraintes supplmentaires. Aux del dun certain stade, les cots induits par les modifications deviennent prohibitifs, et les dlais incompatibles avec les demandes mtiers. Le systme devient trop rigide, prisonnier de son architecture antrieure. Les volutions ralises dans ce cadre dtriorent la qualit du systme et accroissent encore ces difficults. Quelques constatations majeures : Lagilit dun systme dpend au premier ordre du systme rel dploy. Les diffrentes reprsentations, modles ou cartographies, si elles facilitent la tche, et sont souvent ncessaires, nliminent pas la nature des obstacles rencontrs. Les infrastructures technologiques transverses (middleware, web services, ) ne constituent jamais en soi de solutions radicales. On observe au contraire que les stratgies trop ancres sur les technologies masquent les ralits mtiers et peuvent aboutir des rsultats dcevants et contre productifs.

www.softeam.fr

SOA : Architecture Logique. V1.0

fvrier 2007

Page 4 sur 30

Les systmes logiciels sont labors, dvelopps par des quipes. Le travail humain reste largement majoritaire dans nos mtiers et lorganisation, la gestion efficace des hommes est une des cls de la russite.

Larchitecture oriente service se base sur les principes suivants: Diviser pour rgner : Substituer la dcoupe strictement applicative par une structuration en composants plus rduits et potentiellement plus simples faire voluer. Alignement mtier : Construire et organiser le systme partir des ralits mtiers, qui doivent se retrouver dans ses constituants. Neutralit technologique : Assurer une indpendance totale entre les interfaces et les implmentations. Llment qui utilise un service ne doit pas tre contraint ni par la technologie dimplmentation, ni par sa localisation (potentiellement distribu). Mutualisation : Favoriser la rutilisation de services mtiers par plusieurs lignes mtiers ou applications. Permettre la construction de services de haut niveau par combinaison de services existants. Automatisation des processus mtier. Isoler la logique des processus mtiers sur des composants ddis qui prennent en charge les enchanements et les changes de flux dinformation. Echanges orients Document. Les informations changes par les services possdent une structure propre, guide par les besoins mtiers. On privilgie la transmission de contenus complets et utilisables au profit daccs direct aux structures de type objet ou relationnel.

La plupart des acteurs SOA prconisent une mise en uvre progressive, excluant les oprations de type big bang , avec une cohabitation entre les constituants divers (legacy, anciennes applications, ERP etc) et les services SOA. Cette cohabitation est facilite par la forte neutralit technologique, qui permet de dploiement de services sous forme de faades isolantes.

www.softeam.fr

SOA : Architecture Logique. V1.0

fvrier 2007

Page 5 sur 30

Les lments de base de larchitecture

Composant de service
Le composant de service est la brique de base de larchitecture [Figure 3]. Il se dcompose en deux parties : la vue externe (ou spcification de service), qui expose la facette service proprement dite, et la vue interne, qui dcrit le contenu du composant1. La vue externe est constitue par un ensemble doprations de service regroupes en interfaces (au sens UML), et de lappareillage pour les utiliser (types des donnes changes, contrat de service, proprits, etc.). Cette spcification est dcrite en gnral par un fichier WSDL2 ou quivalent.
Composant de service Composant de service
Primtre
Interface A Interface B Opration1 Opration2

Domaine dappartenance, visibilit

Vue externe

Opration1 Opration2

Donnes dchange Contrats

TDE: Types de donnes dchange

Contrat dutilisation des services

Logique interne

Data

Vue interne
Services utiliss Services utiliss

Figure 3 Structure du composant de service

La vue interne contient des informations relatives la logique interne comme le dtail des traitements, les algorithmes, les rfrentiels ou les bases de donne utilises. On y trouve galement les rfrences vers les services utiliss par le composant. Cette vue est masque aux consommateurs du composant de service. Elle est utilise notamment par les architectes, qui travaillent sur la vision globale du systme, et le positionnement du composant.
Vue externe Vue interne Liens de dpendance

Figure 4 - Reprsentation schmatique du systme

La notion de composant ou de composant de service se retrouve notamment dans SCA (Service Component Architecture) propos par lorganisme Open SOA (www.osoa.org)
2

Web Services Description Language. www.w3.org

www.softeam.fr

SOA : Architecture Logique. V1.0

fvrier 2007

Page 6 sur 30

Schmatiquement, larticulation des composants de service, avec leurs liens de dpendance, constitue la structure du systme [Figure 4]. Chaque composant de service peut invoquer les oprations de service dautres composants, dans la mesure ou les rgles de visibilit sont respectes.
Composants et services. Dans cette approche, le service dsigne le point de vue du consommateur, cest dire la vue externe du composant de service. Par exemple le service de gestion des commandes = vue externe du Composant gestion des commandes . Le catalogue des services publis sur un primtre est constitu par lensemble des vues externes des composants de service.

Les composants de service sont identifis et dfinis avant tout suivant une logique mtier, indpendamment de la technologie. On distingue pour ce faire le composant logique, qui fixe la structure du systme dans le cadre de larchitecture logique, et le composant logiciel, qui est sa traduction technique dploye.

Bus dentreprise
Le systme est constitu dun ensemble de participants communiquant qui jouent le rle de consommateur et de fournisseur de service. Les consommateurs de service peuvent tre divers : des applications, progiciels ou dautres composants de service. Les composants de service sont les fournisseurs de service du systme, dans lesquels on distingue deux familles: les composants qui prennent en charge directement limplmentation des services et ceux qui dlguent cette implmentation un tiers (mainframe, ERP, application existante). Il faut nanmoins prciser que dans ce cas de figure, le composant nest pas toujours assimil un simple passe-plat. Des traitements dadaptation sont frquemment ncessaires (format de donne, encapsulation de service) afin de mieux intgrer les besoins des consommateurs de service.
Application 1 Application 2

MainFrame

Bus de communication (ESB)

SGBD

ERP

Figure 5 ESB et Composants de service

Le bus dentreprise (ESB) agit comme la colonne vertbrale reliant ces participants dune manire banalise travers les interfaces de services. Cela permet notamment les modifications dimplmentation ou le remplacement des legacy sans remanier la structure de fonctionnement du systme.

Contrat de service
Le contrat de service3 joue un rle majeur : il dtaille les conditions dutilisation du service sous forme de pr et post conditions, protocoles, et contraintes non fonctionnelles (QoS, SLA4). En effet, la simple

Voir notamment: Reference Model for Service Oriented Architecture. OASIS. www.oasis-open.org

www.softeam.fr

SOA : Architecture Logique. V1.0

fvrier 2007

Page 7 sur 30

spcification fonctionnelle des oprations de services ne suffit pas garantir le fonctionnement correct du systme dploy. Les contraintes non fonctionnelles [Tableau 1], comme le temps de rponse ou le nombre dinvocations par seconde permettent de fixer les termes du contrat oprationnel entre consommateur et fournisseur de service.
Tableau 1 - Contraintes non fonctionnelles Type de contraintes Disponibilit Exemples Taux dindisponibilit par an Plages horaires Contraintes de maintenance Temps de rponse moyen, minimum Nombre de transactions par seconde Taux derreur Politique de droits daccs Non rpudiation Journalisation Tableaux de bord, statistiques

Performance Fiabilit Scurit Administration

Le protocole dutilisation dun composant de service dfinit les squences valides dinvocation des ses oprations [Figure 6]. A noter que les composants de service ne sont pas des objets : ils ne conservent aucun tat (une seule instance du composant est disponible). Les conditions portent sur des attributs des donnes dchange transmises lors de linvocation des oprations : dans lexemple [Figure 6] ltat est un attribut de typefacture transmis en entre de chaque opration du composant Facture.
Composant Facture
Interface dcriture mettre Cre crer(typeFacture): typeFacture modifier(typeFacture): typeFacture emettre(typeFacture): typeFacture regler(typeFacture): typeFacture annuler(typeFacture): typeFacture

annuler annuler

mise

rgler Annule Rgle

typeFacture Numero Etat NumeroClient Date

Figure 6 - protocole d'utilisation du composant Facture

Dans la mme optique, les pr et post conditions dtaillent encore les conditions dutilisation sur les oprations de service5.

4 5

QoS: Quality of Service. SLA: Service Level Agreement. Reprise des mthodes de programmation par contrat. fr.wikipedia.org/wiki/Programmation_par_contrat

www.softeam.fr

SOA : Architecture Logique. V1.0

fvrier 2007

Page 8 sur 30

Donnes dchanges et donnes persistantes

La distinction entre les donnes dchange et les donnes persistantes est inhrente aux architectures SOA, qui isolent les bases de donnes laide de services daccs [Figure 7]. Les donnes dchange sont les informations vhicules entre les participants (consommateurs ou fournisseurs de service) travers linvocation des oprations de service. Les donnes persistantes sont les informations contenues et gres dans les bases de donnes. Ces informations sont structures de faon habituelle (par exemple SGBD en mode relationnel), dans le cadre de rfrentiels ou de bases applicatives.
Zone dchange Zone de stockage

Donnes dchange, flux

Services Applications

Donnes persistantes

Messages
Services

Applications

Bases

Services

Services

Services

Interfaces, schmas XML Formats dchange Service bus

MCD, MPD, schmas

Metadata

Figure 7 - Donnes d'change et donnes persistantes

Les types de donne dchange (TDE) tablissent la smantique, la structure et le format de ces donnes. Ils peuvent tre dfinis laide de schmas XML (et ventuellement de classes UML). Chaque opration de service prcise les types de donne dchange en entre et en sortie.
Tableau 2 - Oprations de service: exemples Opration de service crerCommande validerCommande Entre(s) TDE_Commande TDE_Commande TDE_EtatValidation Sortie(s)

Les caractristiques des TDE sont les suivantes : On privilgie les messages gros grain , qui regroupent un ensemble dinformations exploitables directement par le mtier, et qui minimisent le nombre dinvocation dopration de service [Figure 8]. La structure et lorganisation des TDE nest pas contraint par des normalisations (entit-relation ou orient objet). On parle de contenu orient document, ou message, dans lequel on trouve une copie des lments proche de la vision mtier. (Par analogie avec le fonctionnement dune messagerie, ou chaque message est constitu dlments dont la cohrence est valide par le propos du message luimme).

www.softeam.fr

SOA : Architecture Logique. V1.0

fvrier 2007

Page 9 sur 30

<commande> <client> <nom> Durand </nom> <noContrat> 27615 </noContrat> </client> <montant> 522 </montant> <date> 15O12007 </date> <ligneCommande> <noProduit> 432 </noProduit> <quantit> 3 </quantit> </ligneCommande> <ligneCommande> <noProduit> 603 </noProduit> <quantite> 1 </quantite> </ligneCommande> </commande> Figure 8 Exemple de donne d'change "TDE_Commande' (format XML)

Dans le cadre SOA, la gouvernance des donnes intgre la gestion des donnes persistantes, des donnes dchange et de leurs liens. La matrise de cette gestion est fondamentale et doit tre traite avec une attention particulire6. En effet, le contenu et la structure des donnes dchange sont en grande partie issus des donnes persistantes et le bon fonctionnement du systme ncessite la description dtaille de ces relations.

Ce sujet sera trait dans un document consacr cette question.

www.softeam.fr

SOA : Architecture Logique. V1.0

fvrier 2007

Page 10 sur 30

Typologie et modle en couches logiques

La mise en uvre de services, aux travers de composants de service est-elle suffisante ? Force est de constater que les SI sont des systmes complexes et souvent htrognes. La prolifration dlments, fussent ils des services mtiers, schangeant toutes sortes de messages ne constitue pas une image trs rassurante pour un DSI (on parle de la drive Spaghetti Oriented Architecture).
JBOWS (Just a Bunch of Web Services). An effective, functioning service-oriented architecture requires governance, and the ability to share services across multiple business units and enterprises. Its easy to build Web services. You could build 10 of them in an afternoon. But, then you end up with a JBOWS architecture (Just a Bunch of Web Services), which will grow into a different sort of SOA a Spaghetti-Oriented Architecture. Joe McKendrick , december 2006, ZD Net.

Il existe un consensus aujourdhui pour btir les architectures de systmes partir dune typologie de services bien tablie, organise en couches logiques (Tableau 3). Schmatiquement, les processus sappuient sur un ensemble de services de plus bas niveau et daccs aux donnes.
Tableau 3 - Les diffrentes propositions de typologies de services Herzum & Sims7 ESOA8 Front end Application Processus Process centric Intermediary Entit Utilitaire Public enterprise Basic Microsoft9 Presentation Layer Business Process Business Service Data Service IBM10 Presentation Business process choreography Composite service Service Wikipedia11 Presentation Process Functionality Data Types SEA Prsentation Processus Fonction Entit Utilitaire Public

Nous avons choisi pour SEA de distinguer 4 types de composant: Prsentation, Processus, Fonction, Entit, organiss en 4 couches logiques de stabilit croissante, auxquels nous ajoutons les composants Utilitaire et Public, en charge des fonctions transverses et des changes avec les systmes externes.

7 8 9

Business Component Factory, Peter Herzum & Oliver Sims, Wiley Computing Publishing 2000 Enterprise SOA, Dirk Krafzig, Karl Banke, Dirk Slama, The Coad Series, 2005

An Overview of Service-Oriented Architecture in Retail, Moin Moinuddin, Microsoft Corporation, January 2007
10 11

Bernhard Borges, Kerrie Holley and Ali Arsanjani, IBM , 15 Sep 2004, SearchWebServices.com

This is the type of the service to help distinguish it in the layer in which it resides: Data, Functionality, Process, and Presentation. http://en.wikipedia.org/wiki/Service-oriented_architecture

www.softeam.fr

SOA : Architecture Logique. V1.0

fvrier 2007

Page 11 sur 30

Les couches logiques de stabilit croissante tablissent la rgle de base de dpendance : un composant ne peut pas utiliser un composant dune couche dun niveau suprieur (par exemple, un composant Entit ne doit pas utiliser un composant Fonction ou Processus).
Prsentation Publics
Commande

Stabilit

Processus

Entits

Figure 9 - Modle en couches logiques

Chaque type de composant joue un rle spcifique : Composant Prsentation: Mise en oeuvre du dialogue avec lutilisateur : IHM, gestion de la session utilisateur (Ce nest pas un composant de service proprement parler) Composant Processus: support de processus mtiers complets (rle dorchestration); sappuie notamment sur des composants de type Fonction et Entit Composant Fonction: Composition de services. Adaptations fonctionnelles ou traitements localiss. Composant Entit: Service daccs aux donnes persistantes (CRUD12), aux bases de donnes et rfrentiels. Composant Utilitaire: fournisseur de services dinfrastructure ou transversaux (messagerie, tableau de bord, ditique, annuaire) Composant Public : ddis aux services accessibles lextrieur du SI (B2B, partenaires)
Prsentation Achat Produit (Web)
Prsentation

Processus
processus

Processus Commande
Fonctions

Fonction
Entit

Entit

Catalogue

Figure 10 - Architecture de composants de services: exemple

12

CRUD : Create, Read, Update, Delete

www.softeam.fr

SOA : Architecture Logique. V1.0

fvrier 2007

Utilitaire
Commande Client Client

Fonction

Page 12 sur 30

Composant Entit
Les composants de service de type Entit sont focaliss sur un objet mtier cl du systme (par exemple Client, Contrat, Commande, ). Leur rle est de permettre un accs aux informations relatives cet objet mtier, le plus souvent associ une base de donne. On trouve typiquement les oprations de lecture, criture ou de requte [Figure 11]. On impose que tout accs un objet mtier cl passe par le composant Entit correspondant qui est unique. Par exemple, la cration, modification ou lecture dun objet Client passe obligatoirement par les oprations du composant Entit Client.
Interface de lecture Lire(noClient): TDE_Client Rechercher(criteres): listeDeClients Interface dcriture Crer(TDE_Client): TDE_Client Modifier(TDE_Client): TDE_Client

Client

Figure 11 - Composant de service "Client" avec ses deux interfaces (lecture et criture)

Les types de donne dchange (TDE) reprsentent la structure des flux changs via les oprations de service (entres et sorties des oprations). Plusieurs TDE sur le mme objet peuvent tre dclars [Figure 12], en fonction du dtail demand ou du point de vue.
Contenu dtaill Contenu dtaill
1

*
adresse

TDE_Client1
1 1 1

*
Entreprise Secteur

Profil

Coordonnes bancaires

*
Poste

*
Achats

* *
Mtier

Contenu synthtique Contenu synthtique

adresse TDE_Client2
1

Coordonnes bancaires

Figure 12 - Deux types de donne d'change (TDE) de l'objet mtier Client

Il y a une relation troite entre le composants Entit et le modle des objets mtiers: Pour chaque objet mtier cl, on doit trouver un composant Entit correspondant. Lidentification des objets mtiers cl dpend du contexte mtier et reprend les pratiques danalyse existantes. Par exemple, les objets mineurs ont peu de sens utiliss seuls (adresse du client). A linverse, les objets mtiers cl interviennent directement dans les processus, sous forme de flux, ou sont les plus utiliss comme tels

www.softeam.fr

SOA : Architecture Logique. V1.0

fvrier 2007

Page 13 sur 30

par lutilisateur du systme. Finalement, les messages changs lors de lexcution des oprations de service sont constitus par une grappe dlments dont la racine est un objet mtier cl. Techniquement, ces messages sont gnralement transmis sous la forme de documents XML, et les types de donne dchange (TDE) dcrit par un schma (XSD) correspondant.

SOA et Processus
Dans le cadre SOA, lautomatisation des processus est un axe majeur, avec les notions dorchestration, composition de services ou de chorgraphie. Il sagit de centraliser la logique dun processus dans un composant ddi, qui prend en charge lenchanement et les rgles de gestion associes [Figure 13]. Cette approche tend rduire les impacts lis aux volutions du processus.
Commande Client Application Commande 1 Enregistrement commande Application Facturation Enregistrement facture Application Client Mise jour du profil Envoi facture

Commande Client Achat Web

Rgle de gestion Si nouveau client, cration du client Sinon mise jour du profil Rgle de gestion Si nouveau client, envoi dun message de bienvenue

Processus Commande client Messagerie

commande

facture

Client

Figure 13 - Automatisation de processus. 1) oriente applications 2) oriente services

Une clarification est nanmoins ncessaire : On distingue les processus mtiers transverses et les processus de traitement. Les premiers reprsentent les processus de bout en bout de lentreprise, qui dlivrent une valeur ajoute tangible lextrieur par une collaboration de plusieurs units et acteurs. Les seconds (processus de traitement) reprsentent le droulement dune activit spcifique et localise. Pour simplifier on parlera de processus mtiers et de processus de traitement.
On peut utiliser une identification plus formelle entre processus mtier et processus de traitement : un processus mtier est interruptible et possde un tat quil doit conserver entre deux interruptions. A linverse, un processus de traitement nest pas interruptible et ne maintient pas dtat en dehors de son excution.

Un processus mtier peut durer plusieurs jours, plusieurs mois ou plus : par exemple le traitement dun sinistre dassurance ou la livraison dun produit command [Figure 14]. Le processus de traitement au contraire a une dure limite et relve plus simplement dune opration informatique habituelle (par exemple le contrle et enregistrement dun dossier, le destockage dun produit).

www.softeam.fr

SOA : Architecture Logique. V1.0

fvrier 2007

Page 14 sur 30

Client

Gestion Commande Commande [Cre]

Livraison Vrifier le stock

Comptabilit

Relation Fournisseurs Demander au fournisseur Commande Fournisseur

Commande Commande de produit de produit

Valider la commande
OK

KO

Attente Fournisseur

Dlai dpass Dlai dpass

Commande [Annule]

KO

Prparer la commande
OK

OK Fournisseur

Commande [Valide]

Commande [Prpare]

Facturation

Expdier le produit facture Commande [Expdie] Attente Livraison

Dlai dpass Dlai dpass

Notification Livraison

Notifier la date de livraison

Livraison effectue

Figure 14 - Processus mtier transverse : exemple (diagramme d'activit UML)

Lautomatisation des processus mtiers (transverses) est prise en charge par les composants de type Processus. Cette automatisation est appele Orchestration de service (par analogie avec lorchestre qui comprend un grand nombre de musiciens diffrents collaborant lexcution dune symphonie sous le contrle du chef dorchestre). Les composants de types Fonction sont en charge des processus de traitement. Ils jouent galement le rle dadaptation et dagrgation (composition de service) entre les Entits et les processus mtiers ou la vision utilisateur.
Tableau 4 - Proprit des composants de service de type Processus, Fonctions et Entits Type Processus Fonction Rle Processus mtier transverse. Orchestration de service Processus de traitement, composition de services, adaptation Accs un objet mtier cl Type de participant Fournisseur et consommateur de service Fournisseur et consommateur de service Fournisseur de service Granularit13 Granularit leve. Transverse par nature. Granularit moyenne

Entit

Granularit fine. Focalis sur un objet mtier cl

Composant Processus
La distinction entre processus mtier et processus de traitement nest pas une simple question de vocabulaire. Le type de question pos par lautomatisation des processus mtiers est tout fait spcifique : la gestion des vnements et des tats du processus, les actions de compensations14, le nombre et la diversit des services utiliss. On est dans le domaine du BPM15, avec ses techniques

13 14

La granularit est un indicateur informel li au primtre fonctionnel couvert par le composant.

Les actions de compensation dfinissent les traitements raliser en cas derreur ou dexceptions dans le droulement du processus, pour retrouver un tat correct. BPM : Business Process Management. Gestion de processus mtier. BPEL : Business Process Execution Language. BPMN : Business Process Modeling Notation (www.bpmn.org). BAM : Business Activity Monitoring.
15

www.softeam.fr

SOA : Architecture Logique. V1.0

fvrier 2007

Page 15 sur 30

sous-jacentes comme BPEL, les mthodes de description adapte (voir le langage BPMN), ou la supervision de processus (BAM). Les oprations de service Processus sont lies aux vnements du processus : dmarrage, arrt, ou spcifiques au mtier.
Interface Processus Commande
DemarrerProcess(TDE_Commande, Client): TDE_DossierCommande DepassementDelai (NoDossier) RepriseProcess(NoDossier, Partenaire) ConfirmerPrestation(NoDossier) AnnulationCommande(NoDossier)

Commande
TDE Dossier commande NoDossier: interger Etat : TypeEtat Dlai: Dure

Client

Processus Commande

Fournisseur

Figure 15 - Composant processus: interface et type de donne d'change

Le type de donne dchange du processus contient toutes les informations utiles ainsi que ltat du processus. Il est sauvegard chaque suspension du processus (attente dvnement). Le processus devient un objet part entire, avec un tat propre, distinct de ltat des autres objets mtiers (commande, facture). Cette distinction facilite le traitement des volutions du processus mtier, par le faible impact induit sur les autres composants. Par exemple, lajout dune double validation dans le processus de commande va modifier le processus sans impact sur les tats de lobjet commande. Processus humains et workflow Il faut noter que dans loptique SOA (et BPM), laccent est mis sur les processus mtiers non humain , c'est--dire avec pas ou peu dintervention humaine dans leur droulement. Cest dailleurs un des objectifs de lautomatisation des processus : rationaliser et rduire le poids des tches manuelles dans lexcution des processus mtiers. A linverse, les processus mtiers forte intervention humaine (un grand nombre dactivits sont ralises par des acteurs humains aids par le systme) relvent plus des outils de workflow. Ces outils prennent en compte lorganisation des quipes, la transmission des informations et la synchronisation des tches entre les diffrents acteurs impliqus dans le processus. Cependant, il ny a pas de frontire toujours nette entre ces deux domaines : dans la pratique, lintervention humaine est souvent ncessaire pour traiter les situations exceptionnelles. Une solution ad hoc peut tre mise en place dans ce cas sans faire intervenir un moteur de workflow dans le processus16.

Composant Fonction
Les composants Fonction occupent une place charnire dans cette architecture. On a vu prcdemment quils se chargent des processus de traitement, mais plus gnralement ils fournissent les services proches de la vision utilisateur, par composition de services de type Entit. On retrouve cette notion de composition dans les TDE des services de type Fonction, qui sont souvent dfinis comme une agrgation de TDE de composants de type Entit [Figure 16].

Le langage dexcution de processus BPEL ne couvre pas actuellement lintervention dacteurs humains dans le droulement des activits.

16

www.softeam.fr

SOA : Architecture Logique. V1.0

fvrier 2007

Page 16 sur 30

Lecture du dtail du contrat et du client associ Cration contrat Modification contrat

TDE Contrat + Client

Contrat client

TDE client

Client

Contrat

TDE contrat

Figure 16 - Composant Fonction et agrgation de donnes d'change

Dans la pratique, les composants Fonction sont les moins aiss identifier. Les composants Processus proviennent directement des processus mtier de lentreprise, et les composants Entit des modles dinformation (objet mtier ou base de donne). Les composants Fonction sont mis en place graduellement par consolidations successives du systme.

Composant Utilitaire et public

Les composants Utilitaires fournissent les services transverses, et relativement indpendants du mtier de lentreprise, comme les annuaires, la messagerie ou lditique. Gnralement stables, les composants utilitaires sont souvent implments par des progiciels largement diffuss, et sont peu risqus. Les composants Publics sont ddis aux changes avec lextrieur de lentreprise (B2B e-Business). Le choix est de rserver ces communications un type de composant particulier, compte tenu de ses particularits et des risques spcifiques. Typiquement, ces composants prennent en charge ladaptation des formats de donne (diffrence dencodage, de structure ou de format), la scurit, et tous les ajustements propres aux dialogues avec les partenaires. Les composants Publics et Utilitaires ne sont pas associs une couche logique particulire. Ils peuvent tre en relation avec des composants de service indpendamment de leur type.

Composant Prsentation
Les composants Prsentation pilotent le dialogue entre le systme et les acteurs externes. Ils assurent la gestion des interfaces homme machine et la maintenance du contexte session de lutilisateur. Techniquement, ce type de composant utilise les infrastructures prouves (client riche ou client web, tiers de distribution).

www.softeam.fr

SOA : Architecture Logique. V1.0

fvrier 2007

Page 17 sur 30

Client Composant Prsentation Site Web client

Processus commande

Catalogue Client

Produit

Tarif

Stock

Commande

facture

Client

Figure 17 - Composant Prsentation

Les composants Prsentation ne sont pas des composants de service proprement dit : ils ne fournissent pas de services, sauf lutilisateur. Ils sont consommateurs de service pour tout autre type de composant. Dans le cadre dune architecture SOA, les composants Prsentation sont la fois un point dentre sur le systme et responsables de lintgration des contenus pour lutilisateur. Ils grent galement le dialogue, lvolution des donnes et leurs modifications au cours dune session.

Dmarche et identification
Il nexiste probablement pas de dmarche universelle pour lidentification et la construction des services. Le contexte de lentreprise, les mthodes ou les modles durbanisation utiliss sont autant de facteurs qui devront tre pris en compte. On peut nanmoins distinguer plusieurs dmarches types : Dmarche par processus mtiers Dmarche oriente donnes Dmarche oriente applications

Naturellement, ces dmarches types ne sexcluent pas (et ne sont pas exhaustives). Dans la ralit, le systme se constitue par une articulation de ces diffrentes approches, par consolidations successives, en parallle avec la vision globale de larchitecture.

Dmarche orient processus

La dmarche orient processus sappuie sur une analyse des processus mtiers de lentreprise (ou dun domaine particulier), dans lobjectif de dployer des composants de services de type Processus. Les principales activits sont les suivantes : Cartographie des processus mtiers : inventaire des processus mtiers, avec leurs proprits et leurs liens. Cette cartographie reste au niveau macro, sans dtailler le droulement de chacun des processus. Identification des composants Processus : Dtermination des processus mtiers automatiser. On privilgie les processus forte valeur ajoute pour lentreprise (on vite les processus internes comme la gestion du personnel) et les plus volutifs, de faon aboutir un rel apport mtier et un retour sur investissement notable. A noter que certains processus peuvent tre dj automatiss, mais dissmins sur plusieurs applications. Dans ce cas, la reprise de la logique des ces processus par un composant

www.softeam.fr

SOA : Architecture Logique. V1.0

fvrier 2007

Page 18 sur 30

ddi (type Processus) entrane une rnovation des applications impactes qui facilitera la prise en compte des futures volutions. Elaboration des modles de processus mtiers. Ces modles reprsentent lenchanement des processus mtiers (activits, flux, acteurs) avec un point de vue matrise douvrage. Les flux changs par les activits tablissent une premire structure des types de donnes dchange (TBE) utiliss. Ces modles sont raliss laide de notations BPM ou de diagrammes dactivit UML [Figure 14]. Modles de processus excutable. Le passage de modles mtiers aux modles excutables ncessite la description dtaille de tous les lments (lensemble des chemins, les erreurs, les compensations ventuelles), et de prciser les services consomms par de processus. Ce travail permet gnralement didentifier de nouveaux services ou dajouter des oprations aux services existants (notamment services de type Fonction ou Utilitaire). Les modles sont de type BPEL, excutables laide dun outil ou traduits dans un langage de programmation. Cette reprsentation sert de base pour la spcification des services, avec lensemble des oprations ncessaires.

Dmarche oriente donne

Cette dmarche aboutit la mise en place de composants de type Entit, avec la dfinition des types de donne dchange (TDE) associs. Elle assure un accs banalis aux informations gres par les bases de donnes. Modle des objets mtier. Ce modle reprsente la structure et les proprits des objets mtiers. Typiquement, on utilise le formalisme de classes UML, en sappuyant sur les structures propres des bases de donnes existantes.
S tock

TarifGeneral

Catalogue

* Lot

* Tari fUnit * 1

* Produit

1 FicheTechnique 1 * Proprit

1 1 1 Fournisseur

1 * Transposteur 1 Commande 1 1 1 Client 1 Facture * LigneCommande

Figure 18 - Modle des objets mtier (notation UML)

Identification des objets mtiers cl. Comme il a dj t voqu prcdemment, cette identification sappuie fortement sur la connaissance fonctionnelle. Chaque objet mtier cl donne lieu un composant de service de type Entit, qui fournit les services daccs (cration, modification, suppression et requte). Dfinition des TDE. Pour chaque objet mtier cl (et donc pour chaque composant de type Entit), un ou plusieurs formats dchange est dfini. Ce format est naturellement bas sur les modles des objets mtiers, et consiste dcouper celui-ci sous la forme de format de type document (schma XML), qui seront changs lors de linvocation des oprations du service [17].
17

Voir notamment Enterprise Oriented Architecture, James McGovern, Oliver Sims, Ashish Jain, Mark Little, Springer, 2006, chapitre 2.

www.softeam.fr

SOA : Architecture Logique. V1.0

fvrier 2007

Page 19 sur 30

Branchement des composants. Par leur nature particulire, les composants de type Entit obligent une modification dans les accs linformation. En effet, ces composants sont par dfinition dunique canal vers les donnes persistantes : les autres formes daccs doivent donc tre remanies (par exemple les lectures directes vers les bases de donnes).

Dmarche oriente application

Lobjectif est la restructuration de certaines applications par mutualisation de services. Cartographie des applications. Cest un modle des applications existantes intgrant notamment les changes de flux inter applicatifs. Identification des services mutualiss. Lanalyse des flux et leurs caractristiques (volume, frquence) signale les applications fortement dpendantes. De plus, une connaissance plus dtaille des applications peut faire apparatre des redondances fonctionnelles ou des duplications historiques. Ces lments se conjuguent pour isoler les services potentiellement mutualisables, et dobtenir une dcoupe plus simple et plus cohrente.
Application 1 Application 1 Application 2 Application 2

Figure 19 - restructuration par mutualisation de service

Restructuration. Les composants de services doivent apparatre comme des lments stables, avec un consensus dinterprtation sans entraner une refonte complte du domaine. Dans le cas contraire, une reconstruction globale est souvent prfrable, avec une mise plat de lanalyse mtier. Les composants de services rsultants sont gnralement de type Fonction, proches de lutilisation mtier. Remarque. La mutualisation de service nest pas un objectif en soi. Il est inutile de dpenser du temps (et du budget !) dans la restructuration dapplications stables qui fonctionnent correctement.

Gestion des versions

Comme tout lment logiciel, les composants de services sont soumis aux volutions (maintenance ou modifications fonctionnelles). La mutualisation de service a des impacts plus ou moins importants sur les consommateurs de ces services, en fonction du type dvolution [Figure 20] : lajout dune nouvelle interface ou dune opration, la modification de limplmentation (sans modification des interfaces de service), la modification dinterface existante, la modification des types de donne dchange.
I1 I2 Interfaces I1 I2 I3 I1 I2 I1 I2

V1

V2

V2

V2

Implmentations

Figure 20 - Types d'volution: Ajout d'interface, modification d'implmentation, modification d'interface

www.softeam.fr

SOA : Architecture Logique. V1.0

fvrier 2007

Page 20 sur 30

En toute rigueur, le dploiement dune nouvelle version dun composant de service entrane un cot (et un dlai) supplmentaire d en particulier aux tests ncessaires des diffrents consommateurs du service. Cette contrainte peut dans certains cas devenir contradictoire avec la souplesse recherche, et un dploiement de plusieurs versions dun mme composant est une solution envisageable. Par exemple [Figure 21], si 2 applications A et B utilisent le mme service, et que pour les besoins de lapplication B le service est modifi, la cxistence de deux versions du service permet le dploiement rapide le la nouvelle version sans impact sur lapplication A. Le bus de communication prend en charge le routage en fonction du consommateur de service.
Application A Application B Application A Application B Application A Application B

SX v1

SX v1

SX v2

SX v2

Transition Transition

Figure 21 - Transition utilisant plusieurs versions d'un service

Cependant, on vitera la multiplication de ce genre de situation, qui devra conserver son caractre transitoire. En effet, la prolifration de versions de service engendre des difficults de gestion qui annulent terme ses effets bnfiques. Lutilisation de rgles appropries permet de rduire ce type de risque, par exemple : Le nombre de composants de service dploys en plusieurs versions ne doit pas dpasser 15% du nombre total des composants. Pour un composant de service donn, le nombre de versions dployes est au maximum de 3

Spcification tendue et tests

La spcification de service a t dfinie plus haut avec ces diffrents lments : interfaces et oprations, contrats et protocoles, types de donnes dchange. En considrant le composant de service comme un mini progiciel du point de vue des consommateurs de service, les lments de test sont partis prenante de sa spcification. Certaines mthodes comme Extreme Programming18 assimilent dailleurs spcifications et tests externes. Sans reprendre totalement cette approche, la vision pragmatique qui consiste dfinir un lment logiciel par sa capacit rpondre un ensemble de scnarios dtermins nest pas nouvelle et est la base des oprations de recettes. Dans cette optique, la livraison dun composant de service intgre tous les lments qui participent sa validation : les scnarios dutilisation externes, les exemplaires de donnes dchange et donnes persistantes, les mulateurs ventuels (bouchons) qui permettent la mise en uvre de ces tests.

18

Extreme Programming Explained,Kent Beck, Addison-Wesley, 1999

www.softeam.fr

SOA : Architecture Logique. V1.0

fvrier 2007

Page 21 sur 30

Tests de validation (boites noire)

Scnarios Scnarios Scnarios Scnarios Scnarios Scnarios Primtre
Interface A Interface B Opration1 Opration2

Composant de service Composant de service

Vue externe
Donnes dchange Contrats

Opration1 Opration2

Document de Document de spcification spcification

Logique interne

Data

Jeux de Jeux de donnes donnes

Vue interne
Services utiliss Services utiliss

Bouchons Bouchons

Tests unitaires (boites blanche)

Figure 22 - Composant de service: spcification tendue

Au-del du strict point de vue de validation, qui facilite les travaux dintgration, les scnarios de test ajoutent une dimension concrte et exemplaire qui participe la comprhension du rle du composant. On retrouve cette approche avec les cas dutilisation UML, qui prcisent laide de scnarios types, la dynamique dutilisation et les rsultats attendus. Lensemble de ces lments disponibles pour le consommateur de service est appel spcification tendue, qui pourra inclure galement tous les documents et lments utiles la dfinition du service.

www.softeam.fr

SOA : Architecture Logique. V1.0

fvrier 2007

Page 22 sur 30

Cartographie et modles
Cartographie des services
La cartographie des services est une vue synthtique des composants de services et de leur rpartition dans les diffrentes couches logiques (Prsentation, Processus, Fonction, Entit).
Site Web client
Prsentation

Suivi commande

Gestion tarif

Achat fournisseur

changes Fournisseurs Rglement CB

Processus commande Processus MAJ Catalogue

Processus

Processus retour commande Processus Gestion litiges

Processus MAJ Tarif Processus Achat produit

Messagerie

ditique Catalogue Client

Fonction

Commande Client

Tableaux de bord

Tarification

Public Utilitaire

Produit
Entit

Tarif

Stock

Client

Commande

facture

Transporteur

Figure 23 - Cartographie gnrale des composants de service

Structure gnrale du systme

Le systme contient naturellement tous les constituants du systme. Dans la pratique, on va utiliser diffrentes vues (diagrammes) en fonction du type de tche ou du niveau de dtail dsir. La description des dpendances (liens dutilisation) est particulirement importante pour une analyse du systme.
Client Site Web client changes Fournisseurs Processus commande Gestionnaire commande Poste Gestionnaire

Rglement

Messagerie Catalogue Client

Produit

Tarif

Stock

Client

Commande

facture

Transporteur

Figure 24 - Reprsentation des liens de dpendance entre composants

www.softeam.fr

SOA : Architecture Logique. V1.0

fvrier 2007

Page 23 sur 30

Dpendance dinterfaces
Chaque composant de service peut potentiellement exposer plusieurs interfaces (qui contiennent chacune des oprations de services). Le lien de dpendance au niveau des interfaces permet une connaissance plus fine de la structure du systme et facilite les analyses dimpact.
Catalogue Client MAJ Tarifs

Lecture criture

Produit

Tarif

Stock

Produit

Tarif

Figure 25 - Utilisation des interfaces entre composants

La notation UML2 offre une reprsentation directe de composants laide des notions de Port, Part, Composant et Connecteur.

Catalogue client

lProduit

e Produit lT arif

e Tarif

lStock

e Stock

Produit

Tarif

Stock

Figure 26 - Composants de service: reprsentation UML2

Au-del dune certaine taille, lemploi dun outil de modlisation est un atout indispensable pour la gestion du systme. Il facilite llaboration en cohrence des diffrents points de vue, laudit automatique et lanalyse dimpact, la production dtat (HTML) pour la diffusion et le partage dinformation. La mise en uvre des techniques MDA19, par la production des constituants logiciels partir des modles assure une meilleure matrise des changements en rduisant la distance entre les aspects logiques et techniques.

19

MDA : Model Driven Architecture. www.omg.org/

www.softeam.fr

SOA : Architecture Logique. V1.0

fvrier 2007

Page 24 sur 30

Structuration du SI et application
Application composite
la vue de ce type darchitecture, on peut lgitimement se demander o sont passes nos applications ? Sagit-il dune disparition de lentit logicielle qui structure la majorit des SI daujourdhui ? Les applications sont les lments tangibles du point de vue des utilisateurs du systme. Dans cette mesure, elles jouent un rle essentiel : la rponse aux besoins concrets, et la valeur ajoute du systme se concentre un moment sur le dialogue acteur-systme. La mise en uvre de SOA nimplique pas la suppression des applications : Au contraire, centre sur les objectifs mtiers, SOA tend amliorer la mise disposition dapplications toujours plus performantes et adaptes ses utilisateurs.
Le syndrome architectural. Comme avec dautres approches, il faut se garder de lcueil substituer les moyens aux objectifs . Les architectures comme les technologies ne constituent pas des buts en soi. Il sagit dinstruments (outils) mis en uvre pour rpondre des demandes mtier, qui sont mis en uvre dans le cadre dapplications concrtes.

Une application composite est constitue par un ensemble de composants qui concourent pour rpondre aux besoins ddis une ligne mtier ou une utilisation spcifique du systme. Typiquement on va trouver dans une application composite un composant Prsentation (IHM, session utilisateur) qui sappuit sur des composants de services de diverses natures (Processus, Fonction, Entit ).
Application A Application B

Figure 27 - Applications composites

En terme dorganisation, les projets applicatifs ont en charge la livraison de lapplication auprs des clients utilisateurs (internes ou externes) correspondant aux cahiers des charges. Cette responsabilit implique la mise en uvre de toutes les activits ncessaires : analyse, conception, intgration, validation, construction de lIHM, dveloppement de composants spcifiques. Dans une architecture SOA, ces projets applicatifs vont potentiellement rutiliser et partager des composants de service, qui nappartiennent pas une application particulire. Le dveloppement, la maintenance et la gestion de ces composants mutualiss sont pris en charge par une organisation transverse qui assure la coordination fonctionnelle et technique.
Conflits dintrt. Il existe un risque de conflit dintrt entre les responsables des projets applicatifs et les objectifs SOA. Les premiers sont valus par leurs capacits fournir dans les dlais les lments correspondants aux cahiers des charges en respectant les cots fixs. La prise en compte de facteurs transverses peut tre peru comme une contrainte additionnelle. Le rle de la direction est fondamental pour assurer les coordinations et les actions permettant une collaboration efficace avec les quipes transverses.

www.softeam.fr

SOA : Architecture Logique. V1.0

fvrier 2007

Page 25 sur 30

Remarque : SOA nimplique pas la refonte totale du SI, et dans la pratique, des applications anciennes modes coexistent avec les applications composites. Pragmatiquement certaines vont partiellement utiliser des services tout en conservant leurs structures initiales.

Visibilit et structuration du SI
La notion de primtre de visibilit dun service nest pas une question annexe et impacte lorganisation aussi bien que larchitecture. Le primtre de visibilit dun service prcise les lments qui ont le droit de lutiliser comme consommateur du service. En gnral la structuration des systmes dinformation se retrouve dans lorganisation des responsabilits des quipes. Les termes utiliss sont variables : domaine, sous-systme etc., bien que les dmarches durbanisation ont depuis quelques annes fix un vocabulaire plus homogne. Les composants de service, comme tout lment du systme dinformation doit tre positionn dans cette organisation gnrale, qui nest pas modifie par cette opration. Le primtre de visibilit est une proprit importante : un service limit une application et un service publi en ligne ne sont pas de mme nature. Le facteur cot va galement intervenir : un service disponible sur un large primtre ncessite des efforts supplmentaires sur les plans contractuel et technique.
Bonne pratique. Toujours dfinir le primtre dun service publi. La mutualisation de service implique un cot supplmentaire qui dpend en partie du primtre de visibilit du service. La disponibilit globale non structure de tous les services risque de provoquer des dysfonctionnements majeurs sur les plans organisationnel et technique.

Concrtement, le primtre de visibilit dun service est dfini partir des units dorganisation du systme (domaine, sous-systme etc.) [Figure 28]. Il peut galement tre dfini de manire plus explicite, par numration des consommateurs autoriss.
Systme A Sous-systme Sous-systme

Services de sous-systme

Services disponibles sur le systme A

Systme dinformation

Systme A Services disponibles sur tout le SI

Systme B

Systme C

Figure 28 - Primtre de visibilit

Le primtre de visibilit dun composant peut varier au cours de sa vie. Par exemple, un service expos dans un premier temps sur un sous-systme, accrot son primtre avec le temps pour couvrir tout le SI. Cette modification de visibilit, mme fonctionnalit quivalente implique gnralement une reformulation du contrat de service.

www.softeam.fr

SOA : Architecture Logique. V1.0

fvrier 2007

Page 26 sur 30

SEA (Service Enterprise Architecture)

Larchitecture logique, mme si elle joue un rle central, doit tre articule avec les autres axes de construction: Le processus de mise en uvre, la gouvernance des donnes, les structures dorganisation, la mthodologie, les infrastructures techniques et les dveloppements. Ces points dpassent le primtre de ce document, mais leur matrise constitue un facteur cl de la russite. Notre approche SEA20 (Service Enterprise Architecture) se positionne avant tout dans une vision globale de lentreprise, en intgrant toutes ses facettes. Le processus global SEA [Figure 29] propose une dmarche pragmatique et souple, adaptable chaque contexte, avec une trajectoire progressive base sur une monte en comptence et maturit chaque phase du processus.

Figure 29 - Processus SEA

Au del des effets de mode, la mise en uvre de SOA peut apporter une vritable valeur ajoute pour lentreprise. Cependant, comme pour tout changement, le succs passe par une matrise des risques et des objectifs. Les expriences passes ont montr que les cueils existent : par exemple, le manque de rsultat clair dans le dploiement des EAI, certainement due une orientation trop souvent focalise sur les solutions techniques et les offres diteurs. Une vision clairement oriente mtier, du pragmatisme dans les dcisions sans oublier des organisations motives sont parmi les points cl pour la russite de la dmarche.

20

Une description plus dtaille de SEA est disponible sur notre site www.softeam.fr

www.softeam.fr

SOA : Architecture Logique. V1.0

fvrier 2007

Page 27 sur 30

Glossaire
Application composite BAM Application constitue par assemblage dun ensemble de composants. Business Activity Monitoring. Fournit un tableau de bord, des indicateurs de mesure de la performance mtier, des outils de monitoring, de reporting et permet le contrle du rendu fonctionnel des processus mtier ; associ de faon classique un outil de BPM et considr juste titre comme une application part entire. Business Process Execution Language. Conu par IBM, BEA et Microsoft, c'est la reprsentation XML dun processus excutable, qui peut tre dploye sur nimporte quel moteur de processus mtier. Llment premier dun processus BPEL est une activit , qui peut tre lenvoi dun message, la rception dun message, lappel dune opration (envoi dun message, attente dune rponse), ou une transformation de donnes. L'activit est dfinit par la combinaison de Services Web. BPEL utilise WSDL pour dcrire les actions d'un processus. Business Process Management. Terme gnrique dsignant la fois la modlisation et la traduction, l'aide d'un "moteur", des processus modliss dans la ralit de l'entreprise. A cela s'ajoute, bien videmment, des outils indicateurs, tableaux de bord de suivi de l'excution des processus et d'valuation de leur performance (voir BAM). Acronyme pour Business Process Management Notation (Notation pour la Gestion des Processus Mtiers) Utilise pour la modlisation graphique des processus mtier (pas lexcution). Particulirement pertinente dans le cadre de la modlisation des processus, de leur analyse et de leur simulation. Cette notation est sous le contrle de l OMG (Object Management Group). Composant de service Composant logiciel fournisseur de service divis en vue externe et vue interne. La vue externe est la partie service du composant, qui peut tre utilis par dautres lments du systme, jouant le rle de consommateur de service. La vue externe ( ou spcification de service) est constitue par un ensemble doprations de service regroupes en interface, le contrat et toutes les informations lies son utilisation (voir QoS et SLA). Composant de service qui donne un accs aux informations lies un objet mtier cl. Les oprations sont de type CRUD (Create, Read, Update, Delete). Composant de service qui prend en charge un processsus de traitement, ou une adaptation une vision mtier particulire, sous forme de composition de services. Composant de service ddi linteraction entre acteurs humains et le systme. Il prend en charge les IHM et la gestion de la session utilisateur.

BPEL

BPM

BPMN

Composant Entit

Composant Fonction

Composant Prsentation

www.softeam.fr

SOA : Architecture Logique. V1.0

fvrier 2007

Page 28 sur 30

Composant Processus Composant Public Composant utilitaire MDA www.omg.org/

Composant de service qui automatise un processus mtier. Composant de service qui assure les changes avec les systmes externes (B2B, e-business) Composant de service ddi des fonctions transverses (annuaire, messagerie, ditique) non spcifiques au mtier de lentreprise. Le MDA est une dmarche de ralisation de logiciel, propose et soutenue par l'OMG. L'ide fondamentale est que les fonctionnalits du systme dvelopper sont dfinies dans un modle indpendant de la plate-forme (Platform Independent Model, PIM), en utilisant un langage de spcifications appropri, puis traduites dans un ou plusieurs modles spcifiques la plateforme (Platform Specific Model, PSM) pour l'implmentation concrte du systme. Organization for the Advancement of Structured Information Standards. Consortium international qui travaille pour la normalisation et la standardisation de formats de fichiers ouverts bass notamment sur XML. LOMG (Object Management Group) est une association amricaine but non-lucratif cre en 1989 dont l'objectif est de standardiser et promouvoir le modle objet sous toutes ses formes. LOMG est par exemple linitiative des normes UML et CORBA ou encore MDA et BPMN. Organisme international qui propose des normes SOA : SCA (Service Component Architecture) et SDO (Service Data Objects). Partenaires : BEA, IBM, IONA, Oracle, SAP, SUN, Siemens, TibCo.

OASIS www.oasis-open.org

OMG www.omg.org/

Open SOA www.osoa.org

Processus de traitement Processus mtier

Processus qui reprsente le droulement dune activit localise, de courte dure et non interruptible. Processus de bout en bout de lentreprise, qui dlivre une valeur ajoute tangible lextrieur par une collaboration de plusieurs units et acteurs. Un processus mtier peut avoir une longue dure de vie et est potentiellement interrompu. Voir Processus mtier Quality of service. La qualit de service est une notion ne chez les oprateurs de tlcommunications vers 1997. On parle de contrat de niveau de service quand une entreprise exige de son oprateur une haute disponibilit de son rseau. La gestion du niveau de service s'est, depuis, tendue au systme d'information. Service Component Architecture (voir open SOA) Service Component Architecture aims to provide a model for the creation of service components in a wide range of languages and a model for assembling service components into a business solution activities which are at the heart of building applications using a service-oriented architecture.

Processus mtier transverse QoS

SCA

Silo

Terme utilis pour dsigner une dcoupe verticale dun systme, par applications (silos applicatifs). Application architectures are typically created as independent

www.softeam.fr

SOA : Architecture Logique. V1.0

fvrier 2007

Page 29 sur 30

work efforts that are usually owned by a specific organizational domain or entity. Applications are usually built to automate business applications within a single organization domain. Those single-domain applications are said to be "siloed." Avoiding common pitfalls in SOA adoption, Tilak Mitra, Executive IT Architect, IBM, juin 2006. SLA Service Level Agreement. Contrat dfinissant les engagements du fournisseur de service quant la qualit de sa prestation, et les pnalits engages en cas de manquement. Cette qualit doit tre mesure selon des critres objectifs accepts par les deux parties. Ex : temps de rtablissement du service en cas d'incident Type de Donne dEchange. Structure des informations changes par les messages ou les flux inter composants. Type des paramtres des oprations de service. Par opposition, les donnes persistantes sont les informations contenues dans les bases de donnes. Le World Wide Web Consortium, abrg W3C, est un consortium fond en octobre 1994 pour promouvoir la compatibilit des technologies du World Wide Web telles que HTML, XHTML, XML,, CSS, PNG, et SOAP Il s'agit d'une technologie permettant des applications de dialoguer distance via Internet, et ceci indpendamment des plates-formes et des langages sur lesquelles elles reposent. Pour ce faire, les services Web s'appuient sur un ensemble de protocoles Internet trs rpandus (XML, HTTP), afin de communiquer. Cette communication est base sur le principe de demandes et rponses, effectues avec des messages XML. Les services web sont dcrits par des documents WSDL (Web Service Description Language), qui prcisent les oprations pouvant tre invoques, leurs signatures et les points d'accs du service (URL, port .). Les services Web sont accessibles via SOAP, la requte et les rponses sont des messages XML transports sur HTTP.

TDE

W3C http://www.w3.org/

Web service

www.softeam.fr

SOA : Architecture Logique. V1.0

fvrier 2007

Page 30 sur 30