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 Group

Lawrence 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

o e.g. srmGet, srmPrepareToGet

Function parameters compatibility (subset of later versions?)o ls (path, recursive, offset, count, …)

Functional equivalenceo e.g. srmGet => auto-pin from time file is in cache

Upward compatibility between versionso Client of earlier version works with next version

How to make function obsolete?o e.g. mkPermanent, pin, …o What mechanism? Deprecation time?

Issue 2 :View points

• Top-down view

SRM Functions

AC

L

…………

Advanced

BasicA

ccounting

Copy

Space R

eservation

Multi-file

operation

Lifetim

e per file

Issue 2: View points

• Bottom-Top view

SRM Functions

… …………

Advanced

Basic

AC

L

Accounting

Copy

Space R

eservation

Multi-file

operation

Lifetim

e per file

……

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

o What do we call future versions? Advanced2? Advanced3? …

o 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.o 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 functionalitieso 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?

… ………

Advanced 1Basic

Adv Func

21Copy

Multi-file

operation

Lifetim

e per file

Advanced 2

Adv Func

22Adv Func

12Adv Func

11

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:

o Boolean srmPing() V2:

o Boolean srmPing()o Typedef struct {

int output1;} teststruct;

o teststruct srmTest(int input1); // just to return client's input1 back to the client

V3:o Boolean srmPing(int debug);o Typedef struct {

int output1;int output2;

} teststruct;o 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