3.2  Types of Service-Oriented Technology Architectures

As weÕve already established, every software program ends up being comprised of and residing in some form of architectural combination of resources, technologies, and platforms (infrastructure-related or otherwise). If we take the time to customize these architectural elements, we can establish a refined and standardized environment for the implementation of (also customized) software programs.

The intentional design of technology architecture is very important to service-oriented computing. It is essential to establishing an environment within which services can be repeatedly recomposed to maximize business requirements fulfillment. As evidenced by the range of architectural design patterns in this book, the strategic benefit to customizing the scope, context, and boundary of an architecture is significant.

Below are the common types of technology architectures that exist within a typical service-oriented environment:

•     Service Architecture

•     Service Composition Architecture

•     Service Inventory Architecture

•     Service-Oriented Enterprise Architecture

Although they roughly correspond to the traditional architecture types described earlier, each is distinct due to the unique requirements of service-orientation. The following sections explore them individually.

Note: If you have not read SOA: Principles of Service Design, be sure to look up the definitions for service, service composition, service inventory, and composition member at SOAGlossary.com before proceeding.

Service Architecture

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 agnostic services that need to exist as independent and highly self-sufficient and self-contained software programs requires that each be individually designed.

Figure 3.7 – An example of a high-level service architecture view depicting the parts of the surrounding infrastructure utilized to fulfill the functional requirements of all service capabilities. 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.

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 3.8 – Outside access to service architecture documentation is often limited. In this figure, service consumer designers are only given access to a specific set of published service description documents. The remaining details of the service design are deliberately hidden.

The application of design standards and other service-orientation design principles 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 3.9 – This diagram provides an example of how service-orientation design principles can establish a specific set of design characteristics within a service. Many of these characteristics are designed in advance as part of the service architecture specification.

A central part of a service architecture is its technical contract. Following standard service-oriented design processes, the service contract is generally 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.

This is why some consideration is given to implementation during the service modeling phase. The details documented during this analysis stage are carried forth into design and much of this information can make its way into the official architecture definition.

Figure 3.10 – The service contract is a fundamental part of the service architecture. Its definition gives the service a public identity and helps express its functional scope. In this diagram, the WSDL document (A) expresses operations that correspond to segments of functionality (B) within the underlying Web service logic. The logic, in turn, accesses other resources in the enterprise to carry out those functions (C). The WSDL definition expresses data exchange requirements via type definitions established in separate XML schemas (D).

Another infrastructure-related aspect of service design that may be part of a service architecture is any dependencies the service may have on system agents. The specific agent programs may be identified along with runtime information as to how message contents are processed or even altered by agent involvement. The service agent programs may themselves also have architecture specifications that can be referenced by the service architecture.

Figure 3.11 – Service agents identified as being part of a service architecture.

A key aspect of any service architecture is the fact that the functionality offered by a service resides within one or more individual capabilities. This often requires the architecture definition itself to be taken to the capability level.

Each service capability encapsulates its own piece of logic. Some of this logic may be custom-developed for the service whereas other capabilities may need to access one or more legacy resources. Therefore, individual capabilities end up with their own, individual designs which may need to be so detailed that they may appear as separate Òcapability architectures.Ó However, all relate back to the parent service and its implementation characteristics.

Service Composition Architecture

The fundamental purpose of delivering a series of independent services is so that they can be combined into fully functional solutions capable of automating larger, more complex business tasks. When a set of services is combined into an aggregate for this purpose, it forms a service composition for which a corresponding service composition architecture needs to be defined.

Figure 3.12 – A service composition from a modeling perspective. The numbered arrows indicate the sequence of data flow and service interaction.

In much the same way as an application architecture for a distributed system includes the individual architecture definitions of its components, this form of architecture encompasses service architectures of all composition members involved.

Figure 3.13– The same service composition from Figure 3.x viewed from a physical architecture perspective illustrating how each composition memberÕs underlying resources provide the functionality required to automate the compositionÕs parent task.

