8
pp. 8-58
Les outils du commerce electronique Chantal MORLEY*, Bruno DEFUDE*, Franck BUTELLE**, Daniel LANG*
R6sum6
Un systbme de commerce ~lectronique est une combinaison de pratiques, strategies, processus, applications et technologies, n~cessaires pour effectuer des transactions d'affaires. Cet article est centr~ sur les outils logiciels et les technologies. La premikre pattie pr~sente les diff6rentes familles de solutions applicatives : le marchE semble abandonner l'id~e du produit int~gr~ couvrant toutes les fonctionnalit~s du commerce ~lectronique, ce qui pose le problkme de l'intEgration. La seconde pattie est consacr~e ~ la mod~lisation des solutions et les technologies au coeur des applications de commerce ~lectronique. L'utilisation d'UML couvre diff~rents niveaux dans la construction d'un systbme de commerce ~lectronique. Les technologies Web sont en constante ~volution : XML apparaft notamment comme le langage d'avenir pour l'~change d'informations entre applications informatiques h~t~rogknes. La troisikme partie traite de l'int~gration des composants et applications. Malgr~ la convergence autour de normes sur les langages et les modbles, l'interop~rabilit6 des systbmes reste une question essentielle pour ~changer des informations et partager des processus. Deux courants ~mergent : les services Web et les approches EDL Mots cl~s : Commerce 61ectronique, Transaction 6conomique, Application ordinateurs, Gestion automatis6e, Gestion int6gr6e, Vente, Approvisionnement, Internet, Progiciel, Mod61isation, Langage UML, Mod61isation objet, Toile mondiale, HTML, XML, Architecture syst~me.
ENABLING TOOLS FOR E-COMMERCE Abstract
Electronic commerce (ec) is a combination of practices, strategies, processes, applications and technologies, enabling business transactions. This paper focuses on software and technologies for EC. In the first part, the different categories of applications for EC are reviewed. A fully integrated solution does not seem to be the major trend. However, the "best of breed" approach implies an integration problem. The second part of the paper includes modeling languages and EC applications core technologies. The UML appears to be used at different levels in the development of an EC solution. Web technologies are continually evolving: XML could be the language of the future for information exchanges between heterogeneous applications. The third part deals with component and application integration. In spite of converging standards for languages as well as for models, system interoperability is
* GET/INT - 9, rue Charles Fourier 91011 Evry Cedex, France. ** LIPN, UMR 7030, Universit6 Paris 13. ANy. TI~Lt~COMMUN.,58, n ° 1-2, 2003
1/51
9
C. MORLEY -- LES OUTILS DU COMMERCE I~LECTRONIQUE
a majorproblem, when inJormations are to be shared andprocesses to be jointed. Two major trends can be identified : Web services and EDt approaches. Key words: Electronic trade, Economic transaction, Computer application, Assisted management, Integrated management, Sales, Supply, lnternet, Software package, Modelling, Unified Modelling Language, Object Modelling technique, World Wide Web, Hyper Text Markup Language, Extensible Markup Language, System architecture.
Sommaire I. Introduction II. Les solutions applicatives pour les transactions d'affaires III. Modbles et technologies pour le ddveloppement d'applications e-commerce
IV. Des outils pour une architecture intdgrde V. Conclusion Bibliographie (51 rdf )
I. I N T R O D U C T I O N
Un syst6me de c o m m e r c e 61ectronique (e-commerce) est une combinaison de pratiques, strat6gies, processus, applications et technologies, n6cessaires pour effectuer des transactions d'affaires [Roberts, 1998]. Le mod61e du e-commerce modifie en profondeur les relations entre clients, fournisseurs, partenaires, ainsi que les processus h l'int6rieur de l'entreprise. Pour cela, il faut s'appuyer sur des technologies qui rendent possibles les changements, <
ANN. TI~LI~COMMUN.,58, n ° 1-2, 2003
10
c. MORLEY- LES OUTILSDU COMMERCEI~LECTRON1QUE
La troisihme pattie traite de la question majeure concernant les architectures logicielles dans le cadre du e-commerce : l'int6gration des composants et applications.
II. L E S S O L U T I O N S A P P L I C A T I V E S P O U R L E S T R A N S A C T I O N S
D'AFFAIRES
Le march6 des solutions applicatives pour faire du e-commerce est en constante 6volution. D'une part, aucun produit n'offre une couverture fonctionnelle complbte, d'autre part les 6diteurs 61argissent leur offre. Ainsi, les grands 4diteurs d'ERP ont aujourd'hui largement d6bord6 de leur couverture historique pour proposer des modules destin6s notamment au e-commerce. La complexit6 et l'6volutivit6 des offres du march6 emp~chent d'6tablir un cadre de r6fErence positionnant les outils avec des fronti6res pr6cises. On peut cependant tenter de les situer, de faqon simplifi6e, en fonction de leur finalit6 de gestion. Pour 6laborer la figure 1, nous nous sommes appuy6s sur [Fingar, 2000]. Les march6s 61ectroniques I sont ~ la base du commerce 61ectronique : on peut donc distinguer deux facettes compl6mentaires : le c6t6 vente et le c6t6 achat. De plus, les ERP (progiciel int6gr6) sont aujourd'hui consid6r6s comme la colonne vert6brale d'un syst6me de e-commerce [Yen, 2002b]. Nous y avons adjoint deux outils applicatifs, dont les fonctionnalit6s sont de plus en plus int6gr6es dans une offre com-
FIG. 1. - - Les solutions applicatives.
EC applications.
1. Nous retenons la d6finition d'[Amami, 2002] : ¢< Les march6s 61ectroniques peuvent &re d6finis comme un ensemble d'activit6s 6conomiques virtuelles formant une nouvelle 6conomie appel6e Economic num6ris6e (digital markets) o~ les agents (producteurs, interm6diaires et consommateurs) appuy6s par un syst~me d'information interorganisationnel (bas6 aujourd'hui sur Internet, le web et le browser comme interface universelle) et utilisant des processus virtuels (synchrones ou asynchrones) peuvent 6changer des biens et services en ligne. >>(p. 12). ANN. T[~LI~COMMUN.,58, n ° 1-2, 2003
3/51
C. MORLEY - LES OUTILS DU COMMERCE [~LECTRONIQUE
l1
merciale tourn6e vers le e-commerce : les outils d'entrep6t de donnEes (data warehouse) et d'exploration de donn6es (data mining). Le c6t6 vente contient deux grands types de solutions : Les outils de la cha~ne de vente, Selling Chain, sont principalement des applications de front-office2, destin6s ?ala vente en ligne. On les appelle parfois des applications de I-market. Les outils de gestion de la relation client (Customer Relationship Management) (CRM)couvrent un champ plus large que les outils de la selling chain : d'une part, ils englobent diff6rents canaux de vente et non exclusivement la vente en ligne; d'autre part, ils proposent des fonctions marketing, au-del~ des transactions commerciales, pour fid61iser les clients et en rechercher de nouveaux. Ils comprennent aussi bien des applications de front-office que de back-office. Du c6t6 achat, on trouve 6galement deux types d'outils : Les outils de la cha]ne logistique (Supply Chain Management) (SCM) visent a g6rer la cha~ne logistique qui cherche ~ livrer le bon produit au bon moment, en minimisant les stocks et sans perte d'occasion de vente. Ils s' inscrivent dans une relation entre fournisseurs, fabricants, distributeurs, et prennent en compte aussi bien des flux d'informations que des flux physiques. Ils comprennent des applications de front-office et des applications de back-office. Les outils d'e-procurement et les places de marchd concernent les relations d'achat/vente entre entreprises, c'est-~t-dire les 6changes de type B-to-B. On parle parfois de gestion 61ectronique des achats. Ces outils comprennent des applications de front-office et certaines applications de back-office. Mais pour faire du commerce 61ectronique, il faut 6galement s'appuyer sur des applications supports, en g6n6ral de back-office. Les outils de Data warehouse permettent de centraliser un volume important de donn6es provenant de diff6rentes sources, en vue d'une analyse ult6rieure ~t des fins de gestion. Les outils de Data mining impl6mentent des techniques d'analyses des donn6es pour d6couvrir des tendances ou des corr61ations dans un grand nombre de donn6es, utiles pour le marketing. Les outils de type progiciel de gestion int6gr6 (PG0 ou ERR (Enterprise Resource Planning), darts leur couverture historique, offrent des fonctions de gestion administrative. On verra que leur 6volution les fait d6border de ce p6rim~tre initial pour investir des fonctions destin6es au e-commerce, en particulier dans le cadre du SCM et du CRM. Ces diff6rents outils sont pr6sent6s successivement dans les sept sections qui composent la premi6re partie.
II.1. La chaine de vente Les applications de chaine de vente (selling chain) permettent d'automatiser tout le cycle, depuis une demande initiale jusqu'h la commande, afin d'en r6duire les coots et d'augmenter l'efficacit6. Elles concernent essentiellement le commerce B-to-C, et plus particuli6rement les entreprises de t y p e , click-and-buy >>,c'est-~-dire ofa tout le cycle s'effectue en ligne. 2. On appelle application de front-office une application g6rant l'interface entre l'organisation et un partenaire ext6rieur (client, prospect, administr6, fournisseur). 11 s'oppose h une application de back-office, logiciel destin6 h des tfiches sans contact direct avec le partenaire. Dans un sc6nario de vente, les Iogiciels de back-office assurent les t~ches administratives (raise h jour des stocks, livraison, comptabilisation...) ainsi que des t~ches manag&iales (analyse des ventes, d6termination d'un profil client...). 4/51
ANN. TI~LI~COMMUN.,58, n ° 1-2, 2003
12
c . MORLEY - LES OUTILS DU COMMERCE I~LECTRONIQUE
Demande
~-- Personnalisation
G~de d ' a e h a t
~-- Engagement
~
Commande
Configurate~ eomm
Catalogue
Ge~ionnaire : : de profil
:~ition . . . . .
Paiorne~
:
i
i .........................................................................................................
I
117.1.¸11 ~:~ ............................................................................................................................................
i i" E.P
I
I
On trouve diff6rents composants, h chacune des quatre Etapes de cycle de vente (Fig. 2). FIG. 2. - - Les composants de la cha~ne de vente.
Selling chain components.
Leur int6gration est un facteur c16 de r6ussite : d'abord pour 6viter des interruptions intempestives dans le processus d'achat; mais aussi pour ne pas supporter une charge de maintenance lourde et cofiteuse. De plus, les applications de la cha~ne de vente doivent g6nEralement 8tre interfacEes avec un ERP pour la comptabilisation de la vente, un syst~me bancaire s'il y a paiement en ligne, un syst~me de livraison (6ventuellement un syst~me de gestion de la cha~ne logistique, SCM) et un syst6me marketing pour analyse ult6rieure (6ventuellement un CRM). L'application Guide d'achat fait office de vendeur virtuel : elle aide le client h formuler sa demande, faire des comparaisons, explorer des alternatives... Elle s'appuie sur une application Catalogue, qui rEpertorie les offres et les promotions. L'application Configurateur compl6te le Guide d'achat dans les cas de produits complexes avec un nombre 61eve d'options (automobiles, configuration informatique...). I1 permet au client de faire des simulations avec diff6rents choix. Les Gestionnaires de profil permettent de conserver des profils de pr6fErences pour personnaliser l'interaction. Ils peuvent aussi agir de faqon dynamique, en utilisant des agents intelligents, c'est-a-dire des entitEs logicielles capables d'agir de faqon autonome, avec une representation partielle de leur environnement : l'agent de profil rep6re les prEfErences et/ou premiers choix effectuEs par un client connectE ; il recherche d'autres agents attach6s h des clients prEsentant certaines caract6ristiques similaires. Chaque agent peut alors proposer au client auquel il est attache des choix suppl6mentaires issus des prEfErences ou choix des clients prEsentant un profil semblable. L'application Fixation des prix permet de pratiquer des prix diff6renciEs selon la disponibilitE, les quantitEs en stocks, la demande et le profil du demandeur. Cette application requiert l'explicitation de r6gles de calcul parfois sophistiqu6es. L'application Proposition permet de produire et de g6rer des propositions completes, dans le cas d'achats complexes. Le client peut obtenir plusieurs propositions selon les options choisies. ANN.TI~LI~COMMUN.58, , n° 1-2, 2003
5/51
C. MORLEY -- LES OUTILS DU COMMERCE [~LECTRONIQUE
13
L'application de Gestion de commande cherche h 6viter au maximum les interventions manuelles : la commande sera donc saisie dans un format directement exploitable, et non par courrier 61ectronique non structur6. L'application assure la validation de la commande et sa prise en compte par le syst6me op6rationnel (cha~ne logistique) et int6gre le dispositif de paiement en cas de paiement en ligne. Cette application peut assurer l'6clatement de la commande en sous-commandes concernant des fournisseurs ou lieux de stockage diff6rents, et offre 6ventuellement un suivi en ligne de l'6tat de la commande. Elle s'appuie souvent sur la technologie du workflow, qui permet le pilotage automatique d' un processus,
II.2. La gestion de la relation client Le concept de gestion de la relation client CRM (Customer Relationship Management, ) est apparu au milieu des ann6es 90, comme un r6sultat de l'6volution des m6thodes marketing et de l'ouverture des possibilit6s technologiques. I1 s'inscrit initialement dans le cadre des 6changes de type B-to-C [Lef6bure, 2000]. Le CRM concerne en premier chef les entreprises qui ont un hombre 61ev6 de prospects/clients, dont l'acquisition et la fid61it6 ne sont pas garanties, mais sur lesquels elles sont susceptibles d'avoir des informations int6ressantes pour 6tablir une strat6gie marketing. Les op6rateurs de t616communication, les entreprises de vpc, les banques ou les assurances sont, par exemple, dans ce cas. I1 s'agit alors de recherchef les meitleurs clients, en capitalisant ensuite sur l'ensemble des contacts. D'un point de vue marketing, les entreprises sont pass6es, depuis une dizaine d'ann6es, d'une approche uniforme des clients, faiblement diff6renci6s dans leurs besoins comme dans la valeur qu'ils repr6sentent (marketing de masse),/i la recherche de contacts et d'offres personnalis6s, visant ~ acqu6rir et h conserver des clients ibrtement segment6s (marketing one to one). Du c6t6 technique, les canaux de communication diversifi6s (courrier, fax, internet, centres d'appels, serveur vocal interactif...) ont permis des interactions multiples, et I'informatique a offert des moyens accrus de consolidation des donn6es et d'int6gration des applications. La technologie a permis de faire tomber des fronti~res entre des fonctions souvent cloisonn6es : marketing, gestion de la force de vente, gestion du service client. Grace au partage d'informations, aux analyses informatis6es, au d6clenchement automatique d'actions et aux outils favorisant te travail coop6ratif, des activit6s jusque-1/~ s6par6es peuvent Otre int6gr6es dans des processus transversaux. Enfin, les outils permettent de r6duire les cofits des processus marketing/vente, rendant financi6rement supportable un marketing personnalis6. Les 616ments d'une solution logicielle de CRM sont repr6sent6s sch6matiquement ~ la figure 3. La partie back-office couvre l'ensemble des actions marketing. La partie CRM frontoffice comporte les outils d'aide h la vente et les outils de service apres-vente en ligne. De plus en plus, les solutions CRM ont tendance h int6grer des applications de vente en ligne. De routes faqons, les informations sur les contacts en ligne doivent venir alimenter la base de donn6es CRM. Les canaux de distribution repr6sentant tousles moyens de contact entre le client et Fentreprise. Si les contacts en face-h-face demeurent trbs importants, ils sont compl6t6s par
6/51
ANN. TI~LI~COMMUN., 58, n ° 1-2, 2003
14
c . MORLEY - LES OUTILS DU COMMERCE I~LECTRONIQUE
Canaux d'interaction
Centre d'appels
Internet
Commercial CRM front-office
Aide ~ la vente
~
~BBDextem~e
\
I Service apr6s-vente i
•
\
.
Analyse] (Data Mining)
Back-office entreprise
I
1
"BD CRM ( C l i e n t s ) ~
j,
CRM back-office l~puration/ ] enrichissement
ERP
SVI
]
[Gestion Production]
Actions Marketing ]
l
Gestion Approvisionnements
FIG. 3. - - A r c h i t e c t u r e g6n6rale des c o m p o s a n t s CRM.
CRM component framework.
des communications via internet (Web), le courrier 61ectronique, les centres d'appels, la t616assistance de SAV, les serveurs vocaux interactifs... La diversit6 des canaux de distribution ayant conduit h une multiplication des interactions, il est devenu crucial de garder une coh6rence d'ensemble, pour que le client n'apparaisse pas comme multiple et pour qu'il n'ait pas une vue 6clat6e de l'entreprise. Le terme <
> traduit cette exigence de coordination entre les canaux. Pour cela, la base de donn~es CRMest un 616ment central de consolidation des informations sur les clients ou prospects. Ce peut &re un entrep6t de donn6es, c'est-~-dire une base de donn6es charg6e ~ partir de diff6rents fichiers ou bases de donn6es sources. Dans tous les cas, elle s'accompagne de fonctions d'alimentation, mais surtout de sflection, comptage, extraction. Cette fonction peut &re assur6e par un langage de requ&e, par exemple le langage normalis6 SQL (Structured Query Language) pour les bases de donn6es relationnelles. Certains outils proposent une interface ergonomique qui masque une certaine complexit6 du SQLet permet une s61ection incr6mentale, notamment ~ l'aide de menus permettant de choisir les crit~res de s61ection et de listes de valeurs possibles pour pr6ciser la s61ection. Certaines fonctions peuvent 6purer ou enrichir la base de donn6es Client. Par exemple, l'61imination des doublons, la normalisation des adresses ou la reconstitution d'un foyer par regroupement sur le couple nom-adresse. L'enrichissement peut parfois s'appuyer sur des bases de ANN. TELI~COMMUN., 58, n ° 1-2, 2 0 0 3
7/51
C. MORLEY -- I.ES OUT[LS DI/ COMMERCE I~LECTRONIQUE
15
donn6es externes : c'est notamment le cas des fonctions de gdomarketing. Elles permettent de transformer une adresse en coordonn6es spatiales (g6ocodage), pour ensuite faire des analyses fines par zones ou selon la proximitd. Les donndes clients peuvent 6galement &re enrichies de caract6ristiques r6gionales de consommation, ~ partir de bases de donn6es externes. Les fonctions d'analyse rel~vent essentiellement du data mining. Les applications pour les actions marketing comprennent principalement la gestion des campagnes et la gestion des 6v6nements. Un outil de gestion des campagnes permet notamment de calculer un seuil de rentabilit6 partir d'hypoth6ses de taux de retour et de niveau d'achat. I1 s'appuie sur les outils de data mining, par exemple pour calculer une probabilit6 d'achat, par comparaison entre les profils des prospects et les profils des clients d6j~ acheteurs. L'ex&ution de campagnes personnalisdes peut &re automatis& par un moteur de distribution s61ective (push), c'est-h-dire un outil envoyant automatiquement des informations personnalisdes par courrier 61ectronique. L'automatisation permet de lancer simultan6ment des campagnes pour des produits diff6rents, avec un cofit faible. Les campagnes peuvent aussi passer par le canal du centre d'appel, en utilisant notamment le couplage tdldphonie et informatique pour ddclencher automatiquement des appels partir d'une liste de clients/prospects s61ectionnds et transfdrer l'appel h un op6rateur qui visualise la fiche correspondante. L'application de gestion des campagnes s'appuie sur le data warehouse Client, mais lui renvoie 6galement des informations pour garder une trace des contacts clients r~alis6s par la campagne. E[[e comprend une fonction de suivi des retours. Un outil de gestion des dvdnements permet de d6clencher automatiquement des actions partir de la r~alisation d'un fait. L'dv6nement peut &re lid au client (anniversaire, changement d'adresse...), h des variations dans l'utilisation des produits (nombre de cheques, nombre de connexions internet...) ou ~ une prddiction r6sultant d'une analyse statistique, issue du data mining (probabilit6 de changement de fournisseur...). La gestion des 6v6nements s'appuie souvent sur un outil de workflow. Celui-ci permet de moddliser, souvent sous la forme d'un arbre de d6cision, un encha~nement d'actions, int6grant une gestion de ddlai (par exemple le d61ai entre une offre initiale et une relance), ainsi que la sollicitation de certains acteurs (par exemple, pour d&lencher un appel tdldphonique de la part d'un op6rateur). Les outils d'aide b la vente comprennent trois types d'application. Les applications d'aide h la vente en agence ou sur le terrain : on y trouve des grilles tarifaires en ligne, des aides h l'61aboration de devis, des configurateurs de produits complexes, des fonctions de suivi du dossier au cours du cycle de vente... Les applications de vente par t~l~phone mettent en ~uvre le couplage t616phonie et informatique, et comprennent notamment une gestion des scripts de vente. Les applications de vente en ligne sont de plus en plus souvent int6gr6es dans un syst6me CRM. Leurs t'onctionnalit6s correspondent h cetles de la cha]ne de vente. Les outils d'apr~s-vente comprennent principalement deux types d'application. Les applications de centre d'assistence (help-desk), souvent utilis6es dans |e support informatique, permettent de mener automatiquement un dialogue avec un client en ligne, sous forme d'une suite de questions-r6ponses, pour r6soudre un probl6me. 8/51
ANN. TI~LI~COMMUN., 58, n ° 1-2, 2 0 0 3
16
C. MORLEY -- LES OUTILS DU COMMERCE ELECTRONIQUE
Les applications de service client gErent l'enregistrement et le suivi des demandes. Un moteur de workflow peut atre mis en oeuvre pour gErer automatiquement une succession d'Etapes dans le traitement de la demande selon sa difficult& La convergence tE1Ephonie et Web peut ~tre utilisEe par ces applications, permettant ~t un client connects au serveur Web de basculer, ~ son initiative, vers un tE1E-opErateur qui reqoit aussi bien la voix de l'appelant que le dossier de la session en cours. Les outils de push (envoi automatique de messages Electroniques) peuvent ~tre utilisEs par les applications d'aprbs-vente. Par exemple, un incident sur un materiel, rencontre par un client, peut donner lieu a l'envoi d'une information a tous les clients possEdant un materiel similaire, susceptible de rencontrer l'incident. Sur le marchE, les produits 6tiquetEs CRM sont fort nombreux (plusieurs centaines), avec des couvertures diverses. On prEvoit une croissance des ventes allant jusqu'~ plus de 10 milliards d'euros en 2004. Les outils commencent h inclure le canal de la tE1Ephonie mobile et &re appliques Egalement pour gErer les relations d'une entreprise avec ses dEtaillants, voire avec ses partenaires (PRM, Partner relationship management). Ces outils reprEsentent un 616ment-cl6 dans l'Evolution des strategies de vente [Ingram, 2002].
11.3. La gestion de la chaine Iogistique (SCM) L'intEgration des Stapes de la cha~ne d'approvisionnements, allant de la production ?~la distribution, est une preoccupation ancienne [Pimor, 2001], qui a pris un relief nouveau ces derni~res annEes sous l'influence de deux facteurs. D'une part, la communication 61ectronique via internet a accru les possibilitEs de coordination et d'intEgration d'activitEs entre partenaires. D'autre part, la concurrence et les impEratifs Economiques ont conduit ~ ,, tirer >, l'organisation des syst~mes de production en fonction des ventes, effectives et prEvisionnelles [Poirier, 2001]. Le but du SCM - gestion de la chalne logistique - est de coordonner et d'optimiser la relation offre-demande en gErant le flux mono-directionnel de matiEres et produits et le flux bidirectionnel des informations qui nourrissent les mEcanismes de contr61e et de feed-back [Tang, 2001]. Le SCM s'inscrit dans les relations interentreprises, B-to-B. (Fig. 4). En bout de cha~ne, on trouve souvent des entreprises de grande distribution, soucieuses/~ la fois de rEduire les stocks et de ne passe trouver en rupture face ~ une demande fluctuante (ECR, Efficient Consumer response). Mais parfois, la mise en place d'une chalne provient d'un fabricant, en position dominante. Dans la mesure off le SCM concerne, par definition, plusieurs partenaires, on ne peut que donner une presentation gEnErique des outils. En effet, certains adoptent plut6t un point de vue distributeur (donc acheteur), d'autres plut6t un point de vue fabricant, d'autres plut6t un point de vue transporteur. De faqon gEnErale, on peut dire que ces outils visent ?apermettre aux membres de la chai'ne - l e partage d'informations issues de leurs propres systEmes d'information, notamment leur ERP, leur application de gestion de production (MRP, material requirements planning) et leur application de CRM. Les informations concernant les ventes, les stocks, les
ANN. Tt~Lt~COMMUN., 58, n ° 1-2, 2 0 0 3
9/51
[7
C. MORLEY - LES OUTILS DU COMMERCE I~LECTRONIQUE
~ planification
Ventes Prdvisions Promotions
RP/CRMO
I
Fabricant lisation
~
RP/MRP~
1
planification
r
[ ~1 Distributeur r6alisatio~//"
Stocks Plannings production, Ventes ~livraison /Previsions ~ I ~ / Promotions [ Infbrmation ] [.. Hub J
FIG. 4. - - S c h e m a gdndrique d ' u n s y s t e m e de SCM
SCM generic model.
promotions, les plans de production, tes livraisons.., sont rassemblees dans un concentrateur d'informations (information hub). - l a synchronisation concertee de la planification des actions a chaque maillon de la cha~ne, c'est-~-dire 1' utilisation par chaque partenaire des informations du concentrateur. Le succbs de la cha~ne logistique depend de la confiance entre les partenaires ; mais aussi de la qualit6 de l'information qui va circuler (precision, actualites, modifications...). C'est pourquoi les approches basdes sur les outils (IT driven) sont aujourd'hui les plus frequentes et viennent enrichir les approches basees sur la mise en ~uvre de modeles visant ~ optimiser le systeme logistique [Min, 2002]. D'un point de vue technique, un problbme majeur est celui de la communication entre les systemes des partenaires, en particulier la comprdhension mutuelle du contenu des informations et de la structure des donnees. Le langage normalis6 XML a apport6 une aide significative ~ la resolution de ce probleme.
II.4. Les syst~mes de gestion ~lectronique des achats et les places de march~ La raise en place de cha]nes logistiques completes reste exceptionnel. En revanche, les entreprises recourent de plus en plus h des formes d'achats/ventes via internet, sous deux formes compl6mentaires : la gestion 6lectronique des achats (e-procurement) et les places de march6 61ectroniques.
10/51
ANN. TELECOMMUN., 58, n ° 1-2, 2003
18
C. MORLEY -- LES OUTILS DU COMMERCE I~LECTRONIQUE
II.4.1. L'e-procurement
La gestion 61ectronique des achats ou e-procurement, correspond ?a l'automatisation du processus d'achat via internet, dans le cadre des 6changes interentreprises (B-to-B), depuis l'appel d'offres jusqu'au r~glement des fournisseurs. L'e-procurement vise ~ minorer les coots de transaction tout en acc616rant le traitement des commandes. Ces syst6mes concernent en particulier des biens indirects, c'est-h-dire non directement li6s ~t la production, achet6s en grande quantit6 et banalis6s (fournitures de bureaux, produits d'entretien...). Cependant, la n6cessit6 de minimiser d61ais et stocks conduit les entreprises, dont la production est organis6e en modejuste b temps, ~ 6tendre l'eprocument aux achats de mati~res ou services directs. Elles ouvrent alors une partie de leur syst~me d'information pour simplifier leurs 6changes, concr6tisant ainsi le concept d'entreprise 6tendue, dans lequel fournisseurs et sous-traitants deviennent de v6ritables partenaires ayant des objectifs communs orientals client. L'e-procurement est mis en place ?al'initiative de l'entreprise acheteuse. Une solution de type extranet offre la possibilit6 d'acc6der facilement aux catalogues des fournisseurs habituels de l'entreprise, actualis6s en permanence et dot6s de fonctions de recherche efficaces. Ces catalogues informent notamment de la disponibilit6 des produits car ils sont reli6s au syst~me d'information interne des entreprises fournisseurs. Ces syst6mes incorporent des fonctions de workflow grace auxquelles la commande est transmise par vole 61ectronique un responsable charg6 de la valider, elle est alors automatiquement renvoy6e vers le fournisseur. De plus, les 6critures comptables sont directement enregistr6es sur le syst~me interne et les budgets du service acheteur mis ?ajour. De tels dispositifs permettent en cons6quence un meilleur contr61e analytique des d6penses, une r6duction du cycle d'achat, une simplification des tfiches administratives, une baisse des erreurs de saisie. IL4.2. Les places de march~ ~lectroniques
Une place de march6 (marketplace) est une plate-forme 61ectronique, dot~e d'un ensemble de services en ligne, qui permettent ~ des entreprises, en g6n6ral dans le m~me secteur industriel, d'effectuer des 6changes marchands. Ce lieu virtuel d'interm6diation est accessible h plusieurs offreurs et demandeurs (many-to-many), et permet une d6mat6rialisation des transactions inter-organisationnelles [Nieuwbourg, 2000]. On distingue deux types de places de march6. Les places de march6 verticales sont organis6es autour d'un secteur d'activit6 et permettent l'6change de mati~res et de flux d'information destin6s ~ la production. Ainsi, COVlSINTregroupe les t~nors de l'automobile (Ford, General Motors, Daimler-Chrysler, Renault-Nissan) et leur permet d'effectuer des achats aupr~s de plusieurs milliers d'6quipementiers automobiles. Les places de march6 horizontales concernent des domaines transversaux, multisectoriels (fournitures de bureau, pi~ces de rechange industrielles, voyages d'affaires). Ainsi, ANSWORK, lanc6e par BNP-Paribas, la Soci6t6 G6n6rale et le Cr6dit Agricole, offre ~ leurs clients entrepreneuriau× une place d6di6e aux achats hors production. Certaines places de march6 sont privies : par exemple, DaimlerChrysler, tout en participant ~t COVIr~SINT,a cr66 sa place de march6, FastCar, r6serv6e ~ un nombre restreint de ses fournisseurs. Les principales fonctionnalit6s offertes par ces outils peuvent &re class6es en deux cat6gories : la gestion de r6f6rentiels et la gestion des processus op~rationnels (Fig. 5).
ANN, TI~LI~COMMUN,, 58,
n° 1-2,2003
11/51
19
C. MORLEY - LES OUTILS DU COMMERCE I~LECTRONIQUE
La pr6sentation de catalogues expose les diff6rents produits et services des entreprises fournisseurs adhErentes de la place de march& Les catalogues sont particuli6rement adapt6s aux articles standardis6s et pour lesquels le prix est relativement stable. Les d6p6ts d'appels d'offres donnent lieu ~ un syst6me de raise aux ench6res. A c6t6 des traditionnelles ench~res ascendantes, des syst~mes d'ench~res inversEes permettent h l'acheteur de proposer une requate d'achat, incitant les fournisseurs int6ress6s h y r6pondre ~ un tarif moindre. Dans ce cadre, acheteurs et vendeurs doivent &re capables de prendre des d6cisions rapides, car les op6rations s'effectuent en un temps limit&
.....................
'
Founfisseurs I
j
M6ta-caialogue Produ ts
•
....................................
Mod61esd"e [ Contrats ;
J
Formulaired'appel] : d'offres ....
FIG. 5. - - Fonctionnalitdsproposdespar les places de march& Electronic market placefunctionalities.
Les places de march6s permettent en g6n6ral de g6rer les principales 6tapes du processus d'approvisionnement (e-procurement). Ces outils proposent des fonctions visant ~t rationaliset les diff6rents processus, pour optimiser les stocks et la logistique, dans le cadre de la supply chain. Parfois, la plate-forme cherche ~ avoir un r61e f6d6rateur pour le secteur. Ainsi, la mise disposition de contenu sectoriel (nouvelles du secteur, articles sp6cialis6s, archives, analyse des transactions et comportement des acheteurs et vendeurs au sein du march6 virtuel) et l'6change direct entre membres de cette communaut6 (forums de discussion, 6changes avec des experts...) permettent une fid61isation croissante des partenaires impliqu6s. Enfin, la raise en ligne des nouvelles 16gislations et r6glementations li6es au secteur, du calendrier des 6v6nements importants, d'offres d'emploi ou de formation et de l'6valuation de la qualit~ des partenaires commerciaux peut apporter une valeur ajout6e significative ~ la place de march& ,~ terme, ces plates-formes offriront ~ leurs participants des outils de travail collaboratif [Pick, 2001]. Par exemple, elles permettront de concevoir de nouveaux produits, en pro12/51
ANN. TI~LflCOMMUN., 5 8 ,
n° 1-2,2003
20
C. MORLEY -- LES OUT1LS DU COMMERCE ELECTRONIQUE
posant aux bureaux d'6tudes des clients et fournisseurs, l'4change de plans et de fichiers CAO (conception assist6e par ordinateur), ou d'61aborer un planning de conduite de projet en commun. C'est d6j?a le cas de la place de march6 Buzzsaw, dans le secteur du BTP : h travers cette plate-forme, les diff6rentes entreprises impliqu6es sur un m~me chantier peuvent acc6der aux donn6es techniques, h l'6tat d'avancement et au planning d'intervention de chaque acteur. Toutes ces fonctions induisent l'6tablissement d'une normalisation des outils utilis6s par les diff6rents partenaires et des codifications d'articles 6chang6s, ainsi qu'une rationalisation des m6thodes de travail des divers partenaires. Les places de march6 exigent une masse critique d'4changes et doivent donc favoriser les effets de rdseau indispensables ~t leur r6ussite. La valeur ajout6e propos6e par la place de march6 r6sidera dans les difffrents services offerts ~t cette communaut6, en permettant un maximum d'6changes ~t travers divers processus entrepreneuriaux [Kaplan, 2000]. Ceci explique les alliances entre concurrents et les fusions de ces march6s 61ectroniques en cours ou fi venir. L'implantation de tels espaces virtuels n~cessite l'interconnexion des outils applicatifs des diff6rents membres de la communaut6 via la place de march& I1 s'agit de d6velopper des modules informatiques mettant en relation ERP ou logiciels utilis6s par les entreprises adh6rentes et d'interconnecter ainsi les syst~mes d'informations pour 6viter les redondances de saisie et automatiser les flux d'informations 6chang6es. Cependant, la connexion entre les divers syst6mes ERP utilis6s par les principaux membres est difficile et lente h mettre en oeuvre [Barratt, 2002]. Mame lorsqu'il s'agit de syst6mes commercialis6s par un m~me 6diteur (SAP, BAANOU JD Edwards), il n'est pas ais6 de faire communiquer ces outils, notamment en raison des codifications de produits, r6f6renc6s souvent de mani6re difffrente par chaque entreprise. C'est pourquoi Fun des facteurs cl6s de succbs de l'expansion de ces march6s 6lectroniques r6side dans la mise en place d'un langage commun de codification, aussi bien informatique que sectoriel, permettant ainsi une homog6n6isation des r6f6rences capable de fluidifier les 6changes inter organisationnels. XML est appel6 ~ jouer ce r61e pour la partie informatique.
11.5. L'entrepSt de donn6es Un entrep6t de donn6es ou data warehouse, est une base de donn6es ~tvocation d4cisionnelle, aliment6e par les fichiers ou bases de donn6es produits par les applications op6rationnelles. L'objectif de raise en place d'un entrep6t est de rassembler, en un lieu unique, un ensemble d'informations compl6mentaires mais 6parpill6es [Franco, 2000]. Dans un contexte de e-commerce et de gestion de la relation client, un data warehouse peut permettre de consolider des donn6es clients, enrichies de donn6es extemes (g6ographiques, d6mographiques) pour avoir une vision plus solide du profil client. Les donnfes ne sont pas toujours conserv6es dans leur int6gralit& Par exemple, dans un contexte bancaire, on peut ne stocker que le solde mensuel d'une carte de cr6dit, et non le d6tail des transactions. L'entrep6t contient ~t la fois des donn6es d6taill6es, des donn6es agr6g6es correspondant h des besoins d'analyse et des donn6es historis6es. Les donn6es entrant dans un entrep6t font l'objet d'une d4normalisation. Ainsi, on peut introduire des redon-
ANN. TI~LI~COMMUN.,58, n ° 1-2, 2003
13/51
c. MORLEY-- LES OUTILSDU COMMERCE[~LECTRON1QUE
21
dances pour rdduire le temps de traitement de certaines requ&es. On peut 6galement compl6ter des donn6es manquantes par des valeurs par d6faut. Une solution de data warehouse comprend deux types d'outils (Fig. 6) : 1. Les outils d'extraction et de transformation sont des applications permettant d'automatiser l'alimentation de l'entrep6t de donndes (ETL, extracting, transforming, loading). Elles permettent de d6crire la structure d'un fichier ou d'une base de donn6es, c'est-~t-dire d'en repr6senter les m6ta-donn6es, ainsi que les r6gles de transformation permettant de passer des m&a-donn&s de la source aux mdta-donn6es de la cible. 2. Les outils d'interrogation permettent de traiter des requ&es (query) et de produire des 6tats formatds (report).
M&a-donndes
u'
Do~nn~es d 6 t a i
f
..........
FIG.6. - - Les outils du data warehouse.
Datawarehouse tools.
La recherche d'une optimisation des temps de traitement des requ&es a conduit ~ proposer un type particulier de base de donndes : les bases de donn6es multidimensionnelles, conques pour le traitement de requ&es en ligne (OLAP, On line analytical processing). Ces bases de donn6es sont organis6es selon diff6rentes dimensions, d6finies a priori, par exemple ta date, la region, le magasin et le type de produit. Ces dimensions permettent de construire des interrogations, en naviguant dans un hypercube. Une base de donn6es multidimensionnelle peut &re impl6ment6e avec un syst6me de gestion de base de donn6es relationnel : une table centrale (la table des faits) est reli6e, selon un mod61e en &oile, h plusieurs tables (Fig. 7). Les besoins du commerce 61ectronique ont conduit h construire des bases de donn6es OLAPsur des documents XML [Jensen, 2001 ]. Un data warehouse vise h rassembler l'int6gralit6 des donn6es. Un data mart est un magasin de donndes sp6cialis& par exemple la cible d'une campagne marketing. On peut trouver diff6rents magasins de donndes dans une entreprise, extraits ou non d'un entrep6t global. Un type particulier de data warehouse, dans le contexte de la vente en ligne, est le data webhouse [Kimball, 2000] : cet entrep6t de donn6es conserve la trace de ta navigation des internautes sur les pages d'un site, appel6e le clickstream (courant continu de clics). L'analyse de ces informations permet notamment de mettre en 6vidence les types de parcours qui se concrdtisent par une vente, ainsi que ceux qui conduisent ~ l'abandon. 14/5l
ANN.~LI~COMMUN.,58, n° 1-2, 2003
22
C. MORLEY -- LES OUTILS DU COMMERCE I~LECTRONIQUE P~riode
Fournisseur
Jour : integer Mois : integer I Ann6e : integer ~ . ~ •
'
~
.. ~ / 1
~v,a g a s m
-~S-----7-Nora magasm : stnng Groupe : string R6gion : string
N ° fournisseur : string [ ] Nora fournisseur : string ] f l Implantation : undefined ..---" I
~ ~
Table des fails ~
Quantit6 : integer CA: real ~ I Marge : real ] ~
~
Prodmt Nom produit : string N ° produit : string Prix vente : real Prix achat : real
FIG. 7. - - Mod61e d'une base de donn6es multidimensionnelle. Multidimensional database model
Elle peut 6galement conduire ~ d6finir des comportements types pour une 6ventuelle personnalisation ult6rieure. Le fichier source d'un data webhouse est le journal des logs du serveur Web.
II.6. L'exploration de donn6es L'objectif de l'exploration de donnEes (data mining ou fouille de donn6es), est de d6couvrir des informations cach6es h l'aide de techniques math6matiques et statistiques. Cette production de connaissances nouvelles, r6sulte de l'6tude automatique d'un volume important de donn6es. Ces donn6es peuvent avoir 6t6 pr6alablement engrang6es dins un entrep6t de donn6es, mais ce n'est pas obligatoire. Le data mining repose sur trois 616ments : la d6tention par les entreprises d'une masse d'informations issues des syst~mes op6rationnels et faiblement exploit6es ; les besoins de mieux d6finir et cibler les actions marketing pour des raisons de cofit et d'efficacit6; et la mise au point de techniques d'analyse des donn6es h l'aide de moyens informatiques [Berry, 2000]. On classe souvent les activit6s/produits du data mining en six cat6gories. Les trois premiers types d'outils, qui sont le plus fr6quemment utilis6s, visent h construire un module ; les trois types suivants ont pour but de faire 6merger des relations entre les informations. 1. La classification consiste h r6partir les donnEes, pr6sent6es sous forme d'enregistrements dins une base de donn6es, dins des classes qui ont 6t6 d6finies a priori. On peut, par exemple, classer les abonnements de t616phonie fixe selon leur taux d'utilisation en acc~s internet dins les six derniers mois. La classification permet notamment de d6finir une cible, dont les caract6ristiques permettront ensuite d'extraire les clients h viser pour une campagne marketing. ANN. TI~LI~COMMUN.,58, n ° 1-2, 2003
15/51
C. MORLEY -- LES OUTILS DU COMMERCE E,LECTRONIQUE
23
2. L'estimation est souvent utilis6e en amont d'une classification. L'activit6 consiste produire une nouvelle information/~ partir des informations pr6sentes, pour enrichir la base de donndes. Par exemple, estimer le niveau de revenu des clients, h partir des informations sur 1' adresse et la consommation observde. 3. La prgdiction est une forme d'estimation, qui vise h prdvoir un comportement, par analyse de comportements d' autres clients. Par exemple, on peut chercher ?aestimer la probabilit6 qu'un client se tourne prochainement vers un autre fournisseur, ou bien d6terminer les caractdristiques des clients susceptibles d' accepter une oft're. 4. Le groupement par affinitg consiste ~t rechercher, en analysant les donn6es, d'6ventuelles r6gles d' association. Par exemple, l'analyse du contenu des paniers pourra faire appara~tre que certains articles sont toujours achet6s simultan6ment; cela pourra conduire le marketing a 61aborer des propositions group6es. 5. Le clustering est une technique qui vise ?arechercher des similitudes entre les enregistrements analys6s et de proposer une classification a posteriori. Par exemple, on peut vouloir classer les clients internautes selon leurs types d'achats. Cette segmentation pourra ~tre ensuite utilis6e, par exemple pour mesurer le succ~s d'une campagne promotionnelle sur chaque segment. 6. La visualisation vise ~ pr6senter de faqon visuelle des rapprochements entre les enregistrements d'une base de donn6es. Par exemple, une telle analyse pourra faire apparaltre un comportement diff6rent - et insoupqonn6 - selon le sexe ou le lieu d'habitation. L'exploration et la visualisation des donn6es utilisent notamment des mdthodes factorielles (analyse en composantes principales, analyse de correspondance, analyse discriminante). La recherche d'un mod61e pr6dictif s'appuie sur des m6thodes de r6gression, des arbres de d6cisions, des analyses factorielles ou des r6seaux de neurones. L'utilisation des outils de data mining se d6cline sur deux modes : dans l'exploration automatis6e, tr~s rdpandue, le ddcideur exprime l'int6gralit6 de sa demande avant le lancement du traitement, alors que dans l'exploration libre le d6cideur interagit avec le logiciel. En termes d'outils applicatifs, le data mining s'int~gre aujourd'hui dans un syst6me de veille 6conomique ou BI (Business Intelligence), d6finie comme un ensemble d'outils visant ~t produire de fa~on efficiente des informations pertinentes pour des managers, partir d'un tr~s grand volume de donn6es [Ortiz, 2002]. Ces outils sont particuli~rement int6ressants dans le contexte du e-commerce, quand les entreprises reqoivent de nombreuses informations en ligne et les stockent dans des bases de donn6es pour une analyse ult6rieure ou marne parfois en temps r6el. Une analyse en temps r6el peut, par exemple, servir ~ recommander des produits additionnels ~ un acheteur en ligne, en fonction de ses achats pr6c6dents et de son profil. Les services Web, dont la technologie est pr6sent6e au paragraphe IV.4.1, permettent aux entreprises d'accdder ~t de nombreuses informations mises ~ dispositions par leurs partenaires et leurs fournisseurs : les syst~mes de B~ apportent une aide ~ l'exploitation de ces informations.
11.7. Les progiciels de gestion int~gr~s Un PGI (Progiciel de Gestion Int6gr6) ou ERP (Enterprise Resource Planning) est un ensemble d'applications fortement int6gr6es. Construits de fa~on modulaire, les ERP couvrent 16/51
ANN. TI~LI~COMMUN,, 58, n ° 1-2, 2003
24
c. MORLEY -- LES OUTILS DU COMMERCE I~LECTRONIQUE
plusieurs fonctions et sont consid6r6s comme la colonne vert6brale du syst6me d'information de l'entreprise. En principe, ils assurent la gestion de l'ensemble des flux de mati6res et des flux financiers de l'entreprise, c'est-h-dire ses ressources [Tomas, 2002]. La mise en oeuvre d'un ERP constitue une 6volution darts l'architecture des applications inforrnatiques de l'entreprise et r6pond hun probl6me qui s'est amplifi6 au cours du temps. Les organisations ont d'abord d6velopp6 des applications refl6tant un besoin sp6cifique. De 15 est ride une situation h6t6rog6ne, dans laquelle chaque division de l'entreprise g6rait ses donn6es dans des silos verticaux, sans possibilit6 d'6change. Les saisies de donndes, parfois redondantes, dans des syst6mes h6t6rog6nes souvent incompatibles, multipliaient les risques d'erreurs et d'incoh6rences au sein du syst~me d'information. Pour accro~tre leur efficience et leur productivit6, dans un contexte de mondialisation des march6s et de concurrence accrue, les entreprises ont cherch6 ~ uniformiser et restructurer leurs processus et leurs flux d'information lors d'op6rations de reconfiguration (BPR, business process reengineering). Des 6diteurs ont alors propos6 des outils param6trables, permettant de g6rer de faqon int6gr6e l'ensemble des fonctions vitales des entreprises et des flux majeurs, d'oia la naissance des ERP. Les diffdrents modules visent ?t automatiser les opdrations quotidiennes de l'entreprise pour les rendre plus efficaces. Ces modules sont interconnect6s : historiquement, on distingue cinq grandes briques (Fig. 8). L'616ment central est la gestion financi6re (comptabilit6 g6n6rale, comptabilit6 analytique, gestion de tr6sorerie, gestion budg&aire). L'ERP s'appuie sur un noyau fonctionnel et informationnel central (core system), qui reprend toutes les activit6s des diff6rents centres de responsabilit6s de l'entreprise, selon une vision processus : processus comptable, processus contr61e de gestion, processus logistique, processus vente...
F~G. 8. - -
P6rim~tre f o n c t i o n n e l initial des ERP.
ERP initial components. ANN. T~LECOMMtm., 58, n ° t-2, 2003
17/51
25
C. MORLEY - LES OUTILS DU COMMERCE I~LECTRON1QUE
Les informations sont saisies de fat;on unique, g6n6ralement mises ~t jour en temps r6el, au sein de bases de donn6es centralis6es. Le terme ~, int6gr6 ~>renvoie principalement ?a la notion d'unicit6 de l'information. La centralisation 6vite la redondance et permet la tra~abilit6 : a partir d'une information donn6e, il est possible ~t tout moment de remonter h l'information d'origine. L'adoption d'un ERP oblige notamment ~ uniformiset les trois rdf6rentiels fondamentaux utilis6s par l'organisation : Fournisseurs, Clients et Articles. Chaque membre, quelle que soit sa fonction, dispose donc ~ tout moment des mSmes informations. Cependant, les exigences de s6curit6 n6cessitent d'6tablir des proc6dures rigoureuses de gestion des profils utilisateurs, qui restreignent pour chacun 1' acc6s aux seules informations qui le concernent. Pour 6viter toute fraude, la s6paration des fonctions est d'aurant plus fondamentale. Le r61e de chaque acteur doit &re bien d6fini pour que les contr61es n6cessaires puissent ~tre exerc6s. Initialement congus pour administrer la production et la finance, les ERP 6voluent pour offrir une plate-forme de e-business [Zurek, 2001]. Ils se sont pour cela enrichis de nouvelles briques applicatives, notamment pour g6rer les relations commerciales (¢RM) et la logistique (SCM), ainsi que pour apporter une aide ~ l'analyse des informations (Business Intelligence). Ces trois fonctions constituent une part encore faible, mais en croissance forte (Fig. 9). La mise en place de solutions lnternet est devenue aussi strat6gique pour l'entreprise que la raise en oeuvre de I'ERP. Ce dernier s'dtend d6sormais progressivement au CRM, aux places de march6 et aux technologies Web via la notion de portail d'entreprise. L'information doit ~tre accessible ~t partir de tout support, de n'importe quel endroit, proposant ainsi un processus collaboratif. La vision fonctionnelle initiale de l'architecture applicative a laiss6 place ~t une d6marche d'int6gration (ERP) et s'oriente maintenant vers une optique tournde vers les partenaires externes, dans le cadre de l'entreprise 6tendue [Yen, 2002b].
GPAO 23,5 %
Ressources Humaines 10,7 %
!
//
/
/'
Autres 1,0 %
Gestion Commerciale 24,4 %
Fl(;. 9. --
SCM 5,7 %
Business Intelligence ~ 2 , ~ M 3,1% , %
Comptabilit6 Finance 29,6 %
Le march6 des progiciels ERP par modules applicatifs (Source IDC France 2000). ERP application component marketshares.
18/51
ANN. TI~LI~COMMUN., 58, n ° 1-2, 2 0 0 3
26
C. MORLEY - LES OUTILS DU COMMERCE I~LECTRONIQUE
CONCLUSION
Darts les annEes qui viennent, on devrait assister ~ une croissance forte des investissements en mati~re de B-to-B, en particulier autour du SCM (partage d'informations, processus collaboratifs) [Lee, 2001]. Les investissements en matiEre de CRM dEpassent aujourd'hui les investissements en ERP traditionnel. La supply chain commence ~t inclure l'interaction avec les places de march6 publiques ou privEes. Le march6 semble marqu6 par la fin de l'idEe du produit intEgr6 qui couvre toutes les fonctions du e-commerce, m~me si les 6diteurs d'ERP mettent en avant l'avantage d'une solution compl~tement intEgrEe. En rEalitE, la solution d'intEgration ne peut venir que d'un travail de fond, sur les processus et les donnEes lies aux metiers. Les entreprises sEnt donc confrontees ~ la nEcessitE d'intdgrer des progiciels d'origines diverses.
III. MODI~LES ET TECHNOLOGIES
POUR LE DI~VELOPPEMENT D'APPLICATIONS E-COMMERCE
Les syst~mes de commerce 61ectronique sEnt des systEmes complexes qui font coopErer des logiciels, materiels et bases de donnEes hEtErogEnes en mode distribu6. C'est pourquoi leur construction et leur specification doivent s'appuyer sur des representations a tousles niveaux, depuis une vision metier jusqu'h l'architecture logicielle. L'intEgration des processus inter et intra-organisationnels et la raise en correspondance sEmantique des informations s'appuie de plus en plus sur une representation des processus et des donnEes. Le langage de modElisation UML, normalis6 par I'OMG,offre l'avantage d'une utilisation ~tdiffErents niveaux de construction d'un syst~me e-commerce [Saleh, 2002]. C'est pourquoi il est present6 en section III. 1. Le dEveloppement d'applications e-commerce, dEnt nous venons de brosser un panorama, repose en grande partie sur les technologies autour du www (World Wide Web, toile d'araignOe mondiale). La section 111.2 est consacr6e ~t la prdsentation du fonctionnement de ces technologies, en constant essor depuis le debut des annOes 1990, avec une focalisation sur un point sensible dans le cas du e-commerce : la liaison entre le web et les donnEes de l'entreprise. Parmi les 6volutions, la technologie XML occupe une place privildgiOe dans les Echanges inter-applicatifs lies aux besoins du commerce 61ectronique qui requiert de pouvoir faire communiquer des systEmes de diffErentes entreprises ou diffErents pays : elle fait l'objet de la section 111.3.
III.1. Le cadre m~thodoiogique : UML Ill.l.1. Presentation
d'UML
UML, Unified Modeling Language, est un langage, entendu comme un ensemble organisE de composants (classes, objets messages, EvEnements...), rEgi par des r~gles de grammaire strictes, permettant de representer et specifier un syst~me informatique. UML est issu de trois de mEthodes d'analyse orientEes objet, OOD, OMT et OOSE, dEnt l'objectif 6tait d'augmenter la ANN. Tt~LI~COMMUN., 58, n ° 1-2, 2003
19/51
C. MORLEY - LES OUTILS DU COMMERCE ~,LECTRONIQUE
27
rigueur et la qualit6 quand on construit une application, et de favoriser la rSutilisation de classes et d'objets. La socidt6 Rational Software a rSuni les auteurs principaux de ces trois m6thodes pour qu'i[s s' accordent sur un langage de mod61isation dans 1' espoir qu' il devienne une r6f~rence. Sa r~ussite fut d'8tre retenu en 1997 comme norme de mod61isation par ]'OMG (Object Management Group), apr~s avoir requ le soutien de plusieurs grands constructeurs informatiques et 8diteurs de logiciel. UML est maintenant plac6 sous le contr61e de l'OM6, dont la mission est de promouvoir les technologies objet. L'OMG construe des groupes de travail, ouvre des forums de discussion et lance des appels d'offres pour l'am61ioration et l'6volution d'uM~ par versions. Avant de dScrire le contenu d'UML, il est nScessaire de rappeler deux concepts de base dans la mod61isation objet : l'objet et la classe. Un objet est un 61~ment mat6riel ou immat~riel de la r6alit6 6tudi6e : il peut 8tre distingu6 des autres objets environnants - il a une identit6 ; il est dot8 de permanence dans le temps, mEme s'il passe par diff~rents 6tats; on peut lui attacher des comportements, c'est-8-dire des actions qu'il peut exdcuter ou subir. Une classe est un regroupement d'objets sur lesquels on peut reconnaitre des similitudes portant sur la faqon de les identifier, les 6tats qu'ils sont susceptibles de prendre et les r61es qu'ils peuvent jouer. Passer d'une classe aux objets qui la peuplent s'appelle l'instanciation. Instancier une classe consiste ~. faire apparaitre un objet conforme au module donn~ par la classe. Ill. 1.2 Le c o n t e n u d'UML UML, <( langage graphique pour visualiser, sp6cifier, construire et documenter les artefacts d'un systhme fortement informatis6 >>3 est d6crit par un m6ta-modhle, c'est-a-dire une repr6sentation de ses constituants 616mentaires, avec leurs rhgles d'emploi et de syntaxe. Ce m6tamod6le, 61abor6 au moyen du langage UML lui-m4me, constitue une sp6cification d6taill6e pour les 6diteurs d'atelier de g6nie logiciel supportant UML et garantit la coh6rence interne du langage. Le terme ~, langage de mod61isation ~ et non celui de ,, m6thode ~ signifie qu'UML n'indique aucune faqon d'utiliser le langage. A chacun de trouver une s6mantique dans son utilisation. Les concepteurs d'tJML ont souhait6 donner au langage un caract6re extensible, en offrant tout utilisateur la possibilit~ de rajouter des 616ments dans le malta-modUle. Ces extensions, principalement utilisees pour introduire des classifications additionnelles, sont appel6es stdrdotypes. On trouve, en particulier, trois st6r6otypes largement utilis6s : l'entit6 (classe permettant de ddcrire les informations), l'acteur (classe repr6sentant une cat6gorie d'utilisateurs du syst~me, qui jouent un ensemble coh6rent de r61es) et l'interface (classe regroupant un ensemble d'op6rations correspondant ~ un service offert). La d~finition, pour un contexte ou une finalit6 donn6e, d'un ensemble de stdr6otypes repr6sente un (< profil UML ,>. UML propose des regroupements de ses constituants : un diagramme est la repr6sentation graphique d'un tel regroupement. I1 y a neuf diagrammes, dont nous dvoquerons l'utilisation dans le cadre du e-commerce. Les deux premiers, le diagramme de classes et le diagramme d'objets, permettent de repr6senter la structure statique du syst6me/~ mod6liser. Les deux demiers, le diagramme de composants et le diagramme de d6ploiement, donnent une representation des composants logiciels, ainsi que de Farchitecture logique ou physique du syst6me. Les cinq diagrammes 3. Les specifications du langage UML (version 1.4, septembre 2001) peuvent 6tre trouv6es sur [e site de I'OMG : www.omg.org... Pour une description comment6e de l'utilisation d'UML : voir [Morley, 2002] au niveau m6tier, ]Carlson, 2001] au niveau des composanls applicatifs et [Cnuallen, 2000] au niveau application web. 20/51
ANN. T/~LEf'OMMUN., 58, n ° I-2, 2003
28
c . MORLEY -- LES OUTILS DU COMMERCE I~LECTRONIQUE
restants servent ~ d6crire la dynamique du syst~me, chacun sous un angle particulier. Le diagramme de cas d'utilisation donne le point de vue des utilisateurs potentiels du syst~me. Le diagramme de s6quence et le diagramme de collaboration montrent la dynamique d'interaction entre les objets concern6s par une collaboration. Le diagramme d'activit6s mod61ise les 6tats des instances d'une classe. Le diagramme d'activit6s d6crit en d6tail un enchainement d'actions mettant en jeu des classes. ~" Le diagramme de classes Le diagramme de classes, fortement marqu6 par le formalisme du mod61e Entit6-Relation, permet de faire apparaitre un ensemble de classes, ainsi que les relations qui les unissent. II est notamment utilis6 pour repr6senter l'ensemble des informations formalis6es, ayant fait l'objet d'une d6finition sur le fond et sur la forme, qui sont g6r6es par le syst6me. Ces informations 61~mentaires, appel6es attributs, sont regroup6es en classes (entit6s), qui sont autant de concepts globaux d'information. Comme un attribut ne peut appartenir qu'~ une seule entit6, on a parfois besoin de faire r6f6rence dans une classe donn6e hun attribut figurant sur une autre classe : pour cela on fait apparaitre une association entre les deux classes. Une classe-association est une association porteuse d' attributs, mais d6pendante de deux ou plusieurs classes. Les classes peuvent porter des op6rations : cette possibilit6 est utilis6e, par exemple, pour d6crire des objets IHM (interface homme-machine). Outre les informations, on peut repr6senter avec un diagramme de classes les diff6rents types d'acteurs d'un syst6me de commerce 61ectronique : ces classes (ou leurs instances) seront ensuite utilis6es darts des diagrammes de la dynamique (diagramme de s6quence ou diagramme d'activit6s). Le diagramme de classes peut 6galement permettre de repr6senter une cin6matique d'enchalnement de pages-6crans, avec l'utilisation du st6r6otype ~ interface ~>dans un sens d'interface homme-machine [Conallen, 2000]. Le diagramme d'objets Le diagramme d'objets est similaire au diagramme de classes, mais il met en jeu des objets, instances ou non de classes, ainsi que leurs liens. I1 peut repr6senter une structure de document HTML. m- Le diagramme de cas d'utilisation Un cas d'utilisation exprime une faqon particuliSre d'utiliser le systSme, selon un point de vue utilisateur. Plusieurs cas d'utilisation peuvent ~tre regroup6s dans un diagramme de cas d'utilisation, o~ l'on voit appara~tre les acteurs susceptibles d'utiliser les cas. Le cas d'utilisation est d6crit par un texte ou par un autre diagramme UML, par exemple un diagramme de s6quence ou un diagramme d'activit6s. Le concept de cas d'utilisation permet de donner des repr6sentations des processus m6tiers selon le point de vue des difffrentes parties prenantes dans un syst6me de commerce 61ectronique. Le diagramme de s6quence Le diagramme de s6quence permet de visualiser le d6roulement temporel d'une succession d'6changes de messages entre objets, avec 6ventuellement des conditions de garde contraignant l'envoi. I1 permet notamment de simuler le ddroulement d'un sc6nario, par exemple le traitement en ligne d'une d6claration de sinistres entre un assur6 et sa compagnie. ANN. TI~LI~COMMUN., 58, n ° I-2, 2003
21/51
29
C. MORLEY -- LES OUTILS DU COMMERCE IELECTRONIQUE
m, Le diagramme de collaboration Le diagramme de collaboration est une variante du diagramme de s6quence, avec une topographie plus souple. I1 fait apparai'tre les 6changes de messages entre des objets qui communiquent dans le cadre d'une collaboration. On peut, par exemple, repr6senter un sc6nario d'achat en ligne d'un produit 61ectronique c o m m e une succession ordonn6e de messages entre le navigateur d'un client, une application vente en ligne sur le serveur d'accueil, un serveur de paiement ainsi qu'un serveur de banque. D Le diagramme d'~tats-transitions Le diagramme d'6tats-transitions est une forme de machine ~t 6tats finis. Il est associ6 ~t une classe et montre les diff6rents 6tats dans lesquels peuvent se trouver les instances de la classe, en fonction des choix de gestion que l'on a faits. ,~ chaque 6tat, on peut associer des actions qui sont d6clench6es soit h l'entrde dans l'6tat (entry), soit ~t la sortie (exit), soit ~a la r6alisation d'un dvdnement. Le passage d'un dtat 1/t un 6tat 2, appel6 transition, s'effectue ~t la r6alisation d'un dv6nement. Dans un contexte de vente en ligne de produit complexe, n6cessitant un configurateur, on peut ainsi repr6senter la classe commande et ses diff6rents 6tats selon l'avancement de la transaction d'affaires (produit s61ectionn6, configuration arr~tde, proposition accept6e...). Le diagramme d'activitds Le diagramme d'activit6s, h l'origine consid6r6 c o m m e une variante du diagramme d'6tats-transitions, occupe une place croissante, notamment pour ddcrire les processus m6tier intra ou inter-organisationnel. I1 d6crit un encha~nement d'activit6s, en faisant 6ventuellement figurer les acteurs qui en sont responsables. I1 permet de faire appara]tre les instances de classes touch6es par l'activit6, avec l'6tat dans lequel dolt se trouver l'instance. I1 offi'e la possibilit6 de faire apparMtre des branchements conditionnels, ainsi que des synchronisations ouvertes ou fermdes. Les diagrammes d'impl6mentation Les diagrammes d'impldmentation contiennent principalement deux 616ments : les nceuds et les composants. Un composant correspond souvent ~ un fichier ex6cutable ; ce peut ~tre la r6alisation logicielle d'une ou plusieurs classes de type interface. Un neeud est un objet physique qui repr6sente une ressource de traitement. Ce sont souvent des machines physiques. Le diagramme de composants met en 6vidence les liens entre composants. Le diagramme de d6ploiement repr6sente une architecture d'616ments physiques, dventuellement avec des composants I I I . 1 . 3 . Les utUisations d'uMI, dans le cadre du commerce ~lectronique
llI. 1.3.1. L a g d n 6 r a t i o n 5, p a r t i r d ' U M L
UML est un outil d'analyse et de conception d'un syst6me. Certains 616ments peuvent servir de base ~ la gdn6ration de structures de donn6es ou de code. Par exemple, le schema d'une base de donn6es relationnelle peut atre produit automatiquement ~t partir d'un diagramme de classes des entit6s. La DTD associ6e h u n document XML peut ~tre 6galement g6n6r6e fi partir d'un diagramme de classes UML. L'OMG a inclus dans la spdcification UML des r~gles de g6n&ation de code h partir de diagrammes UML dans un langage appel6 IDC (Interface Definition Language). 1DE n'est pas un 22/51
ANN. TI~LECOMMUN.,58, n ° I-2, 2 0 0 3
30
c. MORLEY -- LES OUTILS DU COMMERCE I~LECTRONIQUE
langage de programmation, mais il est possible de gEn~rer du code Java, C ++ ou Visual Basic, partir de code ]DL. Ce dernier est orient6 vers la definition d'interfaces. Ainsi un dEveloppeur pent, avec un atelier de genie logiciel (case tool) adEquat, dEfinir les interfaces entre composants applicatifs h l'aide de diagrammes UML, pour ensuite gEnErer du code, via une transformation en IDL. De faqon plus large, OMLest le langage de modElisation retenu par I'OMG darts sa nouvelle approche de dEvetoppement, baptisEe MDA (Model Driven Architecture) et basEe sur le fait qu'aucune technologie n'est hEgEmonique. MDA propose de modEliser un syst~me informatique ~ diffErents niveaux d' abstraction en utilisant UML, depuis la cartographie des processus et objets metier jusqu'aux composants [Soley, 2000]. Toute Evolution du systEme d'information s'appuierait sur une modification des mod6les de niveau supErieur, garantissant ainsi la coherence des representations. Pour r6duire les probl~mes d'interop6rabilitE, l'approche MDA pr6conise de faire appara]tre un niveau ind6pendant des technologies d'implantation et des niveaux dependants, les technologies elles-mEmes 6tant modElis6es avec des profils tJML spEcifiques [Emmerich, 2002]. Cette approche renouvelle et 61argit la vision des ateliers de genie logiciel qui principalement orientEs vers la gEnEration d'applications. L'objectif de MDA est 6galement de spEcifier de maniEre quasi-automatique le passage d'un niveau h un autre, mais en se centrant prioritairement sur la gEnEration automatique des interfaces lors de l'assemblage de composants, ce qui est un point crucial pour les applications de commerce 61ectronique, en particulier les applications de services web 4 qui font interagir des plates-formes de clients et fournisseurs hEtErogEnes [Siegel, 2002]. Cela permettrait notamment, au niveau de l'architecture logicielle, de passer facilement d'une solution h l'autre 5. Ill. 1.3.2. UMLet la modElisationdes processus Nous avons vu que la cha]ne logistique joue un rEle stratEgique dans le commerce 61ectronique : la gestion des flux d'informations et de biens, en partenariat avec clients et fournisseurs, devient cruciale. De mEme la gestion de la relation client nEcessite une vision intEgrEe des diffErents flux entre l'entreprise et le client. Le courant actuel de l'urbanisation des systEmes d'information [LongEpE, 2001] propose de dresser une cartographie des processus intra et inter-organisationnel pour ma]triser leur Evolution. L'utilisation d'un langage de modElisation normalisE facilitant le partage, on recourt de plus en plus ~t des diagrammes UML, en particulier le diagramme d'activitEs, pour modEliser les processus intra ou interorganisationnels [Toulet-Lambert, 2000], mettant en Evidence les classes informationnelles utilisEes ou EchangEes. Par ailleurs, les outils de gestion du workflow proposent gEnEralement un langage graphique de description d'un processus workflow. Cependant, il est prEfErable, en particulier quand on vent construire des workflow distribuEs entre plusieurs entreprises, comme c'est le cas dans les applications de B-to-B, d'utiliser un langage indEpendant des outils : UML pent jouer ce r61e [Aversano, 2002]. On pent cependant considErer qU'UML est concurrencE, en ce qui concerne l'objectif de modElisation des processus en rue de leur automatisation, par l'initiative BPM1 (Business Process Management Initiative) qui a propose un langage pour modEliser les
4. DEcrits dans la troisiEme pattie, § 1V.4. I. 5. Par exemple, faire passer une application implant6e sons Corba ~ une implantation .net (cf. §IV.2). ANN. TI~LI~COMMUN.,58, n ° 1-2, 2003
23/51
C. MORLEY
31
t.ES OUTILS DU COMMERCE I~LECTRON1QUE
processus m6tier : le BPML (Business Process Modeling Language, langage de mod61isation des processus mdtier. En r6alitd, les concepts du BPML sont compatibles avec une version simplifide d' UML (diagramme d'activitds ou un diagramme de sdquence) et le BPML permet de transformer la description d'un processus en un schdma XML, puisqu'h chaque concept BPML (participant, message, activitd, r6gle...) correspond une description en XML. On peut donc conclure davantage h une compldmentarit6 qu'~t une concurrence. IIl. 1.3,3. UML ct 1;.).m 6 t a - m o d 6 1 i s a t i o n
UML permet non seulement de mod61iser des processus et des informations, mais 6galement de construire des m6ta-modSles, c'est-h-dire de moddliser un ensemble de modeles. De fagon gdn6rale, on parle de m6ta-donndes, lorsque l'on d6crit la structure d'un ensemble de donn6es de niveau infdrieur. Les m6ta-donn6es servent notamment h construire un Data warehouse, qui doit accepter des donn6es issues de structures diffdrentes, pour alimenter une base unique. I1 est doric essentiel de s'appuyer sur une description de la structure des tables, fichiers ou bases de donn6es en entrde pour pouvoir transformer. Darts le cas des march6s 61ectroniques, un probl6me majeur est la gestion conjointe de catalogues provenant de partenaires et porteurs d'incompatibilit6s structurelles, voire d'incoh6rences ou de redondances sdmantiques. La m6ta-moddlisation permet ainsi d'intdgrer ces sources d'information h6t6rogenes, sans obliger les partenaires h se conformer h une structure unique [Benetti et al., 20021. La mdta-mod61isation s'inscrit dans le cadre conceptuel propos6 par I'OMG qui structure la m6ta-mod61isation en trois niveaux s'appuyant sur UML. Le niveau le plus haut est appel6 MO)~ (Metamodel Object Facility) : c'est un langage de moddlisation de mdtamod6le. MO~ est en fait un sous-ensemble d'UML. Chaque niveau est une instance du niveau sup6rieur (Fig. 10).
M6ta-m6ta..............................................m°d.e[]..MOF ........................................... , ~
ModUles UML
FIG.
10.
--
......
Interfaces IDL
: ~ ,
,
~
N i v e a u x de m 6 t a - m o d 6 1 i s a t i o n .
Meta-modeling levels. 24/51
ANN. TI~LI~COMMUN.,58, n ° 1-2, 2003
32
c. MORLEY -- LES OUTILS DU COMMERCE ELECTRONIQUE
En conclusion, UML peut &re considErE comme le langage de modElisation de rEfErence dans le cadre du d6veloppement d'applications de e-commerce. I1 permet en effet de reprEsenter ~ plusieurs niveaux et avec des preoccupations trEs diverses. I1 apporte une aide dans la construction des processus d'Echange, intra et inter-organisationnel, dans la formalisation de la logique metier et la definition des ElEments d'une application Web, pour les parties frontoffice des applications e-commerce, ainsi que dans la construction d'une solution d'intEgration depuis le niveau metier jusqu' aux interfaces entre composants.
III.2. Les technologies Web III.2.1. Principes g6n6raux des technologies Web
Le Web est ~ tiss6 >~entre les diffErents serveurs, routeurs et postes clients sur toute la surface du globe. Son dEveloppement a 6t6 assure au depart par une communautE de chercheurs comme un moyen commode de diffusion de l'information. Le support rEseau, appelE Internet, offre d'autres services, mais c'est surtout le Web qui en a fair exploser l'usage. Avec son expansion est nee la net-Economie et le e-commerce, qui a gEnErE des besoins nouveaux en termes de souplesse, de rEactivitE et d'intEgration avec le systEme d'information de l'entreprise. Les technologies que nous prEsentons ont rEpondu progressivement ~ces attentes 6. III.2.2. Le serveur Web I1 existe, sur Intemet, un grand nombre de serveurs proposant des documents multim6dias, c'est-h-dire composes de texte, images, sons, animations... Ces documents, appelEs pages Web, sont visualisEs sur le poste client grfice ~ une application appelEe navigateur (browser). Une notation permet de specifier l'endroit, ainsi que le protocole nEcessaire pour trouver les infonnations stock6es sous forme numErique et accessibles via Internet : en effet, toute ressource est identifiEe de faqon unique par son ~, son URI (Uniform
Resource Identifier) 7 Un serveur Web, dans sa version de base, doit dElivrer le document demand6 par l'utilisateur sous la forme d'un ou plusieurs fichiers, charge b, l'application de l'utilisateur de prEsenter ce fichier, en gEnEral sous forme graphique. La figure 11 montre les requ&es EchangEes entre le navigateur client et le serveur par le protocole HarP. Les requStes et rEponses du protocole HTTP sont des lignes de texte ASCII, qui commence par une commande pouvant &re notamment une demande de contenu, c'est-~tdire un fichier ou un appel de programme (GET) OU d'ent~te de contenu (HEAD), un envoi de donnEes vers un programme de traitement (POST) oU un envoi de fichier (GET). La rEponse HTTP precise, le cas EchEant, le format s de fichier utilis6 dans le corps de la rEponse. L'un des formats (<< application >>) permet ainsi de dEclencher une application sur le poste client pour afficher/traiter correctement le contenu fourni. Le format MIME le plus uti-
6. Pour un expose dEtaill6, notamment des syntaxes, voir [Musciano, 20011. 7. Dans le cas particulier d'une page Web, on parle d'URL (Uniform Resource Location). 8. Le format est spfcifi6 par un des codes MIME(Multipurpose lnternet Mail Extensions), h l'origine conqus pour le courtier 61ectronique. ANN. TI~LI~COMMUN.,58, n ° 1-2, 2003
25/51
C . M O R L E Y -- L E S O U T I L S D U C O M M E R C E
Requ6te HTTP • GET, HEAD .... + donn@es optionnelles
Navigateur client exemples: Netscape, Opera, Internet Explorer
33
E,L E C T R O N I Q U E
Reponse(s) HTTP
I
l [ ¢"1
Serveur Web Exemples:
apache, roxen IIS
FIG. 11. - - Schdma de fonctionnement de HTTP.
HTTPdynamic model.
lis6 sur le Web est le langage de balisage HTML(HyperText Markup Language) qui permet de d6finir l'habillage d'un document, c'est-h-dire la fa~on dont il doit ~tre affich4 par un navigateur. En effet, une page 6crite en HTML comporte non seulement du texte, mais aussi des codes - ou balises - permettant de modifier l'affichage de ce texte, ~t savoir sa forme, sa taille, sa couleur. HTML permet 6galement d'inclure des images, du son, des animations ou des vid6os. HTML n'est pas un langage de programmation, car il ne comporte ni variables, ni boucles, ni expressions conditionnelles. Cependant, certaines balises sont des r6f6rences ~ cliquables >, h d'autres documents : on peut ainsi composer des formulaires ~t remplir par l'utilisateur et comportant un bouton de soumission dont l'activation entraine une nouvelle requite HTTP(de type GET OU POST) vers un serveur Web. III.2.3. Des sites Web dynamiques
En dehors des formulaires, HTMLne permet pas d'afficher un contenu qui soit fonction du contexte. Les pages sont dites statiques, car il faut les recomposer si le contenu diff6re. Les applications de e-commerce ont un besoin croissant de contenu dynamique, non seulement pour offrir une personnalisation, par exemple en fonction des r6ponses ~ un formulaire, mais surtout parce que les transactions d'dchange conduisent le vendeur ~ utiliser de faqon intensive ses bases de donndes (produits, services, paiement, client...). La gestion de ~ session client >>par le serveur apporte un premier niveau r6ponse au problame de la personnalisation. Le besoin d'intdgration entre sites web et bases de donn6es a donn6 lieu ~t des technologies ,, web-traitement de donndes >>. La gestion des sessions La gestion des dialogues entre un navigateur client et un serveur Web ne comporte aucune m6morisation des 6tats pr6c6dents, ce qui emp~che notamment d'adaptater des propositions commerciales ~ l'historique des parcours du client. Pour r6pondre h ce probl6me, il faut disposer d'une notion de session, qui peut ~tre raise en oeuvre de deux fa9ons. La premi6re s'appuie sur des champs d'information cach6s au sein de formulaires HTML. Cette technique est lourde, car les informations d6crivant les choix d'un client doivent ~tre r6cup6r4es et r66mises de fonnulaire en formulaire - ce qui complexifie la r6daction des formulaires. La socidt6 Netscape a invent6 une autre technique : lors de la premi6re visite d'un client, le serveur envoie darts son ent6te de r6ponse un ensemble d'informations sur le client, appel6 26/51
ANN. Tt~Lt;COMMUN.,58, n° 1-2, 2003
34
c. MORLEY- LES OUTILSDU COMMERCEI~LECTRONIQUE
cookie (ou t6moin), qui seront stock6es sur la machine du client 9. Un cookie peut porter des param6tres, par exemple, la date d'expiration du cookie, le domaine de fftJRL dans lequel le cookie est valide ou l'exigence de s6curit6 pour ne valider un cookie que si la transaction est s6curis6e. A chaque fois que le navigateur client visite une tJl~a~correspondant aux contraintes exprim6es par les param6tres (domaine, chemin, s6curit6), le cookie sera r66mis par le navigateur du client dans l'entEte de ses requ&es HTTP. Les technologies permettant d'int6grer un traitement de base de donn6es dans une application web peuvent ~tre mises en oeuvre soit du c6t6 du poste client, soit du c6t6 du serveur. De plus, on peut les classer (figure 12) [Morrison, 2002] selon que le langage propos6 est compil6 ou interpr6t6, en distinguant les langages qui ne peuvent pas interagir directement avec une base de donn6es (les scripts c6t6 client) : ~- Les technologies cot6 client Les langages de script, qui s'ex6cutent sur le poste client, ne permettent pas d'interagir directement avec une base de donn6es. Ils sont donc principalement utilis6s pour un premier niveau de validation des donn6es saisies avant envoi vers le serveur. Une applet l° Java est un programme 6crit en Java 11, qui est d~clench6 par la pr6sence d'une balise particuli~re dans une page HTML..~ la reconnaissance d'une applet, le navigateur client effectue une nouvelle connexion vers le serveur Web pour chercher les classes Java n6cessaires. L'applet s'ex6cute apr6s chargement en m6moire, sur le poste client, de la machine virtuelle Java. Les applets Java permettent notamment de construire des animations graphiques interactives. Toutefois, les sites h vocation commerciale en limitent l'usage, car
Technologies Web/Traitement de donn6es
Traitement c6t6 serveur
~1
Programmes compil6s
Langages embarqu6s
~
Programmes CGI SeJwlets Java - ASP.NET (modklecompilk)
l
-JavaScript
Traitement c6t6 client
Scripts c6t6 client
I
~__
- VBScript....
~-PHP -ASP.NET (modg'le interprkt~ - Java applets--Java Serveur Pages -Javascript Server
Programmes compil6s ~ sur le poste client
FIG. 12. - - Classement des technologies Web - Traitement de donn6es. Web technologies classification : Data processing.
9. Les cookies ne doivent pas ~tre confondues avec les traces de passages des internautes sur les serveurs Web, qui sont m6morisEes sur les serveurs, et alimentent 6ventuellement un data webhouse (§11.5). 9. Les cookies ne doivent pas Etre confondues avec les traces de passages des internautes sur les serveurs Web, qui sont m6moris6es sur les serveurs, et alimentent 6ventuellement un data webhouse (§II.5). 10. Litt6ralement : petite application. 11. Ce langage est ind6pendant de la plate-forme sur laquelle il s'ex6cute. Cependant, l'implantation de l'environnement Java selon le navigateur (ou la version du navigateur) peut varier, ce qui entra]ne des diff6rences h l'ex6cution de l'applet.
ANN. TI~LI~COMMUN.,58, n ° 1-2, 2003
27/51
C.
35
MORLEY - - LES OUTILS DU COMMERCE I~LECTRONIQUE
elles supposent une capacitE de calcul suffisante pour poste client. Les technologies c6tE serveur prEsentent l'avantage majeur de lever l'hypothhse de la puissance de la machine client. D Les technologies cote serveur Un p r o g r a m m e cGI (Common Gateway Interface) est un programme executable, rEalisE dans un langage de programmation quelconque 12, et qui respecte le protocole coI d'interface avec un serveur Web. Ces specifications comportent notamment des conventions de communication entre un programme et le serveur Web. Ainsi, en ce qui concerne la sortie, c'est-hdire le rEsultat produit par l'exEcution du programme CGk deux scenarios sont possibles (Fig. 13) : 1. le rEsultat du CGI est analyse par le serveur Web qui rEpond au navigateur du poste client (Parsed Header Output : sortie avec entEte analysEe/modifiEe) ; 2. le CGI rEpond directement au navigateur client (Non Parsed Header Output).
Serveur Web
Navigateur
,"
b th' i
Non Parsed Header Output FIG. 13. - -
SchEma d'interaction Serveur Web - CGl.
Web Server CGIinteraction model.
Les programmes CGI permettent de crEer des pages HTML dynamiquement ou de traiter des formulaires en s'appuyant sur des bases de donnEes... Cependant, cette technologie est consommatrice de ressources serveur, car chaque formulaire requ dEclenche sa propre instance du programme de service. Les technologies J a v a S e r v l e t s et ASP,NET ont toutefois rEsolu ce probl6me. Du point de vue de la sEcuritE des systEmes, les programmes CGI s'exEcutent en gEnEral sur le mEme systbme d'exploitation que le serveur Web et un soin particulier doit 4tre porte h leur conception pour ne pas laisser la possibilitE ~t des hackers real intenfonnEs de pervertir leurs fonctions, c'est-~-dire de faire exEcuter par le CGI un code quelconque. Les l a n g a g e s << e m b a r q u ~ s >> dans une page HTML sont des langages de script ( P H P , ASP.NET13, JSP, Javascript Server...) qui permettent d'insErer du code dans une page HTML. Les scripts sont exEcutEs sur le serveur Web avant l'envoi de la page HTML de rEponse vers le navigateur du poste client. Par exemple, le script peut contenir des requites SQL pour interro-
12. On parle paffois de scripts ccl, car le langage PERL,langage de script, fut longtemps le langage de predilection des programmes COL 13. ASP.NETpermet de choisir entre le mode compile et le mode embarquE. 28/51
ANN. TI~LI~COMMUN.,58,
n° 1-2, 2003
36
c . MORLEY -- LES OUTILS DU COMMERCE I~LECTRONIQUE
ger une base de donn6es. De par la facilit6 de description des interactions avec le serveur Web, les langages embarqufs facilitent la programmation et la maintenance. Le fonctionnement HTML-PHP-SQLest repr6sent6 ~ la figure 14 : Dans ce d6roulement, plusieurs applications de finalit6 diff6rente sont ex6cut6es successivement : serveur Web, interpr6teur r,Hr,, base de donn6es. Ce principe peut ~tre g6n6ralis6 en une architecture dite multi-niveaux (multi-tiers), qui structure l'ensemble des interactions entre plusieurs applications, interfac6es entre elles, jusqu'?t la pr6sentation au client (Fig. 15). L'architecture ~ trois tiers >>, fr6quemment 6voqu6e, est la r6duction de cette architecture ~t trois niveaux : niveau pr6sentation (au niveau du poste client), niveau m6tier (dit aussi application-m6tier) et niveau donn6es. En conclusion sur les technologies Web, le langage HTMLpar sa simplicit6 a jou6 un rSle majeur dans la prolif6ration des sites Internet. Les techniques de gestion dynamique des
i
~:
navigateur
ServeurWeb (HTTP)
Interpr~teur(parser) PHP ou ASP ou...
:......................................................................................................................................................
~.-
i
--> Requite SQL
Page HTML+ script PageHTML FIG. 14. - -
GB
~
.
Au besoin
Tablede resultats
Sch6ma de fonctionnement des langages ~ embarqu6s >>.
Dynamic model for embarked langages.
:
f
APPLET~
RMI
/
/ Serveur WEB + PHP + ASP + JSP + CGI
+'"
FIG. 15.
Donn~es
M6tier / Applications
Presentation i
-
-
~SQLcN etl///
SGBD
/
Sch6ma g6n6ral d'une architecture multi-niveau (<~multitiers >>).
Multitiers general architecture. ANN.TELECOMMUN.,58, n° 1-2, 2003
29/51
C. MORLEY -- LES OUT1LS DU COMMERCE I~LECTRONIQUE
37
pages ont apport6 une grande richesse fonctionnelle. L'dvolution des technologies web/base de donnees se poursuit dans le cadre de la classification presentde. HTML presente toutefois des limites qui, ajoutees au besoin de faire dialoguer des applications informatiques heterog~nes, ont conduit au developpement de XML
III.3. Les technologies
X M L 14
111.3.1. Propridt6s g6n~rales de XML
Le code source d'un document HTML ne permet pas de distinguer ce qui relive du contenu et ce qui traite de la pr6sentation. De plus, les changements de pr6sentation selon le poste client ne sont pas facilement gerables : ainsi, un site Web doit-il ~tre recon~u s'il est destine h un mobile WAP. Par ailleurs, le partage d'informations entre applications, voire entre entreprises, a pris une importance croissante. Pour pouvoir realiser cette integration, on a donc cherch6 ~t definir un format d'echange qui soit facile h implementer, utilisable par tousles programmes informatiques et evolutif. Pour repondre hce double besoin, le w3c (World Wide Web Consortium) a decide de revenir ~t la source originale de HTML -- SGML, Standard Generalized Markup Language ~5 - pour developper un langage de balisage aussi facile ~t utiliser que HTML et d'une fichesse comparable ~ celle de SGML. Le resultat est le langage XML (eXtensible Markup Language, langage de balises extensible), qui permet de distinguer contenu et presentation, qui facilite des presentations differenciees et qui offre un moyen de creer des passerelles entre applications informatiques 16. Comme SGML, XML est un metalangage de balisage, c'est-~t-dire un langage de description d'autres langages. I1 permet de definir autant de langages de balises que de besoin. La figure 16 montre des langages heritant les uns de la syntaxe de SGML OH de celle de XML. Par exemple, un document MathML est un document XML; un document HTMLest un document SGML, mais pas un document XML. Par ailleurs, au-del~t du langage, le terme XML recouvre aujourd'hui un ensemble de technologies complementaires, que nous 6voquerons ci-apres. XML a 6te con~u dans un esprit de simplicit6 : aussi bien dans l'61aboration de la specification technique que dans les principes de gestion de documents (creation, transmission et partage, analyse et traitement). I1 repose sur deux idees majeures : separer les donnees de leur presentation (affichage, impression, etc.) et atre un format non proprietaire, donc non soumis ~ des modifications arbitraires 17. La lisibilit6 des documents est obtenue par l'utilisation d'un format texte, simplement structure et delimit6 par des balises. Cependant, ils sont plus volumineux que leurs equivalents binaires. Ce probleme n ' a pas et6 jug6 primordial, car la capacit6 des disques durs augmente tr~s rapidement et surtout les techniques de compression de donnees sont tres efficaces
14. Pour une presentation detaillee, voir [Turner, 2002] et [Michard, 2001 ]. 15. SGMI, est un langage de balise generalis6 et normalis6 (norme ISO 8879). 16. Le developpement de XML a commence en 1996, mais n'est une technologie enti~rement nouvelle, puisqu'elle beneficie de plus de 15 ans de travail sur SGML. 17. Tels [es formats word, par exemple. 30/51
ANN. TflLI~COMMUN., 58, n ° 1-2, 2003
38
c. MORLEY - LES OUTILS DU COMMERCE I~LECTRONIQUE
MathML
HTML
ATA Airline Transport Association
NewsML
[
WML, WirelessMarkup Language
FIG. 16. - - Distinction entre technologies XMLet HTML. Distinction between XML and HTML technologies.
sur les documents XML. Apr~s compression, les documents sont souvent plus petits que leurs concurrents binaires. Cependant, le temps de calcul associ4 aux traitements interm6diaires peut ~tre important : chaque application a besoin d'un traitant XML charg6 d'analyser (et 6ventuellement ddcompresser, traduire) les documents XML, cela n6cessite une utilisation importante des ressources syst~me (m6moire, disques durs, processeurs)... III.3.2. Caract4ristiques d'un document XML
Un document XML est un ensemble de fichiers textes - souvent un seul - comportant des parties constantes et des parties variables, et qui contiennent ~ la lois des balises et du contenu. Les balises (par exemple ) d61imitent une structure logique arborescente. Contrairement ~ HTML, le jeu de balises n'est pas fix6, mais adaptable au× divers besoins et h l'information ~ stocker, ce qui explique la polyvalence de ×ML. Le contenu du document correspond ~ des donn6es. En effet, XML peut ~tre consid6r6 comme un format de fichier permettant de stocker/repr6senter des donn6es de fa~on ind6pendante des applications qui les utilisent. Un document XML est dit <~bien form6 >>si la synta×e utilis6e pour le composer est rigoureuse. Un document XML bien form~ peut ~tre repr6sent6 de fa~on graphique, 6ventuellement par un diagramme de classes ou un diagramme d'objets UML. Les balises peuvent &re imbriqu6es, ~ condition qu'il n ' y ait qu'une seule racine et que l'imbrication soit logique. EnsuRe, les balises peuvent avoir a p r i o r i un hombre quelconque d'attributs. Un document XML est une sorte de base de donn6es hi6rarchique. L'int&~t majeur de XML est de fournir une structure ouverte et mall6able, facilitant le traitement de l'information. Pour cela, la description d ' u n document destin6 ~ une chaine de traitement - sa grammaire - est d6finie par un <ind6pendant du document XML, dont il existe deux formalismes : les DTD et XML Sch6ma. Un document XML est dit << valide ~ s'il est associ6 h u n sch6ma et qu'il respecte les contraintes qui y sont exprim6es.
ANN. TI~LI~COMMUN.,58,
n° 1-2, 2003
31/51
39
C. MORLEY -- LES OUTILS DU COMMERCE I~LECTRONIQUE
III.3.3. Les sch6mas de d o c u m e n t s
III.3.3.1. Les DTO Une DTD (Document Type Definition/Dgfinition de type de document) est une description formelle de la syntaxe (grammaire) que doit suivre un type particulier de document XML. I1 d6crit les noms de balises et les attributs utilisrs, ainsi que leurs limites d'utilisation. Aprrs avoir 6crit une DTD, il faut faire le lien entre les deux fichiers, par exemple en indiquant la rrfrrence du fichier DTD au drbut du fichier XML, OU bien en indiquant une URL contenant la description de la drfinition du type de document. Ceci permettra a un analyseur XML (XMLprocessor) de lire des documents XML dont il ne conna~t pas a priori la grammaire. L'analyseur est une application interface qui utilise les donn6es et les informations contenues dans le document. Les DTD offrent de nombreuses possibilitrs, mais prrsentent des limites. En particulier, l'absence de typage prdcis des donnres (seul le type PCDATAest disponible : cha~ne de caract~res) peut s'avdrer g~nant. De plus, la syntaxe utilisre pour la rrdaction d'une DTD ne respecte pas la sp6cification des documents XML. C'est pourquoi XML Schdma a 6t6 con~u par le w3c. III.3.3.2. XMLSchrma XML S c h r m a permet de ddcrire la structure d ' u n document de faqon plus riche qu'avec une DTD, par l'identification de types de donnres et la possibilit6 de d6crire des hidrarchies entre les types de donndes. On peut ainsi drfinir des classes d'instances d ' u n document XML. On peut 6galement ddfinir des contraintes sur les documents, permettant une validation automatique. Les schrmas sont eux-mame des documents XML. Un exemple d'application est donn6 dans le contexte des marchds 61ectroniques B-to-B par [Str6bel, 2002] : la drfinition des termes de l'objet des ndgociations pouvant prendre des formes tr~s varires, on peut envisager que, prralablement a un ensemble de nrgociations, les parties drfinissent en temps rdel les termes pertinents pour drcrire l'offre. Cette drfinition est guidre par une ontotogie, reprrsentre avec XML Schdma grace ~ la possibilit6 de hirrarchiser les concepts. L'outil propos6 peut ensuite gdndrer des documents XML qui formeront le cadre de n6gociation. Dans l'ensemble des technologies XML, il existe d'autres 616ments fondamentaux. XSL est un de ceux-l~. III.3.4. XSL XSL (eXtensible Stylesheet Language) vise ?a simplifier les transformations successives des diffrrents documents XML lors les interactions entre applications. C'est un langage de description des feuilles de style rrgissant les rrgles de prrsentation des 616ments d'un document XML. I1 propose une syntaxe pour grrer deux types de traitements (mixables) : la transformation et l'interprrtation. • XSLTest un langage de programmation, qui permet de grrer la transformation d'une partie d'un document XML en un autre document (XML, HTML...) (Fig. 17). XSLT est Ii6 h XML Path Language (XPath), langage d'extraction simple d'information d ' u n document XML xPath est utilis6 aussi par xr,ointer pour 6tendre la notion de rrfrrence externe ~ des parties d'autres documents. 32/51
ANN. TI~L[~COMMUN., 58,
n° 1-2, 2003
40
c. MORLEY - LES OUTILS DU COMMERCE f~LECTRONIQUE
(DTD ou XML Sch6ma Sch6ma)
Autre document XML ;
.
~
~
S
L
T
~ Document HTML
Document XML ]
Document PDF
FIG. 17. - - Fonctionnement g6n6rique de XSLT avec quelques exemples de production.
Generic model of XSLTwith production examples.
• XSL-FOg6re l'interpr6tation du document r6sultant de la transformation, pour produire des objets dits ~ de formatage ~ (Formating Objects), en vue d'une impression, d'une visualisation 6cran, de l'6mission d'un son... Par sa richesse, xsL peut entrainer des temps de calcul importants. C'est pourquoi, il n'est pas toujours recommand6, en particulier pour transformer des fichiers de grande taille (plusieurs m6gaoctets) ou pour traduire un flux continu de donn6es ~ traiter ~ la vol6e. XML ne remplace ni SGML,ni HTML.SGMLcontinue ~ &re utilis6 dans toute sa puissance par certaines applications qui ne pourraient se contenter de XMI.. HTMLest adapt6 h la repr6sentation des documents multim6dias, ce qui lui conserve une utilisation importante. De plus, la traduction en HTMLd'un document XML pour en faire une page Web, affichable par les navigateurs les plus simples, est ais6e. En supposant r6solu le probl~me de la coh6rence sEmantique et structurelle, XMLpermet de d6finir une vue int6gr6e ?apartir d'un ensemble de sources h6t6rog6nes par l'utilisation conjugu6e du module de donn6es XML comme mod61e commun et d'un langage de requ&es pour XML18 [Bellahs6ne, 2001]. Probablement que le second objectif assign6 h XML, le partage d'informations entre applications informatiques h6t6rog6nes, correspondra a 1' avenir ~ l'utilisation majeure du langage, en particulier dans le cas du e-commerce ota la consolidation de donn6es entre partenaires est cruciale. Les 6diteurs d'ERP (SAP, PeopleSoft, Oracle) ont fait 6voluer leurs produits pour adopter XML comme format d'6change ?~ t o u s l e s points d'interface. ,~ terme, il n'est pas impossible que les donn6es op6rationnelles soient stock6es directement en XML Aujourd'hui, dans les syst~mes de e-commerce, la plupart des informations op6rationnelles sont stock6es dans des bases de donn6es relationnelles. Cependant, en 61aborant un m6ta-mod61e de leur structure, par exemple par un diagramme de classes UML ensuite traduit en XML, on peut utiliser un convertisseur qui transforme automatiquement les donn6es en format XML, ce qui permet aussi bien leur publication que leur partage
18. Un groupe de travail du W3C, le XML Query Working Group, travaille h l'61aboration d'un langage de requ6te pour XML. ANN. TI~LI~COMMUN.,58, n ° 1-2, 2003
33/51
41
C. MORLEY - LES OUT|LS DU COMMERCE I~LECTRONIQUE
avec des partenaires, par exemple dans le cas d'une Supply Chain [Chan, 2002]. Pour encourager l'adoption de XML dans le cadre du B-to-B, Microsoft a propos6 en 1999 une plate-forme, BizTalk, inddpendante de tout langage et de tout syst~me d'exploitation, permettant a toute application d'un partenaire d'envoyer et de retirer des donn6es en XML [Yen, 2002a]. Nous allons, dans la troisi6me partie, replacer la question de l'int6gration des donn6es dans la probl6matique plus g6n&ale de l'architecture intra et inter-organisationnelle.
IV. DES OUTILS POUR UNE ARCHITECTURE INTI~GRI~E
La question de l'int6gration a 6t6 plusieurs fois 6voqu6e. Dans la premiere partie, le nombre et de la diversit6 de solutions applicatives, ainsi que le besoin de communication entre les syst6mes d'information d'acteurs partenaires, ont fait apparaltre l'int6gration comme un probl6me, voire une limite h la raise en place d'outils de e-commerce. Dans la seconde partie, une rdponse partielle a 6t6 apport6e par le d6veloppement du langage XML, notamment en permettant de partager des structures de donndes entre partenaires. Le probl6me de l'int6gration des applications va maintenant ~tre abord6 sous l'angle de l'architecture applicative. Apr6s avoir pos6 le probl6me dans la section IV. 1, on introduit dans la section IV.2 la vision actuelle de l'int6gration au niveau entreprise, sous forme d'un module abstrait. La section IV.3 prdsente les solutions existantes pour impl6menter ce mod61e abstrait. Nous terminons, dans la section IV.4, par les solutions sp6cifiques au ecommerce, et notamment la solution des services Web qui semble aujourd'hui la plus complete et la plus f6d6ratrice, ainsi que les solutions applicatives issues du monde de I'ED! (t~change de Donndes Informatisd).
IV.1. Le probl/~me de l'architecture En dehors des questions de s6curit6, l'architecture mat6rielle et applicative pose des problbmes diff6rents selon que 1'on est dans un contexte d'6changes B-to-C ou d'6changes B-to-B. Dans le premier cas, le probl~me principal est celui du volume d'acc~s simultan6s au serveur. La r6ponse est apport6e par des architectures mat6rielles et logicielles de type grappe d'ordinateurs (ou ~ c l u s t e r ,~ ), ensemble de machines interconnect6es via des canaux d'acc~s rapide, dans lequel chaque ordinateur g6re un sous-ensemble des requites h traiter. Une telle architecture permet notamment de r6partir uniform6ment la charge entre les machines. Si le nombre d'utilisateurs augmente, il suffit d'augmenter le hombre de machines dans la grappe 19 Dans les 6changes B-to-B, le probl~me majeur est celui de l'int6gration de syst6mes h6t6rog6nes appartenant h des organisations partenaires. Ce probl6me peut se poser d6jh au sein
19. Les moteursde recherche h succ~scommeGoogle sont de parfaits exemplesde ces solutions : Googledispose d'environ 10000 machines en grappe. 34/51
ANN. TI~LI~COMMUN., 58,
n° 1-2, 2003
42
c. MORLEY -- LES OUTILS DU COMMERCE IELECTRONIQUE
du systEme d'information de chaque entreprise, dans la mesure ofa il est compose d'applications issues de fournisseurs diffErents, mais devant communiquer. Une application se construit gEnEralement par assemblage de briques logicielles, souvent appelEes composants. A l'intErieur d'une mEme organisation, l'assemblage peut ~tre facilitE par l'utilisation d'un ERP ou bien d'architectures logicielles ~ composants comme .NET de Microsoft, Java/J2EE de Sun ou Corba de I'OMG. Ces solutions donnent une homogEnEitE plus ou moins forte ?a toutes les briques, ce qui facilite Evidemment leur assemblage. Dans les faits, il est rare qu'une telle homogEnEisation soit totale. Par exemple, m~me si l'on dispose d'un ERP, certaines briques devront ~tre rajoutEes pour completer la couverture de I'ERP. Ces probl~mes d'intEgration ont longtemps EtE rEsolus de maniEre ad hoc, en dEveloppant des convertisseurs ou passerelles spEcifiques, ce qui est cofiteux lorsque le nombre de briques ~t intEgrer est ElevE. C'est pourquoi l'on se tourne aujourd'hui vers des solutions gEnEriques, dont les plus abouties s'appellent des EAI (Entreprise Application Integration). Ces outils utilisent l'abstraction d'un bus logiciel permettant l'Echange de flux d'informations entre les applications. Tousles flux y sont reprEsentEs avec le m~me formalisme, qui est souvent XML.
IV.2. Le module abstrait d'une architecture d'int6gration 2° IV.2.1. Presentation du m o d ~ | e EA!
Une architecture d'intEgration est organisEe en trois couches logicielles (Fig. 18). Au plus bas niveau, on trouve les fonctions de communication entre applications, basEes sur l'Echange de flux. Chaque flux doit ensuite ~tre adaptE ~ l'application destinatrice. La troisiEme couche sert h gErer l'encha~nement des operations h effectuer en reaction 5 l'arrivEe d'un flux.
Automatisation des processus Adaptation de l'information Communication et connectivit6
FIG. 18. - -
Les trois n i v e a u x d ' u n EAI.
The three tiers o f an EAI.
Une architecture EAI remplit quatre grandes fonctions (Fig. 19) : • La communication, car les deux applications sont gEnEralement sur des machines diffErentes qui peuvent &re EloignEes gEographiquement; • La transformation, car les flux gEnErEs par une application sont gEnEralement dans un format different de ceux attendus par l'autre application ; • Le courtage, car l'application Emettrice ne connait pas forcEment l'application destinatrice;
20. Pour une description dEtaillEe, voir [Manouvier, 2001 ]. ANN. TI~LI~COMMUN., 58, n ° 1-2, 2003
35/51
43
C. MORLEY -- LES OUTILS DU COMMERCE I~LECTRONIQUE
Application 2 I
Connecteur
I Connecteur
Com.twani¢
Tran
FIG. 19.
-
-
ion
_
. Co
Le module abstrait d'une architecture EAI.
Abstract model o f an EAI architecture.
• La connectivit6 c'est-h-dire l'interfa~age via des connecteurs, car on veut pr6server l'autonomie des applications qui fonctionnent 6galement en dehors de l'architecture d'int6gration. Les fonctions de c o m m u n i c a t i o n et de c o n n e c t i v i t 6 sont fortement d6pendantes du mod61e de communication ~ mettre en place entre les applications. Classiquement on distingue quatre dimensions dans un mod61e de communication : le temps, les destinataires, la qualit6 de service et la gestion d'un 6tat. - Le temps : en mode synchrone, l'6metteur est bloqu6 apr6s 6mission de son message rant que la r6ponse ne lui est pas renvoy6e, alors qu'en mode asynchrone il peut continuer son traitement. De plus, en mode synchrone, 6metteur et destinataire doivent atre connect6s en marne temps, ce qui n'est pas n6cessaire en mode asynchrone, - Les destinataires : la communication peut 4tre mono-destinataire ou multi-destinataire. - La qualit6 de service : cette notion recouvre les exigences portant sur l'envoi de messages. Par exemple, on peut demander un niveau 61ev6 de fiabilit6, c'est-~-dire avoir la garantie que le message sera d61ivr6 ou bien exiger que l'envoi d'un ensemble de messages soit atomique. - La gestion d'un 6tat : en mode ~ sans 6tat ~, deux envois successifs sont ind6pendants alors qu'en mode ~ avec 6tat ~,, deux envois successifs peuvent partager le m6me contexte. Tout module de communication peut se d6finir par rapport h ces quatre dimensions. Par exemple le mod61e de communication support6 par H~P est de type synchrone, mono-destinataire, fiable et sans 6tat. La fonction de courtage permet de d6terminer quels sont les destinataires d'un flux. Le courtage peut Otre d6crit explicitement du c6t6 de l'6metteur ou bien d6termin6 dynamiquement par le syst6me d'EAI : la seconde solution assure une 6volutivit6 plus grande du systhme. Pour qu'un flux d'information envoy6 par une application puisse 4tre trait6 par une autre application, il faut non seulement qu'il lui parvienne, ce qui est le r61e de la communication et 36/51
ANN. TI~LI~COMMUN., 58,
n° 1-2, 2003
44
C. MORLEY -- LES OUTILS DU COMMERCE I~LECTRONIQUE
du courtage, mais aussi qu'il soit exprim6 dans un formalisme reconnu par l'application r6ceptrice. C'est pourquoi les syst6mes d'EAI offrent des fonctions de transformation de flux. L'architecture d'un EAI respecte deux contraintes. D'une part, la preservation de l'existant : on s'interdit de r66crire tout ou partie des applications ~t int6grer. D'autre part, la s6paration entre ce qui rel6ve de l'applicatif, et qui doit donc rester dans les applications, et ce qui rel6ve de l'int6gration et qui doit donc rester dans l'architecture d'int6gration. Par exemple, il n'est pas souhaitable de mettre dans le code applicatif, l'adresse du destinataire d'un flux. Les connecteurs sont sp6cifiques d'une application et doivent ~tre r66crits chaque fois qu'une application nouvelle rentre dans le systbme a int6grer. Cependant, les vendeurs de solutions d'EAI proposent des connecteurs standards pour les principaux outils du march& par exemple de type ERP. Cette architecture d'int6gration peut ~tre rEalis6e de mani6re centralis6e, de type hub and spoke (Fig.20a) ou d6centralis6e, de type architecture bus (Fig.2Ob). Le mode centralis6 facilite le raccordement de nouvelles applications, puisqu'il suffit de d6velopper un adaptateur sp6cifique. Par contre, la machine qui h6berge l'architecture d'int6gration devient le goulot d'6tranglement du systbme. L'architecture d6centralis6e 6quilibre mieux la charge, mais n6cessite de distribuer les fonctions de l'architecture d'int6gration entre les diff6rentes machines. Nous allons d6tailler les fonctions de transformation et de courtage.
(a)
~
(b)
Application 3]
FIG. 20. - - Architecture centralis6e (a) et architecture d6centralis6e (b).
Centralized architecture (a) and decentralized architecture (b).
IV.2.2. Les fonctions de transformation et de courtage IV.2.2.1. La fonction de transformation
La transformation d'un flux de sortie d'une application en un flux d'entr6e d'une autre application porte ~ la fois sur des aspects syntaxiques, si le langage d'expression des flux n'est pas le mOme, et sur des aspects s6mantiques, si les concepts vOhicul6s dans le flux de sortie ne sont pas ceux attendus pour le flux d'entr6e. Au niveau syntaxique, on dispose d'outils permettant de simplifier le d6veloppement de traducteurs ; par contre, le niveau s6mantique est plus complexe. Dans le contexte du e-commerce, de nombreuses propositions ont ANY. TELI~COMMUN.,58, n ° 1-2, 2003
37/51
C. MORLEY - LES OUTILS DL/ COMMERCE I~,LECTRONIQUE
45
6t6 faites pour normaliser la syntaxe et la semantique des flux : par exemple, la norme EDIFACT specifie tr~s precisement ce qu'est une facture. • Transformation syntaxique L'ecriture de traducteur (wrapper) est une tfiche assez rEpEtitive, notamment lorsque le hombre de langages ~t traduire est eleve. Dans le contexte du e-commerce, la norme Emergent XML simplifie considerablement cette tfiche. En effet, si tousles flux sont structures en XML, il suffit d'ecrire des traducteurs transformant un flux conforme fi un certain type, exprim6 via une DTD on un schema XML, en un autre type. XML propose des langages pour faciliter l'ecriture de ces traducteurs et notamment xpath et XSLT. • Transformation sdmantique Une application de prise de commande d'une entreprise E1 doit s'interconnecter avec une application de traitement de commande d'une entreprise E2. Dans l'entreprise El, la prise de commande est directe et ne necessite pas de reconfirmation. Par contre pour E2, une prise de commande doit etre confirmde avant traitement. La transformation semantique doit, a partir du flux venant de E 1 reprdsentant une prise de commande, gendrer un flux fictif representant la confirmation de cette commande qui permettra ~ l'application d'E2 de la traiter. Pour etre capable de faire cette transformation de flux, le syst6me doit disposer de bases de connaissances indiquant l'ensemble des concepts manipules par les differentes applications, les relations sdmantiques entre ces concepts et les transformations a faire pour passer d'un concept h l'autre. Le travail de constitution de ces bases de connaissances est long et complexe et doit 8tre mis ~ jour chaque lois qu'une application appara~t ou disparait. Pour simplifier les problemes semantiques, les organismes de normalisation ont un r61e ~t jouer pour proposer des definitions de concepts qui puissent ~tre partagees par tous. 1V.2.2.2 L a fonction de c o u r t a g e
De maniere iddale, le courtage d'un flux doit se faire sans codage explicite du destinataire lors de la cr6ation du flux : l'6metteur se contente de definir declarativement le destinataire du flux et un composant logiciel - le courtier - transforme cette expression declarative en expression explicite. Un courtier peut ~tre soit decentralis6 au niveau de chaque 6metteur, soit centralis6. La version centralisee est plus facile ~t mettre en oeuvre, car chaque 6metteur se contente d'envoyer tous ses flux vers le courtier; par contre, ce dernier doit connaitre toute l'information ndcessaire au courtage. En mode decentralis6, l'information est plus localisde et on peut 6galement faire communiquer des courtiers entre eux. La plupart du temps, le mecanisme utilis6 pour passer d'une adresse declarative ~ une adresse physique repose sur le mecanisme du publish and subscribe. Ce dernier reprend l'idee des listes de diffusion de courtier 61ectronique (Fig. 21). Chaque application declare tous les 6venemeuts qu'elle peut produire (fleche 1). L'information est collectee dans un annuaire, le courtier. Celui-ci peut 6tre consult6 par routes les applications intdressees, qui choisissent les evenements auxquels elles souhaitent s'abonner (fleches 2). L'abonnement et le desabonnement sont dynamiques. Lorsque l'evenement se produit (fleche 3), l'annuaire le redirige (fleches 4) vers tous ceux qui y sont abonnes au moment de l'emission. Une autre approche est celle des courtiers qui suivent la norme Corba. Chaque objet serveur Corba est d6fini par un ensemble de couples attributs-valeurs qui sont stockes dans la base de donnees du courtier. Lorsqu'un objet client Corba a besoin d'un objet serveur spdci-
38/51
ANN. TI~LECOMMUN.,58, n ° l-2, 2003
c. MORLEY-- LESOUTILSDUCOMMERCEI~LECTRONIQUE
46
Application [ Emettrice I
1 (publish) ~ 1- 2 (suscribe) I /" , • , "--. ~.. /~nnualre / ~.. -- I _. I I . ~'. I cour/ler I ~ (~v~nem~t)l 3 [~v~nement) ~ ~.,,'~
~~1~
]
~
~v~_!me~s)fl~
.... ,~ppncatlon R&eptrice 1
v~nement)
] 2Lmt~cribe~2 (suscnbe)
oAppli - - c~ati R&eptrice 2
FIG.21. -- Principedu publish and subscribe. Publish and subscribe principle.
fique, il adresse une requ&e au courtier, qui lui renvoie alors l'ensemble des objets satisfaisant la requ&e. Comme il n'y a pas de schema prEdEfini pour dEcrire les objets stockEs, il est parfois difficile d'exprimer une requ&e de selection.
IV.2.3. L'int6gration des processus m6tiers Pour pouvoir int6grer des applications, il est parfois n6cessaire de coordonner des activit6s sous forme de processus m6tiers. Un processus m6tier peut se d6finir comme un ensemble de procedures ou d'activitEs reliEes, qui rEalisent ensemble un objectif metier, dans le contexte d'une structure organisationnelle dEfinissant les r61es et les relations. Ces processus vont &re modElisEs par des graphes d'activitEs reliEes par diffErentes relations (composition, alternative, iteration, parallElisation et rendez-vous) et temporisEs. Ces graphes sont ensuite exEcutEs par des moteurs de type workflow. La figure 22 illustre, avec un diagramme d'activitEs UML, un processus de prise de commande qui peut &re r6alisE entre diffErentes entries.
NP' Jf
Cr6ationcommande~V&ification validit6
onsultationstock~Cr6ation factur~ [non OK]
[non OK]
alcul commandealternative~
I
Affichage6tat)
~tat de la commande~,
~6servation produits~
FIG.22. -- Exemplede workflow. Workflowprocess example.
ANN.Tt~LI~COMMUN. 58,, n° 1-2,2003
39/51
C. MORLEY - LES OUT[LS DU COMMERCE I~LECTRON1QUE
47
Par exemple, on peut avoir un site Web marchand qui ne s'occupe que de la partie prise de c o m m a n d e e t un back-office dans une autre entitE qui va s'occuper de traiter la commande. Le traitement de la commande est un processus complexe qui va enchainer diffErentes activitEs avec deux alternatives liEes h la validitE ou non de la commande (v6rification que la commande porte sur des produits existants ou que le client est bien identifi6) et h la possibilitE de fournir la commande en fonction du stock. Ce processus produit un Etat global de traitement de la commande qui peut ~tre ensuite affichE au client. ll faut pouvoir spdcifier le comportement attendu pour une activitE en cas d'erreur dans une des procedures. Par exemple, que faire si la crdation de la facture 6choue ? Les transactions sont une solution possible "ace probl6me. Une transaction est un programme qui vErifie les propriEtEs ACID (Atomique, CohErent, IsolE et Durable). Ces propriEt6s sont particuli~rement importantes lorsque l'on manipule des informations persistantes. Dans un contexte d'activitEs, la notion de transaction ACID dolt ~tre Etendue pour prendre en compte des mod61es plus riches comme les transactions emboltEes - une transaction composde d'autres transactions, ce qui permet d'avoir un meilleur parallElisme ainsi que des procddures de reprise plus fines - et les transactions longues, composdes de transactions plus courtes avec des possibilitEs de compensation en cas d'dchec partiel. A. partir d'une description d'un processus m6tier, un syst6me d'intEgration va ~tre capable de gdrer automatiquement le courtage des flux et le dEclenchement des activit6s assocides. Les syst6mes de gestion du workflow sont mis en ~euvre soit avec une architecture centralisde (un serveur coordonne le dEroulement du processus), soit avec une architecture distribuEe oa le contr61e est assur6 successivement par chaque n~eud, h partir d'une feuille de route qui peut fitre dEcrite avec un langage proche d'XML [Kumar, 2002]. Par ailleurs, l'application du workflow au commerce 61ectronique B-to-B requiert une gestion dynamique de l'instance de processus, en fonction des situations et probl6mes rencontres, qui peut atre mise en ~euvre avec la technologie de collaboration multi-agent [Xu, 2002].
IV.3. Les solutions d'int~gration De nombreuses solutions techniques ont 6t6 proposdes pour r6soudre les problSmes d'int6gration ou d'interop6rabilit6 logicielle. Cinq d'entre elles ont un caract~re gdn6ral : le transfert de fichier, la duplication des donndes, les logiciels m6diateurs ou middleware orient6s message (M.O.M), les architectures h base de composants et les outils d'EAI. IV.3.1. L e t r a n s f e r t d e
fichiers
Le transfert de fichiers est le mode le plus ancien, mais aussi le plus rdpandu pour 6changer des flux d'informations entre applications. Les solutions les plus simples sont des implantations du protocole FTP (File Transfer Protocol, de I'IETF). On trouve surtout des moniteurs de transfert de fichiers qui permettent : - d'etre indiff6remment client ou serveur ; - de supporter plusieurs protocoles, notamment ceux de certains secteurs industriels tels PeSIT et ETEBACdans le monde bancaire ; - de faire de la compression de donndes ;
40/51
ANN. Tt~Lt~COMMUN.,58, n ° 1-2, 2003
48
c. MORLEY - LES OUTILS DU COMMERCE I~LECTRONIQUE
d'assurer la garantie de d61ivrance des informations ; - de d6finir des points de reprise afin d'6viter de devoir reprendre compl6tement un transfert qui a 6chou6 avant la fin ; - de faire des 6changes s6curis6s (authentification des partenaires, chiffrement des donn6es, non-r6pudiation des transferts...); - de journaliser et de planifier les 6changes ; - de g6rer des priofit6s ainsi que de faire de la redirection de fichiers (store and forward) ; - de lancer automatiquement des traitements de fin de transferts. Ces moniteurs, tr~s ufilis6s dans les grands secteurs industriels, sont assez lourds ~ mettre en eeuvre et dans un contexte EAI supportent real les fonctions de courtage et d'adaptation des flux. -
IV.3.2. L a d u p l i c a t i o n d e d o n n 6 e s ( d a t a r e p l i c a t i o n )
La plupart des syst6mes de gestion de bases de donn6es (Oracle, DB2 d'IBM,SqlServer de Microsoft) permettent de dupliquer des donn6es entre des bases distantes : on dispose alors de plusieurs copies de la m~me information. Une requite de s61ection exprim6e dans le langage SOL permet en g6n6ral de s61ectionner les donn6es ~ recopier. Les modes de duplication varient selon les op6rations possibles sur les diff6rentes copies et le mode de propagation des mises h jour d'une copie vers les autres : - En mode maitre - esclaves, une seule copie peut &re mise ~ jour, les autres ne sont que des copies de consultation. En mode sym6trique, routes les copies peuvent ~tre consult6es et modifi6es. Ce mode est plus fiche, mais plus compliqu6 ~ g6rer, notamment pour les conflits de propagation de raise h jour lorsque deux copies sont modifi6es simultan6ment : doit-on cumuler les deux raises h jour, en choisir une, refuser les deux mises h jour? - La propagation peut se faire en mode synchrone ou asynchrone. Dans le premier cas, toutes les copies doivent &re mises h jour en m6me temps, au cours de la m~me transaction. I1 faut alors utiliser un protocole de validation h deux phases, cofiteux en nombre de messages 6chang6s et qui ne supporte pas bien la montfe en charge et les grands r6seaux de type Internet. En mode asynchrone, les copies ne sont pas mises ~t jour simultan6ment. La propagation est fare, soit au fil de l'eau, en utilisant un support de communication fiable de type M.O.M, soit par recopie, totale ou partielle, effectu6e h des intervalles de temps fixes. Le cofit de propagation est plus faible que dans la solution pr6c6dente, mais il faut que 1' application tol6re les divergences momentan6es entre les contenus de copies. On peut 6galement rencontrer des probl~mes de coh6rence temporelle, en 6mission au fil de l'eau, car rien ne garantit que deux mises h jour effectu6es dans un certain ordre sur deux sites diff6rents, vont se propager en respectant cet ordre sur toutes les copies. Ces outils de duplication offrent une solution int6ressante pour le transport des flux, mais sont limit6s au niveau courtage et adaptation. Ils sont parfois restreints ~t la duplication entre bases de donn6es du m6me 6diteur. IV.3.3. L e s m . o . m ( M e s s a g e O r i e n t e d M i d d l e w a r e )
Les M.O.M (comme MQSeries d'IBM, MSMQ de Microsoft ou MessageQ de BEA)sont des logiciels interm6diaires qui permettent h des applications d'envoyer et de recevoir des messages en mode asynchrone. Le M.O.M stocke les messages de la file de sortie de l'6metteur et
ANN, TI~LI~COMMUN,,58,
n° 1-2, 2003
41/51
C. MORLEY - LES OUTILS DU COMMERCE E,LECTRONIQUE
49
les transporte vers la file d'entrde du r6cepteur : le stockage des messages sur un support de type fichier assure la fiabilit6 de la communication. La plupart du temps les M.O.M offrent des m6canismes de priorit6 (on peut r6ordonnancer sa file de messages en entr6e selon les crit6res que l'on veut), de qualit6 de service (garantie de ddlivrance du message au moins une fois ou bien exactement une lois) et de s6curit6 (authentification et chiffrement). Ces syst6mes sont simples h programmer, mais ils ne g~rent que des messages de taille limit6e : au-delh, il faut segmenter les messages 5 l'6mission et les reconstruire ~ la r6ception. La normalisation de ces systbmes n'est que partielle, m6me si des efforts out 6t6 faits, comme l'interface de programmation Java Messaging Service pour le langage Java. Les M.O.M modernes supportent 6galement l'6change de type publish and subscribe qui est extr~mement important darts la fonction de courtage des EAL IV.3.4.
Les architectures h base de composants
L'architecture Corba de I'OMG s'appuie sur un langage objet de description d'interfaces, qui permet de repr6senter de mani~re abstraite et homog6ne les composants ~ assembler. Selon ce mod61e, la communication entre objets est g6n6ralement synchrone et repose sur l'appel d'op6rations. Les appels sont transport6s par le bus logiciel Corba. La d6couverte d'objets Corba se fait via des services de recherche, le plus simple 6taut le nommage et le plus sophistiqu6 le courtage. Corba offre 6galement un ensemble de services syst6mes (transactions, s6curit6...), qui simplifient la tfiche de programmation. Les architectures .NET de Microsoft et J2EE/java de Sun s'imposent aujourd'hui face ~t Corba comme environnements de programmation d'applications r6parties. Elles offrent des fonctionnalit6s assez semblables, mais diff6rent selon le systbme d'exploitation utilis6 - plut6t Windows pour .NET, plut6t Unix pour Corba ou les deux pour J2EE - et les langages de programmation support6s - J2EE est mono-langage et les autres solutions multi-langages. Des implantations de Corba et du mod61e J2EE sont propos6es par de nombreux vendeurs, alors que .NET est seulement support6 par Microsoft. J 2 E E et .NET sont maintenant int6gr6s darts des environnements de d6veloppement logiciel comme FORTE, JBuilder ou Visual Studio.NET, ce qui simplifie grandement leur raise en oeuvre. Toutes ces solutions supportent un mod61e de composants logiciels qui facilite le d6ploiemerit, ainsi qu'une plus grande d6clarativit6 darts la mise en oeuvre de fonctions de base comme les transactions, la persistance des donn6es ou la s6curit6. Ces architectures sont largement r6pandues dans l'industrie et leur utilisation tend 5 se gdn6raliser. II faut rioter que J2EE et .NET sont les plates-formes techniques privil6gi6es aujourd'hui pour programmer les services Web, prdsentds ci-dessous (§ IV.4.1)..NET a 6t6 conqu d6s le d6part pour supporter SOAP et XML comme moyen de communication. Le support de XML et des services Web se fait en J2EE via des interfaces de programmation spdcifiques qui sont JAXP pour XML, JAX-RPC et JAXM pour SOAP et JAXR pour l'acc~s aux annuaires UDDI. IV.3.5. Les outils d'int~gration
Les outils d'int6gration (EAI) c o m m e Webmethods r6alisent les fonctionnalit6s d6crites dans le mod61e abstrait. La plupart d'entre eux s'appuient sur des technologies 6prouv6es. Certains peuvent 6tre consid6r6s comme des M.O.M 6tendus : ainsi, MQseries, l'outil d'mM, f6d~re un logiciel M.O.M et un logiciel de workflow existants. Ces outils sont r6cents et leur diffusion reste encore limit6e.
42/51
ANN. TELI~COMMUN., 58, n ° 1-2, 2003
50
C. MORLEY -- LES OUTILS DU COMMERCE [~LECTRONIQUE
Si l'on compare les diff6rentes solutions d'int6gration selon les caract6ristiques de communication, transformation et courtage (Fig. 23), on voit que les trois premi6res solutions mettent l'accent sur les aspects communication et courtage, et non sur les aspects transformation et processus m6tiers. Les architectures a objets r6partis de type Corba de I'OMGou Java de SUN permettent d'6crire des applications compos6es d'objets r6partis interagissant entre eux via des appels synchrones de type appel de proc6dure distante. Des possibilit6s d'appels asynchrones ainsi que d'invocations multi-destinataires existent, mais sont assez limitEes. Corba &ant multi-langages de programmation, il offre des fonctions de transformation syntaxique. Corba et Java supportent du courtage via un service de nommage qui n'oblige pas l'6metteur conna~tre explicitement l'adresse du destinataire. Les aspects transformations s6mantiques et processus m6tiers ne sont pas abord6s par Corba et Java. Seuls les EAI essayent de couvrir l'ensemble du spectre, avec des limitations du c6t6 des aspects s6mantiques. Les approches spEcialis6es, services Web et EDI, cherchent h d6passer ces limites.
Synchrone Mono/multi Qualit6 Asynchrone destinataire de service
l~tat
Courtage
Transf. Syntaxique
Transf. s6mantique
Processus m6tiers
S/AS
M
Oui
Oui
Store and forward
Non
Non
Non
S/AS
M
Oui
Oui
Nommage
Non
Non
Non
AS
M
Oui
Oui
Publish and subscribe
Non
Non
Non
S
m
Non
Non
Nommage
Oui
Non
Non
Java
S/AS
m
Oui
Non
Nommage
Non
Non
Non
EAI
AS
M
Oui
Oui
Publish and subscribe
Oui
Non
Oui
!Transfe~ fichiers Duplication BD M.O.M Corba
FIG. 23. - -
Comparaison entre les solutions d'int6gration.
A comparison of integration solutions.
IV.4. Les outils d'int6gration orient,s commerce ~lectronique zl Plusieurs normes 6mergentes s'int6ressent h l'interop6rabilit6 des applications dans un contexte e-commerce. D'un c6t6, on trouve les services Web qui sont l'6volution du mod61e de programmation Web; d'un autre c6t6, on trouve des normes venant de l'6volution de I'EDI vers le monde Internet, principalement ebxML et RosettaNet. IV.4.1. L e s s e r v i c e s W e b 22
La technologie Web classique a montr6 ses limites pour construire des applications r6parties qui soient bien int6gr6es et r6utilisables. Les portails Web, agr6geant un ensemble de 21. Pour une description d6taill6e, voir [Avignon, 2000] et [Serain, 2000]. 22. Pour une description d6taill6e, voir [Chauvet, 2002] et [Curbera, 2002]. ANN. TI~LI~COMMUN.,58, n ° 1-2, 2003
43/51
C. MORLEY -- LES OUTILS DU COMMERCE I),LECTRONIQUE
51
sources hdt6rogbnes, ne r6alisent qu'une intdgration limit6e, touchant essentiellement l'interface utilisateur. C'est pourquoi les 6diteurs de logiciels ont propos6 un module gEn6ral incluant les technologies majeures de l'Internet que sont le protocole HTTP et les langages HTML et XML. Les services Web peuvent fitre considdrds comme un EAI sp6cialis~ pour le monde Web (Fig. 24).
EAI
Services Web
Communication
SOAP
Transformation s6mantique Transformation syntaxique
WSDL, XSLT
Courtage
WSDL, UDDI
Processus metiers
BPML, WSFL, WSCL, XLANG
FIG. 24. - - Comparaison entre EAI et services Web.
EAI and Web services comparison.
Nous d6taillons maintenant les diff6rents services en commen~ant par la communication la description de services (WSDL), les annuaires de services (UDD0 et les processus m6tiers (BPML, WSFL, WSCL, XLANG). (SOAP),
IM4.1.1, La communication entre services Web
Elle est assur6e par un nouveau protocole appel6 SOAP (Simple Object Access Protocol). Les objectifs majeurs de SOAP sont de pouvoir supporter aussi bien l'appel asynchrone de type envoi de message ou l'appel synchrone de type appel de proc6dure distante. Le codage des informations est fair en XML, avec XNL Sch6ma comme mod61e de type associ6. Ce protocole peut &re ddploy6 au-dessus de plusieurs protocoles de transport (HTTP, SMTP, MQSeries), le protocole le plus utilis6 6rant HTTP, car extr~mement r6pandu et passant facilement les syst6mes de sdcurit6 comme les pare-feu. Les messages SOAP sont auto-descriptifs et ne ndcessitent pas d'informations compl6mentaires pour leur d6codage : c'est une diff6rence majeure par rapport aux protocoles plus classiques comme hop (Internet Inter ORB Protocol) de Corba par exemple. Ce choix conduit des messages de taille importante, car XML est assez verbeux. C'est pourquoi plusieurs algorithmes de compression, sp6cialisds pour XML, ont d6jh 6t6 propos6s. La d6finition d'une interaction SOAP sur HTTP peut par exemple correspondre hun appel de service distant (renseignement sur les horaires adriens). Tout message soaP est constitu6 d'un ent~te (~ header ~) et d'un corps (~ body ~,). L'ent~te contient des informations sur la provenance du message, par exemple l'authentification du client. Le corps d6crit le contenu du message. Les types des arguments sont d6crits en utilisant les sch6mas XML. Les informations de typage peuvent permettre au r6cepteur de transformer les cha~nes de caract~res XML dans les types attendus par le service. La r6ponse ta cette invocation de service est 6galement un message SOAP.
44/51
ANN. TI~LI~COMMUN.,58, n ° 1-2, 2003
52
c. MORLEY -- LES OUTILS DU COMMERCE I~LECTRONIQUE
IV.4.1.2. L a d e s c r i p t i o n de services W e b
Pour qu'un client puisse appeler un service de mani~re synchrone ou asynchrone, il a besoin de conna~tre non seulement l'interface de ce service, mais aussi les informations nEcessaires pour s'y connecter. Celles-ci sont dEcrites dans un langage appelE WSOL(Web Services Description Language), qui est lui-m6me dEcrit en XML. Une definition compl&e WSDLcomprend la definition abstraite du service - analogue ~ une description de type lI)L (Interface Description Language) dans Corba - et la definition dEpendante du protocole h utiliser pour appeler ce service, ce qui permet d'avoir plusieurs maniEres d'appeler un mEme service. Une description WSDLpermet aux utilisateurs et aux dEveloppeurs de conna]tre les services offerts. De plus, la partie liaison peut ~tre utilisEe pour gEnErer automatiquement le code correspondant h l'emballage et au dEballage des arguments lors d'un appel. IV.4.1.3. L'annuaire de servicesWeb La specification UDDI (Universal Description, Discovery and Integration) dEfinit un annuaire centralisE de services Web qui permet aux utilisateurs de trouver les services correspondant ~t leurs attentes. UDDI peut ~tre utilisE selon deux logiques. Initialement les promoteurs de la norme UDDIvoulaient construire un annuaire universel des services Web. Cette logique dispara~t progressivement au profit d'une vision d'annuaires privEs permettant de gErer les services d'intranets ou d'extranets. La figure 25 illustre l'utilisation d'un annuaire UDDI. Une entreprise B produit un service Web S 1 qu'elle declare dans l'annuaire (fl~che 1). Une entreprise A a besoin d'un service et effectue une recherche dans l'annuaire (fl~che 2). Elle trouve le service correspondant h ce qu'elle cherche, c'est le service S1 dont elle rapatrie la description WSDL(fl~che 3). I1 ne lui reste plus qu'h faire des invocations ~ S 1 via SOAr'(flEche 4) et ~ rEcupErer en retour un message SOAPcontenant la rEponse (fl~che 5). Un annuaire UDDIest en rEalitE un annuaire logique qui peut Etre compose d'un ensemble de sites opErateurs. Ces derniers se dE16guent les responsabilitEs et synchronisent leurs Etats par des mEcanismes de duplication, qui utilisent des messages SOAP. VDDI comprend deux parties. La premiere dEfinit le module d'informations de l'annuaire et la seconde dEfinit une interface de programmation en SOAPpour interroger et mettre h jour un annuaire UDDI.
Entreprise A [ a besoin d'un service
FIc. 25. --
~] 5
Entreprise B a publiE le service web S 1
Principe d ' u t i l i s a t i o n d ' u n annuaire UDDI,
Using an UDDIdirector3: ANN. Tt~LECOMMUN., 58, n ° 1-2, 2003
45/51
C. MORLEY -- LES OUTILS DU COMMERCE FzLECTRONIQUE
53
Un document UDDIest compos~ de quatre ~16ments principaux. Le businessEntity d6crit le fournisseur de services Web (identit6, adresse 61ectronique, positionnement dans les classifications m6tiers). Ce foumisseur peut proposer un ensemble de businessServices qui correspondent aux services Web et notamment h leur description WSDL (partie interface abstraite). Un businessService peut ~tre accessible via plusieurs bindingTemplate qui correspondent '~ la partie liaison des descriptions WSDL. BusinessService et bindingTemplate peuvent ~tre index6s par une instance de tModel qui est un couple mot-cl6 et UR~ (Uniform Resource Identifier). Cette notion de tModel permet d'associer des informations plus s6mantiques sur le service, pat" exemple en le rattachant ~ une classification m~tier. Plusieurs sites op6rateurs existent d'ores et d6jh, notamment ceux des promoteurs de la norme. Cependant le succ~s d'UDDI n'est pas encore acquis, d'autant plus que le besoin d'annuaire sera important quand les services Web deviendront nombreux. Mais la lourdeur de la norme risque de r6duire sa diffusion sur le march& De plus, elle introduit encore un nouveau type d'annuaire qui vient se rajouter au standard LDAPpour les annuaires d'entreprise. IV.4.1.4. Les p r o c e s s u s m6tiers des services W e b
De nombreuses propositions de norme ont 6t6 61abor6es par diff6rents 6diteurs ou consortiums. On trouve notamment XLANG de Microsoft, WSFL (Web Services Flow Language) d'mM, WSCL (Web Services Conversation Language) de Hewlett Packard, ainsi que le BPML (Business Process Modeling Language) d6jh 6voqu6 pour sa compatibilit6 avec UML, qui est la proposition la plus g6n6rale et la plus compl6te pour g6rer des processus intra et interentreprises. Dans le contexte des services Web, les concepts BPMLsont utilis6s de la faqon suivante. Les participants ~ un processus m6tier en sont les parties prenantes, tant humaines que mat6rielles ou logicielles, des bases de donn6es par exemple. On distingue les participants statiques, connus h l'avance, et les participants dynamiques qui seront d6couverts pendant l'ex6cution. Les participants communiquent entre eux via des messages, qui sont les unit6s d'interaction entre participants. Les messages sont cod6s en SOAP et leur r6ception d6clenche des op6rations. Celles-ci se composent d'activit6s, qui sont les unit6s d'ex~cution. BPML distingue les activit6s simples (une communication entre deux participants), les activit6s complexes (constitu6es d'activit6s simples) et les activit6s de type processus (analogue ~ un workflow avec des constructions de type boucle, branchement, s6quence ou parall61e). BPML se pr6sente comme un langage d6claratif, de type r~gles de production 23 pour sp6cifier les r6actions. Les r6gles mfitiers peuvent s'encha~ner en cascade et sont trait6es par un moteur de r6gles charg6 de choisir la r6gle ~ appliquer en fonction de l'6tat du syst6me. Ce langage permet de sp6cifier le comportement transactionnel des activit6s via des attributs sp6cifiques. II offre le m~me niveau fonctionnel que ce que l'on trouve darts les services de transactions Corba-oTS ou Java-JTS. Le support des transactions reste cependant faible dans le mod61e des services Web, ce qui en limite aujourd'hui la diffusion. BPML distingue les abstractions de processus qui sont des descriptions de processus non instanci6es dans lesquelles activit6s, participants et messages sont d6finis de mani6re g6n6rale, des ex6cutions de processus, o~J toutes les informations sont instanci6es. Le module BPML va s'ex6cuter via un moteur appel6 BPMS (Business Process Management System)
23. ~ Sl condition ALORS action -. 46/5 l
ANN. TELI~COMMUN.,58, n ° 1-2, 2003
54
c . MORLEY -- LES OUTILS DU COMMERCE I~LECTRONIQUE
construit au-dessus d'un serveur d'applications de type Java J2EE ou bien Microsoft .NET. Au niveau communication, les messages BPMLpeuvent s'Echanger sur tout type de middleware. IV.4.2. Les a p p r o c h e s EDI
Les grands organismes ont con~u et dEveloppE depuis longtemps des norrnes d'l~change de donnEes InformatisE - EDI. Ces normes ont eu et ont toujours un succ~s important dans des domaines d'applications spEcifiques, comme la banque ou la logistique. L'inconvEnient majeur de ces approches EDI est la lourdeur des outils utilisEs et leur coot. De plus, ils supposent que tous les acteurs soient connectEs par un rEseau priv6. Avec l'av~nement d'Internet et de normes comme XML,les approches ED1 sont revisitEes en faveur d'outils plus 16gers et d'un dEploiement sur des rEseaux publics type Internet. Cela peut permettre d'offrir I'EDI h des eME. De nombreux consortiums travaillent sur des specifications XML pour I'EDI. Pour Eviter une dispersion de ces efforts de standardisation, des acteurs majeurs, dont I'UN/CEFACTet OASIS, ont lance ebxML, initiative fEdErative visant ~ dEfinir des specifications gEnErales XML pour L'EDI, qui pourront ensuite ~tre reprises et EventueUement 6tendues par d' autres consortiums visant des secteurs d'activitEs particuliers (RosettaNet pour le secteur des hautes technologies par exemple). ebxML est un ensemble de specifications couvrant : schema de specification de processus metier, convertissant en document XML les modules de processus dEcrits en UML selon la mEthodologie UMM (UN/CEFACT Modeling Methodology). - La documentation des services offerts par une entreprise (formalisEe dans des Collaboration Protocol Profile - cpe) de mani~re ~ pouvoir automatiser un accord (formalisE dans des Collaboration Protocol Agreement - CPA). - Des services d'annuaires (Registry Services) et un module d'information associ6 (Registry Information Model) analogues a UDDIet qui permettent de stocker et rechercher tous les documents ebxML et notamment les CPP. - Des services de messagerie (Messages Services) construits sur SOAP qui permettent de faire l'Echange des documents ebXML. - Des services lies ~ la sEcurit6 (authentification, non repudiation...). A titre d'exemple, un syst~me ebxML (Fig. 26) permet a une entreprise E1 de publier les processus metiers qu'elle est capable de rEaliser dans des cpp. Ces cpP sont stockEs dans un annuaire ebXML, dans lequel une entreprise E2 peut faire des recherches. Si la recherche est fructueuse, les entreprises E1 et E2 peuvent formaliser un accord via un CPA qui sera ensuite nEgoci6 entre les deux parties (rien ne dit dans les specifications ebxML que cette nEgociation est automatisEe). Lorsque la nEgociation est achevEe, les deux parties vont configurer leur interface ebXML (Business Service Interface) pour pouvoir ensuite commencer l'exEcution des processus metiers et 6changer des documents ebxML via des messages ebxML. Les services Web sont un environnement de programmation rEpartie facilement deployable sur un rEseau comme Internet. De plus, cet environnement est supportE par les deux grandes architectures rEparties concurrentes que sont J2EE/Java et .NET. Cela leur permet d'assurer l'interopErabilit6 entre un client .NET et un serveur J2EE par exemple. C'est une brique importante pour le e-commerce, mais qui reste h u n niveau communication, ebxML essaye d'ajouter ~t cette brique une description complete, sous forme de DTD XML, des docu-Un
ANN.TI~LI~COMMUN.58, , n° 1-2, 2003
47/51
C. MORLEY -- LES OUTILS DU COMMERCE I~LECTRONIQUE
1
enregistrement
Entreprise E1
55
2 - recherche CPP Entreprise E2
xMLJ
3 - ndgoclation 4 - configuratio~
3 - n6gociation CPA
4 - configuration
Business Service Interface de El
Business Service Interface de E2 5- communication
FIG. 26. - - Principe de fonctionnement d'un syst6me ebxML.
Collaboration model for an ebgML system.
ments h 6changer entre entreprises dans une session de e-commerce, ainsi qu'une mod~lisation des activit6s de e-commerce, ebXML et les services Web ne sont pas vraiment concurrents, mais plut6t compl6mentaires, ebxML reste n6anmoins une norme g6n6rique pour le e-commerce et des consortiums comme RosettaNet mod61isent encore plus de documents et d'activit6s sp6cifiques en se focalisant sur un domaine industriel particulier.
V. C O N C L U S I O N
Le tableau des outils pour le e-commerce laisse appara]tre plusieurs tendances. L'offre applicative est multiple, avec un 61argissement des fronti6res de chaque domaine. Les progiciels de gestion int6gr6s 6tendent leurs fonctionnalit6s h la cha]ne de vente, h la cha~ne logistique, ~t la gestion de la relation client et au data warehouse. De leur c6t6, les outils d'entrep6t de donn6es int~grent des fonctions d'analyse des donn6es, tandis que les outils d'exploration de donndes se dotent d'entrep6ts de donn6es. Les fonctions d'achats automatis6s et de place de march6 apparaissent dans les outils de gestion de la cha~ne logistique. Ainsi, les entreprises sont-elles plac6es devant le choix, soit de se tourner vers une ~, int6gr6e d'applications fournies par un seul 6diteur, soit de s61ectionner les produits les plus adapt6s h leurs besoins et les int6grer. Ce choix est de nature strat6gique, car il conditionne en grande partie l'architecture du syst6me d'information. La solution de produits int6gr6s, pour s6duisante qu'elle puisse appara]tre h premi6re vue, va ~t l'encontre d'une vision actuelle de l'6volution progressive des syst6mes d'information, par d6formation continue, appel6e urbanisation des systbmes d'information. Par ailleurs, il faut souligner que la raise en oeuvre des outils pr6sent6s dans la premi6re partie est encore limit6e ou partielle. Les principaux obstacles relbvent des pratiques et de la confiance dans les relations entre acteurs. La collaboration et le partage d'informations internes repr6sentent le
48/51
ANN. TI~LI~COMMUN., 58, n ° 1-2, 2003
56
c. MORLEY -- LES OUT|LS DU COMMERCE ELECTRONIQUE
drfi majeur d'une gestion du client 61argie, tandis que la cooprration et la mise en commun d'informations entre partenaires sont les clEs d'acc~s ~ une chaine logistique performante. Du c6t6 des technologies, on observe depuis quelques annres une convergence autour de normes sur les langages et les modules. L'interop6rabilit6 des syst~mes reste toutefois une question essentielle, pour 6changer des informations et partager des processus, notamment duns le cadre du B-to-B. Parmi la multitude d'outils proposals, les approches de type EM sont les plus s6duisantes, car les plus completes et surtout les plus intrgrres. Elles devraient permettre d'interconnecter de mani~re relativement simple et rapide des syst~mes hrt6rog~nes. Des rapprochements rrcents entre fournisseurs d'outils EAI et 6diteurs de logiciel d6di6 au Bto-B sont signe de cette tendance [Linthicum, 2001]. Duns le contexte du e-commerce, on note l'rmergence de deux courants. Les services Web sont plut6t issus du monde Web et peuvent &re vus comme un outil d'intrgration sprcialis6 et bus6 sur les technologies dominantes du Web (XML et HTTP). En revanche, les consortiums comme ebxML OU RosettaNet viennent plut6t du monde EDI : ils proposent une infrastructure technique qui est concurrente des services Web et qu'ils compl~tent avec une vision plus orient6e mrtier. Cependant, ces consortiums EDI sont peut-&re trop ambitieux et proposent des normes fort complexes. Heureusement, ils semblent se rallier aux choix techniques des services Web, ce qui permettra de voir converger l'ensemble des propositions. En ce qui concerne le B-to-C, la convergence de la trlrphonie mobile et de l'Internet, accompagn6e de l'rmergence de standards (WAP, iMode...), ouvre des possibilitEs au drveloppement du commerce mobile, m-commerce [Barnes, 2002], dont on prrvoit qu'il reprdsenterait plus de 3 % des revenus grnrrds par le commerce 61ectronique.
Manuscrit requ le 27 juin 2002 Accept~ le 10 octobre 2002
RI~FI~RENCES [ 1] AMAMI (M.), <>,Proceedings Of CMSR'02, 1EEL,2002. [3] AVIGNON(L.), JOGUET (D.), PEZZlARDI (P.) (2000), <~Intrgration d'applications : I'EM au c0eur du e-business >>, Eyrolles, 2000. [4] BARNES (S.J.), <>, European Journal of Purchasing&Supply Management, 8, Issue 2, juin, pp. 111-122, 2002. 16] BELLAHSENE(Z.), BARIL (X.), <>,lngdnierie des systkmes d'information, 6, n ° 3, pp.l 1-32, 2001. [7] BENETTI(I.), BENEVENrrANO(D.), BERGAMASCHI(S.), GUERRA (E), VINC1N!(M.), <>,1EELIntelligent Systems, 17, Issue 1, janv.-frv, pp. 18-25, 2002. [8] BERRY (M.J.A.), LINOFF (G.S.), << Mastering Data Mining. The art and Science of Customer Relationship Management >>, Wiley, 2000. [9] CARLSON(D.), <>,Eyrolles, 2001. [10] CHAN (S.), DILLON (T.), SIU (A.), <>,Journal of Systems and Software, 60, Issue 3, fEvrier, pp.239-248, 2002. [11] CHAUVET(J.M.), <>, Eyrolles, 2002.
ANN. TELI~COMMUN.,58, n ~ 1-2, 2003
49/51
C. MORLEY - LES OUTILS DU COMMERCE F,LECTRONIQUE
57
[ 121 CONALLEN(J.), ~ Concew)ir des applications Web avecUML ,,, Eyrolles, 2002. [13] CURBEr~A(E), DUVrLER (M.), KHALAF(R.), NAGY (W.), MUKH1 IN.), WEERAWARANAIS.), <,, IEEElnternet Computing 6(2), pp 86-93, 2002. [14] EMM~RICH (W.), ,~ Distributed Component Technologies and their Software Engineering Implications ,,, lose 2002, mai, pp.537-546, 2002. [ 15] FINGAR(R), ~>, F,, Industrial Marketing Management, 31, Issue 7, octobre, pp.559-567, 2002. [18] JENSEN (M.R.), MOLLER (T.H.), PEDERSEN (T.B.), (~ Specifying OLAP cubes on XML data ~,, Proceedings. Thirteenth hlternational Cot!fi'rence on Scientific and Statistical Database Management, pp. 101-112, 2001. [19] LEE (H.L.), WnAN(~ IS.). ~, E-business and Supply Chain Integration ,,. Stanford Global Supply Chain Management Forum, novembre, 20111. [20] KAPLAN IS.), SAWHNEY (M.), ¢¢ E-Hubs : the new B2B marketplaces ~, Harvard Business Review, maijuin, 2000. [211 KIMBALL(R.), MERZ (R.). ~ Le data webhouse ,, Evrolles, 20110. [221 KUMAR (A.), LEON ZBAO (j.h " workflow support for electronic commerce applications ,,, Decision Support Systems, 32, Issue 3, janvier, pp.265-278, 2002. [231 LEFF.Bt!RE(R.), VENTUre IG.), ~, Gestion de la relation client ,,, Eyrolles, 2000. [241 L1NTHICUM(D.S.), ~ Where EAI meets B2B ,,, Sqfiware Magazine, avril-mai, 2001. [251 LONGI~PI~(C.), Le projet d'urbanisation du syst6me d'intk~rmation, Dunod, 2001. [26] MANOUVRIER(B.), ~ EM lntdgration des applications d'entreprise ,,, Herm&, 2001. [271 MICHARD(A.), ~ XML : langage et applications ~,, 2~ 6d., Evrolles 20111. [28] MIN (H.), ZHOU (G.), ~, Supply chain modeling : past, present and future ~, Computers bzdustrial Engineering, 43, Issue [ -2, juillet, pp. 231-249, 2002. [29] Mom.~Y (C.1, HtmuEs (J.), LEBLANC (B.), ~, UML pour l'analyse d'un syst6me d'information ,,, 2 e 6d., Dunod, 2002. [311] MORRISON (M.), MORRISON (J./, KEYS (A& ~, Integrating web sites and databases ,,, Communications of'the ACM, 45, n ° 9, septembre. 2002. [31] MUSCIANO(C.), KENNEDY(B.), ~ HTML et XHTML- La r~f6rence ,~, (4 e 6d)., O'Reilly France, 2001. [32[ NGM (E.W.T.), WAT (EK.T.), ~ A litterature review and classification of electronic commerce research ,~, lnfbrmation&Management, 39, issue 5, mars, pp. 415-429, 21102. [33] NIEUWBOUR(;(R), d'HONDT (H.), ~ Places de march6 sur Internet ~,, BNTE 20011. [34] Or~TIZIS.) 12t)1/21, ~ Is business intelligence a smart move? ~,, Computer, 35, Issue 7, juillet, pp. 11 -14. [351 PICK (J.D.), SCHNEIDER I D.L SCHNETKAMP(G.), ~ E-Markets, les nouveaux modules de B2B ~,, First Editions, 20111 [36] PJMoR (Y.), ~ Logistique. Techniques et mise en ~xzuvre ,,. Dunod, 2001. [371 POIR~l~ (C.C.), RE~TER (S.E.L ~, La supply Chain ,, Dunod, 2001. [381 ROB~RTS (B.), MACKAY (M.), ~ ~T supporting supplier relationship : the role of electronic commerce ,~, European Journal of Purchasing&Supply Management, 4, n ° 2-3, pp. 175-184, 1998. [39] SALEH(K.L ~' Documenting electronic commerce systems and software using the unified modeling language ,~, hzlbrmation and Software Technology, 44, Issue 5, avril, pp. 310-311, 2002. [40] S~RMN (D.). ~ Entreprise Application Integration : l'architecture des solutions e-business ,,, 3e 6d., Eyrolles, 2000. [41] SI~(;~L (J.), ~< Using OMG Model Driven Architecture (MDA) to Integrate Web Services ~,, white paper, http ://www.omg.org, 2002. [42[ SOLEY (R.) et groupe de travail OMG, ~, Model Driven Architecture ,, White Paper, Object Management Group, http ://www.omg.org, novembre, 2000. [43] STROBEL (M.), ~, An XML schema representation for the communication design of electmic negotiations >,, Conqnaer Networks, 39, Issue 5, aofit, pp. 661-680, 2002. [44] TAN(; (J.E.), Snee (D.Y.), TAN¢; (T.I.), <
50/51
ANN. TI~LI~COMMUN.,58, n ° 1-2, 2003
58
C. MORLEY -- LES OUTILS DU COMMERCE t~LECTRONIQUE
[48] Xu (D.), WANG (H.), ~, Multi-agent collaboration for B28 workflow monitoring ,~, Knowledge-Based Systems, 15, Issue 8, novembre, pp. 485-491, 2002. [49] YEN (D.C.), HUANG(S.M.), Ku (C.Y.), ~(The impact and implementation of XML on business-to-business commerce ~, ComputerStandards&Interfaces, 24, Issue 4, septembre, pp. 347-362, 2002a. [50] YEN (D.C.), CHOU (D.C.), CHANG(J.), ~(A synergic analysis for Web-based enterprise resources planning systems )>, ComputerStandards&Interfaces, 24, Issue 4, septembre, pp. 337-346, 2002b. [51 ] ZUREK(T.), KREPLIN(K.),, SaP Business Information Warehouse-from data warehousing to an e-business platform ~, Proceedings of 17th International Conference on Data Engineering, pp. 388 -390, 2001.
ANN. TI~Lf/COMMUN.,58, n ° 1-2, 2003
51/51
