There are eight distinct design principles that are part of the service-orientation design paradigm. Each addresses a key aspect of service design by ensuring that specific design characteristics are consistently realized within every service. When collectively applied to a meaningful extent, service-orientation design principles shape solution logic into something we can legitimately refer to as “service-oriented.”

Below are the eight service-orientation design principles together with their official definitions:

Figure 4.1 provides some perspective as to how these principles affect the design of a service. The application of the principles on the right side tend to result in concrete design characteristics being added to a service, whereas the principles on the left usually act as regulatory influences, ensuring a balanced application of service-orientation as a whole.

Figure 4.1 How service-orientation design principles relate to each other and how they collectively shape service design.

As just mentioned, a solution is considered service-oriented once service-orientation has been applied to a meaningful extent. A mere understanding of the design paradigm, however, is insufficient. To apply service-orientation consistently and successfully requires a technology architecture customized to accommodate its design preferences, initially when services are first delivered and especially when collections of services are accumulated and assembled into complex compositions.

Service-orientation emerged as a design approach in support of achieving the following goals and benefits associated with SOA and service-oriented computing:

When studying the design patterns in this book that support service-orientation, it is important to keep these goals (and the target state they represent) in mind. Understanding the ultimate state attainable provides us with a constant strategic context for each pattern. In other words, it helps provide insight into why certain parts of a service-oriented environment need to be designed in certain ways, which may not always be evident when reading through the pattern descriptions individually.

Traditional technology architectures were commonly designed in support of solutions delivered to fulfill tactical (short-term) business requirements. Because the overarching, strategic (long-term) business goals of the organization aren’t taken into consideration when the architecture is defined, this approach can result in a technical environment that, over time, becomes out of alignment with the organization’s business direction and requirements (Figure 4.2).

Figure 4.2 A traditional technology architecture (A) is often delivered in alignment with the current state of a business but can be incapable of changing in alignment with how the business evolves. As business and technology architectures become increasingly out of synch, business requirement fulfillment decreases, often to the point that a whole new technology architecture (B) is needed, which effectively resets this cycle.

This gradual separation of business and technology results in a technology architecture with diminishing potential to fulfill business requirements and one that is increasingly difficult to adapt to changing business needs.

When a technology architecture is business-driven, the overarching business vision, goals, and requirements are positioned as the basis for and the primary influence of the architectural model. This maximizes the potential alignment of technology and business and allows for a technology architecture that can evolve in tandem with the organization as a whole (Figure 4.3). The result is a continual increase in the value and lifespan of the architecture.

Figure 4.3 By defining a strategic, business-centric scope to the technology architecture, it can be kept in constant synch with how the business evolves over time.

Designing a service-oriented technology architecture around one particular vendor platform can lead to an implementation that inadvertently inherits proprietary characteristics. This can end up inhibiting the future evolution of an inventory architecture in response to technology innovations that become available from other vendors.

An inhibitive technology architecture is unable to evolve and expand in response to changing automation requirements, which can result in the architecture having a limited lifespan after which it needs to be replaced to remain effective (Figure 4.4).

Figure 4.4 Vendor-centric technology architectures are often bound to corresponding vendor platform roadmaps. This can reduce opportunities to leverage technology innovations provided by other vendor platforms and can result in the need to eventually replace the architecture entirely with a new vendor implementation (which starts the cycle over again).

It is in the best interest of an organization to base the design of a service-oriented architecture on a model that is in alignment with the primary SOA vendor platforms, yet neutral to all of them. A vendor-neutral architectural model can be derived from a vendor-neutral design paradigm used to build the solution logic the architecture will be responsible for supporting. The service-orientation paradigm provides such an approach, in that it is derived from and applicable to real world technology platforms while remaining independent of them.

Figure 4.5 If the architectural model is designed to be and remain neutral to vendor platforms, it maintains the freedom to diversify its implementation by leveraging multiple vendor technology innovations. This increases the longevity of the architecture as it is allowed to augment and evolve in response to changing requirements.

Just because solutions are based on a distributed architecture doesn’t mean that there still isn’t the constant danger of creating new silos. In fact, it has been common to build distributed solutions comprised of single-purpose components. Software programs labeled as services that are designed in this manner naturally result in silos (Figure 4.6) that continue to bloat the enterprise and lead to traditional integration requirements.

