RE: T2, Proposed solution for ... Re: SyncReply and ReliableMessa gingMethod in QualityOfServiceInfo

["Burdett, David" <david.burdett@commerceone.com>]

David

I said in an earlier email that I like the idea of retry count. I also think
that it should go in the Via (NAD?) rather than the message header. I will
resend my proposed solution shortly in order to try and get some consensus
on solving this problem.

David

-----Original Message-----
From: David Fischer [mailto:david@drummondgroup.com]
Sent: Friday, August 10, 2001 10:26 PM
To: Burdett, David; ebXML CPPA (E-mail)
Cc: ebXML Messaging (E-mail)
Subject: RE: T2, Proposed solution for ... Re: SyncReply and
ReliableMessaging Method in QualityOfServiceInfo


Instead of ResendOfMessageId, what about a retryCount attribute on
MessageId.
This parameter can only be set by the From Party MSH and MUST start at zero.
The first retry, retryCount is set to one, etc.

Duplicate detection, as always, is detected by the To Party and From Party
based
upon MessageId.  Duplicate detection by the Intermediary is based upon
MessageId
plus retryCount.

For example (see attached flow chart):

Let's say there are three intermediaries (nodes B, C, D).  A is the From and
E
is the To.  A sends a message with MessageId of 1 and retryCount of 0 (let's
call this ID 1.0).  We will assume two failures occur during send -- the
message
makes it to D but has problems sending to E.  The Ack from C also fails
going
back to B.  Since A did not get a DR within retryInterval, it will retry
using
ID 1.1.  B will not see this as a duplicate and will pass it on.  B will
also
retry to C using ID 1.0.  C will see ID 1.0 as a duplicate so it will not
send
on but C will send an Ack back to B (who gets it).  C will also receive ID
1.1
and send it on since it is not a duplicate.  Meanwhile D has finally made
the
send to E and the DR and Ack have come back from E.  D then receives ID 1.1
from
C and sends it on since it is not a duplicate.  E receives ID 1.1 but since
E is
the end, it sees ID 1.0 and ID 1.1 as duplicates (it only uses MessageId).
E
sends an Ack to D for ID 1.1.  E sees ID 1.1 as a duplicate so it does not
pass
on to its application but it does send another DR back to A.  A finally
receives
two DRs, one for ID 1.0 and another for ID 1.1.  Everyone is happy.

That's kind of complicated but I think it works.  The only problem I see is
that
by putting retryCount inside MessageHeader, the Signature would change and
would
have to be reapplied between each retry.  Where else could RetryCount be
put?
Maybe in Via?

What do you think?

David Fischer
Drummond Group.

-----Original Message-----
From: David Fischer [mailto:david@drummondgroup.com]
Sent: Friday, August 10, 2001 6:39 PM
To: Burdett, David; ebXML CPPA (E-mail)
Cc: ebXML Messaging (E-mail)
Subject: RE: T2, Proposed solution for ... Re: SyncReply and
ReliableMessaging Method in QualityOfServiceInfo


Very good!

I have a couple of questions (no surprise) <df>in-line</df>.

Regards,

David Fischer
Drummond Group.

-----Original Message-----
From: Burdett, David [mailto:david.burdett@commerceone.com]
Sent: Friday, August 10, 2001 5:25 PM
To: ebXML CPPA (E-mail)
Cc: ebXML Messaging (E-mail)
Subject: FW: T2, Proposed solution for ... Re: SyncReply and
ReliableMessa ging Method in QualityOfServiceInfo


I'm forwarding this email to the CPPA list as it contains some suggested
changes for thinking about intermediaries which are relevant to the CPPA
discussion.

I'm also reposting to the ebXML Messaging list as I omitted two attachments
from the original post.

David


-----Original Message-----
From: Burdett, David
Sent: Friday, August 10, 2001 3:18 PM
To: 'Arvola Chan'; Fischer, John
Cc: ebXML Messaging (E-mail)
Subject: T2, Proposed solution for ... Re: SyncReply and
ReliableMessaging Method in QualityOfServiceInfo


