L'année dernière, Ganesh Prasad a partagé ses réflexions sur SOA lors de la QCon. Au début de cette année, il a étayé la manière de penser en SOA dans un article, comme étant une pensée orientée dépendances (Dependency Oriented Thinking) :
SOA est la science de l'analyse et de la gestion des dépendances entre les systèmes où « la gestion des dépendances » revient à éliminer les dépendances inutiles et formaliser les dépendances légitimes en contrats faciles à comprendre.
Il a également élaboré un schéma pour illustrer ce concept :
Selon Ganesh :
Au niveau de la couche business, l'accent mis sur les dépendances nous oblige à rationaliser les processus et les rendre plus légers. Les processus business doivent être esquissées selon la vision de l'organisation (son idée de l'Utopie), sa mission (sa stratégie menant à cette Utopie) et la large gamme de fonctionnalités qu’il a besoin d'avoir en place pour exécuter ces stratégies (Gestion du produit, Ingénierie, Marketing, Ventes, etc.) [...] Au niveau de la couche application, on essaie de regrouper les opérations. Notez que la couche business a déjà défini le regroupement de l'exécution des opérations selon des processus. Au niveau de la couche application, nous devons procéder de manière plus statique. Quelles sont les opérations qui vont ensemble et celles qui ne le peuvent pas ? C'est la question à poser sur les dépendances au niveau de cette couche. Cependant, la réponse se trouve uniquement au niveau de la couche d'Information, juste en dessous, car les opérations « appartiennent » seulement à un même ensemble lorsqu’ elles partagent un même modèle de données. En fait, il y a deux groupes de modèles de données, les « externes » et les « internes ». Les modèles de données « internes » de n’importe quel système sont également connus comme « modèles de données de domaine », et ceux-ci ne sont jamais visibles par d'autres systèmes. En revanche, un modèle de données « externe » d'un système, appelé « modèle de données d'interface » est toujours exposé et partagé avec d'autres systèmes.
Récemment, Ganesh a eu la chance de mettre ces idées en pratique et d’examiner les cas d'utilisations réels à la lumière de cette approche. Pour chaque scénario ayant eu un échec, Ganesh suggère que le coupable peut être retracé à travers un ou plusieurs principes de dépendance violés. En conséquence, Ganesh estime qu'une organisation qui suit les règles obtiendra « une SOA réussie ». Bien sûr, nous avons beaucoup d'autres exemples au fil des années où SOA a échoué/réussi avec les tentatives correspondantes aux principes et règles à suivre pour la faire réussir. Les principes décrits par Ganesh peuvent être classés selon les quatre couches au niveau desquelles ils opèrent :
Couche business : (1) Traçabilité - Appliquer la gouvernance de base, « faire en sorte que tout ce qui est fait ait un sens vis-à-vis de la vision de l'organisation. » (2) Le minimalisme - remettre en questions les hypothèses. (3) Vision Domaine - comprendre la vraie nature du business, « ré-imaginer l’activité à partir des principes fondamentaux ».
Couche application : (4) Cohésion et couplage - « Ce qui va ensemble devrait aller de pair avec des liens minimes entre des systèmes différents ». (5) Implémentation contre Exposition - « regrouper les opérations qui partagent un modèle de données domaine et une logique métier en Produits, et celles qui partagent un modèle de données d'interface en Services ». (6) les Variantes et les Versions - « Identifier les variantes multiples et simultanées de chaque opération logique et établir un moyen permettant des changements de logique et d'interfaces ».
Couche information (données) (7) : Interne contre Externe - « Faire la distinction entre modèle de données d'interface et celui des données de domaine ». (8) Contenu contre Contexte - « Séparer les éléments de données essentielles du modèle de données d'interface et ses éléments qualificatifs ». (9) Abstrait contre Concret - « Créer une hiérarchie de type de données à la fois pour le contenu et pour les éléments de contexte ».
Technologie en couches : (10) Regroupement des dépendances - « Éviter d'introduire de nouvelles dépendances entre les composants indépendants dans le processus de mise en œuvre de la logique métier ». (11) Liaison tardive - « Retarder les dépendances incontournables autant que possible ». (12) Le bon outil de travail - « Mettre en œuvre la logique en utilisant le mécanisme le plus approprié ».
Que pensez-vous de ces principes et le concept de la pensée orientée dépendance pour SOA ? Pourraient-ils avoir contribué à un projet SOA sur lequel vous avez travaillé ? Envisageriez-vous de les utiliser dès maintenant, ou préfériez-vous les modifier en fonction de vos propres expériences ?