Méthodes et Langages du Commerce Electronique

(1)

ITCE NFE 102 Année 2013-2014 !

Méthodes et Langages du Commerce Electronique

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

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

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

commande ACHAT

réception paiement

Compagnie A

fourniture VENTE

livraison facturation

Compagnie B

Banque A Clearing Banque B

Sélection, comparaison, ...

Commande ou statistiques Livraison

Facture

paiement confirmation

avant vente

vente

production & distribution

Après vente

Model conceptuel du B2B

Management

S e c u r i t y

Core XML Standards

Backend Integration Service Oriented Architectures Network Transport

Business Conceptual Model

(Definitions, format, structure, and choreography)

Technical Conceptual

Model (Standards, protocols and

tools) Universal Business Processes

Specialized Business Processes Business Process Instance

Universal Business Content Specialized Business Content

Business Content Instance

Messaging

Service Description Language Repository

Directory / Registry

Business Content Format Definition Process Description Language

Trading Partner Agreement

(2)

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

EDI

Deux approches:

!  Store and forward

!  Point to point

electronic business XML (ebXML)

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

XML EDI

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

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

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)

(3)

ebXML ebXML consiste en :

! 

une manière standard d ʼ échanger des messages d ʼ affaire

! 

une ligne directrice pour les relations d ʼ échange

! 

une communication des données avec un langage commun

! 

définition standardisée des processus d ʼ affaire

EDI vs ebXML

L ʼ EDI et ebXML ont été développés par UN/EDIFACT L ʼ EDI coûte très cher et seules les grandes

entreprises peuvent le mettre en œuvre

L ʼ EDI est un système centralisé contrairement à ebXML

ebXML est complémentaire à L ʼ EDI

Modèle de ebXML

implantation 1

Découverte/Négociation 2

Exécution 3

ebXML fonctionne en trois phases :

Phase d’implantation

(4)

Phase de négociation

Phase de transaction

Architecture de ebXML

(5)

Vue fonctionnelle de ebXML

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”

Spécifications ebXML

Trading Partner Profile :

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

(6)

Registry & Repository

Original document in intended format including multimedia attachments Registry of

Registries

Repository Search

App

Repository

…

OASIS or other official site

Return list of hits plus all repositories that were not accessed. From there the user could link to the document of choice.

1

2

3

Repository Registry

Registry

Repository

Repository Repository Repository

…

Registry

…

A global search may go through potentially thousands of registries each of which may in turn have thousands of repositories.

Spécifications ebXML Transport, Routing & Packaging :

!  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

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

(7)

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>

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

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

SOAP

(8)

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>!

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.

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>

(9)

Body Soap

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>!

SOAP section d ʼ erreur

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>!

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)

(10)

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>!

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

White Pages Yellow Pages Green Pages

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)

(11)

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, …

Provider: Information sur l’entité proposant le service

Service: Informations

descriptives sur la famille de produits offerts

Binding: Informations techniques sur le point d’entrée du service et sur les specs de construction du service

tModel: Descriptions des spécifications des services

Les Bindings contiennent les références aux tModels.

Ces références désignent les spécifications de lʼinterface pour un service.

0!n 0!n

1!n

UDDI : le modèle de données UDDI

Document XML

BusinessEntity!

businessKey!

name!

URL!

description!

contacts!

businessServices!

identifierBag!

categoryBag!

Contact!

phone!

address!

email!

BusinessService!

serviceKey!

tModelKey!

name!

description!

bindingTemplates!

keyedReference!

tModelKey!

keyName!

keyValue!

!

keyedReference!

tModelKey!

keyName!

keyValue!

!

(12)

UDDI

Inquiry API Trouver

find_business!

find_service!

find_binding!

find_tModel!

Plus de détails

get_businessDetail!

get_serviceDetail!

get_bindingDetail!

get_tModelDetail!

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

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 comme^rcial

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

(13)

UMM

Vues du "Metamodel"

UMM

Processus de la méthodologie unifiée de modélisation UMM

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 plates- formes :

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 plates- formes :

décrit les détails techniques liés à l'implantation

(14)

Model Driven Architecture (MDA)

PIM Traitements

PM Plateforme

PSM

Modèle spécifique à la plateforme Analyse :

traitement

Conception Analyse : flux et organisation

CIM organisation

CIM flux

Exemple de CIM Flux

organisation

Raffinements successifs des PIM indépendamment de tout plate-forme

Etape 1

Etape 2

Exemple de PIM

Exemple de PM

(15)

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/]

Ontologies

MULECO

Méthodes et Langages du Commerce Electronique

ITCE NFE 102 Année 2013-2014 !