RE: Comments on reliable messaging draft specification

[richard drummond <rvd2@worldnet.att.net>]

we have two use cases being presented to the steering committee on thursday
from gci. this may be usable.... rik

-----Original Message-----
From: David Burdett [mailto:david.burdett@commerceone.com]
Sent: Sunday, August 06, 2000 1:13 PM
To: Christopher Ferris
Cc: ebxml transport
Subject: RE: Comments on reliable messaging draft specification


Folks

All comments inline marked by ## apart from the one below do with use cases
around TPAs.

Chris said ...

"Then it would be a different TPA! I would like to see a specific use
case(s) which would have the *application* twiddling around in this area
[MessageExpirationTimes] on a message by message basis"

... Chris I agree we need a use case. So here are two to start the
discussion.

USE CASE 1
This use case goes along the lines of an instance of a service which is made
up of a number of subservices, where the urgency that service needs to be
executed with can vary depending on business circumstances.

For example, suppose there is a service that consists of two sub services:
a) a buyer requests a price quote from a seller (the price quote service),
followed by
b) an optional placement of an order based on the results of the quote (the
order placement service).

In this service, the buyer wants to secure the best price whereas order
fullfillment for the buyer is less urgent.

You can therefore imagine that in a single conversation:
a) the buyer wants the response to the price quote within 10 mins and and
therefore the buyer wants to set the TTL of the price quote request message
to 5 mins (this is because he's doing comparative shopping)
b) however once the order is placed the response is less urgent so on the
order request message the TTL of message is 1 day

In another example of a purchase between the same buyer and seller using the
same software/servers at each end, it could be the goods that are being
ordered are needed much sooner and therefore the TTL of the buyer wants to
set the TTL of the order request message to 30 mins.

What this means is that:
a) two different messages within a single conversation instance could have
different TTLs.
b) two different conversations using the same service between the same
parties could have different TTLs for the same type of message.

What I think, to a degree, we're doing here, is exploring the boundary
between business process and transport as the need for varying levels of
service within the transport is being driven by business reasons. This is
one of the reasons why I am much keener on a separating the transport parts
of a TPA from the business parts. If, for example we had an "ebXML Transport
Only" TPA, then we would be focussing on the particular aspects that the TRP
group is concerned with.

The other concern with requiring the use of TPAs in *every* instance is
illustrated by the following use case ...

USE CASE 2
A business offers a news distribution service to which users can subscribe
that allows subscribers to receive daily analyses on a particular market.
The service provides the analyses as an XML document since it contains
several tables of historical information that the recipeint wants to
process. To subscribe to the service there need be no pre-existing
relationships between the parties involved. The way the service works is:
a) the new subscriber completes an XML document providing information about
themselves and where the daily analyses should be sent then sends it to the
distribution service as a subscription request
b) the distribution service acknowledges receipt of the request with a
subscription response and from then on sends the daily analysis to the
specified address.

My question is what TPA (and therefore what TPAid) does the new subscriber
use, if they want to use ebXML to send their request? It is quite possible
that the very first instances that these businesses communicated was with
the initial sending of the subscription request.

COMMENT
One thing is clear to me, if nothing else, we need to clearly understand
what's transport, what's business process and keep a very clear separation
between them in my opinion.
##

Remaining comments inline ...

David

-----Original Message-----
From: Christopher Ferris [mailto:chris.ferris@east.sun.com]
Sent: Saturday, August 05, 2000 10:32 AM
To: David Burdett
Cc: ebxml transport
Subject: Re: Comments on reliable messaging draft specification


All,

My comments below.

Chris

David Burdett wrote:
>
> Folks
>
> Here are some initial comments/questions on the reliable messaging spec.
>
> David
> =========
> Section 2.1 Base Concept
> ------------------------
> This doesn't say what you do when an ack is sent by the recipient of a
> normal message(s) but the ack get's lost. From my reading of the spec I
> think what happens is:
> a) sender resends original normal message(s)
> b) recipient recognizes the normal message as a duplicate and discards it
> Perhaps the recipient, if they receive a duplicate normal message should
> resend the ack that was previously sent as otherwise they will never know
if
> their resent message got through. We also need to think about the need for
> single threading of the recording of message ids etc so that duplicate
> messagess are properly recognized

David/All,

I believe that what David describes above is what we discussed
in Burlington. An Ack is returned to the sender regardless of whether the
message
is deemed to be a duplicate by the recipient.

##But is it the *same* ack as sent previously, or newly generated one with a
different id.##

>
> Table 2-1 Message Data Element - Message Identifier
> ---------------------------------------------------
> The outline description of Message Identifier is much more prescriptive
> about what it should contain than the current (v0-63)version of the header
> spec. We need to make them consistent.

The description in RM seems more prescriptive, but the header spec
specifically states that "the message id shall conform to RFC2111". This
seems to me to be more than enough detail! I don't think that we
need to be offering redundant information. We want the document
to be succinct.

##Good point.##

>
> Table 2-1 Message Data Element - Recovery Number
> ------------------------------------------------
> a) The spec isn't clear whether recovery number is increased if you
re-send
> a message. My guess is that it isn't.

Again, as we discussed, a message should never me modified. Section 2.4
needs to be revised to make this clear. At present, the sequence of
steps to be taken would lead to a case where a message could be sent
multiple times and there could be no means of detecting it as a duplicate.

Before line 132 there should be a preliminary step:

1) create message, assign messageId and recoveryCounter
2) store...

> b) Is Recovery Number always increased - and what do you do if you receive
a
> message that has a lower number than any of the ones you are currently
> processing in the Window. This could occur, for example if a message get's
> trapped in an email server somewhere. You possibly might want to ignore it
> or maybe you are trying to get a response to an earlier message that was
> lost.
>
> Table 2-2 Reliable Messaging Info Element
> ------------------------------------------------------------------------
> I think this is a topic we need to discus in the F2F next week. But some
of
> the things we might want to think about are:
> a) Should Message Expiration Timestamp be in the TPA or in the header. If
it

My take is that it belongs in a TPAConversation instance.

> can be expressed as a TTL and doesn't change then you could put it in the
> TPA. OTOH, Message Expiration Timestamp might be something that the
> application that is using ebXML TRP might want to specify, in which case
it
> should be in the header.

Then it would be a different TPA! I would like to see a specific use case(s)
which would have the *application* twiddling around in this area on a
message by message basis. If these exist, I would agree to adding it to
the header. Otherwise, ttl applies and it need not be in the message.
There's no reason why an implementation couldn't store this value with
the message in persistent store so that it could optimize the GC function.
It doesn't seem to me that it is necessary to carry it in the header to
accomodate the sending party's implementation. The problem with a timestamp
is that for it to be effective, there needs to be an agreement as to
what time it is!

##See comment at the start of the email##

> b) Do we want to add other information in here or in the TPA,
specifically:
>   i) Retention Period - how long you keep the message before deleting it
for
> reliable messaging purposes
>   ii) Retry Interval - how long you wait before resending a message
>    Both of the above might also need to be specified by the application.
> IMO I think we should tbe able to put he information in either the header
or
> in the TPA as then it would also allow TRP to be used without a
pre-existing
> TPA (OK I admit that this is one of my hobby horses ;-)

We (you and I) have already addressed this. I believe that these belong
in the TPA. In our proposal (which I covered in the f2f in Burlington)
these were described as being in the TPA. If not mistaken, they are
already covered in tpaML 1.0.6 for the most part.
##I do so wish I could have made Burlington - sigh :-( ##

>
> Section 2-4 Message Transfer Sequence
> -------------------------------------
> I think it would also be a good idea to include an example where a single
> message is acknowledged. My guess is that this would be frequent
occurrence
> when sending messages by email.

Agreed, but it would seem to me that in such a case that the window count
would be 1, and everything else works the same.

>
> Lines 161 and 164 - Recovery Sequence
> -------------------------------------
> It's not clear that the Recovery Sequence is the one specified in section
> 2.6 or some other recovery sequence.

Agreed. This needs to be made explicit.

Lines 181-186
I think that it needs to be made more explicit as to the handling
of the messages to be resent. Is the window the same (yes)? Are the
recovery counters the same (yes). What is the behavior of the receiving
party's system when receiving messages resent in response to an error?

>
> Section 2-7 Detection of Repeated Messages by the Receiver
> ----------------------------------------------------------
> It seems to me that the "Message Id" and "FromPartyId" + "ToPartyId" +
> "Recovery No" are both globally unique identifiers for the Message. Do we
> need both?

RecoveryNo is not unique unless it is qualified with the windowId for
## But the spec says ... "The Recovery Number is generated from a Recovery
Counter which is unique to the Sender-Receiver pair." If the From and the To
are each unique then I reckon that from+to+recoveryno is globally unique."##

which there is no provision. It would seem to me that there would need
to be some provision given for this, otherwise, implementations which
choose to use the suggested idempotency scheme *might* treat a stale
message (which hasn't expired) which was effectively lost, resent and then
subsequently "found" as a NEW message instead of a duplicate and the
actual "NEW" message would be treated as a duplicate and discarded!!!

>
> Lines 198 & 199
> ---------------
> I'm not sure this is sufficient. See response to Section 2.1 above.
>
> That's it !!
> David
>
<SNIP>