negotiation simplification.

[Martin Sachs <msachs@cyclonecommerce.com>]

I am posting this on the negotiation list.  Let's keep the discussions public.

Our draft spec. already provides the option of Party A retrieving Party B's 
CPP first. Party A  would use Party B's CPP to build a CPA template and NDD 
and submit them to Party A as an initial offer. Dale's statement points the 
way toward eliminating unnecessary negotiation by suggesting that Party B 
build  a CPA template that has a high probability of being accepted by 
Party B (or at least reducing the number of iterations of the negotiation).

The negotiation subteam has to attack the specific problem of simplifying 
the negotiation CPA since 12 pages of XML statements is pretty 
off-putting.  Obviously, any simplifications in the CPA in general would 
help the NCPA but might not go far enough. We need to try to get to an NCPA 
that doesn't have to be negotiated at all (Dale's "bootstrap" problem).

Regards,
Marty

At 07:54 AM 5/1/2003 -0600, you wrote:
>This is the statement we could use that shows a simplification path, 
>albeit through discovering the CPP first:
>
>>><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.]<<
>
>Monica :>)
>
>
>
>-------- Original Message --------
>Subject:        RE: [ebxml-dev] CPA driven reliable delivery question
>Date:   Tue, 29 Apr 2003 15:33:19 -0700
>From:   Dale Moberg <dmoberg@cyclonecommerce.com>
>To:     <anthony.ellis@redwahoo.com>, <ebxml-dev@lists.ebxml.org>
>CC:     <ebxml-cppa@lists.oasis-open.org>
>
>
>
>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
>
>
>
>

*************************************
Martin Sachs
standards architect
Cyclone Commerce
msachs@cyclonecommerce.com