This is a static archive of the previous Open Grid Forum GridForge content management system saved from host forge.ogf.org file /sf/tracker/do/viewArtifact/projects.gin/tracker.draftplans2006/artf2009?nav=1&selectedTab=comments at Sun, 06 Nov 2022 19:31:45 GMT SourceForge : artf2009: (1719) Resource Information Schema and Services

Project Home

Tracker

Documents

Tasks

Source Code

Discussions

File Releases

Wiki

Project Admin
Search Tracker
Project: GIN-CG     Trackers > DraftPlans2006 > View Artifact
Artifact artf2009 : (1719) Resource Information Schema and Services
Tracker: DraftPlans2006
Title: (1719) Resource Information Schema and Services
Description:
In order for users to identify appropriate resources within a Grid infrastructure there must be some form of resource 
information, provided through standard schema and with standard query mechanisms. Many (if not most) production grid 
projects today in the science and engineering community use some form of the GLUE schema for historical reasons, however
 CIM is widely adopted within industry as a standard system resource schema, and the organization developing CIM (DMTF) 
is starting to work closely with the Grid community through its alliance with GGF. NAREGI has experience extending the 
CIM schema to be applicable to Grids, as well as building an actual distributed information system for grids that can 
collect information from the information providers, perform translation and store the information into the CIM database,
 and allow the clients to query the info using the extended CIM schema and the OGSA-DAI service API. A separate activity
, primarily in the UK with the UniGridS project, has been looking at the commonalities as well as the differences 
between Glue and CIM, including possible mappings between them.  .
Submitted By: Charlie Catlett
Submitted On: 01/13/2006 12:29 PM EST
Last Modified: 02/19/2006 9:29 PM EST

Status / Comments Change Log Associations Attachments (6)  
Status  
Group: *
Status:* Open
Category: *
Customer: *
Priority: * 2
Assigned To: * Satoshi Matsuoka
Reported in Release: *
Fixed in Release: *
Estimated Hours: * 0
Actual Hours: * 0
Comments
Satoshi Matsuoka: 02/19/2006 9:29 PM EST
  Comment:
Posting the tentative GLUE-CIM Schema mapping chart by Yuji Saeki @ NAREGI. The blue letters indicate the NAREGI extensions to the CIM schema. As such
 it does not make full  sense until we publish the NAREGI's CIM extension schema document for Grids, which is in the works and will be published this 
Spring, 2006. In the mean time though people can still observe the mapping as the field names are pretty much self-evident.
  Action: Update
Satoshi Matsuoka: 02/19/2006 9:29 PM EST
  Attachment: Glue-CIMmapping_NRG.xls (59.5 KB)
  Action: Update
File added set to 755: Glue-CIMmapping_NRG.xls
Satoshi Matsuoka: 02/14/2006 12:43 PM EST
  Comment:
Posting today's summary discussions
  Action: Update
Satoshi Matsuoka: 02/14/2006 12:43 PM EST
  Attachment: MGIFurtherStepsGGF16.ppt (37.5 KB)
  Action: Update
File added set to 751: MGIFurtherStepsGGF16.ppt
Satoshi Matsuoka: 02/14/2006 12:33 PM EST
  Comment:
Here is the GLUE-CIM translation matrix. Colors indicate some properties that are our NAREGI extensions to CIM.
  Action: Update
Satoshi Matsuoka: 02/14/2006 12:33 PM EST
  Attachment: MultiGrid-Interop-Areas.xls (18 KB)
  Action: Update
File Deleted changed from 748: MGinterOp_Info02.ppt to none (no value)
File added set to 750: MultiGrid-Interop-Areas.xls
Satoshi Matsuoka: 02/14/2006 12:31 PM EST
  Comment:
I am posting the slide presentation for info service I used for GGF16. It incorporates various suggestions by Laura and Yuuji, and Jenny.
  Action: Update
Satoshi Matsuoka: 02/14/2006 12:31 PM EST
  Attachment: MGinterOp_Info02.ppt (399 KB)
  Action: Update
File added set to 749: MGinterOp_Info02.ppt
Satoshi Matsuoka: 02/14/2006 12:31 PM EST
  Comment:
I am posting the slide presentation for info service I used for GGF16. It incorporates various suggestions by Laura and Yuuji, and Jenny.
  Action: Update
