Tension emerges between SOA and mashup camps

Tension emerges between SOA and mashup camps

Summary: SOA and mashups serve the same purpose, don't they?


The promise of mashups -- that lightweight front-end apps that can be assembled by business users -- adds a new, more palatable dimension to SOA.

Mashups make SOA real to business users - nothing wrong with that

The mashup market appears to be gaining traction. Dion Hinchcliffe reports fast-breaking progress in mashup adoption across the industry. He noted that there were at least nine different announcements around Web-based mashups coming out of the recent Web 2.0 conference.

However, some SOA purists have said that mashups are still too ungovernable for enterprise SOA environments. And, now, there seems to be an opposing point of view from the Web 2.0 camp as well -- that SOA poisons the mashup well.

As Dave Linthicum points out in a new post, some Web 2.0 proponents don't think SOA should be brought into the mashup world -- it will ruin all the fun. He even has heard from people "who did not want the term 'mashups' sullied with the term 'SOA.'" As Dave observed, "the core message is that they view SOA as something that's "enterprisy," and mashups as much more innovative and not really enterprise related." Hmm.

When Dave and I participated on a panel in January's Open Group confab, Dave said he considered mashups to be a perfectly legitimate part of service oriented architecture. In reference to resistance from mashup proponents to SOA, Dave said both need to come together:

"Not sure I agree with that. While indeed mashups are an innovative way of building very cool applications from many available resources, visual and non-visual, they are still composite applications. While I'm seeing mashups that are completely Web-hosted, I'm seeing more and more that are a mix of Web and enterprise resources, as well as mashups that are true "'enterprise mashups.'"

No question about it, mashups have been gaining ground in the enterprise world. But along with that, some tension has arisen between proponents in the two camps, as Dave had also observed. As Tony Baer puts it, a "kind of a love/hate relationship between SOA and mashups." SOA is seen as complex, while mashups seen as an easy shortcut to agility. "Heck, you can lay chunks of web objects atop each other without having to do all that architecture 'stuff.'"

Tony adds that contrary to what some believe, mashups do not present an alternative or competition to SOA composite apps. As he puts it, "the approach is not a black and white SOA vs. mashups choice for enterprise integration, but rather, use of mashups for the last mile of integration that may, in many cases, utilize data services, feeds, or other sources that more often than not are exposed as Web or RESTful Services."

And, may I add, the ease and lightweightness of mashups make it easier to sell the concept of SOA to the business. Because now they can see and feel and touch service orientation. It's no longer an abstract architectural concept; they can actually create services on their own. (Here's a case where good governance comes in -- can't you just see business users, having had a taste of their own service creation, going wild?)

Topics: Browser, Enterprise Software, Software, Software Development

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • UI components are not normally considered services

    "...they can actually create services on their own."

    UI components, including composite applications or mashups, are not typically "services." They may be service clients but typically services do *not* provide a user interface.
    • Mashups don't need UI....

      I agree that UI components aren't services, but mashups don't need a UI. The ability to mashup the data from different sources is the very definition of an Enterprise Mashup. UI may, or may not, be part of that.

      And this is where the tension first presents itself. If you've got to know all about the SOA, how it's accessed, WSDL, governance, etc. you're not going to get the agility Mashups can provide.
      • Isn't that called "integration"? Or "application development"?

        The consumption of services in a so-called "mashup" isn't necessarily a heavy-weight ordeal. At some point, one must be able ask for the desired data in some way. Call a service. Or write SQL if you're allowed directly at the data.

        One doesn't have to "know all about the SOA" (there's no such thing as "the SOA" IMO)--just the services one wants to use.
      • Another view...

        I can see the appeal of giving "end users" the ability to create their own services. And there may be cases where doing so is exactly the right thing to do.

        But how many times have we all chuckled to ourselves about how system X is still managed via Excel spreadsheets--with all the attendant issues. Agile yes. Robust, maintainable, identifiable, supportable, etc. Maybe but unlikely.

        Balancing agility with long-term issues would seem to be key. Agility isn't the only important "-ility" to consider.
    • Times are changing

      Historically they don't, but times are changing. With service consumers being further removed from the problem domain of the available services, it is becoming harder and more time consuming for them to built a UI on top of these services.

      At Corizon we have brought the SOA pattern to the UI and created the UIService. Read my latest post here for more details: http://blog.corizon.com/

      Edwin van der Sanden
  • The SOA/Mashup Tension is GOOD

    JackBe agrees that mashups and SOA have a lot to offer each other. But the only tension we've encountered has occurred when a mashup community puts pressure on the SOA builders to create mashup-ready services FASTER. That is a tension most SOA architects haven't encountered but a very positive one!

    Chris Warner
    • What exactly is...

      ...a "mashup-ready service?" A service provider should have no inkling of the nature of its clients. And strictly speaking, they'd be "service builders" not "SOA builders."
  • SOA All Hat, No Cattle

    Companies spend millions on SOA and aren't even clear what exactly they're buying. I've worked in shops moving resolutely toward a SOA architecture, sometimes for years, and never saw any appreciable progress toward their goal. I've seen lots of really whiz-bang demos, heard lots of tripe about "enterprise best practices" and "best of class" technologies but rarely does that translate into anything simple and practical that actually works. And, perhaps worst of all, I've never seen it translate into anything the staff really wanted or wanted to use.

    I have seen lots of small groups collaborating with GoogleDocs and mashing up their own home brew apps because they got tired of waiting for the golden SOA manna rain to come down.

    My opinion after years in IT working jobs from management to grunt programmer is that SOA is techno snake oil that's never yielded actual savings for anyone. Process improvement....maybe. But I'd still argue it could have been done cheaper without the SOA architecture overhead.

    Although I'm certain, by just sheer dumb luck, someone has been able to produce a profitable SOA implementation that actually worked, produced something practical and saved more money than it cost to produce. I believe it's out there the same way I believe the Ark of Covenant is out there. Somewhere.
    • It depends on the organization...

      It can be said that SOA is like democracy, in that its a constant journey, often messy and erratic and full of conflict, but never attaining a 100% pure state. The constant vendor chatter does not help, either. But SOA is a best practice for organizations that understand its long-term potential.
  • more religion......

    It's just SOFTWARE, well perhaps there is a lot of Vaporware still...

    Can Web 2.0 or SOA spell "security"?
    • Yes.

      No vaporware.

      There are plenty of web 2.0 components out there, and some even address security.

      SOA is a style of architecture, thus, "vaporware" does not apply. And security would be addressed as part of the architecture definition and/or the implementation design.
  • RE: Tension emerges between SOA and mashup camps

    My 2 cents. SOA and Mashups would complement each in an ideal scenario. Much like how the chefs prepare for a buffet. To call SOA and MashUps at loggerheads with each other is just a speculation that arises from vendor affiliation and enterprise strategy.

    A smart enterprise can easily decipher the difference between the two.
    • Agreed, in a smart enterprise

      My observations are the individuals putting together mashup applications aren't necessarily always the same as those on the SOA teams. In theory, anyone across the enterprise -- including non IT -- could put together a mashup applications. But SOA proponents are likely to be the first ones to pull together mashups.