[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsrf] Proposed resolution - re: WSRF 175 - InitialValues forproperties in WS-RMD
Thanks. Ballot posted:
http://www.oasis-open.org/apps/org/workgroup/wsrf/ballot.php?id=1012
Regards,
Ian Robinson
STSM, WebSphere Messaging and Transactions Architect
IBM Hursley Lab, UK
ian_robinson@uk.ibm.com
"Murray, Bryan
P."
<bryan.murray@hp. To
com> Ian Robinson/UK/IBM@IBMGB, "Heather
Kreger" <kreger@us.ibm.com>,
28/04/2006 18:45 "Daniel Jemiolo"
<danjemiolo@us.ibm.com>
cc
<wsrf@lists.oasis-open.org>
Subject
RE: [wsrf] Proposed resolution -
re: WSRF 175 - InitialValues for
properties in WS-RMD
Ian,
Dan has already posted a proposal (April 6) for initialValues which has
had some support from the TC. I happen to think there is little value in
having initial values in metadata, but the rest of the TC may not agree.
I suggest you ballot Dan's proposal as written.
Bryan
-----Original Message-----
From: Ian Robinson [mailto:ian_robinson@uk.ibm.com]
Sent: Monday, April 24, 2006 2:12 AM
To: Heather Kreger; Murray, Bryan P.; Daniel Jemiolo
Cc: wsrf@lists.oasis-open.org
Subject: Fw: [wsrf] Proposed resolution - re: WSRF 175 - InitialValues
for properties 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]