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?“[1]

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.

[1] Steve Eichert. http://dotnetjunkies.com/WebLog/seichert/posts/5268.aspx#comment

[Weblogs @ ASP.NET]