RE: security and timing parameters

["Welsh, David" <David.Welsh@nordstrom.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.
> 
OOPS then I jumped too fast and read your msg out of context, thanks
Karsten. Have a good holiday.
Dave


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