OASIS ebXML Messaging Services TC

 View Only

Re: T2 SyncReply and ReliableMessagingMethod in QualityOfServiceInfo

  • 1.  Re: T2 SyncReply and ReliableMessagingMethod in QualityOfServiceInfo

    Posted 08-10-2001 11:35
    Chris:
    
    In that case, the quoted excerpt from the CPP/A spec is incorrect and needs
    to be fixed in the 1.1 version.
    
    This actually poses a small problem for mapping the RosettaNet headers to
    the ebXML headers because sync response is always explicitly indicated in
    the request message. What if the CPA between the two parties allows both
    synchronous and asynchronous response for the same business process?
    
    Thanks,
    -Arvola
    
    ----- Original Message -----
    From: "christopher ferris" <chris.ferris@east.sun.com>
    To: "Arvola Chan" <arvola@tibco.com>
    Cc: "David Fischer" <david@drummondgroup.com>; "Burdett David"
    <david.burdett@commerceone.com>; "ebXML Messaging (E-mail)"
    <ebxml-msg@lists.oasis-open.org>; <ebxml-cppa@lists.oasis-open.org>
    Sent: Friday, August 10, 2001 4:09 AM
    Subject: Re: T2 SyncReply and ReliableMessagingMethod in
    QualityOfServiceInfo
    
    
    > Arvola,
    >
    > It was not the intent to require use of the syncReplyMode
    > attribute (and hence the Via). The two parties exchanging
    > messages point-to-point are assumed to "know" by virtue of
    > their CPA (or the virtual equivalent of one) what their
    > syncReplyMode is. The Via element needs this because the
    > intermediaries don't have access to this information.
    >
    > Cheers,
    >
    > Chris
    >
    > Arvola Chan wrote:
    > >
    > > David:
    > >
    > > I don't think using a second DeliveryChannel will work. The following is
    an
    > > excerpt from the CPP/A spec:
    > >
    > > The ebXML Message Service's syncReply attribute is set to a value of
    "true"
    > > whenever the 1190
    > > syncReplyMode attribute has a value other than "none". 1191
    > >
    > > Even if you have a channel that calls for the use of synchronous reply
    mode,
    > > the syncReply attribute still has to be set. In other words, it is still
    > > necessary to use the Via element if the syncReply attribute is present
    only
    > > there, but this constradicts the assumption that the Via element is only
    > > used when intermediaries are involved.
    > >
    > > -Arvola
    > >
    > > ----- Original Message -----
    > > From: "David Fischer" <david@drummondgroup.com>
    > > To: "Arvola Chan" <arvola@tibco.com>; "Burdett David"
    > > <david.burdett@commerceone.com>
    > > Cc: "ebXML Messaging (E-mail)" <ebxml-msg@lists.oasis-open.org>
    > > Sent: Thursday, August 09, 2001 7:45 PM
    > > Subject: RE: T2 SyncReply and ReliableMessagingMethod in
    > > QualityOfServiceInfo
    > >
    > > > This was my original proposal, syncReply in both.  However, I was told
    > > this
    > > > could be accomplished using a second DeliveryChannel.  While this is
    not
    > > my
    > > > first preference, it would work...  <shrug>
    > > >
    > > > David Fischer
    > > > Drummond Group
    > > >
    > > > -----Original Message-----
    > > > From: Arvola Chan [mailto:arvola@tibco.com]
    > > > Sent: Thursday, August 09, 2001 12:24 PM
    > > > To: Burdett David; David Fischer (E-mail)
    > > > Cc: ebXML Messaging (E-mail)
    > > > Subject: Re: T2 SyncReply and ReliableMessagingMethod in
    > > > QualityOfServiceInfo
    > > >
    > > >
    > > > David:
    > > >
    > > > I was mostly concerned with how to obtain synchronous replies in the
    > > single
    > > > hop case, assuming the Via element is to be used exclusively for
    multi-hop
    > > > scenarios. I didn't realize there is a need to have syncReply vary hop
    by
    > > > hop.
    > > >
    > > > I think it is reasonable to have syncReply both in the QOS and in the
    Via
    > > > elements, and to say that the information in the Via element overrides
    the
    > > > information in the QOS element. I don't have any particular preference
    > > > between the names Via versus RoutingHeader.
    > > >
    > > > Thanks,
    > > > -Arvola
    > > >
    > > > -----Original Message-----
    > > > From: Burdett, David <david.burdett@commerceone.com>
    > > > To: David Fischer (E-mail) <david@drummondgroup.com>; 'Arvola Chan'
    > > > <arvola@tibco.com>
    > > > Cc: ebXML Messaging (E-mail) <ebxml-msg@lists.oasis-open.org>
    > > > Date: Thursday, August 09, 2001 9:57 AM
    > > > Subject: RE: T2 SyncReply and ReliableMessagingMethod in
    > > > QualityOfServiceInfo
    > > >
    > > >
    > > > >Arvola
    > > > >
    > > > >I disagree. You need syncReply in the Via. The attached PDF file
    titled
    > > > "Why
    > > > >you need syncReply in the Via" contains a diagram which illustrates
    the
    > > use
    > > > >case. Where the first hop is synchronous and the second not.
    > > > >
    > > > >If we want Via to be used only when intermediaries are being used
    then
    > > you
    > > > >would need ackRequested held elsewhere, e.g. in the Quality of
    Service.
    > > > >However since syncReply can vary from hop to hop (see previous
    example),
    > > > you
    > > > >would then need to also have it in the Via and a rule that the Via
    > > > >over-rides the QoS.
    > > > >
    > > > >There is also the issue that the sender of a message may not know
    that it
    > > > is
    > > > >multiple hop as the PDF file titled "Using ebXML RM behind the
    firewall"
    > > > >illustrates. In this case external communications are done
    synchronously,
    > > > >but the messaging to an application within the company is done
    > > > >asynchronously.
    > > > >
    > > > >I think we need to keep ackRequested and syncReply in the Via, but
    rename
    > > > it
    > > > >... to "Routing Header" perhaps, although I have no strong preference
    ...
    > > > ;)
    > > > >
    > > > >I'd appreciate your thoughts on these use cases.
    > > > >
    > > > >David
    > > > >PS Slides very similar to these two were posted ages ago and
    discussed in
    > > > >Tokyo last November I think.
    > > > >
    > > > >
    > > > >-----Original Message-----
    > > > >From: Arvola Chan [mailto:arvola@tibco.com]
    > > > >Sent: Wednesday, August 08, 2001 6:59 PM
    > > > >To: David Fischer; ebXML Msg
    > > > >Subject: Re: T2 SyncReply and ReliableMessagingMethod in
    > > > >QualityOfServiceInfo
    > > > >
    > > > >
    > > > >David:
    > > > >
    > > > >Sorry for the delayed response. I agree with you that the Via element
    > > > should
    > > > >be used exclusively for those cases where intermediaries are
    involved.
    > > > >Therefore, it makes sense to move the syncReply and ackRequested
    > > attributes
    > > > >to be under the QualityOfServiceInfo element.
    > > > >
    > > > >Since there already is a deliverySemantics attribute under the
    > > > >QualityOfServiceInfo element, and the reliableMessagingMethod
    attribute
    > > can
    > > > >vary from one hop to another, I think reliableMessagingMethod should
    stay
    > > > in
    > > > >the Via element.
    > > > >
    > > > >Regards,
    > > > >-Arvola
    > > > >
    > > > >-----Original Message-----
    > > > >From: David Fischer <david@drummondgroup.com>
    > > > >To: ebXML Msg <ebxml-msg@lists.oasis-open.org>
    > > > >Date: Monday, August 06, 2001 8:51 PM
    > > > >Subject: T2 SyncReply and ReliableMessagingMethod in
    QualityOfServiceInfo
    > > > >
    > > > >
    > > > >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
    >