1. C O M P U T A T I O N A L R E S E A R C H D I V I S I O N SRM Basic/Advanced Spec Issues Arie Shoshani, Alex Sim, Junmin Gu Scientific Data Management Research Group Lawrence Berkeley National Laboratory

2. Issue 1 Compatibility between versions  SRM v1.1, v2.1.1, Basic, Advanced, ??? What do we mean by compatible?  Function name compatibility oe.g. srmGet, srmPrepareToGet  Function parameters compatibility (subset of later versions?) ols (path, recursive, offset, count, …)  Functional equivalence oe.g. srmGet => auto-pin from time file is in cache  Upward compatibility between versions oClient of earlier version works with next version  How to make function obsolete? oe.g. mkPermanent, pin, … oWhat mechanism? Deprecation time?

3. Issue 2 :View points Top-down view SRM Functions ACL … ……… Advanced Basic Accounting Copy Space Reservation Multi-file operation Lifetime per file

4. Issue 2: View points Bottom-Top view SRM Functions … ………… Advanced Basic ACL Accounting Copy Space Reservation Multi-file operation Lifetime per file ……

5. Issue 2: view points Top-down view  All functionalities are pre-defined for the Advanced version  Subsets are defined as Basic  Must know possible functionalities in advance  Easy to understand compatibility issues  Hard to add additional advanced functions oWhat do we call future versions? Advanced2? Advanced3? … oPerhaps best to stick with version numbers only?

6. Issue 2: view points Bottom-top view  Easy to add additional advanced functionalities, once Basic is defined. oThe version would be Advanced 2?  Hard to support compatibility if functionality changes  Can be easier to implement incrementally

7. questions Fundamental questions  Can we have versions with any choice of subset of functionalities oe.g. SRM with space reservation only? If no  how do we eliminate some functions as we advance with versions?  How do we change functionality?

8. Resolution of view points Technically, bottom-top view is easier to implement. The concern and question is how to resolve the compatibility issues between subsequent versions.  e.g. want to eliminate Func 12, in going from Advanced 1 to Advanced 2; how do we make SRMs ensure compatibility? … ……… Advanced 1 Basic Adv Func 21 Copy Multi-file operation Lifetime per file Advanced 2 Adv Func 22 Adv Func 12 Adv Func 11

9. Resolution of view points (2) One way to resolve the concerns is to have higher version requires lower version to be included fully.  Except for functionalities we decide to remove.  In other words, all advanced functionalities are optional from the Basic version’s point of view.  Any additional functionalities are advanced ones. Another way is to have all advanced functionalities are optional.  All un-implemented methods should return appropriate messages, because later versions will include all methods from the earlier versions.  If WSDL version were higher on the calling end and server has a lower WSDL file version, it would return SOAP-fault for those methods.

10. Resolution of view points (3) It is recommended to have one Basic spec defined. All subsequent functionalities are to be in Advanced version 1.  Hope to include all defined functionalities in SRM v.2.1.1. All following additional functionalities are to be in Advanced version 2.  Namely Accountings, Access Controls, etc.

11. What do we do with Basic? It really depends on the “base”. Based on SRM v.1.1 vs. SRM v.2.1.1 Currently SRM v.1.1 is not compatible (inter-operable) with SRM v.2.1.1 unless we build a wrapper on them. Basic version can function as the bridge between these two versions. If we take a subset from SRM v.2.1.1, its implementations will be hard to be compatible to current SRM v.1.1 implementations. If we take a base on SRM v.1.1, its implementations will be hard to be compatible to upcoming SRM v.2.1.1 implementations. So, what would be the solution ?

12. What do we do with Basic ? How far is the SRM v.2.1.1 implementations? If we design SRM Basic in such a way that SRM v.2.1.1 or v.1.1 wrapper can accommodate, it would be nice. Is it possible? YES.  For compatibility between v.2.1.1 and v.1.1, we have to build the wrapper anyways. If we design SRM Basic in such a way that its implementation can take calls from v.1.1 and can call to v.2.1.1, then it would be very nice. Is it possible? YES.

13. Compatibility in incremental versions Test was done for the following cases: all parameters are optionals.  V1: oBoolean srmPing()  V2: oBoolean srmPing() oTypedef struct { int output1; } teststruct; oteststruct srmTest(int input1); // just to return client's input1 back to the client  V3: oBoolean srmPing(int debug); oTypedef struct { int output1; int output2; } teststruct; oteststruct srmTest (int intput1, int input2); // just to return matching input1=output1, input2=output2

14. Compatibility in incremental versions V1 and V2 clients contacts V3 server without any problem for ping.  the optional argument null (automatically inserted by soap) is taken in V3 server. When V3 client contacts V2 server, it is working ok without the extra arguments setting in both ping and test. When extra argument is set, SOAP- FAULT is thrown for unknown parameter. Basically interoperability is not a problem.  It all depends on how the server handles the calls (being robust). Tests were done with Apache Axis

15. A possible choice for the Basic version? Have Basic based on SRM v.1.1 Enhance some features  e.g. Integer RequestID -> String RequestToken Enhance parameters to be concrete  e.g. Put requires SURL – not needed Enhance StatusCodes  Instead of: Pending, Ready, Running, Done, Failed Make obsolete certain features  e.g. MkPermanent => changeFileStorageType

16. What’s next? Decide what goes into the first Advanced version  Is it all other features in SRM v.2.1.1 ?  Is it subset of all other features in SRM v.2.1.1 ? Decide long term plans for Advanced versions