OASIS ebXML Messaging Services TC

 View Only
Back to discussions
Expand all | Collapse all

Re: [ebxml-msg] Re: SyncReply Module

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

    Posted 11-19-2001 13:24 
     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,

    
Some comments below.

    
Cheers,

    
Chris

    
David Fischer wrote:
    

    NFBBIIHJNFIEBFENACIJKEFMCDAA.david@drummondgroup.com">
  
    First, I agree there are still some difficulties with multihop and syncReply.
    This new element does not do anything to solve those difficulties.  The only
    answer I can see is to do as Dale suggested and use a cascading Ack -- but that
    has difficulties too.
    
  
    
This doesn't address the problem, the issue isn't acknowledgments, it is
all about
    
message exchange patterns.
    
  
    NFBBIIHJNFIEBFENACIJKEFMCDAA.david@drummondgroup.com">
    


    Second, I still think there cannot be IM SOAP only nodes.  This makes no sense
    at all since any SOAP IM MUST understand MessageHeader in order to route.  This
    is the Store-and-Forward only IMs we have been discussing -- doesn't need to
    touch the Manifest.  If it can look in MessageHeader to get the To then it can
    also look in MessageHeader/QualityOfServiceInfo to get syncReply.  So I must ask
    again, why are we adding a new element.
    
    
    
There is nothing, nor should there be nothing to preclude OTHER SOAP headers,
not just
    
ebXML MessageHeader in a SOAP message that just happens to also contain ebXML
    
defined extensions. There is no need for a non-ebXML MSH SOAP node to understand
    
anything in the MessageHeader as long as it understands whatever headers
are
    
targetted to it by virtue of the actor of "next" or anything else for that
matter. ebXML is not,
    
nor should it be, a closed protocol, especially given that it is layered
on top of SOAP.
    NFBBIIHJNFIEBFENACIJKEFMCDAA.david@drummondgroup.com">
      


    Third, when I made the assertion that syncReply is for MSHsignals, I did not
    mean to imply that it did not match SyncReplyMode -- it does follow.  If
    SyncReplyMode is not *none* then syncReply MUST be *true*.  This does not imply
    that syncReply cannot still be *true* even if SyncReplyMode is *none* -- this
    would mean MSHsignals only.

    However, when would the MSH syncReply ever be *false*?

    I must reiterate, we don't need syncReply at all.
    
      

    
I don't buy this unless we are going to completely abandon multi-hop and
intermediaries
    
for v1.1. There needs to be some way of communicating to a node whether the
    
connection over which a message was received is expecting a response so that
it
    
can be held open (as long as feasible and practical). Whether the node is
a MSH or a
    
plain old SOAP node serving some other purpose for which ebXML does not
    
define itself is irrelevant. The reason that the actor of "next" is used
is just to provide
    
for the possibility, regardless of how remote that the node at which a message
is received
    
can be asked, in a manner that REQUIRES it to understand (mustUnderstand=1)
    
at least the part about the fact that the connection over which the message
was received
    
will need to be kept open for a subsequent response.

    
We agreed to this in the F2F by vote. I see no reason why it needs to be
continuously
    
debated.

      
    NFBBIIHJNFIEBFENACIJKEFMCDAA.david@drummondgroup.com">
        


    Doug, Chris?

    Regards,

    David Fischer
    Drummond Group.


Related Content