DAIS Face to Face meeting in Manchester 8 & 9 December 2003 =========================================================== Minutes by Mario Antonioletti (mario@epcc.ed.ac.uk) Attendees: --------- Mario Antonioletti (EPCC), Malcolm Atkinson (NeSC) - attended on day 2, Peter Clarke (UCL), Vija Dialani (University of Southampton), Amy Krause (EPCC), Simon Laws (IBM), Allen Luniewski (IBM), David Martin (IBM), Savas Parastatidis (Newcaslte) Norman Paton (Manchester University), Dave Pearson (Oracle). Present during telcons (at different points): Ann Chervenak (ISI), Dieter Gawlick (Oracle), Vitthal gogate (IBM), Shailandra Mishra (Oracle), Susan Malaika (IBM), Greg Riccardi (Florida State University) Agenda: ------ Day1: - Data Management: Discussion of Classification and Terminology (Norman Paton) - XML Realisation Issues (Amy Krause) - Grid Data Distribution (Shailandra Mishra) Day 2: - Web and Grid Services - Impact on DAIS Specification (Savas Parastatidis) - Discussion on terms (as used in the context of WS-Agreement) (Simon Laws) - Planning (Norman Paton) - Relational Issues (Susan Malaika) Copies of the Presentations are/will be available from Grid Forge: Documents->Face-to-face Meetings/Manchester-Dec03 Actions Arising from Meeting: ---------------------------- [Norman Paton] Update the management slides in view of the discussion that has taken place at the f2f. Once posted will flag a request for volunteers from different vendors to take the token. [Amy Krause + Susan Malaika + Simon Laws] Construct a message to send to the list describing the options regarding the use of the OGSI extensibility pattern for parameters and return types to deal with the appearance of the same SDES across multiple portTypes. [Simon Laws] Look at WS-Policy to see what its status is and what the IP is. [GDD Authors] Given that the principle means of the GDD is through an evolving informational document. This document should have a section that addresses its relation to publish/subscribe and other relevant groups/work going on in this area. [Simon Laws] Start and lead a discussion on terms that DAIS should be using. [Mario Antonioletti] Put a link in grid forge to the DAIS charter - consider adding trackers for each of the DAIS milestones. [Norman Paton & Dave Pearson] Invesitage whether dial-in access is going to be provided for the next face-to-face. =========================================================================== Day 1 =========================================================================== Topics discussed:- - Data Management: Discussion of Classification and Terminology (Norman Paton) - XML Realisation Issues (Amy Krause) - Grid Data Distribution (Shailandra Mishra) Program from that originally posted changed as Shailandra Mishra (Oracle) was unable to get a visa in time to attend the f2f. Topic: Data Management ---------------------- Norman gives a presentation on the use and definitions of the Management interface as presented in the OGSA Data Services document. Unattributed statements made in this section can (mostly) be inferred to have originated from Norman. The OGSA Data Services document at present is not entirely clear on management. The third slide presented shows a resource manager which is taken to mean the data service implementation. Savas: why is a "resource manager" not just called a "data service implementation"? The Resource Manager is introducing a new term which is not helpful. It is also pointed out that the third slide also seems to infer that a data service could reprsent more than one data source. Currently there is a task to delete the V-word (virtualization) from the DataManagement definition. In DAIS we have previously tried to invent things when we should really be reusing - (slide 8) have a DMTF CIM data base model which consists of: Database Systems Common Database Database Services. A file system could fit under "common databases" but there are CIM models that describe file systems. XML DBMS would fit better in this categorization. David: It's a UML model but is not object orientated. If you take database service from the CIM model then some of the terms are subsumed by the OGSI SDEs but there are other things that do not fit in this category (see slide 16): e.g. OperationalStatus, LastStatusChangeTime, ... Management of the data source - the underlying artifact - (still slide 16) some of these are defined in the database system of the CIM database model: - PrimaryOwnerName - OperationalStatus - InstalledDate Allen: does that mean you are going to be presciptive if you use the CIM model? We can talk about this later on. slide 11. The CIM_DatabaseParameter class provides an abstract model for capturing data source settings. This provides a "get out jail" card. This allows us to capture missing terms. Savas: As there may be multiple data sources under a single resource manager - what was previously referred to in the plural has now changed to the singular. The Data service document assumes that there is a 1-1 relationship so there is a contradiction there. CIM assumes a 1-1 relationship. If there is a 1-many there is a question as to how this is modelled. Can make it many and use a naming scheme. Savas: fine - once you have a naming scheme then you have a "context" that allows you to identify what information should be returned back to the user. The issue I have with the name thing is that the OGSI people will say that it should be a GSH and hence you go back to a 1-1 relationship ... Discovery Link is a federated system that does not expose the underlying data sources. If you were using Oracle you could use something similar. Savas: if you are exposing something then you have to ... You could use a wrapper that allows you to access this ... David: do you want a gsh for each object? ... Savas: for every object you expose you have to provide a gsh and an interface.... that is the OGSI model. David: this does break down if you try to expose a lot of objects ... Dave: ... a distributed query processor may be a better example ... Savas: if you have a file system then every file would need a gsh because every file needs to be accessed across the VO Allen: but that is a choice you make as a data source provider Savas: I agree but if you want to expose something then ... Allen: I disagree .... you do not want to force everything to be a grid service ... Savas: I agree but in this particular service you have to flick a switch to determine which data source you are going to use ... Allen: but you can have a 2 part name that allows you to resolve between the two ... ... David: they want to have a global name space ... If things are not exposed as services then they are not resources ... they don't have to be in the model .... Savas: but that is the conceptual model of OGSI ... David: the OGSA model does not have anything outside of the model ... Savas: in the file system you could have a single service for the whole file system and some underlying naming mechanism but the OGSI system then wants each file to have its own gsh ... Allen: if you pull something out of a database your query result will not necessarily have its own gsh ... ... Dave: if I own data then I will create services that are specific to the data that people want to access so you might expose your row as a service ... ... Dave: in business I want to know the total sale for a given region for the last month - these would be exposed as a web service ... The thing that is a service is the service but not the data ... Savas: what Norman just said is not what the model says... the OGSA Data Service (DS) paper says that data is exposed as a service ... The OGSA DS advocates the deployment of the handle as an identification scheme at a very fine grain ... you can use a gsh to identify files ... when you go to that level and delegate down to the lower levels people are going to feel uncomortable about drilling down while trying to maintain the identification at these finer levels. In the model you have aggregate and ask for properties .... Dave: you are talking about data regarding the management of the interface ... management and access are different things ... Savas: we need to know whether you are going to make the 1-1 association. If there is a 1-many then you can't do this without having an additional naming scheme ... Dave: if you model it there are certain things that are not object orientated ... I would be against fine grained management... David: we are talking about 2 things - the database and the data inside the database ... The data source is the underlying thing. In the OGSA DS they do not present a vocabulary to distinguish between the data and the DBMS. Dave: in DBMS world there is a distinction between the DBMS stuff and the data that it contains .... David: similar thing in file systems ... We could say that we are not going to deal with the 1-many scenario. Dave: I think that is acceptable. .. and then you could have a parameter that would return you the constituent sources if you wanted to kown this and you could not prevent this. Savas: as I expected you to reach this conclusion I have a follow on... Dave: difference between integration and federation ... Savas: if you make the 1-1 relationship then you have an issue when you expose the data source through various service instances ... how can you determine these are all representing the same thing? Let's say that the data source is a DBMS and suppose you expose this through a single service instance ... then a second service comes in - how can they determine that they are pointing to the same thing? ... Allen: does OGSI provide any answer to the identity question? No Allen: then the identity must be provided by the services ... This means that we have to provide that kind of functionality. Savas: this is just for the database ... but the problem is much bigger ... this is referred to the "relationship service" that can do this ... David: there is WS-Naming .... Savas: ... you have contextualisation... OGSI tries to talk about explicitly managing state while in web services it is implicit ... Dave: I can remember this problem taking place at the beginning of the WWW ... it is something that happens all the time in business Savas: achieve loose coupling by not identifying the service state ... Vijay: you identify the state by application level logic ... Savas: have application specific semantics ... David: I would argue that this is a problem in WS as you cannot easily pass these are around ... there are not many application domains that have global name spaces ... Savas: ISBN, post codes, telephone numbers, bank accounts .... Vijay: there is an assumption that the application logic state can map into ... if your credit card number you could get a book back if the context is not clear ... In the use of CIM stuff the two service would be able to get the database name and within a context you could check whether the service point to the same thing. You could query the database ... Vijay: but you are trusting the information ... you can get the same view of the same database which would give you different names ... Dave: but that is an unsolvable problem ... Savas: but it is an inherent problem with the model ... But this is a general problem ... you would have the same thing with JDBC.... Savas: problem lies because you are making a link between the service representation and the object that it is representing ... The name could be the same but you could have different views of what is being shown ... Savas: if we have a global name for the data source then we can ensure that we are talking to the same data source ... explicit contextualization ... we do not want to name the sessions .... ... Savas: we should not make a 1-1 association between a name, the service instance and the underlying source .... But we are not ... Savas: we should say that there is only one service and ... David: you want a global name space for your data sources ... that is something that we have steered away for ... Savas: everything that you want to expose should have a global name space ... Allen: i don't see a need for that ... Savas: ... because of all the problems ... Allen: I've not seen any problems ... I am comfortable that as you drill down that at some point tha tyou have to slip out of the OGSA model at some point ... David: the fact that you slip out pretty fast is the problem ... as soon as you want to do any managment ... Dave: when you start doing starting and stopping of the dbms... Savas: if you have 2 DS instance defined on a specific database where a DS instance is a stateful WS - you cannot talk to a Grid Service you have to talk to an instance ... if one of us shuts the database how can we ensure whether we are talking to the same databases ... Vijay: if a service is providing an interface to a database why does someone want to stop it for someone else ... Savas: if you shut down the data source I cannot tell anyone else that I am shutting down the servide .... Where do you appeal to for the name? ... if we implement the common database name - if they expose unique names then we are ok ... if we were to take the CIM common database schema name then we use that as an identifier.... Savas: Norman has suggested that we need a second level of naming. Now we have a need to get a second name ... a gsh is not enough ... Vijay: if a service provides management then its namespaces then you need to provide a local naming scheme ... if you are trying to have multiple data sources under a service ... it can extend its internals via some of the local naming system ... you do not have to expose the internal namespace ... There are different flavours and we need to come up with different solutions for these frameworks ... if you have a DS which has a federation scheme then you can choose not to expose those data sources but there are certain situations where you might want to do this in which case you use a prameter ... Savas: problem is with the things that are exposed and how they are expose outside the boundaries of the organization ... The fundamental thing here is that a gsh identifies a service and not a source. The problem is that the OGSA DS document sometimes uses a gsh to identify data and we do not do that. Simon: from our discussions they would like it to identify data. There is a discontinuity between the data identified by a service and the data itself .... Steve Tuecke was worried that other mechanisms were being used to identify data outside the gsh world ... ... and that is the way that it is going to remain ... Vijay: you can name things inside the encapsulation of the data service using your own name space ... Savas: what they suggest is that once you chose to identify something to the outside world then you have to use a gsh and in that context you should not use a 2 part namespaces ... What the OGSA DS are currently suggesting as good practice may not end up in the specs. It's fair to say that that doc it makes warm noises about representing files as services ... the document is an initial pitch and then there may not end up representing stuff as services .... Savas: but this is the only thing that is representing DAIS in OGSA ... this currently is presenting the only way to represent data in OGSA ... It would be wrong in OGSA to over stress that document as the only view of data in OGSA ... ... moving on ... There are things that are not covered by the CIM database model - security mpapings, how a data service is constructed from data sources .... David: you are talking about data service instances? Not really ... David: CIM assumes that your management is welded on top of the data resource ? Not that there is something in between ... Simon: there is a spectrum in how you use service and one of them is how CIM manages things ... Currently have: Data Service -> DBMS -> Data There are things that characterise the DBMS and things that characterise the data. Then there is the management of the relationship between the data service and the DBMS ... Simon: there are other scenarios ... Some things could be implemented in different places ... Things that are more difficult to place: - DDL commands can sit in the data access or data management. ... Dave: there are three main layers: the data base management system, the data objects and the content of the data objects ... Vijay: we have rich query languages ... we should not be replicating work that is already been done and which we should be extending instead ... a database will have views, objects, etc ... Dave: we want a set of operations that give access to comparable operations that are technology management dependent ... Vijay: would these not be best put into the access mechanism ... Dave: Would argue that a systable (systems table) is an ordinary table but we need to be able to factor in the role ... I see problems in the commercial world where people will not want these things to be mixed together ... approach I would like to take that there are diffent classes of operations and I would like the services to distinguish ... ultimately that comes to an implementation dependent level ... the spec should allow for both of these ... Vijay: everyone will have to support the management portType some of which will be mapped to the underlying dbms operations ... Dave: DML and DDL are well characterised ... CIM is not going to be helpful ... it does not classify commands ... Dave: the closest that it comes to is at the database characterisation level There is a suggestion being made here that you could provided the functionality that you could choose to allow some range of commands and then it is an implementaiton detail as to whether you support these and the implementation filters these things ... Allen: I think that is the right position ... it may do the blocking ... Dave: I don't think that I am unique in having this view ... Could use improved slides that take that view on board ... then there are other capabilities that are defined in the CIM database model I'm not sure where they belong. Take size as an example - one possibility is that the "size" is associated with a DBMS ... Allen: but the service has state ... Dave: but you can intepret size depending on the three layer model previously defined .... The service could have its size - it could be the amount of memory or cached data, could ask at the DBMS level and then could do that at the table level ... David: you could take it down to the blob level ... Dave: it is a management thing ... ... Could try to get some of these database characterisations and try to map to fies ... just from the management perspective ... We could go away and fill in a table and see if we feel comfortable about doing this ... Vijay: there are certain objectives that we want to achieve and depending on these objective then that will allow us to decide between the different data models. Norman takes an action to update the slides in view of the discussion that has taken place. David: every vendor has already done this ... Dave: Did a trawl of CIM of what the different vendors are doing in this space .. Discussion on what vendors have done in the space ... Norman picks up an associated point ... Mario: where is this going? Is it going to go forward as an informational document? Modify the OGSA DS document? .... Some of it will feedback to the data service document and other places ... --- break for luch takes place now. Topic: XML Realisation Issues ----------------------------- Unattributed comments in this context should mostly be associated with statements made by Amy. Mario: if removeCollection is applied while another service is accessing that service then that other service faults? Yes ... Simon: are there position in the hierarchy of collections where some interfaces are valid and some are not valid? In order for an operation to be exposed at the interface must it be valid or does it fault? ... Dave: a lot of the operations will be driven by the privileges a user has access to. So, despite the fact that the operations is present, it does not mean that you will be able to use it ... ... Vijay: can use the policy of the underlying resource but can also implement policy using WS-Policy. These are different issues. Simon: I don't see these as different issues... Vijay: our interfaces should specify policy and not the other way round ... Savas: that is not the way that the ogsi model currently works ... ... A general discussion on policy followed as to where these are applied and how they are applied. Porttypes for exposing intefrace are fairly coarse grained and to a certain degree these issues are orthogonal to policy. We define our portTypes in a way that seem to be functional units and we just have to accept that some of these will be operational and some of these will not be. We just have to accept the granularity of our portTypes. This then morphed into a discussion on agreement. The WSDL that you get back may depend on who you are. WSDL only describes the messages that go between the service and the service provider. The WSDL you get back may also depend on who you are (that is to say the level of priviliges that you have). Some of the capabilities may become invalid dependent on the type of data resource that is being represented. Vijay: WS-Policy should not take into account constraints imposed on the service. David: but the policy might be that you get 100 files while I get 1000 ... Vijay: this can be implemented by the internal logic of the service ... policy is about a negotiation ... the fine grained structure is not the part of the policy .. the policy should be about the semantics or the behaviour patterns ... David: you need to determine some fine grained aspect .. Vijay: ok it requires some further thought ... ... Question from the slides - document insertion is in access while creation of collections go in the data management - does this make sense? No dissent. Need to check up with what xmldb is doing. Should we name the factory portTypes after the services they create or the resources that they are associated with? Savas: why do you want to create a service? Why not just send the results back? Norman: there is a synchronous version back that returns the results. Savas: why do you want to do this anyway? Norman: the result may be delivered to a third party ... Savas: the result is then be named by the service.... with my OGSI primer hat on you may not need the factory... you don't have to have a factory ... Norman: this was deliberate - you can have "F" and "f" factories ... you may want to say quite a lot about a derived artifact ... you can tell it the port types that are supported by the interfaces ... thus it cannot be created implicitly. Simon: ... another reason for originally doing this was to encompass WS-Agreement that we are no longer bound to ... this does not mean that we cannot use an implicit factory ... we have struggled with the naming of these things ... so we started going down these route of using the name of the type of query or the type of thing that we were creating ... and you end up with all sorts of names that are not particularly satisfactory ... Savas: if you have a factory portType then you have an XML document that can have a choice that tells you the things that it allows you to represent ... but that is a design choice ... Norman: we have been "diddling" in this space as to what you do ... Simon: this is an area worth revisiting ... we have the luxury of removing agreement ... Savas: this will have to be revisited with factories going ... Norman: are factories going ...? Savas: nods ... David: all of GGF is having this discussion ... Savas: in Java you can have an operation that has do ... Simon: we need to have some kind of consistent naming ... we need to recognise what we are doing as well as what we are not doing. Dave: we need to see whether these things apply to the different data models ... We can take action on this after the OGSI refactoring has taken place. ... At the moment we do not have a document that specifies how things are going to be presented to arguments - design patterns ... this will be revisited tomorrow and try to make sure that an action comes out of this. The terms needed to be placed in the creationService operation. ... When you define an operation in more than one place does this appear only once? Savas: yes. There are some cardinality issues ... Amy: this causes repetition ... but it is repeated in the document. Things should not appear more than once... e.g. version is repeated across access and factory portTypes. Simon: need to factor the SDE to be be a parent portType ... but we can put the versioning information in the xml schema that is used to describe the wsdl ... need to work out what the right thing to do here Savas: ... may require the extensibility ... or can extend the portType ... new message though requires a new portType ... Norman: step that is more strict then stating a parameter ... ... Norman: issues that carry across the portTypes the definition of the generic terms of the asynchronous operations and there is the precise defintion of the operations. ... A discussion regarding the inclusion/mention of WS-Agreement followed and whether we should use WS-Policy or not to describe terms. We need some language to express the possible combination of terms. Savas: WS-Policy is not intrusive into other specs ... it does not have any requirements on WSDL ... Simon: if we are going to have SDE that advertise what is available you need some language to phrase this in ... Savas: with WS-Policy you are referring to something that is static that does not change ... ... David: you do not want to create the instance and then find out what can be done ... Savas: no ... although bootstrapping is an issue ... all the GGF spec will have to be designed to take into account WS-Agreement ... there are issues with the design of the interface ... Simon: maybe it is to do with choice ... we want to do a SQL query and we want to define an interface to interact with the result ... Norman: and some of the semantics ... Simon: is it really matter of choosing some service interface which is policy or is it a matter of how the services are placed ... do not materialise the results until we query them ... Dave: do you think we will have that level of control? We can define it but at the implementation level there may not be that choice .. Simon: question is how you define it ... here we need to look at the policy before the service is created .... Dave: we are interested in the definition of that service ... how it is advertised that it is not something that they had done.... Savas: Policy is described as part of WSDL ... IBM are working on SOAP so that when it answers you it will return a policy document ... but this is not the case of WS-Agreement as it does not decorate ... Simon: WS-Agreement is negotiated ... maybe we just advertise it and do not negotiate it ... we should still list all these things and see where that takes us ... ... Vijay: another thing that services currently do is brokering and have mediators that negotiate the policy and do match making ... I don't think we should spend too much effort ... ... David: if you are logged on and the policy is changed then there is no way to make you follow the new policy ... ... --- coffee break Topic: Grid Data Distribution (GDD) ----------------------------------- Shailandra Mishra gave a persentation via the telephone. Unattributed statements (mostly) came from Shailandra. - Have tried to address issues that arose from GGF9. - Have tried to look at the DAIS scenarios. - GDD simplification. Went through a brief recap of the gdd model. Dynamic operations - can done on the fly - what you want to publish and/or consume. Have administrative and operational tasks. GDD gives you 3rd part delivery...these things are in the slides. A GDS can act both as a source and a target ... Implicit publication occurs when data does not have to be materialised. ... Propragation is a combo of publication and subscription. The common theme of all these interfaces is that you have rules and these define what you want to do. ... Issued raised at the DAIS f2f after GGF9 - trying to factor the GDD stuf to the OGSA DS base portTypes. Eventually decided to put the GDD in as a data type of its own. Put this at the same level of DataAccess, DataDescription et al. Furthermore GDD is divided into subportTypes - GDDConsumer and GDDProducer. GDD and DataAccess are seen as orthogonal. In order to implement a data service you ned to know a lot about data services ... need to have a negotiation protocol which is a requirement on WS-Agreement ... we need to be able to negotiate capabilities ... if you look at the paper a set of capabilities have been described which may not be generic enough but it provides a good starting point. Have type capabilities, etc. This is not finalised as yet. We have all these interfaces - how do we provide monitoring? The monitoring will be provided through views. This is not a database centric view. It applies to files et al. Have: - administrative views - security views - statistical views (a debugging interface) - number of messages, how many bytes have been transferred, etc. If you look at the paper some of the details of the views have been given. These views are accessed through the dataManagement portType. The views put a requirement on data access. Otherwise they are fairly standard ways of accessing stuff from a GDD. How does a GDD handle transactions? It depends on these capabilities being offered though the GDS interface. Transactional capabilities are negotiated capabilities. A note from Dieter states that most transactional implementations do not implement recoverable read and this is a necessecity for .. there is also a fast read which also facilitates certain capabilties. If we look at these interfaces you have all these identifiers so how do you discover it? You would have to have a discovery service to discover the services that a GDS is capable of. We are trying to model DIAS scenarios 2 and 3 (as proposed by Greg Riccardi) with the GDD interfaces. By providing GDD we are not trying to subsume anything. Trying to provide GDD to provide an infrastructure. The existing GDS covers some of these scenarios. The GDD covers most of the other scenarios (asynchronous). Some of the scenarios were then examined in detail. None of this is formalised and the details need to be worked out. Scenario 2 is delivery to 3rd party. Use createPropagation to do this. ... Although we can handle all these scenarios the implementation is quite involved. Could provide a higher level interface to facilitate usage. This is the purpose of doing this GDD simplification. ... Need to work in the route, capability spaces ... can these examples be used as a mechanism to formalise the GDD. Simon: what is the overlap between this and data services? The idea here is that we want to position GDD as an asynchronous interface to do computing. GDS and DataAccess - I don't see an overlap. Simon : is it always necessary to specify a query to identify the data to do a delivery? No, not really. Publication could be cone both implicit and explicitly. In these cases the data has been implicitly defined by the use of a query. You could subscribe a data service against a data service ... Norman: if you take the current DAIS spec the result of a request could be produced as a service and that service could support a GDD portType and then ... That is correct. If you want to implement a messaging service on a GDS using GDD - you define a GDS as a queue and you subscribe to data by whatever mechanism the GDS gives you. You can then subscribe to the GDS as the publication source .... Dieter: the line between publication and the GDS is kind of blurry. You don't know whether you insert the record or ... Savas: this reminded a lot of message queues - what is the relationship to message queues? and in particular the OGSI notification portType? If you look at the GDD interface - the GDD framework is much more general notification interface if you look at propagation ... notification goes from a service to a non-service. Also have the route construction and the delivery construction ... we are not ruling out that some of the notification could use the OGSI interface but you can do it by other means.... Dieter: there is QoS and a lot of other things ... Savas: I don't agree ... although OGSI is simple ... you are replicating a lot of the work that was done there ... you have both a push and a pull interface ... Dieter: we should have this discussion at the next f2f ... it is very light weight but for a real service you want to provide a real one ... ... Savas: you are combining functionalities from different areas into one spec that is why it seems that you are doing a lot ... Vijay: the major diff between the notifications is that the ogsi is .... (missed that) Dieter: the term of an event ... in this system the event is part of the infrastructure ... Savas: I don't agree with you ... Dave: this is an issue that could be dealt with out of band ... Dieter: the difference is very big ... Savas: earlier you mentioned a transactional requirement on the WS-Agreement spec - you should not specify requrements? Transactions are orthogonal to this specification so should not be included in that specification.. Dieter: you are right but none of the transaction that are out there implicitly asume that you use the client server model ... if you are in a messaging environement then you need other services and all we are saying is that if you use transactions then you have to ensure that these other services are there ... Savas: I was talking about ws-transaction ... Dieter: database can internally have transaction services ... Savas: you are talking about semantic descriptions? Dieter: that is an application problem ... can you support this? ... I am a propagator ... can you support this? ... and if you can't specify this ... you currently cannot do this ... this is what commercial systems do ... this should be visible in the community ... Savas: you allow for requests to be named - is that using a gsh? If you look at our interfaces we return a private identifier which is not necessarily a gsh as there are questions of the capability of a gsh ... Savas: I agree with you ... Peter: is someone going to present this tomorrow at the data transport? I don't feel comfortable to do this myself ... it should be about 15 minutes ... Norman: Susan do you know if anyone from IBM is dialling in tomorrow ... I'll chase Cecile ... Ann: Cecile had assigned someone to talk about it tomorrow ... Cecile forwarded some information ... what time? Dave: 3pm tomorrow ... Shail: I can do that ... Ann: wondering if the call destination is the same tomorrow Norman: tomorrow is an access grid session ... Peter: but there is a phone number ... ... Peter: question of scope - David and I are checking the activity of the plan ... are you keeping to your original scope? Is data transport supposed to be in scope of what you are supposed to be doing? Maybe you should have a BOF and propose having another group on data distribution. Dave: we are not in scope to have data distribution in our group but we are interested in this area ... Dieter: best to say to the GGF where this goes ... Peter: if you stay in DAIS you could have a portType that does not have the shape to fit all the other requirements ... Dieter: for us it is convenient to have the context and the data services make them active ... if we separate then it will take much longer ... David: you are still able to go to the DAIS meetings ... Peter: Bill Allcock will talk about reliable file transfer ... I don't know how much overlap there is or whether you guys are talking to them ... you can't do something in a hidden corner... Norman: expected this to be raised at GGF9 but it did not happen ... maybe tomorrow we should have the broader look around and then see how we fit .. Peter: suppose someone came and proposed to set up a BOF on data transport ... we could not say that you cannot do that because there is a group in DAIS doing that ... David: have talked with Cecile about this issue ... I thought you guys were putting together a few bullet points that could constitute a charter .. don't know if any progress has been made ... David: there are a couple of comments - looks very similar to IETF - the CDI group ... they dealt with a lot of these ideas. They have shut down now. Another thing that you may need to discuss is multicast data distribution ... Dieter: there focus is how you distribute things to lots of people in this instance we are looking at transforms ... the expresssion the large numbers of things that you can publish ... this is really needed in the community ... you need to see what is relevant in the guy that wants to receive or the guy that wants to publish the data. We focus on what is relevant to the data consumer ... this is not addressed by the multicast data distribution people ... ... In sigmod we looked at some of the publish-subscribe models - there is no efficient data distribution in this model. ... Dieter: and the subscription is done at the creation not after the creation Each subscriber has got their own rule ... the multicast model does not follow this ... David: you need to answer these questions ... Given that the principle means of the GDD is through an evolving informational document. This document should have a section that addresses its relation to publish subscribe and other relevant groups. Vijay: you are using rules for scheduling ... if you have a 3 part query then ... have you consider when you have a continuous query then your scheduling part may not hold ... in the spec can the subscriber look at the number of messages that have been back dated before the subscription? ... have you considered bookmarks .... and there was a 3rd question Dieter: coming from the database whenever data becomes visible things happen but whether these things happen constitute an even depends on how things happen. When you look at how the events depends on you ... you could look at data 10 years ago. You have 2 streams of events .. we don't care ... warehousing ... there are so many tools to identify events ... if you bring them together then wonderful things can happen... in W3c they were forgetting to put the end points .. Vijay; if you consider a bookmark certain events can be invalidated by subsequent events ... Dieter: it would be wonderful if you worked with us and wrote a richer event language ... the complex event community have not done anything in this area ... you can express a lot of things with existing languages ... we can try to do things with existing languages and alter can try to develop more generic languages ... Vijay: let's see how we can take it forward ... ... David: for tomorrow's discussion if you can put a few sentences together regarding issues ... If you send me some emails regarding the existing issues then I can look at these ... ... Vijay: was not able to say anyhing about the visibility of publications as other folks may become interested if they see this ... Exactly... in the presentation there was a small section in the presentation about the visibility Vijay: if you put it in discovery then it will be a passive ... ... =========================================================================== Day 2 =========================================================================== Topics discussed:- - Web and Grid Services - Impact on DAIS Specification (Savas Parastatidis) - Discussion on terms (as used in the context of WS-Agreement) (Simon Laws) - Planning (Norman Paton) - Relational Issues (Susan Malaika) Topic: Web and Grid Services - Impact on DAIS Specification ----------------------------------------------------------- Unattributed comments in this section mostly belong to Savas. Norman asked me to talk about the DAIS and the impact of the recent and upcoming changes. The presentation does not relate to the up-coming OGSI 1.5. Dave: can you talk about OGSI 1.5? OGSI is going to be an alignment of web services and grid services. Not privy to the changes. OGSI 1.5 will probably be discussed at the next GGF. That is the informal information that I have. Malcolm: couple of recent discussions with Steve Tuecke - that is where Steve hoped it would go but because IBM are major players they have to agree on what the shape of the spec before it can go. Can't say much about OGSI 1.5 is because we do not know. Some of what is in OGSI will be taken out of OGSI and be placed in other standardisation efforts. Try to establish of placing the context of web services. Relate the current OGSI spec with the DAIS spec and how this could fit within the web services architecture. Propose an alternative to SDEs. Some of the things that are important for service architectures are the four tenets give by Don Box: - boundaries are explicit - services are autonomous - service share schema and contract, not class - service compatability is determined based on policy in the Grid services world we do want to cross boundaries Peter: can you explain the former statement? Because of the current model - e.g. being able to manage resources in a VO and expose these to the external world. In service orientation this is not very good. Malcolm: Jeff Nick will give you example after example where customers want to do this kind of thing - this is one of their goals. Dave: that is a bad example - a farmer company becomes internal ... Distributed yes ... but not a farmer company ... ... Malcolm: we are arguing about a position in the spectrum and not a dichotomy .. Savas: if you take extereme positions then you do have a dichotomy... Malcolm: but you are characterising them as being in opposite position of the spectrum ... Savas: but I think they are ... ... Have tried not to use the word state throughout the slides. In the distributed objects world you have services and have pointers that go from one object to a pointer to an object in another system. You have a shared type system ... CORBA imposes a meta type system.. Malcolm: you only agree on the info on the types that you wish to exchange. Internally you can have your own types ... we have to be very careful as to how different these things are ... Once you have these meta type systems where you have interfaces and methods to those interfaces ... these are the entry points to your in-memory representations. Malcom: you don't actually point to the objects and they don't often reside in memory .. in the ejb model you will be constructing them from an implicit state ... This is my view of distributed objects ... you have an IDL for a purchase order ... objects are described in terms of their interfaces ... their behaviour ... We assume that we have these objects in memory and point to their location which brings up a whole bunch of issues ... distributed computing using angle brackets ...i.e. xml. Current tooling encourages this approach. It makes it easier to think of services as objects. The OGSI model is the same ... it is the CORBA model using xml. Web services on the other hand have services that act as black boxes. You do not see the internals. All you do is exchange messages. If you send a message a and a message bacj then how do you correlate these messages? This is where contextualisation comes in. It allows you to place these messages. Cookies can be used to establish a context/state based interaction. Malcom: ... you've changed your perspective where you are talking about someone interacting with the service and do not have to know the internals but if you are building services you do need to know about the internals. Your view is dependant at the level at which you view the system. ... there are fundamental issues here that we have to think about which have their inherent complexities ... when we are an engineer building the system ... we provide a simple interface when we are building ... you are kind of changing focus ... I don't think that I am ... the only thing we agree in my service interaction is how we exchange messages and will not allow you to see my internals ... Malcom: that is true at the level you are presenting but if you are doing business then I will want to know about some of the internals of your system ... at a later point you close the doors ... your cleaness here is a matter of how you are choosing to look at it ... Dave: the way I interpret what you (Savas) are saying is the way that most systems work in real life ... in a car insurance dealership then you will not know anything about the internals ... Malcolm: but if you want to be a cross dealer then I will examine your internals ... so it depends on your perspective ... different perspectives require different amounts of information. ... withing DAIS we are looking at things from the prespective of a service builder ... Vijay: you are mixing two issues - encapsulation is not the issue in moving from the distributed object world to web services ... the web services had three issues ... (missed the frst one) ... wire protocol ... integration issues. ... Malcolm: system builders will have more knowledge of the internals than you will provide to the end user ... it's just a question of perspective... .. Difference between SOA you have message exchanges. In OGSI you allow to references inside your services ... Allen: are you just not making an artificial distinction ... the messages try to refer to things inside your service boundaries ... they have effects ... Discussion of amazon.com as a use case and whether the user identifier (a cookie) can be taken as representing a pointer to an object representing you or whether it does not represent an actual object ... discussion moves on to discuss whether this corresponds to gsh ... the conceptual model encourages thinking of pointers to objects ... ... Malcolm: DAIS has partitioned the space into xml, relational, files because the space is large which will encourage developers to think of these things as separate things ... this is a result of the partitioning... once people partion the infromational exchange into sub-system then people will start thinking about the existence of those sub systems ... ... Another analogy of using an order number as a way of exchanging context. ... Data services currently have a factory interface which creates a data access interface which has a one-to-one association with the data resources. Multiple resources will be exposed through multiple services. Malcom: not necessarily as you could have one service that represents the multiple services ... OGSA DS suggests that every file is represented by its own gsh .... Malcolm: there were a bunch of us who proposed grid data handles to do that kind of identification - the issue is that you are going to have to do this identity problem as you will want to identify files ... do you provide new mechanisms or do you piggy back on existing systems ... and as you have a distributed name space already it's a good idea to piggy back on that ... I do not have an issue with naming it is the coupling of identity and interface that I have a problem with ... identity + interface gives you an object ... which lifetime ... Norman: it's in the semantics of the application ... Malcolm: at some point you still have to make these decisions ... A bank account is unique - credit cards have a different system and the world still works ... OGSI wants to impose a universal identifier .. Malcolm: for all things that want to participate in the Grid ... ... Allen: why can't take a resource and expose it through an interface? ... ... Norman: the tendency here is for you to drill in bits of the OGSA DS document that are weak ... you don't think of a service uniquely identifying a piece of data ... ... but this is the encouraged model in OGSI ... the fact that they are moving to a ws-resource ... it comes back to exposing things coupled to an interface ... that is what the issue is ... in the SOA (Service Orientated Architecture) you don't have that ... Simon: it is clear that in WS and OGSI you have an issue with identity - how do you identify the data that you wish to manipuate? Peter Kuntz introduced the idea of a GDH (Grid Data Handle) .... Malcolm: in a sense this has re-appeared but this involves of developing of another protocol for doing this ... some people say that this is unnecessary ... it is debatable if you can build systems based on one or two naming schemes ... Simon: there is the associated idea of context ... can pass parameters to identify that context. In OGSI the context is identified by the interface and in ws you have to pass your context identifier to the correct service .... Malcom: people building services need to understand what identifier you pass to what service ... we are thinking about things that need doing ... the argument for regularity for services that have common properties ... it is not wrong for people to say that if you want to play in our grid party then you have to wear our gsh badge ... if you want to display your context badge we are just re-organise our regularities ... I am not saying that they are wrong ... Malcom: but you have to re-introduce these regularties ... ... Go back to looking about the model in DAIS. Multiple services pointing to the same data brings up identity issues - is it the data of the service or of the data. Similarly with multiple instances representing the same data resource. If we want SDEs to access some of the state you put them at the service interface. This approach is driven by OGSI and because it is different from the vanilla WS view then you have to modify your tooling to take into account of these extra capabilities ... Malcom: the only fundamental issue though is whether you do need to use additional tooling or whether you can use existing tooling ... my impression of the 1.5 spec is that you can use existing tooling ... but that is only my impression ... I do not know ... I am only talking about what is out there just now ... ... Malcom: do you put under session transient data that which needs to be collected under data resources? ... under data resources ... Simon: what about the other OGSI things like creation and lifetime ... I see that as metadata. Savas goes on to present how data services could live in a web services service orientated architecture ... ... Try to decouple the identity and resource ... Malcolm: but you now have to establish a binding between the interface and the resource ... you then have to reconstruct these regularities. ... I don't care where we do it but we have to do it .... Perhaps we will end up doing similar things but the approach will be different. I have a feeling that the approach that I am presenting is more loosely coupled than what is presented by OGSI. Use a urn and not uri to identify the resource. A urn is a uri but it imposes the extra restriction that it is globally unique and valid for all time. Once you have labelled a urn to a data resource you have not changed it ... Malcom: there is nothing to stop to have more than one urn to refer to the same resource which is what you complained that OGSI are doing ... ... you may be right ... I need to think more about that ... Malcom: do you put all these things in one parameter or in the header where they are not explicitly identified ... I don't think of parameters ... I think in terms of document exchanges .... Malcolm: tooling thinks of parameters and you said that tooling is one of the reasons for moving in this direction ... ... By using the document approach one can use existing tooling for metadata. All the OGSI concepts can map naturally to WSA. Should focus on document formats and not just interfaces. Malcom: to me data sets have nothing to do with services and if they turn them into services then they are making a mistake ... I am not saying that we should not define interfaces but that the focus should be on document formats... ... now did a demo ... Demo showed how things could be done without using SDEs. Malcolm: now we need to sit back and see how that affects this working group. We want to make as few assumptions as possible. Within GGF context though we fit within a larger grouping. ... from the point of view of DAIS it would be nice to define the standards so that they would work with vanilla services, vanilla corba, ... whatever we are able to find available as to what we are really interested in is what is at the base level. We want to minimise dependencies on whatever context is used ... ... Malcolm: ... when I was involved in the early meetings in OGSI about two years ago the plumbing did not seem to be there ... ... I was extremely careful to use technology that was available two years ago ... ... Malcolm: identity and behaviour are exteremly important to us ... interface is something else ... ... Dave: your presentation is a different conceptual model ... ... Norman: that is quite useful, thanks Savas, we know that change is due ... what Savas is saying is that OGSI specific things in the spec - use of instances for sessions - use of instances for results ... can use other data referencing schemes ... Most of our work is defining types ... it would be good to come up with a common schema ... taking the big picture we can drive forward with semantic issues of requests and results and we can try to absorve the changes in OGSI ... What we do know is that factories and instances are getting ... we get resources instead ... Peter: what is the difference? ... Malcolm attempts to represent the changes as he understands them: Currently have: gsh -> grid service instance in the future you will have: ws-address: endpoint service -> service instance internal identifier This labels the resource to be modified by the service instance The current gsh uri type thing maps fairly easily to this new framework.. ... Savas: my understanding is that the ws-address is going to be carried in the headers to do contextualisation ... Malcolm: that I don't like. I prefer things to be done explicitly in the wsdl ... there have been proposal to add header aspects to wsdl but these things have gone away ... ... Malcolm: early discussion of OGSI - nov 2001 - talked about managing the provisioning of services ... one of the models at the time was selling the underlying compute and storage resource by bringing resources to satisfy peak demands ... hence you had a factory to bring this stuff. Bill Joy talked about migrating database or creating an empty database on a site in the power grid ... ... Dave: the next session is on planning. --- coffee break Topic: discussion on terms -------------------------- Simon leads a discussion on semantic terms on the spec. Unattributed comments are mostly Simon's. The "terms" in this instance are as those that would have been referred to in WS-Agreement. The construction of that document allowed you to talk about all the things that could be negotiable terms. Had a tentative set of terms that could be used in the spec. Now want to talk about the terms and the functions that these imply. Malcolm: originally you were talking about requirements on a service but now you are talking about requirements on the results ... Not necessarily ... --- Terms below are as were written up in the white board - text below carries the discussion that went round these terms. ReadData Cached (don't throw away once read; static - snapshot - don't follow underlying data - read consistent in oracle terminology) - created on query - created on 1st use Clients tend to expect read consistency timestamped at query time. Query time - time it was defined some time specified for query run. Metadata can be used to: - advertise options - express given service behaviour - the context to which the apply/ lifetime of the agreement Updateable - Apply to cache only - Write back to the original resource - best effort (still going via the cache) - dependence on query --- Mario brought up Mike's document that was posted to the DAIS list. This considers: Isolation levels mentioned. Isolation - between transactions. David: are you talking about versioning? Malcolm: no. Discussion on versioning followed. Versioning is a property of the underling resource. Dave: we should frame these terms as things that we see that are important... Malcolom: an important property of DAIS components is that they should be linked as closely as possible to the underlying data components. The problem we have here is a component of the underlying service or are we describing something else at the service level? Something that will be done on behalf of the client and whether it will produce a result at a later point. ... Discussion on read consistency followed ... there are lots of implementation strategies - what is important is to have understandable semantics. Norman: there will be no MUSTs for these things. David: not sure if these things should be optional. Norman: ... not all of these things ... Vijay: when considering semantics are we using it to specify the service behaviour? ... is a capability or a way of specifying the service? ... Simon: could be both ... Malcolm: is this metadata of what the service says is available or is it a request for behaviour from the service? ... ... The next one is about the nature of the data and the properties that the data follows ... Talk about best effort to do a write back ... Vijay: are we consider the data set role? ... the model does not apply to all instances? .. David: you don't necessarily know the properties .. Malcolm: that is why you need descriptions ... equally you have to have good descriptions at the clients ... you need to be able to make queries about how many clients are doing updates ... currently though we are in a simple space ... if the query was updating statics some queries are semantically meaningless ... depends very specifically on the query .. David: remember it's not necessarily a database ... Malcolm: but even so I'm using query in a very general sense ... Simon: what is the implication of "write to resource"? Dave: updatable could imply that there is no data in the cache ... Simon: you could be writing to the cache ... David: people that do that type of thing work hard to hide the cache ... maybe this is the wrong thing to do ... Malcolm: db managers do allow you to have different models of cost to apply to different cache strategies ... David: that is usually at the db admin level and not at the negotiation ... Malcom: the db person could be working across the grid Dave: but David is right they tend to hide these things ... Malcolm: but if you are doing tuning then you expose these things... Dave: but going back to the Savas presentation you want to treat it as a black box... Malcolm: ...but for time dependent users you might want to squeeze the last bit of performance .. this would facilitate that in a distributed system .. ... Malcolm: still not clear on the things that Simon is trying to do here - all the terms. - the structure for a space of terms. - what the terms should apply to. Much like ws-agreement sets up a structure if we explore the space we can come out with a structure ... Dave: we are trying to determine the terms. ... Malcolm: I think the three things are getting merged now... Simon: we are trying to identify the terms and what they apply to... Malcolm: you think we should identify terms across multiple data resources ... maybe we should come up with a structure that can later be filled out ... Dave: currently trying to just determine the terms ... David: are we looking at control or just information? is it what is available or what we want ...? Norman: some are to do with properties of the servide and others to do with the underlying data resource ... David: in AFS you can do write through where it will not modify the cached copy and go right back to the server ... ... Simon: want to be a bit more concrete ... want to explore the space .. establish whether we need to be concrete or abstract in the spec ... trying to be a bit more concrete in the first phase ... David: the data and/or the data store ... Simon: the data and the data store ... Dave: an interesting point in the semantics of the terms is whehter they apply do the data or the data resource ... ... Malcolm: you might use these as agreement terms ... do not want to deal with you unless you can specify certain terms ... can enter a negotiation stage ... Dave: we are just looking at the terms and what these terms aply to .. ... Discussion as to how these things should be implemented or not ... current view is to explore the space and see what we come up with. At some later point these guys may be substantiated .... ... Simon: another term was the interface a derived service should implement. What is the mechanism to determine those portTypes? It might be that the factory only supports one type of interface. On the other hand if a factory can have more than one interface then we must be able to provide a mechanism to make that choice or join the particular interfaces in mind. ... Malcolm: not convinced that you can say this resource with this interface or that resource with that interface ... using a factory to create service A with interface A or service B with interface B pointing to the same data resource? Can it be done? Savas: this is something that we have to think about as service instance may go away ... Malcolm: it becomes more and more like a capability model where it relates to the identity to pass it back ... you are entitled to reduce the capabilities ... Savas: the new model - once you create a resource it would allow for the wsdl of a service to dynamically change.... you could express capabilities ... the wsdl of that serfvice will change dynamically. You are allowed to return a subset of a wsdl document... my assumption is that this is the way that they are going to go ... that is the way that I would have gone with ... I think this is bad .... Malcolm: we should identify this as a requirement and ask them how they are going to do it ... Savas: you identify the resource, you give it an identity and then how you give it capabilities you use another service ... Malcolm: but if I want tools that constrain my operations to the wsdl - current tools would not deal with the service is associated with WS-Address and not the end point ... Savas: need a communication between services ... this takes as back to identity. The naming is subject to that context ... David: a metaquestion is this going to be used ? or do people pick their data resources ... Savas: I'm trying to put myself in the mindset of OGSI ... ... Savas: the base is that "I want information ..." Norman: some of the terms will be orthogonal to the interface that you require ... for a given semantics you can assume the maximal interface is provided ... Savas: we tend to think of what humans would do rather than machine-to-machine interactions ... it will be difficult to work out the semantics bu machines. Malcolm: what we are thinking of here is talking in different ways to a database ... how you access the result after it is made. Then you constrain the interface to support that model. ... the service can do A Or (exclusive) B ... ... Simon: how do you make the selection of writing that contract ... how do you say that? In OGSI it relates to the portType name... Savas: I, as a service, support portTypes X,Y and Z and I advertise the fact that I am prepared to accept messages to any of these contracts ... there may be some security or policy based negotiation that forces to use only one of the interfaces but that is orthogonal and we should not care about this ... there might be an issue that, based on the data source, some of your interfaces are not valid but that is a metadata question... Simon: question is the control side of it? Are we going to rely on what the service can do or can we ask for an interface to be supported? Savas: you are suggesting to dynamically alter the published wsdl...? Simon: no ... Savas: why tell the service that you are only going to use only one particular portType? ... Malcolm: it may be that different resources require different portTypes ... how do you tell the portType? Savas: metadata ... if you want to create a data set that data set will be defined in a particular name space and that name space may be associated with a particular interface .... hence you know an identifier belongs in a different name space cannot be used.... when you build the application you will know that ... David: there is a problem with metadata .... Savas: you could put it in metadata but I was talking about the schema ... once you go to global naming scheme then you need more info ... just outlining possibilities ... Simon: ... saying I want to create a resource that is associated with interface A but not interface B ... in the WS world these would have different end points ... in your registry you associate the relevant wsdl with the named end point ... then we could rely on document types to determine which are valid but then you have no info about the end points .. Savas: the same is true with OGSI - Simon: we put in a query that brings forth another resource and you want to specify the way that you access that resource in an exclusive fashion - there is a mixture on interface and policy ... Malcolm: you may be charged depending on the capabilities ...hence you might want to suppport this working model (cost here is not necessarily monetary ... it's also out of scope)... Savas: what is the point for a client to say that a client only can receive a type of message? Malcolm: who checks that though? Savas: if the client only wants to use that interface why do you have to tell the service? Malcolm: you have to tell the service as the service may commit differents amount resource Savas: but you are now talking about behavioural semantics ... Simon: the analogy is your bank account number ... in this instance we want to be able to restrict the capability .... Savas: To the Microsofts & probably IBMs everything is based on policies ... what you get back are the things that you can do with that service ... Simon: and possibly a description of the semantics and capabilities ... Dave: if you look at the real world you have an id that is independent of the services - NHS number, bank account ... Savas: yep Simon: inside the application it knows what it's going to talk to and the semantics that surround that interface ... Savas: how do you know the capabilities ... Dave: the only link here is the unique identifier and the service identifies you against that service ... all service refernece those ids. Savas: that is the model that I have in mind ... Dave: that is the model that is used in the real world ... Savas: that is why they are called banking *services* .... Topic: Planning --------------- Unattributed comments in this section are mainly Norman's. Documents F2F GGF10 --------- --- ----- 1. Data Services Revision: many small changes (Ian) 2. Data Service Spec Try to look at some aspects of submit service semantics. 3. XML Real. submit 4. Relational Real. submit 5. GDD relate to other work 6. Files 7. Compound operations and compound data Change requests about the data services document might best go to Ian Foster directly and possibly to the list as well if you feel that way inclined. When the document goes up we should then log issues as trackers in the DAIS Grid Forge group. There are some issues that are already at the back of the document. There will be a revised version of the document by the next face-to-face. There are 3 weeks between the next face-to-face and the document deadline submission for GGF10. Question as to whether we can revise the documents to reflect the OGSI spec - the consensus is to leave as is until this stabalizes. Plan then is to try to incorporate the terminology for the service semantics. The Realisation documents will reflect these changes and there will also be some local evolution. The issues that are going to require discussion at the f2f are those regarding the service semantics. Submission here is taken to mean as an infromational draft. Other things: GDD: - Relate to other work - Refine in document - Evolve the use case document For GGF10 produce a revised info document and possibly consider a BOF. Files: Not sure on what the status is. Not sure whether this requires a change to the charter or a new group. Compound operations and compound data: this is being lead by Malcolm and Greg. Not to clear how this is being done. Malcolm: at the workflow and provenance workshops at NeSC there was a requirement about thite compound operations document, e.g. Mike Wilde so I hope to take some action in this space ... It is hoped that the compound operation document will make it to ggf10 as an informational document. There are no documents that are in the GGF process. As we have the data areas chairs ... we've been pushing our milestones back. If OGSI changes we should not try to produce specs on something that is changing. We hope to have most things complete but still have issues with David: you should do new milestones ... Peter: your milestones are not easily findable ... possibly put a tracker for each milestones ... At the next face-to-face will do: - files if possible - compound operations if possible - GDD - terminology for service semantics there is a data day... Savas: I don't think the changes on OGSI will affect you much other than in the terms.... Dave: are other groups going to be affected by the OGSI changes? David & Peter: not as far as they know Peter: regarding procedure - no group can take a spec under its care that is not explicitly mentioned in that charter ... the common sense for this - if a group understand the need for a service that has a limited scope in that group which others may also see a need for it. The work on GDD should be exposed to be visible to other groups ... Norman: have been in touch with Dieter ... although a new group may come into being we can still have close collaboration between the two groups ... Vijay: we have to have these forums but the ggf process should not restrict progress through paperwork ... Peter: but there are issues that may be of interest to other groups ... if you want to produce a standard though it needs to be an open process ... ... Malcolm: we need data movement.... the data distribution seems to be something more general ... there seem to be more low level data movement services that are needed as well and it's not clear if it's in that group or whether it even goes in the data area or somewhere else. I would suspect that it is outside the context of DAIS but work closely with DAIS.... I think that that is what is going to happen ... they are been given an opportunity.... David: great to incubate groups ... Malcolm: Unless we incubate midwhich cukoos.... Savas: if you think that there is value in talking about the process issue between the OGSA DS and OGSA ... whether an action takes place? Malcolm: can we get committment from the data area chairs about the gap analysis and how we fit in within the greater framework ... There is a workshop taking place ... Peter: cannot give a committment - Susan and Andre have done work and for that they should be commended but personally I do not have time to work on ... it's going to be a best effort thing. ---- lunch Topic: Susan Malaika on Relational Issues ----------------------------------------- DAIS telcon/Access Grid Susan Malaika on Relational Issues Made a summary list of the points and issues that came up at the previous GGF. Have made a subset list that we can start working for the next f2f. - SQL management portType - improve the DBOperation porttype - review relationship with tranformations and transactions - remove the agreement Have an agreement with the CGS WG to start working on data management. Our plan is to look at CIM 2.8, to be completed in February, and see whether some items can be added to CIM 2.8 and add some more items to CIM 2.9. They are ready and waiting to collaborate. At the end of the meeting the next steps were defined - to put in the next steps. Had some motivating scenarios. Using the scenarios it should possible to use the CIM model. May add/remove from the existing list of scenarios. Malcolm: will this be on the slides when we get them? Yes - everything is on the slides. Larry Flon is the chair and Ellen Stokes may be a co-chair. We could have a section on this topic at the next f2f. Larry is on the west coast so he could come along. The other piece of work is improving the DBOperation description - sketchy at the moment. Also, the data description portTypes ... should send an xml representation for sql to the ansi sql standardisation group. Norman: had a chat about management issues - the action I took away from that was to update the slides. This has not been linked in with the interactions that you have been having. Should liaise with you before distributing the slides more widely. Susan: There are some GGF slides which you may want to look at... Norman: if progress that can be made with management then we could make progress at the next f2f. Dave: there is a lot being done by vendors - I can identify someone in Oracle ... Susan: the IBM folks are Ellen ... ... could do stored procedures and stuff to make representations on. Did not pick anything contravertial Norman: these things are independent on any forthcoming changes coming from the OGSI front ... on the planning front for GGF10 we will leave the spec documents cast in the current version of the OGSI spec. We can be briefed at the data services day ... it would be difficult to cast docs in terms of the new OGSI spec ... Susan: I agree ... so we resubmit the documents with updates ... Norman: deal with as many of the outstanding issues as we can - these are orthogonal to the OGSI changes ... difficulty is that we will not have a recast version of the spec in March and this will have to be done later .... Susan: maybe we can prepare an informal doc as to how we think things will go ... savas took as though some of the constructs that the DAIS spec could map. So we could try following that process though ... even if this is not reflected in the documents ... how do we play this in the community ...? Malcolm: we should try to do an impact assesment for march which will describe the changes that we need to make our documents and plans and provide a set of use cases that Susan: use Greg's... Malcolm: thinking of something more specific ... how do we provide an interface to a result set.... Norman: could try to provide an impact analysis ... and savas is not too far away from having that ... we could allocate time to do this ... putting a document hurdle ... savas could help contribute to such a thing ... if savas sets the ball rolling then people can start contributing to that - an impact assessment or a suggestion on how to evolve the specs ... does that seem sensible ... Susan: yes, there are some people that will be interested in this. Savas: something like this cannot be written before any information is made available ... Susan: presumably after the f2f in January a more informed decision could be made .... Norman: it might be more interesting to decide now so as to allow the document holders to see how they spend their time betweenn now and then ... Dave: one thing would be to send an email to the OGSI spec folks and ask when the information is going to be made available ... Savas: Ian foster mailed the GRIP mailing list by a criticism made of the IBM/ANL changes to the OGSI spec.... Ian replies that it is better for the process to be closed ... ibm has every right to do that .. better for the community to get a complete proposal ... he does suggest that there may be a possibility for parts of OGSI to moved to GGF and somewhere else ... no time scales mentioned ... sent yesterday ... Norman: if we ask for time scales we will probably not get an answer ... we are going as fast as possible ... if we continue with the proposed strategy we can have coherent sessions on the existing spec and have another session regarding how the OGSI changes affect dais.... Savas: although we are going to discuss the impact of the new proposal ... there should not be an assumption that these changes will be accepted by the Grid community ... Susan: which makes approach more solution... Malcolm: which makes the impact analysis all the more relevant ... Norman: Looking at the other topics - improve the DBOperation description ... fair enough ... xml representation for sql has an external dependency ... Susan: not really ... we can do what we like but it would be nice to get other groups involved ... Norman: need to come up with a plan to allocate effort to these areas ... Susan: is there something similar happening in the XML frong? Norman: there is possibly less work required for the xml than the relational ... there are things that are shared btwn the 2 specs ... this is in scope for the parent document ... the harder issues are the shared issues ... the relational spec is going to be bigger ... Dave: relational dbms also support xml ... is there work that has to go to the metadata side ... we did have an issue about duplication of SDEs yesterday ... --- Meeting moved over to a data area meeting - these are minuted elsewhere by someone else.