| VendrEDI |  |
lettre de Claude Chiaramonti | ||
| sur les
données de l'échange électronique |
||||
| Numéro 100 14 octobre 2005 | ||||
|
Sens commun :
|
Back to the future
|
|
|
Semantic Web +
Services Web
|
pour le Cefact-Onu et ebXML
|
|
Le programme IST de la Commission
européenne comporte un projet WS2 (Web Services and
Semantics) qui cherche à rattraper, au niveau
sémantique, le retard européen pris pour les logiciels
des Services Web (SW). Ce projet WS2 a financé une
Conférence organisée en juin dernier, à Innsbruck,
par le Semantic Web Services Interest Group du W3C
qui cherche lui-même à ne pas être distancé par
Oasis en matière de standardisation des SW. Il s'agissait
à Innsbruck de vérifier ce que les outils du Semantic
Web, RDF et OWL, pouvaient apporter à la
sémantique des SW en enrichis-sant ses outils de
base, SOAP, WSDL et UDDI.
On peut d'ailleurs espérer une
convergence promet-teuse entre le "stock" et le "flux" des
données du Web, deux domaines et techniques qui doivent
être complémentaires. D'une part le Semantic Web
permettant la description du "sens" du "stock" des innombrables
pages Web, en allant au-delà des simples mots-clés qui ne
sont que des caractères sans aucun "sens". D'autre part le
"flux" des messages automatisés d'application à
application, si l'on veut que leur "sens" n'ait pas à
être défini au préalable, comme pour le niveau
des codes dans les accords d'interchange de l'EDI pour chaque
Communauté d'échanges.
Le programme d'Innsbruck alliait exposés
théoriques et études de cas en partant des technologies
proposées ou en cours de définition : WSMO
(cf. VendrEDI n°96), Web-Service
Se-mantics (WSDL-S), OWL-S (cf. VendrEDI n°87), First-Order Ontology
for Semantic Web-Services (FLOWS) ou Siemens’
Service Description Refe-rence Model (SDRM). Entre
autres...
La difficulté est notamment de
distinguer ce qui doit être standardisé,
métadonnées et outils pour le rapprochement des
ontologies, et ce qui peut rester foisonnant. Autre
difficulté, concilier l'approche parfois théorique du
Semantic Web et les soucis concrets d'une sémantique
business de mise en oeuvre des SW.
Sans oublier un autre effort du W3C, la
"locali-sation" pour s'adapter aux "coutumes" locales
, ce qui inclue une
sémantique english enrichie (cf. VendrEDI n°95) par le multilinguisme des
langages métiers. |
L'été 2005 a vu la résurgence,
au Cefact-Onu, du débat récurrent depuis les années
1990 sur la réalité de la synergie affichée entre
trade facilitation d'une part et d'autre part EDI, puis
e-business. Un rapport d'audit de l'Onu New-York
préconise ainsi de séparer deux domaines dont la
partie aliquote commune est très minoritaire et qui se
seraient bien mieux développés en devenant autonomes.
C'était déjà, en 1990, l'opinion de la
délégation française à la CEE-Onu de
Genève : elle préconisait alors la migration de l'EDI
à l'ISO. Ce qui a été perçu comme une
trahison par les autres délégations à la
CEE-Onu. Prévisible...ecce homo !
Il y a quelques années, constatant le
schisme entre ebXML et les Services Web (SW), le Cefact-Onu
s'est rapproché de Microsoft pour proposer le BCF
(Business Collaboration Framework) qui aurait permis de
mieux articuler tous ensemble, outils de la trade
facilitation, EDI classique en Edifact, ebXML et SW
(cf. VendrEDI n°80 et n°84). Avec
le SBDH, Standard Business Document Header.
Devant une telle abominable alliance avec le
diable, nouvelle levée de boucliers des délégations
conser-vatrices et retour au status quo. Avec changement de
l'équipe dirigeante du Cefact-Onu et départ sur la pointe
des pieds de Microsoft. Avec, en prime, le rapport d'audit de
l'Onu New-York !
En attendant les suites
éventuelles de cet audit, le monde Edifact
mise toujours sur un rebond avec le sang neuf ebXML. Mais
pour les uns, ebXML s'implante massivement, alors que pour les
autres on en entend de moins en moins parler ! Parce
qu'on parle peu des trains qui arrivent à
l'heure ? A l'inverse, la très forte
influence des francophones au Cefact-Onu n'est peut-être
pas l'indice d'un très fort intérêt des
utilisateurs mondiaux anglophones !
Quant à ebXML, s'il ne
prétend plus couvrir à lui seul, comme
prévu, tout l'e-business, c'est
peut-être enfin un signe de réalisme et d'efficacité
(cf. l'article registry page 2). A la réunion
mondiale des experts du Cefact, le Forum, le mois dernier
à Lyon, d'une part SAP a remplacé Microsoft
; d'autre part, c'est la simple possibilité pour les
concurrents (UB
L) ou
langages sectoriels (GS1ou XBRL) d'uti-liser les Core
Components, outil ebXML de base, qui était
célébrée. |
 |
Pour que "le message passe" il faut être d'accord
sur le sens des données Petit
Glossaire du B2Bfr
|
|
L'intégration en
SO
|
|
Le registry SOA :
|
|
de la SOA au Grid et aux
BP
|
|
UDDI + ebXML registry ?
|
|
Depuis ses origines, l'informatique a
progressé en direction de l'intégration et de
l'interopérabilité : standardisation, modélisation,
modules réutilisables, puis Object Oriented
(OO) d'abord à l'intérieur des SI, puis
entre SI avec le développement des échanges
électroniques de données inter-entreprises ou
organisations. Maintenant, le concept général pour
l'intégration sur le Web est celui de "service" : d'où le
SO (Service Oriented), devant remplacer le OO, ou le CO
(Component Oriented) qui est un OO basé sur des
"super-objets". D'où l'ESB et la SOA(Service Oriented
Architecture) dans le SI interne. D'où
aussi l'échange de "services" dans le cadre d'un
scénario, ou business process,
entre des entreprises "étendues". D'où aussi
une plus grande souplesse pour articuler l'évolution des
applications et des plates-formes qui n'évoluent pas
forcément de manière coordonnée. D'où
enfin le Grid, réseau de "services" rendus
pour le partage des ressources informatiques entre entreprises afin
d'étaler des pics de consommation. Toutes ces formes
d'intégration peuvent utiliser les outils des Services Web
(SW), surtout SOAP, mais aussi WSDL.
Sans être encore passé dans les
mœurs, le SO se mettra d'autant plus facilement en oeuvre
qu'il reprend pas mal du OO. Mais quelle est alors la
différence entre un "objet" et un "service" ? Un objet est
lié à un environnement de programmation (Java etc.) et
est accessible à l'intérieur d'un processus. Le
"service" est remotely accessed et n'est pas
spécifique à un environnement de pro-grammation. La
granularité est moins fine dans un service, ce qui
nécessite moins de messages pour compléter une
transaction. Et l'intégration est basée sur les
messages des SW plutôt que sur du code, loosely
coupled assurant la souplesse permettant de suivre
l'évolution des business process. En partant de la
modélisation des business process pour
l'intégrer comme matériau du SO. Allant dans ce
sens, IBM et SAP proposent BPEL4People, une extension de
WS-BPEL "for people", pour que, dans l'exécution d'un
business scenario, une application puisse repasser la main
à l'utilisateur.
Au total, ce qui est donc en vue est
fondamental et attendu depuis les débuts de l'informatique :
passer du niveau IT au niveau des business process, c'est
à dire faire en sorte que l'intégration ne soit plus
seulement une affaire de techniciens avec
leurs tuyaux, protocoles et
formats, mais soit au "service" des "fonctionnels",
responsables de leurs processus-métiers. |
Pour une discovery pas trop
compliquée d'un service sur le Web, Web-Discovery devrait
suffire à compléter UDDI (cf. VendrEDI n°94), sans besoin de recourir
à ebXML Registry.
Par contre, ebXML Registry pourrait bien
être indiqué afin d'affiner la rusticité
d'UDDI, face à la complexité croissante de la SOA et du
registre de services autour duquel elle doit être
progressivement construite. Il n'est pas surprenant que ce soit, en
tout cas, l'avis du groupe d'Oasis qui a approuvé ebXML
Registry v3.0 comme standard... A noter qu'un autre groupe d'Oasis
a, lui aussi, adopté comme standard UDDI version 3.0.2 !
Sans qu'il y ait de liaison entre les deux groupes d'Oasis,
vérita-ble auberge espagnole ! Aujourd'hui, l'avantage de
l'ebXML Registry sur UDDI est qu'il inclue les données de
governance des Services Web (SW) dont a besoin la SOA.
Avantage réel qui remplace l'ambition d'origine du
framework ebXML de ne pas se contenter (cf. VendrEDI n°73) comme UDDI de la
description des services du CPP (Collaboration Partnership
Profile) mais aider à la conclusion d'un
Agreement entre partenaires, le CPA. Ambition qui
s'est révélée illusoire, en dehors de
Communautés déjà constituées.
Comme pour ebMS2 (cf. VendrEDI n°98), il y aurait alors un
paradoxe à voir des outils ebXML, abandonnant la perspective
d'une mise en place du framework prévu à
l'origine, se reconvertir au service du framework
concurrent, les SW.
Mais, à part Sun et sa Pragmatic
SOA qui inclue une offre combinée ebXML-UDDI, la
plupart des offreurs de plates-formes SOA s'en tiennent
toujours à UDDI seul : c'est le cas de Systinet comme de
BEA, IBM ou Microsoft. Même Oracle, longtemps soutien d'ebXML,
vient de passer, de même que BEA, un accord avec Systinet, qui
est le spécialiste de l'utilisation d'un UDDI
amélioré (cf. VendrEDI n°91) pour la gestion d'une
SOA interne couvrant l'ensemble du SI.
La perspective d'extension de
l'e-business B2B automatisé n'est donc pas celle d'un
registry-repository public, type CPP-CPA d'ebXML, mais,
plus modestement, celle des registres UDDI ou
ebXML pour la SOA interne qui s'articuleront prudemment, en
bottom up, avec ceux des partenaires de
business. L'accord sur les services à échanger
e
t leur
automatisation restant, pour l'essentiel, human, comme
l'était l'accord d'interchange des Communautés
de l'EDI traditionnel en Edifact. |
| Ce numéro 100 de VendrEDI a été adressé à 1993 abonnés Pour écrire |
| Tous les numéros de VendrEDI peuvent être téléchargés à http://www.actimum.com/acvendredi.htm |