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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-cppa message

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


Subject: [ebxml-cppa] Re: [ebxml-msg] A proposal for the interpretation ofdifferent sy nchronous reply modes in the CPP/A


Bruce,

I think that this is an oversight in the spec. The response message
to any reliably delivered message MUST be persisted. What it says on
line 1799+ suggests thsi, but you are correct in that nowhere does it
say that the response message(s) need to be persisted. They MUST be
in order for this to function as intended (the response is retrieved
from persistent storage and returned in response to receipt of a
duplicate message.

Cheers,

Chris

PEDRETTI,BRUCE (HP-NewJersey,ex2) wrote:

> David, you have brought up a second issue, right?  If the business reply
> never comes, then can't we safely assume that the application is behaving in
> error (the original assumption was that the CPA requires a business-level
> response).  If we can make this assumption, then it seems like human
> intervention is ultimately needed to fix the app (or the app's input).
> 
> The way the spec sets things up now, if a business reply never comes, the
> requesting MSH retries until its retry algorithm is complete (because it
> never receives a response), then notifies the requesting app of a
> transmission failure.  Human intervention should be the next step.  Does
> that solve the problem?  The responding MSH still has a process that is
> waiting for its app, but that should get cleaned up during the debugging (or
> vendors may implement their own methods for taking care of a such
> situations).
> 
> Does this sound right to you?  
> 
> The question I asked of Arvola requires a different solution, but I'm not
> sure what is best.  One possibility is to require responding MSH's to
> persist messages that contain business-level responses and are not
> transmitted reliably (in order to effectively handle retries if the response
> is lost).
> 
> ============================================
> Bruce Pedretti       Hewlett-Packard Company
> Software Developer   6000 Irwin Road
> (856) 638-6060       Mt. Laurel, NJ 08054
> http://www.hp.com/
> ============================================
> 
> -----Original Message-----
> From: David Fischer [mailto:david@drummondgroup.com]
> Sent: Thursday, October 11, 2001 11:46 PM
> To: Arvola Chan; PEDRETTIBRUCE (HP-NewJerseyex2);
> ebxml-msg@lists.oasis-open.org
> Cc: ebxml-cppa@lists.oasis-open.org
> Subject: RE: [ebxml-msg] A proposal for the interpretation of different
> synchronous reply modes in the CPP/A
> 
> 
> Yes, Bruce, I wondered the same thing.  I think by "ignore" someone was
> thinking
> that the MSH was already waiting for a business reply.  But, what if the
> business reply never comes?
> 
> I agree, we need to fix this.  What should it be?
> 
> Regards,
> 
> David Fischer
> Drummond Group.
> 
> -----Original Message-----
> From: Arvola Chan [mailto:arvola@tibco.com]
> Sent: Thursday, October 11, 2001 11:59 AM
> To: PEDRETTIBRUCE (HP-NewJerseyex2); ebxml-msg@lists.oasis-open.org
> Cc: ebxml-cppa@lists.oasis-open.org
> Subject: Re: [ebxml-msg] A proposal for the interpretation of different
> synchronous 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>
>>
> 
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
> 
> ----------------------------------------------------------------
> 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