# Presentation: 157115

**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 GuScientific Data Management Research GroupLawrence Berkeley National Laboratory

## Issue 1

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

## Issue 2 :View points

**Issue 2 :View points**

**Top-down view**

- SRM Functions

- ACL

## Issue 2: View points

**Bottom-Top view**

- SRM Functions

## 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**
**What do we call future versions? Advanced2? Advanced3? ...**
**Perhaps best to stick with version numbers only?**

## Issue 2: view points

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

## questions

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

## 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?**

## 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.**

## 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.**

## 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 ?**

## 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.**

## Compatibility in incremental versions

**Test was done for the following cases: all parameters are optionals.**
**V1:**
**Boolean srmPing()**
**V2:**
**Boolean srmPing()**
**Typedef struct {****	****int output1;****} teststruct;**
**teststruct srmTest(int input1);  // ****just to return client's input1 back to the client**
**V3:**
**Boolean srmPing(int debug);**
**Typedef struct {****	****int output1;****	****int output2;****} teststruct;**
**teststruct srmTest (int intput1, int input2); ****// just to return matching input1=output1, input2=output2**

## 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**

## 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**

## 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**