Il ne faut pas oublier que très peu de solutions sont construites sans prendre en compte les applications existantes
qui fourniront des fonctionnalités de prise en charge de la solution ou avec lesquelles la solution doit interagir. De
ce fait, il est donc essentiel que les applications existantes qui seront réutilisées dans une solution soient
cataloguées et que leurs fonctionnalités soient identifiées. Dans le cas d'une solution orientée services, il existe
plusieurs méthodes d'intégration de nouveaux services à la fonctionnalité existante. Elles sont illustrées dans la
figure ci-dessous :
-
Encapsuler une fonction existante comme un service. Dans ce cas, le but est de conserver la fonction en
l'état tout en utilisant des outils ou des logiciels intermédiaires (middleware) pour l'exposer comme un service.
Par exemple, IBM permet d'exposer des transactions CICS existantes comme des service Web SOAP.
-
Encapsuler une fonction existante et la remplacer par un service. Dans ce cas, la fonction est encapsulée
comme indiqué ci-dessus, mais on utilise la spécification de service qui en résulte pour redévelopper le service à
une date ultérieure, en remplaçant le service d'origine et en redirigeant les clients vers la nouvelle
implémentation.
-
Utiliser un adaptateur plus flexible pour l'appel de service. Il n'est parfois pas possible d'encapsuler une
fonction et de l'exposer comme un service, mais il est possible de l'encapsuler dans un élément mieux adapté à
l'intégration, par exemple une interface MQI ou l'architecture J2EE Connector. Cela permet à de nouveaux services
d'accéder à la fonction en place.
-
Intégrer la fonction dans le service. Dans certains cas, il est évidemment possible pour le nouveau service
d'accéder à la fonction existante, en utilisant simplement cette fonction comme un composant logique de
l'implémentation du service.
Prenez en compte le fait que les troisième et quatrième options offrent les meilleures performances en termes de
flexibilité car elles utilisent la fonction existante, mais cessent d'exposer la fonction en l'état aux clients.
Parallèlement, les première et deuxième options peuvent faire apparaître des problèmes d'encapsulage des fonctions en
tant que services, car les performances des protocoles de service Web et les disparités entre les formats de données
natifs et le langage XML peuvent faire naître des préoccupations en termes de performances.
Les ressources logicielles existantes et leurs dépendances ainsi que les interfaces devront être analysées pour
déterminer si des modifications sont requises pour prendre en charge la fonctionnalité métier. Par exemple, pour créer une interface de services Web pour l'implémentation
existante d'une fonction métier, l'analyse peut impliquer l'examen de la composition et du flux des transactions en
ligne ou des travaux par lots ou encore des magasin de données persistants qui aident à exécuter cette fonction. La conception actuelle de ces applications existantes devra peut-être être
modifiée pour prendre en charge la fonctionnalité. Il faut également
identifier tout obstacle potentiel à la création d'une interface de services Web avec la qualité de service souhaitée.
Par exemple, l'implémentation par lots monolithique d'une fonction métier
peut nécessiter un temps de réponse inférieur à la seconde lorsqu'elle est appelée en tant que service.
Encapsulage de ressources existantes en tant que pattern de services
Dans certains cas, cependant, il est utile de développer une partition de service existant lorsque des fonctions
existantes de niveau inférieur formant un ensemble sont exposées chacune comme un service. Cette partition n'est
accessible qu'à des services de niveau supérieur qui l'utilisent pour présenter aux clients une spécification alignée
métier plus granulaire. Cette encapsulation des fonctions existantes doit être considérée comme une solution temporaire
et ne doit être entreprise que si les caractéristiques de performance de la technologie d'encapsulage sont suffisamment
maîtrisées. Pour plus d'informations, voir le concept Partitionnement de la solution.
Une façon d'envisager l'encapsulage d'une fonction existante est de penser à la forme très simplifiée de l'élément de
modèle Fournisseur de services, dans lequel un service spécifique
réalise une spécification donnée avec une opération unique. Le diagramme ci-dessous illustre ce pattern pour la
fonction existante "UpdateCustomerAddress" (mise à jour de l'adresse d'un client).
Pour personnaliser ce pattern, vous pouvez effectuer les actions suivantes :
-
Il est probable qu'un ensemble de fonctions existantes sera fourni par un même composant ; il convient donc
d'utiliser un seul et même fournisseur de services.
-
Le pattern présenté ci-dessus a été généré automatiquement ; il peut être préférable de renommer l'opération par
défaut appelée "exec${service}".
-
De même, il serait utile de renommer les messages générés par défaut ; à ce stade, les structures de message
doivent également être modélisées.
-
Le pattern par défaut suppose que l'opération reçoit un message et en renvoie un ; il est possible que la fonction
existante ne renvoie aucun message ou qu'elle ne soit qu'une notification, la signature de l'opération générée doit
être modifiée.
-
L'architecte/le concepteur doit s'assurer que des valeurs correctes sont définies pour la propriété
"allowedBindings" (liaisons autorisées) du fournisseur de services.
|