>
> 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:[email protected]]
> >> Sent: Thursday, December 28, 2000 10:55 AM
> >> To: '[email protected]'
> >> 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
> >>
>
>