Arvola/David F

I have some ideas for a few changes that might solve the problems raised in
this thread so the rest of this email contains:
1. Extracts from a number of recent emails from you both and analysis of the
issues/requirements they raise
2. Some additional further analysis of the issues to identify a few more
requirements
3. A proposed solution to meeting the identified requirements which
hopefully will solve the problem ... and who knows perhaps bring this email
thread to an end :-)

So please let me know if:
a) I've missed a requirement
b) You (or anyone else) think the proposed solutiuon is wrong or could be
improved ... but then I know you will anyway ;)

Details below

David
******************************
EMAIL THREAD and ISSUES/REQUIREMENTS
====================================

Arvola Chan: Thu 8/9/2001 3:28 PM
---------------------------------
>>I am of the opinion that the DeliveryReceipt element should be used by the
ToParty MSH to inform the FromParty MSH that a reliable message has been
received. ... It is the non-arrival of a DeliveryReceipt that requries the
MSH to notify the application. In this case, it must rely on persistent
information to determine the application service that must be notified.<<

>>I think end to end acknowledgement is always needed to support reliable
messaging, so it is unnecessary to explicitly set deliveryReceiptRequested
to true, it should always be implied by deliverySemantics of
OnceAndOnlyOnce. On the other hand, if intermediary acks are optional, then
ackRequested needs to be an explicit attribute at the QOS level and it
should apply to all intermediaries.<<

[DavidB]This highlights a number of issues/requirements:
Req 1. A positive Ack sent back to the sender of a message by the ultimate
destination is the only sure way the sender can be certain the message was
delivered. If no Delivery Receipt is sent, then the sender cannot be so
certain.
Req 2. If end-to-end Delivery Receipts are always required for the sender to
be certain, then it would be simpler if there was a rule that
deliverySemantics of OnceAndOnlyOnce implies a Delivery Receipt is sent. The
only remaining issue is whether or not the Delivery Receipt should be
signed.

David Fischer: Thu 8/9/2001 7:31 PM
-----------------------------------
>>Question 1 ... the end-to-end MUST be able to do RM as if it does not know
(which it probably doesn't) what the IM(s) are doing.  The end-to-end
probably doesn't care if the IM(s) are doing RM at all (even though each IM
might care very much)<<

>>On the issue of Sender time outs and retries, their are two kinds:  1) a
timeout to the first IM and 2) a timeout getting to the end.  The first is
easy and obvious so we don't need to discuss it.  The second is a timeframe
that is usually contractually guaranteed ...<<

>>While the Sender/Receiver may not have any idea what path or IM transport
the message is taking (and they really don't need to) they must have an idea
about delivery times to the end.  We MUST generate some kind of an
end-to-end Ack allowing the ends to do RM.<<

>>Proposal:
1) We need to update section 10 with end-to-end RM (deliveryReceipt or
something new that is similar to Acknowledgement).
2) We need to put in the spec somewhere that ALL MessageHeaders (including
Via) MUST be passed to the next hop, including the end.<<

>>Question 2 ... I agree that it doesn't matter if ackRequested gets changed
because an Ack gets sent based upon DeliverySemantics (This was my second
solution to Question 2).  Why then do we have ackRequested?  The only way it
would change is if there was some kind of local CPA overriding ackRequested.
If RM is requested and an IM can do RM then it MUST, right?  Then why have
this parameter?  (I see from your comments that you are considering this.)
<<

[DavidB]This highlights a number of issues/requirements:
Req 3. The sender should not know nor care if an IM is being used and
whether or not they are doing RM with the next IM.
Req 4. There are two different types of "acks" that are useful:
  a) It's been accepted by the postal system (i.e. the next MSH has
received, this is the Acknowledgement Message)
  b) It's been received by the final destination (i.e. the To Party has
