RE: Stop the ... -> Usage Cases

Roger
 
You asked the question ..." Is it just the ability to define a sequence of
messages?"
 
No its not, it's actually a lot more ...
 
To really meet the needs of EDI you need to be able to standardize three
things:
1. The choreography - i.e. the sequence of exchanging messages between
partners - as described below and discussed on this list.
2. The messages - i.e. the business document(s) - note the plural, there can
sometimes be more than one document in a message. The documents can also be
XML as well as non-XML
3. The "operations" for a service - i.e. you have a standard operation that
you use whenever you want to make a hotel booking, for example.
 
Messages
The second item, on messages, requires further discussion as you will NEVER
get a single definition for a message that can apply universally. For
example, Invoices in Europe require a VAT reference number and amount
whereas in the US they would have a Sales tax instead. Another variation,
would be that a hotel invoice, could have details about the dates of stay,
hotel used, etc in the individual line items which would not apply to other
types of invoices. This means that there will be many, potentially thousands
of different definitions of a business document such as an Invoice, where
each one could have a different XML namespace. You also need to remember
that many of the messages will contain multiple documents in separate parts.
For example, if you placed an order for some goods, you might attach a
document that contained a specification of the goods. This could be, plain
text a MS Word document, a CAD/CAM drawing, etc. 
 
The OASIS UBL initiative which is doing a lot of work on handling this type
of problem which they describe as applying a "business context" to a
document - see http://www.oasis-open.org/committees/ubl/
<http://www.oasis-open.org/committees/ubl/>  for more details.
 
Message Families
A useful way handling this variability is to group "similar" business
documents that serve the same business purpose into what I would call
"Document Families", and similarly group similar messages into Message
Families. The idea is that all the documents in a document family or the
messages in a message family are used for the same purpose, e.g. for all the
business documents in the Invoice document or message family would be used
by the seller to request a payment from the buyer. 
 
This means that, in order to meet the needs of EDI, Choreographies (or what
David O called Choreography Templates) MUST be defined in terms of Message
or Document Families - otherwise you will need thousands of choreographies
to handle all the different variations of a document/message which just
won't work.
 
Standardizing Operations
The variation in business documents/ families also means that the same
service MUST be able to accept multiple different documents/messages
belonging to the same Message or Document family - otherwise you will need
thousands of services/operations to support all the variations of an
invoice, for example that you could get. The reason for standardizing
service operations is the same as for standardizing choreographies. If every
hotel, for example, had a different operation or a different service, then
you would still have to do some application programming before you could
exchange messages with it. I accept that this goes against the current
thinking for WSDL.
 
Bottom Line
The current focus of Web Services is on simple interactions where you are
integrating to a single service that accepts a single type of
message/document. This is an absolutely valid use case which we MUST
continue to support. However it is not enough to meet the needs of EDI.
 
David

-----Original Message-----
From: Cutler, Roger (RogerCutler) [mailto:RogerCutler@ChevronTexaco.com]
Sent: Saturday, November 02, 2002 11:31 AM
To: 'Burdett, David'; Cutler, Roger (RogerCutler); 'David Orchard';
www-ws-arch@w3.org
Subject: RE: Stop the ... -> Usage Cases


This is great stuff.   Is it possible to be more specific about what portion
of a choreography standard would be required in this use case to enable
these cost savings?  Is it just the ability to define a sequence of
messages?  That would seem to me to require only a rather simple spec,
wouldn't it?
 
-----Original Message-----
From: Burdett, David [mailto:david.burdett@commerceone.com] 
Sent: Friday, November 01, 2002 3:12 PM
To: 'Cutler, Roger (RogerCutler)'; 'David Orchard'; www-ws-arch@w3.org
Subject: RE: Stop the ... -> Usage Cases


Roger
 
You asked the question ...
 
>>>... are there cost savings to the travel agent involved with
communicating an expected sequence of messages with, say, a hotel in a
standardized way? <<<
 
I think there are as:
1. The travel agent will have to write an application that understands the
sequence of messages.
2. There are probably millions of hotels out there.
3. If hotels around the world use different sequence of messages, then, if
the travel agent wants to exchange electronic messages with them they will
need to adapt their application to each one of them.
4. If there are to many different sequences, then the cost of integration
will be so high that it stop widespread adoption.
 
