Developing Cloud Applications with Windows Azure Storage: Blobs
- 3/15/2013
- Blob basics
- Blob containers
- Blob addressing
- Business use cases
- Blob storage structure
- Navigating blob container hierarchies
- Storage Client library blob types
- Container and blob naming rules
- Performing create, read, update, and delete blob operations
- Shared Access Signatures and shared access policies
- Blob attributes and metadata
- Conditional operations
- Blob leases
- Using block blobs
- Using page blobs
- Blob snapshots
- Continuation tokens and blobs
- Conclusion
Blob storage structure
Figure 5-2 shows the hierarchical relationships between storage accounts, blob containers, blobs, and pages. A Windows Azure storage account encapsulates zero or more blob containers, and each blob container can in turn encapsulate a set of zero or more blobs. The final column of Figure 5-2 shows the encapsulation of the individual blocks or pages of a blob.
){kind=link}
Figure 5-2 The blob storage structure is a hierarchical relationship between storage accounts, blob containers, blobs, and pages.
A storage account can be visualized as being similar to the root directory of your computer’s hard drive, where the blob containers are like directory folders. Individual blobs can be thought of like files placed in a directory. Furthering this analogy, blobs are frequently named with common suffixes matching their content type (just as files are named with extensions that reflect their types, such as the .jpg or .png file extensions for image files, and the .docx extension for a Word file). Unlike the directory structure on your computer’s hard drive, which can contain nested subfolders, blob containers cannot contain subcontainers. The way that subfolder-like behavior can be simulated is discussed a little later in this chapter.
For security and architectural reasons, there may be requirements for a blob to be physically located in the base address of a URL. For example, a cross-domain policy file is an XML document that adheres to a specification published by Adobe. This kind of file is used to grant web clients such as Microsoft Silverlight, Adobe Flash Player, and Adobe Reader permission to handle data across multiple domain boundaries. When a client running from one domain makes a request for a resource located in a secondary domain, the secondary domain must have a cross-domain policy file granting access to the requested resources in order for the web client to continue with the request. The specification requires that the file be named policy.xml and that it be located in the root directory of the secondary domain.
Because blobs must be stored in a blob container, a special hidden blob container named $root was created. The $root container is aliased to the base address of the domain. Any blob placed in the $root container will be accessible both by its physical URL (including its $root container name) and by its alias URL off the base address of the domain. The following two URLs are equivalent:
http://www.wintellect.com/$root/Policy.xml http://www.wintellect.com/Policy.xml