email article printer friendly

If SOA Looks Hard, You’re Looking at it Wrong
Deconstruct the way you think about a service in service-oriented architecture.
by John Sadd

February 14, 2006

The playwright Moliere’s creation Monsieur Jourdan was astonished one day to come to the realization that he had been speaking prose all his life without realizing it. Similarly, people in the software industry often attach weighty meanings to what should be simple words and concepts. In the process, the simplicity is lost and the words intimidate you rather than support you.

Today IT professionals are laboring under what seems to be a requirement to express all business applications using a service-oriented architecture (SOA). When you hear the word "service," all the simple meanings seem to disappear (such as, something that serves you), and only the weight and burden remain. To say "service" somehow automatically means using Web services for the communication between all the parts of your applications, let alone with all the other applications that it must talk to in order to survive and prosper.

This assumption brings with it a list of groan-inducing three- and four-letter acronyms—SOAP, WSDL, SSL, SAML—along with a host of burgeoning standards that have to be lumped together as WS-*—read "WS splat," as you’re splattered by the implications of juggling Security, Routing, Reliability, Eventing, Addressing, and more without dropping anything on the floor.

Services were supposed to make it easier for you to build successful applications that handle business needs. But do you even remember the business needs after you’re done struggling with all the technology requirements?

I’d like to suggest that, as with Moliere’s ironic observation that a highfalutin word can really be applied to commonplace things, you should think about the services of a service-oriented architecture as, well, serving you in your business needs, not making your life more complicated. And, like all the mundane everyday statements that can be given a greater cachet by labeling them as prose, the right expression of the solutions to your business problems can turn into services and even fit into a true SOA if you think about the simplicity of the business task at hand and let the technology serve you without getting in the way. Here are some examples of what I mean.

The first step that’s been recommended for years—decades, maybe, at this point—is to turn the spaghetti code of a typical older application into something more flexible and forward-looking. You can do that by separating your user interface from your business logic. Take the logic that captures your business rules and remove it from the code that puts up the old green-screen interface or somebody’s proprietary client/server GUI. Now you’re on the path to keeping the value of the business rules intact when the UI fashions change. What’s the alternative to nicely separated duties between the logic and the UI? Well, as people kept saying with a quiet smile at an architecture conference I recently attended, "Thank the Lord for screen-scraping tools."

With a proper separation of roles, you won’t have to scrap your core business value and code your application again during the next industry "revolution." You’ll be set up to access your data and domain logic from a variety of interfaces. You’ll even be able to let parts of your application that don’t have a UI retrieve data by using the same API calls your nicely separated code now uses. You’ll also be on the way to letting other applications approach your data by publishing the API for them, which will make your code look a lot like—gasp, could it be?—a service.

Here’s another example. What’s one of the most common elements of a bloated application, one that has grown and grown over the years without much coding discipline? What do harried programmers do whenever they need a function that resembles or duplicates something already in the application?

The Dangers of Copy-and-Paste
They copy and paste somebody else’s code—or maybe their own code—into a new procedure and make the necessary changes to adhere to the spec. Of course, they could factor out all the code parts that apply to both cases, or a growing number of cases, taking care not to break the code they started with. Then they could parameterize the variations. But most developers don’t have time to do that.

You know where this scenario leads. Many applications have so much repeated and copied code that the similarity among resulting procedures is the closest thing these applications have to an architecture. A lead developer on a large ERP application once admitted to me that she had identified 157 different places in an application where a price calculation is performed.