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
- From: "Murray, Bryan P." <bryan.murray@hp.com>
- To: "Heather Kreger" <kreger@us.ibm.com>
- Date: Mon, 17 Apr 2006 07:03:10 -0700
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
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>
"Murray, Bryan P."
<bryan.murray@hp.com>
04/06/2006 07:34 PM |
|
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. +++
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]