W3C home > Mailing lists > Public > public-ws-chor@w3.org > January 2004

FW: Burdett 1/20/2004: Auction Use Case

From: Burdett, David <david.burdett@commerceone.com>
Date: Wed, 21 Jan 2004 09:31:44 -0800
Message-ID: <99F57F955F3EEF4DABA7C88CFA7EB45A0CB998D1@c1plenaexm04.commerceone.com>
To: "WS Choreography (E-mail)" <public-ws-chor@w3.org>
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.





Received on Wednesday, 21 January 2004 12:32:26 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 18 December 2010 01:00:47 GMT