Re: request for clarification

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

Jim,
thanks for explaining the conditions around control failure.
Now I am curious if we can describe in general terms when a signal might be
sent from the requesting party to a responding party.

I now understand that a receiptAcknowledgement is always required from
responding to requesting role. Is it always required from requesting to
responding role. I guess I know the answer to that. It couldn't always be
required, because sometimes there is no responding business document. But is
it always required when there is a responding business document? Or is it only
required when explicitly stated as part of the individual pattern?

Also, if requestor sends a receiptAcknowledgement, can that then be used for
non-repudiationOfReceipt of the responding Business Document?

And for acceptanceAcknowledgement. Would there ever be an
acceptanceAcknowledgement from the requesting to the responding role?

The answer to these questions will affect the placement of timing/security
parameters. If both requesting and responding roles can send signals, are
there then separate time-outs governing the signals in the two directions?

-karsten


>Karsten,
>
>Your understanding on how it should work, even when the wording is not a
>precise
>as it should be, is correct. The " requesting role cannot send a business
>signal
>to the responding role" is meant for the context of this paragragh. The issue
>is
>that in the case of a control failure there is no assurance that business
>signal
>can be sent to the responding activity or role. The intent is to assert that
>if
>there is a need to proactively cancel a pending transaction, it needs to be
>done
>via a different route. It needs to be handled outside of the transaction in
>order
>to assure that the responding role cannot deny that "I told you to cancel
>the
>order". In RNet they have a convention that says that if a control exception
>occurs they will execute the "Notify of Failure" PIP if a partner role (eg,
>Dept
>Mgr, Cust Service) has been identified to recieve this notifications. In this
>way,
>there can be a guartentee that the repoding role actually aborts the
>transaction.
>
>The bottom line is that business signals can be and are sent to the
>responding
>activity. Just in this case it makes no sense or has no guarentees.
>
>Best regards,
>Jim Clark
>Principal Consultant
>I.C.O.T.
>936.264.3366
>
>Karsten Riemer wrote:
>
>> Jim,
>> here is another request for clarification:
>>
>> The following phrase is a cut and paste from the metamodel document.
>>
>> A responding role that throws a business protocol exception signals the
>> exception back to the requesting role and then terminates the commercial
>> transaction. A requesting role that throws a business protocol exception
>> terminates the transaction and then sends a notification revoking the
>> offending business document request. The requesting role cannot send a
>> business signal to the responding role.
>>
>> The last sentence says the requesting role cannot send a business signal
>to
>> the responding role. I had previously understood that to mean never, ever.
>But
>> now I am wondering if it is only within the context of the paragraph. The
>> reason for this question is that in the patterns I see requesting roles
>> sending receiptAcknowledgement signals. So a follow-up question is are
>> receiptAcknowledgement from the responding role sometimes, never, or
>always
>> required (or allowed)?
>>
>> thanks,
>> -karsten