Application models for Astoria

When you combine technologies such as Silverlight or AJAX-style applications with Astoria there is an opportunity for building great interactive data-driven applications. However, this combination also results in a new ways of organizing the various pieces that make up the application, so the question on what is the right application architecture comes up.

I’ll tackle the question from the middle-tier/data service perspective, and how the interaction with the presentation tier works. I won’t touch on aspects related to building and managing the user-interface elements of the presentation tier.

One extreme: the "pure data" model

There is a class of applications that are just about data, with relatively or no semantics on top of it; or more likely, where semantics is deeply embedded into the data and doesn’t need a layer of behavior on top to surface or enforce it.

For those applications you can imagine pointing the Astoria service to the database, prepare a nice EDM schema that models types and associations appropriately, and leave the URI space open so client agents can freely use any part of it. This is great when the high-order bit is to share data with people or systems. The data in the store is readily available and with easy access; many tools can deal with HTTP and URIs; Astoria-aware tools and widgets can even make it trivial to display and manipulate data.

You would still setup policies for authorization and such, of course, but I see that as somewhat orthogonal to the semantics/behaviors that may go with the data. From the authorization perspective you would say who can read, who can write, when do you need to be authenticated to even see something and so on. It does happen often that some security aspects are derived from semantics (e.g. "my customers" implies that some components knows how to find customers that are assigned to me, and that is typically captured as data as well), in which case the "pure data" approach won't work in that particular scenario.

I’m not sure if there is a lot of applications that fall in this category, but I'm pretty sure its > 0.

The other extreme: the "pure RPC" model

Elaborate applications, such as those designed to support the operations of businesses out there, need more than "just data" pretty much always, at least for large portions of the data they operate on.

A way of approaching an application with these requirements is to build the core business logic on top of the data, and then provide an interface or façade that clients and other applications can consume. This is nothing new, and has evolved in what is currently called Service Oriented Architecture or SOA.

One of the key aspects of SOA is that contracts are clearly defined, and they are described in terms of operations; of course that the data used by those operations needs to be described as well, but the focus is on operations.

I think that there is a space where this is the right way of creating apps. It does introduce a bit of complexity, but you get in return the ability to build composite applications based on the metadata that describes individual components.

We (Microsoft) have a solid offering in this space through the Microsoft Windows Communication Foundation (WCF) stack. WCF handles the runtime and design-time aspects of this, supports various services and related technologies, and it even plays well with both the SOAP and the HTTP-only (should I say REST?) ways of doing things.

The main drawback of this approach, though, is that it's very hard to build generic frameworks/UI components on top. For example, if you had a "grid" widget, how would the widget be able to do paging and sorting (when the user clicks on a column heading) independently of the service operation being called? I am assuming, of course, that bringing all the data to the client and perform the operation there is not an option (as is the case in any reasonable sized data-set). I think there is an opportunity there.

A hybrid approach

Now that we went through the extremes, let me describe a hybrid approach that looks really promising in my opinion.

Typically in business applications you can find a mix when it comes to the data they consume and its requirements for business logic and enforcement of semantics on top of the raw data. I think that often in these applications you can find a part of the data that is still "plain", that doesn't need added business rules, it is just what it is; you also find the other part that does need business logic on top to make sense, or to say consistent, or both.

The relative sizes of the "pure data" and "data + behavior" parts depends on the nature of the application. I would expect, for example, that a public web site that is designed to share information will lean towards the "pure data" side, where as an internal business application would go the other way.

As I discussed in the Astoria Overview document, one of the key elements of the Astoria services is the use of a uniform URI format regardless of the particular data service you're hitting. This enables tools and frameworks to be built so that they leverage that.

These applications could be built by using two Astoria elements: flat access and "data aware" service operations.

For the parts of the data that are "just data", you could enable direct access to the data through regular Astoria URIs. This helps with development productivity, allows developers to use common widgets and libraries and reduces how much redundant code you write and maintain.

For the parts of the data that need business logic, you create the special form of WCF service operation that Astoria introduces support for, where you don't just return the final data that you want. Instead, you return "query objects" that represent the data you'd like to return. Since what is returned is a non-executed-yet query, the Astoria runtime can still compose query operations on top, such as sorting and paging, and then executing it in order to obtain the data to be sent to the client.

Let me use a brief example to illustrate this point. If you have a service operation that returns Customer entities for a given city, you would use a URI like this one to invoke it:

https://host/vdir/northwind.svc/CustomersByCity?city=London

Now, if this is a data aware service operation, the URI options that UI controls and such use to do their work would still work, so when the user clicks on the “CompanyName” column to sort it, the UI control could simply say:

