It’s well-known how the IT community borrowed the term “architecture” from its traditional association with the design and construction of buildings and structures. Its origin also helps us establish an analogy that is useful for distinguishing a technology architecture from a technology infrastructure.

A building has a physical design expressed in an architecture blueprint or specification. However, the building exists within a surrounding environment. This environment may or may not provide a lot of support for the building to fulfill its purpose. For example, an office or residential building located within a city is supported by the streets, power plants, utility pole cables, sewer systems, and other resources provided by the city environment. This supporting environment is analogous to technology infrastructure.

In order for a building to take advantage of these infrastructure extensions, its physical design needs to integrate them as part of its official architecture. Therefore, an architecture specification for a building will encompass the parts of its surrounding infrastructure that are relevant to the building. As a result, there is no firm boundary between what constitutes the building architecture and the environmental infrastructure. This same overlap exists in the IT world, as explained in the following definitions.

A technology architecture expresses fundamental and foundational aspects of physical design for some piece of technology. Whereas computer hardware products will have their own individual technology architectures, within a typical IT enterprise, we are most concerned with the architecture of software programs.

For a program we purchase, we may want to understand its internal design to ensure that it is compatible with the environment already established within our enterprise. For programs we build, it becomes our responsibility to define the physical design ourselves.

When designing a new software program, we need to take into consideration the environment in which it will need to be deployed and in which it will need to carry out its purpose. In most established enterprises, implementation environments already exist in the form of servers, operating systems, and runtime and middleware platforms. As explained in the next section, all of these parts are considered technology infrastructure. And, as with buildings and cities, the software program’s architecture is comprised of new parts interwoven with the relevant parts of the infrastructure that already exist as part of the surrounding environment.

The scope of technology architecture can vary depending on what it is we are designing. Some well-known types include:

As shown in Figure 3.2, each of these architecture types represents a different scope, whereby one tends to encompass the other.

Figure 3.2 Common traditional levels of documented technology architecture.

In a service-oriented environment the scope of technology architecture can also vary. The distinct forms of service-oriented architectures and how they roughly correspond to the previously listed traditional architecture types is explained separately in the section The Four Types of Service-Oriented Technology Architecture in Chapter 4.

Within a typical IT enterprise, technology infrastructure represents the environment in which software programs are deployed. As with the term “architecture,” infrastructure can also be qualified with “software” or “hardware” to identify certain parts of this environment.

Common forms of hardware infrastructure include:

Types of software typically considered part of an enterprise’s technology infrastructure include:

What generally distinguishes a technology that is part of infrastructure from one that is exclusive to a particular component or application architecture is that it is made available to multiple applications or systems and therefore exists as a resource of the enterprise (and is therefore also separately owned and governed). An example of a common software program that can be either classified as part of infrastructure or specific to an application architecture is a database (Figure 3.3).

Figure 3.3 A software program implemented within an enterprise finds itself dependent on various resources in the surrounding infrastructure.

As previously mentioned, relevant pieces of technology infrastructure find their way into almost all forms of architecture documentation because they become part of the architecture itself. An enterprise technology architecture specification often documents some or all of an enterprise’s infrastructure in a reference format that is made available to authors of other architecture design documents.

The infrastructure of an enterprise will frequently determine the processing potential of technology architectures that reside within it and are built upon it. This potential threshold is then further leveraged or constrained by the design of the architecture itself. Consequently, a software program is required to exist and execute within the boundaries and thresholds established by both its underlying infrastructure and architecture (as explained in Figure 3.4).

Figure 3.4 Technology infrastructures and architectures collectively establish boundaries that determine the processing thresholds of software programs. In this example, the maximum instances of a program that can be concurrently invoked is less than what the infrastructure can support because of limitations introduced by the architecture and the software program’s own implementation.

A software program is simply an existing system, application, or solution. It may represent a purchased product or a custom-designed program. In relation to technology architecture, a software program can be considered an implementation of the design documented in an architecture specification, as well as the logic that resides and executes within the supporting environment also specified by the technology architecture.

Part of a software program’s design can be documented within an application architecture specification. Usually this part is backend-centric with an emphasis on the program’s overall structure (including components it may be comprised of), technologies, and resource requirements. A typical application architecture specification is therefore frequently supplemented with additional types of design documents, such as functional specifications that illustrate the flow and style of the program user interfaces and detailed design documents that establish programming routines and algorithms.

Depending on the conventions, methodologies, or preferences of the IT department, this additional design information may or may not be considered part of the program’s official technology architecture (Figure 3.5).

Figure 3.5 The physical design of a software program is partially defined by its application architecture along with relevant parts of the surrounding infrastructure. Other documents, such as a functional specification, establish additional design characteristics, such as the program’s user-interfaces.

Chapter 3 of SOA Principles of Service Design documents a base design framework that includes the following terms:

Figure 3.6 illustrates how closely this design framework can tie into the architecture-related vocabulary we just covered. In the end, principles, patterns, and architecture all revolve around and influence design.

