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.

 

Bryan

From: Heather Kreger [mailto:] 

Sent: Friday, April 07, 2006 9:21 AM
To: Murray, Bryan 
P.
Cc: Daniel Jemiolo; 
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

' 
src="gif00023.gif" width=16>"Murray, Bryan P." 
<>

  
  

    
      
        
          
            "Murray, Bryan P." 
              <> 
              
04/06/2006 07:34 PM

    
      
        
        

          

            
To

          
Daniel Jemiolo/Durham/IBM@IBMUS

        

          

            
cc

          
<>

        

          

            
Subject

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

      
        
        

          
          

Dan,

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.

Bryan

From: Daniel Jemiolo [mailto:] 

Sent: Thursday, 
April 06, 2006 1:23 PM
To: Murray, Bryan P.
Cc: 
Subject: RE: [wsrf] Proposed 
resolution - re: InitialValues for properties in WS-RMD

Bryan, 

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

Dan

  
  

    "Murray, Bryan P." 
      <> 
      
04/06/2006 03:20 PM 

    
      
        
        

          
            
To

          Daniel Jemiolo/Durham/IBM@IBMUS, 
            <> 

        

          
            
cc

          

        

          
            
Subject

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

      
        
        

          
          

Dan, 

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? 

Bryan 

From: Daniel Jemiolo [mailto:] 

Sent: Thursday, 
April 06, 2006 11:40 AM
To: 
Subject: [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" ... > 
<wsrmd:InitialValues> 

<myns:MyProperty>123</myns:MyProperty> 

<myns:MyProperty>456</myns:MyProperty> 

</wsrmd:InitialValues> 

</wsrmd:Property> 

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. +++