Méthodes et Langages du Commerce Electronique

ITCE NFE 102 Année 2013-2014! Méthodes et Langages du Commerce Electronique F.-Y. Villemin (f-yv@cnam.fr) http://dept25.cnam.fr/itce Plan! Besoins du commerce électronique! L EDI! ebxml! Les Web Services! SOAP! UDDI! WSDL! La méthodologie UMM D'après des textes de Beetschen, Nicolas Jan, Jan Ondrus (HEC Lausanne), O. Perrin, Ph. Bedu (EDF), Rachid Benelfellah et documents EDIFrance et ebxml.org 2! Besoins du Commerce Electronique Faire collaborer toutes les compagnies de toutes les industries Créer des processus d affaire fondés sur des documents intelligents Fournir des moyens aux partenaires d affaire pour rendre leurs systèmes interopérables Compagnie A ACHAT commande réception paiement Banque A paiement Sélection, comparaison,... Commande ou statistiques Livraison Facture Clearing confirmation Compagnie B VENTE fourniture livraison facturation Banque B avant vente vente production & distribution Après vente 3! Business Content Instance Specialized Business Content Universal Business Content Business Content Format Definition Directory / Registry Core XML Standards Network Transport Model conceptuel du B2B Repository Messaging Trading Partner Agreement Service Oriented Architectures Backend Integration Business Process Instance Specialized Business Processes Universal Business Processes Process Description Language Service Description Language S e c u r i t y Management Business Conceptual Model (Definitions, format, structure, and choreography) Technical Conceptual Model (Standards, protocols and tools) 4!

Echange de Données Informatisées (EDI) Objectifs : Medium de transmission électronique Communication directe entre applications Messages formatés et structurés selon un standard convenu Deux standards : ANSI X12 aux Etats-Unis EDIFACT en Europe Problèmes : Limité aux grandes organisations Coût de développement élevé Seules 1% des compagnies peuvent se l'offrir Pas de communication en dehors de la chaîne d approvisionnement Documents non auto-descriptifs et non structurés Deux approches:! Store and forward! Point to point EDI 5! 6! XML electronic business XML (ebxml) EDI ebxml ebxml a été lancée en juin 1999 et les spécifications ont été finalisées en mai 2001 ebxml a été développé par 4500 personnes représentant plus de 2000 organisations de 150 pays OASIS : Organization for the Advancement of Structured Information Standards Organisation à but non lucratif dont l activité principale est de définir des standards garantissant une bonne compatibilité des systèmes UN/CEFACT : United Nations Centre for the Facilitation of Procedures and Practices for Administration, Commerce and Transport Département des Nations Unis pour le développement du commerce électronique Mission ebxml : "ebxml enables anyone, anywhere to do business with anyone else over the Internet" (ebxml permet à n importe qui, n importe où de faire des affaires avec quelqu un d autre sur l Internet) 7! 8!

ebxml consiste en : ebxml EDI vs ebxml L EDI et ebxml ont été développés par UN/EDIFACT! une manière standard d échanger des messages d affaire L EDI coûte très cher et seules les grandes entreprises peuvent le mettre en œuvre! une ligne directrice pour les relations d échange! une communication des données avec un langage commun L EDI est un système centralisé contrairement à ebxml ebxml est complémentaire à L EDI! définition standardisée des processus d affaire 9! 10! Modèle de ebxml Phase d implantation ebxml fonctionne en trois phases : 1 implantation 2 Découverte/Négociation 3 Exécution 11! 12!

Phase de négociation Phase de négociation 13! 14! Phase de transaction Architecture de ebxml 15! 16!

Vue fonctionnelle de ebxml Spécifications ebxml 17! 18! Spécifications ebxml Core Component : structures de données réutilisables de bas niveau Exemples : party, address, phone, date, devise instancié dans plusieurs types d échanges d informations utilisé pour définir les business process et les information models facilite l interopérabilité entre des système différents Business Process : décrit les interfaces du processus identifie quelle donnée doit être présente pour répondre aux demandes des deux partenaires d affaire Exemples: Délivrer un service ou Acheter un produit Trading Partner Profile : Spécifications ebxml CPP (Collaboration Protocol Profile) Défini les capacités d affaire d une compagnie dans un format standard et portable (Profile général, BP, protocoles supportés ) CPA (Collaboration Protocol Agreement) Décrit clairement les éléments et les mécanismes des transactions conduits entre deux compagnies (Contrat) ebxml Registry & Repository (Registry = index et Repository = sauvegarde) : Modèle Distribué dont les nœuds sont maintenus par des groupes industriels, des communautés d affaire (places de marchés, bourses) ou des compagnies individuelles 19! 20!

