RE: [ebxml-msg] Re: [ebxml-cppa] Comments on reliable messaging inthe1.0.5 draft

Whew. 
A lot of TCP connection questions today. Is this the issue:

 

If a 
sender MSH is waiting for a HTTP Reply, and meanwhile the sender MSH is 
told

to 
do an application level retry, should the sender drop the initial 
connection? If so,

what 
happens at the Receiver end? 

 

(Basically, dropping the TCP connection at the sender end will 
cause an IO exception

at the 
other end, that will in production code 

lead 
to some clean up procedures being run that should 
probably

include forgetting about doing any HTTP reply-- 

no 
point to reply on a closed connection

obviously. A lot of stuff about FIN and ACK 

and 
TIMEWAIT2 omitted-- see Stevens.)

 

If 
this is the question, I have some other questions and 
remarks.

 

Is the 
application level retry to be a new message (with a new message id, and so 
on)?

Or is 
retrying a message an implicit service that a MSH offers the application level, 
so

that 
the same message  (with same message id) is pulled out of an archive 

or 
cache or queue and resent?

 

If the 
same message is resent, why can't the currently pending wait for a 
response

continue? Why put on more load, scrap an underway handling of the 
request, just to

adhere 
to an additional retry request? Something sounds funny in what is 
being

done in this case by 
scrapping an already underway service in order to start again and 

encounter the processing overhead 
anew.

 

If this is a way to try to deal with "hangs," and to 
distinguish hangs from slow response,

"good luck!" No good way to sort that one out without 
humans--even adding

