Yossi Dahan [BizTalk]

Google
 

Wednesday, October 31, 2007

Anybody still thinks SOA is just a buzz-word?

If there was any doubt in anyone's mind that SOA is here to stay, that services are the way forward for many applications, and that Microsoft is investing a lot in enabling us to deliver even better solutions based on SOA, SaaS, S+S etc, yesterday's announcement about Oslo (also check out this issue of research directions) shows that the level of commitment in this field by Microsoft is only increasing, and that we're about to see a lot more in this area over the next couple of years.

Everyone says it, and it's true - these are very exciting times to be in software development, especially in the enterprise and BPM/EAI in particular perhaps, and I can't help the feeling we've really only scratched the surface on this one, a lot more is still to come.

I'm sure we're all going to hear, read and write a lot in the next few weeks; I know I've got tons of new stuff to read on my desk now, and hopefully will get to see some nice stuff coming out of this in a few months time.

BTW, don't forget to check out the newly launched SOA web site as mentioned by Marjan Kalantar

Labels: , ,

Tuesday, October 30, 2007

Can project code name "Astoria" align with SOA?

I've recently had the pleasure of seeing Guy Smith-Ferrier presenting Microsoft project codename "Astoria".

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.

Labels: , , ,

Wednesday, October 03, 2007

Great news in my mailbox this week

Earlier this week I've received an email congratulating me for receiving the MVP award for "Windows Server System - BizTalk Server".

I'm honoured and humbled and quite excited I have to admit.

I think I'm up to a great year!

And of course - a huge thank you for everyone involved...