L'un des avantages de l'architecture SOA est qu'elle permet de s'éloigner du mode de penser "silo" en
informatique, le développement d'applications s'effectuant comme celui d'îles de fonctionnalités. Les applications sont
souvent considérées comme une intégration verticale de composants construits pour ce seul objectif. Il arrive souvent
que des projets de développement soient établis autour du développement ou de la maintenance d'une application et même
parfois que des équipes de développement ne soient responsables que d'une seule application. L'image suivante
représente la structure d'une application classique, indiquant que bien souvent la seule réutilisation entre des
applications est le partage d'une base de données commune.
L'approche orientée services donne une vue plus horizontale des applications comme étant l'intégration des services. En
réalité, tous les services d'un portefeuille de fonctions sont des pairs à partir desquels les applications, qui
peuvent à présent être envisagées comme des parties de solutions IT interagissant avec des utilisateurs, peuvent être
développées. Le diagramme suivant indique la façon dont l'application de passation de la commande peut être développée
comme un ensemble de portlets conçus pour les utilisateurs et devant être intégré dans un serveur de portail. Il montre
aussi que la logique métier est fournie par un ensemble de services utilisant à leur tour un ensemble de services
d'infrastructures.
Les services fournissent des composants déployés de manière indépendante, dont la granularité leur permet d'être
"auto-contenus". On obtient ainsi des services gérant et protégeant leurs propres magasins de données au lieu de
partager des mémoires de bases de données. Cela semble être en opposition avec la tendance observée dans certaines
entreprises qui, au fil des années, introduisent des systèmes de stockage des données communs ou du moins des modèles
de données communs que toutes les applications partagent. Une architecture SOA amène généralement les concepteurs à ne
pas développer des modèles de stockage des données communs, mais plutôt des modèles de messages communs facilitant
l'intégration des services grâce aux technologies middleware.
Comme nous l'avons déjà dit, les projets et les équipes de développement ont une portée et une visibilité limitées
concernant les fonctions, les exigences et les objectifs au sens plus large des services informatiques, ainsi qu'au
niveau des services pris en charge par l'entreprise. Dans l'optique de l'adoption de solutions orientées services
et d'une vue horizontale des solutions intégrées, il est donc essentiel que les architectes IT soient capables de
visualiser l'ensemble des services prenant en charge les solutions métier nécessaires au fonctionnement de
l'entreprise. L'un des avantages de la modélisation de services est qu'un modèle abstrait est capable de supprimer
certains détails et donc de présenter une vue plus générale de l'ensemble des services de façon évolutive, c'est-à-dire
qu'en présence de nombreux services, le modèle est capable de présenter des vues du portefeuille indiquant la prise de
décision de l'architecte logiciel et du concepteur.
Le fait que les organisations optent pour des architectures SOA entraînera évidemment une augmentation des services (le
portefeuille sera donc de taille réduite au départ), mais il est possible d'enregistrer l'état de la transition en
terme de services disponibles et planifiés. Le partitionnement des services est très important pour l'organisation du modèle
et la catégorisation des services à mesure que le portefeuille est développé.
Pendant les premières étapes de l'identification des services (voir Activité : Analyse des actifs existants), il est courant que les services candidats
soient capturés en tant que simple liste de noms, éventuellement structurée sous forme de liste hiérarchique ou
sauvegardée dans un tableur. Une liste de ce type est utile lorsque vous travaillez dans un environnement d'atelier et
que vous extrayez les services candidats de matériaux source. Avec l'augmentation du nombre de services candidats, une
liste non structurée peut rapidement devenir ingérable. Par conséquent, une structure hiérarchique de services doit
être identifiée dès que possible afin que les services candidats puissent être organisés en groupes au sein de la
hiérarchie de catégories.
Même si une simple liste de noms de service peut être un point de départ rapide, il reste important d'extraire des
informations supplémentaires sur chaque service. Ces informations peuvent être fractionnées en deux types : les
informations prenant en charge l'identification des services et les informations prenant en charge la spécification de
service. L'identification des services met l'accent sur la construction d'un portefeuille de services pouvant être
associés à des fonctions métier, des objectifs métier et des actifs tels que des systèmes existants et indique si le
service est considéré comme un candidat ou a été choisi pour être exposé. Le canevas de portefeuille de services peut
être utilisé pour documenter les services au niveau de détail nécessaire dans le portefeuille de services.
Il faut être capable de catégoriser les services dans un portefeuille de plusieurs manières, mais la plupart du temps
on emploie une terminologie qui décrit l'objectif, le propriétaire et l'organisation du service. Afin de prendre en
charge cette catégorisation ou cette classification, chaque partition de service a une propriété de classification
pouvant être utilisée pour spécifier le type de classification. Dans ce schéma de classification, le nom de la
partition devient une valeur.
Par exemple, le diagramme suivant (ou des modèles qui lui sont proches) a été développé par certaines entreprises pour
mieux visualiser les types de services contenus dans un portefeuille. Remarquez que cette catégorisation, bien que
commune, ne constitue qu'un exemple de segmentation du portefeuille de services. Dans cet exemple, chaque partition
porte le nom de sa "zone" de propriété de classification.
-
Les services des interactions utilisateur sont utilisés pour décrire la façon dont l'utilisateur interagit
avec l'application. Un service peut, par exemple,avoir besoin d'attribuer une tâche à un utilisateur humain ;
il faut donc qu'un service soit capable de prévenir l'utilisateur de cette tâche, puis d'avertir le service une
fois que la tâche a été accomplie.
-
Les services spécifiques aux applications, développés au sein d'une activité de développement jugée impropre
à la réutilisation, ne sont donc pas considérés comme faisant partie du portefeuille. Les services étant des
entités composables, il est également possible qu'un service fasse partie d'un portefeuille et que les services
imbriqués qu'il utilise ne soient pas publiés.
-
Les services d'intégration de processus, généralement fournis par un middleware à vocation commerciale,
fournissent la chorégraphie des services de façon à ce que les processus puissent avoir lieu dans le middleware et
utilisent les services dans le portefeuille pour implémenter un processus.
-
Les services d'intégration des services sont des services middleware à vocation commerciale qui fournissent
des services pour la formats des données et du contenu des messages entre les services ; par exemple, le message
d'un client peut être généré par le service constitué d'une agrégation de données provenant d'autres services du
portefeuille.
-
Les services métier sont des services propres à l'entreprise, développés pour elle et permettant une prise
en charge directe des applications développées pour prendre en charge le métier. On peut citer, par exemple, la
gestion client, les stocks, les ressources humaines, etc.
-
Les services d'infrastructure fournissent des fonctions IT requises par les services métier, mais aussi par
les services d'intégration. Des exemples de services d'infrastructure sont la messagerie, le répertoire,
l'authentification, l'accès existant, etc.
Pour obtenir plus d'exemples de types de classifications, voir le concept Partitionnement de services.
Pour la conception et l'implémentation, les concepteurs et les développeurs doivent donc avoir accès à un modèle de
l'ensemble des services, mais aussi à la spécification détaillée des services. Il est aussi possible que plusieurs
services implémentent la même spécification et un registre permettant la génération de requêtes ayant la forme "tous
les services implémentant la spécification de la commande" permet aux développeurs de composer des solutions à partir
des services existants et aux développeurs de l'intégration d'identifier les services à utiliser pour satisfaire les
exigences métier ou techniques.
Les référentiels des services peuvent également utiliser la valeur de classification introduite par la partition de
service pour compléter les valeurs comme des métadonnées décrivant les services contenus par le référentiel.
Par exemple, une solution peut demander un service d'expédition, le registre identifiant alors trois services
s'occupant de l'expédition ; deux de ces services garantissent la sécurisation des messages échangés, mais un seul
passe par Java Message Service (JMS), tandis que l'autre fournit SOAP avec HTTP. Les exigences métier spécifient
seulement que les informations client doivent rester confidentielles et donc que l'échange de message doit être
sécurisé. Les standards IT conseillant de ne pas utiliser JMS pour un service à distance, le choix est donc plus
limité.
Différentes implémentations techniques disponibles pour les registres de services :
-
UDDI : registre standard des services Web. Il fut très largement adopté et devait prendre en charge le
développement et l'intégration des requêtes temporelles. Toutefois, le niveau de personnalisation nécessaire pour
garder une trace de toutes les données associées à une spécification de service a certainement contribué à soulever
des questions sur le fait qu'UDDI est capable ou non de prendre en charge le portefeuille de services d'une
entreprise dont traite ce document.
-
Référentiel RAS : la spécification RAS devait prendre en charge la description personnalisable des
métadonnées d'éléments réutilisables et elle a en effet un profil de métadonnées pour les services Web. Si
l'objectif de la spécification RAS n'était pas de fournir un portefeuille de services, il serait cependant possible
de le faire pour les métadonnées temporelles de développement, bien que ce ne soit pas forcément conseillé pour
l'intégration de requêtes temporelles.
-
Personnalisation : de nombreuses organisations, devant cette multiplicité de solutions, ont décidé
d'implémenter des référentiels de services personnalisés, gérant un ensemble de métadonnées ou de documents de
conception pour les services au moment de la conception et en association avec les artefacts de services Web au
moment de l'implémentation. Dans la plupart des cas, un référentiel UDDI distinct est ensuite utilisé pour déployer
des services de production pour les requêtes temporelles d'intégration.
|