RE: New top goal proposal: Management and SLA

We will have use cases for SLA. That is fine, but my feeling is that an important aspect of the WS Architecture is being put aside and diluted. Technically speaking SLAs are an intricate area, but stating a top *goal* of providing a sound architecture with *service agreements* in place is, to my opinion, very necessary for the group.

When someone is building a series of WSs and looks at the architecture concept we would provide, Security is properly stated and standards are appointed, Reliability is too, etc. So one would build a service that users can kick tires around. It would be good for internal EAI projects, it may be good for convincing CIOs to spend more money, but it is not a business component yet. It would be lacking a very important aspect. Without it the architecture would look to much like just another component infrastructure or just another messaging framework 'a la' XML.

So, my point is that use cases would not be enough. It has to be a goal of the group to provide WS Architecture that takes into account agreements and negotiation and provisioning, etc.
We don't have to spend years doing vertical SLA standard recommendations, but we do have to indicate what should be done if a WS was meant as a business component, what standards are used to express agreements and where are the boundaries of technology applicability. In other words place it in the Architecture like any other important area such as Security.

Also I doubt anyone besides us is going to pay much attention to the use cases.

And finally, I don't think service agreements are examples of using Security or Reliable messaging.

-- 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: Tuesday, June 04, 2002 8:19 PM
To: Sedukhin, Igor; www-ws-arch@w3.org
Subject: RE: New top goal proposal: Management and SLA


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.

Hao



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

-----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 21:22:14 UTC