Bonjour,
 
J'espère que vous avez passé de bonnes vacances !
 
Avec un peu de retard pour des lectures d'été, deux adresses pour des textes en français signalés par Eric van der Vlist :
 
    - une introduction à XML et à son usage avec XSLT, très facile à lire, avec des exemples :
http://formats-ouverts.org/blog/2004/08/03/76-LectureDeteComprendreLeFormatOuvertXml
 
    - une synthèse très complète sur les très nombreux standards de la SOA et des Services Web :  http://www.orchestranetworks.com/fr/soa/standardsws.cfm
(avec un triptyque sur les pratiques de base de la SOA et des Services Web à télécharger gratuitement : http://www.orchestranetworks.com/fr/soa/triptyque.cfm)
 
Ci-dessous VendrEDI n° 82. Comme d'habitude, me signaler par retour de courrier des adresses de nouveaux lecteurs ou votre souhait de ne plus recevoir VendrEDI.
 
Cordialement
 
Claude Chiaramonti
 
PS : ci-après, commentaire reçu de Bernard Jeanneau (Galia, cf VendrEDI n°77) sur l'article relatif à la RFID du dernier n° de VendrEDI (VendrEDI n°81) :

"Cher Monsieur Chiaramonti,

Je réagis à votre article au sujet de la RFID.
 
Une puce est seulement un porteur d'information, comme le code à barres. Comme les symbologies pour le code à barres, il va y avoir plusieurs normes d'étiquettes radio-fréquence. De même que toutes les symbologies linéaires sont formées de barres et d'espaces, toutes les étiquette radio-fréquence sont constituées d'une petite surface de silicium gravée, les transpondeurs de ferrite bobinée.
 
L'EPC est l'alternative radio-fréquence au code à barres Gencod (pour la grande distribution française). Une alternative enrichie puisqu'il est prévu d'ajouter d'autres données au code article habituel, tel le n° de lot ou la DLUO ou la DLV.
 
Ce qui est en cours de normalisation en RFID, c'est l'AIR INTERFACE, ou protocole de transmission. On aurait pu croire qu'il y aurait 3 ou 4 grandes "gammes de fréquences". Non car chaque "fondeur" de puce désire garder ses brevets. Pour une même fréquence il pourra y avoir plusieurs protocoles, malheureusement, comme le 13,56 MHz. Et il n'y aura pas d'étiquette radio-fréquence à tout faire : chaque application aura la sienne. Et encore, elle pourra être différente en fonction de l'environnement (métal,  liquides) !
 
En ce moment, on voit un grand métier comme la Distribution s'organiser pour mettre en place la RFID. L'automobile y a déjà pensé, sans faire de pub : comment déverrouille-t-on les portes sans les toucher ? Comment surveille-t-on déjà dans les véhicules haut de gamme, la pression de chaque pneu, à distance ? Comment la fonction anti-démarrage est-elle assurée ? Dans l'industrie, des étiquettes RFID sont déjà largement utilisées sans qu'on en fasse grand bruit : même en fabrication, et ce depuis plus de 15 ans. Comment, en effet, plusieurs types ou modèles différents peuvent-ils être assemblés sur une même ligne et que tout arrive bien au bord de chaîne, dans le bon ordre, sans générer de confusion dans les pièces ?
 
En logistique il peut, en effet, paraître intéressant d'identifier une palette ou un conteneur par un tag. Rappelons-nous que "identifier n'est pas gérer" ! Aujourd'hui les systèmes d'identification usine relèvent le n° de l'étiquette, opération encore manuelle, qui est la clé d'accès à l'information reçue par EDI.. Demain on peut envisager que cette intervention elle-même soit automatisée : une nouvelle étape de la mécanisation.
 
Sur quoi les transporteurs sont-ils en train de travailler ? Il serait intéressant qu'ils associent leurs gros clients ! L'automobile en fait partie. Il existe une norme pour l'identification des conteneurs par RFID, mais peu utilisée, à ce qu'il paraît : en Europe seul le port de Rotterdam serait équipé pour les lire ; en France celui du Havre penserait à s'équiper. Toujours est-il que le parc de conteneurs équipés RFID serait assez faible, m'a-t-on dit.
 
Enfin, il faut à nouveau bien situer les enjeux et définir les besoins : de quelles informations a-t-on REELLEMENT besoin, HORS EDI ? Car n'oublions pas que la RFID ne remplacera PAS l'EDI. Au mieux ce ne peut être qu'un back-up : il faut la lire pour connaître les données de l'entité sur laquelle elle est apposée, alors qu'en EDI on sait ce que contient un conteneur dès qu'il entame le processus d'expédition."
 
Bernard Jeanneau
 
Chef de Projets Logistiques et Identification Automatique chez Galia
 
 
   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 tous 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 strategy", 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