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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-bp message

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


Subject: RE: security and timing parameters


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.
We are still talking just about the "timeToAcknowledgeReceipt and
"timeToAcknowledgeAcceptance" time out parameters only.

As for parameters that actually say that a receiptAcknowledgement is required,
or that a non-substantive response is required, I don't think that such
parameters ever existed. The time-out being non-zero is an implicit flag
saying the response is required.

I think a good solution would be to introduce such flags explicitly so that:

RespondingBusinessActivity:
    ReceiptAcknowledgementRequired (boolean)
    AcceptanceAcknowledgementRequired (boolean)

RequestingusinessActivity:
   timeToAcknowledgeReceipt (time-unit) --- or rename to
ReceiptAcknowledgementTimeOut
   timeToAcknowledgeAcceptance (time-unit) -- or rename to
AcceptanceAcknowledgementTimeOut

thanks,
Karsten

><Karsten Riemer>
>To Bob, a couple of comments:
>I don't agree that "timeToAcknowledgeReceipt and
>timeToAcknowledgeAcceptance"
>could or should be interpreted differently by requestor and responder. And I
>don't see anything in your cut-and-pasted text that supports that. What you
>quote is my understanding, too, that "timeToAcknowledgeReceipt and
>timeToAcknowledgeAcceptance" both are there to specify how long after the
>sending of the original requesting message the requestor should terminate
>(i.e. abort) the transaction in the absense of a response. I put the
>parameters in the responding activity because they are in essence
>requirements
>on the responder. If you would rather have them on the reqesting activity, I
>will move them, but they cannot be both places, because they define only one
>thing. Another option would be to put them at the transaction level because
>they define the overall transaction, not one activity or the other. Give me
>you vote, and I will model it that way if no-one else responds. (How long
>should I wait for a response :-)
></Karsten Riemer>
>
>By "interpreted differently":  I meant "use in different ways".
>My reading was that the parameters are requirements for the
>responder (as you indicated), but timeouts for the requestor,
>who could terminate the transaction (which the responder
>cannot do directly).  I did not mean they would be interpreted
>as different durations or anything like that.  As to putting them
>in one or both places, the original metamodel seems to 
>do that since they are defined on a superclass.  Both activities
>need to know and use the values. I vote against putting them
>only on the Responding activity.  Since this easy to change,
>wait as long as you can and still make the deadline of 1/3/2001.
>
>-Bob
>




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

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC