OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsrf message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [wsrf] Proposed resolution - re: InitialValues for properties in WS-RMD

RMD has been designed to provide additional information to clients so they can better interact with resources. InitialValues is not useful to a client after a resource has been instantiated and is of very little use before the resource has been instantiated due to the changing nature of resources.
RMD has not been designed for service configuration or deployment. In fact there is significant information missing from it to be sufficient for this purpose. For instance, service dependencies, version requirements, transport, security, and reliability requirements are not covered by RMD. This is for good reason as there are other specs which handle this information such as SDD and SDM. The WSRF charter does not cover work in this area.
To address your specific points below:
1. The WSDM properties you mention should just be data in RMD and not properties in the resource model with initialValues.
2. Interesting data, but it does not help a client, because in order for a resource to have those values it must be instantiated, and once instantiated the data begins to change - perhaps before the client can do anything.
3. Again, interesting data, but not particularly useful.
4. Instance relationships should not be in initial values because that significantly restricts the environment that the service can be deployed.
5. I think the utility of such a tool based on initialValues would be fairly limited. No client could even register for change notificaitions before values have already changed from the initial values.

From: Heather Kreger [mailto:kreger@us.ibm.com]
Sent: Friday, April 07, 2006 9:21 AM
To: Murray, Bryan P.
Cc: Daniel Jemiolo; wsrf@lists.oasis-open.org
Subject: RE: [wsrf] Proposed resolution - re: InitialValues for properties in WS-RMD

My two cents here,

While I agree with Bryan that the RMD document is supposed to reflect resource behavior, not inflict it, and its really really tempting to misuse it this way (in fact there are a few places in the current spec that imply required adherence to the values in RMD that should be lighted up), Initial Values is still important to advertise passively.

