Re: [ebxml-cppa] View about assingned issues [RosettaNet RetryParameter ]

[Yukinori Saito <y-saito@ecom.jp>]

Dear Arvola:

Thank you very much for your detailed comments.

I understood followings.
-RosettaNet PIPs are retried due to messaging level failure rather than
business level failure.
-The background the recent CPPA specification says "Such retries (retryCount
attribute) MUST not be used when ebXML Reliable Messaging is employed to
transport messages in the Business Transaction."
-The reason why CPPA specification uses the different words. ['retryCount'
attribute (under BusinessTransactionCharacreristics element) and  'Retries'
element (under ReliableMessaging element)]

But I yet have the following fundamental questions or feelings.
(1) Is it suitable that the 'retryCount' attribute is specified under
BusinessTransactionCharacreristics element, even though this 'retryCount'
means messaging level retries?
(2) It is ambiguous what is the difference between 'retryCount' attribute
[under BusinessTransactionCharacreristics element] and  'Retries' element
[under ReliableMessaging element], and how to choose these functions
clearly.

Followings are my proposals.
(1) Change the position of 'retryCount' attribute from under
BusinessTransactionCharacreristics element to under MessagingCharacteristics
element like dupuricateElimination attribute.
Reason: 'retryCount' attribute means messaging level retries actually.
(2) Guideline how to choose 'retryCount' attribute or 'Retries' element
-If a party want to specify details about Retries, e.g. Retry count, Retry
interval, and Message order semantics, the party had better select Reliable
messaging function under ReliableMessaging element.
-If a party want to specify only Retry count, the party had better select
'retryCount' attribute under MessagingCharacteristics element.
In this case, as the value of Retry interval, the CPP/CPA middleware may
adopt default value (e.g. 2 hours) or the value of 'Time to Acknowledge
Receipt Signal'

Regards,
Yukinori Saito

----- Original Message -----
From: "Arvola Chan" <arvola@tibco.com>
To: "Yukinori Saito" <y-saito@ecom.jp>; "Martin W Sachs"
<mwsachs@us.ibm.com>
Cc: <ebxml-cppa@lists.oasis-open.org>; "EDIgr)K.Mizoguchi"
<mizoguchi@ecom.or.jp>; "EDIgr)H.Sugamata" <sugamata@ecom.or.jp>;
"EDIgr)K.Wakaizumi" <waka@ecom.or.jp>
Sent: Monday, March 25, 2002 11:17 AM
Subject: Re: [ebxml-cppa] View about assingned issues [RosettaNet Retry
Parameter ]


Saito-san:

Please see my comments bracketed by <arvola></arvola>.

-Arvola

----- Original Message -----
From: "Yukinori Saito" <y-saito@ecom.jp>
To: "Arvola Chan" <arvola@tibco.com>; "Martin W Sachs" <mwsachs@us.ibm.com>
Cc: <ebxml-cppa@lists.oasis-open.org>; "EDIgr)K.Mizoguchi"
<mizoguchi@ecom.or.jp>; "EDIgr)H.Sugamata" <sugamata@ecom.or.jp>;
"EDIgr)K.Wakaizumi" <waka@ecom.or.jp>
Sent: Thursday, March 21, 2002 7:15 PM
Subject: Re: [ebxml-cppa] View about assingned issues [RosettaNet Retry
Parameter ]


> Marty, Arvola, and Pallavi,
> Thank you very much for your comments.
>
> [Question about RosettaNet Retry Parameter]
> What is a typical cause of Business level Retries imaged by RosettaNet
group
> and BPSS project group?

<arvola>
The main reason for retry under the RosettaNet Implementation Framework is
to recover from control failures like timeouts. In RNIF 1.1, a request
action message may be retried due to non receipt of the Receipt
Acknowledgment signal before the timeToAcknowledgeReceipt expires, or due to
non receipt of the response action message before the timeToPerform
expires.In RNIF 2.0, a request action message may be retried only due to non
receipt of the Receipt Acknowledgment signal; there is no retry of the
action message if the response action message is not received prior to the
expiration of timeToPerform.
</arvola>

> (When the transaction would be failed, the originating business document
> would be delivered again under RosettaNet Retry count control.)
> Which are suitable examples followings?
> (1) The originating business document is 'Purchase Order Request', but the
> responding business document would be 'Quote'. This case is that the
> responding business message is not matched to the originating business
> document. (Business Process level failure) In this case, The Receipt
> Acknowledgement signal would be delivered correctly.

