GGF 11 - 08/06/04 - DAIS Session 3: Related Standard and Activities =================================================================== Chair: Dave Pearson Note Taker: Mario Antonioletti Dave Pearson opens the session. Agenda for this session: 1. Relationship to other Standards: Brian Collins 2. Data Services Document - Issues and Plans: Allen Luniewski 3. Object Database Services: Norman Paton ---- 1. Relationship to other Standards: Brian Collins Presentation at: http://forge.gridforum.org/projects/dais-wg/document/GGF11-DAIS3-Relationships/en/1 Brian starts the presentation with some holiday snaps. Did some work as part of the DAIS spec writing team to try and familiarise myself with the related standard to the work that DAIS is trying to do. ... DAIS produced a scenarios document that was given to CIM. CGS is the prime interface to CIM in the DMTF. This in turn feed back through WS-Policy to the graap WG at GGF who are producing WS-Agreement. WS-Policy and WS-Addressing are not in a standard body. The CIM database document is an inputs to the web services distributed management effort ... Data management is out of scope for DAIS. DMTF introduce MOWS - Management of web services and MUWS Management Using Web Services which will provide input to the DAIS specs. In the GGF data area there are quite a lot of groups that are of relevance to DAIS. OREP does not do replication it does replication catalogues but Infod could be used as a mechanism to do this. At the previous infod WG meeting it became clear that data movement does not currently appear to be a home. Malcolm Atkinson: you could use the WS-Notification to do data movement ... Is it a could or a should? Malcolm: it was a could ... the thinking in the WS-Notification TC is that it should be capable of doing serious large data transmission ... whether it will be retained and propagated to implementation remains to be seen ... Dave Pearson: the point was that WS-Notification was unsuitable ... infod is looking at how notification models could be extended. Malcolm: the biggest difference between WS-Notification is that it has a reasonably simple language while infod will probably have a full query language. Question whether GIR is really about collection of files. The point is that we are not always clear as to what some of the GGF groups do and whether they have an impact on DAIS. There are a number of people from DAIS liaising with the other working groups. The relationships are not formal but just who might be able to contact to find out who can be asked. Savas Parastatidis: went to the SAGA WG - they want someone to liaise with DAIS ... they are going to develop APIs for application developers .... e.g. submitJob, transferFile ... etc they want to see what people are doing ... they are in the architecture area. Roger Reich: who is the DAIS interface to DMTF? We do that through Larry Flon on the CIM group. Malcolm: I'm on the OGSA data services ... Dave: best thing is to put something out to the list and solicit feedback ... Roger: it might be useful to have pointers back to DAIS ... if we can establish relationships back the way. The action out of this is to publish something out to our mailing list and perhaps to do some targeted mailing list. ------- 2. Data Services Document - Issues and Plans: Allen Luniewski Presentation at: http://forge.gridforum.org/projects/dais-wg/document/GGF11-DAIS3-DataServices/en/1 The purpose of this part of the session is to talk about the OGSA Data Services document. This session is intended to talk about outstanding issues in this document. Will review the open issues and then will open the floor to collect any new issues. The second goal of this session is to capture all the issues that will be addressed for a revision of this document for GGF12. In the current draft of the document still need: - ResourceProperties elements to be defined - DataAccess operations to be defined - DataFactory operations to be defined - Data Management operations to be defined that are common across all data services. Susan Malaika: are not these things that should be in the DAIS core document? That could well be true ... don't have strong issues. Ten issues have been captured up to now. 1. Move design principles from the base document to data services document. Malcolm Atkinson: Metadata level issue - does it make sense to have an OGSA data service specification and a DAIS specification? I feel it makes it harder for people that are tying to implement things - it's also harder to keep the documents consistency. Susan: like data management? Malcolm: yes ... things keep on splitting ... they will not converge if they keep on splitting. Norman Paton: one of the objections is that a specification is quite a terse document ... the OGSA data services is more discursive Malcolm: I think that that is now being done by the OGSA Data Architecture group ... Norman: I think that that is a good point ... Malcolm: have pointed this out to the OGSA data architecture people ... need to get the two groups together and sort this out ... Susan: this has been discussed in the telcons ... the OGSA effort would identify components and not the interfaces ... Norman: the OGSA Data Service document does have different aspects ... characterises behaviour .... what it doesn't do is define the services and their inter-relationships. Malcolm: people in the OGSA Data Architecture space want to describe these services more which starts eating into this space... Norman: interesting thought that the way you think about this material that it could migrate to the data service architecture ... need to digest this. Allen: need to see what the bounds of the data architecture effort are ... we need to resolve this sooner rather than later ... the design team is also supposed to be a short term thing ... this could be a debate that could be had at the f2f later on this month. 2. Using EPRs to denote replicas Dave Pearson: there is a lot of communications in the OASIS mailing list about EPRs .. Malcolm: this came up this morning in the WSRF session ... Dave: give that there is a lot of discussion is this something that we should examine... Malcolm: the WSRF community have postponed discussion on WS-Addressing until November ... Allen: the issue that given 2 services what is the identity of the underlying resource that is being used ... ... Savas Parastatidis: the spec states explicitly that you should not exploit the properties of the EPR Malcolm: this is what I said ... Allen: this is not a question of how the client uses the EPR but how the service uses that field. Malcolm: a standard though will not specify how the implementation will do things Savas: data services are allowed to look at the resource properties of its own EPR but not to the reference properties of another EPR ... even if it's a replica ... Allen: it's a replica owned by another data service Savas: where does the EPR point to - the data or a data service? ... so the EPR does not only point to a data service but to a resource that points to data Norman: if you have replicas there is the thing that you have replicated and the representation of the that resource .... Malcolm: I don't understand this issue as if you have a single WS that is representing a resource in which case it's its own business or whether you are building replicas using different WSs. Savas: there is an issue with the latter case ... if you start having replicas ... Malcolm: then you will require what Peter Kunszt described as a grid data handle... someone has to worry about this Dave: have an interesting discussion ... do we have a decision? Norman: the data services document talked about a functionality but when you start moving from that you start into run into all sorts of architectural issues ... Malcolm: at the OGSA data service meeting this was pushed into the naming scheme ... the architectural document can say those things ... ... I think that you should push this out from here .. 3. DS placement manager vs other placement services. Malcolm: again this is an implementation detail as we are only concerned with the message patterns. I agree. Malcolm: in motivational discussions you might discuss these things. 4. Naming of data services? Savas: do you name services or the data? Services Malcolm: in which case this is out of scope. 5. third party data delivery vs workflow services. Norman: if we thing that something should be thrown out we should minute this and then post this to the list. The people that brought the issues up can then have a chance to come back if they think this decision is incorrect. Malcolm: this is a good question in that someone should discuss it but it should be at the OGSA level This should be thrown to the OGSA data architecture level. 6. Clarification of management interface Talked about this earlier today. The management interface is discussed very loosely - it needs to be clarified and its bounds defined ... are you managing the service, the resource ... Malcolm: depends on whether the data service is offering such interfaces .. have not re-read the document ... I never understood what they meant by virtualisation... Have tried to clarify that with Inderpal. Malcolm: have not read your modifications yet ... ... Dave: there is management between the service and the resource ... Malcolm: interesting to note whether this is mandatory or ... and whether this to be supported by all web services. 7. Data description interfaces: needed wsrf? Removed this interface with the introduction of WSRF ... some people were unhappy with this decision at GGF10. Malcolm: we could keep an SDE like interface ... we can keep our own interfaces ... we will have interfaces that other people will not have but there is no way that we would not want to mandate an additional interface. My gut feeling agrees with you ... Malcolm: goes back to Brian's talk as things like this will be coming up in DMTF ... they will be doing this kind of thing and we don't want to replicate that ... we may want to pass them requirements ... Norman: in the original OGSA Data Services document there were a lot of fine grained properties then, as you have a different portType in WSRF to access such properties, the data description port type became unnecessary ... in the core spec we've said that it is still useful to talk about data description but not necessarily expressing it as a portType ... one describes the data and another the behavioural description ... we have to be careful that we are not dealing with a red herring ... this arose because of a quirk ... if there continues to be an OGSA Data Service document there is an issue as to what the top level headings in the document are ... previously these were coupled to portTypes ... in the specs we have kept the top level headings but have not necessarily associated these with a portType ... Behaviour and informational properties are describing properties of the data service ... these are properties are associated with access methods of the data service ... Susan: the behavioural ones ... the informational one describe the data. Malcolm: we have to describe the data that a service will deliver but we do not need to discuss the interfaces that will deliver that data ... clearly this is not specific to data services. Susan: ok to have a heading called data description ... Malcolm: yes, but it does not have to appear here... this goes higher up... the interface is being dealt with elsewhere wsrf 8. Factory interface - should not be an interface Malcolm: but there is a factory pattern ... suppose if I'm about to generate lots of data ... I want to run my workflow to create a resource that will hold that data so we need a factory pattern the issue is whether we need to state that ... Malcolm: you don't need to as this is stated elsewhere. 9. Relationship of data services to other grid services 10. Clarify: not all data related services are data services Malcolm: have been pushing for that ... have been trying to get the WSRF people to say the same thing ... yep. Malcolm: when I talked yesterday I produced things I thought that were still issues in the data part of OGSA ... we should look at these things in this context or in the OGSA architecture ... will send these out ... How do we go on? Now have an issue regarding its relationship to the OGSA data architecture ... however if the document has a future I would like to have all future work completed, all known open issues resolved, compatible with the work going on in the OGSA data architecture effort. Issues have been posted on grid forge and have not had any feedback ... Malcolm: hard to work in the OGSA data service document and the architecture document as there is so much overlap ... Dave: there might be a consensus in this room but need to ask ... what do the other authors say? Have had no reply. Malcolm: could partition it so that bits go into the architecture document and other bits go into the DAIS core document... Norman: I think that is a fair way to proceed ... it should be rolled into the new effort that is taking the place Mario: what's the process? Dave: look at the document again in the context of the core spec and the OGSA Data Services spec to see which part of the document goes into which... Norman: the reference in the core spec can become references to the OGSA data architecture document and definitions made explicitly in the core document as opposed to referencing the OGSA Data Services document. Malcolm: the OGSA Data Architecture document is not going to be terse. Norman: to take Susan's point if we have a non normative in the DAIS context then this is not the most helpful document to have ... we'll have a primer instead ... ---- 3.Object Database Services: Norman Paton Presentation at: http://forge.gridforum.org/projects/dais-wg/document/GGF11-DAIS3-OO-Realisation/en/1 Have had some folks that expressed an interest in producing an OO database realisation. Two persons expressed an interest in taking this forward at GGF10. Have had one telcon which brought one additional person up. Meant to have another telcon but this did not happen for a variety of reasons. Some issues are outlined in the slides. JDOQL - a query is represented as a Java object ... in a web services world cannot pass a Java objects around so need to find a way of expressing this as a query. This is not yet part of the DAIS charter. Hope to identify additional participants ... getting close to the level of representation to trigger something off in DAIS. Malcolm: I don't know how big a community there is out there that wants to use this but there is a large community wants to use relational and xml ... this may have delaying effect on the task of finishing the relational and xml specs ... has anyone done an assessment on how it will affect our delivery dates? We have not addressed the question as to how it might impact on the rest of the community and the it is true that the likely usage of such a realisation is going to be smaller. Should be logged as an issue and we should try to answer this. Dave: unless people come forward it's not going on to happen ... Charlie: the object access paradigm applies to more than just OO databases ... we have a product that does this kind of thing ... if you just pass SQL around then the tooling has to describe this ... not just OO databases but OO queries and other such types of queries... We chatted about these things at our telcon but we have not chatted round this ... going to ask for volunteers ... the issue was flagged but has not been resolved. Malcolm: at our [OGSA-DAI] user group meeting was files and access to the content of files ... if it takes us resources and if these resources are in competition then we should give more priority to files. Charlie: the notion of disconnected data sets ... is relevant for xml data sets when a resource coughs up data sets ... the ability to work on those result sets and stream them back to the original resource and reconcile these things back together ... is any assumption made about connectedness? No. Charlie: there are the cursor things ... You behave properties that reflect this ... sensitivity ... this does not require you to be connected. You also brought up a use case we have not explicit use case that we have not considered ... you have a data set you manage it and then you pass it on .... Dave: we would welcome a short note describing that use case. ----