Livre blanc: Mise à jour de RUP pour l'architecture orientée services
Le présent document décrit une mise à jour du processus RUP (Rational Unified Process) dont le but est de proposer des conseils destinés à l'architecte logiciel et au concepteur dans l'optique du développement d'un modèle de services, lequel représente un portefeuille de services pouvant servir de base à des tâches d'implémentation déjà présentes dans RUP.
Relations
Eléments connexes
Description
Description principale

Par Ali Arsanjani, Simon Johnston, John Smith, IBM © Copyright 2005, 2006 by IBM Corporation. Tous droits réservés.

Rubriques

Introduction

Ce livre blanc décrit la troisième mise à jour du processus RUP (Rational Unified Process) pour l'architecture orientée services (SOA). Cette mise à jour représente un jalon dans les instructions RUP liées à l'architecture SOA car elle fournit une méthode unifiée qui combine le contenu du processus RUP précédent pour SOA au contenu de la méthode Modélisation et architecture orientées services (SOMA) d'IBM Global Business Services (GBS). La méthode SOMA a été utilisée avec succès par IBM dans un certain nombre de contrats client et, alors qu'elle était initialement développée par l'exploitation de la méthode GS (Global Services Method) IBM existante, il semblait clair que, dans le domaine de l'architecture SOA, tant IBM que ses clients bénéficieraient davantage d'une approche de méthode unifiée que de deux méthodes distinctes. Lorsque l'on observe les deux méthodes, il est clair que les auteurs poursuivaient des buts analogues et qu'ils ont structuré les méthodes de façon similaire - en fait, les deux équipes se sont rencontrées en 2004 et ont modifié les deux méthodes afin de synchroniser leur terminologie. Si cette synchronisation n'est, en fin de compte, pas surprenante puisque les deux méthodes mettent l'accent sur les activités pragmatiques de développement d'une solution orientée services, on a noté qu'une infrastructure préfabriquée pouvait être extraite et permettre de décrire les deux méthodes à un niveau général.

Les clients familiarisés avec Classic RUP peuvent consulter le Concept : Développement de solutions orientées services.

Le personnel IBM familiarisé avec SOMA peut consulter la Feuille de route : Transition d'IBM SOMA.

Présentation de l'intégration de la méthode

Le diagramme suivant illustre l'infrastructure préfabriquée mentionnée plus haut. Il représente un ensemble d'activités neutre de méthode requis par tous les processus pour le développement de solutions orientées services. Ce diagramme simplifie considérablement le contenu des deux méthodes mais il représente clairement les activités essentielles de ces dernières : identification de service, spécification de service et réalisation de service. Dans le domaine des produits de travail, il était clair que l'alignement conceptuel a été considérable. Des produits de travail similaires ont été requis avec des rôles et des intervenants analogues mais, dans certains cas, ils ont été réalisés différemment, par exemple en tant que modèle UML ou document Word. Cet alignement semblait relativement simple à réaliser. En général, les influences majeures correspondent bien aux activités même si, évidemment, la réalité est que toutes les exigences ont un impact sur toutes les activités.

 Présentation de la méthode

Figure - Infrastructure préfabriquée de la méthode SOA unifiée

Il est possible de développer un niveau supplémentaire de l'infrastructure préfabriquée car les activités identifiées ici sont prises en charge par un certain nombre de techniques et l'intégration des méthodes a réellement lieu dans le domaine des techniques détaillées. Le présent livre blanc ne détaille pas l'intégration des techniques, toutefois, il est important de noter que le développement d'une méthode unique et cohérente entraîne des modifications dans les deux méthodes utilisées en tant que points de départ pour assurer que le lecteur verra une cohérence dans les définitions de concept, d'approche, de tâche et de produit de travail. Par exemple, l'une des décisions qui apporte une niveau de cohérence au contenu consiste à utiliser le produit de travail RUP pour SOA existant : Modèle de services en tant que source principale à partir de laquelle des rapports textuels et des tableaux peuvent être créés pour fournir les produits de travail attendus par les spécialistes SOMA. En général, la valeur de ces changements réside dans l'ajout de sémantique au modèle de services UML lequel peut être utilisé pour développer des modèles de spécification et de réalisation de services. Toutefois, le modèle de services doit être étendu pour capturer les informations supplémentaires requises par les produits de travail SOMA existants ; par exemple, le produit de travail : Spécification de service a été étendu à l'aide de source et d'état de propriétés supplémentaires qui capturent des informations couramment utilisées par les spécialistes SOMA.

Principes

Le plugin est basé sur les idées directrices suivantes :

  1. Permettre une croissance ultérieure ; réduire ou éviter les contraintes sur les ajouts ultérieurs d'activités, de produits de travail, de rôles, etc.
  2. Gérer la possibilité d'ajouter des extensions propriétaires aux méthodes commerciales actuelles ou futures : par exemple, des extensions spécifiques du secteur d'activité ou des actifs dans SOMA ; du contenu propriétaire peut également être ajouté à l'infrastructure préfabriquée afin d'optimiser le service.
  3. Converger sur la confrontation avec le client et la messagerie IBM interne
  4. La méthode doit rester indépendante des outils mais fournir des instructions d'intégration pour les guides d'outils, en favorisant le portefeuille IBM
  5. Mettre en oeuvre les capacités des activités de la méthode plutôt que de les restreindre en fonction d'une méthode GS ou RUP ou d'autres méthodes existantes.