Registry & Repository Spécifications ebxml Transport, Routing & Packaging : OASIS or other official site Registry of Registries 1 Repository Repository Repository Registry Search App Repository Registry 2 Repository Registry A global search may go through potentially thousands of registries each of which may in turn have thousands of repositories. Repository Original document in intended format including multimedia attachments Return list of hits plus all repositories that were not accessed. From there the user could link to the document of choice. 3 Repository! défini une méthode pour échanger des messages d affaire électroniques, qui ne dépende pas du protocole de communication, qui soit fiable et sécurisée! le message envelope peut contenir des payloads de différents formats! Possibilité d intégration avec des systèmes qui n utilisent pas une syntaxe XML! contient un ensemble de protocoles et de services incluant SMTP, HTTP! actuellement SOAP sur HTTP 21! 22! ebxml Message Service Conclusions Modulaire et facile à implémenter => possibilité de passer de EDI à ebxml car moins cher et plus facile à implémenter Pour les entreprises de toute taille => possibilité de trouver de nouveaux partenaires même pour les PME ebxml repose sur le standard XML (gratuité, mondial,...) => favorise les pays en voie de développement UN/CEFACT et OASIS travaille sur le standard mais pas sur les logiciels et les services utilisant ebxml => spécification d un Framework global de collaboration d affaire Reste à définir un modèle de programmation standard des Web Services 23! 24!

SOAP SOAP : Simple Object Access Protocol SOAP 1.1! Un moyen de faire communiquer des applications par RPC en utilisant HTTP! Proposé à W3C en 2000 par UserLand, Ariba, Commerce One, Compaq, Developmentor, HP, IBM, IONA, Lotus, Microsoft et SAP SOAP 1.2! Travaux W3C! Protocole de transmission de messages en XML SOAP SOAP est un protocole minimal pour faire du RPC basé sur XML SOAP est indépendant d'un protocole de transport particulier C est le IIOP de Corba ou le JRMP de RMI Structure : 1. Une déclaration XML (optionnelle) 2. Une Enveloppe SOAP (l'élément racine) <SOAP- ENV:Envelope> qui est composée de:! Un en-tête SOAP (optionnel) <SOAP-!!ENV:Header>!! Un corps SOAP <SOAP-ENV:Body> 25! 26! SOAP Un message SOAP valide est un document XML au bon format. Le message doit avoir la forme suivante:! Une déclaration XML (optionnelle)! Une Enveloppe SOAP (l'élément racine) qui est composée de: " Une En-tête SOAP (optionnel : infos nécessaires à l'interprétation du message) " Un Corps SOAP (données du message) # Une section d erreur SOAP SOAP message HTTP headers SOAP Envelope SOAP header headers SOAP body method call & data SOAP Message complet Entête standard HTTP et entête SOAP HTTP Enveloppe Entête Entête individuelle Corps contenant les appels de méthodes SOAP Appel de méthode et description en XML des données La structure des messages SOAP 27! 28!

SOAP Exemple <Envelope> est la racine! <Header>, <Body> et <Fault> sont les enfants :! <?xml version="1.0" encoding="utf-8" standalone="no"?>! <soap:envelope xmlns:soap="http://schemas.xmlsoap.org/soap/ envelope/" soap:encodingstyle=!!!"http://schemas.xmlsoap.org/soap/encoding/">!!<soap:header>!!... Header information...!!</soap:header>!!<soap:body>!!... Body information...!!<soap:fault>!...fault information...!!</soap:fault>! </soap:body>! </soap:envelope> SOAP Enveloppe <SOAP-ENV:Envelope... > décrit le style d'encodage de ce message SOAP suit le schéma défini dans http://schemas.xmlsoap.org/soap/encoding Contient les définitions de namespaces. <SOAP-ENV:Envelope! xmlns:soapenv=!!!"http://schemas.xmlsoap.org/soap/envelope/"! xmlns:xsi=!!!"http://www.w3.org/2001/xmlschema-instance"! xmlns:xsd=!!!"http://www.w3.org/ 2001 /XMLSchema">! </SOAP-ENV:Envelope>! 29! 30! SOAP Entête Mécanisme pour étendre un message de façon décentralisée et modulaire, sans connaissance a priori des parties de la communication.! Typiquement authentification, transaction,! Règles : " Identifié par un namespace et un nom local " Les enfants immédiats qualifiés par le namespace. 31! SOAP Entête Deux attributs particuliers utilisés pour indiquer comment et par qui l entrée est traitée mustunderstand : Indiquer qu une entrée est obligatoire <SOAP-ENV:Header>! <t:transaction xmlns:t="some-uri" SOAP- ENV:mustUnderstand="1">! 5! </t:transaction>! </SOAP-ENV:Header>!! Actor : Indiquer qui peut utiliser l'entête ; par défaut : l ultime <SOAP-ENV:Header>! <m:local xmlns:m ="http://www.cnam.fr/local/"! soap:actor= http://www.cnam.fr/appli>!!<m:language> fr </m:language>!!</m:local>! </soap:header> 32!

