RE: [USTF] high level classification

1. +1 for URI templates and static #references on (a) classification topics and (b) per use case

2. -1 on keeping current document classification/structure.

3. +1 on higher-order structure. I have sent my thoughts on specifics of that in another e-mail.

-- Igor Sedukhin .. (Igor.Sedukhin@ca.com)
-- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788



-----Original Message-----
From: Cutler, Roger (RogerCutler) [mailto:RogerCutler@chevrontexaco.com] 
Sent: Friday, May 31, 2002 10:47 AM
To: 'Hao He'; 'www-ws-arch@w3.org'
Subject: RE: [USTF] high level classification



First, I am moving this to the public list since there does not seem to be anything secret about the discussion.  If I'm missing something sensitive here I apologize.

As I documented before, the present document has the following high level
structure:

<quote>
This document specifies a variety of web services usage scenarios. It is organized roughly as:

S0**: Message exchange patterns, ie rpc, asynchrony, security, reliablity, conversations

S2**: Event based message exchange patterns

S3**: System and other messages

S5**: Service Description above and beyond those in less than 5** numbers

S6**: Discovery.
</quote>

The current document also has anchors that follow the convention shown above.

I personally don't really care very much what structure is used to classify the usage cases -- it seems to me that yours is rather similar in spirit but different in detail from the one in the current document.  What I DO care about, however, are the URI's -- because I would like to refer to them in the EDI-like usage ensemble (whatever we are calling it now) document that I am working on.  Putting in a whole bunch of links to the more atomic usage cases seems to me a useful thing to do, but it is also a lot of work.  And I would prefer, if possible, to do it once.  That is, the idea that the URI's might all be changing shortly is somewhat demotivating.

I would like to suggest that we just take the document more or less as it is and run with it -- perhaps ADDING to the high level structure as needed but keeping what is already there.  I'm not hearing any reason why the current structure is not good, simply that there is another that is also good and might even be a little better -- or might not -- we could probably argue about that.  But given the amount of sunk investment in the current structure, is such an argument really necessary?  Can we just live with what we have?

Of course, if we do that we would need, at the least, to add a higher order structure reflecting the two types of usage case we have been discussing, whatever we call them.  You know, the assemblages like Amazon and EDI and the atomic ones like "Fire-and-Forget".  And possibly some more Sn's, I guess, to reflect additional categories of atomic cases.

-----Original Message-----
From: Hao He [mailto:Hao.He@thomson.com.au] 
Sent: Thursday, May 30, 2002 6:31 PM
To: 'w3c-ws-arch@w3.org'
Subject: [USTF] high level classification


hi,

Here is a repost of the email I sent last week.

As of today's discussion, we might want to change:

<business-point-of-view> to <business-usage-scenarios>

and

<technology-point-of-view> to <technical-usage-scenarios>

Hao

----------------------------------------------------------------------------
--

As discussed in last week's phone conversation, it was agreed to have some high level classifications of possible usage scenarios. Such classification aids better understanding and collecting of usage scenarios.

I've come with a quick list I can think of. I am sure that you will throw in more and better ideas. 

I tried to look at the classifications from business point of view and technology point of view. Hopefully, we can combine them and get better coverage of all possible and distinct scenarios.

<classification of="WS usage scenarios" >

<business-point-of-view>

<role name="Service consumer">

1. Service discovery

2. Service negotiation (Service level agreement, service attribute)

3. Service engagement

4. Service feedback, (Optional)

</role>

 

<role name="Original Service Owner (OSO)">

1. Service management (ensures the well-being of the service)

2. Service advertising

</role>

<role name="Service Integrator" >

1. Service integration

</role>

</business-point-of-view>

<technology-point-of-view>

1. Stateless services

2. Stateful services

3. Service identification

4. Service communication

</technology-point-of-view>

</classification>

Received on Friday, 31 May 2002 11:51:31 UTC