Portée

La présente mise à jour du processus RUP a pour but de proposer des conseils destinés à l'architecte logiciel et au concepteur dans l'optique du développement du modèle de services, lequel représente un portefeuille de services pouvant servir de base à des tâches d'implémentation déjà présentes dans RUP. Nous décrirons également ici la relation entre la modélisation métier et le modèle de services. De nombreux projets d'architecture orientée services (SOA) utilisent des modèles de processus métier pour comprendre leurs exigences fonctionnelles métier et les services nécessaires à la prise en charge d'un processus.

La portée de cette mise à jour a été brièvement traitée dans l'introduction ; voici à présent l'ensemble des exigences et des instructions relatives à la portée, utilisées pour mener à bien ce projet.

  • Optimiser le processus RUP existant : dans ce cas, cela signifie que, lorsque cela est possible, nous devons décrire de nouvelles tâches et de nouveaux produits en relation avec ceux existant déjà dans RUP et qu'il n'est pas superflu d'ajouter de nouveaux concepts. De plus, de nouveaux éléments doivent être ajoutés de façon à s'intégrer au flux global de RUP.
  • Prévoir de futures fonctionnalités d'outils : bien que RUP ne dépende pas d'outils, il faut prendre conscience qu'il est inutile de développer du contenu dans des domaines qui ne disposeront jamais d'outils ; il ne faut pas non plus conclure qu'il est inutile d'écrire une rubrique car l'outil n'est pas encore commercialisé, mais que cela ne saurait tarder.
  • Intégration d'autres connaissances IBM en SOA : il est évident que d'autres groupes de travail au sein d'IBM possèdent des connaissances pouvant être optimisées, exploitées et ajoutées aux concepts, instructions et pratiques que nous présentons ici.
  • Modifications de la portée de l'analyse et de la conception : nous avons étudié la littérature technique décrivant l'application de l'architecture orientée services à la conception métier et l'impact de ce type d'architecture sur les modèles métier, l'organisation opérationnelle et l'intégration métier. Nous avons également observé l'incidence que ce type d'architecture a souvent sur l'implémentation, le déploiement et la gestion opérationnelle. Cette portée étant trop large pour la première itération, nous avons uniquement traité les questions d'architecture et de conception.
  • Fournir une base : il s'agit de la première itération. Dans les itérations suivantes, il est très probable que des conseils supplémentaires soient ajoutés au cadre de base présenté ici, ainsi qu'à la relation établie entre ce contenu et le reste du processus RUP.
  • Identifier les changements à effectuer sur cette base, mais les reporter à une édition ultérieure : nous sommes conscients que certains des concepts présentés ici conviendraient mieux avec une terminologie ou d'autres changements mineurs effectués sur le processus RUP de base. Même s'il serait utile de modifier le processus RUP, cela aurait des implications très poussées et prendrait beaucoup plus de temps.

Décisions clés

Notre intention est de faire de ce contenu une partie intégrante du processus RUP de base dans la prochaine édition commerciale du produit. D'ici là, nous voulons mettre ce contenu à la disposition des clients ; il sera donc mis en forme en tant que plug-in RUP et pourra être téléchargé.

En parallèle, des changements sont effectués sur la discipline de modélisation métier afin de renforcer la relation entre la modélisation métier et l'architecture orientée services ; il a cependant été décidé d'attendre que les modifications affectant cette discipline soient terminées avant de compléter le plug-in SOA. L'intégration de ces deux ensembles de changements sera réalisée pour l'édition commerciale.

Plusieurs idées clés sont tirées de Service-Oriented Modeling and Architecture (SOMA) (Modélisation et architecture orientées services) d'IBM Global Services. Bien qu'il ne soit pas possible d'intégrer ici l'ensemble des idées et conseils présentés dans le document SOMA, principalement lorsqu'ils sortent du cadre que nous avons établi, il nous a été d'une grande utilité dans la réalisation de ce travail.

Des principes nouveaux ont été introduits, dont les concepts ayant influencé notre approche du reste du contenu, en particulier le concept du portefeuille de services et de la vue de l'ensemble des services fournis par une entreprise.

Remerciements

Les auteurs souhaitent remercier les personnes suivantes pour leur précieuse contribution à ce travail. Alan Brown et Sky Matthews, pour leur soutien et pour avoir révisé ce document. Merci à Eoin Lane, Steve Graham, Ed Kahan et Grant Larsen, non seulement pour leurs commentaires, mais également pour les nombreux exemples qui nous ont beaucoup aidé, et parfois décontenancés. Nous souhaitons également remercier nos collègues ayant travaillé sur l'effort SOMA, Ali Arsanjani, Luba Cherbakov et Kerrie Holley. Du matériel supplémentaire a été inclus dans la présente révision par Maryann Hondo, Architecte de sécurité pour les services Web chez IBM.

Enfin, nous adressons nos remerciements à Claus Torp Jensen et à son équipe de la Danske Bank pour nous avoir parlé ouvertement et avec franchise de l'expérience de sa banque dans l'application à un contexte bien réel de l'architecture orientée services.