OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

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

Subject: RE: [ebxml-msg] Interaction betweenAckRequested,DuplicateElimination,and SyncReply elements

The behavior that Arvola describes 
(about resending cached business
responses or waiting for one to 
become available)
is described in the section on
resending acknowledgments, 6.5.5.

The presence of DuplicateElimination by itself 
is to implement "At Most Once" delivery (or
so the spec says). Doesn't say it is supposed
to support caching responses and returning
them if a duplicate is received.

I did not interpolate that some sub-behavior from 6.5.5
applied to the DuplicateElimination on its own case.

I think you have to state that explicitly
if that is what the receiving MSH is supposed to do
It is currently not clear from the spec because
as Arvola emphasizes,  the spec. says
to do nothing in the DuplicateElimination by
itself case.

Dale Moberg

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


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
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?


Arvola Chan wrote:

> Doug:
> In earlier versions of the spec when we had only the concept of
> Messaging and not separate control of AckRequested and
> it was clear that whenever a receiver receives a reliably delivered
> that is not a duplicate, it is obligated to at least make a persistent
> of the message ID as well as a persitent copy of the first response
> When a received reliably delivered message is determined to be a
> the receiver is supposed to return the saved first response message.
> Now that AckRequested and DuplicateElimination can be controlled
> 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
> is triggered by the AckRequested element or by the
> 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
> elimination flag indicates that response must have been stored.)  The
> is
> incomplete around a more specific sub case of what you've described:
> syncReplyMode="MSH Signals" (or whatever the next level above "none"
> called)
> and not a mode involving application information.  With that
> 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
> retry
> cycles.  However, sending a "real" body (probably, just an ebXML
> MessageHeader
> element) in the synchronous reply could be useful for duplicate
> 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
> > implemented ebMS 2.0.
> >
> > If the sender MSH includes a DuplicateElimination element and a
> > element, but no AckRequested element in an ebXML message, and the
> > MSH determines that the received message is a duplicate, should it
> 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
> > parameter kicks in either on the sending or receiving side. This
> > seem an efficient way of using network resources. Can "do nothing"
> > interpreted as closing the connection, or returning a 200 OK status
> 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>

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

Powered by eList eXpress LLC