Efficient: atelier de prototypage de transactions d’e-commerce

1. Efficient: atelier de prototypage de transactions d’e-commerce Workshop ECI16 janvier 2004 Centre de Recherche Public Henri Tudor Centre d’Innovation par les Technologies de l’Information Luxembourg Sophie Ramel, Michael Schmitt, Bertrand Grégoire http://efficient.citi.tudor.lu bertrand.gregoire@tudor.lu

2. Plan de la présentation • contexte • e-commerce • mise en place de nouvelles collaborations • évaluation stratégique d’une transaction • évaluation pratique • modélisation • animation • pistes ouvertes

3. B2B Compagnie A Banque B EAI Front End B2C Monsieur X Back End Contexte - recherche de collaborations • différentes formes d’eBusiness (EDI & web) • recherche de partenariats

4. Contexte- idées de l’atelier • constat • les experts métiers connaissent leur domaine • les experts des systèmes d’informations connaissent les possibilités techniques • la communication entre ces experts se fait par le biais de spécifications plus ou moins précises. • contribution à la résolution de quelques défis du B2B actuel • améliorer le STP (Straight Through Processing): meilleure documentation des messages (ebXML) • considérer les transactions sous un aspect E2E: vue transaction associée à une vue messages • développer « the right transaction at the right time »: automatiser la production de code à partir de modèles

5. Modélisation Vérification Validation Elicitation Experts métier Contexte - design de transactions

6. Modélisation Vérification Elicitation Géneration Code Animation distribuée Proposition Efficient

7. Proposition Efficient - étapes

8. Evaluation stratégique(value layer) que faire? pourquoi le faire? avec qui le faire ?

9. Identification - collaboration prometteuse • objectifs • identifier et évaluer les transactions eBusiness (les plus) prometteuses par rapport à • leur valeur potentielle • leur pertinence • définition:la nature d’une collaboration eBusiness ne se distingue pas des formes traditionelles (Porter) • repondre a un besoin client • fournir un produit valorisé par les clients • être profitable & competetive par l’innovation ou par l’efficacité coût • offrir des incitations pour les acteurs impliqués

10. Evaluation stratégique - valeur • la valeur d’une transaction est crée par (Amitt&Zott) • efficacité de sa réalisation • caractéristiques des biens échangés • facilité avec laquelle un participant peut quitter la transaction (lock-in) • caractère innovant • modélisation des collaborations eBusiness (Gordijn) • modélisation du processus (comment?) • modélisation business (quoi? pourquoi?) • qui fournit quelle part de la valeur de la transaction, • qui traite avec quels partenaires d’affaires directs et • qui reçoit quoi comme contre-valeur pour ses prestations

11. Double exigence de modélisation • pourquoi ? • identifier et modéliser les buts des acteurs impliqués • quoi ? • identifier et modéliser les objects de valeur • tangible (bien/service) ou intangible (confiance, information) • identifier les prestations et contre-parties pour chaque rôle, la valeur d’un échange peut être attribué • via les caractéristiques d’objet de la valeur (ex: qualité, image de marque du produit, ToS) • via les caractéristiques du partenariat (ex: fiabilité, image de marque du partenaire, fidélisation)

12. Propositions actuelles - double réponse • motivation/objectifs pour les participants • capturés par une approche “Balanced Scorecard”: 4 perspectives sur des objectifs et des mesures de la réalisation des objectifs • perspective financières • perspective client • perspective processus métier • perspective d’apprentissage et évolution • objets de valeur et contre-parties • échanges représentés par un diagramme UML ou e3-value • ajout de caractéristiques utiles

13. Evaluation stratégique - faisabilité • but d’évaluation et selection d’une transaction par rapport à • la valeur de la transaction • sa faisabilité au regard de • l’environnement organisationnel • l’environnement technologique • les investissements nécessaires • l’intégration de la faisabilité dans l’atelier Efficient doit encore être investiguée

14. Modélisation(business & specification layers) comment le faire en pratique?

15. Spécification - vue d’ensemble (1) • choix d’UML (UMM) et autres standards • acteurs et autres transactions de l’entreprise • issus directement de l’évaluation stratégique • diagramme de cas d’utilisation UML

