Characteristics of Service Orientation

Modularity, reusability, and flexibility are among the key characteristics of service orientation. Each of these concepts is clarified here:

Modularity: Organizations need to begin their move to service orientation by rethinking the large, complex, and unmanageable applications of the past. The route to modularity begins with the following:

• Identifying the components of business applications

• Configuring reusable services to meet business demands

Reusability: Knowing which services are best suited for reuse depends on how you classify the service. Basically, the components of an application can be classified in one of two ways:

• Reusable: These services are common to various business processes important to the organization. You need to encapsulate the rules and logic of a common business process to create a reusable business service. A service designed to check a customer’s credit is an example of a service that can easily be reused in lots of different situations.

• Application-specific: These services are unique to a particular business process and include logic or instructions that are likely to be used in the specific context of the application at hand. Such services are not likely to be reused.

Using a tested and proven component speeds development enables a higher level of security and trust and saves money.

Flexibility: The flexibility derived from service orientation is a function of the modularity and reuse of business services. The efficiency, manageability, and flexibility of service-oriented IT environments don’t happen by magic. A fair amount of oversight on the part of the IT team to maintain the desired flexibility is needed over the long run. Here is a list of some of the responsibilities required to make sure savings and benefits of service orientation are achieved:

• Maintain a catalog of business services to make it easy for developers to identify which services are tested and approved and should be reused. The more these services are used in different applications, the lower the cost of using them. However, it’s important to remember that the benefit of reusable services is much more than just the savings from reusing the same software code.

• Make service management a top priority by building in a way to identify root causes of problems early in the development process and by continuously monitoring and fixing sources of errors.

• Seek continuous improvement with ongoing measurement of performance and accuracy of business services.

This responsibility for quality becomes increasingly important in hybrid cloud environments. The provider of cloud services shoulders much of the responsibility for oversight because the consumer of a cloud service sees only the end result. The consumer of a cloud service needs to operate under the assumption that the business service will work as intended.

In a business service that is reused 500 times, a single error in your applications quickly becomes 500 errors or more. By adding a greater level of control and management to IT, you will be able to improve the security and governance of your business processes. To avoid this type of problem, make sure that a service is well tested before deploying it throughout your organization.

Building reusable components

Building reusable components can be very challenging. You need to identify which components are best suited for reuse. To accomplish this goal, you need to keep business logic separate from plumbing — technical infrastructure.

To build a software application, you must tell the computer how to do what you want on two levels:

In human terms: the business logic

In computer terms: the plumbing

Business applications comprise lines of program code that tell computers what actions to take. Some of these instructions are written as business logic — “Add an item line to the order,” for example. Some are simply plumbing at the infrastructure level — computer-level directives, such as “Check that the printer is available.” Both are necessary. If you don’t describe the application’s activity in simple business logic (purchase orders, products, customers, accounts, and so on), you quickly lose sight of what you’re trying to achieve. If you don’t describe in computer terms exactly how the computer should carry out its task, the software simply won’t work.

Business logic needs to be as free of plumbing dependencies as possible if you intend to follow a service-oriented approach. You need to keep them separate so you maintain flexibility when things change. For example, if you want to change the order in which particular business functions happen, and you’ve kept your business logic separate from your plumbing, making these changes is no big deal. But if your business logic and your plumbing are one giant application, changes are costly and complicated, take time, require extensive testing, and are a very big deal, indeed.

Figure 3-2 introduces the idea of a business layer and a plumbing layer, also introducing the idea of specific services (for simplicity’s sake, we left out the web server and browser). The combination of business and technical layers works like this:

The Business Service layer consists of software components that provide and carry out specific business functions. In this example, the business services that will be delivered to users are order processing and credit checking.

The Plumbing layer consists of components that support the aforementioned business services by marshaling and managing actual computer resources. In this example, the components needed to handle the plumbing are the web server and the database server.

The diagram in Figure 3-2 illustrates the concept of dividing software applications into components that carry out business functions — business services — and components that support the use and management of computer resources — plumbing. With this breakdown, you are in a better position to reuse the narrowly defined business services in multiple ways.

Service orientation compared to traditional architecture

In traditional software architecture, various software components are often highly dependent on each other. These software component dependencies make the application change management process time-consuming and complex. A change made to one software component may affect lots of other dependent software components, and if you don’t make all the right changes, your application (or related applications) may fail. One small change to an application can make its way through the whole application, wreaking havoc and leading to massive revision of software code.

How do you achieve flexibility? By implementing an approach that removes dependencies between components and services. An architectural approach based on service orientation helps to change the rules by avoiding the complex layers of software components all dependent on each other. Developers need to embrace a new way of thinking to take advantage of modular and reusable components. As a result, they have more freedom to change quickly and accurately. Table 3-1 summarizes some of these key differences between traditional and service-oriented computing.

Table 3-1 Traditional versus Service-Oriented Computing

Traditional Computing	Service-Oriented Computing
Siloed applications	Breaking down of silos
Dependent components	Loosely coupled composite components
Complex change management	Efficient change management
Many different software architectures	More standardized architecture

The Open Group developed and approved a standard for service-oriented computing infrastructure for a cloud called Technical Standard for the Service-Oriented Cloud Computing Infrastructure (SOCCI) Framework. This standard recognizes that IT infrastructure and the management of IT infrastructure need to change to adequately support cloud computing. This evolved infrastructure — SOCCI — is defined by the Open Group as follows (reference SOCCI Framework Technical Standard by Open Group — www.opengroup.org/soa/source-book/socci/index.htm ):

SOCCI is a “service-oriented, utility-based, manageable, scalable on-demand infrastructure that supports essential cloud characteristics, service, and deployment models. In other words, SOCCI describes the essentials for implementing and managing an Infrastructure as a Service (IaaS) environment.”

For more information on the Open Group standards, refer to Chapter 18.

Avoiding and eliminating the many layers and intertwined software dependencies that bog down the change management process in traditional computing is a requirement for moving to service orientation. The goal of service orientation is to ensure that each component is responsible for a single, easily understood function, and nothing else. To accomplish this goal, business and IT need to work together so that the software components represent essential business processes. You will not be able to reuse a component if it tries to do too much at once.

On the other hand, in some situations, business requirements call for certain dependencies to be maintained. This is to be expected. However, it’s important to make sure the components are linked together in an organized and structured way so they can be easily located and changed when necessary.

Avoiding dependencies also applies when writing completely new applications. Initially, more discipline and more time to write software without dependencies are required, but eventually writing software without dependencies becomes the norm for many developers. In the long run, the reality of dependencies in traditional applications slows development, thwarts easy business change, and chokes the manageability of hybrid cloud environments. So, investing in the creation of modular and reusable software components makes sense.