OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Re: RefToMessageID

(through its interface, which is still TBD)

This (TBD) is what hurts us a little bit.

But the MSH will not process this RefToMessageId (in normal messages) in any
way: only pass it along. If there is any intent to use this field for, say,
message ordering, or some check, it is up to the application.
The underlying guideline in (1) and (2) above is: whoever sets the
RefToMessageId (MSH layer vs. app layer) , is expected to interpret it.

There is a notion of ImplicitAcknowledgement => If Recipient side sends back
to Sender side a Normal message with RefToMessageID, which is a MessageID
created by Sender (very abstract here, although I like Marty's "MIDDLEWARE"
and I would even imagine many (not only MSH and "App") "middlewares"
(components, ...) that could do something like
RelateThisMessageToThatMessage (MessageID doesn't need to be exposed to
"App")) Sender might assume that Recipient has received (and by putting it
in a Response message Acknowledged) Sender's message. So, in that case (when
ImplicitAcknowledgement is a valid concept) some kind of CPP/CPA might be
needed to coordinate different "layers" (like: do | don't send both Implicit
and Explicit Acks, ...).

It could also reflect a tree-like linkage of messages.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC