BT

Is SOA Dead as a Term but Alive as a Concept?

by Michael Stal on Apr 28, 2012 |

In a recent and provocative article called "SOA (the term) is dead, but SOA (the architecture) lives on" for SD Times David Rubinstein addressesthe opinion that while SOA has gained a lot of momentum as an architectural principle, it might be dead as a term. He quotes analyst Jason Bloomberg, who considers SOA as a bad term. In his opinion, SOA as a technology has already died due to Cloud Computing and due to the intrinsic complexity of Web services.

To prove his standpoint, Rubinstein quotes experts like Ian Goldsmith, vice president of product management at SOA Software, and Paul Fremantle, CTO and cofounder of WSO2, among a couple of others. Most experts, according to the article, believe that SOA has shifted from a technology stack that comprises standards like SOAP to an architectural principle. In addition, a majority of the experiences delivered to customers is out of the control of SOA vendors, which was different a few years ago and which is why Cloud Computing and other technologies have gained very high importance.

Goldberg from SOA Software said:

There was this pie in the sky about dynamic business processes, the ability to find a service to use and connecting to it automatically. That doesn’t happen. BPM and process automation are great, but it’s automation of relatively static processes. There is no dynamic discovery of new partners to integrate withy static processes. There is no dynamic discovery of new partners to integrate with.

The  experts quoted in the article warned that the term SOA now implies several liabilities, for example:

  • It has been over-promised,
  • Some of the WS-* standards have fallen to the wayside.

On the other hand, SOA technologies such as REST, are considered fundamental. But the trend, has shifted away from services to APIs. Ken Godskind, vice-president of monitoring products at SmartBear is quoted as follows:

SOA is a category; APIs are a general category that fall under that. When I look at Web services, I see just XML RPCs over HTTP. Serving users in richer fashion will be the add-in. For applications to deliver rich functionality, it’ll be primarily with rich navigation and control containers making requests to Web services to pull in data via REST, SOAP and JSON.

What do others believe?  It should be noted that the death of SOA as an implementation technology is not a particularly new topic. For instance, JP Morgenthal already discussed this issue in his own blog posting  "SOA is Dead, Long Live Distributed Computing"  in 2008.

What is your take on this discussion?

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Re: by Carlos Rodriguez

There are a bunch of companies still using WS technologies. I remember when tech news mentioned SOA a lot. At that time, SOA was presented as a principle and WS as the recommended technology, I don't see that "shift" because SOA was never a technology, IMHO. I do not think WS is that complicate but I do think it has performance issues. I think SOA and WS has taken its place in the computing, that is all.

Re: by Richard Clayton

I agree, the principles behind SOA aren't dead (especially since those principles are deeply rooted in quality software design). If anything, "the cloud" makes SOA more important, not less. I'm also glad to see the SOAP/WS* stack start to decline. I think there has been too much emphasis on the use of SOAP for everything; REST and messaging have proven to be better in certain situations.

Depends on how you define it by Udayan Banerjee

Is SOA = “SOA is a conceptual business architecture where business functionality, or application logic, is made available to SOA users, or consumers, as shared, reusable services on an IT network. “Services” in an SOA are modules of business or application functionality with exposed interfaces, and are invoked by messages. ”

OR

Is SOA = “SOA is an architectural style whose goal is to achieve loose coupling among interacting software agents. A service is a unit of work done by a service provider to achieve desired end results for a service consumer.”

First version is dead, second version has gone mainstream!

setandbma.wordpress.com/2010/12/30/soa-trends-m...

Depends on how you define it by Udayan Banerjee

Is SOA = “SOA is a conceptual business architecture where business functionality, or application logic, is made available to SOA users, or consumers, as shared, reusable services on an IT network. “Services” in an SOA are modules of business or application functionality with exposed interfaces, and are invoked by messages. ”

OR

Is SOA = “SOA is an architectural style whose goal is to achieve loose coupling among interacting software agents. A service is a unit of work done by a service provider to achieve desired end results for a service consumer.”

First version is dead, second version has gone mainstream!

setandbma.wordpress.com/2010/12/30/soa-trends-m...

Re: by Tammo van Lessen

Well, SOAP is messaging...

Re: by Richard Clayton

Fair enough; I was attempting to differentiate between SOAP WebServices and "more traditional" messaging technologies like JMS, AMQP, and the vendor specific products (TIBCO, MSMQ, etc.).

SOA isn't a technology stack by Staša Međedović

IMHO, SOA isn't a technology stack, nor it suggests use of any specific technology. SOA is an abstract technology-independent concept, with principles that guide you to more economic software development. I don't understand how things like: reusability, contract, loose coupling, abstraction, composition, statelessness, discoverability; which constitute SOA, can be dead?! So called "SOA technology stacks" are big vendor's marketing deceptions.

When IT hits a wall of absurd by Michael Poulin

I understand that David Rubinstein wanted to provoke a discussion about SOA in Technology and SOA in Architecture but a term cannot e dead if we use it. SOA was coined as Architecture but concurred by Technology; it is not a surprise that Technology had broken its neck in this adventure. Technical “SOA” was announced dead by Anne Thomas Manes in 2009, without assistance from Paul Fremantle and Jason Bloomberg. I do not know when Jason started to consider SOA a bad term but that time his course on SOA had very little in common with Technology.

Actually, I have to add that SOA as architectural realisation of Principle of Service Orientation has shifted, indeed, but not into Architecture (where it was all the time but IT did not want to admit it); it has shifted into Business according to the OASIS SOA Reference Architecture Foundation specification. The absurd is in that people still say “SOA” meaning technology (e.g., Web Services) and use such expression as “SOA vendors” while all agree that architecture, concept or paradigm is not a “thing” which can be bought from a vendor.

Service Orientation is, first of all, a way of thinking, a mentality if you want. I do not know how many years have to pass when people would adopt a simple idea that architecture is independent from the forms of its implementation. The only way an implementation can affect the architecture is via service execution context – a set of policies that regulate particular implementation. In this light, saying that a technology that cannot reflect arbitrary sets of policies is a SOA Technology would be incorrect. In particular, execution context address policies of communication with a service and the policies under which the service executes or is compliant with. In this case, how “SOA technologies such as REST, are considered fundamental”? How REST can reflect any policies beside the Web realm? How a means of communication with a resource may become a service on its own without the service body that, actually, does the job – provides consumers with the results of capability execution?

My take on this subject is very simple: a) forget about technology as a driver; b) engage with service-oriented ecosystem; c) consider that this ecosystem has architecture among others and this architecture is called service-oriented architecture, d) recognise that the driver of the service-oriented ecosystem is business that may or may not need technology for its execution and wellbeing.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

8 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2013 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT