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.
1. 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.
|
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 1 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 1), the real BLOB storage system uses a higher
performing, more scalable, custom 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.
2. Getting around
in the development storage UI
The development storage
service is automatically started whenever you run a web or worker role
project in Visual Studio. The startup of development storage occurs at
the same time as the startup of the development fabric.
If you right-click the Cloud Services icon in the status bar
and select Show Development Storage UI, the Development Storage UI is
displayed, as shown in figure 2.
The development storage UI
shows you the current status of your services and lets you stop and
start them if you need to. Although development storage and the
development storage UI are automatically launched when you run your
application in Visual Studio, you can start them manually using the
command line. This can be useful if you’re interacting with the storage
services from an application that’s not hosted in the cloud (a normal
WPF application that just uses the BLOB storage service).
|
To start development
storage manually, you can use the following command:
C:\Program Files\Windows Azure SDK\v1.1\bin\devstore\dsservice.exe
To shut down the service, you
can use this command:
C:\Program Files\Windows Azure SDK\v1.1\bin\devstore\dsservice.exe/shutdown
|
With the basics of both BLOB
storage and development storage under your belt, get ready! It’s time to
write your first application that talks to the BLOB service.
