|
| |||||||||||
|
|||||||||||
|
L’EDI est un procédé permettant de transférer directement d’ordinateur à ordinateur des données structurées, suivant une syntaxe et des messages préétablis via des réseaux de télécommunications.
EDI (Document au format Word) EDI (Présentation Powerpoint) 2.3 Réseaux à Valeur Ajoutée (RVA) 2.5 EDI sur Internet : EDI-INT protocoles AS1 , AS2, AS3 2.6 Limites de l’EDI Conventionnel 2.6.1 Mise en place d’un traducteur spécifique. 2.6.2 Complexité et lisibilité des documents 3.1 BPSS ( Business Process Specification Schema ) 3.3 CPP ( Collaboration protocol profile ) 3.4 CPA ( Collaboration protocol aggreement ) 3.6 ebMS : ebXML Messaging service 3.7 Scenario de mise en Œuvre de ebXML. 3.8 Comparaison EDI conventionnel et ebXML 4.3 UDDI (Universal Description, Discovery and Integration) 4.6 Architecture des Web Services 4.7 Nouveaux outils de développement 4.8 Analogies entre Web Services et ebXML
1 IntroductionLes entreprises ont un réel besoin d’échanger des informations avec leurs partenaires d’affaires. Ces informations peuvent correspondre à des données commerciales (commande, facture, bon de livraison,…) ou techniques (plans, schémas,…). Pour communiquer, les moyens traditionnels peuvent être utilisés (téléphone, fax, courrier) mais ces moyens nécessitent une intervention humaine importante. Afin de réduire les temps de traitements des différents processus métiers, il a été pensé d’échanger des données de façon informatisée : EDI (Echange de données informatisées ou Electronic Data Interchange).
L’EDI est un procédé permettant de transférer directement d’ordinateur à ordinateur des données structurées, suivant une syntaxe et des messages préétablis via des réseaux de télécommunications.
L’intérêt économique a poussé à la mise en place de systèmes communicants. L’EDI permet en effet de réaliser des économies par
Figure 1.1 Comparatif de gain de temps
L’échange de données informatisée remonte aux années 60 dans
un format propriétaire. Un langage commun s’est révélé nécessaire pour
permettre l’ouverture à un plus grand nombre de partenaires. Les années 80 ont
vus apparaître deux normes pour la structure des fichiers : X12 (ANSI) pour
les Etats Unis et EDIFACT (Nations Unies) pour le reste du monde. L’arrivée
d’Internet et du format XML ont apportés de nouveaux outils de communication et
d’échange. Au début des années 2000 sont ainsi apparus le framework ebXML et
les Web Services. 2 L’EDI « Conventionnel »
L’EDI « conventionnel » peut être résumé comme un échange asynchrone de fichiers formatés (EDIFACT ou X12) entre deux partenaires.
Avant de pouvoir échanger des documents, les partenaires doivent se mettre d’accord sur leur contenu et le format (EDIFACT ou X12). 2.1 EDIFACTLes messages EDIFACT sont composés de segments. Les segments sont composés de données composites. Une donnée composite est formée de donnée élémentaires.
Tous ces éléments doivent obéir à des règles (Interchange)
Par analogie avec un texte en Français, une donnée composite est un mot, un segment est un phrase, un message est un paragraphe et tous ces éléments doivent suivre des règles de grammaire.
Figure 2.1 EDIFACT 2.2 L’Architecture EDI
Les données des entreprises sont gérées au sein d’applications propriétaires ( Bases de données, application de gestion, ERP ). Il est nécessaires de paramétrer les Services EDI de façon à ce qu’ils puissent interagir avec les données propriétaires.
Figure 2.2 Architecture EDI
Le schéma ci-dessous présente les Services EDI.
Gestion des échanges
Figure 2.3 Services EDI
2.2.1 TraductionFonction traduisant les données du format propriétaire de l’entreprise au format EDIFACT. Plusieurs méthodes peuvent être appliquées ( fichier pivot, API, connexion base de données, connecteur ERP). Le fichier à générer ou à traduire dépend du système d’information de l’entreprise et des accords avec chaque destinataire. Chaque partenaire produit un fichier avec un contenu propre. Pour chaque nouveau document, il convient donc d’écrire un traducteur spécifique. La mise en place de la fonction de traduction est la partie la plus longue et coûteuse de la mise en place d’un système EDI conventionnel. 2.2.2 TélécommunicationL’échange se fait toujours de façon asynchrone. La transmission des fichiers peut se faire sans télécommunication ( cd, disquette, clé usb,…). Tout type de télécommunication est possible (RTC, FTP, SMTP, X25, liaison spécialisée,…) 2.2.3 SécuritéLes services de sécurité doivent assurer :
2.2.4 ArchivageL’archivage concerne tous les messages émis ou reçus ainsi que tous les rejets d’échange permettant un traitement différé. 2.2.5 Gestion des échangesCe module prend en charge l’administration et l’exploitation des échanges depuis la traduction jusqu’à l’envoi. Ce module met à jour des journaux d’émission et de réception des messages. 2.3 Réseaux à Valeur Ajoutée (RVA)
Devant la complexité des systèmes EDI, nombre d’entreprises choisissent de faire appel à des RVA pour leur déléguer la gestion des échanges EDI. Le rôle du RVA est similaire à celui de la poste dans la remise des documents.
L’avantage principal des RVA vient du fait qu’après avoir mis en place une communication avec le RVA, une entreprise peut échanger des documents avec tous les membres du RVA sans avoir à définir de nouvelles interfaces de connexion telles que nouvel FTP à configurer, nouvel accès RTC, … Ce qui a pour effet de simplifier le processus de mise en relation.
Les fichiers au format EDIFACT sont mis dans des enveloppes de transport contenant l’adresse du destinataire.
Du fait des volumes importants de transactions qu’ils doivent gérer, les RVA atteignent la taille critique leur permettant de mettre en place des infrastructures robustes.
Les RVA peuvent aussi se charger de la définition des contenus des documents lorsque deux nouveaux partenaires décident de rentrer en relation.
RVA
Figure 2.4 RVA 2.4 Le WEB EDI.
La plupart des RVA et des logiciels EDI intègrent maintenant la possibilité d’interfacer le système EDI avec une interface WEB – EDI. Cette solution plutôt destinée aux petits partenaires, permet de convertir les documents EDIFACT en page HTML pour la bonne lecture dans un navigateur web en réception et propose des formulaires Web qui seront traduits en EDIFACT pour l’émission.
Figure 2.5 WEB EDI
Les WEB EDI sont accessibles aux PME mais elles vont avoir besoin d’un accès et d’un logiciel différent pour chaque partenaire commercial.
De plus, les utilisateurs du WEB EDI doivent agir par des opérations manuelles. Il leur est en outre difficile de réutiliser les données vu qu’elles sont situées sur le serveur.
2.5 EDI sur Internet : EDI-INT protocoles AS1 , AS2, AS3L’EDI conventionnel n’est pas lié à un protocole particulier. L’arrivée d’internet n’avait pas provoqué de raz de marée du fait du manque de standards interopérable au niveau de la sécurité, de la reliabilité et de la qualité de service. Cette situation a changé avec l’arrivée des standards AS1 et AS2 de l’IETF (Internet Engineering Task Foce). Ces standards définissent comment utiliser MIME (Multipurpose Internet Mail Extensions) pour envelopper des documents EDI. L’intégrité et la confidentialité des données sont assurées grâce à des techniques standards (PGP et S/MIME).
Le but recherché lors de la confection de ces standards était de ne plus avoir besoin de RVA pour la transmissions de documents et donc de réduire les coûts de transmissions associés. Malgré des exemples de migrations de RVA vers EDI-INT de la part de plusieurs sociétés (par exemple TF1), le raz de marée de migration n’a pas eu lieu. Beaucoup d’entreprises ne veulent pas perdre le support technique des RVA ou alors le coût de la migration a été jugé comme trop important par rapport aux gains escomptés sur l’adoption de la technologie.
Ironiquement, de plus en plus de RVA proposent des connections EDI-INT afin de proposer une solution de connexion aux partenaires occasionnels des membres du réseau. AS1 se base sur SMTP , AS2 sur http et AS3 sur FTP.
Figure 2.6 AS2 2.6 Limites de l’EDI Conventionnel2.6.1 Mise en place d’un traducteur spécifique.La principale limite de l’EDI conventionnel vient dans la nécessité de mettre en place un traducteur non seulement pour chaque partenaire mais aussi pour chaque type de message échangé. Ces coûts d’initialisation sont rédhibitoires avec des partenaires occasionnels. Pour cette raison, l’EDI conventionnel est très peu utilisé chez les PME qui n’ont pas les moyens humains et techniques de mettre en place une solution EDI.
De plus, tout changement de format suite à un nouveau processus entre partenaire a des conséquences importantes puisqu’il requiert une modification au niveau du traducteur.
2.6.2 Complexité et lisibilité des documents
Un document en EDIFACT est difficilement lisible par un non expert. Les normes X12 et Edifact ont voulu rendre le format le plus compact possible de façon à réduire les coûts de transmissions. Les documents résultants sont peu lisibles et complexes. En cas de problèmes de formatage, seul l’intervention d’un expert pourra débloquer la situation.
3 ebXML
ebXML est né de l’expertise conjointe de UN/CEFACT (expert dans l’EDI Conventionel) et de OASIS (Expert XML). Par rapport à EDIFACT, le système va beaucoup plus loin et ebXML spécifie une architecture complète dédiée au eCommerce.
Figure 3.1 Architecture ebXML
ebXML produit ainsi plusieurs standards :
3.1 BPSS ( Business Process Specification Schema )
BPSS est un mécanisme standard pour décrire les processus d’affaires ( Business processes ).
Les business processes décrivent le rôle des partenaires, leurs relations, leurs responsabilités.
La méthode UML permet de décrire ces processus en confectionnant des diagrammes qui peuvent être traduits en documents XML conforme au métamodèle ebXML.
Les business processes décrivent une « chorégraphie » en incorporant tous les dialogues possibles en fonction des évènements normaux ou non qui peuvent se produire. Par exemple, la réponse à une commande peut différer si le fournisseur est en rupture de stock.
Généralement une grande entreprise met au point plusieurs processus d’affaires correspondant aux différentes facette de son métier : Un ou plusieurs processus pour les achats, pour les déclarations fiscales et sociales, des processus pour les encaissements et les règlements, …
3.2 CC ( Core Components )
Les Core Components (CC) définissent un standard pour la description des documents. Les données élémentaires identifient les concepts du monde réel des affaires ainsi que les relations entre les différents concepts.
L’assemblage de données élémentaires constituent des objets d’affaires ( par exemple un entête de commande). 3.3 CPP ( Collaboration protocol profile )
Ce CPP comporte : 1. Les processus d’affaires supportés. 2. Les rôles en relation avec les processus d’affaire que l’utilisateur peut assumer. Par exemple le rôle d’acheteur ou de vendeur dans un processus d’achat. 3. Les Business Service Interface (utilisés pour la communication entre 2 partenaires) 4. Les messages échangés ( Définis avec des Core Components ) 5. Les configurations techniques des protocoles de transport, de sécurité et de codage.
3.4 CPA ( Collaboration protocol aggreement )
Le CPA décrit la mise en œuvre de la collaboration entre deux partenaires à partir de leurs CPP respectifs.
Le CPA sélectionne les types de documents à échanger , les options de transports, la sécurisation, …
Pour qu’un CPA puisse être généré, il faut réunir des business processes en commun ( et les messages associés), au moins un protocole en commun ainsi qu’un niveau minimum de sécurité commun. Si ces différents points ne sont pas convergents, il ne peut y avoir de possibilité d’ échanges.
Le CPA se présente sous la forme d’un document qui montre l’interaction entre deux CPP. Le CPA contient les besoins d’interfaces de messagerie ainsi que les détails de mise en œuvre issus de l’agrément mutuel sur les processus d’affaires retenus par les partenaires pour la conduite de leurs échanges.
3.5 Registry & Repository
Le registry stocke tous les CPP et CPA des entreprises partenaires ainsi que les modèles de documents à échanger. Le registry peut être consulté par un partenaire soit pour trouver les CPP d’une société particulière ou pour trouver un service particulier.
3.6 ebMS : ebXML Messaging service3.6.1 ebms2ebMS est le protocole d’échange de messages de ebXML basé sur SOAP. ebMS permet les échanges synchrones et asynchrones. ebMS prend en compte les engagements définis dans le CPA.
Les éléments de sécurité sont
ebMS permet le transport de tous les formats des messages, cela sans restriction sur le contenu.
Le diagramme ci-dessous donne la structure logique des modules fonctionnels de l’architecture de messagerie d’ebXML.
Le schéma montre les relations de dépendance entre les différentes parties de l’architecture et donc leurs enchaînements pour la constitution d’un échange entre l’application XML et la couche transport.
Un Message ebXML consiste en
Une enveloppe de transport du type SMTP, http, …
Figure 3.2 ebMS2
3.6.2 ebMS3Une version 3 de ebMS est sortie fin 2006. Si elle assure une convergence vers les standards des Web services, elle a des problèmes de compatibilité avec la version ebms 2.0.
ebMS 3.0 est enfin interopérable avec les Web Services ebMS comprend notemment les functions
suivantes : L’introduction de WS-Reliability permettra de faire des échanges par Pull et Push. Cela devrait favoriser l’adoption de ebXML auprès des PME qui avaient été réticentes à adopter ebms2. En effet dans ebms2, les communications sont de type « push » et communiquent de serveur à serveur qui doivent donc avoir une adresse IP fixe. Les utilisateurs de ces solutions n’ont donc pu être que des entreprises ayant une taille suffisante pour l’achat de serveurs.
L’introduction du PULL s’avère donc importante pour
l’adoption de ebXML auprès des PME.
Figure 3.3 Fonctionnalité PULL de ebms3
Figure 3.4 Structure d’un message utilisateur en ebms3
Figure 3.5 structure
d’un message signal en ebms3 3.7 Scenario de mise en Œuvre de ebXML.
Voici un exemple d’échange entre deux partenaires.
1) La société A créé et enregistre son CPP ( Collaboration Protocol Profile ) dans le registry. Le CPP décrit les capacités et contraintes ebXML de la société X ( contraintes en terme de données, de business processes, de capacité d’échange, de sécurisation, etc…. ).
2) La société B crée et enregistre son CPP dans le registry.
3) A partir des CPP de A et de B, un CPA ( Collaboration Protocol Agreement ) peut être proposé.
4) Les Business System Interface (BSI) et ebMS peuvent être configurés à partir des informations contenues dans le CPA.
5) L’échange des documents via ebms est alors possible.
Figure 3.6 Echange
avec ebXML 3.8 Comparaison EDI conventionnel et ebXML
Figure 3.7
Comparaison ebXML <> EDI 4 Les WEB Services
Les Web Services sont des applications qui relient des programmes, des objets, des bases de données ou des processus d’affaires à l’aide de XML et de protocoles Internet standards. Les Web Services sont des compléments aux programmes et applications existantes, développées à l’aide de langages tel que Visual Basic, C, C++, C# (C sharp), Java ou autre, et servent de pont pour que ces programmes communiquent entre eux.
Les Web Services définissent non seulement les données transmises entre deux applications, mais aussi comment traiter ces données et les relier à l’interne et à l’externe d’une application logicielle sous-jacente.
Les Web Services sont nés afin d’apporter une solution pour faire collaborer des systèmes hétérogènes. Ils n’ont pas été conçus spécifiquement dans l’optique d’échange de documents mais plutôt comme un nouveau moyen d’envisager le système d’information de l’entreprise (SOA Service Oriented Architecture).
Les services Web sont basés sur un ensemble de normes qui décrivent la syntaxe et la sémantique des communications logicielles : XML fournit la syntaxe commune pour la représentation des données, le protocole SOAP (Simple Object Access Protocol) fournit la sémantique pour l'échange de données, et le langage WSDL (Web Services Description Language) fournit un mécanisme permettant de décrire les possibilités d'un service Web. UDDI (Universal Description Discovery and Integration) fournit l’annuaire où un service peut être publié et trouvé.
Dans leur version initiale, les Web Services n’offrent pas les même fonctionnalités que ebXML, cependant, ils peuvent être étendus par les normes WS-* . Par exemple WS-BPEL 2.0 pour la description des collaborations entre Webservices, WS-ReliableMessaging pour la fiabilité des remises des messages. La somme de plusieurs de ces normes apportent des fonctionnalités équivalentes au framework ebXML.
4.1 SOAPLe standard SOAP définit trois éléments composant un message : l’enveloppe, l’entête du message et le corps du message. L’enveloppe définit le cadre pour décrire ce qui est dans le message et comment le traiter. Les règles d’encodages sont placées dans l’en-tête et servent à exprimer et définir le mécanisme de représentation des données. Le corps du message permet de transmettre les requêtes et les réponses entre les systèmes.
4.2 WSDLWSDL est un langage permettant de décrire les Web Services et les données attendues par ces Web Services. L’utilité de WSDL est donc de décrire et publier le format et les protocoles d’un Web Service de manière homogène par l’utilisation de XML. Cela permettra au requérant et à l’émetteur d’un service de comprendre les données qui seront échangées.
4.3 UDDI (Universal Description, Discovery and Integration)UDDI définit les mécanismes permettant de répertorier des Web Services. Ce standard régit donc l’information relative à la publication, la découverte et l’utilisation d’un Web Service. En fait, UDDI définit un registre des Web Services sous un format XML. Ce registre peut être public, privé ou partagé. Tout comme WSDL, UDDI est une création du trio IBM, Microsoft et Ariba. Au départ ils ont développé la spécification puis ont rassemblé quelques 300 entreprises sous le chapeau de l’organisation UDDI.org afin de continuer le développement et de légitimer leurs efforts. UDDI a été déposé à OASIS18 (Organization for the Advancement of Structured Information Standards) en juillet 200219 afin de permettre à cet organisme de standardisation de parrainer la spécification et d’en assurer son développement technique de façon indépendante. OASIS a officialisé son implication en créant le OASIS UDDI Specification Technical Committee en août 2002. En septembre 2002, il existait trois registres publics (aussi appeler UBR ou Universel Business Registry), avec chacun son noeud de registre d’affaires et son noeud de tests. Ils sont entretenus et offerts par IBM, Microsoft et SAP20. Les registres privés et partagés peuvent être logés soit à l’intérieur des coupe-feu, soit hors coupe-feu grâce à certains intermédiaires21. Ces différents registres pourront aussi interagir entre eux. Déjà, les propriétaires des registres publiques s’échangent des informations à des fins de redondance. Ils pourront aussi interagir avec d’autres registres privés ou partagés auxquels ils auront accès. Une entreprise choisit le répertoire dans lequel elle désire 4.4 Les normes WS-*La simplification des normes WS-* est devenue nécessaire à cause de leur prolifération. Certaines normes peuvent être concurrentes en fonction de l’entreprise qui l’a proposé. Et l’implémentation des normes peut différer et rendre difficile l’interopérabilité entre Web Services suivant le fabriquant du logiciel.
Figure 4.1 Les normes WS-*
4.4.1 Les profiles WS-IAfin d’assurer l’interopérabilité entre implémentations des normes, une organisation a été fondée : WS-I . Cette organisation produit des spécifications et des règles à respecter afin de rendre ses Web Services interopérables.
Figure 4.2 les profiles de WS-I
L’arrivée du WS-I Basic Profile 1.0 a pu résoudre plus de 200 problèmes d'interopérabilité.
4.4.1.1 Exemple de conditions pour la conformité WS-Basic Profile:– “Un message doit être arrangé en série avec UTF-8 ou UTF-16” – “Un message doit être envoyé avec HTTP/1.1 ou HTTP/1.0” – “Un message ne doit pas contenir d'élément enfant de soap:Envelope après l'élément soap:Body” – “Le service doit utiliser le code HTTP “500 Internal Server Error” si la réponse est un message SOAP fault” – “Une description [WSDL] peux utiliser tous les composants de XML Schema 1.0”
4.4.2 WS-BPEL 2.0WS-BPEL étend les possibilités des WEB services en permettant l’orchestration de plusieurs web services. Cela est assurée par l’introduction d’éléments conditions ( if, then else), de boucles, séquences et exécutions en parallèles.
La figure ci-dessous montre un exemple d’un service implémenté en process BPEL. A l’intérieur du process, une requête à un autre service est envoyée. Le service attend ensuite l’accusé de réception puis la réponse.
Figure 4.3 Web service avec BPEL
4.5 Normes VerticalesL'accord sur les normes de services Web horizontales, telles que XML, SOAP et l'architecture WS-*, ont jeté les bases des normes de services Web verticales. Ce dessous, un détail de PRESTO (de la DGPME) mais citons également les projets : AIAG (Automotive Industry Action Group), EPCglobal, HL7 (Health Level Seven)
4.5.1 Sémantique des messagesLes Web Services fournissent une solution pour le transport de messages entre deux partenaires. Cependant, ils ne décrivent pas comment interpréter les messages transmis. Il appartient donc aux partenaires de s’entendre sur cette sémantique. Pour illustrer ce problème, prenons l’exemple d’un individu qui désirer effectuer un voyage. Pour ce faire, il voudra acheter tous les services nécessaires à ce périple sur la page Web de son agence de voyage. Chaque service est fourni par un fournisseur distinct, qui désigne l’individu différemment. Ainsi :
• le transporteur désigne l’individu comme un « passager », • l’hôtelier désigne l’individu comme un « invité », • le marchand de valise désigne l’individu comme un « client », • l’assureur désigne l’individu comme un « assuré » et • l’hôpital (fournissant un vaccin) désigne l’individu comme un « patient ».
Or, il s’agit toujours du même individu.
Cette limitation peut être réduite par les standards verticaux de définition de dictionnaires XML.
A noter que UBL constitue une approche horizontale pour définir des documents d’affaires standard.
4.5.2 PRESTOPresto est le PRotocole d’Echange STandard Ouvert de l’administration spécifié par la DGPME ( Direction Générale de la Modernisation de l’Etat). PRESTO définit un ensemble de standards et protocoles à respecter entre les web services des administrations. Ces normes respectent le Basic Profile de WS-I et définissent ainsi un subset de ces normes.
La solution des Web Services a été adopté après avoir étudié deux solution d’échange de documents propriétaires ( FAST et eLink ) ainsi que ebXML Messaging Service. La solution ebMS2 a été écartée car jugée trop complexe et non pérenne vu que la version ebms3 était annoncée comme non compatible avec la version ebms2.
Figure 4.4 PRESTO
4.6 Architecture des Web Services
Figure 4.5 Architecture des Web Services 4.7 Nouveaux outils de développementActuellement, la complexité des normes WS-* constitue un frein au développement massifs des Web Services. L’arrivée des outils WCF (Windows Communication Foundation) et WWF (Windows Workflow foundation)
Figure 4.6 le WCF
La grande nouveauté du WCF est de séparer la partie « Code » de la partie « plomberie ». Ainsi le Binding est une description du protocole (technique) d’échange de message à utiliser Transport : HTTP/HTTPS, TCP, MSMQ, custom, … Encodage: text, binary, MTOM, custom, … Sécurité (Encryption / Authentification) : X509, Kerberos, … Fiabilité, Transaction, Meta-data … Le Binding est maintenant placé dans un fichier de configuration qui peut être mis à jour via une IHM. La conséquence est que le Binding peut être facilement modifié sans intervention sur le code du Web Service.
4.8 Analogies entre Web Services et ebXML
Figure 4.7 Analogie entre Web Services et ebXML 5 Conclusion
Bien que limité au simple transfert de documents l’EDI « Conventionnel » a encore de beaux jours devant lui. Les systèmes et les normes mises en place sont robustes et matures. L’arrivée des protocoles de communications fiables tels que AS1, AS2 n’ont pas vu de fuite massive des RVA du fait du faible retour sur investissement et des fonctions de support et expertise assurés par les RVA.
Bien que très attractive, la solution ebXML n’a pas encore été largement adoptée dans son ensemble. En France, avec le programme TIC 2010, plusieurs projets ebXML ont vu le jour tels que GESFIM ( Gestion Electronique et Sécurisation du Fret International Multimodal ). La sortie de ebMS 3 devrait également aider à l’adoption de ce standard chez les PME.
Les web-services avec les normes WS-* ont d’abord été freinés par leur manque d’interopérabilité. Cette restriction devrait disparaître grâce aux profiles fournis par le WS-I. Actuellement, le frein principal à la mise en place des Web services à grande échelle est la complexité de l’ensemble des spécifications WS-*. Ces problèmes de programmation pourraient se voir fortement réduites avec l’arrivée de MCF ( microsoft communication foundation ) qui est le nouvel outil de Microsoft pour l’écriture de web services. L’idée de ce framework de développement est séparer la partie métier de la partie message ( ws-security, ws-reliablemessaging, … ). Le développeur ne s’occupe que de l’écriture de code métier du web service et ce sont par exemple les équipes systèmes qui vont définir les paramètres dans un fichier de configuration qui peut être mis à jour via une IHM conviviale. Ces nouveaux outils devraient permettre une plus large adoption des WEB Services.
Les différences entre WEB Services et ebXML portent sur la finalité de leurs applications. ebXML oriente plutôt vers les échanges de documents et en cela, couvre le domaine de l’EDI Conventionnel Il gère potentiellement des échanges rapides type « fil de l’eau » entre partenaires avec une dynamique de réponse tout aussi rapide pour les accusés de réception techniques. L’idée consiste à proposer une couche d’échange entre des applications traditionnelles. L’approche des Web Services prend directement appui sur le système d’information de l’entreprise et donc nécessite une réelle révision de ce dernier.
Les critères de choix entre l’une et l’autre des solutions peuvent être les suivants :
Si les échanges sont de type « documents » alimentant des applications existantes, la solution recommandée serait plutôt ebXML. Si les besoins portent sur une ré ingénierie de processus pour apporter des fonctionnalités nouvelles, les Web Services semblent plus adaptés.
Avec l’arrivée de ebMS 3.0 , ebXML et Web Services sont enfin interoperable. Plutôt que d’opposer ces solutions, il convient plutôt de les considérer comme complémentaires. Les Web Services pourraient plutôt être considérés comme solution interne au sein d’une entreprise alors que ebXML pourrait être adopté comme norme d’échange avec l’extérieur. Ceci afin d’éviter une refonte lourde du système d’information de l’entreprise. 6 Bibliographie et Références
Charmot C., L’échange de données Informatisé(EDI) , Que sais je ? n° 3321, Presses Universitaires de France, Paris, 1997.
Chiu E., ebXML Simplified, John Wiley & Son, 2002.
Gibb B., Damodaran S., ebXML Concepts and Application, Wiley Publishing Inc, 2003.
Kadima H., Monfort V., Les WEB Services, Dunod, Paris, 2003.
Langlois M., Faverio. D, Lesourd M., XML dans les échanges électroniques, Lavoisier, 2005.
Weerawarana S., Cubera F., Leymann F., Storey T., Ferguson D., Web Services Platform Architecture,Prentice Hall PTR, 2006.
Ressources Web:
Web service interoperability Organisation. WS-I est responsable des Profiles à respecter pour l’interoperabilité entre Web Services.
Le site de OASIS (Organization for the Advancement of Structured Information Standards )
| |||||||||||
 |
 |
Accueil