[dais-wg] Telcon Minutes from 14/06/05

[Mario Antonioletti]

DAIS Telcon Minutes - 14/06/05
==============================

Notes: Mario Antonioletti
Chair: Norman Paton

Attendees:

 	Norman Paton, University of Manchester
         Mario Antonioletti, EPCC
 	Susan Malaika, IBM
 	Dave Pearson, Oracle
 	Allen Luniewski, IBM
 	Amy Krause, EPCC


Agenda:

  o Finalise Session Contributions for GGF14

+--


A number of things to discuss at the meeting were proposed by Susan
Malaika (numbered items):

0. The role of the conduit when sending messages to Type 2 and Type 3
    resources.

Simon: was not at GGF13 so my understanding was derived from notes and
        conversations from that meeting- had a model where you had to
        identify the conduit which gave a context to those
        messages. That was the model.

        Have seen emails where people say that it is independent
        and that you do not identify the conduit.

Susan: did you see it as a JDBC connection?

Simon: saw it as a fundamental set of properties that allowed you
        to access these resources ...

Norman: the answer is no as JDBC cannot be used to tell you the
 	properties of multiple resources and cannot be shared.

Dave: I remember things differently from GGF - we are passing messages
       to data resources - only passing a string to access data in a
       table and then Jay Unger or Dave Snelling said that the DBMS is
       just serving as a conduit.

Susan: yes, you are right, we are just passing a string which we do
        not want to parse ... people were telling us that we had to
        make tables and resources and visible ... we were trying to
        explain that we were not going to do that ... it does not
        matter how it came about ...

Dave: I think it does ... the conduit did not have a great deal
       of significance - just used to pass a string to a DBMS.
       Conversation went on from there - accessing tables and
       results are not first class citizens but the DBMS is...

Susan: the conduit was WSRFish thing ...

Dave: yes, the conduit was justified to use WSRF ... while
       we are trying to access data which may lie in a DBMS.
       For a result set there is no conduit as far as I can
       see.

Susan: true that the conduit arose this way ... used the
        concept of connecting to the DBMS and the result
        set ...

Dave: the rational that the result sets in WSRF was not because of the
       conduit but because you have to manage its lifetime.

Susan: that is a good summary of how the conduit came about ... this
        does not mean that this is how it has to be..

Norman: clearly it has evolved into something else - it gives a bit of
 	name and property information that can be accessed through a
 	local service ... this could be a useful thing ... can see
 	what is available. What is it's role when you pass messages of
 	type 2 and 3 resources? Are these messages being sent to the
 	context of the conduit or is it being sent directly to the
 	data resource? If you have several resources then there's
 	something to be said for having the conduit to interpret the
 	name of the resource. Can just say that it's a list of data
 	resource names but then need to ensure that the names are
 	unique within the context of the service...

...

Simon: to a certain extent the conduit is transparent of the WSDL but
        it depends on the mapping and the multiplicities ...  if you
        assume there is only one conduit then you have a list of
        resources within that conduit that you can access ... every
        message you pass to that service is passed in the context of
        the conduit ... if you use a different model with a multiplicity
        them you have a trickier job of having to identify the conduit
        and then you have to pass messages in that context.

Susan: what is bad with just having one?

Simon: nothing, you might want to use the conduit to group names...

Dave: using a stored procedure where you have different results what
       happens?

Simon: they are named within the same context ...

Susan: I thought you said one in one of your emails .... it introduces
         a conduit, a sort of light weight registry, but does not
         necessitate a complex naming scheme over and above the end
         point...

Norman: if you have a large number of resources you may want more than
 	one where you could use to group these names ... can use the
 	name of a conduit to resolve this ... however have not had a
 	need for this functionality.

Simon: when going through the WSDL it provides a convenient bridge in
        going from WSRF to WSI and vice versa but that was not
        requirement driven but implementation driven ...

Dave: part of the discussion in GGF was that in WSRF you got a name
       back then you would need two trips to resolve that name ...

