Introduction
Services are useful, but they come with a price tag. The cost of developing a service is higher than the cost of developing a traditional (non-service-oriented) application, primarily due to the extra work and infrastructure required. Another common concern when creating and consuming services is the possibility of a performance hit. Together these issues hint that even if you've decided to wholeheartedly adopt SOA, you may not want or need to move all your functionality into services. This is where the application Service Encapsulation becomes a focal point as we need specific criteria to determine what should and should not be encapsulated into services.

To make this determination, we will take a look at three different aspects:

-- acceptable reasons for creating a service

-- costs associated with creating a service

-- and, of course, the performance issue

After covering these aspects specifically in relation to single-purpose services, I will introduce an implementation strategy.

Reasons to Create a Service
Any service that is created needs to have a cleanly defined responsibility. The capabilities it exposes should clearly fall within this defined responsibility. In the case of a single-purpose service, it can be argued that it may be better to implement single-purpose logic as a non-service-oriented application. Let's take a closer look at some of the more important considerations:

Reuse
When logic is incorporated into a service, it is potentially available for reuse by multiple applications, some of which may themselves be services. Reuse leads to reduced development and maintenance effort, which translates into a lower cost of ownership and can further result in improved quality and lower risks [REF-2]. Reuse is also an important part of the agile IT enterprise. Composing existing logic to solve larger business problems is more efficient than writing all of the logic from scratch.

Alas, enabling this kind of reuse is not as easy as just incorporating logic into services; it often requires a lot of thinking and design effort to create a service that is truly reusable. But, it can be done. With regards to single-purpose services, reuse is usually not a consideration. These services are specific to parent business process logic and therefore serve just that one purpose. Figure 1 illustrates some common service categories [REF-3] and how they relate to each other and business processes.

(Figure 1: A Service Inventory typically consists of services from multiple categories. Process-specific services can not be reused when implementing support for other business processes. The more process-agnostic a service is the higher it's reusability.)

As just stated, services that cannot be repurposed to automate another business process, as per Non-Agnostic Context, are not considered reusable. However, an important realization here is that logic that solves only one large business problem may still be used by multiple consumers.

Let's explore this notion with a simple analogy. Due to technological advances, the manner in which people perform their jobs today is very different compared to 20 years ago and in the years to come we will probably witness an increase in the rate of technological progress. One kind of change that we have seen is that companies want to enable employees to perform their jobs using different tools in different settings. When we are at our desk we typically expect rich functionality and applications that make the best of our hardware, such as advanced large screens with high resolution and many colors and advanced keyboards with many functions, to name but a few.

On the other hand, we want to be able to do at least some of the same tasks when we are traveling and in that setting we may only have access to, say, a Smartphone. This type of mobile device is much more difficult to work with than a desktop application, and it requires a very different kind of user interface. Processing power, development environments and support for frameworks, among other things, are more limited for Smartphone applications. In spite of these differences, the two applications (desktop and mobile) can still be designed to automate the same task (see Figure 2). As a result, both applications could call the same single-purpose service (which actually does lead to a form of reuse).

(Figure 2: Alice, Bob and Carol work for different departments but are responsible for different activities that make up a business process. Some of the process steps need IT support and some don't. Carol owns a desktop application and a smartphone application. She creates a service to encapsulate the process-related logic that she is responsible for and lets her applications call the service.)

Even though reuse is an important criterion for creating a service it is by no means the only one. In a recent blog post [REF-4] Paul C Brown argues that the main criteria for determining if a capability ought to be put inside a service (apart from reuse) are multiple providers and isolation against change. These are discussed briefly below.

Multiple Providers
The reuse of a service can be thought of as the existence of two or more service consumers. The reverse of this is when you have two or more providers of the service

(Figure 3: Reuse compared to multiple providers.)

Choosing between providers, calling multiple providers, or merging together results from different providers might be non-trivial tasks, and applications can be shielded from this kind of logic by placing it inside a service. Corporate mergers and acquisitions often lead to this kind of scenario, but it can also occur within a company when multiple departments work with overlapping tasks and information. Due to the commonality of this situation, there are design patterns available that describe exactly how to construct such services (e.g. Enterprise Domain Repository [REF-5]).

A problem that must be handled when using multiple providers is that of partial failures. As the number of network links and composed services increases, the probability for failure in one of these links or services increases. To address this, a single-purpose service might securely store messages and make a number of retries to accomplish the delivery of messages to composed services, as per Reliable Messaging. Shielding a consumer from these complex tasks is a good enough reason to create a service, even if it cannot be reused.

Isolation Against Change
Being able to handle change successfully is one of the biggest promises of service-orientation. SOA can help us achieve increased business or organizational agility [REF-6] in several ways, one of which is by developing services and consumers in parallel. This approach requires that we (the service and consumer developers) have first have agreed upon the contract.

Another way is to create new functionality by composing existing services, either our own or services provided by someone else. Yet another important aspect is enabling change by limiting the parts that need development effort to bring about the desired changes. This means making sure that when you change something that the change only affects a limited and preferably isolated part of your software assets. All these issues relate to being able to develop new functionality or change existing functionality with less effort and in a shorter period of time.

To be able to quickly adapt to change can be essential for a business. As Jim Webber so eloquently puts it: "Business people are spaghetti-heads" [REF-7]! Behind this statement lies the profound understanding of the fact that business people need to make new decisions - sometimes even unexpected decisions - in the light of new business demands and opportunities.

Changes in a business process can lead to changes in services, consumers, or both, but there are also justifiable reasons for changing a service even when the business process it encapsulates has not changed.

When implementing a service, there are a variety of realization options ranging from buying or building applications hosted on premise via different hosting options and placing services in the cloud to options that haven't even been conceived yet [REF-8]. These ever-evolving options lead to never-ending opportunities for change that are further influenced by the cost associated with the options, your company's business strategy, and many other factors.

One factor worth calling out is the business strategy, because this strategy itself can be subject to change over time. When a company's strategy changes so will the strategic importance of its services and other IT assets. What this means is that outsourcing may become an option for a particular service today (e.g. to cut costs) but it may be then be necessary to in-source it tomorrow when it becomes more strategically significant (Figure 4)

By encapsulating logic into a service, these kinds of changes will become much easier to handle. A single-purpose service might swap out the current implementation of one of it's composed services with an alternative implementation without changing its contract. To be able to accomplish this you may have to apply Data Format Transformation inside the single-purpose service.

(Figure 4: By creating a service that encapsulates single-purpose functionality it becomes possible to quickly outsource or insource functionality - or choose between any of the options in between - without affecting the consumer)

Although it can be tempting to always plan for this kind of flexibility, it is important to keep in mind that agility may not be the most important factor for all processes or companies. Balancing the need for business flexibility in proportion to the cost of IT flexibility can become the true key to success.