[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [ebxml-msg] Arvola's SyncReply issues
Hmmm... I suppose that would be acceptable Cheers, Chris David Fischer wrote: > OK with me. Any objections? > > > > Regards, > > > > David Fischer > > Drummond Group > > ebXML-MS Editor > > -----Original Message----- > From: Arvola Chan [mailto:arvola@tibco.com] > Sent: Thursday, January 03, 2002 9:58 PM > To: David Fischer; Doug Bunting; ebXML Msg > Subject: Re: [ebxml-msg] Arvola's SyncReply issues > > David: > > > > I am in favor of stating in the spec that SyncReply and AckRequested > targeted to the next MSH are incompatible, and that the next MSH > should return an Error with the code Inconsistent. > > > > Thanks, > > -Arvola > > ----- Original Message ----- > > From: David Fischer <mailto:david@drummondgroup.com> > > To: Arvola Chan <mailto:arvola@tibco.com> ; Doug Bunting > <mailto:dougb62@yahoo.com> ; ebXML Msg > <mailto:ebxml-msg@lists.oasis-open.org> > > Sent: Thursday, January 03, 2002 2:59 PM > > Subject: RE: [ebxml-msg] Arvola's SyncReply issues > > > Arvola, if you use a cascading Ack as you describe, why would > you ask for an Intermediate Ack? Isn't this the same as a > toPartyMSH Ack? We already support this kind of Ack. > > > > The problem is combining IM Acks with End-to-End SyncReply. > If you change to require the IM Ack to wait, then you have > defeated the purpose of IM RM (fire and forget). OTOH, if we > don't support End-to-End SyncReply with IM RM, then the problem > goes away. We could either get rid of IM Acks or get rid of > SyncReply (or both). > > > > Regards, > > > > David. > > -----Original Message----- > From: Arvola Chan [mailto:arvola@tibco.com] > Sent: Thursday, January 03, 2002 4:07 PM > To: Doug Bunting; ebXML Msg > Subject: Re: [ebxml-msg] Arvola's SyncReply issues > > Doug: > > > > I believe it was in the joint MSG/CPPA meeting in October in > Palo Alto that we decided that the 1.1 CPP/A spec would not > explicitly address the issue of intermediaries, and that the > use of intermediaries would have to be configured through > other means for now. > > > > If the sender asks for a synchronous reply as well as an > intermediate Acknowledgment, as opposed to an end-to-end > Acknowledgment, one possibility is for the intermediary to > withhold the intermediate Acknowledgment until it has gotten > the response (from the next intermediary or from the To > Party MSH), and then piggyback its intermediate > Acknowledgment on the response message. In this case, the > sender still only receives a single synchronous response as > opposed to an intermediate Acknowledgment and a response as > separate messages. If we decide to do this, some changes to > section 11 may be necessary. > > > > On point (12) below, I did mention > > > > I think there are actually four aspects of reliable > messaging behavior: (1) persisting the sent message and > retry on the part of the sender when an Acknowledgment is > not returned in time; > > > > Thanks, > > -Arvola > > ----- Original Message ----- > > From: Doug Bunting <mailto:dougb62@yahoo.com> > > To: ebXML Msg <mailto:ebxml-msg@lists.oasis-open.org> > > Sent: Thursday, January 03, 2002 1:10 PM > > Subject: Re: [ebxml-msg] Arvola's SyncReply issues > > > Arvola, > > I think you've hit upon an important point we need to > clarify in your comments on (6) below. SyncReply should > be meaningful with intermediaries between the From and > To parties. It doesn't sound as if the CPP/A > specification makes this allowance. I didn't think the > MSH specification described only receiving synchronous > responses from the To Party. > > I'd recommend it be possible for the From Party to > request the first set of MSH signals (errors or > acknowledgments) from the "expected" party. That would > support getting the acknowledgment back from the next > MSH in the case you've described below. I'm not sure > any changes are necessary in the MSH specification in > support of this. > > On point (12) below, don't forget the sender performing > retries as another aspect of reliable messaging :-) Of > course, "reliable messaging" is an overblown/generic > term we've been avoiding in favour of better defined > phrases like "once and only once" (meaning "once or get > a good error to the sending application"). > > later, > doug > > Arvola Chan wrote: > >> Doug: >> >> >> >> Please see my comments inline. >> >> >> >> Regards, >> >> -Arvola >> >> ----- Original Message ----- >> >> From:Doug Bunting <mailto:dougb62@yahoo.com> >> >> To: ebXML Msg <mailto:ebxml-msg@lists.oasis-open.org> >> >> Sent: Wednesday, January 02, 2002 1:48 PM >> >> Subject: [ebxml-msg] Arvola's SyncReply issues >> >> >> Arvola, >> >> >> >> I've snipped out a few of your comments that >> centre on the SyncReply element and embedded a few >> comments below. Hopefully, this will move us >> quickly towards resolving your questions. >> >> >> >> thanx, >> >> doug >> >> >> >> ----- Original Message ----- >> From:Arvola Chan <mailto:arvola@tibco.com> >> >> To: David Fischer <mailto:david@drummondgroup.com> >> ; ebXML Msg <mailto:ebxml-msg@lists.oasis-open.org> >> >> Sent: Wednesday, 02 January 2002 12:33 >> >> Subject: Re: [ebxml-msg] Messaging Spec v1.092 >> >> >> ... >> >> >> >> 6. Line 1412: I like to point out that a SyncReply >> element is not compatible with an AckRequested >> element that is targeted at the next MSH. >> >> I'm not sure why you're of this opinion. Why >> couldn't the next MSH synchronously reply with an >> Acknowledgment element (after it's persisted the >> incoming message, of course)? >> >> >> >> <ac> >> >> The From Party MSH expects a synchronous response >> from the To Party MSH. On the other hand, if the >> intermediary MSH returns the intermediate >> Acknowledgment synchronously after it has >> persisted the message, and then closes the HTTP >> connection (prior to forwarding the message), then >> how can the response from the To Party MSH be >> returned synchronously to the From Party MSH? >> >> </ac> >> >> >> >> 12. Line 1591: I think it may be problematical for >> the recipient to do duplicate elimination when no >> DuplicateElimination element is present. What >> happens if SyncReply is present and AckRequested >> is not present. If the incoming message is not >> passed on to the application, should any reply be >> returned to the sender? >> >> The DuplicateElimination semantics are described >> rather clearly in the specification. The answer >> to your question is that the synchronous reply >> must contain the first response to the duplicate >> message. The receiver application might not hear >> about the duplicate but the will get the same >> answer back as the first time. >> >> >> >> <ac> >> >> You are correct. I was confused by the statement >> on line 1788: "A Receiving MSH node is not >> participating in the reliable messaging protocol >> for a received message if the message either does >> not contain an AckRequested element, or ..." I >> think there are actually four aspects of reliable >> messaging behavior: (1) persisting the sent >> message and retry on the part of the sender when >> an Acknowledgment is not returned in time; (2) >> returning an Acknowledgment message by the >> receiver; (3) persisting the received message to >> allow duplicate elimination by the receiver; (4) >> automatic returning of the first response message >> without forwarding the message to the application >> when a duplicate message is received. (1) and (2) >> are triggered by the AckRequested element. (3) and >> (4) are triggered by the DuplicateElimination >> element, or if the receiver decides to do >> duplicate elimination in spite of the absence of a >> DuplicateElimination element in the incoming >> message. Line 1589 needs to clarify what adopting >> a reliable messaging behavior really means (really >> (3) and (4)). In the paragraph starting on line >> 1591, it will be helpful to qualify "although >> elimination of duplicates is still allowed" to >> mean that (3) and (4) are to be done. >> >> </ac> >> >> >> >> 20. Line 1733 and line 1738: These two bullet >> points assume that syncReplyMode in the CPA is not >> used with an asynchronous communication >> channel. This is in conflict with the 1.0 CPP/A >> spec statement quoted in item 15 above. I think >> this is a minor technical issue that may require >> some discussion. >> >> Would this be resolved by (more correctly) >> referencing the syncReplyMode semantics in the >> CPP/A 1.1 specification? If not, we still have a >> discrepancy between the two specifications and >> that should be resolved as soon as possible. The >> CPP/A 1.0 specification may have some vestiges of >> the "bundling" semantics I've mentioned before >> (using syncReplyMode to describe which signals may >> be bundled with the application response). Those >> semantics apply equally to synchronous and >> asynchronous channels. The current SyncReply MSH >> semantics are all about what signals must appear >> in the synchronous response over a synchronous >> channel. >> >> It's not up to the MSH to determine how later >> business responses might be bundled with business >> signals and asynchronous channels are therefore >> not relevant. Of course, the current description >> of an MSH doesn't provide a way to describe >> expectations around bundling of business responses >> and signals with MSH signals like the >> Acknowledgment element over an asynchronous >> channel. 2.0 issue? >> >> >> >> <ac> >> >> I think the simplest solution may be to request >> the CPP/A team to strike out from the 1.1 spec the >> following sentence: " If the delivery channel >> identifies a transport protocol that has no >> synchronous capabilities (such as SMTP) and the >> Characteristics element has a syncReplyMode >> attribute with a value other than "none", a >> response SHALL contain the same content as if the >> transport protocol did support synchronous >> responses." which contradicts the statement on >> line 1625: "The SyncReplyMode parameter from the >> CPA is used only if the data communications >> protocol is synchronous (e.g. HTTP)." We can defer >> the bundling issue for asynchronous communications >> protocols until the 2.0 versions of the MSG and >> CPP/A specs. >> >> </ac> >> >> >> >> ... >> >> >> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC