| VendrEDI |  |
lettre de Claude Chiaramonti | ||
| sur les
données de l'échange électronique |
||||
| Numéro 78 14 mai 2004 | ||||
|
Projet Actif
|
PrEDIctions : bilan
|
|
|
pour des transports
intelligents
|
5 ans après le n° 1 de
VendrEDI
|
|
Le projet Actif,
Architecture Cadre pour les Trans-ports Intelligents en France,
animé par le Ministère de l'Equipement, s'appuie sur les
projets européens Karen puis Frame. Les "systèmes de
transports intelligents" permettent de "collecter, stocker, traiter
et distribuer de l'information relative au mouvement des personnes
et des marchandises". Sans brider les projets particuliers, Actif
vise au contraire à leur fournir un cadre méthodologique garantissant
l'inté-gration entre les systèmes,
l'interopérabilité des équipements, applications et
services, et la réfé-rence aux mêmes normes et
standards.
En plus de l'architecture-cadre d'ensemble,
Actif couvre plus précisément le transport terrestre de
voyageurs et de marchandises dans une approche
"multi/inter-modale", route, fer, fluvial, y compris les
interfaces vers l'aérien et le maritime. Les très
nombreux documents téléchargeables d'Actif
couvrent donc l'aspect transport de l'e-business mais
aussi d'autres fonctions où les études de domaine,
suivies d'études de projets concrets, ont été
préparées par une étape de modélisation. C'est
à cette occasion, en rattachant aux "objets" du modèle
les normes et standards de facto existants, que le
recensement de la normalisation du domaine a été
effectué : répertoire des normes de matériels
et d'équipements du domaine des transports, les messages
des normes Edifact ou Edigeo concernés par le cadre
d'Actif etc.
Ont été déduits, en s'appuyant
à la fois sur le cadre d'architecture et sur les études
des dix domaines d'Actif, les besoins de normalisation
comme facteur d'interopérabilité, par exemple
amélioration des normes d'identification et de localisation
des véhicules ou intégration des messages EDI et
Edimobile dans les scénarios d'échanges. Sans oublier,
d'une part que la normalisation n'est qu'un moyen et non un
but, les aspects organisationnels étant décisifs, d'autre
part que la dimension interna-tionale, notamment
européenne, est désormais au coeur des besoins
d'intégration.
Au total, le projet Actif est un exemple
à suivre quant à l'implication "intelligente" des
pouvoirs publics dans la définition d'une architecture-cadre
permettant ensuite aux différents acteurs de mieux
valoriser leurs projets grâce à leur
cohérence.
|
Le VendrEDI n° 1 daté du 14 mai 1999
comportait, dans l'article mEDItations, une première ligne
EDItoriale sur Edifact et XML toujours
valable :
"...1/ Edifact est d’abord le
résultat d’innombrables réunions où des
utilisateurs du monde entier, commerçants, banquiers,
transporteurs etc. ont défini les données devant figurer
dans tout échange électronique rendant compte de leurs
transactions. Cela, le monde XML ne devrait pas l’ignorer,
sous peine de réinventer l’eau tiède à grands
frais !
2/ Réciproquement, le monde Edifact ne
devrait pas ignorer les avantages potentiels de XML pour le
transport et le traitement des données qu’il a
défini..
Mais...après des investissements parfois
lourds, les échanges Edifact, ça marche...D’autant
que la révolution culturelle permanente de XML incite à
attendre qu’une certaine maturité soit
atteinte..Voilà
le décor qui va occuper le devant de la
scène pour un moment est planté..."
Si l'importance accordée à XML s'est
justifiée, erreur de prévision de VendrEDI : il
n'était pas envisagé que 5 ans après, ni ebXML
ni les Services Web n'aient encore vraiment permis de
changer de décor ! Edifact ou les standards antérieurs
restent les formats les plus utilisés.
Prévision moins erronée de VendrEDI, le scepticisme
affiché sur ebXML, dès son lancement en septembre
1999, sauf en ce qui concerne son
messaging rallié à SOAP.
Prédiction qui s'est
révélée justifiée : les langages XML vont
fleurir dans des communautés parallèles, l'aspect
eXtensible de XML étant antinomique d'une gestion top
down des contenus business. Autre prédiction
justifiée, celle de trouver fort de café la vente
aux PME de stages d'initiation à une usine à gaz ebXML
présentée comme la panacée pour leur entrée
"facile" en e-business !
A l'inverse, les Services Web ont paru
être l'avenir des échanges électroniques, en tenant
compte de la puissance de leurs parrains, IBM et surtout
Microsoft, aujourd'hui adoubé par le Cefact-Onu. Mais là
aussi, erreur de prévision de VendrEDI quant au rythme
d'implémentation de ces Services Web, faute de standards
stabilisés ! De
rnière pré-diction,
encore à vérifier, l'importance, y compris pour
l'e-business, du Semantic Web et de ses
outils RDF et OWL. |
 |
