This chapter is from the book
This chapter is from the book
This chapter is from the book
5.6 Key Design Considerations
“Enterprise” vs. “Enterprise-wide”
Having discussed the notion of services as enterprise resources back in Chapter 4, 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 use across all service inventories within an enterprise.
This difference in terminology is especially relevant to design patterns associated with specific enterprise boundaries, such as Domain Inventory (123). Note also that a service positioned as an enterprise resource is expected to be an inventory-wide resource, meaning that it is interoperable from anywhere within the inventory boundary.
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 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.
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 were introduced in the Principles of Service-Orientation section in Chapter 4.)
Design Patterns and Design Granularity
Design granularity, as it pertains to service-orientation, is itself something worth being familiar with prior to reading the upcoming chapters. Provided here are brief descriptions of common granularity-related terms:
-
Service Granularity– The overall quantity of functionality encapsulated by a service determines the service granularity. A service’s granularity is set by its functional context, which is usually established during the service modeling phase.
-
Capability Granularity– The quantity of functionality encapsulated by a specific service capability determines the level of corresponding capability granularity.
-
Data Granularity– The quantity of data exchanged by a specific service capability determines the level of its data granularity.
-
Constraint Granularity– The extent of validation logic detail defined for a given service capability within the service contract determines the capability’s level of constraint granularity. Generally, the more specific the constraints and the larger the amount of constraints, the more fine-grained the capability’s constraint granularity is.
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).
Measures of Design Pattern Application
It is important to acknowledge that most patterns do not 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 affects both design patterns and design principles. For example, individual service-orientation design principles can rarely be applied to their maximum potential. The point is to pursue 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.