This post originated from an RSS feed registered with .NET Buzz
by Udi Dahan.
Original Post: So you want a distributed architecture, eh?
Feed Title: Udi Dahan - The Software Simplist
Feed URL: http://feeds.feedburner.com/UdiDahan-TheSoftwareSimplist
Feed Description: I am a software simplist. I make this beast of architecting, analysing, designing, developing, testing, managing, deploying software systems simple.
This blog is about how I do it.
John Cavnar-Johnson does a thorough job of demolishing much of the "advice" found on the recent MSDN article by Rich Turner. To tell you the truth, I agree with a lot of what John says. However, both in Rich's article and in John's rebuttal, I find the focus on technology to be over-the-top. The one main point that needs to get drilled home (that John does mention, but not with enough emphasis in my opinion) is that if you've decided on Service Orientation, then you've decided on messaging between your services. Unless a message is a Query Message (something like GetCustomers - level=platinum AND join date=last month AND last purchase date < last week), then these message interactions should be asynchronous.
For anyone whose ever done this sort of thing, the technology for transporting messages between services is probably not an architectural issue. I have yet to see a single detailed design document online that shows how to design a service that will support asynchronous message exchanges. Everybody's going on and on about which technology to use - System.Messaging, Indigo/WCF/WTF/Whatever, Remoting, ASMX, ... like that's really going to break the bank. Without a solid design, how could such technological decisions even be made?
Previous Topic
