Lijit Search
I only post when I have something worthwhile to say, so it might be easiest to subscribe so that you automatically receive any new content.

Email RSS Twitter ESP

This is my personal blog and anything I write here in no way reflects the opinion of Cisco Systems, my employer. If it does, it is only by pure coincidence :) Nothing here constitutes investment advice either, so you can't sue me.

More about me here

View Jason Kolb's profile on LinkedIn

Popular Tags Recent Archives


    • Creative Commons License

    Fun Stuff

    • The content on this site is provided without any warranty, express or implied. All opinions expressed on this site are those of the author and may contain errors or omissions. NO MATERIAL HERE CONSTITUTES INVESTMENT ADVICE. The author may have a position in any company or security mentioned herein. Actions you undertake as a consequence of any analysis, opinion or advertisement on this site are solely your responsibility.
    Google Proxy Authentication OpenLaszlo/DOJO Partnership

    SOA vs Web 2.0? This is just nuts

    UPDATE:  I've been thinking and posting more about this topic here (further defining SOA and Web 2.0 and how they inter-relate) and here (what I believe is the solution--which doesn't exist, yet--for fixing this "misunderstanding).

    There's been a lot of discussion lately about "SOA vs. Web 2.0".  See these posts by John Hagel and Jeff Nolan.  This is just wrong, wrong, wrong.

    In my eyes they are the EXACT SAME THING.  This debate about REST vs. SOA, is completely off base.  You're debating about what method the user interface should use to access services.  A service is a service, it doesn't matter if it's called using SOAP or REST or a freakin' TCP/IP socket.

    The real point is, the software needs to be written as a service.  If it's built properly (and this is very important, as certain Web 2.0 companies <cough>37signals</cough> have basically derided proper, loosely coupled, software architecture as limiting) you can throw another interface facade on top of the logic code an expose your service whichever way you want.  Hell, if I decide I want to expose my service via smoke signals tomorrow, all I have to do is write a smoke signal interface for the business logic layer of my application.  Not that there's anybody to consume it, but hey, when the smoke signal guys get all up in arms about it I can be the first vendor to embrace their standard :)

    There are already mechanisms out there for rich Web clients to consume SOAP services, REST just happens to be the most popular mechanism to access services by a browser right now for whatever reason.  I personally like SOAP 100x better than REST, I think it's more enterprise-ready, and there are many, many specs out there for extending it and making it secure.  But really, WHO CARES what an app uses to access a service?

    To clarify:  when a Web 2.0 app makes an HTTP request in the background to get data, it's calling a service of some type.  When you click submit and it updates data in the background, it's calling a service of some type.  Now, there are exceptions, such as when a Web app makes a direct call to a business logic layer, but the entire point of Web 2.0 and AJAX is that you're trying to avoid round-trips to the server, which is where most of that happens. 

    The real problem is people who don't understand both camps trying to have a debate about why they're right and the other guy is wrong.  How can you debate something you don't understand?  You're both saying the same thing, just in a different language.

    Google Proxy Authentication OpenLaszlo/DOJO Partnership

    TrackBack URL for this entry:

    Trackbacks to SOA vs Web 2.0? This is just nuts:

  • Web 2.0 and SOA: Contrived or Converging? from
    It's been quite a week of discussion on Web 2.0 and its applicability to the enterprise. John Hagel did quite a write-up at the beginning of the week that was subsequently picked up by quite a number of folks (NIck Carr, Joe McKendrick, D [Read More]

  • Comments

    blog comments powered by Disqus