Update to OGSA 1.5

All, While explaining OGSA to some very technical folks last week it came up that the 1.0 document does not describe an "object model" so to speak. in other words, what are the "atoms", what is the minimum we assume, etc. For example, we assume: that resources have interfaces, that they process messages, that their behavior may be history dependent, that they are referenced with EPR's, that the atoms may have a unique AbstractName that they may be both servers and clients of other services We also seem to assume that there is some mechanism to get/set some form of metadata (resource properties) We seem to want to be able to find out what interfaces are supported (it is in base profile .. And I think should be in any profile - opinion) We seem to assume a factory pattern - though it is not explicit, and not part of lifetimes I am sure there are others. Comments? Should I write something up along this line for inclusion in the 1.5 document? Andrew

Andrew, Yes we should include our object model in the V1.5 document. If you could do a straw-man along these lines, I think we would have a starting point. A lot of the interesting questions come up around "What is the minimum level of support provided by ALL atoms?" E.g. "Must every blade in a server have a globally unique name?" etc. With a straw-man we can start in on these questions. Go for it! On 7 Sep 2005, at 23:42, Andrew Grimshaw wrote:
All, While explaining OGSA to some very technical folks last week it came up that the 1.0 document does not describe an “object model” so to speak… in other words, what are the “atoms”, what is the minimum we assume, etc. For example, we assume: that resources have interfaces, that they process messages, that their behavior may be history dependent, that they are referenced with EPR’s, that the atoms may have a unique AbstractName that they may be both servers and clients of other services We also seem to assume that there is some mechanism to get/set some form of metadata (resource properties) We seem to want to be able to find out what interfaces are supported (it is in base profile …. And I think should be in any profile – opinion) We seem to assume a factory pattern – though it is not explicit, and not part of lifetimes I am sure there are others. Comments? Should I write something up along this line for inclusion in the 1.5 document? Andrew
-- Take care: Dr. David Snelling < David . Snelling . UK . Fujitsu . com > Fujitsu Laboratories of Europe Hayes Park Central Hayes End Road Hayes, Middlesex UB4 8FE +44-208-606-4649 (Office) +44-208-606-4539 (Fax) +44-7768-807526 (Mobile)

Andrew, Dave, I think this is a good idea. It sounds to me that this could end up being a refinement or addition to section 3.2 (OGSA Framework) and could help solve one issue I had with trying to tie that section better with the rest of the document. But I'd like to see a draft first before deciding where it might go. My only concern about this at this point is, of course, the OGSA 1.5 document schedule. So when can we have an initial draft? Andreas David Snelling wrote:
Andrew,
Yes we should include our object model in the V1.5 document. If you could do a straw-man along these lines, I think we would have a starting point. A lot of the interesting questions come up around "What is the minimum level of support provided by ALL atoms?" E.g. "Must every blade in a server have a globally unique name?" etc. With a straw-man we can start in on these questions.
Go for it!
On 7 Sep 2005, at 23:42, Andrew Grimshaw wrote:
All, While explaining OGSA to some very technical folks last week it came up that the 1.0 document does not describe an “object model” so to speak… in other words, what are the “atoms”, what is the minimum we assume, etc.
For example, we assume: that resources have interfaces, that they process messages, that their behavior may be history dependent, that they are referenced with EPR’s, that the atoms may have a unique AbstractName that they may be both servers and clients of other services
We also seem to assume that there is some mechanism to get/set some form of metadata (resource properties) We seem to want to be able to find out what interfaces are supported (it is in base profile …. And I think should be in any profile – opinion) We seem to assume a factory pattern – though it is not explicit, and not part of lifetimes
I am sure there are others.
Comments? Should I write something up along this line for inclusion in the 1.5 document?
Andrew
-- Andreas Savva Fujitsu Laboratories Ltd
participants (3)
-
Andreas Savva
-
Andrew Grimshaw
-
David Snelling