Fundamental SOA

Because the term "service-oriented" has existed for some time, it has been used in different contexts and for different purposes. One constant through its existence has been that it represents a distinct approach for separating concerns. What this means is that logic required to solve a large problem can be better constructed, carried out, and managed if it is decomposed into a collection of smaller, related pieces. Each of these pieces addresses a concern or a specific part of the problem.

This approach transcends technology and automation solutions. It is an established and generic theory that can be used to address a variety of problems. What distinguishes the service-oriented approach to separating concerns is the manner in which it achieves separation.

3.1.1. A service-oriented analogy

Let's take your average cosmopolitan city. It is already full of service-oriented businesses. Individual companies are service-oriented in that each provides a distinct service that can be used by multiple consumers. Collectively, these businesses comprise a business community. It makes sense for a business community not to be served by a single business outlet providing all services. By decomposing the community into specialized, individual outlets, we achieve an environment in which these outlets can be distributed.

When coupled with "architecture," service-orientation takes on a technical connotation. "Service-oriented architecture" is a term that represents a model in which automation logic is decomposed into smaller, distinct units of logic. Collectively, these units comprise a larger piece of business automation logic. Individually, these units can be distributed.

Distributing automation logic into separate units is nothing new. What is it then that makes service-oriented separation so different? Much of this book is dedicated to answering that question. However, let's take a preliminary look at some notable distinctions.

Even in a distributed business community, if we impose overbearing dependencies, we could inhibit the potential of individual businesses. Although we want to allow outlets to interact and leverage each other's services, we want to avoid a model in which outlets form tight connections that result in constrictive inter-dependencies. By empowering businesses to self-govern their individual services, we allow them to evolve and grow relatively independent from each other.

Though we encourage independence within our business outlets, we must still ensure that they agree to adhere to certain baseline conventionsfor example, a common currency for the exchange of goods and services, a building code that requires signage to conform to certain parameters or perhaps a requirement that all employees speak the same language as the native consumers. These conventions standardize key aspects of each business for the benefit of the consumers without significantly imposing on the individual business's ability to exercise self-governance.

Similarly, service-oriented architecture (SOA) encourages individual units of logic to exist autonomously yet not isolated from each other. Units of logic are still required to conform to a set of principles that allow them to evolve independently, while still maintaining a sufficient amount of commonality and standardization. Within SOA, these units of logic are known as services.

3.1.2. How services encapsulate logic

To retain their independence, services encapsulate logic within a distinct context. This context can be specific to a business task, a business entity, or some other logical grouping.

The concern addressed by a service can be small or large. Therefore, the size and scope of the logic represented by the service can vary. Further, service logic can encompass the logic provided by other services. In this case, one or more services are composed into a collective.

For example, business automation solutions are typically an implementation of a business process. This process is comprised of logic that dictates the actions performed by the solution. The logic is decomposed into a series of steps that execute in predefined sequences according to business rules and runtime conditions.

As shown in Figure 3.1, when building an automation solution consisting of services, each service can encapsulate a task performed by an individual step or a sub-process comprised of a set of steps. A service can even encapsulate the entire process logic. In the latter two cases, the larger scope represented by the services may encompass the logic encapsulated by other services.

Figure 3.1. Services can encapsulate varying amounts of logic.

For services to use the logic they encapsulate they can participate in the execution of business activities. To do so, they must form distinct relationships with those that want to use them.

3.1.3. How services relate

Within SOA, services can be used by other services or other programs. Regardless, the relationship between services is based on an understanding that for services to interact, they must be aware of each other. This awareness is achieved through the use of service descriptions.

A service description in its most basic format establishes the name of the service and the data expected and returned by the service. The manner in which services use service descriptions results in a relationship classified as loosely coupled. For example, Figure 3.2 illustrates that service A is aware of service B because service A is in possession of service B's service description.

Figure 3.2. Because it has access to service B's service description, service A has all of the information it needs to communicate with service B.

For services to interact and accomplish something meaningful, they must exchange information. A communications framework capable of preserving their loosely coupled relationship is therefore required. One such framework is messaging.

3.1.4. How services communicate

After a service sends a message on its way, it loses control of what happens to the message thereafter. That is why we require messages to exist as "independent units of communication." This means that messages, like services, should be autonomous. To that effect, messages can be outfitted with enough intelligence to self-govern their parts of the processing logic (Figure 3.3).

Figure 3.3. A message existing as an independent unit of communication.

Services that provide service descriptions and communicate via messages form a basic architecture. So far, this architecture appears similar to past distributed architectures that support messaging and a separation of interface from processing logic. What distinguishes ours is how its three core components (services, descriptions, and messages) are designed. This is where service-orientation comes in.

