This post originated from an RSS feed registered with .NET Buzz
by Udi Dahan.
Original Post: How SOA helps you hit the agile sweet spot
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.
I just read this blog post on "How SOA helps you hit the agile sweet spot" by Steve Jones and wanted to add a couple of points. Martin Fowler also wrote about this in his Application Database pattern.
Steve says:
"1. When you are doing a project, work out what the services are upfront.
2. Clearly define the interactions between these services"
About point #1, I absolutely agree. Grady Booch, in his recent interview to GCN mentioned this as well:
"Services should not be driven bottom up from technology, as DHS folks are proposing, but rather from the top downâwith the use cases."
I'm afraid that this somewhat contradicts Ohad Israeli's guidance on his recent interview on Microsoft's ARCast "Migrating Legacy Systems to SOA".
And I think that point #2 raised above, while it relates to #1, falls short of the guidance that architects and developers need to carve out coarse-grained, autonomous, busines-level services. In order for the system to benefit from the loose-coupling an SOA is supposed to bring, the communication between its services must handle these 3 levels of coupling:
1. Platform coupling: use text (like XML) instead of binary for interoperability.
2. Temporal coupling: use asynchronous messaging patterns like one-way, pub/sub, and correlated request/response - no synchronous RPC.
3. Spatial coupling: use a bus so that when one service is moved from one server to another this will not stop communications to that service.
Corrollaries from these basic principles include that transactions (of the ACID type) do not span services. This in turn leads you to analyze the domain to find the "data consistency fracture points" so that different parts of the domain get handled by different services.
Anyway, I think that its high time we, as an industry, stopped talking about SOA from 30,000 ft and started harvesting and documenting the patterns in this space. I mean, how many times can you say "IT/Business alignment" and not start laughing.
Previous Topic
