Architecture
Zhenhua Guo
Jul 23 2007
broker/proxy Amazon S3
request
Web-based receive request adapter
adapter GFS
Interface execute request
adapter
response
send response
…
Stub functions
Some common API stub functions are defined at broker/proxy above. For example:
createFile
closeFile No concrete implementation now.
Actually just pointers to the
deleteFile
implementation in adapters
renameFile
…
renameFile
Adapters
For every backend file system ( Amazon S3, or GFS or others ), there is a corresponding adapter.
The adapter implements all the stub functions by using methods specific to that file system.
adapter1 Amazon S3
createFile
closeFile
deleteFile
request our API stubs renameFile
…
createFile renameFile
closeFile
adapter2
deleteFile
createFile
dispatcher renameFile closeFile GFS
… deleteFile
renameFile
response renameFile …
renameFile
Procedure to Use a new file system:
(1) reset the API stub functions
(2) register the stub function implementation of the new file system
Several storage services can be used simultaneously.
Problems:
(1) Different storage services provide different functionality, how to define APIs which are
common to most services?
(2) Format of messages used to carry request and response.
I prefer XML. Maybe messages of RPC can be consulted. JSON? Or others?
Next Step:
(1) Define detailed requirement specification.
(2) According to our requirements, define UI components and stub functions.
My resource My shared resource Public resource
- root ..
+ directory1 directory11 directory12
+ directory2 file11 file12
+ directory3
* file1
* file2 author: king
…… size: 1234 Bytes
tag: game silent hill
rate: 4/5
…
Privileges:
delete a file
create a file
add/remove/edit tags
add/remove/edit comments
……
Granularity of Access Control:
private ( only the owner is able to access and edit the resources and associated properties )
public ( all users can access and edit the resource and some properties )
No other policies are in-between.
Maybe in the future we can add more complicated mechanism.