Re: please confirm (Fwd)

[Karsten Riemer <Karsten.Riemer@east.sun.com>]

Subject to a reply from Jim Clark to my below e-mail,
here is my suggested definitions for the four strings we have adopted at
Business Transaction and Binary Collaboration levels:

beginsWhen: A description of an event external to this
collaboration/transaction that normally causes this collaboration/transaction
to commence.

endsWhen: A description of an event external to this collaboration/transaction
that normally causes this collaboration/transaction to conclude.

requires: A description of a state external to this collaboration/transaction
that is required before this collaboration/transaction can commence

resultsIn: A description of a state that does not exist before the execution
of this collaboration/transaction but will exists as a result of the execution
of this collaboration/transaction 




>----------------Begin Forwarded Message----------------<

Date: Sun, 11 Mar 2001 22:14:08 -0500 (Eastern Standard Time)
From: Karsten Riemer <Karsten.Riemer@east.sun.com>
Subject: Re: please confirm
To: Jim Clark <jdc-icot@lcc.net>
cc: Karsten.Riemer@east.sun.com

Thanks for your response on this one,
now we have another one that came up in a meeting last week.
Can you confirm that the intent of "beginsWhen" is in fact to represent some
external event that causes this collaboration to commence, and that "endsWhen"
 is some external event that causes this collaboration to conclude. Is the
intent to  describe events that cause abnormal or normal conclusion or both.

Also, should we review the re-try, or are you for sure dropping it from UMM?

Also, if timeToPerform is for the whole transaction, then why is it repeated
both in requesting and in responding activities?

-karsten


>Karsten,
>My response is in context of the current state of the BP Spec not the UMM.
>
>Karsten Riemer wrote:
>
>> Hi Jim,
>> Could you please confirm the following understanding:
>>
>> We do support/allow an AcknowledgementOfReceipt back from the original
>> requesting role to the responding role upon receipt of the substantive
>> response.
>
>Yes
>
>
>
>> And we do support a signed version of that ack to enable the
>> responding role to do non-repudiation of receipt.
>
>yes, this is why the receipt must be more than a transport signal back. It is
>a
>receipt from the requesting role with the appropiate tamper proof signature.
>
>
>
>> But even if such ack is
>> required, the transaction as such closes upon receipt of the substantive
>> response by the requesting role.
>
>Correct. It is the receipt of the response that effects the state change,
>transferance of obligation and effecting of commitments.
>
>> Control does not pass back to the responding
>> role. Is there a time-out associated with this last, post transaction ack?
>
>No. No time out has been defined as part of the receipt_ack though we did
>talk about
>it. I was determined that either a higher level process (collaboration) or
>backend
>process would control the resend of the response in case of no receipt.
>
>>
>>
>> Also, please confirm the following understanding:
>>
>> We do NOT support an AcknowledgementOfAcceptance back from the original
>> requesting role to the responding role upon receipt of the substantive
>> response.
>
>It not make any sense to.
>
>>
>> And finally, is the following statement true:
>>
>> Regardless what pattern of messages/signals is chosen the messages will
>always
>> be in the following sequence:
>>
>> 1.      Sent by RequestingRole: Request -  Always Required
>
>>
>> 2.      Sent by RespondingRole: ReceiptAcknowledgement - Optional (Except
>if
>> nonrepudiationOfReceipt)
>
>The default is mandatory. The only optional case is for info distribution and
>then it
>may be wise to require it.
>
>>
>
>>
>
>> 3.     Sent by RespondingRole: AcceptanceAcknowledgement
>> - Optional
>
>Not for BT's and when preedit validation or long running transactions are
>needed to
>supported.
>
>> 4.   Sent by RespondingRole: SubstantiveResponse - Optional
>
>True.
>
>>
>> 5.      Sent by RequestingRole: ReceiptAcknowledgement - Optional (Except
>if
>> nonrepudiationOfReceipt)
>
>The default is required. May be needed for other reasons than just
>nonrepudiation.
>
>>
>> thanks,
>> -karsten


>----------------End Forwarded Message----------------<