Re: T2 SyncReply and ReliableMessagingMethod in QualityOfServiceInfo

[christopher ferris <chris.ferris@east.sun.com>]

Agreed!

Martin W Sachs wrote:
> 
> Arvola,
> 
> It's late at night and I have just gone through 140 emails accumulated
> Friday and today so maybe I am getting a bit dull.
> 
> Each party knows about its delivery channels and the other party's delivery
> channels and which one goes with each business transaction.  This is the
> information that is in the CPA and has to be installed in each party's
> system.
> 
> The missing element in your posting is the endpoint address, defined for
> each delivery channel.  As long as each delivery channel has a unique
> endpoint address, the From MSH should have no ambiguity in where to send
> each message and the To MSH has no ambiguity in which delivery channel to
> use for a received message.  Service and Action should be needed only by
> the To Party's MSH and only for routing to the application entry point.
> There may be a problem if one wants to define two delivery channels with
> the same endpoint address but slight variations in some parameters.  I
> believe that we have assumed that each delivery channel has a unique
> endpoint address but I suspect that we don't say so.  Allowing two
> different delivery channels to share an endpoint address would certainly
> require an additional piece of information that the To MSH would need to
> use to identify the correct receive channel for an incoming message.
> 
> I suggest that V1.1 state that every delivery channel SHALL have a unique
> endpoint address (if V1.0 doesn't say so).  For V2.0, we could consider
> permitting different delivery channls to share the same endpoint address
> and adding whatever disambiguator is required to make this work.
> 
> Regards,
> Marty
> 
> 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
> *************************************************************************************
> 
> Arvola Chan <arvola@tibco.com> on 08/20/2001 09:43:52 PM
> 
> To:   David Fischer <david@drummondgroup.com>, "Christopher Ferris
>       (E-mail)" <chris.ferris@east.sun.com>
> cc:   "ebXML Messaging (E-mail)" <ebxml-msg@lists.oasis-open.org>,
>       ebxml-cppa@lists.oasis-open.org
> Subject:  Re: T2 SyncReply and ReliableMessagingMethod in
>       QualityOfServiceInfo
> 
> David and Chris:
> 
> I have a similar issue. It is not clear to me that a sender MSH
> can uniquely determine a delivery channel to be used to send to
> a receiver without knowing the collaboration role played by the
> receiver.
> 
> The structure of the CPP/A elements is such that a Party
> may play multiple collaboration roles. For each such role,
> there can be one or more prioritized service bindings. Each
> service binding has a service element that essentially identifies
> the service provided by the party in question. Each service
> binding specifies a default delivery channel, along with zero
> or more override elements. Each override element pertains
> to a particular action and specifies the delivery channel for
> that action.
> 
> If the sender knows the role played by the receiver, then it
> is straightforward to determine the delivery channel that should
> be used in order to send the message to the receiver. However,
> there is no role element in the message header. If the Message
> Service Interface is defined in such a way that the burden of
> determining the delivery channel falls on the MSH, then I am
> not sure if the MSH has sufficient information to determine
> the delivery channel. The problem I see is that the service
> name associated with a service binding is not necessarily
> unique. Is it possible to have multiple roles played by the
> same receiver with service bindings that share the same
> service name? If so, it is not clear to me which corresponding
> delivery channel should be used. For this discussion, let's assume
> that none of the service bindings in the CPA have override elements.
> Thus, it is not possible to use the Action element in the message
> header to determine the delivery channel.
> 
> Regards,
> -Arvola
> 
> -----Original Message-----
> From: David Fischer <david@drummondgroup.com>
> To: Christopher Ferris (E-mail) <chris.ferris@east.sun.com>
> Cc: ebXML Messaging (E-mail) <ebxml-msg@lists.oasis-open.org>
> Date: Monday, August 20, 2001 5:33 PM
> Subject: RE: T2 SyncReply and ReliableMessagingMethod in
> QualityOfServiceInfo
> 
> Maybe I acceded to quickly?  I am trying to understand how to use another
> delivery channel to support SyncReply.  I see CPAid in the MessageHeader so
> the
> receiving end knows which CPA to use.  I guess the DeliveryChannel is
> chosen
> based upon which transport is involved.
> 
> What if there are two DeliveryChannels with the same transport.  One HTTP
> w/
> SyncReply=True and one HTTP w/ SyncReply=False, how does the receiver know
> which
> one to use?  The CPAid would be the same.  Do we need to append the
> DeliveryChannel ID on the end?
> 
> <eb:CPAid>CompanyA-003</eb:CPAid>
> 
> Where CPAid is "CompanyA" and the DeliveryChannel ID is "003"?  I'm not
> sure
> how
> the sender tells the receiver which DeliveryChannel to use.  Please forgive
> my
> ignorance but, how does this work?
> 
> David Fischer
> Drummond Group.
> 
> -----Original Message-----
> From: David Fischer [mailto:david@drummondgroup.com]
> Sent: Friday, August 10, 2001 10:37 AM
> To: Arvola Chan
> Cc: ebXML Messaging (E-mail)
> Subject: RE: T2 SyncReply and ReliableMessagingMethod in
> QualityOfServiceInfo
> 
> Arvola, I agree with you but I don't think this is a significant enough
> Requirement to fight for.  I will accede to the majority as long as it
> seems
> like a workable solution.
> 
> My personal opinion is that everything in the Via (CPA message related
> parameters) should also be represented in MessageHeader -- again I don't
> feel
> strongly enough about this to fight for it very much.
> 
> Regards,
> 
> David Fischer
> Drummond Group.
> 
> -----Original Message-----
> From: christopher ferris [mailto:chris.ferris@east.sun.com]
> Sent: Friday, August 10, 2001 6:09 AM
> To: Arvola Chan
> Cc: David Fischer; Burdett David; ebXML Messaging (E-mail);
> ebxml-cppa@lists.oasis-open.org
> 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
> 
> ------------------------------------------------------------------
> 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 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>