Body Soap SOAP section d erreur Mécanisme simple pour échanger les informations avec l ultime receveur du message.! Typiquement appels marshalling RPC calls et des rapports d erreur! Une entrée du body est identifiée par un namespace et un nom local <SOAP-ENV:Body>! <ns1:doubleanintegerresponse! xmlns:ns1="urn:messoapservices"! SOAP-ENV:encodingStyle=!!!!"http://schemas.xmlsoap.org/soap/encoding/">! <return xsi:type="xsd:int">30</return>! </ns1:doubleanintegerresponse>! </SOAP-ENV:Body>! Utilisée pour porter les erreurs ou les statuts d erreur d un message Doit apparaître comme une entrée du body Ne doit pas apparaître plus d une fois Sous éléments : faultcode Identifier l erreur faultstring Explication de l erreur : <env:body>! <env:fault>! <faultcode><value>env:versionmismatch</value>! </faultcode>! <faultstring>version Mismatch</faultstring>! </env:fault>! </env:body>! 33! 34! Graphes SOAP L information est traitée comme un graphe constitué de nœuds intermédiaires ou terminaux et de liens entre ces nœuds Il existe des règles d encodage de ces graphes Valeurs simples! XML schema Built-in datatypes et dérivés! Ou SOAP-ENC pour des éléments indépendants d un type hétérogène Valeurs composites Tableaux et structures WSDL Langage de définition de Web Services (comparable à l'idl de CORBA pour les objets) Basé entièrement sur XML Standard W3C (Initiative IBM et Microsoft) Actuellement WSDL 1.1 Définition de l interface, de l URL et du port du Web Service. Utilise le système de typage de XML Schéma Description des signatures d un service web (méthodes, types des paramètres) 35! 36!

WSDL Les balises d'un fichier WSDL décrivent ce qui est nécessaire à l'appel d'un service Web via SOAP :! types : les types utilisés! message : la structure d un message SOAP échangé! porttype : les opérations de l'interface du service web! operation : une opération réalisée par le service web! binding : le lien entre un protocole (http) et un porttype! service : le service comme un ensemble de ports! port : le port pour accéder à des opérations WSDL Exemple :! <definitions>! <documentation> </documentation>! <import/> importation de document! <types> définition des types complexes... </types>! <message> définition des messages... </message>! <porttype> définition des opérations...!!!<operation> définition des entrées - sorties...!!!</operation>! </porttype>! <partnerlinktype> définition interactions entre services! </partnerlinktype>! </définitions>! 37! 38! UDDI UDDI (Universal Description, Discovery, and Integration) :! fournit un annuaire permettant de retrouver des web services sur le même principe que les pages jaunes! UDDI implique que les différents fournisseurs de web services parviennent à s'entendre sur la définition de critères communs et de catégories "métier" bien déterminées! mise en œuvre dans le cadre de places de marché collaboratives ou dans des domaines très spécifiques! Microsoft et IBM proposent des solutions plus légères à mettre en œuvre telles que WS-Inspection (Web Services Inspection Language, WSIL) UDDI Enregistrer séparément les descriptions des Compagnies et les descriptions des services Développeurs, éditeurs de logiciels, organismes de standardisation enregistrent des types de services Les Compagnies enregistrent les services qu'elles supportent White pages (informations générales) Yellow pages (catégories de services) Green pages (business rules) White Pages Yellow Pages Green Pages 39! 40!

UDDI Pages blanches : noms, adresses, contacts, identifiants, des entreprises enregistrées. Ces informations sont décrites dans des entités de type Business Entity. Cette description inclut des informations de catégorisation permettant de faire des recherches spécifiques dépendant du métier de l entreprise Pages jaunes : détails sur le métier de l entreprise, les services qu elle propose. Ces informations sont décrites dans des entités de type Business Service Pages vertes : informations techniques sur les services proposés. Les pages vertes incluent des références vers les spécifications des services Web, et les détails nécessaires à l utilisation de ces services. Ces informations sont décrites dans deux documents : un Binding Template, et un Technology Model (tmodel). UDDI Worldwide directory d entreprises, services, produits... White pages, Yellow pages, Green pages Green pages Namespace pour décrire la manière d utiliser les services, etc. Identifiant de l auteur de la publication du service Unique identifiant (tmodelkey) du service sur les registres Accès aux web services Bindings déclarés dans les répertoires par exemple, association (tmodelkey, URL) Répertoires UDDI, moteurs de recherche xmethods.net, soapware.org, salcentral.com, soap-wrc.com, 41! 42! UDDI : le modèle de données UDDI 0!n Provider: Information sur l entité proposant le service Service: Informations descriptives sur la famille de produits offerts tmodel: Descriptions des spécifications des services 1!n Document XML BusinessEntity! businesskey! name! URL! description! contacts! businessservices! identifierbag! categorybag! Contact! phone! address! email! BusinessService! servicekey! tmodelkey! name! description! bindingtemplates! 0!n Binding: Informations techniques sur le point d entrée du service et sur les specs de construction du service Les Bindings contiennent les références aux tmodels. Ces références désignent les spécifications de l interface pour un service. keyedreference! tmodelkey! keyname! keyvalue!! keyedreference! tmodelkey! keyname! keyvalue!! 43! 44!

Inquiry API Trouver find_business! find_service! find_binding! find_tmodel! Plus de détails get_businessdetail! get_servicedetail! get_bindingdetail! get_tmodeldetail! UDDI Publishers API Enregistrer save_business! save_service! save_binding! save_tmodel! Détruire delete_business! delete_service! delete_binding! delete_tmodel! Sécurité get_authtoken! discard_authtoken! UDDI En pratique les clés de classification et d'identification devraient être gérées et fournies par des agences mondiales Les informations du niveau "yellow pages" de UDDI sont typiquement fondées sur deux standards :! NAICS (the North American Industry Classification System), projet des gouvernements du Canada, du Mexique et des US : http:// www.naics.com!! UNSPSC (the Universal Standard Products and Services Classification), efforts conjoints de Dun & Bradstreet et du Programme de Développement des Nations Unies pour une Unification des Classifications : http://www.unspsc.org 45! 46! UMM La Méthodologie de Modélisation Unifiée (UMM) utilise :! UML pour la représentation des processus d'affaires! XML comme format d'échanges pour les transactions commerciales La méthode UMM intègre plusieurs modèles répondant à des objectifs spécifiques dont : Le Metamodel (ontologique) des informations et des processus commerciaux définit précisément le vocabulaire de modélisation Les modèles de transactions commerciales définissent précisément la structure des interactions du processus commercial UMM Le "metamodel" est articulé autour de vues : Le Business Operation Map (BOM) metamodel : Division de processus commerciaux en secteurs et catégories d'activités Le Business Requirements View (BRV) metamodel : Vue d'un modèle d'information et de processus commerciaux qui capture les scénarios de Cas d'utilisation, les entrées, les productions, les contraintes et des limites du système pour des transactions commerciales et leurs corrélations Le Business Transaction View (BTV) metamodel : Vue d'un modèle d'information et de processus commerciaux qui capture la sémantique des entités d'information commerciales ainsi que leur flux d'échange entre les rôles qu'ils occupent dans les secteurs d'activité Le Business Service View (BSV) metamodel : Vue d'un modèle d'information et de processus commerciaux qui caractérise le réseau constitué par les agents et leurs échanges de messages, comme des interactions nécessaires pour exécuter et valider un processus commercial 47! 48!

UMM UMM Processus de la méthodologie unifiée de modélisation UMM Vues du "Metamodel" 49! 50! Modèle de processus et de données d'affaires Model Driven Architecture (MDA) Principe : séparer les spécifications fonctionnelles des spécifications de l'implantation sur une plate-forme donnée => interopérabilité des applications MDA : Ensemble de techniques de modélisation et de transformation CIM (Computation Independant model) modèles indépendants de calcul : décrit les flux et les actions sur le système PIM (plateform independant model) modèles indépendants des platesformes : décrit les traitements orientés métier PM (plateform model) modèles des plates-formes décrit une architecture technique (plusieurs par projet) PSM (plateform dependant model) modèles dépendants des platesformes : décrit les détails techniques liés à l'implantation 51! (D'après A. Essabri, A. Koudimba & G. Pape, ISTIA)! 52!

Analyse : flux et organisation Model Driven Architecture (MDA) organisation CIM flux CIM Flux Exemple de CIM Analyse : traitement PIM Traitements PM Plateforme organisation Conception PSM Modèle spécifique à la plateforme 53! 54! Raffinements successifs des PIM indépendamment de tout plate-forme Etape 1 Exemple de PIM Exemple de PM Etape 2 55! 56!

Exemple de PSM Ontologies Les ontologies sont des sortes de dictionnaires intelligents décrivant :! le domaine du discours! les concepts avec leurs relations L ontologie est définie pour un objectif donné et exprime un point de vue partagé par une communauté The Enterprise Ontology définit une activité comme étant décomposable en sous activités, réalisée par un exécutant et nécessitant des ressources [www.aiai.ed.ac.uk/project/ enterprise/] 57! 58! Ontologies MULECO 59!