| VendrEDI |  |
lettre de Claude Chiaramonti | ||
| sur les
données de l'échange électronique |
||||
| Numéro 82 27 août 2004 | ||||
|
Distribution,
Santé :
|
BPEL modélise
|
|
|
standardisations
sectorielles
|
le dialogue entre business et IT
|
|
Le consortium HL7, Health Level 7,
avec lequel Edisanté est en relation (cf VendrEDI n°79), a publié pour avis
la version 2.0 de son CDA, Clinical Document
Architecture. Ce CDA est un schéma
XML qui spécifie la structure et la sémantique des
échanges électroniques relatifs aux patients, tout en
admettant l'adjonction de données non prévues. L'objectif
de HL7, avec ce CDA, est de rendre les documents cliniques aussi
bien lisibles par le personnel de santé
que machine-readables, c'est à dire facilement
"parsables" et "processables", y compris par les nouveaux
téléphones portables. Les fonctionnalités du
CDA reflètent naturellement les impératifs "métiers"
de la Santé.
Autre exemple de standardisation sectorielle des langages-métiers, celui de la grande distribution avec la nouvelle version du standard EAN-UCC XML qui a été enrichie avec l'approche d'ensemble de la synchronisation des données (cf les VendrEDI n°59 et n°75). Là aussi, il s'agit de
fournir aux utilisateurs un langage international
e-business couvrant les transactions des processus
métiers : dans le cas de la distribution, alignement des
don-nées, planification, livraison, finance. L'application la
plus prometteuse du standard EAN-UCC
XML est la synchronisation des données,
amenant la suppres-sion des erreurs et litiges,
l'efficacité et un réseau international des
catalogues électroniques.
Cette approche sectorielle bottom up,
collant aux besoins des utilisateurs pour la
standardisation de leurs contenus-métiers", est en phase
avec le côté eXtensible de XML. La question posée
est alors de celle de l'intersectorialité : faut-il aller
plus loin que le métalangage XML qui la garantit presque
à lui seul ? Faut-il, de plus, rassembler les sémantiques
sectorielles dans un repository unique, du type Edifact ou ebXML ?
Pour quel objectif concret autre que purement esthétique,
ou de confort pour les développeurs de (rares) produits
intersectoriels ? Dans le cas des ERP, c'est le langage du coeur de
métier de chaque entreprise qu'ils
doivent gérer, les guides EANCOM dans le cas de la
distribution, mais pas forcément t
ous les répertoires
Edifact sur lesquels ces guides sont basés ! Et si une
entreprise "parle" santé ET distribution, il y a le
mapping avec XSLT ! |
Le Business Process Management (BPM)
doit pouvoir s'appuyer sur des outils communs aux analystes
d'un business process (BP) et aux développeurs de
logiciels. Et il faut modéliser un nouveau BP avant
de le confier aux développeurs IT. Mais comme un BP
relie de plus en plus souvent des entreprises différentes, le
modèle d'une entreprise doit pouvoir être ajusté
avec celui de ses partenaires. Ce que ne permet pas forcément
le recours à UML, considérée comme le standard de la
modélisation : bien qu'utilisant la même notation deux
modèles UML portant sur le même BP ne s'ajusteront
vraiment que s'ils ont été conçus ensemble. Cette
nécessaire "portabilité", d'une entreprise à
l'autre, de la modélisation d'un BP commun est justement, en
principe, un des avantages du BPEL (Business Process
Execution Language) qui est, lui, un langage complet
de description d'un processus et pas seulement une notation. Avec
l'aide d'un outil graphique, le BPEL peut comporter deux niveaux,
la description abstraite des opérations du BP et des
instructions exécutables. Et un BP écrit
en BPEL est plus facilement maintenable que s'il
était simplement écrit en Java ou C#.
Présenté à Oasis, notamment
par Microsoft, IBM et BEA, le projet de standard BPEL avait
un concurrent au W3C, le WSCI-WSCL, plus ambitieux : mais leur
complémentarité est souhaitée, en particulier
par Oracle qui vient de sortir un produit, eADT, qui est le
premier à être natif BPEL, dans le cadre de la
stratégie SOA, Services Web et grid computing
d'Oracle. D'autres parient aussi sur le BPEL, bien que
certains estiment qu'il faudra encore plus d'une année
avant qu'il soit complé-tement mûr et qu'il soit
très spécialisé sur des BP en mode Services
Web. Du coup, des vendeurs de produits de BPM s'appuient, en
attendant, sur BPMN (Business Process Modeling Notation)
qui est plus mature que BPEL mais, par contre, n'a pas
été conçu pour "orchestrer" des Services Web !
En tout cas, la portabilité d'outils de
BPM comme BPEL est censée permettre aux
businessmen de mettre en place et adapter rapidement leurs
BP grâce à un langage commun avec les
développeurs IT. On peut rêver à l'amélioration
de leur dialogue !
|
 |
