I think we need to modify Jem's definition slightly.  A component has to be manageable before it can be configured.  Thus it exists before it is configured :o)  This is the goal of the Ref Model life cycle where we have the notion of -
 
Extant - the component is manageable, i.e. it can be configured
Configured - the component has been configured sufficently to allow it to be started
Active - the component is serving the purpose for which it was intended, i.e. responding to requests, doing a calculation etc.
 
I find a useful way of thinking about this is that state is really reflected by attributes that cannot typically be set externally.  Whilst configuration parameters may be.  Clearly state may be changed by applying verb externally to a managed component, such as start or stop, but this is not the same.
 
Paul
 
 

From: Michael Behrens [mailto:michael.behrens@r2ad.com]
Sent: Tuesday, May 01, 2007 1:54 AM
To: Treadwell, Jem
Cc: Donal K. Fellows; Strong, Paul; ogsa-wg; rm-wg@ogf.org
Subject: Re: [ogsa-wg] Glossary terms for Thursday's call (state definition)

Most insightful.  Would the available attributes vary directly with the lifecycle state of the resource?  Or would there  simply be a  way to categorize attributes and might this affect future resource specifications?

Treadwell, Jem wrote: 
Paul/Donal/All,
Thanks for the comments, and sorry to be slow in responding - I'm not
able to work on this quite as much these days :(
Now that I've taken time to read Paul's comment and Donal's response a
little more carefully, I think Donal makes an excellent point - I would
expect that an entity would exist only after it has been configured. Its
configuration attributes would *contribute* to its state, but would not
be a part of it unless the details are associated with (*maybe*
contained within) the entity, are visible to some external observer
(possibly a debugger), and might change.
I'm happy to add a little more explanation in the definition if anyone
thinks it would be helpful. For example, at the end of Para 1 I could
add: 
  Configuration attributes typically affect an entity's initial state,
  but would not be considered to be part of the state unless they
  can be changed during the entity's lifetime, and thus affect its
  behavior.
Other suggestions welcome!
- Jem


  
-----Original Message-----
From: ogsa-wg-bounces@ogf.org [mailto:ogsa-wg-bounces@ogf.org] On
    
Behalf
  
Of Donal K. Fellows
Sent: Friday, April 13, 2007 4:38 AM
To: Strong, Paul
Cc: ogsa-wg; rm-wg@ogf.org
Subject: Re: [ogsa-wg] Glossary terms for Thursday's call

Strong, Paul wrote:
    
Within the RM-WG we have split attributes into configuration
      
attributes
  
and state attributes.  Configuration attributes to some degree
      
define
  
behavior, defining or constraining the set of allowed states, as
      
well as
  
the possible values of state attributes and allowed transitions
      
between
  
states.  Clearly configuration attributes are "interesting", and
      
thus
  
according to the definition below they would be considered part of
      
the
  
state.  I'm not sure that this is the case.
      
An argument that I made during the call (and which it might have been
nice to have delved into in more detail if we'd had a few days instead
of 15 minutes!) is that an altered configuration creates a different
resource/stateful entity[*], but an altered state is something that is
expected during the normal working lifetime of a resource and does not
change the fundamental nature of that resource. That is, a change of
config is qualitatively different to a change of state, even if both
    
are
  
(represented as) attributes.

In general, there are loads of definitions of state (I've got a
background which leads me to regard it as really a partial function
whose domain is the cartesian product of time and names for "stateful"
things) but they're just different ways of looking at the same thing.
The good aspects of the current definition are that it is observable
    
and
  
changes in it are events, things which are not implicit in the
    
standard
  
CS definitions of the term and yet are very useful for grids.

Donal.
[* As you can tell, I've lost track of what kind of thing contains
    
such
  
    attributes. I know *I* think of them as resources, but that
    
doesn't
  
    make me right. :-) ]
--
  ogsa-wg mailing list
  ogsa-wg@ogf.org
  http://www.ogf.org/mailman/listinfo/ogsa-wg
    
--
  ogsa-wg mailing list
  ogsa-wg@ogf.org
  http://www.ogf.org/mailman/listinfo/ogsa-wg



  

-- 
Michael Behrens
R2AD, LLC
(571) 594-3008 (cell)
(703) 714-0442 (land)