OASIS ebXML Messaging Services TC

Re: [ebxml-msg] Re: SyncReply Module

  • 1.  Re: [ebxml-msg] Re: SyncReply Module

    Posted 11-20-2001 14:20
     MHonArc v2.5.2 -->
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    ebxml-msg message

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


    Subject: Re: [ebxml-msg] Re: SyncReply Module


    David,
     
    This has gone on too long.  I'll bite one last time but what exactly are we debating now the issue has been resolved?
     
    The use case described has been in the document for quite some time.  I refer, for example, to lines 728-730 in section 2.2.10 of the 1.09 draft which explicitly describes the "next MSH" actor as allowing SOAP extensions to skip intermediate SOAP processors without full MSH capabilities.  Otherwise, "next" would be sufficient.  Though it isn't as explicit, the same could be said for the "To Party MSH" actor because it allows the default SOAP actor to be placed before or after the To Party actor on a multi-hop route.
     
    I'd turn off sync reply whenever I know the receiving end can't or won't reply synchronously.  For example, signature validation and other security checks may be time-consuming.  I'd rather wait for a single asynchronous reply (allow push) than retry (poll) for the transport confirmations.  It becomes much more efficient to operate in this way once the chance of failure reaches measurable levels -- especially if the recipient does security checks prior to duplicate detection.  This is exactly how the RosettaNet Integration Framework works today.  In fact, I might turn on sync reply if and only if I were behind a firewall and unable to receive incoming messages.  (We're only covering part of the requirements for such a configuration because we don't cover polling for business responses but it's a start.)
     
    thanx,
        doug