Un des aspects essentiels de l'architecture SOA est que les services peuvent être composites, ce qui signifie qu'un
nouveau service est souvent composé comme une collaboration entre plusieurs services existants. Par bien des aspects,
cela est aussi vrai pour les techniques à base de composants et orientées objet, mis à part que certaines fonctions du
logiciel intermédiaire (middleware) utilisées pour développer des solutions orientées services permettent l'exécution
du reste de ces collaborations à l'aide de standards comme le Langage d'exécution du processus métier pour les
services Web (BPEL4WS, WS-BPEL ou simplement BPEL). C'est cette possibilité de composer la structure des services,
c'est-à-dire de définir les dépendances d'utilisation entre les services, mais aussi de composer les services en
fonction des comportements, qui rendent l'architecture axée services et la stratégie informatique si intéressantes pour
de nombreuses organisations.
De plus en plus d'organisations prennent conscience de la nécessité d'améliorer leur réactivité vis-à-vis des
changements des environnements métier, que ce soit à cause de la pression liée à la globalisation, des nouveaux marchés
et des nouveaux canaux ou encore des nouveaux concurrents utilisant la technologie de manière plus efficace. Ces
organisations considèrent le développement orienté services et les solutions orientées services comme un moyen
d'organiser leurs équipements informatiques, afin de gérer les exigences actuelles et de fournir une infrastructure de
fonctions correspondant à l'entreprise et pouvant être réutilisée, reconfigurée et recombinée de manière efficace pour
gérer les exigences futures.
Composer les services de cette manière permet aussi d'ajouter facilement aux nouvelles solutions aussi bien des
équipements informatiques existants que des équipements plus récents. Par exemple, des équipements existants, même
s'ils ont été développés pour les plateformes de grands systèmes, peuvent être présentés comme des services ayant des
produits middleware et être intégrés de la même façon que les nouveaux services développés à l'aide de J2EE, IBM
WebSphere ou Microsoft .NET. Malheureusement, la plupart des équipements existants sont développés avec des interfaces
qui ne tiennent pas compte des conseils que nous mettrions en oeuvre pour les nouveaux services. Il est donc utile de
créer des services composites qui n'englobent pas seulement ces services existants, mais qui fournissent des interfaces
différentes, correspondant mieux à l'entreprise et qui tirent partie des fonctions existantes en les regroupant et en
les organisant de manière à produire une fonction de niveau supérieur.
Chorégraphie des services
Revenons brièvement sur le terme chorégraphie. Ce terme est utilisé dans de nombreux produits middleware pour
dénoter l'exécution gérée d'un script, signifiant la présence d'un flux de procédés dont les participants sont des
services et les tâches des messages échangés. Pour certains produits, le terme orchestration est utilisé. Si
certains analystes et technologues du domaine décrivent les différences existant entre le sens de ces mots et la façon
dont ces termes sont utilisés dans les standards, pour la plupart des utilisateurs ces différences ont beaucoup moins
d'intérêt que les similitudes.
En termes de standards, une façon commune de représenter la chorégraphie des services Web est apparue tardivement,
après que la plupart des fournisseurs principaux de middleware ont introduit leurs propres solutions. Le standard
actuel utilisé dans le domaine est le langage BPEL (Business Process Execution Language) pour les services Web (BPEL4WS
ou BPEL). Pour plus d'informations sur BPEL4WS, consultez le site OASIS WSBPEL ou le site IBM BPEL.
Les services peuvent facilement être développés grâce aux fonctions fournies par les autres services de manière
récursive, comme l'indique le diagramme ci-dessous, où les services peuvent identifier les services dont ils dépendent.
Dans ce cas, un service composite utilise les services passerelles de saisie de demande et d'échange de données
informatisé. Les services composites sont souvent utilisés lorsque l'organisation habituelle des fonctions de services
identifie des fonctions communes pouvant être fournies dans plus d'une situation. Pour certains services dont le rôle
consiste à fournir des fonctions de l'infrastructure (comme le service d'échange de données informatisé ci-dessous),
cela est relativement simple à identifier. Dans les autres cas, des collaborations de services détaillées identifieront
le besoin de diviser un service candidat plusieurs services réels.
Les services composites servent aussi à rassembler les fonctions réalisées dans les éléments existants. Dans la plupart
des cas, on accédera à ces fonctions par des connecteurs ou des interfaces de programmation fournis par l'élément
lui-même et un nouveau service sera développé, dépendant donc de ces éléments. Cependant, pour permettre à un composant
d'évoluer de manière plus souple et à l'élément existant d'être déplacé lors d'une implémentation différente, une autre
stratégie peut être utilisée : chaque fonction existante est présentée comme un service indépendant ; ces services
indépendants sont ensuite utilisés par le service composite, ce qui permet une évolution indépendante de l'élément
existant et des services composites.
On peut aussi utiliser les services composites lorsqu'on ne sait pas à l'avance quelle partie des services réels sera
optimisée par un service composite. Par exemple, dans un service de gestion des commandes, il peut être nécessaire de
séparer la validation des commandes comme étant un ensemble à part de services de règles métier indépendants, de façon
à ce que de nouvelles règles puissent être ajoutées par la suite. Pour plus de renseignements sur ce sujet, consultez
les Instructions : Médiation de services.
Naturellement, cette approche a des avantages, mais aussi des inconvénients. Si les services de niveau inférieur ne
peuvent être exposés que par le biais de protocoles IP comme SOAP ou HTTP, il est probable qu'ils soient moins fiables
et que leurs performances soient moins bonnes que si on pouvait y accéder par une interface de programme d'application
native ou par un connecteur. Ces compromis doivent faire partie de l'ensemble des décisions architecturales prises et
documentées dans le cadre de la conception du service.
Pour plus d'informations sur l'accès aux ressources existantes et sur la relation entre les services potentiels et
réels, consultez l'Activité : Analyse des actifs existants.
Lors de la modélisation du comportement des services composites, nous utilisons la notion d'Artefact : Contrat de service pendant les phases d'identification et
de conception.
-
Lors de l' Activité : Analyse des actifs existants, nous utilisons la collaboration comme
un outil pour décrire les rôles et les responsabilités des services potentiels. Par exemple, nous pouvons
identifier la nécessité de distinguer les services de validation de commande et de gestion des commandes ; mais
comment communiquent-ils et de quelles informations sont-ils responsables ? Une collaboration de services est
utilisée comme un outil pour décrire cette communication et nous pouvons identifier les échanges de messages
nécessaires à partir du modèle obtenu.
-
Pendant la Tâche : Spécification de service, nous utilisons la collaboration
pour décrire le comportement concret d'un service donné ou d'une opération sur un service. L'exemple de la
validation de commande pourrait être décrit de manière concrète comme un ensemble de messages envoyés à un ensemble
de services de règle de validation.
De cette manière, il est possible de voir qu'une collaboration de services dans la tâche de conception de service est
directement liée à la notion de chorégraphie en termes de services Web. Cela représente une description du flux
externalisé et configurable organisant un ensemble d'échanges de messages entre les services. Dans la plupart des
chorégraphies d'implémentation middleware, le flux est décrit dans un langage de type XML comme le langage BPEL. Ce
type de langage peut être généré grâce à la collaboration de services décrite dans l'Artefact : Modèle de services lorsque le flux lui-même est décrit
avec des activités ou des interactions UML 2.0.
La collaboration a une structure composite indiquant la vue des collaborateurs et de leurs connexions, ainsi qu'un
comportement précisant les messages échangés et leur organisation. Le diagramme ci-dessus indiquant un fournisseur
composite a lui aussi une structure composite, tout comme le schéma de validation de commande ci-dessous.
Il ne s'agit pas de la structure du fournisseur de la validation lui-même, mais de la structure de la collaboration de
services, comme l'indique le diagramme ci-dessous.
Spécification du comportement du service
Comme nous l'avons déjà vu, les activités ou les interactions UML 2.0, et plus particulièrement les diagrammes de
séquence, sont souvent utilisés pour décrire le flux des messages entre différents services collaborant. Le diagramme
ci-dessous est un diagramme d'activité UML 2.0 indiquant le comportement du service de validation de commande. Pour une
commande spécifique, le service qui enregistre la validation donne une liste des opérations de validation à consulter.
Ce type de comportement peut être identifié pour un service entier ou pour une opération spécifique selon les besoins
du service. Dans ce cas, l'activité au sein de la collaboration est liée à l'opération Validate () (via la
spécification/l'association de méthode dans UML 2.0).
Spécification des associations de service
Comme nous l'avons déjà vu, les associations (à savoir les protocoles physiques réels et les codifications de messages)
utilisées pour communiquer entre les services sont identifiées comme appartenant à l'Artefact : Canal de service dans la vue de composition. Les
associations effectives utilisées entre les services ont un réel impact sur les exigences non fonctionnelles comme la
performance, la fiabilité et la sécurité. Les choix disponibles doivent donc être documentés avec les conséquences de
chaque exigence identifiée dans l'architecture générale du système. Par exemple, il est possible que l'une des
utilisations de l'Artefact : Partition de service soit de représenter les associations
autorisées ou nécessaires entre les services à l'intérieur de la partition, une exigence commune étant que les services
situés dans des zones logiques communiquent en utilisant des performances de niveau supérieur mais des
associations qui leur sont propres, tandis que les communications avec les services se trouvant en dehors de la
zone utilisent des performances inférieures mais des associations standardisées.
Les gens se demandent souvent si les capacités requises pour assurer les performances, la fiabilité et l'évolutivité
des services Web peuvent être fournies par une architecture HTTP ou SOAP, qui sont des protocoles à la fois lents et
peu fiables. Il convient tout d'abord de définir la double notion de "lents et peu fiables" et de réaliser que même des
vecteurs fiables reposent finalement sur des moyens peu fiables. Par exemple, lorsqu'on utilise SOAP sur HTTP, il est
toujours possible de construire des protocoles et des interactions au niveau de l'application, qui offrent des
fonctions supplémentaires pour les accusés de réception de messages et la sécurité. Néanmoins, si nous considérons que
certains services communiquent dans le même contexte de sécurité ou d'application, nous pouvons envisager d'utiliser un
autre vecteur que HTTP.
Il est très important de réaliser que, même si les services Web présentent un modèle simple et un ensemble de
protocoles simples et flexibles, vous n'êtes pas limités à ces choix. Tout comme WSDL a déjà des associations à la fois
pour GET/PUT SOAP et HTTP, il est essentiel d'offrir aux demandeurs des choix supplémentaires. Par exemple, un service
spécifique peut exposer un message en utilisant une association avec une file d'attente de messages et une association
avec SOAP, de façon à ce que le demandeur puisse choisir l'association la plus appropriée. Dans ce cas, le fournisseur
peut aussi mettre en place des mesures incitatives, comme un niveau de service garanti si la file d'attente de messages
est utilisée, mais pas de garantie de service pour une conversation HTTP.
Grâce à l'exemple de validation de commande développé plus haut, on peut voir la façon dont les associations sont liées
au stéréotype Artefact : Canal de service et représentées sur le diagramme
ci-dessous.
Lors de la conception et du développement de solutions à l'échelle de l'entreprise, il faut toujours garder à l'esprit
les exigences fonctionnelles et non fonctionnelles et s'assurer que les bons compromis sont faits et que les bonnes
décisions sont prises pour atteindre les objectifs de l'entreprise.
|