[ogsa-wg] [OGSA-D-WG] Definition of "data service"

[Donal K. Fellows]

Subramaniam, Ravi wrote:
> I would think that data is neither a resource, capability nor
> service. It is a unique entity/concept/essence. Thinking of data as a
> capability, resource or service can be problematic.

I don't think I agree with that. But I agree that data isn't a file (or
a database query result, or a stream, etc.) since that's a concept at a
different level. A file resource is a fairly low-level concept (not as
low-level as a particular disk block though) whereas a data resource is
much higher-level/abstract. Compare with the differences between
processes and batch jobs, or between executables and applications.

Because they're at a different level of abstraction, the applicable
manipulations are different too. Thus, you could cause an additional
replica of a data resource to come into existence with some quality
parameters (e.g. frequency of synchronization with the master,
availability, confidentiality) and the service managing this would
translate it into the lower-level operations of things like doing file
copies between systems, computing checksums, etc.

Of course, there's a separate question as to whether it is possible at
all for abstract application resources to be coupled to abstract data
resources in an automatic way (it'd suck if you had to always do the
grounding to low-level resources by hand) or whether applications really
have to care anyway whether they are dealing with files, query results,
streams, etc. I don't have the answer to that at all.

> By this thought process, a 'data service' or 'data resource' is a
> misnomer. A service is a portal into or the external manifestation of
> a resource which in turn 'operates' (in a wide sense) on data. Part
> of the confusion appears on where in this 'concept chain' we are. So
> if we are at the resource level we introduce terms like 'data
> resource' or at the service level 'data service'.

Crudely put, an "XYZ service" is a service that manipulates 1 or more
"XYZ resources". In other words, the abstraction levels should follow
tightly. The interesting part is to what degree a particular resource
type is abstract or concrete, and the tricky bit is that there are a
great many different important abstractions in this area; we have at
least some idea that there are more (understood) levels here than with
execution management. Well, at least before you start to consider the
services themselves to be hosted in executing applications...

> In the example on files in the earlier part of the thread: The file
> is a resource used to organise data. The operations performed on a
> file is the service that is the external manifestations of the
> resource (i.e. the file)
> 
> By this definition, we manage resources and not data. Actually data
> management is only achieved by managing the resources that 'operate'
> on data.

I suspect you're tangled here by assuming that the operations on files
and on data are the same. I'm not at all convinced that that's going to
prove true.

Donal.