Figure 4.6 Single-purpose services delivered to automate specific business processes end up establishing silos within the enterprise.

When applying service-orientation, services are positioned as enterprise resources, which implies that service logic is designed with the following primary characteristics:

Essentially, the body of logic is classified as a resource of the enterprise. This does not necessarily make it an enterprise-wide resource or one that must be used throughout an entire technical environment. In other words, an enterprise resource does not belong solely to any one application or solution environment.

As further established in the pattern description for Service Encapsulation (305), an enterprise resource essentially embodies the fundamental characteristics of service logic.

In order to leverage services as enterprise resources, the underlying technology architecture must establish a model that is natively based on the assumption that software programs delivered as services will be shared by other parts of the enterprise or will be part of larger solutions that include shared services. This baseline requirement places an emphasis on standardizing parts of the architecture (as per the canonical patterns introduced in Chapter 5) so that service reuse and interoperability can be continually fostered (Figure 4.7).

Figure 4.7 When services are positioned as enterprise resources they no longer create or reside in silos. Instead they are made available to a broader scope of utilization by being part of a service inventory.

More so than in previous distributed computing paradigms, service-orientation places an emphasis on designing software programs as not just reusable resources, but as flexible resources that can be plugged into different aggregate structures as part of a variety of service-oriented solutions.

To accomplish this, services must be composable. As advocated by the Service Composability principle, this means that services must be capable of being pulled into a variety of composition designs, regardless of whether they are initially required to participate in a composition when they are first delivered (Figure 4.8).

Figure 4.8 Services within the same service inventory are composed into different configurations. The highlighted service is reused by multiple compositions to automate different business processes.

To support native composability, the underlying technology architecture must be prepared to enable a range of simple and complex composition designs. Architectural extensions (and related infrastructure extensions) pertaining to scalability, reliability, and runtime data exchange processing and integrity are essential to support this key characteristic.

A technology architecture limited to the physical design of a software program designed as a service is referred to as the service architecture. This form of technology architecture is comparable in scope to a component architecture, except that it will typically rely on a greater amount of infrastructure extensions to support its need for increased reliability, performance, scalability, behavioral predictability, and especially its need for increased autonomy. The scope of a service architecture will also tend to be larger because a service can, among other things, encompass multiple components.

Whereas it was not always that common to document a separate architecture for a component in traditional distributed applications, the importance of producing services that need to exist as independent and highly self-sufficient and self-contained software programs requires that each be individually designed. Figure 4.10 shows a highly simplified view of a sample service architecture.

Figure 4.10 An example of a high-level service architecture view for the Accounts Web service, depicting the parts of the surrounding infrastructure utilized to fulfill the functional requirements of all capabilities (or operations). Additional views can be created to show only those architectural elements related to the processing of specific capabilities. Further detail, such as data flow and security requirements, would normally also be included.

Information Hiding

Service architecture specifications are typically owned by service custodians and, in support of the Service Abstraction design principle, their contents are often protected and hidden from other project team members (Figure 4.11).

Figure 4.11 The custodian of the Accounts service intentionally limits access to architecture documentation. As a result, service consumer designers are only privy to published service contract documents.

Design Standards

The application of design standards and other service-orientation design principles (Figure 4.12) further affects the depth and detail to which a service’s technology architecture may need to be defined. For example, implementation consideration raised by the Service Autonomy and Service Statelessness principles can require a service architecture to extend deeply into its surrounding infrastructure by defining exactly what physical environment it is deployed within, what resources it needs to access, what other parts of the enterprise may be accessing those same resources, and what extensions from the infrastructure it can use to defer or store data it is responsible for processing.

Figure 4.12 Custom design standards and service-orientation design principles are applied to establish a specific set of design characteristics within the Accounts service architecture.

Service Contracts

A central part of a service architecture is typically its technical contract (Figure 4.13). Following standard service-oriented design processes, the service contract is usually the first part of a service to be physically delivered. The capabilities expressed by the contract further dictate the scope and nature of its underlying logic and the processing requirements that will need to be supported by its implementation.

