[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: T2 SyncReply and ReliableMessagingMethod in QualityOfServiceI nfo
Re-sending because of addressing error.
*************************************************************************************
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/08/2001
08:53 AM ---------------------------
Martin W Sachs
08/07/2001 03:41 PM
To: Scott Hinkelman/Austin/IBM@IBMUS
cc: "HUGHES,JIM (HP-Cupertino,ex1)" <jim_hughes@hp.com>,
ebxml-msg@lists.oasis-open.orgm ebxml-cppa
From: Martin W Sachs/Watson/IBM@IBMUS
Subject: RE: T2 SyncReply and ReliableMessagingMethod in QualityOfServiceI
nfo (Document link: Martin W. Sachs)
Scott,
It is not at all clear that a multiparty CPA is always needed to handle
intermediaries. It mostly depends on whether the intermediary particpates
in the business process between the from and to party or acts as a
pass-through. At the moment, the BPSS handles a multiparty collaboration
as a set of interconnected binary collaborations. That would be handled in
the year 2001 by a set of 2-party CPAs.
If the intermediary functions as a pass-through, then we would not need a
multiparty CPA. We probably would need support in the CPA for pass-through
intermediaries. This is on the CPPA list of proposed work items and would
be done in collaboration with the MSG team.
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
*************************************************************************************
Scott Hinkelman/Austin/IBM@IBMUS on 08/07/2001 01:16:53 PM
To: "HUGHES,JIM (HP-Cupertino,ex1)" <jim_hughes@hp.com>
cc: ebxml-msg@lists.oasis-open.org
Subject: RE: T2 SyncReply and ReliableMessagingMethod in QualityOfServiceI
nfo
I agree. RM is From <-> To.
However, does this imply that if a CPA is used, and IMs are in the
picture that multiparty (if an IM is a party) CPA is required? Seems to me.
Scott Hinkelman, Senior Software Engineer
XML Industry Enablement
IBM e-business Standards Strategy
512-823-8097 (TL 793-8097) (Cell: 512-940-0519)
srh@us.ibm.com, Fax: 512-838-1074
"HUGHES,JIM (HP-Cupertino,ex1)" <jim_hughes@hp.com> on 08/07/2001 09:59:45
AM
To: ebxml-msg@lists.oasis-open.org
cc:
Subject: RE: T2 SyncReply and ReliableMessagingMethod in QualityOfServiceI
nfo
Marty's answer is precisely why we had difficulties in introducing
multi-hop
RM in MSS V1. I agree with Marty's general observation of the purpose of
RM,
though I would word it as "getting confirmation of message delivery between
the FromParty MSH and the ToParty MSH" -- pointedly, whether there are
intermediate MSH nodes (running RM or not) or static on the wire is not
material, as both scenarios could introduce failure. This is a MSH-level
session protocol, if you will, that just involves the two MSH end points.
Maybe you get more "reliability" if an intermediate MSH node pair use
MQseries, but I think it really confuses the issue when you allow the
presence of intermediate nodes to affect the basic RM algorithm. I think
that a node's use of RM should be quite distinct from the (higher layer?)
RM
between the endpoint MSHs.
jim
> -----Original Message-----
> From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
> Sent: Tuesday, August 07, 2001 9:42 AM
> To: David Fischer
> Cc: ebxml-msg@lists.oasis-open.org
> Subject: RE: T2 SyncReply and ReliableMessagingMethod in
> QualityOfServiceInfo
>
>
>
> In my mind, the only meaningful purpose of reliable messaging
> is to get a
> message from the From Party's application to the To Party's
> application
> once and only once. Everything else is details of how to do
> it. Further,
> it cannot be guaranteed that there will never be a failure to
> deliver a
> message, then the From Party's application is owned a
> guaranteed delivery
> failure notification. Multihop complicates the definition and
> implementations but it does not change the purpose.
>
> 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 11:22:54 AM
>
> To: Martin W Sachs/Watson/IBM@IBMUS, ebxml-msg@lists.oasis-open.org
> cc:
> Subject: RE: T2 SyncReply and ReliableMessagingMethod in
> QualityOfServiceInfo
>
>
>
> 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 parameter
> Receipt-Delivery-Option). IMO, we need to allow for the unforeseen.
>
> In the case of ReliableMessagingMethod, I'm not even sure
> what this does or
> why
> we need it at all. What does a value of "Transport" mean -- the spec
> doesn't
> say? I assume it means just send the message and don't worry about RM
> since
> this hop can't handle it? I think this will never be used
> but David seemed
> to
> think it was needed and I don't have any heartburn with that.
> Since I this
> sits
> right next to SyncReply in the Ack, I included it in
> parameters which need
> to be
> allowed without an Ack. Either way is fine with me.
>
> David.
>
> -----Original Message-----
> From: christopher ferris [mailto:chris.ferris@east.sun.com]
> Sent: Tuesday, August 07, 2001 5:58 AM
> To: David Fischer
> Cc: ebXML Msg
> Subject: Re: T2 SyncReply and ReliableMessagingMethod in
> QualityOfServiceInfo
>
>
> David,
>
> Where does this requirement come from? In the case of
> syncReply, the CPA is what determines this. In the absence
> of a CPA, then a virtual CPA applies.
>
> Cheers,
>
> Chris
>
> David Fischer wrote:
> >
> > There should be nothing in the Via which is not also in
> other headers.
> Via
> > should only be used for multi-hop intermediaries. In the case of
> SyncReply,
> > there is no single-hop way of requesting SyncReply=true.
> >
> > Attributes SyncReply and ReliableMessagingMethod should also be in
> > QualityOfServiceInfo. They should retain their current defaults.
> >
> > Regards,
> >
> > David Fischer
> > Drummond Group.
> >
> > ------------------------------------------------------------------
> > To unsubscribe from this elist send a message with the single word
> > "unsubscribe" in the body to: ebxml-msg-request@lists.oasis-open.org
>
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-msg-request@lists.oasis-open.org
>
>
>
>
>
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-msg-request@lists.oasis-open.org
>
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-msg-request@lists.oasis-open.org
>
>
>
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-msg-request@lists.oasis-open.org
>
------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-msg-request@lists.oasis-open.org
------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-msg-request@lists.oasis-open.org
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC