RE: RefToMessageID

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

Jacques ...

There has already been some good discussion on these topics but I am just
catching up on emails after some connectivity problems.

One small point, you said ...

>>>If it is mostly about "knowing that an earlier message  sent was
received", as David B. suggest, does not this overlap with a reliable
message service? <<<

The point I was trying to make with this statement is that if Party A sends
a message to Party B and then gets a response from Party B to that message
that includes, in the RefToMessageId, the MessageId of the message Party A
sent, then it does not matter at all to Party A whether the Party B's MSH or
application set the value of the RefToMessageId that Party B returned.

David
-----Original Message-----
From: jacques durand [mailto:jacques@savvion.com]
Sent: Monday, January 08, 2001 12:47 PM
To: Martin W Sachs; Burdett, David
Cc: Nikola Stojanovic; ebXML Transport (E-mail)
Subject: Re: RefToMessageID


Martin & David: a follow up on your responses:

Martin W Sachs wrote:

> "More radically, I think RefToMessageId is great for linking Ack and
Normal
> messages, or
> Normal and Error messages, but not Normal to Normal messages:"
>
> I beg to differ.  As originally conceived by the IBM Research team and
> described in tpaML. RefToMessageId
> (we called it past request ID) was specifically for linking normal to
> normal messages.  A response message carries in the past request ID field,
> the ID of the request message to which it refers.  If the messaging
service
> can make use of this field without altering its semantics, fine, but this
> looks like a case where the messaging service is taking over and modifying
> the semantics of a field which was intended for business process use.

I think the problem we have here (and I have, as an MSH implementor)
is to define precisely the exact role of the MSH with regard to the
RefToMessageId field.

In several well defined cases, as  described in V0.91, the RefToMessageId
is clearly the "property" of the MSH (Acks, Errors, MSH Services like
status request, ping). In these cases, RefToMessageId does not
need be visible to the app and is not. The MSH uses it internally for its
 message correlation.

Now if it is to be used also to refer to past business requests ("Normal"
message types),

then there are two roles the MSH could play to support this:

(1) this linking is controlled by the application. The basic scenario goes
like tgis:
- the app receives a message. The MSH app interface makes it possible for
the app
to  access the MessageID (which normally can remain hidden to the app).
- the app accesses also the RefToMessageId to check if this message responds
to
its previously sent one.
- the app prepares a response (within the same conversation)
- the app sets the RefToMessageId field of the response to the previous
MessageID,
using again appropriately the MSH interface.
Clearly, if we want the application to make good use of this Ref field, then
we assume
the app will generally track the MessageID of all its messages (one way for
the MSH
interface
to support this, is for the "sendMessage" call to always return the
MessageID generated
by the MSH.)

(2) this linking is controlled by the MSH. This could be done based on the
conversation
ID.
The MSH automatically tracks the last message sent for each conversation,
and sets the
RefToMessageId appropriately. The application can still track its message
IDs, but does
not have
to set the RefToMessageId.

I am not very fond of (2), as the MSH becomes more stateful (must maintain
status of each
conversation,
more complex, less robust),
and also the linking is totally determined and sequential (no tree-like link
schemes,
etc.)

(1) seems to be within the expected role of MSH, and here indeed the
definition of a
MSH service interface would help  as you suggest.

These practical considerations aside (I do not see any problem with
providing to an app
the
MSH service of accessing and setting RefToMessageId),
I am still a little uneasy  about the reasons put forward to justify
the use of RefToMessageId at business level:
If it is mostly about "knowing that an earlier message  sent was received",
as David B.
suggest,
does not this overlap with a reliable message service? And if it is
considered as a way
for the
app to  know this precisely in case RM was not mandated (BestEffort), then
it is of
little use:
if the message has not been properly received, then the conversation is
likely to block
anyway
and the"From" party will not even have a chance to get a response showing
any Ref...

My impression is that in most cases the notion of conversation will suffice,
combined
with the "Service/Action" fields of the Header element, to identify the next
message in
a conversation. (I bet the notion of "past request ID"
mentioned by Martin is precisely a way to implement a notion of
conversation, in the
absence of such an attribute?)

I am mostly motivated here in avoiding to the application the need to deal
with
IDs that are not business level, but again it does not hurt to have the MSH
allow for
this,
as it can be useful in cases I may not have in mind.
It becomes mostly an app design decision to use it or not
(after all, V0.91 says that RefToMessageId MUST contain a valid ref value
*when
present*...)

Regards,

Jacques Durand
Savvion

> If
> the messaging service needs a construct with similar but not identical
> semantics, please define a separate field for that purpose.
>
> This is one more case where a service interface description would help to
> eliminate confusion and misinterpretation.
>
> Regards,
> Marty
>
>
****************************************************************************
*********
>
> Martin W. Sachs
> IBM T. J. Watson Research Center
> P. O. B. 704
> Yorktown Hts, NY 10598
> 914-784-7287;  IBM tie line 863-7287
> Notes address:  Martin W Sachs/Watson/IBM
> Internet address:  mwsachs @ us.ibm.com
>
****************************************************************************
*********
>
> "