| VendrEDI |  |
lettre de Claude Chiaramonti | ||
| sur les
données de l'échange électronique |
||||
| Numéro 91 11 mars 2005 | ||||
|
UDDI et Systinet :
|
L'interopérabilité
|
|
|
registre de gestion de la
SOA
|
de Bill Gates à la sémantique
|
|
La V3 d'UDDI vient d'être
adoptée par Oasis comme étant un
standard. Avec un U qui ne signifie plus
Universal et la prétention à UN seul
Registry, mais plutôt simplement
le Uniform recherché par un
standard. Cela suffit, d'une
part aux entreprises pour se bâtir
leur propre registry standardisé, ce qui
n'est pas rien pour
assurer le succès d'une SOA
(Service Oriented Architecture) et d'autre part pour
faciliter en même temps le développement de SW ouverts,
en fédérant des répertoires internes
homogènes. UDDI peut aussi être le
registry prévu par
ebXML,
le VP Systinet du groupe UDDI étant
co-éditeur de la note pour ce mapping. Mais il
ne faut pas pour autant surcharger UDDI en y "adressant" tout le
SI, des business processes aux databases,
quand c'est d'abord pour les Services Web qu'est fait
UDDI. De même, si la version UDDI V3 peut contenir des
informations contractuelles ou de sécu-rité, elle
est toujours faite d'abord pour "pointer" simplement sur
des informations, et n'est pas censée résoudre tout le
management des services.
Au total, pour D. Butler, VP Marketing de
Systinet : "A registry without UDDI is not going to work in an
SOA. But where it lacks is the ability to map the business into the
overall SOA model". Et un client de Systinet se
félicite de pouvoir maîtriser, grâce à la
fonction de base d'UDDI, le dévelop-pement
impétueux de ses Services Web : "We feel the Systinet
Registry is the cornerstone of our SOA infrastructure, and all else
should follow".
Offreur spécialisé, Systinet a
été le premier à utiliser UDDI V3 pour la
SOA avec des fonctionnalités complémentaires.
Systinet Registry 5.5 inclut ainsi, pour tous les services de
l'entreprise (Web ou non), federation, security, data
validation, life-cycle services and quality of service
management. Des implémentations sont en cours pour
partager les informations sur les services en interne et en
externe, de la SOA à l'EDI. C'est pour, selon Thomas Erickson,
President & CEO de Systinet, passer de la
simple application integration aux services that
provide business interoperability. Et, prévoyant le
développement en Europe des SW et de la SOA pour une
architecture that allows for an agile on demand business,
Systinet vient, fin 2004, d'ouvrir un
bureau à Paris et à Amsterdam.
|
L'interopérabilité doit être
complète et se décliner suivant les sept couches du
modèle OSI, depuis la connectique des tuyaux jusqu'à la
sémantique, c'est à dire le sens des données
transmises. Au niveau des réseaux, pas de problème, on
peut téléphoner en Chine. Reste les
couches supérieures. Pour tous les utilisateurs, la
couche la plus importante, puisque dépendant d'eux seuls, est
la plus élevée, la séman-tique, couvrant, pour
chaque métier, vocabulaire et business process. En
dessous, les utilisateurs pré-fèrent que
l'interopérabilité reste une boîte noire
assurée par les fournisseurs de logiciels : c'est, sans
doute, là surtout que Microsoft a bâti son
succès, en garantissant l'articulation entre ses
différents outils. Plutôt qu'une hypothétique baisse
des prix gràce à la concurrence, 95% des utilisateurs
préfèrent avoir la garantie d'interopéralité de
la gamme d'outils de Microsoft. Mais on peut comprendre que des
déve-loppeurs soient choqués par une telle attitude
!
En tout cas, Bill Gates vient d'enfoncer
le clou dans un
article sur ce thème :
"building software that is interoperable by design", pour
mettre en garde contre l'Open source qui, selon
lui, ne peut offrir la même garantie. D'autres, comme
Oracle, ont un argumentaire voisin. Un des points sur lequel
insiste Bill Gates est que Microsoft se préoccupe tout
autant de l'interopérabilité avec
ses concurrents, IBM, Sun, BEA et autres, en promouvant
XML et les standards de l'architecture des Services Web.
Dans une
lettre ouverte à Bill Gates
le CBDi Forum lui en donne acte, mais estime que les standards
du WS-* ne concernent que la partie
émergée de l'iceberg. Effectivement, le loosely
coupled des logiciels, grâce à leur
componentization, et "l'orien-tation
services" (SOA) pour les SI ne peuvent que faciliter
l'interopérabilité. Mais à plus ou moins long terme.
Dans l'immédiat, la face cachée de l'iceberg, c'est la
rigidité et la complexité des applications existantes qui
fait hésiter les entreprises à restructurer leur SI. Et,
avec l'interoperability by design pour demain, la
lettre ouverte suggère à Microsoft de contribuer aussi
à simplifier la legacy.
Mais sans oublier, à cette occasion,
q
ue la
séman-tique de l'entreprise n'est pas une cerise sur le
gâteau mais, au contraire, la première étape
(cf. VendrEDI n°90). |
 |
