- From: Hao He <Hao.He@thomson.com.au>
- Date: Wed, 5 Jun 2002 10:18:33 +1000
- To: "'Sedukhin, Igor'" <Igor.Sedukhin@ca.com>, www-ws-arch@w3.org
- Message-ID: <686B9E7C8AA57A45AE8DDCC5A81596AB019ED759@sydthqems01.INT.TISA.COM.AU>
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
Attachments
- text/plain attachment: InterScan_Disclaimer.txt
Received on Tuesday, 4 June 2002 20:17:36 UTC