Re: [wsrm] Draft Agenda for 6/17 WSRM TC conference call

["Jun Tatemura" <tatemura@ccrl.sj.nec.com>]

Draft Agenda to WSRM TC Conference Call - May 06, 2003I regret that I will not be able to attend the first conference call as a member.
Let me give comments and my positions on some RELs.
Thank you,

Junichi Tatemura
NEC Laboratories America

----
REL-9 Pull model

[Question at F2F]: Is this a special case of request-response MEP?
-- I would say NO.

The attached powerpoint shows a use case of the Pull model in which 
a message should not be modeled as a response of request-response MEP.

Suppose we want to deploy a message-driven application which is invoked by
incoming messages (it may receive up-to-date stock information,
new virus definition, or windows bug fixes :-)
Naturally, the corresponding WSDL would define one-way operations
from a sender to the application.
If we deploy the application behind a firewall, or on a mobile device which is not
always on, the platform should pull a message from a node (SOAP intermediary)
and deliver it to the corresponding application.

Defining this case with request-response means that
an application has to be aware that messages have to be pulled
(i.e., the application is no longer a simple message driven module)
and that each application should poll messages for each operation
(someone has to consolidate those numerous pollings...).

My opinion:
I think the Pull model is important and should not be precluded. 
*But* I am not sure this should be included in the requirements, bacause:
+ It may take time since it is not just a special case of req-res. 
   In-time delivery of the spec should be more important.
+ Since there is no standard bindings for SOAP Pull MEP, it may not
   appropriate to specify the Pull model.


----
REL-42: Ack and duplicate elimination

Yes, the receiver must send Ack even for a duplicated message.
(But I think this is a spec issue)

----
REL-44: Duplicate elimination and Time-to-live

What happens if sender resends message which has expired?
-- (My answer) The receiver must send fault back. Duplicated messages
will not be delivered even if the receiver discards info on
expired messages.
But two issues remain:

[1] If the sender sends a message with the same ID and a new TTL (the old one
has expired), the receiver can not eliminate the message as duplicated.
-- Once a message is sent, its TTL must not be modified.

[2] There is a case a message has been delivered but the sender can
not know that fact.
1) The sender A sends a message M
2) The receiver B receives M and sends Ack(M). M is delivered to the application.
3) Ack(M) is lost
4) A sends M again.
5) M expires.
6) B receives M which has expired and sends Fault(M)
7) A thinks it fails to send M - but it is not true...
-- A 'TTL-expired' fault does not guarantee that the message has NOT
been received.

----
REL-33 (Pending Spec issue)
Acknowledgement Message

There are alternatives of the Ack semantics. I would list (1)-(4) as follows.
The proposal in f2f was (2), but I propose (1).

(1) [Ack for message persistance responsibility]
The receiver has received the message and the sender is no longer responsible
to preserve the message (i.e., the receiver now has responsibility for message persistence).

(2) [Ack for deliverability to the destination application]
The receiver has received the message and made it available to the destination application

(3) [Ack for delivery to the destination application]
The receiver has received the message and has delivered it to the destination application
(the message may not be processed by the application)

(4) [Ack for processing by the destination application]
The receiver has received the message and confirmed that it has been processed
by the destination application.


The difference between (1) and (2) is non-trivial when the message is ordered.
Suppose the message M2 should follow the message M1, M1 has lost, and M2 has been
received by the receiver. In this case, "the receiver has received the message M2,
but it is NOT available to the destination application." If we take (2), the receiver
does not send Ack(M2) until it receives M1. Thus the sender needs to resend M2 although
it is already preserved by the receiver.

Apparently, (4) should be achieved at the application level (using e.g. WS-Transaction?)
instead of the WS-RM level.

If my understanding is correct, ebXML MS takes the meaning (3). But it is because
the MS is tightly coupled with the application (ebXML) layer. In the f2f meeting (2) was
proposed instead of (3) since how to deliver to the application is platform dependant.

I prefer the minimum semantics (1).

pull-model-tatemura.ppt