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: T2, Proposed solution for ... Re: SyncReplyandReliableMessagingMethod in QualityOfServiceInfo


David,

persistDuration applies in this case. It specifies how long an
MSH will keep the necessary information (usually MessageId) 
in persistent storage so that idempotency checks can be assured.

As for some additional parameter in the CPA that indentifies
the NRR archival parameters (how long will I keep messages,
not just the artifacts for business/legal reasons) I think that
should be taken up by the CPP/A team. 

I don't think that it is the MSH responsibility to perform
the archive-for-nrr-audit function. That could be handled
at a level above the MSH.

Cheers,

Chris

David Fischer wrote:
> 
> Chris,
> 
> Yes, I agree.  Should we specify something here rather than leave it as
> implementation dependant?  Making a note about minimum times between GC might
> help with Interoperability.  Unfortunately, I can see this as a site parameter
> rather than a CPA value -- could be a problem.  Any ideas what to do?
> 
> Regards,
> 
> David Fischer
> Drummond Group.
> 
> -----Original Message-----
> From: Chris.Ferris@Sun.COM [mailto:Chris.Ferris@Sun.COM]
> Sent: Thursday, September 20, 2001 9:59 AM
> To: David Fischer
> Cc: Dan Weinreb; arvola@tibco.com; ebxml-msg@lists.oasis-open.org
> Subject: Re: T2, Proposed solution for ... Re: SyncReply
> andReliableMessagingMethod in QualityOfServiceInfo
> 
> David,
> 
> Let's not confuse GC with NRR archiving requirements.
> From an RM perspective, the MSH must be able to perform GC
> or it cannot be expected to perform with any degree of
> efficiency.
> 
> Cheers,
> 
> Chris
> 
> David Fischer wrote:
> >
> > We have discussed this in the past and I have asserted that garbage collection
> > would actually never happen at the To Party (unless it was some sort of IM
> such
> > as a Mailroom).  For legal reasons, garbage collection of business documents
> > cannot occur until after 7 years (garbage collection is not in the spec is
> it?).
> > Instead of garbage collection, the To Party might occasionally Archive, which
> > almost amounts to the same thing.  Even this would be infrequent.
> >
> > I suppose such a restriction would have something to do with either
> > PersistDuration, TimeToLive or n*Retries*RetryInterval.  Or maybe this is
> > something new which should go in the CPA?  I would lean toward PersistDuration
> > but I am not sure we have a definitive understanding of what this should be.
> > OTOH, this question might be out of scope.
> >
> > Ralph works for an EDI software company, how often is archiving typically
> done?
> > Is it done?
> >
> > Regards,
> >
> > David Fischer
> > Drummond Group.
> >
> > -----Original Message-----
> > From: Dan Weinreb [mailto:dlw@exceloncorp.com]
> > Sent: Wednesday, September 19, 2001 10:25 PM
> > To: david@drummondgroup.com
> > Cc: arvola@tibco.com; ebxml-msg@lists.oasis-open.org
> > Subject: Re: T2, Proposed solution for ... Re: SyncReply and
> > ReliableMessagingMethod in QualityOfServiceInfo
> >
> >    Date: Wed, 19 Sep 2001 21:30:37 -0500
> >    From: David Fischer <david@drummondgroup.com>
> >
> >                                                         The From Party can
> perform
> >    a Retry at any time it deems appropriate.
> >
> > Well, actually, I think there has to be some kind of restriction or
> > else the To Party would never be able to garbage-collect its set of
> > already-received message ID's, as we've discussed in the past.
> >
> > ----------------------------------------------------------------
> > 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