[jsdl-wg] dataMinx proj

[david.meredith at stfc.ac.uk]

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 at stfc.ac.uk
tel: +44 (0) 1925 603762


-- 
Scanned by iCritical.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/jsdl-wg/attachments/20091027/361d08c5/attachment.html