[seek-dev] RE: OGSA version grid-ftp

[Jing Tao]

Hi, Bertram:

I think your approch works fine. But our GET method in EcoGrid should have 
two URLs and one identifiers as parameters. The first URL is source and 
second one is destination. In the previous email, I just suggested use one 
url as destination and source one is the default - local. But in order to 
handle the situation, we need both(it is third party transfer).

So, when actor B get info in step3. Then B will call the GET method in GB, 
it pass sourceURL(GA), destURL(GB) and identifier(17) to GB. GB will use 
gridftp to transfer the file. When it is done, GET method will return a 
integer to actor B. So from the integer, actor B can know the file 
transfer successed or failed.

Any comments?

Thanks!

Jing

On Thu, 6 Nov 2003, Bertram Ludaescher wrote:

> 
> Jing, Bing and others (esp. Matt):
> 
> Can you have a look at
> 	http://www.sdsc.edu/~ludaesch/Paper/ptii-grid.ppt
> 
> This is a slide I recently used to illustrate how the Grid-enabled
> data transfer could be possibly accomplished in a transparent manner
> in Ptolemy-II. 
> 
> In the figure, A and B are two actors running in PTII as independent
> Java threads. Logically, A sends B a data token X. As it turns out A
> is really a PTII proxy for some remote grid service GA. Similarly for
> B and GB. So when A sends X to B (logically), what really happens is
> all that other stuff that you see (handles being passed back and
> forth, so that eventually GB requests a direct data transfer from GA.
> 
> When the actor B receives message #3, it does NOT indicate completion
> of data transfer (or in PTII lingo: the token X from A did NOT arrive
> yet at B). This happens only when #7 comes in, at which point B
> logically/virtually has received X.
> 
> 
> Is this how this is supposed to work? 
> If not, how then?
> 
> Thanks!
> 
> Bertram
> 
> 
> 
> >>>>> "JT" == Jing Tao <tao at nceas.ucsb.edu> writes:
> JT> 
> JT> Hi, Bing:
> JT> Thanks for the suggestion and info. I am looking at RFT and it is an 
> JT> OGSA based service that provides interfaces for controlling and monitoring 
> JT> 3rd party file transfers using GridFTP server. Basically, client pass a 
> JT> src and des gridftp url, then the grid service will control the file 
> JT> transfer.
> JT> 
> JT> I already install the grid service (RFT) in my local machine and 
> JT> successfully transfer file from my local gridftp server  to my local 
> JT> gridftp sever :). I tried to transfer form my local machine to dev and got some 
> JT> errors.
> JT> 
> JT> I am thinking we can modified the RFT code to achieve our GET method(I 
> JT> already foud source code). I think there are two parameters will be pass 
> JT> to GET, one is the document identifier and the other is destination url 
> JT> (either a gridftp url or file url). Then GET method will do the two steps as you 
> JT> described(first get the source for Metacat or SRB, then call gridftp JAVA 
> JT> API to send it). A integer will be returned from GET indicates if the ftp transfer
> JT> successes or fails.
> JT> 
> JT> The issue I am think is about certicification. Probably it will take some 
> JT> time to figure out.
> JT> 
> JT> Thanks.
> JT> 
> JT> Jing
> JT> 
> JT> On Wed, 5 Nov 2003, Bing Zhu wrote:
> JT> 
> >> Matt and Jing,
> >> 
> >> Currently the OGSA version of grid-ftp is not available according to
> >> William(Bill) Allcock's
> >> mail below.
> >> 
> >> Here is what I suggest for our GET.
> >> 
> >> If the Java package for grid-ftp as you pointed in the web page
> >> http://www-unix.globus.org/cog/jftp/guide.html
> >> work, we can implement our GET file JAVA client with following steps.
> >> 
> >> 1. GET contacts our Ecogrid system with a Ecogrid object ID and the grid
> >> service
> >> returns actual host name along with physical path. (This is a OGSA
> >> service call.)
> >> 2. GET then call Java grid-ftp APIs to contact the grid-ftp server in that
> >> host to get
> >> the file transferred.
> >> 
> >> Since Metacat store files as links, this approach should work well with
> >> Metacat.
> >> 
> >> For the SRB system, if files are actually stored inside SRB, streaming data
> >> of files into grid-ftp server can be a pain.
> >> The grid-ftp driver I developed is another way around, i.e. SRB is on top of
> >> grid-ftp. But I don't worry about this.
> >> SRB has other data model of using file registration in which files resides
> >> in their own place(s) and SRB just have links
> >> pointing to them. This is exactly the same as the implementation in Metacat.
> >> So I didn't see any problem here.
> >> 
> >> Bing
> >> 
> >> 
> >> 
> >> -----Original Message-----
> >> From: William E. Allcock [mailto:allcock at mcs.anl.gov]
> >> Sent: Wednesday, November 05, 2003 6:11 PM
> >> To: bzhu at sdsc.edu
> >> Subject: RE: OGSA version grid-ftp
> >> 
> >> 
> >> The only thing we have right now, is the Reliable File Transfer Service
> >> (RFT)
> >> 
> >> http://www-unix.globus.org/toolkit/reliable_transfer.html
> >> 
> >> The rest of the OGSI-ification of GridFTP is VERY up in the air right now.
> >> The ideas around this work are mostly being discussed in the GGF Data Access
> >> and Integration WG.  This will be a major thrust for next year, but right
> >> now
> >> I can't really tell you what it will look like, or when we will deliver it.
> >> 
> >> Bill
> >> 
> >> >-----Original Message-----
> >> >From: Bing Zhu [mailto:bzhu at sdsc.edu]
> >> >Sent: Tuesday, November 04, 2003 17:20
> >> >To: William E. Allcock
> >> >Subject: OGSA version grid-ftp
> >> >
> >> >
> >> >Bill,
> >> >
> >> >This is Bing again. This time I am sending the mail as a developer from the
> >> >the Science Environment for Ecological Knowledge (SEEK) project.
> >> >
> >> >We are interested in an OGSA version (or wrappers) grid-ftp. I heard in
> >> >GlobusWorld 2003
> >> >in San Diego that your team had been working on this. Would you provide me
> >> >some updates
> >> >or some web links so that I can do an evaluation for the SEEK project? We
> >> >are also interested
> >> >OGSA-version grid-ftp APIs. Thanks.
> >> >
> >> >Sincerely,
> >> >Bing
> >> >===============================================================
> >> >Bing Zhu
> >> >Programmer/Analyst III
> >> >Data and Knowledge Systems
> >> >San Diego Supercomputer Center
> >> >(858)534-8373
> >> >bzhu at sdsc.edu
> >> >===============================================================
> >> >
> >> 
> JT> 
> JT> -- 
> JT> Jing Tao
> JT> National Center for Ecological
> JT> Analysis and Synthesis (NCEAS)
> JT> 735 State St. Suite 204
> JT> Santa Barbara, CA 93101
> JT> 
> JT> _______________________________________________
> JT> seek-dev mailing list
> JT> seek-dev at ecoinformatics.org
> JT> http://www.ecoinformatics.org/mailman/listinfo/seek-dev
> 

-- 
Jing Tao
National Center for Ecological
Analysis and Synthesis (NCEAS)
735 State St. Suite 204
Santa Barbara, CA 93101