<arvola>
The initiator should send a Receipt Acknowledgment Exception to the
responder since the response document does not pass schema validation.
</arvola>

> (2) The originating business document is 'Purchase Order Request', and
some
> products codes in the business document would not be accepted by the
Seller.
> This case is that the contents of the originating business document is
> mistaken. (Business Process level failure) In this case, the Receipt
> Acknowledgement signal would be delivered correctly also.

<arvola>
The initiator would first return a Receipt Acknowledgment signal since the
response document passes schema validation. On determining that the response
document does not pass business rule validation, a Notification of Failure
PIP would be initiated by the initiator.
</arvola>

> (3) The content of ConversationId element of the responding business
> document is not matched to the content of ConversationId element of the
> originating business message. This case may be messaging level failure.
But
> The Receipt Acknowledgement signal would be delivered.

<arvola>
Yes, the Receipt Acknowledgment would be delivered.
</arvola>

> (4) The Receipt Acknowledgement signal did not be received to originator
> because of Internet trouble. This case is typical messaging level failure.

<arvola>
In RNIF 2.0, the initiator expects to receive both the Receipt
Acknowledgment signal and the response action message. These may arrive out
of order, but the initiator expects to have received both messages before
the PIP is considered successful.
</arvola>

> (5) or any other else
>
> I judged RosettaNet Retry count issue is messaging level failure, because
> Arvola said "Asynchronous PIPs have a Retry parameter that governs how
many
> additional retries a sender will send a message, if it has not received a
> Receipt Acknowledgement signal from the other party" by original issue. I
> thought if the Receipt Acknowledgement signal would not be sent, this
would
> be messaging level failure, not a business level failure.  And because
> RosettaNet PIP Specification Guide categorizes Retry count as FSV level,
not
> as BOV level.

<arvola>
Yes, RosettaNet PIPs are retried due to control failure rather than business
failures.
</arvola>

>
> [Another question and recommendation]
> I am sorry that I did not noticed there already is 'retryCount attribute'
> under BusinessTransactionCharacreristics element in CPPA V1.10.
>
> But I have another question and recommendation.
> "8.4.13.12 retryCount attribute" says "Such retries MUST not be used when
> ebXML Reliable Messaging is employed to transport messages in the Business
> Transaction."
> I think this expression is unsuitable. I think the consensus is that this
> Business level retryCount is another function other than Reliable
Messaging
> retries. Therefore there will be possible to use Business level retries
even
> if the business document would use ebXML Reliable Messaging.
>
> The word is different each other between Business process level retries
and
> Reliable messaging retries.

<arvola>
I believe this issue has been discussed at one of the weekly conference
calls and the consensus was that it would be very confusing if there is
retry both at the messaging layer and at the messaging layer. That's why we
added the statement in section 8.4.13.12.
</arvola>

> 'retryCount' attribute  [under BusinessTransactionCharacreristics element]
> 'Retries' element        [under ReliableMessaging element]
> How about matching the word of 'Retry'?
> For example,
> (1) Change the name 'Retries' element to 'RetryCount' element to mach the
> word of 'retryCount' attribute of BusinessTransactionCharacreristics
> element.
> (2) Or change the name 'retryCount' attribute to 'retries' attribute to
mach
> the word of 'Retries' element of ReliableMessaging element.
> I think (1) is much better, because RosettaNet specification and BPSS
> specification uses the word 'Retly Count'.

<arvola>
In the BusinessTransactionCharacteristics element, we have a retryCount
attribute in order to be aligned with the BPSS specification. In the
ReliableMessaging element, we have a Retries element in order to be aligned
with the ebMS specification.
</arvola>

