Re: [ogsa-wg] OGSA Information Services
Hi all, Discussion material for Information Services by Laurence Field and Felix Ehm is now on the GridForge. https://forge.gridforum.org/sf/go/doc14692
This document covers the problem description, experience in GIN, overview of existing systems, generalized system and suggested areas for standardization.
Please have a look before the call today. Felix Ehm will lead the discussion. Thanks, ---- Hiro Kishimoto
Hi all,
Please have a look before the call today.
Information Services discussion is not Today but August 2nd. Sorry, my bad... ---- Hiro Kishimoto -------- Original Message -------- Subject: Re:OGSA Information Services From: Hiro Kishimoto <hiro.kishimoto@jp.fujitsu.com> To: ogsa-wg <ogsa-wg@ogf.org> Cc: felix.ehm@cern.ch Date: 2007/07/26 12:55
Hi all,
Discussion material for Information Services by Laurence Field and Felix Ehm is now on the GridForge.
https://forge.gridforum.org/sf/go/doc14692
This document covers the problem description, experience in GIN, overview of existing systems, generalized system and suggested areas for standardization.
Please have a look before the call today.
Felix Ehm will lead the discussion.
Thanks, ---- Hiro Kishimoto
Hi all, Per Felix's request, I've upload revised draft onto the GridForge. https://forge.gridforum.org/sf/go/doc14692 We will discuss it at Thursday's call. Thanks, ---- Hiro Kishimoto -------- Original Message -------- Subject: Re:[ogsa-wg] OGSA Information Services From: Hiro Kishimoto <hiro.kishimoto@jp.fujitsu.com> To: ogsa-wg <ogsa-wg@ogf.org> Cc: felix.ehm@cern.ch Date: 2007/07/26 12:55
Hi all,
Discussion material for Information Services by Laurence Field and Felix Ehm is now on the GridForge.
https://forge.gridforum.org/sf/go/doc14692
This document covers the problem description, experience in GIN, overview of existing systems, generalized system and suggested areas for standardization.
Please have a look before the call today.
Felix Ehm will lead the discussion.
Thanks, ---- Hiro Kishimoto
-- ogsa-wg mailing list ogsa-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-wg
Hiro Kishimoto wrote:
Per Felix's request, I've upload revised draft onto the GridForge. https://forge.gridforum.org/sf/go/doc14692 We will discuss it at Thursday's call.
Just so I remember, here are the things that occur to me on reading the summary and going over the rest of the document quickly: Query Interface standardization is a good thing, but there will need to be a standard basic set of information that can be counted on to be there for this to be really useful (not just a common model, but a realistic possibility of making a query to an arbitrary instance and getting a result). Registry standardization is again a good thing, but again there needs to be some kind of profile to describe what endpoints go in and how they are looked up (by name, by property?) Information Provider standardization is likely to be very hard, and probably coupled to the idea of a "standard middleware platform". Since a registry is really about the query interface anyway (I'm much less certain about standardization of mechanisms for registry updating) I'm left wondering if we can reuse concepts between the first two items and avoid the third at least for now. Donal.
I have some corrections and questions. I have highlighted those in the attached document. Can someone please help me understand. Thank you, Guru Hiro Kishimoto <hiro.kishimoto@jp.fujitsu.com> wrote: Hi all, Per Felix's request, I've upload revised draft onto the GridForge. https://forge.gridforum.org/sf/go/doc14692 We will discuss it at Thursday's call. Thanks, ---- Hiro Kishimoto -------- Original Message -------- Subject: Re:[ogsa-wg] OGSA Information Services From: Hiro Kishimoto To: ogsa-wg Cc: felix.ehm@cern.ch Date: 2007/07/26 12:55
Hi all,
Discussion material for Information Services by Laurence Field and Felix Ehm is now on the GridForge.
https://forge.gridforum.org/sf/go/doc14692
This document covers the problem description, experience in GIN, overview of existing systems, generalized system and suggested areas for standardization.
Please have a look before the call today.
Felix Ehm will lead the discussion.
Thanks, ---- Hiro Kishimoto
-- ogsa-wg mailing list ogsa-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-wg
-- ogsa-wg mailing list ogsa-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-wg --------------------------------- Be a better Heartthrob. Get better relationship answers from someone who knows. Yahoo! Answers - Check it out.
guru prasad wrote:
I have some corrections and questions. I have highlighted those in the attached document. Can someone please help me understand.
Going through your comments (extracted from the document)... Comment #1:
What information. Information about the resource or the fact that the information provider is on the same host. Too many “This”
Agreed, that paragraph is confusing. (I suspect, but do not know, that the information you highlighted was the information produced by the "resource-level provider" but that's just my reading...) Comment #2:
Does this mean even the resource level information provider is not required??? Or are we saying the service that provides the capability to query is not required????
If the answer to the first question is yes then, I would say it may still be required. Instead of site level information registry getting overloaded with queries about the resources it has, if one has a visibility of a particular resource he could just query that resource.
I'd say that while the resource-level provider is not a priori required, it has to be there conceptually. Sites are free to use other mechanisms to actually do the information provision though. On the other hand, I really disagree with your second paragraph there. One key gain from having a site-level information system is that this is a prime location for carrying out queries for resource discovery and scheduling. If you require everything to ask the end resources directly, then anything that actually needs to look at many resources will end up being dog slow because of the amount of network traffic needed to take any kind of decision (trust me, I've tried this!) A site-level info system is a major optimization, especially if you do not require all information within it to be entirely timely. Comment #3:
Should it say that the developer of the resources could be the information provider ???? This is not clear from the sentence.
That sentence is wildly unclear, but I suspect it's talking about some kind of API for basic info providers to make it easier to write the actual information sources. However, I wonder whether this falls more within the remit of SAGA - do they do server-side APIs? - since OGSA (and related groups) has tended to focus on the wire view of interop. Donal.
Hi, in case you are referring to version 2 of the document:
Agreed, that paragraph is confusing. (I suspect, but do not know, that the information you highlighted was the information produced by the "resource-level provider" but that's just my reading...)
Yes, this paragraph is intended to explain the purpose of a resource level information provider (for performance reasons it may also have a build-in caching). I've changed this part in version 3. Please have a look there.
Does this mean even the resource level information provider is not required??? Or are we saying the service that provides the capability to query is not required????
The passage wants to express that if a site information system is available and provides a common query interface, the resource level information components don't necessarily need to implement the same interface. In my opinion their purpose should then be to populate information to the site level and not serving external requests. Concerning the question if the resource level info providers are essential INSTEAD of a site-level one I agree with Donal. In the past it turned out that caching represents latency, but also protects resources from being bombed by requests. Felix On Tue, 7 Aug 2007, Donal K. Fellows wrote:
guru prasad wrote:
I have some corrections and questions. I have highlighted those in the attached document. Can someone please help me understand.
Going through your comments (extracted from the document)...
Comment #1:
What information. Information about the resource or the fact that the information provider is on the same host. Too many "This"
Agreed, that paragraph is confusing. (I suspect, but do not know, that the information you highlighted was the information produced by the "resource-level provider" but that's just my reading...)
Comment #2:
Does this mean even the resource level information provider is not required??? Or are we saying the service that provides the capability to query is not required????
If the answer to the first question is yes then, I would say it may still be required. Instead of site level information registry getting overloaded with queries about the resources it has, if one has a visibility of a particular resource he could just query that resource.
I'd say that while the resource-level provider is not a priori required, it has to be there conceptually. Sites are free to use other mechanisms to actually do the information provision though.
On the other hand, I really disagree with your second paragraph there. One key gain from having a site-level information system is that this is a prime location for carrying out queries for resource discovery and scheduling. If you require everything to ask the end resources directly, then anything that actually needs to look at many resources will end up being dog slow because of the amount of network traffic needed to take any kind of decision (trust me, I've tried this!) A site-level info system is a major optimization, especially if you do not require all information within it to be entirely timely.
Comment #3:
Should it say that the developer of the resources could be the information provider ???? This is not clear from the sentence.
That sentence is wildly unclear, but I suspect it's talking about some kind of API for basic info providers to make it easier to write the actual information sources. However, I wonder whether this falls more within the remit of SAGA - do they do server-side APIs? - since OGSA (and related groups) has tended to focus on the wire view of interop.
Donal. -- ogsa-wg mailing list ogsa-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-wg
Felix, Donal, Guru,
Agreed, that paragraph is confusing. (I suspect, but do not know, that the information you highlighted was the information produced by the "resource-level provider" but that's just my reading...)
Yes, this paragraph is intended to explain the purpose of a resource level information provider (for performance reasons it may also have a build-in caching). I've changed this part in version 3. Please have a look there.
Comment #2:
Does this mean even the resource level information provider is not required??? Or are we saying the service that provides the capability to query is not required????
If the answer to the first question is yes then, I would say it may still be required. Instead of site level information registry getting overloaded with queries about the resources it has, if one has a visibility of a particular resource he could just query that resource.
I'd say that while the resource-level provider is not a priori required, it has to be there conceptually. Sites are free to use other mechanisms to actually do the information provision though.
On the other hand, I really disagree with your second paragraph there. One key gain from having a site-level information system is that this is a prime location for carrying out queries for resource discovery and scheduling. If you require everything to ask the end resources directly, then anything that actually needs to look at many resources will end up being dog slow because of the amount of network traffic needed to take any kind of decision (trust me, I've tried this!) A site-level info system is a major optimization, especially if you do not require all information within it to be entirely timely.
I figured you'd say this. But somehow I feel that this point should be emphasized in the document. Besides we should also address the case when a new resource is added to a site (where there is already a site level information provider). How will the new resource register or how will the site level information provider discover this new resource. Meaning, is the onus on the resource level provider to advertise or the site level provider to discover. Same thing when a resource drops off. I like the idea of caching. If this is the route we are taking it needs to be put in the document. Then the questions is how frequently the cache is/should be updated? Where will the cache reside? At the host or where the provider is? This needs to go in too. Finally, how will all this be propagated to Grid level. Felix Nikolaus Ehm <felixehm@mail.cern.ch> wrote: Hi, in case you are referring to version 2 of the document:
Agreed, that paragraph is confusing. (I suspect, but do not know, that the information you highlighted was the information produced by the "resource-level provider" but that's just my reading...)
Yes, this paragraph is intended to explain the purpose of a resource level information provider (for performance reasons it may also have a build-in caching). I've changed this part in version 3. Please have a look there.
Does this mean even the resource level information provider is not required??? Or are we saying the service that provides the capability to query is not required????
The passage wants to express that if a site information system is available and provides a common query interface, the resource level information components don't necessarily need to implement the same interface. In my opinion their purpose should then be to populate information to the site level and not serving external requests. Concerning the question if the resource level info providers are essential INSTEAD of a site-level one I agree with Donal. In the past it turned out that caching represents latency, but also protects resources from being bombed by requests. Felix On Tue, 7 Aug 2007, Donal K. Fellows wrote:
guru prasad wrote:
I have some corrections and questions. I have highlighted those in the attached document. Can someone please help me understand.
Going through your comments (extracted from the document)...
Comment #1:
What information. Information about the resource or the fact that the information provider is on the same host. Too many "This"
Agreed, that paragraph is confusing. (I suspect, but do not know, that the information you highlighted was the information produced by the "resource-level provider" but that's just my reading...)
Comment #2:
Does this mean even the resource level information provider is not required??? Or are we saying the service that provides the capability to query is not required????
If the answer to the first question is yes then, I would say it may still be required. Instead of site level information registry getting overloaded with queries about the resources it has, if one has a visibility of a particular resource he could just query that resource.
I'd say that while the resource-level provider is not a priori required, it has to be there conceptually. Sites are free to use other mechanisms to actually do the information provision though.
On the other hand, I really disagree with your second paragraph there. One key gain from having a site-level information system is that this is a prime location for carrying out queries for resource discovery and scheduling. If you require everything to ask the end resources directly, then anything that actually needs to look at many resources will end up being dog slow because of the amount of network traffic needed to take any kind of decision (trust me, I've tried this!) A site-level info system is a major optimization, especially if you do not require all information within it to be entirely timely.
Comment #3:
Should it say that the developer of the resources could be the information provider ???? This is not clear from the sentence.
That sentence is wildly unclear, but I suspect it's talking about some kind of API for basic info providers to make it easier to write the actual information sources. However, I wonder whether this falls more within the remit of SAGA - do they do server-side APIs? - since OGSA (and related groups) has tended to focus on the wire view of interop.
Donal. -- ogsa-wg mailing list ogsa-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-wg
--------------------------------- Park yourself in front of a world of choices in alternative vehicles. Visit the Yahoo! Auto Green Center.
Hi Guru,
Hello Fleix and Donal,
I see we have totally stopped discussions on this thread. I have sent a reply to this and even a reminder after that (which apparently I can't locate in my inbox) but neither do I see any comments nor do I see an update version. My comments were more on the lines of mentioning all the things we have said here more clearly in the document.
Can you guys please look for that email from me and send it to me. Perhaps, we could start and end this thread.
Others,
If anyone of you can find that email from that will be great too.
Thank you. Guru (please find your mail below)
How will the new resource register or how will the site level information
To conclude the agreement : We agree on a site level information system which caches data from its recources. The resources are not queried directly by any other instances, but its information is available in the site level information system. provider discover this new
resource. Meaning, is the onus on the resource level provider to advertise or the site level provider to discover. I think this is rather a implementation/deplyoment issue than a standartization one. The paragraph ("Recommendations for Standards", 2) wants to express the need for a common way of exchanging the registry of endpoints information between infrastructures. It is not intented to standartize a way of how the enpoints are registered within the infrastructure. However, I'm sure there is a way of best practice.
I like the idea of caching. If this is the route we are taking it needs to be put in the document. Then the questions is how frequently the cache is/should be updated? Where will the cache reside? At the host or where the provider is? This needs to go in too. I'm not sure what you mean by 'host' - the resource or the host which requests the information? In both cases I think the site-level info-system (provider) should cache the information. The resource should not cache at all. If we rely on the fact that the user host caches the info, we run against the problem that they will then switch off the chaching to try to get always the latest information. ( at least this is what I'll do :-) ) Then, we have the request bombing scanario again.
But again, this and the frequency of updating the information should be a implementation/deployment issue and is therefore not defined in this document.
Finally, how will all this be propagated to Grid level. The way site information is made available to the grid is suggested by the common query interface ("Recommendations for Standards", 1) .
Felix --- Felix Ehm Tel: +41 22 76 74580 CERN Fax: +41 22 76 68783 IT-GD-ITR CH 1211, Geneve ------------------------------------------ _____ From: guru prasad [mailto:guru_bn@yahoo.com] Sent: Dienstag, 7. August 2007 19:12 To: Felix Nikolaus Ehm; Donal K. Fellows Cc: guru prasad; glue-wg@ogf.org; ogsa-wg Subject: Re: [ogsa-wg] OGSA Information Services - Version 3 Felix, Donal, Guru,
Agreed, that paragraph is confusing. (I suspect, but do not know, that the information you highlighted was the information produced by the "resource-level provider" but that's just my reading...)
Yes, this paragraph is intended to explain the purpose of a resource level information provider (for performance reasons it may also have a build-in caching). I've changed this part in version 3. Please have a look there.
Comment #2:
Does this mean even the resource level information provider is not required??? Or are we saying the service that provides the capability to query is not required????
If the answer to the first question is yes then, I would say it may still be required. Instead of site level information registry getting overloaded with queries about the resources it has, if one has a visibility of a particular resource he could just query that resource.
I'd say that while the resource-level provider is not a priori required, it has to be there conceptually. Sites are free to use other mechanisms to actually do the information provision though.
On the other hand, I really disagree with your second paragraph there. One key gain from having a site-level information system is that this is a prime location for carrying out queries for resource discovery and scheduling. If you require everything to ask the end resources directly, then anything that actually needs to look at many resources will end up being dog slow because of the amount of network traffic needed to take any kind of decision (trust me, I've tried this!) A site-level info system is a major optimization, especially if you do not require all information within it to be entirely timely.
I figured you'd say this. But somehow I feel that this point should be emphasized in the document. Besides we should also address the case when a new resource is added to a site (where there is already a site level information provider). How will the new resource register or how will the site level information provider discover this new resource. Meaning, is the onus on the resource level provider to advertise or the site level provider to discover. Same thing when a resource drops off. I like the idea of caching. If this is the route we are taking it needs to be put in the document. Then the questions is how frequently the cache is/should be updated? Where will the cache reside? At the host or where the provider is? This needs to go in too. Finally, how will all this be propagated to Grid level. Felix Nikolaus Ehm <felixehm@mail.cern.ch> wrote: Hi, in case you are referring to version 2 of the document:
Agreed, that paragraph is confusing. (I suspect, but do not know, that the information you highlighted was the information produced by the "resource-level provider" but that's just my reading...)
Yes, this paragraph is intended to explain the purpose of a resource level information provider (for performance reasons it may also have a build-in caching). I've changed this part in version 3. Please have a look there.
Does this mean even the resource level information provider is not required??? Or are we saying the service that provides the capability to query is not required????
The passage wants to express that if a site information system is available and provides a common query interface, the resource level information components don't necessarily need to implement the same interface. In my opinion their purpose should then be to populate information to the site level and not serving external requests. Concerning the question if the resource level info providers are essential INSTEAD of a site-level one I agree with Donal. In the past it turned out that caching represents latency, but also protects resources from being bombed by requests. Felix On Tue, 7 Aug 2007, Donal K. Fellows wrote:
guru prasad wrote:
I have some corrections and questions. I have highlighted those in the attached document. Can someone please help me understand.
Going through your comments (extracted from the document)...
Comment #1:
What information. Information about the resource or the fact that the information provider is on the same host. Too many "This"
Agreed, that paragraph is confusing. (I suspect, but do not know, that the information you highlighted was the information produced by the "resource-level provider" but that's just my reading...)
Comment #2:
Does this mean even the resource level information provider is not required??? Or are we saying the service that provides the capability to query is not required????
If the answer to the first question is yes then, I would say it may still be required. Instead of site level information registry getting overloaded with queries about the resources it has, if one has a visibility of a particular resource he could just query that resource.
I'd say that while the resource-level provider is not a priori required, it has to be there conceptually. Sites are free to use other mechanisms to actually do the information provision though.
On the other hand, I really disagree with your second paragraph there. One key gain from having a site-level information system is that this is a prime location for carrying out queries for resource discovery and scheduling. If you require everything to ask the end resources directly, then anything that actually needs to look at many resources will end up being dog slow because of the amount of network traffic needed to take any kind of decision (trust me, I've tried this!) A site-level info system is a major optimization, especially if you do not require all information within it to be entirely timely.
Comment #3:
Should it say that the developer of the resources could be the information provider ???? This is not clear from the sentence.
That sentence is wildly unclear, but I suspect it's talking about some kind of API for basic info providers to make it easier to write the actual information sources. However, I wonder whether this falls more within the remit of SAGA - do they do server-side APIs? - since OGSA (and related groups) has tended to focus on the wire view of interop.
Donal. -- ogsa-wg mailing list ogsa-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-wg
_____ Park yourself in front of a world of choices in alternative vehicles. Visit <http://us.rd.yahoo.com/evt=48246/*http://autos.yahoo.com/green_center/;_ylc =X3oDMTE5cDF2bXZzBF9TAzk3MTA3MDc2BHNlYwNtYWlsdGFncwRzbGsDZ3JlZW4tY2VudGVy> the Yahoo! Auto Green Center.
Hello Fleix and Donal, I see we have totally stopped discussions on this thread. I have sent a reply to this and even a reminder after that (which apparently I can't locate in my inbox) but neither do I see any comments nor do I see an update version. My comments were more on the lines of mentioning all the things we have said here more clearly in the document. Can you guys please look for that email from me and send it to me. Perhaps, we could start and end this thread. Others, If anyone of you can find that email from that will be great too. Thank you. Guru Felix Nikolaus Ehm <felixehm@mail.cern.ch> wrote: Hi, in case you are referring to version 2 of the document:
Agreed, that paragraph is confusing. (I suspect, but do not know, that the information you highlighted was the information produced by the "resource-level provider" but that's just my reading...)
Yes, this paragraph is intended to explain the purpose of a resource level information provider (for performance reasons it may also have a build-in caching). I've changed this part in version 3. Please have a look there.
Does this mean even the resource level information provider is not required??? Or are we saying the service that provides the capability to query is not required????
The passage wants to express that if a site information system is available and provides a common query interface, the resource level information components don't necessarily need to implement the same interface. In my opinion their purpose should then be to populate information to the site level and not serving external requests. Concerning the question if the resource level info providers are essential INSTEAD of a site-level one I agree with Donal. In the past it turned out that caching represents latency, but also protects resources from being bombed by requests. Felix On Tue, 7 Aug 2007, Donal K. Fellows wrote:
guru prasad wrote:
I have some corrections and questions. I have highlighted those in the attached document. Can someone please help me understand.
Going through your comments (extracted from the document)...
Comment #1:
What information. Information about the resource or the fact that the information provider is on the same host. Too many "This"
Agreed, that paragraph is confusing. (I suspect, but do not know, that the information you highlighted was the information produced by the "resource-level provider" but that's just my reading...)
Comment #2:
Does this mean even the resource level information provider is not required??? Or are we saying the service that provides the capability to query is not required????
If the answer to the first question is yes then, I would say it may still be required. Instead of site level information registry getting overloaded with queries about the resources it has, if one has a visibility of a particular resource he could just query that resource.
I'd say that while the resource-level provider is not a priori required, it has to be there conceptually. Sites are free to use other mechanisms to actually do the information provision though.
On the other hand, I really disagree with your second paragraph there. One key gain from having a site-level information system is that this is a prime location for carrying out queries for resource discovery and scheduling. If you require everything to ask the end resources directly, then anything that actually needs to look at many resources will end up being dog slow because of the amount of network traffic needed to take any kind of decision (trust me, I've tried this!) A site-level info system is a major optimization, especially if you do not require all information within it to be entirely timely.
Comment #3:
Should it say that the developer of the resources could be the information provider ???? This is not clear from the sentence.
That sentence is wildly unclear, but I suspect it's talking about some kind of API for basic info providers to make it easier to write the actual information sources. However, I wonder whether this falls more within the remit of SAGA - do they do server-side APIs? - since OGSA (and related groups) has tended to focus on the wire view of interop.
Donal. -- ogsa-wg mailing list ogsa-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-wg
--------------------------------- Tonight's top picks. What will you watch tonight? Preview the hottest shows on Yahoo! TV.
Hi Hiro/Felix, Currently the examples in the document are from "academia" (not that I am against that as most who know me will attest) but in the spirit of including enterprise examples would it make sense to include the implementation that I presented at the OGSA F2F in Manchester as an example for the enterprise case? Ravi -----Original Message----- From: ogsa-wg-bounces@ogf.org [mailto:ogsa-wg-bounces@ogf.org] On Behalf Of Hiro Kishimoto Sent: Wednesday, August 01, 2007 2:49 PM To: ogsa-wg Cc: glue-wg@ogf.org Subject: Re: [ogsa-wg] OGSA Information Services Hi all, Per Felix's request, I've upload revised draft onto the GridForge. https://forge.gridforum.org/sf/go/doc14692 We will discuss it at Thursday's call. Thanks, ---- Hiro Kishimoto -------- Original Message -------- Subject: Re:[ogsa-wg] OGSA Information Services From: Hiro Kishimoto <hiro.kishimoto@jp.fujitsu.com> To: ogsa-wg <ogsa-wg@ogf.org> Cc: felix.ehm@cern.ch Date: 2007/07/26 12:55
Hi all,
Discussion material for Information Services by Laurence Field and Felix Ehm is now on the GridForge.
https://forge.gridforum.org/sf/go/doc14692
This document covers the problem description, experience in GIN, >
overview of existing systems, generalized system and suggested > areas for standardization.
Please have a look before the call today.
Felix Ehm will lead the discussion.
Thanks, ---- Hiro Kishimoto
-- ogsa-wg mailing list ogsa-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-wg
-- ogsa-wg mailing list ogsa-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-wg
The presentation Ravi is referring to is https://forge.gridforum.org/sf/go/doc14456?nav=1 Subramaniam, Ravi wrote:
Hi Hiro/Felix,
Currently the examples in the document are from "academia" (not that I am against that as most who know me will attest) but in the spirit of including enterprise examples would it make sense to include the implementation that I presented at the OGSA F2F in Manchester as an example for the enterprise case?
Ravi
-----Original Message----- From: ogsa-wg-bounces@ogf.org [mailto:ogsa-wg-bounces@ogf.org] On Behalf Of Hiro Kishimoto Sent: Wednesday, August 01, 2007 2:49 PM To: ogsa-wg Cc: glue-wg@ogf.org Subject: Re: [ogsa-wg] OGSA Information Services
Hi all,
Per Felix's request, I've upload revised draft onto the GridForge.
https://forge.gridforum.org/sf/go/doc14692
We will discuss it at Thursday's call.
Thanks, ---- Hiro Kishimoto
-------- Original Message -------- Subject: Re:[ogsa-wg] OGSA Information Services From: Hiro Kishimoto <hiro.kishimoto@jp.fujitsu.com> To: ogsa-wg <ogsa-wg@ogf.org> Cc: felix.ehm@cern.ch Date: 2007/07/26 12:55
Hi all,
Discussion material for Information Services by Laurence Field and Felix Ehm is now on the GridForge.
https://forge.gridforum.org/sf/go/doc14692
This document covers the problem description, experience in GIN, >
overview of existing systems, generalized system and suggested > areas for standardization.
Please have a look before the call today.
Felix Ehm will lead the discussion.
Thanks, ---- Hiro Kishimoto
-- ogsa-wg mailing list ogsa-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-wg
-- ogsa-wg mailing list ogsa-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-wg _______________________________________________ glue-wg mailing list glue-wg@ogf.org http://www.ogf.org/mailman/listinfo/glue-wg
Hi all, I don't have anything against having another layer sitting on top of all different Grid information systems implementation but I'm just not sure if that model will scale. I got interested in this discussion because I'm developing an application which is somewhat related to what I'm going to recommend below. The application is being developed for the Australian Grid users and developers and is going to be used in querying an MDS4 index service which uses the GLUE 1.2 schema. We have specified our own query language for querying the information system because we didn't want developers to write XPath queries if they directly interact with MDS4. As you know a very simple resource condition in an info systems query can turn out to be a very long query string when converted into XPath especially XPath 1.1 which is what MDS4 only understands. This group should probably look into implementing a similar generic Grid info systems client application for all the Grid info systems implementations around the world. Since the plan is to use the GLUE schema, there won't be any issues with specifying a standard query language that users can use with this client. The client will need to be able to query a "registry of endpoints" service to get information about the endpoint, query implementation (eg. wsrf/mds4, mds2, etc), and the query language (xpath, xquery, ldap, sql) to use for the info systems. The client will be the one in charge of transforming the user's query into the respective query languages used by the different Grid information systems implementations. I think we'll get a quicker response if we query the "registry of endpoints" service than the top level information system which indexes all the Grid resource information around the world. Our application can only handle a very simple query at the moment. See link below.. https://www.grid.apac.edu.au/repository/svn/infosystems/GlueSchemaQueryLib/R... but we have plans of extending the language later on to support queries like "(Site.Latitude > 0 and Site.Latitude < 50)". Composing a query for the GLUE schema shouldn't be that hard. The only thing which makes the query complicated is the language we use in querying the Grid info systems. I'm just not sure if what we are implementing is something you would want to look into. Regards, Gerson On 8/4/07, Andreas Savva <andreas.savva@jp.fujitsu.com> wrote:
The presentation Ravi is referring to is https://forge.gridforum.org/sf/go/doc14456?nav=1
Subramaniam, Ravi wrote:
Hi Hiro/Felix,
Currently the examples in the document are from "academia" (not that I am against that as most who know me will attest) but in the spirit of including enterprise examples would it make sense to include the implementation that I presented at the OGSA F2F in Manchester as an example for the enterprise case?
Ravi
-----Original Message----- From: ogsa-wg-bounces@ogf.org [mailto:ogsa-wg-bounces@ogf.org] On Behalf Of Hiro Kishimoto Sent: Wednesday, August 01, 2007 2:49 PM To: ogsa-wg Cc: glue-wg@ogf.org Subject: Re: [ogsa-wg] OGSA Information Services
Hi all,
Per Felix's request, I've upload revised draft onto the GridForge.
https://forge.gridforum.org/sf/go/doc14692
We will discuss it at Thursday's call.
Thanks, ---- Hiro Kishimoto
-------- Original Message -------- Subject: Re:[ogsa-wg] OGSA Information Services From: Hiro Kishimoto <hiro.kishimoto@jp.fujitsu.com > To: ogsa-wg <ogsa-wg@ogf.org> Cc: felix.ehm@cern.ch Date: 2007/07/26 12:55
Hi all,
Discussion material for Information Services by Laurence Field and Felix Ehm is now on the GridForge.
https://forge.gridforum.org/sf/go/doc14692
This document covers the problem description, experience in GIN, >
overview of existing systems, generalized system and suggested > areas for standardization.
Please have a look before the call today.
Felix Ehm will lead the discussion.
Thanks, ---- Hiro Kishimoto
-- ogsa-wg mailing list ogsa-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-wg
-- ogsa-wg mailing list ogsa-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-wg _______________________________________________ glue-wg mailing list glue-wg@ogf.org http://www.ogf.org/mailman/listinfo/glue-wg
_______________________________________________ glue-wg mailing list glue-wg@ogf.org http://www.ogf.org/mailman/listinfo/glue-wg
Hi Gerson, A common information system client would bets fit will with the SAGA work. They are already working on an API for Service discovery which will use plugins to find information from the different grids. The OGSA Information Services group is currently looking it existing technologies used in information systems. Your experiences with MDS4 and XPath would be valuable input to this group. Do you have anything available which documents your experiences? Thanks Laurence Gerson Galang wrote:
Hi all,
I don't have anything against having another layer sitting on top of all different Grid information systems implementation but I'm just not sure if that model will scale.
I got interested in this discussion because I'm developing an application which is somewhat related to what I'm going to recommend below. The application is being developed for the Australian Grid users and developers and is going to be used in querying an MDS4 index service which uses the GLUE 1.2 schema. We have specified our own query language for querying the information system because we didn't want developers to write XPath queries if they directly interact with MDS4. As you know a very simple resource condition in an info systems query can turn out to be a very long query string when converted into XPath especially XPath 1.1 which is what MDS4 only understands.
This group should probably look into implementing a similar generic Grid info systems client application for all the Grid info systems implementations around the world. Since the plan is to use the GLUE schema, there won't be any issues with specifying a standard query language that users can use with this client. The client will need to be able to query a "registry of endpoints" service to get information about the endpoint, query implementation (eg. wsrf/mds4, mds2, etc), and the query language (xpath, xquery, ldap, sql) to use for the info systems. The client will be the one in charge of transforming the user's query into the respective query languages used by the different Grid information systems implementations. I think we'll get a quicker response if we query the "registry of endpoints" service than the top level information system which indexes all the Grid resource information around the world.
Our application can only handle a very simple query at the moment. See link below..
https://www.grid.apac.edu.au/repository/svn/infosystems/GlueSchemaQueryLib/R... <https://www.grid.apac.edu.au/repository/svn/infosystems/GlueSchemaQueryLib/README>
but we have plans of extending the language later on to support queries like "(Site.Latitude > 0 and Site.Latitude < 50)". Composing a query for the GLUE schema shouldn't be that hard. The only thing which makes the query complicated is the language we use in querying the Grid info systems.
I'm just not sure if what we are implementing is something you would want to look into.
Regards, Gerson
On 8/4/07, *Andreas Savva* <andreas.savva@jp.fujitsu.com <mailto:andreas.savva@jp.fujitsu.com>> wrote:
The presentation Ravi is referring to is https://forge.gridforum.org/sf/go/doc14456?nav=1 <https://forge.gridforum.org/sf/go/doc14456?nav=1>
Subramaniam, Ravi wrote: > Hi Hiro/Felix, > > Currently the examples in the document are from "academia" (not that I > am against that as most who know me will attest) but in the spirit of > including enterprise examples would it make sense to include the > implementation that I presented at the OGSA F2F in Manchester as an > example for the enterprise case? > > Ravi > > -----Original Message----- > From: ogsa-wg-bounces@ogf.org <mailto:ogsa-wg-bounces@ogf.org> [mailto:ogsa-wg-bounces@ogf.org <mailto:ogsa-wg-bounces@ogf.org>] On Behalf > Of Hiro Kishimoto > Sent: Wednesday, August 01, 2007 2:49 PM > To: ogsa-wg > Cc: glue-wg@ogf.org <mailto:glue-wg@ogf.org> > Subject: Re: [ogsa-wg] OGSA Information Services > > Hi all, > > Per Felix's request, I've upload revised draft onto the GridForge. > > https://forge.gridforum.org/sf/go/doc14692 > > We will discuss it at Thursday's call. > > Thanks, > ---- > Hiro Kishimoto > > -------- Original Message -------- > Subject: Re:[ogsa-wg] OGSA Information Services > From: Hiro Kishimoto < hiro.kishimoto@jp.fujitsu.com <mailto:hiro.kishimoto@jp.fujitsu.com> > > To: ogsa-wg <ogsa-wg@ogf.org <mailto:ogsa-wg@ogf.org>> > Cc: felix.ehm@cern.ch <mailto:felix.ehm@cern.ch> > Date: 2007/07/26 12:55 > >> Hi all, >> >> Discussion material for Information Services by Laurence Field and >> Felix Ehm is now on the GridForge. >> >> https://forge.gridforum.org/sf/go/doc14692 <https://forge.gridforum.org/sf/go/doc14692> >> >> > This document covers the problem description, experience in GIN, > > >> overview of existing systems, generalized system and suggested > >> areas for standardization. >> >> Please have a look before the call today. >> >> Felix Ehm will lead the discussion. >> >> Thanks, >> ---- >> Hiro Kishimoto >> >> >> -- >> ogsa-wg mailing list >> ogsa-wg@ogf.org <mailto:ogsa-wg@ogf.org> >> http://www.ogf.org/mailman/listinfo/ogsa-wg <http://www.ogf.org/mailman/listinfo/ogsa-wg> >> >> > > -- > ogsa-wg mailing list > ogsa-wg@ogf.org <mailto:ogsa-wg@ogf.org> > http://www.ogf.org/mailman/listinfo/ogsa-wg <http://www.ogf.org/mailman/listinfo/ogsa-wg> > _______________________________________________ > glue-wg mailing list > glue-wg@ogf.org <mailto:glue-wg@ogf.org> > http://www.ogf.org/mailman/listinfo/glue-wg <http://www.ogf.org/mailman/listinfo/glue-wg>
_______________________________________________ glue-wg mailing list glue-wg@ogf.org <mailto:glue-wg@ogf.org> http://www.ogf.org/mailman/listinfo/glue-wg <http://www.ogf.org/mailman/listinfo/glue-wg>
------------------------------------------------------------------------
_______________________________________________ glue-wg mailing list glue-wg@ogf.org http://www.ogf.org/mailman/listinfo/glue-wg
Hi Laurence, Have you looked at the discovery mechanisms found in peer-2-peer systems -- which are much more likely to scale? There has been work in integrating P2P concepts with directory services also. My understanding of SAGA effort is that they identify that a discovery service is necessary -- but not how the actual discovery mechanism works (as this is outside, surely, the scope of SAGA)? regards Omer Laurence Field wrote:
Hi Gerson,
A common information system client would bets fit will with the SAGA work. They are already working on an API for Service discovery which will use plugins to find information from the different grids.
The OGSA Information Services group is currently looking it existing technologies used in information systems. Your experiences with MDS4 and XPath would be valuable input to this group. Do you have anything available which documents your experiences?
Thanks
Laurence
Gerson Galang wrote:
Hi all,
I don't have anything against having another layer sitting on top of all different Grid information systems implementation but I'm just not sure if that model will scale.
I got interested in this discussion because I'm developing an application which is somewhat related to what I'm going to recommend below. The application is being developed for the Australian Grid users and developers and is going to be used in querying an MDS4 index service which uses the GLUE 1.2 schema. We have specified our own query language for querying the information system because we didn't want developers to write XPath queries if they directly interact with MDS4. As you know a very simple resource condition in an info systems query can turn out to be a very long query string when converted into XPath especially XPath 1.1 which is what MDS4 only understands.
This group should probably look into implementing a similar generic Grid info systems client application for all the Grid info systems implementations around the world. Since the plan is to use the GLUE schema, there won't be any issues with specifying a standard query language that users can use with this client. The client will need to be able to query a "registry of endpoints" service to get information about the endpoint, query implementation (eg. wsrf/mds4, mds2, etc), and the query language (xpath, xquery, ldap, sql) to use for the info systems. The client will be the one in charge of transforming the user's query into the respective query languages used by the different Grid information systems implementations. I think we'll get a quicker response if we query the "registry of endpoints" service than the top level information system which indexes all the Grid resource information around the world.
Our application can only handle a very simple query at the moment. See link below..
https://www.grid.apac.edu.au/repository/svn/infosystems/GlueSchemaQueryLib/R... <https://www.grid.apac.edu.au/repository/svn/infosystems/GlueSchemaQueryLib/README>
but we have plans of extending the language later on to support queries like "(Site.Latitude > 0 and Site.Latitude < 50)". Composing a query for the GLUE schema shouldn't be that hard. The only thing which makes the query complicated is the language we use in querying the Grid info systems.
I'm just not sure if what we are implementing is something you would want to look into.
Regards, Gerson
On 8/4/07, *Andreas Savva* <andreas.savva@jp.fujitsu.com <mailto:andreas.savva@jp.fujitsu.com>> wrote:
The presentation Ravi is referring to is https://forge.gridforum.org/sf/go/doc14456?nav=1 <https://forge.gridforum.org/sf/go/doc14456?nav=1>
Subramaniam, Ravi wrote: > Hi Hiro/Felix, > > Currently the examples in the document are from "academia" (not that I > am against that as most who know me will attest) but in the spirit of > including enterprise examples would it make sense to include the > implementation that I presented at the OGSA F2F in Manchester as an > example for the enterprise case? > > Ravi > > -----Original Message----- > From: ogsa-wg-bounces@ogf.org <mailto:ogsa-wg-bounces@ogf.org> [mailto:ogsa-wg-bounces@ogf.org <mailto:ogsa-wg-bounces@ogf.org>] On Behalf > Of Hiro Kishimoto > Sent: Wednesday, August 01, 2007 2:49 PM > To: ogsa-wg > Cc: glue-wg@ogf.org <mailto:glue-wg@ogf.org> > Subject: Re: [ogsa-wg] OGSA Information Services > > Hi all, > > Per Felix's request, I've upload revised draft onto the GridForge. > > https://forge.gridforum.org/sf/go/doc14692 > > We will discuss it at Thursday's call. > > Thanks, > ---- > Hiro Kishimoto > > -------- Original Message -------- > Subject: Re:[ogsa-wg] OGSA Information Services > From: Hiro Kishimoto < hiro.kishimoto@jp.fujitsu.com <mailto:hiro.kishimoto@jp.fujitsu.com> > > To: ogsa-wg <ogsa-wg@ogf.org <mailto:ogsa-wg@ogf.org>> > Cc: felix.ehm@cern.ch <mailto:felix.ehm@cern.ch> > Date: 2007/07/26 12:55 > >> Hi all, >> >> Discussion material for Information Services by Laurence Field and >> Felix Ehm is now on the GridForge. >> >> https://forge.gridforum.org/sf/go/doc14692 <https://forge.gridforum.org/sf/go/doc14692> >> >> > This document covers the problem description, experience in GIN, > > >> overview of existing systems, generalized system and suggested > >> areas for standardization. >> >> Please have a look before the call today. >> >> Felix Ehm will lead the discussion. >> >> Thanks, >> ---- >> Hiro Kishimoto >> >> >> -- >> ogsa-wg mailing list >> ogsa-wg@ogf.org <mailto:ogsa-wg@ogf.org> >> http://www.ogf.org/mailman/listinfo/ogsa-wg <http://www.ogf.org/mailman/listinfo/ogsa-wg> >> >> > > -- > ogsa-wg mailing list > ogsa-wg@ogf.org <mailto:ogsa-wg@ogf.org> > http://www.ogf.org/mailman/listinfo/ogsa-wg <http://www.ogf.org/mailman/listinfo/ogsa-wg> > _______________________________________________ > glue-wg mailing list > glue-wg@ogf.org <mailto:glue-wg@ogf.org> > http://www.ogf.org/mailman/listinfo/glue-wg <http://www.ogf.org/mailman/listinfo/glue-wg>
_______________________________________________ glue-wg mailing list glue-wg@ogf.org <mailto:glue-wg@ogf.org> http://www.ogf.org/mailman/listinfo/glue-wg <http://www.ogf.org/mailman/listinfo/glue-wg>
------------------------------------------------------------------------
_______________________________________________ glue-wg mailing list glue-wg@ogf.org http://www.ogf.org/mailman/listinfo/glue-wg
-- ogsa-wg mailing list ogsa-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-wg
-- http://www.cs.cf.ac.uk/User/O.F.Rana/index.html / work-fax:+44(0)29-2087-4598 work:+44(0)29-2087-5542 / other:+44(0)7956-299981 / distributed collaborative computing / room n2.14 / school of computer science / cardiff university queen's buildings / newport road / cardiff cf24 3aa / wales / uk
Hi Omer, Each grid is currently using a different discovery mechanism. This aim of the SAGA work is to provide an API which hides these differences and enables the user to discover resources in all grids. I believe this is the functionality which Gerson was talking about. Standardizing the discovery methods is something that we should look into and the mechanisms used in many P2P systems should definitely be investigated. Laurence The SAGA effort is trying to Omer F. Rana wrote:
Hi Laurence,
Have you looked at the discovery mechanisms found in peer-2-peer systems -- which are much more likely to scale? There has been work in integrating P2P concepts with directory services also.
My understanding of SAGA effort is that they identify that a discovery service is necessary -- but not how the actual discovery mechanism works (as this is outside, surely, the scope of SAGA)?
regards Omer
Laurence Field wrote:
Hi Gerson,
A common information system client would bets fit will with the SAGA work. They are already working on an API for Service discovery which will use plugins to find information from the different grids.
The OGSA Information Services group is currently looking it existing technologies used in information systems. Your experiences with MDS4 and XPath would be valuable input to this group. Do you have anything available which documents your experiences?
Thanks
Laurence
Gerson Galang wrote:
Hi all,
I don't have anything against having another layer sitting on top of all different Grid information systems implementation but I'm just not sure if that model will scale.
I got interested in this discussion because I'm developing an application which is somewhat related to what I'm going to recommend below. The application is being developed for the Australian Grid users and developers and is going to be used in querying an MDS4 index service which uses the GLUE 1.2 schema. We have specified our own query language for querying the information system because we didn't want developers to write XPath queries if they directly interact with MDS4. As you know a very simple resource condition in an info systems query can turn out to be a very long query string when converted into XPath especially XPath 1.1 which is what MDS4 only understands.
This group should probably look into implementing a similar generic Grid info systems client application for all the Grid info systems implementations around the world. Since the plan is to use the GLUE schema, there won't be any issues with specifying a standard query language that users can use with this client. The client will need to be able to query a "registry of endpoints" service to get information about the endpoint, query implementation (eg. wsrf/mds4, mds2, etc), and the query language (xpath, xquery, ldap, sql) to use for the info systems. The client will be the one in charge of transforming the user's query into the respective query languages used by the different Grid information systems implementations. I think we'll get a quicker response if we query the "registry of endpoints" service than the top level information system which indexes all the Grid resource information around the world.
Our application can only handle a very simple query at the moment. See link below..
https://www.grid.apac.edu.au/repository/svn/infosystems/GlueSchemaQueryLib/R... <https://www.grid.apac.edu.au/repository/svn/infosystems/GlueSchemaQueryLib/README>
but we have plans of extending the language later on to support queries like "(Site.Latitude > 0 and Site.Latitude < 50)". Composing a query for the GLUE schema shouldn't be that hard. The only thing which makes the query complicated is the language we use in querying the Grid info systems.
I'm just not sure if what we are implementing is something you would want to look into.
Regards, Gerson
On 8/4/07, *Andreas Savva* <andreas.savva@jp.fujitsu.com <mailto:andreas.savva@jp.fujitsu.com>> wrote:
The presentation Ravi is referring to is https://forge.gridforum.org/sf/go/doc14456?nav=1 <https://forge.gridforum.org/sf/go/doc14456?nav=1>
Subramaniam, Ravi wrote: > Hi Hiro/Felix, > > Currently the examples in the document are from "academia" (not that I > am against that as most who know me will attest) but in the spirit of > including enterprise examples would it make sense to include the > implementation that I presented at the OGSA F2F in Manchester as an > example for the enterprise case? > > Ravi > > -----Original Message----- > From: ogsa-wg-bounces@ogf.org <mailto:ogsa-wg-bounces@ogf.org> [mailto:ogsa-wg-bounces@ogf.org <mailto:ogsa-wg-bounces@ogf.org>] On Behalf > Of Hiro Kishimoto > Sent: Wednesday, August 01, 2007 2:49 PM > To: ogsa-wg > Cc: glue-wg@ogf.org <mailto:glue-wg@ogf.org> > Subject: Re: [ogsa-wg] OGSA Information Services > > Hi all, > > Per Felix's request, I've upload revised draft onto the GridForge. > > https://forge.gridforum.org/sf/go/doc14692 > > We will discuss it at Thursday's call. > > Thanks, > ---- > Hiro Kishimoto > > -------- Original Message -------- > Subject: Re:[ogsa-wg] OGSA Information Services > From: Hiro Kishimoto < hiro.kishimoto@jp.fujitsu.com <mailto:hiro.kishimoto@jp.fujitsu.com> > > To: ogsa-wg <ogsa-wg@ogf.org <mailto:ogsa-wg@ogf.org>> > Cc: felix.ehm@cern.ch <mailto:felix.ehm@cern.ch> > Date: 2007/07/26 12:55 > >> Hi all, >> >> Discussion material for Information Services by Laurence Field and >> Felix Ehm is now on the GridForge. >> >> https://forge.gridforum.org/sf/go/doc14692 <https://forge.gridforum.org/sf/go/doc14692> >> >> > This document covers the problem description, experience in GIN, > > >> overview of existing systems, generalized system and suggested > >> areas for standardization. >> >> Please have a look before the call today. >> >> Felix Ehm will lead the discussion. >> >> Thanks, >> ---- >> Hiro Kishimoto >> >> >> -- >> ogsa-wg mailing list >> ogsa-wg@ogf.org <mailto:ogsa-wg@ogf.org> >> http://www.ogf.org/mailman/listinfo/ogsa-wg <http://www.ogf.org/mailman/listinfo/ogsa-wg> >> >> > > -- > ogsa-wg mailing list > ogsa-wg@ogf.org <mailto:ogsa-wg@ogf.org> > http://www.ogf.org/mailman/listinfo/ogsa-wg <http://www.ogf.org/mailman/listinfo/ogsa-wg> > _______________________________________________ > glue-wg mailing list > glue-wg@ogf.org <mailto:glue-wg@ogf.org> > http://www.ogf.org/mailman/listinfo/glue-wg <http://www.ogf.org/mailman/listinfo/glue-wg>
_______________________________________________ glue-wg mailing list glue-wg@ogf.org <mailto:glue-wg@ogf.org> http://www.ogf.org/mailman/listinfo/glue-wg <http://www.ogf.org/mailman/listinfo/glue-wg>
------------------------------------------------------------------------
_______________________________________________ glue-wg mailing list glue-wg@ogf.org http://www.ogf.org/mailman/listinfo/glue-wg
-- ogsa-wg mailing list ogsa-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-wg
Thanks Laurence, On 8/17/07, Laurence Field <Laurence.Field@cern.ch> wrote:
Hi Gerson,
A common information system client would bets fit will with the SAGA work. They are already working on an API for Service discovery which will use plugins to find information from the different grids.
I'll try and get in contact with the people from SAGA who might find a use for the stuff we've been working on. The OGSA Information Services group is currently looking it existing
technologies used in information systems. Your experiences with MDS4 and XPath would be valuable input to this group. Do you have anything available which documents your experiences?
We have most of our documentations on deploying the Australian National Grid's Info System available on this twiki page... http://www.vpac.org/twiki/bin/view/APACgrid/PlanResource If you want something in a technical report/paper format... http://www.vpac.org/twiki/bin/view/APACgrid/PlanResource#Technical_Reports_P... Regards, Gerson Thanks
Laurence
Gerson Galang wrote:
Hi all,
I don't have anything against having another layer sitting on top of all different Grid information systems implementation but I'm just not sure if that model will scale.
I got interested in this discussion because I'm developing an application which is somewhat related to what I'm going to recommend below. The application is being developed for the Australian Grid users and developers and is going to be used in querying an MDS4 index service which uses the GLUE 1.2 schema. We have specified our own query language for querying the information system because we didn't want developers to write XPath queries if they directly interact with MDS4. As you know a very simple resource condition in an info systems query can turn out to be a very long query string when converted into XPath especially XPath 1.1 which is what MDS4 only understands.
This group should probably look into implementing a similar generic Grid info systems client application for all the Grid info systems implementations around the world. Since the plan is to use the GLUE schema, there won't be any issues with specifying a standard query language that users can use with this client. The client will need to be able to query a "registry of endpoints" service to get information about the endpoint, query implementation (eg. wsrf/mds4, mds2, etc), and the query language (xpath, xquery, ldap, sql) to use for the info systems. The client will be the one in charge of transforming the user's query into the respective query languages used by the different Grid information systems implementations. I think we'll get a quicker response if we query the "registry of endpoints" service than the top level information system which indexes all the Grid resource information around the world.
Our application can only handle a very simple query at the moment. See link below..
https://www.grid.apac.edu.au/repository/svn/infosystems/GlueSchemaQueryLib/R...
< https://www.grid.apac.edu.au/repository/svn/infosystems/GlueSchemaQueryLib/R...
but we have plans of extending the language later on to support queries like "(Site.Latitude > 0 and Site.Latitude < 50)". Composing a query for the GLUE schema shouldn't be that hard. The only thing which makes the query complicated is the language we use in querying the Grid info systems.
I'm just not sure if what we are implementing is something you would want to look into.
Regards, Gerson
On 8/4/07, *Andreas Savva* <andreas.savva@jp.fujitsu.com <mailto:andreas.savva@jp.fujitsu.com>> wrote:
The presentation Ravi is referring to is https://forge.gridforum.org/sf/go/doc14456?nav=1 <https://forge.gridforum.org/sf/go/doc14456?nav=1>
Subramaniam, Ravi wrote: > Hi Hiro/Felix, > > Currently the examples in the document are from "academia" (not that I > am against that as most who know me will attest) but in the spirit of > including enterprise examples would it make sense to include the > implementation that I presented at the OGSA F2F in Manchester as an > example for the enterprise case? > > Ravi > > -----Original Message----- > From: ogsa-wg-bounces@ogf.org <mailto:ogsa-wg-bounces@ogf.org> [mailto:ogsa-wg-bounces@ogf.org <mailto:ogsa-wg-bounces@ogf.org>] On Behalf > Of Hiro Kishimoto > Sent: Wednesday, August 01, 2007 2:49 PM > To: ogsa-wg > Cc: glue-wg@ogf.org <mailto:glue-wg@ogf.org> > Subject: Re: [ogsa-wg] OGSA Information Services > > Hi all, > > Per Felix's request, I've upload revised draft onto the GridForge. > > https://forge.gridforum.org/sf/go/doc14692 > > We will discuss it at Thursday's call. > > Thanks, > ---- > Hiro Kishimoto > > -------- Original Message -------- > Subject: Re:[ogsa-wg] OGSA Information Services > From: Hiro Kishimoto < hiro.kishimoto@jp.fujitsu.com <mailto:hiro.kishimoto@jp.fujitsu.com> > > To: ogsa-wg <ogsa-wg@ogf.org <mailto:ogsa-wg@ogf.org>> > Cc: felix.ehm@cern.ch <mailto:felix.ehm@cern.ch> > Date: 2007/07/26 12:55 > >> Hi all, >> >> Discussion material for Information Services by Laurence Field and >> Felix Ehm is now on the GridForge. >> >> https://forge.gridforum.org/sf/go/doc14692 <https://forge.gridforum.org/sf/go/doc14692> >> >> > This document covers the problem description, experience in GIN, > > >> overview of existing systems, generalized system and suggested > >> areas for standardization. >> >> Please have a look before the call today. >> >> Felix Ehm will lead the discussion. >> >> Thanks, >> ---- >> Hiro Kishimoto >> >> >> -- >> ogsa-wg mailing list >> ogsa-wg@ogf.org <mailto:ogsa-wg@ogf.org> >> http://www.ogf.org/mailman/listinfo/ogsa-wg <http://www.ogf.org/mailman/listinfo/ogsa-wg> >> >> > > -- > ogsa-wg mailing list > ogsa-wg@ogf.org <mailto:ogsa-wg@ogf.org> > http://www.ogf.org/mailman/listinfo/ogsa-wg <http://www.ogf.org/mailman/listinfo/ogsa-wg> > _______________________________________________ > glue-wg mailing list > glue-wg@ogf.org <mailto:glue-wg@ogf.org> > http://www.ogf.org/mailman/listinfo/glue-wg <http://www.ogf.org/mailman/listinfo/glue-wg>
_______________________________________________ glue-wg mailing list glue-wg@ogf.org <mailto:glue-wg@ogf.org> http://www.ogf.org/mailman/listinfo/glue-wg <http://www.ogf.org/mailman/listinfo/glue-wg>
------------------------------------------------------------------------
_______________________________________________ glue-wg mailing list glue-wg@ogf.org http://www.ogf.org/mailman/listinfo/glue-wg
Subramaniam, Ravi wrote:
Currently the examples in the document are from "academia" (not that I am against that as most who know me will attest) but in the spirit of including enterprise examples would it make sense to include the implementation that I presented at the OGSA F2F in Manchester as an example for the enterprise case?
Speaking for myself, I think that would be a superb contribution. Donal.
Hello Ravi,
Currently the examples in the document are from "academia" (not that I am against that as most who know me will attest) but in the spirit of including enterprise examples would it make sense to include the implementation that I presented at the OGSA F2F in Manchester as an example for the enterprise case?
Yes, I also welcome this idea. Would you like to edit it by yourself and announce whenever it is uploaded ? Felix -----Original Message----- From: ogsa-wg-bounces@ogf.org [mailto:ogsa-wg-bounces@ogf.org] On Behalf Of Donal K. Fellows Sent: Montag, 6. August 2007 09:53 To: Subramaniam, Ravi Cc: glue-wg@ogf.org; ogsa-wg Subject: Re: [ogsa-wg] OGSA Information Services Subramaniam, Ravi wrote:
Currently the examples in the document are from "academia" (not that I am against that as most who know me will attest) but in the spirit of including enterprise examples would it make sense to include the implementation that I presented at the OGSA F2F in Manchester as an example for the enterprise case?
Speaking for myself, I think that would be a superb contribution. Donal. -- ogsa-wg mailing list ogsa-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-wg
participants (10)
-
Andreas Savva -
Donal K. Fellows -
Felix Ehm -
Felix Nikolaus Ehm -
Gerson Galang -
guru prasad -
Hiro Kishimoto -
Laurence Field -
Omer F. Rana -
Subramaniam, Ravi