Réutilisation du portefeuille de services de l'entreprise
L'un des avantages les plus souvent cités de l'architecture orientée services (SOA) est la possibilité de faire
représenter par les services des ressources réutilisables dans l'entreprise, plutôt que le développement de composants
uniquement au sein de la portée d'une application unique. Cette vue de l'entreprise est importante car elle incarne la
notion selon laquelle une architecture véritablement orientée services en informatique fournit toute l'infrastructure
et toutes les fonctions métier comme des services et les applications développées par l'entreprise réutilisent les
fonctions du portefeuille de services.
Il est donc essentiel, au début d'un projet, de savoir si vous développez des services faisant partie du portefeuille
ou si vous développez une fonctionnalité d'application qui utilise ces services. Par exemple, le développement d'un
portail permettant à des clients d'accéder à leurs informations de compte est un projet de développement d'application
utilisant des services du portefeuille d'informations client, d'informations de compte, d'offres, etc. Dans chaque cas,
l'utilisation du portefeuille a des implications différentes ; le concepteur de service décrit leur spécification de
service et la publie en tant que composante du portefeuille. Cette spécification permet aux développeurs d'applications
de comprendre les exigences d'interaction relatives au service. L'implémenteur du service peut ensuite utiliser la même
spécification de service pour développer une ou plusieurs implémentations du service, en s'assurant de la conformité de
l'implémentation à la spécification. Le diagramme suivant montre la relation entre le portefeuille de services à
l'échelle de l'entreprise et le portefeuille de projet.
Pour plus d'informations, voir le concept Portefeuille de services.
|
Utilisation de patterns et de mécanismes de conception
Utilisez les patterns et les mécanismes de conception correspondant au service en cours de conception et respectant les
instructions relatives à la conception du projet. L'ajout d'un pattern ou d'un mécanisme permet de réaliser avec succès
la plupart des étapes suivantes de cette tâche, mais en conformité avec les règles définies par le pattern ou le
mécanisme.
Notez que les patterns et mécanismes sont généralement intégrés au fur et à mesure de l'évolution de la conception, et
pas uniquement lors de la première étape de cette tâche. De plus, ils sont souvent appliqués à un ensemble d'éléments
de modèle, plutôt qu'à un élément unique.
La transformation d'un service en sa réalisation implique souvent un ensemble de patterns, dont certains sont décrits
dans les Instructions : Patterns de composant de service.
|
Description de l'organisation logique de la solution
Il est souvent utile d'organiser votre réflexion en termes de vues différentes d'un système et d'étudier la façon dont
les services que vous développez s'intègrent dans ces vues. Lors de la définition des vues de l'organisation logique,
il est important que l'affectation d'un service à une vue n'implique pas une propriété dans le sens UML du terme
(Unified Modeling Language) ou un confinement ; c'est-à-dire qu'un même service doit pouvoir participer à plusieurs
vues logiques. Il n'est pas inutile d'intégrer les vues organisationnelles au modèle avant de développer le service ou
du moins avant la première itération de ces vues, de façon à ce que les services puissent être affectés aux vues
lorsqu'ils sont identifiés. Dans le modèle de services , nous utilisons l'élément de modèle Partition de service pour représenter un aspect d'une vue. Ces
partitions peuvent être employées pour représenter toutes les perspectives différentes de la solution mais n'impliquent
pas la propriété des services qui leur sont affectés. Pour plus d'informations, voir le concept Partitionnement de la solution.
Il est également possible que ces partitions, du moins celles qui représentent des points de vue clés, soient hébergées
dans des modèles distincts des services eux-mêmes, ce qui permet une évolution autonome des modèles de partition.
|
Description des éléments de service
Comme toujours dans la modélisation de systèmes logiciels, il existe un grand nombre de manières d'envisager (points
d'entrée dans) ce type de modèle, les représentations pouvant être utilisées et, naturellement, les différentes
méthodologies pouvant s'appliquer. Dans la plupart des cas, ces points d'entrée sont dus à des préoccupations
spécifiques en termes de domaines techniques ou métier, qu'il convient de traiter. Ces préoccupations sont suffisamment
importantes pour faire office de points de départ car il est essentiel de comprendre leur nature et les interactions
existant entre elles pour obtenir les résultats attendus.
Nous avons remarqué qu'il existe un petit nombre de préoccupations de ce type dans le cadre du développement de
solutions orientées services ; le diagramme ci-dessous représente ces premières préoccupations en tant que tâches de
conception spécifiques. Notons ici que, si chacune de ces préoccupations peut faire office de point de départ de la
conception de service et si chaque approche tend à être optimisée pour une certaine classe de services, il est très
probable qu'un projet de grande envergure aurait recours à une combinaison d'approches pour identifier et concevoir des
services.
Pour plus d'informations, voir l'Activité : Analyse des actifs existants, qui présente un ensemble de techniques
détaillées prenant en charge ces approches.
Dans cette approche, l'accent est mis sur le domaine de service. Des techniques telles que l'ingénierie domaine ou
l'analyse et la conception orientées objet permettent de se faire une idée du développement de modèles de domaine
abstraits. Ce faisant, on obtient généralement des modèles à grande réutilisabilité pour le schéma de message. La
conception de service est souvent une activité secondaire, même si elle est parfois exécutée en parallèle. Dans le cas
de l'échange de données informatisé (Electronic Data Interchange - EDI), par exemple, il n'existe pas véritablement de
notion d'interface de service car les systèmes EDI ont en général une boîte de réception et une corbeille de départ
uniques et globales pour les messages.
Cette approche peut être illustrée par un exemple tiré du milieu traditionnel du business-to-business (commerce
interentreprises), caractérisé par la normalisation EDI. Dans ce cas, l'accent est mis, lors de l'activité de
conception, sur le développement d'un schéma de message faisant l'objet d'un consensus dans un secteur d'activité ou
dans un autre cercle et est jugé représentatif du schéma d'une classe de messages par exemple, ainsi que de normes
industrielles telles que ACORD, SWIFT et RosettaNet (voir Tâche :
Conception des messages).
Dans cette approche, le concepteur est chargé d'exposer, comme un service ou un ensemble de services, la fonctionnalité
prévue pour le métier ou l'application. Dans ce cas, nous ne savons pas forcément ce que le client choisira de faire
avec notre service, mais nous connaissons le type d'interactions dont ce genre de clients souhaite disposer. C'est
pourquoi les messages sont souvent secondaires et développés en réponse aux exigences d'une opération.
Pour illustrer cette approche, on peut prendre l'exemple des interfaces de programme d'application de services Web
proposées par des entreprises telles qu'Amazon ou eBay. Ce type d'interface de service n'impose pas de
processus métier au client. Dans la plupart des cas, elles ne leur imposent pas même d'interfaces obligatoires, mais
exposent les opérations de leurs fournisseurs de services respectifs de manière claire et intuitive aux développeurs
tiers.
Comme indiqué ci-dessus, la modélisation axée sur les services se prête souvent particulièrement bien à une approche
guidée par les cas d'utilisation car elle comprend les besoins des acteurs et les clients externes du service et
fournit des opérations prenant en charge ces besoins, par exemple par l'exploration des catalogues, l'ajout d'éléments
à un panier, la caisse, etc.
Dans le cas de la conception de collaboration, l'accent est mis sur la collaboration de deux services ou plus ; il
s'agit véritablement d'une vue de processus des services, plus en rapport avec une modélisation métier classique
qu'avec une activité de développement logiciel. Dans cette approche, les services sont considérés comme des rôles
satisfaisants de la collaboration et la spécification de service correspond donc à l'ensemble de responsabilités
définies pour le rôle dans une ou plusieurs collaborations.
Ce type d'approche serait connu des personnes ayant participé au développement de processus d'échange entre partenaires
de RosettaNet (Partner Interchange Processes - PIP) ou au développement des normes OAGIS, bien que les collaborations
soient loin d'être achevées dans les cas évoqués. Ce type d'approche serait commune à un métier en termes de conception
de processus métier ou dans des activités d'intégration métier dans lesquelles les composants d'un système informatique
sont exposés comme des services.
Dans ce cas, la spécification de service peut généralement être dérivée directement de la collaboration, mais cette
approche met en général moins l'accent sur le contenu du message, ce qui conduit à une exigence d'approche hybride de
l'achèvement.
Le terme "règle" est relativement vague ; il est utilisé ici pour désigner les instructions ou contraintes pouvant être
considérées comme des exigences non fonctionnelles. Au niveau du modèle, nous devons nous rendre compte que nous ne
voulons pas que le modèle soit rempli avec des instructions détaillées relatives aux informations techniques, mais, de
façon plus réaliste, nous enregistrons l'objectif du système en ce qui concerne ces exigences. Par exemple, il est
possible que nous sachions qu'un message donné doit être transmis et gardé confidentiel lors de l'inclusion des
informations personnelles relatives à nos clients ; nous voulons enregistrer l'objectif de confidentialité du message,
et non le fait que nous faisons appel au chiffrement de données utilisant le chiffrement 128 bits AES sur un fichier
XML canonique avec des certificats X.509 pour le chiffrement de clé publique, principalement parce que très peu de gens
sauront ce que cela signifie, et qu'encore moins seront capables de le définir dans un modèle à ce niveau d'abstraction
(voir Tâche :
Identifier les patterns de sécurité).
Le diagramme ci-dessous illustre l'association d'une règle aux éléments du modèle de service. Notez que les informations sur les règles
peuvent être attachées à des informations autres que les composants de spécification identifiés ci-dessous, bien qu'il
s'agisse de la principale zone d'intérêt.
Pour plus d'informations sur la modélisation des règles de sécurité, reportez-vous au livre blanc Modélisation des questions de sécurité dans une architecture orientée services.
|
Dépendances de service de modèle
Un autre aspect essentiel de l'Artefact : Modèle de services qui doit être développé pendant la
spécification est la capture des dépendances entre les services. Dans le cadre du modèle de services , un certain nombre de dépendances sont
naturellement enregistrées. Elles peuvent être aussi évidentes que la relation entre un service et sa spécification ou
plus complexes, telle la relation logique entre deux services indépendants implémentant tous deux la même
spécification. Ces dépendances (décrites dans l'Artefact : Modèle de services et le Rapport : Dépendances de service) sont importantes pour comprendre la capacité à
déployer un service en tant qu'unité autonome et affecteront son évolution dans le temps lorsque les dépendances
deviendront des contraintes sur la capacité au changement du service.
Les dépendances de service décrivent les relations entre les services qui surgissent dans le contexte plus large de
leur mode d'utilisation. Lorsqu'un service est formé à partir d'une composition d'autres services, le service composant
dépend des services composés. Lorsque des services sont utilisés dans le contexte d'un processus métier, une dépendance
liée au processus surgit de la séquence inhérente d'étapes dans le processus métier qui dicte l'ordre dans lequel les
services seront utilisés.
-
Dépendances fonctionnelles/Dépendance composite qui surgissent de la composition de services multiples.
-
-
Exemple : Réserver un véhicule dépend de Vérifier les prix et Effectuer une réservation pour sa
fonctionnalité
-
Dépendance temporaire où une condition ou une exigence de traitement préalable ou postérieure devra être
prise en compte dans les compositions ou les chorégraphies.
-
-
Dépendance avec condition préalable - un autre appel de service doit avoir été exécuté correctement
pour que l'appel en cours puisse commencer à s'exécuter.
-
Dépendance de traitement - un autre appel de service est requis pour que l'exécution du service en
cours aboutisse.
-
Dépendance avec condition postérieure - cela apparaît dans les cas où un service requiert l'appel
d'un autre service après son exécution.
Ces dépendances font souvent partie du processus de décision par lequel doit passer un client de service lorsqu'il doit
déterminer s'il réutilise un service, en particulier s'il existe plusieurs implémentations à départager.
Principaux types de dépendances/associations du modèle de services :
-
relation entre un service et les fournisseurs de services qui l'implémentent,
-
relation entre un service et la spécification de service qu'il implémente,
-
relation entre un service et toute spécification de service qui lui est nécessaire,
-
relation entre un service et tout canal de service qui le connecte à d'autres services, et donc au service de
l'autre extrémité du canal,
-
relation entre un service et toute partition de service dans laquelle apparaît le service.
Il est donc important que toutes les spécifications de service soient complètes, non seulement en termes d'opérations
et de messages qu'elles fournissent, mais également en termes de dépendances, telles que des interfaces obligatoires
pour les opérations de rappel. Le rapport Dépendances de service fournit une vue d'ensemble des dépendances importantes
dans le cadre du modèle de services .
|
Composition et flux de service de modèle
Les services sont souvent composés d'autres services existants et, dans certains cas, de technologie : par exemple, la
chorégraphique permet de développer un service sans code explicite, comme une pure composition de services existants.
Pendant la spécification, les services qui réutilisent des éléments se trouvant déjà dans le portefeuille de
l'entreprise et qui ont documenté leur dépendances de ces services, peuvent être considérés comme des services
composites si leur fonctionnalité dépend de la fonction d'un service composé et si le composite ne peut pas être
déployé sans accéder aux services composés.
Dans certaines infrastructures préfabriquées SOA, une couche processus métier est destinée à gérer uniquement
les services composites chorégraphiés où des processus complexes sont fournis en tant que chorégraphies gérées de
services à granularité plus fine. Dans ce cas, le langage BPEL4WS (Business Process Execution Language for Web
Services) peut être utilisé comme outil pour le développement des services composites, des flux de services et des
couches de processus métier.
Par conséquent, deux types de services composites peuvent être identifiés :
-
Les services composites câblés : ils sont caractérisés par une faible flexibilité due à un flux et
un contrôle de services prédéfinis où le flux et le contrôle ne sont pas externalisés. Ce type de service ont des
attributs de qualité de service intéressants comme les performances.
-
Les services composites peu câblés : ils sont caractérisés par une flexibilité élevée où la
composition des services en processus métier est réalisée par l'externalisation du flux et du contrôle. La
description du flux de la composition est externalisée. Ce type de composition exploite des outils de modélisation,
la variabilité dynamique via des règles et la variabilité statique via la modélisation. La composition à l'aide de
BPEL en est un exemple.
Pour plus d'informations, voir Concept : Composition et chorégraphie des services ainsi que Instructions : Réalisation de service - services BPEL dans une application SOA pour
consulter un exemple spécifique d'un projet.
|
Exigences non fonctionnelles de document
L'architecture orientée services (SOA) permet de choisir un Artefact : Fournisseur de services basé non seulement sur la
fonctionnalité fournie mais sur la qualité de service (QoS) qu'il peut garantir. L'une des raisons pour changer de
fournisseur de services peut souvent être le résultat d'une modification d'exigences non fonctionnelles, nécessitant un
nouveau niveau de qualité de service qui n'est pas pris en charge par un fournisseur existant. La raison peut également
être la dégradation de la qualité de service attendue par le consommateur du service. Une architecture orientée
services (SOA) permet cette souplesse, généralement à un coût moindre, que les autres styles d'architecture.
La qualité de service peut être envisagée selon deux perspectives : celle du fournisseur et celle du
consommateur. Le fournisseur de services garantit la fourniture et le maintien d'une qualité de service pour
chacun de ses services ou de ses groupes de services.Le consommateur du service, d'un autre côté, recherche la qualité
de service souhaitée et choisit un fournisseur en fonction de la qualité de service. Il est également important de
noter que, dans une configuration commerciale où le consommateur et le fournisseur établissent un contrat légal sur
l'utilisation du service, ces garanties de qualité de service sont matérialisées dans des contrats de service qui
prévoient souvent des pénalités en cas de manquement par le fournisseur à remplir son obligation de qualité de service.
Il est donc très important de spécifier clairement les exigences non fonctionnelles requises par le consommateur (par
exemple, coût de la transaction, performances, disponibilité, sécurité, etc.) pour un service ou un ensemble de
services. Dans cette tâche de spécification de service, nous identifions les exigences non fonctionnelles pour la
qualité de service souhaitée. Les exigences non fonctionnelles sont utilisées pour valider des ressources pour des
composants de service qui offrent les services et pour financer la réalisation et la maintenance des composants de
service qui assurent la fourniture de la qualité de service dans le temps. Des décisions architecturales essentielles
doivent être prises pour assurer que la qualité de service promise, basée sur les exigences non fonctionnelles, est
atteinte.
Le mode dont les exigences non fonctionnelles sont associées à l'Artefact : Spécification de service n'est pas défini dans les
présentes instructions. Aucune limite n'est, par ailleurs, indiquée quant à la définition d'une exigence, excepté bien
entendu la qualité de service et la sécurité mentionnées ci-dessus. Les exemples peuvent être :
-
La disponibilité (c'est-à-dire moyenne des temps de bon fonctionnement)
-
Une fenêtre opérationnelle (y a-t-il une période où le service ne sera pas utilisé ?)
-
Les temps de réponse (rapidité avec laquelle le service doit répondre à une requête)
-
Le rendement en heures pleines (combien de requêtes pour le service peuvent-elles arriver par unité de
temps, par exemple par seconde, par minute, par heure)
|
Exigences de gestion des états de document
Bien que les services individuels soient considérés comme étant sans état, les compositions doivent souvent gérer les
informations d'état lors de l'appel des services composés. Le chorégraphe des services est souvent responsable de la
gestion des états. Un composant qui implémente et réalise plusieurs services associés ou plusieurs opérations sur les
services peut également devoir gérer des états entre les appels, pour des raisons de performances.
La gestion des états en environnement SOA peut être divisée en trois catégories principales :
-
Etat de transaction où un service a une transaction ouverte pendant une conversation avec un
client.
-
Etat de sécurité où un contexte de sécurité est conservé ouvert pendant une conversation avec un
client.
-
Etat fonctionnel - où la conversation avec un client implique plusieurs opérations associées.
Pour plus d'informations, voir les Instructions : Gestion des états pour les services.
|
|