Hi. My name is Udi, and I develop systems using SOA.

(Chorus: "Hello, Udi.")

It's been almost two years since I last wrote code that was not service oriented. But the other day, I had this bug. I needed to add some functionality to my target service so that the initiator could work around it, it was after 7 p.m., and I'd promised the kids to be home early (again)… I just wanted to make a couple of synchronous calls and go home.

Anyway, long story short—I just went home, and the next morning I did it properly, with one-way messaging and everything.

To tell you the truth, that all goes to show that this whole SOA deal, it's not easy. You see, before I got into service-oriented systems development at my previous employer, things were a lot different.

It's not that the systems we developed were much different before than after. I've always stayed pretty much in the same vertical domain. Back then, I wrote modular, flexible code as well as the next guy. I used design patterns where they were appropriate, using all the good object-oriented practices. Objects that could be deployed to different machines were designed to be stateless, but there weren't any constraints on whether calls made to them were synchronous or not—client code would make calls on a different thread if necessary. We used the best practices of the time and things worked fine.

But then people started talking about SOA, about service oriented architectures. I heard about it at first from the tech guys, but then even the business guys started saying "SOA, SOA."

That was weird. Normally, when it comes to new things, the business guys are always telling us, "If it ain't broke, don't fix it," so the fact that they were excited about SOA was definitely unexpected.

I asked one of the old-timers why business people cared about SOA. He's a cynic, so he said there is this five-year cycle where something new comes along, everybody hypes it as The Solution, it slowly gets adopted, the good parts stick, the not-so-good fade away, and our best practices get a bit better. And that's how things work until the next new thing comes along.

"If 42 is the solution, then what's the problem?"—I'd just finished the last installation of the Hitchhiker series, so I thought he'd say that SOA was just another of those overhyped, good-for-five-years new things.

The Five-Year Plan
You know, I was wrong. The old-timer continued, "You know what the problem is? The problem is that every five years they want us to rebuild the same systems using new technologies and methods and all. But the funny thing is, there were real business needs that those systems couldn't answer. For some reason or another, we could hardly ever extend them in the ways they needed. Sure, we could extend them in lots of other ways, but that didn't matter. We just didn't think of those problems when we were building the flexibility in."

I'd heard the business side grumbling about the limitations of us technical types for as long as I could remember, but that just seemed part of the game. I'll be honest—I never saw any major technical blunders get into production. We designed and built solid systems that worked and answered business needs. Sure things could always better, but I thought they were pretty good to begin with.

It was only later that when I realized that SOA came from the field, from the real world—and not from the ivory tower—and it was a way to really make things better, to solve problems that we technical guys didn't see, but which those business guys saw right away.

SOA wasn't a clean refinement of architectural principles distilled by a bunch of out-of-touch academics with too many computer-science degrees. SOA was a battle plan used by commanders to handle the harsh realities of the front lines of getting real systems built—and built to last.

You know what? Forget theories. In this real world of ours, servers go down, either for maintenance, or just because they go down. The same thing happens with network equipment. The network, when it is there, is flaky and sometimes slow—users have this tendency to send 30-meg PowerPoints to each other, databases get migrated or transferred to different servers.

In the real world, deployment is temporary; the software isn't super-glued to one particular device or platform. But once our code needs to leave the machine it is on, it is ill equipped to handle the brave new world it is thrust into. Ever have a problem with a migration or a failover, or a system upgrade that broke everything? That's just one of the problems that SOAs help find. And you know, that's a business problem just as much as it's a technical problem.

SOA to the Rescue(?)
SOA isn't so much about improving how we develop software; it is more about defining which problems we are supposed to solve.

Around the time I had this epiphany about SOAs, I received a nice offer to join my current employer, where service orientation was the norm. And the rest, as they say, is history.

"So you figured out what it means to develop distributed systems. Good for you."

