1 / 8

Storage Resource Management: Functional and Operational Specifications September 14-15, 2005

S torage. R esource. M anagement. Storage Resource Management: Functional and Operational Specifications September 14-15, 2005 Meeting at Jefferson Lab http://sdm.lbl.gov/srm-wg. Framework. Framework Def. Functional Interface. Operational Interface. Lang. Interface.

thiery
Download Presentation

Storage Resource Management: Functional and Operational Specifications September 14-15, 2005

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Storage Resource Management Storage Resource Management: Functional and Operational Specifications September 14-15, 2005 Meeting at Jefferson Lab http://sdm.lbl.gov/srm-wg

  2. Framework Framework Def. Functional Interface Operational Interface Lang. Interface Functional Design SRM-CORBA Operational Interface V1.0 SRM Joint Functional Design V1.0 SRM-CORBA IDL Interface V1.0 SRM Joint Functional Interface V1.0 SRM Joint Functional Design V1.1 SRM-WS Operational Interface V1.1 SRM-WS WSDL Interface V1.1 SRM Joint Functional Interface V1.1 SRM Joint Functional Design V2.0 SRM Joint Functional Interface V2.0 SRM Joint Functional Interface V2.1 SRM Joint Functional Design V2.1 SRM Joint Functional Interface V2.1.1 SRM-WS Operational Interface V2.1.1 SRM-WS WSDL Interface V2.1.1 SRM-WS Operational Interface V3.0 SRM-WS WSDL Interface V3.0 SRM Joint Functional Design V3.0 SRM Joint Functional Interface V3.0 . . . SRM-WSRF WSDL Interface V3.0 SRM-WSRF Operational Interface V3.0 History of Functional and Operational SRM specifications

  3. FEATURE 6 f1 (F3) FEATURE 1 FEATURE 5 f2 (F3) f1 (F1) f2 (F1) CORE f3 (F1) f1 (C) f3 (C) f2 (C) f4 (C) FEATURE 2 FEATURE 4 f7 (C) f5 (C) f1 (F3) f2 (F3) f6 (C) f8(C) f3 (F3) FEATURE 3 f4(F3) f1 (F3) f2 (F3) Extending functions for advance features • Issue: what to do in the case of functions that are in core, but are also used in advanced features with additional functionality • E.g. Specifying a space-token for srmRemoteCopy when “space reservation” feature is supported. • Solution: Extending parameters according to features

  4. Expressing Overloaded Functions in Operational Spec • Issue: given a core function • Some parameters are relevant only when some advanced feature is supported • e.g. srmPrepareToGet: space_token only relevant when “space reservation” feature is supported • Some parameters change what is valid with advanced feature • e.g. srmPrepareToGet: SURL can be a directory if “directory” feature is supported • Issue can come up with advanced function as well • e.g. srmRemoteCopy: SURL can be a directory if “directory” feature is supported, and space token is valid only if “space management” feature is supported • Possible solutions • Have a way for clients to know which parameter combinations to use • Have explicit functions (i.e. methods, portTypes) for each combination

  5. Possible Solutions – pros and cons Solution 1: Explicit Functions Function F(i)

  6. Possible Solutions – pros and cons Solution 1: Explicit Functions Client needs to know which method to call for desired function

  7. Possible Solutions – pros and cons Solution 2: Overloaded Functions Client needs to know which parameters to use for desired function Note: Combination can be determined by AND’ing parameter vectors Therefore, there is no need for feature combinations

  8. Possible Solutions – pros and cons • Both solutions • Clients need to know what to call, based on features supported • Either which explicit method (e.g. srmRm.1, srmRm.2, etc) • Or which parameters (e.g. p1, p2, p3, etc…) • clients need to know when new features are added or changes made to parameters • But • Solution 1 • Requires new method variations when new features are added that effect a function • Requires extensive changes to existing WS server and client that wishes to use the new feature • Solution 2 • Requires only new WSDL with minimal change on the server and client • Can keep the specific method variations at the client API or command line and keep the SRM interface simple • Easy transition from existing v.2.1.1 • Alternative to clients • Multiple specialized (thinner) clients – not attractive • solution 2 seems better

More Related