Figure 4.13 The service contract is a fundamental part of the Accounts service architecture. Its definition gives the service a public identity and helps express its functional scope. Specifically, the WSDL document (A) expresses operations that correspond to segments of functionality (B) within the underlying Accounts service logic. The logic, in turn, accesses other resources in the enterprise to carry out those functions (C). To accomplish this, the WSDL document provides data exchange definitions via input and output message types established in separate XML Schema documents (D).

This is why some consideration is given to implementation during a service’s modeling phase (which occurs prior to its physical design).

Note

Many organizations use standard service profile documents to collect and maintain information about a service throughout its lifespan. Chapter 15 of SOA Principles of Service Design explains the service profile document and provides a sample template.

Service Agents

Another infrastructure-related aspect of service design is any dependencies the service may have on service agents—event-driven intermediary programs capable of transparently intercepting and processing messages sent to or from a service (Figure 4.14). Service agents can be custom-developed or may be provided by the underlying runtime environment, and they form the basis of a pattern appropriately titled Service Agent (543).

Figure 4.14 A variety of service agents are part of the Accounts service architecture. Some perform general processing of all data while others are specific to input or output data flow.

Within a service architecture the specific agent programs may be identified along with runtime information as to how message contents are processed or even altered by agent involvement. Service agents may themselves have their own architecture specifications that can be referenced by the service architecture.

Service Capabilities

A key consideration with any service architecture is the fact that the functionality offered by a service resides within one or more individual capabilities (Figure 4.15). This often requires the architecture definition itself to be taken to the capability level.

Figure 4.15 The Accounts service with an Add capability.

Each service capability encapsulates its own piece of logic, although the underlying logic may itself be modularized allowing different capabilities to share the same routines. Some of this logic may be custom-developed for the service, whereas other capabilities may represent or need to access one or more back-end resources (including other services). Therefore, individual capabilities end up with their own, individual designs that may need to be so detailed that they are documented as separate “capability architectures,” all of which relate back to the parent service architecture.

The fundamental purpose of delivering a series of independent services is so that they can be combined into service compositions—fully functional solutions capable of automating larger, more complex business tasks (Figure 4.16).

Figure 4.16 The Accounts service composition from a modeling perspective. The numbered arrows indicate the sequence of data flow and service interaction required for the Add capability to compose capabilities within the Client and Invoice services.

Each service composition has a corresponding service composition architecture. In much the same way an application architecture for a distributed system includes the individual architecture definitions of its components, this form of architecture encompasses the service architectures of all participating services (Figure 4.17).

Figure 4.17 The same Accounts service composition from Figure 4.16 viewed from a physical architecture perspective illustrating how each composition member’s underlying resources provide the functionality required to automate the process logic represented by the Accounts Add capability.

A composition architecture (especially one that composes services that encapsulate disparate legacy systems) may be compared to a traditional integration architecture. This comparison is usually only valid in scope, as the design considerations emphasized by service-orientation ensure that the design of a service composition is much different than that of integrated applications.

For example, one difference in how composition architectures are documented is in the extent of detail they include about reusable services involved in the composition. Because these types of service architecture specifications are often guarded (as per the requirements raised by the Service Abstraction principle), a composition architecture may only be able to make reference to the technical interface and service-level agreement (SLA) published as part of the service’s public contract (Figure 4.18).

Figure 4.18 The physical service architecture view from Figure 4.17 is not available to the designer of the Accounts service. Instead, only the information published in the contracts for the Invoice and Client services can be accessed and referenced in the Account service composition architecture.

Nested Compositions

Another rather unique aspect of service composition architecture is that a composition may find itself a nested part of a larger parent composition, and therefore one composition architecture may encompass or reference another (Figure 4.19).

Figure 4.19 The Accounts service finds itself nested within the larger Annual Reports composition that composes the Accounts Get History capability which, in turn, composes capabilities within the Client and Invoice services.

Task Services and Alternative Compositions

Service composition architectures are much more than just an accumulation of individual service architectures (or contracts). A newly created composition is usually accompanied by a task-specific service that is positioned as the composition controller. The details of this service are less private, and its design is an integral part of the architecture because it usually provides most of the composition logic required.

Furthermore, the business process the service is required to automate may involve the need for composition logic capable of dealing with multiple runtime scenarios (exception-related or otherwise), each of which may result in a different composition configuration (Figure 4.20). These scenarios and their related service activities and message paths are a common part of composition designs. They need to be understood and mapped out in advance so that the composition logic encapsulated by the task service is fully prepared to deal with the range of runtime situations it faces.