a forward progress indicator every 10 seconds ("100 
Continue" or something like it) 

only gets you so far. I really get the feeling that we 
are adding level 2.0 or beyond 

exception handling for situations that, if they are to 
be dealt with at a protocol level,

need some really new state machines. 
Checkpoint/restart, rendezvous logic, forward 
progress--

is not the kind of stuff for a 1.1 spec. Wait until 
SOAP over BEEP 

and add on a BEEP Channel with all those 
embellishments.. 

HTTP is just not general purpose enough to bother 
trying to put all

this stuff on top of 
it.

 

Also, 
mixing retry of RM with application level retry seems to be an area for new 
tangles.

Is 
application level retry something that can be mixed with RM or should an 
application

choose 
best effort if it is doing A.L. retry? I realize RosettaNet has application 
level retries.

Is 
this functionality something beyond what RM can provide? Couldn't moving to 
RM,

using 
PIP parameter values in the RM parameters, satisfy 
RosettaNet retry requirements?

(If a 
new MessageId is to be used when doing application level retries, 

then 
that would be another story.)

 

Finally, why is this on a blue-greenish background?!!? 

 

-----Original Message-----
From: David Fischer 
[mailto:]
Sent: Tuesday, October 16, 2001 4:39 
PM
To: Arvola Chan; 
Cc: 

Subject: RE: [ebxml-msg] Re: 
[ebxml-cppa] Comments on reliable messaging in the1.0.5 
draft

OK, I agree.  How do we tell the MSH to use this new sync connection 
instead of the old one which is holding?  Just because the Sender decides 
to drop the connection, does not mean the Receiver actually realizes that.  
I am not a packet expert but, isn't the the Receiving end still waiting?  I 
don't think there is anything like a "keep-alive" packet going back and 
forth.  The connection is literally doing nothing.

 

Regards,

 

David.

  
-----Original Message-----
From: Arvola Chan 
  [mailto:]
Sent: Tuesday, October 16, 2001 2:43 
  PM
To: 
Cc: 
  
Subject: [ebxml-msg] Re: 
  [ebxml-cppa] Comments on reliable messaging in the 1.0.5 
  draft

  
David:

  
 

  
The purpose of a sender retrying is not only to solicit for 
  acknowledgment from the receiver, but also to solicit for the business level 
  response. Therefore, if the Acknowledgment message is piggybacked on the 
  business level response, then the latter compound message must be resent by 
  the receiver in response to the duplicate message.

  
 

  
Regards,

  
-Arvola

  
    
-----Original Message-----
From: 
    David Fischer <>
To: 
    David Fischer <>; 
    Arvola Chan <>; 
     
    <>
Cc: 
     
    <>
Date: 
    Tuesday, October 16, 2001 12:10 PM
Subject: RE: [ebxml-cppa] 
    Comments on reliable messaging in the 1.0.5 draft

    
Let me take some of that back.  If we find an Acknowledgment 
    Message in persistent storage, we can only reuse it if it is not 
    piggybacked on another message.  Is this really too much 
    complexity?  Should we just create a new Acknowledgment Message?  
    This kind of search probably takes more cycles then just creating from 
    scratch. . .

    
 

    
Regards,

    
 

    
David Fischer

    
Drummond Group.

    
      
-----Original Message-----
From: David Fischer 
      [mailto:]
Sent: Tuesday, October 16, 2001 
      1:40 PM
To: Arvola Chan; 
      
Cc: 
      
Subject: RE: [ebxml-cppa] 
      Comments on reliable messaging in the 1.0.5 draft

      
Arvola, I think I need some 
      clarification.

      
 

      
<<comments inline>>

      
 

      
David.

      
        
-----Original Message-----
From: Arvola Chan 
        [mailto:]
Sent: Tuesday, October 16, 2001 
        12:39 PM
To: 
Cc: 
        
Subject: [ebxml-cppa] Comments 
        on reliable messaging in the 1.0.5 draft

        
David:

        
 

        
Here are some inlined comments on 
        section 7.5 ebXML Reliable Messaging Protocol.

        
 

        
Regards,

        
-Arvola

        

        7.5.2       
        Receiving Message Behavior
        
If this is an Acknowledgment Message as defined in section 7 
        then:

        
1         
        Look for a message in persistent storage that has a MessageId that is the same 
        as the value of RefToMessageId on the 
        received Message

        
2         
        If a message is found in persistent storage then mark the 
        persisted message as delivered

        
If an AckRequested element is 
        present that is targeted to a role in which the Receiving MSH is acting (see 
        section 2.2.10 and 2.2.11) then do the following:

        
1         
        If the message is a duplicate (i.e. there is a MessageId held in persistent storage that was 
        received earlier that contains the same value as the MessageId in the received 
        message)  generate an Acknowledgment Message (see section 7).  
        The Receiving MSH 
        MUST NOT deliver the message to the application interface.

        
      The above paragraph does 
        not clearly explain how duplicate request messages are to be handled. 
        The pointer to section 7 is imprecise. The section 7.5.3 Generating an 
        Acknowledgment Message also does not provide information on how 
        Acknowledgment messages for duplicate messages should be generated. The 
        required information is actually included in section 7.5.2 but in a 
        rather convoluted form (see below). 

        
<<The second 
        paragraph is section 7 defines what an Acknowledgment Message is -- 
        which is the intention of this link.>> 

        
2         
        If the message is not a duplicate 
        (there is no MessageId held in persistent storage that 
        corresponds to the MessageId in the received 
        message) then do the following:

        
a         
        Save the MessageId of the received 
        message in persistent 
        storage. As an implementation decision, the whole message MAY be 
        stored if there are other reasons for doing so

        
b         
        Generate an Acknowledgment 
        Message in response (this may be as part of another message).  The Receiving MSH MUST NOT send an 
        Acknowledgment Message until the message has be 
        safely stored in persistent 
        storage.  Delivery of an 
        Acknowledgment Message 
        constitutes an obligation by the Receiving MSH to deliver the 
        message to the application or forward to the next MSH in the message 
        path as appropriate.  Look in persistent storage for the first response to the 
        received message (i.e. it contains a RefToMessageId that matches 
        the MessageId of the received 
        message).

        
(1)     
        If a response message was found in persistent storage then resend 
        the persisted message back to the MSH that sent the received 
        message

        
      The above discussions 
        (in red) are really in the wrong place as the 
        enclosing item #2 indicates that the message is not a 
        duplicate. 

        
<<we are not looking for a duplicate here.  We 
        are looking to see if a response (Acknowledgment Message) has previously 
        been sent.  If so, send the same one again.  If not, do the 
        following.  Maybe it would help to say "Acknowledgment Message" 
        instead of "response".>> 

        
(2)     If 
        no response message was found in persistent storage, 
        then:

        
(a)    if syncReply is set to true and if the CPA 
        indicates an application response is included, ignore the received 
        message (i.e. no message was generated in response to the received 
        message, or the processing of the earlier message is not yet 
        complete)

        
If the incoming message message is a duplicate and 
        syncReply is true but no message has been returned in response to the 
        received message, then it must be the case that processing of the 
        earlier message is not yet complete. In that case, the received message 
        cannot be ignored. Instead, it is necessary to wait for completion of 
        the earlier message and then return the response synchronously. (By the 
        way, this clarification does not belong in this section because of the 
        inconsistency (cited in red) 
        above. 

        
<<Somehow just saying ignore seems wrong, I 
        know.  However, we certainly do not need to contact the Application 
        and request a business reply again.  Either the first message is 
        still doing that or the whole thing is hung and there is nothing the MSH 
        can do.  I don't know what else to do besides ignore 
        the resent message and wait for the completion of the old -- which 
        will send an Acknowledgment when it is finished (if it ever 
        finishes).>>

        
(b)    Otherwise, 
        generate an Acknowledgment 
        Message .

        
A Receiving 
        MSH node is NOT participating in the reliable messaging protocol for 
        a received message if that message either; does not contain an AckRequested element, or 
        does contain an AckRequested element that is 
        not targeted at the Receiving 
        MSH, because it is acting in a role other than that specified in the 
        SOAP actor attribute of the received message. If the Receiving MSH node is operating 
        as an intermediary along the message's message path, then it MAY use 
        store-and-forward behavior. However, it MUST NOT filter out perceived 
        duplicate messages from their normal processing at that node. (see 
        section 11.2)

        7.5.3       
        Generating an Acknowledgment Message
        
An Acknowledgment Message MUST be 
        generated whenever a message is received with an AckRequested element that 
        has a SOAP actor URI which targets the Receiving MSH 
        node.

        
As a minimum, it MUST contain a MessageData element with a 
        RefToMessageId that contains 
        the same value as the MessageId element in the 
        message being acknowledged and an Acknowledgment 
        element.

        
The above paragraph contradicts 
        an earlier statement in section 7.5 (before 7.5.1): 

        
<<agreed.  Actually, the 
        RefToMessageId is now in the 
        Acknowledgment element.>> 

        
An Acknowledgment Message MUST 
        contain a MessageData element with a 
        RefToMessageId that contains 
        the same value as the MessageId element in the message being acknowledged and 
        an Acknowledgment element as 
        described in section 7.3.1.

        
It is important to reiterate 
        that the Acknowledgment message must be persisted before being sent. 
        Need to say something about the persist duration for this message. 
        Presumably, this can be the same as the persist duration for the 
        incoming message. In fact, the definition of PersistDuration in section 
        7.4.6 needs to be expanded to cover "first response" messages. 

        
<<PersistDuration on the response message 
        should be the same as on the First Message.  
        OK, persistDuration is an interval.  Is this since the 
        original timestamp or since the timestamp on the response 
        message?>> 

        
Depending on the value of the syncReply parameter, the Acknowledgment Message can be 
        sent at the same time as the response to the received message. In this 
        case, the values for the MessageHeader elements of 
        the Acknowledgment Message 
        are determined by the Service and Action associated with the 
        business response.

        
If syncReply is not 
        specified in the incoming message or is not applicable to the delivery 
        channel being used, then the CPA must be consulted to determine the 
        delivery channel that is suitable for the Acknowledgment action. This 
        delivery channel must not specify the use of Reliable Messaging! 

        
<<OK, what if there is no CPA?  Can I change 
        the above to say "if there is a CPA, 
        then...">> 

        
If an Acknowledgment Message is being 
        sent on its own, then the value of the MessageHeader elements MUST 
        be set as follows:

        
·      
        The Service element MUST be set 
        to: uri:www.oasis-open.org/messageService/

        
·      
        The Action element MUST be set 
        to Acknowledgment.

        
·      
        The From element MAY be 
        populated with the To element extracted from 
        the message received and all child elements from the To element received SHOULD 
        be included in this From element.

        
·      
        The To element MAY be populated 
        with the From element extracted from 
        the message received and all child elements from the From element received SHOULD 
        be included in this To element.

        
·      
        The RefToMessageId element MUST 
        be set to the MessageId of the message 
        received.

        7.5.6       
        Failed Message Delivery
        
If 
        a message sent with an AckRequested element cannot 
        be delivered, the MSH or process handling the message (as in the case of 
        a routing intermediary) SHALL send a delivery failure notification to 
        the From Party. The delivery 
        failure notification message contains:

        
·      
        a From element that identifies 
        the Party who detected the 
        problem

        
·      
        a To element that identifies the From Party that created the 
        message that could not be delivered

        
·      
        a Service element and Action element set as 
        described in 4.2.3.3.

        
·      
        an Error element with a 
        severity of:

        
-          
        Error if the party who 
        detected the problem could not transmit the message (e.g. the 
        communications transport was not available)

        
-          
        Warning if the message was 
        transmitted, but an Acknowledgment Message was not 
        received. This means the message probably was not delivered.

        
·      
        an ErrorCode of DeliveryFailure

        
It is possible that an error message with an Error element with an ErrorCode set to DeliveryFailure cannot be 
        delivered successfully for some reason.  If this occurs, then the From Party that is the ultimate 
        destination for the error message MUST be informed of the problem by 
        other means.  How this is 
        done is outside the scope of this specification

        
Note:  If the From Party MSH 
        receives an Acknowledgment Message from the To Party 
        MSH, it SHOULD ignore all other DeliveryFailure or 
        Acknowledgment Messages.

        
If syncReply is in use, then the 
        error message should be returned synchronously. Otherwise, the CPA needs 
        to be consulted to determine the appropriate delivery channel for the 
        MessageError action.