Re: RefToMessageID

[jacques durand <jacques@savvion.com>]

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