16. Spécification - vue d’ensemble (2) • domaine d’information • concepts du cœur de métier, ensemble de l’information manipulée • réutilisabilité encouragée (ebXML ebCC) • diagramme de classe UML

17. Spécification - vue détaillée (1) • modèle dynamique de la transaction • activités, responsabilités, séquencement, documents métiers, décisions • diagramme d’activité UML (liens avec business & value layers)

18. Spécification - vue détaillée (2) • modèle statique des documents métier échangés • simplifié par une sélection (vue) du business domain • contraintes syntaxiques (structure en arbre) • acyclicité, direction des relations, héritage simple, typage

19. Spécification - vue détaillée (3) • représentation de règles métier • règles de management, pratiques business, connaissance/ontologie, droits d’accès,… • représentation consensuelle entre intuitivité, expressivité et exécutabilité • basées sur des faits • constants (“variable” de la règle, fixée par l’utilisateur) • dérivés du business domain • calculés: faits temporels (occurrence d’un document), logiques ou arithmétiques

20. interprétation en langage naturel (anglais, français) et en prédicats logiques de premier ordre (xlinkit) intuition et exécutabilité expressivité correspondanteau business domain représentation contrainte UML sur les diagrammes de classe des messages correspondants Règles métier - framework linguistique

21. animation les modèles réalisés expriment-ils bien l’idée des experts métiers?

22. Génération de code CASE tool UML (MagicDraw 7.0) Génération de code Workflow Engine XML Schema, XPDL, Xlinkit GUI Outil d'animation

23. Principes technologiques choisis • Choix d'une architecture web • Technologies XML pour les messages, schémas, contraintes, etc. • Échanges de messages XML: web services (SOAP) • Utilisation d'outils open source, respect des standards existants • Vocabulaire: • Partie centralisée: animateur • Parties sur postes des participants: clients

24. Fonctionnement général • L'animateur comprend un moteur de workflow qui exécute la procédure • Les activités d'envoi de messages • un participant jouant un rôle peut envoyer un message à un autre rôle • ce message est intercepté par l'animateur • des activités de vérification du message, de transmission et de complétion du message sont conduites (à l’insu des participants)

25. 4 : Message 2 1 : Message 1 2 Message 1 8 : Message 3 : Réponses Possibles: 3 Message 2 Animateur : Réponses Possibles: 6 7 5 : Message 3 : Message 2 Message 3 Exemple de transaction Participant1 Participant 1 Participant 2 1.xml 3.xml : Animateur 2.xml + réponse possible 2.xml 1.xml + réponse possible 3.xml Participant3 Participant 3 Participant2