Simon: it depends on the mapping you choose. Can use the conduit to
        alleviate the pain - in WSRF everything is a WS-Resource for a
        non-WSRF can use the conduit for ..??missed this??.. can use
        whatever scheme you want and the conduit remains the same.

        There is a convenience .....

Susan: you said that this would not impact too much in the relational
 	/XML specs ... I think you need to make a statement of what
 	goes in a conduit in these specs...

Norman: you are right ... need to determine what information goes in
 	the conduit ...

Susan: if you take the simplest approach that is the only thing ...

*Norman departs*

Susan: are we ok with one conduit?

Simon: sounds ok to me .... but lets discuss the mapping of type 1 and
        2 resources ... I'd assumed that type 1 and 2 resources are
        identified by name alone...

Susan: for type 2 you are using names ... if anyone implements DAIS
        with minimum overhead and there is no extra support then that
        would be what they would do, just use names ... I think type 2
        would be just names and can decide what to do for type 3 ...

Simon: for type 2 can send names but we are not expecting to control
        the lifetime - so no lifetime messages ....

Susan: correct ...

Simon: what about the parameters of those resource - information about
        its structure ... do we rely on the normal messages or are
        there special messages like in the WSDL? ...

Susan: I would go with what you have in the WSDL...

Simon: in type 3 you control the lifetime and you have properties -
        you can use both approaches ... we need to decide what the
        default mapping is. It's not as if we are going to deal with
        one type of resources ... a service would deal with both types
        of resources ...

Susan: I would have imagined this where you would have a conduit
        connecting to type 2 and 3 ...

Simon: if you go with the naming then you can go with a properties doc
        and need something to describe the lifetime ...

Susan: easy for type 2 as they already have names ...

Simon: for type 3 we can generate names ...

Susan: but then you might need to conform to something ....  we would
        need the things that are in WSRF.

Simon: but if we used WSRF we would get things ... though you would be
        using different properties .... we would want to use the same
        interface for type 2 & 3 for queries ... it does not seem
        useful to use two types of messages if you are controlling the
        lifetime for type 3....

Susan: the goal of type 2 is not to parse the input string but if you
        make them the same you might need to parse ...

Simon: why?

Susan: the implementation is going to have to do something with the
        input ...

Simon: I don't see that ...

Dave: I think that is quite important .. type 3 is really a result set
       ... what are the operations you perform on a result set.

Simon: it depends on the interface you have chosen ...

Dave: I did not think you would query the result set...

Simon: you could if you choose an interface that does this ... not
        saying how you implement it ...

....

Dave: breaking the rationale of the model if we have to parse strings.

Simon: I take the view that you always pass strings ... it's just the
        lifetime ...

        Discussed a couple of options for type 3 resources ... that
        brings you back to the conduit because thinking about the
        properties ... if these resources have their properties
        accessed and you only have one conduit then it has to have a
        view over all the resources it deals with ...

Susan: I never envisaged having the name of resources in the conduit.

Simon: the list in the WSDL has the resource name and is also
        extensible to include properties of the resource ...

Susan: I don't think that is good ...

Simon:the problem is that you can only have one type of resource per
       service ... and you have to choose a resource for the service
       and that is the conduit. The other things cannot be WSRF
       resources ... the good thing about that is that you can assume
       that there is only one conduit - the fact that you have a WSRF
       resource is irrelevant...  it's just like the properties of the
       service .... made the list is extensible ... can use properties
       documents or you can use WSRF messages to retrieve resource
       properties by navigating through the conduit document ... have
       not included this information in the spec ...

Dave: where you use WSRF messages you are getting the properties of
       the conduit?

Simon: but the conduit has the properties of the resources ...

Dave: an abstraction of where you get resources from ...

Simon: with a web services that exposes a number of WS-Resources, in
        WSRF, in reality the Web Service has a collection of
        properties - if you had a message that returns all the
        properties you get all the properties ....  it's just an
        abstraction.

Dave: but other abstractions have relevance in the rest of the world
       while here we are inventing something ... while in other WSRF
       examples they refer to something concrete.

Susan: I think it is a real thing ...

