Can project code name "Astoria" align with SOA?
I've been doing some reading on Astoria (and generally on the REST architecture style) recently, and although I have one serious reservation I'm about to discuss I think this is a very interesting area to look at;
What is my reservation regarding "Astoria" then? well, I'll start by saying, of course, that it could very well be simply my lack of understanding, and of course this is all based on a very first impression of "Astoria", and I'm quite certain a lot is still about to change in this area (which is why many "smaller" questions can simply be left aside for now I think), but anyhow - what I'm not sure about at this point is whether, and how, can "Astoria" and SOA fit together, as to me they seem to conflict.
I will not explain Astoria here, as there is enough information out there, but if you just take one sentence from the link provided above - "The goal of Microsoft Codename Astoria is to enable applications to expose data as a data service that can be consumed by web clients within a corporate network and across the internet. "
Also, from playing around a little bit with Astoria, and from Guy's demonstrations , I see "Astoria" as an easy way to publish REST like data services to allow a client to perform CRUD operations on data entities; currently SQL Server is supported, but it is quite obvious this is going to evolve to other platforms.
So - my problem is, quite naturally I should think, with the CRUD bit; I like services, and I am learning to like REST (although have not used it in practice anywhere yet), but over the last couple of years I've been hearing all around (not to say thinking on my own right) that CRUD services are bad, and I do think there are lots of reasons as to why they are bad (some are very nicely explained here)
Do we really want a service that simply provides create/read/update/delete operations on a table, or view?
As I've mentioned before - this raises a lot of questions around security, and transactions etc. some can be solved simply by the fact that "Astoria" is built on WCF which provides support for some of these, but will it be enough? Time will tell.
Either way, from a design perspective, it seems to me that CRUD services like that are only useful, at least in my (narrow?) world, when they actually form a part of a bigger service, one that would actually provide business logic on top of the data logic, and that will "speak" in business terms rather the database entities terms.
For example, if I had a service that maintains inventory in a warehouse, and a product was to be shipped to a customer, using a CRUD-like service you would update a row with the new inventory value (so your message would look something like-[Update inventory for product 'x' with '15']);
Using a business service, the message you would send will probably look something like ['2' items of product 'x' need to be shipped to customer 'y']; the service can then update the stored inventory with the correct value (without worrying about concurrency, I might add), as well as do whatever logic is required around that, for example initiating the packaging and shipment of the product to the customer, updating other systems, etc.
Now, it is true that "Astoria" does provide extensibility points, and one can write code around that data retrieval logic provided to perform some actions before, or after the data was retrieved, but is that a good way to implement business logic? this is a very data centric, data entity aligned, way of thinking, which does not sit well with all that has been said and done with SOA to my understanding.
I like the REST approach for urls and am hoping to see more of it used, but I don't like the idea that logic is treated as essentially pre or post-processing stage on top of a data retrieval logic, nor do I think that business processes should think in data entities terms.
It would be extremely cool to expose REST endpoints to processes in BizTalk or WF, but I feel that is the only way to align REST and SOA and in my mind "Astoria" is a deviation from what I think of a good implementation of SOA.