In-Depth

Codejockeys won’t drink the SODA

• By Stephen Swoyer
• November 1, 2005

The service-oriented development approach (SODA) describes a programming model in which key application features or functions are exposed as well-defined interfaces that can easily be called as services.

Service enablement is often a reactive discipline, in that it’s largely concerned with existing applications that haven’t been designed for a serviceoriented architecture. SODA, on the other hand, is a proactive discipline. It results in applications that are, by definition, service-enabled. To the extent that SOA—or some pragmatic variation thereof—is inevitable, SODA should drive the creation of applications that are good SOA citizens. Sounds great, right?

Yes, it does, many codejockeys say. In fact, some argue, it’s a no-brainer. For this reason, some skeptics question whether SODA is a design approach that needs to be explicitly identified— much less acronym-atized. If you’re pursuing service-enablement, they say—and even if you aren’t—exposing an application’s features or functionality in the context of well-defined interfaces just makes good design sense. Call it SODA. Call it Proactive Enlightened Propitious Service Instantiation (PEPSI)— call it what you want, it’s a good idea, and it’s a major part of what goes into building future-tolerant systems and applications.

“[T]he promises of SOA—autonomy, explicit boundaries, schema and contract, those are sort of the same things that we’ve been trying to get to for years,” says Chris Wheeler, an eXtreme Programming coach and technical team lead with a prominent manufacturer of analytical instruments for the life sciences and pharmaceutical industries. “Nice little silos of functionality that are completely separate from other silos and have narrow interfaces that are well described. Sounds a lot like good design principles—low coupling, high cohesion.”

That’s the approach Wheeler and his colleagues use—although they don’t call it SODA. “We don’t want to lock into a vendor to provide us with one standard for orchestration and application integration, and find out down the road it was the wrong tool. For now, creating architectures that are SOA-ready seems to be the way to go,” he concludes.

Matthew Fleming, an enterprise architect and freelance consultant, agrees. “I think Web services [or] SOAs are marketing terms used to describe good ways to share data across the public Internet, nothing more,” he says. Far from embracing an explicit services-ready design approach such as SODA, says Fleming, developers would do better to focus on the basics. “What I’ve found is that many developers and shops hop onto the technology bandwagon while a technology is still maturing, and through lack of experience, deploy applications that are less than ideal,” he comments, citing the preponderance of “bad COM code” as a case in point. “With all that in mind, if programmers can focus on clean, simple design, and not rush headlong into SOA, then I think that people will find service-enabling architectures to be advantageous in their solutions.”

Ken Auer is an agile programming enthusiast and a principal with agile development house Role Model Software. He isn’t a knee-jerk skeptic of service-enablement, but Auer is critical of service-enablement for service-enablement’s sake, which he says is an engine for needless complexity and confusion. And in the case of SODA—which requires business analysts and programmers to make guesses about which features or functions should be exposed as services, as well as about how coarse or finegrained these services should be— there’s plenty of room for error.

“People are taking existing applications and putting a new interface on it to provide a boxy service that works for some things and has to have the rough edges shaved off by some more programming for others. Others are building new applications and imagining the interfaces others will want to use. They guess at some well, and others need a lot of work,” says Auer. “What we often end up with are problems that still need to be solved. The services offer a starting point. Often, they are merely the equivalent of the first two lines of a complicated solution to a calculus problem, where the rest of the proof is left to the student. There is still a lot more work to do, and often what’s left is the hardest part of the problem.”

Alex Cullen, an analyst with Forrester Research, doesn’t disagree with Auer, or with most other SOA realists, for that matter.

At the same time, he respectfully suggests, SODA makes sense, both on an intuitive level (as “good” design) and also when understood as an explicit design approach. The problem, Cullen says, is that the great blue-collar mass of programmers isn’t accustomed to coding in terms of clean or elegant design. They need some help. And SODA provides an explicit framework to guide them. And as far as many rock-star programmers are concerned, SOAs aren’t a slam dunk, either: they assume an unprecedented alignment of business and IT, with the latter taking a backseat to the requirements of the former. To the extent that many programming rock stars aren’t the savviest of business analysts, they’ll undoubtedly need help, too.

Back to Feature: Services by Design