[ogsa-wg] Glossary terms for Thursday's call

[Donal K. Fellows]

Treadwell, Jem wrote:
> I’ve uploaded version 4 of the glossary – this version includes the 
> changes for deployment and provisioning, as agreed at the last 
> discussion.  You’ll find it at http://tinyurl.com/2mo6r3.
> 
> For Thursday’s call I propose to discuss the following terms, as time 
> permits
> 
> o        State.  We had discussed this, and Jay has an action to improve 
> the current proposal.  So far I haven’t had a proposal from Jay, but we 
> need to put this one to bed, so we’ll have a brief discussion and if we 
> don’t have a better proposal at the meeting I’ll go with what we have.  
> There will be an opportunity to improve this or any term in the final 
> review.
> 
> o        Resource, Grid component, and Service.  We had definitions for 
> Resource and Service in both the OGSA and the EGA glossaries, so we need 
> to produce a consolidated definition.  Grid component comes from the EGA 
> glossary.  I’ve condensed it from the original, but (hopefully) haven’t 
> changed its meaning.
> 
> Rather than reproduce these terms here please take a look at the 
> working/discussion document, which you’ll find at 
> http://tinyurl.com/23a6zd.  These are the first four terms listed, and 
> the text you’ll find is a starting point for discussion. If you have 
> comments and you’re not going to make tomorrow’s meeting, please pass 
> them on to me; otherwise I’ll follow up after the meeting with revised 
> text for review.

On the Service definition: I'm concerned that the proposed definition
constrains a service to be part of a SOA (which to my mind is a
multi-component architecture where the interfaces between the components
are characterized by service interfaces, a term I define below) as
opposed to just saying that this is typically the case. Strictly, a
service is a reactive software entity that responds to requests sent by
clients (either through receiving messages or by listening for the start
of a conversation). A service is also defined by the fact that it
exposes a particular method of accessing it using a defined set of
messages and/or phrases in defined patterns; this is the Service
Interface, and clients of the service only need to know the service
interface in order to be able to use the service; the service interface
might make statements about the internal state model of the service (in
which case the service is a stateful service) but is not required to do so.

On the Resource definition: Are resources always stateful?

On the State definition: I think the defining feature of a state (as
opposed to a configuration) is that a state is capable of changing over
time, whereas an altered configuration can be said to lead to a
different entity/component. (There is a separate question of whether the
set of existing grid components in a grid is itself a state, or whether
it only becomes one if you have registries of the components, and hence
the component-set state of the grid is the state of the registries.)

On the Grid Component definition: I'd like to note that grid components
*must* have state, minimally to describe their situation in their
lifecycle, though the state does not inherently need to be exposed to
all users.


Trawling through the other definitions, do we need to define Abstraction
or DAG/Acyclic Digraph? I'd have thought that we could just use the
standard Computer Science definitions of these. Also, I came up with a
definition of a Grid (or perhaps it really defines a Grid Architecture?)
a few weeks ago that might be useful/relevant:

   A (potentially) inter-organizational dynamic stateful SOA.

Now, there is one problem with this definition in that it directly
conflicts with the definition of an Enterprise Grid (I'm really
suspicious of calling something a grid if it is entirely within a single
management domain) but the above bit of pithy buzzwordisms does
encompass a lot of what we're really about. For example, "inter-org"
means that we want to be both secure and standards-based, "dynamic
stateful" forces real consideration of management of the state (instead
of just sweeping it under the carpet, which seems to be the more usual
SOA approach), and I find it impossible to imagine a grid that does not
meet the definition of a SOA.

Donal.