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

RE: New top goal proposal: Management and SLA

From: Hao He <Hao.He@thomson.com.au>
Date: Wed, 5 Jun 2002 10:18:33 +1000
Message-ID: <686B9E7C8AA57A45AE8DDCC5A81596AB019ED759@sydthqems01.INT.TISA.COM.AU>
To: "'Sedukhin, Igor'" <Igor.Sedukhin@ca.com>, www-ws-arch@w3.org
I actually agree with you that SLA covers a much broader range of issues
than D-AC018 does.  However, this is because SLA is one of the usage
scenarios.  A quick look at SLA reveals that it requires the following:

1. Reliable messaging 
2. Security
3. Privacy
4. Metrics and monitoring
5. Management
6. Stability and of the service 
7. Service description 
... and more ...

The list has already covered a large number of goals in the requirement
document, while all those goals and requirements can be used in other cases
as well. 

My feeling is that it might be more suitable to discuss SLA as a major use
case in USTF rather than a high level goal.


-----Original Message-----
From: Sedukhin, Igor [mailto:Igor.Sedukhin@ca.com]
Sent: Wednesday, June 05, 2002 12:55 AM
To: Hao He; www-ws-arch@w3.org
Subject: RE: New top goal proposal: Management and SLA

D-AC018 is under Reliability goal, also specific focus is instrumentation &
metrics. SLA is much broader than even Reliability itself, how can it be
under a subtopic of it?

Reliability covers other areas like reliable messaging and routing.
Reliability is not the sole goal nor final result of the SLA or management
included. The goal is to *properly serve* the user of a service, and that
means more than merely 24x7. What if a service is available, but does
semantically different function or charges more money for it. Is that
reliability too? While management can detect the later, it provides for the
original agreement with the client/user, and that is why management
infrastructure exists in the first place.

One has to agree on SLA, negotiate it, then only collect metrics and manage,
etc. My view is that SLA comes above and before management and
instrumentation infrastructure. I just don't want a tool become primary
focus and a goal become a feature of a tool.

What is it that we want first: services and users to agree on usage, and
then we want to instrument and provide for it.

So, I would rather state the top goal clearly and then indicate "how" it may
be achieved as a subtopic.

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

-----Original Message-----
From: Hao He [mailto:Hao.He@thomson.com.au] 
Sent: Monday, June 03, 2002 8:07 PM
To: Sedukhin, Igor; www-ws-arch@w3.org
Subject: RE: New top goal proposal: Management and SLA

I am happy to explicitly state SLA as part of D-AC0018.  However, I feel
that SLA is more like at the usage level.  The implied purpose of D-AC0018
is that people can manage web services, reach SLA, and even evaluate web
services independently, and do other things (services integration, ...).
Basically, once you have a standard set of metrics and management, you can
do heaps of things (and SLA is just one of them).  
 -----Original Message-----
From: Sedukhin, Igor [mailto:Igor.Sedukhin@ca.com]
Sent: Monday, June 03, 2002 11:50 PM
To: Hao He; www-ws-arch@w3.org
Subject: RE: New top goal proposal: Management and SLA

Service Level Agreements are not part of D-AC0018. Management
instrumentation is needed to ensure SLAs, reliabiliy is usually one of the
parameters of an SLA. And while I have no problems with Reliability being a
top goal for other reasons, I propose to have *SLA* and Management as
another top goal. D-AC0018 is altogether part 4.1 of my proposal.

Again, I'm primarily concerned about *agreements* and management
instrumetation/metrics being a way to maintain an agreement.

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

-----Original Message----- 
From: Hao He [ mailto:Hao.He@thomson.com.au <mailto:Hao.He@thomson.com.au> ]

Sent: Sunday, June 02, 2002 7:27 PM 
To: Sedukhin, Igor; www-ws-arch@w3.org 
Subject: RE: New top goal proposal: Management and SLA 

I believe this is what D-AC0018 was originally intended for.  

-----Original Message----- 
From: Sedukhin, Igor [ mailto:Igor.Sedukhin@ca.com
<mailto:Igor.Sedukhin@ca.com> ] 
Sent: Saturday, June 01, 2002 3:03 AM 
To: www-ws-arch@w3.org 
Subject: New top goal proposal: Management and SLA 

I was reading our requirements document and realized that there is not a
proper attention being paid to a very important aspect of a service:
agreements between a user and the owner. This is not any less important
element than security for that sake. How can business components comprise a
"digital economy" without agreements?

Now, agreements have to be established, maintained, accounted for, and may
be enforced. Management metrics/instrumentation is merely "how" details of a
bigger goal, and the Reliability is an intermediate effect/characteristic.

Reliability goal has other aspects in messaging, etc. and while I do not
want to contend with it in any way, I'd like to pull Manageability and SLAs
higher on the stack. Here is my proposal for the new top goal.

Goal: Manageability and Service Agreements 
Web Services Architecture must provide a manageable environment for
establishing, maintaining and enforcing Service Level Agreements.

Critical success factors for this goal are: 
To develop standard reference architecture for Web Services that: 

1. Identifies how to express SLAs and associate them with Web services 
1.1 Service usage policies 
1.2 Web service licensing standards 
1.3 Identify technical/legal boundary 

2. Identifies automatic/manual SLA negotiation process 

3. Identifies how agreements are established and preserved 
3.1 License persistence and verification procedures 
3.2 Privacy of SLAs 
3.3 Integrity and non-repudiation of SLAs 

4. Identifies management/instrumentation/metrics standards/technologies
necessary to meter and account for service usage

4.1 - subsume/reference D-AC018 

5. Identifies procedures/standards necessary to maintain the agreement 
5.1. Identify technology/commerce boundary 

6. Identifies SLA enforcement procedures 
6.1 Usage/metrics reconciliation procedures 
6.2 Attempt/provide for automatic conflict resolution 
6.3 Identify technology/legal boundary 

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

Received on Tuesday, 4 June 2002 20:17:36 UTC

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