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.