RE: security and timing parameters

[Bob Haugen <linkage@interaccess.com>]

<Karsten Riemer>
OK,
now I know that you do not want them only in the RespondingActivity only.
Where do you want them? Two choices left. Put them in RequestingActivity only,
or put them in the BusinessTransaction only.
Your wish is my command.
</Karsten Riemer>

You're so obliging!

Ok, I made my my mind: I vote for RequestingActivity only.
I don't think they should go on the BusinessTransaction,
because they do not cover Start and Termination and
anything in the BusinessTransaction beyond the 
transaction scope as defined by the RequestingActivity.
This may not be a problem in terms of the predefined
transaction patterns, but (for example) if somebody
wanted to do something special before terminating,
it should not be covered by the transaction timing
parameters.

Now here are a bunch of cautions about that decision, 
why I hesitated:

1. I understand that the value of those timing parameters
will be the same for both Requesting and Responding
Activities.  But putting them on only one side assumes
an implementation where both sides get all the properties
of the RequestingActivity.  If that is not the case, the
RespondingActivity will not know when it is supposed
to respond.  (Needless to say, this is not a problem
for the infrastructure schema.)

2. There are going to be some metamodel implications
here that I have no idea how to deal with.

In other words, this might be one of those decisions
that is only good for the infrastructure release.

Respectfully, 
Bob Haugen