New features in this release:

• Full support for Visual Studio 2010 RTM
• .NET 4 support – You can now build your Windows Azure web apps and services using either .NET 3.5 or the new .NET 4.0 platform.
• Cloud Storage Explorer: browse the tables and blobs in your Windows Azure account from within VS
• Built-in Deployment: deploy your project to the Windows Azure cloud from within VS, with detailed status info every step of the way
• Service monitoring: monitor the status of your services in the cloud using the new ‘compute’ node in VS Server Explorer
• IntelliTrace support for debugging cloud service activity, with automatic log retrieval.  Requires VS 2010 Ultimate and .NET 4.0

More info on Jim’s blog post

Enjoy!

Share/Bookmark

Check it out!

Share/Bookmark

Windows Azure Tools also received coverage on Soma’s blog – woot!  Soma is Senior Vice President, Developer Division, and my nth degree boss’s boss.

While Jim is out working hard at PDC, back at the ranch we’re taking advantage of the calm following the PDC prep and product release storm to get a head start on the next round of features for Windows Azure Tools.

Share/Bookmark

I’m working on a scenario where I need to process mesh data at intervals. My concern is how I can do delegated authorization in a secure way. How and where do I store the user credentials (or their auth token) in my Windows Azure service? Is there a way of doing interval based processing in the cloud other than Windows Azure (excluding offerings from other third parties)?

You have three approaches to process data in a user’s Live Mesh at regular intervals: 

• An application that runs on the client machine
• A service that runs on a traditional server
• A service that runs in the cloud.

Client Application 

A client application running on the local machine can access the currently logged-in user’s mesh data.  Your app could be written as a desktop .NET Windows application, using the Live Framework SDK to connect to the user’s mesh.  Your desktop app will need to present valid authentication credentials to the Live Framework APIs; to avoid having to store and protect the user’s credentials, use the LiveID SDK.  If the user checks “remember me” and “remember my password”, your app can login on the user’s behalf using the LiveID API’s cached credentials.

You could implement your client app as a mesh-enabled web application, written in HTML+JavaScript or Silverlight.  User authentication is automatic in this situation, since the user must be logged in before they can run your app.  If the user has installed the Live Framework Client on their local machine, they can run your app on their local desktop just as they would a normal desktop app.  When your app is running on the local desktop, it will default to talking to the local cache of mesh data which is synch’d frequently with the cloud when the machine is connected to the network.

These client-side approaches may be sufficient for simple scenarios.  Client side code is convenient to write and doesn’t require allocation or management of server resources, but client side code is at the mercy of the local machine and network connection.  If your users tend to leave their machines on most of the time, this might be good enough, but if you need true round-the-clock processing you need a server side solution.

Traditional Server Application

You could implement mesh data processing in a traditional web server architecture, such as IIS with ASP.NET or Apache with PHP, Perl, or Python scripting.  This will require delegated authorization, and delegated auth requires that your server have a stable domain name.

Delegated authorization requires that the end user approve or opt-into allowing your application to access (parts of) their mesh data.  This approval must take place using a special Microsoft branded web page, so that the user will know that they are telling Microsoft that it’s ok for you to access their data. 

The flow typically looks something like this:

1. Your web page explains what data you want access to, and what you will do with it, and then forwards the user to a Windows Live authorization page
2. LiveID login will interject if the user is not already logged in, then forward to the intended page
3. The user reads the information on the Windows Live web page and chooses to allow or deny access to your site (your domain).
4. The user’s response forwards the user back to a landing page on your web site.  If the user allowed access, this response will contain an authorization token.
5. You store the authorization token in your system, usually paired with the user’s name within your system so you will know which auth token to use to access this user’s data in the future. 

How you store this auth token is up to you, but it should be under physical and network access protection.  At a minimum, you should encrypt whatever table or file you store the auth token in and restrict access to the file to only the administrators and web services that need to access it. You should also avoid transmitting the auth token across the network except when needed, and only via a secure SSL connection.

The auth token cryptographically combines your domain name with the user’s LiveID username.  The auth token can only be used on requests made from your domain name, can only access that particular user’s data, and can only access the kinds of data the user gave you access to.  The user can revoke your access (invalidate the auth token) at any time using the Windows Live web site.

Once you have the user’s authorization to access their data with the auth token, accessing their mesh data is fairly straightforward.  You can use the Live Framework SDK to make data requests of the user’s mesh data from within an ASP.NET server app, or you can make plain old REST style HTPPS requests to the Live Services cloud using your favorite server scripting tools.  You add the delegated authorization token for the particular user in a header to outgoing requests.

And finally, you can schedule your service to check the user’s mesh data on regular intervals, using cron or AT or whatever scheduling tool is appropriate.

Cloud Service

You can implement your mesh-checking logic in a hosted cloud environment, such as Windows Azure, Amazon EC2, GoogleApp, or a variety of other hosting providers.  You will still need to use delegated authorization as with the traditional server scenario and walk through the same steps to obtain the user’s permission and be issued an auth token. The code you write to access the user’s mesh data using the auth token is pretty much the same as what you would write in the traditional server scenario.

Data security is a core requirement of every app, but especially of cloud hosted applications.  I think you’ll find data security is a core component of Windows Azure cloud data services. You can store the username + auth token in a table in Azure’s cloud data service.

