WindowsDevCenter.com
oreilly.comSafari Books Online.Conferences.

advertisement


AddThis Social Bookmark Button

The Logic of Service-Orientation Plus 14 SO Tenets and Practical Principles
Pages: 1, 2

Service-Oriented Applications

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


Figure 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 specific programming languages, versions, technologies and frameworks, operating systems, APIs, and so on. However, between services you use standard messages and protocols, contracts, and metadata exchange.

The various services in a service-oriented application can be all in the same location or distributed across an intranet or the Internet, or they can come from multiple vendors, developed across a range of platforms and technologies, versioned independently, and even executed on different timelines. All of those aspects of plumbing are hidden from the clients in an application that interacts 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.

What Are the Key Attributes of a Service-Oriented Application?

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 that is 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 of the data passed between the client and the service.

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, would enable effortlessly transactional integers, secure strings, and reliable classes. In practice, however, there is a limit to the granularity that is 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. Evidently, this has historically been the trend of trading performance for productivity via methodology and abstraction.

What Are the Benefits of Service-Orientation?

Because the interaction between the client and the service in a service-oriented application is based on industry standards that prescribe how to secure the call, how to flow transactions, how to manage reliability, and so on, it is possible to create an 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 its core benefit. You can certainly interoperate without resorting to services, as was the practice prior to its arrival on the scene, but ready-made plumbing provides the interoperability for you. When you write a service, you usually do not care which platform the client executes on--that 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.

Service-Oriented Tenets and Principles

The service-oriented methodology governs what happens in the space between services. There is a small set of principles and best practices for building service-oriented applications referred to as the tenets of service-oriented architecture.

Core Tenets

  • Service boundaries are explicit

    A service is always confined behind boundaries such as technology and location. The service should not make the nature of these boundaries known to its clients by exposing contracts and data types that betray its technology or location. Adhering to this tenet will make aspects such as location and technology irrelevant. A different way of thinking about this tenet is that the more the client knows about the implementation of the service, the more the client is coupled to the service. To minimize the potential for coupling, the service has to explicitly expose functionality, and only operations (or data contracts) that are explicitly exposed will be shared with the client. Everything else is encapsulated. Service-oriented technologies should adopt an "opt-out by default" programming model, and expose only those things explicitly opted-in.

  • Services are autonomous

    A service should need nothing from its clients or other services. The service should be operated and versioned independently from the clients. This will enable the service to evolve separately from the client. The service is also secured independently, and it protects itself and the messages sent to it regardless of the degree to which the client uses security. Doing so (besides being just common sense) also decouples the client and the service security-wise.

  • Services share operational contracts and data schema, not type- and technology-specific metadata

    What the service does decide to expose across its boundary should be technology-neutral. The service must be able to convert its native data types to and from some neutral representation, and does not share indigenous, technology-specific things such as its assembly version number or its type. In addition, the service should not let its client know about local implementation details such as its instance management mode or its concurrency management mode. The service should only expose logical operations. How the service goes about implementing these operations and how it behaves should not be disclosed to the client.

  • Services are compatible based on policy

    The service should publish a policy indicating what it can do and how clients can interact with it. Any access constraints expressed in the policy (such as reliable communication) should be separate from the service implementation details. Not all clients can interact with all services. It is perfectly valid to have an incompatibility that prevents a particular client from consuming the service. The published policy should be the only way that clients decide if they can interact with the service, and there should not be any out-of-band mechanism by which the clients make such a decision. Put differently, the service must be able to express, in a standard representation of policy, what it does and how clients should communicate with it. Being unable to express such a policy indicates a poor design of the service. Not that the service may not actually publish any such policy due to privacy (if it is not a public service). The tenet implies that the service should be able to publish a policy if it needs to.

Practical Principles

The tenets just listed are very abstract, and supporting them is largely a facet of the technology used to develop and consume the services and the design of the service. Consequently, applications may have various degrees of compliance with the tenets, much the same way as developers can write non-object-oriented code in C++. However, well-designed applications try to maximize adherence to the tenets. I therefore supplement the tenets with a set of more down-to-earth practical principles:

  • Services are secure

    A service and its clients must use secure communication. At the very least, the transfer of the message from the client to the service must be secured, and the clients must have a way of authenticating the service. The clients may also provide their credentials in the message so that the service can authenticate and authorize them.

  • Services leave the system in a consistent state

    Conditions such as partially succeeding in executing the client's request are forbidden. All resources the service accesses must be consistent after the client's call. A service must not have any leftovers as a result of an error, such as only partially affecting the system state. The service should not require the help of its clients to recover the system back to a consistent state after an error.

  • Services are thread-safe

    The service must be designed so that it can sustain concurrent access from multiple clients. The service should also be able to handle causality or logical thread reentrancy.

  • Services are reliable

    If the client calls a service, the client will always know in a deterministic manner if the message was received by the service. The messages should also be processed in the order they were sent, not in the order they were received.

  • Services are robust

    The service isolates its faults, preventing them from taking it, or other services, down. The service should not require the clients to alter their behavior according to the type of error the service encountered. This helps to decouple the clients from the service on the error-handling dimension.

Optional Principles

While I view the practical principles as mandatory, there is also a set of optional principles that may not be required by all applications, although adhering to them is usually a good idea:

  • Services are interoperable

    The service should be designed so that it can be called by any client, regardless of its technology.

  • Services are scale-invariant

    They should use the same service code regardless of the number of clients and the load on the service. This will grossly simplify the cost of ownership of the service as the system grows, and allow different deployment scenarios.

  • Services are available

    The service should always be able to accept the client's requests, and the service should have no downtime. Otherwise, if the service is unavailable, the client needs to accommodate for that, which in turn introduces coupling.

  • Services are responsive

    The client should not wait long for the service to start processing its request. Having a nonresponsive service means the client needs to accommodate for that, which in turn introduces coupling.

  • Services are disciplined

    The service execution of any operation is relatively short and does not take long to process the client's request. Having long processing means the client needs to accommodate for that, which in turn introduces coupling.

Juval Löwy is a seasoned software architect and the principal of IDesign, a consulting and training company that focuses on component-oriented design using Microsoft COM+ and the .NET platforms.


Return to the Windows DevCenter.