Fujitsu Computer Systems

Un survol des Technologies e-Business / e-Gouvernement

Partie 2

Jacques DurandFujitsu Computer Systems

Fujitsu Computer Systems

2. Messageries e-Business

- AS1,2,3- ebMS 2, 3

Fujitsu Computer Systems

AS1AS2AS3

MIME Sur SMTP

MIME Sur HTTP

MIME Sur FTP

TCP / IP

HTTP SMTP FTP

AS2 AS1 AS3

Fujitsu Computer Systems

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

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

SOAPSOAP 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

<?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 headerFor ebMS3

SOAP headerFor WS-Sec

“Payload” du message(partie business)

Enveloppe SOAP

Fujitsu Computer Systems

Enveloppe SOAPAvec QoS (securite’..)

Enveloppe ebMS 3(SOAPHeader)

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

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 messageAprès réception:- synchronous (2a)- asynchronous (2b)- “push-pull”

ServletApp 2a

PHINMS: Messagerie du Center for Disease Control (US)

MSH 1 MSH 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

Aenvoyer

LivraisonMessage

signal Tire (Pull)

Message tire’

12

3

4

1

2

3

Conduits de Messages (Channels)

Document ServiceRequestBasse priorité

CentreServiceClients

Centre deSupportTechnique

• Conduits Utilisables pour :• Transfer sélectif / prioritaires• Suite de messages homogène

• Pour Homogeneite’ de Qualite’ de Service ?• Oui, mais pas nécessairement

MSH MSH

signal “tire”

Document ServiceRequestHaute 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 ApplicationPull Signal

Pulled Response

Pushed MessageDeliver

LightMSH 1

SubmitResponse

LightMSH 2

Pulled Message

B2B Gateway

MSH 3

LightMSH 2 Web

Service C

JMS, MQ..

MSH 1

GatewayOr ESB

Request WebService AResponse

WebService B

One-Way

AsyncResponseIn

tern

et

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 toCore V3

Specification

Use CompatibleConformance

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 3rd-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 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)