received it, this is the Delivery Receipt)
Req 5. Even if the initial Ack (i.e. Acknowledgment Message) is received
there needs to be some method of automated retry if the Delivery Receipt is
not received within the expected timeframe.
Req 6. If you a doing reliable messaging between two hops, then you do not
need ackReqeusted as an acknowledgment must be sent if the ebXML RM protocol
is being sent and not needed if it isn't.

David Fischer: Thu 8/9/2001 8:02 PM
-----------------------------------
>>I am concerned that end-to-end RM is taking a back seat to IM RM.  This is
the opposite of how it should be.  Most transactions will be single-hop.
Many other cases will be single IM where the sender or receiver may not even
know there is an IM so it still appears to be single-hop.  The ends should
not even have to know about the IMs.  Ends will always do automatic retries.
RM should work for the ends in exactly the same manner whether or not there
are IMs.<<

[DavidB]This really just provides further support for issues/requirements
numbered 3 and 5 above.

Arvola Chan: Fri 8/10/2001 12:23 AM
-----------------------------------
>>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.<<

[DavidB]This highlights a number of issues/requirements:
Req 7. The syncReply needs to be set at the message level whether or not an
intermediary is being used
Req 8. There is a contradiction in the spec (which therefore needs to be
removed) that the Via element is only for intermediaries when it is actually
also needed for non-intermediaries.

DAVID BURDETT's COMMENTS
========================
Before proposing a resolution to all these requirements I'd like to make a
few comments and identify an additional couple of requirements.

