In BLOB storage, you can t store BLOBs directly in a storage account because every BLOB must live in a container. A container is really a top-level folder. Although you can set permissions directly on a BLOB, this can be a pain with a large number of BLOBs. To alleviate that administrative headache, you might want to group similar BLOBs that

have similar access levels in the same container. Then you can set permissions at the container level rather than at the individual BLOB level. In BLOB storage, there are two levels of access that you can set on a container: private and public.

BLOBs in a private container are restricted to the owner of the account. If you need to list the contents or download a BLOB stored in a private container, you need to make a request signed with your shared authentication key (in the next chapter we ll show you how to do this). In figure 8.5, the container ChrisOriginals is a private container. If you wanted to access the BLOB podcast01.mp3, you would make a GET request to the following URI (this request must be signed with either your account master key or a pregenerated shared key; we ll explain this later): http://silverlightukstorage.blob.core.windows. net/ChrisOriginals/Podcast01.mp3.

Using Barcode drawer for iPhone Control to generate, create QR Code ISO/IEC18004 image in iPhone applications.

www.OnBarcode.com

If the container is set to full public read access, then you can retrieve any BLOB held in the container over HTTP without providing authentication credentials. Not only that, you can list all the BLOBs in that container and query data about the container. With public read-only access for BLOBs, anonymous requests will only be able to read a BLOB (you won t be able to read container data or list the BLOBs in the container). In figure 8.8, the container ChrisConverted is a public container; anyone on the internet would be able to download the file podcast01.wma by making an HTTP GET request to http://silverlightukstorage.blob.core.windows.net/ChrisConverted/Podcast01.wma. If you need to perform any operations beyond the container permission level (for example, if you need to upload or modify a BLOB), you need to provide authentication credentials (account owner or shared access) because these operations are restricted operations. So far we ve talked only about the live BLOB storage service. Now we ll take some time to look at how you can develop against the BLOB storage service by using a development version of the BLOB service that s in the development storage service.

Development storage hosts all three storage services (BLOB, Queue, and Table storage services) and exposes local endpoints that implement the same APIs as the live service. The production version of the storage services and the development version are two completely different animals. They might expose the same APIs, but the development version is greatly simplified and suitable only for local development. When you ve finished developing your application against your local development storage, you can easily switch to using the live environment by just changing configuration.

The basics of BLOBs

SQL Server backing store

Because the development environments and the data centers of Windows Azure are drastically different (we don t have replicated storage arrays on laptops), the SDK can provide only a simulation of the live storage environment. Although development storage and BLOB storage are API compatible, the underlying implementations are understandably different. In the development storage version of BLOB storage, SQL Server is used as the backing store.

Installation issues

By default, the development storage database is created in the SQLEXPRESS named instance of SQL Server on your development machine. This instance is normally installed as part of the Visual Studio installation, which is why the SDK assumes that this instance is present. If you need or want to install the database onto a different SQL Server instance, you can use a tool in the SDK called DSInit.exe. You might want to do this if you prefer to run a full-blown version of SQL Server on your machine or if you skipped installing the SQLEXPRESS instance during the Visual Studio installation.

If you want, you can even run queries against the database to ensure that your data is stored as you expected. Figure 8.9 shows all the tables representing the various storage services in the SQL Server implementation. Although the development storage system uses SQL Server (as shown in figure 8.9), the real BLOB storage system uses a higher performing, more scalable, cusFigure 8.9 Development storage database in SQL Server tom solution that makes the best use of the Windows Azure infrastructure. You can be assured that your BLOBs aren t stored in some SQL Server table in the live system.