>
> Regards,
> Yukinori Saito
>
>
> ----- Original Message -----
> From: "Arvola Chan" <arvola@tibco.com>
> To: "Martin W Sachs" <mwsachs@us.ibm.com>; "Yukinori Saito"
> <y-saito@ecom.jp>
> Cc: <ebxml-cppa@lists.oasis-open.org>; "EDIgr)K.Mizoguchi"
> <mizoguchi@ecom.or.jp>; "EDIgr)H.Sugamata" <sugamata@ecom.or.jp>;
> "EDIgr)K.Wakaizumi" <waka@ecom.or.jp>
> Sent: Thursday, March 21, 2002 1:41 AM
> Subject: RE: [ebxml-cppa] View about assingned issues
>
>
> Saito-san:
>
> All RosettaNet PIPs currently have a retry parameter. When RosettaNet PIPs
> are expressed as BPSS instances, it is possible to map the RosettaNet
retry
> parameter to the BPSS business transaction level retryCount parameter
(which
> the BPSS team has recently decided to add to the spec in order to be
> consistent with the UMM), or to specify the use of Reliable Messaging. I
> think there is general agreement that either business level retry or
> Reliable Messaging should be used, but not both. We have not yet come to
the
> conclusion that all RosettaNet PIPs when transported over ebMS must use
> Reliable Messaging, so it may be up to the individual PIP designer to
decide
> which one of these two retry mechanisms should be used.
>
> -Arvola
>
> -----Original Message-----
> From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
> Sent: Wednesday, March 20, 2002 6:07 AM
> To: Yukinori Saito
> Cc: ebxml-cppa@lists.oasis-open.org; EDIgr)K.Mizoguchi;
> EDIgr)H.Sugamata; EDIgr)K.Wakaizumi
> Subject: Re: [ebxml-cppa] View about assingned issues
>
>
>
> I have a reply below to Saito-san's  discussion.
>
>
****************************************************************************
> *********
>
> 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
>
****************************************************************************
> *********
>
>
>
>                       Yukinori Saito
>                       <y-saito@ecom.jp>        To:
> ebxml-cppa@lists.oasis-open.org
>                                                cc:
"EDIgr)H.Sugamata"
> <sugamata@ecom.or.jp>, "EDIgr)K.Mizoguchi" <mizoguchi@ecom.or.jp>,
>                       03/19/2002 08:17          "EDIgr)K.Wakaizumi"
> <waka@ecom.or.jp>
>                       PM                       Subject:  [ebxml-cppa] View
> about assingned issues
>
>
>
>
>
>
> Followings are my view about assigned issues.
>
> 87: RosettaNet Retry Parameter not Expressible in BPSS or CPP/A
>
> I studied some RosettaNet PIPs (PIP2A1, PIP3A1, and PIP3A4) and PIP
> Specification Guide.
> These PIPs specify 'Retry Count' under 'Business Process Activity
Controls'
> section. And the value of Retry Count of these PIPs is '3'. '3' is
> RosettaNet default value for asynchronous execution.
> Retry count means that if the Acknowledgement signal would not be received
> against originating business activity, the originator would send the
> originating business document again within the specified Retry count.
> I think this function means a kind of reliable messaging.
> The PIP Specification Guide categorizes Retry count as FSV parameter, not
> as
> BOV parameter.
>
> I think that RosettaNet PIPs had better just use ReliableMessaging element
> in CPP/CPA usually, like the recent CPP example.
> The recent CPP example (CPP-example-companyA-016.xml) is supposed to adopt
> RosettaNet PIP3A4 as Service and Action, and is adopting ReliableMessaging
> element.
> There are other subelements (RetryInterval element and
> MessageOrderSemantics
> element) other than Retries element under ReliableMessaging element of
> CPP/CPA. As the value of these subelements, CPP/CPA might adopt default
> value, e.g. PT2H and Guaranteed.
>
> In view point of BPSS, BPSS is a specification about business process
> level,
> not a specification about messaging level. Therefore I think it is
> reasonable for BPSS not to have Reliable messaging parameters, e.g. Retry
> parameter.
>
> MWS:  Retries at the BPSS level relate to transaction failures, not to
> reliable messaging.  In other words, the transaction failed although the
> message was delivered.  This is a business process matter.  Arvola can
> correct me if necessary but I understand that some RosettaNet PIPs do
> provide for business process level retries.
>
> 221: nonRepudiationOfreceipt attribute concerns business level ack
>
> I think this issue was resolved, as Marty mentioned by e-mail on March 18.
>
> 230: ds:Keyinfo subelement structure handled implicitly by deployment
tool?
>
> The disposition indicates "Maybe resolved: Add "deployment software"".
> The following NOTE is already explained at '8.4.17.2 ds:KeyInfo element'
in
> CPPA specification V1.10.
> "NOTE: Software for creation of CPPs and CPAs MUST recognize the
ds:KeyInfo
> element and insert the subelement structure necessary to define the
> certificate."
> I think this NOTE explains about deployment software. If my understanding
> is
> insufficient, someone please add some suitable NOTE.
>
> Regards,
> Yukinori Saito
> ---------------------------------------------------
> Yukinori Saito
> Electronic Commerce Promotion Council of Japan (ECOM)
> E-mail: y-saito@ecom.jp
> Tel: +81-3-3436-7542    Fax: +81-3-3436-7570
> ---------------------------------------------------
>
>
>
>
>
> ----------------------------------------------------------------
> 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>
>
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>