10:30am PDT 15 Aug 2007
OGSA Info services

Laurence Field (CERN) leading on phone

Same in-person attendees as last session.

On phone:
Morris Riedel (FZJ, Germany)
Shiraz Memon (FZJ, Germany)
Adrian Toth (Univ of Miskolc)

- Any feedback on the recent document?
  . interface, language, schema are needed for IS
  . schema/info model appears to be taken care of by GLUE
  . OGSA are willing to use XQuery as language
  . interface needs to be compatible with these two
 
  . but are the GIN members willing to use XQuery? Perhaps not;
    agreed to disagree at meeting in Copenhagen last December.
    Other possibilities mentioned: SQL, CIM query langauge, XPath, LDAP ...
  . OGSA-DAI is likely too slow over large result sets to be considered
  . JSDL session at OGF20 had experience presentations with XQuery; it
    is being used in production at Intel.

  . "Performance is always a concern."

Donal points out that performance is not the first thing to deal with,
but rather having information in the system...

Is there a proposed alternative to XQuery? Not at the moment. SQL
seems like a possibility, since it's known to scale well. Since
the GLUE schema is likely to be an extension to CIM, the CIM
query language is worth looking at.

The problem with using an underlying RDBMS is that it will be difficult
to track a schema as it changes - and the expectation is that the
schema will change fairly often. It seems that using XML query mechanisms
will make this easier ... but unclear about the performance here, as well.

OGSA base profile already defines a query interface for this system
(XPath). Could define the entire info database as a single large
resource and then query it...

Is WS-DAI a possibility here?

- how do we formulate the query?
- how do we return the result?

Expect that this will be front-ended to a relational database ... what
does that imply for this?

Have we considered INFOD? L. says that his reading of the document is that
it's all about the registry, not the interface between producer and
consumer. Chris will try to clear this up a bit; he asserts that the
p/c relationship is also defined.

Focus is really on use cases around packaging/revealing services that are
offered from a data center to multi-institutional organizations. Hiro
asserts that the data center problem should/could be a subset of this.
L. says that the data center should be solved by DMTF's Web-M (?).

Getting ahead of ourselves...
Should separate requirement/functionality/implementation.

So, is the requirement set for data center a proper subset of the
multi-institutional org problem?

L. believes that DMTF is the standard for the data center and should
work. Dave says it doesn't scale to today's data centers or deal with
the current levels of heterogeneity. Can we/they fix the scale
problems? Not clear that it will happen in a short enough time frame
... they are looking to use new technologies, including grid concepts.

Are these issues written about?
Fred will ask SNIA/Hitachi people to get examples of the scale issues.

Concern about returning and processing the large result sets. Dave believes
that WS-DAI should have a reasonable approach. Belief is that Naregi is
using DAI, but they are having scale issues.

... agree to disagree on language for now, agree that there is an issue about
moving large result set (which implies that we can't agree on XQuery
until we come up with a mechanism for moving a large result set).

Can we move on to look at the service interfaces above these issues? Try
to do something that is agnostic to the query language, in particular.

Where do we go from here? Hiro wants us to take a good look at enterprise
data center use case requirements, and will provide them.

----

Actions:

- Chris to try to matchmake between INFOD and Laurence
- Fred to ask SNIA/Hitachi about documented examples of scale issues with
current DMTF (Web-M) techniques.
- Laurence to look at what WS-DAI provides to manage large result sets.
- Hiro to provide enterprise data center use case requirements.