This post originated from an RSS feed registered with .NET Buzz
by Udi Dahan.
Original Post: But that trick NEVER works
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.
Before getting into the responses of the blogosphere to my last post, I wanted to reiterate what it was about. The purpose of my post was "assuming that you know how to build a LA, how do you go about migrating to an SOA". Meaning, how do you migrate your existing ( and probably well-founded ) knowledge of LAs to knowledge of SOAs.
Now, I'd like to acknowledge the following posts that referred to my previous post on "How To Do SOA":
My good friend Roy Osherove, as always raining compliments down on me, writes "Using SOA on existing N-tier applications", but I'm afraid that there was a misunderstanding here. "when you need to introduce the SOA theme on an existing N-tier application" is not at all what I was attempting to show. Should you have a working application, do NOT change its architecture unless absolutely necessary. No, "SOA is cool" doesn't count.
I think I should stop a second to make a distinction. The definition of SOA has not yet solidified. The way I see it, there are 2 distinct and complementary views. 1. SOA is about how to integrate different systems. 2. SOA is about how to architect a single system. ( Steve pushes the first view with his post: "Making the N-Tier to SOA conversion" )
What I was referring to in my previous post was in the light of the second definition. What Roy refers to is more in line with the first. I won't be getting much into how to do the first kind of SOA, because there are big vendors out there that plan to make loads of money based on that definition. I'm more interested in helping Joe Developer use a new(old) paradigm to develop systems which, IMHO, is the most suitable today.
Let me reiterate. SOA is how to architect a system ( according to view 2 above ). You would be best served choosing this architecture before starting to code, than after. Even the Agile camps have a System Metaphor which must(?) be decided at project start which guides them throughout the project lifecycle - of course, it evolves over time.
Both Roy and Steve make valid points about putting a facade over existing parts of a system to expose them a services. In this way, they continue to support existing client code that is already dependent on it. I totally agree !
But, if your starting a new system, wouldn't it be preferable to have all client code access the given functionality in the same way ? Maybe/Yes.
Wouldn't it be that much easier to scale out the system if/when necessary ? Yes.
Wouldn't it make the client code loosely coupled to the functionality ? Yes.
Wouldn't it make the functionality itself more testable ? Yes.
Wouldn't it be that much easier to handle logging, exception management, security, and other cross-cutting concerns ? Definitely.
>pause /<
I've reached a conclusion. My next post won't be so much of an example of an implementation of a service. My next post will be about replacing the BL as we know it. I think that once you'll see what the BusinessService looks like in a system with an SOA, things will become that much clearer.
Of course, should you have something you're dying to see next, let me know =)
Previous Topic