Scalability and cost management are where running as a cloud service has a distinct advantage over the traditional server scenario.  Scalability is easy: having the option to fire up additional instances of your cloud service by the tens or thousands as needed to meet demand is a key aspect of large scale cloud hosting that traditional servers in the closet or co-lo’s can’t begin to touch.

If your application needs to be checking the user’s mesh data every 5 minutes all day every day, the operational differences between cloud and traditional server will be relatively small, and perhaps offer no cost savings at all. 

If your application needs to run only during business hours or only on certain days of the week, you can do something with a cloud service that you can’t do with a traditional server, hosted VM or co-lo:  You can turn the cloud service off when you don’t need it, and stop paying for it until you turn it on again.

Anticipating a holiday rush?  You can scale up your customer capacity to massive volume during the holiday shopping crunch, then get rid of it in January and coast by on a shoestring ops budget until the next holiday surge.

If your mesh-checking app needs to check for changes in the user’s mesh data every 5 minutes, your service will be running pretty much non-stop.  If you only need to check 4 times a day, though, you might just turn your cloud service off until the next update interval.

When designing your mesh-checking architecture, be sure to take a close look at the notification features offered by Live Frameworks.  Notifications and data sync metadata could significantly reduce the frequency and amount of work your app needs to do to detect changes.

Share/Bookmark

 Dare closes the article with this:

On the flip side, the client-side Live Operating Environment is a technology whose benefits elude me. I admit it is kind of cool but I can’t see its utility.

The answer, in a word, is “offline.” 

The local Live Operating Environment (local LOE) is what makes running mesh-enabled web applications on the desktop, outside the browser, possible.  The local LOE creates and manages a sandboxed execution environment for the mesh app, just like a browser would for an HTML+JavaScript or Silverlight application but without the browser UI frame looming overhead. 

It seems like a trivial thing, whether or not the browser frame surrounds your app UI. Does it matter? The answer is yes – having your app surrounded by browser UI constantly and forcibly reminds the user that this isn’t a real app, it’s just a web page with lipstick.

This is doubly true if you throw offline execution into the mix.  We’ve done a great job drilling into non-technical heads that viewing the web is an online activity (Yes, browsers have offline cached content modes now, but have you ever seen any non-geek use them?).  Now say we’re offline.  “I can’t get to the web, but I can get to that app in the browser?  (wimper) I don’t understand!” or “I click on this shortcut and it brings up my app in the browser. Hey! Is the network connected?  How did that happen?”

There is no such confusion when the user perceives a desktop application that uses the network. The best way to dissociate the app from the browser is to not show the app inside the browser. Thus we arrive at one of the holy grails of web apps: to run on the desktop and look just like any other client app on that local machine.

But I digress.  Back to the LOE.

The local LOE coordinates the data sync between the cloud and the local machine to keep the local cache of Mesh Objects and their data feeds up to date with changes made in the cloud, and to push changes made locally up to the cloud.  This includes pulling down updates to the mesh apps themselves, since they are stored in Mesh Objects also. (Well, isn’t that conveeenient…)

The local LOE manages the user login and identity for mesh-enabled web apps running on the local desktop, just as the browser does for web apps running in the browser.

The local LOE implements the Live Framework APIs for data feed reading, editing, and synchronizing, so that a mesh-enabled web app can use the same APIs with the same semantics whether it’s running in the browser talking to data stored in the cloud or running on the local desktop talking to data stored (cached) on the local machine.  The only real difference between cloud and local is the domain name, and the mesh app doesn’t even have to care about that (the Live Framework client library will take care of it).

Having the local LOE doing all of these things on the local machine gives you the ultimate goal: running mesh-enabled web applications offline, while the network connection is disconnected completely or connected only intermittantly. The local LOE provides the execution environment, the data storage and data sync, the user identity credentials, and the RESTful APIs that the mesh app expects from a cloud - when there isn’t a cloud.

This is a very different approach from the path we chose when building Google Gears (I was a founding member of the Gears team at Google in 2005).  Google Gears is first and foremost a browser extension. We joked at the time that you can talk about getting the browser out of the app (creating “chromeless” web apps with no apparent browser UI), but not getting the app out of the browser. For Google, the browser is the platform, end of discussion. 

The Live Framework local LOE is exactly the opposite – it’s a client application that works like a browser.  It may even create an instance of the browser internally (I don’t know the internal details of the LOE) but it is fundamentally treated as “not the browser.”

Take the challenge of executing JavaScript while offline.  In Gears, we figured out some neat tricks to have our browser extension tap into the browser’s URL decoding stream, so that we could intercept requests for JavaScript URLs that we had cached or preloaded in local storage.  This even worked for desktop shortcuts that contained URLs to our web app.

In Live Framework, such interception tricks are unnecessary because you’re either running the app on the local desktop (in the local LOE sandbox) or you’re running the app in the browser (in the cloud LOE). Either way, the LOE knows what to do.

I’m making no argument that either solution is better or worse than the other, just that their architectural assumptions are fundamentally different.

Regardless of whether you’re in the Google camp or in the Microsoft camp, I think it’s a fair statement to say that these differences of viewpoint accurately reflect each company’s core strength and focus:  Google wants the browser to grow to subsume the desktop;  Microsoft wants the desktop to grow to subsume the cloud.

Share/Bookmark