YASOE: Yet Another Service Orientation Explanation in ASP

The terms service orientation (SO) and Service Oriented Architecture (SOA) are clearly the
new buzzwords leading us into the next generation of distributed applications and shaping
the stack of technologies that enable developers to implement them.
Despite (or maybe because of ) the huge amount of cyberspace real estate dedicated to
SO/A explanations, debates, and marketing, the SO/A semantics still remain unclear. Line up
ten SO/A enthusiasts and ask each “What is SO/A?” and you’ll get ten different answers, each
with varying degrees of overlap and conflict. These discussions, frankly, are becoming more
and more tedious and at the same time less and less fruitful.
That said, we still feel compelled to convey our SO/A point of view within this chapter.
Not because we believe ours is the canonical one, but because:
• Not everyone has had the luxury of reading the hundreds of SO/A related articles,
slides, and presentations. For these folks, this section serves as a nice overview of the
concepts.
• Those who are already veterans of the SO/A definition wars may benefit from this sec-
tion because it explains what we mean when we refer to SO/A. Hopefully, this will ward
off confusion (not to mention a few angry e-mails) based purely on semantics.
SO/A: Revolution, Evolution, or Neither?
One of the many complaints we often hear regarding SO/A is that it offers nothing that sophis-
ticated and successful distributed implementations aren’t already doing. To which we simply
say: “That’s the point.” We’ve all learned many hard lessons over the past few years by watch-
ing distributed applications deliver disappointing results or completely fail. The primary goal of SO/A is to take those lessons to heart and document the characteristics of the most success-
ful distributed systems. The hope is that this information will help future developers avoid the
same mistakes that crippled many early attempts at building distributed applications.
Therefore, we see SO/A as a meta-pattern. Like any pattern, it defines a proven approach
that incorporates the experience of architects and developers as they struggled to build these
systems. Or, as Joe Long of Microsoft succinctly said: “Service orientation is all about building
distributed systems the right way.”
Objects vs. Services: The Metaphor Matters
If you compare object orientation with service orientation, the first obvious distinction is the
use of the object metaphor versus the service metaphor. The object metaphor is simply an
abstraction to help humans better understand the machine code underneath. This, in turn,
makes it easier for humans to reason about and organize the larger system.
By nature, a metaphor implies characteristics. An object, for example, has attributes and
behaviors, and maintains its own state. In the context of software development, an object
implies chatty interfaces and support for encapsulation, inheritance, and polymorphism.
Objects and their implied characteristics have proved extremely helpful when you’re design-
ing and implementing local systems. However, in the early ’90s, high-speed LAN networks
became more common, making it feasible to create applications that were distributed across
several physical machines. Later, the emergence of the Web made it possible to communicate
with business partners over this common networking infrastructure rather than using a costly
propriety infrastructure.
Given the success of objects in the local context, it seemed natural to also apply the object
metaphor in the distributed context. Unfortunately, the characteristics that worked so well in
the local context were ineffective and even destructive in the distributed context. Specifically,
chatty interfaces caused an object-based distributed solution to perform poorly and stateful
objects made it extremely difficult to scale the system out. When you think about it, that’s a
fatal combination. Over time, many developers learned these issues and began developing
“objects” that were stateless and exposed chunky interfaces. But, of course, the resulting entity
was not an object at all. The bottom line is that the object metaphor actually hindered, rather
than helped, developers in gaining an understanding of the best way to develop a distributed
system.
Unlike past distributed approaches, which tried to take the round object metaphor and fit
it into the square distributed world, SO/A introduces a new metaphor—the service, whose
characteristics are much better aligned with the realities of the distributed world. The service
metaphor helps humans reason about the communication that occurs between two distrib-
uted applications. It also implies the characteristics that help make that communication as
efficient, flexible, and open as possible.