Figure 3.6 How the elements of a design framework can be associated with architecture-related elements.

Service-oriented computing is an umbrella term that represents a new generation distributed computing platform. As such, it encompasses many things, including its own design paradigm and design principles, design patterns, a distinct architectural model, and related concepts, technologies, and frameworks.

Service-oriented computing builds upon past distributed computing platforms and adds new design layers, governance considerations, and a vast set of preferred implementation technologies, several of which are based on the Web services framework.

In this book we make reference to the strategic goals of service-oriented computing as they relate to the application of service-orientation and the design of service-oriented architecture. These goals are briefly described in the section The Method of Service-Orientation in Chapter 4.

Service-orientation is a design paradigm intended for the creation of solution logic units that are individually shaped so that they can be collectively and repeatedly utilized in support of the realization of the specific strategic goals and benefits associated with SOA and service-oriented computing.

Solution logic designed in accordance with service-orientation can be qualified with “service-oriented,” and units of service-oriented solution logic are referred to as “services.” As a design paradigm for distributed computing, service-orientation can be compared to object-orientation (or object-oriented design). Service-orientation, in fact, has many roots in object-orientation and has also been influenced by other industry developments, as shown in Figure 3.7.

Figure 3.7 Service-orientation is very much an evolutionary design paradigm that owes much of its existence to established design practices and technology platforms.

The service-orientation design paradigm is primarily comprised of eight design principles, which are listed in the section The Method of Service-Orientation in Chapter 4. These principles are further summarized in Appendix C and referenced by all subsequent design pattern descriptions so as to highlight potential relationships between the application of a pattern and the application of related design principles.

Service-oriented architecture represents an architectural model that aims to enhance the agility and cost-effectiveness of an enterprise while reducing the burden of IT on the overall organization. It accomplishes this by positioning services as the primary means through which solution logic is represented. SOA supports service-orientation in the realization of the strategic goals associated with service-oriented computing. Historically, the term “service-oriented architecture” (or “SOA”) has been used so broadly by the media and within vendor marketing literature that it has almost become synonymous with service-oriented computing itself.

As a form of technology architecture, an SOA implementation can consist of a combination of technologies, products, APIs, supporting infrastructure extensions, and various other parts. The actual complexion of a deployed service-oriented architecture is unique within each enterprise; however it is typified by the introduction of new technologies and platforms that specifically support the creation, execution, and evolution of service-oriented solutions. As a result, building a technology architecture around the service-oriented architectural model establishes an environment suitable for solution logic that has been designed in compliance with service-orientation design principles.

Chapter 4 establishes distinct types of service-oriented architecture and documents four key characteristics that each variation should possess in order to fully support service-orientation. These architecture types are then further referenced by design pattern descriptions in order to highlight the potential scope or applicability of a given pattern.

A service is a unit of solution logic (Figure 3.8) to which service-orientation has been applied to a meaningful extent. It is the application of service-orientation design principles that distinguishes a unit of logic as a service compared to units of logic that may exist solely as objects or components.

Figure 3.8 The chorded circle symbol is used to represent a service, primarily from a contract perspective.

Subsequent to conceptual service modeling, service-oriented design and development stages implement a service as a physically independent software program with specific design characteristics that support the attainment of the strategic goals associated with service-oriented computing.

A service corresponds, in scope, to the service architecture type described in Chapter 4. The design patterns in Part III of this book are further dedicated to or related to the design of services.

Each service is assigned its own distinct functional context and is comprised of a set of functions or capabilities related to this context. Therefore, a service can be considered a container of capabilities associated with a common purpose (based on a common functional context). The individual bullet items within the service symbol from Figure 3.8 are capabilities.

The term service capability has no implication as to how a service is implemented. Therefore, this term can be especially useful during service modeling stages when the physical design of a service has not yet been determined (at which point it is further qualified as a service capability candidate). As explained later in the Service Implementation Mediums section, once it is known whether a service exists as a Web service, a REST service, or a component, terms such as “service method” or “service operation” can be used instead.

When a program invokes and interacts with a service it is labeled as a service consumer. It is very important to understand that this term refers to the temporary runtime role assumed by a program when it is engaging a service in a data exchange.

For example, you can create a desktop application that is capable of exchanging messages with a service. When it is interacting with the service, the desktop application is considered a service consumer.

You can also design a service to invoke and interact with other services (which, in fact, forms the basis of a service composition, as explained in the next section). In this case, the service itself will temporarily act as the service consumer (Figure 3.9).

Figure 3.9 The Purchase Order service being accessed by a variety of programs acting as service consumers.

Many of the examples in the upcoming chapters show consumers as services. Furthermore, due to the unpredictable nature of data flow through service compositions, the directionality between consumers and services is intentionally not standardized in diagrams provided in this book (which is a deviation from the left-to-right convention used with traditional client-server illustrations).

A common alternative term for service consumer is service requester. Also, a term often used to represent the runtime role a service assumes when it is being invoked by a service consumer is service provider. These terms originated with the W3C and are therefore often used when services are built as Web services, as shown in Figure 3.10.