Pour que "le message passe" il faut être d'accord
sur le sens des données Petit
Glossaire du B2Bfr
|
|
Bus interne ESB
|
Profil Microsoft :
|
|
|
pour la gare routière
SOA
|
|
tout pour les Services Web
!
|
|
L'intégration, interne et externe, est le
maître-mot et la préoccupation principale des grandes
entreprises du Fortune Top 500 pour améliorer leur
efficacité. L'intégration se décline
depuis quelque temps en loosely-coupled, Services
Web et SOA, architec-ture "orientée
services". Pour être branché, il faut maintenant y
ajouter un sigle : ESB, Enterprise Service Bus. Sans
équivalent français admis pour le moment, l'ESB
peut être traduit comme le "réseau urbain" d'autobus
assurant les connections internes du SI. L'ESB, concept
inventé et surtout diffusé par Gartner, est un
peu l'EAI ou le middleware de la SOA. Mais l'ESB peut
aussi contribuer à l'inté-gration externe de "banlieue",
par exemple avec des connections incluant l'adaptation des formats
entre ERP d'entreprises ou avec une communauté EDI.
Donc réseau léger, sans trop
d'infrastructure propre, extensible et adaptable à moindre
coût et en utilisant au passage les MOM (Message
Oriented Middle-ware) déjà en place. Les
fonctionnalités de réseau de l'ESB doivent être un
support natif des Services Web en XML, avec une communication
inter-applications en RPC synchrone aussi bien qu'en
messaging asynchrone, non seulement pour le bon
acheminement des messages mais aussi pour la gestion de la
communication des processus.
Et les offreurs ne s'y trompent pas et
ont compris que l'ESB devait être au coeur de leur offre. Si
Microsoft ne mentionne pas toujours l'ESB dans son offre "
orientée service", son prochain produit
Indigo peut déjà
être considéré comme un ESB. Et IBM, qui
travaillait sur l'ESB depuis l'année dernière, a
déjà placé l'ESB au centre de son offre
d'intégration.De même pour les autres offreurs de
l'integration software comme BEA, SeeBeyond, Cape
Clear etc. qui s'appuient, comme Sonic, sur les vues
de Gartner dans sa prévision concernant l'avenir de l'ESB
: "More than any other technological advance, the
transition of the core application platform infrastructure from
RPC-based to ESB-based will enable enterprises to take a major step
toward routine real-time-enterprise agility in their information
proce-ssing". Gartner prévoit que "the industry
transi-tion to messaging and ESB as
the core appli-cation platform infrastructure model will mark an
inflection point — triggering a new, massive wave of
innovation around businesses' use of their information resources,
capitalizing on the architecture of events. Pour Gartner cela
permet de dissiper les doutes sur "the critical role that IT
can play in strategic business differentiation"
|
Microsoft ne participe plus au Cefact-Onu
qui l'avait adoubé comme Standards Liaison Rapporteur
avec les instances de standardisation, dans le but de valider
l'apport d'ebXML comme une "version" des Services Web.
Malgré cela, Microsoft continue de militer pour une vision
standardisée de "services" pour lesquels il entend
bien garder à ses outils leur position de standards de
facto !
Le cessez-le-feu avec Sun (cf VendrEDI n°77) est ainsi suivi de
l'annonce pour la fin de cet été de la
Phase One d'une
collaboration portant sur l'inter-opérabilité de
leurs outils d'authentification. De même Microsoft et SAP
ont-ils annoncé comment leurs outils .Net et
NetWeaver allaient se combiner pour des Services Web
intégrés. Sans oublier le dégel des relations entre
Microsoft et Oracle.
La nécessité d'offrir aux
utilisateurs attentistes une image apaisée et
standardisée des Services Web conduit ainsi les grands
offreurs, avec Microsoft en tête, à une
réconciliation planétaire, à Oasis comme
au WS-I qui vient d'affiner son
Profile.
Microsoft entend profiter de cet
oécuménisme : par exemple pour relier par des
Services Web ses outils d'Office à des applications
métiers ou des ERP grâce à
Office Information Bridge
Framework. A noter également la prochaine version
2.0 de .Net, mieux alignée sur les standards des
services Web, dont elle devrait ainsi faciliter
l'implémentation.
Son souci de favoriser le développement
des Services Web sur lesquels il fonde sa stratégie conduit de
plus Microsoft à animer, avec d'autres offreurs, des
Web Services Protocol
Workshops pour rassembler des retours
d'expériences et proposer des spécifications
d'implémentation qui démontrent
l'interopérabilité des différents standards de la
série WS-* (cf VendrEDI n°77). L'objectif
étant de créer un co-operative environment.
D'autre part, Microsoft vient de publier, lui aussi, un
Devices Profile,
formé d'un core set de spécifica-tions pour
la mise en oeuvre de Services Web de base : "this
profile defines a minimal set of imple-mentation constraints to
enable secure Web Service messaging, discovery, description, and
eventing on resource-constrained end-points". De
manière plus générale, l'objectif de Microsoft est
de convaincre que sa stratégie de "service
orienta-tion" va enfin réconcilier IT managers
et business analysts. Sur cette orientation et son
rôle dans "your connected systems str
ategy",
voir
un exposé clair sur
l'intégration des systèmes, les standards des
Services Web et les outils de Microsoft ! |
| Ce numéro 82 de VendrEDI a été adressé à 1313 abonnés Pour écrire |
| Tous les numéros de VendrEDI peuvent être téléchargés à http://www.actimum.com/acvendredi.htm |