OASIS Week of ebXML Standards Webinars by U7x7nZ

VIEWS: 0 PAGES: 34

									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          MIME Sur SMTP

AS2          MIME Sur HTTP

AS3          MIME Sur FTP




      AS2          AS1                  AS3

      HTTP        SMTP                  FTP

                  TCP / IP



             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)


                   ebXML Messaging

                                     SOAP avec
                  SOAP              Attachements
                                        (MIME)


    HTTP      SMTP

              TCP / IP

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




WS-Security
                                                     Enveloppe
                                                     ebMS 3
                                                     (SOAP
                                                     Header)



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

                                                           Servlet        App 2b
  4. Traitement du message                                 App 2a
  Après réception:
                                          App 1
  - synchronous (2a)                                      HTTP
  - asynchronous (2b)
  - “push-pull”                          MSH 1                       MSH 2

                               Fujitsu Computer Systems
    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)
    Livraison         “Light”   2   signal Tire (Pull)       Pull-Capable      1
    Message
                 4   V3 MSH                                  V3 MSH         Message
                                    Message tire’        3                  A
                                                                            envoyer

       Message à envoyer : soumis à un conduit pour
1       tirage
            Mis en attente
       Signal‫“‏‬Pull”‫(‏‬Tiré)
2           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é
3
            Envoyé sur la reponse HTTP (si HTTP)
            Bénéficie des techniques de Fiabilité (Qualités de
             Livraison)
 Conduits de Messages (Channels)
                            signal “tire”

                    Document ServiceRequest
                    Basse priorité
           MSH                                 MSH
     Centre          Document ServiceRequest   Centre de
     Service                                   Support
                     Haute priorite’
     Clients                                   Technique
• Conduits Utilisables pour :
  • Transfer sélectif / prioritaires
  • Suite de messages homogène
• Pour Homogeneite’‫‏‬de‫‏‬Qualite’‫‏‬de‫‏‬Service‫?‏‬
   • Oui, mais pas nécessairement
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



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


                       Light
                       MSH 2
         B2B Gateway
                      Gateway
                      Or ESB
                    MSH 3       Request
MSH 1                                         Web
                                Response    Service A
         Internet

                                One-Way      Web
                                           Service B
                                Async
                                Response


 Light
MSH 2
                                                 Web
                                               Service C
                                                   JMS, MQ..
    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         Use Compatible       Interoperable MSHs
      Core V3       +    Conformance     =
    Specification          Profiles
    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
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)
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
Questions?
 In addition to common questions:

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

								
To top