RE: [ebxml-msg] InteractionbetweenAckRequested,DuplicateElimination,and SyncReply elements

[Arvola Chan <arvola@tibco.com>]

Doug:

Thanks for pointing out about the existence of

http://www.oasis-open.org/committees/ebxml-msg/documents/ebMS_v2_0.pdf

The TC web page

http://www.oasis-open.org/committees/ebxml-msg/

needs to be updated. It still shows:

"The revision of the Message Service Specification to version 2.0  revision
C has been completed. The formal voting process is now underway. The
specification and outstanding issues may be found in the documents section
below."

I agree with your statement: "My interpretation of that section was that a
message identifier would only be found in the persistent store and a
duplicate detected if DuplicateEllimination appeared in the original
message." My issue is whether cacheing of the response message and returning
the cached response message in reply to a duplicate message is triggered
only by the presence of the AckRequested element. My reading of
ebMS_v2_0.pdf is that the presence of the DuplicateElimination element alone
would not trigger the above cacheing behavior.

I also agree with your suggestion that the HTTP binding section should
clarify what "ignoring" an incoming message means, and that returning an
empty HTTP response would be appropriate.

Thanks,
-Arvola


-----Original Message-----
From: Doug Bunting [mailto:db134722@iPlanet.com]
Sent: Wednesday, March 27, 2002 2:44 PM
To: ebXML Msg
Subject: Re: [ebxml-msg] Interaction
betweenAckRequested,DuplicateElimination,and SyncReply elements


Arvola,

My interpretation of that section was that a message identifier would only
be
found in the persistent store and a duplicate detected if
DuplicateEllimination
appeared in the original message.  The sentence at line 1669 in this version
of
the document also makes this clear.  What more would you like to see?

By the way, the final 2.0 draft is found at
http://www.oasis-open.org/committees/ebxml-msg/documents/ebMS_v2_0.pdf  Our
references to lines in 2.0C should be updated to match this later version as
follows:
    1664 -> 1666
    1669 -> 1670
    1680 -> 1681

The separate "what does ignore mean?" question remains.  I would recommend
we
explicitly describe this situation in the HTTP binding section and choose
either
to return a "bare" MessageHeader or completely empty HTTP response with 200
status when no information is available and things were successful.  I'd
lean
towards the empty HTTP response but that would change the description in
6.5.2
and elsewhere of a search for the first response.  (We'd need to expand
those
words to cover some special tag in the persistent data signifying an empty
response to a message with a particular message identifier.  The current
words
require waiting for another server side process to complete it's response to
the
earlier request.)

thanx,
    doug

Arvola Chan wrote:

> Doug:
>
> The section that causes me to take my stated interpretation is 6.5.2. Line
> 1664 specifies the processing steps in case the AckRequested element is
> present while line 1680 specifies the processing steps when the
AckRequested
> element is not present.
>
> Thanks,
> -Arvola
>
> -----Original Message-----
> From: Doug Bunting [mailto:db134722@iPlanet.com]
> Sent: Wednesday, March 27, 2002 1:39 PM
> To: ebXML Msg
> Subject: Re: [ebxml-msg] Interaction between
> AckRequested,DuplicateElimination,and SyncReply elements
>
> Hmmm,
>
> That wasn't my reading of 2.0 rev C.  If others agree it's a possible
> reading of
> the text, it should be fixed.  I agree with Arvola that duplicate
> elimination
> and returning a copy of the first response should be triggered by the
> DuplicateElimination element.  AckRequested should simply determine
whether
> or
> not that first response includes an Acknowledgment element.
>
> Were others confused?  What change would improve the wording?
>
> thanx,
>     doug
>
> Arvola Chan wrote:
>
> > Doug:
> >
> > In earlier versions of the spec when we had only the concept of Reliable
> > Messaging and not separate control of AckRequested and
> DuplicateElimination,
> > it was clear that whenever a receiver receives a reliably delivered
> message
> > that is not a duplicate, it is obligated to at least make a persistent
> copy
> > of the message ID as well as a persitent copy of the first response
> message.
> > When a received reliably delivered message is determined to be a
> duplicate,
> > the receiver is supposed to return the saved first response message.
> >
> > Now that AckRequested and DuplicateElimination can be controlled
> separately,
> > it is not clear whether the behavior to save the first response message
> and
> > to return the saved first response message in reply to a duplicate
message
> > is triggered by the AckRequested element or by the DuplicateElimination
> > element.
> >
> > I would have preferred that the above behavior be triggered by the
> > DuplicateElimination element. However, Version 2.0 rev C indicates that
> the
> > above behavior should only be exhibited by the receiver MSH if the
> > AckRequested element is present.
> >
> > Regards,
> > -Arvola
> >
> > -----Original Message-----
> > From: Doug Bunting [mailto:db134722@iPlanet.com]
> > Sent: Wednesday, March 27, 2002 11:58 AM
> > To: Arvola Chan
> > Cc: ebXML Msg
> > Subject: Re: [ebxml-msg] Interaction between AckRequested,
> > DuplicateElimination,and SyncReply elements
> >
> > [Please note: Yes, this is still me.  I had to change email addresses
due
> to
> > Yahoo! changes.]
> >
> > Arvola,
> >
> > This is a very good point covered slightly by issue 127 and might touch
on
> > issues 165-166.  If we must interpret "do nothing" or "ignore", it
should
> be
> > explained in the text or an errata.
> >
> > In this particular case, the sender isn't waiting for an MSH signal in
> > general.
> > It should be waiting for the (stored) business response.  (The
duplicated
> > elimination flag indicates that response must have been stored.)  The
text
> > is
> > incomplete around a more specific sub case of what you've described:
when
> > CPA
> > syncReplyMode="MSH Signals" (or whatever the next level above "none" is
> > called)
> > and not a mode involving application information.  With that
> clarification,
> > the
> > original message would also have a problem because no information was
> > available
> > to reply on the synchronous channel.
> >
> > The most efficient response when no information is really required would
> be
> > a
> > 200 OK.  Closing the connection would only tell the originator to start
> > retry
> > cycles.  However, sending a "real" body (probably, just an ebXML
> > MessageHeader
> > element) in the synchronous reply could be useful for duplicate
> elimination
> > cases, allowing the receiver to store something as their response.
> >
> > thanx,
> >     doug
> >
> > Arvola Chan wrote:
> >
> > > I like to address the following question, mostly to folks who have
> already
> > > implemented ebMS 2.0.
> > >
> > > If the sender MSH includes a DuplicateElimination element and a
> SyncReply
> > > element, but no AckRequested element in an ebXML message, and the
> receiver
> > > MSH determines that the received message is a duplicate, should it
> simply
> > do
> > > nothing, as prescribed on line 1681 in the Version 2.0 rev C spec?
> > >
> > > The problem of doing nothing is that the sender MSH is waiting for a
> > > synchronous reply. The connection will not get closed until some
timeout
> > > parameter kicks in either on the sending or receiving side. This
doesn't
> > > seem an efficient way of using network resources. Can "do nothing" be
> > > interpreted as closing the connection, or returning a 200 OK status
code
> > and
> > > closing the connection?
> > >
> > > -Arvola
> > >
> > > ----------------------------------------------------------------
> > > To subscribe or unsubscribe from this elist use the subscription
> > > manager: <http://lists.oasis-open.org/ob/adm.pl>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>