InfoQ

InfoQ

News

My Bookmarks

Login or Register to enable bookmarks for unlimited time.

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

Retire Microsoft's Four SOA tenets?

Posted by Arnon Rotem-Gal-Oz on Aug 20, 2007

Sections
Architecture & Design,
Development,
Enterprise Architecture
Topics
SOA ,
Design ,
.NET ,
Web Services
Tags
Microsoft ,
Criticism
Microsoft's Harry Pierson (a.k.a. DevHawk) suggest that Microsoft's own 4 tenets for SOA should be retired because, well, they are, in Harry's opinion, useless - at least they are not useful anymore
I would say that the tenets' job is done and it's time to retire them. Once you accept the service-oriented paradigm, what further guidance do the tenets provide? Not much, if any
The SOA tenets originally appeared back in 2004 when  Don Box published an article on MSDN called "A Guide to developing and Running Connected Systems with Indigo" (Indigo is what's known today as Windows Communication Foundation or WCF for short). Don Box wrote that WCF is based on SOA principles and that unlike other approaches, specifically object orientation, SOA requires a different set of assumptions:
In Indigo, a service is simply a program that one interacts with via message exchanges. A set of deployed services is a system. Individual services are built to last—the availability and stability of a given service is critical. The aggregate system of services is built to allow for change—the system must adapt to the presence of new services that appear a long time after the original services and clients have been deployed, and these must not break functionality.
Service-oriented development is based on the four fundamental tenets that follow:
Don continues to define and explain he following 4 tenets:
  • Boundaries are explicit
  • Services are autonomous
  • Services share schema and contract, not class
  • Service compatibility is determined based on policy
As mentioned earlier, Harry thinks these tenets are not very useful. Harry concluded this based on discussion he had with John Heintz who wrote that the SOA tenets don't really constraint the solution space:
Tenet 1: Boundaries are Explicit(Sure, but isn't everything? Ok, so SQL based integration strategies don't fall into this category. How do I build a good boundary? What will version better? What has a lower barrier to mashup/integration?)

Tenet 2: Services are Autonomous(Right. This is a great goal, but provides no guidance or boundaries to achieve it.)

Tenet 3: Services share schema and contract, not class(So do all of my OO programs with interface and classes. What is different from OO design that makes SOA something else?)

Tenet 4: Service compatibility is based upon policy(This is a good start: the types and scope of policy can shape an architecture. The policies are the constraints in a system. There not really defined though, just a statement that they should be there.)
Hartmut Wilms doesn't really agree with these claims and says that it might be true in perfect SOA world but not in real life. Especially considering that WCF turned out to be a general purpose communications  framework with a scope wider than SOA:
John and Harry, do you really think that every developer has adopted to the message-oriented paradigm and that “service orientation is mainstream”? I’m afraid not. As long as the CLR/JVM/…-First approach is proclaimed by the vendors and the masses listen and follow, the four tenets are far from retirement!
Don Box, who wrote the original article also commented on the subject. Don said that the tenets were originally published to explain the principles WCF (or at least the original Indigo vision) was built.
The goal wasn’t to provide any more guidance than “this is what we expect you to do with it” at a pretty abstract level.
Regardless, of the original intention, the 4 SOA tenets dominated Microsoft's SOA message for the past 4 years. Do you think there's any merit in these tenets? or is Harry right and its about time we do away with them?  Lastly, does anyone outside of the Microsoft development world care either way?
  • This article is part of a featured topic series on SOA

No comments

Watch Thread Reply

Educational Content

New-age Transactional Systems - Not Your Grandpa's OLTP

John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.

Cool Code

Kevlin Henney examines code samples to see what can be learned from them starting from the premise that one won’t write great code unless he knows how to read it.

Collaboration: At the Extremities of Extreme

Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.

Yesod Web Framework

Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).

Transactions without Transactions

Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.

Attila Szegedi on JVM and GC Performance Tuning at Twitter

Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.

10 tips on how to prevent business value risk

One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.

Interview: Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives

InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.