[Pgi-wg] Next teleconference: tomorrow, wednesday july 15th

[Andrew Grimshaw]

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 at ogf.org [mailto:pgi-wg-bounces at ogf.org] On Behalf Of
> Oxana Smirnova
> Sent: Tuesday, July 14, 2009 6:43 PM
> To: pgi-wg at ogf.org
> Cc: jsdl-wg at 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
> 
> 2009-07-15 00:10, Laurence Field пишет:
> > 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
> the
> >> 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
> 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 at ogf.org
> > http://www.ogf.org/mailman/listinfo/pgi-wg