Re: T2: ackRequested attribute in Via element

[Arvola Chan <arvola@tibco.com>]

Chris:

Sorry for the delayed response. Please see inline.

Thanks,
-Arvola

-----Original Message-----
From: christopher ferris <chris.ferris@east.sun.com>
To: Martin W Sachs <mwsachs@us.ibm.com>
Cc: ebxml-cppa@lists.oasis-open.org <ebxml-cppa@lists.oasis-open.org>
Date: Tuesday, August 07, 2001 7:34 AM
Subject: Re: T2: ackRequested attribute in Via element


Comments embedded.

Cheers,

Chris

Martin W Sachs wrote:
<snip/>
> ----- 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.

Surprisingly, I agree with David;-) This is one of the aspects that makes
it difficult to prescribe a canonical MSI, because there are so many valid
ways of achieving the desired result.

My take is that the CPA defines the rules to which the parties have
agreed by which they will exchange messages. Whether an MSH/MSI uses
the CPA directly, or whether the "application" (whatever that means)
instructs the MSH (e.g. by constructing the message header itself)
is in my mind irrelevant SO LONG AS the rules of engagement as prescribed
in the CPA are followed.

<arvola>
I agree with you and David that the rules of engagement should be prescribed
in the CPA.

If the ebxml-msg TC does take on the task of formally defining a MSI as part
of the 2.0 effort, then I think it should cover all of the common use cases.
</arvola>

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

I disagree (whew! ;-) There is adequate information in the message header
as well as in the CPA without abusing the Via element which is used
exclusively
for multi-hop message paths.

<arvola>
Are you suggesting that the ackRequested and syncReply attributes in the Via
element should only be used in the multi-hop case? The 1.0 spec requires you
to use the Via element even for a single-hop situation if there is a need to
set either one of the above two attributes.
</arvola>

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

The Acknowledgment element is used EXCLUSIVELY for RM. The DeliveryReceipt
is what has been provided for NR and other related business signals.

<arvola>
If the Acknowledgement element is used exclusively for reliable messaging
and not for non repudiation, then I don't see why it should include a
ds:Reference element.

Also, if the Acknowledgement element is always included in an
Acknowledgement message used to support reliable messaging, then it would be
redundant to use the ackRequested attribute. Shouldn't deliverySemantics of
OnceAndOnlyOnce already imply that the message must be acknowledged?

I have always wanted to ask you about the relationship between the
DeliveryReceipt element and the notion of business signals used in the BPSS
spec. The latter defines the payload structure of the business level signal
messages but make no reference to the DeliveryReceipt element in the MSG
spec. Is the application supposed to send the business signal messages and
request the MSH to tag on a DeliveryReceipt element to the business signal
messages? The ReceiptAcknowledgement DTD defined in section 9.1.1 in the
BPSS spec already carries an originalMessageDigest element. Would that be
redundant if the DeliveryReceipt element already carries a ds:Reference
element?
</arvola>

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

Oh ohhh... I have to agree again;-) Looks like the cited reference is
incorrect. At a minimum, an acknowledgment message (for RM) MUST also
include the Acknowledgment header.

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

Possibly. As has been done for other specifications, possibly a tutorial
or primer is something that the TC should consider. I would shy away from
incorporating it in the specification since it would have to be
non-normative.
No sense in adding to the confusion by adding a treatise on how to
construct a business message.

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

I'd say that if the messages are being delivered reliably that *application*
errors
would be delivered reliably as well unless it were specified otherwise.
However,
for MSH-level errors, this may not be the case. I would think that these
would
be treated just as acknowledgment messages, e.g. not sent reliably since
they
would constitute a negative ack.

<arvola>
I agree, but this should be clarified in the 1.1 spec.
</arvola>

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

Right.

>
> 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
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-cppa-request@lists.oasis-open.org

------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-cppa-request@lists.oasis-open.org