W3C home > Mailing lists > Public > www-ws-arch@w3.org > May 2002

FW: [USTF] #IDs/URIs template for use cases and classification

From: Sedukhin, Igor <Igor.Sedukhin@ca.com>
Date: Fri, 31 May 2002 14:32:39 -0400
Message-ID: <849C1D32E4C7924F854D8A0356C72A9E0468555A@usilms08.ca.com>
To: www-ws-arch@w3.org

FYI, down below

-- 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 1:53 PM
To: Sedukhin, Igor
Subject: RE: [USTF] high level classification

OK by me.

-----Original Message-----
From: Sedukhin, Igor [mailto:Igor.Sedukhin@ca.com] 
Sent: Friday, May 31, 2002 11:04 AM
To: Cutler, Roger (RogerCutler)
Subject: RE: [USTF] high level classification

I guess they can be preserved. Current URIs are sub cases/leaf nodes. The classification would merely impose higher-level systematization on top of that.

For example

#Architecture-technicalDetails #Architecture-messagingProptocols #SOAP #SOAP-MEP #SOAP-MEP-fireAndForget

So IDs are formed #<disposition>-<topic>-{<specifics>}*
Where <disposition> would be "Architecture" for the WSAWG classification, "SOAP" for XMLPWG, "WSDL" for WSDWG, etc.

If you like this, let's post it to the group as a guideline.

-- 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 11:54 AM
To: Sedukhin, Igor
Subject: RE: [USTF] high level classification

Do you think that the current URI's can be preserved in the more elaborate classification you are proposing?

-----Original Message-----
From: Sedukhin, Igor [mailto:Igor.Sedukhin@ca.com] 
Sent: Friday, May 31, 2002 10:50 AM
To: Cutler, Roger (RogerCutler); 'Hao He'; 'www-ws-arch@w3.org'
Subject: 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

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.

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


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>


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



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


<role name="Service consumer">

1. Service discovery

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

3. Service engagement

4. Service feedback, (Optional)



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

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

2. Service advertising


<role name="Service Integrator" >

1. Service integration




1. Stateless services

2. Stateful services

3. Service identification

4. Service communication


Received on Friday, 31 May 2002 14:34:09 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:40:56 UTC