[gin-data] On SRB interoperability with gLite

[Jensen, J (Jens)]

Morning boys and girls.

Arun and I had a discussion yesterday on how to make SRB and
gLite interoperate.  We have discussed for a while to build
SRB interfaces to SRM, and vice versa, and this is an old
discussion, but there may be a "lower hanging fruit":

What if FTS (File Transfer Service) - which can already talk
to (at least) 3 SEs, SRM 1, SRM 2 (right?), and Classics
- added support for SRB as another SE.

Stepping back to the use case, I would think the primary customers
would be
(a) any VO which holds data in both worlds, e.g. (1st approx)
all non-HEP VOs in EGEE;
(b) Grids that wish to interoperate, like GridPP (SRM only)
and the (UK) National Grid Service NGS (SRB).

Questions.  People analysing SRB data tend to locate it and Sget
it out of SRB.  Is FTS appropriate for this.  How does it work
with the job submission workflow if an SRB file is needed
(I didn't get enough sleep to figure that one out for myself :-)

Probably a GLUE information service, say a BDII, is needed for
SRB - FTS doesn't need it directly but other tools might if they
are made SRB aware - worth thinking about now.

So it would lose metadata information from the MCAT but
perhaps a smarter egg could write something to transfer it
to something else.

Filenames.  Perhaps we now need "srm://srm.wombat.ac.uk/srm/file"
and "srb://srb.wombat.ac.uk/srb/file" SURLs.  But the GUID and
LFN stuff would work as before.

Apart from everybody thinking interoperability is good, the real
need should be identified.  We need to identify a real user who
needs real data in both worlds, and work through the use cases.
Any show of hands?

Anyway, I am just thinking out loud as usual but thought I would
suggest it so we can discuss it today.

Thanks,
--jens