3.1.5. How services are designed

Much like object-orientation, service-orientation has become a distinct design approach which introduces commonly accepted principles that govern the positioning and design of our architectural components (Figure 3.4).

Figure 3.4. Service-orientation principles address design issues.

The application of service-orientation principles to processing logic results in standardized service-oriented processing logic. When a solution is comprised of units of service-oriented processing logic, it becomes what we refer to as a service-oriented solution.

The individual principles of service-orientation are fully explained later in this book. For the purpose of providing a preliminary introduction, let's highlight some of the key aspects of these principles here:

• Loose coupling Services maintain a relationship that minimizes dependencies and only requires that they retain an awareness of each other.
• Service contract Services adhere to a communications agreement, as defined collectively by one or more service descriptions and related documents.
• Autonomy Services have control over the logic they encapsulate.
• Abstraction Beyond what is described in the service contract, services hide logic from the outside world.
• Reusability Logic is divided into services with the intention of promoting reuse.
• Composability Collections of services can be coordinated and assembled to form composite services.
• Statelessness Services minimize retaining information specific to an activity.
• Discoverability Services are designed to be outwardly descriptive so that they can be found and assessed via available discovery mechanisms.

With a knowledge of the components that comprise our basic architecture and a set of design principles we can use to shape and standardize these components, all that is missing is an implementation platform that will allow us to pull these pieces together to build service-oriented automation solutions. The Web services technology set offers us such a platform.

3.1.6. How services are built

As we mentioned earlier, the term "service-oriented" and various abstract SOA models existed before the arrival of Web services. However, no one technology advancement has been so suitable and successful in manifesting SOA than Web services.

All major vendor platforms currently support the creation of service-oriented solutions, and most do so with the understanding that the SOA support provided is based on the use of Web services. Therefore, while we fully acknowledge that achieving SOA does not require Web services, this book's focus is on how SOA can and should be realized through the use of the Web services technology platform.

3.1.7. Primitive SOA

The past few sections have described the individual ingredients for what we call primitive SOA. It is labeled as such because it represents a baseline technology architecture that is supported by current major vendor platforms.

All forms of SOA we explore from here on are based on and extend this primitive model. Some of the extensions we discuss are attainable today through the application of advanced design techniques, while others rely on the availability of pre-defined Web services specifications and corresponding vendor support.

Case Study

RailCo's accounting solution exists as a two-tier client-server application, where the bulk of application logic resides within an executable deployed on client workstations. The details of this application are described in the next chapter. For now, let's identify two of the primary tasks this application can perform:

• Enter Customer Purchase Order
• Create Customer Order

The completion of each task involves a series of steps that constitute a business process. This process was originally modeled using standard workflow logic and then implemented as part of a packaged solution. Within the application, the process may or may not be separately represented by individual sets of programming routines. Regardless, it is compiled into a single executable that provides a fixed manner in which the process is automated.

Within a service-oriented business model, the logic behind each process would be partitioned into one or more services. If multiple services are used, the execution of the entire process would involve the composition of these services. In this case, each service may represent a sub-process or even a single step within the process that can be executed independently. For example, the Create Customer Order Process may consist of the following sub-processes:

• Retrieve Purchase Order Data
• Check Inventory Availability
• Generate Back Order
• Publish Customer Order

As we know, a process in its entirety can be viewed and modeled as a service. Additionally, one or more processes can be combined to represent an even larger service. For example, the Create Customer Order and Generate Customer Invoice Processes may be combined to form a single Order Processing Process.

Finally, we would also expect these processes to be flexible so that they can incorporate processes or resources that exist elsewhere in the enterprise. For instance, we may decide to extend the Order Processing Process to include a sub-process that automatically retrieves the customer's current accounts payable mailing address. This sub-process may already exist as part of a separate Customer Contact Reporting Process.

To implement such a model, we need a technical architecture capable of providing the following:

• The ability for business automation logic to be partitioned into units so as to properly represent services.
• The ability for these units of logic to be relatively independent of each other so as to support the requirement for them to participate in different compositions.
• The ability for these units of logic to communicate with each other in such a manner that their respective independence is preserved.

The fundamental characteristics of service encapsulation, loose-coupling, and messaging, as realized through service-orientation principles and the Web services technology set, collectively fulfill these requirements through the implementation of a primitive SOA.

SUMMARY OF KEY POINTS

• SOA and service-orientation are implementation-agnostic paradigms that can be realized with any suitable technology platform.
• Our primitive SOA model represents a mainstream variation of SOA based solely on Web services and common service-orientation principles.
• Throughout the remainder of this book, any reference to the term "SOA" implies the primitive SOA model.