SOA Talk - A SearchSOA.com blog

SOA Talk:

 

A SearchSOA.com blog


The SOA blog with observations and commentary for architects and developers about SOA, Web services, integration technologies (ESBs, Grids, XML) and development platforms such as Java EE and .NET

Does WOA bring anything new to SOA?

A lot of analysts I respect have been pushing the concept of Web-oriented architecture, or WOA, of late. For those unfamiliar with the term, Dion Hinchcliffe has covered it extensively and Dana Gardner has been singing its praises. To be honest, it looked like a term in search of a foundation to this observer. We’ve already got RIA and composite applications and mashups and Web 2.0 and SaaS and SOA, but I figured I should ask a few architects what they think of the concept to see if it’s got traction in those circles.

Granted, I only polled half a dozen people (though I’ll note here that they are half a dozen really smart people). The response I got from all of them is that WOA strikes them as redundant and nothing particularly new, an empty suit if you will. One wrote, “It reminds me a lot of the attempt by someone to gain some name recognition with the ‘SOA 2.0′ concept (which one vendor did try to use and then dropped after it was rejected by the SOA community).” Another responded, “It’s the same old thing, relabeled with an even MORE unwieldy name.”

Yet another noted, “This is just composite Web apps.”

Not a single one of them voiced a problem with the notion that Web-based development is an excellent place to concentrate your resources. In fact, some of the architects stated they are eagerly pursuing these sorts of development strategies.

That said, no one showed any love for the “WOA” acronym. “God forbid this take hold because it could complicate something the industry has been trying to simplify,” said one of the architects. He listed numerous reason why WOA, as a term, could do more harm than good:

  • Users should have exactly one enterprise architecture, many don’t and they don’t need the confusion of “which architecture should I use?”
  • WOA doesn’t really have an underlying architecture, it’s more a set of best practices around REST, RIA and composite apps.
  • If users perceive WOA to be outside the principles of SOA, it could prove an excellent vehicle for building Web-based stovepipes.
  • WOA toes and sometimes crosses the line of being technology driven. “We plan on using Google Apps, but Google Apps needs to fit into our structure, not the other way around.”

That last point about the potential technology driven nature of WOA was a point of contention for another architect. “One of the big problems we’ve had to fight is people who act as if SOA is tied to middleware or specific standards like SOAP or to a specific data format like XML. Nothing could be farther from the truth. Just because you’ve got some new technology to use doesn’t mean you go back to shoddy engineering. Everyone should know better than to let a specific hot technology drive the bus. It will cool off and you still need to be in business.”

Strikeiron CEO Dave Linthicum has also blogged about the upside of WOA. He pitched WOA as a potential gateway to SOA.

What is changing quickly is that enterprises are finding that the path of least resistance is in essence to build their SOAs on the Web, using Web resources, including content, internet delivered APIs, and Web services. Once there is success with WOA you’ll see the same patterns emerging behind the firewall, or SOA.

The polled architects viewed that as a perfectly legitimate approach, but one noted, “It’s still SOA. I just don’t see where WOA adds anything. Terms like this tend to make people in the field angry. In this case, it’s an attempt to sell them something they’ve already bought. I don’t know anyone who doesn’t want to use REST or build composite apps using Web tools.”

Time will tell whether WOA gains traction, but these architects expressed an unequivocal desire to have no more than one something-oriented architecture in their lives.

Podcast: Mulesource CEO on why SOA requires many ESBs

This podcast with Mulesource CEO Dave Rosenberg covers the role of the enterprise service bus (ESB) inside an SOA. Rosenberg notes that an ESB shouldn’t be thought of as a singular piece of software sitting in the middle of every application, tossing aside the hub-and-spoke model from the EAI world that often gets grafted onto SOA. He stresses that SOA “is not about integration,” but rather a sensible infrastructure that can handle modular development and changing business needs.

 Standard Podcast: Play Now | Play in Popup

Other topics covered in this interview include:

  • How users are more likely to have an “enterprise service network” with multiple ESBs rather than a single or master ESB
  • The role of open source in SOA development
  • Why neither the Java EE nor .NET meets are well-suited to service orientation
  • The roadmap for the Mulesource, particularly in the management area
  • What constitutes “SOA infrastructure”
  • Data issues, including getting data out of 3rd party SaaS applications

Caught in a sea of SaaS

Over on her ebizQ blog, Krissi Danielsson has noted that the buzzword success of Software as a Service (SaaS) has spawned numerous aaS imitators, including Data, Architecture and Voice all “as a Service.” In his ZDNet blog, Phil Wainewright added that aaS is redundant because the very function of business is to provide services.

It’s about time some sane, responsible folks pointed out that we’re heading into buzzword overkill with “as a service.” Yet we’d be remiss if we didn’t have some irresponsible fun with aaS before it becomes yesterday’s catchphrase.

For instance, here’s a list of software possibilities that still haven’t had their aaSes handed to them:

  • Hidden License Fees as a Service (HLFaaS)
  • Stovepipe Application Sprawl as a Service (SASaaS)
  • Integration Spaghetti as a Service (ISaaS)
  • Every Vendor Insures Lock-in as a Service (EVILaaS)
  • Must Upgrade to the Expensive Enterprise Version If You Want It to Scale as a Service (MUttEEVIYWItSaaS)
  • Rogue Services as a Service (RSaaS)

Also, as we all know fortune cookie proverbs are made infinitely better by adding ‘in bed” at the end. Let’s try that with “as a service.”

  • Count your blessings by thinking of those whom you love … as a service.
  • Plan for many pleasures ahead … as a service.
  • Something you lost will soon turn up … as a service.
  • Good things are being said about you … as a service.
  • Fame, riches and romance are yours for the asking … as a service.
  • A friend asks only of your time … as a service.
  • Romance comes into your life this year in a very unusual sort of way … as a service.
  • Stop and smell the roses … as a service.
  • Someday you shall see a wise person in the mirror … as a service.
  • He who shows too much cheek to a lady may have it slapped … as a service.