Pour que "le message passe" il faut être d'accord
sur le sens des données Petit
Glossaire du B2Bfr
|
|
Les e-Catalogues
:
|
|
2005 : SOA et SW !
|
|
1 seul langage avec n langues
?
|
|
Mais fin de la route pour l'ESB ?
|
|
La normalisation européenne doit
concilier le multi-linguisme européen avec la
nécessité d'avoir un seul langage pour
l'interopérabilité sémantique. Mieux vendre
les produits mondiaux en les présentant dans la langue du
consommateur (cf. VendrEDI n°86). Mais avec d'abord, si
possible, une sémantique com-mune, terminologie,
classification et modèles, pour la présentation de
ces produits mondiaux, ce qui ne pourra que faciliter en
amont la "synchronisation" des données entre
fournisseurs et clients.
C'est le double objectif de l'atelier
ouvert
CEN/ISSS WS/eCAT sur le
Multilingual eCataloguing and eClassification in
eBusiness. Sont déjà en cours d'adoption
définitive deux
CWA (CEN Workshop
Agreement) qui portent sur l'harmonisation de la
terminologie et des modèles du e-Cataloguing. A
côté de spécialistes du multilinguisme ou des
données industrielles, des organisations
sectorielles, pétrole US
PIDX, ou grande distribution GS1,
ont participé à ces recommandations. Le but est, en
principe, d'éviter duplications and inefficiencies in
business processes. Bien que l'on ne voit pas bien
l'intérêt d'avoir un modèle commun aux attributs
chimiques d'un produit pétrolier, aux tailles de chaussures ou
aux dates de fraîcheur de produits alimentaires, dont les
business processes ne se croiseront sans doute jamais
!
La prochaine
étape sera pourtant une
Gen-ePDC, Generic Product
Description and Classification, outil horizontal pour
aller, autant que possible, vers une harmonisation de la
terminologie et des schémas de classification verticaux ou
locaux en vigueur. Pour aboutir à proposer une norme
à l'ISO, complé-tant la norme 13584 PLIB
sur les données relatives aux composants des produits
industriels.
Avec le même souci, le CEN/ISSS lance une
workshop
ADNOM pour un réseau de
nomencla-tures administratives pouvant aboutir à proposer des
harmonisations des terminologies parmi les pays et les langues en
Europe. Là, on peut comprendre que la construction
européenne impose cette approche unificatrice puisqu'il y aura
des réglementations qui se baseront sur ces nomenclatures !
Mais là aussi, il faudra bien concilier "n langues et 1
langage" de classification ! Mais alors, pourquoi ne pas accorder
autant de respect aux particularismes des "n
langa-ges métiers" ? Le métalangage XML,
eXtensible, a justement le double intérêt
d'être déclinab
le en lan-gages parallèles tout en ayant tous les outils
nécessaires, XSLT, RDF et OWL pour
bâtir l'harmonisation sémantique. |
En plus de XML, puis des Services
Web (SW) déjà hype des années
précédentes, les buzzwords à la mode
en 2004 ont été la SOA et l'ESB, Enterprise
Service Bus (VendrEDI n°82). Et les gourous de la
plupart des offreurs suivent Gartner et n'ont aucun doute
sur l'intérêt de "vendre" la SOA aux utilisa-teurs. Avec
quelques
nuances de la part d'IBM. Ce
qui veut dire que 2005 sera l'année où l'on parlera
beaucoup de SOA ! Par contre, il n'y a pas la même
unanimité parmi les offreurs et les analystes concernant
l'ESB. Pour certains, souvent offreurs spécialisés,
l'ESB est incontournable : pour Sonic Software,
l'
ESB est le A de SOA, c'est
à dire en fait sa véritable architecture ; pour Iona
l'extensibilité de son
produit ESB est un atout.
Donc, pour eux,
The Bus stops here, et on a
quand même intérêt à y monter ! Au contraire,
pour bien d'autres, l'ESB est inutile, les
SW étant suffisants, et End of the road for ESB ! Enfin, pour
certains :
You Don’t Need To Queue To Get On
The ESB car les
choses ne seraient pas très claires. Par exemple,
Gartner, "inventeur" du concept ESB
craint qu'en mettant simplement une couche d'ESB par-ci par-là
sur le messaging existant, on finisse par avoir plusieurs
ESB qu'il faudra coordonner etc. D'ailleurs, pour IBM, il faut
démystifier l'ESB, qui n'est
pas un "produit" à acheter, mais simplement l'objectif
d'alléger les
endpoints des applications en renforcant le
bus de transport des données entre ces
endpoints. En partant de l'ensemble de
l'existant, y compris les SW et les
autres formats de messaging, EDI ou ebXML.
En laissant de côté l'ESB, et en
essayant aussi de démystifier la SOA, les
gourous prévoient que 2005 sera
l'année du management de la SOA en liaison avec les SW
et le BPEL, grâce, en particulier,
à l'achèvement à Oasis du
standard WSDM.
En 2004, les ERP/CRM vendors (SAP,
Oracle etc.) ont adapté leur plate-forme
à l'approche "service" interne de la SOA. Mais les
business processes touchant l'entreprise étendue
à ses partenaires, et SOA et SW devant rapprocher IT
et business, les SW, une fois
sécurisés, devront bien à la fois être
internes et externalisés sur le Web, en mode EDI. Ce pour quoi
les SW ont d'ailleurs été conçus, comme leur
nom l'indique. C'est ce que
prévoit IBM comme
étape pour des SOA interopérables.
Mais l'EDI utilisant des formats
traditionnels comme Edifact
sera toujours vivant ! Et comme
pour les langages XML, les premiers de l'EDI seront les
derniers pour les SW ! |
| Ce numéro 91 de VendrEDI a été adressé à 1362 abonnés Pour écrire |
| Tous les numéros de VendrEDI peuvent être téléchargés à http://www.actimum.com/acvendredi.htm |