Bonjour,
 
Ci-dessous VendrEDI n° 83, toujours à imprimer pour un meilleur confort de lecture (imprimer les pages 2-3).
 
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 : contrairement aux dernières années (et tout en ayant bien noté les suggestions qui m'avaient été faites l'année dernière), je n'ai pas utilisé le mois d'août pour mettre à jour le "Petit Glossaire du B2Bfr", n'étant pas sûr que cela intéresse vraiment. Je le ferai néanmoins si des définitions manquantes ou des sigles à expliciter me sont signalés.
 
 
   VendrEDI   lettre de Claude Chiaramonti
 sur les données de
l'échange électronique
           Numéro 83      17 septembre 2004
   Les règles BRMS 
 
Services Web / SOA : 
   placent les métiers avant les TIC
prouver le ROI en marchant !
L'articulation entre métiers et TIC est un des enjeux de l'informatique, récurrent depuis les origines. C'est là que peut se jouer l'efficacité d'un SI. Le dialogue entre les métiers de l'entreprise et son informatique doit pouvoir s'appuyer sur un outil de modélisation type BPEL (cf VendrEDI n°82), mais d'abord sur une définition des règles de business auxquelles il sera fait référence dans un modèle. Ces règles de métier sont du type IF-THEN-ELSE, et ressemblent donc aux règles des langages de programmation. Sauf qu'elles sont exprimées en langage courant (anglais) et peuvent donc être facilement utilisées par les businessmen pour codifier la logique de leurs opérations et permettre ensuite aux dévelop-peurs de prendre la suite avec la logique de leurs langages de programmation. Qui peuvent alors respecter la logique des "fonctionnels" des métiers.
C'est l'objectif des outils de BRMS (Business Rules Management System) qui se répandent : à côté de sociétés spécialisées, Microsoft devrait inclure un "Business Rules Framework" dans la version 2004 de BizTalk. Les avantages d'un BRM se situent aussi bien au stade de la conception que de la maintenance. Plutôt que d'être pendu au téléphone, le côté business, une fois sa modélisation "réglée", peut passer commande au côté TIC qui peut passer aux tests et à la production du code. Et en cas de modification de ces régles des métiers, les fonctionnels compétents peuvent les traduire logiquement eux-mêmes, sans attendre la disponibi-lité des développeurs (mais avec peut-être, quand même, une certaine aide de leur part ;-). Si ça marche, le coût de conception et de maintenance sera réellement moindre et on peut espérer que les régles métiers seront bien implantées correctement. Mais, en fait, un BRMS a un domaine d'application utile à considérer avec précaution : d'une part les PME "mono-métier" n'en ont guère la justification, et d'autre part les ERP ou les CRM des grandes entreprises contiennent déjà, en principe, un outil de gestion des règles. En revanche, toute nouvelle application développée en entreprise justifie un BRMS, surtout si la nouvelle application doit rester autonome. Et mettre à plat les règles des métiers de l'entreprise peut, en soi, être parfois très utile !
 
Les alliances menées par Microsoft-IBM d'une part et Sun-Oracle d'autre part ont décidé de réconcilier leurs standards rivaux pour rassurer les utilisateurs quant à la mise en oeuvre des Services Web (SW) et de la SOA qui est à construire autour. On peut en déduire que ces grands offreurs en attendent un retour sur investissement (ROI). Et les utilisateurs ? Quels avantages peuvent-ils attendre des SW et de la SOA par rapport à leurs outils  qui marchent, EAI interne plus EDI externe ? Tout dépend des objectifs : s'il s'agit de connecter l'application A à l'application B, l'EAI ou l'EDI suffisent. S'il s'agit que A recherche et trouve B, puis surfe, le cas échéant, vers C, alors il faut recourir aux SW avec leur gamme de standards WS* et le profile WS-I.
Grâce à leur approche loosely coupled, les SW autorisent, en effet, des liaisons multiples en interne ou sur le Web, pour échanger des données par messages (REST, SOAP yc variante ebXML) qui suivent des scénarios self describing (WSDL) pouvant être automatically discovered (UDDI).
Chacun des éléments d'une définition complète des SW comporte des bénéfices à attendre, à la fois du côté business et du côté TI. Ces bénéfices sont analysés dans un document du CBDi, qui insiste sur l'indépendance par rapport aux outils propriétaires, à l'intérêt d'une même méthodologie pour l'intégration interne et externe (Web ou Extranet), au moindre coût du changement et de la maintenance comme à la rapidité de réaction du SI aux demandes du business. Enfin, les  TPE devraient pouvoir être reliées au global business à moindre coût, les SW jouant le rôle d'API unique, remplaçant EAI, EDI, EFI, liaisons aux portails etc. Quant à la SOA, vision d'ensemble de l'architecture du SI, elle doit d'abord permettre de vérifier que les SW sont généralisables et qu'ils correspondent bien aux besoins réels.
Si la marche vers les SW et la SOA ne semble donc ne pas être seulement dans l'intérêt des offreurs, reste aux utilisateurs à définir vite les données et les services pour lesquels il ne sera bientôt plus possible de ne pas offrir sans attendre un SW. Sans trop vouloir faire ressortir à l'avance un ROI qui ne se démontrera qu'en marchant, avec les autres, et pas après.
 