A composition architecture (especially one that composes service capabilities 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.

One difference in how composition architectures are documented is in the extent of detail they include about agnostic services involved in the composition. Because these types of service architecture specifications are often guarded, a composition architecture may only be able to make reference to the technical interface documents and SLA-related information published as part of the serviceÕs public contract.

Figure 3.14 – All that may be available about agnostic composition members is the information published in their contracts. This diagram depicts a composition architecture from the composition designers perspective when the Service Abstraction principle has been applied to two of the composition member services.

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

Figure 3.15 – The previously illustrated composition finds itself nested within a larger composition.

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 non-agnostic task 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 provides the composition logic to invoke and interact with all identified composition members.

Furthermore, the business process the task 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. 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 may need to face.

Figure 3.16 – 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, an alternative composition configuration kicks in to deal with an exception condition. This instance of the composition results in a scenario wherein the Account Reports service composition is not even included.

Finally, the composition will rely on the activity management abilities of the underlying runtime environment responsible for hosting the composition members. Security, transaction management, reliable messaging, and other infrastructure extensions, such as support for sophisticated message routing, may all find their way into a composition architecture specification.

Note: Even though compositions are comprised of services, it is actually the service capabilities that are individually invoked and which execute a specific subset of service functionality in order to carry out the composition logic. This is why basic design patterns, such as Capability Composition and Capability Recomposition make specific reference to the composed capability.

Service Inventory Architecture

Services delivered independently or as part of compositions by different IT projects risk establishing redundancy and non-standardized functional expression and data representation. 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.

A service inventory is a collection of services delivered within a pre-defined architectural boundary (Figure 3.17). This collection represents a meaningful scope that exceeds the processing boundary of a single business process and ideally spans numerous business processes.

Figure 3.17 – An inventory of services hosted by a service inventory technology architecture, as represented by the blue container symbol. The scope and boundary of a service inventory architecture can vary, as explained in the Enterprise Inventory and Domain Inventory 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 3.18 – 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 architectural perspective, the service inventory can represent a concrete boundary for a standardized architecture implementation. That 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 5, 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.

Service Layers

Within a typical service inventory there will tend to be services that have similar functional contexts. However, these services may be designed and implemented differently, depending on the nature of the delivery project. This leads to a missed opportunity for establishing consistency in how service boundaries are defined and in the nature of the logic they encapsulate. The result is an inventory of services that cannot easily (or cleanly) be partitioned into groups for the purpose of sub-domain based abstraction and governance.

A service inventory architecture can formally establish classification profiles to represent common types of services within a given inventory. These profiles are referred to as service models, each of which represents a unique set of design characteristics associated with a well defined service category. Service models form the basis for service layers in that a collection of services that conform to one model establish a logical architectural layer of related functionality.

Figure 3.19 – Establishing service layers ensures that services matching common types are designed with the same fundamental characteristics, as derived from common service models. These services can form logical domains within the inventory which can be evolved and governed as groups.

Service layers further allow for groups of services to be owned and governed by custodians most suited to the nature of the underlying service models (Figure 3.20).

Figure 3.20 – Layers (and sub-layers) can form groups of services that can be assigned to dedicated custodians for long-term governance ownership.

The safest way to define service layers is to base them on common industry service models. These fundamental models solve different design problems and are therefore represented by the following basic design patterns (formally described in Chapter 5):

•     Process Abstraction

•     Entity Abstraction

•     Utility Abstraction

Note that organizations can also choose to derive custom variations from industry service models or even create new service models altogether. Sometimes this approach is warranted when a service inventory spans domains and a business domain-specific service model is defined.

A service inventory architecture formally defines service layers to establish the fundamental structure of a service inventory. However, these layers are ideally first defined during the service modeling stage, well before the technology architecture is defined, prior even to the creation of the service inventory blueprint.

Figure 3.21 –

Service Inventory Architecture and Integration Architecture

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 represented 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 homogenous environment where integration, as a separate process, is not required to achieve connectivity.

Note: For more information about how service-orientation differs from and attempts to address the primary challenges associated with silo-based, standalone application environments, see SOAPrinciples.com.

Service-Oriented Enterprise Architecture

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

A service-oriented enterprise architecture is comparable to a traditional enterprise 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 may exists as a subset of the parent enterprise 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.