Figure 4.20 A given business process may need to be automated by a range of service compositions in order to accommodate different runtime scenarios. In this case, alternative composition logic within the Annual Report’s Revenue capability kicks in to deal with an exception condition. As a result, the Notification service is invoked prior to the Accounts service even being included in the composition. (This scenario represents an alternative composition design to the one shown in Figure 4.19.)

Services delivered independently or as part of compositions by different IT projects risk introducing redundancy and non-standardization. This can lead to a non-federated enterprise in which clusters of services mimic an environment comprised of traditional siloed applications.

The result is that though often classified as a service-oriented architecture, many of the traditional challenges associated with design disparity, transformation, and integration continue to emerge and undermine strategic service-oriented computing goals.

As first explained in Chapter 3, a service inventory is a collection of independently standardized and governed services delivered within a pre-defined architectural boundary. This collection represents a meaningful scope that exceeds the processing boundary of a single business process and ideally spans numerous business processes. The scope and boundary of a service inventory architecture can vary, as explained in the Enterprise Inventory (116) and Domain Inventory (123) pattern descriptions.

Ideally, the service inventory is first conceptually modeled, leading to the creation of a service inventory blueprint. It is often this blueprint that ends up defining the required scope of the architecture type referred to as a service inventory architecture (Figure 4.21).

Figure 4.21 Ultimately, the services within an inventory can be composed and recomposed, as represented by different composition architectures. To that end, many of the design patterns in this book need to be consistently applied within the boundary of the service inventory.

From an enterprise design perspective, the service inventory can represent a concrete boundary for a standardized architecture implementation. This means that because the services within an inventory are standardized, so are the technologies and extensions provided by the underlying architecture.

As evidenced by the inventory boundary design patterns in Chapter 6, the scope of a service inventory can be enterprise-wide, or it can represent a domain within the enterprise. For that reason, this type of architecture is not called a “domain architecture.” It relates to the scope of the inventory boundary, which may encompass multiple domains.

It is difficult to compare a service inventory architecture with traditional types of architecture because the concept of an inventory has not been common. The closest candidate would be an integration architecture that represents some significant segment of an enterprise. However, this comparison would be only relevant in scope, as service-orientation design characteristics and related standardization efforts strive to turn a service inventory into a highly homogenous environment.

This form of technology architecture essentially represents all service, service composition, and service inventory architectures that reside within a specific IT enterprise.

A service-oriented enterprise architecture is comparable to a traditional enterprise technical architecture only when most or all of an enterprise’s technical environments are service-oriented. Otherwise it may simply be a documentation of the parts of the enterprise that have adopted SOA, in which case it exists as a subset of the parent enterprise technology architecture.

In multi-inventory environments or in environments where standardization efforts were not fully successful, a service-oriented enterprise architecture specification will further document any transformation points and design disparity that may also exist.

Additionally, the service-oriented enterprise architecture can further establish enterprise-wide design standards and conventions to which all service, composition, and inventory architecture implementations need to comply, and which may also need to be referenced in the corresponding architecture specifications. (Canonical Resources (237) represents a pattern that may introduce such standards.)

Figure 4.22 illustrates how each of the previously described service-oriented architecture types establishes its own scope. Service architectures fall within composition architectures and both are natural parts of a service inventory architecture. The service-oriented enterprise architecture represents a parent architecture that encompasses all others.

Figure 4.22 A layered model of how service-oriented architecture types encompass each other. This view highlights the common levels of SOA that exist within a typical enterprise.

The environment and conventions established by the enterprise are carried over into individual service inventory architecture implementations that may reside within a single enterprise environment. These inventories further introduce new and more specific architectural elements (such as runtime platforms and middleware) that then form the foundation of service and composition architectures implemented within the inventory boundary.

As a result, a natural form of architectural inheritance is formed. This relationship between architecture types is good to keep in mind as it can identify potential (positive and negative) dependencies that may exist.

All of the architecture types explored so far relate mostly to a private IT enterprise environment. While these represent the most common variations, they are by no means the only ones. The following two sections discuss some examples of additional architecture types with different scopes and characteristics.