Section A.2. Service-Orientation

A.2. Service-Orientation

If you examine the brief history of software engineering just outlined, you notice a pattern: every new methodology and technology generation incorporates the benefits of its preceding technology and improves on the deficiencies of its preceding technology. However, every new generation also introduces new challenges. I say that modern software engineering is the ongoing refinement of the ever-increasing degrees of decoupling.

Put differently, coupling is bad, but coupling is unavoidable. An absolutely decoupled application is useless because it adds no value. Developers can only add value by coupling things together. The very act of writing code is coupling one thing to another. The real question is how to wisely choose what to be coupled to. I believe there are two types of coupling. Good coupling is business-level coupling. Developers add value by implementing a system use case or a feature, by coupling software functionality together. Bad coupling is anything to do with writing plumbing. What was wrong with .NET and COM was not the concept, it was the fact that developers still had to write so much plumbing.

Recognizing the problems of the past, in the late 2000s, the service-oriented methodology has emerged as the answer to the shortcomings of object- and component-orientation. In a service-oriented application, developers focus on writing business logic, and expose that logic via interchangeable interoperable service endpoints. Clients consume those endpoints, not the service code or its packaging. The interaction between the clients and the service endpoint is based on a standard message exchange, and the service publishes some kind of standard metadata, describing what exactly it can do and how clients should invoke operations on it. The metadata is the service equivalent of the C++ header file, the COM type library, or the .NET assembly metadata. The service's endpoint is reusable by any client compatible with its interaction constraints (such as synchronous, transacted, and secure communication) regardless of the client's implementation technology.

In many respects, a service is the natural evolution of the component, just as the component was the natural evolution of the object. Service-orientation is, to the best of our knowledge as an industry, the correct way to build maintainable, robust, and secure applications.

When developing a service-oriented application, you decouple the service code from the technology and platform used by the client; from many of the concurrency management issues; from the transaction propagation and management, and from the communication reliability, protocols, and patterns. By and large, securing the transfer of the message itself from the client to the service is also outside the scope of the service, and so is authenticating the caller. The service may still do its own local authorization as is dictated by the requirements. Much the same way, the client is agnostic of the version of the service: as long as the endpoint supports the contract the client expects, the client does not care about the version of the service. There are also tolerances built into the standards to deal with versioning tolerance of the data passed between the client and the service.

A.2.1. Benefits of Service-Orientation

Because the interaction between the client and the service is based on industry standards that prescribe how to secure the call, how to flow transactions, how to manage reliability, and so on, you could also have off-the-shelf implementation of such plumbing. This in turn yields a maintainable application because the application is decoupled on the correct aspects. As the plumbing evolves, the application remains unaffected. A service-oriented application is robust because the developers can use available, proven, and tested plumbing, and the developers are more productive because they get to spend more of the cycle time on the features rather than the plumbing. This is the true value proposition of service-orientation: enabling developers to extract the plumbing out of their code and invest more in the business logic and the required features.

The many other hailed benefits, such as cross-technology interoperability, are merely a manifestation of the core benefit. You can certainly interoperate without resorting to services, as was the practice until service-orientation. The difference is that with ready-made plumbing you rely on the plumbing to provide the interoperability for you. When you write a service, you usually do not care which platform the client executes onthat is immaterial, which is the whole point of seamless interoperability. But a service-oriented application caters to much more than interoperability. It enables developers to cross boundaries. One type of a boundary is technology and platform, and crossing it is what interoperability is all about. But other boundaries may exist between the client and the service, such as security and trust boundaries, geographical boundaries, organizational boundaries, timeline boundaries, transaction boundaries, and even business model boundaries. Seamlessly crossing each of these boundaries is possible because of the standard message-based interaction. For example, there are standards for how to secure messages and establish a secure interaction between the client and the service, even though both may reside in domains (or sites) that have no direct trust relationship. There is a standard that enables the transaction manager on the client side to flow the transaction to the transaction manager on the service side, and have the service participate in that transaction, even though the two transaction managers never enlist in each other's transactions directly.

A.2.2. Service-Oriented Applications

A service-oriented application is simply the aggregation of services into a single logical, cohesive application (see Figure A-1), much as an object-oriented application is the aggregation of objects.

Figure A-1. A service-oriented application

The application itself may expose the aggregate as a new service, much like an object can be composed of smaller objects.

Inside services, developers still use concepts such as specific programming languages, versions, technologies and frameworks, operating systems, APIs, and so on. However, between services you have the standard messages and protocols, contracts, and metadata exchange.

The various services in the application can be all in the same location or be distributed across an intranet or the Internet, or they could come from multiple vendors, developed across a range of platforms and technologies, versioned independently, and even execute on different timelines. All of those plumbing aspects are hidden from the clients in the application interacting with the services. The clients send the standard messages to the services, and the plumbing at both ends marshals away the differences between the clients and the services by converting the messages to and from the neutral wire representation.

Since service-oriented frameworks provide off-the-shelf plumbing for connecting services together, the more granular the services are, the more use the application makes of this infrastructure, and the less plumbing the developers have to write. Taken to the extreme, every class and primitive should be a service to maximize the use of the ready-made connectivity and to avoid handcrafting plumbing. This, in theory, will enable effortlessly transactional integers, secure strings, and reliable classes. In practice, however, there is a granularity limit dictated mostly by the performance of the framework used (such as WCF). I do believe that as time goes by and service-oriented technologies evolve, the industry will see the service boundary pushed further and further inward, making services more and more granular, until the very primitive building blocks will be services. This evidently has been historically the trend of trading performance for productivity via methodology and abstraction.