Chapter 2: Service Orientation

Overview

The Internet is awash with talk of service orientation (SO), and most of that discussion addresses service orientation in the abstract. We are going to take a slightly different approach in this chapter. In the next few pages, we’ll look at service orientation from a requirements perspective. More specifically, we’re going to look at a generic messaging application and expose what is required to make it tick. Through this process, we’ll unearth some of the concepts that are essential to comprehending service orientation. The last sections of this chapter are devoted to a more formal definition of service orientation and a discussion of why service orientation makes sense in today’s world of distributed computing.

If you ask 10 “SO-savvy” people to define service orientation, you’ll probably get 10 different answers. If you ask them again in a couple of years, you’ll probably get a different set of answers. This phenomenon is not new. When object orientation (OO) and component-driven development arrived in the mainstream, many developers were confused as to how they should adapt or reconceive their procedural designs given these new architectural models. Understanding OO and component architectures required a fundamental shift in thinking about application designs. The process was at times painful, but the payoffs are more robust designs, greater code reuse, advanced application functionality, easier debugging, and shorter time to market. In my opinion, moving to SO designs from component-driven designs will require a fundamental shift in thinking of the same magnitude as the move from procedural architectures to OO. The good news is that SO designs offer tremendous benefits in the form of richer communication patterns, loosely coupled applications, improved application functionality, and fulfilling the promise of true application interoperability. Because the term interoperability is heavily overloaded, some specificity is needed to avoid confusion. In this context, interoperability refers to the ability for a system to change hardware, operating system, or platform without affecting the other participants in the distributed scenario.

Service orientation, despite the current confusion associated with its definition, is not a new concept. It has been around since the reign of the mainframe and has been more recently adopted as a paradigm in middleware. Recent initiatives toward interoperability and richer communication patterns have reignited interest in service orientation and are moving SO into the mainstream. It’s reasonable to assume that the definition of service orientation will evolve as it becomes more widely implemented.