Re: [ogsa-wg] [OGSA-D-WG] Definition of "data service"
Hi, 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. Data is 'manipulated' by resources (could not think of a more appropriate word to represent the concept that I am thinking so I put it in quotes). To clarify data can be stored on a resource (storage), distributed by a resource (network), organised by or as a resource (file), operated on by a resource (CPU). Note: the items in parenthesis in the earlier sentence are resources (or more precisely resource types). A service provides access to or a view of a resource (i.e. a *portal* into one or a set of resources) - this latter part is congruent with the WSRF approach. 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'. 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. Ravi Ravi Subramaniam -----Original Message----- From: guru prasad [mailto:guru_bn@yahoo.com] Sent: Monday, July 09, 2007 07:55 AM Pacific Standard Time To: Donal K. Fellows Cc: ogsa-d-wg@ogf.org; ogsa-wg; Allen Luniewski Subject: Re: [ogsa-wg] [OGSA-D-WG] Definition of "data service"
Thank you for your comments Allen.
In that case I vote for Dave Berry's definition:
"A service that provides interfaces to the capabilities and data of one or more data resources within a service-oriented architecture."
There is a separate question as to whether the data *is* a capability; I suspect it is, at least in some abstract sense. On the other hand, you might wish to distinguish the data as a special kind of capability that needs non-generic handling. So can you suggest the modification to the definition that will incorporate what you just above? "Donal K. Fellows" <donal.k.fellows@manchester.ac.uk> wrote: guru prasad wrote:
Thank you for your comments Allen.
In that case I vote for Dave Berry's definition:
"A service that provides interfaces to the capabilities and data of one or more data resources within a service-oriented architecture."
There is a separate question as to whether the data *is* a capability; I suspect it is, at least in some abstract sense. On the other hand, you might wish to distinguish the data as a special kind of capability that needs non-generic handling.
and the Data Resource is .....
A data resource is an abstraction of a file, so I'd imagine that you'd want to describe it as a resource that is an ordered collection of organized information. (The idea is that it doesn't have to be in a file, but it does have many file-like characteristics.) It's strongly beneficial to the overall OGSA if you can have data resources being a subclass of resources (by referencing the OGSA glossary). Donal. --------------------------------- Park yourself in front of a world of choices in alternative vehicles. Visit the Yahoo! Auto Green Center.
Did we decide on a final definition? "Subramaniam, Ravi" <ravi.subramaniam@intel.com> wrote: Hi, 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. Data is 'manipulated' by resources (could not think of a more appropriate word to represent the concept that I am thinking so I put it in quotes). To clarify data can be stored on a resource (storage), distributed by a resource (network), organised by or as a resource (file), operated on by a resource (CPU). Note: the items in parenthesis in the earlier sentence are resources (or more precisely resource types). A service provides access to or a view of a resource (i.e. a *portal* into one or a set of resources) - this latter part is congruent with the WSRF approach. 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'. 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. Ravi Ravi Subramaniam -----Original Message----- From: guru prasad [mailto:guru_bn@yahoo.com] Sent: Monday, July 09, 2007 07:55 AM Pacific Standard Time To: Donal K. Fellows Cc: ogsa-d-wg@ogf.org; ogsa-wg; Allen Luniewski Subject: Re: [ogsa-wg] [OGSA-D-WG] Definition of "data service"
Thank you for your comments Allen.
In that case I vote for Dave Berry's definition:
"A service that provides interfaces to the capabilities and data of one or more data resources within a service-oriented architecture."
There is a separate question as to whether the data *is* a capability; I suspect it is, at least in some abstract sense. On the other hand, you might wish to distinguish the data as a special kind of capability that needs non-generic handling. So can you suggest the modification to the definition that will incorporate what you just above? "Donal K. Fellows" wrote: guru prasad wrote:
Thank you for your comments Allen.
In that case I vote for Dave Berry's definition:
"A service that provides interfaces to the capabilities and data of one or more data resources within a service-oriented architecture."
There is a separate question as to whether the data *is* a capability; I suspect it is, at least in some abstract sense. On the other hand, you might wish to distinguish the data as a special kind of capability that needs non-generic handling.
and the Data Resource is .....
A data resource is an abstraction of a file, so I'd imagine that you'd want to describe it as a resource that is an ordered collection of organized information. (The idea is that it doesn't have to be in a file, but it does have many file-like characteristics.) It's strongly beneficial to the overall OGSA if you can have data resources being a subclass of resources (by referencing the OGSA glossary). Donal. --------------------------------- Park yourself in front of a world of choices in alternative vehicles. Visit the Yahoo! Auto Green Center. --------------------------------- Pinpoint customers who are looking for what you sell.
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.
Crudely put, an "XYZ service" is a service that manipulates 1 or more "XYZ resources".
Hmmm. I'd say that an "XYZ service" provides one or more "XZY capabilities", and those capabilities might manipulate one or more resources (including other services) from diverse domains (i.e., including other than "XYZ"). I could agree with the statement that, in an SOA, every resource will have at least one service whose primary (and perhaps sole) capability is to provide access to that resource. Dave Berry's latest posting of the current defs comes pretty close to matching what I mean/understand by the above. Cheers, BobN
Natale, Bob wrote:
Crudely put, an "XYZ service" is a service that manipulates 1 or more "XYZ resources".
Hmmm. I'd say that an "XYZ service" provides one or more "XZY capabilities", and those capabilities might manipulate one or more resources (including other services) from diverse domains (i.e., including other than "XYZ").
I factor the same things slightly differently. :-) I think that the capabilities (or at least most of them) are aspects of the resource and what the service does is expose them. But that's really just cutting the software into pieces at a slightly different point. I also feel that when you've got the sort of situation you describe above, the service is both an "XYZ service" and an "ABC service", but that's because I feel that the service definitions are really just interfaces (to use Java terminology; in other languages I'd use multiple inheritance to describe what's going on) irrespective of how they're implemented.
I could agree with the statement that, in an SOA, every resource will have at least one service whose primary (and perhaps sole) capability is to provide access to that resource.
That seems fair to me too. Donal.
So how should we go about defining data service and a data resource. "Donal K. Fellows" <donal.k.fellows@manchester.ac.uk> wrote: Natale, Bob wrote:
Crudely put, an "XYZ service" is a service that manipulates 1 or more "XYZ resources".
Hmmm. I'd say that an "XYZ service" provides one or more "XZY capabilities", and those capabilities might manipulate one or more resources (including other services) from diverse domains (i.e., including other than "XYZ").
I factor the same things slightly differently. :-) I think that the capabilities (or at least most of them) are aspects of the resource and what the service does is expose them. But that's really just cutting the software into pieces at a slightly different point. I also feel that when you've got the sort of situation you describe above, the service is both an "XYZ service" and an "ABC service", but that's because I feel that the service definitions are really just interfaces (to use Java terminology; in other languages I'd use multiple inheritance to describe what's going on) irrespective of how they're implemented.
I could agree with the statement that, in an SOA, every resource will have at least one service whose primary (and perhaps sole) capability is to provide access to that resource.
That seems fair to me too. Donal. -- ogsa-wg mailing list ogsa-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-wg --------------------------------- Pinpoint customers who are looking for what you sell.
participants (4)
-
Donal K. Fellows -
guru prasad -
Natale, Bob -
Subramaniam, Ravi