[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: T2 SyncReply and ReliableMessagingMethod in QualityOfServiceInfo
David, DeliveryChannel != service/action. I can have many service/action pairs serviced at a given delivery channel endpoint. The distinction between a synchronous and asynchronous endpoint has only to do with the technical processing and this can be captured as a separate endpoint identifier and there is nothing precluding the same service/action serviced by each delivery channel. Cheers, Chris "Burdett, David" wrote: > > Folks > > I strongly agree with Arvola. > > It is unrealistic require in the ebXML Messaging spec that each delivery > channel has a different endpoint. You should be able to use Service and > Action to identify which application should receive a message instead and > then route, if you want to, all messages to the same endpoint. > > Consider, for example, a payment service operated by a bank. This could > potentially be included in many different collaborations and CPAs for the > eCommerce sites that use the bank's service to do a credit card payment. > > I would suggest that what the bank wants to do is publish a single URL to > which all (or many) messages from different businesses are sent rather than > vary it for each business. > > ... or am I missing something ... > > David > > -----Original Message----- > From: Arvola Chan [mailto:arvola@tibco.com] > Sent: Tuesday, August 21, 2001 8:29 AM > To: David Fischer; Martin W Sachs > Cc: ebXML Msg > Subject: Re: T2 SyncReply and ReliableMessagingMethod in > QualityOfServiceInfo > > David: > > Marty is saying that we need to at least require delivery channels to > have unique endpoint addresses for 1.1. > > Using the ServiceBinding override mechanism, it is possible to > specify a delivery channel with syncReplyMode for a particular > action (for the receiver). > > From the CPA, both the sender and the receiver should know that the > action in question is associated with a unique delivery channel. When a > message arrives on the associated endpoint address, the receiver > should have no difficulty to know that it has to respond synchronously > because the delivery channel is a synchronous one. > > -Arvola > > -----Original Message----- > From: David Fischer <david@drummondgroup.com> > To: Martin W Sachs <mwsachs@us.ibm.com> > Cc: ebXML Msg <ebxml-msg@lists.oasis-open.org> > Date: Tuesday, August 21, 2001 8:00 AM > Subject: RE: T2 SyncReply and ReliableMessagingMethod in > QualityOfServiceInfo > > This is exactly the problem I see. How do I send to the same address but > slightly vary the parameters (change SyncReply from True to False)? Chris > suggested (I think) that all that was necessary was to define another > DeliveryChannel. I don't understand how this solves the problem since I > can't > figure out how to tell the receiver which DeliveryChannel to use -- maybe I > can't by design which means this solution won't work. This is too tightly > coupled! > > Am I missing the mark? If not, then I need to go back to my original > premise > that SyncReply needs to be in MessageHeader. > > Regards, > > David Fischer > Drummond Group. > > -----Original Message----- > From: Martin W Sachs [mailto:mwsachs@us.ibm.com] > Sent: Monday, August 20, 2001 10:20 PM > To: Arvola Chan > Cc: David Fischer; Christopher Ferris (E-mail); ebXML Messaging > (E-mail); ebxml-cppa@lists.oasis-open.org > Subject: Re: T2 SyncReply and ReliableMessagingMethod in > QualityOfServiceInfo > > 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> > > ---------------------------------------------------------------- > 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> > > ---------------------------------------------------------------- > 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