Date post: | 04-Apr-2015 |
Category: |
Documents |
Upload: | raimond-desbois |
View: | 105 times |
Download: | 0 times |
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:[email protected]"/> <theCrashPhoto href="cid:[email protected]"/> <!-- ... 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)