Concepts utilisés dans la démarche SOA

Activation de services

L’activation de services consiste à créer une variante d’un service afin de le configurer conformément aux règles de mise à disposition d’un consommateur : options de fonctionnement, choix du niveau de la qualité d’exploitation… Les règles de mise à disposition forment le contrat d’utilisation du service. Lorsque que le contrat est validé par le fournisseur on considère que le service est activée pour une variante et pour un consommateur.

La plate-forme d'activation de services met en œuvre le modèle d'architecture de gestion par les contextes (pattern Contexte-Aware) pour la gestion des variantes et des contrats d'utilisation. Cette plate-forme dispose d'une console métier qui permet aux équipes techniques et opérationnelles de paramétrer les données des variantes et des contrats. Certains éléments d'une variante peuvent être directement modifiés par le consommateur si celui-ci dispose des droits délégués par le fournisseur. Il faut alors que la plate-forme d'activation de services autorise le travail collaboratif : plusieurs organisations chez le fournisseur et partage de certains paramétrages avec les consommateurs.

L’activation de services est un domaine clef du SOA car la construction de services répond à une volonté d’exposition de multiples services vers plusieurs consommateurs. La gestion de cette exposition crée un nouvel écosystème de paramétrage des variantes de services et de création des contrats d’utilisation. C'est aussi à ce niveau que les fonctions de monitoring des flux d'exploitation sont mises en œuvre.

L’activation de services est également nommée « provisioning » de services.

Administration des Catégories et des Services

Chaque catégorie (au sens de Grady Booch, contributeur à UML : voir aussi définition plus bas) correspond à un agrégat de données dont le périmètre forme une notion métier qui est valable de manière transversale aux projets. Un premier projet construit une version initiale de la catégorie puis les autres la réutilise et l'enrichisse progressivement.

Une cellule transverse d'administration des catégories permet d'unifier et de promouvoir les catégories entre les projets. Par exemple, lorsqu'un projet entame la modélisation de ses données il mène d'abord l'identification et l'analyse des catégories susceptibles d'être réutilisées. Cette réutilisation concerne l'agrégat de données, c'est-à-dire un modèle entités/associations ou un Diagramme de classes mais aussi la réutilisation des services exposés par les catégories.

L'administration des catégories est une évolution des cellules d'administration des données. Le grain de cette administration s'opère sur les agrégats et s'étend aux services qui y sont rattachés.

Cahier des charges SOA