Pour que "le message passe" il faut être d'accord
sur le sens des données Petit
Glossaire du B2Bfr
|
|
Stratégie IBM :
|
Alignement UBL ou
|
|
|
SOA,
Services Web et Grid
|
|
langage-pivot loosely coupled ?
|
|
Big Blue est en train de conforter une
stratégie offensive avec son orientation Grid, Services Web et
SOA (Services Oriented Architecture). Sur la SOA voir
VendrEDI n°
75. CBDi propose comme définition de la
SOA "Save Our Assets" ou, plus sé-rieusement,
"The policies, practices, frameworks that enable application
functionality to be provided and consumed as sets of services
published at a granularity relevant to the service consumer.
Services can be invoked, published and discovered, and are
abstracted away from the implementation using a single,
standards-based form of interface. C'est "services", qui est
important dans cette définition, la SOA ne se résumant
pas à une vision plus large de Services Web plus "maniables"
par les utilisateurs.
Pour IBM, il s'agit, avec cette orientation
SOA de proposer pour le niveau business process (BP)
une modularité du même type que celle du niveau
logiciel sous-jacent, avec des composants réutili-sables
d'un process à l'autre. Avantage collatéral
pour IBM, une meilleure synergie entre ses différentes
divisions "logiciel" : WebSphere, Tivoli, DB2, Rational
et Notes dans le cadre du puzzle On Demand et de
IBM Global Services. Avec Compo-nent Business
Modeling, il s'agit de donner aux clients d'IBM à la fois
la souplesse qu'ils souhaitent et la garantie de maitriser le
retour sur investissement de la mise en place de Services Web. Voir
chez IBM son Service-Oriented Archi-tecture Web site. Désormais
WebSphere, avec son WebSphere Business Integration Server
Foun-dation, est "natif" BPEL4WS, langage de mise en
oeuvre des BP, qu'IBM a lancé avec Microsoft et qui est
en cours de standardisation à Oasis. Mais cette
coopération initiale n'empêche pas les deux principaux
promoteurs des Services Web d'avoir leur propre stratégie,
pouvant même aboutir à une concurrence au niveau
des standards de mise en oeuvre. Si Microsoft a
WS-Eventing, IBM propose la
série des
WS-Resource pour la
gestion du state de la transaction d'un Service Web
et surtout comme outil du
Grid Computing. Le Grid vise à
pouvoir exécuter une application sur des ressources
momentanément inutilisées ailleurs, ce qui nécessite
standards et best practices. Tous les majors
sont au
Global Grid
Forum que
IBM suit de près. Avec les Services Web et la
SOA, IBM entend bien faire du Grid la clef de voûte
d'une architecture et d'une stratégie d'ensemble
d'intégration maîtrisée qui est vue comme la
réalité de demain.
|
L'adoption d'
UBL, Universal Business Language, comme
projet de standard par Oasis est l'occasion de réfléchir
à ce qui est en jeu. Tout d'abord "l'universalité" d'UBL
ne concerne en fait que la supply chain à la
mode anglo-américaine. Même si UBL a
été adopté pour les achats publics danois (cf
VendrEDI n° 73). Surtout, de
quoi s'agit-il ? De proposer aux entreprises de redéfinir
leurs données internes en s'alignant sur les noms et
définitions de ce langage ? Il faut se rappeler que cet
alignement n'a jamais été exigé par l'EDI
traditionnel ! Les noms et définitions des données des
répertoires TDID d'Edifact ne sont proposées que comme
langage-pivot : au départ, l'expéditeur traduit
(map-ping) ses données internes à
transmettre dans les données correspondantes du TDID, et
à l'arrivée du message Edifact, le
destinataire procède à un mapping en sens
inverse pour mettre à jour ses données internes. Le
recours au langage-pivot Edifact permet à
l'expéditeur comme au destinataire d'un message EDI
de garder les noms et définitions de leurs
données internes. Le map-ping qui autorise cette
autonomie préservée est lourd, dit-on : certes, mais il
est effectué une fois pour toutes ! Et redéfinir ses
données pour les aligner sur UBL (ou les Core
Components en cours de définition au Cefact)
ne sera pas une opération légère, même si, elle
aussi, sera faite une fois pour toutes ! Un argument souvent
avancé est qu'il devrait y avoir autant
de mappings que de secteurs avec lesquels
l'entreprise est en relation de e-business, alors
que l'alignement sur UBL resterait une opération unique, du
fait de son caractère universel. On a vu que
l'universalité d'UBL était, au moins pour le moment,
limitée à la supply chain. Surtout, cet argument
suppose que toutes les applications de l'entreprise utilisent
les mêmes défi-nitions de données pour
toutes les fonctions de l'en-treprise : on sait que ce n'est
pas toujours le cas ! L'adoption du Committee Draft UBL alignerait
alors tous les secteurs de l'entreprise étendue sur un seul
catalogue d'infor-mation. Certes, mais ce n'est pas forcément
le scénario le plus réaliste ! Ce n'est pas un hasard si
le seul alignement à peu près réussi concerne les
identifiants, depuis celui des entreprises jusqu'à,
bientôt, celui des objets (cf VendrEDI n° 70). Pour les autres types de
données, l'efficacité a, jusqu'à présent,
consisté à prése
rver la
spécificité des langages métiers : le loosely
coupled vaut encore plus pour la sémantique que pour les
connexions ! |
| Ce numéro 78 de VendrEDI a été adressé à 1283 abonnés Pour écrire |
| Tous les numéros de VendrEDI peuvent être téléchargés à http://www.actimum.com/acvendredi.htm |