Tâche: Spécification de service
Cette tâche définit et spécifie les services et la structure d'une solution orientée services en termes de collaborations d'éléments de conception contenus et d'interfaces/sous-systèmes externes.
Disciplines: Analyse et conception
Objet
  • Définir les services et la structure d'une solution orientée services en termes de collaborations d'éléments de conception contenus et d'interfaces/sous-systèmes externes.
  • Pour analyser la communité et la variabilité du service (voir Instructions : Analyse de variabilité).
  • Documenter la spécification de service.
  • Déterminer les dépendances et la communication entre les services.
Relations
Description principale
Cette tâche détaille l'ensemble d'Artefact : Spécifications de service identifiées et qualifiées pendant l'Activité : Identifier les services ; elle fournit en outre une structure et des détails supplémentaires. Ces détails de niveau conceptuel incluent l'interface, les messages et la composition de services ainsi que l'affectation des services aux fournisseurs.
Etapes
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.

Diagramme décrit dans le contenu textuel.

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.

Conception de messages

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).

Conception des services

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.

Conception de la collaboration

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.

Identification et enregistrement des règles

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.

Diagramme décrit dans le contenu textuel.

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.

Plus d'informations