[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: T2, Proposed solution for ... Re: SyncReplyandReliableMessagingMethod in QualityOfServiceInfo
At this stage of the game functions like NRR archiving belong in the BPSS
instance document, not in the CPA. The CPA has not even begun to get into
business-level information though it may some day.
Regards,
Marty
*************************************************************************************
Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287; IBM tie line 863-7287
Notes address: Martin W Sachs/Watson/IBM
Internet address: mwsachs @ us.ibm.com
*************************************************************************************
christopher ferris <chris.ferris@Sun.COM>@Sun.COM on 09/20/2001 11:50:38 AM
Sent by: Chris.Ferris@Sun.COM
To: David Fischer <david@drummondgroup.com>
cc: Dan Weinreb <dlw@exceloncorp.com>, arvola@tibco.com,
ebxml-msg@lists.oasis-open.org
Subject: Re: T2, Proposed solution for ... Re: SyncReply
andReliableMessagingMethod 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>
----------------------------------------------------------------
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