(This was Darren, a longtime vet of development for one of the big telcos. He'd been coming to our support group for a while, and was always a little sarcastic and skeptical.)

"Udi" (Darren continued), "the fact that your requirements analysts didn't specify what level of flexibility was required and in what areas—that was your problem. SOA and the whole Web services standards are just a mess of mixing generic architectural guidelines and angle brackets. 'Services should be autonomous'—let's see you take that to the bank."

(Darren wasn't the only one. I saw a couple of other guys just waiting to pop my service-oriented optimism bubble. Clem jumped in first.)

"And don't you dare mention orchestration as the killer app of SOA." (Clem and I had worked together before. He was the fastest typist I knew: You should see C++ whipped out at 100 words per minute, no typos. It's impressive. But he's stuck on the idea of coding, and hates drawing little boxes, either with a pencil or with a mouse.)

"You think it's easy to draw business logic? I'm sick of scrolling back and forth on a huge canvas where all the systems' logic appears just to get a clue of what happens when. There are some things that should just stay as code."

Logical Integration
Look, I don't know what SOA means to all of you. All I can tell you is that, the way I develop now, and the problems I try to solve, fall into the general consensus of SOA. But that doesn't mean that I have to get bogged down with all the ins and outs of all the billions of specs that keep popping up around Web services and process management.

Where we did have to deal with integrating our existing systems, maybe with a new system, into a single solution, those standards weren't the problem. I mean, yes, it's nice that we can flow the security context through our SOAP messages and Web service calls, but the hard part was the logical integration. It's always been hard.

"Clem, do you remember a couple of years ago when we were on that post-ERP project in the Valley? They had an enterprise-wide canonical schema that they put, like, ten person-years into. The problem was that systems would behave differently for the same elements—well it's understandable, but it's still a problem."

Anyway, remember that there were those two systems that treated the terms Client and Customer differently? Yeah, even though the Official Documented Schema defined a Customer to be a special case of a Client. Ha ha. It took us weeks until we understood that when going from system A to system B, we had to transform Clients to Customers, but when going back, we had to leave things alone—no reverse transformation. Things were interoperable, just not understandable. It was crazy.

It's the logical integration that'll get you every time. Angle brackets just make it so you don't have to write a parser. To get things right, you need to understand the services—who's using them, who's offering them up, and what they're thinking about. Once you understand that, then you can start stitching them together.

Service Orchestration
(Darren wasn't convinced—not that I was trying to convince him, or Clem, or anyone, though maybe it sounded that way. I was just talking about my experiences. We'd talked a couple of times before and he was squarely in the RPC camp—armed, of course, with the best practices for using remote procedure calls. Actually, there was quite a bit in common with how we deal with versioning. The one thing he didn't like about RPC was the synchronous API—clients had to do the asynchronous work themselves. That was one of the few things he was willing to accept from Messaging.)

And orchestration, or choreography, or whatever the currently "in" thing is — it's a tough concept to get your head around, but when you've got it, you've got it. Development isn't like conducting an orchestra or choreographing a dance. I don't coordinate services as if I'm above, or outside them. When you're writing a service that needs to work with other services to get something done, things are different, and that's where orchestration comes in.

While we're bashing terms, forget "service." What you're communicating with, when you call a service, is really a different system on a different network—you don't even know if it's up, or where it is, or whether it's on Linux or Windows. That's doesn't matter. It's also not about, "Well, I'm sending a message instead of calling a method," thinking it's the same thing. Well, sure, for all intents and purposes, the calls look the same at the code level. But when it comes to the semantics of a distributed world, you think about services and RPCs differently.

First of all, sending a message means "fire-and-forget." You're not calling a subroutine, guys, sitting back and waiting a few milliseconds for the response-that-must-come and then you continue the thread. No, that's not how it works. It's asynchronous. Never forget that.

When you send a message, the thread that sent the message isn't sitting around waiting for a reply or anything. It's busy handling a bunch of other requests. So, if your business logic states that if you don't get a response within 30 seconds something needs to be done, you need to specifically create a timer for that, and tear it down when you get a response.

Don't forget about the case where you get another request that depends on a response you haven't received yet, but you know you should receive. Something has to handle that. To top it all off, you have to take into account the fact that the hardware you're running on can fail at any time. Then, and only then, can you start intelligently talking about performance. System-wide robustness and consistency take center-stage in my mind when I'm developing systems these days.

Go with Your Gut
But you know what hasn't changed all that much? There's still a part—an important part—in software development that's an art. Maybe not so much in projects where you extend an existing environment, but when you're doing green-field development—deciding how to divide the system up into services, setting boundaries, deciding which functionality goes where—it's all gut feeling.

Eventually you manage to translate that gut feeling into something concrete, usually by taking a scenario and drawing the back-and-forth of messages. Right then, you can see that one service can't do its work without a bunch of data that's in another service.

Don't get me wrong—no service is an island. But if you see that you have to push out thousands of entities from one service into another, your boundaries are probably wrong.

"All in all, though, is it worth it? I mean, it sounds like a lot more work."

(It was "the new guy"—Dave, Dale, Dan… something with a 'D...')

For my own selfish reasons, yes, it's worth it. It's more work, but it is more interesting work. You get to play with more hardware—unplugging networks and popping out a hot-swap drives in the middle of business transactions, and such. Plus, it makes a hell of an impression on the business guys, which paves the way for, shall we say, improved work conditions.

As a part of my job, I go around and "consult" on other projects, sometimes in-house, sometimes at our clients. I run into all kinds of development groups and methodologies, each one convinced of that their way is The Right Way™. There's no amount of convincing that will get them to think that maybe they haven't covered everything. So what I do is go into one of their test labs, unplug a switch, and watch the system crash within seconds.

There is no way more efficient to bring the point home. After that, everybody is ready to listen.

"I'd say that messaging, not SOA, paves the way to robust distributed systems. But what about the business flexibility you mentioned? That has nothing to do with robustness."

(Clem was always quick to pick up on things I glossed over. He also had no problem pointing it out, for everyone to see. Thanks, buddy. But he always kept me honest, I'll give him that.)

Well, considering I've only been doing this service-orientation stuff a couple of years, I guess I haven't run into the five-year do-it-again cycle, so I can't really say. What I can say is that business flexibility comes only from understanding the business.

These days, the vast majority of my time spent at the beginning of a project is on understanding why we're even doing it, what business value it's expected to give, and how it will grow over time. It's not about feeds-and-speeds any more. That business-level understanding helps me set the boundaries of my services, and even do a couple of dry runs of future scenarios with our business analysts.

On the technical level, it's the ultimate level of loose coupling that messaging gives you that allows you to change so much without breaking things. The fact is, it's much easier to version message schemas than nearly anything else. (Darren was bristling.) But those of us with experience can probably pull it off in whatever style we like.

Anyway, I've talked enough. Time for somebody else.

("The new guy" stands up, and sighs.)

"Hi. My name is Andy, and I develop systems using SOA…"