Dans le cahier des charges on spécifie les services de type métier. La découverte de ces services se mène à partir de la modélisation des processus organisationnels (MOT en Merise, Diagramme d'activités en UML). La maîtrise d'ouvrage est fortement impliquée dans ce travail et il faut prendre en compte les spécificités suivantes des services métiers :

• Contour fonctionnel mettant en relation un fournisseur avec plusieurs consommateurs.
• Conception des variantes du service métier, c'est-à-dire des besoins d'adaptation du service selon les différents contextes d'usage connus et probables.
• Spécification précise des règles de préconditions, postconditions et d'exceptions du service métier. Ces règles participent directement à la réalisation du contrat d'utilisation du service, elles sont donc lisibles par le consommateur.

Certaines parties du cahier des charges peuvent être mises à disposition de la maîtrise d'ouvrage et de la maîtrise d'œuvre du consommateur. Ce choix dépend du mode d'organisation du projet et plus précisément du niveau d'implication des consommateurs pour la spécification des services métiers. Dans cette hypothèse, le plan-type du cahier des charges SOA doit faire la distinction entre les informations confidentielles du fournisseur et celles pouvant faire l'objet d'une diffusion aux consommateurs.

Catégorie (selon Grady Booch, contributeur à UML)

Le concept de catégorie est pivot dans la démarche SOA. Une catégorie est un agrégat de classes du diagramme de classes (ou entités/association en Merise) qui respecte des propriétés strictes de stabilité, de continuité et de consistance métier. Historiquement le concept de catégorie est aussi nommé objet-métier ou sujet-métier. Il a été introduit la première fois par Grady Booch dans le cadre de UML.

La catégorie permet de décomposer la logique des opérations et des phases sous la forme de services rattachés aux différentes catégories du système d'information. Il s’agit de services de type externe et qui réifie le pattern d’architecture applicative SOA. Selon un principe de base de la taxonomie, on impose qu’un service appartienne à une et une seule catégorie. La catégorie est donc à la fois un régulateur de la granularité des services (on décompose les traitements autour des catégories) mais aussi de classificateur (on range chaque service dans une et une seule catégorie)

Grâce à sa propriété de stabilité, la catégorie à une vocation transversale aux projets. C’est la raison pour laquelle il est intéressant de mettre en place une cellule d’administration des catégories afin d’unifier et de favoriser la réutilisation entre les projets : réutilisation des agrégats de données des catégories (modèle de classes ou MCD) et les services attachés à chaque catégorie.

Propriétés détaillées du concept de catégorie

• Classe pivot dans l’agrégat : Analyse du diagramme de classes afin de déterminer la classe pivot de chaque catégorie. On considère qu'une classe est pivot s'il est possible d'agréger autour d'elle un ensemble d'autres classes qui se trouvent structurellement sous son contrôle. En d’autres termes, on recherche le niveau de stress (effet de propagation) engendré par une évolution de la classe pivot vis-à-vis des autres. Toutes les classes impactées par une évolution de la classe pivot participent à l'agrégat de données.
• Règles de composition et de complétude : Les catégories ne doivent pas se chevaucher entre elles. Chaque classe doit appartenir de manière exclusive à une seule et unique catégorie.
• Règle d'autonomie : L'existence d'une occurrence d’une catégorie est, autant que faire se peut, indépendante des autres catégories.
• Règle de continuité : Une catégorie est composée d'un seul et unique agrégat. Il n'est pas possible d'avoir des classes ou groupes de classes non rattachées à l’agrégat de données.
• Règle de stabilité : La catégorie est dotée d'une durée de vie plus grande que celle d’un projet. Elle est réutilisée et étendue par les projets.
• Règle de granularité : Dans la pratique on constate que la granularité moyenne d'une catégorie est supérieure à une quinzaine de classes et inférieure à une cinquantaine.

Composant

Un composant correspond à une unité de traitement exécutable. Par exemple en J2EE il peut s’agir d’un EJB session, d’une servlet... Le périmètre d’un composant est directement régulé par le pattern d’architecture applicative SOA et à ce titre il réifie obligatoirement soit :

• Une façade d’une catégorie.
• Une partie ou la totalité de l’implémentation interne d’une catégorie.
• Un service métier.
• Un processus.

Un composant est typé selon les couches de l’architecture N-Tiers. Il est, de manière exclusive, spécialisé soit dans la couche de présentation, soit dans celle des règles applicatives soit dans l’accès aux données.

Contrat d'utilisation de service

Un service est décrit par un contrat d’utilisation qui précise ses conditions d’usage (notamment les préconditions, postconditions, exceptions) et les devoirs que le consommateur doit respecter.

Selon le type du service, le contrat d’utilisation prend différentes formes :

• Service interne à une catégorie : il s’agit d’un service proche de l’implémentation du logiciel et dont l’usage est limité au périmètre d’une seule catégorie. Ce contrat peut s’exprimer à l’aide d’une documentation de niveau API comme par exemple un javadoc.
• Service externe à une catégorie, c'est-à-dire exposé par la catégorie : : il s'agit d'un service qui se détache de l'implémentation du logiciel. Ce type de service est administré dans une optique de réutilisation entre les projets. Donc, le contrat d'utilisation ne peut pas se limité à une simple API. Il faut l'étendre à une description informelle en insistant notamment sur les préconditions et postconditions. Il est nécessaire d'utiliser un outil de gestion des contrats adossé à une base de données. Cet outil implémente le modèle d'architecture de gestion par les contextes (pattern Context-Aware) afin de gérer des contrats cadres puis des spécialisations successives selon les besoins.
• Service métier. Ce type de service est complètement détaché de l'implémentation du logiciel. Sa valeur est directement perçue par les maîtrises d'ouvrage du fournisseur et des consommateurs. La gestion des contrats d'utilisation nécessite l'usage d'un outil convivial et partagé entre les maîtrises d'ouvrage du fournisseur et des consommateurs. Ici également, cet outil implémente le modèle d'architecture de gestion par les contextes (pattern de Context-Aware) afin de gérer des contrats cadres puis des spécialisations successives.

Dans les meilleures pratiques on précise une typologie de contrat : syntaxique (interface + binding), sémantique (préconditions, postconditions…), qualité de services (métriques au sens par exemple de WS-Agreement). A partir ce cette définition on étudie la couverture du WSDL actuel, comment la compléter et quels outils de gestion des contrats mettre en œuvre en administration et en exploitation (parsing automatique des clauses du contrat).

Couplage faible

Un service est en couplage faible quand il n’est pas autorisé à appeler directement un autre service. Il délègue cette responsabilité à un traitement spécialisé que l’on nomme fonction d’orchestration.

Grâce au couplage faible, on peut réutiliser un service sans devoir reprendre des services qui lui sont liés.

A partir de cette première définition, on ajoute d'autres principes techniques qui contribuent à découpler les services entre eux :

1. Un service est activable indépendamment de sa technologie. Pour ce faire, l'activation se réalise par l'envoi (et la réception) d'un message XML (il ne s'agit donc pas d'une activation d'objet distribué comme en Corba ou DCOM).

