This SOA hype is getting out of hand

Via Scott Stewart I came across this article on Infoworld. Let me rehash the quote Scott posted as well:

The database community is also heading toward SOA. Plans are afoot to enable IBM DB2, Microsoft SQL Server 2005, Oracle 10g, Sybase (Profile, Products, Articles) ASE, and other platforms to participate actively in Web services-based SOA activities as first-class citizens -- even without the use of application servers. This will have profound implications for the design and management of widely distributed n-tiered applications because, in effect, hierarchical tiers will become horizontal peers.

Let me be blunt here: this whole SOA hype is pure marketing-poop. I mean: every developer on the planet knows that if you have several different elements in your application (gui, business logic, perhaps even a data-layer), element E provides services for element F and F is consumer of the services of element E. That's as old as what, client-server? Similar for library L which provides a set of functionality for application A which loads L at runtime. Offering a 'service' is nothing more than offering functionality (in any form you may think of) to others.

On a sunny day, some marketing department thought it would be great if the company's products would get a new 'unique' feature. What would be better than to re-hash the current features by giving them a new name? After days of brainstorming, consulting expensive advisors and visiting hand-reading guru's, they came up with... Service Oriented Architecture, better known as SOATM©®. SOATM©® would be the unique new feature of their products, which would give them an edge on the competition! Now, in the country were I live, The Netherlands, this acronym was already taken: "Seksueel Overdraagbare Aandoeningen", which roughly translates to: "Deceases transferable through sexual intercourse". Of course an unlucky coincidence.

Is this SOATM©®-thing (the English marketing version) really new? No, of course not. I mean, pulling data out of an RDBMS and into an external client program, how was that done a couple of years ago? That's right, calling into the service which was offered by the RDBMS through its API! However what do we see happening today? People who earn their living by selling hot air under the most weird acronyms, are yelling as hard as their lungs allow them to that something new is invented! SOATM©®! Don't be a slacker! Enable your applications for SOATM©® today! SOATM©® is the only real future! If you don't jump on the bandwagon today, you'll be sorry forever!

...(breath in.... breath out... 1 2 3 4 ... )

When I read an article like The Fallacy of the Data Layer by Rocky Lhotka, my eyes hurt, tears pop up and I can't stop shaking my head and whenever I read articles like that, one thought keeps coming back: are these SOATM©®-guys just doing this to get themselves more air-time at the next INETA sponsored speaker convention/PDC/TechEd/[your favorite fancy fair] ? I mean: it can't be just because they saw the light and can't stop themselves telling everybody how it really has to be done, how software really has to be developed, because all they do is re-hashing decade-old wisdom with newly invented acronyms!

Of course, the Infoworld article is written by a journalist, perfectly echoing the chimes coming from the marketing departments of their favorite sponsors. I can't blame him, he's not writing for developers who are standing knee-deep in the cold mud of the programmer-trenches, he's writing for managers, oh sorry, Enterprise VisionariesTM©®. However more and more, the developer world is talking about things which are just pure marketing inventions and which never should have left the manager's office, and SOATM©® is one of these things.