Pour que "le message passe" il faut être d'accord sur le sens des données   Petit Glossaire du B2Bfr

  Mainframe et SW :
 
  SW automatisés :  
     relier l'ancien et le nouveau ! 
 
    d'abord la sémantique
L'orientation de tous les grands offreurs vers un apaisement bienvenu de leurs conflits sur les standards des Services Web (SW) vise à répondre à l'attentisme des utilisateurs qui, en attendant ce cessez-le-feu, en sont restés à ce qui marche, et notamment à l'EDI traditionnel. Et à propos de ce qui marche, en plus de standards réconciliés, les utilisateurs ont aussi besoin de comprendre comment les SW pourront se raccorder à leurs applications existantes, traitées par leurs gros ordinateurs, ou à des fonctions gérées directement par ces  mainframes. D'où l'intérêt commun aux offreurs d'outils de SW et aux offreurs de mainframes à expliquer ensemble comment relier ces  deux types d'outils. Selon eux, SW et main-frames doivent être considérés comme complé-mentaires dans le cadre de l'architecture SOA qui va gouverner les SI orientés services (cf. les VendrEDI n°75 et n°80).
Non seulement les SW sont l'outil d'avenir de l'EAI (Enterprise Application Integration), mais ils présentent aussi un grand avantage pour une intégration directe Web-to-mainframe : les SW permettent non seulement un accès aux données, mais aussi aux application processing or func-tionality. Ce que l'EDI traditionnel fait moins bien, faute en particulier de SOAP et d'un langage de description des services comme  WSDL dont Edifact n'a pas les fonctionnalités.
Mais architecture "orientée services" ne signifie pas que toutes les applications doivent être ouvertes : ce n'est pas utile pour toutes. De plus la qualité des services offerts par les "grosses bécanes" doit être protégée et ne doit pas être compromise par une "ouverture". Avant de brancher directement des SW sur le mainframe, des ESB seront utilisés (cf VendrEDI n°82). Et l'intégration progressive, avec XML, avec les SW, avec la publication sur un portail etc. est une marche raisonnée vers la SOA, et non un "grand soir". Avec une "feuille de route" claire : choisir les applications éligibles, définir le sous-ensemble de leurs données à transporter vers une autre application, vers un portail ou sur le Web, en déduire le schéma XML, correspondant et implémenter les outils WSDL et SOAP nécessaires.
En fait, les vraies difficultés ne seront pas techniques mais humaines : la culture des services informatiques quelquefois barricadés autour de leur gros ordinateur n'est pas celle des Services Web, dont la culture devrait mieux se partager entre TIC et responsables métiers et aussi mieux relier l'ancien et le nouveau dans les TIC elles-mêmes. 
 
Le succès des Services Web (SW) dépend de la solution de problèmes tels que reliability, sécurité, orchestration et liens avec les applications.  Mais le problème le plus difficile à résoudre, comme d'habitude, est celui de leur sémantique, c'est à dire de leur description standardisée, comprise de la même manière par les fournisseurs et les clients de ces services. Car, sans sémantique, l'interopérabilité n'est qu'une simple connectivité. Et la difficulté d'une sémantique standardisée est d'autant plus grande quand il s'agit de rendre automatiques, sans interfaces précodées, la recherche et l'exécution d'un service complexe ! C'est le même type de diffi-culté qu'a cherché à résoudre Google et surtout le Semantic Web, d'où sa convergence avec les SW (cf VendrEDI n°67) dans le recours aux onto-lologies. Une ontologie, en l'occurrence, est un moyen de spécifier la structure d'un domaine de connaissance dans une formal logic designed for machine processing, basée sur une terminologie communément admise (en anglais). Et pour que les SW puissent être "découverts" automatiquement d'un domaine à l'autre, si possible sans intervention humaine, il faut que des outils basés sur les mêmes standards permettent de relier logiquement leurs diverses ontologies. A ce prix, les SW pourront un jour remplacer avantageusement l'EDI !
Un standard est aujourd'hui proposé : OWL-S, basé sur RDF et complémentaire de WSDL pour la description d'un SW (on peut également mentionner un autre outil, WSMO, basé sur F-Logic et Dublin Core). OWL-S devrait pouvoir automatiser les tâches successives du SW : discovery, invocation, composition and interoperation et bientôt execu-tion monitoring. L'ontologie relative à l'exécution de ces tâches permet de répondre à trois questions : que fait le service ? comment fonctionne-t-il ? com-ment  y accéder ? Les réponses à ces questions étant processables par un service-seeking agent pouvant avoir été mandaté par une application. Et si le service  doit être invoqué de manière répétitive, on retrouve un scénario EDI...
Au total, avec OWL-S, les SW disposent de l'outil qui manquait à ebXML pour la description des profiles CPP et la mise en oeuvre automatisée des CPA. De même, manquait aux core components sémantiques ebXML la possibilité offerte par RDF/OWL d'enregistrer et "processer"  les relations des concepts entre eux. Avec OWL-S, les SW seront à la fois l'EDI classique automa-tisant les relations entre applications et l'EDI ouvert à l'heure du Semantic Web.
Ce numéro 83 de VendrEDI a été adressé à 1351 abonnés      Pour écrire    
Tous les numéros de VendrEDI peuvent être téléchargés à  http://www.actimum.com/acvendredi.htm