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: FW: T2 SyncReply and ReliableMessagingMethod inQualityOfServiceInfo


Marty, as complex as it may get, we have to support end-to-end RM and we have to
allow IM RM.

David Fischer
Drummond Group.

-----Original Message-----
From: christopher ferris [mailto:chris.ferris@east.sun.com]
Sent: Wednesday, August 08, 2001 7:02 PM
To: ebXML Msg
Subject: Re: FW: T2 SyncReply and ReliableMessagingMethod
inQualityOfServiceInfo


Please see below.

Cheers,

Chris

Martin W Sachs wrote:
<snip/>
>
> Retries would have to go all the way to the end.  You could have situations
> where 2 reties to 3 at the same time 3 retries to 4 so 4 receives two
> identical
> messages at the same time it retries to 5 so 5 receives three while
> retrying to
> 6 so 6 receives 4 retries (maybe 5 if 1 has a short retryInterval).  Sounds
> nasty.  Maybe there's a way to avoid this?
>
> MWS:  You are brilliantly supporting my comment above about excess
> complexity.
> The solution is: don't let the intermediaries send their own ACKS or do
> RM between them.

How does this satisfy the use case (a seemingly reasonable one IMO)
where a SME uses an intermediary as a way station between itself
and another intermittently connected partner?

The SME wants to connect, send/receive and disconnect (because it doesn't
have a permanent presence such as the case where it connects through
an ISP) with some assurance that the message, once safely delivered to
the intermediary, will eventually reach its intended destination.

The intermediary(ies) (and ultimate recipient for that matter) doesn't want
to be saddled with a bunch of retransmissions simply because the sending
party is impatient (e.g. its retry interval is less than the mean time
that it takes for the recipient to retrieve and process its messages)
or the intended recipient is delinquent.

This also imposes significantly more overhead on the all of the parties
involved.
The sending party because it needs to remain connected longer
(to effect the retries it might well have off loaded to the intermediary).
The sending and receiving parties because each time they reconnect, they
must remain connected longer so that in addition to the new business, they
need to take care of the old, possibly if not likely duplicate, as well.
The intermediary because there's a decent chance that it is using some
manner of persistent store, whether because it seemed like a good
idea at the time, or simply because it is archiving messages for
calculation of subscription fees, or maybe because it wants to be
perceived as a robust service provider to its customers.

Each of the unnecessary retries, which the intermediaries in this model
blithley pass along adds to the number of duplicate messages, which increases
the connect/processing time, ad infinitum.

It isn't as if we (the TR&P team) haven't been down this path before.
This discussion is like deja vu all over again.

