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.