Steve Eichert suggests that SOA
is just hyped up interface based programming:
“In OO systems we often declare interfaces that define the behavior of our objects.
These interfaces allow us to plug in new implementations quickly and easily. By coupling
our objects to interface contracts rather then concrete objects, we reduce
the coupling between our objects. Is this different then SOA? Do Xml web
services make SOA better or more interesting then normal old interface based
programming in an OO world?“
While it may be safe to say that SOA is interfaced based (or contract based) programming,
saying that it is nothing more is a huge generalization, especially if you are talking
about SOA driven by web services. A few differences:
- Interface programming doesn’t play nearly as well AOP as SOA (especially
web service based SOA).
- Use of interfaces generally doesn’t give you cross-platform support.
- Use of interfaces says nothing about remote procedures.
- SOA is message based (HUGE difference). Web Services are not RMI, you
aren’t dealing with objects, you are dealing with messages (hell, SOAP’s acronym status
has been officially revoked, probably to do away with that very idea).
- The “plug-and-play“ aspects of web services are a non-factor
in most of today’s SOA implementations. People today are worried far more about providing
accessable behavior than swappable behavior. There are definately some very cool applications
that for swappable services, but this type of thing is out on the fringe (stuff like
WS-Transaction implementations fall into this category).
I’m sure there are plenty more reasons why SOA isn’t just interfaced based programming,
but the bottom line is that SOA provides for a ton of scenarios that interfaced based
programming doesn’t even begin to address. If interface programming alone was good
enough, we wouldn’t need SOA.
 Steve Eichert. http://dotnetjunkies.com/WebLog/seichert/posts/5268.aspx#comment