26. Outil client - technologies • basé sur des servlets Java • formulaires de remplissage des messages: • génération de documents XForms à partir du XMLSchema du message (+ d'une instance pré-remplie en fonction des messages précédents) • affichage du document XForms par l'outil Chiba (http://chiba.sourceforge.net) • réception et envoi de web services par Axis (http://ws.apache.org/axis)

27. Outil client - étapes pour l'envoi d'un message • Légende: • cases bleues: activités transparentes pour l'utilisateur • cases jaunes: activité réalisées par l'utilisateur

28. Outil client - interface • formulaire XForms dans Chiba

29. Outil animateur • moteur de workflow exécutant la procédure: WFMOpen • http://wfmopen.sourceforge.net/ • compatible WfMC (import XPDL) et OMG (API Java) • utilisation d'une base de données XML pour le stockage de tous les documents XML: eXist • http://exist.sourceforge.net/ • compatible avec les API standards XML:DB

30. Animateur - activité d'envoi d'un message • activité automatique • rajoute le XMLSchema et l'instance pré-remplie du message dans une liste XML • les clients consultent cette liste (par WS) • web service de réception de message dans l'animateur • enlève la description de la liste • complète l'activité correspondante dans la procédure du moteur de workflow

31. Animateur - activité de vérification • vérification statique du message par rapport à son XML Schema • parser Xerces, http://xml.apache.org/xerces2-j • vérification de règles business sur ce message • outil Xlinkit http://www.xlinkit.com • transmission du message à son destinataire, ou du message d'erreur à son émetteur

32. Animateur - autres modules • définition de procédures • web service permettant de créer, modifier ou détruire une procédure (appelé depuis MagicDraw) • gestion des procédures • web service permettant de connaître les rôles nécessaires à une procédure et d'instancier une procédure en fournissant des clients pour ces rôles (appelé depuis un client)

33. Animateur - architecture générale

34. Perspectives et conclusion

35. Pistes ouvertes • validation exhaustive • model checking des modèles dynamiques • cas réels • des cas théoriques et réels sont étudiés avec cet atelier, des cas supplémentaires sont toujours les bienvenus • collaborations possibles • possibilité de projets « conventionnés » sur certains aspects particuliers (packaging du code, outils d’interopérabilité,…)

36. Conclusion • méthodologie et outil de prototypage de transactions • basé sur des considérations business (proposition de valeur, documents et règles métier) • animation complètement automatisée et tracabilité élevée • utilisation (abusive ;o) de standards • orientation vers le logiciel libre

37. Références • organisations responsables • http:// www.ebxml.org/ • http://www.oasis-open.org/ • http://www.unece.org/cefact/ et http://www.ebtwg.org/ • les différents standards • http://www.w3.org/ • http://www.omg.org/

38. Efficient: atelier de prototypage de transactions d’e-commerce merci pour votre attention Sophie Ramel, Michael Schmitt, Bertrand Grégoire http://efficient.citi.tudor.lu bertrand.gregoire@tudor.lu

39. Annexes tracabilité étude de cas: Mercata génération de XML schéma depuis CD UML Efficient Business Rules

40. W H Y Business Requirements BUSINESS & DOMAIN ANALYSYS W H A T Logical Design TRANSACTIONS & MESSAGES H O W Physical Implementation SYNTAX & CODE Tracabilité importante - change managt

41. Etude de cas - Mercata • Historique • site d’enchères de réductions par lots, Letsbyit.com. • n’est plus en activité. • détaillé dans le MIT Process Handbook. • entreprise fondée en mai 1998, site web en mai 1999, sort des affaires en jan 2001 suite au manque d’offreurs et désintérêt des consommateurs. • Idées • baisse des prix via aggrégation de la demande • offre de services divers pour les différents produits.

42. Génération XML Schema • Génération automatique à partir de UML, basée sur les travaux de SWIFT et XMI • Règles de consistance appliquées au W3D XSD • Business information  XML element/value • Metadata information  XML attribute • Traçabilité de XML (instance, DTD et Schema) au modèle business (W3C PSVI draft proposal) • proposition concurrente de UBL

43. Diagramme de Classe XMLSchema • Traitement des classes: • 1ère classe « racine » retrouvée par son nom: « element » créé, contenant un « complexType » • Autres classes: transformées en types « complexType » directement, non imbriqué <schema> <element name=‘A’> … <element type=‘B’> … <element> <complexType name=‘B’> A  B

44. Diagramme de Classe XMLSchema • Pour toute classe traitée: • Si pas d’héritage, on insère directement “sequence” dans le “complexType” • Si héritage (simple uniquement), on insère “complexContent / extension” du type hérité, suivi par “sequence” <complexType> <complexContent> <extension base="…"> <sequence> … <sequence> </extension> </complexContent> </complexType> <complexType> <sequence> … <sequence> <complexType> ou

45. A String attr B attr2 [0..2] Diagramme de Classe XMLSchema • Attributs transformés en éléments XML: • la multiplicité est retrouvée • Type: • soit type simple (table de conversion entre datatypes) • soit, si c’est une classe du diagramme, le nom du type généré (la classe est alors également traité après pour générer ce type). • Idem pour les relations sortantes (associations, aggrégations et compositions directionnelles), avec comme nom le nom du rôle … <element name="attr" type="xsd:string"/> <element name="attr2" type="B" minOccurs="0" maxOccurs="2"/> 

46. Diagramme de Classe XMLSchema • Autres règles gérées non détaillées ici: • Classes d'associations: element intermédiaire inséré • Contraintes transformées en annotations de l'élément concerné • …

47. Business Rules - structure des EBR

48. Business rules - opérateurs

49. Business rules - expressions