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