Fujitsu Computer Systems Un survol des Technologies e-Business / e-Gouvernement Partie 2 Jacques Durand Fujitsu Computer Systems

Fujitsu Computer Systems 2. Messageries e-Business - AS1,2,3 - ebMS 2, 3

Fujitsu Computer Systems AS1 AS2 AS3 MIME Sur SMTP MIME Sur HTTP MIME Sur FTP TCP / IP HTTP SMTP FTP AS2 AS1 AS3

Fujitsu Computer Systems AS1 AS2 AS3 - “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

Fujitsu Computer Systems 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.

Fujitsu Computer Systems Messagerie ebXML “extension SOAP” (avec attachements) TCP / IP HTTP SMTP SOAP SOAP avec Attachements (MIME) ebXML Messaging

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

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

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)

Fujitsu Computer Systems … <claim:insurance_claim_auto id="insurance_claim_document_id" xmlns:claim=" SOAP header For ebMS3 SOAP header For WS-Sec “Payload” du message (partie business) Enveloppe SOAP

Fujitsu Computer Systems Enveloppe SOAP Avec QoS (securite’..) Enveloppe ebMS 3 (SOAP Header) WS-Security

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 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 – 1 st round started in 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 Systemes ebMS2 en Operation

Fujitsu Computer Systems 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 ? -interfaces neutres : 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” Servlet App 2a PHINMS: Messagerie du Center for Disease Control (US) MSH 1MSH 2 App 1 App 2b HTTP

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)

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

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

Message Tiré (Pulled) 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) “Light” V3 MSH Pull-Capable V3 MSH Message A envoyer Livraison Message signal Tire (Pull) Message tire’

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

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...)‏

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

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

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

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.

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

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)‏ Impact sur l’utilisateur ebMS2? (2) ‏

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

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:

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

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

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)

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)‏

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 3 rd -party (ISP) infrastructure. Pull allows a better understanding and control of message location and status at all times.

Related Links OASIS ebXML Messaging Technical Committee OR Documents (under “Technical Work” section, on above Web page) ebms_core-3.0-spec-cd-06.pdf (V3 Committee Specification) ebms_core-3.0-spec-cd-06.pdf ebms3_ConformanceProfiles-08.pdf (V3 Conformance Profiles Draft) ebms3_ConformanceProfiles-08.pdf