Architecture soa (architecture orientée services)

1.6.5 Décomposition des 3 principales couches SOA

1.6.5.1 La Couche Organisationnelle

Qui mieux que les experts fonctionnels détient la connaissance technique et métier ? La mise en commun de ce savoir est un des moyens possibles pour mettre en mouvement une cellule transverse dédiée à la gestion des services métiers.

Application Comptabilité

Application Contrôle de Gestion

Application Service aux Coopérateurs

Services Métiers

Normalisation

Assistance

Illustration 47 : Cellule transverse chargée de gérer les services

Cette organisation ne nécessite pas la constitution d'une équipe uniquement dédiée à cette tâche et cela ne remet pas non plus en cause l'organigramme de l'entreprise. Cette cellule est vivante dans le sens où elle peut varier de taille et de constitution en fonctions des enjeux stratégiques ou des nouveaux projets. Dans le cas où le SI est constitué de bloc applicatifs nombreux, il peut être envisagé de faire grossir cette cellule qui, peu à peu, redessine les rôles des équipes projet. Elle devient la plaque tournante vis à vis des projets dans le sens où elle se charge de gérer la partie technique qui met à disposition les services aux consommateurs, mais aussi dans le sens où elle apporte aux developpeurs les éléments pour mettre en oeuvre ces services. Enfin, cette cellule constitue les procédures, les normes permettant d'identifier les services, les outils à utiliser, les modèles, un vocabulaire commun, et tout arbitrage concernant les services. Elle aura en charge, la mise à jour de la nomenclature de services afin de disposer à chaque nouvelle étude d'une vue exhaustive et fiable. Ainsi la cartographie macroscopique doit être complètée d'une vue complète des services disponibles.

1.6.5.2 La Couche Fonctionnelle

Cette couche est l'occasion de partager certains modèles UML avec les métiers, tels que les diagrammes de classe (cf le langage de contrainte), d'activité, les cas d'utilisation de Jacobson109(*), et donc de renforcer le travail de modélisation ... Mais avant le déploiement de nouveaux services, il faudrait connaître le budget alloué et calculer le gain escompté. Même si aucun déploiement de service n'est prévu, il est important que soient notifiées dans les futurs appels d'offre ce qui est jugé comme faisant partie des «bonnes pratiques SOA» et ne pas renoncer, aux solutions d'échange XML par exemple. Cette démarche repose sur l'utilisation d'outils collaboratifs dont ceux nécessaires au suivi des contrats de service. Avant une nouvelle écriture, il faut vérifier si le référentiel peut ou non fournir le service recherché.

Fiche Service

Nom du service

Version

Description fine

Cas d'usage

Responsable

Date de création

Date de dernière modification

Nombre d'invocation depuis l'origine

Nombre d'invocation depuis le début de l'année

Nombre d'invocation des 30 derniers jours

Horaire de disponibilité

Performance attendue

Sécurité

Fraîcheur de l'information

Opération N

Format entrée / sortie

Exceptions

SLA (performance, sécurité)

Illustration 48 : Proposition de fiche de service

Bloc applicatifs

La première étape consiste à isoler les blocs applicatifs du SI de façon très macroscopique, puis pour chacun de ces blocs, de séparer les grandes fonctions de communications des fonctions internes. Ainsi, la réutilisation de service interne à un bloc applicatif pourra être mise en oeuvre.

Illustration 49 : Cartographie macroscopique réalisé sous Netbeans

L'approche SOA consiste à modéliser une cartographie des données sous forme de Catégories^110(*), en rapport avec le concept UML de package, émis par Grady Booch111(*). Chaque catégorie représente un groupe d'objets métiers à partir duquel les services seront construits. Autrement dit, un service sémantiquement ne peut concerner qu'une seule catégorie. Une fois administrés, il est alors possible de réutiliser les services et de les enrichir au fur et à mesure de la vie du SI. Cette classification permet d'ajouter de la stabilité à la cartographie d'autant plus qu'il répond aux diverses règles (non chevauchement, classe maîtresse (ici : Client, Produit) etc ...).

* ¹⁰⁹ Jacobson : contributeur important à la fois du langage UML et du RUP (Rational Unified Process) en 1986.

* ¹¹⁰ Le concept de catégorie : agrégat de classes du diagramme de classes respectant des propriétés strictes de stabilité, de continuité et de consistance métier. Pivot de la SOA il existe depuis longtemps dans UML au travers du concept d'objet métier.

* ¹¹¹ Grady Booch : créateur d'une approche d'analyse et de conception orientée objet portant son nom : la méthode booch ; en collaboration avec James Rumbaugh, créateur de la notation OMT, et avec Ivar Jacobson, créateur de la méthode OOSE ; il est à l'origine du langage de modélisation UML.