Hi folks, In our platform - we don't yet have a solution for storing static files in the cloud. A solution that provides a simple service of persisting a file and getting back a URI. The Enterprise Store team built a storage module in the Publisher app that provides persisting of files to a database and getting back URIs. My proposal is to build a jaggery-app that specifically handles file storage with a REST interface extending what the ES team has done.
*Use case* I will be using the Enterprise Store as an example for the Storage App. [image: Inline image 1] 1:- Developer uploads a file to the publisher app using an entry form 2:- Publisher app calls the storage module to contact the storage provider 3:- Storage module contacts the Storage app with a HTTP PUT call and returns the URI of the file persisted. Publisher app will persist this URI to the registry along with other information. 4:- A client contacts the server requesting an asset page. 5:- The server will contact the storage module to request a token. It will in turn call the Storage app requesting a token. After retrieving the token It will append the token to the URI when rendering the pages server side. 6:- Browser will contact the Storage app directly when requesting the file using HTTP GET. Since the browser is passing a valid token - Storage app will return the file in the response. *Architecture overview* Storage app will have service providers. These service providers will be apps that require the Storage service from the Storage app. First let's start off with the API. Storage app will provide an HTTP interface as below GET GET interface is used to request a file. The request can be for permanent links or token based links. PUT PUT can only called by a registered service provider. A token (Provider token) has to be passed to validate the service provider. It will also allow options of - security, permanent links etc. DELETE URI is passed to the DELETE API as well as the provider token. Used to delete files. Next is what the real storage options are. For the first cut we can have the storage app connected to a database. Afterwards we can move to HDFS type storage or Cassandra perhaps. As with Multi-tenancy - we can handle multi-tenancy the same way we handle it for jaggery apps (SaaS multi-tenancy). Ultimate objective of this proposal is to build a cloud storage service like Amazon S3, Google Cloud storage [1]. WDYT guys? [1] - http://www.quora.com/Amazon-S3/What-are-the-best-alternatives-to-S3-and-what-are-the-pros-and-cons Cheers~ -- Chan (Dulitha Wijewantha) Software Engineer - Mobile Development WSO2Mobile Lean.Enterprise.Mobileware * ~Email [email protected] <[email protected]>* * ~Mobile +94712112165* * ~Website dulithawijewantha.com <http://dulithawijewantha.com/>* * ~Blog blog.dulithawijewantha.com <http://dulichan.github.io/chan/>* * ~Twitter @dulitharw <https://twitter.com/dulitharw>*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