2. Un service peut être activé suivant un mode asynchrone. Dans ce cas, le service s'abonne à un événement auprès de la fonction d'orchestration (ce qui renvoi aux principes de l'architecture EDA - Event Driven Architecture).

Décomposition SOA

On distingue trois niveaux de décomposition SOA :

• Le premier est la découverte des opérations exposées par les services métiers à partir de la modélisation des processus. Il s'agit d'un regroupement d'activités formant le périmètre fonctionnel que l'on souhaite exposé aux consommateurs (le terme activité fait ici référence à une étape dans un diagramme d'activité UML. En Merise il s'agit d'une étape organisationnel dans le MOT).
• Le second niveau consiste à décomposer les opérations et les phases découvertes lors de la modélisation du processus sous la forme de services rattachés aux catégories. Chaque opération et phase devient ainsi un orchestrateur d’appel vers les services exposés par les catégories (service de type externe).
• Le troisième niveau dépend de l’usage ou non d’un langage orienté objet. Il s’agit de décomposer chaque service exposé par une catégorie sous la forme de méthodes attachées aux classes qui constituent la catégorie d’appartenance. Cette décomposition se fait uniquement sur les classes de la catégorie d’appartenance, jamais sur les classes d’autres catégories (principe d’isolation des catégories entre elles).

Extensibilité du code des services et réutilisation

Lorsque que l’on souhaite réutiliser un service il est souvent nécessaire de l’adapter au préalable afin qu’il se conforme au nouveau contexte d’utilisation. Cette adaptation ne doit pas nécessiter une duplication du code d’origine, ce qui conduirait à une impasse en génie logiciel (problème d’intégrité et de maintenance de plusieurs codes dupliqués). Pour étendre le code d’origine sans le modifier (principe de fermeture/ouverture du code) il existe trois approches possibles :

• La première consiste à tirer profit des propriétés d’héritage de l’objet et de la programmation par interface. A partir de la classe qui contient le code d'origine du service, on crée une classe fille par variante que l'on spécialise selon les besoins (surcharge ou remplacement des méthodes). Malheureusement ce mécanisme doit être exceptionnel car il conduit à créer des connexions d'héritage qui ne correspondent pas à un objectif de taxonomie au sens de la classification. La maintenance des arbres de classes avec de multiples connexions d'héritage est très difficile.
• La seconde approche consiste à utiliser le modèle d'architecture de gestion par les contextes (pattern de Context-Aware) qui permet de créer des variantes à l'aide d'un paramétrage du code. Cela nécessite une démarche de spécification adaptée ainsi qu'un outillage pertinent (station de paramétrage).
• "La troisième solution est encore prospective mais s'annonce très intéressante. Il s'agit de l'usage des Aspects (AOP : Aspect Oriented Programming). L'AOP complète les langages objets (précompilateur Java, C#) avec des mécanismes qui permettent d'étendre le code sans le modifier. Pour ce faire on définit dans des Pointcuts l'endroit où l'on souhaite ajouter du code en indiquant via des Advices l'événement qui le déclenchera : par exemple " before " l'exécution d'une méthode ou " after " l'initialisation d'une variable. Le code déclenché est écrit sous la forme d'une classe particulière qui est un Aspect (aspect remplace le mot clef class).

L’extensibilité du code et donc la gestion des variantes de service est un sujet déterminant du SOA. Aujourd’hui, la pratique combinée de l’héritage (usage très encadré) et du context-Aware (effort de modélisation et outillage de gestion des paramètres) offre un excellent cadre de développement et d’exploitation des variantes. On ne duplique plus le code, on l’étend. A terme, on pourra ajouter l’AOP pour rationaliser encore plus ces principes.

Fonction d'orchestration

La fonction d’orchestration est assurée par les concepts SOA d’opération (celles exposées par le service métier) et de processus mais jamais à d’autres niveaux de l’architecture. C’est un point très important pour rationaliser l’usage des techniques d’orchestration.

Les quatre rôles clefs de la fonction d’orchestration sont indiqués maintenant :

• Gestion de contexte : La fonction d’orchestration prend en charge la conservation de certaines données qui sont nécessaires tout au long de la durée de vie d’un enchaînement. Par exemple, il peut s’agir de mémoriser un résultat qui est réutilisé plus tard dans l’orchestration. Les données mémorisées forme un contexte. A ce niveau il faut regarder les standards WS-Resource Framework (contexte lié à une endpoint Reference WS-Addressing) et WS-Context (intégré dans WS-CAF).
• Gestion transactionnelle : Les éléments assemblés lors de l’orchestration peuvent émettre des mises à jour dans les bases de données. Puisque ces éléments ne se connaissent pas entre eux, ils sont incapables de se synchroniser. C’est la fonction d’orchestration qui prend en charge la gestion d’une unité transactionnelle globale. A ce niveau ce sont les standards WS-TXM et WS-Coordination Framework qui devront amener des implémentations.
• Gestion de la logique applicative : Au-delà des rôles techniques de gestion de contexte et de transaction, la fonction d’orchestration assure un rôle applicatif. Elle contient la logique fonctionnelle d’assemblage des éléments et uniquement cette logique. Les règles métiers restent localisées dans les éléments assemblés. C’est en quelques sortes, la partie « workflow » de la fonction d’orchestration. Au plus haut niveau de la décomposition SOA, l'enchaînement des opérations et des phases par un processus peut s'envisager par une implémentation en BPEL (Business Process Execution Langage). Aux autres niveau de la décomposition SOA, il s'agit au mieux d'une génération automatique (et partielle) de code selon une stratégie MDA (UML 2.x avec les extensions algorithmiques sur les diagrammes de séquence est intéressants pour cette stratégie MDA).
• Gestion des traitements interactifs : Les opérations et les phases de type IHM enchaînent des écrans. La fonction d’orchestration s’appuie sur un framework technique de type MVC (Modèle Vue Contrôleur) spécialisé dans la gestion des conversations interactives. On trouve à ce niveau le standard des Web services Remote Portlet (WSRP).

Pour la liste des spécifications sur ces standards WS-*** et les autres, veuillez consulter sur notre synthèse des standards Web services

Gestion de projet SOA

Au niveau des services métiers, la particularité SOA réside dans l'existence d'une gestion de projet participative entre les maîtrises d'ouvrage et d'œuvre du fournisseur avec celles des consommateurs impliqués dans la spécification des services. Dans le cas où le fournisseur conduit le projet sans impliquer des consommateurs représentatifs, on revient à une démarche plus classique de conduite de projet.

Au niveau de la spécification des services qui forment l'architecture applicative (services exposés par les catégories et services internes à la catégorie) les consommateurs ne sont pas impliqués. Par contre, du côté du fournisseur, il faut prévoir l'intervention d'une cellule transversale d'administration des catégories afin d'unifier les catégories et de favoriser la réutilisation des services.

Sur ce schéma, le sigle TRS fait référence à la cellule transversale d'administration des catégories.

Modèle d'adaptation

Un modèle d'adaptation est une structure de données qui recense l'ensemble des paramètres susceptibles de faire varier le comportement du service. Une certaine valorisation de ces paramètres permet de créer une variante du service. Une variante est exécutable dans le cadre d'un contexte d'usage identifié. Ce principe de fonctionnement renvoie aussi au modèle d'architecture de gestion par les contextes (pattern de Context-Aware).

Généralement on utilise le format XML Schema du W3C pour créer le modèle d’adaptation. XML Schema est bien approprié pour la définition de paramètres notamment grâce aux facettes de contraintes et aux types étendus.

Quand on spécifie les services et plus particulièrement les services de type métier, il est déterminant de concevoir ce modèle d’adaptation. C’est grâce à lui que la création de variantes de services est possible, ce qui est déterminant pour la flexibilité d’exposition des services aux consommateurs.

Modèle logique SOA

Le modèle logique est un modèle d’organisation des classes qui permet de réifier les concepts SOA manipulés. La continuité entre les phases de spécification et d’implémentation du logiciel est indispensable :

• Le service métier se réifie à l’aide d’une façade dont chaque méthode représente une opération exposée par le service. Ces méthodes sont des orchestrateurs d’appels vers les services exposés par les catégories. Dans le cas d'une implémentation sous la forme de web service (c'est n'est pas une obligation), il y a une correspondance immédiate entre le concept de service métier et le web service.
• Les services exposés par les catégories, que l’on nomme services externes, sont réifiés à l’aide d’une façade associée à la catégorie. Chaque méthode de cette façade correspond à un service exposé par la catégorie. Selon les principes de la décomposition SOA, ces méthodes sont des orchestrateurs d’appels vers les services internes de la catégorie et uniquement de la catégorie d’appartenance du service externe (isolation des catégories entre elles).
• Les services internes à la catégorie sont réifiés directement sous la forme de méthodes attachées aux classes qui constituent l’agrégat de la catégorie.
• Le processus est réifié sous la forme d’une façade dont la méthode permet l’activation du processus. Selon les principes de la décomposition SOA, cette méthode est un orchestrateur d’appel vers les méthodes des façades des services métiers (pour l’activation des opérations) et des façades des catégories (pour la gestion des phases).
• Chaque catégorie forme un package de design (package UML) et de réalisation (package java). La catégorie forme aussi un espace de nommage qui sert de classification; dans le cas de l’usage de XML on met en place un NameSpace par catégorie.

Généralement, on associe à chaque façade une interface qui, selon les principes de la programmation par interface, permet de faire évoluer les implémentations des façades suivants plusieurs versions en limitant les impacts sur le code existant du côté des clients des services.

Opération

Une opération correspond à un traitement exposé par un service métier. Dans l'approche SOA, on admet qu'un service métier puisse exposé plusieurs opérations. Ce principe permet d'être conforme avec la terminologie du W3C sur les Web services, sans pour autant imposer que l'opération soit implémentée ultérieurement en SOAP-XML (ce qui reste un choix technique). L'opération est découverte à partir de l'analyse du processus organisationnel.

Lorsque l'on implémente le service métier en technologie web service, on dispose d'une correspondance sémantique et fonctionnelle immédiate entre l'opération du service métier et l'opération du web service. Evidemment, le choix d'implémentation en web service reste optionnel. On peut pratiquer la démarche SOA sans implémenter la technologie web service. Par contre l'inverse n'est pas pertinent. En effet, la bonne constitution des web services et des opérations exposées en SOAP-XML nécessite l'usage du cadre méthodologique SOA.

Les parties du processus organisationnel qui ne sont pas exposées sous la forme d'opération d'un service métier sont regroupées sous le concept de phase.

En final, un processus organisationnel est donc découpé en une série d'opérations et de phases. Le concept d'opération reste facultatif car il n'est pas toujours nécessaire de spécifier des services métiers, ce qui n'empêche pas d'utiliser la démarche SOA plus tard lors de la découpe des phases sous la forme de services attachés aux catégorises. Voir définition des concepts de catégorie et de phase.

Pattern d'architecture applicative SOA

Le pattern d’architecture applicative SOA s’appuie sur le concept de catégorie pour organiser la structuration du logiciel sous la forme de service. Il ne s’agit pas ici des services de type métier dont le contour fonctionnel est issu de la modélisation des processus mais des services de type externe qui traite d’une préoccupation de génie logiciel.

Pattern Context-aware - Modèle d'architecture de gestion par les contextes

Ce pattern permet la création de variantes de services grâce à un dispositif de gestion de paramètres. Les paramètres susceptibles de faire varier le comportement d’un service sont localisés dans un modèle d’adaptation.

Un produit logiciel permet de créer différentes valorisations des paramètres selon les contextes d’usage du service : un canal, un partenaire, une filiale… Ce produit dispose d’une console de paramétrage qui permet d’agir sur les variantes sans intervenir dans le code du service (principe même du paramétrage). Dans la pratique, cette console peut être utilisée par les maîtrises d’ouvrage afin d’agir de manière autonome sur certains paramètres du modèle d’adaptation.

L'organisation des variantes d'un service respecte généralement la logique d'un arbre qui permet de bénéficier des mécanismes d'héritage. Plus précisément, à partir d'une première variante d'origine (la racine) on peut créer des variantes filles et sous filles qui héritent les unes des autres. Par exemple, on peut utiliser ce dispositif pour créer un contrat d'utilisation cadre (un contrat est un ensemble de paramètres qui définit ses différentes clauses) puis grâce à l'héritage le décliner en multiple variantes selon les besoins d'exposition vers les types de consommateurs (filiale, partenaire, canaux…) puis les consommateurs au niveau nominatif (une organisation).

Phase

Une phase est un sous-ensemble dans un modèle de processus organisationnel qui n'est pas exposé sous la forme d'une opération d'un service métier. Le concept de phase permet d'organiser le processus organisationnel en sous parties afin de mieux maîtriser la complexité.

En final, un processus organisationnel est donc découpé en une série d'opérations et de phases. Le concept d'opération reste facultatif car il n'est pas toujours nécessaire de spécifier des services métiers, ce qui n'empêche pas d'utiliser la démarche SOA plus tard lors de la découpe des phases sous la forme de services attachés aux catégorises. Voir définition des concepts de catégorie et d'opération.

Plan-type Cahier des charges SOA et Contrat d'utilisation

Il faut définir deux plans-types importants pour encadrer la spécification et la mise à disposition des services métiers. Il s'agit d'une part du cahier des charges SOA qui contient la spécification complète de chaque service métier et qui peut faire l'objet d'une communication partielle aux consommateurs. Et d'autre part du plan-type du contrat d'utilisation du service qui reprend certaines parties du cahier des charges (notamment les préconditions, postconditions et exceptions) et ajoute d'autres informations indispensables pour la description des modalités d'usage du service et des devoirs des consommateurs.

Préconditions - postconditions

Une précondition est une règle qui renvoie une valeur booléenne permettant de décider de la possibilité de déclenchement du service ou non. Cette règle utilise sur les paramètres d’entrée du service et d’autres données propres au service comme par exemple certaines informations de son modèle d’adaptation.

Une postcondition est une règle qui détermine comment le résultat doit être restitué en fonction de chaque précondition ou groupe de préconditions.

Ces règles peuvent être représentées via une syntaxe OCL mais dans la pratique une description informelle est plus adaptée pour la validation avec la maîtrise d’ouvrage.

Voir aussi le besoin de validation automatique des pré-conditions et post-conditions au niveau des contrats de service : http://www.orchestranetworks.com/fr/soa/breves.cfm#040825.

Processus

Le processus est la description des traitements au niveau du modèle organisationnel et modélisé soit sous la forme d’un MOT (Merise) soit un Diagramme d’activités UML.

Le processus assure une fonction d’orchestration. Il orchestre l’appel aux opérations des services métiers et aux phases. C'est à partir de la modélisation du processus que les services métiers et leurs opérations sont découverts et spécifiés.

Service

Un service est une unité de traitement qui respecte les propriétés de couplage faible, d’exposition d’un contrat de service et qui correspond à l’un des types suivants :

• Service métier dont le périmètre correspond à une fonctionnalité que l'on souhaite exposer à un consommateur. Les fonctionnalités exposées sont regroupées sous le terme d'opération. Un service métier expose donc une ou plusieurs opérations aux consommateurs. Ce vocable est compatible avec celui des web services mais n'impose pas l'usage de SOAP-WSDL pour implémenter les services métiers. L'opération est un regroupement d'activité au niveau de la modélisation du processus. Le service métier est un concept qui fait sens pour les maîtrises d'ouvrage et maîtrises d'œuvre du fournisseur et du consommateur.
• Service externe attaché à une catégorie dont le périmètre est issu du pattern d'architecture applicative SOA. Ce type de service correspond à une préoccupation de niveau génie logiciel. Le service externe est un service exposé par une catégorie. Le service externe est un concept qui fait sens pour le fournisseur et qui n'est pas visible du consommateur.
• Service interne à une catégorie qui permet l'implémentation des services externes. Un service interne n'est visible que dans le périmètre de sa catégorie d'appartenance. Le service interne est un concept qui fait sens uniquement pour la maîtrise d'œuvre du fournisseur. Il n'est pas visible du consommateur.

A la différence du concept de composant, le contour du service n'est pas celui d'une frontière de code exécutable. Son périmètre est logique. L'implémentation physique du service s'appuie sur le concept de composant. Voir définition du concept de composant.

Service métier - Spécificités de conception

Quand on spécifie les opérations d’un service métier à partir du modèle de processus, il faut veiller à prendre en compte les caractéristiques importantes suivantes :

• Spécifier avec soin et de manière exhaustive les préconditions et postconditions de chaque opération exposée par le service métier. Ces conditions de déclenchement de l'opération et de restitution des résultats sont des informations présentées dans le contrat d'utilisation du service métier.
• Spécifier le modèle d'adaptation du service métier, c'est-à-dire l'ensemble des données qui sont susceptibles de faire varier son comportement selon ses futurs contextes d'usage. Par exemple, un même service métier peut avoir de multiples variantes de comportement selon qu'il soit consommé par un canal, une filiale, un partenaire, un client… Ce travail nécessite un effort particulier de conception avec la maîtrise d'ouvrage afin d'anticiper les futurs cas possibles d'usage du service.

Variantes de service

Une variante de service représente un comportement adapté du service par rapport à sa version d'origine. Il peut s'agir d'adaptation de nature très variée : présentation (marque blanche…), métier (offre commerciale…), technique (environnement d'exécution recette, exploitation…), qualité de services (plages de disponibilité, temps de réponse garanti…). La gestion des variantes s'appuie sur la mise en œuvre du modèle d'architecture de gestion par les contextes (pattern Context-Aware).

Versions - Gestion des versions

Les compteurs de versions portent sur les entités physiques de traitement c'est-à-dire les composants. Dans ce cadre, les composants qui réifient les concepts de services métiers, services externes et services internes font l'objet d'une gestion de version.

Le compteur de type GRC (Généralisation – Révision – Correction) évolue généralement selon ces règles :

• G++ si l'évolution du service nécessite que le code du consommateur évolue pour prendre en compte la nouvelle version du service.
• R++ et/ou C++ si l’évolution du service ne nécessite pas que le code du consommateur évolue pour prendre en compte la nouvelle version du service.

Lorsque l'on crée des variantes de service avec le modèle d'architecture de gestion par les contextes (pattern de Context-Aware) on ne modifie pas les compteurs GRC car le code des composants n'est pas modifié (on agit seulement sur la valorisation des paramètres).

Quand on déploie les services métiers sous la forme de web services SOAP-WSDL, il faut en plus gérer les versions des schémas XML (description des types de données qui transitent dans les messages des opérations des web services) et les WSDL qui décrivent le web service. Les règles sont les suivantes :

Pour les schémas XML :

• Si le nouveau schéma est compatible avec la version précédente alors on se limite à changer le numéro de version dans un « attribute version » du schéma. De cette façon, les instances XML existantes continuent d’être valides. Si les instances souhaitent savoir qu’une nouvelle version est disponible, c’est au parseur XML de traiter spécifiquement l’attribute version sauf si celui-ci est mis en required+fixed.
• Si le nouveau schéma n’est pas compatible avec la version précédente alors on change le nom de la targetnamespace en ajoutant le numéro de la nouvelle version. Dans ce cas, les instances XML existantes doivent faire référence à la nouvelle targetnamespace, ce qui les obligent à prendre en compte la nouvelle version.

Pour les WSDL :

• Toute modification du WSDL conduit à un changement de sa localisation. La stratégie de notification de la nouvelle version aux consommateurs dépend du contexte fonctionnel. L’outil de gestion des contrats d’utilisation des services doit techniquement permettre la notification de l’existence de la nouvelle version (email, workspace…). Ensuite en exploitation, des outils de vérification automatique de conformité de version sont mis en œuvre : contrôle la compatibilité d’un message SOAP avec un WSDL de référence (donc les schémas XML des types de données utilisés).