
Hi folks, Please can I introduce our DataMINX project (http://code.google.com/p/dtsproject ). We have recently started this project to build a data transfer service for supporting a range of different protocols and would like to adopt and potentially contribute to a relevant OGF spec if appropriate. DMI and JSDL file staging have their strengths and weaknesses in this area, and perhaps there's an opportunity to exploit these strengths within each standard in some way? (Steve, hope you don't mind me re-using your words here). DataMINX is a UK-Australia collaboration currently involving the UK NGS, OMII-UK, ARCS and Intersect. May I also point you to our wiki (http://code.google.com/p/dtsproject/wiki/DMI_JSDL_Issues ) where we have put together a summary of some JSDL/DMI issues for use in a bulk data transfer type service. The wiki presents a couple of rough draft proposals (DMIB and JSDL Data Transfer). *Please note* both are merely rough proposals with the aim of capturing requirements and for compare/contrast/creating-conjecture (hopefully lots to discuss). For brevity, I have summarised the proposals below, but please do refer to the wiki as there are lots of considerations/requirements and discussion points. Kind regards, Dave Meredith (on behalf of the DataMinx team) DMIB The first draft proposal ('DMIB' where we have used 'B' to indicate Bulk-transfer) re-uses the existing DMI elements in a new document-literal wrapped style message model. This does not modify the existing DMI (except for the addition of some new <xsd:any> extensions), rather, it wraps together the SourceDEPR and SinkDEPR elements (both <wsa:EndpointReferenceTypeS>) and the <dmi:TransferRequirements> into a single wrapping element. This 'wrapping' element can be defined multiple times in a single request packet in order to define a bulk transfer (The <dmi:DataLocations>, <dmi:Data> elements are not modified and are re-used as per the dmi spec). JSDL Data Transfer The second draft proposal, defines a <DataTransfer> element (rather than DataStaging). This is used to define some extra elements and modifies the format of the <DataStaging> element to be more suited to bulk transfers, since staging data to/from an intermediary compute resource may not appropriate here (implementation detail). Additions include: a repositioned Credential element, new abstract URIProperties element, client defined sub-transfer id (is used in conjunction with the overall bulk transfer id for drilling down to determine status of sub-transfers), added a modified <dmi:TransferRequirements/> element that adds the <jsdl:CreationFlag/>. ---------------------------------------------- David Meredith STFC eScience Centre Daresbury Laboratory (A32) Warrington, Cheshire WA4 4AD email: david.meredith@stfc.ac.uk tel: +44 (0) 1925 603762 -- Scanned by iCritical.