RE: T2 SyncReply and ReliableMessagingMethod in QualityOfServiceI nfo

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

Masayosi/Scott/Marty/Chris/David F

Phew! This is quite a thread which I have just caught up on. I also
apologise for the length of this reply but to try and come to some type of
resolution I have:
1. Presented a specific use case involving an intermediary
2. Analyzed the use case to draw out some of the key issues that arise
3. Responded individual emails by extracting relevant items

The bottom line is that, apart perhaps from some clarifications, I don't
think the spec needs changing. Details below ...

David
--------------------------------------------------------
USE CASE
This use case describes the characteristics of two parties exchanging
messages via an intermediary. Specifically:
1. There is one intermediary between the two parties.
2. When the intermediary receives a message from a "From Party" they do not
always forward it immediately to the "To Party"
3. The intermediary has separately agreed with each of the other two
parties:
   a) the messaging protocols that will be used between the intermediary and
the party
   b) that the intermediay will transform messaging protocols and payloads
if the From Party and To Party use different protocols.
4. Specifically the agreements are:
   a) One party and the intermediary will use RosettaNet documents as
payload with MQ Series without the ebXML Reliable Messaging protocols
   b) The other party and the Intermediary use EDI Messages with ebXML
messaging using SMTP and the ebXML Reliable Messaging Protocol
5. The intermediary does not take part in the business process between the
To and From Parties - i.e. the intermediary does not alter the semantic
meaning of any of the data in the payload
6. The Application that is the ultimate destination at one of the parties
runs in batch and therefore their MSH needs to store messages and deliver
them to the application later.

USE CASE ANALYSIS
There is one intermediary
Although there is only one intermediary the same principles will apply if
there are many.

The intermediary stores messages before forwarding
This is a valid use case since it is possible that the final destination of
a message is off-line (e.g. they are a SME who only uses email) but they
want to be able to let their customers also use HTTP.

What this means is that there is benefit in the intermediary returning an
"acknowledgment message" as the From Party can then turn off their retry
process without waiting for the message to reach the final destination.

The intermediary has separate agreements with each party
What this means is that there two types of agreements in place:
1. Between the From or To Party and the Intermediary which covers how
messages are sent but NOT the business process.
2. Between the From and To Party directly that cover the business process
they will follow but not how messages are sent.

As each party uses diferent transport protocols for reliable messaging, one
MQ Series and one the ebXML RM Protocol, you need to specify separately for
each hop which RM protocol to use. This is why reliableMessagingMethod is in
the Via rather than the main message header.

The application at the ultimate destination runs in batch
If the rule is that application always provides the Delivery Receipt, then
the sender of the message might have to wait a long time to get a response,
even though the message has actually been received by the MSH running at the
To Party. As the To Party is running both the MSH AND the Application it is
OK for the MSH to send the Delivery Receipt. If the Application is online
and can send a receipt immediately after say it has checked the payload,
then the MSH level Delivery Receipt is not necessary.

Now for some comments on individual emails ...
  
EMAIL THREAD
The following are extracts from various emails on this topic with responses
to each one.

David Fischer: Tue 8/7/2001 1:02 PM
>>  We had long (heated) discussions about this in London and David (B)
assured us that Acknowledgements were for intermediate hops only.
Acknowledgement (sp) only goes back to the previous hop.  This is why it is
only in the Via.<<
<DB>No. Acknowledgements are for Reliable Messaging using the ebXML RM only.
If a message is being sent over MQ Series then an Acknowledgment message is
not needed (although it could be requested) as reliable delivery is provided
in a different way. However whether you are using the ebXML RM protocol or a
proprietary protocol such as MQ Series, you still might want Non Repudiation
of Receipt. This is why you need the Delivery Receipt separate from the
Acknowledgement.</DB>

Chris Ferris: Tue 8/7/2001 9:58 PM
>>The following references cite discussion that clearly demonstrates that
the team had felt that the delivery receipt is an application-level response
[1] [2] [3] [4] and that we endeavored to separate the two so that it was
clear that DR was not related to RM. <<
... and ...
>>Again, it clearly states "To Party" which equates to "application" which
means that it is a business level signal. Nowhere in this section will you
find any discussion of reliable messaging because it is completely
unrelated. A search of the Reliable Messaging section (10) in the spec turns
up a whopping 0 (zero) occurances of the word DeliveryReceipt.<<
<DB>I disagree. The Delivery Receipt is a MSH level response. For example,
in the use case where the To Party MSH stores a message before passing it to
the application. Indeed, if the application receiving the message is an old
application it may not be able to generate the equivalent of a Delivery
Receipt. Hence a Delivery Receipt produced by the MSH is useful. In
addition, I don't think it is the MSH's responsibility to generate messages
business application responses.</DB>

