Chapitre 3 : Modélisation orientée services

Chapitre 3 : Modélisation orientée Services

1. Introduction
L’architecture orientée service (SOA) s’est imposée aujourd’hui comme un thème majeur
pour les systèmes d’information d’entreprise. Plus qu’une nouvelle technologie ou méthode,
c’est la convergence de plusieurs approches existantes, et l’émergence d’un style
d’architecture et de gouvernance de SI.
2. Objectifs de démarche de conception SOA
La démarche de conception des services dans SOA a pour objectifs :
- D’identifier les services ;
- De catégoriser les services ;
- De regrouper les services ;
- De formaliser les services.
Le premier chantier servira à identifier les services concourant à la cible d’architecture. Ces
services peuvent être issus d’une conception (refonte, re-conception) ou d’interfaces masquant
l’existant.
Une fois identifiés, les services doivent être « typés », on distingue trois grandes catégories :
- Services organisationnels : généralement issus des cas d’utilisation ou actes de
gestion métiers (par exemple : ouvrir un compte bancaire, passer une commande, etc.).
Les règles contenues dans ces services sont intimement liées à la structure de
l’entreprise et donc plus sujettes à changement. Les services organisationnels sont les
services de haut niveau. Ce sont eux qui orchestrent d’autres services, services
organisationnels ou services métiers. Les services organisationnels sont ceux exposés
à un utilisateur via une IHM.
- Services métier : contenant les règles métiers ou liés à la législation donc réputés
stables. Ces services ne sont normalement pas accessibles directement par les
utilisateurs. Ils sont orchestrés par les services organisationnels. Leur complexité est
limitée et ils doivent répondre à des besoins élémentaires simples. On trouve dans
cette catégorie par exemple « lire contrat » « recherche client », « calculer montant
facture ».
- Services techniques : purement techniques et dont l’existence est pilotée et décidée
par l’informatique et non par le métier.

Page 1
Chapitre 3 : Modélisation orientée services

Pour éviter d’avoir une architecture avec plusieurs centaines voire milliers de services «
flottants », il est nécessaire de les regrouper au sein de composants. Généralement on
considère qu’un composant contient une dizaine à une quinzaine de services maximum. Pour
plus de souplesse, ces composants peuvent aussi être regroupés au sein d’autres composants et
ainsi de suite, toujours en respectant la métrique de 10 à 15.
3. Démarches de conception de SOA (voir l’expsé)
- orienté processus,
- orienté objet,
- orienté application

Page 2
Chapitre 3 : Modélisation orientée services

4. Approches et Méthodes de développement des services web

Il n’existe pas une méthode universelle de développement d’un service web côté fournisseur
ou côté client, mais bien plusieurs méthodes selon la situation dans la quelle nous nous
trouvons.

Approches et Méthodes de développement vu par le fournisseur de services

La méthode de développement du point de vue de fournisseur est conditionnée par la

préexistence ou non de l’interface du service et de l’implémentation du service :

a. L’approche green-field, que l’on peut traduire par départ de zéro, est la situation la
plus simple, où rien n’existe et tout est à faire : dans cette situation, le développeur
crée l’implémentation du nouveau service, à partir de laquelle il génère ensuite
l’interface. Dans cette situation, l’interface et l’implémentation sont la propriété de
fournisseur de service.
b. L’approche top-down : est utilisée lorsque l’interface est déjà définie. Dans cette
situation, le développeur produit une nouvelle implémentation de cette interface, ,
(éventuellement à l’aide d’un générateur de code). Cette situation est susceptible
de se produire lorsque l’interface du service est standardisée par une autorité
métier par exemple. Dans ce cas, seule l’implémentation est propriété de
fournisseur.
Cette approche est plus adéquat pour démarrer un nouveau projet
c. L’approche bottum-up : Correspond à la situation inverse. Ici, c’est
l’implémentation du service web qui existe déjà (il peut s’agit d’une classe java ou
c++, d’un composant COM, Corba ou EJB, etc). Dans cette situation, le
développeur expose une nouvelle interface, éventuellement à l’aide d’un
générateur de code, la plupart du temps par introspection du code exécutable ou
par inspection des descripteurs de déploiement. Dans cette situation, l’interface et
l’implémentation sont la propriété de fournisseur du service.
Cette approche est plus adéquate pour réutiliser l’existant non “SOA ” .
d. L’approche meet-in-the-middle: correspondant à la situation où l’interface du
service existe déjà et où l’application qui sera utilisée pour l’implémenter existe
également. Dans cette situation, le développeur doit établir une correspondance
entre l’interface de l’application et celle du service : ceci peut être facilité par

Page 3
Chapitre 3 : Modélisation orientée services

l’écriture d’une classe d’encapsulation de l’implémentation du service existant.

Dans ce cas, seule l’implémentation est la propriété du fournisseur de service.
Remarque :
Dans la pratique on utilise rarement une seule approche. Une bonne solution est de mixer les
deux démarches, Top-Down pour une portion du S.I. qui est en cours de refonte (ou à
refondre) et Bottom-Up pour le reste, ce qui concourt au bon fonctionnement de l’ensemble au
quotidien :
– Faire l’analyse Top-down sans se préoccuper de l’existant ;
– Faire l’analyse Buttom-up en ne considérant que l’existant ;
– Comparer les services “remontés” avec ceux déduits des processus ;
– Faire les compromis nécessaires pour réutiliser le maximum de code.

Page 4
Chapitre 3 : Modélisation orientée services

5. Méthodes et outils permettent de mettre en oeuvre une architecture

orientée services

5.1. Méthodes de conception des services

• SOMA (IBM)
• SODA (De Gamma)
• Praxeme (Unilog Management et Orchestra Networks)
5.2. Modeleurs de processus
5.2.1. Outils de modélisation des processus métier

− IBM WebSphere Business Modeler

− Bull Bonita

− De Gamma BPM

− MEGA

− Aris

− Corporate Modeler

− WinDesign

− Power AMC

− Popkin System Architecture

5.2.2. Moteurs d’exécution de processus

• Plate-forme d’intégration
– IBM Websphere Process Server
– BEA Weblogic Integrator/Acqualogic
– Microsoft Biztalk
– De Gamma Workflow
– Oracle BPEL PM
– Bull Orchestra
– SAP “Netweaver”
– Apache ODE

Page 5
Chapitre 3 : Modélisation orientée services

• ESB
– IBM Websphere ESB
– Celtix hosted on ObjectWeb/IONA Technologies
– OpenESB (java.net)
– Mule (codehaus.org)
– Sonic ESB
– EBM Web Sourcing Distributed Petals Bus (on OW2)
• Composants de sécurité
− Oracle Web Service Manager
− Oblix

Page 6
Chapitre 3 : Modélisation orientée services

6. Conclusion
Il n’existe pas une méthode universelle de développement d’un service web, mais bien
plusieurs méthodes. La bonne solution est de mixer différentes méthodes afin d’avoir un bon
résultat.

Page 7