4.6 Key Terms and Design Considerations

Services as Enterprise Resources

There are numerous references in this book to a service being qualified as an enterprise resource.

This term represents logic with the following primary characteristics:

•     The logic is available beyond a specific implementation boundary.

•     The logic is designed according to established design principles and enterprise standards.

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 a technical environment. An enterprise resource is simply logic positioned as an IT asset; an extension of the enterprise that does not belong to any one application. As further established in the Service Encapsulation pattern description, an enterprise resource essentially embodies the fundamental characteristics of service logic.

ÒEnterpriseÓ vs. ÒEnterprise-wideÓ

Having just introduced the notion of services as enterprise resources, it is important that there is a clear distinction between something that exists as a resource as part of an enterprise and something that is actually an enterprise-wide resource.

•     An enterprise resource is not a resource that is necessarily made available across the entire enterprise. Instead, it is a resource positioned for use within the enterprise, outside of and beyond any one particular application boundary. (In other words, it is a Òcross-siloÓ resource.Ó

•     An enterprise-wide resource, on the other hand, is truly intended for reuse across all service inventories within an enterprise.

This difference in terminology is especially relevant to design patterns associated with specific enterprise boundaries, such as the Domain Inventory pattern. Note also that a service positioned as an enterprise resource is expected to be an inventory-wide resource, meaning that it is accessible from anywhere within the inventory boundary.

Services as Web Services

As explained at WhatIsSOA.com, service-oriented solution logic is not limited to services implemented as Web services. Service-orientation can be effectively realized with standalone components as well as with logic exposed as Web services (Figure x.x).

While several of the patterns in this catalog can be applied to both of these implementation mediums, examples are primarily based on Web services. Web services allow the service contract to physically exist independently from the serviceÕs underlying logic and implementation. This provides new design options that have inspired SOA design patterns specific to the use of Web services.

Figure 4.8 – A typical Web service architecture in which the core solution logic is physically decoupled from the service contract and further supported by layers of message processing logic. The parts of a Web service that are executed depend on what runtime role it fulfills.

Design Patterns and Design Principles

Most of the upcoming design patterns reference design principles where appropriate to highlight a dependency or relationship or perhaps to describe the effect a design pattern may have on service-orientation.

Specifically, the relationship between service-orientation design principles and patterns can be defined as follows:

•     Design principles are applied collectively to solution logic in order to shape it in such a manner so that it fosters key design characteristics that support the strategic goals associated with service-oriented computing.

•     Design patterns provide solutions to common problems encountered when applying design principles – and – when establishing an environment suitable for implementing logic designed in accordance with service-orientation principles.

Figure 4.x summarizes the close relationship between design principle and design patterns.

Figure 4.9 – While design patterns help realize the application of service-orientation principles, these principles also influence how the patterns themselves are applied.

In many ways, design principles and patterns are alike. Both provide design guidance in support of achieving overarching strategic goals. In fact, it would not be unreasonable to think of the eight service-orientation principles as super patterns that are further supported by the patterns in this book.

Service-orientation design principles have another role in that they collectively define service-orientation as a design paradigm. Ultimately, it is best to view design patterns as providing support for the realization of design principles and their associated goals. (Design principles are documented separately in SOA: Principles of Service Design and SOAPrinciples.com.)

Design Patterns and Design Granularity

Design granularity, as it pertains to service-orientation, is itself something that you should be familiar with prior to reading the upcoming chapters. Specifically, it is suggested that you look up the following terms at SOAGlossary.com because several of the upcoming pattern descriptions reference these terms with no further explanation:

•     Service Granularity

•     Capability Granularity

•     Data Granularity

•     Constraint Granularity

The effect of design patterns on service-related design granularity can vary. For example, when applying multiple patterns (or compound patterns) to the same service, the end-levels of design granularity may be distinctly defined by that combination of patterns (and they may fluctuate between the application of one pattern to another).

Issues pertaining to capability granularity in particular are the subject of several design patterns in Chapter 8.

Measures of Design Pattern Application

It is important to acknowledge that most patterns do not necessarily propose a black or white design option. Design patterns can often be applied at different levels. Although the effectiveness of a given pattern will generally be equivalent to the extent to which it is realized, there may be practical considerations that simply limit the degree to which a pattern can be applied in the real world (as is often the case when designing service logic that is required to encapsulate legacy functionality).

This consideration applies equally to design patterns and design principles. For example, individual service-orientation design principles can rarely be applied to their maximum potential. The point is to take into consideration and incorporate the design goals of a design pattern or principle to whatever extent feasible and to strive for an end-result that realizes the pattern or principle to a meaningful extent.