Satoshi Matsuoka: 02/14/2006 12:31 PM EST
  Action: Update
File added set to 748: MGinterOp_Info02.ppt
Laura Pearlman: 02/13/2006 6:06 AM EST
  Comment:
I've started a matrix of schemas, access managers, etc., with some cursory sample data, at "http://www.isi.edu/~laura/multigrid/matrices.html".
  Action: Update
Satoshi Matsuoka: 02/08/2006 12:50 PM EST
  Comment:
FYI, I have put the master slide on NAREGI adoption of GGF and other standards. It does not merely focus on information systems, but rather on the 
entire software stack, but should be useful for discussions for this thread as well as others. A greatly stripped down version of this document will 
be presented as a keynote co-presented with Dave Snelling on Thursday.
  Action: Update
Satoshi Matsuoka: 02/08/2006 12:50 PM EST
  Attachment: NAREGI-standards-present-GGF16-draft4.zip (1.59 MB)
  Action: Update
File added set to 734: NAREGI-standards-present-GGF16-draft4.zip
Priority changed from 3 to 2
Satoshi Matsuoka: 02/08/2006 12:30 PM EST
  Comment:
Quite in agreement with your last comment, Laura. It should serve as a basis of discussion.

Regarding OGSA-DAI and query language comparison, that is another valid activity. Having said that I believe query into CIM DB using SQL is quite 
commonplace, and OGSA-DAI merely serves as a web service that provides remote SQL capability. The difference in the query style rather stems from how 
the underlying schema is stored and represented, as fairly rigourous CIM schema in a DB, or say in a mo more "loose" fashion using LDAP. 

Both are used in the industry today in a rather interoperable fashion depending on its usage. Even within NAREGI personal account information is 
stored in LDAP provided by NAREGI CA, whereas the accounting information is stored in the CIM DB in the information service for the beta 1.
  Action: Update
Satoshi Matsuoka: 02/08/2006 12:30 PM EST
  Action: Update
Priority changed from - to 3
Laura Pearlman: 01/27/2006 3:54 PM EST
  Comment:
Regarding Charlie's questions and Satoshi's comments on MDS4 -- the MDS4 services will accept and manage any XML-formatted data and does not require 
any particular schema.  A typical MDS4 index out of the box today includes GLUE schema information reported by GRAM along with data in other schemas 
reported by other services.  It's not clear to me that all this data would necessarily fit into the CIM schema (for example, the RFT data includes 
some specifics about the number of transfers completed, the number of bytes transferred, etc.).  MDS4 has some issues with performance on large 
databases. but improving scalability is a high priority for the MDS group.

I think it's important that whatever solution the interop group comes up with allows for management of data about many types of resources and services
, and that it be flexible enough to make it easy to add information about new types of resources and services.
  Action: Update
Laura Pearlman: 01/27/2006 3:33 PM EST
  Comment:
To me, intuitively, it seems like a good initial approach would be to identify the things that need to interoperate with each other (for example, 
services like MDS2 or BDII which use information represented in LDIF format served using LDAP protocols need to talk to services like MDS4 or Clarens 
which use information represented in XML format served using WSRF protocols, VOs which use GLUE schema need to talk to VOs which use CIM, etc.), fill 
in a little matrix to see which combinations are actually used, and then identify and implement a small set of gateway services (probably implemented 
by creating providers for existing information systems services) that can be chained together to enable these systems to talk to each other. 

One thing that concerns me with the draft is that it recommends a query language (SQL) and a service interface (OGSA-DAI) without any real comparison 
of those with query languages (e.g., XPath, LDAP)  and service interfaces (e.g., LDAP, WSRF resource property queries) that are in use today.
  Action: Update
Charlie Catlett: 01/25/2006 10:29 AM EST
  Comment:
Putting a preliminary email discussion into tracker w/ Satoshi's permission-

On Tue, 24 Jan 2006 11:29:18 -0600
Catlett-> 
This paper does a good job giving an overview, but I still not entirely clear on the steps or timing toward low-hanging fruit next steps for 
production Grids.  

Matsuoka->
Agreed. The paper was meant as more of a position statement from NAREGI rather than a impartial status quo document. Nevertheless I felt it was a good
 starters for getting comments. We do need an alternative document structure to gather status quo of each major infrastructure. I will work on a 
revised structure over the next few days.

