- From: Burdett, David <david.burdett@commerceone.com>
- Date: Wed, 21 Jan 2004 09:31:44 -0800
- To: "WS Choreography (E-mail)" <public-ws-chor@w3.org>
- Message-ID: <99F57F955F3EEF4DABA7C88CFA7EB45A0CB998D1@c1plenaexm04.commerceone.com>
Forgot to copy this to the list David -----Original Message----- From: Burdett, David Sent: Tuesday, January 20, 2004 3:06 PM To: 'Monica J. Martin' Subject: RE: Burdett 1/20/2004: Auction Use Case Monica Thanks for the feedback. I've made some comments in line. I've also attached an updated use case (it's only 9k) to hopefully clarify some of the points you made. David -----Original Message----- From: Monica J. Martin [mailto:Monica.Martin@Sun.COM] Sent: Tuesday, January 20, 2004 2:39 PM To: Burdett, David Cc: WS Choreography (E-mail) Subject: Burdett 1/20/2004: Auction Use Case Burdett, David wrote: > As promised, here's the auction use case. To make it a bit more > interesting I've included some descriptions of how problems are > handled as well as the dependency of one use case on another. > > Comments welcome. > > David > > > Director, Standards Strategy > Commerce One > One Market Street, Steuart Tower, Suite 1300, San Francisco, CA 94105, USA > Tel/VMail: +1 (415) 644 8700; Cell: +1 (925) 216 7704 > <mailto:david.burdett@commerceone.com>; Web: > <http://www.commerceone.com <http://www.commerceone.com/>> > > mm1: Comments to use case. Thanks for doing this, David. Buyer Registration * Registration may occur outside of the choreography. Implies context / policy items. * See WSRP on their registration that does this associated with web services, not specific to choreography. Where do we draw the line, and more notably with the registration be observable. Likely, not. <DB>My thoughts on this was that this was NOT a registration to use/consume a web service. It was more the Buyer providing information to the Seller about his name, address, contact information, perhaps even credit card details, etc. so that the Seller could check that he was a 'bona fide' buyer and therefore the seller would accept bids from the buyer and indicate this in response the seller sends back. It's a similar idea to eBay where you have to register with eBay before you place any bids. Even though this would probably be simple request/response mechanism, the registration process would be an observable process - at least to the two parties (buyer and seller) involved. The buyer needs to know what to put in the registration and also know that the registration is required before they can place bids on an auction. The reason this was defined as a separate choreography is that although registration could occur just once, it could be used for more than auctions. For example, the seller might send out a newsletter that also uses the same basic registration process with perhaps some different options selected in terms of what the buyer selects. So suppose you had the same documents exchanged in the same sequence where the buyer in one was registering for the newsletter and in the other for placing auction bids. Are they one choreography or two? I think one. I also agree that it does imply some context/policy terms since there is a dependency between the registration and auction choreographies. The question is, how should this be handled from a choreography persective. </DB> Auction Notification * The buyer could respond that they will not currently bid. However, * they be allowed to monitor as they can bid for another party or later bid. What is meant by 'no' or 'negative' response - in context of participation, monitoring, etc? <DB>What I meant by no or negative response was that the buyer was indicating that they did not want to recieve any messages related to the auction. However this does not stop them from bidding as is described later in the Use Case. I've clarified the text which now says ... "If the potential buyer wants to receive messages that relate to an auction, then they reply in the affirmative to the notification. A negative response from the buyer means that the buyer does not want to receive any messages associated with the auction. No response from a buyer is interpreted by the seller in the same way as a negative response. Note however, that a negative response from the Buyer does not stop the buyer from bidding (see later)." </DB> Need to differentiate notification messages. They are not the same and the processing or implications will be different. Differences may be understood above the choreography [1]. <DB>I agree. However, I think it is quite realistic that a choreography designer, however misguided, might want to use the same message for different purposes as they contain the same content even though the semantics are different because they are being used in a different part of the choreography. The question is should the CDL allow this or should we require that each message/interaction in a choreography definition be different?</DB> Previous no or negative response are ambiguous to stop message. Perhaps they just monitor and do not explicit ask not to participate. <DB>As said earlier, the previous no or negative response means that they no longer want to receive messages associated with the auction. The stop message means that, although they were receiving messages, they no longer want to do so.</DB> Placing the Bid: Bid notification may also be private. [1] Closing the bid: Same comment on visibility. [1] <DB>I agree this is possible, but then this would be a different choreography as the bids made would not be re-broadcast to the other bidders. The main purpose for writing this use case was so that it provided an example of the need to send the same message to multiple participants who could vary in number dynamically.</DB> [1] possible business semantics May also impact auction status or search.
Attachments
- application/octet-stream attachment: AuctionChoreographyUseCase_v2.htm
Received on Wednesday, 21 January 2004 12:32:26 UTC