Firstly on Requirement 6 above (you don't need ackRequested). There could be
benefit in gettingan acknowledgement element back even if you are using a
reliable messaging protocol such as MQ Series as you then have evidence
(especially if it is signed) that the next MSH has received the message. I'm
not convinced though that this is a huge benefit.

Secondly if we put syncReply at the message level then there is an
additional requirement ...
Req 9. The next recipient of a message needs to know whether or not to
return an acknowledgement message synchronously or not.

Now for the proposed solution.

PROPOSED SOLUTION
=================
The solution dsecribed below refers to the requirements identified above ...

Change 1
--------
Summary: Rename the Via element as "Next Actor Data" or similar

Rationale: There can always be "intermediaries" in a message transfer even
if you are going point-to-point. For example consider the two example
message flows that I recently posted (also posted here) that cover the
following use cases:
1. A genuine intermediary who is a third party that is running a MSH and
forwards messages to the final destination.
2. A Party which has a MSH that acts as a "mailroom" that forwards the
message internally using ebXML RM to another MSH that then forwards it to
the application. The "mailroom" MSH ia an intermediary.

I think we need to support both use cases. By renaming the Via element as
"Next Actor Data" we are simply saying that the data contained within the
element is for the Next Actor **only** and does not need to be forwarded.
The Next Actor recreates the data as they need to. If we think of the data
in the Via as being for the "Next Actor" then we are more closely aligned
with SOAP. It also removes the problem of treating intermediaries as
"something special" and allows an internal MSH to forward the message to
another MSH without the original sender needing to know and without having
to re-create the complete message.

This change addresses Req 3 and 8.
<df> agreed </df>

Change 2
--------
Summary: Data in the Next Actor Data (Via) element is for the Next Actor
only

Rationale: What Change 1 means is that we must carefully review the existing
elements in the header and check to see whether they are needed by the
ultimate destination/endpoint or the next actor. I think that this will
require the following changes:
1. CPAId. The CPAId in the Message Header identifies parameters that apply
"end-to-end", e.g. business process level stuff, whereas the CPAId in the
NAD/Via element applies to the transport over a single hop, e.g. transport
level stuff. I realise this will require changes to the CPP/A ... and
probably more discussion.
2. Acknowledgment Element. This should be part of the NAD/Via element as
acknowledgments are between two MSHs and are not propogated to the original
sending party.

This change addresses Req 3, 4a
<df> agreed, does the first IM send an Ack back to the From Party MSH?  does
the
To Party MSH send an ack back to the last IM MSH? The first IM would send an
Ack
back to the From Party without being asked so the From Party needs to
understand
this was an Ack not a DR.  The To Party would send a DR based on the
presence of
deliverySemantics=1&o1 and then if there was a Via (NAD) it would also send
an
Ack (could be in the same message).  Why isn't TraceHeaderList a sub of Via?
Never mind -- too late. </df>

Change 3
--------
Summary: Make the return of a Delivery Receipt required if
deliverySemantics=OnceAndOnlyOnce
<df> agreed </df>

Change 4
--------
Summary: Replace deliveryReceiptRequested by deliverReceiptSigned=true or
false(the default)

Rationale: As the return of a Delivery Receipt is the only sure way that you
know a message was delivered suggests that it will be a simpler solution if
we make this always the case. Therefore we can make the return of a delivery
required if the deliverySemantics are OnceAndOnlyOnce. However you still
need to know if the receipt must be signed.

These changes address Reqs 1, 2, 4b
<df> agreed  What about the requirement that reliableMessagingMethod=ebxml?
Can
we drop that?  What would it mean if deliverySemantics=BestEffort and
DeliveryReceiptSigned=signed|unsigned? </df>

Change 5
--------
Summary: Make the return of an Acknowledgment element in a message required
if the ebXML RM protocol is being used
Change 6
--------
Summary: Replace ackRequested by ackSigned=true or false(the default)

Rationale: The rationale for doing this is similar to changes 3 and 4. It
simply gives the rule that if you are doing ebXML RM then you must include
an Acknowledgment element in the response. The response can be synchronous
or asynchronous (see change 9 below).
<df> agreed.  Same comments as DeliveryReceiptSigned </df>

Change 7
--------
Summary: Include automated retry by the original sender (From Party) if no
Delivery Receipt is returned
<df> agreed.  Need to be careful since the retryInterval specified in the
CPA is
end-to-end and there is no IM retryInterval (probably need one). </df>

Change 8
--------
Summary: Include "ResendOfMessageId" element in the Message Header

Rationale: There is a need for automated retry by the original sender (from
party) if a Delivery Receipt is not received. However, the original sender
cannot send the **identical** message as it will be treated as a duplicate
and therefore ignored by any intermediate MSH that has previously received
it. To solve this problem the from party needs to use a different MessageId.
However there is now a need to stop the message being treated as a
completely new message. To solve this problem we could add a
"ResendOfMessageId" element that identifies which message the new message is
a resend of. In this case even if the resend is received first and the
original appears some time later, the ToParty will be able to recognize that
the message has already been processed and therefore the original should be
ignored. This logic needs to be included in section 10 and probably needs a
bit more thinking through.

These changes addresses Req 5
<df> How does the Sender know to use this?  The sender may not know there is
an
IM.  I understand the problem, I'm just not sure this is the right solution.
I
think the Sender must be allowed to send the **identical** message.  A
duplicate
at the IM is not the same as a duplicate at the To Party MSH.  The presence
of a
duplicate at the IM should signal a problem, not necessarily stop the
message.
Have to think about this more.  What about always including a retry number?
</df>

Change 9
--------
Summary: Include syncReply at both the Message Header and the NAD/Via
elements

The To Party needs to know whether the From Party wants the Delivery Receipt
and Business Payload assembled into one message.The next MSH needs to know
whether to send back an Acknowledgment synchronously or wait for the
Business Payload before sending it. The Delivery Receipt and Business
Payload can be sent asynchronously and the Acknowledgment sent synchronously
and vice versa as they are independent of each other.
As you can't easily cover both requirements in a single element, they need
to be included separately in the header and in the via.

This change adresses Reqs 7 and 9.
<df> agreed.  Might have an Ack in there too.  I still like changing
Acknowledgement to Ack.

Good Plan.</df>

Product Manager, xCBL, XML Standards
Solution Strategy, Commerce One
4400 Rosewood Drive, Pleasanton, CA 94588, USA
Tel/VMail: +1 (925) 520 4422; Cell: +1 (925) 216 7704
mailto:david.burdett@commerceone.com; Web: http://www.commerceone.com


------------------------------------------------------------------
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