Figure 3.10 Three variations of a Web service showing the different physical parts of its architecture that come into play, depending on the role it assumes at runtime. Note how a service that transitions through service provider and consumer roles is further classified as an intermediary.

Many of the patterns in this book deal with design issues that are related to the interaction between service and consumer. Be sure to constantly keep in mind that any service can also be a service consumer.

A service composition is an aggregate of services collectively composed to automate a particular task or business process (Figure 3.11). To qualify as a composition, at least two participating services plus a composition initiator need to be present. Otherwise, the service interaction only represents a point-to-point exchange.

Figure 3.11 A service composition comprised of four services. The arrows indicate a sequence of modeled message exchanges. Note arrow #5 representing a one-way, asynchronous data delivery.

Much of the service-orientation design paradigm revolves around preparing services for effective participation in numerous complex compositions—so much so that the Service Composability design principle is dedicated solely to ensuring that services are designed in support of repeatable composition. A service composition in itself also represents one of the four SOA types explained in Chapter 4.

The design of a composition entails various architectural considerations in order to ensure that runtime service activities can be carried out as expected. Part IV of this book provides a set of chapters with patterns focused on composition design and related runtime processing.

A service inventory is an independently standardized and governed collection of complementary services within a boundary that represents an enterprise or a meaningful segment of an enterprise (Figure 3.12). When an organization has multiple service inventories, this term is further qualified as domain service inventory, as explained in the pattern description for Domain Inventory (123).

Figure 3.12 The standard symbol used to represent a service inventory in this book is the open blue container.

Service inventories are typically created through top-down delivery processes that result in the definition of service inventory blueprints. The subsequent application of service-orientation design principles and custom design standards throughout a service inventory is of paramount importance so as to establish a high degree of native inter-service interoperability. This supports the repeated creation of effective service compositions in response to new and changing business requirements.

The service inventory architecture is one of four SOA types explained in the following chapter. Part II of this book further provides a collection of fundamental and specialized patterns dedicated to service inventory design.

Service-oriented analysis represents one of the early stages in an SOA initiative and the first phase in the service delivery cycle. It is a process that often begins with preparatory information gathering steps that are completed in support of a service modeling sub-process that results in the creation of conceptual service candidates, service capability candidates, and service composition candidates.

The service-oriented analysis process is commonly carried out iteratively, once for each business process. When applied as part of a top-down approach, the scope of a planned service inventory will generally determine the extent of the service-oriented analysis effort. All iterations of a service-oriented analysis then pertain to that scope, with the goal of producing a service inventory blueprint. (Visit SOAMethodology.com for an explanation of the iterative service-oriented analysis process.)

A key success factor of service-oriented analysis is the hands-on collaboration of both business analysts and technology architects. The former group is especially involved in the definition of service candidates with a business-centric functional context because they understand the business processes used as input for the analysis and because service-orientation aims to align business and IT more closely.

The service definition process that is commonly carried out as part of a service-oriented analysis will usually contain steps that correspond to the foundational service patterns provided in Chapter 11.

When conceptualizing services during the service modeling part of the service-oriented analysis phase, services are defined on a preliminary basis and still subject to change and refinement before they are handed over to the service-oriented design project stage responsible for producing the physical service architecture. The term service candidate is used to help distinguish a conceptualized service from an actual implemented service.

A component is a software program designed to be part of a distributed system. It provides a technical interface comparable to a traditional application programming interface (API) through which it exposes public capabilities as methods, thereby allowing it to be explicitly invoked by other programs (Figure 3.13).

Figure 3.13 The symbols used to represent a component. The symbol on the left is a generic component that may or may not have been designed as a service, whereas the symbol on the right is explictly labeled to indicate that it has been designed as a service.

Components typically rely on platform-specific development and runtime technologies. For example, components can be built using Java or .NET tools and are then deployed in a runtime environment capable of supporting the corresponding component communications technology requirements, as implemented by the chosen development platform.

A Web service is a body of solution logic that provides a physically decoupled technical contract consisting of a WSDL definition and one or more XML Schema definitions and also possible WS-Policy expressions. The Web service contract exposes public capabilities as operations, establishing a technical interface but without any ties to a proprietary communications framework (Figure 3.14).

Figure 3.14 The typical Web service architecture containing a service contract, a component, and message processing logic comprised of event-driven agents, as per the pattern Service Agent (543).

Service-orientation can be applied to the design of Web services. The fact that Web services provide an architectural model whereby the service contract is physically decoupled and vendor-neutral is conducive to several of the design goals associated with service-orientation.

Representational State Transfer (REST) provides a means of constructing distributed systems based on the notion of resources. REST services (or RESTful Services) are lightweight programs that are designed with an emphasis on simplicity, scalability, and usability. REST services can be further shaped by the application of service-orientation principles.

As previously explained in the Web Service and REST Service Design Patterns section in Chapter 1, several REST-inspired candidate design patterns have been developed for this pattern catalog and are published at SOAPatterns.org.