Description principale |
Par Ali Arsanjani, Simon Johnston, John Smith, IBM © Copyright 2005, 2006 by IBM Corporation. Tous droits
réservés.
Rubriques
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.
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.
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.
Le plugin est basé sur les idées directrices suivantes :
-
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.
-
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.
-
Converger sur la confrontation avec le client et la messagerie IBM interne
-
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
-
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.
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.
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.
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.
|