mca blog

i read this piece on WCF a while back and needed time to think on it before posting.

first, while titled "The Origins of SOA", it reads more like a piece about the value of WCF and the things that lead up to it. more to the point, it reads like the history of distributed programming along the SOAP curve. and i'm not all that moved by it.

the section that talked about the 'core tenets' of SOA caught my attention:

• Explicit service boundaries
  • total encapsulation of everything except functionality
  • location independence
  • technological independence
• Autonomous services
  • independent operation
  • independent versioning
  • independently secured
  • fault isolated
• share contracts for functionality and data
  • technology independent metadata (WSDL, schemas etc)
  • platform neutral (inter language, inter machine)
  • version independent
  • no shared code
• compatibility is based on policy
  • only compatible services can interact
  • policies are published
  • access control and policy are independent of implementation
• also...
  • services are secure
  • they leave the system in a consistent state
  • they’re thread safe
  • they’re reliable
  • they’re robust

this all seems vaguely (and incompletely) familiar to the REST constraints from Fielding's dissertation. my summary of that material looks like this:

• client and server share *resources*
• each resource has a unique name (URI)
• each resource has one or more representations (media types)
• all resource operations are stateless
• the limited list of fully understood (by client and server) resource operations (GET,HEAD,POST,PUT,DELETE...)
• all client-server interactions can pass through multiple intermediaries (proxies, caches, etc.)
• all 'out-of-band' data for an operation appears as 'headers' to the message

this is ROA (resource oriented architecture) instead of SOA. much more sustainable, imho. i think the last ten years of the Web's growth shows that - as a loosely-coupled, distributed protocol - HTTP is very successful and likely to continue that way for some time. that's why, in the last year or so, i've focused on learning the REST constraints instead of digging deeper into SOAP-based activities.

HTTP has it's problems. support for transactions, reliable messages, and so forth continue to be challenging. but that's nothing new. and it's typical for loosely-coupled scenarios. while it's true that SOAP-based solutions do better in this area. it's always at the cost of reduced performance and more brittle communications. bottom-line: it's tough to do reliable messaging in a network designed for stateless/replay-able operations.

also, it's easy to forget that Fielding's dissertation was completed in 2000. SOAP had it's first drafts in 1999. these two approaches grew up as siblings. they both are attempts to solve the problems of stable, robust, and secure distributed programming over vast networks.

for me, i'm fully in the HTTP/REST camp right now. and i don't see any fundamental reasons to leave.