Université Du Québec Montréal: en Corrélation Avec Guide SWEBOK
Université Du Québec Montréal: en Corrélation Avec Guide SWEBOK
Université Du Québec Montréal: en Corrélation Avec Guide SWEBOK
MÉMOIRE
PRÉSENTÉ
PAR
MARTIN-PIERRE DUMOUCHEL
JUIN 2008
UNIVERSITÉ DU QUÉBEC À MONTRÉAL
Service des bibliothèques
Avertissement
La diffusion de ce mémoire se fait dans le respect des droits de son auteur, qui a signé
le formulaire Autorisation de reproduire et de diffuser un travail de recherche de cycles
supérieurs (SDU-522 - Rév.01-2006) . Cette autorisation stipule que «conformément à
l'article 11 du Règlement no 8 des études de cycles supérieurs , [l 'auteur] concède à
l'Université du Québec à Montréal une licence non exclusive d'utilisation et de
publ ication de la totalité ou d'une partie importante de [son] travail de recherche pour
des fins pédagogiques et non commerciales. Plus précisément, [l'auteur] autorise
l'Université du Québec à Montréal à reproduire , diffuser, prêter, distribuer ou vendre des
copies de [son] travail de recherche à des fins non commerciales sur quelque support
que ce soit, y compris l'Internet. Cette licence et cette autorisation n'entraînent pas une
renonciation de [la] part [de l'auteur] à [ses] droits moraux ni à [ses] droits de propriété
intellectuelle. Sauf entente contraire, [l'auteur] conserve la liberté de diffuser et de
commercialiser ou non ce travail dont [il] possède un exemplaire. »
L'auteur est un informaticien qui a été formé au niveau théorique par l'UQÀM, mais
au niveau pratique par IBM. Son intérêt découle directement de son expérience
associée aux soiutions EAI/AOS de IBM et de ses compétiteurs (i.e.: webMethods,
BEA, Microsoft, etc.). Il était, au moment de la rédaction de ce mémoire, chez
Hydro-Québec à titre d'architecte technologique et de lead développeur dans l'unité
d'informatique en mesurage et relève. Il a travaillé dans le groupe "logiciels IBM" de
2000 à 2001. De plus, il a débuté sa carrière de consultant dans une petite équipe,
chez IBM, qui répondait au nom de "affaires électroniques et intégration" . Lors de
son passage (2001-2005) dans cette équipe, il a eu la chance de participer à des
projets en clientèle ayant directement trait avec des technologies découlant de l'AOS
et de l'EAI. [GAVI2003] , [COXP2000], [WHAL2003], [WACKl 999]. De là provient
son intérêt pour cette sphère d'activité du domaine informatique. Il est certain qu'à
titre d'ancien IBMiste, il a probablement une vision quelque peu biaisée au niveau
technologie. Ce biais, il tentera de ne pas le faire transparaître dans cet ouvrage, voire
de l'effacer. Pour ce qui est de son intérêt pour le SWEBOK, il a été développé par la
lecture et l'approfondissement de ce document dans le cadre de ses cours de maîtrise à
l'ÉTS et à l'UQÀM. Il a apprécié la tendance à l'amélioration continue qui caractérise
ce genre d'ouvrage. L'auteur a donc décidé de joindre ces deux intérêts personnels
afin d'en générer un mémoire de maîtrise que voici. On se demandera probablement
pourquoi l'AOS ? C'est probablement lié au cheminement de carrière de l'auteur. Très
tôt, il a été confronté à des technologies à très forte tendance d'intégration de système.
Alors, il a vite développé un intérêt pour ces technologies. Mais en plus, il a vu,
111
En jetant les bases de ce mémoire, des objectifs généraux ont servi à l'orienter. Tout
d'abord, un premier objectif général est de déterminer la portée précise de l'ouvrage.
C'est-à-dire qu'il faut que le lecteur comprenne la portée du document. Ensuite, le
public cible a été pris en considération quant à la formule de présentation à choisir.
Un style plus littéraire que technique a été choisi, selon les recommandations du
directeur de recherche, Dr. Ghislain Lévesque, professeur au département
d'informatique de l'Université du Québec à Montréal. Il faut donc que le document
s'adresse bel et bien à son public cible. Puis, et non le moindre, l'identification du
sujet lui-même découle de l'objectif voulant que ce mémoire soit avant tout un
document de référence (ou du moins, humblement, les bases d'un éventuel document
de référence) sur l'architecture orientée-service.
contenu à un public cible plus large que seulement une communauté de développeurs.
C'est donc grâce à cet objectif que cet ouvrage a pris une tangente plus littéraire quant
à la présentation du contenu, plutôt que de demeurer un document purement
technique. Ainsi tous les membres d'une équipe de développement et/ou de
maintenance peuvent se référer, au besoin, à cet ouvrage. L'enseignant ou l'étudiant,
le chef de projet, en passant par l'archit~cte, l'analyste, le développeur et le testeur;
Cet ouvrage demeure assez général pour accommoder tous ces styles de lecteurs
éventuels.
TABLE DES MATIÈRES
AVANT-PROPOS ..... ..... ......... .... ......... ...... ...... ..... .. ..... .......... .... ... ... ...... .. ..... ... ...... ...... ii
Intérêts personnels de l'auteur .. .. ....... ... ...... ............................................................... ii
Objectifs Généraux du mémoire ...... ..... ..... ...... ........................................................ iii
À qui s'adresse cet ouvrage .... .... .......... .......... ...... .............. .... .... .. .... ....... .. ... .... ....... .iii
RÉSUMÉ ... ... .. .... .... ................ ......... ............... ..... .... .. ....... .. ....... .. .... ...... ...... .... ... ..... ... xii
INTRODUCTION ....................... ..... ....................... .......... ... .... ... ... ... .... ...... .. ..... ... ....... 1
1. Le mémoire ......... ..... .. ... ........ .... ................... .. ....... .... ..... ...... ............ .. ............... 1
2. Objectifs du mémoire ............. ... ...... ..... ........ .................. .. ... ..... .. .. .. .. ......... ...... .. 2
3. Comment est organisé cet ouvrage ............. ... ....... ....... ,...... ... ........................... 3
CHAPITRE I
L'AOS, UN SURVOL .. ........ ...... ...... .............................. .... ..... .. .................................... 5
Introduction .. .... .......... ... ........................................... .. ................................................... 5
1.1 Le défi de l'intégration ..... .... ... ... .. ..................... .. .. .. ....... ..... ... .. ..... ..... .... ... .. .. 6
1.1.1 Les causes .... ........ ... ..... ..... ... .. .... .... ... ... .. ......... ....................................... 6
1.1.2 Les manifestations .. .. ....... ..... .. ....... .. .................... .. ..... .... ..... ... .... .... ... .. .. 7
1.2 Les perspectives de solutions .. .......... ...... .. .. ... .... ...... ..... .............. .... .. .. ... ... .. 12
1.2. 1 Intégration des données ................... .................... .. ....... ....... .. ...... ........ 12
\...
1.2.2 Intégration des applications par les données ...... ............ ... .................. 13
1.2.3 Intégration par fonctions de programmation distantes ..... .. ...... ... .... .. .. 15
1.2.4 Intégration des applications par le biais d'outils middleware ...... ....... 16
CHAPITRE II
ASPECTS THÉORIQUES ........ ............ .................. ........ ... .. ........................... ........... 19
2 .1 Aspects distinctifs de l' A OS .......... .. .. ..... ... .. ....... .. .......... :.......................... . 19
2.1.1 Forte cohérence interne .. ... ................... .. ......... ...... .......... .. ... ........ .. ..... 19
2.1 .2 Couplage externe faible ... ......................... .. .............. ... .... ... ......... ... ..... 20
2.1.3 Modularité .... ...... ........ ....... ..... .. .................. ......... .... .... ... ... ..... .. .. ...... ... 20
VI
2.1.4 Service abstrait versus agent concret ............. .... .... ... .... ........... .... .. ..... 20
2.1.5 Notion de centres dans un processus plus large ......... .. .. .. ... .. ... .. ....... .. 21
2.1.6 Réutilisation du service .. ...... ..... .... ..... .... ..... .. .. ... ....... .......... .. ... .. ..... .... 21
2.1.7 Notion de description d' un service (ou contrat) .. .. .... .. .... .. ... ........ .. .. ... 21
2.1.8 Généralisation et ré-utilisation ..... ....... .. .... ...... .. ... ..... .. ... ..... .. ... .. ...... ... 21
2.1.9 Découvertabilité ( .. .qui est découvrable ... ) ...... .... .............. ..... ....... .. . 22
2.2 Limites ..... .. .. .... .. ..... ........ .. ....... ........... ... .... ..... .. .... ..... ... ....... ... ... .. .... ..... .... .. 23
2.2.1 Impact d' une panne d'un service .. ....... ................... ....... .... ....... ... ... .... 23
2.2.2 Notion de sécurité ... .. ........ .. .. ... ... ..... .. ....... ... ..... ...... .... ......... .. ... .... .. .... 23
2.2.3 Niveau ou degré d' ouverture technologique .. .. ... ............. ...... .......... ... 25
2.2.4 Limites de l'infrastructure technologique choisie ...... ....... .. .. .... ....... ... 26
CHAPITRE III
SITUATION HISTORIQUE ...... ..... ............ .... ... ..... ... ... ...... ............... ....... ............ ..... 27
3.1 L'intégration avant l'architecture orientée-service .. .. .. ........ .. .... .... ..... .. ....... 27
3 .1.1 Les sockets (TCP/UDP) ...... .... ..... ..... .... ..... ... .. .... ... ..... .... ..... ... .... ....... . 28
3 .1.2 Le FTP (File Transfer Protocol) ... .... ... ....... ... .... .... .... ...... .. ... .. .... ... .... .. 29
3 .1.3 Le RPC (Remote Procedure Call) .. .. .. .. .. ... ...... ............ ... .. ... ..... .. .. .. .. ... 30
3.1.4 Le CORBA (Common Object Request Broker Architecture) .. .. ... ...... 31
3.1.5 MOM (Message-Oriented Middleware) ... .. ... ... .. .. ... ... ..... ... .. ...... ..... ... 33
3.2 Pendant la vague de l'AOS .......... ..... .. ......... ....... .. ... ... ....... ...... .... ............. .. . 34
3.2.1 Intégration d'Application d'Entreprise .... .. .... .. ..... .. ... .. .. ... ... .. .... .. ... ... .. 34
3.2.2 ETL (Extract, Transform & Load) .. .. .... .. .......... ......... .. .. .. .. .. ... .... ...... .. 35
3.2.3 MDB (message-driven bean) ... ... ...... .... ........... .... ..... .. ....... ... .... ..... .. ... 35
3.2.4 Technologie WS (Web Services) ....... .. ... .... .. ... ...... ... .. .. ... .. ....... .... .. .. ... 37
3.2.5 Web 2.0 et la promotion du SOA .... .... .................. ... .. ............. .. ........ .. 38
3.3 Datation approximative des différentes teclmologies d'intégration .. ... .. .. .. . 40
3 .4 Les difficultés rencontrés ....... ...... ... .. ... ... .... .... .... ... .... .. ........... .... ... ... ... ...... . 41
Vll
3 .4. 1 Responsabilité des livrables et produits ... ... .. ..... ........ ... .. ... ... .......... .... 41
3.4.2 L'approche par cas d'utilisation difficile? .... .. ... ........ ...... ..... .. ...... .. ... .. .42
3 .4.3 Le choix d'une technologie d'entreprise est difficile .. .. .... ...... ............. 43
3.4.4 Lamodélisation ... .. ... ..... .... ... ............ ... .......... ...... ...... ...... .. ...... .... ..... .. . 45
3.5 Les perspectives qui se dégagent actuellement ....... .............. ...... ............... .45
3.5. 1 Le vent dans les voiles des services Web et du Web 2.0 ..... ... .. ... ....... 45
3.5.2 L'arrimage des méthodologies .... .... ... .. .... ... .. ....... .... ..... .............. .... .... 46
3.5.3 L'arrimage de la modélisation .. .... ....... .... .. .. .. ...... .... .. ...... .......... ..... ..... 47
3.5.4 Les offres de formation sont compétitives .... .......... ... .. .... .. ................ .47
3.5.5 Émergence technologique ....... .... ... ... ..... .. ...... ..... .. .. .............. ........... ... 47
3.5.6 La difficulté de cerner l'AOS perdure ................... ...... .. ... .. ............ ..... 47
CHAPITRE IV
L'AOS EN CORRÉLATION AVEC LE SWEBOK .. ..... ...... .... .... ... ......... .. ... ..... ....... 49
4.1 Comment est organisé le chapitre 4 ..... ....... ..... .......... ....... ............ .. ............ 49
4.2 La problématique abordée par ce mémoire .. .. .............. ............. ...... ....... ..... 50
4.3 La justification d'un guide sur l'AOS ......... ... ............. ..._.............................. 52
4.3.1 Pourquoi le SWEBOK? ... .... ...... ........... .... ............ ........ .. ........ .... ... .. ... 52
4.3.2 Justification générale ... ... ... ..... .. .... .... .. .... .. ....... .... ... ............ ................. 54
4.4 Objectifs d'un guide sur l'AOS ..... ........ ... ... ....... .. ...... .. .. ..... ....... ...... ......... ... 54
4.5 Contributions associés au SWEBOK ... ........... ........ ... .......... ....... ... ........... .. 56
4.5 .1 Exigences du Logiciel Orienté Service .. ................................... .... ... ... 57
4.5.2 Conception du Logiciel Orienté Service ............................. ....... ......... 64
4.5.3 Construction du Logiciel Orienté Service ... .......... ..... ...... ... ............. ... 77
4.5.4 Essai du Logiciel Orienté Service ............................. ..................... .... 85
4.5.5 Maintenance du Logiciel Orienté Service ... ..... .. ..... ..... .... ............. ..... . 92
4.5.6 La Gestion de Projet .. .. .. ... .... .. ........... .... .... .. ..... ..... .. ... .............. ........ ... 96
4.5.7 Gestion de la Configuration du Logiciel Orienté Service ... .... .. .. ...... .. 99
Vlll
1. Le mémoire
L'architecture orientée-service est un vaste sujet tant commercial que technique. Dans
une vision des sciences de la gestion ou d'études commerciales, on pourrait remarquer
qu'il s'agit d'un phénomène à part entière de l'industrie informatique, de la même
ampleur que l'intégration d'applications d'entreprise par exemple, ou encore que le
paradigme client-serveur. Avec une vision plus scientifique de ce sujet, on peut y
trouver un grand intérêt tant le côté technique est intéressant, voir bouleversant pour
le domaine de l'informatique.
Ceci étant dit, il a fallu concentrer la vision, focaliser vers un ensemble d'objectifs
clairement définis et réduire la portée de l'étude pour finalement produire un livrable
qui formerait un mémoire de maîtrise en science informatique avec spécialisation en
génie logiciel.
Le résultat visé est la base d'un ouvrage de référence utilisable par une équipe de
développement et/ou de maintenance d'un système à architecture orientée-service. Le
but n'est pas d'étudier à fond le côté technique et scientifique de l'archit~cture
orientée-service, ou d'une de ses implémentations, mais plutôt de créer les bases d'un
guide de génie logiciel à saveur architecture orientée-service.
2. Objectifs du mémoire
Dans tm contexte plus formel, voici les principaux objectifs du mémoire, qui
reprennent certains aspects présentés dans la section précédente.
Tout d'abord, le sujet principal, soit l'architecture orientée-service, doit être traité en
effectuant un état de l'art. Ainsi le chapitre I (l'AOS un survol) et II (Aspects
Théoriques) devront y répondre.
Afin de valider la qualité des réponses aux objectifs précédents, ainsi que d'en
déterminer les limites, une technique de validation du mémoire est défini au chapitre
V (Validation).
La conclusion amène des perspectives d'utilisation d'un tel guide et des suites à
donner afin d'indiquer les étapes et moyens pour en assurer la diffusion et l'évolution.
L'AOS, UN SURVOL
Introduction
Mais, on peut aussi avancer que l'architecture orientée-service est une évolution
normale de l'architecture client-serveur en conjonction avec le domaine des systèmes
répaitis. Mais c'est avant tout une solution au problème de l'intégration des systèmes.
Ce mémoire porte donc principalement sur l'architecture orientée-service en se
penchant sur le problème du manque de support au développement de telles
architectures. Il est important de comprendre que l'AOS n'est pas une technologie,
mais bien une approche architecturale. De plus, bien que le nom et la prise de
conscience de cette approche soit récente, cette approche existe depuis longtemps,
mais n'était pas clairement définie ni même reconnue par l'industrie. L'émergence des
services web a donné beaucoup d'importance à ce type d' architecture et a aussi donné
lieu à un éventail incroyable d'ouvrages de référence sur le sujet. Les références sont
présentées à la fin de cet ouvrage. Ce mémoire se penche sur les services web, mais
ils sont traités comme une tangente, bien que principale, de l' architecture orientée-
6
service et non comme étant le centre et le cœur du sujet. Il tente donc d'apporter un
certain support au développement orientée-service en se fondant, au niveau de la
structure et du contenu, de ce guide sur le génie logiciel qu'est le SWEBOK
(software engineering body of knowledge).
1. 1 Le défi de l'intégration
1
Voir la note de bas de page.
N.B.: Cette section du mémoire est une introduction au sujet et est traitée d'une façon
plus personnelle de la part de l'auteur que le reste du contenu. C'est donc une forme
Les données, leurs sémantiques, l'utilisation différentes qu'en font les divers
systèmes, ainsi que les natures technologiques différentes sont toutes des causes
potentielles rendant lourde, complexe et difficile l'intégration de systèmes. On
pourrait deviner ces causes à partir des technologies offertes et couramment utilisées
dans le marché, parce qu'elles tentent toutes de résoudre un certain ensemble de
. problèmes. En identifiant les problèmes soulevés par une technologie d'intégration de
système, il est facile d'en déduire les causes. Par exemple, les produits de ETL
(Extract Transform & Load) [DENG2005] résolvent quelques problèmes en
commençant par la divergence des schémas de base de données entre des systèmes
devant, en principe, partager les dites données. Or la cause apparaît lorsqu'on se
demande, dans ce cas précis, pourquoi les schémas de base de données sont-ils
différents entre des systèmes devant, en principe, partager ces données? Les quatre
causes énumérées en début de paragraphe répondent toutes ensemble à cette question.
Domaine A
Schéma BD 2 Schéma BD 3
Schéma BD 1
Dans la figure ci-haut, trois systèmes créés à trois temps différents ont un schéma BD
qui diffère d'une façon ou d'une autre pour un même domaine d'application.
On peut alors remarquer que différents systèmes d'un même domaine d'application
[ABRA2004] traitent parfois des données semblables, similaires, parentes ou
complémentaires en utilisant des schémas de données précis et donc différents les uns
des autres.
idéalement de réduire les différences entre les schémas implémentés pour un même
domaine d'application.
• Soit un domaine d'applications données pour lequel plus de deux besoins distincts
d'utilisateurs, qui doivent nécessairement mener à deux systèmes distincts (ex: un
système de facturation et un autre d'acquisition pour le domaine d'application
ferroviaire) ; on retrouve normalement deux utilisations différentes des données
potentielles du domaine (ex: identifiant unique d'un wagon). La première, pourrait
utiliser les données du domaine ferroviaire pour créer et gérer des factures,
ajoutant par le fait même des transactions et des données propres à ces activités, et
la deuxième pourrait faire de même, c'est-à-dire ajouter des transactions et des
données propres à ces activités d'acquisitions pour le domaine ferroviaire. Le tout
en créant des disparités au niveau des données. Par exemple, l'identifiant unique
d'un wagon peut être basé sur la même idée fonctionnelle, entre deux schémas,
mais dont l'implémentation diffère, et donc une disparité évidente apparaît au
niveau des valeurs d'un même champ fonctionnel (l'identifiant unique d'un
wagon) d'un domaine d'application. Dans cet exemple, l'un pourrait utiliser la
10
1978 2004
CNA78629BG7 US20070601#467955
Figure 2 - Disparité dans le temps lié à un domaine d'application qui se reflète dans les schémas
BD
Une deuxième manifestation évidente est aussi reliée aux natures technologiques
différentes qui peuvent (et le sont très souvent) être utilisées pour répondre aux
différents besoins d'un même domaine d'application.
Librairie Librairies
d'encryption incompatible
No carte de crédit
propriétaire Java
(encrypté par .Net)
L'intégration au niveau des données donne lieu à diverses tendances telles que les
technologies E.T.L. (extract transform & load), ou à des solutions de convergence
des données de SGBD hétérogènes en un centre logique commun d'outils tels que
DB2 Information Integrator. Elles ont tentées d'apporter des réponses avec un certain
succès.
Source
Dans l'illustration ci-haut, un système A utilisant une certaine base de données sera
interprété comme étant la source. Un autre système (existant ou futur) sera quand à
lui lié à la base de données que l'on peut interpréter comme étant la cible. Le moteur
ETL a pour but d'exécuter l'extraction des données cibles, la transformation voulue et,
finalement, le chargement des données cibles. Le référentiel ici n'est qu'un artifice et
est propre au moteur ETL seulement. Ont peut aussi comprendre qu'initialement une
technique ETL n'est pas vouée à être utilisée en mode transactionnel, ni en ligne ou à
la demande, mais bien dans le cadre de travaux de transformation de données afin de
fournir et charger des données à un système cible.
~ - - - - -~ ,,-
Legae>/ Orner Manageme · [
Application E ·.erprise Applicaiion
t
Custom Connector 1 Applicaoon Connector 1
lnterChange SNVer
0 0
Applicaiion Connecter
Application Contrnctl
Connect1on
Manager Resource Adapter
Transaction
Manager
EIS spedfic
interface
Securlty
Manager ~~\.~.~~~ .
, • Ente{Pnse Information .
System·
Connection Management
Securlty Management
Transaction Management
d'intégrer des technologies autres (ex: SAP, Siebel, etc.), avec des composantes
applicatives Java EE.
Bien sûr d'autres exemp_les existent. D'ailleurs cette idée a même été reprise pour
arriver à d'autres solutions d'intégration.
donc prendre en exemple MQSeries Integrator qui représente un outil beaucoup plus
riche se basant sur les qualités d'un système orienté messagerie. D'autres outils
centraux sont plutôt basés sur l'orientation "appel de procédures distantes" en
utilisant les RMO ou RPC par exemple, ou encore les sockets. Ainsi Microsoft
Transaction Server, les serveurs CORBA, les serveurs de services web, ou encore, les
serveurs de beans d'entreprise (J2EE), sont des environnements centraux qui
permettent le déploiement et l'exécution d'objets/services dans le but d'intégrer et de
réutiliser les objets/services. Dans cette veine, la notion de bus d'entreprise tente sa
chance dans le domaine de l'intégration de système et de la réutilisation de fonctions.
On voit donc des technologies telles que Web Method, MQSeries Integrator et
WebSphere Business Integration Foundation Server, ainsi que d'autres serveurs basés
sur la notion de BPEL (Business Process Execution Language) tenter leur chance.
De tous ces outils centraux, la plupart de ceux qui persistent en 2006 sont basés soit
sur les services web (incluant le BPEL) ou sur des systèmes orientés messagerie.
shared
infrastructuN!, ·
servers,
engines,
data bases,
security, etc.
En conclusion, dans l'illustration ci-haut le middleware est une solution qui agit entre
les systèmes à intégrer de sorte à supporter les difficultés d'intégration à l'aide de
divers outils qui diffèrent d'un type de middleware à l'autre.
Dans cet exemple, il faut considérer que la composante du haut (Web Applications à
titre d'exemple) utilise le middleware afin d'encapsuler les difficultés techniques afin
de communiquer avec un éventuel deuxième système (qui n'est pas illustré).
CHAPITRE Il
ASPECTS THÉORIQUES
2.1.3 Modularité
Le service encapsule des fonctionnalités qui représentent des centres de valeurs pour
une organisation. Dans un processus plus large, ces centres de valeurs peuvent
devenir des nœuds dans un processus, dans un flux. C'est-à-dire qu'il est possible de
chorégraphier les services afin d'utiliser les divers centres de valeurs d'une entreprise
· afin d'élaborer des applications [ALEX1996], [MURP2004].
La réutilisation des fonctionnalités est un des buts principaux de l'AOS. Par contre, ce
n'est pas l'AOS qui a amené ce besoin, cette idée. C'est donc une caractéristique
héritée d'autres courants antérieurs du génie logiciel [NATl2003-A].
La description de l'interface d'un s~rvice est à la base de l'AOS. Le contrat est ainsi
r
défini entre le consommateur et le producteur de service. Cette description comprend
les notions d'adressage, de nom de fonction, de structures de données en entrée et en
sortie, et d'autres détails servant à découpler les détails d'implantation [CHAV2004].
Il s'agit d'un aspect distinctif apporté par la technologie UDDI (Universal Description
Discovery and Integration) et principalement utilisé dans le cadre des services web. Il
s'agit d'une base et d'un service de découvertabilité qui répertorie l'ensell}ble des
services disponible sur un réseau. Cet aspect distinctif est discutable, mais à cause de
la portée du UDDI dans les services web, il est noté ici.
Criteria iscover
1 b ••• • •~ Service - E)\EJ
Requester Entity ,: .JJJ..•j c
·. ./ l~oJ ',1.a. \ Provider Entity
---- --- ----------------- 1 · ·- i. r;~:-î_ 2. 1 --- - -- ----------- -- --- --
1 J
H•=,x .. - -
Requester :,... ....
--- - -
- - ~ A,;::"u
: .2.P ·d
[~~}~3.
+ ~
3. / t +
•
_
:==1
1WSD J ~ ~ 1WSD l
'
''
''
''' -
lnteract
-
4. :.
@ nt
''
1_ - - - - - - - - - - - - - - - - - - - - - - - - 1_ - - - - - - - - - - - - - - - - - - - - - - - -
2.2 Limites
qui rend donc la reproduction d'un appel d'autant plus facile. La notion de sécurité
devient donc un enjeu des plus importants lorsque l'on parle d'architecture orientée-
service. C'est peut-être selon l'orientation technologique que la dimension de sécurité
de l'AOS s'ajuste ([COTR2004]).
Prenons par exemple, certains hôpitaux québécois qui utilisent des technologies
orientées- service afin de maintenir et distribuer les données ayant trait aux dossiers
patients. Il est de toute évidence légalement interdit de permettre la divulgation au
grand public de ce genre de données par un hôpital. Il faut donc s'assurer que malgré
le fait que les méthodes d'accès aux services soient standardisées et donc facilement
reproductibles, les couches de sécurité, elles aussi standardisées, parviennent à
neutraliser les accès indésirables. Comme telles, les notions de base de l'architecture
orientée-service ne dictent pas de méthodes de sécurité des services. Plutôt, il est
remarqué que certains standards naissent des besoins exprimés par l'architecture
orientée-service tels les services web du W3C . Par contre l'AOS , lui-même, a été
utilisé pour définir des stratégies de sécurité comme il est mentionné et expliqué dans
la référence [IMAM2005]. On y voit qu'IBM a utilisé des notions de l'AOS afin
d'élaborer sur le sujet. Dans le même ordre d'idées, d'autres besoins plus spécifiques à
de tels standards donnent naissance à l'adaptation ou carrément à la mise sur pied de
nouveaux standards ou protocoles. D'ailleurs, au sujet des services web, on pourrait
noter la réutilisation/adaptation des protocoles de sécurité de la couche de transport
(ex: HTTPS ou encore SSL) pour ce qui est de l'encryption des échanges réseaux. Au
niveau de l'autorisation et l'authentification, d'autres standards/protocoles tels LDAP
sont utilisés pour gérer les accès.
25
SITUATION HISTORIQUE
Il s'agit ici d'élaborer sur les techniques d'intégration ayant précédé l'AOS avant de
situer celles ayant vu le jour dans les dernières années. Elles sont abordées à des fins
de situation historique. Ensuite, il s'agit d'une discussion des difficultés rencontrées
par les diverses techniques d'intégration, et plus particulièrement celles plus récentes
auxquelles ont peut associer l'AOS. Finalement, on y retrouve quelques perspectives
de solutions à ces difficultés.
Mi M2
8
1030
_J
<Mi, i 030, M2, 7623>
= socket d'écoute
À partir de la figure 9, le programme client a un socket d'échange qui sera utilisé pour
échanger des données avec le programme serveur qui lui a deux sockets. Le premier
est utilisé en mode écoute afin de recevoir des demandes de programme client. Le
deuxième est utilisé pour échanger des données avec le ou les programmes clients.
29
La communication par socket est à la base des échanges de données entre des
processus sur w1 réseau TCP ou UDP . Il s'agit donc d'une technique fortement utilisée
dans le domaine de l'intégration de systèmes, et donc dans le domaine de l'AOS.
Il s'agit d'une solution permettant d'échanger des données entre des machines
distinctes sur le réseau. Il s'agit là d'une première technique qui fut utilisée afin de
faire communiquer des processus distants ensemble. Cette technique est d'ailleurs
encore largement utilisée aujourd'hui [JPOS 1985]. Voir la spécification
http ://www.ietf.org/rfc/rfc959.txt qui date de 1985 .
Se1vei- Client
PI Pl
Selv'l!r Vse1·
DTP DTP
Sy~-1:è Il') e
dé fid, 1ers
Figure 10: Le modèle FTP (diagramme www.co mm entcamarche.net)
Dans le diagramme ci-haut, deux canaux sont utilisés. Le premier est utilisé afin de
permettre l'échange des commandes et des réponses aux commandes. Le second est
utilisé dans le but d'échanger les données. L'utilisateur est normalement au niveau du
30
client. Le but du FTP est de permettre l'échange de données entre deux systèmes sous
forme de fichiers (texte ou binaire), incluant les répertoires.
Bien sûr le FTP est u_tilisé par des humains, mais il est aussi couramment utilisé par
des scripts afin d'élaborer des systèmes automatisés dont les échanges de données se
font par l'entremise de FTP. En ce sens, FTP est définitivement utilisé afin d'intégrer
des systèmes hétérogènes par le biais d'échanges de données sous formes de fichiers .
G)
Calling .,....... ··;;·è threaél -~,\ Called
remote
code .._____~
•····· ........~
.,,. procedure
Client
~
~~01Call thread
application
.......~~ thread .......~~~~~~~~~_,
CORBA sera ensuite introduit afin de définir une méthode orientée-objet permettant
de procéder à des fonctions distantes (liées au modèle RPC). On peut encore voir ici
une solution permettant de faire communiquer ensemble des processus distants.
[0BJE2006] , [COXP2000]
32
1 IDL 1 Implement · 1
..j;
Interface Implement .
repository repository
a) c r é a-t:ton d'objets
Applic ation
(Interface)
Interface
Inte1.·face - selon tn>e
~~~-
standard cle
f------l
Service :s~)ib<<:::·. c~osant.
Invocation >iriL <,: <·>>
dynamique : :è ~ù~::::
b) mise en oeuvre
Architecture CORBA
Dans le diagramme d'architecture CORBA, ont peut retenir qu'il s'agit d'une
technique beaucoup plus complexe que les autres vues jusqu'ici. Il s'agit aussi d'une
technique qui respecte beaucoup plus quelques principes théoriques de l'AOS tels que
décrit dans cet ouvrage. Que ce soit le couplage externe faible, la modularité, l'idée
du service abstrait versus agent concret, la notion de centres dans un processus plus
lai:ge, la réutilisation, la notion de description d'un service, l'architecture CORBA est
un excellent premier effort en ce sens. Cette architecture est d'ailleurs encore .
fortement utilisée. Par contre, cette technique est plus complexe que d'autres qui ont
été proposées par après telles les services web.
· 33
Me$s,aging
Provlder
A A
Clien1 P Ms91 P Client
1 l
Send Aeceive
Dans l'illustration suivante, le client gauche communique avec le client droit à l'aide
de l'envoi et la réception de messages, le tout géré par le fournisseur de messagerie.
34
Hub-and-spoke
Il s'agit de centres (nœuds) d'exécution, soit les hub, puis des liens entre ces centres,
soit les spoke en anglais.
Les MDB sont une technique mis en route par l'initiative J2EE (Java 2 Enterprise
Edition). Ils s'agit d'une composantes technologiques. Elles sont la conjonction entre
les EJB (Enterprise Java Bean) et les techniques de messageries, implémentées
principalement en Java à travers le JMS (Java Messaging Service. Ces composants
36
sont particulièrement utiles afin de créer des tâches asynchrones dans le cadre d'un
serveur J2EE. [WHAL2003]
JMS
Componll!nt
.1.v1,c;
Me>xiii':Jll
Pro d:.Jœrs
x - ....--- r- - ï Application
or
JIJIS Message service
:\ '-
'\ EJB Cont.ainll!r Message
~-
\. .......__ R outing sncl
Delivery
~ Desti'la1ions
IJIDB Contailler : _,..,,-
JMS
- - ~_,..,,-
Message --___;__
Consumer :
MDB _
r1, Instance ~ - - . . . nnM,i.<:<:ll!JA
: melhod
Cette technique est fortement utile dans les environnements Java pour entreprise
(JEE).
37
Setvice
Broker
&,VSDL
...
SOAP
Service Service
Requester Provide<
Les services web font leur apparition au début des années 2000 afin de standardiser
les techniques de communications entre des processus évoluant sur des
environnements hétérogènes distants. Les services Web reposent sur le protocole http
(HyperText Transfer Protocol) et SOAP (Simple Object Access Protocol) .
[BOOT2004]
Les services web sont sans l'ombre d'un doute le fer de lance de l'architecture
orientée-service. A~cune autre technologie n'est aussi fréquemment référencée
lorsqu'il est question d'architecture orientée-service. De plus, des fournisseurs, qui
normalement ne permettent pas l'interopérabilité de leur plateforme avec d'autres, ont
embarqué dans ce mouvement (i.e.: Microsoft).
héritées, voir adoptées les services web dans le but de permettre l'échange de données
qui a beaucoup de valeur commerciale. Ainsi, les BPEL (Business Process Execution
Language - technologie standardisée ayant pour but de composer des processus
d'exécution utilisant directement d' autres services), les WebMethods avec utilisation
des WS , les IBM Business Integration Solutions, etc., ont vu rapidement le jour afin
d'attaquer le marché au bon moment. Jamais l'intégration des systèmes n'avait été si
omniprésente dans les offres de nouvelles technologies des grands et plus petits
fournisseurs de solutions. Ceci nous amène directement à la vague Web 2.0.
Le Web 2.0, véritable plate-forme informatique à part entière et non seulement une
collection de sites web, comprend le SOA (Service-Oriented Architecture). Elle
donne des ailes à l'AOS pour ainsi éclipser les "anciens noms" tels que EAI
(Enterprise Application lntegration) et simplifier le discours . Le Web 2.0 débute vers
2004. [HINC2006], [OREI2005]
39
Ajax Podcasts
13 09
' Réseaux RSS wiki
. , ss . p2 p BI og
Reseaux Blog Blog
Blog
Réseaux
Web 2.0 .~ss Podcasts Ajax Blog
• P:?.P Blog iP ,
AJaX AJ·ax lh~ ,Reseaux
61-0g
Podcasts Reseaux Wiki
m,.1 9 Blog
Dans l'illustration précédente, on peut par contre comprendre qu'il sera toujours
difficile de bien préciser ce qu'est le Web 2.0 tellement la question est large. En fait,
toutes les nouvelles technologies susceptibles de faire avancer la cause technologique
de l'Internet, font partie du Web 2.0 (ou presque). Dans l'illustration ci-haut, seule une
petite partie des technologies faisant partie du Web 2.0 sont en fait illustrées. Il faut
comprendre que l'AOS et les WS ne touche beaucoup moins les internautes que les
technologies avec lesquelles ils pourront directement interagir (ex: AJAX, les blogs,
les wiki, etc.). Mais qu'importe l'AOS fait partie intégrante de cette grande vague
commerciale qui déferle sur le marché au moment de la rédaction de ce mémoire. Par
son approche back-end, elle est moins près du grand public voilà tout. Il faut
comprendre que le lien entre l' AOS et le Web 2.0 n'est que commercial dans le but
de mousser la mise en marché de quantités d'autres nouvelles technologies
impliquées par le Web 2.0.
'
40
Il s'agit ici d'une ligne temporelle exprimant dans quel ordre approximatif les
différentes technologies, dites d'intégration, sont apparues . Les références données ici
ne comportent pas toutes la date exacte de début d'existence des technologies qu'elles
impliquent.
2000
1971 1976 1985 1990 1992 1997 Seivices Web & 2004
Sockets RPC FTP ETL CORBA & MOM & DCOM RMI EAI Web 2.0
*Références:
Socket [WINET 1971]
RPC [OPEN1997]
FTP [JPOS1985]
ETL [DENG2005]
CORBA [OBJE2006]
MOM [BEAM2000], [WACK1999]
DCOM [GERA1999]
RMI [SUNM1997]
Services Web [KEEN2006]
EAI [PUTT2000], [GAVl2003]
41
Web2.0 [HINC2006]
*Il est à noter que le gestionnaires de transactions CICS d' IBM a été mis sur le
marché en 1969 et que son ancêtre, le système IMS a été développé dans le cadre du
programme spatial Apollo en 1966. Ces techniques, bien qu' anciennes sont encore
couramment utilisées par de grandes institutions et banques, par exemple, dans le
cadre de systèmes legacy.
Commerce électronique -
Système d'acquisition de
matériel industriel
0
SAP - Système de gestion du
Centrale - Système de gestion cycle de vie de produits
de flotte de pièces ma nufacturiers
aéronautiques
Figure 18: D ifficul té d'attrib ution de la propriété des livrab les fo nction nels
Dans le domaine de l'intégration des systèmes, dont l'AOS fait partie intégrante, il est
souvent difficile de bien balancer l'attribution de la notion de propriété des livrables
puisque l'environnement est typiquement éclaté et couvre souvent plus d'une
organisation interne déjà existante et en fonction, en plus, parfois, de nouvelles
organisations externes. Ce problème peut s'accentuer au niveau contractuel et légal,
voir encore plus, lorsque le système dépasse les bornes de plus d'une entité légale
(plus d'une entreprise).
Il ne s'agit pas de cas d'utilisation tel qu'on le connaît, mais bien de composants
logiciels inter-système [ALEX 1996]. Aussi, l'analyse attribuée à la couche logicielle
du type AOS est mise de côté par rapport à ce qui est beaucoup plus évident comme,
par exemple, les écrans. De plus, la plupart du temps, les livrables fonctionnels sont
liés aux cas d'utilisation, et encore plus précisément aux écrans d'un système. Par
exemple, le livrable P490 de la méthodologie P+ est presque toujours utilisé dans le
cadre d'écrans. Or qu'en est-il des services? Il est beaucoup plus facile de ne pas tenir
compte de la valeur d'un livrable de la phase d'analyse dans le cadre de l'AOS que
dans le cadre d'écrans (interfaces personne-machine).
Bien que l'approche des cas d'utilisation se prête bien à l'AOS, il est ancré dans nos
mœurs que les acteurs d'un cas d'utilisation sont plus souvent qu'autrement les
utilisateurs et non des consommateurs étant possiblement d'autres services, d'autres
systèmes, des gens, etc.
Voici une citation de la définition de 'Cas d'Utilisation' sur wikipedia (en français en
date du 2007-04-04):
"Chaque cas d'utilisation contient un ou plusieurs scénarios qui définissent comment
le système devrait interagir avec les utilisateurs (appelés acteurs) pour atteindre un
but ou une fonction spécifique d'un travail. Un acteur d'un cas d'utilisation peut être
un humain ou un autre système externe à celui que l'on tente de définir." -
http://fr.wikipedia.org/wiki/Cas d%27utilisation
On y comprend que l'approche par cas d'utilisation est tout de même tout à fait
possible. Ceci étant dit, les mœurs changent toujours.
Les fournisseurs , voir vendeurs, ont tendance à éblouir les décideurs dans le but
évidemment de gagner les ventes. Les bons côtés sont typiquement exagérés et les
mauvais presqu'éliminés du discours de vente.
Les décideurs ne sont pas toujours, voir rarement, des informaticiens au fait des
derniers avancements du domaine, mais plutôt des gestionnaires de haut niveau.
Ajouter à cela que l'AOS et les technologies qui y sont connexes sont plutôt pointues.
La peur face à une certaine technologie qui peut s'avérer complexe et, parfois,
obscure pour la direction, peut faire en sorte qu'elle ne se commet pas ou seulement
en partie [PATR2005] . Le manque d'appui de la direction peut nuire à l'implantation
d'une architecture orientée-service.
Les difficultés au niveau des pourvoyeurs financiers (les payeurs) à s'ajuster au coût
initial de l'AOS est une difficulté souvent rencontrée. Les notions AOS sont plutôt
d'ordre techniques que fonctionnelles ce qui tend à rendre obscur les besoins réels de
telles dépenses aux yeux des responsables financiers.
45
3.4.3.5 La formation
3.4.4 La modélisation
Les difficultés reliées à la modélisation des services et échanges de données entre des
processus distants sont dues au fait d'un non consensus (pas de standards) de la part
de la communauté informatique. [BOOC 1999], [ROSS2006], [MARC2003]
C'est-à-dire que la modélisation des services étant purement au niveau back-end n'a
pas de méthode de facto déjà apprivoisée par les informaticiens d'aujourd'hui . Il
faudra encore un peu de temps pour que la communauté informatique fasse un choix
quand à la méthode de modélisation d'une AOS.
Les services Web ont pris beaucoup d'ampleur depuis 2003 -2004 environ et c'est en
cours d'amélioration. Des plates-formes technologiques propriétaires, telles que
Siebel, ont ajouté la notion de services web à leur environnement après avoir saisi
l'importance de l'interopérabilité entre les systèmes hétérogènes d'une entreprise.
Principalement, il s'agit d'une pression commerciale qui s'exerce sur tous les acteurs
46
de l'industrie dans le but de mousser l'aspect commercial bien sûr, mais aussi dans le
but d'améliorer la qualité des systèmes de façon globale. Le Web 2.0 est donc une
raison que tous se donnent pour suivre une même direction à travers tous les choix
qui pourraient s'offrir afin de standardiser une solution pour un certain type de
problème (ex: les services web pour l'AOS) [HINC2006] , [BOOT2004].
Ainsi, il ne faut pas être surpris si les méthodes Agile, RUP, P+, IBM Method, etc.,
de ce monde offrent maintenant des saveurs AOS de leurs méthodes. C'est bon signe!
47
Au niveau de la modélisation, les outils UML tendent, eux aussi, à s'arrimer avec
l'AOS_(ex: Rational Modeler) afin de permettre de formaliser et de préciser les
livrables d'analyse. [BOOC 1999]
Plusieurs nouvelles conférences importantes sur l'AOS ont fait surface ces dernières
années afin de mieux répondre aux besoins de formation des analystes et concepteurs.
D'ailleurs les grandes conférences de l'industrie (ex: Java One) se sont parfaitement
adaptées à ce nouveau marché et contribuent, jusqu'à une certaine mesure à
l'avancement de la formation dans le domaine de l'AOS.
Plusieurs nouvelles technologies AOS ont émergé depuis 5 ans et une certaine
épuration est en cours. [NORT2007], [WHAL2006], [PUTT2000] , [WHAL2003] ,
[GAVI2003], [WEBM2006]
C'est signe que les technologies se stabilisent et que les choix sont plus sûrs.
L'utilisation à outrance de termes de l'AOS dans le but de mousser les ventes de tel ou
tel produit est encore très répandue et nuit à la compréhension générale de l'AOS
[WEBM2006].
C'est d'ailleurs une forte tendance dans le domaine de l'informatique que d'utiliser à
outrance un terme en vogue, de façon à mousser la commercialisation de tel ou tel
autres produits et/ou solutions moins connus du grand public. Cette tendance est aussi
remarquable avec l'AOS (SOA en anglais) ce qui nuit aux décideurs pour cerner ce
qu'est en fait l'AOS au juste.
CHAPITRE IV
Tout d'abord, une problématique est établie appuyée par quelques exemples et
références . En deuxième lieu la justification du choix du document de base
(SWEBOK) est donnée, suivie par l'établissement des objectifs. Ces objectifs sont
donnés sous une f01me générique pour être référencés à chaque contribution au
SWEBOK. Ces contributions découlent de la juxtaposition de SWEBOK et de l'AOS ,
en se basant sur les références, le discours des chapitres précédents, ainsi que sur
l'expérience de l'auteur.
Les objectifs sont décrits sommairement et, lorsque repris en référence dans une
sous-section de contribution (section 5 de ce présent chapitre), la façon dont un
objectif en question est rencontrée est expliquée plus en détail dans son contexte.
2
L'AOS, dans le cadre du chaptire 5, peut aussi être vu comme étant un paradigme de développement,
!'orientée-service.
50
Un premier problème actuel relié à l'implantation d'une AOS est qu'un investissement
insuffisant au niveau analyse et conception ne permettra pas la conception de services
ayant un bon niveau d'atomicité fonctionnelle. Les possibilités de réutilisation s'en
trouveront directement réduites et donc les services ainsi construit seront moins
rentables, de façon générale. Voici une citation d'une référence [BECK2007]
illustrant ce problème : " ... you need to design business services at the right atomic
level. .. an upfront investment in design is crucial. .. ".
Un deuxième problème actuel relié à l'implantation d'une AOS est l'approche itérative
qui est nécessaire afin de produire des résultats satisfaisants. Si la méthode en cascade
est utilisée pour des projets très importants il pourrait en résulter une dichotomie
entre les besoins de l'entreprise au moment du déploiement et les besoins de
l'entreprise au moment de l'analyse. Voici une citation à ce sujet [GRUM2007]: "The
trick is to not deploy SOA al! at once, because by the time most "big-bang" efforts are
completed, the business needs may have changed and much of the implementation
will be outdated. .. ". Ce problème est lié aux phases d'analyse, de conception et de
construction du cycle de vie du logiciel.
51
Bien d'autres problèmes sont relevés par l'industrie des TI. Ils sont souvent abordés
positivement dans la littérature et on parle souvent en termes de défis plutôt qu'en
termes de problèmes, bien que certaines références utilisent le terme problèmes
comme tel. Finalement, le manque de formalisme nuit au domaine. [SCOT2004],
[JACKS2004], [SEEL2006], [ARSA2007], [L YNC2006] ·
Pour créer un ouvrage formel qui pourra être utile à l'ensemble de la communauté
informatique, il ne s'agit pas de créer un mémoire de maîtrise, vous en conviendrez.
Nous n'avons qu'à considérer l'ampleur du travail et les implications qui ont été
investis dans un ouvrage comme le SWEBOK par exemple. Or, pour répondre à cette
problématique, cet ouvrage propose le premier jalon soit la création des bases d'un
éventuel guide sur l'architecture orientée-service.
Le guide du SWEBOK' [ABRA2004] est utilisé, par cet ouvrage, comme un gabarit
afin de permettre certaines altérations, des précisions ou simplement des
commentaires contextuels aux sections initiales dans le but de le préciser selon la
saveur de l'AOS . En ce sens, le guide sur l'AOS hérite du guide sur le SWEBOK et y
prend d'ailleurs la plus grande partie de son formalisme. Le contenu non-hérité du
SWEBOK, donc ajouté dans ce présent document, est non validé par, et non associé
au SWEBOK comme tel.
Le SWEBOK [ABRA2004] est la référence principale parce que c'est le guide sur le
génie logiciel le plus connu, parce qu'il est facile d'utilisation, parce qu'il est formel et
parce qu'il est le fruit d'innombrables efforts d'édition et de révision de gens de
partout dans le monde, incluant. de grandes entreprises. Il est à noter que d'autres
références auraient pu servir comme gabarit principal de ce mémoire.
54
Les objectifs suivants sont ceux proposés par l'auteur. Il s' agit en fait d' une esquisse
de ce qui serait proposé, à titre d'objectifs d'un guide sur l' AOS, par une équipe de
chercheurs. Dans un tel cadre, les objectifs proposés découleraient d'une évaluation et
d' une analyse systématique des pratiques dans ce domaine, ce que l' auteur n'avait pas
la possibilité ni les moyens de faire. En lieu et place, la démarche choisie a été
d' identifier un ensemble important de contributions préliminaires réalisées par
l'auteur, puis de tenter de les regrouper par type d' objectifs auxquels ils se
rattacheraient le mieux. Toujours dans cette démarche, l' intention est de définir une
liste de types d'objectifs auxquels pourraient être rattachés tous les objectifs
spécifiques associés à chacune des contributions. C'est donc ainsi que la liste
suivante des objectifs a été produite :
55
[SUPPORTER]
• Supporter les analystes, architectes, testeurs, chefs de projet, et développeurs à
chaque étape du développement.
[SPECIFIER]
• Spécifier des informations propres au SWEBOK en relation avec l'AOS .
[MODELISER]
• Donner des indications plus précises quand à la réalisation des travaux de
modélisation d'une AOS.
[EXCEPTION]
• Améliorer la dimension de gestion des exceptions et des erreurs dans le cadre
de l'AOS.
[COMPRENDRE]
• Améliorer la compréhension des différences entre les étapes de génie logiciel
dans le cadre de l'AOS.
[CONCEVOIR]
• Supporter la conception de services d'entreprise.
[ENCADRER]
• Fournir un cadre pour mettre sur pied des architectures orientée-service basé
sur les règles de l'art.
[GÉRER]
• Améliorer l'aspect gestion dans un contexte d'architecture orientée-service.
[ANALYSER]
• Améliorer les méthodes d'analyse dans un contexte d'architecture orientée-
serv1ce.
56
Voici tout d'abord le découpage des thèmes pour le domaine des connaissances des
exigences du logiciel, tel que défini par le SWEBOK, auquel le lecteur peut faire
référence.
E:rigenns du logiciel
PriudPf'l
PJ·oosc u, d•s Élid t:i.tiou d u An..,lyae dM .Spé,d.fir:t tiou , d u V;ilidœtiou du Co~ id fr ~rions
foud amectaux de,
n::igeoru erigeuru n i:;;eu ru f'Xi&~ll('f' 1 u:i.::e.urt'1 Puriques
e-i:i:;eures du loPciel
~fmm:on d'tL'U! U-s ?11odèl e:; de Sow-N,', d~~ Clas~ifieaïion de-!l Le clec\D'nem de Re:1."\le_.o; des °KJ.ture lté'31k e
,z:<l:E'llce dë loi.cieJ l!Xi ge.w::e"> exi:eu.ce~ ditmitiou de 'i)~tène ex ige.."lœ ~ du proce:..n n dM
e.~i.geuœs
Prcx.~it~t
ex1~ncl!.:. de Le ~ ilctelu> de ModW3iou Sp@Cific~ûons de~ Um:u1;1:iIUellt
proc.e,;sm pi:oc.~<..lU Techuique::. cooceptm~ue .e,..-...,,~e.n.c~de du ch."1ng e:ineut
d'~!!cibri<m Conception .~ lê-.ID2
Le'.. exigence.:;
foncriOt"...nelles et Appui et archi1tc.tw-ale e(
Vafüfation du Attn'bunde.s
tmin.1 gemell! <lu 2ri:11burio:1 de:: Sp«.ific..1.tioœ:. des
uon- modè e e.'Clge:nœ,;
proc:es.sm exigences du loriciel
e.'C;:i!i:.t'A!!i"
foru:tic:me.lle.::.
Qua frêg _r~ocia:tion de-t
~ prop1l;?tés
a.n:••!lior.uion dêS e,d;eJce-;
êmergillte;
pH>,~e:s;,;.u:s;
E:rigeru:.ti
qluntillable!
Figure 19 - le découpage des thèmes pour le domaine des connaissances des exigences du logiciel
A - Définir un intégrateur
Premièrement, l'élicitation des exigences, tel que défini dans le guide SWEBOK, est
contraint, dans un contexte d'AOS, au fait que plus d'un participant (sous-système)
doit évaluer des exigences logicielles. Or il faut définir un intégrateur qui est
propriétaire du processus d'élicitation des exigences système et logicielle, tel que
défini dans le guide SWEBOK.
Pourquoi?
• Éviter le dédoublement des exigences connexes et/ou similaires permet
d'éliminer les anomalies dans les exigences.
• Intégrer les exigences connexes et/ou similaires dans les livrables d'exigences
logicielles de façon à ce que la conception AOS soit appropriée.
• Augmenter les chances que toutes les exigences importantes soient
effectivement élicitées.
• Améliorer la qualité des exigences de façon générale.
Complément d'information:
Les réunions facilitées se prêtent très bien à ces situations (voir guide SWEBOK), où
les spécialistes des domaines pour lesquels on doit intégrer les exigences, sont
présents.
Pourquoi?
" ... Quelques types de logiciel demandent que certains aspects soient analysés
particulièrement rigoureusement." - SWEBOK
Évidemment, dans le cadre des AOS , l'aspect des flux de données est très important
au niveau des échanges de messages entre les systèmes hétérogènes et/ou distants.
Ici, on n'entend pas l'analyse des flux de données entre le client (interface personne
machine) et le serveur d'application par exemple. Plutôt, on entend modéliser les
échanges entre les processus. C'est-à-dire tous les aspects à saveur AOS , où donc les
échanges de messages sont inévitables sous toutes sortes de forme (ex:
requête/réponse, send-and-forget, etc.).
" ... La conception architecturale est un point avec lequel le processus des exigences
chevauche celui de la conception ... " - SWEBOK
Cette réalité amenée par le SWEBOK identifie donc, dans un contexte d'AOS, le
besoin d'identifier les exigences logicielles qui correspondront à des composantes de
conception (ex: service) déjà à la phase d'analyse.
Pourquoi?
Afin de bien comprendre quoi concevoir au niveau de la conception AOS. Cette étape
aidera grandement l'ingénieur logiciel. Pour w1 ensemble d'exigences logicielles
données, seules certaines parties ont des liens avec la nature AOS du système visé. Or
l'identification du ou des sous-ensembles des exigences logicielles ayant un lien clair
avec l'AOS, aidera à spécifier la totalité du "quoi" impliquée dans la conception AOS.
Pourquoi?
Même s'il s'agit d'un effort de standardisation, le BPEL est plutôt à cheval entre la
phase de conception et de construction. Il s'agit d'une méthode trop près de la
réalisation pour être utile afin de spécifier le ou les modèle(s) de flux de données
appliqué(s) aux exigences logicielles à saveur d'AOS .
Il faut maintenir une corrélation entre le management du changement (tel que défini
dans le SWEBOK) et Je principe d'intégrateur des exigences logicielles (tel que défini
dans cette présente section).
Pourquoi?
Le but est de maintenir le principe de propriété des exigences logicielles qui sont
partagés entre deux ou plusieurs systèmes intégrés par une technique d'AOS , et ce à
travers le cycle de vie du système global. Finalement, il est donc suggéré que
l'intégrateur soit ou nomme un gestionnaire du changement.
Tel que défini dans le SWEBOK, il est en général utile d'avoir un certain concept de
"volume" des exigences. Or dans un contexte d'AOS, il peut être beaucoup plus facile
de multiplier une ou des exigences à saveur d'AOS à travers les différents sous-
systèmes impliqués.
Pourquoi?
Parce que telle ou telle exigence logicielle peut être reprise plus d'une fois dans de
multiples contextes dû à la nature distribuée et la notion de producteur/consommateur
d'une architecture orientée-service ce qui est, a priori correct. C'est pourquoi il ne faut
pas dédoubler le volume des exigences à saveurs AOS. Il est donc important d'être
plus vigilànt à ce niveau comparativement à un contexte non AOS.
[ANAL YSER] : Aider à être productiflors de l'élicitation des exigences dans le cadre
d'une AOS.
Voici tout d'abord le découpage des thèmes pour le domaine des connaissances de la
conception du logiciel, tel que défini par le SWEBOK, auquel le lecteur peut faire
référence.
ContQption du ltgkicl
> llD SC Ît
JJ1i1titÎjlt$: , lntiltgie:s tt
PJ"Qblii:,uulfiqut~ clês: SlrotOU't t1 , , . 1u, 1ic111W 'iooll ion d•
((u1dn1et-11Uu:. cit- l!i l\l~ hoct,cs d,-
ir.a COIIC<tJtfÎOad11 11 1'tMrtt.t111~1iu 11u~li1icft b c o,nap.l:Îa1 d 11
CCllter:f•IÎOO 1h1 con«.ptjD"• J1~
1ciaiôcl l:tigilic!I .::011a11tian -d u Coiciriel
loiiôcl lo&il'icl
C'est à la phase de conception que l'AOS prend le plus de place dans le cycle de vie
du logiciel. C'est bien pendant cette phase que l'informaticien (disons l'architecte, ou
encore l'ingénieur logiciel) décide de prendre une tendance, ou une saveur
d'architecture orientée service. Dans les termes du SWEBOK, ont parle de deux
activités de conception importantes soit la conception architecturale du logiciel et,
dans un deuxième temps, la conception détaillée du logiciel.
65
C- Le couplage et la cohésion
" ... couplage est défini comme la force des relations entre les modules ... cohésion
est définie par la façon dont les éléments .. . sont reliés." - SWEBOK
Le couplage entre des modules (i.e.: sous-système) devant inévitablement échanger
des données, selon les exigences logicielles, devra être traduit par un/des service(s)
où la force du lien qui unit consommateur et producteur est au plus bas possible, sans
affecter w1e bonne cohésion du service lui-même. C'est-à-dire que le service,
émergeant du besoin d'échange entre deux modules (i.e.: sous-systèmes), doit trouver
un équilibre entre la tendance à diminuer le couplage et la tendance à augmenter la
cohésion au même titre qu'une procédure dans un paradigme procédural doit le faire.
Pourquoi?
Parce que les services candidats doivent simplement être amenés par les besoins du
logiciel visé, c'est-à-dire par les exigences logicielles.
D- Abstraction et encapsulation
Tel que défini dans le SWEBOK, la paramétrisation et la spécification sont les outils
d'abstraction dans le domaine du génie logiciel. Il faut donc contrôler ces deux
aspects afin de maximiser le niveau d'abstraction des services. L'encapsulation des
services sert à grouper et assembler les détails internes au service de l'abstraction.
Pourquoi?
Au niveau de l'architecture orientée-service, il est primordial que les services soient le
plus abstraits possible, grâce à une bonne encapsulation logicielle, afin de tendre vers
la réutilisation, voir vers la centralisation des services à développer et à maintenir.
Pourquoi?
[ENCADRER] : Faire en sorte que le concepteur tienne compte d'une notion AOS
fondamentale .
Pourquoi?
• Tel qu'on le dit si bien en langue anglaise "Keep it simple" est un dicton ayant
porté fruit à maintes reprises dans le domaine du génie logiciel. De plus, la
complétude et la suffisance dénote une forte cohérence.
• Dans le domaine de l'architecture orientée-service, ces notions prennent toutes
leur importance au niveau de la conception des services dans l'optique de leur
utilisation éventuelle à titre de service centraux, avec toutes les spécificités
que cela comprend, c'est-à-dire les notions de réutilisation, de concurrence, de
performance et de robustesse, pour ne nommer que celles-ci. Donc la
suffisance, la complétude et la primarité permet aux services d'une
architecture de mieux répondre aux besoins de leurs consommateurs, du point
de vue de leurs exigences fonctionnelles et non-fonctionnelles communes.
69
[ENCADRER] : Faire en sorte que le concepteur tienne compte d'une notion AOS
fondamentale.
Pourquoi?
Pourquoi?
• Dans d'autres cas, cette réalité sera moins frappante grâce à la nature plus
souple de l'intergiciel utilisé. Par exemple, la simple utilisation d'un outil de
files d'attentes (Message Queuing) n'a pas beaucoup d'effet sur la distribution
des composants (services) puisque ceux-ci peuvent accéder à distance à
l'intergiciel et que celui-ci ne contient pas les services qui l'utilisent.
Le style architectural réparti est celui qui devrait être préconisé dans le cadre d'une
solution orientée-service.
Pourquoi?
• La notion client-serveur est reprise de façon intégrale entre le consommateur
et le producteur dans le cadre orienté-service.
• L'approche trois-tiers est aussi parfaitement valide (voir n-tiers plutôt).
• De plus, l'approche courtier est valable lorsqu'un intergiciel entre en scène
d'une architecture orientée-service.
Pourquoi?
• Permet une plus facile réutilisation et une meilleure séparation des
responsabilités entre le producteur et le consommateur de service.
• D'autres avantages en découle (ex: diminution des coûts de développement) .
Pourquoi?
Parce que les activités d'un tel diagramme expriment assez facilement le découpage
interne d'un service de façon à mieux cerner ce qu'il doit et ne doit pas faire .
M- Diagramme de flux de données pour la description des échanges de
données entre les sous-systèmes par l'entremise des services candidats
Pourquoi?
• Ce type de diagramme permet d'illustrer comment le ou les modèles de
données d'une architecture orientée-service sont utilisés par les divers
consommateurs et producteurs de services.
Pourquoi?
Parce qu'il permet de découper en petite unité conceptuelle chacune des étapes
internes propres à l'exécution du service d'entreprise.
Pourquoi?
Peu importe par quel formalisme ce sera fait, le langage de description d'interface est
fondamental dans le cadre de la conception d'un ou de service(s). Dans le même ordre
d'idée, le langage de description des données l'est tout autant.
Pourquoi?
Parce qu'il permet de formaliser l'interface d'un service afin de guider la conception
d'un consommateur de service, que ce soit un service aussi ou simplement un
composant client. Dans le cas du langage de description des données, il sert à définir
les structures de données d'une façon standardisé et portable entre les différents
environnements technologiques hétérogènes. Par exemple le XML (XSD) peut être
une solution parfaitement applicable.
Voici tout d'abord le découpage des thèmes pour le domaine des connaissances de la
conception du logiciel, tel que défini par le SWEBOK, auquel le lecteur peut faire
référence.
Principes
fondamentaux rie Gérer la Cousldérntious
Comtrnctlon clu construction [ pratiques
Jouiriel
Langages de construction
Prévoir le chan gement Planification de la
.............
construction Codage
Constrnire pom la
.... vérification La mesme de la Essai de cousui1ctioo
... consn11cti on
Réutilisation
01mes dans la
.... construction Qualité de la constrnctiou
Intégra tion
Pourquoi?
Pourquoi?
Parce que ce sont des ensembles intégrés de pièces réutilisables propres au domaine
de l'architecture orientée-service, et fournissent donc une couche logicielle
fondamentale à son bon fonctionnement.
La notation visuelle est fort utile pour représenter la chorégraphie d'un ensemble
de services afin d'associer différents services pour en créer un nouveau.
Pourquoi?
La notation visuelle est fo1iement utile pour configurer les différents composants d'un
service souvent exprimés sous forme XML.
Pourquoi?
Il s'agit d'une méthode qui permet aux développeurs de se retrouver facilement dans
une multitude de métadonnées de configuration souvent persistée sous la forme de
fichiers XML.
81
E- Gestion de compensation
Afin de supporter la gestion des exceptions et des erreurs, il faudra prévoir du code de
gestion de compensation.
Pourquoi?
• Dans le cas où un service rencontre une exception, une erreur, il doit être
capable de la gérer. Pour ce faire, il faut prévoir du code spécifique à ces
éventualités.
• Dans un cadre transactionnel, il peut être primordial de créer du code de
compensation qui permet d'effectuer un rollback complet des activités de la
transaction en erreur.
Les essais d'intégration sont importants et consistent à créer des cas de tests qui
émulent un système consommateur éventuel.
00
N
83
Pourquoi?
Les essais d'intégration sont importants parce que les tests unitaires ne sont pas
suffisants. Ils ne s'attardent pas à représenter le système client éventuel. Par exemple,
la concurrence et la charge sont des dimensions qui échappent normalement aux tests
unitaires.
Pourquoi?
• Parce qu'un service en soi ne peut être utile que dans le cadre d'un appel d'un
consommateur.
• Or le service doit être réutilisable par différents consommateurs.
• De plus, l'architecture orientée service doit servir l'intégration entre les
consommateurs et les producteurs.
Voici tout d'abord le découpage des thèmes pour le domaine des connaissances des
essais du logiciel, tel que défini par le SWEBOK, auquel le lecteur peut faire
référence.
Kssai du logiciel
y
l"l'lllC ll)CS
fonùamcntaax Méthod,s Mesures reliée$.
Niveaux d'essais l'r-0 c e«u• cl'essui
des essa i$ du cl"css•i ll l1 X t"S!-Uis
Jvvidd
t t
f-+ Terminologie du L.1 cible ,ie I' essal F-valuaiion du Considérations.
doma i.ne des Essais fondé sur proe,rmnme à l' essai pratiques
essai>
l'jniuition et l'expérience
de l'jngénieur logiciel
., Objecti fs de Les nctivitésdes.
-+ f>roblémmiques (.:évaluation d~s.
cl és f9ç55n.j Méthodes fOl'ldées essais
essais e, écutés
,ur 1,.s spérifir,atiC1ns
Relations entre
_,. Hes essais et les
Méùiodes ba,ées
autres activ ités du
sur le code
lngir.iel
Méthodes fondée~
sur les déf:rncs
Méthodes rondées
sur l'utll ismion
Méthcdes fondées
sur la narurt de
l'appliéntion
Choisir et combiner
les méthodes
Figure 22 - le déco upage des th èmes pour le domaine des conn aissa nces des essa is du logiciel
Le niveau d'essai d'intégration est nécessaire dans le cadre d'une architecture orientée-
service. Comme un jeux d'ensembles, lorsqu'arrive le temps de tester le super-
ensemble, il s'agira de tests d'intégration.
Pourquoi?
[GERER] : Aider au gestionnaire d'une solution d'AOS à gérer les essais intégrés.
Les objectifs de l'essai, dans le cadre d'une architecture orientée-service, sont fixés en
fonction de la cible. L'architecture orientée-service implique qu'il y a un ensemble dit
services et un ensemble dit systèmes consommateurs. Nous pourrions faci lement,
pour le bien de la discussion, établir qu'un autre ensemble pourrait être formé d'une
ou plusieurs instances d'ensemble dit systèmes consommateurs et d'un certain
ensemble dit services. Or la cible d'essai doit varier en fonction de cet ensemble, en
premier lieu. C'est-à-dire que l'ensemble choisi déterminera les obj ectifs, et donc les
types d'essais à effectuer.
87
Systèmes
consommateurs
Figure 2~ - Ensembles (cibles) en exemple pouvant être identifiés .dans le cadre d'une AOS
88
Pourquoi?
Parce que certains niveaux d'essais s'appliquent mieux à certains ensembles (cibles)
qu'à d'autres, dans le cadre de l'architecture orientée-service.
Par exemple, supposons que la cible d'essai vise l'ensemble dit services. ll est évident
que des essais d'intégration ne sont pas appropriés puisque ce type d'essai serait
beaucoup plus approprié pour une cible visant la conjonction entre un ensemble
donné services et un ensemble donné systèmes consommateurs, afin, par déduction,
de tester l'intégration entre ces ensembles (cibles). Plutôt, dans ce même exemple, un
niveau d'essai de performance, de stress, ou encore de fiabilité serait beaucoup plus
approprié.
Bien que le SWEBOK n'aborde pas les essais de concurrence, il est essentiel, dans le
cadre d'une architecture orientée-service de procéder à des tests de concurrence.
Malheureusement, souvent on confond les essais de performance, ou encore de
fiabilité, avec les essais de concurrence.
89
Système
consommateur A
8 Système
consommateur B
Pourquoi?
Les essais de concurrence sont aussi importants que les essais de performance et de
fiabilité, en ce sens que la problématique de concurrence d'accès est inhérente à tout
système transactionnel. Or une composante dite service aura, du moins à terme, à
faire face à plus d'un système consommateur. De plus, dans le cadre d'un seul système
consommateur, la concurrence peut être requise. Or il devient évident que des tests de
concurrence d'accès doivent avoir lieu avant d'établir une cible d'essai plus grande
que l'ensemble dit services.
À la base, lorsqu'un service est modifié d'une quelconque façon, il faut procéder à des
tests unitaires. Par contre, il faudra aussi procéder à un/des cas d'essais unitaires
équivalent(s) (ayant trait aux mêmes fonctionnalités) au niveau du/des consommateur
dans le cadre des cas d'essais d'intégration. Or il peut être intéressant de partager le ou
les essais unitaires du service aux équipes d'essais d'intégration afin qu'il oriente leur
cible vers la/les fonctionnalités visées.
Voici tout d'abord le découpage des thèmes pour le damai.ne des connaissances de la
maintenance du logiciel, tel que défini par le SWEBOK, auquel le lecteur peut faire
référence.
:Maintenance du
logiciE'l
Problémariques
prîncîpa.les en Le proce5SU5 de T t>ehnique pour l:t
Fondnmeutau:1:
maintenance du mniutenance. mai11te11m1ce
logiciel
L a uam,<? de la Problèmes d e
A ctivitê& de m ainienauœ Ré-ingénierie
maintenance management
Évolution du logiciel
Les c.atégories de
rna.ïurenru1ce
En fait, il s'agit de s'assurer d'une forte cohésion entre les différents responsables de la
gestion de la maintenance dans le but de maintenir l'intégrité d'un système basé sur
l'AOS.
Maintenance
système
consommateur A
Maintenance
services
Maintenance
système
consommateur B
94
Voici tout d'abord le découpage des thèmes pour le domaine des connaissances de la
gestion du génie logiciel, tel que défini par le SWEBOK, auquel le lecteur peut faire
référence.
Managementtlu génie
logiciel
Management Reporrnge
de la qualité
Le plan de
management
[GERER] : Aider à saisir l'importance du plan de gestion intégré dans le cadre d'une
AOS .
Voici tout d'abord le découpage des thèmes pour le domaine des c01maissances de la
gestion de la configuration du logiciel, tel que défini par le SWEBOK, auquel le
lecteur peut faire référence.
100
l
GCL L o-~cietlt- Logidtllt
du lo~ci•I Lo~ciellt livrah on
;~~
C outr.U!I.It!s ~t C'anft~rrlion d11 L.cg-Jd~lle log.idelle ).•fa1:..1iemeu.c de
obU,g.aa.oll.1 C'O!J.C ero.3.ll !otkiel VE:1'.SiOI!
Je. prcx:e;.ru;: de GCL Rappon d-e Stamt L'audit physiq_u.e l.oginell•
JiO.ltl d~
dl? !ll de !,
c.onfJgurar.l;n d"
Pb:iific.a.îc.-..nd~ Jci1â"J
• · Co ~ ~~rioc. coa.fi~no-o
lApmll• Logjc~!le
laGCL logici elle
R9Jamns1111rrv l"f'IXQSS:JlS df
Orgamr.2r1on f'! m!.mztf" rx',nam{~dv
r,spOJ1i<1b1b1ru o·v Auch6, .e.o Cours
c,c'l1}1gwa11-071f.q cJJ:mgMJvn: ét
/aGCL de proJ• d'llll
lof.cid ::;!,JC.'"l
*" Po-,Ult de
1iv:Jt:1urct1: d11 GCl e1 Lr.WltrJ(llldU !mpbncer U!l
R.éfire.nce du
11ck~cim togidoJ Cbaugetl..~~ 1m
l og,del
Logi.ciel
Point dt- rt/1r,me:e
C~ix{fo~iJ g.r {lxn•JÎm,)
msïallmion D~visriou;: et
.kqtrl!Tf dt S iJi Wll' Au con snréo'C
a\'! c.J:mfl€flTM~ff du
Contn,lo de
f {;t:nilimu/Sou.r- lat;1ci<I
c.a71J1::rcrœu
!'l:llld.eGC L
~:~j
Ul!-Ul'\'E.Î3 ance
de ta gesuon di!
..:!~::;.~
cir p.1ocg.rs~ de ta
,'SU'te
.4t.•din. _c,.v1da,u
}"tl'.~lW01l. ~ GCL
A- Contrôle de fournisseurs/sous-contractant
La gestion de version du logiciel est fondamentale en génie logiciel mais peut s'avérer
lourde dans une architecture orientée-service puisque le nombre de composantes
versionnées peut être assez grand. De plus, certaines versions d'un certain service
peuvent être d'une grande importance puisque l'interface ou le comportement change
en vertu d'un nouveau contrat. Dans ces cas, il faudra établir w1 lien de
communication entre les groupes de développement impliqués dans une architecture
orientée-service. Pour les autres versions de service (celles qui n'ont pas d'impact réel
sur les systèmes consommateurs), elles n'ont pas à être communiquées à prime abord.
Certaines technologies fondamentales à l'AOS ne sont pas orientées vers la notion de
gestion de configuration, comme par exemple les services web. Or il faut mettre sur
pied un mécanisme au niveau de l'équipe de gestion de configuration pour supporter
cette notion de versionnement de service.
5
oSUPPORTER
4 • SPECIFIER
oMODELISER
3
oEXCEPTION
2 - • COMPRENDRE
oCONCEVOIR
Figure 29 - Corrélation entre les étapes du cycle de vie du logiciel et les contributions du
mémoire
Ainsi, les contributions présentées dans ce mémoire sont très fortement axées sur les
étapes liées au pré-développement. C'est-à-dire qu'une importante part des
contributions concerne les travaux d'analyse et de conception. En effet, ces deux
premières étapes comptent 28 contributions sur un total de 48, donc 58%. Si on ajoute
l'étape de construction, on atteint 73%.
Posons comme hypothèse que chacune des étapes di1 génie logiciel sont égales entre
elles. Dans le diagramme suivant, la différence entre le nombre de contributions par
étapes du génie logiciel et le nombre hypothétiquement moyen est illustrée.
106
40 , ~~,......._....,.~~..,.......-,.,......,.~...,...__...........~ - - -~
35 +-- --/
30 +--- ---J'------\- - - - - - - - - -- - - - 1
25 +--- ,'--- ---\~ - - - - - - - ~ - - - - - ! ~ - - - - - - - - ~
-+- Pourcentage Réel
20 -,~ --X-- - ---'<---------'-------1 - - Pourcentage hypothétique
15 +---======--=====~ =====111i======aa-=====-====~ ---l
10 - 1 - - - - - - - -~'-<--- - - -- ---él
5-1-- - - - - - - - -~ - -=-=:___---I
0+-- - - - -- -- - - - - - - -- --1
Figure 30 - Différences avec l'hypothèse d'égalité en importance de toutes les étapes du cycle de
vie
En considérant donc hypothétiquement que chacune des étapes abordées sont égales
entre elles, ont atteindrait 14% chacune. C'est donc dire que seules les étapes
« exigences », « conception », et même « construction », semblent avoir été abordées
avec plus d'attention (que la moyenne hypothétique) par l'auteur. Cette observation
appuie celle effectuée précédemment. Les étapes liées au pré-développement ont fait
l'objet de plus de contributions que les autres étapes.
Total
16 ,--~~~-~~~~~~~~~~~~~~~ ........
14 ·
12 + - - - - l
10 - + - - -I
8 -+----,
6 ·1- - -1
4 .
2 .
0 +-'--L--,-..L-........,._._....._,--L_.._-,-~.__,_.....__.__.-'----'-""T"""""'.........~ - ' - - ~
En considérant chaque objectif, on se rend compte que c' est l'objectif « spécifier »
qui reçoit le plus d' attention, suivi des objectifs « encadrer » et « gérer ».
Ces observations semblent consistantes avec les pratiques quel ' on situe au niveau II
du CMMI (voir le livre CMM!for Outsourcing: Guidelinesfor Software, Systems,
and IT Acquisition) [HOFM2008]. L'auteur croit, quant à lui, que les
étapes « exigences », « conception » et « construction » sont les étapes les plus
fondamentales du cycle de vie du logiciel puisqu'elles déterminent le quoi (analyse),
le comment (conception), ainsi que la réalisation (construction) proprement dite. On
peut donc déduire que les résultats observés sont en corrélation avec cette dernière
croyance de l'auteur.
CONCLUSION
Après avoir élaboré sur l'état de l'art et les aspects théoriques, les contributions de ce
mémoire ont été avancées par l'auteur à titre de suggestions à un éventuel guide sur
l'architecture orientée-service. Malgré tout, elles proviennent du meilleur des
connaissances de l'auteur et ont pour but de servir le développement éventuel de ce
futur guide, donc de servir, d'une façon plus large, le développement des
connaissances de ce champs de recherche qu'est l'architecture orientée-service.
Les contributions de l'auteur, proposées dans ce mémoire, sont limitées par les
connaissances, les références et la seule expérience de l'auteur. En revanche, ces
contributions proposent clairement des avenues pour poursuivre ce travail de
recherche.
niveaux moins technique. La question est ouverte à savoir si des contributions à des
niveaux différents que le niveau technique sont aussi des pistes de contributions
concrètes à l'architecture orientée-service.
Il est intéressant de constater que les évaluations ont donné suite à des commentaires
forts différents dépendamment du bagage propre aux évaluateurs en question. Nous
les remercions d'ailleurs beaucoup pour le temps qu'ils ont mis, gratuitement, à
réviser parfois très en détail le contenu de ce mémoire.
Finalement, du point de vue de l'auteur, il serait très souhaitable qu'un jour, un groupe
d'individus mandatés approche la question encore plus formellement pour donner lieu
à un véritable guide sur l'architecture orientée-service neutre technologiquement.
[ABRA2004]
• Alain Abran, James W. Moore, Pierre Bourque, Robert Dupuis, 2004,
«Guide to the Software Engineering Body of Knowledge», IEEE
Computer Society, p. 1-204
[AGRA2001]
• Rakesh Agrawal, Roberto J. Bayardo Jr. , Daniel Gruhl, Spiros
Papadimitriou, 2001 , « Vinci: A Service-Oriented Architecture for Rapid
Development of Web Applications », ACM, ACM l-58113-348-
0/01/0005, p. 357-365
[ALEX1996]
• Christopher Alexander, 1996, « The Origins of Pattern Theory », ACM,
1996 ACM Conference on Object-Oriented Programs, Systems,
Languages and Applications (OOPSLA),
http: //www.patternlanguage.com/archive/ieee/ieeetext.htm
[AMIR2004]
• Rafik Amir, Dr. Amir Zeid, 2004, « A UML Profil For Service Oriented
Architectures », ACM 1-58113-833-4/04/0010, p. 192, 193
112
[ANDE2007]
• Tyler Anderson, 2007, « Understanding Web Services specifications, Part
5: WS-Policy », International Business Machines, htip: //www-
128.ibm.com/developerworks/webservices/edu/ws-d w-ws-Lmderstand-
web-services5.html?S TACT=105AGX04&S CMP=HP
[ARSA2002]
• Ali Arsanjani, David Ng, 2002, « Business Compilers: Towards
Supporting a Highly Re-configurable Architectural Style for Service-
oriented Architecture », ACM, ACM 1-58113-626-9/02/0011 , p. 26-27
[ARSA2007]
• Ali Arsanjani, Liang-Jie Zhang, Michael Ellis, Abdul Allam, Kishore
Channabasavaiah, 2007, «Design an SOA solution using a reference
architecture», IBM, http: //www-
128.ibm.com/developerworks/architecture/library/ar-archtemp/
"the current Web services specifications generally Jack the facility to
define comprehensive relationships among business entities"
[BARE2003]
• Luciano Baresi, Reiko Heckel, Sebastian Thone, Daniel Varro, 2003,
« Modeling and Validation of Service-Oriented Architecture: Application
vs. Style », ACM, ACM 1-58113-743-5/03/0009, p. 68-77
[BEAM2000]
• 2000, « BEA MessageQ, Programming Guide », BEA, p. 1-474,
http: //edocs.bea.com/tuxedo/msgg/pdf/mgprog.pdf
113
[BECK2007]
• Helen Beckett, 2007, «Case studies in implementing service oriented
architecture», Computer Weekly,
http: //www.computerweekly.com/ Articles/2007 /04/17 /222985/case-
studies-in-implementing-service-oriented-architecture-soa.htm
[BETIN2005]
• Aysu Betin-Can, Tevfik Bultan, Xiang Fu, 2005, « Design for Verification
for Asynchronously Comrnunicating Web Services », International World
Wide Web Conference Cornrnittee (IW3C2), ACM 1-59593-046-
9/05/0005 , p. 750-759
[B00C1999]
• Booch, G. , I. Jacobson and J. Rurnbaugh, 1999, «The U nified Modeling
Language User Guide», Addison-Wesley, pp. 219-241
[B00T2004]
• David Booth, Hugo Haas, Francis McCabe, Eric Newcomer, Michael
Champion, Chris Ferris, David Orchard, 2004, « Web Services
Architecture », W3C,
http :// dev. w3. org/cvswe b/~checkout~/2002/ws/ arch/wsa/wd-wsa-arch-
review2 .html
[CASA2003]
• Fabio Casati, Eric Shan, Umeshwar Dayal, Ming-Chien Shan, 2003 ,
« Business-Oriented Management of Web Services », Communications of
the ACM, no 10, Vol. 46, Octobre, p. 55-60
114
[CHAV2004]
• Kamalsinh F Chavda,. 2004, « Anatomy of a Web Service », Kennesaw
State University, JCSC 19, 3
[COTR2004]
• Domenico Cotroneo, Almerindo Graziano, Stefano Russo, 2004,
« Security Requirements in Service Oriented Architectures for Ubiquitous
Computing », ACM, ACM 1-58113-951 -9, p. 172-177
[COXP2000]
• Ryan Cox, Joaquin Picon, Già.nni Scenini? Andrea Conzett, 2000,
« Component Broker 3 .0: First Steps », International Business Machines,
p.1 -441 , ISBN 0738419184
[HOFM2008]
• Hubert F. Hofmann, Deborah K. Yedlin, John W. Mishler, Susan
Kushner, 2008 « CMMI for Outsourcing: Guidelines for Software,
Systems, and IT Acquisition », Carnegie Mellon University, p.1-464,
ISBN-10: 0-321-47717-0, ISBN-13: 978-0-321 -47717-0
[CURBE2003]
• Francisco Curbera, Rania Khalaf, Nirmal Mukhi, Stefan Tai, Sanjiva
Weerawarana, 2003 , « The next step in web services », ACM, Vol. 46, no.
10, p. 29-34
115
[DENG2005]
• Roger Deng, 2005 , «Service-Oriented ETL Architecture»,
www.datawarehouse.com,
http://www.datawarehouse.com/article/?articleid= 5560
[GAVI2003]
• Lee Gavin, Gerd Diederichs, Piotr Golec, Hendrik Greyvenstein, Ken
Palmer, Skreekumar Rajagopalan, Arvind Viswanathan, 2003, « An EAI
Solution using WebSphere Business Integration (V4.1) », International
Business Machines, p. 1-563, ISBN 0738426547
[GERA1999]
• Ronan Geraghty, Sam Joyce, Tom Moriarty, Gary Noone, 1999, «COM-
CORBA Interoperability», Prentice Hall, p. 1-304
[GRUM2007]
• Galen Gruman, 2007, «The real challenge of SOA», Techworld,
http://www.techworld.com/itevolution/features/index.cfm?FeatureID=257
4
[GUDG2006]
• Martin Gudgin, Marc Hadley, Tony Rogers, Ümit Yalçinalp, 2006, « Web
Services Addressing 1.0 - WSDL Binding », W3C,
http://www.w3.org/TR/2006/WD-ws-addr-wsdl-20060216/
116
[HINC2006]
• Dion Hinchcliffe, 2006, «Web 2.0 and SOA: Contrived or Converging?»,
web2 .wsj2.com,
http: //web2.wsj2.com/web 20 and soa contrived or converging.htm
[HOGG2004]
• K. Hogg, P. Chilcott, M. Nolan, B. Srinivasan, 2004, « An Evaluation of
Web Services in the Design of a B2B Application », Australian Computer
Society, Inc. - Conferences in Research and Practice in Information
Technology, Vol. 26, 331 -340
[IMAM2005]
• Takeshi Imamura, Michiaki Tatsubori, Yuichi Nakamura, Christopher
Giblin, 2005, « Web Services Security Configuration in a Service-
Oriented Architecture », IBM/ ACM, ACM l-59593 -051 -5/05/0005 , p.
1120-1121
[JACKS2004]
• Joab Jackson, 2004, «An insider' s thoughts on SOA», GCN,
http ://www.gcn .com/print/24 28/36976-1.html
[JPOSl 985]
• J. Postel, J. Reynolds, 1985 , « FILE TRANSFER PROTOCOL (FTP) »,
Network Working Group, Request for Comments: 959, p. 1-69
117
[KEEN2006]
• Martin Keen, Chris Backhouse, Jim Hollingsworth, Stephen Hurst, Mark
Pocock, 2006, « Architecting Access to CICS within an SAO »,
International Business Machines, p. 1-428, ISBN 0738496952
[KOPE2007]
• Jacek Kopecky, Carine Boumez, Eric Prud'hommeaux, 2007, « Semantic
Annotations for Web Services Description Language Working Group »,
W3C, http: //www.w3 .org/2 002/ws/sawsdl/
[LITT2003]
• Mark Little, 2003 , « Transactions and Web Services », Communications
of the ACM, no 10, Vol. 46, p. 49-54
[L YNC2006]
• Regina Lynch, 2006, «Wanted: A Service-Oriented Architecture
Methodo 1ogy», TheServerS ide. corn,
http: //www.theserverside. com/news/thread .tss?thread id=40256
"Web services appears to be lacking a methodology that addresses the
unique attributes of an SOA project"
[MARC2003]
• Esperanza Marcos, Valeria de Castro, Belén Vela, 2003 , « Representing
Web Services with UML: A Case Study », IC-SOC, LNCS 2910, p. 17-23
[MERE2003]
• L.G. Meredith, Steve Bjorg, 2003 , « Contracts and Types »,
Communications of the ACM, no 10, Vol. 46, Octobre, p. 45-47
118
[MUKH2004]
• Nirmal K Mukhi, Ravi Konuru, Francisco Curbera, 2004, « Cooperative
Middleware Specialization for Service Oriented Architectures », ACM,
ACM l-58113-912-8/04/0005, p. 206-215
[MURP2004]
• Richard C. Murphy, 2004, « The Architecture of Services and the
Phenomenon of Life », Fawcette Technical Publications, 30 mars 2004,
http://ftpon1ine.com
[NADH2004]
• Easwaran G. Nadhan, 2004, «Service-Oriented Architecture:
Implementation Challenges», Microsoft, http://msdn2.microsoft.com/en-
us/library/aa480029.aspx
[NAKA2004]
• Masahide Nakamura, Hiroshi lgaki, Haruaki Tamada and Kenichi
Matsumoto, 2004, « Implementing Integrated Services ofNetworked
Home Appliances Using Service Oriented Architecture », ACM, ACM
1581138717/04/0011 , p. 269-278
[NA TI2003-A]
• Yefim V. Natis, Roy W. Schulte, 2003 , « Introduction to Service-Oriented
Architecture », Gartner, SPA-19-5971, p. 1-6
119
[NATI2003-B]
• Yefim Natis, 2003 , « Service Oriented Architecture Scenario », Gartner,
AV-19-6751, p. 1-4
[NORT2007]
• Philip Norton, 2007, « Invoke Web services with WebSphere MQ and
WebSphere Enterprise Service Bus », International Business Machines,
http://www- 128. ibm.com/developerworks/webservices/edu/ws-dw-ws-
mq-esb.html?S TACT= 105AGX04&S CMP=HP
[OBJE2006]
• Object Management Group, 2006, «CORBA Component Mode!
Specification», OMG, Version 4.0 , p. 1-335,
http: //www.omg.org/docs/fo rmal/06-04-01.pdf
[OPEN1997]
• Open Group, 1997, « Introduction to the RPC Specification », The Open
Group, http://www.opengroup.org/onlinepubs/9629399/chap l .htm
[OREI2005]
• Tim O'Reilly, 2005 , « What Is Web 2.0 », O'Reilly,
http ://www.oreillynet.com/pub/a/oreilly/tim/news/2005/09/30/what-is-
web-20.html
120
[PAPA2003]
• M. P. Papazoglou, D. Georgakopoulos, 2003 , « Service-oriented
computing: Introduction », Communications of the ACM, no 10, Vol. 46,
p. 24-38
[PATR2005]
• Paul Patrick, 2005, « Impact of SOA on Enterprise Information
Architectures», BEA/ACM, ACM 1-59593-060-4/05/06, p. 844-848
[POST2003]
• Jon Postel, Traduction par Valéry G. FREMAUX, 2003 , « RFC 793 :
Transmission Control Protocol (TCP) - Specification », Department of
Defense - US Gov. p.1-52, http://abcdrfc.free.fr/rfc-vf/rfc793.html
[PUTT2000]
• Geert Van de Putte, Colin Brett, Paul Sehorne, Sharon Stubblebine, 2000,
« Business Integration Solutions with MQSeries Integrator », International
Business Machines, p. 1-267, ISBN 0738417254
[ROSS2006]
• Steve Ross-Talbot, Tony Fletcher, 2006, « Web Services Choreography
Description Language: Primer », W3C, http://www.w3 .org/TR/2006/WD-
ws-cdl-1 O-primer-20060619/ .
121
[SEEL2006]
• Rich Seeley, 2006, «OASIS panel ponders: What is SOA»,
Search WebServices.com,
http://searchwebservices.techtarget.com/origina1Content/0,289l42,sid26
gci 1187553,00.html,"Lack of clarity in defining SOA makes it difficult for
software architects to sell it to the business side of their organizations"
[SIMM02006]
• Scott Simmons, 2006, «Scott Simmons: SOA governance and the ./
[SUNM1997]
• Sun Microsystems, 1997, «RMI Architecture and Functional
Specification», Sun Microsystems,
http ://iava.sun.com/i2se/1.4.2/docs/guide/rmi/spec/rrniTOC.html
[TAYLO]
• Keny Taylor, Tim Austin, Mark Cameron, « Charging for Information
Services in Service-Oriented Architectures », ACM
[WACK1999]
• Dieter Wackerow, David Armitage, Tony Skinner, 1999, « MQ Series 5.1
Administration and Prograrnming Examples », International Business
Machines, p.1-255, SG24-5849-00
122
[WEBM2006]
• webMethods.com, 2006, «webMethods SOA Roadmap», webMethods, p.
1-2,
http://www1.webmethods. com/PDF/datasheets/SOA Roadmap datasheet.
129.f
[WHAL2003]
• Ueli Wahli, Wouter Denayer, Lars Schunk, Deborah Shaddon, Martin
Weiss, 2003 , « EJB 2.0 Development with WebSphere Studio Application
Server », International Business Machines, p. 1-725, ISBN 0738426091
[WHAL2006]
• Ueli Wahli, Owen Burroughs, Owen Cline, Alec Go, Larry Tung, 2006,
« Web Services Handbook for WebSphere Application Server 6.1 »,
International Business Machines, p. 1-782, ISBN 0738494909
[WINET 1971]
• Joel M. Winett, 1971, «The Definition of a Socket», Lincoln Laboratory,
Request for Comment 147, NIC 6750, http ://tools.ietf.org/rfc/rfc147.txt
[YANG2003]
• Jian Yang, 2003, « Web Service Componentization », Communications of
the ACM, no 10, Vol. 46, Octobre, p. 35-40
123
[ZHAN2004]
• Jia Zhang, Jen-Yao Chung, Carl K. Chang, 2004, « Migration to Web
Services Oriented Architecture », ACM Symposium on Applied
Computing, ACM 1-58113 -812-1/03/04, p. 1624, 1628