A resource should be able to advertise what the initial values of properties WILL BE when the resource is instantiated. Much like static values... but it can be changed over time by the resource, some other appropriate configuration operation, or even 'setResourceProperty'. Its important that a management system (client) be able to introspect for this kind of information without instantiating the resource. I believe management systems can handle the fact that the values may change over time (instantly or not). Managers can subscribe for changes. I believe this information is especially valuable for:
1. Infrequently changing, relatively static configuration information, like WSDM's Version, Description, ManageabilityCapabilities. WSDM requires these to be mutable, but certainly I'd like to be able to find this information out before instantiation. However, currently, without initial values there's no way to advertise this and be WSDM compliant.
2. Initial configuration information - preconfigured information SET during deployment because that how the resource is ALREADY configured, not to force it to behave that way. Capacity configuration... MaxThreadPool, MaxHeapSize are examples of this. But, performance managers may change the config over time. Even immediately.
3. Advertising what the initial value for a metric will be. Especially for Guages where its within a range, or starting metrics at 0. Its not a given that a metric starts at 0... if the metric is BytesInUse, Current Heap Size, the floor might be something above 0, but its not a guage. And yes, the value will be changed as soon as the resource starts working, but at least we know where it started.
4. Initial configured relationships that are all ready preconfigured to exist between the resource when instantiated and other services... like security services, domain managers, policy managers, whatever.
5. Its also very important for problem determination tools to be able to tell whats been reconfigured since this resource was instantiated. Often, inappropriate reconfiguation is a source of failures and performance faults. Once a manager determines which values have been changed then it can go find change tracking/audit logs to determine who did what. But there should be some reasonably effecient way to determine at a course level whats been changed (I'm not proposing we solve the change tracking/auditing problem).

Static values isn't enough because it doesn't allow the value to be changed, ever. The manager should be able to cache a Static value without checking on it for updates or subscribing for updtes. Not true of Initial Values.

Since you'd have only Static OR Initial values, we could have just 'InitialValue' which, when combined with Mutable=False and Modifiable=False, would give the same semantic effect of Static values (although not as intuitive for users).

Heather Kreger
STSM, Web Services Lead Architect for SWG Emerging Technologies
Author of "Java and JMX: Building Manageable Systems"
919-543-3211 (t/l 441) cell:919-496-9572

Inactive hide details for "Murray, Bryan P." <bryan.murray@hp.com>"Murray, Bryan P." <bryan.murray@hp.com>

          "Murray, Bryan P." <bryan.murray@hp.com>

          04/06/2006 07:34 PM


Daniel Jemiolo/Durham/IBM@IBMUS




RE: [wsrf] Proposed resolution - re: InitialValues for properties in WS-RMD


The purpose of RMD has always been to be an aid to applications wishing to interact with resources of the type specified in the RMD doc. The doc helps applications format messages, especially messages that modify the resource representation, with values that the resource is likely to accept.

The RMD descriptions were intended to be an advertisement of what the service already does. They are not meant to cause the service to check ranges or make sure that received values are listed in the RMD doc. There is no runtime enforcement implied by any data in an RMD doc. Just because you change data in an RMD doc does not imply that the service is going to behave any differently than it did before the modification.

The RMD doc does not contain nearly enough information to be a general purpose deployment specification. I don't understand why we would try to add some small details about deployment at this late date when we are not providing enough other information in this doc to perform deployment.

I recommend that details such as initial value be put in a document intended for deployment, and that we not include it in the RMD specification.


From: Daniel Jemiolo [mailto:danjemiolo@us.ibm.com]
Thursday, April 06, 2006 1:23 PM
Murray, Bryan P.
RE: [wsrf] Proposed resolution - re: InitialValues for properties in WS-RMD


You are correct that the initial values have no relevance to the client. However, I think that the use cases of this spec are not limited to introspection by clients. RMD can also be used by resource implementations to initialize WS-RP documents and enforce metadata for some or all properties (depending on how/where the properties are stored). It's a case of wanting to reuse an artifact we already have rather than inventing something that's implementation-specific.

For example, if you had an IDE that allowed you to design and generate WS-* interfaces and the many artifacts that are required to deploy them, you could use the RMD document (and other artifacts) to automate parts of the WS-* configuration at runtime. This type of automation allows programmers to focus on their custom resource/manageability logic and less on enforcement of basic WS-concepts and plumbing.

Also, Kirk is correct - the term "default" values is semantically inaccurate. I will stick to "initial values".


"Murray, Bryan P." <bryan.murray@hp.com>

04/06/2006 03:20 PM

Daniel Jemiolo/Durham/IBM@IBMUS, <wsrf@lists.oasis-open.org>
RE: [wsrf] Proposed resolution - re: InitialValues for properties in WS-RMD


I will add this issue as you wrote it to the issues list.

My comments on this issue:

Maybe I am getting confused by the terminology, but to me something called "initial" values in a metadata document would not be modified, added or removed over time. The initial values would be used to initialize properties when a resource was created. After creation, the initial values metadata has no further use. The current value of the resource properties are available from the resource, but the initialValue metadata has no meaning once the resource has been created. With this understanding of the semantics, this metadata has minimal value to a client interacting with a resource having these initial values, as an instant after creation the resource is running and having its values changed to reflect the state of the resource.

What am I missing? I don't understand how the initial values is useful to a client. The metadata is only an advertisement about the service, but why advertise something that has minimal value?


From: Daniel Jemiolo [mailto:danjemiolo@us.ibm.com]
Thursday, April 06, 2006 11:40 AM
[wsrf] Proposed resolution - re: InitialValues for properties in WS-RMD

On the TC call on 4/3/06, I proposed that we (re-)add the concept of initial values to the WS-RMD spec. This issue does not have a number yet. Below is a description of the issue and the proposed resolution.

When programming against the RMD spec, it is often necessary to seed a property with a set of initial values that are known at design time. A better term might be "default" values. The difference between these initial values and the concept of static values already in the spec is that initial values should be mutable, while static values are not.

The definition of initial values in an RMD document would be just like that of static values. For example, a property named MyProperty of type integer might have the following definition:

<wsrmd:Property path="myns:MyProperty" ... >

If the property is mutable, these initial values may be deleted or updated over the resource's lifetime. Again, this is different from static values because even on mutable properties, static instances are never deleted or updated.

The proposed resolution is to add the initial values concept to RMD by copying the section on static values (8.4), doing a search-and-replace (StaticValues -> InitialValues), and modifying the two introductory sentences to describe the role of initial values. The schema and infoset figures (in section 8 and appendices) will also need to be updated to reflect this option.

Dan Jemiolo
IBM Corporation
Research Triangle Park, NC

+++ I'm an engineer. I make slides that people can't read. Sometimes I eat donuts. +++

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]