Re: RefToMessageID

[Martin W Sachs <mwsachs@us.ibm.com>]

Jacques,

I agree that the correct usage of RefToMessageId is (1) in your email,
below.  The only role the Messaging Spec needs to play is to provide an
application-independent place to carry this piece of information in normal
messages. Application independence is significant since this field is one
which B2B middleware might process.

Regarding "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?": you lose your bet :-)  The IBM Proof of Concept of
tpaML and BPF includes the conversation notion - it is a key element in the
whole system.  The main purpose of "past request ID" is to correlate a
request with a previous request.  There are various uses for it but
Compensation is the most significant use.  For example, I send a request
whose purpose is to cancel a previous hotel reservation request or
whatever.  While "past request ID" is also useful for correlating
business-level responses to request, that is indeed somewhat redundant with
the conversation notion.

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



jacques durand <jacques@savvion.com> on 01/08/2001 03:47:22 PM

To:   Martin W Sachs/Watson/IBM@IBMUS, "Burdett, David"
      <david.burdett@commerceone.com>
cc:   Nikola Stojanovic <nhomest1@twcny.rr.com>, "ebXML Transport (E-mail)"
      <ebxml-transport@lists.ebxml.org>
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
>
*************************************************************************************

>
> "