>
> Regards,
>
> David Fischer
> Drummond Group.
>
> -----Original Message-----
> From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
> Sent: Wednesday, August 08, 2001 4:16 PM
> To: David Fischer
> Cc: David Burdett; ebXML Msg
> Subject: Re: FW: T2 SyncReply and ReliableMessagingMethod in
> QualityOfServiceInfo
>
> Several points are relevant:
>
> 1.  There is no way to request an end-to-end acknowledgment in the CPA.
> The end-to-end acknowledgment should be mandatory. The CPA specifies
> delivery semantics, retries, retry interval, an and message order
> semantics.  It also specifies idempotency, which is not an option with
> reliable messaging and should be deleted from the CPA. That's all.  With
> delivery semantics of once and only once specified, use of ACKs should
> follow from the RM spec.
>
> 2.  The possibility of needing two ACKs should be a clue that RM is not
> specified properly for multihop.  What will the From party do with two
> ACKs?  There should be only one ACK - from the To party's MSH, propagated
> back through the multihop path.
>
> 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
>
********************************************************************************
>
> *****
>
> David Fischer <david@drummondgroup.com> on 08/08/2001 04:36:32 PM
>
> To:   David Burdett <david.burdett@commerceone.com>
> cc:   ebXML Msg <ebxml-msg@lists.oasis-open.org>
> Subject:  FW: T2 SyncReply and ReliableMessagingMethod in
>       QualityOfServiceInfo
>
> David,
>
> Below I asked someone to show me how to request an end-to-end
> Acknowledgement
> without using a CPA.  I am waiting for someone to tell me to just set the
> QualityOfServiceInfo deliverySemantics=OnceAndOnlyOnce and section 10.3.3
> says
> we MUST send back an Ack (reliableMessagingMethod cannot be set in
> MessageHeader
> but the default is "ebXML" anyway).  However, the Ack is to go back to the
> previous hop not back to the From Party.  We could say there needs to be
> two
> Acks, one for the previous hop and one end-to-end, but that was the whole
> reason
> you suggested having a second Ack called DeliveryReceipt.  Should we now
> dump
> DeliveryReceipt and send two Acks?
>
> My previous proposal was to dump AckRequested in Via and use one flag
> (DeliveryReceiptRequested) for both behaviors instead.  Maybe we should use
> deliverySemantics instead of AckRequested?
>
> Regards,
>
> David Fischer
> Drummond Group.
>
> -----Original Message-----
> From: David Fischer [mailto:david@drummondgroup.com]
> Sent: Wednesday, August 08, 2001 10:56 AM
> To: ebXML Msg
> Subject: RE: T2 SyncReply and ReliableMessagingMethod in
> QualityOfServiceInfo
>
> Chris, yelling the loudest does not make you right.  This is semi-amusing
> because your references prove you wrong!  One of your references doesn't
> even
> mention the DeliveryReceipt element?  How can that be used as an argument?
>
> As of right now, there is no method of sending an Acknowledgement from
> end-to-end except with the DeliveryReceipt (please, someone correct me/show
> me
> how and then I will shut up).  I don't have any preference how this is done
> as
> long as it can be done.  If the DeliveryReceipt gets changed to something
> it
> wasn't, fine, but we then have to replace it or change the functionality of
> something else to do the job -- we still have to have an MSH level
> DeliveryReceipt or Acknowledgement.
>
> Enough of this, I will answer only this once then I'm done.
>
> . . . Comments in-line.
>
> David Fischer
> Drummond Group.
>
> -----Original Message-----
> From: christopher ferris [mailto:chris.ferris@east.sun.com]
> Sent: Tuesday, August 07, 2001 11:58 PM
> To: ebXML Msg
> Subject: Re: T2 SyncReply and ReliableMessagingMethod in
> QualityOfServiceInfo
>
> David,
>
> I don't know what you're smoking. As for the history lesson, thanks,
> but I was there.
>
> <df> As was I, every meeting.  At some I was taking the minutes.  So?
> I was listening while you yelled.
>
> Actually, you were the one smoking... ;-)
> </df>
>
> The following references cite discussion that clearly demonstrates
> that the team had felt that the delivery receipt is an application-level
> response [1] [2] [3] [4] and that we endeavored to separate the two
> so that it was clear that DR was not related to RM. I could have
> dug up more fodder, but this is getting boring and it is late.
>
> <df> Good references.  I wish I had used them to prove my point.  They
> certainly
> do not prove yours.
> Yes, we realized we needed two separate acks if we were going to do
> multi-hop.
> This does not inherently make DeliveryReceipt a business level message.
> More
> comments on the references below.
> </df>
>
> The spec clarifies the distinction between the delivery receipt
> and the acknowledgment in section 8.4.7.1. To wit:
>
>      "The deliveryReceiptRequested attribute is used by a From Party
>      to indicate whether a message received by the To Party should
>      result in the To Party returning an acknowledgment message containing
>      a DeliveryReceipt element.
>
>      Note: To clarify the distinction between an acknowledgement message
>      containing a DeliveryReceipt and a Reliable Messaging Acknowledgement:
>      (1) An acknowledgement message containing a Delivery Receipt
>      indicates the To Party has received the message. (2) The Reliable
>      Messaging Acknowledgment indicates a MSH, possibly only an
>      intermediate MSH, has received the message."
>
> <df>Notice in the above quote, there is no mention of Business Level
> processes
> and also notice that the Delivery Receipt is an ACKNOWLEDGEMENT MESSAGE (it
> says
> it TWICE).  DeliveryReceipt is NOT for business level messages.  The
> purpose of
> the DeliveryReceipt is: "indicates the To Party has received the message"
> NOTHING MORE.  There is nothing here about business processes or business
> level
> signals.
>
> Since we have the syncReply method also available to us, a DeliveryReceipt
> can
> be included with a payload and that can be anything you like (business
> signals
> etc.) and since a DeliveryReceipt (8.15.8) can be on any message, the
> notification to the From Party might be a part of a larger message.  This
> does
> not make the DeliveryReceipt element a business level message.
> </df>
>
> I think that this clearly supports my view. Note that the entire section
> talks about the "To Party", not the "To Party's MSH" because, as I've
> said before, the DeliveryReceipt is a business level response. A
> "signal" in RosettaNet terms. It can be used for Nonrepudiation (signed)
> purposes, or simply to provide for the receiving application to tell
> the sending application (not MSH) that "the message was received... we'll
> get back to you soon". All of this is provided for and prescribed in
> a business process description using the BPSS. Maybe you should read
> that spec as well.
>
> The fact that the DeliveryReceipt and Acknowledgment were temporarily
> siamese twins was merely a marriage of convenience because they shared
> the same structure basically (although that has since evolved).
>
> <df> No, they were Siamese twins because they served the same purpose for
> two
> different situations -- hop-to-hop and end-to-end.
> </df>
>
> Section 8.14 states:
>
>      "The DeliveryReceipt element is an optional element that is used
>      by the To Party that received a message, to let the From Party
>      that sent the original message, know that the message was received.
>      The RefToMessageId in a message containing a DeliveryReceipt element
>      is used to identify the message being for which the receipt is being
>      generated by its MessageId."
>
> Again, it clearly states "To Party" which equates to "application" which
> means that it is a business level signal. Nowhere in this section will
> you find any discussion of reliable messaging because it is completely
> unrelated.
>
> <df>Are you saying that the words "To Party" always mean the application
> and not
> the MSH?  What are you smoking?  What about section 8.4.7.2:
>
>      If the To Party is unable to support the type of messageOrderSemantics
>      requested, then the To Party MUST report the error to the From Party
>      using an errorCode of NotSupported and a severity of Error.
>
> This would mean the Application would be supporting messageOrderSemantic
> and
> sending back related errors?  NOT!  How about section 9.2.1 & 9.2.2 which
> describes MSH level Ping & Pong?  Yet the spec says the response is sent:
>
>      The message is then sent to the To Party.
>
> The words "To Party" & "From Party" in these sections are used to describe
> the
> MSH, not an application.  BTW, Where is your definition defined in the
> spec?
>
> All the way through Section 10, the words "To Party" and "To Party MSH" are
> used
> interchangeably.  If you want to make such a distinction, we REALLY need to
> go
> through the spec.
> </df>
>
> A search of the Reliable Messaging section (10) in the spec turns up
> a whopping 0 (zero) occurances of the word DeliveryReceipt. Is that clear
> enough
> for you?
>
> <df> Yes, exactly.  RM was written from a multi-hop view and won't work
> end-to-end.  That's what we are trying to fix.</df>
>
> Regards,
>
> Chris
>
> [1] http://lists.ebxml.org/archives/ebxml-transport/200104/msg00007.html
> <df>This is the minutes of the meeting where DeliveryReceipt was added and
> it
> has nothing about the nature or description of the element</df>
>
> [2] http://lists.ebxml.org/archives/ebxml-transport/200102/msg00036.html
> <df>This one talks about the "Delivery Receipt" that the BP group is
> defining
> but there is no mention of our DeliveryReceipt element at all.</df>
>
> [3] http://lists.ebxml.org/archives/ebxml-transport/200104/msg00045.html
> <df>This is simply a quote from the current spec.  We discuss that
> above.</df>
>
> [4] http://lists.ebxml.org/archives/ebxml-transport/200104/msg00047.html
> <df>Yes, in his message Dick is understanding the implications.
> DeliveryReceipt
> is an Acknowledgement and he is concerned that we only need one (excerpt
> from
> link above):
>
>   > When I read the proposed changes it appears that a
>   > DeliveryReceipt is sent by the "To" party "to let the From party know
> that
>   > the message was received". This looks very similar to the purpose of an
>   > "Acknowledgement", it simply acknowledges receipt of the data by the To
>   > party, not that the data was delivered to the application. Is my
>   > understanding of this change correct? If it is then we really only need
> one
>   > type of "Acknowledgement" (a delivery acknowledgement).
>
> Yes, Dick understood EXACTLY what was happening.  He wanted a real Delivery
> Receipt, not the thing we were defining.  We defined (and still have) an
> MSH
> level DeliveryReceipt.  Maybe we should have used another name for
> end-to-end
> Acks.  Who knows?
> </df>
>
> <df>End of Comments</df>
>
> David Fischer wrote:
> >
> > Chris,
> >
> > Prior to London (or around that time) we did not have Acknowledgements or
> > DeliveryReceipts (there was a MessageType which could have a value of
> > "Acknowledgement") so it was NOT always like this.  The original name of
> the
> > Acknowledgement element was IntermediateAck (must have been an
> Intermediate
> > Acknowledgement).  The original intent of DeliveryReceiptRequested was to
> send
> > back an Acknowledgement message (we didn't have the DeliveryReceipt
> element
> > yet).
> >
> > > The deliveryReceiptRequested parameter/element MUST be used by a From
> > > Party MSH to indicate whether a message received by the To Party MSH
> > > should result in the To Party MSH returning an acknowledgment message
> > > containing an Acknowledgment element with a type of deliveryReceipt.
> >
> > This is your suggestion Chris (1/16/01).  Obviously the Original meaning
> of
> > DeliveryReceiptRequested was to send an Acknowledgement Message.  Let me
> quote
> > from David Burdett to Saha, Saikat  on 1/4/01 (RE: TRP spec 0.9a
> > comments/feedback):
> >
> > >> 3. Synchronous Messaging spec,. DeliveryReceipt and IntermediateAck.
> Why
> > >> both are required? Last intermediary
> > >> cannot produce IntermediateAck before it receives the DeliveryReceipt
> from
> > >> receiving MSH or intermediary nodes can create
> > >> IntermediateAck before they receive any response from next node?
> > > <DB>The whole idea of an intermediate ack is so that the intermediate
> node
> > > can return a response **before** they receive a reply from the next
> > > destination. This is useful particularly if end-to-end transmission
> times
> > > are long. This way, the sender of the initial message can turn off
> their
> > > timeout and rely on the intermediate node notifying them if they could
> not
> > > deliver the message. To draw an analogy with the real world, if you go
> to
> > > FedEX or UPS, they give you a receipt immediately. You don't hang
> around
> > > until your package has reached its final destination. You also don't
> keep on
> > > pestering FedEx to ask them if the package has got through.</DB>
> > ><DB>I could not follow these until I realised you are talking about 0.91
> and
> > > not 0.9a !!</DB>
> >
> > Chris, these have ALWAYS been Intermediate Acks and not end-to-end.  Let
> me
> > quote David Burdett on another message from the next day (1/5/01 -- RE:
> > SyncReplyMode as defined in .91 is a misnomer):
> >
> > > I am also uncomfortable with having two parameters that imply
> essentially
> the
> > > same thing. For example if deliveryReceiptRequested or
> > > immediateAckRequested are both set to NONE, then a syncReplyMode of
> > > AcksOnly or AcksAndResponse would be inconsistent. We really ought be
> able
> > > to avoid this sort of problem with the correct choice of parameters.
> >
> > > </DB>
> >
> > I still agree. David Burdett may prefer AckRequested rather than
> > DeliveryRequested (David?).  I think whatever parameter we use, we need
> only
> one
> > and it needs to be in the MessageHeader, not in Via (spec is broken if it
> is
> in
> > an element which has actor=next).
> >
> > On 2/26/01 (RE: CPA and Overrides) David Burdett identified the
> parameters
> which
> > pertained to individual hops:
> >
> > > 2. Parameters that apply to an indivual hop:
> > > - syncReplyMode (or whatever it gets renamed as - Prasad?)
> > > - errorURI
> > > - reliableMessagingMethod
> > > - AckRequeted (was IntermediateAckRequested)
> >
> > On 3/9/01 (Issue: We need separate acknowledgment and delivery receipt
> elements)
> > David Burdett added the DeliveryReceipt element:
> >
> > >>Section 8.13 Acknowledgment Element. I think we need to fix the
> > >> acknowledgement element so that you can have, in one message,both:
> > >> ·    a  "MSH acknowledgment" resulting from the ackRequested being set
> to
> > >> true, and also
> > >> ·    a "DeliveryReceipt Acknowledgment" arising from
> > >> DeliveryReceiptRequested being set to true.
> > >>
> > >> Currently if we have syncReply set to true (see lines 2444-7), then
> > >> although both are requested, only one could be returned.
> > >>
> > >> Having two elements would solve this problem: the current
> acknowledgement
> > >> element and a separate Delivery Receipt element with essentially the
> same
> > >> structure but a different meaning. Changes required are as follows ...
> >
> > /..snip
> > >>8.14 DeliveryReceipt Element
> > >>
> > >> The DeliveryReceipt element is used by a To Party that is the final
> > >> destination of a message to indicate to the From Party, that sent the
> > >> message, that the message has been received.
> > >> The DeliveryReceipt element has the same structure and content as the
> > >> Acknowledgement element (see section xx).
> >
> > Chris, this is not, nor has it ever been a business level Delivery
> Receipt.
> It
> > has always been a DeliveryReceipt Acknowledgement.  I see that you have
> always
> > misunderstood this as in 4/16/01 you wrote (Re: comments on David's
> proposed
> > changes):
> >
> > > A DR is a very different animal. I respectfully disagree
> > > with your assertion that we keep the From element in the
> > > DeliveryReceipt with the rationale that it overly complicates
> > > things from an implementation perspective.
> >
> > DR is not a different animal but you misunderstood from the beginning.
> So, I
> > went back and read all instances of DeliveryReceipt in the current spec
> and I
> > don't see what you are describing.  I see types of DeliveryReceipt
> (signed |
> > unsigned).  I see DeliveryReceipt in conjuction with a payload (as with
> > syncReply=true).  I see that the DeliveryReceipt can be specifically a
> > messageService service as in section 8.4.7.1:
> >
> >         · the Service element MUST be set to
> uri:www.ebXML.org/messageService/
> >         · the Action element MUST be set to DeliveryReceipt
> >
> > Chris, There is nothing in the spec describing your view of the
> DeliveryReceipt
> > element, nor is it born out in the eMail list.  DeliveryReceipt has
> always
> been
> > an MSH level Acknowledgement message and Acknowledgement
> (IntermediateAck) has
> > always been for hop-to-hop RM.
> >
> > Sorry for the length.
> >
> > David Fischer
> > Drummond Group
> >
> > -----Original Message-----
> > From: christopher ferris [mailto:chris.ferris@east.sun.com]
> > Sent: Tuesday, August 07, 2001 4:13 PM
> > To: David Fischer
> > Cc: Martin W Sachs; ebxml-msg@lists.oasis-open.org
> > Subject: Re: T2 SyncReply and ReliableMessagingMethod in
> > QualityOfServiceInfo
> >
> > David,
> >
> > I think that you must have misunderstood then.
> >
> > DeliveryReceipt has ALWAYS BEEN a business level response
> > message.
> >
> > Acknowledgment is not exclusive to use when there are
> > intermediaries. Acknowledgment is for MSH RM use exclusively.
> > We left DeliveryReceipt in the spec (actually calling out the
> > clear distinction between it and Acknowledgment) so as to provide
> > for use for business "signals" ala RosettaNet as prescribed by BPSS.
> >
> > ToParty != MSH
> > "ToParty MSH" == MSH
> >
> > ToParty == Application
> > FromParty == Application
> >
> > This has always been the case. That is the reason for the
> > very clear distinction between ToParty and ToParty MSH.
> >
> > The DeliveryReceipt, or NonRepudiationReceipt serve *business*
> > functions, not messaging functions. The source and target of a
> > DeliveryReceipt is an application, the "ToParty", not the messaging
> > software.
> >
> > Cheers,
> >
> > Chris
> > David Fischer wrote:
> > >
> > > No Chris, that's not what we decided.   We had long (heated)
> discussions
> about
> > > this in London and David (B) assured us that Acknowledgements were for
> > > intermediate hops only.  Acknowledgement (sp) only goes back to the
> previous
> > > hop.  This is why it is only in the Via.
> > >
> > > The DeliveryReceipt in the MSH is absolutely not a business level
> receipt.
> > The
> > > only mechanism we have to do end-to-end RM is through DeliveryReceipt.
> > Section
> > > 8.14 says
> > >
> > >         "The DeliveryReceipt element is an optional element that
> > >         is used by the To Party that received a message, to let the
> > >         From Party that sent the original message, know that the
> > >         message was received."
> > >
> > > This is only for receipt purposes -- no business processes.  We even
> built
> in
> > > NRR (critical functionality IMO).
> > >
> > > David Fischer
> > > Drummond Group.
> > >
> > > -----Original Message-----
> > > From: Chris.Ferris@Sun.COM [mailto:Chris.Ferris@Sun.COM]On Behalf Of
> > > christopher ferris
> > > Sent: Tuesday, August 07, 2001 11:58 AM
> > > To: David Fischer
> > > Cc: Martin W Sachs; ebxml-msg@lists.oasis-open.org
> > > Subject: Re: T2 SyncReply and ReliableMessagingMethod in
> > > QualityOfServiceInfo
> > >
> > > Note that DeliveryReceipt is orthogonal to RM. A message
> > > delieverd with BestEffort might require a DeliveryReceipt.
> > > The BPSS determines whether a DeliveryReceipt is necessary.
> > >
> > > DelieveryReceipt is an application-level response/signal,
> > > not a function of RM. It is the responsibility of some
> > > "external" software agent to initiate a DeliveryReceipt.
> > >
> > > What I mean by this is that the MSH itself, while it might
> > > be a part of a greater whole, is not responsible in and of itself.
> > >
> > > The MSH is a concept and it is given certain responsibilities
> > >
> > > How one implements an MSH, whether as a standalone peice
> > > of software or as part of a more comprehensive peice of
> > > infrastructure code is up to the implementer, not the
> > > authors of the MS specification.
> > >
> > > In my mind, DeliveryReceipt is more a function of Stefano's
> > > BSI or IBM's BPF.
> > >
> > > Cheers,
> > >
> > > Chris
> > >
> > > David Fischer wrote:
> > > >
> > > > Marty,
> > > >
> > > > The purpose of Acks is for hop-to-hop RM only.  The way it is set up
> now,
> > once
> > > > the message passes a hop which is not able to handle RM or doesn't
> need RM
> > > (like
> > > > MQseries) then none of the remaining hops will do RM since there is
> no way
> > to
> > > > reset AckRequested once it passes the unreliable hop.
> > > >
> > > > If intermediate-hop RM is not useful then why have Acks at all?
> End-to-end
> > RM
> > > > can be done strictly with DeliveryReceipts ;-).  But, I am not
> suggesting
> > > > getting rid of intermediate Acks, only getting rid of the
> AckRequested
> > > attribute
> > > > in Via.  We need intermediate Acks and we need intermediate-hop RM.
> We
> > don't
> > > > need end-to-end Acks because we already have DeliveryReceipt but they
> need
> > to
> > > > act the same for RM.  By removing AckRequested and using only
> > > > DeliveryReceiptRequested, the integrity of the RM request is
> maintained
> > > > throughout the path.  Any hop which can do RM then will (unless
> overridden
> > by
> > > a
> > > > local CPA).
> > > >
> > > > David Fischer
> > > > Drummond Group
> > > >
> > > > BTW, let's change Acknowledgment (or Acknowledgement) to Ack.  I
> liked
> that
> > > > idea!
> > > >
> > > > -----Original Message-----
> > > > From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
> > > > Sent: Tuesday, August 07, 2001 9:26 AM
> > > > To: ebxml-msg@lists.oasis-open.org
> > > > Cc: "Chris Ferris"
> > > > Subject: RE: T2 SyncReply and ReliableMessagingMethod in
> > > > QualityOfServiceInfo
> > > >
> > > >
> > >
> >
>
********************************************************************************
>
> > > > *****
> > > >
> > > > 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
> > > >
> > >
> >
>
********************************************************************************
>
> > > > *****
> > > > ---------------------- Forwarded by Martin W Sachs/Watson/IBM on
> 08/07/2001
> > > > 10:25 AM ---------------------------
> > > >
> > > > Martin W Sachs
> > > > 08/07/2001 10:24 AM
> > > >
> > > > To:   David Fischer <david@drummondgroup.com>
> > > > cc:
> > > > From: Martin W Sachs/Watson/IBM@IBMUS
> > > > Subject:  RE: T2 SyncReply and ReliableMessagingMethod in
> > > >       QualityOfServiceInfo  (Document link: Martin W. Sachs)
> > > >
> > > > Again, be careful with the ACKS.
> > > >
> > > > If the To and From parties are separated from each other by
> intermediaries
> > > > A, B, C in series, and B can't do reliable messaging:
> > > >
> > > > a) It doesn't matter that B can't do reliable messaging if the
> reliable
> > > > messaging protocol is betwen the To and From parties' MSHs, which is
> what
> > > > it should be.  The job of hops A, B, and C is simply to move the
> message
> > > > along.  I suppose that the A-B and B-C hops could do their own
> reliable
> > > > messaging under the covers but, as I said in the earlier posting, if
> C
> > > > loses the message before forwarding it to the To party, then the fact
> that
> > > > A-B and B-C are doing reliable messaging is of no value.  The message
> still
> > > > won't get to the To party.
> > > >
> > > > b) Aside from that, if hop B-C is generally unreliable, reliable
> messaging
> > > > can still be done between the To and From parties.  However, the To
> party's
> > > > MSH may have a higher than normal frequency of retries because of the
> low
> > > > quality of hop B.
> > > >
> > > > 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
> > > >
> > >
> >
>
********************************************************************************
>
> > > > *****
> > > >
> > > > David Fischer <david@drummondgroup.com> on 08/07/2001 09:42:09 AM
> > > >
> > > > To:   christopher ferris <chris.ferris@east.sun.com>
> > > > cc:   ebXML Msg <ebxml-msg@lists.oasis-open.org>
> > > > Subject:  RE: T2 SyncReply and ReliableMessagingMethod in
> > > >       QualityOfServiceInfo
> > > >
> > > > How do you set SyncReply on a message-by-message basis?  If I
> understand
> > > > you
> > > > correctly, syncReply MUST apply to ALL transfers between two parties
> or to
> > > > None -- must always be the same.  I think we may want a little more
> > > > flexibility.
> > > > We allow this flexibility in multi-hop, why not in single-hop?
> > > >
> > > > In EDIINT, syncReply was always default to True and we occasionally
> would
> > > > change
> > > > to False for very large files -- allowing the connection to close
> rather
> > > > than
> > > > wait (potentially hours) for a very large file to be decrypted or the
> MIC
> > > > to be
> > > > generated for a NRR.  (Instead of syncReply, EDIINT calls this



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


Powered by eList eXpress LLC