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

[Daniel Jemiolo <danjemiolo@us.ibm.com>]

I think that it's tempting to use it
this way because it's an efficient solution to a very real problem: how
to configure and deploy a WS-RF implementation without duplicating a lot
of info in proprietary descriptor files.

On the specific issue of initial values:
users keep asking me for this, and I keep apologizing to them. How have
other WS-RF implementers handled this use case? What do your users do for
initialization of the WS-RP model?

On the general issue of processing an
RMD at runtime: in my experience, the more config files that are added
to an environment, the more difficult it becomes to learn, modify, and
test your code. We should reuse all of our XML files whenever it is reasonable
to do so, because web services programmers don't need any more tedious
mapping files than they already have!

Unlike XSD, RMD is related to a specific
deployment of a resource type; for this reason, it seems natural to use
the document to help configure or police instances of the resource type.
And while WSDL and XSD are not instance documents, I still think programmers
are/will be using them to automate tasks and validate services. Redefining
the info in web services artifacts in the interest of clean separation
will increase the learning curve of programmers, many of whom are already
a bit overwhelmed by basic SOAP and WSDL.

Bryan is right - RMD + WSDL + XSD !=
a complete deployment descriptor - but it's about 80%. Personally, I'm
always looking for ways to make our custom descriptors smaller by reusing
the concepts found in standards-based descriptors; when forced to develop
an arcane XML schema, it's best to offload the work as much as possible.
:)

Dan

Heather Kreger/Raleigh/IBM

04/07/2006 12:21 PM

To	"Murray, Bryan P." <bryan.murray@hp.com>
cc	Daniel Jemiolo/Durham/IBM@IBMUS, wsrf@lists.oasis-open.org
Subject	RE: [wsrf] Proposed resolution - re: InitialValues for properties in WS-RMDLink

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"
kreger@us.ibm.com
919-543-3211 (t/l 441)  cell:919-496-9572

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

04/06/2006 07:34 PM

To	Daniel Jemiolo/Durham/IBM@IBMUS
cc	<wsrf@lists.oasis-open.org>
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:danjemiolo@us.ibm.com]
Sent: Thursday, April 06, 2006 1:23 PM
To: Murray, Bryan P.
Cc: wsrf@lists.oasis-open.org
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." <bryan.murray@hp.com>

04/06/2006 03:20 PM

To	Daniel Jemiolo/Durham/IBM@IBMUS, <wsrf@lists.oasis-open.org>
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:danjemiolo@us.ibm.com]
Sent: Thursday, April 06, 2006 11:40 AM
To: wsrf@lists.oasis-open.org
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. +++