Net-Centricity, SOA, and Web 2.0

Redefining Mob Mentality

My Photo

About

Search


  • Search This Blog

Recent Posts

  • Net-centricity, Web 2.0, and SOA relationship
  • Top Heavy SOA
  • Grady Booch is Mistaken
  • SOA and Modularity
  • The Truth About SOA
  • Enable Net-Centric Interoperability Prototyping and Design Testing
  • Brokering Shared Services
  • Facilitating Community Service Interface Specifications
  • Promoting The Use of Open Industry Standards
  • Using CoIs to Promote Net-Centricity and SOA

Categories

  • Bandwidth
  • Communities of Interest
  • Design Approach
  • EAI
  • Modularity
  • Net-Centricity
  • Web 2.0
Subscribe to this blog's feed

SOA and Modularity

I was having an interesting discussion with Nick, a good friend of mine and fellow SOA professional (Nick's Blog) and he provided me the best analogy I've come across concerning SOA and modularity. Object oriented programming aficionados and old timer component proponents will often ho hum SOA modularity stating that modularity has been around since Moses wrote the Ten Commandments on two tablets. Of course the basic modularity concepts behind an object, component, or service remain intact but the devil is in the details so here is the analogy.

Jigsaw_piece

A traditional module is analogous to a jig saw puzzle piece. Modules can be assembled to deliver a product but the way they fit together is predetermined and static. This can be very useful. For example, if you want to deconstruct a product into modules, to facilitate transport (as in the Moses example), and then reassemble it at its destination ensuring it is put together exactly as it was before transport. However, jigsaw puzzle pieces are a great example of "tightly coupled" interfaces and they do not facilitate reuse.

Tangram_puzzle 

A tangram puzzle (Tangram Definition-Wikipedia) is analogous to a SOA service (i.e.,module). Tangram pieces are "loosely coupled" and provide the flexibility to create a wide variety of products using the same pieces. This is very illustrative of composing SOA services to serve multiple business processes. Abstraction utilizing industry standards (i.e., ReST and Web Services) delivers the ability to create interface specifications that will allow for business process flexibility. Additionally, these interfaces are discoverable. This means that anyone wanting to use the "piece" can find it and understand how to use it. Abstraction and discover-ability are fundamentally what SOA adds to the age old concept of modularity. These are also the primary reason for the current buzz and investment around SOA. 

Think of jigsaw as tightly-coupled and inflexible. The puzzle is built to deliver one picture just as many traditional applications (even modular ones) were built to satisfy one business process. The tangram puzzle or service "modules" are constructed with loosely-coupled interfaces to allow for business process flexibility and use in multiple business processes. 

Thanks Nick. This analogy has long legs.

August 07, 2006 in Modularity | Permalink | Comments (1)