RE: T2: ackRequested attribute in Via element

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

CPPA matters below.

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
*************************************************************************************
---------------------- Forwarded by Martin W Sachs/Watson/IBM on 08/07/2001
10:07 AM ---------------------------

"Burdett, David" <david.burdett@commerceone.com> on 08/06/2001 09:58:56 PM

To:   "'Arvola Chan'" <arvola@tibco.com>, ebXML Msg
      <ebxml-msg@lists.oasis-open.org>
cc:   mwang@tibco.com
Subject:  RE: T2: ackRequested attribute in Via element




See  comments inline

David
-----Original Message-----
From: Arvola Chan  [mailto:arvola@tibco.com]
Sent: Monday, July 30, 2001 2:08  PM
To: Burdett, David; ebXML Msg
Cc:  mwang@tibco.com
Subject: Re: T2: ackRequested attribute in Via  element


David:

Please see my comments inline.

Thanks,
-Arvola
----- Original Message -----
From:  Burdett, David
To: 'Arvola Chan' ; ebXML Msg
Cc: mwang@tibco.com
Sent: Monday, July 30, 2001 12:11  PM
Subject: RE: T2: ackRequested attribute  in Via element

Arvola

Setting the ackRequested to Signed or Unsigned is a  decision that the
designer (and/or implementer) of the business process  makes when they
design or build a business process collaboration or business  process
transaction. Factors that need to be considere include  (IMO):

   The natuure of the business process/transaction -  e.g. payments
   probably need to be secure
   The requirements of the individual trading  partners

This brings up a Messaging Service Interface  question. Does the
application (i.e., whatever software is above the MSI  layer) instruct the
MSH to send a message reliably, and/or to specify the  use of MSH level
acknowledgement, or is it the responsibility of the MSH to  infer from the
CPA and such message header elements as Service, Action,  CPAId, etc. the
quality of service that should be used for sending a  message, and then set
the QualityOfServiceInfo and Via elements  accordingly?
[David  B] I think there are several use cases which are all equally
valid:
1. The MSH looks up the  CPA
2. The Application tells the MSH to send the  data reliably
3. The MSH infers what to do by looking at the  service and action (or
other data) in the header and looking up what to do  in some type of rules
database.

Once the CPA knows what to do it should set the  QualityOfService and Via
elements accordingly.

I have always thought that the ackRequested  attribute should be set if
reliable messaging is being used. Is it allowable  to set deliverySemantics
to OnceAndOnlyOnce and to either omit the Via  element or to include a Via
element but set ackRequested to None?
[David B] As currently  specified I think that you have to use the Via
element if you are doing  reliable messaging as you need ackRequest to be
set even if you are  doing a single hop. The reason that ackRequested is in
the Via element is  because the need for ackRequested is removed if you are
doing multiple  hops and one of the hops is using a proprietary "reliable
messaging  protocol" e.g IBM MQ Series. This really indicates thatr the Via
element is  wrongly named IMO. What are your thoughts about changing it
...

The concept of an Acknowledgement message to  support reliable messaging
seems muddled with the concept of the  Acknowledgement element which is
primarily used to provide non-repudiation  of receipt. My colleagues at
TIBCO have pointed out to me that it seems  possible to send an
Acknowledgement message that does not carry an  Acknowledgement element,
and that only the RefToMessageId is  required.  (See lines 1816 and 1817 in
Section 10.3.3.) Can you  please confirm that this indeed is the case?
[David B] I think that what you say is  correct.


I  think what would be really useful is to have a guide that describes how
to  design a business process/transaction using ebXML Messaging. Do you
agree?  If so hould it be in the 1.1 spec or something separate.

Either way is fine with me, as long as the guide is  available around the
time the 1.1 spec is published.
[David B] Any  volunteers?

I  think that if an error is dicovered then including the ackRequested set
to  true on the error message runs the risk of a never ending series of
messages. The only use cases to consider are where a message is being sent
reliably in which case ...

My question was whether the error message should be  sent reliably. I was
under the impression that the CPA determines the role  played by the
receiver and the delivery channel that it will use for  receiving messages.
If the delivery channel uses a doc exchange that calls  for the use of
reliable messaging, then shouldn't the error message be sent  reliably?
[David  B] Yes if the messages are being sent  synchronously.

   If the message that was in error has ackRequested  set to
   Signed/Unsigned and the error message sent in return is lost, then  the
   sender of the original message will resend it which will cause the
   error message to be resent - see example 1 below
   If the message that was in error has ackRequested  set to None (e.g. it
   is a synchronous resposne) then sending the error  message with Ack
   Requested set to Signed/Unsigned makes sense otherwise  the sender of
   the error message will not know if the message was delivered  - see
   example 2 below

EXAMPLE 1
Message (with  error)(AckRequested=S/U)---------------------->
<---------------ErrorMessage (Includes  Acknowledgment element)

If the message is in error, I doubt if the  responder is obligated to
include an Acknowledgement element in the error  message, even if
AckRequested has been asked for.
[David B] Perhaps. Even if  he did not then the rules say that any errors
in an error message are  not responded to so it would not make much
difference.

EXAMPLE 2

Message (no  errors)(AckRequested=S/U)------------------------>
<-------Message (with error) (Includes  Acknowledgment element)


Error Message  (AckRequested=S/U)----------------------------->

<---------------Message (Includes Acknowledgment  element only)

I still don't  see why in example 1 the sender of the error message does
not set  AckRequested to S/U while in example 2 the sender of the error
message sets  AckRequested to S/U.
[David B] In example 1, suppose the ErrorMessage was  lost, then, as the
original message was sent reliably, the sender would  resend it which would
cause the Error Message to be resent. This means that  the ErrorMessage
does not need to be sent reliably as the sender of the  Error Message knows
that they will receive the original message again if the  error message is
lost
In example 2, the Error Message  needs to be sent reliably as the sender
wants to make sure that it was  received. If it is not sent reliably then
there will be no  acknowledgement.
 Perhaps the design guide you suggested  earlier should clearly define the
error scenarios when reliable messaging  and/or AckRequested are to be
used.

A general  rule (it's somewhere in the spec but I can't immediately find
where) says  that if you find an error in an error message then you don't
respond with  another error message and sort out the problem by some other
means.



Regards
David
-----Original Message-----
From: Arvola Chan  [mailto:arvola@tibco.com]
Sent: Friday, July 27, 2001 7:40  PM
To: ebXML Msg
Cc:  mwang@tibco.com
Subject: T2: ackRequested attribute in Via  element


Section 8.7 does not clearly indicate the  circumstances under which the
ackRequested attribute should be set (to  Signed or Unsigned). Is this
governed by the ReliableMessaging and  NonRepudiation element for the
DocExchange associated with the  DeliveryChannel that is being used?

In particular, when an error is encountered  in processing a message, what
should be the strategy for setting the  ackRequested attribute in the error
message? In other words, under what  circumstances, if any, are error
messages to be sent  reliably?

Thanks,
-Arvola