Years ago, the developer community embraced one of the predecessors of SOATM©®: N-tier developmentTM©®. Even today, large groups of developers are pulling their hair out of their bright heads and wonder "What exactly is n-tier development?" (if you don't believe me, check the www.asp.net forums). And rightfully so, because it's a vague term and almost everybody has a different opinion about it.

Years later, Web-servicesTM©® were introduced.

"Ah, a service which is a web."
"No."
"No?"
"No, a service using the web. (I think)"
"Oh, so a service not using the web, but normal TCP/IP isn't a web-service?"
"Hmm, good question. Ah I have it: a service written by the web-services logic build into VS.NET!"
"Ah, I can work with that. But... what about a remoted service, using SOAP and remoting, not web-services build into VS.NET" ?
"..."

Sounds familiar? Good. Now, to prevent this from happening again with SOATM©®, let's make a deal. Let us, developers across the globe, make a stand here: Enough with the marketing goo polluting our profession!.

Thanks for listening.

13 Comments

  • I myself have not been paying attention to the SOA hype, so I can't comment on it.



    But there is a very real difference between "web-services" and "services using TCP/IP", and I'm sure you realize this, but in a fit of rage, forgot ;) The former is actually a subset (or should we say another implementation?) of the latter.



    As for SOA being marketing hype, well, you could've said the same thing about .Net before it was released:



    "Let me be blunt here: this whole .Net hype is pure marketing-poop. I mean: every developer on the planet knows that if you have several different classes in your application (ui objects, business objects, perhaps even a data transfer object), class E inherits class F and F is the parent of class E. That's as old as what, object oriented programming?"



    Okay, I dunno how well that works, but I think you get my point. Rarely are there really any true breakthroughs in a field. You could argue that Honda is going overboard, hyping up their SH-AWD on their new Acura RL, but if you study the underlying technology, you realize that there are minute differences between their SH-AWD system and current AWD systems on the market that offers tangible benefits.



    Just my thoughts....

  • see the link for explanation

  • "But there is a very real difference between "web-services" and "services using TCP/IP", and I'm sure you realize this, but in a fit of rage, forgot ;) The former is actually a subset (or should we say another implementation?) of the latter."

    Yes I know, but it's still vague, because a lot of people run into problems: they want to / need to use remoting but use webservices techniques build into vs.net and wonder why it's not the same.



    As for .net being a hype too: fully agreed, IF you listened to the marketing machine which sticked .NET to every byte coming out of redmond (and later retracted that, thankfully).



    However I see soa as a complete re-hash of an old idea and being presented as something completely new. That's an old marketing trick and we don't need that, IMHO.

  • Amen, brother! I can't take a step around here without three managers asking, "does it fit our new SOA direction?"

  • I would say that "hype getting out of hand" is an oxymoron.



    :D



    The ".Net" brand was very bad publicity for the .Net framework. Many things were branded .Net Ent Servers without even offering PIAs

  • Thanks for yet another great piece of blogging. I couldn't agree more - here's another allergy to develop: I immediately want to leave the room if someone uses the S..-word.



    By the way: I remember Rasmus Lerdorf calling "web services" a "firewall penetration protocol": Paranoid network administrators have blocked all IP ports but port 80/tcp. With practically one IP port left to communicate on, new protocols have to be written to differentiate what's happening :-)

    Innovation? - No: Circumvention...

  • Thanks all for the kind words :)

    George: good points! Thanks for sharing these :)



    Troels: also a great point about that port 80. :)



  • Wolfgang: I did mention that dutch SOA acronym :). The text indeed looks odd in IE (I use firefox so I didn't notice) Must be the superscript tags...



    As for RDBMS's being stand alone entities: would you hook up your 1TB mission critical database server to the internet? Me neither.

  • Here's why SOA is a big deal.

    1) Interoperability: Why does an application that needs a data persistence service need to hardwire with a vendor/language-specific API unless of course performance requirements demand it?

    2) Ability to take advantage of common infrastructure: Read about SOAP 1.2 message paths and you will realize that application level inter-networking is now a reality. The network can provide value-added services transparently to all inter-application messaging. This wouldn't have been possible hadn't there been standardization around messaging protocols.



    Dig deeper.



    cheers

    prasad

  • Frans,



    Bottomline: All of us agree that these hundreds and thousands of acronyms/concepts we have for computing techniques and technologies all boil down and refer to "data - logic(process) - channel". All of this jargon is either new names for these fundamental pieces or ways to link them or to store/run/implement them.. You get the picture! And the basic premises wont change much even when, say, quantum computing becomes a reality. :-)



    Having said that, I definitely cant stop myself from at least snickering (if not being enraged like you are) at all these peddlars selling old wine in new bottle and sometimes even the bottle is not new.. just the label! :-)



    And having seen firsthand how some of these things start, I know that in most cases "good" technicians who just think aloud in some meeting are the innocent instigators for these marketing hypes/avalanches by peddlars! :-)



    Hope you will have more luck fighting these wars that some of us did/do! :-)



    Keep up the good work.

  • Frans- you're a total bad a33. Amen brother. If i ever disagree with you - I need to have an email generated to warn my of my stupidity- You rock.

  • Sure, we wouldn't hook up 1TB mission critical databases to the Internet, but how many databases are offering very simple stuff? Forums, product information, entire sites, the list goes on. Why o why would we want to have extra layers in between? Look at ASP.NET v2.0. Yes, it has an ObjectDataSource. But it works so well that if you use anything other than a specialization of a DataTable/DataSet, you're screwed. If you have a Business Framework that actually has some intelligence in it, start writing you're own databinding providers.



    Let me emphasize again that I fully agree that critical databases shouldn't be hooked up to the Internet directly, but all that stuff that's doing little more than serving up data? Please, don't bother me with more layers and/or tiers than I want to administer. Just give me an HTTP daemon in the DB. Thank you.

  • Frans,



    With all due respect, I think you're missing an important point here.



    When you state that SOA is just repackaging, you use the example:



    "How was that done a couple years ago? That's right, calling into the service

    which was offered by the RDBMS through its API!"



    What you failed to mention is a series of *VERY* important points:



    - That API is heavily proprietary. Think OCI, think TDI, binary protocol stuff

    - That API probably forces you to use a specific language/framework to access it (usually C)

    - If you want to call that API, it returns proprietary data formats, unique

    types of outputs, etc. There is no standard for the type of information you should

    expect to receive from that API. If you wanted to write a common database layer

    for your application, you have to have two distinct code sets for each type of

    RDMBS you expect to support.



    SOA and Web Services can make better or remove entirely all of those restrictions. And therein lies the beauty.



    If you can show me how OCI can be easily called, in a uniform manner, from almost any language and framework without downloading any additional add-ons from Oracle or the framework provider, then I might be persuaded.



    But if Oracle and MSSQL start supporting direct SOAP access and return some standard XML dataset-schema data, then I can't see how you can say that it's just marketing fluff and serves no purpose and you'd rather use OCI or TDI.

Comments have been disabled for this content.