Let's also think of this from a financial perspective.
 
CASE 1 - Little or no standardization
1. It takes 2 person days of effort to build, adapt, test and deploy a
solution that follows a new sequence of messages for communicating with a
hotel. Cost, $1,000, say
2. There are just 500 different ways of communicating with a hotel - this
assumes there has been some standardization
3. Cost of building adapters to support all hotels = 500 x $1,000 = $500,000
 
CASE 2 - with standardization
1. As above, but now there are just 5 ways of communicating with a hotel
2. Cost is now 5 x $1,000 or $5,000
 
Given this difference in costs, my best on the actual business outcome is as
follows:
1. If there is little or no standardization, then all interactions with
hotels will HAVE to go through a broker or hotel agent system that
understands all the protocols and can map them to just that the travel agent
needs to support. This is effectively standardization by the back door, but
still requires a broker in the middle who provides a service, presumably for
a fee which would probably be charged to the hotel but would be reflected in
higher room rates.
2. If there is standardization, then the travel agent can economically
communicate directly with each hotel. As new hotels add the capability and
they are discovered (e.g. through UDDI), then the agent can interact with
them at next to no additional cost.
 
So, in a sense Roger, standardized interactions are not **required**, but
they sure do reduce the cost of implementation.
 
Hope this helps.
 
David
PS Apologies for the delays in participating on this thread as my emails
were being rejected and then, once they were accepted, I was out of town.
 
 

-----Original Message-----
From: Cutler, Roger (RogerCutler) [mailto:RogerCutler@ChevronTexaco.com]
Sent: Wednesday, October 30, 2002 2:20 PM
To: 'David Orchard'; www-ws-arch@w3.org
Subject: RE: Stop the ... -> Usage Cases


I don't think scuttling the travel case is a good idea.  I'm not trying to
subtract content but to add, or at least to ask for addition.  The travel
use case obviously illustrates sequences of messages.
 
What I am pointing out is the lack of a use case where the business value of
transmitting the choreography from one player to another is made clear.  I'm
beginning to think that there might be some business value hidden in the
travel case, but I have not seen it described clearly.  If it were, I think
it would help focus what is important in the spec.  For example, are there
cost savings to the travel agent involved with communicating an expected
sequence of messages with, say, a hotel in a standardized way?  Not the
whole logic ot the thing, just the part that involves the hotel.  If there
is I don't quite see it, but I think there might be.
 
It seems to me, however, that there are probably other use cases that show
this kind of thing better, perhaps involving companies that sell the same
thing to a lot of other companies.  The travel use case suffers here, I
think, because it sells the same thing to a lot of people, and the thrust of
web services is machine<->machine, not machine<->person.  Unfortunately I am
not in the kind of business setting that gives me personal knowledge of this
sort of interaction.
 
I think to some extent we are talking at cross purposes here.  If the
generic example you mention is the one I think it is, it certainly
illustrates the primary message patterns but is utterly silent about the
business value of standardization.
 
-----Original Message-----
From: David Orchard [mailto:dorchard@bea.com] 
Sent: Tuesday, October 29, 2002 11:36 PM
To: www-ws-arch@w3.org
Subject: RE: Stop the ... -> Usage Cases


I just posted another message on why I think travel is a good example, and
why the generic scenario I came up with covers the main issues.
 
At this point, if the travel example isn't working, then let's just delete
the whole scenario from our documents and minds.  I'm not seeing much or any
support for what I've tried to do with adopting one scenario based upon the
one we have.  Though I'm baffled.  Travel was one of the first things that
programmatic interfaces were put onto, it's been used in a whole bunch of
different choreography specs, and it absolutely is being used for web
services today.  
 
Cheers,
Dave

-----Original Message-----
From: Burdett, David [mailto:david.burdett@commerceone.com]
Sent: Tuesday, October 29, 2002 8:50 PM
To: Cutler, Roger (RogerCutler); 'David Orchard'
Cc: 'www-ws-arch@w3.org'
Subject: RE: Stop the ... -> Usage Cases



Rogedr said ... 

I'm almost certainly oversimplifying, but it seemed to me that the picture 
emrging was one where the public, message driven parts were carrying most of

the business value of standardization, and the much more complex, 
process-involved aspects, particularly of BPEL, were shaking out as more 
relevant to implementation, not standardization. 

... I agree completely 

David 
PS Zahid and I have been unable to make posts for the last few days which
Hugo and Gerald at the W3C have now fixed. This is why we have been so quiet
recently ;)

-----Original Message----- 
From: Cutler, Roger (RogerCutler) [ mailto:RogerCutler@ChevronTexaco.com
<mailto:RogerCutler@ChevronTexaco.com> ] 
Sent: Monday, October 28, 2002 9:33 AM 
To: 'David Orchard' 
Cc: 'www-ws-arch@w3.org' 
Subject: RE: Stop the ... -> Usage Cases 



Although I mostly agree with what you are saying, I think it is unfortunate 
if we are totally focussing for choreography on the Travel Agency Use Case 
because I think that the business drivers for standardizing choreography in 
that one are rather weak.  It seemed to me that some discussion WAY, WAY 
back in the torrent of email was surfacing some usaqe cases where the 
business drivers are much clearer.  For example, 
http://lists.w3.org/Archives/Public/www-ws-arch/2002Oct/0240.html
<http://lists.w3.org/Archives/Public/www-ws-arch/2002Oct/0240.html>  --
which I 
happen to be able to find easily, but there were also several others.  It 
seems to me that if you can see the business drivers clearly that helps to 
winnow the higher value portions of the problem.  For example, I believe 
that the comparisons of public/private, choreography/orchestration and 
message definition/executable (that one is not quite right, I know) were 
moving usefully in that direction. 

I have no desire to debate whether the choreography task needs to be done, I

am just suggesting a business driver approach to high-grading aspects of it.

I'm almost certainly oversimplifying, but it seemed to me that the picture 
emrging was one where the public, message driven parts were carrying most of

the business value of standardization, and the much more complex, 
process-involved aspects, particularly of BPEL, were shaking out as more 
relevant to implementation, not standardization. 

-----Original Message----- 
From: David Orchard [ mailto:dorchard@bea.com <mailto:dorchard@bea.com> ] 
Sent: Monday, October 21, 2002 2:29 PM 
To: www-ws-arch@w3.org 
Subject: Stop the Choreography Definition insanity! 



I've been buried in the gajillion emails about choregraphy; heard proponents

of bpss, wscl, wsci, bpel4ws, and the expected "we don't need no stinking 
yet another ws-* spec" speak up.  This is impossible for a reasonable person

to follow, and certainly for our soon to be bewildered AC reps.  I have a # 
of proposals to help refine the process. 

1. No more "imagine application x.  Message flows blah blah blah" messages. 
I simply can't keep up with the restaurant ordering, POs, travel 
reservations, etc.  Purposefully or accidentally, the myriad of proposals 
prevents us from getting closure.  Let us use ONLY the travel agent usage 
scenario as defined in the *gasp* W3C Web Services Usage Scenarios and Use 
Cases document.  And if it needs additional steps/conditions added, then 
suggest specific changes to the scenario. 

2.  We need actual discussion of REQUIREMENTS, with proposed suggestions. 
For example, I might have requirements: 1. Order of operations MUST be 
expressible.  2.  Dependent Operations MAY be shown in public choreography. 
3. Conditions MAY be exposable.   Therefore, I get something like .. foo .. 

3. Use reasonable subject lines.  I suggest using the requirement (s).  For 
example, if you don't believe in ordering of operations, then the subject 
should reflect such.  Or dependent operations.  Or whatever, just not 
"choreography definition". 

4. Get real.  To be blunt, if this group decides that it wants to re-invent 
choregraphy languages from ground up with n inputs, it will be a total waste

of time.  Simply put, a number of companies are not prepared to go through 
the reinvent the wheel exercise again.  I can state for the record that BEA 
Systems isn't interested in that.  Perhaps it's too much to ask of a 
standards body, in such a short time, but we need to get to closure pretty 
darned fast, and political realities have to reflect that.  And we're going 
to have to find some way of dealing with the fact that some companies and 
people - some of whom aren't w3c member companies - don't want choreography 
done at the w3c at all, so not getting timely closure is a victory.  I have 
every confidence that if choreography isn't standardized at the W3C, it will

happen somewhere else, with commensurately different IPR conditions, process

and influence over the result.  And BEA Systems also believes that only 1 
choreography standard will survive. 

Cheers, 
Dave