[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Fw: [wsrf] Proposed resolution - re: WSRF 175 - InitialValues forproperties in WS-RMD
Bryan, Heather, Dan.
I took an AI at the last WSRF telecon to post an electronic ballot to
resolve this issue once we have a concrete proposal to vote upon. I don't
think we have that yet.
Could I ask Bryan, Heather and Dan to collaborate on a joint proposal - to
be mailed to the TC - for further discussion. If necessary, please could
you produce alternative proposals so the TC can choose between them?
The next scheduled TC telecon is May 8th. We will discuss this issue
further on that call if we have resolved it electronically beforehand.
Regards,
Ian Robinson
STSM, WebSphere Messaging and Transactions Architect
IBM Hursley Lab, UK
ian_robinson@uk.ibm.com
----- Forwarded by Ian Robinson/UK/IBM on 24/04/2006 10:01 -----
"Murray, Bryan
P."
<bryan.murray@hp. To
com> "Heather Kreger"
<kreger@us.ibm.com>
17/04/2006 15:03 cc
"Daniel Jemiolo"
<danjemiolo@us.ibm.com>,
<wsrf@lists.oasis-open.org>
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.
Bryan
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"
kreger@us.ibm.com
919-543-3211 (t/l 441) cell:919-496-9572
(Embedded image moved to file: pic00574.gif)Inactive hide details for
"Murray, Bryan P." <bryan.murray@hp.com>"Murray, Bryan P."
<bryan.murray@hp.com>
"Murray,
Bryan P."
<bryan.murra
y@hp.com> (Embedded image moved to file:
pic16861.gif)
To
04/06/2006 (Embedded image moved to
07:34 PM file: pic30511.gif)
Daniel
Jemiolo/Durham/IBM@IBMUS
(Embedded image moved to file:
pic24963.gif)
cc
(Embedded image moved to
file: pic10755.gif)
<wsrf@lists.oasis-open.org>
(Embedded image moved to file:
pic13992.gif)
Subject
(Embedded image moved to
file: pic04049.gif)
RE: [wsrf] Proposed
resolution - re:
InitialValues for
properties in WS-RMD
(Embedded image moved to file:
pic23974.gif)
(Embedded image moved to
file: pic10057.gif)
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>
To
04/06/2006 03:20 PM Daniel Jemiolo/Durham/IBM@IBMUS,
<wsrf@lists.oasis-open.org>
cc
(Embedded image moved to file:
pic30250.gif)
Subject
RE: [wsrf] Proposed resolution - re:
InitialValues for properties in WS-RMD
(Embedded image moved to file: pic17676.gif)
(Em
bed
ded
ima
ge
mov
ed
to
fil
e:
pic
215
85.
gif
)
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]
