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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

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


Subject: Re: [ebxml-msg] A proposal for the interpretation of differentsynchronous reply modes in the CPP/A


Bruce:

I think you have brought up a very good point. In my last message, I was
trying to point out that the response to a reliably delivered message that
requires synchronous response is not exactly sent reliably (i.e., with
retries). The responder is not required to explicitly retry the response
message. However, it must still persist the response message, so that
when the requester retries the request message, the corresponding
response message can be looked up from persistent store and returned
synchronously to the requester. After all, we want the request message
to be processed once and only once by the To Party's, with its response
delivered back to the From Party appropriately.

I think some clarification in section 10 (Reliable Messaging) is necessary
to describe how reply messages are returned synchronously.

Thanks,
-Arvola

-----Original Message-----
From: PEDRETTI,BRUCE (HP-NewJersey,ex2) <bruce_pedretti@hp.com>
To: ebxml-msg@lists.oasis-open.org <ebxml-msg@lists.oasis-open.org>; 'Arvola
Chan' <arvola@tibco.com>
Date: Thursday, October 11, 2001 9:13 AM
Subject: RE: [ebxml-msg] A proposal for the interpretation of different
synchronous reply modes in the CPP/A


>Arvola,
>
>This sounds pretty good.  I have a question regarding signalsOnly and
>signalsAndResponse.
>
>Is there a (remote) possibility that the business interaction may not
>proceed?  The spec draft from Oct. 1, 2001 (the latest I have) in the
>"Receiving Message Behavior" subsection of the "ebXML Reliable Messaging
>Protocol" there is indication that the responder MSH is only obliged to
>persist the message id, not the whole message.
>
>If:
>1) the synchronous response of the first message is lost,
>2) the requestor retries, and
>3) the responder finds a duplicate message id in its persistent store with
>no corresponding message,
>Then:
>according to the spec the responding MSH should "ignore" the message.
>
>If the responding MSH ignores all retries, the business deal never
>completes.  I'm basing all this on these lines from the spec (from same
>"Receiving Message Behavior" section):
>
>"d) If the message is a duplicate, then do the following:
>...
>"iii) If no message was found in persistent storage, then:
>(1) if syncReply is set to True and if the CPA indicates an application
>response is included, ignore the received message (i.e. no message was
>generated in response to the message, or the processing of the earlier
>message is not yet complete)"
>
>I've assumed:
>1) since the business signal response is synchronous "syncReply" would be
>True.
>2) "receipt acknowledgment business signal" constitutes an "application
>response is included" in the  initial response
>2) the CPA would indicate an "application response is included" in the
>message
>
>In order for this definition of signalsOnly to work, it seems as though the
>responder MSH *MUST* persist the response if the CPA "indicates an
>application response is included".
>
>Please help me understand if my assumptions are in error, or if I have
>misinterpreted you or the spec draft.
>
>b
>
>============================================
>Bruce Pedretti       Hewlett-Packard Company
>Software Developer   6000 Irwin Road
>(856) 638-6060       Mt. Laurel, NJ 08054
>http://www.hp.com/
>============================================
>
>-----Original Message-----
>From: Arvola Chan [mailto:arvola@tibco.com]
>Sent: Wednesday, October 10, 2001 6:44 PM
>To: ebxml-cppa@lists.oasis-open.org
>Cc: ebxml-msg@lists.oasis-open.org
>Subject: [ebxml-msg] A proposal for the interpretation of different
>synchronous reply modes in the CPP/A
>
>
>Consider a typical business transaction that includes both a
>RequestingBusinessActivity and a RespondingBusinessActivity. Assume that
>receipt acknowledgment signals are to be used both for the request activity
>and for the response activity (i.e., their time to acknowledge receipt are
>specified), but no acceptance acknowledgment signal is to be used (i.e.,
>time to acknowledge acceptance is not specified for the request activity).
>Furthermore, assume that the business level messages are to be exchanged
>using Reliable Messaging.
>For the default (fully asychronous) response mode using HTTP binding, each
>such transaction includes the following 8 messages that are sent over 8
>separate HTTP connections:
>
>  1.. Reliable request message from requestor to responder
>  2.. Best-effort MSH level Ack from responder to requestor (for message 1)
>  3.. Reliable business level Ack from responder to requestor
>  4.. Best-effort MSH level Ack from requestor to responder (for message 3)
>  5.. Reliable response message from responder to requestor
>  6.. Best-effort MSH level Ack from requestor to responder (for message 5)
>  7.. Reliable business level Ack from requestor to responder
>  8.. Best-effort MSH level Ack from responder to requestor (for message 7)
>The use of synchronous reply modes can be effective for reducing the total
>number of messages / HTTP connections necessary to complete the
transaction.
>The CPP/A spec currently recognizes the following synchronous reply modes:
>
>  1.. signalsOnly
>  2.. signalsAndResponse
>  3.. responseOnly
>A new synchronous response mode mshSignalsOnly is hereby proposed. The
>following interpretation of these 4 synchronous reply modes is suggested:
>
>  1.. mshSignalsOnly - The MSH level Acknowledgment (which can include an
>MSH level Acknowledment element, a MSH level DeliveryReceipt element, or
>both) is returned as a self-contained ebXML message in the same connection
>that is used to carry the incoming message being acknowledged. Business
>level signals and response messages are returned separately. If this
>synchronous reply mode is used uniformly for all of the business level
>messages, the above business transaction can be accomplished using 4
>separate HTTP connections.
>  2.. signalsOnly - The MSH level Acknowledgment (which can include an MSH
>level Acknowledment element, a MSH level DeliveryReceipt element, or both),
>along with the receipt acknowledgment business signal and the (optional)
>acceptance acknowledgment signal are packaged into the same ebXML message
>and returned in the same connection that is used to carry the incoming
>message being acknowledged. The above message does not have to be sent
>reliably because it is being returned synchronously. If it is not properly
>received by the requester, the original request message will be retried
>because the requester is using Reliable Messaging. The business response
>message must be sent reliably (i.e., with retries) over a connection that
is
>separate from the one used for the request message. If this synchronous
>reply mode is applied to both the request message and the response message,
>the above business transaction can be accomplished using 2 separate HTTP
>connections.
>
>  3.. signalsAndResponse - The MSH level Acknowledgment, plus the receipt
>acknowledgment business signal, plus the (optional) acceptance
>acknowledgment signal, plus the business response, are all packaged into
the
>same ebXML message and returned in the same connection that is used to
carry
>the incoming request message. This effectively overrides the BPSS
>specification and does away with the business level receipt acknowledgment
>from the requestor to the responder to indicate successful receipt of the
>response message. Because the signals and response are returned
>synchronously, the embodying ebXML message does not need to be sent
>reliably. There will not be any retry for this ebXML message. If the
>requestor does not receive the signals and response message, it can simply
>retry the request message. The entire business transaction can be
>accomplished in one HTTP connection.
>  4.. responseOnly - The response message is returned synchronously. This
>also effectively overrides the BPSS specification and does away with the
use
>of business signals in the transaction altogether. No receipt
>acknowledgement business signal is to be used for either the request
message
>or the response message. The MSH level Ack (which can include an MSH level
>Acknowledment element, a MSH level DeliveryReceipt element, or both) can be
>piggybacked on the business response message. As in the case of
>signalsAndResponse, the response message does not need to be sent reliably
>because it is being returned synchronously. Again, the entire business
>transaction can be accomplished in one HTTP connection.
>Because the signalsAndResponse and responseOnly synchronous reply modes do
>away with the sending of the receipt acknowledgment business signal for the
>response message, non repudiation of receipt for the response message
cannot
>be accomplished. In the case of signalsAndResponse, non repudiation of
>receipt for the request message can still be supported. Both the
>mshSignalsOnly and signalsOnly synchronous reply modes allow for the non
>repudiation of receipt for both the request message and the response
>message.
>
>If a reliably delivered message is in error, the receiving MSH returns a
>standalone MSH level error message that is sent using BestEffort only, if
>synchronous reply mode is not in use. Otherwise, the standalone MSH level
>error message is returned synchronously. If the incoming message has been
>passed onto the receiving application and the latter determines that there
>is an error, an application level error message (considered a business
>signal) is returned. The quality of service used for this business signal
>should be governed by the synchronous reply mode as applied to business
>signals. For both the signalsAndResponse and signalsOnly modes, the
business
>signal is returned without an accompanying business response. For the
>responseOnly synchronous reply mode, it is not immediately obvious how the
>application level error message should be returned. However, for the sake
of
>simplicity, it is recommended that it be treated as a response message and
>returned synchronously.
>
>The above treatment of the signalsAndResponse and responseOnly synchronous
>reply modes is more or less consistent with the treatment of synchronous
>response in the RosettaNet Implementation Framework version 2.0.
>Essentially, no receipt acknowledgment is used for the response message. In
>RosettaNet's case, there is no provision for piggybacking a business signal
>on a business response message. Thus, a business signal can only be
returned
>synchronously if the transaction does not call for returning a response
>message (in other words, the transaction has a single action rather than
two
>actions). If there is a response message, then no receipt acknowledgment
>signal for the request message can be included in the synchronous response.
>The RosettaNet Implementation Framework does not allow for non repudiation
>of receipt for the response message, if synchronous reply mode is in use.
>
>Please let me know if this proposal makes logical sense.
>
>Thanks,
>-Arvola
>
>
>
>
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>



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


Powered by eList eXpress LLC