David Fischer: Tue 8/7/2001 6:03 PM
(David B) I am also uncomfortable with having two parameters that imply
essentially the same thing. For example if deliveryReceiptRequested or
immediateAckRequested are both set to NONE, then a syncReplyMode of AcksOnly
or AcksAndResponse would be inconsistent. We really ought be able to avoid
this sort of problem with the correct choice of parameters.

(David F) I still agree. David Burdett may prefer AckRequested rather than
DeliveryRequested (David?).
<DB>In this quote, the two parameters I was refering to as having similar
functionality were the syncReplyMode and either or both of the
deliveryReceiptRequested and intermediateAckRequested. The
deliveryReceiptRequested and the intermediateAckRequested parameters have
different meanings (see above).</DB>

SHIMAMURA Masayoshi: Wed 8/8/2001 5:44 AM
>>It means that if syncReply is set to False, the Reliable Acknowledgement
Message can not carry business level response. If so, at same time, the
Reliable Acknowledgement Message can not carry deliveryReceipt element when
syncReply is set to False. Because deliveryReceipt element is always carried
together business level response.<<
<DB>As the Delivery Receipt is a MSH level response, it can be sent
separately from the business level response.</DB>

David Fischer: Wed 8/8/2001 8:56 AM
>>How about section 9.2.1 & 9.2.2 which describes MSH level Ping & Pong?
Yet the spec says the response is sent:
	The message is then sent to the To Party.
The words "To Party" & "From Party" in these sections are used to describe
the MSH, not an application.<<
<DB>The To Party is BOTH the MSH AND the Application. The MSH is equivalent
to the mail room and the Application to the individual who opens and
processes a letter. They are both part of the same party.</DB>

Jim Hughes: Tue 8/7/2001 10:00 AM
>>Maybe you get more "reliability" if an intermediate MSH node pair use
MQseries, but I think it really confuses the issue when you allow the
presence of intermediate nodes to affect the basic RM algorithm. I think
that a node's use of RM should be quite distinct from the (higher layer?) RM
between the endpoint MSHs.<<
<DB>A node can usefully do its own RM processing especially if it stores a
message before forwarding it as can easily be the case. However hop by hop
RM does not mean that the sender knows that the final destination received
the message which is why you need a Delivery Receipt to let the original
sender know.</DB>

Scott Hinkelman: Tue 8/7/2001 10:17 AM
>>I agree. RM is From <-> To. However, does this imply that if a CPA is
used, and IMs are in the picture that multiparty (if an IM is a party) CPA
is required? Seems to me.<<
<DB>Yes and no. In the exmple above, the intermediary is providing
transformation services but does not "process" the payload in any
conventional sense as they are not the final destination. For example you
could organize it that all letters from French customers go to an outsourced
translation service before they are sent to you. Is the translation service
an integral part of the business relationship between you and your French
customers. I don't think so. Do your French customers need to know that you
have outsourced this part of your operation? Again, I don't think so. On the
other hand there is definitely a business relationship between you and the
French translation service you are using which will need agreements in
place.</DB>

Scott Hinkelman: Wed 8/8/2001 7:22 AM
>>(Marty). It is not at all clear that a multiparty CPA is always needed to
handle intermediaries.  It mostly depends on whether the intermediary
particpates in the business process between the from and to party or acts as
a pass-through. At the moment, the BPSS handles  a multiparty collaboration
as a set of
(Scott) You are hitting on exactly the issue I brought up in [1]. I believe
we need to understand and clearify the functionality and responsibility
differences between a Trading Partner and an IM in order to to resolve much
of this.<<
<DB>Intermediaries CAN be pass throughs in that they do not process the
payload. However intermediaries still have agreements with the parties they
work with. For example as an email user, you have an agreement with your
ISP. However the people you exchange emails with don't need to know anything
about your agreement with them yet the agreement still exists.</DB>

Marty Sachs: Wed 8/8/2001 11:06 AM
>>Certainly an adjacent pair of pass-through intermediaries can forward
messages between themselves reliably "under the covers" but I have no idea
why they would do so since they have no skin in the outcome.  The only ones
the outcome matters to are the From and To parties.<<
<DB>I disagree. They might have a lot of skin in the outcome. For example if
an intermediary stores and forwards a message as a service then they will
want to make sure that they do not lose messages they have received before
forwarding them.</DB>

Let the discussion continue ... ;)


Product Manager, xCBL, XML Standards
Solution Strategy, Commerce One
4400 Rosewood Drive, Pleasanton, CA 94588, USA
Tel/VMail: +1 (925) 520 4422; Cell: +1 (925) 216 7704
mailto:david.burdett@commerceone.com; Web: http://www.commerceone.com