1 / 34

2. Messageries e-Business - AS1,2,3 - ebMS 2, 3

Un survol des Technologies e-Business / e-Gouvernement Partie 2 Jacques Durand Fujitsu Computer Systems. 2. Messageries e-Business - AS1,2,3 - ebMS 2, 3. AS1 AS2 AS3. MIME Sur SMTP. MIME Sur HTTP. MIME Sur FTP. AS3. AS1. AS2. FTP. SMTP. HTTP. TCP / IP.

aira
Download Presentation

2. Messageries e-Business - AS1,2,3 - ebMS 2, 3

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Un survol des Technologies e-Business / e-GouvernementPartie 2Jacques DurandFujitsu Computer Systems

  2. 2. Messageries e-Business- AS1,2,3- ebMS 2, 3

  3. AS1AS2AS3 MIME Sur SMTP MIME Sur HTTP MIME Sur FTP AS3 AS1 AS2 FTP SMTP HTTP TCP / IP

  4. AS1AS2AS3- “Internet Draft” IETF (2003)- AS1,2,3: fournir une alternative a VAN/EDI (“EDI-INT” ou “Web EDI”)- utilise S/MIME, et toutes les facettes de la sécurité (confidentialité, non-répudiation, authentification, authorisation…)- non basé sur SOAP

  5. AS2- Tous types de messages (EDIFACT, X12, XML…)- Définition avancée de “Receipt” (accusé de réception): - MDN (message disposition notification), synchrone ou asynchrone - Synchrone: sur réponse HTTP. - Non-répudiation de réception (NRR): évènement légal = vérification du recu signé renvoé’ par le Receveur.

  6. Messagerie ebXML “extension SOAP” (avec attachements) ebXML Messaging SOAP SOAP avec Attachements (MIME) SMTP HTTP TCP / IP

  7. ebXML origine et contexte • UN/CEFACT • United Nations Centre for Trade Facilitation and Electronic Business • Origine du Standard EDI (UN/EDIFACT standards for Electronic Data Interchange)‏ • OASIS • Organization for Advancement of Structured Information Standards • Standards eBusiness basés sur XML

  8. ebXML • Vision: • “Creer une infrastructure pour “electronic business” • Contribuer au marché global électronique • Approche: • Interopérabilité Sémantique et Technique • Infrastructure modulaire utilisant EDI, XML, Internet, technologies Web

  9. Standards ebXML • ebXML Messaging (ebMS)‏ • Messagerie Secure, Fiable (reliable messaging) • Certification d’ Interoperabilite’ pour Version 2 depuis 2003 • Collaboration Protocols Agreements (CPA)‏ • Document XML d’ agreement bilateral sur le traitement des messages (securite’, conventions de contenu, etc.) • Utilisable comme configuration du service messagerie • Business Process (ebBP)‏ • Modeliser et controler les transactions business • Choreographie d’ echanges (“processus public”) • Le CPA controle la dependence avec le niveau message • Registry-Repository (RR) • Modele et repertoire pour toutes definitions (docs CPA, ebBP…) • Core Components • Modele d’Information pour les vocabulaires and documents business (e.g. XML)

  10. Enveloppe SOAP <?xml version='1.0' ?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Header xmlns:….> <eb:Messaging …> … </eb:Messaging> <wsse:Security …> … </wsse:Security> </SOAP-ENV:Header> <SOAP-ENV:Body> <claim:insurance_claim_auto id="insurance_claim_document_id" xmlns:claim="http://schemas.risky-stuff.com/Auto-Claim"> <theSignedForm href="cid:claim061400a.tiff@claiming-it.com"/> <theCrashPhoto href="cid:claim061400a.jpeg@claiming-it.com"/> <!-- ... more claim details go here... --> </claim:insurance_claim_auto> </SOAP-ENV:Body> </SOAP-ENV:Envelope> SOAP header For ebMS3 SOAP header For WS-Sec “Payload” du message (partie business)

  11. Enveloppe SOAP Avec QoS (securite’..) WS-Security Enveloppe ebMS 3 (SOAP Header)

  12. Systemes ebMS2 en Operation • UK NHS (Health Service)‏ • HL7 (Canada)‏ • National Health Network, Norway • US Centers for Disease Control • Netherlands Criminal Justice System • British Telecommunications (part of a full business process)‏ • General Motors • T-Mobile • US Department of Defense • + More

  13. Systemes ebMS2 en Operation • eBusiness Asia Committee • Promoting ebXML use is part of its charter • 11 South-pacific Regions (Australia, China, Chinese Taipei, Hong Kong, Indonesia, Japan, Korea, Malaysia, Pakistan, Singapore, Thailand) • ebXML Messaging V2 Certification Program – 1st round started in 2003. 14 vendors/orgs passed. Plans for V3 testing. • in Japan: ECOM, JEITA, COXEC consortiums moving toward adopting ebMS V3. • Hermes Open-source from CECID (HongKong) used world-wide • Other Interoperability Test Programs • In US: UCC/DGI • In EU: ETSI

  14. PHINMS: Messagerie du Center for Disease Control (US) • 1. Facilité d’addition de nouveaux partenaires eB / eG ? • Interface utilisateur facile pour éditer des “templates CPA” et les ajouter dans la configuration du handler • 2.Interface application ? • interfacesneutres : bases de données, classeurs fichiers. Introduction récente de files JMS (pour Java apps). 3. Management de la messagerie: niveau d’expertise ? • Installeur, interface utilisateur pour la configuration, monitoring. 4. Traitement du message Après réception: • synchronous (2a) • asynchronous (2b) • “push-pull” App 2b Servlet App 2a App 1 HTTP MSH 1 MSH 2

  15. ebMS 2.0 & 3.0: Principes de Base • Une messagerie sur protocoles Internet, un standard ouvert, avec les fonctions avancées des messageries privées • Base’ sur SOAP, Attachements MIME • Indépendent du niveau bas Transport (HTTP, SMTP, FTP…) • Ne définit pas d’ interface application (JMS ou autre…) • Une en-tête générique “Business” • Identifie partenaires, définit la sémantique Transaction et son Contexte, les attributs du Contrat eB • Fiabilité du message (Reliable Message Delivery) • Livraison garantie, élimination des doublons, livraison dans l’ordre • Sécurité • Digital Signature and Payload Encryption • Support pour la Non-repudiation d’Origine & de Réception • S’ intègre avec les autres composants eBusiness (ebXML or other)

  16. New in ebMS 3.0 Core • Plus de Convergence avec les Web Services • SOAP 1.1 or SOAP 1.2 • SOAP with Attachments or MTOM • WS-Security 1.0 or 1.1 • WS-Reliability 1.1 or WS-ReliableMessaging 1.1 • Compatible with WS-I profiles • Va au devant des exigences nouvelles eBiz/eGov

  17. Nouveaux Concepts dans ebMS 3.0 • Modes de Traitement du Message (P-mode) • Ensemble de paramètres qui contrôlent le traitement du message (codifiable dans le CPA). • Transfert de message en mode “ tiré “ • Le Receveur interroge l’Envoyeur • Polling (style POP3) • Adaptè aux petits utilisateurs ( PME ) • Occasionellement connecté, • pas d’adresse Internet fixe, • restrictions d’accès dues aux parefeux. • “Conduits” (channels) de Messages • Le Message est assigné à un conduit • Permet de gérer les priorités de transfert, et les flux tendus

  18. Message Tiré (Pulled) 2 Pull-Capable V3 MSH “Light” V3 MSH 1 signal Tire (Pull) Livraison Message 4 Message A envoyer 3 Message tire’ • Message à envoyer : soumis à un conduit pour tirage • Mis en attente • Signal “Pull” (Tiré) • Generaté par le Handler de message (MSH, non l’application) • Le signal a pour cible un conduit (pour tirage), et doit etre autorisé pour ce conduit • Message Tiré • Envoyé sur la reponse HTTP (si HTTP) • Bénéficie des techniques de Fiabilité (Qualités de Livraison) 1 2 3

  19. Conduits de Messages (Channels)  signal “tire” Document ServiceRequest Basse priorité MSH MSH Centre Service Clients Centre de Support Technique Document ServiceRequest Haute priorite’ • Conduits Utilisables pour: • Transfer sélectif / prioritaires • Suite de messages homogène • Pour Homogeneite’ de Qualite’ de Service ? • Oui, mais pas nécessairement

  20. Exemples de Déploiement Types • Le Handler mobile (Client “pur”) • La passerelle eB / eG, pour touts types d’intégration avec le niveau application (services Web internes, legacy middleware – MQ / CORBA / JMS...)‏

  21. Pull Signal Submit Response Pulled Response Pulled Message Light MSH 2 Restricted / Intermittent Connectivity Light MSH 1 Application Pushed Message Deliver MSH 3 Roaming endpoints (e.g. no static IP address), or intermittently connected

  22. Request Web Service A Response One-Way Web Service B Async Response Light MSH 2 B2B Gateway Gateway Or ESB MSH 1 MSH 3 Internet Web Service C JMS, MQ..

  23. Conformance Profiles • Subset of V3 Features + narrowing of options • Match different types of Implementations • Light MSH (“pure client”) • B2B Gateway • Underlying Standards may evolve over time • SOAP 1.1  SOAP 1.2 • Reliability Standards • Different Transports (HTTP, SMTP, …) Conform to Core V3 Specification Use Compatible Conformance Profiles Interoperable MSHs + =

  24. Profils de Conformance ebMS3 • Profil Passerelle RM V2/3: ebMS V2 + V3, avec WS-Reliability1.1 pour fiabilité. • Profil Passerelle RM V3: ebMS V3 comme dans RM V2/3 profile, mais pas de support pour V2.

  25. Impact sur l’utilisateur ebMS2? (1)‏ • No “wire-level” backwards protocol compatibility • Incompatible security / reliability modules (new std) • New features introduced • But “Gateway V2 / V3” conformance profile requires an MSH to support for both versions • Supporting the Transition: • Gateway V2/V3 provides guidance on Integrating both • “V2 Compatibility Mapping” (Appendix F) in V3 specification maps Header, Payload, Reliability, Message Exchange Patterns, Signals, Processing Modes • A “functional specification” of an ebMS2 - ebMS3 bridge

  26. Impact sur l’utilisateur ebMS2? (2)‏ • In practice, impact of migration on existing ebXML users will be minimal: • Message Service Interface can be identical • e.g. JMS queues with same properties, values, destinations • Collaboration Protocol Agreement (CPA)‏ • CPP/A 3 will support ebMS2 and ebMS3 • CPA = XML agreement between business partners, used for MSH configuration • Upgrade from v2 to v3 • If automated, e.g. using XSLT, would use V2 compatibility mapping)‏

  27. Future V3 Features • Begin Advanced Features Specification Addition (Part 2) • Routing and Intermediary Roles • Forwarding, multicasting, deliver-and-forward… • Message Bundling / Splitting • Many small messages  aggregate • Very large messages  “chunks” or packets • Status Requests • State of a channel, of a message, QoS status • Payload Processing • Transforms, compression, validation

  28. 1.How does ebMS(V3) relate to other ebXML specifications?2. if ebMS 3 is so heavily based on WS standards, what value does it add to using just plain WS? 3. How does ebMS V3 relate to WS-I Profiles?4. What does ebMS V2/V3 do that AS2 doesn’t?5. Isn't pulling replicating what POP3 servers do? Questions? In addition to common questions:

  29. Question 1 How does ebMS(V3) relate to other ebXML specifications? • Compose with each other, but can be deployed separately (no dependencies on each other)‏ • Integration points: • V3 Message Exchange Patterns map to ebBP Business Transactions • V3 Processing Modes map to CPPA • CPAs used to configure MSH may be stored in, and retrieved from, Registry

  30. Question 2 If ebMS 3 is so heavily based on WS standards, what value does it add to using just plain WS? • Business Headers • Channels, Pulling, Non-repudiation of Receipt • Different message consumption styles (WSDL not always appropriate) • Allows for a gateway architecture to decouple external B2B and internally deployed WS • Future features (Part 2: routing, bundling…)

  31. Question 3 How does ebMS V3 relate to WS-I Profiles? • V3 reuses SOAP, WS-Security, WS-ReliableMessaging, and is subject to compliance with WS-I profiles (BP1.0/1.2, BSP1.0/1.1) • V3 Conformance Profiles, defined in an adjunct document, will state compliance with above profiles (some yet to be finalized in WS-I: BP2.0, RSP1.0)

  32. Question 4 What does ebMS V2/V3 do that AS2 doesn’t? • Some QoS like reliability. • Message pulling, channels (e.g. selective pulling)‏ • Message Exchange Patterns, and their bindings to business transactions • Ability to process WS invocations (SOAP intermediary model) • Will use SOAP model for routing (part 2)‏

  33. Question 5 Isn't pulling replicating what POP3 servers do? • There have been issues with SPAM on SMTP-based solutions. • Pull feature is desirable, regardless of protocol used. • May not want to rely on 3rd-party (ISP) infrastructure. • Pull allows a better understanding and control of message location and status at all times.

  34. Related Links • OASIS ebXML Messaging Technical Committee • http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ebxml-msg • OR http://tinyurl.com/29kcgn • Documents (under “Technical Work” section, on above Web page) • ebms_core-3.0-spec-cd-06.pdf(V3 Committee Specification) • ebms3_ConformanceProfiles-08.pdf(V3 Conformance Profiles Draft)

More Related