What do people mean when they say SOA infrastructure? Service-oriented architecture may be a way of thinking, but it is also represented in a range of architectural practices such as message queuing middleware and enterprise service bus (ESB). Certain types of software may be used like Legos in a typical SOA project, but there is little consensus on what counts as SOA infrastructure.
Indeed, SearchSOA.com recently conducted a 2011 Readership Survey that solicited views on which of the contenders mattered most. The range of responses was striking as was the lack of any clear “winner.” For instance, none of the seven different technologies described earned more than a 50% score and the lowest scores were in the mid-20% range. (Survey choices were message queuing middleware; enterprise service bus (ESB); publish & subscribe middleware; SOA and Web services governance; test or management software; services registry/repository; service orchestration tools; and SOA appliances/XML gateways.)
In other words, there are a lot of choices and little agreement about what’s best. However, of the choices out there, message queuing middleware seems to be leading the pack, followed closely by ESB (see Figure 1).
Mark Eisenberg, a former member of Microsoft’s Azure team and now director of Fino Consulting says it is no wonder there is confusion – SOA is simply too big of a concept. “I think that’s why it has had limited success in the enterprise,” he says. In his view, ESBs and similar kinds of technology are implementation details. “ESB is a way for services to communicate without having to know the specifics of how to contact the services,” he says. In that sense, he says, ESBs are simply an infrastructure element.
The long list of possible SOA infrastructure elements can make implementation difficult. Eisenberg says that the original “dream” for SOA was that you would build a service, you would register it, and then some other service that needed that functionality would simply “go there and say, I need that and simply connect to that service.” However, in fact, that represents a complex undertaking. In Eisenberg’s view, there is no simple “right” answer to the question of which technology is most relevant to the concept of SOA infrastructure. “Message queues are a very fundamental computer concept and services buses are also very fundamental to SOA,” he says.
The long list of possible SOA infrastructure elements can make implementation difficult.
A similar take on the question comes from Mike Rosen, an industry expert in business architecture, SOA and enterprise architecture and a practice director for Business and Enterprise Architecture at the Cutter Consortium (an IT Research Firm). He says, in general, when people refer to SOA infrastructure, they mean the product platform that the SOA runs on, such as an ESB. “Occasionally, if taken from a high level business perspective, they mean the entire SOA stack, including the business services, but that would be an unusual interpretation of the term,” says Rosen. Still, “interpretation” is what’s at issue.
“While ESB is probably the most relevant, it of course depends on the context of the usage and requirements,” he adds. Further, Rosen points out that ESB and queuing are not architectural 'practices', but rather an implementation of the infrastructure. “Also, virtually all ESB products include queuing as an underlying capability,” he adds.
So, is there a way to parse the SOA and infrastructure concept a little further? Possibly. According to Nate Minshew, enterprise architect/principal consultant at Asynchrony Solutions, Inc., who relied on Department of Defense definitions related to SOA to provide a degree of clarity on a recent project. “In our project we built a service taxonomy so we could classify the different services to provide a mechanism to quickly identity a service based on what functional purpose it had. The taxonomy was primarily a high level category of process services.
Minshew says decisions about infrastructure were based on the same standards taxonomy. “We wanted to identify specific taxonomy and DOD had certain standards mandated from the DOD Standards Repository. A lot of those were fairly incomplete, he says. but there was room to make recommendations based on them such as SOAP 1.2, PKI standards and so on,” he explains.
In turn, says Minshew, he hoped to get clearer definitions of infrastructure components, like “what is an ESB?” “We found that a lot of vendors market products as ESBs but what they call an ESB also has services and governance and management tools – we wanted to look for more granular pockets of technology. Our definition of an ESB was the messaging infrastructure and the ability to do composition for web services and the routing and processing that goes on,” he says.
In short, Minshew notes, infrastructure can take many forms and no one term suffices to describe it.
How do you define SOA infrastructure? Let us know.
This was first published in March 2012