RE: [ebxml-dev] CPA driven reliable delivery question

["Dale Moberg" <dmoberg@cyclonecommerce.com>]

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