Susan: you can push this model to describe related data resources -
        nothing says that you have to have related resources but if you
        do, you can build collections of associated data that could be
        useful for sessions and transactions - not necessarily related
        to the way things are done in database land but it allows you
        to group data resources...

...

Susan: so there is no role

Simon: allows you to describe the resources that are available.

Susan: but you don't have to if you already know .... so it scopes
        your world ... it's telling you what things you can get to.

Simon: you can generally access a finite number of things you can
        access and this describes what those things are.

The other questions are considered.

1. The conduit and whether to use the term proposed by Paul Watson "Data
    Resource Group"

Susan: leave that one for the minute?

2. What the conduit properties are. If they include the names of the
    Type 2 and Type 3 resources for the realizations then why were the
    diagrams I sent so disturbing :-) Can a Conduit be referred to by
    another conduit?

Susan: the answer is possibly but then it's a matter of implementation
        ...

Simon: in the relational diagram - the table confused me ...

Susan:taking away table ...just the names of things ...
       have been exchanging a lot of emails around....

3. What kinds of names are used where, and which are compulsory?

    - in Conduit
    - in message exchanges for Type 2

    e.g., for relational databases, relational tables, stored
    procedures, relational functions, XML Collections, XML Documents,
    XML Schemas associated with Collections ... (some items in the list
    are potential Type 2)

    - in message exchanges for  Type 3
      e.g., for Rowsets, XML Sequences ...

...

4. What would a conduit look like for an implementation that supports

    Just the conduit
    Type 2 Resources Only (No conduit)
    Type 3 Resources Only (No conduit)
    Type 2 Resources with conduit
    Type 3 Resources with conduit
    Relational and XML together (Type 2 or Type 3) - without conduit

Simon: an implementation that just supports a conduit every time it
 	got a message to do an SQL query it would return an error
 	message stating "don't know any such database".

5. The CIM database working group - and whether someone other than me
    from DAIS should participate as well. There are two ways non-member
    companies can participate One person from GGF (from a non-member
    company) can join a particular working group Any number of people
    from academia can join (there are special joining instructions)

6. The namespace request I sent to the GGF->DMTF liaison and the DMTF ->
    GGF liaison

Susan: leave 5 and 6 for now ... going back to question 2.

Allen: I think group is just a funny term to use ...

Susan: the conduit groups resources ..

...

Dave: the conduit is performing the role of the WS-Resource in WSRF
       ... I don't think that the conduit is a very useful term ....I
       don't like the data resource group. I would suggest resource
       conduit has has more meaning to people.

Susan: we are not doing group ...

Simon: I don't mind using Dave's "resource conduit"  name ...

Susan: have had a similar discussion in the WSRF calls ...  So all we
        have to state in the relational and XML spec is what is in the
        conduit .... don't you have to state what is in there if there
        is a conduit?

Simon: the answer is optionally the document that is returned by the
        get properties message in that realizations....

Susan: should you not say what is in it?

Simon: you cannot explicitly say what is in it as it might be from a
        composition... in the relational the things that are named are
        the database - the target for SQL queries and the result set
        ...

Susan: we need to say ...

Simon: reason for procrastinating over this is that we already have
        the resource name in the core ... this determines what will go
        in the conduit ...

Susan: the resource name is a collection or sequence in the XML spec
        and in the core spec you state what this name is ...

Simon: would be awkward if there were messages targeted at a data
        resource that required several names but was needed to
        disambiguate the target ...  if there is an issue it is an
        interesting point for discussion.

Susan: the resource name of the core has to tie in with the resource
        name of the realizations and we do not have to mention the
        conduit.


*Allen has to leave for another call*

There is a brief discussion of the specs status ... not minuted as I
cannot speak and write at the same time. Try to do a set of documents
for GGF as planned to be ready for this Friday that people can read but 
after that keep evolving the specs.



+-----------------------------------------------------------------------+
|Mario Antonioletti:EPCC,JCMB,The King's Buildings,Edinburgh EH9 3JZ.   |
|Tel:0131 650 5141|mario at epcc.ed.ac.uk|http://www.epcc.ed.ac.uk/~mario/ |
+-----------------------------------------------------------------------+