Catlett-> 
The paper mentions that NAREGI will do some work in 2006 but it is not clear when in 2006 or what will be the status of the work for production use.

Matsuoka->
The delivery is May 2006. It will be in beta in terms of being "product level" by enterprise-class standards (which may be interpreted as being 
production level in terms of most open source software).

Catlett-> 
I like the approach outlined, but given it has been almost 4 years since the GLUE work started, it would not be unreasonable to think that it will 
take a while for the CIM/GLUE work to mature. In the meantime, is there not a subset of GLUE that multiple grids  could support in early 2006, given 
so many Grids report that they use GLUE?

Matsuoka->
Here are the pros and cons, sprinkled by a little bit of fear scenarios:

=======
Pros for maintaining GLUE:

- That GLUE embodies 4 years of experiences and knowledge that has been accumulated for grid operations, and might contain info pertinent to grid not 
otherwise described in other resource schemas (like CIM).

- It is in use by major grid infrastructures such as OSG and LCG.

- There are production-level grid information systems such as R-GMA that spits out GLUE-compliant information.

- Others?

======

- The entire server and services industry, incl. Web Services, IBM,
Microsoft, etc., are set on CIM as the interoperable standard. The
Windows registry is based on CIM. Thus, one fear scenario is that the grid community will be alienated from the larger IT industry.

- GLUE does not have a developed schema for integration of lower-level, detailed resource information that may be necessary for other purposes  (such 
as remote maintenance) which are present in CIM.

- There is a lack of industry-level tools for information manipulation.
This is akin to the OGSI vs. pure Web Services model (which lead to OGSI to WSRF changeover "event").

- Others?

=======

Matsuoka->
(Below should be recorded in a more impartial, project-centric view portion of the document).

Now, personally speaking, I believe that much of the GLUE vs. CIM feature comparison was technically valuable but somewhat lacked substance, because 
of the unavailability of "grid-enabled" information and monitoring services, whereas GLUE had stuff in operation. However, this may be changing 
because such implementations of systems will be appearing on the CIM side (NAREGI for one, but probably more from the industry side if they are really
 serious). 

So, if the GLUE folks think that the industry at large will move towards
GLUE, it is not going to happen, ever, since there is so much commitment into CIM in the industry, esp. DMTF. I find this synonymous to the situation 
where HEPNET ran its private protocols (DECNET), claimed that they need to sustain that because they were too busy, until they finally "succumbed" to 
TCP/IP.

So, I believe the most profitable course of action is really to 

(1) see how the GLUE knowledge can be transferred to CIM, and
(2) build systems where they could be interoperable in the interim

That is to say, we really need to separate the issue of schema consolidation versus the actual systems. (2) is more easily achievable than (1), since 
if the schema could be preserved for GLUE, then the clients may really not see the difference. In that regard, we concluded that, NAREGI could 
accommodate GLUE in its information services as a proprietary extension to CIM.


Catlett-> 
Or is there a simple way to use the GT4 information services (i.e. is there a simple schema or are these really just blank slates into which you pour 
things like your implementation of GLUE or CIM)?

Matsuoka->
My observation is that GT4 is fairly schema-less, and its information service is more fine-grained, i.e., good for keeping smaller amounts of data but
 not equipped to handle large information schema. In that regard say NAREGI-IS and GT4 information are complimentary, and the latter can be a 
information provider for the former.
  Action: Update
Charlie Catlett: 01/25/2006 10:16 AM EST
  Comment:
Upload draft from Satoshi Matsuoka and Yuji Saeki
  Action: Update
Charlie Catlett: 01/25/2006 10:16 AM EST
  Attachment: info-services-interop.rtf (476.04 KB)
  Action: Update
File added set to 728: info-services-interop.rtf
Charlie Catlett: 01/13/2006 12:56 PM EST
  Action: Update
assigned_to changed from 100 to 130
Charlie Catlett: 01/13/2006 12:29 PM EST
  Action: Create


 
 


The Open Grid Forum Contact Webmaster | Report a problem | GridForge Help
This is a static archive of the previous Open Grid Forum GridForge content management system saved from host forge.ogf.org file /sf/tracker/do/viewArtifact/projects.gin/tracker.draftplans2006/artf2009?nav=1&selectedTab=comments at Sun, 06 Nov 2022 19:31:45 GMT