News

Access Cloud Data With Astoria

• By Lee Thé
• September 28, 2007

By "cloud data services," Microsoft means data living on the Internet in a publicly accessible location. Anyone can reach the data over HTTP, using uniform resource identifiers (URIs) to identify the pieces of information offered by the service. User applications interact with the service using HTTP verbs such as GET, POST, PUT and DELETE. Data exchanged in those interactions are represented by formats such as XML and JavaScript Object Notation (JSON).

Astoria represents a break from traditional Web applications, which use Web pages that combine presentation, behavior and data. New Web technologies, including AJAX, rich Internet applications (RIAs) and mashups (which integrate data from multiple sources), help developers work toward the desirable goal of separating data on the one hand from presentation plus behavior on the other. Astoria serves that goal as a proposed common standard.

Wright, a Microsoft .NET architect evangelist, addressed himself to the needs of JavaScripters in particular.

"All the AJAX technologies give you a way to abstract the UI [user interface]," he said, "but they don't provide a common framework for accessing data."

Instead, developers must choose between "a bunch of frameworks." Yet most developers would like to make the client side somewhat independent of the data sources. Moreover, existing frameworks all have various problems, he added.

Query Without SQL
For Wright, the worst data access option is building SQL query strings on the client side. This leaves the server vulnerable to attacks. And "it's not useful to expose the underlying SQL if you don't want to work at that level on the client side," he said, adding that in general, there's too much dependence on the client. It hasn't been decoupled from the server sufficiently.

He gave a nod to Tibco's General Interface toolkit, which was also discussed at AjaxWorld. He called it "a more robust client-side framework." But he added that it's still not standard: "Wouldn't it be nice if we had some standard way of getting at back-end data?" The solution is Astoria, which Wright characterized as being especially valuable for the small/independent developer that needs flexibility.

Astoria meets the four key requirements for Web data services, according to Wright:

• It's Web friendly and uses plain HTTP;
• It employs uniform patterns;
• It focuses on data, not on formats; and
• It stays high-level, abstracting the store.

Moreover, Astoria doesn't require a rich client or Simple Object Access Protocol (SOAP), which he characterized as not being simple enough for the average developer, despite the claim in its name.

Those who want to start working with Astoria need to use it with Visual Studio's beta 1 release, which has been released. Wright said that VS 2008 is supposed to ship by year's end, with the shipping version of Astoria due soon after. Right now, Microsoft's Data Programmability team is actively soliciting feedback on the current release, which they call a "Community Technology Preview."

Astoria's high-level model uses an entity data model with first-class entities and associations. It features uniform URIs, using entities as resources, and enabling filtering, sorting, navigating and paging. Astoria supports flexible formats: plain XML, RDF+XML and JSON. It lets you exchange data both ways. For retrieving data, you use generic URIs and operations, with options including sorting, paging and navigation. You store data using the same URIs with HTTP verbs.

Microsoft offers an online service developers can use to learn Astoria and run experiments. It includes sample data sets, and it lets you create custom data services hosted in the Astoria online service.

Build a Web Service Layer Without SOAP
Wright demo'd building a cloud data service. He created an ASP.NET Web application in VS 2008 that let him set up access to a database. Wright pointed out that it's quite easy to create the entity data model that surrounds the database, and then hook it up to a Web interface. He used this data model against a generic Northwind server.

Wright mostly built his app using drag and drop methods. When he attached the Web service, he observed that you don't have to use C#. You could map from any .NET language, or even another language. And he emphasized that the Web service layer isn't a SOAP layer. It's a RESTful data service -- a representational state transfer interface -- transmitting domain-specific data using neither SOAP nor session tracking via HTTP cookies.

Wright said all you really have to do is tell the Web data service what namespace to use, then what base object you want it to map to within that entity set of classes. Once you've done that and compiled it, the wrapper is fully RESTful. You can use that data from any client through the Web; you can also determine selectively which entities you want to expose on the Web. You can do post-processing on it as well, with security, data validation and filtering. And you can set objects to come back as JSON objects. This is safer than a SQL query, because it's being parsed on the server side with pre- and post-conditions.

The key takeaway, according to Wright, is that everything is done within the URI itself: lightweight, easy to adopt, with little needed on the server side.

"Astoria is one step towards reaching common industry acceptance of URIs," he added.

Sometimes the industry gets out ahead of the developers. Wright asked the audience how many needed to be building out mashups or Web apps that aren't embedded in one specific database. Nobody raised their hand. He quickly went on to describe other useful Astoria scenarios, such as Silverlight apps using data services, using it from Adobe Flash, a variety of RIA environments, for stateful mashups, for state storage and management for widgets and gadgets, and probably even richer use of this from standard apps trying to connect to the cloud. Basically, Astoria "should be drop-dead simple and not require proprietary APIs on client or server," he said.

Use Astoria With AJAX or RIAs
For AJAX applications, most AJAX frameworks will work. HTTP plus JSON is simple enough. Server pages render the UI plus behavior, while data come out-of-band through the data service. For RIAs, you can build Silverlight apps using Web data services. A "Web data" client works in Silverlight, and it uses a natural .NET programming model.

For stateful mashups, the data service adds a data source specific for the mashup, along with a persistent store for control data, user preferences, configuration and more. You also get a place in the Web to store state. For Web-enabled desktop apps, you can use full desktop applications. They'll interact with the data service over HTTP directly or with a small-footprint .NET client library, using data as .NET objects.

Looking forward, Wright's team will probably iterate again around year end. Avenues being explored include a search for viable, secure authentication schemes, search engine optimization, and more features, such as batching, granular security, synchronization using RSS/SSE, and feed format support.

The biggest concern expressed in the Q&A session centered on security. Wright conceded that "to enable anyone to use it, it means you're going to see people try to hack someone's data source." But "server side, you have a chain with pre- or post-conditions you want, but you never take that string as sent up and execute it as you would with a SQL string, which opens up an attack vector. The aim for Astoria is the spot that's missing: coding up a data access layer to an existing database."

He agreed that AJAX security left a lot to be desired. On the other hand, you can use any ASP.NET security provisions you wish. "If I want to put an HTTP handler ahead of a request I can," he said.

Wright ended by encouraging the audience to get involved, assuring them that the team really wanted to hear from them, and that their dream feature might well get included if they get involved.