[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Regarding where SyncReply information can and/or should reside
Thanks Dale, No, I don't want to use Delivery Channels at all (per message or otherwise) for changing the value of SyncReply. One Delivery Channel is all we need (per transport). Please forget Delivery Channels were ever brought up. I just want to put SyncReply back in MessageHeader + QualityOfServiceInfo. SyncReply(Mode) was in QualityOfServiceInfo in v0.93 and it got taken out somehow. All I am asking is that it be put back in. Regards, David Fischer Drummond Group. -----Original Message----- From: Dale Moberg [mailto:dmoberg@cyclonecommerce.com] Sent: Tuesday, August 21, 2001 11:44 AM To: David Fischer; Martin W Sachs Cc: ebXML Msg; ebxml-cppa@lists.oasis-open.org Subject: Regarding where SyncReply information can and/or should reside David F, If the issue is how to get the CPA to support a "per message" option for delivery (based on message size, for example), we do not have apparatus to do this in v1.0 of the CPPA stuff. Because there can be more than one delivery channel for a given combination of sender, receiver, and service-action (BP), the preference for delivery follows document order. However, it had been tacitly assumed that the main use of multiple channels would be for "backup" in case one server was down. Agreements about per message delivery policies beyond this failover use case had not been discussed much. As long as there are some bounds on how the delivery policy is stated, I guess it would be possible to consider new delivery policies and preferences for v 2. If the idea here is to be allow "sender's choice" out of some range of channels, and you want to have a CPA for it, we would again need to add some "choice" construct over the list of channels. (We are already planning to consider adding constructs for lists, sequences, sets, bags and whatnot of items...) If the Delivery Channel endpoints are the same URI, and we do have a "sender's choice" on these for synch/asynch (that is, the sender can arbitrarily decide whether it expects to get a response back on the request connection or on a distinct connection), then a "flag" in the header would be advisable when using HTTP. We CPPA folks did not imagine the synch/asynch information varying on a per message basis. Generally per-message information (that is, information different for each message) is one kind of information that is a good candidate for going in a header. I take it that part of the underlying rationale for these per message changes would be to compensate for some tacit implementation resource issues on one side or the other. For example, perhaps one side does synchronous "all in memory" and has poor performance from paging, when stream size becomes large, while by switching to asynch mode, it persists all to disk and can avoid a paging penalty. I am not certain how much of this compensating machinery we should get into at the specification level if that is the driver. Do you have other use cases for per-message choice of delivery channel with respect to the asynch/synch property? Dale -----Original Message----- From: David Fischer [mailto:david@drummondgroup.com] Sent: Tuesday, August 21, 2001 8:58 AM To: Martin W Sachs Cc: ebXML Msg Subject: RE: T2 SyncReply and ReliableMessagingMethod in QualityOfServiceInfo Yes, I agree. Make DeliveryChannelId tie to a unique address for v1.1. Normal mode, IMO, for HTTP will be SyncReply=True. However, there will be fairly common cases where there is a large file (100MB+, 500MB+) where we want to change SyncReply to False, just for this one message. My original premise has nothing to do with Delivery Channels. I wanted to be able to set SyncReply at send time. Chris brought Delivery Channels up as an alternative to having SyncReply in MessageHeader. I originally agreed but I am now convinced this will not work - at least not in v1.1. Back to the original topic... We need SyncReply in MessageHeader (in QualityOfServiceInfo -- see Subject Line). Regards, David Fischer Drummond Group. -----Original Message----- From: Martin W Sachs [mailto:mwsachs@us.ibm.com] Sent: Tuesday, August 21, 2001 10:36 AM To: David Fischer Cc: ebXML Msg Subject: RE: T2 SyncReply and ReliableMessagingMethod in QualityOfServiceInfo David, As I explained in my response to Arvola, it appears that at present, each delivery channel must have a unique endpoint address. I suggested saying that in version 1.1 of the CPP-CPA spec and then working on associating multiple delivery channels with the same endpoint address (adding an additional element to disambiguate), if there is a good case for doing so, for version 2.0. We certainly want to avoid putting elements in the message header whose sole purpose is to make up for deficiencies in the CPA spec. 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/21/2001 10:59:07 AM To: Martin W Sachs/Watson/IBM@IBMUS cc: ebXML Msg <ebxml-msg@lists.oasis-open.org> 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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC