[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebxml-dev] CPA driven reliable delivery question
Comments in-line below. anthony.ellis@redwahoo.com writes: "I have a question on ebXML reliable delivery. Basically, there are a lot of parameters listed for the sender and also for the receiver. Which values should you use to drive the reliable messaging, those from the sender or those from the receiver? Dale> The sender of a request or of an (asynchronous) response has to do the retries, so the parameters on the CanSend side of the CPA rule. (But they should be the same on the OtherSide binding, right?) "Reliable delivery at the MSH is driven (in part) by the CPA document. My questions are related to what fields in the CPA document should be used. Scenario: Company A -> Purchase Order -> Company B Company B -> Acknowledgement -> Company A Some of the reliable messaging attributes are specified in <DeliveryChannel ... > <MessagingCharacteristics ackRequested="always" duplicateElimination="always" ... > And both CompanyA and CompanyB have <DeliveryChannel> elements referenced in action bindings." <Dale> This is correct. Suppose Company A is sending a Request using RM, and retrieves Company B's CPP when negotiating a CPA. The draft or proposed CPA offer of Company A can align A's RM parameters with those requested by B, and then A can omit the parameters from negotiation. [Other CPA formation and negotiation scenarios are allowed, but the previous one allows this parameter value issue to be removed from negotiation. Generally that tends to be good because it makes it simpler.] Now suppose the CPA is accepted. Two copies of RM parameters exist under the different PartyInfos. This is redundant. We have not [until now] worried about optimizing removal of this redundancy. </Dale> "Do you take the <DeliveryChannel> element listed in the FromParty or the ToParty? <Dale> Sender side needs to have its alarms set on the agreed upon retry, retry interval etc. Sender side retries. </Dale> "I understand that they should match ( based on ThisPartyActionBinding/OtherPartyActionBinding ) but what if they don't! <Dale> I would ignore the Receiver non-match, but that is with my implementer hat on. // Case should be unreachable! </Dale> "What should you do? An ebXML MSH would need to always verify if DeliveryChannel objects have matching reliable messaging parameters, matching security parameters, even matching endpoint protocols. <Dale> The other side should be able to monitor the sender/retrier side to see that the retry count and intervals are more or less adhered to. Should monitor the sender's values though I guess. </Dale> It seems like a lot of overhead of ensuring corresponding values are 'equal' when in essence they should have been aggreed upon when the CPA was made. <Dale>Yes, and we are discussing adding language in Messaging spec to allow people not to monitor commitments and not throw an INCONSISTENT error. I agree with you that it is overhead from a certain point of view. The CPA does of course govern it. However, you could load your CPA and have a GUI that allowed configuration changes. People might mistakenly change the values. There is, in other words, a gap between the CPA document and the runtime database version of it and discrepancies can creep in. So, business messaging gets subjected to business requirements far beyond what is needed to just move the data around. The idea that your partner(s) will not overload your system with too frequent of retries is part of protecting your systems from load and so being able to process a lot of their other business info. That is, I guess, another kind of legitimate concern.</Dale> "If the CPA was constructed with only one set of reliable delivery, security, endpoint values that was aggreed upon at creation, rather than having two sets of values that 'should' match up, there would never have to be a check (maybe I am dreaming). <Dale> Technically, a mismatch here should have been an invalid CPA. I will bring your issue up to the CPPA group and see whether they want to consider trying to prevent people from banging their heads on this wall or just advise the implementer that in order to avoid the pain, don't bang your head on the wall. </Dale> Any info would be appreciated Thanks in advance <Dale> Thanks for explaining the issue. I have copied the group so we can consider it at our next meeting.</Dale> Anthony Ellis Red Wahoo ----------------------------- Tel: +61 438 878 003 www.redwahoo.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]