Oxana, I think you may have mis-interpreted what I meant. I think different interfaces for different functions is important. I was referring to a single interface for discovering resource properties|meta data|attributes. So that one can gather resource properties (perhaps including what interfaces the resource implements) in a uniform way - much like reflection interfaces in Java. Where and how the information to respond to resource property queries is irrelevant to me ... is it generated on the fly, is it variables in memory, is it stored in some database, I don't care. I just want to be able to ask for it. Similarly, if someone wants to build an "information service" that logically keeps the resource properties of many resources and allows me to query that, that is great too. How they get that information is not my concern. What that "information service" interface is I do care about. It has been debated quite a bit: many arguing against WS and XML representation as too slow and complex, instead arguing for a straight RDBMS interface with well-defined schema; others arguing for the full flexibility of extensible XML schema's. While I think the information service interface is important, I think it will be difficult to reach consensus as infrastructures tend to have their own well developed techniques. I think therefore that we should keep it out of scope for our discussions on the execution service. A
-----Original Message----- From: pgi-wg-bounces@ogf.org [mailto:pgi-wg-bounces@ogf.org] On Behalf Of Oxana Smirnova Sent: Tuesday, July 14, 2009 6:43 PM To: pgi-wg@ogf.org Cc: jsdl-wg@ogf.org Subject: Re: [Pgi-wg] Next teleconference: tomorrow, wednesday july 15th
Hi all,
FWIW, I have mixed feelings on this issue. 4 years ago I thought it would be just great to have exactly the same interface and end-point for job submission/management, for information query, and for file management. We even do have the same interface for job and file management: job is largely characterized by a set of files, after all. And information persistency may well be realized as a set of files, too - why not. But then I killed a job by accident, being sure I deleted a file. So now I think a clear separation is a good think to do.
Cheers, Oxana
Hi Andrew,
With the diverse types of services that we deal with in our infrastructure, I can't imagine a situation where they have all implemented an interface using the same technology. This is due to many factors including but not limited to: legacy, time scales, priories, ideologies, trends, fads etc. However, we have to somehow link all these services together, which is why I believe that a parallel system is the most flexible option. If an agreed information interface emerges, the exiting interfaces could be extended to provide this but the only advantage I see is aesthetics rather than function.
Having said that, one of the advantages that I would see by having this added to BES is that developers of the interface would also have to worry about providing the information, which would save us the trouble :) We could then create a simple adaptor to extract the information and pull it into the parallel information system. In order to achieve this, a simple interface such as an XML document would suffice. Examples of such documents can be found on the GLUE 2.0 wiki page.
http://forge.gridforum.org/sf/wiki/do/viewPage/projects.glue- wg/wiki/GLUE2XMLSchema
Laurence
Andrew Grimshaw wrote:
Laurence,
I agree completely. During the BES discussion we came to an impasse over this: some arguing that that we could use WS-RF resource properties ... and then have a single mechanism for all types of resources. Others, including but not limited to Microsoft, would have nothing to do with WS-RF. In
end to get consensus the WG decided on a separate function - very ugly. We in Genesis II support both the WS-RF mechanism and the OGSA-BES mechanism. The same thing by the way happened over notification, except in the end
2009-07-15 00:10, Laurence Field пишет: the the
WG basically punted.
I personally think that the BES endpoint should provide a mechanism to get the information, but that the spec should be mute on how that information is aggregated or used.
A
_______________________________________________ Pgi-wg mailing list Pgi-wg@ogf.org http://www.ogf.org/mailman/listinfo/pgi-wg