RE: Use Case - Provisioning

David,
 
I don't think this will be a problem. Sub-Processes can be used to reference re-usable activities. I made a quick update to the diagram to show an example (Provisioning2.jpg). The "Send Invoice" and "Send Payment" Tasks are now within a Sub-Process so that they would only need to be developed once. Presumably, you would compose more complex choreography processes that send multiple messages, rather than a single activity that sends a message. This issue will probably come up more clearly in other use cases and we will see if the diagrams can handle the situations adequately. I will be working on representing the use cases that have been submitted.
 
-Steve

 -----Original Message----- 
 From: Burdett, David [mailto:david.burdett@commerceone.com] 
 Sent: Thu 4/3/2003 4:28 PM 
 To: Stephen White; public-ws-chor@w3.org 
 Cc: 
 Subject: RE: Use Case - Provisioning
 
 

 Stephen 

 I like your diagram. I think there are many similarities with the diagram and equivalent in XML that I sent out earlier [1]. I have a question though, at the end of the choreography, you send an Invoice. Wouldn't sending an Invoice be common to multiple choreographies? In which case, is there a way in which we can make sending an Invoice a common choreography that could be reused as part of a larger choreography?

 Regards 

 David 

 -----Original Message----- 
 From: Stephen White [mailto:swhite@SeeBeyond.com] 
 Sent: Thursday, April 03, 2003 4:20 PM 
 To: public-ws-chor@w3.org 
 Subject: RE: Use Case - Provisioning 


 This use case is much more complex than the patient-receptionist-doctor use case. But I took a stab at creating a diagram for it (see attached), with many assumptions based on my interpretation of the description. I also assumed the use of multiple party choreographies for this draft. If we decide on using only bi-party choreographies, then this diagram would have to be divided into three separate ones. Frank had a good point in the discussion about the other diagrams in that we should be careful about how we present things, both internally and externally.

 -Steve 

 -----Original Message----- 
 From: Champion, Mike [mailto:Mike.Champion@SoftwareAG-USA.com] 
 Sent: Sunday, March 30, 2003 6:32 PM 
 To: public-ws-chor@w3.org 
 Subject: RE: Use Case - Provisioning 



 > -----Original Message----- 
 > From: Lipton, Paul [mailto:Paul.Lipton@ca.com] 
 > Sent: Sunday, March 30, 2003 3:59 PM 
 > To: public-ws-chor@w3.org 
 > Subject: Use Case - Provisioning 
 > 

 > The example called for a new employee to receive the usual junior 
 > executive faux-oak desk. After checking internal resources that are 
 > outside of this use case (perhaps empty offices or warehouses 
 > within the 
 > company), no suitable desk is found. So, a choreography is "initiated" 
 > in which an order is placed with one of the approved 
 > suppliers (Company 
 > B) registered in the private UDDI registry of Company A. 

 This seems like a fairly promising use case, but the exposition discusses 
 "choreography" in the most general terms rather than describing a use case 
 for a formal WS Choreography standard.  I think I can imagine something, 
 e.g. Company A publishes its WSChoreography document so that its suppliers 
 "know" that they can respond to an order for a faux oak desk with something 
 else of comparable price and quality (having read "Zen and the Art of 
 Motorcycle Maintenance" I wouldn't ever TRY to define "quality" <grin>). 
 Having a common Choreography description format might not allow software 
 agents on both sides to automagically negotiate the substitution for the 
 faux mahogony desk for the one ordered, but it would at least tell 
 programmers what conditions to look for and where to find the UDDI registry 
 or WSDL description for the alternate responses. 

 So,  I'd like to see this scenario recast to make explicit how a WS 
 Choreography standard would make it easier for people with this (and other) 
 use cases to do their business. 
 >