https://host/vdir/northwind.svc/CustomersByCity?city=London&$orderby=CompanyName

in similar ways, using control arguments such as $skip and $top, the grid widget could support paging over any arbitrary data aware operation.

This offers a great middle-ground between plain open access to the store through URIs and fixed RPCs that do not support query composition. The service operation is still written as code in the middle tier that is controlled by the developer; that code can perform validations on arguments, adjust arguments based on the user or the context, inject predicates to queries based on various conditions and so on. In other words, they are the spot where you can invoke your business logic.

I focused on data retrieval so far. The hybrid approach can be used for updates as well. In those cases where it makes sense to allow direct updates to the data you can let the standard HTTP POST/PUT/DELETE operations do its work; for the other cases, where you do not want just an update but a more complex operation that may result in one or more updates, you can use a service operation.

A complementary tool: interceptors

A broad subset of the cases where you want custom business logic during updates, the requirement is to be able to perform validation that goes beyond the declarative validation that can be enforced by constraints in the EDM model or in the underlying database schema.

For those cases you can still use regular HTTP-style updates with POST/PUT/DELETE verbs, and register code to run in the server whenever an entity is being created, updated or deleted. In Astoria you can define an "interceptor" and bind it to a given entity-set and a direction (reading or writing); the interceptor is a regular .NET method defined in the service class that runs in the middle-tier (where the Astoria service runs). This method can do pretty much anything it wants (Astoria won't limit what it can do, although the runtime environment may). Astoria will even provide an already-established session to the database wrapped in an ADO.NET typed object context to provide easy access to the database in case you need to perform lookups in order to validate the operation.

BTW - if anybody can think of a better name than "interceptors", it'll be happy to take it :)

For more details and an example of this you can take a look at the "Intercepting Entities on Retrieval and Update" section of the Using Astoria document.

Summary

So, summing it up, I think that there is a good middle-ground between flat open access to data and pure RPC. I think that this middle-ground can enable frameworks and tools to help more and make it easier to build applications.

-pablo

Comments

• Anonymous
  May 04, 2007
  Message oriented interop between WCF and Oracle App Server WSIF [Via: ] Astoria: Microsoft's RESTful...

• Anonymous
  May 04, 2007
  I was going to write a blog post on Astoria but Pablo's post says almost everything I was going to

• Anonymous
  May 04, 2007
  Are you a cross between Pablo Picasso and Fidel Castro?

• Anonymous
  May 05, 2007
  "inspector" name-storming: the concept conjures up a likeness to aspect-oriented programming. E.g. custom entity logic to happen before or after r/w ops... or to redirect around; or change the results of; or block the operation altogether... Astoria interceptors... Astoria aspects... aspect behaviors... inspectors... aspectors... HttpAspect... EntityAspect... class MyCustomEntityAspect : EntityAspect { ... } or maybe RequestGarbler()... ServiceAspect, HttpApiAspect...

• Anonymous
  May 06, 2007
  I don't dislike "interceptors" completely, but another term that comes to mind is "handler". You could use "entity operation handlers" or any combination of the words.

• Anonymous
  May 06, 2007
  Here is what I think. The only time where you need to display data in an easy way, Astoria will make it easier (well, developers need to learn one more “query-language” and we already have different technology for query data-sources with URLs). But to mix WCF and Astoria in one app will make the app inconsistent, different technology for different way of getting data. So Astoria will only help if we want to build small apps that will only display data and where no complex logics are needed on the server side and where we don’t care that we have a “close” connection to the data source, right!? >In Astoria you can define an "interceptor" and bind it to a given entity-set and a direction< Will it be in a similar way as Jasper or another way? For me is sounds like it will be two different ways, even if Astoria and Jasper are working against the Entity Framework and use EDM Schemas. It would be interesting to see how many who are going to use Astoria over a service call from Ajax, and Silverlight in the future. Most apps need logics, and I think most part will make a call to a service, to make a separation of layers and reuse code etc. Honestly, wouldn’t it be better if you instead generate code out from the EDM Schemas (create the entities etc) and add a service layer on top with CRUD methods. At least that will give developers the possibility to “own” the code and they can also make modification to it, and also add logic etc. The service that will be generated could also take a query-object or language and paging info to easy ask for a specific entity or using paging over entities etc. CustomerService.Get(“AFKB”) CustomerService.GetAll() Var orderBy = “CompanyName” CustomerService.Get(“city = ‘London’”, orderBy) This is almost what Astoria is doing, but using the URL instead. By using a service that is generated, we can at least have access to the code, and also add our logic in an easy and normal way. The best thing is that you can re-use JASPER in the services and instead of having a specific “query-language” over URLs, we can reuse JASPERs options of doing queries (eSQL or the name is), that will give us one less of new “query-language” to learn.

• Anonymous
  May 06, 2007
  摘要又过去了一周，放假时间就是短暂……本期共有6篇文章：基于Go-Live许可的IIS7.0Beta3发布在ASP.NETAJAX中实现Mashup：使用代理访问远程APIMIX过...

• Anonymous
  May 07, 2007
  debit: I agree with you that if you are in the .NET programming environment you want a nice, typed experience on top of whatever EDM schema Astoria is exposing. And Astoria fully supports this model; you can point the client generator tool (clientedmgen.exe for now, until we complete our integration with WCF) to a service and we will generate types for each of your entities. The types we generate are partial classes, so you can extend them with custom logic and/or custom state. Going further, while it is not in the current CTP, we're experimenting with building LINQ support on top of the client API, effectively allowing you to formulate LINQ queries that will travel to the data service over vanilla HTTP.  LINQ support in this form will give you what you were asking for (CustomerService.Get(...)), but with a nicer syntax and compile-time checking. The nice thing about layering the client API and the LINQ support on top of regular HTTP requests and a URI space is that at the same time we address the needs of other groups of developers that want a HTTP-based interface and don't want any client-side libraries in their ways. Regarding the comment about Jasper...yes, of course, 100% agreed. The folks that built Jasper are in the same team I'm in and we talk every day. We don't have anything now, but we're looking at the options. -pablo

• Anonymous
  May 09, 2007
  Last week at Mix07 Microsoft announced a project code named Astoria. The technology code named Astoria

• Anonymous
  May 10, 2007
  2 things: -SQL Server 2005 Reporting Services/Report Builder does a similar sort of thing with the Report Model, just in a different context, anyhow this "webby" model is an excellent idea -Could you do a better URI system (perhaps with some URL-Rewrite) so that MSN/Live search engine can scan/index the URLs better

• Anonymous
  May 10, 2007
  Lors du Mix de las Vegas, Microsoft a annoncé de très nombreux projet, je me suis récemment interessé

• Anonymous
  May 10, 2007
  Lors du Mix de las Vegas, Microsoft a annoncé de très nombreux projet, je me suis récemment interessé

• Anonymous
  May 11, 2007
  Stefan: Regarding "better" URIs for indexing: yes, we understand that we have to do something about the broad "search engine optimization" problem space. It's not there in the current bits and we don't have something baked enough to try to articulate, but we're aware of the issue. When we have some thoughts on how to approach it I'll publish them so you can take a look and let us know what you think. -pablo

• Anonymous
  May 14, 2007
  Last week at MIX07 Microsoft announced a project code named Astoria. The technology code named Astoria

• Anonymous
  September 30, 2007
  Hi Pablo, Is the hybrid approach still considered REST? i.e. Is using control arguments still REST? Can REST URLs contain control arguments? Also, Interceptors seem like Pre-processors to me. Do you also have a concept of post processors? Thank You, Vish

• Anonymous
  September 30, 2007
  Hi Vish, Strictly speaking the answer is probably no, it cannot be considered REST. That's because REST defines a "uniform interface" that's being broken here. That said, I think that in pretty much every concrete, real-world system architecture there is a level of separation from principles. Astoria is designed to allow you to build a pure-REST system that follows the principles around it such as having a uniform interface, presenting a strictly stateless interaction model, being cache friendly and in general allowing layering. However, I believe that the REST support alone won't be enough in many application scenarios. In those scenarios I still think that there is a lot of value of having a "mostly resource oriented" system, with some actions to support specific application elements. Re: post-processors...we currently do not have a similar construct in Astoria. Whether we'll add it depends on whether we see a lot of users coming up with concrete scenarios that require them. -pablo

• Anonymous
  December 04, 2007
  摘要 又过去了一周，放假时间就是短暂……本期共有6篇文章： 基于Go-Live许可的IIS7.0Beta3发布 在ASP.NETAJAX中实现Mashup：使用代理访问远程API...

• Anonymous
  April 24, 2008
  I was going to write a blog post on Astoria but Pablo&#39;s post says almost everything I was going to

• Anonymous
  March 03, 2009
  hi , i need a help regarding the ado.net data service... can u help me pls.... Am able to do data service and view them in IE 7 Now i added windows appication with web application(which has the web service) i added the web service to the windows application... Am able to see the values of customer and order table in the form. Wen i tried to edit the values of the cutomer or order using Enedit() ,i have given Service.savechanges() in code... It shows the error like "DataserviceRequestException Error" Wat should i do further... the changes wat i made is not stored in db :( help me....waiting for reply :(