Introduction
Il existe trois principaux types d’architecture logicielle pour réaliser des systèmes distribués.- Object-Oriented
- Resource-Oriented
- Service-Oriented
Les 3 styles d’architecture
| Objet | Ressource | Service | |
|---|---|---|---|
| Granularité | Instance de classe | Instance de ressource | Instance de service |
| Caractéristique | Méthode/Paramètre | Requête/URL | Requête/Message |
| Adressage | Un seul objet | Une URL par ressource | Un point par service |
| Interface applicative | Spécifique à l’objet | Générique (http) | Spécifique au service (WSDL) |
| Format de données | Spécifique | Aucun | Schéma XML |
Façade
Avec l'avènement des architectures orientées services, il est apparu un ensemble de bonnes pratiques destinées à cloisonner les applications par le biais de façades. Une façade est une représentation technique d'une interface fonctionnelle. En pratique, on dit qu'une façade constitue le contrôleur des cas d'utilisation d'UML. Elle assure les échanges entre la couche cliente et les services applicatifs.Conception Objet ou Service ?
L'immense majorité des architectures orientées services s'appuieront sur des frameworks orientés objets. Bien que ces deux paradigmes ne soient pas antinomiques, un certain nombre de questions se posent quant à leur cohabitation.Manières d'exposer un traitement
Prenons un cas concret, une application de gestion bancaire dont les spécifications fonctionnelles sont les suivantes: un client possède un compte dont le type peut être un CODEVI, ou un compte courant. Chaque compte comporte un ensemble de propriétés (libellé, plafond, ...) et expose des services (Debiter(), Crediter(), CalculImposition(), ...).Dans un modèle d'architecture n-tiers classique, voici les deux conceptions possibles.
1) Architecture Orientée Objet: placer les traitements dans les objets métiers
Après analyse des cas d'utilisation, la classe GestionCompte est créée et contient deux méthodes:
- Crediter()
- Debiter()
L'appel aux services Crediter() et Debiter() est délégué dans l'objet métier Compte. En pratique s'il n'est pas rare de trouver ce type de conception, l'approche qui prévaut généralement consiste à implémenter les services proprement dits dans le contrôleur de cas d'utilisation (GestionCompteFacade). Dans ce cas, le contrôleur délègue les services aux méthodes polymorphiques Crediter() et Debiter() présentes dans les classes du modèle de domaine.
2) Architecture Orientée Services: placer les traitements dans la couche de service
Dans cette approche, les méthodes Crediter() et Debiter() se chargent d'accéder aux propriétés des comptes afin de vérifier la solvabilité du client. Si la démarche est similaire à la précédente, la philosophie est quelque peu différente. On enlève les méthodes Crediter() et Debiter() de la classe Compte pour les déplacer vers la couche de service.
L'architecture Orientée Services (SOA)
L'exemple précédent montre qu'il est très difficile d'exposer un service polymorphique par le biais d'une seule méthode dans la façade fonctionnelle. Cette approche va à l'encontre de la philosophie de l'héritage et nuit clairement à l'évolutivité du code.Dans l'exemple 1) d'architecture orientée objet nous avions une seule méthode pour représenter l'ensemble de nos trois entités métier. Avec l'exemple 2) d'architecture orientée services, nous obtenons une liste de méthodes spécifiques pour un type donné. De plus et contrairement à l'exemple 1) de l'orientation objet, l'ajout d'un nouveau compte nécessitera plus tard la modification de la couche de service. Il faudra perpétuellement synchroniser la façade avec l'ajout de nouvelles entités métiers. En résumé, lorsqu'on s'interdit d'insérer du code dans les objets métier, il est difficile de concilier vertus de l'héritage et exposition de services.
Alors, pourquoi tant de SOA ?
L'orientation services est un complément important de la programmation objet et qui applique les leçons apprises de la démarche composants, de l'approche orientée messages et du traitement d'objets distribués. L'orientation Services diffère de l'orientation Objet principalement dans la façon dont elle définit le terme application. Le développement orienté objets se focalise sur les applications conçues à partir de différentes bibliothèques interdépendantes de classes. Le développement orienté services se concentre lui sur un système conçu comme un ensemble de services autonomes. Cette différence a un impact profond sur l'approche à adopter dans ce type de développement ... (Don Box, équipe Microsoft)En résumé, cette nouvelle vision de l’intégration des applications est l'argument majeur pour les entreprises afin de maintenir leur compétitivité et leur croissance.
Les pièges du SOA
Un projet SOA peut échouer parce que les développeurs adoptent une approche ascendante c'est à dire une orientation objet. La création d’une architecture axée sur les services aux seules fins de créer ce genre d’architecture, sans lien avec le cadre de fonctionnement de l’entreprise, s’avère un projet sans fondement sur des principes organisationnels ou des lignes directrices, ce qui donne une mise en œuvre chaotique, sans pertinence pour l'entreprise. Par ailleurs, un mégaprojet d’architecture axée sur les services qui est fondé sur une approche descendante requiert tellement de temps que, lorsqu’il est terminé, il ne répond plus aux besoins de l'entreprise... (Microsoft, l'équipe SOA)Il reste encore des zones d'ombre, non seulement lors de la défintion du rôle d'un service, mais aussi comme dans l'exemple précédent à travers l'exposition de méthodes polymorphes. Pas de solution miracle, il incombera de créer l'architecture la plus souple et la moins contraignante pour chaque nouveau projet.
Liens intéressants
- Architecture logicielle: Questions/Réponses
Aucun commentaire:
Enregistrer un commentaire