WebAPI Tip #4: Does This Framework Do SOA?

Tuesday, March 26, 2013

SOA circa 2004This post is a commentary on the statement: "We are sticking with WCF because we want a service oriented architecture."

SOA is a three letter acronym that created a fervor from the server closet to the executive boardroom.  A decade of labor by standards committees, tool vendors, framework builders, consultants, and hucksters made sure SOA became the silver bullet for enterprise architecture.

If I look through the noise for the pragmatic essence of SOA, I see three noble goals:

- Software encapsulation – or the ability to hide complexity behind coarse grained interfaces.

- Software autonomy - or the absolute control of the execution environment and the resources required by software, as well as the freedom to make independent decisions about implementation details.

- Software interoperability – or optimizing for reuse by relying on standard application level communication protocols.

Those three goals are entirely possible with HTTP based services and the ASP.NET WebAPI. The S in SOA doesn't stand for SOAP.

I know many people will say the additional metadata commonly associated with SOA (like WS-Metadata Exchange, WS-Policy, and XML Schema, to name just a few) is also a core part of SOA. I'd argue the metadata was good for vendors who built software to manage the complexity of the metadata.

KISS it goodbye with the WebAPI.


Comments
gravatar Andre Calil Tuesday, March 26, 2013
In fact, SOA is one of the most misused acronym. Whenever a developer said the word "webservice", project manager would send an e-mail to the client including a paragraph about SOA. Implementing this design with WebAPI really makes sense. Client and server will negotiate data type and transmission, all you have to care about is providing the according methods.
gravatar Rob Tuesday, March 26, 2013
Hear, hear!
gravatar Grahame SD Tuesday, March 26, 2013
"A decade of labor by standards committees, tool vendors, framework builders, consultants, and hucksters made sure SOA became the silver bullet for enterprise architecture." and money in the bank for those who could make it sound complicated.
gravatar Petar Repac Tuesday, March 26, 2013
Maybe if we say that we can make a Service Oriented Architecture (SOA) solution with manually passing pieces of paper around then it will be clear that SOA can be used with WCF and WebAPI and with XYZ (NServiceBus anyone :))). BTW using WCF by far doesn't guarantee that you will end up with SOA solution.
gravatar slicklash Wednesday, March 27, 2013
SOA is technology independent.
gravatar Chowdhury Wednesday, March 27, 2013
Brilliant Scott. "The S in SOA doesn't stand for SOAP" -- I'll quote that in the future. :-)
gravatar Sam Gentiile Wednesday, March 27, 2013
Mostly agree and I came from the whole SOA/WCF/SOAP bigot position. I've grown to see that HTTP and REST are powerful and simpler ways. Web API is way simpler. The only place I see for the SOAP/SOA scenarios is multiplatform. Web API is not a Java teachnology. When you have an SOA where there is Microsoft, Java clients and others, the WS-* protocols and coresponding WCF bindings are useful. But it's true - "The S in SOA doesn't stand for SOAP."
gravatar Paul Speranza Wednesday, March 27, 2013
That is exactly why I have latched on to Web API. Simple.Clean. Fun. Bye, bye complexity, don't let the door hit you in the butt on the way out.
Comments are closed.

My Pluralsight Courses

K.Scott Allen OdeToCode by K. Scott Allen
What JavaScript Developers Should Know About ECMAScript 2015
The Podcast!