OASIS ebXML Messaging Services TC

 View Only

MSH Default Operating Mode (DOM)

  • 1.  MSH Default Operating Mode (DOM)

    Posted 07-22-2005 03:31
     MHonArc v2.5.0b2 -->
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    ebxml-msg message

    [Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


    Subject: MSH Default Operating Mode (DOM)


    Summary of the MSH Default Operating Mode (DOM) feature, as previously discussed:

    -        DOM is not intended to represent a default CPA (as defined in CPPA), rather a default operating mode.

    -        The main driver for this feature, is the possibility to deploy and interoperate without any form of prior CPA negotiation. Note that it may not be possible to use it in some environments that are incompatible with the DOM (e.g. security-constrained).

    -        The value is some easier, phased testing and deployment.

    -        It is not intended as a normal operating mode for conducting business.

    -        A conforming MSH would be required to implement it, but the feature can be disabled once A deployment is complete, e.g. for security reasons.

    Two options:

    (i) DOM is Restricted to a "CPA-free" ping feature. Useful when undergoing the initial steps of a deployment, where interoperability has to be established step by step.

    (ii) DOM may apply to any message. Messages can be sent and delivered to applications in that mode, for end-to-end processing and interop testing.

    I suggest that (ii) is more useful, meaning that the DOM is not restricted to / Pong messages, but can be used for initial end-to-end testing, in real operating context.

    - The DOM would be activated by agreementRef, e.g. with value "eb:default" (or approaching URI).

    - It would use no reliability, no security.

    Issues:

    - Messages under DOM can be pushed, but can they be pulled as well? (some MSH may only be intended to pull.) If yes the pulled message can have been submitted under DOM as well. This means we assume that the feature that controls whether a submitted message is queued (for subsequent pulling) or pushed, can be controlled independently from a CPA (implementation level).

    - Some environments may prohibit the use of DOM, e.g. if they always require some form of security. In such cases, proper notification must be sent back. This is a more general issue: discrepancy between what the message header is indicating, and what the MSH (meaning also the security component) is set to process (per CPA requirement or other).



    [Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]