OGSA-Data WG session #1. Notes by Stephen Davey. Data Transfer Session : Wed 29th June, 7:30am Allen's slide 6: Dieter- Security important as well. BillA - Data Transport is at the byte level. slide 8: BillA - What about connectionless protocols? Architecture should allow for both connection & connectionless protocols. MikeB - For issues listed on the slide, does the arch. doc. answer them? Allen - Some positions taken, some left as issues in doc. slide 10: Timur - What about reservation of resources? Not on list of issues. DaveM - What about multicast/streaming? (i.e. Many sources and sinks.) Allen - Not considered yet; is there a use case? DaveM - Possible use case would be video conferences. DaveB - Or multiplayer games. Further questions: ????? - Is Data WG taking on things which are outside data arena? (E.g. Data Transformations). BillA - No, some boxes are optional; just doing to cover all cases. DaveM - Maybe using language like connections which is too low level. Greg - Should stop at a certain level. Allen - but have to specify something at some point. Greg - should stop before the API level. BillA - could then just limit to WS-Agreement!!? Greg - should you change the scope of Data WG? DaveB - should not be specifying mechanisms as such. Dave Berry's presentation. BillA - transformations are interesting. E.g. GridFTP, OGSA-DAI, any other high level service. Becomes a high level scheduling problem. DaveM - just encapsulate everyting. DaveM - are we assuming everyting (in pipelines) is synchronous? BillA - need to support asynchronous transfer. MikeB - although there is a wide range of "asynchronous". DaveB - what do people want from the data arch.? NormP - In DAIS, have SQL execute and factory method only; but has extensibility points. Data arch. should have high level port types for generally conveying data from one place to another. Greg - what about RFT etc? NormP - Now part of InfoD? In DAIS now a staging mechanism. Greg - expect a certain level of interoperability for source & sink. Or can the source & sink use different protocols? BillA - arch. should give a high level view; give overview of what is going on, general issues etc. Need something a bit above GridFTP level say (or SRM copy etc.) - i.e. interface level not API level. BillA - Data arch. should be at level of job scheduler. ("Data movement scheduler".) NormP - DAIS say not necessarily in the middle, but at one end or the other. Timur - RFT, CRM,... Greg - timing out of caches ... Osamu - GFS; federate many forms of file systems, so need to have many different access protocols. Plus consider replication. ======================================================== OGSA-Data WG session #1. Additional notes by Allen Luniewski Security is an issue in transfer that did not appear in the foils. Bill Allcock notes that we need to consider connectionless data transfer as an important case. What is the relationship between data transfer, replication & caching? ======================================================== OGSA-Data WG - session #2. Notes by Stephen Davey Data WG Overview Session : Wed 29th June, 9:00am Dave' slide 12: MikeB - In relation to data federation & data transformations, will there be an OGSA Data Model? DaveB - what would it's defining characteristics? MikeB - XML schema say. Model says what data looks like. Data WG might want to stay out of this, but may want to step over this line to do something that is satisfying to the community out there. DaveM - probably out of scope for Data WG. Further questions: DaveP - there is a need for data transformations, that may be a change in data form or structure. E.g. Data access & integration. MikeB - need to distinguish between transformations internal to a service and transformations between services. Dieter- need a rich context information available. MikeB - difference between just type transformations (int to string) and something much more significant. ???? - high end trnasformations could need significant computer resources, outside data. MikeB - should call out as separate section or say out of scope. DaveB - transformations also linked to scheduling. ??? - may need to detail how data resources are linked to their computation resources; linked to complex workflows. OsamuT- accessing data from (coming out of) applications may be missing from arch. doc. DaveB - client libraries would be utilised. ArunSJ- high level view in data arch. doc. is very useful for someone new coming into data world. ======================================================== OGSA-Data WG - session #2. Additional notes by Allen Luniewski Observation: can not have data access w/o data transfer. Observation (Mike Beckerle): Does this WG define/endorse a data model? The Overview section should clearly state what is not in scope for the document. Where does data transformation fit into the architecture? Note that some transformations require significant amounts of computational resources. Request: we need to make statements about where transformations fit into the architecture. We should consider specifying “simple” transformations (e.g., floating point transformations) as part of the architecture. Think about coordinated delivery of data from multiple sources to a destination at the same time. This gets more complicated if the data needs to be transformed along the way. Can this be turned into a workflow problem? ======================================================== OGSA-Data WG - session #3. Notes by Allen Luniewski Transactions session (joint with TM-RG): Wed 29th June, 6:30pm TM-RG group is shutting down (lack of chairs). CAP group is trying to define web based transactions. If we were to buy in to something like WS-Coordination then in an inter-organizational environment one runs into the problem of which transaction manager to use/trust (e.g., one in each participating organization). Is reliable FTP a use case for scientific oriented transactions? We clearly need to get some use cases that talk about the scientific computing environment.