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.

What’s the well-architected solution to this kind of problem? You must discourage the copying of code into a new procedure because it’s the handiest solution. Instead, you need an architecture that gathers in one place all the logic that supports a related set of data. So whenever programmers need to make a change or an addition to the logic, they can go to one place to do it. Also, any other part of the application that needs to use or update the data knows where to get it. And if you provide a sufficient set of calls into that one procedure, then it can satisfy all requests in a consistent way.

When you develop in this way, the reduction in the amount of your application code can be staggering. Even other applications that will someday need to access data from your application can use a similar interface to retrieve it. And then your application is perilously close to becoming… well, you’re getting the picture now.

Single-Machine Days Long Gone
Make sure all code that belongs together under all circumstances runs as a unit, and that all other code that might want to talk to it runs in some independently-defined unit, without any dependencies between the two units. If you don’t, you’ll be sorry when you discover that for a configuration you never considered, the two code units have to run on two different machines.

Separating out the UI is only the beginning. If you make sure every business object that manages a rational chunk of data can run independently of every other business object, you’re on the right track. And when someone tells you that one of those chunks contains information necessary to somebody on some other corner of the planet, you can respond with a confident smile, and not a shiver of dread.

Here’s another example: One of the big hot buttons in application development is "workflow." Developers, especially those designing and building applications for a larger audience, realize that requirements differ and change depending on how all the steps in a business process need to take place. Just when you thought you were done coding, you are informed that Susie—and Susie has clout—insists on entering the stock code before the customer ID, rather than the other way around, as it was originally spec’d.

You might panic at first. Entering the stock code requires running a whole business object that validates the stock code for the country of origin, assesses its availability, and so on. Entering the customer ID requires accessing another similarly complex object. But wait! You coded each of those business objects so that you didn’t need to concern yourself with where they run, if they’re both in the same place, or whether the caller is a UI or a batch program. So it turns out you can easily accommodate Susie's wishes.

In a more serious scenario, your highly complex multistep ordering and pricing algorithm—remember the 157 price calculations you replaced with one—now has to be applied in a country you didn’t consider during development, but one where your company must now do business to survive. It won’t work to tell your prospective new customers, "Well, that’s not how we do things in our country." All your pricing work needs an overhaul so that step five can execute in front of step four and step seven can be replaced by a new step that reflects the tax requirements of the new customers.

But because you coded the business object that manages each step independently, you won’t have data dependencies or ordering dependencies between objects. With your nicely behaved code, you can reverse step four and step five and replace step seven without the rest of your application being the wiser, or having anything to complain about. It’s the most natural thing in the world for you to express all your business objects as, well, you know… services.

Armed with such civilized code, SOAP and WSDL can hold no terrors for you. You want the output as XML? Nothing simpler. It just becomes another call in a well-defined API. Your boss wants to be able to resell the pricing algorithm without the rest of the ordering code? No problem. They’ll never miss each other.

Jason Bloomberg at ZapThink reminds us that "you can’t get SOA from software, because SOA consists of best practices." Bingo. You have to create an architecture that sets you up for success when the world changes, regardless of what technologies they throw at you. New technologies should just be new wrinkles in an already familiar and comfortable suit, no more distressing than Susie’s special data-entry requirements. You can’t let technology dictate how you think about the basic job you’re working to solve—solving your company’s business problems and letting yourself and your company succeed in a changing world.

Does this mean that SOA is simple? No, not automatically. After all, there’s been enough sloppy code written to demonstrate that writing poorly architected applications is easier than writing good ones. But with the right motivations in place, architects and developers should have what is needed to build applications with a solid architecture, which makes everybody’s job easier in the long run. Anyone who’s had to code that 158th pricing algorithm variation will know exactly what I mean.

So a good "architecture" becomes its own reward. And as for the "service-oriented" part of it? Well, everybody thinks of their business logic as a set of services, don’t they? It just makes life so much easier.

About the Author
John Sadd has been with Progress Software for 18 years, working in many capacities in product development and the company’s Applied Technology group. Now an Engineering Fellow and Evangelist for the Progress OpenEdge product, he has written a half dozen books on OpenEdge products and given many presentations around the world.