RE: security and timing parameters

[Karsten Riemer <Karsten.Riemer@East.Sun.COM>]

I am responding to both Bob and Dave in this e-mail.

First, to Dave, I think you misunderstood my intent. I fully agree that the 
"timeToAcknowledgeReceipt and timeToAcknowledgeAcceptance" are required
parameters in order to define the business transaction. I am not suggesting
dropping them.

I was just trying to pinpoint exactly where in the metamodel they get defined.

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 :-)

The other comment is that we decided to drop all reference to retry. Jim said
he would be removing this from the bigger metamodel, too.

thanks,
-karsten



>Karsten et al ..
>
>I may not be using the defintion concepts in the correct context, my
>appology, but from Bob's defintions of "timeToAcknowledgeReceipt and
>timeToAcknowledgeAcceptance" as they pertain to business operating
>activities, these together with security (which at least I'm defining the
>concept as who I as the sender authorize to the receiver is allowed to
>perform a unit of work for me) are essential elements of and core to the
>fabric of business. 
>If you would like specific business examples of common business proecess
>that occur around the world today, I'd be more than happy to list and detail
>out a few.
>
>I can't imagine letting a supplier respond back to my puchase order ...
>'whenever' in a direct customer-supplier relationship (ex. drop ship
>customer orders off the Internet), or as an intermediary allowing anyone to
>do work on my behalf at a vendor site without exercising some degree of
>reasonable business limitations on the vendor in a
>customer-intermediary-vendor relationship chain where the intermediary is
>servicing the customer (ex freight forwarding in global transport).
>
>Thanks
>Dave
>
>
>
>> -----Original Message-----
>> From: Bob Haugen [mailto:linkage@interaccess.com]
>> Sent: Thursday, December 28, 2000 10:55 AM
>> To: 'ebxml-bp@lists.ebxml.org'
>> Subject: RE: security and timing parameters
>> 
>> 
>> Karsten and all,
>> 
>> Is this a test to see if we are paying attention?
>> (Note:  this is the only parameter assignment I have payed
>> attention to so far.)
>> 
>> <KR>
>>     NOTE: I am not putting timeToAcknowledgeReceipt and
>>     timeToAcknowledgeAcceptance
>>     into RequestingBusinessActivity even though they were in the
>>     BusinessActivity superclass. They are only relevant to 
>> the responding activity. 
>>     I actually think TimeToPerform is not relevent to the 
>> requestor either, but leaving 
>>     it here for now.
>> </KR>
>> 
>> My reading of the spec indicates that both Responding and
>> Requesting BusinessActivities use those parameters in
>> different ways.  The transaction is a unit of work from the
>> viewpoint of the Requesting activity; therefore, if the time
>> parameters are exceeded (that is, the required ack or
>> document does not arrive by the appointed time), the
>> Requesting activity can abort the transaction.
>> 
>> From the description of TimeToAcknowlegeReceipt:
>> "A sending partner must retry a commercial transaction if necessary 
>> or must send notification of failed business control 
>> (possibly revoking 
>> a contractual offer) if a responding partner does not verify properly 
>> receipt of a business document request within the agreed time 
>> period.  
>> The time to acknowledge receipt is the duration from the time 
>> a business 
>> document request is sent by a requesting partner until the time a 
>> verification of receipt is "properly received" by the 
>> requesting business 
>> partner. This verification of receipt is an audit-able 
>> business signal and 
>> is instrumental in contractual obligation transfer during a contract 
>> formation process (e.g. offer/accept)."
>> 
>> -Bob Haugen
>>